How to Write a Detection Rule
A detection rule is a bet that a particular attacker behaviour will show up in your logs in a way you can recognise — and that you can tell it apart from the thousands of benign things that look similar. This guide walks writing one properly: from an ATT&CK technique, through telemetry and tuning, to a tested, documented, version-controlled rule.
In plain words
Writing a detection rule means turning a known attacker behaviour into precise logic over your telemetry that fires on the attack and stays quiet on everything else — and PlayCISO has a free, browser-based detection lab to build and tune one. Start from an ATT&CK technique, find the log source that evidences it, write specific logic, tune against normal activity, test both ways, then document and version it.
The whole craft is signal versus noise: a rule that catches the behaviour but buries analysts in false positives is as useless as one that never fires.
Step by step
- 1
Start from a technique, not a tool
Anchor the rule to a specific adversary behaviour — ideally a MITRE ATT&CK technique or sub-technique — rather than a single indicator or a product name. A behaviour-based detection (e.g. credential dumping via LSASS access, or a scheduled task created for persistence) survives when the attacker swaps tools or recompiles their malware, whereas a hash or IP goes stale almost immediately. Write down the exact behaviour you are trying to catch before you touch a query.
- 2
Identify the telemetry that proves it
A detection is only possible if the behaviour leaves a trace in a log source you actually collect. Map the technique to the telemetry that evidences it — process-creation and command-line logs, authentication events, EDR telemetry, DNS, cloud audit logs — and confirm that source is onboarded, parsed and retained long enough to matter. If the required field (for example, full command line) is not being logged, fixing collection comes before writing any logic.
- 3
Write precise logic
Express the behaviour in detection logic that is as specific as the evidence allows: match on the fields that genuinely characterise the technique, not incidental ones. Prefer durable conditions (a suspicious parent-child process relationship, an unusual flag combination) over brittle string matches that an attacker can trivially vary. Comment the logic and reference the ATT&CK technique so a future analyst understands intent, not just syntax.
- 4
Tune against normal to cut false positives
Run the draft rule against a window of historical data and see what it fires on. Legitimate administration, backup jobs, vulnerability scanners and developer tooling often look like the behaviour you are hunting, so refine the logic and add targeted exclusions for known-good patterns — scoped tightly, because a sloppy exclusion is a blind spot an attacker can hide in. The goal is high true-positive signal at a false-positive rate the SOC can actually sustain.
- 5
Test with positive and negative cases
Validate the rule both ways. Confirm it fires on the behaviour by replaying real telemetry or safely emulating the technique (for example with an adversary-emulation harness in a lab), and confirm it stays quiet on representative benign activity. Testing both the detection and the non-detection is what tells you the rule works, not just that it compiles and runs without error.
- 6
Document and version it
Treat detections as code. Record the technique it covers, the data source and fields it needs, the assumptions and known gaps, the severity, and the expected analyst response so triage has context when it fires. Keep the rule in version control with a changelog, so you can review changes, roll back a bad tuning, and track your detection coverage over time against the techniques that matter to your organisation.
Go from an ATT&CK technique to tested detection logic — pick telemetry, write and tune the rule, and check it against benign and malicious cases, free and in your browser.
Related
Practise triaging the alerts your detection rules generate, from validation to decision.
IR Playbook LabTurn a confirmed detection into a tested incident-response playbook with phases and roles.
Security LabsHands-on browser labs across detection engineering, SOC and incident response.
All PlayCISO toolsThe full free toolkit for security-operations and leadership practice.
Frequently asked questions
Why start from an ATT&CK technique instead of an indicator?
Because behaviours are more durable than indicators. A hash, IP or domain goes stale as soon as the attacker rotates infrastructure or recompiles their tooling, whereas a technique like credential dumping or persistence via a scheduled task describes what the adversary must do to achieve their goal. Anchoring a rule to a technique gives it a longer useful life and makes your coverage measurable against a known framework.
What if the log source I need is not being collected?
Then fixing collection comes before writing the rule — you cannot detect a behaviour that leaves no trace you are keeping. Map the technique to the telemetry that evidences it, confirm that source is onboarded, parsed and retained, and verify the specific fields you rely on (such as the full command line) are present. A detection built on a field you do not actually log will simply never fire.
How do I keep false positives under control?
Tune the rule against real historical data and refine the logic so it keys on the fields that genuinely characterise the behaviour. Add exclusions for known-good patterns like administration, backups and scanners, but scope them tightly, because a broad exclusion becomes a blind spot an attacker can hide inside. Aim for strong true-positive signal at a false-positive rate the SOC can realistically sustain.
How should I test a detection rule?
Test it in both directions. Confirm it fires on the target behaviour by replaying real telemetry or safely emulating the technique in a lab, and confirm it stays quiet against representative benign activity. Checking only that the query runs tells you nothing about whether it actually catches the attack or whether it will bury analysts in noise once it is live.
Should detection rules be version controlled?
Yes — treat detections as code. Keep them in version control with a changelog so you can review changes, roll back a tuning that widened a gap, and track coverage over time. Store the metadata alongside the logic (the technique, required data source, assumptions, severity and expected response) so anyone maintaining or triaging the rule has the context they need.
What makes a detection rule brittle?
Relying on incidental details an attacker can trivially change — a specific file name, a single string, a particular IP — rather than the essential mechanics of the behaviour. Brittle rules look fine in testing and then miss the next variant. Prefer conditions tied to how the technique works, such as an unusual parent-child process relationship or a characteristic flag combination, which an attacker cannot avoid as easily.