What Is CVSS?
The common vulnerability scoring system (CVSS) is open and free to industry for evaluating the seriousness of the software security vulnerabilities and is used in vulnerability management software. CVSS gives scores to vulnerabilities per the seriousness of the threat. Scores are computed considering several metrics. Scores are given between 0-10, with most severe score being 10.
First and CVSS
FIRST.Org, Inc (FIRST) is a non-profit organization based out of US that owns and manages CVSS. It is not required to be a member of FIRST to utilize or implement CVSS but FIRST does require any individual or organization give appropriate attribution while using CVSS. FIRST also states that any individual or organization that publishes scores follow the guideline so that anyone can understand how the scare was calculated.
CVE vs CVSS
Common Vulnerability Scoring System (CVSS) is a universal metric that measures the severity of a security vulnerability. This makes it an integral part of vulnerability scanning tools. Common Vulnerabilities and Exposures (CVE) is a list of publicly known and reported vulnerabilities.
What is CVSS Used For?
Organizations used to adopt their own ways to create a score for security vulnerabilities. However, these didn’t include crucial details about how each score was measured and weighted. Not having a baseline for scoring created an overall problem from organization to organization.
The US National Infrastructure Assurance Council (NIAC) developed CVSS and the standards to measure the impact of severity in an IT environment. CVSS is an open framework, so organizations have access to the measuring criteria used to create scores, enabling everyone to have a clear understanding of the vulnerability scores.
Organizations use this system to gauge the impact of vulnerabilities that are discovered. These organizations use the scale to meet security requirements, regulations, standards, and compliance. This system makes it easy to prioritize security tests and measure the most severe vulnerabilities, so they can be prioritized.
Do All Vulnerabilities have a CVSS?
If it’s a publicly known vulnerability, CVSS has a score for it. The scores range from 0.0 to 10.0, which are based on a large number of varied, grouped metrics.
What Are the Three Metrics Groups of CVSS?
Base metric group
The base metric group shows the qualities of vulnerability that are consistent over a period of time and among different user environments. It is further made up of two sets of metrics.
Exploitability Metric
It shows how easily a vulnerability can be exploited. Referred to as “exploited component”. They have 4 components – attack vector, attack complexity, privileges required, and user interaction.
Impact metrics
Impact metrics show the result of a successful exploitation of a vulnerability referred to as “impacted component”.
Temporal metric group
The temporal metric group shows the characteristics of a potential threat or vulnerabilities that may change after sometime however may not change across users.
Environmental metric group
The environmental metric group shows the characteristics of vulnerability that are important and unique to a specific user’s environment. Affected users calculate this measure usually.
Below each metric is discussed in detail.
Understanding the CVSS Score: Base Metrics
Base metrics are a representation of the vulnerability. These characteristics never change and aren’t dependent on exploitability or based on an organizational security program that’s been implemented. The rankings are listed in the National Vulnerability Database and are exclusive to base CVSS scores.
Base CVSS scores provides an easy starting point for patching and remediation, but it is also limited because it doesn’t account for real world exploits, patching availability, or mitigating organizational controls in place.
What are CVSS Metrics Based Off Of?
Exploitability – Exploitability metrics are based on the characteristics of the vulnerable component, with four sub sections; attack vector, attack complexity, privileges required, and user interaction.
Attack Vector – this metric is based on the level of access required to exploit a vulnerability. A higher score represents that an exploit can be executed remotely outside of the organization vs a lower score requires an attack to be at a physical on-premise location.
Attack Complexity – this metric is based on things outside of an attacker’s control, such as key theft or a middle-man attack. The higher score is based on extra effort the attacker needs to take outside of the cyber attack itself.
Required Privileges – this metric is based on the attacker’s privileges to exploit a vulnerability. A higher score represents the level of administration privileges that are required to carry out an attack, whereas a lower score represents little to no privileges required. part.
User Interaction – this metric is based on if the attacker needs to recruit a willing or unknowing person in order to complete the attack. A higher score represents no additional participation needed.
Scope – Scope metrics are based on the number of components needed to exploit a vulnerability. The higher score if one exploit attack can lead into a deeper backend system attack.
Impact – Impact metrics are based on actual outcomes from an attack result. There are three sub sections that weigh into this metric; confidentiality, integrity, and availability.
Confidentiality – this metric is based on the amount of data the attacker has access to. The higher score equals the most data the attacker can access, lower means no data can be reached.
Integrity – this metric is based on the ability of the attacker to alter data on the exploited system. The score is high if the attacker can completely or severely modify the data.
Availability – this metric is based on the system loss once it’s exploited. A higher score means the system will no longer be accessible by authorized users because of an attack.
1. Exploitability metric
1.1 Attack vector – shows how the vulnerability can be exploited.
Attack Vector | |
Value | Description |
---|---|
Network (N) | Attacker exploits vulnerability only through OSI layer 3 and are called “remotely exploitable”. |
Adjacent (A) | Attacker exploits vulnerability only through shared physical network. |
Local (L) | Attacker exploits the vulnerability locally or may depend on user interaction. |
Physical (P) | Vulnerable component must be physically touched or controlled by the attacker. |
1.2 Attack complexity (AC) – This metric depicts the situations that are not under the attackers control and are required to exploit vulnerability.
Attack Complexity | |
Value | Description |
---|---|
Low (L) | Attacker can be successful more than once against the vulnerable component. |
High (H) | Attacker must be more prepared to execute a successful attack on the vulnerable component. |
1.3 Privileges Required (PR) shows the amount of privileges the attacker must have to exploit the vulnerability successfully.
Privileges required | |
Value | Description |
---|---|
None (N) | The attacker doesn’t need access to files or setting to attack. Attacker is unauthorized. |
Low (L) | Attacker requires privileges to attack usually affects files and owned settings. Attacker has low authorization. |
High (H) | Attacker needs privileges that give them control and affects component wide files and settings. |
1.4 User interaction (UI) it is a user oriented metric. It determines whether a separate user must be present or the attacker or alone exploit the vulnerability.
User Interaction | |
Value | Description |
---|---|
None (N) | Exploitations of vulnerability can be done without any interaction from any user. |
Required (R) | The user can do exploitation of vulnerability only after any action. |
1.5 Scope scope refers to the group of privileges that are characterized by a computing authority when giving access to computing resources. These privileges are appointed based on a technique of approval and identification.
Scope | |
Value | Description |
---|---|
Unchanged (U) | The impacted component and the vulnerable component are the same. Resources affected are controlled by the same authority. |
Changed (C) | The impacted component and the vulnerable component are different. The same authority does not control resources affected. |
2. Impact Metrics
2.1 Confidentiality Impact (C) this metrics limits access to information and reveals information only to authorized users. Also, prevents disclosure of information to unauthorized users.
Confidentially impact | |
Value | Description |
---|---|
High (H) | All resources of the impacted component are disclosed to the attacker due to total loss of confidentiality. |
Low (L) | Attacker can’t control the restricted information that is obtained. Some loss of confidentiality. |
None (N) | No loss of confidentiality. |
2.2 Integrity impact (I) Measures the true nature of the information and how much it can be trusted. Successful exploitation of vulnerability is measured through impact to integrity.
Integrity Impact | |
Value | Description |
---|---|
High (H) | Total loss of integrity or protection. Attacker can alter any file. |
Low (L) | Attacker can modify a file but cannot control the consequences. |
None (N) | No loss of integrity. |
2.3 Availability impact (A) Refers to how much information resources are accessible.
Availability Impact | |
Value | Description |
---|---|
High (H) | Attacker can deny full access to resources in the impacted component. Total loss of availability. |
Low (L) | Attacker cannot deny totally. Partial or full resources are available only for a certain period. |
None (N) | No loss of availability. |
Temporal Metrics
1. Exploit code maturity (E) Exploit codes that are publicly available and are easy to use gives advantage to a potential attacker. This metric is based on the current state of techniques that measures the possibility of the vulnerability attack.
Exploit code maturity | |
Value | Description |
---|---|
Not defined (X) | The score will not be influenced if given this metric value. |
High (H) | Autonomous agents deliver exploit code on a regular basis and works in all situations. |
Functional (F) | If the vulnerability exists, the exploit code will work. |
Proof-of-concept (P) | Modifications are required to use such code by a professional attacker. |
Unproven (U) | No code is available. |
2. Redemption level (RL) – The remediation level of a vulnerability is an imperative component for prioritization. The average weakness is unpatched when first distributed.
Redemption level | |
Value | Description |
---|---|
Not defined (X) | The score will not be influenced if given this metric value. |
Unavailable (U) | It is either impossible to apply or there is no solution. |
Workaround (W) | User provides their own solution unofficially. |
Temporary fix (T) | Temporary fix is available and is official. |
Official fix (O) | Official fix is available by the vendor. |
3. Report confidence (RC) – At times only the presence of vulnerabilities is made public without giving specific details. This metric helps in measuring the credibility of the information and amount of confidence in the existence of the vulnerability.
Report confidence | |
Value | Description |
---|---|
Not defined (X) | The score will not be influenced if given this metric value. |
Confirmed (C) | Source code and reports are available in detail to verify the research independently. |
Reasonable (R) | Important details are published but there is no full access to source code to verify research independently. |
Unknown (U) | Reports indicate presence of vulnerability. Less confidence in reports that are available. |
Environmental metrics
1. Security requirements (CR, IR, AR) – This metric helps in customization of CVSS score based on the affected IT to a user’s organization. Characterized as following:
- Confidentiality (CR)
- Integrity (IR)
- Availability (AR)
Security requirements | |
Value | Description |
---|---|
Not defined (X) | The score will not be influenced if given this metric value. |
High (H) | Very serious consequences on the organization and associates due to loss of CR, IS, AR. |
Medium (M) | Serious consequences on the organization and associates due to loss of CR, IR, AR. |
Low (L) | Limited consequences on the organization and associates due to loss of CR, IR, AR. |
2. Modified base metrics – It helps the adjustment of base metrics in accordance with the modification that is already present in the analyst’s environment.
Security requirements | |
Modified Base Metric | Value |
---|---|
Modified Attack Vector (MAV) | Same as base metrics above and not defined (default). |
Modified Attack Complexity (MAC) | |
Modified Privileges Required (MPR) | |
Modified User Interaction (MUI) | |
Modified Scope (MS) | |
Modified Confidentiality (MC) | |
Modified Integrity (MI) | |
Modified Availability (MA) | |
Low (L) | Limited consequences on the organization and associates due to loss of CR, IR, AR. |
Company Profile
Fortra’s Beyond Security’s testing solutions accurately assess and manage security weaknesses in networks, applications, industrial systems and networked software. We help businesses and governments simplify the management of their network and application security, thus reducing their vulnerability to attack and data loss. We specialize in DAST – our product, beSTORM will help you secure your network and applications, comply with your NERC CIP policy requirements and exceed industry and government standards.
Learn How to Advance Your Current Cybersecurity
See how you can improve your current cybersecurity efforts and create a layered, proactive security portfolio with this guide, The Proactive Approach to Advancing Your Security Maturity.