Cybersecurity OT per le utilities locali: acquedotti, reti elettriche e rifiuti con zero risorse interne

Il paradosso delle utilities locali: critiche ma indifese

Le utilities locali (gestori di acquedotti comunali, distributori elettrici di territorio, operatori di impianti di trattamento acque reflue e rifiuti) gestiscono infrastrutture critiche per la vita quotidiana delle comunità. Un acquedotto che smette di funzionare non è un problema produttivo: è un'emergenza sanitaria. Un impianto di trattamento rifiuti fermo impatta la salute pubblica nel giro di giorni.

Eppure, le risorse di sicurezza di questi enti sono spesso inversamente proporzionali alla loro criticità. Una piccola azienda idrica che serve un bacino di qualche decina di migliaia di abitanti può avere un singolo tecnico responsabile di tutta la gestione operativa dell'impianto, SCADA incluso. Nessun team IT strutturato, nessuna competenza di sicurezza OT, nessun budget dedicato alla cybersecurity.

La NIS2, recepita in Italia con il Decreto Legislativo 138/2024, include esplicitamente nella categoria dei soggetti essenziali i gestori di acqua potabile e di acque reflue, e nella categoria dei soggetti importanti i gestori di rifiuti. Questo significa obblighi concreti: misure di sicurezza adeguate, notifica degli incidenti, responsabilità del management. Il legislatore ha riconosciuto la criticità del settore. Il settore ora deve rispondere.

Il caso Oldsmar: un acquedotto, un TeamViewer, quasi una catastrofe

Il 5 febbraio 2021, un operatore del sistema idrico di Oldsmar, in Florida, notò qualcosa di strano: il cursore del suo computer si muoveva da solo. Qualcuno stava accedendo da remoto al sistema di controllo dell'acquedotto. In pochi minuti, l'attaccante portò il livello di idrossido di sodio (soda caustica) nell'acqua da 100 parti per milione a 11.100, ovvero 111 volte il livello normale, potenzialmente letale per i consumatori.

L'operatore intervenne immediatamente, ripristinando il livello corretto. L'attacco fallì grazie alla prontezza umana e, probabilmente, perché l'idrossido di sodio in quelle concentrazioni avrebbe comunque attivato i sensori di qualità dell'acqua prima di raggiungere le utenze. Ma la vulnerabilità era devastante nella sua semplicità: il sistema SCADA era accessibile via TeamViewer, con una versione del software non aggiornata, e i cui accessi probabilmente non venivano monitorati.

Oldsmar non è un caso isolato. Nei mesi successivi, le autorità statunitensi pubblicarono advisory documentando tentativi simili contro acquedotti in altri stati. In Italia, pur in assenza di incidenti di profilo comparabile documentati pubblicamente, le autorità di sicurezza hanno rilevato attività ricognitive su sistemi SCADA di infrastrutture idriche.

La lezione di Oldsmar è semplice e brutale: un sistema SCADA esposto a internet con accesso remoto non autenticato o debolmente autenticato è una vulnerabilità critica, indipendentemente dalle dimensioni dell'ente gestore. E questa configurazione è più comune di quanto si voglia ammettere.

L'architettura tipica: SCADA datati, connessioni non gestite, esposizione internet

La realtà tecnica delle utilities locali italiane è spesso questa: sistemi SCADA installati 15-20 anni fa, progettati per reti chiuse, che nel tempo sono stati connessi a internet per permettere il monitoraggio remoto e ridurre i costi di intervento in loco. La connessione è avvenuta in modo incrementale (un accesso VPN qui, un account TeamViewer là, un'interfaccia web del SCADA esposta per comodità) senza una valutazione sistematica dei rischi che ogni aggiunta comportava.

Il risultato è una superficie di attacco che si estende su internet, con sistemi che non possono essere aggiornati facilmente (perché il vendor non supporta più il software, o perché un aggiornamento richiede un fermo impianto che non si può programmare), accessibili con credenziali deboli o condivise, senza logging degli accessi che permettano di rilevare attività anomale.

Alcuni pattern ricorrenti:

Credenziali di default non cambiate. Molti sistemi SCADA vengono installati con credenziali di default del vendor ("admin/admin", "operator/operator") che non vengono mai cambiate. Queste credenziali sono pubblicamente note e vengono testate sistematicamente dagli attaccanti in fase di ricognizione.

Accesso VPN senza MFA. L'accesso remoto tramite VPN senza autenticazione a più fattori è vulnerabile al credential stuffing: se le credenziali vengono compromesse (attraverso phishing, leak di database, riuso di password), l'attaccante ottiene accesso diretto al sistema di controllo.

Sistemi operativi end-of-life. Gli SCADA legacy girano spesso su versioni di Windows non più supportate, come Windows XP e Windows 7, che non ricevono patch di sicurezza e sono vulnerabili a exploit noti. Aggiornare questi sistemi è complesso (compatibilità con il software SCADA, certificazione del vendor) ma la vulnerabilità è reale.

Priorità con risorse limitate: cosa fare per primo

Il vincolo delle risorse è reale nelle utilities locali e va rispettato. Non ha senso proporre programmi di sicurezza OT adeguati per grandi organizzazioni a enti che hanno un tecnico part-time per la gestione SCADA. Le priorità devono essere calibrate sul contesto.

Prima priorità: eliminare l'esposizione internet non necessaria. Qualsiasi interfaccia di accesso al SCADA esposta direttamente a internet (web interface, accesso RDP, TeamViewer non protetto) va rimossa o messa dietro un layer di autenticazione forte. Non è un'operazione che richiede competenze specialistiche o budget elevati; richiede la volontà di accettare un po' di scomodità operativa in cambio di una riduzione drastica della superficie di attacco.

Seconda priorità: autenticazione forte per l'accesso remoto. Qualsiasi accesso remoto che rimane dopo la pulizia dell'esposizione internet deve essere protetto con MFA. Anche soluzioni semplici, come un secondo fattore via app o SMS, riducono significativamente il rischio di compromissione tramite credential theft.

Terza priorità: inventario degli asset. Sapere cosa c'è nella rete OT è il prerequisito per qualsiasi altra misura. Un inventario accurato, anche fatto manualmente inizialmente, identifica i sistemi più vulnerabili e le connessioni non documentate. Il monitoraggio passivo del traffico di rete permette di costruire questo inventario in modo sistematico e di mantenerlo aggiornato.

Quarta priorità: procedure di risposta minime. Avere una procedura scritta, anche di poche pagine, che descriva cosa fare in caso di sospetto incidente è infinitamente meglio di non averne. Chi chiamare, come isolare un sistema senza fermare il servizio, come documentare l'incidente per la notifica all'autorità competente.

Monitoraggio: visibilità senza competenze interne

Una delle obiezioni più comuni alle soluzioni di monitoraggio OT è che richiedono competenze interne per gestire gli alert e interpretare i dati. Per una utility locale con un tecnico, questa obiezione è concreta.

La risposta non è eliminare il monitoraggio, ma scegliere un approccio che sia sostenibile con le risorse disponibili. Il monitoraggio passivo del traffico OT, configurato correttamente per l'ambiente specifico, genera un set di alert prioritizzati che non richiedono competenze specialistiche per la triage iniziale: un nuovo dispositivo apparso sulla rete, un accesso remoto fuori orario, una comunicazione verso un indirizzo IP esterno non previsto: questi sono segnali comprensibili anche senza formazione specialistica in cybersecurity OT.

La chiave è la calibrazione: un sistema di monitoraggio non calibrato per l'ambiente specifico genererà un numero di alert che sommerge qualsiasi organizzazione. Un sistema calibrato, che conosce la baseline normale di quel SCADA, quelle RTU, quel sistema di telemetria, genera alert significativi in numero gestibile.

Molte utilities locali beneficerebbero di un modello ibrido: monitoraggio locale con alert prioritizzati, supporto remoto da parte di un provider specializzato per la gestione degli alert di maggiore gravità. Questo distribuisce il carico di competenze senza richiedere che l'ente sviluppi internamente capacità che non ha e probabilmente non può permettersi di sviluppare.

NIS2 e la responsabilità del management

La NIS2 introduce un elemento che molte utilities locali non hanno ancora compreso appieno: la responsabilità personale del management. Il decreto di recepimento italiano prevede che gli organi di amministrazione e direttivi dei soggetti essenziali e importanti approvino le misure di gestione dei rischi cyber e ne vigilino l'attuazione. In caso di gravi violazioni, è prevista la possibilità di sanzionare anche i singoli responsabili.

Per il direttore di una piccola azienda idrica, questo significa che la cybersecurity OT non è più una questione tecnica delegata al tecnico SCADA: è una responsabilità di governance che richiede consapevolezza, decisioni, e documentazione delle scelte fatte.

Non si tratta di diventare esperti di sicurezza OT. Si tratta di poter dimostrare di aver valutato i rischi, di aver preso misure proporzionate alle risorse disponibili, di avere un piano, anche minimo, per rispondere agli incidenti. La documentazione delle decisioni prese è tanto importante quanto le decisioni stesse.

Le utilities locali italiane si trovano a un bivio: cominciare ora a costruire una postura di sicurezza OT proporzionata alle proprie risorse, o aspettare che un incidente, o un'ispezione dell'autorità competente, forzi la mano in condizioni di emergenza.

L'angolo MON5

Un tecnico solo, uno SCADA di quindici anni, nessun budget dedicato: il punto di partenza descritto in questo articolo è quello per cui MON5 prevede un percorso modulare. Si comincia con l'assessment e la discovery passiva degli asset, che fanno emergere esposizioni internet e accessi remoti dimenticati senza richiedere competenze interne né fermi impianto; le capacità di monitoraggio si attivano poi per fasi, quando servono.

Anche il modello ibrido suggerito sopra è supportato nativamente: l'architettura multi-tenant permette a un provider esterno di gestire gli alert di più utilities da una piattaforma unica, lasciando al tecnico locale solo la triage essenziale. Il primo passo sostenibile è un assessment OT proporzionato alle risorse reali.