CVSSv3: New System, Old Problems Remain

This latest blog post in our CVSSv3 series discusses problems with CVSSv2 that persist in CVSSv3. While CVSSv3 did address some concerns with CVSSv2 – as we plan to discuss in a future blog post – it did not address all. Some of the remaining issues we believe are quite problematic.

The Access Complexity Segregation

In early 2013, we published an open letter to the FIRST CVSS SIG about the problems with CVSSv2. One of the sections called: “The Access Complexity Segregation” (fans of “The Big Bang Theory” sitcom should appreciate the titles in that letter) deals with how even with three levels of “Access Complexity (AC)”, the CVSSv2 specification is written in a manner that mostly sees two of the levels being used.

The current abstraction for Access Complexity (AC) all but ensures that only 2 of the 3 choices get used with any frequency. The bar between Medium and High is simply set too high in the current implementation. To support more accurate and granular scoring, it would be advantageous to have a 4-tier system for AC.

Overall, it does not offer sufficient granularity when scoring vulnerabilities. Instead of describing the problem in-depth here, we recommend reading that section of the original CVSSv2 letter (see page 4).

One of the problems documented in that section is “The Context-Dependent Conundrum” related to user-assisted attacks. When we first learned that the FIRST CVSS SIG was adding the “User Interaction (UI)” metric to CVSSv3, we were quite excited. We believed that it should at least address part of the problem by offering more granularity in such cases. Unfortunately, our excitement was short-lived when learning that instead of keeping the three levels of scoring, CVSSv3 now only provides two: “Low (L)” and “High (H)”.

The CVSS SIG did not improve the granularity provided by the “Access Complexity (AC)” metric – or now renamed to “Attack Complexity (AC)” in CVSSv3. They actually made it worse, as we also cover briefly in a previous blog post. It is unclear why the CVSS SIG decided to strip “Medium (M)”. If it was removed to simplify the use of CVSSv3, it is quite ironic, as CVSSv3 overall adds so much more complexity and confusion compared to CVSSv2. Regardless of the reasoning behind it, we believe that this was a clear mistake!

Fortunately, it is a mistake that is pretty straight-forward to rectify by reintroducing “Medium (M)” as a scoring option even if not addressing the related concerns voiced about CVSSv2. To do that, the CVSS SIG would still need to revisit the documented requirements for each level to ensure better use of all three levels.

The Cyberspace Five-O Problem

Another concern we previously voiced about CVSSv2 is it’s inability to properly score remote vulnerabilities with a very minor impact. We detail this on page 3 of our open letter and again, we recommend reading the detailed description of the problem there. Basically the problem is that standard remote vulnerabilities not requiring authentication won’t end up scoring below 5.0.

To help illustrate the issue, consider a minor, unauthenticated remote issue that allows disclosing the version of a specific product being used. That was scored 5.0 in CVSSv2 and now it has been increased to a 5.3 in CVSSv3. On the surface an increase of 0.3 seems very trivial and not even worth bringing up. However, the real point is that many people do not even consider such issues as real vulnerabilities; others consider them very minor issues, as they do provide somewhat helpful information during the reconnaissance phase of an attack.

What about a simple path disclosure issue or enumeration issue? You guessed it! These also both increased and are now scored 5.3. And remember, if anything we’d want them to be scored a lot lower; not higher. In fact, any standard remote, unauthenticated vulnerability with a limited impact to either the confidentiality, integrity, or availability ends up scoring 5.3 even if the impact is miniscule. CVSSv2 as well as CVSSv3 simply cannot deal with remote attacks that have minor impacts.

This means that no remote, unauthenticated issues – regardless of how miniscule the impact may be – are going to score below a “Medium” severity. In fact, when looking at CVSSv3 scoring we have found that very few vulnerabilities overall score as “Low”, which is something we’re going to discuss more in our next blog post.

From the NVD website they very accurately state that:

Two common uses of CVSS are prioritization of vulnerability remediation activities and in calculating the severity of vulnerabilities discovered on one’s systems.

Based on discussions with our customers and other people in the industry, we concur with NVD’s statement. However, the question must be asked: How useful is a risk scoring system really, if it overall cannot adequately deal with many classes of remote weaknesses without scoring them way too high?

As we see it, the only way to address this issue is to introduce an additional level in the impact metrics e.g. “Minor (Mi)” to be used for issues with very minor impacts border lining on security irrelevant.

Next time, we’re going to discuss some general observations about CVSSv3 scores, which have lead to major concerns about the accuracy and usefulness of the resulting scores of CVSSv3.

CVSSv3: When Every Vulnerability Appears To Be High Priority