# Microsoft Sentinel Analytics Rules — Detection Engineering & MITRE ATT&CK

Source: https://ai.techclick.in/blog_microsoft_sentinel_analytics_rules_detection
Markdown: https://ai.techclick.in/blog_microsoft_sentinel_analytics_rules_detection.md
Publisher: Techclick Infosec Pvt Ltd

Master Microsoft Sentinel analytics rules in 2026: scheduled KQL rules, Near-Real-Time detection, Fusion multistage ML, anomaly rules and Microsoft Security rules — plus MITRE ATT&CK mapping and detection tuning.

Microsoft Sentinel Analytics Rules — Detection Engineering & MITRE ATT&CK student learning map
                     A visual study map for Microsoft Sentinel Analytics Rules — Detection Engineering & MITRE ATT&CK showing learning path, evidence, traps, and practice sequence.

                     TECHCLICK STUDY MAP
                     Microsoft Sentinel Analytics Rules — Detection...
                     Microsoft · learn the flow, prove with evidence, avoid unsafe shortcuts

   1. Start
   🎯 By the end you will be able to

   2. Understand
   Pick where you want to start

   3. Prove
   ① The five analytics rule types —...

   4. Practice
   ② Scheduled & NRT rules —...

                     How to use this page
                     First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself.
                     Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456

             Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail.

             Most engineers think…

             Most people assume Microsoft Sentinel is a 'magic box that just detects threats'. In reality, Sentinel fires an alert only when an analytics rule says to — and if you have no rules enabled, you get no alerts at all.

 The real skill is understanding  which of the five rule types  to use for each detection goal: a hand-written  Scheduled KQL rule  for precise custom logic, a  Near-Real-Time rule  when latency matters, a  Microsoft Security rule  to absorb alerts from Defender products,  Fusion ML  to catch multistage attacks you could never write a single KQL query for, and  Anomaly rules  to flag unusual behaviour baselines. Knowing that distinction — plus how to map every rule to MITRE ATT&CK and tune out false positives — is what separates a detection engineer from someone who just pressed 'Deploy'.

## ① The five analytics rule types — your detection menu

 Every Microsoft Sentinel alert is born from one of five analytics rule types.  Scheduled  rules are KQL queries you author (or deploy from the Content Hub) that run on a configurable interval — every 5 minutes to once a day — against Log Analytics tables. They are the workhorse of custom detection engineering.  Near-Real-Time (NRT)  rules are a special subset: hardcoded to run every minute with sub-5-minute end-to-end latency, ideal for high-priority detections like privilege escalation or credential spray where seconds matter.

  Microsoft Security  rules require no KQL at all: they auto-import alerts from connected Microsoft products — Microsoft Defender for Endpoint, Microsoft Defender for Cloud, Microsoft Defender for Identity, and others — and let you filter by product and severity threshold.  Fusion  is a Microsoft-managed ML engine you cannot author yourself; it correlates seemingly unrelated low-fidelity signals across multiple attack stages (initial access, lateral movement, exfiltration) into a single high-confidence multistage-attack incident.  Anomaly  rules use ML to build a behavioural baseline over time and fire when an entity strays significantly from that baseline — no static threshold needed.

  Figure 1 — From log event to Sentinel incident
   Every Sentinel detection follows the same five-step path from raw log data to a triaged incident.
- From log event to Sentinel incident Ingest logs connectors feed tables Rule fires KQL / ML / import Alert raised entities mapped Incident created alerts grouped SOC triages investigate & close Every Sentinel detection follows the same five-step path from raw log data to a triaged incident. Figure 2 — Five rule types — latency vs authoring effort The five rule types trade detection latency against the authoring effort required from your team. Five rule types — latency vs authoring effort Anomaly rules ML baseline, flighting then production Fusion rules ML multistage, Microsoft-managed MS Security rules auto-import from Defender products NRT rules KQL, runs every 60 seconds Scheduled rules KQL, 5 min to 1 day interval The five rule types trade detection latency against the authoring effort required from your team. Quick check · Q1 of 10 · Remember How many analytics rule types does Microsoft Sentinel offer? a) Two — Scheduled and NRT b) Three — Scheduled, Fusion and Anomaly c) Five — Scheduled, NRT, Microsoft Security, Fusion and Anomaly d) Only one — all rules are KQL-based Correct: c. Sentinel has five rule types: Scheduled (custom KQL), NRT (60-second KQL), Microsoft Security (auto-import from Defender), Fusion (ML multistage), and Anomaly (ML baseline). Knowing all five is required for any SC-200 or detection engineering interview. 👉 So far: Sentinel has five rule types: Scheduled (custom KQL), NRT (60-second KQL), Microsoft Security (Defender auto-import), Fusion (ML multistage), Anomaly (ML baseline). No rule = no alert. ## ② Scheduled & NRT rules — writing KQL detections that hold up A Scheduled rule has four key dials: the KQL query itself, the query frequency (how often it runs), the lookback window (how far back the query looks each time), and the alert threshold (how many results trigger an alert). The most common mistake is setting a lookback shorter than the frequency — you create a gap and miss events. Set lookback to at least equal the frequency, or longer for slow-burn detections. ### Entity mapping and alert grouping Entity mapping tells Sentinel which KQL columns are Accounts, Hosts, IPs, or URLs so the SOC can pivot on them. Alert grouping controls whether multiple rule hits within a time window merge into one incident or create separate ones — merge aggressively to reduce alert fatigue. NRT rules share the same KQL and entity-mapping interface but strip away the frequency dial (always 1 minute) and restrict queries to a single table for speed. Use NRT for your top-tier, time-sensitive detections only; their compute cost is higher. ⏱️ NRT rule tap to flip Runs every 60 seconds, captures the preceding minute, gives sub-5-minute alert latency. Single-table KQL queries only. Reserve for your highest-priority detections. 🤖 Fusion engine tap to flip Microsoft-managed ML that correlates multiple low-fidelity signals across kill-chain stages into one high-confidence multistage-attack incident. You cannot author Fusion rules, but you can toggle which signal types it consumes. 📉 Anomaly rule tap to flip Trains an ML baseline on entity behaviour over time; fires a low-severity anomaly record when an entity drifts beyond the baseline. Use Flighting mode first, validate, then promote to Production. 🛡️ Microsoft Security rule tap to flip Auto-imports alerts from connected Microsoft products (Defender for Endpoint, Defender for Cloud, Defender for Identity). No KQL needed — just select the product and the severity filter. Lookback must be >= frequency Set your Scheduled rule lookback window to at least equal the query frequency — ideally a bit longer — otherwise events ingested in the gap between runs are never evaluated and you will miss detections silently. Quick check · Q2 of 10 · Understand What is the most common mistake when configuring a Scheduled rule query window? a) Setting the alert threshold too high b) Setting the lookback window shorter than the query frequency, creating gaps c) Using NRT rules instead of Scheduled rules d) Mapping too many entities to the alert Correct: b. If lookback 👉 So far: Scheduled rule key dials: KQL query, frequency, lookback (must be >= frequency), alert threshold, entity mapping, and alert grouping. NRT rules strip away the frequency dial and run every 60 seconds on a single table. ## ③ Fusion & Anomaly rules — letting ML carry the heavy multistage load Fusion is Sentinel's correlation engine for multistage attacks. It ingests signals from across your connector estate — anomalous sign-ins, impossible travel, malware detections, suspicious process execution, unusual data access — and uses scalable ML to find combinations that indicate a coherent kill-chain even when no single signal crosses a threshold. The output is a Fusion incident with all contributing signals listed, mapped to MITRE ATT&CK tactics , and a high confidence score. You cannot tune the Fusion model directly, but you can toggle which source signal types it consumes. Anomaly rules work differently: each rule observes one specific behaviour (e.g. login-hour distribution, data-volume per user, process execution patterns) over a training window, sets a statistical baseline, and fires a low-severity anomaly record when an entity drifts beyond the threshold. Anomalies are not incidents by themselves — they feed Fusion and can be queried in hunting. The important operations task is to set the anomaly rule to Flighting mode first, validate the baseline fits your environment, then promote to Production . Figure 3 — Fusion ML — signals it correlates Fusion ingests low-fidelity signals from across the estate and correlates them into one high-confidence multistage incident. Fusion ML — signals it correlates Fusion engine ML correlation Anomaly records Defender alerts Sign-in anomalies Impossible travel Process execution Data exfil signals Fusion ingests low-fidelity signals from across the estate and correlates them into one high-confidence multistage incident. Trying to tune Fusion like a KQL rule Fusion is Microsoft-managed ML. You cannot edit its internal thresholds or correlation logic. What you can do is control which anomaly-signal sources it consumes. If Fusion fires false positives, investigate the contributing anomaly or Defender signals, not the Fusion rule itself. ### ▶ Watch a credential-spray become a Fusion incident A real multistage attack flows from raw log to Fusion incident. Press Play for the healthy detection, then Break it to see the classic failure. ① Spray detected 50 failed sign-ins from one IP hit the AAD logs. The Scheduled rule for brute-force fires an alert and maps AccountUPN and IPAddress entities. ▼ ② Anomaly raised The 'impossible travel' anomaly rule also fires for the same user — the successful sign-in arrives from a different country 10 minutes later. ▼ ③ Fusion correlates Fusion ML sees: brute-force alert + impossible travel anomaly + a Defender for Endpoint process-injection signal all linked to the same account. It raises one high-confidence Fusion incident. ▼ ④ Incident triaged The SOC opens the Fusion incident: three contributing signals, MITRE tactics Initial Access + Execution, entity page for the compromised account, and suggested investigation steps. Press Play to step through how a credential spray becomes a Fusion incident. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset Quick check · Q3 of 10 · Apply A user has logged in from London and then from Mumbai 20 minutes later. Which Sentinel feature is most likely to surface this as part of a multistage attack? a) A custom Scheduled KQL rule you write b) A Microsoft Security rule importing Defender alerts c) Fusion ML correlating the impossible-travel anomaly with other kill-chain signals d) A watchlist lookup Correct: c. Fusion correlates anomalous signals — including impossible travel from the Azure AD anomaly rule — with other suspicious signals (e.g. unusual data access) across kill-chain stages to produce a high-confidence multistage incident. 👉 So far: Fusion correlates multiple low-fidelity signals across kill-chain stages using ML into one high-confidence incident — you cannot author it, only toggle its signal sources. Anomaly rules need Flighting validation before promoting to Production. ## ④ Detection tuning & MITRE ATT&CK coverage — closing the gaps Detection engineering in Sentinel has two loops. The first is tuning : start in Observe mode (rule creates alerts but no incidents), watch the false-positive rate for a week, add KQL where exclusions or tighten entity filters, then promote to Active . Use watchlists (CSV lookup tables in Sentinel) to maintain exception lists without touching the KQL query itself — update the watchlist, not the rule. Use automation rules to auto-close known-safe patterns the moment an incident opens. The second loop is coverage . Sentinel's MITRE ATT&CK page shows a heat-map of every active and available rule mapped to a technique cell. Cells that are empty mean no active rule covers that technique — an adversary using it would be invisible. Detection engineers review this matrix, prioritise the emptiest cells against their threat model, and deploy or write rules to fill them. Content Hub solutions (Microsoft-authored rule packs for specific products and threats) are the fastest way to add coverage; custom Scheduled rules fill the remaining gaps specific to your environment. Figure 4 — Scheduled rules vs NRT rules — when to use which Scheduled rules cover most detections; NRT rules are reserved for time-critical, high-priority use cases. Scheduled rules vs NRT rules — when to use which Scheduled rules Run every 5 min to 24 hours Query any number of tables Lower compute cost per rule Best for most custom detections NRT rules Run every 60 seconds always Single-table query only Higher compute cost per rule Best for top-tier critical alerts Scheduled rules cover most detections; NRT rules are reserved for time-critical, high-priority use cases. Priya at a Mumbai fintech company faces this A newly deployed Scheduled rule for 'multiple failed logins followed by success' fires 400 incidents on the first day, flooding the SOC queue and burning analyst goodwill. Likely cause The KQL threshold was set to 3 failed logins before 1 success, which is too low for this environment where shared service accounts routinely retry on transient failures. Diagnosis Open Analytics ▸ Active rules ▸ rule detail ▸ Simulate alerts. Most matches are service accounts with known retry patterns — not real brute-force attempts. Analytics ▸ Active rules ▸ Edit rule ▸ Set rule logic ▸ Query Fix Create a Sentinel watchlist of approved service-account UPNs. Add a where AccountUPN !in (watchlist) filter to the KQL. Raise the threshold to 10 failures. Switch to Observe mode for 3 days, confirm false-positive rate drops, then promote back to Active. Verify Re-run simulation: only genuine human accounts exceeding 10 failures and not on the watchlist now produce alerts. SOC incident volume drops by over 90% while real attack patterns still fire. Check coverage gaps on the MITRE page monthly Go to Microsoft Sentinel ▸ Threat management ▸ MITRE ATT&CK. Any empty cell means no active rule covers that technique. Prioritise empty cells in your threat model and deploy Content Hub rule packs or custom Scheduled rules to fill gaps before an adversary exploits them. Quick check · Q4 of 10 · Analyze Your SOC is overwhelmed with false positives from a scheduled detection rule. Which approach reduces noise without deleting the rule? a) Delete and recreate the rule with a stricter query b) Raise the severity threshold and hope it improves c) Disable all analytics rules temporarily d) Switch the rule to Observe mode, add KQL where-exclusions and watchlist exceptions, then re-promote to Active Correct: d. Observe mode lets the rule run and generate alerts without creating incidents, so you can analyse the false-positive pattern without flooding the queue. Add KQL where-exclusions and watchlist filters, then promote back to Active once the false-positive rate is acceptable. Deleting and recreating loses the rule history. 👉 So far: Tune Scheduled rules via Observe mode + KQL exclusions + watchlist exceptions, not deletion. Close MITRE ATT&CK coverage gaps monthly using Content Hub packs and custom rules. ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. What are the five analytics rule types in Microsoft Sentinel? Why does the lookback window need to be at least as long as the query frequency? What is a Sentinel anomaly rule and how do you validate one? What does Fusion do and why can't you write Fusion rules yourself? How do watchlists help with false-positive tuning? How do I use the MITRE ATT&CK page in Sentinel to improve coverage? Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in. ## 📝 Wrap-up assessment — six more You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end. Q5 · Remember Which Sentinel analytics rule type runs every 60 seconds and offers sub-5-minute alert latency? a) Scheduled rule with a 1-minute frequency b) Microsoft Security rule c) Near-Real-Time (NRT) rule d) Fusion rule Correct: c. NRT rules are hardcoded to run every 60 seconds and capture the preceding minute, giving end-to-end latency under 5 minutes. Scheduled rules can be set to 5-minute frequency but still have higher latency. Microsoft Security rules are event-driven imports, not scheduled; Fusion is ML-based. Q6 · Understand What is the primary purpose of entity mapping in a Scheduled analytics rule? a) To set the query frequency b) To tell Sentinel which KQL columns are Accounts, Hosts, IPs or URLs for incident correlation and entity behaviour analytics c) To block entities on the firewall automatically d) To define which Log Analytics tables the rule queries Correct: b. Entity mapping identifies structured identifiers (Account, Host, IP, URL) inside alert results. Sentinel uses these to correlate related alerts into one incident and to populate entity pages for investigation. Without entity mapping the SOC cannot pivot on who or what is involved. Q7 · Apply You deploy a new brute-force detection rule and it generates 500 incidents on day one. What is the correct first response? a) Delete the rule and start over b) Raise the severity threshold and hope it improves c) Enable Fusion to suppress the duplicates d) Switch the rule to Observe mode, simulate alerts, add KQL exclusions and a watchlist for known-safe accounts, then re-promote Correct: d. Observe mode lets the rule run and generate alerts without creating incidents, so you can analyse the false-positive pattern without flooding the queue. Add KQL where-exclusions and watchlist filters, then promote back to Active once the false-positive rate is acceptable. Q8 · Analyze An Anomaly rule fires low-severity anomaly records for a user but never creates an incident. Why? a) Anomaly records are low-severity signals fed into Fusion and available for KQL hunting, but do not create incidents on their own b) Anomaly rules are misconfigured and need a KQL query added c) Anomaly rules only work for Defender for Endpoint data d) Anomaly rules must be set to Active mode before incidents are created Correct: a. By design, anomaly rules produce anomaly records (low-severity) stored in the Anomalies table. These feed Fusion as contributing signals and are available for threat hunting. They do not directly create incidents — that is intentional to avoid low-confidence noise in the incident queue. Q9 · Evaluate Which approach best closes a newly discovered MITRE ATT&CK technique gap in your Sentinel workspace? a) Deploy a Content Hub rule pack covering that technique, then write a custom Scheduled rule for environment-specific variations b) Wait for Microsoft to add the technique to Fusion automatically c) Ignore techniques that do not appear in your threat model d) Turn on all anomaly rules to cover everything Correct: a. Content Hub packs provide Microsoft-authored, MITRE-mapped rules immediately; custom Scheduled rules then handle environment-specific telemetry. Relying on Fusion alone misses techniques it does not cover; turning on all anomaly rules creates noise without targeted coverage. Q10 · Evaluate A security manager asks why you cannot tune Fusion's correlation thresholds directly. Best answer? a) Fusion is deprecated in 2026 b) Fusion rules require a Premium Sentinel licence to edit c) Fusion is Microsoft-managed ML; its model must stay current with evolving attack patterns so Microsoft controls it — you tune the signal sources it consumes, not the ML itself d) You can tune Fusion by editing the rule's KQL query Correct: c. Fusion is a Microsoft-managed ML engine. Microsoft keeps the internal correlation model current with evolving attack patterns and adversary TTPs, so they do not expose it for customer editing. What you can control is which signal source categories Fusion ingests — toggle specific anomaly or alert types on or off. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again". ### 🧠 In your own words Type one line: what is the difference between a Scheduled rule and an NRT rule, and when would you choose NRT? Then compare with the expert version. Compare with expert answer Expert version: Both are KQL-based and share the same query, entity mapping and alerting settings. The difference is the run cadence: a Scheduled rule runs on a frequency you set (5 minutes to 1 day), can query multiple tables, and is the right choice for the vast majority of custom detections. An NRT rule is hardcoded to run every 60 seconds on a single table and delivers sub-5-minute alert latency. Choose NRT only for your highest-priority, time-sensitive detections — privilege escalation, mass-delete operations, direct attack-pattern matches — where a 5-minute latency difference is operationally significant. NRT rules cost more compute, so reserve them rather than deploying them universally. ### 🗣 Teach a friend Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary. Generate my one-liner 📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Microsoft Sentinel at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 Glossary Scheduled rule A KQL-based analytics rule that runs on a configurable interval (5 min to 1 day) against Log Analytics tables to detect specific patterns. NRT (Near-Real-Time) rule A KQL analytics rule hardcoded to run every 60 seconds on a single table, delivering sub-5-minute alert latency for high-priority detections. Fusion engine Microsoft-managed ML correlation engine that combines low-fidelity signals from multiple kill-chain stages into one high-confidence multistage-attack incident. Anomaly rule An ML rule that builds a behavioural baseline for an entity and fires a low-severity anomaly record when the entity strays beyond that baseline. Microsoft Security rule An analytics rule that auto-imports alerts from connected Microsoft products (Defender for Endpoint, Defender for Cloud, etc.) with no KQL authoring required. Entity mapping A Scheduled or NRT rule setting that identifies which KQL output columns represent Accounts, Hosts, IPs or URLs for incident correlation and entity analytics. Watchlist A CSV-based lookup table uploaded to Sentinel and referenced in KQL queries to maintain exception lists without modifying the core rule logic. MITRE ATT&CK coverage page A Sentinel view that maps every active and available rule to a MITRE ATT&CK technique cell, showing detection coverage gaps as empty cells. #### 📚 Sources Microsoft Learn — Threat detection in Microsoft Sentinel . learn.microsoft.com/en-us/azure/sentinel/threat-detection
- Microsoft Learn — Near-real-time (NRT) analytics rules in Microsoft Sentinel . learn.microsoft.com/en-us/azure/sentinel/near-real-time-rules
- Microsoft Learn — Configure multistage attack detection (Fusion) rules in Microsoft Sentinel . learn.microsoft.com/en-us/azure/sentinel/configure-fusion-rules
- Microsoft Learn — View MITRE ATT&CK coverage in Microsoft Sentinel . learn.microsoft.com/en-us/azure/sentinel/mitre-coverage
- Microsoft Learn — Create Analytics Rules for Microsoft Sentinel Solutions . learn.microsoft.com/en-us/azure/sentinel/sentinel-analytic-rules-creation
- Microsoft Community Hub — Automating export of Microsoft Sentinel analytic rules mapped to MITRE tactics & techniques . techcommunity.microsoft.com

### What's next?

             Got analytics rules down? Next, explore Microsoft Sentinel automation rules and playbooks — how to auto-triage incidents, enrich entities, and fire Logic App workflows without writing a single line of KQL.

                 Next · All interview lessons →
                 Practice on exam.techclick.in →

---
Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees.
Browse all lessons: https://ai.techclick.in/blogs
AI index: https://ai.techclick.in/llms.txt