While Microsoft is still a leader among software manufacturers in the dubious category of product vulnerability to attack, recent studies show that the software vendor has gotten better at plugging security holes.
The SANS Institute partially credits Microsofts Automatic Update feature in Windows, which automatically downloads and installs security patches, but the institute also warns that a side effect has been to divert attackers energies to third-party applications lacking such streamlined support.
Microsoft has shown commitment to securing its products and has made significant progress toward that goal. Disruptions such as those associated with Windows XP SP2 say more about third-party developers bad habits than about any failings on Microsofts part.
We resist, though, the assumption that a broader use of automatic patching is the proper focus of improvement. Its not mainly the failure to respond to new threats thats the problem; its that vendors fail to ship high-quality products in the first place.
Automated patching is a decidedly mixed blessing. Systems cant be left vulnerable and unpatched, to be sure, and few IT departments can manually cope with the deluge of security patches.
Microsoft alone inundates its customers with a set of security patches and fixes on the second Tuesday of every month.
The automation of updates and patches alleviates to some extent the burden of user site management, but it also tends to ratify the assumption that its OK to ship poor-quality products.
The volatility introduced into the enterprise code base by constant updating of executables, not to mention the consumption of network bandwidth, amounts to a significant subsidy of commercial software providers by their customers.
As if that werent bad enough, the time lag of any patch cycle—automated or otherwise—is getting to be unacceptably long compared with the shortening time between the discovery and exploit of vulnerability. It took more than three months for Apple to issue a patch for a security hole made public in January that left the mRouter tool in iSync vulnerable to a buffer-overflow attack.
IT pros who are doing their jobs right know that they must test patches before installing them in production systems. This IT best practice ought not to be sacrificed for vendors convenience.
It would also be desirable, though, for Microsoft to build a framework within Windows that provides for flexible, unified updates of both Windows system components and individual applications; we would then urge participation from the independent development community in that initiative.
We also believe that software vendors can and must do better and that their enterprise IT customers deserve better. Reducing the need for patches—not merely streamlining the process—must remain a critical priority for all software vendors.
Tell us what you think at [email protected].