DE1.7 Anomaly Rules and Fusion

Anomaly rules as signal generators

Anomaly rules are fundamentally different from scheduled rules. A scheduled rule detects a specific pattern you define in KQL. An anomaly rule detects deviation from a learned behavioral baseline — the model determines what is “normal” for each user, device, or entity over a learning period (typically 14-21 days), then flags activity that deviates significantly from that baseline.

The output is different too. Scheduled rules create alerts that become incidents. Anomaly rules write records to the Anomalies table — not directly to incidents. These records are signals: “this user accessed 10x more files than their 30-day baseline” or “this sign-in came from a country this user has never signed in from.” They are not actionable alerts. They are behavioral indicators that require context to become actionable.

This is where the two-stage detection pattern comes in. You build a scheduled rule that queries the Anomalies table and joins it with other data sources to add the context that converts a behavioral signal into an actionable detection. The anomaly provides the “something is different.” The scheduled rule determines whether “different” means “malicious.”

Figure DE1.7 — Two-stage anomaly detection. Stage 1 (ML anomaly) provides the behavioral signal. Stage 2 (custom scheduled rule) adds environmental context to convert the signal into an actionable detection.

Example: two-stage anomaly detection for NE

Northgate Engineering enables the “Anomalous token usage” built-in anomaly template. After the 21-day learning period, the anomaly model identifies that j.morrison (Edinburgh field engineer) normally refreshes his session token 15-20 times per day from 2-3 IP addresses. On Thursday night, the model detects 85 token refreshes from 6 IP addresses — a 4x deviation from baseline. The anomaly writes a record to the Anomalies table.

By itself, this anomaly is low confidence. Morrison might be traveling, using hotel WiFi that rotates IPs, and the increased token refreshes could be from app reconnections during poor connectivity. The anomaly is interesting but not actionable.

The Stage 2 scheduled rule queries the Anomalies table and joins with SigninLogs. It discovers that Morrison’s session tokens are being refreshed from residential proxy IPs that are not in his travel history, that the device details do not match his enrolled device, and that his VPN connected at 22:47 — outside his normal working hours. The combination of behavioral anomaly + session inconsistency + off-hours activity elevates the detection from “interesting” to “probable CHAIN-MESH Phase 1.”

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

// TWO-STAGE PATTERN: Anomaly + Sign-in Risk Correlation
let timeWindow = 1h;
Anomalies
| where TimeGenerated > ago(timeWindow)
| where AnomalyTemplateName == "Anomalous token usage"
| where Score > 0.7  // High anomaly score only
| extend AnomalyUser = tostring(Entities[0].UserPrincipalName)
| join kind=inner (
    SigninLogs
    | where TimeGenerated > ago(timeWindow)
    | where RiskLevelDuringSignIn in ("medium", "high")
        or RiskState == "atRisk"
    | project SigninTime = TimeGenerated, UserPrincipalName,
        IPAddress, DeviceDetail, RiskLevelDuringSignIn, Location
) on $left.AnomalyUser == $right.UserPrincipalName
// Only fires when BOTH conditions are met:
// 1. Behavioral anomaly (token usage deviation)
// 2. Identity risk signal (risky sign-in properties)
// Entity mapping: Account → AnomalyUser, IP → IPAddress

Anomaly sensitivity tuning

Each anomaly template has a configurable sensitivity: High (detects smaller deviations — more anomalies, more false positives), Medium (balanced), or Low (detects only large deviations — fewer anomalies, fewer false positives). The sensitivity determines how far from the baseline an event must deviate to be flagged.

Start at Medium for all anomaly rules. After 30 days, query the Anomalies table to assess volume by template:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

// ANOMALY VOLUME ASSESSMENT — tune sensitivity based on results
Anomalies
| where TimeGenerated > ago(30d)
| summarize
    AnomalyCount = count(),
    AvgScore = round(avg(Score), 2),
    HighScoreCount = countif(Score > 0.7),
    DailyAvg = round(count() / 30.0, 1)
    by AnomalyTemplateName
| sort by DailyAvg desc
// If DailyAvg > 20 for a template: reduce sensitivity to Low
// If DailyAvg < 1 for a template: increase sensitivity to High
// Sweet spot: 2-10 anomalies per day per template at Medium

Fusion: multi-stage ML correlation

Fusion is Sentinel’s built-in multi-stage attack detection engine. It operates independently of your custom rules — you enable it (or disable it) and Microsoft’s ML models handle the correlation. Fusion detects known multi-stage attack patterns by linking low-confidence signals across multiple data sources: a suspicious sign-in (Identity) followed by a suspicious inbox rule (Email) followed by unusual file downloads (SharePoint) = Fusion incident.

Fusion requires no configuration beyond enabling. It cannot be customized or extended. It detects patterns that Microsoft has characterized across their global telemetry — if the pattern recurs across many tenants, Fusion learns it. If the pattern is unique to your environment (CHAIN-PRIVILEGE scope creep, CHAIN-DRIFT configuration exploitation), Fusion will not detect it.

The practical guidance: enable Fusion, let it produce incidents, and review them alongside your custom detection incidents. Fusion will occasionally catch attack patterns that your custom rules miss — particularly novel multi-stage combinations. Your custom rules will catch environment-specific patterns that Fusion cannot detect. The two systems complement each other.

Troubleshooting: Anomaly and Fusion issues

“Anomaly rules show no records after 30 days.” The learning period may not have completed — some anomaly templates require 30-90 days depending on the data volume. Check: Anomalies | where TimeGenerated > ago(7d) | summarize count() by AnomalyTemplateName. If specific templates show zero records, verify that the underlying data source is connected and ingesting (e.g., “Anomalous token usage” requires AADNonInteractiveUserSignInLogs).

“Fusion is enabled but produces no incidents.” Fusion requires multiple alert sources to correlate. If your workspace only has one data connector (e.g., only SigninLogs), Fusion has no cross-source signals to correlate. Enable data connectors for at least 3 domains (identity, endpoint, email) to give Fusion sufficient signal diversity.

“Anomaly rules generate too many records.” Reduce sensitivity from Medium to Low for the noisy templates. Alternatively, adjust your Stage 2 rule’s Anomaly score threshold — only consume anomalies with Score > 0.7 (high deviation) instead of all anomalies.

References used in this subsection

• Microsoft Sentinel anomaly rules documentation
• Course cross-references: DE1.1 (rule types overview), DE1.2 (scheduled rule query design for Stage 2), DE4 (identity anomaly detection using this pattern), DE9 (tuning anomaly sensitivity)

NE operational context

This detection operates within NE’s 18 GB/day Sentinel ingestion environment across 20 connected data sources. The rule’s alert volume, TP rate, and SOC triage burden are calibrated for NE’s 3-person SOC team handling 7-16 incidents per day. The detection engineer (Rachel) reviews this rule’s health during the monthly tuning review (DE9.9) and adjusts thresholds, exclusions, and entity mapping as the environment evolves.

The rule’s position in the overall detection library means it correlates with rules from adjacent kill chain phases — an alert from this rule gains significance when combined with alerts from earlier or later phases targeting the same entity.

This detection contributes to NE’s systematic coverage across the ATT&CK framework, correlating with adjacent-phase rules to identify multi-stage attacks. The monthly tuning review monitors its operational effectiveness.