Patch management is a crucial task. All organizations must perform and Regularly patch OSs, middleware, and applications to guard against newly found vulnerabilities or to provide additional functionality.
Patch management is the process of identifying, acquiring, installing, and verifying patches for products and systems. Patches correct security and functionality problems in software and firmware.
From a security perspective, patches are most often of interest because they are mitigating software flaw vulnerabilities.
Applying patches to eliminate these vulnerabilities significantly reduces the opportunities for exploitation.
Patches serve other purposes than just fixing software flaws; they can also add new features to software and firmware, including security capabilities.
New features can also be added through upgrades, which bring software or firmware to a newer version in a much broader change than just applying a patch.
Upgrades may also fix security and functionality problems in previous versions of software and firmware.
Also, vendors often stop supporting older versions of their products, which includes no longer releasing patches to address new vulnerabilities, thus making older unsupported versions less secure over time.
Upgrades are necessary to get such products to a supported version that is patched and that has ongoing support for patching newly discovered vulnerabilities.
You should develop a patch management plan for the implementation of system patches.
The plan should be part of the configuration-management process and allow you to test patches before deployment.
Live migration of VMs should take place before patching through the use of maintenance mode for all hosts that need to be patched.
You need to understand the vendor-specific requirements of patch management based on the technology platforms under management.
The NIST SP 800-40, “Guide to Enterprise Patch Management Technologies,” is a good point of reference.
The Cloud Patch Management Process
A patch management process should address the following items:
- Vulnerability detection and evaluation by the vendor
- Subscription mechanism to vendor patch notifications
- Severity assessment of the patch by the receiving enterprise using that software
- Applicability assessment of the patch on target systems
- Opening of tracking records in case of patch applicability
- Customer notification of applicable patches, if required
- Change management
- Successful patch application verification
- Issue and risk management in case of unexpected troubles or conflicting actions
- Closure of tracking records with all auditable artifacts
- Some of the steps in the outlined process are well suited for automation in the cloud and traditional IT environment implementations, but others require human interaction to be successfully carried out.
Cloud Patch Management Automation
Automation starts with notifications. Several things happen when a vulnerability is detected:
- Its severity is assessed.
- A security patch or an interim solution is provided.
- This information is entered into a system.
- Automated email notifications are sent to predefined accounts in a straightforward process
Following are other areas for automation:
- Security patch applicability. If there is an up-to-date software inventory available for reference that includes all software versions, releases, and maintenance levels in production, automatic matching of incoming security vulnerability information can be easily performed against the software inventory.
- The creation of tracking records and their assignment to predefined resolver groups, in case of matching.
- Change record creation, change approval and change implementation (if agreed-upon maintenance windows have been established and are being managed via SLAs).
- Verification of the successful implementation of security patches.
- Creation of documentation to support that patching has been accomplished.
Challenges of Cloud Patch Management
The cloud presents unique opportunities and challenges for patch management.
Although the cloud offers highly standardized solutions for customers, it also offers unique challenges because cloud deployments can range from small, single-tenant to extremely large, multitenant environments, with a deep vertical stack due to virtualization.
The following are major hurdles for patch management automation in existing managed environments:
- There’s a lack of service standardization. For enterprises transitioning to the cloud, lack of standardization is the main issue.
- For example, a patch management solution tailored to one customer often cannot be used or easily adopted by another customer.
- Patch management is not simply using a patch tool to apply patches to endpoint systems, but rather a collaboration of multiple management tools and teams,
- such as change management and patch advisory tools.
- In a large enterprise environment, patch tools need to be able to interact with a large number of managed entities in a scalable way and handle the heterogeneity that is unavoidable in such environments.
- To avoid problems associated with automatically applying patches to endpoints, thorough testing of patches beforehand is mandatory.
Beyond those issues, two additional key challenges include VMs running in multiple time zones and VMs that have been suspended and snapshotted.
These concerns are addressed in the following sections.
Multiple Time Zones
In a cloud environment, VMs that are physically located in the same time zone can be configured to operate in different time zones.
When a customer’s VMs span multiple time zones, patches need to be scheduled carefully so the correct behavior is implemented. For some patches, the correct behavior is to apply the patches at the same local time of each VM, such as applying MS98-021 from Microsoft to all Windows machines at 11:00 p.m. of their respective local time.
For other patches, the correct behavior is to apply at the same absolute time to avoid a mixed-mode problem where multiple versions of the software are concurrently running, resulting in data corruption.
Here are some of the challenges that the Cloud patch management professionals may face in this area:
- How can a patch be applied to 1,000 VMs at the same time across multiple time zones?
- How do we coordinate maintenance mode windows for such a deployment activity?
- Is the change-management function aware of the need to patch across multiple time zones?
- If it is, has a rolling window been stipulated and approved for the application of the patches?
VM Suspension and Snapshot
In a virtualized environment, additional modes of operations are available to system administrators and users, such as VM suspension and resume, snapshot, and revert.
The management console that allows the use of these operations needs to be tightly integrated with the patch management and compliance processes. Otherwise, a VM can become non-compliant unexpectedly.
For example, before a VM is suspended, it is patched to the latest deployed patch level using the automated patch management process.
When it resumes after an extended amount of time, it is most likely in a non-compliant state with missing patches.
Therefore, the patch management system must catch it up to the latest patch level before handing the VM to the user’s control.
Likewise, when a VM is reverted to an earlier snapshot, baselining the VM to the latest patch level is most likely required.
Following are some of the challenges that the patch management professionals may face in this area:
- Have all VMs that require the update been patched?
- Can that be validated for compliance reporting or auditing?
- Does the technology platform allow for patching of a suspended VM? A snapshotted instance of a VM?
- Can these activities be automated using the technology platform?
