Un ambiente enterprise, dodici mesi di osservazione. Il percorso è questo:

14,6 miliardi di dati processati. 270,4 mila eventi sospetti analizzati. 14,2 mila allarmi scattati. 796 incidenti gestiti.

La riduzione più ampia, in valore assoluto, è la prima: dai miliardi alle centinaia di migliaia. È il lavoro delle macchine, ed è un lavoro che nessuna organizzazione potrebbe fare a mano.

Ma la riduzione che conta davvero è l'ultima. Tra i 14.200 allarmi scattati e i 796 incidenti gestiti e condivisi con il cliente c'è un -94%.

È esattamente la parte del servizio che il cliente non percepisce, finché non apre le dashboard e scopre quanti allarmi sono stati esaminati e chiusi al posto suo.

E siccome quel 94% è fatto di tecnologia e di giudizio umano, dipende interamente da due cose: quante segnalazioni la tecnologia riesce a filtrare a monte, e quante informazioni ha in mano l'analista quando apre l'allarme. Un analista senza contesto non filtra: scala. È qui che la catena a monte smette di essere un dettaglio tecnico e diventa la variabile che decide tutto.

1. Dalla telemetria agli eventi sospetti: 14,6 miliardi → 270,4 mila

Il primo stadio decide cosa vale la pena guardare, ed è interamente automatico. La telemetria — processi, connessioni, eventi su file e registro, attività utente — viene raccolta integralmente e passata al motore di detection.

Halo, la piattaforma di Detection Engineering di Certego, è ciò che rende la telemetria grezza degli endpoint accessibile e analizzabile, invece che solo parzialmente visibile dentro la console EDR/XDR di un fornitore terzo. Ed è la condizione perché su quei dati si possa scrivere qualcosa di proprio.

Perché a questo stadio i rilevamenti hanno due origini diverse, e la differenza tra le due è la ragione per cui servono entrambe.

Gli alert nativi della soluzione EDR nascono da una telemetria globale: milioni di endpoint, in ogni settore e in ogni Paese, che alimentano una logica costruita su ciò che l'attaccante fa ovunque. Riconoscono i malware commodity, i tool di attacco noti, le tecniche già osservate su scala planetaria. È una capacità che nessuno può ricostruirsi in proprio.

Ha però un vincolo strutturale: è una logica che deve funzionare per decine di migliaia di organizzazioni diverse, quindi per costruzione è one-size-fits-all, calibrata sulla media di tutte e su nessuna in particolare. Funziona bene dappertutto, non funziona benissimo da nessuna parte.

Le regole di detection scritte da Certego non ripetono quel lavoro. Coprono ciò che quella logica non è progettata per vedere. Lavorano sulla telemetria grezza degli stessi endpoint, ma partono da due conoscenze che un modello globale non possiede: la normalità operativa di quella specifica azienda — gli applicativi verticali, il gestionale anni Duemila, gli script che girano in produzione alle tre di notte per ragioni legittime — e il modo in cui le minacce colpiscono il tessuto produttivo italiano: campagne malspam a tema fattura veicolate via PEC, kit di phishing localizzati, infrastrutture che testano per prime le imprese del nostro mercato. Difficilmente un vendor globale scriverà una regola per una campagna che riguarda qualche centinaio di aziende in un solo Paese. Non è una sua mancanza: è una questione di priorità di scala.

Le due origini non si sovrappongono: non si tratta di ricevere due volte l'allarme sullo stesso evento, né di aggiungere una seconda coda da smaltire. È copertura che arriva dove l'altra si ferma.

Un imbuto così stretto solleva però una domanda legittima. Scartare il 99,998% degli eventi è un risultato solo se ciò che resta è tutto ciò che conta: un filtro tarato troppo stretto non è efficiente, è cieco. Le regole costruite sul contesto servono esattamente a questo — far sì che la riduzione del volume non si paghi in falsi negativi.

C'è poi una quota di minacce che non compare nemmeno in questo conteggio, perché viene fermata prima di toccare gli endpoint: gli IOC verificati entrano nei controlli già in campo — blocklist dei firewall, IPS/IDS, proxy, resolver DNS, SIEM — e in casi documentati hanno prodotto un incremento dei blocchi tra il +10% nel finance e il +21% nel manufacturing, fino a 20 milioni di tentativi di connessione malevola fermati in una settimana. Eventi che non sono mai esistiti.

2. Dagli eventi agli allarmi: 270,4 mila → 14,2 mila

Un attacco non si presenta come un evento. Si presenta come decine di eventi distinti, su host diversi, in momenti diversi: un dominio contattato, un processo anomalo, una chiave di registro modificata, una connessione in uscita. Trattarli separatamente significa moltiplicare il lavoro per venti e perdere la storia che li tiene insieme.

Il secondo stadio serve a ricomporli. È il compito di PanOptikon®, la piattaforma di Unified Security Operations: alert nativi dell'EDR e rilevamenti prodotti dalle regole Certego entrano nella stessa pipeline, dove vengono deduplicati, correlati e aggregati in allarmi.

Qui il filtro cambia natura: non scarta, aggrega. Ed è la ragione per cui i 14.200 allarmi che arrivano allo stadio successivo sono unità di lavoro sensate — ciascuna con la sua catena di eventi già ricostruita — invece di 270.400 frammenti da riassemblare a mano.

3. Dagli allarmi agli incidenti: 14,2 mila → 796

È lo stadio del -94%, ed è quello in cui la decisione la prende una persona.

Ogni allarme viene aperto, esaminato e classificato da un analista del team SecOps prima che possa diventare qualcosa su cui il cliente è chiamato a collaborare. Novantaquattro volte su cento la conclusione è: il comportamento appartiene a un processo legittimo di quell'azienda, l'indicatore è già noto e non contestualizzabile come minaccia attiva, l'anomalia ha una spiegazione operativa.

Detto così sembra un lavoro di scarto. È l'opposto: è il punto in cui si decide, allarme per allarme, cosa merita l'attenzione di un'organizzazione. E la qualità di quella decisione dipende da tre cose, tutte costruite prima.

— L'arricchimento automatico. I controlli reputazionali di routine sugli osservabili non sono lavoro da analista. IntelOwl — nato nella divisione R&D di Certego e oggi progetto open source riconosciuto a livello internazionale — interroga da un'unica interfaccia molteplici fonti esterne e integra strumenti avanzati di analisi come Yara, Cuckoo e Passive DNS. Quokka assegna a ogni indicatore un verdetto con un livello di affidabilità dichiarato (A, B, C), la famiglia di malware associata, l'attore e la fase della kill chain. L'analista non apre un'indagine: apre un fascicolo già istruito.

— La telemetria completa. Un verdetto su un indicatore dice cosa è; capire cosa ha fatto richiede di poter guardare l'endpoint per intero. Poter risalire alla catena di esecuzione dentro Halo, senza dipendere da ciò che qualcun altro ha deciso di mostrare, è la differenza tra chiudere un allarme con una motivazione e chiuderlo con un'ipotesi.

— La logica ispezionabile. È l'aspetto meno discusso e il più decisivo, e riguarda una domanda semplice: perché è scattato questo allarme? Buona parte della logica di rilevamento nativa funziona in modalità black-box. Sai che un allarme c'è, a volte conosci la tecnica associata, raramente la condizione esatta che lo ha prodotto. Di fronte a una scatola nera restano due mosse, entrambe costose: crederle — e far uscire verso il cliente falsi positivi che nessuno può smentire — oppure ignorarla, abituando il team a saltare un'intera classe di allarmi. È così che un SOC diventa cieco senza accorgersene.

Una regola scritta dal team di Detection Engineering si comporta all'opposto: si sa quale telemetria legge, a quale condizione scatta, da quale incidente è nata. Si può leggere, discutere, correggere e — quando ha smesso di servire — spegnere. Non rende trasparente la logica del vendor, ma mette a disposizione il contesto per interpretarne il verdetto invece di subirlo.

Senza questi tre elementi il 94% semplicemente non si produce: l'analista che non ha contesto non può chiudere, e quello che non può chiudere scala. Il rumore riappare sul tavolo del cliente, con un'etichetta più autorevole.

4. I 796 che restano — e quelli che non torneranno

Gli incidenti che superano lo stadio umano arrivano al cliente già arricchiti, correlati, motivati e validati. E quando uno di essi supera la soglia della gestione ordinaria, il passaggio all'Incident Response Team non riparte da zero: le evidenze raccolte lungo tutti gli stadi precedenti sono già lì, nella stessa piattaforma.

Ma c'è un'ultima attività, ed è quella che impedisce alla catena di rifare ogni anno lo stesso lavoro.

— Il threat hunting trasforma gli indicatori più recenti in ipotesi di caccia immediate e permette di rileggere i dati storici alla luce di IOC emersi solo dopo, facendo riemergere minacce sfuggite in passato.

— La detection engineering chiude il cerchio, e agisce proprio sul punto più costoso della catena. Ogni falso positivo analizzato da un analista diventa una regola più precisa: è rumore che l'anno prossimo non arriverà nemmeno allo stadio umano. Ogni incidente reale diventa una detection che il giorno dopo è già in produzione. Ogni indicatore estratto da un attacco verificato entra nel patrimonio di intelligence e torna all'inizio della catena, dove blocca senza generare nulla.

Ed è qui che la prossimità pesa più di quanto sembri. Il perimetro osservato da Certego conta oltre 200 organizzazioni, in larghissima parte italiane, esposte alle stesse campagne e spesso nella stessa settimana, con IOC alimentati da deception assets — honeypot e spamtrap su infrastrutture italiane — e dai sensori negli ambienti monitorati. Quando un attacco colpisce un'azienda italiana, la probabilità che quella tecnica sia già stata vista, capita e tradotta in una regola altrove nel perimetro non è un auspicio: è il funzionamento ordinario del sistema.

Cosa cambia, in termini di business

Conclusione

Il -94% è la cifra che colpisce, ma il punto non è quanto viene scartato.

Il punto è che quel taglio è l'ultimo della catena, ed è l'unico in cui a decidere è una persona. Tutto ciò che viene prima — la detection sulla telemetria grezza, le regole scritte sul contesto, la correlazione degli eventi, l'arricchimento degli indicatori — serve a mettere quelle persone nella condizione di decidere in fretta e bene. Una catena che si ferma prima consegna al cliente lo stesso rumore, solo con qualche passaggio in meno.

Ed è per questo che i numeri da guardare in un servizio gestito non sono quelli grandi in cima all'imbuto. Sono i 796 in fondo: quanti ne arrivano, e in che stato arrivano.