Rule development can be hotly debated and there are many ideas for what makes a detection rule good. We hear about arguments between Indicators of Compromise vs. Indicators of Attack and signatures vs. rules. Instead of rehashing those discussions, we want to share our approach and what we've learned: detection engineering is about understanding adversary behavior, available telemetry, and building detections that hold up over time. This document captures the principles that guide our work and our expectations of this repository.
Threats change, data sources evolve, and attackers adapt. Every detection in this repository needs continuous tuning, measurement, and improvement. Shipping a rule is the start of its lifecycle, not the end.
A detection is more than a query that fires. Quality encompasses purposeful rule context and intentional behavior detection: confirmed behavior matching, severity and risk scoring, ATT&CK mapping, investigation guidance, highlighted fields, enrichment fields, and documentation of what the rule detects, what it misses, and its known limitations. This enables a full analyst experience. A smaller set of well-documented rules is worth more than a large set of noisy, brittle ones.
A single rule mapped to a technique does not mean that technique is "covered." True coverage means understanding the technique's variants, the telemetry required to observe them, surrounding security controls and infrastructure, the evasion paths available to attackers, and the gaps that remain.
A detection that does not function correctly is a liability. Every rule should be accompanied by evidence that it fires correctly and models scoped threat behavior, whether through emulation, simulation, or representative log samples.
No detection is perfect. Rules should document their known limitations and accepted blind spots, whether in the description, false positive notes, investigation guide, or inline query comments. A rule with clearly stated constraints is more trustworthy and maintainable than one with undiscovered weaknesses.
Detection rules are software that run in production. They must be performant, maintainable, and effective, not just technically correct. That means lean queries with acceptable execution time, clear logic, documented assumptions, adequate lookback windows and schedules, and active maintenance as schemas and data sources evolve.
What we build and in what order should be driven by real-world threat intelligence: customer incidents, adversary emulation, emerging campaigns, and telemetry gap analysis. Not by abstract completeness goals.
For endpoint protections, the goal is not only to detect a threat but to block it. When possible, the workflow should include verification that an attack is actually prevented once a production rule is merged, not just that the logic triggers an alert.
Elastic Security supports multiple query languages and detection mechanisms, each capable of expressing different analytical patterns. Some detections identify rare or novel behavior, others focus on frequency and threshold-based anomalies, while others rely on event sequencing, correlation, or broad field matching. Advanced analytics enable aggregation, enrichment, and cross-domain reasoning. Choosing the right language for each threat is key.
Our goal is to improve detection within Elastic Security while combating alert fatigue. When developing or reviewing a rule, consider these questions:
- What behavior am I detecting?
- What data proves that behavior?
- What assumptions am I making?
- How does an attacker break those assumptions?
- What happens when this fires?
We tend to prefer rules that are more behavioral in nature. Behavioral rules focus on the attacker technique, and less on a specific tool or indicator. This may require more research to understand how a technique works, but it does a better job detecting the attacks of today and tomorrow, not just the attacks of yesterday.
Even though we gravitate towards behavioral or technique-based rules, we don't automatically disqualify a rule because it uses indicators of a specific actor or tool. Though indicator-based detections are typically more brittle, they tend to have less noise and are specifically written to detect exactly one thing. When a tool is used across multiple actors or red teams, a well-scoped signature can go a long way.
When writing or reviewing a rule, think like an adversary: How could I perform this action while going undetected by this rule? Prefer structured fields like parsed arguments over raw command lines, and avoid pattern matching that is trivially bypassed by whitespace, quoting, or encoding changes. When evasions are accepted trade-offs, document them.