Vulnerabilità nei protocolli industriali: Modbus, DNP3, OPC-UA e i rischi nascosti

I protocolli industriali: nati per l'affidabilità, non per la sicurezza

Quando Modbus fu sviluppato nel 1979 da Modicon, Internet non esisteva. Le reti industriali erano sistemi chiusi, fisicamente isolati, dove l'unica preoccupazione era la trasmissione affidabile dei dati di controllo. La sicurezza informatica non era una categoria concettuale per chi progettava impianti industriali.

Cinquant'anni dopo, quegli stessi protocolli girano su reti TCP/IP connesse a Internet, su dispositivi accessibili da remoto, in ambienti dove gli attori malevoli esistono e sono attivi. Il problema non è che questi protocolli abbiano dei bug: il problema è che sono stati progettati in un modello di minaccia completamente diverso da quello attuale.

Comprendere le vulnerabilità specifiche di ciascun protocollo è il primo passo per implementare le mitigazioni appropriate.

Modbus: nessuna autenticazione by design

Modbus è il protocollo industriale più diffuso al mondo. La sua semplicità è il suo punto di forza: request/response su seriale o TCP, pochi tipi di messaggi, basso overhead. Milioni di dispositivi lo implementano.

Le vulnerabilità sono intrinseche al design:

• Nessuna autenticazione: qualsiasi dispositivo sulla rete può inviare comandi Modbus a qualsiasi altro dispositivo. Non c'è modo di verificare che il comando provenga da un master autorizzato.
• Nessuna crittografia: tutti i dati viaggiano in chiaro. Su una rete sniffabile, i valori dei registri, i comandi di controllo, tutto è visibile.
• Nessun controllo di integrità: non c'è meccanismo per verificare che un messaggio non sia stato alterato in transito (salvo il CRC, che protegge dagli errori accidentali, non dagli attacchi intenzionali).
• Nessuna autorizzazione: un client che riesce a comunicare con un server Modbus può leggere o scrivere qualsiasi registro, senza restrizioni basate su ruolo o privilegio.

In pratica: un attaccante sulla rete OT con accesso al traffico Modbus può inviare comandi arbitrari a qualsiasi PLC che usa il protocollo. Cambiare un setpoint, aprire una valvola, spegnere un motore.

DNP3: spoofing e replay attack

DNP3 (Distributed Network Protocol 3) è nato per le applicazioni SCADA nelle utility elettriche e idriche, con requisiti di affidabilità su canali a bassa qualità. È più sofisticato di Modbus, ma presenta vulnerabilità specifiche.

Spoofing di indirizzo: DNP3 usa indirizzi sorgente e destinazione, ma non li autentica. Un attaccante può inviare messaggi che sembrano provenire da un master SCADA legittimo, modificando i dati di processo o emettendo comandi di controllo.

Replay attack: senza meccanismi di freshness (timestamp, nonce), un messaggio DNP3 intercettato può essere reinviato in un momento successivo. Un comando legittimo registrato durante un'operazione normale può essere "risuonato" per ripetere quell'operazione fuori contesto.

DNP3 Secure Authentication (SA): esiste un'estensione di sicurezza per DNP3 (SA v5, definita in IEEE 1815) che aggiunge autenticazione basata su chiave condivisa. Il problema è che la sua adozione è lenta e molti dispositivi legacy non la supportano.

OPC-UA: il protocollo moderno con problemi moderni

OPC-UA è il successore moderno di OPC Classic, progettato dall'OPC Foundation per avere sicurezza nativa: autenticazione, autorizzazione, crittografia. In teoria, è il protocollo che risolve i problemi degli standard precedenti.

In pratica, la sicurezza di OPC-UA è spesso compromessa dalle scelte di implementazione:

Configurazione di sicurezza "None": OPC-UA definisce Security Policies che vanno da "None" (nessuna sicurezza) a configurazioni con crittografia e autenticazione forti. Per compatibilità o semplicità, molte installazioni usano Security Policy "None" o Basic128Rsa15, che è considerata deprecata per vulnerabilità crittografiche.

Certificati self-signed non verificati: OPC-UA usa certificati per l'autenticazione dei nodi. Senza una PKI adeguata e la validazione dei certificati, l'autenticazione basata su certificati è vulnerabile ad attacchi man-in-the-middle.

Vulnerabilità nelle implementazioni: come ogni software complesso, le implementazioni di OPC-UA hanno avuto vulnerabilità specifiche scoperte nel tempo. La buona notizia è che le librerie principali sono mantenute attivamente; la cattiva è che gli aggiornamenti nell'OT sono lenti.

Superficie di attacco ampia: OPC-UA è un protocollo ricco di funzionalità. Un server OPC-UA esposto può essere oggetto di discovery per mappare la struttura del sistema OT, come punto di pivot per movimenti laterali.

PROFINET e il panorama degli altri protocolli

PROFINET, EtherNet/IP, Foundation Fieldbus, BACnet: ogni settore industriale ha i suoi protocolli dominanti, ciascuno con il suo profilo di vulnerabilità.

PROFINET, ampiamente usato nell'automazione manifatturiera, gira su Ethernet standard e condivide molti dei problemi di autenticazione dei suoi predecessori. EtherNet/IP si basa su TCP/IP e condivide le vulnerabilità delle reti IP. BACnet, dominante nel building automation, ha vulnerabilità specifiche nelle sue modalità di discovery e gestione dei dispositivi.

Il pattern comune a tutti: protocolli progettati per la comunicazione affidabile in reti chiuse, ora esposti in ambienti aperti.

Mitigazioni pratiche

La soluzione non è smettere di usare questi protocolli: nella maggior parte dei casi non c'è alternativa a breve termine. L'approccio è la difesa in profondità:

Segmentazione di rete: i dispositivi che comunicano via Modbus o DNP3 dovrebbero essere in zone di rete isolate, accessibili solo dai sistemi che devono comunicarci. Un attaccante che non può raggiungere il segmento non può sfruttare l'assenza di autenticazione.

Monitoraggio del traffico: il comportamento dei protocolli industriali è altamente prevedibile. Monitorare il traffico e alertare su deviazioni dalla baseline (nuovi indirizzi, comandi insoliti, volumi anomali) è un controllo compensativo efficace.

Whitelist di comunicazione: dove possibile, implementare regole che permettano solo le comunicazioni attese. Solo il master SCADA A può comunicare con il PLC B, solo su porta X, solo con i function code Y.

Aggiornare OPC-UA dove in uso: dove è tecnicamente possibile, configurare OPC-UA con Security Policy sicure e gestione appropriata dei certificati. È l'area dove un miglioramento della configurazione dà un beneficio immediato.

La consapevolezza delle vulnerabilità dei protocolli industriali non deve portare al panico, ma a scelte architetturali informate. La sicurezza nell'OT si costruisce a strati: nessun singolo controllo è sufficiente, ma l'insieme di controlli compensativi ben progettati riduce il rischio a livelli accettabili.

L'angolo MON5

Se Modbus e DNP3 non possono autenticare nessuno, il controllo compensativo più concreto è osservare cosa fanno. La fase PROTECT di MON5 fa esattamente questo: NDR passivo fuori banda che decodifica i protocolli OT nativi (Modbus, Siemens S7, OPC UA, PROFINET, EtherNet/IP) e segnala le deviazioni dalla baseline, come function code insoliti o nuovi master che compaiono in rete.

La segmentazione indicata tra le mitigazioni trova supporto nella fase ANALYZE, con il modello a zone e conduit IEC 62443. Per scoprire quali protocolli circolano davvero nel tuo impianto, parti da un assessment OT.