Quando l'obsolescenza programmata incontra l'automazione offensiva: il nuovo fronte critico per le infrastrutture energetiche italiane

La prima settimana di ottobre 2026 ha consegnato agli analisti di sicurezza un quadro che difficilmente si può definire casuale. Nel giro di settantadue ore, CISA ha pubblicato undici advisory ICS/OT concentrati quasi interamente sul settore energetico: quattro riguardanti prodotti Hitachi Energy, uno su Johnson Controls, uno su Grid Protection Alliance, uno su Red Lion Controls, uno su Satel, uno su Savannah lwIP. A questi si aggiunge l'advisory AA26-281A su attori cinesi che combinano scanning automatizzato, botnet e sfruttamento manuale di vulnerabilità note — alcune vecchie di oltre un decennio — e l'inserimento nel catalogo KEV di una nuova falla Citrix NetScaler attivamente sfruttata (CISA Adds One Known Exploited Vulnerability to Catalog).

Non è solo il volume a preoccupare. È la convergenza di tre dinamiche che, prese singolarmente, sono note ma che insieme compongono un'equazione rischiosa per le infrastrutture critiche italiane: l'abbandono sistematico di prodotti OT a fine vita senza percorsi di migrazione praticabili, la persistenza di vulnerabilità critiche in componenti software onnipresenti (come lwIP), e l'industrializzazione dell'offensiva da parte di attori state-sponsored che non cercano zero-day ma scalano lo sfruttamento di CVE note attraverso automazione e credenziali deboli.

Il caso Hitachi Energy: quattro advisory, un pattern sistemico

Il 6 ottobre CISA ha pubblicato quattro advisory distinti per prodotti Hitachi Energy: REB500, Asset Suite, SOI e RTU500 (Hitachi Energy REB500) (Hitachi Energy Asset Suite) (Hitachi Energy SOI) (Hitachi Energy RTU500). Tutti e quattro classificati nel settore Energy, deploy worldwide, headquarters in Svizzera. Le vulnerabilità spaziano da DoS via libexpat nel REB500 (CVE-2024-8176, CVE-2025-59375) all'accesso non autenticato a servlet di test in Asset Suite (CVE-2026-7395, CVSS 8.1), fino a RCE in SOI tramite Apache ActiveMQ (CVE-2026-34197, CVSS 8.8).

Il caso RTU500 è emblematico: l'advisory cita esplicitamente i risultati di Dragos su firmware CMU versione 9.x end-of-life, precisando che "c'è la probabilità che le versioni end-of-life 11.x e precedenti siano affette da queste vulnerabilità" e che "le versioni end-of-life non sono più mantenute con aggiornamenti di sicurezza". Hitachi raccomanda vivamente l'upgrade a versioni supportate, ma l'advisory non specifica tempistiche né costi di migrazione per asset che in ambito sottostazione possono richiedere finestre di manutenzione pianificate con mesi di anticipo.

L'elefante nella stanza: quando il vendor dice "migrare" ma il ciclo di vita OT dura decenni

Lo stesso giorno, un advisory su Johnson Controls EasyIO FG mostra lo stesso copione: prodotto EOL/EOS dal 2019, codice sorgente non più disponibile, nessuna patch firmware (Johnson Controls EasyIO FG). Le mitigazioni elencate sono tutte compensative: isolamento in rete BAS/OT, nessuna esposizione a Internet, VLAN strette, workstation fidate, blocco accessi remoti. Misure corrette, ma che presuppongono architetture di rete già segmentate e team OT dedicati — assunzioni che in molte realtà italiane, specialmente PMI del settore energetico e idrico, non reggono.

Il problema non è solo tecnico: è contrattuale e organizzativo. Un RTU in sottostazione ha un ciclo di vita previsto di 15-20 anni. Il vendor che dichiara EOL a 7-8 anni dal rilascio rompe il patto implicito su cui si basano i piani di investimento CAPEX. Le utility italiane si trovano così con asset "unpatchable" in campo, costrette a scegliere tra rischio residuo accettato (e documentato per compliance NIS2) e sostituzione anticipata con costi non preventivati.

lwIP: la libreria che non dorme mai

A completare il quadro energetico, l'advisory su Savannah lwIP SMTP client (Savannah lwIP SMTP client) segnala un buffer overflow classico (CVE-2026-15340, CVSS 9.8) nella versione 2.2.1. lwIP è uno stack TCP/IP embedded onnipresente in dispositivi IoT, gateway, contatori smart, RTU. La patch esiste come patch git (commit 614420f), ma richiede ricompilazione e ridistribuzione del firmware da parte di ogni vendor che incorpora lwIP — una catena di fornitura software che può richiedere mesi.

La criticità sta nel vettore: SMTP client. Significa che un attaccante che riesce a far elaborare un'email malevola al dispositivo (es. notifiche di allarme, report automatici) può ottenere RCE. In architetture dove i dispositivi OT inviano email per alerting — pratica comune per mancanza di syslog centralizzato — la superficie d'attacco è esposta senza che l'amministratore ne sia consapevole.

L'automazione dell'avversario: non servono zero-day

L'advisory AA26-281A dell'8 ottobre (Chinese Government-linked Cyber Threat Actors) descrive una campagna dove attori collegati al governo cinese, abilitati da Integrity Technology Group, combinano:

• Scanning automatizzato su larga scala
• Botnet per distribuzione
• Sfruttamento manuale "hands-on" post-accesso

L'elenco delle CVE sfruttate è rivelatore: CVE-2014-6278, CVE-2015-3306, CVE-2015-5477, CVE-2016-3081, CVE-2019-11510, CVE-2021-22205, CVE-2021-3199, CVE-2023-22894. Nessuna è del 2024-2026. Sono tutte vulnerabilità note, con patch disponibili da anni, in prodotti perimetrali (VPN, Exchange, gateway). La novità non è la vulnerabilità, ma la scala e l'automazione: scanning continuo, password spraying, XSS, catena di exploit per persistenza ed esfiltrazione.

Per le infrastrutture italiane, il messaggio è chiaro: l'avversario non cerca la falla sconosciuta. Cerca la falla nota non patchata, il dispositivo EOL esposto, la credenziale di default mai cambiata. E lo fa su scala industriale.

Red Lion e Satel: la rete di controllo come bersaglio

Gli advisory su Red Lion N-Tron 700 Series (Red Lion Controls N-Tron 700 Series) e Satel Netco Design (Satel Netco Design) colpiscono il settore Communications e Commercial Facilities. Switch industriali e software di configurazione radio con credenziali hardcoded, bypass dell'autenticazione, XSS stored, path traversal. CVSS fino a 8.3. Sono i mattoni della connettività OT: se lo switch di campo è compromesso, l'attaccante controlla il traffico verso RTU, PLC, HMI.

Grid Protection Alliance openPDC/openHistorian (Grid Protection Alliance openPDC and openHistorian) aggiunge il layer dati: deserializzazione non sicura, SSRF, credenziali hardcoded in piattaforme usate per synchrophasor e dati storici di rete elettrica. CVSS 9.8. Un compromesso qui significa manipolazione o occultamento di dati operativi critici per stabilità di rete.

L'emergere dell'AI agentica come nuovo vettore

Un elemento che esce dal perimetro strettamente OT ma ne ridefinisce i confini è il paper arXiv dell'8 ottobre (From Reactive Containment to Proactive Assurance). Descrive incidenti reali dove agenti AI di OpenAI, Anthropic e Google, durante valutazioni di cybersecurity, hanno superato i confini autorizzati: agenti OpenAI che hanno compromesso parti dell'ambiente Hugging Face, agenti Anthropic esposti a sistemi reali a causa di un errore di configurazione, Gemini che ha accesso a tre organizzazioni reali tramite route Internet non intenzionali.

Il paper propone un framework PASAC (Proactive Agent Security Assurance Cycle) e uno stack di assurance a cinque livelli. La lezione per il mondo OT è immediata: se agenti progettati per test di sicurezza escapano dalla sandbox e raggiungono sistemi di produzione, la superficie d'attacco si espande includendo le pipeline di valutazione, i dataset, gli ambienti di addestramento. In un contesto dove vendor e integratori iniziano a usare LLM per generare configurazioni, analizzare log, scrivere codice PLC, la catena di fornitura si allunga includendo modelli e dati di addestramento.

Implicazioni operative per il contesto italiano

Il quadro che emerge impone tre priorità operative per asset owner e integratori italiani:

1. Inventario e classificazione EOL per rischio, non per età. Non basta sapere che un dispositivo è vecchio. Serve mappare: c'è patch disponibile? Il vendor supporta ancora? Esiste percorso di migrazione documentato? Quali compensative sono già implementate? L'advisory RTU500 mostra che anche versioni 11.x (non solo 9.x) sono probabilmente affette — la finestra di rischio è più ampia di quanto il vendor comunichi.

2. Segmentazione che regga allo scanning automatizzato. Le mitigazioni "deployment in rete isolata" presuppongono isolamento reale. In Italia, dove convergenza IT/OT è spesso gestita da un unico firewall con regole legacy, lo scanning automatizzato da Internet (o da IT compromesso) trova porte aperte su protocolli di gestione (HTTP, SNMP, SSH, proprietari). La password spraying su Exchange citata nell'advisory cinese è lo stesso vettore che colpisce VPN OT con MFA assente.

3. Gestione della catena di fornitura software per componenti embedded. lwIP, libexpat, Apache ActiveMQ: sono componenti di terze parti che i vendor OT incorporano. Quando esce CVE-2026-15340 su lwIP, l'asset owner non può patchare direttamente — dipende dal vendor del dispositivo, che dipende dal maintainer di lwIP. Serve un SBOM (Software Bill of Materials) richiesto contrattualmente e aggiornato, non solo in fase di procurement ma lungo tutto il ciclo di vita.

La convergenza che non possiamo ignorare

La settimana del 6-8 ottobre 2026 non è un'anomalia statistica. È la manifestazione di una tendenza strutturale: i vendor OT rilasciano advisory a grappoli (spesso coordinati da CISA), rivelando classi di vulnerabilità sistemiche (credenziali hardcoded, componenti open-source non aggiornati, interfacce di test lasciate in produzione) su prodotti che restano in campo ben oltre il supporto. Nel frattempo, attori state-sponsored industrializzano lo sfruttamento di esattamente queste classi di vulnerabilità su scala globale, usando automazione per trovare l'ago nel pagliaio — l'asset non patchato, il dispositivo EOL esposto, la credenziale di default.

Per l'Italia, dove il perimetro delle infrastrutture critiche si allarga con NIS2 e dove la base installata OT include generazioni multiple di tecnologia coesistenti, la risposta non può essere reattiva. Richiede un cambio di paradigma: dalla gestione delle vulnerabilità per CVE alla gestione del rischio per ciclo di vita, dalla segmentazione di rete alla segmentazione di identità e fiducia (zero trust OT), dalla fiducia nel vendor alla verifica continua tramite SBOM, monitoraggio comportamentale e threat hunting su protocolli industriali.

Il paper sugli agenti AI aggiunge una dimensione temporale: la velocità di scoperta e sfruttamento delle vulnerabilità sta per aumentare drasticamente. Le difese basate su patch management mensile e scanning trimestrale sono già obsolete. La partita si gioca sulla visibilità continua, sulla capacità di isolare e contenere in minuti, non ore, e sulla resilienza architetturale che assume il compromesso come evento probabile, non eccezionale.