Alert fatigue nel SOC: cos'è e come si riduce

La risposta breve: l'alert fatigue è la condizione in cui un team di sicurezza riceve più segnalazioni di quante ne possa esaminare, e smette di esaminarle davvero. Non nasce dalla scarsa attenzione degli analisti, ma da come è progettato il rilevamento: regole non calibrate, strumenti che segnalano lo stesso evento, soglie lasciate ai valori di fabbrica. Si riduce calibrando, correlando e presidiando, non aggiungendo console.

Che cos'è l'alert fatigue

Un sistema di rilevamento produce segnalazioni. Una parte descrive attività innocue, una parte descrive attività sospette che si rivelano innocue, una parte molto più piccola descrive un attacco in corso. L'alert fatigue compare quando il primo gruppo cresce al punto da rendere impraticabile la lettura del terzo.

Aiuta distinguere tre parole che si usano come sinonimi. ACN, nella Relazione annuale al Parlamento 2025, definisce l'evento cyber come un avvenimento d'interesse per il CSIRT Italia con potenziale impatto su almeno un soggetto nazionale, e l'incidente cyber come un evento cyber con impatto confermato dalla vittima o dal CSIRT Italia. In mezzo c'è il triage, la fase in cui gli operatori analizzano le segnalazioni per identificare i potenziali impatti e decidere se proseguire.

I numeri di quel documento danno la scala del lavoro. Nel 2025 il CSIRT Italia ha ricevuto 12.202 comunicazioni, ha trattato 2.729 eventi cyber (circa 227 al mese, contro i 165 del 2024) e ne ha classificati 615 come incidenti con impatto confermato. È un CSIRT nazionale e non la coda di un SOC aziendale, quindi il paragone non è uno a uno, ma la meccanica è la stessa: tra quello che arriva e quello che è davvero un incidente c'è un salto di ordine di grandezza, e quel salto lo percorre qualcuno, un elemento alla volta.

Perché non è un problema di persone

La lettura comoda è che servano analisti più attenti. La lettura corretta è che il volume sia una condizione di progetto. NIST SP 800-61r3, la revisione di aprile 2025 della guida all'incident response, lo mette per iscritto nella Tabella 3 del Community Profile, alla voce DE.AE (Adverse Event Analysis): "The volume of potentially adverse events to be analyzed is generally quite high, so organizations should rely on technical solutions that filter large event datasets down to a subset that is suitable for human viewing and analysis." Il volume alto è il punto di partenza, e la responsabilità che ne segue è costruire il filtro.

Nella stessa tabella, alla voce DE.CM (Continuous Monitoring), la raccomandazione è calibrare: "Tune the continuous monitoring technologies to reduce false positives and false negatives to acceptable levels." Va letta per intero: la calibrazione ha due direzioni, e tagliare i falsi positivi alzando le soglie fa scomparire anche detection che servivano.

Una terza indicazione smonta il modello mentale della coda. Alla voce RS.MA (Incident Management) NIST scrive che, a causa dei limiti di risorse, gli incidenti non vanno gestiti con il criterio di arrivo, e che triage ed escalation vanno basati su fattori di valutazione del rischio. Un SOC che lavora la coda dall'alto verso il basso sta già perdendo.

Regole non calibrate sul contesto

Una regola di detection è un'ipotesi sul comportamento normale di un ambiente. Se arriva dal manuale del vendor e non dal tuo, produce rumore strutturale: l'accesso notturno dell'operatore di turno, il job di backup che apre mille sessioni, lo scanner di vulnerabilità che assomiglia a una ricognizione. Informazioni che allo strumento non sono mai state date.

Strumenti sovrapposti che raccontano lo stesso evento

L'esecuzione di un file sospetto su un portatile genera una segnalazione dall'EDR, una dal firewall che vede la connessione in uscita, una dal filtro di posta che ha consegnato l'allegato e una dal SIEM. Quattro voci, un fatto solo: senza un livello che le unisca, il carico si moltiplica per il numero di strumenti installati.

Soglie ereditate dai default

I valori predefiniti sono tarati per un cliente medio che non esiste. Restano in piedi perché cambiarli richiede di sapere cosa è normale nell'ambiente, e quella conoscenza va costruita nelle prime settimane. Se non si costruisce, il rumore di fabbrica resta il livello di riferimento.

Nessun modello dei dati comune

Se ogni sorgente chiama in modo diverso lo stesso campo, l'utente, l'host, l'indirizzo, correlare non è più questione di regole: è archeologia. Normalizzare i log su uno schema condiviso è un lavoro noioso e a monte, che però determina quanto potrà essere buono tutto quello che viene dopo: per questo conviene capire cos'è un SIEM prima di scegliere cosa collegarci.

Cosa costa davvero: le conseguenze che si misurano

L'alert fatigue non si manifesta come un guasto, si manifesta come un rallentamento diffuso. I punti in cui si vede sono tre.

• Il tempo di triage per alert sale. Se la segnalazione arriva senza il contesto che serve a decidere, l'analista deve cercarlo in tre console diverse, e quella ricerca è il grosso del tempo speso.
• Il tempo di rilevamento si allunga. Non perché lo strumento non abbia visto, ma perché la segnalazione è rimasta in coda: i termini del problema sono in quanto tempo serve per accorgersi di un attacco.
• Il tempo di risposta eredita il ritardo. Il contenimento parte dopo, e ogni ora in più è tempo che l'attaccante usa per muoversi. La metrica e le leve per abbassarla sono in cos'è il MTTR.

Il rischio peggiore è però più silenzioso. NIST, alla voce DE.AE-08, raccomanda di tenere conto dei falsi positivi già conosciuti per decidere se dichiarare un incidente. Se quella lista è stata compilata per disperazione invece che per analisi, diventa il posto dove l'alert vero va a morire: un pattern silenziato sei mesi fa resta silenziato anche quando smette di essere rumore.

Come si interviene, in ordine di resa

L'ordine conta più dell'elenco: le prime due voci tolgono la quota più grossa di volume.

1. Calibrazione e soppressione dei duplicati. Si parte dalle regole che generano più volume, si guarda quante di quelle segnalazioni hanno prodotto un'azione reale, e si riscrivono quelle che non ne producono mai. Poi si decide quale strumento è la fonte autorevole per ciascun tipo di evento, così la stessa azione smette di arrivare quattro volte.
2. Arricchimento con il contesto che serve a decidere. Un alert utile dice chi è l'utente, quanto è critico l'asset, se quell'indirizzo è già noto, cosa è successo prima e dopo. NIST lo chiede alla voce DE.AE-07: integrare intelligence aggiornata e informazioni di contesto, per esempio gli inventari degli asset.
3. Correlazione e raggruppamento in incidenti. Alla voce DE.AE-03 NIST raccomanda tecnologie di correlazione che mettano insieme i dati collegati raccolti da più fonti. È il passaggio che trasforma quaranta segnalazioni in un caso solo, con una storia leggibile.
4. Playbook di triage. Per i casi ricorrenti serve una procedura scritta che dica cosa verificare, in che ordine e quando escalare. NIST, nella sezione 2.3, mette le linee guida per prioritizzare gli incidenti tra gli elementi di una policy di incident response, e tiene i playbook su un piano diverso: sono un formato in cui documentare le procedure, e scrivere le procedure in un playbook invece che in un altro formato può migliorarne l'usabilità.
5. Agenti AI sul primo livello. Raccogliere il contesto, confrontare con i casi già visti, scartare il rumore evidente e preparare il caso per una persona sono passaggi ripetitivi e ben definiti: è il lavoro che un agente AI può prendere in carico, lasciando agli analisti la decisione. Il modello resta supervisionato, con un registro di cosa l'agente ha fatto.
6. Presidio continuo. Nessuna delle leve precedenti produce effetto se la coda viene guardata solo in orario d'ufficio. Gli attacchi si muovono di notte e nel fine settimana perché è allora che non la legge nessuno.

Come si misura se sta migliorando

Senza numeri, ogni intervento sul rumore resta una questione di impressioni. NIST, sempre nella sezione 2.3, mette le misure di performance tra gli elementi di una policy di incident response. Cinque indicatori bastano, letti come serie nel tempo.

• Volume di alert per analista e per turno. È il carico grezzo. Se non scende, tutto il resto è cosmetica.
• Quota di falsi positivi. Va calcolata sugli alert effettivamente lavorati, non sul totale generato, altrimenti misura la capienza della coda e non la qualità del rilevamento.
• Tempo medio di triage per alert. Risponde per primo all'arricchimento: quando scende, le informazioni per decidere arrivano insieme alla segnalazione.
• Quota di alert escalati. Dice se il primo livello filtra o smista. Se cresce mentre il volume scende, a passare sono i casi giusti.
• Tempo di rilevamento e tempo di risposta. Sono l'esito, non la causa. Se il carico scende ma restano fermi, il collo di bottiglia è a valle del triage.

Per tutte e cinque vale la stessa accortezza: definire prima quando parte e quando si ferma il cronometro, altrimenti si confrontano numeri che misurano cose diverse.

Il punto onesto

Nessuno strumento risolve l'alert fatigue se nessuno ha il tempo di leggere e decidere. Si può calibrare, correlare e arricchire bene, e restare con una coda che cresce, perché chi la guarda ha altre otto cose da fare. Il rumore si riduce di molto, non a zero.

Da qui le due risposte legittime, che non si escludono. La prima è un percorso di calibrazione sul proprio ambiente: costa settimane di detection engineering e produce l'effetto più duraturo, perché agisce sulla causa. La seconda è affidare il presidio a chi lo fa di mestiere, con processi di triage già scritti e copertura continua: i due modelli sono a confronto in SOC interno o SOC gestito. Con un equivoco da chiarire: un servizio gestito senza calibrazione eredita lo stesso rumore.

In sintesi

L'alert fatigue è un problema di progettazione del rilevamento, non di attenzione delle persone: nasce da regole non calibrate, strumenti che raccontano lo stesso fatto più volte, soglie di fabbrica e dati che non parlano una lingua comune. Si vede nei tempi di triage, rilevamento e risposta. Si affronta nell'ordine: calibrare, arricchire, correlare, scrivere i playbook, mettere gli agenti AI sul primo livello, presidiare in continuo.

Se il problema è già sul tavolo e la domanda è come ridurre il rumore nel tuo ambiente, puoi vedere come lo affrontiamo nei servizi di observability e SecOps. Se manca il quadro d'insieme, il punto di ingresso è cos'è un SOC e come funziona.