Nei miei quasi 30 anni come professionista della sicurezza informatica, ho spesso avuto la sensazione che stiamo cercando di risolvere i problemi sbagliati. Il mercato della sicurezza può essere estremamente rumoroso: non manca certo l’informazione, ma spesso fatichiamo a trovare quella giusta. Il rapporto segnale/rumore non è mai stato così critico e, per gestire una funzione tanto dinamica quanto strategica, abbiamo bisogno di dati accurati e tempestivi.
A volte facciamo le domande sbagliate
Ricordo un “security audit” intorno al 1996 – oggi lo chiameremmo più correttamente penetration test. L’organizzazione utilizzava un firewall Check Point e alcuni server UNIX; il firewall bloccava tutto tranne FTP e SMTP verso i sistemi Sun Solaris interni. Il server FTP era completamente aperto ed era stato compromesso per ospitare warez; il server SMTP, basato su Sendmail, era configurato come open relay. La domanda che mi venne posta fu: “Il firewall è configurato e funziona correttamente?”. La risposta era sì — sì, ma avevate comunque un gravissimo problema di sicurezza.
Quando iniziai a lavorare in Sophos nell’ottobre 2003, tutti chiedevano firewall client e software anti-spyware. Forse sarebbe stato più efficace adottare il processo Patch Tuesday appena introdotto, disabilitare gli script in Outlook e Outlook Express, limitare le macro, disattivare l’Autorun o combinare queste misure, che oggi sembrano ovvie. Spesso ci lasciamo distrarre da problemi visibili, come le toolbar del browser, trascurando quelli invisibili ma più critici.
Dire verità scomode
Molti di noi si confrontano con i propri pari per valutare maturità e progressi in ambito sicurezza. A livello generale funziona, ma tutto si complica quando analizziamo i fallimenti. Qui entra in gioco l’accordo di riservatezza: ciò che impariamo dai nostri errori non può essere condiviso. Non possiamo discutere le lezioni apprese. Ho visto centinaia di volte organizzazioni scegliere di nascondere i problemi. Per ciascuna può avere senso, ma da Sophos abbiamo osservato clienti cadere come tessere del domino per le stesse cause. (Questo ha rafforzato il nostro impegno alla trasparenza, sia nei mesi di analisi che precedono ogni Report sia in progetti aziendali come il Pacific Rim del 2024.)
L’effetto peggiore delle responsabilità legali che aziende e dirigenti affrontano dopo un incidente è assistere alla ripetizione degli stessi errori da parte di altri. Probabilmente. È difficile dirlo, visto che anche le altre vittime non possono parlare.
Da Bangkok a Calgary
Quando sei anni fa John Shier propose l’Active Adversary Report, ne fui entusiasta. Voleva analizzare cosa accade dopo l’accesso iniziale degli attaccanti; io vedevo l’opportunità di condividere le cause profonde, aiutando i responsabili sicurezza a imparare dagli errori altrui. Anonimizzando e aggregando centinaia di casi, possiamo evidenziare i problemi strutturali senza danneggiare reputazioni.
Il report di quest’anno si basa su oltre 600 casi in diversi settori a livello globale. Nonostante la varietà, molte organizzazioni affrontano problematiche ricorrenti che portano a incident response.
Ad esempio, solo il 16% degli incidenti del 2025 ha coinvolto vulnerabilità sfruttate, ma analizzando meglio scopriamo che il 52% riguardava appliance di sicurezza e il 33% applicazioni esposte su Internet. Spicca la CVE-2024-40766, vulnerabilità critica di SonicWall, dominante nei risultati di quest’anno. Questo indica dove concentrare gli sforzi e ripensare le priorità di patching nel 2026. Ulteriori dati saranno pubblicati nei prossimi mesi.
Allons-y
Abbiamo tutti molto lavoro da fare e questo report vuole guidare le priorità. È il più completo dalla prima edizione del 2020. Come l’anno scorso, i dati sono stati condivisi con Verizon per il Data Breach Investigation Report (DBIR). Inoltre, in nome della trasparenza, pubblichiamo i dataset su GitHub (periodo 2022–2025).
Vi invito a leggere il report completo: spesso il diavolo è nei dettagli, e i nostri ricercatori aiutano a interpretarli correttamente. Se scaricherete i dati da GitHub per ulteriori analisi, saremo lieti di conoscerne i risultati.

