Microsoft Sentinel SOAR Pipeline & Incident Automation

Project Objective

The objective of this project was to build and validate a production-aligned SOAR pipeline in Microsoft Sentinel that could:

• ingest security alerts from connected Microsoft security sources
• reliably create incidents inside Sentinel
• trigger automation rules when incidents are created
• run Azure Logic App playbooks through managed identity
• support incident-based automation instead of alert-based noise
• provide a trustworthy automation layer before integrating third-party tools

This project existed to answer a critical operational question: Can the Microsoft-native SOC backbone create and automate incidents reliably enough to serve as the foundation for the wider SaintValTech SOC environment?

Environment Overview

Core Microsoft Components

• Microsoft Sentinel
• Microsoft Defender XDR
• Microsoft Defender for Endpoint
• Microsoft Entra ID
• Azure Logic Apps
• Log Analytics Workspace: LAW-Production-SOC
• Resource Group: RG-Production-SOC

Endpoint Sources Used During Validation

• macOS endpoint onboarded to Defender for Endpoint
• Windows Server endpoint previously onboarded and validated
• Microsoft-native connectors active inside Sentinel

Scope Constraint

This project intentionally focused on Microsoft-native signals only during validation. No Wazuh, Security Onion, TheHive, Cortex, or third-party telemetry was used during the core trust-validation phase.

That design choice mattered because it isolated the Microsoft incident and automation pipeline from external troubleshooting noise.

Architecture Role

This project established the Microsoft-native detection-to-automation path for the lab.

High-Level Flow

Endpoint telemetry → Microsoft Defender XDR → Microsoft Sentinel → Analytics rule → Incident creation → Automation rule → Logic App playbook execution

This created the first verified SOAR backbone in the environment.

Core Components Implemented

1. Microsoft Defender for Endpoint Validation

Before building automation, the project first confirmed that Defender telemetry was actually reaching the Microsoft security stack.

• Windows Server Defender health and sensor state reviewed
• macOS Defender detection tested
• Microsoft Defender portal alerts confirmed
• endpoint activity visible in connected Microsoft tools

2. Sentinel Connector State Review

Connected Microsoft security sources were reviewed to confirm ingestion paths and establish what was already native to the platform.

• Microsoft Defender for Endpoint
• Microsoft Defender XDR
• Microsoft Defender for Identity
• Microsoft Entra ID
• Microsoft Entra ID Protection
• Microsoft Defender for Cloud Apps
• Microsoft Defender Threat Intelligence
• Security Events (legacy, where applicable)

3. Core Logic App Creation

A Sentinel-compatible Logic App was created to serve as the automation target for incident workflows.

• Hosting model: Consumption
• Tenancy model: Multi-tenant
• Workflow type: Stateful
• Resource Group: RG-Production-SOC
• Region: Canada East
• Playbook Name: PB-Incident-Core-SOAR
• Trigger: Microsoft Sentinel — When an incident is created
• Authentication model: Managed Identity

4. Sentinel Playbook Permissions

A key issue during implementation involved Sentinel’s permission model for running playbooks.

• removed existing resource group permission assignment
• re-added permission for RG-Production-SOC
• confirmed managed identity and playbook visibility state
• validated that Sentinel could execute the playbook after permission refresh

A major operational lesson from this step was that permission UI behavior can be misleading. Successful SOAR operation depends on actual resource permissions and managed identity readiness, not just what the browse interface appears to show.

5. Automation Rule Creation

An incident-driven automation rule was created to standardize what happens when Sentinel creates an incident.

• Name: AR-Incident-Core-SOAR
• Trigger: When incident is created
• Actions: Add tags, Assign owner, Change severity, Run playbook

Action order mattered. The playbook was intentionally placed last to preserve clean processing behavior.

6. Guaranteed Incident Rule Concept

Controlled analytics rules were created to remove uncertainty around whether Sentinel was truly capable of creating incidents on demand.

This followed a deliberate operational principle: A SOC pipeline should be validated with deterministic tests, not hope.

7. Scheduled Guaranteed Incident Rule

An initial analytics rule was built around Defender-derived detection signals. While the logic worked, visible testing was complicated by alert grouping, incident reuse, schedule windows, and evaluation timing.

8. Near Real-Time (NRT) Rule Design

To remove lag and ambiguity, the project moved to a Near Real-Time rule model.

• Name: NRT-Test-Immediate-Incident
• Rule type: Near Real Time
• Query source: SecurityAlert
• Incident creation: enabled
• Re-open closed incidents: disabled

NRT rules were better for SOAR validation because they reduced waiting time and provided immediate feedback.

9. EICAR-Based Endpoint Validation

A controlled endpoint detection test was used to generate a safe, known security event.

• Defender detected the EICAR test file
• an alert was created in Microsoft Defender
• Sentinel ingested the alert
• the NRT rule matched the event
• an incident was created
• the automation rule triggered
• the playbook execution path was validated

Incident Confirmation

The project confirmed that the following sequence worked correctly:

• endpoint telemetry generated a valid detection
• Microsoft Defender created an alert
• Sentinel ingested the signal
• analytics rule logic matched the event
• a Sentinel incident was created
• the incident triggered the automation rule
• the playbook executed through the configured SOAR path

This validated the core Microsoft-native incident pipeline.

Challenges Encountered

Alerts vs Incidents Confusion

One of the most important lessons from this project was the distinction between alerts and incidents.

• alerts do not always create fresh visible incidents
• incidents may be grouped
• repeated tests may enrich or reopen prior workflows
• analytics rule success is not always visually obvious without checking the right history and logic

Grouping and Reuse Behavior

Sentinel’s alert grouping and incident reuse behavior initially made the environment appear unreliable, even though the platform was behaving normally.

Alert-Based vs Incident-Based SOAR

Another key design decision was rejecting alert-based SOAR as the primary operational model.

• higher duplication risk
• inconsistent UI behavior
• less aligned with how Sentinel is actually used in real SOC operations

The final decision was to adopt incident-based SOAR as the correct design.

Security & Operational Value

This project demonstrates practical capability in:

• Microsoft Sentinel analytics rule design
• SOAR playbook deployment
• Logic App workflow design
• Defender-to-Sentinel integration validation
• incident-based automation architecture
• permission troubleshooting
• managed identity usage
• deterministic SOC pipeline testing
• understanding of alert vs incident semantics
• operational debugging inside Microsoft security tooling

Operationally, this project matters because it created a trusted automation backbone for the environment. Without this proof, later integrations with TheHive, Wazuh, Security Onion, and Cortex would be built on uncertainty.

Outcome

This project successfully validated the Microsoft-native SOAR foundation of the SaintValTech SOC environment. It proved that incidents can be created reliably in Sentinel, that those incidents can trigger automation rules, and that playbooks can execute correctly through managed identity and Logic Apps.

This created a production-aligned, incident-centric automation model that now serves as the trusted base for future integrations involving TheHive, Wazuh, Shuffle, Security Onion, Cortex, and multi-source case workflows.