13 % Ihrer Detektionsregeln feuern nie
Die Zahl stammt aus dem 5. jährlichen State of SIEM Detection Risk-Report von CardinalOps, der mehr als 13.000 echte Detektionsregeln aus hunderten produktiver SIEM-Umgebungen ausgewertet hat — Microsoft Sentinel eingeschlossen, neben Splunk, QRadar und anderen. Das Ergebnis: rund 13 % dieser Regeln sind nicht funktionsfähig und werden nie auslösen. Nicht, weil jemand die Query kaputt geschrieben hätte, sondern weil die Datenquelle fehlkonfiguriert ist oder das Log-Feld, auf das die Regel zeigt, in dieser Umgebung nie befüllt wird. Derselbe Report beziffert die Abdeckung der MITRE-ATT&CK-Techniken auf nur etwa 21 % — die meisten Angriffstechniken sind schlicht nicht abgedeckt.
Das ist die Art Zahl, die man leicht wegnickt, bis man sie umdreht: Jede achte Regel in Ihrem Sentinel-Workspace ist womöglich ein Platzhalter, der aussieht wie Schutz. Auf dem Dashboard steht, dass eine Detektion für diese Technik existiert. Der Auditbericht hakt sie ab. Der Angreifer läuft trotzdem hindurch, weil die Regel nie feuert. Und der entscheidende Punkt am CardinalOps-Befund ist die Ursache: fehlende Datenquellen und fehlende Felder. Das ist ein Daten- und Prüfproblem — keines, das sich lösen lässt, indem man noch mehr Regeln generiert.
Eine Regel, die sauber parst, kann trotzdem tot sein
Der gefährliche Teil ist, dass eine tote Regel sich in nichts von einer gesunden unterscheidet, solange Sie nur ihren Text lesen. Sie ist gültiges KQL. Sie speichert ohne Fehlermeldung. Sie wird planmäßig ausgeführt, terminiert sauber, produziert null Ergebnisse — und null Ergebnisse liest sich als „keine verdächtige Aktivität“, also genau wie eine funktionierende Detektion an einem ruhigen Tag. Es gibt keinen roten Balken, keine Ausnahme, kein Signal, dass etwas kaputt ist. Genau das macht diese Fehlerklasse so tückisch: Sie versagt still und in exakt der Richtung, die niemandem auffällt, bis der Vorfall da ist.
Eine Regel wird auf diese Weise tot, wenn sie auf eine Tabelle oder ein Feld filtert, das dieser Workspace nie befüllt, oder wenn sie einen Vergleich benutzt, der die Form der Daten nie treffen kann — eine Bedingung, die immer zu falsch auswertet. Beides sieht im Query-Text vollkommen plausibel aus. Beides überlebt ein Review, bei dem jemand die Regel durchliest und nickt. Der einzige Ort, an dem der Unterschied sichtbar wird, ist das tatsächliche Schema Ihres Workspace — und das liest niemand im Kopf mit.
Zwei Regeln, eine ist still tot
Ein konkretes Beispiel. Beide folgenden Fragmente sollen dieselbe Sache erkennen: eine PowerShell, die eine base64-kodierte Nutzlast lädt. Beide sind gültiges KQL. Beide würde ein Analyst — oder ein LLM, das man um ein Review bittet — für vernünftig halten.
// Sieht korrekt aus. Parst sauber. In diesem Workspace still tot: DeviceProcessEvents // Tabelle hier nie onboarded → immer leer | where FileName =~ "powershell.exe" | where ProcessCommandLine has "FromBase64String" // Gleiche Absicht, gegen die Tabelle, die dieser Workspace wirklich befüllt: SecurityEvent | where EventID == 4688 // klassisches Prozess-Log, onboarded | where NewProcessName endswith "powershell.exe" | where CommandLine has "FromBase64String"
Die erste Regel referenziert DeviceProcessEvents — eine Tabelle aus Microsoft Defender for Endpoint. In einem Workspace, der nur die klassischen Windows-Sicherheitsereignisse ins SecurityEvent onboarded und Defender for Endpoint nie angebunden hat, existiert diese Tabelle nicht. Die Regel bindet gegen nichts, liefert nie eine Zeile und feuert nie — dauerhaft, geräuschlos, mit grünem Status. Die zweite Regel zielt auf SecurityEvent, das dieser Workspace tatsächlich befüllt; ihre Referenzen lösen auf, also kann sie überhaupt feuern. Der Unterschied zwischen einer toten und einer lebenden Regel steht nicht im Text. Er steht nur im echten Schema — und die einzige Frage, die zählt, lautet: Wie prüft man das über Tausende von Regeln, ohne jede einzeln zu öffnen?
Wie prüft man Tausende Regeln — ohne ein Sprachmodell zu fragen?
Ein großer Bestand lässt sich nicht mit dem Auge prüfen, und noch einmal drüberlesen ist exakt der Vorgang, der stille Regeln übersieht. Die naheliegende moderne Antwort lautet: ein LLM jede Regel bewerten lassen. Genau daran scheitert der Ansatz im Kern. Ein Sprachmodell ist nicht vertrauenswürdig darin, die Ausgabe eines anderen Sprachmodells — oder eines Menschen — als korrekt zu zertifizieren, weil „sieht korrekt aus“ der Fehlermodus selbst ist. Das Modell wird die tote Regel aus demselben Grund selbstbewusst durchwinken, aus dem ein Mensch es tut: Sie liest sich plausibel.
Ein plausibel aussehendes Artefakt mit einem System zu prüfen, dessen native Ausgabe ebenfalls „plausibel, vielleicht falsch“ ist, fügt keine Grundwahrheit hinzu — es fügt eine weitere Schicht Plausibilität hinzu. Dazu kommt: Ein LLM, das Regeln prüft, ist selbst wieder eine LLM-Anwendung mit sicherheitsrelevanter Eingabe und erbt alle bekannten Schwächen jedes LLM-Systems mit nicht vertrauenswürdigem Input. Was Sie brauchen, ist eine Prüfung, die sich nicht in eine falsche Antwort reden lässt. (Wie man Regeln baut, statt sie zu auditieren, ist eine verwandte, aber andere Frage — dazu die generieren-prüfen-verfeinern-Schleife in Detection Engineering mit LLMs.)
Deterministische Validierung gegen Microsofts eigenen KQL-Parser
Die belastbare Antwort ist unspektakulär: Microsoft liefert die KQL-Engine als Bibliothek aus. Kusto.Language ist derselbe Parser und semantische Analysator, den Azure Data Explorer und Sentinel selbst verwenden — quelloffen und öffentlich. Man kann damit jede Regel parsen; nicht mit einer Nachbildung der Grammatik, sondern mit Microsofts eigenem Werkzeug. Und dann kommt der Schritt, der die eigentliche Arbeit leistet: die semantische Analyse gegen einen Zustand laufen lassen, der das tatsächliche Tabellen- und Spaltenschema Ihres Workspace enthält. Jede Tabellenreferenz, jede Spalte, jede Funktion löst gegen das echte Schema auf — oder eben nicht.
Eine Referenz, die nicht auflöst, ist kein „vielleicht“. Sie ist ein Beweis, dass die Regel die Zeilen, die sie zu liefern behauptet, nicht liefern kann. Das ist die Bedeutung von deterministisch: dieselbe Regel plus dasselbe Schema ergibt jedes Mal dasselbe Urteil, ohne Modell in der Schleife, ohne etwas, das halluzinieren könnte. Sie tauschen eine Meinung gegen einen Beweis.
Parsen, binden, das Unbeweisbare markieren
Konkret arbeitet die Prüfung in drei Stufen. Parsen mit Kusto.Language fängt Regeln ab, die schon syntaktisch nicht halten. Binden gegen das Workspace-Schema fängt genau die Fälle, die CardinalOps benennt: Referenzen auf Tabellen, die nie onboarded wurden, und auf Felder, die eine reduzierte Connector-Konfiguration nie liefert — die „fehlende Datenquelle“ und das „fehlende Log-Feld“. Typprüfen fängt den Vergleich gegen eine Spalte des falschen Typs, der immer zu falsch auswertet — als Diagnose des Analysators, nicht als Feinheit, die ein Prüfer erspähen muss.
Das Ergebnis ist keine Ampel, die „wahrscheinlich in Ordnung“ sagt. Es ist eine Liste von Regeln, die als geschrieben beweisbar nicht feuern können, jeweils mit der genauen Referenz, die nicht auflöst. Diese Prüfung skaliert, weil sie mechanisch ist: über Tausende Regeln in einem Durchlauf, ohne dass ein Mensch — oder ein Modell — jede einzeln beurteilen müsste. Für ein MSSP, das Regeln über viele Mandanten pflegt, läuft dieselbe Prüfung pro Mandant, gegen dessen jeweiliges Schema.
Was diese Prüfung nicht kann
Ehrlichkeit gehört dazu, sonst tauscht man nur ein falsches Sicherheitsgefühl gegen ein anderes. Deterministische Validierung beweist strukturelle und schemabezogene Totheit: dass eine Regel keine Zeile zurückgeben kann oder etwas referenziert, das nicht existiert. Sie beweist nicht das Gegenteil. Eine Regel, die sauber bindet, jede Tabelle und Spalte auflöst und brav Zeilen liefert, kann trotzdem die falsche Sache erkennen, die eigentliche Technik verfehlen oder auf harmlosem Verkehr feuern. Ob die Detektionslogik zum realen Angreifer passt, ist eine Frage des Bedrohungsmodells — und die braucht weiterhin einen Menschen, der weiß, was diese Organisation Stehlenswertes hat und wer wahrscheinlich danach greift.
Auch Fehler auf Wert-Ebene liegen außerhalb der reinen Schemabindung — ein Filter auf "user", während die Daten "User" schreiben, ist ein Casing-Problem, das erst der Lauf gegen repräsentative Daten aufdeckt, nicht der Parser. Deterministische Validierung nimmt eine ganze Klasse stiller Ausfälle günstig und beweisbar vom Tisch; sie ersetzt das Bedrohungsmodell nicht. Für Betreiber unter NIS2 ist gerade dieser beweisbare, dokumentierbare Nachweis, dass die eigenen Detektionen leben, aber genau die Art Beleg, die im Ernstfall zählt — mehr dazu in NIS2-Meldepflichten in der Praxis.
Wo Tippel ins Spiel kommt
Genau diese Prüfschicht baut Tippel für Microsoft Sentinel. Kein KQL-Generator — das Erzeugen von Queries hat Microsofts Security Copilot zur Massenware gemacht. Der verteidigbare Teil ist die Validierung: jede Regel in Ihrem Workspace mit Microsofts eigener KQL-Engine parsen, jede Referenz gegen Ihr Live-Schema auflösen und Ihnen die Liste der Regeln zurückgeben, die beweisbar nicht feuern können — die 13 %, von denen Sie nicht wussten, dass Sie sie haben. Für MSSPs läuft das pro Mandant; für ein internes SOC über den eigenen Bestand. Es ist eine messbare, unglamouröse Disziplin: Validierung, nicht noch mehr Generierung. Wie das als Engineering-Arbeit aussieht, beginnt bewusst eng — ein Workspace, das echte Schema, ein Durchlauf — und wird erst danach skaliert.
Wenn das ein Problem trifft, das Sie tatsächlich haben, ist der KI-Readiness-Check der günstigste Weg, es an Ihrem eigenen Bestand zu belegen, mit einem ehrlichen Go/No-Go am Ende. Und weil das Thema besser in einen Raum voller Detection Engineers gehört als in ein Verkaufsgespräch: Ich halte dazu gerne einen Vortrag bei Ihrem SOC-Team, Ihrem MSSP-Partnertag oder auf einer Security-Konferenz — die 13 %, wie man sie deterministisch findet, und wo die Methode ehrlich an ihre Grenze kommt. Schreiben Sie mich an, dann finden wir das passende Format.