Last updated: 2017-10-05
A list of potential improvements targeted at CVSS 3.next 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.
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.
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.
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.
"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.
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 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.
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.
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 facebook.com 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).
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.
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.
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.
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: Benjamin Picuira sent an email that Darius replied to on 2017-09-28.
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.