CCSP study materials
CCSP study resources

Containment After a Cross-Account Pivot

CCSP · Put your knowledge to work in context.

All case studies

Containment After a Cross-Account Pivot

Meridian Health's cloud estate grew from 30 to 210 accounts after two acquisitions. During a red-team engagement, the team obtained domain admin in the acquired subsidiary's flat VPC in 40 minutes, then reached the core imaging archive because a full-mesh peering connection was left in place 'temporarily' 14 months ago. The subsidiary still runs a shared svc-ops IAM user with s3:* and ec2:* whose access key the red team found baked into a public container image. Clinical imaging must stay available 24/7, and a change freeze for the EHR begins in ten days. The CISO wants a first-72-hours plan that does not trigger a clinical outage.

1. Sequence the first 72 hours. Justify the order, especially the choice between containing identity and containing network.

Read the worked answer

Contain identity first, network second - and preserve evidence before either destroys it.

  1. Snapshot and export (0–4h). Snapshot compromised volumes and export CloudTrail and VPC flow logs to a forensics account the compromised principals cannot write to. Key rotation does not destroy logs, but instance termination and log-group retention settings do.
  2. Kill the credential (0–4h, parallel). Disable the svc-ops access key and attach an explicit deny. Rationale: the attacker's persistence is portable identity, not a network position. Severing the peering while the key stays valid leaves an attacker who can act from any source IP, including from the core account if that key is reused anywhere. Identity containment is the only single action that reduces the whole attack surface at once.
  3. Sever the peering (4–12h). Remove the full-mesh link. Confirm with the imaging team that nothing clinical calls into the subsidiary before cutting - the dependency direction is subsidiary-to-core - then monitor.
  4. Isolate hosts (12–24h). Apply a quarantine security group or detach from the network rather than terminating. No power-off before snapshots.
  5. Hunt (24–72h). Search all 210 accounts for the same key, the same image digest, and any persistence the attacker created: new roles, cross-account trust policies, added SSH keys, modified logging.

The EHR freeze must not delay step 3. The freeze governs EHR workloads; request a named exception for a security containment change on the subsidiary path and record who approved it.

2. How do you retire the shared svc-ops key without causing an outage, given it is embedded in images and its full consumer set is unknown?

Read the worked answer

Treat it as a migration, not a revocation.

  1. Enumerate consumers. Query 90 days of CloudTrail for that principal: source IPs, user agents, and calling services identify which pipelines, instances, and humans use it. A 7-day window will miss monthly and quarterly jobs - that is why 90 days.
  2. Replace with identity, not another key. Per-workload IAM roles (instance profiles, workload identity for pods, OIDC federation for CI) scoped to the buckets and actions the trail actually shows. Static keys in images must not exist after this.
  3. Canary and watch. Roll out one workload at a time, then watch for AccessDenied from that principal across at least one full business cycle. Two weeks of silence is not completeness evidence if a quarterly job exists - check the calendar, not just the logs.
  4. Disable first, delete later. A disabled key is reversible in minutes if you missed a consumer; a deleted one is not. Delete after 30 days of clean logs.
  5. The public image: assume every credential ever baked into it is compromised regardless of this key. Rebuild from clean layers, add secret scanning and image scanning as pipeline gates, and request takedown of the public copy while assuming it has already been pulled.

3. What segmentation model do you replace the full mesh with, and how do you justify the spend to a cost-focused CFO?

Read the worked answer

Hub-and-spoke with centralized inspection and no transitive routing, plus identity-based service-to-service access.

Why patching the one link is insufficient: keep the mesh and the next misconfiguration anywhere in 210 accounts is again one hop from the imaging archive. The CFO question is not 'what does segmentation cost' but 'what did 40 minutes of blast radius cost' - lead with the red-team number and the imaging archive's regulatory exposure.

Design:

  • One VPC per account attached to a transit hub. Spokes cannot route to each other directly; inter-spoke traffic traverses an inspection VPC. The peering set becomes small, auditable, and enforceable by policy.
  • East-west application traffic goes over private endpoints or mesh workload identity, not network adjacency. The imaging archive should accept calls from an authenticated workload identity, never from any IP in a peered CIDR.
  • Centralized egress with logging, plus policy-as-code that denies peering attachments created outside the approved module - otherwise the 'temporary' link returns in a quarter.

Phase it: cut the subsidiary link now as a break-fix, then build the hub. A funded two-phase plan beats a six-month target architecture during which the mesh is still live.