Detection Requirements

What is it?

A detection requirement states precisely what behavior must be detected, why it matters, and how success will be judged — before any logic is written. A good requirement is specific and testable ('detect an Office application spawning an encoded PowerShell child process'), not vague ('detect malware').

Why it matters

The requirement is the contract the detection is measured against. Without it there is no way to know whether a rule succeeded, and no basis for testing or tuning.

Where you see it

The first line of every detection ticket: the behavior to catch, its threat basis, and its success criteria.

What normal looks like

A requirement naming a specific, observable behavior with a threat rationale and a testable success condition.

What suspicious looks like

Not applicable directly — this is the specification step.

How analysts investigate

By writing a specific, behavior-level requirement tied to a real threat before touching logic, so testing and tuning have a target to measure against.

Common beginner mistakes

Starting from vague goals like 'detect ransomware' — untestable and unbounded, it produces either a rule so broad it is all false positives or so narrow it misses everything.

"Detect ransomware" is not a requirement — it is a wish. A Jisr detection requirement reads: "Detect a process rapidly enumerating and modifying many files across shares within a short window (candidate pre-encryption behavior), on file servers, from a non-backup account." Specific, observable, threat-based, testable. Now testing has a target and tuning has a boundary.

Quick check

Which is a usable detection requirement?

A quick self-check — it doesn't affect your XP or progress.