Topic 54

Detection Engineering

Detection Eng

Detections do not write themselves — someone has to turn knowledge of an attacker technique into a rule that fires on it, with few enough false positives that analysts trust it. Detection engineering is that discipline: treating detections as code, written against ATT&CK techniques, tested, version-controlled, and continuously improved.

This topic teaches how to write a good detection — using portable rule formats like Sigma for logs and YARA for files — and how to reason about the fidelity-versus-coverage tradeoff at the heart of the craft.

From Technique to Detection

Start with an ATT&CK technique your threat model says matters, understand its observable artifacts, and write a rule that fires on them. Detection engineering is hypothesis-driven, not "alert on everything unusual" — you decide what attacker behavior to catch, work out what it looks like in the data, and build the rule to match that, so every detection has a reason to exist.

Sigma and YARA as Portable Rules

Sigma is a vendor-neutral detection format for log events that compiles to any SIEM's query language; YARA describes file and malware patterns (Chapter 8). Portable rule formats let the community share detections and avoid lock-in — write a Sigma rule once and deploy it to whatever SIEM you run, and pull in the community's rules for techniques you have not yet covered.

A Sigma rule for the intruder's technique — a web process spawning a shell

title: Web Server Process Spawning a Shell
status: experimental
logsource:
  category: process_creation
  product: linux
detection:
  selection:
    ParentImage|endswith: ['/nginx', '/gunicorn', '/php-fpm']
    Image|endswith: ['/bash', '/sh', '/dash']
  condition: selection
level: high
# maps to ATT&CK T1059 (Command and Scripting Interpreter) via a web foothold

This rule fires when a web server process — nginx, gunicorn, php-fpm — spawns a shell, which is exactly the signature of a web-shell foothold from Chapter 6, and almost never legitimate. Written in Sigma, it compiles to any SIEM, maps to a specific ATT&CK technique, and can be tuned against Meridian's normal activity before it goes live — the whole detection-engineering loop in one small artifact.

The Fidelity-Coverage Tradeoff

A broad rule catches variants but fires on benign activity (false positives); a narrow rule is precise but misses evasion (false negatives). Every detection lives on this curve, and choosing the point deliberately is the skill. There is no universally right answer — a high-fidelity rule you can auto-block on and a broad rule you only alert on are both valid, as long as the choice was made on purpose.

Detections as Code

Version control, peer review, testing against known-good and known-bad, and measuring each rule's performance — a detection that is never tested or measured is a liability, not an asset. Treating detections as code (validated with tools like Atomic Red Team) is what keeps a rule set trustworthy as it grows, so nobody is guessing whether a rule fires on the attack or only on lunch traffic.

Sigma vs YARA vs SIEM-Native Rules

Sigma — portable log-detection rules that compile to any SIEM and are community-shareable; write once, deploy anywhere.

YARA — content patterns for files, memory, and malware (Chapter 8); the standard for file detection.

SIEM-native (SPL, KQL) — maximally expressive for one platform but locked to it. Author in Sigma and YARA for portability; drop to native for platform-specific power.

Common Mistakes

Writing detections without a technique or hypothesis, producing anomaly noise nobody can triage.
Ignoring the fidelity-coverage tradeoff — shipping rules so broad they are muted, or so narrow that trivial evasion defeats them.
Treating detections as one-off SIEM searches rather than tested, version-controlled, measured code.
Never validating rules against known-good and known-bad, so nobody knows if they fire on the attack or only on normal traffic.
Building only bespoke rules and ignoring the community's shareable Sigma and YARA coverage.

Best Practices

Write detections against specific ATT&CK techniques with a clear hypothesis about the observable artifacts.
Use portable formats (Sigma, YARA) for shareability and to avoid SIEM lock-in, dropping to native only when needed.
Manage detections as code: version-controlled, peer-reviewed, tested against known-good and known-bad, and performance-measured.
Choose the fidelity-coverage point deliberately per rule and tune it with real environment data.
Validate rules with adversary-emulation tooling so you know they actually fire on the technique.

Comparable toolsFormats Sigma · YARA · SIEM query languages (SPL/KQL)Validation Atomic Red Team · detection-as-code pipelinesCoverage MITRE ATT&CK · DeTT&CT

Knowledge Check

What makes detection engineering hypothesis-driven rather than "alert on anything unusual"?

You start from a technique and match its observable artifacts
You alert on every single deviation from a machine-learned baseline
You copy every available community rule without any selection at all
You only ever write new rules after an incident occurs

What is the fidelity-coverage tradeoff in a detection rule?

Broad rules false-positive; narrow rules miss evasion
Higher fidelity in a rule always means it has broader coverage
Coverage and fidelity are entirely unrelated, independent properties
A single rule can maximize both at once with no cost

Why is the portable Sigma format valuable for detection engineering?

One rule compiles to any SIEM and is community-shareable
Sigma rules run measurably faster than native SIEM queries
Sigma can only detect file-based malware on disk
Using Sigma removes the need to tune rules

You got correct