What is CVSS?
The Common Vulnerability Scoring System (aka CVSS Scores) provides a numerical (0-10) representation of the severity of an information security vulnerability. CVSS scores are commonly used by infosec teams as part of a vulnerability management program to provide a point of comparison between vulnerabilities, and to prioritize remediation of vulnerabilities.
CVSS is an open framework maintained by the Forum of Incident Response and Security Teams (FIRST), a US-based nonprofit with over 500 member organizations globally. While rating vulnerabilities based on an open, standardized methodology is powerful, it’s also important to recognize the drawbacks and limitations of CVSS in order to ensure that it’s being applied appropriately in your organization..
CVSSv2 vs CVSSv3
CVSS is now on its third major version (v3.1), which was designed to address some of the shortcomings in its predecessor, v2. Most notably, version 3 introduces the looks at the privileges required to exploit a vulnerability, as well as the ability for an attacker to propagate across systems (“scope”) after exploiting a vulnerability.
CVSS Score Metrics
A CVSS score is composed of three sets of metrics (Base, Temporal, Environmental), each of which have an underlying scoring component.
CVSS Base Metrics
Base Factors represent characteristics of the vulnerability itself. These characteristics do not change over time, and are not dependent on real world exploitability or on compensating factors that an enterprise has put into place to prohibit exploit. Public rankings of severity, such as those listed in NIST’s National Vulnerability Database (NVD) refer exclusively to Base CVSS scores.
The easy availability of Base CVSS scores provides a seductive starting point for patching prioritization, but is of limited use as it does not account for real world exploits, availability of patches, or other environmental or mitigating controls that your organization has put into place.
CVSS Base Metrics are comprised of three subscore elements – Exploitability, Scope, and Impact.
Exploitability – Exploitability metrics are made up of characteristics of the vulnerable component, with Exploitability being made up of four further sub-components.
- Attack Vector – this score varies based on the level of access required to exploit a vulnerability. The score will be higher for exploits that can be executed remotely (i.e. outside of a company’s network) than for exploits that require physical presence (i.e. must have access to a physical port on an appliance or access to a local network inside of a private data center).
- Attack Complexity – this score varies based on the factors outside of the attacker’s control that are required to exploit the vulnerability. The score will be higher for exploits that require additional work on the attacker’s part, such as theft of a shared secret key or a man-in-the-middle attack, than for an attack that requires no such additional effort.
- Privileges Required – this score varies based on the privileges required for the attacker to conduct the exploit. A vulnerability that requires administrative privileges to exploit will have a higher score than an exploit that requires no authentication or escalated privileges on the attacker’s part.
- User Interaction – this score varies based on whether the attacker must recruit either a willing or unwitting participant in order to complete their task. The score will be higher if the attacker can operate autonomously, with no participation from a user.
Scope – Scope relates to whether a vulnerability in one component can propagate to other components. The scope score is higher if propagation is possible. Examples of scope include ability to access and exploit the underlying operating system after exploiting a vulnerability in a software application, or an attacker accessing a backend database after successfully exploiting a vulnerability in a web server.
Impact – Impact focuses on the actual outcome that an attacked can achieve as a result of exploiting the vulnerability in question. Impact metrics are comprised of three sub-metrics – Confidentiality, Integrity, and Availability.
-
- Confidentiality – this score varies on the amount of data that the attacker gains access to. It will be higher if all data on the impacted system is accessible by the attacker, lower if no data is accessible.
-
- Integrity – this score varies based on the ability of the attacker to alter or change data on the impacted system. If complete, or severely consequential modifications to data are possible, this score will be high.
-
- Availability – this score varies based on the loss of availability of the exploited system. The score will be high if the system is no longer accessible or usable for authorized users as a result of the attack.
CVSS Temporal Metrics
CVSS Temporal Metrics are exactly as they sound – metrics related to a vulnerability that change over time. These metrics measure the current exploitability of the vulnerability, as well as the availability of remediating controls, such as a patch. Subcomponents of Temporal Metrics include Exploit Code Maturity, Remediation Level, and Report Confidence.
- Exploit Code Maturity – Until a method exists to exploit a vulnerability, it is relatively benign. As with most software, code available to conduct an exploit can mature, becoming more stable and more widely available over time. As this happens, the score on this subcomponent will increase.
- Remediation Level – When a vulnerability is first discovered, there might not be a patch or other workaround available. Over time, workarounds, temporary fixes, and ultimately official patches become available, lowering the vulnerability score as remediation is improved.
- Report Confidence – Confidence measures the level of validation demonstrating that a vulnerability is both real and exploitable.
CVSS Environmental Metrics
CVSS Environmental Metrics allow the organization to modify the Base CVSS based on Security Requirements and modifications of Base Metrics.
- Security Requirements – Security Requirements characterize the criticality of the asset in question. Mission critical data or assets get a higher score than less important assets. For example, a vulnerability identified in a database of all customer data would get a higher score than a vulnerability identified in a non-privileged user’s workstation.
- Modified Base Metrics – An organization may choose to modify values of the Base CVSS Metrics based on mitigations that they have put into place. For example, “air gapping” a server, or removing any external network connections, will prohibit and attacker from being able to exploit a vulnerability that might otherwise be accessible remotely. The result is that the Attack Vector Base Metric is reduced in this instance.
CVSS Qualitative Ratings
It is sometimes useful, especially for purposes of discussion with less technical stakeholders, to map the 0-10 CVSS scores to qualitative ratings. FIRST maps CVSS scores to these qualitative ratings as follows:
| 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 |
What is the Difference between CVSS and CVE?
CVE stands for Common Vulnerability Enumeration, which is a unique identifier for each vulnerability listed in the NIST NVD. CVSS provides an indication of the severity of each CVE.
The CVE format is as follows:
CVE-[4 Digit Year]-[Sequential Identifier]
For example, the CVE for the Heartbleed vulnerability is: CVE-2014-0160
Which means that it was the 160th vulnerability categorized in the NVD in 2014. Its Base CVSS Score is 7.5 (High).
Limitations of CVSS
As we’ve already discussed, publicly available CVSS scores are Base Scores only. They represent the severity of a vulnerability, but do not reflect the risk that the vulnerability poses to your environment. In other words, CVSS answers the question, “Is this dangerous?”, but not, “Is this dangerous to my company?”
Given the large (and growing) number of vulnerabilities facing the typical organization, effective vulnerability management must account for not only the Base Score, but Temporal and Environmental Factors as well. For this part, FIRST provides the framework, but NIST can’t help you with tailoring your CVSS score to these factors, as they require first-hand knowledge of business criticality of the assets, identification of mitigating controls, use of the asset in question, and current real-world exploitability of the vulnerability. Maximizing efficiency of your security team requires a risk-based approach to vulnerability management that accounts for these factors.
