UNINA, UNICAL Feb. 2014

1. Gruppo di lavoroBig data for security evaluationAnalisi di tracce di esecuzione ed estrazione di modelli graph-based UNINA, UNICAL Feb. 2014

2. 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

3. Architettura del sistema EventCollector (UNINA) InstrumentedSoftware (rule-basedlogging) (UNINA) Model Extraction • (UNICAL) Traces Extracted model Nominal model Anomalydetection Conformance Analysis (UNICAL)

4. Generazione delle tracce • Il sistema target è suddiviso in moduli E5 E0 • Una traccia di esecuzione cattura l’attivazione dei moduli e le interazioni tra essi E2 E1 E4 E3

5. 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; // * logbuscode * { logAnEvent( SEN, 113, 4 ); return err; } …

6. Esempio di traccia (Apache Web Server) EVENTO NOME MODULO IST ap_note_cleanups_for_socket_exhttp_main SST ap_note_cleanups_for_socket_exalloc SST ap_pallocalloc SEN ap_pallocalloc SST ap_close_fd_on_execalloc SEN ap_close_fd_on_execalloc SEN ap_note_cleanups_for_socket_exalloc IEN ap_note_cleanups_for_socket_exhttp_main SST ap_update_child_statushttp_main SEN ap_update_child_statushttp_main

7. Estrazionedeimodellinominali • Estrazione di modellicontrol-flow (graph-based) da tracce di eventi “leciti” mediante tecniche di processmining • 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

8. Esperimenti per l’estrazione dimodellinominali • 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%)

9. 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

10. 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%

11. 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

12. Sviluppifuturi • 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)

13. Strategia 1: risultatipreliminari Input: eventi di traccelecite, astratti al livello di modulo (chiamante) Risultati: modellipiùleggibili Modello con algoritmo abstraction-based (le attivitàediflussimenosignificativi non sonovisualizzati) Modelloestratto con un algoritmoclassico