Common sense tells us that when code used to exploit vulnerabilities becomes publicly-available, somebody will use it for an attack.
New research from Kenna Security and the Cyentia Institute tells us the exact impact the public release of such code has on corporate security and attacker momentum – especially in the relatively rare instances where the release of an exploit code predates a patch. When this happens, attackers get a 47-day head start against the security teams defending against them.
Our research mapped the lifecycles of 473 vulnerabilities with evidence of exploits in the wild in 2019. And it raises some interesting points about how software vendors and security teams can work together.
It’s worthy to note that there’s no typical sequence in when a vulnerability gets discovered, a CVE created, a patch issued, or an exploit developed. While zero-days captivate a lot of attention, true zero-days are very rare. Only about 7 percent of vulnerabilities are exploited before a CVE gets published, patches are available, and exploit code released.
It’s not all bad news. We’re not dealing with the wild west. More than 80 percent of exploited vulnerabilities have a patch available prior to, or within a few days of CVE publication. About one-third of vulnerabilities have exploit code published before a patch becomes available.
Just because a patch becomes available doesn’t mean an organization has the time or resources to implement it. Conversely, there’s also a learning curve to using exploits. The question becomes: What factors give defenders momentum?
When patches are made available before exploit code goes public, organizations get a significant period of time in which they can patch more assets than attackers can target. But when an exploit predates the availability of a patch, attackers get a 47-day head start, and it usually takes defending organizations more time to patch than normal.
All of this data adds up to a fairly simple conclusion. There’s a system of coordinated disclosure in which security researchers give software vendors a chance to issue a patch before going public with their findings. That system largely works. If anything, vendors would like it if researchers gave them a little more time.
While that conclusion might seem obvious, it does fly in the face of some conventional wisdom. After all, intrusion detection vendors can’t always write detection signatures without exploit code. And if an intrusion detection system (IDS) can’t detect an exploit attempt the security team might not know if it’s being exploited.
In a perfect world, security researchers who find vulnerabilities would give software vendors plenty of time to fix security holes they find. On the other side of the coin, software vendors would act expediently when security researchers find vulnerabilities.
Unfortunately, we don’t live in a perfect world. Sometimes, software vendors don’t respond to security threats. And security researchers disclose their findings before vendors have had a chance to issue the fix.
That dynamic, and these rare exceptions, has led to years of recriminations between researchers and vendors. We don’t have to live with these recriminations. We consider our research novel. We’ve found nothing that pairs vulnerability lifecycle and vulnerability management data at this scale. It offers a unique path to get past the age-old fights over the role of security researchers and their relationship with vendors. Simply put, it’s a huge dose of data that offers a road map for better outcomes.
Ed Bellis, co-founder and CTO, Kenna Security
