Cutaway has a good post up today over at Security Ripcord. In it, he suggests that Microsoft should… well, I’ll let him say it:
Here is my solution: Microsoft needs to come up with a Central Update Console that software and driver developers can hook to configure automatic updates. They already provide this type of feature through the “Add/Remove Programs” console. Good developers utilize this to help users and administrators manage the software that is installed on their systems. How hard would it be to come up with a solution that other developers could hook to help with centralizing the management of updates and provide a significant positive impact on the overall security of every computer on the Interweb? Although the design, development, testing, implementation, and maintenance of this project would be challenging, I am willing to be that this would be a small project in the grand scheme of Microsoft OS development. They don’t need to take every software vendor into consideration, they just need to come up with one method all of them could use.
This is something I’ve actually put some thought into (and not just because Cutaway and I talked about it a couple weeks ago), but I don’t think it can work. At least not today.
Managing vulnerabilities and patches is a huge issue, with a moderately sized third party market just to deal with it. While Microsoft provides patches for their own software only (with few exceptions, like a recent ATI driver update), they don’t provide patches for non-Microsoft software. I think this is for two reasons that I don’t expect to change anytime soon.
- Antitrust- there’s an entire market dedicated to vulnerability and patch management. MS can’t step in an include this in the OS, however useful an idea, without having to face antitrust accusations. Due to past mistakes, they are often restricted from including features other OS vendors don’t blink an eye at. Take a look at all the whining by Symantec and McAfee over Patchguard.
- Liability- it doesn’t matter how many warnings and disclaimers MS puts on the darn thing; the first time a bad third-party patch propagates through a Microsoft central patch console and blows up systems (which is inevitable), the world will cry havoc and let slip the dogs of alt.ms.sucks- and at least a few lawyers, wanting a piece of the MS pot of valuation.
On the enterprise side this isn’t as much of an issue since most organizations don’t use the update function built into Windows (although they do use WSUS (Windows Software Update Server).
Consumers, on the other hand, rely heavily on Microsoft for their updates and some sort of central service for third party patches could really help keep their systems current. Especially for device drivers; while applications can build in their own update functions and check whenever they’re used, device drivers represent a huge class of vulnerability that even most enterprises don’t pay enough attention to.
Also, as software gets more and more intermingled the risk of relying on application launch to check for patches becomes a problem. Components can represent an exploit risk through a web browser or a virus, even if you haven’t launched the application in a long time. Today, vendors manage this by ignoring it or installing YAASTS (Yet Another Annoying System Tray Service) that runs constantly, draining your system resources.
Thus I think Cutaway’s idea of a central patch service could provide a lot of value and help improve security. No argument there. But it represents a risk to Microsoft that I just don’t think the product managers, never mind the lawyers, will let them take.
Comments