Who patches the guest OS? Correcting a shared responsibility misreading before an external audit
Northwind Bank runs 62 AWS accounts under AWS Organizations. During a quarterly review, an internal auditor flags 'unpatched OpenSSL 1.1.1 on 38 EC2 instances' and writes: 'Patching the guest operating system is AWS's responsibility under the shared responsibility model - raise a support case.' A separate finding notes that the same team runs 11 Amazon RDS for PostgreSQL instances and has never scheduled an engine upgrade, which a developer defends with 'RDS is managed, so AWS does everything.' The CISO wants a written clarification before the external audit in three weeks, plus a control plan that will generate evidence next quarter. The team currently has no patch baseline, no tagging standard, and no inventory of which instances are production. There are 4 cloud security engineers and roughly 900 EC2 instances across the estate.
1. Explain the responsibility boundary for the 38 EC2 instances and for the 11 RDS instances, and state precisely what is wrong with the auditor's statement.
Read the worked answer
Responsibility follows the service model, not the provider's brand.
- EC2 is IaaS. AWS owns facilities, physical hosts, the hypervisor, and the managed network backbone. The customer owns the guest OS and everything above it: kernel and library patching (including OpenSSL), host firewalling, security groups, IAM, data, and application code. The 38 unpatched instances are therefore Northwind's gap. The auditor's statement is wrong on its face.
- RDS is a managed service. AWS patches the database engine and the underlying OS, and applies minor versions automatically during the maintenance window. The customer still owns parameter groups, security groups, IAM and authentication, KMS keys, schema, data, and the decision to accept a major-version upgrade when AWS deprecates a release. So the developer is only half right: AWS executes the patch, but ignoring end-of-life dates is a customer failure.
For the audit response: (1) correct the responsibility statement in writing, citing the AWS shared responsibility documentation and the service terms for each service; (2) evidence the RDS side with maintenance-window configuration, DescribePendingMaintenanceActions output, and engine-version lifecycle dates; (3) accept the EC2 finding as a customer-side control gap and attach the remediation plan so the auditor sees ownership plus a dated fix, not a dispute.
2. Propose a control plan that both fixes the patching problem and produces defensible audit evidence within one quarter, given 4 engineers and 900 instances.
Read the worked answer
Do not try to patch 900 hosts by hand with 4 people - build a pipeline and make it the only path.
- Inventory and ownership. Enforce
Owner,Environment,PatchGrouptags with an AWS Config required-tags rule plus an SCP that blocks instance launch without them. Anything untagged goes to a quarantine OU so it cannot silently drift. - Baseline. Rebuild golden AMIs monthly with EC2 Image Builder against the CIS benchmark, so new capacity is born patched. For existing instances use SSM Patch Manager maintenance windows per PatchGroup with a two-tier SLA: critical CVEs within 7 days, everything else within 30.
- Detection. Amazon Inspector scans continuously; route findings to Security Hub and build a custom insight limited to production and internet-facing so the queue stays actionable.
- Exceptions. Time-boxed, ticket-approved suppressions with an expiry date recorded in Security Hub. No permanent exceptions.
- Evidence. Config rule for patch compliance, monthly export of Inspector findings and maintenance-window results to S3 with Object Lock, and a one-page dashboard.
- Operating model. The 4 engineers own the pipeline, not the patching; application owners receive auto-created tickets. Track one headline metric: percentage of production instances with no critical CVE older than 7 days, target 95% by quarter end.