Industrial DMZ: come progettare la zona di confine tra rete IT e rete OT

Perché una connessione diretta IT-OT è un rischio architetturale

La spinta a connettere la rete IT con la rete OT è comprensibile: i dati di processo hanno valore anche fuori dalla fabbrica. I sistemi ERP devono sapere quante unità ha prodotto ogni linea. Il team di ingegneria vuole accedere da remoto per la diagnostica. La direzione vuole un cruscotto con i KPI di produzione in tempo reale.

Il problema è come si realizza questa connessione. L'approccio più semplice, tecnicamente, è abbattere la separazione: mettere la rete OT sullo stesso segmento della rete IT, o al massimo aggiungere una regola di firewall permissiva. Il risultato è una rete piatta dove un endpoint IT compromesso ha accesso diretto ai PLC, agli HMI, ai sistemi SCADA. Un ransomware che si propaga lateralmente nella rete IT non trova ostacoli architetturali prima di raggiungere i sistemi di controllo.

La DMZ industriale (Industrial DMZ, I-DMZ) è la risposta architetturale a questo problema. È una zona di rete intermedia, fisicamente e logicamente separata sia dalla rete IT che dalla rete OT, dove vivono i servizi che hanno bisogno di parlare con entrambi i mondi. Non è un firewall più potente: è un cambio di paradigma. Nessun host IT comunica direttamente con un host OT, e viceversa. Tutto il traffico passa attraverso sistemi intermedi collocati nella DMZ, che mediano la comunicazione e applicano controlli.

Cosa va nella DMZ industriale

Identificare quali componenti appartengono alla DMZ è il primo passo progettuale. Il criterio è semplice: se un sistema deve ricevere dati dall'OT e renderli disponibili all'IT, o se deve permettere all'IT di agire sull'OT in modo controllato, quel sistema sta nella DMZ.

Historian replica (o data broker). L'historian di processo raccoglie i dati in tempo reale dall'OT e li mette a disposizione dei sistemi IT per analisi, reportistica, integrazione ERP. L'approccio corretto non è permettere all'ERP di interrogare direttamente l'historian OT, ma replicare i dati verso un secondo historian collocato nella DMZ, che diventa il punto di accesso per l'IT. Il flusso è unidirezionale: OT scrive nell'historian di processo, l'historian di processo replica in DMZ, i sistemi IT leggono dalla replica. Nessun sistema IT ha mai una connessione verso la rete OT.

Jump server (o bastion host). L'accesso remoto agli asset OT, sia da parte del personale interno che dei vendor, deve passare per un punto di accesso controllato. Il jump server vive nella DMZ, è hardened, ha autenticazione multi-fattore, registra tutte le sessioni. Un tecnico esterno che deve fare manutenzione su un PLC si connette alla VPN aziendale, da lì al jump server in DMZ, da lì al dispositivo OT. In ogni passaggio ci sono autenticazione, log, e la possibilità di terminare la sessione in caso di comportamento anomalo.

File transfer controllato. Aggiornamenti firmware, file di configurazione, patch per sistemi Windows embedded nell'OT: tutto questo deve attraversare il confine IT-OT. Il meccanismo corretto è un sistema di file transfer nella DMZ con scansione antimalware obbligatoria e workflow di approvazione. I file arrivano dall'IT nella DMZ, vengono scansionati, vengono approvati, vengono poi scaricati dall'OT. Mai trasferimento diretto da USB o da condivisioni IT.

Patch management server. I sistemi Windows o Linux nell'OT hanno bisogno di patch di sicurezza, ma non possono accedere direttamente a Windows Update o ai repository IT. Un server di patch management nella DMZ raccoglie gli aggiornamenti dall'IT e li distribuisce verso l'OT in modo controllato, con possibilità di staging e rollback.

Proxy per protocolli OT verso il cloud. Se alcuni dati OT devono raggiungere servizi cloud (telemetria verso il vendor del PLC, integrazioni con piattaforme di analytics), il proxy risiede in DMZ e non nella rete OT. Questo limita la superficie esposta verso l'esterno.

Pattern di design: il firewall dual-homed e le regole minime

La realizzazione fisica della DMZ industriale prevede tipicamente due firewall in serie: un firewall tra IT e DMZ, e un secondo firewall tra DMZ e OT. Il traffico deve attraversare entrambi per andare da un lato all'altro.

Il pattern dual-homed con due firewall separati (idealmente di vendor diversi, per evitare che una vulnerabilità nel firewall colpisca entrambi i livelli) è preferibile all'approccio con un singolo firewall a tre interfacce. La ragione è semplice: se il firewall unico viene compromesso, tutti e tre i segmenti sono esposti. Con due firewall in serie, un attaccante deve comprometterne due.

Le regole di firewall per la DMZ industriale devono seguire il principio del minimo privilegio applicato al traffico di rete:

• Dall'OT alla DMZ: solo i protocolli necessari per la replica dell'historian e per le comunicazioni verso il patch server. Nessuna connessione OT verso internet.
• Dalla DMZ all'OT: solo il traffico di risposta alle connessioni iniziate dall'OT, il traffico del patch server, le sessioni autorizzate dal jump server.
• Dall'IT alla DMZ: accesso all'historian replica, al jump server (previa autenticazione), al sistema di file transfer.
• Dalla DMZ all'IT: nessuna connessione iniziata dalla DMZ verso l'IT. Solo risposte.

La tentazione di aggiungere eccezioni cresce nel tempo: un sistema vuole accedere direttamente, un vendor chiede una porta aperta temporanea che poi rimane permanente, un'integrazione legacy non funziona con i proxy. Ogni eccezione deve essere documentata, giustificata, approvata e revisionata periodicamente.

Segmentazione per criticità all'interno dell'OT

La DMZ non è l'unica separazione necessaria. All'interno della rete OT, la segmentazione per criticità riduce ulteriormente il rischio: se un dispositivo OT viene compromesso, la segmentazione interna limita la propagazione verso i sistemi più critici.

Un approccio comune per l'OT manifatturiero è dividere la rete OT in zone basate sulla criticità del processo:

• Zona critica: PLC, DCS, sistemi di sicurezza (SIS). Accesso strettamente limitato, nessuna connessione diretta da zone meno critiche.
• Zona di supervisione: HMI, SCADA server, historian primario. Comunica con la zona critica e con la DMZ.
• Zona periferica: dispositivi di campo con connettività di rete, stampanti industriali, sistemi di visione. Isolati dalle zone superiori dove possibile.

La segmentazione interna non richiede firewall enterprise per ogni zona: VLAN con ACL correttamente configurate sono spesso sufficienti per la maggior parte degli ambienti manifatturieri di medie dimensioni.

Iniziare con una DMZ minimale e farla crescere

La DMZ industriale completa, con historian replica, jump server, patch management e tutti i componenti descritti, può sembrare un progetto di grande scala. Per molte PMI manifatturiere, il punto di partenza pratico è una DMZ minimale che risolve i problemi più urgenti.

La versione minimale parte da due elementi: un firewall che separa l'OT dalla rete IT (anche con un singolo firewall, come primo passo) e un jump server per l'accesso remoto controllato. Questo elimina già l'accesso diretto all'OT e centralizza la gestione degli accessi remoti dei vendor, che sono tra i vettori di attacco più frequenti in ambito OT.

Il secondo passo è aggiungere l'historian replica, che toglie ai sistemi IT la necessità di accedere direttamente all'OT per i dati di processo. Il terzo passo è strutturare il file transfer con scansione malware. Solo dopo questi elementi fondamentali conviene affrontare la segmentazione interna OT e il patch management strutturato.

Ogni aggiunta deve essere pianificata con il team operations, non solo con il team IT: modificare l'architettura di rete OT richiede finestre di manutenzione, test di regressione sul processo, e coordinamento con i vendor dei sistemi di controllo. La DMZ industriale non è un progetto che si implementa in un pomeriggio, ma ogni passo riduce concretamente il rischio architetturale di partenza.

L'angolo MON5

Chiariamo subito un punto: la DMZ industriale la realizzano i firewall e gli apparati che applicano le regole deny-all con whitelist descritte sopra. MON5 non è quel firewall, non fa enforcement e non blocca traffico inline. Il suo ruolo è un altro, ed è complementare: fornire la visibilità per progettare il confine e poi verificare che resti integro.

Le regole della DMZ si scrivono infatti a partire dal traffico reale, non dalle ipotesi. La fase DISCOVER di MON5 serve proprio a questo: osservazione passiva dei flussi tra IT e OT e ricostruzione della topologia di rete, senza fermare la produzione, per documentare cosa transita davvero al confine. ANALYZE struttura poi quei flussi in zone e conduit secondo IEC 62443.

Una volta in esercizio, la fase PROTECT con NDR passivo fuori banda verifica nel tempo che i conduit vengano rispettati e segnala le comunicazioni che violano l'architettura: porte temporanee rimaste permanenti, flussi mai autorizzati, deviazioni dalla baseline. Prima di disegnare la tua DMZ, fotografa i flussi reali con un assessment OT.