paint-brush
Why Vulnerability Remediation Teams Wish They Were All Zero Daysby@mikestarr
115 reads

Why Vulnerability Remediation Teams Wish They Were All Zero Days

by Mike StarrJuly 6th, 2023
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Zero day vulnerabilities are software security gaps disclosed to the public often before a patch is available. The race is on between the software manufacturer and their customers to get a patch developed, tested, and deployed before the bad guys can use it to launch attacks. Many attacks are launched against vulnerabilities months or years old with patches that have been available for as long as the vulnerability has been public.
featured image - Why Vulnerability Remediation Teams Wish They Were All Zero Days
Mike Starr HackerNoon profile picture

Zero day vulnerabilities are sexy. Much sexier than a two-year old vulnerability for which a patch has been available for 23 months. They get the attention of the press, which gets the attention of senior management, which, unsurprisingly, gets the attention of the security and vulnerability remediation teams. And, believe it or not, that’s really good news for the folks responsible for patching them. Allow me to explain.

Zero day vulnerabilities are software security gaps disclosed to the public often before a patch is available. Some bad actors are aware of these new vulnerabilities before the public (and sometimes also before the software manufacturer), so they have a head start developing and deploying exploits to take advantage before a patch is released. Thus, once a zero-day becomes public, the race is on between the software manufacturer and their customers to get a patch developed, tested, and deployed before the bad guys can use it to launch attacks.

To understand why I’m implying (sarcastically, of course) that remediation teams prefer zero-day vulnerabilities to the garden variety, some context is helpful. Under typical circumstances, cyber security teams routinely scan for, and identify, dozens, hundreds, or even thousands of vulnerabilities on the typical enterprise network. They then hand these vulnerabilities off to the IT team to be fixed, or “patched,” hopefully offering some insight into which are the most critical and the highest priority. Since many - if not most - of the vulnerabilities routinely identified are not being actively exploited by bad guys, the urgency to fix them is tempered by their low risk of exploitation, and the possibility that patching them will cause disruption.

Indeed, IT professionals endure a lot more criticism for causing downtime when patching than they do for patching too slowly, so their default state is to be exceptionally cautious while absorbing the cyber risk of exposed vulnerabilities.

All that changes when zero-day vulnerabilities are added to the equation. Since the actual - and perhaps more importantly, perceived - risk of an unpatched zero day vulnerability is exceptionally high, remediation teams are incentivized to patch those much more aggressively. Consequently, they’re chided much less, if at all, if they disrupt network operations patching a zero day vulnerability. IT teams feel more comfortable patching zero-days aggressively, despite the higher likelihood of a disruption from a zero-day patch.

Unsurprisingly, zero-day fixes are often rushed to the market by software vendors under pressure to deliver them as quickly as possible, often subjecting them to less rigorous testing than a typical patch with less urgency associated with it.

This common reaction to zero days is at the same time understandable and disappointing.  Understandable because it's the result of a cold risk calculation: assume the heightened risk of a zero-day patch network disruption, as it eclipses the perceived risk of a breach originating from an unpatched zero-day vulnerability.

Conversely, it’s disappointing because a similar philosophy would be welcomed from corporate leadership with respect to all high priority vulnerabilities. It’s not as if all vulnerability-initiated breaches are the result of zero-days. Quite the contrary. Many attacks are launched against vulnerabilities months or years old with patches that have been available for about as long as the vulnerability has been public.

One recent study revealed that, of the vulnerabilities used to launch ransomware attacks in 2022, over 75% were disclosed in 2019 or before, meaning 3-year old vulnerabilities were responsible for three quarters of the ransomware attacks traced to vulnerabilities last year.  

And yet, when routine vulnerability remediation efforts of IT teams cause disruptions, something that happens much more rarely than in the past, they’re subject to immediate and often harsh criticism. So, hyper-cautious patching behaviors are reinforced. Vulnerabilities remain unpatched for months. And threat actors celebrate.

As less than 2% of patches are rolled back (uninstalled because of a serious disruption) in this modern IT era, the industry’s endemic delay in patching vulnerabilities - up to 16 months - is a human problem driven by an outdated perception of patching disruption risk, and an shameful lack of empathy for the IT professionals tasked with perhaps the most critical cyber risk reduction activity in the enterprise: timely patching.

And as is the case with all human-driven problems, only humans can fix it. Even in the age of AI, technology can do only so much.