Follow GFI:
Find us on Facebook Follow us on Twitter Find us on Linkedin Subscribe to our RSS Feed Find us on YouTube Find us on Google+
 

What Should Be Included In Your Patch Management Policy?

on June 2, 2011

Creating a patch management policy Most organizations pay attention to security and patching their systems, but how many have a well-honed patch management policy? Patch management is often seen as a trivial task. Simply click on ‘update’ and that’s it. But in reality there is a lot more to it and a proper policy is certainly not overkill. But what should a patch management policy include apart from deploying patches.

  • Monitoring

The first important step in a patch management operation is to know when there is a need for a patch to be made. A patch management policy should have a section detailing what must be done to ensure the security personnel know what to do in this situation. Patch scanning can be one option or monitoring the media. Patch scanning is obviously the most convenient method and the least time-consuming as in most cases it can be setup and left to work autonomously. However, even then your monitoring policy should still include monitoring of current events because it is not always the case that a patch is released before a vulnerability is made known to the world. Sometimes the vulnerability is disclosed before a vendor has had time to develop a patch and it is imperative that when this happens your security team acts on it just the same.

  • Handling cases where a patch isn’t available

The patch management policy should include details of what the security team should do when an application or operation system component requires patching but that patch is not yet available. What steps would they need to take before disabling a component or implementing a workaround? Who are the stakeholders they will need approval from?

  • Testing

An essential step in patch management is to ensure that the patch about to be deployed will not conflict with the current environment. To do this the organization will require an effective change management policy so that the patch management team has a current mirror of the different environments in the organization so that patches can be tested on these systems before being deployed to live environments.

  • What requires patching?

If not clearly defined, most people relate patch management to the operation system only. Applications that are not connected with the operation system also require patching because they can be a security risk. It is important to define the scope of the patch management operation when writing a patch management policy to ensure no application is overlooked during the patch management process.

  • Patch deployment

The patch management policy must list the times and limit of operations the patch management team is allowed to carry out. For example, patches that do not require a restart might be deployed during working hours, while those that do are deployed after working hours. The policy would need to include a notification to users when they can expect reboots or when they are required to have their machines available for a patch deployment.

  • Disaster recovery

No matter how good your staff and systems are, things can still go wrong. Therefore, the patch management policy will include a disaster recovery procedure, including details on how to revert bad patches or what the team should do if reverting to a previous version is not possible.

  • Reporting

Patch management is generally included in various compliance regulations. Thus, the team has to document their efforts to be in compliance with certain regulations. Effective reporting can also help pinpoint potential issues; allowing for further refinement of the policy and instructions that will help the team avoid pitfalls in future.

Even though patch management that can be performed quickly, doing it properly is what counts most and doing so requires a lot more work. With an effective patch management policy in place, the team will know exactly what is expected of them and what they need to do. The extra effort required to perform an effective patch management operation is more than justified when a single botched patch management operation can lead to down time, profit loss and reputation loss.

 
Comments
Paula Franco June 2, 20112:53 pm

Like anything, patch management is about making sure all your bases are covered in case something goes wrong. Having a patch management policy is all about protecting yourself in the worst case scenario. A list of things to consider like this is a great foundation for that kind of thing in case it brings up something that you may have forgotten to consider when preparing a system of patch management for your organization. Thanks for the article.

Emmanuel Carabott June 3, 201111:10 am

Thanks for your kind words Paula, and you’re right, Patch Management is exactly about having as many bases as possible covered for when things go wrong.

Morris July 10, 20118:37 pm

Thanks from me to, the article is a great checklist about the whole patch management process. A very concise list of all the points one shouldn’t skip. I must admit, I personally do omit many of the steps but fortunately, since I am currently not in charge of a huge network, so there won’t be many fatalities if I skip a step or two (I know, I shouldn’t be doing it but anyway I am doing it).