This seems to be a revolutionary idea, as it seems that I am always having to argue this: Patching is an absolute MUST! When I manage IT operations and vulnerability management, I patch continuously. What does that mean? Patch Tuesday comes along? I patch immediately. There’s a new patch for Pulse Secure VPN appliances? I patch immediately. I have patch management systems implement workstation patches daily. It could be a patch from Microsoft, LogMeIn, Adobe Reader, Firefox, Chrome, Java, WinZIP, or any other commonly patched program. Daily.
So why are people afraid of patching? Mostly, because of two reasons, both associated with fragility:
- Critical systems are left unpatched by many organizations because they are considered too fragile or risky too patch. When downtime could cost millions, companies leave the systems at the same state for a decade. A SQL Server patch might break an application. A security patch may break the way an application uses an old version of SSL. Patch avoidance avoids the consequences.
- Administrators have all experienced that rogue patch that kills a server. Install a patch and the Exchange Server transport service refuses to start. Install a patch and the domain controllers won’t boot. You get the idea.
The fragility is real, and the risk is real, but so is the threat of attack to unpatched (vulnerable) systems.
I approach patching as an exercise in resilience. Your business needs to plan for patching, plan to recover quickly from bad patches, and plan redundancy to maintain system availability during patching. These are critical core skills for your organization. If you are unable to design for resilience in order to patch while during business operations, how is your business going to deal with a server failure, site failure, ransomware attack, or bad code deployment? Your business depends on you to plan your infrastructure in a way that you can patch during production and recover from bad patches during production without skipping a beat.