We often hear the advice “patch early, patch often” as a mantra for keeping software up to date. The unfortunate truth is that not all patches fix the problems they were designed to fix and some patches actually do more damage than good.
As I write this, there is an issue with a patch for Microsoft Windows. It’s known as MS13-081/KB 2862330. It appears that this patch causes the occasional “Blue Screen”. For a concise description of the patch and the issues, check out this article from InfoWorld. (InfoWorld does a great job of keeping up with issues like this. Disclaimer: Learning Tree doesn’t endorse any products in these blogs, but I do read this blog myself on a regular basis).
In Learning Tree Course 468, System and Network Security Introduction we discuss the importance of patching systems. It is necessary to keep software up-to-date as developers, researchers and users discover issues with software than can be fixed by “patching” – the process of releasing new versions of a program or library. Occasionally a new part of the operating system (a device driver, for instance) needs to be updated for a security issue. Of course systems can be patched or updated for other reasons besides security – maybe to add features or improve performance, for example.
But it’s not a good idea to rush all patches into production. They need to be tested in your environment to ensure they don’t break anything. Many organizations have copies of production systems set up for just this purpose. If the copy is patched and if the patch fails or causes issues, the live systems are not impacted and the copy systems can be easily be restored from backups. On one project where I served as developer, we had a test server and we kept a backup copy of that server’s disk. If a patch failed, we inserted the copy drive and ran the test server from that while restoring or analyzing the disk with the failed patch. That scenario worked quite well for us.
Some organizations have reported a habit of waiting for others to test patches. They receive the patches but don’t install them until others have reported the success of the new versions and issues have not been reported. That leads to slower patching, but for small companies it may be a workable solution.
What method of patch control do you use? Take the survey and let us know in the comments below.