5 Ways to Create the Right Patch Management Policy

While patch management is, conceptually, a straightforward task, its correct implementation is not always that simple. One might be tempted to simply deploy patches on a need to basis without giving it much thought; however, in order for patch management to be fully effective, the right patch management policy is required, as without it patch management could become the threat you’re actually trying to prevent.

So what makes the right patch management policy?

1. Inventory

Without knowing which software or systems need patching, no proper patch management process can exist. While this might seem obvious, it’s a step often overlooked in a company’s patch management policy. An inventory is also required when testing environments are created – an essential item in any patch management policy. Inventories can be done manually, however it’s wise to either have scripts that automate the process to a degree, or use a network scanner to do the job.

2. Monitoring

Every patch management policy needs a process that can identify which patches are missing or outdated, and this can be achieved by either monitoring vendor sites or using patch management detection software.

3. Testing

Once an administrator determines and downloads the patches needed on the network, it is essential that they are tested before they are deployed to make sure that that they are working well across all systems. Test environments that perfectly mimic the actual environments that the patches will be deployed on are needed. A blueprint for such environments ought to be prepared during the inventory step. As time goes by it’s important to keep the test environments in line with the actual environments. This can be done by comparing inventories or through the use of software which can notify the administrator when environments change.

4. Deployment and Verification

This is another pitfall. For many, their patch management process does not include verification but just deployment; however, the right patch management policy requires both. If the deployment fails for any reason, especially if the whole process of deployment is unattended, it can easily happen that the failure goes unnoticed thus giving the administrator a false sense of security. To avoid this, ensure that there is a way to determine the patch level of each machine and confirm that all the patches deployed were successful.

5. Disaster Recovery

No matter how many precautions are taken and how many tests are run, there is no guarantee that a patch deployment will not cause issues. Computer software is complex and it is impossible to test all possible combinations, especially when you factor hardware and chipsets in. Therefore, it is essential that a patch management policy includes a section on disaster recovery, so, should things go wrong, an administrator will be able to quickly recover the network to a working state.

Without the right patch management policy in place, patch management can indirectly be a security risk since the patch deployment itself can cause issues and possibly downtime. Once designed, the patch management policy will require a little extra effort; however, this is a much more favourable option than the effort spent trying to fix a broken environment, not to mention the loss of productivity.

Editor Note: This guest post was provided by Casper Manes 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. Learn more about creating the right patch management policy.