CVSS V3: What’s in a Name?
Marina Kidron Aug 6, 2015
In June 2015, the Forum of Incident Response and Security Teams (FIRST) announced the availability of version 3 of the Common Vulnerability Scoring System (CVSS), the universal open and standardized method for rating IT vulnerabilities and determining the urgency of response.
“The updated version includes enhancements such as: the promotion of consistency in scoring, and consideration of the system in order to make it more applicable to modern concerns. More information on the standard is available at https://www.first.org/cvss.”
In a Nutshell
In short, some of the vectors’ names in CVSS V3 were changed to follow the “attacks” terminology (instead of access), added User Interaction and Scope vectors, and made a few changes in existing metrics’ value names.
The main problem, though, with the old CVSS V2 is not in the vectors’ names or values, but in the limited adoption rate, even though it was published eight years ago in June 2007.
The CVSS adoption map for selected vendors demonstrates the big picture of vendor adoption prior to the CVSS V3 rollout:
Problems in the Current Situation
The National Vulnerability Database (NVD) has CVSS V2 scores and vectors for all vulnerabilities. But the major vendors don’t always follow it, to say the least.
Vendors that don’t support the CVSS V2 often have an internal severity rating system, which does not always match the NVD CVSS score.
For example, the recently published Microsoft Bulletin MS15-068 is marked as “critical,” but got the CVSS Base Score of 7.2 by NVD (out of 10). 7.2 is translated as “high” severity rating, which is quite far from the critical rate—a score of 9.0 or higher.
On the other hand, many vendors that do support the CVSS V2 metrics often disagree with NVD on both the vector parameters and score.
For example, CVE-2015-0189 is a denial-of-service vulnerability affecting IBM WebSphere MQ. NVD rated it as 4.0 (medium) with Access Vector = Network; but IBM rated this vulnerability as 1.5 (low on the NVD scale) with Access Vector = Local.
The discrepancies in in scoring systems can be a headache for vulnerability management teams trying to prioritize actions. While CVSS or vendor-specific scoring is good starting point, organizations really need prioritization methods specific to their network in order to understand where best to focus resources. Even vulnerabilities with moderate or low-level scores according to any system may have a more damaging impact when considered in the context of a living, breathing network.
Will CVSS V3 Address the Main Problem?
First, it is important to say that CVSS V3 addresses some of the technical problems that were seen in CVSS V2.
One of them is the scoring consistency issue. For example, code execution vulnerabilities in Google Chrome sometimes rated with “medium” severity, with CVSS score of 6.8 or 7.5 (e.g., CVE-2015-1255) with “partial” impact in confidentiality, integrity, and availability. In other cases, a very similar vulnerability is rated with “critical” severity, resulting in a CVSS score 9.3 or 10.0 (e.g., CVE-2015-0308), with “complete” impact in confidentiality, integrity, and availability.
CVSS V3 is supposed to address this issue by modeling the scope of the vulnerability, and having a stricter definition of when to use partial and complete impacts.
However, the real success of CVSS V3 will be measured by the adoption of the standard by the community, including security scanners, NVD, and the vendors themselves.
See how Skybox Vulnerability Control enables context-aware prioritization to find vulnerability hot spots for targeted, streamlined remediation, and determines access and impact on a specific network by considering asset value, surrounding security controls, and more.
Don’t stop at vulnerabilities—see how Skybox Threat Manager can prioritize threats based on business impact, and bring risk into view for your network.