Updated Poll: Which Patch Delivery Schedule Works the Best for You?

Published: 2012-06-22
Last Updated: 2012-06-22 18:42:15 UTC
by Kevin Liston (Version: 1)
3 comment(s)

In May I created a poll to sample our readers' preferences concerning the delivery of patches from their vendors.  Do you prefer the predictable delivery of a batch of security advisories and patches?  Or do you prefer a as-they-become-available model? (https://isc.sans.edu/diary.html?storyid=13150)

After the first week, I was surprised that nearly two-thirds of the poll participants preferred the predictable batch method and the few comments that did come in, didn't match up with my expectation that the breakdown would be based on the size of the environment.  Currently it's closer to my expectations showing about 3/4 prefer the "as it becomes available" method.

So, I have new hypotheses and have added a new level of detail to capture in this month's poll.

Considering the results of the poll (https://isc.sans.edu/poll.html?pollid=331&results=Y) did it turn out the way that you expected?



3 comment(s)


"... as-they-become-available model?"

How? ... when we get stuff like this with regularity?:
> - http://support.microsoft.com/kb/2720211
Last Review: June 18, 2012 - Revision: 6.0 <<<

In a medium to large shop, I don't even know how you'd handle the "as available" model.
I handle all software deployment for a group of roughly 400 machines with a large amount of variation from machine to machine. None of my users have local admin (I don't even have local admin - I insist on dogfooding). The problem with your survey is someone like me doesn't really fit in cleanly to the options given.

There is a moderate amount of work involved in packaging updates, and my goal is to be into beta the next morning after an update is released, so having a bunch of different updates hit on the same day just makes for a long day. There is also the difficulty of testing, which means the reality is I basically test for two things. Does the patch install (or the software update properly) consistently, and does the package appear to pass the most cursory test (i.e. can I view the Flash test page, can I open Word, etc.). Beyond that, I don't have the resources to do in depth testing, especially given the constant flood of updates, so it really is a model of deploying to a limit beta group, waiting a day after install to see if anyone complains, and then going into wide spread deployment.

As a result, I love that Microsoft has gone to a consistent patch cycle. I plan my life around Patch Tuesday. But it's a royal pain when other vendors attempt to piggy back off of Microsoft's schedule. It poses two problems. First, it just drives up the stress and the length of Patch Tuesday - by the time I've finished updating all the patch bundles and queries and gotten Patch Tuesday into beta, that's generally 3 hours. Only then can I turn my attention to packaging and testing whatever Adobe or Sun/Oracle decided to release. The other problem is that if there are issues with the updates, it's a lot harder to figure out what broke something if a machine just got a whole host of updates. Also, I try not to reboot my user's computers too many times on the same day, so I have to schedule the update deployments (and I've gotten pretty good at intra-job optional reboots and things like that to only punish users who can't figure out how to close a browser before trying to update Flash, but even still there are unavoidable reboots).

So, if I had my complete druthers, it would look like this:
* Vendors work it out amongst themselves - Sun/Oracle takes first Tuesday, Microsoft takes second Tuesday, Adobe does Reader/Acrobat on third Tuesday and Flash/Shockwave on fourth Tuesday (Reader/Acrobat is a big pain - we're still on 9, and testing Acrobat is very time consuming - Acrobat Pro 9.0 is 717 MB, but the 20 patches that have to be installed one-by-one are 1,364 MB!).
* If an exploit is in the wild, release as soon as the patch is ready, but please give us a heads up the day before if at all possible so know ahead of time to prepare.

Diary Archives