15.4 Sentinel Incident Management & SOAR Automation

8.4 Sentinel Incident Management & SOAR Automation

When security anomalies are identified by threat detection engines, Microsoft Sentinel aggregates related alerts into central investigation cases known as Incidents. Sentinel provides native Security Orchestration, Automation, and Response (SOAR) capabilities to streamline incident triage, reduce resolution SLAs, and execute automated response playbooks.

---

Sentinel Incident Triage & Investigation Graph

An Incident in Microsoft Sentinel represents a correlated grouping of one or more security alerts that together indicate a potential cyber attack. Triage operations take place within the Incident Management interface.

Incident Properties & Lifecycle

• Status: New (unassigned/untriaged), Active (under active investigation), or Closed (resolved).
• Severity: High, Medium, Low, or Informational.
• Owner: Assigned SOC analyst or automated triage group.
• Tactics & Techniques: Mapped MITRE ATT&CK categories.
• Entities: Mapped identifiers (Users, Hostnames, IP Addresses, File Hashes, Azure Resources) involved in the attack chain.

The Investigation Graph

The Investigation Graph provides a visual, node-based interactive canvas that allows security analysts to examine an incident's full blast radius and lateral movement:

1. Entity Node Connections: Displays central entity nodes (e.g., a targeted user account) connected to related alert nodes, IP addresses, and hostnames.
2. Timeline Exploration: Allows analysts to scrub back and forth through time to trace the exact chronological sequence of events across compromised endpoints and identity services.
3. Entity Insight Sidebars: Generates real-time contextual telemetry for selected entity nodes (e.g., recent failed sign-ins, privilege escalations, or geographic location anomalies for a targeted account).
4. Expanding Related Entities: Enables analysts to expand node connections to discover whether an entity is implicated in other concurrent incidents across the enterprise.

---

Sentinel Analytics Rules Deep Dive

Sentinel correlates incoming log streams using five distinct Analytics Rule engines:

1. Scheduled Analytics Rules: Custom or built-in KQL queries that execute on a defined schedule (e.g., every 10 minutes looking back 30 minutes). Features custom alerting thresholds, suppression windows, and entity mappings.
2. Near-Real-Time (NRT) Rules: Evaluates KQL query conditions with ultra-low latency (evaluating log ingestion within 1 minute intervals) to detect critical threat indicators instantly.
3. Fusion ML Engine: A pre-configured machine learning engine that automatically evaluates low-fidelity signals and alerts across disparate telemetry sources (Microsoft Defender XDR, Entra ID Protection, Azure Activity) to synthesize high-fidelity multi-stage attack incidents without requiring KQL writing.
4. Threat Intelligence Rules: Matches ingested STIX/TAXII threat indicators (malicious IPs, domains, hashes) directly against streaming event logs (DNS, Web Proxy, Firewall logs) in real time.
5. Microsoft Security Rules: Automatically creates Sentinel incidents directly from native security alerts generated by Microsoft Defender products (Defender for Cloud, Defender for Endpoint, Defender for Identity).

---

Automation Rules vs. SOAR Playbooks

Sentinel provides two complementary mechanisms for response automation:

---

Triggering Playbooks: Alert vs. Incident Triggers

SOAR Playbooks leverage dedicated Microsoft Sentinel Logic App connectors:

• Alert Trigger (Microsoft Sentinel Alert): Executes when an individual security alert is generated. Useful for localized enrichment or immediate resource-level responses before incident correlation occurs.
• Incident Trigger (Microsoft Sentinel Incident): Executes when an overall Incident is created or updated. Passes the entire array of correlated alerts and mapped entities into the Logic App, allowing holistic automation across all attack vectors simultaneously.

---

Managed Identity Permissions for Playbooks

For security playbooks to modify Sentinel incidents or execute remediation tasks against Azure resources, they must authenticate securely.

Authentication Best Practices

• Managed Identity (Recommended): Playbooks use System-Assigned or User-Assigned Managed Identities rather than static credentials, API keys, or OAuth user tokens.
• Required Azure RBAC Roles:
  • Microsoft Sentinel Automation Contributor: Grants Sentinel permission to execute the Logic App playbook on behalf of automation rules.
  • Microsoft Sentinel Contributor / Responder: Granted to the Logic App's Managed Identity so it can update incident statuses, assign tags, or post comments to Sentinel.
  • Target Workload Roles: Specific roles required for active remediation (e.g., Virtual Machine Contributor to isolate network interfaces, or Entra ID User Administrator roles to revoke compromised user sessions).

---

Incident Assignment & SLA Management

Effective Security Operations Center (SOC) management relies on structured incident response workflows:

• SLA Tracking: Automation rules assign incoming incidents to specific analyst queues based on severity and source, establishing operational response targets.
• Incident Closure Taxonomy: When closing an incident, analysts must select a mandatory Closure Reason:
  • True Positive – Suspicious Activity: Confirmed security incident requiring remediation.
  • False Positive – Incorrect Alert Logic: Alert logic was flawed or overly sensitive.
  • Benign Positive – Suspicious but Expected: Authorized activity (e.g., scheduled penetration test).
• Audit Comments: Detailed closure comments are required to train Fusion ML models and maintain audit trails for regulatory compliance.