Gli alert che nessuno legge

Perché il monitoraggio delle PMI si rompe prima dell’infrastruttura, e come una pipeline di analisi assistita dall’IA può restituire ai team ciò che manca davvero: la costanza.

Nella maggior parte delle infrastrutture che incontriamo il problema non è l’assenza di segnali. È il contrario: i segnali ci sono tutti, sono registrati correttamente, sono nel posto giusto — e nessuno li legge. Non per negligenza, ma perché leggerli davvero, tutti, tutti i giorni, non è un lavoro che una persona possa fare.

Il rumore ha già vinto

I numeri sul cosiddetto alert fatigue sono ormai poco controversi. Le organizzazioni ricevono in media circa 3.000 alert di sicurezza al giorno e ne lasciano non gestita una quota vicina ai due terzi; tra il 20% e il 30% non viene mai investigato in tempo utile. Il 2025 SANS Detection and Response Survey riporta che il 73% dei team di sicurezza indica i falsi positivi come principale ostacolo alla detection, e il report State of the SOC 2026 di Microsoft e Omdia stima che il 46% degli alert si riveli un falso positivo: quasi metà del carico di lavoro di un analista non produce alcun valore di sicurezza.

Il costo non è solo il tempo bruciato. È l’assuefazione. Un sistema che grida sempre smette di essere un sistema di allarme e diventa rumore di fondo: il 76% delle organizzazioni indica l’alert fatigue come una delle principali preoccupazioni operative, e circa tre quarti degli analisti dichiara di non avere più tempo per il lavoro proattivo. È il punto in cui il monitoraggio si è formalmente rotto pur continuando a funzionare.

SANS 2025 Detection & Response Survey, analisi di Stamus Networks — stamus-networks.com

Team sottodimensionati, sistemi mal calibrati

Nella piccola e media impresa questa dinamica si somma a due condizioni strutturali.

La prima è il dimensionamento. Lo studio ISC2 sulla forza lavoro cyber del 2025, su oltre 16.000 professionisti, registra che il 95% dichiara almeno una carenza di competenze in azienda e il 59% la definisce critica o significativa; l’88% ha subito almeno una conseguenza concreta di sicurezza riconducibile a quella carenza. Un terzo degli intervistati afferma semplicemente di non avere le risorse per presidiare adeguatamente il proprio perimetro. In una PMI italiana questo si traduce spesso in una persona, a volte mezza, che presidia tutto: rete, backup, postazioni, telefonia, e in aggiunta la sicurezza.

ISC2 Cybersecurity Workforce Study 2025 — isc2.org

La seconda è la configurazione. I sistemi di monitoraggio, quando ci sono, sono quasi sempre installati e mal calibrati. I sintomi si ripetono con una regolarità sospetta:

soglie lasciate ai valori di default del produttore, tarate su un’infrastruttura media che non è quella del cliente;
nessuna baseline: non esiste una definizione di “normale” per quell’ambiente, quindi non può esistere una definizione di anomalo;
alert su tutto ciò che è tecnicamente monitorabile, invece che su ciò che ha un impatto sul servizio;
notifiche che convergono su una casella condivisa che nessuno presidia, senza ownership né escalation;
nessuna correlazione tra sorgenti: lo storage, l’hypervisor e l’applicativo raccontano tre pezzi della stessa storia in tre posti diversi;
retention dei log troppo breve per accorgersi di un degrado che matura in settimane.

Il risultato è un impianto che genera lavoro invece di ridurlo, e che perde esattamente gli eventi che avrebbe dovuto intercettare: quelli lenti.

Il limite umano non è la competenza. È la costanza.

Vale la pena essere precisi su dove sta davvero il vantaggio di un sistema automatico, perché non è dove di solito si racconta.

Un sistemista esperto è molto più bravo di qualunque modello nell’interpretare un guasto conclamato: ha il contesto, conosce l’infrastruttura, sa cosa è stato toccato la settimana scorsa. Il punto è un altro. L’occhio umano è eccellente sull’anomalia macroscopica e strutturalmente cieco sul cambiamento graduale. Un evento che passa da tre a trenta occorrenze al giorno nell’arco di una settimana non “sembra” diverso quando si scorre un log: sembra normale, perché lo si è visto anche ieri. La differenza si vede solo contando, e contando sempre, sulla stessa metrica, per settimane.

È esattamente questo il tipo di lavoro che una pipeline ben calibrata fa senza degradare: non si stanca il venerdì pomeriggio, non salta il controllo perché c’è un’emergenza altrove, non abbassa la soglia di attenzione perché “quell’errore c’è sempre stato”. La costanza, non l’intelligenza, è la vera funzione delegata.

Un caso concreto: il disco che si era già rotto

Un cliente segnalava un sintomo tanto fastidioso quanto vago: blocchi di operatività quotidiani, della durata di alcuni minuti, dopo i quali tutto tornava a funzionare normalmente. Nessun errore riportato agli utenti, nessun servizio caduto in modo evidente, nessun alert. L’infrastruttura era un server Dell con ruolo di host Hyper-V.

Il monitoraggio hardware non segnalava nulla. iDRAC non aveva sollevato alcun predictive failure: i parametri di salute dei dischi rientravano nelle soglie previste dal vendor. Dal punto di vista del controller, l’infrastruttura era sana.

Abbiamo esportato integralmente i log dell’Event Viewer dell’host e li abbiamo sottoposti a un modello linguistico fornendo il contesto necessario: ruolo della macchina, natura del sintomo riportato, finestra temporale, configurazione dello storage. L’analisi ha isolato un pattern che non era un errore: un settore di un disco veniva riscritto ripetutamente, e la frequenza di quel comportamento era aumentata di circa dieci volte nell’ultima settimana rispetto alle precedenti.

Nessuno dei singoli eventi che componevano quel pattern era, di per sé, un alert. Il segnale non stava nell’evento: stava nella sua derivata.

Il dato è stato sufficiente a costruire una segnalazione tecnica circostanziata verso il produttore, che ha autorizzato la sostituzione del disco prima che il predictive failure venisse sollevato. Con la sostituzione, i blocchi di operatività sono cessati: quelle pause di alcuni minuti erano i tentativi ripetuti di scrittura sull’area degradata, che tenevano occupato lo storage sottostante l’intero host virtualizzato.

Il punto interessante non è che “l’IA ha trovato il guasto”. È che il guasto era scritto in chiaro nei log da settimane, accessibile a chiunque avesse contato quegli eventi giorno per giorno. Semplicemente, nessuno lo stava facendo — e nessun sistema era stato configurato per farlo.

Come si costruisce una pipeline di questo tipo

Un caso isolato è un aneddoto. Ciò che lo rende un metodo è la sua industrializzazione in un flusso ripetibile. L’architettura che proponiamo si articola su cinque stadi.

Deterministico dove basta, modello dove serve

L’errore più comune è affidare tutto al modello linguistico. È inefficiente e costoso: contare occorrenze, calcolare deviazioni e applicare soglie dinamiche è lavoro per una query e qualche riga di statistica, deterministico e verificabile. Il modello entra dopo, su un volume di dati già ridotto di ordini di grandezza, e serve per ciò che sa fare meglio di una regola: leggere insieme sorgenti eterogenee, formulare un’ipotesi e spiegarla in un linguaggio che un tecnico può verificare in dieci minuti.

I guardrail non sono opzionali

Nessuna azione distruttiva o non reversibile eseguita automaticamente. Riavvii, isolamenti di host, cancellazioni e modifiche di configurazione restano decisioni umane.
Ogni output del modello deve essere accompagnato dalle evidenze grezze su cui si basa, verificabili in autonomia dal tecnico. Un’ipotesi senza righe di log a supporto non è utilizzabile.
Il trattamento dei log va progettato tenendo conto della natura dei dati: minimizzazione, pseudonimizzazione dove necessario e scelta consapevole tra elaborazione on-premise e servizi esterni.
La pipeline va misurata come qualsiasi altro sistema di detection: falsi positivi, ma soprattutto falsi negativi. Un sistema che non sbaglia mai è quasi sempre un sistema tarato troppo largo.
La calibrazione non è un’attività di progetto, è manutenzione ordinaria. L’infrastruttura cambia, e con essa la baseline.

”Ma questo lo fa un SIEM”

Sì. Gran parte di questo carico di lavoro è esattamente ciò per cui esistono i SIEM enterprise, e nessuno qui sostiene il contrario. Il problema è di accessibilità reale, non di capacità tecnica.

Un SIEM non è un prodotto che si installa, si adotta. Richiede licenze proporzionate al volume di dati ingeriti, un progetto di onboarding delle sorgenti, una fase di tuning che dura mesi e, soprattutto, un presidio stabile che legga ciò che produce. Senza quel presidio, un SIEM diventa il generatore di alert più costoso dell’azienda: aggiunge rumore a un’organizzazione che stava già annegando nel rumore.

Ed è proprio la fascia che non se lo può permettere quella più esposta. Il Rapporto Clusit 2026 registra 5.265 incidenti cyber a livello globale nel 2025, con un incremento del 48,7% rispetto all’anno precedente il più elevato mai rilevato. Colloca l’Italia al 9,6% degli attacchi mondiali. In Italia le PMI rappresentano circa il 72% dei bersagli, con quasi una PMI su quattro che ha subito una violazione negli ultimi tre anni e un punteggio medio di maturità cyber fermo a 55 su 100, sotto la soglia di sufficienza. Sul fronte internazionale, il Verizon DBIR 2025 osserva che l’estorsione tramite ransomware compare nell’88% delle violazioni che coinvolgono piccole e medie imprese, contro il 39% delle grandi organizzazioni.

Rapporto Clusit 2026, ripreso da Innovation Post — innovationpost.it

Le pipeline non sostituiscono un SIEM. Sono il gradino che lo precede in chi non può ancora sostenerlo, e il moltiplicatore che ne riduce il rumore in chi lo ha già. Nell’ordine giusto: prima si mette qualcuno o qualcosa in grado di leggere davvero i segnali, poi si aumenta il numero di segnali raccolti. Farlo al contrario è il modo più affidabile per sprecare un budget di sicurezza.

Dove ci collochiamo

Fenix & Vega lavora esattamente in questa frattura: tra ciò che una tecnologia promette e ciò che l’organizzazione del cliente è realmente in grado di assorbire oggi. Non proponiamo lo strumento più avanzato disponibile sul mercato, ma quello che il cliente riuscirà a mantenere vivo tra dodici mesi.

Questo significa, a seconda dei casi, progettare e gestire noi la pipeline come servizio; oppure costruirla insieme al reparto IT interno e formarne le persone perché la sappiano leggere, calibrare e far evolvere in autonomia; oppure ancora accompagnare un’azienda già strutturata verso una piattaforma enterprise, ma solo quando esistono le condizioni organizzative per reggerla. La scelta non parte dalla tecnologia: parte da chi dovrà conviverci.

L’obiettivo dichiarato è banale e ambizioso insieme: alzare di un gradino il livello tecnologico dell’azienda, e far sì che quel gradino regga anche quando non c’è nessuno a guardare. Che poi è l’unica definizione operativa che conosciamo di dormire sonni tranquilli.

Fonti: Rapporto Clusit 2026; Verizon Data Breach Investigations Report (dato PMI: edizione 2025); 2025 SANS Detection and Response Survey; Microsoft / Omdia, State of the SOC 2026; ISC2 Cybersecurity Workforce Study 2025; Cybersecurity Insiders, 2025 SOC survey.