One of the challenges of working in vulnerability management for a federal agency is that you spend a considerable amount of time worrying about the risk of being blindsided by an update from CISA’s Known Exploited Vulnerabilities (KEV) catalog.
What if there was a way to anticipate the things most likely to end up in the CISA KEV catalog and already have a plan in motion or, better yet, complete for when new vulnerabilities are added?
Here are three ways to predict items that are likely candidates to make it onto the CISA KEV list:
Use threat intelligence
A good threat intelligence feed is an excellent way to identify vulnerabilities that are likely to end up on the CISA KEV list. If a threat intelligence provider has identified a vulnerability as being problematic and makes a compelling argument for why they have rated it high or critical, it stands to reason that same vulnerability will get CISA’s attention as well.
To identify high probability candidates, look for CVEs that that your threat intelligence feed rates as high or critical. In most cases, fewer than 2 percent of vulnerabilities should meet these criteria, but that will vary depending on the feed. In one anonymized sample scan data, 62 vulnerabilities were found that met these criteria compared with 1,472 vulnerabilities in the same data set that had a CVSS score of seven or higher.
Use EPSS (Exploit Predictive Scoring System)
EPSS is a model that uses machine learning to try to predict the likelihood of a vulnerability becoming exploited, based on the similarities it shares with known exploitable vulnerabilities. This is an ideal companion to the CISA KEV list because it tells you on a percentage basis how similar any given CVE is to the rest of those listed on CISA KEV. EPSS outperforms the 90/10 rule, which suggests 10% of the population represents 90% of your problem.
At the time of this writing, some 200,000 CVEs exist. Only six percent (or about 12,000) have an EPSS score higher than 0.1, which indicates a 10% likelihood of becoming widely exploited. In the sample dataset, 233 vulnerabilities out of 2,700 that were not listed on CISA KEV and had an EPSS score over 0.1 were found.
When it comes to your environment, you want to set the threshold low enough to catch things that threat intelligence didn’t already flag, but not so low that it matches everything.
Use other exploitation data
Finally, you can use other sources of exploitation data to better predict if a vulnerability will end up in the CISA KEV database. Some threat intelligence feeds have their own list of exploited vulnerabilities, and most vulnerability scanners have a flag stating whether an exploit exists for the vulnerability or not.
The difference here is whether their exploit data is tracking exploitable vulnerabilities or exploited vulnerabilities – with the former having the exposure to be exploited, and the latter having already been actively exploited. This differentiator is important.
Thousands of exploits exist that, for whatever reason, nobody uses. One common reason is that sometimes the exploit will work, and other times it might crash the system. Threat feeds tend to be more aggressive about filtering out obscure exploits, while scanners tend to report any existing exploit.
A layered approach
The best way to get ahead of potential known exploited vulnerabilities is to employ all three of the approaches listed above, as they complement each other rather than replace one another. Here’s a prioritization method that would work well based on the data we observed, with longer due dates the further they are down the list:
1. Vulnerabilities on the CISA KEV list
2. Exploitable according to threat intelligence, but not on the CISA KEV list
3. Critical or high risk according to threat intelligence, but not on the CISA KEV list
4. EPSS score higher than 0.1, but not on the CISA KEV list
5. Exploitable according to your vulnerability scanner, but not on the CISA KEV list
When it comes to any remaining backlog, testing and deploying the current month’s updates and being sure to clear any pending restarts does a surprisingly good job of keeping the backlog from growing and even reducing it. Overall following this approach positions you to be able to report CISA KEV vulnerabilities as already fixed, rather than having to give an ETA.
David Farquhar is a Solutions Architect at Nucleus Security, a supplier of Risk Based Vulnerability Management products and services.
Have an Opinion?
This article is an Op-Ed and the opinions expressed are those of the authors. If you would like to respond, or have an editorial of your own you would like to submit, please email C4ISRNET Senior Managing Editor Cary O’Reilly.
