Gruppo
This presentation is the property of its rightful owner.
Sponsored Links
1 / 14

UNINA, UNICAL Feb. 2014 PowerPoint PPT Presentation


  • 70 Views
  • Uploaded on
  • Presentation posted in: General

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)

Download Presentation

UNINA, UNICAL Feb. 2014

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Unina unical feb 2014

Gruppo di lavoroBig data for security evaluationAnalisi di tracce di esecuzione ed estrazione di modelli graph-based

UNINA, UNICAL

Feb. 2014


Obiettivi

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

Architettura del sistema

EventCollector

(UNINA)

InstrumentedSoftware

(rule-basedlogging)

(UNINA)

Model

Extraction

  • (UNICAL)

Traces

Extracted model

Nominal model

Anomalydetection

Conformance

Analysis

(UNICAL)


Generazione delle tracce

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


Eventi registrati

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;

    }


Esempio di traccia apache web server

Esempio di traccia (Apache Web Server)

EVENTONOMEMODULO

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


Estrazione dei modelli nominali

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


Esperimenti per l estrazione di modelli nominali

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%)


Anomaly detection

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

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

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

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)


Strategia 1 risultati preliminari

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


  • Login