EPSS: Exploit Prediction Scoring System

This is a more technical introduction to how Lupasafe keeps score.

At Lupasafe we believe the context of a vulnerability is highly relevant in making decisions over just a CVSS score. The security professional wants to know the real-world risk for each vulnerability. The CTO or IT partner wants to know ‘why’ a vulnerability should be patched in order to minimize business disruption. 

For this reason, we use the public vulnerability data as a starting point. We include other data sources to build a real-world risk model for vulnerabilities, inspired by EPSS[1]. To understand the context of the vulnerability we need to know the importance of the asset it runs on for the business. How critical is this asset? We also want to understand the intruder’s perspective, for this reason we gather attack data and incorporate dark web data. What is the ‘talk of town’ and how many Tor-sites discuss this vulnerability? Finally, Lupasafe bots continuously scrape the dark and deep web for exploits. This results in a probability that a vulnerability will be exploited in the next twelve months, from 0 to 100%.

The results from the machine learning model should not be a black box, for this reason we deliver a break down for each vulnerability in the contribution of each factor to the result. The CISO and CTO can use this information in their decision-making process and give feedback to further improve predictions.

A bit on CVSS first

Vendors indicate the risk of their vulnerability by a CVSS score (‘Common Vulnerability Scoring System’). The score ranks from 0 to 10, with 10 being the most severe. Certain industries base their patching policy on this score like PCI-DSS[3] . In this case all vulnerabilities with a CVSS score over 4.0 should be patched. CVSS does not take into account contextual factors like criticality of business asset, threat intelligence feeds and amount or popularity of exploits that can be applied.

Crossing the chasm: CVSS and real-world risk

Let’s look at the risk for vulnerabilities, a key metric for decision-making on whether to patch or wait. As an example, we see CVE-2014-3566 on the Lupasafe network. It has a CVSS score of 4.3 and says this vulnerability “..makes it easier for man-in-the-middle attackers to obtain cleartext data”. 

Lupasafe classifies this as an 81%[4] risk. The 81% score implies we expect this vulnerability to be exploited in the next twelve months. The score is high because we found 236 public references but no exploits. The vulnerability can be remotely exploited, authentication is not required and there are many references and conversations online around the topic. In this case a hidden tail risk of 4.3 could cause a major disruption.

Here the Lupasafe view:

High CVSS low LES

On the other end of the spectrum, we have vulnerabilities with a high CVSS score. In this case, the organization could be concerned about urgently fixing a CVSS rated 9.8 that has little real-world risk.

Let’s review CVE-2017-7375:

The vulnerability has a stunning 9.8 base-score: ‘A flaw in libxml2 allows remote XML entity inclusion with default parser flags’. Lupasafe rated this <1% because we did not detect applications in the wild, zero exploits and very few conversations. Again, absence of evidence does not imply evidence of absence - yet the security leadership can use this information to make its own informed decision.

Read more about EPSS here.