OPC-UA: il protocollo più diffuso nell'OT e i suoi problemi di sicurezza più comuni

OPC-UA: cosa è e perché è ovunque

OPC-UA (Open Platform Communications Unified Architecture) è il protocollo standard per la comunicazione tra componenti nei sistemi di automazione industriale moderni. Sviluppato dalla OPC Foundation come evoluzione del precedente OPC classico (basato su COM/DCOM Windows), OPC-UA è stato progettato per essere indipendente dalla piattaforma, scalabile dall'edge al cloud, e sicuro by design, con un modello di sicurezza basato su certificati X.509, crittografia e autenticazione integrati nelle specifiche del protocollo.

In pratica, OPC-UA è il collante che connette i PLC agli SCADA, i server di processo agli historian, i gateway OT alle piattaforme di analisi dati industriale. Si trova praticamente in ogni impianto produttivo moderno, nei macchinari CNC di nuova generazione, nei sistemi di supervisione conformi alle specifiche Industry 4.0. La sua diffusione è tale che capirne i problemi di sicurezza equivale a capire una parte sostanziale della superficie d'attacco di qualsiasi rete OT contemporanea.

Il paradosso di OPC-UA è che le specifiche di sicurezza sono ben progettate, notevolmente meglio di quelle di Modbus, DNP3 o dei protocolli industriali più datati, ma le implementazioni reali spesso non le usano. La pressione operativa, la compatibilità con client legacy, la necessità di non rompere configurazioni funzionanti, portano sistematicamente a deployment con le funzionalità di sicurezza disabilitate o degradate.

Sessioni anonime: il problema più diffuso

OPC-UA supporta diversi meccanismi di autenticazione: certificato client, username/password, e accesso anonimo. Quest'ultima modalità esiste per scenari specifici di diagnostica e test, ma viene abilitata in produzione con una frequenza che sorprende chi si avvicina per la prima volta agli ambienti OT reali.

Le ragioni per cui si lascia abilitato l'accesso anonimo sono quasi sempre operative. Un client legacy che non supporta l'autenticazione con certificati. Un pannello HMI di un fornitore che usa anonymous per semplicità implementativa. Un integratore di sistema che ha configurato così durante il commissioning e nessuno ha mai revisionato la configurazione. Il risultato è che chiunque raggiunga il server OPC-UA a livello di rete può connettersi e leggere, e in alcuni casi scrivere, i nodi esposti senza presentare nessuna credenziale.

La portata di questo accesso dipende da come è strutturata la gerarchia di nodi del server: in configurazioni permissive, un client anonimo può leggere tutti i tag di processo, navigare l'albero degli oggetti e ottenere una mappa completa dell'impianto. In configurazioni peggiori, può anche scrivere valori verso nodi che controlano setpoint o attuatori.

Dal punto di vista del rilevamento, una sessione anonima verso un server OPC-UA è distinguibile nel traffico di rete analizzando il messaggio di handshake della sessione. Il campo UserTokenType nella richiesta di CreateSession e ActivateSession indica il tipo di autenticazione usato: AnonymousIdentityToken è il valore che indica accesso anonimo e non richiede decodifica profonda per essere rilevato.

Certificati self-signed e validazione disabilitata

OPC-UA usa certificati X.509 per due scopi: autenticare il server verso i client (analoga alla funzione TLS nei siti web) e autenticare i client verso il server quando si usa l'autenticazione con certificato. Entrambi i meccanismi richiedono una infrastruttura di gestione dei certificati, una PKI, che nella maggior parte delle organizzazioni manifatturiere non esiste o è gestita in modo approssimativo.

Il risultato pratico è che i certificati OPC-UA in produzione sono quasi sempre self-signed, cioè firmati dal server stesso senza una CA di fiducia a fare da garante. I client che si connettono a un server con certificato self-signed ricevono un warning che il certificato non è validabile e, per non interrompere le operazioni, vengono configurati per accettare qualsiasi certificato senza validazione.

Questo comportamento, che in ambiente web sarebbe equivalente a cliccare "accetta comunque" su un sito con certificato scaduto o non valido, per sempre, per tutte le connessioni, svuota di significato la protezione che i certificati OPC-UA dovrebbero garantire. Un attaccante in posizione di man-in-the-middle sulla rete OT può presentare il proprio certificato self-signed al posto di quello del server legittimo, e i client si connetteranno senza rilevare la sostituzione.

Security Policy "None": crittografia assente

OPC-UA definisce security policy che determinano la combinazione di algoritmi usati per firma e crittografia delle comunicazioni. Tra questi c'è la policy speciale "None", che disabilita completamente sia la firma sia la crittografia: il traffico scorre in chiaro, senza integrità crittografica.

"None" esiste per scenari di test e debugging, e per ambienti completamente isolati dove la crittografia è ritenuta non necessaria. In pratica si trova in produzione per due ragioni: compatibilità con client molto datati che non supportano le policy crittografiche moderne, e ragioni di performance su hardware con capacità computazionale limitata.

Il problema di sicurezza è diretto: con policy "None", un attaccante che ha accesso passivo al traffico di rete OT può leggere tutto il contenuto delle sessioni OPC-UA: valori di tag di processo, comandi verso attuatori, dati di configurazione. Se ha accesso attivo (man-in-the-middle), può modificare i messaggi in transito senza che il server o il client se ne accorgano, perché non c'è firma crittografica da violare.

Nel traffico di rete, la security policy usata da una sessione OPC-UA è visibile nel messaggio OpenSecureChannel: il campo SecurityPolicyUri contiene l'URI della policy selezionata. L'URI "http://opcfoundation.org/UA/SecurityPolicy#None" identifica inequivocabilmente le sessioni non crittografate e non firmate.

Esposizione su porte non standard e discovery

La porta standard di OPC-UA è TCP 4840. In pratica, molte implementazioni usano porte diverse: per ragioni di convenienza, per evitare conflitti con altri servizi, o semplicemente per scelta dell'integratore. Questo crea un problema di inventario: i sistemi di monitoraggio configurati per rilevare OPC-UA sulla porta 4840 non vedono i server che usano porte alternative.

OPC-UA include un meccanismo di discovery, il Local Discovery Server (LDS), che consente ai client di trovare i server disponibili sulla rete. Nei deployment in cui l'LDS è attivo e raggiungibile, un client può ottenere automaticamente la lista di tutti i server OPC-UA nella rete, con i loro endpoint e le security policy supportate. Questo meccanismo, progettato per semplificare la configurazione operativa, è anche un meccanismo di ricognizione estremamente efficiente per un attaccante: una singola query all'LDS restituisce una mappa completa dei server OPC-UA presenti.

Il rilevamento corretto di OPC-UA in rete richiede identificazione basata sul comportamento del protocollo, il processo di handshake Hello/Acknowledge che caratterizza l'apertura di ogni connessione OPC-UA binary, non solo sul numero di porta. Un sistema di monitoring del traffico industriale che decodifica i protocolli applicativi identifica sessioni OPC-UA su qualsiasi porta.

Cosa si vede nel traffico e come rilevare accessi anomali

Le sessioni OPC-UA legitimate hanno caratteristiche riconoscibili: vengono stabilite da indirizzi sorgente noti (il client SCADA, l'historian), usano security policy coerenti con la configurazione dell'impianto, hanno pattern di operazione prevedibili (lettura periodica di un insieme stabile di tag).

I segnali che indicano accessi anomali o configurazioni problematiche includono:

• Sessioni da indirizzi non visti in precedenza: un client OPC-UA che si connette a un server da un indirizzo che non ha mai stabilito sessioni prima va investigato. Può essere un nuovo tool di engineering, può essere un attaccante con accesso alla rete.
• Sessioni con security policy None o Anonymous su server che non dovrebbero usarle: se la baseline mostra che un determinato server usa sempre policy Basic256Sha256, una sessione con policy None verso lo stesso server è anomala.
• Operazioni di browse intensiva sull'address space: le operazioni di Browse, che navigano la gerarchia dei nodi del server, sono normali durante la configurazione e rare durante l'operatività. Un burst di operazioni Browse da un client insolito indica ricognizione.
• Write verso nodi che hanno solo traffico Read nella baseline: un nodo OPC-UA che viene interrogato ogni 5 secondi in lettura ma non riceve mai scritture è probabilmente un sensore di processo. Una scrittura verso quel nodo da un client non autorizzato è un segnale critico.
• Volume di traffico significativamente superiore alla baseline: potrebbe indicare dump massivo di dati di processo, esfiltrazione di dati storici o configurazione.

OPC-UA è un protocollo ben documentato e completamente decodificabile dall'analisi del traffico di rete. La granularità di visibilità che offre, fino al livello dei singoli nodi letti e scritti, con i valori associati, è superiore a quella di protocolli più datati come Modbus. Questo è un vantaggio per il monitoring della sicurezza, a condizione che gli strumenti usati implementino la decodifica completa del protocollo e non si limitino alla visibilità a livello TCP.

L'angolo MON5

Sessioni anonime, policy None, certificati mai validati: tutti i problemi descritti in questo articolo sono visibili nel traffico, a patto di decodificare OPC UA a livello applicativo e non fermarsi alla porta TCP. Il NDR passivo della fase PROTECT di MON5 fa proprio questo: decodifica nativa di OPC UA (oltre a Modbus, Siemens S7, PROFINET, EtherNet/IP), baseline per server e per nodo, alert su sessioni anonime impreviste, write verso nodi di sola lettura, burst di Browse anomali.

Tutto fuori banda, senza toccare i sistemi in produzione. Per scoprire come sono configurati davvero i server OPC-UA del vostro impianto, il punto d'ingresso è un assessment OT.