Gruppo di lavoroBig data for security evaluation
Analisi di tracce di esecuzione ed estrazione di modelli graph-based
UNINA, UNICAL
Feb. 2014
Obiettivi
• Detection di errori che non “bloccano” il flusso di controllo (ad es. utilizzo malizioso di un web server)– Generazione di log di eventi rappresentanti tracce
di esecuzione– Estrazione di modelli da log di eventi– Utilizzo dei modelli estratti quali • modelli predittivi di attacco/malfunzionamento • modelli descrittivi di comportamento lecito/atteso
– Individuazione di “pattern d’interesse” in base alla conformance dei modelli
Architettura del sistema
EventCollector(UNINA)
Instrumented Software
(rule-based logging)(UNINA)
Model Extraction(UNICAL)
Nominal model
ConformanceAnalysis(UNICAL)
Anomalydetection
Extracted model
Traces
Generazione delle tracce
• Il sistema target è suddiviso in moduli
E0
E1
E3
E4
E2
E5
• Una traccia diesecuzione cattural’attivazione dei modulie le interazioni tra essi
Eventi registrati
• Una traccia è composta da servizi e interazioni individuate da eventi prodotti durante l’esecuzione del programma
API_EXPORT(const char *) ap_parse_vhost_addrs(pool *p, const char *hostname, server_rec *s){
// * logbus code *logAnEvent( SST, 113, 4 ); server_addr_rec **addrs; const char *err; /* start the list of addreses */ addrs = &s->addrs; while (hostname[0]) {// * logbus code *{logAnEvent( IST, 184, 4 );/* LBFLAG */ err = get_addresses(p, ap_getword_conf(p, &hostname), &addrs, s->port);logAnEvent( IEN, 184, 4 );} if (err) { *addrs = NULL;// * logbus code *{logAnEvent( SEN, 113, 4 ); return err;}…
Esempio di traccia (Apache Web Server)
EVENTO NOME MODULOIST ap_note_cleanups_for_socket_ex http_mainSST ap_note_cleanups_for_socket_ex allocSST ap_palloc allocSEN ap_palloc allocSST ap_close_fd_on_exec allocSEN ap_close_fd_on_exec allocSEN ap_note_cleanups_for_socket_ex allocIEN ap_note_cleanups_for_socket_ex http_mainSST ap_update_child_status http_mainSEN ap_update_child_status http_main
Estrazione dei modelli nominali
– Estrazione di modelli control-flow (graph-based) da tracce di eventi “leciti” mediante tecniche di process mining
– Uso di metriche di log conformance per valutare la qualità del modello estratto (e quindi dell’algoritmo usato)• Metrica di riferimento: Fitness
– misura la % di eventi, presenti nel log, che sono conformi al modello – misura robusta rispetto alla presenza di rumore– sensibile in presenza di mix di scenari d’uso
– Sperimentazione con vari algoritmi control-flow discovery, disponibili nella suite open-source ProM
Esperimenti per l’estrazione dimodelli nominali
• Setting– Attività: Tipo interazione
(IST,IEN,SST,SEN) + Funzione invocata– Input: tracce di esecuzioni “lecite”
• Criticità riscontrate– Modelli “spaghetti-like” (molti nodi e
collegamenti ) di difficile comprensione
– Presenza di molti loop e di nodi sconnessi (privi di nette dipendenze causali da/verso altri nodi)
– Grado di fitness (conformità del modello) basso (≈75%)
Anomaly Detection
– Analisi di “conformance” per riconoscere le tracce anomale (potenziali errori)• Confronto fra una generica traccia (non classificata) ed
il modello “nominale”, estratto dalle tracce lecite• Fitness bassa vs al modello nominale indica che la
traccia è anomala
– Estrazione di modelli da log di eventi “ERRORE”• Utilizzo dei modelli estratti quali modelli descrittivi di
attacco/malfunzionamento
Esperimenti per la rilevazione ditracce “anomale”
• Risultati– Buoni risultati solo per alcune tracce di
errore• Modelli di attacco leggibili• Fitness ≈ 20% (<< 75%, ottenuto, in media, su
tracce corrette)
– Altre tracce di errore non sono riconosciute come anomale rispetto al modello nominale• Modelli di attacco spaghetti-like, non molto
diversi da quello nominale• Fitness > 70%
Conclusioni
• L’utilizzo di tracce di control flow comporta alcune problematiche:– elevato numero di attività (interazioni con funzioni)– tracce costituite da lunghe catene di eventi, con numerose ripetizioni
delle attività
• Si rendono necessarie strategie per migliorare la conformance del modelli e la rilevazione di anomalie
Sviluppi futuri
• Strategia 1: Innalzare il livello di astrazione sugli eventi– Considerare solo le interazioni fra moduli (cioè per ogni evento si
considera solo il modulo chiamante, ignorando la funzione invocata)– Uso di tecniche automatiche di astrazione e/o definizione di algoritmi
per la scoperta di modelli control-flow block-structured
• Strategia 2: Estrarre più modelli control-flow parziali– Ogni modello descrive il comportamento normale di un sotto-
processo (modulo o funzione di interfaccia di un modulo)• E’ necessario modificare il sistema di logging per generare un insieme di sotto-
tracce per ogni esecuzione dell’applicazione analizzata– Ogni modello descrive un particolare scenario di esecuzione del
processo• E’ necessario definire un metodo di clustering per partizionare le tracce in gruppi
omogenei rispetto al control-flow (ogni gruppo sarà usato per indurre uno dei modelli)
Strategia 1: risultati preliminari
Modello estratto con un algoritmo classico
Input: eventi di tracce lecite, astratti al livello di modulo (chiamante)Risultati: modelli più leggibili
Modello con algoritmo abstraction-based (le attività ed i flussi meno significativi non sono visualizzati)
Top Related