From IOCs to Regex: Automating CTI Operationalization for SOC with LLMs

1. Problemstellung

Cyber Threat Intelligence (CTI) Berichte enthalten Indikatoren für Kompromittierungen (IOCs), die für Sicherheitsoperationen (SOC) essenziell sind. Um diese IOCs in der Praxis nutzbar zu machen, müssen sie in reguläre Ausdrücke (Regex) umgewandelt werden, um sie in SIEM-Systemen (Security Information and Event Management) oder bei der forensischen Analyse gegen heterogene Logdaten abzugleichen.

Der aktuelle Prozess ist jedoch stark manuell geprägt und weist folgende kritische Mängel auf:

• Zeitintensivität: Der manuelle Transfer von IOCs aus Berichten zu validen Regex-Mustern dauert Stunden bis Tage.
• Fehleranfälligkeit: Analysten machen Syntaxfehler oder wählen falsche Capture-Groups (Gruppen, die extrahiert werden sollen).
• Skalierbarkeit: Die wachsende Menge an CTI-Berichten überfordert manuelle Teams.
• Lücke in der Automatisierung: Bisherige Ansätze nutzen Large Language Models (LLMs) zwar zur Extraktion von IOCs, lassen aber den kritischen Schritt der Transformation in deploybare Regex-Muster offen. Zudem generieren bestehende LLM-Ansätze oft zu einfache Muster oder solche, die syntaktisch ungültig sind.

Die Herausforderung besteht darin, Regex-Muster zu erstellen, die einerseits präzise genug sind, um Angriffe zu erkennen, aber andererseits flexibel genug, um Variationen in Systemumgebungen (z. B. verschiedene Pfadtrennzeichen, Groß-/Kleinschreibung) und Angreifer-Verhalten abzudecken, ohne zu viele False Positives zu produzieren.

2. Methodik: IOCRegex-gen

Die Autoren stellen IOCRegex-gen vor, ein vollautomatisiertes System auf Basis von LLMs, das extrahierte IOCs in deploybare Regex-Muster übersetzt. Das System besteht aus zwei Hauptphasen:

A. Phase 1: Identifikation von Capture Groups (Capture Group Finding)

Ein zentrales Problem ist die Unterscheidung zwischen statischen Teilen eines IOCs (die als Capture Groups für die Extraktion dienen sollen) und variablen Teilen (die als Non-Capture Groups behandelt werden müssen).

• Wissensbasierte Graph-Datenbank: Das System nutzt eine Graph-Datenbank (Neo4j), die native Windows-Pfade, Registry-Schlüssel und Befehlszeilenargumente (für Windows 8–11 und Server-Versionen) als Baumstrukturen abbildet.
• Algorithmen:
  • Für Dateipfade und Registry-Keys: Ein Algorithmus durchsucht die Graph-Datenbank nach längsten zusammenhängenden Sequenzen von Substrings, die als native Systemelemente identifiziert werden. Diese werden als Capture Groups markiert.
  • Für Befehlszeilenargumente: Der Algorithmus unterscheidet zwischen Befehlen (Hauptknoten) und Parametern (Kindknoten). Bekannte Befehle und ihre Standardparameter werden als Capture Groups behandelt, während benutzerdefinierte Werte (z. B. <remote_host>) als variable Non-Capture Groups markiert werden.
• Filterung: IOCs, die keine identifizierbaren Capture Groups enthalten, werden als False Positives der Extraktionsphase verworfen.

B. Phase 2: Regex-Generierung durch iteratives Reasoning

Da LLMs oft syntaktisch ungültige Regexes oder solche mit falschen Gruppierungen produzieren, wird ein mehrstufiger Validierungs- und Verfeinerungsprozess eingesetzt:

1. Initiale Generierung: Das LLM (z. B. GPT-4o) generiert basierend auf dem IOC und den ermittelten Capture Groups einen ersten Regex-Entwurf.
2. Debugging-Schleife: Ein Regex-Debugger prüft, ob der Entwurf das Original-IOC korrekt matcht. Bei Fehlern wird die Fehlermeldung an das LLM zurückgespeist, um den Regex iterativ zu korrigieren.
3. Validierung von Non-Capture Groups: Es wird geprüft, ob das Muster versehentlich Non-Capture Groups enthält, die als Capture Groups definiert sein sollten (oder umgekehrt).
4. Über-Verallgemeinerungs-Check (Over-Generalization Check): Um zu verhindern, dass das LLM zu generische Muster (z. B. .*) erzeugt, werden 10 zufällige Teststrings generiert. Matcht der Regex alle diese Strings, wird er als zu allgemein verworfen und der Prozess neu gestartet.
5. Bewertung und Auswahl (Grading): Für ein IOC werden mehrere Kandidaten-Regexes generiert. Diese werden nach einer Formel bewertet, die Punkte für korrekte Capture Groups und Strafpunkte für falsche Non-Capture Groups vergibt. Der Regex mit dem höchsten Score wird ausgewählt.

3. Wichtige Beiträge

1. IOCRegex-gen System: Ein End-to-End-System, das die Lücke zwischen CTI-Extraktion und operativer Detektion schließt, indem es IOCs direkt in Regex übersetzt.
2. Neuartige Methoden:
   • Eine wissensbasierte, graph-basierte Methode zur automatischen Identifikation von Capture Groups unter Nutzung von Systemwissen.
   • Ein Reasoning-basierter Workflow mit iterativer Validierung, der syntaktische Korrektheit, semantische Genauigkeit und eine angemessene Generalisierung sicherstellt.
3. Umfassende Evaluation: Die Studie basiert auf über 3.000 realen CTI-Berichten und mehr als 2.400 Ground-Truth-Strings aus dem MITRE ATT&CK Evaluation Framework.

4. Ergebnisse

Die Evaluation ergab folgende Leistungskennzahlen:

• Trefferquote (Hit Rate): Die generierten Regexes erreichten eine durchschnittliche Trefferquote von 99,1 % auf den Ground-Truth-Daten. In einigen Datensätzen (z. B. Enterprise2024 LockBit) wurde sogar 100 % erreicht.
• False-Positive-Rate: Die durchschnittliche False-Positive-Rate lag bei nur 0,8 %.
• Komplexität: Die generierten Regexes wiesen eine hohe strukturelle Komplexität auf (durchschnittliche Bewertung > 3), was zeigt, dass sie nicht nur einfache Literal-Matches sind, sondern komplexe Muster mit Capture Groups enthalten.
• Generalisierung: Die Ähnlichkeit zwischen den generierten Regexes und den ursprünglichen IOCs lag bei ca. 0,4, was darauf hindeutet, dass das System Variationen erfolgreich abdeckt, ohne zu spezifisch zu sein.
• Ablationsstudie: Der Vergleich mit Baseline-Modellen (direktes Prompting ohne die speziellen Komponenten) zeigte, dass IOCRegex-gen die Trefferquote um über 30 % steigerte und die False-Positive-Rate signifikant senkte. Dies unterstreicht die Notwendigkeit sowohl der Capture-Group-Identifikation als auch des iterativen Reasoning-Prozesses.

5. Bedeutung und Fazit

Das Paper demonstriert, dass die Automatisierung der CTI-Operationalisierung durch LLMs möglich ist, wenn spezifische Sicherheitskontexte (wie die Unterscheidung von Systempfaden vs. Angreifer-Variablen) berücksichtigt werden.

• Praktischer Nutzen: Das System entlastet SOC-Analysten von repetitiven, fehleranfälligen Aufgaben und beschleunigt die Reaktion auf neue Bedrohungen erheblich.
• Technischer Fortschritt: Es zeigt, dass LLMs durch gezielte Validierungsschleifen und Wissensintegration (Graph-Datenbanken) über ihre natürlichen Grenzen hinausgeführt werden können, um hochpräzise, sicherheitsrelevante Muster zu generieren.
• Open Source: Der Quellcode ist verfügbar, was die Reproduzierbarkeit und Weiterentwicklung in der Community fördert.

Zusammenfassend bietet IOCRegex-gen einen robusten Ansatz, um die manuelle Lücke zwischen Threat Intelligence und automatisierter Detektion zu schließen, und setzt neue Maßstäbe für die Generierung von Regex-Mustern im Sicherheitskontext.