How Sentinel detects: rules, alerts, incidents, and the hunt

Connecting a source and watching its table fill up feels like progress, and it's the moment most people believe they're "covered." They aren't. A full table detects nothing on its own — it's raw material. Detection is a separate act: something has to read that data and decide "this is worth a human's attention." In Sentinel there are three different stances you can take toward the same tables, and a mature practice runs all three.

01Rules: the templates trap, and why a rule is more than its query

Two buckets — Microsoft's templates and your own — and one misconception that leaves teams with a green connector and zero live detections.

When you add a connector, its detection content arrives from the Content Hub as part of a solution — but it arrives as rule templates, not running rules. You still have to create a rule from a template and switch it on. This is the single most common beginner misread: the connector is green, data is flowing, and nothing is actually watching it because no rule was ever activated. Data flowing is not detection running.

Custom rules are where the craft lives — you write the KQL, decide what a single result means, and shape how findings behave. But here's the part that separates a working rule from a noisy one: the query is maybe half the rule. Every rule is its KQL plus a schedule, a threshold, entity mapping, and grouping logic — and the last two are what beginners skip.

SigninLogs
| where ResultType == 0
| where RiskLevelDuringSignIn == "high"
| where AppDisplayName has "Azure Portal"
// the query is the easy part. the rule also needs:
//   schedule  → run every 5m, look back 5m
//   threshold → fire on >= 1 result
//   entities  → map Account=UserPrincipalName, IP=IPAddress  (so you can pivot)
//   grouping  → fold repeats for the same Account into one incident

02The four kinds of rule

"Analytics rule" is a small family, and one member is where the Defender-unification story quietly shows up.

Type	What it does	Reach for it when
Scheduled	Your KQL on a timer — you set frequency and lookback. The workhorse.	Almost always — this is what "a detection" usually means
Near-real-time (NRT)	Same idea, runs about once a minute with minimal delay; comes with constraints (a single query, limited lookback).	The handful of signals you can't wait ~5 minutes on
Microsoft Security	Turns alerts from other Microsoft security products into Sentinel incidents — it relays, it doesn't query tables.	Surfacing Defender / Defender for Cloud alerts as incidents
Anomaly / ML	Behavioural baselines and multistage correlation instead of logic you wrote.	Catching deviations you can't express as a query

That third row is the seam we argued about in the foundations post: with Sentinel and Defender unified, a growing share of what used to be your custom detection now arrives pre-built as Defender alerts, flowing in through Microsoft Security rules. The honest read of "what's still distinctly SIEM" is the Scheduled and Anomaly rows — the custom logic for the sources Defender doesn't natively understand — plus the retention layer underneath.

03Watchlists: the context you bring to the data

Connectors bring in what happened. Watchlists hold what you know. Crossing the two is where detection gets sharp.

A watchlist is a small, admin-curated lookup you import and maintain by hand — VIPs, known-good IP ranges, service-account inventory, terminated-employee lists, asset criticality. In a rule it does two opposite jobs: enrich/prioritise ("new-country sign-in by a user on the VIP list" — now it's worth waking someone) and filter/allowlist ("alert on admin logins except from IPs on my jump-box list"). Same join, in a workbook, turns anonymous rows into "that's the CFO's laptop."

04Alert → incident, and grouping done honestly

The alert is a single fact. The incident is the story you assemble from related facts — and the art is drawing "related" tightly enough to be true.

The chain is precise: a rule runs, each qualifying result is an alert, and alerts are grouped into an incident — the unit a human actually works. Grouping is the right default, because without it one noisy source spawns a hundred near-identical incidents and the queue becomes useless. But what you group by decides whether grouping helps or hides.

05Hunting: the questions you didn't know to ask

Rules catch attacks you predicted. Hunting is for the ones you didn't — and it's the R&D that feeds your detections.

An analytics rule can only fire on a pattern you already described. Hunting inverts that: you form a hypothesis ("if an attacker were living off the land here, what would it look like?"), run the query once against history, and chase the hunch. The part that closes the loop — and the reason hunting isn't just ad-hoc querying — is that a hunt which finds something real graduates into a scheduled rule. Hunting is where new detections are born.

When a hunt outgrows KQL — you need Python, a library, an ML model, or a graph you can't draw in a workbook — that's what notebooks are for: Jupyter notebooks you drive cell by cell. Two honest caveats: a notebook is a power tool you steer, not an agent that investigates for you; and it needs its own compute — you attach it to a separate Azure Machine Learning workspace (distinct from your Log Analytics workspace), which carries setup and cost. It's the specialist's instrument, used deliberately and rarely — not the daily driver.

06Entity behaviour: from "what fired" to "who's involved"

Mid-incident, the useful pivot isn't another query — it's a single screen that assembles everything tied to one actor.

The entity page takes a user, host, or IP and pulls together everything about it — incidents, alerts, sign-ins, an activity timeline — on one screen. It flips the axis of investigation from "what did this rule catch" to "what is this user doing," which is exactly the move you want once an alert points at someone. Underneath it, optionally, is UEBA (User and Entity Behaviour Analytics) — the ML baselining that flags "this account is acting anomalously versus its own history" and writes its own signal for the entity pages to surface. The entity page is always useful; UEBA is the optional engine that enriches it, and it carries cost — so it's a switch you flip deliberately, not a default.

07Next: making it act

Detection ends with an incident sitting in a queue — accurately built, correctly grouped, ready for a human. But a well-made incident still hasn't done anything. Part 3 is response: automation rules and playbooks, the reflex and the muscle — including the single highest-leverage automation in a SOC, and the one place you should absolutely keep a human on the trigger.