Adversarial Detection Engineering (ADE) Framework

Seien Sie False Negatives voraus – indem Sie verstehen, wie Erkennungslogik versagt, bevor Threat Actors sie ausnutzen.

Besuchen Sie die Website: https://adeframework.org/

Was ist ADE?

Adversarial Detection Engineering (ADE) ist die Disziplin, über False Negatives in Erkennungsregeln zu reflektieren. 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.

Der ADE-Vorteil

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 verfehlt, was sie eigentlich erfassen sollte?"

Diese adversariale Denkweise spiegelt wider, wie Threat Actors Schwächen in der Erkennungslogik ausnutzen können.

Hauptmerkmale

• ✅ Reproduzierbare Detection Logic Bugs identifizieren und sie formalen ADE-Kategorien zuordnen
• ✅ Das mentale Modell eines Angreifers einbetten in die Art und Weise, wie Erkennungslogik entworfen und überprüft wird
• ✅ Strukturelle Schwächen aufdecken in Regeln, die für Hunts oder Produktions-MDR-Tooling (SIEM, XDR, EDR) verwendet werden
• ✅ Sicherheitsteams ausstatten mit umsetzbaren Erkenntnissen zu Detection Logic Bugs
• ✅ False Negatives voraus sein, bevor Threat Actors sie entdecken und ausnutzen

ADE-Zweck

Der Zweck von ADE ist nicht, Perfektion im Design zu erzwingen, obwohl das ein ideales Ziel ist – sondern das Bewusstsein zu schärfen und Einschränkungen nachzuverfolgen, selbst wenn sie beabsichtigt sind:

• Bei ADE geht es nicht darum, perfekte Erkennungsregeln zu verlangen; es geht darum, das Risiko von False Negatives sichtbar zu machen.
• Viele Regeln enthalten absichtlich Einschränkungen aufgrund von Scope, Signalqualität oder operativen Rahmenbedingungen, und diese können dennoch ADE-Bug-Typen zugeordnet werden, ohne „falsch" zu sein.
• ADE bietet eine gemeinsame Möglichkeit, diese Risiken über ein Regelwerk hinweg zu dokumentieren, zu akzeptieren, zu mindern oder zu kompensieren, anstatt einzelne Regeln isoliert zu beurteilen.

ADE-Verbindung zu Detection Logic Exposures (DLE)

• ADE liefert eine kanonische Taxonomie und Bug-Klassen für Detection Logic Bugs.
• DLE bietet eine anerkannte Liste öffentlich offengelegter Bypässe mit ADE-Zuordnungen.

Schnellstart

Neu bei ADE? Beginnen Sie hier:

1. Einführung – Verstehen Sie, was ADE ist und warum es wichtig ist
2. Kernkonzepte – Lernen Sie die grundlegende Terminologie
3. Schnellstartanleitung – Wenden Sie ADE auf Ihre erste Erkennungsregel an
4. Bug Likelihood Test – Schnelle Checkliste zur Bewertung von Regeln auf Bugs

Bereit für einen Deep Dive?

• Detection Logic Bug Theory – Formale Grundlagen
• Taxonomie-Übersicht – Alle Bug-Kategorien
• Beispiele – Praxisnahe Beispiele

ADE Detection Logic Bug Taxonomie

Das Framework identifiziert 4 Hauptkategorien und 16 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
    ├─ 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

→ Die vollständige Taxonomie erkunden

Was das Framework bietet

1. Theorie der Detection Logic Bugs

Formale Definitionen und theoretische Grundlage:

• Was einen Detection Logic Bug ausmacht
• Wie Bugs False Negatives erzeugen
• Beziehung zwischen Scope und Erkennungslogik
• Konzept der Rule Bypasses

2. Formale Bug-Taxonomie

Umfassende Klassifizierung mit klarer Terminologie:

• 4 Hauptkategorien
• 16 detaillierte Unterkategorien
• Konsistentes Bezeichnungssystem (ADE1-01, ADE2-01 usw.)
• Zuordnung zu realen Erkennungsregeln

3. Praxisnahe Beispiele

Konkrete Beispiele aus Produktions-Regelwerken:

• Sigma-Erkennungsregeln
• Microsoft Sentinel-Analysen
• Elastic Security SIEM- & EDR-Regeln

Beispielkategorien:

• ADE1-Beispiele – String-Manipulation-Bypässe
• ADE2-Beispiele – Ausgelassene Alternativen
• ADE3-Beispiele – Kontextentwicklung
• ADE4-Beispiele – Logikmanipulation

4. Praktische Werkzeuge

• Bug Likelihood Test – Schnelle Checkliste zur Voranalyse
• Schnellstartanleitung – Schritt-für-Schritt-Anwendungsprozess

Wie ADE bestehende Frameworks ergänzt

ADE integriert sich in bestehende Detection-Engineering-Praktiken und erweitert sie: