Sentinel-Detektionen, die nachweislich stimmen.
Dieses System erzeugt Detektionsregeln für Microsoft Sentinel und beweist mit Microsofts eigenem Parser, dass sie tragen. 185 Tests decken die Prüf-Logik ab — und alles läuft offline in Ihrem Netz.
Das teure Problem ist nicht die Generierung — es ist das Vertrauen
Generierung ist Ware geworden
Microsofts eigener Security Copilot schreibt Detektionsabfragen (KQL) — enthalten in Lizenzen, die viele Unternehmen ohnehin bezahlen. Der Wert steckt nicht mehr im Schreiben der Regel.
Eine falsche Regel schweigt
Eine plausibel aussehende Detektion, die subtil falsch ist, feuert auf Rauschen — oder übersieht den Angriff still. Im Review wirkt sie sauber. Erst im Ernstfall zeigt sich, dass sie nie funktioniert hat.
Rund 13 % sind kaputt
So viele Detektionsregeln feuern nie — gemessen von CardinalOps an über 13.000 Regeln aus hunderten produktiven SIEM-Umgebungen, Sentinel eingeschlossen. Das ist ein Prüfproblem, kein Schreibproblem.
Ein Parser rät nicht — er bindet, oder er benennt das Scheitern
Jede erzeugte Abfrage wird deterministisch gegen Microsofts eigenen KQL-Parser gebunden — dieselbe Bibliothek, auf der Sentinel selbst aufsetzt. Jede Tabelle und jedes Feld wird gegen Ihr echtes Schema aufgelöst, nicht gegen eine Annahme. Werkzeuge, die stattdessen eine zweite KI „drüberschauen“ lassen, erben genau die Unsicherheit, die sie beheben sollen: eine Vermutung bewertet eine Vermutung.
Das Unverifiziert-Kennzeichen
Der Report hält fest, was gegen Ihr Schema nicht geprüft werden konnte — statt es zu verstecken. Ein markiertes „unverifiziert“ trägt mehr als ein grünes Häkchen, hinter dem keine Prüfung steckt.
Falle 1: strukturell leer
Eine Regel, die aufgrund ihrer eigenen Logik nie eine Zeile zurückgeben kann. Sie parst sauber, läuft fehlerfrei — und feuert in keinem einzigen Fall. Die Bindung fängt das ab, bevor die Regel produktiv geht.
Falle 2: fehlendes Feld
Eine Regel verweist auf eine Tabelle oder ein Feld, das in Ihrem Workspace nicht existiert. Im Review sieht sie sauber aus, an echten Daten liefert sie nichts. Die Schema-Bindung deckt genau diese Lücke auf.
Läuft offline — deshalb Lizenz statt SaaS
Die Prüfung braucht nichts außer der Regel und dem Schema: kein Netzzugriff, keine Workspace-Verbindung, keine ausgehende Verbindung zu irgendeiner Cloud. Auch die Erzeugung bleibt auf Wunsch im Haus — das System läuft nachgewiesen gegen ein lokal betriebenes Modell (vLLM); der Umstieg besteht aus zwei Umgebungsvariablen. Ihre Detektionen und Ihre Logik verlassen Ihr Netz nie. Ein reguliertes SOC kauft keine Blackbox, die seine Regeln in eine fremde Cloud schickt — es lizenziert etwas, das im eigenen Perimeter läuft. Warum genau diese Lieferform Sie nach BaFin-Auffassung von den DORA-Drittparteien-Pflichten entlastet, erklärt das DORA-Datenblatt.
Die ehrliche Grenze
Die Bindung beweist, dass eine Regel technisch tragen kann — nicht, dass ihre Logik die richtige Bedrohung jagt. Dafür gibt es einen optionalen Zweitgutachter auf Sprachmodell-Basis: bewusst ein anderes Modell, strukturiert befragt und nur beratend — die Entscheidung, ob eine Regel trägt, bleibt bei der deterministischen Prüfung und beim Menschen mit Bedrohungsmodell. Ein Überversprechen wäre genau die Sorte plausibel klingender Fehlaussage, gegen die dieses System gebaut ist.
Lizenz und Preis
Sie beschreiben kurz Ihre Sentinel-Umgebung, ich zeige das System in einer 30-minütigen Demo an Ihrem Kontext — danach erhalten Sie ein schriftliches Lizenzangebot. Zuerst gebaut für die Bluerope Consult GmbH; dort schrumpfte die Query-Entwicklung von Tagen auf Minuten.
