Temporal CVSS Scores

What is a CVSS Score?

Vulnerability management programs need a mechanism for deciding which vulnerabilities to mitigate, and when. To help accomplish this task, many enterprises turn to the Common Vulnerability Scoring System (CVSS), which provides a mechanism by which the severity of vulnerabilities can be computed and compared.

CVSS scores range from 0-10, with this numeric rating being composed of three sub groups of metrics (Base, Temporal, Environmental), of which each metric group has several subcomponents.

The unchanging, static components of a vulnerability are known as Base Metrics, which are the primary metric group reported in NIST’s National Vulnerability Database (NVD), a public database of CVSS scores for known vulnerabilities. Base Metrics do not change over time – they remain the same throughout the lifetime of a vulnerability.

Environmental Metrics apply to the specific environment in which a vulnerability exists. These metrics are, by definition, specific to each enterprise. These metrics relate to either the business criticality of the asset that is vulnerable, or to compensating controls or mitigations that might make an organization more or less susceptible to the vulnerability.

Temporal Metrics, on the other hand, change over time as a result of activities conducted by both software vendors and hackers. These metrics are sometimes, but not always, reported in the NVD. If the vendor of a piece of software has created a patch, and that patch is widely available, the temporal score for that vulnerability will be lower. On the other hand, if there are known exploits for a vulnerability, and those exploits are widely used and distributed, the temporal score will be higher. As the availability of patches and exploit code changes, the underlying attributes of the Temporal Metric will change, changing the temporal score and the overall CVSS score.

CVSS Temporal Metrics

According to FIRST, the organization that publishes the CVSS methodology, “Temporal metrics measure the current state of exploit techniques or code availability, the existence of any patches or workarounds, or the confidence in the description of a vulnerability.” There are three metrics within this metric group – Exploit Code Maturity, Remediation Level, and Report Confidence.

Exploit Code Maturity

Exploit code maturity answers the question, “Is this exploit being used in the wild?” Many exploits are only theoretical in nature, and never actually get exploited by adversaries. Others get exploited, but code to operationalize those exploits never gets widely distributed, rendering it unusable to unskilled hackers, who represent the majority.

Exploit Code Maturity is rated at one of five levels:

1. Not Defined (X) – there is not enough information to assign one of the other values. This value does not impact the Temporal score.
2. High (H) – There is wide availability of reliable, easy-to-use, functional exploit code.
3. Functional (F) – Code that works is available and is at least somewhat reliable.
4. Proof-of-concept (P) – Code exists, but might not be reliable and might require a very skilled attacker to use successfully.
5. Unproven (U) – this applies when the exploit is only theoretical and/or no known exploit code exists.

Remediation Level

Remediation level refers to the availability and maturity of a fix or patch for the vulnerability. As remediation code matures, the Temporal score will decreased.

Remediation Level is rated at one of five levels:

1. Not Defined (X) – there is not enough information to assign one of the other values. This value does not impact the Temporal score.
2. Unavailable (U) – there is no mitigation or patch available for the vulnerability.
3. Workaround (W) – there is either an unofficial patch available, or configuration/setting that can mitigate the impact of the vulnerability.
4. Temporary Fix (T) – there is a vendor created, but temporary, fix or patch available.
5. Official Fix (O) – a fix for the vulnerability is available as either a permanent patch or as an upgrade from the vendor.

Report Confidence

This metric measures the confidence level that the vulnerability actually exists, as well as the details of the issue. For example, if the vendor publicly acknowledges that a vulnerability exists, there is a very high confidence level that the vulnerability is real.

Report confidence is rated at one of four levels:

1. Not Defined (X) – there is not enough information to assign one of the other values. This value does not impact the Temporal score.
2. Confirmed (C) – Either the vendor has confirmed that the vulnerability exists, reproduction of the vulnerability has been proven, or source code is available to confirm the issue.
3. Reasonable (R) – Details have been published, but the vulnerability has not been independently verified.
4. Unknown (U) – There are reports or rumors that the vulnerability exists, but there is some reason to question the validity of those reports or the vulnerability is not consistently reproducible.

Impact of Temporal Metrics

Here is an example of Temporal Metrics in action. We start with a vulnerability with a medium CVSS score, as indicated by CVSS score that comprises only Base Metrics:

Then, without changing the Base metrics, we determine that it’s unproven whether an exploit exists, and that there is a patch that is widely available from the software vendor:

You can see that the Base Score doesn’t change at all, yet the Overall CVSS Score drops from 6.8 to 5.5. Still a medium level vulnerability, but the lower Temporal Score had significant impact on the severity.

This example demonstrates that in addition to widely available Base Factors, Temporal Factors must also be accounted for when determining the severity, and priority, of open vulnerabilities.

Operationalizing CVSS Scores

As discussed previously, published CVSS scores are typically comprised of Base Metrics only. This is a useful starting point, but really only answers the question, “Can this do damage?”, when you really need to answer, “Can this do damage to my company?” In order to ensure that you’re not being misled by CVSS scores, you need to ensure that you’re accounting for Temporal and Environmental factors as well. This is key to successfully operationalizing CVSS scores in your vulnerability management program.