DE1.8 Module Summary

What you learned

This module taught the architecture of detection rules in Microsoft Sentinel — not as wizard configurations to click through, but as engineering decisions that determine how the SOC experiences your detections.

The five-stage pipeline

A scheduled analytics rule is a pipeline: the KQL query produces results, results are evaluated against a threshold, matching results are enriched with entity mappings and custom details, enriched results are packaged into alerts through event grouping, and alerts are grouped into incidents. Every parameter at every stage is a design decision. Every default you leave unchanged is a decision you didn't make — and each one has consequences for the analyst who triages the resulting incident.

The three detection engines

Sentinel scheduled rules handle 90% of detections with the full KQL language — joins, aggregation, time-series analysis, behavioral baselines. NRT rules handle the 3 to 5 time-critical detections where sub-minute latency changes the outcome — ransomware pre-encryption, credential dumping, C2 beaconing, security tool tampering. Defender XDR custom detections handle endpoint and email telemetry with automated response actions — device isolation, investigation package collection, file quarantine. These engines are complementary, not competing. A time-critical detection like shadow copy deletion should exist in multiple engines simultaneously.

Entity mapping as investigation infrastructure

Entity mapping is not optional enrichment. It is the mechanism that connects your detection to the investigation graph, cross-alert correlation, entity pages, UEBA insights, and Fusion multi-stage attack detection. A rule without entity mapping produces alerts that exist in isolation. The detection engineering standard: every rule gets entity mapping with the strongest identifiers your data source provides.

Metadata as engineering decisions

Severity classification controls SOC triage priority — calibrated using a three-factor model of impact, confidence, and SOC capacity, not template defaults. ATT&CK technique mapping drives coverage measurement, incident context, and Fusion correlation. Rule documentation captures every design decision so the rule is maintainable by anyone on the team. All three are configured on the General tab and all three are typically left on defaults. Detection engineers don't leave them on defaults.

The rule specification

Every rule you build from DE3 onward includes a specification with seven sections: detection hypothesis, threat context, data requirements, configuration rationale, false positive profile, analyst response procedure, and maintenance cadence. The specification is the engineering document. The KQL is the implementation. Both are required.

What you built

Through this module, you configured a brute force detection rule with: a KQL query that detects failed sign-ins followed by a success, 15-minute frequency with a 20-minute lookback for ingestion delay compensation, Account and IP entity mapping with strong identifiers, custom details surfacing FailedCount and SuccessCount on the incident card, dynamic alert names including the affected user and source IP, 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 rule specification documenting every design decision.

That single rule demonstrates every concept in this module. The rest of this course applies these concepts to increasingly sophisticated detection hypotheses.

What comes next

Module 2 teaches threat modeling and detection prioritization — the process that determines which detection rules you build and in what order. You've learned how to build a rule correctly. Module 2 teaches how to decide which rules to build.

The MITRE ATT&CK coverage matrix you examined in Section 1.4 showed the gap between your active detections and the techniques relevant to your threat landscape. Module 2 turns that gap into a prioritized detection backlog — ranked by the threat actors targeting your industry, the data sources you have available, and the techniques that would cause the most damage to your specific environment. The backlog becomes the engineering plan that guides your detection program.

You'll also learn how threat intelligence feeds into detection design — not as IOC lists to block, but as behavioral patterns to detect. The difference between detecting a specific IP address (fragile, short-lived) and detecting the behavior that IP address exhibits (durable, transferable) is the difference between reactive security operations and proactive detection engineering.