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...

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-An...

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.