With hundreds of thousands of vulnerabilities in the National Vulnerability Database, it’s no wonder I get multiple client inquiries on how to make sense of the volume of vulnerabilities and implement an effective remediation strategy. My recent report, How To Strengthen Vulnerability Risk Management With Remediation Prioritization, details what security teams should consider for their vulnerability remediation prioritization plans.
While conducting our research interviews, several publicly available vulnerability risk resources were mentioned multiple times. Organizations of all sizes should understand these resources with the understanding that utilizing only one will not mitigate all vulnerability risks. A comprehensive vulnerability risk strategy needs input from multiple resources, but more importantly requires inputs on factors specific to each organization, including business mission, vision, critical processes, and specifics around its technology stack and security controls. Here is a quick summary of the most useful resources:
- Common Vulnerabilities and Exposures (CVE) is a database storing known software vulnerabilities. The CVE database has been maintained by MITRE since 1999 and feeds into NIST’s National Vulnerability Database (NVD). When a security researcher, bug bounty hunter, or software developer detects a vulnerability, they report it to a CVE Numbering Authority (CNA), who evaluates the report and assigns the vulnerability a unique CVE-ID. You may recognize the CVE-ID as the familiar format of “CVE-YEAR-12345” (the infamous Log4J vulnerability being CVE-2021-44228). We commonly refer to vulnerabilities that have been accepted into the CVE database as … a “CVE.” Note that not all vulnerabilities are stored within the CVE database or have a CVE-ID issued.
- The Common Vulnerability Scoring System (CVSS) provides technical severity, but not your riskiest vulnerability. CVEs are often scored with the Common Vulnerability Scoring System on NIST’s NVD, although the scoring system itself is developed and maintained by a Special Interest Group through first.org. Despite the frequency at which we hear about CVSS-based prioritization procedures, CVSS was intended to capture common characteristics of vulnerabilities to quantify technical severities — not prioritize vulnerabilities exposing the biggest risk to your organization. It does, however, let us know how bad a vulnerability could be and gives us a common language to use when discussing and scoring vulnerabilities across the industry.
- The Exploit Prediction Scoring System (EPSS) aims to calculate the probability that a vulnerability will be exploited. EPSS analyzes CVEs that have already been exploited in the wild, along with hundreds of variables, to predict what the yet-to-be exploited CVE will be and when. It is maintained by a separate Special Interest Group at first.org and utilizes statistical modeling techniques to determine an EPSS probability score. Foundational to measuring the EPSS model are the concepts of capacity, efficiency, and coverage, which recognize that not all vulnerabilities can be fixed, so organizations should measure vulnerabilities that weren’t prioritized but exploited before the remediation date, as well as vulnerabilities that were prioritized, but never exploited.
- Stakeholder Specific Vulnerability Categorization (SSVC) uses decision trees to identify qualitative impacts of vulnerability exploits and an organization’s response. SSVC was published in 2019 by Carnegie Mellon’s Software Engineering Institute, with collaboration and endorsement from CISA. This method ensures that all inputs and outputs are qualitative and that each output yields another transparent and explainable decision. CISA recently published its own SSVC decision tree model and calculator, which organizations can borrow and/or learn from when building their own SSVC model.
- CISA Known Exploited Vulnerabilities (KEV) informs security teams of vulnerabilities that are known to be exploited. CISA’s Known Exploited Vulnerabilities publishes a catalogue of vulnerabilities known to be exploited in the wild, which mandates that federal agencies remediate within the prescribed timeframes. Private organizations can, and should, utilize this list to prioritize vulnerabilities as well.
- Open Web Application Security Project (OWASP) categorizes types of vulnerabilities in software. The nonprofit OWASP is known for publishing the top 10 web application security risks, but it also provides tools and training to identify and prevent secure coding vulnerabilities that can be introduced through other software development practices like CI/CD or APIs. OWASP does not issue CVEs, but the defects described in OWASP can often map to flaws in specific CVEs.
- Common Weakness Enumeration (CWE) describes security flaws in software and hardware. CWE is a MITRE-led project that, like OWASP, catalogues the types of weaknesses found in architecture, code, and implementations. It may underline a specific vulnerability and be used to describe how and why a vulnerability exists. Think of OWASP and CWE defining the “why” in a vulnerability and the CVE database and the CVE-ID as the “what.”
Many organizations utilize vulnerability risk management (VRM) vendors that incorporate a combination of these resources. Many vendors have their own scoring (and acronyms) for prioritizing remediations, which may include additional proprietary or open source components, such as threat intelligence. It’s important to understand what factors are included in your VRM vendor’s risk scoring and weighting.
But every organization is unique, and most vulnerability risk scorings require some customization to accurately gauge risk. Forrester’s Remediation Prioritization Triad recommends using a combination of business importance, threat likelihood, and strength of compensating controls when assessing remediation strategies.
If you’d like to understand more about vulnerability risk scoring, the resources above, or how you can leverage Forrester’s Remediation Prioritization Triad, please schedule an inquiry with me to discuss further.