Un flusso di lavoro strutturato per trasformare l'intelligence delle minacce informatiche in modelli di rilevamento calcolabili

Sommario

Qui presentiamo un protocollo per convertire indicatori di compromissione dai percorsi dei file dei report di intelligence informatica, chiavi di registro e indicatori della riga di comando in espressioni regolari validate per regole di rilevamento di sicurezza delle informazioni ed eventi (SIEM), utilizzando l'estrazione di ensemble con grandi modelli linguistici (LLM) e l'etichettatura dei componenti assistita da grafi.

Abstract

I Security Operations Center (SOC) convertono regolarmente i report di intelligence sulle minacce informatiche (CTI) in contenuti di rilevamento operativo. Un collo di bottiglia persistente in questo flusso di lavoro è la traduzione degli indicatori estratti di compromissione (IOC), in particolare percorsi di file, chiavi di registro e stringhe da riga di comando, in espressioni regolari (regex) deployabili adatte all'incorporamento nelle regole di correlazione per la sicurezza delle informazioni e della gestione degli eventi (SIEM). Sebbene lavori precedenti abbiano migliorato l'estrazione automatica tramite indicatore di compromesso (IOC), trasformare le stringhe estratte in pattern regex validati rimane in gran parte manuale, richiede competenze specializzate ed è soggetto a errori. L'obiettivo di questo protocollo è fornire una procedura standardizzata e riproducibile per la traduzione da IOC a regex. Il flusso di lavoro comprende cinque fasi: (1) parsing report CTI eterogenei in una rappresentazione Markdown unificata; (2) estrazione IOC utilizzando molteplici grandi modelli linguistici (LLM) con voto di consenso; (3) normalizzazione, categorizzazione e deduplicazione basate su regole degli IOC estratti; (4) etichettatura assistita da grafo dei componenti IOC come keep (gruppo di cattura) o scartato (gruppo non di cattura); e (5) generazione iterativa di regex con validazione diagnostica rispetto alle stringhe IOC originali. Per valutare l'utilità, il flusso di lavoro è stato applicato a 3.156 report CTI, e i regex risultanti sono stati valutati rispetto a oltre 2.400 stringhe di verità sul campo raccolte indipendentemente da dieci scenari MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK) Evaluation, ottenendo un tasso medio di successo del 99,1% e un tasso medio di disallineamento tra l'IOC dello 0,8%. Il protocollo documenta quindi un'implementazione riproducibile per la traduzione IOC-to-regex e ne delinea esplicitamente l'ambito attuale, le assunzioni operative e i casi di guasto noti.

Introduzione

Il cybercrimine continua a imporre oneri operativi e finanziari sostanziali alle organizzazioni del settore pubblico e privato. Nel 2023, le perdite segnalate dovute alla criminalità informatica negli Stati Uniti hanno superato i 12,5 miliardi di^dollari, evidenziando la portata e la persistenza delle attività dannose. In questo contesto, i Security Operations Center (SOC) fungono da unità operative principali responsabili di rilevare, analizzare e rispondere alle minacce in tempo reale.
La logica di rilevamento in molti flussi di lavoro SOC è implementata tramite meccanismi basati su regole all'interno delle piattaforme di Security Information and Event Management (SIEM), ampiamente utilizzate perché interpretabili, deterministiche e compatibili con i flussi di lavoro SOC esistenti. Tra i diversi tipi di regole, le regole SIEM basate sulla correlazione sono particolarmente importanti per identificare comportamenti di attacco che coprono più eventi, host e finestre temporali. All'interno di queste regole, le espressioni regolari (regex) funzionano come primitive di ricerca riutilizzabile: gli analisti le inseriscono in regole di rilevamento più ampie che aggiungono vincoli di campo, filtri specifici per piattaforma e logica di correlazione eventi, invece di distribuirli come rivelatori autonomi.

In pratica, gli analisti SOC spesso iniziano lo sviluppo delle regole con indicatori di compromissione (IOC) derivati dai rapporti di cyber threat intelligence (CTI) pubblicati da fornitori di sicurezza, ricercatori indipendenti o basi di conoscenza pubbliche come MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK⁾². Queste stringhe IOC possono includere percorsi di file, frammenti di riga di comando, chiavi di registro o altri artefatti strutturati osservati durante gli^{attacchi 3}. Tradurre tali stringhe in pattern regex adatti alle regole di correlazione SIEM è un compito ricorrente nel flusso di lavoro di authoring delle regole.

Questo passaggio di traduzione rappresenta un collo di bottiglia operativo pratico. Creare pattern regex abbastanza generali da catturare variazioni significative ma abbastanza precisi da evitare abbinamenti indesiderati richiede competenze specializzate; piccoli errori sintattici o decisioni errate su quali componenti preservare o generalizzare possono rendere inefficace una regola di rilevamento altrimenti utile. Poiché questo lavoro è manuale, ripetitivo e orientato ai dettagli, può ritardare il dispiegamento del rilevamento per minacce emergenti, richiedere revisione da parte di analisti più esperti e contribuire al carico di lavoro degli analisti nelle impostazioni SOC^{operative 4,5}.

La sfida centrale nella traduzione IOC-regex è decidere quali parti di un IOC codificano un comportamento stabile e rilevante per l'attaccante e quindi debbano essere preservate, e quali parti riflettono variazioni specifiche per ambiente o host e dovrebbero essere generalizzate. Ad esempio, le radici canoniche del registro come HKEY_CLASSES_ROOT\CLSID, le directory di sistema come System32 e i nomi eseguibili noti come rundll32.exe devono tipicamente rimanere espliciti, mentre i percorsi dei profili utente, gli Identificatori di Sicurezza specifici per host (SID) e gli Identificatori Globalmente Unici (GUID) dovrebbero normalmente essere astratti. Fare questo in modo coerente tra tipi eterogenei di IOC è ciò che rende il compito di traduzione non banale. In tutto questo protocollo, ci riferiamo ai primi come componenti preservati o di gruppo di cattura, e ai secondi come componenti astratti o non di gruppo di cattura.

Lavori precedenti hanno esplorato l'estrazione automatizzata di intelligence sulle minacce da testi non strutturati utilizzando tecniche di elaborazione del linguaggio naturale e estrazione^{di entità 6,7}. Più recentemente, diversi studi hanno indagato la generazione diretta di regole di rilevamento a partire dai report CTI utilizzando grandi modelli linguistici (LLM⁾⁸. Questi approcci dimostrano che parti del flusso di lavoro di authoring delle regole possono essere supportate da modelli di linguaggio, ma di solito non si concentrano sul problema operativo specifico di generare pattern regex che preservino la semantica dei gruppi di cattura e rimangono adatti per la distribuzione successiva di SIEM. Linee di lavoro complementari hanno strutturato contenuti CTI per l'uso a valle in modi diversi, inclusi rappresentazioni basate su grafi di conoscenza come TINKER⁹ e generazione guidata da CTI di query di ricerca di log come ThreatRaptor¹⁰, che convertono CTI non strutturati in linguaggi di conoscenza strutturata o di query specifici per dominio invece che in pattern regex destinati all'incorporamento nelle regole di correlazione SIEM.

Parallelamente, studi precedenti hanno esplorato la sintesi automatica di regex utilizzando metodi basati su esempi, traduzione neurale e approcci generate-and-repair 11,12,13,14,15,16. Tuttavia, questi metodi sono generalmente progettati per contesti che si basano su ampi insiemi di esempi rappresentativi o descrizioni in linguaggio naturale piuttosto che su contesti di rilevamento guidati dall'IOC. Nei flussi di lavoro SOC, le stringhe IOC sono spesso scarse, strutturalmente eterogenee e strettamente legate alla semantica operativa. Questa discrepanza motiva un flusso di lavoro pensato per la traduzione IOC-regex piuttosto che l'affermazione che i metodi esistenti di generazione regex siano ampiamente inadeguati.

Il protocollo presentato qui si concentra specificamente sulla fase di traduzione IOC-re-regex del flusso di lavoro di rilevamento SOC. L'estrazione IOC è trattata come un input a monte che può derivare da analisi manuale, strumenti automatizzati o una combinazione di entrambi; il protocollo non tenta di generare regole SIEM complete. Al contrario, fornisce una procedura sistematica per convertire le stringhe IOC in pattern regex sintatticamente validi, semanticamente interpretabili e adatti al deployment operativo. L'attuale ambito IOC è deliberato: i percorsi dei file, le chiavi di registro e gli indicatori a riga di comando contengono sia componenti strutturali stabili che variabili beneficiano della generalizzazione regex, mentre indicatori atomici come indirizzi IP, domini e hash sono più naturalmente operativi tramite condizioni di corrispondenza esatta o ricerche in stile reputazione e quindi escono dall'ambito primario. All'interno di questi limiti, il protocollo è pensato per essere portatile su ambienti SOC che condividono formati di input e precondizioni degli strumenti comparabili.

Protocollo

Utilizzare il seguente flusso di lavoro in cinque fasi per trasformare un report CTI in pattern regex validati con output intermedi tracciabili (vedi Figura 1 per una panoramica).

1. Configurazione del sistema

1. Requisiti per l'installazione.
   1. Installa Python 3.8 o successivo, tutte le dipendenze Python elencate in requirements.txt e un database di grafi Neo4j.
      1. Conferma l'accesso a una o più interfacce di programmazione applicativa (API) per i grandi modelli linguistici scelti e verifica che il servizio Neo4j sia in esecuzione e raggiungibile dalla macchina locale.
   2. Conferma che la Tabella dei Materiali sia completa.
      1. Verifica che siano elencate le dipendenze in runtime, inclusa la versione dell'interprete Python, le dipendenze della pipeline, la versione Neo4j e il backend di estrazione testuale Portable Document Format (PDF).
      2. Verifica che siano elencate le opzioni di configurazione degli LLM, inclusi i fornitori di LLM, nomi e versioni dei modelli, temperatura, opzioni di ragionamento e impostazioni di voto per l'ensemble.
      3. Verifica che i formati di input e output siano elencati, inclusi i formati di file di input supportati e i formati di esportazione supportati.
2. Avvia l'interfaccia utente web (UI).
   1. Apri un terminale, naviga alla directory radice di riferimento e implementazione e avvia l'applicazione usando il comando di avvio documentato (nell'implementazione di riferimento: cd langchain_pipeline seguito da streamlit run app_v2.py).
   2. Verifica che l'applicazione si carichi a http://localhost:8501 e che il pannello di configurazione della barra laterale sia visibile.
3. Configura il provider LLM.
   1. Nella sezione Configurazione LLM della barra laterale, seleziona un provider LLM, inserisci il nome del modello e fornisci una chiave valida dell'interfaccia di programmazione applicativa (API).
   2. Annota il fornitore, il nome del modello, la versione del modello, la temperatura, le opzioni di ragionamento e la data di accesso per la Tabella dei Materiali.
      NOTA. Nell'implementazione di riferimento, l'estrazione IOC a singolo LLM si basa sul LLM commerciale primario elencato nella Tabella dei Materiali con temperatura = 0,0; La generazione regex è predefinita a temperatura = 0,3.
4. Abilita il voto d'ensemble (opzionale ma consigliato per risultati riproducibili).
   1. Abilita l'opzione Votazione Ensemble nella barra laterale per mantenere solo gli IOC che soddisfano una soglia minima di voto (Min Votes ≥ 2 raccomandati).
   2. Aggiungi ulteriori istanze LLM specificando provider, nome del modello, chiave API e numero di ripetizioni di esecuzione per modello.
      1. Annota il conteggio delle ripetizioni di ciascun fornitore e la soglia minima di voto selezionata.
         NOTA. Il voto d'ensemble è opzionale. Quando disabilitato, la pipeline esegue l'estrazione single-LLM e il filtro di consenso viene saltato. Le impostazioni predefinite dell'ensemble sono ripetizioni = 1 per modello configurato e min_votes = 2.
5. Collegati a Neo4j.
   1. Nella sezione Connessione Neo4j della barra laterale, inserisci l'URI di connessione (ad esempio, bolt://localhost:7687), il nome utente e la password.
   2. Conferma che l'interfaccia segnali una connessione riuscita. Non procedere senza una connessione attiva.
6. Proteggi tutte le credenziali.
   1. Considera le chiavi API LLM e la password Neo4j come credenziali sensibili. Memorizzali nelle variabili dell'ambiente o in un gestore di segreti invece che in file sorgente, report esportati o screenshot, e ruota rapidamente qualsiasi chiave se si sospetta una fuga di notizie.
      NOTA. Questo protocollo software non richiede una cappa per i fumi chimici, un armadietto di biosicurezza o altre apparecchiature di contenimento fisico; gestire rapporti e credenziali CTI riservati secondo le politiche istituzionali di sicurezza dei dati.

2. Fase 1: analisi dei documenti

1. Procedura.
   1. Naviga nella scheda Processing nell'interfaccia principale.
   2. Carica un report CTI in un formato supportato (.pdf, .docx, .md, .txt o .html).
   3. Clicca su "Run Next Stage" per eseguire la Fase 1, oppure su "Run All Stages" per eseguire l'intera pipeline in sequenza.
2. Conferma il checkpoint di Fase 1.
   1. Conferma che sia visualizzata un'anteprima Markdown del documento di input.
   2. Verifica che i percorsi dei file, le chiavi del registro, i frammenti della riga di comando e i confini delle sezioni rimangano intatti nell'anteprima.
   3. Se le stringhe tecniche vengono troncate o la formattazione viene eliminata, correggere il file sorgente o pre-elaborare il documento con un convertitore esterno prima di ricaricarlo.

3. Fase 2: estrazione IOC

1. Procedura.
   1. Conferma la configurazione dell'LLM (e il voto dell'ensemble, se abilitato).
   2. Clicca su "Esegui la fase successiva" per eseguire la fase 2.
2. Conferma il checkpoint di Fase 2.
   1. Conferma che l'interfaccia visualizzi una collezione IOC in formato JavaScript Object Notation (JSON) con tre chiavi di primo livello: File Paths, Command Lines e Registry Keys.
   2. Quando il voto in ensemble è abilitato, verifica che i conteggi dei voti e i metadati del modello contributivo siano registrati per ogni IOC conservato.
      NOTA. Il sistema letterale della Fase 2 e i prompt umani, insieme ai prompt di generazione e ottimizzazione della Fase 5, vengono rilasciati come File Supplementare 1 (Supplemental_File_1_Prompts.txt).

4. Fase 3: analisi e classificazione dell'IOC

1. Procedura.
   1. Clicca su "Esegui Fase Successiva" per eseguire la Fase 3.
2. Conferma il checkpoint di Fase 3.
   1. Conferma che ogni IOC conservato sia elencato con una categoria standardizzata, un tag sorgente e la chiave di estrazione originale quando disponibile.

5. Fase 4: Normalizzazione IOC assistita da Neo4j

1. Procedura.
   1. Conferma che la connessione Neo4j sia attiva.
   2. Clicca su "Run Next Stage" per eseguire la Fase 4.
   3. Ispezionare l'output di normalizzazione per ogni IOC e verificare che siano prodotte etichette di mantenimento/scarto per i componenti di percorso e di riga di comando e che le chiavi di registro producano una sottostringa canonica contigua.
2. Conferma il checkpoint della Fase 4.
   1. Conferma che le tabelle IOC normalizzate siano prodotte per ogni tipo di IOC (percorsi di file, chiavi di registro, indicatori a riga di comando).
   2. Verifica che ogni voce includa il valore originale, il valore normalizzato e una lista di componenti di coppie elemento/stato etichettate keep o discard.
      NOTA. Schema dettagliato di Neo4j, query Cypher, regole decisionali e la procedura di normalizzazione della chiave di registro sono elencati nel File Supplementare 2; un esempio lavorato è fornito nei Risultati Rappresentativi.

6. Fase 5: generazione e punteggio regex

1. Procedura.
   1. Clicca su "Esegui Fase Successiva" per eseguire la Fase 5. Confermare che ogni IOC normalizzato e la sua lista di token proibiti siano stati inviati per la generazione di regex e la validazione deterministica.
   2. Se un candidato non supera la validazione, si permette al ciclo di ottimizzazione di perfezionare il regex fino a quando non viene prodotto un candidato conforme o fino a raggiungere il limite di iterazione.
   3. Ispezionare l'output diagnostico, la cronologia di ottimizzazione e i conteggi delle iterazioni per qualsiasi IOC il cui regex finale scende da conforme a corrispondenza parziale con punteggio più alto (registrato come used_fallback = Vero).
2. Conferma il checkpoint di Stage 5.
   1. Conferma che venga prodotto un regex finale per ogni IOC conservato.
   2. Verifica che i punteggi dei candidati, le storie di ottimizzazione, le liste dei problemi e il conteggio delle iterazioni siano registrati.
   3. Verifica che la telemetria per IOC, inclusa stima dell'uso e della latenza del token, sia registrata.
      NOTA. Le regole dettagliate di validazione regex, la formula di punteggio e i parametri di controllo delle iterazioni sono elencati nel File Supplementare 2.

7. Analisi e validazione

1. Apri la scheda Analytics per esaminare le distribuzioni IOC, i risultati del voto in ensemble (quando abilitati), i riassunti di qualità regex e le statistiche di ottimizzazione. Utilizzare questi riassunti per rilevare anomalie come squilibri di estrazione o fallimenti di ottimizzazione ripetuti.

8. Risultati delle esportazioni

1. Nella scheda Esporta, seleziona il formato di esportazione (testo semplice, JSON o YAML) e scarica il set regex. Conferma che i regex esportati includano i punteggi associati e i metadati di categorizzazione.
2. Genera e scarica il report JSON completo contenente documenti analizzati, IOC estratti, rappresentazioni normalizzate, regex candidati e output finali. Conserva questo rapporto come un registro di riproducibilità.

9. Risoluzione dei problemi

1. Se la Fase 1 restituisce contenuti PDF troncati o vuoti, pre-elabora il documento con un convertitore esterno o uno strumento di riconoscimento ottico dei caratteri prima di ricaricarlo e conferma che gli artefatti tecnici rimangano visibili nell'anteprima Markdown.
2. Se la Fase 2 restituisce troppo pochi IOC consensuali, verifica le impostazioni del provider, del modello, della chiave API, del conteggio ripetuto e dei voti minimi prima di cambiare la soglia. Ispezionare i candidati esclusi per distinguere le allucinazioni dal voto eccessivamente rigido.
3. Se la fase 4 etichetta tutti i componenti come scartati, verifica la connettività Neo4j e conferma che il grafo contenga il vocabolario pertinente di Path, Registry o interfaccia da riga di comando (CLI) per il tipo IOC analizzato.
4. Se la fase 5 produce un regex che compila ma non corrisponde o generalizza eccessivamente, si ispeziona la cronologia di ottimizzazione, la posizione diagnostica di guasto e i controlli di ipergeneralizzazione prima di rigenerare il candidato.

10. Confermare gli output finali del protocollo.

1. Conferma che il file Markdown analizzato, l'insieme IOC (validato per consenso quando il voto in ensemble è abilitato, o modello singolo quando disabilitato), la tabella IOC categorizzata e le rappresentazioni IOC normalizzate a grafi sono tutti presenti.
2. Conferma che il set regex compatibile con SIEM, i riassunti analitici e il report JSON completo siano tutti presenti, e archivia il report JSON come record di riproducibilità.

Risultati

Questa sezione presenta i risultati rappresentativi prodotti dal protocollo IOC-to-regex e riassume la valutazione di riferimento utilizzata per valutarne l'applicabilità operativa. La valutazione di riferimento ha elaborato 3.156 rapporti CTI associati alle tecniche MITRE ATT&CK, analizzato più di 230.000 frasi, estratto più di 63.000 candidati IOC e valutato regex generati rispetto a più di 2.400 stringhe di accuratezza sul terreno raccolte indipendentemente da dieci scenari di valutazione MITRE ATT&CK. Queste stringhe di verità sul terreno sono artefatti di attacco curati da esperti, riportati indipendentemente dai fornitori di cybersecurity durante gli esercizi di valutazione MITRE ATT&CK e quindi riflettono i modelli strutturali che analisti umani e fornitori documentano nella pratica. I risultati seguenti si concentrano sul comportamento dei flussi di lavoro, sulla correttezza strutturale e sugli esiti di valutazione rilevanti per l'analisi operativa dei log e i flussi di lavoro di rilevamento.

Una panoramica della pipeline end-to-end è fornita nella Figura 1, che riassume le fasi di ricerca del gruppo di cattura e generazione regex che incorniciano il resto dei risultati rappresentativi.

Fase 1: Output di analisi del documento

La Figura 2 mostra l'output della Fase 1, in cui un rapporto CTI in input viene analizzato in una rappresentazione Markdown unificata. Una volta eseguita con successo, l'interfaccia mostra un'anteprima strutturata del documento, inclusi i confini delle sezioni e gli indicatori di rilevanza.

La corretta esecuzione è indicata da segmentazioni coerenti dei paragrafi e dalla conservazione di artefatti tecnici come percorsi di file, chiavi di registro e frammenti della riga di comando. Un eccessivo troncamento o la perdita di formattazione in questa fase possono influire sull'analisi a valle e dovrebbero essere affrontate prima di procedere.

Fase 2: Estrazione IOC basata sul consenso

La Figura 3 illustra l'output della Fase 2, dove i candidati IOC vengono estratti utilizzando il voto multi-LLM ensemble. L'interfaccia risultante presenta una collezione IOC in formato JSON annotata con conteggi dei voti e modelli che contribuiscono a tutto.

Vengono mantenuti solo gli IOC che soddisfano la soglia minima di consenso configurata. Gli IOC esclusi a questa fase tipicamente riflettono allucinazioni specifiche del modello o frammenti di testo ambigui. La loro esclusione è un esito atteso e auspicabile, indicando che il voto d'ensemble sta funzionando correttamente.

Fase 3: Analisi e classificazione dell'IOC

La Tabella 2 riassume l'output atteso, i passaggi di validazione automatica e i controlli di controllo qualità rivolti agli analisti per ogni fase del protocollo.

La Figura 4 mostra i candidati IOC che non hanno raggiunto la soglia di consenso durante il voto dell'ensemble alla Fase 2 e che l'interfaccia emerge per l'ispezione da parte degli analisti. Tali candidati tipicamente riflettono allucinazioni specifiche del modello o frammenti di testo ambigui. La Figura 4 e la Figura 5 quindi corrispondono a uscite di stadi distinte — il set scartato dalla Fase 2 e il set conservato dalla Fase 3 — piuttosto che a vedute alternative dello stesso processo della Fase 3.

La Figura 5 presenta la tabella IOC conservata prodotta dalla Fase 3 dopo il parsing JSON, la categorizzazione basata su regole e la deduplicazione IOC. Per ogni IOC trattenuto, lo stadio registra una categoria standardizzata, un tag sorgente e la chiave di estrazione originale quando disponibile, prima di passare l'IOC alla normalizzazione a valle.

Fase 4: Normalizzazione IOC assistita da grafo tra i tipi di IOC

Le Figure 6, Figura 7 e Figura 8 illustrano i risultati di normalizzazione rappresentativa per tre categorie IOC affrontate nello studio attuale: percorsi dei file, chiavi del registro e indicatori a riga di comando. Per ciascuna categoria, le figure confrontano l'IOC originale estratto dal rapporto CTI con la rappresentazione normalizzata prodotta tramite analisi assistita da grafi.

In tutti i tipi di IOC, il protocollo decompone ogni IOC in componenti semantiche e risolve le relazioni gerarchiche utilizzando conoscenze strutturate codificate nel database dei grafi. Nell'implementazione attuale, Neo4j memorizza nodi normalizzati Path, Registry e CLI e utilizza relazioni di adiacenza per testare se i componenti appartengono a catene riconosciute. Questo ruolo è analogo all'uso della conoscenza strutturata di ATT&CK durante l'ingegneria di^{rilevamento 2}.

È importante notare che questo passaggio di normalizzazione registra i ruoli espliciti dei componenti IOC etichettandoli come keep o scard, piuttosto che rimuoverli silenziosamente dal record di analisi. La stringa normalizzata viene ricostruita principalmente dai componenti di mantenimento, mentre i componenti di scartato rimangono disponibili come metadati per la generazione e validazione a valle di regex.

La corretta esecuzione di questa fase è indicata da IOC normalizzate che mantengono un contesto strutturale significativo e mostrano un'etichettatura coerente del gruppo di cattura tra diversi tipi di IOC. Il confronto visivo tra rappresentazioni originali e normalizzate fornisce un meccanismo pratico di controllo qualità per verificare che la risoluzione del gruppo di cattura sia stata applicata in modo coerente e senza perdite indesiderate di informazioni.

Fase 5: Generazione di espressioni regolari con selezione ausiliaria basata su vincoli

La Figura 9 illustra l'output della Fase 5, dove il protocollo genera espressioni regolari strutturalmente conformi da IOC normalizzati attraverso un flusso di lavoro di validazione iterativo. L'implementazione combina un prompt di generazione iniziale, un re-prompting diagnostico quando un candidato non corrisponde all'IOC, la validazione consapevole dello scarico e i loop di ritentativo limitati.

Dato un IOC normalizzato e la relativa specifica di componente keep/discard, il flusso di lavoro genera innanzitutto un candidato regex iniziale. Il candidato viene poi testato rispetto all'IOC, riproposto diagnosticamente quando l'abbinamento fallisce, controllato per token scartati proibiti e valutato per sovrageneralizzazione usando stringhe negative casuali.

Quando più candidati soddisfano i controlli di validazione di base, il protocollo applica un meccanismo ausiliario di selezione basato su vincoli per mantenere un regex rappresentativo per l'uso a valle. L'implementazione attuale assegna ai candidati il punteggio con 'Score = n_cg - n_wc', dove 'n_cg' è il numero di componenti di keep rappresentati e 'n_wc' è il numero di token scartati o non mappati presenti nel regex.

La funzione di selezione è definita come:

Punteggio = n_cg − n_wc

Questa è la specializzazione a peso uguale (α = β = 1) della forma più generale Score = α·n_cg − β·n_wc. Qui, n_cg indica il numero di componenti di keep rappresentati e n_wc indica il numero di componenti di scarto o token extra non mappati reintrodotti dal regex. L'implementazione registra anche il conteggio delle iterazioni, le liste di emissione, il consumo stimato dei token, l'uso della cache e la telemetria della latenza per ogni IOC. L'impostazione a peso uguale veniva usata come semplice impostazione deterministica per l'implementazione di riferimento; Poiché considera ugualmente indesiderabili un componente di keep mangente e uno reintrodotto di scarto, possono essere preferiti altri pesi in contesti di distribuzione dove falsi negativi e falsi positivi comportano costi operativi differenti.

Il regex finale viene selezionato come il candidato che meglio soddisfa questi vincoli. Le regex che inseriscono componenti di gruppo di cattura richieste all'interno di costrutti opzionali, ad esempio ( ... )?, sono escluse dalla selezione perché indeboliscono la coerenza semantica. Questo passaggio di selezione è ausiliario al processo di generazione e non è inteso come una metrica di qualità autonoma.

Panoramica dell'analisi dell'elaborazione CTI

La Figura 10 fornisce una panoramica degli esiti dell'analisi CTI su tutti i documenti elaborati. Nella valutazione dei riferimenti, l'estrazione IOC di oltre 3.156 rapporti CTI ha prodotto più di 63.000 candidati IOC, inclusi 12.195 percorsi di file, 2.302 chiavi di registro e 10.286 indicatori a riga di comando, con i restanti candidati appartenenti a tipi IOC non regex-target.

Questi conteggi forniscono una validazione di alto livello che gli indicatori estratti sono concentrati nelle tre categorie IOC target dal protocollo attuale, mostrando anche che molti artefatti estratti rimangono fuori dall'ambito di generazione regex. Quando si riproduce il flusso di lavoro, si riporta il numero esatto di report CTI elaborati, il totale dei candidati IOC, i conteggi per categorie e il fornitore, modello, versione del modello, temperatura, conteggio delle ripetizioni e soglia di consenso utilizzata durante l'estrazione.

Nella valutazione di riferimento, i regex generati sono stati valutati rispetto a oltre 2.400 stringhe di accuratezza sul campo raccolte indipendentemente da dieci scenari di valutazione MITRE ATT&CK e hanno raggiunto un tasso medio di successo del 99,1% insieme a un tasso medio di disallineamento tra l'IOC dello 0,8%. In questo manoscritto, il tasso di disadattamento è utilizzato come misura di specificità semantica: un disadattamento si verifica quando un regex generato per un IOC corrisponde anche a una stringa di verità sul campo associata a un diverso IOC. Questa quantità non deve essere interpretata come un tasso di allerta operativo end-to-end di falsi positivi, che dipende anche dalla logica delle regole a valle e dal contesto di implementazione.

La distribuzione riflette la composizione strutturale del corpus CTI e permette agli utenti di verificare che gli indicatori estratti siano in linea con i tipi previsti di IOC. Grandi deviazioni dalle proporzioni previste possono indicare problemi di parsing o estrazione a monte e dovrebbero essere esaminate prima di procedere con la normalizzazione a valle e la generazione di regex.

Analisi delle azioni di ottimizzazione Regex

La Figura 11 riassume le azioni effettuate durante la generazione e il raffinamento delle espressioni regolari. La distribuzione include tre tipi di azioni: generazione iniziale di regex, passaggi di ottimizzazione guidati da LLM e rigenerazione basata su ritentativi.

L'ottimizzazione guidata dall'LLM rappresenta il 51,7% di tutte le azioni osservate. Questa prevalenza indica che la sola generazione iniziale è spesso insufficiente per produrre regex che soddisfino i vincoli del gruppo di cattura e i requisiti di esclusione. Invece, l'ottimizzazione iterativa viene applicata attivamente e ripetutamente per perfezionare i regex candidati.

Piuttosto che riflettere inefficienza, questa distribuzione dimostra che il flusso di lavoro di ottimizzazione è una componente necessaria e integrante del protocollo nella generazione di regex strutturalmente conformi da input IOC complessi.

Una caratterizzazione separata della scalabilità su un campione casuale di 6.000 IOC generati con l'LLM per il test di scalabilità (vedi la Tabella dei Materiali) ha riportato una latenza mediana di 2,95 s per IOC e una latenza media di 23,18 s. Nella stessa caratterizzazione, la compilazione regex sintatticamente valida ha raggiunto il 99,56%, il successo complessivo della generazione ha raggiunto il 99,4 %, l'uso medio stimato dei token era di circa 3.986 token per IOC e il flusso di lavoro richiedeva in media circa 7,89 chiamate LLM per IOC. I tassi di successo al primo passaggio erano del 56,46% per il ciclo match-debug e del 72,92% per il ciclo di validazione non cattura-gruppo. Queste misurazioni aiutano a caratterizzare il costo computazionale e la capacità operativa per l'uso in batch.

Nessuna revisione esperta di un sottoinsieme di output campionato è stata utilizzata per il ritraining del modello nella caratterizzazione di riferimento attuale; I risultati riportati riflettono l'esecuzione automatica delle pipeline e i dataset di valutazione a valle descritti sopra.

Prove operative e gestione dei guasti. La Figura 12 mostra la struttura del file regolare SIEM esportato prodotto dal protocollo, insieme a prove di validazione a livello di regola per i pattern rappresentativi di percorso file, chiave di registro e riga di comando. La Figura 13 mostra il corrispondente report JSON completo, che espone tutti gli output degli stadi (IOC estratti, analizzati e normalizzati insieme ai pattern regex generati e ai flag di validazione per IOC) ed è l'artefatto principale che gli strumenti a valle consumano. La Figura 14 illustra la gestione da parte del protocollo di un input CTI rumoroso: un percorso file defanged e perturbato dallo spazio bianco viene segnalato nella fase di analisi, corretto, normalizzato al modello canonico %TEMP% e poi convertito in un regex compilante e corrispondente. Questo esempio funzionante integra le prove operative in Figura 12 e Figura 13 documentando come si comporta il protocollo quando il testo grezzo dell'IOC si discosta dalla forma canonica.

Figura 1: Architettura complessiva del protocollo IOC-to-regex. La figura riassume la pipeline end-to-end. Le stringhe IOC candidate prodotte dall'estrattore IOC a monte vengono scomposte e confrontate con i nodi di riferimento in un grafo Neo4j popolato dalla documentazione Windows (passo 1), che recupera i componenti noti del percorso, del registro e della riga di comando (passo 2). I frammenti variabili o specifici per ambiente sono etichettati come scartati ed esclusi dalla ricostruzione normalizzata mentre sono mantenuti nei metadati dei componenti, producendo un IOC normalizzato con etichette di mantenimento e scarico a livello di componente (passo 3). Questi IOC normalizzati vengono poi passati a una fase di generazione regex basata su LLM (step 4) che produce espressioni regolari candidate, che vengono punteggiate e ottimizzate iterativamente rispetto ai vincoli del gruppo di cattura e alle regole dei token scartati (step 5) prima che venga selezionato un regex finale (step 6). Clicca qui per visualizzare una versione più grande di questa figura.

Figura 2: Fase 1 dell'analisi del risultato del documento. Confronto affiancato tra il rapporto CTI originale e l'anteprima del documento analizzato. Il pannello sinistro mostra il report CTI originale in formato PDF, mentre il pannello destro mostra la rappresentazione unificata di Markdown generata dal parser. Clicca qui per visualizzare una versione più grande di questa figura.

Figura 3: Estrazione IOC basata sul consenso utilizzando il voto multi-LLM ensemble. L'interfaccia illustra il processo di estrazione IOC basato su ensemble e i suoi risultati intermedi. La casella rossa evidenzia le istanze LLM configurate che partecipano all'estrazione IOC, inclusi i provider selezionati e il numero di esecuzioni di estrazione ripetute effettuate per ciascun modello. La casella blu indica la soglia di consenso definita dall'utente, che specifica il numero minimo di occorrenze richiesto affinché un IOC venga mantenuto. Dopo aver aggregato i risultati di estrazione su tutti i modelli e le ripetizioni, vengono scartati gli IOC candidati che appaiono meno volte della soglia di soglia (IOC). La casella arancione mostra l'ultimo insieme di IOC conservati che soddisfano il criterio di consenso e vengono passati alle fasi di analisi a valle. Clicca qui per visualizzare una versione più grande di questa figura.

Figura 4: CIO scartati tramite voto d'ensemble alla Fase 2. Vista fianco a fianco dei candidati del CIO che non hanno raggiunto la soglia minima di voto configurata durante il voto in ensemble e vengono mostrati per l'ispezione da parte degli analisti. I candidati scartati tipicamente riflettono allucinazioni specifiche del modello o frammenti di testo ambigui e non vengono passati alla fase di categorizzazione della Fase 3. Clicca qui per visualizzare una versione più grande di questa figura.

Figura 5: Insieme IOC conservato con classificazione standardizzata. I candidati IOC mantenuti dopo l'elaborazione della Fase 3 sono mostrati insieme alle loro categorie standardizzate, tag di origine e chiavi di estrazione originali quando disponibili. Questa tabella fornisce l'input IOC strutturato utilizzato dalla fase di normalizzazione. Clicca qui per visualizzare una versione più grande di questa figura.

Figura 6: Normalizzazione IOC del percorso file utilizzando analisi assistita da grafo. Confronto affiancato tra un IOC originale del percorso file e la sua rappresentazione normalizzata. Le query di attraversamento basate su grafi conoscono i componenti del Path con nome normalizzato e etichettano ogni componente come keep o discard. Gli identificatori di unità e i frammenti di nome file variabile possono quindi essere segnati come scartati nel record componente, mentre la forma normalizzata viene ricostruita principalmente a partire dai segmenti strutturali mantenuti necessari per la costruzione del pattern a valle. Clicca qui per visualizzare una versione più grande di questa figura.

Figura 7: Normalizzazione IOC della chiave di registro utilizzando analisi assistita da grafo. Normalizzazione di una chiave di registro IOC tramite risoluzione assistita da grafo di strutture gerarchiche di registri. Le chiavi root abbreviate vengono espanse in alveari canonici del registro, e l'analizzatore estrae la sottostringa di registro contigua più lunga conosciuta saltando i segnaposto dell'host, i valori simili a SID e i token simili a GUID. I record di output conservano/scartano etichette per ogni componente conservato e producono un percorso di registro canonico per l'elaborazione a valle. Clicca qui per visualizzare una versione più grande di questa figura.

Figura 8: Normalizzazione IOC da riga di comando usando analisi assistita da grafi. Confronto tra un IOC originale in riga di comando e la sua rappresentazione normalizzata. Il protocollo tokenizza la riga di comando preservando le stringhe di virgolette, normalizza il token di comando principale tramite la ricerca Neo4j quando possibile e analizza ricorsivamente frammenti embedded simili a percorsi o registri. I componenti stabili legati ai comandi sono etichettati come keep, gli argomenti delle variabili sono etichettati come scart, e la struttura di comando canonica finale viene ricostruita dagli elementi conservati. Clicca qui per visualizzare una versione più grande di questa figura.

Figura 9: Selezione basata su vincoli dei candidati a espressione regolare. Vengono generati più candidati regex per ogni IOC normalizzato utilizzando un flusso di lavoro di validazione iterativa. Viene applicato un meccanismo di punteggio guidato dai vincoli per selezionare un regex finale che preserva i componenti designati del gruppo di cattura limitando le sottostringhe di variabili indesiderate. Clicca qui per visualizzare una versione più grande di questa figura.

Figura 10: Distribuzione degli IOC estratti tra i rapporti CTI. Riepilogo dei risultati dell'estrazione IOC che mostrano il numero totale di indicatori identificati dai report CTI e la loro distribuzione tra percorsi di file, chiavi di registro e indicatori a riga di comando. Questa vista fornisce una validazione ad alto livello della copertura dei contenuti CTI e del comportamento di estrazione. Clicca qui per visualizzare una versione più grande di questa figura.

Figura 11: Distribuzione delle azioni di ottimizzazione durante la generazione delle espressioni regolari. Analisi delle azioni eseguite durante la generazione regex, inclusa la generazione iniziale, l'ottimizzazione guidata da LLM e la rigenerazione basata su retry. L'ottimizzazione guidata da LLM rappresenta il 51,7% di tutte le azioni, dimostrando che il raffinamento iterativo è una componente essenziale del protocollo per produrre regex che soddisfano i vincoli del gruppo di cattura. Clicca qui per visualizzare una versione più grande di questa figura.

Figura 12: File regex esportato rappresentativo. Contenuti di esempio dell'esportazione regolare SIEM (siem_rules.txt) generati dal protocollo. Ogni voce include l'IOC sorgente, la categoria dedotta (percorso file, chiave di registro o riga di comando) e il pattern regex validato. La tabella di validazione allegata riassume il comportamento atteso e le prove di sistema utilizzate per confermare la correttezza per ogni tipo di regola. Clicca qui per visualizzare una versione più grande di questa figura.

Figura 13: Rapporto rappresentativo completo JSON. Output end-to-end della pipeline prodotto dopo aver eseguito tutti e cinque gli stadi del protocollo su un rapporto CTI rappresentativo. Il documento JSON registra il file sorgente, il conteggio delle sezioni analizzate, gli IOC estratti raggruppati per categoria, i record categorizzati dello stadio 3 con tag sorgente, la difficolazione di normalizzazione dello stadio 4 e i pattern regex dello stadio 5 con flag di validazione per IOC. Il rapporto espone inoltre metadati di successo e errore di alto livello che permettono agli strumenti a valle di rilevare guasti parziali. Clicca qui per visualizzare una versione più grande di questa figura.

Figura 14: Input fallito o rumoroso: identificazione e correzione. Esempio funzionante di come il protocollo identifica e recupera da un IOC rumoroso. L'input grezzo %T E M P%\malware[.]Exe viene segnalato perché il token variabile di ambiente contiene spazi inseriti e la sua estensione file è stata defangata. Il passaggio di correzione rimuove lo spazio bianco inserito e ripristina il punto letterale; La normalizzazione della fase 4 espande quindi %TEMP% al modello canonico della directory Windows Temp; e Stage 5 genera un regex che compila e corrisponde all'IOC normalizzato corretto. Questo esempio illustra la gestione degli input rumorosi discussa nella Discussione. Clicca qui per visualizzare una versione più grande di questa figura.

Elemento	Tipo	Valore / Schema	Esempio	Note
Etichetta del nodo	Etichetta	:P ath	Windows, System32, cmd.exe	Memorizza componenti del percorso file di Windows
Etichetta del nodo	Etichetta	:Registro	SOFTWARE, Microsoft, Windows NT	Memorizza i componenti della chiave di registro sotto le arnie radici
Etichetta del nodo	Etichetta	:CLI	powershell.exe, -PoliticaEsecuzione, Bypass	Memorizza token di comando e parametri
Proprietà del nodo	Corda	Nome	cmd.exe	Involucro originale; Utilizzato per la visualizzazione in output normalizzato
Proprietà del nodo	Corda	name_lower	cmd.exe	Forma minuscola; usata come chiave di ricerca per tutte le query MATCH
Relazione	Bordo diretto	(a)-[:NEXT]->(b)	(Windows)-[:AVANTI]->(System32)	Entrambi i punti finali condividono la stessa etichetta; codifica l'adiacenza nativa sui sistemi Windows
Vincolazione	Unicità	n.name_lower UNICO per etichetta	-	Ho fatto domanda per :P ath, :Registry, :CLI
Fonte dei dati	Copertura	Windows 8, 10, 11	-	Sistema operativo client popolato in un grafo
Fonte dei dati	Copertura	Windows Server 2012, 2016, 2019, 2022	-	Sistema operativo server popolato in un grafo

Tabella 1: Schema grafico Neo4j utilizzato per la normalizzazione IOC (Fase 4). Elenca le tre etichette dei nodi (Path, Registry, CLI), il loro schema di proprietà condivisa (nome, name_lower), la relazione di adiacenza diretta usata per l'ordine nativo degli archi, i vincoli di unicità e le versioni client e server di Windows che popolano il grafo.

Teatro	Produzione prevista	Validazione automatica	Controllo qualità rivolto agli analisti
Fase 1: Analisi dei documenti	Testo Markdown unificato, suddiviso a 4.000 caratteri prima dell'elaborazione del LLM.	—	Controllo visivo dell'anteprima Markdown per confermare che percorsi di file, chiavi di registro, frammenti di riga di comando e confini di sezione sopravvivano all'analisi analizzante; Cambia backend se le stringhe tecniche sono troncate.
Fase 2: Estrazione IOC	JSON con tre chiavi di livello superiore (Percorso dei file, linee di comando, chiavi del registro); conteggi per voti per IOC e metadati del modello contributivo quando il voto in ensemble è abilitato.	Il filtro soglia di consenso (min_votes) esclude gli IOC il cui conteggio dei voti è inferiore alla soglia configurata.	Ispezione dei candidati esclusi per distinguere le allucinazioni dal voto eccessivamente rigido prima di adeguare min_votes.
Fase 3: Analisi e classificazione dell'IOC	Elenco IOC categorizzato: ogni IOC abbinato a una categoria standardizzata, un tag di sorgente e una chiave di estrazione originale quando disponibili.	Mappatura standardizzata delle categorie tramite regole regex e euristiche di pattern IOC; (IOC, categoria) deduplicazione di coppie.	Controllo puntuale delle uscite categorizzate per candidati ambigui o rumorosi (Figura 4A).
Fase 4: Normalizzazione assistita da Neo4j	Forma normalizzata per IOC con etichette di conservazione/scarto a livello di componente.	Query cifrari (i)-(iii) sul grafo di riferimento di Windows; fallback di preprocessing deterministico quando Neo4j non è disponibile.	Ispezione di casi completamente scartati per identificare lacune nella copertura dei grafi; Estensione dei dati dei grafi con riferimenti specifici per il fornitore o l'ambiente quando necessario.
Fase 5: Generazione e punteggio Regex	Regex finale per IOC con punteggi dei candidati, cronologia dell'ottimizzazione, conteggio delle iterazioni e telemetria per IOC.	Test di corrispondenza, controlli di qualità statici, controllo dei token proibiti consapevole dei confini, test di sovrageneralizzazione contro 5 campioni negativi deterministici; ritorno alla partita parziale con il punteggio più alto (used_fallback flag).	Revisione della cronologia di ottimizzazione per i regex di riserva; per ogni IOC e ispezione diagnostica della posizione di guasto prima della rigenerazione.

Tabella 2: Riassunto dell'output e della validazione delle fasi. Mappare ogni fase del protocollo (1–5) al suo artefatto atteso, alle prove di validazione automatica prodotte dalla pipeline (stato della compilazione regex, tasso di successo, tasso di disallineamento cross-IOC, conteggio di iterazioni di ottimizzazione) e al corrispondente controllo qualità rivolto all'analista (confronto visivo, ispezione dei candidati scartati e revisione delle categorie).

File supplementare 1: prompt letteralmente per il LLM. Il sistema letterale e i prompt umani utilizzati per l'estrazione IOC di Fase 2 e la generazione e ottimizzazione di regex di Fase 5. Clicca qui per scaricare questo file.

File supplementare 2: Dettagli di implementazione per le fasi 4 e 5. Dettagli algoritmici e di implementazione a supporto della normalizzazione IOC assistita da grafi dello Stadio 4 e della validazione, punteggio e controllo delle iterazioni regex dello Stadio 5. Clicca qui per scaricare questo file.

Discussione

Tradurre i report CTI non strutturati in logica di rilevamento eseguibile rimane un compito che richiede tempo e soggetta a errori nei flussi di lavoro di sicurezza operativa. Sebbene gli sforzi precedenti abbiano esplorato l'automazione a livello di estrazione IOC o generazione di regole ad alto livello, i professionisti affrontano ancora notevoli difficoltà nel convertire le stringhe IOC estratte in regex strutturalmente corretti, semanticamente precisi e adatti all'uso SIEM a valle. Il protocollo qui presentato affronta questa lacuna attraverso un flusso di lavoro a stadi in cui ogni fase produce un artefatto intermedio ben definito e applica una validazione esplicita prima di passare i risultati alla fase successiva. La Figura 14 documenta uno di questi casi, in cui un percorso di file defanged e perturbato dallo spazio bianco viene identificato, corretto, normalizzato e convertito in un regex di compilazione; La gestione degli input rumorosi del protocollo e il suo attuale ambito sono discussi congiuntamente con le limitazioni elencate di seguito.

Un contributo centrale di questo protocollo è la sua esplicita decomposizione del flusso di lavoro in fasi con output intermedi ispezionabili. L'implementazione è ora descritta in modo concreto: il parsing dei documenti produce Markdown e testo a blocchi per l'elaborazione degli LLM; L'estrazione IOC emette JSON strutturato per percorsi di file, chiavi di registro e indicatori da riga di comando; l'analisi IOC basata su regole standardizza e deduplica i valori estratti; La normalizzazione assistita da Neo4j etichetta ogni componente IOC come keep o scartato; e la generazione regex applica controlli di debug delle corrispondenze, convalidazione degli scarti e sovrageneralizzazione prima della selezione dei candidati.

Il protocollo tratta la generazione di espressioni regolari come un compito di costruzione iterativa piuttosto che come un problema di previsione one-shot. L'implementazione utilizza un prompt di generazione iniziale, diagnostica automatica delle partite, cicli di raffinamento limitati e una funzione di punteggio basata sui componenti per preservare elementi IOC strutturalmente importanti penalizzando al contempo le sottostringhe scartate o non mappate. Questo disegno iterativo, insieme a validatori deterministici applicati in ogni fase, supporta la produzione di pattern regex che rimangono strutturalmente fedeli su un ampio e eterogeneo insieme di valutazione. Nella valutazione di riferimento, questo flusso di lavoro è stato applicato a 3.156 report CTI e valutato su oltre 2.400 stringhe indipendenti di accuratezza sul terreno, ottenendo un tasso medio di successo del 99,1% e un tasso medio di disallineamento tra l'IOC dello 0,8%. Poiché queste stringhe di verità sul terreno sono artefatti curati da esperti e riportati dai fornitori di cybersecurity durante gli esercizi di valutazione MITRE ATT&CK, questa valutazione confronta implicitamente l'output del protocollo con i modelli IOC documentati dagli analisti umani piuttosto che con quelli generati automaticamente.

Come mostrato nei risultati rappresentativi, l'ottimizzazione iterativa è particolarmente importante quando il flusso di lavoro gestisce strutture IOC complesse come percorsi di file annidati o lunghe stringhe di riga di comando. I risultati della valutazione dei riferimenti indicano anche che i casi non corrispondenti più comuni si verificano quando gli attaccanti utilizzano eseguibili o parametri personalizzati che non sono rappresentati nel database dei grafi o non sono esplicitamente documentati nei report CTI di origine. Nell'uso operativo, queste modalità di guasto dovrebbero essere trattate come condizioni al contorno attese piuttosto che errori silenziosi e dovrebbero attivare la revisione della copertura del grafo, della completezza del rapporto sorgente e della telemetria regex-debug.

Il protocollo può essere confrontato con tre famiglie di metodi alternativi. Innanzitutto, i metodi di sintesi regex basati su esempi come TransRegex¹¹ e Regex+¹² apprendono regex da insiemi curati di esempi di stringhe positive e negative. Questi metodi funzionano bene quando sono disponibili set di esempio rappresentativi ma sono meno direttamente applicabili ai contesti SOC, dove ogni IOC riportato in CTI appare tipicamente come una singola stringa rappresentativa, e il confine di generalizzazione richiesto è guidato dalla semantica operativa piuttosto che dalla copertura degli esempi. In secondo luogo, gli approcci di programmazione genetica come quelli introdotti da Bartoli et ^al.13,14 esplorano lo spazio dei regex tramite operatori evolutivi e tipicamente richiedono un corpus etichettato di stringhe corrispondenti e non corrispondenti; sono ben adatti alla costruzione a lotti di modelli di estrazione ma non consumano direttamente narrazioni CTI non strutturate. In terzo luogo, gli approcci neurali e basati su LLM^{recenti 15,16} traducono le descrizioni in linguaggio naturale direttamente in stringhe regex; questi metodi sono potenti per prompt ben specificati ma, in uso singolo, possono produrre regex sintatticamente validi ma trascurare i componenti richiesti del gruppo di cattura o generalizzare troppo tra varianti IOC non correlate. L'attuale protocollo integra queste indicazioni (i) prendendo report CTI non strutturati invece di set di esempi curati o query in linguaggio naturale come input, (ii) scomponendo ogni IOC in componenti keep e discard tramite normalizzazione assistita da grafo prima che venga generata qualsiasi regex, e (iii) validando ogni regex candidato con controlli deterministici di corrispondenza, scartato e sovrageneralizzazione all'interno di un ciclo iterativo limitato. L'obiettivo non è superare i metodi precedenti sui propri benchmark, ma fornire una pipeline riproducibile IOC-regex le cui decisioni intermedie siano ispezionabili e verificabili dagli analisti SOC.

Il protocollo fa diverse ipotesi sulla qualità dei report CTI in ingresso. Si presume che (i) le stringhe IOC appaiano in una forma testuale recuperabile dopo l'analisi dei documenti, cioè i percorsi dei file, le chiavi di registro e gli indicatori della riga di comando non siano incorporati esclusivamente in immagini, screenshot o codifiche offuscate; (ii) i frammenti IOC riportati nel CTI sono sufficientemente completi da preservare i loro ancoraggi strutturali (ad esempio, le chiavi di registro mantengono il prefisso alveare, i percorsi dei file mantengono almeno un ancoraggio di directory riconoscibile nel grafo di documentazione di Windows, e le righe di comando conservano l'eseguibile invocante o un riferimento al modulo noto); e (iii) gli IOC riportati non vengono troncati, oscurati o riscritti in modi che rimuovano i componenti del gruppo di cattura da cui il protocollo dipende. I report CTI che soddisfano queste ipotesi includono la maggior parte delle descrizioni delle tecniche MITRE ATT&CK, avvisi ai fornitori, resoconti di risposta a incidenti e bollettini di minacce ben formattati. I rapporti che si basano principalmente su screenshot, liste IOC altamente abbreviate prive di contesto circostante, o parafrasi in testo libero senza stringhe IOC esplicite escono dall'inviolo operativo previsto e dovrebbero essere attesi a produrre una riduzione del richiamo dell'estrazione e una normalizzazione meno fedele; tali report potrebbero beneficiare di una pre-elaborazione a monte immagine-testo o di una revisione da parte degli analisti prima di entrare nella pipeline.

Devono essere considerate diverse limitazioni nell'applicazione di questo protocollo. Innanzitutto, l'implementazione attuale si concentra su percorsi di file, chiavi di registro e indicatori a riga di comando piuttosto che su categorie IOC più ampie come domini, artefatti email, stringhe user-agent o sequenze comportamentali. Questa è una scelta deliberata di ambito, poiché gli indicatori atomici sono generalmente ben serviti dai flussi di lavoro a corrispondenza esatta e il protocollo attuale mira agli IOC a struttura variabile che beneficiano della generalizzazione regex; tuttavia limita l'applicabilità ai tipi IOC attualmente non rappresentati nel grafico. In secondo luogo, gli scenari di guasto attuali si dividono in tre categorie principali: percorsi non nativi o argomenti a riga di comando assenti dal grafo del sistema operativo, copertura incompleta del grafo per utilità o strutture rilevanti, e incompletezza nella fonte CTI stessa quando frammenti di comando importanti o cmdlet non vengono mai riportati. In terzo luogo, la metrica di disadattamento cross-IOC utilizzata nella valutazione di riferimento misura la specificità semantica dei regex generati piuttosto che i falsi positivi di allarme end-to-end sotto la logica SIEM distribuita.

Riproducibilità sotto variabilità e versioning LLM. Poiché le fasi di estrazione IOC e generazione regex dipendono dagli endpoint LLM commerciali, due fonti di variabilità influenzano la riproducibilità: gli aggiornamenti del modello lato provider nel tempo e la stocasticità del campionamento per chiamata. Per mitigare il primo, tutti i campi relativi all'LLM nella Tabella dei Materiali registrano gli identificatori esatti del modello e la data di accesso utilizzata nella valutazione di riferimento, e il protocollo raccomanda di fissare uno snapshot specifico del modello ogni volta che il fornitore ne espone uno. Per mitigare il secondo, l'implementazione di riferimento fissa la temperatura di estrazione dell'IOC a 0,0 e utilizza una temperatura diversa da zero solo nella fase di generazione regex, dove il voto dell'ensemble e i validatori deterministici nelle fasi 2 e 5 assorbono la variazione residua. Quando replicano questi risultati, gli utenti dovrebbero registrare la versione esatta del modello, la data di accesso, la temperatura e la soglia di voto dell'ensemble utilizzata; deviazioni sostanziali su uno qualsiasi di questi assi dovrebbero essere prese a modificare le metriche di tasso di successo e disallineamento.

Diverse modalità di guasto recuperabili possono essere affrontate a livello dello stadio che le ha prodotte. Fallimenti di parsing della fase 1 (ad esempio, PDF scansionati che producono Markdown vuoto o distorto): pre-elaborare l'input con riconoscimento ottico dei caratteri o un convertitore esterno prima di ricaricare; verifica che il conteggio delle sezioni analizzate e il numero totale di caratteri siano diversi da zero prima di procedere. Fallimenti di estrazione della fase 2 (nessun IOC restituito o voci allucinate): aumentare la soglia di voto dell'ensemble (Voti minimi ≥ 2), abilitare ulteriori istanze del modello o abbassare la temperatura dell'LLM; verifica la connettività API e che il modello configurato accetti output formattati in JSON. Normalizzazione della fase 4 con etichette all-discast (ogni componente IOC è etichettato come scartato): estendere il grafo di riferimento Neo4j con componenti di percorso specifici per fornitore o ambiente e radici del registro; gli script di importazione Cypher e la regola di decisione di conservazione/scarto sono elencati nel File Supplementare 2. Fallimenti regex di fase 5 (used_fallback = veri, o rifiuti ripetuti di validazione degli scarti): ispezionare il campo di cronologia di ottimizzazione per IOC per identificare il validatore in guasto; se l'IOC manca davvero di componenti stabili per il mantenimento, si può considerare la creazione manuale di regex per quell'IOC o l'esclusione dalla generazione automatica delle regole mantenendola nella tabella classificata dell'IOC per la revisione da parte degli analisti.

In linea con le limitazioni sopra menzionate, i regex generati sono meglio trattati come primitive di ricerca riutilizzabili all'interno di contenuti più ampi di rilevamento SOC piuttosto che come rivelatori autosufficienti. In contesti operativi, gli analisti possono combinarli con logica di campo specifica per la piattaforma, whitelist, controlli di provenienza o condizioni di correlazione per sopprimere corrispondenze benigne che derivano da percorsi insoliti ma non dannosi.

I lavori futuri potrebbero includere confronti sistematici con regex autori da uomini, valutazioni più ampie su ulteriori categorie IOC, studi strutturati di feedback tra analisti, copertura dei grafi ampliata per utility e cmdlet creati dagli attaccanti e report più completi della latenza end-to-end e dei costi in vari contesti di implementazione. Tuttavia, l'attuale protocollo fornisce un quadro riproducibile e operazionalmente interpretabile per la traduzione IOC-to-regex che documenta sia i suoi punti di forza sia i suoi limiti attuali.

Materiali

Elenco dei materiali utilizzati in questo articolo

Nome	Azienda	Numero di catalogo	Commenti
Computer (CPU)	—	≥ 4 core raccomandati	Nessuna GPU richiesta
LangChain	LangChain	≥ 0.1.x	Framework di orchestrazione LLM
LLM (estrazione IOC, singolo modello)	OpenAI	gpt-5.1	Usato per l'estrazione IOC (Fase 2) quando il voto dell'ensemble è disabilitato. temperature = 0.0; max_workers = 5. Accesso: 2025-12-15.
LLM (Generazione regex)	OpenAI	gpt-5.1	Usato per la generazione regex (Fase 5). temperature = 0.3 prima della validazione a valle. Accesso: 2025-12-15.
LLM (Caratterizzazione della scalabilità)	OpenAI	gpt-5.1	Usato per l'esecuzione di scalabilità 6.000-IOC riportata nei Risultati Rappresentativi. Accesso: 2025-12-15.
Memoria (RAM)	—	≥ 16 GB raccomandati	Richiesta per l'elaborazione dei documenti
Neo4j	Neo4j, Inc.	≥ 5.x	Database grafico per la normalizzazione IOC
Neo4j Python Driver	Neo4j, Inc.	≥ 5.x	Interfaccia Python per Neo4j
Sistema Operativo	Microsoft / Apple / Linux	Windows, macOS o Linux	Supporto multi-piattaforma
Analisi PDF — backend principale	Microsoft	MarkItDown ≥ 0.0.x	Backend della Fase 1; converte gli input PDF/DOCX/HTML/TXT in Markdown. L'output analizzato viene suddiviso in blocchi di 4.000 caratteri prima dell'elaborazione LLM. Accesso: 2025-12-15. https://github.com/microsoft/markitdown
Configurazione della pipeline (Fase 2 — estrazione IOC)	—	Default di riferimento	Modalità Single-LLM: temperature = 0.0, max_workers = 5. Modalità di voto dell'ensemble: ripetizioni = 1 per modello configurato, min_votes = 2.
Configurazione della pipeline (Fase 5 — generazione regex)	—	Default di riferimento	Temperatura di generazione = 0.3. Validazione: overgen_random_tests = 5 campioni negativi deterministici per IOC. Limiti dell'iterazione: max_iterations = 10, debug_loop_cap = 5, discard_validation_cap = 5.
Python	Python Software Foundation	≥ 3.8	Ambiente di runtime richiesto
Motore regex	Python Standard Library	modulo re	Usato per la validazione e il test regex
Streamlit	Streamlit Inc.	≥ 1.25	Interfaccia utente basata sul web
Codice sorgente dell'implementazione di riferimento	Autori / GitHub | Repository GitHub		Codice sorgente per l'interfaccia Streamlit, la pipeline LangChain, la normalizzazione assistita da Neo4j, la generazione regex, gli strumenti di validazione e i file di configurazione di esempio. Disponibile su https://github.com/SOCautomatic/cti-ioc-regex-pipeline. Accesso: 11 giugno 2026.