CVSS
 |
This article has multiple issues. Please help improve it or discuss these issues on the talk page.
|
Common Vulnerability Scoring System (CVSS) is a free and open industry standard for assessing the severity of computer system security vulnerabilities, and is under the custodianship of the Forum of Incident Response and Security Teams (FIRST). It attempts to establish a measure of how much concern a vulnerability warrants, compared to other vulnerabilities, so efforts can be prioritized. The scores are based on a series of measurements (called metrics) based on expert assessment. The scores have a range of 0 (least severe) to 10 (critical). Vulnerabilities with a base score in the range 7.0-10.0 are typically categorised as critical, those in the range 4.0-6.9 as major, and 0-3.9 as minor.[1]
History
Research by the National Infrastructure Advisory Council in 2003/2004 lead to the launch of CVSSv1 in 2004. As this initial draft had not been subject to peer review or review by multiple organisations, issues were swiftly identified. Work on CVSSv2 (the current version) began in 2005, and it was launched in 2007. Work on version 3 began[2] in 2012, and is expected to be released in early 2014.
Usage
The CVSSv2 base score has been adopted as primary method for quantifying the severity of vulnerabilities by a wide range of organisations and companies, including:
Metrics
The CVSS assessment measures three areas of concern:
- Base Metrics for qualities intrinsic to a vulnerability.
- Temporal Metrics for characteristics that evolve over the lifetime of vulnerability. These metrics build upon the base metrics
- Environmental Metrics for characteristics of a vulnerability that depend on a particular implementation or environment. The environmental metrics build on both the base and temporal metrics.
These metrics are used to generate both a numerical score and a text vector that indicates the severity of the vulnerability, and the way in which it was calculated.
Base Metrics
Exploitability Metrics
Access Vector
The access vector (AV) shows how a vulnerability may be exploited.
| Value | Description | Score |
|---|---|---|
| Local (L) | The attacker must either have physical access to the vulnerable system (e.g. firewire attacks) or a local account (e.g. a privilege escalation attack). | 0.395 |
| Adjacent Network (A) | The attacker must have access to the broadcast or collision domain of the vulnerable system (e.g. ARP spoofing, bluetooth attacks). | 0.646 |
| Network (N) | The vulnerable interface is working at layer 3 or above of the OSI Network stack. These types of vulnerabilities are often described as remotely exploitable (e.g. a remote buffer overflow in a network service) | 1.0 |
Access Complexity
The access complexity (AC) metric describes how easy or difficult it is to exploit the discovered vulnerability.
| Value | Description | Score |
|---|---|---|
| High (H) | Specialised conditions exist, such as a race condition with a narrow window, or a requirement for social engineering methods that would be readily noticed by knowledgeable people. | 0.35 |
| Medium (M) | There are some additional requirements for access, such as a limit on the origin of the attacks, or a requirement for the vulnerable system to be running with an uncommon, non-default configuration. | 0.61 |
| Low (L) | There are no special conditions for access to the vulnerability, such as when the system is available to large numbers of users, or the vulnerable configuration is ubiquitous. | 0.71 |
Authentication
The authentication (Au) metric describes the number of times that an attacker must authenticate to a target in order to be able to exploit it. These refer specifically to the number of times authentication is required once access has been gained to the system - it does not include (for example) authentication to a network in order to gain access to a vulnerable system. For locally exploitable vulnerabilities, this value should only be set to Single or Multiple if further authentication is required after initially accessing the system.
| Value | Description | Score |
|---|---|---|
| Multiple (M) | Exploitation of the vulnerability requires that the attacker authenticate two or more times, even if the same credentials are used each time. | 0.45 |
| Single (S) | The attacker must authenticate once in order to exploit the vulnerability. | 0.56 |
| None (N) | There is no requirement for the attacker to authenticate. | 0.704 |
Impact metrics
Confidentiality
The confidentiality (C) metric describes the impact on the confidentiality of data on or processed by the system.
| Value | Description | Score |
|---|---|---|
| None (N) | There is no impact on the confidentiality of the system. | 0.0 |
| Partial (P) | There is considerable disclosure of information, but the scope of the loss is constrained such that not all of the data is available. | 0.275 |
| Complete (C) | There is total information disclosure, providing access to any / all data on the system. | 0.660 |
Integrity
The Integrity (I) metric describes the impact on the integrity of the exploited system.
| Value | Description | Score |
|---|---|---|
| None (N) | There is no impact on the integrity of the system. | 0.0 |
| Partial (P) | Modification of some data or system files is possible, but the scope of the modification is limited. | 0.275 |
| Complete (C) | There is total loss of integrity; the attacker can modify any files or information on the target system. | 0.660 |
Availability
The availability (A) metric describes the impact on the availability of the target system. Attacks that consume network bandwidth, processor cycles, memory or any other resources will affect the availability of a system.
| Value | Description | Score |
|---|---|---|
| None (N) | There is no impact on the availability of the system. | 0.0 |
| Partial (P) | There is reduced performance or loss of some functionality. | 0.275 |
| Complete (C) | There is total loss of availability of the attacked resource. | 0.660 |
Calculations
These six metrics are used to calculate the exploitability and impact sub-scores of the vulnerability, with these sub-scores being used to calculate the overall base score.
Exploitability = 20* AccessVector*AccessComplexity*Authentication
Impact = 10.41*(1-(1-ConfImpact)*(1-IntegImpact)*(1-AvailImpact))
f(impact)= 0 if Impact=0, 1.176 otherwise
BaseScore = round_to_1_decimal(((0.6*Impact)+(0.4*Exploitability)-1.5)*f(Impact))
The metrics are concatenated to produce the CVSS Vector for the vulnerability.
Example
There is a buffer overflow vulnerability affecting web server software that allows an anonymous remote user to remotely gain partial control of the system, including the ability to cause it to shut down:
| Metric | Value | Description |
|---|---|---|
| Access Vector | Network | The vulnerability may be accessed from any network that can access the target system - typically the whole of the internet |
| Access Complexity | Low | There are no special requirements for access |
| Authentication | None | There is no requirement for authentication in order to exploit the vulnerability |
| Confidentiality | Partial | The attacker can read some files and data on the system |
| Integrity | Partial | The attacker can alter some files and data on the system |
| Availability | Complete | The attacker can cause the system and web service to become unavailable / unresponsive by shutting the system down |
This would give an exploitability sub-score of 10, and an impact sub-score of 8.5, giving an overall base score of 9.0. The vector for the base score in this case would be AV:N/AC:L/Au:N/C:P/I:P/A:C. The score and vector would normally be presented together to allow the recipient to fully understand the nature of the vulnerability, and to calculate their own environmental score if necessary.
Temporal Metrics
The value of the temporal metric will change over the lifetime of the vulnerability, as exploits are developed, disclosed and automated, and as mitigations and fixes are made available.
Exploitability
The exploitability (E) metric describes the current state of exploitation techniques or automated exploitation code.
| Value | Description | Score |
|---|---|---|
| Unproven (U) | No exploit code is available, or the exploit is theoretical | 0.85 |
| Proof-of-concept (POC) | Proof-of-concept exploit code or demonstration attacks are available, but not practical for widespread use. Not functional against all instances of the vulnerability. | 0.9 |
| Functional (F) | Functional exploit code is available, and works in most situations where the vulnerability is present. | 0.95 |
| High (H) | The vulnerability can be exploited by automated code, including mobile code (such as a worm or virus). | 1.0 |
| Not Defined (ND) | This is a signal to ignore this score. | 1.0 |
Remediation Level
The remediation level (RL) of a vulnerability allows the temporal score of a vulnerability to decrease as initial mitigations, and then official fixes, are made available.
| Value | Description | Score |
|---|---|---|
| Official Fix (OF) | A complete vendor solution is available - either a patch or an upgrade. | 0.87 |
| Temporary Fix (TF) | There is an official but temporary fix / mitigation available from the vendor. | 0.90 |
| Workaround (W) | There is an unofficial, non-vendor solution or mitigation available - perhaps developed or suggested by users of the affected product or another third party. | 0.95 |
| Unavailable (U) | There is no solution available, or it is impossible to apply a suggested solution. This is the usual initial state of the remediation level when a vulnerability is identified. | 1.0 |
| Not Defined (ND) | This is a signal to ignore this score. | 1.0 |
Report Confidence
The report confidence (RC) of a vulnerability measures the level of confidence in the existence of the vulnerability and also the credibility of the technical details of the vulnerability.
| Value | Description | Score |
|---|---|---|
| Unconfirmed (UC) | A single unconfirmed source, or multiple conflicting sources. Rumored vulnerability. | 0.9 |
| Uncorroborated (UR) | Multiple sources that broadly agree - there may be a level of remaining uncertainty about the vulnerability | 0.95 |
| Confirmed (C) | Acknowledged and confirmed by the vendor or manufacturer of the affected product. | 1.0 |
| Not Defined (ND) | This is a signal to ignore this score. | 1.0 |
Calculations
These three metrics are used, in conjunction with the base score that has already been calculated, to produce the temporal score for the vulnerability with its associated vector.
The formula used to calculate the temporal score is:
TemporalScore = round_to_1_decimal(BaseScore*Exploitability*RemediationLevel*ReportConfidence)
Example
To continue with the example above, if the vendor was first informed of the vulnerability by a posting of proof-of-concept code to a mailing list, the initial temporal score would be calculated using the values shown below:
| Metric | Value | Description |
|---|---|---|
| Exploitability | Proof-of-concept | Proof-of concept, non-automated code is provided to show basic exploit functionality. |
| Remediation Level | Unavailable | The vendor has not yet had the opportunity to provide a mitigation or fix. |
| Report Confidence | Unconfirmed | There has been a single report of the vulnerability |
This would give a temporal score of 7.3, with a temporal vector of E:POC/RL:U/RC:UC (or a full vector of AV:N/AC:L/Au:N/C:P/I:P/A:C/E:POC/RL:U/RC:UC).
If the vendor then confirms the vulnerability, the score would then rise to 8.1, with a temporal vector of E:POC/RL:U/RC:C
A temporary fix from the vendor would reduce the score back to 7.3 (E:POC/RL:TF/RC:C), while an official fix would reduce it further to 7.0 (E:POC/RL:OF/RC:C). As it is not possible to be confident that every affected system has been fixed or patched, the temporal score will not reduce beyond a certain level based on the vendor's actions, and may indeed increase if an automated exploit for the vulnerability is developed.
Environmental Metrics
The environmental metrics use the base and current temporal score to assess the severity of a vulnerability in the context of the way that the vulnerable product or software is deployed. This measure is calculated subjectively, typically by the affected parties.
Collateral Damage Potential
The collateral damage potential (CDP) metric measures the potential loss or impact on either physical assets such as equipment (and lives), or the financial impact upon the affected organisation if the vulnerability is exploited.
| Value | Description | Score |
|---|---|---|
| None (N) | No potential for loss of property, revenue or productivity | 0 |
| Low (L) | Slight damage to assets, or minor loss of revenue or productivity | 0.1 |
| Low-Medium (LM) | Moderate damage or loss | 0.3 |
| Medium-High (MH) | Significant damage or loss | 0.4 |
| High (H) | Catastrophic damage or loss | 0.5 |
| Not Defined (ND) | This is a signal to ignore this score. | 0 |
Target Distribution
The target distribution (TD) metric measures the proportion of vulnerable systems in the environment.
| Value | Description | Score |
|---|---|---|
| None (N) | No target systems exist, or they only exist in laboratory settings | 0 |
| Low (L) | 1%-25% of systems at risk | 0.25 |
| Medium (M) | 26%-75% of systems at risk | 0.75 |
| High (H) | 76%-100% of systems at risk | 1.0 |
| Not Defined (ND) | This is a signal to ignore this score. | 0 |
Security Requirements
There are three further metrics by which the specific security requirements for each of the dimensions confidentiality (CR), integrity (IR) and availability (AR) can be specified, allowing the environmental score to be fine tuned according to the users' environment.
| Value | Description | Score |
|---|---|---|
| Low (L) | Loss of (confidentiality / integrity / availability) is likely to have only a limited effect on the organisation. | 0.5 |
| Medium (M) | Loss of (confidentiality / integrity / availability) is likely to have a serious effect on the organisation. | 1.0 |
| High (H) | Loss of (confidentiality / integrity / availability) is likely to have a catastrophic effect on the organisation. | 1.51 |
| Not Defined (ND) | This is a signal to ignore this score. | 1.0 |
Calculations
The five environmental metrics are used in conjunction with the previously assessed base and temporal metrics to calculate the environmental score and to produce the associated environmental vector.
AdjustedImpact = min(10,10.41*(1-(1-ConfImpact*ConfReq)*(1-IntegImpact*IntegReq)*(1-AvailImpact*AvailReq)))
AdjustedTemporal = TemporalScore recomputed with the BaseScores Impact sub-equation replaced with the AdjustedImpact equation
EnvironmentalScore = round_to_1_decimal((AdjustedTemporal+(10-AdjustedTemporal)*CollateralDamagePotential)*TargetDistribution)
Example
If the vulnerable web server were used by a bank to provide online banking services, and a temporary fix was available from the vendor, then the environmental score could be assessed as:
| Metric | Value | Description |
|---|---|---|
| Collateral Damage Potential | Medium-High | This value would depend on what information the attacker is able to access if a vulnerable system is exploited. In this case I am assuming that some personal banking information is available, therefore there is a significant reputational impact on the bank. |
| Target Distribution | High | All of the bank's web servers run the vulnerable software. |
| Confidentiality Requirement | High | Customers expect their banking information to be confidential. |
| Integrity Requirement | High | Financial and personal information should not be changeable without authorisation. |
| Availability Requirement | Low | Unavailability of online banking services is likely to be an inconvenience for customers, but not catastrophic. |
This would give an environmental score of 8.6, and an environmental vector of CDP:MH/TD:H/CR:H/IR:H/AR:M. This score is within the range 7.0-10.0, and therefore constitutes a critical vulnerability in the context of the affected bank's business.
References
- ^ "NVD Common Vulnerability Scoring System Support v2". National Vulnerability Database. National Institute of Standards and Technology. Retrieved March 2, 2013.
- ^ "Announcing the CVSS Special Interest Group for CVSS v3 Development". First.org, Inc. Retrieved March 2, 2013.
- ^ "National Vulnerability Database Home". Nvd.nist.gov. Retrieved 2013-04-16.
- ^ "The Open Source Vulnerability Database". OSVDB. Retrieved 2013-04-16.
- ^ "CVE - Common Vulnerabilities and Exposures (CVE)". Cve.mitre.org. Retrieved 2013-04-16.
- ^ "CVSS scoring". Qualysguard.qualys.com. Retrieved 2013-04-16.
- ^ Worldwide. "CVSS Usage within Cisco - Cisco Systems". Cisco.com. Retrieved 2013-04-16.
