Corrélation d événements et d alarmes pour la détection d intrusions dans les systèmes répartis.

(1)

Laboratoire d’Informatique Fondamentale d’Orléans U.F.R. Sciences - Université d’Orléans

Master IPVGCA:

Informatique : Parallélisme, Vérification, Graphes, Contraintes et Apprentissage

Corrélation d’événements et d’alarmes pour la détection d’intrusions dans les

systèmes répartis.

Etude présenté par :

Jonathan ROUZAUD-CORNABAS

Effectué au laboratoire:

Laboratoire d’Informatique Fondamentale d’Orléans Projet SDS : Sécurité et Distribution des Systèmes.

Localisé à l’ENSI-Bourges.

(2)

Remerciements

Je tiens à remercier l’ensemble de l’équipe du projetSDSduLIFOpour m’avoir acueilli pendant ce stage et tout particulièrement Patrice Clemente et Jeremy Briffaut pour leur aide et encadrement.

Je remercie également leLIFOet l’ENSIB pour m’avoir permis de participer à la conférenceCTS’07.

(6)

Chapter 2

Introduction

La sécurité des systèmes d’informations est un enjeu crucial du 21ème siècle.

L’interconnexion massive des systèmes informatiques les rend de fait plus vul- nérables. Aussi de nombreux travaux s’intéressent à la protection des systèmes, la prévention des attaques, la réduction des risques, et la réparation des dégats. Nos travaux s’inscrivent dans une démarche développée au sein de l’équipe-projet ’Sécu- rité et Distribution des Systèmes’ (SDS), du LIFO. Cette démarche essaie de concilier au mieux d’une part, les aspects concernant la protection des système, notamment en termes de contrôle d’accès et d’autre part, les aspects de surveillance (monitoring) et surtout de détection d’intrusions.

En particulier, nous visons par ces travaux à augmenter le pouvoir de détection d’intrusions des systèmes actuels, et notamment de PIGA IDS[BBLT06a] (Intrusion Detection System based on Policy Interaction Graph Analysis), développé au sein du projetSDS duLIFO. PIGA-IDSest un IDS¹basé sur des politiques de sécurité. PIGA

vérifie en effet qu’il n’y a pas d’opérations enfreignant la politique de sécurité définie sur le système. PIGA est de plus capable de vérifier que les séquences d’opérations sont elles aussi en conformité avec la politique de sécurité concernant les séquences.

PIGAse fonde pour son fonctionnement sur des politiques de contrôle d’accès man- dataire [BBLT06b, BCH05].

Notre travail de Master part du postulat que la plupart des systèmes de détection existants sont performants mais très spécialisés et fonctionnent de façon cloisonnée (indépendamment des autres). En terme de contribution scientifique, notre position- nement est le suivant : plutôt que de chercher à définir et implanter un système de dé- tection d’intrusion ouIDS(pour Intrusion Detection System) nous souhaitons faire col- laborer (au sens des informations qu’ils fournissent) les différents outils existants. Cela signifie concrètement de corréler les diverses informations concernant les événements systèmes et réseaux, informations retournées par l’analyse constante et dynamique du réseau et du système par les différents outils,IDSréseaux (ouNIDS) et systèmes (ou

HIDS) Il existe déjà des travaux de détection d’intrusion par corrélation mais à l’heure actuelle, ces travaux se basent sur les outils classiques tels queNIDSpour lesquelles les informations de sessiosn restent assez limitées. En particulier, une fois que l’attaquant a pénétré le système les outilsHIDSsont incapables de de fournir les informations néces- saires au traçage des actions de l’attaquant sur la machine pénétrée. Ces informations sont disponibles dorénanvant par l’intemédiaire dePIGAce qui permet ainsi d’espérer

1Intrusion Detection System: Système permettant de surveiller l’ensemble d’un système informatique.

(7)

la reconstruction de séquences complètes d’alarmes, depuis la toute première alerte réseau, jusqu’à l’opération ultime de l’ensemble des actions effectuées par l’attaquant sur le système.

Un premier aspect du travail consistera donc en la constitution d’un ensemble de schémas représentant les événements effectués pour mener à bien une attaques donnée.

Ce premier travail consistera donc à analyser les intrusions rencontrées sur un honeypot²et essayer manuellement de tracer les attaques complètes, c’est-à-dire de suivre la séquence des opérations effectuées sur le système une fois l’intrusion (entrée sur le système) réussie, afin de représenter à l’aide d’un formalisme donné (et les stocker con- crètement dans une base de données). Cela correspondra à une premier phase manuelle de corrélation chronologique et temporelle des événements hétérogènes, liés pourtant à une même session³.

Le but de cette première phase est de parvenir à connaître un peu mieux les attaques locales (sur une seule et même machine) mais aussi des attaques migrantes (l’attaquant se déplace de machine en machine durant l’attaque globale) ou distribuées (l’attaquant utilise plusieurs machines pour mener à bien son attaque, ou destinées à plusieurs machines qui en sont la cible).

Ensuite, en fonction de la base de connaissances acquise sur les attaques, et en nous appuyant sur la littérature du domaine, nous chercherons à identifier les corrélations les plus appropriées à effectuer pour construire les connaissances les plus pertinentes et complètes possibles sur les données brutes dont nous disposerons (alarmes reportées par lesIDS). L’un des objectifs à ce stade est de parvenir à reconstituer automatiquement des sessions complètes d’attaques. Nous essaierons de formaliser ces traitements sous la forme d’un ensemble d’algorithmes spécifiques de corrélation. Cela se traduira par la proposition d’un framework conceptuel et son implémentation sous la forme la plus souple possible. Vu le grand nombre d’alarmes générées par les outils actuels, les alarmes devanta prioritoutes être traitées, il est probable que les techniques de répartition des bases de données et/ou de traitement des données devront être étudiées, comme c’est d’ailleurs déjà le cas dans la littérature⁴.

Nous chercherons à définir les moyens nécessaires à la mise en oeuvre d’un système de détection par corrélation capable, d’une part de détecter et classifier des intrusions et plus globalement, de fournir à l’administrateur des sessions complètes d’attaques, et d’autre part, d’être capable d’apprendre automatiquement de nouveaux schémas (ou patterns) d’attaques.

Le document est structuré comme suit. Le chapitre 3 présente un état de l’art sur les travaux de détection d’intrusions par corrélation et termine par une discussion sur les forces et faiblesses des solutions existantes. Cette discussion nous permet, au chapitre suivant d’exposer nos motivations précises pour ce travail. Au chapitre 5, nous introduisons un framework de corrélation issu de certains travaux de la littérature, auquel nous ajoutons quelques éléments marquants. Ce framework regroupe un ensemble de fonctionnalités permettant d’effectuer différents types de corrélation. Au chapitre 6, nous formalisons ce cadre et définissons explicitement l’ensemble des algorithmes nécessaires aux différents types de corrélation proposées. Nous y introduisons quelques

2Un honeypot (en français pot de miel) est un ordinateur ou un programme volontairement vulnérable destiné à attirer et à piéger les pirates informatiques.

3Une session est un ensemble d’alarmes générées par unIDSreprésentant le comportement d’un attaquant lors d’une tentative d’intrusion.

4De nombreux travaux s’intéressent aux aspects techniques de la corrélation, du point de vue des ressources CPU et mémoires à utiliser, car cet aspects est couvent bloquant pour une corrélation pertinente, c’-est-à-dire travaillant sur des ensembles de données brutes importants.

(8)

exemples de signatures corrélatives d’attaques. Le chapitre 7 présente l’implantation du framework. Le chapitre 8 fait place à notre étude et nos réalisations permettant d’optimiser la gestion mémoire et la répartition des requêtes de corrélation. Le chapitre 9 fait place aux expérimentations et les premiers résultats encourageants obtenus. Le chapitre 10 établit une synthèse de l’ensemble des travaux. Le chapitre 11 dresse une liste de perspectives détaillées à donner à ces travaux. Le chapitre suivant constitué la conclusion générale à ce document.

L’annexe A présente les automates représentant les attaques, et précisément les algorithmes de manipulation de ces automates. Enfin l’annexe B présente un certain nombre de résultats concernant l’étape de classification manuelle des attaques.

(9)

Chapter 3

Etat de l’art: Détection

d’Intrusions par Corrélation

3.1 Introduction

Nous proposons ici un aperçu assez large du domaine de la détection d’intrusion (DI) par corrélation. Nous synthétisons donc les travaux les plus marquants dans ce domaine ainsi que le vocabulaire nécessaire à la compréhension du document.

Cet état de l’art n’a pas prétention à être exhaustif mais pose les bases des référents théoriques et pratiques sur lesquels nous nous sommes appuyés pour nos travaux. Le principe général de la corrélation est d’assembler/agréger/regrouper des informations provenant de sources différentes et indépendantes, de façon supervisée (guidée) ou totalement automatique pour faire apparaitre de nouvelles informations.

Dans le cadre de laDI, il s’agit de dépasser les limites des systèmes existants pour fournir, à partir d’informations brutes, parcellaires et dispersées, (...) ou des informations plus précices, ou de nouvelles informations, à savoir : soit confirmer ou infirmer des intrusions déjà détectées par des outils classiques, soit être capable de détecter des attaques/intrusions non détectées jusque là.

Sous le terme d’attaque, nous regroupons la notion d’attaque simple (par exemple, une tentative de connexion à une machine), mais aussi la notion d’attaque plus complexe, telle qu’une tentative de connexion réussie (intrusion) et la suite des actions malveillantes effectuée par l’intrus.

3.2 Scénario d’attaque

Les auteurs [SHM02] ont pu constater qu’une alarme¹est rarement isolée, elle fait en général partie d’un scénario plus vaste. Partant de ce constat, ils se sont fixé comme principal objectif de la corrélation, la capacité a reconstituer des scénarios d’attaque.

Les auteurs [KVV05] ont, quant à eux, proposé comme autre objectif la possibilité de générer un rapport d’intrusion complet à partir d’alarmes. Le processus de corréla- tion va consister en une méthode permettant de pratiquer une liaison logique entreN alarmes provenant d’une ou plusieurs sources d’information. La corrélation va donc

1Une alarme correspond à une possibilité d’intrusion telle que, vue par unIDS, c’est-à-dire, une action (ou suite d’actions) malveillante unique et isolée détectée par l’IDS.

(10)

permettre, à partir d’alarmes IDS ou systèmes bas niveau, de construire un scénario d’attaque plus ou moins générique et de détecter des attaques incluses dans le sur- ensemble défini par le scénario. L’un des prerequis est que les alarmesIDSne soient pas corrompues entre l’instant où elles sont générées et celui où elles sont utilisées pour le processus de corrélation. Au fur et à mesure qu’un scénario [DC05] est con- struit à partir de différentes alarmes, son niveau de priorité va augmenter. Ces scénarios peuvent servir aussi bien à la détection, la défense ou/et le forensics².

Trois types de corrélation existent:

• basée sur les similitudes entre 2 alarmes (ie même source, etc): méthode de regroupement sous forme de cluster par comparaison des valeurs(clustering correlation method), i.e., la comparaison des champs et des valeurs entre deux alarmes.

• basée sur les prérequis et les conséquences d’une attaque:méthode de corréla- tion causal³ (causal correlation method), i.e., la définition de prérequis et de conséquences à chaque alarme afin de pouvoir reconstituer le scénario.

• basée sur la connaissance: signature, i.e., en définissant des comportements d’intrusion et en comparant ceux ci aux alarmes reçues.

Le but du processus de corrélation est d’utiliser ces 3 types pour maximiser les possibilités de détection. Pour calculer l’efficacité d’un système de corrélation, les auteurs [NX02] introduisent deux mesures qui permettront de classer les différents systèmes de corrélation les un par rapport aux autres.

• Complétude(Completness) ie si les alarmes ont bien été corrélées entre elles.

Rc= #correctlycorrelatedalerts

#relatedalerts

• Validité(Soundness) ie si les alarmes ont bien été corrélées comme il le fallait.

R_s= #correctlycorrelatedalerts

#correlatedalerts

Le probleme du scénario de corrélation est qu’il ne refléte pas totalement la stratégie d’attaque (i.e. il détermine un flux d’alarme qui représente une stratégie d’attaque et pas la stratégie elle-même) et donc des petits changements peuvent provoquer une non-détection de celui-ci e.g.: une répetition inutile d’un événement, l’utilisation de la même méthode par une autre personne/outil, etc. Les auteurs [CO00] introduisent par conséquent une méthode efficace pour les comparer qui devra être précise tout en acceptant l’abstraction. Elle va prioritairement chercher les couples attributs/valeurs (i.e.

les attributs sont l’ensemble des champs instanciés pour chaque alarme e.g. username et les valeurs sont le ou les contenus de ces attributs e.g. username=’foobar’) qui ne changent pas d’une utilisation à une autre pour le même scénario d’attaque.

Cinq types de variation de session d’attaque peuvent survenir:

• Mutation: la plus simple et correspond à des changements dans les valeurs de certains attributs (eg.IP, port, username).

• Resequencing: modification de l’ordre temporel des alarmes.

2Le forensics correspond au domaine de la récupération de système après une intrusion et regroupe des méthodes permettant de relever des indices sur le déroulement, la source et les répercussions de cette intrusion.

3Le causal est un cas exprimant la raison ou le motif de l’alarme exprimée.

(11)

• Substitution: remplacement d’une ou plusieurs étapes (et donc des alarmes correspondantes) de l’attaque par d’autres.

• Distribution: utilisation de plusieurs valeurs pour le même attribut (eg. plusieurs adresses sourceIP).

• Looping: répétition inutile de certaines parties du scénario.

Pour éviter le problème du temps et du classement temporel entre les alarmes, [WLJ05] abstraient légérement en déclarant que si deux alarmes sont espacées d’un temps inférieur àtalors ils sont considérés comme parallèles.

Les graphes (ou les autres représentation des scénarios d’attaques) sont utilisés de deux façons: en détection passive à postériori (backward), en remontant ce qui va permettre de corréler uniquement les sessions d’attaques étant allé jusqu’à un certain but et en prévention en anticipant (foward) ce qui permet de “prévoir” la suite des évènements. En plus de la corrélation entre alarmesIDS, les auteurs [NRJ04] proposent d’utiliser des informations provenant desscans de vulnérabilité(voir section 3.9) mais aussi provenant de sondes de monitoring ou d’informations tierces sur le réseau. Dans de nombreux cas, ces scénarios d’attaque sont construits à la main ce qui provoque beaucoup d’erreurs, ils sont souvent trop grands et inutilisables, les auteurs expriment le besoin de définir des méthodes pour apprendre ces scénarios. Devant la complexité de certains graphes d’attaques, ils recommandent de prévoir un mécanisme permettant de réduire ces derniers afin qu’ils puissent être étudié et visualisés par l’Homme.

Les intérêts principaux de la corrélation sont

• un haut niveau de représentation des alarmes.

• une reconstitution du scénario complet.

• une réduction des faux positifs.

• la capacité de détecter des attaques complètes.

• la possibilité de détecter des variantes d’attaques connues.

• la possibilité de découvrir de nouvelles attaques.

• la capacité d’éliminer une partie des faux positifs (car ils sont aléatoires) ou tout du moins, augmenter la priorité des alarmes corrélées et donc qui ont plus de chances d’être de réelles attaques.

Les problèmes principalement sont:

• qu’elle se base sur des alarmes provenant d’IDSou d’autres évènements de plus haut niveau (logs, ...) donc des riques de faux-positif et faux-négatif mais aussi que ces derniers prennent par à la corrélation.

• que les sessions d’attaque peuvent muter d’une instanciation à une autre du même scénario d’attaque.

• qu’elle ne permet pas de détecter des profils d’attaque n’ayant pas encore eu lieu.

• que la qualité est toujours influencée par les faux-positifs et faux-négatifs.

• que la surcharge de la demande de puissance de calcul d’un senseur peut mener à une perte d’alarmes.

(12)

• que trouver des filtres proprent à chaqueIDSdemande un travail de parsing relativement long.

• que cela se base sur une très bonne connaissance des différents types d’attaques.

• qu’en utilisant les alarmesIDS, pour l’apprentissage, le risque d’apprendre des scénarios qui utilisent partiellement ou totalement des faux-positifs est important mais également de ne pas reconnaitre des scénarios dans leur ensemble car certains aspects ne sont pas détectés (faux-negatif).

• que si une alarme n’est pas corrélé avec un scénario d’attaque alors ce n’est pas forcément est un faux-positif.

3.3 Vocabulaire

Nous introduisons ici le vocabulaire courant du domaine, provenant de différentes pub- lications, nécessaire à la compréhension du document. Un glossaire complet se trouve à la fin du document.

• Action Malicieuse (Malicious action): une action qui ne respecte pas la politique de sécurité.

• Action Suspicieuse (Suspicious action): une action qui peut mener vers un scé- nario de malicious action.

• Attaque Silencieuse (Stealth attack): elle ne va pas génerer d’alarme(s) IDS

(faux-negatif).

• Attaque Détectable (Detectable attack): elle va génerer des alarmesIDS (vrai- positif).

• Session Corrélée: un groupe d’alarmes qui font partie de la même attaque, il peut y avoir des duplicats pour chaque alarme. Le but est de chercher les con- séquences (ou prévenir les conséquences) de cette attaque.

• Aggregation: regroupement d’alarmes suivant certains critères.

• Duplicat (Duplicate): un événement peut correspondre à plusieurs alarmes.

• Generalisation: Le but est d’abstraire plus ou moins certaines valeurs d’attributs qui composent une alarme afin de regrouper un plus ou moins grand nombre d’alarmes ayant les mêmes prédicats en commun (e.g. remplacer l’IP source d’une alarme par l’ensemble du réseau source). Cette abstraction implique en retour une perte de précision des informations composant l’alarme. Ce taux de généralisation doit être réglé suivant les besoins et peut changer suivant le scé- nario et entre les étapes d’un même scénario. La difficulté de la généralisation étant de regrouper suffisament d’alarmes sans perdre trop d’informations.

• Session d’attaque: rassemblement d’alarmes liés entre elles par des contraintes tel que les adressesIPet la temporalité.

• Thread: reconstitution d’un ensemble d’alarmes généré depuis un senseur par une seule et unique session.

(13)

• Incident de Sécurité (Security Incident): corrélation d’un accident depuis les alarmes de plusieurs senseurs.

• Cluster d’alarmes (Alert Clustering): Regroupement d’alarmes qui forment des groupes (méta-alarmes) suivant un certain nombre de prédicat commun (e.g.

username == ’foobar’) pouvant provenir de plusieurs senseurs différents.

• Mesure de similarité (Similarity Measure): Comparaison uniquement entre les attributs qui sont présents dans les 2 alarmes (feature overlap) et généralisation de certains attributs. Par exemple, uneIPen un réseau, un port en une serie de port e.g. 172.30.3.25 devient 172.30.*.*.

• Niveau de similarité attendu (Similarity Expectation): le niveau de similarité attendu pour chaque argument.

• Niveau de similarité minimum accepté (Minimum Similarity): le minimum de similarité accepté mais n’implique pas que cela soit suffisant pour la classification d’une session comme intrusive (ou faisant partie d’une classe d’intrusion).

• Hypothétisation: le but est de partir de l’hypothèse que lesIDSpeuvent n’avoir pas détecté certaines attaques provoquant une rupture dans le scénario et l’impossibilité de finir de détecter ce scénario.

• Alarme fusionée (Alert Fusion): combine les alarmes qui correspondent à la même étape dans un scénario et provenant de plusieurs senseurs.

• Vérification des alarmes (Alert Verification): élimination des faux positifs et des attaques n’ayant pas abouti pour ne pas géner la corrélation. Cette vérification peut être passive en utilisant une base de connaissance ou active en vérifiant via du monitoring la disponibilité des machines et des services mais également via des scans de vulnérabilité, des scripts, etc (applicable plus particulièrement auxNIDS, e.g. via l’utilisation de filtres, suppression de l’ensemble des alarmes réseaux destinées à une machine ou un service qui n’est pas présent sur le réseau au moment de la génération de l’alarme).

• Reconstruction de thread (Thread Reconstruction): le but est de regrouper les alarmes lancées depuis un attaquant vers un host c’est-à-dire les alarmes ayant la même source et la même destination dans une fenêtre de temps.

• Reconstruction d’une session d’attaque (Attack Session Reconstruction): cette méthode a pour but de lier les alarmes provenant de différentsIDSpour reconstituer la session, e.g., pouvoir lier les alarmesNIDSavec celles deHIDScorre- spondantes.

• Reconnaissance par focus (Focus recognition): permet d’identifier les hosts qui sont la source ou la destination de nombreuses attaques et fusionner ces dernières en une seule e.g. scanning,DDOS⁴. En pratique, utilisation d’une méthode de focus se basant sur un certain nombre de prédicat pour détecter si une fusion d’alarme regroupent plus d’alarmes qu’une constante.

4L’attaque par déni de service ou Denial of Service (DoS) vise à rendre une application informatique incapable de répondre aux requêtes de ses utilisateurs. Celle-ci devient DDoS - Distributed Deny of Service - quand l’attaque provient de plusieurs sources simultanément.

(14)

• Scénario distribué: scénario se déroulant sur plusieurs machines en série et/ou en paralléle.

• Niveau ajustable de réduction (Adjustable reduction): niveau de généralisation de la phase d’agrégation pour regrouper un nombre plus ou moins grand d’alarmes suivant la précision ou non des prédicats utilisés.

• Augmentation de la priorité (Focused Analysis): permet de se focaliser sur une partie des alarmes en utilisant des comparateurs logiques entre les attributs et leurs valeurs (ex: Source_IP = 192.168.25.78) permettant d’augmenter (ou de diminuer) la priorité de celles-ci.

3.4 Agrégation

Le but de l’agrégation est de rassembler en une seule “méta-alarme” un ensemble d’alarmes qui partagent une série de valeurs d’attributs en commun. Les auteurs [DW01]

ont introduit cette méthode afin de pouvoir détecter des attaques de type scan et/ou

DDOSfacilement et rapidement, de plus, l’ajout d’une fenêtre de temps permet de ré- duire la complexité du processus d’agrégation e.g. si les auteurs détectent plus de X alarmes relevant d’une attaque précise (comme une tentative DoS) mais provenant de plusieurs sources, ils vont pouvoir rassembler ces alarmes en utilisant un taux de similarité fixe entre chaque attribut et cela dans un intervalle de tempsY. Ce taux de similarité est fixé pour chaque attribut avec une valeur variant entre 0 et 100. Par exemple, dans une tentative deDDOS, une majorité des attributs des alarmes est iden- tique, comme la destinationIP, et aura donc un taux de similarité proche des 100% et une minorité des attributs sera totalement variable d’une alarme à une autre, comme la sourceIP, et aura un taux de similarité proche des 0%.

3.5 Probabiliste

Les auteurs [VS01, VS04] proposent une approche probabiliste afin de pouvoir corréler des alarmes entre elles en acceptant un taux d’erreurs pour les valeurs des attributs qui composent les alarmes et assimiler une alarme à une autre alors qu’elles ne le sont pas exactement (les valeurs de leurs attributs ne sont pas strictement égales deux à deux), afin de pouvoir y arriver, seuls les attributs qui sont commun aux deux alarmes sont pris en compte. Les auteurs précisent le besoin de faire définir par l’utilisateur le degré minimal de similitude entre les deux alarmes. En pratique, leur but est de comparer les nouvelles alarmes avec les anciennes pour essayer de trouver des similitudes.

Pour les auteurs [VS02], il faut corréler les nouvelles alarmes avec des méta alarmes (qui sont composées de différentes alarmes provenant de différents senseurs), pour cela il faut chercher ce qu’elles ont en commun - feature overlap (par exemple: la source

IP, les ports) mais également les similitudes (par exemple: est ce que les IP sources appartiennent au même réseau).

Pour optimiser le processus de corrélation probabiliste, ils ajoutent l’utilisation de matrices d’attaque qui vont comporter le taux de similitude entre 2 classes d’alarmes.

Pour cela, les auteurs calculent la similarité attendue (expectation of similarity) entre les deux classes d’alarmes concernées par rapport à ce qui a pu être observé dans le passé. Par exemple: le degré de similarité entre une alarme de typeDENIAL_OF_SERVICE

etPRIVILEGE_VIOLATION. Leur but étant de pouvoir assigner des importances plus ou

(15)

moins grandes à certains attributs suivant le type d’attaque (par exemple: il est connu que la source IP a des risques d’être falsifié pour certains types d’attaques). [VS02]

proposent également un degré minimal de similarité entre deux attributs, ce degré minimal n’est pas suffisant pour pouvoir corréler deux alarmes entre elles mais c’est le minimum requis. Sans ce degré minimal atteint, la suite du processus de corrélation ne sera pas lancée.

Leur but est de recréer les threads par senseurs puis de regrouper les threads correspondant à la même attaque et provenant des différents senseurs enfin de créer le circuit totale de l’attaque.

[VS02] proposent de mesurer la similitude de façon suivante:

SIM(X, Y) = P

jE_jSIM(X_j, Y_j) P

jEj

où:

X= la méta alarme de référence.

Y = une nouvelle alarme

j= l’index de l’attribut à prendre en compte Ej= la similarité attendu entre les 2 attributs

Xj,Yj = la valeur de l’attribut j pour les alarmes X et Y (la valeur peut être une liste).

La niveau de similarité entreX etY correspond à la somme des multiplications entre la similarité attendu et la similarité effective des attributs des deux alarmes qui est ensuite divisé par la somme des similarités attendues des attributs des deux alarmes.

La similarité attendue pour chaque attribut entre deux alarmes de type DoS (qui a été fixé précédemment par l’utilisateur) est mise en comparaison avec les valeurs réelles des attributs des alarmesXetY ce qui nous permet de connaitre le taux effectif de similarité entre ces deux alarmes.

3.6 Pre/Post Condition

Il y a 3 grandes familles de corrélation par pre/post condition: celle développée par Ning,MIRADOR(et le langageLAMBDA) et le langageJIGSAW. Dans cette approche, les auteurs utilisent les termes de prérequis comme une vulnérabilité d’un service et de conséquence comme une intrusion dans la machine. Par exemple, un scan de port est corrélé avec un scénario et va correspondre à la découverte par un attaquant d’une vulnérabilité. Les auteurs expriment de plus le fait qu’il peut ne pas y avoir de prérequis pour certaines alarmes: celle qui sont au début (temporellement) d’attaques.

Les trois possibilités générales de transition entre les alarmes sont:

• Consequences: les conséquences de la réussite d’une attaque.

• Prepare-For: une alarme prépare pour une prochaine si elle contribue au prerequis de celle-ci. Elle doit également avoir lieu avant dans le temps.

• Prérequis: les conditions nécessaire pour qu’une alarme puisse avoir lieu.

Cette technique utilise des graphes orientés et acycliques où un noeud représente une alarme et les transitions correspondent à une des possibilités de transitions entre

(16)

deux alarmes, le problème étant que leur taille croit exponentiellement avec la com- plexité de l’attaque. Tout d’abord, les auteurs expliquent qu’il faut construire des hyper alarmes à partir des alarmes arrivant, une hyper alarme étant constituée de trois attributs: l’alarme en elle-même, les prerequis et les conséquences. En général, une hyper alarme représente une alarme mais ils expriment également la possibilité de généraliser un ensemble d’alarme en une hyper alarme (agrégation).

L’intérêt d’inclure des fenêtres de temps est qu’elles permettent de faire des calculs sur des ensembles plus petits donc plus rapide mais l’inconvénient est qu’une attaque peut passer outre la corrélation en s’étallant sur le temps. Cette vulnérabilité peut être contrée en utilisant des fenêtres de temps plus grand. Mais comme exprimé par les auteurs, elle implique une augmentation exponentielle du temps de corrélation pour chaque nouvelle alarme.

Le problème de toutes ces techniques de pre/post condition est qu’elles se basent sur un modeling précis des pre et post conditions ce qui impose d’avoir une très bonne qualité de représentation pour avoir une corrélation efficace.

Les différences entre les divers langages et approches de la détections par pre/post conditions sont relativement faibles. JIGSAW a clairement le plus de défaut (et est également le plus ancien) car peu adapté aux nouvelles réalités du monde desIDSet ne sera pas présenté ici (il a été introduit par ces auteurs dans l’article [TL00]).LAMBDA

et l’approche de Ning sont relativement similaires et de qualité proche. La différence récurente est la phase d’agrégation qui est libre pour l’approche de Ning et qui se passe forcément avant la corrélation avecLAMBDA.

3.6.1

LAMBDA

: A Langage to Model A Database for Detection of Attacks

Ce langage a été développé au cours du projet européenMIRADOR[CM02, MD03].

[CO00] permet de décrire une attaque avec le point de vue d’un attaquant et va permettre une corrélation en utilisant des scénarios explicites (ie les auteurs définissent en “dur” les arguments et les alarmes de la corrélation) mais également de la corrélation implicites oùLAMBDAapprend à partir d’un groupe d’alarmes des régles de corrélation (cette méthode est basé sur l’apprentissage et peut utiliser des techniques tel que la classification, le data mining, les réseaux de neurones, etc).

Les auteurs proposent d’utiliser des graphes où les noeuds représentent des alarmes et les transitions se comportent en pre/post condition. Les transitions sont exprimés sous la formeA= action, actor, date avec action qui correspond au type d’action de l’attaque, actor (le ou les utilisateurs prenant part à l’attaque) et date (l’intervalle de temps de l’action). La définition des scénarios d’attaque se fait en utilisant la grammaire définie (cf publication [CO00]). Par exemple, knows(A,use_service(S,telnetd)) permet d’indiquer queAsait queSa un service actif telnetd.

Tout d’abord, les auteurs proposent de réduire le nombre d’alarmes en utilisant l’agrégation qui permet de regrouper toutes les variations d’une alarme dans une seule hyper-alarme.

La corrélation était rarement parfaite (direct correlation ieA→B)soitpost(A) = pre(B)), ils proposent de faire place à un peu d’abstration (ieA AN D X → Bsoit post(A) +X =pre(B)).

(17)

3.6.2 Ning Approach

L’équipe de Ning [NX04, NCR02, NCR01] propose de reconstruire un scénario d’attaque en se basant sur un graphe représentant les liaisons entre les différentes alarmes générées.

Cette méthode se base sur l’utilisation de contraintes sur les attributs de l’attaque et sur l’ordre temporel des diverses étapes de celle-ci. P. Ning apporte de nombreuses ap- plications de traitement de graphe appliquées aux scénarios d’attaques, mais aussi des méthodes d’apprentissage de ces derniers et d’optimisation de la rapidité du calcul de corrélation. Les traitements de graphe spécialement développés pour la corrélation sont [NCR05]réduction ajustable de graphe(adjustable graph reduction), reconnaissance par focus et découpage de graphe qui permettent de réduire la complexité d’un graphe en abstrayant certaines valeurs et de focaliser le graphe sur un sous ensemble.

Ning définit trois niveaux de classe de corrélation [NXHA04]:

1. Similitude entre les différents attributs d’une alarme (par exemple, même source et destination).

2. Scénario d’attaque défini par des humains ou appris depuis d’autres scénarios.

3. Basé sur les pre/post conditions d’une attaque individuel (une alarmeIDS), les auteurs proposent de corréler celle-ci avec d’autres alarmes passées qui vont présenter les prérequis de celle-ci et attendre en regardant les alarmes futures, pour obtenir la post condition.

Le but est de combiner ces méthodes afin de détecter le maximum de sessions mais l’équipe de Ning se focalise sur les recherches dans le domaine des pre/post conditions.

En effet, les 2 premières classes de corrélation restreignent leur détection à des attaques déjà connues alors que grâce à la généralisation, la 3ème méthode est moins limitée à ce niveau.

Les Hyper-Alarmes

Pour P. Ning, une hyper alarme est un triplet qui regroupe:

1. le fait (l’alarme) qui est une serie d’attributs associés à une ou plusieurs valeurs.

2. le prérequis et la conséquence qui sont des combinaisons logiques de prédicats.

Au lieu, de voir si une hyper alarme correspond au prérequis d’une autre, il vérifie qu’une hyper alarme contribue ou pas au prérequis d’une suivante. En pratique, il propose le découpage des prédicats d’une hyper alarme et voir si des hyper alarmes précédentes vérifient certains de ces prédicats puis corréler ces hyper alarmes entre elles, e.g. UDPVulnerableToBOF(VictimIP,VictimPort) représente la découverte par un attaquant que la machine qui a pourIPVictimIP fait tourner un service sur le port

UDPVictimPort et que ce service est vulnérable a une attaque par buffer overflow.

Selon cette méthode, l’agrégation n’est pas obligatoire mais permet de limiter le nombre d’alarmes et de créer des alarmes aggrégées enrichies.

Similarité de scénarios d’attaque

L’approche introduite par P. Ning va utiliser une méthode permettant de mesurer la similarité entre 2 stratégies d’attaques, permettant d’apporter de la tolérance aux fautes mais également de détecter des similarités de sous attaques entre deux attaques. Pour

(18)

répondre à cette dernière exigence, il propose d’utiliser la généralisation à partir d’un graphe d’attaque pour en détecter les variances. L’isomorphisme des graphes (et/ou sous graphes) tolérant aux erreurs permet de détecter la signature d’une attaque même si c’est une variante. Tout d’abord, sa méthode est d’aggréger les alarmes qui correspondent à la même étape de l’attaque pour éviter les répetitions puis extraire les contraintes entre les différentes étapes de l’attaque et les représenter dans un graphe d’attaque.

Généralisation de graphes de scénarios

Pour pouvoir construire des graphes d’attaques performants, P. Ning inclut des fonctions de mapping de généralisation qui va permettre de généraliser les attributs d’une hyper alarme. Bien entendu, cette fonction ne peut pas être faite à la main, c’est pourquoi, il introduit le besoin de techniques de clustering pour identifier les types d’hyper alarmes, puis les généraliser en un seul (bottom-up hierarchical clustering), sa méthode de clustering se base sur les similarités entre les hyper-alarmes puis va les dériver pour construire les conditions pre et post. L’utilisation de la méthodeJac- card Similarity Coefficient⁵lui permet de calculer la similitudes entre 2 ensembles de predicats S1 et S2 [NX03]:

Son but est de pouvoir en déduire la similarité entre deux scénarios d’attaque mais également de savoir si un scénario fait partie d’un autre. Afin de permettre de détecter le bruit et la distortion entre 2 graphes, P. Ning propose d’utiliser l’isomorphisme. Il introduit deux techniques d’approche: le graph edit distance et le graphe commun maximal(maximal common graph). La technique qu’il a retenu est graph edit distance.

L’auteur introduit la liaisonMayentre 2 alarmes pour pouvoir passer outre la non dé- tection de certaines alarms. Cela lui permet de pouvoir détecter les variations d’une attaque sans avoir à posséder les signatures pour chaque variation.

La méthode précédente était orienté à corréler des alarmes homogénes, celle-ci [ZNIR04]

permet une corrélation d’alarmes hétérogénes par les auteurs, elle ne se limite pas à corréler des alarmes IDS, elle les corréle également avec des rapports de vulnérabil- ité pour renforcer la qualité de l’analyse. Cette technique et l’utilisation de graphes d’attaque permet de ne pas se limiter à détecter des attaques qui ont eu lieu, mais de les détecter quand elles arrivent et donc prendre les décisions correspondantes. P. Ning introduit également l’utilisation detrigger event[XN04] qui sont des évènements de bas niveaux qui vont déclencher des alarmes. En regroupant les alarmes qui ont les même

”triggering event”, un ensemble d’alarme peut être partitionné en plusieurs clusters dont chacun correspond à une attaque. Pour identifier les triggering events, il introduit le besoin de chercher pour une alarme l’ensemble de type d’événement qui peuvent dé- clencher ce type d’alarme et les valeurs d’attributs correspondant. Dans cette approche, la connaissance des domaines des valeurs des attributs est essentielle. L’auteur exprime également le faite qu’il ne faille pas se limiter à l’égalité des valeurs des attributs, en effet, une alarme peut implicitement en exprimer une autre (par exemple: si il y a suppression du fichier doc/files.txt ou du répertoire doc/, les 2 alarmes vont supprimer le fichier files.txt, il faut donc prendre en compte que la première alarme va être contenue dans la seconde).

5Le coefficient de similarité Jaccard est une méthode statique utilisé pour comparer les similitudes et la diversité d’un ensemble.

(19)

3.7 Model Checker

Les auteurs [JSW02, SHJ⁺02] amènent une autre approche pour la corrélation via l’utilisation de model checker ⁶ et l’implémentent avec ORCHIDS⁷. Leur approche est de simplifier la construction et la comparaison de scénarios d’attaque entre eux (et également avec des alarmes) en utilisant des arbres de stockage typeBDD⁸et une logique temporelle commeLTLouCTL. Les auteurs veulent prouver l’utilité des model checkers pour construire automatiquement des graphes d’attaques. En effet, d’après leurs recherches, trouver un scénario d’attaque possible dans un graphe équivaut au problème duminimum hitting set. Ils introduisent également la possibilité d’utiliser des chaines de Markov pour calculer la chance de réussite d’une attaque. Un model checker symbolique est introduit utilisant une méthode en marche arrière (backward) en partant de l’état d’arrivé (goal state). L’intérêt de la méthode backward est qu’elle ne va pas chercher à reconstruire un graphe pour une attaque qui n’a pas été jusqu’au point voulu (goal state).

L’un des avantages du model checker est qu’il va être capable à partir d’un état final (goal state) de reconstruire à partir des différents alarmes tous les chemins qui peuvent mener à une telle attaque. Leur but est donc de construire un graphe qui va être composé de tous les chemins qui ménent à la rupture de la régle de sécurité. Ce graphe doit être succin et exhaustif. Par la suite, la méthode prévoit de reconstruire le graphe inverse (en utilisant la méthode deprocédure transversal- traversal procedure), c’est- à-dire de le reconstruire en partant des noeuds initiaux pour trouver tous les chemins accessibles qui ménent vers la rupture de régle de sécurité. Leur graphe d’attaque correspond à l’union de tous ces chemins depuis le noeud initial jusqu’à celui de rupture de politique. Ils motivent leur utilisation de model checker par la possibilité à réutiliser les recherches effectuées dans le domaine du model checking.

3.8 Queue Graph

Le but des auteurs [TA05, WLJ05] de cette approche est de pouvoir supporter les floods⁹d’alarmes provoqués par un attaquant souhaitant cacher son intrusion. L’utilisation d’untoken bucket filter(ouTBF)¹⁰va permettre de contrôler la quantité de flux de don- nées (aussi utilisé en QoS¹¹). Ce token bucket filter a 2 paramètres: la taille du “panier”

et la rapidité de diffusion. Il ne va donc pas y avoir de problèmes de flood puisque les alarmes sont délivrées à la vitesse voulue. Les nouvelles alarmes arrivant sont stock- ées, avant d’être livrées, dans un buffer appellé “panier” (bucket). Quand ce dernier est

6Le Model Checking désigne une famille de techniques de vérification automatique des systèmes dynamiques (souvent d’origine informatique où électronique). Il s’agit de vérifier algorithmiquement si un modèle donné, le système lui-même ou une abstraction du système, satisfait une spécification, souvent for- mulée en termes de logique temporelle.

7IDSse basant sur un model checker [OGL05].

8Un diagramme de décision binaire (BDD, binary decision diagram en anglais), comme une forme nor- male niée ou un graphe orienté acyclique propositionnel, est une structure de données utilisée pour représen- ter des fonctions booléennes.

9Flood: Envoi massif de données dans le but d’empécher un système de fonctionner correctement.

10L’implémentation TBF consiste en un tampon, ou seau, constamment rempli par des éléments virtuels d’informations appelés jetons, avec un débit spécifique, dit “ débit de jeton ”. Le paramètre le plus important du tampon est sa taille, soit le nombre de jetons qu’il peut stocker. Dans l’implémentation réelle, les jetons correspondent à des octets et non à des paquets.

11QoS est un sigle qui signifie Quality of Service en anglais, que l’on traduit par “qualité de service” en français. La Qualité de Service (QoS) est la capacité à véhiculer dans de bonnes conditions un type de trafic donné, en termes de disponibilité, débit, délais de transit, taux de perte de paquets...

(20)

plein, il déborde et les alarmes sont perdues. Pour éviter ce genre d’incident, les auteurs introduisent la possibilité d’augmenter temporairement la vitesse de traitement en utilisant plus de ressources disponibles (ie unbustdans le domaine de la QoS). De par le problème de risque de perte d’alarme dû à un panier plein, les auteurs souhaiteraient pouvoir vérifier que ces alarmes perdues ne sont pas d’une importance crutiale.

Leur graphe d’attaque est représenté via un graphe dirigé et acyclique. Il est com- posé d’alarmesNIDSet de rapports Nessus. Grâce à l’utilisation des queue graphs, au lieu de chercher à travers toutes les alarmes déjà reçues celles qui peuvent préparer pour une nouvelle alarme, les auteurs expliquent le besoin de chercher en incluant uniquement la dernière alarme de chaque type. Cela implique donc implicitement une corrélation avec un ordre temporel. En intégrant des fonctions de généralisation des alarmes et des graphes d’attaque, les auteurs tentent de réduire la possibilité de non détection et de perte de certaines alarmes mais également de tenter de prédire la suite de l’attaque.

D’après les auteurs, l’intérêt de cette technique par rapport aux graphes d’attaques classiques est qu’elle ne va pas augmenter en complexité avec le temps. Leur approche introduit également comme les graphes d’attaque classiques (voir section 3.6) lanested loop approachavec ou sans fenêtres de temps. Grâce à la méthode décrite par les auteurs, la corrélation est capable de détecter les attaques lentes grâce à la conservation de la dernière alarme pour chaque type jusqu’à temps qu’elle soit corrélée. Comme d’autres méthodes, l’introduction du processus d’hypothétisation de la perte de certaines alarmesIDSva permettre de pouvoir continuer la corrélation même si certaines alarmes sont ratées par unIDS. Du point de vue des graphes, cela revient à combler des parties intermédiaires entre le début et la fin d’un graphe d’attaque.

3.9 Corrélation IDS/Vulnerability Analysis

L’approche proposée par les auteurs [Gul07] est de corréler les alarmes IDSavec les informations données par un scan de vulnérabilité. D’après eux, cette méthode est très efficace pour éliminer les faux positifs qui sont produits par lesNIDS. Leur but est d’augmenter le niveau de confiance envers certaines alarmes IDS. Ils introduisent également la possibilité d’utiliser des sources d’informations autres comme la topolo- gie du réseau. Le but des auteurs est de pouvoir se focaliser sur l’étude des attaques impliquant des failles réelles dans le réseau.

Grâce au scan de vulnérabilité, il est possible de savoir où sont les risques et créer les régles de sécurité et de l’IDScorrespondantes, mais les auteurs évoquent également le fait qu’il est intéressant de monitorer les endroits où il n’y a pas de vulnérabilité. Leur principal problème est de corréler les informations venant du scan de vulnérabilité avec des informations valides venant desIDSet pas avec des faux positifs qui pourrait mener à augmenter la priorité d’une attaque qui n’a pas lieu. Au niveau de la mise en place, leur problème est de trouver un formalisme pour pouvoir comparer les informations provenant des scans de vulnérabilité tout comme les informations venant desIDS.

Ils distinguent trois types de corrélation entreIDSetVA:

• PersistentVA/IDSCorrelation: le but est de maintenir une base de données des vulnérabilités duSIet dès qu’une alarme est corrélée avec cette base d’augmenter son niveau d’importance.

• Near-TimeVA/IDSCorrelation: Sensiblement la même chose que Persistent sauf que les recherches de vulnérabilités sont effectué en fonction des alarmes IDS

(21)

reçues.

• Real-TimeVA/IDSCorrelation: Cette méthode est la méthode parfaite pour les

VA/IDS Correlation, elle va permettre aux IDS de connaitre en temps réel les vulnérabilités touchant leSI de manière “magique”, i.e. cette méthode est impossible à mettre en place car elle sous entend d’être capable de prévoir ce que le processus de corrélation va avoir besoin comme informations sur les vulnéra- bilités avant même qu’il sache qu’il en a besoin.

Le principal problème de cette méthode est la perte de beaucoup d’informations intéressantes comme les étapes de préparation du scénario d’attaque qui ne vont pas être détectées. Par contre, elle permet d’augmenter la confiance envers certaines alarmes mais ne permet pas la reconstitution de scénario d’attaque complet.

3.10 Data Mining

Les auteurs [MCZH00, LSC04] amènent une approche de la corrélation via Data Min- ing où le but est d’apprendre à partir des alarmes antérieures les signatures des scénar- ios d’attaque et les contre-mesures à mettre en place. [JD02] proposent deux méthodes de Data Mining pour la corrélation:namely episode rulesetconceptual clustering technique. Leur idée est que les techniques de Data Mining seront particulièrement efficace pour réduire les problèmes de mutation des scénarios. Comme la plupart des méth- odes de corrélation, cette technique perd des informations car elle rassemble plusieurs alarmes en une seule. La recherche est faite sous 2 axes: tout d’abord une recherche d’alarme se déroulant de façon séquentielle (ou serielle) (une suite récurrente d’alarmes qui peut être potentiellement la signature d’une attaque) et une recherche d’alarme par- allèle, e.g., un scan réseau ou unDDOS.

D’après les auteurs, seul 1% des attaques est détectée en utilisant l’apprentissage sur les attaques précédentes. Pour améliorer la détection, ils ajoutent une couche de généralisation qui va, par exemple généraliser uneIPen un réseau, mais ils expriment également le problème qu’il ne faut pas tomber dans trop de généralisation qui finirait par provoquer trop de corrélation positive (et potentiellement faux positive). Finale- ment, ils proposent d’utiliser les informations apprises de la généralisation pour créer des procédures d’agrégation plus précises mais sans donner de résultats plus précis sur l’amélioration du nombre d’attaques détectées.

3.11 Stockage des évènements IDS : Database Versus Mem- ory

Comme P. Ning l’a exprimé, l’utilisation de base de données dans le processus de cor- rélation le ralentit énormément. En effet, lesBDDne sont pas faite pour une étude in- téractive comme la corrélation le demande. Le but des auteurs [NX02] est d’optimiser les recherches dans la base de données et de faire les études intéractives en stockant en mémoire certaines données utilisées par le processus de corrélation. D’après les auteurs, dans un processus de corrélation classique avec 65,000 alarmes, il faut 4 minutes pour pouvoir les traiter en utilisant une base de données, en utilisant des données en mémoire, il est possible de réduire ce temps à moins d’une seconde.

Il existe plusieurs méthodes de stockage en mémoire [NR02]

(22)

• Tableau de recherche binaire (Array Binary Search): cette méthode va stocker les données dans un tableau et va effectuer les recherches en utilisant une technique de typerecherche binaire(binary search). Elle est efficace sur les données statiques mais peu sur les données dynamiques. En effet, le tableau doit avoir assez de place pour pouvoir ajouter des nouvelles données sinon il faut réallouer un emplacement mémoire plus grand puis recopier entièrement le tableau à ce nou- vel endroit. Mais également, si il y a assez de place dans le tableau, l’insertion implique une complexité deO(N)en nombre de déplacement de données.

• AVL Tree: se base sur des arbres de recherche binaires équilibrés (balanced).

Avec ce système, chaque noeud contient des données, des informations de con- trôle, un pointeur gauche qui va pointer vers le sous arbre qui contient les élé- ments plus petit et le droit qui va pointer sur les éléments plus grand. La recherche est très rapide dans ce système mais l’insertion dans l’arbre demande l’ajout d’une feuille qui peut impliquer de gros changements dans l’arbre comme un rebalancement de ce dernier.

• B-Tree: est également un arbre de recherche équilibré mais contrairement à ceux enAVL, il peut avoir plusieurs données et pointeur pour chaque noeud. Les don- nées sont ordonnés à l’intérieur de chaque noeud et chaque pointeur pointe sur un sous arbre qui contient les données qui sont compries dans le panel identifié par les 2 données adjacentes. Ses intérêts sont:

1. moins d’accès au noeud par rapport àAVL.

2. l’insertion est plus rapide et ne remet en cause qu’un seul noeud.

• T-Tree: ce sont des arbres binaires avec un ensemble d’éléments dans chaque noeud. C’est une évolution desAVLet B Tree. Ils combinent la bonne capacité de recherche desAVLavec la rapidité de stockage des mise à jour des B-Tree. La recherche dans les T-Tree correspond à la recherche dans un arbre binaire suivi d’une recherche sur un noeud. L’insertion implique des mouvements de données uniquement dans un noeud mais également des rotations dans la structure de l’arbre pour le rebalancer.

• Chained Bucket Hashing: cette méthode utilise une table statique de hash et une chaine de “panier” pour chaque hash. Elle est très efficace dans un environe- ments statiques où il est possible de prévoir à l’avance le nombre d’éléments qui vont être présent. Mais quand ce nombre n’est pas connu, les performances deviennent rapidement mauvaises, en effet, si la table de hash est trop petite alors trop de “panier” risque d’être chainer pour un seul et même hash et si la table est trop grande alors on risque de perdre de la place à cause d’entrée vide.

• Linear Hashing: va également utiliser une table de hash mais dynamique ici qui va couper les hash des “paniers” dans un ordre linéaire prédéfini. A chaque fois qu’un “panier” déborde, l’algorithme va le couper en 2 et la taille de la table de hash va augmenter. Les “paniers” sont ordonné séquentiellement ce qui permet à une adresse d’un “panier” d’être calculer à partir d’une adresse de base.

Pour utiliser efficacement ces stockages en mémoire, un algorithme appellé “Nested Loop Correlation” a été créé par l’équipe de P. Ning qui permet d’utiliser des structures Linear Hashing et T-Tree pour rechercher les relations entre les alarmes (relation de type “prepare-for”).

(23)

Contrairement aux bases de données, le stockage en mémoire de l’ensemble des alarmes est impossible, la RAM arrivant rapidement à saturation. Pour minimiser le problème, les auteurs proposent d’utiliser le concept de fenêtre de temps pour con- server en mémoire seulement certaines alarmes. Le nombretd’alarme disponible en mémoire est calculé par rapport à la taille de la mémoire disponible. En pratique, quand une alarme est ajoutée, la plus ancienne est supprimée. Les structures de données, présentées ci-dessus, ne sont pas optimisées pour la suppression car elles demandent un parcours de l’arbre en entier avant de pouvoir trouver et supprimer une alerte. Il faut donc ajouter une deuxième structure de données pour la localisation des alarmes dans la structure de donnée en utilisant une file. Pour minimiser le problème de l’allocution de mémoire, les auteurs ont proposé que chaque tableau soit initialisé à une taille fixe, si il n’y a plus assez de place dans celui-ci, un nouveau avec une taille double soit créé puis les données précédentes recopiés dedans.

3.12 Correlation et Réseau Neuronal

Cette méthode introduit un autoassociateur [SJD05] qui est unFeed-Forward ¹² sur les réseaux neuronaux qui prend le même nombre d’entrées que de sorties. D’après les auteurs, malgré leur simplicité, ils ont prouvé leur efficacité dans le milieu civil et militaire. Un autoassociateur peut corréler des réseaux similaires (scénarios d’attaque) et il est extrêmement rapide une fois entrainé. De plus, contrairement aux autres méth- odes de corrélation, celle-ci ne perd aucune d’informations au fur et à mesure de la corrélation. En pratique, le réseau neuronal est entrainé en utilisant l’algorithme de error-backpropagation avec pour objectif de reconstruire l’espace d’entrée à la sortie.

3.13 Framework de corrélation

Ces travaux [VVKK04, Qin05] ont favorisé l’utilisation de méta-alarmes. Ce sont des alarmes enrichies par le processus de corrélation. Le processus de corrélation proposé peut être découpé en plusieurs étapes:

1. la normalisationqui permet de comparer facilement les alarmes entre elles, peu importe le senseur qui l’a généré.

2. le preprocessingqui vérifie que tous les arguments sont initialisés avec des valeurs cohérentes.

3. la fusionqui regroupe la même alarme venant de plusieurs sondes en une seule.

4. la verificationqui, à partir d’une alarme simple, définit son niveau de danger (le risque de réussite).

5. le thread reconstructionqui combine une serie d’alarme référant à un attaquant lançant plusieurs attaques sur un seul et même host.

6. l’attack session reconstruction: association des alarmesNIDSetHIDSpour une

“session” d’attaque.

12Feed-Forward est un terme decrivant une sorte de système qui réagit au changement de son environ- nement, normalement pour obtenir certains états dans ce système. Un système qui utilise un feed-foward répond aux turbulances d’une manière prédéfinie.

(24)

7. le focus recognition: concentration sur une partie des résultats.

8. la multi step correlation: reconstruction du scénario global.

9. l’impact analysis: calcul de l’impact sur le système, des contre-mesures, etc.

[VVKK04, Qin05] précisent que des étapes supplémentaires peuvent être ajoutées comme la corrélation avec un dépot d’informations (qui peut contenir la typologie réseau, divers informations de monitoring, le résultat de scan de vulnérabilité, etc), un backend permettant de trouver l’identité de l’attaque dans des bases de données tel que CVE, Bugtraq et arachNIDS pour aider à la construction de contre mesures et de rapport d’incident [Cal02, Buv03] mais également des interfaces [CBB⁺04] permettant à l’humain de régler des valeurs qu’il souhaite (comme le niveau d’agrégation ou de réduction des graphes).

Les auteurs introduisent également deux algorithmes permettant de formaliser l’étape de “multistep correlation“¹³:

• reconnaissance-intrusion-escalade de privilége (recon-breakin-escalate):

1. scan network/host à la recherche de vulnérabilité 2. utilisation de la vulnérabilité pour pénétrer la cible.

3. utilisation d’une escalade de privilége et passage en root sur la cible.

• island-hopping: permet de détecter une attaque où la destination devient la source de la seconde attaque (attaque migrante).

3.14 Corrélation décentralisée

Dans l’architecture introduite par les auteurs [KTK05], la corrélation n’a pas lieu en un point central mais à de multiples endroits contrairement à la plupart des architectures de corrélation déjà présentées ici qui sont distribuées mais où les données et les calculs sont centralisées ce qui pose un problème pour le passage à l’échelle et la tolérance aux pannes. Le passage à une architecture décentralisée ne régle pas tout, il y a toujours le cas où une machine n’a pas assez de puissance pour effectuer sa part du travail de corrélation. Le cas présenté [KTK05] utilise une corrélation par signature. Les auteurs expliquent qu’un tel système oblige à avoir un langage pour déclarer les signatures mais également un mode de transfert qui sera basé sur un algoritme réseau de typeP2P

pour partager les alertes et les signatures entre les machines. Grâce à cette méthode, il est possible de détecter un scan de port sur l’ensemble d’un réseau en faisant transiter l’information entre les HIDS. Ils expliquent également que leur méthode permet de mettre en place des contre mesures adaptées pour chaque étape d’un scénario d’attaque et pas uniquement quand celui-ci est totalement détecté. Les systèmes décentralisés ne l’étant jamais totalement, il faut un (ou plusieurs) centre(s) de management qui vont stocker la configuration de chaqueIDS.

Dans cette approche, les alarmes sont traitées en local (sur chaque senseurIDS) en utilisant du prefiltrage avant d’envoyer l’information au système de stockage. Ensuite, leur but est de créer un modèle réseau de type publisher/subscriber pour disséminer

13MultiStep Correlation: étape de la corrélation permettant de détecter des attaques composées de plusieurs sous attaques e.g. un scénario composé d’une attaque par brute force et une session locale illé- gale.

(25)

l’information sur les machines. La communication se fait sur un mécanisme fonction- nant au dessus d’une connexionSSLentre senseurs permettant le transfert d’alarmes et de descriptions de signature. Un canal de management (également protégé) est utilisé pour la reconfiguration et la construction de block. La grammaire utilisée pour décrire les attaques doit pouvoir écrire des relations entre différents évènements sur différents hosts en utilisant ou des expressions régulières ou des grammaires d’arbres.

Un des problèmes majeurs de la corrélation distribuée est qu’il faut pouvoir définir un temps universel afin de pouvoir classer correctement les évènements temporellement les uns par rapport aux autres. Le modèleP2Pamène également le probléme de l’utilisation réseau, en effet, si les signatures deviennent trop compliquées, le nombre d’alarmes échangées va rapidement augmenter. Le pire des cas pour ce principe de cor- rélation décentralisée est de se retrouver dans le cas où chaque événement est envoyé sur chaque machine.

La distribution du système permet de détecter des scénarios d’attaques se passant sur l’ensemble du réseau. Au niveau du système de corrélation, les auteurs [KTK05]

proposent de mettre en place des domaines afin d’alléger le processus puis de rassembler les informations provenant des différents domaines et déjà prétraiter. Suivant les différentes études, que la procédure de preprocessing peut être faite au niveau local de chaque senseur mais ne donne souvent rien par manque d’informations en local et le besoin d’informations provenant de l’extérieur. Les auteurs expriment également le besoin de prendre en compte qu’un système décentralisé doit pouvoir gérer des signatures ou autres représentations des scénarios en utilisant une grammaire supportant ce processus décentralisé.

La décentralisation permet de se passer du modéle manager où un point central est le point de rendez-vous en utilisant un modéle publisher/subscriber mais elle ne régle pas totalement le problème d’un ou plusieurs points critiques dans la structure du réseau de corrélation. Leur but étant de permettre que chaque machine fasse une part de la corrélation afin de répartir la charge. Mais le problème est que la corrélation peut être corrompue si une des machines effectuant celle-ci est corrompue (on passe donc d’un point critique à plusieurs). Il y a 2 types d’architecture décentralisée qui ont déjà été étudié: Cooperating Security Manager (CSM) et Security Policy Adaptation Reinforced Trough Agents (SPARTA).

[KTK05] énumèrent plusieurs méthodes de décentralisation:

• seules les machines impliquées dans le scénario vont participer à la corrélation.

• utilisation de code mobile qui vont parcourir le réseau à la recherche d’alarme utile pour le processus de corrélation qu’ils sont entrain d’effectuer.

• utilisation d’architecture type peer to peer.

3.15 Discussion

Plusieurs méthodes de corrélation d’alarmesIDSont déjà été avancées. Tout d’abord, la méthode probabiliste qui permet de détecter facilement des variantes d’un scénario.

Mais pour permettre cela, il faut disposer de scénario déjà construits et faire définir à l’utilisateur le degré de similitude souhaité entre 2 variables. De plus, cette méth- ode requiert de comparer les nouvelles attaques avec d’anciens scénarios, il faut donc une base d’attaque validée, il n’est pas possible de détecter les nouvelles attaques. De plus, cet algorithme a été presque uniquement utilisé pour lesNIDS(particulièrement