L’AI è il nuovo alleato nei SOC (Security Operations Center), l’asset principale nel contenimento del tempo di risposta agli incidenti.

Nel cuore dei centri di coordinamento di tutti i processi di emergenza scatenati da una cyber minaccia esterna, per minimizzarne gli impatti, la pressione degli attacchi informatici è diventata travolgente. La mole di alert da gestire supera ormai di gran lunga la capacità manuale di analisi, generando una diffusa “alert fatigue” tra gli analisti.

Nel frattempo, le campagne di attacco si evolvono, articolandosi in più fasi e coinvolgendo catene di fornitori estese, imponendo una necessità stringente: correlazioni rapide, affidabili e riproducibili dei dati raccolti.

È in questo contesto che i Large Language Model (LLM) emergono come una risorsa preziosa.

Ecco qual è il ruolo dell’AI nei SOC e la sfida crescente da affrontare.

L’AI nella risposta agli incidenti

I modelli LLM (algoritmi di Deep learning in grado di riconoscere contenuti, generarli, riassumerli, tradurli e persino prevederli), sono capaci di sintetizzare eventi complessi, suggerire ipotesi intelligibili e trasformare dati e risultati in linguaggio naturale strutturato. Essi riducono drasticamente il tempo che gli specialisti dedicano ad integrare e collegare strumenti e informazioni.

Occorre chiarire che i LLM non sostituiscono il processo di Incident Response (IR), bensì lo potenziano, a patto che vengano integrati con regole precise, tracciabilità e responsabilità ben definite.

Quadro normativo e tendenze di mercato

La cornice normativa e metodologica si è fatta più solida. La revisione 3 della NIST SP 800-61 (guida del National Institute of Standards and Technology per la gestione degli incidenti di sicurezza informatica) aggiorna ruoli e fasi dell’Incident Response.

Invece il NIST AI Risk Management Framework, con un focus specifico sull’AI generativa, disegna linee guida per la governance e la gestione del rischio.

Sul mercato, stanno nascendo assistenti AI integrati in piattaforme SIEM e EDR. Promettono triage più veloce e timeline forensi guidate, ma devono sempre essere valutati con indicatori di performance (KPI) replicabili e adattati al proprio contesto operativo.

Cresce inoltre la preoccupazione per minacce specifiche rivolte proprio all’AI, come la prompt injection o l’abuso dei tool collegati, che esigono l’implementazione di guard-rail tecnici e procedure di approvazione rigorose, documentate e auditabili.

Applicazioni tecniche mature nei SOC

Sul piano tecnico, i casi d’uso più maturi vedono i LLM affiancare il lavoro di triage multi-alert in linguaggio naturale, la deduplicazione e il clustering di campagne, e la sintesi automatica di query su linguaggi specifici come KQL, ES|QL, SQL, YARA e Sigma, con spiegazioni dettagliate dei filtri applicati.

In ambito forense, i modelli supportano la costruzione di timeline verificabili, indicano evidenze a sostegno delle analisi e propongono pivot investigativi, incrociando indicatori e comportamenti con framework come MITRE ATT&CK (strumento per “conoscere” i comportamenti e le tecniche di attacco dei criminal hacker) e MITRE ATLAS (framework per la security AI con supporto alla tutela dei modelli AI e LLM dagli attacchi più evoluti).

Un’architettura efficace combina la Retrieval-Augmented Generation (RAG) con basi conoscitive firmate e un obbligo di grounding delle risposte alle fonti, sandbox rigorose (un ambiente “sterile” per la sicurezza) con rete deny-by-default, credenziali a scopo limitato e validazione automatica delle azioni intraprese.

Essenziali restano poi il prompt hardening, il parsing strutturato con schema JSON e la presenza dell’umano nel ciclo per garantire contenimento ed eradicazione.

La capacità di riprodurre le operazioni è assicurata dal versioning dei modelli, dalla temperatura, dai template di prompt, dagli snapshot del sistema RAG e da log append-only.

Vincoli legali e compliance in Europa

Nel contesto europeo, l’uso di LLM nei SOC deve rispettare vincoli stringenti. Il GDPR (General Data Protection Regulation, il Regolamento generale sulla protezione dei dati) impone basi giuridiche solide, il principio di minimizzazione e, quando richiesto, una valutazione d’impatto sulla protezione dati (DPIA).

La direttiva NIS2 (normativa europea per rafforzare la cyber resilienza delle infrastrutture critiche e imporre misure di sicurezza più stringenti a più settori) detta misure tecniche e organizzative robustissime, focalizzate anche sulla catena di fornitura software.

Per gli operatori finanziari, il Digital Operational Resilience Act (DORA) , regolamento dell’Unione Europea che punta a rafforzare la resilienza operativa digitale del settore finanziario contro le cyber minacce, estende i requisiti di resilienza ICT, prevedendo test periodici e reporting accurato.

L’AI Act – la prima legge europea che regolamenta l’uso dell’intelligenza artificiale – introduce obblighi di governance e trasparenza per sistemi AI, mentre il Cyber Resilience Act (CRA, quadro normativo Ue che impone requisiti di cyber security obbligatori per hardware e software) mette sotto la lente qualità e sicurezza lungo tutta la catena del software.

Dentro contratti e policy devono trovare spazio regole su localizzazione dati, no-training, no-retention e auditabilità degli scambi.

Ruoli e responsabilità nella gestione AI

Questo cambiamento interessa diversi ruoli aziendali. Il Chief Information Security Officer (CISO) definisce priorità, regole di segregazione sull’uso degli LLM e soglie di rischio, impostando KPI e KRI su tempi di risposta, qualità delle evidenze e impatti operativi.

I team SecOps e IT curano l’integrazione tecnica con SIEM e EDR, mantengono un inventario dei dati ammessi, realizzano RAG “security-grade”, sandbox e content firewall, e gestiscono l’approvazione per azioni ad alto impatto.

Legal e Privacy garantiscono basi giuridiche, redigono clausole contrattuali precise e gestiscono le notifiche e DPIA, assicurando la conservazione delle prove.

Il management sponsorizza investimenti formativi, allinea obiettivi di qualità e velocità di risposta, e misura il valore generato sul campo.

Un approccio graduale per un’adozione efficace

Un approccio graduale permette un’adozione efficace e sicura. È consigliato definire subito una AI use policy per il SOC, chiarendo dati ammessi, modelli consentiti, retention e responsabilità, abilitando audit log append-only e accountability distribuita.

La scelta di un RAG “security-grade” è essenziale: playbook e runbook firmati, citazioni obbligatorie alle fonti e risposte solo con evidenze verificabili. Infine, un content firewall leggero protegge i dati sensibili (come PII) tramite redaction prima dell’invio al modello, e filtra output limitandoli a domini in allow-list con regole trasparenti.

Con l’AI nei SOC, è l’ora dell’Incident response 2.0

L’Incident Response 2.0 si basa su una collaborazione sinergica uomo-AI. La rapidità d’intervento, la copertura e la qualità dell’analisi crescono significativamente se l’LLM è ancorato a fonti affidabili e solidi controlli.

È fondamentale misurare costantemente l’impatto con KPI su tempi medi di rilevazione e risoluzione (MTTA e MTTR), qualità dei report e riduzione di falsi positivi, aggiornando regolarmente le baseline.

La fiducia nella soluzione si costruisce attraverso un controllo puntuale di versioning, prompt, firme e log immutabili che garantiscono audit e riproducibilità.

Ma soprattutto, l’intervento umano deve restare protagonista per ogni azione a rischio, attraverso sandbox, approvazioni tracciate e test preliminari, trasformando così l’AI in un moltiplicatore di efficienza senza introdurre nuovi punti ciechi.