Patch management is not as straightforward as one might imagine. A main consideration is the patch management tool used, but it’s important to realize that, while the tool plays an integral part of the patch management strategy, it is just one aspect in the overall strategy. What should one consider when choosing a tool and how does one deploy a patch management tool?
Patch Management Tool
Choosing the right patch management tool is an important part of the patch management process. There are many tool s available and although there are some common requirements, each entity needs to identify others areas that may require a different type of solution or one with additional functionality.
Common Requirements for all organizations
- Supports patching of Microsoft solutions
- Third party applications
- Customizable deployment strategy
- Patch rollback
- Automatically monitors for patches and informs you when these are available
- Allows manual control of the patch management process
- Multilingual patch support
- Allows you to deploy your own custom patches
- Alerts you of vulnerabilities that do not yet have a patch available
Requirements that differ from organization to organization
Deploying the Patch Management Tool
Proper patch management is more than just deploying patches as and when they become available. There is a process that one needs to follow.
- Configure the environment to work with the patch management tool. This can include:
- Creating the necessary accounts on our domain
- Setting up a test environment mirroring our main network setup in order to be able to test the patches before deployment
- Configuring firewalls to allow the proper access for the patch management tool.
The patch management process starts with you being aware of missing patches. When deploying your patch management solution you need to configure it with this in mind as it needs to automatically look for missing patches periodically and inform you when these are found.
When we know what patches are required, the next step is to test those patches on our test environment. At this stage we should have a mirror of our network’s various setups available on a test network. We need to deploy our patch management tool in a location where it can deploy these patches not only on our main network but also on our test network.
Provided testing goes well our next step is deployment. Some questions to ask before deploying patches:
- Will it force a reboot when deployment finishes?
- Will it allow the users to choose when to reboot or not in order to avoid disruptions?
- Can we set the deployment process to occur after working hours?
Next comes validation, make sure that after deployment is complete you use the tool to verify that the process was successful.
Finally we need to ensure the patch management tool is properly configured and can be used effectively in the event that you need to follow a disaster recovery plan. For example, if part of our disaster recovery plan includes patch rollback, is the tool configured to roll back patches quickly in case of disaster?
Deploying your patch management tool correctly is an important part of the patch management strategy. Patch management is partly meant to ensure maximum availability on your network therefore a bad deployment can hinder the stability of your network and cause the exact issues you set out to avoid 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.