Incident Response in Azure: KQL, Playbooks & SOAR

Incident Response Lifecycle in Azure

1. Detection: Analytics rule fires, Alert created, Incident created (if grouping is on)
2. Triage: Analyst reviews incident, assigns severity, sets status (New to Active)
3. Investigation: KQL queries in the workspace, entity timeline, threat intelligence correlation
4. Containment: Isolate VM, block user, revoke tokens: manual or automated
5. Remediation: Root cause fix: patch, reconfiguration, policy update
6. Documentation: Close incident, record findings, update detection rules

KQL Basics for the Exam

The exam expects you to read and understand KQL, not write complex queries from scratch. Key operators:

// Find failed sign-ins from a specific IP
SigninLogs
| where ResultType != 0
| where IPAddress == "1.2.3.4"
| summarize count() by UserPrincipalName, bin(TimeGenerated, 1h)
| order by count_ desc

Key KQL operators to recognise: where, project, summarize, join, extend, render, order by, bin().

Logic App Playbooks

Playbooks are Logic Apps triggered by Sentinel alerts or incidents. Common patterns:

• On high-severity alert: post to Teams channel plus page on-call
• On user account alert: disable Entra ID account, force sign-out of all sessions
• On malicious IP alert: add IP to Named Location block list in Conditional Access

Exam tip: Playbooks require a Logic App plus an automation rule in Sentinel to connect them. The automation rule specifies trigger conditions.

Automation Rules

Automation rules run before playbooks and can:

• Auto-assign incidents to an analyst
• Auto-tag incidents with labels
• Auto-close known-false-positive patterns
• Trigger a playbook

Order of execution: Automation rules run in priority order (lowest number first) and can be stopped mid-chain.