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

Recommendations

Info

60 4. L’implementazione apprendimento delle alternative infine è direttamente legata alla cardinalità degli insiemi su cui opera. 4.4.2 Costo della verifica Negli stessi insiemi creati con il training, durante la fase di verifica del modello (e quindi online) è necessario cercare gli archi relativi agli stack che si osservano e anche l’operazione find() ha complessità logaritmica. In un prototipo questa complessità è accettabile ma in un sistema vero è più opportuno usare una hash table. Supponiamo, in riferimento alla Definizione 5, di dover verificare due stack di altezza n = n ′ e con i primi k elementi a partire dal basso uguali: per verificare se vale rtn call → serve O(n − k), come pure per verificare se vale →. Verificare se (rk, r ′ k ) ∈ Ecrs ha complessità O(1) e verificare se ri = r ′ i per 1 ≤ i < k richiede O(k). Per cui la verifica costa all’incirca O(n) per chiamata di sistema, costo valido se si usa una hash table. Per quanto riguarda la parte unaria del data flow del modello è necessario cercare se un valore è presente in un insieme o se è compreso in un certo range. Nel primo caso l’operazione ha costo logaritmico nella dimensione dell’insieme, mentre nel secondo caso ha costo costante. La parte binaria invece presenta il problema di dover cercare le formule apprese durante il training e verificare che valgano. In base a quanto ampie sono le relazioni di un dato parametro le formule avranno dimensioni più o meno grandi, quindi il costo della valutazione è legato alla loro dimensione. Naturalmente è possibile valutarle con strategie furbe (short circuit) e questo migliora i tempi di esecuzione. 4.4.3 Alcuni dati sperimentali Di seguito vengono riportate alcune misure effettuate su software reali relative alle dimensioni medie degli stack. Queste misure permettono di avere un’idea dei dati che devono essere raccolti ad ogni chiamata di sistema. Supponendo di lavorare su una macchina a 64 bit e di avere un’altezza media di n, ad ogni system call si raccoglieranno 8n byte. Questo valore non considera i dati necessari alla parte data flow del modello. Per costruire la parte control flow infatti è necessario registrare ogni chiamata di sistema, mentre per la costruzione del modello dataflow questo non è necessario, anzi, potrebbe essere controproducente: in base al programma da monitorare infatti certe system call hanno poco a che fare con la sua sicurezza e dunque è superfluo monitorarle [16].
4.4. Costo computazionale del modello 61 Server web Apache (httpd) Altezza stack Occorrenze Altezza stack Occorrenze 7 2 (0.12%) 20 18 (1.1%) 10 10 (0.6%) 22 1348 (81%) 11 8 (0.48%) 23 132 (8%) 14 4 (0.24%) 24 1 (0.06%) 15 1 (0.06%) 25 5 (0.3%) 16 3 (0.18%) 26 2 (0.12%) 17 16 (0.96%) 28 18 (1.1%) 18 8 (0.48%) 30 1 (0.06%) 19 10 (0.6%) 31 73 (4.4%) I dati sono stati ottenuti monitorando per una decina di minuti un server web Apache con lieve carico. Sono stati osservati 1660 differenti stack, con altezza media di 22 elementi. MySQL (mysqld) Altezza stack Occorrenze Altezza stack Occorrenze 3 1 (0.32%) 14 6 (1.9%) 5 10 (3.2%) 15 6 (1.9%) 6 9 (2.9%) 16 8 (2.6%) 7 10 (3.2%) 17 27 (8.7%) 8 14 (4.5%) 18 24 (7.7%) 9 6 (1.9%) 19 21 (6.8%) 10 4 (1.3%) 20 25 (8%) 11 6 (1.9%) 22 120 (39%) 12 3 (0.96%) 31 8 (2.6%) 13 3 (0.96%) In questo caso i dati si riferiscono al server MySQL a cui si appoggia il web server dei dati precedenti. In questo caso il processo è stato monitorato per 10 minuti, nei quali si sono osservati 311 differenti stack con altezza media di 18 elementi.
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: 4.4. Costo computazionale del model
Page 73 and 74: 5 Conclusioni e sviluppi futuri La
Page 75 and 76: 5.2. Sviluppi futuri 65 5.2.1 L’u
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?