Last week, Microsoft issued a patch to address a kernel vulnerability in Windows. Then, three days later, they pulled it due to the patch causing blue screens of death and endless reboot loops. Not good.
Predictably, some people are asking whether they should apply security patches.
Of course I say yes. Here’s why, and more importantly, how. Situations like MS14-045, which, in my experience, happen about once a year most years, are why we have test environments. Industry best practice is to set up an environment that matches production as closely as possible, deploy, watch for problems or other people reporting problems, troubleshoot if necessary, then deploy to production.
The test environment lets us spot problems Microsoft didn’t think of–which are rare but admittedly not unheard of. Microsoft’s testing is generally pretty good, and they’ve been doing this for 13 years now. Some companies deploy all patches within 5 days, to everything, but those are the high achievers. Someone who can roll out that fast can rebuild very quickly as well.
Mere mortals like me patch every month and it takes around four weeks, typically finishing up just in time for the next month’s round, and then we do it again. Inside that four weeks we adjust and prioritize everything we need to, based on criteria I’m not willing to share (sorry–I have to protect my employer). Staffing or environment size may allow some shops to get it done a bit faster, and that’s great, but personally, I would hesitate to commit to getting it done much faster than 14 days because when there’s truly a problematic patch out there, sometimes it takes longer than a week for the problems to surface.
And if we think we’ve found a problem, we open a case with Microsoft and the applicable software vendor. Not patching is never the right answer–getting working patches and functioning security is.