Prepared access and blast radius

Lesson 2 of 3 in Designing the Response.

Here is the single most reliable way to tell a right answer from a plausible one in this domain: during an incident you must not be inventing permissions. A question that offers "create an IAM role with the permissions the responder needs" as a response step is offering you the preparation phase disguised as a response step. The responder role exists already, deployed to every account by the organization — not created under pressure by whoever has the broadest credentials to hand.

The reason is not procedural tidiness. It is that the three things you need most in the first ten minutes all take longer than ten minutes if you start from zero: permission in the account that is burning, somewhere clean to put the evidence, and tooling that was already running when the attack started. Logging you enable after the fact has no history. A snapshot you cannot decrypt is not evidence. And a responder waiting for an access approval is a responder watching an attacker work.

Then there is the path you hope never to use. Break-glass credentials are the pre-built, highly-privileged route for the case where the normal one is gone: the identity provider is down, the federation trust is broken, or the attacker holds the credentials you would normally respond with. The design problem is that a standing path to full privilege is exactly what an attacker wants, so break-glass is defined less by its permissions than by its controls: hardware MFA held by two named people, the secret split or sealed so one person cannot use it alone, a documented approval with a stated reason, a hard time limit, an alarm on any use that goes to people other than the user, and a scheduled test so the path is known to work.

The exam’s instinct here is consistent: a break-glass credential that nobody monitors is a backdoor, and a break-glass credential that nobody has ever tested is a rumour. In AWS Organizations you also now shrink the problem rather than guard it — centralised root access lets you remove root credentials from member accounts entirely and perform the handful of genuinely root-only tasks from the management account, so there are far fewer break-glass identities to defend. The organizational mechanics live in Multi-Account Governance; what matters here is that the path is pre-built, alarmed, and rehearsed.

Pre-provisioned responder roles

One incident-response role per account, identical everywhere, deployed centrally by CloudFormation StackSets so a new account is never a gap. Trust policy names the security account only, with MFA required in the condition. Permissions are the response verbs, not administrator: read logs and findings, describe resources, create and share snapshots, modify security groups and network ACLs, attach deny policies, and revoke sessions. Keep write access to data stores out of it — a responder who can delete the logs is a responder who can be blamed for deleting the logs. Exam reflex: the right answer assumes this role exists; the wrong answer creates it.

The forensics account

A dedicated account whose only job is to hold evidence and analyse it, normally in the Security OU alongside the log archive. Properties that matter: different credentials from every workload account, its own KMS keys, an evidence bucket with Object Lock so artefacts are write-once, an isolated analysis VPC with no egress, and service control policies that stop anyone — including you — deleting its contents. Give it read-only cross-account roles into the environments it examines, never write access. One account per organization is normal; regulated organizations sometimes run one per jurisdiction so evidence never crosses a border it should not.

Security tooling deployed ahead of the incident

Detection you turn on after the attack has no history, and that is the whole argument. Organization-wide GuardDuty and Security Hub with a delegated administrator, an organization CloudTrail trail landing in the log-archive account, VPC Flow Logs on the subnets you would need to reason about, AWS Config recording so you can answer "what did this security group look like at 14:00?", and the SSM Agent installed with instances already managed — because Session Manager and Run Command are how you reach a host you have just cut off the network. Detection design is Content Domain 1; the incident-response angle is simply that it must predate the incident.

Minimizing blast radius by design

Every boundary you drew in advance is a boundary the response does not have to establish under fire. Separate accounts per environment and per workload, so a compromised principal’s reach ends at the account edge. Least-privilege roles with no wildcard trust. Short session durations, so stolen credentials expire on their own. Network segmentation into isolated subnets, so lateral movement needs a route that does not exist. Per-workload KMS keys, so one stolen key does not decrypt everything. Separate deployment pipelines, so a poisoned build does not reach every account. The exam frames this as "minimizing the blast radius" and the answer is almost always another boundary, created early.

Rehearsed access, not theoretical access

Access that has never been exercised is access you are guessing about. Quarterly, have a responder actually assume the IR role in a production account, actually share a snapshot to the forensics account, and actually open a session to an isolated host. The failures this finds are mundane and fatal: a StackSet that never reached the newest account, an SCP that denies ec2:CreateSnapshot in the Security OU, a KMS key policy missing the forensics principal, an expired MFA device. Game days are the subject of Testing the plan; the point here is that preparation includes verifying the preparation.

Interactive sorting exercise: Sort each activity into the phase it belongs to. Anything in the left bucket is work you must not be doing for the first time while an incident is live.

Key terms: Incident-response role, Forensics account, Break-glass credentials, Blast radius

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.