Een gestructureerde workflow voor het omzetten van cyberdreigingsinformatie in berekenbare detectiepatronen

Samenvatting

Hier presenteren we een protocol om indicatoren van compromittering uit cyberdreigingsintelligentierapporten, bestandspaden, registersleutels en commandoregelindicatoren om te zetten in gevalideerde reguliere expressies voor beveiligingsinformatie- en gebeurtenisbeheerregels (SIEM), met behulp van ensemble-extractie met grote taalmodellen (LLM's) en grafiekondersteunde componentlabeling.

Samenvatting

Security Operations Centers (SOC's) zetten routinematig cyberdreigingsintelligentie (CTI)-rapporten om in operationele detectie-inhoud. Een persistent knelpunt in deze workflow is de vertaling van geëxtraheerde indicatoren van compromittering (IOC's), met name bestandspaden, registersleutels en commandoregelstrings, naar deployable regular expressions (regexes) die geschikt zijn voor het inbedden in security information and event management (SIEM) correlatieregels. Hoewel eerder werk de geautomatiseerde indicator-of-compromise (IOC) extractie heeft verbeterd, blijft het omzetten van geëxtraheerde strings in gevalideerde regex-patronen grotendeels handmatig, vereist gespecialiseerde expertise en is foutgevoelig. Het doel van dit protocol is het bieden van een gestandaardiseerde, reproduceerbare procedure voor IOC-naar-regex vertaling. De workflow bestaat uit vijf fasen: (1) het parsen van heterogene CTI-rapporten tot een uniforme Markdown-representatie; (2) IOC-extractie met behulp van meerdere grote taalmodellen (LLM's) met consensusstemming; (3) regelgebaseerde normalisatie, categorisatie en deduplicatie van geëxtraheerde IOC's; (4) graf-ondersteunde labeling van IOC-componenten als keep (capture-groep) of discard (niet-capture-groep); en (5) iteratieve regex-generatie met diagnostische validatie tegen de originele IOC-strings. Om de bruikbaarheid te beoordelen werd de workflow toegepast op 3.156 CTI-rapporten, en de resulterende regexes werden geëvalueerd aan meer dan 2.400 onafhankelijk verzamelde ground-truth-strings uit tien MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK) Evaluation-scenario's, wat resulteerde in een gemiddeld trefferspercentage van 99,1% en een gemiddeld cross-IOC mismatch percentage van 0,8%. Het protocol documenteert daarom een reproduceerbare implementatie voor IOC-naar-regex vertaling en geeft expliciet de huidige scope, operationele aannames en bekende faalgevallen uiteen.

Inleiding

Cybercriminaliteit blijft aanzienlijke operationele en financiële lasten leggen voor organisaties in zowel de publieke als private sector. In 2023 bedroegen gerapporteerde verliezen door cybercriminaliteit in de Verenigde Staten meer dan $12,5 miljard^{per jaar}, wat de omvang en persistentie van kwaadaardige activiteiten benadrukt. Binnen dit landschap dienen Security Operations Centers (SOC's) als de primaire operationele eenheden die verantwoordelijk zijn voor het detecteren, analyseren en reageren op dreigingen in realtime.
Detectielogica in veel SOC-workflows wordt geïmplementeerd via regelgebaseerde mechanismen binnen Security Information and Event Management (SIEM)-platforms, die veel worden gebruikt omdat ze interpreteerbaar, deterministisch en compatibel zijn met bestaande SOC-workflows. Van de verschillende regeltypes zijn correlatiegebaseerde SIEM-regels vooral belangrijk om aanvalsgedrag te identificeren dat meerdere gebeurtenissen, hosts en tijdsvensters overslaat. Binnen deze regels functioneren reguliere expressies (regexes) als een herbruikbare zoekprimitief: analisten integreren ze in bredere detectieregels die veldbeperkingen, platformspecifieke filters en gebeurteniscorrelatielogica toevoegen, in plaats van ze als zelfstandige detectoren in te zetten.

In de praktijk beginnen SOC-analisten vaak met het ontwikkelen van regels met indicatoren van compromis (IOC's) die zijn afgeleid van cyberdreigingsintelligentie (CTI)-rapporten die zijn gepubliceerd door beveiligingsleveranciers, onafhankelijke onderzoekers of publieke kennisbanken zoals MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK)². Deze IOC-strings kunnen bestandspaden, fragmenten van de commandoregel, registersleutels of andere gestructureerde artefacten bevatten die tijdens aanvallen^worden waargenomen. Het vertalen van dergelijke strings naar regex-patronen die geschikt zijn voor SIEM-correlatieregels is een terugkerende taak in de regel-authoring workflow.

Deze vertaalstap is een praktische operationele bottleneck. Het schrijven van regex-patronen die algemeen genoeg zijn om betekenisvolle variatie vast te leggen, maar nauwkeurig genoeg om onbedoelde matches te vermijden, vereist gespecialiseerde expertise; Kleine syntactische fouten of verkeerde beslissingen over welke componenten behouden of generaliseren kunnen een anders nuttige detectieregel ineffectief maken. Omdat dit werk handmatig, repetitief en detailgericht is, kan het de detectie-implementatie voor opkomende dreigingen vertragen, beoordeling door meer ervaren analisten vereisen en bijdragen aan de werklast van analisten in operationele ^{SOC-instellingen 4,5}.

De centrale uitdaging bij IOC-naar-regex vertaling is bepalen welke delen van een IOC stabiel, aanvaller-relevant gedrag coderen en daarom behouden moeten blijven, en welke delen omgevings- of host-specifieke variatie weerspiegelen en gegeneraliseerd moeten worden. Bijvoorbeeld, canonieke registerwortels zoals HKEY_CLASSES_ROOT\CLSID, systeemmappen zoals System32 en bekende uitvoerbare namen zoals rundll32.exe moeten doorgaans expliciet blijven, terwijl gebruikersprofielpaden, host-specifieke Security Identifiers (SID's) en Globally Unique Identifiers (GUIDs) normaal gesproken geabstraheerd moeten worden. Dit consequent doen over heterogene IOC-typen heen maakt de vertaaltaak niet triviaal. In dit protocol verwijzen we naar de eerste als behouden of capture-groepcomponenten, en de laatste als abstracte of niet-capture-groepcomponenten.

Eerder werk heeft geautomatiseerde extractie van dreigingsinformatie uit ongestructureerde tekst onderzocht met behulp van natuurlijke taalverwerking en entiteitsextractietechnieken ^6,7. Meer recentelijk hebben verschillende studies directe generatie van detectieregels uit CTI-rapporten onderzocht met behulp van grote taalmodellen (LLM's)⁸. Deze benaderingen tonen aan dat delen van de regel-authoring workflow kunnen worden ondersteund door taalmodellen, maar ze richten zich doorgaans niet op het specifieke operationele probleem van het genereren van regex-patronen die de capture-group semantiek behouden en geschikt blijven voor downstream SIEM-implementatie. Aanvullende werklijnen hebben CTI-inhoud gestructureerd voor downstream gebruik op verschillende manieren, waaronder kennisgrafgebaseerde representaties zoals TINKER⁹ en CTI-gedreven generatie van log-hunting queries zoals ThreatRaptor¹⁰, die ongestructureerde CTI omzetten in gestructureerde kennis- of domeinspecifieke querytalen in plaats van in regex-patronen die bedoeld zijn voor inbedding in SIEM-correlatieregels.

Parallel hebben eerdere studies geautomatiseerde regex-synthese onderzocht met behulp van voorbeeldgebaseerde methoden, neurale translatie en generate-and-repair-benaderingen 11,12,13,14,15,16. Deze methoden zijn echter meestal ontworpen voor omgevingen die vertrouwen op grote sets representatieve voorbeelden of natuurtaalbeschrijvingen in plaats van IOC-gedreven detectiecontexten. In SOC-workflows zijn IOC-strings vaak schaars, structureel heterogeen en nauw verbonden met operationele semantiek. Deze mismatch motiveert een workflow die is afgestemd op IOC-naar-regex vertaling, in plaats van te beweren dat bestaande regex-generatiemethoden over het algemeen onvoldoende zijn.

Het hier gepresenteerde protocol richt zich specifiek op de IOC-naar-regex vertaalfase van de SOC-detectieworkflow. IOC-extractie wordt behandeld als een upstream input die kan voortkomen uit handmatige analyse, geautomatiseerde tools, of een combinatie van beide; het protocol probeert geen volledige SIEM-regels te genereren. In plaats daarvan biedt het een systematische procedure om IOC-strings om te zetten in regex-patronen die syntactisch valide, semantisch interpreteerbaar en geschikt zijn voor operationele inzet. De huidige IOC-scope is bedachtzaam: bestandspaden, registersleutels en commandoregelindicatoren bevatten zowel stabiele als variabele structurele componenten die profiteren van regex-generalisatie, terwijl atomaire indicatoren zoals IP-adressen, domeinen en hashes natuurlijker worden geoperationaliseerd via exact-match voorwaarden of reputatie-achtige opzoekingen en daarom buiten de primaire scope vallen. Binnen deze grenzen is het protocol bedoeld om draagbaar te zijn over SOC-omgevingen die vergelijkbare invoerformaten en toolvoorwaarden delen.

Protocol

Gebruik de volgende vijffasige workflow om een CTI-rapport om te zetten in gevalideerde regex-patronen met traceerbare tussentijdse output (zie Figuur 1 voor een overzicht).

1. Systeemopstelling

1. Installeer de vereisten.
   1. Installeer Python 3.8 of later, alle Python-afhankelijkheden staan in requirements.txt, en een Neo4j-grafendatabase.
      1. Bevestig de toegang tot één of meer application programming interfaces (API's) voor de gekozen grote taalmodellen en controleer dat de Neo4j-service draait en bereikbaar is vanaf de lokale machine.
   2. Bevestig dat de Materiaaltabel compleet is.
      1. Controleer dat runtime-afhankelijkheden zijn vermeld, waaronder de Python-interpreterversie, de pipeline-afhankelijkheden, de Neo4j-versie en de Portable Document Format (PDF) tekstextractie-backend.
      2. Controleer dat LLM-configuratieopties zijn vermeld, inclusief de LLM-providers, modelnamen en -versies, temperatuur, redeneer-inspanningsopties en ensemble-steminstellingen.
      3. Controleer of invoer- en uitvoerformaten worden vermeld, inclusief de ondersteunde invoerbestandsformaten en de ondersteunde exportformaten.
2. Start de webgebruikersinterface (UI).
   1. Open een terminal, navigeer naar de referentie-implementatie rootmap en start de applicatie met het gedocumenteerde launch-commando (in de referentie-implementatie: cd langchain_pipeline gevolgd door streamlit run app_v2.py).
   2. Controleer of de applicatie op http://localhost:8501 laadt en dat het configuratiepaneel in de zijbalk zichtbaar is.
3. Configureer de LLM-provider.
   1. Selecteer in de LLM-configuratiesectie van de zijbalk een LLM-provider, voer de modelnaam in en geef een geldige application programming interface (API) sleutel.
   2. Noteer de leverancier, modelnaam, modelversie, temperatuur, redeneringsmogelijkheden en de datum van toegang voor de Materiaaltabel.
      OPMERKING. In de referentie-implementatie wordt de single-LLM IOC-extractie standaard gebruikt de primaire commerciële LLM die in de Materials Table staat met temperatuur = 0,0; Regex-generatie is standaard temperatuur = 0,3.
4. Schakel ensemble-stemmen in (optioneel maar aanbevolen voor reproduceerbare resultaten).
   1. Schakel de optie Ensemble Voting in in de zijbalk in om alleen IOC's te behouden die aan een minimale stemdrempel voldoen (Min Stemmen ≥ 2 aanbevolen worden).
   2. Voeg extra LLM-instanties toe door provider, modelnaam, API-sleutel en aantal uitvoeringsherhalingen per model te specificeren.
      1. Noteer het aantal herhalingen van elke aanbieder en de geselecteerde minimumstemdrempel van de provider.
         OPMERKING. Ensemble-stemmen is optioneel. Wanneer uitgeschakeld, voert de pipeline single-LLM-extractie uit en wordt het consensusfilter overgeslagen. Standaard ensemble-instellingen zijn herhalingen = 1 per geconfigureerd model en min_votes = 2.
5. Verbind met Neo4j.
   1. In het Neo4j Connection-gedeelte van de zijbalk voer je de verbindings-URI (bijvoorbeeld bolt://localhost:7687), de gebruikersnaam en het wachtwoord in.
   2. Bevestig dat de interface een succesvolle verbinding rapporteert. Ga niet verder zonder een actieve verbinding.
6. Beveilig alle inloggegevens.
   1. Behandel LLM API-sleutels en het Neo4j-wachtwoord als gevoelige inloggegevens. Sla ze op in omgevingsvariabelen of een secrets manager in plaats van in bronbestanden, geëxporteerde rapporten of screenshots, en roteer elke sleutel direct als er een lek wordt vermoed.
      OPMERKING. Dit softwareprotocol vereist geen chemische dampkap, bioveiligheidskast of andere fysieke containmentapparatuur; vertrouwelijke CTI-rapporten en credentials behandelen volgens institutionele gegevensbeveiligingsbeleid.

2. Fase 1: documentparsing

1. Procedure.
   1. Ga naar het tabblad Verwerkingen in de hoofdinterface.
   2. Upload een CTI-rapport in een ondersteund formaat (.pdf, .docx, .md, .txt of .html).
   3. Klik op "Run Next Stage" om Stage 1 uit te voeren, of op "Run All Stages" om de volledige pipeline in volgorde uit te voeren.
2. Bevestig het controlepunt van fase 1.
   1. Controleer of er een Markdown-preview van het invoerdocument wordt weergegeven.
   2. Controleer of bestandspaden, registersleutels, commandoregelfragmenten en sectiegrenzen intact blijven in de preview.
   3. Als technische strings worden afgebroken of de opmaak wordt weggelaten, corrigeer dan het bronbestand of verwerk het document vooraf met een externe converter voordat het opnieuw wordt geüpload.

3. Fase 2: IOC-extractie

1. Procedure.
   1. Bevestig de LLM-configuratie (en ensemble-stemming, indien ingeschakeld).
   2. Klik op "Run Next Stage" om Stage 2 uit te voeren.
2. Bevestig het controlepunt van Fase 2.
   1. Bevestig dat de interface een IOC-collectie toont in JavaScript Object Notation (JSON)-formaat met drie topniveausleutels: Bestandspaden, Opdrachtregels en Registersleutels.
   2. Wanneer ensemble-stemmen is ingeschakeld, controleer dan dat stemtellingen en metadata van het bijdragende model worden geregistreerd voor elk behouden IOC.
      OPMERKING. Het letterlijke Stage 2-systeem en menselijke prompts, samen met de Stage 5 generatie- en optimalisatieprompts, worden uitgebracht als Supplement File 1 (Supplemental_File_1_Prompts.txt).

4. Fase 3: IOC-analyse en classificatie

1. Procedure.
   1. Klik op "Run Next Stage" om Stage 3 uit te voeren.
2. Bevestig het controlepunt van fase 3.
   1. Bevestig dat elke behouden IOC wordt vermeld met een gestandaardiseerde categorie, een brontag en de originele extractiesleutel wanneer beschikbaar.

5. Fase 4: Neo4j-geassisteerde IOC-normalisatie

1. Procedure.
   1. Bevestig dat de Neo4j-verbinding actief is.
   2. Klik op "Run Next Stage" om Stage 4 uit te voeren.
   3. Controleer de per-IOC normalisatie-output en controleer dat keep/discard-labels worden geproduceerd voor pad- en commandoregelcomponenten en dat registersleutels een aaneengesloten canonieke substring opleveren.
2. Bevestig het controlepunt van fase 4.
   1. Bevestig dat genormaliseerde IOC-tabellen worden geproduceerd voor elk IOC-type (bestandspaden, registersleutels, commandoregelindicatoren).
   2. Controleer dat elke invoer de oorspronkelijke waarde, de genormaliseerde waarde en een componentenlijst van element/statusparen bevat die zijn gelabeld met behoud of weggooien.
      OPMERKING. Gedetailleerde Neo4j-schema, cypher-zoekopdrachten, beslissingsregels en de normalisatieprocedure voor registry-sleutels zijn vermeld in Aanvullend Bestand 2; een uitgewerkt voorbeeld wordt gegeven in Representative Results.

6. Fase 5: regex-generatie en -scoren

1. Procedure.
   1. Klik op "Run Next Stage" om Stage 5 uit te voeren. Bevestig dat elke genormaliseerde IOC en de bijbehorende verboden-tokenlijst zijn ingediend voor regex-generatie en deterministische validatie.
   2. Als een kandidaat faalt voor validatie, laat de optimalisatielus de regex verfijnen totdat een conforme kandidaat is geproduceerd of de iteratielimiet is bereikt.
   3. Bekijk de diagnostische output, optimalisatiegeschiedenis en iteratietellingen voor elke IOC waarvan de definitieve regex terugvalt van compliant naar hoogst scorende gedeeltelijke match (geregistreerd als used_fallback = Waar).
2. Bevestig het controlepunt van Fase 5.
   1. Bevestig dat er voor elk vastgehouden IOC een definitieve regex is geproduceerd.
   2. Controleer dat kandidaatscores, optimalisatiegeschiedenissen, issuelijsten en iteratietellingen worden geregistreerd.
   3. Controleer dat per IOC telemetrie, inclusief geschat tokengebruik en latentie, wordt geregistreerd.
      OPMERKING. Gedetailleerde regex-validatieregels, de scoringsformule en iteratiecontroleparameters zijn opgenomen in Supplementair Bestand 2.

7. Analyse en validatie

1. Open het tabblad Analytics om IOC-distributies, ensemble-stemmingsuitkomsten (indien ingeschakeld), regex-kwaliteitssamenvattingen en optimalisatiestatistieken te bekijken. Gebruik deze samenvattingen om afwijkingen te detecteren, zoals extractie-onevenwicht of herhaalde optimalisatiefouten.

8. Exportresultaten

1. Selecteer in het tabblad Exporteren het exportformaat (platte tekst, JSON of YAML) en download de regex-set. Bevestig dat de geëxporteerde regexes de bijbehorende scores en categorisatiemetadata bevatten.
2. Genereer en download het volledige JSON-rapport met geparseerde documenten, geëxtraheerde IOC's, genormaliseerde representaties, kandidaat-regexes en eindresultaten. Bewaar dit rapport als een reproduceerbaarheidsdocument.

9. Probleemoplossing

1. Als Fase 1 afgeknotte of lege PDF-inhoud teruggeeft, bewerk het document dan vooraf met een externe converter of optische tekenherkenningstool voordat je het opnieuw uploadt, en controleer of technische artefacten zichtbaar blijven in de Markdown-preview.
2. Als Fase 2 te weinig consensus-IOC's oplevert, verifieer dan de instellingen voor provider, model, API-sleutel, herhaaltelling en minimale stemmen voordat de drempel wordt aangepast. Inspect sloot kandidaten uit om hallucinaties te onderscheiden van te streng stemmen.
3. Als Fase 4 alle componenten als afdanken labelt, verifieer dan de Neo4j-connectiviteit en bevestig dat de grafiek het relevante Pad-, Register- of commandoregelinterface (CLI) vocabulaire bevat voor het te analyseren IOC-type.
4. Als Fase 5 een regex produceert die compileert maar faalt bij matching of overgeneraliseert, inspecteer dan de optimalisatiegeschiedenis, diagnostische faalpositie en overgeneralisatiecontroles voordat de kandidaat wordt geregenereerd.

10. Bevestig de definitieve protocol-outputs.

1. Bevestig dat het geparseerde Markdown-bestand, de IOC-set (consensusgevalideerd wanneer ensemble voting is ingeschakeld, of single-model wanneer uitgeschakeld), de gecategoriseerde IOC-tabel en de grafgenormaliseerde IOC-representaties allemaal aanwezig zijn.
2. Bevestig dat de SIEM-compatibele regex-set, de analytics-samenvattingen en het volledige JSON-rapport allemaal aanwezig zijn, en archiveer het JSON-rapport als het reproduceerbaarheidsrecord.

Resultaten

Deze sectie presenteert representatieve resultaten die zijn geproduceerd door het IOC-to-regex protocol en vat de referentie-evaluatie samen die is gebruikt om de operationele toepasbaarheid ervan te beoordelen. De referentie-evaluatie verwerkte 3.156 CTI-rapporten die verband houden met MITRE ATT&CK-technieken, analyseerde meer dan 230.000 zinnen, extraheerde meer dan 63.000 IOC-kandidaten en evalueerde gegenereerde regexes aan meer dan 2.400 onafhankelijk verzamelde ground-truth string...

Discussie

Het vertalen van ongestructureerde CTI-rapporten naar uitvoerbare detectielogica blijft een tijdrovende en foutgevoelige taak in operationele beveiligingsworkflows. Hoewel eerdere inspanningen automatisering op het niveau van IOC-extractie of hoog-niveau regelgeneratie hebben onderzocht, staan praktijkmensen nog steeds voor aanzienlijke uitdagingen bij het omzetten van geëxtraheerde IOC-strings in regexes die structureel correct, semantisch precies en geschikt zijn voor downstream SIEM-g...

Materialen

Lijst van materialen gebruikt in dit artikel

Naam	Bedrijf	Catalogusnummer	Opmerkingen
Computer (CPU)	—	≥ 4 cores aanbevolen	Geen GPU vereist
LangChain	LangChain	≥ 0.1.x	LLM-orkestratieframework
LLM (IOC-extractie, single-model)	OpenAI	gpt-5.1	Gebaat voor IOC-extractie (Stadium 2) wanneer ensemble-voting is uitgeschakeld. temperatuur = 0,0; max_workers = 5. Toegankelijk: 2025-12-15.
LLM (Regex-generatie)	OpenAI	gpt-5.1	Gebaat voor regex-generatie (Stadium 5). temperatuur = 0,3 vóór downstream-validatie. Toegankelijk: 2025-12-15.
LLM (Schaalbaarheidskarakterisering)	OpenAI	gpt-5.1	Gebaat voor de 6.000-IOC-schaalbaarheidsuitvoering gerapporteerd in representatieve resultaten. Toegankelijk: 2025-12-15.
Geheugen (RAM)	—	≥ 16 GB aanbevolen	Vereist voor documentverwerking
Neo4j	Neo4j, Inc.	≥ 5.x	Grafische database voor IOC-normalisatie
Neo4j Python-driver	Neo4j, Inc.	≥ 5.x	Python-interface naar Neo4j
Besturingssysteem	Microsoft / Apple / Linux	Windows, macOS of Linux	Cross-platform ondersteuning
PDF-parsing — primaire backend	Microsoft	MarkItDown ≥ 0.0.x	Stadium 1-backend; converteert PDF/DOCX/HTML/TXT-invoer naar Markdown. Geparseerde uitvoer in stukken van 4.000 tekens voor LLM-verwerking. Toegankelijk: 2025-12-15. https://github.com/microsoft/markitdown
Pijplijnconfiguratie (Stadium 2 — IOC-extractie)	—	Referentie-standaardwaarden	Single-LLM-modus: temperatuur = 0,0, max_workers = 5. Ensemble-voting-modus standaardwaarden: herhalingen = 1 per geconfigureerd model, min_stemmen = 2.
Pijplijnconfiguratie (Stadium 5 — regex-generatie)	—	Referentie-standaardwaarden	Generatie temperatuur = 0,3. Validatie: overgen_random_tests = 5 deterministische negatieve steekproeven per IOC. Iteratiegrenzen: max_iteraties = 10, debug_loop_cap = 5, discard_validation_cap = 5.
Python	Python Software Foundation	≥ 3.8	Vereiste runtime-omgeving
Regex-engine	Python Standard Library	re-module	Gebaat voor regex-validatie en -testen
Streamlit	Streamlit Inc.	≥ 1.25	Webgebaseerde gebruikersinterface
Referentie-implementatiebroncode	Auteurs / GitHub | GitHub-repository		Broncode voor de Streamlit-interface, LangChain-pijplijn, Neo4j-ondersteunde normalisatie, regex-generatie, validatiehulpmiddelen en voorbeeldconfiguratiebestanden. Beschikbaar op https://github.com/SOCautomatic/cti-ioc-regex-pipeline. Toegankelijk: 11 juni 2026.