Mastering CVSS version 3.0, Elearning Course Transcript

Module 1: CVSS Elearning Course Introduction

Welcome to the elearning course on CVSS.

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:

  • Describe the CVSS version 3.0 metrics and their importance in CVSS scoring;
  • Identify vulnerable and impacted components and establish their importance in CVSS scoring; and
  • Use the CVSS calculator to evaluate different types of vulnerabilities. Let’s begin.

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.

Module 2 (Optional): CVSS v2.0 to CVSS v3.0

Here’s some background on the move from CVSS version 2.0 to CVSS version 3.0.

CVSS version 3.0 was released in June 2015 with the numerical formulas updated to incorporate the new metrics while retaining the existing scoring range of 0 to 10.

  1. CVSS version 3.0 defined new textual severity ratings of None, or 0, Low, or 0.1 to 3.9, Medium, or 4.0 to 6.9, High, or 7.0 to 8.9, and Critical, or 9.0 to 10.0.
  2. CVSS version 3.0 added the new metrics User Interaction, or UI, and Privileges Required, or PR, to help distinguish vulnerabilities that require user interaction or user or administrator privileges to be exploited. Previously, these concepts were part of the Access Complexity metric of CVSS version 2.0.
  3. CVSS version 3.0 introduced the Scope, or S, metric, which was designed to make clear which vulnerabilities may be exploited and then used to attack other parts of a system or network.

Here is more detail about the change from CVSS version 2.0 to CVSS version 3.0:

CVSS version 3.0 updated the Confidentiality, Integrity and Availability, or C, I, and A, metrics to have scores consisting of None, Low, or High, which allows more flexibility in determining the impact of a vulnerability on those metrics.

  1. CVSS version 3.0 renamed the metric Access Complexity to Attack Complexity, or AC, to make clear that access privileges were moved to a separate metric.
  2. CVSS version 3.0 includes a new metric value of Physical, or P, in Attack Vector, or AV, to describe vulnerabilities that require physical access to the device or system.
  3. CVSS version 3.0 revamped the Environmental Metrics of CVSS version 2.0 to reflect differences within an organization or company compared to the world as a whole with new metrics added to capture the importance of Confidentiality, Integrity, and Availability to a specific environment.
  4. Keep in mind that CVSS version 2.0 and version 3.0 scores may not always be comparable.

And now, please read about how the metrics in CVSS version 3.0 work.

Module 3, Part 1: Working with CVSS v3.0 Base Metrics

First, let’s examine how to work with Base Metrics in CVSS version 3.0.

Your first set of tasks will be to evaluate a threat by using CVSS Base Metrics, via a simulation of the CVSS version 3.0 calculator. The CVSS calculator implements the formula defined in the CVSS version 3.0 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.

Base Metric calculator buttons are listed below by Metric and Value.

Metric Values
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)

Temporal Metric calculator buttons are listed below by Metric and Value.

Metric Values
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)

Environmental Metric calculator buttons are listed below by Metric and Value.

Metric Values
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

Let's define some terminology we need, and then go through the metrics one by one.

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:

  1. The GET request is made to the server with actions to be performed only on the web application configuration file containing the list of blacklisted users.
  2. The server checks the requestor’s privileges.
    • If the requestor is not a privileged user, then the server discards the request.
    • If the requestor is a privileged user, the server generates an authorization prompt. If the request is authorized, the server executes the actions specified in step 1. If it is not, the request is discarded.

Here is how the vulnerability allows the following execution flow: It’s the same flow as the one directly previous, but the 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 computing authority when granting access to computing resources is the authorization 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.

Examine the Attack Vector Scoring Rubric. We will use rubrics like this throughout this module. The rubrics are visual devices and we will give the logic descriptions for the rubrics here.

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. Note that this excludes user interaction.

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. As a successful attack requires the pre-existence of certain system configuration settings that are not set by default, the conditions for a successful attack are considered to be beyond the attacker’s control. Attack Complexity is therefore rated as High.

The Attack Complexity would be rated as Low if the vulnerable configuration was the default one in this example.

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.

Module 3, Part 2: Working with CVSS v3.0 Base Metrics

Now let’s talk about the Scope metric. When we talk about Scope, we need to examine vulnerable components and impacted components.

Authorization 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 the impact affects systems beyond the vulnerable component.

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 authorization 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 the integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. This metric value increases 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, such as a networked service, for example, web, database, or email. Since 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 with the degree of resource availability affected.

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.0 Base Score you derive for the vulnerability, based on all the Base Metrics, is 5.4. A Base Score of 5.4 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 the impacted component itself. The Availability Impact metric measures the loss of availability of the impacted component’s data.

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:

  1. The Temporal Metric group reflects the characteristics of a vulnerability that may change over time but not across user environments.
  2. The Environmental Metric group represents the characteristics of a vulnerability that are relevant and unique to a particular user’s environment.

The Temporal Metrics measure the current state of exploit techniques or code availability, the existence of any patches or workarounds, and the confidence that one has in the description of a vulnerability.

Environmental Metrics enable the analyst to customize the CVSS score depending on the importance of the affected IT asset to a user's organization, measured in terms of complementary/alternative security controls in place, Confidentiality, Integrity, and Availability. Environmental Metrics are the modified equivalent of Base Metrics and are assigned values based on the component placement in an organization’s infrastructure.

CVSS version 3.0 also works with:

Module 4 (Optional): CVSS v3.0 Temporal Metrics, Environmental Metrics, and Vector String

Let’s examine Temporal Metrics, Environmental Metrics, and Vector String in a little more detail.

Let’s look briefly at the three main groups of CVSS version 3.0 metrics. The Base Metric group represents the intrinsic characteristics of a vulnerability that are constant over time and across user environments.

  1. The Temporal Metric group reflects the characteristics of a vulnerability that may change over time but not across user environments.
  2. The Environmental Metric group represents the characteristics of a vulnerability that are relevant and unique to a particular user’s environment.

This module will focus on the Temporal and Environmental Metrics.

First, let’s examine Temporal Metrics. The Temporal Metrics measure the current state of exploit techniques or code availability, the existence of any patches or workarounds, and the confidence that one has in the description of a vulnerability.

Temporal Metrics are expected to change over time and may need to be adjusted as information and patches become available.

All Temporal Metrics have a default value of Not Defined, which is used when you do not have sufficient information to choose a specific value, or do not wish to use the metric. Selecting Not Defined for a metric produces the same score as selecting the worst case value for the metric, for example, the value that leads to the highest score. The Temporal Score defaults to the same score as the Base Score, and selecting non-default values reduces the score. The Temporal Score can never exceed the Base Score.

Exploit Code Maturity measures the likelihood of the vulnerability being exploited, and is typically based on the current state of exploit techniques, exploit code availability, or active, "in-situ" exploitation. Public availability of an easy-to-use exploit code increases the number of potential attackers by including those who are unskilled, thereby increasing the severity of the vulnerability. The available exploit code may progress from a proof-of-concept demonstration to an exploit code that is successful in exploiting the vulnerability consistently. In severe cases, it may be delivered as the payload of a network-based worm or virus or other automated attack tools.

In scoring the authentication bypass vulnerability, you discover that a Proof- of-Concept exploit code is available, but is incomplete and cannot be used to perform a practical attack without significant enhancements made by a skilled coder. We choose an Exploit Code Maturity of Proof-of-Concept.

A value of Not Defined would not influence the score. A High value would mean that functional autonomous code exists, or no exploit is required, or manual trigger, and details are widely available. A value of Functional would mean an exploit code is available that works in most situations where the vulnerability exists. A value of Unproven would mean no exploit code is available, or an exploit is theoretical.

The Remediation Level of a vulnerability is an important factor for prioritization. The typical vulnerability is unpatched when initially published. Workarounds or hotfixes may offer interim remediation until an official patch or upgrade is issued. Each of these respective stages adjusts the Temporal Score downward, reflecting the decreasing urgency as remediation becomes final. The less official and permanent a fix, the higher the vulnerability score.

In scoring the authentication bypass vulnerability, you discover that the vendor of the web application software has released a temporary fix that the vendor suggests is used until they release a complete fix. We choose a Remediation Level of Temporary Fix.

A value of Not Defined would not influence the score.

A value of Unavailable would mean there is either no solution available or it is impossible to apply. A value of Workaround means there is an unofficial, non-vendor solution available. A value of Official Fix would mean that a complete vendor solution is available.

Report Confidence measures the degree of confidence in the existence of the vulnerability and the credibility of the known technical details. Sometimes only the existence of vulnerabilities is publicized, but without specific details. For example, an impact may be recognized as undesirable, but the root cause may not be known. The vulnerability may later be corroborated by research or through acknowledgement by the author or vendor of the affected technology. The urgency of a vulnerability is higher when a vulnerability is known to exist with certainty, and the more a vulnerability is validated by the vendor or other reputable sources, the higher the score.

In scoring the authentication bypass vulnerability, you discover that significant details are published, but researchers either do not have full confidence in the root cause, or do not have access to source code to fully confirm all of the interactions that may lead to the result. We choose a Report Confidence of Reasonable.

A value of Not Defined would not influence the score. A value of Unknown would mean that there are inconsistent reports from security researchers, some of whom believe this vulnerability exists, and others who cannot reproduce it at all. A value of Confirmed would mean that detailed reports exist, or functional reproduction is possible, and functional exploits may provide this. Source code would be available to independently verify the assertions of the research, or the author or vendor of the affected code has confirmed the presence of the vulnerability.

The Temporal Score you generate is 4.7, which is rated as a Medium severity using the Severity Rating system.

Environmental Metrics enable the analyst to customize the CVSS score depending on the importance of the affected IT asset to a user's organization, measured in terms of complementary/alternative security controls in place, and relative importance of Confidentiality, Integrity and Availability. The metrics are the modified equivalent of Base Metrics and are assigned values based on the component placement in the organizational infrastructure.

The first three metrics allow the relative importance of Confidentiality, Integrity and Availability to be altered. By default, all three have equal weight, but particular environments may place more importance on maintaining the confidentiality or integrity of information, or on the availability of the service. Setting the Confidentiality Requirement to High increases the impact that different Confidentiality values have on the Environmental Score. This is also the case for the Integrity Requirement and Availability Requirement metrics.

The full effect on the Environmental Score is determined by the corresponding Modified Base Impact metrics. That is, these metrics modify the Environmental Score by reweighting the Modified Confidentiality, Integrity, and Availability impact metrics.

We will define a specific environment which is affected by the authentication bypass vulnerability we are using as an example, so that we can calculate an Environmental Score. You work for an open source software development company that employs the web application to manage code commits and ticket requests. The platform allows both employees and external users contributing to the project to add requests.

For your company it is vital that the platform remains available in order to allow users to commit new code and review existing code. Similarly, the integrity of the configuration file containing a blacklist of users is important as a change may compromise the normal operation of the service. Finally, the Confidentiality of the blacklist configuration file is considered non important for the normal operation of your company.

We would score the first three Environmental Metrics as:

Although this example results in one Low, one Medium and one High value, any combination of values is valid. Not Defined is the default value and produces the same score as choosing Medium.

The remaining Environmental Metrics allow the modification of one or more Base Metrics. This is useful if a particular system changes characteristics of the vulnerability by implementing protection measures or altering the configuration assumed when selecting Base Metrics.

Returning to our authentication bypass vulnerability example, you decide to protect the system by temporarily disabling user blacklisting in the web application. A successful attack will now modify the blacklist file, but the change will be ignored by the web application. You choose a Modified Availability of None to indicate that the Availability of the impacted component has not been affected. You leave the other Modified metrics as Not Defined as they are not altered by your action. For the purposes of creating an Environmental Score, Not Defined uses the same metric values as those set for the associated Base Metric.

The Environmental Score you generate is 2.3, which is rated as a Low severity using the Severity Rating system.

Now we have finished scoring our example vulnerability, let's cover:

For some purposes it is useful to have a textual representation of the numeric Base, Temporal and Environmental Scores. All scores can be mapped to the qualitative ratings defined here.

As an example, a CVSS Base Score of 4.0 has an associated severity rating of Medium. The use of these qualitative severity ratings is optional, and there is no requirement to include them when publishing CVSS scores. They are intended to help organizations properly assess and prioritize their vulnerability management processes.

The CVSS version 3.0 vector string is a text representation of a set of CVSS metrics and it is used to record or transfer CVSS metric information in a concise form.

The version 3.0 vector string begins with the label "CVSS:" and a numeric representation of the current version, "3.0."

Metric information follows in the form of a set of metrics, each metric being preceded by a forward slash, "/", acting as a delimiter.

Each metric consists of a name in abbreviated form, a colon, and its associated value in abbreviated form.

All Base Metrics must be included in a vector string. Temporal and Environmental Metrics are optional, and omitted metrics are considered to have the value of Not Defined. Programs reading version 3.0 vector strings must accept metrics in any order and treat unspecified Temporal and Environmental as Not Defined.

The CVSS Calculator on the FIRST website can be used to create the Vector Strings for vulnerabilities.

You can access the vector string from the box below the Base Score table at this link: https://www.first.org/cvss/calculator/3.0

In this example, the AV:N part of the Vector String translates to an Attack Vector value of Network in the CVSS Calculator. All of the other parts of the Vector string correspond to the Base Metrics in the same way.

Sample vector string: CVSS:3.0/AV:N/AC:H/PR:L/UI:R/S:U/C:N/I:L/A:H

Temporal Metrics, Environmental Metrics, and Vector String are three scoring tools you can use to score vulnerabilities once you have your Base Metrics figured out.

Next, you can practice your knowledge of CVSS version 3.0 with some scoring scenarios.

Module 5: CVSS v3.0 Scoring Scenarios

Let’s walk through some scoring scenarios with CVSS version 3.0.

This module will allow you to walk through some attack scenarios and figure out the best way to score vulnerabilities with CVSS version 3.0.

Let’s start with our first case study. An airplane in-flight entertainment system allows passengers to watch movies via their mobile devices over the plane's wi-fi network. The entertainment system creates a sandbox environment for each passenger, allowing a passenger to watch a movie or play a video game independently of other passengers' use of the system.

A flaw in the logic of the entertainment system allows an attacker to break out of the sandbox and access any data stored on the entertainment system. The attack can only occur over the in-plane wi-fi network.

We will examine each metric and introduce more information about the vulnerability as we go, allowing you to choose the correct metric value.

Before we start looking at metrics, we need to identify the vulnerable component. We are told that the sandbox contains the vulnerable code. It controls access to resources by limiting each passenger to their own sandbox, preventing them from interfering with other passengers' use of the entertainment system and restricting them to only watching movies or playing games. As the sandbox meets the requirements for an authorization scope, and contains the vulnerable code, it is the vulnerable component.

Knowing this and that the attack occurs over the in-plane wi-fi network, what do you select as the Attack Vector?

Values: Network (N), Adjacent (A), Local (L), Physical (P)

You pick Adjacent.

Moving to Attack Complexity, the attack does not depend on conditions beyond the attacker's control, and an attacker can expect repeatable success. What do you select for Attack Complexity? Values: Low (L), High (H)

You select Low.

For Privileges Required, you are told that mobile devices connect to the plane's wi-fi network without requiring a password. They then automatically connect to the entertainment system. As an attacker needs no passwords or other credentials to perform an attack, what do you select for Privileges Required? Values: None (N), Low (L), High (H)

You select None.

For User Interaction, an attack on the in-flight entertainment system is possible without the involvement of other people. What do you select for User Interaction? Values: None (N), Required (R)

You select None.

Let's examine Scope.

Recall that an authorization scope is defined as a computing authority that controls access to computing resources. We need to identify the authorization scopes present in the system and identify the vulnerable component: the authorization scope that contains the vulnerability, and the impacted component: the authorization scope that is impacted by the vulnerability.

For this vulnerability, the vulnerable component is the sandbox environment that the entertainment system creates for each passenger to separate their activities, for example, watching a movie, from the rest of the system.

What about the impacted component? Is that also the sandbox environment, or is it a different authorization scope? Determine this to decide whether Scope is Changed or Unchanged. Values: Unchanged (U), Changed (C)

The Scope is Changed, because the attack impacted the whole entertainment system, which is considered a different authorization scope.

If the vulnerability alternatively impacted a different user's sandbox instance, it would still be considered a Changed scope because each instance is considered as a separate authorization scope.

You would have selected Unchanged if the impact were limited to the vulnerable component. For this example, it would have meant that the attacker was restricted to his or her own sandbox.

Now we have determined that the impacted component is the whole entertainment system, we can define the impact in terms of the Confidentiality, Integrity and Availability metrics. You are told that a successful attack allows the attacker to read any data stored on the entertainment system.

What do you select for Confidentiality? Values: None (N), Low (L), High (H)

You select High because the attacker can read any data.

You also find out that the attacker can use this vulnerability to modify some data stored on the entertainment system, but none that can be used to cause a direct, serious impact. What would you select for Integrity? Values: None (N), Low (L), High (H)

You pick Low.

Finally, you find out that this vulnerability can noticeably reduce the performance of the in-flight entertainment system if the attacker repeatedly accesses large files, such as movies. However, it does not allow the attacker to shut down the system or completely deny service to other users.

What do you select for Availability? Values: None (N), Low (L), High (H)

You select Low, resulting in a Base Score of 8.8, High.

Now let’s examine the Temporal Score for this vulnerability.

Temporal Metric calculator buttons are listed below by Metric and Value.

Metric Values
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)

You currently have no information on whether exploit code exists to exploit this vulnerability, so you select Not Defined for Exploit Code Maturity. This produces the same score as selecting High, but is an indication that you do not currently have sufficient information to select a more specific metric value.

Administrators of entertainment systems can alter their systems' configurations to prevent successful attacks, though at the cost of disabling a few of the more advanced system features. As this is an effective workaround, you select Workaround for Remediation Level

Though there are public reports discussing this vulnerability, there is not yet a full understanding of the root causes of the vulnerability. You select Reasonable for Report Confidence.

The Temporal Score you generate is 8.2, High.

Next let’s examine the Environmental Score for this vulnerability.

Environmental Metric calculator buttons are listed below by Metric and Value.

Metric Values
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

Let's assume that we are scoring on behalf of an airline with a large fleet of airplanes that have the vulnerable in-flight entertainment system.

The airline has not enabled any features of the entertainment system software that may collect and store sensitive information, for example, passengers cannot enter credit card numbers to purchase additional services, so we are not too concerned that an attack can reveal data on the system. You select Low for the Confidentiality Requirement. Note that this decision is based on the general risk tolerance of the airline, and is decided independently of the Confidentiality impact of the vulnerability we are scoring.

The airline is very concerned that an attack that modified the content displayed on other users’ screens could severely impact its reputation, so you select High for the Integrity Requirement.

Problems with the availability of the in-flight entertainment system won't affect the safety of the flight, and may only prove a minor annoyance to passengers. You select Low for the Availability Requirement.

Leaving all the metrics on the right as Not Defined will use the value set in the Base Metrics. It is best to do this unless you need to change the value for a given metric because of a specific environment. For the vulnerability we are scoring, we assume the airline has not changed the environment in which the entertainment system runs in a way that requires the use of the Modified Base Metrics.

This gives an Environmental Score of 7.0, High.

Now for the next case study. A machine-tooling organization has a website that uses an embedded SQL database to store user data. The website is on the organization's internal network and is not accessible from the Internet. The site creates SQL statements that include data supplied by users and passes these to the database, but insufficient validation of this data allows SQL injection attacks.

An attacker who has legitimate access to the website can send malicious input that exploits this vulnerability, allowing the data of other users of the system to be read and modified.

Before we start looking at metrics, we need to identify the vulnerable component. In this case, the website is the cause of the vulnerability because of its insufficient data validation, so the website is the vulnerable component.

Base Metric calculator buttons are listed below by Metric and Value.

Metric Values
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)

Let's start by looking at the Attack Vector metric. An attack requires the attacker to connect to the website over the organization's internal network. Which metric value should we choose?

Adjacent seems like a good choice for Attack Vector because the website is only accessible on the organization's internal network.

But wait! Adjacent is only used if the attack is limited to the same shared physical or logical network, and cannot be performed across an OSI Layer 3 boundary such as a router. Is that really the case here, or is there a better metric value that we should pick?

The attack can be performed anywhere on the organization's internal network, so you choose Network. You would choose this value for all attacks where the vulnerable component is bound to the network stack and the attacker's path is through OSI Layer 3, the Network layer. You would only choose Adjacent for attacks limited to the same shared physical network, for example Bluetooth or IEEE 802.11, or to the same logical network, for example a local IP subnet, and that cannot be performed across an OSI Layer 3 boundary, for example a router.

Moving to Attack Complexity, most SQL injections can be exploited without needing specific conditions to exist that are outside an attacker's control. It means attackers can normally expect repeatable success when performing attacks.

Our SQL injection vulnerability follows this pattern as there are no specific conditions that need to exist to exploit it. What do you choose for Attack Complexity?

You pick Low for Attack Complexity because, without evidence to the contrary, you know that SQL injection is a simple attack.

You select Low for Privileges Required. You would have selected High only if the attacker needed the privileges of an application administrator to launch the attack.

You select None for User Interaction because an attack is possible without the involvement of other users.

You select Unchanged for Scope. User data is stored in a database that is embedded in the software running the website, and both are considered to be within the same authorization scope.

According to the information you have, the attacker can modify data for all other users, so you select High for Confidentiality.

You select High for Integrity because, again, the attacker can modify the data for all other users.

You select High for Availability because the attacker can modify or delete data, and the score you generate is 8.8, High.

But wait! Availability is not about modifying data.

You select None for Availability, because a successful attack does not impact the accessibility of the website service; other users can continue to use the website. The score you generate is 8.1, High.

Now let’s examine the Temporal Score for this vulnerability.

Temporal Metric calculator buttons are listed below by Metric and Value.

Metric Values
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)

You find exploit code available on the Internet along with evidence that it works in limited cases, but it is not usable in its current state as a practical attack against most systems. You select Proof Of Concept for Exploit Code Maturity.

There is a hot fix available, so you select Temporary Fix for Remediation Level.

Fortunately, even though the fixes are in their early stages there are abundant reports out about this vulnerability, so you select Confirmed for the Report Confidence.

The Temporal Score you generate is 7.4, High.

Next let’s examine the Environmental Score for this vulnerability.

Environmental Metric calculator buttons are listed below by Metric and Value.

Metric Values
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

You find out that the loss of confidentiality is likely to have a limited adverse effect on the operations of the machine-tooling company, so you select Low for the Confidentiality Requirement. The company is moderately concerned about unauthorized changes to its data, so you select Medium for Integrity Requirement.

If access to the intranet site is impacted by an attack it may cause slight disruption among employees, but will otherwise not be a significant problem. You select Low for the Availability Requirement.

The organization changes the website configuration to disable the ability for users to update their data, thereby preventing attacks from impacting the integrity of data. This drastic course of action is intended as a temporary measure until a permanent fix can be applied. To reflect this change, you set Modified Integrity to None. No other environmental factors require changes to the values you picked for the Base Metrics, so you select Not Defined for the other metrics.

The Environmental Score you generate is 4.3, Medium.

Now let’s move to our third case study. A standalone document viewer displays documents that can contain embedded images. However, the viewer does not correctly check the length of these images before loading them into a memory buffer, allowing malformed images to overflow the buffer. A carefully malformed image can contain malicious code that overwrites document viewer code, gets run, and thereby takes over the document viewer program, inheriting all its rights and permissions.

Before we start looking at metrics, we need to identify the vulnerable component. The vulnerability is in the document viewer code, so the document viewer is the vulnerable component.

We also need to determine how the attacker would launch an attack. The attacker creates a maliciously malformed document and then needs a victim to open it on their machine. We are going to assume the attacker emails the document to a potential victim who opens it. The attacker could also place the document on a website and entice victims to download and open it, or maybe even put it on CDs or USB flash drives and mail them to victims who may open the document from there.

When you have several potential attacks for a vulnerability, score each and use the one that results in the highest Base Score.

We assume the attacker emails the malformed document to the victim, and the victim opens it on their machine.

What should the value for Attack Vector be? Values: Network (N), Adjacent (A), Local (L), Physical (P)

Network seems like a good choice because the attacker sends the malformed document to the victim via email, which is sent over a Network. It would be the correct choice if the document viewer was bound to the network and the attacker connected to it directly and transferred the document. However, this is not the case here. The document viewer is not bound to the network stack, and can only open documents from local media.

With this clarification, what should the value for Attack Vector be? Values: Network (N), Adjacent (A), Local (L), Physical (P)

If you said Attack Vector should be Local, you are correct. When scoring Attack Vector, remember to determine if the vulnerable component is bound to the network stack and being attacked through it. What should the value for Attack Complexity be?

The Attack Complexity for this vulnerability is Low because there are no specialized access conditions or extenuating circumstances that may prevent an attack [from?] being successful. An attacker can expect repeatable success against the vulnerable component.

Although an attack requires a victim to open the malformed document and trigger the attack, this is not considered as part of the Attack Complexity metric. It is part of User Interaction.

Other buffer overflow vulnerabilities may have extenuating circumstances that lead to an Attack Complexity of High. For example, attacks may not work every time due to the presence of protection mechanisms such as randomization of memory layouts or stack overflow protections.

Moving to the next metric, what should the value for Privileges Required be? Values: None (N), Low (L), High (H)

Low seems like a good choice if we consider the privileges that the victim probably requires to login to their system and open the malicious document attachment the attacker has sent.

However, we only consider privileges that the attacker requires on the target system, and in this case the attacker only needs to create a malformed document and email it. This metric does not consider privileges that the victim needs to interact with the target system.

Based on this clarification, what do you think Privileges Required should be? Values: None (N), Low (L), High (H)

You pick None for Privileges Required as the attacker needs no privileges on the target system, which in this case is the victim's computer.

This attack is only successful if a person other than the attacker opens the malformed document, so what do you think User Interaction should be? Values: None (N), Required (R)

If you picked Required, you are correct. If any sort of user actions are required for an attack to succeed, even if they are normal actions that users perform as part of their everyday activities, User Interaction should be Required.

Is Scope Changed or Unchanged? Earlier, we identified that the vulnerable authorization scope is the document viewer. The document viewer does not have a privilege mechanism and does not control access to resources, relying instead on the underlying operating system. We consider the underlying operating system to be the authorization scope. Scope is Unchanged if you think the impacted component is within the operating system's authorization scope, or Changed if you think components outside this authorization scope are impacted. Values: Unchanged (U), Changed (C)

Unchanged is correct, as a successful exploit can take over the document viewer and use its privileges to perform arbitrary actions on the operating system. Although the impact is to a different component - the operating system rather than the document viewer - both are within the authorization scope of the operating system, which is why Scope is Unchanged.

In the worse case, the result of a successful attack is that the attacker includes malicious code in the malformed document, and this code is executed when the victim opens the document. This code takes over the document viewer process and can perform any action on the operating system that the document viewer process has privileges for.

Given this, what should the value for Confidentiality be? Values: None (N), Low (L), High (H)

Low is correct in situations where we know that the document viewer process is running with limited privileges, and therefore cannot access all data on the impacted component and cannot access any data that has a direct, serious impact, such as plaintext passwords.

However, it is still common for users of older operating systems to login as a highly privileged user and run all programs as this user. If this is the case, then the attacker's malicious code will be able to read all data on the system.

Given this extra information, what do you think the value for Confidentiality should be? Values: None (N), Low (L), High (H)

If you picked High, you are right!

What about Integrity? Do you think the same analysis applies as for Confidentiality? Values: None (N), Low (L), High (H)

If you chose High on the basis that the same argument applies as for Confidentiality, you are correct. If the attacker's malicious code runs as a highly privileged operating system user, it will be able to modify any file on the file system.

What about Availability? Values: None (N), Low (L), High (H)

You select High for Availability. When scoring a vulnerability where the attacker is able to take over a process and execute any code of their choosing, it is common for Confidentiality, Availability, and Integrity to be the same.

Based on the metric values you chose, the Base Score is 7.8, High.

We covered Temporal and Environmental Metrics in the previous scenarios, so we are not going to cover them again with this scenario. However, you will get more chances to show your expertise with those metrics in the course project.

Now that you have practice with applying CVSS version 3.0 to vulnerabilities, you are ready for the course project.

Module 6: CVSS v3.0 Course Project

Here is the CVSS version 3.0 course project.

In this course project, you will show your mastery of CVSS version 3.0 scoring. This is a guided scenario asking you to choose metric values.

While going through the course, feel free to open the CVSS guide documents located at https://www.first.org/cvss in a separate tab or window of your browser. For instance, open the CVSS version 3.0 Specification Document to read detailed metric descriptions, or open the CVSS version 3.0 User Guide to read detailed guidance and rubrics for scoring. You can also navigate to an earlier part of this course as a refresher for the basics of CVSS.

You work in the Product Security Incident Response Team, or PSIRT, of a firewall vendor. Your company prioritizes work based on CVSS scores.

A security researcher sends details of a vulnerability she found in one of your firewall products.

Look at the email you receive about the vulnerability.

From: Artie J.
Sent: Monday, August 29, 2016 12:30 PM
To: PSIRT
Subject: Data Breach Firewall

I was testing the security of a client's network that uses version 5.1 of your firewall product. It is configured to block certain types of data packets received from the Internet, but seems to allow it through if the packets are fragmented. The firewall also rebooted several times, preventing any data getting through until the reboot was complete, and I think this happens for certain types of invalid packets.

As this vulnerability allows anyone on the Internet to bypass your product and reach internal systems that your firewall is designed to protect, I consider it a serious problem. I'm attaching a description of the proof-of-concept code I used to create the fragmented and invalid packets, along with the configuration and logs of my client's firewall.

You go to the calculator to score the vulnerability. First, determine the vulnerable component, then select the value for Attack Vector that corresponds to the vulnerability described

Here you are choosing the context by which vulnerability exploitation is possible. How remote can an attacker be to a vulnerable component in order to exploit it? Values: Network (N), Adjacent (A), Local (L), Physical (P) Answer: Network.

Now select the value for Attack Complexity that corresponds to the vulnerability described.

Here you are ascertaining the level of privileges an attacker must possess before successfully exploiting a vulnerability. For example, what level of privileges does an attacker need to perform an attack? Values: Low (L), High (H) Answer: Low.

Now select the value for Privileges Required that corresponds to the vulnerability described. Here you are ascertaining the level of privileges an attacker must
possess before successfully exploiting a vulnerability. For example, what level of privileges does an attacker need to perform an attack? Values: None (N), Low (L), High (H) Answer: None.

Now select the value for User Interaction that corresponds to the vulnerability described.

Here you are assessing whether the vulnerable system can be exploited with or without interaction from any user. Can the attacker exploit the vulnerability on his own or only with the help of others? Values: None (N), Required (R) Answer: None.

Now select the value for Scope that corresponds to the vulnerability described.

Here you are deciding whether an attacker can use a vulnerability to affect resources within or beyond the authorization privileges intended by the vulnerable component. For this attack, are the vulnerable component and impacted component the same or different? Values: Unchanged (U), Changed (C)

Scope is now Changed because there is an impact to the downstream network and devices.

Now select the value for Confidentiality Impact that corresponds to the vulnerability described.

Here you are assessing resources within the impacted component, that is, the downstream network and devices, that can be divulged to an attacker. Because of this vulnerability, how much information can an attacker access? Values: None (N), Low (L), High (H) Answer: None

Now select the value for Integrity Impact that corresponds to the vulnerability described.

Here you are choosing the level of integrity or protection loss. For example, to what extent is the attacker able to modify data in the impacted component, that is, the downstream network and devices? Values: None (N), Low (L), High (H)

Picking High for Integrity is correct because the attacker is able to send any network packet over the downstream network.

Now select the value for Availability Impact that corresponds to the vulnerability described.

Here you are assessing the loss of availability of the impacted component itself, that is, the downstream network and devices. For instance, to what extent can an attacker interrupt a networked service or a device? Values: None (N), Low (L), High (H)

Picking High for Availability is correct because an attacker can cause the firewall to reboot, causing all network traffic to be dropped until the reboot completes.

Here is the score you generated; 10.0. Good work! The severity is Critical, based on the Base Metrics.

Based on the Base Score, you advise the development team for the firewall product to work on this as the highest priority.

You examine the proof-of-concept code that the researcher provided.

Your product developers suggest that changing the firewall configuration to drop fragmented packets should prevent malicious packets bypassing the firewall, with a downside that legitimate fragmented packets will also be dropped.

Furthermore, this workaround will not prevent the firewall from rebooting when it receives invalid data.

Your company uses its own firewall product to protect its network. To get an idea of how impacted your own company is by this vulnerability, you generate a Temporal Score.

You go to the calculator again, to calculate the Temporal Score.

Select the value for Exploit Code Maturity that corresponds to the vulnerability described.

You are attempting to measure the likelihood of the vulnerability being attacked, based on the current state of exploit techniques, exploit code availability, or active exploitation. Values: Not Defined (X), Unproven (U), Proof-of-Concept (P), Functional (F) High (H) Answer: Proof-of-Concept.

Now select the value for Remediation Level that corresponds to the vulnerability described.

Here you are trying to measure the progress toward creating a complete fix for the vulnerability. Values: Not Defined (X), Official Fix (O), Temporary Fix (T), Workaround (W), Unavailable (U) Answer: Workaround.

Now select the value for Report Confidence that corresponds to the vulnerability described.

Here you are attempting to measure the degree of confidence in both the existence of the vulnerability and the credibility of the known technical details on the vulnerability. Values: Not Defined (X), Unknown (U), Reasonable (R), Confirmed (C) Answer: Unknown.

Here is the score you generated; 8.4. Good work! The severity is High.

Due to the high priority you put on the vulnerability, the development team soon reproduces the problem and creates an official fix. In conjunction with other stakeholders in your company, your PSIRT would like to release the patch with an updated Temporal Score to reflect the current situation.

You go to the calculator again, to recalculate the Temporal Score. Select the new value for Remediation Level that corresponds to the new situation described.

Here you are trying to measure the progress toward creating a complete fix for the vulnerability. Values: Not Defined (X), Official Fix (O), Temporary Fix (T), Workaround (W), Unavailable (U) Answer: Official Fix.

Now select the value for Report Confidence that corresponds to the vulnerability described.

Here you are attempting to measure the degree of confidence in both the existence of the vulnerability and the credibility of the known technical details on the vulnerability. Values: Not Defined (X), Unknown (U), Reasonable (R), Confirmed (C) Answer: Confirmed.

Here is the score you generated; 9.0. Good work! The severity is Critical. Now let’s examine the Environmental Metrics.

Your company uses your firewall to protect a set of systems providing investor relation information. Every quarter, this site holds unreleased financial details whose disclosure or modification will seriously impact the company.

It will take a few weeks to test and apply the complete patch for the reported vulnerability to this firewall, so the system administrators have implemented the workaround that stops fragmented packets bypassing the firewall. However, it does not prevent the firewall from rebooting when it receives invalid data.

You are asked to determine the severity of this vulnerability to this particular firewall.

You go to the calculator to calculate the Environmental Score for your organization. Select the value for Confidentiality Requirement that corresponds to your company’s situation.

How important is the confidentiality of the affected IT asset to the organization stated in the scenario? Not Defined (X), Low (L), Medium (M), High (H) Answer: Medium.

Now select the value for Integrity Requirement that corresponds to your company’s situation.

How important is the integrity of the affected IT asset to the organization stated in the scenario? Not Defined (X), Low (L), Medium (M), High (H) Answer: Not Defined.

Now select the value for Availability Requirement that corresponds to your company’s situation.

How important is the availability of the affected IT asset to the organization stated in the scenario? Values: Not Defined (X), Low (L), Medium (M), High (H) Answer: Not Defined.

Here is the score you generated; 9.0. Good work! The severity is Critical.

Now you want to use one of the Modified Base Metrics in the Environmental Metrics to indicate that the workaround to your company's firewall prevents malicious fragmented packets from entering the internal network.

Which of these three Modified Base Metrics do you change to refer to the workaround to your company's firewall?

You would use Modified Privileges Required if the privileges that the attacker needed to conduct an attack were different because of the reconfiguration of this firewall, which is not the case here.

You would use Modified Availability if the reconfiguration of the firewall changed the effect that the attack has on performance or on interruptions to the firewall, which is not the case here.

Answer: Modified Integrity.

Now pick the value for the Modified Integrity metric. Select the correct value for Modified Integrity that indicates the workaround to your company's firewall.

Here you are choosing the level of integrity or protection loss. For example, to what extent is the attacker able to modify data in the impacted component, that is, the downstream network and devices? Values: Not Defined (X), None, Low, High Answer: None.

Here is the score you generated; 7.7. Good work! The Environmental Score is High.

Congratulations! You have now mastered CVSS version 3.0 scoring. Go to this page to access a collection of information and documentation you can study on your own: (https://www.first.org/cvss)[https://www.first.org/cvss]

Thank you for taking the course on CVSS version 3.0!