I am starting my new research project for Q4 2011 (stepping briefly away from PCI DSS compliance): on vulnerability management. As I am going through existing Gartner coverage of the matter (tools, practices) as well as recent customer calls on the subject, one interesting theme emerges: vulnerability prioritization for remediation presents THE critical problem to many organizations operating the scanning tools. The volume of data from enterprise scanning for vulnerabilities and configuration weaknesses is growing due to both additional network segments and new assets types.
In order to cut through the noise and hype around this issue, I have created a structured approach for analyzing the prioritization approaches observed in practice (sometimes these are also called “risk scoring” by the tool providers). Specifically, I have cut every dimension of the prioritization decision making into a separate row in the table below.
Note that some of the methods are more likely to be used in combination with others and not standalone. For example, you can first choose to fix vulnerabilities with CVSS base score > 8 in US DMZ (thus combining 3 of the method from the table: CVSS base score – 8, asset physical location – US, asset network location – DMZ). Or you can fix only issues which are High or Medium on the assets from the specific list of “key” assets, but only High on others (thus combining the good old H/M/L with a specific asset list).
Here is what I came up with – any comments, additions, related ideas, feedback?
Please also see my call to action below the table!
|Method label||Prioritization Method details|
|Asset list||List of select assets where vulnerabilities get fixed|
|Asset network location||Asset location on the network, segment; internal/external|
|Asset physical location||Asset location in country, city, corp location, etc|
|Asset role||Business role of an asset|
|Asset value||Assigned or computed business value of an asset; BC/DR asset scores|
|Compliance||Organization-wide compliance or asset compliance; regulatory/internal|
|Countermeasures||Delay fixing vulnerabilities on more protected networks|
|CVSS environmental scores||Site-specific CVSS environmental scores|
|CVSS score||CVSS base and (sometimes) temporal scores|
|CVSS vector||CVSS vector components such as access, exploit etc in addition to a score|
|Ease of fixing||Ease of fixing of vulnerability|
|Exploitability||Check vulnerability exploitability in the real world|
|Network topology||Model vulnerabilities across networks with ACL and network topology; use flow information|
|Threat-based||Count attacks on assets or exploits observed|
|Vulnerability popularity||Number of vulnerable assets fixable with a single patch|
|Vulnerability type||Vulnerability type such as overflow, SQLi, XSS, etc|
So, here is my call to action!
To vendors: please point me to (or send me) your resources where you describe your prioritization algorithms, if any. If you still expect your customers to use only High/Medium/Low for prioritization, please don’t contact me
To tool users: please let me know (through whatever means) how you are prioritizing what to fix – at the very least, tell me what methods from the above table you use and in what combinations.
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.