ACES. Livrable 6.1. Spécifications Détaillées du Gestionnaire de Corrélation

Transcription

1 ACES Livrable 6.1 Spécifications Détaillées du Gestionnaire de Corrélation

2 Résumé L objectif du sous-projet 6 est de réaliser des composants de corrélation d alertes, dont la fonction est d améliorer le diagnostic porté par les alertes émanant de sondes de détection d intrusions. Ce livrable spécifie les mécanismes de corrélation que nous proposons. Leur mise en œuvre est l objet du second livrable de ce sous-projet. Le raisonnement effectué par ces processus de corrélation d alertes s appuie sur les connaissances disponibles concernant 1) le contexte local et global dans lequel les attaques ont lieu, 2) sur les caractéristiques intrinsèques de ces attaques et 3) sur la configuration des sondes qui les détectent. Les mécanismes de collecte des connaissances contextuelles locales et globales sont l objet des sous projets 3 et 4, respectivement ; le sous-projet 5 traite de la configuration des sondes. Le sous projet 2 décrit le modèle M4D4, qui définit formellement l ensemble des concepts et relations qui constitue le domaine des connaissances nécessaires pour raisonner sur les alertes. Le sous-projet 6 décrit pour sa part les mécanismes de raisonnement mis en œuvre pour manipuler ces connaissances afin d améliorer le contenu sémantique des alertes. Il s appuie donc sur le modèle de données M4D4. Ce livrable détaille le fonctionnement interne de certains composants identifiés dans l architecture fonctionnelle des flots de contrôle et de données (livrable du sous-projet 1). Il explicite comment les scénarios d attaques présentés dans ce livrable sont traités par les mécanismes de corrélation.

3 Table des matières 1 Introduction Problématique Corrélation d alertes Contributions Gestionnaire de corrélation Caractéristiques du gestionnaire de corrélation Traitement en ligne vs hors ligne Traitement en série vs parallèle Communication des résultats de la corrélation Spécifications du gestionnaire de corrélation Composants du gestionnaire de corrélation Interface avec M4D Connexion avec Prélude Architecture logique de la plateforme Corrélation mono-événementielle Corrélation avec les vulnérabilités Corrélation avec des rapports de vulnérabilité Corrélation avec des configurations logicielles Reconnaissance de faux positifs Traitement d alertes redondantes Corrélation avec le contexte global Traitements préventifs Corrélation avec des alertes émanant d autres équipements Analyses complémentaires Corrélation multi-événementielle Introduction au langage ADeLe Notion de filtre d événements Opérateurs de corrélation Opérateur Sequence Opérateur NonOrdered Opérateur OneAmong Opérateur Without Opérateur Repeat Corrélation contextuelle Algorithme de corrélation Présentation de GNG Architecture Notions d automate et de plan Traitement des opérateurs de contrainte temporelle Travaux connexes

4 Chapitre 1 Introduction 1.1 Problématique Les outils de détection d intrusions actuels génèrent un volume important d alertes dont le contenu sémantique est souvent pauvre. L excès d alertes provient essentiellement de la présence de fausses alertes ou d alertes non pertinentes (indifféremment désignées faux positifs dans la suite). Selon les études, le taux de faux positifs varie de 40 à 90% du nombre global d alertes. Au problème de faux positifs s ajoutent différents facteurs de multiplication d alertes, parmi lesquels la récurrence et la redondance. Les alertes redondantes proviennent de la détection d un même événement (intrusif ou non) par plusieurs sondes. Le problème de redondance est particulièrement sensible avec les sondes de détection réseau, car il est généralement nécessaire de déployer ce type de sonde sur plusieurs segments du réseau pour obtenir une couverture maximale de détection. En fonction du chemin suivi par les paquets réseau depuis la source d une attaque jusqu à sa cible, plusieurs sondes sont donc susceptibles de détecter une même attaque. Les alertes récurrentes sont souvent aussi des faux positifs. En effet, la probabilité d occurrence de phénomènes normaux (ou bénins) étant largement supérieure à celles des phénomènes réellement intrusifs, si ces phénomènes donnent lieu à des alertes, alors ces alertes sont récurrentes. En tout état de cause, la résolution de l excès global d alertes passe avant tout par l identification des faux positifs. Le problème de sémantique des alertes inclut l évaluation simpliste de la criticité des incidents et la désignation peu explicite des attaques et des protagonistes (victimes et attaquants) par les sondes de détection. Par exemple, la sévérité affichée n est généralement fonction que des dommages potentiels maximaux de la faille exploitée, mais ne prend pas en compte les caractéristiques propres à l attaque et la vulnérabilité de la victime. Enfin, en dépit de l excès d alertes, certaines attaques demeurent non détectées. L amélioration de la complétude de la détection requiert une multiplications de sondes hétérogènes, afin non seulement d accroître la couverture de surveillance, mais aussi de bénéficier de techniques de détections complémentaires ; la multiplication des sondes engendre mécaniquement un accroissement du nombre d alertes, ce qui renforce la nécessité d une analyse complémentaire des alertes en aval de leur production par les sondes de détection d attaques. Le débit d alertes est incompatible avec le temps nécessaire à leur analyse par un exploitant humain. C est pourquoi cette analyse doit être en partie automatisée. 1.2 Corrélation d alertes La corrélation d alertes a pour objectif de faire coopérer les sondes de détection d intrusions, afin d améliorer le taux de détection et de réduire le volume global d alertes, tout en enrichissant leur contenu sémantique. Plusieurs approches de corrélation ont été proposées dans la littérature. Nous ne les énumérons pas dans le présent document, mais nous présentons leur caractéristiques principales. On distingue généralement trois catégories de techniques de corrélation d alertes dans le domaine de la détection d intrusions : 2

5 Corrélation implicite : La corrélation implicite consiste à effectuer des regroupements d alertes sur la base de critères de similarité. L objectif principal de ce type d approche est de synthétiser le volume d information présenté à l opérateur pour lui faciliter la tâche d analyse, en lui permettant de se focaliser sur les incidents prioritaires. Différents termes sont associés à ce type de corrélation, parmi lesquels la fusion, l agrégation ou le clustering d alertes. La fonction prioritaire de ce type d approche n est donc pas tant le diagnostic ou l enrichissement sémantique que la diminution du nombre d alertes. Ces techniques sont néanmoins tout à fait pertinentes. Corrélation explicite : À l instar des méthodes de détection d intrusions par signatures d attaques, la corrélation explicite consiste à confronter le flot d alertes à des scénarios d intrusions spécifiés explicitement (d où leur nom) dans un langage donné. Ces scénarios sont constitués de filtres sur les alertes, liés entre eux par des contraintes logicotemporelles (et, ou, puis, etc.). Lorsque l ensemble des contraintes exprimées dans un scénario sont vérifiées par une séquence d alertes en entrée, une alerte de haut niveau est émise et reliée à l ensemble des alertes ayant participé à l instanciation du scénario. Ces scénarios sont généralement compilés sous la forme d automates à états finis, dont les états correspondent aux étapes du scénario et les transitions sont conditionnées par la correspondance des alertes avec les filtres et le respect des contraintes logico-temporelles. Les scénarios peuvent être utilisés pour reconnaître des phénomènes d attaques impliquant plusieurs alertes et dont le déroulement est déterministe (par exemple la propagation d un ver), ou bien des phénomènes bénins dont l identification requiert plusieurs événements. Ces scénarios peuvent aussi modéliser les différentes étapes d une stratégie d intrusion complexe. Il faut cependant noter que cette dernière utilisation est peu réaliste car l élaboration anticipée des stratégies d attaque sous la forme de scénarios est quasi-impossible du fait du nombre de variantes possibles. Corrélation semi-explicite : La corrélation semi-explicite part du principe que les stratégies d intrusions d un attaquant sont constituées d étapes logiquement liées entre elles et contribuent à l accomplissement d un objectif précis. Ce type de corrélation consiste donc à détecter des correspondances entre les pré-requis (ou pré-conditions d attaques et les conséquences (ou post-conditions) d attaques antérieures. Le résultat de ces techniques de corrélation se présente généralement sous la forme d un graphe d attaque, dont les nœuds sont les attaques référencées dans les alertes et les liens correspondent aux similitudes trouvées entre les pré-conditions et les post-conditions. Si le principe de ce type de corrélation est séduisant, sa mise en pratique est plus problématique. Tout d abord, la corrélation semi-explicite suppose l existance des pré-requis et post-conditions associés à chaque type d attaque, ce qui n est pas le cas actuellement et peu vraisemblable dans l avenir, compte tenu de la difficulté d identifier et de formaliser ces caractéristiques. Ensuite, la corrélation explicite est inadaptée aux flots d alertes rencontrés en environnement opérationel, car la proportion majoritaire de faux positifs conduit ce type d approche à construire des plans inutiles. Enfin, la complexité des mécanismes mis en jeu est incompatible avec le volume d alertes à traiter. D autres approches, difficilement classables, proposent d apporter des solutions pratiques à des problèmes spécifiques des sondes de détection d intrusions. Par exemple, Pietraseck propose de modéliser les phénomènes qui sont réputés pour engendrer des faux positifs dans les réseaux. Les alertes sont alors comparées à ces modèles et en cas de correspondance, la sévérité associée aux alertes est diminuée. Dans la grande majorité des cas, les mécanismes de corrélation proposés dans la littérature partagent une propriété, à savoir l utilisation de données liées au contexte surveillé et des connaissances sur les caractéristiques des attaques. C est pour cette raison que nous avons proposé le modèle M4D4 (c.f. livrables du sous projet 2), qui fédère les informations qui sont nécessaires à la corrélation d alertes. L objectif de ce sous projet est de mettre en œuvre des mécanismes de corrélation qui exploitent les données modélisées. 1.3 Contributions Comme l illustre l état de l art de la corrélation d alertes, la notion de corrélation d alertes recouvre des notions très différentes ; les objectifs poursuivis par les mécanismes de corrélation proposés dans la littérature sont différents, ainsi que les techniques utilisées pour les mettre en œuvre. Pour autant, il est possible de dégager un ensemble de fonctions 3

6 élémentaires partagées par la majorité des mécanismes de corrélation, parmi lesquels la réception, la production, la modification des alertes et l accès aux informations contextuelles. Une première contribution réside dans la conception d une plate-forme générique remplissant ces fonctions élémentaires, sur laquelle des modules de corrélation peuvent se greffer pour effectuer leur traitement. Le gestionnaire de corrélation est cette plate-forme générique, décrit en section 2. Les différents traitements de corrélation sont implémentés sous la forme de processus indépendants. On distingue généralement deux catégories de traitements de corrélation, qualifiés de mono- ou multi-événementiels. En référence au livrable 1.1, les traitements de corrélation mono-événementiels sont notés F 1. Le traitement d un processus F 1 est dit mono-événementiel s il porte sur une seule alerte, indépendamment des alertes reçues antérieurement et ultérieurement. Un module F 1 est donc sans état. Les traitements portent sur le contenu de l alerte et peuvent exploiter des informations externes par interrogation du contexte local et global. Le cas échéant, les informations contextuelles utilisées peuvent être des événements ou alertes présents dans la base de connaissances M4D4. Par exemple, un module F 1 dont l objectif est de déterminer la vulnérabilité d un hôte vis-à-vis d une attaque peut interroger le contexte pour savoir s il existe un rapport de vulnérabilité (qui est un type d événement particulier) relatif à l hôte en question. Les performances attendues des modules F 1 sont élevées. Les traitements multi-événementiels sont notés F n. Un processus de corrélation est qualifié de multi-événementiel si son traitement porte sur une séquence d alertes. Un module F n possède donc un état, qui est modifié au fur et à mesure de la réception des alertes. Cet état peut par exemple correspondre à l évolution d un plan dans le cas d un système de corrélation explicite, ou bien à la mise à jour d un groupe d alertes dans le cas d un système de corrélation implicite. Il est important de distinguer les systèmes de corrélation mono-événementiels utilisant des informations qui correspondent à des alertes reçues antérieurement, des systèmes de corrélation multi-événementiels. Les premiers interrogent le contexte pour prendre une décision (mode pull), tandis que les second adaptent leur état en fonction de la réception des alertes (mode push). Les deux autres contributions du projet résident dans la conception de modules de corrélation mono-événementiel et d un module multi-événementiel. Les premiers sont présentés en section 3 et le second en section 4. Le module de corrélation multi-événementiel enrichit un système existant baptisé GnG, issu de travaux antérieurs menés au sein de Supélec. L ensemble de ces modules exploite les informations disponibles dans une base de connaissances M4D4, c est-à-dire des informations concernant le contexte local et global, les attaques, les vulnérabilités, la configuration des sondes et les alertes reçues préalablement. 4

7 Chapitre 2 Gestionnaire de corrélation Dans cette section, nous spécifions le fonctionnement du gestionnaire de corrélation. Le gestionnaire de corrélation est responsable de l ensemble des services élémentaires rendus aux modules de corrélation, c est-à-dire la réception des alertes issues des sondes, la persistance des alertes, le transfert des alertes aux modules de corrélation et l accès aux données contextuelles. Nous nous focalisons donc ici sur les éléments génériques qui permettent de corréler des alertes. Le principe de fonctionnement des systèmes de corrélation est spécifié dans les sections 3 et 4. Les fonctions de réception et de persistance d alertes sont assurées par un outil existant, Prélude. Nous explicitons la manière dont le gestionnaire de corrélation s interface avec Prélude à la fin de ce chapitre. La figure 2.1 illustre l architecture globale du système de corrélation, dans laquelle le gestionnaire de corrélation joue un rôle central. Le gestionnaire de corrélation reçoit des alertes issues des sondes de détection d intrusions (via le gestionnaire d alertes de Prélude) et transmet leurs références aux différents modules de corrélation après les avoir stockées dans une mémoire cache. Le gestionnaire de corrélation reçoit les alertes produites par les modules de corrélation est relaye leurs requêtes à destination du contexte local (Q CL ) et global (Q CG ), c-à-d. M4D4. Les différents composants évoqués ci-dessus sont détaillés dans la seconde section de cette partie. Dans la première section, nous présentons et justifions certaines caractéristiques du gestionnaire de corrélation. La dernière section fournit le schéma d architecture complet de la plateforme ACES, qui illustre les interactions entre les différents composants identifiés et précise comment ils se positionnent vis-à-vis de l architecture fonctionnelle proposée dans le livrable 1.1 et des sous projets de ACES. 2.1 Caractéristiques du gestionnaire de corrélation Traitement en ligne vs hors ligne D une manière générale, les alertes peuvent être traitées en ligne ou hors ligne par les modules de corrélation. Le traitement en ligne suppose que le traitement d un module de corrélation est déclenché par la réception d une alerte (c-à-d. au fil de l eau ). Le traitement hors ligne suppose que le traitement d un module de corrélation est déclenché autrement que par la réception d une alerte, le plus souvent par une horloge, ce qui suppose que ces modules interrogent régulièrement la base où les alertes précédemment reçues ont été stockées. Le mode de fonctionnement par défaut adopté dans le gestionnaire de corrélation est orienté en ligne : le gestionnaire de corrélation diffuse les références des alertes aux modules de corrélation, pour que ces derniers puissent les traiter en temps réel. Ceci permet notamment de garantir une meilleure réactivité dans les traitement de corrélation. Néanmoins, rien n empêche un module de corrélation de mémoriser localement des alertes qu il reçoit dynamiquement, pour déclencher régulièrement un traitement sur cet ensemble d alertes mémorisé. Par exemple, un module de corrélation statistique qui a besoin de compter des alertes peut mettre à jour les compteurs au fur et à mesure de la réception des alertes et exécuter périodiquement les traitements statistiques. Bien entendu, un module de corrélation en ligne ne peut pas exploiter une information qui serait obtenue après 5

8 Cache d'alertes Module de Corrélation alertes Gestionnaire de Corrélation Module de Corrélation Q_CL Q_CG Gestionnaire de contexte Module de Corrélation Base d'alertes Informations contextuelles FIG. 2.1 Architecture globale du système de corrélation la réception d une alerte. En revanche, il est envisageable que la réception d une alerte par un module de corrélation déclenche de manière synchrone un traitement spécifique ayant pour objectif d obtenir une information nécessaire au module de corrélation. Par exemple, si une attaque exploite vulnérabilité, un module de corrélation en ligne ne peut pas vérifier s il existe un rapport de vulnérabilité plus récent que l alerte établissant la vulnérabilité de la victime ; en revanche, un module de corrélation peut déclencher un audit de vulnérabilité contre la victime pour savoir si cette dernière est affectée ou non Traitement en série vs parallèle Nous distinguons deux types d envoi des alertes par les modules de corrélation par le gestionnaire de corrélation : l envoi en série et l envoi en parallèle. Traitement en parallèle : Un traitement en parallèle consiste pour le gestionnaire de corrélation à envoyer simultanément chaque alerte à l ensemble des module de corrélation. Un traitement en parallèle garantit ainsi que chaque module de corrélation reçoit effectivement chaque alerte originale, ce qui facilite les traitements concurrents (i.e. des traitements différents sur une même alerte). En revanche, le traitement en parallèle complexifie les traitements coopératifs, dans lesquels un ordre dans les traitements entre module de corrélation est souhaité. Enfin, par définition, un traitement strictement parallèle ne permet pas à un module de corrélation de faire de la rétention d alertes (c.f. ci-dessous), ce qui peut s avérer nécessaire compte tenu de la récurrence de certaines alertes. Traitement en série : Le traitement en série correspond à un chaînage des modules de corrélation. Le gestionnaire de corrélation transmet chaque alerte au premier module de corrélation de la chaîne, qui la transmet à son tour au module de corrélation suivant, une fois son traitement terminé ou annulé. En cas d échec, l alerte est transmise inchangée au processus suivant ; en cas de succès, l alerte initiale peut être modifiée ou subsumée par une méta-alerte. Notons que le 6

9 traitement d un module de corrélation peut être long et engendrer un blocage de l ensemble de la chaîne de traitement de corrélation si un tel module se trouve en série. Un traitement en série peut ou non dénoter un ordre logique dans les traitements effectués par les modules de corrélation, mais un ordonnancement volontaire de traitements de corrélation impose de pouvoir chaîner les modules de corrélation. Dans l architecture fonctionnelle de la plate-forme, un ordre est suggéré, qui consiste à exécuter les traitements mono-événementiels avant les traitements multi-événementiels. En résumé, les traitements en série permettent d ordonner les traitements de corrélation et effectuer de la rétention d alertes ; les traitements en parallèle garantissent la remise des alertes à un ensemble de modules de corrélation et limite les problèmes liés à un blocage d un module. On constate donc que ces deux types de traitements doivent être implantés au niveau du gestionnaire de corrélation. Dans un traitement en série, une communication par création d alerte impose à chaque module de corrélation soit de transmettre au processus suivant la méta-alerte et l alerte initiale, soit de ne transmettre que la méta-alerte, en laissant le soin au processus suivant de rapatrier le contenu de l alerte initiale de la base de connaissance (ce qui suppose que les alertes ont été systématiquement stockées en base avant leur traitement par les modules de corrélation). En effet, le format IDMEF ne permet pas d encapsuler des alertes ; une méta-alerte ne peut que contenir des références à des alertes. La première solution n est pas satisfaisante car l ordre dans lequel une méta-alerte et l alerte subsumée doivent être transmises est discutable : si l alerte est transmise avant la méta alerte, le module de corrélation suivant ne sait pas encore que cette alerte est déjà subsumée au moment du traitement ; si la méta-alerte est transmise avant l alerte, le module de corrélation doit consommer les alertes sur sa file d attente pour trouver l alerte en question (qui ne se trouve pas nécessairement juste après la méta-alerte). Nous optons donc pour la seconde solution, qui consiste pour un module de corrélation à rapatrier les caractéristiques d une alerte dont il trouve la référence dans une méta-alerte. Plus généralement, comme nous l avons évoqué en introduction, le gestionnaire de corrélation ne transmet que les références des alertes aux modules de corrélation, pas leur contenu. Tout accès au contenu d une alerte par un module de corrélation passe donc nécessairement par une requête au gestionnaire de corrélation. Afin d éviter que chaque accès se traduise par un accès à la base de données relationnelle où sont stockées l ensemble des alertes ce qui serait prohibitif du point de vue des performances, le gestionnaire de corrélation maintient à jour un cache où sont stockées les alertes les plus récentes ou les plus fréquemment accédées (c.f. Figure 2.1) Communication des résultats de la corrélation Nous nous intéressons ici à la manière dont un module de corrélation peut informer un opérateur de sécurité (c-à-d un exploitant humain) ou un autre module de corrélation du résultat de son traitement. Nous distinguons trois méthodes possibles : la création d une nouvelle alerte, la modification de l alerte et la notification annexe. Création d une alerte Pour un module de corrélation, une manière d informer son environnement du résultat de son traitement peut être de générer une nouvelle alerte. Les alertes créées par les modules de corrélation sont souvent appelées dans la littérature méta-alertes ou hyper-alertes, du fait de leur caractère haut niveau ; nous opterons pour le premier qualificatif dans la suite de ce document. La création d une méta-alerte par un module de corrélation s accompagne généralement de la création d une relation (dite de subsomption ou d inclusion) entre cette méta-alerte et la ou les alertes qui ont contribué à la sa création. Par exemple, un procédé de clustering d alertes peut lier les alertes élémentaires à la méta-alerte qui caractérise le cluster d alertes similaires. Dans le format IDMEF, une méta-alerte est une instance de la classe CorrelationAlert, qui hérite de la classe Alert. Il est important de noter qu une classe CorrelationAlert n encapsule pas le contenu des alertes qu elle subsume ; elle contient uniquement les références de ces alertes (c-à-d, leurs identifiants). Nous verrons par la suite que cette propriété a un répercussion sur le traitement en série ou en parallèle des alertes par les modules de corrélation. Modification d alertes Pour un module de corrélation d alertes, une seconde manière (complémentaire de la précédente) d informer son environnement du résultat de son traitement peut être de modifier le contenu d une alerte 7

10 existante. Dans la perspective de traitements concurrents sur les alertes, toute modification d une alerte est problématique. En effet, une alerte qui n est initialement pas candidate pour un système de corrélation, peut le devenir ultérieurement suite à une modification par un autre module de corrélation. La modification d une alerte par un module de corrélation implique donc éventuellement la ré-émission de cette alerte aux autres modules de corrélation, ce qui peut avoir des répercussions négatives sur les performances du système. De plus, les modules de corrélation qui se voient réadresser des alertes modifiées doivent être capables d identifier cette alerte comme ayant déjà été traitée, afin de ne pas réitérer un raisonnement déjà effectué. Nous pouvons distinguer quatre types de modifications : Modification d attribut existant : La modification de la valeur d un attribut d alerte existant est une fonctionnalité discutable. En effet, au cours du traitement d une alerte par un module de corrélation, toute modification externe de la valeur d un attribut de cette alerte (typiquement par un système de corrélation concurrent) peut engendrer une inconsistance dans le raisonnement du module de corrélation. De plus, la perte d information que constitue une modification est peu souhaitable dans un contexte de sécurité. Nous excluons donc la modification d attributs existants d une alerte par un module de corrélation. Suppression d attribut : Ce cas est similaire au précédent ; nous l excluons donc aussi. Ajout d attribut : L ajout d un attribut à une alerte par un module de corrélation est vraisemblablement une fonctionnalité incontournable pour permettre d enrichissement du contenu des alertes sans nécessairement passer par la création d une méta-alerte. Suppression d alertes : La suppression d alertes peut être perçue de deux façons différentes : Suppression complète : l alerte est éliminée (filtrée) par le module de corrélation et n est pas mise à disposition de l opérateur. Comme la suppression et la modification d attributs, la suppression d alertes est discutable dans un contexte sécuritaire. Rétention d alerte : la rétention d alerte consiste pour un module de corrélation à ne pas transférer une alerte aux autres modules de corrélation. En ce sens, la rétention d alerte peut être perçue comme une suppression d alerte, à ceci près que l alerte d origine est préalablement stockée et mise à disposition de l opérateur. Bien entendu, la rétention d alerte implique un traitement en série des alertes. Afin de prendre en compte la modification des alertes, nous supposons que l ensemble des modules de corrélation partagent une mémoire où sont stockées les alertes. C est le cache d alerte qui joue ce rôle (c.f. Figure 2.1). Toute modification d alerte passe par une requête au gestionnaire de corrélation, qui garantit que deux modifications concurrentes sur la même alerte n ont pas lieu simultanément par deux modules de corrélation distincts. Une alerte absente du cache est rapatriée de la base de données d alertes par le gestionnaire de corrélation. Notification annexe : Une troisième alternative permettant à un module de corrélation d informer son environnement du résultat de son traitement peut consister à associer une description du résultat à l alerte IDMEF, sous la forme d une annexe. Les triplets (A,V,R) évoqués dans le livrable 1.1 sont des exemples de messages annexes. L intégration des résultats de différents modules de corrélation concernant une même alerte peut alors être sous la responsabilité d un module spécifique, ayant une fonction d arbitrage sur des résultats de corrélation éventuellement antagonistes. Cette fonction d arbitrage peut être assurée par le module Dec de l architecture fonctionnelle. On notera que les annexes peuvent éventuellement être stockées en tant que données additionnelles (AdditionalData) des alertes plutôt qu en tant que messages externes. Il faut noter que cette solution nécessite la modification du contenu des alertes par ajout d attributs. Cette solution est pratique car elle n impose aucune modification des implémentations existantes de bus d alertes utilisant IDMEF (c.f. section Prélude ci-après). Néanmoins, cette solution est peu élégante car la structure (type, valeur) des données additionnelles n est pas suffisamment expressive pour distinguer les résultats de différents modules de corrélation sur une même alerte. 2.2 Spécifications du gestionnaire de corrélation Nous détaillons dans cette section le fonctionnement du gestionnaire d alertes et ses composants périphériques. Dans un second temps, nous montrons comment ce gestionnaire de corrélation s interface avec une plate-forme de gestion d alertes existante, Prelude. 8

11 2.2.1 Composants du gestionnaire de corrélation Le gestionnaire de corrélation est constitué d un ensemble de briques de base : un gestionnaire, chargé notamment de recevoir les alertes issues des sondes, de les mettre en cache et de les transmettre aux différents modules de corrélation, par l intermédiaire de canaux d alertes et de répartiteurs d alertes. Ces différents composants sont décrits dans la suite. Cache d alertes Le cache d alerte est une mémoire partagée par l ensemble des composants de corrélation, qui permet de stocker les alertes les plus récentes ou accédées fréquemment. Tout accès en lecture ou en écriture aux alertes contenues dans le cache passe par le gestionnaire de corrélation, qui garantit que l accès se fait en exclusion mutuelle. Les modifications apportées aux alertes se font exclusivement dans le cache. Une alerte absente du cache d alerte est rapatriée complètement par le gestionnaire de corrélation. Un processus exécuté en arrière plan est chargé de scruter le contenu du cache, de répercuter les modifications apportées aux alertes au niveau de la base de données relationnelle et de maintenir la taille du cache en dessous d un seuil fixé. Canal d alertes Un canal d alertes est une file d attente de type FIFO alimentée par un producteur d alertes (un module de corrélation, un répartiteur d alertes ou un analyseur), où les alertes sont stockées en attente d être consommées par un module de corrélation pour être analysées, ou bien par un répartiteur d alertes pour être diffusées à d autres modules de corrélation. Les objets stockés dans un canal d alertes sont en réalité des références d alertes (c-à-d. leurs identifiants) qui sont utilisés par les modules de corrélation pour accéder au contenu des alertes, qui est stocké au niveau du gestionnaire de corrélation. Répartiteur d alertes Les répartiteurs d alertes sont destinés au traitement en parallèle des alertes par des modules de corrélation. Un répartiteur d alertes est constitué d un canal d entrée et de un ou plusieurs canaux de sortie. Un répartiteur d alertes consomme les alertes disponibles sur son canal d entrée et les diffuse systématiquement sur chaque canal de sortie, de manière asynchrone. Module de corrélation Un module de corrélation implémente un traitement d alerte particulier, tel que ceux décrits dans les sections 3 et 4. Un module de corrélation possède un canal d entrée et un canal de sortie d alertes. Deux modules de corrélation peuvent donc être agencés en série, si le canal de sortie de l un coïncide avec le canal d entrée du module de corrélation suivant. L agencement en parallèle de plusieurs modules de corrélation passe par l utilisation d un répartiteur d alertes (c.f. figures 2.2 et 2.3). La logique de traitement d alertes doit se faire explicitement, en associant entre eux elles les entrées et les sorties des modules de corrélation. Le cas échéant, cet agencement pourra être paramétré dans un fichier de configuration plutôt que codé en dur dans l application du gestionnaire de corrélation. Le traitement d un module de corrélation est synchrone : une alerte n est consommée que lorsque le traitement portant sur l alerte précédente est terminé. Un module de corrélation est implémenté sous la forme d un processus léger, synchronisé sur ses canaux d entrée et de sortie : un module de corrélation dont le canal d entrée est vide est mis en sommeil jusqu à ce qu une nouvelle alerte soit mise à disposition, ce qui provoque son réveil. Un module de corrélation peut aussi être mis en sommeil si son canal de sortie est plein. On notera que le blocage d un module peut engendrer un blocage en chaîne des modules de corrélation qui le précèdent. Si le traitement effectué le permet, plusieurs instances d un même module de corrélation peuvent être exécutées en parallèle au sein d un même module, pour accélérer le traitement des alertes. Toute émission d alerte par un module de corrélation se fait par un appel explicite à la méthode de dépôt d alerte du canal de sortie. Par conséquent, le transfert d une alerte non modifiée par un module de corrélation se fait de manière explicite. 9

12 MaCo : Manager de Corrélation MoCo : Module de Corrélation Canal d'alertes MaCo MoCo MoCo MoCo FIG. 2.2 Agencement en série des modules de corrélation MaCo : Manager de Corrélation MoCo : Module de Corrélation RepAl : Répétiteur d'alerte Canal d'alertes MoCo MaCo MoCo RepAl MoCo MoCo MoCo FIG. 2.3 Agencement en parallèle et série des modules de corrélation Les différents modes de notification du résultat du traitement d un module de corrélation sont mis en œuvre des manières suivantes : La notification par création d alerte se fait simplement par la création d une nouvelle alerte, suivi de son dépôt sur le canal de sortie. La modification du contenu d une alerte existante est déléguée au gestionnaire de corrélation, au niveau duquel est stocké le contenu des alertes. Un module de corrélation souhaitant modifier une alerte invoque donc les méthodes idoines au niveau du serveur. Chaque modification d alerte se fait en exclusion mutuelle : à un instant donné, un seul module de corrélation peut modifier le contenu d une alerte. En revanche, plusieurs modifications simultanées peuvent être effectuées par des modules de corrélation différents, à condition que ces modifications portent sur des alertes distinctes. Les éventuels modules de corrélation désirant apporter des modifications de manière concurrente sur une même alerte sont mis en attente au niveau de l alerte, jusqu à ce que le module courant ait terminé sa modification. Rappelons que seules les modifications par ajout d attributs sont retenues dans ce projet. L ajout d une nouvelle alerte en tant que fille d une méta-alerte existante fait partie des modifications d alertes possibles. On veillera à ce que ce système de modification d alerte ne provoque pas d interblocage entre deux modules de corrélation étant mis mutuellement en sommeil sur deux alertes. La rétention d alerte par un module de corrélation se fait simplement par un chaînage en série et la non-transmission d une alerte sur le canal de sortie. Le canal de sortie d un module de corrélation peut être connecté à n importe quel autre canal d entrée existant, selon que les méta-alertes produites par le module de corrélation doivent être mises à disposition des autres modules de corrélation ou non : Le canal de sortie d un module de corrélation peut être relié au canal d entrée du gestionnaire de corrélation, qui diffusera naturellement la nouvelle alerte aux autres modules de corrélation. Pour éviter des boucles infinies de traitement d alertes consommées et produites par un même module, on suppose que les modules de corrélation sont équipés de filtres permettant de ne pas traiter les alertes dont l identité du producteur correspond à celle du 10

13 module. Le canal de sortie d un module de corrélation peut être relié au canal d entrée d un autre module de corrélation ou d un répartiteur d alertes situé en aval. Éventuellement, le canal de sortie d un module de corrélation peut-être un relié à un trou noir, si ce module de corrélation ne produit aucune méta-alerte et se contente de modifier le contenu d alertes existantes. Dans tous les cas, on suppose que toute nouvelle méta-alerte créée par un module de corrélation est systématiquement mémorisée au niveau du gestionnaire de corrélation. On notera que la question de l enchaînement des modules de corrélation n est pas triviale, ou du moins peut être litigieuse. Par exemple, considérons un phénomène dans lequel des alertes fortement récurrentes sont reçues par le gestionnaire de corrélation, avertissant d occurrences d attaques exploitant une vulnérabilité référencée. Le caractère récurrent des alertes fait qu un module d agrégation d alertes est tout indiqué. L exploitation de la vulnérabilité impose une vérification du succès de l attaque. Les deux ordres de traitement se justifient : la vérification du succès de l attaque peut porter sur une méta-alerte qui synthétise chacune des alertes individuelle et présente l avantage de limiter le nombre de vérifications de vulnérabilité. L agrégation peut aussi s appliquer sur des alertes pour lesquelles le diagnostic de succès a été effectué de manière individuelle. Cet ordre impose un surcoût de traitement, mais permet éventuellement de distinguer deux groupes d alertes distincts : celui englobant les alertes pour lesquelles le diagnostic est positif et celui pour lequel les diagnostics sont négatifs (suite au patch d une machine, par exemple). L idéal serait d automatiser le choix de l ordre des traitements. Nous n abordons pas ce problème dans le cadre du projet ACES. Le choix de l ordre du traitement des alertes est laissé à l administrateur du système de corrélation. Gestionnaire de corrélation Le gestionnaire de corrélation reçoit les alertes IDMEF de l ensemble des sondes, mémorise leur contenu localement et transmet leurs références aux modules de corrélation. Le gestionnaire de corrélation est donc constitué d un canal d entrée et d un canal de sortie d alertes. Les alertes reçues par le manager de corrélation ne sont pas directement stockées en base de données ; elles sont mémorisées dans l espace d adressage du processus, pour permettre un accès rapide au contenu des alertes par les modules de corrélation, à partir de leur identifiant. Un processus exécuté en arrière-plan est chargé du stockage en base des alertes, lorsque le volume d alertes stockées en mémoire excède un seuil donné, qui dépend de la quantité de mémoire vive disponible. Le gestionnaire de corrélation sert d interface pour l accès au contenu de n importe quelle alerte : si un module de corrélation demande d accéder au contenu d une alerte qui n est plus présente en mémoire vive, le gestionnaire de corrélation recharge l alerte en mémoire vive à partir de la base de données où l ensemble des alertes sont stockées. Du point de vue d un module de corrélation, l accès au contenu d une alerte est donc transparent. Le gestionnaire de corrélation fait enfin fonction d interface pour le traitement des requêtes en rapport avec le contexte global et local : il reçoit les requêtes émanant des modules de corrélation sous la forme de prédicats du premier ordre, délègue le traitement aux composants Q CL et Q CG, et transmet la réponse au module demandeur. La figure 2.4 représente le diagramme de classes simplifié de ces différents composants Interface avec M4D4 M4D4 est un modèle de données qui fédère les concepts et relations nécessaires au raisonnements sur les alertes effectués par les modules de corrélation. Ce modèle de données contextuelles est décrit dans le livrable 2.2 du projet. Les interactions entre les modules de corrélation et le contexte est géré par un composant particulier du gestionnaire de corrélation, le gestionnaire de contexte. Le gestionnaire de contexte communique avec le contexte global (Q C G), le contexte local (Q C L), ainsi qu avec les bases d informations relatives aux attaques, aux vulnérabilités et à la configuration des sondes (c.f. Figure 2.1 et livrable 1.1). Les bases de données contextuelles utilisées dans le cadre de ACES possèdent leur propre schémas de données. M4D4 peut être perçu comme un langage de description unificateur des informations manipulées par les modules de corrélation. Ce langage constitue une couche d abstraction qui affranchit les modules de corrélation de la connaissance des structures de données spécifiques utilisées par les systèmes de collecte d informations contextuelles. Le rôle du 11

14 Correlation Node output channel Alert Hub input channel input channel 1 Correlation Manager Correlation Module 1 output channels 1 n Alert Channel 1 Alert FIFO 1 Alert Cache n Alert FIG. 2.4 Diagramme de classes gestionnaire de corrélation est donc de traduire des requêtes exprimées en M4D4 en requêtes compatibles avec les schémas de données utilisées par les bases d informations concrètes. Le modèle M4D4 utilise le formalisme de la logique du premier ordre. Les requêtes d interrogation du contexte par le modules de corrélation ont donc naturellement la forme d un but à la Prolog. Le gestionnaire de contexte a comme objectifs : de recevoir les requêtes des modules de corrélation, de traduire ces requêtes dans le langage de requêtes de la base de données cible (en l occurrence SQL), d unifier les variables libres de ce but avec les faits disponibles dans différentes bases de données, de fournir le résultat au module de corrélation qui le demande, sous la forme d une liste de n-uplets ((X 1,V 1 ),...,(X n,v n )), où X i représente le nom d un variable libre et V i une valeur de cette variable. Une requête peut être par exemple : nodeaddress(x, ),hosts(x,y ),so ftware(y,z,, os, ),Z debian Le langage permet d exprimer des contraintes sur les variables grâce aux opérateurs ==,! =, <, <=, >, >= et pour la comparaison à une expression régulière. Les prédicats portant sur M4D4 sont paramétrables (ici nodeaddress, hosts, so f tware), ainsi que leur relation avec les tables de la base de données interrogée. La reconnaissance des prédicats M4D4 et l accès au tables de la base M4D4 repose sur : le paramétrage du gestionnaire de contexte par la définition des prédicats ; la définition de vues équivalentes à ces prédicats sur les tables des bases concrètes (nom de vues identiques aux noms de prédicats, noms de champs identiques aux noms d arguments) ; il s agit de reporter l optimisation de l exécution des requêtes sur le moteur de la base de données ; Il est envisageable de déduire automatiquement ces vues à partir des prédicats visés, du schéma de la base de données et de la correspondance entre les champs de prédicats et les champs des tables (les tables et leurs clés étrangères permettant de constituer un graphe, les jointures correspondent à un chemin dans ce graphe). L algorithme de principe du gestionnaire de contexte est le suivant : Analyse du but par un analyseur récursif descendant, permettant de constituer une liste des arbres abstraits des prédicats M4D4, une liste des contraintes sur les variables et une table des variables avec la liste des références 12

15 par les prédicats M4D4 ; Vérification de l appartenance de la liste des variables sur laquelle projeter les tuples à la liste des variables du but ; Génération de la requête SQL Connexion avec Prélude Nous détaillons ici comment le gestionnaire de corrélation décrit précédemment s interface avec l outil Prélude. Présentation de Prélude Prélude 1 est un système de gestion d événements de sécurité (SEMP, Security Event Management Product) opensource. Prélude est constitué de trois types de composants : des sondes, un gestionnaire d alertes prelude-manager et une console d alertes (prewikka). Ces composants sont basés sur une bibliothèque commune (libprelude) et remplissent les différentes fonctions attendues d un SEMP : Bus d alertes : Le manager Prelude remplit la fonction de bus d événements. Un mécanisme d abonnement permet à des composants de se connecter au manager pour émettre et/ou recevoir des alertes. Conformément à l architecture des IDS définie par le groupe de travail IDWG (Intrusion Detection Working Group) de l IETF, les sondes sont des producteurs d alertes et les composant de corrélation sont des consommateurs et producteurs de nouvelles alertes, qui résultent de la corrélation des alertes entre elles et/ou avec des informations contextuelles. Deux managers d alertes peuvent être connectés entre eux, ce qui permet de construire une hiérarchie de managers. Le manager Prélude gère les files d attentes d alertes qu il reçoit sur son interface d entrée. Les alertes échangées entre les composants sont formattées en IDMEF. Le bus d alertes possède en outre des propriétés souhaitables de sûreté de fonctionnement. Par exemple, le canal d alertes est chiffré et requiert de la part des composants une authentification mutuelle. Des mécanismes de reprise sur panne garantissent pour leur part l absence de perte d alertes, en cas de coupure de connexion entre les composants. Persistance des alertes : Le manager Prelude est responsable de la persistance des alertes reçues des différents abonnés. Le stockage s effectue dans une base de donnée dont le schéma relationnel est calqué sur le format IDMEF. Alternativement, le stockage peut s effectuer dans un fichier à plat, dans le format IDMEF ou CSV (Comma Separated Variable). Nous optons ici pour le stockage en base de données, pour permettre aux composant M4D4 d interroger les bases de données d alertes. Présentation des alertes d alertes. Prélude inclut un composant de visualisation d alertes basé sur la base de données On notera enfin que l utilisation du standard IDMEF et l API offerte par la bibliothèque Prélude facilitent considérablement l intégration de nouvelles source d alertes. Certaines sondes sont dores et déjà compatibles avec Prelude, notamment Snort, que nous utilisons dans le cadre de ACES comme sonde de détection d intrusions réseau. Connexion du gestionnaire de corrélation avec Prélude Des fonctions de corrélation sont actuellement en cours de conception dans le projet Prélude. Il est prévu que différents plugins de corrélation puissent se connecter à un gestionnaire d alerte, mais l implémentation semble encore peu mature et n offre pas la souplesse nécessaire au différents types de traitements de corrélation envisagés. C est pour cette raison que nous préférons concevoir notre propre gestionnaire de corrélation et contribuer ainsi au développement de Prélude

16 Le gestionnaire de corrélation de la plateforme ACES est simplement implémenté sous la forme d un processus abonné à un gestionnaire d alertes Prélude. Le gestionnaire d alerte reçoit l ensemble des alertes issues des sondes, les stocke dans une base de données relationnelle et les transmet au gestionnaire de corrélation. En référence à l architecture fonctionnelle des flots de données et de contrôle (c.f. Figure 2.5), nous suggérons que les messages en mode push soient formattés en IDMEF par les sondes, puis envoyés à un manager Prélude, qui le transmet au gestionnaire de corrélation. 2.3 Architecture logique de la plateforme Les figures 2.5 et 2.6 illustrent toutes les deux les relations entre les différents composants de la plateforme ACES constituée des composants de corrélation, de la base de connaissance et des différents systèmes chargés d alimenter cette base de connaissance avec des informations relatives au contexte, aux attaques et à la configuration des sondes. Elle représente aussi l intégration de Prélude au sein de cette plateforme. La première figure met en évidence les composants de l architecture fonctionnelle des flots de données et de contrôle identifiés dans le livrable 1.1. On notera que la division F 1 /F n des différents types de modules de corrélation et l agencement des modules sont arbitraires et ont uniquement un but illustratif. La seconde figure montre pour sa part les sous projets dans lesquels ces composants sont développés. Module de Corrélation (MoCo) Configuration des sondes IDS IDS Sondes Alertes Gestionnaire d'alertes Prelude Alertes Events & Alerts Gestionnaire de Corrélation (MaCo) Module de Corrélation (MoCo) RepAl Module de Corrélation (MoCo) Module de Corrélation (MoCo) F1 FN Base de faits et règles M4D4 Q_CL et Q_CG Contexte Global Topologie Cartographie Attaques & Vulnérabilités Honeypots Sondes Passives DNA OSVDB OVAL CG CL FIG. 2.5 Gestionnaire de corrélation v-à-v de l architecture fonctionnelle 14

17 Module de Corrélation (MoCo) IDS IDS Sondes Alertes Gestionnaire d'alertes Prelude Gestionnaire de Corrélation (MaCo) Module de Corrélation (MoCo) RepAl Module de Corrélation (MoCo) Configuration des sondes SP5 Alertes Events & Alerts Module de Corrélation (MoCo) Base de faits et règles M4D4 SP2 SP6 Contexte Global Topologie Cartographie Attaques & Vulnérabilités Honeypots Sondes Passives DNA OSVDB OVAL SP4 SP3 SP2 FIG. 2.6 Gestionnaire de corrélation v-à-v des WP 15

18 Chapitre 3 Corrélation mono-événementielle 3.1 Corrélation avec les vulnérabilités L objectif de ce type de corrélation consiste à évaluer le succès d une attaque exploitant une vulnérabilité en vérifiant si la vulnérabilité exploitée est effectivement présente sur la victime. Deux techniques complémentaires peuvent être envisagées pour y parvenir, que nous présentons dans la suite de cette section Corrélation avec des rapports de vulnérabilité Principe La première technique de corrélation avec les vulnérabilité consiste simplement à exploiter les rapports d audits fournis par des scanners de vulnérabilités. Ce schéma de corrélation est probablement l un des premiers à avoir été proposés dans la littérature. À la réception d une alerte faisant référence à une attaque exploitant une vulnérabilité identifiée V contre un hôte H, ce schéma de corrélation consiste à vérifier si il existe un rapport de vulnérabilité ayant été reçu par le passé, faisant état de la présence de V sur H. Dans l affirmative (et à condition que le rapport ne soit pas obsolète), la sévérité de l alerte peut être augmentée ; dans la négative, celle-ci peut être diminuée. La question de l actualité des rapports de vulnérabilité est cruciale, mais nous ne l abordons pas dans ce document car la gestion de l obsolescence des rapports est une problématique propre aux sondes. Ce schéma de corrélation repose sur une identification commune des vulnérabilités par les sondes de détection d intrusion, d une part, et par les scanners de vulnérabilité, d autre part. Différents systèmes de nommage peuvent être utilisés à cet effet, notamment CVE, BugTraq, Nessus. Schéma de corrélation Étant donnés un hôte h et une classe d attaque k présents dans une alerte, la formule suivante traduit la requête existe-t-il une vulnérabilité V exploitée par k qui a été détectée sur h et rapportée dans un rapport de vulnérabilité? : exploits(k,v ) report(r, h,v ) Une réponse positive à cette requête (c-à-d une instanciation de V et R) indique que le rapport d audit R établit que h est affecté par la vulnérabilité V exploitée par l attaque k. Une réponse négative peut indiquer soit que la vulnérabilité est absente, soit que l information n est pas disponible (auquel cas aucune conclusion définitive sur la vulnérabilité de la victime ne peut être tirée). Pour distinguer ces deux possibilités, il est possible d interroger le contexte pour savoir s il existe un scanner de vulnérabilité configuré pour tester la présence de V sur h : monitors(s,v,h) message(r,s) report(r,h, ) 16

19 où S symbolise l identifiant de scanner à l origine d un message R, qui est aussi un rapport de vulnérabilité relatif à h (v représente ici une instanciation de V précédemment évoqué). Une réponse positive à cette requête signifie que le scanner est effectivement configuré pour effectuer des audits périodiques pour tester la présence de V sur h et qu au moins un audit de h a déjà été effectué (indiqué par la présence d un rapport R). Cette dernière condition doit être vérifiée, sinon le système de corrélation pourrait conclure qu une victime est immunisée (car un scanner est correctement configuré), alors qu en réalité aucun audit n a encore été effectué. On suppose donc tout audit de vulnérabilité déclenche au moins un message message(r, S) permettant de connaître la date du dernier audit. Pour distinguer l absence de connaissance sur l état de vulnérabilité de la victime de son immunité, le contexte local pourrait aussi mémoriser des faits traduisant l absence de vulnérabilité (i.e. report(r,v, h)). Cependant, les systèmes d audit ne fournissent généralement que les présences de vulnérabilité. Résultat de la corrélation L annonce du résultat de la corrélation se fera par la construction d une méta-alerte subsumant l alerte originale. Le contenu de la méta-alerte est le même que l alerte originale, à l exception des champs de la classe IDMEF Impact suivants : Severity = 3 si la victime est vulnérable, 1 sinon. Completion = 1 si la victime est vulnérable, 0 sinon. Le champ name de la CorrelationAlert est un champ libre qui précise la raison de la corrélation ; dans le cas présent, les chaînes suivantes seront utilisées : Tested vulnerable victim pour une victime vulnérable et Tested and immune victim pour une victime non vulnérable. L absence d information relative à la vulnérabilité de la victime ne donne pas lieu à la création de méta-alerte Corrélation avec des configurations logicielles Le schéma de corrélation précédent suppose l existence de rapports de vulnérabilités pour évaluer le succès des attaques. Cependant, les rapports ne sont pas toujours disponibles dans les réseaux. En effet, ces derniers peuvent avoir des effets de bord peu souhaitables sur l environnement surveillé. Nous présentons ici un schéma de corrélation alternatif, dont l objectif est le même que le précédent, mais qui n utilise pas de rapports de vulnérabilités. Principe Les vulnérabilités sont des failles introduites involontairement au cours l ensemble des phases de conception d un logiciel (spécification, conception, configuration). Les vulnérabilités connues sont donc généralement associées à une ou plusieurs configurations logicielles. Une configuration logicielle est un ensemble de logiciels dont la présence conjuguée sur une machine provoque la faille. Par exemple, la présence d une version spécifique d un serveur applicatif sur un système d exploitation précis peut constituer une configuration vulnérable. L objectif de la corrélation avec des configurations logicielles est d évaluer le succès d une attaque en comparant les configurations d une vulnérabilité exploitée par une attaque avec la configuration effective de la victime de l attaque. Cette comparaison se base sur les logiciels affectés par une configuration, d une part, et sur ceux effectivement hébergés par les hôtes du réseau, d autre part. Le principe de la corrélation consiste à accroître le niveau de sévérité d une attaque exploitant une vulnérabilité affectant des logiciels hébergés par la victime. Cependant, statuer sur le succès d une attaque sur la base d une correspondance entre les logiciels affectés par une vulnérabilité et ceux hébergés par la machine nécessite un niveau de détail extrêmement fin dans les observations fournies par les outils de collecte de la cartographie et les bases de vulnérabilité. En effet, une vulnérabilité affecte généralement une version très spécifique d un logiciel ou d un système d exploitation. Les systèmes de cartographie ne sont généralement pas capables de fournir ce niveau de détail. Nous serions donc contraints d effectuer des comparaisons grossières entre les configurations affectées et celles observées sur les hôtes. Le diagnostic de succès de l attaque serait donc très incertain : même en cas de correspondance entre 17

20 les logiciels affectés et ceux hébergés par un hôte, le système de corrélation ne pourrait que supposer le succès de l attaque, sans le garantir. Par conséquent, en pratique, nous raisonnerons à l inverse, en diminuant le niveau de sévérité d une attaque dont la vulnérabilité affecte des logiciels absents de la victime. Par exemple, savoir qu une victime héberge un système d exploitation Linux suffit à diagnostiquer l échec d une attaque exploitant la vulnérabilité CAN , qui correspond au ver Blaster. A contrario, diagnostiquer le succès de cette attaque nécessite d avoir des informations beaucoup plus détaillées (numéro de version ou de patch) sur la victime, si celle-ci héberge Windows. L échec de la corrélation traduit alors le fait que la victime est potentiellement vulnérable. En plus des difficultés techniques liées à l identification précise des logiciels hébergés par les hôtes du réseau, se pose le problème de la dénomination de ces logiciels par les outils de collecte de la cartographie d une part, et les bases de vulnérabilités d autre part. Il n existe à l heure actuelle aucune convention de nommage des logiciels. Par conséquent, les différentes dénominations utilisés dans les systèmes sont non seulement rarement compatibles entre elles, mais sont en plus souvent entachées d incertitudes, voire d erreurs, et manquent de cohérence. Par exemple, un système peut nommer une version de Windows Windows 2000, alors qu un autre le nommera Win2k. Un prérequis à toute tentative de raisonnement sur le succès des attaques à partir des vulnérabilités consiste donc à construire un référentiel unique des identifiants de logiciels. Nous ne détaillons pas ici la construction de ce référentiel de nommage, qui est décrit dans le livrable 3.1 et nous supposons que l ensemble des noms de logiciels sont normalisés. Schéma de corrélation Comme évoqué précédemment, une vulnérabilité n affecte généralement un seul logiciel, mais au moins une configuration, une configuration étant un ensemble de logiciel dont la présence conjuguée est nécessaire pour qu un hôte soit affecté. Étant donnés un hôte H et une vulnérabilité V présents dans une alerte, le système de corrélation estimera qu un hôte n est pas vulnérable si la condition suivante est satisfaite : où est défini de la manière suivante : vulnerability(v ) node(h) C.a f f ects(v,c) ( S V.takespartin(S V,C) ( S H.hosts(H,S H ) S V S H )) S 1 S 2 S 1 S 2 S 1 S 2 S 1.type S 2.type S 1.type = S 2.type S 1.name S 2.name S 1.type = S 2.type S 1.name = S 2.name S 1.version S 2.version S.name, S.type et S.version désignent respectivement le nom, le type et la version d un logiciel. On suppose que la relation est définie sur l ensemble des versions de logiciels. Cette règle dit qu un hôte H n est pas affecté par la vulnérabilité V si chaque ( C...) configuration vulnérable C inclut au moins un logiciel S V qui ne correspond ( ) à aucun ( S H ) des logiciels S N effectivement hébergés (hosts(...)) par H. Dans le cas contraire, la victime est peut-être vulnérable. Comme dans le cas de la corrélation avec des rapports de vulnérabilité, on distinguera plusieurs cas : La règle précédente est satisfaite, ce qui signifie que la victime n est pas vulnérable, donc que l attaque est un échec. La règle précédente n est pas satisfaite, ce qui signifie : Soit qu au moins une configuration vulnérable correspond à la configuration de l hôte, auquel cas l attaque est peut-être un succès. Soit que la configuration de la victime est inconnue. Aucune conclusion ne peut alors être tirée sur le succès de l attaque. On supposera que la configuration d un hôte est inconnue si aucune information cartographique n est disponible à son sujet. 18

21 Résultat de la corrélation L annonce du résultat de la corrélation se fera par la construction d une méta-alerte subsumant l alerte originale. Le contenu de la méta-alerte est le même que l alerte originale, à l exception des champs de la classe IDMEF Impact suivants : Severity = 3 si la victime est vulnérable, 1 sinon. Completion = 1 si la victime est vulnérable, 0 sinon. Le champ name de la CorrelationAlert est un champ libre qui précise la raison de la corrélation ; dans le cas présent, les chaînes suivantes seront utilisées : Tested vulnerable victim pour une victime vulnérable et Tested and immune victim pour une victime non vulnérable. L absence d information relative à la vulnérabilité de la victime ne donne pas lieu à la création de méta-alerte. 3.2 Reconnaissance de faux positifs Principe L analyse des alertes non pertinentes et récurrentes, qui représentent une large majorité de l ensemble des alertes émises par les sondes de détection d intrusions montre que ces alertes sont souvent engendrées par le comportement normal d entités du réseau, dont l activité nominale est ressemble à une activité intrusive, du point de vue des sondes de détection d intrusions. Dans certains cas, l activité à l origine des fausses alertes provient d un comportement erratique, mais dans tous les cas les activités sont bénignes. Exemple 1 : Les proxies web sont des systèmes dont la fonction est de relayer les requêtes HTTP des utilisateurs internes d un réseau vers des serveurs web. Le fonctionnement nominal d un proxy engendre un grand nombre de connexions sur le port 80 de serveurs externes, car plusieurs utilisateurs sont susceptibles de soumettre des requêtes simultanément. L initiation d un grand nombre de connexions en un laps de temps court depuis une même machine, à destination de plusieurs serveurs, sur un même port, est caractéristique d une attaque par balayage de port. Si l entité agissant en qualité d attaquant est un proxy web, les alertes émises par un IDS réseau situé en aval du proxy sont en réalité des fausses alertes. Exemple 2 : Du fait de leur fonctionnement normal, un proxy web reçoit des requêtes HTTP des utilisateurs internes du réseau, à destination de l extérieur. Ces requêtes peuvent contenir des éléments suspect (accès à des scripts cgi réputés vulnérables, utilisation d encodage dans les URLs, etc.) susceptibles d engendrer des alertes par des sondes de détection d intrusions situées en amont des proxies, qui confondent le proxy avec le destinateur final des requêtes HTTP 1. La présence de ces éléments suspects dans les requêtes HTTP pourrait éventuellement justifier l émission d alertes si ces requêtes étaient adressées à des serveurs web internes, mais en l occurrence, ces requêtes sont adressés à des serveurs externes, dont on ne connaît pas la configuration. Surtout, le proxy n est pas le destinataire final des requêtes. L objectif de ce schéma de corrélation est de modéliser les profils des entités dont le comportement est à l origine des fausses alertes. Ces profils peuvent souvent se ramener à un ensemble de caractéristiques des attaques et des entités intervenant en qualité d attaquant et/ou de victime dans les alertes. La corrélation consiste alors à confronter chaque alerte reçue à l ensemble des profils réputés pour engendrer des fausses alertes ; une alerte dont les caractéristiques correspondent à un profil connu est qualifiée de fausse alerte. Un profil correspond donc à un filtre d alerte, c est-à-dire une conjonction de contraintes sur les attributs des alertes, pouvant faire intervenir des éléments du contexte local. Dans les deux exemples précédents, les proxies web peut donner lieu à deux profils différents. Le premier profil dit que les attaques de type balayages IP dont l attaquant correspond à une machine dont une fonction est proxy web (i.e. héberge un produit de type proxy) sont en fait des activités normales. Le second profil dit que les attaques de type web dont l attaquant est interne et dont la victime correspond à une machine remplissant la fonction de proxy web sont en fait des activités normales. 1à condition que le proxy HTTP écoute sur le même port qu un serveur web, c est-à-dire 80 19

22 Schéma de corrélation Les profils sont modélisés sous la forme de règles logiques de la forme : f alsepositive(profilename,e) alert(e,a) c 1... c n où c i correspond à l une des primitives offertes par le modèle M4D4. Par exemple, la règle suivante permet de modéliser un des profils associés aux proxies web : f alsepositive(proxyweb1, E) alert(e, A) attacktarget(a,a T ) target(a T,ipaddress(T A )) nodeaddress(t,t A ) hosts(t,so ftware(,,webproxy, )) attackorigin(a,a O ) origin(a O,ipaddress(O A )) internal(o A ) attacktype(a, K) attacksubclass(k, web-attack) (on suppose que le prédicat internal est vrai si l adresse fournie en paramètre correspond à une adresse IP interne). Résultat de la corrélation L annonce du résultat de la corrélation se fera en subsumant l alerte courante avec une méta-alerte qui représente le phénomène à l origine des faux positifs (c est-à-dire le profil). Une seule méta-alerte subsumera l ensemble des alertes qui correspondent au profil au lieu de générer une méta-alerte par occurrence de faux positif. La méta-alerte sera donc créée lors de la première occurrence de faux positif ; les mises à jour ultérieures se feront simplement par ajout de la référence de l alerte courante à l ensemble des alertes subsumées par la méta-alerte. La méta-alerte sera construite de la manière suivante : Classification : Description du profil, c est-à-dire du phénomène à l origine du faux positif. Severity = 1. Completion = 0. Source : éventuellement, les sources distinctes apparaîssant dans les alertes subsumées. Target : éventuellement, les cibles distinctes apparaîssant dans les alertes subsumées. Éventuellement, le processus de corrélation mettant en œuvre ce schéma de corrélation pourra ne pas transmettre les alertes aux autres processus de corrélation. 3.3 Traitement d alertes redondantes Principe Deux alertes sont redondantes si elles sont émises par des sondes distinctes et qu elles concernent la même attaque. Le problème de redondance d alertes concerne en particulier les sondes de détection d intrusions réseau, car une même attaque peut être détectée sur plusieurs portions du chemin qui relie l attaquant à la victime. Le traitement de la redondance contribue non seulement à la réduction du volume d alerte par le regroupant des alertes associées à une même attaque, mais aussi à l amélioration du contenu sémantique des alertes. En effet, en connaissant les circonstances dans lesquelles des alertes redondantes sont attendues, il est possible d identifier des cas de faux et/ou de vrais négatifs. Par exemple, l absence d alerte provenant d une sonde fonctionnellement 2 et topologiquement 3 capable de détecter une attaque peut traduire un mauvais fonctionnement de la sonde (c est-à-dire un faux négatif), ou simplement la présence d un système de filtrage de trafic entre les sondes, qui bloque l activité malveillante (c est-à-dire un vrai négatif). La distinction de ces deux cas nécessite une connaissance de la topologie du réseau et de la configuration des sondes. L identification d alertes redondantes n est pas triviale car le contenu des alertes peut être différent suivant les sondes qui sont à l origine des alertes 2 la capacité fonctionnelle d une sonde dénote son aptitude à détecter une attaque par sa configuration (par exemple une signature permettant de détecter une attaque est activée 3 la capacité topologique d une sonde dénote son aptitude à détecter une attaque par son positionnement dans le réseau 20

23 L identification de l attaque peut être différente. Par exemple, la description de l attaque par un HIDS ne sera vraisemblablement pas la même que celle fournie par un NIDS. Plus généralement, des méthodes de détection différentes (comportementale ou par scénario) ne peuvent pas donner les mêmes descriptions. L identification des protagonistes peut être différente. Par exemple, deux sondes réseau peuvent identifier une même victime par deux adresses IP différente, s il existe un mécanisme de translation d adresse entre ces deux sondes. Les dates de l attaque et de l alerte sont différentes. L information temporelle est malgré tout importante pour identifier des phénomènes de redondance, car l écart entre les dates contenues dans les alertes est théoriquement faible. Schéma de corrélation Dans la perspective d un traitement en ligne des alertes, le système de traitement de la redondance que nous proposons suppose que chaque alerte peut potentiellement être liée à une ou plusieurs autres par une relation de redondance. A leur réception, les alertes sont comparées à une liste de groupes d alertes. Les alertes d un groupe sont des alertes potentiellement redondantes. Une même alerte peut être associée à plusieurs groupes. Si aucun groupe ne convient, l alerte forme un nouveau groupe. Un timer de courte durée est associé à chaque groupe d alertes. L ajout d une alerte dans un groupe provoque la réinitialisation du timer associé. Ceci permet de gérer les cas de redondance d alertes en cascade. Nous détaillons les conditions que doit remplir une alerte pour être candidate dans un groupe existant plus loin. A l expiration du timer, les alertes associées au groupe font l objet de vérifications supplémentaires, afin de valider l hypothèse de redondance (capacité des sondes à détecter l attaque, présence de translation d adresse dans le réseau, etc.). Ces vérifications font appel au contexte local. L échec de la validation peut le cas échéant engendrer une annulation de la corrélation entre les alertes du groupe, ce qui signifie que, en dépit des similitudes observées, les alertes sont probablement indépendantes. Si au contraire aucune alerte correspondant aux critères n est reçue pendant l intervalle de temps, alors des vérifications similaires sont effectuées pour tenter de justifier l absence de redondance, c est-à-dire vérifier qu aucune sonde n est effectivement censée détecter l attaque. Si c est le cas (du fait de la présence de filtrage entre les sondes par exemple), alors la sévérité de l alerte peut éventuellement 4 être diminuée. Dans le cas contraire, il peut s agir d un cas de faux négatif, auquel cas cette information peut être ajoutée à l alerte. Ce traitement peut sembler très coûteux, surtout s il est effectué sur chaque alerte. Il faut noter que le résultat de ce raisonnement peut être mémorisé, associé à des motifs d alertes et appliqué automatiquement à des alertes similaires reçues ultérieurement. Dans ce schéma de corrélation, nous essayons de valider a posteriori des hypothèses de redondance sur des groupes d alertes en utilisant des informations contextuelles, c est-à-dire après que des ensembles d alertes potentiellement redondantes ont été identifiées. Nous aurions aussi pu effectuer ce raisonnement a priori, pour identifier les types d alertes candidates, en positionnant des filtres plus restrictifs (sur l identité de la sonde émettrice ou de la cible), ce qui limiterait le nombre de candidats potentiels. Ce procédé nécessite une connaissance fiable de la topologie et de la configuration des sondes. Nous préférons faire l hypothèse que ces informations peuvent ne pas être connues, sans quoi des cas évidents de redondance pourraient être manqués. Les conditions que doivent remplir les alertes d un groupe pour être candidates à une relation de redondance sont les suivantes : Les analyseurs à l origine des alertes doivent être tous différents. Cette condition est à la base du phénomène de redondance d alertes. Les alertes doivent être reçues dans une fenêtre temporelle étroite par le processus de corrélation. Le timer associé à chaque groupe d alertes joue ce rôle. Cette fenêtre temporelle doit prendre en compte les éventuels délais de production d alertes par les sondes et de transmission sur le réseau. Cet intervalle est fixé arbitrairement à deux secondes. Les sources des attaques apparaissant dans les alertes issues de sondes réseau uniquement doivent toutes être identiques. On suppose que les sources sont au moins identifiées par leur adresse IP et un numéro de port ; en revanche, la source d une attaque peut ne pas être renseignée dans une alerte issue d une sonde système. 4 ceci dépend du type de sonde à l origine de l alerte 21

24 En l absence de convention de nommage des attaques, nous ne pouvons pas non plus imposer de contraintes spécifiques sur l identification des attaques. De même, du fait des mécanismes de translation d adresse précédemment cités, nous ne pouvons pas non plus imposer de contrainte sur les destinations des attaques. Lorsque le timer associé à un groupe d alertes expire, afin de valider l hypothèse de redondance, les vérifications suivantes sont effectuées si le groupe est constitué d au moins deux alertes : Toutes les adresses IP destination différentes présentes dans des alertes issues de sondes réseau doivent être explicables par des règles de translation d adresses enregistrées au niveau du contexte local. L identité de la destination finale de l attaque présente dans l alerte provenant d une sonde système (si elle existe) doit correspondre à au moins une des adresses IP présentes dans les alertes issues de sondes réseau. Cette correspondance peut par exemple être établie par l intermédiaire d une résolution de nom. On suppose qu il existe au plus une sonde de détection système susceptible de générer des alertes. Éventuellement, s il existe une chaîne de règles de translation d adresse permettant d obtenir l identité de la destination finale à partir d une des adresses IP destination, on considérera que cette condition est remplie. Les vérifications supplémentaires suivantes sont effectuées pour détecter d éventuels cas de vrais ou faux négatifs, quelle que soit la taille du groupe d alertes : Identification des sondes topologiquement capables : la route supposée suivie par les paquets d une attaque jusqu à la destination finale est évaluée à partir du couple (adresse IP source, adresse IP destination) de l alerte initiale, puis l ensemble des sondes réseau en écoute sur un des segments de la route est identifié. L alerte initiale est celle pour laquelle l adresse IP destination est la plus éloignée de celle de la destination finale. Comme détaillé dans les livrables 2.1 et 2.2, étant données une adresse source A S et une adresse destination A D, la visibilité topologique d un NIDS A est donnée par le prédicat can detect : can detect(a,a S,A D ) nids(a) path(a S,A D,P) monitors(a,h Gi,H G j ) [H Gi,H G j ] P La visibilité topologique d un IPS est définie quant à elle de la manière suivante : can detect(a,a S,A D ) ips(a) path(a S,A D,P) monitors(a,h G ) H G P La visibilité topologique d un HIDS est directement donnée par le terme primitif monitors(a,h) qui associe un analyseur A à l hôte qu il surveille, H. Identification des sondes fonctionnellement capables : sur la base de l ensemble précédent, l ensemble des sondes censées détecter l attaque initiale 5 est extrait à partir de la configuration enregistrée de ces sondes. La capacité fonctionnelle des IDS orientés signature est modélisée par le prédicat f unc vis(a, K) ; celle des IDS comportementaux est modélisée par le terme primitif detects(a,k), où A et K sont respectivement l identité de la sonde et K la classe d attaque. Les sondes présentes dans le groupe d alertes qui ne sont pas présentes celui des sondes topologiquement et fonctionnellement capables de détecter l attaque initiale peuvent ne pas avoir détecté l attaque. Il convient donc de vérifier s il existe des mécanismes de filtrage sur la route empruntée par l attaque, ce qui expliquerait l absence d alerte. Si c est le cas, alors l absence d alerte de la part de ces sondes est normal (vrai négatif), à condition qu aucune sonde située en aval n ait détecté l attaque. Si aucun mécanisme de filtrage n est référencé, il peut s agir d un faux négatif, hypothèse qui peut être renforcée par l existence dans le groupe d alertes provenant de sondes situées en aval de celles qui auraient dû réagir. La présence d une alerte émanant d une sonde de détection système dans un groupe indique de facto que l attaque a atteint la destination finale. Ceci ne signifie pas que l attaque a fonctionné, mais constitue un élément important dans l évaluation du succès. En l absence d alerte système, les cas de vrais négatifs avérés peuvent permettre de diminuer la sévérité de l ensemble des alertes d un groupe. A l inverse, les cas de faux négatifs renforcent la sévérité des alertes. On notera que le traitement de la redondance tel que nous l envisageons ici pourrait être implémenté sous la forme d un scénario d un module d un composant de corrélation explicite. Pour des raisons d efficacité, nous préférons le mettre en œuvre sous la forme d un module spécifique. 5 l attaque initiale est celle identifiée dans l alerte initiale 22

25 Résultat de la corrélation Plusieurs situations sont à envisager pour l annonce du résultat de la corrélation : Si le groupe est constitué de plusieurs alertes pour lesquelles la redondance vérifiée, une méta-alerte est créée. Cette méta-alerte subsume les alertes du groupe. La source de l attaque est celle trouvée dans les alertes initiales (par construction, ces adresses sont les mêmes). La destination de l attaque est l identité de la machine disponible dans l alerte système, si celle-ci existe. Sinon, c est l adresse IP la plus proche de la destination finale qui est retenue. L identification de l attaque est celle de l alerte système si elle existe, une de celles des alertes réseau sinon. Le champ name de la CorrelationAlert correspondante est affecté à la valeur Redundant alerts. La date de la méta-alerte est celle de l alerte la plus ancienne du groupe. Si le groupe est constitué d une seule alerte, alors aucune méta-alerte n est créée. Quel que soit la taille du groupe, les attributs de la méta-alerte ou l alerte individuelle suivants sont modifiées de la façons suivante : La sévérité de l alerte est augmentée si une alerte système est présente dans le groupe ou si en cas de faux négatif avéré de la sonde la plus proche (topologiquement parlant) de la destination finale. La sévérité de l alerte est diminuée en cas de vrai négatif avéré. En cas de vrai ou faux négatif avéré, l information est ajoutée en tant que donnée additionnelle de l alerte (additional data de IDMEF). Compte tenu des modifications éventuellement apportées aux alertes, ce module de corrélation est synchrone et devrait être exécuté en priorité. 3.4 Corrélation avec le contexte global L utilisation du contexte global pour la corrélation d alertes sera essentiellement centré sur le traitement des malwares et des activités de scanning associées Traitements préventifs Les observations fournies par le contexte global ne concernent pas nécessairement des activités ciblées contre le réseau surveillé. Ces activités ne nécessitent donc pas de contre-mesure immédiate. En revanche, ces observations peuvent déclencher des mesures préventives visant à vérifier que le système d information est correctement protégé contre les malwares en cours de propagation. Évaluation de l immunité des hôtes Sur la réception d une alerte émanant du contexte global et relative à la propagation d un malware, la corrélation peut, de manière préventive, vérifier la vulnérabilité ou l immunité des hôtes du réseau surveillé, sur la base des configuration logicielles réputées pour être affectées par le malware. Les configurations logicielles affectées sont connues soit par le biais de ScriptGen, qui est capable de dire sur quelles types de plateformes le malware fonctionne, soit par le biais des empreintes de systèmes d exploitation des victimes impliquées dans la propagation du ver, obtenues passivement (utilisation de pof). Dans les deux cas, la comparaison des configurations affectées avec les configurations effectivement présentes sur les machines du réseau surveillé se font comme décrit en section La notification du résultat de ce type de corrélation ne se fera qu en cas de correspondance exacte entre les configurations affectées et les configurations effectives. En effet, les alertes relatives à la propagation de malwares sont des observations sur des tendances observées à l extérieur du réseau et non des attaques observées contre des machines ; il est donc inutile de générer des alertes établissant l immunité de machines vis-à-vis d attaques qui ne les ciblent pas directement. En cas de correspondance, la notification du résultat de la corrélation pourra se faire sous la forme de rapports de vulnérabilité plutôt que sous la forme d alertes. 23

26 Reconfiguration d équipements Certains malwares rapatrient une charge virale à partir de sites centraux. La propagation d un malware de ce type peut déclencher la reconfiguration d équipements de filtrage pour empêcher les connexions vers les adresses des sites de téléchargement, par l intermédiaire du gestionnaire de corrélation. Dans le même ordre d idée, le gestionnaire de corrélation peut vérifier, et le cas échéant modifier, la configuration des équipements de filtrage du réseau pour empêcher la propagation du malware, à partir du numéro de port exploité par ce malware (fourni par la primitive exploit port(md5,p), où MD5 est le condensé de la charge virale du malware et P le numéro de port utilisé pour exploiter la vulnérabilité). Bien entendu, ce type de modification doit tenir compte des impératifs de service du site sous surveillance et empêcher des dénis de services auto-infligés par le blocage d un port critique pour le fonctionnement des applications (par exemple, blocage du port 445 sous Windows). Enfin, dans l hypothèse où des attaques ciblées 6 sont détectées par le contexte global, il est possible de reconfigurer les équipements de filtrage pour bloquer les blocs d adresses IP d où émane le trafic malveillant. Nous définissons deux primitives pour obtenir des informations sur l origine et la destination des attaques observées au niveau du contexte global : srcnetblocks(md5,block,g,t 1,T 2 ) et dstnetblocks(md5,block,granularity,t 1,T 2 ), où MD5 est le condensé de la charge virale du malware, BLOCK est un bloc d adresse IP, dont la granularité demandée est spécifiée par G, T 1 et T 2 représentent les limites inférieures et supérieures d une fenêtre d observation par le contexte global Corrélation avec des alertes émanant d autres équipements Corrélation multi-événementielle Le caractère polymorphique des malwares ne permet généralement pas d élaborer des signatures capables de détecter un malware donné ; en revanche, la propagation d un malware peut avoir des effets de bord sur le réseau, que des signatures génériques peuvent capturer. Ce n est plus la structure d une signature particulière qui permet de discriminer une activité normale de celle correspondant à la propagation du malware, mais l activation d une séquence de ces signatures, respectant des contraintes temporelles. En confrontant l activité d un malware à des sondes Snort, un pot de miel peut donc associer une séquence d alertes à un malware donné. Ainsi, les pots de miel peuvent fournir au gestionnaire de corrélation une méta-signature, sous la forme de séquences de signatures activées par un IDS (en l occurrence Snort), cette méta-signature étant utilisée pour configurer les processus de corrélation d alerte multiévénementiels. Ces méta-signatures devront être constituées au minimum de deux signatures, sans quoi la généricité des signatures risquerait d accroître le volume d alertes non pertinentes. La reconnaissance d une séquence d alerte par le système de corrélation multi-événementiel sera donc caractéristique d un malware connu. Nous ne détaillons pas plus ce procédé de corrélation, qui rentre plutôt dans le cadre de la corrélation multi-événementielle décrite dans le chapitre suivant. La notification du résultat de ce type de corrélation se ferait par la création d une méta-alerte encapsulant les alertes élémentaires fournies par Snort, dont le champ Classification correspondrait à un des noms donné au malware par les antivirus, avec une sévérité élevée, puisque l occurrence de ce type d alerte par des sondes surveillant le réseau interne dénote l infection d une des machines du réseau par le malware. Corrélation avec anti-virus Le nommage des malwares détectés par le contexte global repose en partie sur le service VirusTotal 7, qui soumet une trace d une activité malveillante à une base d antivirus du marché pour déterminer s il s agit d une activité malveillante connue et, dans l affirmative, sous quel(s) nom(s) le malware est connu. En cas de propagation d un malware connu sous les noms K 1,...,K n, une mesure préventive prise par le gestionnaire de corrélation peut être de vérifier la capacité fonctionnelle des antivirus installés sur les postes du système d information surveillé à détecter le malware, c est-à-dire : A, S,antivirus(A),detects(S,K i ) active(s,a) 6 On qualifie de ciblée une attaque qui vise exclusivement le site surveillé et non l ensemble des honeypots

27 En cas d incapacité des antivirus à détecter le malware (i.e., la réponse à la requête précédente est négative), le gestionnaire de corrélation peut ordonner une mise à jour des bases de signatures des antivirus des machines. En cas de succès, le nom fourni par un antivirus au malware peut être associé à celui affecté par le module de corrélation multi-événementiel précédemment évoqué, pour agréger les alertes redondantes selon le procédé présenté en section 3.3. Cette association permet de renforcer le lien entre alertes redondantes fournies par les antivirus, d une part, et les alertes fournies par le module de corrélation multi-événementiel, d autre part. Dans le cas des malwares qui téléchargent une charge virale depuis l extérieur du réseau surveillé, une technique pour évaluer le succès ou l échec d une attaque virale par un anti-virus peut consister dans une tentative de téléchargement de cette charge virale (selon le procédé utilisé par le malware répertorié dans la base de contexte global) par le gestionnaire de corrélation. Un échec dans le rapatriement de la charge virale indiquerait un échec de l attaque Analyses complémentaires Nous regroupons dans cette partie les utilisations complémentaires des connaissances fournies par le contexte global pour la corrélation. Contribution à une propagation : Cette vérification consiste pour le gestionnaire de corrélation à vérifier périodiquement l absence de participation du site administré à une quelconque activité de propagation de malwares à l encontre d un partenaire du projet Leurre.com. La présence du bloc d adresse associé au site administré dans la liste des attaquants connus d un partenaire indique la présence d une machine infectée dans le réseau, qu il est nécessaire de faire remonter sous la forme d une alerte. Attaques ciblées : Les propagations de malwares à l extérieur du suite administré sont généralement des phénomènes globaux, c est-à-dire ne ciblant pas un site en particulier. Néanmoins, le gestionnaire de corrélation peut vérifier que le site administré n est pas la cible privilégiée d un ou plusieurs malwares. Cette vérification peut être déclenchée par la réception d une alerte émanant du contexte global, relative à la propagation d un malware, ou bien de manière périodique, par interrogation de contexte global sur l existence d attaques visant exclusivement le site administré. Dans l affirmative, une alerte peut être créée par le gestionnaire de corrélation pour notifier l opérateur d une attaque ciblée à l encontre du site administré. Suivi d attaquant : À partir de l adresse d un attaquant trouvée dans une alerte issue d une sonde, il peut être intéressant d enrichir l alerte avec des informations relatives à l activité de l attaquant observée par d autres sites. Cette requête prend en paramètre l adresse IP de l attaquant et retourne la liste des noms d attaques dans lesquelles cette cible a été impliquée. Explication de tendances : Á partir d observations provenant d équipements de type IDS, pare-feux, ou sondes de collecte passive d informations cartographiques, relatives à une activité anormales sur un port donné, le gestionnaire de corrélation peut tenter d apporter une explication en interrogeant le contexte global sur l existence de propagations de malwares associés à ce port (qu il s agisse du port exploité par le malware pour exploiter la vulnérabilité ou bien celui utilisé pour communiquer avec l extérieur). Dans le cas où ces activités anormales proviennent de l extérieur du réseau surveillé, le gestionnaire de corrélation pourra préciser s il s agit d un phénomène global connu ou non. Si l attaque correspond à un malware inconnu des antivirus (i.e., aucun nom n est associé à la charge virale capturée par le contexte global et soumise à VirusTotal), alors une alerte de haute sévérité peut être envoyée, en complément des vérifications présentées précédemment. En effet, l absence de nom peut être révélateur de la nouveauté du malware, et par conséquent d un risque accru de vulnérabilité des victimes. 25

28 Chapitre 4 Corrélation multi-événementielle 4.1 Introduction au langage ADeLe Le but du langage ADeLe [5] est de décrire tous les aspects fonctionnels relatifs à une attaque, que ce soit du point de vue de l attaquant ou de l administrateur du système. Ces différents aspects, décrits grâce à un langage unique, permettent de construire une base de données d attaques contenant toutes les informations nécessaires à la compréhension de la mise en oeuvre, de la détection et de la réaction à une attaque. En fait, la description d une attaque contient : la description de l exploitation d une ou plusieurs vulnérabilités afin de compromettre la politique de sécurité du système (c est-à-dire le scénario d attaque) ; la description de l attaque du point de vue de la cible, qui permet de détecter la signature de l attaque quand celle-ci a lieu. la description d une réponse appropriée à donner à une attaque détectée. Dans les sections qui suivent, nous nous intéresserons aux aspects détection d intrusion, et tout particulièrement à la signature d une attaque multi-événements, qui utilise des mécanismes de corrélation, soit entre événements, soit entre l environnement et des événements. Il faut noter ici que l on nomme événement toute entrée du mécanisme de corrélation, et alerte tout sortie indiquant la détection positive d une signature. Une signature est composée de trois parties distinctes : la partie EVENT qui définit des filtres d événements (section 4.2) ; la partie ENCHAIN qui définit une relation d ordre temporel entre événements à corréler (section 4.3, et la partie CONTEXT qui décrit les corrélations contextuelles (section 4.4). 4.2 Notion de filtre d événements La détection est fondée sur la reconnaissance d événements. Afin de déterminer quels événements sont susceptibles de contribuer à une signature, on définit des filtres d événements. Ces filtres décrivent quel événements doivent être utilisés comme éléments de base du processus de corrélation. Comme indiqué sur la figure 4.1, un filtre d événements est défini en utilisant son nom source (ici outil PRELUDE 1 ), et un nom (ici CP or OPEN nomment les types de filtre). Le filtre d événement défini les attributs significatifs de l événement source, et les valeurs qu ils doivent prendre. L outil de détection GnG utilise ces informations pour filtrer les données d audit et élire les données qui correspondent à cette définition. De plus, on peut nommer une instance spécifique d un type d événement, sous forme d une variable qui pourra être utilisée dans le processus de corrélation. Dans l exemple fourni, CP0 or OPEN0 sont les noms de telles variables. 1 Prelude est un IDS ouvert pour Unix, permettant de fédérer des sondes autour de managers pour alimenter une base de données d alertes http :// 26

29 <EVENTS> CP : PRELUDE { event.name == "execve()"; path == "/bin/cp"; arguments MATCHES "cp /bin/sh *"; } CP0; OPEN: PRELUDE { event.name == "open(o_wronly O_CREAT)"; process.name == "cp"; attributes == "rwxr-xr-x"; } OPEN0;... </EVENTS> 4.3 Opérateurs de corrélation FIG. 4.1 Event filter examples Une fois qu un événement a passé l étape du filtre en entrée, il faut déterminer s il peut contribuer à la détection d une attaque, en mettant en place un processus de corrélation avec d autres événements. Les liens entre les événements sont définis par l utilisation de cinq opérateurs : Sequence, OneAmong, NonOrdered, Without and Repeat. Ces opérateurs sont utilisés pour définir la signature d une attaque. Dans la suite de cette section, nous définissons formellement chacun de ces opérateurs Opérateur Sequence L opérateur Sequence permet la description d une séquence d événements. Comme montré par l exemple 1, l expression de séquence définit à la fois une contrainte temporelle sur l ordre des événements, et les éléments qui sont nécessaires à la reconnaissance de la signature d attaque. Dans cet exemple, nous devons détecter séquentiellement trois événements A, B et C dans cet ordre. Le formalisme utilisé pour exprimer la sémantique de l opérateur est celui des chroniques [2, 3]. Exemple 1 Syntaxe: <ENCHAIN> Sequence(A, B, C) </ENCHAIN> Sémantique : event(a) event(b) event(c) t(a) < t(b) t(b) < t(c) Opérateur NonOrdered L opérateur NonOrdered permet la description d une signature dans laquelle tous les éléments doivent être reconnus sans contrainte d ordonnancement. L exemple associé montre que trois événements A, B et C doivent être reconnus, dans n importe quel ordre temporel. Exemple 2 Syntaxe: <ENCHAIN> NonOrdered(A, B, C) </ENCHAIN> Sémantique : event(a) event(b) event(c) 27

30 4.3.3 Opérateur OneAmong L opérateur OneAmong permet la description d une reconnaissance d une expression parmi plusieurs. Il définit en fait une disjonction entre les éléments durant une détection donnée. Pour une attaque particulière, seule la détection d un des éléments proposés est suffisante pour assurer la détection de la signature. Dans l exemple donné, nous montrons que A, B ou C doit être détecté pour assurer la détection de la signature. Exemple 3 Syntaxe: <ENCHAIN> OneAmong(A, B, C) </ENCHAIN> Sémantique : event(a) event(b) event(c) Opérateur Without L opérateur Without permet de décrire comment la détection d une signature positive peut être annulée par la détection d une signature négative. La signature positive correspond à ce qui doit être détecté pour qu une alerte soit levée, alors que la détection de la partie négative permet de stopper la reconnaissance. Ceci est illustré par un exemple où la séquence A suivi de B doit soulever une alerte seulement si C n est pas détecté. En d autre termes, l opérateur permet d annuler une détection partielle d une signature sur l occurrence d une signature particulière. Exemple 4 Syntaxe: <ENCHAIN> Without(Sequence(A, B), C) </ENCHAIN> Sémantique : event(a) event(b) noevent(c) t(a) < t(b) Opérateur Repeat L opérateur Repeat permet la description d une répétition d un événement ou d une expression. Dans l exemple donné, une alerte est levée sur la répétition d au moins 10 événements A consécutifs. Exemple 5 Syntaxe: <ENCHAIN> Repeat(A, 10) </ENCHAIN> Sémantique : event(a i ) t(a i ) < t(a i+1 ) i [1,10] i [1,9] 4.4 Corrélation contextuelle Les opérateurs précédemment décrits permettent d écrire une signature où on définit l ordonnancement des événements. Cette information, bien qu importante, est insuffisante pour décrire des relations contextuelles entre les événements ou entre les événements ou le système. D autre part, les informations de corrélation à ajouter peuvent être soit d ordre temporel (relation temporelle entre les événements), soit en valeur (relations entre les valeurs des événements). Les parties qui suivent décrivent quels types de corrélation nous mettons en place dans le cadre de GnG. 28

31 Contraintes temporelles Les contraintes temporelles que l on se propose d exprimer dans GnG nécessitent la définition de trois opérateurs : TimeOut, MinDelay, MaxDelay. Le premier opérateur concerne la durée de validité de la reconnaissance d une signature, tandis que les deux suivants concernent les relations entre les moments d occurrence d événements. L opérateur TimeOut définit combien de temps une reconnaissance reste en suspend avant qu on ne l annule. L opérateur MinDelay définit une durée minimale imposée entre deux événements, alors que l opérateur MaxDelay définit une durée maximale imposée entre deux événements. Dans le cas de tous ces opérateurs, les événements ne sont acceptés que si les contraintes temporelles sont vérifiées. L utilisation de ces opérateurs sont exprimés dans l exemple associé. Exemple 6 <CONTEXT> TimeOut(100); MaxDelay(A, B, 20); MinDelay(A, B, 10); </CONTEXT> Sémantique : (t(a) t(b) < 20s (t(a) t(b) > 10s scenariodetection < 100s Contraintes inter-événements Le langage permet, outre les contraintes temporelles, d établir des relations imposées entre les valeurs des attributs des événements acceptés. Ces contraintes nécessitent que l on lie entre eux des attributs de différents événements. L exemple associé met en lumière ce type de relation, en imposant que les champs user.id des événements A, B et C soient identiques : Exemple 7 <CONTEXT> A.user.uid == B.user.uid; B.user.uid == C.user.uid; </CONTEXT> Contraintes sur des valeurs externes Les contraintes que nous avons spécifiées dans les précédents paragraphes concernent les événements, et leurs liens respectifs. On peut toutefois décider de lier l acceptation d un événement non pas à un autre événement mais à son environnement système. Ceci nécessite, bien évidemment, de disposer d une entité capable de nous fournir toute information disponible sur le contexte environnemental de l événement. A cette fin, GnG est capable de s interfacer avec la base de données M4D4. Cette interface comprend deux types d interrogations de l environnement, qui sont explicités dans l exemple cijoint : Vérifier si une assertion est vraie, par exemple lier l acceptation d un événement à une condition sur l environnement ; Demander des valeurs de données de l environnement pour les confronter à des valeurs d attributs des événements. Exemple 8 <CONTEXT> A.user.uid in env("f("+b.user.id+")"); cond("g("+a.user.gid+")"); </CONTEXT> 29

32 4.5 Algorithme de corrélation Présentation de GNG GNG Gassata New Generation est un corrélateur d alertes paramétré par des signatures exprimées en langage ADeLe, traduites en autant d automates de reconnaissance. Initialement développé dans le cadre du projet RNTL DICO ( ), GNG était une application autonome, des modules d entrée lui permettant d accepter des événements selon différents formats : snare, filemon, regmon, IDMEF... Les alertes de corrélation étaient générées dans un fichier au format IDMEF. GNG a été profondément remanié dans le cadre d ACES : le langage de description d attaques ADeLe et le corrélateur GNG ont été modifiés pour prendre en compte des contraintes sur le contexte topologique et cartographique décrit par une base M4D4, il a été intégré au gestionnaire de corrélation développé dans le cadre du projet. Nous étudierons les aspects suivants : l architecture de GNG, les notions d automate de reconnaissance et de plan, la traduction des contraintes temporelles ADeLe (Sequence, OneAmong...) en automates et la gestion des plans Architecture GNG est abonné aux alertes diffusées par un gestionnaire de corrélation ; quand GNG émet une alerte de corrélation, il se comporte comme une sonde (c.f. Figure 4.2). Les principales fonctionnalités de GNG sont les suivantes : le compilateur de signatures analyse les signatures ADeLe pour paramétrer le filtrage d alertes entrantes et construire un automate de reconnaissance, le Filtrage, en attente bloquante sur les alertes diffusées par un Manager, ne laisse passer que les événements prévus dans les signatures, le Moteur de corrélation, à la réception d alertes filtrées et sous réserve que les contraintes de contexte soient vérifiées, fait évoluer si possible l état des automates de reconnaissance ; une alerte est émise si un automate atteint un état d acceptation. Gestionnaire de corrélation alertes Filtrage d'alertes Moteur de corrélation alertes Compilateur de signatures Signatures ADeLe Module de corrélation GnG FIG. 4.2 Architecture de GNG 30

33 4.5.3 Notions d automate et de plan La partie DETECT d une signature ADeLe fournit trois catégories d informations : des filtres sur les alertes entrantes (types et instances d événements dans la section EVENTS), des contraintes temporelles sur la succession d alertes filtrées conduisant à la génération d une alerte de corrélation (section ENCHAIN), des contraintes de contexte portant soit sur les champs des alertes entrantes, soit sur le contexte topologique ou cartographique (section CONTEXT). De chaque signature, GNG va déduire un automate à états finis dont les transitions sont libellées par un filtre d alertes. Principe général de la corrélation : l état de départ de chaque automate est activé, si une alerte entrante est reconnue par le filtre associé à une transition issue d un état actif et sous réserve que les contraintes de contexte soient vérifiées, l état en sortie de transition est activé, pour permettre que la signature Sequence(A, B,C) avec la contrainte B.x = C.y soit reconnue deux fois dans le flux A,B{x = 1},B{x = 2},C{y = 2},C{y = 1}, l état initial de la transition tirée reste actif (non déterminisme), les informations associées à une exécution de l automate état courant, historique des événements consommés constituent un plan ; notation : p i = (q i,[e i,...,e j ]) (cette représentation sera étendue pour le NonOrdered, le Repeat, le Without et la corrélation) ; l initialisation crée un plan p 1 = (1,[]), c est-à-dire lié à l état de départ et dont l historique est vide, lors de l exécution d un NonOrdered, équivalent d un fork, l état courant est multiple (un sous état par branche du NonOrdered), les sous-états étant fusionné en sortie du NonOrdered, il y a détection d une attaque quand un plan atteint un état d acceptation Traitement des opérateurs de contrainte temporelle Pour chacun de ces opérateurs, la suite décrit l automate généré et la gestion des plans. Notations : - n-uplet (e, f,g) - ensemble {e, f, g} - liste [e, f,g] La séquence Soit l extrait de spécification ADeLe : <EVENTS> # types d événements (filtres) E:PRELUDE {...}; F:PRELUDE {...}; G:PRELUDE {...}; </EVENTS> <ENCHAIN> # contrainte temporelle Sequence(E, F, G); </ENCHAIN> L automate équivalent est : Exemple d exécution avec Sequence(E,F,G) et le log [e, f,e 2, f 2,g] : 31

34 E F G S A 4 Evénement états concernés Plan(s) Plan(s) créé(s) concernés père p 1 = (1,[]) e 1 2 p 1 p 2 = (2,[e]) f 2 3 p 2 p 3 = (3,[e, f ]) e p 1 p 4 = (2,[e 2 ]) f p 2 p 5 = (3,[e, f 2 ]) p 4 p 6 = (3,[e 2, f 2 ]) g 3 4 p 3 p 7 = (4,[e, f,g]) //alerte! p 5 p 8 = (4,[e, f 2,g]) //alerte! p 6 p 9 = (4,[e 2, f 2,g]) //alerte! Quand un plan atteint l état d acceptation, il est détruit (rayé) et il y a production d une alerte (ici trois). On notera que les plans 1 à 6 sont toujours en attente de nouvelles transitions. Le OneAmong Exemple d extrait de spécification ADeLe : <EVENTS> # types d événements (filtres) E:PRELUDE {...}; F:PRELUDE {...}; G:PRELUDE {...}; </EVENTS> <ENCHAIN> # contrainte temporelle Sequence(OneAmong(Sequence(E, F), F), G); </ENCHAIN> L automate équivalent est : S 1 E 2 F F G 3 A 4 La traduction du OneAmong apparaît simplement comme deux transitions issues du même état, intuitivement : 2 chemins vers l acceptation. Avec le log [ f,e, f 2,g], on obtient la trace d exécution suivante : 32

35 Evénement états concernés Plan(s) père Plan(s) créés p 1 = (1,[]) f 1 3, 2 3 p 1 p 2 = (3,[ f ]) e 1 2 p 1 p 3 = (2,[e]) f 2 1 3, 2 3 p 1 p 4 = (3,[ f 2 ]) p 3 p 5 = (3,[e, f 2 ]) g 3 4 p 2 p 6 = (4,[ f,g]) p 4 p 7 = (4,[ f 2,g]) p 8 = (4,[e, f 2,g]) p 5 Soit trois alertes, décrites par les historiques de p 6, p 7 et p 8, et cinq plans encore vivants. On notera qu il est normal de faire consommer f 2 par deux transitions différentes : il s agit de faire progresser des plans indépendants. Le NonOrdered Exemple d extrait de spécification ADeLe : <EVENTS> # types d événements (filtres) E:PRELUDE {...}; F:PRELUDE {...}; G:PRELUDE {...}; </EVENTS> <ENCHAIN> # contrainte temporelle Sequence(E, NonOrdered(F,G)) </ENCHAIN> L automate équivalent est : E! S G F 5! [sync] 6 sync Où le NonOrdered se traduit par : une ε-transition de création d un plan multiétat, sous la forme d une fourche entre l état 2 et les états 3 et 4 (transition fork ), des branches parallèles représentant les opérandes du NonOrdered (ici au nombre de deux et réduits à de simples filtres), une ε-transition de retour à un état simple, grâce à la garde et à l action sync. Principe de gestion du marquage de l automate : lors du franchissement de l ε-transition fork, l état courant du plan devient un n-uplet contenant un numéro d état par branche du NonOrdered, le plan ne peut franchir la transition sync (entre les états 5 et 6 dans l exemple) que quand tous les états du n-uplet d état sont égaux à l état source (5 dans l exemple), le plan franchit alors l ε-transition sync et son état courant redevient un état simple (6 dans l exemple). 33

36 Avec le log [e, f,g,e 2, f 2 ], on obtient la trace d exécution suivante : Evénement états Plan(s) Plan(s) créés concernés père p 1 = (1,[]) e 1 2 p 1 p 2 = ((3,4),[e]) // après fork f 3 5 p 2 p 3 = ((5,4),[e, f ]) g 4 5 p 2 p 4 = ((3,5),[e,g]) p 3 p 5 = ((5,5),[e, f,g]) // regroupement! p 5 = (6,[e, f,g]) // alerte e p 1 p 6 = ((3,4),[e 2 ]) // après fork f p 2 p 7 = ((5,4),[e, f 2 ]) p 4 p 8 = ((5,5),[e,g, f 2 ]) // regroupement! p 8 = (6,[e,g, f 2 ]) // alerte! p 6 p 9 = ((5,4),[e 2, f 2 ]) Soit deux alertes ([e, f,g] et [e,g, f 2 ]) et sept plans encore vivants Le Repeat Opérateur ADeLe : Repeat(<signature>, <compte entier>) ([],[e],[e, f ],[e,g],[e 2 ],[e, f 2 ],[e 2, f 2 ]). Remarque importante : de même que Sequence(E,F) réussit aussi bien avec [e, f ] qu avec [e,e 2, f ] ou [e,e 2,e 3, f ], puisque Sequence(E,F) est équivalent à la formule de logique temporelle E F (si est stricte), et non pas E F, on notera que Sequence(Repeat(E,20),F) ne représente pas 20 E suivis d un F, mais au moins 20 E suivis d un F. La gestion du compteur et la sortie de boucle sont assurés par des gardes et actions de l automate équivalent : 3 signature 4!! [c 2 < max] c ++! 2! c 2 := 0 [c 2 == max] Le compteur est propre à chaque plan : il est porté par lui. Plutôt que de gérer une pile de compteurs actifs, on alloue autant de compteurs qu il y a de boucles dans l automate considéré, c i étant le compteur lié à l état i. Exemple et automate correspondant : Sequence(E, Repeat(Sequence(F,G),2)) Analyse du log [e, f,g, f 2,g 2 ] : 34

37 F G [c 3 < 2]! c ++ 3 E!! c 3 := 0 [c 3 == 2]! Evénement états concernés Plan(s) père Plan(s) créés p 1 = (1,[],c 2 = 0) e 1 2 p 1 p 2 = (4,[e],c 2 = 0) f 4 5 p 2 p 3 = (5,[e, f ],c 2 = 0) g 5 6 p 3 p 4 = (4,[e, f,g],c 2 = 1) f p 2 p 5 = (5,[e, f 2 ],c 2 = 0) p 4 p 6 = (5,[e, f,g, f 2 ],c 2 = 1) g p 3 p 7 = (4,[e, f,g 2 ],c 2 = 1) p 5 p 8 = (4,[e, f 2,g 2 ],c 2 = 1) p 6 p 9 = (7,[e, f,g, f 2,g 2 ],c 2 = 2) // fini! Le Without Opérateur ADeLe : Without(signature 1, signature 2 ) signifiant que signature 1 ne peut être reconnue que si signature 2 n est pas détectée dans le même temps. Par exemple, avec la signature : Without(Sequence(A,B),Sequence(C,D)) le log [a, c, d, b] n entraîne pas de détection puisque la signature inhibitrice (ou négative) a été reconnue après le début et avant la fin de la signature principale (ou positive). Par contre il y a détection avec les logs [c,a,d,b] ou [a,c,b,d]. NB : signature 1 ne peut pas correspondre à un seul événement - l inhibition n aurait pas de sens. Principe de l automate équivalent à un Without Une action lors de la première transition de la branche positive permet de créer un plan sur la branche négative. Exemple : Without(Sequence(A, B, C), Sequence(D,E)) a pour automate équivalent : A B C S Success 4 D D E 5 Fail 6 Les choses se compliquent si la branche positive commence par un OneAmong : le démarrage de l automate inhibiteur est validé par la première transition de chaque branche de OneAmong. Exemple : Without(OneAmong(Sequence(A,B), Sequence(C,D)), E) avec pour automate équivalent : Enfin, quand la branche positive commence par un NonOrdered, il n y a pas de bretelle sur les états atteints par ε-transition au début de ce NonOrdered : il n y a pas encore d événement consommé par la branche positive, donc la branche négative ne doit pas démarrer. 35

38 A 2 B S 1 C E D Success 4 3 E Fail 5 Exemple : Without(NonOrdered(A,OneAmong(B,C)), D) où la branche inhibitrice D n est active qu après un événement de type A ou B ou C, ce qui est clair si l on considère l automate : 1! 2 4 B A C 3 D! [sync] sync Success 5 Fail 6 Principe de l analyse du log pour un Without A la naissance d un plan négatif un lien de filiation est créé avec son parent positif : il permettra la destruction des plans positifs en cas de réussite du plan négatif ; un plan positif ne donne naissance qu à un plan négatif (voir exemple avec un NonOrdered ci-dessous) ; Si un plan négatif est issu d un plan positif dans un NonOrdered (donc avec un n-uplet d état), on ne garde que l état dans la branche négative. Quand un plan négatif réussit (atteint l état fail), il est détruit ainsi que tous les plans positifs et négatifs liés ; exemple : avec Without(Sequence(A,B,C),Sequence(D,E)) et le log [a,b 1,b 2,d,e], il faut purger les trois plans contenant respectivement dans leur historique [a], [a,b 1 ] et [a,b 2 ] ; Il faut aussi purger les plans de l automate inhibiteur d historiques [a] et [a,d] : ils n ont plus de parent dans la branche positive. Quand un plan positif atteint l état Success du Without, il laisse derrière lui les plans dont il a été cloné : il ne faut donc pas purger la branche négative. Reprenons le premier exemple ci-dessus : Without(Sequence(A, B, C),Sequence(D,E)). A B C S Success 4 D D E 5 Fail 6 avec le log [d,a,b,d 2,c,e] : 36

39 Evénement états Plan(s) père Plan(s) créés concernés p 1 = (1,[]) d 2ou3 5 // trop tôt! a 1 2 p 1 p 2 = (2,[a]) // tué par p 7 b 2 3 p 2 p 3 = (3,[a,b]) // tué par p 8 d p 2 p 4 = (5,[a,d 2 ]) // p 3 p 5 = (5,[a,b,d 2 ]) //... c 3 4 p 3 p 6 = (4,[a,b,c]) // without réussi! e 5 6 p 4 p 7 = (6,[a,d 2,e]) // tue p 2, p p 5 p 8 = (6,[a,b,d 2,e]) // tue p 3, p 5 On notera qu il reste encore p 1, non encore entré dans le Without et p 6 déjà sorti. 4.6 Travaux connexes Les approches de corrélation peuvent être divisées en trois catégories : explicite, semi-explicite and les corrélation implicites. La corrélation explicite considère qu une intrusion dans un système peut être décrite sous la forme d une succession d événements (la signature de l attaque). De nombreux travaux utilisent ce processus de corrélation : par exemple, Cuppens et Ortalo ont publié un langage de description d attaque appelé Lambda [1]. Ce langage cherche à décrire tous les aspects d une attaque contre un système. D un autre côté, Logweaver est un outil paramétré par un langage qui peut analyser en ligne des flots d événements et corréler des informations [4]. Suthek est un langage logique qui est utilisé pour décrire des séquences d événements dans des traces d audit [7, 8]. Enfin, les chroniques ont été utilisées pour corréler des alertes [6]. Elle apportent un moyen de décrire des séquences d événements qui peuvent être détectées dans un système : ce papier montre comment une corrélation peut être envisagée en utilisant les chroniques comme moyen de corrélation. Le type de corrélation semi-explicite généralise le concept de corrélation explicite en introduisant la notion de pre-conditions et post-conditions pour des attaques. Lambda [1] propose une telle notion. La corrélation implicite, au contraire des approches explicites ou semi-explicites, tente de reconnaitre et construire des scenarios d attaque. Cette approche est illustrée, par exemple, dans [9]. 37

40 Bibliographie [1] Frédéric Cuppens and Rodolphe Ortalo. Lambda : A language to model a database for detection of attacks. In H. Debar, L. Mé, and S. F. Wu, editors, Proceedings of the Third International Workshop on the Recent Advances in Intrusion Detection (RAID 2000), number 1907 in LNCS, pages , October [2] C. Dousson. Suivi d evolutions et reconnaissance de chroniques. PhD thesis, [3] C. Dousson. Alarm driven supervision for telecommunication networks. In Annales des Telecommunications, pages , [4] Jean Goubault-Larrec. An introduction to logweaver. Technical report, LSV, [5] Cédric Michel and Ludovic Mé. Adele : an attack description language for knowledge-based intrusion detection. In Proceedings of the 16th International Conference on Information Security (IFIP/SEC 2001), pages , June [6] Benjamin Morin and Hervé Debar. Correlation of intrusion symptoms : An application of chronicles. In Giovanni Vigna, Erland Jonsson, and Christopher Krügel, editors, Proceedings of the 6th International Symposium on Recent Advances in Intrusion Detection (RAID 2003), volume 2820 of Lecture Notes in Computer Science, pages Springer, September [7] Jean-Philippe Pouzol and Mireille Ducassé. From declarative signatures to misuse ids. In W. Lee, L. Mé, and A. Wespi, editors, Proceedings of the Fourth International Workshop on the Recent Advances in Intrusion Detection (RAID 2001), LNCS, October [8] Jean-Philippe Pouzol and Mireille Ducassé. Formal specification of intrusion signatures and detection rules. In Proceedings of 15th Computer Security Foundations Workshop (CSFW 02), IEEE Computer Society Press, pages 64 76, [9] A. Valdes and K. Skinner. Probabilistic alert correlation. In W. Lee, L. Mé, and A. Wespi, editors, Proceedings of the 4th International Symposium on the Recent Advances in Intrusion Detection (RAID 2001), LNCS, October