A Clean View of Vulnerabilities Helps Prioritize Patching

The importance of prioritization

Prioritization is arguably the most consequential, time-sensitive, and challenging aspect of vulnerability management.

And it’s easy to see why: Hundreds of new vulnerabilities are reported every month. Patching them all is rarely feasible, so instead, security teams must quickly figure out which need mitigation, and in what order, to minimize risk for their organizations.

But the tricky thing about minimizing the risk a vulnerability poses to your specific organization is that there isn’t exactly an easy or foolproof way to evaluate the variables that contribute to it. These variables include:

• How likely the vulnerability is to be exploited in the wild

• If the vulnerability is exploited in the wild, how likely it is to impact your organization

• If the vulnerability is exploited at your organization, what impact it is likely to have

Going beyond CVSS

Further complicating matters is the widespread misconception that Common Vulnerability Scoring System (CVSS) scores fully encompass risk. A CVSS score is attached to each Common Vulnerabilities and Exposures (CVE) identifier that MITRE assigns to a vulnerability, but this score reflects severity — not risk. Although they are two different things, severity and risk are often conflated in this context. One reason is the variables that contribute to risk are similar to those used to formulate CVSS severity scores. Those include:

• How easily the vulnerability could be exploited in the wild

• If the vulnerability is exploited in the wild, how it is likely to impact the confidentiality, integrity, and availability of information on or connected to the system where the vulnerability is present

The difference between both sets of variables, though seemingly subtle, raises a crucial point: Risk is simply how severity manifests within a specific environment. In other words, just because a CVSS score indicates a CVE could easily be exploited in the wild doesn’t mean it will be. And even if that CVE is exploited, and confidentiality, integrity, or availability of some of an organization’s information is compromised as a result—the security community, as outsiders, still know far too little to be able to assess the risk that CVE posed to, and the impact it had on, that organization.

The best of both worlds

So where does this leave us with respect to patch prioritization? There still isn’t a universally accepted or foolproof way to evaluate—much less prioritize mitigation based on—the risk posed by a CVE. But it’s also far from impossible. Alleviating some of the challenges and uncertainties inherent to these tasks is largely what motivated us to create the Flashpoint CVE Dashboard.

One of the dashboard’s top use cases is helping security teams better understand how likely a CVE is to be exploited. It does this by mapping the latest CVE data from MITRE and the NVD to threat actors’ discussions about those vulnerabilities in illicit online communities in near real-time. Our team has consistently found that the more frequently a CVE is mentioned in these communities, the more likely it is to be exploited regardless of CVSS Score. 

And these findings aren’t unique to our team and aren’t just anecdotal. A 2014 study concluded that “fixing a vulnerability just because it was assigned a high CVSS score is equivalent to randomly picking vulnerabilities to fix.” It also found that while a CVE’s CVSS score does not appear to correlate with its likelihood of being exploited, these factors do:

• The existence of proof-of-concept (POC) exploit code for the CVE

• Mentions of the CVE in illicit online communities 

The results of this study shouldn’t be too surprising because most vulnerabilities, regardless of their CVSS score, are never exploited in the wild. But in order to exploit a vulnerability, threat actors must first determine how—and this often requires POC code. Using or developing POC code can entail ample trial-and-error, which for many threat actors leads to discussions with peers in the illicit online communities they frequent. 

Few security teams, however, have the expertise and resources needed to access these discussions and understand the context in which they take place. With this in mind, we designed the Flashpoint CVE dashboard to make all of the relevant information—including the latest CVE data, potential or confirmed exploits for those CVEs, the specific threads and communities in which those CVEs are discussed, and finished intelligence reporting on these and related topics—accessible in a single-pane, customizable view.

This customizability plays a big role in another use case for the Flashpoint CVE Dashboard: providing greater visibility into which vulnerabilities, if exploited, are most likely to impact an organization and how. As I mentioned, with so many new vulnerabilities identified each month, determining which are most important to your organization can be a tedious, arduous process. But by enabling security teams to customize their view of these vulnerabilities and all related information by type, vendor, product, date, severity, and status, the dashboard filters out unnecessary noise. As a result, security teams can more easily and quickly identify and focus on the vulnerabilities present within critical systems or that could compromise critical assets at their organization.