Appearance
Patch Management
Purpose
This document defines the patch management policy, SLAs, tooling architecture, exception process, and HIPAA audit evidence requirements for all Cirius Group infrastructure — Azure (PROD and DDE) and AWS.
Scope
| Environment | Tooling | Coverage |
|---|---|---|
| Azure PROD | Azure Update Manager | All Windows VMs (BIZADSAZP01, BIZARCAZP01, BIZFTPAZP01, CGIADSAZP01, CGIRDPAZP01, NNTFIMAZP01, VEEAMAZP01, BIZWRKAZP01–09, ACTDIRAZP01, ACTDIRAZP02) |
| Azure DDE | Azure Update Manager | All AVD session hosts (bc-host-01–07), AD VMs (ACTDIRAZC01, ACTDIRAZC02, ENTRACAZC01), syslogdde |
| AWS Prod | AWS SSM Patch Manager | cgirdpawp01, bizftpawp01, Cloud PC (Ubuntu 24.04) |
| AWS Identity | AWS SSM Patch Manager | actdirawp01, actdirawp02 |
| AWS Management | AWS SSM Patch Manager | Management Ubuntu instances |
| AWS Networking | AWS SSM Patch Manager | syslogawp |
Excluded from automated patching: Palo Alto firewalls and Panorama (PAN-OS managed by Palo Alto), Arctic Wolf VLC appliances (vendor-managed), decommission-bound resources.
Patch SLAs
| Severity | Apply SLA | Notes |
|---|---|---|
| Critical | 48 hours | Immediate triage; emergency out-of-band patching if needed |
| High (Important) | 7 days | Standard maintenance window sufficient in most cases |
| Medium | 30 days | Next scheduled maintenance window |
| Low | 90 days | Next scheduled maintenance window |
SLAs measure time from vendor patch release to confirmed installation. Auto-approval timers in tooling are set to 7 days as a stability soak period. Critical severity patches that require faster application are handled via emergency out-of-band windows (see Exception Process below).
Azure Update Manager — Architecture
Two maintenance configurations per resource group:
| Configuration | Schedule | Classifications |
|---|---|---|
<prefix>-patch-critical | 1st Tuesday monthly, 02:00 UTC | Critical + Security |
<prefix>-patch-monthly | 3rd Tuesday monthly, 02:00 UTC | All classifications |
- Reboot policy:
Never— patches install without forced reboot. Manual reboot is planned outside business hours as needed. - Assessment mode:
AutomaticByPlatform— Azure continuously assesses patch state. - Patch mode:
AutomaticByPlatform— Azure Update Manager drives installation; OS auto-update is disabled. - All VMs are enrolled in both windows: critical patches apply on Patch Tuesday, all remaining patches apply two weeks later.
- Business hours: 02:00 UTC = 21:00 ET / 18:00 PT — outside business hours for all US time zones.
Terraform: azure-infra/modules/patch-management/ (PROD), azure-dde-infra/billings/avd/ and azure-dde-infra/firewall/ (DDE).
AWS SSM Patch Manager — Architecture
| Component | Configuration |
|---|---|
| Baseline | cirius-windows-patch-baseline — CriticalUpdates + SecurityUpdates, MSRC Critical + Important, 7-day auto-approve |
| Baseline | cirius-ubuntu-patch-baseline — Required + Important priority, 7-day auto-approve |
| Maintenance window | Nightly, 02:00 UTC, 3-hour duration, 1-hour cutoff |
| Reboot policy | NoReboot — patches install without forced reboot |
| Tag-based targeting | EC2 instances tagged PatchGroup=cirius-windows-patch or cirius-ubuntu-patch |
Accounts with active baselines: Prod (807267566999), Identity (414134953818), Management (206820231356), Networking/Firewall (238342914131).
Accounts with no EC2s (no baseline needed): Backup, Dev (instances decommissioned), Logging.
Terraform: aws-infra/<account>/patch_manager.tf per account.
Exception Process
Exceptions to standard patch SLAs require written approval from Rory and must be documented as a SecOps risk acceptance.
When exceptions apply:
- A patch introduces a known regression with a production impact higher than the vulnerability risk
- A patch requires a reboot during a period when the VM cannot be taken offline (e.g., active payer billing runs)
- A vendor-managed component is affected (coordinate with vendor before patching)
Process:
- Engineer identifies the conflict and documents the specific CVE, patch KB, and risk rationale
- Rory reviews and approves or denies in SecOps (PATCH story with
ACCEPTED_RISKlabel is not permitted — use exception documentation only) - A deferred patch SLA is agreed with a firm end date not to exceed 2x the original SLA
- The exception is tracked in SecOps as an open finding until patched
Emergency out-of-band patching (Critical CVE within 48h):
- Create a SecOps CM ticket for the maintenance window
- Manually trigger
AWS-RunPatchBaselinevia SSM Run Command on affected instances - For Azure: manually trigger patch scan and install via Azure Update Manager portal
- Confirm patch applied via SSM compliance report or Azure Update Manager assessment
- Close CM ticket
HIPAA Audit Evidence
Patch compliance is included in the weekly HIPAA audit pipeline (ops-automation/.github/workflows/weekly-hipaa-audit.yml).
| Evidence artifact | Source | Retention |
|---|---|---|
aws-patch-results.json | SSM describe-instance-patch-states across 4 accounts | 90 days in GitHub Actions artifacts |
aws-patch-findings.json | Classified HIGH/MEDIUM lag instances posted to SecOps | Permanent in SecOps findings |
azure-patch-results.json | Azure Update Manager assessment per VM | 90 days in GitHub Actions artifacts |
| Azure Update Manager assessment history | Azure portal / Log Analytics | 90 days LAW, 6 years WORM archive |
Compliance thresholds (automated):
> 30 dayssince last SSM patch scan → HIGH finding in SecOps7–30 dayssince last SSM patch scan → MEDIUM finding in SecOps- Missing patches present → MEDIUM finding in SecOps
For HIPAA audits, pull the weekly artifact from the hipaa-audit-<date> GitHub Actions run and the SecOps findings export for the audit period.
Monitoring and Alerting
- Weekly HIPAA audit emails include patch compliance summary for both Azure and AWS
- HIGH lag instances generate SecOps findings that appear in the analyst queue
- Azure Update Manager assessment results are queryable via Log Analytics (
cirius-logging-law-central)