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 strings uit tien MITRE ATT&CK-evaluatiescenario's. Deze ground-truth-strings zijn door experts samengestelde aanvalartefacten die onafhankelijk worden gerapporteerd door cybersecurityleveranciers tijdens de MITRE ATT&CK Evaluatie-oefeningen en weerspiegelen daarom de structurele patronen die menselijke analisten en leveranciers in de praktijk documenteren. De onderstaande resultaten richten zich op workflowgedrag, structurele correctheid en evaluatieresultaten die relevant zijn voor operationele loganalyse en detectieworkflows.

Een overzicht van de end-to-end pijplijn wordt gegeven in Figuur 1, die de fasen van het vinden van capture-groepen en regex-generatie samenvat die de rest van de representatieve resultaten omlijsten.

Fase 1: Document Parsing uitvoer

Figuur 2 toont de output van Fase 1, waarbij een invoer-CTI-rapport wordt ontleed in een uniforme Markdown-representatie. Na succesvolle uitvoering toont de interface een gestructureerde preview van het document, inclusief sectiegrenzen en relevantie-indicatoren.

Correcte uitvoering wordt aangegeven door coherente paragraafsegmentatie en het behoud van technische artefacten zoals bestandspaden, registersleutels en fragmenten van de commandoregel. Overmatige afkorting of verlies van opmaak in deze fase kan de downstream-analyse beïnvloeden en moet worden aangepakt voordat er verder wordt gegaan.

Fase 2: Consensus-gebaseerde IOC-extractie

Figuur 3 illustreert de output van Fase 2, waarbij kandidaat-IOC's worden geëxtraheerd met behulp van multi-LLM ensemble stemming. De resulterende interface presenteert een JSON-geformatteerde IOC-collectie met annoten van stemtellingen en bijdragende modellen.

Alleen IOC's die voldoen aan de geconfigureerde minimale consensusdrempel worden behouden. IOC's die in deze fase worden uitgesloten, weerspiegelen doorgaans modelspecifieke hallucinaties of dubbelzinnige tekstfragmenten. Hun uitsluiting is een verwacht en wenselijk resultaat, wat aangeeft dat ensemble-stemmen correct functioneren.

Fase 3: IOC-analyse en classificatie

Tabel 2 vat de verwachte output, geautomatiseerde validatiestappen en analytische kwaliteitscontrolecontroles voor elke protocolfase samen.

Figuur 4 toont de IOC-kandidaten die tijdens het ensemble-stemmen in fase 2 niet aan de consensusdrempel voldeden en die de interface naar voren brengt voor analisteninspectie. Dergelijke kandidaten weerspiegelen doorgaans modelspecifieke hallucinaties of dubbelzinnige tekstfragmenten. Figuur 4 en Figuur 5 komen dus overeen met verschillende fase-uitgangen — de weggegooide set uit Fase 2 en de behouden set uit Fase 3 — in plaats van met alternatieve weergaven van hetzelfde Fase 3-proces.

Figuur 5 toont de behouden IOC-tabel die door Fase 3 is geproduceerd na JSON-parsing, regelgebaseerde categorisatie en IOC-deduplicatie. Voor elke behouden IOC registreert de fase een gestandaardiseerde categorie, brontag en de originele extractiesleutel wanneer beschikbaar, voordat de IOC wordt doorgegeven aan downstream normalisatie.

Fase 4: Graf-ondersteunde IOC-normalisatie over IOC-typen heen

Figuren 6, Figuur 7 en Figuur 8 illustreren representatieve normalisatieresultaten voor drie IOC-categorieën die in de huidige studie worden behandeld: bestandspaden, registersleutels en commandoregelindicatoren. Voor elke categorie vergelijken de cijfers de oorspronkelijke IOC die uit het CTI-rapport is gehaald met de genormaliseerde representatie die is geproduceerd met behulp van grafiekondersteunde analyse.

Over alle IOC-typen heen verdeelt het protocol elke IOC in semantische componenten en lost het hiërarchische relaties op met behulp van gestructureerde kennis die in de grafiekdatabase is gecodeerd. In de huidige implementatie slaat Neo4j genormaliseerde Path-, Registry- en CLI-nodes op en gebruikt het adjacency-relaties om te testen of componenten tot herkende ketens behoren. Deze rol is analoog aan het gebruik van gestructureerde ATT&CK-kennis tijdens detectietechniek².

Belangrijk is dat deze normalisatiestap expliciete semantische rollen voor IOC-componenten registreert door ze te labelen als behouden of weggooien in plaats van ze stilletjes uit het analyserecord te verwijderen. De genormaliseerde string wordt voornamelijk gereconstrueerd uit keep-componenten, terwijl verwijderde componenten beschikbaar blijven als metadata voor downstream regex-generatie en validatie.

De correcte uitvoering van deze fase wordt aangegeven door genormaliseerde IOC's die betekenisvolle structurele context behouden en consistente capture-group labeling vertonen over verschillende IOC-typen. Visuele vergelijking tussen originele en genormaliseerde representaties biedt een praktisch kwaliteitscontrolemechanisme om te verifiëren dat capture-group resolutie consistent is toegepast en zonder onbedoeld informatieverlies.

Fase 5: Reguliere expressiegeneratie met hulpbeperkingsgebaseerde selectie

Figuur 9 illustreert de output van Fase 5, waarbij het protocol structureel conforme reguliere expressies genereert uit genormaliseerde IOC's via een iteratieve validatieworkflow. De implementatie combineert een prompt voor initiële generatie, diagnostische heropvatting wanneer een kandidaat niet overeenkomt met de IOC, discard-aware validatie en gecapte herprobeerloops.

Gegeven een genormaliseerde IOC en de bijbehorende keep/discard-componentspecificatie, genereert de workflow eerst een initiële regex-kandidaat. De kandidaat wordt vervolgens getest tegen de IOC, diagnostisch opnieuw gevraagd wanneer de matching faalt, gecontroleerd op verboden afgedankte tokens en geëvalueerd op overgeneralisatie met willekeurige negatieve strings.

Wanneer meerdere kandidaten voldoen aan de basisvalidatiecontroles, past het protocol een hulpselectiemechanisme toe op basis van beperkingen om een representatieve regex te behouden voor downstream gebruik. De huidige implementatie geeft kandidaten een score met 'Score = n_cg - n_wc', waarbij 'n_cg' het aantal vertegenwoordigde keep-componenten is en 'n_wc' het aantal weggegooide of niet-toegewezen tokens in de regex.

De selectiefunctie wordt gedefinieerd als:

Score = n_cg − n_wc

Dit is de gelijkgewichtspecialisatie (α = β = 1) van de algemenere vorm Score = α·n_cg − β·n_wc. Hier duidt n_cg het aantal gerepresenteerde keep-componenten aan en n_wc het aantal discard-componenten of niet-toegewezen extra tokens die door de regex opnieuw zijn geïntroduceerd. De implementatie registreert ook iteratietellingen, issuelijsten, geschat tokenverbruik, cachegebruik en latentietelemetrie voor elke IOC. De gelijkgewicht-instelling werd gebruikt als een eenvoudige deterministische standaard voor de referentie-implementatie; Omdat het een ontbrekende keep-component en een heringevoerde weggooicomponent als even ongewenst behandelt, kunnen andere wegingen worden verkiezen in implementatiecontexten waar valse en valse positieven verschillende operationele kosten met zich meebrengen.

De uiteindelijke regex wordt geselecteerd als de kandidaat die het beste aan deze voorwaarden voldoet. Regexes die vereiste capture-groepcomponenten in optionele constructies plaatsen, bijvoorbeeld ( ... )?, worden uitgesloten van selectie omdat ze de semantische consistentie verzwakken. Deze selectiestap is een bijkomend onderdeel van het generatieproces en is niet bedoeld als een op zichzelf staande kwaliteitsmaatstaf te dienen.

Analytics Overzicht van CTI-verwerking

Figuur 10 geeft een overzicht van de CTI-analyseresultaten over alle verwerkte documenten. In de referentie-evaluatie leverde IOC-extractie van meer dan 3.156 CTI-rapporten meer dan 63.000 IOC-kandidaten op, waaronder 12.195 bestandspaden, 2.302 registersleutels en 10.286 commandoregelindicatoren, waarbij de overige kandidaten tot niet-regex-doelgerichte IOC-types behoorden.

Deze tellingen bieden een overzichtelijke validatie dat de geëxtraheerde indicatoren geconcentreerd zijn in de drie IOC-categorieën die door het huidige protocol worden aangepakt, terwijl ook wordt aangetoond dat veel geëxtraheerde artefacten buiten het bereik van regex-generatie blijven. Bij het reproduceren van de workflow rapporteer je het exacte aantal verwerkt CTI-rapporten, het totale aantal IOC-kandidaten, de categorieëngewijze tellingen, en de leverancier, model, modelversie, temperatuur, herhaaltelling en consensusdrempel die tijdens de extractie zijn gebruikt.

In de referentie-evaluatie werden gegenereerde regexes beoordeeld aan meer dan 2.400 onafhankelijk verzamelde ground-truth strings uit tien MITRE ATT&CK-evaluatiescenario's en behaalden zij een gemiddelde trefferskans van 99,1%, samen met een gemiddelde cross-IOC mismatch van 0,8%. In dit manuscript wordt mismatch rate gebruikt als een semantische specificiteitsmaat: een mismatch treedt op wanneer een regex die voor één IOC is gegenereerd, ook overeenkomt met een ground-truth string die aan een andere IOC is gekoppeld. Deze hoeveelheid moet niet worden geïnterpreteerd als een end-to-end operationeel alarm-vals-positiefpercentage, dat ook afhangt van de downstream-regellogica en de implementatiecontext.

De verdeling weerspiegelt de structurele samenstelling van het CTI-corpus en stelt gebruikers in staat te verifiëren dat de geëxtraheerde indicatoren overeenkomen met de verwachte IOC-types. Grote afwijkingen van de verwachte verhoudingen kunnen wijzen op problemen met upstream parsing of extractie en moeten worden onderzocht voordat men doorgaat met downstream normalisatie en regexgeneratie.

Analyse van Regex-optimalisatieacties

Figuur 11 vat de handelingen samen die worden uitgevoerd tijdens het genereren en verfijnen van reguliere expressies. De distributie omvat drie soorten acties: initiële regexgeneratie, LLM-gestuurde optimalisatiestappen en retry-gebaseerde regeneratie.

LLM-gedreven optimalisatie is goed voor 51,7% van alle waargenomen acties. Deze prevalentie geeft aan dat de eerste generatie alleen vaak onvoldoende is om regexen te produceren die voldoen aan capture-group beperkingen en uitsluitingseisen. In plaats daarvan wordt iteratieve optimalisatie actief en herhaaldelijk toegepast om kandidaatregexen te verfijnen.

In plaats van inefficiëntie te weerspiegelen, toont deze verdeling aan dat de optimalisatieworkflow een noodzakelijk en integraal onderdeel is van het protocol bij het genereren van structureel conforme regexes uit complexe IOC-invoer.

Een aparte schaalbaarheidskarakterisering over een willekeurige steekproef van 6.000 IOC's, gegenereerd met de schaalbaarheidstest LLM (zie de Materiaaltabel), rapporteerde een mediane latentie van 2,95 seconden per IOC en een gemiddelde latentie van 23,18 s. In dezelfde karakterisering bereikte syntaxis-valide regex-compilatie 99,56 %, het totale generatiesucces 99,4 %, het gemiddelde geschatte tokengebruik was ongeveer 3.986 tokens per IOC, en vereiste de workflow gemiddeld ongeveer 7,89 LLM-aanroepen per IOC. De slagingspercentages bij de eerste ronde waren 56,46% voor de match-debug lus en 72,92% voor de validatielus zonder capture-groep. Deze metingen helpen de rekenkosten en operationele doorvoer voor batchgebruik te karakteriseren.

Er werd geen deskundige beoordeling van een bemonsterde output-subset gebruikt voor modelhertraining in de huidige referentiekarakterisering; De gerapporteerde resultaten weerspiegelen de geautomatiseerde pijpleidinguitvoering en de hierboven beschreven downstream evaluatiedatasets.

Operationeel bewijs en afhandeling van storingen. Figuur 12 toont de structuur van het geëxporteerde SIEM regex-bestand dat door het protocol wordt geproduceerd, samen met validatiebewijs op regelniveau voor representatieve bestandspaden, registersleutel- en commandoregelpatronen. Figuur 13 toont het bijbehorende volledige JSON-rapport, dat alle stage-uitvoeren (geëxtraheerde, geanalyseerde en genormaliseerde IOC's samen met de gegenereerde regexpatronen en per-IOC validatieflags) blootlegt en het primaire artefact is dat downstream tools verbruiken. Figuur 14 illustreert hoe het protocol omgaat met een ruiserige CTI-invoer: een ontwapend, door witruimte gestoord bestandspad wordt gemarkeerd in de analysefase, gecorrigeerd, genormaliseerd naar het canonieke %TEMP%-sjabloon en vervolgens omgezet in een compilerend, overeenkomend regex. Dit uitgevoerde voorbeeld vult het operationele bewijs in Figuur 12 en Figuur 13 aan door te documenteren hoe het protocol zich gedraagt wanneer de ruwe IOC-tekst afwijkt van de canonieke vorm.

Figuur 1: Algemene architectuur van het IOC-naar-regex protocol. De figuur vat de end-to-end pijplijn samen. Kandidaat-IOC-strings die door de upstream IOC-extractor worden geproduceerd, worden ontleed en vergeleken met referentieknopen in een Neo4j-graaf die uit Windows-documentatie is ingevuld (stap 1), die bekende pad-, register- en commandoregelcomponenten ophaalt (stap 2). Variabele of omgevingsspecifieke fragmenten worden gelabeld als aflegging en uitgesloten van de genormaliseerde reconstructie, terwijl ze in componentmetadata worden behouden, wat resulteert in een genormaliseerde IOC met componentniveau bewaar- en weggooilabels (stap 3). Deze genormaliseerde IOC's worden vervolgens doorgegeven aan een LLM-gebaseerde regexgeneratiefase (stap 4) die kandidaat-reguliere expressies produceert, die worden beoordeeld en iteratief worden geoptimaliseerd op basis van capture-group constraints en discarded-token-regels (stap 5) voordat een definitieve regex wordt geselecteerd (stap 6). Klik hier om een grotere versie van deze figuur te bekijken.

Figuur 2: Fase 1 documentparsing-uitvoer. Zij-aan-zij vergelijking van het originele CTI-rapport en de geanalyseerde documentpreview. Het linkerpaneel toont het originele CTI-rapport in PDF-formaat, terwijl het rechterpaneel de uniforme Markdown-representatie toont die door de parser is gegenereerd. Klik hier om een grotere versie van deze figuur te bekijken.

Figuur 3: Consensus-gebaseerde IOC-extractie met multi-LLM ensemble stemming. De interface illustreert het ensemble-gebaseerde IOC-extractieproces en de tussenliggende resultaten daarvan. Het rode vakje markeert de geconfigureerde LLM-instanties die deelnemen aan IOC-extractie, inclusief de geselecteerde providers en het aantal herhaalde extractieruns per model. Het blauwe vakje geeft de door de gebruiker gedefinieerde consensusdrempel aan, die het minimale aantal gevallen aangeeft dat nodig is om een IOC te behouden. Na het aggregeren van extractieresultaten over alle modellen en herhalingen, worden kandidaat-IOC's die minder vaak dan de drempel voorkomen verworpen. Het oranje vakje toont de laatste set behouden IOC's die voldoen aan het consensuscriterium en worden doorgegeven aan downstream analysefasen. Klik hier om een grotere versie van deze figuur te bekijken.

Figuur 4: IOC's verworpen door ensemblestemming in Fase 2. Zij-aan-zij weergave van IOC-kandidaten die niet voldeden aan de geconfigureerde minimumstemdrempel tijdens ensemble voting en die ter inspectie van analisten worden getoond. Afgedankte kandidaten weerspiegelen doorgaans modelspecifieke hallucinaties of dubbelzinnige tekstfragmenten en worden niet doorgegeven aan de categorisatiestap van fase 3. Klik hier om een grotere versie van deze figuur te bekijken.

Figuur 5: Behouden IOC-set met gestandaardiseerde classificatie. IOC-kandidaten die na Fase 3-verwerking zijn behouden, worden samen met hun gestandaardiseerde categorieën, brontags en originele extractiesleutels getoond wanneer beschikbaar. Deze tabel geeft de gestructureerde IOC-invoer die door de normalisatiefase wordt gebruikt. Klik hier om een grotere versie van deze figuur te bekijken.

Figuur 6: IOC-normalisatie van het bestandspad met behulp van grafiekondersteunde analyse. Zij-aan-zij vergelijking van een origineel bestandspad IOC en de genormaliseerde representatie daarvan. Grafgebaseerde doorloopzoekopdrachten gebruiken bekende padcomponenten met een genormaliseerde naam en labelen elke component als behouden of weggooien. Schijfidentificaties en variabele bestandsnaamfragmenten kunnen daarom als weggegooid worden gemarkeerd in het componentrecord, terwijl de genormaliseerde vorm voornamelijk wordt gereconstrueerd uit behouden structurele segmenten die nodig zijn voor downstream patroonconstructie. Klik hier om een grotere versie van deze figuur te bekijken.

Figuur 7: Normalisatie van de IOC-registersleutel met behulp van grafiekondersteunde analyse. Normalisatie van een registersleutel IOC door grafiekondersteunde oplossing van hiërarchische registerstructuren. Verkorte root-sleutels worden uitgebreid tot canonieke register-hives, en de analyzer haalt de langst aaneengesloten bekende register-substring uit terwijl host-placeholders, SID-achtige waarden en GUID-achtige tokens worden overgeslagen. De uitvoerrecords bewaren/verwijderen labels voor elk behouden onderdeel en genereren een canoniek registerpad voor downstream verwerking. Klik hier om een grotere versie van deze figuur te bekijken.

Figuur 8: Commandoregel-IOC-normalisatie met behulp van grafiekondersteunde analyse. Vergelijking van een originele commandoregel-IOC en de genormaliseerde representatie ervan. Het protocol tokeniseert de commandoregel terwijl de aangehaalde strings behouden blijven, normaliseert het leidende commandotoken via Neo4j-lookup waar mogelijk, en analyseert recursief ingebedde pad- of registerachtige fragmenten. Stabiele commando-gerelateerde componenten worden gelabeld als keep, variabele argumenten worden gelabeld als afwerpen, en de uiteindelijke canonieke commandostructuur wordt gereconstrueerd uit de bewaarde elementen. Klik hier om een grotere versie van deze figuur te bekijken.

Figuur 9: Constraint-gebaseerde selectie van kandidaten voor reguliere expressie. Meerdere regex-kandidaten worden voor elke genormaliseerde IOC gegenereerd met behulp van een iteratieve validatieworkflow. Een constraint-gedreven scoringsmechanisme wordt toegepast om een laatste regex te selecteren die aangewezen capture-groepcomponenten behoudt terwijl ongewenste variabele-substrings worden beperkt. Klik hier om een grotere versie van deze figuur te bekijken.

Figuur 10: Verdeling van geëxtraheerde IOC's over CTI-rapporten. Samenvatting van IOC-extractieresultaten toont het totale aantal indicatoren dat uit CTI-rapporten is geïdentificeerd en hun verdeling over bestandspaden, registersleutels en commandoregelindicatoren. Deze weergave biedt een overzichtelijke validatie van CTI-inhoudsdekking en extractiegedrag. Klik hier om een grotere versie van deze figuur te bekijken.

Figuur 11: Verdeling van optimalisatieacties tijdens het genereren van reguliere expressies. Opsplitsing van acties uitgevoerd tijdens regex-generatie, inclusief de initiële generatie, LLM-gestuurde optimalisatie en retry-gebaseerde regeneratie. LLM-gedreven optimalisatie is goed voor 51,7% van alle acties, wat illustreert dat iteratieve verfijning een essentieel onderdeel is van het protocol om regexes te produceren die voldoen aan capture-group constraints. Klik hier om een grotere versie van deze figuur te bekijken.

Figuur 12: Representatief geëxporteerd regex-bestand. Voorbeeldinhoud van de SIEM regex-export (siem_rules.txt) die door het protocol wordt gegenereerd. Elke vermelding bevat de bron-IOC, de afgeleide categorie (bestandspad, registersleutel of commandoregel), en het gevalideerde regex-patroon. De bijbehorende validatietabel vat het verwachte gedrag samen en het systeembewijs dat is gebruikt om de correctheid voor elk regeltype te bevestigen. Klik hier om een grotere versie van deze figuur te bekijken.

Figuur 13: Volledig JSON-rapport van de vertegenwoordiger. End-to-end pijplijnoutput geproduceerd na het uitvoeren van alle vijf protocolfasen op een representatief CTI-rapport. Het JSON-document registreert het bronbestand, het aantal geparste secties, geëxtraheerde IOC's gegroepeerd per categorie, stage-3 gecategoriseerde records met brontags, stage-4 normalisatiediff en stage-5 regex-patronen met per-IOC validatievlaggen. Het rapport onthult ook top-level succes- en foutmetadata die downstream-tools in staat stellen gedeeltelijke fouten te detecteren. Klik hier om een grotere versie van deze figuur te bekijken.

Figuur 14: Mislukte of ruisachtige invoer: identificatie en correctie. Een bewerkt voorbeeld van hoe het protocol een lawaaierige IOC herkent en herstelt. De ruwe invoer %T E M P%\malware[.]EXE wordt gemarkeerd omdat het omgevingsvariabeletoken ingevoegde ruimtes bevat en de bestandsextensie is ontmanteld. De correctiestap verwijdert de ingevoegde witruimte en herstelt de letterlijke punt; Fase 4-normalisatie breidt vervolgens %TEMP% uit naar het canonieke Windows Temp-directorytemplate; en Fase 5 genereert een regex die de gecorrigeerde genormaliseerde IOC compileert en matcht. Dit voorbeeld illustreert de afhandeling van ruisachtige input die in de Discussie wordt besproken. Klik hier om een grotere versie van deze figuur te bekijken.

Element	Type	Waarde / Schema	Voorbeeld	Noten
Knooplabel	Label	:P ath	Windows, System32, cmd.exe	Slaat Windows-bestandspadcomponenten op
Knooplabel	Label	:Register	SOFTWARE, Microsoft, Windows NT	Slaat registersleutelcomponenten op onder wortelbijentjes
Knooplabel	Label	:CLI	powershell.exe, -ExecutionPolicy, Bypass	Slaat commandotokens en parameters op
Knoopeigenschap	Snaar	Naam	cmd.exe	Originele behuizing; Gebruikt voor weergave in genormaliseerde uitvoer
Knoopeigenschap	Snaar	name_lower	cmd.exe	Kleine letter; gebruikt als opzoeksleutel voor alle MATCH-zoekopdrachten
Relatie	Gerichte rand	(a)-[:VOLGENDE]->(b)	(Windows)-[:NEXT]->(System32)	Beide eindpunten delen hetzelfde label; codeert native adjacency op Windows-systemen
Beperking	Uniekheid	n.name_lower UNIEK per label	-	Aangevraagd op :P ath, :Registry, :CLI
Gegevensbron	Dekking	Windows 8, 10, 11	-	Clientbesturingssysteem ingevuld in graaf
Gegevensbron	Dekking	Windows Server 2012, 2016, 2019, 2022	-	Serverbesturingssysteem ingevuld in de grafiek

Tabel 1: Neo4j-graafschema gebruikt voor IOC-normalisatie (Fase 4). Geeft een lijst van de drie knooplabels (Pad, Register, CLI), hun gedeelde eigenschapsschema (naam, name_lower), de gerichte adjacencyrelatie die wordt gebruikt voor native-ordering randen, uniciteitsbeperkingen en de Windows-client- en serverversies die de grafiek vullen.

Podium	Verwachte productie	Geautomatiseerde validatie	Kwaliteitscontrole gericht op analisten
Fase 1: Documentparsing	Unified Markdown-tekst, gefragmenteerd met 4.000 tekens vóór LLM-verwerking.	—	Visuele controle van Markdown-preview om te bevestigen dat bestandspaden, registersleutels, commandoregelfragmenten en sectiegrenzen de parsing overleven; Wissel van backend als technische strings worden afgekapt.
Fase 2: IOC-extractie	JSON met drie topniveausleutels (Bestandspaden, Commandoregels, Registersleutels); per IOC-stemtellingen en bijdragende modelmetadata wanneer ensemblestemming is ingeschakeld.	Consensus threshold filter (min_votes) sluit IOC's uit waarvan het aantal stemmen onder de geconfigureerde drempel ligt.	Inspectie van uitgesloten kandidaten om hallucinaties te onderscheiden van te streng stemmen voordat min_votes wordt aangepast.
Fase 3: IOC-analyse en classificatie	Gecategoriseerde IOC-lijst: elke IOC gekoppeld aan een gestandaardiseerde categorie, brontag en originele extractiesleutel indien beschikbaar.	Gestandaardiseerde categorie-mapping via regex-gebaseerde regels en IOC-patroonheuristieken; (IOC, categorie) pardeduplicatie.	Steekproef van gecategoriseerde output voor ambigue of ruisachtige kandidaten (Figuur 4A).
Fase 4: Neo4j-geassisteerde normalisatie	Per-IOC genormaliseerde vorm met component-niveau bewaar-/weggooilabels.	Cypher-query's (i)-(iii) over de Windows-referentiegraaf; deterministische preprocessing fallback wanneer Neo4j niet beschikbaar is.	Inspectie van alle afvalkoffers om gaten in de grafiekdekking te identificeren; uitbreiding van grafiekgegevens met leveranciers- of omgevingsspecifieke referenties indien nodig.
Fase 5: Regex-generatie en puntentelling	Definitieve regex per IOC met kandidaatscores, optimalisatiegeschiedenis, iteratietellingen en telemetrie per IOC.	Matchtest, statische kwaliteitscontroles, grensbewuste verboden-token controle, overgeneralisatietest tegen 5 deterministische negatieve steekproeven; val terug naar de hoogst scorende gedeeltelijke wedstrijd (used_fallback vlag).	Optimalisatiegeschiedenis review voor fallback-regexes; per IOC faalpositie-diagnostische inspectie voordat het wordt geregenereerd.

Tabel 2: Stage-output en validatiesamenvatting. Koppelt elke protocolfase (1–5) aan het verwachte artefact, het geautomatiseerde validatiebewijs dat door de pijplijn wordt geproduceerd (regex-compilatiestatus, hit rate, cross-IOC mismatchrate, optimalisatieiteratietellingen), en de bijbehorende analytische kwaliteitscontrole (visuele vergelijking, inspectie van afgedankte kandidaten en categoriebeoordeling).

Aanvullend Bestand 1: Woordelijke LLM-prompts. Het woordelijke systeem en menselijke prompts worden gebruikt voor Stage 2 IOC-extractie en Stage 5 regex-generatie en optimalisatie. Klik hier om dit bestand te downloaden.

Aanvullend Dossier 2: Implementatiedetails voor Fasen 4 en 5. Algoritmische en implementatiedetails ondersteunen de Stage 4 graf-ondersteunde IOC-normalisatie en de Stage 5 regex-validatie, scoring en iteratiecontrole. Klik hier om dit bestand te downloaden.

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-gebruik. Het hier gepresenteerde protocol pakt die kloof aan via een gefaseerde workflow waarbij elke fase een goed gedefinieerd tussenproduct produceert en expliciete validatie toepast voordat de resultaten naar de volgende fase worden doorgegeven. Figuur 14 documenteert zo'n geval, waarin een ontwapend, door witruimte verstoord bestandspad wordt geïdentificeerd, gecorrigeerd, genormaliseerd en omgezet in een compilerregex; De afhandeling van ruisachtige invoer en de huidige scope van het protocol worden gezamenlijk besproken, met de hieronder genoemde beperkingen.

Een centrale bijdrage van dit protocol is de expliciete ontbinding van de workflow in fasen met inspecteerbare tussenliggende outputs. De implementatie wordt nu concreet beschreven: documentparsing levert Markdown- en chunked tekst op voor LLM-verwerking; IOC-extractie zendt gestructureerde JSON uit voor bestandspaden, registersleutels en commandoregelindicatoren; regelgebaseerde IOC-analyse standaardiseert en dedupliceert geëxtraheerde waarden; Neo4j-ondersteunde normalisatie labelt elke IOC-component als behouden of weggooien; en regex-generatie past match-debugging, discard-validatie en overgeneralisatiecontroles toe vóór kandidaatselectie.

Het protocol behandelt reguliere expressiegeneratie als een iteratieve constructietaak in plaats van als een eenmalige voorspellingsopgave. De implementatie gebruikt een prompt voor de eerste generatie, geautomatiseerde matchdiagnostiek, gecapte verfijningslussen en een componentgebaseerde scoringsfunctie om structureel belangrijke IOC-elementen te behouden, terwijl weggegooide of niet-toegewezen substrings worden bestraft. Dit iteratieve ontwerp, samen met deterministische validatoren die bij elke stap worden toegepast, ondersteunt de productie van regex-patronen die structureel trouw blijven over een grote en heterogene evaluatieset. In de referentie-evaluatie werd deze workflow toegepast op 3.156 CTI-rapporten en geëvalueerd aan meer dan 2.400 onafhankelijke ground-truth strings, wat resulteerde in een gemiddelde trefferskans van 99,1% en een gemiddelde cross-IOC mismatch rate van 0,8%. Omdat deze ground-truth-strings door experts samengesteld zijn die door cybersecurityleveranciers zijn gerapporteerd tijdens de MITRE ATT&CK Evaluatie-oefeningen, vergelijkt deze evaluatie impliciet de output van het protocol met IOC-patronen die door menselijke analisten zijn gedocumenteerd, in plaats van met automatisch gegenereerde patronen.

Zoals te zien is in de representatieve resultaten, is iteratieve optimalisatie bijzonder belangrijk wanneer de workflow complexe IOC-structuren verwerkt, zoals geneste bestandspaden of lange commandoregelstrings. Referentie-evaluatieresultaten geven ook aan dat de meest voorkomende niet-matched gevallen optreden wanneer aanvallers aangepaste uitvoerbare bestanden of parameters gebruiken die niet in de grafiekdatabase zijn weergegeven of niet expliciet zijn gedocumenteerd in de bron-CTI-rapporten. In operationeel gebruik moeten deze faalmodi worden behandeld als verwachte randvoorwaarden in plaats van stille fouten en moeten ze een beoordeling van grafiekdekking, bron-rapport volledigheid en regex-debug telemetrie triggeren.

Het protocol kan worden vergeleken met drie families van alternatieve methoden. Ten eerste leren voorbeeldgebaseerde regex-synthesemethoden zoals TransRegex¹¹ en Regex+¹² regexen uit gecureerde sets van positieve en negatieve stringvoorbeelden. Deze methoden presteren goed wanneer representatieve voorbeeldsets beschikbaar zijn, maar zijn minder direct toepasbaar op SOC-contexten, waar elke IOC die in CTI wordt gerapporteerd doorgaans slechts als één representatieve string verschijnt, en de vereiste generalisatiegrens wordt bepaald door operationele semantiek in plaats van door voorbeelddekking. Ten tweede doorzoeken genetische programmeringsbenaderingen zoals die geïntroduceerd door Bartoli et ^al.13,14 de ruimte van regexen via evolutionaire operatoren en vereisen doorgaans een gelabeld corpus van match- en non-matchstrings; ze zijn goed geschikt voor batchconstructie van extractiepatronen, maar consumeren niet direct ongestructureerde CTI-verhalen. Ten derde vertalen recente neurale en LLM-gebaseerde benaderingen^15,16 natuurtaalbeschrijvingen direct naar regex-strings; deze methoden zijn krachtig voor goed gespecificeerde prompts, maar kunnen bij gebruik met één shot regexes produceren die syntactisch geldig zijn, maar de benodigde capture-groupcomponenten missen of overgeneraliseren over niet-gerelateerde IOC-varianten. Het huidige protocol vult deze richtingen aan door (i) ongestructureerde CTI-rapporten te nemen in plaats van gecureerde voorbeeldsets of natuurtaalqueries als input, (ii) elke IOC te ontleden in keep- en discard-componenten via graf-ondersteunde normalisatie voordat een regex wordt gegenereerd, en (iii) elke kandidaat-regex te valideren met deterministische match-, discard- en overgeneralisatiecontroles binnen een gecapde iteratieve lus. Het doel is niet om eerdere methoden op hun eigen benchmarks te overtreffen, maar om een reproduceerbare IOC-naar-regex-pijplijn te bieden waarvan de tussenliggende beslissingen inspecteerbaar en controleerbaar zijn door SOC-analisten.

Het protocol maakt verschillende aannames over de kwaliteit van de ingevoerde CTI-rapporten. Het gaat ervan uit dat (i) IOC-strings in een herstelbare tekstuele vorm verschijnen na documentparsing, d.w.z. bestandspaden, registersleutels en commandoregelindicatoren zijn niet uitsluitend ingebed in afbeeldingen, screenshots of verborgen coderingen; (ii) IOC-fragmenten die in de CTI worden gerapporteerd voldoende compleet zijn om hun structurele ankers te behouden (bijvoorbeeld, registersleutels behouden hun hive-prefix, bestandspaden behouden ten minste één directoryanker die herkenbaar is voor de Windows-documentatiegrafiek, en commandoregels behouden het aanroepende uitvoerbare bestand of een bekende modulereferentie); en (iii) de gerapporteerde IOC's worden niet afgekapt, geredigeerd of herschreven op manieren die de capture-groepcomponenten waarop het protocol steunt worden verwijderd. CTI-rapporten die aan deze aannames voldoen, omvatten de meeste MITRE ATT&CK-techniekbeschrijvingen, leveranciersadviezen, incidentresponsrapporten en goed geformatteerde dreigingsbulletins. Rapporten die voornamelijk vertrouwen op screenshots, sterk ingekorte IOC-lijsten zonder context of vrije tekst zonder expliciete IOC-strings vallen buiten de beoogde operationele grens en moeten worden verwacht dat ze minder extractie-recall en minder getrouwe normalisatie opleveren; Dergelijke rapporten kunnen profiteren van upstream beeld-naar-tekst preprocessing of analyse van analisten voordat ze in de pijplijn worden gegaan.

Bij het toepassen van dit protocol moeten verschillende beperkingen worden overwogen. Ten eerste richt de huidige implementatie zich op bestandspaden, registersleutels en commandoregelindicatoren in plaats van bredere IOC-categorieën zoals domeinen, e-mailartefacten, user-agent-strings of gedragssequenties. Dit is een bewuste keuze voor scope, aangezien atomaire indicatoren over het algemeen goed worden bediend door exact-match workflows en het huidige protocol zich richt op variabele-structuur IOC's die profiteren van regexgeneralisatie; het beperkt de toepasbaarheid echter tot IOC-types die momenteel niet in de grafiek worden weergegeven. Ten tweede vallen huidige faalscenario's in drie hoofdcategorieën: niet-native paden of commandoregelargumenten die afwezig zijn in de besturingssysteemgraaf, onvolledige grafiekdekking voor relevante hulpprogramma's of structuren, en onvolledigheid in de CTI-bron zelf wanneer belangrijke commandofragmenten of cmdlets nooit worden gerapporteerd. Ten derde meet de cross-IOC mismatch-metriek die in de referentie-evaluatie wordt gebruikt de semantische specificiteit van gegenereerde regexes in plaats van end-to-end waarschuwingsvalse positieven onder de geïmplementeerde SIEM-logica.

Reproduceerbaarheid onder LLM-variabiliteit en versiebeheer. Omdat de IOC-extractie- en regex-generatiefasen afhankelijk zijn van commerciële LLM-eindpunten, beïnvloeden twee bronnen van variabiliteit de reproduceerbaarheid: updates aan provider-side modelupdates in de loop van de tijd en stochasticiteit van per-call samples. Om het eerste te beperken, registreren alle LLM-gerelateerde velden in de Materials Table exacte modelidentificaties en de toegangsdatum die in de referentie-evaluatie is gebruikt, en het protocol raadt aan om het aan een specifieke modelsnapshot vast te pinnen telkens wanneer de aanbieder er een blootstelt. Om het tweede te beperken, fixeert de referentie-implementatie de IOC-extractietemperatuur op 0,0 en gebruikt een niet-nul temperatuur alleen in de regex-generatiefase, waar ensemble voting en deterministische validators in Fasen 2 en 5 residuele variatie absorberen. Bij het repliceren van deze resultaten moeten gebruikers de exacte modelversie, toegangsdatum, temperatuur en gebruikte ensemblestemdrempel noteren; Er moet worden verwacht dat wezenlijke afwijkingen op een van deze assen de hit-rate- en mismatch-metrics verschuiven.

Verschillende herstelbare faalmodi kunnen worden aangepakt op het niveau van het stadium dat ze heeft veroorzaakt. Fase 1 parsing fouten (bijvoorbeeld gescande PDF's die lege of vervormde Markdown opleveren): de invoer vooraf verwerken met optische tekenherkenning of een externe converter voordat het opnieuw wordt geüpload; Controleer dat het aantal geanalyseerde secties en het totale aantal tekens niet nul zijn voordat u verder gaat. Fase 2 extractiefouten (geen IOC's teruggegeven, of hallucinatie-items): verhoog de ensemble-stemdrempel (Min Votes ≥ 2), schakel extra modelinstanties in, of verlaag de LLM-temperatuur; verifieer de API-connectiviteit en dat het geconfigureerde model JSON-geformatteerde output accepteert. Normalisatie van fase 4 met volledig verwijderde labels (elke IOC-component wordt gelabeld als afdanken): uitbreiding van de Neo4j-referentiegraaf met leveranciers- of omgevingsspecifieke padcomponenten en registerwortels; de Cypher-importscripts en de keep/discard-beslissingsregel staan vermeld in Supplementary File 2. Fase 5 regex-fouten (used_fallback = waar, of herhaalde afwijzingen van verwijdering-validatie): inspecteer het per-IOC optimalisatiegeschiedenisveld om de falende validator te identificeren; als het IOC echt geen stabiele keep-componenten heeft, overweeg dan handmatig regex authoring voor die IOC of het uit te sluiten van geautomatiseerde regelgeneratie terwijl het in de gecategoriseerde IOC-tabel wordt behouden voor analistenbeoordeling.

In overeenstemming met bovenstaande beperkingen worden de gegenereerde regexen het beste behandeld als herbruikbare zoekprimitieven binnen bredere SOC-detectie-inhoud, in plaats van als zelfvoorzienende detectoren. In operationele omgevingen kunnen analisten deze combineren met platformspecifieke veldlogica, whitelists, herkomstcontroles of correlatievoorwaarden om onschuldige matches te onderdrukken die ontstaan uit ongebruikelijke maar niet-kwaadaardige paden.

Toekomstig werk kan bestaan uit systematische vergelijking met door mensen geschreven regexes, bredere evaluatie over aanvullende IOC-categorieën, gestructureerde feedbackstudies van analisten, uitgebreide grafiekdekking voor door aanvallers gemaakte nutsprogramma's en cmdlets, en een uitgebreidere rapportage van end-to-end latentie en kosten in de implementatieinstellingen. Desalniettemin biedt het huidige protocol een reproduceerbaar en operationeel interpreteerbaar kader voor IOC-naar-regex vertaling, dat zowel de sterke punten als de huidige beperkingen documenteert.

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.