Gruppo di lavoro Big 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 Instrumented Software (rule-based logging) (UNINA) Event Collector (UNINA) Traces Model Extraction (UNICAL) Extracted model Nominal model Conformance Analysis (UNICAL) Anomaly detection Generazione delle tracce • Il sistema target è suddiviso in moduli • Una traccia di esecuzione cattura l’attivazione dei moduli e le interazioni tra essi E0 E5 E1 E2 E4 E3 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 IST SST SST SEN SST SEN SEN IEN SST SEN NOME ap_note_cleanups_for_socket_ex ap_note_cleanups_for_socket_ex ap_palloc ap_palloc ap_close_fd_on_exec alloc ap_close_fd_on_exec alloc ap_note_cleanups_for_socket_ex ap_note_cleanups_for_socket_ex ap_update_child_status ap_update_child_status MODULO http_main alloc alloc alloc alloc http_main http_main 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 di modelli 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 di tracce “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 sottoprocesso (modulo o funzione di interfaccia di un modulo) • E’ necessario modificare il sistema di logging per generare un insieme di sottotracce 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 Input: eventi di tracce lecite, astratti al livello di modulo (chiamante) Risultati: modelli più leggibili Modello estratto con un algoritmo classico Modello con algoritmo abstraction-based (le attività ed i flussi meno significativi non sono visualizzati)