Detection Engineering mit LLMs

Die Query zu erzeugen sind die leichten 20 %

Detection Engineering mit LLMs funktioniert — aber nicht dort, wo die Demos den Akzent setzen. Natürlichsprachliche Absicht in eine KQL-Query zu übersetzen, also den Teil, der sich im Meeting gut vorführen lässt, sind die leichten 20 %. Ein fähiges Modell kennt die Kusto-Grammatik und liefert für die meisten Detection-Ideen mit wenig Prompting eine syntaktisch saubere Query. Die harten 80 % sind Vertrauen: die Gewissheit, dass die Query auf Ihren Logs das tut, was der Satz gesagt hat, bevor sie scharf geschaltet wird. Eine Detection ist kein Absatz, den man liest und abnickt. Sie ist eine Behauptung über Ihre Daten, die entweder wahr oder falsch ist — und die Kosten einer falschen sind asymmetrisch und zeitverzögert.

Eine plausible falsche Regel ist schlimmer als keine

Eine Detection, die subtil falsch ist, ist gefährlicher als gar keine — weil sie in beide Richtungen leise versagt. Ist sie zu eng, verpasst sie den Angriff: ein übersehener Treffer, der keinen Fehler, keinen Alarm, kein Zeichen produziert, dass etwas kaputt ist. Sie entdecken die Lücke im Incident-Review, falls überhaupt. Ist sie zu breit, feuert sie auf harmlosem Verkehr: ein Fehlalarm, der sehr wohl ein Signal produziert, hunderte davon, bis der Analyst, der sie triagieren muss, die Alarme dieser Regel reflexartig wegklickt. Eine laute Regel verschwendet nicht nur Zeit; sie trainiert ein SOC darauf, eine ganze Alarmkategorie zu ignorieren — und genau so rutscht ein echter Alarm durch.

So oder so hat die plausible Query Sie unsicherer gemacht, während sie aussah, als hätte sie Sie sicherer gemacht. Das ist die konkrete Falle: LLMs sind extrem gut darin, Ausgaben zu erzeugen, die korrekt aussehen, und Detection ist eine Domäne, in der „sieht korrekt aus“ und „ist korrekt“ monatelang auseinanderlaufen können, ohne dass es jemand merkt. Der Generator ist selbst eine LLM-Anwendung, die sicherheitsrelevante Absicht verarbeitet, und erbt damit die üblichen Härtungsfragen jedes LLM-Systems mit nicht vertrauenswürdiger Eingabe. Das tiefere Problem ist aber nicht die Prompt-Oberfläche. Es ist, dass selbstbewusst-flüssige Fehlerhaftigkeit der Standard-Fehlermodus eines Sprachmodells ist — und eine Detection ist genau das Artefakt, bei dem Sie sich das nicht leisten können.

Wo LLM-geschriebene Detections scheitern

Die Fehler sind nicht zufällig. Sie ballen sich an ein paar vorhersagbaren Stellen — und eine Prüfschleife ist genau um dieses Wissen herum gebaut.

Halluzinierte Tabellen und Felder

Das Modell referenziert eine Spalte, die es nicht gibt — SourceIP, während Ihre Tabelle sie IPAddress nennt, oder ein EventID-Feld auf einer Tabelle, die nie eines trug. Scheitert die Erfindung an der Kompilierung, haben Sie Glück: Der Fehler ist laut und leicht zu fangen. Die gefährliche Variante ist eine Spalte, die es gibt, die in Ihrer Umgebung aber fast immer leer ist, oder eine Tabelle, die ein subtil anderes Ereignis enthält als vom Modell angenommen. Die Query kompiliert, läuft, liefert nichts zurück und liest sich als „keine passende Aktivität“ — ununterscheidbar von einer gesunden Detection an einem ruhigen Tag. Die Lösung ist kein cleverer Prompt. Sie besteht darin, die Generierung im echten Workspace-Schema zu verankern und danach zu bestätigen, dass jede Tabelle und jedes Feld dagegen auflösbar ist.

Zeitfenster, die um eins danebenliegen

Detection ist zeitlich: „N Ereignisse innerhalb von M Minuten“, „zum ersten Mal in den letzten 24 Stunden gesehen“, „ein Ausschlag gegenüber dem Ist-Wert der Vorwoche“. Genau hier geht die plausible Schätzung schief. Ein Rückblick, der nicht zur Ausführungsfrequenz der Regel passt, lässt Lücken zwischen den Läufen, durch die ein Ausbruch schlüpft. Eine Fenstergrenze, die mitten im Angriff zurücksetzt, zählt fünf fehlgeschlagene Anmeldungen als drei-dann-zwei und reißt die Schwelle nie. Ein ago() vom falschen Anker aus verschiebt das ganze Fenster. Nichts davon sieht im Query-Text falsch aus. Es zeigt sich erst, wenn Sie die Regel gegen einen bekannten Angriff laufen lassen, der eine Grenze überspannt, und zusehen, wie sie stumm bleibt.

Zu breite Treffer

Der häufigste Weg, auf dem eine erzeugte Regel unbrauchbar wird, ist der Zuschnitt. Ein contains, wo Sie einen exakten Vergleich brauchten; ein Treffer auf einen Prozessnamen, den auch legitime Admin-Werkzeuge nutzen; ein EventID ohne Filter auf die Konten oder Hosts, die es überhaupt aussagekräftig machen. Sie feuert pausenlos, die Queue läuft über, die Regel wird stummgeschaltet — dasselbe Ergebnis, als hätte man sie nie geschrieben, nur teurer erreicht. Zu breite Regeln sind schlimmer, als sie aussehen, denn ihr Schaden trifft die Aufmerksamkeit, die knappste Ressource eines SOC.

Generieren, prüfen, verfeinern

Deshalb ist die Architektur, auf die es ankommt, nicht „Prompt → Query“. Es ist eine Schleife mit unabhängigen Prüfungen — und das ist die Form des Multi-Agenten-KQL-Generators, den wir für Bluerope Consult GmbH gebaut haben, ein System, das natürlichsprachliche Absicht in validierte Sentinel-Detections übersetzt und die Query-Entwicklung von Tagen auf Minuten bringt. Das Tempo ist die Schlagzeile. Die Schleife ist der Grund, warum das Tempo sicher statt fahrlässig ist.

Ein Agent generiert: Er entwirft KQL aus der Absicht, aber verankert im echten Workspace-Schema statt in der Erinnerung des Modells daran, wie Sentinel-Tabellen üblicherweise aussehen — was die meisten Halluzinationsfehler bei Feldern verhindert, bevor sie entstehen können. Ein zweiter Agent prüft: Er parst die Query, löst jede Tabelle und Spalte gegen das tatsächliche Schema auf und — der Teil, der die eigentliche Arbeit leistet — führt sie gegen repräsentative Beispieldaten aus, samt Ereignissen, die bekannt bösartig, und solchen, die bekannt gutartig sind. Eine Regel, die beim Bekannt-Bösartigen stumm bleibt oder beim Bekannt-Gutartigen feuert, ist gerade durch einen Test gefallen, den das Lesen der Query nie leisten könnte. Ein dritter Agent ist adversarial: Er stellt die Frage, die ein guter Detection Engineer stellt — „Wie würde ein Angreifer das umgehen, und welche harmlose Aktivität würde es auslösen?“ — und übersetzt die Antworten in konkrete Verfeinerungsanweisungen. Der Entwurf dreht so lange in der Schleife, bis er alle drei übersteht, oder bis er es nicht kann — dann eskaliert er an einen Menschen, statt still etwas Kaputtes auszuliefern.

Der Sinn mehrerer Agenten ist nicht Neuartigkeit, sondern Unabhängigkeit. Der Wert entsteht dadurch, die Generierung gegen etwas zu prüfen, mit dem der Generator nicht diskutieren kann — eine Grammatik, ein Schema und vor allem ein Grundwahrheits-Orakel in den Daten. Das ist derselbe Grund, aus dem Sie, in anderem Kontext, ein Modell nicht zum alleinigen Richter über seine eigene Arbeit machen; es ist die zentrale Warnung beim ehrlichen Evaluieren von LLM-Systemen. Detection Engineering passt zufällig ungewöhnlich gut zu diesem Muster, weil alle drei Prüfungen wirklich existieren: Das Ziel ist eine strukturierte Sprache mit Grammatik, die Ausgabe ist ausführbar, und Sie haben gelabelte Daten, gegen die Sie sie laufen lassen können. Lassen Sie die Schleife weg, bleibt das Gegenteil — ein schneller Weg, selbstbewusste, unprüfbare Vermutungen über Ihre Sicherheitslage zu erzeugen.

Wo der Detection Engineer in der Schleife bleibt

All das ersetzt keinen Detection Engineer; es verändert, womit er den Tag verbringt. Die Schleife nimmt den Boilerplate ab — die KQL-Syntax, die Schema-Nachschläge, die ersten drei kaputten Entwürfe —, sodass die Zeit des Engineers zu den Teilen wandert, die ein Modell wirklich nicht kann. Das Bedrohungsmodell ist der erste: zu entscheiden, was sich zu erkennen lohnt, gegen welchen Angreifer, gemessen an dem, was diese konkrete Organisation tatsächlich Stehlenswertes hat. Ein Modell kennt weder Ihre Kronjuwelen noch, wer wahrscheinlich danach greift. Das Tuning ist der zweite: Was als normales Rauschen zählt, ist lokales Wissen, und eine Regel, die für ein Unternehmen gut kalibriert ist, überflutet ein anderes. Sie verfällt auch — eine vor sechs Monaten getunte Detection wirft nach einer Infrastrukturänderung Fehlalarme, was ein Monitoring-Problem ist, kein Generierungsproblem. Und die Freigabe ist der dritte: Jemand mit Verantwortung muss entscheiden, dass die Regel gut genug ist, um die Produktion zu bewachen — denn „die Agenten haben zugestimmt“ ist kein Satz, den Sie nach einem Vorfall sagen möchten.

Wo Tippel ins Spiel kommt

Wenn Sie eine Sentinel- oder SIEM-Umgebung betreiben und der Engpass die Stunden sind, die Ihre Engineers mit dem Schreiben und Debuggen von Detections verbringen, statt darüber nachzudenken, was zu erkennen ist, dann ist genau das der Boilerplate, den eine LLM-Schleife vom Tisch nimmt — ohne Ihre Detection-Qualität einem Modell auf Vertrauen zu überlassen. Die Methode trägt, ob Sie ein MSSP sind, der Regeln über viele Mandanten pflegt, oder ein mittelständisches Security-Team, das seine eigene Umgebung betreut. Wie das als Engineering-Arbeit aussieht, ist bewusst unspektakulär: eng anfangen, das Prüf-Orakel an Ihr echtes Schema und einen repräsentativen Ausschnitt anschließen und beweisen, dass die Schleife korrekte Detections ausliefert, bevor Sie sie skalieren.

Wenn das das Problem ist, das Sie tatsächlich haben, ist der KI-Readiness-Check der günstigste Weg herauszufinden, ob sich der Bau in Ihrer Umgebung lohnt — mit einem ehrlichen Go/No-Go am Ende statt einer weiteren überzeugenden Demo. Wenn Sie es lieber erst besprechen möchten, nehmen Sie Kontakt auf.