`
`
`
`
`
`
`
`
`
`
`
`
`
`
`I n t e r n a t i o n a l T e l e c o m m u n i c a t i o n U n i o n
`
`
`
`ITU-T
`
`TELECOMMUNICATION
`STANDARDIZATION SECTOR
`OF ITU
`
`X.1521
`
`(03/2016)
`
`SERIES X: DATA NETWORKS, OPEN SYSTEM
`COMMUNICATIONS AND SECURITY
`
`Cybersecurity information exchange – Vulnerability/state
`exchange
`
`
`
`Common vulnerability scoring system 3.0
`
`Recommendation ITU-T X.1521
`
`
`
`
`
`WIZ, Inc. EXHIBIT - 1106
`WIZ, Inc. v. Orca Security LTD.
`
`

`

`
`
`ITU-T X-SERIES RECOMMENDATIONS
`
`DATA NETWORKS, OPEN SYSTEM COMMUNICATIONS AND SECURITY
`
`
`
`PUBLIC DATA NETWORKS
`OPEN SYSTEMS INTERCONNECTION
`INTERWORKING BETWEEN NETWORKS
`MESSAGE HANDLING SYSTEMS
`DIRECTORY
`OSI NETWORKING AND SYSTEM ASPECTS
`OSI MANAGEMENT
`SECURITY
`OSI APPLICATIONS
`OPEN DISTRIBUTED PROCESSING
`INFORMATION AND NETWORK SECURITY
`General security aspects
`Network security
`Security management
`Telebiometrics
`SECURE APPLICATIONS AND SERVICES
`Multicast security
`Home network security
`Mobile security
`Web security
`Security protocols
`Peer-to-peer security
`Networked ID security
`IPTV security
`CYBERSPACE SECURITY
`Cybersecurity
`Countering spam
`Identity management
`SECURE APPLICATIONS AND SERVICES
`Emergency communications
`Ubiquitous sensor network security
`PKI related Recommendations
`CYBERSECURITY INFORMATION EXCHANGE
`Overview of cybersecurity
`Vulnerability/state exchange
`Event/incident/heuristics exchange
`Exchange of policies
`Heuristics and information request
`Identification and discovery
`Assured exchange
`CLOUD COMPUTING SECURITY
`Overview of cloud computing security
`Cloud computing security design
`Cloud computing security best practices and guidelines
`Cloud computing security implementation
`Other cloud computing security
`
`
`For further details, please refer to the list of ITU-T Recommendations.
`
`
`
`
`
`
`X.1–X.199
`X.200–X.299
`X.300–X.399
`X.400–X.499
`X.500–X.599
`X.600–X.699
`X.700–X.799
`X.800–X.849
`X.850–X.899
`X.900–X.999
`
`X.1000–X.1029
`X.1030–X.1049
`X.1050–X.1069
`X.1080–X.1099
`
`X.1100–X.1109
`X.1110–X.1119
`X.1120–X.1139
`X.1140–X.1149
`X.1150–X.1159
`X.1160–X.1169
`X.1170–X.1179
`X.1180–X.1199
`
`X.1200–X.1229
`X.1230–X.1249
`X.1250–X.1279
`
`X.1300–X.1309
`X.1310–X.1339
`X.1340–X.1349
`
`X.1500–X.1519
`X.1520–X.1539
`X.1540–X.1549
`X.1550–X.1559
`X.1560–X.1569
`X.1570–X.1579
`X.1580–X.1589
`
`X.1600–X.1601
`X.1602–X.1639
`X.1640–X.1659
`X.1660–X.1679
`X.1680–X.1699
`
`
`

`

`Recommendation ITU-T X.1521
`
`
`
`Common vulnerability scoring system 3.0
`
`Summary
`
`Recommendation ITU-T X.1521 on the common vulnerability scoring system (CVSS) provides an
`open framework for communicating the characteristics and impacts of information and communication
`technologies (ICT) vulnerabilities in the commercial or open source software used in communications
`networks, end user devices, or any of the other types of ICT capable of running software. The goal of
`the Recommendation is to enable ICT managers, vulnerability bulletin providers, security vendors,
`application vendors and researchers to speak from a common language of scoring ICT vulnerabilities.
`
`History
`
`Edition Recommendation Approval
`
`Study Group
`
`Unique ID*
`
`1.0
`
`2.0
`
`
`
`ITU-T X.1521
`
`2011-04-20
`
`ITU-T X.1521
`
`2016-03-23
`
`17
`
`17
`
`11.1002/1000/11062
`
`11.1002/1000/12614
`
`Keywords
`
`Common vulnerability scoring system, CVSS, CYBEX, , metrics.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`* To access the Recommendation, type the URL http://handle.itu.int/ in the address field of your web
`browser, followed by the Recommendation's unique ID. For example, http://handle.itu.int/11.1002/1000/1
`1830-en.
`
`
`
`
`
`Rec. ITU-T X.1521 (03/2016)
`
`i
`
`

`

`
`
`FOREWORD
`
`The International Telecommunication Union (ITU) is the United Nations specialized agency in the
`field of telecommunications, information and communication technologies (ICTs). The ITU
`Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is
`responsible for studying technical, operating and tariff questions and issuing Recommendations on
`them with a view to standardizing telecommunications on a worldwide basis.
`
`The World Telecommunication Standardization Assembly (WTSA), which meets every four years,
`establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations
`on these topics.
`
`The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA
`Resolution 1.
`
`In some areas of information technology which fall within ITU-T's purview, the necessary standards
`are prepared on a collaborative basis with ISO and IEC.
`
`
`
`
`
`
`
`NOTE
`
`In this Recommendation, the expression "Administration" is used for conciseness to indicate both a
`telecommunication administration and a recognized operating agency.
`
`Compliance with this Recommendation is voluntary. However, the Recommendation may contain
`certain mandatory provisions (to ensure, e.g., interoperability or applicability) and compliance with
`the Recommendation is achieved when all of these mandatory provisions are met. The words "shall"
`or some other obligatory language such as "must" and the negative equivalents are used to express
`requirements. The use of such words does not suggest that compliance with the Recommendation is
`required of any party.
`
`
`
`
`
`
`
`INTELLECTUAL PROPERTY RIGHTS
`
`ITU draws attention to the possibility that the practice or implementation of this Recommendation
`may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the
`evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU
`members or others outside of the Recommendation development process.
`
`As of the date of approval of this Recommendation, ITU had not received notice of intellectual
`property, protected by patents, which may be required to implement this Recommendation. However,
`implementers are cautioned that this may not represent the latest information and are therefore
`strongly urged to consult the TSB patent database at http://www.itu.int/ITU-T/ipr/.
`
`
`
`
`
` ITU 2016
`
`All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior
`written permission of ITU.
`
`ii
`
`Rec. ITU-T X.1521 (03/2016)
`
`

`

`
`
`Table of Contents
`
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`Scope .............................................................................................................................
`
`References .....................................................................................................................
`
`Definitions ....................................................................................................................
`
`3.1
`
`3.2
`
`Terms defined elsewhere ................................................................................
`
`Terms defined in this Recommendation .........................................................
`
`Abbreviations and acronyms ........................................................................................
`
`Conventions ..................................................................................................................
`
`About common vulnerability scoring system ...............................................................
`
`6.1
`
`6.2
`
`6.3
`
`6.4
`
`6.5
`
`6.6
`
`6.7
`
`6.8
`
`Introduction ....................................................................................................
`
`Base metrics ....................................................................................................
`
`Temporal metrics ............................................................................................
`
`Environmental metrics ....................................................................................
`
`Qualitative severity rating scale .....................................................................
`
`Vector string ...................................................................................................
`
`CVSS v3.0 XML schema definition ...............................................................
`
`CVSS v3.0 equations ......................................................................................
`
`Appendix I – CVSS v3.0 user guide ........................................................................................
`
`I.1
`
`I.2
`
`I.3
`
`I.4
`
`I.5
`
`Introduction ....................................................................................................
`
`Changes in CVSS v3.0 ...................................................................................
`
`Scoring guide ..................................................................................................
`
`Glossary of terms ............................................................................................
`
`Scoring rubric .................................................................................................
`
`Appendix II – Resources and links ..........................................................................................
`
`Bibliography.............................................................................................................................
`
`
`
`Page
`
`1
`
`1
`
`1
`
`1
`
`1
`
`2
`
`3
`
`3
`
`3
`
`5
`
`10
`
`12
`
`14
`
`14
`
`16
`
`16
`
`19
`
`19
`
`19
`
`23
`
`25
`
`26
`
`29
`
`30
`
`
`
`
`
`Rec. ITU-T X.1521 (03/2016)
`
`iii
`
`

`

`
`
`Introduction
`
`The common vulnerability scoring system (CVSS) is an open framework for communicating the
`characteristics and severity of software vulnerabilities. CVSS consists of three metric groups: base,
`temporal, and environmental. The base group represents the intrinsic qualities of a vulnerability, the
`temporal group reflects the characteristics of a vulnerability that change over time, and the
`environmental group represents the characteristics of a vulnerability that are unique to a user's
`environment. The base metrics produce a score ranging from 0 to 10, which can then be modified by
`scoring the temporal and environmental metrics. A CVSS score is also represented as a vector string,
`a compressed textual representation of the values used to derive the score. This Recommendation
`provides the official specification for CVSS v3.0.
`
`CVSS v3.0 represents radical improvements over CVSS v2.0 and is not backward compatible with
`it. During the use of CVSS v2.0, several limitations of that specification came to light. Some of them
`are: scoring vulnerabilities in virtual environment, representing ''indirect'' vulnerabilities like cross
`site scripting, lack of ability to capture interdependencies between applications within the same
`system and capturing actions of a user other than attacker. More information of v3.0 improvements
`is given in Appendix I, clause 2.
`
`While working to address these limitations, CVSS working group realised that it is not possible to
`maintain backward compatibility with the CVSS v2.0. While acknowledging that lack of
`compatibility will cause some issues with existing systems that use and process CVSS v2.0, it is our
`belief that version 3.0 brings sufficient value that would compensate for the inconvenience. We are
`strongly advising users and vendors that are currently producing and processing CVSS v2.0 to migrate
`to CVSS v3.0.
`
`While the CVSS v2.0 specification will continue to be available for historic purposes it will cease to
`be in force. Implementers of tools and processes are strongly encouraged to adopt the CVSS v3.0
`specification while keeping support for v2.0 in order to process existing vulnerabilities already scored
`with the v2.0 specification.
`
`
`
`iv
`
`Rec. ITU-T X.1521 (03/2016)
`
`

`

`Recommendation ITU-T X.1521
`
`
`
`Common vulnerability scoring system 3.0
`
`1
`
`Scope
`
`This Recommendation provides a standardized approach for communicating the characteristics and
`impacts of ICT vulnerabilities using temporal and environmental metrics that apply contextual
`information to more accurately reflect the risk to each user's unique environment.
`
`This Recommendation is technically equivalent and compatible with the "Common Vulnerability
`Scoring System (CVSS) version 3", 10 June 2015 which can be found at the website
`http://www.first.org/cvss
`
`2
`
`References
`
`The following ITU-T Recommendations and other references contain provisions which, through
`reference in this text, constitute provisions of this Recommendation. At the time of publication, the
`editions indicated were valid. All Recommendations and other references are subject to revision;
`users of this Recommendation are therefore encouraged to investigate the possibility of applying the
`most recent edition of the Recommendations and other references listed below. A list of the currently
`valid ITU-T Recommendations is regularly published. The reference to a document within this
`Recommendation does not give it, as a stand-alone document, the status of a Recommendation.
`
`None.
`
`3
`
`Definitions
`
`3.1
`
`Terms defined elsewhere
`
`This Recommendation uses the following term defined elsewhere:
`
`vulnerability [b-ITU-T X.1500]: Any weakness that could be exploited to violate a system
`3.1.1
`or the information it contains.
`
`3.2
`
`Terms defined in this Recommendation
`
`This Recommendation defines the following terms:
`
`access: A subject's ability to view, modify, or communicate with an object. Access enables
`3.2.1
`the flow of information between the subject and the object.
`
`3.2.2
`
`availability: The reliable and timely access to data and resources by authorized individuals.
`
`confidentiality: A security principle that works to ensure that information is not disclosed to
`3.2.3
`unauthorized subjects.
`
`integrity: A security principle that makes sure that information and systems are not modified
`3.2.4
`maliciously or accidentally.
`
`3.2.5
`
`risk: The relative impact that an exploited vulnerability would have to a user's environment.
`
`3.2.6
`
`threat: The likelihood or frequency of a harmful event occurring.
`
`
`
`
`
`Rec. ITU-T X.1521 (03/2016)
`
`1
`
`

`

`
`
`4
`
`Abbreviations and acronyms
`
`This Recommendation uses the following abbreviations and acronyms:
`
`A
`
`AC
`
`AR
`
`Availability Impact
`
`Attack Complexity
`
`Availability Requirement
`
`ARP
`
`Address Resolution Protocol
`
`AV
`
`C
`
`CIA
`
`CPU
`
`CR
`
`CVE
`
`Attack Vector
`
`Confidentiality Impact
`
`Confidentiality, Integrity and Availability
`
`Central Processing Unit
`
`Confidentiality Requirement
`
`Common Vulnerability Exposure
`
`CVSS
`
`Common Vulnerability Scoring System
`
`CWE
`
`Common Weakness Enumeration
`
`DMA
`
`Direct Memory Access
`
`DNS
`
`Domain Name System
`
`DOM
`
`Document Object Model
`
`DoS
`
`Denial-of-Service
`
`E
`
`I
`
`Exploit code maturity
`
`Integrity impact
`
`ICT
`
`Information and Communication Technologies
`
`ID
`
`IP
`
`IR
`
`ISC
`
`IT
`
`LAN
`
`MA
`
`Identifier
`
`Internet Protocol
`
`Integrity Requirement
`
`Impact Sub Score
`
`Information Technology
`
`Local Area Network
`
`Modified Availability
`
`MAC
`
`Modified Attack Complexity
`
`MAV
`
`Modified Attack Vector
`
`MC
`
`MI
`
`Modified Confidentiality impact
`
`Modified Integrity
`
`MPR
`
`Modified Privileges Required
`
`MS
`
`MUI
`
`Modified Scope
`
`Modified User Interaction
`
`NIST
`
`National Institute of Standards
`
`OS
`
`Operating System
`
`2
`
`Rec. ITU-T X.1521 (03/2016)
`
`

`

`OSI
`
`Open Systems Interconnection
`
`PCI DSS Payment Card Industry Data Security Standard
`
`
`
`PR
`
`RC
`
`RL
`
`Privileges Required
`
`Report Confidence
`
`Remediation Level
`
`RPC
`
`Remote Procedure Call
`
`S
`
`Scope
`
`SCAP
`
`Security Content Automation Protocol
`
`SQL
`
`TCP
`
`UI
`
`USB
`
`VM
`
`XSS
`
`Structured Query Language
`
`Transmission Control Protocol
`
`User Interaction
`
`Universal Serial Bus
`
`Virtual Machine
`
`Cross Site Scripting
`
`5
`
`Conventions
`
`None.
`
`6
`
`About common vulnerability scoring system
`
`The common vulnerability scoring system (CVSS) is an open framework for communicating the
`characteristics and severity of software vulnerabilities. CVSS consists of three metric groups: Base,
`Temporal, and Environmental. The Base group represents the intrinsic qualities of a vulnerability, the
`Temporal group reflects the characteristics of a vulnerability that change over time, and the
`Environmental group represents the characteristics of a vulnerability that are unique to a user's
`environment. The Base metrics produce a score ranging from 0 to 10, which can then be modified by
`scoring the Temporal and Environmental metrics. A CVSS score is also represented as a vector string,
`a compressed textual representation of the values used to derive the score. This Recommendation
`provides the official specification for CVSS v3.0.
`
`6.1
`
`Introduction
`
`Software, hardware and firmware vulnerabilities pose a critical risk to any organization operating a
`computer network, and can be difficult to categorize and mitigate. The common vulnerability scoring
`system (CVSS) provides a way to capture the principal characteristics of a vulnerability, and produce
`a numerical score reflecting its severity, as well as a textual representation of that score. The
`numerical score can then be translated into a qualitative representation (such as low, medium, high
`and critical) to help organizations properly assess and prioritize their vulnerability management
`processes.
`
`In short, CVSS affords three important benefits. First, it provides standardized vulnerability scores.
`When an organization uses a common algorithm for scoring vulnerabilities across all IT platforms, it
`can leverage a single vulnerability management policy defining the maximum allowable time to
`validate and remediate a given vulnerability. Next, it provides an open framework. Users may be
`confused when a vulnerability is assigned an arbitrary score by a third party. With CVSS, the
`individual characteristics used to derive a score are transparent. Finally, CVSS enables prioritized
`risk. When the environmental score is computed, the vulnerability becomes contextual to each
`
`
`
`
`
`Rec. ITU-T X.1521 (03/2016)
`
`3
`
`

`

`
`
`organization, and helps provide a better understanding of the risk posed by this vulnerability to the
`organization.
`
`This Recommendation describes the official CVSS v3.0 specification.
`
`6.1.1 Metrics
`
`CVSS is composed of three metric groups, Base, Temporal and Environmental, each consisting of a
`set of metrics, as shown in Figure 1.
`
`Figure 1 – CVSS v3.0 metric groups
`
`
`
`The Base metric group represents the intrinsic characteristics of a vulnerability that are constant over
`time and across user environments. It is composed of two sets of metrics: the exploitability metrics
`and the impact metrics.
`
`The exploitability metrics reflect the ease and technical means by which the vulnerability can be
`exploited. That is, they represent characteristics of the thing that is vulnerable, which we refer to
`formally as the vulnerable component. On the other hand, the Impact metrics reflect the direct
`consequence of a successful exploit, and represent the consequence to the thing that suffers the
`impact, which we refer to formally as the impacted component.
`
`While the vulnerable component is typically a software application, module, driver, etc.
`(or possibly even a hardware device), the impacted component could be a software application, a
`hardware device or a network resource. This potential for measuring the impact of a vulnerability
`other than the vulnerable component, is a key feature of CVSS v3.0. This property is captured and
`further discussed by the Scope metric below.
`
`The Temporal metric group reflects the characteristics of a vulnerability that may change over time
`but not across user environments. For example, the presence of a simple-to-use exploit kit would
`increase the CVSS score, while the creation of an official patch would decrease it.
`
`The Environmental metric group represents the characteristics of a vulnerability that are relevant and
`unique to a particular user's environment. These metrics allow the scoring analyst to incorporate
`security controls which may mitigate any consequences, as well as promote or demote the importance
`of a vulnerable system according to her business risk.
`
`Each of these metrics are discussed in further detail below.
`
`4
`
`Rec. ITU-T X.1521 (03/2016)
`
`

`

`
`
`6.1.2 Scoring
`
`When the Base metrics are assigned values by an analyst, the base equation computes a score ranging
`from 0.0 to 10.0 as illustrated in Figure 2.
`
`Figure 2 – CVSS metrics and equations
`
`
`
`Specifically, the base equation is derived from two sub equations: the exploitability sub score
`equation, and the impact sub score equation. The exploitability sub score equation is derived from
`the base exploitability metrics, while the impact sub score equation is derived from the base impact
`metrics.
`
`The Base score can then be refined by scoring the temporal and environmental metrics in order to
`more accurately reflect the risk posed by a vulnerability to a user's environment. However, scoring
`the temporal and environmental metrics is not required.
`
`Generally, the Base and Temporal metrics are specified by vulnerability bulletin analysts, security
`product vendors, or application vendors because they typically possess the most accurate information
`about the characteristics of a vulnerability. On the other hand, the Environmental metrics are specified
`by end-user organizations because they are best able to assess the potential impact of a vulnerability
`within their own computing environment.
`
`Scoring CVSS metrics also produces a vector string, a textual representation of the metric values used
`to score the vulnerability. This vector string is a specifically formatted text string that contains each
`value assigned to each metric, and should always be displayed with the vulnerability score.
`
`The scoring equations and vector string are explained further below.
`
`Note that all metrics should be scored under the assumption that the attacker has already located and
`identified the vulnerability. That is, the analyst need not consider the means by which the vulnerability
`was identified. In addition, it is likely that many different types of individuals will be scoring
`vulnerabilities (e.g., software vendors, vulnerability bulletin analysts, security product vendors, etc.),
`however, note that vulnerability scoring is intended to be agnostic to the individual and their
`organization.
`
`6.2
`
`Base metrics
`
`6.2.1 Exploitability metrics
`
`As mentioned, the exploitability metrics reflect the characteristics of the thing that is vulnerable,
`which we refer to formally as the vulnerable component. Therefore, each of the exploitability metrics
`listed below should be scored relative to the vulnerable component, and reflect the properties of the
`vulnerability that lead to a successful attack.
`
`
`
`
`
`Rec. ITU-T X.1521 (03/2016)
`
`5
`
`

`

`
`
`6.2.1.1 Attack vector (AV)
`
`This metric reflects the context by which vulnerability exploitation is possible. This metric value
`(and consequently the Base score) will be greater the more remote an attacker is (in terms of logical
`and physical distance) in order to exploit 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. The list of possible values is presented in
`Table 1.
`
`Metric value
`
`Description
`
`Table 1 – Attack vector
`
`Network (N)
`
`Adjacent (A)
`
`Local (L)
`
`Physical (P)
`
`A vulnerability exploitable with network access means the vulnerable component is bound
`to the network stack and the attacker's path is through open systems interconnection (OSI)
`layer 3 (the network layer). Such a vulnerability is often termed ''remotely exploitable'' and
`can be thought of as an attack being exploitable one or more network hops away
`(e.g., across layer 3 boundaries from routers). An example of a network attack is an attacker
`causing a denial-of-service (DoS) by sending a specially crafted transmission control
`protocol (TCP) packet from across the public Internet (e.g., CVE-2004-0230).
`
`A vulnerability exploitable with adjacent network access means the vulnerable component
`is bound to the network stack, however the attack is limited to the same shared physical
`(e.g., Bluetooth, IEEE 802.11), or logical (e.g., local Internet protocol (IP) subnet) network,
`and cannot be performed across an OSI layer 3 boundary (e.g., a router). An example of an
`adjacent attack would be an address resolution protocol (ARP) (IPv4) or neighbour
`discovery (IPv6) flood leading to a denial of service on the local area network (LAN)
`segment. See also CVE-2013-6014.
`
`A vulnerability exploitable with local access means that the vulnerable component is not
`bound to the network stack, and the attacker's path is via read/write/execute capabilities. In
`some cases, the attacker may be logged in locally in order to exploit the vulnerability,
`otherwise, he or she may rely on user interaction (UI) to execute a malicious file.
`
`A vulnerability exploitable with physical access requires the attacker to physically touch
`or manipulate the vulnerable component. Physical interaction may be brief (e.g., evil maid
`attack1) or persistent. An example of such an attack is a cold boot attack which allows an
`attacker access to disk encryption keys after gaining physical access to the system, or
`peripheral attacks such as Firewire/universal serial bus (USB) direct memory access
`attacks.
`
`6.2.1.2 Attack complexity (AC)
`
`This metric describes the conditions beyond the attacker's control that must exist in order to exploit
`the vulnerability. As described below, such conditions may require the collection of more information
`about the target, the presence of certain system configuration settings, or computational exceptions.
`Importantly, the assessment of this metric excludes any requirements for user interaction in order to
`exploit the vulnerability (such conditions are captured in the User interaction metric). This metric
`value is largest for the least complex attacks. The list of possible values is presented in Table 2.
`
`
`
`1 See https://www.schneier.com/blog/archives/2009/10/evil_maid_attac.html for a description of the evil maid attack.
`
`6
`
`Rec. ITU-T X.1521 (03/2016)
`
`

`

`
`
`Table 2 – Attack complexity
`
`Metric value
`
`Description
`
`Low (L)
`
`Specialized access conditions or extenuating circumstances do not exist. An attacker can
`expect repeatable success against the vulnerable component.
`
`High (H)
`
`A successful attack depends on conditions beyond the attacker's control. That is, a
`successful attack cannot be accomplished at will, but requires the attacker to invest in some
`measurable amount of effort in preparation or execution against the vulnerable component
`before a successful attack can be expected.2 For example, a successful attack may depend
`on an attacker overcoming any of the following conditions:
`• The attacker must conduct target-specific reconnaissance. For example, on target
`configuration settings, sequence numbers, shared secrets, etc.
`• The attacker must prepare the target environment to improve exploit reliability. For
`example, repeated exploitation to win a race condition, or overcoming advanced exploit
`mitigation techniques.
`• The attacker must inject himself or herself into the logical network path between the
`target and the resource requested by the victim in order to read and/or modify network
`communications (e.g., man in the middle attack).
`
`6.2.1.3
`
`Privileges required (PR)
`
`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. The list of possible values is
`presented in Table 3.
`
`Metric value
`
`None (N)
`
`Low (L)
`
`High (H)
`
`Table 3 – Privileges required
`
`Description
`
`The attacker is unauthorized prior to attack, and therefore does not require any access
`to settings or files to carry out an attack.
`
`The attacker is authorized with (i.e., requires) privileges that provide basic user
`capabilities that could normally affect only settings and files owned by a user.
`Alternatively, an attacker with low privileges may have the ability to cause an impact
`only to non-sensitive resources.
`
`The attacker is authorized with (i.e., requires) privileges that provide significant
`(e.g., administrative) control over the vulnerable component that could affect
`component-wide settings and files.
`
`6.2.1.4 User interaction (UI)
`
`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. The
`list of possible values is presented in Table 4.
`
`
`
`2 Note that we make no comment regarding the amount of effort required. We simply consider that some amount of
`additional effort must be exerted in order to exploit the vulnerability.
`
`
`
`
`
`Rec. ITU-T X.1521 (03/2016)
`
`7
`
`

`

`
`
`Table 4 – User interaction
`
`Metric value
`
`Description
`
`None (N)
`
`The vulnerable system can be exploited without interaction from any user.
`
`Required (R)
`
`Successful exploitation of this vulnerability requires a user to take some action before
`the vulnerability can be exploited. For example, a successful exploit may only be
`possible during the installation of an application by a system administrator.
`
`6.2.2 Scope (S)
`
`An important property captured by CVSS v3.0 is the ability for a vulnerability in one software
`component to impact resources beyond its means, or privileges. This consequence is represented by
`the metric Authorization scope, or simply Scope.
`
`Formally, Scope refers to the collection of privileges defined by a computing authority
`(e.g., an application, an operating system, or a sandbox environment) when granting access to
`computing resources (e.g., files, central processing unit (CPU), memory, etc.). These privileges are
`assigned based on some method of identification and authorization. In some cases, the authorization
`may be simple or loosely controlled based upon predefined rules or standards. For example, in the
`case of Ethernet traffic sent to a network switch, the switch accepts traffic that arrives on its ports and
`is an authority that controls the traffic flow to other switch ports.
`
`When the vulnerability of a software component governed by one authorization scope is able to affect
`resources governed by another authorization scope, a scope change has occurred.
`
`Intuitively, one may think of a scope change as breaking out of a sandbox, and an example would be
`a vulnerability in a virtual machine that enables an attacker to delete files on the host operating system
`(OS) (perhaps even its own virtual machine (VM)). In this example, there are two separate
`authorization authorities: one that defines and enforces privileges for the virtual machine and its users,
`and the other that defines and enforces privileges for the host system within which the virtual machine
`runs.
`
`A scope change would not occur, for example, with a vulnerability in Microsoft Word that allows an
`attacker to compromise all system files of the host OS, because the same authority enforces privileges
`of the user’s instance of Word, and the host’s system files.
`
`The Base score is greater when a scope change has occurred. The list of possible values is presented
`in Table 5.
`
`Metric value
`
`Unchanged (U)
`
`Changed (C)
`
`Table 5 – Scope
`
`Description
`
`An exploited vulnerability can only affect resources managed by the same authority.
`In this case the vulnerable component and the impacted component are the same.
`
`An exploited vulnerability can affect resources beyond the authorization privileges
`intended by the vulnerable component. In this case the vulnerable component and
`the impacted component are different.
`
`6.2.3
`
`Impact metrics
`
`The Impact metrics refer to the properties of the impacted component. Whether a successfully
`exploited vulnerability affects one or more components, the impact metrics are scored according to
`the component that suffers the worst outcome that is most directly and predictably asso