cybersecurity

L'OT invisibile: building automation e IoT consumer come vettori d'attacco per le infrastrutture critiche italiane

Una nuova ondata di advisory CISA rivela come sistemi di building automation, dispositivi IoT consumer e librerie embedded stiano espandendo la superficie d'attacco OT oltre i confini tradizionali. Per le aziende italiane, il rischio non sta più solo negli switch o nei PLC, ma nei sistemi di videosorveglianza, aspirapolvere robot e stack TCP/IP ubiqui.

Pubblicato il

La superficie d'attacco si sposta: dall'impianto all'edificio intelligente

Le ultime due settimane di advisory CISA raccontano una storia che molti CISO italiani faticano ancora a interiorizzare: il perimetro dell'Operational Technology non finisce più al cancello dello stabilimento. Tra il 22 e il 24 settembre 2026, l'agenzia statunitense ha pubblicato undici advisory ICS che coprono settori critici — energia, trasporti, manifatturiero, chimico, sanitario, idrico — ma i vettori d'attacco non sono i classici controller logici programmabili o gli switch industriali. Sono sistemi di building automation come Siemens Desigo CC e Siveillance Control (Fonte 11) (Fonte 12), dashcam per flotte veicolari Botslab G980H nel settore trasporti (Fonte 2), persino aspirapolvere robot Eufy Omni classificati nel settore Information Technology (Fonte 1). A questi si aggiunge una vulnerabilità critica nello stack lwIP MQTT (Fonte 7), libreria embedded onnipresente in dispositivi medicali, sistemi SCADA, contatori smart e gateway industriali.

Il filo conduttore è sottile ma potente: componenti considerati "periferici", "di facility" o "consumer" condividono rete, credenziali e percorsi di lateral movement con gli asset critici. In Italia, dove il Piano Nazionale Industria 4.0 ha accelerato la convergenza IT/OT e dove il patrimonio immobiliare industriale è vetusto ma sempre più sensorizzato, questo spostamento del fronte d'attacco richiede una riconsiderazione radicale della gestione del rischio.

Building automation: il cavallo di Troia negli uffici tecnici

Due advisory Siemens su sistemi di building automation illustrano perfettamente il problema. Siveillance Control, piattaforma di videosorveglianza e gestione allarmi usata in stabilimenti, campus universitari, ospedali e infrastrutture di trasporto, presenta una vulnerabilità di unrestricted file upload nel modulo Open Interface Services (OIS) che consente a un attaccante di ottenere accesso root sul server (Fonte 12). Il CVSS 9.0 riflette la gravità: caricando un file malevolo, si compromette l'intero host e, potenzialmente, la rete OT adiacente. Le versioni interessate — Siveillance Control Pro V3.0/V4.0 e Siveillance Control V3.0/V4.0 — sono diffuse in installazioni che spesso condividono VLAN o segmenti di rete con sistemi di controllo di processo.

Parallelamente, Desigo CC (building management per HVAC, illuminazione, antincendio) soffre di una Client Code Execution via documenti grafici malevoli (Fonte 11). Un attaccante che riesca a far aprire un file grafico compromesso a un operatore con privilegi — tipicamente il facility manager o il tecnico manutentore — esegue codice arbitrario sulla workstation client, aprendo la strada a lateral movement verso la rete OT. CVSS 8.2, vettore d'attacco: ingegneria sociale su file apparentemente innocui. Entrambi i sistemi sono classificati nei settori Critical Manufacturing e Commercial Facilities, ma nella pratica italiana si trovano spesso nella stessa zona DMZ dei sistemi SCADA, gestiti dallo stesso team IT/OT ibrido, con policy di patching allineate ai cicli manutentivi dell'edificio — trimestrali, semestrali — non alle finestre di esposizione critica.

IoT consumer e fleet management: la supply chain fisica si digitalizza

Il settore Transportation Systems porta un altro vettore sorprendente: le dashcam Botslab G980H (Fonte 2). Dodici vulnerabilità in un singolo firmware, tra cui authentication bypass, hard-coded credentials, path traversal, cleartext transmission e predictable session identifiers. CVSS 8.8. Questi dispositivi vengono installati su flotte logistiche, mezzi di soccorso, trasporto pubblico locale — asset mobili che si connettono a backend cloud, scaricano telemetria, ricevono aggiornamenti OTA e, in architetture moderne, fungono da edge node per analisi video in tempo reale. Una compromissione non è solo furto di video: è accesso a credenziali hardcoded, manipolazione di configurazione, persistenza su dispositivo mobile che entra ed esce dal perimetro fisico dell'azienda.

Similmente, gli aspirapolvere robot Eufy Omni C20 e X10 Pro (Fonte 1) — classificati in Information Technology ma spesso presenti in uffici tecnici, sale controllo, data center edge — presentano command injection durante il pairing (CVE-2026-93289, CVSS 4.0: 9 CRITICAL) e hard-coded credentials nei log (CVE-2026-93290). Un dispositivo che mappa l'ambiente, si connette al Wi-Fi aziendale, ha microfono e telecamera, e accetta comandi di sistema non autenticati durante il provisioning: è una backdoor mobile che il team security non inventaria perché "non è OT".

La libreria invisibile: lwIP MQTT e il rischio sistemico

Se building automation e IoT consumer sono vettori visibili, la vulnerabilità CVE-2026-87121 nello stack lwIP TCP/IP MQTT Client (Fonte 7) rappresenta il rischio sistemico per eccellenza. CVSS 9.8 CRITICAL, out-of-bounds write che porta a full code execution sul dispositivo. La lista dei settori colpiti è l'elenco completo delle infrastrutture critiche: Chemical, Communications, Critical Manufacturing, Energy, Financial Services, Healthcare and Public Health, Transportation Systems, Water and Wastewater Systems. lwIP è lo stack TCP/IP de facto per microcontrollori resource-constrained: lo trovi in PLC compatti, gateway protocolli, sensori wireless, contatori gas/acqua/elettricità, dispositivi medicali impiantabili, controller di ricarica EV, moduli radio LoRaWAN/NB-IoT. La versione vulnerabile (2.0.1–2.2.1) è stata incorporata in firmware rilasciati tra il 2020 e il 2024 da centinaia di vendor. Non esiste un "vendor lwIP" da patchare centralmente: ogni integratore deve ricompilare, testare, ricertificare (se in ambito safety) e ridistribuire. Per un'azienda italiana con migliaia di asset OT eterogenei, l'inventario delle istanze lwIP è spesso inesistente.

KEV Catalog e sfruttamento attivo: l'urgenza operativa

Il catalogo Known Exploited Vulnerabilities di CISA si è arricchito di sei nuove voci in tre giorni (Fonte 4) (Fonte 8). Quattro meritano attenzione immediata per il contesto italiano: CVE-2026-85102 e CVE-2026-93616 su prodotti Check Point (certificate validation bypass e path traversal), CVE-2026-93952 su Arista VeloCloud Orchestrator (input validation), CVE-2026-94127 su F5 BIG-IP APM (heap buffer overflow). Sono tecnologie pervasive nelle architetture secure remote access, SD-WAN e application delivery che collegano siti produttivi, cloud ibridi e terze parti. La direttiva BOD 26-04 impone alle agenzie federali USA la remediation prioritaria su asset esposti pubblicamente; per le imprese italiane soggette a NIS2, DORA o classificazione essential/important entity, lo stesso principio dovrebbe guidare lo SLA di patching: se ci sono evidenze di sfruttamento attivo e l'asset è esposto su Internet o raggiungibile da supply chain, la finestra non è "prossima finestra manutentiva" ma "entro 72 ore".

Terze parti e principio di minimo privilegio: la guida FBI/CISA

Il fact sheet congiunto FBI/CISA del 23 settembre (Fonte 5) chiude il cerchio: gli integratori ICS di terze parti — system integrator, vendor OEM, managed service provider — detengono spesso accesso privilegiato persistente a reti OT per manutenzione, troubleshooting, aggiornamenti firmware. Il documento raccomanda esplicitamente Principle of Least Privilege (PoLP): accesso just-in-time, just-enough, con MFA, session recording, revoca immediata post-intervento. In Italia, dove la filiera OT è frammentata tra grandi EPC, system integrator regionali e vendor globali con team locali, l'applicazione rigorosa di PoLP rimane l'eccezione. Credenziali condivise, VPN sempre attive, account service con password mai ruotate, accesso da workstation non gestite: sono pratiche diffuse che trasformano ogni integratore in un vettore di compromissione della supply chain potenziale.

Siemens: un caso di studio sulla complessità del patch management OT

Gli advisory Siemens della settimana (Fonte 6) (Fonte 9) (Fonte 10) (Fonte 11) (Fonte 12) coprono cinque linee di prodotto diverse: dispositivi di protezione rete energia (WTV676/776, DoS via input validation), runtime industriali e HMI (SIPLUS/SIMATIC, "Copy Fail" su dozzine di modelli), fleet management e MES (SIMOVE/SIPLANT, path traversal con esposizione credential store), building automation (Desigo CC, Siveillance). Ogni linea ha cicli di rilascio, canali di notifica, procedure di aggiornamento e requisiti di fermo impianto differenti. Per un asset owner italiano che gestisce impianti con tecnologia Siemens stratificata su 15-20 anni, la coordinated vulnerability disclosure si traduce in un progetto di change management multi-mese, con finestre di fermo negoziate con produzione, validazione su test bed, piano di rollback documentato. L'advisory revocato su Mendix Runtime (Fonte 3) — falso positivo su insecure inherited permissions — ricorda che il noise informativo è parte del problema: triage, validazione, priorizzazione richiedono competenze OT-specifiche che scarseggiano.

Implicazioni per la postura di sicurezza italiana

Tre azioni concrete emergono da questo quadro per le organizzazioni italiane che gestiscono infrastrutture critiche o asset industriali rilevanti:

1. Estendere l'inventario OT oltre il perimetro di processo. Building automation (BMS, videosorveglianza, access control, antincendio), IoT facility (sensoristica ambientale, robotica di servizio, fleet telematics), dispositivi edge consumer portati da dipendenti o fornitori: tutto ciò che ha indirizzo IP, stack TCP/IP, credenziali e connettività alla rete aziendale va inventariato, classificato per criticità, monitorato per anomalie comportamentali. Strumenti di passive network detection e asset discovery agentless sono prerequisiti, non opzioni.

2. Trattare le librerie embedded come componenti critici della supply chain software. lwIP, mbedTLS, FreeRTOS, Zephyr, OpenSSL embedded: ogni vulnerabilità in questi componenti transitivi richiede una bill of materials (SBOM) per firmware OT/IoT. I vendor devono fornire SBOM in formato SPDX/CycloneDX; gli asset owner devono pretendere SBOM nei contratti di fornitura e dotarsi di tooling per vulnerability matching continuo (es. Grype, Trivy, Syft integrati in pipeline SBOM).

3. Implementare Zero Trust per accessi terze parti e dispositivi non gestiti. Il PoLP di FBI/CISA va tradotto in architettura: Privileged Access Management (PAM) per integratori con sessioni just-in-time brokerate, Network Access Control (NAC) con posture assessment per dispositivi non domain-joined (dashcam, robot, laptop vendor), micro-segmentazione che isoli building automation e IoT facility da reti OT di processo, EDR/XDR su workstation di ingegneria e client SCADA/HMI. La direttiva NIS2, recepita in Italia con D.Lgs. 138/2024, richiede gestione del rischio supply chain e sicurezza nella gestione degli incidenti: l'accesso terze parti non controllato è una violazione implicita.

La convergenza tra IT, OT, IoT e building automation non è una tendenza futura: è la realtà operativa di oggi. Le vulnerabilità della settimana CISA non sono episodi isolati — sono la manifestazione sistemica di una superficie d'attacco che le organizzazioni italiane continuano a sottostimare perché non corrisponde al modello mentale tradizionale di "impianto industriale". Chi non adatta inventario, governance e architettura a questa realtà espansa, lascia la porta aperta — letteralmente — a chi quella porta sa come aprirla da remoto, senza credenziali, tramite un file grafico, un firmware dashcam o uno stack TCP/IP vecchio di quattro anni.

Fonti