How does the CVE scoring system work?
Have you ever wondered how vulnerabilities are scored? Here’s a simplified explanation for an overly complex system.
Once a month, you hear me talk about CVE references in the Android Security Bulletin overviews. But what is CVE? CVE stands for Common Vulnerability and Exposures and is scored using the CVSS (Common Vulnerability Scoring System) standard. This standard is a bit complicated to grasp at first, and (on the surface) seems a bit arbitrary.
Even so, it’s this system that is in place, and I’m going to help you understand how it works.
SEE Windows 10 security: A guide for business leaders (TechRepublic Premium)
And so, without further ado, let’s explain.
The first thing to understand is that there are three types of Metrics used in this system:
- Base Score Metrics – depends on sub-formulas for Impact Sub-Score (ISS), Impact, and Exploitability.
- Temporal Score Metrics is equal to a roundup of BaseScore * EploitCodeMaturity * RemediationLevel * ReportConfidence.
- Environmental Score Metrics – depends on sub-formulas for Modified Impact Sub-Score (MISS), ModifiedImpact, and ModifiedExploitability. The formula for this is Minimum ( 1 – [ (1 -ConfidentialityRequirement * ModifiedConfidentiality) * (1 – IntegrityRequirement × ModifiedIntegrity) * (1 – AvailabilityRequirement * ModifiedAvailability) ], 0.915).
Within each set of metrics are the following sub-categories.
- Base Score Metrics: Attack Vector, Attack Complexity, Privileges Required, User Interaction, Scope, Confidentiality Impact, Integrity Impact, Availability Impact.
- Temporal Score Metrics: Exploitability, Remediation Level, Report Confidence.
- Environmental Score Metrics: Attack Vector, Attack Complexity, Privileges Required, User Interaction, Scope, Confidentiality Impact, Integrity Impact, Availability Impact, Confidentiality Requirement, Integrity Requirement, Availability Requirement.
Each metric is scored in different ways. For example, under Base Score Metrics you can score the Attack Vector with one of the following:
- Network (AV:N) – A vulnerability with network access. This means the component is bound to the network stack and the attackers path is through Open Systems Interconnection (OSI) layer 3 (the network layer).
- Adjacent Network (AV:A) – A vulnerability exploitable with Adjacent Network access, however the component is bound to the network stack via bluetooth or logical network (such as a local IP subnet).
- Local (AV:L) – A vulnerability with local access. This means the vulnerability is not bound to the network stack and the attack path is via read/write/executable capabilities on the local filesystem.
- Physical (AV:P) – A vulnerability which requires physical access to a vulnerable component on a device.
Within the Base Scores there are three different scores:
This is where it starts to get complicated (as if it isn’t already). Each sub-category has a list of metrics, of which you can select one. After selecting a metric for each sub-category a score is tallied via a specific equation. For example, the Base Score is a function of the Impact and Exploitability Sub Score equations.
The Base Score is defined as:
If (Impact sub score <= 0) 0 else … Scope Unchanged - ([( + ), 10]) Scope Changed - ([1.08 * ( + ), 10])
The Impact Sub Score is defined as:
Scope Unchanged 6.42 * Base Scope Changed 7.52 * [ − 0.029] − 3.25 * [ − 0.02]15 Where, = 1 − [(1 − ) * (1 − ) * (1 − )]
Finally, the Exploitability Sub Score is defined as:
8.22 * AttackVector * AttacComplexity * PrivilegeRequired * UserInteraction
Fortunately, we don’t have to depend on formulae to calculate the score of a vulnerability. Why? Because there is a handy Common Vulnerability Scoring System Calculator available that does this automatically. All you have to do is select a metric for each sub-category and the score is tallied, no manual calculation necessary.
But this doesn’t help to explain how each metric is scored. Back in Version 2 of the CVSS, it was much easier to calculate these scores, as each metric was given a value (finding values for v3 is an exercise in futility). For instance, the following Access Vectors (AV) had the following scores:
- Local (L) 0.395
- Adjacent Network (A) 0.646
- Network (N) 1.0
Each metric subcategory had an associated score. Once you applied a score to a metric’s subcategory, you could then calculate a vulnerability by plugging the scores into the related formula. For example:
Exploitability = 20 * AccessVector * AttackComplexity * Authentication
So if a vulnerability had an Access Vector of Local (score .395), an Attack Complexity of High (.35), and an Authentication of Multiple (.45), the CVSS score would be:
20 * .395 * .35 * .45 = 1.2442
A CVSS score of 1.2442 would earn a rating of Low. Of course that score is only a portion of a vulnerability (as there are other metrics to consider).
For CVSS v3, your best bet is going straight to the on-line calculator, selecting the individual metrics for each subcategory, and allowing the algorithms do the work for you.
The CVE scoring method is complicated, so much so that the average user shouldn’t even bother trying to calculate scores for vulnerabilities. However, having even a superficial understanding of how the system works helps you to better comprehend when you see a particular vulnerability is rated at Non (0.0) Low (0.1-3.9), Medium (4.0-6.9), High 7.0-8.9), or Critical (9.0-10).
This explanation barely scratches the surface of the complexity associated with the Common Vulnerability Scoring System. For more information about the CVSS, check out the official documentation for v3.