L’adozione dell’IA si sta diffondendo tra i team delle operazioni di sicurezza. Il sondaggio State of AI in Security Operations 2026 di Prophet Security, condotto su oltre 250 CISO, responsabili dei SOC e professionisti del settore, ha rilevato che il 40% dei team utilizza l’IA quotidianamente, mentre un altro 56% la sta testando. Solo il 4% ha dichiarato di non avere piani per adottare la tecnologia.
Per i team che stanno ancora valutando l’IA, la domanda chiave è se il loro SOC sia pronto a implementare agenti. La preparazione ha due dimensioni: i problemi operativi che un agente IA potrebbe affrontare e le basi tecniche e di governance necessarie per analizzare accuratamente gli avvisi.
Gli agenti IA sono particolarmente utili nei SOC che devono gestire escalation ritardate dei servizi di managed detection and response, contesto mancante, copertura limitata dei provider, arretrati di avvisi e scarsa visibilità sulle decisioni investigative. I team interni possono inoltre avere difficoltà a rispondere rapidamente alla domanda se siano interessati da una nuova vulnerabilità o campagna, a esaminare gli avvisi di gravità inferiore, ottimizzare i rilevamenti rumorosi, condurre threat hunt e mantenere la copertura al di fuori del normale orario di lavoro.
Il sondaggio ha rilevato che il 60% degli intervistati aveva visto un avviso ignorato o non rilevato trasformarsi successivamente in un problema serio, come una violazione o un’interruzione del servizio. Ha inoltre riportato che il 28% degli avvisi non viene mai esaminato. Queste pressioni fanno sì che la threat hunting proattiva e la detection engineering competano con la gestione quotidiana degli avvisi.
Il modello di maturità del SOC descritto da Prophet Security colloca la gestione degli avvisi alla base, seguita dalla copertura dei rilevamenti, dalla consapevolezza delle minacce, dalla threat hunting proattiva e dai miglioramenti della postura. Gli agenti IA iniziano generalmente con l’analisi degli avvisi, sebbene le piattaforme più recenti possano supportare anche la threat hunting e la detection engineering. Il tempo recuperato dal lavoro di routine può quindi essere reindirizzato verso le attività situate più in alto nel modello.
La preparazione tecnica inizia dall’accesso. Un agente può analizzare soltanto i dati che è in grado di interrogare, quindi le integrazioni rilevanti possono includere il SIEM, l’EDR, il provider di identità, le piattaforme cloud, la posta elettronica e le applicazioni SaaS importanti. Ha inoltre bisogno di un contesto leggibile, come la criticità degli asset, i ruoli degli utenti, gli elenchi dei VIP, le unità aziendali e le attività note come legittime. È altrettanto importante monitorare lo stato e la tempestività delle pipeline di logging, perché dati mancanti o ritardati possono far sembrare completa un’indagine quando invece mancano prove fondamentali.
Un test pratico consiste nell’esaminare cinque incidenti recenti e nell’elencare ogni query utilizzata da un analista senior per risolverli. Qualsiasi query che l’agente proposto non sia in grado di eseguire identifica una lacuna di accesso o di integrazione. È inoltre necessario esaminare la gestione dei dati: il 44% degli intervistati al sondaggio ha indicato la privacy dei dati e l’addestramento dei modelli IA come un ostacolo importante. Le organizzazioni dovrebbero chiedere ai fornitori se i dati dei clienti vengono utilizzati per addestrare i modelli e dove tali dati vengono elaborati.
Un progetto pilota deve inoltre includere una definizione scritta di indagine completata. Tale standard dovrebbe specificare le prove necessarie per i casi comuni, inclusi gli avvisi di phishing e di impossible travel, e ciò che è sufficiente per classificare un avviso come benigno. Le organizzazioni dovrebbero registrare metriche di riferimento, come la percentuale di avvisi esaminati, il tempo medio necessario per l’indagine, il tempo che precede la prima revisione e la percentuale di avvisi chiusi che vengono riaperti.
Il rapporto afferma che un’indagine approfondita richiede in media 75 minuti e che spesso gli avvisi attendono quasi un’ora prima di essere aperti. Afferma inoltre che fino al 40% delle organizzazioni ha disabilitato alcuni rilevamenti perché non disponeva della capacità necessaria per esaminarli. Un elenco documentato di tali rilevamenti può aiutare a identificare i casi in cui un’indagine automatizzata aggiuntiva potrebbe ripristinare la copertura.
La governance deve distinguere tra indagine e risposta. Nel sondaggio, il 57% dei team richiedeva una revisione umana prima di ogni decisione dell’IA volta a chiudere un avviso. Per le azioni di risposta, il 44% utilizzava l’IA per raccomandare azioni da eseguire da parte delle persone, mentre il 30% consentiva la remediation autonoma nei casi a basso rischio. Nessun intervistato ha dichiarato di aver concesso un’autonomia completa e non supervisionata.
Prima di un progetto pilota, le organizzazioni dovrebbero definire quali azioni richiedono sempre un’approvazione, chi può ampliare i permessi dell’agente, dove appariranno i suoi risultati e chi è responsabile della revisione degli errori. Iniziare con un accesso investigativo di sola lettura e ampliare gradualmente i permessi segue lo stesso approccio prudente adottato quando si introduce un nuovo analista umano.
La checklist di preparazione proposta distingue la necessità dell’IA dalla capacità di implementarla. Un caso solido per l’adozione può esistere quando gli avvisi arrivano in ritardo, i provider non dispongono di contesto, le indagini subiscono ritardi, i rilevamenti sono stati disabilitati o i casi difficili dipendono soltanto da pochi analisti senior. La preparazione all’implementazione dipende invece dall’accesso alle API, dalla disponibilità del contesto relativo ad asset e utenti, da standard investigativi scritti, da regole di approvazione, dal monitoraggio delle fonti di log, da dati di riferimento sulle prestazioni, da un registro dei rilevamenti disabilitati e da un piano per utilizzare il tempo restituito al team.
Se il SOC non è pronto, la preparazione raccomandata consiste in larga misura in attività di configurazione e documentazione. I team possono iniziare colmando le lacune di accesso individuate attraverso la revisione dei cinque incidenti, documentando gli standard per le tipologie di avviso con il volume più elevato e facendo operare un agente insieme agli analisti per diverse settimane. Le modifiche apportate dagli analisti dovrebbero essere registrate come informazioni relative al contesto mancante o a comportamenti errati. I permessi possono quindi essere ampliati una categoria di azione alla volta.
Un’altra opzione consiste nel costruire un agente internamente, ma il sondaggio indica rischi significativi. Tra gli utenti dell’IA, il 72% aveva provato a sviluppare strumenti IA interni e il 46% di questi progetti era stato abbandonato, non era arrivato in produzione oppure era stato sostituito da un prodotto commerciale. Oltre il prototipo, i team devono mantenere le integrazioni, gestire le modifiche alle API e i limiti di frequenza, amministrare la dismissione dei modelli, ripetere le valutazioni e i test di prompt injection e preservare tracce di audit che spieghino le decisioni relative agli avvisi.
Prophet Security descrive la propria piattaforma Prophet AI come uno strumento a supporto dell’indagine, della threat hunting e della detection engineering. Il suo agente SOC Analyst interroga gli strumenti di sicurezza e registra le domande, le query e le prove alla base delle decisioni, mentre le azioni di risposta restano soggette ai permessi definiti dal cliente e all’approvazione umana predefinita. Il componente Threat Hunter è progettato per eseguire ricerche relative a minacce appena divulgate e indagini programmate, mentre il componente Detection Engineer utilizza i risultati delle indagini e le lacune di copertura per proporre e sottoporre a backtest i rilevamenti prima dell’approvazione.
Secondo l’azienda, i risultati di queste funzioni si alimentano reciprocamente: le indagini possono rivelare rilevamenti rumorosi o mancanti, le attività di threat hunting possono esaminare tali lacune e i loro risultati possono informare nuove regole di rilevamento. Prophet Security dichiara inoltre che i dati dei clienti non vengono utilizzati per addestrare i propri modelli e che il suo data plane può essere eseguito all’interno del virtual private cloud del cliente.
Fonti: The Hacker News.