The Zen of Security Rules
- almost all points from The Zen of Python are applicable to security rules — start there
- favour inclusion-by-exception over exclusion-by-exception, or else endure perpetual whack-a-mole
- have a propensity towards performance; expensive rules must justify the cost
- resist temptation to over or under-scoping; balance is key
- generic patterns can minimize brittleness, but at the cost of performance
- correlation is powerful, but overly comprehensive rules can lead to brittleness and trivial bypasses
- detect behaviours over IOCs, except when necessary
- if a rule is too complex to understand, the alert is even worse
- just like code, readability is important for avoiding errors
- detection logic formatting should emphasize logical precedence and grouping
- detection logic should be resilient, but when it can’t, use multiple rules
- consistency in rule structure leads to predictability and fewer errors
- if you can detect it, you can test it
- always version your rules
- maintenance cost of a rule should not outweigh the value of the rule
- there will ALWAYS be surprises from FPs and FNs
- minimizing FPs sometimes outweighs eliminating FNs, due the costs of Alert Fatigue
- less is more; don’t write rules for the sake of writing rules
- there is no “correct” quantity of total rules, but there can be too many and too few
- when necessary, break the rules, so you don’t break the rules
- production environments vary wildly, so minimize assumptions
- adopt a detections-as-code or similar software-driven process for managing rules early
Relevant Note(s):