2.6. Automate Response in Microsoft Sentinel
💡 First Principle: Response work splits into two kinds. Triage housekeeping (assign the right owner, set severity, tag, add a checklist, close known noise) is simple, frequent, and benefits from central ordering. Orchestration (enrich with external data, open a ticket, disable an account, post to Teams) is multi-step and talks to other systems. Sentinel gives each kind its own tool: automation rules for the first, playbooks for the second, with automation rules usually deciding when playbooks run.
The payoff is mean time to respond. Automating the first ten minutes of every incident (owner, severity, enrichment, notification) means analysts start investigating rather than administering, and containment for well-understood scenarios happens at machine speed.
| Automation rules | Playbooks | |
|---|---|---|
| What it is | Lightweight if-then rules inside Sentinel | Azure Logic Apps workflows |
| Triggered by | Incident created, incident updated, alert created | An automation rule, or an analyst manually on an incident, alert, or entity |
| Can do | Assign owner, change status or severity, add tags, add tasks, run playbooks | Anything with a connector or API: enrich, notify, ticket, contain, update the incident |
| Ordering | Central, sequential order | Runs when called |
| Permissions | Sentinel Contributor to manage | Logic App Contributor to build; Playbook Operator to run manually; service account permission for automated runs |
| Cost | Included | Logic Apps charges apply |
⚠️ Common Misconception: "Automation rules and playbooks are interchangeable." Automation rules can't call external systems; playbooks don't provide central ordering or triage conditions. A second trap: thinking a playbook runs with the analyst's permissions. It authenticates with its own connections or managed identity, which need their own rights in each target system.