The CVSS (Common Vulnerability Scoring System) describes the severity of vulnerabilities based on defined metrics (e.g., attack vectors, complexity) and classifies them according to a point system from 0 to 10.
One of the strengths of the CVSS is that it establishes a standard within IT for transporting and passing on important and essential information about vulnerabilities between different companies or within a company. The calculation formula and basis of the CVSS are publicly available, allowing anyone to understand and cross-check the assessment. And finally, the CVSS offers the possibility to prioritize vulnerabilities that exist in one’s own company through the threefold structure of its assessment.
The Common Vulnerability Scoring was established in 2005
The Common Vulnerability Scoring System was founded in 2005 by the National Infrastructure Advisory Council (NIAC), a working group under the U.S. Department of Homeland Security. Today, the Forum of Incident Response and Security Teams (FIRST) is responsible for the further development of the CVSS standard.
Companies such as Cisco, Microsoft, IBM, Apple, or the CERT (Computer Emergency Response Team) are involved in the further development.
The CVSS is metrically structured and has a point system in which the so-called CVSS score can be uniformly evaluated in the range from 0.0 – 10.0 (slightly critical to critical). Currently, version 3.1 (as of 20.07.2020) of the CVSS is available.
The CVSS points system can be divided into three main categories:
- Base (most important category)
The most important part of these categories is the definition of vulnerability indicators. These can only be defined by having certain rules for each individual group.
The base score
The base score of the CVSS describes the basic dangerousness of the vulnerability, as well as the ease with which it can be exploited, and can be calculated from the following Base Score metrics. The “Base Score” is defined once and does not change thereafter.
This metric indicates how “close” the attacker must be to the object. Is physical access required or is the vulnerability attackable via the Internet? The score increases as the “distance” increases.
Describes if and what conditions exist – over which the attacker has no control – to exploit the vulnerability. A low score means that no separate conditions or preparatory work need to be met.
Does the attacker need permissions (authorization) before he can exploit the vulnerability? If so, the score becomes lower, otherwise, it increases.
Does a user need to be encouraged to perform certain activities for the attack to succeed? For example, if a user must first click on a link in a phishing mail or provide input in the context of the vulnerability, the score is set to “required”.
The Impact Metrics are structured according to the following three values:
This indicator shows the extent to which an attack affects confidentiality in relation to the level of authorization obtained by exploiting the vulnerability. For example, an administrator’s password could have been obtained.
Similarly, this metric describes the impact on data integrity. For example, if an attacker can change all files on the file server as a result of his/her exploit , the integrity of the data has been completely lost and accordingly, the effect must be set to “high”.
Describes the extent to which the accessibility of a resource or a service is lost due to the vulnerability, i.e. whether it is not possible to work with it in the short, medium or long term.
Here are the 3 most important security goals:
Protecting information from unauthorized disclosure
Ensuring that information is accessible and usable by authorized entities
Protection of information from modification, insertion, deletion, rearrangement, duplication, or re-importation.
The temporal score
The Temporal Score of the CVSS is intended to give one a rough idea of how likely an exploit is in the wild, how reliably a vulnerability can be detected, and what countermeasures are possible.
Exploit code maturity (E):
This indicator shows how likely it is that the vulnerability will be exploited, depending on the availability of the exploit code in the wild. Is the code to be found proof of concept or already a full exploit kit?
Remediation level (classification of countermeasures):
This metric represents the quality and ease of available countermeasures, such as through a workaround or vendor patch.
This indicator shows how confident one is that this vulnerability exists. So this is about how trustworthy the report about this vulnerability and its basis is. A vulnerability may have been identified by a third party, but not by the vendor, or you may not be sure about the root cause of the vulnerability.
The Environmental Score
The Environmental Score of the CVSS is calculated from two categories, the Security Requirements Subscore, which is based on the three values of the Impact Score (Confidentiality, Integrity, and Availability) for a specific environment (for example, a company or department), and a modified Base Score, which also includes in its assessment the score from the Security Requirements Subscore.
By default, the Environmental Score is not populated due to its specific nature, which incorporates an organization’s circumstances and requirements into the impact of a vulnerability.
The CVSS value, which thus takes all 3 groups into account, states the vulnerability of a computer system in a given environment at a known point in time.
CVSS v2 Ratings
|Severity||Base Score Range|
CVSS v3.1 Ratings
|Severty||Base Score Range|