*Published: 4/20/2026* ## Axioms - Security efficacy has diminishing value, at some point, as rule quantity grows - Rule count is not an absolute measure of successful coverage - Coverage is not an absolute measure of security - Alert count has an inverse relationship with their manageability - Threats are not static - Security posture is a snapshot, thus only instantaneously represented --- ## The zen approach to detection - Detect behaviors over IOCs, except when necessary - Resist temptation to over or under-scope; balance between precise and broad - Rule upkeep should not outweigh the value of its protection - Correlation has power, but it can be overdone, leading to trivial bypasses - Generic patterns can minimize brittleness, but at the cost of performance - Have an inclination towards performance; expensive rules must justify the cost - Large environments are unpredictable; there will always be surprises from false positives and negatives - Clear beats vague, simple tops complex, readable rules win - Just like code, readability is important for avoiding errors - In the face of ambiguity, refuse the temptation to guess - If you can detect it, you can test it - If the implementation is hard to explain, it's a bad idea - If the implementation is easy to explain, it may be a good idea - If a rule is too complex to understand, the alert is even worse - Consistent rule formats create predictability and fewer mistakes - Detection logic formatting should emphasize logical precedence and grouping - Detection logic should be resilient, but when it can’t, use multiple rules - Cut false positives to fight alert fatigue, even if it has missed behavior; there will be another angle - 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 - Production environments vary wildly, so minimize assumptions - Adopt a detections-as-code or similar software-driven process for managing rules early - Always version your rules --- ## Evaluation questions for detection opportunities - Is the detection **brittle**? - Does it have **narrow coverage**? - Is it focused on **elements lower on the Pyramid of Pain**? - Is it **resilient over time** and **resistant to changes in attack behavior**? - Do we have reliable **visibility** into the required log source? - Does it result in **too much noise** in my environment? - Does it **incur excessive labor cost**? - Is it **threat-oriented**? - Does it come from a **threat model** or **threat intelligence**? - What is the **prevalence or chokepoint** of the threat? - Is it **actionable**? - Does it **reflect insightful risk and impact** for my organization? - Is it tailored to my **unique environment** and **crown jewels**? --- ## End goal Confidently answer "yes" to every one of these. - Can you name the assets you are defending? - Do you have visibility across your assets? - Can you detect unauthorized activity? - Can you accurately classify detection results? - Who are your adversaries? What are their capabilities? - Can you detect adversary activity within your environment? - Can you detect an adversary that is already embedded? - During an intrusion, can you observe adversary activity in real time? - Can you deploy proven countermeasures to evict and recover? - Can you collaborate with trusted partners to disrupt adversary campaigns? - And ultimately, can you operate at the tempo of the adversary? ## References and inspiration - [The Zen of Python](https://peps.python.org/pep-0020/) - [The Zen of Security Rules](https://br0k3nlab.com/resources/zen-of-security-rules/) - [Elastic Security's Philosophy](https://github.com/elastic/detection-rules/blob/main/PHILOSOPHY.md) - [DFIR Hierarchy of Needs](https://holisticinfosec.blogspot.com/2016/12/the-dfir-hierarchy-of-needs-critical.html)