CVSS is Just the Beginning

The Buck Starts Here

When it comes to discussing vulnerabilities, you can’t avoid CVSS, the Common Vulnerability Scoring System.  CVSS provides a convenient way to (for the most part) objectively analyze a vulnerability, and summarize it using a standard vector format, which then translates to a score on a 0-10 scale. 

The cybersecurity industry has further reduced this scale to four categories – Low, Medium, High, and Critical – as so:

CVSS score	Severity of vulnerability
9.0 - 10.0	Critical
7.0 - 8.9	High
4.0 - 6.9	Medium
0.1-3.9	Low

Obviously, a score of 0 would be not vulnerable.

CVSS has evolved over the years, and we’re currently on CVSS v3.1.  There are easy-to-use calculators, it is found in almost every CVE published, NIST provides their CVSS score for every vulnerability in the National Vulnerability Database (NVD), and you’ll find CVSS scores in security advisories from nearly every vendor – including F5.  CVSS is nigh-ubiquitous.

However, this ubiquity isn’t always a good thing.  For one, familiarity breeds contempt.  There has been a bit of a backlash against CVSS in some circles.  Personally, I think this is overblown and mostly unwarranted, but I also understand what drives it. 

CVSS is not perfect – but that’s why it has continued to evolve, and why CVSS 4.0 is currently in Public Preview.  I’m not on that working group myself, for lack of time, but one of my F5 SIRT colleagues is.  However, you don’t throw out the baby with the bath water, as they say, and CVSS is a useful tool, warts and all.

The real problem is that, to use another metaphor, when all you have is a hammer, everything looks like a nail.  CVSS is everywhere, so people are using it for everything – even things it is not good at or wasn’t designed to do.  Or they’re using it for things it was designed for, but not using it appropriately. 

Let’s start there.

All your base are belong to us

I’m not going to do a full CVSS tutorial here, maybe another time.  If you’re reading this, I’m presuming you have some familiarity with it and, if not, the documentation is well written.  As the User Guide states early on:

The CVSS Specification Document has been updated to emphasize and clarify the fact that CVSS is designed to measure the severity of a vulnerability and should not be used alone to assess risk.

Concerns have been raised that the CVSS Base Score is being used in situations where a comprehensive assessment of risk is more appropriate. The CVSS v3.1 Specification Document now clearly states that the CVSS Base Score represents only the intrinsic characteristics of a vulnerability which are constant over time and across user environments. The CVSS Base Score should be supplemented with a contextual analysis of the environment, and with attributes that may change over time by leveraging CVSS Temporal and Environmental Metrics. More appropriately, a comprehensive risk assessment system should be employed that considers more factors than simply the CVSS Base Score. Such systems typically also consider factors outside the scope of CVSS such as exposure and threat.

Take the time to read that and internalize it.  That is a vitally important point.

One of the biggest mistakes we see, over and over, is the use of a CVSS base score as the deciding factor on whether to address a vulnerability.  In the F5 SIRT we see this all the time with customers, and we also see it internally when working to address our own vulnerabilities.  How many of you have heard it, or done it, yourself?  “Oh, that’s only a Medium, we don’t need to deal with that right now.”  Or “That’s a Critical – drop everything and patch that immediately!”

CVSS scores drive everything from IT response to press coverage, often massively out of proportion to the actual issue.  Especially when the score provided by a vendor is the base score, which is basically a theoretical score of the vulnerability of the issue in a vacuum.  A vendor’s 10.0 Critical may be a 0.0 if you don’t have that functionality enabled at all.  Or their 5.9 Medium may be a critical issue if it is in a key bit of mission-critical kit exposed to the public Internet, and there is a known exploit in the wild.

The problem isn’t CVSS.  The problem is that too much weight is being placed on the CVSS base score as the end-all and be-all factor in evaluating a vulnerability, or, more specifically, risk.

Expanding Your Base

An easy place to start is with the rest of CVSS.  That’s right, there’s more!  Vendors provide the Base Metric Group, or base score.  This mix of exploitability and impact metrics are universal and apply to all environments.  As I said above, it is an evaluation of the vulnerability in a vacuum.  Vendors don’t have visibility into each customer’s network – but you do.  At least your own network.  If you have visibility into all networks… Setec Astronomy, right?

There are two more groups available – the Temporal Metric Group and the Environmental Metric Group.  As the name implies, the temporal metrics cover characteristics that may change over time, such as the publication of exploit code or the release of a patch or mitigation.  While the environmental metrics allow you to consider factors unique to your environment which may affect the score.

As the base vector is nigh-universally available, making evaluation of the two additional vectors part of your vulnerability analysis process is a reasonable place to start.  This would produce a CVSS score adjusted for your environment, which would be a start for use in existing prioritization systems you may have.  It would be an improvement over the generic base scores, but it really is just a start.

Strike That. Reverse It.

As a step beyond CVSS in your vulnerability analysis, might consider Stakeholder-Specific Vulnerability Categorization (SSVC).  Yes, that’s CVSS backwards; never let it be said geeks don’t have a sense of humor.  SSVC was created by Carnegie Mellon University's Software Engineering Institute, in collaboration with the Cybersecurity & Infrastructure Security Agency (CISA).

The concept behind SSVC is a decision-tree model which results in three basic end states for the issue.  As very, very brief summary which does not do it justice:

• Track – no action required at this time.
• Attend – requires attention from higher levels and further analysis.
• Act – needs high level attention and immediate action.

SSVC is, as made very clear by the name, stakeholder specific.  It is something each end consumer can use to evaluate the impact of an issue on their network, to help them prioritize their response.  Part of your complete vulnerability response plan, as it were.

It is a fairly simple system, and CISA provides a PDF guide, a YouTube training video, and a simple online calculator to make it easy.  I recommend checking it out.  You may find that SSVC helps you better prioritize allocation of your limited IT resources.  How do I know they’re limited?  Is water wet?

Just My Type

Another factor you may want to consider in your risk assessment is the type of vulnerability.  Is this a DoS vector or unauthorized access?  Not all CVSS 7.5 vulnerabilities are created equal.  And that’s where the Common Weakness Enumeration (CWE) can help.

CWE provides a standardized way to categorize a vulnerability to, well, enumerate the type of weakness it is.  Many vendors, F5 being one, include CWEs in their security advisories.  It isn’t as widespread as CVE, but it is not uncommon.

And, in the cases where the vendor doesn’t provide it, NVD has NIST’s evaluation of the appropriate CWE for each entry.  The type of vulnerability can be another input into your risk assessment.  A DoS is bad, but not as bad as data exfiltration.  It goes beyond the score and helps foster a deeper understanding of the issue.

What You Don’t Know Can Hurt You

Which poses a greater risk to your network; a vulnerability CVSS 8.9 High which was found internally by the vendor and has never been seen in the wild, or a CVSS 5.8 Medium which has several known exploit scripts and active exploitation reported?  Now, answer honestly to yourself, which one is likely to get more attention from your own vulnerability response policies?  What if the first issue was a 9.9 Critical with the same characteristics?  Too often, the policies we see are “Bigger Number First”.

We’ve seen policies where anything less than a 7.0 is basically ignored.  If it isn’t a High or a Critical, it doesn’t matter.  That boggles my mind.  We’ve seen so many exploits where a Medium, or even a Low, severity vulnerability was used as part of a chain of exploits to completely own a network.  Any vulnerability is still a vulnerability.  And, to repeat the important point, CVSS base score is not a comprehensive risk assessment.  It should not be used as such.

OK, so how can we include what is being exploited in our evaluations?  How can we know?  Well, we consult the Known Exploited Vulnerabilities Catalog (KEV), of course.  OK, this is just one of many resources available, but it is a free service provided by CISA for all to take advantage of.  There are many commercial tools out there as well, of course, and I’m not going to get into those.  Knowing that a vulnerability is being actively exploited would certainly factor into my risk assessment, I’m just saying.

Minority Reporting

Wouldn’t it be nice if you knew which vulnerabilities were the most likely to be exploited, and therefore the highest priority to patch?  That’s the goal of the Exploit Prediction Scoring System (EPSS).  EPSS is an effort to develop a data-driven model to predict which vulnerabilities are most likely to be exploited.  Its first public release was in early 2021, so it is still a relatively young effort, but it is certainly interesting.

EPSS is available for all to use.  You can browse some of the data online, as well as download it.  There is an API, User Guide, etc.  All the usual good stuff.  I’m not quite comfortable recommending making this part of a production risk assessment system just yet, but it wouldn’t hurt to be something to evaluate and see how it correlates with what you’re doing.  I find the idea promising.  I don’t see it even being a perfect prediction engine, but I can see it highlighting higher risk vulnerabilities that might otherwise be overlooked.  Time will tell.

Risky Business

The key point is that you need to evaluate the risk of a given vulnerability to your business.  No one else can do that for you, and there is no one-size-fits-all solution.  CVSS is not bad, it just isn’t meant for that task.  My personal view is that anyone writing articles or giving talks about how ‘CVSS is dead’ is just doing it for the clickbait – and probably looking to sell an alternative.  But the arguments generally come down to what I said right at the top – vendors provide the CVSS base vector and score, and that was never intended to be some kind of triage trigger on what gets addressed.

As I mentioned in my previous articles on CVE, F5’s role as a vendor is to inform our customers.  But we’re limited to providing general information on vulnerabilities, we cannot perform risk assessments for customer networks.  We do our best to provide the data, but the rest is up to you.

Keep using CVSS but use it as part of a balanced risk assessment system.  It should be one input, not the deciding factor.  I presented a few options above, but this is hardly an exhaustive list.  If you have other suggestions, please leave a comment – DevCentral is a community.  It doesn’t have to be a free resource, if there is a commercial tool you can’t live without, by all means recommend it.  I tried to remain neutral on that front as an F5 employee, but you don’t have to.

Until next time!

P.S. Check out the other articles from the F5 SIRT.