This chapter covers cloud incident response in AWS and Azure, two of the most widely adopted cloud platforms. Understanding how to detect, contain, and remediate security incidents in these environments is critical for the CS0-003 exam, as cloud-related questions constitute approximately 15-20% of the Incident Response domain. You will learn the specific tools, automation mechanisms, and best practices unique to each platform, along with practical step-by-step procedures and real-world scenarios.
Jump to a section
Imagine a massive skyscraper with 100 floors, each floor representing a cloud service (AWS or Azure). The building has a central security team (the Cloud Incident Response Team) and a fire alarm system (CloudWatch, Azure Monitor). When a fire starts on floor 42 (a security incident), the following happens: Step 1: Detection – Smoke detectors (CloudTrail, Azure Activity Log) sense the fire and trigger the alarm. The alarm sends a notification to the security team's mobile devices (SNS, Azure Alerts). Step 2: Isolation – The security team remotely locks all doors on floor 42 (Security Groups, NSGs) and cuts off the floor's power (shuts down EC2 instances, VMs). They also isolate the floor from the rest of the building by sealing off stairwells (Network ACLs, Azure Firewall). Step 3: Investigation – The team reviews security camera footage (log analysis) from the past hour to see who entered floor 42 (IAM users, roles). They also examine the fire's origin (compromised resource) and spread (lateral movement). Step 4: Eradication – The team extinguishes the fire (removes malware, patches vulnerability) and ensures no embers remain (scans for persistence mechanisms). Step 5: Recovery – They restore power and unlock doors, but only after confirming the floor is safe (restoring from snapshots, AMIs). They also install new smoke detectors (updated monitoring rules). Step 6: Post-Incident Review – The team documents the incident and updates the building's fire response plan (runbooks, playbooks). The key difference from a traditional building is that the skyscraper can be divided into multiple identical floors (regions), and the security team can replicate the entire floor from a backup (AMI) in another region. They can also use a pre-built fire suppression system (AWS Shield, Azure DDoS Protection) to automatically contain the fire. The building's layout (VPC, Virtual Network) is software-defined, allowing instant reconfiguration. This analogy mirrors cloud incident response's automation, scalability, and need for precise logging and isolation.
What is Cloud Incident Response?
Cloud incident response (IR) is the process of identifying, containing, and recovering from security incidents in cloud environments like AWS and Azure. Unlike on-premises environments where you control the physical infrastructure, cloud IR requires leveraging native tools, APIs, and shared responsibility models. The CS0-003 exam tests your ability to apply IR principles using cloud-specific services.
Why Cloud IR is Different
In the cloud, the provider (AWS/Azure) manages the hypervisor, network fabric, and often the operating system (in PaaS/SaaS). The customer is responsible for data, access management, and application security. This shared responsibility model affects every step of IR. Key differences include: - Ephemeral resources: Instances can be terminated and recreated quickly, which can destroy evidence. - Automation: Cloud environments enable automated response via scripts (AWS Lambda, Azure Functions) and orchestration. - Scalability: Incidents can involve thousands of resources across regions. - Logging: Logs are generated and stored differently (CloudTrail, VPC Flow Logs; Azure Activity Log, NSG Flow Logs).
AWS Incident Response Tools
#### AWS CloudTrail - Purpose: Records API calls for governance, compliance, and audit. - Details: Logs every action taken via AWS Management Console, SDKs, CLI, and services. Includes identity, source IP, request parameters, and response elements. - Default: Enabled for all regions. Logs are stored in S3 buckets. Trail can be multi-region or single-region. - Exam Tip: CloudTrail is the first place to look for unauthorized API calls. It is essential for forensic analysis.
#### Amazon GuardDuty - Purpose: Intelligent threat detection using machine learning and integrated threat intelligence. - Sources: Analyzes CloudTrail events, VPC Flow Logs, and DNS logs. - Findings: Categorizes threats (e.g., Recon, UnauthorizedAccess, Persistence). Each finding includes severity, resource, and recommended action. - Automation: Can trigger Lambda functions via EventBridge for automated response.
#### AWS Config - Purpose: Evaluates resource configurations against desired policies. - Rules: Managed or custom rules to detect non-compliant resources (e.g., S3 bucket public access). - Remediation: Can automatically remediate using SSM Automation documents.
#### AWS Shield and WAF - Shield: DDoS protection. Shield Standard is free; Shield Advanced provides enhanced detection and cost protection. - WAF: Web application firewall that filters HTTP/S requests based on rules (IP sets, SQL injection, XSS).
#### AWS Lambda - Purpose: Serverless compute for automating response actions. - Use Cases: Isolate EC2 instances by modifying security groups, revoke IAM credentials, or snapshot volumes for forensics.
#### AWS Systems Manager (SSM) - Purpose: Manage EC2 instances at scale. Includes Run Command, Automation, and Session Manager. - Forensics: Use SSM to collect memory dumps, disk images, and logs without needing SSH keys.
Azure Incident Response Tools
#### Azure Monitor and Log Analytics - Purpose: Collect and analyze telemetry from Azure resources. - Log Analytics Workspace: Central repository for logs. Queries are written in Kusto Query Language (KQL). - Diagnostic Settings: Enable logging for specific resources (e.g., NSG flow logs, VM diagnostics).
#### Azure Security Center (now Microsoft Defender for Cloud) - Purpose: Unified security management and threat protection. - Findings: Security alerts based on analytics and threat intelligence. Includes severity, affected resources, and remediation steps. - Automation: Can trigger Logic Apps or Azure Functions via Azure Monitor alerts.
#### Azure Sentinel - Purpose: Cloud-native SIEM and SOAR. - Data Connectors: Ingest logs from Azure services, Microsoft 365, and third-party sources. - Analytics Rules: Custom or built-in rules to detect threats. - Playbooks: Automated response workflows using Logic Apps.
#### Azure Network Security Groups (NSGs) and Azure Firewall - NSGs: Stateful packet filtering at the subnet or NIC level. Can be used to isolate compromised VMs. - Azure Firewall: Managed, cloud-native firewall with threat intelligence-based filtering.
#### Azure Automation and Runbooks - Purpose: Automate management tasks using PowerShell or Python runbooks. - Use Cases: Shut down VMs, remove public IPs, or apply NSG rules.
Incident Response Phases in Cloud
#### 1. Preparation - AWS: Set up CloudTrail, GuardDuty, AWS Config, and enable VPC Flow Logs. Create IAM roles for incident response with least privilege. Use AWS Organizations for multi-account management. - Azure: Enable diagnostic settings, deploy Microsoft Defender for Cloud, and configure Azure Sentinel. Use Azure Policy to enforce compliance. - Both: Develop runbooks for common scenarios (e.g., compromised EC2, ransomware in blob storage). Test regularly.
#### 2. Detection and Analysis - AWS: GuardDuty generates findings. CloudTrail logs show API calls. VPC Flow Logs reveal network traffic patterns. Use Athena to query CloudTrail logs in S3. - Azure: Microsoft Defender for Cloud generates security alerts. Azure Activity Log tracks management operations. NSG flow logs show traffic. Use KQL in Log Analytics for advanced queries. - Common: Both platforms support integration with third-party SIEMs via Event Hubs (Azure) or Kinesis (AWS).
#### 3. Containment - AWS:
Modify security groups to block traffic to/from compromised instances.
Use Network ACLs to block entire subnets.
Remove IAM roles from compromised EC2 instances.
Use AWS Shield Advanced to mitigate DDoS.
Azure:
Apply NSG rules to deny traffic.
Use Azure Firewall to block outbound traffic.
Deallocate VMs to stop them.
Revoke RBAC roles.
Automation: Both platforms support automated containment via Lambda (AWS) or Logic Apps (Azure).
#### 4. Eradication - AWS: Terminate compromised EC2 instances, delete malicious S3 objects, revoke compromised IAM keys, and apply patches. - Azure: Delete compromised VMs, restore blobs to clean versions, rotate storage account keys, and apply updates. - Persistence: Check for backdoor users, Lambda functions, or automation accounts.
#### 5. Recovery - AWS: Restore EC2 from AMI snapshots, restore RDS from automated backups, or fail over to a different region using Route 53. - Azure: Restore VMs from Azure Backup, restore SQL databases, or use Azure Site Recovery for failover. - Testing: Validate that the restored environment is clean and that security controls are intact.
#### 6. Post-Incident Review - AWS: Analyze CloudTrail logs and GuardDuty findings to determine root cause. Update AWS Config rules and GuardDuty threat lists. - Azure: Review Sentinel incidents, update analytics rules, and improve playbooks. - Both: Document lessons learned and update runbooks.
Key Numbers and Defaults
CloudTrail: Default retention of 90 days for events in the management console, but S3 buckets can store indefinitely.
GuardDuty: 30-day free trial; pricing based on volume of CloudTrail, VPC Flow Logs, and DNS logs processed.
Azure Sentinel: Pricing based on data ingestion (GB/day). Free tier available for first 31 days.
NSG Flow Logs: Enabled per NSG; logs are written to a storage account or Log Analytics. Retention can be set up to 365 days.
VPC Flow Logs: Can be published to CloudWatch Logs or S3. Maximum aggregation interval is 10 minutes.
Automation and Orchestration
AWS: Use EventBridge to trigger Lambda based on GuardDuty findings or CloudWatch alarms. Example: When GuardDuty detects a crypto-mining instance, Lambda automatically adds a deny rule to the security group.
Azure: Use Azure Monitor alerts to trigger Logic Apps. Example: When Microsoft Defender for Cloud detects a VM with suspicious outbound traffic, Logic App runs a runbook to isolate the VM.
Playbooks: Pre-built or custom workflows. In Azure Sentinel, playbooks can automate investigation and remediation.
Forensics in the Cloud
AWS:
Create snapshots of EBS volumes for offline analysis.
Use SSM to collect memory dumps.
Preserve EC2 instance state by stopping (not terminating).
Azure:
Export VM disks as VHD files.
Use Azure Disk Encryption to ensure data is encrypted at rest.
Capture memory dumps via Azure Serial Console or PowerShell.
Shared Responsibility Considerations
AWS: Customer is responsible for data classification, IAM, and OS-level security. AWS handles physical security, hypervisor, and network infrastructure.
Azure: Similar model. Customer manages identity, data, and application security.
Implication: In an incident, you cannot access the hypervisor or physical network. You must rely on provided logs and tools.
Exam Tips
Know the difference between CloudTrail (API logging) and Config (configuration compliance).
Understand that GuardDuty uses machine learning and threat intelligence; it does not replace CloudTrail.
For Azure, remember that Azure Sentinel is the SIEM, while Microsoft Defender for Cloud is the security posture management tool.
Automated response is a key advantage of cloud IR; be familiar with Lambda and Logic Apps.
The shared responsibility model means you cannot perform network forensics at the hypervisor level.
Command Examples
#### AWS CLI Examples
# List CloudTrail events for the last hour
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventSource,AttributeValue=ec2.amazonaws.com --start-time $(date -u -d '1 hour ago' '+%Y-%m-%dT%H:%M:%SZ')
# Describe security group rules
describe-security-group-rules --group-id sg-12345678
# Revoke IAM user credentials
aws iam update-access-key --access-key-id AKIAIOSFODNN7EXAMPLE --status Inactive --user-name Bob#### Azure CLI Examples
# List Azure activity log entries
ez monitor activity-log list --start-time 2023-01-01T00:00:00Z --end-time 2023-01-02T00:00:00Z
# Show NSG rules
ez network nsg show --name myNsg --resource-group myResourceGroup --query "securityRules"
# Stop a VM
ez vm stop --name myVM --resource-group myResourceGroupKey Differences Between AWS and Azure
Logging: AWS uses CloudTrail for API logs; Azure uses Activity Log. Both have flow logs (VPC Flow Logs vs. NSG Flow Logs).
Threat Detection: AWS GuardDuty vs. Azure Microsoft Defender for Cloud (formerly Azure Security Center).
SIEM: AWS has no native SIEM; third-party or use Athena. Azure has Sentinel.
Automation: AWS Lambda vs. Azure Logic Apps or Azure Automation.
Forensics: AWS SSM vs. Azure Serial Console.
Integration with Other Services
AWS: GuardDuty integrates with Shield, WAF, and Lambda. CloudTrail integrates with CloudWatch and S3.
Azure: Microsoft Defender for Cloud integrates with Sentinel, Logic Apps, and Azure Policy.
Both: Can send logs to third-party SIEMs (Splunk, QRadar).
Common Pitfalls
Insufficient logging: Not enabling CloudTrail or diagnostic settings for all resources.
Over-reliance on automation: Automated response can cause denial of service if not properly tested.
Ignoring shared responsibility: Trying to perform actions that require provider access (e.g., hypervisor forensics).
Not preserving evidence: Terminating instances before taking snapshots.
Summary
Cloud incident response in AWS and Azure requires a deep understanding of native tools, automation, and the shared responsibility model. The CS0-003 exam tests your ability to apply these concepts in scenario-based questions. Focus on the specific services, their purposes, and how they integrate to form a complete IR workflow.
Enable Comprehensive Logging
Before an incident occurs, ensure all relevant logs are enabled. In AWS, activate CloudTrail for all regions and enable VPC Flow Logs for all VPCs. In Azure, enable diagnostic settings for all resources and send logs to a Log Analytics workspace. Also enable NSG flow logs. Set up alerting for key events (e.g., root account login, creation of new IAM users). This step is proactive and falls under the Preparation phase. Without these logs, detection and forensics become nearly impossible.
Detect and Validate the Incident
Use threat detection services like GuardDuty (AWS) or Microsoft Defender for Cloud (Azure) to identify potential incidents. When an alert fires, validate it by reviewing related logs. For example, if GuardDuty detects 'UnauthorizedAccess:EC2/SSHBruteForce', check CloudTrail for failed SSH login attempts and VPC Flow Logs for source IPs. In Azure, a Defender alert for 'RDP brute force' should be cross-referenced with NSG flow logs. Validation prevents false positives from wasting resources.
Contain the Affected Resources
Isolate compromised resources to prevent lateral movement. In AWS, modify the security group associated with the affected EC2 instance to deny all inbound and outbound traffic. Alternatively, apply a network ACL to the subnet. In Azure, add a deny rule to the NSG or use Azure Firewall to block traffic. For IAM-related incidents, disable access keys or remove roles. Automation via Lambda (AWS) or Logic Apps (Azure) can speed this step. Document the containment actions for later review.
Collect Forensic Evidence
Preserve evidence before remediation. In AWS, take an EBS snapshot of the compromised instance's volumes. Use SSM to collect memory dumps and system logs. Do not terminate the instance yet. In Azure, export the VM's disk as a VHD file and capture memory via Serial Console. Store all evidence in a secure, isolated location (e.g., a separate S3 bucket with restricted access). Timestamp all actions and maintain a chain of custody.
Eradicate the Threat
Remove the root cause of the incident. In AWS, terminate compromised EC2 instances, delete malicious S3 objects, revoke compromised IAM keys, and apply patches. In Azure, delete compromised VMs, restore blobs to clean versions, rotate storage account keys, and apply updates. Scan for persistence mechanisms such as scheduled tasks, Lambda functions, or automation accounts. Use AWS Config or Azure Policy to ensure compliance after cleanup.
Recovery and Post-Incident Review
Restore services from clean backups. In AWS, launch new EC2 instances from recent AMIs, restore RDS from snapshots, or fail over to another region. In Azure, restore VMs from Azure Backup, restore SQL databases, or use Azure Site Recovery. After recovery, conduct a post-incident review to identify gaps in detection, containment, or recovery. Update runbooks, IAM policies, and monitoring rules. Document lessons learned and share with the team.
Enterprise Scenario 1: Compromised EC2 Instance Used for Crypto Mining
A large e-commerce company running thousands of EC2 instances in AWS receives a GuardDuty finding 'CryptoCurrency:EC2/BitcoinTool.B!DNS'. Investigation reveals an instance in the production VPC has been mining cryptocurrency. The incident response team immediately isolates the instance by modifying its security group to deny all traffic and takes an EBS snapshot for forensics. They then terminate the instance and launch a replacement from a clean AMI. The root cause is traced to an unpatched web application vulnerability. The team updates the WAF rules and implements a patch management policy using AWS Systems Manager Patch Manager. They also enable GuardDuty to automatically trigger Lambda to isolate instances with similar findings in the future. This scenario highlights the importance of automated containment and forensic preservation. Common misconfiguration: not enabling VPC Flow Logs, which would have shown the outbound connections to known mining pools.
Enterprise Scenario 2: Ransomware Attack on Azure Blob Storage
A healthcare organization stores patient data in Azure Blob Storage. Microsoft Defender for Cloud alerts that blob containers have been modified with '.encrypted' extensions. The incident response team immediately enables soft delete on the storage account (if not already enabled) and restores the blobs from a previous version. They isolate the storage account by removing public access and rotating the account keys. Investigation reveals that a compromised application service principal had excessive permissions (Storage Blob Data Contributor). The team revokes the service principal's access and implements Azure Policy to enforce least privilege. They also enable advanced threat protection for Azure Storage and configure alerts for unusual access patterns. This scenario demonstrates the need for proper IAM controls and backup strategies. Common mistake: relying solely on backups without testing restoration.
Enterprise Scenario 3: DDoS Attack on an Azure Web App
A media streaming service using Azure App Service experiences a DDoS attack. Azure DDoS Protection Standard automatically mitigates the attack at the network layer. However, the application layer is still overwhelmed. The team uses Azure WAF to block malicious requests based on rate limiting and IP reputation. They also scale out the App Service Plan to handle the load. After the attack, they analyze the traffic patterns using Azure Monitor and update the WAF rules. This scenario emphasizes the importance of layered defenses and auto-scaling. Common pitfall: not enabling DDoS Protection Standard, which leaves the application vulnerable to volumetric attacks.
CS0-003 Exam Focus: Cloud Incident Response
This topic is tested under Objective 3.2: 'Given a scenario, implement incident response procedures in cloud environments.' Expect scenario-based questions where you must choose the correct tools and steps for AWS or Azure. Key areas:
Detection Tools: Know that GuardDuty (AWS) and Microsoft Defender for Cloud (Azure) are the primary threat detection services. Beware of distractors like 'AWS Inspector' (vulnerability assessment) or 'Azure Policy' (compliance).
Containment Methods: For a compromised EC2, the correct action is modifying the security group (not terminating the instance immediately). For Azure VMs, apply NSG deny rules.
Forensic Preservation: Always take snapshots before termination. In AWS, use EBS snapshots; in Azure, export VHD. SSM (AWS) and Serial Console (Azure) can capture memory.
Automation: Lambda (AWS) and Logic Apps (Azure) are the correct automation services. EventBridge (AWS) and Azure Monitor Alerts trigger them.
Logging: CloudTrail for API logs, VPC Flow Logs for network traffic. In Azure, Activity Log for management, NSG Flow Logs for network.
Shared Responsibility: You cannot access hypervisor logs. Rely on provided tools.
Common Wrong Answers and Why
Choosing 'AWS Config' for detection: Config is for configuration compliance, not threat detection. Candidates confuse it with GuardDuty.
Terminating an instance first: This destroys evidence. The correct step is isolate and snapshot.
Using 'Azure Policy' for containment: Policy enforces rules but doesn't block traffic. Use NSGs or Azure Firewall.
Selecting 'CloudWatch' for API logs: CloudWatch is for metrics and logs, not API activity. CloudTrail is correct.
Numbers and Terms That Appear on Exam
CloudTrail: 90-day retention by default, but can be stored indefinitely in S3.
GuardDuty: 30-day free trial.
NSG Flow Logs: Retention up to 365 days.
VPC Flow Logs: Aggregation interval 10 minutes max.
Azure Sentinel: Pricing per GB ingested.
Shared Responsibility Model: Customer = data, IAM, OS; Provider = hypervisor, network, physical.
Edge Cases
Ephemeral resources: Containers (ECS, AKS) may not have persistent storage. Use logging to stdout and centralized logging.
Multi-region incidents: Use AWS Organizations and Azure Management Groups for centralized logging.
Serverless: Lambda functions generate CloudWatch logs; use GuardDuty for detection.
How to Eliminate Wrong Answers
If the question mentions 'API activity', the answer is CloudTrail (AWS) or Activity Log (Azure).
If it mentions 'threat detection using ML', it's GuardDuty or Microsoft Defender for Cloud.
If it asks for 'automated response', look for Lambda or Logic Apps.
If it asks for 'network traffic analysis', it's VPC Flow Logs or NSG Flow Logs.
Always consider the shared responsibility model: if the action requires provider access, it's not possible.
CloudTrail (AWS) and Activity Log (Azure) are the primary sources for API-level audit logs.
GuardDuty (AWS) and Microsoft Defender for Cloud (Azure) provide ML-based threat detection.
Containment in the cloud involves modifying security groups (AWS) or NSGs (Azure) to isolate resources.
Always preserve forensic evidence (snapshots, memory dumps) before terminating or deleting resources.
Automated response can be implemented using Lambda (AWS) or Logic Apps (Azure).
The shared responsibility model prevents customers from accessing hypervisor-level data.
VPC Flow Logs (AWS) and NSG Flow Logs (Azure) capture network traffic metadata.
Azure Sentinel is a cloud-native SIEM; AWS does not have a native SIEM, but integrates with third-party tools.
These come up on the exam all the time. Here's how to tell them apart.
AWS Incident Response
Primary detection: GuardDuty (ML-based threat detection)
API logging: CloudTrail
Network logging: VPC Flow Logs
Automation: Lambda, EventBridge
Forensics: EBS snapshots, SSM for memory dumps
Azure Incident Response
Primary detection: Microsoft Defender for Cloud
API logging: Azure Activity Log
Network logging: NSG Flow Logs
Automation: Logic Apps, Azure Automation
Forensics: Export VHD, Serial Console for memory dumps
Mistake
CloudTrail logs all network traffic.
Correct
CloudTrail logs API calls, not network traffic. For network traffic, use VPC Flow Logs.
Mistake
You should terminate a compromised EC2 instance immediately.
Correct
Terminating destroys evidence. First, isolate the instance by modifying security groups, then take a snapshot for forensics.
Mistake
Azure Security Center and Azure Sentinel are the same service.
Correct
Azure Security Center (now Microsoft Defender for Cloud) is for security posture management and threat detection. Azure Sentinel is a SIEM/SOAR that ingests logs from multiple sources, including Defender for Cloud.
Mistake
AWS GuardDuty replaces the need for CloudTrail.
Correct
GuardDuty analyzes CloudTrail logs but does not replace them. CloudTrail is still needed for detailed API auditing and compliance.
Mistake
In the cloud, you can perform hypervisor-level forensics.
Correct
The shared responsibility model means the provider manages the hypervisor. You cannot access it; you must rely on provided logs and tools.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The first step is to isolate the instance by modifying its security group to deny all traffic. Then, take an EBS snapshot for forensics. Do not terminate the instance immediately. After isolation and evidence collection, you can proceed with eradication and recovery.
In the cloud, you rely on native tools (CloudTrail, GuardDuty, Azure Monitor) and cannot access the hypervisor. Automation is easier using serverless functions. Resources are ephemeral, so evidence preservation must be done quickly. The shared responsibility model means you are responsible for data and IAM, while the provider handles physical security.
VPC Flow Logs capture information about IP traffic going to and from network interfaces in a VPC. They can be published to CloudWatch Logs or S3. For deeper analysis, you can use Athena to query VPC Flow Logs stored in S3.
No. Sentinel is a SIEM that ingests logs from multiple sources, including Defender for Cloud. Defender for Cloud provides security posture management and generates security alerts. Sentinel can correlate those alerts with other data. They are complementary.
By default, CloudTrail events are retained for 90 days in the AWS Management Console. However, if you store logs in an S3 bucket, you can retain them indefinitely. The S3 bucket itself has configurable lifecycle policies.
You can use Azure Monitor alerts to trigger Logic Apps or Azure Automation runbooks. For example, an alert from Microsoft Defender for Cloud can trigger a Logic App that isolates a VM by adding a deny NSG rule. Azure Sentinel also provides playbooks for automated response.
AWS Systems Manager (SSM) allows you to manage EC2 instances remotely without needing SSH keys. During incident response, you can use SSM to run commands to collect memory dumps, gather logs, or apply patches. It is also used for forensic data collection.
You've just covered Cloud Incident Response in AWS and Azure — now see how well it sticks with free CS0-003 practice questions. Full explanations included, no account needed.
Done with this chapter?