What are CVEs and How are They Scored?
Our ever-increasing reliance on technology has been both a boon and a burden to many organizations over the last couple of decades. If you keep up on the technology industry, you may have recently read articles from various technology-related news sites that go something along the lines of “Major CVE found in software – millions of servers affected” or even “Everything you know about security is wrong and we are all on fire!” Headlines like these strike fear into the hearts of many small to large businesses the world over. Questions of how this affects day-to-day operations, customer concerns about their personal information, and general uncertainty are enough to keep any business owner up at night wondering if their efforts of building their businesses and keeping data secure can feel like they are all for naught.
In the beginning, each software vendor had their own database of software flaws with varying definitions of what the significance of those flaws were. As you can imagine, this caused confusion quite often so a better system of classifying and maintaining a list of vulnerabilities was needed. In comes the Common Vulnerabilities and Exposures listings, or CVE, for short. You may have heard of such vulnerabilities as Heartbleed, Meltdown, Spectre, Dirty Cow, Shellshock and a whole gamut of problems making rounds in the news over the last few years.
Each of these more commonly known vulnerabilities actually have their own CVE number, and an associated numerical score ranging from 0-10 using a standard called the Common Vulnerability Scoring System or CVSS. These numbers are used to help security researchers, product vendors, business owners, and consumers understand and keep track of flaws discovered in software that could potentially allow malicious actors to get their hands on sensitive information.
Just what exactly does a CVE listing look like? Below are some examples of the more popular CVEs that have made their rounds in the news and I’ll be providing a quick overview of how these are structured and what information they convey.
CVE-2017-5715
CVE-2017-5753
CVE-2017-5754
CVE-2014-0160
CVE-2016-10012
CVE-2014-6271
These listings may look quite familiar to you. The general structure of a CVE listing is as follows. They are always prefixed with CVE, following the year of discovery (e.g, 2018), and unique arbitrary number. There are some vendors that do have reservations of the last grouping of digits in a CVE listing. As mentioned earlier, each CVE item has a calculated CVSS. These scores are calculated using various metrics that include but are not limited to ease of exploitation, data confidentiality and integrity, level of access or authentication required (if any), among other variables. Those metrics are beyond the scope of this article, but if you find yourself curious about the subject, I recommend viewing the scoring guidelines posted below.
— CVSSv3.0 Scoring Equations —
Source: https://www.first.org/cvss/specification-document – Section 8.{1,2,3}
The Base Score is a function of the Impact and Exploitability subscore equations. Where the Base Score is defined as:
If (Impact sub-score <= 0) 0 else,
Scope Unchanged = RoundUp (Minimum [(Impact + Exploitability),10])
Scope Changed = RoundUp (Minimum [1.08 × (Impact + Exploitability),10])
and the Impact sub-score (ISC) is defined as,
Scope Unchanged = 6.42 × ISCBase
Scope Changed = 7.52 × [ISCBase ? 0.029] ? 3.25 × [ISCBase ? 0.02]
Where,
ISCBase = 1 – [(1 ? ImpactConfidentiality) × (1 ? ImpactIntegrity) × (1 ? ImpactAvailability)]
And the Exploitability sub-score is,
8.22 × AttackVector × AttackComplexity × PrivilegeRequired × UserInteraction
What does this mean to me?
At first glance, this can seem quite overwhelming and not of much use to an individual who is not a security professional. No worries, we’re here to help shed some light on how all this fits together. Think of this as a general road map to how vulnerabilities are scored. These scores are meant to give a basic understanding of the severity of a given CVE listing, but can go much deeper depending on various environmental factors and how your organization can be impacted. In general, the higher the CVSS score, the more severe a vulnerability. As a result, higher scores mean these items should be given more priority for review within your organization.
While scores can serve as a good baseline to assess your environment’s risk, they are far from telling the whole story. For instance, some vulnerabilities might have a score of 6.3 which one could possibly argue as potentially significant issue and only affect the availability of services and not being able to modify or disclose sensitive information. There are also cases where in PCI reports, not having a specific version of software installed automatically constitutes a failure of that audit. A lot of vendors will frequently only check versions of installed software and check if there is a known CVE against that particular version. If a result is made, your PCI vendor fails you on this without taking into consideration any preventative measures or other mitigations.
Most CVE failures in PCI scan reports can typically be addressed in two ways.
- Reviewing package changelogs against a particular CVE or list thereof as shown below.
[josh@desktop-vm ~] # rpm -qa openssh --changelog | grep 'CVE-2015-8325' - CVE-2015-8325: privilege escalation via user's PAM environment and UseLogin=yes (#1329191)
- Mitigating vulnerabilities by adjusting configuration values of affected software.
In either case, you will want to review the appropriate security errata from your software vendor. This can be a daunting task, but it is a necessary task as part of maintaining any software environment. We understand that this can be a time-consuming and ongoing process, but you can certainly ask the most helpful humans in hosting to help you through the process of ensuring your environment remains secure.
In conclusion, CVE listings are a tool to help you ensure the security of your business operations. New vulnerabilities are being discovered every day and as a result, we’re slowly making progress to writing more effective and secure software.
You can find out more about CVEs and how to mitigate vulnerabilities on the sites listed below.
https://www.first.org/cvss/specification-document
https://www.first.org/cvss/user-guide#5-Scoring-Rubric