Module Summary

What you learned in this module

Module 1 built the two automation mechanisms that power every Sentinel workflow in this course: automation rules for lightweight, immediate triage actions, and Logic App playbooks for multi-step enrichment and response workflows.

Automation rules (Section 1.1). The three triggers (incident created, incident updated, alert created), execution ordering by number, sequential evaluation where each rule sees the previous rule's changes, and the zero-cost property. Automation rules handle severity overrides, owner assignment, tagging, and playbook triggering without consuming Logic App resources.

Playbooks (Section 1.2). Logic App architecture for Sentinel automation: the Consumption plan pricing model, the three playbook triggers (incident, alert, entity), the distinction between built-in actions and connector actions, and why Consumption plan almost always makes more sense than Standard for security automation. The incident trigger as the recommended default for enrichment and response workflows.

Your first automation rule (Section 1.3). Building the AiTM triage acceleration rule: compound conditions with AND and OR logic, action configuration for severity change and tag assignment, execution order positioning, and the Defender portal navigation for automation rule management after workspace onboarding.

Your first playbook (Section 1.4). End-to-end Logic App construction: the Create Playbook wizard, incident trigger with managed identity, entity extraction with Get Accounts, KQL query for sign-in history using dynamic expressions, Graph API call for user risk, formatted incident comment assembly, and Teams channel notification. The complete enrichment pipeline from raw incident to investigation-ready package.

Authentication and permissions (Section 1.5). System-assigned managed identity as the default authentication for all Microsoft API calls. The permission model: Microsoft Sentinel Responder for incident write actions, Log Analytics Reader for KQL queries, and specific Graph API permissions (IdentityRiskyUser.Read.All, User.Read.All) for enrichment data. Key Vault for third-party API keys. The separation of read-only enrichment playbooks from read-write containment playbooks to enforce least privilege at the workflow level.

Entity extraction and mapping (Section 1.6). How Sentinel maps entities from analytics rule KQL output columns to typed entity objects. The Get Accounts, Get IPs, and Get Hosts connector actions. The empty array problem when an analytics rule does not map the entity type the playbook expects. Defensive patterns: array length checks before For Each loops, graceful degradation when entity extraction returns no results, and incident comments that document missing entities for manual follow-up.

Error handling and retry logic (Section 1.7). Scope-based error grouping that isolates failures to individual enrichment sources without terminating the entire playbook. Exponential backoff retry policies with action-specific tuning: three retries for non-critical enrichment, five retries for containment actions. The partial enrichment model where the playbook documents what succeeded and what failed rather than producing all-or-nothing results.

Testing automation safely (Section 1.8). The staging workspace methodology: deploy and test in a non-production workspace before promoting to production. Test incident creation, run history inspection for action-level debugging, and the validation checklist that confirms trigger firing, entity extraction, enrichment query results, comment formatting, and notification delivery before production deployment.

Monitoring automation health (Section 1.9). The three-layer monitoring model: SentinelHealth for native Sentinel connector status, AzureDiagnostics for Logic App run-level and action-level telemetry, and SecurityIncident for output validation. The health monitoring KQL query that detects playbook failures within one hour. The distinction between complete failures (run-level "Failed"), partial failures (run succeeded but individual actions failed), and silent no-entity runs that produce no error but also no enrichment.

Cost management (Section 1.10). Consumption plan pricing mechanics: built-in actions at $0.000025, connector actions at $0.000125, 4,000 free built-in actions per month. The cost estimation method using action counts per run multiplied by incident volume. External API costs (VirusTotal, Shodan, GreyNoise) that typically exceed Logic App costs by an order of magnitude. Runaway cost scenarios from unbounded For Each loops and misconfigured triggers. Azure Cost Management alerts as the safety net.

Guided walkthrough (Section 1.11). Six integration exercises that tested the automation chain end-to-end: rule execution order interaction, permission boundary validation, entity extraction across incident types, monitoring coverage for partial failures, full-chain validation with a realistic incident, and cost projection from actual diagnostic data.

What's next