It’s that time of the month again, when we are all getting ready to apply security patches, from Microsoft’s monthly release, and, this month, from Adobe. There may be a few more that will emerge over the next few days. So the timing is apt for a recently-posted article at the SANS Internet Storm Center [ISC], by Rob VandenBrink, one of the ISC’s volunteer handlers, in which he asks the somewhat provocative question, “Should We Still Test Patches?”
The traditional wisdom on applying patches to important systems is that one should test them first, to make sure that they don’t break anything, and then apply them to live systems in a timely way. VandenBrink’s argument is that, due to the sheer volume of patches, most organizations face an unappealing choice: either forgo most patch testing, or risk having systems compromised before they are patched. Concern about the number of patches is not new; some estimates show that the average PC user needs to apply at least one patch every week to keep current. And testing patches tends not to rank very high on managements’ priority lists.
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).
This is in line with what seems to be a general trend in the software industry, of automating the update process rather than leaving the process entirely up to the user. Windows has its auto-update mechanism, as do most anti-virus packages, and Google’s Chrome browser updates itself automatically. The underlying motivation for this is that users typically are not very good at keeping their systems up to date. Even those users who ought to be especially security conscious often fall down on the job; it was one year ago today that I wrote about patching problems at the Department of Homeland Security.
Up to a point, I think this is a good thing. As I’ve said before, the typical user is not a competent systems security administrator, and it is not reasonable to expect him or her to be. Providing understandable, timely notice of new security fixes, and making those fixes as painless as possible to apply, is a step in the right direction.
I think there is a danger, though, of taking this idea too far. The reason standard practice has included patch testing is that patches do sometimes break things. Beyond that, there have been some proposed “improvements” to the patching process that, to me, make no sense. For example, there was a proposal for Firefox recently to remove all version numbers that are visible to the user (e.g., in the “About Firefox” dialogue); fortunately, it seems to have been shelved, at least for now. The user is not the adversary, and hiding things from the user is a dumb idea. Similarly, I think the user should always have the choice to require positive approval to install patches. When I have had to use Windows PCs, I have always set the anti-virus software to manual updates, because I don’t want a long-running update to slow the machine to a crawl when I need to bang out an urgent E-mail.
The patching process, to be fair, has gotten better in the last few years. Rob VandenBrink’s article has some sensible suggestions for what updates to keep under manual control, rather than just “turn on auto-update and stand back”. It’s still a thorny problem, but getting people to pay attention may make life easier in the long run.