Vulnerability Assessment Using CVSS 3.0
We have been using the CVSS scoring system since the creation of our vulnerability database and our first product, XSpider (hopefully someone still remembers it). For us, it is extremely important to keep the knowledge base used in our products and services up to date.
Since the recommendations for working with CVSS metrics do not cover every possible type of vulnerability, we often face the question: how should the metrics be set so that the final score reflects the real danger of a vulnerability?
We constantly monitor the development of the standard, so we had been waiting for the final version of CVSSv3 for quite some time. When opening the specification, the main questions were:
What has improved?
What exactly has changed?
Can the new standard be used in our products?
Another important question relates to training new specialists who work with vulnerability databases. We wanted to understand how quickly someone can learn the methodology and how clear the evaluation criteria are.
While studying the standard, the idea for this article appeared. Hopefully, it will help you better understand the new vulnerability assessment methodology.
---
A Brief History of CVSS
The Common Vulnerability Scoring System (CVSS) standard was originally developed by a group of security experts from the National Infrastructure Advisory Council. The group included specialists from organizations such as CERT/CC, Cisco, DHS/MITRE, eBay, IBM Internet Security Systems, Microsoft, Qualys, and Symantec.
The first version of the standard was published in 2005. The basic principles of vulnerability scoring defined at that time are still used today.
Later, the standard began to be supported by the CVSS Special Interest Group (CVSS-SIG) within the Forum of Incident Response and Security Teams (FIRST). Membership in this group does not impose restrictions on the support or distribution of the standard.
In 2007, the second version of the standard was released. Several metrics were refined, and the formula for calculating the final score was updated to provide more accurate vulnerability assessments.
In 2014, organizations such as NIST and ITU published recommendations on using CVSSv2 in telecommunications and information system standards. The use of CVSS metrics for vulnerability assessment was also incorporated into standards such as PCI DSS.
In June 2015, FIRST released the final version of CVSSv3, which is the focus of this discussion.
---
Basics of CVSS
CVSS provides a simple tool for calculating a numerical score on a scale from 0 to 10. This score helps security specialists quickly decide how to respond to a vulnerability. The higher the score, the more urgent the response should be.
The standard defines three groups of metrics:
Base metrics describe the intrinsic characteristics of a vulnerability that do not change over time and do not depend on the environment. These metrics evaluate how difficult the vulnerability is to exploit and what potential impact it has on confidentiality, integrity, and availability.
Temporal metrics adjust the score depending on factors such as the availability of exploit code, the maturity of the exploit, and the presence of patches or fixes.
Environmental metrics allow security professionals to modify the final score depending on the characteristics of a specific infrastructure or environment.
Temporal and environmental metrics are optional. They are mainly used when a more precise assessment is needed for a particular system or organization.
The result is usually published as a pair consisting of a vector (the set of metric values) and a numerical score calculated according to the formula defined in the standard.
---
Key Changes Introduced in CVSSv3
CVSSv3 introduces several improvements compared to the previous version.
One important concept is the distinction between the vulnerable component and the impacted component.
The vulnerable component is the system component that contains the vulnerability itself.
The impacted component is the one whose confidentiality, integrity, or availability can be affected when the vulnerability is exploited.
In many cases these components are the same, but some vulnerabilities affect different parts of a system. Examples include sandbox escape vulnerabilities, access to browser-stored user data through web application vulnerabilities like XSS, or escaping from a virtual machine.
In CVSSv3, exploitability metrics are calculated for the vulnerable component, while impact metrics are calculated for the impacted component.
---
Exploitability Metrics
Several important improvements were made in the metrics describing how vulnerabilities can be exploited.
The Attack Vector metric now distinguishes between network, adjacent network, local, and physical access.
In earlier versions, “local” covered almost all non-network scenarios. CVSSv3 now separates local access from physical access, which allows more accurate risk assessments.
The Attack Complexity metric describes how difficult it is to exploit a vulnerability. In CVSSv3, the criteria were simplified and clarified to reduce ambiguity.
Another new metric is User Interaction, which specifies whether the victim must perform some action for the attack to succeed. For example, opening a malicious link or file.
The previous authentication metric was replaced with Privileges Required, which indicates what level of access an attacker needs before exploiting the vulnerability. This allows a clearer distinction between attacks requiring normal user privileges and those requiring administrative access.
---
Scope and Impact
CVSSv3 also introduces the Scope metric. This indicates whether exploiting a vulnerability affects only the vulnerable component or also impacts other components in the system.
If the exploitation crosses security boundaries and affects additional components, the vulnerability receives a higher severity score.
Impact metrics also changed significantly. Instead of using the previous “partial” and “complete” impact values, CVSSv3 uses qualitative values such as low and high for confidentiality, integrity, and availability. This makes the evaluation more flexible and realistic.
---
Temporal Metrics
Temporal metrics did not change significantly in CVSSv3.
They include factors such as the maturity of exploit code, the availability of patches or workarounds, and the reliability of vulnerability reports.
However, the formula used to calculate the final score has been adjusted so that temporal metrics have slightly less influence on the final result.
---
Environmental Metrics
Environmental metrics allow organizations to adjust vulnerability scores depending on their own infrastructure and security requirements.
For example, if confidentiality is especially critical for a particular system, the final score may increase accordingly. Conversely, compensating security controls may reduce the final risk score.
CVSSv3 also introduces modified versions of base metrics that can be adjusted to match the real conditions of a specific environment.
---
Vulnerability Chains
Another interesting addition in CVSSv3 is guidance for evaluating vulnerability chains.
Sometimes a single vulnerability does not pose a serious threat by itself. However, when combined with another vulnerability, it can lead to a much more severe attack.
The standard recommends evaluating such scenarios by combining exploitability metrics from one vulnerability with impact metrics from another.
---
Severity Rating Scale
Over the years, different organizations used slightly different qualitative scales when interpreting CVSS scores. CVSSv3 standardizes this scale.
The recommended severity levels are:
0 — None
0.1 to 3.9 — Low
4.0 to 6.9 — Medium
7.0 to 8.9 — High
9.0 to 10.0 — Critical
---
Summary
CVSSv3 introduces several important improvements compared to earlier versions.
The standard now distinguishes between vulnerable and impacted components, adds a physical attack vector, introduces the user interaction metric, and improves the way privileges and impact are evaluated. It also provides clearer guidance for evaluating vulnerability chains and standardizes severity levels.
Overall, the new approach allows security professionals to evaluate vulnerabilities more accurately while still keeping the assessment process relatively straightforward.
Many companies involved in vulnerability analysis have already started adopting CVSSv3 in their products and services. Our team is also integrating support for CVSSv3 scoring into our internal knowledge base and security products.
We have been using the CVSS scoring system since the creation of our vulnerability database and our first product, XSpider (hopefully someone still remembers it). For us, it is extremely important to keep the knowledge base used in our products and services up to date.
Since the recommendations for working with CVSS metrics do not cover every possible type of vulnerability, we often face the question: how should the metrics be set so that the final score reflects the real danger of a vulnerability?
We constantly monitor the development of the standard, so we had been waiting for the final version of CVSSv3 for quite some time. When opening the specification, the main questions were:
What has improved?
What exactly has changed?
Can the new standard be used in our products?
Another important question relates to training new specialists who work with vulnerability databases. We wanted to understand how quickly someone can learn the methodology and how clear the evaluation criteria are.
While studying the standard, the idea for this article appeared. Hopefully, it will help you better understand the new vulnerability assessment methodology.
---
A Brief History of CVSS
The Common Vulnerability Scoring System (CVSS) standard was originally developed by a group of security experts from the National Infrastructure Advisory Council. The group included specialists from organizations such as CERT/CC, Cisco, DHS/MITRE, eBay, IBM Internet Security Systems, Microsoft, Qualys, and Symantec.
The first version of the standard was published in 2005. The basic principles of vulnerability scoring defined at that time are still used today.
Later, the standard began to be supported by the CVSS Special Interest Group (CVSS-SIG) within the Forum of Incident Response and Security Teams (FIRST). Membership in this group does not impose restrictions on the support or distribution of the standard.
In 2007, the second version of the standard was released. Several metrics were refined, and the formula for calculating the final score was updated to provide more accurate vulnerability assessments.
In 2014, organizations such as NIST and ITU published recommendations on using CVSSv2 in telecommunications and information system standards. The use of CVSS metrics for vulnerability assessment was also incorporated into standards such as PCI DSS.
In June 2015, FIRST released the final version of CVSSv3, which is the focus of this discussion.
---
Basics of CVSS
CVSS provides a simple tool for calculating a numerical score on a scale from 0 to 10. This score helps security specialists quickly decide how to respond to a vulnerability. The higher the score, the more urgent the response should be.
The standard defines three groups of metrics:
Base metrics describe the intrinsic characteristics of a vulnerability that do not change over time and do not depend on the environment. These metrics evaluate how difficult the vulnerability is to exploit and what potential impact it has on confidentiality, integrity, and availability.
Temporal metrics adjust the score depending on factors such as the availability of exploit code, the maturity of the exploit, and the presence of patches or fixes.
Environmental metrics allow security professionals to modify the final score depending on the characteristics of a specific infrastructure or environment.
Temporal and environmental metrics are optional. They are mainly used when a more precise assessment is needed for a particular system or organization.
The result is usually published as a pair consisting of a vector (the set of metric values) and a numerical score calculated according to the formula defined in the standard.
---
Key Changes Introduced in CVSSv3
CVSSv3 introduces several improvements compared to the previous version.
One important concept is the distinction between the vulnerable component and the impacted component.
The vulnerable component is the system component that contains the vulnerability itself.
The impacted component is the one whose confidentiality, integrity, or availability can be affected when the vulnerability is exploited.
In many cases these components are the same, but some vulnerabilities affect different parts of a system. Examples include sandbox escape vulnerabilities, access to browser-stored user data through web application vulnerabilities like XSS, or escaping from a virtual machine.
In CVSSv3, exploitability metrics are calculated for the vulnerable component, while impact metrics are calculated for the impacted component.
---
Exploitability Metrics
Several important improvements were made in the metrics describing how vulnerabilities can be exploited.
The Attack Vector metric now distinguishes between network, adjacent network, local, and physical access.
In earlier versions, “local” covered almost all non-network scenarios. CVSSv3 now separates local access from physical access, which allows more accurate risk assessments.
The Attack Complexity metric describes how difficult it is to exploit a vulnerability. In CVSSv3, the criteria were simplified and clarified to reduce ambiguity.
Another new metric is User Interaction, which specifies whether the victim must perform some action for the attack to succeed. For example, opening a malicious link or file.
The previous authentication metric was replaced with Privileges Required, which indicates what level of access an attacker needs before exploiting the vulnerability. This allows a clearer distinction between attacks requiring normal user privileges and those requiring administrative access.
---
Scope and Impact
CVSSv3 also introduces the Scope metric. This indicates whether exploiting a vulnerability affects only the vulnerable component or also impacts other components in the system.
If the exploitation crosses security boundaries and affects additional components, the vulnerability receives a higher severity score.
Impact metrics also changed significantly. Instead of using the previous “partial” and “complete” impact values, CVSSv3 uses qualitative values such as low and high for confidentiality, integrity, and availability. This makes the evaluation more flexible and realistic.
---
Temporal Metrics
Temporal metrics did not change significantly in CVSSv3.
They include factors such as the maturity of exploit code, the availability of patches or workarounds, and the reliability of vulnerability reports.
However, the formula used to calculate the final score has been adjusted so that temporal metrics have slightly less influence on the final result.
---
Environmental Metrics
Environmental metrics allow organizations to adjust vulnerability scores depending on their own infrastructure and security requirements.
For example, if confidentiality is especially critical for a particular system, the final score may increase accordingly. Conversely, compensating security controls may reduce the final risk score.
CVSSv3 also introduces modified versions of base metrics that can be adjusted to match the real conditions of a specific environment.
---
Vulnerability Chains
Another interesting addition in CVSSv3 is guidance for evaluating vulnerability chains.
Sometimes a single vulnerability does not pose a serious threat by itself. However, when combined with another vulnerability, it can lead to a much more severe attack.
The standard recommends evaluating such scenarios by combining exploitability metrics from one vulnerability with impact metrics from another.
---
Severity Rating Scale
Over the years, different organizations used slightly different qualitative scales when interpreting CVSS scores. CVSSv3 standardizes this scale.
The recommended severity levels are:
0 — None
0.1 to 3.9 — Low
4.0 to 6.9 — Medium
7.0 to 8.9 — High
9.0 to 10.0 — Critical
---
Summary
CVSSv3 introduces several important improvements compared to earlier versions.
The standard now distinguishes between vulnerable and impacted components, adds a physical attack vector, introduces the user interaction metric, and improves the way privileges and impact are evaluated. It also provides clearer guidance for evaluating vulnerability chains and standardizes severity levels.
Overall, the new approach allows security professionals to evaluate vulnerabilities more accurately while still keeping the assessment process relatively straightforward.
Many companies involved in vulnerability analysis have already started adopting CVSSv3 in their products and services. Our team is also integrating support for CVSSv3 scoring into our internal knowledge base and security products.
