Complexity requires new cloud-based patch management strategies
Patch management for cloud creates new challenges than traditional in-house programs. Expert Dave Shackleford presents patch management best practices for providers and consumers alike.
It's important to remember that cloud-based patch management systems and applications may differ from traditional in-house programs. These differences will extend to different types of deployments.
For example, patching for SaaS deployments is relatively straightforward, because consumers have no control over patching processes. This can present significant risks if the provider doesn't patch software and components in a timely fashion.
Consumer responsibility for cloud-based patch management
All consumers should verify their SaaS or PaaS provider's patching cycles. The service provider should also communicate patching to customers so they are aware of potential performance or availability issues.
Ensure the provider has the capability to rapidly patch vulnerabilities across all devices, applications and systems. Ask whether the provider will share its risk-based patching time frames with tenants. Ultimately, organizations should look for a cloud service provider with processes that align with their internal patch management practices and standards.
PaaS cloud-based patch management best practices
For PaaS environments, organizations will have slightly more control over patching and configuration -- particularly application and development environment components and libraries. Look to integrate any of the platforms -- ASP .NET, PHP, Java, etc. -- used, and the applications running on them, into existing test and quality assurance cycles, with fixes applied at the same time or in the same cycle as internal applications.
Patch management is a huge challenge in PaaS environments. Infrastructure teams need to coordinate closely with development and testing teams when applying patches in these environments. Change windows also need to be planned to accommodate those approved by the cloud provider, if applicable. If using containers for PaaS deployments, the container images can be patched and tested before being deployed into a secure repository.
All back-end infrastructure, including operating systems and network components, is still patched by the provider. The same questions and concerns mentioned for SaaS environments should also apply with this model.
IaaS cloud-based patch management best practices
For IaaS providers, teams can install traditional patch management agents from providers like IBM and Microsoft. These agents can report to patch management systems located in a central data center or even in the same cloud infrastructure, depending on the deployment scenario.
New cloud-based patch management options are emerging for cloud workloads, such as AWS' Systems Manager and Microsoft's Azure Update Management service. These tools are likely more efficient and can be natively integrated with any instances running in that cloud infrastructure. They also include scripting and scheduling options.
Progressive cloud engineering and operations teams are moving away from traditional models of patching.
New and emerging cloud-native services may facilitate patching cloud workloads more readily, but some organizations still opt to use the same tools they already own for IaaS deployments to simplify operational management.
Progressive cloud engineering and operations teams are moving away from traditional models of patching. Instead of running workloads for extended periods of time that necessitate patch application to run systems, DevOps teams are now shifting toward patches and updates being applied to new system images. These are then pushed out to replace the old workloads.
This allows for extensive testing in the deployment pipeline. Patching and configuration are largely automated with the use of orchestration platforms like Chef, Puppet, Salt, Ansible and others. By applying patches through a configuration template or orchestration tool, teams can rapidly deploy patches and test outcomes on workload images, then push the new image with all updates into the production cloud.
Alternately, in a blue-green deployment, the test environment is validated and then becomes production, while the old production environment is now the test area.
Regardless of the cloud model in use, all providers should be formally evaluated for internal patching and vulnerability management controls. Providers should also be able to provide an independently verified attestation of controls like an SSAE 18 SOC report, at a minimum.
