Examining vulnerability criticality when risk ranking vulnerabilities

Feb 16, 2017 / 2 min read

Table of Contents

Vulnerability criticality
Likelihood of an attack
What don’t I fix?

Every organization starting a security testing program struggles with addressing vulnerabilities. With limited resources in virtually all organizations, prioritizing this work is a requirement. That's where assessing vulnerability criticality comes in.

My previous post explained three steps to risk ranking your applications. This is critical because, quite simply, some of your applications warrant more scrutiny than others. Those applications that manage sensitive data or are core to achieving your business goals should be at the top of your list. Other applications, perhaps those that can’t be reached from outside your environment, may deserve less of your attention.

Once you have prioritized your applications, the next step is understanding which vulnerabilities pose the greatest risk.

Vulnerability criticality

The second step involves looking at the specific vulnerabilities. Your triage team needs to rank order these across all of your applications. A good starting point is to classify the vulnerabilities by severity and exploitability.

When a vulnerability is disclosed through NIST’s National Vulnerability Database (NVD), a 1 – 10 score is also provided using the Common Vulnerability Scoring System (CVSS). In addition, information is provided about the vulnerability’s impact on application Confidentiality, Integrity, Availability and how difficult it would be for an attacker to exploit this vulnerability.

The figure above shows a vulnerability with a base score of 9.8 – close to the highest score possible. It reaches this score not only by virtue of the type of vulnerability (input validation error), but by the degree of difficulty for an attacker to exploit the vulnerability. In this case, we see a few key pieces of information:

Attack Vector - The vulnerability access vector is the network. In other words, the attacker can be anywhere and remotely exploit the vulnerability.
Attack Complexity - The complexity of the vulnerability is low – so less-skilled attackers can take advantage of it, and “repeatable success” can be expected.
Privileges Required - No privileges (authentication) are required, simplifying the attack and (again) enlarging the number of potential adversaries.

Likelihood of an attack

That all sounds pretty bad, right? What could make it worse? Let’s check the references in the NVD listing…

How about a publicly available exploit?

Following the link brings you to a detailed proof of concept (sometimes you can even find YouTube videos explaining the exploit). Public exploits are obviously bad news, but not just because it makes a determined hackers job easier. It also subjects you to random, non-targeted attacks.

What don’t I fix?

It’s important to remember that security should always support business goals, and that some residual risk will likely always remain. The security team’s task is to make sure the remaining risk is within reasonable bounds. This will differ for each application, but even critical applications may be “ok” with minor, difficult to exploit vulnerabilities – that’s a judgment decision.

Finally, just because you agree to fix a vulnerability, it doesn’t necessarily happen overnight. Depending on engineering resources and release cycles, it may take weeks or months to replace a vulnerable component. Meanwhile, the bad people are busy looking for targets.

And that’s the subject of the next posting on this topic…