Building Your First Sentinel Analytics Rule: From KQL to Incident

If you’re managing security for multiple tenants — government, banking, MNC clients — Microsoft Sentinel’s Analytics Rules are how you turn raw log noise into actionable incidents. This guide walks through building one from scratch: writing the KQL, wiring it into a rule, and understanding how it becomes an incident your SOC team can triage.

Why Analytics Rules Matter

Sentinel ingests enormous volumes of data — sign-in logs, Defender XDR alerts, firewall logs, Azure Activity logs. Without analytics rules, that’s just a searchable haystack. A well-built rule turns a specific pattern (e.g., “5+ failed sign-ins followed by a success from a new country”) into an incident with severity, entities, and an owner.

Step 1: Identify the Detection Scenario

Start narrow. A good first rule targets one clear behavior, for example:

Detect a user account signing in successfully from two countries within an implausible travel window.

This is a classic “impossible travel” detection and a great first rule because the logic is intuitive and the data (SigninLogs) is almost always already connected.

Step 2: Write the KQL Query

SigninLogs
| where ResultType == 0
| project TimeGenerated, UserPrincipalName, IPAddress, Location = tostring(LocationDetails.city), Country = tostring(LocationDetails.countryOrRegion)
| summarize Countries = make_set(Country), Locations = make_set(Location), Count = count() by UserPrincipalName, bin(TimeGenerated, 1h)
| where array_length(Countries) > 1

Test this in the Logs blade first. Confirm it returns rows you’d actually expect to see flagged — not every UPN in the tenant.

Step 3: Create the Analytics Rule

In Sentinel:

1. Analytics → + Create → Scheduled query rule
2. General tab — name it clearly (e.g., “Impossible Travel — Successful Sign-in from Two Countries”), set severity (Medium is reasonable for a first pass), and map to a MITRE ATT&CK tactic (Initial Access / Credential Access).
3. Set rule logic — paste your KQL. Set Query scheduling: run every 1 hour, lookback 1 hour (match your bin() window).
4. Alert threshold — trigger when results are “greater than 0.”
5. Entity mapping — map UserPrincipalName to the Account entity, IPAddress to the IP entity. This is what lets Sentinel auto-populate the incident’s entity graph — don’t skip this.
6. Incident settings — enable “Create incidents from alerts.” Optionally enable grouping so repeated alerts for the same user within a time window collapse into one incident instead of flooding your queue.
7. Automated response (optional at first) — you can attach a playbook here later once you’re comfortable with the rule’s accuracy.

Step 4: Validate Against Real Traffic

Let the rule run for a few days in a lower-severity state before treating its output as trustworthy. Check:

• Are legitimate VPN users or frequent travelers generating noise? If so, add a suppression list or exclude known corporate VPN egress IPs.
• Is the entity mapping populating correctly in the incident view?

Step 5: From Alert to Incident

Once triggered, Sentinel bundles the alert into an incident with:

• Severity and status (New → Active → Closed)
• Entity graph (accounts, IPs, hosts involved)
• Related alerts if grouping is enabled

This is where your SOC analyst picks it up for triage — which is the subject of the companion article, Triaging a Defender XDR Incident: A Step-by-Step Walkthrough.

Common Pitfalls

• Too broad a query — floods analysts with false positives and trains them to ignore the rule.
• No entity mapping — incidents show up but without the context needed to act fast.
• No suppression tuning — legitimate patterns (traveling executives, multi-region admins) get flagged repeatedly.

Next Steps

Once this rule is stable, expand into more advanced detections — anomalous OAuth consent grants, mass mailbox rule creation (often used in BEC attacks), or Defender for Endpoint process-based detections joined with SigninLogs for account-takeover correlation.

Start with one solid rule that your team trusts before scaling out a full rule set — a Sentinel workspace with 40 noisy rules is worse than one with 5 that analysts actually act on.