La strategia Zero Trust all’interno delle infrastrutture critiche

Negli ultimi anni, il processo accelerato di digitalizzazione ed innovazione e gli ambienti di forza lavoro remota hanno reso le architetture di sicurezza perimetrale della rete fisica tradizionali inefficaci a far fronte agli attacchi dei cyber criminali sempre più abili sia nello sfruttare qualsiasi vulnerabilità tecnica o umana esposta nelle reti aziendali moderne e altamente distribuite sia nel far leva sulla fiducia implicita che invece dovrebbe essere mitigata e gestita.

È qui che entra in gioco l’adozione della strategia di sicurezza estensibile ed olistica Zero Trust (ZT).

La guida di Cloud Security Alliance (CSA) – Guidance ZT for Critical Infrastructures – fornisce strategie pratiche e metodologiche specifiche per implementare lo ZT all’interno degli ambienti OT/ICS delle IC, oltre a fornire una esamina delle differenze intrinseche tra i sistemi IT tradizionali e OT/ICS.

Le infrastrutture critiche e gli ambienti OT/ICS

Le IC costituiscono collettivamente le strutture vitali su cui si basano le civiltà moderne e sono costituite da reti complesse e interconnesse, sempre più connesse ad internet, rendendole suscettibili di cyber attack sempre più sofisticati.

Inoltre, molti ambienti OT e ICS si basano fortemente su sistemi legacy, protocolli specializzati, oltre ad essere spesso sistemi chiusi che non possono essere facilmente “patchati” o aggiornati.

Ancora, molte organizzazioni non dispongono di un inventario accurato delle proprie risorse OT/ICS senza contare che, spesso, sono poco comprese da coloro che hanno il compito di gestirle e proteggerle in modo strutturato efficace ed efficiente.

Infrastrutture critiche e vettori di minacce

I settori IC sono obiettivi primari grazie al loro ruolo vitale nelle comunità e nelle economie ma spesso subiscono attacchi. Di seguito un elenco delle principali cause di attacco a queste infrastrutture evidenziate dalla guida di CSA:

Pressione normativa e di conformità – Il complesso panorama normativo che regola la IC può inavvertitamente creare vulnerabilità. Di fatto, le misure di sicurezza incentrate sulla conformità potrebbero non essere sempre in linea con le pratiche di sicurezza informatica più efficaci, lasciando potenzialmente lacune che gli aggressori possono sfruttare.

Minacce interne – Dipendenti, appaltatori o altre persone, con conoscenze privilegiate e accesso ai sistemi delle IC, rappresentano un rischio, poiché potrebbero, intenzionalmente o per negligenza, eludere le misure di sicurezza, provocando danni o interruzioni significative.

Vulnerabilità della supply chain – Le IC si basano spesso su supply chain complesse e globali per i componenti hardware e software. Di conseguenza, eventuali compromissioni nella supply chain possono introdurre vulnerabilità o elementi dannosi nei sistemi, con il rischio di colpire interi settori senza necessità di intrusioni dirette.

Alto impatto delle interruzioni – L’interruzione o il danneggiamento dell’IC può avere un impatto rilevante sulla sicurezza pubblica, sulla sicurezza nazionale e sull’economia, poiché gli aggressori mirano a generare caos diffuso o a interrompere servizi essenziali.

Interconnessione e interdipendenza dei sistemi – I settori delle IC sono altamente interconnessi e spesso interdipendenti. Ne consegue che un attacco andato a buon fine in un’area può ripercuotersi a cascata su altre aree, sfruttando il movimento laterale o le connessioni interdipendenti, portando a un effetto domino che ne amplifica l’impatto.

Motivazioni economiche – Alcuni attacchi alle IC hanno una motivazione finanziaria, i.e. gli aggressori possono cercare di estorcere denaro a organizzazioni o nazioni minacciando di interrompere i servizi essenziali a meno che non venga pagato un riscatto.

Spionaggio informatico – Gli stati-nazione e i criminali informatici possono prendere di mira le IC per attività di spionaggio, poiché l’accesso non autorizzato a questi sistemi permette loro di raccogliere informazioni sulle capacità, vulnerabilità e risorse strategiche di un Paese.

Motivazioni politiche – Gli attacchi alle IC possono avere motivazioni politiche, mirati a destabilizzare una nazione o a fare pressione sui governi per ottenere concessioni in situazioni di tensione geopolitica, controversie o conflitti ideologici.

Legacy dei sistemi – Molti sistemi di IC impiegano tecnologie legacy che non sono state sviluppate considerando i requisiti di cybersecurity moderni, rendendoli vulnerabili e potenzialmente sfruttabili da parte di aggressori.

Cyber war degli stati-nazione – Le IC possono diventare obiettivi strategici nella cosiddetta guerra cibernetica tra stati-nazione, poiché interrompere le infrastrutture di un avversario offre un vantaggio strategico nei conflitti senza dover ricorrere a mezzi militari tradizionali.

Sicurezza fisica – I sistemi OT/ICS sono bersagli accessibili per i cyber criminali a causa della loro esposizione e spesso limitata sorveglianza, offrendo possibilità di manomissione diretta, spionaggio e sabotaggio, oltre a sfruttare vulnerabilità fisiche. In molti casi, un attacco all’infrastruttura fisica risulta essere il metodo più semplice e ad alto impatto per danneggiare tali sistemi.

Il processo di trasformazione digitale e la maggiore convergenza tra ambienti IT/OT

L’interconnessione crescente di sistemi IT/OT, con livelli di sicurezza variabili, rende complessa l’implementazione di controlli di cybersecurity efficaci. Inoltre, l’espansione di internet, cloud, e IIoT ha inoltre moltiplicato i punti di accesso ai sistemi critici, creando nuovi punti di vulnerabilità.

Le debolezze delle reti tradizionali di supply chain sono aggravate da connessioni sempre più diffuse, che facilitano l’accesso dei cyber criminali dopo un attacco andato a buon fine.

Storicamente, i sistemi OT erano isolati fisicamente (“air gapped”) da altre reti, ma oggi sono spesso interconnessi tramite accesso wireless, cloud e servizi SaaS, mentre i sistemi legacy si interfacciano con dispositivi di manutenzione per aggiornamenti e trasferimenti di dati. Il passaggio da sistemi isolati a reti integrate aumenta il rischio di violazioni, richiedendo controlli di sicurezza adeguati.

Progressi tecnologici – Il passaggio dalle connessioni seriali a quelle Ethernet, l’integrazione di adattatori wireless nei componenti OT e l’interfacciamento con i dispositivi per la manutenzione hanno contribuito a creare un panorama più connesso e potenzialmente maggiormente vulnerabile, dato che questi sistemi, un tempo stabili, sono ora collegati a reti dinamiche e interconnesse, costringendoli a adattarsi a nuovi rischi e sfide.

Interconnettività delle infrastrutture critiche – I confini sempre più sfumati e i sistemi altamente interconnessi rendono i settori delle IC interdipendenti e strettamente accoppiati. Pertanto, ognuna di queste dipendenze intersettoriali coinvolge il flusso di dati tra diverse entità, creando una complessa rete di interconnessioni in cui un attacco a un settore potrebbe potenzialmente innescare interruzioni a cascata in più settori o aziende, amplificando l’impatto ben oltre l’obiettivo iniziale.

Integrazione OT e IT – L’integrazione dei sistemi OT e IT ha subito un’accelerazione, guidata dalla necessità di accesso remoto, monitoraggio e controllo del sistema, oltre che dall’aggregazione, dall’analisi e dalla reportistica dei dati. Ne consegue che l’integrazione e la convergenza, tipiche dell’Industria 4.0 e 5.0, vanno oltre la semplice raccolta dei dati, includendo altresì la comunicazione e il controllo bidirezionali. Inoltre, le notifiche e le risposte alle interruzioni richiedono spesso una perfetta integrazione OT/IT, con i dati provenienti dai sistemi operativi, che alimentano i canali di comunicazione gestiti dall’IT e, sempre più spesso, i dati OT vengono inviati a piattaforme cloud per il monitoraggio e l’analisi avanzati.

Di fatto, i dati fluiscono continuamente tra i sistemi OT (linee di produzione, sensori di trasporto) e i sistemi IT (gestione dell’inventario, pianificazione della logistica), creando un thread digitale che migliora l’efficienza e la tracciabilità.

Tuttavia, questa integrazione introduce anche nuove vulnerabilità dovute all’aumento della connettività e all’offuscamento dei confini tradizionali OT-IT. Pertanto, la sfida consiste nello sfruttare questi vantaggi, mantenendo – al contempo – una solida sicurezza in tutta l’infrastruttura convergente.

In questo contesto, l’adozione di strategia ZT offre un significativo valore aggiunto per accelerare la crescita del business in modo sicuro e, al contempo, proteggere i sistemi, soddisfare i requisiti legali, di conformità, di audit e di difesa dagli attacchi informatici.

È importante sottolineare che lo ZT non si limita alle nuove implementazioni. Se da un lato il successo dell’implementazione di un’architettura ZT (ZT Architecture – ZTA) garantisce naturalmente un approccio “secure-by-design” per i nuovi progetti, dall’altro può anche rafforzare in modo significativo i sistemi esistenti. Pertanto, le organizzazioni – attraverso un’attenta applicazione dei principi ZT – possono ottenere la “sicurezza per retrofit” per quanto riguarda i sistemi legacy e migliorare la loro posizione di sicurezza degli ambienti OT/ICS.

OT vs. IT: obiettivi differenti – Le IC ed i sistemi OT/ICS, su cui si basano, sono per definizione mission-critical. Inoltre, a differenza dei sistemi IT – che sono spesso progettati pensando alla triade CIA (Confidentiality, Integrity, Availability – i.e., riservatezza, integrità e disponibilità) incentrata sulla cybersecurity, i sistemi OT/ICS sono stati progettati principalmente per l’affidabilità e la sicurezza, ponendo meno attenzione alla riservatezza e all’integrità. Tale differenza deriva dal focus operativo degli ambienti OT/ICS, dove mantenere un funzionamento continuo e sicuro è fondamentale e i tempi di inattività possono avere gravi conseguenze.

Resilienza, operatività e sicurezza: obiettivi primari – L’introduzione di strumenti e tecnologie più recenti nei sistemi critici e legacy delle IC richiede un’attenta valutazione e test per garantire che l’implementazione non interferisca con la sicurezza o le operazioni. Di fatto, durante un incidente di cybersecurity, prevenire ulteriori danni e impatti può significare rallentare o mettere offline questi servizi e sistemi essenziali, compromettendone la normale funzionalità, fino, addirittura, paralizzare un intero Paese.

I sistemi delle IC sono statici, complessi e costosi – I sistemi delle IC sono caratterizzati da costi elevati, ciclo di vita prolungato, design articolati e complessi, oltre a richiedere lunghi processi di implementazione. Ciò contribuisce alla loro natura statica, rendendoli meno adattabili alle minacce in evoluzione.

Molti asset operano oltre la durata prevista, superando il ciclo di supporto dei produttori, rendendo la loro sostituzione o aggiornamento un processo complesso e dispendioso, con fasi di progettazione, ingegneria, approvvigionamento e collaudo.

Questo è particolarmente critico per applicazioni dove errori possono influire sulla sicurezza, salute o ambiente. Pertanto, i sistemi obsoleti vengono spesso mantenuti per prolungare la vita dell’infrastruttura, complicando il bilanciamento tra continuità operativa e necessità di aggiornamenti di sicurezza. Inoltre, l’uso di protocolli proprietari nei sistemi OT rende difficili gli aggiornamenti e crea vulnerabilità, aggiungendo complessità alla protezione e modernizzazione degli ambienti OT/ICS.

Differenze nell’architettura e nella tecnologia dell’OT/ICS vs. l’IT – È importante notare che i sistemi OT/ICS, oltre a perseguire obiettivi diversi rispetto agli ambienti IT aziendali, presentano significative differenze in architettura e tecnologie utilizzate. Questa comprensione è fondamentale poiché i dettagli delle politiche di sicurezza e l’applicazione dei controlli possono variare. La guida di CSA utilizza il Modello Purdue come riferimento per visualizzare i componenti e le connessioni in un ambiente OT/ICS. Per un’analisi più approfondita, si rimanda alla guida stessa.

Fonte immagine: CSA Guidance for Critical Infrastructures – Esempio di Modello Purdue.

Da quanto si evince dalla figura sopra riportata, più un asset è vicino al livello di esecuzione del processo (livelli 0 e 1), più proprietari sono i sistemi e i protocolli in uso. Tuttavia, i sistemi coinvolti nel controllo, nell’automazione e nella gestione dei processi (livelli 2 e 3) sono spesso costituiti da sistemi operativi Windows e Linux di vari tipi ed età.

Molti di questi sistemi utilizzano versioni obsolete o modificate dei sistemi operativi, che vengono raramente aggiornate e mantenute secondo processi e cicli differenti rispetto ai tradizionali sistemi IT ed endpoint aziendali.

Inoltre, la diffusione di sistemi legacy va oltre i sistemi operativi e le applicazioni obsoleti; i sistemi OT/ICS comprendono spesso risorse cyber-fisiche con una vita utile che si misura in decenni anziché in anni. Inoltre, molti di questi sistemi mancano di protezioni di base.

Protocolli unici e configurazioni proprietarie – I professionisti IT devono comprendere i protocolli e i rischi specifici di questo ambiente, acquisendo nuove competenze. I dispositivi e le reti OT/ICS, in particolare nei livelli inferiori del modello Purdue, utilizzano una serie di protocolli specifici come Modbus, PROFIBUS, PROFINET, OPC, MQTT, EtherNet/IP, Fieldbus e RS-485.

Sebbene questi protocolli seguano standard di settore, le configurazioni possono variare tra le implementazioni e spesso non sono ben documentate. Ciò rende difficile l’individuazione e la gestione di vulnerabilità e configurazioni errate.

Inoltre, a differenza delle risorse con sistemi operativi standard, molti dispositivi OT/ICS possono avere sistemi operativi personalizzati o addirittura nessun sistema operativo, e le patch sono raramente disponibili. Ancora, poiché i componenti sono progettati per funzioni specifiche, presentano limitazioni in termini di risorse computazionali, funzioni e memoria, riducendo ulteriormente la possibilità di aggiornamenti o di integrazione di nuove misure di sicurezza.

Comunicazione non crittografata – È doveroso evidenziare che molti protocolli utilizzati nei sistemi OT, in particolare nelle zone di controllo locali, non sono crittografati, rendendo i sistemi vulnerabili all’intercettazione di dati sensibili, all’inserimento di comandi falsi e all’interruzione della comunicazione tra sistemi di controllo e dispositivi.

Tali azioni possono comportare un controllo non autorizzato dei processi industriali, causando interruzioni operative, danni alle apparecchiature e rischi per la sicurezza.

Inoltre, secondo un rapporto della CSA, molti di questi protocolli non sono stati progettati per la crittografia. Ne consegue che l’aggiunta della crittografia può introdurre una latenza inaccettabile nei sistemi OT/ICS che richiedono comunicazione in tempo reale.

I ritardi, di fatto, possono influenzare l’esecuzione tempestiva dei comandi e la sincronizzazione dei sistemi, portando a potenziali interruzioni nei processi di controllo. Ciò, in situazioni critiche, potrebbe ritardare o compromettere il funzionamento dei meccanismi di sicurezza, soprattutto in sistemi strettamente coordinati come quelli impiegati nella produzione di energia o nei processi chimici.

Conoscenze e competenze specifiche – L’hardware, l’architettura e le tecnologie multigenerazionali tipiche dell’OT/ICS richiedono una conoscenza più ampia in più aree. Ne consegue che è fondamentale che i membri dei team IT acquisiscano le necessarie competenze, oltre a strutturarsi in team interfunzionali permanenti al fine di garantire una maggiore cybersecurity degli ambienti OT/ICS e colmare il tradizionale divario conoscitivo.

Esposizione fisica di numerosi asset – Molti componenti OT/ICS, a differenza dei sistemi IT tradizionali protetti in data center sicuri, sono installati in ambienti aperti e accessibili, esponendoli a vari rischi, tra cui manomissioni o sabotaggi da parte di malintenzionati, vulnerabilità a catastrofi naturali ed eventi meteorologici estremi, danni accidentali causati da errori umani e raccolta di informazioni tramite osservazione fisica.

Pertanto, la protezione di questi asset richiede un approccio multilivello che combini misure di sicurezza fisica con controlli tecnici. Inoltre, la pianificazione della resilienza deve considerare le minacce sia fisiche che informatiche, implementando una strategia di sicurezza integrata che affronti entrambi gli ambiti contemporaneamente.

Monitoraggio continuo delle esigenze e delle sfide – L’evoluzione del panorama delle minacce richiede un cambiamento nelle pratiche di monitoraggio, in particolare per quanto riguarda il rilevamento di eventi potenzialmente legati a incidenti informatici. Una sfida significativa è rappresentata dalla mancanza di un monitoraggio completo delle attività dannose nei sistemi OT.

Sebbene i dati operativi siano monitorati attentamente, il monitoraggio della sicurezza è spesso in ritardo, portando a danni informatici erroneamente attribuiti a problemi di affidabilità o configurazioni errate, nascondendo così la vera natura e portata degli incidenti di sicurezza. L’introduzione di funzionalità di monitoraggio avanzate richiede nuove connessioni per il monitoraggio della rete, aumentando la superficie di attacco e il rischio di esposizione dei dati.

Pertanto, gli ambienti OT devono adattarsi integrando sistemi moderni per il monitoraggio continuo della sicurezza, senza compromettere l’integrità operativa. Ciò richiede una maggiore interoperabilità tra i sistemi di monitoraggio tradizionali e i moderni strumenti di gestione delle informazioni e degli eventi di sicurezza (Security information and event management – SIEM).

Sfide nella supply chain – La sicurezza della supply chain negli ambienti OT/ICS pone sfide significative, alcune delle quali condivise con il mondo IT, ma spesso amplificate quando si tratta di contesti operativi.

Di fatto, da un lato, l’IT deve affrontare le proprie sfide relative alla sicurezza della supply chain; dall’altro, i fornitori OT tendono a privilegiare gli obiettivi aziendali e le funzionalità operative rispetto alla sicurezza. Questa attenzione può tradursi in una mancanza di misure di sicurezza integrate nella catena di fornitura OT, aumentando le vulnerabilità nei sistemi OT/ICS.

Inoltre, i fornitori del settore OT spesso non hanno processi consolidati per la segnalazione, l’applicazione di patch e la risoluzione di problemi di sicurezza, come le controparti IT.

Le organizzazioni delle IC devono quindi prestare particolare attenzione ai dettagli della loro supply chain OT/ICS, poiché le informazioni e le pratiche di sicurezza possono essere meno accessibili o trasparenti rispetto a quelle del settore IT.

È fondamentale condurre un’analisi approfondita, poiché le vulnerabilità della catena di approvvigionamento in ambienti OT/ICS possono avere impatti significativi sulla sicurezza operativa e sull’infrastruttura critica.

Standard come ISA/IEC 62443 per la sicurezza delle reti di comunicazione industriale evidenziano questa tendenza e specificano i requisiti per la convalida e verifica formale di dispositivi, software e aggiornamenti critici, affrontando anche le vulnerabilità della supply chain. Si consiglia alle organizzazioni di IC di familiarizzare con questi standard per migliorare la sicurezza della propria supply chain, integrandoli in una strategia complessiva di gestione del rischio e in un percorso di ZT.

Il processo di implementazione dello ZT in cinque fasi

La guida CSA fornisce l’implementazione della strategia ZT in cinque fasi. Inoltre, fa riferimento al CISA ZTMM (Cybersecurity and Infrastructure Security Agency ZT Maturity Model) e lo utilizza come modello chiave su cui basare un percorso di ZT in ambienti sia IT sia OT/ICS.

Il CISA ZTMM definisce quattro fasi di maturità – i.e. tradizionale, iniziale, avanzato e ottimale – che hanno lo scopo di facilitare un percorso progressivo verso la sicurezza ZT. Inoltre, il CISA ZTMM si basa su cinque pilastri – i.e. identità, dispositivi, reti, applicazioni & carichi di lavoro e dati.

Ognuno dei quali fornisce dettagli generali relativi alle seguenti funzionalità trasversali: visibilità & analisi, automazione & orchestrazione e governance.

Fonte immagine: CSA Guidance to ZT for Critical Infrastructures.

Processo di implementazione ZT per ambienti OT/ICS

Il processo di implementazione della strategia ZT in cinque fasi è progettato per adattarsi agli ambienti OT/ICS. Ogni fase si fonda su approcci consolidati nella gestione della sicurezza informatica per ambienti OT/ICS e ibridi, seguendo le linee guida del NIST e dell’International Society of Automation (ISA). Vediamo in dettaglio in cosa consistono le cinque fasi.

Fonte immagine: CSA Guidance to ZT for critical Infrastructures – Processo di implementazione.

Fase 1 – Definizione della superficie di protezione per OT/ICS

La guida CSA fa riferimento alla guida generale Defining the Zero Trust Protect Surface per questa fase, evidenziando come la definizione di una ZT Protect Surface implica lo sviluppo di un inventario solido delle risorse del sistema aziendale dell’organizzazione, classificate in base al rischio e alla criticità, nonché al loro attuale livello di maturità della sicurezza.

È doveroso evidenziare che l’inventario delle risorse dell’organizzazione viene utilizzato per dare priorità all’ordine di implementazione della strategia di ZT, oltre a consentire di bilanciare criticità, rischi e misure di sicurezza esistenti.

La guida di CSA sottolinea che l’implementazione della strategia ZT trae vantaggio da un approccio misurato e incrementale, spesso definito come “crawl, walk, run“, particolarmente utile negli ambienti OT/ICS dove le conseguenze delle interruzioni possono essere gravi. Tale approccio incoraggia il progresso attraverso iterazioni iniziali a basso rischio, permettendo alle organizzazioni di migliorare la sicurezza senza sovraccaricare le risorse o interrompere operazioni critiche.

Si raccomanda alle organizzazioni di iniziare identificando una superficie di protezione semplice e a basso rischio, il “crawl”, per consentire ai team di acquisire esperienza pratica e completare tutte e cinque le fasi del processo di implementazione di ZT in un ambiente controllato e non critico.

Con l’aumento di fiducia e competenze, le organizzazioni possono passare al “walk”, seguendo la pratica Protect Surfaces. Infine, si arriva al “run”, affrontando i sistemi più critici o complessi, spesso definiti “i gioielli della corona”.

Fonte immagine: CSA guida ZT per le infrastrutture critiche.

La curva di apprendimento dello Zero Trust: implementare lo Zero Trust un passo alla volta

Si tratta di adottare un approccio strategico e graduale che consente di padroneggiare progressivamente il processo di implementazione della strategia ZT, aumentando competenza e fiducia, e garantendo l’efficacia e la continuità quando applicato ai sistemi mission-critical.

Man mano che l’IC avanza nel processo può estendere i principi ZT ai sistemi secondari e terziari, fino a raggiungere un’architettura ZT completa a livello aziendale.

Inoltre, CSA consiglia di sfruttare gli strumenti e le capacità esistenti prima di investire in nuove tecnologie ZT, per raccogliere informazioni utili su esigenze specifiche, requisiti architetturali e punti di integrazione. Tale approccio consente di prendere decisioni più informate, assicurando che gli investimenti futuri si allineino con i requisiti ZT e l’infrastruttura già presente.

Proteggere le superfici OT/ICS –È necessario, per definire la ZT Protect Surface, identificare la relazione di ciascun asset con i processi aziendali e il loro valore. In generale, si tratta di proteggere dati, applicazioni, risorse e servizi, noti come elementi DAAS ((Data, Applications, Assets and Services). Negli ambienti OT/ICS, le superfici di protezione includono sia risorse digitali sia fisiche, riflettendo la loro natura cyber-fisica.

Un approccio efficace consiste nel partire da una visione ampia, analizzando i sistemi informativi aziendali e i sistemi operativi e suddividerli in sottosistemi e singoli elementi DAAS. Tale gerarchia si adatta alla complessità degli ambienti OT/ICS, che sono costituiti da “sistemi di sistemi”.

Di fatto, ogni livello della gerarchia può fungere da superficie di protezione autonoma, a seconda delle esigenze e della complessità dell’organizzazione. L’obiettivo è identificare la superficie di protezione più granulare per implementare controlli e politiche con privilegi minimi.

ISA/IEC 62443 – Modello a “zone” e “condotti” – I settori delle IC hanno ciascuno le proprie linee guida e normative di cybersecurity di riferimento per la classificazione, la segmentazione e la gestione del rischio dei dati.

In particolare, l’International Society of Automation (ISA) offre una serie di standard per OT/ICS tra cui l’ISA/IEC 62443 che fornisce un insieme di termini comuni e requisiti che possono essere utilizzati dai proprietari di asset, dai fornitori di prodotti e dai fornitori di servizi per proteggere la sicurezza dei propri Security of Industrial Automation and Control Systems (IACS).

La serie di standard ISA/IEC 62443 contiene sia una guida normativa (attività richieste) sia una guida informativa (how-to) per la protezione OT/ICS per i proprietari di sistemi, gli operatori di sistema, i professionisti del rischio e i produttori. Inoltre, fornisce un’architettura di riferimento basata sul modello Purdue e fa riferimento ai concetti di zone e di condotti da utilizzare per la segmentazione e il controllo degli accessi.

Dalla guida di CSA si evince che le IC, che hanno già implementato il modello di zona e di condotti, possono utilizzare queste zone come punto di partenza per la definizione delle superfici protette. Inoltre, ogni zona, o sottosistema, può essere ulteriormente suddivisa in elementi DAAS secondo necessità. Si rimanda alla guida CSA per il dettaglio di questi elementi.

La guida di CSA fornisce, altresì, esempi di protezione delle superfici all’interno di OT/ICS, tra cui:

Fonte: CSA Guidance ZT for Critical Infrastructures (traduzione in italiano).

È doveroso evidenziare che gli elementi DAAS cambiano costantemente man mano che vengono sviluppate nuove tecnologie e quelle vecchie diventano obsolete. Pertanto, è importante che i proprietari e gli operatori OT/ICS valutino regolarmente le loro superfici di protezione per assicurarsi che siano ancora allineate con le loro risorse critiche.

Elementi DAAS vs. i 5 pilastri CISA ZTMM – Essi hanno scopi distinti nel processo di implementazione della strategia ZT.

Gli elementi DAAS costituiscono un inventario delle risorse che le organizzazioni intendono proteggere, contribuendo a definire le superfici di protezione e fornendo una visione completa di ciò che deve essere tutelato.

Invece, i 5 pilastri CISA ZTMM offrono un framework per l’implementazione e la maturazione delle funzionalità ZT, permettendo una valutazione strutturata del livello di maturità ZT dell’organizzazione.

Di conseguenza, le organizzazioni possono:

• Definire efficacemente le superfici di protezione basate su un inventario completo delle risorse critiche (elementi DAAS), organizzate in sottosistemi o zone.
• Utilizzare il framework ZTMM per dare priorità all’implementazione e alla maturazione delle funzionalità ZT in tutti gli aspetti rilevanti dell’infrastruttura, identificando e documentando le dipendenze.
• Dare priorità agli sforzi per migliorare gradualmente la loro postura ZT, assicurando adeguata protezione per tutti gli aspetti dell’infrastruttura, sia digitale sia fisica.

È consigliabile mantenere un inventario dinamico e in tempo reale degli asset, utilizzando soluzioni in grado di monitorare l’inventario in modo continuo. Queste soluzioni dovrebbero essere capaci di aggiornare automaticamente i dati in un sistema e/o inviare avvisi in caso di modifiche. Inoltre, è utile monitorare il traffico e interrogare i dispositivi tramite protocolli specifici per l’OT.

Importanza della raccolta dei metadati – La raccolta dei metadati per ogni superficie protetta è essenziale durante tutto il processo di implementazione della strategia ZT, considerando che forniscono dettagli come tipi di dati, protocolli e criticità del sistema.

Man mano che si procede in ogni passaggio – dalla mappatura dei flussi alla progettazione dell’architettura e alla creazione di policy – i metadati si evolvono e si espandono continuamente. Inoltre, ogni fase si basa sui metadati raccolti nella fase precedente, fornendo informazioni sempre più dettagliate che consentono misure di sicurezza più precise e mirate. In definitiva, questo crescente corpus di metadati guida lo sviluppo di una policy ZT su misura e basata sulle esigenze e sulle caratteristiche specifiche di ciascuna superficie protetta.

Fase 2 – Mappatura dei flussi operativi per ambienti OT/ICS

È essenziale comprendere il funzionamento del sistema mappando i flussi di informazioni verso, da e all’interno della superficie protetta, nonché le interazioni tra gli elementi DAAS e altre risorse. Questa comprensione aiuta a posizionare i controlli adeguati e a prendere decisioni informate riguardo alla sicurezza, alle policy di accesso e all’allocazione delle risorse.

A differenza dei sistemi IT, i sistemi OT richiedono un approccio di mappatura che consideri le loro peculiarità fisiche e operative. Ogni punto di connessione dovrebbe essere trattato come non attendibile fino a verifica, seguendo i principi dello ZT per prevenire il movimento laterale delle minacce, un aspetto critico negli ambienti OT/ICS.

È importante avere familiarità con i linguaggi dei controlli logici programmabili (Programmable Logic Controller – PLC), i flussi dei sistemi di controllo di supervisione e acquisizione dati (Supervisory Control and Data Acquisition – SCADA) e l’architettura dei sistemi di controllo distribuito (Distributed Control System – DCS).

Un inventario completo delle risorse permette di documentare chiaramente le dipendenze, le interconnessioni e le relazioni di accesso, facilitando lo sviluppo di mappe di flusso operative e l’individuazione di potenziali vulnerabilità. Il processo di mappatura può rivelare asset o connessioni trascurati, arricchendo l’inventario iniziale con nuove informazioni e potenzialmente portando a modifiche nelle superfici di protezione e nelle relative priorità.

Convergenza OT/IT e mappatura dei flussi operativi – Il rapido processo di trasformazione digitale in corso ha accelerato la convergenza tra i sistemi OT e IT, rendendo la mappatura dei flussi operativi ancora più fondamentale. Tale mappatura richiede l’integrazione di connessioni tradizionali e moderne, insieme alla gestione di un ecosistema misto di protocolli e tecnologie.

È essenziale garantire la continuità dei percorsi dei dati tra gli asset e le connessioni di rete esistenti, soprattutto quando queste si espandono o vengono modificate in risposta alla trasformazione digitale, per assicurare una maggiore visibilità e, di conseguenza, una sicurezza potenziata.

Suggerimenti per la mappatura dei flussi operativi in OT/ICS – La guida di CSA consiglia di considerare strumenti come Dragos Platform26, Claroty27, Nozomi Networks28 e Armis Centrix29 che offrono il rilevamento dinamico degli asset. Inoltre, alcuni di essi includono la mappatura dinamica del flusso operativo, accelerando potenzialmente le prime due fasi critiche del processo di implementazione di ZT.

Ancora, molti fornitori di firewall compatibili con il protocollo OT offrono funzionalità di visibilità simili, con alcuni in grado di contrassegnare automaticamente le etichette (metadati) o integrare metadati di terze parti per la creazione dinamica di policy.

Si consiglia, altresì, dove è possibile, di utilizzare strumenti automatizzati per il monitoraggio continuo della rete ed assicurarsi che le modifiche alla rete vengano rapidamente riconosciute, documentate e convalidate.

Inoltre, negli ambienti OT in cui l’implementazione del software è limitata, risulta quanto mai opportuno considerare approcci alternativi “basati sui sistemi” di sicurezza e di gestione dei rischi, quali ad esempio la metodologia Consequence-driven Cyber-Informed Engineering (CCE) sviluppata dallo sviluppato dall’Idaho National Laboratory e che offre informazioni preziose per scenari in cui le soluzioni software tradizionali non sono applicabili. Si rimanda alla guida di CSA per ulteriori dettagli.

Documentazione dei flussi – Si tratta di definire i requisiti di documentazione, di incorporarli nei processi di gestione delle modifiche e includere sia gli aggiornamenti dell’inventario delle risorse sia i disegni di rete e i backup, nonché la verifica dei flussi di transazione aggiornati. Inoltre, è importante conoscere le interdipendenze per sviluppare controlli ed ambienti personalizzati per ogni superfice di protezione e, al contempo, creare le basi per una sicurezza resiliente che si adatti ai rischi emergenti, garantendo al contempo la continuità dei processi industriali mediante l’allineamento delle misure di protezione all’interno dell’ambiente OT/ICS.

Fase 3 – Creazione di una ZTA in ambienti OT/ICS

Si tratta, in questa fase, di pianificare e progettare una ZTA sulla base delle informazioni raccolte nelle prime due fasi.

La guida di CSA per questa fase fa riferimento sia ai livelli del modello Purdue (i.e. livelli 0-5) sia ai livelli del modello OSI (i.e. livelli 1-7), ovvero, un framework concettuale utilizzato per descrivere le funzioni di un sistema di rete. Fare riferimento alla guida di CSA per maggiori approfondimenti.

Se da un lato il modello Purdue aiuta a comprendere la struttura gerarchica dei sistemi di controllo industriale, dall’altro lato il modello OSI viene utilizzato per descrivere il modo in cui i dati vengono trasferiti tra i componenti all’interno di tale struttura, indipendentemente dal loro livello nella gerarchia Purdue.

Segmentazione e punti di applicazione Zero Trust – Dal punto di vista operativo, la segmentazione tra le reti IT e OT e la segmentazione all’interno della rete OT sono diverse dalla segmentazione IT aziendale sia nell’architettura sia nell’implementazione. Nelle reti IT potremmo avere un insieme centrale di firewall e regole per consentire l’accesso attraverso diverse reti e dispositivi.

Mentre, in una rete OT, idealmente, non dovrebbe esserci un singolo percorso che attraversa più di un hop all’interno dei livelli del modello Purdue. Ad esempio, non è possibile progettare una VPN o un percorso di accesso dalla rete IT aziendale o da internet (modello Purdue livello 5) direttamente ad un’interfaccia HMI (modello Purdue livello 2 o 3). Invece, ci sarebbe un hop (o condotto) dalla rete IT aziendale (modello Purdue livello 4) alla IT/OT DMZ (modello Purdue livello 3.5) e quindi un hop separato (condotto) nella gestione OT/ICS (modello Purdue livello 2 o 3).

Fonte immagine CSA Guidance TO ZT for Critical Infrastructures.

Hop multipli del modello Purdue

Punti di applicazione delle politiche di pianificazione (Policy Enforcement Points – PEP) in OT/ICS – Durante la progettazione di una ZTA, è fondamentale considerare l’importanza della facilità di funzionamento e manutenzione, nonché della flessibilità per adattarsi all’evoluzione della rete e dei requisiti aziendali.

Altrettanto cruciale è garantire la ridondanza sia nei piani di controllo sia in quelli dei dati – che comprende i punti di applicazione delle politiche (Policy Enforcement Points – PEP) e i punti decisionali delle politiche (Policy Decisions Points – PDP) – come descritto nella di NIST SP 800-207. Tale ridondanza elimina i singoli punti di guasto, salvaguardando così la disponibilità e la sicurezza dei sistemi critici.

Si tratta di un approccio completo che garantisce un framework ZT resiliente e adattabile, proteggendo la IC con efficienza, agilità e garantendone il funzionamento ininterrotto.

Posizionamento del PEP – L’obiettivo è posizionare il PEP il più vicino possibile al bene da proteggere. Questa implementazione è preferibile sia per la rete IT aziendale (modello Purdue, livelli 4 e superiori) sia per le aree della DMZ (Demilitarized Zone) che separano le reti IT e OT (intorno al livello 3.5 del modello Purdue).

Inoltre, è indicata anche per la rete di controllo e di elaborazione, in cui si trovano i server applicativi OT/ICS, i database, gli storici dei dati, le workstation di ingegneria e gli HMI (livelli 2 e 3 del modello Purdue).

La parte più bassa del modello Purdue (livelli 0 e 1), che si avvicina ai dispositivi di campo, include spesso sistemi operativi, PLC e altre risorse legacy che non supportano un client software.

In tali situazioni, potrebbe essere necessario aggiornare l’infrastruttura per applicare le politiche al livello 7 (livello dell’applicazione) oppure implementare soluzioni basate sulla rete al livello 2 (livello di collegamento dati) o al livello 3 (livello di rete) del modello OSI. Questo aggiornamento potrebbe richiedere l’aggiunta di funzionalità come l’installazione di un router di rete in grado di supportare i criteri di livello 7 per applicare misure di sicurezza in contesti dove i client software tradizionali non sono praticabili.

Ecco alcuni suggerimenti per la pianificazione dei punti di applicazione in ambienti OT/ICS:

• Utilizzare qualsiasi documentazione esistente, quali: diagrammi ISA/IEC 62443, valutazione dei rischi, pianificazioni di zone e condotti, nonché prove o report derivanti da audit di conformità.
• Se l’asset supporta un agente o un client software, considerarlo come punto di applicazione delle politiche (i.e., soluzioni Zero Trust Network Access – ZTNA, gestione degli accessi privilegiati, ecc.).
• Se l’asset non può supportare nativamente un agente o un client software, è consigliabile aggiornare l’asset per installare il software necessario oppure aggiungere un gateway di applicazione, sia basato su software che su hardware, davanti all’asset protetto.
• Se l’asset non può supportare un agente o un client software, valutare diversi livelli di segmentazione, quali: segmentazione di livello 3-7 con firewall OT/ICS adeguati; segmentazione di livello 3-7 con soluzioni di rete virtualizzate come SDN o VRF; segmentazione di livello 2-4 con router o switch di routing adatti per OT/ICS; segmentazione di livello 2-3 con gateway di micro-segmentazione LAN progettati specificamente; segmentazione di livello 1-2 con gateway unidirezionali.

Fase 4 – Creazione della policy ZT in ambienti OT/ICS

La creazione della policy ZT prevede il controllo degli accessi, pianificato e progettato nella Fase 3 durante la definizione della ZTA. La policy stabilisce le autorizzazioni di accesso e prevede revisioni regolari dei diritti, consentendo agli utenti di accedere solo alle risorse e alle funzioni critiche necessarie per le loro attività. Ciò riduce al minimo i potenziali vettori di attacco e gli accessi non autorizzati.

Inoltre, è importante sottolineare che l’implementazione della strategia ZT negli ambienti OT/ICS richiede un delicato equilibrio tra misure di sicurezza rigorose e la necessità di mantenere operazioni sicure e ininterrotte, soddisfacendo al contempo le esigenze operative e i requisiti di sicurezza specifici degli ambienti industriali, diversamente dalle implementazioni ZT focalizzate sull’IT.

Obiettivi della policy ZT

Per garantire una gestione semplificata delle applicazioni, focalizzandosi sull’uso di quelle essenziali a supporto delle operazioni dell’IC. Inoltre, è importante prestare attenzione alla sicurezza mirata, autorizzando solo le operazioni strettamente necessarie per scopi aziendali legittimi. Per sviluppare un criterio ZT, è necessario intraprendere specifiche azioni. Vediamo di seguito quali sono.

Autenticazione delle identità dell’utente e del dispositivo nei punti chiave delle transazioni negli ambienti OT/ICS – Si tratta di bilanciare una rigorosa verifica dell’identità con l’esigenza di garantire un accesso tempestivo ai sistemi critici, tenendo conto dell’impatto potenziale degli errori di autenticazione sulla continuità operativa e sulla sicurezza.

Inoltre, è importante posizionare strategicamente i punti di applicazione per minimizzare i rischi operativi e massimizzare i benefici in termini di sicurezza. Infine, è fondamentale implementare un monitoraggio costante della postura dei dispositivi, del comportamento degli utenti e delle applicazioni, per facilitare l’identificazione rapida di eventi di sicurezza, inclusi tentativi di accesso non autorizzato.

Regole dei criteri di sicurezza – Sono stabilite regole di sicurezza tenendo presente i requisiti dell’IC in termini di: segmentazione della rete; principio del privilegio minimo; ispezione e registrazione del traffico.

Rispetto degli standard di sicurezza – Le regole della policy di sicurezza sono conformi agli standard di sicurezza specifici dei settori di appartenenza delle singole IC.

Monitoraggio degli utenti – È importante sottolineare che il monitoraggio degli utenti nelle IC varia in base alle funzionalità del sistema. Gli utenti, in sistemi che supportano la responsabilità individuale – come i computer Windows – sono monitorati e tracciati in modo continuo, garantendo una sicurezza coerente. Tuttavia, molti sistemi OT non supportano tecnologie di gestione degli utenti tradizionali, pertanto si raccomandano strategie alternative di monitoraggio, quali:

• Utilizzare strumenti di gestione della configurazione per rilevare modifiche al sistema, anche se non attribuibili a singoli.
• Implementare account di gruppo, quando non è possibile utilizzare account individuali, e modificare sempre le impostazioni delle password predefinite.
• Applicare controlli di accesso fisici per limitare e monitorare l’accesso al sistema.
• Installare telecamere in aree dove non sono possibili altre forme di monitoraggio.

Queste misure consentono di bilanciare la responsabilità con i limiti tecnici degli ambienti OT, mantenendo la sicurezza e la vigilanza tra i diversi sistemi.

Regole dei criteri di decrittografia – Le regole dei criteri di decrittografia garantiscono la visibilità del traffico delle applicazioni, oltre a consentire alle regole dei criteri di sicurezza di ispezionare e di identificare in modo efficace le potenziali minacce all’interno del traffico.

Policy ZT – Limiti di sicurezza specifici per gli asset – È fondamentale notare che, mentre la micro-segmentazione controlla efficacemente il traffico di rete tramite suddivisioni granulari, i limiti di sicurezza specifici per gli asset si concentrano sull’applicazione di controlli di sicurezza direttamente adiacenti agli asset critici delle IC.

Tale approccio consente di applicare i principi di ZT– sia fisicamente sia logicamente – a ciascuna superficie di protezione, garantendo controlli personalizzati e precisi, oltre a ridurre la superficie di attacco interna e a aderire al principio del privilegio minimo attraverso rigorosi controlli di accesso.

Le regole delle policy ZT stabiliscono limiti di sicurezza specifici che assicurano un controllo dettagliato su chi o cosa può interagire con ogni asset, in quali condizioni e quando, mantenendo così la continuità operativa e la sicurezza degli ambienti OT/ICS, che è cruciale nelle IC.

Inoltre, le IC – implementando sia la micro-segmentazione sia i limiti di sicurezza specifici per gli asset – possono sviluppare una solida strategia di difesa, proteggendo il traffico di rete e rafforzando gli asset fisici, oltre a migliorare la reattività e la resilienza delle operazioni.

Il metodo Kipling per la creazione di politiche – La guida di CSA evidenzia che le politiche ZT possono essere create utilizzando il Metodo Kipling che affronta gli aspetti chi (identità dichiarata), cosa (applicazione), quando (tempi-cronometraggio), dove (destinazione), perché (scopo) e come (metodo d’accesso)” della rete e delle sue politiche.

Di fatto, l’utilizzo del metodo Kipling per la creazione di policy consente un’applicazione granulare, garantendo che solo il traffico noto e autorizzato e la comunicazione legittima delle applicazioni siano consentiti all’interno della rete delle IC, riducendo sostanzialmente sia la superficie di attacco sia la dipendenza dalle tradizionali regole del firewall basate sulle porte.

Si consiglia di consultare la sezione dedicata della guida di CSA per ulteriori spunti di attuazione.

Fase 5 – Attività di monitoraggio e manutenzione continuative in ambienti OT/ICS

Il monitoraggio e l’analisi continui sono fondamentali per rilevare e per rispondere rapidamente a qualsiasi potenziale minaccia nei confronti delle IC, senza dimenticare l’importanza di svolgere valutazioni periodiche della sicurezza e test di penetrazione per identificare e affrontare le vulnerabilità in modo proattivo.

Inoltre, la guida di CSA ribadisce che il programma ZT in un ambiente OT/ICS dovrebbe includere quanto segue:

• Piano di Incident Response OT/ICS (IR OT/ICS) garantendone l’integrazione con il piano IR IT aziendale per un approccio olistico.
• Visibilità delle reti OT/ICS, quale elemento chiave per una ZTA, assicurandosi di: aver identificato le risorse, i percorsi dei dati che devono essere monitorati; disporre di un piano per la raccolta dei dati appropriati e l’invio al repository appropriato.
• Strumenti compatibili con OT/ICS, dato che questi ambienti comunicano con protocolli specifici per l’ambiente OT/ICS e gli strumenti IT aziendali tradizionali potrebbero non essere adatti o addirittura “consapevoli” di questo traffico.
• Gestione delle vulnerabilità in OT/ICS attraverso le politiche ZT dato che -se implementate correttamente – permettono non solo di gestire le patch, ma anche includere la valutazione contestuale delle vulnerabilità mediante la visibilità e le attività di monitoraggio e altri controlli di mitigazione.

Evoluzione della ZTA e azioni necessarie di aggiornamento e modifiche – L’evoluzione della ZTA di una IC implica necessariamente adeguare le misure di sicurezza informatica e/o mantenere la conformità alle leggi e alle normative del settore. Ne consegue che saranno necessari aggiornamenti periodici, almeno su base annuale e – se i sistemi e l’automazione lo consentono – ogni 90 giorni oppure, in modo ottimale, su base continua.

Pertanto, tutta la documentazione dovrà essere rivista e aggiornata nell’ambito della gestione del cambiamento, riavviando il processo dall’inizio e ripercorrendo tutte le fasi ogni qual volta siano sostituiti gli asset o variati requisiti di accesso. Inoltre, anche la ZTA e politiche ZT dovranno essere aggiornate o modificate.

Si consiglia, altresì, di rivalutare periodicamente i fornitori e gli strumenti di sicurezza, richiedendo aggiornamenti per comprendere le nuove funzionalità e ricevere le integrazioni disponibili. Senza dimenticare i piani di risposta agli incidenti, gli strumenti di monitoraggio, l’analisi e la gestione delle vulnerabilità che dovrebbero far parte delle attività di valutazione e miglioramento continuo.

Conclusione

Le IC affrontano un panorama in continua evoluzione di minacce sia informatiche sia fisiche. Inoltre, l’adozione della trasformazione digitale e la progressiva convergenza tra gli ambienti IT e OT, richiedono sempre più strategie di sicurezza flessibili e robuste. Il modello ZT può, di fatto, rappresentare un approccio efficace per proteggere questi sistemi critici da avversari sempre più sofisticati, in grado di sfruttare i rapidi avanzamenti tecnologici e le mutevoli dinamiche delle minacce.

La guida della CSA si rivela uno strumento prezioso, fornendo numerosi spunti su come implementare con successo e in modo integrato il modello ZT nelle IC. Affinché le IC possano trarre il massimo vantaggio dal modello ZT, è fondamentale promuovere una comunicazione aperta, una visione condivisa e un impegno verso la sicurezza a tutti i livelli.

Tale approccio non solo garantirà la continuità operativa, ma contribuirà anche a rafforzare la resilienza collettiva della comunità globale, migliorando la sicurezza, l’affidabilità e la solidità dei servizi essenziali per il benessere fisico ed economico della nostra società.