What’s Missing in Your Vulnerability Management Strategy? Exploring CVSS, EPSS, KEV, and Beyond.

Which vulnerabilities are crucial for your organization, and how do you prioritize them? As we use more technology, finding and fixing these vulnerabilities is not just about being tech-savvy. It’s about having a clear plan, collecting the right information, and understanding their impact on the business. In this article, we’ll talk about adjusting our vulnerability management process so it does not become a headache for the cybersecurity team and other departments.

Without a doubt, vulnerability management is a crucial aspect of cybersecurity and is essential for mitigating risks. Yet, many companies struggle with it, finding it a consistent challenge. Though this task is key for security, companies often delegate it to less experienced staff due to its repetitive and time-consuming nature. However, the reality is undeniably different: effective vulnerability management is complex and requires expertise. The person responsible for this role should have a comprehensive understanding of the existing architecture and a deep knowledge of how vulnerabilities work. Only with expertise in both domains can one accurately estimate the risk of each vulnerability within a given environment.

Lacking this knowledge may lead, on the one hand, to overemphasizing vulnerabilities that won’t have a real impact or are not likely to be exploited, thereby wasting resources and potentially causing other departments not to trust the cybersecurity department. For instance, if teams are frequently alerted about ‘critical’ vulnerabilities, pressing them to stop their tasks to address these, they might eventually become desensitized. Therefore, when a genuinely severe vulnerability appears, it may not receive the urgency and attention it deserves. On the other hand, some vulnerabilities might be ignored as, in theory, they do not look critical, even if they can cause significant harm to our environment. Both scenarios emphasize the importance of proper vulnerability management.

Let’s examine the elements that will improve your vulnerability management process to avoid overlooking vulnerabilities or escalating incorrect ones. We will need a proper patch management process to keep the software updated on an established frequency and a vulnerability detection and prioritization system that activates a special procedure for vulnerabilities requiring urgent fixes beyond standard patch management.

Patch Management

Though it may seem separate from vulnerability management, patch management is essential for a successful vulnerability management program. It’s vital not just to define how critical vulnerabilities will be reported and patched but, more importantly, to identify all assets and establish a process to keep software up-to-date. Teams must designate resources to maintain their software up to date rather than merely responding to alerts from the cybersecurity team. And as these resources cost money, deciding on the frequency of updates is essential. Teams should evaluate the update frequency, considering factors like update difficulty, software criticality, and the regularity of new versions.

Without a designated update cycle, at least two risks arise:

1. When a severe security vulnerability appears, the software might be multiple versions behind; because of this, it will be almost impossible to update without affecting the system or spending extensive hours adapting our code or configuration to the newer version. Regular updates would mitigate this issue, as our current version would be closer to the patch release.
2. The cybersecurity department will be the only one requesting updates, potentially causing friction between teams — especially if the latter hasn’t set aside time to address cybersecurity concerns.

With a proper patch management strategy, the cybersecurity team’s primary role will be ensuring compliance with the agreed-upon patching protocol and identifying vulnerabilities that need immediate attention. Ideally, such urgent vulnerabilities should be exceptions, not the norm.

The answer to how we ensure that only vulnerabilities that are really critical for the business are escalated is Vulnerability Prioritization.

Vulnerability Prioritization

The number of vulnerabilities reported each year continues to grow. In 2022, 25,059 CVEs were published, and the trend shows no signs of slowing down.

Figure 1. Published CVE Records trend — https://www.cve.org/About/Metrics

In the first quarter of 2023 alone, there’s already been a 16% increase.

Given this trend, an effective process to evaluate and prioritize vulnerabilities becomes crucial to ensure that only important vulnerabilities for our business are escalated. This process should take into consideration at least the following aspects.

Severity

Determine the severity of the vulnerability and, most importantly, its severity within our specific environment. This should include knowing the likelihood of exploitation and the impact.

Non-environment dependent

First, we can analyze the vulnerability without considering the environment using the CVSS, EPSS, and the KEV catalog.

CVSS: The Common Vulnerability Scoring System (CVSS) is a widely recognized — yet often misused — metric in vulnerability management. First defines the CVSS as " a way to capture the principal characteristics of a vulnerability and produce a numerical score reflecting its severity.” However, using the CVSS in isolation can be misleading. Data from CVEdetails.com reveals that over 50% of vulnerabilities have a CVE score of High or Critical (7+). If we base our vulnerability prioritization process on this measure alone, we might escalate over half of the reported vulnerabilities. Because of this, while CVSS offers a quick insight into a vulnerability’s potential severity, it shouldn’t be used in isolation.

EPSS: Introduced at Blackhat in 2019 and updated in March 2023, the Exploit Prediction Scoring System (EPSS) provides an estimate of the likelihood that a particular software vulnerability will be exploited in the wild within 30 days. As we can see in the data presented by First, it’s not just the high CVSS scores that attract attackers, so it’s essential to consider vulnerabilities with lower scores but a higher risk of exploitation.

Figure 2. EPSS score compared to CVSS Based Score data from First

It’s also worth noting that EPSS has limitations — it only covers vulnerabilities with a CVE ID and can produce false positives and negatives. Nonetheless, if we look at the data provided by First when comparing it with using only CVSS, we can see that EPSSv2 is more efficient and has more significant coverage of exploited vulnerabilities.

Figure 3. EPSS Comparision by Effort data by First

KEV: The CISA KEV (Known Exploited Vulnerabilities) Catalog, launched in November 2021, records vulnerabilities that have a CVE ID assigned, have been exploited, or are under active exploitation, and there is a clear action to take. Vulnerabilities featured in the KEV catalog require careful consideration and prioritization since adversaries actively exploit them.

Despite remediating vulnerabilities from KEV is not a waste of time as they are being exploited in the wild, the “Prioritization to Prediction Volume 9: Role of the known exploited vulnerability catalog in risk-based vulnerability management” report evidence that “94% of CVEs that have
exploitation activity aren’t on the KEV.” Showing that KEV should be only one of the data sources of information.

In summary, CVSS, EPSS, and CISA’s KEV are valuable data sources that, when used collectively, can help organizations understand both the likelihood and potential impact of exploitation.

To easily access these three data sources (CVSS, EPSS, and CISA’s KEV), consider using CVE_Prioritizer. The tool evaluates and ranks vulnerabilities based on their potential risk, resulting in five distinct priority levels:

Figure 4. Priority levels from CVE_Prioritizer

Figure 5. Example of the output of cve_prioritizer

Environment dependent

While CVSS, EPSS, and CISA KEV provide vital vulnerability data, they don’t involve specific environmental contexts. Understanding how a vulnerability impacts our environment is also vital. Thus, it’s crucial to confirm the following:

1. System Vulnerability: Confirm whether our system is genuinely at risk. This involves determining if we’re using the vulnerable component and if our configurations expose the component to potential threats. Sometimes a vulnerability can only be exploited if certain conditions are met, and we have to verify whether our scenario meets these conditions.
2. Reachability: Evaluate how easily an attacker might access the vulnerable component. For instance, a vulnerability in a system exposed to the internet differs significantly from one in an internal system protected by a firewall.
3. Actual Risk Assessment: Recognize whether the vulnerability genuinely poses a risk to our setup. Consider scenarios where the threat may not have tangible repercussions — for example, if exploiting a vulnerability requires administrative privileges, and it merely leads to privilege escalation, then its real-world impact could be negligible, as there’s little to gain for an attacker.

By deeply examining these parameters, we can better measure the real-world implications of any potential vulnerability.

Business context

Regarding the environment, the business context is essential. The business context involves examining how the potential exploitation of a vulnerability would affect the company’s operations and overall mission. Such an analysis provides insight into the ramifications on the system and the broader business operations. It’s crucial to give precedence to vulnerabilities that, when exploited, could have significant business repercussions. For instance, while a critical vulnerability might be detected, if it doesn’t pose a substantial threat to business operations, it might not be as urgent as another vulnerability with a slightly lower likelihood of exploitation but a more significant potential business impact. Take a Denial of Service (DoS) attack as an example: it could severely disrupt business operations if the targeted asset is crucial to the platform, but it might be less consequential if it only affects a tool used by a few employees.

Fix availability

Lastly, when prioritizing and escalating vulnerabilities to teams, we must ensure a fix or workaround is available. Escalating vulnerabilities without straightforward mitigation can lead to unnecessary distractions. We need to specify the version or workaround that addresses the vulnerability. Suppose a solution isn’t available for a particular vulnerability. In that case, we may need to either wait or develop custom mitigation based on its criticality, such as blocking traffic with the firewall or creating a blocking rule in the IPS (intrusion prevention system).

Conclusion

Effective vulnerability management isn’t just about recognizing threats but strategically prioritizing them in context. For this process to succeed, an effective patch management strategy is indispensable. Also, a robust vulnerability prioritization approach is needed. This approach can determine when actions beyond the standard patch management process are required by analyzing vulnerabilities, assessing their likelihood of exploitation, and estimating their impact.