What Is CVSS v3.1? Understanding The New CVSS
Table of Contents
The Common Vulnerability Scoring System (CVSS) provides an open framework for communicating the characteristics and impacts of software and hardware security vulnerabilities. Its quantitative model aims to ensure consistent and accurate measurement while enabling users to see the underlying vulnerability characteristics that were used to generate the scores.
FIRST (The Forum of Incident Response and Security Teams), the organization responsible for maintaining and developing the CVSS, recently announced the publication of CVSS version 3.1.
We’re here to explain the changes made in CVSS v3.1, their importance, and how this scoring should figure in when looking at security vulnerabilities.
CVSS v3.1: Measuring severity, not risk
FIRST’s Twitter announcement about the CVSS v3.1 highlights the biggest change, which is the new version’s clarification of the concepts introduced in version 3.0.
FIRST’s detailed user guide for CVSS v3.1 states that the “changes between CVSS versions 3.0 and 3.1 focus on clarifying and improving the existing standard without introducing new metrics or metric values, and without making major changes to existing formulas.”
The first and most prominent change that CVSS v3.1 brings is that it measures severity, not risk. In the words of the The CVSS v3.1 User Guide: “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.”
The new version aims to address and correct a common mistake where the CVSS Base Score was seen as the only factor for assessing risk, rather than a comprehensive risk assessment system.
In order to facilitate this, and ensure a consistent scoring standard across all industries, changes to the CVSS v3.1 include:
Clarification of the definitions and explanation of existing base metrics
The CVSS Extensions Framework: a new standard method of extending CVSS that allows a scoring provider to include additional metrics and metric groups while retaining the official Base, Temporal, and Environmental Metrics
- An expanded and refined version of the CVSS Glossary of Terms
CVSS v3.1: Examples
The main changes in v3.1 clarify the definitions of base metrics such as Attack Vector, Scope, Privileges Required, Security Requirements and more definitions in all of the three metric groups (Base, Temporal, and Environmental).
Although this might not seem like much of a difference, it can actually affect the scoring. For example, if an attacker needs to move the mouse for successful exploitation, which of the following CVSS v3.1 metrics of attack vector would you choose: “Network”, “Adjacent”, “Local”, or “Physical”?
Without a clear definition of every metric you might have chosen “Physical”, since a mouse is a physical device. But that’s not always the case: a mouse can also be moved using code or remote control, you don’t necessarily have to move the user’s physical mouse with your bare hands. Choosing “Physical” Instead of “Local” would change the score result by at least 0.35, and potentially even more if the value is multiplied, depending on the other metrics. This is just one example of how the CVSS v3.1’s updated and clarified definitions can impact the final score.
It’s important to note that while there weren’t any algorithm or calculations changes in this version, some formulas have been restructured. One of the issues that was found in v3.0 and addressed directly in v3.1 was in the “Roundup” function. In 3.0, this caused a slight difference in scoring results between different implementations of the algorithm by different users.
FIRST’s official site clarifies with this example: “although the intuitive result of 0.1 + 0.2 is 0.3, JavaScript implementations on many systems return 0.30000000000000004. A simple implementation of Roundup would round this up to 0.4, which is counter-intuitive”. In order to address potential inconsistencies in scoring, 3.1 contains the updated Roundup definition.
Updated vulnerability scores: What’s in the NVD?
The NVD has announced that it will begin to officially support the CVSS v3.1 on September 10, 2019. The announcement states that “Due to the clarifications in guidance, there will be some changes to the scoring practices used by NVD analysts for CVSS v3.0”
In order to see how fast these updates will be put in place, and also check how much using CVSS v3.1 changes the score, we went to our comprehensive open source vulnerabilities database to crunch the numbers and see how many of the open source vulnerabilities have been updated with a v3.1 score.
We found that 20% of the open source vulnerabilities in the NVD have a CVSS v3.1 score, and that nearly all of them (18%) are the most recently published vulnerabilities from 2019.
Interestingly, nearly all of the scores that were updated from CVSS v3.0 to CVSS v3.1 remained exactly the same. While we’re still in the early days of these updates, it appears that so far, the scores of existing CVE’s that were updated were not impacted.
That said, vulnerabilities are being re-analyzed and old mistakes are being discovered and remediated. We stumbled upon this positive by-product of the update in a few vulnerabilities that were re-analyzed and in some cases got surprising new scores.
The biggest variation that we found was in CVE-2019-1010241. This vulnerability in Jenkins Credentials Binding Plugin Jenkins 1.17, originally published on the NVD in July 2019, was first given a CVSS v3.0 score of 8.8 by the NVD, and was now updated to a much lower CVSS 3.1 score of 6.5
While this somewhat big dip isn’t a direct result of CVSS 3.1 updates, it’s a reminder that it’s always good to re-analyze and refresh to ensure that your data quality is optimal.
How should we use CVSS v3.1?
The CVSS scoring system is meant to create a universal guideline to help organizations easily understand the impact and importance of every CVE. FIRST released CVSS v.3.1 because assessing a vulnerability in your systems or network is a complex process, and you can’t rely solely on the CVSS score to evaluate the impact of a security vulnerability on your company assets.
For example, let’s say there is a vulnerability for servers which is scored “Low”, If you need to choose between remediating this vulnerability or others from your huge list of alerts, you probably would have fixed this last, or maybe never. But if I told you that this vulnerability affects your firewall server, you probably would prioritize it as urgent.
Factors like vulnerable dependencies, network architecture and configuration, to name a few, are very important when you’re assessing the risk of a security vulnerability in your assets. FIRST’s updated CVSS v3.1 asserts that the CVSS shouldn’t be taken as the only parameter, and that your company network structure must be taken into consideration as part of the assessment process of vulnerabilities.
While the change in CVSS scoring may seem minimal, CVSS v3.1 can potentially have a big impact. It provides users with a more comprehensive and precise context and shared understanding. The updated standard allows more users to share it, affecting not only the CVSS score, but also the security community and the way that we share knowledge, assess our risk, and address security vulnerabilities within a clear and consistent context.
