It Fired.
That Was Never The Hard Part.
The judgment calls that apply whether the rule is written in YARA, Sigma, or Suricata: false-positive reduction, ATT&CK mapping discipline, and testing before a rule ever reaches production. See the YARA, Sigma, and Suricata/Snort guides for the syntax itself.
Rule Anatomy, Universally
Strip away the syntax and every detection rule, regardless of tool, shares the same four parts.
The Four Parts Every Rule Has
1. Trigger Condition The pattern or event that fires the rule: a string match, a field comparison, a behavioral sequence └── This is the only part most people think about when they say "write a rule" 2. Context / Enrichment Asset criticality, user role, time-of-day — the data that turns a raw match into an actual risk score └── The same trigger on a domain controller and a kiosk workstation should not carry equal weight 3. Suppression / Threshold Rate-limiting a pattern that's real but noisy by nature, so a legitimate signal doesn't drown the queue // a brute-force alert without a threshold fires on the third failed login exactly as loud as the three-hundredth 4. Response Action Alert-only vs auto-block, and critically, who actually sees the alert and what they're expected to do with it └── A rule with no defined response action is a rule nobody is accountable for acting on
False Positive Reduction Techniques
A rule that's always right and never fires isn't useful. A rule that fires constantly and is usually wrong gets ignored. The craft lives between those two failure modes.
TECHNIQUE
Document Every Allowlist Entry
Why it's excluded matters as much as that it is
An allowlist entry with no documented reason becomes technical debt nobody can safely remove. Record what it is, why it's excluded, and who approved it, or the exclusion outlives the justification for it.
TECHNIQUE
Enrich Before You Score
The same event means different things on different assets
A raw match against a domain controller carries different weight than the identical match on a kiosk workstation. Pull in asset criticality and user role before the alert is scored, not after.
TECHNIQUE
Threshold And Frequency Analysis
Volume changes the story
One occurrence of a borderline pattern is noise. Five occurrences from the same source in ten minutes is a pattern. The rule's job is to tell the difference, not just to notice the pattern exists.
TECHNIQUE
Correlate Weak Signals
Three forgivable things together are not forgivable
Three individually weak indicators occurring together are stronger evidence than any one of them alone. This is the entire premise behind detection stacking: no single condition has to carry the whole rule.
ATT&CK Mapping Discipline
A tag is either useful triage information or it's decoration. The difference is specificity.
DISCIPLINE
Tag The Technique, Not The Tactic
"Persistence" tells an analyst nothing actionable
A tactic like "persistence" gives an analyst no idea what artifact to expect. A technique ID like T1547.001 tells them exactly where to look. Tag the specific technique every time one applies.
DISCIPLINE
A Wrong Mapping Is Worse Than None
Misleading beats uninformative
An over-broad or incorrect technique tag actively misleads triage and any later coverage-gap analysis built on top of it. If you're not confident in the mapping, leave it off rather than guess.
DISCIPLINE
Use Mapping For Coverage Analysis
Where detection is actually thin, not where it feels thin
Plot every tagged rule against the ATT&CK matrix to see real coverage gaps. A gut sense of "we're probably fine on lateral movement" is not the same as a matrix showing zero rules mapped to that tactic.
Testing Before Deploy
A rule that has never been tested against anything but the sample that inspired it is a rule that hasn't actually been tested.
STEP
Confirm It Fires On The Target First
Prove the positive before worrying about the negative
Test against the known-malicious sample or pcap before anything else. A rule that can't catch what it was written for has no business being tuned for false positives yet.
STEP
Run It Against A Clean Baseline
A week of normal traffic tells you what "quiet" looks like
Run the rule against a representative window of normal production traffic or logs before enabling it in blocking mode. Anything it fires on here is the false-positive rate you're about to ship.
STEP
Stage The Rollout
Alert-only first, always
Enable in alert-only mode for a defined window before flipping to enforce or block, and actually review what fired during that window instead of assuming silence means it's ready.
STEP
Get A Second Set Of Eyes
The author's blind spots are invisible to the author
A rule reviewed only by the person who wrote it inherits every assumption that person made without noticing. A second reviewer catches what familiarity hides.
Common Pitfalls
The mistakes that let a rule ship half-finished, and stay that way for years.
PITFALL
Environment-Specific Logic
Works in the lab, does nothing in production
A hardcoded IP, hostname, or file path specific to the test environment doesn't generalize. A rule that only fires under the exact conditions it was written in is not a rule, it's a demo.
PITFALL
No Documented False-Positive Rate
"It works" is not a specification
A rule needs a stated tolerance for how often it's allowed to be wrong. Without one, nobody can decide later whether the rule's actual FP rate is acceptable or a problem.
PITFALL
No Owner Or Review Date
Nobody's job to notice it stopped mattering
A rule with no maintainer and no expiration outlives the threat it was written for. It becomes silent background noise that nobody has the standing to remove.
PITFALL
Confusing Detected With Confirmed
A match is a lead, not a verdict
Publishing a rule as if a match is proof of compromise, rather than the start of an investigation, sets up every downstream analyst to over-trust the alert.
Full Example
A hypothesis, taken through every step above to a rule actually ready to ship.
From Hypothesis To Shipped Rule
Hypothesis An attacker is using certutil to download a second-stage payload Trigger condition certutil.exe with -urlcache or -split flags present in the command line Context / enrichment Exclude known software-deployment accounts that legitimately run certutil for certificate operations ATT&CK mapping T1105 (Ingress Tool Transfer) — a specific, well-known technique, not a broad tactic guess Testing Ran against a clean one-week baseline: two hits, both traced to the certificate management team's own scheduled maintenance script, added to the documented allowlist with the ticket number attached Staged rollout Alert-only for one week, zero unexplained hits, promoted to full alerting with an assigned owner and a 90-day review date // this is the difference between a rule that ships and a rule that just gets written