Mt V3.0

0 views

Skip to first unread message

Rosalyn Pomposo

unread,

Aug 3, 2024, 10:21:30 AM8/3/24

to celbespmeder

JoinDetails about FIRST membership and joining as a full member or liaison.LearnTraining and workshop opportunities, and details about the FIRST learning platform.ParticipateRead about upcoming events, SIGs, and know what is going on.

This guide supplements the formal CVSS v3.0 specification document by providing additional information, highlighting relevant changes from v2.0, as well as providing scoring guidance and a scoring rubric.

The Common Vulnerability Scoring System (CVSS) provides a way to capture the principal characteristics of a vulnerability, and produce a numerical score reflecting its severity, as well as a textual representation of that score. The numerical score can then be translated into a qualitative representation (such as low, medium, high, and critical) to help organizations properly assess and prioritize their vulnerability management processes.

Since its initial release in 2004, CVSS has enjoyed widespread adoption. In September 2007, CVSS v2.0 was adopted as part of the Payment Card Industry Data Security Standard (PCI DSS). In order to comply with PCI DSS, merchants processing credit cards must demonstrate that none of their computing systems has a vulnerability with a CVSS score greater than or equal to 4.0. In 2007 NIST included CVSS v2.0 as part of their Security Content Automation Protocol (SCAP).[1] In April 2011, CVSS v2.0 was formally adopted as an international standard for scoring vulnerabilities (ITU-T X.1521).[2]

CVSS v2.0 presented difficulties for vendors when scoring vulnerabilities that would fully compromise their software, but only partially affect the host operating system. In v2.0 vulnerabilities are scored relative to the host operating system, which led one application vendor to adopt a "Partial+" impact metric convention.[3] CVSS v3.0 addresses this issue with updates to where the impact metrics are scored and a new metric called Scope (discussed further below). Therefore, an important conceptual change in CVSS v3.0 is the ability to score vulnerabilities that exist in one software component (that we refer to formally as the vulnerable component) but which impact a separate software, hardware, or networking component (that we refer to formally as the impacted component), as illustrated in Figure 1.[4]

For example, consider a vulnerability in a virtual machine that compromises the host operating system. The vulnerable component is the virtual machine, while the impacted component is the host operating system. Because these two components independently manage privileges to computing resources, they therefore represent separate (authorization) authorities. In Figure 1, the virtual machine is managed by "Authority A," while the host OS is managed by "Authority B." When two authorities are involved in a vulnerability exploit, CVSS considers that a scope change has occurred. This condition is captured by the new metric, Scope.

As depicted in Figure 1, when scoring vulnerabilities in CVSS v3.0, the Exploitability metrics are scored relative to the vulnerable component. That is, they are scored by considering the component that suffers the coding flaw. On the other hand, the Impact metrics are scored relative to the impacted component. In some cases, the vulnerable component may be the same as the impacted component, in which case, no scope change has occurred. However, in other cases, there may be an impact to the vulnerable component, as well as to the impacted component. In these cases, a scope change has occurred, and the Confidentiality, Integrity and Availability Impact metrics should reflect the impact to either the vulnerable component, or the impacted component, whichever is most severe.

In the case of a vulnerability that allows the theft of a password file, while there may be subsequent steps the attacker takes to commit unauthorized account access, the most direct outcome is a loss of confidentiality of the local system file. As such, there would be no scope change. However, in the case of a vulnerability that allows a router's ARP table to be overwritten by an attacker, there are two impacts. First, to the router's system file (Integrity impact to the vulnerable component), and second, to those Internet services served by the router (Availability impact to affected systems). Because the score should reflect the most severe outcome, the impact metric score may reflect either the Integrity loss to the vulnerable component, or the Availability loss to the Internet services, whichever is more severe.[5]

The Access Vector (from v2.0) has been renamed to Attack Vector, but still generally reflects the "remoteness" of the attacker relative to the vulnerable component. That is, the more remote an attacker is to the vulnerable component (in terms of logical and physical network distance), the greater the Base score will be. Further, this metric now distinguishes between local attacks which require local system access (such as with an attack against a desktop application) and physical attacks which require physical access to the platform in order to exploit a vulnerability (such as with a firewire, USB, or jailbreaking attack).

Access Complexity (from v2.0) conflated two issues: any software, hardware, or networking condition beyond the attacker's control that must exist or occur in order for the vulnerability to be successfully exploited (for example a software race condition, or application configuration), and the requirement for human interaction (for example, requiring a user execute a malicious executable). Therefore, Access Complexity has been separated into two metrics, Attack Complexity (which addresses the former condition), and User Interaction (which addresses the latter condition).

The new metric, Privileges Required, replaces the Authentication metric of v2.0. Instead of measuring the number of times an attacker must separately authenticate to a system, Privileges Required captures the level of access required for a successful attack. Specifically, the metric values High, Low, and None reflect the privileges required by an attacker in order to exploit the vulnerability.

The Confidentiality, Integrity and Availability impact metric values from v2.0 of None, Partial, and Complete have been replaced with None, Low, and High. Rather than representing the overall percentage (proportion) of the systems impacted by an attack, the new metric values reflect the overall degree of impact caused by an attack. For example, while the Heartbleed [6] vulnerability only caused a loss to a small amount of information, the impact was quite severe. In CVSS v2.0, this would have been scored as Partial, while in CVSS v3.0, this is appropriately scored as High.

Additionally, in the example above, the impact metrics now reflect the consequence to the impacted component. And the impacted component may or may not be the same as the component that possesses the vulnerability being exploited.

The Environmental metrics Target Distribution and Collateral Damage Potential have been replaced by Modified factors which accommodates mitigating controls or control weaknesses that may exist within the user's environment that could reduce or raise the impact of a successfully exploited vulnerability.

Some organizations created systems to map CVSS v2.0 Base scores to qualitative ratings. CVSS v3.0 now provides a standard mapping from numeric scores to the severity rating terms None, Low, Medium, High and Critical, as explained in the CVSS v3.0 specification document. The use of these qualitative severity ratings is optional, and there is no requirement to include them when publishing CVSS scores.

Organizations using CVSS v3.0 scores that wish to use an alternate severity rating system are asked to use different rating terms or to clearly state that their ratings do not comply with the CVSS v3.0 specification, to avoid confusion.

An important consequence of these changes is that v2.0 and v3.0 scores may not always be comparable. For example, a vulnerable application that could result in its complete compromise would have been scored in v2.0 with Confidentiality, Integrity and Availability impact metric values of Partial. Whereas in v3.0, this same vulnerability would now be scored with the equivalent Confidentiality, Integrity and Availability impact metric values of High.

When understanding when to score the impact of vulnerabilities, analysts should constrain impacts to a reasonable final impact which they are confident an attacker is able to achieve. Ability to cause this impact should be supported by the Exploitability sub score as a minimum, but may also include details from the vulnerability's description. For example, consider the following two vulnerabilities:

In vulnerability 1, a remote, unauthenticated attacker can send a trivial, crafted request to a web server which causes the web server to disclose the plaintext password of the root (administrator) account. The analyst only knows from the Exploitability sub score metrics and the vulnerability description that the attacker has access to send a crafted request to the web server in order to exploit the vulnerability. Impact should stop there; while an attacker may be able to use these credentials to later execute code as the administrator, it is not known that the attacker has access to a login prompt or method to execute commands with those credentials. Gaining access to this password represents a direct, serious loss of Confidentiality only:Base score: 7.5 [CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N].

In vulnerability 2, a local, low-privileged user can send a trivial, crafted request to the operating system which causes it to disclose the plaintext password of the root (administrator) account. The analyst knows from the Exploitability sub score metrics and the vulnerability description that the attacker has access to the operating system, and can log in as a local, low privileged attacker. Gaining access to this password represents a direct, serious loss of Confidentiality, Integrity, and Availability because the analyst can reasonably issue commands as the root / administrator account (assume that the attacker could log out from her own account and log back in as root):Base score: 7.8 [CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H].