Vulnerability Scoring – The good, the bad, the ugly
Vulnerability Scoring
What is vulnerability scoring?
Vulnerabilities are something that most IT-organizations are trying to eliminate or minimize the effect of in their IT- and OT-environments.
Vulnerabilities are often tracked and referenced as “CVEs” (short for “Common vulnerability and Exposure“). Adding to the complexity is that there are many thousands of new vulnerabilities (or CVEs) created each year. And also that there are a few different scoring systems for vulnerabilities.
The vulnerability scoring systems focus on different things, and are maintained by different organizations. Some have open information, and some are proprietary and you need to pay for it. But the common denominator of them is that they all try to help organizations to assess and prioritize vulnerabilities. (Assess and prioritize are step 2 and 3 in vulnerability management).
But it should be noted that these scorings are general scorings, and non-environment-specific. Meaning that the scoring is based on information on the vulnerability but every organization and environment are different and implements things differently. So a vulnerability in one environment that is critical, can in another environment be completely benign and should probably not be prioritized at all (we’ll talk more about that under the headline “What are the downsides with vulnerability scoring”)
What’s the strengths of using vulnerability scoring
By using an industry standard everyone working with vulnerabilities can have a common ground and a way to communicate with each other’s about the vulnerabilities.
Having vulnerabilities is a bad thing, that’s something most of us agree on. But how do security researcher X communicate to researcher Y, or to an IT-operator, or an IT-operations manager that vulnerability 1 is much more important to focus on than vulnerability 2?
The answer is having a type of scoring where we can say that vulnerability 1 has a score of for example 9 (out of 10) and vulnerability 2 has a score of 5. Then vulnerability 1 should probably be prioritized first.
The way this is normally done is by having an open and transparent way of how the score is calculated. Coupled with clear information on what the different numbers mean (for example: 10 is critical, and 3 is Low).
So with this in mind some of the strength are:
Standardized Communication:
Vulnerability scoring offers a standardized way for IT professionals, security researchers, and management to communicate about the severity and priority of vulnerabilities. By assigning a numerical score, different stakeholders can easily understand and discuss which vulnerabilities need urgent attention. Also, it is easier to understand and discuss which vulnerabilities can be deferred. This common language helps bridge the gap between technical teams and non-technical decision-makers. Not to mention, ensuring everyone is aligned on the organization’s security priorities.
Prioritization and Resource Allocation:
One of the primary challenges in vulnerability management is determining which vulnerabilities to address first, especially when resources are limited. Vulnerability scores provide a clear, quantifiable method for prioritizing threats. High-scoring vulnerabilities can be flagged for immediate action, while lower-scoring vulnerabilities can be scheduled for future updates. This prioritization is crucial for optimizing the use of security resources. Enabling the organizations to focus efforts where they are needed most to protect critical systems.
Risk Assessment and Management:
Vulnerability scores are often based on multiple factors, including the potential impact of the vulnerability, the complexity of an exploit, and the likelihood of exploitation. This comprehensive approach allows organizations to assess risk more effectively. Such as taking into account not just the presence of a vulnerability but its potential consequences. By integrating these scores into a broader risk management framework, organizations can make informed decisions that balance security needs with business objectives.
Transparency and Accountability:
Most scoring systems, such as CVSS, are based on open and transparent methodologies. This transparency ensures that the criteria for scoring are clear and consistent. Thereby allowing organizations to understand exactly why a particular vulnerability has been assigned a specific score. This openness also fosters accountability. For example as organizations can track and review how vulnerability scores are determined and adjust their response strategies accordingly.
Scalability:
In environments with thousands of vulnerabilities, manually assessing and prioritizing each one would be impractical. And to be honest, most organizations are dealing with hundreds, if not thousands, of vulnerabilities. (Based on our assessments, we typically observe an average of over 7,000 vulnerabilities per customer).
Scoring systems automate much of this process, allowing organizations to scale their vulnerability management efforts across large, complex infrastructures. This scalability is essential for keeping up with the ever-growing number of vulnerabilities discovered each year. This to help organizations stay ahead of potential threats.
Facilitating Automated Processes:
Many modern security tools and vulnerability management platforms integrate vulnerability scoring into their automated workflows. For example, vulnerability scanning tools can automatically assign scores and generate reports that highlight critical issues. This automation streamlines the vulnerability management process, reducing the time and effort required to identify and respond to threats.
Benchmarking and Continuous Improvement:
Vulnerability scores provide a benchmark that organizations can use to measure their security posture over time. Organizations can track how scores change as vulnerabilities are patched or new ones are discovered. This then enables them to assess the effectiveness of their security measures and identify areas for improvement. This ongoing monitoring supports a cycle of continuous improvement, helping organizations adapt to evolving threats and maintain robust security defenses.
“Based on our assessments, we typically observe an average of over 7,000 vulnerabilities per customer.”
(Number calculated spring 2024)
By leveraging these strengths, vulnerability scoring becomes an indispensable tool in the cybersecurity arsenal. IT enables organizations to manage vulnerabilities more effectively, reduce risk, and protect their critical assets from potential threats.
What are the downsides with vulnerability scoring
While vulnerability scoring is a powerful tool for prioritization, it is not without its limitations. Some of the downsides include:
Over-reliance on Scores:
There is a risk of organizations relying too heavily on scores without considering the broader context of their environment. For example, a vulnerability with a lower score may be more critical in a specific context due to its location in a highly sensitive system or its exposure to external threats.
Often this sort of prioritization is done by an expert with insights into the IT-environment and the needs of the organization. But software tools can in some cases also help with these sorts of enrichments.
But we really would like to highlight that it is important not only to detect vulnerabilities. It is important to also do enrichments of that data with information about the current threat landscape. Including the architecture of the IT-environment, the needs/prioritization of the organization, and so on.
Subjectivity and Inconsistencies:
Different scoring systems may use varying methodologies, leading to inconsistencies in scores across platforms. This can create confusion, especially when different departments or stakeholders use different scoring systems.
Lag in Scoring Updates:
Vulnerability scores may not be updated in real-time, especially in rapidly evolving threat landscapes. This lag can lead to delayed responses to emerging threats.
This is a minor problem for most organizations, since the scoring is usually done within a couple of hours. But depending on the business need this might be a problem for some organizations. (But if you only can patch once a week, then it might not be a problem if the scoring takes a few hours…)
Ignoring Contextual Factors:
Some scoring systems may not account for specific organizational factors. For example, the presence of mitigating controls or the potential impact of a vulnerability on business operations. At first glance this point is reminding of the first one about over-reliance on scores, but there is a difference. The first point is about how important/sensitive the system is for your organization. In contrast, this point focuses more on if there are mitigating factors. (Like for example an unpatched webserver is secured behind a proxy. Or an unpatched or end-of-life system is segmented into a secured network and only accessed though a virtual desktop).
Complexity and Misinterpretation:
The calculations behind some scores can be complex. This in turn, leading to misinterpretation by non-technical stakeholders who may not fully understand the implications of the score.
Some scores try to mitigate this by showing a vector, or the different parts of the calculation to enable the analyst to do their own assessment. But then we still relies on the expertise of the person doing the assessment. And if that person only does this from time to time the risk of misinterpretation increases.
Not every vulnerability is an CVE
The IT and OT environments of today are complex. There are vast numbers of applications, databases, hardware, operating systems, applications, cloud systems, and IoT/OT devices. While many vulnerabilities are tracked and referenced as CVEs, it’s important to recognize that not all vulnerabilities are cataloged in this way.
Many vulnerabilities are disclosed by vendors and may not immediately be assigned a CVE. These can include zero-day vulnerabilities, proprietary software issues, and vulnerabilities in less commonly used systems.
Vulnerabilities can also arise from misconfigurations or poor implementation practices. These issues may not have a CVE associated with them but can still pose significant risks to the organization.
For organizations that develop custom software, vulnerabilities within these applications may not be covered by the CVE system. Identifying and addressing these vulnerabilities requires robust internal processes and tools.
Understanding that not all vulnerabilities are listed as CVEs emphasizes the need for a comprehensive approach to vulnerability management. This includes using multiple sources of threat intelligence, performing regular security assessments, and maintaining a proactive stance on potential vulnerabilities that may not be captured by traditional databases.
Common vulnerability scoring systems
Several widely recognized vulnerability scoring systems are used across industries, each with its strengths and focus areas:
| Scoring System | Description |
|---|---|
| CVSS (Common Vulnerability Scoring System) | The most widely used scoring system, CVSS is maintained by the Forum of Incident Response and Security Teams (FIRST). It provides an open framework for communicating the characteristics and severity of software vulnerabilities. CVSS scores are typically composed of three metric groups: Base, Threat, and Environmental, offering a comprehensive view of the risk posed by a vulnerability. CVSS v1 as launched in 2005. This was then replaced by CVSS v2 in June 2007. The versions in use today are version 3.1 (released in June 2019), and version 4.0 that was officially released in November 2023. Not all all systems out there are updated to use v4.0 yet, so version 3.1 is still used by many (please note that the different versions calculate the score a little different so the same vulnerability can get different scores depending on the version used. Therefore when presenting a score it is customary to also include the version used. Eg. “CVSS:3.1 Score: 7.0” or “CVSS:4.0 Score 7.3”) CVSS is a score between 0 and 10 where 10.0 is the highest. – 0.1 – 3.9 = Low – 4.0 – 6.9 = Medium – 7.0 – 8.9 = High – 9.0 – 10.0 = Critical For more information about CVSS please see: https://www.first.org/cvss/ What we have seen is that many organizations states that all vulnerabilities with a CVSS score with 7.0 or higher have to be patched. But this is a rather blunt rule. It does not take into context the likelihood of the vulnerability being exploited or if there has been some other mitigations done. |
| EPSS (Exploit Prediction Scoring System) | EPSS focuses on predicting the likelihood of a vulnerability being exploited in the wild. This to compliment CVSS (that focuses more on the technical side of attack vector, complexity, requirements and so on). By using machine learning and historical data, it helps organizations prioritize vulnerabilities based on the real-world likelihood of exploitation. EPSS was first presented at Blackhat 2019, and the latest version was released in March 2023. The EPSS model produces a probability score between 0 and 1 (0 and 100%). The higher the score, the greater the probability that a vulnerability will be exploited. EPSS is a daily estimate of the probability of exploitation activity being observed over the next 30 days. For more information about EPSS please see: https://www.first.org/epss/ This is a quite new standard, but it helps solving the issue of prioritizing vulnerabilities. There are only so much resources in IT-organizations and they should be used where they do the most good. |
| Proprietary scoring systems | Some organizations, such as Tenable and Qualys, offer proprietary vulnerability scoring systems integrated into their vulnerability management platforms. These systems often enhance or build upon CVSS to provide additional context or prioritization tailored to specific industries or environments |
Other vulnerability sites and organisations
In addition to First (with CVSS and EPSS), several other organizations and platforms provide valuable resources for tracking and managing vulnerabilities:
| Site/organization | Description |
|---|---|
| NVD (National Vulnerability Database) | Managed by the National Institute of Standards and Technology (NIST), the NVD is a comprehensive repository of vulnerability data. It includes CVE information, along with CVSS scores, and provides additional analysis such as impact metrics and references to related exploits. Link: https://nvd.nist.gov/ |
| CVE (Common Vulnerabilities and Exposures) | The CVE program (Common Vulnerabilities and Exposures) is a standardized system for identifying and cataloging publicly known cybersecurity vulnerabilities. Each vulnerability receives a unique identifier, or CVE ID, which makes it easier for organizations to track, assess, and communicate about specific vulnerabilities across different systems and tools. Managed by MITRE, the CVE program is a critical component in global cybersecurity, providing a common reference for security professionals. Link: https://www.cve.org/ |
| CWE framework | The CWE (Common Weakness Enumeration) framework, also managed by MITRE, complements the CVE program by focusing on the underlying software and hardware weaknesses that can lead to vulnerabilities. CWE categorizes these weaknesses, offering a structured approach to understanding the root causes of security flaws, which can help in preventing vulnerabilities during the development process. Link: https://cwe.mitre.org/ |
| ATT&CK framework | The ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) framework, another MITRE initiative, is a comprehensive matrix that describes the tactics, techniques, and procedures (TTPs) used by adversaries in real-world cyberattacks. ATT&CK helps organizations understand how attackers operate, enabling them to strengthen their defenses, detect malicious activities, and respond effectively to threats. Link: https://attack.mitre.org/ |
| OSV (Open Source Vulnerabilities) | The Open Source Vulnerability (OSV) database is a project by Google aimed at improving the security of open-source software. OSV provides a comprehensive, open, and searchable database of vulnerabilities specifically for open-source packages across various ecosystems, including Python, Go, Rust, Java, and more. The OSV service is designed to streamline the process of vulnerability management for developers and security teams by offering precise and up-to-date information about vulnerabilities in open-source dependencies. Link: https://osv.dev/ |
| CISA KEV (Known Exploited Vulnerability Catalog) | This is an authoritative source of vulnerabilities that have been exploited in the wild. It is maintained by the Cybersecurity and Infrastructure Security Agency (CISA) and can be used as an input to vulnerability management prioritization. Link: https://www.cisa.gov/known-exploited-vulnerabilities-catalog |
| Bug Bounty Platforms | Platforms like HackerOne and Bugcrowd host bug bounty programs where security researchers can report vulnerabilities in exchange for rewards. These platforms often uncover vulnerabilities that may not yet have a CVE or public disclosure. Link: https://www.hackerone.com/ https://www.bugcrowd.com/ |