Vulnerability Management is Hard! Using CVSS and other scoring to prioritize patching

I spent 10 years learning and building a robust vulnerability management program at a large financial institution. Like most things in information security, it’s a process, not a mountain you climb once.

At a high level, your organization should be patching at the same pace that the vendor releases patches. For example, Microsoft has patch Tuesday on the second Tuesday of every month. By the time the second Tuesday of the month comes, you should be fully patched with the patches released the previous month. Oracle does it quarterly. While this goal was always “impossible”, we slowly moved from 180+ days for patching to under 30 days in an organization with over 1 million internal hosts. It can be done!

Vulnerability prioritization focuses on the real, urgent vulnerabilities that need to be patched at a much faster timeline than the "business as usual". This post covers various methods to determine which of those vulnerabilities fall into this category of "patch now":

• Common Vulnerability Scoring System
• Exploit Predictability Scoring System
• AttackerKB
• Other vendor scoring systems

Common Vulnerability Scoring System (CVSS)

CVSS (Full Disclosure: I was a working group, voting member of CVSS v3.0 and v3.1) is the industry standard for scoring vulnerabilities. The CVSS base score is calculated when submitting a new CVE (common vulnerabilities and exposures). CVEs are generally created by the affected vendor and assigned a CVSS base score by the vendor releasing the patch. Most of the time, the CVE, CVSS, and patch are all released at the same time. 

As the name suggests, CVSS is a scoring system, not a risk rating system. Consumers of CVE and CVSS are supposed to calculate the temporal and environmental scores of each vulnerability to have a better metric for which patches to prioritize. The base score on it's own will result in many high and critical risk vulnerabilities and not reflect your organization’s contextual risk. The environmental score is a modifier for your unique environment depending on the importance of the affected asset. This is the problem new projects are trying to solve but I personally do not see an easy button to understanding contextual, business risk of vulnerabilities for prioritization.

One of the underlying considerations for prioritizing which patches to apply is exploitability (can a threat take meaningful advantage of the vulnerability) which is covered in CVSS temporal score under Exploit Code Maturity. The temporal score looks at three metrics:

• Exploit Code Maturity (E) - measures the likelihood of the vulnerability being attacked, and is typically based on the current state of exploit techniques, exploit code availability, or active, “in-the-wild” exploitation.
• Remediation Level (RL) - is there an official patch, workaround, temporary fix, or are none available.
• Report Confidence (RC) - is there a confirmed report or functional reproduction, is it reasonable, or is it unknown.

While CVSS is used to score vulnerabilities that have CVE, the MITRE site does not provide the CVSS score. Instead, I recommend using the National Vulnerability Database which has both the CVE and the CVSS. It also has some analytics and more information about certain vulnerabilities.

Exploit Prediction Scoring System

Many vendors have applied other fields when they release patches that help defenders prioritize if the vulnerability is exploitable:

• Actively exploited in the wild - this means the vendor is aware this vulnerability is already being exploited and hence should be prioritized
• Disclosed by a third party - this means a third party has disclosed the vulnerability to the vendor. While this may not imply that it is exploitable, if a third party found it, there is a high chance another third party will too and may exploit it.

The Exploit Prediction Scoring System (EPSS) began as research presented at Blackhat 2019 and is now an official FIRST working group. EPSS is different from CVSS in that it is an effort for predicting when vulnerabilities will be exploited. By knowing what vulnerabilities have a higher chance of being exploited, consumers can better prioritize which vulnerabilities to remediate. 

AttackerKB

Rapid7, a vulnerability management company, has a community project called AttackerKB which brings crowd-sourced feedback to help consumers figure out which vulnerabilities to prioritize (FD: I participated in the private beta). In this portal, the security analyst can provide ratings and analysis based on two metrics:

• Attacker Value - between low and high
• Exploitability - between difficult and easy

Based on those metrics, the analyst can then choose and tag why the vulnerability is of high or low value to an attacker. Analysts also have the ability to confirm that the vulnerability is actively exploited in the wild. For an example, check out my technical analysis of SMBGhost.

Other Vendor Scoring Systems

Many vulnerability management vendors  have their own prioritization framework or scording as part of their vulnerability scanning/management products however it requires the consumer to use the product to have a third or even forth score to consider:

• Rapid7’s insightVM Real Risk Prioritization
• Tenable Vulnerability Priority Rating

Best Practices

Every organization is different. Identifying, quantifying, and prioritizing the vast number of vulnerabilities in your environment is hard. 

• Pick a scoring system and stick to it
• Calculate temporal and environmental scores in CVSS
• Be consistent but have room to make exceptions (Heartbleed is a great example)
• Prioritize based on actual risk
• Consider exploitability either by calculating temporal score in CVSS or using EPSS

Conclusion

Organizations should be patching at the same pace the affected vendors are releasing patches. Prioritization should be done for vulnerabilities that require more urgency and that is the ultimate goal of vulnerability management, to identify and resolve the most critical vulnerabilities facing your organization. Organizations can prioritize by calculating CVSS temporal and environmental score and/or leveraging some of the newer projects for vulnerability prioritization covered in this post. I leave you with one of my favorite quotes: “if everything is a priority, nothing is.”

‍

About SCYTHE

SCYTHE provides an advanced attack emulation platform for the enterprise and cybersecurity consulting market. The SCYTHE platform enables Red, Blue, and Purple teams to build and emulate real-world adversarial campaigns in a matter of minutes. Customers are in turn enabled to validate the risk posture and exposure of their business and employees and the performance of enterprise security teams and existing security solutions. Based in Arlington, VA, the company is privately held and is funded by Gula Tech Adventures, Paladin Capital, Evolution Equity, and private industry investors.

‍