EFFICACIA ED INTEGRAZIONE DI SISTEMI DI...

POLITECNICO DI MILANO

Facolta di Ingegneria

Corso di Laurea Specialistica in Ingegneria Informatica

EFFICACIA ED INTEGRAZIONE DI

SISTEMI DI ANOMALY DETECTION

Relatore: Prof. Giuseppe SERAZZI

Correlatore: Ing. Stefano ZANERO

Tesi di Laurea di:

Federico MAGGI

Matr. n. 674706

Anno Accademico 2005–2006

Dedicato a Silvia.In memoria di Franca.

Federico

i

RINGRAZIAMENTI

Diverse persone hanno contribuito, in modo più o meno diretto, alla nascitaed al completamento di questo lavoro, chi con un consiglio chi con una critica.Prima di tutto, desidero ringraziare esplicitamente coloro senza i quali questoprogetto non sarebbe esistito.

Un sincero ringraziamento va al Professor G. Serazzi, per avermi dato lapossibilità di lavorare a questa tesi, presso il VPLAB, a fianco dell’Ing. S. Za-nero. A quest’ultimo va un particolare ringraziamento: per la fiducia che con-tinua a darmi e perché, anche se sempre di fretta, è sempre riuscito a trovarela pazienza per consigliarmi al meglio.

Il mio secondo «grazie» va all’Ing. M. Matteucci sia per la disponibilità adiscutere creativamente di ogni idea, sia per la precisione delle sue critichesempre costruttive. Ringrazio il Prof. A. Bonarini, per i preziosi consigli ed iriferimenti sulla parte fuzzy. Allo stesso modo ringrazio la Prof.ssa I. Epifanie l’Ing. M. Tanelli, senza le quali alcune parti della tesi sarebbero state moltomeno chiare e accurate, e la Prof. ssa C. Bolchini, per i “consulti algoritmici”sempre “in tempo”.

Mi scuso con i miei genitori per aver sopportato i miei interminabili («cin-que minuti e scendo!») ritardi a pranzo e a cena: grazie, senza il vostro aiutonon sarei mai arrivato, così come sono, a questo punto della mia vita. Valen-tina invece ha sempre accettato con pazienza tutti i miei «no, oggi non posso»: grazie, ovviamente non solo per questo! Allo stesso modo ringrazio raist,per essermi sempre stato vicino ed aver ascoltato le mie lamentele.

Senza l’aiuto di eyelash sarei ancora in alto mare: grazie davvero. Ringra-zio anche h725, per la montagna di riferimenti utili, Ikki, per aver condivisola “volata finale”, e tutti gli altri compari del VPLAB e del CTF, per le mieinnumerevoli imprecazioni-contro-il-monitor™ che hanno dovuto sorbirsi. Miscuso anche con tutti i membri di inginfo-ml per la prolungata assenza.

Infine, affinché si noti, ringrazio Duma, anche se non è ritornata: ogniattimo passato in sua compagnia è indimenticabile e insostituibile.

iii

CONVENZIONI

In questo capitolo riportiamo alcune convenzioni lessico-sintattiche e tipogra-fiche utilizzate nella stesura del documento.

NOTAZIONI

Segue una lista delle notazioni impiegate nel documento, con relativa spiega-zione del significato.

– Nome notevole: con questa formattazione indichiamo in genere un nomedi un’azienda, di un prodotto, di un software. Altrimenti è utilizzatoper identificare nomi univoci all’interno del documento. Ad esempio, ilnome identificativo di un esperimento.

– Variabile o campo: con questa formattazione indichiamo in genere ilnome di una variabile oppure di un campo in una struttura dati.

– P[E] o P(E): probabilità dell’evento E.

– M(x1, . . . , xn): media campionaria del campione x1, . . . , xn.

– G(x1, . . . , xn): media geometrica del campione x1, . . . , xn.

– E ; F : E causa F secondo (il test di) Granger.

ACRONIMI

Segue una lista delle definizioni di tutti gli acronimi che compaiono nel docu-mento.

ARMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Auto Regressive Moving Average

ARX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Auto Regressive eXogenous

AR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Auto Regressive

ASCII . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . American Standard for Information Interxchange

BMU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Best Matching Unit

BSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Basic Security Module

CIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Confidentialiy Integrity Availability

CIDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Collaborative IDS

CSV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Comma Separated Values

CTF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Capture The Flag

DAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Direct Acyclic Graph

DARPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defense Advanced Research Projects Agency

v

DBMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DataBase Management System

DIDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Distributed IDS

DoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Denial of Service

DR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Detection Rate

DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Document Type Definition

ED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Elementary Detector

FPR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . False Positive Rate

HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HyperText Transfer Protocol

IDEVAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intrusion Detection eVALuation

IDMEF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intrusion Detection Message Exchange Format

IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intrusion Detection System

IDWG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intrusion Detection Working Group

ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intrusion Detection

IETF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Engineering Task Force

IODEF . . . . . . . . . . . . . . . . . . . . . . . . . . . . Incident Object Description and Interchange Format

IPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intrusion Protection System

ISP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Service Provider

IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Protocol

IR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Information Retrieval

ISS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Security Systems

KBS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Knowledge Base System

LARIAT . . . . . . . . . . . . . . . . . . . . .Lincoln Adaptable Real-time Information Assurance Testbed

LL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lincoln Laboratory

MIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Massachusetts Institute of Technology

MTU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Maximum Transfer Unit

NIDES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Next-generation Intrusion Detection Expert System

NNID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Neural Network Intrusion Detection

NSTISSC . . . . . . . . National Security Telecomm. and Information Systems Sec. Committee

PHAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Packet Header Anomaly Detection

PID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Process ID

ROC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Receiving Operating Characteristic

SDEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security Device Event Exchange

SMTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simple Message Transfer Protocol

SOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Self Organizing Map

SRI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Stanford Research Institute

SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Secure SHell

STATL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . State Transition Analysis Technique Language

SYN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SYNchronize

TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Trasmission Control Protocol

vi

TF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Truth File

TOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Type Of Service

TTL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Time To Live

UCSB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . University of California Santa Barbara

UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .User Datagram Protocol

UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Unified Modeling Language

XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . eXtensible Markup Language

XSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .XML Schema Definition

vii

INDICE

INDICE viii

ELENCO DELLE FIGURE x

ELENCO DELLE TABELLE xiii

1 INTRODUZIONE 11.1 Motivazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Struttura del documento . . . . . . . . . . . . . . . . . . . . . . . 3

2 IL PROBLEMA DELLA SICUREZZA INFORMATICA 52.1 Concetti e paradigmi . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Problemi tradizionali . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 La situazione attuale: problematiche e sfide . . . . . . . . . . . . 7

3 SISTEMI DI INTRUSION DETECTION 113.1 Intrusion Detection . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Cos’è un IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.3 Contesto di funzionamento e architettura . . . . . . . . . . . . . 123.4 Tassonomia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.5 Valutazione degli IDS . . . . . . . . . . . . . . . . . . . . . . . . . 233.6 Approcci e strumenti: stato dell’arte . . . . . . . . . . . . . . . . 253.7 Considerazioni conclusive . . . . . . . . . . . . . . . . . . . . . . 45

4 ANALISI DEL DATASET IDEVAL 474.1 Dati di training e di testing . . . . . . . . . . . . . . . . . . . . . . 474.2 Traffico di rete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.3 Dati di auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.4 IDEVAL e correlazione di allarmi . . . . . . . . . . . . . . . . . . 534.5 Dataset alternativi . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5 VALUTAZIONE E INTERVENTI SUI PROTOTIPI ESISTENTI 595.1 Parte host-based . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.2 Parte network-based . . . . . . . . . . . . . . . . . . . . . . . . . 71

6 VERSO UN SISTEMA DI ALERT CORRELATION 836.1 Definizione del problema . . . . . . . . . . . . . . . . . . . . . . 836.2 Problematiche di semantica e di formato . . . . . . . . . . . . . . 856.3 Prototipo proof-of-concept . . . . . . . . . . . . . . . . . . . . . . 93

viii

6.4 Approcci secondari . . . . . . . . . . . . . . . . . . . . . . . . . . 112

7 CONCLUSIONI E SVILUPPI FUTURI 117

ix

ELENCO DELLE FIGURE

2.1 Evoluzione della complessità degli attacchi, contro la riduzione dellivello di abilità richiesto agli aggressori (J. McHugh). . . . . . . . . 8

3.1 Collocazione di un generico Intrusion Detection System (IDS) in unagenerica rete. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Modello generico di un IDS distribuito/collaborativo. . . . . . . . . 193.3 Storia e passi fondamentali dalla pubblicazione dell’articolo di J.

Anderson al 2000. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.4 Andamento della percentuale di falsi positivi e falsi negativi al

variare della sensibilità di un sistema di intrusion detection. . . . . 253.5 Curva Receiving Operating Characteristic (ROC) d’esempio. I dati

mostrati in questo esempio sono reali e sono tratti da http://en.wikipedia.org/wiki/Image:Roc.png. . . . . . . . . . . . . . . . . 26

3.6 Interpretazione di una curva ROC . . . . . . . . . . . . . . . . . . . 273.7 Schema di un generico algoritmo di apprendimento supervisionato. 293.8 Schema di un generico algoritmo di apprendimento non supervi-

sionato. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.9 Modello generico di riferimento per il problema della correlazione

di eventi (allarmi) in un sistema informatico. . . . . . . . . . . . . . 343.10 Funzionalità e livelli di astrazione nell’architettura di OSSIM. . . . 433.11 Architettura di alto livello di Prelude-IDS (a) e livelli di astrazioni

nelle librerie (b). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.12 Architettura di Prelude-NIDS, il sensore network misuse-based di

Prelude-IDS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.1 Rete simulata per la creazione del dataset IDEVAL. . . . . . . . . . 484.2 Distribuzione della lunghezza delle escuzioni (distanza tra invoca-

zioni successive di in.telnetd, misurata in numero di chiamatetra due execve consecutive). . . . . . . . . . . . . . . . . . . . . . . . 52

4.3 Distribuzione delle chiamate di sistema ritrovate in tre programmi:in.ftpd, in.telnetd e find (nei soli dati di training). . . . . . . . 53

4.4 Architettura di alto livello di Lincoln Adaptable Real-time InformationAssurance Testbed (LARIAT). . . . . . . . . . . . . . . . . . . . . . . . 56

4.5 Fasi di un esperimento automatizzato con LARIAT. In evidenza,l’unica fase in cui è richiesta interazione con l’utente. . . . . . . . . 56

4.6 Esempio di interfaccia grafica di LARIAT, così come appare da unoscreenshot pubblicato sull’articolo. . . . . . . . . . . . . . . . . . . . 57

4.7 Architettura schematica di SPLOIT, un framework per la verificadell’efficacia delle tecniche di evasione (mutazione di attacchi). . . 58

x

http://en.wikipedia.org/wiki/Image:Roc.png


5.1 Schema dell’architettura dell’analizzatore del prototipo host-based. 605.2 Curva ROC del prototipo host-based originale. . . . . . . . . . . . . 665.3 Variazione della probabilità minima (threshold) di sequenza al va-

riare della lunghezza della sequenza. . . . . . . . . . . . . . . . . . . 675.4 Seconda versione modificata dell’algoritmo per il calcolo della th-

reshold: variazione della probabilità minima (threshold) di sequen-za al variare della lunghezza della sequenza. . . . . . . . . . . . . . 69

5.5 Curva ROC del prototipo host-based dopo la prima modifica: nor-malizzazione basata su media geometrica. . . . . . . . . . . . . . . . 71

5.6 Curva ROC del prototipo host-based dopo la seconda versione del-l’algoritmo di normalizzazione. . . . . . . . . . . . . . . . . . . . . . 72

5.7 Schema dell’architettura a due stadi dell’analizzatore del prototiponetwork-based. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.8 Variazione della durata dell’addestramento: curve ROC per i quat-tro esperimenti. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

5.9 Comportamento in caso di traffico frammentato: curve ROC per iquattro esperimenti. . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

5.10 Curva ROC per un esperimento NF/NF con un training che hacoinvolto un numero di pacchetti dell’ordine di 106. . . . . . . . . . 82

6.1 Gerarchia di classi del modello dei dati IDMEF. . . . . . . . . . . . . 876.2 Andamento di due possibili funzioni per ridurre la misura di belief

in funzione del valore di False Positive Rate (FPR) . . . . . . . . . . . 926.3 Architettura prototipale di alto livello del sistema di correlazione:

sono state omessi i processi di normalizzazione, per la loro scarsarilevanza. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

6.4 Architettura prototipale di del sistema di correlazione: dettagliosui dati. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

6.5 Esempio di “fuzzificazione” di un intervallo crisp. . . . . . . . . . . 986.6 Esempio di intersezione di due intervalli fuzzy. . . . . . . . . . . . . 996.7 Differenza tra due possibili modellazioni dell’incertezza sulla mi-

surazione del timestamp di un alert. . . . . . . . . . . . . . . . . . . 1006.8 Esempio di intervallo fuzzy. L’interpretazione è la seguente: all’i-

stante 0.4 è stato misurato il timestamp d’inizio, all’istante 0.95quello di fine. Le incertezze sono modellate da un ritardo di 0.15che porta a presumere che l’inizio reale dell’alert possa essere in0.25, mentre la fine reale in 0.8. . . . . . . . . . . . . . . . . . . . . . 100

6.9 Differenza tra due possibili modi di misurare la distanza tra duealert: il primo è crisp, il secondo è fuzzy. . . . . . . . . . . . . . . . . 101

6.10 Variazione dell’efficacia di rilevazione al variare della riduzionepercentuale del numero di alert. . . . . . . . . . . . . . . . . . . . . . 103

6.11 Variazione di FPR al variare della riduzione percentuale del nume-ro di alert. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

6.12 Funzioni di cross-correlazione tra le serie temporali costruite a par-tire dagli alert dei rispettivi IDS. . . . . . . . . . . . . . . . . . . . . 105

xi

6.13 p-value (a) e GCI (b) per un periodo di campionamento di 60.0secondi per i test NetP ; HostP (rosso tratteggiato) e HostP ;NetP (nero continuo). . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

6.14 p-value (a) e GCI (b) per un periodo di campionamento di 1800.0secondi per i test NetP ; HostP (rosso tratteggiato) e HostP ;NetP (nero continuo). . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

6.15 p-value (a) e GCI (b) per un periodo di campionamento di 3600.0secondi per i test NetP ; HostP (rosso tatteggiato) e HostP ; NetP(nero continuo). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

6.16 p-value per un periodo di campionamento di 60.0 secondi per i testNetP ; HostP (rosso tatteggiato) e HostP ; NetP (nero continuo).Senza aggregazione (a) e con aggregazione (b). . . . . . . . . . . . . 108

6.17 GCI(p) per un periodo di campionamento di 60.0 secondi per i testNetP ; HostP (rosso tatteggiato) e HostP ; NetP (nero continuo).Senza aggregazione (a) e con aggregazione (b). . . . . . . . . . . . . 108

6.18 Valori di p-value e per un periodo di campionamento di 1800.0 (a)e 3600.0 secondi (b) per i test NetP ; HostP (rosso tatteggiato) eHostP ; NetP (nero continuo). . . . . . . . . . . . . . . . . . . . . . 109

6.19 Valori di p-value per i test NetP ; HostP (rosso tratteggiato) eHostP ; NetP (nero continuo). I periodi di campionamento sono60.0, 1800.0, 3600.0 per la colonna 1,2,3, rispettivamente. La secon-da riga indica l’impiego di aggregazione, la prima no. . . . . . . . . 110

6.20 Valori dell’indice di causalità per i test NetP ; HostP (rosso trat-teggiato) e HostP ; NetP (nero continuo). I periodi di campio-namento sono 60.0, 1800.0, 3600.0 per la colonna 1,2,3, rispettiva-mente. La seconda riga indica l’impiego di aggregazione, la primano. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

6.21 Valori di p-value e GCI al variare di p (anni) per il test Uova ;Galline (nero continuo) e Galline ; Uova (rosso tratteggiato). . . . . 112

xii

ELENCO DELLE TABELLE

4.1 Numero di istanze di esecuzione calcolate su tutto il dataset ditraining. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.2 Numerosità degli attacchi rilevabili a seconda del tipo di attivi-tà (host o network). Per “istanze raggruppate” s’intende il con-teggio effettuato contando una sola volta le istanze con lo stessoidentificatore, ovvero gli attacchi lanciati durante la stessa sessione. 54

5.1 Dati per il training massiccio del prototipo host-based. . . . . . . . 665.2 Confronto con il training effettuato in origine dallo sviluppatore

del prototipo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.3 Caratteristiche del traffico (frammentato) utilizzato per il training

e per il testing dell’IDS network-based. . . . . . . . . . . . . . . . . 80

6.1 Riduzione percentuale del numero di alert in ingresso (1404) al va-riare dei parametri di configurazione dei fuzzy set (in secondi). Ivalori invariati sono stati omessi nelle righe successive. Intestazio-ni: AC = Alpha Cut, W = Crisp Window, S = Fuzzy Slope, AD =Alert Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

6.2 Differenti misure di similarità . . . . . . . . . . . . . . . . . . . . . . 113

xiii

— CAPITOLO 1 —

INTRODUZIONE

La sicurezza delle reti, delle informazioni e delle applicazioni è un tema estre-mamente importante, non solo dal punto di vista economico. Nel 2000 un’al-larmante serie di disservizi colpisce i più importanti portali del mondo: Ya-hoo!, Buy.com, eBay, Amazon.com, CNN, E*Trade. Nel 2001 Egghead.comannuncia la sottrazione di 70000 numeri di carte di credito: i dati parlano diuna perdita del 20% del fatturato. Nel 2004 Yahoo!.com, Google.com e Micro-soft.com restano off-line per poco più di due ore: la perdita è inestimabile. Inun rapporto del 2005, l’FBI stima che i crimini informatici riportati hanno avu-to un impatto attorno ai 400 miliardi di dollari. Nel 2006 il sito di MicrosoftFrance viene defacciato con intenti puramente ludici. Dai dati CERT/CC [?],gli incidenti riportati nel 2000 erano 21756; nel 2003 furono 137529.

La ricerca non richiede più solo abilità tecniche ma approcci e metodi efficacie innovativi, soprattutto per quanto riguarda anomaly detection e correlazione diallarmi. L’anomaly detection è l’unica tecnica di Intrusion Detection (ID) in gradodi rilevare uno 0-day attack (attacco contro una vulnerabilità non ancora resapubblica); gli IDS classici (di tipo misuse) non sono più sufficienti, essendo ingrado di rilevare attacchi soltanto se conosciuti. Le tecniche per la correlazionedi allarmi devono essere approfondite: sembrano infatti essere l’unico approc-cio valido per lo sviluppo di IDS ibridi, in cui i contro delle tecniche classichevengono compensati dai pro degli algoritmi di anomaly detection, e viceversa.

Secondo un rapporto pubblicato all’inzio di novembre 2006 da SANS In-stitute[?], le vulnerabilità 0-day sono sempre più sfruttate. Per definizione, unexploit di tipo 0-day ha sempre successo: è utilizzato per sferrare un attaccoprima che la vulnerabilità sfruttata venga scoperta e corretta. Solo nel 2006,Microsoft ed Apple contano oltre 20 vulnerabilità 0-day riportate.

In questo contesto, il nostro lavoro ha l’obiettivo di analizzare in dettagliodue prototipi originali per anomaly detection, valutarne le prestazioni e le ca-pacità di generalizzazione degli algoritmi di apprendimento impiegati, di tiponon supervisionato. Viste le nuove sfide e le nuove necessità della ricerca nelcampo, ancora poco esplorato, della correlazione di allarmi, proponiamo unprototipo allo scopo di valutare l’efficacia e l’applicabilità degli approcci fino-ra noti anche all’anomaly detection. Lo sviluppo di un prototipo ha permessodi far emergere diversi problemi riguardo al campo specifico dell’anomalydetection. Inoltre, riportiamo una precisa definizione del problema della cor-relazione nel caso di sistemi di anomaly detection i quali hanno ipotesi moltopiù rigide rispetto ai classici IDS misuse-based.

1.1 MOTIVAZIONI

I recenti miglioramenti nella progettazione di attacchi sempre più sofistica-ti hanno posto nuove sfide, soprattutto nel campo degli IDS; sono necessari

1

1. INTRODUZIONE

nuovi approcci, prima di tutto dal punto di vista algoritmico ma anche per riu-scire ad integrare le capacità di rilevazione di più IDS, nei cosiddetti distributedIDS o IDS collaborativi. In questi sistemi si combinano algoritmi di correlazionee grandi basi di dati distribuite che raccolgono informazioni riportate dagliIDS a livello globale.

La raccolta, l’aggregazione e la centralizzazione di alert provenienti dafonti distribuite è un problema già risolto con successo da strumenti comeDShield o myNetWatchman. Tuttavia, nella maggior parte dei casi, queste in-formazioni sono prive di qualsiasi forma di semantica e non è raro trovarlearchiviate sottoforma di testo “libero”. Un primo problema è perciò quello diintegrare i normali IDS con una base di conoscenza: tuttavia questa possibilitàriguarda i soli sistemi misuse-based.

Il problema più difficile è invece il progetto del motore di correlazione che,di fatto, costituisce la base per qualsiasi sistema distribuito per ID. In lettera-tura sono stati proposti numerosi approcci, tuttavia nessuno sembra esseresufficientemente generico per essere adattato all’anomaly detection. Il designdi algoritmi per correlazione di allarmi è un problema nuovo, aperto e senzasoluzioni generiche. Il problema stesso dell’anomaly detection richiede nuovicontributi: migliorare l’efficacia e la precisione di questi strumenti e riusciread associare gli alert riportati a classi di attacco note, tipiche degli strumentimisuse-based.

Valutare l’efficacia di un IDS non è banale ma è indispensabile, non soloper valutare se l’approccio è buono ma per poter confrontare le prestazionidi diversi IDS in maniera quanto più possibile oggettiva. Questo problema èdifficilmente risolvibile dal momento che l’unico dataset effettivamente uti-lizzabile è affetto da gravi regolarità che, di fatto, permettono ai ricercatori digiungere a qualsiasi risultato.

Fatte queste premesse, lo scopo del nostro lavoro è triplice. Prima di tut-to vogliamo valutare l’efficacia di due prototipi per anomaly detection, host-/network-based, sviluppati presso il Politecnico di Milano: principalmenteperché non sono stati effettuati sufficienti esperimenti per verificare le effettivecapacità di generalizzazione (soprattutto per quanto riguarda il traffico fram-mentato), ma anche perché uno dei due presenta problemi in fase operativache si traducono in scarsa accuratezza.

In secondo luogo, i problemi finora riportati riguardo il dataset Intrusion De-tection eVALuation (IDEVAL) riguardano soltanto il traffico di rete. Riteniamonecessaria un’analisi approfondita anche dei dati dell’attività host: derivandodirettamente dalle stesse simulazioni è altamente probabile che presentino glistessi problemi dei dati network.

Infine, ma non per questo meno importante, riteniamo sia fondamenta-le un’analisi dettagliata degli algoritmi di correlazione proposti in letteraturaal fine di valutarne l’efficacia e l’adattabilità al caso anomaly detection. Larealizzazione di un prototipo che permettesse il test delle varie possibilità èindispensabile.

2

Struttura del documento

1.2 STRUTTURA DEL DOCUMENTO

Il documento è strutturato come segue. Il primo capitolo presenta le nuovesfide del panorama della sicurezza informatica mettendole a confronto e ri-chiamando i concetti ed i paradigmi tradizionali sui cui è fondata la sicurez-za dell’informazione. Tali basi permettono di introdurre il problema specificodegli attacchi informatici e, più precisamente, delle intrusioni. Il Capitolo 3è dedicato al concetto di rilevazione delle intrusioni, o ID: in questo capitoloè definito il concetto di IDS ed è presentata una panoramica completa dellostato dell’arte in fatto di anomaly detection e correlazione di allarmi. Il capito-lo è arricchito con una breve introduzione alle metodologie per la valutazio-ne dell’efficacia degli IDS. I capitoli successivi documentano le attività svoltenell’ambito di questo lavoro e, se necessario, introducono concetti utili allacomprensione della lettura.

Nel Capitolo 4 si discutono le principali problematiche dovute alla man-canza di dataset per la valutazione degli IDS. Oltre ad una breve analisi dellavalidità di alcuni metodi alternativi, il capitolo documenta i peculiari difettidel dataset IDEVAL: sia quelli noti, sia alcuni non riportati che abbiamo avutomodo di riscontrare. Il Capitolo 5 riguarda infatti l’analisi di due prototipi peranomaly detection sviluppati presso il Politecnico di Milano. Di tali strumentiè stata valutata l’efficacia e, quando possibile, sono state apportate alcune cor-rezioni con lo scopo di migliorare ulteriormente le performance. Il successivocapitolo presenta in dettaglio il problema della correlazione di allarmi, nel ca-so specifico degli alert prodotti da sistemi di anomaly detection. Sono discusseproblematiche di formato, di semantica e le limitazioni principali poste dal-l’approccio anomaly-based. Il tutto è riportato attraverso la documentazionedi un sistema di correlazione prototipale, sviluppato sia per far emergere pro-blemi problemi pratici, sia per valutare l’effettiva applicabilità degli approccie degli algoritmi proposti in letteratura.

3

— CAPITOLO 2 —

IL PROBLEMA DELLA SICUREZZA

INFORMATICA

I moderni sistemi informatici sono molto sofisticati e complessi; altrettantocomplesso è l’ambiente distribuito in cui questi sistemi sono immersi su scala,oggi, globale. Questa situazione è caratterizzata da un rischio particolarmen-te elevato per le istituzioni il cui business è basato sull’erogazione di serviziinternet, ma anche per le piccole aziende che necessitano di servizi Internetper la semplice comunicazione. Un tempo i servizi telematici erano semplici,pochi utenti vi accedevano via rete telefonica ed il problema della sicurezzadelle informazioni era ridotto al problema della sicurezza fisica. Le informa-zioni sensibili erano infatti archiviate in “posti sicuri” come i classici schedari“chiusi a chiave”.

Fu nei primi anni sessanta che il problema della sicurezza iniziò a riguar-dare sempre meno l’informazione fisica e sempre di più la comunicazione te-lematica. Con il progetto ARPANet il problema della sicurezza iniziò ad es-sere preso in considerazione con i connotati di “requisito di sistema”. Oggi ilproblema ha raggiunto proporzioni tali da non riguardare più solo i sistemiinformatizzati ma la totalità degli “ingranaggi aziendali” in cui il concetto dicomputer security è solo un aspetto.

Questo capitolo introduce i concetti ed i formalismi per definire in modopreciso il problema della sicurezza delle informazioni. Successiva mente simettono in risalto le nuove sfide per gli esperti ed i ricercatori, dopo averpresentato i problemi tradizionali della sicurezza informatica. Il concetto diintrusione e di rilevazione delle intrusioni conclude il capitolo e fornisce lebasi per il successivo.

2.1 CONCETTI E PARADIGMI

La sicurezza dell’informazione, così come definita dal National Security Telecomm.and Information Systems Sec. Committee (NSTISSC), è la protezione delle infor-mazione e dei sistemi hardware che utilizzano, memorizzano e trasmettonol’informazione stessa. Questa semplice definizione non include il fatto che,per mettere in sicurezza l’informazione, sono necessari strumenti, politiche,tecnologie, formazione e consapevolezza da parte degli utilizzatori. In mo-do più formale, la definizione generale di sicurezza è basata sulle proprietàche devono essere garantite affinché si possa parlare di “sistema sicuro” o“informazione sicura”.

Confidentiality — Solo gli utenti ed i sistemi autorizzati possono accedereall’informazione. Quando entità non autorizzate possono consultare ecomprendere informazioni, la confidenzialità è violata. Spesso è confusa

5

2. IL PROBLEMA DELLA SICUREZZA INFORMATICA

con il concetto di privacy per via dell’importanza della confidenzialitàdei dati personali.

Integrity — Solo gli utenti ed i sistemi autorizzati possono modificare le infor-mazioni e solo nelle modalità per cui sono state autorizzate. Si noti chequesta proprietà è violata anche nel caso in cui un utente modifichi leinformazioni in modalità diverse da quelle previste. L’integrità dell’in-formazione è violata anche se l’utente danneggia informazione senzacomprenderne il contenuto e tale danno non è riscontrabile.

Availability — L’informazione dev’essere disponibile nelle modalità previste dairequisiti. Se un sistema o un utente autorizzati impiegano troppo tem-po per consultare l’informazione o non riescono del tutto a consultarla,allora questa caratteristica è violata.

Esistono ulteriori caratteristiche (utility, accuracy, authentication) ma rite-niamo, come molti autori, che quelle elencate permettano di derivare tutte lealtre. In ogni caso, se il cosiddetto paradigma Confidentialiy Integrity Availabi-lity (CIA) è violato, l’istituzione subisce un danno. Più precisamente, il dan-no deriva dal rischio che l’istituzione corre nell’esporre i propri sistemi (p.e.,sulla rete pubblica). Tutti i sistemi informatici sono inevitabilmente affetti davulnerabilità, ovvero debolezze che possono essere sfruttate (exploiting) da unaggressore: questo processo è chiamato disastro o attacco e, di fatto, trasformail rischio in danno. In realtà, se la minaccia è attuata non intenzionalmente(es., terremoto, alluvione, ecc.) si tratta di disastro: se la minaccia è invece unaggressore allora si parla più propriamente di attacco informatico.

2.2 PROBLEMI TRADIZIONALI

Viste le premesse, il problema principale della sicurezza informatica è la so-luzione del delicato bilancio tra accesso alle risorse e livello di sicurezza. Metterein sicurezza una risorsa implica necessariamente restringerne l’accesso, al li-mite negarlo. In questo modo si riduce automaticamente la disponibilità dellarisorsa stessa.

Un sistema informatico è sicuro a diversi livelli, da diversi punti di vista e,soprattutto, in rapporto alla specifica situazione dell’organizzazione: la sicu-rezza non è una lista di “cose da (non) fare”, tanto meno la “giusta combina-zione di programmi”. La sicurezza agisce dal livello più alto della gerarchiaaziendale (politiche di sicurezza), fino alle scelte tecnologiche, architetturali eimplementative dei sistemi informatici. Spesso si parla anche di sicurezza delleapplicazioni ad indicare l’insieme dei problemi da risolvere nel progetto (secu-rity by design) e nell’implementazione di applicazioni sicure, specialmente sesi tratta di applicazioni server.

2.2.1 SICUREZZA “by design”

Spesso ci si accorge di una vulnerabilità dopo che questa viene sfruttata percondurre un attacco dopodiché, normalmente, la risorsa vulnerabile viene ag-

6

La situazione attuale: problematiche e sfide

giornata per ripristinare il necessario livello di sicurezza. Più auspicabilmente,una risorsa, una rete, un sistema in generale vengono progettati pensando allasicurezza.

Il primo principio che solitamente si tiene presente è la separazione dei privi-legi ovvero dando ad utenti e procedure il minimo set di privilegi necessarioper svolgere la propria funzione. Per esempio, se un web server deve accede-re ad una base di dati è necessario (e sufficiente!) che il DataBase ManagementSystem (DBMS) permetta l’accesso solo alla base di dati coinvolta, solo al si-stema previsto e solo nella modalità (lettura e/o scrittura) prevista. Con unagranulare separazione dei privilegi si evita la propagazione incontrollata diun attacco in risorse diverse e collegate (e.g., DBMS) a quelle compromesse(e.g., web server).

Inoltre, riducendo la dimensione di ogni singolo componente di un siste-ma informatico se ne riduce anche la complessità con un triplice beneficio:maggior controllo e gestibilità, possibilità di impiego di tecniche formali diverifica o (qualora non possibile) di testing massiccio per provare in che mi-sura i requisiti di sicurezza sono soddisfatti. Quando rilasciato, se un sistemainformatico (e.g., un access point) dovrebbe comunque essere anche configu-rato in modo sicuro (default security settings); ciò è spesso in contrasto conla richiesta di funzionamento out of the box o plug & play dei moderni sistemicommerciali (e.g., access point in modalità “open”).

2.2.2 POLITICHE DI SICUREZZA

Essere consapevoli delle vulnerabilità e progettare un sistema con “la sicurez-za in mente” non basta. Il primo, fondamentale passo verso la sicurezza inun sistema informativo è l’organizzazione stessa. Prima di tutto è necessariostudiare ed applicare politiche di accesso, controlli, procedure e strutture orga-nizzative pensate in modo tale che il flusso informativo non sia compromessorispetto al paradigma CIA.

Tutto ciò deve essere parte integrante della gestione di un’impresa e, al-lo stesso modo, deve essere continuamente rivisto, adattato e migliorato neltempo. Una politica di sicurezza è quindi la scelta di gestire e controllare lasicurezza esattamente come si fa per ogni altro processo aziendale. Non sipuò prescindere da una corretta politica di sicurezza: è la base di ogni sistemasicuro.

2.3 LA SITUAZIONE ATTUALE: PROBLEMATICHE E SFIDE

Vecchi e nuovi problemi hanno in comune i concetti appena descritti; tuttavia,oltre alla complessità, la situazione attuale è caratterizzata dalla maggior partedi aziende ed enti che trattano, memorizzano e scambiano i propri dati critici informato digitale. Il tutto immerso nel contesto di Internet: rete pubblica pensataper interconnettere gli host di tutto il mondo.

Oltre ad offrire vulnerabilità e opportunità diverse agli aggressori, l’evo-luzione del Web e la naturale tendenza a condividere informazioni hanno con-

7


18 J. McHugh: Intrusion and intrusion detection

1988 through late 1996, there appear to have been rela-tively few intrusions enabled by bu!er overflows. In late1996, the online magazine Phrack published a cookbookfor bu!er overflows [59] and the number of such incidentsrose dramatically. A search of the CERT advisories showsbu!er overflows becoming increasingly important, start-ing in early 1997. A keyword search of the CVE for theterm “bu!er overflow” results in about 25% of the entriesand candidate entries6 being identified. A substantial per-centage of the incidents reported to the CERT/CCduringthe past few years have involved a bu!er overflow exploitof some kind. There are several reasons for the popularityof these exploits:– The vulnerabilities are ubiquitous, as seen above. Thisincreases the likelihood that attacks against randomtargets will succeed.– A successful attack has a high probability of yieldingadministrator or superuser privileges on the target,since the subverted process typically runs with theseprivileges.– Exploit scripts or programs for these attacks are read-ily available on the internet and require minimal skillsto execute.As is the case with many other classes of attacks,

bu!er overflows have evolved in complexity and sophis-

6 The search was made against version 20001013 of the CVEwhich contains 1077 entries and 678 candidate entries. Of these,434 or 24.7% contain the terms “bu!er” and “overflow”.

1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000

hijackingsessions

sniffers

packetspoofing

GUIintruder

tools

automatedwidespread

attacks

widespreaddenial-of-

service attacks

"stealth"/advancedscanning

techniques

emailpropagationof maliciouscode

distributedattacktools

distributeddenial-of-

servicetools

executablecode attacks

(againstbrowsers)

widespreadattacks on DNSinfrastructure

increase in wide-scale Trojanhorse distribution

automatedprobes/scans

Internetsocialengineeringattacks

techniques toanalyse code for

vuls without source

widespreadattacks usingNNTP todistribute attack

windows-basedremote controllable

Trojans (backorifice)

Sophistication ofattacks

Intruder knowledgeneeded to execute

attacks

dates indicate majorrelease of tools orwidespread use of a typeof attack

Fig. 2. The evolution of attack sophistication and devolution of attacker skill

tication. Early attacks involved data explicitly read bythe target program. Subsequently, it was discovered thatvariables used to hold the values of environment variablescould also be used as attack vectors. Recently overflowsbased on format strings have been used.In 1992, the first widespread appearances of what are

now known as “root kits” started to appear [15]. Intruderswould gain access to a system as an ordinary user, typ-ically by obtaining a password to a user account throughguessing, social engineering, or other means. They wouldthen attempt to become root by exploiting a vulnerabilityon the system. Once root access was obtained, subvertedversions of various system utilities such as su, ftp andftpd would be installed and remote access permissionsenabled to facilitate subsequent reentry by the intruder.This line of intrusion has been refined over time with theaddition of numerous modified utilities intended to hidethe intruder’s activities from other users, administratorsand auditors.Often, substantial time elapses between the discovery

of a potential vulnerability and the development of an ex-ploit. Bellovin hypothesized TCP hijacking in 1989 [11],but exploits did not actually appear until 1995 [16]. Asnoted above, Morris demonstrated a race condition vul-nerability in 1988, but the first widespread incident of thiskind apparently occurred in 1991 [14].Figure 2 illustrates the increasing sophistication of at-

tacks from the mid-1980s to the present. As the attacks

FIGURA 2.1: Evoluzione della complessità degli attacchi, contro la riduzione del livellodi abilità richiesto agli aggressori (J. McHugh).

tribuito ad aumentare a dismisura la popolarità degli exploit [?]. Il risultato èmostrato in Figura 2.1: i tempi degli attacchi “manuali” hanno presto lasciatospazio a strumenti automatici che integrano scansione di vulnerabilità e allascelta degli exploit più appropriati.

Tra le principali ragioni di tale evoluzione le principali sono:

• la diffusione delle vulnerabilità rende possibile provare gli exploit inmaniera casuale e totalmente alla cieca, con una comunque alta proba-bilità di successo;

• le capacità richieste per eseguire gli exploit diffusi via Web sono estrema-mente basse: potenzialmente chiunque può essere in grado di provarli;

• la natura delle vulnerabilità più gravi è tale da permettere facilmente dieseguire istruzioni arbitrarie e privilegiate sulla macchina colpita.

2.3.1 ATTACCHI

Parallelamente alla devoluzione delle abilità tecniche richieste agli aggresso-ri, la complessità, l’efficacia e la sofisticatezza degli attacchi è in crescita, co-me mostrato in Figura 2.1. Di seguito riportiamo alcuni degli attacchi più ri-scontrati negli ultimi anni anche se non si tratta necessariamente di tecnicheattuali:

0-day — Sono gli attacchi non resi pubblici: uno 0-day sfrutta una vulnera-bilità non nota. Gli attacchi 0-day possono rimanere non rilevati anchedopo essere stati eseguiti. Fino a che la vulnerabilità non viene scopertaè infatti molto difficile riuscire a caratterizzare un possibile attacco chela sfrutti. Come sarà più chiaro in seguito, nel campo degli IDS gli 0-day sono particolarmente importanti: le capacità di generalizzazione di

8

La situazione attuale: problematiche e sfide

un IDS siano l’unica strada perseguibile verso la rilevazione automaticadegli 0-day.

Malware — Questo termine indica tutti quegli attacchi basati sull’esecuzionedi codice con il fine di distruggere o, comuqnue, di sottrarre informa-zione in modo illecito. Virus, worm, trojan, spyware, adware e scriptweb attivi sono diverse forme di malware. Lo stadio più avanzato dicomplessità è rappresentato dagli worm polimorfici, capaci non solo dipropagarsi in una rete attraverso meccanismi di auto-replicazione maanche di “mutare” in modo da rendere difficoltosa la loro rilevazion. I“cavalli di Troia” sono un’altra forma di malware: anche se la tecnica èpiuttosto datata, i trojan sono oggi molto diffusi.

Injection e applicazioni web — Con l’aumentata presenza di applicazioni webcomplesse, spesso vulnerabili a tecniche come l’SQL injection [?], si è ini-ziato a parlare di “web application vulnerability”. Con questo terminesi indicano le vulnerabilità spesso connesse ai moderni sistemi per la ge-stione dei contenuti web, i cui exploit permettono in molti casi di ricava-re l’intera base di dati. In questo contesto, i rimedi si stanno orientandoverso lo studio e l’implementazione di firewall a livello applicativo (webserver).

Social engineering — Seppur collocata da J. McHugh come la più vecchia tec-nica di attacco, il social engineering è tutt’oggi praticata con successoquasi sempre garantito, visto che esistono pochissime contromisure. Sibasa infatti sull’uso di abilità sociali e di dialogo con lo scopo di per-suadere i possessori di informazioni importanti o comunque utili (e.g.,segretarie, centraliniste, ecc.) nel tentativo di sottrarle semplicementefacendosele comunicare. L’efficacia di questa tecnica si basa sull’umananatura di comunicare e di interagire e fanno di tale attacco una vera epropria arte. Kevin Mitnick, pioniere del social engineering disse:

«People are the weakest link. You can have best technology, firewalls,intrusion detection systems, biometric devices...and somebody cancall an unsuspecting employee. That’s all she wrote, baby. They goteverything.»

Il social engineering fa uso di influenza e persuasione per convincereuna persona che il social engineer è in realtà un’altra persona. Come ri-sultato, un social engineer è in grado di trarre vantaggio dalle personeper ottenere informazioni, con o senza l’uso di mezzi tecnologici. Sol-tanto attraverso un accurata formazione aziendale è possibile mettere inguardia il proprio personale da questo tipo di attacco, anche se è sta-to mostrato [?] che la naturale curiosità umana può essere sfruttata consuccesso.

Phishing — Si tratta di un modo di utilizzare le tecniche di social engineeringattraverso il canale della posta elettronica. Con la diffusione dei portalibancari e di siti che gestiscono transazioni monetarie, il phishing è sta-to applicato principalmente per rubare informazioni sensibili relative a

9


conti correnti, credenziali di accesso o numeri di carte di credito. In unamail dall’aspetto volutamente formale, l’aggressore si spaccia per l’isti-tuto bancario (ad esempio) e chiede al destinatario di seguire un link chein genere mostra una riproduzione fedele del sito web dell’istituto. Il de-stinatario, se non consapevole, non sospetta di nulla e nella migliore del-le ipotesi inserisce le proprie credenziali che possono essere facilmenteraccolte dall’aggressore.

10

— CAPITOLO 3 —

SISTEMI DI INTRUSION DETECTION

In questo capitolo sono presentati in modo più approfondito i sistemi di ID.In particolare, dopo una breve introduzione sul modello e sull’architettura diriferimento verrà riportata una panoramica dei sistemi esistenti sul mercatoe, soprattutto, nella ricerca. Successivamente si forniranno le basi per com-prendere correttamente i risultati e le modalità per valutare l’efficacia di unIDS. Il resto del capitolo è dedicato alla review dello stato dell’arte per quantoriguarda i metodi per anomaly detection e correlazione di allarmi.

3.1 INTRUSION DETECTION

Nella sicurezza dei sistemi informatici e dell’informazione, la rilevazione del-le intrusioni, o ID, è l’atto di riconoscere un tentativo di attacco [?] (si ve-da la Sezione 2.1 per le definizioni di tali proprietà). Un’intrusione in un si-stema informatico è un qualsiasi tentativo di violare confidenzialità, integrità odisponibilità.

Intrusione in un sistema informatico non vuol dire necessariamente chel’aggressore si “introduce” virtualmente ottenendo accesso ad una risorsa;un’intrusione è considerata tale anche quando l’aggressore non autorizza-to (autenticità) riesce completare con successo un attacco ovvero ad ottenereinformazioni riservate (confidenzialità) oppure a compromettere il funziona-mento di una risorsa critica per l’azienda (disponibilità), eccetera. Come ogniforma di attacco informatico, le intrusioni sono rilevabili non solo per i danniche provocano ma, più sperabilmente, per la particolare attività di rete (o delsistema operativo) riscontrabile durante la compromissione. Questo concetto èanche noto come tamper evidence.

In pratica, l’ID è l’azione di cercare tracce evidenti di un attacco ad unarisorsa. L’operazione di rilevazione può essere effettuata sia manualmente cheautomaticamente. Nel primo caso, un umano monitora il funzionamento di unarisorsa (e.g., un server) e/o ne esamina i log di attività con lo scopo di trova-re segni di intrusione e, in generale, di funzionamento inatteso. Nel secondocaso la stessa analisi è effettuata (quasi sempre) on-line da sistemi software(eventualmente embedded): gli IDS, presentati in maniera approfondita nelCapitolo 3.

Anche se c’è confusione a riguardo, in generale l’ID non include né la pre-venzione d’intrusioni né la reazione alle intrusioni. La confusione è probabilmentedovuta alla convivenza di queste due attività nei moderni IDS, oltre alla fun-zione base di ID di base. Come sarà esemplificato da alcuni casi reali in 3.4.4,la maggior parte dei sistemi esistenti prevedono la definizione di quali azionicompiere prima/dopo l’ID in sé. Oltre alla pura segnalazione è infatti possi-bile memorizzare l’evento (dopo che questo è stato rilevato) per prevenirlo in

11

3. SISTEMI DI INTRUSION DETECTION

. . .

. . .

Database Analizzatore

Sensorenetwork

Sensorehost

Gesitone

FIGURA 3.1: Collocazione di un generico IDS in una generica rete.

futuro (prevenzione) o per analisi post mortem. Altrimenti è possibile reagiredisattivando la risorsa compromessa.

3.2 COS’È UN IDS

Gli IDS sono sistemi informatici che implementano la funzionalità di ID. Sitratta di sistemi software che automatizzano il monitoraggio del comporta-mento e del funzionamento di una risorsa [?; ?]; ad esempio, una workstation,un server o la rete stessa come mezzo di transito delle unità informative (pac-chetti Internet Protocol (IP)). Intuitivamente, sono l’equivalente degli antifurtiper le risorse e i sistemi informatici.

La ricerca nel campo degli IDS è relativamente giovane anche se esistonogià numerosi prodotti maturi (si veda la Sezione 3.4.4). Il primo a pronun-ciare il termine IDS fu J. Anderson [?] nel 1980, seguito successivamente daD. Denning [?] che, nel 1987, propose il primo framework e ispirò numerosiricercatori, gettando le basi per la nascita dei primi prodotti.

3.3 CONTESTO DI FUNZIONAMENTO E ARCHITETTURA

Da un punto di vista puramente infrastrutturale, un IDS viene affiancato aglialtri dispositivi in una rete rete. In generale un IDS è composto da più unitàlogiche, implementate da uno o più software separati, che possono o menocoincidere con degli elaboratori fisici.

La vera e propria funzionalità di ID è l’analisi di dati provenienti da più sor-genti dette sensori. In realtà, come mostrato in Figura 3.1, nel modello genericodi un IDS, possono essere presenti ulteriori componenti.

3.3.1 COMPONENTI

A scopo di generalità è utile smembrare un IDS nelle seguenti parti, ognunacon una diversa funzionalità:

12

Contesto di funzionamento e architettura

I. sensore/i,

II. analizzatore,

III. esecutore,

IV. base di dati e/o di conoscenza,

V. unità di gestione,

VI. unità di visualizzazione.

Da questa suddivisione emergono anche le principali dimensioni tassono-miche attraverso cui classificare un IDS. Il servizio di comunicazione tra compo-nenti è assolto da un canale di comunicazione/segnalazione (in banda o fuoribanda); non riteniamo opportuno dettagliare ulteriormente questo aspetto an-che perché dipende molto da quanto i componenti sono distribuiti su diversielaboratori.

SENSORI

A prescindere dal tipo di dati analizzati, i sensori implementano la funzionedi “cattura delle attività” del(la parte di) sistema da monitorare. Le attivitàpossono essere catturate in diverse “forme”, a seconda delle necessità e deltipo di attività. Per esempio, l’attività di rete è identificabile negli scambi deipacchetti ai vari livelli protocollari. Ancora, l’attività di un host è ricostruibiledai log delle varie applicazioni o, nello specifico, del sistema operativo stesso.

I dati che un sensore dovrà catturare dipendono quindi dal tipo di IDS.Come verrà rimarcato anche in seguito si possono dividere i sensori (e quindigli IDS) in due macro categorie, a seconda che questi analizzino:

l’attività di rete — questi sensori altro non sono che degli sniffer (ovvero in-terfacce di rete funzionanti in modalità promiscua) che intercettano tut-ti i pacchetti in transito sul segmento di rete dove vengono collocati:per esempio, nel caso di Figura 3.1, il Sensore N1 cattura i pacchettiTrasmission Control Protocol (TCP)/IP di tutta la rete interna.

l’attività dell’host — a seconda dei dati disponibili e del livello di dettaglionecessario, un sensore di questo tipo può essere semplicemente un “let-tore” di file di log, oppure un complesso modulo di auditing per il ker-nel; ad esempio, il Sensore network accumula i log di un’applicazioneweb mentre il Sensore host cattura le sequenze di chiamate al sistemaoperativo dell’host che offre i principali servizi interni.

Il tipo di sensore caratterizza dunque il tipo di IDS: si parla quindi di IDShost-based o network-based, rispettivamente.

13


ANALIZZATORE

L’analizzatore implementa la funzionalità di ID ovvero individua l’eventualepresenza di intrusioni analizzando, tramite opportuni algoritmi, i dati prove-nienti dai sensori. Questo è di gran lunga il componente più importante inun IDS, non solo per la funzionalità ma perché gli algoritmi con cui esso èinstrumentato determinano il tipo di analisi e quindi il tipo di approccio.

Un analizzatore può individuare attacchi, noti gli attacchi stessi, oppuregenerici comportamenti non-normali (anomali), noto il comportamento norma-le della risorsa. Il primo approccio è implementato dagli analizzatori misuse-based mentre il secondo da quelli anomaly-based. Come si vedrà in seguito, idue approcci sono profondamente differenti.

BASE DI DATI E/O DI CONOSCENZA

Questo componente offre un servizio di memorizzazione di dati, per la mag-gior parte necessari al funzionamento dell’analizzatore. In generale può essereun DBMS o un semplice file, anche se esistono delle proposte per impiegareKnowledge Base System (KBS) per questa funzionalità. Come minimo questocomponente contiene informazioni su cosa si ritenga un attacco, in forma dipattern, o cosa un comportamento normale.

ESECUTORE

Un tradizionale antifurto avverte la presenza di un intruso tramite un avverti-mento (sonoro/visivo) oppure può intraprendere azioni più intelligenti, comeavvertire il proprietario dell’abitazione o una guardia. Il primo comportamen-to è di tipo passivo, si limita infatti a segnalare lasciando decidere a chi notal’avvertimento la politica di reazione. Il secondo tipo è invece di tipo attivo.

Esattamente allo stesso modo, in un IDS, l’esecutore può essere passivo oattivo a seconda del tipo di avvertimento implementato. Talvolta, specialmen-te nel secondo caso, può interagire con altri componenti software per intra-prendere azioni di avvertimento complesse, come ad esempio lo spegnimen-to del sistema compromesso o di altri sistemi potenzialmente messi a rischiodall’ultima intrusione).

UNITÀ DI GESTIONE E DI VISUALIZZAZIONE

Implementano l’interfaccia umano-sistema. Per gestione s’intendono tutte quel-le attività che modificano lo stato, gli ingressi e, in generale, la configurazio-ne dell’IDS. La visualizzazione riguarda invece la consultazione di informa-zioni sul sistema: dalla visualizzazione degli avvertimenti al controllo delleprestazioni on-line, ecc.

Come minimo, attraverso l’intefaccia/unità di gestione è possibile control-lare:

• l’avvio lo stop e il riavvio de(i componenti de)l sistema,

• sensibilità e frequenza di analisi,

14

Tassonomia

• aggiornamenti della base di dati/conoscenza,

• tipo di reazione agli attacchi e azioni da intraprendere (e.g., programmida invocare).

3.4 TASSONOMIA

Come anticipato, le caratteristiche dei diversi componenti principali determi-nano diverse classi di IDS. Sarebbe possibile trattare esaustivamente tutte letipologie di IDS attraverso diverse dimensioni tassonomiche; tuttavia, per loscopo di questo lavoro, è più utile presentare le tipologie di sistemi di seguitoanalizzate e, di fatto, valutate.

3.4.1 MISUSE VS. ANOMALY BASED

Rispetto alla modalità di analisi implementata nell’analizzatore è possibiledistinguere due tipologie di sistemi di ID.

MISUSE BASED

Un IDS si dice si dice misuse based se impiega una base di conoscenza (notaanche come “lista di firme”) per rilevare un attacco. Ciò che viene descritto inquesto tipo di sistemi sono i comportamenti anomali, memorizzati sotto formadi firme le quali vengono confrontate, dall’analizzatore, con gli eventi che siverificano durante l’attività della risorsa monitorata. Semplicemente, si rilevaun attacco ogni qual volta un evento corrisponde ad una firma o, più in generale,soddisfa delle caratteristiche espresse da quest’ultima. In genere esiste unafirma per ogni attacco noto, ma ci sono casi in cui si può rilevare più di unattacco con una singola firma (usando dei linguaggi di descrizione state basedcome STATL [?]).

La semplicità dell’approccio e la possibilità di contare su tecniche conso-lidate e ottimizzate di pattern matching rendono l’ID misuse-based la sceltapiù comune adottata dagli IDS moderni, soprattutto commerciali. La ricercain questo campo si appoggia infatti tecniche avanzate di specifica e riconosci-mento di pattern. Ad esempio in [?] si propone un metodo che affianca alla tra-dizionale descrizione degli attacchi al livello di byte con espressioni regolari,delle considerazioni di livello superiore basate sulla conoscenza del contestodella rete e dello stato della connessione. Un esempio di ottimizzazione si hain [?], che propone l’utilizzo di di alberi di decisione ricavati con un processodi clustering dalle firme per accelerare il processo di pattern matching.

ANOMALY BASED

Un IDS anomaly based cerca di costruire dei modelli sensati dell’attività nor-male (non-anomala) della risorsa, o del modo in cui viene utilizzata di norma.La base di conoscenza di un un IDS di questo tipo memorizza tali informa-zioni. L’analizzatore, come già accennato, si basa su tale conoscenza per in-dividuare delle deviazioni significative del comportamento monitorato, rispetto

15


a quanto noto. Quantitativamente, una deviazione è considerata significativase alcuni indicatori del comportamento attuale oltrepassano opportune soglie(threshold) di riferimento. Questo approccio prescinde completamente dallaconoscenza/descrizione degli attacchi e, in un certo senso, implementa l’ideaoriginaria di IDS.

La maggiore eleganza e robustezza dell’approccio farebbero pensare ad unmaggiore successo. Tuttavia, la difficoltà di trovare dei buoni modelli per de-scrivere il comportamento normale non ha ancora permesso agli IDS anomalybased di affacciarsi sul mercato: rimangono infatti un acceso ambito di ricerca.Le proposte note in questo campo sono radicate negli algoritmi di apprendi-mento e, in generale, nelle tecniche statistiche e di data mining. Lo scopo èquello di far apprendere al sistema i dati necessari per distinguere tra attivitànormali o anomale. Vista la sua rilevanza in questo lavoro l’approccio anoma-ly based sarà trattato in maniera più estensiva nella Sezione 3.6, presentandosia le tecniche generali sia lo stato dell’arte.

CONFRONTO

Gli approcci appena descritti costituiscono i due poli opposti nel campo degliIDS, sia per la loro intrinseca diversità sia per la totale simmetria dei rispettivipro e contro.

MISUSE DETECTION ANOMALY DETECTION

Progettazione e implementazione (dell’analizzatore)Si tratta di progettare o riutilizza-re un motore di (pattern) matching,quindi piuttosto semplice.

Piuttosto difficili da realizzare, siaper le scelte algoritmiche sia perla necessità ottimizzare le procedureeccessivamente complesse.

AccuratezzaBasandosi su tecniche deterministi-che tipo il pattern matching, a menoche le firme degli attacchi non sianoscritte in modo errato, presentano unnumero di falsi positivi trascurabile.

Presentano un alto numero di fal-si positivi, dovuti ad allarmi scattatiper comportamenti considerati non-normali perché mai visti durante lefasi di addestramento.

Semantica degli allarmiFornisce indicazioni precise su qua-le firma corrisponda all’evento cheha fatto scattare l’allarme. Ad ogniallarme è possibile associare unadescrizione.

Segnalano un comportamento “ano-malo”, ma le informazioni fornitea riguardo sono vaghe o del tuttoassenti.

Requisiti di aggiornamento(continua nella pagina successiva)

16

Tassonomia

(continua dalla pagina precedente)MISUSE DETECTION ANOMALY DETECTION

Richiedono studi su tutti i possibiliattacchi e si basano sull’ipotesi (fal-sa) di conoscere qualsiasi attacco. Co-me avviene per gli antivirus, il setdi firme dev’essere costantemente eautomaticamente aggiornato in mo-do da contenere quanti più attacchiconosciuti.

Relativamente agli attacchi, non ri-chiedono alcun tipo di aggiorna-mento dal momento che le informa-zioni mantenute riguardano il com-portamento normale, non l’attivitàanomala.

Tipo di attacchi rilevatiVengono rilevati soltanto gli attacchiper cui si dispone di almeno una fir-ma, quindi un attacco ad hoc ver-so un’applicazione oppure non anco-ra (o mai) rilasciato non può essererilevato.

Potenzialmente rilevano qualsiasicomportamento diverso da quellonormale, quindi, se gli attacchi sitraducono in comportamento diversoqualsiasi tipo di attacco è rilevato.

Addestramento e configurazioneNon richiedono alcun tipo di adde-stramento ma richiedono un accuratascelta di parametri di funzionamentoquali la sensibilità (si veda la Sezione3.5).

Non è possibile modellare tutto ilcomportamento normale ma affinchéil sistema abbia una conoscenza suf-ficientemente generica della “norma-lità”, gli algoritmi di apprendimentonecessitano un lungo addestramen-to. La regolazione dei parametri è“inclusa” nel training.

3.4.2 NETWORK VS. HOST

Anche se spesso compaiono più sfumature in questa dimensione, rispetto altipo di sensore impiegato, un IDS può è essere network-based o host-based. Aven-do già definito queste due categorie, nella sezione precedente, riportiamo diseguito i principali vantaggi e svantaggi di ognuna.

NETWORK-BASED

I sensori vengono posizionati in punti strategici della rete interna ed è di cru-ciale importanza che gli sniffer siano il più possibile invisibili e trasparenti al-l’attaccante il quale, in caso contrario, potrebbe prendere le contromisure; perquesto motivo le interfacce di rete dei sensori vengono configurate in “stealthmode” ovvero operano, senza indirizzo IP, e senza inviare alcun traffico.

Questi IDS hanno il fondamentale vantaggio di essere indipendenti dalsistema operativo in quanto si servono di pacchetti che provengono dalla retee non di una risorsa o dato di una specifica macchina. Inoltre il loro svilupponon impatta molto la struttura della rete preesistente in quanto consiste nelcollocare dei sensori (in genere puramente passivi) nei nodi strategici. Ciò fasi che i costi di gestione siano relativamente bassi perché pochi sono i moduli

17


da mantenere. Nelle moderne reti,tuttavia, con la presenza assai frequente diswitch, non è sempre facile individuare una giusta collocazione ai sensori.

Tale vantaggio ha come conseguenza degli svantaggi: tali IDS possono in-fatti rilevare solo gli attacchi “visibili” sul segmento di rete. Se per esempiola comunicazione è criptata anche la firma per un certo attacco è disponibile,questo non verrà rilevato. Dal punto di vista delle performance, se questi siste-mi devono cercare di rilevare anche gli attacchi frammentati (si veda la Sezione5.2.4) la complessità richiesta dalla ricostruzione risulta un problema più chereale (essendo questa operazione fattibile solo in teoria, con un elaboratore apotenza arbitraria).

HOST-BASED

Questi sistemi analizzano attività con enorme livello di dettaglio e precisionee consentono di determinare esattamente i processi coinvolti in un particola-re attacco. A differenza degli IDS network-based, quelli host-based possonoosservare direttamente gli effetti di un intrusione dato che hanno accesso emonitorano i file e i processi che normalmente sono il bersaglio designato ditali attacchi.

Questi sistemi sono stati i primi ad essere implementati, come primordialianalizzatori di log. L’implementazione di un IDS host-based, essendo forte-mente dipendente dal sistema operativo, comporta costi di sviluppo e deploysuperiori rispetto a quella di un IDS network-based, in quanto richiede l’in-stallazione e la configurazione su più macchine spesso eterogenee. Risultanoinoltre poco adatti agli odierni sistemi informatici, profondamente basati sullarete e su informazione fortemente distribuita in sorgenti paritarie.

3.4.3 CENTRALIZZATI VS. DISTRIBUITI

Il contesto di funzionamento ed il modello generico presentati nella Sezio-ne 3.3 fanno facilmente intuire come spesso gli IDS reali siano distribuiti. Inun framework come quello presentato risulta naturale la collaborazione traIDS anche diversi: network-based e host-based, per esempio. È chiaro che lacompresenza, nello stesso sistema informatico, di più IDS network-based e piùIDS host-based, può potenzialmente aumentare la qualità del monitoraggio,quindi il livello di sicurezza.

In letteratura questi sistemi possono prendere diversi nomi: IDS ibridi IDScollaborativi o IDS distribuiti. Al di là del loro nome, solitamente adottanorilevatori di intrusioni elementari che lavorano a differenti livelli (rete, host oapplicazione). Possono essere considerati dei “meta-IDS”.

Come delineato in Figura 3.2 il sistema ha spesso un manager a cui i rileva-tori comunicano i loro allarmi usando, ad esempio, un meccanismo di trasmis-sione a coda. Il manager usa metodi di aggregazione statistici, ad esempio, peraddivenire a una decisione sulla presunta intrusione.

Come si può intuire, i principali problemi di questi sistemi distribuiti sonole difficoltà nelle operazioni di

18

Tassonomia

Analizzatore e motore d'inferenza GLOBALE

Applicazione regole

Aggregazione

Analizzatore e motore d'inferenza LOCALE

Applicazione regole

Aggregazione


Applicazione regole

Aggregazione


Applicazione regole

Aggregazione

IDS 1 IDS k IDS n

. . . . . .

DIDS

Propagazione e traduzione

Sensore Sensore Sensore. . . . . .

Gestione evisualizzazioneDatabase

FIGURA 3.2: Modello generico di un IDS distribuito/collaborativo.

I. normalizzazione (del formato) delle sorgenti di informazione,

II. aggregazione e correlazione,

III. prioritizzazione delle informazioni.

Infatti, non solo i diversi esecutori possono avvertire in modo/formato di-verso, spesso è necessario decidere quali allarmi considerare e quale importanzadare ai diversi allarmi. Spesso questi ultimi problemi possono essere risoltisoltanto dipendentemente dal contesto, nota la (topologia del)la rete. La Se-zione 3.6.2 definisce il problema della correlazione e della collaborazione trasistemi di ID, presenta alcune proposte notevoli riguardanti correlazione eaggregazione di allarmi e fornisce una breve panoramica dei sistemi automa-tici di correlazione. Tra i sistemi esistenti, presentati nella sezione successiva,alcuni implementano blandi supporti per aggregazione, sommarizzazione eanalisi statistica.

3.4.4 PANORAMICA SUI SISTEMI ESISTENTI

Dopo la pubblicazione dell’articolo di J. Anderson [?] nel 1980 e dei lavori diD. Denning [?] nel 1987, i primi IDS (commerciali) sono apparsi sul mercatonegli anni novanta: il primo fu Stalker, un sistema host-based degli HaystackLabs. La Figura 3.3 mostra i prodotti più importanti rilasciati dal 1980 al 2000.

19


1999: boom degli IDS

1998

19971996199519941993199219911990

1989: Haystack Lab.

1988

1987

198619851984

1983

198219811980

1999

1998: Centax Corporation

1997, Real Secure: ISS

1994: Wheel Group

1991, Air Force: ASIM

1990, Heberlein: "Network Security Monitor"

1989

1988: progetto Haystack

1987, Denning: "An intrusion detection model"

1984, Denning: modello IDES. Sviluppo IDES.

1983: primo IDS presso SRI

1980, Anderson "Computer security threat monitoring and surveillance"

FIGURA 3.3: Storia e passi fondamentali dalla pubblicazione dell’articolo di J.Anderson al 2000.

Nel 2000 si contavano circa un centinaio di prodotti, commerciali e non[?]. Alla fine del 2004 se ne contavano più di 130 [?]. Senza la presunzionedi offrire una panoramica completa, segue una breve overview sugli attualisistemi effettivamente utilizzabili.

SISTEMI COMMERCIALI E DI PUBBLICO DOMINIO

Segue una breve descrizione dei più comuni e famosi sistemi commercialie di dominio pubblico. Oltre a quelli citati esistono una moltitudine di si-stemi “minori”, specialmente host-based, studiati per monitorare l’attività diworkstation o personal computer [?].

Tripwire Non è esattamente un sistema di ID; è piuttosto un tool per l’a-nalisi degli effetti di un’intrusione su un host. Tripwire mantiene un databasedelle informazioni critiche residenti sulla macchina, con rispettive checksum,in modo da poter rilevare alterazioni in tali file. Il sistema si limita a riportareun elenco dei file modificati lasciando all’utente il compito di filtrare i reportnon interessanti. La configurazione di Tripwire può risultare molto complicataper utenti non esperti, soprattutto se si desidera proteggere il database delle si-gnature in modo da evitare tentativi di compromissione. Tripwire è disponibileanche in versione open-source.

Prodotti Cisco System Dagli anni ’90 ad oggi la famiglia di prodotti Ci-sco copre entrambi i domini host e network. I sistemi network-based sonoben integrati con il resto dei dispositivi di rete (e.g., firewall, router): sia perraccogliere informazioni sull’attività di rete sia per la messa in atto di con-tromisure (attive) nel caso di intrusioni (e.g., riconfigurazione dinamica delletabelle di routing). Per gli attacchi rilevati con buona accuratezza è possibi-le abilitare funzioni di protezione automatiche per bloccare dinamicamentel’attività dell’aggressore verso un certo host/router. Chiaramente una similefeature deve essere utilizzata con molta cautela, dal momento che potrebbefacilmente bloccare attività lecita.

20

Tassonomia

RealSecure Prodotto da Internet Security Systems (ISS) è una soluzione real-time integrata host/network con relativa interfaccia di amministrazione perl’analista. L’architettura permette il deploy di sensori/analizzatori di rete di-stribuiti (misuse-based) e la configurazione delle azioni da svolgere in caso diattacco. I sensori/analizzatori host analizzano i log di sistema per la ricerca dievidenti segni di attività anomala: anche per questi analizzatori è possibile de-finire le azioni da svolgere (ad esempio, la distruzione dei processi sospetti).L’integrazione e la centralizzazione del controllo sono il punto forte di questoprodotto.

Snort È lo standard de facto per l’ID open-source. Stando al sito web ufficia-le [?], Snort è un IDS open-source che beneficia delle più moderne tecnichedi detection: ispezione a livello applicativo, anomaly detection, misuse de-tection. La parte misuse, la prima sviluppata, è basata su un linguaggio perdefinizione di regole e vanta di un database di firme estremamente popolato.Attualmente è il sistema di ID più diffuso nel mondo.

I sensori di Snort sono progettati per essere del tutto generici: è infatti pos-sibile costruire sia analizzatori host-based che network-based. Tuttavia, fino-ra sono stati sviluppati solo analizzatori network-based basati sul formatoPcap. L’architettura modulare e basata su preprocessori e plug-in (per l’a-lert manager) ha permesso velocemente lo sviluppo di estensioni per la ge-stione dell’output in formati proprietari/aperti (MySQL, American Standardfor Information Interxchange (ASCII), Comma Separated Values (CSV), eXtensibleMarkup Language (XML), Intrusion Detection Message Exchange Format (IDMEF),ecc.) e, soprattutto, di analizzatori personalizzati (ad esempio, l’aggiunta di unmotore anomaly-based).

Snort è utilizzabile con DShield un sistema collaborativo globale per laraccolta di informazioni sull’attività degli IDS dislocati su Internet. DShieldsarà descritto in seguito.

PROTOTIPI

Segue una breve descrizione dei più importanti prototipi apparsi in letteratu-ra, limitatamente ai soli tool rilasciati. Alcuni prototipi non sono citati perchémenzionati e introdotti nel seguito del documento. Altri progetti, di cui alcuniormai conclusi, sono riportati su [?; ?; ?].

NIDES (EMERALD) Sviluppato da Stanford Research Institute (SRI) con ilnome di NIDES [?; ?], oggi EMERALD [?] è un sistema integrato host/networkche, allo stato attuale, implementa le più recenti tecniche di anomaly/misusedetection. L’obiettivo di EMERALD è quello di soddisfare le esigenze di reti digrandi dimensioni di livello enterprise, con sensori distribuiti completamenteindipendenti e un sistema di reporting centralizzato; le informazioni sono ag-gregate in modo gerarchico (su tre livelli: servizio, dominio, rete), fino al nodocentrale. EMERALD è un esempio della direzione più probabile nello svilup-po di IDS integrati, capace di rispondere alle crescenti difficoltà nel rilevareattacchi sempre più complessi

21


IDIOT Successivamente assorbito da altri progetti come [?; ?], IDIOT [?] eraun sistema di misuse detection proof-of-concept. Sostanzialmente si tratta diun motore di pattern matching con il quale sono state valutate le prestazionidi diversi algoritmi di misuse detection.

GrIDS È un progetto ormai concluso basato sull’uso di grafi per la rappre-sentazione di attività distribuite su larga scala. GrIDS [?] è stato progettato perindividuare attacchi su reti anche molto estese in cui gli host corrispondonoai nodi del grafo. I grafi sono confrontati con un insieme noto di “scenari diattacco” in stile misuse-based.

NADIR Questo sistema è stato provato in casi di studio reali in settori com-merciali e fiscali. NADIR [?] si basa su informazioni raccolte da log di sistema(profili e history utente), di rete e di autenticazione (Kerberos): cerca di indi-viduare automaticamente tracce di incidenti informatici. Il motore è basato suun database di regole.

SISTEMI DISTRIBUITI

Segue una breve descrizione delle proposte, tutte di pubblico dominio, disistemi di ID distribuiti, senza la pretesa di presentarli in modo esaustiva.

DShield Nato nel 2000, oggi riceve più di 30 milioni di report di attacchi almese. Gli amministratori che desiderano utilizzare DShield [?] per riportaregli (alert degli) attacchi rilevati dai propri IDS e firewall possono contare suclient per i più comuni prodotti: Windows firewall, ZoneAlarm, BlackICE, Sy-gate personal firewall, Snort, Cisco, eccetera. I client si occupano di “norma-lizzare” nel formato interno di DShield e li inviano semplicemente via e-mailai server. È possibile anche il report manuale via Web e via e-mail e, per i pro-dotti non ancora supportati, DShield offre assistenza alla creazione di scripttraduttori.

Gli alert e i log ricevuti vengono aggregati per produrre report nazionali/-globali, grafici e liste dei nodi e dei servizi più attaccati. Tutte queste informa-zioni sono consultabili liberamente via Web con in più la possibilità di osser-vare l’attività di un particolare insieme di indirizzi. DShield permette ancheazioni attive nei confronti degli aggressori: con un sistema chiamato “Fight-Back” l’utente dà il permesso di comunicare i propri log all’Internet ServiceProvider (ISP) degli aggressori.

myNetWatchman Come DShield anche myNetWatchman [?] aggrega re-port provenienti da sorgenti distribuite. Gli obiettivi di questo sistema sonotre:

I. evitare falsi positivi riportati in grande quantità soprattutto dai prodottiad uso personale. Tuttavia questo problema è difficilmente risolvibile vi-sto che, senza informazioni sul contesto in cui i log sono stati generati, è

22

Valutazione degli IDS

difficile distinguere un falso positivo da un vero positivo semplicementeosservando il report.

II. Propagare i report alle autorità competenti che, come nel caso di DShield,possono essere ISP o amministratori di rete.

III. Minimizzare i requisiti del processo di reporting.

Il numero di prodotti supportati da myNetWatchman è inferiore rispetto alnumero di client per DShield: i client, in cui non sono inclusi quelli per Sygatee Norton peroonal firewall, sono comunque gratuiti. Diversamente da DShield,i log sono inviati in tempo reale e aggregati. Il sistema prevede una modi-fica automatica del grado di “fiducia”, a seconda di quanta attività sospettaperviene da una certa famiglia di IP.

Come per DShield, i report aggregati sono consultabili via Web; in più, my-NetWatchman offre informazioni più dettagliate, come la data e l’ora di ogniattività riportata. Altri sistemi distribuiti dello stesso livello di quelli appe-na presentati sono DeScan.net e Symantec DeepSight™ (precedentemente diSecurityFocus, ora è commerciale).

3.5 VALUTAZIONE DEGLI IDS

Valutare l’efficacia di un IDS significa valutarne le capacità di distinguere cor-rettamente gli attacchi dai comportamenti normali. Come per qualsiasi altro si-stema, per confrontare l’efficacia di diversi IDS è necessario poter ripetere gliesperimenti nelle medesime condizioni e calcolare opportuni indicatori a fron-te dei medesimi stimoli. La valutazione dell’efficacia di un IDS non è banale ecostituisce tutt’oggi argomento di ricerca aperto; è necessario tenere conto didiversi parametri e condurre sessioni di test che possono durare anche moltoa lungo. Il problema più difficile rimane comunque, come sottolineato in [?],la diversa semantica che ogni IDS può dare all’evento di avvertimento; non èsempre chiaro infatti il significato dato all’evento di alert, soprattutto quandosi parla di IDS con sensori completamente diversi (host o network).

3.5.1 PARAMETRI D’INTERESSE

Misurare in maniera quantitativa la bontà di un IDS significa osservare il si-stema in fase operativa tenendo traccia degli eventi da esso riconosciuti/ri-scontrati. Nella più semplice delle analisi, tali eventi possono essere di quattrotipi:

VP (Vero Positivo) quando l’IDS riporta (almeno) un alert per un evento diattacco;

FP (Falso Positivo) se l’IDS riporta un alert quando invece di un evento nor-male;

VN (Vero Negativo) per ogni evento normale per il quale l’IDS non riporta al-cun alert;

23


FN (Falso Negativo) per ogni evento di attacco per il quale l’IDS non riportaneanche un alert.

A partire dal conteggio di questi eventi si calcolano solitamente degli in-dicatori (normalizzati) di sintesi che, a seconda del contesto, possono averenomi diversi sebbene si tratti sempre dello stesso concetto. Nel caso degli IDSprendono il nome di Detection Rate (DR) e FPR e sono definiti come:

FPR :=FP

FP + V N

DR :=V P

V P + FN

Entrambi esprimono una misura di efficacia in [0, 1]. La DR, detta anchecompletezza, esprime il numero di attacchi rilevati dal sistema nell’insieme.FPR indica invece il grado di errore commesso nel riportare allarmi, ovveroquanti allarmi sono falsi. In alternativa è possibile misurare, l’accuratezza (oprecisione), definita come:

A :=V P

V P + FP

La DR è l’equivalente al concetto di “richiamo” in un sistema di InformationRetrieval (IR) mentre FPR può essere intesa alla stregua della “precisione”. UnIDS è accurato se genera pochi falsi allarmi (accuratezza alta). Un IDS idealeha DR = 1 e FPR = 0, ovvero rileva tutti gli attacchi senza riportare neanche unfalso allarme. Tali performance non sono ovviamente raggiungibili, soprattuttoperché all’aumentare della DR cresce inevitabilmente anche FPR.

Sia FPR che DR dipendono dalle caratteristiche intrinseche degli algorit-mi impiegati per la rilevazione. Nello specifico, detta s la sensibilità, si puòscrivere:

FPR = FPR(s)

DR = DR(s)

In Figura 3.4 è tracciato un andamento immaginario di tali funzioni, al va-riare della sensibilità. In un IDS di tipo anomaly detection, dovrebbe esseresempre possibile tarare la sensibilità di un IDS fino ad ottenere valori di effica-cia desiderabili. Come mostrato in Figura 3.4, nel caso in cui un falso positivosia grave quanto un falso negativo, la situazione ideale si ottiene in corrispon-denza di FPR = FNR = 1 (dove per FNR si intende la percentuale di fal-si negativi). Per “gravità” di un FP , per esempio, s’intende il costo indottodalle conseguenze di aver rilevato un falso positivo (non necessariamente intermini monetari). Si noti che l’analisi ROC non ha senso per un IDS di tipomisuse.

24

Approcci e strumenti: stato dell’arte

0.0 0.2 0.4 0.6 0.8 1.0

0.0

0.2

0.4

0.6

0.8

1.0

Sensitivity

FP

R (

−)

e F

NR

(−

−)

FIGURA 3.4: Andamento della percentuale di falsi positivi e falsi negativi al variaredella sensibilità di un sistema di intrusion detection.

ANALISI ROC

Un’analisi molto utile che viene condotta per valutare la bontà di un qualsia-si strumento di classificazione o di predizione è l’analisi ROC. Nata e utiliz-zata nell’ambito della teoria dei segnali, si basa sull’osservazione e sul con-fronto di curve ROC, che altro non sono che dei grafici parametrici che de-scrivono l’andamento di DR al variare di FPR. In Figura 3.5 è tracciata unacurva ROC d’esempio (dati reali, tratti da http://en.wikipedia.org/wiki/Image:Roc.png).

L’andamento di una curva ROC è intuibile dalla Figura 3.6, in cui lo spa-zio degli eventi è rappresentato dall’asse reale e il numero/percentuale diFN/FP/V N/V P è indicato dall’area sottesa sotto ogni curva.

Il significato di una curva ROC è piuttosto semplice: più la curva è “vicina”alla bisettrice e più il classificatore/predittore sta lavorando in maniera total-mente casuale. Infatti, in corrispondenza della bisettrice DR

FPR = 1, pertantola probabilità di rilevare un vero positivo piuttosto che un falso positivo è lastessa. Per confrontare la bontà di due o più IDS è quindi sufficiente registra-re DR ed FPR in condizioni operative, al variare della sensibilità, e vederequale sistema presenta la curva che sottende un’area maggiore. Si noti che nelcaso in cui il costo di un FP , CFP sia diverso da quello di un FN , CFN , ilcriterio di confronto appena citato va raffinato.

3.6 APPROCCI E STRUMENTI: STATO DELL’ARTE

Il già menzionato Snort, rappresentante della categoria misuse based, utilizzaun “semplice” analizzatore basato su pattern matching [?]. Gli unici migliora-menti che si possono apportare a strumenti misuse based riguardano l’aumen-

25




FIGURA 3.5: Curva ROC d’esempio. I dati mostrati in questo esempio sono reali e sonotratti da http://en.wikipedia.org/wiki/Image:Roc.png.

to di performance degli algoritmi di matching. Risulta invece più interessanteanalizzare lo stato dell’arte delle tecniche di anomaly detection, non solo perlo scopo di questo lavoro ma per l’accesa attività di ricerca.

Nota Nel seguito si farà uso di terminologie e concetti tratti dalla letteraturastatistica e del machine learning [?], una branca dell’intelligenza artificiale [?]che ha a che fare con la creazione e lo studio di algoritmi di apprendimento(computazionalmente trattabili). I concetti più importanti saranno introdotti ese ne daranno comunque dei riferimenti aggiornati.

3.6.1 ANOMALY DETECTION

L’idea originaria di un IDS è quella di rilevare anomalie. È già stato presentatoil concetto di anomaly detection; in questa sezione si tratteranno invece i temipiù attuali, ovvero gli approcci sperimentati, le tecniche e gli algoritmi.

NETWORK ANOMALY DETECTION

Le tecniche in letteratura da noi analizzate possono essere raggruppate in clas-si differenti. Di seguito proponiamo le più notevoli, suddivise in maniera nonnecessariamente esaustiva né tassonomica.

Metodi statistici Il comportamento normale di un sistema/soggetto è de-scritto in relazione a valori di particolari indicatori. La teoria della stima e del-

26



FIGURA 3.6: Interpretazione di una curva ROC in termini di FP/FN/V P/V N .

la verifica di ipotesi [?] permette quindi di confrontare le attività stabilendo sepossono essere generate dalla stessa distribuzione.

Più precisamente, nel campo dell’ID network based, l’interesse principaleè quello per algoritmi che analizzano serie temporali, visto che lo stream direte è di fatto una serie temporale. Quindi, in linea di massima, una tecnica èutile in questo campo se è in grado di rilevare dei campioni che deviano dallanormale serie temporale.

Si noti che, è sbagliato pensare che sia sempre necessario effettuare un’a-nalisi statistica a priori per calcolare degli indicatori o, comunque, stabilire lecaratteristiche della “normalità”. In [?] si fa notare come sia possibile indivi-duare anomalie basandosi sul fatto che, su un insieme di dati sufficientemen-te grande, le anomalie sono molto meno frequenti della normalità. Quindi èpossibile, in linea teorica, individuare anomalie senza un insieme di dati “pu-lito”. Un esempio ancora più lampante è costituito da SmartSifter [?], il qualenon necessita che vengano definiti un insieme di profili. Bensì è progettatoper apprendere la distribuzione dei dati autonomamente (in maniera cioè nonsupervisionata).

Il già citato Next-generation Intrusion Detection Expert System (NIDES) [?] faampio uso di tecniche statistiche nella sua componente host based; tuttavia, iconcetti alla base sono simili a quelli impiegati per la parte di rete, non solo diquesto sistema. Mentre i log di sistema vengono generati si calcolano dei pun-teggi, aggregati di altri indicatori di utilizzo risorse. L’evoluzione di tali soglieè controllata continuamente e, qualora ecceda dei valori limite, viene lanciatoun alert. Un altro metodo, basato sul classico test chi-quadro, è presentato in[?].

Altri metodi come la finestra di Parzen [?] non risultano in nessun modoadatti all’anomaly detection, per via della loro pesantezza computazionale che

27


li rende inutilizzabili in pratica.SmartSifter, base dell’analizzatore del prototipo di IDS network-based che

verrà trattato nella Sezione 5.2, sembra l’unico algoritmo adatto. Purtroppo in-fatti, le altre tecniche, oltre a non essere adatte a sistemi il cui profilo di utilizzonormale cambia rapidamente, hanno il limite di non considerare informazionitemporali, e di rimanere per lo più insensibili all’ordine degli eventi. Un erra-to valore iniziale delle soglie, inoltre, potrebbe causare il mancato rilevamentodi attacchi al sistema.

Analisi dei protocolli I protocolli di rete sono ben noti e perfettamentespecificati. È facile dunque stabilire con buona confidenza se un pacchettorispetta il protocollo o meno.

Packet Header Anomaly Detection (PHAD) [?; ?] è un semplice analizzatoreprotocollare che rileva pacchetti maliziosi sulla base di informazioni estrat-te dal solo header dei pacchetti TCP/IP. Questa tecnica tecnica richiede unafase di addestramento durante la quale, per dei campi selezionati, il sistemaapprende degli indicatori di “normalità”. Se i pacchetti analizzati nella faseoperativa non rientreranno negli intervalli di tali indicatori verranno segnaticome anomali.

Tuttavia questo sistema si basa sull’ipotesi, oggi sempre meno vera, che unattacco venga inserito in uno o più pacchetti con intestazione anomala.

Apprendimento supervisionato Sono algoritmi che prevedono una fasedi addestramento supervisionata ovvero generano (imparano) modelli sullabase di un insieme di dati di ingresso etichettati con i corrispondenti dati diuscita desiderati (si veda la Figura 3.7). Solitamente i dati sono etichettati ma-nualmente, da un umano (e.g., classi, intervalli), oppure le etichette sono ilrisultato di un ulteriore algoritmo (e.g., cluster generati). Le reti neurali arti-ficiali sono un esempio tra gli algoritmi supervisionati più diffusi. L’onerosaattività di classificazione rende questi algoritmi poco utilizzabili in pratica e si-curamente poco adatti ai sistemi di ID, anche per il problema dell’overfitting,cui questi algoritmi sono esposti.

Tuttavia, esistono dei risultati interessanti sono riscontrabili se si aggiungedella conoscenza pregressa sul dominio applicativo ed ulteriori tecniche perridurre la dimensione degli input [?; ?; ?]. Uno strumento di test [?] implemen-ta un sistema basato su regole [?] per rilevare connessioni TCP anomale.

Apprendimento non supervisionato Il tipo di addestramento previstoper questi algoritmi è di tipo non supervisionato. I criteri secondo cui ven-gono generati (imparati) i modelli sono intrinseci o estratti dai dati stessi. Adesempio, un algoritmo di clustering non raggruppa gli ingressi sulla base dietichette ma sulla base del loro “naturale” raggruppamento. Con un algoritmodi questo tipo si possono apprendere modelli più complessi rispetto a quelliche costruibili con algoritmi supervisionati. Il motivo è l’esplosione della com-plessità computazionale di un algoritmo supervisionato quando le dimensionidegli ingressi crescono.

28


Dati(etichettati)

Etichettatura Dati grezzi

Apprendimento supervisionato

Regole Classificazione

12

3

4

5

6 (nuovi dati)

Dati classificati

7

1. Fase di addestramento 2. Fase operativa

FIGURA 3.7: Schema di un generico algoritmo di apprendimento supervisionato.

Modelli(es. cluster)

Apprend. non superv.(es. clustering)

Dati grezzi

Etichettatura automatica

Pesi Classificazione

12

3

4

5

6 (nuovi dati)

Dati classificati

7

1. Fase di addestramento 2. Fase operativa

FIGURA 3.8: Schema di un generico algoritmo di apprendimento non supervisionato.

È possibile accomunare le caratteristiche principali degli approcci che se-guono (si veda la Figura 3.8). In un IDS basato su apprendimento non super-visionato, si costruiscono e si memorizzano modelli sulla base delle caratteri-stiche degli ingressi. In fase operativa i nuovi dati provenienti dai sensori ven-gono processati e ne viene valutata l’aderenza ai modelli appresi. L’anomaliaè quindi un dato che devia (outlier) troppo dai modelli memorizzati. La fasedi addestramento coincide spesso con algoritmo di clustering (e successiva fa-

29


se di etichettatura automatica). La fase operativa è solitamente implementatacon un classificatore, che usa i cluster come l’insieme di classi etichettate note.

Nessuno degli approcci che seguono considera il contenuto (payload) deipacchetti nel processo di clustering: si limitano alle caratteristiche dello hea-der. Le uniche eccezioni sono: l’approccio proposto in [?; ?], PAYL [?] e, inminor misura, [?].

L’uso delle Self Organizing Map (SOM) per l’ID si è rivelato piuttosto “invoga” negli ultimi anni, ma non solo. Esistono risultati, [?], che mostrano comequesti algoritmi possano essere resi più efficienti per l’ID.

NSOM Ispirato da [?], il prototipo proposto in [?] impiega una SOMper rilevare attacchi all’interno di connessioni TCP. È capace di individuareattacchi di Denial of Service (DoS).

INBOUNDS Basato sulla distanza dalla Best Matching Unit (BMU) e suuna, quasi mai vera, ipotesi di gaussianità. Presentato in [?; ?], il prototipo ef-fettua una normalizzazione di alcune caratteristiche (categoriche) estratte daipacchetti (raggruppati per connessione). Se, per qualcuna di queste caratteri-stiche, un pacchetto risulta troppo distante dal neurone vincitore della SOM,allora è anomalo. Si noti che l’ipotesi di gaussianità non è affatto sempre vera,neanche per caratteristiche non categoriche.

MINDS Limitato dall’essere di tipo batch e dall’ingnorare il payload, [?]è stato sperimentato con successo come modulo di Snort; è capace di rileva-re anche attacchi non noti, purché questi sfruttino lo header del pacchetto.Agisce su finestre di temporali di dieci minuti, all’interno delle quali cerca diindividuare eventuali outlier.

HOST ANOMALY DETECTION

Si propone ora una panoramica, non esaustiva né tassonomica, delle tecnichee degli approcci applicabili all’host anomaly detection. Essendo questo tipo diIDS i primi ad essere studiati, si trovano delle tecniche schematizzate in [?] ein [?].

Tecniche statistiche Nel già accennato NIDES (che comprende anche unaparte host) is fa uso di diversi metodi statistici. I principali sono:

• si calcolano delle soglie entro cui il comportamento del sistema è consi-derato normale;

• simile al precedente, si basa sul calcolo di media e varianza campionarieche definiscono un intervallo di confidenza entro il quale il sistema si stacomportando in maniera anomala;

Atri approcci puramente statistici/matematici presentati a livello moltoteorico hanno dato risultati sperimentali molto promettenti [?; ?; ?]. Tuttavia,

30


nessuno di questi metodi considera correlazione di eventi nel tempo: gli eventiin un sistema sono invece spesso delle sequenze e considerarli atomici può farperdere molta informazione.

Algoritmi di apprendimento supervisionato Le principali proposte so-no l’impiego di (1) tecniche di data mining e (2) reti neurali. (1) per un’ana-lisi sulle caratteristiche da monitorare [?][?] e (2) per analizzare le interazionidell’utente in termini di certe caratteristiche.

L’uso di reti neurali multi-livello in questo campo è stato implementato inNeural Network Intrusion Detection (NNID) [?; ?] e in altre proposte [?; ?]. Que-sto tipo di reti, che consente anche di mantenere uno stato, è stato utilizzatoper analizzare delle sessioni di interazione utente-host. Tuttavia è un’analisi delgenere è priva di senso se l’inseme delle variabili da osservare (arbitrario) èprivo di senso.

Altre tecniche

Liste bianche — Questi metodi sono basati sul filtraggio a cascata di unostream di dati. I filtri sono in realtà degli accettori di linguaggi basati supattern che lasciano passare solo se trovano corrispondenza in una o piùliste bianche. Gli scarti del filtraggio dovrebbero essere solo gli elementisospetti. Si tratta, tuttavia, di una classificazione (supervisionata) mol-to rudimentale, forse più utile in un’attività di post-elaborazione degliallarmi.

Alterazione di file — Sulla base del calcolo e sul mantenimento di un databasedi checksum dei file/programmi critici, questo sistema monitora ed è ingrado di individuare cambiamenti. È molto utile per rilevare l’installa-zione non autorizzata di programmi o il tentativo di nascondere dellebackdoor. Tuttavia, quest’analisi è limitata alla modifica, quando inveceun’attacco può essere portato a termine con la sola esecuzione e letturadi file.

Apprendimento non supervisionato — Le proposte di questo tipo non sononotevoli come per il caso network-based: vanno dall’applicazione di al-goritmi di clustering per raggruppare profili di attività simili [?] all’im-piego di algoritmi genetici [?] per l’analisi di sequenze di chiamate.

Come illustrato in seguito, pare che l’unica tecnica di questo tipo chepossa tornare utile sia la costruzione di modelli di Markov.

Approcci basati sulle chiamate di sistema In questo paragrafo sono in-trodotti per linee generali i due algoritmi principali, in ordine cronologico, cheprendono in considerazione le anomalie a livello di (sequenze di) chiamate disistema.

TIDE È basato su un dizionario, pre-costruito, di sequenze ammesse.Con un throughtput massimo di 1250 chiamate al secondo è possibile con-

31


frontare nuove sequenze con il dizionario: ogni sequenza che non trova corri-spondenza è segnata come anomala. Le chiamate sono processate per mezzodi una finestra a scorrimento di dimensione configurabile: la dimensione dellasequenza. L’algoritmo è presentato in [?].

Anche se gli esperimenti principali considerano solo la sequenzialità trauna chiamata e le successive, sono state sviluppate delle varianti [?; ?] dell’al-goritmo per considerare le sequenze raggruppate per lunghezza e penalizzaremaggiormente le sequenze rare.

RIPPER È un algoritmo che è stato studiato per l’estrazione di regole datesto libero [?; ?]. Considerando la sequenza di chiamate come testo è possi-bile usare questo algoritmo per estrarre pattern rappresentativi del comporta-mento di un programma. L’approccio presentato in [?] spiega come utilizzareRIPPER per generare e ordinare classi di regole in base alla frequenza. la fasedi detection è fatta in base ad un punteggio calcolato per ognuna delle classi.

Altri approcci sono stati applicati come la specifica del linguaggio delle chia-mate di sistema per ogni programma per mezzo di automi a stati finiti (deter-ministici e non deterministici) [?; ?]. La versione probabilistica di tale approc-cio è stata tentata specificando il linguaggio per mezzo di modelli di Markovnascosti [?].

Approcci basati sugli argomenti delle chiamate di sistema Nessu-no dei metodi elencati in precedenza effettua un’analisi degli argomenti dellechiamate di sistema. Gli argomenti delle chiamate di sistema contengono mol-tissime informazioni utili alla rilevazione di anomalie. Infatti non è detto cheanalizzando una chiamata (o una sequenza) si possa distinguere tra un’invo-caziona “normale” ed una “non normale”. Esiste, per esempio, una tipologiadi attacchi, i mimicry attacks [?], basati sull’invocazione di chiamate di sistemarispettando l’ordine di esecuzione normale ma con contenuto degli argomentiaccuratamente studiato.

L’analisi degli argomenti di sistema aumenta moltissimo la complessitàcomputazionale di uno strumento di ID host-based, nonché la difficoltà didesign e di modellazione del comportamento. Questo è il motivo principaleper cui, oltre al prototipo che verrà presentato nella Sezione 5.1, esistono soloaltre due proposte (tra l’altro, molto recenti).

libAnomaly Nella forma di una libreria C++ disponibile su [?], l’Universityof California Santa Barbara (UCSB) ha implementato una serie di primitive uti-lizzabili per analizzare le chiamate di sistema dal punto di vista degli argo-menti: impiegata da un software proof-of-concept, syscallAnomaly, permettedi rilevare anomalie a fronte di una fase di addestramento su dati Snare oBasic Security Module (BSM).

Ogni tipo di argomento di ogni chiamata viene modellizzato in modo diver-so. Sono stati considerati i seguenti modelli:

Lunghezza delle stringhe — Le stringhe vengono modellizzate in termini di

32


media e varianza campionarie. In fase di rilevazione viene fatta inferenzasulla lunghezza della stringa rispetto ai parametri del modello.

Distribuzione dei caratteri — Viene approssimata la distribuzione (discreta)dei caratteri e, in fase di rilevazione, si effettua un test chi-quadro (diPearson) per controllare l’aderenza alla distribuzione approssimata.

Modello d’inferenza strutturale — Le stringhe vengono compresse in due fasi,fino ad essere ridotte a pochi caratteri ritenuti “significativi”. Attraversol’uso di un modello di Markov nascosto [?], viene costruita la grammati-ca probabilistica [?] che avrebbe dato luogo alla stringa. In fase di rileva-zione si controlla che la stringa appartenga al linguaggio generato dallagrammatica.

Ricerca di sotto-stringhe — In fase di detection viene stabilito, con un test sta-tistico, se un certo argomento è da considerarsi (o contiene) un token: intal caso viene aggiunto ad una lista. In fase di detection, per i soli token,viene controllata l’appartenenza a tale lista.

Ogni argomento risulta quindi più o meno aderente al modello di normali-tà appreso. Ogni chiamata risulta più o meno aderente a seconda della sommadei contributi dell’aderenza dei singoli argomenti. Tutto ciò si traduce in unasoglia, calcolata per ogni nuova chiamata.

LERAD È un algoritmo che cerca di indurre/apprendere delle regoledagli argomenti delle chiamate “normali” di sistema [?]. Vengono costruitidue gruppi di regole, che possono essere usati in modo combinato in fase didetection:

Sequenze — Su una sequenza finita di chiamate per modellare, il fatto chedopo le chiamate open, close, per esempio, in posizioni precise della se-quenza, allora è probabile che in posizioni successive si troverà un’altrachiamata, di tipo munmap, per esempio.

Argomenti — Banalmente memorizza regole del tipo:

nome_chiamata⇒ set_valori_arg_1, set_valori_arg_2, ...

fino ad un massimo di cinque argomenti.

libAnomaly non prende in considerazione le chiamate immerse nel conte-sto di esecuzione: manca, ancora, il concetto di sequenza.

L’approccio più recente in questa categoria è stato sviluppato presso il Po-litecnico di Milano e, vista l’importanza per questo lavoro, verrà presentato indettaglio nella Sezione 5.1.

33


KB sensori

Normalizzazione Pre-filtraggio Aggregazione Verifica

Ricostruzione scenari

Correlazione

DB asset

Analisi impattoPrioritizzazione

Visualizzazione

.

.

.

FIGURA 3.9: Modello generico di riferimento per il problema della correlazione dieventi (allarmi) in un sistema informatico.

3.6.2 ANALISI E CORRELAZIONE DI ALLARMI: INTRODUZIONE E

STATO DELL’ARTE

Con abuso di linguaggio, per correlazione intendiamo la possibilità di osserva-re tutti gli eventi (allarmi) provenienti da tutti i sistemi in un solo nodo, in unostesso formato e, da questo punto di vista, essere capaci di comparare e processaretali dati per produrre informazioni di livello più alto. Nel campo degli IDS, loscopo ultimo, come già accennato, è quello di aumentare le capacità e la qua-lità di detection ma anche poter prioritizzare gli eventi a seconda del contestoin cui accadono. Questo genere di attività va spesso sotto il nome di securityinformation monitoring: nell’ambito di questo lavoro, le informazioni rilevantisono gli eventi di attacco. Il modello molto generico dei processi, del flusso diinformazioni e delle entità coinvolte in questo tipo di problema è mostrato inFigura 3.9. Nel seguito si farà riferimento a questo modello.

L’analisi degli allarmi o, più in generale, degli eventi di uno o più IDS (o al-tri dispositivi) è un’attività quasi del tutto manuale. Lo scopo principale di que-st’attività è contestualizzare gli allarmi e, quindi, riuscire a distinguere quelli ri-levanti da quelli non rilevanti. Nel caso degli IDS, non solo si ha a che fare construmenti non ideali, e che quindi producono dei falsi positivi o dei positivinon rilevanti, ma in una rete reale ci sono più IDS che lavorano contempora-neamente; possono monitorare attività diverse (network e host) oppure mo-nitorare segmenti di rete diversi. L’ostacolo, in generale, è quindi l’eccessivaquantità di allarmi o altri eventi cui l’analista (o il responsabile della sicurez-za dei sistemi) si trova a dover leggere, verificare e controllare. Tale problemapuò essere visto da almeno due punti di vista che, spesso, vengono confusientrambi sotto lo termine di alarm correlation (o event correlation).

Contestualizzazione e aumento della precisione Oltre al problema deifalsi positivi molto comune negli IDS (soprattutto anomaly-based) c’è sempreda tener presente il fatto che gli IDS sono degli strumenti automatici, pertan-to ciechi rispetto alle particolari condizioni di funzionamento (e.g., topologiadella rete, tipo di applicazioni, grado di aggiornamento dei sistemi, ecc.). Non

34


è affatto detto che ad ogni allarme corrisponda un attacco che abbia centra-to l’obiettivo: primo perché può essere che l’aggressore stia “provando” unattacco (o un portscan), secondo perché l’attacco potrebbe far leva su una vul-nerabilità alla un sistema è stato già reso immune (con un aggiornamento,per esempio). In casi simili a quelli esemplificati, gli allarmi sono non rilevantirispetto al contesto [?].

Collaborazione tra IDS Nel caso in cui siano presenti più IDS è possibilesfruttare tutte le informazioni per avere criteri più solidi su cui fondare la scel-ta di scartare o meno un allarme, per esempio. Si tratta dunque di un processodi analisi che produce report compatti a partire dai vari flussi di allarmi prove-nienti dagli IDS [?]. Anche se questo processo può essere svolto manualmente,oggi l’interesse è ovviamente volto all’automatizzazione di quest’attività.

Quindi lo scopo è sempre lo stesso ma le informazioni da sfruttare e le atti-vità da seguire per raggiungerlo sono diverse e complementari. Nel seguito siforniranno i concetti principali per comprendere le funzionalità di un sistemaautomatico di correlazione.

AGGREGAZIONE

Riprendendo la terminologia utilizzata in [?] e nella Sezione 3.4, i processidi normalizzazione di centralizzazione possono essere facilmente confuse conl’aggregazione. Tuttavia riteniamo che normalizzare e centralizzare siano at-tività meramente legate alle scelte tecnologiche (formato e memorizzazione).Invece, l’aggregazione è un processo legato agli allarmi in sé e dal nostro puntodi vista è un’attività che può prescindere dalla tecnologia, pertanto può essereconsiderata a parte.

Il modo più efficace per definire cosa s’intende per aggregazione è con unesempio. I processi di aggregazione ricordano molto le funzioni tipiche usatenel campo dei data warehouse [?]: si tratta infatti di raggruppare e presentaregli eventi sulla base di attributi notevoli come indirizzi/porte sorgente/destina-zione, nome dell’attacco, sensore, tempo, eccetera. Ad esempio:

• aggregare per indirizzo destinazione permette di individuare i passi segui-ti dall’aggressore;

• aggregare per porta destinazione permette di osservare i servizi interessatidagli attacchi;

• aggregare nel tempo permette di individuare (nuovi) pattern di attacco.

L’aggregazione è la funzionalità di base in un sistema di analisi degli al-larmi. Oltre a diminuire il numero di allarmi da verificare, aggregando si au-mentano anche le capacità di rilevazione. Per esempio l’analista può riuscirea ricostruire facilmente i vari passi che l’aggressore ha seguito per condurrel’attacco. Nel caso distribuito non si esclude la possibilità di riuscire a ricono-scere attacchi condotti da più aggressori, in maniera coordinata, osservando,per esempio, gli intervalli temporali in cui i diversi allarmi sono stati rilevati.

35


PRIORITIZZAZIONE

Per prioritizzazione intendiamo l’attribuzione di un peso ad un allarme, inrelazione alla situazione. In realtà è il fine ultimo del processo di contestualiz-zazione: infatti la priorità di un allarme dipende, come minimo, dalla topologiadel sistema informatico e dalle politiche di sicurezza dell’azienda.

In altre parole prioritizzare vuol dire dare più o meno importanza ad unallarme in relazione all’ambiente in cui tale allarme è stato rilevato. Il motivoper cui è interessante valutare la priorità è abbastanza ovvio. Per esempio, seper un sistema UNIX che utilizza il server web Apache viene rilevato un alertper un attacco verso il server web Microsoft IIS, l’allarme dovrebbe avere unapriorità molto bassa. Allo stesso modo, se si riceve un allarme per un attac-co che sfrutta una vulnerabilità presente in una certa versione di Apache lapriorità dovrebbe essere bassa se la versione attualmente in uso è più recente.

Dal punto di vista dell’aggregazione, la priorità può essere considerataanche a monte di tale processo. Difatti l’attività di aggregazione stessa puòbasarsi sul livello di priorità per raggruppare gli allarmi.

SISTEMI AUTOMATICI PER LA CORRELAZIONE

Come è facile intuire, un sistema software di correlazione di allarmi è pre-visto che svolga in modo automatico la maggior parte delle attività descritte.Nelle ipotesi più generali, tali sistemi sono “alimentati” dai vari flussi di allar-mi e, come minimo, devono produrre automaticamente altri allarmi (possibil-mente in numero inferiore): questo, per noi, è l’output minimo di un processoautomatico di correlazione ed è già un problema molto difficile da risolvere.

Visto che l’output è una versione “aumentata” dell’input questi sistemi de-vono necessariamente “conoscere” il contesto di funzionamento; pertanto, osono realizzati ad-hoc o devono poter essere configurati con informazioni ag-giuntive. Poi, a seconda del livello di astrazione e di ricchezza che si desideraraggiungere, la conoscenza potrà riguardare (in ordine): gli attacchi e la lorotassonomia, la topologia della rete, gli asset aziendali, i servizi ed il loro livellodi esposizione, le (versioni delle) applicazioni, le politiche di sicurezza o tuttequeste informazioni. Per esempio, se si vuole che il sistema debba essere ingrado di verificare il successo o meno di un attacco (operazione tutt’altro chesemplice) come dovrà conoscere la topologia della rete e il meccanismo percontattare l’host vittima. Ancora, se si desidera poter scartare degli alert sul-la base della loro priorità per l’azienda, il sistema dovrà avere a disposizionesulla criticità di certi sistemi rispetto all’attività dell’azienda.

Tuttavia questi problemi costituiscono un passo ulteriore già ben risoltoda alcuni dei sistemi esistenti. Il problema più importante (e poco risolto)resta infatti la ricerca di metodi e, soprattutto, algoritmi per correlare, aggre-gare, scartare allarmi: requisito minimo dei sistemi di correlazione. Visto chel’interesse principale di questo lavoro è volto alla valutazione di metodi, ciconcentreremo in seguito su questi aspetti e sulle proposte di soluzione.

36


METODI STATISTICI

In [?] lo stream di alert è modellizzata come una serie temporale, in cui gli al-larmi sono considerati come un processo stazionario; per questo propongonoun metodo classico di analisi per la rimozione di trend e periodicità. Invece,gli allarmi veri sono ipotizzati essere la componente “anomala”, non filtrabi-le, di una serie temporale. La variabile osservata è il numero di allarmi all’ora,preventivamente aggregati a seconda della firma. L’approccio si basa su me-todi ben noti e verificati, tuttavia ha almeno due limiti: prima di tutto si basasulla preventiva aggregazione degli allarmi con la stessa firma (disponibilesolo nei sistemi misuse-based); in secondo luogo, per avere una descrizionesignificativa del fenomeno osservato, è necessaria un’enorme quantità di dati,soprattutto per riuscire ad eliminare trend e componenti periodiche. Infine èdiscutibile la reale applicabilità del metodo on-line.

In [?] gli alert vengono modellizzati come un vettore aleatorio bernoullia-no; i campi del vettore sono relativi alle informazioni sull’alert che possonoessere presenti (in quel caso ci sarà uno zero) o non presenti (in quel caso cisarà un uno). Il flusso di alert è quindi una serie temporale multivariata convariabili in {0, 1}. Tale serie viene poi visualizzata in un diagramma a barre incui ogni riga rappresenta un allarme e ogni colonna rappresenta il campo delvettore (che non viene visualizzato se pari a zero): lo scopo sarebbe quello diavere un’idea di come varia il contenuto informativo degli allarmi nel tempo.Per ogni campo di ogni allarme viene misurato un grado di tipicality, che al-tro non è che la somma, su una finestra temporale a scorrimento, del numerodi occorrenze di quel campo (pari a uno). L’ipotesi è che un allarme sarebbetanto più tipico quanto più frequentemente appare nel tempo. Il primo puntooscuro di questo metodo è il modo in cui venga calcolata la tipicality di unallarme a partire da quella dei suoi campi: di fatto non viene specificato. Insecondo luogo, la misura di tipicality è basata solo sulla frequenza: basare unfiltro su questa variabile porterebbe presto a scartare allarmi frequenti; non èdetto che siano falsi solo perché frequenti. Inoltre, perdere completamente ilcontenuto informativo degli allarmi sembra a nostro avviso troppo riduttivo:è possibile costruire metriche molto più accurate ispezionando il contenuto.

Implementato nel motore di correlazione di EMEALD, la tecnica propostain [?; ?] è in grado di analizzare e correlare (nel tempo) gli alert provenienti dapiù IDS e valutandone la similarità sulla base di un insieme di feature comu-ni. È proposta una metrica di similarità diversa per ogni feature. L’approccio èmolto pratico e prevede un solo parametro di configurazione: una soglia di si-milarità minima. Inoltre, differentemente da altre proposte analizzate, preve-de, tra i sensori, la presenza di un IDS host-based nondimeno riporta risultatiprecisi sugli esperimenti condotti. Le feature osservabili sono:

1. identificatore del sensore,

2. il thread dell’alert (ovvero il gruppo assegnato all’alert dal sensore),

3. IP sorgente/destinazione,

4. porta sorgente/destinazione,

37


5. il tempo

e altre feature meno interessanti. Gli allarmi vengono aggregati progressi-vamente in meta-allarmi. Abbiamo deciso di sfruttare alcune di queste idee nelprototipo da noi proposto nel Capitolo 6.

Test di Granger di causalità In [?] è presentato un algoritmo molto inte-ressante, soprattutto per il nostro lavoro, dal momento che non richiede nes-sun tipo di conoscenza pregressa per le operazioni di correlazione. Una basedi conoscenza è richiesta soltanto se si desidera anche prioritizzare gli alert.Alla vera e propria fase di correlazione viene fatta precedere una fase di ag-gregazione usata per fondere allarmi con attributi identici, fatta esclusione peri timestamp. A questa fase può essere fatta seguire una fase di clustering perevitare che allarmi “non esattamente identici ma simili” non vengano aggre-gati. Il risultato di questa fase è quindi un set di cluster che gli autori defini-scono hyper-alert il cui contenuto differisce solo per il tempo. Sostanzialmen-te ogni hyper-alert è una serie temporale sulla quale il metodo proposto cercadi individuare delle relazioni di “causalità” in termini probabilistici. Di fatto,l’algoritmo proposto si basa su una finestra a scorrimento di dimensione con-figurabile (negli esperimenti fatti dagli autori è fissata a 60 secondi). Ogni alertè modellato come una tupla di attributi: timestamp, IP sorgente/destinazione,porta/e TCP, utente, processo, classe di attacco, identificatore dell’IDS.

L’algoritmo può essere scomposto nelle seguenti fasi:

I. aggregazione basata su:

I. tutti gli attributi tranne il timestamp: il risultato è che tutti gli alert dipari attributi si trovano nello stesso insieme;

II. sull’attributo “identificatore dell’IDS”: a partire dall’output della pre-cedente aggregazione vengono raggruppati tutti gli alert che sonostati riportati da sensori diversi (eterogenei); il risultato è quindi lafusione dei gruppi precedentemente creati solo se tutti gli attribu-ti (degli alert) di tali gruppi sono identici tranne l’identificatore delsensore.

Il risultato di questa fase è quindi un insieme di hyper-alert, ovvero uninsieme di gruppi di alert: in realtà si tratta di un insieme di serie tempo-rali.

II. Clustering (opzionale): all’interno di ogni gruppo di alert aggregati vienevalutata la similarità tra alert e, se necessario, alert molto simili vengonofusi in uno solo (per esempio è possibile che, se la risoluzione del tempoè troppo scarsa, due alert presentino lo stesso timestamp).

III. Prioritizzazione (opzionale): questa fase richiederebbe conoscenza a prio-ri: è necessario avere una struttura dati è memorizzato, per ogni tipo diattacco noto un assegnamento di probabilità. Tale assegnamento espri-me, secondo una rete bayesiana rappresentata con un Direct Acyclic Gra-ph (DAG), la priorità di ogni attacco rispetto alle risorse nella rete (e.g.,

38


sistemi operativi, interessi, utenti, porte, ecc.). Questa fase sfrutta dei con-cetti derivati dalla teoria dell’evidenza per calcolare la priorità di ogni at-tacco: tuttavia, allo scopo di questo lavoro non è interessante valutare lepriorità basandosi su cononscenza a priori, questo aspetto non verrà appro-fondinto. Tuttavia, nel Capitolo 6 verrà proposta una versione adattatadi questo algoritmo che terrà conto comunque delle priorità senza alcuntipo di conoscenza a priori.

IV. Correlazione temporale basata sul test di Granger di causalità.

I. Ogni hyper-alert Aj = [a1, a2, . . . , an] è modellato come una serietemporale univariata A(k). In pratica, si suddivide il periodo di tem-po Tj ∈ R+ di ogni hyper-alert in Nj = Tj/w intervalli di am-piezza w. A questo punto aj(k) con k = 0, 1, . . . , Nj − 1 è la serietemporale formata dagli aji ovvero dal numero di alert che cadononell’intervallo di tempo i-esimo.

II. Per ogni alert Aj viene calcolato l’indice di causalità di Granger contutti gli altri alert e tutti gli alert che passano il test di Granger ven-gono considerati “correlabili” all’alert Aj . Così facendo si ha, perogni hyper-alert, una lista di possibili cause (hyper-alert): da questevengono estratte quelle con indice di causalità più alto.

Noi concludiamo che tutti gli alert che o vengono scartati dal test o hannoun indice di causalità troppo basso devono essere trattati separatamente: po-trebbero essere dei falsi positivi oppure degli attacchi “spot” comunque andatia buon fine.

Il test di Granger tra due serie temporali x, y (della stessa dimensione N )si basa sulla seguente intuizione: per vedere se x è causa di y bisogna vederequanto y è influenzata sia dalla storia di x sia dalla storia di y. Per far questosi modella la seconda serie con due modelli:

y(k) =p∑

i=1

αiy(k − i) + e0(k)

y(k) =p∑

i=1

βiy(k − i) +p∑

i=1

γix(k − i) + e1(k)

che sono rispettivamente di tipo Auto Regressive (AR) e Auto Regressive Mo-ving Average (ARMA) (più precisamente si tratterebbe di un Auto RegressiveeXogenous (ARX), dove la parte esogena viene dai campioni di x(·)). I coef-ficienti αi, βi, γi sono calcolabili tramite diverse tecniche di minimizzazionedell’errore di predizione, non è questa la sede per discuterli. Se il passo dipredizione è p vi sono a disposizione N campioni, il test ha senso sui restantiT = N − p. Una volta calcolati i residui R0 =

∑Tk=1 e0(k) e R1 =

∑Tk=1 e1(k)

la statistica è:

GCI =(R0 −R1)/p

R1/(T − 2p− 1)∼ F(p, T − 2p− 1)

39


dove F è la distribuzione di Fisher. Se GCI > fc (valore critico) allora èpossibile asserire causalità tra x e y. Chiaramente il valore critico di pendedai gradi di libertà della distribuzione di Fisher e dalla significatività del test.Si noti che la condizione ideale di completa causalità è in corrispondenza diR0 = 0 e GCI →∞.

Questa tecnica ha un significato statistico chiaro e ben definito ed è in gra-do di trovare relazioni di causalità sconosciute. Tuttavia potrebbe richiedereuna quantità di allarmi considerevole prima di rilevare correttamente nuoviscenari. Di più, così come è stato formulato, l’algoritmo non sembra diretta-mente utilizzabile on-line. Inoltre, gli stessi autori notano il limite di non avervalidato l’efficacia dell’algoritmo con serie temporali di variabili categoriche,come ad esempio la porta TCP.

TECNICHE DI DATA MINING

In [?] si propone un’analisi degli allarmi basata sulla ricerca delle cause (rootcause analysis). Vengono impiegate una versione approssimata di un algorit-mo di clustering, con lo scopo di raggruppare allarmi con la stessa root cau-se. Visto che è impossibile risolvere questo problema, il criterio di raggrup-pamento è basato sulle proprietà strutturali degli alert. Tali proprietà sonoespresse in logica abduttiva [?]. Per calcolare le distanze tra allarmi, questi ul-timi vengono generalizzati in opportune gerarchie (DAG) e –sulla base del li-vello nella gerarchia– vengono considerati più o meno simili. Chiaramente, untale approccio è imperniato sul modo in cui tali gerarchie vengono costruite.

In [?] si propone di eliminare sequenze di allarmi ricorrenti. Tali sequenzevengono individuate con una tecnica cui gli autori danno il nome di episodicrule mining ma, sostanzialmente, si tratta di apprendere regole di associazione[?]. Similmente, in [?] le sequenze ricorrenti (scenari) vengono apprese/indi-viduate a partire da un set di pattern etichettato manualmente; chiaramentequesto genere di approcci ha lo svantaggio di doversi basare su un insieme discenari conosciuti. Una variazione di questa tecnica, [?], cerca di individuareun insieme di attacchi che, generalmente, seguono un (allarme per un) datoattacco.

ANALISI CAUSA-EFFETTO

Sulla base di [?], in [?] si (ri-)propone un linguaggio per la definizione di (sce-nari di) attacchi in un sistema informatico. In sostanza il linguaggio JIGSAWpermette di specificare un attacco come una tripla 〈Req, Fact, Prov〉 dove Req

(requires) sono i requisiti (chiamati “concetti”) dell’attacco (detto Fact) e Prov

(provides) sono gli effetti riscontrabili dell’attacco. Il vantaggio di vedere gliallarmi (di attacchi) immersi nel contesto di pre/post condizioni, permette diindividuare scenari complessi e generici sulla base dei quali è possibile aggre-gare gli allarmi. Un approccio molto simile, ma che impiega un formalismodiverso, è descritto in [?].

In [?] viene sfruttata la stessa idea di [?] con la differenza che gli allarmi(chiamati hyper-alerts) vengono organizzati e aggregati in strutture dati ad al-

40


bero (tipo DAG). Uno dei criteri di aggregazione è basato sul matching di po-st/pre condizioni di allarmi (di attacchi) successivi; altrimenti, gli alert pos-sono essere aggregati se “abbastanza” vicini nel tempo. La proposta è stataimplementata in un tool chiamato TIAA ed impiega, oltre alle informazioniaggregate dal motore di correlazione, delle conoscenze a priori sui possibilialert (in formato hyper-alert). Uno dei limiti di questa proposta è la necessitàdi popolare la base di conoscenza, tra l’altro in un formato dedicato.

TECNICHE DI ASTRAZIONE E GENERALIZZAZIONE

In [?] si propone un framework generico, in cui sono evidenti le idee contribui-te nei lavori precedenti, per l’analisi e la correlazione. Di fatto è un’architetturapronunciatamente “a pipe”, in cui gli allarmi vengono:

1. normalizzati (in uno stesso formato),

2. pre-processati,

3. correlati e

4. prioritizzati.

In realtà la terza fase è una serie di processi, che possono o meno essereeseguiti, ognuno con un focus diverso. Ad esempio, è possibile correlare (ag-gregare) attacchi relativi allo stesso bersaglio, o allo stesso aggressore; oppureè possibile verificare se gli attacchi hanno effettivamente avuto successo; op-pure, correlare gli attacchi rispetto agli asset aziendali, eccetera. La prima ela terza fase si basano su un’entità che viene definita meta-alert e, di fatto, èuna struttura ad albero che contiene (uno o) più allarmi: durante i vari pro-cessi gli allarmi vengono “appesi” a questa struttura dati se rispettano certicriteri di “vicinanza” con (gli altri contenuti nel)la struttura. Sono propostidiversi criteri di vicinanza: nome dell’attacco, bersaglio, aggressore, servizio.Per quanto completa e generale nel presentare il problema, la proposta nonindaga a fondo l’applicazione dei criteri di vicinanza, soprattutto per quantoriguarda quelli basati sul tempo.

Una proposta basata sull’analisi degli allarmi rispetto agli asset aziendaliè descritta in [?]. La differenza di questi approcci è nel prevedere un meccani-smo di prioritizzazione (in questo caso basato sull’impatto degli attacchi sugliasset aziendali).

AGENTI AUTONOMI

Ci sono alcune proposte nel campo degli agenti, che tentano di sfruttare il di-verso modello di comunicazione allo scopo di propagare più efficientementegli alert provenienti dai diversi sensori. Ogni sensore (host o network) vienemodellizzato come un agente autonomo. Esiste un prototipo di frameworkcollaborativo basato su agenti [?; ?]: si tratta di un sistema distribuito in cui gliagenti aggregano l’informazione in maniera gerarchica la quale può essere vi-sualizzata in un’interfaccia grafica. È rilasciato anche un generatore di codiceper facilitare lo sviluppo di nuovi sensori (agenti).

41


Questo ed altri approcci [?] simili non si occupano per niente dell’aspettospecifico della correlazione; concentrandosi invece sulla propagazione delleinformazioni risultano piuttosto delle proposte complementari alle altre.

MODELLI FORMALI

Esistono anche proposte nel campo dei metodi formali. In [?] si utilizza unatecnica basata su model checking [?] per analizzare gli attacchi sulla base dipre/post-condizioni e informazioni sulla connettività degli host nella rete.Questo tipo di approcci è volto a individuare quali attacchi potrebbero avve-nire in certe situazioni, piuttosto che ricostruire quali attacchi siano accadutisulla base degli allarmi.

In [?] propone un modello formale di un processo di correlazione in cuisono coinvolte più sorgenti di informazione: caratteristiche dei sistemi con-trollati, conoscenze sulla vulnerabilità e sugli IDS.

APPROCCI COMPLEMENTARI

Esistono infine delle proposte che possono essere considerate a prescinderedalla tecnica scelta per effettuare correlazione automatica. In particolare esi-stono diversi tool che aiutano l’analista a ridurre ulteriormente lo sforzo ri-chiesto per individuare scenari complessi di incidenti, specialmente in siste-mi su larga scala. Questo tipo di approcci, basati sulla visualizzazione del-la situazione ricostruibile a partire dai log, possono essere impiegati a valledi un qualsiasi sistema di correlazione. Alcuni di questi strumenti sono sta-ti resi disponibili: NVisionIP, NVision-Vscan, NVision-PA, VisFlowConnect-IP,VisFlowCluster-IP, VisFlowCluster-Ports, VisTextFlow-IP e UCLog+ [?].

SISTEMI REALI ESISTENTI

I sistemi di correlazione automatica esistenti sono pochi e con caratteristichediverse. A parte le applicazioni commerciali si tratta comunque di proget-ti molto recenti, taluni ancora da concludere e rilasciati in forma di versionidimostrative intermedie.

OSSIM Si tratta di un’applicazione e di un progetto open-source [?] svilup-pati con l’intento di soddisfare i requisiti di sicurezza dei moderni sistemi diID attraverso l’implementazione di un potente motore di correlazione. La ca-ratteristica principale di OSSIM è la personalizzabilità: si tratta infatti di unset di sensori (sensori, librerie, interfacce, ecc.) e di linee guida (es., architettura)per la creazione di un framework integrato per il monitoraggio degli incidenti.

Come mostrato in Figura 3.10, le funzionalità offerte sono stratificabili evanno da quelle di base di detection fino a quelle di alto livello come la corre-lazione. Il cuore di OSSIM è il motore di correlazione, implementato da unaserie di algoritmi raggruppabili in due categorie:

esatti — sono basati su un database di sequenze note di attacchi e, sostanzial-mente, funzionano come una macchina a stati finiti in stile State Transi-

42


Misuse detection

Anomaly detection

Normalizzazione

Prioritizzazione

Analisi rischio (impatto)

Correlazione

01001..110...100x23...0x1f...1

!

?

Visualizzazione

Live

llo d

i ast

razio

ne a

lert

FIGURA 3.10: Funzionalità e livelli di astrazione nell’architettura di OSSIM.

tion Analysis Technique Language (STATL) per rilevare scenari complessiin maniera deterministica;

euristici — cercano di rilevare “situazioni rischiose” sulla base di attacchi notie non e altre informazioni. Cerca di superare le mancanze degli algoritmiesatti, soprattutto nel caso di attacchi o sequenze non noti.

Il tutto è configurabile ed utilizzabile attraverso un’interfaccia ipertestualeattraverso la quale è possibile svolgere attività di analisi forense.

Prelude-IDS Sebbene questo strumento avrebbe potuto essere riportato nel-la sezione dedicata agli IDS distribuiti abbiamo preferito collocarlo a questopunto, per via dell’orientamento alla correlazione. È un’idea completamentediversa dai sistemi presentati nella Sezione 3.4.4 ed è pensata su scala moltopiù ridotta (es., grandi reti locali, intranet). Di fatto è un framework (si veda laFigura 3.11) per l’integrazione di qualunque tipo di IDS, commerciale, libero,host, network, ecc. Prelude-IDS [?] è un progetto relativamente nuovo, tantoche alcune delle funzionalità sono solo pianificate.

Si tratta di un insieme di librerie e componenti che permettono di crearedegli IDS ibridi estremamente personalizzabili. I moduli principali di Prelude-IDS (in Figura 3.11) sono LibPrelude, sensori (Prelude-NIDS in Figura 3.12,ma anche custom), manager intermedi o centrale, agenti per la reazione agliattacchi e un’interfaccia grafica.

Oltre al vantaggio di imporre IDMEF, il formato standard per lo scambiodi messaggi di alert tra IDS, il progetto prevede linee guida e best-practice pergli sviluppatori che vogliono creare sensori personalizzati o adattare l’outputdi un certo sistema. Di base, Prelude-IDS prevede supporo per Snort, ShadowIDS, SANCP (network) e SAMHAIN (host).

La possibilità di fare correlazione di alert, feature forse più interessante, èancora in stadio primordiale e non è disponibile nelle versioni rilasciate.

43


(a) (b)

FIGURA 3.11: Architettura di alto livello di Prelude-IDS (a) e livelli di astrazioni nellelibrerie (b).

FIGURA 3.12: Architettura di Prelude-NIDS, il sensore network misuse-based diPrelude-IDS.

MARS Prodotto commerciale di Cisco Systems, MARS [?] è un’appliancein cui è implementato un sistema integrato per ID, correlazione e prevenzionedi attacchi network. Progettato con lo scopo di ridurre i falsi positivi, MARSpermette all’analista di monitorare velocemente, da una postazione integra-ta, i tentativi di compromissione in atto in una rete locale. Il sistema funzionaanche con eventi provenienti da altri sistemi (anche se tuttavia non è speci-ficato in che formato) e comprende funzionalità di topology auto-discovery,

44

Considerazioni conclusive

visualizzazione degli scenari di attacco e configurazione personalizzata dellepolitiche di reazione.

SSIM È l’analogo di MARS prodotto da Symantec.

3.7 CONSIDERAZIONI CONCLUSIVE

Lo stato della ricerca ed i risultati finora ottenuti circa l’ID hanno diversi pro-blemi. L’intuizione a monte della rilevazione delle intrusioni è che un attaccosia rilevabile o perché ha delle caratteristiche semplici e ricorrenti (misuse) operché è diverso dal comportamento “normale” (anomaly). Entrambe le intui-zioni sono sensate, tuttavia non esiste alcuna teoria a supporto: difatti, il mon-do degli IDS è costellato da una moltitudine di soluzioni ad-hoc che risolvonoin modi diversi lo stesso problema.

Non esiste un’evidenza teorica che un modo di procedere sia meglio diun’altro, tant’è che la valutazione dell’efficacia degli IDS è completamente empi-rica. Tra l’altro la totalità dei prototipi di ricerca è valutata sulla base dello stes-so dataset. Per converso, i test di efficacia dei prodotti commerciali seguonostrategie e criteri completamente diversi.

Il limite principale, probabilmente impossibile da eliminare, degli IDS èl’ipotesi alla base del funzionamento: che un attacco presenti caratteristichetali da essere riconoscibile, o in quanto tale o in quanto diverso dalla norma-lità. Per esempio, un attacco DoS non ha niente di anomalo: si basa sull’usolegittimo di un servizio, in proporzioni non previste, ma comunque legittimo.

Ricordiamo che i principali sforzi in questo campo dovrebbero essere orien-tati, prima di tutto, allo sviluppo di una teoria o –come minimo– di un fra-mework per caratterizzare in modo preciso il comportamento intrusivo. Fattibi-le o meno, una teoria di questo tipo fornirebbe opportunità di progresso nonindifferenti, garantendo una guida per il progetto degli analizzatori. Inoltre,visto che non esiste il sistema normale (e quindi è impensabile poter caratte-rizzare la normalità in modo efficace), gli sforzi andrebbero diretti verso lacreazione di modelli degli ambienti in cui l’IDS opera: a partire da tali descri-zioni, la definizione della “normalità” può essere sicuramente più contestualee precisa.

45

— CAPITOLO 4 —

ANALISI DEL DATASET IDEVAL

L’efficacia di un IDS deve poter essere misurata in maniera affidabile e ripeti-bile in modo da permettere confronti con altri sistemi. Questo capitolo intro-duce brevemente l’unico dataset esistente sui cui la comunità scientifica puòfare affidamento per valutare questi strumenti. La parte centrale del capito-lo riporta invece i difetti del dataset IDEVAL riscontrati nel corso degli anni;si arricchisce infine con ulteriori problematiche che abbiamo avuto modo dirilevare analizzando, in modo molto approfondito, i dati IDEVAL relativi del-l’attività host. Il capitolo si conclude con una breve panoramica aggiornata deimetodi alternativi per la valutazione degli IDS.

4.1 DATI DI TRAINING E DI TESTING

Come illustrato nella Sezione 3.5, nel caso degli IDS, e più in generale deisistemi di classificazione, la valutazione dell’efficacia non è banale in pratica;non solo per il numero di parametri di cui è necessario tener conto ma per lamancanza di buoni dati di test.

Tra il 1998 ed il 1999, il Lincoln Laboratory (LL) del Massachusetts Institute ofTechnology (MIT) hanno prodotto il primo (e unico) dataset tutt’oggi impiegatoper questi scopi: IDEVAL [?; ?; ?]. Si tratta di un insieme piuttosto corposo didati raccolti simulando l’attività degli host in una rete, sia a livello networkche a livello di sistema operativo. La topologia della rete simulata è riportatain Figura 4.1.

Tutti i dati sono simulati per motivi di privacy. I più recenti sono stati rac-colti nelle cinque settimane dall’1 marzo al 9 aprile 1999. Sono divisi in dueporzioni: training e testing. I dati di training sono relativi alle prime tre settima-ne e non contengono attacchi tranne che durante la seconda. I dati di testing(delle ultime due settimane) invece contengono diversi attacchi, comunquesimulati. Più precisamente, i dati permettono di ricostruire le condizioni disimulazione in termini di:

• traffico di rete proveniente dagli sniffer esterni (outside dump) ed interni(inside dump): entrambi in formato Pcap.

• Sequenze di chiamate al sistema operativo di uno degli host “vittima”interni (i.e., pascal) in formato BSM.

• Log di sistema (Windows NT) di uno degli host “vittima” interni (i.e.,hume) nel formato utilizzato da Windows NT.

• Backup e liste di file e directory di alcuni host (i.e. pascal, marx, zeno ehume): in altre parole, il contenuto di alcuni dischi fissi.

47

4. ANALISI DEL DATASET IDEVAL

9

Sun Sun Sun

Linux 2.2 Win NT 4.0SunOS Win 98

Win NT 4.0Linux 2.2 Linux 2.2 Virtuale

Linux 2.2 Win NT 4.0 MacOS

Linux 2.2 Win NT 4.0 Virtuale

SunOSSolaris 5.2 Linux 2.2

. . .

. . .

Aggressore Aggressore Aggressore

WWWaesop

192.168.1.20

Gatewaycalvin

192.168.1.10

Sniffersolomon

192.168.1.90

SNMPmonitor

192.168.1.30

Aggressore Aggressore

Snifferlocke

172.16.112.10

Gatewayhobbes

172.16.112.20

Vittimapascal

172.16.112.50

Vittimazeno

172.16.113.50

Vittimamarx

172.16.114.50

Vittimahume

172.16.112.100

Vittimakant

172.16.112.110

Rete172.16.112.5

Rete192.168.1.1

Linux 2.2

Rete172.16.0.1

= switch

= router

FIGURA 4.1: Rete simulata per la creazione del dataset IDEVAL.

Come è stato fatto notare [?; ?], i dati simulati non sono privi di difetti, anzi.La simulazione ha generato un traffico di base che non può essere consideratoverosimile in un reale sistema informativo.

D’altra parte, essendo gli attacchi generati a partire da exploit [?] reali enoti, costituiscono forse la componente più plausibile di tutto il dataset. Tut-tavia le tipologie di attacco sono piuttosto obsolete: buffer overflow, attacchibasati su dizionario, portscanning, denial of service o derivati. Gli attacchi odier-ni sono molto più articolati, molto meno “visibili” e molto più accurati, comeaccennato nella Sezione 2.3.

Vista l’importanza scientifica di avere fonti affidabili e realistiche su cui ef-fettuare degli esperimenti, le Sezioni 4.2 e 4.3 sommarizzano le critiche finoramosse all’unico dataset disponibile per la valutazione di IDS (si veda anche alSezione 4.5).

4.1.1 DATI DI TRAINING

Gli esperimenti per la valutazione di un IDS possono basarsi sui dati di trai-ning per la/e fase/i di addestramento. Le 43 istanze dei 18 attacchi inseritedurante la seconda settimana avrebbero lo scopo di introdurre variabilità nelcomportamento normale.

48

Traffico di rete

Gli attacchi contenuti sono comunque etichettati, ovvero esiste un elen-co che contiene informazioni circa l’aggressore, il bersaglio, i timestamp diinizio/fine ed un identificatore, per ogni attacco.

4.1.2 DATI DI TESTING

Gli attacchi contenuti nella quarta e quinta settimana sono in totale 201, traattacchi di rete ed attacchi host. Per queste due settimane è disponibile unTruth File (TF) che riporta informazioni piuttosto dettagliate su ognuna delleistanze di attacco.

Similmente a come avviene per gli attacchi immersi nei dati della secon-da settimana, il TF riporta informazioni indispensabili affinché sia possibileindividuare precisamente ogni istanza di ogni attacco ai fini di conteggio.

4.2 TRAFFICO DI RETE

Venticinque giorni di simulazione, per un totale di oltre 16GByte di trafficodi rete, considerando anche quello interno. Nell’analisi dettagliata del datasetdel 1999, fatta in [?], l’autore fa notare che, né nella documentazione [?] nénelle pubblicazioni [?; ?; ?; ?; ?] sono disponibili dettagli tecnici su come talesimulazione sia stata effettuata.

Non c’è però alcuna prova che il traffico possa essere realistico. La stessatopologia schematizzata in Figura 4.1 mostra una rete “piatta”, quindi pocoverosimile in un sistema reale. Inoltre, analizzando pochi MByte di trafficoInternet reale è facile notare frequenti pacchetti spuri; nel traffico simulato nonvi è traccia di questa caratteristica, nonostrante si tratti di un fenomeno moltocomune.

4.2.1 ATTACCHI

A prima vista, sembrerebbe che gli attacchi siano l’unico elemento ben docu-mentato [?; ?]: in realtà, se si considera il fatto che gli attacchi sono stati tutticondotti in tempi noti, manualmente o con programmi instrumentati, la co-noscenza disponibile è scarsa. Per esempio, non si conoscono i dettagli tecnicisugli attacchi complessi, che possono coinvolgere sequenze di azioni ed esecu-zioni di diverse applicazioni; piuttosto è riportata una descrizione sommaria[?] su come ogni attacco debba essere condotto, in generale e non come è statoeffettivamente condotto.

4.2.2 REGOLARITÀ

In [?; ?] sono riportate le seguenti e altre regolarità riscontrabili nel dataset,sfruttando le quali è banale costruire un IDS con una DR = 45% e una FPR ≈0: basta controllare il terzo byte dei campi source address e destinationaddress.

49


• Regolarità dei SYNchronize (SYN): tutti i pacchetti SYN TCP dei file com-prendono sempre gli stessi quattro byte di opzioni mentre nei pacchettireali questi valori vanno da 0 a 28 byte.

• Regolarità della finestra del TCP: assume solamente sette valori (tra 512e 32120). Entrambe queste regolarità sono causate dalla simulazione enon si riscontrano nella realtà.

• Prevedibilità del campo source address dei pacchetti IP: l’indirizzosorgente dei pacchetti IP assume uno tra 29 valori distinti. La metà diquesti indirizzi compare solo nello 0.1% del traffico. Un IDS reale ricevepacchetti con decine di migliaia di indirizzi sorgente diversi. Se rilevarele anomalie, basandosi sugli idirizzi IP, potrebbe essere fruttuoso lavo-rando con questo dataset, potrebbe rivelarsi fuorviante in una situazionereale.

• Completa assenza di errori di checksum e di pacchetti frammentati: seb-bene rari anche nella realtà, nel dataset sono totalmente assenti.

• Regolarità di Time To Live (TTL) e Type Of Service (TOS): per entrambiquesti campi dell’header IP si nota un insieme di valori eccessivamen-te ristretto e una ripetitività non realistica. Di conseguenza gli attacchiback, dosnuke, neptune, neptbus, netcat, ntinfoscan e quaeso possono esserefacilmente rilevati perchè lanciati con pacchetti che hanno valori di TTLche non compaiono mai nei file delle settimane di addestramento.

• Eccessiva ripetitività nelle richieste HyperText Transfer Protocol (HTTP),Simple Message Transfer Protocol (SMTP) ed Secure SHell (SSH). Tutte lerichieste HTTP sono nella forma GET url HTTP/1.0 e l’header User--Agent assume solo sei valori permutati. Nel traffico reale, le richiesteHTTP presentano almeno tre comandi. i browser reali sono più di 800.

4.3 DATI DI AUDITING

Venticinque giorni di attività sul kernel di una singola macchina, pascal, perun totale di ventisette file BSM (1.6GB circa). Le applicazioni “diverse” im-piegate sono 494, nei dati di training, e 561, nei dati di testing. Le applicazionidiverse in assoluto sono in totale 831. Si noti che per diverse s’intende con nomedel file eseguibile diverso, dal momento che non è possibile identificare in altromodo le applicazioni: per quanto è a nostra conoscenza non esiste prova chetali applicazioni siano effettivamente tutte diverse.

I dati in formato BSM registrano le chiamate al sistema operativo che, nelcaso di pascal è Solaris 2.5. Le chiamate sono 1070934 per i dati di traininge 2056834 per i dati di testing, effettuate da processi per un insieme di 4980Process ID (PID) diversi per i dati di training e 5176 per i dati di testing.

Si tratta di versioni di programmi obsolete e, nonostante fossero disponibi-li sei diversi sistemi operativi (SunOS, Mac OS, Linux, Windows NT, Windows98), i dati di auditing provengono da due sole macchine (due sistemi operatividiversi).

50

Dati di auditing

4.3.1 SCARSITÀ DELLE ESECUZIONI

Nei dati di training è stato riscontrato un numero di istanze di esecuzionetroppo basso affinchè possa essere correttamente modellizzato il comporta-mento normale di un software.

Programma Num. di esecuzionifdformat 5eject 7ps 105ftpd 65telnetd 1082sendmail 827

TABELLA 4.1: Numero di istanze di esecuzione calcolate su tutto il dataset di training.

Come si può osservare dalla tabella 4.1, per i programmi fdformat e eject,sono disponibili solo poche esecuzioni, rispetto al numero di istanze per pro-grammi come telnetd (demone, tra l’altro, considerato attualmente obsole-to).

Si ritiene che il numero di esecuzioni non sia sufficiente per poter conside-rare esaustiva la fase di apprendimento, in quanto poco rappresentativo delfunzionamento di un host.

4.3.2 ATTACCHI

Anche gli attacchi soffrono di regolarità e obsolescenza. Quelli rilevabili neifile BSM sono in totale 19, distribuiti in 142 istanze. Le tipologie principalidi attacco presenti sono il buffer overflow (24%), denial of service (24%), di-zionario (18%). Tuttavia, gli attacchi all’host veri e propri (ovvero eseguiti daconsole) sono soltanto dei buffer overflow, rilevabili tra l’altro dalla sempliceispezione degli argomenti della prima chiamata (execve).

Similmente a come è stato fatto notare per il traffico di rete, precisiamo cheanche in questo caso è semplice costruire un IDS basato sulla lunghezza degliargomenti che segni come anomale le chiamate con argomenti di lunghezzasuperiore a 500 caratteri. Tra l’altro è stato provato che un IDS di questo tipoavrebbe DR = 100% e FPR ≈ 0 (quasi ideale).

4.3.3 REGOLARITÀ

Il numero di chiamate di sistema diverse è molto limitato, in più le esecuzio-ni di ogni programma diverso risultano piuttosto simili: le possibilità di unsistema reale non sono coperte. Per esempio, in Figura 4.2 è mostrata la distri-buzione della lunghezza delle escuzioni (distanza tra invocazioni successivedi in.telnetd, misurata in numero di chiamate tra due execve consecutive):come è facile notare esiste un range di valori molto più frequente di tutti glialtri. Si tratta di un chiaro segno di automatizzazione senza l’inserimento dialcuna casualità.

51


0

100

200

300

400

500

600

700

25 30 35 40 45 50 55 60 65 70

Num

ero

di o

ccor

renz

e

Distanza tra due syscall execve consecutive

FIGURA 4.2: Distribuzione della lunghezza delle escuzioni (distanza tra invoca-zioni successive di in.telnetd, misurata in numero di chiamate tra due execveconsecutive).

Allo stesso modo, gli argomenti delle chiamate sono poco variabili. Per lostesso programma in.telnetd, ad esempio, sono limitate al seguente set divalori: .so.1, :zero, pts, logindmux, initpipe, utmp, wtmp. Come ul-teriore evidenza si riporta, in Figura 4.3, la distribuzione delle chiamate di si-stema ritrovate in tre programmi: in.ftpd, in.telnetd e find (nei soli datidi training): si nota una marcata presenza delle chiamate di tipo open.

Inoltre le sequenze di esecuzione di alcuni gruppi di programmi sono alta-mente predicibili. Per esempio, apparentemente per effetto di uno script, sonoriscontrabili esecuzioni cicliche di cat, mail, mail e, talvolta, lynx (ripetutodue volte). Lo stesso capita per rm, sh, ps, ls che sono eseguiti spesso unodopo l’altro ma in ordine permutato.

4.3.4 ANOMALIE NEI PID E NEI NOMI DEI PROGRAMMI

Il nome di alcuni processi è evidentemente stato modificato: per esempio log-out appare come loKout, log0ut, ecc. Lo stesso avviene per i nomi dei percor-si: per sempio lynx presenta esecuzioni sia da /usr/bin/lynx che da /usr-/local/bin/lynx, tra l’altro con lo stesso PID. In questo secondo caso i pro-grammi sembrerebbero identici: probabilmente si tratta di link simbolici co-me tentativo di introdurre del rumore all’interno dei dati di testing. La com-binazione dei due crea effetti strani come /etc/loKout o /opt/local/bin-/lPgout.

In un certo numero di casi lynx, mail e q hanno esecuzioni duplicate con

52

IDEVAL e correlazione di allarmi

0 2000 4000 6000 8000

execve

vfo

rkexit

open

setu

idcre

at

unlin

k

Tip

o d

i chia

mata

Numero di occorrenze

0 20000 40000 60000 80000

exe

cve

op

en

fork

exit

se

tgid

se

tuid

cre

at

un

link

vfo

rk

Tip

o d

i chia

mata


0 10000 20000 30000 40000

exe

cve

op

en

exit

fork

Tip

o d

i chia

mata


FIGURA 4.3: Distribuzione delle chiamate di sistema ritrovate in tre programmi:in.ftpd, in.telnetd e find (nei soli dati di training).

PID e timestamp identici ma con percorsi e argomenti diversi. Questo generedi problemi sono a nostro avviso spiegabili soltanto considerando il fatto chei dati sono stati simulati in maniera automatica.

4.3.5 ALTRE ANOMALIE

Sono state fatte delle statistiche riguardo alla proporzione di chiamate execverispetto a tutte le altre nella stessa sequenza. È risultato che, per il 28% circadei programmi che appaiono nei dati di training questa proporzione è parial 100%. Ovvero, tutte le sequenze di tutti questi programmi sono composteda sole execve; di più, tali sequenze erano composte da una sola chiamata disistema, la execve per l’appunto.

La quasi totalità di queste sequenze era riferita all’esecuzione di program-mi con nomi modificati (e.g., loKout, log0ut, ecc.). È ovvio che valutare unIDS host-based su questo tipo di sequenze non ha alcun senso; per questo mo-tivo nei test che abbiamo effettuato abbiamo escluso tutte queste esecuzioni.

4.4 IDEVAL E CORRELAZIONE DI ALLARMI

Al fine di costruire e valutare la qualità e l’impatto di un sistema di correla-zione network/host è necessario disporre di attacchi rilevabili da entrambi gli IDS.A questo scopo abbiamo analizzato le possibilità offerte dal dataset.

Rispetto alle 204 istanze di attacchi in totale, 23 sono presenti sia nei dumpBSM che nel traffico Pcap; tra queste si ritrovano 14 attacchi diversi, su untotale di 111 tipi di attacchi diversi (tra host e network): circa il 13%. Tuttaviaquesto limite risulta dovuto ai tipi attacco rilevabili (anche) lato host, che sono19 diversi.

53


NETWORK HOST NETWORK E HOST

Tipi di attacchi diversi 111 19 14Istanze di attacco 1292 142 106Istanze raggruppate 154 38 28

TABELLA 4.2: Numerosità degli attacchi rilevabili a seconda del tipo di attività (hosto network). Per “istanze raggruppate” s’intende il conteggio effettuato contando unasola volta le istanze con lo stesso identificatore, ovvero gli attacchi lanciati durante lastessa sessione.

Quindi, dal punto di vista “host” si potrà usufruire di una post-analisi(e correlazione) per il 74% degli attacchi (diversi), tuttavia questa porzione èrelativa solo al 13% degli attacchi totali (diversi). La Tabella 4.2 mostra un pro-spetto degli attacchi rilevabili a seconda del tipo di attività (host o network),a diverse granularità. Per “istanze raggruppate” s’intende il conteggio effet-tuato contando una sola volta le istanze con lo stesso identificatore, ovvero gliattacchi lanciati durante la stessa sessione.

4.5 DATASET ALTERNATIVI

Vista l’obsolescenza, la scarsa qualità e gli altri difetti del dataset IDEVALè naturale chiedersi perché, dopo più di sei anni, la ricerca sugli IDS conti-nui ad utilizzarlo. Il motivo principale non è la mancanza di altri dataset mal’impossibilità di utilizzarli.

Tra i principali requisiti per un buon dataset si ritrovano:

I. separazione (o separabilità) di “attività normale” da “attività con non-normalità”: nel caso del traffico di rete si tratta di “traffico senza attacchi”e “traffico normale misto ad attacchi”.

II. etichettatura di tutte le istanze di comportamento non normale: nel casoè sufficiente la presenza di un TF.

III. generalità e aderenza alla realtà, per evitare problemi di overfitting erisultati di valutazione poco significativi.

I primi due hanno a che fare non solo con la necessità di verificare gli allar-mi ma con la ripetibilità degli esperimenti e sono il motivo principale per cuiè difficile produrre un dataset significativo. Inoltre, per motivi di riservatezza,non è facile ottenere concessioni per raccogliere traffico su una rete reale (ades., di un’azienda).

Altre possibili sorgenti di dati che, in un modo o nell’altro, catturano l’at-tività di un sistema informatico sono:

Capture the Capture The Flag — Nella forma delle immagini di alcuni deglihost che hanno partecipato al Capture The Flag (CTF) DEFCON (ed. 8 e10), questi dati sono stati resi pubblici da The Shmoo Group [?] con li-cenza che ne impedisce l’uso a scopi commerciali. Per queste tracce non

54

Dataset alternativi

è disponibile alcun TF e, particolare più importante, non esiste traffi-co normale: il CTF DEFCON è un contest di sicurezza in cui il trafficoprincipale è costituito da attacchi.

KDD Cup ’99 — Sono una rielaborazione dei dati IDEVAL e sono disponibilipresso [?]. I dati originali sono stati mantenuti ma sono stati suddivi-si per connessione. Si tratta più di un tentativo di migliorare il datasetesistente; tuttavia questi dati non sono più utili di IDEVAL.

Treasure Hunt — Questo dataset è il risultato di un esercizio condotto da al-cuni studenti della UCSB [?]. Resi disponibili da G. Vigna, sono statiregistrati da diversi tipi di sensori i quali hanno prodotto: dump di re-te in formato Pcap, log di Apache, di sistema (Syslog e Windows EventLog) e auditing del kernel (Snare e BSM). L’arco di tempo è di qualcheora, durante il quale due squadre si sfidavano in una “caccia al tesoro”informatica. Neanche per questi dati è disponibile un TF.

Ethereal Sample Capture — Per la maggior parte si tratta di dump di retein formato Pcap [?]. Sono stati pubblicati dagli autori di Ethereal [?] ascopo di test e includono attività dei protocolli applicativi più diffusi.Sono reali e coprono la quasi totalità dell’attività di una rete. Tuttavia,oltre a non poter ricostruire la situazione, sono stati catturati a blocchi,per ogni applicazioni: manca quindi il concetto di tempo.

4.5.1 METODI ALTERNATIVI PER LA VALUTAZIONE

Prima che il LL pubblicasse IDEVAL, i primi studi e i primi tentativi di pro-porre una metodologia rigorosa per la valutazione degli IDS furono [?] e [?].Gli autori propongono una metodologia ed un’applicazione a supporto delleattività di test di un IDS. Di fatto si tratta di una serie di script che automa-tizzano la generazione di traffico e intrusioni. Tuttavia, come fatto notare in[?], i risultati pubblicati, riguardo al test di un IDS network-based, mancanodi ogni forma di analisi sistematica.

Dopo quelle di Puketza (et al.) e dopo IDEVAL vi furono altre proposte perla valutazione dell’efficacia degli IDS [?; ?], alcune delle quali vanno oltre l’im-piego di dataaset ma propongono, ancora, un applicativo per la generazionedi traffico e attacchi.

LARIAT

In particolare, LARIAT [?] è una proposta del LL che si propone come esten-sione del progetto IDEVAL. In realtà LARIAT è, a detta degli autori, una verae propria piattaforma completa per la valutazione degli IDS.

Il sistema permette una valutazione on-line e automatizzata degli IDS, apartire dalla generazione del traffico, fino alla verifica degli attacchi rilevatio meno e, addirittura, alla gestione di vari profili di traffico/attacchi. L’analisidell’output degli IDS è ancora una feature “sperimentale”, probabilmente per

55


Configurazione del traffico base

Configurazione traffico attacchi

Configurazione network/host

Distribuzione configurazione

Verifica degli attacchi

Calcolo FP/VP/VN/FN

Generazione reportisticaGUI

Network director

Profili di traffico

Prof. fusione attacchi

Script attacchi

Installazione e riconfigurazione Traffico di base Scheduler

degli attacchiVerificatore

attacchi IDS

File configurazione

Script di trafficoScript di trafficoScript di traffico

Script di trafficoScript di traffico

Script degli attacchi

Script di trafficoScript di trafficoLog

XML XMLNetwork

FIGURA 4.4: Architettura di alto livello di LARIAT.

FIGURA 4.5: Fasi di un esperimento automatizzato con LARIAT. In evidenza, l’unicafase in cui è richiesta interazione con l’utente.

la difficoltà di dover gestire una moltitudine di formati potenzialmente mol-to varia. Il tutto è supportato da un’interfaccia grafica, mostrata in Figura ):l’architettura è schematizzata in Figura.

LARIAT permette di istanziare degli esperimenti generici modificando alcuniparametri di configurazione. Il punto di partenza di ogni esperimento è una re-te di base, specificata come un insieme di host interconnessi. Le fasi successivemostrate in Figura 4.5 sono tutte automatizzate, tranne la prima in cui l’uten-te seleziona il profilo del traffico e le istanze degli attacchi (con i relativi tempi diesecuzione).

Dopo aver distribuito le configurazioni (istanziazione dell’esperimento) il ge-neratore di traffico inizia a sintetizzare del traffico simulato, a seconda del pro-

56

Dataset alternativi

!"#$%&'()*)&'+,-

!"#$#% "&'%('&)*&+',% -."-% (&'("&'% )*&% -.'% )/*0%*)% #12-.'-34%

-&"))345% % !.'% -&"))34% 6'2'&"-*&#% #12-.'#37'% 8#'&% -&"))34% 91%

983/,326%#4&3(-#%)*&%'"4.%9"4$6&*82,%-&"))34%#'##3*25%%!.'#'%

#4&3(-#% 8#'% "% 48#-*+% ':-'2#3*2% ;<=% -*% -.'% >:('4-% #4&3(-326%

/"268"6'% ;?@=A% ;?B=% -."-% 0"#% ,'C'/*(',% )*&% -.'% ?BB@% "2,%

?BBB% 'C"/8"-3*2#5% % D32'E6&"32',% 4*2-&*/% *)% .*0% /*26%

#3+8/"-',%.8+"2%8#'&#%0"3-%9'-0''2%'2-'&326%4*++"2,#%32%

32-'&"4-3C'%#'##3*2#%"2,%.*0%/*26%3-%-"$'#%-*%-1('%4*++"2,#%

8#326%(&*9"93/3#-34%32-'&E4."&"4-'&%,'/"1#%3#%(*##39/'5%%F--"4$%

#4&3(-#% "&'% "/#*% (&'("&',% #*% -."-% 9*-.% -.'% "--"4$% "2,%

9"4$6&*82,% -&"))34% #4&3(-#% 4"2% 9'% #4.',8/',% -*% &82% "-% -.'%

"((&*(&3"-'%-3+'#%*2%'"4.%-&"))34%6'2'&"-*&%"2,%"--"4$'&5%%%

%

./'-0"122)3,-

F-%-.3#%(*32-%-.'%'C"/8"-3*2%4*++'24'#5%%G8&326%-.'%&82A%-.'%

(&*6&'##%*)%9"4$6&*82,%-&"))34%"2,%"--"4$#%4"2%9'%C3'0',%32%

&'"/E-3+'%C3"%-.'%HIJ5%%%

%

4#")25-1'(-63&"#,-

I(*2%4*+(/'-3*2%*)% -.'%&82A%*&%"-%"%#('43)3',%32-'&C"/%")-'&%

'"4.%"--"4$A%-.'%#1#-'+%#4"2#%"--"4$'&%/*6#%"2,%#'"&4.'#%)*&%

'C3,'24'% *)% -.'% "--"4$% *2% -.'% C34-3+% .*#-A% 32% "2% '))*&-% -*%

C'&3)1%-.'%#844'##)8/%4*+(/'-3*2%*)%'"4.%"--"4$5%%F/'&-#%)&*+%

-.'% JG% #1#-'+#% "&'% #-*&',% )*&% "2"/1#3#% #*% -."-% -.'1% 4"2% 9'%

4*+("&',%"6"32#-%"%C'&3)3',%/3#-%*)%"--"4$#5%%%

H'2'&"-3*2% *)% 9"4$6&*82,% -&"))34% 3#% 3+(*&-"2-% 9'4"8#'% 3-%

(&*C3,'#% &'"/% 8#'&% -&"))34% *2% -.'% 2'-0*&$% 03-.32% 0.34.%

"--"4$#%03//%9'% 32K'4-',5% % J,'"//1%"2% JG%#1#-'+%#.*8/,%*2/1%

#'2,% "/'&-#% 0.'2% 3-% 3,'2-3)3'#% &'"/% "--"4$#% L-&8'% ,'-'4-3*2#M%

"2,% 2*-% 0.'2% "% 8#'&% ('&)*&+#% "% /'63-3+"-'% "4-3*2% L)"/#'%

"/"&+M5%

J2% )8-8&'% C'&#3*2#A% NFOJF!%+36.-% 9'% "9/'% -*% #4*&'% "2% JG%

#1#-'+% 91% 32-'&(&'-326% 2"-3C'% JG% "/'&-#5% % P8&&'2-/1% -0*%

(&*9/'+#% ':3#-5% % D3&#-% '"4.% C'2,*&% 8#'#% "% (&*(&3'-"&1%

+'##"6'%"/'&-%)*&+"-% -."-%0*8/,%&'Q83&'%"%48#-*+%("&#'&%-*%

32-'&(&'-% -.'% +'##"6'% 4*2-'2-5% % !.'% J>!D% 4*++823-1% 3#%

*C'&4*+326% -.3#% (&*9/'+% 91% 4&'"-326% -.'% JGR>D% #-"2,"&,%

-*% #-"2,"&,37'% -.'% JG% "/'&-% )*&+"-S% -.*86.% 48&&'2-/1% -.'%

+'##"6'% 4*2-'2-% )*&+"-% 32% 2*-% #-"2,"&,37',% "2,% C"&3'#%

9'-0''2%8#'&#5%

%

%7#1'-89,-

F)-'&% -.'%C'&3)34"-3*2%"2,% #4*&326A% 4/'"28(% #4&3(-#A% #('43)34%

-*%'"4.%"--"4$A%&'+*C'%'C3,'24'%*)%-."-%"--"4$%&82A%&'#'--326%

"21%4."26'#%+",'%91%-.'%"--"4$%#4&3(-5%%F%4/'"28(%4"2%&"26'%

)&*+%&'32#-"-326%"%4*&&8(-',%)3/'% -*%&'#-*&326%"2%'2-3&'%."&,%

,&3C'% )&*+%"% #-*&',% 3+"6'5% %T*#-#% 32C*/C',% 32%9"4$6&*82,%

-&"))34% "&'% "/#*% &'E323-3"/37',5% %P*2-328326%8#'&% #'##3*2#%"&'%

$3//',A%"#%32%-.'%'"&/3'&%UJ23-3"/37"-3*2V%(."#'A%-*%'2#8&'%-."-%

-'#-%&82#%#-"&-%)&*+%4*++*2%#1#-'+%#-"-'A%'C'2%3)%"%-'#-%&82%

3#% -'&+32"-',% 9')*&'% 4*+(/'-3265% % F)-'&% -.3#% /"#-% #-'(%

",,3-3*2"/%':('&3+'2-#%4"2%9'%&825%

%

:;:--<13=>"&/'(-0"122)3W-

!*%#-"&-%"% -'#-% &82A%"%8#'&%+8#-% )3&#-%#'/'4-%"%(&*)3/'% )*&% -.'%

9"4$6&*82,%-&"))345%%F%9"4$6&*82,%-&"))34%(&*)3/'%,')32'#%-.'%

*('&"-326% '2C3&*2+'2-% -*% 9'% #3+8/"-',% 91% -.'% -'#-9',% "2,%

4*2-"32#% 32)*&+"-3*2%#84.%"#% -.'% -1('%*)%#'&C34'#% L'65%.--(A%

)-(M%-."-%03//%9'%'+8/"-',A%-.'%#-"-3#-34"/%,3#-&398-3*2%*)%'"4.%

#'&C34'%*C'&% -.'% 4*8&#'%*)% "%,"1A% "2,% -.'% -&"))34% &"-'5% %!.'%

9"4$6&*82,% -&"))34% (&*)3/'% 4"2% 9'%+*,3)3',%03-.% &'#('4-% -*%

-.'%4*2-'2-%"2,%,3#-&398-3*2%*)%#'&C34'#5%%%

!.'% -&"))34% (&*)3/'#% 0'&'% ,'-'&+32',% 91% &'4*&,326% "2,%

"2"/17326% -.'% 2'-0*&$% -&"))34% ,3#-&398-3*2% "2,% 4*+(*#3-3*2%

)&*+%"%IX%+3/3-"&1%9"#'5%%Y'0%-&"))34%(&*)3/'#%4"2%9'%",,',%

"2,%4*2)368&',%-*%#83-%"%("&-348/"&%2'-0*&$%'2C3&*2+'2-5%

D368&'%Z% #.*0#%.*0%"%8#'&% 4"2% #'-8(%"2%':('&3+'2-5% %!.'%

-*(%(*&-3*2% 32% -.'%("2'/%"//*0#% -.'%':('&3+'2-'&% -*%4*2-&*/%

':('&3+'2-% ,8&"-3*2% "2,% #'/'4-% "% (&'C3*8#/1% ,')32',%

9"4$6&*82,%-&"))34%(&*)3/'5%%[1%',3-326%-.'#'%(&*)3/'#%"%8#'&%

4"2%Q834$/1%#'-8(%"2,%&82%"2%':('&3+'2-5% %D32'&%4*2-&*/%*)%

-&"))34% 6'2'&"-3*2% 4"2% 9'% "4.3'C',% 91% #'/'4-326% -.'%

?(@1'3#(%98--*25%

D368&'% \% #.*0#% "% #4&''2% 4"(-8&'% *)% -.'% ("2'/% -."-% "//*0#%

9"4$6&*82,% -&"))34% +*,3)34"-3*25% % !.'% 8(('&% ("&-% *)% -.'%

("2'/%#.*0#%-.'%"66&'6"-'%-&"))34%-*%9'%6'2'&"-',A%324/8,326%

-.'%#-"&-%"2,%'2,%-3+'#A%"%6/*9"/%&"-'%+*,3)3'&A%"2,%(&*)3/'#%

*)%-.'%"&&3C"/%&"-'#%*)%-.'%8#'&%#'##3*2#%*)%'"4.%-&"))34%-1('5%%

!.'% -&"))34% (&*)3/'% 6&"(.% 63C'#% -.'% ':('4-',% 28+9'&% *)%

#'##3*2% "&&3C"/#% L1E":3#M% )*&% '"4.% ?]E+328-'% 32-'&C"/%

-.&*86.*8-%"%Z^E.*8&%,"1%L:E":3#M5%%!.'%/*0'&%("&-%*)%D368&'%

\%#.*0#%.*0%-.'%8#'&%#('43)3'#%-.'%"+*82-%*)%D!_%-&"))34%-*%

9'% 6'2'&"-',A%03-.% -.'% (&*)3/'% )*&% -.'%D!_% #'##3*2% "&&3C"/#%

('&%?]E+328-'% -3+'% 32-'&C"/A%*2%"%#3+3/"&%6&"(.%L(/*--',%91%

3-#'/)M5%%F&&3C"/%&"-'%"2,%,3#-&398-3*2%*)%#'##3*2#%*)%'"4.%-1('%

4"2%9'%",K8#-',%-*%#('43)1%"66&'6"-'%4*2-'2-%*)%9"4$6&*82,%

-&"))345%%!.3#%"//*0#%-'#-326%*)%"2%32-&8#3*2%,'-'4-3*2%#1#-'+%

32% "% &"26'% *)% *('&"-326% '2C3&*2+'2-#% *&% -'#-326% *)% #1#-'+%

-.&*86.(8-%03-.%.36.%-&"))34%&"-'#5%%%%

%

%D368&'%Z%E%!.'%NFOJF!%HIJ%(&*)3/'E#'/'4-3*2%("2'/5%

FIGURA 4.6: Esempio di interfaccia grafica di LARIAT, così come appare da unoscreenshot pubblicato sull’articolo.

filo specificato e a partire da una serie di script ad hoc che si occupano di creareil traffico vero e proprio.

Le fasi successive sono il cuore dell’esperimento: il traffico (con i relativi at-tacchi) viene “eseguito” e i risultati del test (attacchi rilevati) vengono accu-mulati in opportuni file di log.

Sebbene LARIAT costituisca un notevole passo avanti rispetto a IDEVAL(di fatto fa risparmiare molto tempo), non è immune da problemi. Innanzitut-to, come fatto notare in [?], non è stato effettivamente rilasciato pubblicamentema è disponibile solo in alcune “circostanze” non chiare: al 2001 il sistema erastato provato in un totale di quattro laboratori. Inoltre, gli attacchi predefinitisono ancora quelli di IDEVAL (1998–99). Non solo, sembra che gli script inclusiper generare il traffico di base siano gli stessi di IDEVAL. Anche se gli autori ri-cordano che il sistema è perfettamente personalizzabile, il resto dei ricercatoripotrebbe chiedersi quando ciò sarà possibile, visto che dopo cinque anni nonesiste ancora una versione rilasciata: [?].

SPLOIT

Sviluppato da G. Vigna e D. Balzarotti [?], SPLOIT si concentra invece sull’a-nalisi dei soli attacchi e, in particolare, sulla reazione di un IDS alle tecnichedi evasione [?]. Si tratta comunque di un sistema per automatizzare la valuta-zione dell’efficacia ma, invece di guardare al riconoscimento degli attacchi sioccupa di verificare quanto sia possibile “nascondere” gli attacchi.

Come descritto in [?] esistono diverse tecniche per evadere il controllo diun IDS. In generale, mutando un attacco è possibile farlo passare come “attività

57


Exploit

OracoloValutazione

Risultati

IDS 1 IDS 2 IDS n. . .

AllarmiAllarmiAllarmi AllarmiAllarmiAllarmi AllarmiAllarmiAllarmi

AllarmiAllarmiTemplate AllarmiAllarmiMutatori

AllarmiAllarmiMutante

Motore di mutazione

Vittime(applicazioni)

FIGURA 4.7: Architettura schematica di SPLOIT, un framework per la verificadell’efficacia delle tecniche di evasione (mutazione di attacchi).

normale”. L’architettura in Figura 4.7 da un’idea del funzionamento: a partireda un insieme di attacchi generici (exploit templates) si applicano varie com-binazioni di operatori di mutageni e si verifica via via il risultato riportato dagliIDS.

Sebbene quest’idea sia molto utile nel contesto attuale (si veda la Sezione2.3) risulta un approccio piuttosto qualitativo e, in ogni caso, rimane limitatoalla verifica dell’efficacia delle tecniche di evasione: non può essere conside-rato uno strumento per la valutazione di efficacia generale. Per questo motivosi è pensato di menzionarlo soltanto.

58

— CAPITOLO 5 —

VALUTAZIONE E INTERVENTI SUI

PROTOTIPI ESISTENTI

Presso il Dipartimento di Elettronica e Informazione del Politecnico di Milanosono stati messi a punto due prototipi per anomaly detection host e network-based. Visto che il resto del lavoro è basato sulle anomalie e sul funzionamentodi tali strumenti, lo scopo di questo capitolo è valutarne l’efficacia e presentarei problemi riscontrati. Oltre alla documentazione dei risultati sperimentali siriportano anche alcuni dettagli implementativi, sia degli strumenti originalisia delle modifiche apportate per migliorarne le performance.

5.1 PARTE HOST-BASED

Questa sezione descrive l’architettura, le caratteristiche distintive ed i suppor-ti teorici impiegati nel prototipo di IDS host-based analizzato [?]. Il prototipo èstato sviluppato presso il Politecnico di Milano, nell’ambito di ricerca sulla si-curezza di reti e applicazioni. Il sistema è la risposta a syscallAnomaly e, a tuttigli effetti, ne costituisce un’estensione. Per un’introduzione a syscallAnomalysi veda la Sezione 3.6.

5.1.1 ARCHITETTURA E CARATTERISTICHE

L’architettura, non documentata, è stata dedotta dall’analisi dell’implementa-zione e, in parte, dal tipo di algoritmi utilizzati, descritti in seguito. L’architet-tura dell’analizzatore è mostrata in Figura 5.1: sono state distinte le due fasiprincipali di training e detection, con le relative linee temporali.

In fase di training le chiamate di sistema vengono raggruppate in sequenzeognuna delle quali viene analizzata a livello di singola chiamata. Una primafase si occupa del clustering delle chiamate, i cui dettagli verranno presentatiin seguito. Lo scopo è quello di ridurre le dimensioni degli ingressi raggrup-pando le invocazioni a chiamate di sistema simili. L’ipotesi di fondo è cheuna stessa chiamata possa comportarsi in un numero numerabile di modi, aseconda degli argomenti con cui viene invocata.

Una seconda fase, a partire dalla sequenza dei cluster corrispondenti adogni chiamata, considera le chiamate immerse nel proprio contesto di esecu-zione. Il comportamento dell’intera sequenza, e quindi la correlazione tra lediverse chiamate che la compongono, viene sintetizzato in un modello di Mar-kov (del prim’ordine). Ogni chiamata, identificata dal cluster di appartenen-za, è uno dei possibili stati del modello di Markov (che descrive il processo delprogramma); le transizioni da una sequenza e l’altra viste durante il trainingcontribuiscono invece a determinare le probabilità di transizione del modello.

59

5. VALUTAZIONE E INTERVENTI SUI PROTOTIPI ESISTENTI

Argomenti [arg1, arg2, ..., argN]Nome

exit

Sequ

enza

[PID

, Pro

gram

ma]

Scel

ta e

cre

azio

ne d

ei m

odel

li ag

greg

atiArgomenti [arg1, arg2, ..., argN]execve

modello1 modello2 ... modelloN

Argomenti [arg1, arg2, ..., argN]Nome

Clus

terin

g de

lle c

hiam

ate

rispe

tto a

i mod

elli

Tempo (fase addestram

ento)

Memorizzazione del modello di Markov del progr. (nodi = cluster)



. . .. . .

Sequ

enza

di

Clus

ter

[Pro

gram

ma]

Tempo (fase operativa)

Confronto comportamento e calcolo grado di anomalia

Confronto con (i cluster di) chiamate note

. . .

Sequ

enza

di

Clus

ter

[Pro

gram

ma]

Sequ

enza

di

Clus

ter

[Pro

gram

ma]

Sequ

enza

di

Clus

ter

[Pro

gram

ma]

Sequ

enza

di

Clus

ter

[Pro

gram

ma]

. . .

Sysc

all

Sysc

all

Sysc

all

Sysc

all

Sysc

all

Sysc

all

Sysc

all

Sysc

all

Sysc

all

Sysc

all

Sysc

all

Sysc

all

Sysc

all

Sysc

all

Sysc

all

FIGURA 5.1: Schema dell’architettura dell’analizzatore del prototipo host-based.

In fase di detection, le sequenze vengono processate come appena descrit-to. In più viene stabilito il grado di anomalia di ogni chiamata e di ogni se-quenza. Una chiamata è considerata anomala se è “troppo diversa” da chia-mate dello stesso tipo analizzate in fase di clustering. Una sequenza è conside-rata anomala se si comporta in modo “troppo diverso” da quanto descritto dalmodello di Markov. Nel seguito si darà una descrizione precisa e quantitativadi cosa s’intende per “diversità”.

60

Parte host-based

5.1.2 SUPPORTI TEORICI

Non è scopo di questa sezione analizzare le motivazioni e i risultati origina-li riguardanti il prototipo, pertanto ci si limita a riportare in modo oggettivoi concetti necessari per comprendere il funzionamento e gli algoritmi utiliz-zati. Rispetto alla parte network-based, questa parte risulta più dettagliata,dal momento che contiene elementi di originalità che non sono descritti inletteratura.

CLUSTERING DELLE CHIAMATE

Come anticipato, la prima fase dell’addestramento consiste nell’analisi dellesingole syscall che vengono raggruppate utilizzando un algoritmo di cluste-ring gerarchico. A questo scopo costruisce una matrice delle distanze di ognichiamata rispetto a tutte le altre ed impiega un algoritmo di tipo bottom-upper creare i cluster. Il processo di clustering lavora su un tipo di chiamataper volta, mentre l’intero processo di training e la fase operativa funzionanoanalizzando l’attività di un programma per volta.

La caratteristica più importante dell’implementazione è il criterio con cuiviene valutata la distanza. In particolare impiega una misura aggregata, ovverola somma delle distanze tra le coppie di argomenti corrispondenti:

D(cj , ck) :=n∑

i=1

dτ (ai,j , ai,k) τ ∈ T

dove cj , ck sono le due chiamate, ai,j , ai,k sono i rispettivi argomenti i-esimi e d(·) è la funzione di distanza tra i due argomenti. A seconda del tipo diargomento τ il sistema prevede una serie di funzioni di distanza. Tali funzionisono basate sui modelli spiegati in dettaglio nel paragrafo dedicato; ne esisteuno per ogni tipo e sono:

T = {path, disc, args, guid}

dove:

path indica il tipo “percorso nel filesystem”, ad esempio:

“/usr/local/lib/libvolmgr.so.1”

disc indica il tipo “valori discreti numerici”.

args indica il tipo “argomenti di esecuzione” alla chiamata execve. Ad esem-pio:

“/usr/bin/sendmail, /usr/lib/sendmail [email protected]”

guid indica il tipo “identificatore gruppo/utente”. Si tratta di token numericiche identificano il gruppo/utente in un sistema UNIX.

61


Il criterio di terminazione del processo di clustering è invece completamenteparametrico ed è regolabile a livello di configurazione. Un primo parametrostabilisce la distanza limite oltre la quale due cluster sono considerati eccessiva-mente distanti per essere raggruppati. Un secondo parametro specifica inveceil numero minimo di cluster oltre il quale il processo deve arrestarsi. Il primo deidue criteri che interviene ferma il processo di raggruppamento gerarchico.

Modelli degli argomenti Non esistendo alcun centroide sui cui basare lascelta del cluster di appartenenza di un nuovo elemento, sia in fase di cluste-ring che in fase di detection, viene calcolato con che probabilità un nuovo ele-mento appartenga ad un cluster: ogni elemento appartiene quindi ad un clu-ster con una certa probabilità. Questa misura è basata sui diversi modelli chevengono utilizzati a seconda del tipo di argomento. I modelli implementatisono:

path — In fase di clustering il modello è costituito dalla profondità del per-corso quindi la distanza è proporzionale alla differenza delle profondità,ovvero dpath(ai, aj) = Kpath + αpath|#/(ai) − #/(aj)| dove #/(x) è ilnumero di occorrenze di ‘/′ in x. In fase di detection viene utilizzato unmodello ad albero probabilistico, creato per ogni cluster, che rappresen-ta il tipo di percorsi contenuti in quel cluster. Dato un nuovo percorso,la probabilità ritornata dal modello è Ppath = Pa · Pf dove Pa è la pro-babilità che il percorso sia stato generato dall’albero e Pf = 1 se il nomedel file è stato “visto” durante il training (oppure se si è deciso di igno-rare i file); altrimenti Pf = 0. Quest’ultimo criterio è a nostro avvisotroppo pessimistico per questo abbiamo deciso di disattivarlo a livellodi configurazione.

disc — Questo modello è molto semplice, dal momento che due valori discretipossono essere solo uguali o diversi, perciò:

ddisc(ai, aj) ={

Kdisc se ai 6= aj

0 se ai = aj

Allo stesso modo, la probabilità ritornata sarà zero se il cluster non con-tiene l’argomento o il numero di occorrenze (normalizzato) del valoretra quelli memorizzato nel cluster.

args — Similmente al precedente, ma fa uso della lunghezza della stringa,ovvero:

ddisc(ai, aj) ={

Kdisc se |ai| 6= |aj |0 se ai = aj

Similmente, la probabilità ritornata sarà zero se la lunghezza del nuovoargomento non è compresa tra la lunghezza massima/minima relativeagli argomenti nel cluster.

guid — Vengono trattati a seconda del gruppo (utenti di sistema o altri utentio root) di appartenenza. La distanza è:

ddisc(ai, aj) ={

Kdisc se appartengono a gruppi diversi0 altrimenti

62

Parte host-based

La probabilità ritornata dal modello è 0 o 1 a seconda che l’argomentonon appartenga o appartenga al set di quelli appresi.

Tutti i modelli sono parametrici rispetto ad un K(·) il cui valore è specifi-cabile durante la configurazione. Lo stesso vale per αpath. Per ogni modello èstato stabilito un criterio per stabilire, in fase di clustering, un nuovo modelloaggregato nel momento in cui due cluster vengono uniti.

MODELLI DI COMPORTAMENTO

Come accennato, si utilizza il formalismo dei modelli di Markov del primoordine, non nascosti, per descrivere il comportamento di un programma, intermini di sequenze. Durante la fase di addestramento, dopo aver creato icluster di tutti i tipi di chiamata, una fase di classificazione fa uso dei model-li descritti in precedenza per assegnare ogni chiamata al cluster più simile;viene scelto il modello che massimizza la probabilità composta max (

∏i Pi).

Più sequenze vengono modellizzate e più il modello di Markov descriverà ilcomportamento del programma.

Durante la fase di detection, il criterio secondo cui una sequenza viene con-siderata anomala è basato su due soglie (probabilistiche): threshold di sequenzae threshold di transizione. Il loro significato è il seguente:

I. threshold di sequenza indica la soglia entro cui, all’arrivo di una exit, lanuova sequenza è considerata ben spiegata dal modello markoviano. Du-rante la fase di training, per ogni istanza di esecuzione, viene memo-rizzata la probabilità dell’intera sequenza: la più bassa tra queste vienescelta come threshold di sequenza. In fase di training, una sequenza conprobabilità PS inferiore è segnalata come anomala;

II. threshold di transizione indica la soglia entro cui, all’arrivo di una chiamataqualsiasi cj , tale chiamata è da considerarsi un “buon stato successivo”a quella precedente ci. In fase di testing viene calcolato il grado di ap-partenenza Pc(cj) della chiamata cj al cluster più vicino e viene moltipli-cato per la probabilità di transizione Pt(ci, cj) nel modello di Markov; laprobabilità di transizione totale risulta: PT = Pc(cj) · Pt(ci, cj). Anche inquesto caso si sceglie il minimo come threshold.

A questo punto, la fase di detection è semplicissima in quanto basata subanali confronti tra probabilità e threshold memorizzate.

5.1.3 TIPO DI IMPLEMENTAZIONE E FUNZIONAMENTO

Il prototipo è implementato in linguaggio Perl. L’architettura non è documen-tata ma è ricavabile osservando il modo in cui lo sviluppatore ha modulariz-zato il codice. Ovvero:

model.pm è il modulo che astrae la gestione dei vari tipi di modelli di (argo-menti di) chiamate.

63


markov.pm è il modulo che si occupa della creazione e della serializzazionedei modelli di transizione.

tree.pm mette a disposizione un’astrazione necessaria a Model.pm per il mo-dello dell’albero di directory (relativo agli argomenti di tipo “percorsonel filesystem”).

view.pm mette a disposizione alcune funzioni utili per la visualizzazione inconsole delle singole syscall con alcune procedure di traduzione di for-mato (ad esempio, per il formato dei timestamp).

Interfacce L’interfaccia offerta per la configurazione dei parametri è, difatto, il modulo config.pm: per modificare la configurazione è necessario quin-di editare a mano il valore di alcune variabili dichiarate e inizializzate inquesto modulo.

L’interfaccia per l’utilizzo è costituita da un eseguibile Perl, build.pl, checome vedremo permette

• specifica del tipo di funzionalità (training o testing) da invocare;

• specifica del percorso dei file di testing/training;

• variazione della verbosità dell’output per il debugging.

Formati di I/O Sia in fase di training che in fase di testing (detection) l’u-nico output disponibile è lo standard output: in nessun modo questo sistemaprevede funzionalità di logging o integrazione con altre facilty per il report diattività.

L’input è costituito da uno stream di testo: una forma, opportunamentemodificata, dell’output di syscallAnomaly che altro non è che una sequenzadi stringhe di testo separate dall’escape \n. Ogni stringa (linea) è la rappre-sentazione di un evento (syscall) marcato nel tempo secondo il formato NTPTimestamp (documentato in [?]). Lo schema di ogni linea è così specificabile:

0xSsecs.0xUsecs ProcName? SyscallName: SyscallArguments

Abbiamo modificato libAnomaly e syscallAnomaly in modo da aggiungereil PID del processo ottenendo il formato di input ufficiale per il prototipo:

0xSecs.0xUsecs ProcName? (PID) SyscallName: SyscallArguments

dove SyscallArguments è nella forma

SyscallArgument_1, ..., SyscallArgument_i, ..., SyscallArgument_N

• 0xSecs.0xUsecs è il timestamp. La parte 0xSecs rappresenta i secondiin esadecimale, la parte 0xUsecs i microsecondi in esadecimale.

• ProcName è il nome del processo che, come indicato dal ?, può anchenon essere presente (nel caso in cui il processo non sia ancora nato o siaappena morto).

64

Parte host-based

• SyscallName è il nome della chiamata, ad esempio: open, execve, exit.

• SyscallArgument_i è a sua volta strutturato come SyscallArgument-Type(Value) dove SyscallArgumentType è il tipo di argomento (strin-ga, intero) e Value è il valore.

5.1.4 PROBLEMI RISCONTRATI ED ESTENSIONE DEI TEST ORIGINALI

I principali problemi riscontrati riguardano la necessità di dover prepararel’input. Inoltre, dall’analisi del comportamento del prototipo durante il trai-ning sono emersi dei dettagli non evidenziati dall’autore: innanzitutto il trai-ning deve essere effettuato per-programma, non è possibile addestrare il si-stema su tutti i programmi incontrati in un file .systr. Di più, se sivuole effettuare il training per un certo programma, sembrerebbe che i file.systr di training debbano contenere dei tracciati relativi al solo programmad’interesse.

Lo strumento non è quindi predisposto per training massiccio automatiz-zato, tanto meno per testing massiccio automatizzato. La strada corretta sareb-be la riprogettazione della gestione degli input; per motivi di tempo abbiamoinvece optato per la creazione di programmi ausiliari per la preparazione au-tomatica dell’input e l’invocazione automatica delle procedure di training etesting. A questo scopo sono stati creati alcuni script ad-hoc:

• bsm2systr automatizza, usando syscallAnomaly, la conversione da fileBSM a file .systr rendendola batch.

• IdevalParser e IdevalSplitter implementano una libreria di parsingper file .systr (e per TF) ed un sistema che automatizza lo splitting diun singolo file .systr in diversi .systr, ognuno che raggruppi syscallrelative allo stesso programma. Il parser implementa anche un piccolomotore di query per realizzare agevolmente procedure di selezione eproiezione sui parametri di ogni singola riga dei file .systr.

I dati utilizzati per effettuare il training sono stati preventivamente rag-gruppati per programma a partire dai log BSM del dataset IDEVAL, convertitiin .systr. I dati sono riassunti in Tabella 5.1.

Il training è risultato nella creazione di 118 modelli di transizione (e relati-ve soglie). I cluster creati sono 531. In Tabella 5.2 è riportato il confronto con iltraining effettuato dallo sviluppatore originale.

Risultati sperimentali In Figura 5.2 è riportata la curva ROC relativa alfunzionamento del prototipo originale. Tenendo conto che si tratta di un si-stema di anomaly detection il risultato è più che accettabile, anche se per DRprossime al 95-100% l’entità dei falsi positivi inizia a non essere più trascu-rabile (4%). Lo scopo delle sezioni successive è dare una spiegazione dellemodifiche apportate alle fasi principali di training e testing, nel tentativo direndere più accurato il processo di detection.

65


GIORNO #SYSCALL #PROGR. DIVERSI

Prima settimanaLunedì 97645 111Martedì 34932 67Mercoledì 41134 129Giovedì 50240 152Venerdì 38292 115

Terza settimanaLunedì 53076 128Martedì 41494 128Mercoledì 69375 155Giovedì 58706 177Venerdì 50687 117

TABELLA 5.1: Dati per il training massiccio del prototipo host-based.

TRAINING ORIGINALE NUOVO TRAINING

Mod. tran. memoriz. 0 188Cluster memorizz. 22 531Programmi diversi 7 206

TABELLA 5.2: Confronto con il training effettuato in origine dallo sviluppatore delprototipo.

0

20

40

60

80

100

0,000 2,000 4,000 6,000 8,000 10,000 12,000

FPR (%)

DR

(%

)

FIGURA 5.2: Curva ROC del prototipo host-based originale.

PROBLEMI IN FASE DI THRESHOLD

Tra le altre grandezze, durante la fase di training vengono calcolate le thresholddi sequenza che altro non sono che delle probabilità. Con la stessa procedura, infase operativa vengono calcolate le probabilità di sequenza (relativamente almodello di Markov). In entrambe le fasi abbiamo notato che i valori di queste

66

Parte host-based

20 30 40 50 60 70 80 90 100 110 120−0.5

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5x 10

−4

Lunghezza sequenza

Val

ore

thre

shol

d

FIGURA 5.3: Variazione della probabilità minima (threshold) di sequenza al variaredella lunghezza della sequenza.

variabili tendono rapidamente a zero: sostanzialmente questo effetto dipendedalla relazione tra lunghezza della sequenza e threshold di sequenza che può essereapprossimata come:

PS(l) ∝l∏

i=1

PC(i)

dove PC(i) è la probabilità della chiamata i-esima ed l è la lunghezza dellasequenza (in numero di chiamate). Dal momento che PC(·) ∈ [0, 1] è facilecapire come

liml→+∞

PS(l) = 0

Questo fenomeno tende quindi ad abbassare molto la probabilità del ve-rificarsi di sequenze lunghe (calcolato con lo stesso procedimento in fase didetection), le quali vengono quindi penalizzate e segnalate come anomale.Sperimentalmente è stato comunque possibile confermare questo fenomeno,osservando come varia il threshold di una sequenza (e quindi la probabilitàminima) al variare della lunghezza della sequenza.

Il risultato in Figura 5.3 dimostra come, per chiamate di lunghezza l > 30la probabilità sia praticamente nulla (dell’ordine di 10−24).

Per risolvere questo problema è necessario effettuare una sorta di “nor-malizzazione”. A questo scopo abbiamo modificato la funzione per il calcolo

67


della probabilità (e quindi delle threshold) di sequenza in modo da renderlauna media geometrica, rallentando in questo modo la discesa a zero:

PS(l) ∝ l

√√√√ l∏i=1

PC(i)

in questo modo tutte le PC(i) hanno lo stesso peso (geometrico). L’effettosui valori del threshold al variare della lunghezza delle chiamate è mostrato inFigura 5.4: si precisa che, anche se sono rappresentati valori di lunghezze finoa 1800 (circa), è possibile dimostrare che tale funzione tende ad un valore finitoe maggiore di zero. Quindi, il valore misurato della probabilità (threshold) disequenza non potrà né divergere né annullarsi al crescere della lunghezza.

Proposizione 5.1.1 Il limite della probabilità (e quindi del threshold) di sequenzavale essenzialmente e−1 ovvero:

P

liml→+∞

l

√√√√ l∏i=1

PC(i) = e−1

= 1

DIMOSTRAZIONE Ipotizzando che il campione PC(1), . . . , PC(l) sia una rea-lizzazione di un processo regolato da un modello uniforme U(0, 1) è banalemostrare che (primo passo):

G(PC(1), . . . , PC(l)) = − 1β

log PC(i) ∼ E(β) β = 1

Pertanto, per la legge forte dei grandi numeri, la media campionaria

M(− log PC(1), . . . ,− log PC(l)) =l∑

i=1

− log PC(i)

del campione casuale − log PC(1), . . . ,− log PC(l) ∼ E(1) converge, per l

grande, alla media dell’esponenziale di parametro uno, ovvero converge es-senzialmente a β = 1. Infatti, per la legge forte dei grandi numeri è possibilescrivere (secondo passo):

P( limN→+∞

M(− log PC(1), . . . ,− log PC(N)) = 1) = 1

Ma, per il legame tra media aritmetica e media geometrica

l

√√√√ l∏i=1

PC(i) = e−1l

Pli=1 PC(l)

e per il primo passo si ha l’asserto.

Nel caso in cui si voglia eliminare l’ipotesi di uniformità del modello è co-munque possibile dimostrare che la media geometrica converge ad un numero

68

Parte host-based

0 100 200 300 400 500 600 700 800 900 10000

0.05

0.1

0.15

0.2

0.25

0.3

0.35

0.4

0.45

0.5

Lunghezza sequenza

Val

ore

thre

shol

d

FIGURA 5.4: Seconda versione modificata dell’algoritmo per il calcolo della threshold:variazione della probabilità minima (threshold) di sequenza al variare della lunghezzadella sequenza.

finito, basta che la variabile aleatoria − log PC(1) abbia media finita. Questo èsempre vero per l sufficientemente grande: in questo caso è infatti possibile,standardizzando opportunamente, approssimare la funzione di ripartizionedi G(·) con la funzione di ripartizione della gaussiana di media e−1. Quindi seil modello è sconosciuto, in media, G(·) tende a − log PC(1).

L’introduzione di questa modifica ha risolto il problema dei valori di pro-babilità (threshold) troppo bassi per sequenze appena più lunghe di 25 chia-mate. Tuttavia ha introdotto un nuovo problema: se prima ad una sequenzacon più di 25 chiamate veniva assegnata probabilità nulla, dopo la modifica lasituazione è inversa. Difatti, una sequenza diventa tanto più probabile quan-to più è lunga, fino a raggiungere il valore notevole di cui abbiamo discussosopra. Ovviamente entrambi i comportamenti non sono desiderabili: la lun-ghezza non dovrebbe infatti influenzare così pesantemente la probabilità adessa assegnata.

L’ideale sarebbe una misura di probabilità indipendente dalla lunghezzadella sequenza. In alternativa noi proponiamo un’ulteriore modifica al calcolodella probabilità: entrambe verranno valutate in seguito e comparate con leprecedenti. La seconda modifica apportata è formalizzata nello pseudo-codiceriportato di seguito:

1 #2 # REQUIRES: Pc - the syscall probability array3 # RETURNS: Ps - the sequence probability scalar4 #5 def seq_probability(Pc):6 Ps := Pc[0]7 for i in [0, len(Pc)]:8 Ps = sqrt(Ps * Pc[i])910 return Ps

In Figura 5.4 è riportato l’andamento, misurato empiricamente, della pro-

69


babilità (threshold) al variare della lunghezza, utilizzando la seconda versionedella normalizzazione. Come si nota il comportamento è molto simile a quel-lo in Figura 5.3, con la differenza che nella seconda versione l’annullamentodella threshold è molto meno marcato ed evidente solo per l > 100.

PROBLEMI IN FASE DI DETECTION

Sensibilità di chiamata e di sequenza L’analizzatore è tarabile in termi-ni di sensibilità. I parametri di sensibilità sono due: uno relativo alle sequenzeed uno relativo alle singole chiamate. Questi due parametri sono dei fatto-ri di scala che vengono moltiplicati per le rispettive soglie (di sequenza e dichiamata) in fase di threshold.

Si è notato che, fissando la sensibilità di chiamata ed escludendo l’anali-si “markoviana” delle sequenze (sensibilità di sequenza nulla), il numero dialert per sequenza risultava nullo, mentre il numero di chiamate anomale ri-maneva invariato. Chiaramente questo effetto evidenzia che non è possibilecaratterizzare una sequenza come anomala, se non tramite analisi del modellodi transizione.

Tuttavia crediamo che si debba poter considerare anomala anche una se-quenza che presenti almeno una chiamata anomala: per esempio è facilissimocostruire un attacco di buffer overflow modificando gli argomenti della solachiamata execve lasciando inalterate le successive (e quindi l’intera sequen-za). È molto probabile che in una situazione del genere il sistema rilevi comeanomala solo la chiamata, pertanto il criterio di classificazione di una sequen-za come anomala è stato modificato da “una sequenza è anomala se ha unaprobabilità inferiore alla threshold di sequenza” a “una sequenza è anomalase ha una probabilità inferiore alla threshold di sequenza oppure se presentadelle chiamate anomale”.

Sequenze non terminate Alle sequenze non terminate viene assegnataprobabilità zero. Questo significa che sono deterministicamente segnalate co-me anomale. Quindi se un processo non termina durante l’attività dell’IDS,il suo comportamento verrà sempre segnalato come anomalo. Questa poli-tica risulta particolarmente pessimista nonché scorretta: basti pensare che –soprattutto su un server– i processi più comuni sono demoni sempre in esecu-zione che raramente vengono terminati.

D’altra parte non è neanche semplice trovare una buona politica per trat-tare questo tipo di sequenze. Una modifica sensata sta nel decidere che unasequenza non terminata è anomala se presenta una certa percentuale di chia-mate anomale. Purtroppo questa “percentuale” è un’ulteriore parametro disensibilità che difficilmente può essere legato a quelli già presenti; le sceltesono quindi due:

I. considerare anomala una sequenza non terminata con almeno una chia-mata anomala (pessimista ma non richiede configurazione);

II. segnare come anomala una sequenza non terminata con una percentuale

70

Parte network-based

0

20

40

60

80

100

0,000 2,000 4,000 6,000 8,000 10,000 12,000

FPR (%)

DR

(%

)

Senza normaliz.

Con normaliz.

FIGURA 5.5: Curva ROC del prototipo host-based dopo la prima modifica:normalizzazione basata su media geometrica.

di chiamate anomale superiore ad un limite (ottimista ma richiede confi-gurazione).

VALUTAZIONE DELL’EFFICACIA DOPO LE MODIFICHE

Al fine di valutare l’effetto delle modifiche apportate al prototipo abbiamocondotto degli ulteriori test (con gli stessi dati) i cui risultati sono riportati inFigura 5.5 e 5.6 e analizzati di seguito.

L’efficacia dalla versione zero alla prima versione della normalizzazionesono considerevoli: a parità di DR vi è stata una riduzione dei falsi positividi oltre la metà; in quest’ultima versione infatti a DR 98% la FPR registrata èdell’1.7%, contro il 4% della versione originale.

L’accuratezza migliora ancora con l’introduzione della seconda versionedella normalizzazione: si registra infatti una FPR dell’1.3% per DR addiritturadel 99%. I miglioramenti trovano spiegazione in una aumentata precisionenel calcolo delle soglie che, nella versione originale, tendevano a penalizzarele sequenze troppo lunghe: falsi positivi che le successive versioni riescono adevitare.

5.2 PARTE NETWORK-BASED

Questa sezione descrive l’architettura, le caratteristiche distintive ed i sup-porti teorici impiegati nel prototipo di IDS network-based analizzato [?; ?].Il prototipo è stato sviluppato presso il Politecnico di Milano, nell’ambito diricerca sulla sicurezza di reti e applicazioni.

Come già accennato nella Sezione 3.6, la quasi totalità delle proposte esi-stenti ignora il contenuto (payload) dei pacchetti, basano l’analisi solo sulle fea-ture estrapolabili dallo header. Al contrario, proposte come [?] e [?; ?] ispezio-

71


0

20

40

60

80

100

0,000 2,000 4,000 6,000 8,000 10,000 12,000

FPR (%)

DR

(%

)

Senza normaliz.

Con normaliz.

Con nuova normaliz.

FIGURA 5.6: Curva ROC del prototipo host-based dopo la seconda versionedell’algoritmo di normalizzazione.

nano, seppur con tecniche differenti, (anche) il contenuto. Ignorare il contenu-to significa perdere informazione preziosa: gli attacchi più comuni non si ba-sano più sull’uso illecito di un protocollo e sono rilevabili soltanto osservandocambiamenti nel payload.

A partire da questo presupposto, l’IDS di seguito presentato implementaun’analisi sia a livello header che a livello payload del flusso di pacchetti TCP.La fine della sezione verrà dedicata alla presentazione dei risultati di alcuniesperimenti di valutazione che non erano stati inclusi nell’analisi originale.

5.2.1 ARCHITETTURA E CARATTERISTICHE

L’architettura presentata è relativa al solo analizzatore (si veda la Sezione 3.3).L’analizzatore impiega un’architettura a due stadi, denominati FIRST STAGEe SECOND STAGE in Figura 5.7.

Il primo stadio si occupa del clustering del payload dei pacchetti che, peripotesi di lavoro (confermata), darà origine ad un numero di classi (cluster)relativamente ridotto. Lo scopo è quello di condensare l’informazione del pay-load nella forma di un indice della classe a cui viene assegnato: di fatto, si stariducendo la dimensione dello spazio dei possibili ingressi al secondo sta-dio. Oltre all’indice della classe è possibile passare al secondo stadio anche un(sotto-)insieme di altre feature ricavabili/selezionabili dalla decodifica delloheader. Questa e altre “scelte” possono essere espresse in termini di parametridi configurazione che, come vedremo, è gestita da una serie di file XML.

Il secondo stadio analizza lo stream di informazioni provenienti dal primostadio, trattandole alla stregua di una serie temporale. Lo scopo è quello dirilevare deviazioni nella serie temporale (outlier), ovvero rilevare anomalie. Sinoti che un’anomalia può essere costituita sia da una serie di pacchetti che da unpacchetto: in entrambi i casi il risultato è una deviazione dalla normalità. Nelcaso si tratti di una sequenza anomala, il sistema avverte solo quando arriva

72

Parte network-based

LAYER 3header

IP

LAYER 4header

TCP/UDP/...

PAYLOAD(upper layer protocol data)

Ethernet: 0–1460 bytes

Decoded Header Data

(IP, ports, flags)

Payload Classification

(from first stage)

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

LAYER 3header

IP

LAYER 4header

TCP/UDP/...



Decoded Header Data

(IP, ports, flags)


(from first stage)

LAYER 3header

IP

LAYER 4header

TCP/UDP/...



Decoded Header Data

(IP, ports, flags)


(from first stage)

FIRS

T ST

AGE

Unsu

perv

ised

lear

ning

cla

ssifie

r

Deco

ded

Head

er D

ata

(IP, p

orts

, flag

s)

Payl

oad

Clas

sific

atio

n(fr

om fi

rst s

tage

)

Deco

ded

Head

er D

ata

(IP, p

orts

, flag

s)

Payl

oad

Clas

sific

atio

n(fr

om fi

rst s

tage

)

Deco

ded

Head

er D

ata

(IP, p

orts

, flag

s)

Payl

oad

Clas

sific

atio

n(fr

om fi

rst s

tage

)

Deco

ded

Head

er D

ata

(IP, p

orts

, flag

s)

Payl

oad

Clas

sific

atio

n(fr

om fi

rst s

tage

)

Deco

ded

Head

er D

ata

(IP, p

orts

, flag

s)

Payl

oad

Clas

sific

atio

n(fr

om fi

rst s

tage

)

Deco

ded

Head

er D

ata

(IP, p

orts

, flag

s)

Payl

oad

Clas

sific

atio

n(fr

om fi

rst s

tage

)

SECOND STAGETime correlation and outlier detection

Time

Time

FIGURA 5.7: Schema dell’architettura a due stadi dell’analizzatore del prototiponetwork-based.

il pacchetto che rende tale sequenza anomala: si tratta comunque di un dettaglioimplementativo.

5.2.2 SUPPORTI TEORICI

Non è scopo di questa sezione analizzare le motivazioni e i risultati originaliriguardanti il prototipo, pertanto ci si limita a riportare in modo oggettivo iconcetti necessari per comprendere il funzionamento e gli algoritmi utilizzati.

PRIMO STADIO: CLUSTERING DEL PAYLOAD

Come anticipato, questo stadio si basa su un algoritmo di clustering [?; ?] perraggruppare i payload dei pacchetti in gruppi con caratteristiche simili. A que-sto livello gli elementi in ingresso all’algoritmo sono dei vettori le cui celle so-no i byte del payload decodificati. La dimensione massima di tali vettori èpertanto 1460.

Il problema del clustering è risolvibile con diversi algoritmi, più o me-no sensibili alle caratteristiche intrinseche dei dati da raggruppare. In [?] siconfrontano le capacità di corretta classificazione e le performance di vari al-goritmi di clustering: gli esperimenti riguardano il clustering del traffico di

73


rete. È stato notata la sorprendente accuratezza delle SOM nel classificarecorrettamente il payload del traffico.

Pertanto, questo stadio impiega (l’addestramento di) una SOM per crea-re le classi di payload. Il risultato della fase di addestramento è l’insieme deicluster, ognuno dei quali è rappresentato da un neurone (o nodo della rete).In altre parole quando in fase operativa bisogna controllare a che classe (clu-ster) appartiene un nuovo vettore basta calcolare la BMU: il neurone vincito-re identifica infatti (con i propri pesi) il gruppo di vettori più simili a quellonuovo.

Per aumentare la velocità di addestramento si impiega un’euristica perla riduzione del numero di neuroni da controllare nella fase di ricerca dellaBMU [?]. In poche parole, l’euristica si basa sul raggruppamento dei neuroni,effettuato con un algoritmo di clustering di tipo K-means. Invece di esplora-re esaustivamente ogni neurone, si cerca prima il super-neurone (cluster cheraggruppa più neuroni) relativo all’input di cui si vuole calcolare la BMU.La ricerca è dunque effettuata nei soli neuroni appartenenti al super-neurone.Dal momento che cambiano ad ogni epoca della fase di addestramento, an-ziché aggiornare i cluster K-means ad ogni epoca, è prevista una frequenzafissata di aggiornamento per effettuare quest’operazione.

SECONDO STADIO: OUTLIER DETECTION

Molto più interessanti risultano le tecniche implementate il motore di rile-vazione di anomalie. Come anticipato, il secondo stadio analizza il flusso dipacchetti nel tempo. Più precisamente, a partire dalla sequenza dei pacchettinuovi nel tempo e dalla classificazione del secondo stadio, il secondo stadio èin grado di valutare in che misura:

• un pacchetto è anomalo rispetto alla classe cui il suo contenuto appartie-ne (confrontando, ad esempio, la porta di destinazione specificata nelloheader con quella associata alla classe cui il pacchetto appartiene);

• un pacchetto è anomalo perché introduce una deviazione significati-va nella distribuzione dei pacchetti nel tempo (limitatamente ad unafinestra temporale).

L’algoritmo di base utilizzato è SmartSifter ed è descritto in [?; ?]. È unalgoritmo per la ricerca di outlier in serie temporali multi-variate, le cui carat-teristiche distintive sono:

I. non supervisionato: non richiede dunque che per la fase di addestramentosi usino campioni etichettati;

II. on-line: ogni volta che arriva un nuovo dato, valuta quanto si discostadalla normalità;

III. adattativo a sorgenti non stazionarie: impiega un fattore di oblio per adattareil modello dei dati a sorgenti dinamiche;

74

Parte network-based

IV. significato statistico chiaro: il punteggio che viene dato ai dati per quan-tificarne l’anomalia è espresso in termini di distanza statistica. Dunquequantifica la modifica subita dalla distribuzione statistica con l’arrivo del-l’ultimo campione;

V. computazionalmente poco complesso: la complessità del calcolo del punteg-gio è lineare nel numero dei parametri e cubica nel numero delle variabili;

VI. utile sia per variabili continue che categoriche: l’algoritmo può trattare siavariabili categoriche che variabili continue. Con il termine continue si in-cludono anche le variabili intere per le quali sia sensato il calcolo di gran-dezze statistiche come la media e la deviazione standard (dunque ancheil campo Payload Length del TCP è da considerarsi continuo).

Questo stadio implementa una versione (modificata dagli sviluppatori) diSmartSifter il quale, in pratica, altro non è che un algoritmo per la stima [?]online della densità di probabilità di una serie temporale di variabili aleatoriecon domini categorici (ovvero, le feature). Il punteggio che SmartSifter attri-buisce ad ogni pacchetto è la misura di quanto l’arrivo di tale pacchetto hamodificato la densità di probabilità stimata fino al pacchetto precedente. Perevitare gli effetti “del passato” l’implementazione dell’algoritmo permette dispecificare un fattore di oblio (forgetting factor) per sfavorire il contributo divecchi pacchetti alla stima corrente.

In questo stadio interviene la sensibilità la quale è legata a SmartSifterattraverso un’altra densità di probabilità. Stimata la distribuzione dei pun-teggi dei pacchetti, la sensitività è definita come la percentuale di pacchettiche si desidera considerare come anomalie (outlier), ovvero il quantile di taledistribuzione.

Come anticipato, il secondo stadio non considera soltanto le classi di pay-load: le feature selezionate (ovvero il set di domini delle variabili categoriche)sono:

1. porta sorgente/destinazione,

2. indirizzo sorgente/destinazione,

3. flag TCP e

4. la classe di payload.

Questo rappresenta un insieme molto più piccolo di tutte le possibili ca-ratteristiche che si potrebbero osservare che sono circa una decina.

5.2.3 TIPO DI IMPLEMENTAZIONE E FUNZIONAMENTO

Il prototipo è scritto completamente in linguaggio C: le implementazioni di re-te SOM, algoritmi di clustering e SmartSifter sono stati scritti ex-novo per mo-tivi di prestazioni. Non si scenderà in alcun modo in altri dettagli implementa-tivi, già perfettamente documentati in [?] nella forma di component/sequencediagram Unified Modeling Language (UML).

75


INTERFACCE

Le interfacce offerte sono tre: due costituite dagli eseguibili som_training ess_training per l’addestramento del primo e del secondo stadio, rispettiva-mente; l’altra interfaccia è in forma di preprocessore per Snort, implementatain una patch. Il preprocessore di Snort, chiamato ul, implementa il funzio-namento della fase operativa del secondo stadio. L’interfaccia per la confi-gurazione è implementata in un interprete di file XML (di configurazione),pertanto ricade nel paragrafo seguente dedicato ai formati.

Gli eseguibili per il training permettono di specificare, oltre al percorsodei file di configurazione e di input, alcune opzioni per l’addestramento; esseriguardano la dimensione dei buffer di lettura, il numero di pacchetti che siintende utilizzare per l’addestramento, il modo in cui la sequenza di pacchettiviene caricata in memoria e la possibilità di scrivere dei log. Alcuni di questiparametri sono molto importanti, soprattutto per l’impatto che hanno sulleperformance medie delle fasi di training.

FORMATI DI I/O

L’output in fase operativa è completamente a carico dei moduli di Snort per lagestione degli alert e la generazione dei log, pertanto non verrà approfonditoin questa sede dal momento che tali formati di alert sono ben documentati [?].

L’input è costituito dal formato Pcap: anche in questo caso i formati sonogià perfettamente specificati. La parte interessante riguarda la configurazionee la serializzazione del training (batch), completamente affidata ad opportunifile XML. In particolare, i file coinvolti nella configurazione sono:

• SOM_BASE_ia.xml per la configurazione del modulo che gestisce le strut-ture dati (vettori) in ingresso alle SOM.

• SOM_BASE_conf.xml per la configurazione della topologia e del tipo ditraining delle SOM.

• SS_BASE_ia.xml per la configurazione del modulo che gestisce le strut-ture dati (vettori) in ingresso a SmartSifter.

• SS_BASE_ss.xml per la scelta delle feature e la “connessione” tra il pri-mo ed il secondo stadio (classi di payload).

mentre quelli per la serializzazione del training sono:

• SS_BASE_iainfo.xml memorizza lo stato delle strutture dati utilizzatedurante l’addestramento delle SOM.

• SOM_BASE_neur.xml memorizza (i pesi del)le reti neurali delle SOM.

• SS_BASE_iainfo.xml memorizza lo stato delle strutture dati utilizzateda SmartSifter durante l’addestramento.

• SS_BASE_ssmest.xml memorizza il blando addestramento (distribuzio-ne dei punteggi) di SmartSifter.

76

Parte network-based

L’addestramento del primo stadio avviene in maniera batch ed i pacchettisono selezionati dallo stream in modo casuale. Inoltre, per entrambi gli sta-di, è possibile interrompere l’addestramento e riprenderlo in qualsiasi altromomento.

L’implementazione permette di creare e addestrare delle SOM di tipo di-verso. Tuttavia quelle effettivamente utilizzate nel primo stadio sono di ti-po esagonale, con distanza euclidea, discesa learning-rate e inizializzazione en-trambe lineari, training sequenziale e adattamento dei pesi di tipo gaussiano.

5.2.4 PROBLEMI RISCONTRATI ED ESTENSIONE DEI TEST ORIGINALI

A parte la moltitudine di file coinvolti tra training/testing e configurazione,c’è da far notare che il formato XML non è il massimo per compattezza edimensioni di file risultanti. A parte questo, il maggiore problema riguardacertamente il tempo necessario al training del primo stadio. È stato misuratosperimentalmente che per un numero di pacchetti dell’ordine del milione iltempo necessario sia aggira attorno ai 350–400 minuti (ordinamento) e 1300–1350 minuti (sintonizzazione), per un totale di 1650–1750 minuti (più di ungiorno intero).

Non essendo possibile effettuare il training in maniera concorrente non ènemmeno pensabile di sfruttare le capacità di calcolo di elaboratori paralleli.Inoltre, se non si tara opportunamente il parametro “lunghezza del buffer diinput” è facilissimo o aumentare a dismisura il tempo già lungo di training, osaturare velocemente la memoria centrale rendendo impossibile il training.

Per questi motivi non è stato facile condurre un gran numero di test diefficacia con questo strumento, soprattutto al variare del tipo di training e/odi configurazione delle reti neurali. Invece, ci si è dovuti accontentare di ef-fettuare pochi training ma su numerosi pacchetti, in modo da disporre diclassificatori robusti e con buona capacità di generalizzazione.

Il resto della sezione è dedicato alla prova sperimentale degli strumenti.In particolare si focalizza sulla necessità di effettuare ulteriori test rispetto aquelli già riportati dagli sviluppatori. Differentemente dal caso host-based, ilprototipo network-based è stato valutato con attenzione per quanto riguarda:

• capacità di classificazione del primo stadio;

• convergenza;

• throughtput;

• efficacia (analisi ROC).

Tuttavia, riteniamo opportuno verificare il funzionamento dello strumentoda almeno altri due punti di vista, ovvero:

• influenza del periodo di addestramento sull’efficacia (qualitativo);

• capacità di generalizzazione: in particolare, rilevazione di tentativi dievasione come la frammentazione (quantitativo).

77


0

10

20

30

40

50

60

70

80

90

100

0,000 0,100 0,200 0,300 0,400 0,500 0,600 0,700 0,800 0,900 1,000

1000000 pacchetti

100000 pacchetti

250000 pacchetti

500000 pacchetti

FPR (%)

DR

(%)

FIGURA 5.8: Variazione della durata dell’addestramento: curve ROC per i quattroesperimenti.

I test sono stati effettuati nelle medesime condizioni di quelli originali, ri-portati in [?], ovvero con un calcolatore AMD Athlon XP 3000+ 2166 MHz e1GB di memoria centrale. Anche la configurazione del primo e del secondostadio è rimasta la stessa: i nodi della SOM 10 × 10 hanno vettori dei pesi didimensione |∆| = 1460. Se non diversamente specificato, i risultati riportatinelle sezioni successive, si riferiscono ad un addestramento sul file Pcap del lu-nedì della prima settimana (IDEVAL 1999); gli ingressi “nuovi” provengonoinvece dal file Pcap del martedì della quarta settimana con l’aggiunta di trenuove istanze di attacco (così com’era stato fatto in [?]).

VARIAZIONE DELLA DURATA DELL’ADDESTRAMENTO

Questo primo test valuta come cambiano, qualitativamente, le capacità di rile-vazione delle anomalie variando l’entità dell’addestramento. Il file di trainingè sempre lo stesso ma il numero di pacchetti effettivamente utilizzato cambiaogni volta. Il numero di pacchetti utilizzato durante la fase di verifica è inveceil medesimo.

Sono stati effettuati quattro esperimenti in totale quattro, E1, E2, E3, E4con 105, 2.5× 105, 5× 105, 106 pacchetti, rispettivamente. I risultati sono mes-si a confronto in Figura 5.8: le interpretazioni dei risultati sono riportate diseguito.

E1 Sebbene la fase di addestramento abbia coinvolto solo 100000 pacchet-ti, questo esperimento ha rivelato –in fase operativa– un’efficacia superiore atutti gli altri, fino a DR ≤ 75 − 77%. Riteniamo che questo possa essere spie-

78

Parte network-based

gato con una migliore capacità di generalizzazione delle classi di payload in-dividuate. Tuttavia, per valori di DR ≥ 78% le performance peggiorano dra-sticamente. Addirittura, la DR non supera stranamente il 92%; esaminandonel dettaglio si è notato che l’IDS non ha rilevato uno degli attacchi: moltoprobabilmente non sono state etichettate le classi necessarie ad individuarel’anomalia.

E2 Sorprendentemente un training con 250000 pacchetti ha dato prestazionipeggiori in fase operativa, rispetto ad E1. La curva è infatti sempre al di sottodi quella dell’esperimento precedente. Tuttavia la DR rilevata arriva fino al100%.

E3 Con un addestramento di questa durata le prestazioni in fase operati-va sono globalmente migliori di tutti gli altri casi. Escludendo infatti la fascia65-80%, per arrivare ad FPR paragonabili a quelle degli altri esperimenti ènecessario che DR superi il 90%. Questo comportamento rivela che l’adde-stramento ha conferito buone capacità di generalizzazione rispetto ai casi pre-cedenti: il training è stato tuttavia sufficientemente breve da non permettereallo strumento di incorrere in evidenti problemi di overfitting (E4).

E4 Per DR molto alte il comportamento assomiglia molto a quello rilevato inE3. Tuttavia riteniamo che il peggioramento delle prestazioni (più falsi positi-vi) tra l’80-90% sia dovuto a problemi di overfitting che, nel caso di un datasetcon problemi di regolarità (si veda, Capitolo 4), è molto facile a presentarsi.

FRAMMENTAZIONE E CAPACITÀ DI GENERALIZZAZIONE

Le prove che sono state effettuate riguardano il comportamento dell’IDS an-che nel caso di presenza di pacchetti IP frammentati. Il protocollo IP stessosuddivide un pacchetto più grande dell’Maximum Transfer Unit (MTU) in piùframmenti IP appartenenti allo stesso pacchetto. È possibile sfruttare questomecanismo per “nascondere” un attacco frammentandone i pachetti a livello2. Difatti, se il sensore è posto in un segmento di rete che riceve (frammenti di)pacchetti non riassemblati, l’analizzatore non potrà rilevare l’attacco perchénessuno dei pacchetti (preso singolarmente) viene considerato anomalo. Seinvece l’IDS è posizionato a valle di un “riassemblatore” allora l’attacco eva-so può essere riconosciuto, semplicemente perché si rimette l’IDS nelle nor-mali condizioni operative. Questo problema è oggi facilmente risolto, negliIDS misuse-based come Snort, da appositi preprocessori che ricostruiscono ipacchetti prima passarli al motore inferenziale.

Come accennato in 4.2, i pacchetti IP frammentati sono oggi molto rari manon inesistenti. Per modificare il traffico di addestramento e di testing intro-ducendo frammentazione è stato impiegato dapprima Fragroute [?]; si trattadi un semplice software impiegato in [?] per verificare l’efficacia delle tattichedi evasione basate su questo meccanismo. Tuttavia il traffico risultante risul-tava poco realistico: erano evidenti gli interventi regolari della frammentazio-ne. Per ovviare a questo inconveniente è stato impiegato uno script Python

79


dal funzionamento analogo ma con la possibilità di frammentare a intervallitotalmente casuali e in frammenti di dimensione totalmente casuale.

TRAINING

Frammentaz. %Framm. #Pac. utiliz. #Pac. totali %AttacchiF 11.72 100000 1310898 0NF - 100000 1157328 0

TESTING

Frammentaz. %Framm. #Pac. utiliz. #Pac. totali %AttacchiF 9.71 1350285 1350285 0.0158NF - 1219154 1219154 0.0158

TABELLA 5.3: Caratteristiche del traffico (frammentato) utilizzato per il training e peril testing dell’IDS network-based.

Le caratteristiche dei dataset impiegati sono riassunti in Tabella 5.3. Gliesperimenti condotti ci hanno permesso di stabilire le possibilità di trattarequesto problema nel caso di IDS anomaly-based. È comunque vero che baste-rebbe porre la sonda a valle di un de-frammentatore IP; resta comunque inte-ressante vedere come si comporta l’IDS addestrato con diversi tipi di traffico(frammentato e non) se stimolato con esempi diversi (frammentati e non).

Sono stati effettuati quattro esperimenti denotati con NF/NF, NF/F, F/NF,F/F. La notazione ha il significato traffico <training/traffico testing> quindi, adesempio, NF/F indica un training su traffico non frammentato e testing contraffico frammentato. Le quattro curve sono riportate in Figura 5.9. In favoredi un maggior numero di prove è stato diminuito il numero di pacchetti ditraining.

Tuttavia, per mostrare che i risultati (abbassando il numero di dati di trai-ning) non sono qualitativamente diversi, in Figura 5.10 è mostrata la curvaROC ottenuta per un solo esperimento di tipo NF/NF con un numero di pac-chetti di training di un ordine di grandezza superiore rispetto agli altri quattrooriginali. Come ulteriore conferma dell’andamento dell’efficacia di rilevazio-ne ci sono comunque i risultati riportati nella sezione precedente. Segue unabreve analisi dei risultati degli esperimenti.

Training e testing su traffico normale (NF/NF) Questo esperimento nonpresenta grosse sorprese ed è stato condotto sia per avere un metro di rife-rimento con gli altri tre, sia per confermare che, diminuendo il numero dipacchetti in fase di training, la qualità di classificazione non cambia drastica-mente: la curva è difatti simile a quella in Figura 5.10.

Training su traffico normale e testing su traffico frammentato (NF/F)I peggiori risultati si sono ottenuti, com’era facile aspettarsi, in questo caso.Il sistema non era addestrato sui payload tipici dei pacchetti frammentati iquali vengono, in fase di detection, classificati come anomali per effetto delladistanza rispetto alla feature “payload class”. Già con una DR del 65% la FPRè dello 0.02%.

80

Parte network-based

0

10

20

30

40

50

60

70

80

90

100

0,000 0,100 0,200 0,300 0,400 0,500 0,600 0,700 0,800 0,900 1,000

Non frammentato/Non frammentato

Non framm./Framm.

Framm./Framm.

Framm./Non framm.

FPR (%)

DR

(%)

FIGURA 5.9: Comportamento in caso di traffico frammentato: curve ROC per i quattroesperimenti.

Training e testing su traffico frammentato (F/F) Sensibilmente miglioredi quello precedente per DR fino al 70%, nettamente migliore per DR superio-ri. Probabilmente l’alto numero di falsi positivi anche a bassi valori di DRdipende dalla presenza di pacchetti non anomali non frammentati nei dati ditesting, che vengono individuati come anomali solo perché i relativi payloadsono stati “visti” in forma frammentata durante il training.

Training su traffico frammentato e testing su traffico normale (F/NF)È sorprendente la qualità della rilevazione in questo tipo di esperimento. Seb-bene presenti qualche piccola irregolarità per DR dell’75–80%, è necessarioarrivare a DR del 92% per avere FPR comparabili con quelle dei preceden-ti esperimenti. Non solo, questa curva è nettamente migliore anche di quelladi Figura 5.10, riferita ad un training 10 volte più massiccio. Molto probabil-mente, un traffico (non totalmente) frammentato aumenta le capacità di gene-ralizzazzione del classificatore. Da questo punto di vista, l’introduzione del-la frammentazione, totalmente assente nel traffico di training originale, con-tribuisce a diminuire gli effetti delle troppe regolarità riportate nel Capitolo4.

81


0

10

20

30

40

50

60

70

80

90

100

0,000 0,100 0,200 0,300 0,400 0,500 0,600 0,700 0,800 0,900 1,000FPR (%)

DR

(%)

FIGURA 5.10: Curva ROC per un esperimento NF/NF con un training che ha coinvoltoun numero di pacchetti dell’ordine di 106.

82

— CAPITOLO 6 —

VERSO UN SISTEMA DI ALERT

CORRELATION

Il capitolo precedente ha riportato dettagli e risultati sperimentali riguardantii due prototipi per anomaly detection. Gli alert riportati da questi strumentipossono essere ulteriormente processati al fine di produrre report più compat-ti e non ridondanti. Scopo di questo capitolo è definire il problema dell’analisie correlazione di allarmi nel caso specifico di sistemi di anomaly detection.Il problema è stato ampiamente discusso in letteratura: manca tuttavia di so-luzioni realizzabili in pratica. Scopo principale di questo capitolo è l’analisidei problemi da risolvere in questo ambito fatta attraverso la discussione delprototipo sviluppato per verificare l’efficacia di diversi approcci. Il resto delcapitolo è dedicato alla proposta di possibili soluzioni ai problemi presentati.

6.1 DEFINIZIONE DEL PROBLEMA

Ricordiamo che abbiamo analizzato la possibilità di realizzare un sistema col-laborativo per la correlazione di allarmi provenienti da due o più IDS. Nelcaso specifico ci siamo occupati di valutare le possibilità di realizzare un siste-ma di correlazione per i due prototipi host e network descritti nel Capitolo 5. Ilmotivo che ci ha portato a scegliere questi strumenti non è solo la disponibilitàdel software stesso, ma la profonda cononscenza sviluppata e l’abbondanza didati relativi ai test già condotti. Sottolineiamo che, se non diversamente spe-cificato, il termine correlazione è utilizzato in senso lato e non (soltanto) con ilsignificato statistico. Difatti degli allarmi possono essere “correlati” nel sensoche riguardano lo stesso attacco, oppure che afferiscono a due attacchi conse-quenziali, oppure ancora che nascondono lo stesso obiettivo da parte dell’ag-gressore. Non è detto che questi casi implichino correlazione anche in sensostatistico.

Come sottolineato nella Sezione 3.6.2 esistono diverse proposte che per-mettono di correlare allarmi, tuttavia quasi tutti si basano su ipotesi che nonsono affatto garantite nel caso di IDS anomaly-based. La maggior parte degliapprocci si appoggia infatti su una qualche forma di conoscenza pregressa: peresempio, la priorità o la gravità di un tipo di attacco, oppure sul semplice fattodi sapere di che attacco si tratta. Invece, nel nostro caso, questa apparentemen-te semplice non può essere fatta. Come verrà descritto in dettaglio, gli alertprovenienti da sistemi anomaly-based hanno delle peculiarità e dei limiti dacui è difficile, se non impossibile, prescindere.

Analizzando il problema a livello algoritmico, si tratta di studiare o adatta-re criteri per verificare, a partire da due alert, se questi siano in qualche modolegati. A seconda dello scopo dell’analisi e del tipo di risultato che si vuoleottenere il legame alla base di tali algoritmi sarà diverso. Riprendendo l’e-

83

6. VERSO UN SISTEMA DI ALERT CORRELATION

sempio precedente, se si vuole raggruppare/correlare alert riferiti allo stessoattacco può essere utile un criterio per calcolare la “similarità” dei due alert.Ancora, se lo scopo è dire se un’attacco è causa di un altro allora servirà unmodo per valutare il grado di “causalità”. La difficoltà di esprimere questotipo di misure è indubbia quando il contesto è a priori indefinito e quandomancano ipotesi sul dominio applicativo. Approcci sufficientemente generici,sensati ed effettivamente funzionanti sono piuttosto scarsi in letteratura: sen-za la presunzione di proporre una soluzione migliore, riteniamo sia invece piùimportante valutare la bontà, l’applicabilità e le capacità di correlazione dellesoluzioni esistenti.

6.1.1 VALUTAZIONE DI SISTEMI DI CORRELAZIONE

Se un IDS è difficile da valutare in pratica (si veda la Sezione 3.5), per un si-stema di correlazione è difficile anche soltanto stabilire cosa si vuole valutare.Infatti, se per un IDS l’efficacia è traducibile in “capacità di rilevare corretta-mente/accuratamente gli attacchi”, per un sistema di correlazione non è faciledefinire una misura di performance.

La disciplina e l’originalità del problema si riscontrano soprattutto da que-sto punto di vista: in letteratura le proposte in fatto di tecniche di valutazionedi sistemi di correlazione sono ancora molto limitate [?] e, comunque, confi-nate a correlazione per un solo specifico obiettivo. Dal nostro punto di vista,la necessità di stabilire delle metriche di efficacia è molto importante specifi-chiamo da subito le modalità con cui gli algoritmi da noi considerati verrannovalutati.

Lo scopo di più alto livello di un sistema di correlazione è produrre reportcompatti, eliminando informazioni ridondanti circa gli attacchi. Pertanto unsistema è tanto più efficace quanto è in grado di ridurre il numero di informa-zioni presentate all’analista, senza ovviamente perdere di completezza. Difat-ti è necessario che la riduzione non comprometta la qualità della rilevazione.Quindi, a parità di grado di riduzione del numero di allarmi, un algoritmoè migliore di un altro se riduce di poco le capacità di rilevazione dei sistemioriginali. Idealmente, le prestazioni dovrebbero restare inalterate: in pratica èfacile intuire –ed abbiamo anche verificato– che l’abbassamento delle capaci-tà di rilevazione è inevitabile, specialmente nel caso di sistemi “ciechi” comequelli anomaly-based. Si vorrebbe quindi che, in termini di alert, venisseroeliminati/non-riportati soltanto (o principalmente) i falsi positivi.

Da questa breve analisi si conclude che è sensato occuparsi di valutarecongiuntamente:

I. quanto la DR venga ridotta: meno questa risulta alterata, più il sistema èbuono;

II. quanto la FPR venga ridotta: più questa viene abbassata, più il sistema èbuono;

III. quanto il sistema abbia ridotto il numero di allarmi totali inizialmenteriportati dagli IDS.

84

Problematiche di semantica e di formato

Si noti che, visto che gli allarmi totali provengono potenzialmente da tuttigli IDS è necessario tenere conto di DR e FPR di tutti questi sistemi. In real-tà è possibile considerare gli allarmi come provenienti da un solo unico IDS“globale” di cui è facile misurare DR e FPR.

6.1.2 PROBLEMI SPECIFICI DEI SISTEMI ANOMALY-BASED

Come anticipato nella Sezione 3.4, uno dei problemi tipici dell’anomaly de-tection è la mancanza di informazioni sull’attacco rilevato. Quando viene ri-scontrata un’anomalia, non si può far altro che riportare l’istante di tempo,il tipo di servizio/programma, l’host bersaglio/aggressore ma non si può co-noscere il tipo di attacco, semplicemente perché non è previsto, come nel casomisuse-based, un database di firme e (nel caso ci fosse) non è detto che l’at-tacco sia conosciuto (0-day attack). È necessario quindi tenere conto di questalimitazione durante il progetto dei criteri alla base dell’analisi di correlazionetra allarmi. Nella peggiore delle ipotesi, la mancanza di questo tipo di infor-mazioni si traduce nella richiesta di una configurazione molto accurata dellostrumento.

6.2 PROBLEMATICHE DI SEMANTICA E DI FORMATO

A prescindere dal problema da risolvere, se più sistemi (diversi) debbono col-laborare il primo requisito è un formato ed un protocollo per lo scambio dimessaggi. Nel nostro caso i messaggi gli eventi (allarmi) riportati da ogniIDS e il protocollo è il meccanismo secondo cui tali eventi vengono propagati(soprattutto da e verso quali sistemi e in che ordine).

6.2.1 FORMATO DEGLI ALLARMI

In un framework di correlazione generico come quello tratteggiato in [?] ilproblema del formato è risolto dal processo di normalizzazione. In letteraturasono stati suggeriti e proposti diversi formati per lo scambio di eventi tra IDS:le due più notevoli sono quella degli ICSA Labs (1998) chiamata Security De-vice Event Exchange (SDEE) e quella dell’Intrusion Detection Working Group (ID-WG)/Internet Engineering Task Force (IETF) (2001), chiamata IDMEF. Sebbenela prima sia stata adottata da Cisco, Sourcefire e Symantec, oggi non esistepiù traccia delle specifiche originali. Anche se non del tutto compatibile [?]con IDMEF, lo stesso IETF ha da poco rilasciato una bozza delle specifiche ag-giornate di Incident Object Description and Interchange Format (IODEF) [?]. Nelseguito, ci si baserà sulla proposta IDMEF perché considerata non obsoleta edabbastanza stabile.

Chiaramente, nessuna delle proposte “impone” ai produttori il loro utiliz-zo; difatti la maggior parte dei prodotti (soprattutto commerciali) continua-no a basarsi sul proprio formato. Talvolta, ed è il caso di Snort per esem-pio, vengono rese disponibili applicazioni di normalizzazioni scritte ad-hocper esportare in IDMEF. Questa operazione è comunque molto semplice daeffettuare.

85


IL FORMATO IDMEF

Senza la pretesa di dare una spiegazione esaustiva, IDMEF [?] è basato suXML e fornisce un linguaggio per la specifica di messaggi/eventi di alert.Come esemplificato dal frammento riportato nel Listato 6.1, ogni messaggiocontiene, come minimo, informazioni sull’host che ha riportato l’attacco, sul-l’istante di tempo in cui questo attacco è stato creato/rilevato/riportato (secondoil formato NTP-timestamp definito per [?]), sul bersaglio e sul tipo di attacco(se disponibile).

Nonostante si tratti solo di un modello dei dati orientato agli oggetti perrappresentare allarmi, uno dei principali obiettivi di IDMEF è quello di cerca-re di rappresentare relazioni tra alert a scopo di correlazione/aggregazione.A seconda delle capacità dell’analizzatore esistono diversi gradi di comples-sità con cui possono essere modellati gli eventi. La classe di più alto livel-lo è IDMEF-Message ed è specializzata in Alert e HeartBeath. La secondadefinisce il formato per messaggi di “stato” dei dispositivi.

La classe Alert Rappresenta un allarme o un gruppo di allarmi. Come mo-strato in Figura 6.1, ogni alert contiene informazioni circa l’analizzatore (i.e.,IDS) che l’ha riportato, il timestamp in cui è stato rilevato (riferito all’attacco),creato, analizzato, sorgenti e destinatari.

Sono previsti altri attributi (opzionali o meno) tra cui il più importante èClassification: ovvero il nome che si è deciso di attribuire all’alert; se nondisponibile, dovrebbe essere rimpiazzato con informazioni utili al riconosci-mento, almeno, del tipo di alert (si vedano le considerazioni sulla semanticanella sezione successiva).

A sua volta, la classe può essere specializzata in ToolAlert, Overflow-Alert e CorrelationAlert. Secondo le specifiche, ToolAlert ha a che farecon i programmi “maliziosi” che avrebbero causato l’alert. Dal nostro puntodi vista, questa classe può tranquillamente essere impiegata per raggrupparealert provenienti da un IDS host-based. Infatti, tra gli attributi c’è command. Laclasse AlertOverflow è molto simile, ma è focalizzata sugli attacchi di bufferoverflow. Invece, per aggregare/correlare alert simili si dovrebbe elencarnegli identificatori in un oggetto di tipo CorrelationAlert.

Source, Target Differiscono solo per l’attributo file, mancante in Sour-ce. Entrambe hanno a che fare con la modellizzazione dei nodi coinvolti nel-l’alert, identificati dal campo Node (indirizzo o nome di rete). Gli altri cam-pi, sempre opzionali, riguardano processo/utente e servizio causa e oggettodell’alert, rispettivamente.

Molto importante risulta, a nostro avviso, il campo Confidence della clas-se Assessment: da usarsi per memorizzare il grado di confidenza che l’a-nalizzatore attribuisce all’alert. Nel caso l’analizzatore impieghi criteri basa-ti su soglie statistiche questo attributo potrebbe memorizzare questo tipo diinformazioni.

86


IDM

EF E

vent

Hear

tbea

tAn

alyz

er

Crea

teTi

me

Dete

ctTi

me

Anal

yzer

Tim

e

Clas

sific

atio

n

Asse

ssm

ent

Addi

tiona

lDat

a

Aler

t

Sour

ceUs

er

Node

Proc

ess

Serv

ice

Targ

et

User

Node

Proc

ess

Serv

ice

File

Aler

t

Corr

elat

ionA

lert

Nam

e

Aler

tIden

tSt

ring

Ana

lyze

rId

1..*

Aler

t

Tool

Aler

tNa

me

Com

man

d0.

.1

Aler

tIden

tSt

ring

Ana

lyze

rId

1..*

Asse

ssm

ent

Impa

ct0.

.1

Actio

n0.

.*

Confi

denc

e0.

.1

FIGURA 6.1: Gerarchia di classi del modello dei dati IDMEF.

87


1 <idmef:IDMEF-Message2 xmlns:idmef="http://iana.org/idmef"3 version="1.0"4 >5 <idmef:Alert messageid="abc123456789">6 <idmef:Analyzer analyzerid="Hq-dmz-analyzer01">7 <Idmef:Node category="dns">8 <idmef:location>Headquarters DMZ Network</idmef:location>9 <idmef:name>analyzer01.example.com</idmef:name>10 </idmef:Node>11 </idmef:Analyzer>12 <idmef:CreateTime ntpstamp="0xbc723b45.0xef449129">13 2000-03-09T10:01:25.93464-05:0014 </idmef:CreateTime>15 <idmef:Source ident="a1b2c3d4">16 <idmef:Node ident="a1b2c3d4-001" category="dns">17 <idmef:name>badguy.example.net</idmef:name>18 <idmef:Address ident="a1b2c3d4-002"19 category="ipv4-net-mask">20 <idmef:address>192.0.2.50</idmef:address>21 <idmef:netmask>255.255.255.255</idmef:netmask>22 </idmef:Address>23 </idmef:Node>24 </idmef:Source>25 <idmef:Target ident="d1c2b3a4">26 <idmef:Node ident="d1c2b3a4-001" category="dns">27 <idmef:Address category="ipv4-addr-hex">28 <idmef:address>0xde796f70</idmef:address>29 </idmef:Address>30 </idmef:Node>31 </idmef:Target>32 <idmef:Classification text="Teardrop detected">33 <idmef:Reference origin="bugtraqid">34 <idmef:name>124</idmef:name>35 <idmef:url>http://www.securityfocus.com/bid/124</idmef:url>36 </idmef:Reference>37 </idmef:Classification>38 </idmef:Alert>39 </idmef:IDMEF-Message>

LISTATO 6.1: Esempio di messaggio IDMEF

Implementazione Il modello dei dati IDMEF è attualmente “implementa-to” in un Document Type Definition (DTD). Al contrario, il modello di IODEF èspecificato in uno schema XML Schema Definition (XSD) [?]. Un frammento dicodice è mostrato nel Listato 6.1.

SEMANTICA

Molto legato al formato vi è il problema, molto più importante, della seman-tica. Dal nostro punto di vista, i problemi principali sono due: uno legato allanecessità di dare un significato condiviso e univoco agli attacchi (almeno al-l’interno dello stesso sistema informatico); l’altro aspetto critico riguarda lagranularità degli alert.

Quest’ultimo problema ha a che fare con le caratteristiche e l’implementa-zione degli analizzatori: non è detto infatti che due sistemi diversi, (per esem-pio entrambi host-based) che osservano la stessa attività, riporteranno gli stes-si alert per gli stessi attacchi. Per capire il problema si consideri il seguenteesempio: si supponga che due sistemi host-based osservino le chiamate di si-stema. Il primo sistema segnala un attacco non appena rileva una chiamata disistema contenente un noto attacco di tipo buffer overflow. Il secondo sistemasegnala lo stesso attacco quando rileva che la sequenza di chiamate succes-

88


sive è “diversa” da quella attesa per il programma in esecuzione. Si trattaevidentemente dello stesso attacco ma, per via delle diverse implementazionio dei diversi criteri, viene segnalato in tempi diversi, a granularità differentie con informazioni diverse. Si noti che i tempi potrebbero essere anche moltodiversi, con le relative conseguenze in un sistema di correlazione.

Come anticipato, avere un formato comune non basta affinché un sistemadi ragionamento automatico possa “comprendere” il significato degli even-ti di alert. In aggiunta al messaggio di alert è necessario, come previsto daIDMEF, una classificazione (una tassonomia) o, meglio, un’ontologia degli at-tacchi e degli eventi in generale [?]. Come sarà più chiaro in seguito, questorequisito è ancora più forte nel caso dei sistemi anomaly detection che, di fatto,rappresentano il futuro dei sistemi di ID.

Classificare gli eventi di intrusione è difficoltoso, non solo per la loro quan-tità ma perché non è facile trovare un set di caratteristiche più corretto di unaltro lungo il quale sviluppare la tassonomia. Le proposte di dimensioni tasso-nomiche sono diverse e vanno dalle idee di considerare “tecniche” e “effetti”[?] a quelle più specifiche di basarsi sulle firme degli attacchi (quando possibi-le) [?]. Altre proposte si fermano invece alla definizione del linguaggio e dellatassonomia consigliata [?].

CONSIDERAZIONI SULLA SEMANTICA DEL FORMATO INTERNO

Nonostante l’indubbia utilità prevedere un formato aperto con una semanticaben definita è altrettanto fuori dubbio che ogni IDS o sistema di correlazionepossa impiegare un proprio formato interno per le elaborazioni, soprattuttoper motivi di efficienza.

A questo scopo è utile riportare i requisiti minimi in termini dei soli at-tributi interessanti che caratterizzano gli eventi nel sistema proposto, perchécostituiscono la base fondamentale per il formato interno. Per definire unevento di allarme si è preso spunto dal modello dei dati proposto da IDMEF.Per ragioni di efficienza si tenterà di mantenere una rappresentazione quan-to più “flat” possibile, evitando quindi l’approccio orientato agli oggetti. Nelseguito e nell’implementazione prototipale, un alert sarà caratterizzato, comeminimo, dalle seguenti proprietà:

• indirizzo di rete di

– IDS, in entrambi i casi, network/host-based, deve essere possibi-le identificare la provenienza dell’allarme nel contesto dalla rete.Visto che è possibile che sullo stesso nodo funzionino più di unIDS, non è detto che basti l’indirizzo IP per disambiguare: a que-sto scopo si giustappone un identificatore univoco, pre-assegnato eimmutabile all’IP. Ad esempio, un alert proveniente da un’host conindirizzo IP 172.16.87.101 potrebbe avere questo attributo pari a172.16.87.101/24-a032j11.

– Aggressore — In questo caso è sufficiente la coppia indirizzo IP,porta TCP. Si noti che questa richiesta è perfettamente generale e

89


copre anche il caso host-based: nel caso di attacco puramente lo-cale è sufficiente porre questo attributo all’indirizzo di default perlocalhost. Chiaramente la porta TCP non è detto che abbia sen-so nel caso di attacchi host puramente locali, pertanto può essereomessa o, meglio, fissata ad un valore predefinito (0, ad esempio).

– Vittima — In questo caso è sufficiente l’indirizzo IP; la porta TCPpuò non essere molto significativa semplicemente perché, nel casonetwork per esempio, è molto facile che non corrisponda a quel-la predefinita per un certo servizio. Pertanto un alert indirizzatoa 172.16.87.101:80 non è detto che sia indirizzata alla “risorsaweb”. Per trattare questo caso particolare è necessaria un’analisipiù accurata ed un attributo dedicato, spiegato di seguito.

• tipo (host/network) — Una semplice flag ad indicare il tipo di IDS.

• timestamp inizio/fine — Per i problemi illustrati in precedenza riguardoalla “granularità” ed ai tempi di segnalazione è indispensabile trovareun modo per isolare l’intervallo di tempo in cui l’attacco è stato condotto.Il modo più semplice ma allo stesso modo efficace consiste nel mante-nere due istanti di tempo: il significato è il più ovvio, ovvero dare una“durata” a quell’entità che l’IDS considera come attacco. Si noti che, perquanto possibile, questo attributo dovrebbe essere quello originale cal-colato dall’analizzatore e non dovrebbe, in nessun modo, essere alteratodurante il processo di normalizzazione/centralizzazione. Nel caso nonsia possibile conoscere i timestamp originali si dovrebbe tentare di ef-fettuare una stima che tenga conto dei tempi di propagazione dall’IDSal sistema che raccoglie gli allarmi. In oltre, come suggerito da IDMEF,è necessario che i timestamp abbiano una buona risoluzione, almenodel microsecondo: si tenga conto infatti che, ad esempio, tra due syscallpossono intercorrere anche pochi microsecondi. Questo attributo è for-se l’unico che non può prescindere dal formato di memorizzazione dalmomento che, a seconda delle scelte, dipende anche la risoluzione: adesempio i timestamp UNIX arrivano fino al secondo, i timestamp NTPfino al picosecondo. Volendo adottare quest’ultimo formato si avrebbe,ad esempio, 0xbc723b45.0xef449129-0xbc723b45.0xff449130.

• nome/classe dell’attacco — Chiaramente, come anticipato più volte, que-sto attributo può essere noto solo in certi casi, ovvero se l’IDS è di tipomisuse-based. Per questo motivo è stato pensato un attributo appositoper il caso anomaly-based.

• grado di anomalia — Non potendo dare una caratterizzazione discreta(e.g., nome, classe) è necessario fornire quello che, per un sistema dianomaly detection, contraddistingue un attacco, ovvero il grado di ano-malia (come suggerito anche da [?]). Per esempio, il prototipo di cui inSezione 5.2 considera attacchi i pacchetti con punteggio è oltre una so-glia: lo scarto rispetto a tale soglia può essere considerato come un gradodi anomalia. Chiaramente è indispensabile che questo numero sia nor-malizzato in un intervallo noto, visto che è molto facile che –in fase di

90


correlazione– vengano confrontati attacchi provenienti da diversi siste-mi. Questo attributo è l’equivalente di Confidence di IDMEF, con ladifferenza che quest’ultimo è a valori discreti (low, medium, high, ecc.).Si noti che nel caso frequente di analizzatori basati su tecniche statisticheè facile dare a questo attributo un significato probabilistico; come verràspiegato meglio in seguito, abbiamo deciso dare a questo attributo il si-gnificato di “credenza” (belief) ovvero “quanto l’IDS crede che si trattidi un attacco”.

• risorsa coinvolta — Riguarda il bersaglio dell’attacco. Nel caso di sistemimisuse-based è piuttosto facile reperire quest’informazione direttamen-te dal database delle firme: tuttavia, anche in questi casi possono essercidelle complicazioni dal momento che non è detto che l’informazione ri-guardo gli attacchi sia strutturata [?]. Ancora più problematico è il casoanomaly-based. Nel caso network il problema è risolvibile facilmente,tramite ispezione del payload e tecniche di fingerprinting con le quali èpossibile risalire al servizio in modo accurato, anche se la porta di desti-nazione è diversa da quella predefinita. Nel caso host, almeno per i si-stemi esaminati, dovrebbe essere sempre possibile conoscere sia il nomedel programma compromesso che il PID del processo relativo.

Nel seguito, soprattutto nella descrizione del prototipo, si farà riferimentoagli attributi appena specificati; per chiarezza, i nomi saranno, rispettivamen-te, i seguenti:

(ids_id, source, destination, ids_type, start_ts, end_ts, attack_class, attack_belief, target_resource)

Pertanto, a prescindere dal formato, un esempio di tupla potrebbe essere ilseguente:

(172.16.87.101/24-a032j11, 172.16.87.103/24, 172.16.87.100/24, N, 0xbc723b45.0xef449129, 0xbc723b45.0xff449130, -, 0.290937, smtp)

e nel caso host invece:

(127.0.0.1-z7012gf, 127.0.0.1, 127.0.0.1, H, 0xbc723b45.0xef449129, 0xbc723b45.0xff449130, -, 0.141044,fdformat(2351))

6.2.2 GRADO DI ANOMALIA COME CLASSE DI ATTACCO

Nel caso non sia disponibile un nome per caratterizzare l’attacco riportatoda un alert è possibile sfruttare, se noto, il “livello di anomalia” dell’attacco.Diversi IDS includono un valore di “confidenza” o di “credenza” nei reportdegli alert; infatti, come visto in precedenza, il formato IDMEF prevede questoattributo per ogni alert, attraverso un’istanza di tipo Assessment.

Abbiamo deciso di usufruire di questo dato, dandovi però un significatoben definito. Per questo ci siamo avvalsi della teoria delle misure fuzzy [?; ?]: iconcetti di belief (“evidenza” a favore, credenza) e misbelief (“evidenza” a sfa-vore) risultano particolarmente utili per modellare questo tipo di grandezze,

91


0.0 0.2 0.4 0.6 0.8 1.0

0.0

0.2

0.4

FPR

Bel

FIGURA 6.2: Andamento di due possibili funzioni per ridurre la misura di belief infunzione del valore di FPR

per via della loro formalità e flessibilità. Infatti, non si ha abbastanza cono-scenza sulla natura di queste variabili per potersi appoggiare alla teoria dellaprobabilità.

Definizione 6.2.1 (belief) Detto X l’universo del discorso si definisce belief la se-guente misura fuzzy:

Bel : ℘(X) 7→ [0, 1]

tale che valgano le seguenti proprietà:

Bel(∅) = 0,Bel(X) = 1Bel(A1 ∪ · · · ∪An) ≥

∑j Bel(Aj)+∑

j<k Bel(Aj ∩Ak) + · · ·+ (−1)n+1Bel(A1 ∩ · · · ∩An)Bel(A) + Bel(AC) ≤ 1

Intuitivamente, il significato di belief (misbelief ) è quello di dare una misuradell’evidenza a favore (sfavore) una proposizione. Nel nostro caso la proposi-zione è “ad un certo istante di tempo è stato rilevato un attacco con certi attri-buti”. Non conoscendo completamente X non ci è però dare alla (mis)belief unsignificato direttamente legato a ℘(X); invece, utilizziamo l’idea implementa-ta in MYCIN [?] (un sistema di supporto alle decisioni in campo medico) in cuiil grado di credenza di un esperto (medico) su una certa affermazione è model-lato come belief, mentre il grado di non-credenza come misbelief. Le due gran-dezze sono additive e, se combinate, possono dare un’ulteriore misura dettacertainy factor (fattore di certezza) in [−1, 1] (dove gli estremi corrispondono a“nessuna evidenza a favore” e “tutta l’evidenza a favore”, rispettivamente).Se non si ha modo di raccogliere evidenza a sfavore si può comunque evitaredi tener conto di misbelief.

Nel caso dei prototipi anomaly-based si possono sfruttare le stime di FPRper pesare la misura di belief; difatti, se un IDS ha una FPR non trascurabileè bene diminuire la belief di conseguenza. Infatti è sensato “credere poco” inun risultato, se questo è sbagliato con un certo grado di errore (noto). Dal mo-mento che FPR è una misura di errore generica e non quella relativa ad ognialert ci è sembrato troppo azzardato interpretarla alla stregua di misbelief: si èscelto invece di costruire una funzione “ad hoc” per abbassare la belief inizialea seconda dell’entità di FPR:

92

Prototipo proof-of-concept

Correlazione

Coda allarmi(formato interno)

Coda allarmi(formato interno)

Aggregazione

Aggregazione

Allarme

Allarme Meta-allarme

Meta-allarme

Log Coda dimeta-allarmi

Metaallarme

.

.

.

.

.

.

HIDS

NIDS

FIGURA 6.3: Architettura prototipale di alto livello del sistema di correlazione: sonostate omessi i processi di normalizzazione, per la loro scarsa rilevanza.

Bel(A) = Bel(A)(1− FPR)eFPR

il cui andamento è preferibile rispetto a quello di

Bel(A) = Bel(A)(1− FPR)

perché un po’ meno pessimistico. In Figura 6.2 riportiamo l’andamento dientrambe le funzioni per Bel(A) = 0.5.

6.3 PROTOTIPO PROOF-OF-CONCEPT

Scopo di questa sezione è presentare l’architettura ed il funzionamento dellanostra proposta di sistema di correlazione. Si è deciso di sviluppare un siste-ma per la correlazione di allarmi provenienti da IDS host e network-based,di tipo anomaly-detection. Nello specifico, la finalità di questo sistema è lacorrelazione degli alert provenienti dai due prototipi presentati nel Capitolo5, entrambi basati su algoritmi di apprendimento non supervisionati. Senzaperdere di generalità il sistema è stato implementato in forma di prototipo inmodo da poter focalizzare l’attenzione sul problema specifico degli algoritmidi correlazione: di fatto si tratta di un test-bed sviluppato in Python.

Lo scopo dello sviluppo è quindi duplice: prima di tutto si vuole analizzarela reale applicabilità delle proposte presentate nella Sezione 3.6.2 e, in secon-do luogo, valutare l’efficacia di un sistema di correlazione nel caso specificodell’anomaly-detection. In particolare ci interessa verificare l’effettiva ridu-zione del numero di falsi allarmi. Nonostante l’implementazione sia di livelloprototipale, nel seguito sono comunque illustrate le specifiche architetturali edi formato, con particolare attenzione, ovviamente, agli algoritmi.

Nel resto della sezione si farà sempre riferimento al caso di alert pro-venienti da due IDS, tuttavia è facile estendere architettura e specifiche alcaso generico, semplicemente replicando i processi di (normalizzazione e)aggregazione.

93


HIDS

NIDS

Alla

rme

(IDS,

src

, tgt

, ...)

Alla

rme

(IDS,

src

, tgt

, ...)

Alla

rme

(IDS,

src

, tgt

, ...)

Alla

rme

(IDS,

src

, tgt

, ...)

Alla

rme

(IDS,

src

, tgt

, ...)

Alla

rme

(IDS,

src

, tgt

, ...)

Alla

rme

(IDS,

src

, tgt

, ...)

Alla

rme

(IDS,

src

, tgt

, ...)

Alla

rme

(IDS,

src

, tgt

, ...)

Alla

rme

(IDS,

src

, tgt

, ...)

Alla

rme

(IDS,

src

, tgt

, ...)

Alla

rme

(IDS,

src

, tgt

, ...)

Alla

rme

(IDS,

src

, tgt

, ...)

Alla

rme

(IDS,

src

, tgt

, ...)

src

src

src

Aggregazione

Alla

rme

(IDS,

src

, tgt

, ...)

Alla

rme

(IDS,

src

, tgt

, ...)

Alla

rme

(IDS,

src

, tgt

, ...)

Alla

rme

(IDS,

src

, tgt

, ...)

Alla

rme

(IDS,

src

, tgt

, ...)

Alla

rme

(IDS,

src

, tgt

, ...)

Alla

rme

(IDS,

src

, tgt

, ...)

Alla

rme

(IDS,

src

, tgt

, ...)

Alla

rme

(IDS,

src

, tgt

, ...)

Alla

rme

(IDS,

src

, tgt

, ...)

Alla

rme

(IDS,

src

, tgt

, ...)

Alla

rme

(IDS,

src

, tgt

, ...)

Alla

rme

(IDS,

src

, tgt

, ...)

Alla

rme

(IDS,

src

, tgt

, ...)

src

src

src

Aggregazione

Correlazione

FP

7

73

3

3

FIGURA 6.4: Architettura prototipale di del sistema di correlazione: dettaglio sui dati.

6.3.1 ARCHITETTURA

In Figura 6.3 è riportata l’architettura di riferimento (alto livello) del sistemadi correlazione: sono stati omessi i processi di normalizzazione, per la loroscarsa rilevanza ed estrema semplicità. L’input della fase di aggregazione èuna coda di allarmi che vengono prodotti dai rispettivi IDS e consumati daiprocessi di aggregazione; questi ultimi producono degli allarmi “aggregati”.Di fatto questa fase ha lo scopo di effettuare una prima riduzione del numerodegli allarmi.

Il motore di correlazione riceve in ingresso un certo numero di code diallarmi (in questo caso due) e, a seconda degli algoritmi di decisione imple-mentati, aggregherà o meno allarmi delle diverse code. Inoltre, per esempio,potrebbe eliminare un certo allarme perché non confermato da una delle al-tre code. L’output sarà costituito da un numero di allarmi molto inferiore ri-spetto al totale di quelli iniziali. In Figura 6.4 sono riportati i dettagli degliinput/output delle due fasi principali.

6.3.2 AGGREGAZIONE: CONCETTI E METODOLOGIE

Di seguito riportiamo gli aspetti, i concetti più importanti ed i problemi che sisono dovuti risolvere nel progetto della fase di aggregazione.

Meta-allarmi Questo termine indica un allarme in realtà costituito da piùsotto-allarmi. In altre parole è il risultato della fase di aggregazione. Questiallarmi verranno chiamati meta-allarmi (o meta-alert) perché rappresentano unallarme astratto che può contenere logicamente da uno o più allarmi. Al limi-te contengono un solo allarme. In letteratura, questo tipo di entità ha presodiversi nomi: hyper-alert, meta-alert, alert-tree, eccetera, ma il significato èsempre lo stesso. Come suggerito da IDMEF questo tipo di dato può esserevisto, banalmente, come una lista di riferimenti agli allarmi originali (o adaltri meta-allarmi).

94


A seconda della dimensione di aggregazione è possibile produrre diversi tipimeta-allarmi; ad esempio, i meta-allarmi per sorgente aggregheranno gli al-larmi con lo stesso attributo source, per esempio. Si noti che non è indispen-sabile che le dimensioni di aggregazione siano esattamente degli attributi: peresempio è possibile aggregare per netmask, se presente, oppure per “famigliadi indirizzi”, ecc. Si tratta comunque di proprietà direttamente derivabili dagliattributi di ogni allarme.

Si noti che ci sono degli attributi lungo i quali non ha sempre senso aggre-gare: ids_id, ids_type, start_ts, end_ts, attack_belief.

È necessario che ogni meta-allarme costituisca un allarme e che, quindi, ab-bia un set di attributi. Per questo motivo è indispensabile disporre una seriedi criteri per (ri-)calcolare gli attributi di un meta-allarme a partire da quellidei suoi componenti. Ovviamente, l’attributo (o gli attributi) scelti come di-mensione di aggregazione sono ereditati direttamente dal meta-allarme. Diseguito si riportano i criteri da noi proposti.

source e destination — Il modo più semplice è di mantenere la lista degliindirizzi degli allarmi che costituiscono il meta-allarme, eliminando ov-viamente gli indirizzi duplicati. Se non è interessante tenere traccia deisingoli host è possibile utilizzare l’indirizzo di (sotto-)rete anziché tene-re la lista di tutti gli indirizzi di una stessa (sotto-)rete: tuttavia questascelta diminuisce la precisione delle operazioni di correlazione che potràbasarsi su (sotto-)reti e non più su host. Tale scelta può essere giustificatanel caso si stia lavorando in reti molto estese con molte (sotto-)reti.

start_ts e end_ts — L’inizio e la fine di una sequenza (non necessariamen-te ordinata nel tempo) di allarmi sono identificabili con l’inizio del pri-mo e la fine dell’ultimo. Pertanto è sufficiente calcolare minimo deglistart_ts ed il massimo degli end_ts. Se la serie è invece ordinata, op-pure se gli istanti di inizio/fine degli allarmi coincidono è più indicatoutilizzare una sola misura di tempo costituita dalla mediana calcolatarispetto agli allarmi che formano un meta-alert.

attack_class — Come nel caso degli indirizzi, la strategia più semplice ènel mantenere una lista dei valori dell’attributo degli alert costituenti.Nel caso, già discusso, in cui si disponga di una descrizione tassonomi-ca degli attacchi o, addirittura, di un’ontologia è possibile ricavare valori“aggregati” più sensati. Per esempio, se due alert si riferiscono a due at-tacchi appartenenti alla stessa sovra-classe è possibile sostituire il nomedi tale classe.

attack_belief — Si tratta di utilizzare un operatore per combinare eviden-ze. In letteratura ne sono stati proposti diversi, dalla semplice mediaaritmetica o geometrica alla media statistica.

resource — Trattandosi di valori categorici non si può far altro che mantene-re una lista, come nei casi precedenti. Anche in questo caso è comunquepossibile calcolare dei valori aggregati ma ciò è possibile se si dispone

95


di conoscenza a priori sulle classi di servizi (caso network) e sulle clas-si di programmi (caso host). Altrimenti è possibile mantenere il valorepiù frequente come quello rappresentativo della risorsa coinvolta in unmeta-alert.

Numero di alert processati Si presuppone che il processo di aggregazio-ne consumi la coda degli alert elaborandone un numero prefissato per volta.Anche se si tratta di semplice aggregazione, questo parametro può influen-zare molto non solo le performance ma anche l’efficacia del sistema, dal mo-mento che da esso dipende la “qualità” del processo di correlazione. Con unasliding window molto piccola decresce la probabilità di trovare candidati perla composizione di un meta-alert quindi è molto facile che l’output del pro-cesso di aggregazione abbia la stessa cardinalità dell’input. D’altra parte, unvalore troppo grande implica la possibilità di aggregare allarmi effettivamenteappartenenti a sessioni di attacco diverse.

La soluzione di questo trade-off dipende molto dal tipo di IDS a monte edè quindi indispensabile prevedere un parametro di configurazione per modi-ficare la dimensione della sliding window. Per esempio, se si sa che gli alert diun IDS network sono riportati con la granularità del pacchetto IP è necessarioimpostare una finestra di dimensione opportuna o si rischia ottenere troppimeta-alert per ogni connessione TCP. Al contrario, se sappiamo che gli alertdi un secondo IDS sono riportati con la granularità della connessione TCP èsufficiente un valore di poche unità, se si vuole mantenere coerente la granu-larità degli alert dei due IDS. Chiaramente gli esempi fatti sono estremamentesemplici e riguardano il caso specifico degli IDS network, in cui comunque lascelta non è facile. Lo stesso problema sussiste ovviamente per ogni ingressoal processo di correlazione.

Si ricorda che, a seconda del tipo di algoritmo scelto in fase di correlazione,la fase di aggregazione può essere o meno utile: pertanto potrà fungere sem-plicemente da buffer con funzionalità di riordinamento basato sui timestamp;non è detto infatti che l’ordine di arrivo degli allarmi sia lo stesso in cui gliallarmi sono stati generati. In altre implementazioni della fase di correlazione,la funzione di aggregazione può assumere caratteristiche diverse.

6.3.3 CORRELAZIONE

Di seguito riportiamo gli aspetti, i concetti più importanti ed i problemi chesi sono dovuti risolvere nel progetto della fase di correlazione. Si ricorda chealcune delle tecniche presentate sono state applicate con successo anche nellafase di aggregazione.

CORRELAZIONE TEMPORALE: APPROCCIO NAÏVE

Un primo approccio consiste nell’osservare gli intervalli di tempo degli allar-mi e cercare di individuare attacchi network che hanno effetti riscontrati anchedall’IDS host-based, senza conoscere nulla sulla tipologia di attacco. Si cercaquindi di catturare tutti quei casi in cui un aggressore sta tentando di compro-

96


mettere remotamente il normale funzionamento di un programma. È il caso,per esempio, di un buffer overflow sul demone del web server: se viene indi-viduata un’anomalia sul traffico di rete, causata da una richiesta HTTP in cuiè stato inserito l’exploit, è molto facile che –entro un certo periodo di tempo–il comportamento del web server inizi a deviare, proprio a causa dell’exploit.Non è il caso, invece, di un attacco lanciato dopo un regolare accesso remo-to all’host: anche nel caso irreale di connessione in chiaro via Telnet è quasiimpossibile che il traffico di rete contenga tracce dell’attacco, pertanto l’IDSnetwork non potrebbe rilevarlo. Si noti che questo stesso approccio è statoutilizzato in realtà anche in fase di aggregazione in quanto è molto frequenteche un IDS riporti alert, molto vicini nel tempo, fanno riferimento allo stessoevento.

Sostanzialmente questo primo approccio è una versione semplificata diquanto proposto in [?]: la differenza sta nel fatto che si è dovuto necessaria-mente rinunciare ad una serie di attributi (e.g., nome/classe di attacco) per-ché non disponibili nel caso anomaly-detection. In [?] si fa comunque uso diattack_belief (succedaneo di attack_class) ma a nostro avviso questo at-tributo non costituisce un buon criterio di similarità: non è detto che due attac-chi con attack_belief simile debbano essere per forza correlati, soprattuttoperché i valori di questo attributo provengono da sistemi diversi.

Un presupposto di questo approccio è dunque che gli alert di tipo networkriferiti ad un certo host (vittima) possano essere confermati dai rispettivi alertdi tipo host, solo se questi ultimi sono nel futuro e sufficientemente viciniai primi. Un primo set di elementi di decisione che un tale algoritmo ha adisposizione è:

• indirizzo destinazione (destination),

• timestamp di inizio/fine (start_ts, end_ts).

Già sulla base di questi attributi è possibile un algoritmo molto sempliceper valutare in maniera comunque sensata la distanza tra due allarmi (con va-lore destination identico). Si noti che vengono considerati “correlabili” duealert a1, a2 se a1 è di tipo network e a2 è di tipo host e a1.start_ts ≤ a2.start_ts;in caso contrario gli alert non vengono considerati del tutto. Anche in questosemplice caso risulta indispensabile tener conto di possibili ritardi: basandosimeramente sui timestamp il grado di correlazione tc(a1, a2) temporale tra dueallarmi è calcolabile come

tc(a1, a2) ∝{

0 a2.start_ts > a1.end_ts

a1.end_ts− a2.start_ts altrimenti

La proposta successiva costituisce l’estensione naturale di questo primopasso: i due verranno confrontati a fine sezione.

CORRELAZIONE TEMPORALE: APPROCCIO FUZZY

L’approccio semplice appena presentato ha il difetto di attribuire sovrapposi-zione nulla ad eventi abbastanza vicini ma non sovrapposti. Invece, il buon

97


t2t1t1 - h t2 + h

FIGURA 6.5: Esempio di “fuzzificazione” di un intervallo crisp.

senso ci fa intuire che, probabilmente, la causa della non-sovrapposizione po-trebbe essere un semplice ritardo intrinseco nel sistema di ID (ad esempio).Per catturare anche questo caso abbiamo deciso di trarre spunto dalla teoriadegli insiemi fuzzy modellando l’intervallo di tempo come un fuzzy set.

Considerazioni di base Non solo l’introduzione di distanze basate su in-tervalli fuzzy permette di evitare di valutare in modo troppo pessimistico ilgrado di correlazione tra due alert, ma da un significato preciso all’incertezzache si ha riguardo al tempo. Infatti, questo approccio permette di modellareprima di tutto l’incertezza che abbiamo sul modo in cui la distanza tra duealert viene misurata; in secondo luogo considera anche l’incertezza sui tempicon cui gli attacchi vengono elaborati propagati in alert. La nota è giustifica-ta dal fatto che il formato IDMEF tenga effettivamente conto di tutte questepeculiarità, infatti è possibile specificare tre timestamp diversi: CreateTime,DetectTime, AnalyzerTime. Nel caso in cui l’analizzatore non introduce ri-tardi (o se gli alert vengono marcati con il timestamp dei pacchetti che hannogenerato l’attacco) allora questi attributi coincideranno.

La Figura 6.5 dà un’idea dell’equivalente fuzzy di un intervallo originaria-mente crisp. Chiaramente è necessario introdurre il parametro h e la funzione,non necessariamente simmetrica, di appartenenza (che nell’esempio è un tra-pezio). Aumentando il valore di h si aumenta la possibilità che due eventinon sovrapposti siano sovrapposti, mentre con la funzione di appartenenza sicontrolla il grado di correlazione (sovrapposizione).

Si noti che non si tratta di un intervallo fuzzy in senso stretto, dal momentoche non sì è definito alcun symbol grounding. A questo punto il grado dicorrelazione c(a1, a2) è calcolabile come l’intersezione di due intervalli fuzzy,ovvero

tc(a1, a2) = inters([a1.start_ts, a1.end_ts], [a2.start_ts, a2.end_ts], h, f) ∈ [0, 1]

dove inters(α, β, h, f) calcola la funzione di appartenenza dell’intervallofuzzy “intersezione” dei due intervalli fuzzy α e β (opportunamente norma-lizzato). Il parametro f controlla il tipo di funzione di appartenenza con i re-lativi parametri. È necessario, comunque, che h sia proporzionale, e sempreinferiore, all’ampiezza dell’intervallo: in questo modo si evita di penalizzaregli intervalli troppo brevi e di favorire intervalli più lunghi, come esemplifica-to in Figura 6.6. Si noti che questo approccio resta comunque valido nel casodi intervalli degeneri per i quali start_ts coincide con end_ts: questa situa-zione è del tutto verosimile e non trascurabile, si pensi per esempio ai sistemidi ID che riportano gli alert come eventi istantanei o al caso di risoluzionetroppo bassa.

98


t

FIGURA 6.6: Esempio di intersezione di due intervalli fuzzy.

Se si interpreta il dominio [0, 1] come l’universo del discorso della varia-bile tc(·), “correlazione nel tempo”, è immediato definire un fuzzy set su talevariabile. A questo punto è possibile considerare anche l’attributo resourcefinora scartato. Per uniformità con quanto fatto precedentemente trattiamoanche questo confronto in modo fuzzy, così da poter trattare la correlazionein generale come l’output di un sistema di logica fuzzy. È necessario dun-que dare una misura di quanto due resource sono considerabili vicine il che,a nostro avviso, costituisce una forzatura. Ipotizziamo pertanto che a monteesista una tassonomia dei servizi e delle applicazioni e che gli alert host/-network riguardanti la stessa applicazione/servizio abbiano gli stessi nomi;quindi, basta definire la funzione di appartenenza (della correlazione rispettoalla resource) pari ad 1 nel caso in cui a1.resource = a2.resource e 0 altrimen-ti. Si tratta evidentemente di un caso degenere di fuzzy set, tuttavia questascelta non chiude la strada ad ulteriori miglioramenti. Avendo a disposizionela possibilità di effettuare un confronto più raffinato basterà modificare la fun-zione di appartenenza ed il sistema di decisione basato su logica fuzzy resteràinalterato.

Approccio completo Le considerazioni fatte in precedenza non sono pri-ve di difetti. Per questo motivo abbiamo deciso di rivederle per riassumere lecaratteristiche importanti in un unico modello di “distanza fuzzy” che tenesseconto di tutti gli aspetti sopra elencati. Prima di tutto è importante notare che,volendo modellare l’incertezza sul timestamp di un alert è bene tenere in con-siderazione che i ritardi difficilmente sono nel futuro; pertanto (ipotizzandoalert di durata nulla), tra le due possibili forme di funzioni di appartenenzamostrate in Figura 6.7 la seconda è molto più verosimile della prima. È moltodifficile che un alert riporti un timestamp più recente di quello reale, mentre èpossibile che il timestamp misurato sia affetto da ritardo.

Questa osservazione è generalizzabile anche al caso di alert con duratanon nulla. Considerando l’intervallo fuzzy in Figura 6.8, l’interpretazione è laseguente: all’istante 0.4 è stato misurato il timestamp d’inizio, all’istante 0.95quello di fine. Le incertezze sono modellate da un ritardo di 0.15 che porta apresumere che l’inizio reale dell’alert possa essere in 0.25, mentre la fine realein 0.8.

Il secondo aspetto che viene modellato è la distanza. A partire dal casoestremo di distanza puramente crisp la situazione è mostrata in Figura 6.9(a). L’insieme a sinistra indica la finestra temporale entro la quale due alertsono considerati vicini (il primo alert non è disegnato ma è posizionato nel-l’origine). L’insieme sulla destra indica l’alert istantaneo: non ricadendo nel-l’intervallo crisp viene considerato lontano. Questa conclusione non tiene in

99


(a) (b)

FIGURA 6.7: Differenza tra due possibili modellazioni dell’incertezza sulla misurazio-ne del timestamp di un alert.

FIGURA 6.8: Esempio di intervallo fuzzy. L’interpretazione è la seguente: all’istante 0.4è stato misurato il timestamp d’inizio, all’istante 0.95 quello di fine. Le incertezze sonomodellate da un ritardo di 0.15 che porta a presumere che l’inizio reale dell’alert possaessere in 0.25, mentre la fine reale in 0.8.

alcun modo conto dei possibili ritardi e delle possibili incertezze nell’opera-zione stessa di misura della distanza, aspetto che viene invece modellato nelcaso in 6.9 (b). Questa seconda alternativa mostra che, considerando anche so-lo l’insieme derivato dall’operazione di minimo tra i due fuzzy set, è possibileapprezzare in modo un po’ più robusto il concetto di distanza/vicinanza.

Ovviamente tutti i parametri di ritardo che costituiscono la forma dei duefuzzy set devono essere stimati a seconda della situazione e specificati comeparametri di configurazione. Se, per esempio, si sa che i timestamp degli alertnon vengono alterati, allora il fuzzy set che rappresenta l’alert in Figura 6.9(a/b) può avere forma a singleton. Si noti che c’è una differenza concettualemolto forte tra utilizzare una forma trapezoidale piuttosto che quella trian-golare per la finestra temporale: nel caso trapezoidale si vuole modellare lacertezza di considerare vicini due alert entro un certo intervallo, ma si ha in-certezza su quanto questo intervallo sia ampio. Nel caso triangolare invece si èdel tutto incerti sulla distanza entro la quale due alert sono considerati vicini,infatti in nessun punto la funzione di appartenenza vale 1. Si ricorda infine cheè ovviamente necessario specificare un ulteriore parametro di configurazione:l’alpha cut del fuzzy set che esprime “Vicinanza”. Infatti, nel momento in cui

100


(a) (b)

FIGURA 6.9: Differenza tra due possibili modi di misurare la distanza tra due alert: ilprimo è crisp, il secondo è fuzzy.

bisogna prendere una decisione, l’unica strada è quella di scegliere una sogliaal di sotto della quale il grado di appartenenza è troppo basso per considerarei due eventi “Vicini”.

Post-elaborazione L’output della fase di correlazione dovrà essere un elen-co di (meta-)allarmi, possibilmente tutti scorrelati tra loro. Inoltre si vuole chese un allarme host (network) non è correlato a nessun allarme network (ho-st), questo venga scartato e considerato come falso positivo. Questo approcciopuò risultare in alcuni casi eccessivamente pessimistico, portando a scartaretroppi allarmi. Per questo motivo è preferibile sfruttare un ulteriore attributo,ovvero la attack_belief. Interpretando i valori di questa variabile come unfuzzy set con tre funzioni di appartenenza (Low, Medium, High) si è scelto discartare tutti gli alert per i qualiattack_belief è Low e per i quali non è pos-sibile trovare un alert (nella coda degli altri alert) con destination identico.Intuitivamente, si scartano gli attacchi “poco credibili”. Chiaramente anche inquesto caso è necessario poter configurare opportunamente la forma dei fuzzyset.

Per dare un’idea di come cambia l’entità della riduzione degli alert al va-riare dei parametri che caratterizzano i fuzzy set sopraindicati, riportiamo inTabella 6.1.

Risultati sperimentali Metteremo ora a confronto l’efficacia dei tre criterifinora presentati

I. distanza crisp,

II. distanza fuzzy e

III. distanza fuzzy considerando la belief

in termini di impatto della riduzione degli allarmi su DR e FPR. Gli esperimen-ti sono stati condotti a partire dagli alert generati dai due IDS, in condizionidi funzionamento ottimale, su tutto il traffico network e host del dataset IDE-VAL. Il tutto si traduce in un totale di circa 1700 alert di cui 1404 riguardano

101


AC W S AD Rid. %- 0 0 0.5 15.17%

1.0 15.24%1.5 15.24%2.0 19.44%3.0 19.44%4.0 20.73%5.0 20.73%6.0 21.58%

0.5 0 1.0 0 15.24%0 2.0 15.67%

1.0 2.0 20.73%1.0 1.0 15.24%1.0 1.0 19.44%

0.7 0 1.0 20.73%

W

SAD

AC

TABELLA 6.1: Riduzione percentuale del numero di alert in ingresso (1404) al variaredei parametri di configurazione dei fuzzy set (in secondi). I valori invariati sono statiomessi nelle righe successive. Intestazioni: AC = Alpha Cut, W = Crisp Window, S =Fuzzy Slope, AD = Alert Delay

l’host pascal (si veda la Figura 4.1): di questi, 128 sono di tipo network, il restodi tipo host. Per questo e per i successivi esperimenti i blocchi di alert vengo-no identificati dalle seguenti sigle: NetP indica gli alert di rete diretti versopascal, NetO indica gli alert di rete diretti verso tutti gli altri host, HostP (oHost) indica gli alert di tipo host, su pascal.

In Figura 6.10 è riportata la variazione dell’efficacia di rilevazione al varia-re della riduzione percentuale del numero di alert. La riduzione percentualedel numero di alert è misurata banalmente come #AlertUscita

#AlertIngresso . È immediatonotare come utilizzando il metodo fuzzy si abbiano pressoché le stesse presta-zioni riscontrate col metodo crisp, tuttavia ricordiamo che il primo approccioè comunque preferibile dal punto di vista del significato teorico. Invece, co-me forse era prevedibile, tenendo conto del valore di belief prima di scartaregli alert scorrelati si ottengono risultati più incoraggianti: questo è da spie-garsi con una maggiore focalizzazione sui falsi positivi che vengono eliminatiperché la loro belief è probabilmente troppo bassa.

In Figura 6.11 è invece riportato l’andamento di FPR. Tenendo conto checomunque si parte da valori di FPR abbastanza bassi, man mano che la ridu-zione aumenta si riesce ad abbassare ancora sensibilmente la percentuale difalsi positivi (a discapito di DR): per le ragioni esposte precedentemente, ilcaso che tiene conto della belief è leggermente migliore degli altri.

CORRELAZIONE BASATA SULLA CAUSALITÀ

Come riportato nella Sezione 3.6.2, un interessante lavoro ha mostrato la pos-sibilità di analizzare statisticamente il grado di correlazione tra due alert. Nel-lo specifico, gli autori hanno sperimentato l’impiego di un test econometrico

102


0 0.02 0.04 0.06 0.08 0.1 0.12 0.14 0.16 0.18 0.20.65

0.7

0.75

0.8

0.85

0.9

0.95

1

1.05

Coeff. riduzione del numero di allarmi

DR

CrispFuzzyFuzzy (belief)

FIGURA 6.10: Variazione dell’efficacia di rilevazione al variare della riduzionepercentuale del numero di alert.

(di Granger) per effettuare il seguente test di ipotesi:

H0: meta-alert a1, a2 non causali H1: a1 causa a2

oppure, equivalentemente

H0: meta-alert a1, a2 non causali H1: a2 causa a1

Come anticipato nella Sezione 3.6, ricordiamo che questo approccio non ri-chiede in alcun modo conoscenza pregressa: è sufficiente infatti pre-processareopportunamente gli alert in modo da creare delle serie temporali (costruitecontando il numero di alert presenti in ogni periodo di campionamento). Iltest infatti permette di asserire se due meta-alert (che altro non sono che delleserie temporali) sono legati da una relazione di causalità. Più precisamente iltest è parametrico rispetto al “passo” p (lag) massimo entro cui si vuole veri-ficare l’influenza della prima serie sulla seconda. Di fatto, le regressioni ven-gono costruite tenendo conto di questo parametro quindi il test è in grado didire se, ad esempio, la storia di a2, fino a p passi indietro, causa a1. A secondadel periodo campionamento il passo p avrà granularità diverse: nelle provefatte abbiamo variato la durata del tempo di campionamento da un minuto amezz’ora, fino ad un’ora.

Gli esperimenti condotti avevano più che altro lo scopo di verificare chel’approccio proposto, per misuse detection, in [?] avesse un senso anche nelcaso particolare di anomaly detection. In particolare, abbiamo notato che gliautori non davano alcuna indicazione sulla scelta del parametro p quindi ab-biamo voluto verificare come variano i risultati al variare di questo parametroe come il periodo di campionamento influenzava i risultati. Ricordiamo che

103


0 0.02 0.04 0.06 0.08 0.1 0.12 0.14 0.16 0.18 0.20.015

0.02

0.025

0.03

0.035

0.04

0.045

0.05

0.055

Coeff. riduzione del numero di allarmi

FP

R

CrispFuzzyFuzzy (belief)

FIGURA 6.11: Variazione di FPR al variare della riduzione percentuale del numero dialert.

nei test prodotti dagli autori impiegano tempo di campionamento pari a 60.0secondi e p non specificato.

Le nostre prove si basano sulla definizione di causalità così come data daltest quindi il minimo che ci si attende è che, se due serie sono legate da unarelazione di causalità, il test duale fallisca. La seconda ipotesi che volevamoverificare è la possibilità di mostrare che gli alert NetP sono legati causalmen-te agli alert HostP, e non il contrario. Allo stesso modo gli alert NetO non do-vrebbero essere legati a quelli HostP. Si sottolinea che dal punto di vista dellacorrelazione statistica, in senso stretto, è curioso notare come i legami appenacitati siano completamente diversi dalle aspettative: per esempio, dalla Figura6.12 sembrerebbe che gli alert NetO siano più correlati a quelli HostP, quandoinvece dovrebbero essere NetP ad essere legati ad HostP.

Primo esperimento Prima di tutto abbiamo voluto indagare, rispetto allapura correlazione, che tipo di informazioni si possono effettivamente estrarreda un test di Granger. L’esperimento è stato condotto nelle medesime con-dizioni dei precedenti (vedi Figura 6.12) e dei successivi. Con un tempo dicampionamento di un minuto si posso trarre le seguenti conclusioni:

• NetP ; HostP: per p = 10 (minuti) il p-value è molto alto, pari a 0.809;ciò significa che per rifiutare l’ipotesi nulla la significatività richiesta do-vrebbe essere almeno dell’81%, il che vuol dire confidenza molto bassanell’asserire causalità. In conclusione, i campioni del passato di NetP(da 0 a 10) non influenzano la storia di HostP: gli alert di tipo networknon causano secondo Granger quelli di tipo host, l’indice di causalità èGCI = 0.6073.

104


−20 −10 0 10 20

−0.

100.

050.

20

Lag

CC

F

NetP, HostP

−20 −10 0 10 20

−0.

10.

10.

3

Lag

CC

F

NetO, HostP

−20 −10 0 10 20

−0.

10.

10.

3

Lag

CC

F

NetP, NetO

FIGURA 6.12: Funzioni di cross-correlazione tra le serie temporali costruite a partiredagli alert dei rispettivi IDS.

• HostP ; NetP: nelle medesime condizioni il p-value è ancora più al-to 0.9502, mentre GCI = 0.3935. Confrontando con il caso precedente,HostP ; NetP meno di quanto NetP ; HostP. Tuttavia nessuno dei duetest è abbastanza significativo per poter concludere “causalità”.

I due risultati appena riportati sono paradossali: nessuna delle due serie dialert causa l’altra. Per questo motivo abbiamo condotto un ulteriore test, sem-pre per p = 10, per vedere se NetO ; HostP: anche questo test ha un p-valuetroppo alto (0.7671) per poter concludere che le due serie siano causali. Cu-riosamente il test duale, HostP ; NetO, ha esito positivo con GCI = 5.5323,infatti il p-value è praticamente nullo (2.841×10−08). Sembrerebbe quindi chegli attacchi condotti sull’host pascal generino in realtà parte di quelli diret-ti verso gli altri host: tuttavia non esiste, nella documentazione di IDEVAL,alcun tipo di evidenza che porti ad accettare questa conclusione.

Secondo esperimento Questa prova è stata condotta per cercare di da-re una spiegazione ai paradossi emersi. Pertanto abbiamo voluto verifica-re estensivamente come cambiano i risultati dei test all’aumentare di p =1, 2, ..., 300 (minuti). Per esempio, la Figura 6.13 mostra p-value (a) e GCI (b)per un periodi di campionamento di 60.0 secondi per i test NetP ; HostP(rosso tratteggiato) e HostP ; NetP (nero continuo).

105


0 10 20 30 40

0.0

0.2

0.4

0.6

0.8

1.0

Lag [minuti]

p−V

alue

0 10 20 30 40

0.0

0.5

1.0

1.5

2.0

Lag [minuti]

Gra

nger

Cau

salit

y In

dex

(a) (b)

FIGURA 6.13: p-value (a) e GCI (b) per un periodo di campionamento di 60.0 secondiper i test NetP ; HostP (rosso tratteggiato) e HostP ; NetP (nero continuo).

50 100 150 200 250

0.0

0.1

0.2

0.3

0.4

Lag [minuti]

p−V

alue

50 100 150 200 250

24

68

Lag [minuti]

Gra

nger

Cau

salit

y In

dex

(a) (b)

FIGURA 6.14: p-value (a) e GCI (b) per un periodo di campionamento di 1800.0 secondiper i test NetP ; HostP (rosso tratteggiato) e HostP ; NetP (nero continuo).

La linea verde orizzontale indica la significatività (α = 0.05): nessuno deidue test ha esito positivo e, se si esclude l’eccezione del p-value per il test NetP; HostP (che in un solo caso scende al di sotto del 20%), l’aumento del para-metro p ha come effetto quello di rendere sempre più “confondibili” i risultatidei due test, che invece dovrebbero essere opposti. Questa conclusione è sup-portata ovviamente anche dall’andamento di GCI(p) che tende, per i due test,tennde allo stesso valore.

La Figura 6.14 conferma quest’ultimo problema e ne introduce un ulterio-re: il risultato dei due test è sempre lo stesso ma è esattamente opposto a quelloprecedente. L’aver aumentato la finestra di campionamento ha quindi avutocome effetto quello di invalidare del tutto i risultati precedenti. Fatta eccezio-

106


100 150 200 250 300

0.0

0.2

0.4

0.6

0.8

1.0

Lag [minuti]

p−V

alue

100 150 200 250 300

2.0

2.5

3.0

3.5

4.0

4.5

Lag [minuti]

Gra

nger

Cau

salit

y In

dex

(a) (b)

FIGURA 6.15: p-value (a) e GCI (b) per un periodo di campionamento di 3600.0 secondiper i test NetP ; HostP (rosso tatteggiato) e HostP ; NetP (nero continuo).

ne per un solo punto, p = 120 (minuti), i risultati dei due test sono sempregli stessi ed indicano “causalità” reciproca (tra l’altro con una significativitàdi 0.001), confermata come in precedenza dai valori di GCI(p).

Aumentando ulteriormente il periodo di campionamento (a 3600.0 secon-di) la situazione è ancora differente, come mostrato in Figura 6.15. Per valoridi p > 230 il test indica causalità per NetP ; HostP (corretto) e non per HostP; NetP (corretto, ma con un p-value molto vicino alla soglia α = 0.05). Senzasorprese, il risultato è confermato da un relativamente alto grado di causalitàper il primo test e di qualche punto più basso per il secondo.

Terzo esperimento (effetto dell’aggregazione) Per via dell’influenza delperiodo di campionamento sui risultati del test, abbiamo voluto verificare an-che quale fosse l’effetto dell’aggregazione sui risultati appena esposti. L’ag-gregazione è stata effettuata con una finestra totalmente fuzzy (funzione diappartenenza triangolare) di ampiezza 2.0 secondi (si veda la Tabella 6.1).

In Figura 6.16 mostriamo il p-value per un periodo di campionamento di60.0 secondi per i test NetP ; HostP (rosso tatteggiato) e HostP ; NetP (nerocontinuo). Senza aggregazione (a) e con aggregazione (b). L’andamento qua-litativo non è molto diverso, difatti per questo test i risultati sono gli stessi,anche il GCI(p) non ha subito forti variazioni, come mostrato in Figura 6.17.

L’unica sostanziale variazione si apprezza con periodi campionamento mag-giori: 1800.0 e 3600.0 secondi. P-value e GCI tracciati in Figura *** permettonoinfatti di rifiutare la nulla con buona significatività, concludendo che NetP ;HostP (con p ∈ [50, 150] minuti).

È invece molto interessante notare come per un periodo di campionamentodi 3600.0 secondi, questo risultato venga a valere per p ∈ [120, 220] minuti.Andando ad osservare la durata media delle sessioni successive di attacco neldataset IDEVAL si riscontra che valori di p ∈ [50, 150] sono più verosimili: in

107


0 10 20 30 40

0.0

0.2

0.4

0.6

0.8

1.0

Lag [minuti]

p−V

alue

0 10 20 30 40

0.0

0.2

0.4

0.6

0.8

1.0

Lag [minuti]

p−V

alue

(a) (b)

FIGURA 6.16: p-value per un periodo di campionamento di 60.0 secondi per i test NetP; HostP (rosso tatteggiato) e HostP ; NetP (nero continuo). Senza aggregazione (a)e con aggregazione (b).

0 10 20 30 40

0.0

0.5

1.0

1.5

2.0

Lag [minuti]

Gra

nger

Cau

salit

y In

dex

0 10 20 30 40

0.0

0.5

1.0

1.5

2.0

Lag [minuti]

Gra

nger

Cau

salit

y In

dex

(a) (b)

FIGURA 6.17: GCI(p) per un periodo di campionamento di 60.0 secondi per i test NetP; HostP (rosso tatteggiato) e HostP ; NetP (nero continuo). Senza aggregazione (a)e con aggregazione (b).

nessun caso attacchi in sequenza sono separati da tempi più lunghi.Confrontando quanto emerso dagli esperimenti con i risultati pubblicati

in [?] le conclusioni non sono affatto incoraggianti. Il primo problema è, chia-ramente, la troppa inaffidabilità del test: se non è neanche possibile verificarecon certezza che una serie causa l’altra e non il viceversa, ci chiediamo come irisultati ottenuti dagli autori siano effettivamente significativi. Inoltre, se nonè possibile impiegare il test con certezza a livello di tutti gli alert (serie tempo-rale completa), le performance non possono altro che calare impiegandolo conmeno campioni, ovvero sulle serie temporali costruite dai singoli meta-alert.

108


50 100 150 200 250

0.0

0.1

0.2

0.3

0.4

Lag [minuti]

p−V

alue

100 150 200 250 300

0.0

0.2

0.4

0.6

0.8

1.0

Lag [minuti]

p−V

alue

(a) (b)

FIGURA 6.18: Valori di p-value e per un periodo di campionamento di 1800.0 (a) e3600.0 secondi (b) per i test NetP ; HostP (rosso tatteggiato) e HostP ; NetP (nerocontinuo).

Ancora più problematica risulta la scelta del passo di regressione p. Abbia-mo constatato infatti come, al variare di quest’ultimo, i risultati siano cambiatianche significativamente. Per questo motivo abbiamo ritenuto opportuno ve-rificare quale fosse la causa: i dati a disposizione o il test di Granger. In Figura6.21 riportiamo i risultati dei test (p-value e GCI) sui dati originali pubblicatiin [?]. I dati sono affidabili e riguardano le popolazioni di polli ed il numerodi uova prodotte ogni anno negli Stati Uniti d’America (dal 1930 al 1983: 33campioni). È interessante notare come per p ≤ 16 ' 33

2 il test Uova ; Gallinerisulti vero mentre per p > 16 il risultato vada a favore del test opposto (nonè stato possibile aumentare ulteriormente p per mancanza di dati). Cionono-stante, per valori ragionevoli di p (rispetto al dominio applicativo) il test “dicala verità”. Pare che la causa dei risultati “falsati” sia quindi da attribuirsi allaqualità dei dati in ingresso che nel caso di IDEVAL è piuttosto scarsa per viadelle numerose regolarità , come abbiamo più volte sottolineato nel Capitolo4.

Riguardo all’aggregazione possiamo concludere che, in linea di massima,ha un effetto simile a quello dell’aumento del periodo di campionamento an-che se non introduce sostanziali variazioni nei risultati finali dei test (fatta ec-cezione, appunto, per un solo caso). Pertanto, visti anche i risultati in Figura6.10 e 6.11, riteniamo che questa metodologia sia tanto semplice ed immediataquanto soddisfacente nei risultati.

Infine ricordiamo che, anche se queste prove sono state effettuate in moda-lità batch, è facile adattare l’implementazione del test di Granger in modo chei parametri dei modelli di regressione vengano calcolati ricorsivamente. Tut-tavia è comunque necessario mantenere una finestra temporale a scorrimentodi ampiezza minima pari a p.

109


010

2030

40

0.0 0.2 0.4 0.6 0.8 1.0

Lag [minuti]

p−Value

50100

150200

250

0.0 0.2 0.4 0.6 0.8 1.0

Lag [minuti]

p−Value

100150

200250

300

0.0 0.2 0.4 0.6 0.8 1.0

Lag [minuti]

p−Value

010

2030

40

0.0 0.2 0.4 0.6 0.8 1.0

Lag [minuti]

p−Value

50100

150200

250

0.0 0.2 0.4 0.6 0.8 1.0

Lag [minuti]

p−Value

100150

200250

300

0.0 0.2 0.4 0.6 0.8 1.0

Lag [minuti]

p−Value

FIGURA 6.19: Valori di p-value per i test NetP ; HostP (rosso tratteggiato) e HostP; NetP (nero continuo). I periodi di campionamento sono 60.0, 1800.0, 3600.0 per lacolonna 1,2,3, rispettivamente. La seconda riga indica l’impiego di aggregazione, laprima no.

110


010

2030

40

0.0 0.5 1.0 1.5 2.0

Lag [minuti]

Granger Causality Index

50100

150200

250

2 4 6 8

Lag [minuti]


100150

200250

300

2.0 2.5 3.0 3.5 4.0 4.5

Lag [minuti]


010

2030

40

0.0 0.5 1.0 1.5 2.0

Lag [minuti]


50100

150200

250

1 2 3 4 5

Lag [minuti]


100150

200250

300

2 4 6 8

Lag [minuti]


FIGURA 6.20: Valori dell’indice di causalità per i test NetP ; HostP (rosso tratteggiato)e HostP ; NetP (nero continuo). I periodi di campionamento sono 60.0, 1800.0, 3600.0per la colonna 1,2,3, rispettivamente. La seconda riga indica l’impiego di aggregazione,la prima no.

111


5 10 15

0.0

0.2

0.4

0.6

0.8

Lag (anni)

p−V

alue

5 10 15

05

1015

2025

Lag (anni)

Gra

nger

Cau

salit

y In

dex

FIGURA 6.21: Valori di p-value e GCI al variare di p (anni) per il test Uova ; Galline(nero continuo) e Galline ; Uova (rosso tratteggiato).

6.4 APPROCCI SECONDARI

In questa sezione riportiamo spunti e considerazioni che, per via della lorodubbia applicabilità hanno un peso minore rispetto agli approcci discussi inprecedenza.

6.4.1 ELIMINAZIONE DI ALERT DUPLICATI

Un approccio complementare ma diverso da quelli visti è basato sull’idea dieliminare alert duplicati: se applicato sugli alert provenienti da un singolo IDSquesta soluzione dovrebbe essere in grado di ridurne il numero senza elimi-nare quelli importanti. Se impiegato considerando tutte le code di alert con-temporaneamente, i candidati per l’eliminazione sono in buona misura alertcorrelati. Questa sezione ha lo scopo di sondare la reale efficacia di questoapproccio e l’applicabilità al problema della correlazione di allarmi.

Un problema ancora aperto e molto simile a questo è quello del record mat-ching [?] che ha come scopo l’identificazione di record (in una base di dati)che afferiscono allo stesso oggetto nel mondo reale. Un generico algoritmo direcord matching è basato sul confronto diretto di attributi corrispondenti perinferire se due record sono o meno lo stesso, anche in presenza di errori e nonperfetta coincidenza tra attributi.

Esistono diversi algoritmi e misure di similarità nel campo del record mat-ching, alcune molto dipendenti dal contesto, altre cieche e puramente lessico-sintattiche. La maggior parte purtroppo non è utilizzabile se non in modalitàbatch, perché richiede che i record siano ordinati. Chiaramente questa richie-sta non è garantibile nel campo dell’alert correlation (gli alert vengono proces-sati in tempo reale), pertanto ci si può appoggiare soltanto ai criteri di distan-

112

Approcci secondari

za proposti per valutare la similarità tra due stringhe. Intuitivamente, e ancheconsiderando i criteri riportati nella sezione successiva, non ha senso valutarela similarità tra due alert tenendo conto di tutti gli attributi; si incorrerebbefacilmente nel grossolano errore di considerare simili, ad esempio, i valori 21e 22 per le porte di destinazione.

Primo esperimento Prima di tutto abbiamo paragonato l’efficacia di diver-se distanze tra stringhe. Abbiamo scelto degli alert effettivamente molto diver-si ed altri effettivamente molto simili. Questo esperimento è limitato all’analisidi alert provenienti dalla stessa coda (medesimo IDS), ovvero:

A1 Timestamp: 04/09-16:48:39.0Belief: 0.0400735183086529Resource: /export/home/felinai/temp.bkgAddresses: NULL:NULL - 172.16.112.50:NULL

A2 Timestamp: 04/09-18:15:34.0Belief: 0.0400735183086529Resource: /export/home/felinai/temp.bkgAddresses: NULL:NULL - 172.16.112.50:NULL

A3 Timestamp: 03/29-08:50:19.0Belief: 0.3796873405677Resource: /opt/local/bin/gccAddresses: NULL:NULL - 172.16.112.50:NULL

I risultati sono riportati in Tabella 6.2. Gli identificatori dei criteri jaro e levindicano l’uso della distanza di Jaro-Winkler [?; ?] e di Levenshtein [?] (nor-malizzata). Senza la pretesa di dare una spiegazione di come i due criteri fun-zionino, le due misure sono state scelte perché molto diverse tra loro: la primainfatti è di tipo “edit-distance” (misura ovvero il numero di caratteri da modi-ficare per rendere le due stringhe identiche), la seconda invece tiene conto dilunghezza, caratteri identici e trasposizioni.

A1 vs. A2 A1 vs. A3 CRITERIO

0.975355 0.731977 jaro0.952381 0.457375 lev

TABELLA 6.2: Differenti misure di similarità

Le distanze totali riportate in Tabella 6.2 sono la media pesata (sulla lun-ghezza degli attributi) delle distanze tra i singoli attributi, limitatamente aindirizzo IP e porta di destinazione, belief, timestamp e risorsa. Sebbene ledue distanze diano risultati piuttosto diversi, in entrambi i casi riescono adindividuare più o meno marcatamente che A1 = A2 e A1 6= A3. Chiaramente ènecessario stimare delle soglie che permettano di discriminare tra la decisionedi “similarità” e “dissimilarità”.

6.4.2 CLUSTERING DEGLI ALLARMI

Il problema del clustering diventa molto difficile quando gli elementi da rag-gruppare non sono numerici. Nel nostro caso vogliamo verificare la possibi-

113


lità (e l’efficacia) di raggruppare allarmi “simili” o, meglio, correlati. A par-tire da una serie di allarmi si vuole che, sulla base di criteri di vicinanza si-mili a quelli discussi nel paragrafo precedente, questo algoritmo sia in gra-do di individuare gruppi di allarmi: a partire dai cluster saranno costrui-ti quindi i meta-allarmi di output (eventualmente input di altri algoritmi dicorrelazione).

L’unica tecnica di clustering a nostra disposizione è di tipo gerarchico [?],dal momento che non è metrica. Questo tipo di algoritmi si basa sul calcolodelle distanze tra coppie di cluster, raggruppando ad ogni iterazione i due piùvicini. Inizialmente ci sono tanti cluster quanti sono gli elementi da raggrup-pare e l’algoritmo prosegue fino a che non è soddisfatta una certa condizionedi terminazione. Chiaramente la scelta di un criterio di terminazione influenzanotevolmente la qualità del processo di clustering: arrestare prematuramentel’algoritmo potrebbe portare ad un raggruppamento troppo blando; arrestarlotroppo tardi, invece, indurrebbe la formazione di gruppi magari non naturali.Ancora più importante è ovviamente la definizione delle funzioni di distan-za, soprattutto in casi particolari come quello in esame: tale funzione riceve-rà in ingresso due allarmi e dovrà ritornare una misura numerica della lorodistanza.

Distanza tra due allarmi Sebbene si tratti di due problemi concettualmen-te diversi, il clustering degli allarmi assomiglia molto al clustering delle chia-mate di sistema, così come descritto in [?]. Ogni allarme è una tupla di attributidi tipo diverso; allo stesso modo una chiamata di sistema è caratterizzata daun nome e da una lista di argomenti di diverso tipo.

Con questa premessa, la distanza tra due allarmi può essere vista come lasomma di tanti contributi ovvero le distanze tra i singoli attributi corrispon-denti. Intuitivamente, due allarmi sono tanto più distanti quanto più sono di-stanti i rispettivi attributi. Per essere più precisi di seguito abbiamo riportatouna serie di considerazione sulla similarità tra valori di attributi dello stessotipo:

IP — Se due alert presentano indirizzi IP sorgente e/o destinazione “vicini”allora è possibile che si riferiscano alla stessa sessione di attacco in quan-to, per esempio, provengono dalla stessa sotto-rete e/o sono diretti allastessa sotto-rete, come suggerito in [?]. Il modo più sensato di esprimereil concetto di vicinanza tra indirizzi IP è quello di contare quanti dei 32bit sono, in sequenza, uguali. Ad esempio,

• 172.16.112.50 (10101100000100000111000000110010) e

• 172.16.113.50 (10101100000100000111000100110010)

hanno 31 bit identici infatti, nell’ipotesi di netmask a 24 bit appartengo-no a due sotto-reti adiacenti, per netmask più ridotte alla stessa sotto-rete. Per questo motivo, nel calcolo di questo valore è necessario tenerconto della sotto-rete di appartenenza. Per questo ed altri motivi, l’ideapresentata in [?] sarà adattata per tenere conto di adiacenza di sotto-retie adiacenza di indirizzi nella stessa sotto-rete. È comunque vero che non

114

Approcci secondari

è affatto detto che l’adiacenza tra indirizzi indichi effettiva similarità:dipende fortemente dalle scelte dei progettisti della rete.

Timestamp — Come approfonditamente visto in precedenza, due con time-stamp molto vicini hanno buone ragioni di essere considerati simili.

Risorse e porte — Le porte (es., 21) e le risorse (es., in.ftpd) esprimono l’og-getto dell’attacco. Considerando questi attributi separatamente, non èdetto che due alert che presentano gli stessi valori siano effettivamente“correlati”. Tuttavia, se si tiene conto anche degli altri criteri di vicinan-za, ha senso considerare vicini gli alert che presentano stessi valori peruno dei due (o entrambi questi) attributi. Per esempio, se due alert sonovicini nel tempo e hanno, rispettivamente:

• PORT: 22, RESOURCE: sshd

• PORT: -, RESOURCE: lynx

è abbastanza sensato concludere che si riferiscono ad una stessa sessioneremota (via SSH). Un’alternativa è invece quella di considerare le soleporte ed assegnare un valore di distanza pari a zero se per entrambi glialert si tratta di porte well-known; un valore fisso altrimenti. La stessaconsiderazione può essere applicata alle risorse per le quali risulta peròdifficile stabilire se due risorse fanno parte dello stesso “tipo”.

Per la mancanza di un numero cospicuo di alert questo approccio è statolasciato agli sviluppi futuri (Capitolo 7), soprattutto per quanto concerne lavalidazione delle misure di distanza e la scelta di criteri sensati per la com-putazione di modelli aggregati per caratterizzare i cluster durante i vari passidell’agglomerazione.

115

— CAPITOLO 7 —

CONCLUSIONI E SVILUPPI FUTURI

L’anomaly detection e la correlazione di eventi di anomalia è un problemaestremamente difficile da risolvere. La varietà di contributi in letteratura, nonsempre approfonditi e validati con cura, dimostra quanto sforzo sia ancoranecessario, in particolare per le tecniche di correlazione.

Riguardo l’anomaly detection, durante questo lavoro abbiamo potuto esa-minare lo stato dell’arte e, soprattutto, il funzionamento e le prestazioni distrumenti che implementano algoritmi completamente non supervisionati: no-nostante si tratti di prototipi di ricerca entrambi hanno mostrato notevoleefficacia e possibilità di miglioramento effettivo. Ciò vale per l’anomaly de-tection in generale, in quanto approccio che, a nostro avviso, può aumentaresignificativamente il livello di protezione nei moderni sistemi informatici.

In merito alla valutazione degli IDS abbiamo potuto riscontrare le mancan-ze ed i difetti di IDEVAL, unico dataset oggi esistente e in pratica utilizzabile.Oltre alle problematiche riportate in letteratura, ne abbiamo rilevate di nuoveriguardanti l’attività host.

L’alert correlation si è rivelato un campo di ricerca molto giovane. La mag-gioranza degli strumenti, commerciali e non, oggi si basa su algoritmi chespesso non possono prescindere dalla particolare situazione e dal particolaretipo di analizzatori. Ciò vale a maggior ragione nel caso dell’anomaly detec-tion, in cui la conoscenza a priori sul fenomeno riportato è ancora più scarsarispetto agli strumenti tradizionali. Non solo, lo sviluppo di un prototipo peranalizzare algoritmi di correlazione, ha rivelato mancanze anche a livello didefinizione del problema. Si è potuto notare che i maggiori problemi teorici ri-guardano anche il significato dei dati in ingresso ai sistemi di correlazione,sia per quanto riguarda l’eterogeneità (o l’assenza) della semantica di ciascunformato, sia per via della “granularità degli alert” a priori diversa per ogniIDS.

Il prototipo sviluppato ha volutamente un’architettura molto semplice esi focalizza su entrambi gli aspetti di aggregazione e correlazione, spesso con-fusi. Il problema dell’aggregazione riguarda la “fusione” di alert a scopo diridurre le dimensioni dell’input alle operazioni di correlazione e, in ogni caso,a sopperire ai problemi di “granularità” appena menzionati. Il risultato fina-le dovrebbe aiutare l’analista ad individuare scenari di attacco o, comunque,attacchi progettati per essere in qualche modo collegati.

Gli algoritmi di aggregazione esatti basati sugli attributi degli alert nonhanno presentato alcun tipo di difficoltà, se non per i problemi di normaliz-zazione di formato. Più interessanti si sono rivelate invece le tecniche basatesulla prossimità temporale degli eventi. Questo aspetto è stato affrontato inmodo classico, con algoritmi di aggregazione basati su finestre temporali cri-sp, e con una proposta originale, naturale evoluzione della precedente e basatasu intervalli fuzzy. Sebbene i due non abbiano presentato notevoli differenze

117

7. CONCLUSIONI E SVILUPPI FUTURI

di prestazioni, il secondo approccio ha il duplice vantaggio di essere sensi-bilmente più robusto e, soprattutto, di modellare il concetto di incertezza (sianel processo stesso di aggregazione, sia nel concetto di “vicinanza nel tem-po”, sia sugli eventuali ritardi di propagazione/registrazione degli eventi diattacco-alert).

Per la soluzione del problema di correlazione, quando i possibili scena-ri non sono noti, ci siamo appoggiati alla teoria della verifica di ipotesi. Inparticolare abbiamo voluto verificare l’efficacia dei test di causalità i qualisembrano essere gli unici approcci in grado di dare un significato statisticochiaro al “legame” tra attacchi. Applicati con discreto successo al caso misusedetection (in [?]), i test di Granger si sono rivelati alquanto problematici all’a-nomaly detection. Prima di tutto per la mancanza di conoscenza sull’attaccoma anche per la contraddittorietà dei risultati al variare di parametri di test,la scelta dei quali si è rivelata cruciale per la correttezza dei risultati. Non siesclude che parte di questi problemi sia causato dallo scarso numero di dati adisposizione.

Nella realizzazione del prototipo, alcuni approcci sono stati valutati soloin parte o lasciati agli sviluppi futuri. In particolare, nel caso del clusteringè necessario studiare in modo approfondito dei modelli per caratterizzare icluster e gli elementi ad essi appartenenti; alcune considerazioni sul concettodi “distanza tra alert” sono già state riportate.

Il prototipo host-based modellizza le sequenze di chiamate come modellimarkoviani del primo ordine. Non si esclude tuttavia che il comportamentodelle syscall sia meglio caratterizzabile con modelli di ordine superiore; perquesto abbiamo pianificato l’implementazione di procedure per la verifica dimarkovianità dei modelli costruiti. In un secondo momento verrà consideratala possibilità di generalizzare la modellazione con modelli nascosti.

Dal punto di vista dello sviluppo è già stato avviato un progetto per lareingegnerizzazione, in C, del prototipo host-based, soprattutto per l’aspettodel funzionamento on-line. È necessario che il prototipo network-based vengaesteso per gestire il protocollo di trasporto User Datagram Protocol (UDP) e IPversione 6 (per il livello 2).

Il prototipo di alert correlation funziona attualmente in modalità batch. Siail test di Granger sia gli algoritmi di aggregazione possono essere implemen-tati per funzionare on-line, se si riesce a garantire che gli eventi (alert) arrivanonello stesso ordine specificato dai timestamp.

Tutti i prototipi dovranno subire ulteriori test, su dati diversi da IDEVAL:chiaramente una richiesta simile presuppone l’esistenza un dataset realisticoed effettivamente utilizzabile. In merito, stiamo elaborando una metodologiaper il test degli IDS, ma si tratta di un problema estremamente complesso nellasua natura.

118

RIFERIMENTI BIBLIOGRAFICI

ANDERSON, DEBRA, LUNT, TERESA F., JAVITZ, HAROLD, TAMARU, ANN,& VALDES, ALFONSO. 1995 (May). Detecting unusual program behaviorusing the statistical component of the next-generation intrusion detection expertsystem (nides). Tech. rept. Computer Science Laboratory SRI-CSL.

ANDERSON, J. P. 1980 (Apr). Computer security threat monitoring andsurveillance. Tech. rept. J. P. Anderson Co., Ft. Washington, Pennsylvania.

ANDERSON, ROSS. 2001. Security engineering. USA: John Wiley & Sons.

ATHANASIADES, NICHOLAS, ABLER, RANDAL, LEVINE, JOHN, OWEN, HEN-RY, & RILEY, GEORGE. 2003. Intrusion detection testing and benchmar-king methodologies. Page 63 of: Ieee-iwia ’03: Proceedings of the first ieeeinternational workshop on information assurance (iwia’03). Washington, DC,USA: IEEE Computer Society.

BACE, REBECCA GURLEY. 2000. Intrusion detection. Indianapolis, IN, USA:Macmillan Publishing Co., Inc.

BALASUBRAMANIYAN, JAI, GARCIA-FERNANDEZ, JOSE OMAR, SPAFFORD,EUGENE H., & ZAMBONI, DIEGO. 1998. An architecture for intrusion de-tection using autonomous agents. Tech. rept. Coast TR 98-05. Department ofComputer Sciences, Purdue University.

BALDWIN, LAWRENCE. 2001. mynetwatchman. http://www.mynetwatchman.com/.

BARBARÁ, D., WU, N., & JAJODIA, S. 2001a. Detecting novel network intru-sions using bayes estimators. In: Proceedings of the first siam internationalconference on data mining.

BARBARÁ, DANIEL, COUTO, JULIA, JAJODIA, SUSHIL, & WU, NINGNING.2001b. Adam: a testbed for exploring the use of data mining in intrusiondetection. Sigmod rec., 30(4), 15–24.

BOYD, S., & KEROMYTIS, A. 2004. Sqlrand: Preventing sql injection attacks.http://citeseer.ist.psu.edu/boyd04sqlrand.html.

BURGESS, MARK, HAUGERUD, HÂREK, STRAUMSNES, SIGMUND, & REITAN,TROND. 2002. Measuring system normality. Acm trans. comput. syst., 20(2),125–160.

CABRERA, J. B. D., LEWIS, L., & MEHARA, R.K. 2001. Detection and classifi-cation of intrusion and faults using sequences of system calls. Acm sigmodrecord, 30(4).

119

http://www.mynetwatchman.com/

http://www.mynetwatchman.com/

http://citeseer.ist.psu.edu/boyd04sqlrand.html

CASAS-GARRIGA, G., DÍAZ, P., & BALCÁZAR, J.L. 2005. ISSA: An integra-ted system for sequence analysis. Tech. rept. DELIS-TR-0103. UniversitatPaderborn.

CENTER, CERT COORDINATION. 2006. Cert coordination center statistics 1988-2006. http://www.cert.org/stats/cert_stats.html.

CHAUDHURI, SURAJIT, & DAYAL, UMESHWAR. 1997. An overview of datawarehousing and olap technology. Sigmod rec., 26(1), 65–74.

CHEVALEYRE, Y., BREDECHE, N., & ZUCKER, J. 2002. Learning rules frommultiple instance data : Issues and algorithms. In: Proceedings of the9th international conference on information processing and management ofuncertainty in knowledge-based systems (ipmu02).

COCHINWALA, M., DALAL, S., ELMAGARMID, A.K., & VERYKIOS, V.S. 2001.Record matching: Past, present and future. http://citeseer.ist.psu.edu/588173.html.

COHEN, WILLIAM W. 1995. Fast effective rule induction. Pages 115–123of: PRIEDITIS, ARMAND, & RUSSELL, STUART (eds), Proc. of the 12thinternational conference on machine learning. Tahoe City, CA: MorganKaufmann.

COLOMBE, JEFFREY B., & STEPHENS, GREGORY. 2004. Statistical profiling andvisualization for detection of malicious insider attacks on computer net-works. Pages 138–142 of: Vizsec/dmsec ’04: Proceedings of the 2004 acm work-shop on visualization and data mining for computer security. New York, NY,USA: ACM Press.

COMBS, GERALD. 1998. Ethereal: A network protocol analyzer. http://www.ethereal.com.

COMBS, GERALD. 2006. Ethereal sample captures. http://wiki.ethereal.com/SampleCaptures.

CROSBIE, MARK, PRICE, KATHERINE, & CURRY, DAVID A. 1997. Intrusiondetection systems. http://www.cerias.purdue.edu/about/history/coast_resources/idcontent/ids.html.

CUPPENS, FRÉDÉRIC, & MIÉGE, ALEXANDRE. 2002. Alert correlation in a coo-perative intrusion detection framework. Page 202 of: Sp ’02: Proceedings ofthe 2002 ieee symposium on security and privacy. Washington, DC, USA:IEEE Computer Society.

DAIN, O., & CUNNINGHAM, R. 2001. Fusing heterogeneous alert streams intoscenarios. http://citeseer.ist.psu.edu/dain01fusing.html.

DANYLIW, R., MEIJER, J., & DEMCHENKO, YURI. 2005. Incident object descrip-tion and exchange format xml schema. http://staff.science.uva.nl/~demch/projects/iodef/draft-ietf-inch-iodef-044.xsd.

120

http://www.cert.org/stats/cert_stats.html

http://citeseer.ist.psu.edu/588173.html


http://www.ethereal.com

http://www.ethereal.com

http://wiki.ethereal.com/SampleCaptures

http://wiki.ethereal.com/SampleCaptures

http://www.cerias.purdue.edu/about/history/coast_resources/idcontent/ids.html

http://www.cerias.purdue.edu/about/history/coast_resources/idcontent/ids.html

http://citeseer.ist.psu.edu/dain01fusing.html

http://staff.science.uva.nl/~demch/projects/iodef/draft-ietf-inch-iodef-044.xsd

http://staff.science.uva.nl/~demch/projects/iodef/draft-ietf-inch-iodef-044.xsd

DANYLIW, R., MEIJER, J., & DEMCHENKO, YURI. 2006 (September). The in-cident object description exchange format. Tech. rept. Extended IncidentHandling Working Group/Internet Engineering Task Force.

DE QUEIROZ, JOSE DUARTE, DA COSTA CARMO, LUIZ F. RUST, & PIRMEZ,LUCI. 1999. Micael: An autonomous mobile agent system to protectnew generation networked applications. In: Recent advances in intrusiondetection.

DEBAR, H., BECKER, M., & SIBONI, D. 1992. A neural network componentfor an intrusion detection system. In: Proc. ieee symposium on research incomputer security and privacy.

DEBAR, H., CURRY, D., & FEINSTEIN, B. 2006 (March). The intrusion detectionmessage exchange format. Tech. rept. France Telecom and Guardian andTNT.

DEBAR, HERVÉ, & WESPI, ANDREAS. 2001. Aggregation and correlation ofintrusion-detection alerts. Pages 85–103 of: Raid ’00: Proceedings of the 4thinternational symposium on recent advances in intrusion detection. London,UK: Springer-Verlag.

DEMCHENKO, YURI. 2001. Iodef vs idmef: Xml dtd analysis.http://www.terena.nl/activities/tf-csirt/iodef/docs/iodef-idmef-xmldtd-00-rfc.html.

DENNING, D. E. 1987. An intrusion-detection model. Ieee transactions onsoftware engineering, SE-13(2), 222–232.

DSHIELD. 2000. Distributed intrusion detection system - Dshield. http://www.dshield.org/.

ECKMANN, S., VIGNA, G., & KEMMERER, R. 2000 (November). STATL: Anattack language for state-based intrusion detection. In: Proceedings of theacm workshop on intrusion detection.

EDMUND M. CLARKE, JR., GRUMBERG, ORNA, & PELED, DORON A. 1999.Model checking. Cambridge, MA, USA: MIT Press.

ERTOZ, L., EILERTSON, E., LAZAREVIC, A., TAN, P., SRIVASTAVA, J., KUMAR,V., & DOKAS, P. 2004. Next generation data mining. MIT Press. Chap. 3.

ESKIN, ELEAZAR. 2000. Anomaly detection over noisy data using learnedprobability distributions. Pages 255–262 of: Proc. 17th international conf. onmachine learning. Morgan Kaufmann, San Francisco, CA.

FAN, WEI, MILLER, MATTHEW, STOLFO, SALVATORE J., LEE, WENKE, &CHAN, PHILIP K. 2001. Using artificial anomalies to detect unknownand known network intrusions. Pages 123–130 of: ICDM.

FORREST, STEPHANIE, HOFMEYR, STEVEN A., SOMAYAJI, ANIL, & LONG-STAFF, THOMAS A. 1996. A sense of self for Unix processes. In: Proceedingsof the 1996 ieee symposium on security and privacy. Washington, DC, USA:IEEE Computer Society.

121

http://www.terena.nl/activities/tf-csirt/iodef/docs/iodef-idmef-xmldtd-00-rfc.html

http://www.terena.nl/activities/tf-csirt/iodef/docs/iodef-idmef-xmldtd-00-rfc.html

http://www.dshield.org/

http://www.dshield.org/

GIL, DAVID. 2003. Open source security information management. http://www.ossim.net/docs.php.

GOSH, A. K., WANKEN, J., & CHARRON, F. 1998. Detecting anomalous andunknown intrusions against programs. Page 259 of: Acsac ’98: Proceedingsof the 14th annual computer security applications conference. Washington, DC,USA: IEEE Computer Society.

HAINES, JOSHUA, RYDER, DORENE KEWLEY, TINNEL, LAURA, & TAYLOR,STEPHEN. 2003. Validation of sensor alert correlators. Ieee security andprivacy, 01(1), 46–56.

HARTIGAN, J. A. 1975. Clustering algorithms. Wiley.

HIPP, JOCHEN, GÜNTZER, ULRICH, & NAKHAEIZADEH, GHOLAMREZA.2000. Algorithms for association rule mining — a general survey andcomparison. SIGKDD explorations, 2(1), 58–64.

HOCHBERG, JUDITH, JACKSON, KATHLEEN, STALLINGS, CATHY, MCCLARY,J. F., DUBOIS, DAVID, & FORD, JOSEPHINE. 1993. Nadir: an automatedsystem for detecting network intrusion and misuse. Comput. secur., 12(3),235–248.

HOWARD, J., & LONGSTAFF, T. 1998. A common language for computer securityincidents. http://citeseer.ist.psu.edu/howard98common.html.

HU, YI, & PANDA, BRAJENDRA. 2004. A data mining approach for databaseintrusion detection. Pages 711–716 of: Sac ’04: Proceedings of the 2004 acmsymposium on applied computing. New York, NY, USA: ACM Press.

JAIN, A. K., MURTY, M. N., & FLYNN, P. J. 1999. Data clustering: A review.Acm computing surv., 31(3), 264–323.

JARO, M. A. 1995. Probabilistic linkage of large public health data files.Statistics in medicine, 14(5–7), 491–498.

JAVITS, H. S., & VALDES, A. 1993 (March). The NIDES statistical component:description and justification. Tech. rept. SRI International.

JULISCH, KLAUS. 2003. Clustering intrusion detection alarms to support rootcause analysis. Acm trans. inf. syst. secur., 6(4), 443–471.

JULISCH, KLAUS, & DACIER, MARC. 2002. Mining intrusion detection alarmsfor actionable knowledge. Pages 366–375 of: Kdd ’02: Proceedings of theeighth acm sigkdd international conference on knowledge discovery and datamining. New York, NY, USA: ACM Press.

KENDALL, K. 1999. A database of computer attacks for the evaluation of intrusiondetection systems. M.Phil. thesis, Massachussets Institute of Technology.

KLIR, GEORGE J., & FOLGER, TINA A. 1987. Fuzzy sets, uncertainty, andinformation. Upper Saddle River, NJ, USA: Prentice-Hall, Inc.

122

http://www.ossim.net/docs.php

http://www.ossim.net/docs.php

http://citeseer.ist.psu.edu/howard98common.html

KLIR, GEORGE J., & WANG, ZHENYUAN. 1992. Fuzzy measure theory. Springer.

KRUEGEL, C., MUTZ, D., VALEUR, F., & VIGNA, G. 2003. http://www.cs.ucsb.edu/~rsg/libAnomaly.

KRÜGEL, CHRISTOPHER, & TOTH, THOMAS. 2003. Using decision trees toimprove signature-based intrusion detection. Pages 173–191 of: Raid.

KUMAR, S. 1995. Classification and detection of computer intrusions. Ph.D. thesis,Purdue University.

LABIB, K., & VEMURI, R. 2002. NSOM: A real-time network-based intrusiondetection system using self-organizing maps. Tech. rept. Dept. of AppliedScience, University of California, Davis.

LANDWEHR, CARL E., BULL, ALAN R., MCDERMOTT, JOHN P., & CHOI,WILLIAM S. 1994. A taxonomy of computer program security flaws. Acmcomput. surv., 26(3), 211–254.

LEE, WENKE, & FAN, WEI. 2001. Mining system audit data: opportunitiesand challenges. Acm sigmod rec., 30(4), 35–44.

LEE, WENKE, & STOLFO, SALVATORE. 1998. Data mining approaches forintrusion detection. In: Proc. of the 7th USENIX security symp.

LEE, WENKE, STOLFO, SALVATORE, & MOK, KUI. 1999. Mining in a data-flowenvironment: Experience in network intrusion detection. Pages 114–124of: CHAUDHURI, SURAJIT, & MADIGAN, DAVID (eds), Proc. of the 5th int’lconf. on knowledge discovery and data mining.

LEVENSHTEIN, VLADIMIR I. 1966. Binary codes capable of correcting deletions,insertions, and reversals. Tech. rept. 8.

LICHODZIJEWSKI, P., ZINCIR-HEYWOOD, A.N., & HEYWOOD, M.I. 2002(May). Dynamic intrusion detection using self organizing maps. In: 14thannual canadian information technology security symp.

LINDQVIST, ULF, & JONSSON, ERLAND. 1997. How to systematically classifycomputer security intrusions. In: Proc. of the 1997 ieee symposium on securityand privacy.

LIPPMANN, RICHARD, CUNNINGHAM, ROBERT K., FRIED, DAVID J., GRAF,ISAAC, KENDALL, KRIS R., WEBSTER, SETH E., & ZISSMAN, MARC A.1999. Results of the darpa 1998 offline intrusion detection evaluation. In:Recent advances in intrusion detection.

LIPPMANN, RICHARD, HAINES, JOSHUA W., FRIED, DAVID J., KORBA, JONA-THAN, & DAS, KUMAR. 2000a. The 1999 darpa off-line intrusion detectionevaluation. Comput. networks, 34(4), 579–595.

LIPPMANN, RICHARD, HAINES, JOSHUA W., FRIED, DAVID J., KORBA, JO-NATHAN, & DAS, KUMAR. 2000b. Analysis and results of the 1999 DAR-PA off-line intrusion detection evaluation. Pages 162–182 of: Proceedings

123

http://www.cs.ucsb.edu/~rsg/libAnomaly

http://www.cs.ucsb.edu/~rsg/libAnomaly

of the third international workshop on recent advances in intrusion detection.London, UK: Springer-Verlag.

LIPPMANN, RICHARD, FRIED, DAVID, GRAF, ISAAC, HAINES, JOSHUA, KEN-DALL, KRISTOPHER, MCCLUNG, DAVID, WEBER, DAN, WEBSTER, SE-TH, WYSCHOGROD, DAN, CUNNINGHAM, ROBERT, & ZISSMAN, MARC.2000c. Evaluating intrusion detection systems: The 1998 DARPA off-lineintrusion detection evaluation. In: Proceedings of the DARPA informationsurvivability conference and exposition. Los Alamitos, CA: IEEE ComputerSociety Press.

MAHONEY, M. V., & CHAN, P. K. 2002a. A machine learning approach to detec-ting attacks by identifying anomalies in network traffic. Tech. rept. CS-2002-08.Florida Institute of Technology.

MAHONEY, M. V., & CHAN, P. K. 2003 (September). An analysis of the 1999DARPA / Lincoln laboratory evaluation data for network anomaly de-tection. Pages 220–237 of: Proceedings of the 6th international symposium onrecent advances in intrusion detection (raid 2003).

MAHONEY, MATTHEW V., & CHAN, PHILIP K. 2002b. Learning nonstationarymodels of normal network traffic for detecting novel attacks. Pages 376–385 of: Kdd ’02: Proceedings of the eighth acm sigkdd international conferenceon knowledge discovery and data mining. New York, NY, USA: ACM Press.

MAHONEY, M.V., & CHAN, P.K. 2001. Detecting novel attacks by identifyinganomalous network packet headers. Tech. rept. CS-2001-2. Florida Instituteof Technology.

MANNING, CHRISTOPHER D., & SCHÜTZE, HINRICH. 1999. Foundations ofstatistical natural language processing. The MIT Press.

MCHUGH, JOHN. 2000. Testing intrusion detection systems: a critique of the1998 and 1999 DARPA intrusion detection system evaluations as perfor-med by lincoln laboratory. Acm trans. on information and system security,3(4), 262–294.

MCHUGH, JOHN. 2001. Intrusion and intrusion detection. International journalof information security, 1(August), 14–35.

MCILRAITH, S. 1998. Logic-based abductive inference. http://citeseer.ist.psu.edu/mcilraith98logicbased.html.

ME, L. 1996 (May). Genetic algorithms, a biologically inspired approachfor security audit trails analysis. In: 1996 ieee symposium on security andprivacy. short paper.

MEIER, MICHAEL. 2004 (12). Intrusion detection systems list and bibliogra-phy. http://www-rnks.informatik.tu-cottbus.de/en/security/ids.html.

124

http://citeseer.ist.psu.edu/mcilraith98logicbased.html

http://citeseer.ist.psu.edu/mcilraith98logicbased.html

http://www-rnks.informatik.tu-cottbus.de/en/security/ids.html

http://www-rnks.informatik.tu-cottbus.de/en/security/ids.html

MICHAEL, C. C., & GHOSH, ANUP. 2002. Simple, state-based approaches toprogram-based anomaly detection. Acm trans. inf. syst. secur., 5(3), 203–237.

MILLS, DAVID L. 1992. Network time protocol (version 3). Tech. rept. Universityof Delaware.

MITCHELL, THOMAS M. 1997. Machine learning. McGraw-Hill HigherEducation.

MITNICK, KEVIN. 2002. The art of deception. Wiley.

MORIN, BENJAMIN, MÉ, LUDOVIC, DEBAR, HERVÉ, & DUCASSÉ, MIREILLE.2002. M2d2: A formal data model for ids alert correlation. Pages 115–127of: Raid.

NING, P., CUI, Y., FAND, D., & XU, D. 2004. Techniques and tools for analyzingintrusion alerts. http://citeseer.ist.psu.edu/ning04techniques.html.

OURSTON, DIRK, MATZNER, SARA, STUMP, WILLIAM, & HOPKINS, BRYAN.2003. Applications of hidden markov models to detecting multi-stagenetwork attacks. Page 334 of: Hicss.

PAL, S.K., & MITRA, P. 2004. Pattern recognition algorithms for data mining:Scalability, knowledge discovery, and soft granular computing. Boca Raton,FL: Chapman Hall/CRC Press.

PESTMAN, WIEBE R. 1998. Mathematical statistics: An introduction. Walter deGruyter.

PORRAS, P. A., & NEUMANN, P. G. 1997. EMERALD: Event monitoring ena-bling responses to anomalous live disturbances. Pages 353–365 of: Proc.20th NIST-NCSC nat’l information systems security conf.

PORRAS, PHILLIP A., FONG, MARTIN W., & VALDES, ALFONSO. 2002. Amission-impact-based approach to infosec alarm correlation. Lecture notesin computer science, 2516/2002(October), 35.

POTTER, BRUCE. 2006. The shmooo group capture the ctf project. http://cctf.shmoo.com.

PTACEK, THOMAS H., & NEWSHAM, TIMOTHY N. 1998. Insertion, evasion, anddenial of service: Eluding network intrusion detection. Tech. rept. T2R-0Y6.Secure Networks, Calgary, Canada.

PUKETZA, NICHOLAS, CHUNG, MANDY, OLSSON, RONALD A., & MUKHE-RJEE, BISWANATH. 1997. A software platform for testing intrusiondetection systems. Ieee software, 14(5), 43–51.

PUKETZA, NICHOLAS J., ZHANG, KUI, CHUNG, MANDY, MUKHERJEE, BI-SWANATH, & OLSSON, RONALD A. 1996. A methodology for testing in-trusion detection systems. IEEE transactions on software engineering, 22(10),719–729.

125

http://citeseer.ist.psu.edu/ning04techniques.html

http://citeseer.ist.psu.edu/ning04techniques.html

http://cctf.shmoo.com

http://cctf.shmoo.com

QIN, XINZHOU, & LEE, WENKE. 2003. Statistical causality analysis of infosecalert data. Pages 73–93 of: Raid.

RABINER, LAWRENCE R. 1990. A tutorial on hidden markov models and selectedapplications in speech recognition.

RAMADAS, M. 2003 (March). Detecting anomalous network traffic withself-organizing maps. M.Phil. thesis, Ohio University.

RAMADAS, M., OSTERMAN, S., & TJADEN, B. 2003. Detecting anomalous net-work traffic with self-organizing maps. Pages 36–54 of: VIGNA, GIOVAN-NI, KRUEGEL, CHRISTOPHER, & JONSSON, ERLAND (eds), Proceedings ofthe 6th international symposium on recent advances in intrusion detection (raid2003), vol. 2820. Pittsburgh, PA, USA: Springer-Verlag.

RANUM, MARCUS J. 2001. Experiences benchmarking intrusion detection systems.http://www.snort.org/docs/Benchmarking-IDS-NFR.pdf.

RASKIN, VICTOR, HEMPELMANN, CHRISTIAN F., TRIEZENBERG, KATRI-NA E., & NIRENBURG, SERGEI. 2001. Ontology in information security:a useful theoretical foundation and methodological tool. Pages 53–59 of:Nspw ’01: Proceedings of the 2001 workshop on new security paradigms. NewYork, NY, USA: ACM Press.

RHODES, B. C., MAHAFFEY, J. A., & CANNADY, J. D. 2000. Multiple self-organizing maps for intrusion detection. In: Proceedings of the 23rd nationalinformation systems security conference.

RITCHEY, RONALD W., & AMMANN, PAUL. 2000. Using model checking toanalyze network vulnerabilities. Page 156 of: Sp ’00: Proceedings of the2000 ieee symposium on security and privacy. Washington, DC, USA: IEEEComputer Society.

ROSSEY, L., CUNNINGHAM, R., FRED, D., RABEK, J., LIPPMANN, R., HAI-NES, J., & ZISSMAN, M. 2001. Lariat: Lincoln adaptable realtime informationassurance testbed. http://citeseer.ist.psu.edu/rossey01lariat.html.

ROSSEY, L., CUNNINGHAM, R., FRED, D., RABEK, J., LIPPMANN, R., HAI-NES, J., & ZISSMAN, M. 2001-2006. Lincoln laboratory computer securi-ty technology - mit-tlo. http://web.mit.edu/tlo/www/industry/comp_security_tech.html#lariat.

RUSSELL, STUART, & NORVIG, PETER. 2003. Artificial intelligence: A modernapproach. Prentice Hall.

RYAN, J., MENG-JANE, L., & MIIKKULAINEN, R. 1998a. Intrusion detectionwith neural networks. Mit Press. Chap. 8.

RYAN, JAKE, LIN, MENG-JANG, & MIIKKULAINEN, RISTO. 1998b. Intrusiondetection with neural networks. In: JORDAN, MICHAEL I., KEARNS,MICHAEL J., & SOLLA, SARA A. (eds), Advances in neural informationprocessing systems, vol. 10. The MIT Press.

126

http://www.snort.org/docs/Benchmarking-IDS-NFR.pdf

http://citeseer.ist.psu.edu/rossey01lariat.html

http://citeseer.ist.psu.edu/rossey01lariat.html

http://web.mit.edu/tlo/www/industry/comp_security_tech.html#lariat

http://web.mit.edu/tlo/www/industry/comp_security_tech.html#lariat

S., HETTICH, & D., BAY S. 1999. KDD Cup ’99 Dataset. http://kdd.ics.uci.edu/.

SANS INSTITUTE, INC. 2006. Sans top-20 internet security attack targets. http://files.sans.org/top20/top20_2006.pdf.

SEKAR, R., BENDRE, M., DHURJATI, D., & BOLLINENI, P. 2001. A fa-st automaton-based method for detecting anomalous program beha-viors. In: Proceedings of the 2001 ieee symposium on security and privacy.Washington, DC, USA: IEEE Computer Society.

SHORTLIFFE, EDWARD HANCE. 1976. Computer-based medical consultations:Mycin. Elsevier.

SNORT. 2006. http://www.snort.org.

SOBIREY, MICHAEL. 2000. Intrusion detection systems page. http://www.cse.sc.edu/research/isl/mirrorSobireys.shtml.

SOMMER, ROBIN, & PAXSON, VERN. 2003. Enhancing byte-level network in-trusion detection signatures with context. Pages 262–271 of: Ccs ’03: Pro-ceedings of the 10th acm conference on computer and communications security.New York, NY, USA: ACM Press.

SONG, DUG. 1998. Fragroute. http://www.monkey.org/~dugsong/fragroute/.

SPAFFORD, EUGENE H., & ZAMBONI, DIEGO. 2000. Intrusion detection usingautonomous agents. Computer networks, 34(4), 547–570.

STANIFORD-CHEN, S., CHEUNG, S., CRAWFORD, R., DILGER, M., FRANK,J., HOAGLAND, J., LEVITT, K., WEE, C., YIP, R., & ZERKLE, D. 1996.GrIDS – A graph-based intrusion detection system for large networks. In:Proceedings of the 19th national information systems security conference.

SYSTEMS, CISCO. 2006. Cisco security monitoring, analysis and response system.Tech. rept. Cisco Systems Inc.

TEMPLETON, STEVEN, & LEVITT, KARL. 2000. A requires/provides model forcomputer attacks. http://citeseer.ist.psu.edu/561559.html.

THEUS, M., & SCHONLAU, M. 1998. Intrusion detection based on structuralzeroes. Statistical computing & graphics newsletter, 9, 12–17.

THURMAN, WALTER N., & FISHER, MARK E. 1998. Chickens, eggs, andcausality, or which came first? American journal of agricultural economics.

VALDES, ALFONSO, & SKINNER, KEITH. 2000. An approach to alertcorrelation. http://www.raid-symposium.org/raid2000/Materials/Abstracts/41/corr_approach.pdf.

VALDES, ALFONSO, & SKINNER, KEITH. 2001. Probabilistic alert correlation.Lecture notes in computer science, 2212.

127

http://kdd.ics.uci.edu/

http://kdd.ics.uci.edu/

http://files.sans.org/top20/top20_2006.pdf

http://files.sans.org/top20/top20_2006.pdf

http://www.cse.sc.edu/research/isl/mirrorSobireys.shtml

http://www.cse.sc.edu/research/isl/mirrorSobireys.shtml

http://www.monkey.org/~dugsong/fragroute/

http://www.monkey.org/~dugsong/fragroute/


http://www.raid-symposium.org/raid2000/Materials/Abstracts/41/corr_approach.pdf

http://www.raid-symposium.org/raid2000/Materials/Abstracts/41/corr_approach.pdf

VALEUR, F., VIGNA, G., KRUEGEL, C., & KEMMERER, R. 2004. A comprehensi-ve approach to intrusion detection alert correlation. http://citeseer.ist.psu.edu/valeur04comprehensive.html.

VANDOORSELAERE, YOANN. 2005. Prelude-IDS. http://www.prelude-ids.org/.

VENEZIANO, DAVIDE. 2005. Un sistema di intrusion detection basato sugliargomenti delle chiamate di sistema. M.Phil. thesis, Politecnico di Milano.

VIGNA, G., ROBERTSON, W., & BALZAROTTI, D. 2004 (October). TestingNetwork-based Intrusion Detection Signatures Using Mutant Exploi-ts. Pages 21–30 of: Proceedings of the acm conference on computer andcommunication security (acm ccs).

VIGNA, GIOVANNI. 2004-05. The treasure hunt dataset. http://www.cs.ucsb.edu/~vigna/treasurehunt/index.html.

VIINIKKA, JOUNI, DEBAR, HERVÉ, MÉ;, LUDOVIC, & SÉGUIER, RENAUD.2006. Time series modeling for ids alert management. Pages 102–113 of:Asiaccs ’06: Proceedings of the 2006 acm symposium on information, computerand communications security. New York, NY, USA: ACM Press.

WAGNER, DAVID, & SOTO, PAOLO. 2002. Mimicry attacks on host-based in-trusion detection systems. Pages 255–264 of: Proceedings of the 9th acm con-ference on computer and communications security. New York, NY, USA: ACMPress.

WANG, KE, & STOLFO, SALVATORE J. 2004 (September). Anomalous payload-based network intrusion detection. In: Raid symposium.

WINKLER, W. 1999. The state of record linkage and current research problems.http://citeseer.ist.psu.edu/article/winkler99state.html.

YAMANISHI, K., TAKEUCHI, J.-I., WILLIAMS, G. J., & MILNE, P. 2004. Onli-ne unsupervised outlier detection using finite mixtures with discountinglearning algorithms. Knowledge discovery and data mining, 8(3), 275–300.

YAMANISHI, KENJI, ICHI TAKEUCHI, JUN, WILLIAMS, GRAHAM J., & MILNE,PETER. 2000 (Aug). On-line unsupervised outlier detection using finitemixtures with discounting learning algorithms. Pages 320–324 of: Proc. ofthe 6th acm SIGKDD int’l conf. on knowledge discovery and data mining.

YE, N., & CHEN, Q. 2001. An anomaly detection technique based on a chi-square statistic for detecting intrusions into information systems. Qualityand reliability engineering international, 17(2), 105–112.

YEUNG, DIT-YAN, & CHOW, CALVIN. 2002 (aug). Parzen-Window networkintrusion detectors. Pages 385–388 of: Proc. of the 16th int’l conf. on patternrecognition, vol. 4.

YURCIK, BILL. 2005. Security incident fusion tools. http://www.projects.ncassr.org/sift/.

128

http://citeseer.ist.psu.edu/valeur04comprehensive.html

http://citeseer.ist.psu.edu/valeur04comprehensive.html

http://www.prelude-ids.org/

http://www.prelude-ids.org/

http://www.cs.ucsb.edu/~vigna/treasurehunt/index.html

http://www.cs.ucsb.edu/~vigna/treasurehunt/index.html

http://citeseer.ist.psu.edu/article/winkler99state.html

http://www.projects.ncassr.org/sift/

http://www.projects.ncassr.org/sift/

ZANERO, S. 2005. Improving self organizing map performance for networkintrusion detection. In: Sdm 2005 workshop on “clustering high dimensionaldata and its applications”.

ZANERO, STEFANO, & SAVARESI, SERGIO M. 2004. Unsupervised learningtechniques for an intrusion detection system. Pages 412–419 of: Proc. of the2004 acm symposium on applied computing. ACM Press.

ZAZZETTA, MATTEO FEDERICO. 2005. Un sisetma di intrusion detection basatosu apprendimento non supervisionato. M.Phil. thesis, Politecnico di Milano.

ZISSMAN, MARC. 1999a. 1999 darpa intrusion detection evaluation sche-dule. http://www.ll.mit.edu/IST/ideval/docs/1999/detections_

1999.html.

ZISSMAN, MARC. 1999b. Darpa intrusion detection evaluation. http://www.ll.mit.edu/IST/ideval/data/dataindex.html.

ZISSMAN, MARC. 1999c. Darpa intrusion detection evaluation documentation.http://www.ll.mit.edu/IST/ideval/docs/docs_index.html.

ZISSMAN, MARC. 1999d. Ideval database of attacks. http://www.ll.mit.edu/IST/ideval/docs/1999/attackDB.html.

129

http://www.ll.mit.edu/IST/ideval/docs/1999/detections_1999.html

http://www.ll.mit.edu/IST/ideval/docs/1999/detections_1999.html

http://www.ll.mit.edu/IST/ideval/data/dataindex.html

http://www.ll.mit.edu/IST/ideval/data/dataindex.html

http://www.ll.mit.edu/IST/ideval/docs/docs_index.html

http://www.ll.mit.edu/IST/ideval/docs/1999/attackDB.html

http://www.ll.mit.edu/IST/ideval/docs/1999/attackDB.html

EFFICACIA ED INTEGRAZIONE DI SISTEMI DI...

Documents

Transcript of EFFICACIA ED INTEGRAZIONE DI SISTEMI DI...