Il paradosso del difensore vulnerabile: CISA Malcolm e la supply chain degli strumenti di sicurezza OT in Italia

La scorsa settimana il flusso degli advisory CISA ha consegnato una lezione scomoda: le difese stesse possono diventare il tallone d'Achille. Tra il 29 settembre e il 2 ottobre 2026, l'agenzia statunitense ha pubblicato undici alert, di cui quattro ingressi nel catalogo KEV (Known Exploited Vulnerabilities) e sette advisory ICS/OT. Il filo rosso non è solo la quantità, ma la natura degli asset colpiti: non solo dispositivi di campo o PLC, ma le console di gestione, le piattaforme cloud di orchestrazione, i gateway cellulari e — fatto emblematico — lo stesso strumento di analisi del traffico di rete sviluppato e distribuito da CISA. Per le aziende italiane che gestiscono infrastrutture critiche, dalla rete elettrica ai trasporti, il messaggio è chiaro: la supply chain del software di sicurezza va trattata con lo stesso rigore riservato ai sistemi di controllo industriale.

Il caso CISA Malcolm: quando chi sorveglia è sorvegliato

L'advisory ICSA-26-254-01 su CISA Malcolm è il caso studio più eloquente. Malcolm è una piattaforma open source per l'analisi del traffico di rete (full packet capture, Zeek, Suricata, Arkime) adottata in settori Energy, Information Technology, Water and Wastewater (CISA Malcolm). La versione antecedente alla v26.06.0 accumula dodici vulnerabilità, tra cui: OS Command Injection, Server-Side Request Forgery (SSRF), Authentication Bypass by Spoofing, Missing Authentication for Critical Function, Use of Default Credentials e Cross-Site Scripting non autenticato (CVE-2026-90443). Quest'ultimo permette a un aggressore remoto, senza credenziali, di iniettare JavaScript nel contesto della sessione di un analista e di reindirizzarne il browser verso siti arbitrari. In pratica, chi monitora la rete per rilevare intrusioni può essere compromesso semplicemente visitando un link malevolo mentre usa la console Malcolm.

Il vettore è sottile: l'interfaccia web riflette porzioni dell'URL in contesti script e attributi href senza encoding adeguato, e non richiede autenticazione per essere raggiunta. Un analista che clicca su un link appositamente creato — magari ricevuto via email o generato da un alert automatico — esegue codice nell'applicazione con i propri privilegi. La correzione è arrivata con il rilascio di settembre 2026, ma la finestra di esposizione per chi non ha aggiornato è critica. Il paradosso è strutturale: uno strumento pensato per vedere l'attacco diventa vettore d'attacco se la sua superficie web non è indurita quanto i sistemi che protegge.

La superficie d'attacco della toolchain di sicurezza: oltre Malcolm

Malcolm non è un caso isolato. La stessa ondata di advisory rivela un pattern sistemico: le console di gestione e i software di ingegneria che configurano, aggiornano e supervisionano l'OT sono bersagli primari.

• ABB PCM600 (Protection and Control IED Manager), usato per configurare i dispositivi di protezione e controllo delle sottostazioni elettriche (Energy sector), presenta due vulnerabilità: un privilege escalation locale via servizio Scheduler che gira come LocalSystem ma accetta utenti standard (CVE-2026-15952) e un Path Traversal (CVE-2026-15953) (ABB Protection and Control IED Manager PCM600). ABB raccomanda un workaround — far girare il servizio con l'account utente dell'operatore — ma non una patch immediata.
• Armatura One, sistema di controllo accessi fisico (badge, tornelli, serrature IP) diffuso in Communications, Critical Manufacturing, Energy, Transportation, integra Apache ActiveMQ esponendo di default il listener OpenWire. La deserializzazione non autenticata (CVE-2023-46604, CVSS 9.8) concede esecuzione di codice arbitrario con massimi privilegi sull'host (Armatura LLC Armatura One). Si aggiungono chiavi crittografiche e credenziali hardcoded, inserimento di dati sensibili nei log: la piattaforma che governa chi entra dove è apribile da remoto senza credenziali. Armatura ha rilasciato la v4.7.2, ma l'adozione nei siti distribuiti è spesso lenta.
• Johnson Controls EasyIO Neo (controller edge per building automation: HVAC, illuminazione, energia) soffre di trasmissione in chiaro di credenziali e dati di sessione (CVE-2026-64893, CVSS 5.4) e esposizione di informazioni sensibili (CVE-2026-64892) (Johnson Controls EasyIO Neo Series EC and CW Controllers - Cleartext) (Johnson Controls EasyIO Neo Series EC and CW Controllers - Info Exposure). L'interfaccia web di gestione diventa sniffer passivo per chiunque abbia accesso al segmento di rete.
• Lantronix G520 Series Cellular Gateway (connettività critica per Transportation, Energy, Water) combina XSS persistente via metadati di aggiornamento non firmati (HTTP, non HTTPS) e esecuzione comandi di sistema come root nell'interfaccia di gestione (CVE-2026-84409, CVE-2026-91191) (Lantronix G520 Series Cellular Gateway). Un attaccante che controlla il canale di aggiornamento — o ne inietta i metadati — ottiene RCE sul gateway che collega siti remoti al SOC.

Questi non sono dispositivi di campo "headless". Sono workstation di ingegneria, server di gestione, gateway di connettività, console di sicurezza: il livello manage dell'architettura Purdue. Comprometterli significa poter riscrivere la logica di controllo, disabilitare protezioni, pivotare verso il livello control e field. Eppure, la gestione delle patch su questi sistemi — spesso basati su Windows, con dipendenze complesse, requisiti di validazione del vendor — rimane il tallone d'Achille dei programmi di vulnerability management italiani.

Il cloud come singolo punto di fallimento: Meari e la responsabilità del vendor

Un secondo pattern emerge dalle piattaforme cloud-native di orchestrazione IoT/OT. Meari IoT Cloud Platform OpenAPI espone due vulnerabilità di Missing Authorization (CVE-2026-101104, CVSS 7.7; CVE-2026-96613) che permettono a utenti autenticati di manipolare configurazioni di dispositivi altrui, accedere a credenziali, dettagli proprietari e dati di rete (Meari IoT Cloud Platform OpenAPI Service). La risposta del vendor è assente: "No fix planned. Meari did not respond to CISA's coordination attempts." Gli utenti sono invitati a contattare il supporto. Per un'azienda italiana che abbia implementato telecamere, sensori o attuatori gestiti via Meari, l'opzione tecnica è migrare; l'opzione contrattuale è far valere clausole di security maintenance — se esistono.

Monta monta.app, piattaforma cloud per la gestione di colonnine di ricarica EV (Energy, Transportation), mostra un approccio diverso: quattro vulnerabilità (CVSS fino a 9.4) tra cui Missing Authentication for Critical Function su WebSocket (impersonazione stazioni di ricarica), brute-force non limitato, session expiration insufficiente, credenziali insufficientemente protette (Monta monta.app). Monta dichiara mitigazioni rolling: adozione progressiva di connessioni autenticate (OCPP 1.6 Security Profile 2 con HTTP Basic Auth over TLS), rate limiting a livello WebSocket. È una roadmap, non una patch immediata. Nel frattempo, la superficie d'attacco resta ampia per un'infrastruttura che la direttiva NIS2 e il PNRR stanno spingendo a diffondere capillarmente in Italia.

Il denominatore comune: **la fiducia delegata a un SaaS/IaaS esterno senza clausole di continuous vulnerability management vincolanti**. Quando il vendor non risponde (Meari) o mitiga su tempi lunghi (Monta), l'azienda cliente non ha leve tecniche per chiudere il buco. L'unica difesa è architetturale: segmentazione rigorosa, zero trust verso le API cloud, capacità di disconnect & operate in modalità degradata ma sicura.

KEV in accelerazione: il segnale di sfruttamento attivo su infrastrutture core

Il catalogo KEV di CISA — riferimento operativo per la direttiva BOD 26-04 che impone alle agenzie federali USA la remediation prioritaria su asset esposti — si è arricchito in quattro giorni di quattro voci, ciascuna indicativa di vettori reali:

1. CVE-2026-86950 — Apple Multiple Products Out-of-Bounds Write (CISA Adds One Known Exploited Vulnerability to Catalog - 29 Set): endpoint utente (iPhone, Mac) come foothold iniziale.
2. CVE-2026-76504 — Cisco Catalyst SD-WAN Manager Hex Encoding (CISA Adds One Known Exploited Vulnerability to Catalog - 30 Set): il controller centrale della WAN aziendale, spesso esposto per gestione out-of-band.
3. CVE-2026-104286 — Fortinet FortiMail Path Traversal (CISA Adds One Known Exploited Vulnerability to Catalog - 1 Ott): gateway email perimetrale, vettore classico per business email compromise e delivery malware.
4. CVE-2026-102489 / CVE-2026-102490 — Zammad Session Fixation & Improper Privilege Management (CISA Adds Two Known Exploited Vulnerabilities to Catalog): helpdesk/ticketing system, spesso accessibile da internet per supporto clienti/fornitori.

Quattro ingressi in 96 ore. Non sono vulnerabilità teoriche: CISA richiede evidenza di sfruttamento attivo per l'inclusione. Significa che gruppi threat actor stanno colpendo oggi la catena: endpoint → gateway email → SD-WAN controller → helpdesk → (potenzialmente) console OT. Per un CISO italiano, la mappa KEV non è una lista di controllo burocratica: è un radar di priorità operative. Se nel proprio asset inventory compaiono FortiMail, Cisco SD-WAN Manager, istanze Zammad o dispositivi Apple non aggiornati, la finestra per patch or perimeter è chiusa: si deve assumere il compromesso e attivare threat hunting mirato.

Implicazioni per il contesto italiano: NIS2, PNRR e la filiera del "manage"

L'Italia sta riversando risorse PNRR su digitalizzazione energetica (smart grid, colonnine EV), sanità digitale, trasporti intelligenti. Ogni nuovo asset connesso porta con sé una console di gestione, un gateway, un fornitore cloud. La direttiva NIS2 (recepimento in corso) estende gli obblighi di supply chain security, vulnerability handling e incident reporting a migliaia di enti essential e important. La lezione di questa settimana CISA è operativa:

• Inventariare la toolchain di sicurezza: Malcolm, PCM600, Armatura, EasyIO, gateway Lantronix, console FortiMail, SD-WAN manager, helpdesk Zammad. Sono asset critici a tutti gli effetti, non "tool di supporto".
• **Contrattualizzare il vulnerability SLA con i vendor SaaS/Cloud**: clausole di time-to-patch, coordinated disclosure, escape hatch (esportazione configurazione, modalità offline). Il caso Meari insegna che senza clausole, l'azienda è ostaggio.
• Segmentare e monitorare il piano di gestione: rete out-of-band dedicata, jump host con MFA phishing-resistant, logging centralizzato e alert su anomalie (es. login da IP nuovi su console Malcolm/PCM600/Armatura).
• **Allineare il patching al KEV**: adottare una policy KEV-first per ogni asset esposto su internet o su reti di gestione. BOD 26-04 non è legge italiana, ma è best practice riconosciuta internazionalmente.
• Testare la resilienza delle console: red teaming periodico su interfacce web di gestione, API cloud, aggiornamenti firmware OTA. La catena update mechanism → XSS → RCE vista su Lantronix è un pattern riutilizzabile.

La settimana appena trascorsa non è un'eccezione: è la nuova normalità. La superficie d'attacco si è spostata upstream, verso chi configura, aggiorna, monitora e autorizza. Difendere l'OT italiano nel 2026 significa difendere prima di tutto gli strumenti con cui lo si difende.