Un modello integrato control-flow e data-flow per il rilevamento ...

Recommendations

Info

64 5. Conclusioni e sviluppi futuri 5.1 Riepilogo del lavoro svolto 5.1.1 Il modello Lo studio dei modelli esistenti ha messo in luce vari casi in cui essi sono ciechi a certi tipi di attacchi e partendo da tre scenari e da una semplice osservazione sono venute alla luce le possibili migliorie. L’osservazione è che l’apprendimento del control flow richiede l’acquisizione di informazioni relative allo stack al momento della chiamata di sistema, informazioni di cui però può beneficiare anche il modello data flow. Il modo in cui questo può beneficiarne appare dai primi due scenari presentati, che riguardano le relazioni unarie: si è visto che l’uso dello stack permette di classificare i parametri delle system call in base al percorso che il control flow ha seguito per arrivare a fare una certa chiamata. Nel caso delle relazioni binarie invece l’utilità dell’uso dello stack rimane poco chiara e deve essere ancora investigata ma si è comunque proposta una miglioria, la cui motivazione appare nel terzo scenario analizzato. L’osservazione in questo caso è stata che non è assolutamente garantito che le relazioni che coinvolgono i parametri delle chiamate di sistema siano invarianti rispetto al loro valore e dunque si è proposto un nuovo schema di apprendimento che tiene conto di questo fatto. 5.1.2 L’implementazione Nel quarto capitolo sono stati presentati alcuni dei dettagli dell’implementazione, in particolare è stato mostrato come DTrace abbia permesso di non scrivere nem- meno una riga di codice in kernel space. Certamente in un’implementazione reale questo è inevitabile ma per un proof-of-concept l’overhead imposto da DTrace è di tutto rispetto. Inizialmente si è quindi vista la struttura di DTrace per poi passare all’interfacciamento al framework tramite l’apposita libreria. Successivamente si è visto come la data collection ruoti interamente attorno ad uno script nel linguaggio di DTrace. Infine, dopo aver presentato una possibile struttura dati per l’esecuzione efficiente di un’operazione necessaria al modello, è stata discussa la complessità in modo del tutto informale, essendo questa dettata prevalentemente dalle strutture dati utilizzate. 5.2 Sviluppi futuri In questa sezione verranno presentate alcune idee che si vorrebbe investigare ed eventualmente integrare nel modello.
5.2. Sviluppi futuri 65 5.2.1 L’uso dello stack nell’apprendimento delle relazioni binarie Nel capitolo 3 è già stata accennata la possibilità di considerare lo stack anche nell’apprendimento di relazioni binarie. Questo è equivalente a giustapporre lo stack al nome del parametro preso in considerazione, differenziandolo quindi rispetto al percorso che è stato seguito per eseguire una data chiamata di sistema. L’idea di usare lo stack in questo modo potrebbe permettere di apprendere una sorta di “data flow procedurale”: invece di guardare finemente il data flow tra una chiamata e l’altra in questo modo potrebbe diventare fattibile di apprendere delle informazioni più high-level rispetto al flusso che seguono i dati. Tuttavia non è ancora ben chiaro quanto utile possa essere l’aggiunta di questo tipo di informazioni e la prima evoluzione che verrà investigata sarà proprio questa. 5.2.2 Una dimensione statistica per il modello Control flow e data flow sono due dimensioni in qualche modo ortogonali e la loro osservazione combinata consente di raggiungere un buon livello di dettaglio nella comprensione del comportamento di un programma, che si traduce nella capacità di impedire un gran numero di attacchi. Tuttavia sembra perfettamente possibile im- maginare dei casi in cui pur rimanendo esattamente all’interno del comportamento prescritto dal modello diventa possibile un attacco denial of service. Immaginiamo un ciclo al cui interno viene eseguita una malloc() (ad esempio si sta allocando memoria per una matrice): ad ogni chiamata si osserverà lo stesso stack, quindi lo stack s sarà successore di se stesso. Se in qualche modo si riesce a modificare l’esecuzione del ciclo è possibile eseguire un numero indefinito di malloc(), saturando la memoria. In questo caso si potrebbe pensare di far entrare in gioco un’ulteriore dimensione ortogonale alle precedenti due, cioè quella statistica. L’idea, che sarà mostrata su un FSA, è la seguente: durante il training si osserva le frequenze delle transizioni da uno stato all’altro, dando un peso agli archi. Finito il training e passa- ti alla verifica online si controlla che il processo monitorato rispetti le frequenze delle transizioni. Nel caso non le rispetti si è di fronte ad un comportamento anomalo che va segnalato. In Figura 5.1 si può vedere un esempio estremamente semplificato dell’idea. Sup- poniamo che in un ciclo una venga eseguita una malloc() 10 volte e infine venga eseguita una close(): questo nei run di training verrà osservato e si otterrà che le due transizioni etichettate malloc e close avranno un peso rispettivamente di circa
Page 1:
Università degli Studi di Udine Fa
Page 5 and 6:
Ringraziamenti In questo percorso m
Page 7 and 8:
Indice 1 Introduzione 1 1.1 Anomaly
Page 9 and 10:
Elenco delle figure 1.1 Codice sema
Page 11 and 12:
1 Introduzione Dai tempi della “d
Page 13 and 14:
1.1. Anomaly detection e system cal
Page 15 and 16:
1.2. Obiettivo del lavoro 5 informa
Page 17 and 18:
1.3. Struttura della tesi 7 seconda
Page 19 and 20:
2 Modelli per l’anomaly detection
Page 21 and 22:
2.1. Modelli control flow 11 con un
Page 23 and 24: 2.1. Modelli control flow 13 • Vi
Page 25 and 26: 2.1. Modelli control flow 15 1 int
Page 27 and 28: 2.2. Modelli data flow 17 • se v
Page 29 and 30: 2.2. Modelli data flow 19 suo scopo
Page 31 and 32: 2.3. Discussione dei modelli studia
Page 33 and 34: 2.3. Discussione dei modelli studia
Page 35 and 36: 3 Un modello che integra control fl
Page 37 and 38: 3.1. Debolezze dei modelli esistent
Page 45 and 46: 3.2. Proposta 35 1 int main(void) 2
Page 47 and 48: 3.3. Costruzione del modello 37 mai
Page 49 and 50: 3.3. Costruzione del modello 39 Un
Page 51 and 52: 3.3. Costruzione del modello 41 Tra
Page 53 and 54: 3.3. Costruzione del modello 43 Par
Page 55 and 56: 3.3. Costruzione del modello 45 Tut
Page 57 and 58: 3.5. L’algoritmo per la verifica
Page 59 and 60: 3.5. L’algoritmo per la verifica
Page 61 and 62: 4 L’implementazione L’implement
Page 63 and 64: 4.2. Introduzione a DTrace 53 un ce
Page 65 and 66: 4.2. Introduzione a DTrace 55 1 sta
Page 67 and 68: 4.3. Implementazione del sistema 57
Page 69 and 70: 4.4. Costo computazionale del model
Page 71 and 72: 4.4. Costo computazionale del model
Page 73: 5 Conclusioni e sviluppi futuri La
Page 77 and 78: 5.2. Sviluppi futuri 67 sistemi. In
Page 79 and 80: Bibliografia [1] System V Applicati
show all

Un modello integrato control-flow e data-flow per il rilevamento ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?