Common mistakes in using CVSS | Kaspersky official blog

Common mistakes in using CVSS | Kaspersky official blog

/in

When you first encounter CVSS (Common Vulnerability Scoring System), it’s easy to think this is the perfect tool for triaging and prioritizing vulnerabilities. A higher score must mean a more critical vulnerability, right? In reality, that approach doesn’t quite work out. Every year, we see an increasing number of vulnerabilities with high CVSS scores. Security teams just can’t patch them all in time, but the vast majority of these flaws are never actually exploited in real-world attacks. Meanwhile, attackers are constantly leveraging less flashy vulnerabilities with lower scores. There are other hidden pitfalls too — ranging from purely technical issues like conflicting CVSS scores to conceptual ones like a lack of business context.

These aren’t necessarily shortcomings of the CVSS itself. Instead, this highlights the need to use the tool correctly, as part of a more sophisticated and comprehensive vulnerability management process.

CVSS discrepancies

Do you ever notice how the same vulnerability might have different severity scores depending on the available source? One score from the cybersecurity researcher who found it, another from the vendor of the vulnerable software, and yet another from a national vulnerability database? It’s not always just a simple mistake. Sometimes, different experts can disagree on the context of exploitation. They might have different ideas about the privileges with which a vulnerable application runs, or whether it’s internet-facing. For instance, a vendor might base its assessment on its recommended best practices, while a security researcher might consider how applications are typically configured in real-world organizations. One researcher might rate the exploit complexity as high, while another deems it low. This isn’t an uncommon occurrence. A 2023 study by Vulncheck found that 20% of vulnerabilities in the National Vulnerability Database (NVD) had two CVSS3 scores from different sources, and 56% of those paired scores were in conflict with each other.

Common mistakes when using CVSS

For over a decade, FIRST has advocated for the methodologically correct application of CVSS. Yet organizations that use CVSS ratings in their vulnerability management processes continue to make typical mistakes:

  1. Using the CVSS base score as the primary risk indicator. CVSS measures the severity of a vulnerability — not when it will be exploited or the potential impact of its exploitation on the organization under attack. Sometimes, a critical vulnerability is harmless within a specific company’s environment because it resides in insignificant and isolated systems. Conversely, a large-scale ransomware attack might begin with a seemingly innocuous information leak vulnerability with a CVSS score of 6.
  2. Using the CVSS Base score without Threat/Temporal and Environmental adjustments. The availability of patches, public exploits, and compensatory measures significantly influences how and how urgently a vulnerability should be addressed.
  3. Focusing only on vulnerabilities above a certain score. This approach is sometimes mandated by government or industry regulators (“remediate vulnerabilities with CVSS score above 8 within one month”). As a result, cybersecurity teams face a continuously growing workload that, in reality, doesn’t make their infrastructure more secure. The number of vulnerabilities with high CVSS scores identified annually has been rapidly increasing over the past 10 years.
  4. Using CVSS to assess the likelihood of exploitation. These metrics are poorly correlated: only 17% of critical vulnerabilities are ever exploited in attacks.
  5. Using only the CVSS rating. The standardized vector string was introduced in CVSS so that defenders could understand the details of a vulnerability and independently calculate its importance within their own organization. CVSS 4.0 was specifically revised to make it easier to account for business context using additional metrics. Any vulnerability management efforts based solely on a numerical rating will largely be ineffective.
  6. Ignoring additional sources of information. Relying on a single vulnerability database and analyzing only CVSS is insufficient. The absence of data on patches, working proofs of concept, and real-world exploitation cases makes it difficult to decide how to address vulnerabilities.

What CVSS doesn’t tell you about a vulnerability

CVSS is the industry standard for describing a vulnerability’s severity, the conditions under which it can be exploited, and its potential impact on a vulnerable system. However, beyond this description (and the CVSS Base score), there’s a lot it doesn’t cover:

  • Who found the vulnerability? Was it the vendor, an ethical researcher who reported the flaw and waited for a patch, or was it a malicious actor?
  • Is there an exploit publicly available? In other words, is there readily available code to exploit the vulnerability?
  • How practical is it to exploit in real-world scenarios?
  • Is there a patch? Does it cover all vulnerable software versions, and what are the potential side effects of applying it?
  • Should the organization address the vulnerability? Or does it affect a cloud service (SaaS) where the provider will automatically fix the defects?
  • Are there signs of exploitation in the wild?
  • If there are none, what’s the likelihood attackers will leverage this vulnerability in the future?
  • Which specific systems within your organization are vulnerable?
  • Is the exploitation practically accessible to an attacker? For example, a system might be a corporate web server accessible to anyone online, or it could be a vulnerable printer physically connected to a single computer that has no network access. A more complex example might be a vulnerability in a software component’s method, where the specific business application using that component never actually calls the method.
  • What would happen if the vulnerable systems were compromised?
  • What’s the financial cost of such an event to the business?

All these factors significantly influence the decision of when and how to remediate a vulnerability — or even if remediation is necessary at all.

How to amend CVSS? RBVM has the answer!

Many factors that are often hard to account for within the confines of CVSS are central to a popular approach known as risk-based vulnerability management (RBVM).

RBVM is a holistic, cyclical process, with several key phases that repeat regularly:

  • Inventorying all IT assets of your business. This includes everything from computers, servers and software, to cloud services and IoT devices.
  • Prioritizing assets by importance: identifying your crown jewels.
  • Scanning assets for known vulnerabilities.
  • Enriching the vulnerability data. This includes refining CVSS-B and CVSS-BT ratings, incorporating threat intelligence, and assessing the likelihood of exploitation. Two popular tools for gauging exploitability are EPSS (another FIRST rating that provides a percentage probability of real-world exploitation for most vulnerabilities), and consulting databases like CISA KEV, which contains information about vulnerabilities actively exploited by attackers.
  • Defining the business context: understanding the potential impact of an exploit on vulnerable systems, considering their configurations and how they’re used within your organization.
  • Determining how the vulnerability can be neutralized through either patches or compensatory measures.
  • The most exciting part: assessing the business risk and setting priorities based on all the gathered data. Vulnerabilities with the highest probability of exploitation and possible significant impact on your key IT assets are prioritized. To rank vulnerabilities, you can either calculate CVSS-BTE — incorporating all collected data into the Environmental component, or use alternative ranking methodologies. Regulatory aspects also influence prioritization.
  • Setting deadlines for each vulnerability’s resolution based on its risk level and operational considerations, such as the most convenient time for updates. If updates or patches aren’t available, or if their implementation introduces new risks and complexities, compensatory measures are adopted instead of direct remediation. Sometimes, the cost of fixing a vulnerability outweighs the risk it poses, and a decision might be made not to remediate it at all. In such cases, the business consciously accepts the risks of the vulnerability being exploited.

In addition to what we’ve discussed, it’s crucial to periodically analyze your company’s vulnerability landscape and IT infrastructure. Following this analysis, you need to introduce cybersecurity measures that prevent entire classes of vulnerabilities from being exploited or significantly boost the overall security of specific IT systems. These measures can include network micro-segmentation, least privilege implementation, and adopting stricter account management policies.

A properly implemented RBVM process drastically reduces the burden on IT and security teams. They spend their time more effectively as their efforts are primarily directed at flaws that pose a genuine threat to the business. To grasp the scale of these efficiency gains and resource savings, consider this FIRST study. Prioritizing vulnerabilities using EPSS alone allows you to focus on just 3% of vulnerabilities while achieving 65% efficiency. In stark contrast, prioritizing by CVSS-B requires addressing a whopping 57% of vulnerabilities with a dismal 4% effectiveness. Here, “efficiency” refers to successful remediation of vulnerabilities that have actually been exploited in the wild.

Kaspersky official blog – ​Read More