SA0.7 Sentinel Automation Architecture

Automation rules — the lightweight layer

Automation rules are Sentinel’s simplest automation mechanism. They require no code, no Logic Apps, and no Azure resource deployment. You configure them in the Sentinel portal under Automation → Automation rules.

An automation rule triggers when an incident is created or updated. It evaluates conditions (incident severity, analytics rule name, entity type, tags) and executes actions (change severity, change status, assign owner, add tags, run a playbook, close the incident).

When to use automation rules:

Triage acceleration — change severity on specific alert types. The “AiTM credential phishing” detection fires at Medium severity by default. An automation rule changes it to High because you have determined that AiTM is always High in your environment. This takes 2 minutes to configure and improves triage prioritisation permanently.

Assignment routing — assign incidents to the correct analyst or queue based on the analytics rule or severity. All identity-related incidents go to the identity specialist. All endpoint incidents go to the endpoint team. All Critical severity incidents go to the IR lead.

False positive auto-close — close incidents that match known false positive patterns. The impossible travel alert for the CEO who flies London-to-New-York weekly fires every Monday. An automation rule with conditions (analytics rule = “Impossible Travel” AND entity contains “ceo@northgateeng.com”) auto-closes the incident and adds a tag “auto-closed-known-travel.”

Playbook trigger — the most important use. Automation rules are the mechanism that triggers playbooks. You do not trigger a Logic App directly from an analytics rule (that is the less-common analytic rule action). Instead: the analytics rule creates an alert → the alert becomes an incident → the automation rule fires on incident creation → the automation rule triggers the playbook. This indirect path gives you incident-level context (grouped alerts, mapped entities) in the playbook.

Execution order matters. Automation rules execute in the order you define. If Rule 1 changes severity to High and Rule 2 triggers a playbook only on High severity incidents, Rule 1 must execute before Rule 2. Sentinel processes rules sequentially by their configured order number.

Playbooks — the power layer

Playbooks are Logic Apps — Azure’s serverless workflow automation service. They provide the multi-step, conditional, integration-capable automation that automation rules cannot.

A playbook can: call any REST API (Microsoft Graph, Defender API, VirusTotal, AbuseIPDB, ServiceNow, Slack, PagerDuty), execute conditional logic (if user is VIP then route to approval, else auto-contain), loop over entities (for each IP in the incident, query TI feeds), run parallel branches (query 3 TI feeds simultaneously), wait for human input (Teams adaptive card with Approve/Reject), and process complex data transformations.

Authentication. Playbooks authenticate to APIs using managed identities (recommended for Microsoft APIs), service principals (for third-party APIs that support OAuth), or API keys stored in Azure Key Vault. SA1 covers authentication in detail. The key principle: never store credentials in the playbook definition. Always use managed identity or Key Vault references.

The Sentinel connector. Every Sentinel playbook uses the “Microsoft Sentinel” connector as its trigger. The trigger type determines when the playbook fires: “When a Microsoft Sentinel incident is created” (most common) or “When a Microsoft Sentinel incident is updated.” The trigger provides the incident object with all its properties: severity, title, description, entities (accounts, IPs, hosts, URLs, files), alerts, and custom properties.

Entity extraction. The incident trigger provides entities — but extracting them reliably is the first challenge every playbook builder encounters. The entities are in a JSON array, and the array structure varies by alert type. Some alerts map a single Account entity. Some map an Account and an IP. Some map nothing (poorly configured analytics rules). Your playbook must handle all cases: extract the entity if it exists, skip gracefully if it does not. SA1 covers entity extraction patterns in detail.

Cost. Logic Apps charge per action execution. A playbook with 10 actions that fires 500 times per day executes 5,000 actions per day = 150,000 per month. At the Consumption plan rate of approximately £0.000025 per action, that is £3.75/month. Playbook costs are negligible for most SOCs. The exception is playbooks that query expensive external APIs (VirusTotal Premium, Shodan) — those APIs have their own pricing independent of Logic Apps.

Analytic rule actions — the fast path

The third mechanism is the least used but has a specific, important use case. An analytics rule can trigger a playbook directly when an alert is created — before the alert is grouped into an incident.

The advantage is speed. An automation rule fires after the incident is created, which can be seconds to minutes after the alert. An analytic rule action fires on the alert itself — as fast as the analytics rule schedule allows (minimum 5 minutes for scheduled rules, near-real-time for NRT rules).

The disadvantage is context. The alert-triggered playbook receives a single alert, not a grouped incident. It does not have the entity mapping that incident grouping provides. It cannot access other alerts in the same incident because the incident does not exist yet.

When to use analytic rule actions: Time-critical enrichment where you want data before the incident is created. For example: a near-real-time rule detects a potential AiTM. The analytic rule action fires a lightweight playbook that immediately queries the user’s current session status (are they actively signed in from the suspicious IP right now?). By the time the incident is created and an analyst opens it, the session status — which changes every minute — has already been captured.

When NOT to use analytic rule actions: For anything that requires incident-level context. Enrichment that needs to iterate over multiple entities (IPs, users, devices) requires the incident entity mapping. Containment actions that need to correlate alerts require the incident grouping. Notification playbooks that need severity-based routing require the incident severity, which may have been changed by an automation rule.

Choosing the right mechanism

Use this decision tree for every automation requirement:

Does the automation need conditional logic, API calls, or multi-step workflows? If yes → Playbook (Logic App), triggered by an automation rule on incident creation.

Is it a simple action (change severity, assign owner, add tag, close incident) with no external integration? If yes → Automation rule alone. No playbook needed.

Does it need to fire immediately on alert creation, before incident grouping, for time-critical evidence capture? If yes → Analytic rule action triggering a lightweight playbook.

In practice, 80% of your automation will be playbooks triggered by automation rules. 15% will be automation rules alone (severity changes, assignment routing, FP auto-close). 5% will be analytic rule actions for time-critical scenarios.