Security administrators have many tools to help protect network resources. In this video, you’ll learn about Security Content Automation Protocol (SCAP), secure baselines, SIEMs, and more.
On your enterprise network, there are probably many different security tools. You might have next generation firewalls, intrusion prevention systems, your IT department is probably performing standard vulnerability scans. There are many different sources of information. And all of these have very different types of logs and descriptions of what they’re finding on your network. The challenge, of course, is that a next generation firewall, an IPS, and a vulnerability scanner could all identify the same vulnerability. But they might all use different terms, different titles, different descriptions all to describe the same vulnerability.
To address this, the industry has created the Security Content Automation Protocol, or SCAP. This SCAP protocol is maintained by the National Institute of Standards and Technology, or NIST. And you can find out more about it at scap.nist.gov. SCAP allows for the consolidation of these vulnerabilities into a single language that all devices will understand. So if you find the same vulnerability with a next gen firewall, and intrusion prevention system, and a vulnerability scanner, SCAP will allow all of those devices to identify them as exactly the same vulnerability.
This also means that these very diverse security tools can now start working together and automate the detection and removal of these vulnerabilities from your network. This means we can have a vulnerability scanner that can identify a device that might have a vulnerability and send that information off to your management system, which can then automate the process of sending a patch and fixing that vulnerability, all without any type of human intervention.
This can be especially useful if you have hundreds or even thousands of devices, and you need to patch a lot of different vulnerabilities across multiple operating systems. And now that all of your security devices are using exactly the same language to be able to identify a single vulnerability, they can much easier communicate with each other and automate the process of patching those systems.
This means processes that were very manual before can be completely automated. You can have your monitoring system constantly scanning and looking for vulnerabilities. You can notify an alert when a vulnerability is found. And then the patching process can be automatically pushed out to those systems to bring them back into compliance. Throughout this course, we often talk about best practices for security. And through the years, we’ve been able to compile a set of best practices for practically any operating system and any application.
This means we can grab a list of the best practices for a particular operating system and configure that entire operating system to be as secure as possible. The same thing will apply to applications that you use, connections to cloud providers, and everything else you’re using in your environment. Here’s an example of a security benchmark for a mobile device. This benchmark would disable screenshots, disable screen recordings, prevent voice calls when the system is locked, force encryption backups, and so on.
This combination of security best practices creates a benchmark that makes this system as secure as possible right out of the box. There’s an extensive library of these benchmarks available at the Center for Internet Security, or CIS. And you can visit their website at cissecurity.org. One of the challenges in keeping all of these devices secure is that there are constant changes occurring to the devices, and we’re also finding new vulnerabilities all the time.
So every time these systems connect to a network or someone logs in, we tend to scan the system to make sure that it is in compliance. Sometimes, this is done with an agent that is previously been installed onto that device. And there’s other cases where we might run an on-demand agentless check. Installing an agent onto a system requires some setup program, and you have to plan to install that agent on that system prior to performing the check.
One of the advantages of having this agent-based system is that it’s always on and always running to check and make sure that the system is always in compliance. But this also requires that you constantly update the agent either with the agent code itself or with the descriptions of what needs to be applied to that system. An agent list check runs without performing any type of formal install, and it usually runs when you first log in or connect to something like a VPN concentrator.
It will then execute in the memory of that system, check and verify that it is in compliance, and if everything looks good, it will automatically remove itself from the system. Since there’s nothing permanently installed on that device, you don’t have to provide any ongoing maintenance of the software or the descriptions of the security best practices. But this agent list system obviously will not be running 24 hours a day and seven days a week. So you have to make sure that you’re able to execute that agentless system on a regular basis.
We’ve often talked about a SIEM, or a Security Information and Event Manager, which is very commonly used to consolidate log files to a central database. We can then use that log file to create numerous reports to give us an idea of how the security may be running in our network. These SIEMs are not only very good at consolidating many different log types and putting them into one central database, but they usually include a very powerful reporting engine.
This means we can easily create reports on how our firewall might be performing or a VPN concentrator may be authenticating. But it also means that we can correlate data between these different data types. So we can examine someone logging into a VPN concentrator, looking at the applications that they may be running from an application server, and then identifying any rules that may be blocked in a firewall while that application is running.
Since we’re also storing this information into this very large database over a very long period of time, we can also use the SIEM to create forensics reports. This might give us more ideas of what happened prior to a particular security event and allow us to go back in time to see what information might be available to help us better understand how this event occurred.
Another security tool that’s included with many operating systems these days is antivirus and anti-malware. These tools are used to identify malicious software, such as Trojan horses, worms, macro viruses, and other types of malware. And although malware is a very broad term that could incorporate both viruses and other types of malicious software, commonly malware is associated with spyware, ransomware, fileless malware, and other types of malicious code.
The difference is between those two, though, are relatively minor. And the way that we use the software today, both terms tend to be interchangeable. So you will commonly refer to antivirus software and anti-malware software as effectively the same software on your system. If you’d like to stop sensitive data from being transferred across your network, then you should look into using Data Loss Prevention, or DLP. DLP is used to look for and block any type of data that you do not want running on your network.
So if somebody is transferring Social Security numbers, medical information, credit card data, or any other type of sensitive information, you can identify it and block it using a DLP solution. This provides a way to constantly monitor the traffic in real time. And if anything is identified that could be considered sensitive, you can block that, especially if you’re concerned about attackers trying to transfer that information outside of your network.
And on many networks, this is more than just one single appliance that’s connected to the network. So an organization might use DLP software on their endpoints or have cloud based systems that can monitor this traffic even when it’s in the cloud. You may not realize it, but you probably have monitoring software that’s built into the system that you’re using right now. This information is usually collected and provided using SNMP, or the Simple Network Management Protocol.
Depending on the device you’re using, there is a specific database of information that is being collected on your system. We refer to this database as a Management Information Base, or a MIB. Inside the MIB are a series of metrics that are being monitored. And instead of spelling out the individual name of each metric, we instead use object identifiers, which is a group of numbers. Sometimes, you’ll hear these referred to as an OID.
And if you look at a packet capture, you may see SNMP data being sent across the network over UDP port 161. This usually works by polling a device and receiving information back from that poll. So you might have a network management station that is asking a device like a router how much information has been transferred in bytes on a particular interface. And that device will respond back with that value.
The management station can then wait a certain amount of time, say five minutes or 10 minutes and then perform the same query again and collect an updated value for that information. Now that you have all of these statistics that you’ve been gathering over time, you can create graphs and charts showing the difference between one time frame and another. For example, this graph has been created by querying a firewall with SNMP and receiving response time information over a long period.
This polling process used by SNMP requires the management station to poll the device on regular intervals. And if that management station does not poll a device, then it simply won’t receive any data for that period. It would be more useful if there was a proactive alerting or alarming process. And with SNMP, there is one. It’s called an SNMP trap. You would configure the policies for this trap on the remote device running the SNMP agent. And whenever that trap happens to fire, it will proactively send an alarm or alert back to your management station over UDP 162.
For example, we may be monitoring CRC errors on a server, and we’ll configure the SNMP agent on that server to wait until the number of CRC errors increases by five. And if it does, send a trap back to the management station. Once the management station receives that trap, it can then fire off alerts, alarms, and text messages and emails and perform additional automation just by receiving that trap.
SNMP focuses on gathering lower level metrics from these devices, such as utilization or the number of packets passing through an interface. But there’s obviously more information that can be gathered from this information going across the network. And one of the ways to gather additional details is by using NetFlow. NetFlow is a standard for monitoring traffic flows and looking at statistics relating to application use.
There are many organizations that have NetFlow compatible agents, NetFlow management stations, or hardware devices. NetFlow commonly works by first having a probe to compile this information for the traffic flows. This NetFlow probe may be built into the software that’s included with a switch or router, or it may be included as a separate external probe. These probes may connect to the network with a monitoring port from a switch, like a switched port analyzer, or SPAN. Or there may be a physical tap on the network that’s providing the NetFlow probe with a copy of all network traffic flows.
These probes will then collect information and send a copy of those metrics down to a NetFlow collector, which can then be used to create reports and other details about the application traffic flows on your network. Here’s a summary of the type of information that you would get from a NetFlow collector that has received information from a probe. You can see top 10 conversations on the network, who’s talking to who, and how much traffic is being sent between those devices.
You can also see the top 10 endpoints on your network by their IP address or their fully qualified domain name. You can see where the NetFlow sources might be. And here’s a list of traffic analyzer events that might be interesting for the network or security administrator. There are many different dashboard screens and details. And usually, you can drill down into all of these to get more information about the traffic flows that are important to you.
We can also gather a great deal of information about our security posture by using a vulnerability scanner. This is designed to be minimally invasive. So it’s not going to perform any exploits to any systems. But it will gather details about whether a system could potentially hold a vulnerability. Many vulnerability scanners will also provide a port scan to see what services may be installed on a particular device. You can also provide a vulnerability scanner with a list of IP addresses or range, and it will find all of the devices that are active on that particular range.
We often will perform vulnerability scans within our own network. But it’s sometimes interesting to perform the same scan from outside of your network so that you can get a perspective of what a potential attacker might see. Vulnerability scans collect a lot of information, and not everything collected is entirely accurate. So it’s useful afterwards to go through a vulnerability scan to verify the information that was collected.
Here’s the output from a vulnerability scan. This one has found a number of critical vulnerabilities, some that are mixed in its severity, and others that may be listed as medium. And if you scroll down even further, you would see scan results that were qualified as low or informational. If we look at the results of this scan, we can see there’s an issue with the random number generator on a server. And this would allow someone to gain a shell of that device remotely.
We also have a Unix operating system that is unsupported, and therefore is probably not going to provide us with any type of security patches. We would commonly run these vulnerability scans on a regular basis so that we can avoid having any of these critical or high level vulnerabilities active on our network.