A vulnerability is some aspect of a system functionality, architecture, or configuration that enables cybercriminals to execute attacks, exploit services, and steal data. There are many available methods for ranking vulnerabilities to establish their level of risk. The most widely used industry standard for this purpose is the Common Vulnerability Scoring System (CVSS).
What is the Common Vulnerability Scoring System?
There are many different ways to evaluate the severity of a vulnerability. One way is the Common Vulnerability Scoring System (CVSS), a set of open standards for assigning a severity score to a vulnerability. Scores vary from 0.0 to 10.0, with higher numbers representing a higher degree of vulnerability severity.
CVSS scores are used by the National Vulnerability Database (NVD), Computer Emergency Response Teams (CERT), and others to evaluate the impact of vulnerabilities. Many security companies have established their own scoring systems, as well. There are three CVSS versions, the most recent version is CVSSv3.1, released in 2019.
What Causes Vulnerabilities?
Vulnerabilities can be created as a result of human error or incorrectly applied security measures. Hackers use vulnerabilities to exploit a security blindspot and then launch attacks. For example, hackers can gain access to root credentials and cause an outage or steal corporate data. Typically, each vulnerability provides hackers with different types of exploits. Many of these vulnerabilities are a result of human error, but some are created by hackers.
Here is a brief review of the most common errors and attacks that often create vulnerabilities:
- Complexity—complex systems increase the probability of a failure due to misconfiguration or unauthorized access.
- Familiarity—common code, operating systems and hardware increase the chances that an attacker can find information about known vulnerabilities.
- Connectivity—connected devices often have a higher chance of vulnerability because of weak security measures.
- Operating system flaws—operating systems can have flaws, just like any software. Vulnerable operating systems usually give full access to all users. As a result, malware, and viruses can execute malicious commands.
- Software bugs—programmers can intentionally or accidentally create a bug that makes the entire software vulnerable.
- People—to gain access to credentials and sensitive and corporate data, hackers use methods that involve social engineering and insider threats attacks. These techniques trick, blackmail, or manipulate human resources into revealing information.
How CVSS Scoring Works
CVSS consists of three general metric groups—base, temporal, and environmental. Each of these metrics are composed of different elements, as explained in further detail below.
Base Score
The base score metric represents a ranking of some of the native properties of a vulnerability. Native properties do not change over time, and they are not dependent on the environment of the vulnerability. The base score is based on a formula that takes into account two subscores—the impact subscore, and the exploitability subscore.
Exploitability subscore
The exploitability subscore reflects the ease and technical means with which an attacker can exploit a vulnerability. CVSS uses specific metrics to rank the severity of a vulnerability:
- Attack vector (AV)—describes the accessibility of an attacker to the vulnerability. A vulnerability that can be accessed through a local network will receive a higher AV score. A vulnerability that requires an attacker to be physically present to execute an attack will receive lower scores.
- Attack complexity (AC)—defines the conditions that can prevent an exploitation of the vulnerability. A high score indicates that the attacker may need to collect additional information on a particular target before executing an attack. A low score means that an attacker can frequently exploit a vulnerability without any special conditions.
- Privileges required (PR)—describes the level of privileges an attacker needs to execute an attack. A high score indicates that the attack might only affect files and settings at a basic user level. Low scores indicate that the attacker needs administrative privileges to exploit the vulnerability.
- User interaction (UI)—defines whether the attacker needs another user to take part in the attack. This score is binary, either the interaction required or it isn’t.
Impact subscore
An impact subscore defines the impact of a successful exploit. The most important measure of impact is the authorization scope (S) metric. This metric indicates the impact of an exploited vulnerability on other resources or components. The S metric is binary, which means either a vulnerability enables the attacker to impact systems with different privileges, or it impacts only the resources at the same level of privilege. When the scope measure is not available, the impact metric reflects the following three values:
- Confidentiality (C)—determines the level of authority of an exploited vulnerability. An exploit can result in a low degree of confidentiality loss, where some indirect access to restricted information is available. An exploit can also result in a high degree of loss that leads to serious manipulation of sensitive information. For example, access to an administrator’s password and username.
- Integrity (I)—defines the level of data corruption after an attack. A low score indicates that some data was modified but there are no significant consequences. A high score indicates a complete loss of data protection, or the modified data would significantly impact the functionality of the vulnerable system.
- Availability (A)—a measure of the loss of availability to the services or resources of the impacted component. Low scores indicate that there is minimal impact, or no impact at all. High scores indicate that there is a persistent disruption, or a complete loss of access.
Temporal Score
Temporal score metrics measure the current state of code availability, exploit techniques, and the existence of any patches or alternative solutions.
- Exploit code maturity (E)—reflects the availability of techniques or code an attacker can use to exploit the vulnerability. The score changes over time.
- Remediation level (RL)—measures the level of available remediation for the exploited vulnerability.
- Report confidence (RC)—defines the degree of the credibility of a vulnerability report. Vulnerabilities can be identified by third parties but not recognized by the component’s official vendor. Vulnerabilities can also be recognized but their cause will remain unknown.
Environmental Metrics
Environmental metrics enable you to customize the CVSS score based on the importance of the affected resources. The score is measured in terms of the existence of alternative security controls, CIA (integrity, confidentiality, and availability). Environmental scores are the modified version of base metrics. The metric values are based on the component placement within organizational infrastructure:
- Collateral damage potential (CDP)—reflects the potential for loss of physical assets due to damage or theft, or the loss of revenue and productivity.
- Target distribution (TD)—the number of vulnerable systems in your user’s environment.
- Confidentiality requirement (CR)—the level of impact of confidentiality loss when a vulnerability is exploited on this asset.
- Integrity requirement (IR)—determines the level of impact of the integrity loss when a vulnerability is successfully exploited.
- Availability requirement (AR)—measures the level of impact to the asset’s availability.
Conclusion
CVSS consists of three metric groups, base, environmental, and temporal. The base score measures the severity of a vulnerability according to its native features. The temporal metrics modify the base score based on factors that change over time, like the availability of exploit. The environmental metrics adjust the temporal and base metrics to a specific computing environment. The benefits of CVSS include the provision of a standardized platform and vendor agnostic vulnerability scoring system.
