Why Prioritizing Based on CVSS Doesn't Work

In 2005, the first YouTube video, Me at the zoo, was uploaded. Hollaback Girl was the most downloaded song. And Ed, Edd n Eddy was in its final season of a glorious run.

This is the same year the Common Vulnerability Scoring System (CVSS) was introduced.

The CVSS was created to be an open standard for assigning severity scores to Common Vulnerabilities and Exposures (CVEs). Due to the overwhelming number of vulnerabilities at the time, security teams quickly adopted CVSS as a framework for prioritization.

The year before the introduction of CVSS (2004), there were 1,612 vulnerabilities.

Last year there were over 25,000. This represented a sixth consecutive year of record vulnerability discovery. Unfortunately, the trend doesn't look to be reversing any time soon.

This is unwelcome news to teams whose security procedures are still centered on CVEs.

In addition to the ever-increasing number of vulnerabilities, attackers are getting more sophisticated. Whether it's social engineering, spear-fishing, a wireless Raspberry Pi from a parking lot, or one of the countless other methods employed by attackers, a CVE is not required for an attacker to exploit an organization.

In fact, in our experience across thousands of penetration tests over the last decade it's more common to breach an environment without using a CVE.

So if the game has so drastically changed, why are the players the same? The likely answer is inertia.

Because CVSS was adopted early on as a prioritization framework and has been the standard for so long, it's simply believed to be the best option.

How CVSS Works

First, we will explain how scores are determined and how CVSS fits into vulnerability management.

How scores are determined

CVSS attempts to rank the severity of CVEs based on theoretical exploitability and impact metrics.

Below are some examples of technical factors that go into the calculation:

Attack vector (AV): How close does an attacker need to be to exploit it? Local access? Adjacent network? Internet? Easier vectors mean higher scores.

Attack complexity (AC): Does the attack require extra steps and resources beyond access? Or is it straightforward to exploit? More complexity lowers scores.

Privileges required (PR): Does the attacker need to be an admin or can any low privilege user exploit it? The more privileges required, the lower the score.

User interaction (UI): Does a user need to click or download something to allow exploitation? Automated attacks increase scores.

These factors are combined with additional impact, temporal, and environmental factors to determine a severity rating between 0.0 and 10.0.

In theory, a higher score = more severe vulnerability.

How CVSS fits into vulnerability management

Here is how traditional vulnerability management works at a technical level:

In a CVE-centric approach, security teams will then prioritize remediation efforts based on those CVSS scores.

The Shortcomings of CVSS

There are a few major issues with this approach.

The most glaring might be that out of the 25,080 vulnerabilities last year, 12,579 (50.2%) were scored as high (7.0 - 8.9) or critical (9.0 - 10.0).

It's infeasible for teams to prioritize and act on that many vulnerabilities.

Nor do they need to.

Less than 25% of vulnerabilities with a score of 7.0 or higher have ever had an exploit published against them. And only about 15% of all CVEs are exploitable at all.

This inefficiency problem compounds when you add in the fact that attackers frequently use methods other than CVEs to exploit an environment.

Imagine if we could redirect all that talent, time, and resources to protecting what's important.

The additional shortcomings listed below highlight why the score is "theoretical":

• Lack of business context: The CVSS scores only consider technical details, not the potential business impact. A lower-scored vulnerability affecting a critical system may warrant priority over a theoretically high-risk vulnerability in a non-essential system.
  
• Static scoring: A vulnerability gets a CVSS score when it's first disclosed. These scores are hardly ever updated. The scores don't reflect how easy it is to take advantage of vulnerabilities in real life and can become outdated as threat landscapes change.
  
• One-size-fits-all approach: The same CVSS scores apply universally across organizations. However, the level of risk from vulnerabilities varies depending on the environment, including factors like the assets involved and the existing defenses.
  
• Focus on public vulnerabilities: CVSS scoring overlooks business-specific vulnerabilities in custom applications that aren't tracked by public CVE databases.

A Modern Approach: From CVE-Centric to Attacker-Centric

Somewhere along the way "CVE" became interchangeable with "vulnerability".

The standard definition of vulnerability is: the quality or state of being exposed to the possibility of being attacked or harmed. In cybersecurity, this would represent any way an attacker could harm your organization. As we've covered, this extends well beyond CVEs.

So, the first step in modernizing vulnerability management is a return to the original definition of vulnerability.

The next step is adopting an attacker-centric approach. This approach allows security teams to better protect clients, and do so more efficiently, by automating the following:

• IT asset discovery
• Attack surface mapping
• Identifying risks at the identity layer
• Categorizing tier zero and other critical assets
• Contextualizing vulnerabilities based on their relation to users, groups, and computers within the network
• Prioritizing remediation efforts by potential business impact
• Grouping of vulnerabilities by remediation strategy
• Continuous monitoring across business environment

To learn more about attacker-centric Continuous Exposure Management (CEM), visit: https://www.shieldcyber.io/