engineering-detections

Engineering Detections

A detection is a hypothesis about attacker behaviour, expressed as a query, that a human will be paged for. Two properties decide whether it is worth deploying: does it fire on the behaviour, and does it stay quiet otherwise. Most rules fail the second test, and the cost is paid by whoever is on call.

When to Use

• Writing a new detection rule from a TTP, a sample, or an incident
• Reviewing or tuning an existing rule that is noisy or silent
• Converting threat intelligence into deployable detection content
• Assessing detection coverage against ATT&CK
• Setting up detection-as-code: repo layout, testing, CI, deployment

When NOT to Use

• Searching for an unknown compromise right now — use hunting-threats
• Working an active incident — use responding-to-incidents
• Analyzing the sample the detection is for — use analyzing-malware
• Authoring a file/memory signature — use writing-yara-rules; a log/SIEM rule — use writing-sigma-rules
• Preventive controls and hardening — hardening is not detection; a rule is not a substitute for closing the path

Route to a Depth Skill

This skill covers the whole detection lifecycle across Sigma, YARA, and Suricata; reach for writing-sigma-rules when the task is the Sigma rule itself and its conversion to a target SIEM.

Detect Behaviour, Not Artifacts

Rank what you write by how expensive it is for the adversary to change:

Hash              trivial to change      → block, don't alert
IP / domain       days                   → block + low-severity alert
Filename / path   trivial                → weak signal, combine only
Tooling artifact  weeks (recompile)      → good, decays
Behaviour / TTP   expensive              → this is the target

The pyramid-of-pain reasoning is the whole discipline: a rule on mimikatz.exe is worthless; a rule on a process opening a handle to LSASS with PROCESS_VM_READ catches every tool that does the same thing.