3.3 Automation & SOAR
Key Takeaways
- Automation rules orchestrate incident handling natively in Sentinel (assign owner, change status/severity, add tags, run playbooks) and execute in priority order
- Playbooks are Azure Logic Apps built on the Microsoft Sentinel connector with incident, alert, or entity triggers
- A playbook that calls Microsoft Sentinel or Defender XDR needs permissions: a managed identity or the Microsoft Sentinel connection plus the Microsoft Sentinel Automation Contributor and Responder roles on the resource group
- Sentinel must be granted permission to run playbooks (Microsoft Sentinel Automation Contributor on the playbook's resource group) before an automation rule can invoke them
- Automation rules also support a no-incident path that runs on alert creation, and can suppress noisy incidents by auto-closing them
SOAR in Microsoft Sentinel
Security orchestration, automation, and response (SOAR) in Microsoft Sentinel is delivered through two layered components:
- Automation rules — native, no-code orchestration that runs when an incident or alert is created or updated. They set ownership, status, severity, and tags, and can chain one or more playbooks.
- Playbooks — Azure Logic Apps that perform the actual integrations and actions (isolate a device, disable a user, post to Teams, open a ticket, enrich an entity).
Think of the automation rule as the conductor and playbooks as the musicians. On SC-200, the Manage a security operations environment domain expects you to configure both and to get the permission model right — the single most common automation exam trap.
Why Two Layers
| Need | Use |
|---|---|
| Assign owner, set severity, tag, auto-close noise, run in order | Automation rule |
| Call an external system, remediate, enrich, notify with logic | Playbook (Logic App) |
| Run the same response for many rules consistently | Automation rule that calls a shared playbook |
Automation Rules
Automation rules centralize incident handling so logic is not duplicated across every analytics rule.
Triggers
- When incident is created
- When incident is updated (for example, status changed, owner changed, tags added)
- When alert is created (alert-trigger automation rules — useful when no incident is generated)
Conditions and Actions
- Conditions filter on properties such as severity, title, tactics, analytics rule name, or entity values.
- Actions can: change status, change severity, assign an owner, add/remove tags, and run a playbook.
- Rules run in a configurable order; lower order numbers execute first, which lets you, for example, tag and triage before invoking a heavy response playbook.
- An expiration can be set so a temporary rule auto-disables on a date.
Common Patterns
- Noise suppression — condition on a known benign title, action set status to Closed with classification Benign Positive. This is the recommended way to suppress noisy incidents, not deleting the analytics rule.
- Auto-assignment — route incidents to a tier-1 queue owner based on severity or product.
- Standardized enrichment — every new incident triggers an enrichment playbook before an analyst opens it.
Playbooks (Logic Apps)
A playbook is an Azure Logic App workflow that uses the Microsoft Sentinel connector. The connector trigger determines what data the playbook receives.
Playbook Trigger Types
| Trigger | Receives | Typical use |
|---|---|---|
| Incident trigger | Full incident object (alerts, entities, properties) | End-to-end incident response/orchestration |
| Alert trigger | A single alert | Per-alert action where no incident exists |
| Entity trigger | One entity (account, host, IP, URL, file) | Manual, targeted action from the investigation graph |
Logic App Plan
Playbooks run on either the Consumption Logic Apps plan (per-execution billing, classic) or the Standard plan (single-tenant, predictable cost, multiple workflows per app). SC-200 may ask which plan suits high-volume or isolated workloads — Standard for predictable/high volume and VNet integration; Consumption for simple, low-volume automation.
Where Playbooks Are Invoked
- Automatically by an automation rule.
- Manually from an incident or alert in the Sentinel portal.
- Manually against an entity from the investigation experience (entity-trigger playbooks).
Permissions and Managed Identity
This is the highest-value SC-200 automation topic. A playbook fails silently if authorization is wrong.
Playbook Identity
A Logic App authenticates to Microsoft Sentinel and other services using either:
- A managed identity (recommended) — the Logic App's system-assigned identity is granted the needed Azure roles.
- An API connection authorized with a user or service principal (legacy pattern).
To let a playbook act on Sentinel data (update incidents, add comments), grant its managed identity the Microsoft Sentinel Responder (or Contributor) role on the Sentinel workspace's resource group. Actions against other products (for example, Microsoft Defender XDR Isolate machine, Entra ID Disable user) require the corresponding Graph or product permissions on that identity.
Letting Sentinel Run the Playbook
Separately, Microsoft Sentinel itself must be permitted to trigger the playbook. You grant the Microsoft Sentinel Automation Contributor role to the Sentinel service on the resource group that contains the playbook. Without this, an automation rule lists the playbook but cannot run it.
Permission checklist:
1. Playbook managed identity -> Microsoft Sentinel Responder/Contributor (act on incidents)
2. Playbook managed identity -> product/Graph roles (e.g., disable user, isolate device)
3. Microsoft Sentinel service -> Microsoft Sentinel Automation Contributor on the playbook's resource group (allow trigger)
Notification and Response Orchestration
Real SOC automation chains triage, response, and communication. SC-200 scenarios describe an outcome and ask you to assemble the right components.
Notification Orchestration
- A playbook posts an adaptive card to a Microsoft Teams channel or sends email with incident details and action buttons (for example, Confirm compromised / Dismiss).
- Responses on the card feed back to the playbook to drive conditional next steps.
- For paging, the playbook calls an on-call tool (for example, an ITSM or paging webhook).
Response Orchestration
- Containment: playbook calls Defender XDR to isolate a device or Entra ID to disable/require sign-in for a user.
- Enrichment: playbook queries threat intelligence or geo-IP and writes findings back as an incident comment.
- Ticketing: playbook opens and later closes a ServiceNow/Jira ticket synced to incident status.
Designing the Right Solution
| Requirement | Correct design |
|---|---|
| Same triage steps for many analytics rules | One automation rule with broad conditions calling a shared playbook |
| Auto-close known benign incidents | Automation rule: condition on title/tactic, action close as Benign Positive |
| Disable user + notify SOC on high-severity identity incident | Automation rule (severity = High) runs a playbook with managed identity having Entra and Teams permissions |
| Analyst-initiated targeted action on one IP | Entity-trigger playbook run manually from the investigation graph |
An automation rule lists a playbook in its action dropdown, but the playbook never executes when incidents are created. Permissions on the playbook's managed identity are correct. What is the most likely missing configuration?
A SOC wants known benign 'Scheduled task created' incidents from one analytics rule to be closed automatically without deleting the detection. What is the best approach?
Which playbook trigger type should an analyst use to run a targeted enrichment action manually against a single suspicious IP address from the Sentinel investigation graph?