Un tema importante che è stato dibattuto durante l’evento “Sovranità Digitale e Cybersecurity” tenutosi lo scorso 2 dicembre 2025 presso il Cefriel a Milano, è stato quello della necessaria integrazione fra Threat Hunting, Threat Intelligence ed AI. Nell’articolo che segue, Enrico Frumento, Cybersecurity Research Lead di Cefriel, approfondisce le relazioni che intercorrono tra i diversi ambiti del Threat hunting e della Threat intelligence, la necessità di collegarle tra loro in una catena informativa e decisionale integrata, l’apporto corretto fornito dall’AI in questo contesto. Come spiega Enrico Frumento, la catena Threat Hunting → Threat Intelligence → Business Impact → Actionable Insights è un processo organizzativo, non solo tecnologico, che integra competenze tecniche, di sicurezza e strategiche. L’AI valorizza ogni fase: filtra anomalie nel threat hunting, automatizza classificazioni nella threat intelligence e supporta l’analisi del rischio nel business impact. Tuttavia, il giudizio umano resta cruciale per interpretare risultati, gestire ambiguità e decisioni incerte. I limiti strutturali dell’AI e la qualità dei dati determinano l’affidabilità della pipeline. Il futuro è nell’amplificazione intelligente delle capacità umane, non nell’automazione totale. Investire solo in tecnologia senza sviluppare competenze porta al fallimento; un approccio strutturato trasforma i dati in intelligence reale.
Dalla frammentazione alla catena integrata
Di Enrico Frumento, Cybersecurity Research Lead, Cefriel
Il threat hunting e la threat intelligence sono discipline che si sono sviluppate separatamente nella storia della cybersecurity. Il primo è nato come risposta operativa alla necessità di cercare minacce nascoste nei sistemi; la seconda come funzione di analisi strategica del panorama delle minacce. Per anni sono rimaste attività distinte, gestite da team diversi con competenze diverse.
Questa separazione ha creato un problema strutturale. I threat hunter producevano segnali tecnici che non raggiungevano chi doveva prendere decisioni. Gli analisti di intelligence raccoglievano informazioni strategiche che non si traducevano in azioni operative. Il management riceveva report periodici disconnessi dalla realtà tecnica dei sistemi.
La maturazione del settore ha portato a comprendere che queste funzioni non possono operare in isolamento. La loro efficacia dipende dalla capacità di connetterle in una catena informativa continua: dal rilevamento tecnico all’analisi contestuale, fino alla decisione strategica. Non si tratta di strumenti separati ma di fasi di un unico processo che trasforma dati grezzi in intelligence azionabile.
L’intelligenza artificiale ha accelerato questa integrazione rendendo possibile processare volumi di dati altrimenti ingestibili. Ma ha anche introdotto nuove criticità che richiedono comprensione tecnica per essere gestite correttamente.
Dal data lake al data swamp
Le organizzazioni raccolgono enormi quantità di dati di sicurezza: log di sistema, eventi di rete, alert automatici, report di vulnerabilità. L’infrastruttura moderna produce informazioni a velocità che supera qualsiasi capacità di analisi manuale. La risposta architetturale è stata di costruire data lake — archivi centralizzati dove confluiscono tutti questi flussi.
Il problema è che un data lake richiede governance continua. I dati devono essere catalogati, normalizzati, validati. Le relazioni tra entità diverse devono essere mappate. I metadati devono essere mantenuti aggiornati. Senza questo lavoro di manutenzione, il lake degenera rapidamente in un data swamp — una palude informativa dove i dati esistono ma non sono utilizzabili.
Quando si verifica questa degenerazione, l’errore concettuale più diffuso è pensare che l’AI possa “ripulire” autonomamente il dato. Questa aspettativa si basa su un fraintendimento di come funzionano i sistemi di machine learning. Un modello non corregge la qualità dei dati in ingresso. Al contrario, amplifica i loro difetti strutturali.
Garbage in, garbage out nell’era dell’AI
Il principio “garbage in, garbage out” non è nuovo, ma l’AI lo rende più insidioso. Un sistema tradizionale basato su regole fallisce in modo prevedibile quando riceve dati malformati: genera errori, si blocca, produce output evidentemente sbagliati. Un sistema di AI invece continua a produrre risultati apparentemente coerenti anche quando i dati in ingresso sono compromessi.
Questo accade perché i modelli di machine learning apprendono pattern statistici dai dati di addestramento. Se questi dati contengono rumore, bias sistematici o lacune, il modello incorpora questi difetti come se fossero caratteristiche legittime del dominio. Il risultato è un sistema che produce output tecnicamente validi ma semanticamente errati.
Nel contesto della cybersecurity, le conseguenze sono dirette. Un modello addestrato su log incompleti apprende a considerare normale ciò che è solo un artefatto della raccolta dati. Un sistema alimentato da alert mal classificati replica e amplifica gli errori di classificazione. Un motore di correlazione che processa eventi senza timestamp affidabili genera false relazioni causali.
Il problema si aggrava quando questi sistemi operano in catena. L’output di un modello diventa input per il successivo, propagando e amplificando l’errore iniziale. Senza governance del dato a monte, l’intera pipeline diventa inaffidabile.
Tassi di errore intrinseci delle AI
Anche quando i dati in ingresso sono di qualità elevata, i sistemi di AI mantengono tassi di errore strutturali. Questi errori non sono bug eliminabili ma conseguenze dirette del loro funzionamento.
Il primo tipo è il bias statistico. Un modello apprende dai dati che gli vengono forniti e riflette inevitabilmente le caratteristiche di quel campione. Se il dataset di addestramento sovra-rappresenta certi tipi di attacco o certi ambienti operativi, il modello sarà più accurato in quei contesti e meno in altri. Questo bias può essere mitigato ma non eliminato completamente.
Il secondo tipo è la correlazione spuria. I modelli statistici identificano associazioni nei dati senza comprenderne la causalità. Due eventi possono co-occorrere frequentemente per ragioni contingenti — orari di lavoro, cicli di manutenzione, stagionalità — e il modello li tratterà come correlati anche quando non lo sono. Il risultato sono alert su attività legittime che seguono pattern insoliti.
Il terzo tipo, particolarmente problematico nei modelli generativi, è l’allucinazione. Questi sistemi sono progettati per produrre output coerenti e plausibili. Quando non hanno informazioni sufficienti per rispondere correttamente, generano contenuti che sembrano validi ma sono inventati. Nel contesto dell’intelligence, questo significa report tecnicamente corretti nella forma ma falsi nella sostanza.
L’incertezza statistica è il quarto fattore. Ogni predizione di un modello ha un margine di confidenza che indica quanto il sistema è sicuro del risultato. Molte implementazioni non espongono questo dato o lo presentano in modo che gli operatori lo ignorano. Un alert con confidenza al 51% viene trattato come uno al 99%, generando falsi positivi che desensibilizzano i team.
Questi limiti non sono difetti temporanei ma proprietà intrinseche dei sistemi statistici. Comprendere questo è necessario per usare l’AI in modo efficace, soprattutto nella cybersecurity.
La catena operativa: dove l’AI porta valore reale
La figura che rappresenta la catena operativa mostra come si collegano tre livelli organizzativi: IT Level, Sec Level e C-Level. Questa struttura non è teorica ma riflette il flusso informativo necessario per trasformare dati tecnici in decisioni strategiche.
Figura 1 – La figura mostra come si collegano tre livelli operativi: Threat Hunting, Threat Intelligence e Business Impact per produrre Actionable Insights
Al livello IT operano i threat hunter. Il loro compito è analizzare dati grezzi — log, eventi di rete, comportamenti di sistema — per identificare anomalie che potrebbero indicare compromissione. Tradizionalmente questo lavoro si basava su indicatori statici: hash di malware noti, indirizzi IP in blacklist, firme di attacco catalogate. L’approccio funzionava contro minacce commodity, ma falliva contro attaccanti sofisticati che modificano continuamente questi indicatori.
L’AI ha cambiato questo processo introducendo l’analisi comportamentale. Pur essendo soggetti alle incertezze descritte nel paragrafo precedente, invece di cercare impronte digitali note, i modelli identificano deviazioni da pattern normali. Un amministratore che accede a sistemi critici in orari insoliti. Un processo che stabilisce connessioni di rete mai osservate prima. Un account che scarica volumi di dati anomali. Questi comportamenti non sono necessariamente malevoli ma richiedono verifica umana.
Il vantaggio operativo è la riduzione del dwell time — il tempo tra la compromissione iniziale e la scoperta. Gli Advanced Persistent Threat rimangono nei sistemi per mesi muovendosi lentamente per evitare il rilevamento. L’analisi comportamentale permette di identificare questi movimenti laterali anche quando non generano alert tradizionali.
Ma l’AI qui non sostituisce il threat hunter. Filtra il rumore evidenziando le anomalie che meritano attenzione. L’analista umano valuta se quell’anomalia è un falso positivo, un errore di configurazione o una minaccia reale. Senza questo giudizio, il sistema produce troppi alert per essere gestibile.
Le evidenze del threat hunting alimentano la threat intelligence essendo una delle sue fonti primarie. Questo è il passaggio più critico della catena perché trasforma dati tecnici in intelligence contestualizzata. Un indirizzo IP sospetto rilevato durante l’hunting diventa intelligence quando l’analista scopre, ad esempio, che appartiene a un gruppo di attaccanti noto per colpire il settore dell’organizzazione, che ha già compromesso un fornitore critico la settimana precedente, e che usa un ransomware specifico con tecniche documentate.
Questa contestualizzazione richiede l’integrazione di altre fonti esterne: report di sicurezza, bollettini di vulnerabilità, analisi di ricercatori, discussioni su forum specializzati. Un analista umano non può processare manualmente centinaia di documenti al giorno mantenendo la coerenza terminologica. L’AI automatizza questa fase attraverso il Natural Language Processing, estraendo Tactics, Techniques and Procedures dai testi e mappandole sul framework MITRE ATT&CK.
ATT&CK fornisce un vocabolario standardizzato per descrivere le tecniche d’attacco. Questo permette a team in organizzazioni diverse di comunicare usando gli stessi termini e di confrontare la propria postura di sicurezza con pattern di minaccia noti. L’automazione non elimina la necessità di analisti esperti, ma li libera dal lavoro di classificazione manuale, permettendo di concentrarsi su un’analisi già prioritizzata.
Il problema è che i modelli di linguaggio hanno un gap semantico. Riconoscono pattern testuali ma faticano con contesto, ironia, ambiguità. Un tool di cybersecurity può essere categorizzato in un report come strumento legittimo o come vettore d’attacco. Senza supervisione umana, l’AI può produrre classificazione erronee contaminando le basi informative dell’intelligence.
Il terzo livello è dove la catena tipicamente si interrompe. La threat intelligence produce output tecnici — codici di tecniche ATT&CK, descrizioni di vulnerabilità, indicatori di compromissione. Questi dati non sono direttamente utilizzabili dal management. Un CEO non può agire su un’informazione come “Abbiamo rilevato la tecnica T1566.001“. Ha bisogno di sapere: siamo vulnerabili al ransomware che sta colpendo i nostri competitor? Qual è il rischio finanziario? Quali azioni concrete dobbiamo intraprendere?
Questa trasformazione richiede l’analisi del Business Impact. La threat intelligence può essere essenziale per comprendere le probabilità di subire impatti aziendali da minacce cyber: potenziale interruzione operativa, perdita di dati critici, costi di ripristino, danni reputazionali, sanzioni regolamentarie. Questi impatti vengono sintetizzati in Actionable Insights — raccomandazioni concrete: investire in una specifica tecnologia di protezione, modificare policy di accesso, condurre training mirato, attivare audit su fornitori critici.
Gli Actionable Insights definiscono una traccia per le decisioni strategiche aziendali in termini di protezione. Con normative come NIS2, che impongono la responsabilità della sicurezza informatica direttamente sul board, questo collegamento diventa obbligatorio.
Il risultato finale è costituito dai Key Risk Indicators, direttamente legati al business, metriche che il management può monitorare per valutare la postura di sicurezza nel tempo del business. In altre parole, indicatori di rischio non tecnologici, legati a concetti di business (es. rischio di dover fermare la produzione, rischio di dover ridurre gli investimenti nella crescita ecc.).
La figura precedente mostra anche quattro superfici di rischio oltre l’IT tradizionale. I sistemi OT — Operational Technology come SCADA e controlli industriali — hanno caratteristiche e linee guida per la loro sicurezza completamente diverse dall’IT. Un modello addestrato su dati IT genera falsi positivi massivi se applicato all’OT senza personalizzazione. L’elemento umano (Human Element – HE) rimane la superficie d’attacco più vulnerabile: phishing, social engineering, errori operativi non possono essere eliminati completamente da nessuna tecnologia. Infine, l’AI stessa diventa una nuova superficie d’attacco: model poisoning, adversarial attacks, data leakage attraverso modelli.
Il ruolo critico per collegare questi livelli è il Chief Risk Officer. Opera nell’interfaccia tra Sec Level e C-Level, traducendo intelligence tecnica in rischio di business. Questo richiede competenze ibride: comprensione tecnica sufficiente per interpretare l’intelligence di sicurezza e capacità di business per valutarne l’impatto strategico. Senza questa figura, o una funzione equivalente, la catena ha un punto di debolezza perché il C-Level prenderebbe decisioni sulla base di percezioni anziché di analisi strutturate.
Limiti operativi e sostenibilità del processo
È quindi evidente che l’AI amplifica le capacità di ispezione in ogni fase della catena ma non elimina la necessità di competenze umane. Tre limiti operativi devono essere compresi per evitare aspettative irrealistiche.
Il primo è la manutenzione continua. Le minacce evolvono quotidianamente. I modelli devono essere riaddestrati costantemente, le mappature verificate, i parametri aggiustati. Non è un’installazione una tantum, ma un processo che richiede risorse qualificate permanenti. Le supply chain del software cambiano continuamente, le normative evolvono, gli attaccanti sviluppano nuove tecniche. Ogni cambiamento richiede aggiornamenti a cascata su tutta la catena.
Il secondo è il rischio di dequalificazione. Un analista junior che si affida ciecamente all’output dell’AI senza applicare pensiero critico diventa meno capace di affrontare situazioni impreviste. L’AI deve essere un copilota che amplifica le competenze, non un autopilota che le sostituisce. Questo richiede programmi di formazione che insegnano a usare l’AI criticamente, non a fidarsi ciecamente dei suoi output.
Il terzo è l’alert fatigue. Un sistema che produce centinaia di allarmi al giorno desensibilizza gli operatori. Quando arriva l’allarme critico, viene ignorato perché indistinguibile dal rumore. La calibrazione dei sistemi è cruciale quanto la loro implementazione. Preferire precisione a recall (i.e. generare meno alert ma più accurati) è spesso il punto critico della corretta implementazione di questa catena, anche se significa perdere alcuni veri positivi.
La sostenibilità del processo nel tempo è la sfida più sottovalutata. Le organizzazioni che trattano la cybersecurity come un progetto con un inizio e una fine falliscono strutturalmente. La catena operativa descritta richiede impegno permanente in termini di budget, personale qualificato e attenzione del management.
Conclusioni: aspettative corrette e direzione evolutiva
La catena Threat Hunting → Threat Intelligence → Business Impact → Actionable Insights non è una sequenza tecnologica ma un processo organizzativo. Collega tre livelli di competenza — tecnico, di sicurezza, strategico — attraverso un flusso informativo strutturato.
L’AI porta valore reale in ogni fase, ma non come soluzione autonoma. Nel threat hunting filtra il rumore evidenziando anomalie comportamentali. Nella threat intelligence automatizza la classificazione e la mappatura su framework standardizzati. Nella produzione di business impact può supportare l’analisi quantitativa del rischio. Ma in ognuno di questi passaggi il giudizio umano rimane necessario per interpretare i risultati, gestire le ambiguità e prendere decisioni in contesti incerti.
I tassi di errore intrinseci dei sistemi di AI (bias, correlazioni spurie, allucinazioni, incertezza statistica) non sono difetti temporanei ma proprietà strutturali. Comprendere questi limiti è necessario per usare correttamente la tecnologia. La qualità dei dati in ingresso determina l’affidabilità dell’intera pipeline. Senza governance dei dati a monte, l’AI non risolve il problema del data swamp ma lo rende meno visibile.
La direzione evolutiva del settore non è verso l’automazione completa ma verso l’amplificazione intelligente delle capacità umane. I sistemi più efficaci sono quelli che espongono chiaramente la propria incertezza, permettono agli operatori di comprendere come arrivano a certe conclusioni e facilitano la verifica indipendente dei risultati.
Le organizzazioni che investono solo in tecnologia senza costruire le competenze necessarie a guidarla falliscono. Quelle che trattano l’AI come strumento all’interno di un processo strutturato, con ruoli chiari e flussi informativi definiti, trasformano i data swamps in intelligence utilizzabile.
La domanda finale non è se adottare l’AI, ma se stiamo investendo abbastanza per mantenere l’intelligenza umana necessaria a guidarla.
