Why Patch Management Should Not Be a Fire and Forget Operation

We all know that patch management is an essential task to keep our network safe. There are various approaches to running a patch management process. Windows allows an administrator to set the auto-update system to automatically install patches when these are made available by Microsoft. While having a patch management system that automatically deploys patches as they become available is certainly better than having no patch management system at all, one must be aware of the risks this approach entails. To ensure maximum security and systems availability, the patch management process has to have some human intervention. In this post I’ll discuss what manual intervention is needed and why.

1.      Testing

Patches are essentially small code changes to software. These changes most of the time affect the way the application does certain things internally, and most of the time these changes will not impact other software; however, sometimes these changes do alter the way an application interacts with other applications, or even hardware, and when that happens the patch itself might stop other applications from working properly or even lead to system instability. To avoid downtime due to patch installation it is therefore essential that patches are tested on a test environment that closely resembles the live environment before they are deployed. Critical applications should then be tested to ensure these operate well even after patches are deployed.

2.      Verification

A patch is effective only if it is deployed successfully. There are a number of reasons why a patch installation might fail. These can include factors such as missing dependencies or perhaps a user stops the installation as it might have been interfering with his work. Perhaps more likely an employee who leaves his system constantly running  because it’s convenient, prevents the patch from restarting his machine and the said patch will not become effective until the machine is restarted at some point in the future. These issues highlight the need that after patch deployment, whether automated or manual, the network should be audited again to ensure the all patches have been deployed successfully and that none are still missing.

3.      Post-Deployment

The job of the administrator in terms of patch management does not end with patch deployment. An administrator can expect people experiencing issues due to the deployed patches, and s/he also needs to ensure the deployed patches do not require environment reconfiguration to be complete in the securing process.  In any event, changes due to the patch deployment in the live network will also need to be mirrored in the testing network – an important step that is often neglected.

Patch management is essential; it can be time consuming, so automating tasks as much as possible is a good move. It is important however to keep in mind that just because patch management can be fully automated it does not mean that it can be left running with no supervision. The few manual procedures mentioned in this article will not take long for the administrator to accomplish, however neglecting them might result in an unstable system which is what patch management is meant to prevent in the first place.

This guest post was provided by Emmanuel Carabott on behalf of GFI Software Ltd. GFI is a leading software developer that provides a single source for network administrators to address their network security, content security and messaging needs. Read more on the importance of patch management.

All product and company names herein may be trademarks of their respective owners.

Notify of
1 Comment
Newest Most Voted
Inline Feedbacks
View all comments

[…] Why Patch Management Should Not Be a Fire and Forget Operation http://www.sectechno.com/2011/11/15/why-patch-management-should-not-be-a-fire-and-forget-operation/ […]