1.2 Playbooks — The Power Layer

What a playbook is

A Sentinel playbook is an Azure Logic App configured with a Sentinel trigger. Logic Apps is Azure's serverless workflow engine: you define a sequence of steps, each step calls an API or performs a data operation, and Azure handles the execution, scaling, and retry logic. For security automation, you need approximately 10% of the platform's capability. This section focuses on the 10% that matters.

A Logic App is a sequence of steps. Each step is an action from a connector. The Sentinel connector provides the trigger (when an incident is created, updated, or when an alert is created) and incident manipulation actions (add comment, change severity, change status, update incident). The Microsoft Graph connector provides identity operations: get user details, revoke sessions, list group members, check user risk level. The Defender for Endpoint connector provides endpoint operations: isolate device, run live response, collect investigation package. The Teams connector sends messages and adaptive cards. The HTTP connector calls any REST API, which means any service with an API endpoint is reachable from a playbook.

Steps execute sequentially by default. You can add parallel branches to execute multiple API calls simultaneously, conditions to implement decision logic (if user is VIP, route to approval; otherwise auto-contain), loops to iterate over entity collections (for each IP entity, query TI feed), and scopes to group steps for shared error handling. Every step produces output that subsequent steps can reference. When the Sentinel trigger fires, its output includes the full incident object: title, severity, description, entities, alerts, and custom properties. When a Graph API call completes, its output includes the user's display name, department, risk level, and authentication methods. You reference these outputs in downstream steps using the dynamic content picker or expression syntax.

The five-step pattern

Every Sentinel playbook follows the same structural pattern. The complexity varies, but the skeleton is consistent.

Step 1: trigger. The playbook fires when a Sentinel automation rule invokes it. The incident trigger provides the full incident object with all properties and entities. The trigger is configured once during playbook creation and rarely changes.

Step 2: extract entities. The incident contains entities (accounts, IPs, hosts, URLs, file hashes) in a JSON array. You parse this array to extract the specific entity types your playbook needs. An enrichment playbook extracting the compromised account uses the "Entities - Get Accounts" action from the Sentinel connector, which returns a typed array of Account entities with properties like AadUserId, UPNSuffix, and Name. A TI enrichment playbook extracting IP addresses uses "Entities - Get IPs."

Step 3: query external data. This is where the connector ecosystem matters. Call the Graph API for identity data (user risk, sign-in history, group membership, authentication methods). Call the MDE API for endpoint data (device health, installed software, vulnerability exposure). Use the HTTP action for any REST API (VirusTotal, AbuseIPDB, Shodan, or internal APIs). Use the Sentinel connector's "Run query and list results" action to execute KQL against your workspace. Each query adds a layer of context that the automation rule could not provide.

Step 4: apply conditional logic. Based on the query results, the playbook decides what to do. The decision logic maps directly to the frameworks from Module 0. If the user's risk level is High AND the IP is not on the known-safe watchlist AND the composite confidence score exceeds 95%, execute session revocation. If the user is on the VIP watchlist, route to the Teams approval gate instead. If any query failed (API timeout, permission error, rate limit), skip to the error handling path and add a comment documenting the partial enrichment.

Step 5: execute and document. Take the appropriate action: add a structured enrichment comment, send a Teams adaptive card, revoke sessions, isolate a device, create a ServiceNow ticket. The final action is always an incident comment documenting what the playbook did, what data it found, and what action it took. This comment creates the audit trail that Section 0.9 governance requires.

Consumption vs Standard plans

Logic Apps offers two hosting plans, and the choice affects cost, performance, and architecture.

Consumption is the default for Sentinel playbooks. Each Logic App is a single workflow. Azure handles all infrastructure. You pay per action execution, approximately $0.000025 per action at current pricing. A playbook with 15 actions running 500 times per day costs roughly $5.60 per month. This is the correct choice for most SOCs. The entire NE automation stack (10 playbooks averaging 20 actions each, all running on every incident) costs approximately $75 per month in Logic App execution fees. The ROI calculation is simple: if automation saves five minutes per alert across 500 daily alerts, that is 41 hours of recovered analyst time per day, costing $75 per month in platform fees.

Standard runs on a dedicated App Service plan with a fixed monthly cost regardless of execution volume. Standard supports multiple workflows within a single Logic App, private endpoints for VNet connectivity, and stateful or stateless workflow types. Standard is appropriate when the SOC requires VNet integration (playbooks accessing on-premises resources through private endpoints) or when execution volume is high enough that the fixed monthly cost is lower than the per-action Consumption cost. For NE's scale (500 incidents per day), Consumption is more cost-effective. Standard becomes attractive above approximately 10,000 daily executions with complex playbooks.

The Sentinel Automation page in the Defender portal lists both plan types. You can mix Consumption and Standard playbooks in the same automation stack. The automation rule that triggers the playbook does not care which plan the Logic App uses.

Dynamic content and expressions

Every Logic App step produces output. Subsequent steps reference that output using dynamic content, which the designer displays as a picker of available fields from previous steps. When the Sentinel incident trigger fires, the dynamic content picker shows fields like Incident Title, Incident Severity, Incident Description, and Entities. When a "Get user" action from the Graph connector completes, the picker adds the user's Display Name, Job Title, Department, and Risk Level.

For complex data manipulation, Logic Apps uses expressions. The syntax is verbose but learnable. The expression @{triggerBody()?['object']?['properties']?['severity']} extracts the severity value from the trigger payload. @{body('Get_user')?['riskLevel']} extracts the risk level from a Graph API response. @{length(body('Entities_-_Get_Accounts'))} counts the number of account entities in the incident.

Three expressions you will use in every playbook: triggerBody() returns the complete trigger payload (the incident object). body('action_name') returns the output of a specific action. items('For_each') returns the current item when iterating over a collection. The designer provides autocomplete for expressions, and this course shows the exact expression for each playbook step. You do not need to memorize the syntax.

{
  "definition": {
    "triggers": {
      "Microsoft_Sentinel_incident": {
        "type": "ApiConnectionWebhook",
        "inputs": {
          "host": { "connection": { "name": "@parameters('$connections')['azuresentinel']['connectionId']" } },
          "body": { "callback": "@{listCallbackUrl()}" },
          "path": "/incident-creation"
        }
      }
    },
    "actions": {
      "Entities_-_Get_Accounts": {
        "type": "ApiConnection",
        "inputs": {
          "body": "@triggerBody()?['object']?['properties']?['relatedEntities']",
          "host": { "connection": { "name": "@parameters('$connections')['azuresentinel']['connectionId']" } },
          "method": "post",
          "path": "/entities/account"
        }
      },
      "For_each_Account": {
        "type": "Foreach",
        "foreach": "@body('Entities_-_Get_Accounts')?['Accounts']",
        "actions": {
          "HTTP_Get_User_Risk": {
            "type": "Http",
            "inputs": {
              "method": "GET",
              "uri": "https://graph.microsoft.com/v1.0/identityProtection/riskyUsers/@{items('For_each_Account')?['AadUserId']}",
              "authentication": { "type": "ManagedServiceIdentity", "audience": "https://graph.microsoft.com" }
            }
          }
        }
      }
    }
  }
}

This ARM template excerpt shows the trigger, entity extraction, and a Graph API call using managed identity authentication. The triggerBody() expression passes the incident's entity array to the extraction action. The items('For_each_Account') expression accesses the current account entity during iteration. The authentication block specifies managed identity with the Graph API audience, which means no stored credentials.

Sequential vs parallel execution

Steps execute sequentially by default: Step 1 completes, Step 2 starts. For a playbook that queries five data sources (SigninLogs via KQL, user risk via Graph, device compliance via Graph, IP reputation via HTTP, and alert history via KQL), sequential execution takes the sum of all query times. If each query averages 3 seconds, sequential execution takes 15 seconds.

Parallel branches execute multiple actions simultaneously. The playbook waits until all branches complete before proceeding. The same five queries in parallel take the duration of the slowest query: 3 seconds instead of 15. Logic Apps supports parallel branches natively. In the designer, add multiple actions from the same step to create a parallel branch. After all branches complete, use a Compose action to aggregate results.

The trade-off is debuggability. Sequential execution produces a linear run history where each step's input and output is visible in order. Parallel execution produces a branched run history where failures in one branch can be harder to trace. The practical recommendation: build your first version of any playbook sequentially. Validate that every step works correctly. Then refactor to parallel execution once the logic is proven. The refactoring takes five minutes in the designer. The debugging time saved during initial development is worth the temporary performance cost.

Authentication models

Playbooks authenticate to external services using three models. The model you choose determines the security posture and operational fragility of every playbook.

Managed identity is the recommended model for all Microsoft services. The Logic App authenticates using its Entra ID identity. No credentials are stored, no secrets require rotation, no risk of credential theft exists. Used for Microsoft Graph, Sentinel API, MDE API, and Azure Resource Manager. The managed identity must be granted the specific API permissions it needs (User.Read.All for user risk queries, SecurityIncident.ReadWrite.All for incident updates, Machine.Isolate for endpoint isolation). Every playbook in this course uses managed identity for Microsoft API calls.

API key is required for third-party services that do not support Entra ID authentication. The key is stored in the Logic App configuration or, preferably, in Azure Key Vault with access policies limiting which Logic Apps can read which keys. Used for VirusTotal, AbuseIPDB, Shodan, and similar threat intelligence services. API keys must be rotated on a schedule (quarterly for most services).

OAuth 2.0 connection is used for SaaS connectors like Teams, ServiceNow, and Outlook. The connection is created during connector setup and is tied to the user account that authorized it. If that user leaves the organization and their account is disabled, the OAuth connection breaks and every playbook using it stops working. The mitigation is to create OAuth connections using a dedicated service account with a descriptive name like svc-sentinel-automation@northgateeng.com, not a personal analyst account.

The Sentinel service account

Sentinel uses its own service account to run playbooks triggered by automation rules. This service account needs the Microsoft Sentinel Automation Contributor role on the resource group where the playbook resides. Without this role, the automation rule can fire but the playbook will not execute, and the failure is not always visible in the automation rule's run history. Section 1.5 covers the full permission model, but the critical point is this: the Sentinel service account's permissions are separate from your managed identity's permissions. The service account needs permission to invoke the playbook. The managed identity needs permission to call the APIs inside the playbook. Both must be configured for the playbook to function.