List of Potential Improvements for CVSS

Last updated: 2017-10-05

A list of potential improvements targeted at CVSS has been created based on input and feedback from various sources.

Dates are in ISO 8601 format, i.e., YYYY-MM-DD or YYYY-MM.

Split some aspects of existing Attack Complexity into a new Attack Requirements metric [v4.0]

This is a substantial change targeted for CVSS v4.0.

The scope of Attack Complexity will be reduced to reflect the exploit engineering complexity required to evade or circumvent defensive or security-enhancing technologies. The new Attack Requirements metric will reflect the prerequisite conditions of the vulnerable component that make the attack possible.

Owners: Daniel Sommerfeld and Luca Allodi

Progress: Currently under discussion in SIG meetings.

Provide guidance for using Security Requirements in Environmental Metrics Group

The current Specification and User Guide do not give sufficient guidance on choosing Security Requirements metric values. The proposal is to add text, primarily to the User Guide, to fix this.

Owner: Dale Rich

Progress: Currently under discussion in SIG meetings.

Clarify that we only score increases in impacts

Update the CVSS Specification to clarify that only impacts that increase as the result of a success exploit of a vulnerability should be scored. Specifically, impacts that an attacker can cause before exploiting the vulnerability should not be included in the CVSS score. For example, imagine a vulnerability that can only be exploited by a user with a "backup" privilege that allows the user read access to all data on a system. The vulnerability allows users with the "backup" privilege to escalate privileges to a user with the ability to read and write any data on the system. This should only be scored as an Integrity impact as the user could read all data without the vulnerability being present.

Origin: CVSS SIG meeting held 2016-04-14.

Adjust weighting of Man-in-the-Middle in Attack Complexity

"Man in the middle is in a strange position for Attack Complexity when we calculate in other more complex mitigations."

Origin: Entered on Amnesia wiki by Brian Phan.

Provide guidance on vulnerabilities in libraries (or similar)

The current CVSS guidance is difficult to interpret for vulnerabilities in code that provides functionality to other code, but which cannot run by itself. Libraries are an example. As such libraries cannot run without other code, scoring just the library results in CVSS 0 because there's no way an attacker can access it. An approach to generating a more useful CVSS score is to guess how third party code commonly calls the library, and score for the reasonable worse case. This is easier for libraries like OpenSSL that are typically used for a defined purpose, in this case securing network communication, but it is less simple for other types of library. For example, should we assume that a library that performs image conversion is used by programs that accept images from untrusted sources over a network and pass them to the library without validation checks? I think the answer is "yes", but it would be good to have guidance in the docs to explain the preferred approach.

Origin: Entered on Amnesia wiki by Darius Wiles.

Clarify difference between Attack Vector values of Adjacent and Network

Clarify the language in the Specification describing the difference between Attack Vectors of Adjacent and Network. Some SIG members informally think of AV as "how far an attacker can be from the target system to exploit the vulnerability", and we should consider adding similar language to the standard to make this clearer. In particular, we need to be clearer on the split between Adjacent and Network.

Additionally, add a new metric value to distinguish attacks possible only on specific networks, but not the entire Internet. An example could be an attack using a protocol that is generally not routed over the Internet, e.g., the protocol for Windows file sharing.

Origin: Comments from John Lento in CVSS SIG meetings held 2016-04-21 and 2016-07-28.

Remove naming confusion in Environmental Score formula

The Environmental Score formula is confusing as it reuses a name used for another formula:

"10) Please take the following comment as a constructive comment: I think it is confusing to have the Modified Impact Sub Score include as part of its formula another Modified Impact Sub Score, even though another formula is given to calculate this score. To me, it is easy to get confused when talking about the Modified Impact Sub Score that is the result of the formula and the Modified Impact Sub Score that is an input into the equation, even though we have a separate formula."

Origin: Email from Steven Finegan.

Owner: Darius Wiles

Progress: We agree that this is confusing and should be easy to rectify with minimal changes to the Specification.

Provide guidance on handling a vulnerability that has different Base Scores on different platforms

A vulnerability may have different impacts on different platforms. For example, an application may detect and use all the low-level protections that an operating system provides, so the impact maybe lower on operating systems that offer more protections. "Low-level protections" refer to functionality such as Address Space Layout Randomization (ASLR) and Data Execution Prevention (DEP). Some vendors already have systems for providing different Base Scores in such situations, but if vendors commonly need to do this, it makes sense for the CVSS standard to suggest how to do it to provide some conformity.

Origin: Comments from John Lento in CVSS SIG meetings held 2016-07-28.

The CVSS specification should make clear that an attacker is assumed to have detailed knowledge of any software and hardware that he/she can readily obtain and study before the attack, or for which detailed knowledge is readily obtainable. This does not extend to site-specific data or configuration, such as cryptographic keys or IP addresses. A statement of this type is needed so scorers don't score Attack Complexity as High purely because they believe it is difficult for an attacker to understand the target system. We assume that the attacker has ample time to perform this work before launching an attack, and it should not influence the score.

Optionally, we could extend this by stating that an attacker is assumed to have detailed knowledge of all software and hardware, including bespoke code that is unique to a site, e.g., a person attacking is assumed to have knowledge of code that is specific to that website. This is basically Kerckhoffs's principle, commonly quoted as "one ought to design systems under the assumption that the enemy will immediately gain full familiarity with them". However, it is usually much harder for an attacker to obtain site-specific code, so we may not wish to go this far.

Origin: Darius Wiles (in an email to Max Heitman dated 2016-09-22).

Privileges Required: split reconnaissance vs attack phases of an exploit as they may require different privileges

Discuss whether it is worth differentiating the privileges an attacker needs to perform reconnaissance that must be performed before launching an attack, to the privileges needed to perform the attack. For example, a vulnerability may require an attacker to login using a legitimate account to determine the username of an administrator, before launching a brute force attack against that account that does not require any privilege to perform.

Origin: Unknown

Remediation Level: Add a way to track the source of vulnerability information

Add a way to track the source of vulnerability information, especially for Temporal metrics. For example, was threat intelligence information released by the product vendor?

This information would probably not form part of the CVSS score or Vector String.

Origin: Unknown

How should we handle default configuration, common configurations, and unsupported configurations? Improve the CVSS standard to better explain how to score if configuration is a factor

For example, if a managed switch has a vulnerability in SNMP v1, but the switch ships with this disabled in the configuration and almost no customers change this, how should it be scored? If we know that 99% of customers do enable it, does that change the score? If 99% of customers enable it but the documentation explicitly tells them to never do this, does that change the score?

Origin: Unknown, but was discussed (perhaps independently) in CVSS SIG meetings held 2017-09.

Define the term “successful attack”

As well as defining the term "successful attack", clarify if it includes cases where an attack impacts the vulnerable component, but not in the way the attacker planned. For example, the attack aims to execute code on a remote system, but crashes the remote system instead.

Origin: Unknown.

Formula rounding problems

JavaScript's implementation of the formula can lead to rounding errors that give unexpected results. Benjamin showed that particular values of Environmental metrics can lead to a formula of the form (1 - (1 - 0.22)), which we expect to be 0.22, but which JavaScript calculates as 0.21999999999999997. As the CVSS formula rounds this number down, this tiny difference can lead to a 0.1 difference in the score. We need to determine whether we need to add a lot more explicit rounding in the JavaScript implementation, and maybe also make this clear that this is required in the Specification Document.

Origin: Benjamin Picuira sent an email that Darius replied to on 2017-09-28.

Accepted or Rejected Proposals

CVSS3.x_AV_Clarification: Within Attack Vector, expand Adjacent and clarify other definitions [Accepted]

Reword Attack Vector references to the OSI Layer model to make it easier to understand for non-network geeks. Expand Adjacent to include logically adjacent or trusted networks (MPLS, VPNs, etc.). Provide guidance in the User Guide on using Modified Attack Vector Environmental Metric when resources are exclusively behind a firewall.

Owner: Dave Dugal

Status: CVSS3.x_AV_Clarification accepted.