DE0.4 The Detection Engineering Discipline

What a detection engineer does

A SOC analyst triages alerts. A threat hunter searches for evidence of compromise. An incident responder investigates and contains confirmed threats. A detection engineer builds the system that generates the alerts the SOC analyst triages, codifies the patterns the threat hunter discovers, and prevents the incidents the responder investigates.

The detection engineer operates upstream of the SOC. The SOC’s effectiveness is bounded by the detection library it operates against — if the library contains 23 rules covering 10% of techniques, the SOC can only respond to threats that fall within that 10%. The detection engineer expands the library systematically, targeting the techniques most likely to affect the organization and most damaging if missed.

This is not a theoretical distinction. In organizations without detection engineering, the analytics rule library grows opportunistically: a rule gets added after an incident (“we should have caught that”), a vendor template gets enabled during a SIEM deployment, a consultant recommends a rule during an assessment. The result is an unplanned, untested, untuned collection of rules with no coverage strategy and no maintenance cadence. Detection engineering replaces that with a deliberate program.

Figure DE0.3 — The detection engineering lifecycle. Six stages from hypothesis to ongoing tuning, with feedback loop. Inputs feed from threat intelligence, hunting, and incidents. Outputs serve the SOC, IR team, and leadership.

The six stages

Stage 1: Hypothesize. Every detection rule starts with a hypothesis — not a query. The hypothesis states what you expect to detect, in what data source, and what conditions distinguish the attack from normal activity. “I hypothesize that AiTM credential theft produces a non-interactive token refresh from a different IP address than the preceding interactive sign-in, within a 30-minute window, where the device details do not match.” This hypothesis is testable, specific, and maps to a concrete ATT&CK technique (T1557). If the hypothesis is wrong — if the data does not contain the distinguishing signal — the detection engineer discovers this before writing the rule, not after deploying it. DE2 teaches how threat modeling produces hypotheses.

Stage 2: Design. The hypothesis becomes a rule specification document: ATT&CK technique mapping, data source, expected telemetry, KQL logic outline, entity mappings (which fields map to Account, Host, IP), severity rationale, known false positive patterns, response procedure, and tuning plan. The specification is reviewed before the KQL is written. This prevents the common failure mode of writing a query that works technically but detects the wrong thing operationally. DE1 teaches the rule specification template.

Stage 3: Build. The KQL query is written, annotated line by line, and entity mappings configured. The query is tested in Advanced Hunting before deployment to Sentinel. The detection engineer verifies that the query returns the expected results against known data — either historical attack data from a past incident or synthetic data from an attack simulation. DE3 through DE8 build rules at this stage.

Stage 4: Test. The rule is validated against historical data (does it fire on known incidents?) and tested for false positives (does it fire on legitimate activity?). The false positive rate is estimated before deployment, not discovered after. If the estimated FP rate exceeds the acceptable threshold, the rule returns to Stage 3 for refinement. DE9 teaches the testing methodology.

Stage 5: Deploy. The tested rule is deployed to the production Sentinel workspace as a scheduled or NRT analytics rule. Automation rules are configured (assign to analyst, set severity, tag, trigger playbook if appropriate). The rule is documented in the detection library with its full specification. DE10 teaches detection-as-code deployment.

Stage 6: Tune. After 7-14 days in production, the rule is reviewed: how many alerts fired, how many were true positives, how many were false positives, what patterns do the false positives share. Thresholds are adjusted, exclusions are added to watchlists, and the rule specification is updated. This review repeats monthly. Rules that consistently produce zero alerts after 90 days are reviewed for relevance (has the technique been mitigated by a preventive control?) or accuracy (is the KQL logic correct?). DE9 teaches the tuning cadence.

How detection engineering differs from adjacent roles

Detection engineer vs. SOC analyst. The SOC analyst consumes detection rules — triaging the alerts they generate, investigating incidents, and escalating. The detection engineer produces detection rules — building the detection library the SOC operates against. In small teams, the same person does both. In mature teams, the roles specialize. This course teaches the production side.

Detection engineer vs. threat hunter. The threat hunter searches proactively for evidence of compromise using ad-hoc queries. When a hunter discovers a technique that should be detected automatically, that discovery becomes an input to the detection engineering lifecycle — a new hypothesis at Stage 1. The hunter finds it once. The detection engineer builds the rule that finds it forever. Our Practical Threat Hunting course teaches the hunting methodology. This course teaches what happens after the hunter reports a finding.

Detection engineer vs. incident responder. The incident responder investigates confirmed threats and produces findings. Those findings — the specific techniques the attacker used, the telemetry they generated, the indicators of compromise — are inputs to detection engineering. The IR lesson learned “we should have detected the lateral RDP movement earlier” becomes a detection engineering hypothesis: “I hypothesize that RDP connections from user accounts to servers they have never previously accessed can be detected in DeviceNetworkEvents joined with DeviceLogonEvents.” Our Practical IR course teaches investigation. This course teaches converting findings into automated detection.

The maturity model

Detection engineering maturity exists on a spectrum. Most organizations start at Level 1 and aspire to Level 3. Level 4 and 5 represent mature practices that develop over years.

Level 1 — Reactive. Rules are added after incidents. Templates are enabled during SIEM deployment. No coverage measurement. No testing. No tuning cadence. This is where Northgate Engineering starts.

Level 2 — Structured. A detection backlog exists. Rules are prioritized by threat relevance. New rules follow a specification template. ATT&CK coverage is measured quarterly. False positives are tracked. This is where the course takes the learner by DE9.

Level 3 — Systematic. Detection-as-code with version control. CI/CD deployment pipeline. Automated testing. Monthly coverage reports to leadership. Sprint cadence for new rules and tuning. This is where the course takes the learner by DE10.

Level 4 — Proactive. Threat intelligence integration drives rule development before attacks occur. Purple team exercises validate detection. Coverage targets are set by threat model and measured against them. Detection engineering metrics are part of the security program’s KPIs.

Level 5 — Self-improving. Machine learning augments rule development. Automated false positive classification. Detection rules automatically adapt thresholds based on environmental baselines. Feedback loop from SOC triage data directly informs rule tuning.

This course builds Levels 1 through 3. Levels 4 and 5 require organizational maturity and tooling that extends beyond what a single course can deliver — but the foundation built here supports that progression.

Troubleshooting: “We do not have a dedicated detection engineer”

Most organizations do not. Detection engineering is a function, not necessarily a full-time role. In a team of 3-5 security staff, the detection engineering function is performed by the senior analyst or security engineer who allocates 20-30% of their time to rule development and maintenance. The rest of their time is SOC operations, incident response, or security architecture.

The minimum viable detection program: 4 hours per week dedicated to detection engineering. That is enough for: 2 new rules per month (2 hours each including testing), 1 tuning review per month (2 hours), and 1 coverage report per quarter (2 hours). At that pace, 24 new rules in the first year bring Northgate Engineering from 23 rules to 47, roughly doubling their technique coverage. Not transformative, but measurably better — and sustainable alongside other responsibilities.

The detection engineering sprint (DE10) scales this up: 2-week sprints with 2-4 new rules and 2-4 tuned rules per sprint. At that cadence, 48-96 new rules per year with continuous tuning. This is the cadence for a security engineer who dedicates 40-50% of their time to detection, or a team that shares the function.

References used in this subsection

• Course cross-references: DE1 (rule specification template), DE2 (threat modeling and hypothesis generation), DE3-DE8 (rule building), DE9 (testing and tuning), DE10 (detection-as-code and sprint cadence)

The rule lifecycle in KQL: from hypothesis to production

1
2
3
4
5
6
7
8
9

// RULE INVENTORY: What rules exist and when were they last modified?
// This query audits your current analytics rule estate
SentinelAudit
| where TimeGenerated > ago(90d)
| where SentinelResourceType == "Analytic Rule"
| summarize LastModified = max(TimeGenerated), Changes = count() by RuleName = SentinelResourceName
| sort by LastModified asc
// Rules not modified in 90+ days are candidates for tuning review
// Rules with 0 changes since creation were deployed and never maintained