Most detection rules just fire. Here's why.

Walk into most SOCs and the detection ruleset tells the same story: a few hundred rules, most of them written once, deployed, and never touched again. They fire when their exact condition is met and stay silent otherwise. Nobody planned for that to be the end state - it's just what happens when rule-writing is treated as a one-off task instead of an ongoing discipline. Three habits get you there.

1. The condition is static because static was fastest

Under deadline pressure, the fastest rule to ship is one keyed to something you can see right now - a file hash, a specific process name, a literal string in a command line. It works immediately, it's easy to test, and it closes the ticket. What it doesn't do is survive the next minor variation, because it was never built to generalise past the exact sample that prompted it.

This isn't a criticism of writing static rules - sometimes the condition genuinely is static and no amount of enrichment changes that. The problem is when static becomes the default for everything, including detections where the underlying behaviour is anything but fixed.

2. Enrichment was somebody else's job

A rule that could check asset criticality, user role, or a live threat intel feed instead just alerts flat, leaving that context for the analyst to look up by hand at 2am. Enrichment usually isn't skipped because nobody thought of it - it's skipped because it requires a maintained data source, and maintaining a data source is a different job to writing a query. Nobody owns the join.

The fix isn't more enrichment for its own sake. It's picking the handful of rules where the context genuinely changes the verdict, and making sure that context is live rather than static at the point the rule was written.

3. No rule has an owner once it ships

The most common reason a rule quietly stops working isn't a clever evasion - it's that the environment changed underneath it and nobody was watching. A log source got reconfigured, a field got renamed, a service migrated. The rule didn't break loudly; it just stopped catching anything, and because nobody owned it, nobody noticed.

Ownership doesn't have to mean one engineer per rule. It means someone, on some cadence, is checking that the rule still does what it was written to do against current data - not just that it still exists in the ruleset.

What changes when a rule has to earn its alert

The rules worth the extra effort are the ones where a false negative is expensive and a static condition genuinely can't keep up - credential misuse, lateral movement, anything an adversary can trivially reword. For those, enrichment and adaptive baselining aren't nice-to-haves, they're the difference between a rule that catches the second attempt and one that only ever catches the first.

For everything else, a well-maintained T1 rule with a clear owner beats an ambitious T3 rule nobody checks on. The goal was never to make every rule as complex as possible - it's to know which ones deserve the investment, and to actually make it.