Le tre principali forme di pregiudizio che alimentano costantemente lo scollamento tra l’universo dell’IT e quello dell’OT sono riconducibili a tre categorie: bias di filosofia, bias di progetto e bias tecnologico.
- I bias filosofici riguardano le prospettive d’insieme sulla funzione della tecnologia operativa.
- I bias progettuali sono inerenti agli impedimenti fisici e psicologici che frenano il progresso.
- I bias tecnologici vertono sulla selezione degli strumenti più adatti per i progetti definiti in ambito OT, considerando il supporto, il budget e il punto di vista della divisione dell’OT.
Questo post esaminerà i tre bias tra i team IT e OT e discuterà dei modi in cui entrambi i team possono superarli.
I bias filosofici
Di seguito sono riportati tre punti importanti da considerare in merito ai “bias filosofici”. Questi punti mettono in luce le divergenze di fondo nella visione dell’IT e dell’OT e chiariscono perché alcuni aspetti cruciali dell’OT possano sfuggire all’attenzione o essere mal interpretati.
La Tecnologia Operativa: un aspetto spesso tralasciato nelle analisi di settore
Quando le divisioni IT cercano consulenza e informazioni, fanno solitamente affidamento su fonti di analisi IT convenzionali. Queste società d’analisi dedicano tempo, risorse e sforzi considerevoli all’esame di una vasta gamma di strumenti prettamente informatici. È fondamentale sottolineare, però, che tali valutazioni sono effettuate da specialisti dell’IT, principalmente per finalità IT e in contesti prettamente IT. Ne consegue che, nella scelta di una tecnologia e nell’adeguarla ai componenti di un ambiente OT, può emergere un notevole disallineamento tra le strategie IT e quelle OT.
Detto altrimenti, gli strumenti informatici non sempre si integrano perfettamente negli ambienti OT, quantomeno non secondo l’uso per cui sono originariamente concepiti negli scenari IT tradizionali.
Un caso emblematico di tale scollamento IT nei sistemi di rete OT è quello di uno strumento per la sicurezza IT che privilegia l’aggiornamento continuo tramite patch. Benché ciò aiuti a proteggere dalle vulnerabilità, impone riavvii continui. L’impiego di tale strumento in un contesto OT potrebbe rivelarsi nefasto, soprattutto se applicato a un sistema di controllo di un’industria manifatturiera o di una centrale elettrica. I riavvii imposti possono interrompere processi nevralgici, causando blocchi operativi o pericoli per l’incolumità. Per questo motivo è cruciale valutare le realtà operative e le limitazioni proprie dell’ambiente OT, prima di proporre qualsiasi soluzione.
I sistemi di rete OT non sono uniformi
Frequentemente, le squadre IT ricorrono a consulenze esterne e a strumenti unificati per amministrare un vasto numero di sistemi analoghi e sostanzialmente identici. Tale metodologia permette una gestione efficace di centinaia o persino migliaia di asset tramite un’unica piattaforma di strumenti o un team di dimensioni ridotte, centralizzato o delocalizzato.
Nel mondo dell’OT, tuttavia, il contesto è diverso. Nonostante la presenza di molti asset dall’apparenza IT, questi si presentano in molteplici configurazioni, utilizzano software eterogenei, possiedono personalizzazioni specifiche e possono avere necessità particolari. Tale eterogeneità conduce frequentemente a scenari dove uno strumento scelto per una specifica generazione o un particolare profilo di sistema operativo, può non risultare idoneo per ogni tipologia di asset nel dominio OT. Di conseguenza, ogni scelta strumentale che si limiti a soddisfare un sottoinsieme degli asset non potrà mai garantire una copertura globale, completa.
Sebbene soluzioni come i System Center Configuration Manager (SCCM) siano ideali per l’installazione e la messa in sicurezza centralizzata di tutti i computer all’interno di un’azienda in ambito IT, non sono strutturate per gestire le peculiarità di oltre un migliaio di asset operativi basati su Linux o Unix, comuni nei contesti operativi.
Nella sicurezza dell’OT, è fondamentale privilegiare le basi anziché la complessità
Quante volte avete letto analisi da cui emerge che l’aspetto operativo di un’organizzazione difetta di elementi cardine come il controllo perimetrale, una soluzione SIEM (Security Information and Event Management) o la supervisione da parte di un SOC (Security Operations Center)? Pur essendo aspetti di sicura importanza per un programma di sicurezza robusto, la criticità sta nel fatto che l’allerta o il monitoraggio spesso intervengono solo a posteriori, dopo l’accaduto. Ciò che per anni è stato omesso o sottovalutato in molti scenari dell’OT sono i cardini elementari della sicurezza, come l’installazione di patch, le copie di sicurezza, il rafforzamento strutturale dei sistemi (system hardening) e l’applicazione del principio dei privilegi minimi.
Se si vuole ottenere un’effettiva ottimizzazione della sicurezza dell’OT, è mandatorio cominciare proprio da queste misure fondanti.
Bias progettuali
Esaminiamo qui di seguito le problematiche specifiche dei “bias progettuali”, che scaturiscono dalla stretta integrazione della tecnologia operativa con i suoi componenti fissi. Questi spunti illustrano i motivi per cui la gestione dei progetti nell’ambito OT si discosti notevolmente dai tipici progetti dell’IT e i complessi fattori che possono indurre a sottovalutare o mal interpretare elementi dell’OT.
L’OT e il vincolo degli asset inamovibili
È risaputo che i sistemi OT frequentemente si basano su hardware e sistemi operativi non più recenti e privi di manutenzione da parte dei fornitori, rendendo di fatto impraticabile un diretto aggiornamento a Windows 10. Questi sistemi, spesso legacy, impiegano software specifici e protocolli di comunicazione indispensabili per garantire l’esercizio in sicurezza degli impianti. Se il produttore non mette a disposizione una soluzione d’aggiornamento, o se mancano all’appello il budget e i fermi macchina necessari per gli upgrade software, i collaudi, la stesura della documentazione e il ritorno a regime, l’upgrade dell’asset stesso diventa irrealistico. In determinate circostanze, questi asset gestiscono segmenti cruciali dell’intero processo operativo. L’upgrade di un Sistema di Controllo Distribuito (Distributed Control System, DCS) o di un sistema SCADA (Supervisory Control and Data Acquisition) esige tempi e risorse finanziarie considerevoli, il che si traduce in estesi periodi d’interruzione della produzione. Al momento di pianificare un upgrade OT o di richiederne uno per un sistema, è cruciale afferrare che non si tratta di un’operazione scontata o fine a sé stessa, come il semplice aggiornamento di un sistema operativo: le implicazioni in gioco sono infatti ben più vaste.
Per i sistemi di Tecnologia Operativa servono servizi e supporto specifici dell’OT
Rendere sicuri gli ambienti OT implica affrontare due tipi di sfide e priorità in conflitto, originate da 1) i team IT e 2) i costruttori di apparecchiature originali (OEM).
Coordinare l’impegno dei team dell’IT e dell’OT
Le squadre OT procedono con cautela per quanto concerne gli accessi non autorizzati e l’introduzione di modifiche alle loro infrastrutture strategiche. Le iniziative IT come gli aggiornamenti software o le nuove implementazioni tecnologiche amplificano ulteriormente queste preoccupazioni.
La conclusione: le squadre OT devono sentirsi a proprio agio con l’eventualità che chiunque, all’interno del loro ambiente, possa accedere o intervenire sui loro asset. Le divergenze di vedute tra i team dell’IT e quelli dell’OT evidenziano l’importanza fondamentale di creare un rapporto fiduciario tra i due gruppi. Costruire tale fiducia è un processo lungo che esige una comunicazione continua, ma è un fattore determinante per la corretta implementazione e manutenzione degli strumenti di sicurezza nell’ecosistema OT.
Gestione delle relazioni con i fornitori OEM
I fornitori OEM (Original Equipment Manufacturer) costituiscono un’ulteriore centro d’influenza in tema di sicurezza. Spesso questi ultimi tentennano quando i team dell’OT propongono di implementare soluzioni di sicurezza, preoccupati di come tali variazioni possano ripercuotersi sull’assistenza ai loro sistemi critici. Questa esitazione si manifesta in due modi:
- Dipendenza dal fornitore: i team OT dipendono dall’OEM per l’assistenza operativa e spesso cedono di fronte alle obiezioni del fornitore, anche quando si tratta di cambiamenti necessari per la sicurezza.
- Vincoli contrattuali: un fornitore OEM può far valere i termini contrattuali come scudo per precludere ai team dell’OT l’installazione di strumenti di sicurezza che non siano stati preventivamente testati o approvati dal fornitore stesso.
In ambedue le situazioni, la comprensione del ruolo dei vendor OEM nelle operazioni di stabilimento rappresenta una notevole difficoltà in ambito OT, un campo dove i team dell’IT possono essere carenti d’esperienza. Prima di apportare qualsiasi aggiornamento all’OT, è fondamentale capire i rapporti in essere tra il team dell’OT e i fornitori OEM.
È necessario distinguere il budget dell’IT da quello dell’OT
Di frequente, CISO o figure apicali dell’IT tentennano nell’approvare piani di sicurezza destinati all’OT poiché sottostimano il numero effettivo di beni strumentali presenti nell’ambiente OT. In stabilimenti di grandi dimensioni o in realtà aziendali d’interesse globale, il numero di asset può raggiungere le decine di migliaia, superando talora anche quello degli asset informatici. Nel momento in cui un progetto per l’OT sollecita finanziamenti importanti per potenziare la sicurezza degli stabilimenti, si scontra con una certa opposizione. Si può arrivare alla richiesta di ridimensionare il progetto o di programmarne l’esecuzione per fasi, e il personale operativo, già al limite, potrebbe vedersi assegnare i compiti d’implementazione e manutenzione per tagliare i costi. Purtroppo, questo di frequente si traduce in progetti mai portati a termine del tutto o gestiti in modo inadeguato. Numerosi contesti dell’OT accusano ritardi di mesi, se non anni, nell’adozione delle pratiche basilari di sicurezza, e l’investimento iniziale richiesto per implementare la tecnologia e rendere sicuri gli asset comporta un onere finanziario immediato di notevole entità.
Bias tecnologici
Le tre analisi che seguono illustrano più chiaramente le singolari difficoltà della gestione della sicurezza nell’OT, spiegando perché i progetti OT si discostino in maniera sostanziale dai tradizionali progetti dell’IT e i complessi fattori che in alcuni casi possono compromettere o impedire la tutela di aspetti nevralgici della sicurezza dell’OT.
Soluzioni di gestione IT: il presupposto di endpoint sufficientemente robusti
Nei fatti, la realtà dell’IT e quella dell’OT sono assai diverse.
In verità, la maggioranza degli strumenti IT fondati su scansione può dimostrarsi invasiva e vanta un pregresso di interruzioni causate ai sistemi OT, notoriamente più delicati e proprietari. Per poter impiegare la tecnologia di scansione all’interno degli ambienti OT, occorre ridimensionare scrupolosamente la scansione, stanziare tempo extra per la supervisione da parte del personale dell’OT e limitare tale attività ai sistemi offline o durante interruzioni pianificate del servizio. Quando si considerano tutte queste premesse, il risultato è una copertura di sicurezza esigua da parte degli strumenti basati su scansione.
Per ottenere risultati concreti, occorrono strumenti di profilazione e d’acquisizione dati che siano affidabili, testati specificamente per l’OT, in grado di estendere al massimo la copertura degli asset e di automatizzare le informazioni derivanti dagli stessi, preservando allo stesso tempo l’integrità delle operazioni. Detto altrimenti, è d’importanza cruciale adattare le misure di sicurezza alle sfide e alle peculiarità proprie dell’OT, invece di fare affidamento su approcci IT standard che potrebbero non essere idonei in questo specifico contesto.
Quando le best practice dell’IT compromettono i sistemi dell’OT
Un’abituale pratica dell’IT per il rafforzamento dei sistemi implica che gli endpoint visualizzino un banner d’accesso all’accensione del sistema. L’intento sotteso è quello di far presente agli utenti che operano su un sistema di proprietà dell’azienda o di importanza critica. Ciononostante, per l’OT questo costituisce una criticità, poiché tali sistemi devono assicurare un tempo di attività ininterrotto al 100%. Conseguentemente, questi asset sono spesso predisposti per il riavvio e l’autenticazione automatici, onde garantire ridondanza e monitoraggio costante dei sistemi di sicurezza. L’inserimento di banner di login, però, interferisce sul meccanismo di autenticazione automatica di questi fondamentali sistemi dell’OT.
Si prenda ad esempio il sistema di controllo di un’installazione chimica. Tale sistema è strutturato per riavvii automatici. Il banner d’accesso risulta problematico in quanto arresta l’aggiornamento periodico e impedisce al sistema di reagire a pericolosi sbalzi di pressione.
Questa è la ragione per cui la maggior parte degli ambienti dell’OT adotta solamente tra i 40 e i 50 dei 100 principali controlli di sicurezza elencati nelle CSC 20. Molti di questi controlli o non trovano applicazione o possono interferire con processi operativi d’importanza vitale. In breve, trasporre le pratiche di sicurezza IT standard al mondo dell’OT può sollevare sfide considerevoli e non sempre risulta confacente ai requisiti specifici degli ambienti dell’OT.
Gli accordi sul Livello di servizio (SLA) nell’OT sono più rigorosi di quelli dell’IT
Generalmente, negli ambienti dell’IT, gli utenti si aspettano una pronta disponibilità di internet e dei server di posta o file al momento dell’accesso. In caso d’inconveniente, possono solitamente portare avanti i propri compiti mentre il supporto IT lavora alla risoluzione del problema e al ripristino della connettività. Queste interruzioni o finestre di manutenzione programmata nell’IT durano in genere da tre a quattro ore, durante le quali gli utenti finali potrebbero non poter accedere al sistema o al servizio. Diversamente, nell’ambito dell’OT, un semplice riavvio o una configurazione errata di uno switch o di un punto di comunicazione possono compromettere all’istante l’operatività in sicurezza.
Per molte realtà industriali, tale compromissione può significare una perdita delle specifiche di prodotto e della sua qualità. Nei frangenti più critici, può rappresentare un rischio per l’incolumità, venendo a mancare la visibilità su parametri vitali come pressione, flusso, temperatura o velocità, con conseguente degrado istantaneo del prodotto o addirittura un arresto completo dell’impianto. Simili fermi di produzione possono avere un impatto significativo sui ricavi. Questa problematica si complica ulteriormente in quei settori dove il riavvio della produzione non è semplice come premere un interruttore di un nastro trasportatore.
Per esempio, le unità di generazione elettrica a carbone possono richiedere da 25 a 30 ore per raggiungere la piena capacità operativa dopo uno shutdown, mentre nella raffinazione e nel petrolchimico possono volerci ore, o persino giorni, per ritornare alle specifiche di prodotto corrette.
Ho memoria di una presentazione sulla sicurezza in ambito OT tenuta per un’azienda manifatturiera. L’azienda aveva da poco subito un serio attacco informatico alla propria rete aziendale, che aveva provocato danni notevoli. Nel corso della mia esposizione, i responsabili dell’IT sollevarono numerose perplessità su possibili vulnerabilità di sicurezza, il che non destava sorpresa, essendo nessun sistema di sicurezza esente da falle. Mi assicurarono d’avere la situazione sotto controllo, ma appresi in un secondo momento che ciò si era tradotto nella disconnessione dall’accesso a internet per tutte le sedi operative.
Esprimendo la mia preoccupazione, ipotizzai che i responsabili degli impianti potessero ricorrere a “sneakernet” e memorie USB per trasferire dati, aggiornamenti e file all’interno e all’esterno delle strutture. Ma loro erano convinti che i direttori dei loro impianti non avrebbero mai contravvenuto alla policy sull’utilizzo delle USB. Eppure, quando quello stesso giorno visitammo lo stabilimento, trovammo la scrivania del direttore dell’impianto piena di chiavette USB. Chiesi allora il motivo per cui ignorasse la politica aziendale sulle USB. Lui sorrise e mi disse candidamente: “Lei ha idea dei guai che passerei se l’impianto si fermasse? Sono quasi certo che sull’uso delle USB chiuderanno un occhio.”
Colmare il divario tra team IT e OT
Una volta esaminati i tre bias, esploriamo ora le strategie atte a colmare le divergenze. L’armonizzazione tra i team dell’IT e quelli dell’OT presuppone una più profonda cognizione dei processi gestionali e delle normative di settore. Questo comprende:
- Far conoscere ai team dell’IT le dinamiche operative e gli impianti specifici dell’OT
- Acquisire familiarità con le misure di cybersecurity e i protocolli di gestione dati propri dell’IT
- Approfondire i regolamenti di conformità che interessano sia l’universo dell’IT sia quello dell’OT
- Condurre sessioni di confronto bisettimanali o mensili per l’esame delle sfide e la pianificazione degli interventi (action item)
Dopo aver maturato una miglior comprensione reciproca, si può procedere all’elaborazione di policy e procedure per la gestione dei sistemi OT (OTSM) che rispondano alle necessità di entrambi i fronti. Se risulta impraticabile implementare una procedura IT standard per un’infrastruttura particolare, l’adozione di controlli compensativi può facilitare il bilanciamento tra esigenze di sicurezza ed efficienza operativa
Il passaggio successivo per ridurre il gap tra IT e OT consiste nell’identificare strumenti e tecnologie che siano funzionali per la gestione dei sistemi dell’OT (OTSM) e, al tempo stesso, capaci d’integrarsi con i sistemi IT esistenti. Questi possono includere:
Trovare il giusto equilibrio tra produzione e protezione
È d’importanza vitale tutelare la vostra infrastruttura e la vostra produzione. Applicare puramente e semplicemente soluzioni IT all’ambiente OT può avere ripercussioni gravissime. Un successo reale presuppone d’informarsi sulle distinzioni tra le necessità dell’IT e quelle dell’OT, affrontare i bias di natura filosofica, progettuale e tecnologica, e favorire una collaborazione che potenzi la gestione efficace del divario IT/OT. Risulta cruciale nutrire aspettative realistiche: i miglioramenti nella sicurezza non si concretizzeranno nell’immediato, né senza incontrare ostacoli strada facendo. In questo panorama in continua evoluzione, la perseveranza e un impegno costante nel rendere la sicurezza dell’OT più robusta nel tempo sono la chiave di volta.
1 - https://www.ibm.com/reports/data-breach
