Transmission 09 · Detection Engineering

Detection Engineering Is Instrument Building

A detection is not a rule you turn on. It is an instrument you build: designed for a specific signal, calibrated against known inputs, versioned, tested, and retired when it no longer sounds true. Most SOCs do not have a detection engineering practice — they have an accumulation of vendor defaults nobody has ever heard ring.

Detections as code

• Every detection lives in version control with an owner, a stated hypothesis, and the attack technique it targets (map to MITRE ATT&CK explicitly).
• Changes go through review like any other code — a detection modified silently is an instrument detuned silently.
• Deployment is reproducible: the same rule set, deployed twice, yields the same coverage. Idempotence is not bureaucracy; it is how you know what you are actually running.

Test against known signals

An instrument is calibrated by playing a known note through it. Atomic red-team tests, replayed attack telemetry, and purple-team exercises are the tuning forks: if the detection does not fire against the technique it claims to catch, it is decoration. Schedule calibration; coverage claims without replay evidence are folklore.

Measure like an engineer

Per detection: true-positive rate, time-to-fire, and analyst cost per alert. Portfolio-wide: technique coverage against your actual threat model, not against the longest possible list. This is signal integrity made operational — and the metrics that matter roll up into measures of coherence, not counts of noise.

Build fewer instruments. Tune every one. We synchronize.