6 Test e Simulazioni

(1)

6 Test e Simulazioni

In questo capitolo verrà illustrata la metodologia di testing impiegata per l’intera fase di sviluppo del grafo. Grazie all’uso di questa metodologia è stato possibile ottimizzare, in termini di tempo e uso di memoria, le prestazioni del simulatore. Di seguito verrà fatta una panoramica sull’infrastuttura di esempio studiata mediante il simulatore [2] e sulle simulazioni prodotte da Haruspex v2 [4]; successivamente verranno illustrate le misure ottenute durante la fase di sviluppo del grafo, le misure ottenute da un campione di simulazioni e, infine, verrà fatto un confronto con le prestazioni della versione del simulatore presa in esame.

6.1 Infrastruttura di esempio: laboratorio di

Cybersecurity di Enel

L’infrastruttura di esempio studiata mediante il simulatore è quella del laboratorio di Cybersecurity presente nell’area di ricerca sperimentale dell’Enel a Livorno. Il laboratorio contiene un circuito idraulico ed un sistema di supervisione e controllo di tipo Supervisory Control and Data Acquisition (SCADA) che lo gestisce. Que-st’infrastruttura è stata implementata con un’architettura e con dei protocolli che riproducono ciò che si può realmente trovare in un impianto di produzione elettrica. La dorsale interna dell’infrastruttura è costituita da uno switch e da alcuni firewall che gestiscono le comunicazioni tra lo switch e tre sottoreti: la rete intranet (Po-wer Context), la rete di processo (Rete di Processo) e la rete di controllo (Rete di Controllo). Il perimetro di ogni sottorete è definito dai firewall, che svolgono anche la funzione di router. Mentre lo switch e i firewall si occupano di filtrare le comunicazioni tra le sottoreti, ogni sottorete al suo interno è piatta.

La tabella degli attacchi e la tabella delle vulnerabilità del database del si-mulatore sono state generate dallo scanner di vulnerabilità globali GVScan [2]. In Figura 6.1 viene illustrato il livello di astrazione che definisce l’infrastruttura del laboratorio di Enel in GVScan.

(2)

Figura 6.1: Screenshot rete Enel in GVScan

Rete Power Context

I processi di business dell’organizzazione usano la Rete Power Context (192.168.8.0/24), che interfaccia i nodi collocati all’esterno dell’impianto di produzione con accesso privilegiato ad alcuni nodi di controllo della rete. La rete è costituita da 6 nodi e le componenti principali sono un server Windows Domain e due client VPN che accedono in remoto alla Rete di Processo

Rete di Processo

La Rete di Processo (10.0.255.0/24) è costituita da 17 nodi che eseguono i sever e i client SCADA per la supervisione e il controllo dell’impianto di produzione dell’e-nergia elettrica. Alcuni nodi sono ridondati per ragioni di sicurezza. Le componenti principali della rete sono:

• la stazione di controllo (eth1: 10.0.255.5, eth2: 172.16.10.21), rinominata DIGITOOL;

• la stazione di ingegneria (eth1: 10.0.255.4, eth2: 172.16.10.3), rinominata TENORE;

• l’area di servizi comune, ASC, (10.0.255.163).

I nodi DIGITOOL e TENORE forniscono agli operatori un’interfaccia per il controllo dei PLC che si trovano nella Rete di Controllo. Il nodo ASC offre dei servizi di

(3)

diagnostica, raccolta e diffusione dei dati rilevati dal sistema di controllo. A causa della molteplicità dei servizi offerti, l’ASC è il sistema più vulnerabile all’interno dell’infrastruttura.

Rete di Controllo

La Rete di Processo (172.16.10.0/24) è costituita da 7 nodi che simulano l’impianto di produzione dell’energia elettrica tramite un particolare sistema di circuiti idraulici. Le componenti principali della rete sono due nodi PLC (172.16.10.1 e 172.16.10.2).

6.1.1 Minacce e obiettivi

Nel simulatore sono state definite 32 minaccie con differenti diritti iniziali d’accesso sulla rete. L’obiettivo finale di ciascuna minaccia è quello di ottenere il diritto di “net info” sul PLC con indirizzo 172.16.10.1. Poiché la rete Enel è divisa in 3 sottoreti, per testare le prestazioni del simulatore è stato selezionato un campione di 3 minacce, ognuna con diritti iniziali d’accesso su una delle 3 sottoreti:

• Minaccia 1, con diritto iniziale d’accesso su 10.0.255.1 (Rete di Processo);

• Minaccia 20, con diritto iniziale d’accesso su 172.16.10.229 (Rete di Controllo);

• Minaccia 31, con diritto iniziale d’accesso su 192.168.8.30 (Rete Power Con-tex).

6.2 Haruspex v2: Simulazioni

A partire dalla descrizione dello scenario, Haruspex v2 ritorna un database con i campioni raccolti in diversi e indipendenti run di simulazione, e un insieme di statistice. Il tempo di simulazione varia ad intervalli discreti e ad ogni minaccia è associato uno stato che definisce i nodi dell’attack graph che sono stati raggiunti da essa. Le condizioni di terminazione delle simulazioni sono: il raggiungimento del time limit fissato dall’utente o il raggiungimento di tutti gli obiettivi prefissati per la minaccia.

In Figura 6.2 viene mostrata l’interfaccia utente da cui è possibile eseguire le simulazioni. Per eseguire le simulazioni è necessario impostare da interfaccia i seguenti parametri: una o più minaccie, la strategia di selezione, il lookahead, il time limit, il tipo di simulazione (deterministica o probabilistica) e il numero di simulazioni da eseguire.

(4)

Figura 6.2: Screenshot simulazioni multiple in Haruspex v2

6.3 Test

Un primo studio delle prestazioni del simulatore è stato effettuato sfruttando la funzionalità di debugging offerta dal simulatore. La funzionalità di debugging da l’opportunità di effettuare delle simulazioni singole. Per eseguire una simulazio-ne singola occorre selezionare una minaccia e quindi la strategia di seleziosimulazio-ne, il lookahead, il timelimit e il tipo di simulazione (deterministica o probabilistica).

Lo studio è stato svolto sulla dimensione dei grafi generati dalle simulazioni singole di tipo deterministico impostando progressivamente il lookahead della mi-naccia da 1 a 6. Le misure sono state effettuare selezionando la Mimi-naccia 1 e nello specifico prendendo in considerazione il primo grafo generato dalla simulazione1_{. Per}

avere una stima del miglioramento delle prestazioni ottenuto, in termini di memo-ria, sono state effettuate le medesime misure con la versione del simulatore presa in esame ricompilando i sorgenti in Java 72_.

Le tabelle con le misure riportano i seguenti valori:

• lookahead della minaccia;

• numero di archi;

• numero di nodi;

• numero di nodi finali;

• dimensione del grafo.

1_{Il grafo generato nella prima iterazione delle simulazioni singole è indipendente dalle strategie} di selezione e dalla probabilità di scoperta delle vulnerabilità che è pari a 1.

(5)

Inoltre, questi valori hanno permesso di verificare la correttezza della procedura in Algoritmo 5.4, valutando il numero di nodi finali; di verificare la presenza di nodi doppioni nella versione del simulatore presa in esame, valutando il numero di archi e di nodi; infine, di mettere in evidenza un eccessivo numero di archi determinato dalla presenza di numerosi attacchi con uguali pre e post condizioni.

6.3.1 Misure Grafo

In Tabella 6.1 vengono riportate le misure dell’Attack Graph.

LA Num. Archi Num. Nodi Num. Nodi finali Dim. del grafo

1 3 2 0 27.5703 Kb 2 292 15 0 109.5078 Kb 3 3776 103 2 1.0880 Mb 4 25354 526 33 7.7536 Mb 5 117798 2129 258 38.9050 Mb 6 419439 7049 1273 148.1320 Mb

Tabella 6.1: Misure dell’Attack Graph

In Tabella 6.2 vengono riportate le misure dell’Hash Attack Graph.

1 3 2 0 1.6562 Kb 2 292 15 0 13.3203 Kb 3 3776 103 2 134.25 Kb 4 25354 524 33 857.8828 Kb 5 117798 2094 258 3.8240 Mb 6 419439 6756 1273 13.4665 Mb

Tabella 6.2: Misure dell’Hash Attack Graph

6.3.2 Attack Graph vs Hash Attack Graph

Dimensione

In Tabella 6.3 vengono messi a confronto le dimensioni dei grafi. Come è possibile notare, si ha una riduzione di memoria approsimativamente del 90% .

(6)

Attack Graph Hash Attack Graph LA Dim. Grafo Dim. Grafo

1 27.5703 Kb 1.6562 Kb 2 109.5078 Kb 13.3203 Kb 3 1.0880 Mb 134.25 Kb 4 7.7536 Mb 857.8828 Kb 5 38.9050 Mb 3.8240 Mb 6 148.1320 Mb 13.4665 Mb Riduzione : ≈90%

Tabella 6.3: Confronto dimensione grafi

Correttezza

In Tabella 6.4 vengono messi a confronto il numero di nodi finali dei grafi. La corri-spondenza del numero di nodi finali congiuntamente alla procedura in Algoritmo 5.4 è condizione necessaria e sufficiente per dimostrare un corretto calcolo dei nodi finali nell’Hash Attack Graph.

Attack Graph Hash Attack Graph LA Nodi Finali Nodi Finali

1 0 0 2 0 0 3 2 2 4 33 33 5 258 258 6 1273 1273 Riduzione :

-Tabella 6.4: Verifica di correttezza

Numero nodi

In Tabella 6.5 vengono messi a confronto il numero di archi e il numero di nodi dei grafi. Come è possibile notare, il numero di archi corrisponde in entrambi i casi, tuttavia il numero di nodi evidenzia una progressiva diminuizione a partire da lookahead uguale a 4. Queste evidenze denotano la presenza nell’Attack Graph

(7)

di nodi con lo stesso insieme di diritti, dovuta al funzionamento della procedura di inserimento dei nodi (sezione 3.5) e ai criteri di ordinamento degli archi (sezione 3.7).

Attack Graph Hash Attack Graph

LA Archi Nodi Archi Nodi Riduzione Nodi

1 3 2 3 2 -2 292 15 292 15 -3 3776 103 3776 103 -4 25354 526 25354 524 2 5 117798 2129 117798 2094 35 6 419439 7049 419439 6756 293

Tabella 6.5: Confronto numero nodi

6.3.3 Attacchi Ridondanti

Dal report degli attacchi ottenuto tramite i criteri di ordinamento in Algoritmo 5.6 è stato possibile osservare che nel database del simulatore sono presenti numerosi attacchi con lo stesso insieme di pre e post condizioni. In Tabella 6.6 ne viene mo-strato un campione indicando gli id delle pre/post condizioni e il rispettivo numero di attacchi.

Id Pre Condizioni Id Post Condizioni #

33 97 18 65 95 13 37 71 26 35 70 41 33 69 30 16 17 15

Tabella 6.6: Campione attacchi ridondanti

Nell’ultima versione della tabella degli attacchi fornita da GVScan[2] è stato aggiunto un campo che permette di classificare gli attacchi con uguali pre e post condizioni. Sfruttando le informazioni di classificazione è stato possibile ottenere una ulteriore riduzione della collezione di attacchi usata per generare il grafo.

(8)

Descrizione dell’Algoritmo di Taglio degli Attacchi

Il taglio degli attacchi viene effettuato dopo la chiamata alla procedura purgeAttack in Algoritmo 4.1, usando quindi come parametro per il taglio la collezione degli attacchi restituita dalla procedura. L’algoritmo scandisce la collezione degli attacchi raggruppandoli in base alla classe di appartenenza. Successivamente, per ogni classe di attacchi:

1. viene effettuato un raggruppamento in base alla probabilità di successo;

2. per ogni gruppo viene selezionato un attacco in modo casuale.

La procedura di taglio degli attacchi permette di ridurre il numero di archi uscenti dai nodi mantenendo invariato il numero complessivo di nodi, e quindi di nodi finali, calcolati in Algoritmo 4.1. Inoltre, la procedura non influenza i risultati ottenuti dalle strategie di selezione presentate in sezione 4.6: il contenuto informativo della collezione di attacchi usata per generare il grafo rimane invariato.

Misure Grafo

In Tabella 6.7 vengono riportate le misure dell’Hash Attack Graph ottenute con il taglio degli attacchi ridondanti.

1 1 2 0 1.6093 Kb 2 26 15 0 5.7890 Kb 3 342 103 2 36.8984 Kb 4 2420 524 33 206.5234 Kb 5 11854 2094 258 905.8593 Kb 6 44035 6756 1273 3.0526 Mb

Tabella 6.7: Misure grafo con taglio degli attacchi rindondanti applicando

Attacks Cut Disabled vs Attacks Cut Enabled

In Tabella 6.8 vengono messi a confronto il numero di nodi e il numero di nodi finali dei grafi prima e dopo il taglio degli attacchi. Come è possibile notare, il numero di nodi e il numero di nodi finali rimane invariato.

(9)

Atks Cut Disabled Atks Cut Enabled LA Nodi Nodi Finali Nodi Nodi Finali

1 2 0 2 0 2 15 0 15 0 3 103 2 103 2 4 524 33 524 33 5 2094 258 2094 258 6 6756 1273 6756 1273 Riduzione: -

-Tabella 6.8: Confronto numero archi e dimensione dei grafi con attacks cut

In Tabella 6.9 vengono messi a confronto il numero di archi e la dimensione dei grafi prima e dopo il taglio degli attacchi ridondanti. Come è possibile notare, si ha una riduzione degli archi approssimativamente del 90% e una riduzione di memoria approssimativamente del 75% .

Atks Cut Disabled Atks Cut Enabled LA Archi Dim. Grafo Archi Dim. Grafo

1 3 1.6562 Kb 1 1.6093 Kb 2 292 13.3203 Kb 26 5.7890 Kb 3 3776 134.25 Kb 342 36.8984 Kb 4 25354 857.8828 Kb 2420 206.5234 Kb 5 117798 3.8240 Mb 11854 905.8593 Kb 6 419439 13.4665 Mb 44035 3.0526 Mb Riduzione: ≈90% ≈75%

Tabella 6.9: Confronto numero archi e dimensione dei grafi con attacks cut

6.4 Simulazioni

Di seguito verranno mostrate le misure ottenute eseguendo delle simulazioni mul-tiple, con comportamento deterministico, selezionando le minacce introdotte in sezione 6.4. I parametri adottati per le simulazioni sono: strategia di selezione Max Probabilità, time limit = 100 e lookahead impostato progressivamente da 1 a 5.

(10)

• lookahaed della minaccia; • numero di simulazioni; • tenacia della minaccia3_;

• tempo di simulazione;

• numero di simulazioni al secondo;

• media della memoria allocata per l’intero processo di simulazione;

Queste misure hanno permesso di testare le prestazioni, in termini di tempo e memo-ria, della versione del simulatore in cui è stata integrata la soluzione proposta, e di effettuare i confronti con le prestazioni della versione del simulatore presa in esame. Le misure che seguono sono state effettuate applicando il taglio degli attacchi.

6.4.1 Minaccia 1

In Tabella 6.10 sono riportate le misure effettuate eseguendo 10000 simulazioni.

LA Num. Sim. Minaccia Tenace Tempo Sim/sec Mem. Media

1 10000 si 27 sec 370 508 Mb

2 10000 si 30 sec 333 690 Mb

3 10000 si 48 sec 208 760 Mb

4 10000 si 150 sec 66 1060 Mb

5 10000 si 532 sec 18 1703 Mb

Tabella 6.10: Minaccia 1: prestazioni eseguendo 10000 simulazioni

1 50000 si 132 sec 378 577 Mb

2 50000 si 143 sec 349 771 Mb

3 50000 si 232 sec 215 838 Mb

4 50000 si 728 sec 68 1373 Mb

5 50000 si 2599 sec 19 2061 Mb

3_{Parametro che è possibile definire da file di configurazione e non da interfaccia utente, indica se} la minaccia ripete o meno gli attacchi che ha fallito [3].

(11)

6.4.2 Minaccia 20

1 10000 si 27 sec 370 468 Mb

2 10000 si 27 sec 370 545 Mb

3 10000 si 31 sec 322 742 Mb

4 10000 si 56 sec 178 865 Mb

5 10000 si 209 sec 47 1194 Mb

1 50000 si 130 sec 384 564 Mb

2 50000 si 130 sec 384 572 Mb

3 50000 si 150 sec 333 768 Mb

4 50000 si 268 sec 186 814 Mb

5 50000 si 997 sec 50 1736 Mb

6.4.3 Minaccia 31

1 10000 si 27 sec 370 499 Mb

2 10000 si 30 sec 333 644 Mb

3 10000 si 47 sec 212 734 Mb

4 10000 si 141 sec 70 998 Mb

5 10000 si 490 sec 20 1756 Mb

(12)

LA Num. Sim. Minaccia Tenace Tempo Sim/sec Mem. Media 1 50000 si 132 sec 378 560 Mb 2 50000 si 143 sec 349 751 Mb 3 50000 si 231 sec 216 846 Mb 4 50000 si 686 sec 72 1272 Mb 5 50000 si 2399 sec 20 2000 Mb

6.5 Confronto delle prestazioni

In Tabella 6.16 vengono messe a confronto le prestazioni della versione del simula-tore presa in esame con la versione ottenuta integrando la soluzione proposta. Il confronto comprende le misure effettuate selezionando la Minaccia 1 con lookahead = 3 ed eseguendo 10000 simulazioni. Queste misure rappresentano dei casi critici nella versione del simulatore presa in esame: eseguendo 50000 simulazioni con loo-kahaed = 4 non è sempre possibile portare a termine l’intero processo di simulazione e con lookahead = 5 risulta impraticabile eseguire delle simulazioni. Come è possi-bile osservare, si ha una riduzione di memoria approssimativamente del 54% e una riduzione dei tempi di calcolo approssimativamente del 85%.

Ver. LA Num. Sim. Min. Tenace Tempo Sim/sec Mem. Media

old 3 10000 si 319 sec 31 1713 Mb new 3 10000 si 48 sec 208 760 Mb old 3 10000 no 367 sec 27 1756 Mb new 3 10000 no 51 sec 196 853 Mb Riduzione : ≈85% - ≈54% Incremento : - ≈85%

-Tabella 6.16: Minaccia 1: confronto delle prestazioni con la vecchia versione eseguendo 10000 simulazioni

6.6 Considerazioni finali sulla soluzione proposta

Integrando l’Hash Attack Graph in Haruspex v2 è stato possibile dimostrare l’effi-cienza della soluzione proposta. I risultati ottenuti hanno evidenziato che le inef-ficienze dell’attack graph in questione derivano dalla rappresentazione interna del grafo e dagli algoritmi impiegati per il calcolo e la visita di questo.

(13)

Per comprendere a pieno le inefficienze del simulatore in termini di uso di me-moria, sarebbe stato opportuno fare una verifica puntuale del consumo di memoria dovuto alla rappresentazione degli altri oggetti coinvolti nel processo di simulazione: minacce, vulnerabilità e attacchi. La scelta di una adeguata rappresentazione degli oggetti in Java è stata determinante per l’implementazione della soluzione proposta. Quindi, si presume che svolgere un’analisi simile per gli altri oggetti coinvolti nel processo di simulazione potrebbe portare ad una ulteriore riduzione dei consumi di memoria del simulatore. Inoltre, partendo dal presupposto che il grafo in questione è un DAG etichettato, un’importante limitazione, sia in termini di efficienza che di correttezza, è dovuta all’uso dell’algoritmo per il calcolo dell’albero di copertura mi-mina (MST) di Prim. L’algoritmo di Prim è stato progettato per grafi non orientati con archi pesati, quindi non da alcune garanzie sia di efficienza che di correttezza dei risultati ottenuti dalle strategie di selezione durante la visita dell’MST. L’algoritmo è stato riproposto solamente per motivi di coerenza con la versione del simulatore presa in analisi, in modo da poter effettuare un confronto con i risultati ottenuti in-tegrando l’Hash Attack Graph nel simulatore. In alternativa all’algoritmo di Prim, sarebbe stato opportuno usare l’algoritmo per il calcolo dell’albero di cammini mi-nimi (SPT) di un DAG. L’algoritmo calcola, in tempo lineare, l’SPT di un DAG rilassando gli archi secondo un ordinamento topologico dei suoi vertici [6][7][17].