A framework and taxonomy for identifying, classifying, and reasoning about detection logic bugs in SIEM, EDR, and XDR rules, with concrete examples and real-world bypasses.
Get ahead of False Negatives by understanding how detection logic fails before threat actors abuse it.
Check out the website: https://adeframework.org/
Adversarial Detection Engineering (ADE) is the discipline of reasoning about False Negatives in detection rules. The ADE Framework provides a modern open-source formalization of Detection Logic Bugs - mismatches between what a detection rule intends to detect and what it actually detects.
Instead of waiting for real-world False Negatives, detection engineers can proactively ask:
"What variations would cause this rule's detection logic to miss what it was intended to catch?"
This adversarial line of reasoning mirrors how threat actors can abuse weaknesses in detection logic.
The purpose of ADE is not to force perfection in design, although that is an ideal goal - but to raise awareness and track limitations, even if intentional:
New to ADE? Start here:
Ready to dive deep?
The framework identifies 4 major categories and 16 subcategories of detection logic bugs:
🌳 ADE1 – Reformatting in Actions
├─ ADE1-01 Substring Manipulation
└─ ADE1-02 Normalization Asymmetry
🌳 ADE2 – Omit Alternatives
├─ ADE2-01 Method/Binary
├─ ADE2-02 Versioning
├─ ADE2-03 Locations
└─ ADE2-04 File Types
🌳 ADE3 – Context Development
├─ ADE3-01 Process Cloning
├─ ADE3-02 Aggregation Hijacking
├─ ADE3-03 Timing and Scheduling
├─ ADE3-04 Event Fragmentation
├─ ADE3-05 Lineage Spoofing
└─ ADE3-06 Limit Saturation
🌳 ADE4 – Logic Manipulation
├─ ADE4-01 Gate Inversion
├─ ADE4-02 Conjunction Inversion
├─ ADE4-03 Incorrect Expression
└─ ADE4-04 Field Mismapping & Semantics
Formal definitions and theoretical foundation:
Comprehensive classification with clear terminology:
Concrete examples from production rulesets:
Example Categories:
ADE integrates with and enhances existing detection engineering practices: