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

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

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.