Late last year, news spread in the cybersecurity community about the zero-day Apache Log4j vulnerability. This vulnerability was somewhat unique—it was dangerous enough to warrant breathless news coverage, causing concern far outside of cybersecurity circles. RSM’s advice for organizations affected by the vulnerability was simply, “Drop everything and fix it. Now.” That level of urgency was easy for businesses to understand.
But as cybersecurity experts are all too aware, most vulnerabilities, even serious ones, fall under the radar. “Drop everything and fix it” means much more to a C-suite member than news about “CVE-2021-44228.”
So what about vulnerabilities that don’t make headlines? For those, it first helps to understand what exactly is meant by Common Vulnerabilities and Exposures (CVE). But it’s not enough to know what designates a vulnerability—the question that always follows is, “Just how will this impact the business?” For that, it’s helpful to consider Common Vulnerability Scoring System (CVSS).
As with most issues in the business world, if you can’t put a number on it, it may as well not exist.
What is a CVE ID and Why Does It Matter?
A CVE ID is a unique set of letters and numbers assigned to a specific vulnerability. Every CVE follows the format: [CVE Prefix] – [year the vulnerability was identified] – [arbitrary digits] (i.e., CVE-YYYY-NNNN). Note that there is no limit on the number of arbitrary digits in a CVE ID.
CVE was first introduced by David Mann and Steven Christey in a 1999 white paper titled, “Towards a Common Enumeration of Vulnerabilities.” After the paper was officially launched with a list of 321 CVE records in September of the same year, it was quickly adopted by a multitude of companies and groups. The National Institute of Standards and Technology recommended that U.S. agencies use CVE in 2002, and today CVE is used all over the world and by virtually every software vendor and trade publication in product alerts.
CVEs are assigned by CVE Number Authorities (CNAs), which consist of 215 organizations that include software vendors, open-source projects, coordination centers, bug bounty service providers, hosted services and research groups.
And just what does a “vulnerability” mean in this context? CNAs are able to determine what is or isn’t a vulnerability, but there are a few rules. If a product owner considers it a vulnerability, then it is always a vulnerability. If a CNA receives a report from a party that is not a product owner, then they may decide if it is or is not a vulnerability.
A CVE ID is given only to an “independently fixable vulnerability” (i.e., if one vulnerability can be fixed without fixing another, both receive CVEs; if a vulnerability is fixed as a result of another vulnerability being fixed, only one would receive a CVE).
To determine if a vulnerability should be published, it goes through a multi-step process. First, someone discovers a vulnerability, and they report it to a CVE program participant. That participant then requests a CVE ID—though this may not be used, it acts as a placeholder while the vulnerability is researched. Once all the details of a vulnerability are put together (e.g., affected/fixed product versions, vulnerability type, root cause), the CNA can publish it to the publicly available CVE list. Once published, a CVE can be rejected, but remains on the list so a user knows that it is no longer in use.
CVSS Scores—Helping Vulnerabilities Make Sense
It’s all well and good to have a process for naming vulnerabilities, but that still doesn’t explain why they should be acted upon. For that, enter the CVSS.
If the CVE is the what, then the CVSS is the why. This system is an open framework that can be used to put a base number (which corresponds to a qualitative descriptor) on a vulnerability. These scores differ depending on which version of the CVSS is used (more on that later). Versions 2.0 and 3.X (3.1 is the most recent) are still widely supported, depending on the need.
CVSS scores are broken down this way:
Those base scores can then be altered by temporal (metrics that change over time due to external factors) and environmental (customized to the impact of a vulnerability on a particular organization) scores.
It is important to note that base scores and descriptions measure the severity of a vulnerability and should not be used alone to describe the risk of a vulnerability.
CVSS 3.X was designed to provide a more comprehensive picture of a vulnerability and what it impacts that vulnerability may have on what systems. This means that many scores change depending on if you view them in CVSS v2.0 or CVSS v3.1.
Overall, a survey by Cisco found that the average score of all vulnerabilities changed from a 6.5 in v2.0 to 7.4 in v3.0. That survey also found that 1077 vulnerabilities changed from low or medium to high or Critical, a 52% increase in high or critical vulnerabilities.
Regardless of the version you use, however, these scores provide a valuable way to explain why an executive would spend valuable company resources to fix a vulnerability. When it comes to reports, it helps to cut through the jargon and tell an executive, “This is a high-rated vulnerability, and we need X resources and X dollars to fix it.” These scores put valuable information in concrete terms that any reader can understand.
Overall, CVE and CVSS work together to help explain what a vulnerability is, what it impacts, how it can be fixed and how severe that vulnerability could be to an organization—all vital steps for helping an organization prioritize and mitigate threats in a way that can be understood by everyone in the C-suite.
