Security Operations: Sentinel SIEM, Defender XDR, SOAR & MITRE ATT&CK

Security Operations: Sentinel SIEM, Defender XDR, SOAR & MITRE ATT&CK — Full Guide

Unit 6 of 7. Last-mile recall: 01-Cheat-Sheet · Understand-once worked examples: 02-High-ROI-Explanations · Dates, deprecations & glossary: 99-Appendix

Prerequisite unit (the signals this layer consumes): 05-posture-governance-defender-cloud — Defender for Cloud plans, data connectors, and DCRs are stood up there; this unit collects, detects, and responds to what they emit.

Also feeds in: 01-identity-access-foundations (Conditional Access / PIM / Entra ID Protection sign-in risk) · 02-secure-networking (NSG flow / firewall logs) · 03-data-storage-keyvault (Defender for Storage/Databases, data-plane audit) · 04-secure-compute-containers (Defender for Servers, MDE endpoint signal) · 07-apps-m365-strategy-capstone (Defender for O365 / Cloud Apps signal; downstream IR strategy).

The defining pattern: AZ-500 makes you operate the telemetry pipeline (connectors → DCRs → analytics rules → automation rules → playbooks) and respond to Defender for Cloud alerts. SC-100 makes you architect the same machinery one altitude up — XDR+SIEM topology, the SOAR split between Sentinel and Defender XDR, MITRE-driven coverage, and centralized logging including Purview Audit. Recurring tell: AZ-500 = “configure / enable / respond”; SC-100 = “design / evaluate / recommend.”

This unit is the operational telemetry and response layer of the guide. It consumes signals from every prior unit: the Defender for Cloud plans, data connectors, and DCRs you enabled in 05-posture-governance-defender-cloud (its prerequisite); identity signals from Entra/Conditional Access; network telemetry from the networking unit; and data-plane audit from the storage/database and Purview units. Learn the objects once at the operate level (AZ-500) and the SC-100 design questions reduce to “which of these objects, composed how, at scale, and why.”

1. The unified platform and where things live

1.1 Three roles, one console

• Microsoft Sentinel — cloud-native SIEM + SOAR. Ingests telemetry from across the digital estate into a Log Analytics workspace, detects with analytics rules (KQL), investigates, hunts, and orchestrates response with playbooks. This is the breadth + multicloud layer.
• Microsoft Defender XDR — extended detection and response that natively coordinates Defender for Endpoint, Identity, Office 365, Cloud Apps, Vulnerability Management, Defender for Cloud, and Entra ID Protection, correlating their signals into single unified incidents with full attack-story context and automated cross-product response. This is the Microsoft-first-party depth layer.
• The Microsoft Defender portal (security.microsoft.com) — the unified security operations console that hosts SIEM, SOAR, XDR, posture/exposure management, cloud security, threat intelligence, and Security Copilot in one place.

1.2 Portal convergence — the single most important current fact

This is high-yield and current; both exams now assume the unified portal as the target state.

• Microsoft Sentinel is generally available in the Microsoft Defender portal, either with Microsoft Defender XDR or on its own — including for customers without Defender XDR or an E5 license.
• After March 31, 2027, Sentinel is no longer supported in the Azure portal and exists only in the Defender portal; customers are redirected. (The retirement date was extended from the originally announced July 2026 to March 31, 2027.)
• Starting July 1, 2025, new customers onboarding their first Sentinel workspace who hold subscription Owner or User Access Administrator permissions (and are not Azure Lighthouse-delegated) have their workspace automatically onboarded to the Defender portal, and use Sentinel there only.
• Multitenant: in the Defender portal you connect one primary Sentinel workspace and multiple secondary workspaces per tenant, enabling cross-tenant incident triage and advanced hunting — relevant for MSSP / Lighthouse designs.

1.3 XDR ↔ Sentinel integration — two models

1. Onboard Sentinel to the Defender portal (the unified model). Sentinel data sits alongside Defender incidents, alerts, and vulnerabilities in one queue. Critically, incident creation is owned by the Defender portal (see §4.3).
2. Use the Defender XDR data connector in Sentinel (the Azure-portal model). This streams all Defender XDR incidents and advanced-hunting events into Sentinel and keeps incidents bi-directionally synchronized on status, owner, and closing reason, with in-context deep links between the parallel incidents. You also gain Defender XDR’s alert grouping/enrichment inside Sentinel.

2. Data collection: connectors, DCRs, and ingestion transformations (AZ-500 core)

2.1 Data connectors

Sentinel ships 350+ out-of-the-box data connectors (first- and third-party, plus cloud platforms), installed from the Content hub as part of product solutions. Categories:

• Service-to-service (API-based: Microsoft 365, Entra ID, Defender XDR, AWS, GCP) — often one-click.
• Agent-based via the Azure Monitor Agent (AMA) for Syslog, Common Event Format (CEF), Windows Security Events, and Custom Logs.
• Logs Ingestion API / Codeless Connector Platform for custom sources.

Configure connectors from Configuration > Data connectors in either portal (in the Defender portal: Microsoft Sentinel > Configuration > Data connectors).

2.2 Data Collection Rules (DCRs) — the ingestion control plane

A DCR is an Azure Monitor resource that answers three questions for a stream of telemetry: what source → what transformation → what destination. It is the modern replacement for the legacy Log Analytics agent workflow, and it is used by AMA-based connectors and by the Logs Ingestion API. Key properties:

• Region / resilience: a DCR is created and stored in a region, backed up to the paired region within the same geography, and deployed across all three availability zones — a zone-redundant service.
• Service limit: approximately 12,000 ingestion requests per minute per DCR (a throttling boundary worth knowing for high-volume designs — split high-volume sources across multiple DCRs).
• Authorization: the Logs Ingestion API caller (app / service principal) must be granted the Monitoring Metrics Publisher role on the DCR (via Access Control / IAM).

AMA connector flow (Syslog / CEF / Custom Logs): open the connector → + Create data collection rule → name / subscription / RG (Basic) → select VM Resources (AMA is installed if absent) → Collect (facilities/severities for syslog; table + file pattern + transform for custom logs) → Review + create. For the Custom Logs via AMA destination, the table name must end with the _CL suffix and contain TimeGenerated (DateTime) + RawData (String) — or Message when collecting via a log forwarder.

2.3 Ingestion-time transformations — the exam favorite

A transformation is a KQL query inside the DCR that runs against every incoming record before storage. Three uses:

• Filter to drop irrelevant rows → lower ingestion cost (source | where Facility != "cron").
• Mask / remove sensitive or personal data so it is never persisted (privacy / compliance) — e.g. partially redacting an IP before it lands.
• Reshape / enrich to match the destination schema (source | project-rename Message = RawData) or add columns from a lookup.

DCR variants to distinguish:

• Standard DCR — bound to a specific source (AMA on selected VMs, or a Logs Ingestion API endpoint).
• Workspace transformation DCR — one per workspace; applies transforms to supported tables for sources that don’t otherwise use their own DCR (e.g. built-in connectors). This is the lever to filter a first-party Microsoft connector’s output.
• Multi-stage transformations (Preview) — chain transforms (client-side, then ingestion-time).

Monitoring: DCR data collection emits metrics/logs (errors, ingestion bytes/min, rows dropped) — alert on these to catch broken transformations or throttling.

3. Analytics rules — detection engineering (AZ-500 “enable analytics rules”)

View and manage rules under Configuration > Analytics (active rules, templates, anomalies). Templates come from Content hub product solutions.

3.1 Rule types — picking the right detection engine

3.2 Rule configuration essentials

• Entity mapping: map up to 10 entity types (User, IP, Host, etc.) from query fields. Entities power investigation graphs, incident enrichment, and Fusion correlation.
• Custom details: surface chosen fields directly on alerts/incidents.
• MITRE ATT&CK tagging: select tactics/techniques; these flow to resulting incidents and improve the MITRE coverage matrix (§6).
• Incident settings: enable/disable incident creation and alert grouping. In the unified Defender portal, incident creation is owned by Defender — see §4.3 for the exact behavior.
• Status: Enabled (runs immediately or on a scheduled start) or Disabled.

3.3 Fusion (advanced multistage attack detection)

Fusion’s ML correlates lower-fidelity alerts across products into high-fidelity multistage incidents mapped to the kill chain — e.g. “data exfiltration following a suspicious Entra sign-in,” “rare app consent following suspicious sign-in.”

4. SOAR — orchestration and automated response

4.1 Sentinel automation rules (the triage / orchestration layer)

An automation rule centrally manages incident handling — no code.

• Triggers: When incident is created, When incident is updated, or When alert is created.
• Conditions: on alert fields/entities, analytics-rule name, incident provider (Sentinel vs Defender XDR — shown only in non-onboarded workspaces).
• Actions (ordered): run a playbook, assign an owner, change status/severity, add tags, create incident tasks (standardized analyst checklists), and sequence multiple playbooks/actions. Rules themselves run in a defined Order number.

Use cases: auto-assign incidents, suppress/triage noise, apply one playbook across many analytics rules at once, standardize IR tasks.

4.2 Playbooks (the action layer = Azure Logic Apps)

A playbook is an Azure Logic Apps workflow (so additional Logic Apps consumption charges apply) that performs the heavy lifting — isolate an endpoint via MDE, block / confirm-compromised an Entra user, post to Teams/Slack, send an adaptive card, open a ServiceNow / Jira ticket, send a formatted incident report. Triggers:

• Microsoft Sentinel incident — recommended; receives the full incident (alerts + entities); callable by automation rules.
• Microsoft Sentinel alert (Preview) — for manual runs on alerts or for scheduled rules that don’t create incidents; not callable by automation rules and not usable for Microsoft-security-rule alerts.
• Microsoft Sentinel entity — manual, from investigation/hunting; not callable by automation rules.

Permissions (commonly tested): to run a playbook from an automation rule, the playbook’s resource group needs the Microsoft Sentinel Playbook Operator role and Owner to grant Sentinel access to that RG; the Sentinel service must be granted access to that RG. A greyed-out playbook = Sentinel lacks permission to that RG.

Authentication best practice: use a managed identity for the Logic App over stored connector credentials (least privilege — no secrets on disk).

4.3 Two deprecations / portal behaviors to memorize

• Legacy alert-triggered method: attaching a playbook directly to an analytics rule was disabled for new use in June 2023, and existing such playbooks stop running as of March 2026 → migrate to automation rules.
• Unified Defender portal: because incident creation lives in Defender, Sentinel analytics-rule incident creation must be disabled and automation uses the alert trigger. (Nuance from Microsoft’s docs: for scheduled analytics rules you typically leave incident creation Enabled so Defender XDR — not Sentinel — creates the incident; Microsoft security rules are auto-disabled. The exam-load-bearing point stands: in the unified portal, Defender owns incident creation, so design for alert-triggered automation.)

4.4 Defender XDR automated response (the XDR half of SOAR)

Sentinel is not the only automation engine — Defender XDR brings its own:

• AIR (Automated Investigation & Response): a virtual analyst. An alert triggers an automated investigation that returns a verdict (malicious / suspicious / no threats) and remediation actions, with self-healing of devices, identities, and mailboxes, and cross-product signal sharing (a malicious file found on an endpoint can be purged from all mailboxes).
• Automation level is set per device group via the Remediation level setting; Microsoft recommends Full – remediate threats automatically. Lower levels gate actions on analyst approval in the Action center.
• Automatic attack disruption: high-confidence, machine-speed containment — isolate compromised devices, disable compromised accounts — without human intervention, halting lateral movement mid-attack.
• Action center: the unified queue of automated / pending remediation actions.
• Advanced hunting: KQL across 30 days of raw cross-product signals (endpoint + Defender for Office 365 and more); also powers custom detection rules.

5. Microsoft Defender for Cloud: alert response & workflow automation (AZ-500)

DfC (its plans enabled in the prerequisite 05-posture-governance-defender-cloud unit) generates security alerts (threat detection via integrated TI, behavioral analytics, anomaly detection) and recommendations.

5.1 Respond to alerts

• Triage / respond in DfC; alerts and recommendations land in the SecurityAlert and SecurityRecommendation Log Analytics tables (requires a Security/Audit solution on the workspace).
• One-time export: Download CSV.

5.2 Workflow automation (DfC’s native SOAR hook)

Workflow automation triggers an Azure Logic App in response to changes in security alerts, recommendations, or regulatory-compliance assessments. Use it to email owners, open tickets, or kick off remediation. Deploy at scale with Azure Policy DeployIfNotExist.

5.3 Continuous export (feeding the SIEM)

Continuous export streams DfC data — security alerts, recommendations, secure score, regulatory compliance, attack paths — to one of:

• Log Analytics (Azure Monitor), or
• Azure Event Hubs (the bridge to a third-party SIEM / SOAR), or
• Sentinel, via the Microsoft Defender for Cloud connector (streams alerts) or the broader Defender XDR connector.

Granular config is supported (e.g. only high-severity alerts to an event hub; secure-score changes to a workspace). Required roles: Security Admin or Owner; plus Event Hubs / workspace write permissions as applicable.

6. MITRE ATT&CK coverage (SC-100 signature objective)

ATT&CK is the knowledge base of adversary tactics/techniques used to measure detection coverage. Microsoft Sentinel is currently aligned to MITRE ATT&CK version 18.

6.1 The MITRE page (Preview)

Overlays your detections onto the tactic × technique matrix, distinguishing:

• Active coverage — techniques covered by scheduled / NRT rules currently running (and rules tagged with techniques).
• Simulated coverage — techniques you could cover by enabling available detection templates not yet configured.

Tagging rules, hunting queries, and bookmarks with techniques propagates the technique onto resulting incidents — making coverage measurable end-to-end. SOC optimization surfaces threat-based coverage recommendations and their environmental (ingestion) impact for prioritization, now spanning SIEM + XDR in unified workspaces.

Worked example. The matrix shows strong Initial Access / Execution coverage but a gap at Exfiltration. You enable a simulated rule template for “mass file download,” tag it with the relevant technique, and active coverage closes the gap — and SOC optimization tells you the ingestion impact so you can prioritize.

6.2 The three matrices (exam-critical for SC-100)

• Enterprise — cloud, endpoint, identity, SaaS (the default for most Microsoft-stack design).
• Mobile — mobile device techniques.
• ICS — industrial control systems / OT; pair detection design with Microsoft Defender for IoT (see the Defender for IoT & OT/ICS Security coverage in 04-secure-compute-containers). A coverage design for a manufacturing / OT estate must reach for the ICS matrix and Defender for IoT, not Enterprise alone.

7. Centralized logging & auditing, incl. Purview Audit (SC-100)

SC-100’s “centralized logging and auditing” objective spans two distinct log domains:

7.1 Security / operational telemetry → Sentinel

Aggregate via connectors + DCRs into the Log Analytics workspace (analytics tier), with mirroring to the data-lake tier as the unified repository. For hybrid / multicloud monitoring:

• Azure Arc-enable on-prem / other-cloud servers, then deploy AMA + DCRs.
• Connect AWS and GCP to Defender for Cloud (CSPM / CWP), with findings flowing onward to Sentinel.
• Use DfC continuous export / connectors to centralize cloud-posture signals.

7.2 Audit / forensic logs → Microsoft Purview Audit

Know the tiering:

• Audit (Standard): baseline audit logging across M365 workloads.
• Audit (Premium): adds audit log retention policies (longer, configurable retention), additional high-value events (e.g. MailItemsAccessed), higher bandwidth, and supports forensic investigation of compromised accounts.

Worked example (the design cue). A compromised-mailbox investigation needs to know which messages the attacker accessed. The MailItemsAccessed event and extended retention are Purview Audit (Premium) features — a Standard tenant lacks the evidence. Any SC-100 scenario asking for the blast radius of an account compromise (which messages/files an attacker touched) implies Purview Audit (Premium).

8. Security workflows: IR, hunting, incident management (SC-100)

SC-100 asks you to “design and evaluate security workflows.” Map the tooling to each phase:

• Detection → analytics rules (Sentinel) + XDR correlation; measured by MITRE coverage (§6).
• Triage / incident management → the unified incident queue in the Defender portal; automation rules for auto-assignment, tasks, and SLA tagging; case management for collaboration.
• Investigation → entity / incident graphs, advanced hunting (KQL — 30 days in XDR; longer in Sentinel / data lake), the unified device timeline.
• Threat hunting → proactive KQL hunting queries (tagged with ATT&CK), bookmarks, and Security Copilot for natural-language hunting/automation.
• Response → Sentinel playbooks + automation rules; XDR AIR + attack disruption.
• Lessons learned → SOC optimization recommendations close coverage and cost gaps.

9. Edge cases, gotchas, and exam traps

• NRT is once-per-minute, not real-time / streaming. A “fastest single-condition detection” answer = NRT.
• Fusion silently degrades without entity mapping + MITRE tactics on contributing scheduled rules.
• Unified portal disables Sentinel incident creation (Defender owns it) → use alert-triggered automation.
• Analytics-rule-attached playbooks stop running March 2026 → migrate to automation rules.
• Continuous export to Event Hubs ≠ to Sentinel — Event Hubs is the conduit to a third-party SIEM/SOAR; for Sentinel use the DfC connector or export to the workspace.
• Same syslog facility for Syslog + CEF on one forwarder → duplicate ingestion.
• Sentinel-enabled workspaces are exempt from the Azure Monitor filtering charge — aggressive DCR filtering is free.
• Playbook permissions: Microsoft Sentinel Playbook Operator on the playbook’s RG; Owner to grant Sentinel access. Greyed-out playbook = missing RG permission.
• DCR throttling: ~12,000 ingestion requests/min per DCR — split high-volume sources across DCRs.
• Logs Ingestion API auth: caller needs Monitoring Metrics Publisher on the DCR.
• Custom-log table must end in _CL with TimeGenerated + RawData (or Message from a forwarder).
• Azure portal Sentinel retires March 31, 2027; auto-onboarding for new tenants since July 1, 2025 — design for the Defender portal as the target.

10. AZ-500 (operate) ↔ SC-100 (architect) summary

Master the objects at the operate level (AZ-500) and the SC-100 design questions reduce to “which of these, composed how, at scale, and why.”

Navigation: ← Prev 05-posture-governance-defender-cloud · Next → 07-apps-m365-strategy-capstone · Index 00-Strategy-and-Map · Appendix 99-Appendix