A week or so earlier, after issuing patches for three critical Internet Explorer vulnerabilities, Microsoft scrambled to correct a glitch that blocked customers from pulling the patches from its Download Center--effectively patching the system that distributes its patches. One can only assume that Microsoft tested the patch-distribution system patch before patching the system.
An Epidemic
Windows, of course, isn't the only software with more patches than a 14-year-old soccer player. Among operating systems, everything from Sun's Solaris to Cisco's IOS to open-source Linux is subject to regular fixes. Then there are the myriad office suites, messaging platforms, enterprise apps, Web browsers, network- and content-management systems, databases, and graphics tools that run the patch gauntlet.
Adding to the complexity is the fact that most IT infrastructures are networks of interdependencies: You're not just patching one system; you're tampering with a fragile ecosystem. Will the patches screw up custom apps and cobbled-together systems? Will they degrade performance? No doubt it's more critical than ever to test patches, but with the narrowing time frame between exposed vulnerability and exploit, IT organizations are pressured to just slap on the fixes.
There are no comprehensive solutions. Microsoft lets U.S. government agencies and other select customers test its patches before they're generally available, but you get no head start if you're smaller fry. And though patch automation may appeal to staff-strapped IT shops, it's not the silver bullet vendors are making it out to be, because of the need for manual testing. Automated patch deployment should be considered only for systems where information confidentiality is more important than availability (as with stored customer data that doesn't need to be accessed regularly), or where the risk of an attack is deemed to outweigh the risk of downtime, according to a recent Gartner report.