Gestione basata sul rischio delle vulnerabilità note sfruttate: come il KEV di CISA e gli assessment red team guidano la difesa delle infrastrutture italiane

Negli ultimi sette giorni, l’Agenzia per la Sicurezza delle Infrastrutture e della Cybersecurity (CISA) ha continuato ad arricchire il proprio Known Exploited Vulnerabilities (KEV) Catalog con nuove CVE sfruttate attivamente, mentre ha pubblicato il suo Vulnerability Review che offre una panoramica delle cause profonde delle compromissioni. Parallelamente, l’advisory “A Tale of Two SOCs” ha messo a confronto le capacità di rilevamento e risposta di due organizzazioni sottoposte a test red team. Questi documenti, insieme agli avvisi ICS su dispositivi quali ASE2000, Fuel‑Boss, Ebyte NA111‑M, Mitsubishi FA, Xiiaozet LK100W e Rockwell Automation OTTO Fleet Manager, forniscono un quadro chiaro su dove concentrarsi per una gestione del rischio realmente efficace. In questo articolo esploriamo come il modello basato sul rischio promosso da CISA, le indicazioni del Vulnerability Review e gli insegnamenti degli assessment red team possano tradursi in azioni concrete per le imprese italiane che operano in settori critici.

Il ruolo del KEV di CISA nella gestione del rischio

Il KEV Catalog di CISA elenca le vulnerabilità per cui esiste prova concreta di sfruttamento in ambiente reale. Le ultime aggiunte includono, ad esempio, due falle nel prodotto PaperCut NG/MF (CVE-2026-81578 e CVE-2026-82078) che consentono l’accesso non autenticato a funzioni critiche e l’uso improprio di reflection, nonché altre CVE relative a ownCloud, al kernel Linux e a JFrog Artifactory Fonte 9. Secondo il Binding Operational Directive (BOD) 26‑04, le agenzie governative statunitensi devono dare priorità alla remediazione di queste vulnerabilità su asset pubblicamente esposti che, una volta sfruttate, concedono il controllo totale del sistema Fonte 10. Anche se il BOD si applica solo alle agenzie federali, CISA raccomanda a tutte le organizzazioni di adottare un approccio basato sul rischio, concentrando le risorse sulle CVE presenti nel KEV piuttosto che disperdersi su migliaia di falle teoriche.

Il Vulnerability Review pubblicato il 26 agosto 2026 analizza i dati fiscali 2024‑2025 e dimostra che la maggior parte delle compromissioni deriva da errori di configurazione, software non patchato e credenziali deboli, piuttosto che da tecniche avanzate o zero‑day Fonte 10. Questo conferma che l’individuazione e la correzione delle vulnerabilità già note e sfruttate rappresenta il passo più efficace per ridurre la superficie di attacco. Per le aziende italiane, soprattutto quelle che gestiscono infrastrutture critiche (energia, manifattura, trasporti), integrare il KEV nei processi di vulnerability management significa:

• Mantenere un inventario aggiornato di tutti gli asset esposti a internet.
• Verificare quotidianamente la presenza di CVE elencate nel KEV su tali asset.
• Applicare le patch o le mitigazioni entro i tempi definiti dal BOD (tipicamente entro 48 ore per le vulnerabilità ad alto impatto).
• Documentare lo stato di sfruttamento pre‑patch, come richiesto dal BOD, per valutare se è necessario un’indagine forense.

Lezioni dagli assessment red team: detection e risposta

L’advisory “A Tale of Two SOCs” descrive due valutazioni red team condotte simultaneamente da CISA. In entrambi gli ambienti, il team rosso ha ottenuto il pieno dominio del dominio e ha acceduto a sistemi di business sensibili e risorse cloud. Tuttavia, le organizzazioni hanno reagito in modo molto diverso: l’Organizzazione A non è riuscita a rilevare o contenere l’attività, mentre l’Organizzazione B ha identificato rapidamente i primi tentativi di compromesso, isolato i sistemi interessati e costretto il rosso a operare sotto un modello “assume breach” Fonte 12.

Le lezioni apprese sono direttamente applicabili al contesto italiano:

1. Baseline e riduzione del rumore – Senza una linea di base ben definita e senza filtrazione degli alert, i difensori vengono sopraffatti da falsi positivi e avvisi di routine. Implementare sistemi di SIEM che si adattano al comportamento normale della rete e che riducono il volume degli alert è fondamentale per permettere agli analisti di concentrarsi sulle vere minacce.
2. Spezzare i silos organizzativi – La frammentazione della comunicazione, le responsabilità poco chiare e l’autorità limitata dei team di difesa ostacolano una risposta efficace. Creare un centro di operazioni di sicurezza (SOC) con autorità chiara, processi ben documentati e collaborazione tra IT, OT e cloud migliora la capacità di contenere un attacco.
3. Sottovalutazione degli ambienti cloud – Molte organizzazioni non prevedono controlli specifici per il cloud né procedure di risposta a un compromesso cloud. Dato che il red team ha potuto accedere a risorse cloud in entrambi gli scenari, è essenziale estendere le policy di sicurezza, i controlli di accesso condizionato e i meccanismi di logging anche alle workload cloud.
4. Efficacia degli strumenti dipende da persone e processi – Gli strumenti di detection sono utili solo se supportati da personale formato, procedure chiare e autorità di agire. Investire in formazione continua e in esercitazioni red team/blue team regolari aumenta la prontezza operativa.

Questi punti rispecchiano quanto indicato nel Vulnerability Review, che sottolinea l’importanza di passare da una postura reattiva a una proattiva, risolvendo le falle software alla radice piuttosto che limitarsi a rilevare gli sfruttamenti Fonte 10.

Casi studio: vulnerabilità nei dispositivi OT/ICS

Gli avvisi ICS pubblicati nello stesso periodo offrono esempi concreti di come le vulnerabilità note sfruttate si manifestino in dispositivi operativi critici. Di seguito sintetizziamo le più rilevanti, evidenziando il potenziale impatto e le mitigazioni consigliate.

• Applied Systems Engineering ASE2000 V2 Communications Test Set – Colpito da CVE‑2018‑1285 (XXE) e CVE‑2026‑18717 (validazione certificati TLS impropria). Un attaccante potrebbe leggere o scrivere file locali arbitrari, avviare richieste di rete in uscita o intercettare e modificare comunicazioni protette Fonte 2. La mitigazione consiste nell’aggiornare alla versione 2.38, che include una versione aggiornata di log4net e una corretta validazione dei certificati.

• All‑Line Equipment Company Fuel‑Boss – Affetto da CVE‑2018‑19518 (argument injection) e CVE‑2019‑11043 (classic buffer overflow) nello strumento IMAP Toolkit. Sfruttando queste falle, un aggressore può eseguire comandi arbitrari sul sistema operativo tramite nomi di server IMAP malevoli Fonte 3. Non è disponibile una patch ufficiale; la raccomandazione è di limitare l’accesso alla interfaccia IMAP a reti fidate e di monitorare i log per tentativi di injection.

• Ebyte NA111‑M – Una serie di CVE (dal 2026‑73125 al 2026‑77977) riguardano mancata autenticazione, uso di GET con query string sensibili, CSRF, mancata autorizzazione, trasmissione in chiaro di informazioni sensibili e uso di algoritmi crittografici deboli. Queste vulnerabilità permettono il completo compromesso del dispositivo Fonte 4. Il vendor ha dichiarato che è in corso lo sviluppo di una patch, ma non ha fornito tempistiche; la mitigazione suggerita è di disabilitare l’interfaccia web di gestione se non strettamente necessaria e di applicare firewall rigorosi.

• Xiiaozet LK100W – Affetto da CVE‑2026‑78037 (OS command injection), CVE‑2026‑78239 (bypass di autenticazione) e CVE‑2026‑76943 (altra funzione critica senza auth). Un attaccante autenticato può eseguire comandi di sistema con privilegi elevati, mentre un utente non autenticato può attivare servizi amministrativi riservati Fonte 6. La mitigazione consiste nell’aggiornare alla versione 2.1.240 o successiva.

• Rockwell Automation OTTO Fleet Manager – CVE‑2026‑75112 riguarda l’uso di un fattore di lavoro insufficiente nell’hashing bcrypt delle password, riducendo il costo di attacchi brute‑force offline su hash di password estratte da backup non cifrati Fonte 8. La soluzione è passare alla versione 2.36.3, che aumenta il work factor, oppure applicare le best practice di sicurezza di Rockwell per proteggere i backup.

• Mitsubishi Electric Multiple FA Products (Update D) – CVE‑2025‑3511 consente a un attaccante remoto di inviare pacchetti UDP specially crafted per causare denial‑of‑service, timeout o ritardi di comunicazione sui moduli CC‑Link IE TSN Remote I/O Fonte 5. Non è indicata una patch; la mitigazione prevede di filtrare il traffico UDP verso questi dispositivi a livello di rete.

Questi casi mostrano che, nonostante le vulnerabilità siano spesso note da mesi o anni, molti dispositivi rimangono esposti a causa di ritardi nell’applicazione delle patch, di mancata segmentazione di rete o di configurazioni di default non sicure. Per le aziende italiane che operano nei settori chimico, energetico, manifatturiero e dei trasporti, l’adozione di un inventario accurato di tutti gli asset OT, la verifica periodica della presenza di CVE nel KEV su tali asset e l’applicazione rapida delle mitigazioni disponibili sono passi indispensabili per ridurre il rischio di interruzione di servizio o di perdita di proprietà intellettuale.

Implicazioni per le aziende italiane e best practice

Alla luce delle informazioni raccolte dalle fonti sopra citate, le imprese italiane possono trarre alcune indicazioni operative:

1. Integrare il KEV nel ciclo di vita della vulnerabilità – Utilizzare il feed pubblico del KEV di CISA (disponibile via API o download JSON) per arricchire i propri scanner di vulnerabilità. Priorizzare la remediazione delle CVE presenti nel KEV su tutti gli asset con esposizione pubblica o critica, applicando le tempistiche suggerite dal BOD (48 ore per vulnerabilità ad alto impatto, 30 giorni per quelle a medio impatto).
2. Adottare un modello di sicurezza “assume breach” – Come dimostrato dall’Organizzazione B nell’advisory red team, presupporre che un attaccante possa già essere dentro la rete aiuta a focalizzare l’attenzione sul contenimento, sul monitoraggio dei comportamenti anomali e sulla segmentazione rigorosa (es. micro‑segmentazione OT/IT, zero trust).
3. Migliorare la visibilità su ambienti cloud e OT – Estendere i sistemi di log aggregation e di analisi comportamentale anche alle workload cloud e ai dispositivi industriali. Utilizzare strumenti di network traffic analysis (NTA) per rilevare traffico insolito verso dispositivi come l’Ebyte NA111‑M o il Fuel‑Boss, che spesso comunicano su protocolli legacy poco monitorati.
4. Gestire centralmente le patch e le configurazioni di default – Creare un processo di patch management che includa anche i dispositivi OT, con test di compatibilità in ambienti di staging prima del rollout. Dove il vendor non fornisce patch tempestive (es. Fuel‑Boss, Mitsubishi FA), applicare controlli di rete (firewall, IDS/IPS) e disattivare servizi non necessari.
5. Formazione e esercitazioni regolari – Investire in programmi di formazione continua per gli analisti di SOC, includendo scenari basati sulle CVE recenti del KEV e sui casi ICS citati. Eseguire esercitazioni red team/blue team almeno semestralmente per verificare l’efficacia delle detection e delle procedure di risposta.
6. Documentare e condividere le lezioni apprese – Dopo ogni incidente o esercitazione, produrre un report che descriva cosa è stato rilevato, quanto tempo è stato necessario per contenere l’evento e quali miglioramenti sono stati implementati. Condividere questi report internamente e, ove possibile, con consorzi di settore (es. ANIE, Confindustria) contribuisce ad alzare il livello di sicurezza collettivo.

In sintesi, le vulnerabilità note sfruttate rappresentano la minaccia più concreta e più gestibile per le organizzazioni oggi. Sfruttando il KEV di CISA, le indicazioni del Vulnerability Review e le lezioni dagli assessment red team, le aziende italiane possono passare da una strategia di patching reattivo a una gestione del rischio basata su evidenze, migliorando sia la resilienza delle proprie infrastrutture critiche che la capacità di rispondere rapidamente agli attacchi. L’adozione di queste pratiche non è più un’opzione, ma una necessità per proteggere la continuità operativa e la fiducia degli stakeholder in un contesto di minacce in continua evoluzione.