Le strategie di cyber-difesa di un sistema OT (Operational Technologies) sono sostanzialmente diverse da quelle di un normale sistema IT. Esse devono essere necessariamente in “depth” cioè articolate su più livelli e più strati, ma in ogni caso una delle dimensioni su cui occorre concentrare l’attenzione è la formazione degli operatori soprattutto in un settore, quale quello dei sistemi industriali, in cui ancora non vi è piena contezza delle reali problematiche di cyber security.
I principali incidenti ai sistemi OT
Gli incidenti più rilevanti occorsi ai sistemi OT , ovvero quelli che hanno causato i maggiori danni materiali, economici e di immagine sono accomunati dall’utilizzo di comandi “legittimi” utilizzati per condurre il processo fisico in una configurazione erronea.
Se andiamo infatti ad analizzare le modalità operative di Stuxnet (che ha causato la distruzione delle centrifughe per l’arricchimento dell’uranio in IRAN), Blackenergy3 (che ha causato un blackout in Ucraina nel 2015) e CrashOverride (che ha causato un blackout in Ucraina nel 2016) notiamo che, a prescindere dalle modalità di infiltrazione ed attivazione, in tutti e tre i casi i worm hanno generato comandi legittimi (ovvero sintatticamente e semanticamente corretti) ma errati dal punto di vista del funzionamento del sistema, cioè che in relazione alla configurazione del processo quella specifica manovra/comando era tale da portare lo stesso in una condizione operativa non consentita e quindi indurre un effetto cinetico (rottura meccanica) o comunque un ampio disservizio nella popolazione.
Acquisizione delle informazioni per sferrare un attacco
Da ciò discende che per poter condurre con successo un attacco contro un sistema OT è necessario che l’attaccante (ovvero il malware) acquisisca preventivamente informazioni sull’impianto e sulle sue modalità operative. Tralasciando Stuxnet, per il quale è ipotizzabile che queste informazioni siano state acquisite con attività di intelligence condotte a vari livelli e su una molteplicità di soggetti, vediamo che Blackenergy3 ha acquisito le informazioni necessarie a comprendere quali comandi inviare e quali dispositivi attaccare analizzando le attività che l’operatore umano eseguiva andando ad intercettare gli input e gli output del HMI (Human Machine Interface). In modo ancora più sofisticato CrashOverride acquisisce questa conoscenza sia mediante analisi del HMI che effettuando una mappatura dei diversi dispositivi presenti sulla rete sfruttando alcuni comandi del protocollo OPC (uno dei più diffusi standard a livello industriale per l’interoperabilità dei prodotti ICS). In entrambi i casi è evidente che l’acquisizione della conoscenza dei legami causa-effetto correlati al singolo comando, e con riferimento allo specifico target, richiede un tempo proporzionale al numero di manipolazioni che l’operatore effettua sull’impianto.
Se dunque il traffico di rete conterrà un alto numero di comandi inviati dall’operatore verso un determinato target, risposte o segnali di diagnostica, allora sarà più semplice per il malware apprendere il funzionamento del sistema e i relativi legami causa-effetto. Ciò implica che prima di essere efficaci queste tipologie di attacco devono essere dormienti per un lasso di tempo significativo ed impiegare tale tempo in operazioni di sniffing ovvero di intercettazione passiva di dati che transitano in rete. Non per altro il CERT US ha scoperto che Blackenergy3 era istallato e dormiente in sistemi di controllo di diverse utilities americane da almeno 5 anni. Questa latenza è un tallone di Achille di questa tipologia di attacchi in quanto vi è la possibilità che il malware possa essere identificato durante normali operazioni di verifica, alle volte in modo anche fortuito come recentemente occorso in Arabia Saudita dove le indagini per determinare le cause di un incendio hanno portato alla scoperta di un malware dormiente (che non aveva alcuna implicazione con l’incendio).
Il risvolto della medaglia è che una volta acquisita questa conoscenza l’attività prodotta dal malware è “legittima” e, quindi, i vari strumenti usualmente impiegati come Intrusion Detection System, Anomaly Detection ecc. risultano inefficaci in quanto il traffico, il payload ed i comandi veicoli risultano tutti coerenti e corretti. Detto in altri termini, quando il malware attiva l’azione di attacco nessun sistema sarà in grado di evidenziare un qualche warning all’operatore che avrà contezza di essere sotto attacco solo alla luce degli esiti negativi sul processo; quanto oramai sarà impossibile attivare azioni di prevenzione e mitigazione.
Da questo punto di vista è interessante considerare la strategia adottata da CrashOverride che una volta identificato il target (mediante scansione via OPC della rete) e acquisito le mappe causa-effetto (mediante analisi del traffico della rete relativo all’utilizzo del HMI) genera una sequenza ininterrotta di comandi di apertura ai sezionatori per prevenire i tentativi di ripristino “sovrascrivendo” in questo modo eventuali comandi di chiusura inviati dall’operatore.
Possibili strategie di contrasto
Per contrastare questa tipologia di attacco, una possibile strategia è quella di dotare il campo di capacità “decisionali” al fine di prevenire l’esecuzione di comandi “errati”. È questo il caso di alcune valvole che hanno dei meccanismi tali per cui in presenza di reiterati comandi di apertura e chiusura a breve distanza temporale (che potrebbero creare danni cinetici a causa del colpo di ariete) semplicemente ignorano i comandi successivi al primo per un determinato periodo di tempo. E’ possibile, quindi, adottare strategie messe in atto anche da Terna impiegando meccanismi di armed & fire. Ovvero un sezionatore può aprirsi solo se riceve da una sorgente il comando di “arm” e da una diversa sorgente quello di “fire” in una finestra temporale compresa fra 1 e 5 secondi, in questo modo un malintenzionato dovrebbe prendere il controllo di almeno due distinti sistemi che operano in stretto coordinamento.
Attacchi DoS
Altri attacchi ben noti appartengono alla categoria dei Denial of Service (DoS). Adottati dal campo dei servizi web, essi introducono un certo ritardo nella trasmissione/manipolazione dei dati, rendendo determinate risorse indisponibili. Tale effetto è il frutto di un elevato numero di interrogazioni ad alcuni elementi del sistema che faticano a smaltire l’alto tasso di richieste che li sovraccarica saturandoli e causando una latenza. In genere un DoS non è in grado di produrre un effetto cinetico in quanto in assenza di comunicazioni con il sistema centrale le diverse componenti tendono ad assumere una configurazione safe. È interessante, però, considerare che un attacco DoS può ridurre i tempi necessari alla preparazione di un attacco più sofisticato. Infatti con l’obiettivo di ridurre i tempi apprendimento dei legami causa-effetto, un attacco DoS viene lanciato al fine di rendere non raggiungibile (o disponibile) il target dell’attacco fino a provocarne il sovraccarico ed eventualmente il riavvio automatico dato dall’eccedenza di richieste. Al momento del riavvio, il target produrrà un quantitativo di traffico maggiore rispetto al suo normale funzionamento al fine di comunicare al sistema il suo ritorno in uno stato di disponibilità dopo il blocco o l’eventuale riavvio. Possiamo quindi assumere tale utilizzo degli attacchi DoS come un mezzo per sollecitare la rete a contribuire all’addestramento del malware durante le operazioni di apprendimento dei legami causa-effetto.
CrashOverride, per ritardare ancora maggiormente l’azione di recovery da parte dell’operatore, interviene anche sul flusso proveniente dal campo sovrascrivendo il messaggio OPC relativo al target con uno in cui inserisce nel campo payload il codice 0x01 che indica che il dato è fuori scale e quindi da considerare come non corretto e non attendibile. Questa operazione fa sì che il sistema e/o l’operatore non prendano in considerazione il valore anomalo proveniente dal campo ritenendolo, semplicemente, un problema legato ad una errata misurazione del sensore.
Questa idea è quella alla base di un’altra classe di modalità di attacco che prende di mira non tanto il sistema SCADA centrale, ma le RTU (Remote Terminal Unit) ovvero il canale di comunicazione fra queste e il sistema centrale. I vantaggi di questa tipologia di attacco sono sostanzialmente due. Da un lato occorre considerare che la superficie di attacco è ben maggiore essendo maggiore il numero di dispositivi, molti dei quali collocati nel territorio e non supervisionati e, generalmente posti in armadi e/o locali non sempre adeguatamente protetti da effrazioni. Inoltre, i dispositivi in campo si caratterizzano per limitate capacità computazionali e, quindi, anche le misure di protezione cyber sono di minore “spessore”. A questo si unisce il fatto che le conoscenze necessarie per portare con successo un attacco sono minori. Infatti, l’idea di base non è quella di inviare una serie di comandi in grado di condurre il sistema in una situazione anomala, ma, al contrario, modificare le misure del campo affinché il sistema centrale adotti (ovvero non adotti) le azioni prescritte. Semplificando, l’obiettivo dell’attacco è far credere al sistema SCADA centrale che un serbatoio è vuoto, quando in realtà è pieno, per indurre il sistema ad aprire le pompe fino a far tracimare il serbatoio stesso.
Stealth Attack
È facile intuire che la quantità di informazioni che un attaccante deve raccogliere in questo caso è inferiore dovendo solo individuare la variabile di misura proveniente dal campo e, di conseguenza, il tempo di preparazione dell’attacco si accorcia notevolmente. C’è un però, ed è legato al fatto che i sistemi di controllo industriali sono corredati da dei particolari dispositivi che vanno sotto il nome di BDD (Bad Data Detection) o FDI (Fault Detection and Isolation) il cui scopo è quello di rilevare e segnalare all’operatore eventuali dati provenienti dal campo anomali e/o incoerenti. La presenza di questi sistemi nasce dal fatto che con una non trascurabile probabilità le misure provenienti dal campo posso risultare corrotte per cause legate al processo di misura, a problemi con i sensori, ecc. Ovviamente qualora questi sistemi rilevassero che le misure provenienti dal campo, seppur sintatticamente e semanticamente corrette, non rispettino le regole del funzionamento dinamico del processo, segnalerebbero l’anomalia all’operatore “smascherando” l’attacco. Per ovviare a ciò l’attaccante deve mettere in atto tecniche di modifica “incrementali” delle variabili al fine di passare inosservato. Queste tecniche vengono genericamente indicate con il nome di Stealth Attack. In realtà le tecniche di stealth attack possono essere anche più sofisticate di un semplice aumento incrementale ed esiste un corposo filone di ricerca che mette in luce il numero e la dislocazione dei sensori che occorre attaccare per garantire che l’attacco non sia scoperto.
Fake attack
Una diversa soluzione di attacco, per certi aspetti simile a quanto visto con il worm Triton, sfrutta l’anello debole della catena di controllo, ovvero il fattore umano. Questa tipologia di attacchi, che potremmo indicare come Fake Attack, in realtà non alterano né i comandi inviati dallo SCADA alla periferia né quelli che dal campo vengono inviati verso lo SCADA. Essi attaccano il modulo degli allarmi al fine di evidenziare all’operatore una situazione anomala e/o pericolosa al fine di indurre l’operatore ad adottare una strategia di recovery se non addirittura lo shutdown del processo. Questo scenario, decritto moto bene nel romanzo “Blackout “ di M. Elsberg, gioca sul fatto che l’operatore all’insorgere di un allarme attiva tutte le procedure previste per mettere in sicurezza il processo. Questo tipo di attacco ha il pregio di richiedere una limitata conoscenza del processo e del sistema, sebbene non sia in grado di causare danni “cinetici”. Occorre considerare che il riavvio/ripristino di un impianto è un processo che può impiegare ore se non giorni e che quindi le conseguenze possono essere significative.
