10 Mar 2003
Reaction to the news that Microsoft is improving its system of distributing and deploying software patches is likely to be ambivalent at best.
Although many users will instinctively applaud any initiative that improves the lot of hard-pressed system administrators, cynics may note that the root cause of their problems is the inherent vulnerability of Microsoft products in the first place.
Further reading
As a result, the more enlightened may decide to compare the latest step in Microsoft's "Trustworthy Computing" initiative to that of a progressive cigarette company proudly telling cancer victims that it has invented a more effective kind of chemotherapy.
Hardly a week goes by without worms and viruses becoming just a little bit more sophisticated and just a little bit more nasty, and quite frankly it's all starting to become rather tiresome. Never-theless, Microsoft's admission that it was partly to blame for the damage caused by the Slammer virus, because its patch was too hard to deploy, was a welcome chink of light in the darkness.
In the past, none of the major vendors seemed to take the problem of patching very seriously, so it is right that we applaud their recent efforts to improve a deeply flawed system.
Over the years, vendors have approached security against worms and viruses on an ad hoc basis, which is reflected in the chaotic collection of Web sites and myriad solutions that bewildered system administrators must attend to on a daily basis.
Patching has been in desperate need of some strategic thought for a long time, and finally the major vendors are starting to clear up their own mess. This change of attitude is long overdue. The central plank to any corporate governance policy that is worth its salt must be to defend mission-critical systems against all kinds of attacks and remove known vulnerabilities.
But vendors are still not working hard enough. Many administrators have been shocked to receive most of the blame for failing to stop attacks such as Slammer. But blame should be shared, not offloaded, so vendors need to work hand in hand with customers to create the most efficient defence systems they possibly can.
In an ideal world, vendors and user bodies would agree common standards for patching procedures. What is desperately needed is a definitive decision on when alerts about unsafe software should be issued and to whom. Vendors should be obliged to distribute patches within a certain time, and users should be given as much information as possible about any knock-on effects after installation.
As the government takes a growing interest in digital security, perhaps it should now introduce legislation obliging vendors to create secure software.
And if all else fails, I cannot understand why firms that suffer from insecure software do not take legal action against the companies that sold it to them. Nothing would wake the vendors from their stupor quicker than a few legal precedents making them financially responsible for damage to businesses.
Sadly, until the realities of vulnerable software have been driven home to vendors in such a meaningful way - in other words by hitting their bottom lines - the patchwork nightmare is set to continue.
Have your say on this article
Newsletters
Latest stories from Security
You may also like
Security jobs
Technology Patent Wars
Case studies from large organisations across all sectors
... And rich media, and flexible working, and peaks in traffic ...
Upcoming Events
Join us for this Computing web seminar, in which the Head of BI at the Co-operative Group Nick Colebourn will be explaining just how he reigned in the Group’s sprawling database estate and how significant savings were realised and data quality improved as a result.
Date: 31 May 2012
Time: 11:00 AM
Live June 13th 11:00am: Register now. During this web seminar we will be looking at the sorts of incidents that can bring data centres grinding to a halt and what can be done about them.
Date: 13 Jun 2012
Time: 11:00 am
Receive the latest jobs direct to your inbox
Are you being paid what you are worth?