CVE and CVSS: Explained
CVE and CVSS are some of the most commonly misunderstood aspects of patching today. Explore the differences and see how they can affect your patching strategy.
Although many IT managers are familiar with these terms, CVE and CVSS are some of the most commonly misunderstood aspects of patching today. These two different terminologies are synonymous with operating system, software vulnerabilities, and patching.
What is CVE?
The CVE (Common Vulnerabilities and Exposures) number is a unique identifier used by vendors such as Microsoft, RedHat, and Adobe to catalog individual vulnerabilities where patches are provided as a resolution. For example, every page of a book has a unique number. This solves the problem of finding the information on the page quickly.
Usually all CVE numbers look like this: CVE-nnnn-nnnn. You can see there is scope for millions of vulnerabilities.
“Our clients should feel confident that the CVE number is not owned by any specific software vendor,” said Robert Brown, Director of Services for Verismic Software. “Therefore, it is an unbiased and independent database for all vendors to publish their vulnerabilities.”
This also means that vendors must publish transparent content to these databases. At the very least, this provides some assurance to the accuracy of the data. Each company that wishes to publish its vulnerability announcements must become a CNA (CVE Numbering Authority) before its participation is considered reliable.
Vendors will include as much information as possible within each CVE record. For example:
- CVE number
- Description of vulnerability
- References to other CVE records (also known as supersession)
- Change History
- Publish Date
What is a CVSS Score?
The CVSS (Common Vulnerability Scoring System) is an independently assigned score (out of 10) which is based on a large number of factors to determine the importance of a vulnerability. To compare CVSS scores, let’s look at how Microsoft scores their vulnerabilities.
Microsoft’s rating system is relatively simple:
- Critical – A vulnerability that could allow remote code execution without user interaction or where code executes without warnings or prompts.
- Important – Vulnerabilities where the client is compromised with warnings or prompts and whose exploitation could result in compromise of data.
- Moderate – The impact is mitigated by numerous factors such as authentication or non-default applications being affected.
- Low – The impact is comprehensively mitigated by the characteristics of the mitigated component.
- NA – Not Available
However, Microsoft’s approach self-certifies vulnerabilities in its products.
Generating the CVSS score is highly complex, but it takes into consideration the following important questions:
- How easy is the vulnerability to be exploited? Do you need network or physical access and do you need elevated privileges?
- Can you exploit over the internet or do you need physical access?
- Is specific software or configuration of software needed? Does it impact everything?
- How much end-user interaction is needed?
Each of the above (and much more) are arranged in a sub score that is calculated together. The CVSS score is then calculated out of 10. Industry experts believe this offers the most accurate way to determine the priority of how quickly you must take action if any of these vulnerabilities exist within your environment.
|Low||0.1 – 3.9|
|Medium||4.0 – 6.9|
|High||7.0 – 8.9|
|Critical||9.0 – 10.0|
Are CVSS scores necessary? Prove it!
Let’s take a couple updates from the August 2019 Patch Tuesday, and a few others to compare:
|Vendor||Patch Name||Vendor Security||CVSS Score|
|Chrome_v76.0.3809.100||NA||High – 8.8|
|Microsoft||KB4462137||Critical||High – 7.8|
|Microsoft||KB4474419||NA||Critical – 9.8|
|Microsoft||KB4508433||NA||Critical – 9.8|
|The Document Foundation||LibreOffice_v6.2.5||NA||Critical – 9.8|
As you can see from the sample above, vendor severity and CVSS scores are not always aligned. If you take Microsoft’s severity rating at face value, you can potentially waste two of the most precious assets you have—time and resources. Rolling out many patches across a massive distributed IT environment takes time.
The longer a known vulnerability is left unpatched, the greater the risk of having it exploited by an attacker. Evidence suggests that attacks against known vulnerabilities spike in the hours and days after the patches are released—this is why it’s important to know how urgent a vulnerability is.
What’s the solution?
Take any vulnerability ratings with a respectful pinch of salt and start looking at independently assessed scores, such as the Common Vulnerability Scoring System (CVSS). Each month US-CERT / NIST uses CVSS to rate most patch updates the same day they are released. This gives a better idea of the risk level for a particular vulnerability to your business.
Downtime for businesses can also be extremely costly. The best approach to patching is to have a dedicated window of downtime each month to update systems. If there is a compatibility issue with a patch and systems need to be rolled back, this extends the downtime and can impact the bottom line of a business.
However, this is a service we provide to clients. We analyze the binary code for each patch update and begin testing and piloting the updates before deploying them through Cloud Management Suite. This allows us to discover any problems with patch updates before they’re implemented.
Patching is all about improving your security posture. By taking a measured approach and using independently assessed scores, you can confidently prioritize which patches need to roll out.