Last Updated on March 11, 2024 by Dave Farquhar
How Tenable sets plugin severity is a question customers have been asking me for years, dating back to the days I worked for Tenable partners. It can be a bit complicated, so in this blog post I will explain what goes into Tenable plugin severity.
Plugins versus CVE
The first part that makes things complicated is the relationship between CVE and plugin. It is usually a many-to-one relationship, not a one to one relationship. Tenable will frequently group several related CVEs in a single plugin.
Each CVE has a severity rating based on the CVSS scale of critical, high, medium, and low. If you have your scanner set up to use CVSS, the plugin severity will generally be the same as the CVE with the highest CVSS score. Yes, I said generally, but not always.
If the most severe CVE is a denial of service vulnerability, the overall score will be based on the highest non-denial of service vulnerability. This nuance isn’t something many people know, and is a frequent source of confusion.
How can a vulnerability be on the CISA KEV and only rate a medium?
Another question I see frequently is how a vulnerability can be on the CISA KEV, and only be medium severity. If you are not familiar with it, the CISA KEV is a list of known exploited vulnerabilities maintained by a department of the US Department of Homeland Security. It is not a list of exploitable vulnerabilities. It is a list of vulnerabilities that either the US government or one of its sources has observed being actively exploited. There is a difference. I can find any number of exploits on GitHub for various software products that work, at least allegedly, but don’t work reliably.
Exploited vulnerabilities are different. These are vulnerabilities that have evidence of actually being used.
Pro tip: Understanding that difference and figuring out how to explain it to others is one of the keys to turning around a vulnerability management program.
The reason a plugin can be a CVSS medium and be on the KEV is because CVSS prior to version 4 only measure impact, not probability. KEV is purely a probability measure. CVSS 4 attempts to remedy this shortcoming. Time will tell how effective it is.
VPR and plugin severity
VPR is Tenable’s own rating scale that factors threat intelligence into determining severity. The criteria includes around 175 factors from various threat intelligence sources. It measures probability and impact. VPR is one reason I say you can get away with not buying threat intelligence separately.
The idea is that if a vulnerability is actively being exploited or is likely to be exploited within the next month, it will have a high VPR score. If it is not likely to be exploited within the next month, it will have a lower VPR score.
What makes VPR different from other models is that it actually tries to measure both probability and impact, where many competing models, such as EPSS, only measure probability. For its faults, CVSS measures impact well. So VPR uses CVSS impact in its scoring.
The reason I bring this up is that when it comes to scoring a plug-in, the CVE with the highest CVSS score may not be the one with the highest VPR score. There will rightfully be a difference between CVSS and VPR score for any given CVE, but the presence of multiple CVEs in a plugin can exacerbate the difference.
Note that frequently a CVE will have a lower VPR score than its CVSS score. CVSS is criminally top heavy. But exceptions do happen, so sometimes a vulnerability can be a CVSS high yet a VPR critical, based on high probability of exploitation.
Since VPR measures both probability and impact, and its scores get re-evaluated daily, where CVSS scores get re-evaluated slightly more frequently than we get a February 29, I use and recommend VPR.
The case of end of life plugins
End of life plugins make the matter more confusing. These are plugins that track unsupported software like Microsoft Internet Explorer, Windows 7, Windows 98, and so on. Frequently these get marked critical, because critical is the worst case scenario. When Windows 7 first went end of life, it may or may not have had a critical vulnerability in it as long as it received that final update. But within a month or two it certainly did. And that count only grew over time.
I get the occasional question about what to do with these if they throw off an SLA. Retiring end of life software is often a bigger project that may be a different team’s responsibility.
For those cases, I use the recast functionality. The right thing to do is use the risk acceptance process for them. Somebody accepted the risk of continuing to use that software. It should be documented.
But that’s the ideal. Not every organization can live by ideals. In lieu of a risk acceptance, you can recast the end of life plugins to a lower severity to keep them from blowing up your SLA tracking. Especially if there is a project in place to retire those systems.
Legal stuff
This blog post was neither sanctioned nor endorsed by Tenable. Opinions expressed herein may not necessarily be the opinion of Tenable. Tenable and Nessus are trademarks of Tenable Network Security, Inc.
David Farquhar is a computer security professional, entrepreneur, and author. He has written professionally about computers since 1991, so he was writing about retro computers when they were still new. He has been working in IT professionally since 1994 and has specialized in vulnerability management since 2013. He holds Security+ and CISSP certifications. Today he blogs five times a week, mostly about retro computers and retro gaming covering the time period from 1975 to 2000.