Sign In
In this section

Detection Rule Architecture in Microsoft Sentinel

6-8 hours · Module 1 · Free

0.1 What is detection architecture

Detection architecture is the engineering layer between writing a KQL query and operating a production detection rule. A query that returns the right results in Advanced Hunting does not automatically become a good analytics rule. The architecture decisions around that query — how often it runs, how far back it looks, what triggers an alert, which entities it maps, how severity is classified, how alerts group into incidents, and how the rule is documented — determine whether the rule detects threats reliably or generates noise that degrades the SOC.

Most Sentinel deployments skip this layer. The analyst writes a query, pastes it into the rule wizard, accepts every default, clicks Create, and moves to the next rule. The result is a detection library where every rule runs on default timing, produces alerts with no entity mapping, fires at Medium severity regardless of impact, doesn't register in the ATT&CK coverage matrix, and has no documentation beyond the rule name. Each individual default seems harmless. Collectively, they produce a detection program that the SOC cannot effectively triage, that leadership cannot measure, and that nobody can maintain.

This module teaches detection architecture as a set of deliberate engineering decisions. You'll learn what every configurable parameter does, why it matters, and what happens when you get it wrong. By the end, you'll be able to read any rule configuration and predict its operational behavior — detection latency, alert volume, false positive patterns, investigation quality, and correlation capability.

0.2 What you will learn

This module covers every architectural component of a detection rule. Each section teaches a concept at depth and then has you apply it to a test rule you configure and modify throughout the module.

Section 1.1 — Sentinel analytics rule types. The five rule types in the Sentinel detection engine: Scheduled (the detection engineer's primary tool), NRT (sub-minute latency for time-critical events), Microsoft Security (pass-through from Defender products), Anomaly (ML-based behavioral baselining with the Anomalies table), and Fusion (multi-stage attack correlation). What each produces, how each executes, and which to choose for each detection hypothesis. You'll audit your existing rules by type.

Section 1.2 — Anatomy of a scheduled rule. The five-stage pipeline: KQL query, alert threshold, enrichment (entity mapping + custom details + dynamic alert content), event grouping, and incident creation. Query frequency and lookback configuration, the 5-minute execution delay and ingestion_time() compensation, threshold tuning, and the results simulation. You'll configure a brute force detection rule from scratch.

Section 1.3 — Entity mapping and alert enrichment. Entity types (Account, Host, IP, URL, File, FileHash, Mailbox), strong versus weak identifiers, entity merge behavior across alerts, the 10-mapping and 500-entity limits, custom details in ExtendedProperties, and dynamic alert name and severity templates. The July 2026 Account Name breaking change. You'll add entity mapping and enrichment to your test rule.

Section 1.4 — Severity, MITRE mapping, and documentation. The four severity levels with Microsoft's definitions. The three-factor calibration model (impact, confidence, SOC capacity). ATT&CK technique mapping for coverage measurement, incident context, and Fusion integration. Sub-technique precision. The six-question rule specification framework. You'll classify your test rule and audit your workspace's ATT&CK mapping status.

Section 1.5 — NRT and Defender XDR custom detections. NRT architecture in depth: the latency decision framework, ingestion_time() versus TimeGenerated, query restrictions (filter chains only), the 30-alert cap and 50-rule workspace limit. Defender XDR custom detections: Advanced Hunting tables, required columns (Timestamp + DeviceId + ReportId), automated response actions (isolate, collect, scan, restrict, quarantine), frequency options. The multi-engine pattern for time-critical threats.

Section 1.6 — Alert grouping and incident architecture. The distinction between event grouping (how results become alerts within a single execution) and alert grouping (how alerts become incidents across executions). Three grouping criteria: all alerts, all entities match, selected entities match. Time windows from 5 minutes to 7 days. The 150-alert cap. Reopening closed incidents. The Defender portal correlation engine. You'll configure entity-based grouping on your test rule.

Section 1.7 — The rule specification template. The complete seven-section engineering document: detection hypothesis, threat context, data requirements, configuration rationale, false positive profile, analyst response procedure, and maintenance cadence. The anti-pattern library of eight common rule design mistakes. You'll complete the full specification for your test rule.

Section 1.8 — Module summary. Recap of the pipeline, the three detection engines, entity mapping as investigation infrastructure, metadata as engineering decisions, and the rule specification. Transition to DE2: threat modeling and detection prioritization.

0.3 What makes Microsoft Sentinel ideal for detection engineering

Sentinel's architecture maps directly to the detection engineering lifecycle. The KQL query language supports the full range of detection logic — from simple event matching to complex behavioral baselines with time-series analysis and cross-table correlation. The analytics rule engine provides five rule types, each designed for a different detection use case. Entity mapping connects detections to the investigation graph, UEBA insights, and Fusion correlation. The MITRE ATT&CK coverage matrix provides the measurement framework that tells you exactly which techniques you detect and which you don't.

The Defender XDR integration extends the detection surface with Advanced Hunting tables that carry deep endpoint, email, identity, and cloud application telemetry — and custom detections in Defender can trigger automated response actions that Sentinel cannot. With the Defender portal migration (required by March 2027), both engines coexist in a unified interface with a single incident queue.

No other platform combines KQL's analytical power, Sentinel's rule architecture flexibility, Defender's automated response actions, and the built-in ATT&CK coverage measurement in a single stack. That combination is why this course teaches detection engineering on Microsoft — not because it's the only platform, but because it's the most complete for the full lifecycle.

0.4 Lab environment

You need an M365 E5 developer tenant (free, 25 E5 licenses) and an Azure subscription with Sentinel enabled (5 GB/day free tier). If you completed DE0, your lab is already configured. If you're starting here, Section 1.2 walks you through creating your test rule — the lab setup from DE0 Section 6 provides the full environment configuration.

The developer tenant provides SigninLogs, AuditLogs, and AADNonInteractiveUserSignInLogs through Entra ID. If you've onboarded devices to Defender for Endpoint, you also get DeviceProcessEvents, DeviceNetworkEvents, and DeviceFileEvents. The test rule you build in this module uses SigninLogs — available in every M365 E5 tenant with sign-in activity.

0.5 How to get the best from this module

This module builds one test rule across eight sections. Each section adds a layer of architectural understanding. The sections are designed to be completed in sequence — Section 1.3 (entity mapping) modifies the rule you created in Section 1.2 (anatomy), and Section 1.6 (alert grouping) depends on the entity mapping from Section 1.3.

Read each section's conceptual teaching before configuring your rule. The architecture decisions make more sense when you understand what each parameter controls before you change it. The scenario boxes at the top of each section show what happens when the parameter is wrong — that context makes the correct configuration meaningful rather than arbitrary.

Run the audit queries. Several sections include KQL queries that examine your existing rules — entity mapping audit, ATT&CK mapping audit, severity distribution. These queries produce your own environment's numbers, not generic examples. The numbers tell you where your current rules fall short of engineering standards.

Estimated total time: 6 to 8 hours. Two to three sections per session produces consistent progress. The test rule is functional after Section 1.2 — subsequent sections refine and document it.

0.6 What you'll build

By the end of this module, you will have built and deployed one complete detection rule with every architectural parameter set deliberately:

A KQL brute force detection query with ingestion delay compensation, per-user-per-IP aggregation, and dynamic severity calculation. Account and IP entity mapping with strong identifiers. Custom details surfacing failure count and source IPs on the incident card. Dynamic alert names that include the affected user and attack intensity. Calibrated Medium severity with dynamic override to High for intense attacks. ATT&CK mapping to Credential Access T1110. AlertPerResult event grouping. Entity-based alert grouping on Account with a 24-hour window.

And a complete seven-section rule specification documenting every design decision — the engineering document that makes the rule maintainable by anyone on your team.

One rule. Every concept in the module applied. The rest of this course builds 70 more using the same architecture.

0.7 Module structure

  • Section 1.1 — Sentinel analytics rule types
  • Section 1.2 — Anatomy of a scheduled rule
  • Section 1.3 — Entity mapping and alert enrichment
  • Section 1.4 — Severity, MITRE mapping, and documentation
  • Section 1.5 — NRT and Defender XDR custom detections
  • Section 1.6 — Alert grouping and incident architecture
  • Section 1.7 — The rule specification template and common mistakes
  • Section 1.8 — Module summary

Prerequisites

Complete DE0 (What Is Detection Engineering). KQL proficiency is assumed — you can write queries with where, summarize, join, and let. If you need KQL foundations, complete the KQL for Security course first.

Every scheduled rule is a five-stage pipeline 1. Query KQL + timing 5min–14d frequency 2. Threshold Result count gt / lt / eq / neq 3. Enrichment Entities + details Dynamic content 4. Event group All → 1 alert or each → 1 alert 5. Incident Alert grouping Entity-based Every default you leave unchanged is a design decision you didn't make Default: no entities, Medium severity, no grouping, no documentation
A scheduled rule is not a query with a timer. It's a five-stage pipeline where each stage has parameters you control. This module teaches every parameter as a design decision — what it does, why it matters, and what breaks when you leave it on the default.
Without entity mapping vs with entity mapping Without Mapping Empty investigation graph No cross-alert correlation No Fusion integration No UEBA insights Analyst manually extracts entities With Strong Identifiers Investigation graph populated Cross-alert entity merge Fusion multi-stage correlation UEBA anomaly scores visible Click entity → full context Entity mapping is not optional enrichment — it is investigation infrastructure
Entity mapping connects your detection to Sentinel's investigation infrastructure. Without it, the alert is an isolated data point. With strong identifiers, the alert becomes a node in a graph that links users, IPs, hosts, and alerts across your entire workspace.
Three metadata decisions that control SOC operations Severity Info → Low → Medium → High Dynamic override per alert → SOC triage priority ATT&CK Mapping Tactic + technique + sub Drives MITRE coverage matrix → Coverage % + Fusion Documentation 7-section rule specification Every design decision recorded → Maintainability All three configured on the General tab — the first thing you see, the last thing most people consider
Severity drives what the SOC investigates first. ATT&CK mapping drives coverage measurement and Fusion correlation. Documentation drives whether the next engineer can maintain the rule. Template defaults leave all three uncalibrated.
Three engines — complementary, not competing Sentinel Scheduled Full KQL: joins, agg, time-series Any Log Analytics table 5 min – 14 day frequency 90%+ of detections Sentinel NRT Filter chains only ~1 minute frequency 30-alert cap, 50-rule limit 3–5 time-critical rules Defender XDR Custom Advanced Hunting tables Automated response actions Isolate, collect, quarantine Endpoint + email response Shadow copy deletion: NRT for fast alert + Defender custom for device isolation = both fire
A time-critical detection like ransomware pre-encryption should exist in multiple engines simultaneously. NRT provides sub-minute alerting. Defender custom provides automatic device isolation. Scheduled handles the cross-family correlation. The detection engineer chooses the right engine for each purpose.
Seven sections every production rule documents Hypothesis What + why Context Threat intel Data Table + fields Config Rationale FP Profile Sources Response Triage steps Maintain Cadence The wizard captures the configuration. The specification captures the reasoning. Every rule you build from DE3 onward includes a complete specification
A rule without a specification is a query only the author understands. The seven-section template documents every design decision — hypothesis, threat context, data requirements, configuration rationale, FP profile, response procedure, maintenance cadence — so anyone on the team can review, tune, or decommission the rule.

Go to Section 1.1 — Sentinel Analytics Rule Types to begin.

© 2026 Ridgeline Cyber Defence™ Ltd. Content may not be reproduced or redistributed. Worked artifacts may be adapted for use within your organization.
Unlock the Full Course See Full Course Agenda
← Previous Next →