Last week I read a great article over on the ISC Diary by Rob VandenBrink that asked the question “Should We Still Test Patches?” Rob makes some excellent points! Given that Microsoft and Adobe coming out with patches tomorrow and me being on the road missing NovaHackers tonight, I thought I’d throw in my thoughts.
My personal approach is to mostly follow his auto-pilot advice however I do try to configure things to delay a day or so. This way if some bad patches slip out, I have time to manually remove them from the auto-install queue.
In an enterprise environment, I would recommend a similar approach however holding off a little longer (e.g., maybe 2 days) and intermediately deploying the patches out to a representative set of low risk guinea pig machines (e.g., 1 day as before). This way an enterprise at least gets to wait a little for others to find problems as well as get some live testing to make sure the patches don’t break any of their applications.
And here are a few points from Rob’s article that I would like to highlight.
via ISC Diary
In short, dozens (or more) critical patches per week are in the hopper for the average IT department. I don’t know about you, but I don’t have a team of testers ready to leap into action, and if I had to truly, fully test 12 patches in one week, I would most likely not have time to do any actual work, or probably get any sleep either.
Where it’s not already in place, it’s really time to turn auto-update on for almost everything, grab patches the minute they are out of the gate, and keep the impulse engines – er- patch “velocity” at maximum.
Going to auto-pilot is almost the only option in most companies, management simply isn’t paying anyone to test patches, they’re paying folks to keep the projects rolling and the tapes running on time (or whatever other daily tasks “count” in your organization). The more you can automate the better.
There are a few risks in the “turn auto-update on and stand back” approach:
- A bad patch will absolutely sneak in once in a while, and something will break. For this, in most cases, it’s better to suck it up for that one day, and deal with one bad patch per year as opposed to being owned for 364 days. (just my opinion mind you)
- If your update source is compromised, you are really and truly toast – look at the (very recent) kernel.org compromise for instance. Now, I look at a situation like that, and I figure – “if they can compromise a trusted source like that, am I going to spot their hacked code by testing it?” Probably not, they’re likely better coders than I am. It’s not a risk I should ignore, but there isn’t much I can do about it, I try really hard to (ignore it).
Read more here.
Also be sure to check out the comments on the ISC Dairy post … lots of good suggestions as well. See ya!