UNIVERSITÀ DEGLI STUDI DI GENOVA

UNIVERSITÀ DEGLI STUDI DI GENOVA FACOLTÀ DI INGEGNERIA CORSO DI LAUREA SPECIALISTICA IN INGEGNERIA ELETTRONICA TESI DI LAUREA Sviluppo di tecniche di clustering e log correlation dedicate al trattamento intelligente dei dati per la difesa preventiva e reattiva di infrastrutture informatiche critiche Relatore: Chiar.mo Prof. Ing. Rodolfo ZUNINO Correlatore: Ing. Ermete MEDA Candidati: Vito IOVANE Edoardo TORREGGIANI Anno accademico 2009-2010 24 settembre 2010

Abstract Development of clustering and log-correlation techniques for intelligent data processing in order to preventively and reactively defend critical computer infrastuctures. This thesis concerns the automatic search for network attacks towards critical computer infrastructures (the network of a railway system). We focused on clustering log files, which are specific files automatically generated by network analyzers and which contain attack-related information. The files we worked on were in the Intrusion Detection Message Exchange Format (IDMEF), which is a network security format described by RFC 4765 and implemented in the extensible Markup Language (XML). In our work we added log-clustering IDMEF-focused capabilities to an already existing data mining environment (SLAIR) and we tested the performances of this module on publicly avaiable datasets. I

II Alla Commissione di Laurea e Diploma Alla Commissione Tirocini e Tesi Sottopongo la tesi redatta dagli studenti Vito Iovane e Edoardo Torreggiani dal titolo Sviluppo di tecniche di clustering e log correlation dedicate al trattamento intelligente dei dati per la difesa preventiva e reattiva di infrastrutture informatiche critiche. Ho esaminato, nella forma e nel contenuto, la versione finale di questo elaborato scritto, e propongo che la tesi sia valutata positivamente assegnando i corrispondenti crediti formativi. Il Relatore Accademico Prof. Rodolfo Zunino

Prefazione Questa tesi riguarda la ricerca automatica di attacchi informatici verso un infrastruttura di rete di un sistema critico (rete ferroviaria). Il nostro lavoro si è concentrato sulla suddivisione in cluster di file di log, ovvero particolari file in cui gli analizzatori di rete registrano il verificarsi e le caratteristiche di attacchi informatici. Abbiamo lavorato con file di tipo IDMEF (Intrusion Detection Message Exchange Format), il quale è uno standard nel settore della sicurezza delle reti descritto dalla RFC 4765 e definito in linguaggio XML (extensible Markup Language). Nell ambito della nostra tesi si sono aggiunte funzionalità di log clustering mirate al formato IDMEF ad un ambiente di data mining già esistente (SLAIR) e si sono verificate le prestazioni di questo modulo su dataset prelevati dalla rete. III

Ringraziamenti Vogliamo qui ringraziare tutti coloro che ci hanno assistito ed aiutato nel corso di tutti questi mesi di studio. In particolare ringraziamo il nostro relatore Prof. Rodolfo Zunino con il quale abbiamo ideato e sviluppato il nostro lavoro e che con la sua disponibilità ci ha permesso di superare tutti i problemi e le difficoltà incontrati in questo periodo. Ringraziamo anche gli Ingg. Fabio Sangiacomo e Alessio Leoncini per la loro pazienza nei nostri confronti e per le loro sempre utili delucidazioni che sono state di insegnamento e di supporto allo sviluppo del nostro lavoro. Infine un grazie va sicuramente a tutti i nostri amici e colleghi con i quali abbiamo condiviso gioie e dolori in questi cinque anni universitari, in particolare: Andrea, Francesco, Ilir, Luca, Lucio, Michele. Grazie ragazzi! Vito e Edoardo Grazie ai miei genitori per essermi stati vicino ed avermi aiutato in questi cinque anni: non è stato facile, ma anche grazie a loro sono passati più serenamente. Grazie a Edoardo: questi dieci mesi di lavoro sono stati lunghi, ma alla fine ce l abbiamo fatta! Grazie infine a tutti coloro che mi volevano bene che cinque anni fa c erano, e ora non ci sono più. Vito IV

V Un ringraziamento introduttivo va sicuramente alla mia famiglia che mi ha sostenuto per questi cinque anni di studi e mi ha aiutato a crescere insegnandomi i veri valori della vita: mamma, papà, sorella, nonno, zia, e tutti gli altri. Il pensiero va anche a tutti i miei amici più cari con cui ho passato questi anni e che mi hanno sempre voluto bene nonostante le mie assenze. Ringrazio Vito il mio collega e socio di tanti giochi e lavori prima scolastici e poi universitari, il quale pazientemente ha sopportato tutti i miei continui ritardi (scusa!). Infine il ringraziamento più grande è rivolto alla mia ragazza Virginia che con il suo amore, la sua gentilezza e la sua energia mi ha fatto vivere questi anni meravigliosi in un ambiente sereno e costruttivo. Ti ringrazio con tutto il cuore. Vi voglio bene! Edoardo

Indice Abstract I Prefazione III Ringraziamenti IV Indice VI Elenco delle figure IX 1 Introduzione 1 2 Sicurezza dei sistemi 4 2.1 Un attacco tradizionale................................ 5 2.2 Una tassonomia degli attacchi............................ 6 2.2.1 Attacchi Denial of Service (DoS)....................... 7 2.2.2 Probe (sorveglianza, scansione)....................... 7 2.2.3 Compromissioni................................ 9 2.2.4 Virus, worms, trojan............................. 10 2.3 Difesa in profondità.................................. 12 2.3.1 Controllo degli accessi............................ 12 2.3.2 Verifiche di vulnerabilità e applicazione di patch............. 13 2.3.3 Chiusura delle porte............................. 13 2.3.4 Firewall..................................... 14 VI

INDICE VII 2.3.5 Strumenti antivirus e antispyware..................... 14 2.3.6 Filtri antispam................................. 16 2.3.7 Honeypot.................................... 17 2.3.8 Controllo degli accessi alla rete....................... 17 2.3.9 Quarantena.................................. 17 2.4 Gli intrusion detection system (IDS) e gli intrusion prevention system (IPS).. 18 2.4.1 Tecniche degli IDPS per l individuazione di attacchi........... 20 2.4.2 Componenti di un IDPS........................... 22 2.4.3 Tipi di tecnologie IDPS............................ 23 2.4.4 Approcci per la realizzazione degli IDS.................. 24 3 Intrusion detection message exchange format (IDMEF) 29 3.1 Il modello dei dati IDMEF............................... 30 3.2 Il documento IDMEF-XML (Tipi di dato)...................... 32 3.3 Il modello dei dati IDMEF............................... 33 3.3.1 La classe IDMEF-Message.......................... 34 3.3.2 La classe Alert................................. 34 3.3.3 La classe Heartbeat.............................. 37 3.3.4 Le classi fondamentali............................ 38 3.3.5 Le classi Time, Assessment e le classi di supporto............. 42 4 Correlazione degli allarmi 44 4.1 Approcci alla correlazione degli allarmi....................... 45 4.1.1 Normalizzazione............................... 45 4.1.2 Aggregazione................................. 47 4.1.3 Correlazione.................................. 48 4.1.4 Riduzione dei falsi allarmi.......................... 49 4.1.5 Analisi della strategia di attacco....................... 50 4.1.6 Assegnamento delle priorità......................... 50 4.2 Clustering di documenti................................ 51

INDICE VIII 4.2.1 Clustering basato sul kernel k-means.................... 52 5 Il modulo IDMEF per l ambiente SLAIR 54 5.1 L ambiente text mining: SLAIR............................ 54 5.1.1 La struttura.................................. 55 5.1.2 Funzionamento................................ 56 5.2 Il Modulo IDMEF.................................... 58 5.2.1 Il caricamento dei file............................. 59 5.2.2 Il gestore dei file................................ 60 5.2.3 La metrica................................... 61 5.2.4 Il clustering.................................. 62 6 Risultati 64 6.1 Verifica del funzionamento del modulo....................... 64 6.2 La suddivisione in cluster............................... 67 6.3 Tempi di calcolo.................................... 75 7 Conclusioni e sviluppi futuri 76 7.1 Strumenti utilizzati................................... 76 7.2 Sviluppi futuri..................................... 77 A Il DTD IDMEF 82 Bibliografia 93

Elenco delle figure 2.1 Schema di un attacco SYN flood.............................. 8 2.2 Schema di un attacco DDoS................................. 8 2.3 Risultato di una scansione tramite Nmap......................... 9 2.4 Confronto tra i tipi di programmi pericolosi più diffusi................. 10 2.5 Nuove firme scoperte tra il 2002 ed il 2009........................ 15 2.6 Settori maggiormente colpiti dal phishing........................ 16 2.7 Rete protetta da un IDS e da alcuni firewall....................... 18 2.8 Alcuni approcci per la realizzazione di IDS........................ 24 3.1 Diagramma UML delle principali classi del modello IDMEF.............. 34 3.2 Diagramma UML che illustra le classi che compongono un messaggio Alert.... 36 3.3 Diagramma UML che illustra le classi che compongono un messaggio Heartbeat.. 38 4.1 Fasi di cui si compone la correlazione degli allarmi................... 46 5.1 L avvio dell ambiente SLAIR................................ 58 5.2 Le possibilità di clustering proposte da SLAIR...................... 58 6.1 Il dump del primo file IDMEF caricato........................... 66 IX

Capitolo 1 Introduzione In questi anni si è assistito ad una sempre maggiore espansione degli strumenti di comunicazione digitale, in particolare delle comunicazioni via rete pubblica (Internet) e delle comunicazioni via reti private (gestione/monitoraggio telematico di infrastrutture, reti aziendali...). Attualmente i computer e le workstation sono presenti in quasi tutti gli uffici e le case, Internet è sempre più diffuso e sempre più sono le transazioni e le attività commerciali che sono basate sul Web. Grazie ad una così estesa diffusione delle reti, l utente di un sistema informatico può essere praticamente chiunque nel mondo. Questo sviluppo ha condotto ad un ambiente su cui nessuno, né l amministratore di rete, né il singolo utente ha il controllo: per questo si rendono necessari sistemi che forniscano protezione dal punto di vista tecnico, procedurale, operativo ed ambientale contro il maggior numero possibile di minacce, come attacchi sferrati da singoli utenti o da intere organizzazioni nazionali od internazionali. Vari sono i motivi che spingono a violare un sistema informatico: la soddisfazione intellettuale personale, la ricerca di un vantaggio economico, la vendetta, la disobbedienza civile od altre ragioni. I controlli di sicurezza devono essere in grado di gestire circostanze in cui non esiste alcuna forma di controllo, poiché il bacino di utenti dal quale un attacco può essere generato si è ingrandito inglobando utenti di tutto il mondo. La sicurezza informatica può essere paragonata ad una assicurazione: in entrambi i casi si deve affrontare un ambiente pieno di pericoli, conosciuto solo superficialmente e che può ge- 1

CAPITOLO 1. INTRODUZIONE 2 nerare molti attacchi; gli esatti dettagli ed il momento preciso in cui l attacco avviene però non possono essere noti se non dopo che si è verificato. Essendo il mondo moderno basato su flussi di informazioni, la nostra società e le istituzioni non possono funzionare senza sistemi informativi basati sui calcolatori: questi sistemi devono perciò essere protetti sotto ogni punto di vista, ed il possessore del sistema nonché il suo staff diventano responsabili della protezione delle informazioni custodite. Il progresso nella sicurezza informatica è stato lento, essenzialmente a causa di una errata percezione della reale pericolosità delle minacce, ma anche perché il costo della sicurezza di un sistema informatico spesso è apparso troppo elevato rispetto ai rischi che si corrono in mancanza di una protezione adeguata, ed in particolare rispetto alle conseguenze economiche. Negli ultimi anni sono stati sviluppati diversi strumenti con lo scopo di proteggere le reti ed i sistemi dagli attacchi e dalle minacce: strumenti per la protezione dei singoli host, quali antivirus, personal firewall, filtri antispam; strumenti per la protezione di reti come i firewall hardware, gli intrusion detection system, IPSec. Questi strumenti offrono diversi servizi legati alla sicurezza, da quelli che proteggono dai singoli attacchi ai servizi di analisi del traffico. In quest ultimo caso è necessario che tali servizi producano dei resoconti che descrivano lo stato e le minacce rilevate sulle reti analizzate in modo che gli amministratori di rete possano più agevolmente individuare i punti critici dell infrastruttura e porvi rimedio se possibile. Per agevolare la comunicazione tra gli strumenti di sicurezza e fornire ulteriori servizi ai gestori di rete, l IDWG (Intrusion Detection Working Group) ha introdotto un formato standard, IDMEF (Intrusion Detection Message Exchange Format) nel quale vengono registrate informazioni relative agli attacchi subiti e allo stato della rete. A questo punto sorge il problema di come gestire i file IDMEF prodotti dagli analizzatori: l amministratore di rete si può trovare di fronte ad una quantità enorme di informazioni e file, i quali non solo possono non essere di facile interpretazione, ma se presi singolarmente difficilmente chiariscono la reale situazione della rete. A partire da questo problema, si rendono necessari dei tool che effettuino una correlazione tra i dati, ovvero li presentino all amministratore in modo più compatto e di più facile interpretazione. Il nostro lavoro si inserisce in questo ambito e si pone l obiettivo di sviluppare un modulo che effettui clustering su allarmi

CAPITOLO 1. INTRODUZIONE 3 di tipo IDMEF in modo tale da riassumere in un unico resoconto le informazioni in input ed evidenziare ulteriori pericoli o situazioni critiche che i singoli allarmi non possono mettere in luce. Tra gli approcci che si possono seguire nello sviluppare un tool di questo genere, per il lavoro di questa tesi se ne è scelto uno che si basa su tecniche tipiche del data mining. Il nostro modulo va ad inserirsi in un ambiente di text mining già esistente, il quale è stato sviluppato presso il laboratorio SEA Lab (Smart Embedded Application Laboratory) dell Università di Genova. Tale ambiente si chiama SLAIR (SEA Lab Advanced Information Retrieval): lavora specialmente su file di tipo testuale e a partire da essi produce alberi ordinati divisi per argomento. Gli algoritmi che costituiscono il cuore di questo ambiente sono quelli relativi a tecniche di clustering e più in generale di machine learning. Noi ci siamo dedicati ad ampliare il suddetto ambiente con una nuova funzionalità che permette di clusterizzare file IDMEF: dopo una prima fase iniziale volta a prendere confidenza con questo ambiente, si è realizzata una nuova metrica che descrive questi particolari file e costituisce il nucleo del nostro modulo. La presente tesi illustra il lavoro di ricerca svolto ed è organizzata come segue: nel capitolo 2 sono presentate alcune minacce comuni verso le reti ed i sistemi informatici, insieme a strumenti sviluppati per contrastare tali pericoli; nel capitolo 3 è descritto il formato IDMEF, illustrandone le caratteristiche principali; il capitolo 4 offre una panoramica delle tecniche di correlazione degli allarmi più diffuse, tra le quali viene dato un certo spazio al metodo di clustering impiegato in SLAIR ed è presentato l algoritmo del kernel k-means; nel capitolo 5 sono presentate con maggiore dettaglio le varie fasi della realizzazione del modulo per il clustering degli allarmi IDMEF aggiunto all ambiente SLAIR; nel capitolo 6 sono illustrati i risultati ottenuti al termine del nostro lavoro, mentre il capitolo 7 offre dei possibili spunti per futuri sviluppi od ampliamenti del modulo realizzato.

Capitolo 2 Sicurezza dei sistemi La presenza sempre maggiore di computer collegati ad Internet, per poter usufruire o offrire servizi diventati ormai essenziali, quali la posta elettronica, l accesso remoto, il VoIP, espone gli utenti ad una vasta gamma di rischi: l intrusione di malintenzionati (hacker, cracker, ecc...) può avere come effetto l eliminazione di file di sistema o di dati importanti, l introduzione di virus, la sottrazione di informazioni confidenziali o di segreti industriali, la manipolazione di informazioni aziendali, solo per citare qualche esempio. Le minacce possono arrivare anche dall interno della rete: se un utente scarica in buona fede un file infettato da un virus, questo si può rapidamente diffondere all intera rete, con effetti potenzialmente molto pericolosi. Si è pertanto reso necessario l impiego di dispositivi che, da soli o usati in maniera combinata, forniscano protezione ai sistemi contro la maggior parte delle minacce possibili, giacché contro la totalità sarebbe impossibile. Accanto a strumenti che bloccano gli accessi alla rete sulla base di alcune regole, come i firewall, si possono predisporre altri sistemi (intrusion detection system, liste di controllo degli accessi sui router, sistemi antivirus e antivirus sui computer host), ognuno dei quali costituisce un livello dell intero sistema di sicurezza: in questo modo se anche un livello è compromesso, non lo è la sicurezza del sistema nel suo complesso, e questo può servire da deterrente contro gli attacchi. 4

CAPITOLO 2. SICUREZZA DEI SISTEMI 5 2.1 Un attacco tradizionale Analogamente a quanto avviene per un attacco fisico, anche gli attacchi informatici tipicamente si svolgono secondo le seguenti fasi: conoscenza dell obiettivo, compromissione dell obiettivo, mantenimento del controllo senza farsi scoprire [8]. La prima fase ha lo scopo di acquisire quante più informazioni possibili sull obiettivo, soprattutto le sue debolezze, che faciliteranno l attacco. Attraverso ping e traceroute si può realizzare una mappa della rete dell obiettivo (o dell area intorno ad esso) comprensiva degli indirizzi IP (Internet Protocol), mentre effettuare una scansione delle porte (port scan) rivela quali sono aperte e può anche suggerire se e quali attacchi sono stati portati in passato. Una miglior conoscenza del target si può ottenere attraverso strumenti che individuano il sistema operativo in uso, come Nmap scanner 1, o che cercano vulnerabilità note, come SAINT, SARA, SATAN e Nessus 2. Nella seconda fase di un attacco diretto si cerca di compromettere l obiettivo. Un attacco sulle password è comune, perché spesso esse sono parole comuni, facilmente individuabili tramite un attacco a dizionario, o perché, se si entra in possesso del file delle password, si può risalire ad esse tramite un attacco a forza bruta. Un altro attacco comune è quello che ricorre alle vulnerabilità tramite gli exploit, porzioni di codice che sfruttano proprio queste vulnerabilità per portare gli attacchi: esse sono pubblicate periodicamente e valutate con un particolare punteggio da organizzazioni come CERT e MITRE 3, e per numerose vulnerabilità è disponibile pubblicamente anche il codice di exploit; rientrano in questa categoria attacchi come i buffer overflow e le SQL injection (soprattutto per i Web server). Per quanto comuni, gli exploit non sono l unico modo per portare un attacco: si può ricorrere a pratiche di ingegneria sociale (social engineering), in cui si inganna il target, ad esempio tramite phishing (per il furto di identità 1 Network mapper scanner: http://nmap.org/ 2 Security Administrator s Integrated Network Tool (SAINT): http://www.saintcorporation. com/ Security Auditor s Research Assistant (SARA): http://www-arc.com/sara/ Security Administrator Tool for Analyzing Networks (SATAN): http://www.porcupine.org/satan/ Nessus: http://www.nessus.org/nessus/ 3 Computer Emergency Response Team (CERT): http://www.cert.org/ MITRE: http://www.mitre.org/

CAPITOLO 2. SICUREZZA DEI SISTEMI 6 o di altri dati importanti) o tramite messaggi di spam che recano un allegato pericoloso. La terza fase dell attacco consiste nel coprire le tracce dell attacco portato (ad esempio manipolando opportunamente i registri di sistema del target) e nel mantenere il controllo del sistema senza essere scoperti (grazie a malware, come backdoor, trojan per il controllo remoto, rootkit e bot). Esistono varie tecniche per poter comunicare con il target compromesso senza essere individuati dai sistemi predisposti, ovvero gli intrusion detection system (IDS): il tunneling, ovvero l incapsulamento dei pacchetti di un protocollo nei payload di un altro pacchetto; la cifratura, in cui la chiave per cifrare i messaggi è conosciuta solo dall intrusore e dal target; la frammentazione dei pacchetti IP, che confonde l IDS soprattutto se effettuata in grande quantità. Tuttavia, grazie anche a IDS sempre più efficaci, sembra che questi attacchi diretti stiano divenendo meno diffusi e siano rimpiazzati da attacchi basati sul Web, meno rumorosi e perciò più difficili da individuare: attacchi di questo genere sono il già citato phishing e il drive by download, nel quale al visitatore di un sito all apparenza normale, ma molto spesso compromesso, è proposto di scaricare del malware, spesso camuffato e spacciato come software non pericoloso per non insospettire l utente. 2.2 Una tassonomia degli attacchi Ormai da molti anni si cerca di creare una tassonomia degli attacchi informatici: ai primi tentativi degli anni Settanta (ad esempio [2]) sono seguite molte altre proposte, sempre più complesse per via del sempre maggior numero di attacchi scoperti. Sebbene una tassonomia completa e definitiva non sarà probabilmente realizzabile, uno studio piuttosto recente [25] ha cercato di crearne una piuttosto generale, basandosi anche su analoghi lavori del passato. La classificazione degli attacchi in base al tipo è una delle strade più comuni. Si possono individuare i seguenti tipi: attacchi Denial of Service (DoS); probe; compromissioni; virus, worms, trojan.

CAPITOLO 2. SICUREZZA DEI SISTEMI 7 2.2.1 Attacchi Denial of Service (DoS) Questo tipo di attacchi (la cui traduzione letterale è negazione del servizio ) tentano di spegnere un computer o interrompere una rete o un servizio, o altrimenti tentano di negare l accesso di risorse e servizi agli utenti autorizzati. Esistono due tipi di attacchi DoS: gli attacchi ai sistemi operativi, che sfruttano vulnerabilità presenti nei sistemi operativi (spesso eliminabili tramite l applicazione di patch v. sezione 2.3.2), e gli attacchi alla rete, che sfruttano limitazioni presenti nei protocolli e nelle infrastrutture di rete. Un esempio per il primo caso è teardrop, che sfrutta una vulnerabilità del codice di riassemblamento dei frammenti TCP/IP che non gestisce correttamente la sovrapposizione di frammenti IP. Per gli attacchi alla rete, si può portare l esempio dell attacco SYN flood (fig. 2.1), che usa l handshake a tre vie per stabilire una connessione: usando l IP spoofing, l intrusore crea molte connessioni half-open, per le quali invia dei pacchetti SYN (con l indirizzo IP falso) alla vittima; questa memorizza la richiesta di apertura della connessione in una struttura dati e risponde con un pacchetto SYN/ACK, che però non arriva a destinazione (perché l indirizzo IP è falso o perché l intrusore rifiuta questro pacchetto), pertanto la vittima non può ricevere il pacchetto ACK. Anche se la struttura dati viene periodicamente ripulita da voci come questa, il malintenzionato cerca di crearne a sufficienza da produrre un segmentation fault o un blocco della macchina. Una variante del DoS è il DoS distribuito (DDoS, fig. 2.2), nel quale più computer cercano di ottenere lo stesso obiettivo perseguito dal DoS. Per contrastare questi attacchi sono state studiate diverse soluzioni, essenzialmente: meccanismi di individuazione e riconoscimento di attività di DoS in corso e meccanismi di risposta per mitigare gli effetti di un DoS (come l identificazione dell origine dell attacco attraverso tecniche di tracciamento a ritroso). 2.2.2 Probe (sorveglianza, scansione) In questi attacchi gli indirizzi IP di una rete sono soggetti ad una scansione mirata a raccogliere informazioni su di essi, quali i servizi offerti ed il sistema operativo in uso. In questo modo, il malintenzionato può risalire alle vulnerabilità note e sfruttarle per portare un attacco.

CAPITOLO 2. SICUREZZA DEI SISTEMI 8 Figura 2.1. Schema di un attacco SYN flood (fonte: [10]). Figura 2.2. Schema di un attacco DDoS (fonte: [29]). Esempi di probe sono IPsweep (in cui si effettua la scansione per cercare un servizio su una porta in particolare), portsweep (scansione di molte porte per cercare i servizi offerti da un

CAPITOLO 2. SICUREZZA DEI SISTEMI 9 certo host), Nmap (uno strumento per determinare la mappa di una rete, fig. 2.3). Figura 2.3. Risultato di una scansione tramite Nmap. Contro questi attacchi esistono metodi semplici, che cercano quegli indirizzi IP che effettuano più di un certo numero di connessioni in un intervallo di tempo definito; questi metodi, però, non funzionano con attacchi più sofisticati e silenziosi, in cui la frequenza delle connessioni è più ridotta, e contro i quali esistono alcune tecniche basate sulla raccolta di statistiche. 2.2.3 Compromissioni In questi attacchi si sfruttano vulnerabilità come i buffer overflow e punti deboli del sistema per ottenere un accesso privilegiato all host. A seconda che l attacco sia portato dall interno o dall esterno del sistema, si parla di: attacchi R2L (Remote to Local), in cui l intrusore invia pacchetti alla vittima attraverso una rete, spesso Internet, e riesce a guadagnare l accesso alla macchina. Esempi di questa categoria sono gli attacchi a dizionario, i guest attacck e i phf attack; attacchi U2R (User to Root), in cui si sfrutta un baco o una vulnerabilità del sistema operativo o di un programma installato per aumentare i privilegi di un dato account di

CAPITOLO 2. SICUREZZA DEI SISTEMI 10 una macchina (che può arrivare ad avere i privilegi di root). In questo caso la minaccia, che arriva direttamente dall interno, spesso consiste negli attacchi buffer overflow, che cercano di danneggiare dati memorizzati in certe porzioni di memoria (buffer) andando a sovrascriverle di proposito e ottenendo così all utente i privilegi di amministratore. Gli attacchi buffer overflow possono anche rintrare nella categoria degli R2L. 2.2.4 Virus, worms, trojan Si tratta di programmi che si replicano sugli host e si diffondono attraverso la rete. Sebbene questi programmi abbiano caratteristiche diverse fra loro, non sempre si riesce ad identificare una minaccia con uno solo di essi: ad esempio, Love Bug è allo stesso tempo un trojan, perché finge di essere una lettera d amore ma è un programma pericoloso; è un virus, perché infetta tutte le immagini presenti sul computer vittima rendendole a loro volta trojan; ed è un worm, perché si propaga attraverso Internet nascondendosi nei trojan che spedisce usando la rubrica della posta elettronica, IRC, ecc... Figura 2.4. Confronto tra i tipi di programmi pericolosi più diffusi (fonte: [11]).

CAPITOLO 2. SICUREZZA DEI SISTEMI 11 Virus I virus sono programmi che si riproducono attaccando (infettando) altri programmi. Possono creare danni di lievi, come la comparsa di semplici scritte sul monitor, o gravi, come la cancellazione di interi settori del disco rigido (virus Michelangelo), ma richiedono l interazione umana per attivarsi e diffondersi. Un virus ha diverse caratteristiche e non è facile dividerli per categorie; alcuni tentativi sono comunque stati fatti, tra cui quello in [23], che tiene in considerazione l ambiente, il sistema operativo, i diversi algoritmi impiegati e le capacità distruttive. Worms I worms sono programmi che si auto-replicano e diffondono attraverso una rete, sfruttando le funzionalità di invio e ricezione automatica dei pacchetti. Si possono suddividere in alcune categorie: worms tradizionali, che usano connessioni di rete per diffondersi senza richiedere l intervento umano; worms della posta elettronica (e di altre applicazioni client), come Melissa, che infettano gli host sulla rete (Internet) attraverso la posta elettronica o altre applicazioni client; worms della condivisione file di Windows, come ExploreZip, che si auto-replicano utilizzando il servizio peer-to-peer di Microsoft Windows, che si attiva ogni volta che un nuovo dispositivo di rete è individuato. Questo worm spesso si accompagna ad altri attacchi, come virus; worm ibridi, come Nimda, che sfruttano diverse vulnerabilità che rientrano nelle categorie appena esposte. Nimda, ad esempio, per diffondersi utilizza la posta elettronica, i dispositivi di archiviazione condivisi in rete, la scansione di backdoor aperte da altri worm.

CAPITOLO 2. SICUREZZA DEI SISTEMI 12 I worm possono essere utilizzati per lanciare attacchi DoS (li0n è stato usato per attacchi DDoS e Code Red per attacchi TCP SYN), e per il futuro questi attacchi potrebbero essere sempre più di frequente parte del payload dei worm. Trojan I trojan (dall inglese Trojan horse, cavallo di Troia ) sono programmi pericolosi che si camuffano da programmi innocui. Per esempio, possono sembrare giochi gratuiti che, quando eseguiti, cancellano interamente il disco fisso. Di solito le vittime scaricano i trojan (come Silk Rope e Saran Wrap) da siti Internet o tramite programmi di file sharing o instant messaging. 2.3 Difesa in profondità Sebbene una difesa totale dagli attacchi non sia ottenibile, i dati più importanti possono comunque essere protetti adottando la strategia della difesa in profondità: tra i dati ed il possibile malintenzionato si interpongono vari livelli di difesa che, pur essendo singolarmente abbattibili, se posti in serie possono scoraggiare l intrusore, a causa del tempo e delle risorse necessari per superarli tutti. Per ogni livello di difesa si possono usare varie tecnologie: firewall, IDS, router con lista di controllo degli accessi (o ACL, Access Control List), antivirus, controllo degli accessi, filtri antispam. Le attività volte a mantenere la sicurezza si possono dividere in due categorie: quelle preventive, che includono la valutazione delle vulnerabilità, l applicazione di patch, l irrobustimento dei sistemi (chiusura di porte non necessarie) ed il controllo degli accessi, e quelle reattive, che dovrebbero individuare le attività pericolose, bloccare gli attacchi, isolare le risorse più importanti e tracciare gli intrusori. 2.3.1 Controllo degli accessi Il controllo degli accessi consiste in una serie di meccanismi che consentono agli utenti di eseguire azioni fino ai livelli per i quali sono autorizzati, mentre vietano loro quelle per le

CAPITOLO 2. SICUREZZA DEI SISTEMI 13 quali non hanno autorizzazione. Tra questi meccanismi vi sono: l autenticazione degli utenti, ovvero la verifica della loro identità tramite qualcosa che l utente sa (password, PIN), che ha (token), qualcosa che è (identificatori biometrici); l autorizzazione dei loro privilegi, ovvero stabilire quali azioni un utente autenticato può eseguire (lettura, scrittura, esecuzione di file); l auditing e la registrazione delle azioni degli utenti. 2.3.2 Verifiche di vulnerabilità e applicazione di patch Le vulnerabilià, ovvero debolezze nel software sfruttando le quali si può portare un attacco, interessano tutti i tipi di sistemi operativi e applicazioni; quando una vulnerabilità è pubblicata (tipicamente dal produttore del software), spesso è accompagnata da una patch, cioè una correzione che deve essere applicata al software in modo da eliminare quella vulnerabilità. Sebbene la pubblicazione delle vulnerabilità possa avvantaggiare i malintenzionati, d altro canto essa consente agli amministratori di sistema di prendere le dovute precauzioni: attraverso una verifica delle vulnerabilità condotta sulla rete del proprio sistema, un amministratore può conoscere le configurazioni dei computer presenti, individuare vulnerabilità presenti e correggerle se esiste una patch apposita. 2.3.3 Chiusura delle porte Le applicazioni comunicano a livello di trasporto (usando i protocolli TCP e UDP) attraverso i numeri di porta: i numeri da 1 a 1023 sono usati per servizi stabiliti dalla Internet Assigned Numbers Authority (IANA), quelli da 1024 a 49151 sono usati da varie applicazioni utente, mentre i numeri da 49152 a 65535 sono usati dinamicamente dalle applicazioni. Una buona pratica consiste nel chiudere le porte non necessarie, specialmente quelle con i numeri più alti, anche se un intrusore può riuscire ad infiltrarsi attraverso le porte che devono necessariamente rimanere aperte.

CAPITOLO 2. SICUREZZA DEI SISTEMI 14 2.3.4 Firewall Un firewall è uno strumento che protegge una rete da minacce esterne, attraverso un opportuno filtraggio del traffico in ingresso e in uscita. I firewall possono essere dispositivi indipendenti, posti all ingresso di una rete per proteggerla, o software installati su PC, che dunque proteggono solo quell host. Sebbene esistano vari tipi di firewall (a filtraggio di pacchetti, proxy e stateful firewall), per essere efficaci tutti richiedono un buon insieme di regole, scritte correttamente. I firewall a filtraggio di pacchetti (packet-filtering firewall) analizzano i pacchetti in entrata e in uscita e decidono se lasciar passare o bloccare i pacchetti in base alle regole fornite, che di solito controllano le porte, i protocolli, gli indirizzi IP ed altri attributi degli header dei pacchetti. Questi firewall sono stateless, ovvero non tengono traccia dei pacchetti analizzati. Gli stateful firewall riescono a riconoscere i pacchetti che appartengono ad uno stesso flusso di traffico e a tener traccia dello stato di una connessione, lavorando al livello di rete. I proxy firewall possono lavorare fino al livello di applicazione, poiché sono in grado di riconoscere certe applicazioni e di capire se un protocollo non desiderato sta usando una porta non standard o se si sta abusando di un protocollo di livello applicazione. Funzionano come gateway primari da una rete interna verso Internet, proteggendo così la rete stessa. I firewall sono dispositivi estremamente importanti per la protezione di una rete, ma ne proteggono solo il perimetro: per questo non sono efficaci se l attacco riesce a superare il perimetro o se arriva dall interno della rete stessa. 2.3.5 Strumenti antivirus e antispyware A causa della grande espansione del malware, si sono resi necessari strumenti antivirus in grado di indentificare le minacce, rimuoverle e proteggere l host da nuove future infezioni. L individuazione può avvenire attraverso vari modi, tra i quali il più semplice consiste nella scansione dei file: si confrontano i bytes del file con delle firme (signatures) conosciute, appartenenti a malware conosciuto. Questa tecnica richiede però di aggiornare costantemente il database delle firme, in modo che si possano riconoscere le ultime minacce conosciute, ma

CAPITOLO 2. SICUREZZA DEI SISTEMI 15 contro le più recenti si potrebbe comunque non essere protetti (per avere un idea di quante nuove minacce sono annualmente scoperte, si possono consultare idati riportati in figura 2.5). Figura 2.5. Nuove firme di minacce scoperte tra il 2002 ed il 2009 (fonte: [11]). Un altro approccio individua il malware in base al suo comportamento: tutto ciò che compie azioni pericolose diventa sospetto e potenzialmente malware. Questo approccio supera gli svantaggi delle firme perché permette di trovare minacce anche molto recenti; tuttavia, può essere complicato descrivere cosa è sospetto e, ancor più, cosa è pericoloso: per questo si sviluppano delle regole euristiche per riconoscere i sospettati, mentre i casi pericolosi si scoprono con analisi più approfondite. I sistemi antispyware sono una categoria di antivirus specializzati. Lo spyware può effettuare numerose modifiche pericolose nei file di sistema e, più in generale, in tutto il disco fisso. Tipicamente i sistemi infettati hanno parecchi spyware, a volte anche in certi cookies.

CAPITOLO 2. SICUREZZA DEI SISTEMI 16 2.3.6 Filtri antispam I messaggi di spam sono e-mail non richieste, spedite in grandi quantità e di natura prevalentemente commerciale. Costituiscono un problema poiché una piccola minoranza dei destinatari risponde a questi messaggi, rendendo lo spam lucroso a chi lo pratica. Oltre ad essere fastidioso per gli utenti ed a sprecare risorse di rete, lo spam è anche un ottimo veicolo per diffondere malware o per portare attacchi di phishing. Il filtraggio dello spam può avvenire a livello dell impresa, se tutti i messaggi di posta diretti all interno dell organizzazione sono controllati dal filtro che elimina quelli ritenuti pericolosi (spesso usando tecniche bayesiane), o a livello personale, agendo direttamente sull host, dove si possono ulteriormente affinare le regole con cui individuare i messaggi indesiderati. Figura 2.6. Settori maggiormente colpiti dal phishing, per volume di URL (fonte: [11]).

CAPITOLO 2. SICUREZZA DEI SISTEMI 17 2.3.7 Honeypot Un honeypot (letteralmente barattolo del miele ) serve a conoscere le tecniche di attacco di un malintenzionato verso un host apparentemente vulnerabile. È considerato uno strumento forense piuttosto che di difesa, e per questo non può essere utilizzato per servizi o traffico regolari. Deve inoltre essere in grado di monitorare e registrare ciò che avviene e deve essere isolato dalla vera rete, onde evitare che gli intrusori possano usare l honeypot per colpirla. Gli honeypot classici sono strumenti passivi, che attendono i malintenzionati; sono però stati sviluppati degli honeypot attivi, chiamati honey monkey o client honeypot, con lo scopo di cercare server pericolosi ed interagire con essi. 2.3.8 Controllo degli accessi alla rete Un host compromesso non rappresenta un pericolo solo per sé, ma per l intera rete alla quale appartiene, poiché può essere usato come punto d accesso ad essa o per ottenere informazioni sulla rete. Il controllo degli accessi alla rete (NAC, Network Access Control) blocca ad un host l accesso alla rete se questo non dimostra di essere dotato di una buona protezione: sono tipicamente controllati il suo indirizzo IP, il sistema operativo, il software antivirus ed il personal firewall in uso. Le informazioni sulla sicurezza dell host sono quindi inviate ad un server delle politiche che le confronta con le politiche di sicurezza e decide se ammettere l host alla rete, eventualmente parzialmente, o se allontanarlo, anche solo temporaneamente, ad esempio a causa di un software antivirus non aggiornato o di un sistema operativo che richiede l applicazione di una o più patch. 2.3.9 Quarantena Quando si è individuato un attacco, una possibile risposta è la quarantena, cioè impedire che l host colpito possa colpire altri host sani, come avviene per la quarantena dei malati umani. Questo può essere effettuato impiegando dei firewall o dei router con liste di controllo degli accessi (simili alle regole di un firewall), che bloccano certi pacchetti allo scopo di isolare gli host infettati.

CAPITOLO 2. SICUREZZA DEI SISTEMI 18 2.4 Gli intrusion detection system (IDS) e gli intrusion prevention system (IPS) Il termine individuazione delle intrusioni indica l operazione di monitoraggio degli eventi che avvengono in un sistema informatico o in una rete di calcolatori, seguita dalla successiva analisi di tali eventi in cerca di indizi di possibili incidenti, cioè violazioni o minacce di violazione di politiche di sicurezza, politiche di utilizzo o pratiche di sicurezza standard [36]. L individuazione delle intrusioni può essere automatizzata facendo uso di un software chiamato intrusion detection system (IDS), o di un intrusion prevention system (IPS), ovvero un IDS in grado anche di bloccare possibili incidenti (fig. 2.7). Poiché tipicamente le funzionalità di Figura 2.7. Un intrusion detection system (IDS) e dei firewall impiegati per la protezione di una rete. prevenzione di un IPS possono essere disabilitate, IPS e IDS offrono funzionalità molto simili, e nel seguito saranno indicati con il termine più generico intrusion detection and prevention system (IDPS).

CAPITOLO 2. SICUREZZA DEI SISTEMI 19 Scopo principale degli IDPS è di invidiuare possibili incidenti, come la violazione di un sistema da parte di un malintenzionato sfruttando una vulnerabilità del sistema stesso. Informazioni sugli eventi individuati sono registrate ed inviate agli amministratori del sistema che cercheranno di minimizzare il danno. Un altra possibilità è usare un IDPS per individuare violazioni di politiche di sicurezza (per esempio l uso di programmi di file sharing), oppure per scoprire attacchi imminenti o sistemi che attirano l attenzione di malintenzionati (attraverso attività di ricognizione ). Un IDPS può anche essere usato per ottenere statistiche sugli attacchi, in modo da proteggere meglio i sistemi più esposti. A differenza di un IDS, un IPS può tentare di prevenire un attacco usando diverse tecniche, che possono essere divise nei segenti gruppi: l IPS stesso blocca l attacco, ad esempio terminando la connessione di rete o impedendo l accesso all obiettivo (target) da parte del malintenzionato tramite blocco del suo account o del suo indirizzo IP; l IPS modifica l ambiente di sicurezza, ad esempio riconfigura il firewall di rete per bloccare l accesso al malintenzionato o verso l obiettivo, oppure riconfigura il firewall sull host obiettivo per bloccare gli attacchi; l IPS modifica il contenuto dell attacco, ovvero ne modifica alcune porzioni maligne rendendole innocue, per esempio rimuovendo un file infetto da un messaggio di posta elettronica, ma lasciando proseguire il messaggio senza allegato; oppure l IPS può funzionare da proxy e normalizzare le richieste in ingresso, rimuovendo le informazioni dell header, operazione che blocca alcuni attacchi. Al fine di evitare di bloccare connessioni in ingresso innocue scambiate per attacchi, alcuni IPS possono funzionare in modalità apprendimento o simulazione, nelle quali mostrano agli amministratori quali connessioni avrebbero bloccato in modo che questi possano capire se alcune impostazioni dell IPS debbano essere modificate. Poiché un IDPS non è in grado di individuare correttamente tutti gli attacchi, esso può fornire dei falsi positivi, cioè attività non pericolose scambiate per attacchi, e falsi negativi, cioè attacchi non individuati. Poiché ridurre i primi comporta un aumento dei secondi, tipicamente si preferisce riconoscere più

CAPITOLO 2. SICUREZZA DEI SISTEMI 20 falsi positivi, con lo svantaggio, però, di dover impiegare più risorse per dividere le vere minacce da quelle false. Inoltre, molti IDPS riescono ad individuare le evasioni, ovvero quegli attacchi in cui si modifica l aspetto dell attività maligna, ma non il suo effetto, per cercare di sfuggire ai controlli degli IDPS. 2.4.1 Tecniche degli IDPS per l individuazione di attacchi Sebbene gli IDPS usino varie tecniche per scoprire gli attacchi, le principali sono quella basata sulla firma, quella basata sulle anomalie e l analisi di stateful protocol. Nel seguito saranno descritte queste tre tecniche. Individuazione basata sulla firma Questa tecnica si basa sul confronto tra eventi già osservati (noti) e le firme, ovvero schemi che corrispondono ad un attacco o tipo di attacco conosciuto. Esempi sono: un tentativo di connessione telnet usando come nome utente root, procedura che vìola le politiche di sicurezza aziendale; un messaggio di posta elettronica con oggetto Free pictures! ed allegato freepics.exe, una nota forma di malware. Questa tecnica è molto semplice ed efficace contro attacchi conosciuti, ma del tutto inefficace contro attacchi sconosciuti: basta, ad esempio, modificare il nome dell allegato precedente in freepics2.exe e questo non sarebbe individuato, a meno di non creare una nuova regola che controlli anche questa firma. Questa tecnica non consente di tracciare e comprendere lo stato della comunicazione: ad esempio non è in grado di accoppiare una richiesta con la corrispondente risposta, né di ricordare precedenti richieste simili a quella corrente. Per questo la tecnica basata sula firma non è in grado di riconoscere attacchi costituiti da eventi multipli se ciascuno di essi non è riconosciuto come attacco. Individuazione basata sulle anomalie Questa tecnica coniste nel confrontare attività ritenute normali con gli eventi osservati, con lo scopo di scoprire differenze evidenti. Si usano profili, cioè rappresentazioni del normale comportamento di host, utenti, connessioni di rete o applicazioni ottenute nel corso di un certo

CAPITOLO 2. SICUREZZA DEI SISTEMI 21 periodo, detto periodo di addestramento. Un profilo può, ad esempio, rappresentare la quantità di banda media usata durante i giorni lavorativi, e quando l IDPS nota un utilizzo molto maggiore del consueto può far scattare un allarme verso gli amministratori. La tecnica basata sulle anomalie riesce a scoprire piuttosto facilmente attacchi precedentemente sconosciuti, poiché questi possono modificare in maniera significativa certe attività del cui funzionamento si tiene traccia nei profili. Questi profili possono essere statici o dinamici: nel primo caso, una volta generati l IDPS usa sempre gli stessi profili, salvo quando gli sia ordinato di generarne di nuovi; nel secondo caso, i profili inizialmente creati sono aggiornati man mano che si osservano nuovi eventi. In questo modo, i profili dinamici si adattano meglio alle modifiche della rete, che possono causare variazioni nei livelli delle attività ritenuti normali, e quindi rendere i profili statici non più attendibili a meno di non ricrearli. Un problema di cui soffrono i profili dinamici, però, è la loro esposizione alle evasioni, poiché, se effettuate con le giuste tempistiche, possono essere considerate dall IDPS come normali attività (non maligne). Altri problemi sono: il numero elevato di falsi positivi, prodotti da attività non maligne ma che si discostano dai livelli normali o che non si sono mai verificate durante il periodo di apprendimento e sono dunque riconosciute come anomale; la difficoltà per gli analisti nel capire cosa ha prodotto un certo allarme. Analisi di stateful protocol Questa analisi consiste nel confrontare profili predefiniti di attività generalmente considerate innocue per ogni stato di protocollo con gli eventi osservati, per scoprire differenze significative. Diversamente dal caso precedente, in questa analisi si usano profili universali creati dal produttore, che specificano come un protocollo debba o non debba essere usato. Inoltre l IDPS è in grado di comprendere e tener traccia dello stato dei protocolli di rete, trasporto ed applicazione per i quali esiste un concetto di stato (da qui stateful). Come esempio si può considerare un sessione FTP (File Transfer Protocol): all inizio essa è nello stato non autenticato e l IDPS si aspetta che l utente si autentichi; se, invece, proverà ad eseguire uno dei vari comandi disponibili nella modalità autenticata, il suo comportamento potrà essere considerato sospetto (e quindi precursore di possibili attacchi), mentre non lo sarà se eseguirà uno

CAPITOLO 2. SICUREZZA DEI SISTEMI 22 di quei comandi dopo essere entrato con successo nella sessione autenticata. L analisi di stateful protocol può effettuare altri controlli, come la segnalazione di sequenze inaspettate di comandi e di comandi (o loro argomenti) dalla lunghezza inusuale. Tra gli svataggi di questo tipo di analisi vi è l utilizzo intenso delle risorse, a causa della complessità dell analisi e del tracciamento delle connessioni. Inoltre, quest analisi non rileva quegli attacchi che non di discostano dalle caratteristiche ritenute normali dei comportamenti di protocollo, come quegli attacchi che possono provocare un denial of service (DoS) a partire da singole azioni non ritenute pericolose. Infine, il modello di un protocollo usato da un IDPS può entrare in conflitto con l implementazione del protocollo in una certa applicazione o sistema operativo. 2.4.2 Componenti di un IDPS Un sistema IDPS è tipicamente costituito dalle seguenti parti: sensore o agente, che monitora e analizza l attività sulla rete (sensore) o su un host (agente); server di gestione, un dispositivo che riceve le informazione dai sensori e le gestisce. Alcuni server sono in grado di analizzare le informazioni ricevute in maniera più approfondita di quanto non possano fare i sensori, ad esempio tramite correlazione; server del database, dove sono memorizzate le informazioni sugli eventi raccolte da sensori, agenti e dal server di gestione; console, un programma che fornisce ad utenti e amministratori un interfaccia verso l IDPS. La console è di solito installata su normali computer desktop e può servire per attivtà di amministrazione dell IDPS o di analisi e monitoraggio. Tutti i componenti possono essere connessi attraverso una normale rete o attraverso una rete di gestione, appositamente progettata per software sicuro e sulla quale passa tutto il traffico di questi dispositivi, che sono di fatto nascosti ai malintenzionati. In alternativa, si può usare

CAPITOLO 2. SICUREZZA DEI SISTEMI 23 una normale rete sulla quale sia stata creata una VLAN (Virtual Local Area Network), che protegge le comunicazioni dell IDPS, anche se non al livello di una rete di gestione. 2.4.3 Tipi di tecnologie IDPS Esistono varie tecnologie per gli IDPS, che si possono raggruppare nei seguenti gruppi in base al tipo di eventi che controllano (per maggiori dettagli si può consultare [36]): IDPS basato sulla rete, che controlla il traffico della rete ed analizza l attività dei protocolli di applicazione e di rete alla ricerca di eventi sospetti. Può individuare vari tipi di attacchi ed è utilizzato soprattutto ai confini di una rete, ad esempio in prossimità di firewall e router di confine o di server per l accesso remoto; IDPS wireless, che controlla il traffico wireless ed analizza l attività dei protocolli di rete wireless, ma non quella dei protocolli di trasporto o dei livelli superiori, che non sono gestiti. Solitamente è usato all interno di una rete senza fili di un organizzazione; sistema di analisi del comportamento della rete (NBA system, Network Behavior Analysis), che analizza il traffico di rete alla ricerca di minacce che generano insoliti flussi di traffico, come avviene per gli attacchi di denial of service distribuito, per certi tipi di malware (worms, backdoors, ecc...) e per violazioni di politiche. Un sistema NBA è tipicamente impiegato per controllare reti interne ad un organizzazione o reti che collegano un organizzazione con l esterno (ad esempio Internet); IDPS basato su host, che controlla le attività di un singolo host, come il suo traffico di rete, i registri di sistema, applicazioni attive, ecc... Questo tipo di IDPS è impiegato su host critici, come server pubblicamente accessibili o contenenti informazioni sensibili. Per via dei diversi vantaggi e svataggi che ogni tecnologia presenta, di solito se ne combinano due o più per cercare di ottenere una migliore protezione: IDPS basati sulla rete e su host sono tra i più utilizzati, ma anche i sistemi NBA sono impiegati quando sia richiesta una maggiore protezione verso attacchi DoS, worms o altre minacce che provocano flussi di traffico anomali.

CAPITOLO 2. SICUREZZA DEI SISTEMI 24 Per ottenere una buona protezione, però, conviene integrare gli IDPS, dal momento che, altrimenti, funzionerebbero in maniera indipendente l uno dall altro. L integrazione può essere diretta, cioè le informazioni raccolte da un IDPS passano ad un altro IDPS (spesso si tratta di sistemi dello stesso produttore), oppure indiretta, nel qual caso vari IDPS inviano i dati raccolti a dei software di gestione degli eventi e delle informazioni sualla sicurezza (SIEM, Security Information and Event Management), che effettuano operazioni di correlazione sui dati per scoprire attività pericolose o l uso inappropriato della rete. 2.4.4 Approcci per la realizzazione degli IDS Il modo in cui un IDS (o IDPS) è realizzato influenza in maniera considerevole il suo funzionamento e l effetto che ha sulle risorse monitorate, senza però dover mai risultare di ostacolo al funzionamento della rete analizzata e dei suoi elementi. Nel seguito si illustrano gli approcci più comuni impiegati per la realizzazione di un IDS, di cui una rappresentazione schematica è in figura 2.8 (per una panoramica più completa si può consultare [3]). Figura 2.8. Alcuni approcci per la realizzazione di IDS.

CAPITOLO 2. SICUREZZA DEI SISTEMI 25 IDS basati su reti neurali Una rete neurale (neural network) può essere utilizzata per identificare e classificare le attività della rete. Ogni elemento della rete, strettamente interconnesso con gli altri, è in grado di elaborare le informazioni che riceve in ingresso, ed il risultato prodotto dall intera rete dipende dalle caratteristiche dei singoli nodi e dai pesi associati ad ogni interconnessione: variando questi pesi, si può ottenere il risultato desiderato. Tipicamente una rete neurale è inizialmente sottoposta ad una fase di addestramento (training) in cui analizza degli esempi pre-selezionati che riguardano un determinato problema; al termine di questo periodo, quando la rete ha acquisito una certa esperienza su quel problema e raggiunge risultati soddisfacenti, può essere usata anche su dati nuovi, non scelti ad hoc. Gli IDS basati sulle reti neurali sono in grado di elaborare dati provenienti da numerose sorgenti, prevedere eventi e lavorare anche con segnali non lineari. Oltre ad essere veloci, possono effettuare apprendimento supervisionato mettendo in corrispondenza i segnali in ingresso con le uscite desiderate; sono in grado di adattare i propri pesi all ambiente in cui lavorano ed in caso di danneggiamento le loro prestazioni si degradano piuttosto lentamente. Tuttavia, la fase di apprendimento (che non può essere evitata) deve essere ripetuta se i dati con cui si lavora cambiano nel tempo. Ghosh et al. [20] hanno sviluppato un sistema che sfrutta le rete neurali per analizzare i profili di comportamento delle applicazioni, anziché degli utenti: dopo aver identificato il profilo considerato normale, il sistema lo confronta con lo stato attuale alla ricerca di anomalie. IDS basati su metodi bayesiani La logica bayesiana è impiegata quando si devono prendere decisioni su cosa avverrà in futuro: in particolare, l inferenza bayesiana utilizza la conoscenza di eventi del passato per predire quelli del futuro. Gli IDS basati sui metodi bayesiani devono avere a disposizione un modello statistico ottimo, che può essere usato in situazioni in cui i dati da estrarre siano affetti da rumore; inoltre, questi sistemi sono piuttosto robusti poiché piccole variazioni nel modello non modificano comple-

CAPITOLO 2. SICUREZZA DEI SISTEMI 26 tamente le prestazioni del sistema. Problemi di incertezza possono però sorgere quando il numero di parametri necessari a definire il sistema è elevato. Un IDS basato su metodi bayesiani è stato proposto da Scott [37], che utilizza tecniche generiche per adattarsi a vari tipi di reti. Le regole bayesiane offrono un modo per combinare metodi per l individuazione delle intrusioni come l individuazione delle anomalie e delle firme, mentre dei metodi bayesiani sono impiegati per presentare all operatore umano le prove delle intrusioni in termini di probabilità, che egli deve valutare. IDS basati su logica fuzzy Gli approcci classici per l individuazione delle intrusioni stabiliscono un intervallo di valori che rappresenta la situazione normale; quando i valori cadono fuori da quest intervallo, la situazione è considerata anomala, indipendentemente da quanto il valore registrato sia lontano (o vicino) dalla normalità. Questa separazione netta può essere ammorbidita dalla logica fuzzy, grazie alla quale si possono creare regole che aumentano la flessibilità dell IDS. Questi sistemi sono in grado di gestire informazioni imprecise o vaghe, imitando le decisioni che un essere umano prenderebbe in situazioni analoghe. Questi sistemi sono veloci e possono modellare problemi complessi e non lineari; tuttavia, a causa della loro astrattezza richiedono degli esperti per la determinazione delle regole che rappresentano le relazioni tra i dati. Dickerson et al. [19] hanno creato il sistema FIRE (Fuzzy Intrusion Recognition Engine), che utilizza la logica fuzzy per scoprire le minacce verso reti di calcolatori. I compiti di monitoraggio sono suddivisi tramite un sistema basato sugli agenti: questi comunicano attraverso un motore di valutazione fuzzy, che combina i risultati prodotti dai singoli agenti tramite regole fuzzy, producendo degli allarmi veri fino ad un certo punto. Questo sistema è in grado di identificare attacchi di denial of service e di scansione delle porte, oltre che ad individiuare backdoor e trojan.

CAPITOLO 2. SICUREZZA DEI SISTEMI 27 Linguaggi special purpose per IDS Questi sistemi sono progettati in base al comportamento dei programmi: le regole sono definite in termini di risorse del sistema piuttosto che di attacchi e devono essere aggiornate alcune volte durante l esecuzione del programma. Esse sono specifiche per una particolare versione del programma, perciò ogni versione ha il proprio insieme di regole modificate. Sekar et al. [38] hanno proposto un sistema per identificare gli attacchi di rete raccogliendo e aggregando molti pacchetti ed elaborandoli. Esso è costituito da un compilatore e da un sistema runtime: il primo effettua la trasformazione delle specifiche dell intrusione in codice C++ e la compilazione di pattern matching, mentre il secondo fornisce la possibilità di catturare pacchetti da un interfaccia di rete o da file. IDS basati su regole Gli IDS basati su regole, che comprendono gli IDS basati su sistemi esperti, sono impiegati per decisioni, elaborazioni e compiti ripetitivi. Sono in grado di ridurre gli errori commessi dagli operatori umani (ad esempio ricontrollando transizioni sfuggite all operatore), ma, essendo basati su regole, richiedono di essere aggiornati frequentemente; inoltre, l acquisizione di queste regole è una fase che può essere soggetta ad errori. Ilgun et al. [22] utilizzano l analisi delle transizioni di stato per individuare le intrusioni. Il modello è rappresentato come una serie di cambiamenti di stato, dallo stato iniziale sicuro allo stato del target compromesso. Questi stati costituiscono un grafo e rappresentano i passaggi necessari affinché un attacco possa verificarsi. Tali diagrammi costituiscono l ingresso di STAT (State Transition Analysis Tool), uno strumento che confronta le informazioni sulle transizioni di stato registrate sul sistema target con una rappresentazione basata su regole di un attacco conosciuto e specifico del sistema. IDS basati su immunizzazione Gli IDS basati sull immunizzazione imitano il sistema immunitario che individua e blocca le intrusioni, ed è in grado di riconoscere nuove minacce senza che qualcuno gliele indichi come

CAPITOLO 2. SICUREZZA DEI SISTEMI 28 tali. Questi sistemi utilizzano diversi meccanismi per fornire protezione; tuttavia, i modelli di base sono semplici poiché manca una teoria generale sul funzionamento del sistema immunitario umano. Un sistema immunitario artificiale, NAIS (Native Artificial Immune System), è stato sviluppato da Pagnoni e Visconti [28]: è in grado di distinguere le applicazioni normali da quelle anomale, di proteggere server Web e FTP da attacchi nuovi o sconosciuti e di impedire ad applicazioni esterne l accesso al server.

Capitolo 3 Intrusion detection message exchange format (IDMEF) Il formato IDMEF (Intrusion Detection Message Exchange Format) è stato sviluppato con lo scopo di diventare un formato standard che possa essere utilizzato dagli intrusion detection systems (IDS) per segnalare eventi ritenuti sospetti [15]. Sebbene il luogo più naturale dove implementare questo formato sia il canale tra il sensore (o intrusion detection analyzer) e la console (o manager) a cui sono inviati gli allarmi, l IDMEF si può rivelare utile in tutte quelle situazioni in cui si richieda l aggregazione di dati provenienti da più fonti, per poter formare più facilmente un quadro d insieme omogeneo: per esempio, sistemi a singolo database che ricevono e memorizzano dati provenienti da vari dispositivi di individuazione delle intrusioni, per i quali l IDMEF aiuterebbe le attività di analisi dei dati e di reporting; oppure interfacce grafiche che permettano all utente di visualizzare su un unico schermo tutti gli allarmi provenienti dai diversi sensori; o ancora, l IDMEF potrebbe servire come formato comune per lo scambio di dati tra diverse organizzazioni. 29

CAPITOLO 3. INTRUSION DETECTION MESSAGE EXCHANGE FORMAT 30 3.1 Il modello dei dati IDMEF Il modello dei dati IDMEF è una rappresentazione object-oriented dei dati dell allarme che è inviato dall intrusion detection analyzer all intrusion detection manager. Questa rappresentazione consente di trovare una soluzione per diversi problemi: grazie alla flessibilità e all estensibilità di una rappresentazione orientata agli oggetti (rese possibili dall aggregazione e dalle sottoclassi, ad esempio), si possono gestire, senza compromettere la validità né l integrità del modello, allarmi costituiti da dati di diverso tipo, peraltro non sempre presenti in tutti gli allarmi, quali porte, informazioni sull utente, ecc...; particolari classi di supporto permettono di rendere più omogenei gli stessi tipi di allarmi provenienti da diverse sorgenti. A causa delle differenze tra i diversi IDS (in particolare differenze sull individuazione degli attacchi), uno stesso allarme può infatti essere trasmesso con informazioni diverse da IDS diversi; l estensibilità del Document Type Definition (DTD) consente la gestione di allarmi semplici e complessi, che si rende necessaria a causa dei diversi tipi di analizzatori esistenti, i quali, a seconda delle loro capacità, possono generare allarmi corredati da poche o tante informazioni; grazie alle sottoclassi si possono gestire allarmi prodotti in ambienti operativi differenti, che usano sistemi operativi e infrastrutture di rete diversi, i quali segnalano e riportano gli allarmi con caratteristiche diverse. Il modello ha come obiettivo quello di fornire una rappresentazione standard delle informazioni prodotte da un IDS quando questo individua il verificarsi di un qualche evento insolito. Il modello è content-driven e, pur essendo flessibile ed estensibile, non dà spazio ad ambiguità di alcuna sorta: informazioni contrastanti non sono pertanto ammesse. Inizialmente furono proposte due diverse possibilità di realizzazione del formato IDMEF: una che faceva uso della Structure of Management Information (SMI) per descrivere un semplice MIB (Management Information Base) di tipo SNMP (Simple Network Management Protocol);

CAPITOLO 3. INTRUSION DETECTION MESSAGE EXCHANGE FORMAT 31 l altra che faceva uso di un DTD per descrivere documenti nel linguaggio XML (extensible Markup Language). L Intrusion Detection Working Group (IDWG) scelse nel 2000 la seconda opzione, che si prestava meglio a soddisfare i requisiti richiesti al nuovo formato. La flessibilità dell XML lo rende adatto ad applicazioni di vario tipo, dallo scambio di dati in formato elettronico alla creazioni di linguaggi di markup per chimica, matematica, astronomia, per citarne alcuni. Oltre a ciò, altri fattori hanno contribuito alla scelta dell XML come base per la realizzazione di IDMEF: XML consente di creare un linguaggio apposito per la descrizione degli allarmi, che può essere esteso attraverso successive revisioni; vasta è la quantità di strumenti ed applicazioni disponibili per l elaborazione di documenti XML, nonché per la loro validazione, riducendo il tempo necessario per l adozione del formato IDMEF; lo standard XML richiede il supporto delle codifiche UTF-8 e UTF-16 della ISO/IEC 10646 (Universal Multiple-Octet Coded Character Set, o UCS), e dell Unicode, pertanto anche i documenti IDMEF risultano compatibili con queste diffuse codifiche di caratteri; l integrazione di XML con XSL (extensible Stylesheet Language) garantisce l aggregazione ed il filtraggio dei messaggi XML (e, di conseguenza, IDMEF); successivi sviluppi al linguaggio XML, quali potrebbero essere il supporto alle basi di dati ed estensioni per supportare la programmazione ad oggetti, risulterebbero da subito applicabili anche al formato IDMEF; XML è gratuito, non prevede licenze (né gratis né a pagamento) né diritti d autore. Per approfondimenti sul linguaggio XML si rimanda ai numerosi libri e risorse disponibili (spesso gratuitamente in rete), ad esempio [34, 43, 44].

CAPITOLO 3. INTRUSION DETECTION MESSAGE EXCHANGE FORMAT 32 3.2 Il documento IDMEF-XML (Tipi di dato) Tutti i dati di un file IDMEF devono essere espressi in formato testo (piuttosto che binario), poiché XML è un linguaggio testuale. Esistono vari tipi di dato predefiniti dal formato IDMEF, ognuno dei quali ha dei precisi requisiti che devono essere rispettati: interi, rappresentati dal tipo INTEGER e codificati in base 10 o base 16, usano cifre da 0 a 9 ed il segno opzionale + o - (per la base 10), oppure le cifre da 0 a 9 e da a a f (o le equivalenti maiuscole), precedute da 0x (per la base 16); reali (o floating-point), rappresentati dal tipo REAL e codificati in base 10, aderiscono alla rappresentazione della funzione di libreria strtod della famiglia di standard POSIX 1003.1, ovvero un segno opzionale ( + o - ) seguito da una stringa di cifre non vuota (che può contenere un radix character, cioè un carattere. o, ), seguita a sua volta da una parte di esponente opzionale (costituita dal simbolo e o E seguito dal segno opzionale e da una o più cifre); caratteri e stringhe, rappresentati rispettivamente dai tipi CHARACTER (per un singolo carattere) e STRING (per più caratteri), non richiedono una formattazione particolare, salvo i casi in cui sia necessario utilizzare i caratteri &, <, >,,, che devono essere sostituiti da sequenze particolari dette entity reference. Si possono comunque usare tutti i caratteri definiti dagli standards ISO/IEC 10646 e Unicode attraverso i numeric character reference (NCR), ovvero una stringa che comincia con i caratteri & e #, seguiti da una serie di cifre (in base decimale o esadecimale) e terminata da ;; dati binari, rappresentati dal tipo BYTE e codificati in base 64; enumerazioni, rappresentati dal tipo ENUM e costituiti da una lista ordinata di valori; stringhe di data e orario, rappresentate dal tipo DATETIME, identificano un preciso istante temporale seguendo la sintassi dello standard ISO 8601:2000, per il quale le date devono avere il formato YYYY-MM-DD (dove YYYY è l anno espresso con 4 cifre, MM è il mese espresso con 2 cifre e DD è il giorno espresso con 2 cifre), mentre gli orari devono avere

CAPITOLO 3. INTRUSION DETECTION MESSAGE EXCHANGE FORMAT 33 il formato hh:mm:ss (dove hh sono le ore, mm sono i minuti e ss sono i secondi, tutti espressi con 2 cifre) oppure il formato hh:mm:ss,ss o hh:mm:ss.ss (dove ss,ss o ss.ss sono i secondi seguiti da frazioni di essi, queste ultime costituite da un numero di cifre arbitrario). Il formato supporta anche i secondi intercalari: quelli positivi sono inseriti tra 23:59:59Z e 24:00:00Z e sono rappresentati da 23:59:60Z, mentre quelli negativi si ottengono omettendo 23:59:59Z. Il tempo deve essere espresso nel tempo coordinato universale (UTC, Coordinated Universal Time), nel qual caso si aggiunge una Z alla stringa temporale, oppure in un altro fuso, aggiungendo alla stringa temporale la stringa +hh:mm (se l orario è successivo a UTC) o -hh:mm (se l orario è precedente a UTC). Infine, stringhe data-orario si possono ottenere unendo le stringhe di data e orario separate dal simbolo T (YYYY-MM-DDThh:mm:ss.ssZ); marche temporali NTP (Network Time Protocol), rappresentate dal tipo NTPSTAMP, sono numeri senza segno in virgola fissa a 64 bit, di cui i primi 32 costituiscono la parte intera, mentre gli ultimi 32 la parte frazionaria; liste delle porte, rappresentate dal tipo PORTLIST, sono costituite da elenchi di numeri interi separati da virgole e da intervalli di numeri interi (nel formato N-M, dove N e M sono inclusi). 3.3 Il modello dei dati IDMEF La figura 3.1 illustra le relazioni che esistono tra i principali componenti del modello. Ogni messaggio è figlio della classe madre IDMEF-Message e può essere di due tipi: Alert e Heartbeat. Le sottoclassi consentono di specificare ulteriori informazioni per ogni tipo di messaggio. Nelle successive sottosezioni saranno descritte le principali classi che costituiscono il modello IDMEF, facendo uso anche dei diagrammi UML (Unified Modeling Language). Il DTD IDMEF completo è riportato nell appendice A.

CAPITOLO 3. INTRUSION DETECTION MESSAGE EXCHANGE FORMAT 34 Figura 3.1. IDMEF. Diagramma UML che illustra le relazioni tra le classi principali del modello 3.3.1 La classe IDMEF-Message La classe IDMEF-Message è la classe principale, di cui tutte le altre sono istanza. Attributo: version, ovvero la versione del formato IDMEF alla quale il messaggio si conforma. 3.3.2 La classe Alert Un messaggio Alert (cioè un allarme) è inviato da un analizzatore al proprio manager ogni volta che esso individua un evento insolito; un singolo messaggio può corrispondere ad uno o più eventi. Un messaggio Alert (di cui un esempio è nel listato 3.1) è costituito dalle seguenti sotto-classi (fig. 3.2): Analyzer (obbligatorio, 1), informazioni sull analizzatore che ha generato l allarme;

CAPITOLO 3. INTRUSION DETECTION MESSAGE EXCHANGE FORMAT 35 Listing 3.1. Un Alert IDMEF che rappresenta un attacco teardrop. <? xml version =" 1.0 " encoding ="UTF -8"?> <IDMEF - Message xmlns:idmef =" http: // iana. org / idmef " version =" 1.0 "> < Alert messageid =" abc123456789 " > < Analyzer analyzerid ="hq -dmz - analyzer01 "> <Node category =" dns "> < location > Headquarters DMZ Network </ location > < idmef:name > analyzer01. example. com </ name > </ Node > </ Analyzer > < CreateTime ntpstamp ="0 xbc723b45.0 xef449129 "> 2000-03 -09 T10:01:25.93464-05 :00 </ CreateTime > < Source ident =" a1b2c3d4 "> <Node ident =" a1b2c3d4-001 " category =" dns "> <name > badguy. example. net </ name > < Address ident =" a1b2c3d4-002 " category ="ipv4 -net - mask "> < address > 192.0.2.50 </ address > < netmask > 255.255.255.255 </ netmask > </ Address > </ Node > </ Source > < Target ident =" d1c2b3a4 "> <Node ident =" d1c2b3a4-001 " category =" dns "> < Address category ="ipv4 -addr - hex "> < address >0 xde796f70 </ address > </ Address > </ Node > </ Target > < Classification text =" Teardrop detected " > < Reference origin =" bugtraqid "> <name >124 </ name > <url >http: // www. securityfocus. com / bid /124 </ url > </ Reference > </ Classification > </ Alert > CreateTime (obbligatorio, 1), l orario a cui l allarme è stato generato; Classification (obbligatorio, 1), il nome dell allarme o comunque informazioni che permettano al manager di capire di che allarme si tratti;

CAPITOLO 3. INTRUSION DETECTION MESSAGE EXCHANGE FORMAT 36 DetectTime (0 o 1), l orario a cui è stato individuato il primo degli eventi che hanno condotto all allarme; AnalyzerTime (0 o 1), l orario dell analizzatore; Source (0 o più), la sorgente degli eventi che hanno condotto all allarme; Target (0 o più), l obiettivo degli eventi che hanno condotto all allarme; Assessment (0 o 1), informazioni sull impatto dell evento e su comportamenti adottati dall analizzatore in risposta ad esso; AdditionalData (0 o più), informazioni aggiunte dall analizzatore che non rientrano in nessuna delle categorie qui sopra (ad esempio a causa di un estensione del formato IDMEF). Figura 3.2. Diagramma UML che illustra le classi che compongono un messaggio Alert. Attributo: messageid (opzionale), un identificatore univoco per l allarme.

CAPITOLO 3. INTRUSION DETECTION MESSAGE EXCHANGE FORMAT 37 Informazioni aggiuntive sull allarme sono memorizzate in altre 3 classi di supporto: ToolAlert, per informazioni sugli strumenti o programmi usati per portare l attacco, se l analizzatore riesce ad individuarli (con l obiettivo di raggruppare attacchi in cui si sono usati gli stessi strumenti); CorrelationAlert, per informazioni atte alla correlazione di informazioni sugli allarmi (con l obeittivo di individuare allarmi tra loro correlati); OverflowAlert, per informazioni dettagliate su attacchi di buffer overflow. 3.3.3 La classe Heartbeat I messaggi Heartbeat indicano al manager lo stato dell analizzatore e sono inviati con cadenza regolare. L arrivo di un messaggio Heartbeat significa che l analizzatore è funzionante, mentre la mancanza di questi messaggi significa che l analizzatore o la rete non funzionano correttamente. Un messaggio Heartbeat (di cui un esempio è riportato nel listato 3.2) è costituito dalle seguenti sotto-classi (fig. 3.3): Analyzer (obbligatorio, 1), informazioni sull analizzatore che ha generato l heartbeat; CreateTime (obbligatorio, 1), l orario a cui l heartbeat è stato generato; HeartbeatInterval (0 o 1), l intervallo in secondi al quale gli heartbeat sono generati; AnalyzerTime (0 o 1), l orario dell analizzatore; AdditionalData (0 o più), informazioni aggiunte dall analizzatore che non rientrano in nessuna delle categorie qui sopra (ad esempio a causa di un estensione del formato IDMEF). Attributo: messageid (opzionale), un identificatore univoco per l heartbeat.

CAPITOLO 3. INTRUSION DETECTION MESSAGE EXCHANGE FORMAT 38 Listing 3.2. Un Heartbeat IDMEF. <? xml version =" 1.0 " encoding ="UTF -8"?> <IDMEF - Message version =" 1.0 " xmlns:idmef =" http: // iana. org / idmef "> < Heartbeat messageid =" abc123456789 " > < Analyzer analyzerid ="hq -dmz - analyzer01 "> <Node category =" dns "> < location > Headquarters DMZ Network </ location > <name > analyzer01. example. com </ name > </ Node > </ Analyzer > < CreateTime ntpstamp ="0 xbc722ebe.0 x00000000 "> 2000-03 -09 T14:07:58Z </ CreateTime > < AdditionalData type =" real " meaning ="% memused "> <real >62.5 </ real > </ AdditionalData > < AdditionalData type =" real " meaning ="% diskused "> <real >87.1 </ real > </ AdditionalData > </ Heartbeat > </ IDMEF - Message > Figura 3.3. Diagramma UML che illustra le classi che compongono un messaggio Heartbeat. 3.3.4 Le classi fondamentali Le classi fondamentali che costituiscono Alert e Heartbeat sono: Analyzer, Source, Target, Classification e AdditionalData. Nel seguito si darà una descrizione di ciascuna di esse.

CAPITOLO 3. INTRUSION DETECTION MESSAGE EXCHANGE FORMAT 39 La classe Analyzer La classe Analyzer fornisce informazioni sull analizzatore che ha generato l allarme o l heartbeat. Ogni allarme o heartbeat può portare il nome di un solo analizzatore che l ha prodotto (anche nel caso di IDS installati gerarchicamente occorre che sia indicato un unico analizzatore). Un oggetto Analyzer è costituito da tre classi: Node (0 o 1), informazioni sull host o dispositivo su cui è presente l analizzatore (indirizzo di rete, nome del nodo, ecc...); Process (0 o 1), informazioni sul processo nel quale è eseguito l analizzatore; Analyzer (0 o 1), informazioni sull analizzatore attraverso il quale il messaggio può essere transitato (utile per conservare il percorso del messaggio qualora esso sia inoltrato a più analizzatori prima di giungere al manager). Attributi: analyzerid (opzionale), un identificatore univoco per l analizzatore; name (opzionale), nome esplicito dell analizzatore, più facile da leggere rispetto a analyzerid; manufacturer (opzionale), nome del produttore del software o dell hardware dell analizzatore; model (opzionale), il nome/numero del modello dell analizzatore; version (opzionale), il numero di versione dell analizzatore; class (opzionale), la classe dell analizzatore; ostype (opzionale), nome del sistema operativo; osversion (opzionale), versione del sistema operativo.

CAPITOLO 3. INTRUSION DETECTION MESSAGE EXCHANGE FORMAT 40 La classe Classification La classe Classification fornisce il nome dell allarme (scelto dal generatore dell allarme stesso) o comunque informazioni che permettano al manager di capire di cosa si tratta. Un oggetto Classification è composta dalla seguente classe: Reference (0 o 1), informazioni sul messaggio, puntando a risorse di documentazione esterne. Attrubuti: ident (opzionale), un identificatore univoco per la classificazione corrente; text (obbligatorio), una stringa fornita dal produttore che identifica il messaggio Alert. La classe Source La classe Source contiene informazioni sulle possibili sorgenti che hanno provocato gli eventi che hanno causato l allarme. Un oggetto Source è composto dalle seguenti classi: Node (0 o 1), informazioni sull host o dispositivo che sembra provocare gli eventi (indirizzo di rete, nome del nodo, ecc...); User (0 o 1), informazioni sull utente che sembra provocare gli eventi; Process (0 o 1), informazioni sul processo che sembra provocare gli eventi; Service (0 o 1), informazioni sul servizio di rete coinvolto negli eventi. Attributi: ident (opzionale), un identificatore univoco per la sorgente corrente; spoofed (opzionale), indica, sulla base delle informazioni che l analizzatore riesce a recuperare, se la sorgente è un indirizzo falsificato (spoofed) allo scopo di nascondere la vera origine dell attacco;

CAPITOLO 3. INTRUSION DETECTION MESSAGE EXCHANGE FORMAT 41 interface (opzionale), indica su quale interfaccia dell analizzatore è stata vista la sorgente corrente, se l analizzatore è fornito di più interfacce. La classe Target La classe Target contiene informazioni sui possibili obiettivi degli eventi che hanno causato l allarme. Un oggetto Target è composto dalle seguenti classi: Node (0 o 1), informazioni sull host o dispositivo al quale sembrano indirizzati gli eventi (indirizzo di rete, nome del nodo, ecc...); User (0 o 1), informazioni sull utente al quale sembrano indirizzati gli eventi; Process (0 o 1), informazioni sul processo al quale sembrano indirizzati gli eventi; Service (0 o 1), informazioni sul servizio di rete coinvolto negli eventi; File (opzionale), informazioni sui file coinvolti negli eventi. Attributi: ident (opzionale), un identificatore univoco per l obiettivo corrente; decoy (opzionale), indica, sulla base delle informazioni che l analizzatore riesce a recuperare, se l obiettivo è reale o è un esca (decoy); interface (opzionale), indica su quale interfaccia dell analizzatore è stato visto l obiettivo corrente, se l analizzatore è fornito di più interfacce. La classe AdditionalData La classe AdditionalData contiene informazioni che non possono rientrare in nessun altra classe del modello IDMEF. Può essere usata per informazioni semplici o più complesse (header dei pacchetti), ad esempio dopo aver esteso il modello ed il DTD IDMEF. Attributo:

CAPITOLO 3. INTRUSION DETECTION MESSAGE EXCHANGE FORMAT 42 meaning (opzionale), una stringa che descrive il contenuto dell elemento (i valori dipendono dal produttore e dall implementazione). 3.3.5 Le classi Time, Assessment e le classi di supporto Le altre classi del modello IDMEF si possono dividere nelle categorie: Time, Assessment e supporto. Nel seguito saranno solo elencate, mentre per una descrizione più approfondita si rimanda a [15]. Le classi Time CreateTime, fornisce la data e l ora alla quale l allarme o l heartbeat sono stati generati. DetectTime, fornisce la data e l ora alla quale il primo tra gli eventi che hanno provocato l allarme è stato individuato. AnalyzerTime, fornisce la data e l ora correnti dell analizzatore. Le classi Assessment Assessment, fornisce il giudizio dell analizzatore su un evento. Impact, fornisce il giudizio dell analizzatore sull impatto dell evento sull obiettivo. Action, descrive qualsiasi azione intrapresa dall analizzatore in risposta ad un evento. Confidence, rappresenta la migliore stima che l analizzatore fa della validità della propria analisi. Le classi di supporto Reference, fornisce il nome di un allarme o altre informazioni che consentano al manager di capire di cosa si tratta.

CAPITOLO 3. INTRUSION DETECTION MESSAGE EXCHANGE FORMAT 43 Node, identifica host ed altri dispositivi di rete (router, switch, ecc...). Address, rappresenta gli indirizzi di rete, hardware e delle applicazioni. User, descrive gli utenti e serve come contenitore per oggetti UserId. UserId, informazioni specifiche su un utente. Più di un UserId può essere usato nella classe User. Process, descrive i processi in esecuzione su sorgente, obiettivo e analizzatore. Service, descrive i servizi di rete per sorgente e obiettivo. WebService, include informazioni aggiuntive sul traffico Web. SNMPService, include informazioni aggiuntive sul traffico SNMP (Simple Network Management Protocol). File, rappresenta informazioni su un file o su oggetti analoghi che sono stati creati, cancellati o modificati sull obiettivo (Target). FileAccess, rappresenta i permessi di accesso ad un file. Linkage, rappresenta collegamenti nel file system tra il file corrente ed altri oggetti del file system. Inode, rappresenta informazioni contenute in un file system Unix inode. Checksum, rappresenta informazioni di checksum associate al file.

Capitolo 4 Correlazione degli allarmi Con la continua diffusione degli intrusion detection systems (v. capitolo 2) e degli strumenti di sicurezza complementari per l individuazione delle minacce ad una rete, la gestione degli allarmi, spesso di basso livello, generati da questi dispositivi assume una sempre più rilevante importanza. IDS, firewall, strumenti antivirus e file integrity checkers lavorano a diversi livelli e generano allarmi solitamente tra loro scollegati, sebbene possano riferirsi ad una stessa minaccia. Una gestione più intelligente di questi allarmi di basso livello porterebbe alcuni benefici: si potrebbe più facilmente capire qual è la sorgente o l obiettivo dell attacco, si potrebbero trovare collegamenti tra gli allarmi, eliminando quelli ridondanti, e ridurre i falsi allarmi, che sono mischiati insiemi agli allarmi veri. Con la correlazione degli allarmi (alert correlation) si cerca di ottenere una gestione degli allarmi di questo genere, che fornisca una visione d insieme sullo stato della rete a partire dai singoli allarmi. A causa della sua complessità, la correlazione è suddivisa in varie fasi (o componenti), che, a seconda dell approccio seguito, possono variare in numero e azioni che in esse sono svolte; non cambiano, comunque, ingresso ed uscita, rispettivamente gli allarmi di basso livello e uno scenario degli attacchi di più alto livello. 44

CAPITOLO 4. CORRELAZIONE DEGLI ALLARMI 45 4.1 Approcci alla correlazione degli allarmi Una suddivisione piuttosto generale della correlazione degli allarmi, basata anche su precedenti lavori disponibili in letteratura, è stata proposta in [35]; le fasi individuate sono le seguenti: normalizzazione, aggregazione, correlazione, riduzione dei falsi allarmi, analisi della strategia di attacco e assegnamento delle priorità. Per ogni componente sono state usate tecniche provenienti da diverse discipline, dal data mining alle tecniche fuzzy, passando per il machine learning. In figura 4.1 è presentato uno schema che associa ogni fase con alcune delle tecniche impiegate di cui si abbia notizia in letteratura. Queste fasi saranno trattate in maniera più dettagliata nei prossimi sotto-paragrafi. 4.1.1 Normalizzazione I messaggi di allarme possono provenire dai sensori di diversi sistemi, che codificano le informazioni ciascuno a proprio modo. Risulta perciò fondamentale l impiego di un formato standard, comune a tutti i componenti dell aggregazione, e a questo scopo l Internet Engineering Task Force (IETF) ha sviluppato il modello di dati IDMEF (Intrusion Detection Message Exchange Format, analizzato in dettaglio nel capitolo 3), un modello orientato agli oggetti ed implementato nel linguaggio XML (extensible Markup Language). Il formato IDMEF è in grado di esprimere le relazioni tra gli allarmi, grazie alle sottoclassi CorrelationAlert e ToolAlert: la prima tiene traccia delle relazioni con allarmi precedenti, mentre la seconda fornisce informazioni aggiuntive sugli strumenti usati per portare l attacco. Tuttavia, perché il formato IDMEF sia veramente accettato ed il suo utilizzo si diffonda tra gli IDS (per ora IDMEF è ancora classificato come sperimentale [15]), alcune questioni dovrebbero essere risolte: la più importante è senz altro la mancanza di una tassonomia degli attacchi comune a tutti gli IDS, che permetterebbe di avere segnalazioni di allarmi uniformi ed una cooperazione più semplice tra IDS ed analizzatori. Mancando una classificazione del genere, sono stati sviluppati database di attacchi e vulnerabilità pubblicamente disponibili, come CVE (Common Vulnerability Exposure) [12]: anche se non forniscono una vera e propria tassonomia, consentono comunque una certa interoperabilità tra diversi IDS.

CAPITOLO 4. CORRELAZIONE DEGLI ALLARMI 46 Figura 4.1. Rappresentazione delle fasi di cui si compone la correlazione degli allarmi e delle tecniche che possono essere usate in ciascuna di esse.

CAPITOLO 4. CORRELAZIONE DEGLI ALLARMI 47 4.1.2 Aggregazione L obiettivo di questa fase è di raggruppare gli allarmi simili. Un problema è definire la somiglianza tra due allarmi: possono essere simili se hanno molte caratteristiche in comune, oppure se sono originati dalla stessa causa. In quest ultimo caso, l aggregazione si è mostrata efficace nel ridurre il numero di allarmi provocati da un particolare attacco, agevolando il lavoro di analisi degli allarmi rimanenti e di identificazione dei falsi positivi. Valdes e Skinner [42] hanno proposto di valutare la somiglianza tra allarmi sulla base della somiglianza tra gli attributi (indirizzo IP, numeri di porta, orario di creazione, ecc...); quest ultima deve essere opportunamente pesata per la determinazione della somiglianza complessiva. Julisch [24] ha proposto una tecnica di clustering per raggruppare allarmi con la stessa causa. Questa tecnica si basa su strutture gerarchiche dette gerarchie di generalizzazione (generalization hierarchies), che scompongono gli attributi di un allarme dal più generico al più specifico; la diversità tra due attributi si calcola come il percorso più lungo tra i valori di quell attributo nella gerarchia, mentre la diversità tra due allarmi è la somma delle diversità dei singoli attributi. Tecniche di data mining sono state usate da Dain e Cunningham [14] per imparare come raggruppare gli allarmi in base a quanto si somigliano, mentre Zhu e Ghorbani [47] hanno usato tecniche di machine learning per stimare la probabilità di somiglianza tra coppie di allarmi. Queste tecniche permettono di unificare le fasi e aggregazione e correlazione, perché si sfruttano delle caratteritiche ottenute nella fase di aggregazione per la successiva di correlazione. Sempre in questo articolo si definisce la matrice di correlazione degli allarmi (ACM, Alert Correlation Matrix), che memorizza la correlazione media tra classi di allarmi, la quale è calcolata in maniera adattiva in base all analisi statistica di allarmi consecutivi. Questo permette di iniziare con valori della probabilità di correlazione non necessariamente perfetti, perché saranno corretti nella fase di apprendimento. Maggiori dettagli sulle tecniche di clustering sono forniti nel paragrafo 4.2.

CAPITOLO 4. CORRELAZIONE DEGLI ALLARMI 48 4.1.3 Correlazione La correlazione è finalizzata a trovare relazioni causali tra gli allarmi, in modo da ricostruire lo scenario dell attacco a partire dai singoli allarmi e da fornire una visione d insieme degli attacchi. Esistono vari metodi per effetuare la correlazione, che si possono suddividere nei seguenti gruppi: correlazione basata su scenario, nella quale gli allarmi sono correlati tra loro se la loro combinazione crea lo scenario dell attacco. In questa categoria rientrano lavori che usano modelli formali o tecniche di machine learning: ad esempio, Debar e Wespi [16] hanno descritto gli scenari degli attacchi attraverso regole di conseguenza, che codificano relazioni ordinate tra i tipi di attacco che sono usati per correlare gli allarmi. Dain e Cunningham [14] hanno invece usato tecniche di machine learning: allarmi generati da una rete vera sono stati raccolti ed etichettati a mano dagli autori, e queste etichette rappresentano lo scenario di attacco a cui l allarme appartiene; dopo una fase di apprendimento con questi allarmi etichettati, il sistema può correlare nuovi allarmi, anche se non può correlare scenari di attacco che non erano presenti nella fase di apprendimento; correlazione basata su regole, nella quale le relazioni tra gli allarmi sono specificate in regole. In particolare, questi metodi effettuano la correlazione tra allarmi che soddisfano dei pre-requisiti (o pre-condizioni) e delle conseguenze (o post-condizioni) delle fasi di un attacco. Gli attacchi possono essere descritti in linguaggi appositi, come JIGSAW [40] o LAMBDA [13]: in particolare, usando quest ultimo gli allarmi sono convertiti dal formato IDMEF in un insieme di eventi logici, e due allarmi sono correlati se c è un legame logico tra di essi (per esempio, se un allarme presuppone l arrivo di un secondo). Attraverso una prima fase offline si scoprono i collegamenti logici tra gli allarmi e si creano le regole per le quali un certo allarme può essere seguito da un altro; quindi, nella fase online si usano queste regole per creare gli scenari di attacco; correlazione statistica, nella quale si cercano relazioni statistiche tra gli allarmi. Qin [32]

CAPITOLO 4. CORRELAZIONE DEGLI ALLARMI 49 ha proposto un metodo che sfrutta le reti bayesiane per modellare le relazioni di causalità tra allarmi: indicando gli allarmi come nodi e le relazioni come archi, si suddividono i nodi in segmenti temporali uguali e si definisce lo stato di ogni nodo che corrisponde ad un allarme come una valore temporale che rappresenta la presenza dell allarme in quel segmento. L obiettivo è determinare quali allarmi possono causare un determinato allarme e come la probabilità condizionata di quest ultimo è legata all allarme che l ha provocato; correlazione temporale, nella quale si cercano relazioni temporali tra gli allarmi. Lee e Qin [26] hanno proposto di analizzare le relazioni di causalità tra allarmi usando il test di causalità di Granger (GCT), che verifica se la varibile di x di una serie temporale può correlare con la variabile y di un altra serie temporale effettuando un test statistico delle ipotesi. Aggregando gli allarmi che hanno caratteristiche simili, eccetto differenze temporali, si realizzano gli iper-allarmi, per i quali si costruiscono le serie temporali in base al numero di allarmi per unità temporale; con il GCT si verifica se la variabile x fornisce informazioni interessanti su y e, se è così, l allarme di tipo x può essere la causa dell allarme di tipo y. I metodi basati su scenario e su regole richiedono una conoscenza che deve essere già presente nel sistema o deve essere appresa (machine learning), mentre quelli statistici e temporali sono adatti anche a correlare allarmi sconosciuti; tuttavia, questi ultimi richiedono un tempo di elaborazione maggiore rispetto ai primi e, di solito, sono utilizzati accanto ad essi. 4.1.4 Riduzione dei falsi allarmi L obiettivo di questo componente è di ridurre i falsi allarmi, che sono riportati insieme a quelli veri. A questo scopo sono stati proposti vari metodi, tra i quali quello di Yu e Frincke [45] che si basa sulle reti di Petri colorate, introducendo le reti di Petri colorate nascoste per distinguere le azioni di un intrusore (dette transizioni) dagli allarmi (detti osservabili). Attraverso algoritmi di inferenza, si stimano quali sono le transizioni più probabili dato un insieme di osservabili, ottenendo come risultato un rapporto per l amministratore di sistema molto più sintetico di

CAPITOLO 4. CORRELAZIONE DEGLI ALLARMI 50 tutti gli allarmi analizzati. Per una panoramica sugli altri metodi atti a ridurre i falsi allarmi, come quelli basati sulla logica fuzzy, si può consultare [35]. 4.1.5 Analisi della strategia di attacco Questa fase si pone come obiettivo quello di rappresentare nella maniera più completa possibile la strategia di attacco dell intrusore, possibilmente predicendone le future intenzioni, in modo da prendere le adeguate contromisure. Fa parte di questa categoria il lavoro di Qin e Lee [33]: dopo aver correlato gli allarmi di basso livello, questi sono ulteriormente analizzati per scoprire se alcuni allarmi sono andati perduti (ad esempio perché considerati falsi positivi) e per predire possibili future azioni del malintenzionato. Si costruisce un piano degli attacchi, che raccoglie in maniera gerarchica tutti gli obiettivi ed i sotto-obiettivi dell intrusore: le foglie sono le azioni specifiche che compie, i nodi intermedi sono i sotto-obiettivi, mentre il nodo radice rappresenta il suo obiettivo finale. Per effettuare la predizione, gli alberi sono trasformati in reti bayesiane, nelle quali si calcolano le probabilità degli obiettivi e sotto-obiettivi sulla base dello stato dei loro nodi padre. A runtime, si applica il processo di inferenza alla rete per calcolare le probabilità condizionate di obiettivi e sotto-obiettivi a partire dagli allarmi registrati e dai sotto-obiettivi raggiunti. 4.1.6 Assegnamento delle priorità L assegnamento delle priorità serve a classificare gli allarmi a seconda della loro gravità e a prendere azioni adeguate per ciascun tipo di allarme. Per definire queste priorità occorre tener presenti vari fattori, quali le politiche di sicurezza, la topologia della rete, l analisi di vulnerabilità dei servizi di rete e dei software installati; è dunque necessario avere una conoscenza dell ambiente in cui si lavora. In questo ambito si colloca il lavoro di Porras et al. [31], che propongono un framework, chiamato M-Correlator, per determinare la posizione da assegnare agli allarmi e per effettuare il clustering su di essi in base a queste posizioni. L M-Correlator possiede una topologia della rete (aggiornabile tramite Nmap), che elenca i componenti della

CAPITOLO 4. CORRELAZIONE DEGLI ALLARMI 51 rete, le associazioni indirizzo IP-hostname, informazioni su tipo e versione del sistema operativo in uso, servizi TCP e UDP attivi su ogni host e hardware impiegato. La priorità degli allarmi è calcolata in base alla criticità dei componenti e dei servizi che possono essere colpiti (il valore di ogni componente deve essere stimato da un analista di sicurezza), ed in base anche alla pericolosità dell attacco. Quindi si assegna ad ogni allarme una posizione, combinando la probabilità di successo con la sua priorità. 4.2 Clustering di documenti Il clustering è una tecnica del machine learning che può essere applicata al text mining per analizzare dei documenti, estrarne gli argomenti chiave ed organizzare i documenti in base ad essi, in maniera non supervisionata. Questa tecnica si rivela utile soprattutto quando non è possibile stabilire a priori un insieme di categorie nelle quali saranno divisi i documenti, e nei casi in cui si lavori con grandi insiemi di dati, dove fatti di interesse possono facilmente nascondersi o essere persi di vista. Il clustering di documenti (quali possono essere gli allarmi generati da un IDS) si può definire come segue [17]: anzitutto occorre definire un insieme di documenti D = {D 1,..., D n }, una misura di somiglianza (o metrica) ed un criterio di partizionamento, che tipicamente si realizza tramite una funzione di costo. Il flat clustering genera una serie di cluster senza fare alcuna assunzione a priori sulla struttura dei cluster; occorre solitamente specificare in anticipo il numero di cluster desiderati, K, anche se esistono metodi che determinano in maniera adattiva la cardinalità dei cluster. Stabilito questo numero, l obiettivo è calcolare una funzione di appartenenza φ : D {1,..., K}, tale che φ minimizzi il costo di partizionamento rispetto alle somiglianze tra i documenti. Il clustering gerarchico, invece, crea gruppi strutturati su più livelli e non richiede di definire a priori il numero dei cluster, perché effettua una serie di partizionamenti annidati che producono la struttura gerarchica; questo al costo, però, di avere una minor efficienza computazionale. Nel progettare un framework di clustering, occorre tener presenti tre problematiche che si possono presentare. La prima è la maledizione della dimensionalità (curse of dimensionality), che

CAPITOLO 4. CORRELAZIONE DEGLI ALLARMI 52 sorge quando, considerando i documenti come vettori di uno spazio, si lavori in spazi con migliaia o decine di migliaia di dimensioni, che rendono l apprendimento estremamente difficile. Una possibile soluzione è la proiezione dei documenti in uno spazio con un numero di dimensioni inferiore, senza però perdere la struttura semantica dei documenti: esistono vari metodi allo scopo, tra i quali il clustering spettrale [18], il clustering che usa il latent semantic index [4, 21], il clustering che usa il locality preserving indexing [7], ciascuno con pro e contro. Un secondo problema è la definizione di una misura della somiglianza, cioè la metrica su cui si basa il clustering. Lavorando nello spazio dei vettori, si può impiegare la similarità del coseno: sim(d i, D j ) = v i v j v i v j, (4.1) dove v i è la rappresentazione vettoriale del documento D i e l operatore ( ) è il prodotto scalare definito nello spazio dei vettori. La terza problematica riguarda l algoritmo da implementare: sebbene siano molti gli algoritmi di clustering disponibili in letteratura, i più usati sono il clustering tramite k-means, le self organizing map (SOM) e l algoritmo di expectation-maximization (EM). Altri approcci si basano su tecniche di clustering fuzzy, sui document index graph (DIG) o sul modello suffix tree document (STD). 4.2.1 Clustering basato sul kernel k-means Un framework di clustering che cerca di porre un rimedio alle problematiche sin qui esposte è presentato in [17]. La fase di clustering è preceduta da una pre-elaborazione che che trasforma ogni documento in un vettore di uno spazio definito dal dizionario (o vocabolario) T = {t j ; j = 1,..., n T }: esso è una raccolta di tutti i termini che compaiono in almeno un documento del corpus (o raccolta di documenti) D = {D u ; u = 1,..., n D }. Questo framework utilizza l algoritmo kernel k-means [46], un estensione dell algoritmo k- means [27]. Il k-means convenzionale effettua un partizionamento non supervisionato dell insieme dei campioni, D = {D u ; u = 1,..., n D }, in un insieme di Z cluster, C j (j = 1,..., Z). Per tracciare la disposizione dei documenti nei cluster, si definisce un vettore di appartenenza: m u = j D u C j, m u = 0 altrimenti (u = 1,..., n D ). Un opportuna funzione di

CAPITOLO 4. CORRELAZIONE DEGLI ALLARMI 53 appartenenza definisce la relazione tra l u-esimo documento e il j-esimo cluster: 1 se m u = j δ uj = 0 altrimenti (4.2) Il numero di elementi di un cluster si può esprimere come: N j = n D u=1 mentre il centroide (o punto medio) del cluster è dato da: δ uj, j = 1,..., Z (4.3) w j = 1 n D x u δ uj, j = 1,..., Z (4.4) N j u=1 dove x u è una qualsiasi rappresentazione vettoriale di D u. La versione del k-means basata sui kernel sfrutta il fatto che una funzione Φ può mappare qualsiasi elemento D in una posizione Φ(D) di uno spazio di Hilbert ad infinite dimensioni [39]. In questo spazio, i centroidi sono dati da: Ψ j = 1 n D Φ u δ uj, j = 1,..., Z (4.5) N j u=1 Secondo [17], ciò consente di agevolare la procedura di clustering. Essa ha come obiettivo la determinazione del vettore m, per il quale occorre determinare la distanza tra l immagine Φ u del generico documento D u ed il cluster Ψ j ; essa si può calcolare come segue: 1 + 1 (N j ) 2 d(φ u, Ψ j ) = Φ u 1 N j n D m,v=1 n D v=1 Φ v 2 = (4.6) δ mj δ vj Φ m Φ v 2 n D δ vj Φ u Φ v N j A partire dall equazione 4.6 si può trovare il cluster più vicino per ogni immagine e riempire di conseguenza il vettore m. Il clustering tramite k-means può aiutare in maniera significativa non solo alla suddivisione dei documenti in gruppi, ma anche a scoprire quelli più difficili da notare; in questo senso il metodo basato sui kernel può rappresentare una strada percorribile per abbattere la maledizione della dimensionalità. v=1

Capitolo 5 Il modulo IDMEF per l ambiente SLAIR Come visto nel capitolo 2, gli analizzatori di rete atti a proteggere i sistemi informatici generano una quantità di informazione non gestibile manualmente: per questo si rende necessaria una tecnica per la correlazione automatica degli allarmi o comunque delle informazioni raccolte. Tra le varie tecniche a disposizione (ampiamente presentate nel capitolo 4), per il lavoro presentato in questa tesi si è scelto di usarne una tipicamente sfruttata nel text mining, la quale consiste nell effettuare il clustering di allarmi di basso livello per ottenere informazioni utili alla protezione del sistema monitorato. Abbiamo sfruttato un ambiente già operativo che offre le funzionalità di clustering per file testuali e lo abbiamo ampliato con un nostro modulo in grado di gestire i file prodotti dagli analizzatori di rete in formato IDMEF. 5.1 L ambiente text mining: SLAIR Il framework SLAIR (SEA Lab Advanced Information Retrieval) è un insieme di classi realizzate con lo scopo di gestire grandi quantità di documenti per finalità di clustering. Con il 54

CAPITOLO 5. IL MODULO IDMEF PER L AMBIENTE SLAIR 55 termine documenti si intente una qualsisi sorgente di dati che può fungere da vettore di informazioni. SLAIR normalizza i documenti in ingresso in una rappresentazione interna (oggetti di tipo Docum e derivati) ed applica oggetti Metric per calcolare la distanza tra coppie di documenti. Attraverso un analisi delle distribuzioni delle distanze tra insiemi (Corpus) di oggetti Docum, SLAIR effettua un clustering ed aggrega gruppi di Docum simili in oggetti Cluster. SLAIR è scritto interamente in C++ e non fa uso della meta-programmazione, soprattutto per praticità di debug; inoltre esso segue rigorose regole di stesura del codice sorgente di cui è composto. 5.1.1 La struttura Le classi e le interfacce base di cui si compone SLAIR sono: Docum raccoglie tutte le informazioni generali che riguardano un documento definito dentro SLAIR. Tutti gli oggetti Docum sono gestiti da una particolare classe DocumFactory e sono univocamente identificati da un DUID che è assegnato al momento della creazione dell oggetto. Alcune operazioni di base che devono essere definite per un Docum sono i membri Dist e Dot, che definiscono metodi per calcolare rispettivamente la distanza ed il prodotto interno rispetto ad un altro oggetto di tipo Docum; tuttavia non sempre queste funzioni sono usate, poiché sono ridefinite all interno degli oggetti Metric. La classe base Docum serve anche come riferimento per altre possibili classi da essa derivate; ObjectCreatorIF ogni oggetto significativo di SLAIR (Docum, Metric, Cluster) deve essere accompagnato da un metodo specifico che supporti la creazione delle relative istanze. La classe astratta ObjectCreatorIF, che deve essere personalizzata per ogni Docum derivato, permette l inizializzazione e la creazione degli oggetti Docum specifici; LoaderIF questa interfaccia mostra le caratteristiche che i Loader dei vari Docum devono avere. In generale un Loader deve fornire i metodi per la lettura ed acquisizione dei

CAPITOLO 5. IL MODULO IDMEF PER L AMBIENTE SLAIR 56 file da analizzare che verrano poi memorizzati in un oggetto Docum; MetricIF la classe base memorizza le informazioni che identificano l oggetto Metric associato. Una metrica è essenzialmente caratterizzata da una stringa che contiene il suo nome e da un identificatore MUID. MetricIF imposta operator(docum*, Docum*) come una funzione puramente polimorfica cosicché ogni classe metrica derivata sia costretta ad implementare un comportamento specifico. Le classi derivate da questa interfaccia sono di fondamentale importanza ai fini del clustering che il framework si propone di effettuare: infatti esse definiscono le regole base per calcolare le distanze tra coppie di oggetti di tipo Docum. 5.1.2 Funzionamento A causa della sua complessità, l ambiente SLAIR richiede un file di configurazione in cui impostare tutti i principali parametri dell applicazione; i principali sono: APPLICATION, il quale specifica il nome dell applicazione; MAX_CORPUS_SIZE, che imposta il numero massimo di documenti caricabili; CLUST_ALGORITHM, un parametro molto importante in quanto determina l algoritmo di clustering da impiegare. Esso può assumere i valori: kmeans, per usare l algoritmo kernel k-means; KDBS, per l algoritmo kernel DBScan; METRIC_NAME, che specifica il nome della metrica che l applicazione userà per calcolare le distanze fra i documenti in ingresso; OPERATING_MODE, parametro che indica il modo operativo con cui calcolare i prodotti scalari richiesti. Esso può assumere i valori: ON_THE_FLY_MODE, che impone di calcolare il prodotto scalare incondizionatamente senza far riferimento ad alcuna quantità pre-calcolata;

CAPITOLO 5. IL MODULO IDMEF PER L AMBIENTE SLAIR 57 RAM_BASED_MODE, in cui si può sfruttare una matrice pre-caricata in memoria nel calcolo del prodotto scalare; HD_BASED_MODE, simile alla modalità precedente, ma la matrice è memorizzata sul disco rigido a causa delle eccessive dimensioni; MAX_HIERARCHY_LEVELS, il quale specifica la profondità massima dell albero dei cluster che viene generato durante l esecuzione del programma; MAX_NUM_CLUSTERS, che limita i cluster generati a non essere in numero maggiore a quello specificato da questo parametro; WORKING_FOLDER, il quale determina la cartella principale dell intera applicazione; DATASET_FOLDER, che specifica il percorso relativo alla cartella che contiene il dataset da analizzare. Oltre ai parametri sopra elencati, sempre nel file di configurazione di SLAIR si possono attivare o disattivare alcuni flag relativi a caratteristiche secondarie dell esecuzione del programma, come la visualizzazione a monitor di informazioni utili al debug. Quando il file di configurazione e l applicazione stessa sono pronti ad essere usati, si può cominciare con la procedura di clustering. Anzitutto è necessario predisporre i documenti da analizzare nella cartella specificata nel file di configurazione, quindi si può avviare il programma in due modalità (fig. 5.1): create la quale crea il corpus dei documenti da zero; load che evita la generazione di un nuovo corpus ma ne utilizza uno già esistente. Dopodiché, non appena caricato il corpus sul quale lavorare, si può scegliere se caricare una matrice per il prodotto scalare pre-calcolata oppure proseguire senza; quindi si entra nella fase del clustering e viene chiesto quale tipo di clustering effettuare, flat o hierarchical (fig. 5.2). Una volta eseguito il clustering vi è la possibilità di salvare i cluster e l albero ottenuti in file specifici, e, successivamente, si può procedere con l ultima fase del programma, che è quella relativa all analisi semantica dei risultati.

CAPITOLO 5. IL MODULO IDMEF PER L AMBIENTE SLAIR 58 Figura 5.1. L avvio dell ambiente SLAIR. Figura 5.2. Le possibilità di clustering proposte da SLAIR. 5.2 Il Modulo IDMEF Per poter sfruttare l ambiente SLAIR al fine di poter effettuare il clustering di allarmi in formato IDMEF, è stato necessario aggiungere all ambiente un modulo ad hoc. Tale modulo

CAPITOLO 5. IL MODULO IDMEF PER L AMBIENTE SLAIR 59 consiste di alcune classi (scritte, come il resto del framework, in linguaggio C++) che gestiscono le operazioni di clustering dal caricamento del file fino alla creazione della struttura ad albero prodotta da SLAIR. 5.2.1 Il caricamento dei file Per caricare correttamente i dati nell ambiente di lavoro, occorre che ogni allarme sia memorizzato in un file dedicato. Poiché gli allarmi IDMEF spesso sono memorizzati in un file unico, abbiamo realizzato un piccolo programma (esterno e scollegato da SLAIR) che provvede a separare gli allarmi in singoli file. Questo programma, scritto in linguaggio C#, riceve in ingresso un file contenente gli allarmi in formato IDMEF e, dopo aver individuato i tag di apertura e chiusura di ogni allarme, provvede a creare un numero di file pari a quello degli allarmi contati e memorizza un allarme in ciascuno di essi. A questo punto il caricamento dei dati degli allarmi è gestito dalla classe LoaderIdmef e, più in particolare, dal metodo Load: esso acquisisce tutti i file presenti nelle cartelle di lavoro, controlla che rispettino il formato specificato nel file di configurazione (IDMEF nel nostro caso) e, se tale controllo è passato, crea per ogni allarme un oggetto DocumIdmef, chiamando su di esso il metodo Init. Per il caricamento vero e proprio dei file IDMEF (la cui sintassi è basata sull XML) abbiamo impiegato una libreria open source che abbiamo inglobato nel framework SLAIR, chiamata TinyXML [41]: tra le varie funzionalità che essa offre, abbiamo utilizzato quelle dedicate alla lettura e validazione di un file XML, che producono, per ogni file analizzato, una linked list che rispecchia la struttura originaria del file, comprensiva di tutti i campi e gli attributi. Grazie ai metodi offerti da TinyXML, le liste così prodotte possono essere scorse facilmente per caricare i campi d interesse per la successiva fase di clustering, e questo è risultato uno dei vantaggi maggiori nell ambito del nostro progetto.

CAPITOLO 5. IL MODULO IDMEF PER L AMBIENTE SLAIR 60 5.2.2 Il gestore dei file La gestione dei file degli allarmi avviene tramite la classe DocumIdmef: essa, che deriva dalla classe Docum, rappresenta un file in formato IDMEF e permette di elaborarlo successivamente all interno di SLAIR. I principali metodi di questa classe sono elencati di seguito: Init, che carica il file IDMEF attraverso le funzioni fornite dalla libreria TinyXML, producendo un oggetto di tipo TiXmlDocument; quindi, chiama il metodo LoadValues che legge da questo oggetto i campi di interesse e li memorizza in un oggetto di tipo DocumIdmef; LoadValues, che si occupa di memorizzare all interno di un oggetto DocumIdmef i campi dell allarme IDMEF che saranno necessari per la successiva fase di clustering. In particolare, per ogni allarme sono caricati i seguenti campi: date, la data in cui è stato registrato l attacco (giorno, mese, anno); time, l orario al quale è stato registrato l allarme (ore, minuti, secondi); sessionduration, la durata della registrazione; source_address, l indirizzo IP dal quale proviene l attacco; target_address, l indirizzo IP verso il quale è diretto l attacco; service_name, il servizio che è coinvolto nell attacco; service_source_port, la porta del servizio dalla quale è partito l attacco; service_destination_port, la porta del servizio alla quale è diretto l attacco. Inoltre, la classe DocumIdmef è dotata dei metodi Dot e Dist: il primo calcola il prodotto scalare tra l oggetto su cui è chiamato e quello che è passato per argomento, mentre il secondo calcola una distanza ibrida tra l oggetto su cui è chiamato e quello che è passato per argomento. L oggetto DocumIdmef è creato e gestito dalla classe ObjectCreator (che implementa l interfaccia ObjectCreatorIF): essa si occupa anche della creazione dell oggetto che rappresenta

CAPITOLO 5. IL MODULO IDMEF PER L AMBIENTE SLAIR 61 la metrica da usare per il clustering (oggetto di tipo MetricIdmef), della sua registrazione all interno dell applicazione e dell inizializzazione del ClusterBuilder. 5.2.3 La metrica L oggetto DocumIdmef così creato è pronto per la fase di clustering. In questa fase su tutti i documenti appartenenti al corpus è chiamato l operatore () ( parentesi tonde ) della classe MetricIdmef (che implementa l interfaccia MetricIF), il quale è stato opportunamente sovraccaricato. Questo operatore rappresenta il nucleo della fase di clustering, poiché permette di calcolare le distanze tra i documenti, sulla base delle quali si realizza successivamente la suddivisione in cluster. Tra gli attributi che vengono caricati dal metodo LoadValues della classe DocumIdmef, abbiamo scelto di utilizzare per la nostra metrica solo un sottoinsieme di questi; in particolare abbiamo preso in considerazione: date, time e source_address. Ci siamo focalizzati su questi dati perché li consideriamo i più significativi al fine di effettuare una semplice correlazione degli allarmi (per maggiori dettagli su questa scelta si può vedere anche il paragrafo 7.2). Per la realizzazione di questa metrica non abbiamo fatto considerazioni strettamente geometriche, ma data la natura dei dati del nostro lavoro abbiamo sviluppato una metrica empirica che certamente risulta essere più incline a trattare questi dati. Per giungere al calcolo della distanza fra due documenti facciamo uso di numerose istruzioni condizionali necessarie per discriminare i vari casi che abbiamo in ingresso. La metrica si compone di due aspetti: uno che tiene conto dell istante nel quale viene registrato l allarme e l altro che riguarda l indirizzo IP dal quale proviene la minaccia. Nel primo caso la distanza viene calcolata considerando prima di tutto la data nella quale viene registrato l allarme: se i due allarmi si sono verificati in giorni diversi, la distanza viene impostata al valore massimo (1), altrimenti si passa a considerare gli orari di registrazione degli allarmi e la distanza ritornata è un valore proporzionale alla differenza tra gli orari stessi (compreso tra 0 e 1). A questo punto si analizzano gli indirizzi IP sorgenti con i quali si conclude il calcolo della distanza. La nostra strategia nel calcolare la distanza tra due indirizzi IP parte col considerare

CAPITOLO 5. IL MODULO IDMEF PER L AMBIENTE SLAIR 62 che due indirizzi hanno distanza minima solo quando sono identici, mentre se differiscono anche solo per qualche cifra bisogna valutare l appartenenza o meno ad una stessa sottorete. Meno sono gli ottetti in comune fra i due indirizzi, maggiore sarà la distanza fra gli stessi: in particolare se i primi tre ottetti sono in comune, allora consideriamo che i due indirizzi facciano parte di una stessa sottorete, quindi la distanza calcolata sarà breve; se invece il numero degli ottetti in comune è inferiore, allora la differenza pesata tra i vari ottetti dei due IP produrrà un valore di distanza molto elevato (in ogni caso compreso tra 0 e 1). Le distanze così ottenute successivamente devono essere unificate per poter rappresentare la distanza definitiva tra i due documenti IDMEF originari: prima di tutto le distanze vengono sommate tra loro poi si divide il risultato per due in modo da ottenere sempre un valore normalizzato (ovvero compreso tra 0 e 1). E importante far notare che nel calcolo della distanza si è data uguale importanza ai due contributi che compongono il valore finale: questa scelta è stata dettata dalla mancanza di conoscenza a priori che potesse dar maggior peso ad uno dei due. 5.2.4 Il clustering La metrica definita come nel paragrafo precedente permette all ambiente SLAIR di clusterizzare i dati in ingresso seguendo la logica dell algoritmo impostato nel file di configurazione di SLAIR (kernel k-means nel nostro caso, illustrato nel paragrafo 4.2.1). Il processo di clustering porta alla produzione di un file di output in cui è rappresentato l albero gerarchico dei cluster calcolati. Il suddetto file, però, non dà una visione completa della situazione: infatti esso mostra semplicemente la dimensione e la numerosità dei cluster ottenuti con i relativi collegamenti gerarchici, mentre non rappresenta in alcun modo il contenuto qualitativo dei cluster stessi. Sulla scorta del problema evidenziato in queste prime righe, abbiamo elaborato una classe che aggiungesse informazioni di carattere qualitativo all albero prodotto in fase di clustering e che, quindi, permettesse ad un ipotetico utente finale una comprensione migliore della realtà degli allarmi ispezionati. Tale classe si chiama ClusterPartIdmef: essa permette di as-

CAPITOLO 5. IL MODULO IDMEF PER L AMBIENTE SLAIR 63 segnare i nomi ai cluster sulla base degli elementi contenuti. I metodi più significativi che compongono la suddetta classe sono: Set_ClusterName, che è chiamato dopo la fase di clustering per ogni cluster appartenente all albero generato. Esso scorre in maniera ricorsiva tutto l albero arrivando fino alle foglie, poi per tutti gli elementi foglia effettua una chiamata alla funzione CreateClusterName, la quale ritorna un nome adatto per il cluster analizzato. Dopo aver assegnato i nomi a tutti i cluster foglia di uno specifico ramo, la ricorsione incomincia il suo percorso a ritroso verso la radice e vengono assegnati i nomi per i cluster intermedi sulla base dei nomi dei nodi figli. La nostra logica di assegnamento dei nomi è molto semplice: essa prevede che i cluster siano nominati con il nome dell elemento più frequente all interno di essi: ciò comporta che alla fine della ricorsione si otterrà un albero gerarchico in cui gli attacchi più frequenti daranno i nomi ai nodi posizionati al vertice dell albero stesso. Abbiamo deciso di nominare ogni attacco con l indirizzo IP sorgente che lo caratterizza e con il numero della frequenza dell attacco stesso, quindi l albero così ottenuto offre delle informazioni non banali sulla provenienza degli attacchi registrati all interno della rete; CreateClusterName, che è il metodo che viene chiamato sui nodi foglia dell albero gerarchico ed assegna il nome a questi cluster sulla base dell elemento più frequente contenuto. Il nome è caratterizzato dall indirizzo IP sorgente dell attacco seguito dal numero degli attacchi di quel tipo contati all interno del cluster. Questo metodo viene chiamato dal metodo sopra descritto Set_ClusterName.

Capitolo 6 Risultati Dopo la fase di progettazione e sviluppo del nostro modulo per l ambiente SLAIR, siamo passati alla verifica della consistenza del lavoro realizzato. Siamo partiti con l obiettivo di creare uno strumento aggiuntivo per SLAIR che potesse gestire file di tipo IDMEF e su di essi potesse effettuare clustering seguendo l approccio comune a tutto il framework, che è quello tipico del text mining. 6.1 Verifica del funzionamento del modulo La fase di verifica è iniziata con la validazione delle classi relative all acquisizione dei dati di input ed è composta di due parti: come primo step abbiamo dovuto cercare una fonte di dati da cui prelevare quelli che avremmo utilizzato per verificare il funzionamento delle caratteristiche del nostro modulo. Questa ricerca è stata piuttosto difficile a causa della scarsa diffusione del formato IDMEF per la generazione di log di allarmi (su questo aspetto vedi anche il paragrafo 7.2) e per la mancata aderenza di vari dataset ai requisisti proposti dal formato IDMEF. Si è quindi operato a scartare i dataset non conformi alle nostre esigenze ed alla fine per esclusione siamo rimasti con un solo dataset utilizzabile. Quello che abbiamo scelto di utilizzare per i nostri test proviene dal Lincoln Laboratory del Massachusetts Institute 64

CAPITOLO 6. RISULTATI 65 of Technology (MIT) [1] ed è stato utilizzato dal laboratorio stesso per effettuare delle ricerche sugli intrusion detection system in collaborazione con l Air Force Research Laboratory (AFRL/SNHS) e con la Defense Advanced Research Projects Agency (DARPA ITO); successivamente è stato pubblicato per renderne libero l utilizzo. Tale dataset è contenuto in un singolo file di tipo XML e raggruppa 25000 allarmi in formato IDMEF: per prima cosa abbiamo dovuto scindere i vari allarmi in singoli file per poterli poi caricare dentro SLAIR (v. paragrafo 5.2.1); con il secondo step abbiamo verificato che le classi da noi realizzate acquisissero in modo corretto i file del dataset. Abbiamo quindi creato una cartella contenente tutti gli allarmi IDMEF e l abbiamo inserita anche nel file di configurazione di SLAIR (alla voce DATASET_FOLDER); successivamente abbiamo lanciato il programma verificando che il sistema caricasse in memoria tutti i file del dataset. Per completezza bisognava ancora verificare che il contenuto dei dati caricati fosse effettivamente identico a quello dei file di input: per far questo abbiamo chiamato le funzioni di dump di SLAIR su alcuni dati scelti a campione sui 25000 caricati, tra cui necessariamente il primo file caricato e l ultimo. In questo modo abbiamo constatato effettivamente l uguaglianza tra la due rappresentazioni del dataset e quindi verificato il funzionamento delle classi relative all acquisizione dei dati. Un esempio del caricamento di un file IDMEF è illustrato in figura 6.1. Dopo la verifica dell acquisizione dei dati, si è proceduto con la validazione delle classi relative al clustering vero e proprio. Abbiamo effettuato il clustering gerarchico sui dati a nostra disposizione ed abbiamo analizzato l output generato, controllando per prima cosa che fosse creata una struttura ad albero con un numero di elementi pari a quello degli allarmi caricati. Successivamente si è cercato di interpretare come il motore di clustering di SLAIR avesse realmente diviso gli allarmi nei vari cluster e se rispettava la logica da noi implementata nella metrica relativa al formato IDMEF. Non avendo altri strumenti a disposizione, si è proceduto con un controllo manuale degli elementi dei cluster; tuttavia, questo non ha portato a risultati interessanti, poiché l elevato numero di elementi per ogni cluster rendeva difficile trovare le

CAPITOLO 6. RISULTATI 66 Figura 6.1. Il dump del primo file IDMEF caricato. relazioni tra gli elementi stessi. A questo punto si è reso necessario introdurre una tecnica automatica per trovare questo tipo di relazioni, che avrebbe permesso di verificare il corretto funzionamento del clustering. La soluzione che abbiamo realizzato prevede di effettuare una etichettatura dei cluster, ovvero di assegnare loro un nome significativo che renda immediatamente chiare le caratteristiche degli allarmi contenuti: nel nostro caso si è scelto di usare nomi costituiti dall indirizzo IP sorgente più frequente tra gli elementi di uno stesso cluster seguito dal numero di elementi con questi indirizzi, in modo da rispecchiare le caratteristiche della metrica adottata. Grazie a questa aggiunta si è verificato che gli allarmi erano stati effettivamente suddivisi in base all indirizzo IP più frequente ed in particolare si notava che, salendo verso il nodo radice dell albero, i nomi dei nodi intermedi contenevano gli indirizzi che popolavano maggiormente i cluster figli. Tramite l aggiunta di output di debug è stato possibile controllare che gli allarmi simili (ad esempio perché accomunati da indirizzi sorgen-

CAPITOLO 6. RISULTATI 67 te appartenenti ad una stessa sottorete) fossero stati effettivamente raggruppati negli stessi cluster e questa è stata la conferma ricercata. 6.2 La suddivisione in cluster Come detto in precedenza, il risultato finale prodotto da SLAIR è una struttura ad albero i cui nodi foglia rappresentano i cluster generati in base ai dati in ingresso al programma e alla metrica realizzata, mentre i nodi di livello intermedio rappresentano aggregazioni dei nodi foglia. Il risultato che si riporta di seguito è l albero prodotto da SLAIR utilizzando come ingresso l intero dataset utilizzato (25000 file IDMEF). Da notare che i risultati ottenuti sono dipendenti dai parametri contenuti nel file di configurazione del framework relativi al motore di clustering; in particolare per i parametri più significativi si sono scelti i seguenti valori: MAX_HIERARCHY_LEVELS = 2 HIERARCHY_ARK = 2 128 4 BRANCHING_FACTOR = 4. La variazione di questi valori può influire anche significativamente sul risultato finale, ma quelli scelti si sono dimostrati adeguati al dataset a nostra disposizione (sulla scelta del valore ottimo di questi parametri, si veda anche il paragrafo 7.2). [ 0-1] - 37.199.124.103 240 (0/ 25000) [ 1-2] - 47.156.201.199 195 (0/ 195) [ 1-3] - 82.10.11.167 173 (0/ 173) [ 1-4] - 57.40.94.249 209 (0/ 409) [ 2-84] - 57.40.94.249 209 (0/ 209) [ 2-85] - 115.82.237.159 200 (0/ 200) [ 1-5] - 52.238.12.164 204 (0/ 766) [ 2-86] - 30.243.63.184 181 (0/ 181) [ 2-87] - 52.238.12.164 204 (0/ 204) [ 2-88] - 31.226.32.179 192 (0/ 381) [ 1-6] - 18.152.138.12 197 (0/ 197) [ 1-7] - 9.10.87.111 199 (0/ 387) [ 2-90] - 9.10.87.111 199 (0/ 199) [ 2-91] - 10.209.221.106 188 (0/ 188) [ 1-8] - 1.245.156.51 202 (0/ 202) [ 1-9] - 55.46.15.110 196 (0/ 196)

CAPITOLO 6. RISULTATI 68 [ 1-10] - 64.77.235.224 195 (0/ 378) [ 2-94] - 65.33.63.180 183 (0/ 183) [ 2-95] - 64.77.235.224 195 (0/ 195) [ 1-11] - 37.199.124.103 240 (0/ 431) [ 2-96] - 84.68.1.51 191 (0/ 191) [ 2-97] - 37.199.124.103 240 (0/ 240) [ 1-12] - 38.208.63.124 194 (0/ 194) [ 1-13] - 72.56.119.244 190 (0/ 190) [ 1-14] - 111.176.229.174 205 (0/ 205) [ 1-15] - 32.129.42.239 193 (0/ 193) [ 1-16] - 77.172.146.181 194 (0/ 383) [ 2-102] - 77.172.146.181 194 (0/ 194) [ 2-103] - 110.9.70.195 189 (0/ 189) [ 1-17] - 123.150.109.164 172 (0/ 172) [ 1-18] - 124.244.239.27 202 (0/ 393) [ 2-105] - 125.82.202.110 191 (0/ 191) [ 2-106] - 124.244.239.27 202 (0/ 202) [ 1-19] - 75.128.214.172 205 (0/ 205) [ 1-20] - 56.190.174.97 189 (0/ 362) [ 2-108] - 62.113.178.106 173 (0/ 173) [ 2-109] - 56.190.174.97 189 (0/ 189) [ 1-21] - 11.249.58.25 226 (0/ 417) [ 2-110] - 11.249.58.25 226 (0/ 226) [ 2-111] - 17.187.204.215 191 (0/ 191) [ 1-22] - 61.112.189.10 191 (0/ 379) [ 2-112] - 85.104.78.132 188 (0/ 188) [ 2-113] - 61.112.189.10 191 (0/ 191) [ 1-23] - 26.243.182.181 166 (0/ 166) [ 1-24] - 69.109.78.88 201 (0/ 201) [ 1-25] - 41.55.233.106 200 (0/ 384) [ 2-116] - 121.227.224.231 184 (0/ 184) [ 2-117] - 41.55.233.106 200 (0/ 200) [ 1-26] - 92.130.183.178 193 (0/ 193) [ 1-27] - 109.49.142.210 203 (0/ 203) [ 1-28] - 48.107.216.11 217 (0/ 217) [ 1-29] - 60.243.52.64 207 (0/ 409) [ 2-121] - 60.243.52.64 207 (0/ 207) [ 2-122] - 22.129.37.43 202 (0/ 202) [ 1-30] - 59.17.127.15 156 (0/ 156) [ 1-31] - 16.123.190.17 218 (0/ 825) [ 2-124] - 16.123.190.17 218 (0/ 411) [ 2-125] - 15.242.211.247 202 (0/ 202) [ 2-126] - 24.68.179.37 212 (0/ 212) [ 1-32] - 73.185.20.90 207 (0/ 412) [ 2-127] - 73.185.20.90 207 (0/ 207) [ 2-128] - 74.152.32.111 205 (0/ 205) [ 1-33] - 91.101.82.230 209 (0/ 380) [ 2-129] - 36.90.106.101 171 (0/ 171) [ 2-130] - 91.101.82.230 209 (0/ 209) [ 1-34] - 23.232.137.12 202 (0/ 383) [ 2-131] - 23.232.137.12 202 (0/ 202) [ 2-132] - 70.138.218.60 181 (0/ 181) [ 1-35] - 0.219.40.153 200 (0/ 200) [ 1-36] - 113.130.222.122 205 (0/ 594) [ 2-134] - 34.237.134.90 194 (0/ 194) [ 2-135] - 113.130.222.122 205 (0/ 205) [ 2-136] - 112.26.133.125 195 (0/ 195) [ 1-37] - 122.86.31.88 187 (0/ 187) [ 1-38] - 76.171.38.102 209 (0/ 209) [ 1-39] - 50.126.9.35 197 (0/ 566) [ 2-139] - 98.193.34.185 178 (0/ 178) [ 2-140] - 50.126.9.35 197 (0/ 197) [ 2-141] - 97.4.24.55 191 (0/ 191) [ 1-40] - 49.64.29.3 188 (0/ 370)

CAPITOLO 6. RISULTATI 69 [ 2-142] - 49.64.29.3 188 (0/ 188) [ 2-143] - 51.30.92.189 182 (0/ 182) [ 1-41] - 6.145.142.55 203 (0/ 379) [ 2-144] - 6.145.142.55 203 (0/ 203) [ 2-145] - 46.5.191.112 176 (0/ 176) [ 1-42] - 42.31.25.206 197 (0/ 197) [ 1-43] - 66.217.122.187 184 (0/ 184) [ 1-44] - 58.64.21.54 184 (0/ 184) [ 1-45] - 88.175.209.16 184 (0/ 184) [ 1-46] - 100.10.209.160 200 (0/ 200) [ 1-47] - 5.43.78.50 204 (0/ 384) [ 2-151] - 5.43.78.50 204 (0/ 204) [ 2-152] - 53.233.108.46 180 (0/ 180) [ 1-48] - 127.170.13.55 198 (0/ 379) [ 2-153] - 127.170.13.55 198 (0/ 198) [ 2-154] - 12.248.22.12 181 (0/ 181) [ 1-49] - 83.92.231.9 180 (0/ 180) [ 1-50] - 117.167.32.134 211 (0/ 413) [ 2-156] - 118.176.47.16 202 (0/ 202) [ 2-157] - 117.167.32.134 211 (0/ 211) [ 1-51] - 79.213.165.82 212 (0/ 404) [ 2-158] - 79.213.165.82 212 (0/ 212) [ 2-159] - 104.38.70.209 192 (0/ 192) [ 1-52] - 67.203.108.202 196 (0/ 196) [ 1-53] - 96.210.67.159 198 (0/ 198) [ 1-54] - 33.89.106.141 187 (0/ 187) [ 1-55] - 35.137.4.163 211 (0/ 211) [ 1-56] - 81.119.74.88 207 (0/ 805) [ 2-164] - 27.227.14.45 203 (0/ 203) [ 2-165] - 14.246.188.182 199 (0/ 395) [ 2-166] - 81.119.74.88 207 (0/ 207) [ 1-57] - 54.215.21.39 205 (0/ 595) [ 2-167] - 39.223.10.104 200 (0/ 200) [ 2-168] - 54.215.21.39 205 (0/ 205) [ 2-169] - 40.176.237.232 190 (0/ 190) [ 1-58] - 19.41.69.132 186 (0/ 352) [ 2-170] - 71.76.19.185 166 (0/ 166) [ 2-171] - 19.41.69.132 186 (0/ 186) [ 1-59] - 102.94.110.175 219 (0/ 219) [ 1-60] - 93.103.142.186 197 (0/ 369) [ 2-173] - 93.103.142.186 197 (0/ 197) [ 2-174] - 114.20.145.233 172 (0/ 172) [ 1-61] - 108.167.155.49 197 (0/ 385) [ 2-175] - 107.37.119.3 188 (0/ 188) [ 2-176] - 108.167.155.49 197 (0/ 197) [ 1-62] - 68.132.223.41 213 (0/ 213) [ 1-63] - 45.197.3.61 208 (0/ 208) [ 1-64] - 99.60.251.106 217 (0/ 387) [ 2-179] - 99.60.251.106 217 (0/ 217) [ 2-180] - 8.182.85.235 170 (0/ 170) [ 1-65] - 3.222.81.232 202 (0/ 584) [ 2-181] - 2.159.254.233 193 (0/ 193) [ 2-182] - 29.208.16.27 189 (0/ 189) [ 2-183] - 3.222.81.232 202 (0/ 202) [ 1-66] - 103.41.111.171 177 (0/ 177) [ 1-67] - 80.154.2.142 211 (0/ 406) [ 2-185] - 116.168.99.36 195 (0/ 195) [ 2-186] - 80.154.2.142 211 (0/ 211) [ 1-68] - 7.199.251.171 203 (0/ 203) [ 1-69] - 119.118.110.103 170 (0/ 170) [ 1-70] - 87.187.107.67 202 (0/ 394) [ 2-189] - 87.187.107.67 202 (0/ 202) [ 2-190] - 90.103.169.122 192 (0/ 192) [ 1-71] - 120.222.71.135 193 (0/ 193)

CAPITOLO 6. RISULTATI 70 [ 1-72] - 78.254.250.194 177 (0/ 177) [ 1-73] - 95.122.184.211 197 (0/ 197) [ 1-74] - 106.104.123.252 214 (0/ 587) [ 2-194] - 44.231.20.124 178 (0/ 178) [ 2-195] - 106.104.123.252 214 (0/ 409) [ 1-75] - 21.226.1.228 226 (0/ 433) [ 2-196] - 21.226.1.228 226 (0/ 226) [ 2-197] - 20.208.30.183 207 (0/ 207) [ 1-76] - 63.224.105.19 200 (0/ 200) [ 1-77] - 126.48.178.31 206 (0/ 206) [ 1-78] - 25.148.14.200 188 (0/ 188) [ 1-79] - 4.86.169.8 189 (0/ 189) [ 1-80] - 94.37.246.14 220 (0/ 604) [ 2-202] - 94.37.246.14 220 (0/ 220) [ 2-203] - 101.181.81.199 184 (0/ 184) [ 2-204] - 89.62.109.91 200 (0/ 200) [ 1-81] - 86.216.115.136 197 (0/ 197) L albero sopra riportato ha una profondità massima di 2 livelli; il nome del cluster di livello 0 rappresenta l allarme il cui indirizzo IP è il più frequente tra tutti (in termini di attacco, questo indirizzo è quello da cui proviene la maggioranza degli attacchi). Si può inoltre notare che i cluster che si fermano al livello 1 sono quelli che raggruppano perfettamente gli allarmi provenienti da una stessa sorgente: infatti il numero degli elementi di tali cluster è uguale alla frequenza dell elemento più comune contenuto. I rami che arrivano al livello 2 sono quelli che mostrano delle imperfezioni, comunque limitate, della fase di clustering. Nel complesso il risultato ottenuto è buono, poiché ispezionando manualmente il contenuto dei cluster si verifica che circa l 84% di essi raggruppa correttamente gli allarmi, inserendo in uno stesso cluster quelli che hanno indirizzo IP sorgente più vicino (ovvero appartenenti alla stessa sottorete). Un ulteriore verifica del nostro modulo prevedeva di utilizzare allarmi completamente scorrelati tra loro, ovvero con indirizzi IP sorgente diversi l uno dall altro: si tratta di un dataset da 254 elementi costruito appositamente da noi per verificare che il nostro modulo creasse un numero di cluster (nodi foglia) pari all incirca al numero di allarmi in ingresso. Si sono utilizzati i seguenti valori per i parametri di SLAIR: MAX_HIERARCHY_LEVELS = 1 HIERARCHY_ARK = 1 10000 BRANCHING_FACTOR = 1.

CAPITOLO 6. RISULTATI 71 Da notare che HIERARCHY_ARK è stato impostato a 10000 per garantire che il motore di clustering generasse il maggior numero di cluster possibili (sarebbe comunque bastato un qualsiasi numero molto maggiore delle dimensioni del dataset). Di seguito si riporta l albero ottenuto. [ 0-1] - 22.22.22.22 1 (0/ 254) [ 1-2] - 202.202.202.202 1 (0/ 1) [ 1-3] - 13.13.13.13 1 (0/ 1) [ 1-4] - 212.212.212.212 1 (0/ 1) [ 1-5] - 38.38.38.38 1 (0/ 1) [ 1-6] - 240.240.240.240 1 (0/ 1) [ 1-7] - 150.150.150.150 1 (0/ 1) [ 1-8] - 72.72.72.72 1 (0/ 1) [ 1-9] - 24.24.24.24 1 (0/ 1) [ 1-10] - 47.47.47.47 1 (0/ 1) [ 1-11] - 136.136.136.136 1 (0/ 1) [ 1-12] - 228.228.228.228 1 (0/ 1) [ 1-13] - 117.117.117.117 1 (0/ 1) [ 1-14] - 225.225.225.225 1 (0/ 1) [ 1-15] - 16.16.16.16 1 (0/ 1) [ 1-16] - 249.249.249.249 1 (0/ 1) [ 1-17] - 37.37.37.37 1 (0/ 1) [ 1-18] - 204.204.204.204 1 (0/ 1) [ 1-19] - 35.35.35.35 1 (0/ 1) [ 1-20] - 201.201.201.201 1 (0/ 1) [ 1-21] - 110.110.110.110 1 (0/ 1) [ 1-22] - 78.78.78.78 1 (0/ 1) [ 1-23] - 152.152.152.152 1 (0/ 1) [ 1-24] - 194.194.194.194 1 (0/ 1) [ 1-25] - 184.184.184.184 1 (0/ 1) [ 1-26] - 114.114.114.114 1 (0/ 1) [ 1-27] - 10.10.10.10 1 (0/ 1) [ 1-28] - 58.58.58.58 1 (0/ 1) [ 1-29] - 155.155.155.155 1 (0/ 1) [ 1-30] - 222.222.222.222 1 (0/ 1) [ 1-31] - 65.65.65.65 1 (0/ 1) [ 1-32] - 23.23.23.23 1 (0/ 1) [ 1-33] - 176.176.176.176 1 (0/ 1) [ 1-34] - 15.15.15.15 1 (0/ 1) [ 1-35] - 70.70.70.70 1 (0/ 1) [ 1-36] - 76.76.76.76 1 (0/ 1) [ 1-37] - 160.160.160.160 1 (0/ 1) [ 1-38] - 159.159.159.159 1 (0/ 1) [ 1-39] - 39.39.39.39 1 (0/ 1) [ 1-40] - 60.60.60.60 1 (0/ 1) [ 1-41] - 188.188.188.188 1 (0/ 1) [ 1-42] - 49.49.49.49 1 (0/ 1) [ 1-43] - 99.99.99.99 1 (0/ 1) [ 1-44] - 137.137.137.137 1 (0/ 1) [ 1-45] - 51.51.51.51 1 (0/ 1) [ 1-46] - 133.133.133.133 1 (0/ 1) [ 1-47] - 12.12.12.12 1 (0/ 1) [ 1-48] - 205.205.205.205 1 (0/ 1) [ 1-49] - 145.145.145.145 1 (0/ 1) [ 1-50] - 186.186.186.186 1 (0/ 1) [ 1-51] - 170.170.170.170 1 (0/ 1) [ 1-52] - 50.50.50.50 1 (0/ 1) [ 1-53] - 177.177.177.177 1 (0/ 1)

CAPITOLO 6. RISULTATI 72 [ 1-54] - 174.174.174.174 1 (0/ 1) [ 1-55] - 126.126.126.126 1 (0/ 1) [ 1-56] - 62.62.62.62 1 (0/ 1) [ 1-57] - 211.211.211.211 1 (0/ 1) [ 1-58] - 210.210.210.210 1 (0/ 1) [ 1-59] - 84.84.84.84 1 (0/ 1) [ 1-60] - 86.86.86.86 1 (0/ 1) [ 1-61] - 143.143.143.143 1 (0/ 1) [ 1-62] - 67.67.67.67 1 (0/ 1) [ 1-63] - 139.139.139.139 1 (0/ 1) [ 1-64] - 11.11.11.11 1 (0/ 1) [ 1-65] - 189.189.189.189 1 (0/ 1) [ 1-66] - 127.127.127.127 1 (0/ 1) [ 1-67] - 179.179.179.179 1 (0/ 1) [ 1-68] - 193.193.193.193 1 (0/ 1) [ 1-69] - 31.31.31.31 1 (0/ 1) [ 1-70] - 138.138.138.138 1 (0/ 1) [ 1-71] - 18.18.18.18 1 (0/ 1) [ 1-72] - 57.57.57.57 1 (0/ 1) [ 1-73] - 83.83.83.83 1 (0/ 1) [ 1-74] - 63.63.63.63 1 (0/ 1) [ 1-75] - 44.44.44.44 1 (0/ 1) [ 1-76] - 87.87.87.87 1 (0/ 1) [ 1-77] - 45.45.45.45 1 (0/ 1) [ 1-78] - 88.88.88.88 1 (0/ 1) [ 1-79] - 102.102.102.102 1 (0/ 1) [ 1-80] - 34.34.34.34 1 (0/ 1) [ 1-81] - 122.122.122.122 1 (0/ 1) [ 1-82] - 71.71.71.71 1 (0/ 1) [ 1-83] - 121.121.121.121 1 (0/ 1) [ 1-84] - 54.54.54.54 1 (0/ 1) [ 1-85] - 196.196.196.196 1 (0/ 1) [ 1-86] - 178.178.178.178 1 (0/ 1) [ 1-87] - 243.243.243.243 1 (0/ 1) [ 1-88] - 154.154.154.154 1 (0/ 1) [ 1-89] - 66.66.66.66 1 (0/ 1) [ 1-90] - 46.46.46.46 1 (0/ 1) [ 1-91] - 235.235.235.235 1 (0/ 1) [ 1-92] - 231.231.231.231 1 (0/ 1) [ 1-93] - 6.6.6.6 1 (0/ 1) [ 1-94] - 164.164.164.164 1 (0/ 1) [ 1-95] - 79.79.79.79 1 (0/ 1) [ 1-96] - 101.101.101.101 1 (0/ 1) [ 1-97] - 103.103.103.103 1 (0/ 1) [ 1-98] - 90.90.90.90 1 (0/ 2) [ 1-99] - 214.214.214.214 1 (0/ 1) [ 1-100] - 96.96.96.96 1 (0/ 1) [ 1-101] - 17.17.17.17 1 (0/ 1) [ 1-102] - 153.153.153.153 1 (0/ 1) [ 1-103] - 168.168.168.168 1 (0/ 1) [ 1-104] - 213.213.213.213 1 (0/ 1) [ 1-105] - 115.115.115.115 1 (0/ 1) [ 1-106] - 111.111.111.111 1 (0/ 1) [ 1-107] - 173.173.173.173 1 (0/ 1) [ 1-108] - 215.215.215.215 1 (0/ 1) [ 1-109] - 236.236.236.236 1 (0/ 1) [ 1-110] - 229.229.229.229 1 (0/ 1) [ 1-111] - 8.8.8.8 1 (0/ 1) [ 1-112] - 14.14.14.14 1 (0/ 1) [ 1-113] - 199.199.199.199 1 (0/ 1) [ 1-114] - 119.119.119.119 1 (0/ 1) [ 1-115] - 207.207.207.207 1 (0/ 1) [ 1-116] - 20.20.20.20 1 (0/ 1) [ 1-117] - 7.7.7.7 1 (0/ 1)

CAPITOLO 6. RISULTATI 73 [ 1-118] - 106.106.106.106 1 (0/ 1) [ 1-119] - 230.230.230.230 1 (0/ 1) [ 1-120] - 5.5.5.5 1 (0/ 1) [ 1-121] - 105.105.105.105 1 (0/ 1) [ 1-122] - 26.26.26.26 1 (0/ 1) [ 1-123] - 141.141.141.141 1 (0/ 1) [ 1-124] - 98.98.98.98 1 (0/ 1) [ 1-125] - 149.149.149.149 1 (0/ 1) [ 1-126] - 203.203.203.203 1 (0/ 1) [ 1-127] - 64.64.64.64 1 (0/ 1) [ 1-128] - 254.254.254.254 1 (0/ 1) [ 1-129] - 156.156.156.156 1 (0/ 1) [ 1-130] - 129.129.129.129 1 (0/ 1) [ 1-131] - 241.241.241.241 1 (0/ 1) [ 1-132] - 220.220.220.220 1 (0/ 1) [ 1-133] - 197.197.197.197 1 (0/ 1) [ 1-134] - 172.172.172.172 1 (0/ 1) [ 1-135] - 112.112.112.112 1 (0/ 1) [ 1-136] - 48.48.48.48 1 (0/ 1) [ 1-137] - 69.69.69.69 1 (0/ 1) [ 1-138] - 209.209.209.209 1 (0/ 1) [ 1-139] - 113.113.113.113 1 (0/ 1) [ 1-140] - 89.89.89.89 1 (0/ 1) [ 1-141] - 234.234.234.234 1 (0/ 1) [ 1-142] - 226.226.226.226 1 (0/ 1) [ 1-143] - 52.52.52.52 1 (0/ 1) [ 1-144] - 148.148.148.148 1 (0/ 1) [ 1-145] - 56.56.56.56 1 (0/ 1) [ 1-146] - 166.166.166.166 1 (0/ 1) [ 1-147] - 73.73.73.73 1 (0/ 1) [ 1-148] - 198.198.198.198 1 (0/ 1) [ 1-149] - 183.183.183.183 1 (0/ 1) [ 1-150] - 191.191.191.191 1 (0/ 1) [ 1-151] - 169.169.169.169 1 (0/ 1) [ 1-152] - 19.19.19.19 1 (0/ 1) [ 1-153] - 3.3.3.3 1 (0/ 1) [ 1-154] - 250.250.250.250 1 (0/ 1) [ 1-155] - 142.142.142.142 1 (0/ 1) [ 1-156] - 27.27.27.27 1 (0/ 1) [ 1-157] - 134.134.134.134 1 (0/ 1) [ 1-158] - 238.238.238.238 1 (0/ 1) [ 1-159] - 108.108.108.108 1 (0/ 1) [ 1-160] - 4.4.4.4 1 (0/ 1) [ 1-161] - 107.107.107.107 1 (0/ 1) [ 1-162] - 61.61.61.61 1 (0/ 1) [ 1-163] - 190.190.190.190 1 (0/ 1) [ 1-164] - 97.97.97.97 1 (0/ 1) [ 1-165] - 218.218.218.218 1 (0/ 1) [ 1-166] - 147.147.147.147 1 (0/ 1) [ 1-167] - 187.187.187.187 1 (0/ 1) [ 1-168] - 95.95.95.95 1 (0/ 1) [ 1-169] - 30.30.30.30 1 (0/ 1) [ 1-170] - 124.124.124.124 1 (0/ 1) [ 1-171] - 28.28.28.28 1 (0/ 1) [ 1-172] - 151.151.151.151 1 (0/ 1) [ 1-173] - 132.132.132.132 1 (0/ 1) [ 1-174] - 53.53.53.53 1 (0/ 1) [ 1-175] - 195.195.195.195 1 (0/ 1) [ 1-176] - 59.59.59.59 1 (0/ 1) [ 1-177] - 120.120.120.120 1 (0/ 1) [ 1-178] - 208.208.208.208 1 (0/ 1) [ 1-179] - 182.182.182.182 1 (0/ 1) [ 1-180] - 244.244.244.244 1 (0/ 1) [ 1-181] - 161.161.161.161 1 (0/ 1)

CAPITOLO 6. RISULTATI 74 [ 1-182] - 224.224.224.224 1 (0/ 1) [ 1-183] - 165.165.165.165 1 (0/ 1) [ 1-184] - 55.55.55.55 1 (0/ 1) [ 1-185] - 237.237.237.237 1 (0/ 1) [ 1-186] - 75.75.75.75 1 (0/ 1) [ 1-187] - 43.43.43.43 1 (0/ 1) [ 1-188] - 91.91.91.91 1 (0/ 1) [ 1-189] - 223.223.223.223 1 (0/ 1) [ 1-190] - 82.82.82.82 1 (0/ 1) [ 1-191] - 77.77.77.77 1 (0/ 1) [ 1-192] - 217.217.217.217 1 (0/ 1) [ 1-193] - 242.242.242.242 1 (0/ 1) [ 1-194] - 216.216.216.216 1 (0/ 1) [ 1-195] - 130.130.130.130 1 (0/ 1) [ 1-196] - 253.253.253.253 1 (0/ 1) [ 1-197] - 232.232.232.232 1 (0/ 1) [ 1-198] - 192.192.192.192 1 (0/ 1) [ 1-199] - 135.135.135.135 1 (0/ 1) [ 1-200] - 104.104.104.104 1 (0/ 1) [ 1-201] - 245.245.245.245 1 (0/ 1) [ 1-202] - 94.94.94.94 1 (0/ 1) [ 1-203] - 167.167.167.167 1 (0/ 1) [ 1-204] - 206.206.206.206 1 (0/ 1) [ 1-205] - 36.36.36.36 1 (0/ 1) [ 1-206] - 163.163.163.163 1 (0/ 1) [ 1-207] - 158.158.158.158 1 (0/ 1) [ 1-208] - 146.146.146.146 1 (0/ 1) [ 1-209] - 162.162.162.162 1 (0/ 1) [ 1-210] - 1.1.1.1 1 (0/ 1) [ 1-211] - 9.9.9.9 1 (0/ 1) [ 1-212] - 74.74.74.74 1 (0/ 1) [ 1-213] - 32.32.32.32 1 (0/ 1) [ 1-214] - 219.219.219.219 1 (0/ 1) [ 1-215] - 171.171.171.171 1 (0/ 1) [ 1-216] - 80.80.80.80 1 (0/ 1) [ 1-217] - 2.2.2.2 1 (0/ 1) [ 1-218] - 81.81.81.81 1 (0/ 1) [ 1-219] - 246.246.246.246 1 (0/ 1) [ 1-220] - 251.251.251.251 1 (0/ 1) [ 1-221] - 131.131.131.131 1 (0/ 1) [ 1-222] - 247.247.247.247 1 (0/ 1) [ 1-223] - 33.33.33.33 1 (0/ 1) [ 1-224] - 92.92.92.92 1 (0/ 1) [ 1-225] - 100.100.100.100 1 (0/ 1) [ 1-226] - 116.116.116.116 1 (0/ 1) [ 1-227] - 21.21.21.21 1 (0/ 1) [ 1-228] - 128.128.128.128 1 (0/ 1) [ 1-229] - 252.252.252.252 1 (0/ 1) [ 1-230] - 221.221.221.221 1 (0/ 1) [ 1-231] - 227.227.227.227 1 (0/ 1) [ 1-232] - 233.233.233.233 1 (0/ 1) [ 1-233] - 85.85.85.85 1 (0/ 1) [ 1-234] - 25.25.25.25 1 (0/ 1) [ 1-235] - 239.239.239.239 1 (0/ 1) [ 1-236] - 200.200.200.200 1 (0/ 1) [ 1-237] - 125.125.125.125 1 (0/ 1) [ 1-238] - 140.140.140.140 1 (0/ 1) [ 1-239] - 157.157.157.157 1 (0/ 1) [ 1-240] - 93.93.93.93 1 (0/ 1) [ 1-241] - 123.123.123.123 1 (0/ 1) [ 1-242] - 180.180.180.180 1 (0/ 1) [ 1-243] - 185.185.185.185 1 (0/ 1) [ 1-244] - 118.118.118.118 1 (0/ 1) [ 1-245] - 29.29.29.29 1 (0/ 1)

CAPITOLO 6. RISULTATI 75 [ 1-246] - 68.68.68.68 1 (0/ 1) [ 1-247] - 175.175.175.175 1 (0/ 1) [ 1-248] - 40.40.40.40 1 (0/ 1) [ 1-249] - 248.248.248.248 1 (0/ 1) [ 1-250] - 109.109.109.109 1 (0/ 1) [ 1-251] - 144.144.144.144 1 (0/ 1) [ 1-252] - 41.41.41.41 1 (0/ 1) [ 1-253] - 42.42.42.42 1 (0/ 1) [ 1-254] - 22.22.22.22 1 (0/ 1) Non vi sono nodi intermedi ed il nodo radice è in questo caso privo di significato, poiché in realtà qualsisi indirizzo IP potrebbe essere usato per etichettarlo. L output ottenuto conferma ulteriormente il corretto funzionamento del nostro modulo, essendo in grado di generare cluster da un solo elemento laddove gli allarmi siano del tutto scorrelati fra loro. 6.3 Tempi di calcolo I tempi di calcolo per la suddivisione degli allarmi in cluster dipendono fortemente dalla macchina in uso. Abbiamo utilizzato due macchine diverse per effettuare la stessa operazione di clustering sul medesimo dataset (impiegando la stessa metrica): la prima macchina è dotata di un processore Intel Pentium 4 (single core) a 3,20 GHz con 1 GB di RAM su cui è installato Windows XP Professional SP2, mentre la seconda ha un processore Intel Xeon E5462 (quad core) a 2,80 GHz con 8 GB di RAM su cui è installato Windows Vista Ultimate SP2. I tempi di elaborazione dell intero dataset sono stati molto diversi nei due casi: con la prima macchina sono stati necessari 2916 secondi (48,6 minuti) dall inizio del caricamento dei file alla fine della fase di clustering; con la seconda sono stati necessari 499 secondi (8,3 minuti) per le stesse operazioni. Mentre i tempi di caricamento dei dati sono stati piuttosto simili in entrambi i casi (rispettivamente 35 e 30 secondi), la fase di clustering ha richiesto tempi diversi, a causa dei numerosi calcoli necessari (soprattutto per la creazione della dot matrix, la cui durata cresce con l aumentare dei documenti da elaborare): con la prima macchina si sono impiegati 2881 secondi (48 minuti), mentre con la seconda i tempi sono scesi a 469 secondi (7,8 minuti).

Capitolo 7 Conclusioni e sviluppi futuri Gli obiettivi che erano stati prefissati all inizio di questo lavoro di tesi sono stati sostanzialmente raggiunti: si è aggiunto ad un framework per il text mining già esistente [17] un modulo sviluppato appositamente per la gestione e la correlazione (tramite clustering) di allarmi in formato IDMEF [15] prodotti dai sensori di un IDS operante in una rete di calcolatori. Si è verificato il funzionamento di questo modulo su un dataset composto da circa 25000 file in formato IDMEF, pubblicamente disponibile in rete [1]: poiché questi file non erano stati etichettati, non è stato possibile ottenere misure di prestazioni del nostro modulo; tuttavia, la struttura ad albero che esso genera rappresenta in maniera più chiara le situazioni critiche memorizzate nei file IDMEF analizzati, evidenziando le sorgenti da cui arriva la maggioranza degli attacchi alla rete. Questo consente di avere una visione immediata delle minacce alle quali è soggetta la rete ed accelera i tempi necessari a porvi rimedio. 7.1 Strumenti utilizzati Gli strumenti maggiormente utilizzati durante questa tesi e dei quali si è raggiunta una buona conoscenza operativa sono: Microsoft Visual Studio 2005 SLAIR 76

CAPITOLO 7. CONCLUSIONI E SVILUPPI FUTURI 77 TinyXML Notepad++. Si è acquisita una buona capacità di operare in ambiente SLAIR, dalla creazione di una nuova applicazione alla verifica del suo funzionamento, passando per la corretta configurazione delle impostazioni del framework. Queste conoscenze sono state impiegate per realizzare una prima applicazione di prova, con lo scopo di effettuare clustering su un insieme di numeri complessi, e successivamente per l applicazione oggetto della tesi, con l obiettivo di effettuare clustering su allarmi in formato IDMEF. Questo ci ha permesso di approfondire le nostre conoscenze sul linguaggio XML e sul formato IDMEF (che si basa su XML ed è attualmente allo stato sperimentale), oltre che sugli strumenti adatti all utilizzo di file in questo formato: ad esempio la libreria TinyXML, che è stata impiegata per la lettura ed il caricamento degli allarmi in formato IDMEF all interno dell ambiente SLAIR. Per la realizzazione del modulo IDMEF, si è ampliata la nostra conoscenza operativa anche dell ambiente di sviluppo Microsoft Visual Studio 2005 e dell editor Notepad++, con i quali si è scritto il codice sorgente del modulo e se ne è verificato il corretto funzionamento. Ciò ha contribuito a migliorare le nostre conoscenze sul linguaggio C++, utilizzato per la realizzazione del framework SLAIR e del nostro modulo IDMEF. 7.2 Sviluppi futuri Il lavoro sin qui svolto si presta a diversi possibili sviluppi, che si elencano nel seguito: i file IDMEF utilizzati durante il nostro lavoro (messaggi Alert) non rispettavano completamente i requisiti del formato: mancava il campo obbligatorio Classification, destinato a memorizzare informazioni sul tipo di attacco rilevato (ad esempio, il nome dell attacco o dati che lo identificano univocamente). La disponibilità di allarmi IDMEF con queste informazioni permetterebbe di apportare alcune innovazioni al modulo sviluppato: supponendo che i dati del campo Classification siano omogenei per tutti gli allarmi (ad esempio, l attributo text, ovvero il nome, sia assegnato secondo criteri stan-

CAPITOLO 7. CONCLUSIONI E SVILUPPI FUTURI 78 dard e Reference, cioè il sito di documentazione sull attacco, sia comune), si possono utilizzare queste informazioni per una prima suddivisione in cluster, ottenendo gruppi i cui elementi rappresentano attacchi simili tra loro; oppure, questi dati potrebbero essere usati alla fine della procedura di clustering, ovvero in fase di calibrazione: se, per esempio, il clustering è basato sulla distanza tra gli indirizzi IP da cui provengono gli attacchi, le informazioni di Classification potrebbero fornire indicazioni sugli attacchi più frequenti portati da certi indirizzi IP. Probabilmente, allarmi in formato IDMEF che rispettano completamente i requisiti si potranno avere quando il formato abbandonerà lo stato experimental e passerà dal nonstandards track allo standards track (per maggiori dettagli sulle fasi di standardizzazione di protocolli e procedure, si può consultare l RFC 2026 [6]); la disponibilità di file IDMEF aderenti alle specifiche e, più in generale, ricchi di informazioni permette di riformulare la metrica usata per il clustering di allarmi IDMEF che è stata introdotta nel nostro lavoro. Il formato IDMEF prevede due classi (ToolAlert e CorrelationAlert) progettate con il preciso scopo di memorizzare informazioni utili ad eventuali successive operazioni di correlazione degli allarmi: avendo a disposizione queste informazioni, si potrebbe effettuare una prima fase di clustering sulla base di questi dati, quindi il risultato potrebbe essere raffinato con un secondo clustering che utilizzi la metrica proposta nel nostro lavoro. Per gli allarmi provocati da attacchi di buffer overflow (che potrebbero essere individuati utilizzando la classe Classification citata in precedenza), esiste la classe OverflowAlert, progettata appositamente per questo tipo di attacchi e che risulterebbe utile per la prima fase di clustering. Come per il punto precedente, anche in questo caso la diffusione del formato IDMEF, che potrebbe derivare dalla sua promozione a standard, potrebbe favorire l utilizzo più completo delle classi che il formato offre, favorendo le operazioni di analisi degli allarmi come la correlazione; nel caso il punto precedente fosse realizzato e quindi la metrica del nostro modulo fosse ampliata, bisognerebbe certamente prevedere la possibilità di utilizzare dei fattori

CAPITOLO 7. CONCLUSIONI E SVILUPPI FUTURI 79 di peso per le varie parti di cui è composta la metrica stessa. In questo modo sarebbe possibile dare più importanza a quegli aspetti della metrica che si ritengono essere più significativi. Per una maggiore facilità d uso i valori dei pesi potrebbero essere impostabili nel file di configurazione di SLAIR sotto un apposita voce riguardante il modulo IDMEF. Nel modulo da noi sviluppato non si è adottato ancora questo approccio poiché sarebbero necessarie ulteriori e più approfondite verifiche per capire quali componenti della metrica siano davvero più rilevanti rispetto ad altri; con l introduzione dei pesi di cui al punto precedente si avrebbe un numero maggiore di parametri da impostare. Infatti, oltre a dover assegnare un valore a questi pesi, occorre scegliere anche un valore adeguato per i parametri nel file di configurazione di SLAIR relativi al clustering, quali MAX_HIERARCHY_LEVELS, HIERARCHY_ARK, BRANCHING_FACTOR. Un possibile sviluppo potrebbe prevedere la ricerca di quell insieme di parametri e di pesi che, per un determinato dataset, permetta di ottenere il miglior risultato: nel caso in cui si disponesse di allarmi già etichettati a mano, il miglior risultato corrisponderebbe ad una suddivisione degli allarmi in cluster da parte del framework uguale a quella che effettuerebbe un operatore umano. Se, inoltre, si avessero a disposizione diversi dataset di prova, si potrebbe trovare l insieme di parametri ottimo per ogni dataset e successivamente individuare quell insieme di parametri che, in media, fornisce i risultati migliori (per tutti i dataset), che potrebbe essere usato come punto di partenza per l analisi di dataset sconosciuti. Mentre alcuni parametri (come BRANCHING_FACTOR) potrebbero non ricoprire un ruolo fondamentale per trovare il miglior risultato, con altri occorre senz altro prestare maggior attenzione, poiché una variazione anche piccola può variare significativamente il modo in cui gli allarmi sono suddivisi; il framework SLAIR (dalla versione 3.0 in poi) offre anche la possibilità di classificazione attraverso SVM (Support Vector Machine). La classificazione potrebbe essere preceduta da una fase di apprendimento in cui il nostro sistema impara a distinguere gli attacchi reali dai falsi positivi sulla base di un dataset i cui elementi siano stati precedentemen-

CAPITOLO 7. CONCLUSIONI E SVILUPPI FUTURI 80 te etichettati manualmente. Successivamente il sistema sarebbe in grado di effettuare le operazioni di classificazione in autonomia e passare i risultati ottenuti al modulo di clustering da noi realizzato, permettendo di avere una correlazione più precisa ed attendibile; la limitata adozione del formato IDMEF rende difficile trovare dataset contenenti file di questo tipo pubblicamente disponibili. Questo non ha favorito lo sviluppo né soprattutto la verifica del funzionamento del nostro modulo: da una parte è stato difficile capire quali sono in media le informazioni sempre presenti in un allarme IDMEF sulle quali si potesse basare la metrica del nostro modulo (ciò sarebbe stato reso più facile se i requisiti del formato fossero sempre rispettati); dall altra parte, la scarsità di dataset non ha permesso di effettuare numerose prove, che avrebbero permesso di mettere a confronto diversi scenari e tipi di attacco. Per sopperire a questa scarsità, almeno fino a quando il formato IDMEF non conoscerà una maggior diffusione, si può ricorrere a degli strumenti che convertano le registrazioni di traffico in formato TCP dump, PCAP o simili in registrazioni IDMEF: con questo scopo è stato realizzato il lavoro di Bisogno e Porru [5], che, integrato con quello descritto in questa tesi, fornisce un sistema completo per l individuazione degli allarmi in una rete di calcolatori, dalla fase di sniffing a quella di generazione dei cluster degli allarmi rilevati. Un possibile sviluppo potrebbe proprio essere l integrazione di questi due lavori e la verifica delle prestazioni di questo sistema su una rete reale. Sempre nell ambito dei sistemi per la conversione degli allarmi in formato IDMEF, si segnalano: il plugin IDMEF per Snort 1, il quale è un network intrusion prevention system open source disponibile per piattaforme Linux e Windows; Vermont (VERsatile MONitoring Toolkit) 2, un toolkit open source per la creazione e l elaborazione dei flussi di dati di una rete di calcolatori, in grado di esportare 1 http://sourceforge.net/projects/snort-idmef/ 2 http://vermont.berlios.de/

CAPITOLO 7. CONCLUSIONI E SVILUPPI FUTURI 81 informazioni nel formato IDMEF; PreludeIDS 3, un intrusion detection system che usa il formato IDMEF per le comunicazioni tra i propri moduli interni. 3 http://www.prelude-technologies.com/en/development/download/index.html

Appendice A Il DTD IDMEF <?xml version="1.0" encoding="utf-8"?> <!-- *************************************************************** ******************************************************************* *** Intrusion Detection Message Exchange Format (IDMEF) XML DTD *** *** Version 1.0, 07 March 2006 *** *** *** *** The use and extension of the IDMEF XML DTD are described in *** *** RFC 4765exp, "The Intrusion Detection Message Exchange *** *** Format", H. Debar, D. Curry, B. Feinstein. *** ******************************************************************* *************************************************************** --> <!-- =============================================================== =================================================================== === SECTION 1. Attribute list declarations. =================================================================== =============================================================== --> <!-- Attributes of the IDMEF element. In general, the fixed values of these attributes will change each time a new version of the DTD is released. --> <!ENTITY % attlist.idmef " version CDATA #FIXED 1.0 "> <!-- Attributes of all elements. These are the "XML" attributes that every element should have. Space handling, language, and name space. --> <!ENTITY % attlist.global " xmlns:idmef CDATA #FIXED http://iana.org/idmef xmlns CDATA #FIXED http://iana.org/idmef xml:space (default preserve) default xml:lang NMTOKEN #IMPLIED "> 82

APPENDICE A. IL DTD IDMEF 83 <!-- =============================================================== =================================================================== === SECTION 2. Attribute value declarations. Enumerated values for === many of the element-specific attribute lists. =================================================================== =============================================================== --> <!-- Values for the Action.category attribute. --> <!ENTITY % attvals.actioncat " ( block-installed notification-sent taken-offline other ) "> <!-- Values for the Address.category attribute. --> <!ENTITY % attvals.addrcat " ( unknown atm e-mail lotus-notes mac sna vm ipv4-addr ipv4-addr-hex ipv4-net ipv4-net-mask ipv6-addr ipv6-addr-hex ipv6-net ipv6-net-mask ) "> <!-- Values for the AdditionalData.type attribute. --> <!ENTITY % attvals.adtype " ( boolean byte character date-time integer ntpstamp portlist real string byte-string xmltext ) "> <!-- Values for the Impact.completion attribute. --> <!ENTITY % attvals.completion " ( failed succeeded ) "> <!-- Values for the File.category attribute. --> <!ENTITY % attvals.filecat " ( current original ) "> <!ENTITY % attvals.fileperm "( noaccess read write execute search delete executeas changepermissions takeownership)" > <!-- Values for the UserId.type attribute. --> <!ENTITY % attvals.idtype " ( current-user original-user target-user user-privs current-group group-privs other-privs ) "> <!-- Values for the Impact.type attribute. --> <!ENTITY % attvals.impacttype " ( admin dos file recon user other ) "> <!-- Values for the Linkage.category attribute. -->

APPENDICE A. IL DTD IDMEF 84 <!ENTITY % attvals.linkcat " ( hard-link mount-point reparse-point shortcut stream symbolic-link ) "> <!-- Values for the Checksum.algorithm attribute --> <!ENTITY % attvals.checksumalgos " ( MD4 MD5 SHA1 SHA2-256 SHA2-384 SHA2-512 CRC-32 Haval Tiger Gost ) "> <!-- Values for the Node.category attribute. --> <!ENTITY % attvals.nodecat " ( unknown ads afs coda dfs dns hosts kerberos nds nis nisplus nt wfw ) "> <!-- Values for the Reference.origin attribute. --> <!ENTITY % attvals.origin " ( unknown vendor-specific user-specific bugtraqid cve osvdb ) "> <!-- Values for the Confidence.rating attribute. --> <!ENTITY % attvals.rating " ( low medium high numeric ) "> <!-- Values for the Impact.severity attribute. --> <!ENTITY % attvals.severity " ( info low medium high ) "> <!-- Values for the User.category attribute. --> <!ENTITY % attvals.usercat " ( unknown application os-device ) "> <!-- Values for yes/no attributes such as Source.spoofed and Target.decoy. --> <!ENTITY % attvals.yesno " ( unknown yes no ) "> <!-- =============================================================== =================================================================== === SECTION 3. Top-level element declarations. The IDMEF-Message === element and the types of messages it can include. =================================================================== =============================================================== --> <!ELEMENT IDMEF-Message (

APPENDICE A. IL DTD IDMEF 85 (Alert Heartbeat)* )> <!ATTLIST IDMEF-Message %attlist.global; %attlist.idmef; > <!ELEMENT Alert ( Analyzer, CreateTime, DetectTime?, AnalyzerTime?, Source*, Target*, Classification, Assessment?, (ToolAlert OverflowAlert CorrelationAlert)?, AdditionalData* )> <!ATTLIST Alert messageid CDATA 0 %attlist.global; > <!ELEMENT Heartbeat ( Analyzer, CreateTime, HeartbeatInterval?, AnalyzerTime?, AdditionalData* )> <!ATTLIST Heartbeat messageid CDATA 0 %attlist.global; > <!-- =============================================================== =================================================================== === SECTION 4. Subclasses of the Alert element that provide more === data for specific types of alerts. =================================================================== =============================================================== --> <!ELEMENT CorrelationAlert ( name, alertident+ )> <!ATTLIST CorrelationAlert %attlist.global; > <!ELEMENT OverflowAlert ( program, size?, buffer? )> <!ATTLIST OverflowAlert %attlist.global; > <!ELEMENT ToolAlert ( name, command?, alertident+ )> <!ATTLIST ToolAlert %attlist.global; > <!-- =============================================================== =================================================================== === SECTION 5. The AdditionalData element. This element allows an === alert to include additional information that cannot === be encoded elsewhere in the data model. =================================================================== =============================================================== --> <!ELEMENT AdditionalData ( (boolean byte character date-time

APPENDICE A. IL DTD IDMEF 86 integer ntpstamp portlist real string byte-string xmltext ) )> <!ATTLIST AdditionalData type %attvals.adtype; string meaning CDATA #IMPLIED %attlist.global; > <!-- =============================================================== =================================================================== === SECTION 6. Elements related to identifying entities - analyzers === (the senders of these messages), sources (of === attacks), and targets (of attacks). =================================================================== =============================================================== --> <!ELEMENT Analyzer ( Node?, Process?, Analyzer? )> <!ATTLIST Analyzer analyzerid CDATA 0 name CDATA #IMPLIED manufacturer CDATA #IMPLIED model CDATA #IMPLIED version CDATA #IMPLIED class CDATA #IMPLIED ostype CDATA #IMPLIED osversion CDATA #IMPLIED %attlist.global; > <!ELEMENT Classification ( Reference* )> <!ATTLIST Classification ident CDATA 0 text CDATA #REQUIRED > <!ELEMENT Source ( Node?, User?, Process?, Service? )> <!ATTLIST Source ident CDATA 0 spoofed %attvals.yesno; unknown interface CDATA #IMPLIED %attlist.global; > <!ELEMENT Target ( Node?, User?, Process?, Service?, File* )> <!ATTLIST Target ident CDATA 0 decoy %attvals.yesno; unknown interface CDATA #IMPLIED %attlist.global; > <!ELEMENT Assessment ( Impact?, Action*, Confidence? )> <!ATTLIST Assessment %attlist.global;

APPENDICE A. IL DTD IDMEF 87 > <!-- =============================================================== =================================================================== === SECTION 7. Support elements used for providing detailed info === about entities - addresses, names, etc. =================================================================== =============================================================== --> <!ELEMENT Reference ( name, url )> <!ATTLIST Reference origin %attvals.origin; unknown meaning CDATA #IMPLIED > <!ELEMENT Node ( location?, (name Address), Address* )> <!ATTLIST Node ident CDATA 0 category %attvals.nodecat; unknown %attlist.global; > <!ELEMENT Address ( address, netmask? )> <!ATTLIST Address ident CDATA 0 category %attvals.addrcat; unknown vlan-name CDATA #IMPLIED vlan-num CDATA #IMPLIED %attlist.global; > <!ELEMENT File ( name, path, create-time?, modify-time?, access-time?, data-size?, disk-size?, FileAccess*, Linkage*, Inode?, Checksum* )> <!ATTLIST File ident CDATA 0 category %attvals.filecat; #REQUIRED fstype CDATA #IMPLIED file-type CDATA #IMPLIED %attlist.global; > <!ELEMENT Permission EMPTY > <!ATTLIST Permission perms %attvals.fileperm; #REQUIRED %attlist.global; > <!ELEMENT FileAccess ( UserId, Permission+ )> <!ATTLIST FileAccess %attlist.global; > <!ELEMENT Inode ( change-time?, (number, major-device, minor-device)?, (c-major-device, c-minor-device)? )>

APPENDICE A. IL DTD IDMEF 88 <!ATTLIST Inode %attlist.global; > <!ELEMENT Linkage ( (name, path) File )> <!ATTLIST Linkage category %attvals.linkcat; #REQUIRED %attlist.global; > <!ELEMENT Checksum ( value, key? )> <!ATTLIST Checksum algorithm %attvals.checksumalgos; #REQUIRED %attlist.global; > <!ELEMENT Process ( name, pid?, path?, arg*, env* )> <!ATTLIST Process ident CDATA 0 %attlist.global; > <!ELEMENT Service ( (((name, port?) (port, name?)) portlist), protocol?, SNMPService?, WebService? )> <!ATTLIST Service ident CDATA 0 ip_version CDATA #IMPLIED iana_protocol_number CDATA #IMPLIED iana_protocol_name CDATA #IMPLIED %attlist.global; > <!ELEMENT SNMPService ( oid?, messageprocessingmodel?, securitymodel?, securityname?, securitylevel?, contextname?, contextengineid?, command? )> <!ATTLIST SNMPService %attlist.global; > <!ELEMENT User ( UserId+ )> <!ATTLIST User ident CDATA 0 category %attvals.usercat; unknown %attlist.global; > <!ELEMENT UserId ( (name, number?) (number, name?) )> <!ATTLIST UserId ident CDATA 0 type %attvals.idtype; original-user tty CDATA #IMPLIED %attlist.global;

APPENDICE A. IL DTD IDMEF 89 > <!ELEMENT WebService ( url, cgi?, http-method?, arg* )> <!ATTLIST WebService %attlist.global; > <!-- =============================================================== =================================================================== === SECTION 8. Simple elements with sub-elements or attributes of a === special nature. =================================================================== =============================================================== --> <!ELEMENT Action (#PCDATA) > <!ATTLIST Action category %attvals.actioncat; other %attlist.global; > <!ELEMENT CreateTime (#PCDATA) > <!ATTLIST CreateTime ntpstamp CDATA #REQUIRED %attlist.global; > <!ELEMENT DetectTime (#PCDATA) > <!ATTLIST DetectTime ntpstamp CDATA #REQUIRED %attlist.global; > <!ELEMENT AnalyzerTime (#PCDATA) > <!ATTLIST AnalyzerTime ntpstamp CDATA #REQUIRED > %attlist.global; <!ELEMENT Confidence (#PCDATA) > <!ATTLIST Confidence rating %attvals.rating; numeric %attlist.global; > <!ELEMENT Impact (#PCDATA) > <!ATTLIST Impact severity %attvals.severity; #IMPLIED completion %attvals.completion; #IMPLIED type %attvals.impacttype; other %attlist.global; > <!ELEMENT alertident (#PCDATA) > <!ATTLIST alertident analyzerid CDATA #IMPLIED %attlist.global; > <!-- =============================================================== =================================================================== === SECTION 9. Simple elements with no sub-elements and no special === attributes. ===================================================================

APPENDICE A. IL DTD IDMEF 90 =============================================================== --> <!ELEMENT boolean (#PCDATA) > <!ATTLIST boolean %attlist.global; > <!ELEMENT byte (#PCDATA) > <!ATTLIST byte %attlist.global; > <!ELEMENT character (#PCDATA) > <!ATTLIST character %attlist.global; > <!ELEMENT date-time (#PCDATA) > <!ATTLIST date-time %attlist.global; > <!ELEMENT integer (#PCDATA) > <!ATTLIST integer %attlist.global; > <!ELEMENT ntpstamp (#PCDATA) > <!ATTLIST ntpstamp %attlist.global; > <!ELEMENT real (#PCDATA) > <!ATTLIST real %attlist.global; > <!ELEMENT string (#PCDATA) > <!ATTLIST string %attlist.global; > <!ELEMENT byte-string (#PCDATA) > <!ATTLIST byte-string %attlist.global; > <!ELEMENT xmltext ANY > <!ATTLIST xmltext %attlist.global; > <!ELEMENT access-time (#PCDATA) > <!ATTLIST access-time %attlist.global; > <!ELEMENT address (#PCDATA) > <!ATTLIST address %attlist.global; > <!ELEMENT arg (#PCDATA) > <!ATTLIST arg %attlist.global; > <!ELEMENT buffer (#PCDATA) > <!ATTLIST buffer %attlist.global; > <!ELEMENT c-major-device (#PCDATA) > <!ATTLIST c-major-device %attlist.global; > <!ELEMENT c-minor-device (#PCDATA) > <!ATTLIST c-minor-device %attlist.global; > <!ELEMENT cgi (#PCDATA) > <!ATTLIST cgi %attlist.global; > <!ELEMENT change-time (#PCDATA) > <!ATTLIST change-time %attlist.global; > <!ELEMENT command (#PCDATA) > <!ATTLIST command %attlist.global; > <!ELEMENT create-time (#PCDATA) > <!ATTLIST create-time %attlist.global; > <!ELEMENT data-size (#PCDATA) > <!ATTLIST data-size %attlist.global; > <!ELEMENT disk-size (#PCDATA) > <!ATTLIST disk-size %attlist.global; >

APPENDICE A. IL DTD IDMEF 91 <!ELEMENT env (#PCDATA) > <!ATTLIST env %attlist.global; > <!ELEMENT http-method (#PCDATA) > <!ATTLIST http-method %attlist.global; > <!ELEMENT location (#PCDATA) > <!ATTLIST location %attlist.global; > <!ELEMENT major-device (#PCDATA) > <!ATTLIST major-device %attlist.global; > <!ELEMENT minor-device (#PCDATA) > <!ATTLIST minor-device %attlist.global; > <!ELEMENT modify-time (#PCDATA) > <!ATTLIST modify-time %attlist.global; > <!ELEMENT name (#PCDATA) > <!ATTLIST name %attlist.global; > <!ELEMENT netmask (#PCDATA) > <!ATTLIST netmask %attlist.global; > <!ELEMENT number (#PCDATA) > <!ATTLIST number %attlist.global; > <!ELEMENT oid (#PCDATA) > <!ATTLIST oid %attlist.global; > <!ELEMENT path (#PCDATA) > <!ATTLIST path %attlist.global; > <!ELEMENT permission (#PCDATA) > <!ATTLIST permission %attlist.global; > <!ELEMENT pid (#PCDATA) > <!ATTLIST pid %attlist.global; > <!ELEMENT port (#PCDATA) > <!ATTLIST port %attlist.global; > <!ELEMENT portlist (#PCDATA) > <!ATTLIST portlist %attlist.global; > <!ELEMENT program (#PCDATA) > <!ATTLIST program %attlist.global; > <!ELEMENT protocol (#PCDATA) > <!ATTLIST protocol %attlist.global; > <!ELEMENT size (#PCDATA) > <!ATTLIST size %attlist.global; > <!ELEMENT url (#PCDATA) > <!ATTLIST url %attlist.global; > <!ELEMENT HeartbeatInterval (#PCDATA) > <!ATTLIST HeartbeatInterval %attlist.global; > <!ELEMENT messageprocessingmodel (#PCDATA) > <!ATTLIST messageprocessingmodel %attlist.global;> <!ELEMENT securitymodel (#PCDATA) > <!ATTLIST securitymodel %attlist.global; >

APPENDICE A. IL DTD IDMEF 92 <!ELEMENT securityname (#PCDATA) > <!ATTLIST securityname %attlist.global; > <!ELEMENT securitylevel (#PCDATA) > <!ATTLIST securitylevel %attlist.global; > <!ELEMENT contextname (#PCDATA) > <!ATTLIST contextname %attlist.global; > <!ELEMENT contextengineid (#PCDATA) > <!ATTLIST contextengineid %attlist.global; > <!ELEMENT value (#PCDATA) > <!ATTLIST value %attlist.global; > <!ELEMENT key (#PCDATA) > <!ATTLIST key %attlist.global; > <!-- End of IDMEF DTD -->

Bibliografia [1] Lincoln Laboratory, Massachusetts Institute of Technology (MIT). http://www.ll.mit. edu/. [2] C.R. Attanasio, P.W. Markstein, and R.J. Phillips. Penetrating an operating system: a study of VM/370 integrity. IBM Systems Journal, 15(1):102 116, 1976. [3] B.I.A. Barry and H.A. Chan. Intrusion Detection Systems. Handbook of Information and Communication Security, pages 193 205, 2010. [4] M.W. Berry, S.T. Dumais, and G.W. O Brien. Using linear algebra for intelligent information retrieval. SIAM review, 37(4):573 595, 1995. [5] A. Bisogno and M. Porru. Progetto di un Network Intrusion Detection System. Tesi specialistica in Ingegneria elettronica, Genova, 2010. [6] S. Bradner. The Internet Standards Process Revision 3. RFC 2026 (Best Current Practice), October 1996. http://www.ietf.org/rfc/rfc2026.txt. [7] D. Cai, X. He, and J. Han. Document clustering using locality preserving indexing. IEEE Transactions on Knowledge and Data Engineering, pages 1624 1637, 2005. [8] T. Chen and P.J. Walsh. Guarding against network intrusions. In Computer and Information Security Handbook, pages 53 66. Morgan Kaufmann Publishers Inc., 2009. [9] S. Coppi and G. Maiolini. Metodi e strumenti per la sicurezza delle reti. AMTEC Elsag Datamat, 2010. Materiale di supporto al corso. [10] Ax3soft Corporate. How to prevent denial of service (DoS) attack. http://www. ids-sax2.com/articles/preventdosattacks.htm. [11] Symantec Corporation. Symantec global internet security threat report Trends for 2009. http://eval.symantec.com/mktginfo/enterprise/white_papers/b-whitepaper_ internet_security_threat_report_xv_04-2010.en-us.pdf, 2010. [12] The MITRE Corporation. Common vulnerabilities and exposures (CVE). http://cve. mitre.org/. [13] F. Cuppens and A. Miege. Alert correlation in a cooperative intrusion detection framework. Security and Privacy, IEEE Symposium on, 0:202, 2002. 93

BIBLIOGRAFIA 94 [14] O. Dain and R.K. Cunningham. Fusing a heterogeneous alert stream into scenarios. In Proceedings of the 2001 ACM workshop on Data Mining for Security Applications, pages 1 13. Citeseer, 2001. [15] H. Debar, D. Curry, and B. Feinstein. The Intrusion Detection Message Exchange Format (IDMEF). RFC 4765 (Experimental), March 2007. http://www.ietf.org/rfc/rfc4765. txt. [16] H. Debar and A. Wespi. Aggregation and correlation of intrusion-detection alerts. In Recent Advances in Intrusion Detection, pages 85 103. Springer, 2001. [17] S. Decherchi, P. Gastaldo, J. Redi, and R. Zunino. Hypermetric k-means clustering for content-based document management. In Proceedings of the International Workshop on Computational Intelligence in Security for Information Systems CISIS 08, pages 61 68. Springer, 2009. [18] I.S. Dhillon. Co-clustering documents and words using bipartite spectral graph partitioning. In Proceedings of the seventh ACM SIGKDD international conference on Knowledge discovery and data mining, pages 269 274. ACM, 2001. [19] J.E. Dickerson, J. Juslin, O. Koukousoula, and J.A. Dickerson. Fuzzy intrusion detection. In IFSA World Congress and 20th North American Fuzzy Information Processing Society (NAFIPS) International Conference, volume 3, pages 1506 1510. Citeseer, 2001. [20] A.K. Ghosh, A. Schwartzbard, and M. Schatz. Learning program behavior profiles for intrusion detection. In Proceedings of the 1st conference on Workshop on Intrusion Detection and Network Monitoring-Volume 1, page 6. USENIX Association, 1999. [21] D.J. Hand, H. Mannila, and P. Smyth. Principles of data mining. The MIT press, 2001. [22] K. Ilgun, A. Kemmerer, and A. Porras. State transition analysis: A rule-based intrusion detection approach. IEEE transactions on software engineering, 21(3):181, 1995. [23] Metropolitan Networks BBS, Inc. Computer virus classification, 2003. [24] K. Julisch. Clustering intrusion detection alarms to support root cause analysis. ACM Transactions on Information and System Security (TISSEC), 6(4):471, 2003. [25] A. Lazarevic, V. Kumar, and J. Srivastava. Intrusion detection: a survey. Managing Cyber Threats, pages 19 78, 2005. [26] W. Lee and X. Qin. Statistical causality analysis of INFOSEC alert data. Managing Cyber Threats, pages 101 127, 2005. [27] J. MacQueen. Some methods for classification and analysis of multivariate observations. In Proceedings of the fifth Berkeley symposium on mathematical statistics and probability, volume 1, page 14. California, USA, 1967. [28] A. Pagnoni and A. Visconti. An innate immune system for the protection of computer networks. In Proceedings of the 4th international symposium on Information and communication technologies, page 68. Trinity College Dublin, 2005.

BIBLIOGRAFIA 95 [29] C. Patrikakis, M. Masikos, and O. Zouraraki. Distributed denial of service attacks. http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-4/ dos_attacks.html, 2004. [30] C. Pfleeger and S. Pfleeger. Sicurezza in informatica. Pearson Paravia Bruno Mondadori, 2004. [31] P.A. Porras, M.W. Fong, and A. Valdes. A mission-impact-based approach to INFOSEC alarm correlation. In Proceedings of the 5th international conference on Recent advances in intrusion detection, pages 95 114. Springer-Verlag, 2002. [32] X. Qin. A probabilistic-based framework for INFOSEC alert correlation. PhD thesis, Citeseer, 2005. [33] X. Qin and W. Lee. Attack plan recognition and prediction using causal networks. In Computer Security Applications Conference, 2004. 20th Annual, pages 370 379, 2004. [34] E.T. Ray. Learning XML, Second edition. O Reilly Media, 2003. [35] R. Sadoddin and A. Ghorbani. Alert correlation survey: framework and techniques. In Proceedings of the 2006 International Conference on Privacy, Security and Trust: Bridge the Gap Between PST Technologies and Business Services, page 37. ACM, 2006. [36] K. Scarfone and P. Mell. Intrusion detection and prevention systems. In Handbook of Information and Communication Security, pages 177 192. Springer, 2010. [37] S.L. Scott. A Bayesian paradigm for designing intrusion detection systems. Computational statistics & data analysis, 45(1):69 83, 2004. [38] R. Sekar, Y. Guang, S. Verma, and T. Shanbhag. A high-performance network intrusion detection system. In Proceedings of the 6th ACM conference on Computer and communications security, pages 8 17. ACM, 1999. [39] J. Shawe-Taylor and N. Cristianini. Support Vector Machines and other kernel-based learning methods. Cambridge University Press, 2000. [40] S.J. Templeton and K. Levitt. A requires/provides model for computer attacks. In Proceedings of the 2000 workshop on New security paradigms, pages 31 38. ACM, 2001. [41] L. Thomason. TinyXml Main Page. http://www.grinninglizard.com/tinyxml/. [42] A.D.J. Valdes and K. Skinner. Probabilistic alert correlation, August 31 2001. US Patent App. 09/944,788. [43] The World Wide Web Consortium (W3C). Extensible markup language (XML). http: //www.w3.org/xml/. [44] W3Schools. XML tutorial. http://www.w3schools.com/xml/default.asp. [45] D. Yu and D. Frincke. Alert confidence fusion in intrusion detection systems with extended dempster-shafer theory. In Proceedings of the 43rd annual Southeast regional conference-volume 2, page 147. ACM, 2005.

BIBLIOGRAFIA 96 [46] R. Zhang and A.I. Rudnicky. A large scale clustering scheme for kernel k-means. Pattern Recognition, 4:40289, 2002. [47] B. Zhu and A.A. Ghorbani. Alert correlation for extracting attack strategies. International Journal of Network Security, 3(3):244 258, 2006.