
Ein Framework und eine Taxonomie zur Identifizierung, Klassifizierung und Begründung von Erkennungslogikfehlern in SIEM-, EDR- und XDR-Regeln, mit konkreten Beispielen und realen Umgehungen.
Sei False Negatives voraus, indem du verstehst, wie Erkennungslogik versagt, bevor Bedrohungsakteure sie missbrauchen.
Besuche die Website: https://adeframework.org/
Adversarial Detection Engineering (ADE) ist die Disziplin des Nachdenkens über False Negatives in Erkennungsregeln. Das ADE Framework bietet eine moderne Open-Source-Formalisierung von Detection Logic Bugs – Diskrepanzen zwischen dem, was eine Erkennungsregel erkennen soll, und dem, was sie tatsächlich erkennt.
Anstatt auf reale False Negatives zu warten, können Detection Engineers proaktiv fragen:
"Welche Variationen würden dazu führen, dass die Erkennungslogik dieser Regel das verpasst, was sie erkennen sollte?"
Diese gegnerische Denkweise spiegelt wider, wie Bedrohungsakteure Schwächen in der Erkennungslogik ausnutzen können.
Der Zweck von ADE ist nicht, Perfektion im Design zu erzwingen, obwohl das ein ideales Ziel ist – sondern Bewusstsein zu schaffen und Einschränkungen zu verfolgen, selbst wenn sie beabsichtigt sind:
Neu bei ADE? Beginne hier:
Bereit für tiefere Einblicke?
Das Framework identifiziert 4 Hauptkategorien und 13 Unterkategorien von 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
🌳 ADE4 – Logic Manipulation
├─ ADE4-01 Gate Inversion
├─ ADE4-02 Conjunction Inversion
└─ ADE4-03 Incorrect Expression
Formale Definitionen und theoretische Grundlage:
Umfassende Klassifikation mit klarer Terminologie:
Konkrete Beispiele aus produktiven Regelsätzen:
Beispielkategorien:
ADE integriert sich in bestehende Detection-Engineering-Praktiken und verbessert sie:
| Framework | Schwerpunkt | ADE-Integration |
|---|---|---|
| MITRE ATT&CK | Angriffstechniken & -taktiken | ADE erklärt, warum die Erkennung für ATT&CK-Techniken fehlschlägt |
| MITRE CAR | Repository für Erkennungsanalysen | ADE bietet eine Fehlertaxonomie für CAR-Analysen |
| Detection Engineering Lifecycle | Phasen des Engineering-Workflows | ADE ist das Reasoning-Framework für die Verbesserungsphase |
| Sigma/YARA/KQL | Regelsyntax & -formatierung | ADE analysiert semantische Logikfehler über alle Abfragesprachen hinweg |
ADE's einzigartiger Wert: Formale Klassifikation auf Logikebene der Ursachen von False Negatives
Wir begrüßen Beiträge! Bereiche der aktiven Entwicklung sind:
Entwicklung statischer Analysewerkzeuge - Tools zur Analyse von Erkennungsregeln auf potenzielle Logikfehler
Erweiterung des Bug-Repositorys - Kuratierte Sammlung identifizierter Fehler
Geplante Entwicklungen:
| Merkmal | Wert |
|---|---|
| Basiert auf | MIT license |
| Verbreitung | Ja |
| Modifikation | Ja |
| Private Nutzung | Ja |
| Kommerzielle Nutzung | Ja |
| Haftung | Nein |
| Garantie | Nein |
| Lizenz- und Urheberrechtshinweis | Ja |
| Autorenangabe | Erforderlich |
⚠️ Wichtig: Dieses Framework ist ausschließlich für defensive Sicherheitsforschung, Detection Engineering und Risikobewertung gedacht. Sein Zweck ist es, Verteidigern zu helfen, Schwächen in der Erkennungslogik und Sicherheitsüberwachungssystemen zu identifizieren, zu analysieren und zu beheben. Die Benutzer sind allein dafür verantwortlich, dass ihre Nutzung allen geltenden Gesetzen, Vorschriften und Autorisierungsanforderungen entspricht. Die Autoren und Mitarbeiter übernehmen keine Haftung für Missbrauch, Schäden oder Beeinträchtigungen, die durch die Nutzung dieses Frameworks entstehen.
Autorisierung erforderlich: Holen Sie stets eine ausdrückliche schriftliche Genehmigung ein, bevor Sie Erkennungen, Systeme oder Kontrollen außerhalb von Umgebungen testen, die Sie besitzen oder betreiben.
Verantwortungsvolle Offenlegung: Beispiele werden unter Berücksichtigung der verantwortungsvollen Offenlegung bereitgestellt. Erkennungsregeln und Überwachungsinhalte fallen in der Regel nicht in den Rahmen von Schwachstellenoffenlegungen und Bug-Bounty-Programmen von Anbietern.
Keine Gewährleistung: Dieses Framework wird "wie besehen" ohne jegliche ausdrückliche oder stillschweigende Gewährleistung bereitgestellt.