CVSS stands for The Common Vulnerability Scoring System and is a vendor-agnostic, industry-open standard designed to convey vulnerability severity and help determine urgency and priority of response. CVSS was commissioned by the National Infrastructure Advisory Council, or NIAC, tasked in support of the global Vulnerability Disclosure Framework. It is currently maintained by the Forum of Incident Response and Security Teams, or FIRST.
Let’s start with some learning objectives and an agenda.
After you complete this course, you will know how to:
In this course, you will first learn about Base metrics, Temporal metrics, Environmental metrics, and then move on to CVSS Severity Ratings and Vector String.
From there, you will get to practice working with different kinds of vulnerabilities, culminating in a course project.
And now, please read about how the metrics in CVSS version 3.1 work.
Your first set of tasks will be to evaluate a threat by using CVSS Base metrics, via a simulation of the CVSS version 3.1 calculator. The CVSS calculator implements the formula defined in the CVSS version 3.1 standard, generating scores based on the metric values you enter. You should refer to the standard for details of the metrics to ensure you pick the correct values for a given vulnerability. Hovering your mouse pointer over metric group names, metric names and metric values displays a summary of the information in the standard. This feature is not available on devices with no pointer, such as touchscreen. Also, the calculator is not yet accessible to people who are blind or low-sighted, so we will describe the calculator textually.
The calculator is actually three calculator applications, to determine Base metrics, Temporal metrics, and Environmental metrics.
|Attack Vector (AV)||Network (N), Adjacent (A), Local (L), Physical (P)|
|Attack Complexity (AC)||Low (L), High (H)|
|Privileges Required (PR)||None (N), Low (L), High (H)|
|User Interaction (UI)||None (N), Required (R)|
|Scope (S)||Unchanged (U), Changed (C)|
|Confidentiality (C)||None (N), Low (L), High (H)|
|Integrity (I)||None (N), Low (L), High (H)|
|Availability (A)||None (N), Low (L), High (H)|
|Exploit Code Maturity (E)||Not Defined (X), Unproven (U), Proof-of-Concept (P), Functional (F) High (H)|
|Remediation Level (RL)||Not Defined (X), Official Fix (O), Temporary Fix (T), Workaround (W), Unavailable (U)|
|Report Confidence (RC)||Not Defined (X), Unknown (U), Reasonable (R), Confirmed (C)|
|Confidentiality Requirement (CR)||Not Defined (X), Low (L), Medium (M), High (H)|
|Integrity Requirement (IR)||Not Defined (X), Low (L), Medium (M), High (H)|
|Availability Requirement (AR)||Not Defined (X), Low (L), Medium (M), High (H)|
|Modified Attack Vector (MAV)||Not Defined (X), Network, Adjacent Network, Local, Physical|
|Modified Attack Complexity (MAC)||Not Defined (X), Low, High|
|Modified Privileges Required (MPR)||Not Defined (X), None, Low, High|
|Modified User Interaction (MUI)||Not Defined (X), None, Required|
|Modified Scope (MS)||Not Defined (X), Unchanged, Changed|
|Modified Confidentiality (MC)||Not Defined (X), None, Low, High|
|Modified Integrity (MI)||Not Defined (X), None, Low, High|
|Modified Availability (MA)||Not Defined (X), None, Low, High|
We will introduce the Base metrics using the scenario of a web application that has a vulnerability. The web application requires all users to log in, but it denies access to those on a blacklist of banned users. This blacklist is accessible only to privileged users, and blacklist changes require a separate administrative password. A vulnerability exists in the application, but only in specific non-default configurations. It allows a privileged user to change the blacklist without entry of the administrative password. The vulnerability can be exploited via a malicious HTTP GET request.
Here is the intended normal execution flow:
Here is how the vulnerability allows the following execution flow: It’s the same flow as the one directly previous, but when the server checks the privileges of the requestor:
So, again, previously, once the server identified a privileged user, it issued a request for authorization. In this scenario, the server executes actions.
An attacker with unprivileged access to the web application may trick a user with administrative privileges, for example by creating a support request, into visiting a specially crafted URL; by escaping certain parameters of the GET request in the URL, the attacker may force the software module that manages the request to erroneously bypass the authentication prompt and execute the requested actions without the explicit authorization of the privileged user.
A successful attack allows an attacker to modify only the configuration file that contains the blacklist. The modification of these files may allow the attacker to add arbitrary users to the blacklist file, thus preventing those users from accessing the web application.
We will explain more details of this vulnerability as we introduce each metric. This module will take you through the Base metrics in detail, followed up by Temporal metrics and Environmental metrics, so that you can create a CVSS score for this vulnerability.
Before we get further into the vulnerability, you need to know some key terminology.
The collection of privileges defined by a security authority when granting access to computing resources is the security scope.
The vulnerable component is the thing that is vulnerable, and is typically a software application, module, driver, or possibly a hardware device.
This hypothetical vulnerability is caused by a faulty management of URL requests in the software module of the web application.
Under normal conditions, a privileged user would be prompted with an authentication dialogue for every request passed to the software module. However, in this case the module fails to properly handle all input from privileged users, which may lead to the execution of the requested actions without the prompt of the authentication dialogue.
Here the software module is controlled by the web application. The web application is considered an authorization scope because it implements its own privilege system consisting of users, passwords, and permissions restricting users to specific data. The web application is therefore the part of the overall system that is considered the vulnerable component.
Let’s start with the first Base metric, Attack Vector. This metric reflects the context by which vulnerability exploitation is possible. The Attack Vector metric value, and consequently the Base Score, will be larger the more remote logically, and physically, an attacker can be while exploiting the vulnerable component. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across the Internet is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater score.
If an attacker physically touches or manipulates the hardware of the vulnerable component, Attack Vector is Physical.
When a vulnerability is bound to the network stack, Attack Vector is either Network or Adjacent. If a vulnerability requires user interactions to either download or receive malicious content, such as through USB drives, that is then executed locally, then Attack Vector is Local. An example of this might be a code execution through a file-parsing vulnerability in a PDF reader.
Attack Vector for vulnerabilities exploited via Secure Shell, or SSH, Remote Desktop, VMWare Remote Console, and other remote access methods may be Local or not, depending on how the protocol or application is used as part of the vulnerability.
For example, if a vulnerability is exploited in the SSH protocol itself, such as a remote script execution through a vulnerability in sshd, then Attack Vector is Network or Adjacent.
For another example, if shell access on a system is required to exploit a system vulnerability and SSH is simply the method for obtaining the shell, then Attack Vector is Local.
If the vulnerable system is inside a private but nonrestrictive network behind a Network Address Translation, or NAT, and the attacker has to be on the private network to exploit it, then the Attack Vector is Network. If the attacker needs to be in the same network collision domain, secure domain, or limited administrative domain as the vulnerable system, then the Attack Vector is Adjacent.
Examine the Attack Vector Scoring Rubric. The rubrics are visual devices and we will give the logic descriptions for the rubrics throughout the module in the following bullet-point format.
If the attacker is able to exploit the vulnerable component via the network:
The Network rating says that the vulnerability is exploitable from a remote network, such as across the Internet. By the way, metrics and metric values have an abbreviated form used in the vector string that we'll explain later in the course. For example, Network can be abbreviated as "N".
If the attacker is not able to exploit the vulnerable component via the network, the Adjacent rating states that the vulnerability is limited at the protocol level to a logically adjacent topology such as Bluetooth or Wi-Fi.
If the attacker is unable to exploit the vulnerable component via the network, the next question is, does the attacker require physical access to the target?
Keep in mind that the Base Score increases the farther logically and physically the attacker can be from the target.
The attacker can perform all steps of the attack against the vulnerable web application over a network, so the Attack Vector is rated as Network. A vulnerability exploitable with Adjacent network access would mean the vulnerable component is bound to the network stack, but the attack must be performed from the same shared physical or logical network, that is, an attack is only possible over a Bluetooth network. A vulnerability exploitable with Local access would mean that the vulnerable component is not bound to the network stack, and the attacker's path is via read/write/execute capabilities. A vulnerability exploitable with Physical access would require the attacker to physically touch or manipulate the vulnerable component.
Now let’s talk about Attack Complexity. This metric describes the conditions beyond the attacker's control that must exist to enable them to exploit the vulnerability. Such conditions may require the collection of more information about the target, the presence of certain configuration settings on the target, or significant computational work, such as brute-forcing a secret. Importantly, the assessment of this metric excludes any requirements for user interaction in order to exploit the vulnerability, and such conditions are captured in the User Interaction metric. The Base Score increases the most for the least complex attacks.
Let’s examine the Attack Complexity rubric.
The Base Score is greater when the attack can be performed at will.
In scoring the authentication bypass vulnerability, keep in mind that this vulnerability is triggered by a non-default setting of the web application that allows remote HTTP GET requests to modify a configuration file of the web application that contains a blacklist of users. If a specific configuration is required for an attack to succeed, the Base metrics must be scored assuming that the vulnerable component is in that configuration. Attack Complexity is therefore rated as Low.
Now let’s talk about Privileges Required. This metric describes the level of privileges an attacker must possess before successfully exploiting the vulnerability. This metric is greatest if no privileges are required.
Let’s examine the Privileges Required rubric.
In this case, the Base Score increases as fewer privileges are required.
In scoring the authentication bypass vulnerability, a successful attack requires the attacker to login to the vulnerable web application to send the crafted URL to a privileged user; for example, by creating a support request. This attack would not be possible if the attacker did not have access to the web application prior to attempting the attack. As the attacker only needs an account providing basic user capabilities, Privileges Required is rated as Low.
Privileges Required would be rated as None if the attacker did not need to log in to the web application to perform the attack. It would be rated High if the attacker needed to log in to the web application as a privileged user to perform the attack.
Now let’s talk about User Interaction. This metric captures the requirement for a user, other than the attacker, to participate in the successful compromise of the vulnerable component. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user or user-initiated process must participate in some manner. This metric value is greatest when no user interaction is required.
Let’s examine the User Interaction rubric.
Does the attacker require some other user to perform the action to let an attack unfold?
Here the Base Score is greater when no user interaction is required.
In scoring the authentication bypass vulnerability, a successful attack requires a privileged user to open the malicious URL. As the attack requires an action by a user other than the attacker, User Interaction is rated as Required. User Interaction would be rated as None for a vulnerability where an attack is possible without the involvement of other people.
Now let’s check your learning on the Base metrics by asking a question about the Base metrics.
Take a minute to figure out which of these statements about the Base metrics you’ve learned are true or false.
Here are the answers:
It’s true that Attack Vector reflects the context by which vulnerability exploitation is possible.
Attack Complexity does not describe the level of privileges an attacker must possess before successfully exploiting the vulnerability. This is the description for Privileges Required.
Privileges Required does not describe the conditions beyond the attacker's control that must exist in order to exploit the vulnerability. This is the description for Attack Complexity.
It’s true that User Interaction captures the requirement for a user, other than the attacker, to participate in the successful compromise of the vulnerable component.
Now let’s talk about the Scope metric. When we talk about Scope, we need to examine vulnerable components and impacted components.
What you need to do is consider the authorization scope of both components and determine whether they are different.
Security scopes can be represented graphically, showing the vulnerable components and the impacted components.
Let’s examine the Scope rubric.
Note that the Base Score is greater when systems beyond the vulnerable component are impacted.
To give you some context on the Scope metric, here is how the various Base metrics work together. Exploitability metrics reflect the characteristics of the vulnerable component. They include:
The Scope metric is either:
Impact metrics are scored according to the impacted component, or the thing that suffers the worst outcome in a successful attack. They include:
The Base Score is greater when a scope change has occurred.
Earlier, we determined that our hypothetical vulnerability was caused by a faulty management of URL requests in the software module. This module operates under the control of the web application, which is therefore the vulnerable component.
A successful attack allows the attacker to modify the configuration files of the same web application. Therefore, the web application is also the impacted component.
As the vulnerable component and the impacted component are the same, the Scope is Unchanged. If an alternate vulnerability resulted in an impact to a different security scope, for example, an attack allowed unauthorized actions to be taken directly on the underlying operating system, the Scope would be Changed.
Now let’s check your learning on the Base metrics by asking a question about a different vulnerability to test your understanding of the Scope metric.
Karen works on the computer security incident response team, or CSIRT, for an international bank. She gets an email from a constituent showing that the bank's website is vulnerable to reflected cross-site scripting, or XSS. A successful attack requires an attacker to trick a legitimate bank user into browsing to a specific URL. This URL points to the bank's website, but it contains malicious URL parameters that trigger the vulnerability.
A successful attack could allow the attacker to run malicious code on the legitimate user's web browser. However, the malicious code is only able to access information associated with the bank's vulnerable web site due to Same Origin Policy, or SOP, restrictions in web browsers.
What is the Scope metric value Karen assigns from these four choices?
Answer: The vulnerable component is the web server vulnerable to cross-site scripting, and the impacted component is the victim's browser, so the Scope is Changed. The vulnerable component and the impacted component are not the same thing, so the Scope cannot be Unchanged. Low and High are values assigned to another type of CVSS metric.
Let's return to our original authentication bypass vulnerability, and review: The impacted component in this case, as we established a bit earlier, is the web application.
Let’s talk about Confidentiality Impact. This metric measures the impact to the confidentiality of the information resources managed by a software component due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones. This metric value increases with the degree of loss to the impacted component.
Let’s examine the Confidentiality Impact rubric.
In this case, the Base Score increases with the degree of information disclosed.
In scoring the authentication bypass vulnerability, the Confidentiality Impact is rated None because a successful attack does not allow the attacker to access any information he or she did not already have access to. Remember that the attacker cannot gain full administrative privileges. Confidentiality would be rated as Low if a successful attack allowed the attacker to obtain information that he or she did not already have access to. Confidentiality would be rated High if a successful attack allowed the attacker to access all the information managed by the web application, or access limited data that presents a direct, serious impact on this metric, for example, user passwords that can be used to cause further harm.
Now let’s talk about Integrity Impact. This metric measures the impact to data trustworthiness and veracity resulting from a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. This metric value increases in accordance with the amount of consequence to the impacted component.
Let’s examine the Integrity Impact rubric.
The Base Score increases with the degree of information that can be modified.
In scoring the authentication bypass vulnerability, the Integrity Impact is rated Low because a successful attack allows the attacker to only modify a configuration file that he or she did not already have the ability to change. Again, remember that the attacker cannot gain full administrative privileges. Integrity would be rated as None if a successful attack did not allow the attacker to modify information he or she did not already have the ability to change. Integrity would be rated High if a successful attack allowed the attacker to either modify all data managed by the web application, or modify limited data that presents a direct, serious impact to this metric, for example, passwords that can be used to cause further harm.
Now let’s talk about Availability Impact. This metric measures how the successfully exploited vulnerability affects the availability of impacted component. While the Confidentiality Impact and Integrity Impact metrics apply to the loss of confidentiality or integrity of data, for example, information or files, used by the impacted component, this metric refers to the loss of availability of the impacted component itself, which can include networked services such as web, database, or email. Because availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all affect the availability of an impacted component. This metric value increases with the amount of consequence to the impacted component.
Let’s examine the Availability Impact rubric.
The Base Score increases in accordance with the degree of disruption to availability.
In scoring the authentication bypass vulnerability, the attacker can make the service unreachable to potentially all users by modifying the blacklist configuration file. The Availability Impact is therefore rated as High. Availability would be rated None if a successful attack did not impact the availability of the web application. Availability would be rated Low for vulnerabilities that noticeably reduced performance or caused interruptions in service.
The CVSS version 3.1 Base Score you derive for the vulnerability, based on all the Base metrics, is 6.3. A Base Score of 6.3 is rated as a Medium severity using the Severity Rating system.
Now let’s check your learning on the Base metrics by asking a question about the Confidentiality Impact, Integrity Impact, and Availability Impact metrics.
Pick the statement that is true about Confidentiality Impact, Integrity Impact, and Availability Impact metrics.
Answer: This statement is true and the other two are false: The Confidentiality Impact and Integrity Impact metrics measure, respectively, the loss of confidentiality and integrity of data used by the impacted component. The Availability Impact metric measures the loss of availability of the impacted component itself.
Let’s review: We have just talked about the Base Metric group, which represents the intrinsic characteristics of a vulnerability that are constant over time and across user environments. There are two other metric groups we will cover now:
This module will focus on the Temporal and Environmental metrics.