We have been using the CVSS rating system since our vulnerability base came into being and our first product, XSpider (I hope someone still remembers it). It is very important for us to keep the knowledge base that we use in our products and services up to date. Since the recommendations for working with CVSS metrics do not cover all possible vulnerabilities, it is sometimes necessary to ask the question: “How is it better to set the metrics so that the final assessment reflects the real danger of vulnerability?”.

We constantly monitor the development of the standard, so we have been waiting for the final version of CVSSv3 for a long time. Opening the specification, I first of all wanted to answer the questions: “What has become better?”, “What exactly has changed?”, “Will we be able to use the new standard in our products?” And - because young professionals are often involved in maintaining the database - “How can you quickly master the assessment methodology? ”,“ How clear are the criteria? ”.

During the study of the standard, this article was born, I hope it will help you in mastering the new methodology for assessing vulnerabilities.
')

Milestones in CVSS history

The Common Vulnerability Scoring System was developed by the National Infrastructure Advisory Council's security expert group. This group includes experts from various organizations, such as CERT / CC, Cisco, DHS / MITRE, eBay, IBM Internet Security Systems, Microsoft, Qualys, Symantec.

In 2005, the first publication of the standard. The basic principles for calculating the vulnerability metrics, originally laid down in the standard, have been preserved to this day.

Further, the standard was maintained by the Common Vulnerability Scoring System-Special Interest Group (CVSS-SIG) working group as part of the Forum of Incident Response and Security Teams (FIRST) project. Membership in the group does not impose on its members any restrictions on the support and distribution of the standard.

In 2007, the second version of the standard was published: changes were made to the list of indicators and the formula for calculating the final metric was changed to more accurately assess the risk of vulnerabilities.

In 2014, guidelines for using CVSSv2 are issued by such reputable organizations as NIST and ITU, which develop manuals and standards for telecommunications and information systems.

The use of CVSS metrics for vulnerability assessment is enshrined in the PCI DSS standards and STO BR IBBS.

In June 2015, FIRST published the final version of the CVSSv3 standard, which will be discussed in this article.

The basics

CVSS provides a simple tool for calculating a numerical score on a ten-point scale, which allows security professionals to quickly decide how to respond to a particular vulnerability. The higher the value of the metric, the more rapid the response required.

The standard includes three groups of metrics:

• The base metrics describe the vulnerability characteristics that do not change over time and are independent of the execution environment. These metrics describe the complexity of exploiting a vulnerability and the potential damage to the confidentiality, integrity and availability of information.
• The time metrics , as the name implies, make an amendment to the overall assessment for the completeness of the available information about the vulnerability, the maturity of the operating code (if available) and the availability of corrections.
• With the help of contextual metrics , security experts can make corrections to the resulting assessment, taking into account the characteristics of the information environment.

Time and context metrics are optional and are used to more accurately assess the risk that this vulnerability poses to more or less specific infrastructure.

The value of a metric is usually published as a pair of a vector (specific values ​​of individual indicators) and a numerical value calculated on the basis of all indicators using the formula defined in the standard.

Innovations in CVSSv3

Further in the text we will not consider CVSSv2 in detail, there is quite good documentation on this subject [ 6 , 9 ], we will dwell in more detail on the changes made by the new standard.

Base Metrics

System components for which metrics are calculated

Within the framework of the standard, the following concepts are introduced:

• The vulnerable component is the component of the information system that contains the vulnerability and is subject to exploitation;
• impacted component - the one whose confidentiality, integrity and availability may suffer if the attack is successfully implemented.

In most cases, the vulnerable and attacked components are the same, but there are entire classes of vulnerabilities for which this is not the case, for example:

• going beyond the application sandbox;
• accessing user data stored in a browser through a vulnerability in a web application (XSS);
• going beyond the guest virtual machine.

According to the new standard, the exploitation metrics are calculated for the vulnerable component, and the impact metrics for the attacked. In CVSSv2, it was not possible to describe the situation in which the vulnerable component and the attacked differ.

Exploitation metrics

Attack vector

The degree of remoteness of the potential attacker from the vulnerable object.

CVSSv2	CVSSv3
Metric name
Access Vector (AV)	Attack Vector (AV)
Possible metric values
Network (N)	Network (N)
Adjacent Network (A)	Adjacent Network (A)
Local (L)	Local (L)
	Physical (P)

Note: here and hereafter, letter mnemonics are used in brackets used in the description of the CVSS vector.

The changes affected the concept of “Local”, which in previous versions of the standard described any actions that did not affect the network. The new version introduces the following division:

• Local - an attacker needs a local session or certain actions from a legitimate user to operate.
• Physical - an attacker needs physical access to a vulnerable subsystem.

Consider two vulnerabilities that have the same rating in terms of CVSSv2: 7.2 (AV: L / AC: L / Au: N / C: C / I: C / A: C) .

• CVE-2015-2363 - The win32k.sys driver of the Windows operating system incorrectly processes a number of objects in memory, which allows an attacker who has local access to the system to obtain administrative privileges and execute arbitrary code in kernel mode.
• CVE-2015-3007 - Juniper SRX network gateways do not correctly implement the function of disabling password recovery by an unprivileged user through the console port (set system ports console insecure). Vulnerability allows an attacker who has physical access to the console port to gain administrative privileges on the device.

The metrics for the same vulnerabilities under the new CVSSv3 standard differ:

Vulnerability	CVSSv3 vector	CVSSv3 Evaluation
CVE-2015-2363	AV: L / AC: L / PR: L / UI: N / S: U / C: H / I: H / A: H	7.8
CVE-2015-3007	AV: P / AC: L / PR: N / UI: N / S: U / C: H / I: H / A: H	6.8

It can be seen that in CVSSv3, the degree of vulnerability is assessed more accurately, without averaging, which occurred in CVSSv2.

Difficulty exploiting vulnerabilities

Qualitative assessment of the complexity of the attack. The more conditions that must be met for the exploitation of a vulnerability, the greater the complexity.

CVSSv2	CVSSv3
Metric name
Access Complexity (AC)	Attack Complexity (AC)
Possible metric values
Low (L)	Low (L)
Medium (M)
High (H)	High (H)

“Complexity” in itself is a subjective concept, therefore this metric has always been interpreted by experts in different ways. For example, for vulnerabilities that allow to implement the “Man in the middle” attack, in the NVD database one can find various options for assessing Access Complexity.

• CVE-2014-2993 - Vulnerability in the SSL certificate checking function of the Birebin.com application for the Android operating system allows an attacker to carry out the “Man in the middle” attack and gain access to confidential data. [ Access Complexity - Low ]
• CVE-2014-3908 - Vulnerability in the Amazon.com Kindle application's SSL certificate verification function for the Android operating system allows an attacker to carry out the Man-in-the-Middle attack and gain access to confidential data. [ Access Complexity - Medium ]
• CVE-2014-5239 - Vulnerability in the Microsoft Outlook.com SSL application certificate verification function for the Android operating system allows an attacker to carry out the Man-in-the-Middle attack and gain access to confidential data. [ Access Complexity - High ]

To facilitate the interpretation of this metric, the new standard offers only two levels of complexity and more clearly spells out the criteria for assigning vulnerability to one or another. In particular, vulnerabilities that allow the “Man in the Middle” attack are prescribed to be classified as High.

The factors considered in the CVSSv2 metric Access Complexity, in the new standard are taken into account two metrics - Attack Complexity and User Interaction.

Authentication / Privilege Required

Whether authentication is required for an attack, and if so, which one.

CVSSv2	CVSSv3
Metric name
Authentication (Au)	Privileges Required (PR)
Possible metric values
Multiple (M)
Single (S)
	High (H)
	Low (L)
None (N)	None (N)

The approach to calculating the metric, based on the number of independent authentication processes that an attacker needs to pass, does not accurately reflect the meaning of privileges necessary for operation.

The value of Multiple in the NVD database is quite rare and is mainly used for vulnerabilities, information about which is not detailed enough.

CVE-2015-0501 - Unknown vulnerability in Oracle MySQL Server allows remote authenticated users to disrupt database availability using an unknown vector associated with 'Server: Compiling'.

The Single value does not allow you to determine if a privileged user level access is required for operation or a standard user authentication is sufficient.

Consider two vulnerabilities that have the same rating in terms of CVSSv2: 9.0 ( AV: N / AC: L / Au: S / C: C / I: C / A: C )

• CVE-2014-0649 - The Cisco Secure Access Control System (ACS) does not authorize correctly when accessing the Remote Method Invocation (RMI) interface, which allows remote authenticated attackers to gain administrative privileges.
• CVE-2014-9193 - Innominate mGuard incorrectly handles the Point-to-Point Protocol (PPP) settings, which allows remote attackers with limited administrative rights to gain root privileges.

Metrics for the same vulnerabilities on CVSSv3:

Vulnerability	CVSSv3 vector	CVSSv3 Evaluation
CVE-2014-0649	AV: N / AC: L / PR: L / UI: N / S: U / C: H / I: H / A: H	8.8
CVE-2014-9193	AV: N / AC: L / PR: H / UI: N / S: U / C: H / I: H / A: H	7.2

As the table shows, CVSSv3 underestimates the danger of vulnerabilities requiring privileged access to operate.

The need for user interaction

Do you need any actions from the user of the attacked system to successfully launch an attack?

CVSSv2	CVSSv3
Metric name
	User Interaction (UI)
Possible metric values
	None (N)
	Required (R)

In CVSSv2, this factor was taken into account within the framework of the Access Complexity metric, the new standard is presented as an independent one.

Consider two vulnerabilities that have the same rating in terms of CVSSv2: 9.3 ( AV: N / AC: M / Au: N / C: C / I: C / A: C ).

• CVE-2014-0329 - ZTE ZXV10 W300 routers have a built-in administrator account with a fixed password in the 'XXXXairocon' format, where XXXX is the last four characters of the device’s MAC address. The remote attacker can obtain the administrator password and use it to access the device via the Telnet service.
• CVE-2015-1752 - Microsoft Internet Explorer does not properly process objects in memory, which allows an attacker to execute arbitrary code on the system when a user clicks a link containing malicious code.

Metrics for CVSSv3:

Vulnerability	CVSSv3 vector	CVSSv3 Evaluation
CVE-2014-0329	AV: N / AC: L / PR: N / UI: N / S: U / C: H / I: H / A: H	9.8
CVE-2015-1752	AV: N / AC: L / PR: N / UI: R / S: U / C: H / I: H / A: H	8.8

From this example, it is clear that CVSSv3 estimates the severity of a vulnerability more correctly.

Boundaries of operation

Whether the exploited and attacked components differ, that is, whether the exploitation of a vulnerability allows violating the confidentiality, integrity and availability of any other component of the system.

CVSSv2	CVSSv3
Metric name
	Scope (s)
Possible metric values
	Unchanged (U)
	Changed (C)

Consider two vulnerabilities that have the same CVSSv2: 10.0 rating ( AV: N / AC: L / Au: N / C: C / I: C / A: C ).

• CVE-2014-0568 - A vulnerability in the NtSetInformationFile system call handler in Adobe Reader and Adobe Acrobat on the Windows operating system allows an attacker to bypass sandbox restrictions and execute arbitrary code in a privileged context.
• CVE-2015-3048 - Vulnerability in Adobe Reader and Adobe Acrobat on Windows and MacOS X operating systems allows an attacker to cause a buffer overflow and execute arbitrary code on the system.

Vulnerability	CVSSv3 vector	CVSSv3 Evaluation
CVE-2014-0568	AV: N / AC: L / PR: N / UI: R / S: C / C: H / I: H / A: H	9.6
CVE-2015-3048	AV: N / AC: L / PR: N / UI: R / S: U / C: H / I: H / A: H	8.8

In the new vulnerability standard, in which the vulnerable and attacked components differ, receive a higher risk rating.

Exposure metrics

Assessment of the degree of influence on the confidentiality, integrity and availability of the attacked component.

CVSSv2	CVSSv3
Metric name
Confidentiality Impact (C), Integrity Impact (I), Availability Impact (A)
Possible metric values
None (N)	None (N)
Partial (P)
Complete (C)
	Medium (M)
	High (H)

In this metric, the approach to calculating weight is fundamentally changed: from quantitative (Partial — Complete) to qualitative (Medium — High).

Consider two vulnerabilities that have the same CVSSv2: 5.0 rating ( AV: N / AC: L / Au: N / C: P / I: N / A: N ).

• CVE-2014-0160 - Vulnerability exists in the TLS and DTLS implementation for OpenSSL due to incorrect handling of the Heartbeat expansion packs. Operation of this vulnerability allows attackers acting remotely to gain access to confidential information from process memory using specially crafted packets that cause reads outside the buffer.
• CVE-2015-4202 — The implementation of Cable Modem Termination Systems (CMTS) in Cisco uBR10000 routers does not allow you to restrict access to the IP Detail Record (IPDR) service, which allows a remote attacker to access confidential information by sending specially crafted IPDR packets.

Vulnerability	CVSSv3 vector	CVSSv3 Evaluation
CVE-2014-0160	AV: N / AC: L / PR: N / UI: N / S: U / C: H / I: N / A: N	7.5
CVE-2015-4202	AV: N / AC: L / PR: N / UI: N / S: U / C: L / I: N / A: N	5.3

As can be seen from the example, the qualitative approach allows to more accurately assess the risk of vulnerability.

Time metrics

Time metrics have not undergone any fundamental changes.

Maturity of available operating facilities

Is there a publicly available code or other means by which an attack can be carried out, or, on the contrary, there is only a theoretical possibility of exploitation.

CVSSv2	CVSSv3
Metric name
Exploitability (E)	Exploit Code Maturity (E)
Possible metric values
Not Defined (ND / X)
High (H)
Functional (F)
Proof-of-Concept (POC / P)
Unproven (U)

In this metric, only the name has changed: now it more accurately reflects the purpose.

Available remedies for vulnerability

Are there formal or unofficial means to eliminate the vulnerability.

CVSSv2	CVSSv3
Metric name
Remediation Level (RL)
Possible metric values
Not Defined (ND / X)
Unavailable (U)
Workaround (W)
Temporary Fix (TF / T)
Official Fix (OF / O)

No changes were made to this metric.

Confidence in Vulnerability Information

The granularity of available vulnerability reports

CVSSv2	CVSSv3
Metric name
Report Confidence (RC)
Possible metric values
Not Defined (ND)	Not Defined (X)
Unconfirmed (UC)
Uncorroborated (UR)
	Unknown (U)
	Reasonable (R)
Confirmed (C)	Confirmed (C)

The new standard more clearly describes the criteria for assigning a vulnerability report to one category or another:

• Unknown - in the existing reports there is no description of the cause of vulnerability or different researchers differ on the causes and possible consequences of exploitation;
• Reasonable — Vulnerability reports are available to judge the causes of the vulnerability with a reasonable degree of certainty (for example, the report provides an example of an exploiting code);
• Confirmed - the vulnerability is confirmed by the manufacturer of the product or a fully featured exploit is freely available.

Impact of time metrics

Consider the vulnerability:

CVE-2015-2373 - Vulnerability in the Remote Desktop Protocol (RDP) service of the Windows operating system allows a remote attacker to execute arbitrary code on the system by sending specially crafted RDP packets.

Standard Version	CVSS vector	Baseline score	final grade
CVSSv2	AV: N / AC: L / Au: N / C: C / I: C / A: C / E: U / RL: OF / RC: C	10.0	7.4
CVSSv3	AV: N / AC: L / PR: N / UI: N / S: U / C: H / I: H / A: H / E: U / RL: O / RC: C	9.8	8.5

As can be seen, the new standard redesigned the calculation formula in favor of reducing the overall impact of time metrics on the final numerical score.

Context Metrics

Context metrics are modified to simplify the assessment of the impact of the environment on the final assessment.

Security requirements

Allows you to declare which characteristic of the data of the attacked component (confidentiality, integrity or availability) most affects the functionality of the business system or the whole business processes.

CVSSv2	CVSSv3
Metric name
Confidentiality Requirement (CR), Integrity Requirement (IR), Availability Requirement (AR)
Possible metric values
Not Defined (ND / X)
High (H)
Medium (M)
Low (L)

No changes were made to this metric.

Adjusted base metrics

Exploitability and potential damage in the conditions of the IT infrastructure of a particular company.

CVSSv3
Metric name
Modified Attack Vector (MAV), Modified Attack Complexity (MAC), Modified Privileges Required (MPR), Modified User Interaction (MUI), Modified Scope (MS), Modified Confidentiality (MC), Modified Integrity (MI), Modified Availability (MA )
Possible metric values
The values ​​described in the section "Basic metrics", or Not Defined (X)

This metric can either increase the final score, for example, if a potentially weak application configuration is used, or lower, if any compensating means are introduced to reduce the risk of exploitation or the potential damage from a successful attack.

Abandoned Metrics

The following metrics are excluded from the standard:

• Collateral Damage Potential (CDP) is the None / Low / Medium / High assessment of potential damage to equipment or other assets from exploitation of a vulnerability. This metric could also account for economic damage from production downtime or lost revenue.
• Target Distribution (TD) is the percentage of systems in a company's information environment that may be affected by the exploitation of a vulnerability.

Other innovations in the standard

Chains of Vulnerabilities

The CVSS standard was originally developed for independent assessment of each vulnerability, but there are a number of cases in which it is possible, by operating several vulnerabilities consistently, to inflict significantly more damage.
The new standard recommends using CVSS metrics to describe vulnerability chains, combining the exploitation characteristics of one vulnerability with the impact metrics of another.

Consider an abstract example.

• Vulnerability 1 - Local privilege escalation that does not require user interaction.
• Vulnerability 2 - Vulnerability that allows a remote unauthenticated attacker to modify the files of a vulnerable component. Vulnerability requires the user to perform any action for successful operation, for example, clicking on a link.

Vulnerability	CVSSv3 vector	CVSSv3 Evaluation
Vulnerability 1	AV: L / AC: L / PR: N / UI: N / S: U / C: H / I: H / A: H	8.4
Vulnerability 2	AV: N / AC: L / PR: N / UI: R / S: U / C: N / I: L / A: N	4.3

If, during the exploitation of vulnerability 2, it is possible to modify the application files so that this could lead to the exploitation of vulnerability 1, we can talk about the presence of a chain of vulnerabilities with the following characteristics.

Chain of Vulnerabilities	CVSSv3 vector	CVSSv3 Evaluation
Vulnerability 2 -> Vulnerability 1	AV: N / AC: L / PR: N / UI: R / S: U / C: H / I: H / A: H	8.8

As can be seen from the example, the final assessment for the chain may be higher than the severity level of each individual vulnerability.

Qualitative Hazard Rating Scale

Over the years of using CVSSv2, different companies have developed different approaches to setting a qualitative level of danger based on the CVSS metric:

• Nvd.nist.gov: 0–3.9 Low; 4.0—6.9 Medium; 7.0-10.0 High;
• Tenable: 0–3.9 Low; 4.0—6.9 Medium; 7.0-9.9 High; 10.0 Critical;
• Rapid 7: 0–3.9 Moderate; 4.0-7.9 Severe; 8.0-10.0 Critical.

The CVSSv3 standard recommends using the following quality rating scale:

Quantification	Qualitative assessment
0	None
0.1–3.9	Low
4.0—6.9	Medium
7.0—8.9	High
9.0—10.0	Critical

List of most important changes

Briefly summarize and list the most important CVSSv3 innovations:

• Introduced the concept of "vulnerable component" and "attacked component." The exploitation metrics are calculated for the vulnerable component, and the impact metrics for the attacked.
• Added new level of access required for operation - “physical access”.
• A new metric "The need for user interaction" has been introduced.
• Reworked metric, taking into account the need for authentication. Now you can take into account the need for privileged access to the system.
• From quantitative to qualitative, the scale of metrics of impact has been reworked.
• Contextual metrics “Probability of collateral damage” and “Target density” are replaced by more meaningful “Corrected base metrics”.
• Recommendations are given for assessing vulnerability chains using the CVSS methodology.
• Standardized hazard rating scale.

The assessment approach proposed in the new standard allows for more accurate consideration of most of the factors affecting the risk of vulnerabilities; therefore, it is quite possible to expect an early implementation of this standard in companies whose work is related to the analysis of vulnerabilities.

The introduction of new metrics practically did not affect the development of the assessment process. At some points it became easier (the complexity of the attack, the need for user interaction), in some more difficult (a qualitative assessment of the impact on confidentiality, integrity and availability, the boundaries of operation).

Those who want to learn more about the CVSS vulnerability assessment methodology, I recommend, besides the specification [ 1 ], get acquainted with examples of calculations [ 3 ] and FIRST recommendations [ 2 ], where typical examples explain how to correctly use the standard for vulnerability assessment.

A number of foreign companies, including the IBM X-Force and Security Database, have already implemented CVSSv3 ratings in their products and services. We at Positive Technologies are laying the possibility of assessing CVSSv3 vulnerabilities in the corporate knowledge base and MaxPatrol product line.

Resource list

1. CVSSv3 Specification
2. CVSSv3 guidelines
3. Examples of calculating metrics according to CVSSv3
4. CVSSv3 calculator
5. Vulnerability Database National Vulnerability Database
6. CVSSv2 Specification
7. CVSSv2 calculator
8. Open letter to FIRST on CVSSv2 weaknesses
9. NIST CVSS Implementation Guide
10. ITU guidelines for using CVSS