What Is Detection Engineering

0.1 What is detection engineering

Detection engineering is the discipline of building, testing, deploying, and maintaining the detection rules that determine what a security operations program can see. It sits upstream of the SOC — the SOC triages what detection rules produce, but someone has to decide which attack techniques get detected, design the logic that distinguishes attack from legitimate activity, test whether that logic works, and maintain it as the environment and threat landscape evolve.

The discipline is not KQL syntax. KQL is the implementation language on the Microsoft stack — the same way SPL is the implementation language on Splunk and Lucene on Elastic. The discipline is the thinking: which threats matter for this organization, what those threats look like in telemetry, what signals distinguish attack from legitimate activity, how to test whether a detection rule works, and how to measure the result. Detection engineering operates through a six-stage lifecycle that every rule in this course follows: hypothesize, design, build, test, deploy, tune.

Four roles form the security operations cycle. SOC operations monitors and triages — consuming detection outputs. Threat hunting searches for what detection rules miss — discovering gaps. Incident response investigates and contains — producing post-mortem findings. Detection engineering builds and maintains the rules all three depend on — closing gaps systematically. In most organizations, the first three functions exist. The fourth doesn't. The detection library grows reactively and degrades over time. Detection engineering is the discipline that makes it intentional.

0.2 What you will learn

This module covers detection engineering as a discipline — what it is, why it exists, and how it's measured — before you touch a single rule configuration.

Section 0.1 — Detection Engineering — What It Is and Why It Is Important. The discipline defined. Four security operations roles and the cycle that connects them. What a detection engineer actually does day-to-day. Why the discipline formalized now. You'll run a PowerShell inventory of your analytics rules to see how old they are and when they were last modified.

Section 0.2 — Why Organizations Need Detection Engineers. Six symptoms of the missing function. What changes when the function exists. You'll run a KQL query against SentinelAudit to see how stale your detection library is.

Section 0.3 — The Detection Coverage Gap and the Illusion. Coverage percentage calculated against ATT&CK. Three layers of detection failure. You'll see your coverage number and a Sigma community rule showing the vendor-agnostic detection format.

Section 0.4 — The Microsoft Detection Surface. Five data source families. Cross-family detection and why it traces full attack chains. You'll run a PowerShell data connector inventory and a KQL cross-family join example.

Section 0.5 — Measuring Detection. Four metrics: coverage percentage, MTTD, false positive rate, rule health. Industry benchmarks for each. You'll run the rule health query and export your baseline with PowerShell.

Section 0.6 — Walking CHAIN-HARVEST. A five-phase AiTM→BEC attack walked phase by phase. JSON attack chain specification. The cross-family KQL join that detects phase 3. Interactive step-through of the detection query.

Section 0.7 — The Six Attack Chains in Detail. CHAIN-HARVEST, CHAIN-MESH, CHAIN-ENDPOINT, CHAIN-PRIVILEGE, CHAIN-DRIFT, CHAIN-FACTORY. KQL attack chain coverage query showing which chains your rules can detect.

Section 0.8 — MITRE ATT&CK for Detection Engineering. ATT&CK as the measurement standard, development framework, and communication language. Coverage-by-tactic KQL query. JSON Navigator layer for your coverage visualization.

Section 0.9 — The Detection Engineering Discipline. The six-stage lifecycle in practice. JSON rule specification template. The adversarial mindset. Measurement as accountability.

Section 0.10 — Tools and Capabilities. Sentinel, Defender XDR, KQL, the lab pack, AI integration. PowerShell workspace health check. KQL table usage query.

Section 0.11 — Creating a Detection Engineering Baseline. The seven baseline components. Data source health query with annotated output. PowerShell full baseline export. The comparison point for the capstone.

0.3 Why Microsoft Sentinel is ideal for detection engineering

Sentinel's detection architecture is built around ATT&CK at every layer. Every analytics rule accepts MITRE tactic and technique tags. The ATT&CK coverage page under Threat Management renders your coverage as a heatmap — techniques with active rules highlighted, techniques without coverage blank. You can query active rules, extract ATT&CK mappings programmatically via SecurityAlert and SentinelAudit, and produce a machine-readable coverage baseline that updates as you deploy new rules.

Five data source families feed the detection surface. Cross-family joins — SigninLogs to OfficeActivity, DeviceProcessEvents to DeviceNetworkEvents — trace attack chains across identity, endpoint, email, and cloud. No other platform on the Microsoft stack provides this breadth of telemetry with native KQL query support across all families in a single workspace.

The Defender XDR integration extends the detection surface with automated response actions that Sentinel analytics rules cannot trigger directly — device isolation, investigation package collection, app execution restriction. With the Defender portal migration, both detection engines coexist in a unified interface with a single incident queue.

0.4 How to get the best from this module

Work the sections sequentially. Section 1 produces your rule inventory. Section 3 produces your coverage number. Section 5 produces the four baseline metrics. Each section builds on the previous one.

Run every query against your own environment, not just the examples. The examples show what the output looks like. Your own workspace produces the baseline that everything in this course improves. If you don't have a Sentinel workspace yet, Section 6 walks through the developer tenant setup — the M365 E5 developer tenant with Azure free subscription provides a fully functional Sentinel workspace at no cost.

Estimated time: 8 to 10 hours. Two to three sections per session.

0.5 Module structure

• Section 0.1 — Detection Engineering — What It Is and Why It Is Important
• Section 0.2 — Why Organizations Need Detection Engineers
• Section 0.3 — The Detection Coverage Gap and the Illusion
• Section 0.4 — The Microsoft Detection Surface
• Section 0.5 — Measuring Detection
• Section 0.6 — Walking CHAIN-HARVEST
• Section 0.7 — The Six Attack Chains in Detail
• Section 0.8 — MITRE ATT&CK for Detection Engineering
• Section 0.9 — The Detection Engineering Discipline
• Section 0.10 — Tools and Capabilities
• Section 0.11 — Creating a Detection Engineering Baseline

Go to Section 0.1 — Detection Engineering — What It Is and Why It Is Important to begin.