Nell’ambito della Cybersecurity industriale (ICS/OT) la Defense in Depth (“Difesa in profondità”) si avvale della separazione tra i dispositivi, del censimento e del monitoraggio delle porte di comunicazione, delle applicazioni, dei servizi e delle altre risorse suddivise in gruppi definiti Zone di sicurezza. Queste Zone interconnesse tramite Condotti di sicurezza, proprio come un condotto utilizzato per ospitare e contenere fili e cavi, vengono utilizzate per proteggere più percorsi o canali di comunicazione: isolando le risorse in gruppi e controllando tutto il flusso di comunicazioni interne nonché tra gruppi, la superficie di attacco informatico relativa ad un determinato gruppo viene notevolmente ridotta.

Questo concetto è stato originariamente definito nel modello architetturale di riferimento Purdue, che delinea l’organizzazione gerarchica dei sistemi CIM (Computer Integrated Manufacturing). Il modello è stato successivamente incorporato dal comitato ISA-99, e successivamente incluso nello standard IEC-62443. Le Zone di sicurezza (o semplicemente Zone da questo punto in poi), possono essere definite sia da un punto di vista fisico che logico: le Zone fisiche sono definite in base al raggruppamento degli asset nonché alla loro ubicazione logistica, mentre le Zone logiche sono più affini a delle aree virtuali, in quanto le risorse sono raggruppate in base a una particolare funzionalità o caratteristica.

I Condotti di sicurezza costituiscono un tipo particolare di Zona che raggruppa le comunicazioni (traffico dati, voce, traffico IoT, wi-fi, traffico 5G ecc..ecc..) in disposizioni logiche dei flussi di informazioni all’interno e tra le varie Zone. I Condotti possono anche essere disposti in base a vincoli fisici (cablaggi di rete) e/o logici (canali di comunicazione).

Il modello a Zone e Condotti è stato ideato per un motivo preciso. Se implementati correttamente, Zone e Condotti di sicurezza limitano le comunicazioni digitali in modo tale che ogni Zona diverrà intrinsecamente più sicura. In altre parole, tale modello è più resiliente alle conseguenze di un attacco informatico nell’ipotesi in cui una minaccia sfrutti una particolare vulnerabilità all’interno di una Zona: fornisce quindi una base solida su cui progettare e mantenere policy di Sicurezza fisica (Safety) e policy di Sicurezza informatica (Cybersecurity) e, per sua natura, supporta altri ben noti principi di sicurezza, tra cui il Principio del privilegio minimo (in cui gli utenti possono accedere solo ai sistemi e servizi a cui sono autorizzati), nonché il Principio del percorso minimo (in cui a un nodo in rete dovrebbe essere fornita la sola connettività necessaria per svolgere le sue funzioni). Sfortunatamente, le Zone sono spesso definite solo in termini molto ampi, separando la rete industriale in appena due o tre Zone (ad esempio: una Zona del sistema di controllo, una Zona commerciale e una Zona demilitarizzata tra le altre due). Allo stesso modo, i condotti sono spesso definiti in modo superficiale, ad esempio come “tutti i percorsi di comunicazione all’interno di una singola Zona” o “tutti i percorsi di comunicazione tra due zone”.

Man mano che la definizione di Zone e Condotti diventerà più chiara per l’analista, si otterrà un corrispondente miglioramento della Sicurezza informatica.

Risulta quindi di primaria importanza identificare con attenzione le Zone nelle prime fasi del ciclo di vita progettuale della Cybersecurity industriale.

In alcuni casi, come negli impianti nucleari, è obbligatorio un sistema a cinque livelli, sulla base di regolamenti specifici.

Queste linee guida dovrebbero essere considerate come un punto di riferimento basilare per la separazione delle Zone. Nella maggior parte dei casi, le Zone possono e devono essere definite in modo assai più preciso. Una volta definiti, Zone e Condotti contribuiranno a individuare le aree in cui è fondamentale richiedere controlli di accesso e sicurezza sia alla rete che agli host. Questo perché, limitando le comunicazioni a Condotti definiti, ogni Condotto rappresenta un potenziale vettore di attacco alla rete. Se implementati in modo inadeguato, Zone e Condotti si tradurranno in un’architettura disorganizzata e vulnerabile, viceversa, se strutturati con cognizione di causa concorreranno alla messa in opera di un’architettura ICS resiliente ad attacchi informatici. Questo non vuol dire che una Zona o un Condotto siano definiti dai controlli di sicurezza, ma piuttosto che Zone e Condotti possono facilitare la corretta selezione, il più adatto posizionamento e la miglior configurazione dei controlli di sicurezza. I controlli di sicurezza della rete, come firewall, IDS e IPS, ACL sugli switch, monitor delle applicazioni e/o analoghi prodotti di sicurezza, saranno estremamente efficaci se implementati in un’architettura ben organizzata con policy chiare e definite sulla base delle Zone e dei Condotti. Come per le difese perimetrali, le difese interne devono essere configurate anche sulla base dei parametri autorizzati da Zone e Condotti circoscritti e documentati con accuratezza.

Un altro aspetto interessante della progettazione e dell’implementazione di Zone e Condotti è come possano essere utilizzati per fornire architetture di sicurezza informatica più resilienti. Prendiamo in considerazione un raggruppamento di risorse che non può essere protetto individualmente con difese antimalware: queste risorse potranno essere raggruppate logicamente in una Zona, e le difese antimalware implementate sui Condotti in quella stessa Zona. Si tratta di un assetto efficace in cui i proprietari delle risorse potranno continuare a operare su sistemi legacy e persino non più supportati (come ad esempio Windows 7 e precedenti) attraverso la creazione di Zone di risorse correlate, e quindi applicando severi controlli di sicurezza sui Condotti che accedono in quelle Zone.

I concetti alla base di Zone e Condotti possono creare confusione, e spesso sono fraintesi da coloro che credono che si tratti semplicemente di un sinonimo del modello Purdue, adottato come standard ISA nell’IEC-62264. Gli addetti ai lavori dovrebbero rendersi conto che le motivazioni alla base del modello Purdue e di IEC-62264 costituivano (e costituiscono ancora!) l’integrazione di applicazioni aziendali e d’automazione e il relativo scambio di informazioni. Questi concetti sono molto diversi da quelli alla base del raggruppamento e classificazione degli asset in base a particolari criteri di sicurezza.

Ogni architettura industriale è unica, non tanto per la selezione delle apparecchiature, quanto per il modo in cui ciascun sistema viene implementato in un particolare ambiente (prodotti finali fabbricati, posizione geografica, personale, ecc..) e nel modo in cui ciascun sistema è integrato con altri sistemi ausiliari per formare un’architettura di controllo industriale completa, integrata. Una buona analogia con le Zone di sicurezza consiste nel considerare quante strutture industriali mantengono la separazione tra le risorse di controllo di base e quelle relative alla sicurezza. Questa separazione si verifica non solo a causa delle leggi e dei regolamenti esistenti, ma anche a causa dei livelli di protezione sottostanti forniti da ciascuno di questi sistemi, e dall’unicità della relativa protezione di ciascun sistema. Questo “livello di sicurezza” può essere applicato a ciascun sistema in modo che possano essere messe in atto misure appropriate per garantire che ciascun sistema funzioni come previsto senza conseguenze o interazioni involontarie tra i sistemi che ne influenzano le funzionalità di base. In termini di sicurezza, si può applicare un concetto simile: le risorse in un determinato impianto industriale possono essere raggruppate in base ai relativi requisiti di sicurezza o “livelli di sicurezza”. Queste Zone vengono quindi create come “esterne” o, quando sono richiesti più livelli di protezione, possono essere “nidificate” l’una nell’altra. Questo consente di implementare i controlli di sicurezza nelle Zone (e nelle risorse che contengono) in base ai Requisiti di sicurezza univoci di ciascun Zona: le informazioni devono fluire dentro, fuori e all’interno di una determinata Zona. Anche nei sistemi autonomi o “air-gapped”, gli aggiornamenti software e i dispositivi di programmazione vengono generalmente utilizzati per effettuare manutenzioni di sistema e mantenere operativo e funzionale l’ICS stesso: rappresentano tutti punti di ingresso alle Zone, detti appunto Condotti.

Identificare e classificare Zone di sicurezza e Condotti

Una delle principali sfide nella definizione di Zone e Condotti di sicurezza adeguati consiste nella definizione di una serie di requisiti di base che vengono utilizzati per determinare se una particolare risorsa debba essere collocata in una determinata Zona. Non esiste una risposta univoca al metodo che possiamo utilizzare: dopotutto, raramente due installazioni ICS sono identiche e, pertanto, anche i relativi livelli di sicurezza non saranno mai gli stessi. Questi requisiti in genere possono essere suddivisi in due grandi categorie. Il primo si basa sulle comunicazioni e su come ogni risorsa interagisce con altre risorse al di fuori di una particolare Zona. Per spiegarlo diversamente, consideriamo un dipendente dell’azienda (un Ingegnere di processo ad esempio) che utilizza il computer dell’ufficio nell’edificio amministrativo, e la workstation di Ingegneria nella sala di controllo. Questo utente è una risorsa, ma di quale “Zona” fa parte? Oppure questo utente in realtà costituisce un “Condotto” tra Zone? Questi asset sono anche tipicamente collegati a una rete industriale che fornisce la capacità per lo scambio elettronico di informazioni. Questa comunicazione può inoltre essere designata come “locale” o all’interno della stessa Zona, piuttosto che “remota” o all’esterno della Zona.

L’accesso fisico rappresenta un altro approccio per classificare le risorse all’interno di una particolare Zona di sicurezza. Consideriamo una sala di controllo che ospita operatori d’impianti, tecnici e ingegneri dei sistemi di controllo. Sebbene questi individui si trovino tutti all’interno della sala di controllo (fisicamente sicura), non possiedono necessariamente lo stesso livello di “fiducia” l’uno rispetto all’altro. Ciò porta alla creazione di Zone integrate in cui una Zona con un livello di sicurezza superiore (utilizzata da un Ingegnere ad esempio) è incorporata in una Zona di livello inferiore (utilizzata dagli operatori) che riflette la relativa fiducia (il livello di “trust”) e il livello di sicurezza degli utenti.

Gli asset possono esistere al di fuori di una particolare Zona di sicurezza, ma non significa che i beni siano necessariamente a un livello superiore o inferiore, piuttosto a un “diverso livello” da altri asset nella stessa Zona. Uno degli esempi più lampanti di questo tipo di suddivisione si palesa quando si dispone di un particolare raggruppamento di risorse che utilizzano un protocollo industriale vulnerabile. Alcuni di questi protocolli sono necessari per eseguire funzioni specifiche all’interno di una Zona che originariamente non era stata pensate per contenere risorse “ostili” o “non attendibili”. Un impianto di produzione può avere più aree o celle di lavoro che ospitano apparecchiature simili in Zone associate: per proteggere adeguatamente tali Zone, i relativi Condotti dovranno limitare le comunicazioni impedendo appunto l’uso di protocolli vulnerabili – così come di quelli meno sicuri – a utenti o servizi non autorizzati.

Come accennavo, le Zone possono essere definite ad alto livello (Zone di “controllo” rispetto a Zone “aziendali”) o in modo certosino, creando Zone per gruppi funzionali di risorse altamente granulari. Il modello “Zone e Condotti” può essere applicato a quasi tutti i livelli: l’esatta implementazione dipenderà dall’architettura di rete, dai requisiti operativi, dai rischi identificati e dalla tolleranza al rischio associata, insieme a molti altri fattori. Ecco alcune raccomandazioni su come definire Zone distinte. (Nota: quando si definiscono Zone estremamente peculiari, si dovrebbe presumere che prima o poi ci si imbatterà in una sovrapposizione che potrebbe impedire un’adeguata applicazione di Zone e Condotti, ad esempio, è probabile che una Zona definita da sottosistemi di controllo fisico possa sovrapporsi a Zone definite logicamente da protocolli specifici, e dal punto di vista architetturale potrebbe essere ostico separarle).

Il processo che esamina i vari modi in cui le risorse possono essere raggruppate logicamente e come può essere controllata la comunicazione, è fondamentale e altamente vantaggioso: contribuirà a identificare aree di rischio precedentemente non individuate, e dove sarà opportuno definire e controllare Zone più specifiche. Contribuirà inoltre a migliorare la Cybersecurity Posture della rete end-to-end.

Quando si valuta la rete del cliente e si identificano le potenziali Zone, occorre includere tutte le risorse (dispositivi fisici), i sistemi (software e applicazioni, anche quelli virtualizzati), gli utenti, i protocolli e altri elementi. Scenario del tentativo di separare due elementi, ad esempio un protocollo da una risorsa: se i due elementi possono essere separati senza influire sulla funzione primaria di nessuno dei due, appartengono a due gruppi funzionali, e sono quindi ottimi candidati per le proprie Zone. Ad esempio, se alcuni sistemi SCADA utilizzano il protocollo DNP3, è opportuno creare un elenco di tutti i dispositivi che attualmente comunicano tramite DNP3, valutare ciascun dispositivo per verificare se DNP3 sia fondamentale o meno per la sua funzione operativa (potrebbe supportare più protocolli ad esempio, e potrebbe utilizzare attivamente un protocollo diverso per svolgere le sue funzioni). In caso contrario, è opportuno rimuoverlo dal gruppo funzionale e, se possibile, disabilitare anche il protocollo inutilizzato sul server SCADA. Il risultato sarà un elenco di tutte le risorse che utilizzano legittimamente quel protocollo. Allo stesso modo, occorre valutare quali risorse sono connesse tra loro in rete, sia fisicamente che logicamente. Ognuno rappresenta un gruppo funzionale basato sulla connettività di rete e sul flusso di dati. Ancora una volta, è opportuno valutare ogni elemento non solo su base individuale e, se non è necessario che vi appartenga, rimuoverlo dal gruppo. Un gruppo funzionale può essere basato su quasi tutto. I gruppi funzionali comuni da considerare quando si definiscono le Zone nelle reti industriali includono sicurezza, controllo dei processi di base, controlli di supervisione, processi di controllo peer-to-peer, archiviazione dei dati di controllo, comunicazioni commerciali, accesso remoto, capacità di applicare patch, ridondanza, protezione da malware, capacità di autenticazione ecc..ecc.. Possono essere presi in considerazione altri gruppi, come gruppi di utenti e gruppi di protocolli industriali.

I gruppi funzionali basati sulla segmentazione della rete sono facili da identificare poiché le reti collegano tra loro dispositivi. Il modo in cui i diversi dispositivi sono collegati alla rete distingue a livello perimetrale gli elementi che appartengono a un gruppo interconnesso, da quelli che sono esclusi da una connessione o da un determinato Condotto di rete. Le reti devono essere valutate sia fisicamente (quali dispositivi sono connessi ad altri dispositivi tramite cavi di rete o connessioni wireless) che logicamente (quali dispositivi condividono lo stesso spazio di rete instradabile, sottorete o elenco di ACL). I confini fisici della rete sono facili da determinare utilizzando una network map aggiornata: idealmente (sebbene non realisticamente), tutte le reti di un ICS dovrebbero avere un confine fisico rigido sotto forma di un flusso unidirezionale che impedisca al traffico di rete di accedere ad una Zona più sicura da una meno sicura. Realisticamente, ci saranno punti di interconnessione costituiti da un unico collegamento, preferibilmente attraverso un firewall e/o altri dispositivi di networking.

Tipicamente i confini logici della rete sono definiti attraverso l’uso di dispositivi che operano sul terzo livello della pila OSI (router, firewall, switch layer 3) separando una rete fisica in più sottoreti. Questi dispositivi forniscono una demarcazione logica tra ogni rete, forzando tutto il traffico di rete (da una rete logica a un’altra) a passare attraverso il dispositivo di terzo livello, dove è possibile implementare ACL, set di policy e altre misure di protezione. Le LAN virtuali (VLAN) costituiscono un tipo di confine logico, ma applicato a livello 2 anziché 3. Le VLAN utilizzano un tag standardizzato nell’intestazione del pacchetto Ethernet per determinare come vengono gestite da un dispositivo di livello 3. Il traffico destinato alla stessa VLAN viene commutato, mentre il traffico destinato a una diversa VLAN verrà instradato. Si tenga presente, tuttavia, che le VLAN non sono uno strumento esaustivo di Cybersecurity, in quanto in vari scenari legacy è possibile modificare l’intestazione del pacchetto per bypassarle, ingannando quindi lo switch e riuscendo così ad accedere al dominio di broadcast di un’altra VLAN.

Circuiti di controllo

Un circuito di controllo è costituito dai dispositivi responsabili di un particolare processo automatizzato. L’applicazione di questo elenco di dispositivi a un gruppo funzionale è relativamente semplice. Nella maggior parte dei casi, un circuito di controllo consta di un sensore (come un interruttore o un trasduttore), un controller (come un PLC) e un attuatore (come un relè o una valvola di controllo), come illustrato in figura:

Laddóve la definizione di un gruppo funzionale basato sulla connettività di rete costituisce un esempio lasco che potrebbe essere realizzato con una manciata di gruppi funzionali, la creazione di un gruppo funzionale basato su un ciclo di controllo è un esempio più dettagliato. I gruppi funzionali creati saranno numerosi, e ciascuno di essi conterrà un numero relativamente ridotto di dispositivi (uno specifico PLC o unità terminale remota (RTU), una raccolta di relè e dispositivi elettronici intelligenti (IED)). Uno degli esempi lampanti di come questo approccio sia utilizzato al giorno d’oggi nelle architetture industriali, è nell’uso di reti Fieldbus e nel modo in cui particolari circuiti di controllo vengono posizionati su segmenti di rete dedicati in base alla classificazione di rischi e delle funzionalità.

Controlli di supervisione

Ogni circuito di controllo è inoltre connesso a una sorta di controllo di supervisione, in genere un server di comunicazione e una o più workstation, responsabili della configurazione (engineering workstation EWS) nonché del monitoraggio e della gestione (operator workstation HMI) del processo automatizzato. Poiché l’HMI è responsabile del PLC, questi due dispositivi appartengono a un gruppo funzionale comune. Tuttavia, poiché l’HMI non è direttamente responsabile degli IED collegati ai PLC, gli IED e i PLC stessi non fanno necessariamente parte di un gruppo funzionale comune, come l’HMI (appartengono a un gruppo che li accomuna in base ad altri criteri, come il protocollo in uso).

In questo schema sono inclusi tutti i PLC controllati dall’HMI, così come qualsiasi HMI “master”, server di comunicazione o sistemi di gestione del controllo che potrebbero avere responsabilità o controllo sull’HMI iniziale. Non sono inclusi ulteriori HMI in quanto non sono di responsabilità dell’HMI iniziale. Piuttosto, ogni HMI potrebbe rappresentare il proprio gruppo funzionale. Se si utilizza un controller master comune per gestire più HMI, il gruppo funzionale distinto di ogni HMI conterrà lo stesso master, creando una sovrapposizione tra più gruppi funzionali (ci sono molti altri dispositivi, come azionamenti a motore, stampanti e sistemi di sicurezza che potrebbero essere
collegati a un HMI, tuttavia, questi elementi non sono mostrati in questo schema per semplificarne l’illustrazione e la comprensione).

Processi di controllo a livello di impianto

Ogni processo industriale è costituito da più di un PLC, svariati sistemi di I/O e un HMI. I sistemi di produzione, le applicazioni specifiche del settore, gli storici (“Historian”), gli asset management, i servizi di rete, le workstation di Ingegneria e le workstation operative e così via giocano tutti un ruolo essenziale. Inoltre, possono essere utilizzati un controller master, un’unità terminale master (MTU) e/o un server SCADA per gestire più HMI, ciascuno responsabile di una parte specifica di un processo di controllo più ampio.

La seguente figura, ad esempio, mostra come le Zone di controllo di base si possano estendere per includere altri sistemi rilevanti che abbracciano “livelli di integrazione”.

Questo esempio introduce anche il concetto di comunicazione e storicizzazione (“historization”) del processo. Se un dispositivo o un sistema si interfaccia con un server ICCP (ad esempio) per comunicare il carico elettrico di massa a un’altra entità elettrica, anche il server ICCP dovrebbe essere incluso nello stesso gruppo funzionale. Allo stesso modo, se le informazioni di processo provenienti dal dispositivo o dal sistema vengono immesse in un Data Historian, bisognerebbe includervi anche tale sistema.

Memorizzazione dei dati di controllo

Molti, moltissimi dispositivi utilizzati nei sistemi di automazione e controllo industriale generano dati che riflettono le modalità operative correnti, lo stato del processo, gli allarmi e altre vitali attività di informazione sul processo di produzione. Questi dati vengono generalmente raccolti e storicizzati attraverso un Data Historian, che può raccogliere dati da tutta la rete del sistema di controllo, dalla rete di supervisione e, in alcuni casi, anche dalla rete aziendale, come illustrato nel seguente schema:

In questo schema sono assenti i NAS (Network Attached Storage), le SAN (Storage Area Network) e altri sistemi di storage che potrebbero essere utilizzati per supportare i requisiti di archiviazione dei dati dell’Historian, in particolare nelle operazioni industriali più grandi.

Comunicazioni commerciali

La necessità di comunicare tra i centri di controllo (necessità diffusa nei settori della trasmissione elettrica e dei condotti) è sufficiente a giustificare un protocollo industriale specializzato, sviluppato appositamente per tale compito. Le connessioni ICCP (Inter-Control Center Communication Protocol) richiedono connessioni definite in modo esplicito tra client e server. Qualsiasi operazione che utilizzi ICCP per comunicare con un impianto sul campo e/o una filiale utilizzerà verosimilmente uno o più server ICCP e uno o più client ICCP (possono essere costituiti da un singolo server fisico o più server distribuiti).

Lavorando su questo gruppo funzionale è opportuno rammentare che i dispositivi client e quelli remoti sono tutti definiti esplicitamente, anche se di proprietà di un’altra azienda e ospitati presso le relative strutture. I client remoti dovrebbero essere inclusi all’interno del gruppo funzionale, in quanto hanno una relazione diretta con qualsiasi server ICCP locale che potrebbe essere in uso. Poiché le connessioni ICCP sono generalmente utilizzate per le comunicazioni commerciali, è fondamentale l’accesso alle informazioni operative: potrebbe essere costituito da un processo informativo manuale piuttosto che automatizzato, coinvolgendo gli archivi di dati storicizzati dall’Historian, rendendo quindi l’Historian parte della Zona “Trading Communications”, come in questo esempio.

Accessso remoto

Il protocollo ICCP è solo uno dei tanti protocolli che consentono l’accesso remoto a un sistema, infatti, molti sistemi di controllo e dispositivi industriali – tra cui HMI, PLC, RTU e persino IED – consentono di accedere tramite connessioni dial-up piuttosto che tramite connessioni di rete instradabili per motivi di diagnostica o di supporto tecnico. Nel contesto delle Zone di sicurezza e dei Condotti, è importante comprendere che “accesso remoto” si riferisce a qualsiasi comunicazione tramite Condotti verso zone “esterne”. Un accesso remoto non avviene necessariamente attraverso reti geografiche su vaste aree differenti, ma potrebbe semplicemente essere un accesso tra due Zone di sicurezza che si scambiano informazioni relative al controllo, da un lato all’altro dell’impianto.

Se viene autorizzato, l’accesso remoto ai dispositivi del sistema di controllo dovrebbe essere controllato tramite reti private virtuali (VPN) ma soprattutto attraverso architetture Zero Trust, dovrebbe consentire solo connessioni point-to-point definite in modo esplicito da entità note, tramite modalità sicure e canali cifrati. I Condotti di accesso remoto dovrebbero essere ulteriormente protetti con metodi di controllo degli accessi potenziati, tra cui l’applicazione delle policy end-point, appliance NGFW e policy di autorizzazione point-to-point. Gli utenti definiti in modo esplicito, i dispositivi a cui accedono e qualsiasi sistema VPN o RAS utilizzato costituiscono un gruppo funzionale di accesso remoto, come illustrato nella seguente figura:

Isolando funzionalmente le connessioni remote, è possibile applicare ulteriori controlli di sicurezza informatica: è estremamente importante per evitare un vettore vulnerabile e invitante per gli attacker.

Utenti e ruoli

I gruppi funzionali sono costruiti attorno ai sistemi, definendo esplicitamente quali siano i dispositivi che dovrebbero legittimamente comunicare con gli altri. Per l’interazione umana, come per un operatore che accede a un HMI per controllare un processo, è altrettanto importante definire quali utenti possano legittimamente comunicare con quali dispositivi: questo richiede uno o più sistemi di gestione professionale delle Identità e degli Accessi (popolarmente noti con la sigla IAM, acronimo di Identity and Access Management) centralizzati, in grado di definire gli utenti autorizzati all’accesso, i loro dispositivi, loggare e tracciare (sia testualmente ma a volte anche graficamente) i loro accessi, circoscrivere i loro ruoli nonché le relazioni e comunicazioni autorizzate tra loro. L’esempio più triviale di un sistema IAM è costituito dai servizi Active Directory di Microsoft, sebbene esistano altri IAM (sia commerciali che Open Source) più efficaci. La seguente figura mostra un gruppo funzionale contenente un utente, e quei dispositivi che l’utente può interfacciare:

Redigere una meticolosa mappatura di ruoli e responsabilità dei dispositivi può essere un’attività noiosa, ma è fondamentale poiché i gruppi funzionali risultanti possono essere utilizzati per rilevare accessi non autorizzati ai sistemi da parte di utenti altrimenti legittimi. Questo è uno dei motivi principali per cui molte architetture ICS si stanno spostando verso un’infrastruttura di controllo degli accessi basata sui ruoli (RBAC). RBAC fornisce un meccanismo per configurare privilegi di accesso specifici a ruoli specifici, e quindi in grado di assegnare a questi ruoli singoli utenti. Tipicamente le responsabilità associate a un determinato ruolo non cambiano di molto nel tempo, diversamente dai ruoli: un dipendente con accesso al sistema di controllo di una determinata HMI, al termine del rapporto di lavoro potrebbe decidere di manomettere dei sistemi. Inserendo un utente in un gruppo funzionale con solo i dispositivi che dovrebbe utilizzare, questo tipo di attività potrebbe essere facilmente rilevata e prevenuta (ricordiamolo: la stesura di Gruppi funzionali è solo il primo passo per definire le Zone, e una volta che le Zone effettive sono state definite, i Condotti dovranno ancora essere implementati e prudentemente protetti).

Protocolli

I dispositivi di automazione e gestione utilizzati nelle reti industriali possono essere descritti in modo efficiente al fine di creare gruppi funzionali basati sui protocolli che utilizzano. Ad esempio, dovrebbero poter utilizzare DNP3 i soli dispositivi censiti per l’utilizzo del protocollo DNP3, e se qualsiasi altro dispositivo utilizza DNP3, si tratta di un’eccezione degna di nota che gli analisti dovrebbero rilevare rapidamente e, se possibile, prevenire. Tornerò sul tema protocolli in successivi articoli di prossima pubblicazione. I dispositivi che utilizzano specifici protocolli industriali dovrebbero quindi essere identificati e registrati, al fine di costruire un gruppo funzionale chiaro e delineato, come mostrato nel seguente schema:

Criticità

Implementare Zone di sicurezza vuol dire isolare i fattori di influenza comuni in gruppi funzionali, in modo che possano essere tenuti separati e protetti da altri fattori non influenti. In termini di sicurezza funzionale dell’impianto, si parla di “Livello di integrità della Sicurezza” (Security Integration Level). Il SIL consente di quantificare la capacità di Sicurezza di un componente per garantire che dispositivi simili possano essere implementati in un sistema al fine di fornire sufficienti garanzie di funzionalità. Un concetto simile, noto come “Security Level (SL)”, è stato sviluppato dall’ISA come parte degli standard di Sicurezza ISA-62443 per fornire una misura in grado di quantificare la Sicurezza relativa di una particolare Zona o di un Condotto. Se applicato come parte del ciclo di vita della Sicurezza, durante la progettazione iniziale del sistema viene determinato un “Livello di Sicurezza target”. Questo livello iniziale viene quindi tilizzato per selezionare i componenti che hanno un particolare “Capability Security Level”, in modo che i componenti e i sistemi possano essere selezionati per garantire che tutte le risorse all’interno di una particolaref Zona soddisfino lo stesso SL. Una volta che il sistema è stato messo in servizio, è possibile determinare un “Livello di Sicurezza raggiunto” conclusivo attraverso una valutazione fisica per garantire che il sistema sia stato installato e messo in servizio correttamente, e che il sistema soddisfi il livello di Sicurezza desiderato una volta che è in funzione.

Lo standard ISA-62443 costituisce una base per il raggiungimento di un particolare livello di Sicurezza attraverso l’implementazione di controlli di Sicurezza definiti come requisiti di base (FR) e requisiti di sistema associati (SR).

La suddivisione in granulare in Zone offre i seguenti vantaggi:

• contribuisce a minimizzare la portata di un incidente di sicurezza informatica, qualora si verificasse, separando ulteriormente i sistemi secondo il Principio del percorso minimo. Se un asset venisse compromesso, l’incidente influirà solo su di un numero limitato di sistemi poiché la capacità di comunicare con altre zone tramite Condotti circoscritti è stata limitata anticipatamente
• concorre a proteggere i dispositivi critici dalle minacce interne – come un dipendente rancoroso che dispone già di un accesso fisico e logico alla Zona padre – poiché sono consentiti solo canali di comunicazione limitati tra le Zone
• coopera alla prevenzione dei movimenti laterali tra un sistema critico e gli altri: se i sistemi chiave vengono raggruppati tutti insieme solo perché tutti critici, una violazione riuscita di un sistema critico metterà a rischio l’intera infrastruttura. Consiglio di documentare e caratterizzare attentamente ogni Zona e tutti i dispositivi, i servizi, i protocolli e gli utenti al suo interno. Ribadisco che questa è una misura di sicurezza fondamentale poiché questi elenchi saranno utilizzati quando si implementeranno le difese perimetrali (parlerò della sicurezza perimetrale in un successivo articolo) ma anche quando si effettuerà il monitoraggio comportamentale (Network Behavior Analysis) delle Zone.

Istituzione di Zone e Condotti di Sicurezza

Come ho scritto in precedenza, i Condotti sono un tipo speciale di Zona di Sicurezza, quindi quando si tratta di capire come vengono strutturati Condotti e Zone, ha senso confrontarsi in più riunioni invitando i vari responsabili di area. I Condotti sono essenzialmente un tipo di Zone che contengono solo meccanismi di comunicazione come risorse. Quando la parola Zona viene utilizzata nel contesto della Cybersecurity OT, salvo diversa indicazione si presume che includa delle “condutture” (le risorse fisiche e logiche sono raggruppate in Zone). In termini di Condotti queste risorse sono strumenti di comunicazione, come l’infrastruttura di rete attiva e passiva (cavi, switch, router, firewall, ecc..) nonché i canali di comunicazione che transitano su questi cavi (protocolli industriali, chiamate di procedure remote, condivisione file, ecc..). All’inizio del ciclo di vita della Sicurezza, a queste Zone viene assegnato un livello di Sicurezza relativo che verrà utilizzato come base per requisiti di Sicurezza più specifici e per le caratteristiche associate che verranno applicate a tutte le risorse contenute all’interno di una certa Zona. Queste caratteristiche includono:

• policy di Sicurezza informatica
• inventario degli asset
• requisiti di Controllo
• requisiti degli Accessi
• minacce e vulnerabilità informatiche
• tecnologie autorizzate e non
• processi di Change Management
• elenco delle Zone collegate (solo tramite Condotti)

Man mano che ciascuna delle caratteristiche di una Zona viene definita, l’allocazione delle risorse all’interno di se stessa diventa palese, inclusa la possibile creazione di sottozone nidificate per risorse particolari che possono essere allineate con altre risorse all’interno della Zona specifica. Sarà quindi possibile stabilire un inventario completo delle risorse con cui si elencheranno componenti fisici (come computer, dispositivi di rete, dispositivi IoT, collegamenti di comunicazione e parti di ricambio) nonché componenti logici (come sistemi operativi, applicazioni, patch, database, file di configurazione e progettazione, documentazione ecc.. solo per citarne alcuni). Le risorse contenute all’interno di una Zona verranno quindi valutate in base alle potenziali minacce e vulnerabilità, al fine di determinare il rischio risultante nell’ipotesi in cui queste risorse dovessero cessare di svolgere la loro funzione operativa. Queste informazioni sono vitali per identificare le possibili contromisure di Sicurezza che potrebbero essere utilizzate per ridurre il rischio derivante da una minaccia che sfrutti una vulnerabilità, e quindi selezionare i controlli appropriati necessari per soddisfare il livello di Sicurezza per la Zona, considerando il costo rispetto al rischio. Le Zone vengono stabilite considerando le tecnologie autorizzate e quelle non consentite. Ogni tipo di tecnologia possiede verosimilmente delle vulnerabilità intrinseche (sia conosciute che sconosciute), e con queste vulnerabilità una certa quantità di rischio. Queste tecnologie devono essere allineate con le Zone di Sicurezza per evitare che una particolare tecnologia possa compromettere l’intera Zona. Una problematica comune a molti sistemi ICS è quella derivante dalla possibilità di consentire l’accesso negli impianti ai dispositivi e smartphone personali di tecnici manutentori piuttosto che di visitatori, a cui ci riferisce comunemente come come BYOD (“Bring Your Own Device”) all’interno delle Zone di controllo critiche. È risaputo che questi dispositivi portano con sé una certa quantità di rischi, ma creando Zone di Sicurezza dedicate per il loro traffico di rete, diventa possibile applicare una particolare policy di sicurezza attraverso altri controlli che possono essere implementati sui canali di comunicazione del Condotto da questa Zona ad altre più critiche. Fino a questo punto probabilmente è chiaro come si possa prendere una particolare risorsa informatica, piuttosto che un dispositivo integrato, e collocarlo in una particolare Zona di sicurezza. Ciò che potrebbe non essere così chiaro è come creare canali e assegnare risorse di “comunicazione” a queste speciali Zone. Il punto di partenza più semplice è considerare che nella maggior parte delle architetture industriali, la rete fisica è costituita da un Condotto. Prima di dire a te stesso “è facile”, è importante notare che la rete industriale funge solo da Condotto per canali di comunicazione “esterni” tra altre risorse e Zone: non rappresenta i canali utilizzati per la comunicazione tra applicazioni e processi esistenti all’interno di un singolo asset. Il fatto che esistano minacce e vulnerabilità per le risorse informatiche è altrettanto importante per le risorse di comunicazione. È noto che molti protocolli industriali oggi in uso contengono vulnerabilità che, se non adeguatamente gestite attraverso opportuni controlli di sicurezza informatica, potrebbero introdurre un rischio considerevole non solo per i dispositivi e per gli operatori che utilizzano quei protocolli, ma anche per altri dispositivi e altre persone che operano all’interno della stessa Zona. È anche importante valutare le vulnerabilità che possono esistere all’interno dell’infrastruttura di rete attiva, inclusi switch, router e firewall, poiché trascurare uno qualsiasi di questi componenti può introdurre un rischio significativo non solo per la rete (Condotti), ma anche per tutte le Zone connesse tramite l’eventuale Condotto compromesso: è questo il motivo per cui è altresì fondamentale eseguire un’approfondita Valutazione dei rischi e delle potenziali vulnerabilità anche per i Condotti di sicurezza, al fine di accertare che siano state implementate adeguate contromisure sul Condotto per garantire che venga raggiunto il livello di sicurezza desiderato. La documentazione dei canali di sicurezza, e dei canali di comunicazione in essi contenuti, è un ragguaglio vitale necessario per implementare accuratamente i controlli di sicurezza in tutta l’architettura. Tale documento viene utilizzato non solo per configurare dispositivi di livello superiore come router firewall switch e/o WLAN controller (che gestiscono l’accesso tra le Zone) ma anche tecnologie per il monitoraggio delle applicazioni, i sistemi IPS nonché tecnologie di monitoraggio e correlazione degli eventi (SIEM/SOAR). Una delle principali cause alla radice delle compromissioni in ambito industriale è l’errata o sciagurata configurazione dei dispositivi posizionati in prossimità dei Condotti, che collegano Zone “esterne” meno affidabili a Zone “interne” più sicure. Questi (e|o)rrori di configurazione derivano comunemente dal tentativo di configurare il controllo degli accessi alle comunicazioni senza un’adeguata documentazione del contenuto di ciascuno dei canali di comunicazione che attraversano il Condotto (tratterò più ampiamente questo specifico problema in un successivo articolo).

Concludendo questo articolo (non esaustivo del tema), Zone e Condotti rappresentano strumenti analitici utilizzabili per raggruppare dispositivi simili e controllare le comunicazioni tra gruppi, al fine di migliorare la sicurezza e ridurre al minimo l’impatto di un incidente informatico, impedendo a un utente malintenzionato o a un attacker esterno di spostarsi tra i sistemi, quindi osteggiando gli attacchi laterali. Le Zone possono essere utilizzate per identificare ampi gruppi o sottosistemi altamente focalizzati sui requisiti operativi, aziendali e tecnologici specifici di un determinato sistema. Come si può riscontrare nella seguente figura – che mostra come diverse Zone (ideate inizialmente attorno a diversi requisiti) possano sovrapporsi – questa condizione può spesso portare a confusione se Zone e Condotti non sono stati definiti in modo accurato e coerente. Tuttavia, una volta svolto il lavoro di analisi iniziale, i benefici saranno tangibili e inoppugnabili: segmentando i sistemi in Zone ed accertandosi H24 delle comunicazioni interzona utilizzando Condotti controllabili, l’intera infrastruttura industriale sarà resa più sicura.

Caro lettore, sei certo che l’impianto industriale in cui operi sia stato progettato adeguatamente con Zone di sicurezza, Condotti ingegnerizzati e separati con cognizione di causa alla luce di quanto hai appena letto? (e alla luce di quanto puoi approfondire consultando gli standard normativi).

Quali strumenti chi di dovere utilizza per effettuare il monitoraggio dell’ICS? Quanto periodicamente lo verifichi? (o chi di dovere lo verifica). Hai mai provveduto ad effettuare dei test a sorpresa per verificare se quello che ti raccontano in merito ai controlli e al monitraggio corrisponde effettivamente a verità?

…ma soprattutto, la rete dell’ICS in cui lavori e/o presso cui giungono le connessioni dei tuoi clienti e fornitori, è realmente protetta a dovere, preparata adeguatamente per resistere a un eventuale attacco ransomware senza perdere produttività né arrecare danni a chi vi lavora?