Musings About Patch Deployment Time

Joao Correia

February 10, 2023 - Technical Evangelist

Organizations will often try to patch their systems “on time” in order to be secure from new threats. In this context, “on time” will mean different things to different organizations – some will strive to patch within a month of a vulnerability being disclosed, others will do it the moment a patch is available (as made possible with live patching, for example), while others will still do it as soon as business needs allow for the required downtime.

But are we even counting time the right way here? What does “on time” really mean when talking about patching?

On time

Let’s look at an example of a somewhat innocuous vulnerability that was just announced: CVE-2023-25136 – an OpenSSH vulnerability in the pre-authentication process caused by attempting to “free” an already released variable, thus potentially causing issues. It was publicly disclosed on February 3rd, and some CVE registrars still lack details about it.

Disregarding the (apparent) lack of risk, and hypothetically assuming it was a high risk vulnerability, what would patching “on time” mean for this flaw? If you patched today, (as of the time of writing this article), then you would patch within a week of its public announcement, and that would be pretty good, and you could consider your infrastructure secure again – which is a solid timeline in light of a study last year showing that a majority of organizations took more than a month to patch high risk vulnerabilities. All the right boxes would be ticked, your compliance officer would be very happy, and you could go back to your regular activities.

Consider now that the vulnerability has, in fact, been reported in January to the OpenSSH team, and that there were messages exchanged in the public mailing list about it around January 15th. This adds another two weeks of public information on a potentially crash-inducing bug before the actual CVE disclosure happened. And this is just the visible aspect of a bug-that-spawns-a-CVE. There can be a completely different timescale if the bug was not reported to the right team in the first place. For example, if it was sold as a zero-day exploit in a shady forum somewhere. In the case of this specific vulnerability, even if you patched it on the day the CVE was announced, you would potentially already be at risk for two weeks.

Over-rated CVEs

So, “on time” really means “since it is officially publicly disclosed” or “since it has a CVE number slapped onto it”, not really “since it is known.” There are situations where the initial information around a bug happens months before a CVE appears. Ever wondered why some CVEs will have a year indicator from the year before? It’s because they were found the previous year and the whole analysis-patch creation-release process took several months. And this process will often happen in the public eye under the guise of bug reports and github or mailing list discussions.

And here is where the conversation can derail – you can’t have an insecure system if there isn’t even a CVE out for you to know about it, right? That, unfortunately, is the wrong question.

Not all vulnerabilities have CVEs assigned. For example, the kernel security team will introduce fixes to new vulnerabilities every week without ever having (publicly known) CVEs assigned to them – in part because that would provide malicious actors a vector for unpatched systems, and in part because the CVE system itself has a series of inefficiencies. Learn more about it here.

The cybersecurity industry is laser focused on CVEs. We create, track, prioritize, patch, and strategize work around the ones we can’t patch – but CVEs are just the tip of the proverbial iceberg.

Minimizing the risk window

If your only metric towards security is the number of CVEs that you patch within a given timeframe, say, to meet compliance requirements, then you’re probably a bit less “secure” than you think. The risk window doesn’t start when a CVE is announced, but sometime before that, and how long that is is uncertain, so your best bet is to shorten the risk window as much as possible. You only control the risk window’s closing time. This implicit risk speaks volumes when organizations take a month or more to patch – that’s on top of everything else that happens prior.

Of course, it isn’t exactly possible to patch something before said patch is out, but all steps should be taken to ensure that you patch as soon as possible rather than take weeks to deal with a new vulnerability.

The (sometimes long) period of time until a vulnerability is actually divulged should be the best reason to have a faster approach to patching. Threat actors actively monitor bug reports looking for new opportunities and have the skills required to “weaponize” bugs quickly.

Do not help the hackers – they don’t need it. Patch now.

Summary