Ein strukturierter Arbeitsablauf zur Umwandlung von Cyberbedrohungsinformationen in berechenbare Erkennungsmuster

Zusammenfassung

Hier präsentieren wir ein Protokoll zur Umwandlung von Kompromittierungsindikatoren aus Dateipfaden, Registrierungsschlüsseln und Kommandozeilenindikatoren aus Cyber-Bedrohungs-Intelligence-Berichten in validierte reguläre Ausdrücke für Sicherheitsinformations- und Ereignismanagement-(SIEM)-Erkennungsregeln, wobei Ensemble-Extraktion mit großen Sprachmodellen (LLMs) und graphunterstützte Komponentenkennzeichnung verwendet wird.

Zusammenfassung

Security Operations Centers (SOCs) wandeln routinemäßig Berichte über Cyberbedrohungsinformationen (CTI) in operative Detektionsinhalte um. Ein beständiger Engpass in diesem Workflow ist die Übersetzung extrahierter Kompromittierungsindikatoren (IOCs), insbesondere Dateipfade, Registrierungsschlüssel und Kommandozeilenzeichen, in deployable reguläre Ausdrücke (Regexes), die sich für die Einbettung in Sicherheitsinformations- und Ereignismanagement-(SIEM)-Korrelationsregeln eignen. Obwohl frühere Arbeiten die automatisierte Indikator-of-Compromise-(IOC)-Extraktion verbessert haben, bleibt die Umwandlung extrahierter Zeichenketten in validierte Regex-Muster weitgehend manuell, erfordert spezialisierte Expertise und ist fehleranfällig. Ziel dieses Protokolls ist es, ein standardisiertes, reproduzierbares Verfahren für die IOC-zu-Regex-Übersetzung bereitzustellen. Der Arbeitsablauf besteht aus fünf Schritten: (1) das Parsen heterogener CTI-Berichte in eine einheitliche Markdown-Darstellung; (2) IOC-Extraktion mit mehreren großen Sprachmodellen (LLMs) und Konsenswahl; (3) regelbasierte Normalisierung, Kategorisierung und Deduplizierung extrahierter IOCs; (4) graphunterstützte Beschriftung von IOC-Komponenten als Keep (Capture-Group) oder Discard (Non-Capture-Group); und (5) iterative Regex-Generierung mit diagnostischer Validierung gegenüber den ursprünglichen IOC-Strings. Zur Bewertung des Nutzens wurde der Workflow auf 3.156 CTI-Berichte angewendet, und die resultierenden Regexes wurden gegen mehr als 2.400 unabhängig gesammelte Ground-Truth-Strings aus zehn MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK) Evaluationsszenarien ausgewertet, was eine durchschnittliche Trefferquote von 99,1 % und eine durchschnittliche Cross-IOC-Mismatch-Rate von 0,8 % ergab. Das Protokoll dokumentiert daher eine reproduzierbare Implementierung für die IOC-zu-Regex-Übersetzung und legt explizit den aktuellen Anwendungsbereich, die operativen Annahmen und bekannten Ausfallfälle dar.

Einleitung

Cyberkriminalität stellt weiterhin erhebliche operative und finanzielle Belastungen für Organisationen im öffentlichen und privaten Sektor dar. Im Jahr 2023 überstiegen die gemeldeten Verluste durch Cyberkriminalität in den Vereinigten Staaten 12,5^Milliarden US-Dollar, was das Ausmaß und die Persistenz böswilliger Aktivitäten unterstreicht. In diesem Umfeld dienen Security Operations Centers (SOCs) als primäre operative Einheiten, die für die Erkennung, Analyse und Reaktion auf Bedrohungen in Echtzeit verantwortlich sind.
Die Erkennungslogik in vielen SOC-Workflows wird durch regelbasierte Mechanismen innerhalb von Security Information and Event Management (SIEM)-Plattformen implementiert, die weit verbreitet sind, da sie interpretierbar, deterministisch und kompatibel mit bestehenden SOC-Workflows sind. Unter den verschiedenen Regeltypen sind korrelationsbasierte SIEM-Regeln besonders wichtig, um Angriffsverhalten zu identifizieren, das sich über mehrere Ereignisse, Hosts und Zeitfenster erstreckt. Innerhalb dieser Regeln funktionieren reguläre Ausdrücke (Regexes) als wiederverwendbares Suchprimitiv: Analysten betten sie in breitere Erkennungsregeln ein, die Feldbeschränkungen, plattformspezifische Filter und Ereigniskorrelationslogik hinzufügen, anstatt sie als eigenständige Detektoren einzusetzen.

In der Praxis beginnen SOC-Analysten die Regelentwicklung oft mit Indikatoren für Kompromittierung (IOCs), die aus Cyber Threat Intelligence (CTI)-Berichten stammen, die von Sicherheitsanbietern, unabhängigen Forschern oder öffentlichen Wissensdatenbanken wie MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK)² veröffentlicht wurden. Diese IOC-Strings können Dateipfade, Kommandozeilenfragmente, Registrierungsschlüssel oder andere strukturierte Artefakte enthalten, die während Angriffen^{beobachtet wurden}. Die Übersetzung solcher Zeichenketten in Regex-Muster, die für SIEM-Korrelationsregeln geeignet sind, ist eine wiederkehrende Aufgabe im Regelerstellungs-Workflow.

Dieser Übersetzungsschritt ist ein praktischer operationeller Engpass. Das Erstellen von Regex-Mustern, die allgemein genug sind, um sinnvolle Variationen zu erfassen, aber präzise genug, um unbeabsichtigte Übereinstimmungen zu vermeiden, erfordert spezielles Fachwissen; Kleine syntaktische Fehler oder falsche Entscheidungen darüber, welche Komponenten erhalten oder verallgemeinert werden sollen, können eine ansonsten nützliche Detektionsregel wirkungslos machen. Da diese Arbeit manuell, repetitiv und detailorientiert ist, kann sie die Erkennung für neue Bedrohungen verzögern, eine Überprüfung durch erfahrenere Analysten erfordern und zur Arbeitsbelastung der Analysten in den operativen SOC-Einstellungen ^4,5 beitragen.

Die zentrale Herausforderung bei der IOC-zu-Regex-Übersetzung besteht darin zu entscheiden, welche Teile eines IOC stabiles, angreiferrelevantes Verhalten enkodieren und daher erhalten bleiben sollten, welche Teile umgebungs- oder hostspezifische Variationen widerspiegeln und verallgemeinert werden sollten. Zum Beispiel müssen kanonische Register-Wurzeln wie HKEY_CLASSES_ROOT\CLSID, Systemverzeichnisse wie System32 und bekannte ausführbare Namen wie rundll32.exe typischerweise explizit bleiben, während Benutzerprofilpfade, host-spezifische Security Identifiers (SIDs) und Globally Unique Identifiers (GUIDs) normalerweise abstrahiert werden sollten. Wenn man dies über heterogene IOC-Typen hinweg konsequent macht, ist das, was die Übersetzungsaufgabe nicht trivial macht. Im gesamten Protokoll bezeichnen wir erstere als erhaltene oder Capture-Group-Komponenten und letztere als abstrakte oder nicht-capture-group-komponenten.

Frühere Arbeiten untersuchten automatisierte Extraktion von Bedrohungsinformationen aus unstrukturiertem Text mittels natürlicher Sprachverarbeitung und Entitätsextraktionstechniken ^6,7. In jüngerer Zeit haben mehrere Studien die direkte Erzeugung von Detektionsregeln aus CTI-Berichten mit großen Sprachmodellen (LLMs^{) untersucht}. Diese Ansätze zeigen, dass Teile des Regelerstellungs-Workflows durch Sprachmodelle unterstützt werden können, konzentrieren sich jedoch typischerweise nicht auf das spezifische operative Problem, Regex-Muster zu erzeugen, die die Capture-Group-Semantik erhalten und für die nachgelagerte SIEM-Bereitstellung geeignet bleiben. Komplementäre Arbeitsbereiche haben CTI-Inhalte für den nachgelagerten Einsatz auf unterschiedliche Weise strukturiert, darunter wissensgraphbasierte Darstellungen wie TINKER⁹ und CTI-gesteuerte Generierung von Log-Hunting-Abfragen wie ThreatRaptor¹⁰, die unstrukturierte CTI in strukturiertes Wissen oder domänenspezifische Abfragesprachen umwandeln, anstatt in Regex-Muster, die für die Einbettung in SIEM-Korrelationsregeln vorgesehen sind.

Parallel dazu haben frühere Studien automatisierte Regex-Synthese mit beispielbasierten Methoden, neuronaler Translation und Generate-and-Repair-Ansätzen 11,12,13,14,15,16 untersucht. Diese Methoden sind jedoch im Allgemeinen für Settings konzipiert, die auf großen Mengen repräsentativer Beispiele oder natürlichsprachlicher Beschreibungen basieren, statt auf IOC-gesteuerten Detektionskontexten. In SOC-Workflows sind IOC-Strings oft spärlich, strukturell heterogen und eng mit der operativen Semantik verbunden. Diese Diskrepanz motiviert einen Workflow, der auf die IOC-zu-Regex-Übersetzung zugeschnitten ist, anstatt zu behaupten, dass bestehende Regex-Generierungsmethoden im Großen und Ganzen unzureichend seien.

Das hier vorgestellte Protokoll konzentriert sich speziell auf die IOC-zu-Regex-Übersetzungsphase des SOC-Detektionsworkflows. Die IOC-Extraktion wird als vorgelagerter Input behandelt, der aus manueller Analyse, automatisierten Werkzeugen oder einer Kombination aus beidem stammen kann; das Protokoll versucht nicht, vollständige SIEM-Regeln zu erzeugen. Stattdessen bietet es ein systematisches Verfahren zur Umwandlung von IOC-Strings in Regex-Muster, die syntaktisch gültig, semantisch interpretierbar und für den operativen Einsatz geeignet sind. Der aktuelle IOC-Anwendungsbereich ist bewusst: Dateipfade, Registrierungsschlüssel und Kommandozeilenindikatoren enthalten sowohl stabile als auch variable strukturelle Komponenten, die von der Regex-Generalisierung profitieren, während atomare Indikatoren wie IP-Adressen, Domänen und Hashes natürlicher durch exakt-übereinstimmungsbedingte Bedingungen oder Reputations-Lookups operationalisiert werden und daher außerhalb des primären Bereichs fallen. Innerhalb dieser Grenzen ist das Protokoll darauf ausgelegt, über SOC-Umgebungen hinweg portabel zu sein, die vergleichbare Eingabeformate und Werkzeugbedingungen teilen.

Protokoll

Verwenden Sie den folgenden fünfstufigen Workflow, um einen CTI-Bericht in validierte Regex-Muster mit nachverfolgbaren Zwischenausgaben umzuwandeln (siehe Abbildung 1 für einen Überblick).

1. Systemaufbau

1. Installiere Voraussetzungen.
   1. Installiere Python 3.8 oder neuer, alle in requirements.txt aufgeführten Python-Abhängigkeiten und eine Neo4j-Graphdatenbank.
      1. Bestätigen Sie den Zugriff auf eine oder mehrere Anwendungsprogrammierschnittstellen (APIs) für die gewählten großen Sprachmodelle und überprüfen Sie, ob der Neo4j-Dienst läuft und vom lokalen Rechner aus erreichbar ist.
   2. Bestätigen Sie, dass die Materialtabelle vollständig ist.
      1. Überprüfen Sie, dass Laufzeitabhängigkeiten aufgeführt sind, einschließlich der Python-Interpreter-Version, der Pipeline-Abhängigkeiten, der Neo4j-Version und des Portable Document Format (PDF)-Textextraktions-Backends.
      2. Überprüfen Sie, dass LLM-Konfigurationsoptionen aufgeführt sind, einschließlich der LLM-Anbieter, Modellnamen und -versionen, Temperatur, Argumentationsaufwandsoptionen und Ensemble-Voting-Einstellungen.
      3. Überprüfen Sie, dass Eingabe- und Ausgabeformate aufgeführt sind, einschließlich der unterstützten Eingabedateiformate und der unterstützten Exportformate.
2. Starte die Web-Benutzeroberfläche (UI).
   1. Öffnen Sie ein Terminal, navigieren Sie zum Root-Verzeichnis der Referenzimplementierung und starten Sie die Anwendung mit dem dokumentierten Startbefehl (in der Referenzimplementierung: cd langchain_pipeline gefolgt von streamlit run app_v2.py).
   2. Überprüfen Sie, dass die Anwendung auf http://localhost:8501 lädt und das Seitenleisten-Konfigurationspanel sichtbar ist.
3. Konfigurieren Sie den LLM-Provider.
   1. Im LLM-Konfigurationsbereich der Seitenleiste wählen Sie einen LLM-Anbieter aus, geben Sie den Modellnamen ein und geben Sie einen gültigen API-Schlüssel an.
   2. Notieren Sie den Anbieter, den Modellnamen, die Modellversion, die Temperatur, die Argumentationsmöglichkeiten und das Zugriffsdatum für die Materialtabelle.
      HINWEIS. In der Referenzimplementierung setzt die Einzel-LLM-IOC-Extraktion standardmäßig auf das primäre kommerzielle LLM, das in der Materialtabelle mit Temperatur = 0,0 aufgeführt ist; Die Regex-Generierung steht standardmäßig auf Temperatur = 0,3.
4. Aktivieren Sie das Ensemble-Voting (optional, aber empfohlen für reproduzierbare Ergebnisse).
   1. Aktivieren Sie die Option Ensemble Voting in der Seitenleiste, um nur IOCs zu behalten, die eine Mindeststimmenschwelle erreichen (Minimum Votes ≥ 2 empfohlen).
   2. Fügen Sie zusätzliche LLM-Instanzen hinzu, indem Sie Provider, Modellname, API-Schlüssel und Anzahl der Ausführungswiederholungen pro Modell angeben.
      1. Notieren Sie die Anzahl der Wiederholungen jedes Anbieters und die gewählte Mindeststimmenschwelle.
         HINWEIS. Ensemble-Abstimmung ist optional. Wenn deaktiviert, führt die Pipeline eine Einzel-LLM-Extraktion durch und der Konsensfilter wird übersprungen. Die Standardeinstellungen des Ensembles sind Wiederholungen = 1 pro konfiguriertem Modell und min_votes = 2.
5. Verbinde dich mit Neo4j.
   1. Im Abschnitt Neo4j Connection der Seitenleiste geben Sie die Verbindungs-URI (zum Beispiel bolt://localhost:7687), den Benutzernamen und das Passwort ein.
   2. Bestätigen Sie, dass die Schnittstelle eine erfolgreiche Verbindung meldet. Fahren Sie nicht ohne aktive Verbindung fort.
6. Sichern Sie alle Zugangsdaten.
   1. Behandle LLM-API-Schlüssel und das Neo4j-Passwort als sensible Zugangsdaten. Speichere sie in Umgebungsvariablen oder einem Secrets Manager statt in Quellcode-Dateien, exportierten Berichten oder Screenshots und rotiere jeden Schlüssel umgehend, wenn ein Leck vermutet wird.
      HINWEIS. Dieses Softwareprotokoll benötigt keine chemische Abzugshaube, keinen Biosicherheitsschrank oder andere physische Eindämmungsgeräte; vertrauliche CTI-Berichte und Zugangsdaten gemäß institutionellen Datenschutzrichtlinien zu bearbeiten.

2. Stufe 1: Dokumentenparsing

1. Verfahren.
   1. Navigiere zum Verarbeitungs-Tab in der Hauptoberfläche.
   2. Laden Sie einen CTI-Bericht in einem unterstützten Format hoch (.pdf, .docx, .md, .txt oder .html).
   3. Klicken Sie auf "Nächste Stufe ausführen", um Stufe 1 auszuführen, oder auf "Alle Stufen ausführen", um die vollständige Pipeline nacheinander auszuführen.
2. Bestätige den Kontrollpunkt Stufe 1.
   1. Bestätigen Sie, dass eine Markdown-Vorschau des Eingabedokuments angezeigt wird.
   2. Überprüfen Sie, dass Dateipfade, Registrierungsschlüssel, Kommandozeilenfragmente und Abschnittsgrenzen in der Vorschau erhalten bleiben.
   3. Wenn technische Zeichenketten abgeschnitten oder Formatierung weggelassen wird, korrigieren Sie die Quelldatei oder bevorbereiten Sie das Dokument mit einem externen Konverter vor dem erneuten Hochladen.

3. Phase 2: IOC-Extraktion

1. Verfahren.
   1. Bestätigen Sie die LLM-Konfiguration (und Ensemble-Voging, falls aktiviert).
   2. Klicken Sie auf "Nächste Stufe ausführen", um Stufe 2 auszuführen.
2. Bestätigen Sie den Kontrollpunkt Stufe 2.
   1. Bestätigen Sie, dass die Schnittstelle eine IOC-Sammlung im JavaScript Object Notation (JSON)-Format mit drei Top-Level-Schlüsseln anzeigt: Dateipfade, Befehlszeilen und Registrierungsschlüssel.
   2. Wenn das Ensemble-Voting aktiviert ist, wird überprüft, dass Stimmenzählungen und beitragende Modell-Metadaten für jedes behaltene IOC erfasst werden.
      HINWEIS. Das wortwörtliche Stage-2-System und die menschlichen Prompts sowie die Level-5-Generierungs- und Optimierungsprompts werden als Supplementary File 1 (Supplemental_File_1_Prompts.txt) veröffentlicht.

4. Stufe 3: IOC-Analyse und Klassifikation

1. Verfahren.
   1. Klicken Sie auf "Nächster Schritt ausführen", um Stufe 3 auszuführen.
2. Bestätigen Sie den Kontrollpunkt Stufe 3.
   1. Bestätigen Sie, dass jedes erhaltene IOC mit einer standardisierten Kategorie, einer Quellcode-Marke und dem ursprünglichen Extraktionsschlüssel, sofern verfügbar, aufgeführt ist.

5. Phase 4: Neo4j-unterstützte IOC-Normalisierung

1. Verfahren.
   1. Bestätigen Sie, dass die Neo4j-Verbindung aktiv ist.
   2. Klicken Sie auf "Nächste Stufe ausführen", um Stufe 4 auszuführen.
   3. Überprüfen Sie die Normalisierungsausgabe pro IOC und überprüfen Sie, ob Keep/Discard-Labels für Pfad- und Kommandozeilenkomponenten erstellt werden und dass Registrierungsschlüssel eine zusammenhängende kanonische Teilzeichenkette liefern.
2. Bestätigen Sie den Kontrollpunkt Stufe 4.
   1. Bestätigen Sie, dass für jeden IOC-Typ normalisierte IOC-Tabellen erstellt werden (Dateipfade, Registerschlüssel, Kommandozeilenindikatoren).
   2. Überprüfen Sie, dass jeder Eintrag den ursprünglichen Wert, den normalisierten Wert und eine Komponentenliste von Element-/Statuspaaren mit der Bezeichnung "behalten" oder "Verwerfen" enthält.
      HINWEIS. Detailliertes Neo4j-Schema, Cypher-Abfragen, Entscheidungsregeln und das Normalisierungsverfahren für Registry-Schlüssel sind in Supplementary File 2 aufgeführt; ein ausgearbeitetes Beispiel findet sich in Representative Results.

6. Stufe 5: Regex-Generierung und Wertung

1. Verfahren.
   1. Klicken Sie auf "Nächste Stufe ausführen", um Stufe 5 auszuführen. Bestätigen Sie, dass jedes normalisierte IOC und seine verbotene Token-Liste zur Regex-Generierung und deterministischen Validierung eingereicht wurden.
   2. Wenn ein Kandidat die Validierung nicht besteht, lassen Sie die Optimierungsschleife den Regex verfeinern, bis ein konformer Kandidat erstellt wird oder die Iterationsgrenze erreicht ist.
   3. Überprüfen Sie die diagnostische Ausgabe, die Optimierungshistorie und die Iterationszählungen für jedes IOC, dessen endgültiges Regex von konform zu mit der höchstbewerteten Teilübereinstimmung zurückfällt (verzeichnet als used_fallback = True).
2. Bestätige den Kontrollpunkt Stufe 5.
   1. Bestätigen Sie, dass für jedes zurückbehaltene IOC ein endgültiges Regex erstellt wird.
   2. Überprüfen Sie, dass Kandidatenwerte, Optimierungshistorien, Themenlisten und Iterationszählungen erfasst werden.
   3. Überprüfen Sie, dass pro IOC Telemetrie, einschließlich geschätzter Tokennutzung und Latenz, protokolliert wird.
      HINWEIS. Detaillierte Regex-Validierungsregeln, die Bewertungsformel und Iterationskontrollparameter sind in Supplementary File 2 aufgeführt.

7. Analyse und Validierung

1. Öffnen Sie den Analytics-Reiter, um IOC-Verteilungen, Ensemble-Abstimmungsergebnisse (wenn aktiviert), Regex-Qualitätszusammenfassungen und Optimierungsstatistiken zu überprüfen. Verwenden Sie diese Zusammenfassungen, um Anomalien wie Extraktionsungleichgewichte oder wiederholte Optimierungsfehler zu erkennen.

8. Exportergebnisse

1. Wählen Sie im Export-Tab das Exportformat (Klartext, JSON oder YAML) aus und laden Sie das Regex-Set herunter. Bestätigen Sie, dass die exportierten Regexes die zugehörigen Scores und Kategorisierungsmetadaten enthalten.
2. Erstellen und laden Sie den vollständigen JSON-Bericht herunter, der geparste Dokumente, extrahierte IOCs, normalisierte Darstellungen, Kandidatenregexes und Endausgaben enthält. Bewahren Sie diesen Bericht als Reproduzierungsprotokoll auf.

9. Fehlerbehebung

1. Wenn Stufe 1 getrunkene oder leere PDF-Inhalte zurückgibt, werden Sie das Dokument vor dem erneuten Hochladen mit einem externen Konverter oder einem optischen Zeichenerkennungstool vorverarbeiten und sicherstellen, dass technische Artefakte in der Markdown-Vorschau sichtbar bleiben.
2. Wenn Stufe 2 zu wenige Konsens-IOCs liefert, überprüfen Sie die Anbieter-, Modell-, API-Key-, Wiederholungszahlen und Mindeststimmen-Einstellungen, bevor Sie die Schwelle ändern. Inspect schloss Kandidaten aus, um Halluzinationen von übermäßig strengem Wählen zu unterscheiden.
3. Wenn Stufe 4 alle Komponenten als verworfen kennzeichnet, überprüfe die Neo4j-Konnektivität und stelle sicher, dass der Graph das relevante Pfad-, Registry- oder CLI-Vokabular für den analysierten IOC-Typ enthält.
4. Wenn Stufe 5 ein Regex erzeugt, das kompiliert, aber beim Matching oder Übergeneralisierung fehlschlägt, inspizieren Sie die Optimierungshistorie, die diagnostische Fehlerposition und Übergeneralisierungsprüfungen, bevor der Kandidat neu generiert wird.

10. Bestätigen Sie die endgültigen Protokollausgaben.

1. Bestätigen Sie, dass die geparste Markdown-Datei, die IOC-Menge (konsensusvalidiert, wenn Ensemble-Voting aktiviert ist, oder Single-Model, wenn deaktiviert), die kategorisierte IOC-Tabelle und die graph-normalisierten IOC-Darstellungen alle vorhanden sind.
2. Bestätigen Sie, dass das SIEM-kompatible Regex-Set, die Analysezusammenfassungen und der vollständige JSON-Bericht vorhanden sind, und archivieren Sie den JSON-Bericht als Reproduzierbarkeitsdatensatz.

Ergebnisse

Dieser Abschnitt präsentiert repräsentative Ergebnisse aus dem IOC-zu-Regex-Protokoll und fasst die Referenzbewertung zusammen, die zur Bewertung ihrer operativen Anwendbarkeit verwendet wurde. Die Referenzbewertung verarbeitete 3.156 CTI-Berichte, die mit MITRE ATT&CK-Techniken zusammenhängen, analysierte mehr als 230.000 Sätze, extrahierte mehr als 63.000 IOC-Kandidaten und bewertete generierte Regexes mit mehr als 2.400 unabhängig gesammelten Ground-Truth-Strings aus zehn MITRE ATT&CK-Evaluationsszenarien. Diese Ground-Truth-Strings sind von Experten kuratierte Angriffsartefakte, die während der MITRE ATT&CK-Evaluationsübungen unabhängig von Cybersicherheitsanbietern gemeldet werden und spiegeln daher die strukturellen Muster wider, die menschliche Analysten und Anbieter in der Praxis dokumentieren. Die untenstehenden Ergebnisse konzentrieren sich auf Arbeitsablaufverhalten, strukturelle Korrektheit und Bewertungsergebnisse, die für die Analyse und Erkennung von operativen Logbüchern relevant sind.

Ein Überblick über die End-to-End-Pipeline findet sich in Abbildung 1, die die Phasen der Erfassungsgruppenfindung und Regex-Generierung zusammenfasst, die den Rest der repräsentativen Ergebnisse rahmen.

Stufe 1: Dokumentenparsing der Ausgabe

Abbildung 2 zeigt die Ausgabe von Stufe 1, in der ein Eingabe-CTI-Bericht in eine einheitliche Markdown-Darstellung umgewandelt wird. Nach erfolgreicher Ausführung zeigt die Benutzeroberfläche eine strukturierte Vorschau des Dokuments an, einschließlich Abschnittsgrenzen und Relevanzindikatoren.

Eine korrekte Ausführung wird durch kohärente Absatzsegmentierung und die Bewahrung technischer Artefakte wie Dateipfade, Registrierungsschlüssel und Kommandozeilenfragmente angezeigt. Übermäßige Abkürzungen oder Verluste der Formatierung in diesem Stadium können die nachgelagerte Analyse beeinflussen und sollten vor dem Fortschreiten behoben werden.

Phase 2: Konsensbasierte IOC-Extraktion

Abbildung 3 zeigt das Ergebnis von Phase 2, bei dem IOCs der Kandidaten mittels Multi-LLM-Ensemble-Voting extrahiert werden. Die resultierende Benutzeroberfläche präsentiert eine JSON-formatierte IOC-Sammlung, die mit Stimmenzahlen und beitragenden Modellen annotiert ist.

Nur IOCs, die die konfigurierte Mindestkonsensschwelle erreichen, werden beibehalten. IOCs, die in dieser Phase ausgeschlossen werden, spiegeln typischerweise modellspezifische Halluzinationen oder mehrdeutige Textfragmente wider. Ihr Ausschluss ist ein erwartetes und wünschenswertes Ergebnis, was darauf hindeutet, dass das Ensemble-Voting korrekt funktioniert.

Phase 3: IOC-Analyse und Klassifikation

Tabelle 2 fasst die erwartete Ausgabe, automatisierte Validierungsschritte und Analysten-bezogene Qualitätskontrollkontrollen für jede Protokollstufe zusammen.

Abbildung 4 zeigt die IOC-Kandidaten, die während der Ensemble-Abstimmung in Phase 2 die Konsensschwelle nicht erreicht haben, sowie die Schnittstelle für die Analysteninspektion. Solche Kandidaten spiegeln typischerweise modellspezifische Halluzinationen oder mehrdeutige Textfragmente wider. Abbildung 4 und Abbildung 5 entsprechen daher unterschiedlichen Stufenausgaben – der verworfenen Menge aus Stufe 2 und der erhaltenen Menge aus Stufe 3 – und nicht alternativen Ansichten desselben Stufen-3-Prozesses.

Abbildung 5 zeigt die von Stufe 3 erstellte IOC-Tabelle nach JSON-Parsing, regelbasierter Kategorisierung und IOC-Deduplizierung. Für jedes behaltene IOC zeichnet die Stufe eine standardisierte Kategorie, ein Quell-Tag und den ursprünglichen Extraktionsschlüssel auf, wenn verfügbar, bevor das IOC an die nachgelagerte Normalisierung weitergeleitet wird.

Phase 4: Graph-unterstützte IOC-Normalisierung über IOC-Typen hinweg

Abbildungen 6, Abbildung 7 und Abbildung 8 illustrieren repräsentative Normalisierungsergebnisse für drei IOC-Kategorien, die in der aktuellen Studie behandelt wurden: Dateipfade, Registrierungsschlüssel und Kommandozeilenindikatoren. Für jede Kategorie vergleichen die Zahlen das ursprüngliche IOC, das aus dem CTI-Bericht extrahiert wurde, mit der normalisierten Darstellung, die mit graphunterstützter Analyse erstellt wurde.

Über alle IOC-Typen hinweg zerlegt das Protokoll jedes IOC in semantische Komponenten und löst hierarchische Beziehungen mithilfe von strukturiertem Wissen, das in der Graphendatenbank kodiert ist. In der aktuellen Implementierung speichert Neo4j normalisierte Pfad-, Registry- und CLI-Knoten und verwendet Adjazenzbeziehungen, um zu testen, ob Komponenten zu anerkannten Ketten gehören. Diese Rolle ist analog zur Nutzung strukturierter ATT&CK-Kenntnisse während der Detektionstechnik².

Wichtig ist, dass dieser Normalisierungsschritt explizite semantische Rollen für IOC-Komponenten aufzeichnet, indem sie als behalten oder wegwerfen gekennzeichnet werden, anstatt sie stillschweigend aus dem Analysedatensatz zu entfernen. Der normalisierte String wird hauptsächlich aus Keep-Komponenten rekonstruiert, während Discard-Komponenten als Metadaten für die nachgelagerte Regex-Generierung und -Validierung verfügbar bleiben.

Die korrekte Durchführung dieser Stufe wird durch normalisierte IOCs angezeigt, die einen sinnvollen strukturellen Kontext bewahren und eine konsistente Capture-Group-Markierung über verschiedene IOC-Typen hinweg aufweisen. Der visuelle Vergleich zwischen ursprünglichen und normalisierten Darstellungen bietet einen praktischen Qualitätskontrollmechanismus, um zu überprüfen, dass die Capture-Group-Auflösung konsistent und ohne unbeabsichtigten Informationsverlust angewendet wurde.

Stufe 5: Generierung regulärer Ausdrucks mit zusätzlicher Constraint-basierte Auswahl

Abbildung 9 veranschaulicht die Ausgabe von Stufe 5, in der das Protokoll strukturkonforme reguläre Ausdrücke aus normalisierten IOCs über einen iterativen Validierungs-Workflow erzeugt. Die Implementierung kombiniert einen initialen Generierungsprompt, diagnostisches erneutes Prompting, wenn ein Kandidat das IOC nicht übereinstimmt, discard-aware validierung und gekappte Retry-Loops.

Gegeben ein normalisiertes IOC und die zugehörige Spezifikation der Komponente behalten/wegwerfen, generiert der Workflow zunächst einen initialen Regex-Kandidaten. Der Kandidat wird dann gegen das IOC getestet, bei Fehlschlägen diagnostisch erneut aufgefordert, auf verbotene verworfene Token geprüft und mit zufälligen negativen Zeichenketten auf Übergeneralisierung ausgewertet.

Wenn mehrere Kandidaten die grundlegenden Validierungsprüfungen erfüllen, wendet das Protokoll einen ergänzenden, auf Einschränkungen basierenden Auswahlmechanismus an, um ein repräsentatives Regex für die nachgelagerte Nutzung zu behalten. Die aktuelle Implementierung bewertet Kandidaten mit 'Score = n_cg - n_wc', wobei 'n_cg' die Anzahl der repräsentierten Keep-Komponenten und 'n_wc' die Anzahl der im Regex vorhandenen verworfenen oder nicht abgebildeten Tokens ist.

Die Auswahlfunktion ist definiert als:

Punktzahl = n_cg − n_wc

Dies ist die gleichgewichtige Spezialisierung (α = β = 1) der allgemeineren Form Score = α·n_cg − β·n_wc. Hier bezeichnet n_cg die Anzahl der repräsentierten Keep-Komponenten und n_wc die Anzahl der Abwurfkomponenten oder nicht abgebildeten zusätzlichen Token, die durch das Regex wieder eingeführt werden. Die Implementierung erfasst außerdem Iterationszählen, Ausgabelisten, geschätzten Tokenverbrauch, Cache-Nutzung und Latenztelemetrie für jeden IOC. Die Gleichgewichtseinstellung wurde als einfacher deterministischer Standard für die Referenzimplementierung verwendet; Da eine fehlende Halte-Komponente und eine wieder eingeführte Discard-Komponente als gleichermaßen unerwünscht behandelt werden, können andere Gewichtungen in Bereitstellungskontexten bevorzugt werden, in denen Fehlalarme und Fehlalarme unterschiedliche Betriebskosten verursachen.

Der endgültige Regex wird als Kandidat ausgewählt, der diese Einschränkungen am besten erfüllt. Regexes, die benötigte Capture-Group-Komponenten in optionale Konstrukte einfügen, zum Beispiel ( ... )?, werden von der Auswahl ausgeschlossen, da sie die semantische Konsistenz schwächen. Dieser Auswahlschritt ist eine Hilfsmaßnahme zum Erzeugungsprozess und soll nicht als eigenständige Qualitätskennzahl dienen.

Analytischer Überblick über die CTI-Verarbeitung

Abbildung 10 gibt einen Überblick über die CTI-Analyseergebnisse über alle bearbeiteten Dokumente hinweg. In der Referenzbewertung ergab die IOC-Extraktion von 3.156 CTI-Berichten mehr als 63.000 IOC-Kandidaten, darunter 12.195 Dateipfade, 2.302 Registrierungsschlüssel und 10.286 Kommandozeilenindikatoren, wobei die übrigen Kandidaten zu nicht-regex-Ziel-IOC-Typen gehörten.

Diese Zählungen liefern eine übergeordnete Bestätigung, dass die extrahierten Indikatoren in den drei IOC-Kategorien konzentriert sind, die vom aktuellen Protokoll anvisiert werden, und zeigen zudem, dass viele extrahierte Artefakte außerhalb des Regex-Generationsbereichs liegen. Beim Reproduzieren des Workflows geben Sie die genaue Anzahl der verarbeiteten CTI-Berichte, die Gesamtzahl der IOC-Kandidaten, die kategorienweise Zählungen sowie den Anbieter, das Modell, die Modellversion, die Temperatur, die Wiederholungszahl und den bei der Extraktion verwendeten Konsensschwelle an.

In der Referenzbewertung wurden generierte Regexe mit mehr als 2.400 unabhängig gesammelten Ground-Truth-Strings aus zehn MITRE ATT&CK-Evaluationsszenarien bewertet und erreichten eine durchschnittliche Trefferquote von 99,1 % sowie eine durchschnittliche Cross-IOC-Mismatch-Rate von 0,8 %. In diesem Manuskript wird die Mismatch-Rate als Maß für die semantische Spezifität verwendet: Ein Mismatch tritt auf, wenn ein für ein IOC erzeugtes Regex ebenfalls mit einer Ground-Truth-String übereinstimmt, die mit einem anderen IOC verbunden ist. Diese Größe sollte nicht als End-to-End-operative Alarm-Falsch-Positiv-Rate interpretiert werden, die ebenfalls von der nachgelagerten Regellogik und dem Bereitstellungskontext abhängt.

Die Verteilung spiegelt die strukturelle Zusammensetzung des CTI-Korpus wider und ermöglicht es den Nutzern zu überprüfen, dass die extrahierten Indikatoren mit den erwarteten IOC-Typen übereinstimmen. Große Abweichungen von den erwarteten Proportionen können auf Upstream-Parsing oder Extraktionsprobleme hinweisen und sollten vor Beginn der Downstream-Normalisierung und Regex-Generierung untersucht werden.

Analyse der Regex-Optimierungsmaßnahmen

Abbildung 11 fasst die während der Generierung und Verfeinerung regulärer Ausdrucks durchgeführten Aktionen zusammen. Die Verteilung umfasst drei Arten von Aktionen: initiale Regex-Generierung, LLM-gesteuerte Optimierungsschritte und Retry-basierte Regeneration.

LLM-gesteuerte Optimierung macht 51,7 % aller beobachteten Aktionen aus. Diese Prävalenz zeigt, dass die anfängliche Generierung allein häufig nicht ausreicht, um Regexe zu erzeugen, die Capture-Group-Constraints und Ausschlussanforderungen erfüllen. Stattdessen wird iterative Optimierung aktiv und wiederholt angewendet, um Kandidaten-Regexes zu verfeinern.

Anstatt Ineffizienz widerzuspiegeln, zeigt diese Verteilung, dass der Optimierungs-Workflow ein notwendiger und integraler Bestandteil des Protokolls ist, wenn strukturell konforme Regexes aus komplexen IOC-Eingaben generiert werden.

Eine separate Skalierbarkeitscharakterisierung über eine zufällige Stichprobe von 6.000 IOCs, die mit dem Skalierbarkeitstest-LLM generiert wurde (siehe Materialtabelle), berichtete eine mediane Latenz von 2,95 s pro IOC und eine mittlere Latenz von 23,18 s. In derselben Charakterisierung erreichte die syntaxgültige Regex-Kompilierung 99,56 %, der Gesamterfolg der Generierung 99,4 %, die durchschnittliche geschätzte Tokennutzung lag bei etwa 3.986 Token pro IOC, und der Workflow erforderte durchschnittlich etwa 7,89 LLM-Aufrufe pro IOC. Die Erstdurchlauf-Erfolgsraten lagen bei 56,46 % für die Match-Debug-Schleife und 72,92 % für die Validierungsschleife ohne Capture-Gruppen. Diese Messungen helfen, die Rechenkosten und den Betriebsdurchsatz für den Batch-Einsatz zu charakterisieren.

Für die Modell-Neuschulung in der aktuellen Referenzcharakterisierung wurde keine Expertenbewertung einer ausgewählten Ausgabe-Teilmenge verwendet; Die berichteten Ergebnisse spiegeln die automatisierte Pipeline-Ausführung und die oben beschriebenen nachgelagerten Evaluationsdatensätze wider.

Operationelle Beweise und Fehlerhandhabung. Abbildung 12 zeigt die Struktur der exportierten SIEM-Regex-Datei, die vom Protokoll erzeugt wird, zusammen mit regelbasierten Validierungsnachweisen für repräsentative Dateipfad-, Registry-Key- und Befehlszeilenmuster. Abbildung 13 zeigt den entsprechenden vollständigen JSON-Bericht, der alle Stufenausgaben (extrahierte, analysierte und normalisierte IOCs zusammen mit den generierten Regex-Mustern und pro-IOC-Validierungsflags) offenlegt und das primäre Artefakt ist, das nachgelagerte Werkzeuge verbraucht. Abbildung 14 veranschaulicht den Umgang des Protokolls mit einer verrauschten CTI-Eingabe: Ein entzündeter, durch Weißraum gestörter Dateipfad wird in der Analysephase markiert, korrigiert, auf die kanonische %TEMP%-Vorlage normalisiert und dann in ein kompilierendes, passendes Regex umgewandelt. Dieses ausgearbeitete Beispiel ergänzt die operativen Beweise in Abbildung 12 und Abbildung 13 , indem es dokumentiert, wie sich das Protokoll verhält, wenn der rohe IOC-Text von der kanonischen Form abweicht.

Abbildung 1: Gesamtarchitektur des IOC-zu-Regex-Protokolls. Die Abbildung fasst die End-to-End-Pipeline zusammen. Kandidaten-IOC-Strings, die vom Upstream-IOC-Extraktor erzeugt werden, werden zerlegt und mit Referenzknoten in einem aus der Windows-Dokumentation befüllten Neo4j-Graphen verglichen (Schritt 1), der bekannte Pfad-, Registry- und Kommandozeilenkomponenten abruft (Schritt 2). Variable oder umgebungsspezifische Fragmente werden als Abwurf bezeichnet und aus der normalisierten Rekonstruktion ausgeschlossen, während sie in den Komponentenmetadaten erhalten bleiben, was zu einem normalisierten IOC mit Komponenten-Level-Keep- und Discard-Labels führt (Schritt 3). Diese normalisierten IOCs werden dann an eine LLM-basierte Regex-Generierungsstufe (Schritt 4) weitergegeben, die Kandidaten-reguläre Ausdrücke erzeugt, die bewertet und iterativ anhand von Capture-Group-Constraints und Discarded-Token-Regeln (Schritt 5) bewertet und iterativ optimiert werden, bevor ein finales Regex ausgewählt wird (Schritt 6). Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.

Abbildung 2: Phase 1 Dokument-Parsing-Ausgabe. Nebeneinander-Vergleich des ursprünglichen CTI-Berichts und der geparsten Dokumentvorschau. Das linke Panel zeigt den ursprünglichen CTI-Bericht im PDF-Format, während das rechte Panel die einheitliche Markdown-Darstellung des Parsers darstellt. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.

Abbildung 3: Konsensbasierte IOC-Extraktion mittels Multi-LLM-Ensemble-Abstimmung. Die Schnittstelle veranschaulicht den ensemblebasierten IOC-Extraktionsprozess und seine Zwischenergebnisse. Das rote Feld hebt die konfigurierten LLM-Instanzen hervor, die an der IOC-Extraktion teilnehmen, einschließlich der ausgewählten Anbieter und der Anzahl der wiederholten Extraktionsläufe für jedes Modell. Das blaue Feld zeigt die benutzerdefinierte Konsensschwelle an, die die Mindestanzahl der Vorkommnisse angibt, die für die Beibehaltung eines IOC erforderlich ist. Nach der Aggregation der Extraktionsergebnisse über alle Modelle und Wiederholungen hinweg werden Kandidaten-IOCs, die seltener als die Schwelle erscheinen, verworfen. Das orangefarbene Feld zeigt die endgültige Reihe der zurückgehaltenen IOCs, die das Konsenskriterium erfüllen und an nachgelagerte Analysephasen weitergeleitet werden. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.

Abbildung 4: IOCs, die durch Ensemble-Abstimmung in Phase 2 verworfen wurden. Seiten-an-Seite-Ansicht von IOC-Kandidaten, die die festgelegte Mindeststimmen-Schwelle während des Ensemble-Voting nicht erreicht haben und zur Analysteninspektion vorgelegt werden. Verworfene Kandidaten spiegeln typischerweise modellspezifische Halluzinationen oder mehrdeutige Textfragmente wider und werden nicht in den Kategorisierungsschritt Stufe 3 übergeben. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.

Abbildung 5: Beibehaltene IOC-Menge mit standardisierter Klassifikation. IOC-Kandidaten, die nach Phase 3 behalten wurden, werden zusammen mit ihren standardisierten Kategorien, Quelltags und originalen Extraktionsschlüsseln angezeigt, sofern verfügbar. Diese Tabelle liefert die strukturierte IOC-Eingabe, die von der Normalisierungsstufe verwendet wird. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.

Abbildung 6: Dateipfad-IOC-Normalisierung mittels graphunterstützter Analyse. Nebeneinander-Vergleich eines ursprünglichen Dateipfads IOC und seiner normalisierten Darstellung. Graphbasierte Traversal-Abfragen verwendet bekannte Pfadkomponenten nach normalisiertem Namen und bezeichnet jede Komponente als behalten oder verwerfen. Laufwerksidentifikatoren und variable Dateinamenfragmente können daher im Komponentendatensatz als verworfen markiert werden, während die normalisierte Form hauptsächlich aus gespeicherten strukturellen Segmenten rekonstruiert wird, die für die nachgelagerte Musterkonstruktion erforderlich sind. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.

Abbildung 7: IOC-Normalisierung des Registerschlüssels mittels graphunterstützter Analyse. Normalisierung eines Registerschlüssel-IOC durch graphunterstützte Auflösung hierarchischer Registerstrukturen. Abgekürzte Root-Schlüssel werden zu kanonischen Registry-Hives erweitert, und der Analyzer extrahiert die längste zusammenhängende bekannte Registrierungs-Substring, während er Host-Platzhalter, SID-ähnliche Werte und GUID-ähnliche Token überspringt. Die Ausgabedatensätze speichern/verwerfen Labels für jede erhaltene Komponente und erzeugen einen kanonischen Registerpfad für die nachgelagerte Verarbeitung. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.

Abbildung 8: Kommandozeilen-IOC-Normalisierung mittels graphunterstützter Analyse. Vergleich eines ursprünglichen Befehlszeilen-IOC und seiner normalisierten Darstellung. Das Protokoll tokenisiert die Kommandozeile, während es Anführungszeichenfolgen beibehält, normalisiert das führende Befehlstoken durch Neo4j-Abfrage und analysiert rekursiv eingebettete pfadähnliche oder registry-ähnliche Fragmente. Stabile, befehlsbezogene Komponenten werden als behalten bezeichnet, variable Argumente als verwerfen, und die endgültige kanonische Befehlsstruktur wird aus den gehaltenen Elementen rekonstruiert. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.

Abbildung 9: Einschränkungsbasierte Auswahl von Kandidaten für reguläre Ausdrücke. Mehrere Regex-Kandidaten werden für jedes normalisierte IOC mithilfe eines iterativen Validierungs-Workflows generiert. Ein von Einschränkungen gesteuerter Scoring-Mechanismus wird angewandt, um einen finalen Regex auszuwählen, der bestimmte Capture-Group-Komponenten bewahrt und unerwünschte Variablen-Substrings begrenzt. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.

Abbildung 10: Verteilung der extrahierten IOCs über CTI-Berichte. Zusammenfassung der IOC-Extraktionsergebnisse zeigt die Gesamtzahl der aus CTI-Berichten identifizierten Indikatoren und deren Verteilung über Dateipfade, Registrierungsschlüssel und Kommandozeilenindikatoren. Diese Ansicht bietet eine übergeordnete Validierung der CTI-Inhaltsabdeckung und des Extraktionsverhaltens. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.

Abbildung 11: Verteilung der Optimierungsaktionen während der Generierung regulärer Ausdrucks. Aufschlüsselung der während der Regex-Generierung durchgeführten Aktionen, einschließlich der Anfangsgenerierung, LLM-gesteuerter Optimierung und Retry-basierter Regeneration. LLM-gesteuerte Optimierung macht 51,7 % aller Aktionen aus, was zeigt, dass iterative Verfeinerung ein wesentlicher Bestandteil des Protokolls ist, um Regexes zu erstellen, die die Capture-Group-Constraints erfüllen. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.

Abbildung 12: Repräsentative exportierte Regex-Datei. Beispielinhalte des SIEM-Regex-Exports (siem_rules.txt), der vom Protokoll generiert wird. Jeder Eintrag enthält das Quell-IOC, die abgeleitete Kategorie (Dateipfad, Registrierungsschlüssel oder Befehlszeile) und das validierte Regex-Muster. Die beigefügte Validierungstabelle fasst das erwartete Verhalten und die Systembelege zusammen, die zur Bestätigung der Korrektheit für jeden Regeltyp verwendet wurden. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.

Abbildung 13: Vertreter des vollständigen JSON-Berichts. End-to-End-Pipeline-Ausgabe wird nach Ausführung aller fünf Protokollstufen in einem repräsentativen CTI-Bericht erzeugt. Das JSON-Dokument erfasst die Quelldatei, die Anzahl der geparsten Abschnitte, extrahierte IOCs nach Kategorie gruppiert, kategorisierte Datensätze der Stufe 3 mit Quelltags, Normalisierungsdifferenz der Stufe 4 und Regex-Muster der Stufe 5 mit Validierungsflaggen pro IOC. Der Bericht legt außerdem Top-Level-Metadaten für Erfolge und Fehler offen, die es downstream-Tools ermöglichen, teilweise Fehler zu erkennen. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.

Abbildung 14: Fehlgeschlagene oder verrauschte Eingabe: Identifikation und Korrektur. Ein ausgearbeitetes Beispiel dafür, wie das Protokoll einen lauten IOC identifiziert und sich davon erholt. Die rohe Eingabe %T E M P%\malware[.]EXE wird markiert, weil sein Umgebungsvariablen-Token eingefügte Leerzeichen enthält und die Dateiendung entwaffnet wurde. Der Korrekturschritt entfernt den eingefügten Weißraum und stellt den wörtlichen Punkt wieder her; Die Normalisierung von Stufe 4 erweitert dann %TEMP% auf die kanonische Windows-Temp-Verzeichnisvorlage; und Stufe 5 erzeugt ein Regex, das das korrigierte normalisierte IOC kompiliert und abgleicht. Dieses Beispiel veranschaulicht die in der Diskussion diskutierte Rausch-Eingabe-Handhabung. Bitte klicken Sie hier, um eine größere Version dieser Abbildung anzusehen.

Element	Typ	Wert / Schema	Beispiel	Anmerkungen
Knotenetikett	Label	:P ath	Windows, System32, cmd.exe	Speichert Windows-Dateipfadkomponenten
Knotenetikett	Label	:Registry	SOFTWARE, Microsoft, Windows NT	Speichert Registerschlüsselkomponenten unter Wurzelbienenstöcken
Knotenetikett	Label	:CLI	powershell.exe, -ExecutionPolicy, Bypass	Speichert Befehlstoken und Parameter
Knoteneigenschaft	Saite	Name	cmd.exe	Originalgehäuse; Verwendet für die Anzeige in normalisierter Ausgabe
Knoteneigenschaft	Saite	name_lower	cmd.exe	Kleinbuchstabenform; verwendet als Suchschlüssel für alle MATCH-Abfragen
Beziehung	Gerichtete Kante	(a)-[:NEXT]->(b)	(Windows)-[:NEXT]->(System32)	Beide Endpunkte teilen dasselbe Label; encodiert native Adjacency auf Windows-Systemen
Einschränkung	Einzigartigkeit	n.name_lower EINZIGARTIG pro Etikett	-	Beantragt auf :P ath, :Registry, :CLI
Datenquelle	Abdeckung	Windows 8, 10, 11	-	Client-Betriebssystem in den Graphen eingefügt
Datenquelle	Abdeckung	Windows Server 2012, 2016, 2019, 2022	-	Server-Betriebssystem in den Graphen eingefügt

Tabelle 1: Neo4j-Graphschema verwendet für die IOC-Normalisierung (Stufe 4). Listet die drei Knotenlabels (Pfad, Registry, CLI), ihr gemeinsames Eigenschaftsschema (Name, name_lower), die für native Reihenreihen verwendete Directed Adjacency Relationship, Uniqueness-Constraints sowie die Windows-Client- und Serverversionen, die den Graphen befüllen, auf.

Bühne	Erwartete Leistung	Automatisierte Validierung	Analystenorientierte Qualitätskontrolle
Stufe 1: Dokumentenparsing	Vereinheitlichter Markdown-Text, mit 4.000 Zeichen vor der LLM-Verarbeitung.	—	Eine visuelle Überprüfung der Markdown-Vorschau, um sicherzustellen, dass Dateipfade, Registrierungsschlüssel, Kommandozeilenfragmente und Abschnittsgrenzen das Parsen überstanden haben; Wechsle das Backend, wenn technische Strings abgeschnitten werden.
Phase 2: IOC-Extraktion	JSON mit drei obersten Schlüsseln (Dateipfade, Kommandozeilen, Registrierungsschlüssel); Stimmenzählungen pro IOC und Metadaten des beitragenden Modells, wenn das Ensemble-Voting aktiviert ist.	Der Konsensschwellenfilter (min_votes) schließt IOCs aus, deren Stimmenanzahl unter der konfigurierten Schwelle liegt.	Inspektion ausgeschlossener Kandidaten, um Halluzinationen von übermäßig strengem Wählen zu unterscheiden, bevor min_votes angepasst wird.
Stufe 3: IOC-Analyse und Klassifikation	Kategorisierte IOC-Liste: Jedes IOC wird mit einer standardisierten Kategorie, einem Quell-Tag und einem ursprünglichen Extraktionsschlüssel kombiniert, sofern verfügbar.	Standardisierte Kategorie-Mapping mittels Regex-basierten Regeln und IOC-Musterheuristiken; (IOC, Kategorie) Paar-Deduplizierung.	Stichprobe des kategorisierten Outputs auf mehrdeutige oder verrauschte Kandidaten (Abbildung 4A).
Stadium 4: Neo4j-assistierte Normalisierung	Normalisiertes Formular per IOC mit Labels, die auf Komponentenebene behalten und wegwerfen werden.	Cypher-Abfragen (i)-(iii) über den Windows-Referenzgraphen; deterministischer Preprocessing-Fallback, wenn Neo4j nicht verfügbar ist.	Inspektion von all-weggeworfenen Hüllen zur Identifizierung von Lücken in der Graphabdeckung; Erweiterung der Graphdaten mit hersteller- oder umgebungsspezifischen Referenzen bei Bedarf.
Stufe 5: Regex-Generierung und Wertung	Endgültiges Regex pro IOC mit Kandidatenwerten, Optimierungshistorie, Iterationszählungen und Telemetrie pro IOC.	Übereinstimmungstest, statische Qualitätsprüfungen, grenzenbewusste verbotene Token-Prüfung, Übergeneralisierungstest gegen 5 deterministische negative Stichproben; Rückzug zum punktreichsten Teilmatch (used_fallback Flagge).	Optimierungs-Historie-Review für Rückfall-Regexes; pro IOC diagnostische Inspektion der Fehlerposition vor der Regeneration.

Tabelle 2: Phasenausgabe und Validierungszusammenfassung. Jede Protokollstufe (1–5) wird dem erwarteten Artefakt, den automatisierten Validierungsbeweisen der Pipeline zugeordnet (Regex-Kompilierungsstatus, Trefferrate, Cross-IOC-Mismatchrate, Optimierungiterationszählungen) und der entsprechenden analystenbezogenen Qualitätskontrollprüfung (visueller Vergleich, Inspektion verworfener Kandidaten und Kategorienüberprüfung).

Zusatzakte 1: Wortwörtliche LLM-Eingabeaufforderungen. Das wortwörtliche System und menschliche Eingabeaufforderungen, die für die IOC-Extraktion der Stufe 2 und die Generierung und Optimierung des Regex in Stufe 5 verwendet werden. Bitte klicken Sie hier, um diese Datei herunterzuladen.

Ergänzende Akte 2: Umsetzungsdetails für die Stufen 4 und 5. Algorithmische und Implementierungsdetails unterstützen die graphunterstützte IOC-Normalisierung der Stufe 4 sowie die Validierung, Bewertung und Iterationskontrolle der Stufe 5 für Regex. Bitte klicken Sie hier, um diese Datei herunterzuladen.

Diskussion

Die Übersetzung unstrukturierter CTI-Berichte in ausführbare Erkennungslogik bleibt eine zeitaufwändige und fehleranfällige Aufgabe in operativen Sicherheitsworkflows. Während frühere Bestrebungen Automatisierung auf der Ebene der IOC-Extraktion oder der hochrangigen Regelgenerierung erforscht haben, stehen Praktiker weiterhin vor erheblichen Herausforderungen bei der Umwandlung extrahierter IOC-Strings in Regexes, die strukturell korrekt, semantisch präzise und für nachgelagerte SIEM-Anwendungen geeignet sind. Das hier vorgestellte Protokoll adressiert diese Lücke durch einen gestuften Workflow, bei dem jede Phase ein klar definiertes Zwischenartefakt erzeugt und explizite Validierung anwendet, bevor die Ergebnisse an die nächste Stufe weitergegeben werden. Abbildung 14 dokumentiert einen solchen Fall, in dem ein entwaffneter, durch Weißraum gestörter Dateipfad identifiziert, korrigiert, normalisiert und in ein Kompilierungsregex umgewandelt wird; Die Behandlung von rauschen Eingaben und sein aktueller Umfang des Protokolls werden gemeinsam mit den unten aufgeführten Einschränkungen besprochen.

Ein zentraler Beitrag dieses Protokolls ist die explizite Zerlegung des Arbeitsablaufs in Stufen mit inspizierbaren Zwischenausgaben. Die Implementierung wird nun konkret beschrieben: Das Dokumentparsing erzeugt Markdown- und Chunk-Text für die LLM-Verarbeitung; IOC-Extraktion liefert strukturiertes JSON für Dateipfade, Registrierungsschlüssel und Kommandozeilenindikatoren; regelbasierte IOC-Analyse standardisiert und dedupliziert extrahierte Werte; Die neo4j-unterstützte Normalisierung bezeichnet jede IOC-Komponente als behalten oder verwerfen; und die Regex-Generierung führt Match-Debugging, Discard-Validierung und Übergeneralisierungsprüfungen vor der Kandidatenauswahl an.

Das Protokoll behandelt die Generierung regulärer Ausdruck als iterative Konstruktionsaufgabe und nicht als einmalige Vorhersageaufgabe. Die Implementierung verwendet einen Prompt für die Anfangsgenerierung, automatisierte Match-Diagnosen, gekappte Verfeinerungsschleifen und eine komponentenbasierte Bewertungsfunktion, um strukturell wichtige IOC-Elemente zu erhalten und verworfene oder nicht abgebildete Teilstrings zu bestrafen. Dieses iterative Design, zusammen mit deterministischen Validatoren, die in jedem Schritt angewendet werden, unterstützt die Erstellung von Regex-Mustern, die strukturell treu über ein großes und heterogenes Bewertungsset hinweg bleiben. In der Referenzbewertung wurde dieser Workflow auf 3.156 CTI-Berichte angewendet und mit mehr als 2.400 unabhängigen Ground-Truth-Strings bewertet, was eine durchschnittliche Trefferquote von 99,1 % und eine durchschnittliche Cross-IOC-Mismatchrate von 0,8 % ergibt. Da diese Ground-Truth-Strings von Experten kuratierte Artefakte sind, die von Cybersicherheitsanbietern während der MITRE ATT&CK-Evaluationsübungen gemeldet wurden, vergleicht diese Bewertung implizit die Ergebnisse des Protokolls mit IOC-Mustern, die von menschlichen Analysten dokumentiert wurden, anstatt mit automatisch generierten.

Wie in den repräsentativen Ergebnissen gezeigt, ist iterative Optimierung besonders wichtig, wenn der Workflow komplexe IOC-Strukturen wie verschachtelte Dateipfade oder lange Kommandozeilen-Strings verarbeitet. Referenzbewertungsergebnisse zeigen außerdem, dass die häufigsten unmatched Fälle auftreten, wenn Angreifer benutzerdefinierte ausführbare Dateien oder Parameter verwenden, die in der Graphdatenbank nicht dargestellt oder nicht explizit in den Quell-CTI-Berichten dokumentiert sind. Im operativen Einsatz sollten diese Ausfallarten als erwartete Randbedingungen und nicht als stille Fehler behandelt werden und sollten eine Überprüfung der Graphabdeckung, der Vollständigkeit von Quellberichten und der Regex-Debug-Telemetrie auslösen.

Das Protokoll kann mit drei Familien alternativer Methoden verglichen werden. Zunächst lernen beispielbasierte Regex-Synthesemethoden wie TransRegex¹¹ und Regex+¹² Regexe aus kuratierten Mengen positiver und negativer String-Beispiele. Diese Methoden funktionieren gut, wenn repräsentative Beispielsets verfügbar sind, sind aber weniger direkt auf SOC-Kontexte anwendbar, wo jeder in CTI gemeldete IOC typischerweise nur als eine einzelne repräsentative Zeichenkette erscheint und die erforderliche Verallgemeinerungsgrenze durch operative Semantik statt durch Beispielabdeckung bestimmt wird. Zweitens durchsuchen genetische Programmierungsansätze, wie sie von Bartoli et ^al.13,14 eingeführt wurden, den Raum der Regexes durch evolutionäre Operatoren und erfordern typischerweise einen markierten Korpus aus Match- und Nicht-Match-Strings; sie eignen sich gut für den Batch-Aufbau von Extraktionsmustern, konsumieren aber nicht direkt unstrukturierte CTI-Erzählungen. Drittens übersetzen neuere neuronale und LLM-basierte Ansätze ^15,16 natürliche Sprachbeschreibungen direkt in Regex-Strings; diese Methoden sind für gut spezifizierte Prompts leistungsfähig, können aber bei Einzelaufnahmen Regexes erzeugen, die syntaktisch gültig sind, aber erforderliche Capture-Group-Komponenten übersehen oder sich über nicht verwandte IOC-Varianten hinweg überallgemeinern. Das vorliegende Protokoll ergänzt diese Richtungen, indem es (i) unstrukturierte CTI-Berichte anstelle von kuratierten Beispielsätzen oder natürlichsprachigen Abfragen als Eingabe nimmt, (ii) jedes IOC per graphunterstützter Normalisierung in Behalte- und Verwerfkomponenten zerlegt, bevor ein Regex generiert wird, und (iii) jeden Kandidaten-Regex mit deterministischen Übereinstimmungs-, Verwurfs- und Übergeneralisierungsprüfungen innerhalb einer begrenzten iterativen Schleife validiert. Das Ziel ist es nicht, frühere Methoden bei ihren eigenen Benchmarks zu übertreffen, sondern eine reproduzierbare IOC-zu-Regex-Pipeline bereitzustellen, deren Zwischenentscheidungen von SOC-Analysten inspizierbar und prüfbar sind.

Das Protokoll trifft mehrere Annahmen über die Qualität der Eingabe-CTI-Berichte. Es geht davon aus, dass (i) IOC-Zeichenketten nach Dokumentparsing in einer wiederherstellbaren Textform erscheinen, d. h. Dateipfade, Registrierungsschlüssel und Kommandozeilenindikatoren sind nicht ausschließlich in Bildern, Screenshots oder verschleierten Codierungen eingebettet; (ii) IOC-Fragmente, die im CTI gemeldet werden, ausreichend vollständig sind, um ihre strukturellen Anker zu erhalten (zum Beispiel behalten Registrierschlüssel ihr Hive-Präfix, Dateipfade behalten mindestens einen Verzeichnisanker, der für den Windows-Dokumentationsgraphen erkennbar ist, und Kommandozeilen behalten die aufrufende ausführbare Datei oder eine bekannte Modulreferenz); und (iii) die gemeldeten IOCs werden nicht abgeschnitten, geschwärzt oder so umgeschrieben, dass die Capture-Group-Komponenten, auf denen das Protokoll basiert, entfernt werden. CTI-Berichte, die diese Annahmen erfüllen, umfassen die meisten MITRE ATT&CK-Technikbeschreibungen, Lieferantenhinweise, Incident-Response-Berichte und gut formatierte Bedrohungsbulletins. Berichte, die hauptsächlich auf Screenshots basieren, stark gekürzte IOC-Listen ohne Kontext oder Freitext-Paraphrasen ohne explizite IOC-Strings liegen außerhalb des beabsichtigten Betriebsbereichs und sollten mit reduziertem Extraktionsabruf und weniger treuer Normalisierung rechnen; Solche Berichte können von einer vorgelagerten Bild-zu-Text-Vorbearbeitung oder einer Analystenprüfung vor dem Eintritt in die Pipeline profitieren.

Bei der Anwendung dieses Protokolls sollten mehrere Einschränkungen berücksichtigt werden. Erstens konzentriert sich die aktuelle Implementierung auf Dateipfade, Registerschlüssel und Kommandozeilenindikatoren statt auf breitere IOC-Kategorien wie Domains, E-Mail-Artefakte, User-Agent-Strings oder Verhaltenssequenzen. Dies ist eine bewusste Wahl des Umfangs, da atomare Indikatoren im Allgemeinen gut durch exakte-Match-Workflows bedient werden und das vorliegende Protokoll variable-strukturelle IOCs anspricht, die von der Regex-Generalisierung profitieren; sie beschränkt jedoch die Anwendbarkeit auf IOC-Typen, die derzeit nicht im Graphen dargestellt sind. Zweitens fallen aktuelle Ausfallszenarien in drei Hauptkategorien: nicht-native Pfade oder Kommandozeilenargumente, die im Betriebssystemgraphen fehlen, unvollständige Graphabdeckung für relevante Dienstprogramme oder Strukturen sowie Unvollständigkeit der CTI-Quelle selbst, wenn wichtige Befehlsfragmente oder Cmdlets nie gemeldet werden. Drittens misst die Cross-IOC-Mismatch-Metrik, die in der Referenzbewertung verwendet wird, die semantische Spezifität erzeugter Regexes anstelle von End-to-End-Alarm-Fehlalarmen unter der eingesetzten SIEM-Logik.

Reproduzierbarkeit unter LLM-Variabilität und Versionierung. Da die IOC-Extraktions- und Regex-Generierungsphasen von kommerziellen LLM-Endpunkten abhängen, beeinflussen zwei Quellen der Variabilität die Reproduzierbarkeit: Anbieter-seitige Modellupdates im Zeitverlauf und Stochastizität der Pro-Call-Stichproben. Um das erste zu vermeiden, speichern alle LLM-bezogenen Felder in der Materialtabelle exakte Modellkennungen und das in der Referenzauswertung verwendete Zugriffsdatum, und das Protokoll empfiehlt, jedes Mal ein bestimmtes Modell-Snapshot zu pinnen, wenn der Anbieter eines offenstellt. Um die zweite zu mildern, fixiert die Referenzimplementierung die IOC-Extraktionstemperatur auf 0,0 und verwendet eine von null verschiedene Temperatur nur in der Regex-Generierungsphase, wo Ensemble-Voting und deterministische Validatoren in den Stufen 2 und 5 Restvariationen absorbieren. Bei der Replikation dieser Ergebnisse sollten Benutzer die genaue Modellversion, das Zugriffsdatum, die Temperatur und den verwendeten Ensemble-Vote-Schwellenwert notieren; Substanzielle Abweichungen auf einer dieser Achsen sollten erwartet werden, die Trefferrate und Mismatch-Metriken verschieben.

Mehrere wiederherstellbare Fehlerarten können auf der Ebene der Stufe, die sie verursacht hat, behoben werden. Phase-1-Parsingfehler (zum Beispiel gescannte PDFs, die leere oder verzerrte Markdown erzeugen): Vorverarbeitung der Eingabe mit optischer Zeichenerkennung oder einem externen Konverter vor dem erneuten Hochladen; Überprüfen Sie, dass die Anzahl der geparsten Abschnitte und die Gesamtzahl der Zeichen nicht null sind, bevor Sie fortfahren. Phase-2-Extraktionsfehler (keine IOCs zurückgegeben oder halluzinierte Einträge): Erhöhung der Ensemble-Stimmen-Schwelle (Min Votes ≥ 2), Aktivieren zusätzlicher Modellinstanzen oder Senkung der LLM-Temperatur; die API-Konnektivität zu überprüfen und dass das konfigurierte Modell JSON-formatierte Ausgaben akzeptiert. Stufe 4 Normalisierung mit all-Discard-Labels (jede IOC-Komponente ist als Discard bezeichnet): Erweiterung des Neo4j-Referenzgraphen mit hersteller- oder umgebungsspezifischen Pfadkomponenten und Registerwurzeln; die Cypher-Importskripte und die Entscheidungsregel für Behalten/Abwerfen sind in Supplementary File 2 aufgeführt. Phase-5-Regex-Fehler (used_fallback = wahr oder wiederholte Ablehnungen der Discard-Validierung): Inspizieren Sie das per-IOC-Optimierungs-Historie-Feld, um den fehlerhaften Validator zu identifizieren; wenn das IOC tatsächlich keine stabilen Keep-Komponenten hat, sollten Sie eine manuelle Regex-Erstellung für dieses IOC in Betracht ziehen oder es von der automatisierten Regelgenerierung ausschließen, während es in der kategorisierten IOC-Tabelle für die Analystenüberprüfung beibehalten wird.

Im Einklang mit den oben genannten Einschränkungen werden die generierten Regexes am besten als wiederverwendbare Suchprimitive innerhalb des umfassenderen SOC-Detektionsinhalts behandelt und nicht als selbstversorgende Detektoren. In operativen Umgebungen können Analysten sie mit plattformspezifischer Feldlogik, Whitelisten, Herkunftsprüfungen oder Korrelationsbedingungen kombinieren, um harmlose Übereinstimmungen zu unterdrücken, die aus ungewöhnlichen, aber nicht bösartigen Pfaden entstehen.

Zukünftige Arbeiten könnten einen systematischen Vergleich mit von Menschen verfassten Regexes, eine umfassendere Bewertung über zusätzliche IOC-Kategorien, strukturierte Analysten-Feedback-Studien, erweiterte Graphenabdeckung für von Angreifern erstellte Dienstprogramme und Cmdlets sowie umfassendere Berichte über End-to-End-Latenz und Kosten in allen Bereitstellungssettings umfassen. Dennoch bietet das vorliegende Protokoll einen reproduzierbaren und operativ interpretierbaren Rahmen für die IOC-zu-Regex-Übersetzung, der sowohl seine Stärken als auch seine aktuellen Grenzen dokumentiert.

Materialien

Liste der in diesem Artikel verwendeten Materialien

Name	Unternehmen	Katalognummer	Kommentare
Computer (CPU)	—	≥ 4 Kerne empfohlen	Keine GPU erforderlich
LangChain	LangChain	≥ 0.1.x	Orchestrierungs-Framework für LLM
LLM (IOC-Extraktion, Einzelmodell)	OpenAI	gpt-5.1	Wird für die IOC-Extraktion (Stufe 2) verwendet, wenn Ensemble-Voting deaktiviert ist. Temperatur = 0,0; max_workers = 5. Zugriff am: 15.12.2025.
LLM (Regex-Generierung)	OpenAI	gpt-5.1	Wird für die Regex-Generierung (Stufe 5) verwendet. Temperatur = 0,3 vor der nachgelagerten Validierung. Zugriff am: 15.12.2025.
LLM (Skalierbarkeitscharakterisierung)	OpenAI	gpt-5.1	Wird für den 6.000-IOC-Skalierbarkeitslauf verwendet, der in den repräsentativen Ergebnissen berichtet wurde. Zugriff am: 15.12.2025.
Arbeitsspeicher (RAM)	—	≥ 16 GB empfohlen	Erforderlich für die Dokumentenverarbeitung
Neo4j	Neo4j, Inc.	≥ 5.x	Graphdatenbank für IOC-Normalisierung
Neo4j Python Driver	Neo4j, Inc.	≥ 5.x	Python-Schnittstelle zu Neo4j
Betriebssystem	Microsoft / Apple / Linux	Windows, macOS oder Linux	Plattformübergreifende Unterstützung
PDF-Parsing — primäres Backend	Microsoft	MarkItDown ≥ 0.0.x	Backend der Stufe 1; konvertiert PDF/DOCX/HTML/TXT-Eingaben in Markdown. Geparsete Ausgabe wird vor der LLM-Verarbeitung in Chunks zu je 4.000 Zeichen unterteilt. Zugriff am: 15.12.2025. https://github.com/microsoft/markitdown
Pipeline-Konfiguration (Stufe 2 — IOC-Extraktion)	—	Referenzvorgaben	Einzel-LLM-Modus: Temperatur = 0,0, max_workers = 5. Standardeinstellungen für Ensemble-Voting-Modus: Wiederholungen = 1 pro konfiguriertes Modell, min_votes = 2.
Pipeline-Konfiguration (Stufe 5 — Regex-Generierung)	—	Referenzvorgaben	Generierungstemperatur = 0,3. Validierung: overgen_random_tests = 5 deterministische negative Proben pro IOC. Iterationsgrenzen: max_iterations = 10, debug_loop_cap = 5, discard_validation_cap = 5.
Python	Python Software Foundation	≥ 3.8	Erforderliche Laufzeitumgebung
Regex-Engine	Python Standard Library	re-Modul	Wird für die Regex-Validierung und -Tests verwendet
Streamlit	Streamlit Inc.	≥ 1.25	Webbasierte Benutzeroberfläche
Quellcode der Referenzimplementierung	Autoren / GitHub | GitHub-Repository		Quellcode für die Streamlit-Benutzeroberfläche, LangChain-Pipeline, Neo4j-gestützte Normalisierung, Regex-Generierung, Validierungs-Dienstprogramme und Beispielkonfigurationsdateien. Verfügbar unter https://github.com/SOCautomatic/cti-ioc-regex-pipeline. Zugriff am: 11.06.2026.