Falsi positivi nel SOC: come valutare la qualità del triage

Per ridurre i falsi positivi in un SIEM (Security Information and Event Management, la piattaforma che raccoglie gli eventi di sicurezza) o in un SOC (Security Operations Center, il centro operativo che li sorveglia) non basta «filtrare di più»: serve un triage di cui puoi giudicare la qualità. Un buon triage non è quello che scarta di più, ma quello in cui ogni scarto ha una motivazione leggibile, può essere riesaminato e riaperto, e in cui la chiusura definitiva di un allarme resta una decisione di una persona. Questa guida spiega da dove nasce il rumore, quali segnali osservare per capire se il triage butta via anche allarmi veri e cosa chiedere a un fornitore prima di fidarti.

Da dove arrivano i falsi positivi

Una piattaforma SIEM raccoglie registri ed eventi dai sistemi aziendali e li trasforma in allarmi. Il triage è il primo esame di questi allarmi: decidere in fretta cosa merita un'indagine, cosa può attendere e cosa va chiuso. Un falso positivo è un allarme che segnala un pericolo che non esiste; il problema opposto, spesso dimenticato, è il falso negativo: un segnale vero chiuso come rumore.

Il rumore nasce quasi sempre da cause riconoscibili:

• Regole troppo generiche. Una soglia pensata per un'azienda diversa dalla tua segnala comportamenti normali nel tuo contesto: il commercialista che lavora a fine mese, il tecnico che si collega di notte per una manutenzione concordata.
• Contesto mancante. Il sistema non sa che quell'accesso era autorizzato, che quel server è in dismissione, che quel giorno c'era un inventario. Senza contesto, ogni deviazione sembra sospetta.
• Fonti duplicate o mal collegate. Lo stesso evento arriva da tre strumenti e diventa tre allarmi; oppure una fonte smette di inviare dati e il silenzio viene scambiato per normalità.
• Cambiamenti dell'infrastruttura. Un nuovo gestionale, una migrazione, lo smart working esteso cambiano ciò che è «normale». Le regole calibrate sull'anno prima producono rumore, o peggio silenzio, dove non dovrebbero.

La tentazione, quando gli allarmi sommergono la squadra, è stringere le regole finché il rumore sparisce. Ma un quadro silenzioso non è un quadro pulito: può semplicemente essere un quadro cieco. Ecco perché la domanda giusta non è «quanti allarmi in meno ricevo», ma «posso verificare cosa è stato scartato, e perché».

Esempio illustrativo: l'allarme chiuso troppo in fretta

Esempio illustrativo. Lo scenario seguente è inventato e non racconta un incidente avvenuto presso un cliente; serve a mostrare cosa osservare, cosa manca e chi decide.

Una media impresa riceve di notte un allarme: un trasferimento di dati verso l'esterno, più voluminoso del solito, da un server applicativo. La regola che lo genera è nota per «sparare» spesso durante i backup, così l'allarme viene chiuso automaticamente come rumore, insieme ad altri quaranta della stessa notte. Il giorno dopo, un accesso amministrativo insolito a quel server riapre il caso: i due eventi, letti insieme, raccontano una storia diversa.

Cosa era stato osservato: un volume anomalo, in un orario anomalo, da una macchina specifica. Cosa mancava: il calendario delle attività pianificate, il collegamento tra i due eventi e una persona che valutasse la combinazione. Chi ha deciso: nessuno, di fatto — la regola ha deciso al posto dell'organizzazione, e nessuno poteva ricostruire con quali informazioni.

Con un triage di qualità quell'allarme poteva comunque essere chiuso: non è proibito scartare. La differenza è che la chiusura avrebbe avuto una motivazione scritta («coerente con la finestra di backup pianificata, fonte: calendario manutenzioni»), sarebbe rimasta riesaminabile e il secondo evento l'avrebbe riaperta automaticamente invece di partire da zero.

Come capire se il triage scarta segnali veri

Non esistono numeri universali: le statistiche sui falsi positivi dipendono dal contesto e vanno misurate sui tuoi casi. Esistono però segnali qualitativi che puoi osservare in qualsiasi sistema, anche senza competenza tecnica profonda:

• Ogni scarto ha una motivazione leggibile. Non «chiuso dal sistema», ma una ragione comprensibile, con la fonte del contesto usato. Se la motivazione manca o è generica, lo scarto non è verificabile.
• Gli scarti sono riesaminabili a campione. Una persona può estrarre periodicamente una quota degli allarmi chiusi e controllarli. Se nessuno riesamina mai ciò che è stato scartato, la qualità del triage è un atto di fede.
• Gli scarti si raggruppano per causa. Regola troppo larga, fonte mancante, contesto assente, orario: se non puoi dire perché si accumula il rumore, non puoi correggerlo alla radice.
• Uno scarto si può riaprire senza perdere la storia. Il caso dell'esempio mostra perché: l'evento di stanotte può dare senso a quello di ieri. Chiusura e riapertura devono conservare motivazioni ed evidenze.
• Gli scostamenti tra proposta e decisione sono registrati. Se il sistema propone priorità alta e la persona declassa, o viceversa, la divergenza va conservata con la motivazione: è la materia prima per migliorare regole e criteri.
• Dopo un incidente, le regole cambiano in modo tracciato. Se un allarme vero era stato scartato, la correzione (regola, contesto, procedura) deve risultare documentata, non affidata alla memoria di chi c'era.

La pubblicazione SP 800-61 revisione 3 del NIST (National Institute of Standards and Technology statunitense), uscita nell'aprile 2025, colloca la risposta agli incidenti dentro la gestione complessiva del rischio, con preparazione e lezioni apprese come parte integrante del processo. Applicata al triage, questa impostazione significa una cosa semplice: la qualità non si dichiara, si coltiva con riesami periodici e criteri scritti.

Chi risponde quando un allarme vero viene chiuso come falso positivo

La risposta breve: l'organizzazione, attraverso i ruoli che ha definito — non il modello, non il fornitore in astratto. L'automazione può preparare una proposta di chiusura o di escalation, ma la decisione che conta resta di una persona che opera dentro criteri concordati. Se quei criteri non esistono, o nessuno li ha mai verificati, il problema è organizzativo prima che tecnico.

Perché la responsabilità sia esercitabile e non solo nominale servono tre condizioni: criteri di gravità scritti e condivisi (coinvolge dati riservati? un account privilegiato? un servizio interrotto?), una registrazione di chi ha deciso cosa e con quali informazioni, e un percorso di escalation praticabile anche quando il primo responsabile non è raggiungibile. Su questi punti puoi approfondire con la guida su priorità ed escalation nel SOC.

C'è anche un caso limite istruttivo: il sistema propone di escalare e il responsabile declassa con motivazione. È legittimo, a patto che la scelta resti registrata: se domani l'allarme si rivela vero, quella decisione diventa la base per migliorare i criteri, non per cercare un colpevole. Il riesame serve al processo, non alla caccia alle streghe — altrimenti nessuno chiuderà più nulla e il rumore tornerà a vincere.

Cosa chiedere a un fornitore sulla gestione del rumore

Porta queste domande in demo, a qualsiasi fornitore, e chiedi di vedere le risposte nel prodotto, non solo nella presentazione:

• «Mostrami cosa hai scartato questa settimana e perché.» La schermata degli scarti motivati conta più della promessa di riduzione.
• «Come riesamino a campione gli allarmi chiusi, e cosa succede quando ne riapro uno?» Verifica che la storia del caso non si perda.
• «Chi può modificare le regole o il modello di triage, e con quale traccia?» Una modifica non registrata può creare silenzio invisibile.
• «Cosa succede se nessuno risponde a una richiesta di decisione?» Diffida di chi interpreta il silenzio come autorizzazione.
• «Come collegate gli eventi tra loro?» Il rumore spesso è lo stesso evento visto tre volte; il segnale vero spesso è due eventi banali letti insieme.
• «Quali riduzioni potete dimostrare, e su quali casi?» Percentuali generiche senza un perimetro di prova concordato non sono verificabili.

Trovi una lista più ampia nell'articolo sulle domande da fare in demo a un fornitore di SOC AI; per la griglia completa di confronto vale la guida su come scegliere un SOC AI per la tua azienda.

Come OverZeus affronta triage e rumore

OverZeus organizza il percorso dal segnale alla decisione con un confine netto: gli agenti osservano, collegano e propongono; la chiusura o l'escalation di un caso resta una scelta della persona. Gli agenti descritti in questo articolo sono quattro:

• Argus mantiene il monitoraggio continuo e rileva le anomalie nelle fonti collegate.
• Odysseus collega i segnali in una timeline unica, senza dare per certa una compromissione: è il passaggio che trasforma due eventi banali in un caso da leggere insieme.
• Ares organizza priorità, indagini ed escalation e prepara le proposte di contenimento; esegue soltanto le misure elencate e approvate.
• Mnemosyne conserva fonti, proposte, autorizzazioni ed esiti, incluse le chiusure motivate: è ciò che rende gli scarti riesaminabili e i casi riapribili senza perdere la storia.

Nel flusso OverZeus la proposta arriva con il contesto e l'approvazione prevista passa dall'app tramite Hermes; il silenzio non viene interpretato come autorizzazione. Themis applica privilegi e limiti operativi con controlli esterni al modello AI, così una richiesta fuori perimetro viene bloccata a prescindere da come è formulata.

Due avvertenze di onestà. Le integrazioni verso specifici SIEM e strumenti di raccolta vanno concordate per il progetto: la correlazione descritta dipende dalle fonti effettivamente collegate. E nessuna riduzione percentuale dei falsi positivi può essere promessa in astratto: va misurata sui tuoi casi, per esempio durante una prova in sola osservazione con Oracle e la Shadow Mode, in cui il sistema prepara proposte senza modificare la produzione.

Dal rumore al metodo

La fatica da allarmi non si risolve chiudendo più in fretta, ma rendendo ogni chiusura verificabile. Valuta il triage chiedendo: gli scarti sono motivati? Posso riesaminarli? So chi ha deciso e con quali informazioni? Un sistema che risponde bene a queste tre domande ridurrà il rumore in modo sostenibile; uno che promette solo silenzio, probabilmente, lo sta solo spostando fuori dalla tua vista.

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

Tutti gli articoli OverZeus