Vulnerability scans provide a way for organizations to check how resistant their networks will be to an attack. The way they typically work is this: a scan shows the known vulnerabilities in the target systems and then ranks them by severity, usually on a scale of “Low,” “Medium,” “High” and “Critical." In order to best protect the network, the Critical and High severity vulnerabilities are fixed, the Medium severity vulnerabilities are dealt with when and if there is personnel and budget capacity, and the Low severity vulnerabilities are left to persist indefinitely.

This approach to vulnerability management, focusing on the findings that the scanning tool labels as Critical and High severity, has some serious flaws that can leave networks at risk. It’s not that fixing these vulnerabilities is the problem, it’s that the Medium and Low severity vulnerabilities can pose significant risks as well. For any given vulnerability, we need to distinguish between its severity and the risk that results from it being present on a particular system on our network.

First it is necessary to understand how vulnerabilities are assigned a severity ranking. Let’s assume that the scanning tool’s severity rankings are based either directly or indirectly on a vulnerability’s CVSS score. Publicly known vulnerabilities cataloged in databases like the U.S. National Vulnerability Database are assigned a numeric severity score based on the CVSS, or the “Common Vulnerability Scoring System.”

The CVSS is currently in transition from version 2 to version 3, but for our purposes the difference between these versions is irrelevant. The general idea is that a number of criteria are considered in order to calculate a “Base Score” for a vulnerability. The Base Score ranges from 0-10 where the threshold for Medium Severity is 4.0, High is 7.0 and Critical is 9.0, and it is this information that is often used to assign severity ratings to vulnerability scanning tool findings.

The Base Scores are calculated using a number of factors including how complex a vulnerability is to exploit, where it can be exploited from, whether an attacker needs to be authenticated, and what the potential impact would be on confidentiality, integrity and availability. While these are all valid criteria that can tell us quite a bit about a vulnerability, the base score ignores some key things that should matter to us. The full version of the CVSS can also calculate “Temporal” and “Environmental” scores but these are not included in the severity ratings assigned by scanning tools, and for good reason.

Temporal scores are calculated based on whether or not exploits and/or patches exist for a vulnerability and will change over time as exploits are developed and patches are released. An argument can be made that a Medium severity vulnerability (according to the Base Score) that is being actively exploited should be a priority over a High or Critical severity vulnerability which is so far only theoretical.

The Environmental score factors in how many systems would potentially be affected by a vulnerability, the potential for collateral damage, and the confidentiality, integrity and availability requirements of the data that the vulnerability would affect. These Environmental metrics will be wildly different from one organization to the next and highlight the key issue with vulnerability remediation based on a CVSS Base Score.

Within any organization’s network some systems will be more critical than others, and not necessarily in the same way. For example, in a hospital environment availability will be paramount on the increasing number of network-connected medical machines that are literally keeping someone alive. A particular vulnerability may be assigned a CVSS base score that translates to Low or Medium severity because it “only” affects availability, but if that vulnerability affected one of these systems, the results could be fatal, and it should be considered a critical vulnerability in that context, regardless of the  severity listed by a scanning tool. This is where we get into the concept of the theoretical severity of a vulnerability in isolation from any real-world context versus the real-world risk of a vulnerability: how exploitation would affect an organization based on the actual systems affected, their functions and the data they contain.

Focusing on the Critical and High Risk vulnerabilities also ignores the possibility of vulnerabilities being chained together by an attacker. For example, one vulnerability may allow an attacker to gain a foothold on a system under an account with very low privileges while another vulnerability may allow an attacker to escalate privileges to an administrator level. Taken independently these vulnerabilities might each be Low or Medium severity but when combined together the result is an attacker who can gain remote access with administrator level privileges which many organizations would (or at least should) consider high risk. A real world example of how chaining vulnerabilities this way works can be seen in the “Hot Potato” exploit that relies on a series of Windows vulnerabilities, some of which date back over a decade.           

Organizations shouldn’t be prioritizing vulnerability remediation based on blind acceptance of severity ratings applied by their scanning tools. Instead we need much more focus on determining how detected vulnerabilities would affect specific systems, both alone and when combined with other vulnerabilities present on the network, and the risk this presents to the organization. The results might put some of those Low and Medium severity vulnerabilities at the top of the priority list, and for good reason.