Dec 14, 2020
Common Vulnerability Scoring System (CVSS) allows companies to make use of a common language when dealing with vulnerability threats. Since it was created in 2003, CVSS has been widely implemented by many companies.
Today, CVSS standards are used by different vulnerability databases, which include government databases such as the National Vulnerability Database (NVD). But, the CVSS of 2003 is not the same as the one used today. This article reviews the recent changes introduced in the latest version of CVSS.
Common Vulnerability Scoring System (CVSS) is a standardized structure for rating known vulnerabilities in components. It was created by the US National Infrastructure Advisory Council in 2003 and has been maintained by the Forum of Incident Response and Security Teams (FIRST) since 2005.
The structure is designed to help security experts measure the threat associated with a given vulnerability, prioritize work, and create a common language of threat categories. Major vulnerabilities databases and information sources use CVSS scores as a way to help security experts filter threats.
CVSS 3.1 is the recently released version of the framework. It was released in 2019 as a partial update version 3 in order to enhance and clarify the standards. However, it did not add additional metrics. This is part of an ongoing effort to make CVSS easier to use and more accessible.
For instance, when the version 3.0 specification document was released, it was accompanied by a user manual and a document filled with examples. These resources help to ensure that the standards are correctly used. This was not done for other versions of the CVSS.
Regardless of the modifications to make the standard more user-friendly, knowing how to implement CVSS v3 can still be an issue. There are different changes you need to take into consideration such as changes to formulas and changes to metrics.
There are several changes that you need to know about so as to calculate a consistent score. Generally, these changes have been made to make scoring clearer and to eradicate any ambiguities. This includes the following:
In the base metrics, user interaction (UI) and privileges (PR) metrics were added. These metrics were extracted from the access vector metric. This was done in order to help highlight vulnerabilities that need additional circumstances or access to be exploited, meaning vulnerabilities that had less potential impact.
A scope metric was also added to help highlight vulnerabilities that can be used as part of a bigger attack. In the attack vector (AV) metric, a sub-metric measuring physical access requirement was added. Small changes were also made to the scales of metrics to allow greater flexibility of definition.
For environmental metrics, the measures were totally replaced with a modified base score. This score is meant to allow security experts to develop a score personalized to their specific configurations and environments.
Using CVSS, scores are determined by a combination of base score and temporal score. You can change this score to match your specific systems via environmental metrics. Scores are scaled from 0-10, with 10 being the highest severity.
While only the base metrics are needed to generate a score, it’s recommended that temporal metrics be included for general scores. In addition, you should make use of environmental metrics when planning your own security efforts.
The base score is created to reflect the stationary qualities of vulnerabilities that do not change because of time or environment. The base score is determined by a combination of the following subscores:
The exploitability subscore rate how easily a vulnerability can be exploited by cyber attackers. It’s based on a combination of metrics defining attack vectors (AV), attack complexity (AC), privileges required (PR) and user interaction required (UI).
All metrics except UI are scales which range from high barriers to low, with low representing higher scores. UI is a binary metric in which interaction is not needed.
The impact score rates the security impact, such as attacker access or privileges, on systems being exploited and measures the change from pre to post-exploit. It’s based on a combination of metrics defining confidentiality (C), integrity (I) and availability (A). These metrics include a range of none, low and high.
The scope subscore relates to the impact that a vulnerability has on components that are not directly vulnerable. It includes any resources that are contained under the same set of access controls or security authority as the affected component.
The temporal metrics remain the same from CVSS 2. These metrics evaluate the current state of code availability or exploit techniques, the accuracy of the description of the vulnerability and the existence of patches or workarounds. Metrics include remediation level, exploitability and report confidence.
Changes in environmental metrics are the most significant improvement in CVSS. These metrics enable you to personalize scores based on individual relevance. These metrics include modifications of integrity, confidentiality and availability as well as:
CVSS v3 is a great improvement on previous versions. It simplifies official documentation which enables users to understand the framework concepts. The addition of the examples document is beneficial because it clarifies how to use the concepts.
The changes to metrics can help to effectively classify vulnerabilities relating to users, privileges and formula changes can help avoid unclear calculations. These are ideal modifications that can help improve how vulnerabilities are scored.
Three Important Steps for Your Vulnerability Remediation ProcessKent Weigle July 12, 2021
Challenges with Traditional Vulnerability ScannersKent Weigle July 10, 2021
Vulnerability Scanning: What Does It Entail?Kent Weigle July 09, 2021
To Patch or Not to PatchKent Weigle June 30, 2021
Common Issues with Patch ManagementKent Weigle June 30, 2021