We have all seen the CVSS score for vulnerabilities listed on the National Vulnerability Database (NVD) when researching vulnerabilities. It is a numeric value between 0 to 10 and comes with a qualitative description of the score such as Low, Medium, High Or Critical. Because of the qualitative description of the score, I never bothered to dig deeper into how this was calculated.
The organization maintaining the specification for CVSS is the Forum of Incident Response and Security Teams (FIRST). FIRST defines CVSS as follows:
The Common Vulnerability Scoring System (CVSS) captures the principal technical characteristics of software, hardware and firmware vulnerabilities. Its outputs include numerical scores indicating the severity of a vulnerability relative to other vulnerabilities
first.org
Corporations, organisations and individuals interacting with Technology are dealing with vulnerabilities on a daily basis. With so many different minds looking at vulnerabilities subjectively, there are bound to be inconsistencies in the way severity of the vulnerabilities is perceived. CVSS eliminates the need of this subjectivity and defines clear, unambiguous parameters to quantify the severity of a vulnerability that all can agree upon. Other than providing a framework to calculate the intrinsic severity of the vulnerability (Base Metrics), it also provides an optional scoring system to gauge how severity modifies with time (Temporal Metrics) and environment of the organization (Environmental Metrics) that is assessing the vulnerability.
Well, what’s the practical use of understanding the methodology to derive CVSS score? I too had this notion until I read the actual specification myself and came to appreciate the beauty of this scoring system. I reckon that every security researcher, information security personnel or IT personnel should understand this scoring system well because this scoring system not only helps you understand the intrinsic severity of the vulnerability but it also provides a way to modify the severity level specific to your environment. Based on your organisation or application environment, the score might go higher or lower than the intrinsic score. This will help you to better prioritise remediation actions.
CVSS parameters are broadly classified in the following three groups:
Base Metrics: represent the intrinsic characteristics of a vulnerability that are constant over time and across user environments. The score derived from these metrics is called the Base Score and this is the score displayed on vulnerability publishing websites such as NVD.
Temporal Metrics: reflect the characteristics of a vulnerability that may change over time but not across user environments. The score derived from these metrics is called the Temporal Score.
Environmental Metrics: represent the characteristics of a vulnerability that are relevant and unique to a particular user’s environment. The score derived from these metrics is called the Environmental Score.
I am going to cover Base Metrics in this part and leave Temporal and Environment Metrics for another day.
The Base Metric group is further classified into three sub-groups:
This metric describes how remote or local an attacker should be in order to exploit this vulnerability.
The below table indicates the possible values for this metric, its abbreviation, description and the numeric value that is used while calculating the CVSS score.
Value | Abbreviated | Description | Numeric Value |
Network | N | Can be exploited over the network and beyond the local area network | 0.85 |
Adjacent | A | Can be exploited over local area network | 0.62 |
Local | L | Can be exploited only if attacker has logical access to the vulnerable system or component | 0.55 |
Physical | P | Can be exploited only if the attacker has physical access to the vulnerable system | 0.2 |
This metric describes the conditions beyond the attacker’s control that must exist in order to exploit the vulnerability.
Value | Abbreviated | Description | Numeric Value |
Low | L | Specialized conditions are not required to exist or attacker can exploit default installation of the component or system | 0.77 |
High | H | One or more special conditions should be met for the attacker to exploit this vulnerability | 0.44 |
This metric describes the level of privileges an attacker must possess before successfully exploiting the vulnerability.
Value | Abbreviated | Description | Numeric Value |
None | N | Attacker requires no privileges on the vulnerable system or component | 0.85 |
Low | L | Attacker requires non-administrative user capabilities on the vulnerable system or component | 0.62 |
High | H | Attacker requires administrative privileges over the vulnerable system or component | 0.27 |
This metric describes whether a victim or any benign user other than the attacker should interact with the system to successfully exploit the vulnerability.
Value | Abbreviated | Description | Numeric Value |
None | N | The vulnerable system can be exploited without interaction from any user. | 0.85 |
Required | R | Successful exploitation of this vulnerability requires a user to take some action before the vulnerability can be exploited. | 0.62 |
The Exploitability sub-group provides an Exploitability sub-score (ESS) which is calculated as follows:
ESS = 8.22 × Attack Vector × Attack Complexity × Privileges Required × User Interaction
Next, we move on to the Impact sub-group.
This metric measures the impact to the confidentiality of the information resources managed by the vulnerability component due to a successfully exploited vulnerability.
Value | Abbreviated | Description | Numeric Value |
High | H | All information is disclosed and/or some information that is disclosed is critical and/or attacker has complete control over what information can be disclosed. | 0.56 |
Low | L | Some information is disclosed to the attacker and/or information that is disclosed is not critical and/or attacker has no control over what information can be disclosed. | 0.22 |
None | N | No information is disclosed to the attacker. | 0 |
This metric measures the impact to integrity of information that resides on a successfully exploited system.
Value | Abbreviated | Description | Numeric Value |
High | H | There is a total loss of integrity, or a complete loss of protection. | 0.56 |
Low | L | Modification of data is possible, but the attacker does not have control over the consequence of a modification, or the amount of modification is limited. | 0.22 |
None | N | No information can be modified by the attacker. | 0 |
This metric measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability
Value | Abbreviated | Description | Numeric Value |
High | H | There is a total loss of availability, resulting in the attacker being able to fully deny access to resources in the impacted component. | 0.56 |
Low | L | Performance is reduced or there are interruptions in resource availability. Attacker does not have the ability to completely deny service to legitimate users. | 0.22 |
None | N | There is no impact to availability within the impacted component. | 0 |
The Impcat sub-group provides an Impact sub-score (ISS) which is calculated as follows:
ISS = 1 - [(1 - Confidentiality) × (1 - Integrity) × (1 - Availability)]
Scope is not a sub-group but a metric in itself with no numeric value.
Scope describes whether the attacker can access or impact resources, components or systems beyond the vulnerable component or system after successful exploitation of the vulnerability.
Value | Abbreviated | Description | Numeric Value |
Changed | C | An exploited vulnerability can only affect resources managed by the vulnerable component or system. | See Below |
Unchanged | U | An exploited vulnerability can affect resources other than those managed by the vulnerable component or system. | See Below |
Scope metric does not have a direct numeric value. It rather causes changes to the Impact & Exploitability sub-scores as follows:
Now that we have got the ESS & ISS, let’s understand the base score calculation. The final Base Score calculation formula differs based on Scope values and is as follows:
If Scope is Unchanged:
Base Score = Roundup(Minimum[(ISS + ESS), 10])
If Scope is Changed:
Base Score = Roundup(Minimum[1.08 ×(ISS + ESS), 10])
where Roundup( ) returns the smallest number, specified to 1 decimal place, that is equal to or higher than its input. For example, Roundup (4.02) returns 4.1; and Roundup (4.00) returns 4.0.
As you can see, a lot of information goes into calculating the Base Score. Hence, there needs to be a concise way of representing this information for the sake of brevity. That’s where the vector string notation comes into play.
Let us look at an example of a CVSS vector string to understand it:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
A vector notation starts with the words ‘CVSS’ followed by a colon and the version number of the specification, the latest being 3.1.
Following this are tuples containing the metric abbreviation for all base metrics and their corresponding value abbreviation separated by colons ( : ). Tuples are separated by slashes (/). For a vector string to be valid, it should contain all the base metrics. So, let’s decode the above string based on what we learnt earlier about the Base Metrics.
CVSS:3.1 = CVSS version is 3.1
AV:N = Attack Vector is Network
AC:L = Attack Complexity is Low
PR:N = Privileges Required is None
UI:N = User Interaction is None
S:U = Scope is Unchanged
C:H = Confidentiality Impact is High
I:H = Integrity Impact is High
A:H = Availability Impact is High
First, The Exploitability Sub-score:
ESS = 8.22 × Attack Vector × Attack Complexity × Privileges Required × User Interaction
First, let’s replace the variables with the metric value tuples from the vector string:
ESS = 8.22 × AV:N × AC:L × PR:N × UI:N
Now, let’s enter the numeric values for these metrics:
ESS = 8.22 × 0.85 x 0.77 x 0.85 x 0.85
ESS = 3.887042775
Now, for The Impact Sub-score:
ISS = 1 - [(1 - Confidentiality) × (1 - Integrity) × (1 - Availability)]
Replacing the variables:
ISS = 1 - [(1 - C:H) × (1 - I:H) × (1 - A:H)]
Entering the numeric values:
ISS = 1 - [(1 - 0.56) × (1 - 0.56) × (1 - 0.56)]
ISS = 0.914816
Now, let’s go for scope adjustment:
Scope = Unchanged
Hence, ESS remains the same.
And ISS
= 6.42 × ISS
= 6.42 × 0.914816
= 5.87311872
Now, finally, the Base Score:
Since Scope = Unchanged,
Base Score
= Roundup(Minimum[(ISS+ ESS), 10])
= Roundup(Minimum[(5.87311872+3.887042775), 10])
= Roundup(Minimum[9.760161495,10])
= Roundup(9.760161495)
= 9.8
So, that’s it. We have got the CVSS for our vulnerability.
Base Score = 9.8
The Vector String mentioned above was taken from CVE-2019-15107. Check out this NVD link to see if our numbers match.
CVSS provides the following qualitative rating scale to have a textual representation of the numeric values:
CVSS Score | Qualitative Rating |
0.0 | None |
0.1 – 3.9 | Low |
4.0 – 6.9 | Medium |
7.0 – 8.9 | High |
9.0 – 10.0 | Critical |
Now, you may be wondering, how on earth are you going to perform this calculation manually for every vulnerability that you are assessing. Don’t worry. FIRST team has put up an awesome calculator on their website for you: https://www.first.org/cvss/calculator/3.1
Go ahead and give it a try.
The next time you look up a vulnerability on NVD, you would be better equipped to understand the severity of the same and would be in a position to gauge which vulnerability should be a priority to for you.
I will cover the Temporal Metrics & Environmental Metrics in a later article.
See Also:
]]>