Reliability
Part of Cloud security operations
Managing operating system updates for cloud servers: 4 steps
Plan cloud server patch priorities and deployment waves, then verify application health and track skipped or failed machines.
Use a four-step cycle for guest operating system updates on cloud servers: identify affected machines, prioritise fixes, deploy in a controlled window, and verify the application. A patch dashboard is a starting point; it does not show that every server was assessed, every update installed or the application remained healthy after a restart.
Identify machines and fixes
Keep a register of virtual machines and server images with their owner, operating system, support status, exposure, update source and application role. Include temporary and seldom-run machines; a server missing from an assessment may be stopped or unreachable rather than fully patched.
For each available security fix, record the affected systems, vendor advice, known exploitation information and machines in scope. Compare the intended machine list with assessment results so you can identify servers that were missed.
Step 2: Prioritise fixes using the organisation’s policy and current risk information. Consider exposure, severity, vendor advice and known exploitation when setting a deadline.
If using ASD Essential Eight Maturity Level 1 timeframes, internet-facing servers and network devices have a 48-hour timeframe if a flaw is critical or exploited, otherwise two weeks. The timeframe for workstations, internal servers and network devices is one month.
Keep an exception route for urgent security work during a change freeze. Record the reason and set a deadline for resolving the exception.
Plan a wave the service can tolerate
Group machines by workload, not only operating system, and decide which instances can restart without stopping the service. Identify workloads that need drained traffic, a replacement image or a maintenance notice before the window.
Check that a suitable recovery point and recovery procedure are available before deployment. A snapshot alone does not prove the application can be restored.
Validate an update on a representative non-production machine first where useful, and record what the check covers. For a service with several instances, decide which machines receive updates first and what observation allows the next wave.
Use a schedule and target group to make the deployment window controlled. Azure Update Manager maintenance configurations each have a single schedule and can target any number of resources through associations; Update Manager also supports central scheduling, compliance reporting and staged deployments.
Azure Update Manager assesses and applies guest operating system updates to Azure virtual machines and Azure Arc-enabled servers running Windows or Linux. It honours each machine’s configured update source and does not publish or provide updates; for Windows Azure VMs, it controls the native Windows Update Agent (WUA).
For Azure Windows VMs, Microsoft recommends Update Manager for central scheduling, compliance reporting and staged deployments. Microsoft also recommends validating updates in pre-production before promoting them to production.
For IBM Cloud Classic Bare Metal Servers, IBM Cloud Classic infrastructure provides private-network access to locally hosted repository mirrors for multiple Linux distributions, Microsoft Server Update Services (WSUS), Red Hat Satellite infrastructure and a locally hosted SUSE for SAP repository. Updates can also come directly from vendors.
Verify results and close exceptions
After each wave, check installation status, reboot state, service health and an important application action. Compare the intended machine list with the machines actually assessed and updated.
For Windows Azure VMs patched through Update Manager, updates might not appear in Settings > Windows Update > Update history because they use the WUA API. Review WindowsUpdateClient events in Windows Event Viewer to verify installation.
Assign failures, skipped machines and pending restarts an owner and deadline. Reassess a repaired machine rather than treating a rescheduled job as a completed fix.
Keep the affected-machine list, patch or mitigation, priority reason, approval, deployment results, application checks and unresolved items together.
