Incident Response in AWS

Incident Response in AWS: A Comprehensive Guide for the AWS Security Specialty Exam

Why is Incident Response in AWS Important?

Incident response (IR) is one of the most critical domains in cloud security and forms a significant portion of the AWS Security Specialty exam. In the cloud, the speed at which resources can be provisioned, modified, or compromised is dramatically faster than in traditional environments. A misconfigured S3 bucket can expose millions of records in minutes, and a compromised IAM credential can lead to lateral movement across an entire AWS account within seconds. Having a well-defined incident response strategy ensures that organizations can detect, contain, eradicate, and recover from security incidents with minimal impact. AWS provides a rich ecosystem of native services and architectural patterns that enable automated, scalable, and repeatable incident response workflows — and understanding these is essential for both real-world security and exam success.

What is Incident Response in AWS?

Incident Response in AWS refers to the structured approach to preparing for, detecting, analyzing, containing, eradicating, and recovering from security events within an AWS environment. It follows the well-established NIST Incident Response Lifecycle, adapted for the cloud:

1. Preparation – Setting up the right tools, access, runbooks, and automation before an incident occurs.
2. Detection and Analysis – Identifying that a security event has occurred and understanding its scope and impact.
3. Containment – Limiting the blast radius of the incident to prevent further damage.
4. Eradication – Removing the root cause of the incident (e.g., deleting malware, revoking compromised credentials).
5. Recovery – Restoring systems to normal operation and validating that the threat has been eliminated.
6. Post-Incident Activity – Conducting lessons learned, updating runbooks, and improving security posture.

In the AWS Shared Responsibility Model, AWS is responsible for security of the cloud (physical infrastructure, hypervisor, managed services), while the customer is responsible for security in the cloud (data, IAM, network configurations, application security). Incident response squarely falls under the customer's responsibility.

How Does Incident Response Work in AWS?

1. Preparation Phase

Preparation is the foundation of effective incident response. Key AWS practices include:

- Enable AWS CloudTrail in all regions and all accounts, with log file validation enabled. Store logs in a centralized, secured S3 bucket with MFA Delete and versioning enabled. CloudTrail provides the API-level audit trail that is essential for forensic analysis.

- Enable Amazon GuardDuty across all accounts and regions. GuardDuty uses threat intelligence, machine learning, and anomaly detection to continuously monitor for malicious activity and unauthorized behavior.

- Enable AWS Config to continuously record resource configurations and evaluate compliance. Config Rules can detect configuration drift and non-compliant resources.

- Set up Amazon Detective for deep investigation and root cause analysis of security findings.

- Create dedicated incident response AWS accounts (forensic accounts) within your AWS Organization. These accounts are isolated and pre-configured with the tools needed for forensic investigation.

- Pre-provision IAM roles with cross-account access for incident responders. These roles should follow the principle of least privilege but have sufficient permissions to perform forensic activities (e.g., creating EBS snapshots, isolating EC2 instances).

- Develop and test runbooks using AWS Systems Manager Automation documents or AWS Step Functions. Automate common IR actions such as isolating an instance, revoking credentials, or capturing memory.

- Tag resources appropriately to enable quick identification of asset owners, criticality, and environment during an incident.

- Use AWS Organizations SCPs (Service Control Policies) to prevent deletion of critical security resources like CloudTrail logs, GuardDuty detectors, or VPC Flow Logs.

2. Detection and Analysis Phase

AWS provides multiple services for detecting security events:

- Amazon GuardDuty – Detects threats such as compromised EC2 instances (cryptocurrency mining, C&C communication), compromised IAM credentials, reconnaissance activities, and S3 bucket compromise. GuardDuty findings are categorized by severity (Low, Medium, High) and type (e.g., UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS).

- AWS Security Hub – Aggregates findings from GuardDuty, Inspector, Macie, Firewall Manager, IAM Access Analyzer, and third-party tools into a single pane of glass. Supports automated response via EventBridge integration.

- Amazon CloudWatch – Monitor metrics and logs. Set up CloudWatch Alarms for suspicious activities like unauthorized API calls, root account usage, or changes to security groups.

- AWS CloudTrail + CloudWatch Logs – Create metric filters for critical events such as: console sign-in without MFA, changes to IAM policies, disabling of CloudTrail logging, security group modifications, and NACL changes.

- Amazon Macie – Detects sensitive data (PII, financial data) in S3 buckets and alerts on policy violations or unusual data access patterns.

- VPC Flow Logs – Capture network traffic metadata for analysis. Essential for detecting unusual traffic patterns, data exfiltration, or lateral movement.

- AWS IAM Access Analyzer – Identifies resources shared with external entities and generates findings for overly permissive policies.

- Amazon EventBridge (formerly CloudWatch Events) – The central event bus that routes security findings to automated response workflows. This is the glue that connects detection to response.

3. Containment Phase

Containment strategies in AWS leverage the programmable nature of the cloud:

For compromised EC2 instances:
- Isolate the instance by replacing its security group with a restrictive "forensic" security group that denies all inbound and outbound traffic (or allows only specific forensic access). Do NOT terminate the instance — you need it for forensic analysis.
- Remove the instance from any Auto Scaling group (by detaching it) to prevent it from being terminated and replaced.
- Disable or detach the instance's IAM role to revoke temporary credentials. Note: temporary credentials from the instance metadata remain valid until they expire unless the role session is revoked.
- Create EBS snapshots of attached volumes for forensic analysis.
- Enable termination protection to prevent accidental deletion.
- Optionally capture memory using tools like LiME before isolating (if volatile data is needed).

For compromised IAM credentials:
- For IAM Users: Immediately deactivate or delete access keys. Attach an explicit deny-all IAM policy to the user. Revoke any active console sessions by setting a revoke-sessions policy. Rotate any passwords.
- For IAM Roles: Revoke active sessions by modifying the role's trust policy or using the "Revoke Sessions" feature in the IAM console (which adds an inline policy denying all actions for sessions older than a specified time). This invalidates all temporary credentials issued before that time.
- For federated users: Revoke the federation token or modify the role trust policy.

For compromised S3 buckets:
- Remove public access using S3 Block Public Access settings.
- Review and restrict bucket policies and ACLs.
- Enable or review S3 server access logging and CloudTrail data events for the bucket.
- If data has been exfiltrated, determine the scope using CloudTrail S3 data event logs and Macie findings.
- Consider using S3 Object Lock for critical data to prevent deletion or modification.

For compromised AWS accounts:
- Rotate all root and IAM credentials.
- Review and remove unauthorized IAM users, roles, and policies.
- Check for unauthorized resources (EC2 instances for crypto mining, Lambda functions, etc.) in ALL regions.
- Review CloudTrail for unauthorized API calls.
- Consider using AWS Organizations SCP to restrict the compromised account's capabilities.

4. Eradication Phase

- Remove any backdoors (unauthorized IAM users, roles, key pairs, security groups).
- Delete any malicious resources (unauthorized EC2 instances, Lambda functions, ECS tasks).
- Patch vulnerabilities that were exploited (use AWS Inspector to identify them).
- Update AMIs and launch templates to include security fixes.
- Rotate all potentially compromised secrets stored in AWS Secrets Manager or Systems Manager Parameter Store.

5. Recovery Phase

- Restore from known good backups (AMIs, EBS snapshots, S3 versioned objects, RDS snapshots).
- Deploy fresh instances from hardened, patched AMIs rather than trying to clean compromised instances.
- Gradually restore network access and monitor closely for any signs of re-compromise.
- Validate that all security controls are functioning correctly (GuardDuty, CloudTrail, Config, etc.).

6. Post-Incident Activity

- Conduct a thorough lessons-learned session.
- Update runbooks and automation based on findings.
- Improve detection rules and monitoring.
- Document the incident timeline, actions taken, and outcomes.
- Consider implementing additional preventive controls (SCPs, additional Config Rules, tighter IAM policies).

Key AWS Services for Incident Response Summary:

- CloudTrail – API audit logging (who did what, when, from where)
- GuardDuty – Threat detection (continuous monitoring)
- Security Hub – Centralized findings aggregation and compliance
- Detective – Investigation and root cause analysis
- Macie – Sensitive data discovery and protection
- CloudWatch – Monitoring, alerting, and log analysis
- EventBridge – Event-driven automation
- Systems Manager – Automation, patching, and remote management
- Lambda – Custom automated response actions
- Step Functions – Orchestration of complex IR workflows
- Config – Configuration recording and compliance
- IAM – Access control, credential management
- S3 – Log storage, evidence preservation
- KMS – Encryption of forensic artifacts
- VPC Flow Logs – Network traffic analysis

Automated Incident Response Patterns:

A common pattern tested in the exam is the automated response pipeline:

GuardDuty Finding → EventBridge Rule → Lambda Function → Remediation Action

Examples:
- GuardDuty detects UnauthorizedAccess:EC2/MaliciousIPCaller.Custom → EventBridge triggers Lambda → Lambda isolates the EC2 instance by swapping its security group and creating EBS snapshots.
- GuardDuty detects Recon:IAMUser/MaliciousIPCaller → EventBridge triggers Lambda → Lambda disables the access key and sends an SNS notification.
- Macie detects PII in an S3 bucket → EventBridge triggers Lambda → Lambda applies a restrictive bucket policy and notifies the security team.
- Config detects a non-compliant security group (open SSH to 0.0.0.0/0) → EventBridge triggers Lambda → Lambda removes the offending rule via automatic remediation.

Forensic Investigation Best Practices in AWS:

- Always work on copies of evidence, not originals. Create EBS snapshots and share them to a dedicated forensic account.
- Maintain chain of custody by using S3 with Object Lock (WORM) for storing forensic artifacts.
- Use AWS KMS to encrypt forensic snapshots and data.
- Create forensic EC2 instances in an isolated VPC to mount and analyze EBS snapshots.
- Use Amazon Athena to query CloudTrail logs stored in S3 for specific API activity during the incident window.
- Use CloudTrail Lake for advanced querying of CloudTrail events.

---

Exam Tips: Answering Questions on Incident Response in AWS

1. Never terminate a compromised EC2 instance immediately. The exam frequently tests whether you understand that forensic evidence must be preserved. The correct approach is to isolate (swap security group), snapshot (EBS volumes), and then investigate. Terminating destroys volatile data and evidence.

2. Understand the difference between revoking IAM user credentials and IAM role temporary credentials. For IAM users, you deactivate access keys and change passwords. For IAM roles, you must revoke active sessions because temporary credentials remain valid until expiration — simply removing the role from an instance does not immediately invalidate existing credentials.

3. Know the automated response pattern cold: GuardDuty → EventBridge → Lambda → Remediation. If a question asks about automating a response to a specific finding, this is almost always the correct architecture. Security Hub can also trigger EventBridge rules.

4. CloudTrail is always the answer for "who did what." If a question asks how to determine which API calls were made, by whom, and when, CloudTrail is the answer. For S3 object-level operations, remember that data events must be explicitly enabled in CloudTrail (they are not on by default).

5. Forensic accounts should be separate AWS accounts. If a question mentions performing forensic analysis, the best practice is to share EBS snapshots or copy evidence to a dedicated, isolated forensic account. This preserves the integrity of the investigation and prevents the attacker from tampering with evidence if they still have access to the compromised account.

6. Know your GuardDuty finding types. The exam may reference specific finding names. Understand the categories: Backdoor, CryptoCurrency, Trojan, UnauthorizedAccess, Recon, Exfiltration, etc. Know which findings relate to EC2, IAM, S3, EKS, and Lambda.

7. For questions about compromised AWS accounts, remember to check ALL regions. Attackers often spin up resources in regions that are not commonly monitored. Also, remember to look for unauthorized IAM users, roles, policies, and key pairs that may serve as backdoors.

8. Understand isolation strategies for different resource types. EC2 → security group swap. IAM credentials → deactivate keys / attach deny policy / revoke sessions. S3 → block public access, restrict bucket policy. Lambda → remove triggers, restrict execution role. ECS → stop tasks, restrict security groups.

9. Read questions carefully for keywords. "Automated" usually means EventBridge + Lambda. "Least operational overhead" usually means a managed service over a custom solution. "Near real-time" usually means EventBridge/Lambda vs. periodic scanning. "Forensic analysis" means preserve evidence first, investigate second.

10. Remember that prevention is different from detection and response. SCPs and IAM policies are preventive controls. GuardDuty, CloudTrail, and Config are detective controls. Lambda and Systems Manager Automation are responsive controls. The exam may test whether you can distinguish between these categories and choose the appropriate control for the scenario described.

11. AWS Config auto-remediation is a valid approach for responding to configuration drift. Config Rules can detect non-compliant resources and trigger Systems Manager Automation documents to remediate them automatically. This is an alternative to the EventBridge + Lambda pattern for configuration-related incidents.

12. For cross-account incident response, understand how to use IAM roles with cross-account trust policies, AWS Organizations, and delegated administrator features in GuardDuty and Security Hub to manage security across multiple accounts.

13. When a question mentions encrypted EBS volumes, remember that you need access to the KMS key used for encryption to create snapshots and share them with a forensic account. You may need to update the KMS key policy to grant access to the forensic account.

14. Time-based questions: If a question specifies that a response must happen within minutes, choose automated solutions (EventBridge + Lambda). If the question allows for hours, a manual review workflow with SNS notifications and human approval might be acceptable.

15. AWS Step Functions is the preferred choice when the exam describes a complex, multi-step incident response workflow that requires conditional logic, parallel execution, or human approval steps. Lambda alone is suitable for simple, single-action responses.