Il punto di vista di Pentester sulla "Tecnologia dei gemelli digitali".
Post sul blog 11 dicembre 2020 di Willem Westerhof, Senior Security Specialist di Bureau Veritas Cybersecurity
Un gemello digitale è una versione completamente (o quasi completamente) digitalizzata di qualcosa che normalmente è un oggetto fisico, compreso il contesto in cui tale oggetto viene utilizzato.
Un caso d'uso tipico, ad esempio, è la manutenzione predittiva nei sistemi industriali. Questi sistemi operano in condizioni di grande stress e possono verificarsi problemi gravi se un sistema si arresta improvvisamente. Simulando digitalmente gli effetti della fisica e delle sollecitazioni a lungo termine su un dispositivo di questo tipo, è possibile prevedere che dopo un certo numero di ore di funzionamento, alcune parti specifiche dovranno essere sostituite.
Un altro caso d'uso tipico è il gemello digitale di un edificio, dove è possibile determinare la sollecitazione di parti specifiche dell'edificio, capire quanta luce naturale è disponibile all'interno dell'edificio, determinare quali sono le posizioni più adatte per gli 'uffici del silenzio' o quali reparti dovrebbero essere vicini l'uno all'altro, qual è il modo più efficiente di protezione antincendio, ecc. Inoltre, è possibile eseguire diverse simulazioni sull'impatto che si avrebbe se si verificasse uno scenario specifico, ad esempio: se un incendio si sviluppa nel lato ovest dell'edificio, cosa accadrà?
Ciò che sembra essere passato inosservato ai più, però, è che questa tecnologia del gemello digitale può essere utilizzata anche per migliorare la Cybersecurity! Soprattutto in quei prodotti e sistemi in cui una violazione della cybersecurity può causare rischi per la sicurezza.
Dal punto di vista del miglioramento della cybersecurity, esistono due tipi di gemelli digitali "utili":
- Gemello di prodotto
- Gemello dell'ecosistema
Gemello di prodotto
La creazione di un gemello di prodotto è simile alla virtualizzazione del software, ma fa un passo avanti: Prende in considerazione anche il contesto operativo del dispositivo. Questo è un enorme vantaggio per l'esecuzione di test di sicurezza!
Un esempio tipico sono i dispositivi automobilistici. Sebbene sia possibile testare il software e l'hardware automobilistico, di solito lo si fa in un veicolo fermo o forse addirittura a motore spento. In realtà, però, il veicolo percorrerà le strade a media o alta velocità per la maggior parte del tempo, e un hack del dispositivo durante questo periodo sarà anche una delle cose più disastrose che possano accadere all'auto (e al suo proprietario).
Creando un gemello digitale di un prodotto di questo tipo (come un'automobile), è possibile simulare il dispositivo alla guida di un percorso specifico, affrontando il traffico, ecc. e contemporaneamente tentare di hackerarlo. I bug che normalmente passano inosservati - come ad esempio un piccolo ma potenzialmente fatale ritardo nell'elaborazione degli input dei sensori di collisione laterale - possono essere individuati perché è possibile testare anche il contesto completo in cui il dispositivo opera. Un altrobuon esempio è rappresentato dagli aeroplani o dai dispositivi spaziali, che sono entrambi sistemi che non si vuole assolutamente hackerare in senso fisico mentre stanno volando da qualche parte, a causa dei rischi connessi se qualcosa va storto.
Inoltre, può anche testare vulnerabilità specifiche in determinate condizioni. Se, ad esempio, si hackera una gru industriale e si riesce a spostare il peso del contrappeso, normalmente non si dovrebbe provocare la caduta della gru. Ma forse, in determinate circostanze come forti piogge, una giornata ventosa o un carico pesante attaccato alla gru, sarà sufficiente per farla cadere e causare gravi danni a persone e cose.
Oltre all'ovvio miglioramento di trovare problemi seri e di poter eseguire i test in uno stato operativo normale, elimina anche molti aspetti negativi del testare questi prodotti nel loro stato fisico normale. I penetration testing invasivi possono a volte rompere le cose o addirittura bloccare i sistemi in modo permanente, e questi tipi di dispositivi non sono esattamente economici da reinstallare o ripristinare le impostazioni iniziali, mentre un gemello digitale può essere semplicemente ripristinato al suo stato originale.
Inoltre, i costi generali necessari per ottenere l'autorizzazione, sottoporsi a tutti i controlli, alle verifiche, ai controlli di sicurezza quotidiani e alle visite in loco, ecc. necessari per testare questo tipo di apparecchiature, possono essere ridotti al minimo, in quanto può ottenere un gemello digitale che può gestire da solo nel suo ufficio. Il che, alla fine, porta a test di penetrazione più economici e più approfonditi.
Ecosistema gemello
Questo è (e dovrebbe essere) un termine molto ampio. In sostanza, si tratta di un sistema di sistemi che si influenzano a vicenda in un certo modo. Un ecosistema gemello può essere piccolo o grande quanto si può immaginare. Per citare alcuni esempi:
- Il processo di un prodotto che si muove all'interno di una fabbrica.
- Un edificio intelligente, con tutti i tipi di dispositivi al suo interno.
- Reti elettriche con risposte autonome alle variazioni di domanda e offerta basate sugli input dei sensori.
- Una città o una nazione con tutti i suoi sistemi infrastrutturali vitali.
- Che in realtà è un ecosistema di ecosistemi.
Questo tipo di gemello digitale è più adatto per l'analisi dell'impatto di una vulnerabilità scoperta. Diventa possibile simulare ciò che accadrà se viene causato un DoS su un determinato sistema. Cosa si guasta inizialmente? Quali sono le conseguenze? Ci sono conseguenze a cascata? Ad esempio, un attacco DoS a un sistema di condizionamento dell'aria sarebbe tipicamente considerato un problema di rischio medio. Nel contesto in cui il sistema di condizionamento dell'aria è l'unico sistema presente nella sala server, e tutti i server iniziano a surriscaldarsi e a causare guasti alla rete, tempi di inattività, mancanza di accesso, eccetera, potrebbe tuttavia essere considerato un problema di rischio elevato o critico e qualcosa che dovrebbe essere risolto, o almeno mitigato.
Un altro esempio potrebbe essere quello di determinare la superficie d'attacco. Se qualcuno è fisicamente vicino all'edificio, quale tecnologia Wi-Fi/Bluetooth/Wireless può essere attaccata? Oppure, dopo aver importato tutte le regole del firewall, se un aggressore ottiene l'esecuzione di codice remoto su un sistema specifico, quali dispositivi potrebbe potenzialmente aver raggiunto dal punto di infezione originale? Qual è l'impatto della compromissione di questi sistemi e dove si trovano fisicamente questi dispositivi nell'edificio?
Anche se a volte queste domande possono trovare una risposta parziale interpellando vari esperti all'interno della sua organizzazione, le risposte spesso non sono altro che supposizioni istruttive. Soprattutto nei sistemi grandi o complessi, diventa estremamente difficile supervisionare la superficie di attacco totale e le conseguenze di un guasto o di una compromissione del sistema.
A titolo di esempio, consideriamo il seguente scenario:
Esiste un difetto di progettazione in un sistema di sensori dell'acqua, in cui i dati del sensore possono essere falsificati da un aggressore e sono sempre attendibili dal dispositivo hub centrale. È stata rilasciata una patch per risolvere questo problema, ma il dispositivo non si aggiorna automaticamente. Un giorno, un aggressore si avvicina a questo sensore e inizia a falsificare i dati, mostrando che stanno arrivando piogge eccessive. L'hub centrale si fida e inoltra l'allarme e l'ecosistema risponde automaticamente pompando l'acqua in eccesso nelle aree allagabili dei campi degli agricoltori, per evitare inondazioni altrove. I campi degli agricoltori vengono rovinati a causa dell'irrigazione eccessiva e in altre aree sorgono problemi di siccità, poiché l'acqua è stata pompata via.
Questo esempio dimostra che una vulnerabilità abbastanza insignificante o con un basso punteggio CVSS può (se inserita nel contesto del quadro generale) avere un impatto importante. Se l'analisi dell'impatto fosse stata effettuata utilizzando la tecnologia digital twin, questo problema avrebbe potuto essere facilmente evitato e prevenuto in futuro , adottando azioni di mitigazione come:
- Ritoccare i sensori attuali.
- Passare a più tipi di sensori per evitare guasti su larga scala dovuti a vulnerabilità in un solo tipo di sensore.
- Creare un'automazione aggiuntiva per evitare un processo decisionale errato (ad esempio, una siccità in un luogo e un'inondazione in un altro vicino, dovrebbero far scattare una sorta di allarme, poiché non si verificano normalmente).
Le possibilità di accesso a tale ecosistema gemello non si limitano solo all'analisi dell'impatto delle vulnerabilità conosciute. È anche possibile utilizzarlo come strumento per l'analisi del rischio e scoprire i singoli punti di fallimento, nonché le debolezze generali del design (comprese le debolezze agli attacchi zero day) nell'ecosistema. Inoltre, potrebbe aiutare a determinare quali sezioni della rete dovrebbero essere sottoposte a pentesting o quali "bandiere" dovrebbero essere impostate durante un impegno del Red Teaming.
Nel complesso, la tecnologia digital twin può davvero essere utilizzata comeamplificatore del livello di sicurezza di un'organizzazione, ma naturalmente ci sono anche alcune insidie e pericoli.
Insidie e pericoli comuni dell'utilizzo dei gemelli digitali
In primo luogo, e questo può sembrare ovvio per alcuni, ma deve sempre mantenere il suo gemello digitale sicuro e riservato. Un aggressore che ha accesso al gemello digitale della sua organizzazione, edificio o prodotto può trovare tutte le informazioni di cui potrebbe avere bisogno per cercare di violarla nel mondo reale.
In secondo luogo, si applica lo stesso principio che vale per tutti i sistemi basati sui dati: Garbage in = Garbage out. O lo fa bene, o non lo fa affatto. E si assicuri che qualsiasi consiglio o problema di progettazione identificato sia verificato come corretto, verificandolo sul campo.
In terzo luogo, se sta creando dei gemelli di prodotto, di solito prima implementa molti sensori su un prodotto vivo, per capire tutta la fisica e le singole cose che dovrebbe implementare nel suo gemello digitale. Ciò significa che si sta introducendo anche un'ampia superficie di attacco su quel prodotto specifico, quindi quando si implementano questi sensori, bisogna richiedere sicurezza nella selezione del prodotto.
Per riassumere
Tutto sommato, la tecnologia del gemello digitale è fantastica, anche per la sicurezza, se la si usa bene. In pratica, attualmente non è molto utilizzata per la sicurezza, ma stiamo lentamente iniziando a vedere alcuni early adopter che ricercano (o addirittura creano Proof of Concepts) le possibilità di utilizzarla proprio per questo scopo.