Eine KQL-Detection ist nicht fertig, bevor sie auf ATT&CK mappt

Eine KQL-Query, die anomales Verhalten findet, fühlt sich fertig an, sobald sie feuert. Sie ist es nicht. Solange nicht klar ist, welche Technik sie abdeckt, weiß niemand — der Autor eingeschlossen — was sie eigentlich detektiert. Sie ist eine Log-Zeile mit Ambitionen.

MITRE ATT&CK ist dabei kein Compliance-Anhang, den man nachträglich anklebt. Das Mapping ist der Test, der beantwortet, ob die Detection überhaupt fertig ist: Welche Technik, welche Sub-Technik, und deckt die Query die Technik ab — oder nur eine bequeme Instanz davon.

Das Mapping deckt die Lücken auf

Der Wert entsteht im Moment, in dem man die Technik hinschreiben muss. Eine Query, die T1059.001 — PowerShell — behauptet, aber nur auf encodedCommand triggert, mappt nicht sauber auf die Technik. Sie mappt auf ein Artefakt. Das Mapping zwingt die Frage: Was von T1059.001 fange ich nicht.

Genau diese Lücke ist die eigentliche Ausbeute. Ohne Mapping bleibt sie unsichtbar, weil eine feuernde Query wie Coverage aussieht. Mit Mapping wird aus “ich habe eine Detection” ein ehrliches “ich decke diesen Teil dieser Technik ab, den Rest nicht”.

Coverage wird erst durch Mapping messbar

Über eine Rule-Library hinweg ist das Mapping das, was aus einzelnen Queries eine Coverage-Aussage macht. Erst wenn jede Detection auf Technik-Ebene verankert ist, lässt sich sagen, welche Taktiken dünn besetzt sind und wo drei Regeln dieselbe Sub-Technik dreifach abdecken.

Deshalb gehört das Mapping nicht ans Ende als Dokumentation, sondern in die Definition of Done. Eine Detection ist fertig, wenn sie feuert, wenn sie getunt ist — und wenn sie auf ATT&CK mappt. Vorher ist sie ein Kandidat.