Microsoft Sentinel analytic rules

Analytic rules are the detection engine of Microsoft Sentinel — KQL queries that run on schedule against ingested data, generating alerts and incidents when matching patterns are found. Understanding rule types, tuning approach, and custom-rule authoring is what separates basic Sentinel deployment from a working detection programme.

The rule types

Sentinel supports several analytic rule types:

Scheduled

The most common — runs a KQL query on a recurring schedule, generates alerts on matches.

• Query interval — how often to run (every 5 minutes, every hour, etc.).
• Lookup period — how far back to query.
• Threshold — how many matches before alerting.
• Entity mapping — which fields are users, devices, IPs, hashes.

Most rules are scheduled rules.

Near real-time (NRT)

For very fast detection on specific events:

• Runs every minute against the last minute of data.
• Lower latency than scheduled rules.
• Limited compared to scheduled — simpler queries, less complex aggregation.

Used for high-priority detections where minutes matter — confirmed account compromise, mass-deletion detection.

Microsoft Security

Pre-built rules that forward Defender XDR alerts into Sentinel as incidents. Don't author these; just enable them per product (Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps).

Anomaly

Built-in ML-based anomaly detection. Microsoft ships these; you tune by deciding which behaviours are "normal" for your environment.

Fusion

The cross-product correlation engine. Combines signals from multiple sources into multi-stage incident detection.

Threat Intelligence

Match logged events against threat-intelligence indicators (IP addresses, file hashes, domains).

Tuning rules

Out of the box, many rules generate more alerts than you can investigate. Tuning is essential:

Suppress known-good

Add exclusions for:

• Internal vulnerability scanners that look like attackers.
• IT operations activities that look like attacker behaviour.
• Service accounts with elevated permissions doing legitimate things.
• Backup software with broad file-access patterns.
• DevOps pipelines with unusual cross-service patterns.

Adjust thresholds

A rule alerting on "10 failed sign-ins" may produce too many alerts; raising to "50 failed sign-ins" tightens.

Time-of-day filtering

Some activities are normal at 14:00, suspicious at 03:00. Add time-aware logic.

Entity grouping

Combine multiple events into single incidents — group failures by same user / device / IP.

Custom rule authoring

For your specific environment, you'll write custom rules. The pattern:

// Detect unusual data export by departing employees
let HRData = externaldata(UserPrincipalName:string, DepartureDate:datetime)
    [@"https://your-data-source/hr.csv"] with(format="csv");
let DepartingUsers = 
    HRData
    | where DepartureDate between (now() .. now()+30d);
SignInLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName in (DepartingUsers | project UserPrincipalName)
| join kind=inner OfficeActivity on $left.UserPrincipalName == $right.UserId
| where Operation in ("FileDownloaded", "SyncDownloadedFiles")
| summarize TotalDownloads = count() by UserPrincipalName, bin(TimeGenerated, 1h)
| where TotalDownloads > 100

Key elements:

• External data for context (HR data here).
• Time filtering for performance.
• Join against relevant signals.
• Aggregation for threshold logic.
• Output with the right entities mapped.

Rule lifecycle

1. Author rule in the workspace.
2. Test with historical data — verify it would have detected past events.
3. Run in alert-only mode for a week — see what fires.
4. Tune based on findings.
5. Promote to incident creation when stable.
6. Periodic review as the environment evolves.

Operational discipline

• Document every rule — what it's for, expected fire rate, owner.
• Track false-positive rate per rule — high FP rules need tuning or retirement.
• Quarterly rule review — what's still useful, what to retire.
• Test before deploying custom rules — bad rules generate alert storms.

Where to learn

• GitHub repository of community-shared Sentinel queries.
• MITRE ATT&CK framework — many Sentinel rules map to specific ATT&CK techniques.
• Microsoft Learn Sentinel learning paths.
• Sentinel content hub for vendor-published rule packs.

For mature SOC operations, custom analytic rules are where Sentinel's value compounds — your team writes detections specific to your environment, your threats, your patterns. The pre-built rules are a starting point; the custom rules are the durable investment.