cybersecurity
Oltre l'hype dell'IA: la CISA Vulnerability Review svela il vero volto della cybersecurity industriale nel 2026
Mentre l'attenzione mediatica si concentra sull'IA, l'analisi CISA e numerosi advisory ICS mostrano che la maggior parte dei compromessi deriva da fallimenti basilari: vulnerabilità decennali sfruttate, dispositivi OT senza autenticazione e vendor che ignorano le segnalazioni. Cosa dicono i dati alle aziende italiane.
È facile farsi abbagliare dalle narrazioni sull'intelligenza artificiale generativa che riscrive le regole dell'attacco e della difesa. Ma se si guarda ai dati grezzi — quelli che la Cybersecurity and Infrastructure Security Agency (CISA) ha pubblicato nell'ultima Vulnerability Review e nei bollettini ICS della scorsa settimana — emerge un quadro molto meno futuristico e molto più urgente: la stragrande maggioranza degli incidenti non nasce da tecniche all'avanguardia, ma da «fallimenti di sicurezza basilari» che consentono agli attori di minaccia di scansionare Internet alla ricerca di vulnerabilità note, ben documentate e spesso vecchie di anni (CISA Vulnerability Review).
La settimana dal 25 al 27 agosto 2026 ne è una dimostrazione lampante. In pochi giorni CISA ha pubblicato dodici advisory ICS che coprono vendor globali — Siemens, Rockwell Automation, Mitsubishi Electric, Xiiaozet, Ebyte, All-Line Equipment, Applied Systems Engineering — e ha aggiornato tre volte il catalogo Known Exploited Vulnerabilities (KEV), aggiungendo dieci CVE complessivi, di cui sei risalenti al 2015-2022 (CISA Adds Six Known Exploited Vulnerabilities to Catalog) (CISA Adds Three Known Exploited Vulnerabilities to Catalog) (CISA Adds One Known Exploited Vulnerability to Catalog). Non sono «zero-day» esotici: sono debiti tecnici mai saldati che continuano a generare interessi composti per chi li ignora.
Il paradosso del KEV: vulnerabilità legacy ancora armate
Il catalogo KEV è diventato il termometro del rischio reale. La direttiva operativa vincolante BOD 26-04 impone alle agenzie federali civili statunitensi di dare priorità assoluta alle CVE presenti nel catalogo su asset esposti pubblicamente, differendo quelle a rischio inferiore (CISA Adds Three Known Exploited Vulnerabilities to Catalog). Ma ciò che colpisce negli ultimi inserimenti è l'età media delle vulnerabilità: CVE-2015-3246 (Libuser race condition), CVE-2015-5287 (ABRT privilege escalation), CVE-2019-1068 (Microsoft SQL Server RCE), CVE-2021-23758 (Ajax.NET deserialization), CVE-2022-0995 (Linux kernel out-of-bounds write) (CISA Adds Six Known Exploited Vulnerabilities to Catalog). Vulnerabilità che hanno dai 4 agli 11 anni, per le quali patch esistono da anni, vengono ancora sfruttate attivamente nel 2026.
A queste si aggiungono CVE recenti ma già armate: CVE-2023-49105 (ownCloud improper authentication), CVE-2026-53362 (Linux kernel), CVE-2026-66384 (JFrog Artifactory path traversal) (CISA Adds Three Known Exploited Vulnerabilities to Catalog) e CVE-2026-60004 (Gitea code injection) (CISA Adds One Known Exploited Vulnerability to Catalog), oltre a CVE-2026-8452 su Citrix NetScaler (CISA Adds Six Known Exploited Vulnerabilities to Catalog). Il messaggio è chiaro: il tempo tra la disclosure e l'exploitation si sta accorciando, ma la coda lunga delle vulnerabilità legacy rimane il vettore dominante.
Per le imprese italiane — molte delle quali gestiscono parchi applicativi eterogenei, spesso con componenti legacy non aggiornabili senza fermi produzione — il KEV non è una lista di «cose da fare per la compliance USA», ma una mappa di priorità basata su evidenze di sfruttamento reale. Ignorare una CVE-2015 presente nel KEV significa accettare consapevolmente un rischio che gli avversari stanno già convertendo in accesso iniziale.
L'emergenza OT/ICS: quando il «critical manufacturing» non ha password
Se il KEV racconta la persistenza del passato, gli advisory ICS della scorsa settimana raccontano la fragilità del presente industriale. Il caso più eclatante è Siemens SIMATIC IoT2050 Advanced: un dispositivo edge pensato per l'Industria 4.0, diffuso in settori Chemical, Critical Manufacturing, Energy, Transportation Systems worldwide, che espone l'interfaccia HTTP di Node-RED senza alcuna autenticazione (Siemens SIMATIC IoT2050 Advanced). CVSS 10.0. Un attaccante non autenticato può creare flussi malevoli ed eseguire codice arbitrario con privilegi massimi sul server sottostante. Siemens ha rilasciato la versione 4.3.4.1, ma quante installazioni italiane — magari gestite da system integrator terzi — hanno già applicato l'aggiornamento o, come mitigazione temporanea, disinstallato Node-RED o ne hanno indurito la configurazione?
Non è un caso isolato. Xiiaozet LK100W (CVSS 9.8) presenta OS command injection, missing authentication for critical function e authentication bypass sull'interfaccia di gestione web (Xiiaozet LK100W). Ebyte NA111-M accumula tredici CVE in un solo firmware (9013-2-17), tra cui missing authentication, CSRF, cleartext transmission/storage of sensitive information, weak/broken crypto, client-side authentication (Ebyte NA111-M). Il vendor cinese ha riconosciuto le segnalazioni ma non ha più risposto alle richieste di coordinamento e CISA non è stata informata del rilascio di patch: un classico caso di vendor abandonment che lascia i clienti — potenzialmente anche in Italia, dato il deployment «Worldwide» — senza rimedio ufficiale.
Rockwell Automation OTTO Fleet Manager (<= V2.36.2) usa un work factor insufficiente in bcrypt, riducendo il costo computazionale per attacchi offline brute-force su hash di password rubati da backup non cifrati (Rockwell Automation OTTO Fleet Manager). CVSS 6.8, ma l'impatto operativo su flotte di robot mobili autonomi in ambienti Critical Manufacturing e Transportation Systems può essere sproporzionato.
Due advisory Mitsubishi Electric completano il quadro: la serie CNC (CVE-2025-2399, CVSS 5.9) presenta out-of-bounds read che causa DoS remoto su decine di modelli M800/M80/E80/C80/M700/E70 (Mitsubishi Electric CNC Series (Update A)); i moduli CC-Link IE TSN Remote I/O (CVE-2025-3511) possono subire DoS, timeout o ritardi di comunicazione da un singolo pacchetto UDP specially crafted (Mitsubishi Electric Multiple FA Products (Update D)). Settore: Critical Manufacturing, deployment mondiale.
A questi si aggiungono All-Line Equipment Fuel-Boss (CVE-2018-19518, CVE-2019-11043, CVSS 8.7) — vulnerabilità PHP di sei-sette anni fa su sistemi di gestione carburante usati in Critical Manufacturing, Defense Industrial Base, Emergency Services, Transportation Systems (All-Line Equipment Company Fuel-Boss) — e Applied Systems Engineering ASE2000 V2 (CVE-2018-1285, CVE-2026-18717, CVSS 9.8) con XXE su log4net e validazione certificati TLS difettosa su dispositivi usati in Chemical, Critical Manufacturing, Energy, Water and Wastewater (Applied Systems Engineering ASE2000 V2 Communications Test Set).
Il denominatore comune non è la sofisticazione dell'attacco, ma l'assenza di controlli basilari: autenticazione, validazione input, cifratura, gestione sicura delle dipendenze terze. Dispositivi che controllano processi fisici — robot, CNC, I/O remoti, test set per telecontrollo — espongono interfacce di gestione come se fossero blog personali.
Secure by Design: dalla teoria alla pratica (o il costo di non farla)
Il CISA Vulnerability Review analizza dati degli anni fiscali 2024-2025 per stabilire una baseline prima che la scoperta di vulnerabilità individuate tramite IA diventi pervasiva (CISA Vulnerability Review). La conclusione centrale è che i principi Secure by Design — spostare l'onere dalla reazione alla prevenzione, eliminare classi intere di debolezze (CWE) alla radice — non sono opzionali: sono l'unica via per ridurre la superficie d'attacco in modo sistemico.
La review identifica le common software weaknesses che alimentano vulnerabilità sfruttabili e dettaglia pratiche per i produttori di software: eliminare intere classi di bug (es. memory safety con linguaggi sicuri, input validation by default, secure defaults per autenticazione e autorizzazione), adottare threat modeling precoce, fornire SBOM e vulnerability disclosure programs efficaci. Il framework di priorità della BOD 26-04 — exposure status, KEV status, potential for automated exploitation, impact — offre alle organizzazioni una bussola per decidere cosa patchare per primo quando le risorse sono finite (CISA Vulnerability Review).
Per il tessuto industriale italiano — PMI manifatturiere, utility, trasporti, sanità — la lezione è duplice. Lato domanda: pretendere Secure by Design nei capitolati d'appalto, richiedere SBOM, verificare che i vendor abbiano un Product Security Incident Response Team (PSIRT) reattivo (il caso Ebyte insegna che non tutti ce l'hanno (Ebyte NA111-M)), includere clausole di end-of-life e patch guarantee nei contratti. Lato offerta: i system integrator e vendor italiani che esportano componenti OT/ICS devono internalizzare che la sicurezza non è un «optional» da vendere a parte, ma un requisito di product liability emergente — anche in Europa con il Cyber Resilience Act e la NIS2.
La gestione del rischio basata su evidenze: oltre il CVSS
Il CVSS rimane utile, ma insufficiente. Il KEV aggiunge la dimensione temporale e operativa: «questa vulnerabilità è stata sfruttata in the wild». La BOD 26-04 aggiunge la dimensione contestuale: «questo asset è esposto pubblicamente e concede controllo totale post-exploitation?» (CISA Adds Three Known Exploited Vulnerabilities to Catalog).
Applicato al caso Siemens IoT2050: CVSS 10, KEV? (non ancora, ma exploitation è banale), asset esposto pubblicamente? Spesso sì, perché Node-RED è pensato per essere accessibile via web. Priorità: immediata. Caso Mitsubishi CNC: CVSS 5.9 (DoS), KEV? No, ma se il CNC governa una linea just-in-time per un OEM automotive italiano, l'impatto operativo di un DoS remoto non autenticato è business-critical. Priorità: alta, anche senza KEV.
Le organizzazioni italiane dovrebbero dotarsi di un processo di vulnerability prioritization che incroci: (1) KEV catalog, (2) exposure scanning continuo (Shodan, Censys, scanner interni), (3) business criticality dell'asset, (4) compensating controls esistenti (segmentazione, MFA, monitoring anomalie). Solo così si evita la paralisi da «mille CVE critiche» e si concentra lo sforzo dove riduce davvero il rischio.
La filiera della responsabilità: vendor, integratori, asset owner
La catena di valore OT/ICS italiana è spesso a tre livelli: vendor globale (Siemens, Mitsubishi, Rockwell...), system integrator locale, asset owner (fabbrica, utility, ospedale). La responsabilità della sicurezza si diluisce. L'advisory Siemens raccomanda di aggiornare o indurire Node-RED (Siemens SIMATIC IoT2050 Advanced): chi lo fa? Il vendor ha rilasciato la patch, ma l'integratore ha incluso Node-RED nell'installazione standard? L'asset owner sa che Node-RED è attivo e accessibile?
Il caso All-Line Fuel-Boss è emblematico: vulnerabilità note dal 2018-2019 su componenti PHP (IMAP toolkit) usati in sistemi critici (All-Line Equipment Company Fuel-Boss). Chi ha aggiornato il runtime PHP? Chi ha verificato che l'applicazione non passi input non sanitizzato a imap_open? Spesso la risposta è «nessuno», perché il sistema «funziona» e non c'è budget per rifattorizzare.
Il CISA Vulnerability Review chiama in causa i produttori di software: sono loro che devono eliminare le root cause (CWE) (CISA Vulnerability Review). Ma finché il mercato non premia la sicurezza by design — con requisiti contrattuali, certificazioni, liability — i vendor ottimizzeranno per time-to-market e feature count. Le aziende italiane, come committenti aggregate, hanno il potere contrattuale per cambiare questo incentivo: richiedere secure development lifecycle, vulnerability disclosure policy pubblicata, patch SLA contrattuali.
Cosa fare domani mattina: una checklist operativa
Alla luce dei dati della scorsa settimana, ecco azioni concrete per CISO, IT/OT manager e risk owner italiani:
- Mappare l'esposizione KEV: confrontare l'inventario asset (IT + OT) con il catalogo KEV aggiornato al 27 agosto 2026. Ogni match su asset esposto pubblicamente = emergency patching entro 72 ore (BOD 26-04 baseline).
- Audit Node-RED su Siemens IoT2050: verificare presenza, versione, autenticazione, esposizione di rete. Applicare patch 4.3.4.1 o mitigazioni (disinstallazione, hardening, segmentazione VLAN + MFA su jump host) (Siemens SIMATIC IoT2050 Advanced).
- Censire dispositivi Xiiaozet, Ebyte, All-Line, ASE: sono marchi meno noti ma potenzialmente presenti in nicchie (IoT gateway, fuel management, test set). Verificare versioni firmware, applicare patch dove disponibili, isolare dove il vendor non risponde (Xiiaozet LK100W) (Ebyte NA111-M) (All-Line Equipment Company Fuel-Boss) (Applied Systems Engineering ASE2000 V2 Communications Test Set).
- Revisionare la gestione backup Rockwell OTTO: se si usano versioni <= V2.36.2, i backup non cifrati contengono hash bcrypt deboli. Cifrare i backup oggi, pianificare upgrade a 2.36.3 (Rockwell Automation OTTO Fleet Manager).
- Inserire clausole Secure by Design nei prossimi bandi: SBOM obbligatorio, PSIRT con SLA di risposta, patch guarantee per il ciclo di vita dichiarato, no end-of-life surprise.
- Adottare il framework di priorità a 4 criteri (exposure, KEV, automation potential, impact) per tutto il parco vulnerabilità, non solo KEV (CISA Vulnerability Review).
La cybersecurity industriale nel 2026 non si vince con l'IA generativa, ma con l'igiene sistemica: sapere cosa si ha, dove è esposto, quali vulnerabilità realmente vengono sfruttate, e avere processi per chiudere le falle prima che diventino incidenti. I dati CISA di agosto 2026 sono un promemoria brutale: il passato non passa mai, se non lo si patcha.