CVSS Version 3.0:
CVSS version 3.0 was released on June 10th 2015 after been under development for 3 years. This was overseen by the CVSS Special Interest Group (SIG) with inputs from representatives of a broad range of industry sectors, from banking and finance to technology and academia.
What is new in CVSS version 3.0?
There are many improvements introduced in version 3.0. In this post I will cover only the major improvements in Base metric group, which is the metric group that SAP uses.
If you need more information about the Base metric group, please refer to CVSS version 3.0 specification document (section 2).
1) Scope, Vulnerable Component, and Impacted Component
One of the major development goals for CVSS version 3.0 was to solve the ‘Scope’ problem. Let me explain what a ‘Scope’ problem is.
‘Scope’ problem: In CVSS version 2, vulnerabilities are scored in relation to the “target host operating system”. As a result, vulnerabilities which have severe impact to SAP applications but limited impact to the target host operating system are rated as less severe (‘partial impact’). For example, a vulnerability in SAP application allows an attacker to perform a Denial-of-Service (DoS) attack with impact to the availability to the vulnerable SAP application. Even with a total take down of the vulnerable SAP application would only result in a ‘Partial’ (impact) rating for Availability metric in CVSS version 2. A ‘Complete’ (impact) rating for Availability can only be given if the host operating system can be taken down as well, per CVSS version 2 guidance.
This is clearly a problem for many application software vendors, including SAP. As a result, a solution is introduced in CVSS version 3.
To address the issue, CVSS version 3 introduces ‘Authorization Scope’, or simply ‘Scope’ metric to the Base metric group. This new metric allows us to capture the extent of a vulnerability with impact that extends beyond the vulnerable component.
The definition of scope refers to the collection of privileges defined by a computing authority (e.g. an application, an operating system, or a sandbox environment) which grant access to computing resources (e.g. files, CPU, memory, etc).
When we have two discrete components which manage privileges to computing resources separately, they represent separate (authorization) authorities. Referring back to our DoS attack example, let’s say the vulnerable SAP application is managed by "Authority A," while the host Operating System is managed by "Authority B."
(Credit: CVSS user guide) As depicted in the above diagram, CVSS version 3.0 leverages the Exploitability metrics to assess the vulnerable component in isolation. On the other hand, the Impact metrics are scored relative to the impacted component. When the vulnerable component is the same as the impacted component, there is no scope change. However, a scope change has occurred when there are impacts to components outside of the vulnerable component. In these cases, Confidentiality, Integrity and Availability impact metrics should be scored to reflect impact to either the vulnerable component, or the impacted component, whichever is most severe.
Going back to our DoS attack example above, in CVSS version 3, we can rate the Availability impact as ‘High’ (maximum score) to represent the real impact on the vulnerable application irrespective of its impact on Host Operating System. For cases where the Availability of the Host Operating System is also impacted, the increased severity is represented by the ‘Scope’ metric – scope changed.
(Credit: CVSS user guide) The diagram above illustrates the ‘Scope’ metric calculation.
2) Explanation of Impact metric score calculation
a) ‘Primary Impact’ versus ‘Reasonable Final Impact’
In version 3.0 the ‘Impact metric’ (CIA - Confidentiality impact, Integrity impact and Availability impact) calculation represents the ‘reasonable final impact’ possible caused by a successful vulnerability exploitation. In CVSS version 2, the impact calculation only considers the ‘primary impact’. CVSS version 3 is superior in considering the big picture in my opinion.
For example, a vulnerability resulting in disclosure of administrator credentials was rated with ‘partial’ impact to Confidentiality (with no impact to Integrity or Availability) in CVSS version 2. Yet, we should recognize the potential impact (or consequences rather) would lead an attacker to obtain administrative privileges. In version 3.0, the same vulnerability would be rated with ‘High’ impact to CIA.
b) ‘None, Partial, Complete’ versus ‘None, Low, High’
In CVSS version 2, the possible values for CIA impact were ‘None, Partial and Complete’ which are replaced by ‘None, Low and High’ in version 3.0. The new metric values reflect the overall ‘degree of impact’ caused by an attack. This is a departure from the overall percentage of the systems impacted by an attack in CVSS version 2. This change can be best explained via the ‘Heartbleed’ vulnerability (CVE-2014-0160). This ‘buffer over-read’ vulnerability which enabled an attacker to read up to 64 KB of victim’s memory is rated as having a Base metric score of 5.1 (NLN|PNN) in CVSS version 2. A successful exploitation of this vulnerability can result in only some (up to 64 KB) amount of information disclosure. However the ‘partial’ rating provided for ‘Confidentiality Impact’ does not consider the sensitivity of the data (or information) which is disclosed. Since CVSS version 2 cannot capture the sensitivity of data under attack, a vulnerability which results in disclosing information of lower sensitivity like version information of a web server, is also rated with the same Base metric score of 5.1. Yet in the ‘Heartbleed’ vulnerability, information of higher sensitivity like secret keys used for X.509 certificates, user names and passwords, emails, instant messages, business critical documents is disclosed. In version 3.0, ‘Heartbleed’ vulnerability has a Base metric score of 7.5 (NLNN|UHNN). You can see the Confidentiality impact is rated as ‘High’ considering the sensitivity\criticality of data under attack, even though the data is less than 64 KB.
3) Attack Complexity
Access Complexity (from CVSS version 2) conflated two issues: 1) Any condition beyond the attacker’s control that must exist or occur in order for the vulnerability to be successfully exploited (for example a software race condition, or a specific configuration setting), and 2) the requirement for human interaction (for example, requiring a user to click on a button or a link in case of ‘clickjacking’ or phishing attack scenarios). Therefore, Access Complexity has been separated into two metrics in CVSS version 3 - Attack Complexity (which addresses the former condition), and User Interaction (which addresses the later condition).
4) Privileges Required
The new metric – ‘Privileges Required’ replaces the Authentication metric of CVSS version 2. Instead of measuring the number of times an attacker must separately authenticate to a target system, Privileges Required captures the level of access required for an attacker to mount a successful attack. In CVSS version 2, rating of ‘Single’ for Authentication metric was unable to distinguish whether an attacker needs to have low level (for example read-only) privileges or high level (for example Administrator) privileges to successfully exploit a vulnerability.
Summary of all the changes introduced in CVSS version 3.0 compared to CVSS version 2 can be found here (section 2.9)
For more information:
The CVSS version 3.0 documents are available online on FIRST's website at https://www.first.org/cvss
Related blog posts:
- SAP Managed Tags:
1 Comment
| User | Count |
|---|---|
| 6 | |
| 5 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 |
