Best Practices for Patch Management

The first item on an administrator’s to-do list is generally patch management. If done incorrectly patch management can be a risk for the organization instead of a risk mitigator. A few simple best practices however easily eliminate all of these risks as well as ensure that the process is finished quickly and efficiently.

Monitor the patch status of all your applications

The first step in patch management is to be aware when new patches are needed. The easiest way to accomplish this is by employing a solution that monitors your network patch status and notifies you automatically when patches are available. If budget is an issue another possibility is to keep track of what applications you use and periodically check the respective websites for new issued updates.

Caution: A common mistake here is that administrators sometimes focus exclusively on Microsoft patching only. This might be due to convenience because Microsoft have efficient patch management solutions or due to a genuine belief that this is enough. This however is a misconception, as applications from other vendors that have vulnerabilities left unpatched can pose a security risk just as much as any Microsoft application. Administrators should ensure all their applications are kept up to date.

Test patches before deploying

Often this step is skipped completely. When deploying patches without properly testing them out you risk that one of the patches might conflict and cause issues on the organization’s infrastructure.

You have to keep in mind that patches are pieces of code that change the existing code of the application they apply too. The changes can be numerous including a change in the behaviour of that application and/or its underlying libraries. In some cases these changes could conflict with other applications deployed on that system that make use of this functionality thus causing malfunctions which, in some cases, can be system wide.

There are reported cases in which patches cause a system to blue screen on boot up requiring a complete system reinstallation to recover.

Suggestion: Ensure optimum patch testing before patch deployment – it is good practice to keep a standardized installation on companywide workstations and servers. Ensure that you keep perfectly mirrored test machines with the same exact software and same versions of your production network. When you test the patches successfully on your test setup prior to patch deployment you can rest easy that no problems will be experienced when deploying on your production network.

Caution: For proper testing in this context it is essential that users are restricted from installing software indiscriminately. If a user installs a piece of software that the administrator is not aware of it might conflict with the patch about to be deployed.

Automate Deployment

Patch management can be a time consuming operation. There are plenty of patch management solutions that can help with automating this deployment process for both Microsoft and non-Microsoft patches thus minimising administrator interaction.

If budget is an issue there are free solutions by Microsoft that can help automate patch management for Microsoft products; however, as mentioned earlier it is still essential to patch non-Microsoft products even if this needs to be done manually.

Disaster Recovery

Another important, yet often overlooked, best practice is to have a disaster recovery plan should your patch management fail and cause problems. Backups are the easiest option and they can also be used to mitigate other risks such as a virus infection or intrusion.

Caution: When employing testing before deployment it might be tempting to think that disaster recovery from a botched patch is redundant as this risk would have been mitigated; however, there are various scenarios in which some subtle differences (perhaps even in hardware or a user installing an application without the administrator’s knowledge) might cause issues when the patch is deployed on the production environment yet have no issues on the testing environment itself.