Network segmentation nell'OT: dal modello Purdue alle zone IEC 62443 in produzione

Il modello Purdue: ancora valido?

Il modello Purdue è stato per decenni la mappa di riferimento per le architetture di rete nei sistemi di controllo industriale. Definisce cinque livelli gerarchici, dai sensori e attuatori fisici (livello 0) fino ai sistemi aziendali (livello 5), con comunicazioni che dovrebbero fluire verticalmente, livello per livello, senza salti orizzontali.

L'idea è elegante: separare fisicamente e logicamente i livelli in modo che una compromissione a un livello non si propaghi automaticamente agli altri. Un problema nel livello 1 (controller di campo) non dovrebbe raggiungere il livello 4 (sistemi aziendali) e viceversa.

Il modello Purdue nella sua forma pura è stato eroso dalla realtà moderna. La pressione verso la connettività diretta (per l'analisi dei dati di produzione, per la manutenzione predittiva, per l'integrazione con sistemi ERP) ha creato un ecosistema dove le connessioni trasversali tra livelli sono diventate la norma. Il modello rimane valido come framework concettuale, ma la sua implementazione rigorosa è diventata rara.

Zone e conduit secondo IEC 62443

IEC 62443 aggiorna e generalizza il concetto Purdue con il modello di zone e conduit, più flessibile e applicabile agli ambienti moderni.

Una zona è un gruppo di asset con requisiti di sicurezza omogenei e un livello di trust comune. Non è necessariamente legata a un livello fisico o a un edificio specifico: può essere definita da funzione operativa, da criticità, da esposizione al rischio. Una zona tipica può includere tutti i PLC di una linea di produzione, o tutti i sistemi di supervisione di un impianto specifico.

Un conduit è il canale di comunicazione autorizzato tra zone diverse. Ogni comunicazione che attraversa un confine di zona deve passare attraverso un conduit, che implementa i controlli necessari: firewall con regole specifiche, proxy applicativi, sistemi di filtraggio del traffico OT.

Il modello è più granulare del Purdue: permette di definire zone basate sulla realtà dell'ambiente specifico, non su una gerarchia astratta. Può coesistere con architetture esistenti senza richiedere una ristrutturazione completa.

La DMZ IT-OT: perché è fondamentale e come implementarla

La zona di maggiore rischio in qualsiasi architettura OT moderna è l'interfaccia tra rete IT aziendale e rete OT. È il punto dove i dati di produzione devono fluire verso i sistemi aziendali, ma dove allo stesso tempo una compromissione IT non dovrebbe propagarsi all'OT.

La soluzione è una DMZ dedicata IT-OT: una zona intermedia che non appartiene né alla rete IT né a quella OT, che funge da buffer controllato per gli scambi di dati.

Come funziona in pratica:

• I sistemi OT non comunicano direttamente con la rete IT. Pubblicano i dati in sistemi nella DMZ (historian, data collector, API gateway).
• I sistemi IT leggono i dati dalla DMZ, non direttamente dall'OT.
• Le regole firewall permettono flussi di dati verso la DMZ dall'OT, e dalla DMZ verso l'IT. Non esistono regole dirette OT-IT o IT-OT.
• Un attaccante che compromette la rete IT può raggiungere la DMZ, ma non ha accesso diretto ai sistemi OT.

L'implementazione richiede la revisione di tutti i flussi di dati esistenti tra IT e OT, spesso una mappatura che non esiste documentata, e la ridefinizione di ogni integrazione perché passi attraverso la DMZ.

Micro-segmentazione nei moderni ambienti OT

Oltre alla segmentazione tra IT e OT, c'è valore nell'introdurre segmentazione all'interno della rete OT stessa. L'obiettivo è limitare il movimento laterale di un attaccante che abbia già ottenuto accesso a un segmento OT.

In ambienti OT moderni basati su Ethernet industriale, la micro-segmentazione può essere implementata con VLAN separate per zone funzionali diverse, con ACL che limitano le comunicazioni ai flussi strettamente necessari, e con firewall next-generation in grado di ispezionare il traffico OT a livello applicativo (Modbus, DNP3, OPC-UA).

La sfida è fare questo senza interrompere le comunicazioni necessarie al funzionamento degli impianti. Ogni regola restrittiva introdotta rischia di bloccare un flusso di dati che qualcuno ha bisogno. La segmentazione deve essere preceduta da una mappatura accurata di tutte le comunicazioni attive nella rete OT.

Passi pratici: da dove iniziare senza bloccare la produzione

La segmentazione di rete in un ambiente OT in produzione è uno dei progetti con il rischio operativo più alto se mal eseguito. Alcune indicazioni per farlo in modo controllato:

Iniziare con la mappatura passiva: prima di toccare qualsiasi configurazione, monitorare passivamente il traffico di rete per settimane. L'obiettivo è avere una mappa completa di tutte le comunicazioni attive. Qualsiasi regola di segmentazione basata su una mappa incompleta rischia di bloccare qualcosa di importante.

Introdurre i firewall in modalità monitor first: prima di applicare regole restrittive, configurare i firewall in modalità di solo log. Verificare che le regole pianificate non bloccherebbero traffico legittimo. Solo dopo alcune settimane di verifica, passare alla modalità enforcement.

Segmentare prima i sistemi meno critici: iniziare con zone che hanno minor impatto operativo in caso di errori di configurazione. Costruire esperienza e confidenza prima di toccare i sistemi di controllo più critici.

Pianificare finestre di manutenzione per i cambiamenti: ogni modifica all'architettura di rete OT dovrebbe essere eseguita durante finestre di manutenzione pianificate, con personale operativo presente e con un piano di rollback pronto.

Documentare ogni eccezione: durante il processo di segmentazione emergeranno casi in cui le regole standard non possono essere applicate per ragioni operative. Documentare ogni eccezione con la giustificazione e i controlli compensativi. Questo documento è anche la mappa del rischio residuo.

La segmentazione di rete non è un progetto con una data di fine: è un processo continuo che deve evolvere con l'ambiente. Ogni nuovo sistema introdotto, ogni nuovo flusso di dati, ogni integrazione con sistemi esterni deve essere valutata rispetto al modello di zoning esistente.

L'angolo MON5

Una premessa, per evitare equivoci: MON5 non è il firewall e non applica la segmentazione. Non si frappone al traffico, non blocca pacchetti inline e non è un prodotto di micro-segmentazione. Quello che MON5 fa è renderla progettabile e poi verificabile nel tempo. La distinzione conta, perché l'enforcement resta in capo agli apparati di rete che già conoscete.

Come spiega l'articolo, segmentare senza una mappa completa delle comunicazioni è il modo più rapido per fermare una linea. Qui entra in gioco MON5, in due fasi. DISCOVER ricostruisce topologia e flussi reali con discovery passiva, senza interferire con la produzione, così le regole di firewall si scrivono su dipendenze verificate e non su documentazione obsoleta. ANALYZE supporta la progettazione di zone e conduit secondo IEC 62443 a partire dal traffico osservato.

Quando la segmentazione è in esercizio, PROTECT verifica nel tempo che venga davvero rispettata e segnala le comunicazioni che violano l'architettura disegnata: flussi mai autorizzati, eccezioni che si accumulano, deviazioni dalla baseline. Per arrivare alla segmentazione con una mappa affidabile in mano, il primo passo è un assessment OT.