The Case for A Vulnerability Funnel

Utilizing a Vulnerability Funnel

In order to appropriately handle the volume of vulnerabilities, it is important to have in place techniques to prioritize which vulnerabilities are addressed first. One source is not enough. How can we build a funnel to focus the efforts of managing the vulnerability patching process? Before we get to that, let's level set what the vulnerability landscape has looked like so far in 2023.

As of 2023-10-01 according to CVEdetails there have been 21,213 vulnerabilities this year. We will take a look at the breakdown of these vulnerabilities in a few different lenses as we touch on the various methodologies below.

Here we can see the volume of vulnerabilities per month for 2023:

Let's take a look at some of the methodologies out there and their strengths and weaknesses.

CVSS - Common Vulnerability Scoring System

A brief history on CVSS: CVSS v1 came out in 2003/2004, v2 in 2007, v3 in 2015 and v3.1 in 2019. The latest iteration, v4, was released in 2023-06.

Newer is better, right...?

If you were using CVSS v2 to perform your vulnerability prioritization, when v3 came out you would have overnight been targeting completely different vulnerabilities due to changes in the scoring utilized.

Selecting a random CVE, CVE-2022-22321, which had a v2 score of 2.1, following the implementation of v3.x this vulnerability now rates as a 5.5 and while this would still not be a high priority CVE to target for remediation, this shows that there could be a rather large difference in scoring when nothing about the vulnerability itself changed.

Of note, the major difference between v2 and v3 was the addition/modification of the Severity Scale:

Cisco found that the average score changed from 6.5 in CVSSv2 to 7.4 in CVSSv3 - shifting the average from medium to high severity. In Cisco's analysis between CVSSv2 and CVSSv3, they noted that of the 3,862 vulnerabilities which they used to compare the two scorings 227 of them went from Low to Medium, 846 went from Medium to High, and 187 went from High to Critical. Of note, 472 of the Critical vulnerabilities were lowered to high and 59 were lowered from High to Medium in the change to CVSSv3.

With most organizations' prioritizations being to patch all High/Critical, the lowering of those Critical -> High vulnerabilities doesn't do anything to narrow the focus as the differential from the vulnerabilities which saw an increase in score adds an additional 787 vulnerabilities (20% of the study) to the workload and would merely constiute a reprioritization of effort.

Based on the data provided by CVEdetails, there have been 21,211 vulnerabilities from 2023-01-01 to 2023-10-01, with 17.5% of these being Critical severity and 39.8% of them being High severity. That means your vulnerability management focusing on patching all High/Critical vulnerabilities would have to handle 12,166 vulnerabilities in the first 9 months of 2023 or 44.56 vulnerabilities per day (including weekends) or 56.32 vulnerabilities per day (excluding weekends).

Thankfully not every organization is running every piece of software out there so these numbers could be decreased substantially by focusing on only your vendors utilized.

For example, let's say we have a very simple software stack of Microsoft for OS and applications with users who use Chrome and users who use Firefox and our network stack is Cisco.

• Date Range 2023-01-01 to 2023-10-01:
• Source: CVEdetails

By limiting to vulnerabilities in-line with our software stack, we were able to reduce the total High/Critical vulnerabilities from 12,166 in the first 9 months to 881 bringing our vulnerabilities per day from 44.56 (including weekends) or 56.32 (excluding weekends) down to 3.23 (including weekends) or 4.08 (excluding weekends).

The biggest requirement here is ensuring you have your software/hardware inventory documented accurately and automatically updating as changes and modifications are made.

As your environment changes, so too will your risks. Of note, none of the above results have yet taken CVSSv4 into account as the methodology is still fairly young and not yet implemented across the large majority of sources.

EPSS - Exploit Prediction Scoring System

EPSS v1 was released by Forum of Incident Response and Security Teams (FIRST) in 2021 and focuses on pre-threat modeling to give you the probability of a vulnerability being exploited. FIRST has stated that "EPSS is not, and should not be treated as a complete picture of risk" but should be used as another input in the risk analysis process.

EPSS since its initial release in 2021 has come out with v2 in 2022 and v3 in 2023 - showing very active development. One thing to keep in mind is that because of the way that EPSS works, it could have vastly different scores from one day to the next even without a change in version. EPSS is not meant to give you a severity and is only assessing the likelihood of exploitation based on a variety of factors including things like the complexity of the attack, likelihood of discovery, potential impact of a successful attack, and the current threat landscape.

EPSS takes all published CVEs and provides an output between 0 and 1, which is the likelihood that the vulnerability will be exploited in the next 30 days. Of note, EPSS has both a probability and a percentile score. The probability score is what references a base output for the vulnerability and only changes as information surrounding that vulnerability changes. The percentile score can change when any other vulnerability score changes. As such, I will be referencing the probability score for all below mentions. To put this another way, as stated by FIRST: "EPSS probabilities convey a global, or overall, sense of the threat of exploitation, while percentiles provide a relative, or localized, measure of threat."

For example, using CVE-2023-29357, an issue affecting Microsoft Sharepoint Server 2019: On 2023-09-27 the EPSS score was changed to 0.27% and on 2023-10-01 the EPSS score changed to 78.87%, meaning that there is a 78.87% probability that this vulnerability will be exploited in the next 30 days.

Layering EPSS and CVSS together can give us a vulnerability funnel which can allow us to prioritize based on severity and probability of exploitation.

So without even needing to ensure accurate/updated inventory lists, you could combine an approach to capture any vulnerabilities rated High/Critical severity giving us our 12,166 vulnerabilities and then filter them through EPSS to provide a targeted list of vulnerabilities for remediation.

A snapshot from FIRST showing top CVEs last 30 days by EPSS. Notable inclusions are:

• CVE-2023-36761: Microsoft Word Information Disclosure Vulnerability
• CVE-2023-4863: Vulnerability in libwebp
• CVE-2023-42793: Authentication Bypass in JetBrains TeamCity
• CVE-2023-38205: Adobe ColdFusion Improper Access Control

CISA KEV

Next up is CISA KEV. Cybersecurity and Infrastructure Security Agency (CISA) has a list known as the KEV (Known Exploited Vulnerabilities). This list, while not a complete picture of all known exploited vulnerabilities, hosts a large majority of the known exploited vulnerabilities and can be a good reference. Started in 2021, CISA KEV came about as part of Binding Operational Directive (BOD) 22-01. It just recently passed 1,000 vulnerabilities in the list and seems to have stabilized following immense initial additions to the list to catch up.

CISA KEV has a set of 3 criteria for vulnerabilities to be added:

1. It must be assigned a CVE ID
2. It must be actively exploited (includes attempted exploitation but does not include scanning, security research, or PoCs)
3. It must have clear remediation guidance for the affected organization to take

In the first 9 months of 2023, there were 144 vulnerabilities added to the CISA KEV with a mean CVSS of 8.2 and a mean EPSS score of 33.9% (79th percentile)¹ with a median CVSS of 8.6 and a median EPSS score of 3.5% (90th percentile).

Benefits of the KEV include actionable intel, deadlines for patching, and knowing that you are targeting important vulnerabilities - HOWEVER - as you are targeting actively exploited vulnerabilities, you are at higher risk of not patching a vulnerability prior to exploitation in your environment.

SSVC - Stakeholder-Specific Vulnerability Categorization

SSVC was released by Cernegie Mellon University's Software Engineering Institute (SEI) in collaboration with CISA in 2019. In 2020, CISA worked with SEI to develop an SSVC decision tree to examine vulnerabilities relevant to the US Government, as well as state/local/tribal/territorial (SLTT) governments, and critical infrastructure entities. The SSVC decision tree has you answering 4 questions to determine activity performed.

SSVC Questions and Sub-Categories:

1. Exploitation?
   • None
   • PoC
   • Active
2. Automatable?
   • Yes
   • No
3. Technical Impact?
   • Partial
   • Total
4. Mission & Well-Being?
   • Low
   • Medium
   • High

Based on responses to the above questions, you will be given a priority in the form of one of the following statuses:

• Track
  • The vulnerability does not require action at this time. The organization would continue to track the vulnerability and reassess it if new information becomes available. CISA recommends remediating Track vulnerabilities within standard update timelines.
• Track*
  • The vulnerability contains specific characteristics that may require closer monitoring for changes. CISA recommends remediating Track* vulnerabilities within standard update timelines.
• Attend
  • The vulnerability requires attention from the organization's internal, supervisory-level individuals. Necessary actions may include requesting assistance or information about the vulnerability and may involve publishing a notification, either internally and/or externally, about the vulnerability. CISA recommends remediating Attend vulnerabilities sooner than standard update timelines.
• Act
  • The vulnerability requires attention from the organization's internal, supervisory-level and leadership-level individuals. Necessary actions include requesting assistance or information about the vulnerability, as well as publishing a notification either internally and/or externally. Typically, internal groups would meet to determine the overall response and then execute agreed upon actions. CISA recommends remediating Act vulnerabilities as soon as possible.

Further information on SSVC can be found in the CISA Stakeholder-Specific Vulnerability Categorization Guide

One benefit which comes to mind for SSVC is that it is something which would be simple to implement into a ticketing system, however on the flip side, there is a bit of manual work which needs to be done on every vulnerability that comes in so you would want to combine this with something like the XBOMs (yes, I think I just made that up) you are using to track software/hardware exposure risk in your organization or passing it through another filter prior to limit the manual work required.

Conclusion

In conclusion, there are a variety of methodologies out there and combining them into a picture that works for your organization is unique to each organization based on risk acceptance and availability of staffing and solutions.