7.3 Analytics Rules, Incidents, and Detection
Key Takeaways
- Analytics rules evaluate ingested data with KQL to detect threats and generate alerts that become incidents.
- Rule types include scheduled (KQL), Microsoft security (promote Defender alerts), Fusion (ML multistage attack detection), anomaly, and near-real-time (NRT).
- An incident groups related alerts and entities into one investigation case with a severity and status.
- Fusion uses machine learning to correlate low-fidelity alerts into high-fidelity multistage attack incidents.
- Detection (analytics) is automated and rule-driven; hunting is analyst-driven proactive search.
From Analytics Rules to Incidents
Analytics rules are Microsoft Sentinel's detection engine. A rule runs a query — usually written in Kusto Query Language (KQL) — over the data that connectors have ingested, on a schedule. When the rule's logic matches, it produces an alert. Sentinel then groups related alerts (and the entities they reference, such as users, hosts, and IP addresses) into an incident: a single case with a severity, status (New / Active / Closed), and owner that the SOC investigates.
The direction is fixed and exam-friendly: connectors -> data -> analytics rule -> alert -> incident -> investigation/response. Recognizing that an analytics rule detects and an incident organizes the investigation is most of what SC-900 wants.
Sentinel offers several rule types. You do not need to author them, but recognizing the names helps:
| Rule type | What it does |
|---|---|
| Scheduled | Runs a custom KQL query on a schedule; the most common, flexible rule |
| Microsoft security | Automatically creates Sentinel incidents from alerts raised by Microsoft Defender products |
| Fusion | Uses machine learning to correlate many low-fidelity signals into high-fidelity multistage attack incidents |
| Anomaly | Built-in machine-learning templates that flag unusual behavior |
| Near-real-time (NRT) | Runs about once per minute for faster detection of time-sensitive threats |
Fusion is worth remembering specifically: it is the machine-learning correlation engine that connects seemingly unrelated, individually weak alerts into a single incident describing a probable multistage attack, dramatically reducing alert noise. When a prompt mentions ML-based correlation of multiple signals into one high-confidence incident, Fusion is the concept.
Detection vs. Hunting, and Selecting Sentinel
Detection and hunting are easy to confuse. Analytics rules are automated, predefined detection logic that runs continuously and raises incidents on its own. Hunting (next section) is analyst-driven, proactive exploration of the same data looking for threats no rule caught yet. Both rely on ingested data and both feed investigation, but they start from opposite modes — automatic vs. manual.
Use verbs in the prompt to pick the right Microsoft product area:
- Detect, correlate, alert, raise an incident, mitigate a threat -> Microsoft Sentinel (analytics/incidents).
- Approve access, review entitlements, activate a privileged role, detect identity risk -> Microsoft Entra.
- Label, retain, discover sensitive data, support eDiscovery -> Microsoft Purview.
Analytics rules also help you keep Sentinel apart from individual Defender products. A Microsoft security analytics rule is exactly the bridge that pulls Defender alerts into Sentinel as incidents — that is how XDR signals gain SIEM-wide context. But if the scenario is purely "protect endpoints" or "protect mailboxes," the right answer is the specific Defender product, not Sentinel.
| Cue in the scenario | Best match |
|---|---|
| Custom KQL detection on ingested logs | Sentinel scheduled analytics rule |
| ML correlation of weak signals into a multistage attack incident | Sentinel Fusion |
| One case grouping related alerts and entities to investigate | Sentinel incident |
| Bring Defender alerts into the SIEM as incidents | Sentinel Microsoft security rule |
For SC-900, you are matching products and recognizing vocabulary, not writing detections. Know that analytics rules detect, incidents organize the investigation, Fusion adds ML correlation, and all of it lives in Microsoft Sentinel's SIEM role.
The Life of an Incident
Understanding what happens to an incident after it is created helps you answer investigation-flow questions. A new incident arrives with a severity (Informational, Low, Medium, or High) and a status of New. An analyst, or an automation rule, assigns an owner and moves it to Active while it is being worked, then to Closed with a classification such as true positive, benign positive, or false positive once resolved.
Throughout, the incident carries its grouped alerts and entities — the users, hosts, IP addresses, files, and URLs involved — so the analyst can see the full picture in one case rather than chasing isolated alerts.
Sentinel supports the investigation with several built-in aids. The investigation graph visually maps the relationships among the entities and alerts in an incident, letting an analyst pivot from a suspicious account to the devices it touched to the IP addresses it used. Entity pages summarize everything Sentinel knows about a single user or host. And because Sentinel can ingest Microsoft Defender XDR incidents through a Microsoft security analytics rule, a single Sentinel incident can carry context that originated across endpoints, identities, email, and cloud apps.
| Incident attribute | Possible values | Purpose |
|---|---|---|
| Severity | Informational, Low, Medium, High | Prioritize analyst attention |
| Status | New, Active, Closed | Track investigation progress |
| Classification | True positive, benign positive, false positive | Record the outcome on closure |
| Owner | A user or group | Assign responsibility |
For SC-900 you will not run an investigation, but recognizing this lifecycle clarifies why incidents are the heart of Sentinel's SIEM role: they convert raw alerts into a managed, prioritized, ownable unit of work. When a scenario describes grouping related alerts, assigning severity, tracking status, or reviewing the entities involved in suspicious activity, the concept is a Sentinel incident, and the detection that produced it traces back to an analytics rule running over connected data.
What does a Microsoft Sentinel analytics rule do?
Which Sentinel analytics rule type uses machine learning to correlate low-fidelity signals into high-fidelity multistage attack incidents?
In Sentinel, what is an incident?