Cumulative Patches: Help or Hindrance?

 
 
By Larry Seltzer  |  Posted 2004-04-21 Print this article Print
 
 
 
 
 
 
 

Is Microsoft's practice of bunching patches together a great convenience for users, a denial of control for administrators or just "patch marketing?" There's an argument for all three.

In the wake of Microsofts release last week of a series of "cumulative" patches to address a large number of serious security issues, the security community is debating the merits of Microsofts approach. One patch, for example, coded MS04-011 by Microsoft, was rated "critical" by the company. Like all of the patches released the same day, the MS04-011 patch is a cumulative patch, including fixes for a large number of vulnerabilities—14, to be specific—some more critical than others. But others were rated just "important" or "moderate" or even "low," depending on the platform.

Some administrators have been complaining that the bunching together of patches in this way limits their options. For years, many have complained that they hesitate to apply patches to functioning systems without proper testing. By including so many patches in one package, cumulative patches multiply the number of changes to the system.

By the same token, they limit the number of test cases—forcibly—for those who do want to test. But if something goes wrong with a patched system, the only option may be to remove the entire cumulative patch when only one part of it is causing problems. There are already reports of some users experiencing problems that can only be fixed by removing an entire patch.

In the past, and with many other vendors and open-source projects, individual patches are available to address individual issues. This is certainly the most flexible option for sophisticated administrators. But is it the best option for less sophisticated users? This isnt as clear. Less experienced users could be intimidated by 20 or more patches appearing suddenly.

Others assert that Microsoft, by consolidating the patches into just a few super-patches, is trying to make it appear that there are fewer problems than there really are. As Jupiter Researchs Joe Wilcox puts it, "Issuing 17 alerts, as opposed to four, makes it harder for Microsoft executives to count up the number of alerts as use the counting and evidence security is improving."

For insights on security coverage around the Web, check out eWEEK.com Security Center Editor Larry Seltzers Weblog. Microsoft would argue that the consolidated patches make patching easier, and that is better for all. Certainly its better for everyone if the patches are widely and quickly deployed. But if the future of patching, as Microsoft itself has argued, is in automated methods, such as Windows Automatic Updates and patch management systems such as St. Bernard Softwares UpdateEXPERT, then cumulative patches add little to usability. An automated tool can certainly handle 20 patches as easily as four—and better if uninstallation is a consideration.

Microsoft used to offer individual hotfixes as an option for administrators in some cases, even if "roll-ups" or service packs later became available. Providing both again would answer all criticisms.

Check out eWEEK.coms Security Center at http://security.eweek.com for security news, views and analysis. Be sure to add our eWEEK.com security news feed to your RSS newsreader or My Yahoo page:  
 
 
 
 
Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Rocket Fuel