Cloud Incident Response Playbooks & Runbooks

How Cloud IR Differs from Traditional IR

Traditional incident response relied on physical or network access to affected systems — imaging hard drives, capturing memory, pulling network captures. Cloud IR operates differently:

Dimension	Traditional IR	Cloud IR
Evidence	Disk images, memory captures, pcaps	CloudTrail API logs, VPC Flow Logs, GuardDuty findings, Lambda traces
Preservation	Bit-for-bit disk image (dd, FTK Imager)	EBS snapshot, S3 export of logs to immutable bucket
Containment	Network isolation at switch port	Security Group isolation, IAM credential revocation
Ephemeral resources	N/A	Lambda, Fargate tasks, spot instances disappear — acquire before termination
Timeline	Events reconstructed from file system metadata	CloudTrail timestamps are UTC, millisecond precision
Multi-tenancy	Not applicable	Shared hypervisor — provider may have relevant logs
Provider cooperation	Not applicable	AWS Support / AWS Security must be engaged for provider-side logs

The NIST SP 800-61 Cloud IR Lifecycle

NIST SP 800-61 defines four IR phases. Their cloud implementation:

Phase 1: Preparation

• All CloudTrail trails enabled (management + data events, all regions)
• VPC Flow Logs enabled on all VPCs
• GuardDuty active in all accounts and regions
• IR playbooks written and approved before an incident occurs
• Emergency contact list: AWS Support Enterprise (or Business) tier, Legal, DPO, HR
• Quarantine Security Group pre-created (allows outbound to logging services only, blocks all inbound)
• Forensic S3 bucket with Object Lock pre-created for evidence

Phase 2: Detection and Analysis

Detection sources in priority order:

Source	What It Detects
GuardDuty	Threat intelligence matches, ML anomalies
CloudTrail + SIEM rules	Specific high-risk API call sequences
AWS Health Dashboard	Service disruptions that may indicate attack
Customer complaint	User reports inability to access account
Billing alert	Unexplained cost spike

Initial triage questions:

1. Which account(s) and region(s) are affected?
2. Which IAM principal is involved (human, service, role)?
3. What resources were accessed or modified?
4. Is the incident still ongoing (active threat actor) or historical?
5. Is any data potentially exfiltrated?

Phase 3: Containment, Eradication, and Recovery

Containment steps (immediate):

Step	AWS Action
Revoke compromised IAM credentials	aws iam delete-access-key, aws iam update-login-profile --no-password-reset-required --password ...
Isolate compromised EC2 instance	Apply pre-built quarantine Security Group; remove from auto-scaling group
Disable compromised IAM user	aws iam update-user --user-name victim --no-permissions → detach all policies
Block attacker IP at WAF	Add IP set rule in AWS WAF (if attack is HTTP-based)
Preserve evidence	Take EBS snapshot; export relevant CloudTrail period to S3 forensic bucket
Disable malicious Lambda	Update function concurrency to 0 (--reserved-concurrent-executions 0)

Eradication: Identify root cause (the vulnerability or misconfiguration that allowed initial access), close it, and verify that the threat actor has no remaining persistence (new IAM users, Lambda functions, rogue Security Groups, EventBridge rules pointing to attacker-controlled endpoints).

Recovery: Restore from known-good snapshot or redeploy from version-controlled IaC. Verify integrity of restored system before returning to production.

Phase 4: Post-Incident Activity

CERT-In Reporting (mandatory for significant incidents): Report to CERT-In within 6 hours of detection at incidents@cert-in.org.in and via the CERT-In reporting portal. Required information:

• Organisation name, contact details
• Affected systems and estimated number of users impacted
• Nature of incident (data breach, ransomware, DDoS, etc.)
• Actions taken
• Current status

Internal post-mortem:

• Timeline of events (UTC timestamps from CloudTrail)
• Root cause analysis (5 Whys)
• Control gaps identified
• Remediation actions with owners and deadlines
• CERT-In submission reference number

Core Playbooks

Playbook 1: Compromised IAM Access Key

Trigger: GuardDuty finding UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS
         or internal detection of key used from unexpected location

1. Identify: Which key? Which user/role? What actions were taken?
   → aws cloudtrail lookup-events --lookup-attributes Key=AccessKeyId,Value=AKIAXXXXXXXX

2. Contain: Immediately deactivate key
   → aws iam update-access-key --access-key-id AKIAXXXXXXXX --status Inactive

3. Assess damage: What was accessed/changed with this key?
   → CloudTrail query: filter by accessKeyId for past 90 days

4. Eradicate: Delete key; review role permissions; check for new IAM users created
   → aws iam delete-access-key --access-key-id AKIAXXXXXXXX

5. Recover: Rotate all keys in the same role; review similar roles for over-privilege

6. Report: File CERT-In report if significant data accessed

Playbook 2: Public S3 Bucket Discovered

Trigger: Macie finding or GuardDuty finding Policy:S3/BucketPublicAccessGranted

1. Assess: What data is in the bucket? Is it actually sensitive?
   → aws s3api list-objects --bucket BUCKET-NAME (check file names/types)
   → Check Macie sensitive data findings for this bucket

2. Contain: Enable Block Public Access immediately
   → aws s3api put-public-access-block --bucket BUCKET-NAME \
     --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,...

3. Investigate: How long was it public? Who accessed it?
   → S3 server access logs (if enabled)
   → CloudTrail for PutBucketAcl/PutBucketPolicy events

4. Report: If sensitive data was accessible and may have been accessed → CERT-In + DPDP breach notification