CVSS Scores: A Practical Guide for Application

CVSS Scores: A Practical Guide for Application
7 minute read

What is CVSS?

Common Vulnerability Scoring System (CVSS) is an open framework for assessing the characteristics and severity of software vulnerabilities. The framework is owned by FIRST.Org, Inc, a United States nonprofit organization with a mission to assist security incident responders. Security teams widely use CVSSs to assign a relative numerical value to vulnerabilities. Scoring vulnerabilities on a normalized system allows Vulnerability Threat Management (VTM) teams to prioritize vulnerabilities for their organization. 

One of the main benefits of security teams leveraging CVSS scoring is that it’s standardized and platform agnostic allowing you to compare apples to apples. Alternatively, if each tool only provided a proprietary scoring mechanism, it would be challenging to prioritize vulnerabilities based on score. CVSS also provides transparent guidance on how to score vulnerabilities overall based on specific scoring metrics. 

CVSS Score Metrics

CVSS scores are composed of three main metric groups: Base, Temporal and Environmental. All three metrics combine to output one numerical value between 0 and 10. Figure 1 from FIRST.Org’s CVSS specification document highlights the different attributes of each metric group that will be described in further detail below.

Base Metric

The base metric is typically decided by the vendor with the vulnerable product or an organization that scores on their behalf. Base scores for vulnerabilities will often be published and can be found on various websites. The National Vulnerability Database (NVD) hosted by the National Institute of Standards and Technology (NIST) is a good reference to find the published base score for a vulnerability. Figure 2 below shows an example of a vulnerability on NVD. 

Keep in mind that if a newly published vulnerability is complex, it may take time to score. As a result, fresh vulnerabilities can often be published without a base score. 

Temporal Metric

The temporal metric changes over time, and there are several factors that can cause this metric to be re-calculated. A new vulnerability exploit proof-of-concept (POC) is an event that can lead to a new temporal metric scoring. Many exploit POCs are open-source and can be found on commonly used sites such as Github or Exploit Database. For example, on Exploit DB - there is a verified exploit for remote code execution on the following CVEs: 2020-10884 2020-10883 2020-10882. Figure 3 shows a screenshot of the script.

Having a verified exploit for a vulnerability discovered on critical business systems presents huge risks for organizations and the temporal metric ensures exploitability is captured in the overall CVSS score. 

On the other hand, if an official patch is released for the vulnerable product, then the temporal score could decrease. Don’t let a decreased score create a false sense of security. Having a patch released by the vulnerable product vendor is not the same thing as actually having your vulnerability patched. Unless your systems update automatically - it will require work. Unfortunately, some patches may cause unexpected behavior on your system, causing availability or performance issues. 

Environmental Metric

The environmental metric used in CVSS scores is unique to the environment where the vulnerability was discovered. It considers an organization’s security controls. For example, if the security controls mitigate the consequences of a successful exploit, it would lead to a lower environmental metric. Consequences considered are related to the infamous security CIA triad - Confidentiality, Integrity and Availability. 

In general, when it comes to the environmental metric - you should be thinking, “what is the impact if the vulnerability is successfully exploited in my company’s environment?” 

What Does a High CVSS Score Mean?

CVSS scores are evaluated on a scale of 0 to 10. For the latest standard, CVSS v3.0, here are the score ranges:

A high or critical CVSS score could be a cause for concern for your VTM or infosec team. However, what’s most important is understanding what risk a vulnerability presents to your business. For example, consider a vulnerability with a valid exploit on an old web server that doesn’t contain sensitive data and is behind your organization’s VPN. Although the CVSS base score might be high, the vulnerability doesn’t result in high risk for your business. Therefore the overall CVSS should be lowered to consider environmental factors. 

On the other hand, if you have a critical system that is internet-facing and contains an unpatched vulnerability - you need to take action. If exploited, your organization is at risk of being hacked and ending up in the news because you leaked customer data. 

Another factor to consider is compliance. Certain compliance frameworks require vulnerabilities to be patched. Under the Payment Card Industry Data Security Standard (PCI DSS) v3.2.1, Requirement 11.2.3b specifies that all internal scans must have “high” vulnerabilities resolved and all external scans result in no vulnerabilities with a severity of  4.0 or higher. In other words, any vulnerability above the low CVSS rating on your public attack surface causes you to fail a PCI audit. 

CVSS vs. CVE: What's the Difference?

CVE, CVSS, NVD, NIST - there are so many acronyms to keep up with when it comes to understanding vulnerabilities. CVE stands for Critical Vulnerabilities and Exposures. CVE is simply a list of all publicly disclosed vulnerabilities that include the CVE ID, a description, dates and comments launched by Mitre in 1999. Later in 2005, NIST built the National Vulnerability DB, which consumes data directly from the Mitre CVE list.

In the NVD, security teams can see the assigned CVSS scores for each CVE if available. NVD is also a useful tool because it allows security teams to query based on various parameters such as product, vendor, OS, type and more. 

To summarize the relationship - vulnerabilities are added to a list with a CVE ID and assigned a CVSS score when possible. 

Why CVSS Scores Need to Be Contextualized to Each Organization

As mentioned above - A CVSS base score by itself isn’t enough for an organization to prioritize patching a vulnerability. It’s important to understand what asset is vulnerable and what damage will be done if successfully exploited. This is the purpose of the environmental metric on the CVSS scoring system. 

Fortunately, NVD provides a calculator that allows you to derive your own score based on environmental inputs such as exploitability and impact. If exploiting a critical vulnerability on a host would have no impact on your organization, is it really critical?

How to Use CVSS Scores for Your Company

It may seem like common sense, but use CVSS base scores as a BASE. While it provides generic information on the vulnerability - updating the environmental metrics is crucial to understanding the true risk. 

You can also take CVEs and leverage ZeroFox’s threat intelligence tools to enrich your vulnerabilities with simple-to-understand descriptions, exploitability scores and existing exploit POCs. Once you have updated CVSS scores for discovered vulnerabilities, prioritize the vulnerabilities based on which is most dangerous if exploited. 

If you are subject to compliance audits like PCI, there may be other security requirements that your organization must adhere to in order to pass. A successful vulnerability threat management team or risk management team will consider all of these different variables to create security controls and prioritize vulnerability patching.

Tags: ComplianceVulnerability

See ZeroFox in action