Identifying and analyzing vulnerabilities can be a relatively complex process. In this video, you’ll learn about vulnerability databases, classification, exposure factor, risk tolerance, and more.
One of the challenges when looking through log files or receiving reports of vulnerability scans is that you’ll often have to sift through information that is simply not correct. We refer to this false information as a false positive. We’ve been given information that this particular vulnerability exists in this operating system. But after looking into it, you see that vulnerability really does not exist in that OS. In that scenario, you’ve been given a positive, but that positive is false.
When you look at a report of all of the vulnerabilities that may exist on a system, they’re usually in order of severity. So there may be high severity or critical vulnerabilities, and there may be some that are low or informational. Sometimes these vulnerabilities marked as low or informational are referred to as a false positive. Although these vulnerabilities are marked at a lower priority, they’re still valid vulnerabilities, and they should not be referenced as a false positive.
The reverse scenario to a false positive would be a false negative. And in many ways, a false negative is much worse than a false positive. A false negative means that the vulnerability does exist on that operating system, but you’re scanning software did not detect it. That means, in your report of known vulnerabilities, you won’t see that vulnerability listed anywhere. And if an attacker does come across that system, they may be able to exploit that vulnerability that you had no idea even existed.
If you’re planning to perform a vulnerability scan, it’s always a good idea to update your signatures. That way, you’ll minimize the number of false positives. And hopefully, you won’t run into a situation where there’s a false negative. And if you have questions about whether something is legitimate or not legitimate in the final output, you can always work with the scanning manufacturer directly to see if they can give you an updated set of signatures.
This categorization of severity is an important one because the critical vulnerabilities will probably need to be addressed first, and the low and informational vulnerabilities may be the last thing to address. Without any type of context, it may be difficult to take a single vulnerability and determine what priority needs to be set. Fortunately, there are a number of publicly available vulnerability lists that have already set these priorities. This would allow you to take the list of vulnerabilities that you found and put them in order from most critical to least critical.
If you’d like to see one of these scoring systems, they are available in the National Vulnerability Database that you can find at nvd.nist.gov. This list of vulnerabilities is synchronized with the main CVE list. And you can search through to find exactly what you’re looking for. Each vulnerability in this list is assigned a score. We refer to this as the Common Vulnerability Scoring System, or CVSS. Each vulnerability has a score between 0 and 10, where 10 would be the most critical.
These scoring systems have changed a bit over time. So often, there will be multiple scores available with the version number of the scoring system. For example, you might see a vulnerability that has different scores associated with it, and one of those scores might be the CVSS 2.0 score. The other might be a CVSS 3.x score. The industry wants to make these vulnerability lists valuable, and having a separate score allows you to prioritize them based on your specific needs.
You’ll often be referencing these vulnerability lists, especially when you see something unknown pop up in your vulnerability scanner. Fortunately, all of these lists are available online, and most vulnerability scanners will specify what CVE is associated with that vulnerability. You can cross-reference this against the National Vulnerability Database at nvd.nist.gov. You can also look at the Common Vulnerabilities and Exposures database, or the CVE, at cvve.mitre.org/cve.
If the vulnerability is specific to Microsoft, you might even check the Microsoft website. And the URL is listed here for the Microsoft security bulletins. Most manufacturers will have a database of their own vulnerabilities. So once you’ve referenced the CVE database, you may want to go directly to the manufacturer to see what other information they can provide.
Some vulnerability scanners are very good at identifying specific vulnerabilities and their related CVE. But some vulnerabilities may be very generic, or it may not have a CVE associated with it. So you may either want to verify that that vulnerability really exists or do additional research against the CVE database to see if you can identify it. Your vulnerability scanner is going to identify any vulnerabilities that it finds and then provide you with additional context of how that vulnerability is associated with a severity.
The key to the vulnerability scanner is the database of vulnerabilities that it knows about. So before you begin any type of vulnerability scan, you want to make sure you’re always using the latest set of signatures. Vulnerability scans are also able to search for many different types of vulnerabilities. For example, they can perform application scans to look for vulnerabilities inside of desktop applications or mobile apps. For example, CVE 2020-1889 was a vulnerability that allowed a bypass in the WhatsApp desktop.
Vulnerability scanners can also scan web applications located on a web server. CVE 2020-24981 is specific to an incorrect access control vulnerability in UCMS version 1.4.8 which is a web-based application. And your vulnerability scanner may be able to identify vulnerabilities inside of firewalls, switches, routers, and other network devices. CVE 2020-2579 found an issue inside of D-Link software and provided an option for fixing that particular issue.
Once we’ve identified a vulnerability in our network, we want to understand how risky it might be to have that vulnerability existing on those systems. One of the ways that you can quantify that is with an exposure factor. An exposure factor is usually represented as a percentage. For example, if this vulnerability might cause this particular service to become unavailable half the time, we can specify that that is a 50% exposure factor.
Or we know that this particular vulnerability doesn’t have any patches, it’s available on our public web servers, and, if somebody does exploit that vulnerability, they may be able to completely disable a service. In that situation, we might want to consider that a 100% exposure factor. The CVSS scores and your own exposure factor numbers can help you understand where to prioritize the fixes for these particular vulnerabilities, especially if you have limited resources.
Another consideration when planning for patching is understanding the environment. This vulnerability might exist on a public cloud, or it might be in a test lab, and we would handle the patching for those in very different ways. We would obviously want to patch both of those different environments. But something that is on a public cloud that’s accessible to everyone on the internet would obviously have a much higher priority than a single system located in a lab which has no other connectivity to the rest of the network.
Every organization has a different set of metrics when it comes to determining what’s important and what isn’t. But usually, you would look at the number and type of users that would be accessing that system and whether the system is one that’s only internally facing or whether it’s one that may be available to others outside the organization. We might also want to consider if this application is a key or critical application for the company and if this application happens to be revenue-generating. And of course, if this is a relatively easy vulnerability to exploit, it may be at the highest priority for fixing as quickly as possible.
The impact can also be very different depending on the type of organization it might be. Some organizations are much more sensitive to any type of outage than others. For example, Tallahassee Memorial Health in February of 2023 was hit with ransomware, and they were closed for two weeks. During that time frame, they had to divert all emergency cases to different hospitals, and anything that was scheduled for surgery during that time frame had to be canceled.
There’s a different set of considerations if your organization is one that is a power generator. For example, in March of 2019 in Salt Lake City, Utah and LA County, California there were distributed denial-of-service attacks that brought systems down for both of those organizations. All of these attacks obviously had a dramatic impact on all of these organizations. But depending on the type of organization you are, the same exploit could have a very different effect across different organizations.
One of the challenges of managing security patches is that you can’t patch all devices all at the same time. You have to set some type of priority over which patch is installed first, which is installed second, and so on. The process of determining which device may be more important than another may depend on how risky it is to have that vulnerability exist on that device. We refer to this prioritization as a risk tolerance. This describes how much risk an organization is willing to accept by having that particular vulnerability still unpatched.
It would be great if we could take a patch from a manufacturer and immediately install it the moment it’s available. But of course, we can’t deploy the patch until we know the patch is going to work properly in our environment. And that requires us to perform a great deal of testing. While we’re going through this testing process, we’re obviously still vulnerable. And so the organization needs to decide how much or little testing needs to take place so that we can close that particular hole and minimize the amount of risk.
In most organizations, there’s a middle ground. We want to be able to perform as much testing as we can. But we also want to be sure that our organization is secure. And if this particular vulnerability is one that affects many of our systems, and it’s a relatively easy vulnerability to exploit, we may have a very low tolerance. And we may want to rush through that testing process so we can patch those systems as quickly as possible.