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.
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?
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.
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.
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.
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.