Shared Responsibility When a Managed Database Is Exposed
NorthBank runs its cardholder-data platform on AWS: 40 EC2 instances, 12 RDS for PostgreSQL databases, and 300 S3 buckets. A regulator's audit found three issues in the same week: one S3 bucket containing daily settlement files allowed public read; six EC2 instances had operating-system patches missing for 90 days; and an RDS security group allowed 0.0.0.0/0 to port 5432. The cloud team says, 'AWS patches RDS and runs the hardware, so the database finding is AWS's problem.' The CISO wants a shared-responsibility decision for each finding, plus a control that would have caught it before the auditor did. NorthBank already owns CloudGuard Posture Management and CloudGuard Network Security, but has no workload-protection subscription, and the budget is frozen.
1. For each of the three findings, assign responsibility to AWS, NorthBank, or shared, and justify the allocation.
Read the worked answer
Responsibility follows control, not where the managed service runs.
- S3 public read - NorthBank. AWS secures the S3 service infrastructure and offers Block Public Access, encryption, and policy evaluation. The bucket policy, ACL, and public-access-block settings are customer configuration. The audit finding is a customer-side configuration defect.
- EC2 missing OS patches - NorthBank. EC2 is IaaS. AWS secures the hypervisor, physical hosts, and network fabric; the guest OS, installed agents, and patch baseline are the customer's. A managed service does not change this for EC2.
- RDS security group open to 0.0.0.0/0 - NorthBank for the exposure; AWS for engine patching. AWS patches the database engine and host OS under RDS, but it does not choose which source CIDRs may reach port 5432. The security group is a customer-managed virtual firewall. This is the classic 'shared' case, but the specific finding is customer-owned because the control that failed is customer-controlled.
The team's argument confuses 'who patches the engine' with 'who decides network exposure'. Those are different controls in the same service.
2. Map each finding to a CloudGuard capability NorthBank already owns, and state what that capability would not detect.
Read the worked answer
- Public S3 bucket -> CloudGuard Posture Management. A posture ruleset can evaluate bucket policy, ACL, and public-access-block settings continuously and raise a finding on drift. It would not read the settlement files or decide whether the data is cardholder data; data classification remains a customer process.
- Open RDS security group -> CloudGuard Posture Management. Rules can detect ingress from 0.0.0.0/0 to sensitive ports, including 5432, and can flag the security group as noncompliant. It would not prove whether the database was actually reached; that requires flow logs or network telemetry.
- Missing EC2 patches -> weak fit for the existing stack. Posture Management can check instance metadata and configuration, but it does not patch guests. Without a workload-protection or patch-inventory feed, NorthBank has a visibility gap. CloudGuard Network Security can reduce exploitation risk with IPS and virtual patching, but it does not remediate the missing patch. The honest answer is to add a patch-inventory data source or accept the gap explicitly.
A control that would have caught all three earlier is continuous posture evaluation with alerting, not a one-time audit.
3. Explain why 'AWS patches RDS' does not move the open-port finding to AWS, and what evidence would settle the dispute.
Read the worked answer
RDS splits controls. AWS owns the database engine patching, host hardening, and underlying infrastructure. The customer owns the security group, subnet routing, IAM access to the RDS API, database users, and data. The open port is created by a customer API call against a customer-owned security group. AWS's default configuration does not open 5432 to the internet, and AWS does not approve customer CIDR ranges.
Evidence to settle it: AWS CloudTrail events showing which principal called AuthorizeSecurityGroupIngress, the security group's owner account, and the resource policy; VPC Flow Logs showing whether connections from external addresses were accepted; and the RDS configuration showing the DB instance's associated security groups. If CloudTrail shows a role in NorthBank's account made the change, the responsibility is clear. The shared-responsibility model allocates the patching of the engine to AWS, but not the network exposure decision. Treating the two as one finding would leave the actual control unowned.