DE1.13 Module Summary

Module summary

This module taught the architecture of Microsoft Sentinel analytics rules — every configurable dimension, its operational impact, and the specification discipline that prevents the common mistakes that turn correct KQL into broken detection. You now understand HOW rules work. DE2 teaches WHAT to detect. DE3 starts building production rules.

What you learned across 12 subsections

Sentinel analytics rule types (DE1.1). Five types with different architectures. Scheduled rules are the detection engineer’s primary tool (90%+ of custom rules): full KQL flexibility, configurable frequency, any table in the workspace. NRT rules provide sub-minute detection with restricted KQL (no joins, no aggregations). Microsoft Security rules forward vendor alerts to Sentinel incidents. Anomaly rules provide ML behavioral baselines. Fusion correlates low-confidence signals via ML. Detection engineering focuses on scheduled and NRT — the other three provide the vendor baseline.

Query and lookback window (DE1.2). The lookback window must exceed the query frequency to prevent detection gaps. Events occurring in a gap between lookback and frequency are permanently missed. The recommended pattern: lookback = frequency + 10-50% buffer. Query design for analytics rules: deterministic (no take or sample), filtered to return only actionable results, and including all entity fields in the output. Performance constraint: 10-minute query execution timeout.

Frequency and trigger logic (DE1.3). Query frequency determines detection latency: average total latency = ingestion latency + (frequency / 2). Match frequency to severity: 5 min for critical, 15 min for high, 30 min to 4 hours for medium, 12-24 hours for low. Trigger logic supports threshold-based detection — encode complex multi-dimensional thresholds in KQL, keep the trigger at “results > 0.” NE compute budget: ~3,370 daily executions across 50 rules at distributed frequencies.

Entity mapping and alert enrichment (DE1.4). Entity mapping transforms raw query fields into correlatable Account, Host, IP, URL, File, Process, Mailbox, and CloudApplication identifiers. Without entity mapping: incidents cannot correlate across rules, the investigation graph has no entities, and automation rules cannot act on specific objects. The single most impactful configuration for operational detection. Map ALL relevant entities on every rule.

Severity classification and MITRE ATT&CK mapping (DE1.5). Severity = confidence × impact. The matrix produces four tiers: Critical (high confidence + catastrophic impact — 3-5 rules), High (significant impact — 10-15 rules), Medium (moderate scenarios — 15-25 rules), Low (posture monitoring — 10-15 rules). ATT&CK mapping at sub-technique level enables coverage measurement. Without it, rules are invisible to the coverage assessment. Every rule maps to at least one technique.

NRT rules (DE1.6). Sub-minute detection for 3-5 critical detections where all three conditions are met: high confidence (>90% TP rate), catastrophic impact if delayed, and single-event detection pattern. NE NRT candidates: ransomware pre-encryption (vssadmin), LSASS credential dump, and known C2 beacon patterns. NRT + companion scheduled rule: the NRT catches fast, the scheduled rule provides investigation context.

Anomaly rules and Fusion (DE1.7). Anomaly rules write to the Anomalies table — not directly to incidents. The two-stage pattern: anomaly rule provides behavioral signal → scheduled rule joins Anomalies with identity/activity data → high-fidelity alert. Sensitivity tuning: start at Medium, adjust based on 30-day volume assessment. Fusion provides ML multi-stage correlation — enable and let it complement custom rules.

Defender XDR custom detections (DE1.8). Endpoint-only detection with native Defender response actions (isolate, quarantine, block). Fixed frequency (1/3/12/24 hours — no 5-minute option). Cannot query third-party data. Use when detection AND response are both Defender-native. Sentinel is the default for everything else. Dual deployment pattern for critical rules: Sentinel NRT for fast detection, Defender custom detection for automated response.

Alert grouping and incident creation (DE1.9). Three strategies: by entity (recommended — one incident per attack source), all-in-one (state monitoring), one-per-alert (critical independent tracking). Entity-based grouping prevents the SOC-flooding anti-pattern where volume rules create hundreds of separate incidents from one attack. Cross-rule correlation via shared entities links alerts from different rules into multi-alert incidents — requires entity mapping on both rules.

Automation rules and response integration (DE1.10). Two-layer architecture: automation rules (conditions) + playbooks (actions). Three tiers: Tier 1 auto-contain (3-5 rules, >90% TP rate, reversible actions), Tier 2 auto-enrich + assign (15-25 rules, context acceleration), Tier 3 assign only (remaining rules). Automate enrichment by default. Automate containment only for confirmed-high-confidence, reversible-action, time-critical detections.

The rule specification template (DE1.11). 12 sections: name, hypothesis, ATT&CK mapping, data sources, KQL, entity mapping, frequency/lookback, severity, trigger/grouping, FP analysis, response procedure, tuning plan. Specification before code. Every rule in DE3-DE8 ships with a completed specification. The 15-minute specification prevents hours of troubleshooting from undocumented rules.

Common architecture mistakes (DE1.12). Eight anti-patterns: lookback gap (#1), missing entities (#2), arbitrary severity (#3), no ATT&CK mapping (#4), all-5-minute frequency (#5), no FP analysis (#6), wrong grouping (#7), automating low-confidence (#8). All preventable through the specification template. NE’s current 23 rules exhibit multiple anti-patterns — the detection engineering program fixes them systematically.

Key artifacts from this module

What comes next

DE2 (Threat Modeling for Detection Prioritization) teaches how to decide WHAT to detect. You now know how to build rules. DE2 teaches which rules to build first: crown jewel analysis, ATT&CK coverage assessment, risk-based gap scoring, the detection backlog, and the 90-day roadmap. After DE2, you have a prioritized list. DE3 starts building production rules against that list.