CVSS: Scoring IT Vulnerabilities

From the moment we enter the education system, we are used to being evaluated. But evaluation is not limited to the educational sphere; we are evaluated in almost all areas of our lives, whether formally or informally. In the field of cybersecurity services, the assessment of vulnerabilities in IT environments is key, to help correct detected problems and prevent attackers from using these vulnerabilities to compromise software and hardware security. For this reason, the Common Vulnerability Scoring System (CVSS) has become an open framework, accepted as a worldwide standard, for scoring IT vulnerabilities.

The origin of CVSS dates back to the dawn of the digitalization of the world. In 1990, following the catastrophic consequences of an Internet worm, the Forum of Incident Response and Security Teams (FIRST) was set up. Its goal was and still is to contribute to a safer Internet for all by managing security vulnerabilities and responding to ongoing attacks.

To fulfill its mission, this forum, which includes security teams from administrations, companies, and researchers from all over the world, created the CVSS in 2004. A standard system for scoring IT vulnerabilities and analyzing the impact they would have on an organization’s assets.

The latest version of CVSS, 3.1., saw the light of day in 2019 confirming the status of this framework and the importance it has for developers and cybersecurity services around the globe. In the following, we will analyze how it is used and its usefulness.

1. Risk metrics

As we said, CVSS is essentially a scoring system that makes it possible to standardize the evaluation of the impact of vulnerabilities. This system is based on three main groups of metrics: base, temporal, and environment.

1.1. Base Metrics

This group includes metrics that refer to the intrinsic characteristics of a vulnerability that are constant over time and across all user environments. These are, in turn, grouped into two subcategories: Exploitation and Impact.

1.1.1. Vulnerability Exploitation

Exploitation metrics refer to both the difficulty of exploiting a vulnerability and the technical means that can be employed to do so. CVSS includes four Exploitation metrics:

• Attack Vector. This metric focuses on the context in which exploitation of the vulnerability being assessed can occur. It is not the same that a vulnerability can be exploited through the network, as it is that such exploitation can only be carried out if you have physical access to the component you want to attack.
• Attack complexity. Describes the conditions that must be in place for it to be possible to exploit the vulnerability. Such as the collection of more information about the target or the existence of specific conditions.
• Required privileges. Focuses on the level of privileges an attacker must possess to successfully exploit the analyzed vulnerability.
• User interaction. This metric determines whether the vulnerability being analyzed can be exploited solely by the action of the attacker or whether another user must participate.

Also, starting with version 3, a new metric has been introduced: Scope. This feature complements the evaluation of the previous metrics. Its purpose is to determine whether a vulnerability in a vulnerable component affects the resources of that component beyond its security scope. If this happens, a change of scope occurs and the base score will be higher.

1.1.2. Vulnerability Impact

While the Impact metrics synthesize the consequences of successful exploitation of the impacted component, be it an application, a device, or a network resource. These metrics are:

• Confidentiality. This metric focuses on the potential impact of access to the information managed by the system. If a vulnerability is exploited, would confidentiality be lost?
• Integrity. Measures how the exploitation of a vulnerability impacts its integrity, i.e. whether there can be any type of manipulation of the information managed by the information system.
• Availability. This metric measures the availability of the impacted component when the vulnerability is successfully exploited. The first two metrics focus on the loss or not of confidentiality and integrity of the data used by the component that has been affected. The latter focuses on the availability of the component itself, i.e. the accessibility of information resources.

It should be noted that, if there has been a change in the security scope, the analyst must study confidentiality, integrity, and availability not only in the vulnerable component but also in the affected component, depending on which of the two suffers the most severe result.

1.2. Temporal Metrics

This group of metrics reflects the characteristics of a vulnerability that may change over time, but not with environments. Thus, they measure the current state of exploitation techniques. For example, if developers create an official patch for an application, the vulnerability level and thus the CVSS score would be reduced. These metrics are:

• Exploitability. This metric measures the probability of a vulnerability being attacked. It is based on the current state of exploitation techniques, the availability of exploit code, or active exploitation. Thus, if the code is publicly available, the number of potential attackers is greatly increased.
• Remediation level. The typical vulnerability is unpatched when initially published. However, if patches are developed or updates have been deployed the level of remediation increases, and thus the severity of the vulnerability decreases. So this temporal metric serves to reduce the IT vulnerability score.
• Confidence report. This metric studies the level of certainty that the vulnerability exists, as well as the credibility of the known technical details. The higher the level of certainty that the vulnerability exists, the greater the urgency to fix it.

1.3. Environment metrics

Environment metrics refer to the characteristics of a vulnerability that are important for a particular environment given its potential criticality in the context of an organization. These include the presence or absence of security controls that can mitigate the consequences of a successful attack. As well as the impact on the confidentiality, integrity, and availability of information.

These metrics are used to customize the CVSS score of an IT vulnerability, depending on the importance of the affected asset to the organization. For example, if the organization is an e-commerce platform, and the exploitation of the vulnerability affects the availability of the platform, the impact on the business will be major. Hence, the analyst will give it greater weight than confidentiality or integrity.

These metrics allow the analyst to override the base metrics, depending on the specificities of the organization and the specific characteristics of the environment.

2. Calculating the CVSS score: values, vectors, and equations

2.1. CVSS values and headings

Each of the metrics described above is evaluated using predefined CVSS values. For example, the first metric, Attack Vector, has four possible values: Network (N), Adjacent (A), Local (L), and Physical (P). The value of this metric will be higher the more remote an attacker can be. Since, if a vulnerability can be exploited from the other side of the network, it is exposed to a greater number of possible attacks than if physical access to a device is required. In numerical terms, Network (N) is rated at 0.85 points, while Physical (P) is rated at only 0.2.

The existence of a rubric for each metric facilitates the task of analysts and is fundamental not only for scoring IT vulnerabilities but also for systematizing the way they are analyzed.

2.2. CVSS vectors

As we have noted, each value has a note associated with it, but also a letter that identifies it. This is essential to create the vectors. These vectors represent graphically and succinctly all the values of the CVSS metrics.

In the CVSS specification document itself, the following vector example is given:
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N

If we translate it we find the following information about the vulnerability, regarding the base metrics: Attack vector: Network; Attack complexity: Low; Privileges required: High; User interaction: None; Scope: No change; Confidentiality: Low; Integrity: Low; Availability: None.

In the case of adding temporal or environment metrics, they would be subsequently included in the vector.

This vector not only systematizes and summarizes the entire analysis but also shows the characteristics of the vulnerability simply and transparently.

2.3. Essential metrics

In the example we have just illustrated, the temporal and environment metrics were not included. This is because these metrics are not indispensable when analyzing a vulnerability using CVSS.

In other words, the base metrics are mandatory and the temporal and environment metrics are optional. Therefore, the analyst applying the metrics must decide whether to include them in his analysis or not, depending on the characteristics of the vulnerability and the component.

2.4. CVSS Calculator

Obtaining the final score for IT vulnerabilities is not the result of a mere sum, but CVSS incorporates in its specifications the formulas to be used to calculate the score.

The calculations of these equations can be automated. For example, the US National Institute of Standards and Technology (NIST) as well as FIRST make available to analysts and developers a calculator to obtain a vulnerability score. The user only has to enter the value of each metric and the application performs the calculation automatically, using CVSS formulas.

Thus, a vulnerability X represented by a CVSS:3.1./AV:A/AC:H/PR:L/UI:R/S:C/C:H/I:L/A:L vector, would get a score of 6.8.

Whereas in the example above: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/S:U/C:L/I:L/A:N, the score would be 3.8.

If some of the temporal and environment metrics were included, the score would be altered. Thus, in the first vulnerability case, whose score is 6.8, after applying the base metrics, it would rise to 7.5, if the availability impact modification metric (MA) is added and rated high (H).

3. Vulnerability severity level

As in the education system, the numerical score translates into words. If obtaining a 9-10 in a subject is translated as an A, achieving a score between 9-10 in the analysis of a vulnerability means that the severity of the vulnerability is critical. That is, the impact of its exploitation can be devastating to the platform that is affected.

At the opposite end of the spectrum are vulnerabilities scored 0 (zero impact level) and between 0.1 and 3.9 (low severity level). Between 4 and 6.9 the severity of the vulnerability is medium, while between 7 and 8.9 it is high.

If we go back to the examples in the previous section, we would find that the first vulnerability would have a medium severity level, while the vulnerability given as an example by CVSS would be below.

3.1. CVE: the systematization of public vulnerabilities

The MITRE corporation collects and discloses publicly known cybersecurity vulnerabilities. The CVE, or Common Vulnerabilities and Exposures, is a constantly updated dictionary that records vulnerabilities as they become known. This has enabled it to become a standard in the field of cybersecurity, helping to ensure that the naming of vulnerabilities is homogeneous and systematized.

To get an idea of the immense number of existing vulnerabilities, all of them can be consulted on this website, filtering them by their CVSS score. There are almost 20,000 critical vulnerabilities, i.e. those with a score of more than 9 (11.20% of the total). For example, vulnerability CVE-2022-30525 has a score of 10 points in the CVSS framework.

Thus, CVSS is not only a particularly useful working tool but also systematizes the detection of vulnerabilities that can have serious consequences for organizations and users. In addition, when combined with another standard such as CVE, we can obtain a complete overview of existing vulnerabilities.

4. Facilitate vulnerability management

Thanks to CVSS, developers and cybersecurity analysts can use the same standards when assessing IT vulnerabilities. This makes it much easier to manage these vulnerabilities. But, in addition, by scoring them, it is possible to prioritize the resources that the organization must employ to remedy the various vulnerabilities that have become apparent in its software and hardware.

No organization has unlimited financial, human, technical, and temporal resources. Therefore, it is essential to plan how those resources will be used when remediating vulnerabilities and securing applications and devices.

CVSS offers a framework that facilitates decision-making and the design of a working strategy. The greater the damage caused by the vulnerability, if it is successfully exploited, the more urgent it is for the organization to put a stop to it.

In addition to contributing to the organization of cybersecurity work and the implementation of rapid responses, CVSS and its system for scoring IT vulnerabilities are key to raising awareness within organizations.

4.1. Going to market with security guarantees

In an increasingly fast-paced world with an extremely competitive global market, concepts such as Time to Market have become key. IT development times have been reduced, to get applications and devices to market as soon as possible.

However, this cannot mean neglecting security and opening the door to IT vulnerabilities. Even more so if these vulnerabilities are critical, such as those that score above 9 in CVSS.

The consequences of suffering a serious attack can be devastating for a company. Both in economic and legal terms in the short term. But also in terms of its prestige and reputation in the long term.

CVSS thus makes visible a reality that is sometimes overlooked: cybersecurity is a strategic issue. Securing applications and devices is not just another element to be taken into account when defining business strategy, but must be a master pillar of it.

In short, CVSS has become a standard for analyzing vulnerabilities affecting software and hardware worldwide. Helping cybersecurity analysts to study them in detail and assess their level of severity through metrics and rubrics. CVSS does not focus on the risk of vulnerabilities being exploited, but on the severity of the consequences, this can generate.

All this has made the CVSS framework a key ally in the detection, analysis, and mitigation of vulnerabilities in applications and devices.