KEV Catalog Reaches 1000, What Does That Mean and What Have We Learned
By: Eric Goldstein, Executive Assistant Director for Cybersecurity, Elizabeth Cardona and Tod Beardsley
Every organization is confronted by a common cybersecurity challenge: there are too many vulnerabilities in technology products. This makes it difficult to prioritize limited resources – with over 25,000 new vulnerabilities released in 2022 alone, where should an organization begin? As a starting point, we know that the majority of vulnerabilities are never exploited by malicious actors. With that understanding, we launched the Known Exploited Vulnerabilities catalog (known simply as “The KEV”) in November 2021 to provide an authoritative source of vulnerabilities that have been exploited “in the wild.” The purpose of the KEV is simple: while focusing on vulnerabilities that have been exploited isn’t sufficient, it’s absolutely necessary – so let’s start there.
Recently, the catalog has grown to cover more than 1,000 vulnerabilities, which seems like an appropriate time to check in. In this blog, we review how the KEV program works and what we’ve learned along the way, how organizations can most effectively use the KEV, improvements in the pipeline, and, most importantly, how we can reduce the prevalence of vulnerabilities by design.
We’ll start with the two most important points up front: first, every organization should be prioritizing mitigation of KEVs as part of a vulnerability management program that enables prioritization based on organizational attributes such as how a vulnerable product is being used and the exploitability of the relevant system; and, second, as noted in the National Cybersecurity Strategy, “poor software security greatly increases systemic risk across the digital ecosystem and leaves Americans bearing the ultimate cost”; to that point, we must work to ensure that all technology providers develop and deliver products that reduce vulnerabilities by design.
How does it work?
Providing an authoritative catalog is no trivial matter, and our team has developed three standardized criteria to identify which vulnerabilities to include in the KEV. The process for validating which vulnerabilities to consider for KEV inclusion, out of the quarter million vulnerabilities we know about, can be arduous and time-consuming.
First, every candidate vulnerability needs to have a CVE ID so organizations can know precisely which vulnerabilities we’re talking about when we add them to the KEV. Even this straightforward criterion can present challenges. When evaluating zero-day vulnerabilities, we are in a race against time. These vulnerabilities may not have a reserved CVE ID, which could slow down any defensive action by public and private organizations. To mitigate this, our team works with vendors, open-source projects, and the CVE program to ensure that every vulnerability that is exploited in the wild is properly identified with a CVE ID.
Second, our analysts need evidence that threat actors are actively exploiting the vulnerability in the wild. This evidence needs to be from a credible source – a known industry partner, a trusted security researcher, or a government partner. This can be a significant challenge since even the software manufacturers may not be tracking initial exploitation. We can find ourselves chasing whispers of exploitation in the wild that circulate online. Adding to the challenge is that some adversaries are elusive and sophisticated, leaving barely a trace of their digital footprints. We focus on validating our sources and data quality and differentiate between scanning for the presence of the vulnerability and threat actors attempting to or actively exploiting that vulnerability. Often, we delve into detective work, as even the best sources may have only incomplete evidence. Sorting through vast amounts of data to distinguish genuine, malicious exploitation can be daunting.
Finally, there needs to be an effective mitigation available to resolve the issue; after all, knowing about a vulnerability doesn’t do defenders much good unless there’s something to act on. Our team spends hours scouring security forums, manufacturer websites, open-source mailing lists, end-of-life announcements, and vulnerability databases to search for a patch or official mitigation guidance. If we cannot locate remediation information, then we need to contact the software manufacturer, urging them to expedite the patch's development and release or clarify their own public mitigation messaging. This process can take days depending on correspondence response times and the stage of patch development. Sometimes it’s impossible to find an official patch. In these instances, we coordinate alternative messaging to inform the public about the vulnerability with actions that should be taken so there’s something that can be done to prevent exploitation. In any event, we don’t add a vulnerability to the KEV unless there is an actionable patch or other suitable mitigation.
Are we making progress?
Creating a catalog is just a first step. As described in our Cybersecurity Strategic Plan, “we must ensure that all of our efforts have a measurable impact in reducing cybersecurity risk, whether directly or indirectly, and rigorously leverage available data in determining whether our intended impacts are being achieved.” Let’s ask the key question: are we seeing progress in fixing KEVs more quickly? At the outset, it bears reminding that the KEV Catalog was accompanied by a Binding Operational Directive to federal civilian executive branch (FCEB) agencies requiring those agencies to remediate internet-facing KEVs within 15 days and all other KEVs within 25 days.
Since November 2021, FCEB agencies have remediated more than 12 million KEV findings, including over 7 million this calendar year alone
FCEB agencies have demonstrated a 72% decrease in the percentage of KEVs exposed for 45 or more days
State, local, tribal, and territorial (SLTT) governments and critical infrastructure entities enrolled in our vulnerability scanning service demonstrated a 31% decrease in the percentage of KEVs exposed for 45 or more days
The mean-time-to-remediate KEVs was an average of nine days faster than for non-KEVs – and 36 days faster for Internet-facing KEVs.
How should the KEV be used?
As mentioned above, using the KEV to prioritize vulnerability management is a starting point, not a finish line. As the number of vulnerabilities in the catalog passed 1,000, we’ve often been asked how organizations can prioritize within the KEV. The answer is nuanced but essential: the importance of a given vulnerability isn’t constant, but is highly dependent on how the vulnerable product is being used in a specific instance. As an example: a KEV in an Internet-facing web server providing privileged access to customer accounts would, reasonably, be a much higher priority for mitigation than the exact same KEV in an internal system providing unprivileged access to the organization’s cafeteria menu.
This example reflects the importance of organizational attributes as a key driver of vulnerability prioritization, including through the Stakeholder Specific Vulnerability Categorization (SSVC) decision model developed in collaboration with the Carnegie Mellon Software Engineering Institute. SSVC provides CISA a methodology to analyze vulnerabilities, taking into consideration unique aspects like exploitation status, impacts to safety, and prevalence of the affected product in a singular system. Our goal is simple: avoid one-size-fits-all prioritization criteria while providing organizations with information that can drive rigorous prioritization through models like SSVC. At the same time, we know that more information can be useful to enable organizational prioritization, so we’re moving there as well – see below!
What’s coming next?
We’ve seen real positive change from the KEV and associated Binding Operational Directive. But we’re still in the first few laps of a long-distance race. Going forward, we’re focused on a few areas of advancement:
The KEV should be easy to use – ideally incorporated into tools already being used to prioritize vulnerability management. Federal agencies are able to see their open KEVs in their Continuous Diagnostics and Mitigation (CDM) Dashboard, and commercial partners including Palo Alto Networks , Tenable , Runecast, Qualys , Wiz, and Rapid7 have incorporated the KEV into their products. Our goal is for the KEV to be incorporated wherever companies are prioritizing vulnerabilities – if you know of a product using the KEV, let us know at CISA.JCDC@CISA.DHS.GOV
The KEV should contain information relevant to fully understand exploitation status. A few months ago, we added a “Notes” field to add additional context about particular vulnerabilities. We’re now exploring additional fields, such as noting whether a KEV is being used by ransomware actors, which may be of particular use to sectors such as healthcare and education.
The addition of a new KEV to the catalog must, over time, transition from a normal event to a surprising anomaly. As we note in our Secure by Design guidance, technology manufacturers must “prioritize the integration of product security as a critical prerequisite to features and speed to market.” The KEV is a clear example of the security burden falling on the customer – but we can do better. We know how to reduce the prevalence of vulnerabilities as a design decision – by using memory safe programming languages, by using web template frameworks and parameterized queries, by conducting robust testing and code reviews, and by adopting vulnerability disclosure programs that help good-faith researchers find vulnerabilities before adversaries, to name only a few. Consistent with the National Cybersecurity Strategy, we will continue to drive the ecosystem toward a future where nearly all KEVs are eliminated before a product is released to the market.
Finally, the KEV, like all we do as CISA, is a product of collaboration. We want to hear from you. Please send your thoughts, questions, and ideas to CISA.JCDC@CISA.DHS.GOV