This article recommends some best practices for how to stay secure and ensure patch compliance when using Miradore Management Suite’s Patch Management module.
If you’re looking for the user guide or operator’s instructions, please refer to the Operator’s Guide in the product guide of Miradore Management Suite.
Study the patching status
After a patch scan has run, the results of the patch scan appear into the Security patch status view, which is located under the Operations > Security management settings in the user interface of Miradore Management Suite.
Before approving or deploying any patches, we recommend you to open this view and try to get a comprehensive understanding of the patching status of your software and computers. Identify what are the most common and severe patches that are missing from your computers.
Also, check which patches have been superseded by newer patches, because you might not want to deploy patches that have already been replaced by newer patches.
Create a patching plan
Before you actually start approving the patch deployments, we recommend you to spend a while to plan your patching principles. Below you can find a checklist of questions and tips that might help you with this.
- What patches are you or your customer interested in? Make a list of software applications to be patched.
- Review and verify your list against the results of the patch scan. Make sure your list is not unintentionally missing any software that has been detected in the environment.
- How soon new patches should be applied to managed computers?
- Who is responsible for approving patches and for maintaining the patch approval rules?
- How long are patch deployments tested with pilot computers before deploying the patches to the production computers? Our recommendation is 7 days.
- Should users be informed about the patching activities? We recommend to inform at least the pilot users about the new patch deployments so that they can report back the possible problems.
Approve the existing patches manually
When you have a conception of what existing patches you want to deploy to your devices, we recommend to approve the patches using the view tools in the Operations > Security patch status view.
It’s good practice to start approving the patches from the most recent ones and pay attention to the Superseded and Installed by superseding data columns. This way you can easily avoid the deployment of unnecessary patches that have already been replaced by newer patches.
This manual method of approving patches is also recommended for patches that are very urgent to deploy as soon as possible (in matter of hours rather than days). For those cases, the automated approval workflow might be too slow.
Define patch approval rules for the future patches
If you want to be very attentive to what software patches or updates are approved for installation in your environment, keep checking the Security patch view for updates regularly and handle the patch approvals manually as described in the previous paragraph.
However, we recommend to define automatic approval rules for the future patches because that can save you a great deal of manual work.
When creating an automatic patch approval rule, you can test the rule’s scope using the Show matching patches task under the Tasks menu. We advise not to use the “Apply rule” button on the popup window because that may lead to approving already superseded or undesired patches. Use the popup only for evaluating the scope of the automatic approval rules that you are creating.
Also, when creating the automatic patch approval rules, we recommend to define the rules for each software vendor separately, or by the patch category. For example, one rule could be for approving critical patches. This way, understanding and managing the patch approval rules is easier.
In addition, you should always approve all patches for a pilot group first and wait for 7 days before approving the patches for the production computers. If any problems would occur with the pilot computers, then do not approve the patch for the production computers before resolving the problems first.
Reminder about the importance of patch testing
Always test new patches against typical workstation and server configurations in a pilot or test environment before deploying the patches to any production computers. Try to avoid deploying any patches to the production computers without testing them first.
Make sure that you have a diverse set of test or pilot devices that you can ensure the patches’ compatibility with all business critical applications on all affected operating systems. The pilot computers should be non-business critical and easily recoverable in case any problems would occur.
Also, pay attention to the users of the pilot computers when choosing the pilot systems. If possible, try to select pilot devices whose users are tech-savvy and perceptive. Remember to inform the users about the upcoming patch deployments so that they are aware of what’s going on, and thus ready to report any possible problems without delay.
Always have a patch rollback plan prepared in case the patches would cause any problems on the target devices.