Agenti AI e SIEM esistente: cosa aggiungono e cosa non sostituiscono

No, gli agenti AI (intelligenza artificiale) non rendono obsoleto il tuo SIEM: lo completano. Il SIEM (Security Information and Event Management, il sistema che raccoglie, normalizza e conserva i log di sicurezza) resta il punto in cui i dati arrivano, vengono messi in ordine e conservati. Gli agenti AI aggiungono un livello diverso: leggono gli eventi con il contesto della tua azienda, collegano segnali che una regola non collegherebbe e preparano proposte motivate che una persona approva o rifiuta. L'integrazione tra i due mondi è una possibilità architetturale da concordare nel progetto, non un connettore già pronto per ogni prodotto di mercato.

Cosa fa bene un SIEM e dove si ferma

Se hai investito in un SIEM, hai messo in sicurezza una capacità fondamentale: raccogliere in un punto solo i log di firewall, server, applicazioni e sistemi di identità, normalizzarli in un formato comune, conservarli per il tempo necessario e poterci cercare dentro quando serve ricostruire un evento. A questo si aggiungono le regole di correlazione: condizioni scritte da persone che trasformano combinazioni di eventi in allarmi.

Questi pregi sono anche il confine naturale dello strumento:

• Le regole vedono ciò che qualcuno ha previsto. Una combinazione di segnali mai scritta in una regola non diventa un allarme, anche se è sospetta.
• Ogni allarme arriva come caso a sé. La domanda «questi tre eventi raccontano una storia sola?» resta sul tavolo dell'analista.
• Il contesto vive altrove. Sapere se quella modifica era una manutenzione approvata o se quel fornitore doveva davvero collegarsi sta nei ticket, nei calendari e nella memoria delle persone, non nel log.
• La decisione non è compito suo. Il SIEM segnala; cosa fare, con quali conseguenze e con quale priorità, resta una responsabilità umana.

La pubblicazione NIST SP 800-61 revisione 3 (aprile 2025) del NIST, l'istituto di standard e tecnologia degli Stati Uniti, descrive la risposta agli incidenti come parte della gestione complessiva del rischio: le raccomandazioni sono distribuite lungo le attività del Cybersecurity Framework 2.0, con ruoli e responsabilità definiti. Uno strumento di raccolta e correlazione copre una parte di questo percorso: preparazione, coordinamento e lezioni apprese richiedono processo e persone, non solo log.

Cosa aggiungono gli agenti AI: correlazione ragionata e proposte

Gli agenti AI lavorano su un piano diverso: non raccolgono i log al posto del SIEM, ma li leggono insieme al contesto disponibile e ragionano su ciò che vedono. In concreto, tre aggiunte:

• Correlazione ragionata. Collegano eventi che nessuna regola aveva previsto insieme — un accesso fuori orario, un trasferimento anomalo, una modifica di configurazione — e li presentano come un unico caso con una timeline, senza dare per certa una compromissione.
• Spiegazione e priorità. Ogni segnalazione arriva con il perché: cosa è stato osservato, quali fonti lo dicono, quali informazioni mancano ancora. È il terreno su cui si gioca la qualità del triage.
• Proposte con conseguenze. Invece di un allarme da interpretare, una proposta di intervento con opzioni, impatti e condizioni, che una persona approva o rifiuta.

Il confine resta esplicito: gli agenti propongono, le persone decidono. In OverZeus un intervento attivo richiede il piano visibile e l'approvazione prevista; il silenzio non viene interpretato come autorizzazione, e i limiti operativi sono applicati da controlli esterni al modello AI. Nessuna «sostituzione miracolosa»: la raccolta e la conservazione restano al SIEM, la responsabilità della decisione resta all'organizzazione.

Quali dati devono arrivare dal SIEM agli agenti

La risposta breve: il necessario per ragionare, non una copia di tutto. Duplicare l'intero flusso dei log dentro un secondo sistema crea costi e rischi senza aggiungere giudizio. Un perimetro realistico da concordare comprende:

• Gli allarmi e gli eventi rilevanti per i casi d'uso scelti, con la loro severità e la regola che li ha generati.
• I riferimenti ai log originali, così l'approfondimento avviene nel SIEM, che resta l'archivio unico: gli agenti puntano alle evidenze, non le duplicano.
• Il contesto concordato: inventario degli asset e loro proprietari, attività pianificate, calendario delle manutenzioni, elenco dei fornitori con accesso. È spesso il dato che manca di più, e quello che cambia di più la qualità delle proposte.
• Gli esiti delle decisioni: cosa è stato approvato, rifiutato o declassato, e perché. Servono a valutare nel tempo se il perimetro concordato è quello giusto.

Per iscritto, prima di partire: quali flussi si muovono, in quale direzione, con quale frequenza, chi è responsabile di mantenerli. Se un dettaglio non è definibile oggi, meglio dichiararlo che prometterlo.

Come evitare la doppia console per gli analisti

È l'obiezione più concreta di chi ha già un SOC (Security Operations Center, il centro operativo di sicurezza), anche piccolo: «i miei analisti non devono guardare due schermi». La risposta è organizzativa prima che tecnica, e vale tre regole:

1. Una sola superficie decisionale. Le proposte degli agenti devono arrivare dove la persona già lavora: come caso arricchito nel flusso esistente oppure in un'unica app di approvazione. Quale delle due forme adottare va deciso nel progetto, in base agli strumenti in uso.
2. Un solo stato per incidente. Chi stabilisce la priorità finale, chi può declassare e chi chiude il caso va scritto nero su bianco. Se due sistemi tengono due stati diversi dello stesso incidente, la confusione è garantita.
3. Il cerchio si chiude nel sistema di record. L'esito della decisione deve tornare dove il caso viene conservato, così fra sei mesi la ricostruzione è unica e completa. Su questo tema vedi anche come ricostruire un incidente tra timeline ed evidenze.

Se queste tre condizioni non sono definibili con il fornitore, l'integrazione rischia di aggiungere lavoro invece di toglierlo. Il punto di vista della persona che resta responsabile del caso è approfondito nell'articolo sul lavoro dell'analista SOC con l'AI.

Esempio illustrativo: l'accesso del fornitore alle due di notte

Esempio illustrativo. Lo scenario seguente mostra come i ruoli si dividono; non racconta un incidente avvenuto presso un cliente.

Un'azienda manifatturiera ha un SIEM da anni. Domenica alle 2:10 l'account di un fornitore di manutenzione accede in VPN (rete privata virtuale, il collegamento remoto cifrato con la rete aziendale); venti minuti dopo, dallo stesso account partono letture sul database delle commesse. Il SIEM genera due allarmi di severità media, separati, in coda con altri quaranta eventi del weekend. Li vedrà qualcuno lunedì mattina.

Con gli agenti collegati, il percorso cambia. Argus evidenzia lo scostamento: quell'account non ha mai lavorato in quella fascia oraria. Odysseus collega i due eventi in un caso unico con timeline, consulta le fonti autorizzate — calendario delle manutenzioni, ticket aperti — e non trova un intervento pianificato, senza per questo dichiarare una compromissione. Ares propone una priorità alta e un piano: prima verifica con il referente del fornitore, poi, se serve, la sospensione dell'account come misura specifica da approvare.

Il responsabile riceve il caso sull'app con fonti, ragionamento e opzioni. Decide di verificare prima di bloccare: scopre che il fornitore aveva un intervento d'emergenza concordato a voce con il caporeparto. Il caso si chiude come attività legittima, la motivazione resta registrata accanto alle evidenze, e si apre un miglioramento di processo: gli interventi d'emergenza devono finire nel calendario condiviso. Il SIEM aveva visto tutto; quello che mancava era il ragionamento sopra i dati.

Integrazione realistica con OverZeus: aspettative e limiti

OverZeus riunisce 16 agenti AI specializzati. Per questo scenario ne entrano in gioco tre, con ruoli distinti: Argus osserva in continuo eventi, servizi e dispositivi collegati ed evidenzia gli scostamenti dalla situazione attesa; Odysseus collega gli indizi e coordina i moduli in un piano comprensibile; Ares organizza priorità, indagini, escalation e proposte di contenimento, eseguendo solo le misure elencate e approvate. Accanto a loro, Mnemosyne conserva fonti, timeline, proposte, autorizzazioni ed esiti; Hermes porta segnalazioni e decisioni sull'app dei responsabili; Themis applica privilegi e limiti operativi con controlli esterni al modello AI.

Sull'integrazione con il tuo SIEM vale la massima onestà: non esistono connettori documentati come già disponibili verso prodotti specifici. Il collegamento è una possibilità architetturale da concordare — quali flussi leggere, con quale strumento, con quale formato — e va valutato nel progetto insieme al fornitore del SIEM. In cambio, il percorso di adozione permette di verificare il valore prima di toccare la produzione: con Oracle e la modalità di sola osservazione il sistema osserva e prepara proposte senza modificare nulla, per un periodo concordato.

Restano fermi anche i limiti: gli agenti non sostituiscono la raccolta e la conservazione dei log, non eliminano la necessità di persone responsabili e non promettono il rilevamento di ogni incidente. Se stai valutando soluzioni di questo tipo, la guida ai criteri per scegliere un SOC AI ti dà una griglia di prove da chiedere a ogni fornitore, OverZeus compreso.

In sintesi: due strumenti, due ruoli

Il SIEM resta la memoria e la cassaforte dei tuoi dati di sicurezza: raccolta, conservazione, ricerca. Gli agenti AI sono lo strato che ragiona sopra quei dati: correlano, spiegano, propongono e chiedono l'approvazione prevista prima di intervenire. L'integrazione funziona quando i ruoli sono scritti, i flussi sono minimi e dichiarati, e gli analisti guardano una sola superficie decisionale. Chi ti propone di buttare via il SIEM, o di aggiungere agenti senza chiarire questi confini, sta vendendo una sovrapposizione, non un'integrazione.

Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.

Tutti gli articoli OverZeus