Security Ripcord

Recent hardware and software problems got me thinking about patch management. Some companies have a handle on this effort. SMBs, SOHOs, and home users, however, are a bit more challenged because of funds and skill levels. The software manufacturers haven’t made it very easy either. Let’s list out the overall problem.

1. Vulnerabilities in software and drivers put computers and users at risk. The mitigation for this is to patch the software and driver whenever there is an update and especially when there is a security update.

2. Most software do have automatic update features. They can poll on bootup or when the program starts. They can be configured to run at granular start times or stopped completely. Unfortunately, there is not really a standard where to place this information and there is no way to determine when other softwares are scheduled to update unless you specifically open that piece of software and record the scheduled update time.

3. Drivers are more difficult to keep up with than other software. Users do not usually directly interact with drivers and most do not have an automatic update scheduler to determine if an update is available. Although some OSes handle this for some drivers they do not do it for all.

4. The more confusing and time consuming a process the less likely end users are going to perform the task. Most systems are vulnerable because people do not know how to update or just don’t want to take the extra time necessary to go through and configure automatic updates or monitor specific drivers that do not include the service. And, if the automatic update affects their user experience they are going to find a way to turn that feature off.

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. Once a system is developed software developers can start modifying their products to hook the console. They wouldn’t need to take out their current auto-update mechanism, rather, they could leave it in place. This is how the “Add/Remove Programs” console works. Software developers have not removed the mechanism to uninstall from their software, rather, they have placed hooks in the “Add/Remove Programs” console that calls their uninstall and repair mechanism. Users and admins who prefer a particular method are all satisfied.

Finally, it is not like this is not done other places. Linux in particular, and to a smaller context Apple, has been doing this for a while. Most distros have a packaging system the allows developers to centralize the patch management and automatic updates. End users and admins only have to worry about watching for updates to software that they have installed outside that packaging system. Very nice, very ease, very secure.

So, how about it Microsoft? Don’t you think that this would benefit everybody? It certainly could not hurt.

Go forth and do good things,
Cutaway

Microsoft, Apple, updates, patches, automatic updates, patch management, Security Ripcord

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported.

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.