Responsible Exposure and What It Means for the Industry

There’s a debate that crops up continously in security circles over the role of security researchers that hunt for vulnerabilities. 

On the one hand, this group of professionals perform a vital service. They find vulnerabilities in systems before bad guys do. 

To prove that a vulnerability exists and is exploitable, the researchers may develop exploit code. Every once in a while that code becomes public before a patch for that vulnerability is released. 

These situations have often put security researchers in the line of fire. After all, it is assumed that releasing exploit code on the internet makes the overall IT community less secure – quite the opposite of the stated mission of most security researchers. 

To this, security researchers have some valid points: the existence of exploit code may motivate companies to patch once one becomes available, it alerts companies to security risks when publishers fail to act, it helps assessment and intrusion prevention vendors develop signatures, and the threat of disclosure motivates software publishers to develop patches quickly. Google’s Project Zero, for example, sets a rigid, 90-day deadline for disclosure of vulnerabilities its researchers discover. It’s important, however, to not confuse vulnerability disclosure with exploit disclosure.

That dynamic has existed for years. Security researchers discover vulnerabilities, while occasionally drawing fire for what some see as inappropriate disclosure. New research from Kenna Security and the Cyentia Institute on the lifecycle of vulnerabilities shows how that state of play affects attackers and defenders. The research offers a first-of-its-kind, data-driven view of what’s working and what could work better in the world of responsible disclosure. 

Kenna and the Cyentia Institute looked at 473 vulnerabilities from 2019 in which there was some evidence of exploitation in the wild in a massive, global sensor network and other data sources. To our knowledge, no existing research combines vulnerability data with exploitation data at a scale of this size.

For each vulnerability, the research team charted its lifecycle over a 15-month period: when a vulnerability was discovered, when a CVE was reserved, when a CVE was published, when a patch was released, when it was first detected by vulnerability scanners, and when it was exploited in the wild. 

Interestingly enough, the research showed that there was no dominant lifecycle. Only 16% of the CVEs studied followed the most common sequence of Reserved-Patched-Scanned-Published-Exploited. The order in which these events occur has significant effects. 

About 60 percent of vulnerabilities have a patch before the official publication of the CVE. This number jumps up to over 80 percent within just a few days following the publication of a CVE. That’s a strong indication that the practice of coordinated disclosure is working really well. Companies are, for the most part, issuing patches when researchers point them out. 

We see a similar pattern in the ability of vulnerability scanners to detect vulnerabilities. Nearly 80 percent of vulnerabilities are detected in a live environment within two days of the release of the patch. This means defenders know where the vulnerability exists across their assets and have the means (the patch) to begin remediating it.

So, how often does exploit code become public before the release of a patch? It happened about 24 percent of the time. And 10 percent of exploitations came before a patch was available. Exploit code predated exploitation in the wild for 70 percent of exploited CVEs.

Just because a patch is released, it doesn’t mean it will get used. Companies have a backlog of open vulnerabilities. Conversely, just because an exploit is available, that doesn’t mean attackers will use it. And so, there are periods of time when attackers are able to deploy more attacks than defenders can patch, and there are times when defenders have momentum. 

Our research shows that when exploit code is released into the wild, attackers get, on average, a 47-day head start on their targets. At the same time, when exploits are released before patches, it takes security teams more time to address the problem, even after the patch is released. That’s an indication that exploit code availability is not the motivator that some would suggest it is. 

For the entire 15-month study period, attackers had the momentum about 60 percent of the time. 

Remediation and exploitation timelines are incredibly interlinked. While this research provides strong evidence that early disclosure of exploit code gives attackers a leg up, more research is needed. IDS and IPS can’t detect exploitation without signatures, and those often come from exploit code. It could be the case that exploitation predates disclosure of exploit code, and that exploitation was occurring all along. We only learn about it later. This scenario would support earlier disclosure of exploit code, regardless of ramifications. 

For now, it seems that the most positive takeaway from this research is that responsible exposure – researchers and software vendors working together – benefits the whole community. It’s possible that we could see an even bigger benefit by extending the amount of time vendors have to write and release patches. 

Read the full report, Prioritization to Prediction, Volume 6: The Attacker-Defender Divide.