SA0: The Automation Problem

0.1 What is SOC automation

Security automation is the discipline of replacing manual, repetitive SOC workflows with programmatic execution. Every SOC reaches the same breaking point: alert volume grows, headcount does not, and the analysts who can detect threats spend their time running the same enrichment queries, sending the same notification emails, and executing the same containment steps for every alert. The work is critical. It is also entirely automatable.

The discipline is not about Logic Apps or playbooks or any specific tooling. It is about the judgment that determines when automated action is safe, what confidence level justifies containment without human approval, and how to prevent automation from causing more damage than the incident it responds to. A playbook that disables a VIP account based on a medium-confidence alert is not automation. It is an automated mistake with organizational consequences.

This module establishes the framework before the tooling. Twelve sections build the decision criteria that every playbook in the remaining modules applies: the three-tier classification (enrichment, collection, containment) that maps every automation action to a risk category, the composite confidence threshold model that gates containment decisions, the blast radius assessment that prevents high-impact actions on critical assets, the governance pillars that keep automation operational over years, and the maturity model that measures where your SOC is today and where the course takes you.

The framework exists because the alternative is what NE has now: 847 automated Defender actions that nobody reviews, four Sentinel automation rules with no documentation (one of which is actively harmful), one dead playbook that failed six months ago and nobody noticed, and zero enrichment, evidence collection, notification, or containment automation built by the SOC team.

0.2 What you will learn

Twelve sections, each building a specific component of the automation decision framework.

Section 0.1: Why Most SOCs Don't Automate. The five barriers that prevent SOC teams from building automation programs, why IBM's 2025 data shows $1.9 million in savings from automation, and the capacity arithmetic that proves automation is not optional at NE's alert volume.

Section 0.2: The Automation Spectrum. The five automation levels from fully manual through autonomous response, the left-to-right dependency chain that prevents skipping levels, and the action classification framework that places every automation on the spectrum before deployment.

Section 0.3: The Three Automation Tiers. Tier classification by blast radius: Tier 1 (enrichment, zero blast radius, always safe), Tier 2 (collection and notification, low blast radius), and Tier 3 (containment, high blast radius, requires confidence thresholds, VIP checks, and rollback playbooks). Managed identity permission model for each tier.

Section 0.4: The Confidence Threshold Problem. The distinction between alert severity and detection confidence. The composite additive scoring model, signal weight calibration, and the threshold-by-action-type framework: 95% for session revocation, 97% for account disablement, 98% for device isolation.

Section 0.5: The Blast Radius Assessment. Four blast radius categories (standard user, VIP, server, service account) and dynamic assessment via Sentinel watchlists. The combined confidence-plus-blast-radius gate that prevents high-impact containment on critical assets.

Section 0.6: NE's Automation Landscape. Current-state audit of NE: 847 unreviewed Defender actions, four automation rules, one dead playbook, zero enrichment or containment automation. The 90-day target architecture.

Section 0.7: Sentinel Automation Architecture. The two-layer model: automation rules as orchestration, playbooks as Logic Apps execution. Service account permissions, the Enhanced Alert Trigger, and the decision framework for choosing rules-only vs playbook-backed automation.

Section 0.8: Defender XDR Automation Architecture. Attack disruption's three-minute containment model, AIR's four automation levels, custom detection rules with auto-actions and NRT capability, and the coordination framework that prevents conflicts between Sentinel and Defender XDR.

Section 0.9: The Automation Governance Framework. Four pillars: version control, testing, monitoring, and documentation. The deploy gate, tiered change management, monthly review cycle, and the retirement process.

Section 0.10: The Automation Maturity Model. Five maturity levels, eight assessment dimensions, scoring methodology. NE's Level 1 baseline and the progression path that maps each level transition to specific course modules.

Section 0.11: Guided Walkthrough. Apply all frameworks to NE: score the maturity assessment, identify automation candidates, classify blast radius for critical systems, and produce the 90-day roadmap.

0.3 What makes Sentinel and Defender XDR ideal for automation

Microsoft Sentinel provides the orchestration layer. Automation rules evaluate conditions on every incident and execute actions or trigger playbooks without custom code. Logic Apps (playbooks) call any API with a REST endpoint: Microsoft Graph for identity operations, Defender for Endpoint API for device isolation, third-party APIs for threat intelligence, Teams and email connectors for notification. The incident trigger passes the full incident object to the playbook, including all correlated alerts and mapped entities. This means one playbook receives the complete context it needs to make an informed automation decision.

Defender XDR provides the platform automation layer. Attack disruption correlates signals from Defender for Endpoint, Defender for Identity, Defender for Office 365, and Defender for Cloud Apps to identify high-confidence attack patterns (AiTM, BEC, ransomware) and automatically contains compromised assets within three minutes. AIR investigates alerts and remediates threats without playbook development. Custom detection rules run KQL queries on a schedule and attach auto-actions (isolate device, quarantine file, disable user) directly to detection results.

The two platforms complement each other. Defender handles fast, single-product, high-confidence actions using built-in intelligence. Sentinel handles complex, cross-product orchestration using your environmental context: your VIP watchlist, your blast radius classifications, your approval gates, your notification routing, your external integrations. The automation program you build in this course uses both platforms, coordinated to avoid conflicts and redundant actions.

NE's M365 E5 license includes everything required: Sentinel workspace, Defender for Endpoint, Defender for Identity, Defender for Office 365, Defender for Cloud Apps, Azure Logic Apps, and the Graph API permissions for identity and device operations. The infrastructure cost of the automation program is minimal. The investment is in the design, testing, and governance of the automation workflows.

0.4 How to get the best from this module

This module is the conceptual foundation. The frameworks here determine every design decision in the remaining thirteen modules. Read it thoroughly before moving to SA1.

Sections 0.1 through 0.5 build the decision framework. These five sections are the analytical core: the tier classification, the confidence thresholds, and the blast radius assessment are the tools you apply to every automation decision. If you remember one thing from this module, remember the three questions: can this be automated safely (tier classification), should it be automated (capacity and value analysis), and at what confidence level (composite threshold model)?

Sections 0.6 through 0.8 map the platforms. The NE audit (0.6) establishes the current state. The Sentinel architecture (0.7) and Defender XDR architecture (0.8) explain how the two automation engines work and how they coordinate. These sections are reference material you will return to when building playbooks in later modules.

Sections 0.9 and 0.10 establish the operational infrastructure. Governance (0.9) and the maturity model (0.10) are not optional additions. Every playbook passes the deploy gate from 0.9 before reaching production. The maturity assessment from 0.10 provides the before/after measurement that quantifies the program's impact.

Section 0.11 applies everything. The guided walkthrough produces the 90-day roadmap that structures the remaining modules.

Estimated time: five hours for the full module, including the walkthrough and knowledge check.

0.5 Module structure

Section 0.1 — Why Most SOCs Don't Automate

Section 0.2 — The Automation Spectrum

Section 0.3 — The Three Automation Tiers

Section 0.4 — The Confidence Threshold Problem

Section 0.5 — The Blast Radius Assessment

Section 0.6 — NE's Automation Landscape

Section 0.7 — Sentinel Automation Architecture

Section 0.8 — Defender XDR Automation Architecture

Section 0.9 — The Automation Governance Framework

Section 0.10 — The Automation Maturity Model

Section 0.11 — Guided Walkthrough: Automation Assessment

Section 0.12 — Module Summary

Prerequisite: Familiarity with the Sentinel incident queue and alert triage workflow. You do not need automation experience. If you have completed the Detection Engineering (DE) or Triage (TR) courses, you have more than enough background. If you are starting fresh, SA0 is self-contained and explains every concept at first use.

Go to Section 0.1 — Why Most SOCs Don't Automate to begin.