Different people tend to advocate different approaches to software updating. The single most common approach I have seen recommended is very simple — even simplistic: keep your system updated with all recent patches. It is suggested in the statements of people who want to pass themselves off as security experts (or at least security aware) all the time. A reasonable assumption, if you take that advice, would be that you should have Automatic Updates running on your Microsoft Windows systems so that every Patch Tuesday you get updated with the newest security patches.

The world is not so simple, though. For example, Microsoft issued a patch for a vulnerability in its SQL Server software in late 2002. Later, two unrelated patches issued for Microsoft Windows effectively deactivated the preceding SQL vulnerability patch. In 2003, a bit of malicious mobile code that came to be known far and wide as the SQL Slammer worm crippled much of the Internet because of systems that had been fully patched, but had the relevant security patch deactivated by later patches. This was not a universal problem; it depended on the order in which certain patches were applied, but the number of computers it affected was mind-boggling nonetheless.

Microsoft issued press releases chastising system administrators for failing to keep their systems properly patched. People lost jobs over this. Ironically, the problem was not people who didn’t keep their systems updated; it was people who did so too zealously, and too uncritically. This is exactly the sort of situation many system and network administrators fear when they turn off Windows Automatic Updates.

The preferred alternative on many well-secured, firewalled, gateway scanned networks with careful usage policies is to have automatic updating mechanisms turned off so that network administrators can test all updates on systems set aside for exactly that purpose, and ensure there will be no interruptions to daily operations when a given patch is distributed. Examples of annoyances that admins encounter while testing patches (or while letting patches get applied without testing, of course) have included not only patch conflicts such as the SQL vulnerability conflict in 2002/3, but also:

  • unwanted installs of Windows XP’s Service Pack 2
  • unwanted installs of Windows Genuine Advantage and similar DRM measures
  • unwanted version updates of Internet Explorer
  • unwanted default configuration resets
  • unwanted system reboots
  • unwanted reactivations of Automatic Updates

The common wisdom among those who actually know about, and professionally deal with, this kind of problem is that one should never allow computers in one’s charge to update software automatically. Updates should always be tested before being applied. It is a popular point of view among network administrators who have been in the business for a decade or so, but not among Microsoft employees like Bret Arsenault.

There are situations in which software updates should not be delayed, however. Such circumstances involve computers that will be connected more directly to the Internet or other hostile networks before there’s a chance to test security patches. Such computers might be mobile systems, such as laptops that are taken on business trips, as well as non-mobile systems such as the gaming system you have running World of Warcraft on your desk at home without the resources to maintain a test network to determine the problems that might arise with dangerous software updates.

Sometimes, you might simply have to apply security patches — or even functionality patches, if there’s some functionality being rolled out that you can’t pass up — without taking the time to properly test the software updates first. I myself do not currently have much of a test network at home, and don’t get to test patches as thoroughly as I would like before applying them to my laptop. I do, however, endeavor to avoid applying updates that I don’t have to without advance testing. Luckily, my laptop runs FreeBSD, so I can use portaudit to determine what software updates are really critical, and ignore the rest until I get a chance to test them or otherwise make a less hurried decision about what to do with them.

This suggests another rule of thumb of software updating; that one need not apply all patches. Most software updates have nothing to do with fixing security vulnerabilities. As a result, most software updates never need to be applied unless there’s some compelling need for the functionality changes the updates provide. It is unfortunate that many operating systems don’t do a reasonable job of clearly differentiating between security updates and nonsecurity functionality updates, assuming that all users will want to apply all patches. In some extreme cases, failing to apply a given patch may in fact interfere with the ability to apply a different patch later, as is too often the case with MS Windows patches.

In cases where your computer is not well-secured against mobile malicious code and the specific attention of malicious security crackers — where it lacks good external firewall and gateway scanning protection, for instance, since (one hopes) there will always be decent on-system firewall and scanning software — it may even be necessary to apply almost all updates immediately, without any testing.

The canonical example is the home user with a Microsoft Windows desktop system plugged directly into a DSL transceiver (more commonly, and inaccurately, called a “DSL modem”). Under such circumstances, the threat represented by the direct, unfiltered connection to the ISP’s network is marginally greater than that of an unwanted software update. The recent explosive growth of Conficker Worm infections is a perfect example of why such systems’ security updates should be less critically examined if such scrutiny of patches might delay application of important vulnerability fixes. As physically carrying the worm from network to network has proven to be a big problem with Conficker, it’s also an incidental example of the importance of good organizational security policy.

If the home user scenario describes you (even if you’re one of the Three in 10 Windows PCs still vulnerable to Conficker exploit), however, you should not simply take it as justification for just turning on Windows Automatic Updates and feeling smug about security. This is not a good answer to the problem, though it may be an effectively necessary answer in some cases. It’s just the lesser of two evils. The importance of maintaining good backups — always very important — is increased significantly by the automatic application of untested patches, for one thing.

For another, such a policy is only “good” by comparison with a policy that leaves the system unprotected against outside threats, as in the case of a computer that has no external firewall and scanning protection. Finally, on MS Windows systems in particular, there is rarely any way to only automate the application of security patches, and leave functionality patches unrelated to security to be applied “manually”, which means that you are at even more significant risk of unwanted or faulty updates making hash of your system configuration than if you were only applying the security patches without testing.