Incident Response

Incident Response (IR) is the structured process for handling security incidents. The NIST SP 800-61 Rev. 2 framework defines four phases: (1) Preparation, (2) Detection & Analysis, (3) Containment, Eradication & Recovery, (4) Post-Incident Activity. In practice, these are commonly broken into operational steps:

1. Detection: identify the incident through alerts, monitoring, or reports
2. Containment: limit the blast radius (isolate instances, deactivate keys, block IPs)
3. Eradication: remove the threat (delete backdoors, patch vulnerabilities, clean compromised resources)
4. Recovery: restore normal operations (deploy clean resources, validate integrity, re-enable access)
5. Lessons Learned: post-incident review, update runbooks, improve detection

What Makes IR Different on AWS

Two things change in the cloud, one in your favor and one against. In your favor: every control-plane action is an API call, so containment and evidence collection are scriptable. Deactivating a key, snapshotting a disk, or isolating an instance is one command, and CloudTrail records what the attacker did with a fidelity on-premises responders rarely get. Against you: the attacker moves at API speed too. A leaked credential can be exercised within minutes of exposure, and infrastructure the attacker creates (new users, new access keys, roles with modified trust policies, resources in Regions you never use) is your problem to find. That is why AWS incident response leans so heavily on preparation: CloudTrail delivered to durable storage, GuardDuty enabled in every Region, contact and escalation paths decided in advance, and pre-written playbooks per incident type. During credential incidents, remember that AWS may attach a quarantine deny policy (AWSCompromisedKeyQuarantine) to exposed IAM users; it limits high-risk actions but is not full containment, and AWS explicitly tells you to follow the support case rather than just detaching the policy.

How It Goes Wrong in Practice

The canonical failure is partial eradication after credential compromise. A team detects abuse of a leaked access key, deactivates that key, and declares victory. But in the window before containment, the attacker used the key to create a second access key on another user, or a new IAM user, or edited a role trust policy to allow assumption from an external account. Days or weeks later the activity resumes through the backdoor identity. Eradication for credential incidents means reviewing everything the compromised principal did in CloudTrail (filter by AccessKeyId and by Username), then hunting for persistence: new users, new keys, new roles, changed trust policies, Lambda functions or EventBridge rules created as re-entry mechanisms, and activity in unused Regions. If you cannot bound what the attacker did, you cannot claim eradication.

Practical Check: First Moves via CLI

Containment for a compromised access key, reversible and immediate:

aws iam update-access-key --access-key-id AKIAIOSFODNN7EXAMPLE --status Inactive --user-name svc-deploy

Then reconstruct the timeline of what that key did:

aws cloudtrail lookup-events --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIAIOSFODNN7EXAMPLE --start-time 2026-07-20T00:00:00Z --end-time 2026-07-27T00:00:00Z

lookup-events covers the last 90 days of management events and is rate-limited to 2 requests per second per account per Region, so for large investigations query a CloudTrail trail in S3 (via Athena) instead. Preserve evidence before destroying anything: aws ec2 create-snapshot --volume-id vol-0abc12345 --description "IR evidence" captures a disk image while the instance keeps running.

Frequently Asked Questions

What should we prepare before we ever have an incident?

Organization-wide CloudTrail delivered to a protected account, GuardDuty in all Regions with findings routed to humans via EventBridge, playbooks for the common AWS incident types (leaked keys, public S3 bucket, compromised EC2), a break-glass access path that works when SSO is down or suspect, and practice: tabletop exercises or GuardDuty sample findings to test the pipeline end to end.

Contain first or investigate first?

Contain first when active harm is ongoing (cryptomining spend, data exfiltration), but choose reversible containment that preserves evidence: deactivate keys rather than delete users, isolate instances rather than terminate them, snapshot before rebuilding. The order in the playbook exists so you do not have to decide under stress.

How does the shared responsibility model apply to IR?

AWS handles incidents affecting the cloud infrastructure itself; incidents inside your account (your credentials, your misconfigurations, your workloads) are yours to detect and respond to, using the telemetry AWS provides. AWS Support and the AWS security team assist, notably for exposed credentials and abuse reports, but they do not run your response.