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