Without context, the KEV catalog is just a very large collection of data. Tod Beardsley is the former CISA KEV section chief, and he recently released a paper called KEVology that provides key context and evaluates the value of certain enrichment signals.
The Known Exploited Vulnerabilities catalog that CISA maintains has become a key reference point and tool for security researchers and defenders, providing a common source of data on which bugs have been exploited and when exploitation was first detected. But without context, the KEV catalog is just a very large collection of data. Tod Beardsley is the former CISA KEV section chief and the current VP of security research at runZero, and he recently released a paper called KEVology that provides key context and evaluates the value of certain enrichment signals. Beardsley recently joined me on the Decipher podcast to talk about the paper and how defenders can best make use of the KEV catalog. This is an edited excerpt of that conversation.
Dennis: You worked at CISA, you were essentially in charge of this. What motivated you to dive deep into this report, Kevology, which is a look at CISA’s Known Exploited Vulnerabilities catalog from all these different perspectives?
Tod: The inciting event for Kevology: An analysis of exploit scores and timelines on CISA's KEV was essentially a customer wish. We do exposure management at runZero, and the wish was, "Boy, it would be cool if I could just deal with all the outstanding KEVs with your product." We said that would be cool, but I wrote a 20,000-word paper on why that's a hard ask.
Getting 100 percent KEV coverage today is, I would posit, impossible with certainly one solution. The KEV covers traditional IT, operational technology (OT) vulnerabilities, mobile stuff—all things that don't fit nicely into one security solution. A misconception is that the KEV is just a list of the worst of the worst vulnerabilities used for initial access, but it's much broader than that.
The real goal of Kevology is to figure out what we can take from the KEV that is a useful vulnerability signal and what we can use as an intelligence source. We look at ways to prioritize, like focusing on specific CVSS attributes, such as non-authenticated, no user interaction, full shell access bugs—the straight-shot RCEs that people often think of when they talk about software vulnerabilities.
Dennis: The report discusses the time delta between when CVEs are issued and when they enter the KEV. Sometimes the CVE is even published after the KEV entry. How and why does that happen?
Tod: I can explain. One of the barriers to entry for the KEV is that a vulnerability must have an assigned CVE ID. However, major vendors are their own CVE numbering authorities and can reserve IDs. Typically, the CVE is published weeks or months before the KEV catches up.
But every once in a while, CISA will get a communication from a vendor saying, "Hey, we're going to publish this thing, and there's active exploitation right now. You should probably put this on the KEV." We push them to get the CVE published, but if they don't immediately, we'll still list it on the KEV to avoid slowing down patching. The CVE might then be published a few days later.
Dennis: In the case of a zero-day that is not publicly known, what qualifies as evidence of exploitation for CISA? What are you looking for?
Tod: If you have evidence of exploitation, you should definitely get in touch with the team at CISA. Things like PCAPs are really good for data that isn't encrypted. For things like privilege escalation, EDR logs, smart firewall, or intrusion prevention system logs are also very useful.
A lot of the evidence work involves correlation. We might get an anomaly detection log from a network device, and then we see by the timestamps that a machine started acting "real funny" and has a bunch of corresponding logs. We then build a case for which specific CVE is being exploited, especially when a single patch addresses multiple CVEs.
Dennis: Was there anything that really surprised you as you dug into the data?
Tod: It was surprising to me how you could play around with time. We saw a pleasing pattern in our graphs showing how public exploit development is starting to coalesce around the KEV. For instance, the Nuclei templates used to be published well after the KEV was published, but now they are falling down to being published on the same day.
Also, we routinely see very old vulnerabilities, like a 2008 bug, being added to the KEV because old exploits work and are still found in the wild.
The other thing that jumped out was the distribution of KEV vulnerabilities on the Exploit Prediction Scoring System (EPSS). It describes a really fun inverse bell curve: the 90–100% chance of exploitation is overrepresented, but so is the 0–10% chance. This tells me that the KEV has good visibility into highly targeted attacks, which often have a very low EPSS score because the exploit gets "burned" and fixed quickly after a highly targeted use.
Dennis: Tell me a little bit about the Kev Collider tool that you released.
Tod: We read this whole paper with four or five different ways to slice and dice KEV issues, but I thought the paper would get out of date fast. So, we put together a web app that is just a view of the KEV, but it exposes all the analysis in Kevology.
The tool allows you to pick the things that are interesting to you in that moment. For example, you can filter the KEV to focus only on denial-of-service bugs, or find vulnerabilities with a high EPSS score but without a network component, which would show you high-value privilege escalation bugs.
It's a very static, snappy tool; it loads all the data at once in your browser. All the filtering is expressed as GET parameters, so you can share the link with a colleague, and they will see exactly the same filtered view. It’s a test bench for prioritization. We call it the Collider because we're smashing vulnerabilities together to see what falls out.
