Detection Engineering

TheoryMedium15 minDetection EngineeringSIEM Operation

From Behaviour to Rule: What Detection Engineering Is

What is it?

Detection engineering is the discipline of turning a known adversary behaviour into a reliable, automated rule that fires when that behaviour recurs. It is a lifecycle, not a one-off: a hypothesis or a piece of intelligence becomes a detection, which is tested, tuned, deployed, and then maintained as the environment and the adversary change. A good detection targets a technique (a durable behaviour), not a single indicator (a brittle artefact).

Why it matters

Analysts do not scale; detections do. A SOC cannot manually watch for every technique on every host, so the leverage comes from encoding hard-won knowledge into rules that run continuously. This module is where the confirmed TTP handed over by threat intelligence becomes lasting defensive value — a technique seen once is caught automatically forever after, provided the rule is engineered well.

Where you see it

Detections live as rules and queries in the SIEM, EDR and detection-as-code repositories, often written in a portable format (such as Sigma) and version-controlled like software. They are fed by the same telemetry you have read all path long — process events, logs, network records — and their alerts land back in the analyst queue.

What normal looks like

A healthy detection is specific to a behaviour, documented with what it catches and why, tested against both real attacks and normal activity, and owned by someone who maintains it. Its alerts are rare and mostly true, so analysts trust them.

What suspicious looks like

A poor detection is built on a brittle indicator (a single hash that changes next build) or an over-broad condition (every use of a common tool). The first misses the very next variant; the second buries the team in false positives until they mute it — and a muted rule detects nothing. Both are engineering failures, not bad luck.

How analysts investigate

Start from the behaviour, not the artefact. Take the confirmed TTP, express the parent-child, command-line or network pattern that defines it, write the smallest rule that captures that pattern, and immediately ask what benign activity it would also catch. Then test, tune and document before you trust it.

Common beginner mistakes

Writing a detection on a single hash or IP — it breaks the moment the attacker changes it.
Deploying a rule without ever asking what benign activity it will also fire on.
Treating a detection as done once written, instead of a living rule that must be maintained.

What you will be able to do

Describe the detection lifecycle from hypothesis to maintenance.
Explain why a behaviour-based detection is durable and an indicator-based one is brittle.
Turn a confirmed TTP into the smallest rule that captures it.

You have spent this path reading attacks after they happened. Detection engineering flips that: you encode what you learned so the machine catches it next time. The unit of a good detection is a behaviour — a parent that should never launch a child, a command line no legitimate use produces — because behaviour is expensive for the attacker to change, while a hash or IP is free.

  DETECTION LIFECYCLE  (it loops — a rule is never 'done')

  intel / hypothesis --> BUILD --> TEST --> TUNE --> DEPLOY
        ^                                              |
        |                                              v
        +---------------- MAINTAIN <-------------------+
                     (environment & adversary change)

A detection is a living thing: built from a hypothesis, tested, tuned, deployed, then maintained as the world changes — which feeds the next hypothesis.

Step by step for turning a TTP into a rule: (1) state the behaviour precisely (which parent, which child, which arguments); (2) write the smallest selection that captures it; (3) list the benign activity that also matches; (4) add exceptions for those; (5) test against a real example and against normal data; (6) document and assign an owner.

Worked example — hash rule or behaviour rule?

# Option A — indicator-based (brittle)
detection:
  file_hash: 9f2b...c41   # today's build only

# Option B — behaviour-based (durable)
detection:
  parent_image: '*\WINWORD.EXE'
  child_image:  '*\powershell.exe'
  command_line: '*-enc*'        # encoded, hidden execution
  condition: parent AND child AND command_line

Same intrusion, two rules. Before reading on, decide: which one still catches the attacker after they rebuild the payload?

The answer: Option B. Option A matches one file hash; the attacker recompiles and the hash changes, so the rule goes blind on the very next build — it detects only history. Option B targets the behaviour: a document application spawning an encoded PowerShell child. To evade it the attacker must abandon the whole technique, which is far more expensive than changing a hash. That is the entire thesis of detection engineering — engineer for the behaviour, because the behaviour is what the attacker cannot cheaply change.

Recap

Detection engineering encodes a behaviour into an automated rule — analysts don't scale, detections do.
Target the technique (durable), not a single indicator (brittle).
A detection is a lifecycle — build, test, tune, deploy, maintain — never 'done'.