Anche un buon sistema di monitoraggio può non vedere un incidente: manca una fonte, una credenziale è legittima, la tecnica è nuova o il comportamento sembra normale. Il rimedio non è inseguire la copertura perfetta, ma trattare ogni segnale come un indizio da verificare: stratificare fonti diverse, incrociare i controlli e prevedere revisioni umane regolari. Questa guida spiega cosa può sfuggire, come ridurre i falsi negativi senza illudersi e perché la fiducia cieca nel rilevamento è un rischio di governance.
I falsi negativi: il lato meno raccontato del rilevamento
Nel racconto commerciale della sicurezza si parla quasi sempre di falsi positivi: gli allarmi che si rivelano rumore e fanno perdere tempo. Esiste però il problema opposto, più silenzioso: il falso negativo, cioè l'evento reale che il sistema non segnala. Un falso positivo costa attenzione; un falso negativo costa la scoperta tardiva di un incidente.
Cosa può sfuggire anche a un buon monitoraggio? Le cause ricorrenti sono poche e concrete:
- Fonti mancanti o incomplete. Un sistema non collegato, un registro disattivato, un applicativo che non produce log: ciò che non viene osservato non può essere rilevato. Il perimetro di raccolta definisce il perimetro di visibilità.
- Comportamenti legittimi in apparenza. Chi entra con credenziali valide, usa strumenti amministrativi normali e agisce negli orari previsti può non generare alcuna anomalia. Il rilevamento basato su regole o su modelli statistici fatica proprio dove l'abuso assomiglia al lavoro quotidiano.
- Tecniche nuove o insolite. Un metodo mai visto prima non corrisponde a nessuna regola scritta e può rientrare nella normalità statistica finché qualcuno non lo riconosce.
- Contesto cambiato. Dopo una riorganizzazione, un nuovo gestionale o un cambio di fornitore, ciò che era anomalo può diventare normale e viceversa. Un sistema calibrato sul passato può tacere proprio quando serve, un fenomeno legato alla deriva dei modelli nel tempo.
- Rumore che copre il segnale. Quando gli allarmi sono troppi, l'evento importante rischia di restare sepolto tra gli altri: tecnicamente rilevato, di fatto non visto. È uno dei motivi per cui la qualità del triage conta quanto il rilevamento stesso.
La pubblicazione SP 800-61 revisione 3 del NIST (National Institute of Standards and Technology, l'ente tecnico del governo statunitense), pubblicata in forma finale nell'aprile 2025, colloca rilevamento e analisi dentro la gestione complessiva del rischio, lungo le funzioni del Cybersecurity Framework 2.0. Il punto utile qui è metodologico: rilevamento e analisi sono attività continue da preparare, migliorare e riesaminare dopo ogni incidente, non un interruttore acceso una volta per tutte. Ammettere che il rilevamento è imperfetto non è un'ammissione di debolezza: è la premessa per gestirlo seriamente.
Esempio illustrativo: l'esportazione della domenica
Esempio illustrativo. Lo scenario seguente è inventato a scopo didattico; non racconta un incidente avvenuto presso un cliente.
Un'azienda logistica usa un account di servizio per esportazioni automatiche dal gestionale del magazzino, ogni notte verso le due. Una domenica mattina lo stesso account avvia un'esportazione analoga ma molto più ampia del solito. Dal punto di vista formale tutto torna: credenziali valide, strumento abituale, destinazione consueta, rete interna. Nessuna regola scatta.
Un agente di monitoraggio come Argus, che osserva in continuo le fonti collegate, nota però due deviazioni deboli: l'orario insolito e il volume cresciuto. Non sono una prova di compromissione: sono un indizio. Artemis, che distingue un'anomalia da una compromissione confermata, raccoglie il contesto disponibile: nessuna manutenzione risulta pianificata, nessun inventario straordinario è stato richiesto, l'account appartiene a un processo automatico che nessuna persona sta usando in quel momento. Il caso passa ad Ares, che prepara una proposta: sospendere temporaneamente l'account o ridurne i permessi di esportazione, spiegando che la sospensione fermerebbe anche le esportazioni legittime della notte successiva.
La decisione resta a una persona. Il responsabile verifica con chi gestisce il gestionale, scopre che nessuna modifica era autorizzata e approva la sospensione. Se invece fosse emersa una manutenzione concordata e registrata male, la scelta documentata sarebbe stata di non intervenire. In entrambi i casi il valore sta nel passaggio: un segnale debole è stato trattato come indizio, verificato da un umano con il contesto aziendale, e la decisione è rimasta tracciata.
Nota bene il limite: se l'account avesse lavorato nel solito orario, con volumi e destinazioni abituali, anche questa catena avrebbe potuto non vedere nulla. Nessun esempio ben costruito elimina l'angolo cieco.
Stratificare: fonti diverse, controlli incrociati, revisioni umane
Se nessun singolo rilevamento vede tutto, la strategia è stratificare: più punti di osservazione indipendenti, in modo che ciò che sfugge a uno possa emergere in un altro. In pratica:
- Allargare le fonti prima di affinare le regole. Identità e accessi, rete, endpoint, applicativi, backup: ogni fonte aggiunge un punto di vista. Una copia fallita o un accesso privilegiato possono essere invisibili in un registro ed evidenti in un altro.
- Incrociare i controlli. Un'anomalia debole in due fonti diverse vale più di un allarme forte in una sola. Collegare gli indizi in una timeline unica con le evidenze aiuta sia la verifica immediata sia la ricostruzione successiva.
- Verificare ciò che è stato scartato. La domanda giusta a chi gestisce il monitoraggio — interno o esterno — non è solo «cosa hai segnalato» ma «cosa hai scartato e perché». Una revisione periodica degli eventi chiusi come rumore è uno dei modi più semplici per scoprire falsi negativi.
- Prevedere ricerca attiva. Accanto al rilevamento automatico serve chi va a cercare: il threat hunting parte da ipotesi («e se qualcuno usasse queste credenziali di servizio fuori orario?») invece di aspettare un allarme.
- Riesaminare dopo i cambiamenti e dopo gli incidenti. Nuovi sistemi, nuovi fornitori, nuove abitudini di lavoro spostano la normalità. La revisione post-incidente indicata dalla SP 800-61r3 serve anche ad aggiornare ciò che si osserva e come.
La verifica umana non è il ripiego di quando l'automazione fallisce: è un livello del disegno. Il lavoro dell'analista con il supporto dell'AI consiste proprio in questo: giudicare indizi con contesto che il sistema non ha, e assumersi la responsabilità della chiusura o dell'escalation.
Aspettative corrette verso fornitori e direzione
La fiducia cieca nel rilevamento è un rischio di governance perché trasforma uno strumento probabilistico in una garanzia che nessuno può dare. Se la direzione crede che «il sistema vede tutto», ogni incidente non rilevato diventa una sorpresa ingiustificabile; se invece i limiti sono dichiarati, il non rilevato rientra in un rischio noto, con presidi e responsabilità definiti.
Verso i fornitori, tre domande tengono le aspettative oneste:
- Cosa il sistema non vede? Chiedi per iscritto fonti coperte e non coperte, casi in cui serve una persona, errori ammessi. Una risposta precisa è un segno di serietà; «copriamo tutto» è un segnale d'allarme.
- Come mostri ciò che hai scartato? Eventi chiusi come rumore, anomalie declassate, casi senza conclusione: la trasparenza su ciò che non è diventato allarme vale quanto quella sugli allarmi.
- Come si misura la qualità nel tempo? Su casi concordati con esito noto, compresi eventi innocui e fonti mancanti, non su promesse generali. È uno dei criteri anche nella guida per scegliere un SOC AI per la tua azienda (un SOC, Security Operations Center, è il centro che sorveglia gli eventi di sicurezza).
Verso la direzione, la comunicazione corretta suona così: «osserviamo queste fonti, con questi limiti; gli allarmi sono indizi verificati da persone; ciò che non vediamo è un rischio che presidiamo con controlli incrociati e revisioni periodiche». È un messaggio più difficile di «siamo coperti», ma è l'unico che regge alla prima verifica dei fatti.
Come OverZeus tratta i segnali
Questo articolo descrive il metodo prima del prodotto, e il metodo vale anche per OverZeus: nessun sistema di rilevamento — OverZeus incluso — può promettere una copertura completa. Ciò che il progetto dichiara è come i segnali vengono trattati una volta osservati:
- Argus mantiene il monitoraggio continuo sulle fonti collegate e segnala le anomalie, anche quelle deboli che una regola rigida ignorerebbe.
- Artemis svolge la ricerca attiva: distingue un'anomalia da una compromissione confermata e dichiara quando le evidenze non bastano per concludere.
- Ares organizza priorità, indagine ed escalation e prepara proposte di contenimento, eseguendo solo le misure elencate e approvate.
Attorno a loro, Themis applica limiti e autorizzazioni con controlli esterni al modello AI, e Mnemosyne conserva fonti, proposte, autorizzazioni ed esiti, segnalando le lacune invece di ricostruirle a posteriori. Il passaggio decisivo resta umano: gli agenti spiegano la proposta e le conseguenze, e il silenzio non autorizza alcun intervento attivo.
Questa architettura riduce il rischio che un indizio vada perso tra il rilevamento e la decisione, ma non elimina gli angoli ciechi a monte: ciò che non è collegato, non è registrato o assomiglia del tutto alla normalità può non essere visto. Per questo la prova su casi concordati, le integrazioni definite per iscritto e la revisione periodica degli scarti restano parte del progetto, non accessori.
La misura giusta: diffidenza organizzata
Ridurre i falsi negativi senza inseguire la perfezione significa investire dove il rapporto tra sforzo e visibilità è migliore: più fonti, controlli incrociati, revisione degli scarti, ricerca attiva, riesame dopo ogni cambiamento. E significa dichiarare i limiti a fornitori, direzione e team, perché un rischio ammesso si governa, un rischio negato si subisce. I segnali sono indizi: il valore sta nel percorso con cui diventano decisioni verificate.
Vuoi vedere come un segnale debole diventa una decisione tracciata, con limiti e approvazioni chiari?
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.