Detection Engineering

For Security Engineers and Detection Engineers Building Detection Programs in Microsoft Sentinel and Defender XDR

Aligned to MITRE ATT&CKSigma rulesCISA KEVMandiant tradecraft

Detection Engineering

Write detection rules that catch real attacks and survive production.

Build a detection engineering program from threat model to deployed rule. Prioritize techniques using crown jewel analysis, write Sigma and KQL detection rules against real attacker telemetry, test rules with synthetic and live data, tune false positives systematically, and operate a detection-as-code pipeline. You finish with 71 production rules deployed, an ATT&CK coverage map, and the methodology to take any technique and ship a validated detection.

What you'll deploy
71 production KQL detection rules mapped to 6 attack chains
Detection-as-code pipeline with Git, CI/CD, and peer review
ATT&CK coverage heatmap with risk-prioritized gap analysis
Sigma rules convertible to KQL, SPL, and Elastic Query DSL
DETECTION ENGINEERING — ATTACK CHAIN COVERAGE CHAIN-HARVEST AiTM → BEC → Financial fraud 5 detection points: phishing, token theft, inbox rule, email collection, wire fraud CHAIN-MESH Ransomware via SD-WAN lateral movement 7 detection points: VPN compromise to pre-encryption indicators CHAIN-ENDPOINT Watering hole → Cobalt Strike → crown jewels 7 detection points: drive-by, beacon, LSASS, PtH, recon, file share, C2 exfil CHAIN-PRIVILEGE Insider PIM abuse → app registration persistence 5 detection points: role activation, app creation, mailbox access, exfil, cover tracks CHAIN-DRIFT Config change exploit 4 points: CA gap → spray → persist → exfil CHAIN-FACTORY Physical USB theft 5 points: USB → exec → recon → copy → exfil 71 rules 6 chains 13 modules 36–40 hours From 10% ATT&CK coverage to defensible, risk-prioritized detection
View Pricing Download Lab Pack Take End of Course Exam → 40 CPE Credits

What you'll be able to do

Build a detection engineering program from threat model to deployed rule
Write Sigma and KQL detection rules against real attacker telemetry
Test and tune rules to achieve acceptable false positive rates
Operate a detection-as-code pipeline with version control and peer review
Measure and report detection coverage using ATT&CK mapping
Premium tier | 13 modules across 4 phases | 36–40 hours at your own pace | 40 CPE credits | 2 free modules — no account needed | Updated May 2026
Course Agenda View all 14 modules

Who this course is for

“I triage alerts all day but I want to write the rules.” You know what good alerts look like because you’ve investigated thousands of bad ones. You need the methodology to go from “I can spot the pattern” to “I can ship a production detection rule with entity mapping, FP analysis, and ATT&CK coverage.” This course builds that bridge.

“Our Sentinel workspace has 40 template rules we’ve never tuned.” Templates fire on everything and nothing. Half are disabled because they generated too many false positives. The other half haven’t been reviewed since deployment. This course replaces the template approach with rules designed against your actual threat landscape.

“I know detection engineering from Splunk or Elastic and I’m migrating to Microsoft.” The methodology transfers. The implementation doesn’t. KQL syntax, Sentinel analytics rule architecture, Defender XDR custom detections, entity mapping, and the Microsoft data model are all different. This course gets you productive in the Microsoft stack.

“My CISO asked for an ATT&CK coverage report and I have no idea where to start.” You need to know what your detection rules cover, what they miss, and how to prioritize the gaps. This course builds the coverage measurement methodology — crown jewel analysis, risk-weighted technique prioritization, and the board-ready report that justifies the detection program.

“I write KQL rules but I don’t have a process for testing them before production.” You deploy a rule and find out it generates 300 alerts on day one. Or worse — it generates zero because the query logic doesn’t match the actual data format. This course teaches systematic testing: synthetic data, Atomic Red Team validation, historical backtesting, and staged deployment.

“We need detection-as-code but nobody on the team has built a pipeline.” Detection rules in the portal are unversioned, unreviewed, and unrecoverable if someone deletes them. This course builds the Git-backed pipeline: version control, peer review, CI/CD deployment, and the rule lifecycle management that turns ad-hoc rule creation into an engineering discipline.

Whatever your background — if the subject interests you and you’re willing to put in the work, this course is for you.

Before and after this course

Before

Your Sentinel workspace has template analytics rules that fire on everything or nothing. Half are disabled. The other half haven’t been reviewed since the day they were enabled. Nobody can explain what any rule detects or why the threshold is set where it is.

A new threat advisory drops and you search for a template rule. There isn’t one. You don’t know how to write a detection rule from a technique description, test it against your data, and deploy it to production.

Your CISO asks what percentage of ATT&CK techniques your SOC can detect. You don’t have a coverage map. You don’t have a way to build one. You guess “maybe 15%” and hope nobody asks how you measured it.

Detection rules live in the Sentinel portal. No version control, no peer review, no deployment pipeline. When a rule breaks or gets deleted, there’s no way to recover it or trace what changed.

After

71 production detection rules, each with documented ATT&CK mapping, entity mapping, severity rationale, FP analysis, and tuning history. Every rule designed against a specific attack technique, tested against real data, and deployed through a governed pipeline.

A new advisory drops and you have the methodology: extract the technique, map the telemetry, write the KQL, test with Atomic Red Team, backtest against 30 days of data, and ship through your detection-as-code pipeline. Rule in production the same day.

Your ATT&CK coverage map shows exactly which techniques are detected, which are partially covered, and which are gaps. The coverage is risk-weighted against your crown jewel analysis. The board report shows detection improvement quarter over quarter.

Every detection rule is version-controlled in Git. Changes go through peer review. Deployments are automated via CI/CD. Rule health metrics track TP rate, FP rate, and MTTD. The detection program is an engineering discipline, not a collection of portal configurations.

How the course works

Four phases build from detection foundations through technique coverage to program operations. Each phase produces deployed detection rules:

Phase 1
Foundations

The detection gap, Sentinel analytics rule architecture, rule types (scheduled, NRT, anomaly, fusion), entity mapping, threat modeling, and crown jewel analysis. You understand the engineering before you write the rules.

Phase 2
Technique Detection

Six modules, one per ATT&CK tactic cluster: initial access, credential & identity, persistence & execution, discovery & evasion, collection & exfiltration, lateral movement & impact. 71 rules across 6 attack chains.

Phase 3
Operations

Testing with Atomic Red Team, systematic FP tuning, watchlist-based exclusions, detection-as-code with Git and CI/CD, rule health metrics, and coverage measurement. The engineering discipline that sustains the program.

Phase 4
Capstone & AI

Full capstone: threat model a new attack chain, write the detection rules, test, tune, and deploy. Plus AI-accelerated detection engineering — using AI to generate rule hypotheses, accelerate Sigma conversion, and review detection logic.

What the content looks like

This is a real detection rule specification from the credential theft module. Before you write any KQL, you design the rule on paper — the threat it detects, the data it queries, the false positives it will generate, and the tuning strategy that makes it production-ready:

Detection Rule Specification — From Module 4: Credential & Identity Detection

Rule name: LSASS access from non-system process

MITRE mapping: T1003.001 — OS Credential Dumping: LSASS Memory

Data source: DeviceProcessEvents (MDE) — ProcessCommandLine, InitiatingProcessFileName

Severity: High — credential access is pre-lateral movement; detection here prevents the next 5 stages

Known FPs: AV/EDR scanning lsass.exe (CrowdStrike, SentinelOne, Windows Defender). IT management tools using WMI to query process memory. Exclude via watchlist WL-LSASS-Approved.

Entity mapping: Account (AccountName, AccountSid), Host (DeviceName), Process (InitiatingProcessFileName)

Tuning strategy: Deploy with 7-day lookback. If FP rate >5% in week 1, add approved processes to WL-LSASS-Approved. Review monthly — new legitimate tools appear, new attack tools evade. Never tune by raising the threshold.

The specification tells you why this rule exists (credential access precedes lateral movement), what will break it (AV scanning lsass.exe), and how to fix the false positives without weakening the detection. Every rule in this course starts as a spec before it becomes KQL. Every module teaches at this level — spec first, then code, then test, then deploy.

Lab Pack — Detection Engineering Toolkit

Downloadable lab pack covering the full detection engineering lifecycle. Realistic-volume evidence data across 8 Sentinel tables with all 6 attack chains buried in 14 days of legitimate noise, plus detection rules in 6 formats, a Sysmon configuration, threat model artifacts, and program management templates.

Evidence data (~3,500 entries): SigninLogs, AuditLogs, EmailEvents, DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents, DeviceRegistryEvents, SysmonEvents — all with attack indicators hidden in baseline noise.

Detection rules (6 formats, ~80 files): 10 KQL rules, 10 Sigma rules (convert with sigma-cli), 5 YARA rules, 30+ auditd rules by tactic, 7 Suricata rules, 7 Velociraptor VQL hunts.

Program artifacts: ATT&CK coverage matrix (30 techniques), NE threat profile, detection-as-code Git structure, FP register with classification guide, 3 tuning case studies, Atomic Red Team test mapping, Sysmon config.

Detection Engineering Lab Pack
~80 files · 6 rule formats · ~3,500 evidence entries · Sysmon config · ATT&CK coverage matrix
Download Lab Pack (.zip)

Usage rights and disclaimer

Course materials: Licensed for individual professional development. You may deploy detection rules in your organization’s production Sentinel workspace. You may not redistribute course content, share account credentials, or republish course materials.

Detection rules: Provided as-is for deployment. Test every rule against your environment’s data before enabling in production. Ridgeline Cyber Defence is not responsible for operational impact from deployed rules.

Fictional environment: All scenarios use the fictional Northgate Engineering environment. Any resemblance to real organizations is coincidental.

Version and changelog

Current version: 2.0  |  Last updated: May 2026

May 2026 — v2.0: Course page restructured. Lab pack with detection rules in 6 formats, Sysmon config, ATT&CK coverage matrix, threat profile, FP register, and tuning case studies.

2026 — v1.0: Course launch. 13 modules (DE0–DE12). 71 production KQL detection rules. 6 attack chains.

This course is actively maintained. Detection rules are updated as the Microsoft security platform and threat landscape evolve.

COURSE ASSESSMENT

End of Course Exam

Complete the course, then prove your skills under time pressure. Pass mark: 70. Earn your certificate with CPE credits.

40minutes
3phases
100points
3scenarios
Take End of Course Exam

Requires 80% course completion. One random scenario per attempt. Certificate issued on pass.