Wide uses the full column for everything, text, diagrams, code, and exercises. Narrow keeps the standard reading width.
Text size
Scales the body text. Headings and code blocks keep their size.
In this section
▾
Threat Detection Engineering on Microsoft Sentinel: Course Orientation
Module 0
THREAT DETECTION ENGINEERING · MODULE 00
Decide what your SOC can see, then build, test, and ship the detections that make it true.
By the end of this course you take any attacker technique and ship a validated detection for it: hypothesis to rule to test to production, measured against ATT&CK and tuned against noise. This module shows you what you will build, where you will build it, and how the course gets you there.
13 modules
across 4 phases
71 rules
production KQL you build
Sentinel + XDR
the Microsoft detection surface
No prerequisites
every concept built up
Why this course exists
Every organization is under continuous attack: identity compromise, ransomware, business email compromise, data theft. The SOC can only act on what it can see, and what it can see is decided entirely by its detection rules. Yet in most organizations nobody owns those rules. The library is whatever the vendor shipped plus whatever someone bolted on during an incident, it is never measured, and it quietly decays as the environment and the threat landscape move underneath it.
That gap has a name and a number. Measured against MITRE ATT&CK, most organizations detect a fraction of the techniques used against them, and they cannot tell you which fraction. Detection engineering is the discipline that closes it on purpose: deciding which techniques matter, designing logic that separates attack from legitimate activity, proving that logic works, and maintaining it over time. SOC triage, threat hunting, and incident response all depend on the rules this discipline produces. This course builds the capability to own them.
What you will be able to do
This course is built around what you can do at the end, not what you have read. Every module puts you through the six-stage lifecycle, hypothesize, design, build, test, deploy, tune, until shipping a validated detection is routine.
Write detections from a hypothesis
Turn an attacker technique into KQL detection logic that separates the attack from legitimate activity, with documented specification and ATT&CK mapping.
Cover the attack chain
Build detections across initial access, credential abuse, persistence, discovery, exfiltration, and lateral movement, tracing chains across identity, endpoint, email, and cloud.
Test and tune systematically
Validate rules against attack data before production, then classify every false positive by root cause and drive the rate down on a cadence.
Measure coverage honestly
Calculate ATT&CK coverage, MTTD, false-positive rate, and rule health, and report them in terms a board understands.
Run detection as code
Put rules under version control with CI/CD deployment and review, so detections survive personnel changes instead of living in one person's head.
Ship any technique
Leave with a repeatable method to take a technique you have never seen before and produce a validated production detection for it.
You also leave with artifacts you keep: 71 production KQL detection rules, a detection-as-code pipeline, a prioritized detection backlog, a measured coverage baseline, threat-model documentation, and a board-ready program report.
The environment you will work in
You build against the Microsoft detection surface: five data-source families, identity sign-in and audit logs, endpoint and device events, email, cloud apps, and audit activity, all landing in a Microsoft Sentinel workspace alongside Defender XDR. Sentinel is built around ATT&CK at every layer: rules carry tactic and technique tags, coverage renders as a heatmap, and cross-family joins let a single detection trace an attack chain across identity, endpoint, email, and cloud. That breadth in one queryable workspace is why the course teaches on this stack.
You practice on a downloadable lab pack built for this: realistic-volume evidence across eight Sentinel tables, with six full attack chains buried in fourteen days of legitimate noise, plus reference rules in six formats, a Sysmon configuration, threat-model artifacts, and program templates. The discipline is the point, not the vendor. KQL is the implementation language here, the same way SPL is on Splunk and Lucene on Elastic, so what you learn ports to any SIEM you work on.
How the course is built
Thirteen modules move through four phases: you learn the discipline and the rule-building craft, then build detections across the whole attack chain, then operate and scale the program, before the capstone proves it end to end.
What you need and who this is for
There are no prerequisites, and every concept is explained the first time it appears. This course is for anyone who wants to learn to build detections, SOC analysts who want to move upstream from triage, threat hunters who want to codify their findings into production rules, security engineers specializing into detection, and responders who want to catch the next incident in the first hour instead of investigating it for three weeks.
Transferable discipline
The thinking, which threats matter, what they look like in telemetry, how to prove a rule works, transfers to any SIEM. KQL is the implementation language here; the method ports to Splunk, Elastic, and beyond.
Helpful, not required
A Sentinel workspace lets you run everything live; a free M365 E5 developer tenant gives you one at no cost. Without one, the lab pack and on-page output let you follow every step.
How to get the most
Build every rule, run it against the lab data, and predict each result before you reveal it. You measure your own coverage baseline early and improve it for the rest of the course.
Do I already know this material?
Six quick scenarios across the full range of this course, from the fundamentals of a good detection to running a detection program. Answer them to find out where you sit, and whether this course fits or it will sharpen knowledge you already have.
You write a detection that fires on every PowerShell execution with an encoded command. It catches the technique but generates 200 alerts a day, almost all benign admin activity. What is the core problem?
The rule makes no allowance for the base rate of legitimate use; a good detection is scoped by what is anomalous in context, not by the mere presence of a technique.
Detection quality is precision under real base rates, not coverage of a technique. A rule that fires on common legitimate behaviour buries the true positives. You scope to the anomalous slice, by parent, context, or rarity, rather than the technique alone.
The rule is too narrow and should be widened.
PowerShell should not be monitored at all.
The SIEM is misconfigured.
You have limited time to build detections. How should you decide what to build first?
Build a detection for every ATT&CK technique to maximise coverage.
Build whatever has the most ready-made public rules available.
Start with the techniques most likely against your environment and highest in impact, driven by a threat model, rather than chasing total coverage.
Coverage for its own sake spreads effort thin. Threat-model-driven prioritisation puts detection where the likely, high-impact attacks are, which is where it earns its keep first.
Start with whichever techniques are easiest to detect.
A detection keyed to a specific malware file hash worked last week but missed the same actor this week. What happened, and what is the better approach?
The SIEM dropped the log; re-onboard the source.
The hash changed, which is trivial for the attacker; key the detection to the behaviour the technique requires, not to a brittle indicator the attacker controls.
Indicators like hashes sit at the bottom of the pyramid of pain and cost the attacker nothing to change. Detecting the behaviour that the technique cannot avoid is durable; detecting a swappable artifact is not.
The actor stopped using that technique entirely.
Hashes never work; switch to IP blocklists instead.
Your lateral-movement detection fires correctly in the lab but never fires in production. The detection logic is sound. What do you check first?
Rewrite the detection logic from scratch.
Assume the attacker is simply not present and move on.
Raise the alert severity so it stands out.
Whether the telemetry the rule depends on, the specific events and fields, is actually being collected and onboarded in production.
Sound logic over absent data produces silence. The first failure mode of a non-firing detection is a data dependency that holds in the lab but is not onboarded in production. Confirm the inputs before touching the logic.
Six months after deploying a detection, it has not fired once. What is the most important thing to determine, and how?
Whether it is silently broken, by a schema or field change or an onboarding gap, versus genuinely having no true positives; you determine this by testing it with a controlled emulation of the technique, not by waiting.
Silence is ambiguous: it can mean clean, or it can mean broken. The only way to tell is to fire the technique in a controlled way and confirm the detection responds. Detection lifecycle is active validation, not assumption.
Assume it is working as intended and move on.
Delete it; an unused rule is just noise.
Lower its threshold so it fires more often.
Your team manages 300 detections by editing them directly in the SIEM console. Changes are frequent and occasionally break things in production. Which practice most directly addresses this?
Freeze all detection changes.
Manage detections as code in version control, with peer review and automated testing in a pipeline, so every change is reviewable, testable, and reversible.
Console editing has no review, no test, and no rollback. Detection as code brings the discipline of software change to detections: peer review catches mistakes, automated tests catch regressions, and version control makes any change reversible.
Reduce the number of detections to something manageable.
Give only one person edit access to the console.
This course is for you.
You will build detection from the ground up: rule architecture, threat-model-driven prioritisation, detecting across the full kill chain, and the testing and lifecycle that keep detections working in production.
You have the fundamentals. The value here is the harder half.
You understand what makes a detection good, so the payoff is the back half: detecting across every tactic, testing and tuning, detection as code, and running a detection program end to end.
You handled rule quality, durable design, lifecycle, and program practice, the senior end of the discipline. Take the course to sharpen what you have, close the gaps you did not expect, and turn strong instincts into a repeatable detection program.
You are a student of this course now, so start by deciding what you want from it. Are you here to build a detection capability from nothing, to raise a coverage number you can already measure, or to move from triaging alerts to owning them? Name that outcome, then turn it into a study plan: which phases matter most to you, how much time you will give it each week, and what you want to be able to ship by the time you finish.
The rest of Module 0 sets you up to do exactly that. Work through it to define detection engineering, see your own coverage gap, walk a real attack chain, and produce the baseline that everything in this course improves. Then begin Module 1.
Stuck on this lesson?
Your question goes straight to the team and we'll reply by email. Sign in to ask.
