The Common Vulnerability Scoring System (CVSS) is an established standard for assessing vulnerabilities. CVSS is used by default to assess known vulnerabilities in the Common Vulnerabilities and Exposures (CVE) database and is also used to assess vulnerabilities resulting from a pentest.

In this blog entry, I would like to clarify 5 misconceptions that are often misunderstood in practice. The blog entry is based on CVSS 4.0 and references some technical terms that have been around since v4.0 (e.g. CVSS-BT instead of Temporal Score, Threat Metrics, Exploitability Metrics). In principle, however, the statements also apply to CVSS 3.0 and 3.1.

According to the standard, the CVSS score does not explicitly evaluate the risk, but rather the technical severity of a vulnerability. What does that mean exactly?

CVSS only considers the "technical impact", not the "business impact"

CVSS looks at the technical impact on the confidentiality and integrity of the data as well as the availability of the system. The resulting consequences for the individual situation of a company and its business processes are not evaluated. The official CVSS documentation lists the following criteria, for example, which must also be considered: "[...] regulatory requirements, number of customers impacted, monetary losses due to a breach, life or property threatened, or reputational impacts". ⁽¹⁾

CVSS does not assess the likelihood of an attack

Even without business impact, CVSS could still determine the technical risk? To do this, the probability of a vulnerability being exploited would have to be taken into account (risk = probability * severity). However, CVSS does not sufficiently consider the probability because important factors are missing. According to the standard, the CVSS base score in particular should deliberately only evaluate factors that are independent of the time component and the individual context or environment in which the vulnerability is located. This is the only way that a CVSS score can be applied to all companies at all times. For example, the following factors that would be necessary for the consideration of a probability are missing:

• Accessibility of the system from the internet vs. intranet (Fun Fact: Intranet does not mean Adjacent for Attack Vector)
• Size of the potential attacker group
• Relationship of trust with the attacker group (employees vs. customers)
• Difficulty of finding the vulnerability
• Degree of awareness of the vulnerability

So what does CVSS assess in the Exploitability Metrics?

The factors that CVSS takes into account look more at the technical requirements or the technical exploitability of a vulnerability. The factors for exploitability (e.g. Attack Complexity, Privileges Required and User Interaction) also have little influence on the CVSS score. This is because CVSS focuses on severity, as the following example illustrates:

The advantages of CVSS are obvious: a transparent, comprehensible, standardized and also customizable assessment of vulnerabilities is important and valuable. CVSS offers all of this. However, CVSS also has two major disadvantages for the evaluation of pentest findings.

• CVSS does not distinguish between exploitable vulnerabilities and hardening measures.
• CVSS (and CVSS 4.0 in particular) assumes published vulnerabilities

Hardening measures rated too low or too high

Usually, not only vulnerabilities but also hardening measures are reported in a pentest or other security assessments. Hardening measures cannot be exploited directly, but they make an attack more difficult if another vulnerability is exploited. Examples of this are information leakages of version numbers, the lack of use of TLS 1.3 or additional protective measures such as 2FA for OWA (Outlook Web App) and Applocker on Windows systems.

These are findings that cannot be exploited in themselves or are the cause of attacks. However, the associated measures can make attacks more difficult if they are implemented.

Such hardening measures either have no severity level in CVSS (CIA = None) and would therefore have a CVSS score of 0 or are given a low severity level (CIA = Low), which often results in a CVSS score of between 4 and 6. This puts such hardening measures on a par with exploitable vulnerabilities such as XSS and would sometimes be rated far too high. Traceability is also lost because it is no longer clear why the absence of TLS 1.3 now has an impact on confidentiality. In most cases, it is more of a compliance issue.

New with CVSS 4.0: unpublished vulnerabilities are generally rated very low

A pentest usually identifies vulnerabilities that are subsequently reported confidentially to the customer but not published. The CVSS base score is applicable to both published vulnerabilities and unpublished vulnerabilities. The application of the base score is therefore practicable in both cases.

However, if you now want to evaluate the BT score (Threat Metrics, formerly Temporal) and thus the susceptibility to an exploit, CVSS 4.0 brings an exciting change. The Threat Metrics introduced there has a greater influence on the overall score, but only takes into account published proofs of concept. This means, of course, that the vulnerability must already be publicly known. As this is rarely the case with pentests, pentest findings could in principle be downgraded significantly, regardless of how easy it is to find the vulnerability (as we know, the CVSS does not take this into account).

It remains to be seen how the BT score will be used in practice for unpublished pentest findings and what impact it will have.

Conclusion

Ultimately, it depends on the type of pentest or security assessment. If the focus is on exploitable vulnerabilities, CVSS is a suitable evaluation scheme for the severity level. If hardening measures are also to be assessed, CVSS is only suitable to a limited extent and a decision should be made as to how such findings can be considered in a differentiated manner.

When using CVSS 4.0, the use of the CVSS-BT score should be evaluated internally and a clear decision made as to how and whether it should be used for unpublished vulnerabilities.

The CVSS base score should not be used directly to prioritize measures. Rather, it indicates what could happen from a technical perspective. The following aspects should be taken into account when prioritizing:

• When evaluating hardening measures, an internal reassessment of the risk and cost-benefit ratio should be carried out. This is because we have already learned that CVSS does not sufficiently consider pure hardening measures.
• The CVSS base score should be supplemented with the CVSS BTE score (Threat and Environmental Metrics) by the customer in order to be able to view the vulnerability in a specific context. When using CVSS 4.0, the use of the CVSS BT score must be evaluated internally in advance, see #2. The BT score must be calculated regularly if it is used to prioritize vulnerabilities.
• The CVSS score must be used to derive the actual and concrete risk for the company. In addition to the CVSS BTE score, it is advisable to consider other factors for the probability of exploitation and for the business impact that are not taken into account by CVSS.

CVSS requires post-processing for your own situation and assessment of the specific risk in order to derive a prioritization. If the CVSS-BT score is used for deprioritization, it must also be recalculated regularly to rule out the risk of underrated vulnerabilities.

There are usually 3 parties involved in the assessment of CVSS

• Security researcher: reports a vulnerability to the manufacturer (supplier)
• Supplier : He owns a product in which the vulnerability is located
• Consumer: uses the product in which the vulnerability is located

The CVSS standard stipulates that only the CVSS base score is calculated by the "supplier" or "security researcher". The CVSS-BT and CVSS-BTE score must be calculated by the consumer, i.e. usually the customer, as the individual context of the environment and the current point in time are taken into account. This means that the customer can use CVSS-BTE to incorporate the individual security requirements for the product and the current threat level for the vulnerability at the time of the assessment.
Note: If the additional factors in the BT and BTE score (e.g., Exploit Maturity) are not evaluated, a "Not-Defined" always corresponds to the highest value (e.g., Security Requirements = "High" and Exploit Maturity = "Attacked"). As a result, the CVSS base score can only be corrected downwards by the other factors.

Conclusion

CVSS requires the customer to calculate the CVSS BTE score in order to be able to view the vulnerability in an individual context.

The different factors ensure that several relevant aspects are taken into account when assessing vulnerabilities. However, CVSS is not always particularly flexible in the assessment of the individual factors. For example, when assessing the severity level and the associated confidentiality, integrity and availability, there is only a choice between "None", "Low" and "High". You therefore have to choose between a low or high severity level. Cross-site scripting is therefore often rated just as highly for confidentiality as the existence of a software version number in the HTTP header. The situation is similar for "Attack Complexity" and "Attack Requirements". These can also only be "low" and "high".

Conclusion

Sometimes one would like to see a gray area in the evaluation instead of having to choose between black and white in order to be able to better differentiate between different vulnerabilities.

^{1 - https://www.first.org/cvss/specification-document → Introduction
2 - https://www.first.org/cvss/calculator/4.0#CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
3} - ^{https://www.first.org/cvss/calculator/4.0#CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
4 - https://www.first.org/cvss/calculator/4.0#CVSS:4.0/AV:A/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
5 - https://owasp.org/www-community/OWASP_Risk_Rating_Methodology
6 - https://www.first.org/cvss/v4.0/user-guide → Chapter 2.2 - Further information on this under point 4
7 - https://www.first.org/epss/}