Sentinel Fusion ML Detection Scenarios

Fusion is a built-in, machine learning-based detection engine in Microsoft Sentinel that correlates alerts from multiple security products (e.g., Microsoft Defender for Cloud, Azure Active Directory Identity Protection, Microsoft 365 Defender) to identify multi-stage attacks. It consumes low-fidelity alerts—each individually may be a false positive—and produces high-fidelity incidents that represent a likely real attack. Fusion reduces alert fatigue by presenting security operations center (SOC) analysts with a single incident instead of dozens of separate alerts. On the SC-200 exam, you must know that Fusion is enabled by default and cannot be entirely disabled via the UI—only specific sources can be excluded.

Fusion operates through a multi-step pipeline: 1. Ingestion: Sentinel collects alerts from connected data sources. Fusion only processes alerts from specific Microsoft security products, not third-party sources. The supported sources include: Azure Active Directory Identity Protection, Microsoft Defender for Cloud (formerly Azure Security Center), Microsoft Defender for Endpoint, Microsoft Defender for Identity, Microsoft Defender for Office 365, Microsoft Cloud App Security, and Microsoft 365 Defender. Third-party alerts (e.g., from Syslog, CEF, or custom connectors) are NOT processed by Fusion. 2. Pre-processing: Alerts are normalized into a common schema. Fusion extracts key fields: alert type, severity, timestamp, affected entities (users, IPs, devices), and kill-chain stage. Alerts with severity 'Informational' are typically ignored. 3. Correlation: Fusion uses pre-trained machine learning models to find patterns across alerts. The models are trained on millions of real-world attack patterns and known multi-stage attack chains (e.g., credential theft followed by lateral movement). Fusion does NOT require custom training; the models are updated automatically by Microsoft. 4. Scoring: Each correlated set of alerts receives a confidence score. If the score exceeds a threshold (internal, not configurable), Fusion generates a single incident. The incident includes a fusion signal (a unique identifier) and a detailed description of the attack chain. 5. Incident Creation: The incident is created in Sentinel with severity based on the highest severity among correlated alerts. The incident contains all source alerts as entities. Fusion incidents have a special 'Fusion' source in the incident details.

Fusion is configured via the Azure portal under Sentinel -> Analytics -> Rule templates. To verify Fusion incidents:

PowerShell/CLI: There is no direct command to modify Fusion; use Azure Resource Manager REST API or Azure CLI with the Sentinel workspace. Example Azure CLI to list Fusion rule:

az sentinel alert-rule list --resource-group <rg> --workspace-name <workspace> --query "[?kind=='Fusion'].{name:name, enabled:enabled}"

Fusion works alongside other Sentinel analytics: - Scheduled Analytics Rules: These generate alerts from KQL queries. Fusion can consume these alerts if they are from supported sources? Actually, Fusion only consumes alerts from Microsoft security products, not from custom scheduled rules. This is a common exam trap: custom alerts do NOT feed into Fusion. - NRT (Near-Real-Time) Rules: Same as scheduled; not consumed by Fusion. - Behavioral Analytics (UEBA): UEBA in Sentinel provides user and entity behavior analytics. Fusion does NOT directly use UEBA; they are separate detection methods. However, both can generate incidents independently. - Microsoft 365 Defender: Alerts from M365D (e.g., incidents from Defender for Endpoint) are ingested into Sentinel and can be correlated by Fusion.

In the Azure portal, navigate to Sentinel -> Analytics -> Active rules. Find the 'Advanced Multistage Attack Detection' rule. Click on it and select 'Edit'. In the rule configuration, you will see a list of source products with checkboxes. Uncheck the ones you want to exclude. You can also use PowerShell or REST API to update the rule's sourceSettings.

A global enterprise with 50,000 employees uses Microsoft 365, Azure, and Defender for Endpoint. The SOC receives over 10,000 alerts per day from these sources, most of which are low-fidelity false positives (e.g., sign-ins from unfamiliar locations, anomalous file downloads). The SOC was overwhelmed and missing real attacks. By enabling Fusion (default), the SOC saw a 70% reduction in incidents because Fusion correlated related alerts into a single incident. For example, a 'Impossible travel' alert from Azure AD Identity Protection combined with a 'Malware detected' alert from Defender for Endpoint on the same user within 10 minutes became a single 'Credential theft and malware deployment' incident. The SOC now focuses on Fusion incidents first, which have a much higher true positive rate. Configuration: The SOC excluded Microsoft Cloud App Security alerts from Fusion because those were generating too many false correlations with Defender alerts. This was done by editing the Fusion rule and unchecking Cloud App Security.

A financial services company uses Sentinel to monitor its hybrid environment. An attacker compromised a user's credentials via a phishing email (detected by Defender for Office 365 as 'Phish delivered'). The attacker then used those credentials to access a SharePoint site (alert from Microsoft Cloud App Security: 'Unusual file access pattern'). Finally, the attacker attempted to exfiltrate data via an external share (alert from Defender for Cloud Apps: 'Mass download'). Without Fusion, these three alerts would appear as separate incidents, and the SOC might miss the connection. Fusion correlated them into a single incident: 'Phishing followed by data exfiltration attempt'. The incident severity was set to Critical because one of the alerts was Critical. The SOC was able to contain the threat within minutes. The company also uses Fusion to feed incidents into its SIEM (via Sentinel's API) for further automation.