CVSS stands for the Common Vulnerability Scoring System. It's a way to evaluate and rank reported vulnerabilities in a standardized and repeatable way. The goal of CVSS is to help you compare vulnerabilities in different applications – and from different vendors - in a standardized, repeatable, vendor agnostic approach.
CVSS generates a score from 0 to 10 based on the severity of the vulnerability. A score of 0 means the vulnerability is less significant than a vulnerability with a score of 10, if you're only using CVSS. By using CVSS to prioritize vulnerabilities, you can focus on the most critical ones first and reduce the overall risk to your organization.
CVSS values have been grouped as well into the rankings that you may have seen, of Critical, High, Medium, and Low.For CVSS v3, they are as follows:
|CVSS Base Score||CVSS Severity Level|
|0.1 - 3.9||Low|
|4.0 - 6.9||Medium|
|7.0 - 8.9||High|
|9.0 - 10.0||Critical|
The above is what is defined within the CVSS documentation, which can be found on the FIRST website.
What is all taken into account to generate the CVSS score?
That is a great question, and it is a slightly more complex question to answer than what is CVSS. The CVSS score combines a lot of factors to be able to generate a score. Those factors are:
- Attack Vector
- Attack Complexity
- Privileges Required
- User Interaction
That’s a lot of things that go into the mix. Now let’s dig a little deeper into each of these.
The attack vector has 4 different values that can be assigned to it:
- Local, or
Think of these as how the attacker can access the system in system in question. Ranging from anywhere to I need to physically connect something to the system. A network value here will generate the highest CVSS value.
Attack Complexity comes down to how hard it is to exploit the vulnerability.Two possible values exist for this, which are:
- Low or
The low attack complexity will generate the highest score.
This outlines what privileges the attacker needs to have BEFORE exploiting the vulnerability. Possible values are:
- Low, or
None is no access to any settings or files on the system.Low is basic user capabilities.High is administrative level privileges are needed.
This defines how a user needs to be engaged somehow to successfully exploit the vulnerability. The options here are:
- None or
When no user is required the impact on the CVSS score is highest.
This is a slightly harder sub-component to understand. Here it is trying to measure if the vulnerability can impact items that are outside of the security authority of the affected component. A security authority is something that controls access to objects under its control. Examples of a security authority could be an application (controls how things work inside the application), an operating system (controls how things work within the environment). Values here are:
- Unchanged or
A scope change haS the largest impact.
Confidentially is the potential for unauthorized access to sensitive information. The possible values are:
- Low, or
The greatest impact comes from the High value, or total confidentially being lost.
This component measures the potential for unauthorized modification or deletion of data. Potential values are:
- Low, or
High is the most severe.
Availability attempts to measure the potential for denial of access to authorized users. This could be the denial access to a service or processor cycles. Potential values for Availability are:
- Low, or
High is the most severe.
Now that we know all the components, we could dive into how all of this is calculated, but to be honest, the majority of people don’t need to know this level of information. Why? Because the majority of tools calculate this for us. But if you REALLY want to know the values of each of the above components, feel free to look at the documentation HERE. And if you want to see how to calculate these all manually, take a look at the documentation and formulas HERE
Suppose you did want to try some calculations. In that case, there are numerous calculators available online, but one that FIRST puts out is found HERE. You can select the values for each component listed above, and see the final CVSS score.
History of CVSS: Are you using v1 or v2 or v3.1?
In 2003/2004, the original CVSS was released by the National Infrastructure Advisory Council (NIAC) and they selected the Forum of Incident Response and Security Teams (FIRST) to become the custodian of CVSS. This was done in April 2005.
Version 2 of the specification was released in 2007 and V3 in 2015. The current version that is being used is 3.1, released in 2019. Updates were done based on feedback received to help improve the overall value of CVSS.
Why does this matter? Well, some of the tools we use today display different information. Some show CVSS v2 scores, some show CVSS v3 scores. Some display both. You must be careful when looking at vulnerabilities and their CVSS scores to know which is being used.
For example, the same CVE is shown in the two pictures below (from the NVD website, and you can see the same CVE by going HERE). The top one is showing v3 scores, and the bottom one shows v2 scores.
Image of CVE v3 scoring
Image of CVE v2 scoring
As you can see, two different values come out of the formula depending on which version of CVSS is being used. The v3 value is 5.5, ranking a MEDIUM score while the v2 score is 2.1, earning a LOW ranking.
If you were prioritizing based on CVSS alone, this would most likely fall into two different remediation timeframes for your organization. Not overly consistent, which isn’t good.
Hopefully this has helped you understand what CVSS is and how the score is generated. While CVSS is an important tool for determining which vulnerabilities to remediate first, it's only one piece of a much larger vulnerability management puzzle. Most organizations use multiple sources of information to assess and prioritize vulnerabilities, not just CVSS scores.
That said, understanding how CVSS works and what factors contribute to the score can be extremely useful. By using the CVSS score in conjunction with other information, you can make better informed decisions about which vulnerabilities to address and in what order.
About the Author
With a career spanning over 20 years that has included working in network design, IP telephony, service development, security and project management, Jonathan has a deep technical background that provides a wealth of information he draws upon when teaching. Currently, Jonathan works for the Canadian Government conducting cyber security research in the areas of vulnerability management and automated remediation. He is also an independent security consultant. Jonathan is a co-author and instructor for SANS MGT516: Building and Leading Vulnerability Management Programs. Learn more about Jonathan.