Prioritize Vulnerabilities as per Severity Level

Document created by Leif Kremkow on Apr 16, 2012
Version 1Show Document
  • View in full screen mode

A qualitative approach to setting the threshold determining which vulnerabilities should be addressed.


QualysGuard expresses the importance of vulnerabilities based on "Severity" levels. These Severity levels go from "1", the lowest, to "5", the highest. This article discusses how you can determine which vulnerabilities you will consider as relevant and which not. It offers a very simple approach based on the cost/gain ratio of a given vulnerability to help determine whether you should fix it.


Vulnerabilities are also categorized according to the reliability with which they were found, namely as "Vulnerabilities", or "Potential Vulnerabilities". This latter distinction is beyond this article. For now we will focus simply on the Severity level.

Damage Done

The Severity levels can be grossly reduced into three groups: High, Medium, and Low.


High vulnerabilities are those of Severity levels 4 or 5. Vulnerabilities of this group are those that give an attacker the possibility to execute code on the target; easily with a level 5, or less so, with a level 4.


In terms of CIA (Confidentiality, Integrity, Availability) you can assume that all three are compromised. If the attacker can run unauthorized code, potentiality with high privileges, then that code can extract information (Confidentiality is breached), tamper the data (Integrity is no longer guaranteed), or delete system/user data (Availability is no longer assured).


Medium vulnerabilities are those of Severity level 3.


Low vulnerabilities are those of levels 2 or 1.


The groups Medium and Low have something in common: they represent attack vectors that reveal information about a target, with increasing degrees of sensitivity (levels 1 to 3). Unlike High vulnerabilities, where and attacker might be able to execute code on the target, Medium and Low are all about information leakage.


A typical Severity level 1 example is a TCP sequence number guessing vulnerability. The attacker cannot extract information or tamper data. In fact, he or she has no control over the target whatsoever. At worst he or she can be a nuisance by guessing sequence numbers and injecting RST packets and terminating TCP sessions early. There are other, simpler, attacks that are much more effective. Think about distributed SYN flood attacks.


Medium level vulnerabilities are a little more complicated, as they often depend on context. Take, for example, the sharing of NetBIOS shares with anonymous access. This is not normally something that you want exposed on the Internet, as it tends to lead to all sorts of (often successful) attacks against a system. On the inside of a network the story is different. Disabling access to NetBIOS shares will seriously interfere with your file server by making it unusable.


From a vendor point of view, High, Medium, and Low vulnerabilities can be over-simplified another way. High vulnerabilities are those for which the vendor ofttimes accepts that there is a problem and will proceed to issue a patch. On the other extreme are Low vulnerabilities which tend to be ignored by the vendors. Medium vulnerabilities find their special place again, as the vendor will usually not accept that there is a defect, but may well issue a Knowledge base article or some-such document suggesting alternative configurations.

Cost of a Fix

Having talked about the damage a vulnerability can do, let's take a quick look at cost.


In an ideal world all problems will get fixed. This being far from an ideal work world, all sorts of constraints come to play: a) writing the code or configuration change that will fix the core issue, b) deploying and installing the patch/change, and c) compatibility and quality assurance.


From a qualitative point of view we can argue that a Microsoft patch is relatively cheap. Writing the patch is done for you by Microsoft and generally provided free of charge, deployment can be done with any of a range of patch management tools, and quality assurance is also already done with regards to other Microsoft products. The only part that remains is really the compatibility testing with your environment.


By contrast consider some problem not acknowledged by the vendor where you have to do all that work, on the assumption that you have access to all the resources needed (availability and competence of staff) and the technology to develop and test, alongside production.


This article is trying lead you to the conclusion that High and Medium level vulnerabilities deserve your attention, whereas Low level issues don't.


We can therefore look at vulnerabilities this way:

Outline of the ROI of a Vulnerability Fix.png

This chart chart makes obvious what you will have guessed by now: High level vulnerabilities are low-cost/high-gain; whereas Low vulnerabilities are exactly the inverse: you will most likely incur a high cost for very little gain.


To wrap-up: let's look at two examples:


High: MS08-067, a.k.a. "the Conficker vulnerability". The damage is pretty high: there is code that propagates autonomously to run in administrator mode on an infected target. The cost, in turn, is pretty low: install the patch that Microsoft has issued. Granted, you will need to test the patch and make sure it doesn't break your system, but that can be overlooked, as we will see below.


Low: Weak Randomness when generating TCP sequence numbers. The damage, as discussed before, it pretty low. The solution on the other hand, is pretty costly. The vendor, in this case I'll take Microsoft, does not consider this an issue, so there is no fix. You are therefore on your own to fix the Windows TCP stack. I doubt you will get easy access to the source code, and even if you do, you have meddled with a key part of the Operating System: quality assurance testing will be pretty heavy. Or you redesign your network around filtering devices based on Operating Systems that do addressed this (BSD, for example). So now you have to fit a new network device into your architecture that intercepts traffic (the TCP connection needs to terminate there). I suspect you can see what I mean this this is expensive. Sole point in common: once the solution is deployed, doing Quality Assurance that all works - as you would had you simply installed a patch.