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)