Writing detection rules that don't cry wolf

Every SOC inherits the same problem eventually: a detection rule that looked precise in the lab starts firing on legitimate admin activity three weeks into production, and by month two someone has quietly muted it. The rule isn’t wrong, exactly — it’s just untested against the noise of a real environment.

A few habits have saved me from that fate more than once.

Baseline before you write the condition

Before writing a single match clause, pull two weeks of the relevant log source and ask what normal looks like. Scheduled tasks, backup agents, and monitoring tools all generate events that look suspicious in isolation. If you skip this step, you’re not writing a detection rule — you’re writing a hypothesis you haven’t tested.

Scope the rule to intent, not to a single IOC

A rule built around one specific command line survives until the next campaign changes a flag. A rule built around the behaviour — process ancestry, unusual parent-child relationships, timing — survives longer and generalises to variants you haven’t seen yet.

process.parent.name: "winword.exe"
process.name: ("powershell.exe" OR "cmd.exe")
process.args: "*-enc*"

That’s still a narrow example, but the principle holds: office applications spawning encoded PowerShell is a pattern, not a signature.

Give every rule an owner and an expiry

Rules without an owner rot silently. Attach a name, a review date, and a one-line rationale to every rule you ship. When it starts misfiring, whoever’s on shift should be able to find out why it exists in under a minute — not spend twenty minutes reverse-engineering intent from a query string.

None of this is exotic. It’s just the difference between a detection rule that survives contact with a real environment and one that gets muted before it ever catches anything.