Is It Really Worth Testing Patches Anymore?

Microsoft Logo Covered with Patches

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) 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!

6 comments for “Is It Really Worth Testing Patches Anymore?

  1. September 12, 2011 at 11:56 pm

    BLOGGED: Is It Really Worth Testing Patches Anymore?

  2. September 13, 2011 at 9:12 am

    And just something I commented on last night re if patch testing is really needed anymore.

  3. September 13, 2011 at 10:11 am

    Is It Really Worth Testing Patches Anymore?: Last week I read a great article over on the ISC Diary by Rob…

  4. September 13, 2011 at 4:58 pm

    Another interesting article that contemplates that it may be worth not installing patches and depend on anti* software to keep the badies out.

  5. September 13, 2011 at 9:49 pm

    "bad patch will absol sneak in .. suck it up for that 1 day .. as opposed to being owned for 364 days"

  6. September 14, 2011 at 8:22 am

    #NOVABLOGGER Is It Really Worth Testing Patches Anymore?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.