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 Event Collector (UNINA) Instrumented Software (rule-based logging) (UNINA) Model Extraction (UNICAL) Nominal model Conformance Analysis (UNICAL) Anomaly detection Extracted model Traces

Generazione delle tracce Il sistema target è suddiviso in moduli E0E0 E1E1 E3E3 E4E4 E2E2 E5E5 Una traccia di esecuzione cattura l’attivazione dei moduli e 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) EVENTONOMEMODULO IST ap_note_cleanups_for_socket_ex http_main SST ap_note_cleanups_for_socket_ex alloc SST ap_palloc alloc SEN ap_palloc alloc SST ap_close_fd_on_exec alloc SEN ap_close_fd_on_exec alloc SEN ap_note_cleanups_for_socket_ex alloc IEN ap_note_cleanups_for_socket_ex http_main SST ap_update_child_status http_main SEN ap_update_child_statushttp_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 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)