Protocolli ICS: il linguaggio della fabbrica è insicuro per progetto
Protocolli ICS è il nome collettivo dei linguaggi con cui i sistemi di controllo industriale impartiscono ordini al mondo fisico: aprire una valvola, far girare un motore, leggere la temperatura di un reattore. Sono protocolli come Modbus, DNP3, EtherNet/IP, e condividono una caratteristica che continua a sorprendere chi viene dalla sicurezza informatica: non sono insicuri per un difetto, lo sono per progetto. Quando furono concepiti, decenni fa, l’idea stessa di proteggerli non aveva senso, perché vivevano in reti chiuse e isolate dove la presenza fisica equivaleva all’autorizzazione. Quell’assunzione non vale più, ma i protocolli sono rimasti gli stessi.
La conseguenza è netta e scomoda. Su questi protocolli un comando legittimo e un comando malevolo sono indistinguibili: nessuno dei due porta una firma, una credenziale, una prova di chi lo ha mandato. Un ordine che apre una valvola appare identico che provenga dal pannello dell’operatore o da un intruso che è riuscito a raggiungere la rete. E poiché milioni di dispositivi parlano questi linguaggi, non si tratta di un problema che si chiude con un aggiornamento: è un’eredità con cui la sicurezza industriale deve convivere.
Modbus, o l’innocenza di una rete che si fidava
Modbus è l’archetipo, e la sua storia spiega il resto. Nato nel 1979 per la comunicazione seriale tra dispositivi industriali, presupponeva una rete chiusa in cui chiunque avesse accesso fisico era, per definizione, qualcuno di cui fidarsi. In quel contesto non serviva autenticazione, non serviva cifratura, non serviva nemmeno un controllo di integrità: il messaggio arrivava su un cavo a cui solo le persone autorizzate potevano collegarsi. La sua versione su rete IP, il Modbus TCP, non ha aggiunto sicurezza, ha solo messo quel linguaggio del 1979 su una rete moderna e raggiungibile.
Il risultato è che un server Modbus accetta comandi da qualunque indirizzo riesca a contattarlo, senza nome utente, senza password, senza scambio di certificati. E poiché il protocollo non distingue la lettura dalla scrittura come privilegi diversi, un attaccante che lo raggiunge non si limita a osservare: può scrivere nei registri che governano il processo, e anche una modifica minima ai valori da cui un impianto dipende può mandarlo fuori controllo. Modbus è solo il caso più noto: DNP3, EtherNet/IP, S7comm e gli altri protocolli industriali condividono lo stesso peccato d’origine, trasmettendo in chiaro e senza autenticazione.
Quando la rete chiusa si è aperta
Tutto questo era sostenibile finché l’assunzione di partenza reggeva, cioè finché quelle reti restavano davvero isolate. La digitalizzazione degli impianti, la convergenza tra informatica e tecnologia operativa, l’accesso da remoto per la manutenzione hanno smontato quell’isolamento, collegando a reti raggiungibili sistemi nati per restare chiusi. In molti casi i dispositivi industriali sono finiti esposti direttamente su Internet. Le scansioni grezze contano oltre diecimila sistemi in ascolto sulla porta 502, quella predefinita di Modbus; non tutte quelle porte aperte corrispondono a veri dispositivi industriali, ma quando i ricercatori filtrano il rumore ciò che resta è comunque allarmante: un’indagine di Comparitech del 2026, scartando honeypot ed emulatori, ha confermato 179 dispositivi di controllo realmente esposti, alcuni appartenenti a infrastrutture critiche reali, tra cui una rete ferroviaria nazionale e due reti elettriche. Il punto non è il numero grande, è che bastano pochi sistemi raggiungibili sui bersagli giusti. E non serve illudersi che spostare la porta predefinita basti a nascondersi: i dispositivi si identificano dalla risposta del protocollo, non dal numero della porta, e uno scanner che interroga il linguaggio industriale li trova comunque.
Su questo terreno si sono mossi gli attacchi più gravi alle infrastrutture critiche. Industroyer, che nel dicembre 2016 colpì la rete elettrica ucraina, fece leva proprio sulla mancanza di meccanismi di sicurezza nei protocolli di controllo per impartire comandi agli impianti. Triton, noto anche come Trisis, andò oltre, prendendo di mira i controllori dei sistemi strumentati di sicurezza di un impianto, quelli che dovrebbero intervenire per evitare il disastro: un attacco concepito per disabilitare l’ultima barriera tra un processo fuori controllo e il danno fisico alle persone. In entrambi i casi i protocolli non hanno opposto alcuna resistenza, perché non erano fatti per opporne.
Difendere i protocolli ICS che non si possono cambiare
Qui sta il cuore del problema pratico: non si può semplicemente correggere un protocollo del 1979 che milioni di dispositivi parlano, né riavviare in massa impianti che devono restare in funzione. La difesa, allora, non sta dentro il protocollo ma intorno ad esso, e poggia su tre pilastri. Il primo è la segmentazione: se il protocollo si fida di chiunque lo raggiunga, allora la sicurezza si gioca nel controllare chi può raggiungerlo, isolando i dispositivi di controllo in zone separate e sorvegliando i pochi passaggi consentiti. È la ragione per cui nel mondo industriale la rete che circonda i protocolli conta più dei protocolli stessi.
Il secondo pilastro è il monitoraggio consapevole del protocollo. Poiché i comandi non sono autenticati, l’unico modo per accorgersi di un comando ostile è guardarne il contenuto: un’ispezione profonda dei pacchetti, capace di leggere la semantica industriale e non solo le porte, può segnalare una scrittura anomala, un codice di funzione inatteso, una tempistica che non torna. È un lavoro che richiede strumenti che conoscano nativamente i linguaggi industriali, e che trova nel centro operativo di sicurezza, affiancato da tecniche come gli honeypot per sistemi industriali, la sua collocazione naturale. Il terzo pilastro è il privilegio minimo applicato al controllo: limitare quali postazioni possono inviare comandi agli impianti, trattando le stazioni di ingegneria e i pannelli operatore come gli asset più sensibili dell’intera architettura.
La via lunga: protocolli sicuri per progetto
Esiste anche una direzione di fondo, più lenta. Sono nate versioni sicure dei protocolli esistenti, come il Modbus con cifratura o l’autenticazione sicura di DNP3, e soprattutto si è affermato OPC UA, un protocollo industriale progettato fin dall’inizio con autenticazione e cifratura integrate. È la risposta strutturale, quella che risolve il problema all’origine invece di tamponarlo dall’esterno. Ma gli impianti cambiano con tempi misurati in decenni, non in mesi, e per ogni dispositivo nuovo che parla un protocollo sicuro ne restano molti che parlano ancora il linguaggio del 1979. La migrazione è la meta, non il presente.
Visto nel suo insieme, il tema dei protocolli ICS impone un cambio di mentalità a chi arriva dalla sicurezza informatica. Là si dà per scontato che un canale possa essere autenticato e cifrato; qui bisogna partire dall’assunzione opposta, che il canale non lo sia e non lo sarà a breve. La sicurezza dei protocolli ICS, allora, non è la ricerca di una firma da aggiungere al comando, ma la costruzione di un perimetro di controllo e di visibilità attorno a un dialogo che resta, per sua natura, fidato e quindi abusabile. Finché il linguaggio della fabbrica resterà quello di un’epoca in cui la rete era chiusa, la sicurezza del processo fisico dipenderà non da ciò che il protocollo garantisce, perché non garantisce nulla, ma da chi lo può raggiungere e da chi lo sta ascoltando.
