How the CVSS 3.1 Scoring Model Influences Enterprise Security

With thousands of security vulnerabilities reported each month in products ranging from hardware devices to firmware to popular software apps, how does one prioritise what needs the most attention? From a business and project management perspective, it makes sense to, first and foremost, allocate engineering and/or risk assessment resources to the most severe vulnerabilities that need immediate patching. Trivial vulnerabilities, which are likely to be practically unexploitable in the current business context, could be addressed at a later time, if at all.

To solve this problem, an open standard, Common Vulnerability Scoring System (CVSS) was devised in 2004 by the National Infrastructure Advisory Council (NIAC).

The CVSS score is a way to assess the severity of a vulnerability. It consists of a base score assigned to a vulnerability, followed by the temporal and environmental scores which further reflect the severity of factors around the vulnerability.

CVSS 2.0 calculator

CVSS 3.0 calculator

The initial CVSS standard released to address this problem, however, didn’t undergo a massive peer-review. Only after receiving valuable feedback from industry stakeholders was a version 2.0 introduced with some improvements. However, major noticeable differences were added in CVSS version 3.0 which incorporated additional changes into the Base score, such as replacement of Authentication (Au) with the Privileges Required (PR) parameter and addition of Scope (S).

Over the last decade, CVSS 2.0 and 3.0 scoring has been used most widely when reporting vulnerabilities across NVD, and MITRE, with a few other and miscellaneous platforms taken into consideration.

What Changed in Version 3.1: Context

Where CVSS 2.0 and 3.0 scores could have been ‘erroneously’ employed as a measure of risk arising from a vulnerability, CVSS 3.1 standard, maintained by FIRST (Forum of Incident Response and Security Teams) explicitly clarifies “CVSS measures severity, not risk.”

Version 3.1, without making major changes to the CVSS scoring formula itself, focuses on clarifying what is meant by attack vector. Different factors and configurations may allow for the same vulnerability to have multiple, different base scores depending on the context. This is especially useful when a vulnerability on a particular system configuration or operating system may not pose a high severity, whereas it would on another.

The new CVSS version also accounts for concepts such as “vulnerability chaining.” This is when an attacker follows steps to carry out a series of attacks after performing some basic reconnaissance.

CVSS 3.1 Impacts Score Formula and Decision Making

All of this impacts prioritization from a decision-maker’s perspective. For example, where previously a vulnerability with a low base score would normally have been ignored by your project management team under the impression it poses “low risk,” CVSS 3.1 guidelines and factors instruct accounting for circumstances specific to an organization, such as the network architecture and overall configuration. Naturally, a vulnerability with a “low” score may in fact be highly exploitable when it comes to the network design of your corporate environment. This therefore helps security professionals look at ‘surrounding’ factors around a vulnerability rather than mistakenly focusing on just a score as the sole indicator of risk.

Regardless of whichever version of CVSS you stick to, 2.0, 3.0, or 3.1, consistency is important. Additionally, when converting scores between CVSS 2.0 and 3.x, care must be taken to ensure additional parameters further augment the quality of the score meaningfully rather than focusing exclusively on keeping the newly calculated scores “in match” with the previous ones.

A key challenge arises when scoring vulnerabilities for which a CVE ID has not yet been assigned by NVD and there’s no CVSS score.

Photo by Sigmund