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)