This chapter covers incident response in Microsoft Azure, a critical domain for the AZ-500 exam. Incident response is the structured approach to handling security breaches, and it makes up about 15-20% of the Security Operations domain. You will learn the Azure-specific tools and processes for detecting, investigating, containing, eradicating, and recovering from security incidents, including Azure Sentinel, Azure Defender, and Azure Monitor. Mastery of this topic is essential for passing the exam and for real-world cloud security operations.
Jump to a section
Think of incident response in Azure as a well-rehearsed fire drill for a large office building. The building has multiple floors (subscriptions), each with many rooms (resources). A fire alarm (Azure Security Center alert) triggers a predefined response. The fire warden (Security Operations Center - SOC) receives the alarm and immediately checks the floor plan (Azure Resource Graph) to locate the fire. They don't run into the building blindly; instead, they follow a playbook: first, they confirm the fire (verify alert), then they isolate the affected floor by closing fire doors (network security groups to block traffic), and they call the fire department (escalate to Azure Sentinel or third-party SIEM). Meanwhile, they record the time of the alarm (timestamp in logs), the floor affected (resource ID), and any witnesses (affected users). After the fire is out (incident resolved), they investigate the cause (root cause analysis) by reviewing security camera footage (Azure Monitor logs) and interviewing witnesses (user reports). Finally, they update the fire drill plan (incident response runbook) to prevent future fires. The key is that every step is automated where possible, using Azure Logic Apps to trigger responses, and the entire process is documented and tested regularly. If the fire warden deviates from the plan, the response becomes chaotic and the fire spreads (lateral movement).
What is Incident Response in Azure?
Incident response is the systematic approach to managing the aftermath of a security breach or attack. In Azure, this involves a combination of native tools and third-party integrations to detect, analyze, contain, eradicate, and recover from incidents. The goal is to minimize damage, reduce recovery time and costs, and preserve evidence for legal or compliance purposes.
The Incident Response Lifecycle
The standard incident response lifecycle consists of four phases: Preparation, Detection & Analysis, Containment, Eradication & Recovery, and Post-Incident Activity. Azure provides specific services for each phase.
Preparation: This includes setting up Azure Security Center (now Microsoft Defender for Cloud), enabling diagnostic logging, configuring Azure Sentinel, and creating incident response playbooks. Key actions: enable Azure Defender plans, configure network security groups (NSGs), and set up Azure Policy to enforce security configurations.
Detection & Analysis: Azure Security Center provides security alerts based on threat intelligence and behavioral analytics. Azure Sentinel is a cloud-native SIEM that can ingest logs from multiple sources. Azure Monitor collects metrics and logs. The SOC analyst triages alerts to determine if they represent a real incident.
Containment, Eradication & Recovery: Once an incident is confirmed, the goal is to contain it to prevent further damage. In Azure, this can involve isolating a virtual machine by applying a network security group that blocks all traffic, or using Azure Policy to disable certain resource types. Eradication involves removing the threat (e.g., patching a vulnerability, deleting malicious files). Recovery involves restoring systems from clean backups or redeploying resources.
Post-Incident Activity: After the incident is resolved, a root cause analysis is performed. Lessons learned are documented, and the incident response plan is updated. Azure Monitor and Azure Sentinel can help with forensic analysis.
Key Azure Services for Incident Response
#### Microsoft Defender for Cloud (formerly Azure Security Center)
Microsoft Defender for Cloud is the central security management tool. It continuously assesses your resources for vulnerabilities and provides security alerts. Key features:
Security Alerts: Generated based on threat intelligence, behavioral analytics, and anomaly detection. Each alert has a severity (High, Medium, Low), a description, remediation steps, and a kill chain stage.
Workflow Automation: You can define automation rules that trigger actions when alerts are generated, such as sending an email, creating a ticket in ITSM, or running a Logic App.
Integration with Azure Defender: Azure Defender provides advanced threat protection for specific workloads like VMs, SQL databases, and storage accounts. It generates additional alerts.
#### Azure Sentinel
Azure Sentinel is a cloud-native SIEM and SOAR (Security Orchestration Automated Response) solution. It collects data from across your environment, including Azure, on-premises, and other clouds. Key capabilities:
Data Connectors: Over 100 connectors to ingest logs from Microsoft services, third-party firewalls, and custom sources.
Analytics Rules: You can create custom rules to detect specific patterns of behavior. Rules can be scheduled or based on real-time streaming.
Incidents: When an analytics rule triggers, it creates an incident. Incidents can be grouped, assigned to analysts, and tracked through a lifecycle.
Playbooks: Automated response workflows built on Azure Logic Apps. Playbooks can be triggered by incidents or alerts to perform actions like blocking an IP address, isolating a VM, or resetting a password.
Threat Intelligence: Integrate with threat intelligence feeds to correlate alerts with known indicators of compromise (IOCs).
#### Azure Monitor
Azure Monitor collects metrics and logs from Azure resources. It is essential for forensic analysis. Key components:
Log Analytics Workspace: A repository for log data. You can query logs using Kusto Query Language (KQL).
Diagnostic Settings: Enable diagnostic logs for resources like VMs, NSGs, and Azure Key Vault. These logs are sent to a Log Analytics workspace, Storage account, or Event Hub.
Activity Log: Records control-plane events (e.g., create, update, delete resources). Retained for 90 days by default, but can be exported.
Incident Response Steps in Detail
#### 1. Preparation
Enable Azure Defender Plan: In Defender for Cloud, enable the enhanced security features for all supported resource types. This generates alerts for suspicious activities.
Configure Data Collection: Ensure diagnostic settings are enabled for all resources. For VMs, install the Log Analytics agent to collect security event logs.
Set Up Azure Sentinel: Create an Azure Sentinel workspace and connect data sources. Create analytics rules for common attack patterns (e.g., brute force, malware detection).
Create Playbooks: Develop playbooks for common incidents, such as isolating a compromised VM or blocking a malicious IP.
Define Roles and Responsibilities: Use Azure Role-Based Access Control (RBAC) to assign permissions. The Security Admin role can manage alerts, while the Contributor role can modify resources.
#### 2. Detection and Analysis
Alert Triage: When an alert is generated, the analyst reviews it in Defender for Cloud or Sentinel. They check the alert details, affected resources, and severity.
Investigation: Use Azure Sentinel's investigation graph to visualize the attack path. Query logs in Log Analytics to find related events.
Validation: Determine if the alert is a true positive or false positive. This may involve checking if the activity is expected (e.g., a legitimate admin action).
Escalation: If the incident is confirmed, escalate to the appropriate team. Use Sentinel's incident management to assign the incident.
#### 3. Containment, Eradication, and Recovery
- Containment: The immediate goal is to stop the attack from spreading. Options include: - Block IP: Use Azure Firewall or NSG to block the attacker's IP. - Isolate Resource: Apply an NSG to a VM that denies all inbound and outbound traffic except for management. - Disable Compromised Account: Use Azure AD to disable a user account. - Stop Resource: Power off a virtual machine or scale down a service.
- Eradication: Remove the threat. This could involve: - Patching: Apply security updates to vulnerable software. - Removing Malware: Use antivirus or antimalware tools. - Reimaging: Rebuild a VM from a clean image. - Revoking Credentials: Rotate keys and passwords.
Recovery: Restore services to normal operation. Use Azure Backup to restore data from backups. Ensure no backdoors remain.
#### 4. Post-Incident Activity
Root Cause Analysis: Determine how the attacker gained access. Review logs to identify the entry point.
Lessons Learned: Document what worked and what didn't. Update incident response playbooks.
Improve Detection: Tune analytics rules to reduce false positives and detect similar attacks earlier.
Compliance Reporting: Generate reports for regulatory bodies if required.
Incident Response Automation with Playbooks
Playbooks in Azure Sentinel are built on Azure Logic Apps. They can be triggered automatically by an incident or alert. Example playbook actions:
Block IP Address: Use a connector to Azure Firewall or a third-party firewall to block the IP.
Isolate VM: Apply an NSG to the VM's subnet that denies all traffic.
Send Email: Notify the SOC team via email or Teams.
Create Ticket: Create a ticket in ServiceNow or Jira.
Reset Password: Use Azure AD connector to reset a user's password.
Integration with External Tools
Azure Sentinel can integrate with third-party SIEMs like Splunk via the Common Event Format (CEF) connector. It also supports Syslog and custom logs. This allows you to maintain a hybrid incident response process.
Best Practices
Regularly Test Playbooks: Use Sentinel's incident simulation to test playbooks without triggering real alerts.
Monitor Logs Continuously: Use dashboards in Azure Monitor or Sentinel to visualize security posture.
Use Automation: Automate repetitive tasks to speed up response times.
Train Staff: Conduct tabletop exercises to practice incident response procedures.
Enable Azure Defender and Data Collection
In the Azure portal, navigate to Microsoft Defender for Cloud. Under 'Environment settings', select your subscription and enable all Azure Defender plans (e.g., Servers, SQL, Storage). This triggers advanced threat detection alerts. Next, under 'Data collection', configure the Log Analytics agent to collect security events from VMs. Choose the workspace and set the event collection level (e.g., Common or All Events). Without this, many alerts will not be generated.
Configure Azure Sentinel and Analytics Rules
Create an Azure Sentinel workspace in the same region as your resources. Connect data sources using data connectors (e.g., Azure Activity, Azure Security Center, Office 365). Then create analytics rules. For example, create a scheduled rule to detect multiple failed logins from a single IP to multiple VMs. Use KQL to query the SecurityEvent table. Set the threshold (e.g., 10 failures in 5 minutes). When the rule triggers, it creates an incident.
Triage and Investigate Alerts
When an alert appears in Defender for Cloud or Sentinel, the SOC analyst reviews it. In Sentinel, open the incident. Check the 'Entities' tab for affected resources, users, and IPs. Use the investigation graph to see connections. Query Log Analytics for related events. For example, if the alert is 'RDP brute force', query SecurityEvent for EventID 4625 (failed logon) from the source IP. Determine if it's a true positive by correlating with known admin activity.
Contain the Incident Using Automation
If the incident is confirmed, containment is critical. Use a Sentinel playbook to automatically block the attacker's IP. The playbook can call the Azure Firewall connector to add a rule that drops traffic from that IP. Alternatively, apply an NSG to the affected VM's subnet with a deny-all rule. This can be done manually or via a Logic App. Ensure the containment action is logged for audit.
Eradicate and Recover
After containment, eradicate the threat. For a compromised VM, reimage it from a known good backup. Use Azure Backup to restore the VM to a point before the compromise. If the attack involved stolen credentials, reset the password and revoke tokens. Then recover services by allowing traffic back through the NSG. Verify the system is clean by scanning with antimalware. Finally, update the incident in Sentinel with resolution notes.
Scenario 1: Ransomware Attack on a Financial Services Company
A financial services company uses Azure for its customer-facing web applications. One morning, Azure Security Center generates a high-severity alert: 'Ransomware detected on VM-Web01'. The SOC analyst in Azure Sentinel sees the incident and immediately triggers a playbook that isolates the VM by applying an NSG that denies all traffic except to the management subnet. The analyst then uses Azure Backup to restore the VM's disks from the previous night's backup. Meanwhile, they investigate the entry point: a user clicked a phishing email that installed malware. The analyst disables that user's account and resets their password. The incident is resolved in 2 hours. The company updates its playbook to include user awareness training.
Scenario 2: Data Exfiltration from a SQL Database
A healthcare organization stores patient data in Azure SQL Database. Azure Defender for SQL alerts on unusual access patterns: a sudden spike in data export queries from an IP outside the corporate network. The SOC team uses Azure Sentinel to investigate. They see that the IP is from an unknown country. They immediately use a playbook to block the IP at the Azure Firewall. Then they review the SQL audit logs to see which records were accessed. They determine that a compromised admin account was used. They revoke the account's permissions and enable Azure AD Conditional Access to require MFA for all admin logins. The incident is logged for HIPAA compliance.
Scenario 3: Compromised Storage Account
A media company uses Azure Blob Storage to store video files. Azure Defender for Storage alerts on 'Anonymous access to blob container'. The SOC analyst finds that a container was misconfigured to allow public read access. They use a playbook to immediately set the container to private. Then they check the access logs to see if any data was downloaded. No data was exfiltrated because the alert was triggered by a security researcher scanning for open buckets. The company adds an Azure Policy to prevent public access on storage accounts.
Performance Considerations: In large environments, log ingestion can be costly. Use Log Analytics workspace retention policies to manage costs. Also, playbooks that run on many incidents can cause throttling; design them to be efficient. Common misconfigurations include not enabling diagnostic logs on all resources, leading to blind spots, and not testing playbooks, causing failures during real incidents.
The AZ-500 exam tests incident response under objective 4.4: 'Configure and manage security incident response'. Key areas:
Microsoft Defender for Cloud alerts: Know the difference between security alerts and security incidents. An incident is a collection of related alerts. The exam may ask which service is used to view alerts (Defender for Cloud) vs. which is used for SIEM (Sentinel).
Azure Sentinel: Be able to identify the correct component: data connectors, analytics rules, playbooks, and incidents. The exam loves questions about playbook triggers: playbooks can be triggered from alerts or incidents. A common wrong answer is that playbooks can only be triggered manually — they can be automated.
Incident response steps: The exam may ask the correct order: Prepare, Detect, Contain, Eradicate, Recover, Post-Incident. Another wrong answer is putting 'Recover' before 'Contain'.
Automation: Know that Logic Apps are the underlying technology for playbooks. The exam may ask which service can be used to automatically block an IP in response to an alert — answer: Logic Apps via a playbook.
Logging: Understand diagnostic settings. The exam may ask where to send logs for long-term retention (Azure Storage) vs. for analytics (Log Analytics). The default retention for Activity Log is 90 days.
- Common wrong answers: - 'Azure Policy' is used for incident response — it's for governance, not response. - 'Azure Firewall' is the only way to block IPs — NSGs and Web Application Firewall (WAF) also work. - 'Azure Monitor' is a SIEM — it's a monitoring service, not a SIEM; Sentinel is the SIEM.
Edge cases: The exam may test that playbooks can be assigned to specific analytics rules. Also, that Sentinel incidents can be grouped using automation rules. Another edge: you can create custom analytics rules using KQL.
Elimination strategy: When a question asks about automated response, look for 'Logic Apps' or 'Playbook'. If it asks about long-term log storage, choose 'Azure Storage' over 'Log Analytics'. If it asks about threat intelligence, look for 'Azure Sentinel'.
Incident response in Azure follows the NIST framework: Preparation, Detection & Analysis, Containment, Eradication & Recovery, Post-Incident Activity.
Azure Sentinel is the primary SIEM and SOAR tool; playbooks are built on Azure Logic Apps.
Diagnostic settings must be enabled on all resources to collect data-plane logs for forensics.
Containment can be achieved by blocking IPs via NSG, Azure Firewall, or WAF, or by isolating resources.
The Activity Log is retained for 90 days by default; export to Storage for longer retention.
Automation rules in Sentinel can automatically assign playbooks to incidents based on conditions.
Common exam wrong answer: using Azure Policy for incident response (it's for compliance, not response).
These come up on the exam all the time. Here's how to tell them apart.
Microsoft Defender for Cloud Alerts
Single service alerts (e.g., Defender for Servers).
No built-in incident grouping; each alert is standalone.
Limited automation (workflow automation via Logic Apps).
No SIEM capabilities; cannot ingest third-party logs.
Best for quick threat detection and remediation.
Azure Sentinel Incidents
Aggregates alerts from multiple sources (Azure, on-prem, third-party).
Groups related alerts into incidents for investigation.
Rich automation with playbooks and automation rules.
Full SIEM: log ingestion, custom analytics, threat intelligence.
Best for centralized incident management and advanced analysis.
Mistake
Azure Security Center is a SIEM.
Correct
Azure Security Center (now Microsoft Defender for Cloud) is a CSPM (Cloud Security Posture Management) and workload protection platform. It provides alerts but is not a full SIEM. Azure Sentinel is the cloud-native SIEM that can ingest logs from multiple sources and provides advanced analytics and incident management.
Mistake
Incident response playbooks can only be triggered manually.
Correct
Playbooks in Azure Sentinel can be triggered automatically by incidents or alerts. They can also be triggered manually from the incident blade. Automation rules allow you to assign playbooks to run when certain conditions are met, enabling automated response.
Mistake
The Activity Log is sufficient for forensic investigation.
Correct
The Activity Log only records control-plane events (e.g., creating a VM). For data-plane events (e.g., reading a blob), you need resource-level diagnostic logs. Also, Activity Log is retained for 90 days by default; for longer retention, export to a Storage account or Log Analytics.
Mistake
Containment always means shutting down the resource.
Correct
Containment can be achieved without downtime by isolating the resource via NSGs or disabling accounts. Shutting down may destroy evidence. The preferred method is to deny network traffic while preserving the resource state for forensics.
Mistake
Azure Sentinel incidents are automatically created from all alerts.
Correct
By default, alerts from Defender for Cloud are not automatically created as incidents in Sentinel. You must configure the 'Microsoft Security Incident Creation' analytics rule or use a data connector to sync alerts. Incidents are only created when an analytics rule triggers.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Playbooks in Azure Sentinel are built using Azure Logic Apps. In the Azure portal, go to Azure Sentinel > Automation > Create > Playbook. Choose a trigger: 'When a Microsoft Sentinel incident is created' or 'When a Microsoft Sentinel alert is created'. Then add actions like 'Block IP' or 'Send email'. Once created, assign the playbook to an automation rule or run it manually from an incident.
A security alert is a single notification of a potential threat, generated by services like Defender for Cloud. A security incident is a collection of related alerts that together indicate a likely attack. Azure Sentinel groups alerts into incidents for easier investigation. For example, multiple brute force alerts from the same IP to different VMs become one incident.
No, Azure Policy is for enforcing compliance and governance rules (e.g., requiring encryption). It is not designed for incident response. For automated response, use Azure Sentinel playbooks or Defender for Cloud's workflow automation.
By default, Azure Activity Logs are retained for 90 days. To keep logs longer, you can export them to a Storage account (for long-term archival) or to a Log Analytics workspace (for analytics). You can also set a retention policy in Log Analytics up to 730 days or use Azure Data Explorer for longer.
The best way is to apply a network security group (NSG) to the VM's subnet that denies all inbound and outbound traffic except for management (e.g., Azure Bastion). This preserves the VM for forensics. Alternatively, you can use Azure Firewall to block traffic or use Azure Policy to deny changes. Do not delete the VM until forensic analysis is complete.
Azure Sentinel can ingest logs from third-party SIEMs using the Common Event Format (CEF) connector. You can also use Syslog or custom log connectors. For outbound integration, Sentinel can forward incidents to other SIEMs via webhooks or Logic Apps.
Azure Monitor collects metrics and logs from Azure resources. It provides the raw data for forensic analysis. You can query logs using KQL to find evidence of an attack. Azure Monitor also powers dashboards and alerts. However, it is not a SIEM; for advanced correlation and incident management, use Azure Sentinel.
You've just covered Incident Response in Azure — now see how well it sticks with free AZ-500 practice questions. Full explanations included, no account needed.
Done with this chapter?