Detection Engineering: Turning Telemetry Into Alerts That Matter

Most organisations discover the same thing a few months after deploying a detection platform: default rules generate either too much noise or too little signal. Detection engineering is the discipline that closes that gap — treating detections as code that is written, tested, versioned and retired deliberately rather than accumulated by accident.

Why default rules are not enough

Out-of-the-box content is written for a generic environment. Yours is not generic: it has administrative tooling that looks suspicious, scheduled jobs that resemble persistence, and legitimate scripts that trip generic heuristics.

The result is predictable. Teams either suppress broadly, creating blind spots, or leave the noise in place until analysts learn to ignore that rule entirely — which is functionally the same as disabling it, but harder to audit.

The pyramid of pain, applied

A useful model for prioritising what to detect ranks indicators by how costly they are for an attacker to change.

File hashes are trivial to alter. IP addresses and domains are cheap to rotate. Tools take more effort to replace. Techniques and behaviours — how an attacker actually achieves persistence or moves laterally — are expensive to change because they reflect how the intrusion works.

Detections built on behaviour therefore survive far longer than detections built on indicators. Indicator feeds still have a place, but a detection programme resting entirely on them is rebuilt continuously.

The detection lifecycle

1. Hypothesis — state the behaviour you want to catch, ideally mapped to a specific ATT&CK technique relevant to your threat model.
2. Data check — confirm you actually collect the telemetry required. Most detection ideas die here, and that is useful information about coverage gaps.
3. Write — express the logic, preferably in a portable format such as Sigma so it is not locked to one platform.
4. Test positively — generate the behaviour safely in a lab or with an atomic test and confirm the rule fires.
5. Test negatively — run it against historical data to measure how often it fires on normal activity. This is the step most often skipped, and it determines whether analysts will trust the rule.
6. Document — record what it detects, what it does not, and exactly what an analyst should do when it fires.
7. Maintain — review periodically. Environments change and rules silently rot.

Writing rules analysts can act on

• Every alert needs a triage path. If the documentation cannot say what to check first, the rule is not finished.
• Include context in the alert — the account, host, parent process and preceding activity — so triage does not begin with ten minutes of manual lookup.
• Set severity honestly. If everything is critical, nothing is.
• Prefer several precise rules over one broad rule with many exceptions; exceptions accumulate and become impossible to reason about.
• Track per-rule false-positive rates and treat a rising rate as a defect to fix, not noise for analysts to absorb.

Measuring coverage honestly

Mapping detections to ATT&CK produces a coverage map, which is genuinely useful — provided it is read carefully. A technique marked "covered" by one narrow rule addressing one variant is not the same as robust coverage.

The honest version records what each detection catches and what it misses, and pairs the map with validation results proving the rule fires against a real test. Purple-team exercises are the most direct way to produce that evidence.

Related from TechBiz Security

• SOC services
• Threat hunting
• Purple team exercises

Sources & further reading

• MITRE ATT&CK
• Sigma — generic signature format for SIEM systems
• Atomic Red Team
• MITRE ATT&CK — Working with ATT&CK

Frequently asked questions