Cloud Incident Response — Detection, Containment & Recovery Guide
In this tutorial, you'll learn about Cloud Incident Response. We cover key concepts, practical examples, and best practices to help you understand and apply this topic effectively.
Cloud Incident Response adapts traditional IR phases to the cloud by automating detection with GuardDuty and Security Hub, isolating compromised resources through IAM and networking controls, and recovering from Immutable Infrastructure backups.
What You Will Learn
How to build an Incident Response plan for cloud environments, automate detection and containment, collect forensic evidence, and recover without data loss.
Why It Matters
Cloud attacks move fast. A compromised IAM key can be used to exfiltrate data within minutes. Manual Incident Response cannot keep up. Automated detection and containment are essential.
Real-World Use
DodaTech's Incident Response playbook detects a compromised Lambda function through GuardDuty. The playbook automatically revokes the function's IAM role, isolates the VPC, and creates a forensic snapshot of the function's environment for analysis.
Incident Response Lifecycle
flowchart LR Prepare[Prepare\nIR Plan & Playbooks] --> Detect["Detect\nGuardDuty / Security Hub"] Detect --> Contain[Contain\nResource Isolation] Contain --> Investigate[Investigate\nForensic Analysis] Investigate --> Eradicate[Eradicate\nRemove Threat] Eradicate --> Recover[Recover\nRestore from Backup] Recover --> Learn[Learn\nPost-Incident Review] Learn --> Prepare style Detect fill:#f90,color:#fff style Contain fill:#e00,color:#fff
Detection Phase
Cloud-native detection services analyze logs, network traffic, and API calls for suspicious behavior.
# AWS: Create a CloudWatch event rule for critical GuardDuty findings
aws events put-rule \
--name guardduty-critical-alert \
--event-pattern '{
"source": ["aws.guardduty"],
"detail": {"severity": [{"numeric": [">=", 7}]}
}'
# Route to SNS topic for paging
aws events put-targets \
--rule guardduty-critical-alert \
--targets '[
{"Id": "1", "Arn": "arn:aws:sns:us-east-1:123456789012:incident-response"}
]'
# Azure: Create a security alert automation
az sentinel alert-rule create \
--resource-group prod-rg \
--workspace-name prod-sentinel \
--rule-name "Critical Alert to Teams" \
--display-name "Post critical alerts to Teams" \
--query-frequency PT5M \
--query 'SecurityAlert | where AlertSeverity == "High"'
Containment Phase
Contain the incident by isolating the compromised resource without destroying evidence.
# AWS: Automatically isolate an EC2 instance by modifying security group
aws ec2 modify-instance-attribute \
--instance-id i-1234567890abcdef \
--groups sg-isolate sg-forensic
# AWS: Revoke compromised IAM credentials
aws iam create-access-key \
--user-name compromised-user
# Wait for key creation
aws iam update-access-key \
--user-name compromised-user \
--access-key-id AKIAIOSFODNN7EXAMPLE \
--status Inactive
# Azure: Remove a compromised VM from the load balancer
az network nic update \
--resource-group prod-rg \
--name prod-nic \
--lb-name prod-lb \
--remove backendAddressPools 0
Forensic Investigation
Preserve volatile data before recovery. Take snapshots of EBS volumes, export CloudTrail logs, and capture memory.
# AWS: Create forensic snapshot of EBS volume
aws ec2 create-snapshot \
--volume-id vol-1234567890abcdef \
--description "Forensic snapshot - incident IR-2026-001"
# Export CloudTrail logs for the incident timeframe
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=ResourceName,AttributeValue=i-1234567890abcdef \
--start-time 2026-06-24T09:00:00Z \
--end-time 2026-06-24T11:00:00Z \
--query 'Events[*].[EventTime,EventName,Username,SourceIPAddress]' \
--output table
# Output:
# ------------------------------------------------------------------
# | EventTime | EventName | Username | SourceIP |
# | 2026-06-24T09:15:00 | ConsoleLogin | admin | 203.0.113.5|
# | 2026-06-24T09:20:00 | CreateAccessKey | admin | 203.0.113.5|
# ------------------------------------------------------------------
Recovery Phase
Restore from immutable backups. Rebuild compromised resources from trusted images rather than patching in place.
# AWS: Restore an EC2 instance from an AMI
aws ec2 run-instances \
--image-id ami-0abcdef1234567890 \
--instance-type t3.medium \
--security-group-ids sg-restored \
--subnet-id subnet-restored \
--tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=restored-web}]'
Common Mistakes
- No pre-defined IR playbook: Without a playbook, teams waste critical minutes deciding what to do. Write and test playbooks for common scenarios.
- Destroying evidence during containment: Rebooting an instance or deleting resources destroys forensic data. Isolate before investigating.
- Forgetting to revoke credentials: Revoking the compromised user's credentials must happen immediately. Automate this in your IR playbook.
- No backup of critical data: Without backups, recovery from ransomware or data deletion is impossible. Enable automated backups with cross-region Replication.
- Not testing the IR plan: A plan that has never been tested will fail in a real incident. Run tabletop exercises and simulate attacks quarterly.
Practice Questions
- What are the five phases of Incident Response in the cloud?
- How can CloudWatch Events automate incident containment?
- Why is forensic snapshot creation important before recovery?
- How does the shared responsibility model affect Incident Response?
- What is the purpose of a pre-defined IR playbook?
Challenge
Design an automated Incident Response workflow for a compromised IAM user. The workflow should detect the compromise through GuardDuty or Security Hub, automatically disable the user's access keys, isolate any resources the user created in the last hour, capture a CloudTrail log snapshot for the incident timeframe, and notify the security team through Slack. Write the CloudWatch Events rule and Lambda function outline.
FAQ
Built by the developers of DodaTech
Doda Browser, DodaZIP & Durga Antivirus Pro