In this list, we don’t see any of the significant factored software types, so there are no weights to add here.

Calculating the Likelihood of Exploitation of a Vulnerability

Now that we have all our factors and weights, we can do some simple math in a spreadsheet.
 

Table 2. Factors and weights contributing to likelihood of exploitability of CVE-2019-11043.

Adding these numbers up, we get 1.69. To yield a probability, we need to run it through a log calculation which, in Excel, looks like: =1/(1+EXP(-3.07)). This comes out to 0.8443, which is a probability percentage, which translates to 84.4% Probability of exploitation in next 12 months. This is a higher priority patch. Looking at the factors, it appears that the highest significant factor is due to the widespread dispersal of this vulnerability, as counted in references, and the availability of exploits.

Measuring our Success

CVE-2019-11043 was released in late October of 2019. Even though the twelve months aren’t up yet, we have more information on this vulnerability. At the end of January, F5 Labs published Vulnerabilities, Exploits, and Malware Driving Attack Campaigns in December 2019. That update mentioned specific CVEs being targeted for attack (hint: this a great resource to use for patching priority, as well). One of the CVEs F5 Labs noted being exploited in the wild was CVE-2019-11043. Specifically, we saw two campaigns targeting ThinkPHP servers vulnerable to CVE-2019-11043. So yes, this vulnerability is getting attacked. In general F5 Labs sees a lot of PHP-related attack traffic, so if we were to add a weight to this model, it would be one for PHP vulnerabilities.

Estimating the Likelihood without Using Math

That was a little bit of work (really about 10 minutes of lookups and a spreadsheet), but even that may turn some folks off. Just looking at this model, teams can easily improve their intuitive guesstimates with the following rule of thumb: The highest priority to patch should be for software from Microsoft, IBM, Adobe, or HP that has published exploit code that allows code execution.

The second most significant factor would be to look at reference count, or how widespread or embedded this vulnerability is across the technical landscape. After only about a half dozen references, the weighting for this factor gets significant.

Even though our example wasn’t from a major software source, the reference count and exploit code was enough to push this up to a higher probability.

All of these factors point at the economic rationality of attackers. They will go after vulnerabilities that are abundant, easily exploited, and allow them to quickly gain control of our systems. It’s a no brainer that these would be highly targeted.

The key contributor to this model, Kenna Security, hosts an easy-to-use calculator for the EPSS on its website, which is already pre-populated with major vulnerability entries.

Conclusion

An additional benefit from a simple, effective, and repeatable process like this is that it can be assigned to less-experienced security professionals or even automated. These are the kinds of benefits we wrote about earlier in how CISOs are using machine learning to augment security staffing shortages. The EPSS model is definitely something worth adding to the arsenal of security operational processes.

Update

The Exploit Prediction Scoring System (EPSS) is now part of FIRST (Forum of Incident Response and Security Teams), the custodian of the older model CVSS.

They now supply updated data to feed into your EPSS models here: https://www.first.org/epss/data_stats