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.

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.

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.

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

// 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