Assess severity of a vulnerability
The following article addresses how Common Vulnerabilities and Exposures (CVE) severity scores are calculated. It is useful to understand the metrics that influence these scores for the following reasons:
If you have more than one CVE with an equally high severity score, you may need to understand the different factors contributing to the severity score to decide which CVE to resolve first.
CVE severity scores are logical and often useful, however it does not take into account:
Specific business requirements you may need to adhere to and that may cause you to interpret the metrics differently.
Specific environment or mitigations you already have in place that reduce the likelihood of a vulnerability being exploited.
Severity
CVE severity uses the Common Vulnerability Scoring System (CVSS) to measure the expected harm to your software after a successful exploit of the vulnerability. CVSS is an open set of standards used to assess a vulnerability and assign a base score on a scale of 0-10. The base score determines the severity of a CVE.
Severity | Base score | Description | Status | Recommendation |
---|---|---|---|---|
Critical | 9.0-10.0 | This issue can result in a full outage or affect a critical function of the product. There is no workaround. | Fail | Resolve immediately and with as many resources as required. |
High | 7.0-8.9 | This issue significantly affects the security of the software and impacts the processes it supports. Partial or overly complicated workarounds exist but are not recommended. | Pass | Resolve quickly. |
Medium | 4.0-6.9 | This issue affects multiple users and require little or no user interaction to trigger. | Pass | Resolve in a reasonable timescale. |
Low | 0.1-3.9 | This issue affects singular users and require interaction or significant prerequisites to trigger. | Pass | Resolve at your convenience to improve your software. |
None | 0 | This issue is a non-exploitable vulnerability that are generally deemed an acceptable business risk. | Pass | Resolve eventually to improve your software. |
How is the severity of a vulnerability calculated?
As of July 13th, 2022, the National Vulnerability Database (NVD) relies on CVSS version 3.1 to calculate CVE base score. The base score determines the severity of a vulnerability and is calculated by adding the following metrics, each of which assesses specific aspects of the vulnerability's characteristics.
Attack Vector (AV)
Attack vector measures the access required for an attacker to exploit a vulnerability. The attack vector score is calculated as follows:
Value | Abbreviation | Score | Description |
---|---|---|---|
Network | N | 0.85 | An attacker can exploit this vulnerability remotely across networks using LAN, WAN, or the internet. |
Adjacent | A | 0.65 | An attacker can exploit this vulnerability over a network but is limited to systems that are one hop from each other (network adjacent), this includes a physical network link like a crossover cable or local network like Bluetooth. |
Local | L | 0.55 | An attacker can exploit this vulnerability via physical access to the system or remotely (generally via social engineering). |
Physical | P | 0.2 | An attacker requires physical access to the system to exploit this vulnerability. |
Attack Complexity (AC)
Attack complexity measures the level of difficulty required for an attacker to exploit a vulnerability. The attack complexity score is calculated as follows:
Value | Abbreviation | Score | Description |
---|---|---|---|
Low | L | 0.77 | It is relatively easy for an attacker to exploit this vulnerability. |
High | H | 0.44 | It requires significant effort and skills for an attacker to exploit this vulnerability. |
Scope (S)
Scope measures whether a vulnerability in one system or component impacts other resources beyond its security scope.
Nota
Scope does not have a CVSS score of its own but it does affect the Privileges Required (PR) score.
Value | Abbreviation | Description |
---|---|---|
Changed | C | The exploited vulnerability in one component can effectively damage other system components. |
Unchanged | U | The exploited vulnerability is contained and the damage is limited to the exploited component. |
Privileges Required (PR)
Privileges required measures the permissions required for an attacker to exploit a vulnerability. The privileges required score is calculated as follows:
Value | Abbreviation | Score | Description |
---|---|---|---|
None | N | 0.85 | An attacker requires no account or permissions to exploit this vulnerability. |
Low | L | 0.68 When Scope = Changed | An attacker requires basic access (general account user) to exploit this vulnerability. |
0.62 When Scope = Unchanged | |||
High | H | 0.5 When Scope = Changed | An attacker requires elevated permissions such as a local admin or any user greater than a standard user to exploit this vulnerability. SuggerimentoConsider this a higher risk if many users within your organization have elevated privileges. |
0.27 When Scope = Unchanged |
User Interaction (UI)
User interaction measures whether an attacker requires a user to perform a specific action to successfully exploit a system. The user interaction score is calculated as follows:
Value | Abbreviation | Score | Description |
---|---|---|---|
None | N | 0.85 | An attacker does not require the user to perform a specific action to exploit this vulnerability. |
Required | R | 0.65 | An attacker requires the user to perform a specific action (generally via social engineering) to exploit this vulnerability. |
Impact
Impact measures consequences of a vulnerability being exploited by combining the score of these three factors:
Confidentiality (C)
Confidentiality measures the potential of an attacker accessing sensitive information during a successful exploit of the vulnerability. The confidentiality score is calculated as follows:
Value | Abbreviation | Score | Description |
---|---|---|---|
High | H | 0.56 | An attacker can access critical files in the affected system. |
Low | L | 0.22 | An attacker access some non-critical data in the affected system. |
None | N | 0 | An attacker could not exploit this vulnerability to access data in the affected system. |
Integrity (I)
Integrity measures if an attack could modify a system component by adding, changing, or removing information therefore impacting the trustworthiness and accuracy of information. The integrity score is calculated as follows:
Value | Abbreviation | Score | Description |
---|---|---|---|
High | H | 0.56 | An attacker can modify critical files in the affected system. |
Low | L | 0.22 | An attacker modify some non-critical data in the affected system. |
None | N | 0 | An attacker could not exploit this vulnerability to modify data in the affected system. |
Availability (A)
Availability measures the potential ability of an attacker to disrupt or prevent access to your services or data after a successful exploit of the vulnerability. The availability score is calculated as follows:
Value | Abbreviation | Score | Description |
---|---|---|---|
High | H | 0.56 | An attacker can block access to the affected system. |
Low | L | 0.22 | An attacker can cause performance degradation and intermittent outages in the affected system. |
None | N | 0 | An attacker could not exploit this vulnerability to disrupt or prevent access to the affected system. |