One Event, Three Portals: How a Single Sysmon Line Becomes a Microsoft Defender XDR Incident

1. One event, three portals, nine minutes#

At 14:03:17 UTC on a Tuesday, winword.exe on the host MAL-CONTOSO-PRD-04 spawns a child process: powershell.exe -EncodedCommand JABwAD0AJwBoAHQAdABwADoALwAv.... Sysmon, which loads early in the boot sequence as a boot-start kernel driver, writes a single ProcessCreate record (Event ID 1) to the Windows event log channel Microsoft-Windows-Sysmon/Operational ^[1]. The record is roughly two kilobytes of XML with a stable ProcessGuid field that uniquely identifies the new process across the host's lifetime ^[6].

At 14:03:21 UTC, the same record appears in the Event table of an Azure Log Analytics workspace named law-contoso-secops ^[7]. At 14:05:00 UTC, a Microsoft Sentinel scheduled analytics rule fires its five-minute KQL query, matches a parent-image heuristic (winword.exe -> powershell.exe -EncodedCommand), and produces a SecurityAlert row whose Entities JSON column names the host, the parent process, the child process, and the encoded command line ^{[8] [9]}. At 14:07:42 UTC, a Microsoft Defender for Cloud (MDC) alert -- emitted by the MDC for Servers cloud workload protection plan, which sits on top of the Microsoft Defender for Endpoint (MDE) sensor on that same host -- shows up in the workspace's SecurityAlert table with the title Suspicious PowerShell command line ^{[10] [11]}. And at 14:09:30 UTC -- nine minutes and thirteen seconds after the kernel call -- a single incident appears in the Microsoft Defender XDR portal at security.microsoft.com. Its title: Multi-stage incident on one endpoint. Its alert tab lists three rows: one from Sentinel, one from MDC, and (because MDE was also installed) one from Defender for Endpoint's native detection engine ^{[12] [4]}.

Three independent detection systems, three different timestamps, three different alert grammars, one incident. How?

That question is the spine of this article. It is not a marketing question -- "look how unified it is" -- because the convergence is partial and the seams are load-bearing. It is an engineering question: which hops happen where, what does each hop cost in latency and money, and where does the unification actually stop?

Microsoft Defender XDR is not a single product. It is a correlation surface that fans in three structurally different pipelines: Sentinel's KQL analytics rules over Log Analytics, Defender for Cloud's cloud-workload-protection (CWPP) alerts from MDC plans (servers, containers, SQL, storage, App Service), and the native Defender stack (Endpoint, Identity, Office, Cloud Apps). The fan-in is real but partial: Sentinel cross-workspace correlation, MDC posture findings, and most third-party connectors stay outside the unified incident graph ^{[13] [3]}.

Here is the full path the Sysmon record takes from kernel to portal. Each numbered box is a real component with its own owner team, deployment lifecycle, and failure mode:

{<code>flowchart LR   A["1 Sysmon kernel ETW provider on host"]   B["2 Azure Monitor Agent + Data Collection Rule"]   C["3 Log Analytics workspace Event/SecurityEvent tables"]   D["4 Sentinel scheduled or NRT analytics rule -- KQL"]   E["5 MDC alert via Defender for Servers + MDE sensor"]   F["6 Defender XDR correlation engine -- security.microsoft.com"]   A --> B --> C --> D --> F   C --> E --> F   classDef src fill:#e8f4ff,stroke:#2b6cb0,color:#1a365d   classDef sink fill:#fffaf0,stroke:#dd6b20,color:#7b341e   class A,B,C src   class F sink</code>}

The diagram understates how separate these hops are. Box 2 lives on the host. Box 3 is a multi-tenant Azure Data Explorer cluster ^[14]. Box 4 runs on Sentinel's serverless query engine inside the workspace's home region. Box 5 is a Defender for Cloud plan with its own SKU, scoped to an Azure subscription. Box 6 is a separate web portal in a separate Microsoft 365 tenant scope. Each one rolled out at a different time, was renamed at least once, and absorbed a different earlier product. The next section recovers the lineage that explains why.

2. Three lineages that became one portal#

The three pipelines that converge at hop 6 did not start as siblings. They started as three separate Microsoft product lines aimed at three different buyer personas: an Azure subscription owner who wanted posture scoring, a Windows engineer who wanted endpoint detection, and a SOC analyst who wanted a SIEM. Reading the path right-to-left -- from the unified portal back to its three roots -- is the only honest way to understand why the seams look the way they do.

The CSPM line started first. In December 2015, Microsoft put Azure Security Center (ASC) into public preview as a per-subscription posture dashboard that scored Azure resources against a baseline of hardening recommendations ^[20]. ASC went generally available in July 2016 alongside JIT VM access ^[21]. Public sources frequently report ASC GA as "October 2015" or "October 2016." The primary Azure blog from December 2015 explicitly says "Azure Security Center -- now in public preview," and the July 2016 Microsoft Security blog announces the GA wave of new capabilities. The December 2015 preview / mid-2016 GA framing matches both authoritative announcements ^{[20] [21]}. Over the next five years ASC absorbed runtime protection plans -- Defender for Servers, SQL, Storage, App Service, Containers -- and was renamed Microsoft Defender for Cloud at Ignite Fall 2021, the same wave that renamed Microsoft Cloud App Security to Microsoft Defender for Cloud Apps (MDCA) ^{[22] [23]}.

The SIEM line is much younger. Microsoft announced Azure Sentinel in public preview on February 28, 2019 as the first cloud-native SIEM from a hyperscaler, built on top of Azure Log Analytics and the Kusto Query Language ^[24]. It went GA on September 24, 2019 ^[25]. It was renamed Microsoft Sentinel in November 2021 (same Ignite wave). Sentinel inherited every Log Analytics integration that Azure Monitor already had, which meant it could ingest Windows event logs, syslog, Office 365 audit, Microsoft Entra ID sign-ins, and anything you could shove into a workspace with a custom collector ^[26].

The XDR line landed last. In September 2020 Microsoft announced "Microsoft unified SIEM and XDR" as a direction, and rolled the Office 365 ATP and Microsoft Defender ATP detection surfaces into a single portal called Microsoft 365 Defender ^[27]. The portal was renamed Microsoft Defender XDR in early 2024, and the SIEM and XDR portals were merged at Ignite November 2023, with the unified Microsoft security operations platform going generally available in July 2024 ^{[28] [29]}. The Sentinel experience inside the Azure portal will be retired on March 31, 2027 (a deadline extended from its original July 1, 2026 target); after that date, Sentinel lives only inside security.microsoft.com ^{[30] [31]}.

{`gantt
title Three lineages converging at security.microsoft.com
dateFormat YYYY-MM
axisFormat %Y

section EDR line
Sysmon v1 (Sysinternals)         :done, 2014-08, 12M
Microsoft Defender ATP (EDR)     :done, 2016-03, 60M
Renamed Microsoft Defender for Endpoint :done, 2020-09, 24M

section CSPM and CWPP line
Azure Security Center preview    :done, 2015-12, 8M
Azure Security Center GA         :done, 2016-07, 64M
Renamed Microsoft Defender for Cloud :done, 2021-11, 36M

section SIEM line
Azure Sentinel preview           :done, 2019-02, 7M
Azure Sentinel GA                :done, 2019-09, 26M
Renamed Microsoft Sentinel       :done, 2021-11, 24M

section XDR convergence
Microsoft 365 Defender portal    :done, 2020-09, 38M
Sentinel merged into Defender portal :done, 2023-11, 8M
Unified secops GA                :done, 2024-07, 24M
Sentinel Azure portal retires    :crit, 2027-03, 1M`}

Three things matter about this timeline for the rest of the article. First, the CSPM/CWPP line is older than either SIEM or XDR -- which is why the Defender for Cloud team owns its own alert format, its own subscription-scoped permissions model, and its own portal at portal.azure.com/#blade/Microsoft_Azure_Security, none of which fully merge into the unified Defender experience even today. Second, Sentinel inherited Log Analytics, not the other way around -- so the storage substrate, the agent (Azure Monitor Agent), and the query language (KQL) all predate Sentinel by years and serve far more workloads than security. Third, the unified portal is the new arrival, not the foundation. The convergence is grafted on top of three pre-existing pipelines, and that grafting -- not the products themselves -- is what makes the architecture interesting.

3. The pre-cloud SIEM bottleneck#

To understand why Sentinel was built the way it was, hold the question in mind that every SIEM buyer asked their finance team between roughly 2008 and 2018: "Why does each new server cost me a license-tier upgrade?"

Classic on-premises SIEMs -- Splunk Enterprise, ArcSight, QRadar -- priced by ingested gigabytes per day, billed as a perpetual or annual license tied to a tier. Crossing a tier boundary triggered a forklift purchase. Storage was on-prem disk, and retention was constrained by how much steel you bought; compute was on the same hardware, so peak query load contended with peak ingest. The cost shape was step-wise, and the constraint that bound it most painfully was peak ingest rate.

The reframe Sentinel proposed -- and that the Kusto/Log Analytics substrate enabled -- was to separate the three cost axes: ingest, storage retention, and query compute. Each axis bills continuously and independently. There is no tier to cross. Adding a new data source is a Data Collection Rule edit, not a procurement event. Retaining last quarter's logs another year is a per-GB-month flag, not a disk purchase ^[32].

This deconstruction is what makes the Sentinel pipeline interesting upstream of the SOC. When ingest is a separately-billed continuous variable, the Data Collection Rule becomes the most important security artifact in the deployment: it determines what flows in and therefore both what costs you incur and what you can possibly detect. (The accuracy-report follow-up that drives section 10 hinges on exactly one wrong word in a DCR.) When query compute is serverless and per-byte, a long-running threat hunt over a year of process-creation events is a question of dollars, not of capacity-plan slack. And when storage retention is a per-GB-month flag, the question "should we retain this for compliance?" decouples from "do we have rack space?"

"Sentinel offers a flexible and predictable pricing model. Pay-as-you-go pricing lets you pay for what you use, while commitment tiers provide guaranteed discounts." ^[32]

That is the pricing-page sales line. The architectural truth underneath it is that the three pre-cloud bundles unbundled, and once they unbundled, the SIEM was free to grow horizontally with the rest of the cloud workload. That is exactly what happened with Sentinel between 2019 and 2024: it accumulated 300+ data connectors for every Azure service, every Microsoft 365 surface, every major SaaS log feed, and a long tail of third-party security tools ^[26]. None of that catalog would have been economically sane on a per-GB/day license tier.

But the unbundle was not free. The price of separately-billed continuous axes is that you have to measure on all three axes. You now need to know your steady-state ingest rate, your retention policy, and your hunt query patterns. The next section steps inside the substrate that makes those measurements -- and the queries on top of them -- possible.

4. The cloud-native SIEM substrate: KQL on Log Analytics#

Microsoft Sentinel is a thin layer over a much older substrate. That substrate is Azure Monitor Log Analytics, which itself is a security-and-multitenancy wrapper around Azure Data Explorer (ADX), the cluster engine that runs Kusto Query Language (KQL) ^[14]. Understanding the stack matters because almost everything Sentinel can or cannot do is determined by what Log Analytics and KQL can or cannot do, not by anything Sentinel itself implements.

The layering is shown below. Notice that KQL itself spans four Microsoft surfaces, of which Sentinel is just one. ※ KQL's polymorphism -- one query language across Monitor, Sentinel, Defender XDR advanced hunting, and ADX itself -- is the single most under-appreciated decision in the Microsoft security stack. It is also the reason your KQL skills move across teams.

{<code>flowchart TB   subgraph L1["Layer 1 -- storage cluster"]     ADX["Azure Data Explorer (Kusto engine)"]   end   subgraph L2["Layer 2 -- managed namespace"]     LA["Log Analytics workspace -- typed tables, RBAC, regional"]   end   subgraph L3["Layer 3 -- query surfaces"]     AZM["Azure Monitor logs -- ops + perf"]     SEN["Microsoft Sentinel -- SIEM analytics rules"]     XDR["Defender XDR -- advanced hunting"]     ADXQ["ADX direct -- analytics + BI"]   end   ADX --> LA   LA --> AZM   LA --> SEN   LA --> XDR   ADX --> ADXQ   classDef stor fill:#e8f4ff,stroke:#2b6cb0,color:#1a365d   classDef ns fill:#fff5d6,stroke:#b7791f,color:#5f370e   classDef ui fill:#e6fffa,stroke:#319795,color:#234e52   class ADX stor   class LA ns   class AZM,SEN,XDR,ADXQ ui</code>}

The substrate predates Sentinel by years. Log Analytics was the rebranded form of Operations Management Suite (OMS), which Microsoft introduced in 2015 as a cloud companion to System Center Operations Manager. The agent that fed OMS -- the Microsoft Monitoring Agent (MMA), sometimes also called the Log Analytics agent -- shared its agent lineage with the System Center Operations Manager agent and ran on Windows and Linux servers to ship event logs and performance counters to the workspace ^{[35] [36]}. ADX (Kusto) was productised externally in 2018 after years of internal Microsoft use as the engine behind Bing telemetry, Office 365 ops, and Azure monitoring ^[14].

Two consequences of the substrate inheritance shape every hop downstream:

1. Schema is per-table, not per-product. A Log Analytics workspace exposes typed tables like Event (Windows event log records), SecurityEvent (Windows Security channel), Syslog, Heartbeat, SecurityAlert, DeviceProcessEvents (mirrored from Defender XDR's advanced hunting schema), Perf, and any number of Custom_CL tables ^{[7] [37]}. KQL queries are written against tables, not against products. A Sentinel analytics rule is just a saved KQL query that runs on a schedule and emits a row into SecurityAlert.

2. Cross-workspace and cross-table joins are first-class. Because the substrate is a real query engine, you can join between SecurityEvent and SigninLogs and DeviceProcessEvents in a single rule. You can use workspace("law-other").Event to reach into a separate workspace. You can call externaldata() to read from a blob. This expressive power is the source of both Sentinel's flexibility and its operational complexity: the rule that worked in test stops working in prod because the test workspace did not have a SigninLogs table or because the cross-workspace permission is missing ^[38].

For the Sysmon worked example: the kernel record will land in the Event table (because Sysmon's channel is treated as a generic Windows event log, not as the SecurityEvent Security channel). The detection KQL will live as a Sentinel scheduled analytics rule that reads from Event, filters to Source == "Microsoft-Windows-Sysmon" and EventID == 1, parses the XML payload (the next section will show the exact pattern), and emits a SecurityAlert row. That SecurityAlert row is what hop 6 ultimately fans in. The substrate did all the heavy lifting; Sentinel just wrote the rule.

5. The XDR reframe: from per-product portals to a single incident graph#

If the SIEM substrate is "many tables, one query engine," the XDR reframe is "many alert sources, one incident graph." Microsoft Defender XDR exists because by 2019 a typical Microsoft enterprise customer had four or five separate Microsoft security portals -- one for Office 365 ATP, one for Microsoft Defender ATP, one for Microsoft Cloud App Security, one for Azure AD Identity Protection, and the Azure Security Center / Sentinel pair. Each portal had its own alert grammar, its own console, and its own analyst workflow. The XDR reframe is to keep the alert sources but merge the analyst surface.

The mechanism the merge uses is the entity graph. When any of the source pipelines emits an alert, it is required to attach a set of typed entities (e.g., Host = MAL-CONTOSO-PRD-04, Process = winword.exe, Account = CONTOSO\\jdoe) to that alert ^[9]. The Defender XDR correlation engine reads incoming alerts, normalizes the entity values, and groups alerts whose entities overlap in time and identity into a single incident ^[4]. That is the entire trick. It is conceptually simple. Operationally it has many edge cases, which section 8 returns to.

For the worked example, the three alert sources (Sentinel KQL rule, MDC for Servers, MDE) each emit a separate alert. Each alert lists Host = MAL-CONTOSO-PRD-04 and (for two of the three) ProcessGuid = {abc-...}. The correlation engine merges them on the host entity within a sliding time window. Result: one incident with three correlated alerts, not three separate incidents. The temporal fan-out is shown below; the fan-in geometry returns in section 6.6.

{<code>sequenceDiagram     autonumber     participant K as Host kernel (Sysmon)     participant LA as Log Analytics workspace     participant SEN as Sentinel scheduled rule     participant MDC as MDC for Servers alert     participant MDE as MDE native detection     participant XDR as Defender XDR correlation     K->>LA: 14:03:21 -- Event row (ProcessGuid abc)     LA->>SEN: 14:05:00 -- 5-min query fires     SEN->>XDR: 14:05:04 -- SecurityAlert from KQL     K->>MDE: 14:03:17 -- local EDR sensor signal     MDE->>MDC: 14:06:30 -- MDE telemetry surfaces MDC alert     MDC->>XDR: 14:07:42 -- SecurityAlert from MDC plan     MDE->>XDR: 14:08:11 -- DeviceAlertEvents direct     XDR->>XDR: 14:09:30 -- merge on host + ProcessGuid -> Incident I-7842</code>}

Two things in the diagram deserve to be noticed. First, the three alerts arrive in a window that is small but not synchronous: about six minutes from earliest to latest, all gated by the slowest pipeline (Sentinel's five-minute scheduled query). Second, MDE shows up twice: once as the source that feeds MDC's CWPP plan (hop 5 in the master diagram), and once as a native Defender XDR alert source. The two are the same sensor data routed through two different alert grammars to the same correlation surface. The fact that the correlation engine deduplicates them on ProcessGuid is not accidental -- it is the load-bearing identifier that makes the unification work for endpoint events. For non-endpoint sources (cloud-control-plane alerts from MDC for Storage, for example), there is no equivalent shared identifier, and the deduplication has to fall back on weaker entity matches like account name or IP. That is where the convergence frays.

The next section walks the six hops in order, naming the artifact at each hop and the failure mode that lives there. Hops 1 through 4 are the SIEM lineage. Hop 5 is the CWPP lineage. Hop 6 is the XDR fan-in.

6. Walking the six hops#

6.1 Hop 1 -- The kernel emission#

The Sysmon driver -- SysmonDrv.sys -- is registered as a Windows boot-start driver under HKLM\SYSTEM\CurrentControlSet\Services\SysmonDrv with Start=0, which means the I/O manager loads it during the early-boot phase before the bulk of user-mode services start; it also registers as an event-tracing-for-Windows (ETW) provider. On every process creation, it hooks the kernel's PsSetCreateProcessNotifyRoutineEx callback, builds an event record, and writes it to the Windows event log channel Microsoft-Windows-Sysmon/Operational ^{[1] [6]}. The record carries roughly thirty fields, including the parent and child image paths, the command lines, the user SID, the integrity level, the hashes (configurable: MD5, SHA1, SHA256, IMPHASH), the parent and child ProcessGuid values, and the kernel-side timestamp.

For the worked example, the kernel emission at 14:03:17 UTC contains, among other fields:

EventID:       1
TimeCreated:   2026-06-02T14:03:17.412Z
Computer:      MAL-CONTOSO-PRD-04
ProcessGuid:   {62b9c5cf-7c64-67ab-2e00-000000003200}
ProcessId:     8124
Image:         C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
CommandLine:   powershell.exe -EncodedCommand JABwAD0AJwBoAHQAdABwADoALwAv...
ParentProcessGuid:   {62b9c5cf-7b21-67ab-2c00-000000003200}
ParentProcessId:     6210
ParentImage:   C:\Program Files\Microsoft Office\root\Office16\winword.exe
ParentCommandLine:   "winword.exe" /n "C:\Users\jdoe\Downloads\invoice.docm"
User:          CONTOSO\jdoe
IntegrityLevel: Medium
Hashes:        SHA256=04ED...

Nothing further happens at hop 1 until someone reads the channel. The kernel will not push the event off the host; it will only sit in the local event log, rotating by size or age, until an agent picks it up. That is hop 2.

6.2 Hop 2 -- Azure Monitor Agent shipping via a Data Collection Rule#

The agent that reads the Sysmon channel and ships it to the workspace is the Azure Monitor Agent (AMA). AMA replaced the older Microsoft Monitoring Agent (MMA) / Log Analytics agent, which Microsoft retired effective August 31, 2024 ^[35]. Customers still running MMA past that date are in unsupported territory, and -- this is the critical operational fact -- AMA does not automatically pick up where MMA left off. AMA requires explicit migration: a Data Collection Rule (DCR) describing which events to collect and which workspace to send them to ^[39].

{<code>flowchart LR   CH["Windows event channels (XPath subscription)"]   AMA["Azure Monitor Agent process"]   DCR["Data Collection Rule (cached locally)"]   ING["Log Analytics ingestion endpoint -- regional HTTPS"]   TBL["Workspace table -- Event / SecurityEvent / WindowsEvent"]   CH --> AMA   DCR --> AMA   AMA --> ING   ING --> TBL   classDef cfg fill:#fff5d6,stroke:#b7791f,color:#5f370e   classDef agent fill:#e8f4ff,stroke:#2b6cb0,color:#1a365d   classDef sink fill:#e6fffa,stroke:#319795,color:#234e52   class DCR cfg   class AMA,CH agent   class ING,TBL sink</code>}

For the Sysmon channel specifically, AMA needs a DCR whose windowsEventLogs block names the XPath subscription Microsoft-Windows-Sysmon/Operational!*[System[(EventID=1)]] (or a broader filter that includes EventIDs 1, 3, 7, 8, 10, 11). The stream name in the destination block determines which table the record lands in: a DCR that names Microsoft-Event ships into the generic Event table; one that names Microsoft-WindowsEvent ships into the newer WindowsEvent table; and naming anything else silently emits nothing ^{[5] [26]}. The AMA does not log a hard error in this case; the events simply never appear, and the analyst sees a dashboard that is missing the wave.

Hop 2 finishes at about 14:03:19 UTC for the worked example -- two seconds after the kernel emission. The record is now in the workspace's ingest buffer.

6.3 Hop 3 -- Workspace ingestion and the table-choice question#

The ingestion endpoint validates the record against the named stream's schema, applies any DCR-side transformations, and persists the row into the destination table. From here on the record is queryable via KQL with end-to-end ingestion latency typically in the low minutes ^[7]. For the Sysmon channel the destination table is almost always Event, because the SecurityEvent table is the Windows Security channel only (the AMA securityEvents data source), and the Sysmon channel is a separate operational channel ^[37].

The table choice matters because it changes the shape of the row and the cost of querying it. The two relevant tables for Windows event data behave as follows:

A representative KQL detection that runs against the older Event table for the worked example looks like the snippet below. Show it to a SOC analyst and they will read it left-to-right; show it to a Kusto engineer and they will tell you the parse_xml is the expensive part.

The KQL that parses a Sysmon event out of the older Event table follows a four-step idiom that is worth walking explicitly, because the same shape appears in every detection a SOC writes against XML-shaped Windows event data. Step one: parse_xml(EventData) reads the entire EventData payload (a string column) and returns a dynamic JSON tree whose root is DataItem.EventData and whose interesting children are an array of <Data Name="...">value</Data> elements ^[40]. Step two: mv-expand ev = ...DataItem.EventData.Data flattens that array so each <Data> child becomes its own row -- a long-form representation where one event becomes thirty rows, one per field. Step three: extend Field = tostring(ev["@Name"]), Value = tostring(ev["#text"]) projects the XML attribute and text payload into two typed columns named Field and Value. Step four: evaluate pivot(Field, take_any(Value), TimeGenerated, Computer) invokes the Kusto pivot plugin, which rotates the long-form (Field, Value) rows back into a wide row with one column per field name -- so after the pivot, CommandLine, Image, ParentImage, and ProcessGuid become first-class columns the detection can filter on as if they had been typed all along ^[41]. The same chain adapts to any other EventID (3 / NetworkConnect, 11 / FileCreate, etc.) and, with one less hop, to the typed WindowsEvent table where EventData is already pre-parsed JSON.

Event
| where TimeGenerated > ago(5m)
| where Source == "Microsoft-Windows-Sysmon" and EventID == 1
| extend ev = parse_xml(EventData).DataItem.EventData.Data
| mv-expand ev
| extend Field = tostring(ev["@Name"]), Value = tostring(ev["#text"])
| evaluate pivot(Field, take_any(Value), TimeGenerated, Computer)
| where ParentImage endswith "winword.exe"
  and Image endswith "powershell.exe"
  and CommandLine contains "-EncodedCommand"
| project
    TimeGenerated, Computer, User,
    ParentImage, ParentProcessGuid,
    Image, ProcessGuid, CommandLine, Hashes
| extend
    HostCustomEntity = Computer,
    AccountCustomEntity = User,
    ProcessCustomEntity = ProcessGuid

The five lines after the pivot are the actual detection: an Office process spawning PowerShell with -EncodedCommand. The three *CustomEntity columns at the bottom are what wire this alert into the Defender XDR correlation engine at hop 6 -- they become typed entities on the resulting SecurityAlert row ^[9].

Hop 3 finishes at about 14:03:21 UTC: four seconds after kernel emission, with the row written to the workspace's Event table and indexed for KQL query.

6.4 Hop 4 -- Sentinel analytics rule emits a SecurityAlert#

Microsoft Sentinel supports several detection-rule shapes. The five that matter for understanding the Sysmon pipeline are summarized below, with the timing characteristics that drive end-to-end latency for hop 4.

The five rule shapes and where they fire in the Sysmon path:

For the worked example, the detection runs as a scheduled analytics rule at five-minute cadence. The rule fires at 14:05:00 UTC, the query returns one row matching winword.exe -> powershell.exe -EncodedCommand, and a SecurityAlert is emitted at 14:05:04 UTC. The alert carries the HostCustomEntity, AccountCustomEntity, and ProcessCustomEntity mappings that the rule defined.

// Three alerts arriving from three pipelines, each with entities.
const sentinelAlert = {
source: 'Sentinel',
time: '14:05:04Z',
entities: { Host: 'MAL-CONTOSO-PRD-04',
            Process: '{62b9c5cf-7c64-67ab-2e00-000000003200}' }
};
const mdcAlert = {
source: 'MDC for Servers (via MDE)',
time: '14:07:42Z',
entities: { Host: 'MAL-CONTOSO-PRD-04',
            File: 'powershell.exe' }
};
const mdeAlert = {
source: 'MDE native',
time: '14:08:11Z',
entities: { Host: 'MAL-CONTOSO-PRD-04',
            Process: '{62b9c5cf-7c64-67ab-2e00-000000003200}' }
};
function correlate(alerts, windowMin = 30) {
const byHost = new Map();
for (const a of alerts) {
  const k = a.entities.Host;
  if (!byHost.has(k)) byHost.set(k, []);
  byHost.get(k).push(a);
}
return [...byHost.entries()].map(([host, alts]) => ({
  incidentKey: 'host:' + host,
  alerts: alts.map(a => a.source)
}));
}
console.log(correlate([sentinelAlert, mdcAlert, mdeAlert]));
// -> [{ incidentKey: 'host:MAL-CONTOSO-PRD-04',
//        alerts: ['Sentinel','MDC for Servers (via MDE)','MDE native'] }]

The toy correlator above only keys on Host. The real one also keys on Process (ProcessGuid where present), Account, IP, URL, and FileHash, and uses a sliding window plus a confidence-weighted merge that allows weak entities (file name) to participate when strong entities (ProcessGuid) overlap ^[4]. The result is the same: three alerts in, one incident out.

There is one further detection family worth introducing here because §10's recipe will explicitly avoid it: Defender XDR Custom Detections. These are KQL queries authored not in Sentinel but in the unified portal's advanced hunting surface, and they emit alerts directly into Defender XDR rather than via the SIEM analytics-rule pipeline ^[44]. Custom detections can read DeviceProcessEvents and the rest of the Defender advanced hunting schema, which is fed by the MDE sensor independent of Sysmon. For the worked example, a Custom Detection equivalent to the Sentinel scheduled rule would also have fired -- but it would have fired against MDE's DeviceProcessEvents table, not against Log Analytics Event. The two paths are not interchangeable. Microsoft's documentation is explicit that custom detections operate over the Defender XDR-internal advanced hunting schema, not over arbitrary Log Analytics tables ^{[44] [34]}.

"Custom detection rules are rules you can design and tweak using advanced hunting queries. These rules let you proactively monitor various events and system states, including suspected breach activity and misconfigured endpoints." ^[44]

That is the policy line that decides where to put a new rule: if your query reads from DeviceProcessEvents (MDE feed), it belongs as an advanced-hunting custom detection inside Defender XDR; if your query reads from Sentinel Event or SecurityEvent (Log Analytics feed), it belongs as a Sentinel analytics rule. The recipe in §10 picks the Sentinel side because the worked example begins in Sysmon, not in MDE -- and Sysmon flows to Log Analytics, not to the MDE advanced-hunting schema.

6.5 Hop 5 -- Microsoft Defender for Cloud as the CWPP alert source#

This hop is the most architecturally interesting and the most operationally misunderstood. It is also where the previous iteration of this article had to be corrected on its single most load-bearing detail, so the framing here is deliberate.

Only Microsoft Defender for Cloud's CWPP alerts flow into Defender XDR -- not its CSPM posture findings. A Secure Score recommendation that "VMs should have endpoint protection installed" or "Storage accounts should restrict public access" is a posture finding. A "Suspicious PowerShell command line detected on MAL-CONTOSO-PRD-04" emitted by the Defender for Servers runtime plan is an alert. Defender XDR ingests the alerts; the posture findings stay in the MDC blade ^{[3] [45]}.

The vocabulary first, because everything in this section depends on it.

The CSPM-versus-CWPP distinction has direct operational consequences for what shows up at hop 6:

The CWPP alerts come from MDC's five priced runtime plans. Each plan has its own data path, but they all converge on the same SecurityAlert table in Log Analytics and on the same XDR ingestion path:

For the worked example, the relevant plan is Defender for Servers. Because MDE is installed on the host (Defender for Servers Plan 2 includes the MDE license), the MDE sensor's runtime telemetry feeds into MDC's detection engine and emits the Suspicious PowerShell command line MDC alert at 14:07:42 UTC ^{[11] [54]}. That alert flows to Defender XDR via the MDC-to-XDR alert-ingestion integration that reached general availability in March 2024 (specifically March 13, 2024) ^{[45] [3]}.

The CSPM/CWPP separation also explains the multi-cloud story. MDC's CSPM scope spans Azure, AWS, and GCP via cloud connectors -- you can onboard an AWS account with aws-onboarding and see your S3 buckets in the Secure Score ^[55]. The CWPP plans for non-Azure clouds are narrower: Defender for Servers works on AWS EC2 and on-prem via Azure Arc, Defender for Containers works on EKS and GKE, but several plans (Storage, App Service) are Azure-only. The result is a posture surface that is genuinely multi-cloud and a runtime surface that is mostly Azure-plus-Arc -- which is the layer that actually flows to XDR at hop 6 ^[22].

6.6 Hop 6 -- The Defender XDR correlation engine and the fan-in#

The last hop is the merge. The Defender XDR correlation engine reads incoming alerts from all source pipelines, normalizes the entity values they carry, and groups alerts whose entities overlap within a sliding time window into a single incident. The grouping is asymmetric: a higher-confidence alert (e.g., an MDE process-tree alert with a strong ProcessGuid) can pull in lower-confidence alerts (e.g., a Sentinel rule whose only entity is Host), but not vice-versa ^[4].

The geometry of the fan-in for the worked example is the mirror image of the fan-out in section 5. The same three alerts that arrived at three different timestamps now converge on a single incident object I-7842:

{<code>sequenceDiagram     autonumber     participant SEN as Sentinel SecurityAlert     participant MDC as MDC SecurityAlert     participant MDE as MDE DeviceAlertEvents     participant COR as Defender XDR correlator     participant INC as Incident I-7842     SEN->>COR: Host MAL-... ProcessGuid abc at 14:05:04     MDC->>COR: Host MAL-... File powershell.exe at 14:07:42     MDE->>COR: Host MAL-... ProcessGuid abc at 14:08:11     Note over COR: match window ≤ 30 min     COR->>INC: open incident, attach Sentinel alert     COR->>INC: merge: MDE matches on ProcessGuid     COR->>INC: merge: MDC matches on Host within window     INC-->>SEN: backlink to source alert     INC-->>MDC: backlink to source alert     INC-->>MDE: backlink to source alert</code>}

Three things deserve explicit attention in this fan-in:

1. The strong-entity priority. The MDE alert and the Sentinel alert share ProcessGuid. Microsoft documents that field as a unique value designed to make event correlation easier across hosts and domains ^[1]. The merge between them is unambiguous. The MDC-from-Servers alert only carries Host and File -- the MDC plan's alert grammar does not necessarily emit ProcessGuid even though the underlying MDE sensor knows it. The MDC alert merges into the incident on the weaker Host match within the time window.

2. The Microsoft-managed thresholds. The correlation window, the entity-priority rules, and the merge logic are not exposed for customer tuning. They are documented at the policy level -- "alerts that share entities within a time window" -- but the exact heuristics are part of the Defender XDR service ^[4]. §9 returns to this opacity as an open problem.

3. What does NOT merge. Some categories of source data stay outside the incident graph even when they ought to: cross-workspace Sentinel rules (alerts in a workspace other than the Defender-XDR-connected "primary" one), third-party connector alerts that lack entity mappings, and -- as already underlined -- MDC posture findings of every kind ^[3].

For the worked example, hop 6 completes at 14:09:30 UTC: the SOC analyst sees a single incident in their queue, titled Multi-stage incident on one endpoint, with three correlated alerts on its alerts tab, a unified entity graph showing the host, the user, the parent and child processes, the file hash, and the URL embedded in the encoded command line, and one-click pivots to the MDE timeline, the Sentinel investigation graph, and the MDC alert detail. Three pipelines, one analyst surface, nine minutes thirteen seconds end-to-end.

That is the full path. The next three sections compare it to what other vendors do, name the theoretical limits any such pipeline has to live with, and walk the open problems that even the best-tuned version of this pipeline still faces.

7. Competing approaches: inside and outside the Microsoft fence#

The architecture in §6 is one answer to "how do I turn endpoint telemetry into a SOC incident." It is not the only answer. Other detection engines exist both inside Microsoft and outside, with materially different design choices that are useful to compare side-by-side.

Inside Microsoft, six detection engines run on roughly the same data over the same workspace -- and an architect picking where to put a new detection has to know what each one optimizes for.

The takeaway is that Sentinel and Defender XDR custom detections are not interchangeable. They read from different schemas (Log Analytics tables vs MDE advanced-hunting tables), they have different governance models (Azure RBAC vs Defender role-based access), and they emit alerts via different paths. The right engine depends on where your telemetry lives. For the worked example, Sysmon in Event is reached by Sentinel, not by Custom Detections; MDE's DeviceProcessEvents for the same host is reached by Custom Detections, not by Sentinel scheduled rules.

Outside Microsoft, the six widely-deployed alternative stacks each make different trade-offs:

The structural difference that matters most across these stacks is where the storage and query engine live. Splunk on-prem owns its full stack and bills on ingest. Elastic gives you the stack and lets you self-host or buy SaaS. Google SecOps removes the per-GB axis entirely and bills per employee, betting that the value of the SOC is the analyst's time, not the byte count. AWS Security Lake decomposes further than Microsoft does, exposing S3 directly so you can bring any analytics engine. Microsoft's design point -- KQL over Log Analytics with grafted XDR correlation -- sits in the middle: more managed than AWS, more opinionated than Elastic, billed per-GB like Splunk but with separable axes.

There is also a migration option worth knowing about. Microsoft introduced a Sentinel SIEM migration experience in 2024 that uses generative AI to translate detection rules from Splunk SPL to KQL ^[59]. The tool is not a complete replacement for human review of every translated rule, but it materially shortens the migration spike that has historically blocked SOCs from switching SIEMs. The existence of such a tool is itself evidence that the SIEM market is becoming more substitutable than it once was -- a SOC's investment in detection logic is no longer locked to one vendor's query language.

For the worked example specifically, every one of the alternative stacks could in principle deliver the same end result -- one incident for a parent-child process-spawn detection. The differences are in the operating model: who owns the storage, who owns the agent, who priced the ingest, and how easily the analyst can pivot from the incident into raw telemetry. Microsoft's pitch with the unified secops platform is that "all of the above are in one portal." The honest reading is "the Microsoft-side ones are in one portal, and the third-party feeds you stream into Sentinel still participate via the same SecurityAlert table."

8. Theoretical limits#

The six-hop pipeline is mostly an engineering object. But it inherits a few honestly theoretical limits that no amount of clever product design can defeat. Naming them sharply is the difference between an architect who knows what the system cannot do and a buyer who is surprised.

The first hard limit is that entity resolution across pipelines is structurally probabilistic whenever the strong identifiers are missing. The Defender XDR correlator depends on entity overlap; the worked example merged cleanly because ProcessGuid was shared between MDE and Sentinel. Take that identifier away and the merge falls back on Host, which is shared but ambiguous (hostnames are reused, machine accounts get recycled), and ultimately on weaker identifiers like file name or command-line substring. The table below names what identifiers each source pipeline can be relied upon to carry.

The second hard limit is normalization lossiness. ASIM (Advanced Security Information Model), Microsoft's effort to normalize Sentinel data into common schemas like _Im_ProcessCreate, makes cross-source queries dramatically easier -- but the normalization is lossy. Fields that exist only in Sysmon (such as the Sysmon-specific IntegrityLevel value, or the OriginalFileName from the PE manifest) get dropped on the way into the normalized schema ^[60]. The trade-off is honest and inescapable: a normalized schema is a projection from a richer per-source schema, and projections lose data by construction.

We can sketch this formally. If $S$ is the per-source schema (a set of fields), $N$ is the normalized schema, and $\pi: S \to N$ is the projection (the ASIM mapping), then the information loss on a single record $r$ is

where $H$ is the entropy (number of bits) of the record. For a Sysmon ProcessCreate row, $H(r)$ is roughly $\log_2 |S|$ bits over a thirty-field schema (call it ~150-200 bits of effective entropy after compression of correlated fields); $H(\pi(r))$ is around half that after mapping into the much smaller normalized _Im_ProcessCreate schema. The dropped bits are exactly the fields you cannot query in the normalized form. ASIM is good for cross-source detections that need only common fields; per-source detections that need the long tail of source-specific fields must query the raw source table directly.

The third limit is temporal alignment. Each pipeline has its own clock: Sysmon timestamps come from the host kernel, MDC alerts from the MDC service back-end, Sentinel TimeGenerated from the workspace ingestion. Within a single host these clocks are usually close (NTP-synced), but across hosts and across pipelines they can drift by seconds or minutes. The correlator's "within a time window" merge has to tolerate this drift, which means the window has to be larger than the worst-case clock skew. A larger window means more false-positive merges. There is no way out of this trade-off; only operational tuning between sensitivity and specificity.

The fourth limit is rule expressiveness ceiling. KQL is Turing-complete in the sense that any computable detection can be expressed if you are willing to write enough of it -- but Sentinel scheduled rules cap query duration, query result size, and join cardinality. Detections that conceptually want to scan a year of data and join against a separately-changing IOC list are expressible in KQL but not runnable under Sentinel rule limits. Custom ADX clusters or Spark-on-Synapse can run such queries, at the cost of leaving the unified portal entirely.

These are the limits any honest architecture has to live with. The Microsoft pipeline does well on the first (when strong identifiers exist), is honest about the second (ASIM is documented as a normalization, not a transparent overlay), tolerates the third (windowed merge), and surfaces the fourth as a Sentinel pricing-and-scope conversation. None of them is a Microsoft-specific defect. They are properties of the problem.

9. Open problems#

The pipeline is fast enough, accurate enough, and -- in the worked example -- correct. It is not finished. Seven open problems remain, in roughly decreasing order of how much they hurt a working SOC today.

1. The Sentinel-Azure-portal cutover is on a hard date. Microsoft has announced the retirement of the Microsoft Sentinel experience in the Azure portal effective March 31, 2027 (extended from the original July 1, 2026 target) ^{[30] [31]}. After that date, Sentinel can only be operated through the unified Defender portal at security.microsoft.com. The cutover affects analytics-rule authoring (the Azure-portal rule wizard goes away), automation rules, watchlists, and the investigation graph. Customers with custom dashboards, ARM templates, or automation that targets the Azure-portal Sentinel surface must port them. This is the most concrete migration deadline in this article.

2. CWPP-to-XDR coverage is still expanding. As of the documented integration scope, MDC for Servers, Containers, SQL, Storage, and App Service alerts flow to Defender XDR ^{[3] [45]}. New CWPP plans (e.g., Defender for APIs as it matures) tend to land first in the MDC blade and only later in the unified incident graph. Customers operationalizing a new MDC plan should check the integration documentation for that specific plan rather than assuming XDR ingestion is automatic.

3. Posture-finding context still lives in a separate blade. As §6.5 established, MDC posture findings do not flow to Defender XDR. A SOC analyst looking at an incident on a host has no incident-side way to see "this host also has a CSPM finding for missing endpoint protection." The workaround is to join SecurityRecommendation against the incident-affected resources via KQL, or to pivot manually to the MDC blade. A first-class "posture context on incident" feature does not exist as of the documented surface area.

4. The correlation engine's heuristics are not user-tunable. The Defender XDR correlation engine merges alerts using a Microsoft-managed set of thresholds: time window, entity priority, confidence weighting ^[4]. These are not exposed for customer override. A SOC that wants to widen the merge window (because their telemetry has long ingest tails) or tighten the entity-priority (because they distrust hostname matches for shared-name VMs) has no knob to turn. The correlation behaviour is whatever Microsoft ships; tuning happens by raising support cases against perceived false-merges or false-splits.

5. Custom detection semantics are subtly different from Sentinel rule semantics. A KQL detection authored as a Defender XDR Custom Detection runs over the advanced-hunting schema (DeviceProcessEvents, DeviceFileEvents, etc.), not over Log Analytics tables ^{[44] [34]}. The two schemas overlap (you can write conceptually similar detections over both), but the field names, the freshness windows, and the result-size caps differ. An organization with parallel teams authoring detections in both surfaces can end up with two near-duplicate detections that drift apart over time. There is no first-class deduplication or "promote this Sentinel rule to a Custom Detection" workflow.

6. Logic Apps write-back from Sentinel to MDC has rough edges. Sentinel automation rules can invoke Logic Apps playbooks to take response actions ^{[61] [16]}. Writing back to MDC -- for example, suppressing an alert in MDC or creating a Defender for Cloud assessment programmatically -- is possible but requires the playbook to call the MDC REST API directly ^[62]. There is no native "MDC action" connector with the breadth of the MDE actions connector. Customers building bidirectional response automation between Sentinel and MDC end up writing HTTP-action playbooks by hand. The MDC REST API for assessments lets you create and update assessment results programmatically, but the surface area for writing back to MDC (e.g., dismissing or recategorizing an alert) is smaller than the read API and is not symmetric with Sentinel's native alert-lifecycle actions ^{[62] [63]}. Closing this gap with a first-class connector is on most enterprise customers' wish lists.

7. Multi-workspace and multi-tenant topologies remain awkward. The unified secops experience connects Defender XDR to exactly one Sentinel primary workspace per tenant. Customers with multiple workspaces -- common in regulated industries with data-residency boundaries -- must choose which workspace is the XDR-connected one, and accept that the other workspaces' alerts are visible only inside Sentinel, not in the unified incident graph ^{[56] [57]}. Multi-tenant MSSPs and customers with subsidiaries on separate Azure tenants face an even harder design problem: there is no single pane across tenants in the unified portal, only the cross-workspace KQL pattern from §4.

8. Multicloud entity resolution: the EC2-on-AWS case. A Windows VM running as an AWS EC2 instance can be brought into Microsoft's stack through two layers, neither of which produces a single shared identifier. Defender for Cloud's multicloud connector ingests AWS CloudTrail and EC2 metadata into MDC's posture surface (CSPM coverage) ^[64]; Defender for Servers' Arc-based provisioning then installs Azure Monitor Agent and Microsoft Defender for Endpoint on the EC2 host, projecting the box into the Azure tenant's resource graph as an Microsoft.HybridCompute/machines Arc resource. Three identifiers therefore describe the same physical workload but never coincide on a single strong identifier: (1) the EC2 ARN arn:aws:ec2:<region>:<account>:instance/<instance-id>, which is what AWS CloudTrail and the AWS console use; (2) the Arc machine resource ID /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.HybridCompute/machines/<arc-machine-name>, which is what the Log Analytics _ResourceId column carries when AMA forwards the Sysmon event; (3) the MDE DeviceId, a GUID assigned at MDE first-onboarding, which is what the Defender for Servers CWPP alert and the DeviceInfo advanced-hunting table key on. Bridging the three at query time requires bespoke KQL: lift the Arc machine name from _ResourceId via extend ArcMachine = tostring(split(_ResourceId, "/")[-1]), look up the corresponding DeviceId in DeviceInfo keyed by DeviceName, and join to a customer-maintained Watchlist (or external CMDB) that maps Arc machine name -> EC2 instance-id -> EC2 ARN. The pattern works, but every join is a place where the inventory can drift; a renamed EC2 instance or a reimaged host that picks up a new MDE DeviceId will silently break correlation until the watchlist is refreshed.

None of these problems is fatal to the architecture. Each is the kind of structural friction that comes from grafting three pre-existing pipelines into one analyst surface in fewer than three years. The cutover date is the only one with a deadline; the rest are roadmap items.

10. Recipe: building the pipeline yourself in six steps#

This section walks the six setup steps that produce the worked example end-to-end, in the order an engineer should actually do them. Each step names the artifact, the documentation reference, and the single most common mistake that will silently break the step.

Step 1 -- Install Sysmon with a curated configuration#

Install Sysmon on the host (Azure VM, Arc-enabled server, or on-prem Windows) with a configuration that emits the events you actually need ^[1]. The default Sysmon config is essentially empty; a curated config is what makes it useful. Many teams start with the SwiftOnSecurity sysmon-config or Olaf Hartong sysmon-modular public baselines and prune from there ^{[65] [66]}.

Validate that Sysmon is emitting by reading the local event log on the host: Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 5. If you see ProcessCreate (Event ID 1) records, hop 1 works.

Step 2 -- Deploy the Azure Monitor Agent with a Data Collection Rule#

Install AMA on the host (via Azure Policy for Azure VMs, the Arc agent for non-Azure, or the standalone installer) ^[2]. Then create a Data Collection Rule that names the Sysmon channel and ships it to your Sentinel-enabled workspace. The ARM snippet below is the load-bearing artifact: the streams value must be exactly Microsoft-WindowsEvent (or, for the older Event table path, Microsoft-Event), not a variant. This is the silent-failure cliff §6.2 named: get this string wrong and the agent ships nothing, returning no error.

{
  "type": "Microsoft.Insights/dataCollectionRules",
  "apiVersion": "2022-06-01",
  "name": "dcr-sysmon-to-sentinel",
  "location": "eastus",
  "properties": {
    "dataSources": {
      "windowsEventLogs": [
        {
          "name": "sysmonOperational",
          "streams": ["Microsoft-WindowsEvent"],
          "xPathQueries": [
            "Microsoft-Windows-Sysmon/Operational!*[System[(EventID=1 or EventID=3 or EventID=7 or EventID=10 or EventID=11)]]"
          ]
        }
      ]
    },
    "destinations": {
      "logAnalytics": [
        { "name": "lawDest",
          "workspaceResourceId":
            "/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.OperationalInsights/workspaces/law-contoso-secops" }
      ]
    },
    "dataFlows": [
      { "streams": ["Microsoft-WindowsEvent"],
        "destinations": ["lawDest"] }
    ]
  }
}

The silent-miss bug is real: a DCR that names "Microsoft-Event" ships into the older Event table; a DCR that names "Microsoft-WindowsEvent" ships into the newer typed WindowsEvent table; a DCR that names anything else (typo, copy-paste from another data source, or a name that does not exist) emits nothing, returns no validation error at deploy time, and produces a silent dashboard hole ^{[5] [26]}. The fix is to validate post-deploy by checking that rows are arriving in the destination table within ~5 minutes.

Validation KQL to run in the workspace:

Event
| where TimeGenerated > ago(10m)
| where Source == "Microsoft-Windows-Sysmon" and EventID == 1
| summarize count() by Computer

If you see a row per Sysmon-emitting host, hop 2 and hop 3 work.

Step 3 -- Author the Sentinel scheduled analytics rule#

Inside the Defender portal's Sentinel section (or the Azure-portal Sentinel blade until the March 31, 2027 cutover), create a new scheduled analytics rule ^{[8] [30]}. Paste the KQL from the Spoiler in §6.3. Configure entity mappings: Host from Computer, Account from User, Process from ProcessGuid. Schedule: run every 5 minutes over the last 5 minutes. Severity: Medium. Tactic: Execution (MITRE ATT&CK T1059.001).

The single most common mistake at this step is omitting the entity mappings. The rule will fire and produce a SecurityAlert row, but the alert will not participate in cross-pipeline correlation at hop 6 because there are no entities to merge on. Always configure at least Host, Account, and -- when available -- Process or FileHash entity mappings on a Sentinel rule.

Step 4 -- Enable Defender for Servers (Plan 2) for MDC alerts#

On the Azure subscription that owns the VM (or the Arc-enabled resource group), enable Microsoft Defender for Cloud's Defender for Servers Plan 2 ^[10]. Plan 2 includes the MDE license and the runtime detection engine that emits the MDC alert at hop 5. Enabling the plan automatically deploys MDE to the in-scope hosts and configures the MDC-to-XDR alert-ingestion integration that reached general availability in March 2024 ^{[11] [45]}.

Validation: trigger a benign test pattern (e.g., powershell -EncodedCommand of a harmless script) on a test host. Within ~5 minutes, you should see an MDC alert in the MDC Alerts blade titled Suspicious PowerShell command line (or similar), and a corresponding alert in security.microsoft.com.

Step 5 -- Connect Sentinel to the unified Defender portal#

Inside the Defender portal, enable the Sentinel connection that designates your Log Analytics workspace as the primary workspace for the unified secops experience ^{[72] [57]}. This step is what makes the Sentinel SecurityAlert rows flow into the Defender XDR incident graph at hop 6 and become merge candidates with the MDC and MDE alerts.

One-tenant, one-primary-workspace constraint: as §6.6 noted, a Defender XDR tenant has exactly one primary Sentinel workspace. If you have multiple workspaces (regional residency reasons, MSSP topology, etc.), choose deliberately which one is the XDR-connected one. Alerts in secondary workspaces remain queryable via Sentinel but do not participate in the unified incident graph.

Step 6 -- Write a watchdog rule that fires on telemetry silence#

The pipeline can fail silently in multiple places: AMA stops on a host, the DCR is removed or mis-edited, Sysmon is uninstalled, the workspace fills its daily cap. None of these failures produce an alert by themselves. Write a Sentinel scheduled rule that fires when expected telemetry is absent: for each host in your inventory, alert if Event table rows from that host stop appearing for more than N minutes.

# Run via Azure Monitor REST API or the az monitor cli; here we simulate
# the comparison logic that an analytics rule would express in KQL.

EXPECTED_INVENTORY = {
  'MAL-CONTOSO-PRD-01',
  'MAL-CONTOSO-PRD-02',
  'MAL-CONTOSO-PRD-03',
  'MAL-CONTOSO-PRD-04',
  'MAL-CONTOSO-PRD-05',
}

# In a real deployment this list comes from KQL against the Event table:
#   Event | where TimeGenerated > ago(24h)
#         | summarize by Computer
RECENTLY_EMITTING_HOSTS = {
  'MAL-CONTOSO-PRD-01',
  'MAL-CONTOSO-PRD-02',
  # PRD-03 absent: agent down? DCR removed?
  'MAL-CONTOSO-PRD-04',
  'MAL-CONTOSO-PRD-05',
}

silent_hosts = EXPECTED_INVENTORY - RECENTLY_EMITTING_HOSTS
if silent_hosts:
  print(f"ALERT: telemetry silence on {len(silent_hosts)} host(s):")
  for h in sorted(silent_hosts):
      print(f"  - {h}")
else:
  print("OK: all expected hosts emitted Sysmon events in the last 24h.")

The equivalent in Sentinel is a scheduled rule that joins a static Watchlist of expected hosts against Event | summarize by Computer over the last 24 hours and alerts on the set difference. This watchdog is the only thing standing between an architectural diagram of perfect convergence and the operational reality of one host's silent agent.

With these six steps the Sysmon record from §1 reaches security.microsoft.com in roughly nine minutes, three alerts merged into one incident. The pipeline is real. The next section addresses the questions that show up in every architecture-review meeting once the pipeline is built.

11. FAQ#