A Glimpse Into the CISA KEV

On March 27, Elizabeth Cardona and Tod Beardsley gave a presentation at VulnCon 2024 about CISA’s KEV, or ‘Known Exploited Vulnerabilities’ list. This initiative was created as a result of BOD 22-01, which is a ‘Binding Operational Directive’ aimed at reducing the risk due to vulnerabilities that are known to be exploited in the wild, and that may impact federal, executive branch, departments and agencies. Many private organizations and companies also follow it closely as a guide to know what may be the biggest digital threat they face.

While the idea of the KEV is simple on the surface, Cardona and Beardsley gave us insight that shows it is not as straight-forward as it may seem. This blog aims to capture some of what they shared with a little commentary thrown in.

---

First, what criteria must be present for a vulnerability to be included in the KEV? Note that any quotes are direct from the speaker, but I did not note which speaker said it.

• It must have a CVE ID. “We need to speak same language, that language is CVE ID.“
• Have reliable evidence that vulnerability has been actively exploited in the wild, and it is not limited to federal resources. So a commercial company can provide evidence, not just an agency.
• It must have clear remediation such as a vendor update, vendor instructed removal of EOL devices, and official mitigation such as a temporary workaround. Note that this makes it very difficult, but not impossible, to add vulnerabilities in third-party libraries, chipsets, or protocol specifications. [At the time of the talk, this was preventing multiple vulnerabilities from appearing on the KEV.]

These are fairly easy to understand and they make sense, but there are some caveats and details that matter. First, the reliable evidence of exploitation means that there is the execution of malicious code, performed by an actor on a system without permission of the system owner, or attempted exploitation with the same criteria where the result would have been malicious code execution. In short, “bad guys doing bad things to another computer“. The criteria for this is quite high because it represents money federal agencies must spend in remediation efforts. A false positive on the KEV can waste thousands of hours and considerable money.

The speakers made a point to say the KEV is not there to predict exploitation, rather, it is evidence-based. Exploitation could happen against one system or a thousand, and that does not matter to them, as either can land a vulnerability on the list. CISA also does not care if the exploitation information comes from a federal agency, researcher, commercial company, or vendor. Beardsley also qualified that “if something is ripping across the Internet, you can read it elsewhere… the fact it is on the KEV or not is immaterial“. I believe this was speaking to cases where there was heavy news on active exploitation of a vulnerability while it not appearing on the KEV yet.

So, what does not count for inclusion in the KEV?

• The simple existence of an exploit posted to a web site, as that does not prove it has been successfully used against a host.
• Vulnerabilities exploited during authorized penetration testing, as the activity was condoned and not malicious.
• Vulnerability scanning and inventory actions that test for the presence of a vulnerability, but do not exploit it.
• Most, but not all, honeypot activity. The speakers said that while honeypots are great, not all evidence is the same. For example, they had a vulnerability that was about to be included in the KEV, but last minute determined it was the researcher that discovered the vulnerability exploiting it, not a threat actor. They pointed out that “honeyposts rarely catch post-exploitation activity, TTPs, etc.“
• Vulnerabilities in a television, toothbrush, or video game do not qualify, as they are not a direct use-case and impact to federal agencies.

Next, what counts as ‘evidence’ in CISA’s eyes?

• Source of exploitation: is it reliable versus unreliable. Was it an open or confidential source?
• The type of exploitation evidence: was it the victim reporting it or a researcher?
• The quality of the exploitation evidence. Logs and packet captures are great, but honeypot scans typically aren’t enough. Post exploitation evidence, such as forensics are of great quality.

From here, the talk turned into a fairly extensive Q&A session. I’ll include some interesting bits from that before ending with future plans for the KEV. My comments in brackets for the following.

• According to Beardsley, to his knowledge, CISA does not refer criminal activity to the FBI.
• There is a huge library of exploits in CISA’s backlog that they are investigating.
• Someone asked if there is a worry about researchers trying to get on the KEV, for notoriety and their exploit being more serious. The speakers responded that they do not link to advisories or credit anyone, reducing the ‘glory’ aspect. [All well and good, but researchers can still just include it on their profile / LinkedIn / resume.]
• They were asked, how do you incentivize people to give evidence? That has changed dramatically over time they said, and more people are willing to help make things secure. They want more partners in the private sector, and they “do not want customer info, sanitize logs etc.“
• It’s rare, but they have had cases of a vendor saying they needed help amplifying to customers that there is known exploitation of their devices.
• They were asked how one agency, CISA, can make the determination of what hardware and software is used by all other agencies. The micro-answer is that CISA has a lot of tools to figure out what is used in other branches. Different team uses CyberHygiene, they have contractors work on it, and more programs. “We know more or less but rely on agencies to do their own homework.”
• At one point, a speaker said “CVE allows the community to uniquely identify a vulnerability” and it “serves as single source of truth…”. During this part, a mention of the numerous CNAs was made as well. [CVE is no longer the SSoT for issues through references. A considerable amount are being published with invalid references that are 404 from publication. There are not 368 CNAs issuing CVEs either, at least 47 minted in the last 12 months have zero published advisories.]
• The speakers were asked, what if there is no CVE ID? CISA is a CNA and can create an ID if needed. For example, they assigned for the ConnectWise ScreenConnect vulnerability.
• Depending on where evidence comes from, CISA may or may not share exploitation details with a vendor. If they do, it is coded with the Traffic Light Protocol (TLP).
• The speakers were asked if they have thought about applying confidence levels to reports. They answered that any questions tend to be shaken out during analysis, and that 70 or 80 people may see parts or all of the evidence before it reaches the KEV.
• If an entity or network poses a risk to the federal enterprise in any way, it can end up on the KEV. Even if a threat actor compromises an Australian or New Zealand government server, CISA cares. The KEV is target agnostic and evidence from allies, big companies, or small companies that do a niche thing, all matter.
• Does a CVE ever get removed from KEV, and what was the criteria? They answered “yes, if it doesn’t meet the criteria”, if a patch will break something, or if they make a mistake. Beardsley said it has happened “two or three times ever”. [There was a high profile removal at the end of last year that made news. Another happened a couple months before that. I believe that is the ‘two’ Beardsley refers to, but I haven’t kept a list of removals. Perhaps we should…]

What does the future hold for KEV? The speakers briefly mentioned several things they hope to see in the future including:

• Vulnerabilities tagged by CWE ID
• Also tagged by “type of target”
• Add two SSVC decision points: technical impact, automatable
• More documentation and explanation about KEV

Hopefully this sheds some light on the KEV. The talk was certainly interesting to me and helped me better understand the process and caveats for the initiative.

Before this talk, I certainly had some criticism of the KEV, but this talk really opened my eyes to some of the details on how they operate and why the KEV seemingly fell short. I think after the talk and thinking on it more, the big thing that stands out to me is the KEV is one thing while the industry thinks it is another thing. This talk bridged that gap for me. Now, my criticism is leveled more at organizations and vendors that have evidence of exploitation and don’t share it with CISA, so that the KEV can be updated more rapidly, and be more thorough.