This chapter covers Fusion ML (Machine Learning) detection rules in Microsoft Sentinel, a critical topic for the SC-200 exam under Objective 2.3 (Configure and manage analytics rules). Fusion is a built-in, advanced analytics rule that uses machine learning to correlate alerts across multiple products into high-fidelity incidents. Understanding Fusion is essential because it appears in approximately 5-10% of exam questions, often testing your knowledge of its behavior, configuration limitations, and how it differs from other analytics rules. By the end of this chapter, you will understand the internal mechanism of Fusion, how to configure it, and how to interpret its output—key skills for both the exam and real-world security operations.
Jump to a section
Think of Microsoft Sentinel's Fusion ML detection as an advanced fire detection system in a large office building. Traditional detection rules (like simple analytics) are individual smoke detectors: each one triggers an alarm when smoke reaches a certain threshold in its specific room. But a sophisticated fire detection system doesn't just rely on individual detectors. It integrates data from multiple sensors—heat sensors, smoke detectors, carbon monoxide detectors, and even camera feeds—and uses a central AI to analyze patterns. For example, a smoke detector in the kitchen might trigger due to burnt toast, but the AI also checks if the heat sensor shows a rapid temperature rise and if the camera detects flames. Only when multiple correlated signals cross a learned threshold does it declare a real fire, avoiding false alarms from burnt toast. Similarly, Fusion ML in Sentinel correlates alerts from different sources (e.g., Defender for Endpoint, Defender for Identity, Azure AD logs) and uses machine learning to identify multi-stage attacks like ransomware or lateral movement. It learns what 'normal' alert patterns look like and flags only anomalous combinations. Just as the fire system reduces false positives by requiring corroboration, Fusion reduces alert fatigue by surfacing only high-fidelity incidents that represent genuine threats, not isolated suspicious events.
What is Fusion ML Detection?
Fusion is a type of analytics rule in Microsoft Sentinel that leverages machine learning to correlate multiple low-fidelity alerts from various Microsoft security products into a single, high-fidelity incident. It is designed to detect multi-stage attacks (e.g., ransomware, lateral movement, data exfiltration) that span across different kill chain phases. Unlike scheduled or near-real-time rules that match specific query patterns, Fusion uses ML models trained on Microsoft's global threat intelligence and telemetry to identify anomalous alert combinations.
How Fusion Works Internally
Fusion operates as a continuous background process within Sentinel. It ingests alerts from connected Microsoft security services such as:
Microsoft Defender for Endpoint (MDE)
Microsoft Defender for Identity (MDI)
Microsoft Defender for Office 365 (MDO)
Microsoft Defender for Cloud Apps (MDCA)
Azure Active Directory Identity Protection (AADIP)
These alerts are fed into a machine learning pipeline that: 1. Groups alerts by entity – Fusion groups alerts that share common entities (user, IP, device, etc.) into a candidate incident. 2. Extracts features – For each group, it extracts hundreds of features such as alert severity, alert type, time proximity, entity risk scores, and historical patterns. 3. Scores the group – A trained ML model assigns a probability score that the group represents a real attack. The model is a gradient-boosted decision tree (LightGBM) trained on millions of alerts from Microsoft's global infrastructure. 4. Threshold comparison – If the score exceeds a dynamic threshold (which adapts based on the environment's false positive rate), Fusion creates an incident.
Key Components and Defaults
Rule Type: Fusion is a Microsoft rule (not custom). It is enabled by default in all Sentinel workspaces.
Data Sources: Only alerts from Microsoft security products are used. Third-party alerts (e.g., from Syslog or CEF) are not correlated by Fusion.
Incident Creation: Fusion creates incidents with a severity of Medium, High, or Low based on the ML score. The incident includes a Fusion signature (e.g., "Fusion: Ransomware detection") and a detailed description of the attack chain.
Tuning: You cannot modify the ML model or its thresholds directly. However, you can use incident suppression rules to automatically close Fusion incidents that are false positives (e.g., from known benign activity).
Limitations: Fusion does not correlate with custom analytics rules or non-Microsoft data sources. It also cannot be duplicated or disabled individually—only enabled/disabled as a whole.
Configuration and Verification
To verify Fusion is enabled: 1. In Sentinel, navigate to Analytics > Rule templates. 2. Search for "Fusion" – you will see a rule template named "Advanced Multistage Attack Detection". 3. Click on it and select Create rule (if not already created). 4. In the wizard, you can enable/disable Fusion. No other configuration is available.
To view Fusion incidents:
Go to Incidents in Sentinel.
Filter by Product name = "Azure Sentinel" and Rule ID containing "Fusion".
Alternatively, use the following KQL query to find Fusion incidents:
SecurityIncident
| where RuleId contains "Fusion"
| project TimeGenerated, IncidentNumber, Title, Severity, DescriptionInteraction with Related Technologies
Fusion works alongside other analytics rules: - Scheduled rules: These can trigger on specific events, but Fusion may correlate their output if they produce alerts (only if they are from Microsoft products). - NRT rules: Near-real-time rules are similar to scheduled but with lower latency. Fusion does not use NRT alerts directly; it only uses alerts from the built-in connectors. - Anomaly rules: Anomaly rules (e.g., UEBA) produce alerts that can be ingested by Fusion if they are from Microsoft sources.
Fusion also integrates with Automation rules and Playbooks. For example, you can create an automation rule that runs a playbook when a Fusion incident is created, such as isolating a compromised device or disabling a user account.
Machine Learning Model Details
Training Data: The model is trained on alerts from Microsoft's global customer base, with labels from Microsoft's security research team.
Features: Over 1000 features including alert types, entity relationships, time deltas, and historical false positive rates.
Threshold: The threshold is dynamic and adjusts based on the false positive rate in your environment. If too many false positives are observed, the threshold increases automatically.
Model Refresh: The model is updated periodically (every few weeks) by Microsoft to adapt to new attack patterns.
Exam-Relevant Details
Fusion is the only ML-based analytics rule in Sentinel (as of exam date).
It cannot be customized; you can only enable/disable it.
It correlates alerts only from Microsoft security products.
It creates incidents automatically; you cannot modify the incident creation logic.
The rule template is named "Advanced Multistage Attack Detection".
Fusion incidents have a distinct RuleId containing "Fusion".
You can suppress false positives using incident suppression rules (not by editing the rule).
Fusion does not support third-party data sources (e.g., AWS, GCP, Palo Alto).
Enable Fusion Rule
Navigate to Sentinel > Analytics > Rule templates. Locate 'Advanced Multistage Attack Detection' (Fusion). Click 'Create rule' to enable it. This activates the ML pipeline. Ensure that the required data connectors (MDE, MDI, MDO, MDCA, AADIP) are connected and sending alerts. Without these, Fusion will have no input and will not generate incidents.
Ingest Alerts from Microsoft Sources
Fusion relies on alerts from Microsoft security products. These alerts are generated by the respective products and sent to Sentinel via their connectors. For example, MDE sends endpoint detection alerts, MDI sends identity alerts, and AADIP sends risk alerts. Each alert contains entities (user, device, IP) and a severity level. Fusion groups alerts by common entities.
ML Model Correlates Alerts
The Fusion engine collects alerts over a sliding window (default 24 hours). It groups alerts that share entities (e.g., same user or device). For each group, it extracts features and runs the ML model. The model outputs a score between 0 and 1. If the score exceeds the dynamic threshold (typically around 0.8), the group is flagged as a potential multi-stage attack.
Incident Creation with Fusion Signature
When a group scores above threshold, Fusion creates an incident in Sentinel. The incident title includes 'Fusion:' followed by the attack type (e.g., 'Fusion: Ransomware with lateral movement'). The incident description lists the correlated alerts and the attack chain. Severity is set based on the score (High for >0.95, Medium for >0.8, Low for >0.6).
Respond Using Automation
Fusion incidents can trigger automation rules. For example, you can create a rule that runs a playbook to isolate a compromised device or reset a user's password. Automation rules can be scoped to specific Fusion signatures. This step is optional but recommended for efficient incident response. Fusion itself does not automate response; it only creates incidents.
Scenario 1: Ransomware Attack Detection
A large enterprise with 10,000 endpoints uses Microsoft Defender for Endpoint and Defender for Identity. An attacker gains initial access via a phishing email (detected by MDO as a malicious link click). They then install Cobalt Strike on a workstation (MDE alerts on suspicious process). The attacker uses stolen credentials to move laterally to a domain controller (MDI alerts on anomalous logon). Fusion correlates these three alerts: the user clicked a malicious link, then a process was created on that user's device, then the same user logged into a DC from an unusual IP. The ML model scores this as a high-confidence ransomware precursor, creating a Fusion incident titled 'Fusion: Ransomware with lateral movement'. The SOC team receives one incident instead of three separate alerts, reducing alert fatigue.
Scenario 2: Data Exfiltration via Cloud App
A company uses Microsoft Defender for Cloud Apps (MDCA) and Azure AD Identity Protection. An insider threat downloads sensitive files from SharePoint Online (MDCA alerts on unusual download). Simultaneously, the user authenticates from a new location (AADIP alerts on anonymous IP). Fusion correlates these alerts because they share the same user entity. The ML model identifies this as a potential data exfiltration attempt, creating a Fusion incident. The SOC can investigate and block the user's access using a playbook.
Misconfiguration Pitfalls
Common mistakes include disabling Fusion due to initial false positives (e.g., from noisy MDI alerts). Instead of disabling, use incident suppression rules to close specific patterns. Another mistake is expecting Fusion to correlate with third-party alerts; it does not. Also, some administrators try to edit the Fusion rule, which is not possible. The only configuration is enable/disable. Performance-wise, Fusion scales automatically; no tuning is needed. However, if you have a very small environment (e.g., only 10 users), Fusion may produce fewer incidents due to low alert volume.
Exam Objective: SC-200 Objective 2.3 – Configure and manage analytics rules
Fusion is specifically tested under 'Manage analytics rules' and 'Configure built-in analytics rules'. Expect 1-2 questions on Fusion.
Common Wrong Answers and Why
'Fusion can be customized to use custom ML models' – Wrong. Fusion uses Microsoft's pre-built ML model; you cannot customize it. Candidates confuse Fusion with custom analytics rules that use KQL.
'Fusion correlates with third-party alerts' – Wrong. Fusion only uses alerts from Microsoft security products. Candidates assume because Sentinel ingests third-party data, Fusion uses it; it does not.
'Fusion can be disabled per attack type' – Wrong. You can only enable/disable the entire Fusion rule. Some think you can disable specific ML detections; this is not supported.
'Fusion uses scheduled queries' – Wrong. Fusion is a separate rule type (Microsoft rule) that runs continuously, not on a schedule. Candidates confuse it with scheduled query rules.
Exam Numbers and Values
Rule template name: 'Advanced Multistage Attack Detection'
Data sources: Microsoft security products only (MDE, MDI, MDO, MDCA, AADIP)
Severity: High, Medium, Low (automatic)
Incident title prefix: 'Fusion:'
Configuration: Only enable/disable; no other settings
Suppression: Use incident suppression rules, not rule editing
Edge Cases
If no Microsoft security products are connected, Fusion will never create incidents.
Fusion can create incidents even if the alerts are from different products (e.g., MDE + MDI).
Fusion incidents can have multiple alert groups if the same entities are involved in separate attack chains.
How to Eliminate Wrong Answers
Focus on the limitations: Fusion is a Microsoft-only, non-customizable, always-on rule. If an answer suggests customizing thresholds, using third-party data, or disabling specific detections, it is wrong. Also, remember that Fusion is a rule type distinct from scheduled and NRT rules.
Fusion is a built-in, ML-based analytics rule that cannot be customized.
It correlates alerts only from Microsoft security products (MDE, MDI, MDO, MDCA, AADIP).
The rule template is named 'Advanced Multistage Attack Detection'.
Fusion incidents have titles starting with 'Fusion:' and a distinct RuleId.
You can suppress false positives using incident suppression rules, not by editing the rule.
Fusion is enabled by default in all Sentinel workspaces.
The ML model is trained on Microsoft's global telemetry and is updated periodically.
These come up on the exam all the time. Here's how to tell them apart.
Fusion ML Rule
Uses machine learning to correlate alerts.
Only uses alerts from Microsoft security products.
Cannot be customized; only enabled/disabled.
Runs continuously in the background.
Creates incidents automatically with ML scoring.
Scheduled Query Rule
Uses KQL queries to match specific patterns.
Can use any data in Log Analytics (including custom logs).
Fully customizable: query, frequency, threshold, etc.
Runs on a schedule (e.g., every 5 minutes).
Creates incidents based on query results and threshold.
Mistake
Fusion can correlate alerts from any data source connected to Sentinel.
Correct
Fusion only correlates alerts from Microsoft security products (MDE, MDI, MDO, MDCA, AADIP). Third-party alerts via Syslog or CEF are not used.
Mistake
You can customize the ML model thresholds in Fusion.
Correct
Fusion's ML model and thresholds are managed by Microsoft and cannot be modified. You can only enable/disable the rule.
Mistake
Fusion incidents can be created from custom analytics rules.
Correct
Fusion does not use alerts from custom analytics rules. It only uses built-in alerts from Microsoft security connectors.
Mistake
Disabling Fusion reduces false positives.
Correct
Disabling Fusion eliminates all Fusion incidents, including true positives. Instead, use incident suppression rules to handle false positives selectively.
Mistake
Fusion is a scheduled query rule.
Correct
Fusion is a Microsoft rule type that runs continuously, not on a schedule. It is not a scheduled query rule.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, you cannot create custom Fusion rules. Fusion is a built-in Microsoft rule that uses a pre-trained ML model. You can only enable or disable it. If you need ML-based detection with custom data, consider using Azure Machine Learning with custom analytics rules, but that is not part of Fusion.
Fusion uses alerts from Microsoft security products: Microsoft Defender for Endpoint, Defender for Identity, Defender for Office 365, Defender for Cloud Apps, and Azure Active Directory Identity Protection. It does not use third-party alerts or custom logs.
Use incident suppression rules to automatically close Fusion incidents that match specific criteria (e.g., known benign IPs or users). Do not disable Fusion entirely, as that would also suppress true positives.
Yes, if UEBA anomalies generate alerts that are ingested via Microsoft security connectors (e.g., MDI or AADIP), Fusion can correlate them. However, standalone UEBA alerts from Sentinel's anomaly rules are not used by Fusion unless they are from a Microsoft product.
No, Fusion only correlates alerts within the same Sentinel workspace. Cross-workspace correlation is not supported.
Fusion sets severity automatically based on the ML score: High for scores >0.95, Medium for >0.8, Low for >0.6. You cannot override this.
Microsoft updates the model every few weeks to adapt to new attack patterns. The update is automatic and transparent to the user.
You've just covered Fusion ML Detection Rules in Sentinel — now see how well it sticks with free SC-200 practice questions. Full explanations included, no account needed.
Done with this chapter?