.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
Combining EPSS and Reachability Analysis to Optimize Vulnerability Management
Exploit Prediction Scoring Systems (EPSS) is a data set that helps you understand the likelihood that a CVE will be exploited. Learn what the EPSS includes and how to use it to prioritize vulnerability remediation.
Exploit Prediction Scoring Systems (EPSS) is a data set that helps you understand the likelihood that a CVE will be exploited. Learn what the EPSS includes and how to use it to prioritize vulnerability remediation.
Exploit Prediction Scoring Systems (EPSS) is a data set that helps you understand the likelihood that a CVE will be exploited. Learn what the EPSS includes and how to use it to prioritize vulnerability remediation.
Exploit Prediction Scoring Systems (EPSS) is a data set that helps you understand the likelihood that a CVE will be exploited. Learn what the EPSS includes and how to use it to prioritize vulnerability remediation.
Exploit Prediction Scoring Systems (EPSS) is a data set that helps you understand the likelihood that a CVE will be exploited. Learn what the EPSS includes and how to use it to prioritize vulnerability remediation.
Past performance doesn’t guarantee future results.
At least when it comes to vulnerability management, though, you’ll want to pay attention to what issues have been - and are currently being - exploited in the wild. This key information, along with other factors, can help you predict the likelihood of future exploitations in your network.
The Exploit Prediction Scoring Systems (EPSS) lets you do just this.
In a previous post, we surveyed some of the available tools for vulnerability management, the EPSS among them. In this article, we are going deeper on it and also explore how to use the EPSS alongside a reachability analysis tool.
What is the EPSS?
The EPSS is a publicly- and freely-available data set that projects the likelihood of exploitation of all published Common Vulnerabilities and Exposures (CVEs). Hosted by the nonprofit Forum of Incident Response and Security Teams (FIRST), the EPSS is available for consumption both by downloadable spreadsheet and application programming interface (API).
The key output of the EPSS is a numerical value between 0 and 1 that predicts the likelihood of a given CVE’s exploitation in the next 30 days. Percentile scores are also available to give an idea of the relative exploitability of any given CVE.
No system is perfect, and we looked at some of the limitations of the EPSS in our previous post. But with that said, the EPSS can be an excellent part in the toolkit for organizations seeking to address the all-too-common problem of CVE overload.
Factors that drive the EPSS
According to the EPSS version 3 paper, released earlier this year, the model leverages a wide variety of data sources to drive its calculations.
Detected exploitation activity in the wild
Using predominantly signature- but also anomaly-based detection systems, the EPSS “collected 6.4 million exploitation observations…targeting 12,243 unique vulnerabilities.” This information comes from the commercial vendors Fortiguard, Alienvault, and GreyNoise along with the nonprofit Shadow Server Foundation.
The ability of the EPSS to draw on multiple sources of real-world exploitation data is one of its unique strengths and sets it apart from systems that don’t inherently draw from live data, like the Common Vulnerability Scoring System (CVSS) and Stakeholder-Specific Vulnerability Categorization (SSVC) approach.
Public mention of exploitation
Separately from its own data partners, the EPSS also looks for mentions of CVEs on prominent websites listing vulnerabilities exploited in the wild. These include:
- The Cybersecurity and Infrastructure Security Agency’s (CISA) Known Exploited Vulnerability (KEV) catalog
- Google’s Project Zero
- Trend Micro’s Zero Day Initiative (ZDI)
Publicly available exploit code
In addition to collecting live exploitation data, the EPSS also queries Exploit-DB, GitHub, and MetaSploit to determine if there is published exploit code for the CVE in question. While there is certainly some correlation between the availability of code allowing for automated use of a vulnerability and exploitation events themselves, the former does not necessarily guarantee the latter.
Open source security tools
Likely due to the fact that they are “double-edged swords” capable of use by both ethical and unethical hackers, open source security tools Intrigue, sn1per, jaeles, and nuclei are also queried by the EPSS to determine if they are capable of exploiting a given CVE.
Social media mentions
Because the “notoriety” of a given CVE can correlate with its likelihood of exploitation, the EPSS also pulls social media data from X (formerly Twitter). By looking at original Tweets over the past 7, 30, and 90 days, the EPSS can determine the level of chatter regarding a given issue.
References with labels
As with Tweets about a given CVE, the number of mentions of it on both the MITRE CVE List and National Vulnerability Database (NVD) can correlate with exploitation activity. Thus, the EPSS looks at vendor and third parties advisories, press coverage, and other external references in these two data repositories.
Keyword description of vulnerability
Using 147 different text tags in the MITRE CVE List, such as “remote attacker,” “code execution,” and “authenticated,” the EPSS is able to use heuristics to intuit the likelihood that an attacker can leverage a given CVE maliciously.
CVSS vectors
Pulling from the NVD directly, the EPSS uses CVSS v3 base metrics such as attack vector and privileges required as well as impact measurements (confidentiality, integrity and availability) to drive its calculations. Due to the fact that network-accessible vulnerabilities are generally much more likely to be exploited than ones requiring local access (all other things being equal), ingesting these metrics would seem to correlate well with exploitability.
Common Weakness Enumeration (CWE)
Similarly, the EPSS also relies on the CWE of a given CVE to predict future exploitation activity. For example, CWE-94, also known as “remote code execution,” is one such designation.
Vendor labels
Due to the differing levels of market penetration and thus prevalence in technology stacks, CVEs from different vendor products have different likelihoods of exploitation in the wild. Drawing from NVD data, the EPSS takes this reality into account.
Age of the vulnerability
Finally, the EPSS incorporates the number of days since a CVE was published on the MITRE CVE list. Since there is good evidence that recently disclosed CVEs are rapidly exploited, it makes sense to consider their age.
How EPSS can be used to prioritize vulnerabilities for remediation
A key advantage of the EPSS over existing vulnerability prioritization systems is that it leverages real-world malicious activity to predict the likelihood of a given CVE being exploited. Unlike CVSS, which gives an arbitrary exploitability score, the EPSS gives a probabilistic value for risk management calculations.
Additionally, if you were to use a purely EPSS-driven approach to make vulnerability remediation decisions, it would be much more efficient than if using a CVSS-driven one. To fix the same amount of vulnerabilities exploited in the wild, you would need to apply much less effort than when using a CVSS “fix all high and criticals” strategy.
Assuming you were to take such an approach, you would need to patch the majority of known issues (because most are high are critical). And in doing so, you will fix ~82% of exploitable CVEs.
Now, compare that to using the EPSS v3, using a threshold score of 0.088 (remediating all issues that score higher than this rating):
To achieve roughly the same outcome with EPSS, you will only need to resolve 7.3% of all known CVEs. This is only ~12.5% of the number necessary to fix when using CVSS.
And when you incorporate it with other techniques, like reachability analysis, it becomes even more powerful!
Combining the EPSS with reachability analysis
No security tool or approach is a silver bullet, and this is true for the EPSS. Primarily because it does not incorporate environment- or product-specific context into its analysis, the EPSS can benefit from integration with reachability analysis in several ways.
Prioritizing reachable issues
By analyzing call graphs it is possible to determine whether a given vulnerability is actually reachable by an attacker under realistic circumstances. This can often cut down on the number of findings you need to process by 80%.
Even with that massive improvement, however, many organizations are still struggling with hundreds of thousands of CVEs. If you are in the unfortunate position of having 100,000 CVE findings, reducing the number you need to worry about to 20,000 is an excellent start. But it will still be challenging to tackle all of these potentially exploitable vulnerabilities rapidly.
In this situation, you can use the EPSS to further prioritize CVE findings. It’s quite possible that, while they may be reachable by an attacker, certain issues are quite difficult to exploit in practice due a lack of published exploit code, a prevalence of compensating controls (e.g. firewall rules), or similar reasons. Conversely, some might be trivial to exploit and are under active attack in other organizations’ networks.
Thus, after making the ‘first cut’ using reachability analysis to determine which vulnerabilities present any risk in your environment, you can then use the EPSS to identify the highest priority issues within that sub-group.
Evaluating exploitability in others’ proprietary code
When using software developed by other commercial organizations, it may not be feasible or permissible (due to contractual prohibitions on decompilation or reverse engineering) to conduct reachability analysis on it. But it might be possible to conduct traditional software composition or dynamic analysis.
These techniques often produce huge numbers of CVE findings which are difficult to prioritize. With the EPSS, however, you can quickly communicate with the vendor about the general priority for investigating and potentially fixing these problems.
Targeting any CVEs at or above the threshold of 0.088 (as done in the EPSS paper) is probably a good starting point. With this list, the vendor can then focus on investigating those issues which are most likely to be exploited globally. After conducting technical analysis of them, it can determine which ones present a true risk and which ones can be deprioritized.
And hey, you might even suggest that the vendor get a reachability analysis solution themself…
Conclusion
With dozens of CVEs identified every day, staying on top of them can be a major problem. Reachability analysis is the best way to understand the risk presented by a given vulnerability in your specific environment. With that said, layering in alternative approaches like the EPSS can accelerate your efforts even more, reducing your remediation burden and saving your engineering teams precious time.
Want to learn more about reachability analysis and how Endor Labs does it? Watch this short video: