Detection Engineering: Turning Raw Telemetry into Defensible Decisions

For decades, enterprise threat detection was treated as an operational cataloging exercise. Security administrators downloaded vendor-provided antivirus signatures, imported predefined SIEM correlation rules, and waited for an incoming log line to trigger a notification. In an era dominated by living-off-the-land techniques (LotL), fileless in-memory execution, and cloud credential hijacking, static signatures are functionally obsolete.

Modern threat actors operate using native operating system binaries (e.g., PowerShell, WMI, certutil on Windows; bash, curl, systemd on Linux) and authenticated cloud APIs. Detecting these actions requires understanding context, behavioral baseline deviations, and relational graph anomalies rather than matching static MD5 hashes or known bad IP addresses.

Detection Engineering is the disciplined application of software engineering methodologies to the problem of cyber threat identification. Rather than treating detection rules as static configuration entries stored inside a GUI, detection engineers treat rules as modular, version-controlled software assets.

"Signatures detect known tools from yesterday’s breach; detection engineering uncovers immutable adversary behaviors during today’s campaign."

The foundational paradigm of modern detection engineering is Detection-as-Code (DaC). Under this framework, detection logic is authored in standardized, vendor-agnostic formats such as Sigma or Yara-L and stored in an enterprise Git repository.

Whenever an engineer proposes a new detection rule or modifies an existing threshold, the change triggers an automated Continuous Integration (CI) pipeline. This pipeline executes static analysis, validates syntactic compliance against the enterprise data schema (e.g., OCSF), and executes automated unit tests against historical event telemetry to quantify false-positive generation before the rule is ever deployed to production.

This engineering approach eliminates accidental rule breakage, establishes comprehensive audit trails required by regulators, and allows detection teams to collaborate using familiar peer-review pull-request workflows.

title: In-Memory LSASS Process Memory Dump via Suspicious API Call
id: 8d1f054b-22d7-4638-a1c2-3e2b9c7a1234
status: production
description: Detects processes attempting to create a memory minidump of the Local Security Authority Subsystem Service (LSASS)
references:
  - https://attack.mitre.org/techniques/T1003/001/
author: Burhani Mtengwa (Mtengwa Strategic Advisory)
date: 2026-08-14
logsource:
  category: process_access
  product: windows
detection:
  selection_target:
    TargetImage|endswith: '\lsass.exe'
  selection_access:
    GrantedAccess|contains:
      - '0x0010'   # PROCESS_VM_READ
      - '0x1F0FFF' # PROCESS_ALL_ACCESS
      - '0x0040'   # PROCESS_DUP_HANDLE
  filter_legitimate:
    SourceImage|endswith:
      - '\system32\csrss.exe'
      - '\system32\svchost.exe'
      - '\Program Files\Windows Defender\MsMpEng.exe'
  condition: selection_target and selection_access and not filter_legitimate
falsepositives:
  - Legitimate administrative debugging utilities (require change authorization ticket)
level: high

In cybersecurity operations, more data is rarely better data. Indiscriminately ingesting terabytes of raw debug logs into an enterprise SIEM does not improve security posture; it merely inflates cloud storage invoices and accelerates analyst burnout.

High-velocity detection engineering teams operate a Telemetry Shaping layer at the point of ingestion. Using stream-processing frameworks like Apache Kafka, Vector, or FluentBit, raw event streams are filtered, deduplicated, and enriched before landing in permanent storage.

Low-value event noise—such as successful internal DNS queries or repetitive load balancer health checks—is dropped at the edge, while high-value security events (process creations, authentication grants, network socket binds) are enriched with asset criticality tags and user risk scores in real time.

Many security teams use the MITRE ATT&CK matrix as an administrative compliance checklist, striving to turn every square on the heatmap green by deploying a single generic detection rule. This creates a dangerous illusion of coverage.

True detection coverage is multidimensional. A single ATT&CK sub-technique (e.g., T1059.001: PowerShell execution) encompasses hundreds of distinct operational variations, obfuscation encodings, and execution wrappers. A detection rule that matches only unencoded "-enc" parameters provides near-zero defense against sophisticated adversaries.

Detection engineering treats ATT&CK as a taxonomy for continuous gap analysis and purple teaming, evaluating detection depth rather than superficial checklist breadth.

How does an enterprise know its detection rules actually function today? In most organizations, the answer is "we will find out during our annual penetration test or our next real incident."

Modern engineering teams reject this uncertainty by implementing Continuous Adversary Emulation. Using automated frameworks such as Atomic Red Team, Prelude, or Caldera, the engineering pipeline systematically executes benign, controlled attack techniques across staging and production clusters on a daily basis.

If a simulated credential dumping technique fails to trigger the corresponding detection rule within 90 seconds, a continuous integration alert is raised, treating detection degradation with the same urgency as a production software outage.

"Untested detection logic is merely an unverified hypothesis. In an engineering discipline, unverified hypotheses do not belong in production."