This article recommends some best practices for administrators and security officers using Miradore Management Suite's Patch Management module.
Recommendations for the administrators:
During the implementation phase of Miradore's Patch Management module, administrators need to choose all languages and operating system versions for which patches are desired to be managed with Miradore Management Suite. For this phase, we give three recommendations:
1. In large environments with thousands of devices, it is recommended to add supported operating systems gradually, because choosing multiple options at once may cause immense impact to the performance when the system starts to process the patches. Choose some of the desired operating system versions first, and add more later when the patch manager component has successfully processed the patches for the previously selected operating system.
2. Don’t choose any unnecessary operating system versions because choosing more operating system versions quickly increases the amount of required disk space and network bandwidth needed for processing and storing the patch data.
3. If some application is used in a different language other than the operating system language, remember to add the application language to the scope of the patch management. For example, internet browsers often have a different language version than the operating system and if the browser language is not selected to be supported, the browser may not be patched correctly.
You should also know that only patches or updates categorized as security patches are automatically included in the patch feed by default. The release of missing non-security updates must be requested separately from Miradore support.
Schedule and scope of automated patching actions
During the implementation phase, administrators can also configure the basic settings for patch scanning and deployment in your environment. These settings determine what computers (asset groups) are included in the scope of the patch management, and how often patch scans or installations are performed automatically on the devices.
We recommend to use the interval of 24 hours for the patch scan and installation profile. This ensures that the vulnerabilities are dealt with in a timely manner. Running the scans and installations more frequently is not recommended because it may cause high performance load unnecessarily often, thus disturbing the end-users.
We also recommend to set a carefully thought allowed time frame for the patch scan and install actions. The allowed time frame should be scheduled for off-peak hours when the computers are also most likely turned on. Otherwise, users may feel the patching actions disturbing, or performing the patching actions may not be possible. For servers, it is often best to set the allowed time frame for the nighttime. Also, make sure to not define a too narrow time frame because it may take some time to download and install the patches, especially if the network connection is slow.
With the Profile scope, you can choose what devices or device groups should be included in the scope of the patch management. Notice that you can create multiple Scheduled task profiles to set different scopes and schedules for different devices.
If you want to separately control when patch installations can take place, you can do that by defining the Patch maintenance window(s) in Miradore Management suite.
When creating the patch maintenance windows, make sure you configure the settings well in advance, because it may take a day or two before all managed clients start to follow the restrictions set by the patch maintenance window.
Notice that you can create multiple maintenance windows if necessary.
Bandwidth and storage considerations
In networks with low bandwidth capacity, you can control the bandwidth consumption of Miradore's Patch Management by using the Max bandwidth for file copying per distribution setting that is located in the Location item. This setting defines the maximum bandwidth consumption for assets that are assigned to the location. This setting applies to Miradore package distributions and to the downloading of the patch data.
In the System settings > Patch management > Patch management settings, you can define what and in which case patch installation packages should be downloaded to the Miradore media master installation point. The recommended setting is to download the approved non-installed patches. Downloading all not installed patches is not recommended because that can easily consume very large amounts of disk space.
Besides that, you can also configure how many days of cached but unused patch data will be stored at the media master installation point and how quickly a patch becomes obsolete after it is omitted from the daily patch feed that is imported to the Miradore server.
Recommendations for the security officers:
This section recommends some best practices for the day-to-day patch management activities. If you’re looking for more detailed operator’s instructions for use, please refer to the Operator’s Guide in the product guide of Miradore Management Suite.
Study the patching status
After a patch scan has completed, 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 should the new patches be applied? How should the old patches be applied?
- 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 (superseded).
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.
Please send comments to firstname.lastname@example.org.