How to do Vulnerability Prioritization

Working through all of the details that go into choosing what to fix and when

If you’re overwhelmed by thousands of vulnerabilities across thousands of systems, you’re not alone. This article will cover exactly what factors to consider when trying to prioritize what needs to get fixed.

My first time embarking into the CVE nightmare zone, my CISO asked for a list of “all the highs and criticals, and when they’ll be fixed.” This mentality is still widespread, and is at its core correct - we want to find all our high risk items, and get them fixed as soon as possible. However, over the ensuing years, I’ve realized the complexity of fulfilling that simple request - knowing what’s actually important to get fixed. Cloud workloads have only exacerbated the complexity of this simple challenge.

Vulnerability Management is something that sounds simple - I often say it’s really just project management and data engineering; however, the simple premise often manifests itself in a series of lambda functions manipulating excel spreadsheets that sprawl across the entire organization. This creates a sprawling data architecture that’s impossible to keep up with, and really not a good use of anyone’s time.

The root of this problem is that, despite ambitious practitioners like myself not wanting to believe it, there is no single employee that has all of the necessary skills to get vulnerability prioritization done.

1. Compliance typically understands the timelines and evidence expectations depending on the audit framework. 

2. Security engineers understand the application and infrastructure context of the vulnerability. 

3. Security researchers understand how to exploit the vulnerability, and the complexity of disclosures and scoring systems

4. Threat intel teams understand how to hunt for exploitation data

5. Data engineers understand how to build scalable complex data architectures for managing large numbers of vulnerabilities.

In this article we’ll start unraveling some of those difficulties by focusing only on the numerous signals that go into vulnerability. Most of this prioritization methodology will be based on how Opus Security combines multiple vulnerability intelligence indicators into a single intelligence score to help prioritize across multiple tools.

Opus Prioritization Methods

Things that Go into Prioritization

Base Score:

1. Severity from base sensor

Unfortunately, most organizations are totally reliant on their sensor’s base score for prioritization. However, even in the most stringent of FedRAMP environments, you’re able to show auditors risk adjustments to better account for environmental context. 

Anyone who’s used base CVSS scores for prioritization is aware of just how unreliable the metric is for judging the actual priority of fixing a vulnerability. I also don’t blame this on the scoring system - CVSS needs to be scored based on the worst case scenario in order to try and accurately judge the impact of a vulnerability. If they adjusted scores based on a “how many people use this package this way,” it would be seriously misleading to organizations actually impacted, even if it’s very low.

What you’re supposed to use to adjust vulnerability scores

In order to try and account for environmental context, CVSS offers temporal and environmental score adjustments for CVSS. The problem? This is not at all scalable. In prior roles, I experimented with using LLMs to fill this out, environmental contexts, all sorts of things, but it never quite worked correctly. 

This means that in 2024, the vast majority of companies are totally wasting their time when it comes to vulnerability management. There’s no contextual prioritization - either based on their environment, or on intelligence on the vulnerability itself. It’s clear that more advanced data is needed to prioritize, data that it’s almost impossible to get yourself.

Vulnerability Intelligence:

In this section we’ll dive into Opus Security’s intelligence breakdown, which I find to be a thorough enumeration of the kinds of vulnerability intelligence that exist out there. Intelligence is based on three categories:

1. Exploit Status

   1. How available and known is it how to exploit this vulnerability?

   2. This increases the likelihood that a vulnerability will be exploited 

2. Threats

   1. How weaponized has this vulnerability been in known attacks?

   2. This increases the likelihood that a vulnerability will be exploited, and it’s weaponization suggests that it’s a commonly susceptible configuration

3. Patches

   1. Is there anything I can do to fix this?

   2. If you can’t fix something, it’s not worth prioritizing because there’s nothing to be done until a fix is available! This data is also helpful for tracking time to fix, and creating fix campaigns.

Let’s take a minute to break down what exactly these categories mean, and what sources of intel are useful for filling it out.

Exploit Status

The availability of exploits is key information for determining the likelihood or plausibility of an attack. While a CVE may be technically exploitable, there is a big difference between needing a dedicated attacker to craft a specific exploit for your environment, versus if they’re one Google search away from an exploit. When new exploits arise, there are at least four phases to their adoption within attacker toolkits:

Exploit discussions on open forums

First, discussion around a PoC typically exists either on GitHub or on attacker forums. The amount of discussion is a good early indicator of how “hot” a vulnerability might become for exploitation.

Proof of Concept code on GitHub

Second, a proof of concept is published, usually in GitHub repos. In worst case scenarios, this will be easily copy pasteable code to allow a user of any skill level to exploit a vulnerability. This where vulnerability exploits become the most widely attempted, as a PoC is available.

Exploit a part of a common framework or toolkit

Third, an exploit might be included into a common pentester framework or toolkit. This indicates that a package is so widely used that it’s worth incorporating into common testing. Adoption into a pentester framework indicates that both the package is widely used in a particular configuration, and that exploits are mature enough to be automated.

KEV indicating known exploits

Finally, in the wild comes from CISA KEV and indicates that known attacks and exploits have been carried out against the vulnerable package. 

Threats:

While exploits give attackers the ability to more easily launch attacks, threats are how weaponized the exploits have become. This section has at least four statuses to indicate how widespread an attack may be, or if there are certain attack types that most likely correspond to the exploit.

Used as known malware

First, malware indicates that the vulnerability has been widely distributed in the form of malicious software.

Specific Exploits

Second, exploits refer back to if proof of concepts have been weaponized into known exploitations in specific systems.

Third, threat actors are specific groups of attackers that are known to have weaponized the vulnerability.

Fourth, ransomware indicates that the vulnerability has been observed as part of ransomware campaigns

Patches

Whether or not a patch is available is a key component of vulnerability tracking, especially for regulative standards like FedRAMP. There is a category for this called “vendor dependencies” wherein you’re tracking all of your vulnerabilities without a patch yet available, with the stipulation that you will follow your normal vulnerability timelines upon publishing a patch.

While this may seem like a minor problem, tracking the ongoing statuses of patch availability, especially for your specific Linux Distro or open source library is an extremely time consuming process.

Environmental:

Now that we have a good understanding of the vulnerability itself, namely its likelihood to be exploited, and how well known it is, we can begin considering the risk within our environment itself. There are many categories you could consider here, but here’s a subset:

1. Service Criticality

   1. Typically an understanding of the kind of data being processed combined with the role the service plays in your overall business functioning.

2. Environment Type

   1. Usually split between test, development, staging, and production

3. Compliance Requirements

   1. For large organizations, different products might be audited to different standards with different remediation standards

4. External Facing

   1. An application being internet facing means that it’s the most open for attack

5. Sensitive Data

   1. Typically we’re worried about protecting data that attackers are interested in!

6. Mitigating controls

   1. If a control, like EDR or WAF, is actively mitigating a known threat, then it’s less urgent to patch it.

What I like about modern vulnerability platforms is their ability to try and make some of this environmental prioritization attainable for businesses. In my experience, this data always comes up once you’re in a meeting with development and suddenly you watch your high priority vulnerability plummet to the bottom of the prioritization list.

By combining all of these factors, some manual and some contextual, you’re able to create a scalable prioritization version of the CVSS environmental scores. In most environments I’ve seen, these environmental adjustments are almost never used because of the complexity of scaling it across 1,000’s of workloads and even more vulnerabilities. 

Checking other tools for mitigating controls on assets is an emerging feature of vulnerability management platforms as a way to de-prioritize large categories of findings that known preventions like IDS/IPS or EDR would catch and prevent.

Putting it all Together

Turning the telemetry into a single risk score

The goal of this post was twofold:

1. Show that your vulnerability prioritization program should go way beyond CVSS score. If you’re struggling to prioritize based only on CVSS, you’re not doing anything wrong, it just doesn’t make much sense. 

2. Demonstrate why having a platform to do all of this is worth the money. I’ve tried to script this all out a few times, believe me when I say I wish we had just bought a tool to do it for me.

Even if your vulnerability scripts are working well, there is so much telemetry that’s out there that’s unrealistic for most teams to access and manage themselves. This post was done in collaboration with Opus Security because they have a strong intelligence engine for prioritization, but the time savings are massive for investing in any tool in this category.

Your business will also have weird edge cases, so evaluate the customization of the various platforms. Whether in the ability to appease auditors with different risk weightings, getting data into other platforms, or ingesting other telemetry, these details will go a long way to make sure the tool fits your needs in the long run.

This post is meant to be educational and was completed in collaboration with the team at Opus Security. This is not meant to be a product endorsement or review.