Hervé Debar 23 mai 2002

Transcription

1 Projet RNTL DICO Sous Projet 5 Corrélation d alertes et cartographie de sites - Livrable 5.1 Etat de l art sur la cartographie de sites, les techniques de corrélation a-priori et les techniques de corrélation explicite. - Version: draft 0.1 Hervé Debar herve.debar@francetelecom.com 23 mai 2002 Résumé Ce document a pour objectifs de présenter différentes techniques de corrélation d alertes, de décrire comment et avec quels résultats possibles ces techniques peuvent être utilisées dans le cadre des systèmes de d etection d intrusions, de décrire les avantages et inconvénients de chacune de ces techniques et de proposer des exemples d implémentation pour la partie prototype du projet. Rédacteurs: Contributeur Organisme Role Visa Salem BENFERHAT SB IRIT Contributeur Frédéric CUPPENS FC ONERA Responsable du livrable Hervé DEBAR HD France Télécom R&D Responsable du SP5 Ludovic ME LM Supelec Rennes Contributeur Benjamin MORIN BM France Télécom R&D Contributeur Diffusion : les rédacteurs plus 1

2 Table des Matières Table des matières 1 Introduction (HD) Description d un système de détection d intrusions (HD) Définition du groupe IDWG Relations entre composants Objectifs de la correlation d alertes Réduction du volume d information Augmentation de la qualité du diagnostic Prise en compte de l évolution du diagnostic Prise en compte des contre-mesures et de leurs effets Cartographie de sites (BM) Intérêt de la cartographie pour la corrélation Topologie Types de topologies Modèle de réseau Conclusion Eléments logiques Modèles unificateurs Conclusion Corrélation á partir des marqueurs (FC) 13 4 Corrélation á partir des marqueurs et des scénarios (LM) Introduction Utilisation d algorithmes génétiques (G a ssata) Présentation rapide des algorithmes génétiques Principe de fonctionnement Architecture de l IDS G a ssata Alternative à l algorithme génétique (G n G) Génération d hypothèses (SB) 21 6 Conclusion 21 7 Glossaire et Index 21 8 Bibliographie 21 A Topologie physique 21 B Protocole SNMP 23 C Modèle formel de réseau 23 2

3 1 Introduction (HD) L objectif de ce document est de passer en revue les différentes techniques de corrélation d alertes qui peuvent être appliquées dans le cadre de la corrélation d alertes fournies par les systèmes de détection d intrusions. 1.1 Description d un système de détection d intrusions (HD) Cette section décrit brièvement les systèmes de détéction d intrusions, en se focalisant sur les travaux du groupe Intrusion Detection exchange format Working Group (IDWG) au sein de l Internet Engineering Task Force (IETF) Définition du groupe IDWG L objectif des travaux du groupe IDWG est la définition d un standard de communication entre certains composants d un systeme de detection d intrusions. Ce standard inclus la définition d un format de message et d un protocole de communication sécurisé pour le transport de ces messages. Plus précisément, le flux de communications á standardiser est le flux Alert de la figure 1, extraite du document de définitions [12] du groupe IDWG. Environnement Sonde DATA SOURCE Activity SENSOR Event SENSOR Event ANALYZER Alert ADMINISTRATOR Security Policy RESPONSE Security Policy MANAGER Notification OPERATOR Environnement de Management Fig. 1 Architecture standard d un système de détection d intrusions Les autres flux d information sont considérés comme des flux internes, ne nécessitant pas d interface publique, alors que le flux d alertes représente un diagnostic sur la sécurité du système surveillé. Ceci est

4 matérialisé dans la figure par les deux losanges regroupant les composants principaux d un système de détection d intrusions Relations entre composants Les composants intéressants pour la corrélation sont: Analyzer (analyseur) L analyseur est la partie importante de la sonde, qui réalise le traitement sur les données pour fournir le diagnostic. L analyseur fournit des alertes représentatives d un problème trouvé dans le flux d informations, qui a un impact sur la sécurité. Ce flux d information peut bien entendu être constitué d alertes fournies par d autres briques d un système de détection d intrusions complet. Manager (gestionnaire) Le gestionnaire est le composant recevant les alertes. Dans la mesure ou cette architecture se généralise, un composant peut avoir un rôle de manager vis-à-vis d outils situés hiérarchiquement en dessous de lui, et d analyseur vis-à-vis d outils situés hiérarchiquement au dessus de lui. Un tel manager implémente des fonctions de traitement des alertes dont une partie est de la corrélation intéressant le projet DICO. Data source (source d informations) La source d information est un flux de données acquis par le système de détection d intrusion et analysé pour déterminer si des événements anormaux par rapport à l algorithme d analyse se produisent dans ces données. Cette source d information se décompose en une suite au moins partiellement ordonnée d événements. Des exemples de source de donnée peuvent être le traffic réseau, les sessions TCP ou les transactions avec un serveur HTTP. Event (événement) Un événement est un morceau de la source de données dont les propriétés sont telles qu il peut être traité indépendemment des autres. La définition de l événement dépend évidemment de la source de données. Pour le traffic réseau, l événement peut être un paquet IP, un paquet IP défragmenté, ou une paquet de niveau supérieur. Cette définition de l événement est importante pour les outils de détection d intrusions puisqu elle conditionne d une part la répartition du travail entre la sonde et l analyseur, et d autre part la qualité du diagnostic fourni par l ensemble sonde et analyseur. Alert (alerte) Une alerte est un résumé du processus d analyse indiquant qu un des événements possède des propriétés jugées indésirables par l algorithme d analyse. Cette alerte doit offrir le plus possible d informations sur le problème, son étendue d abord, comment réagir sur le champ ensuite et finalement comment prévenir sa réapparition. Plus d information à ce sujet est présentée en section 1.2. La première étape d un processus d analyse de données consiste à extraire un ensemble de facteurs de l événement reçu. Ces facteurs peuvent ne pas être déterminants pour la décision de génération d une alerte, mais ils constituent au moins des bribes d information permettant à un analyste de travailler sur l alerte. Une alerte est donc la somme d un ensemble de facteurs. La corrélation d alertes intervient ensuite. Quatre fonctions de corrélation peuvent être définies, qui déterminent à quel niveau dans l architecture la corrélation intervient, et lequel des deux rôles de gestionnaire et d analyseur implémentent ces fonctions: single source, single event Les systèmes de détection d intrusion actuels ont tendance à confondre alerte et facteur, et a générer une alerte pour chaque facteur trouvé dans un événement. Une première fonction de corrélation est de regrouper ces différentes alertes pour prévenir l explosion du nombre d alertes, en s assurant qu il y a pour chaque événement au plus une alerte. Cette fonction de corrélation intervient naturellement au niveau de l analyseur. single source, multiple events Le deuxième niveau de corrélation est le regroupement d alertes liées à plusieurs événements de la même source de données. Ceci peut être comparé de façon macroscopique à la progression d un attaquant contre une seule cible. Là encore, l analyseur est la localisation privilégiée de cette fonction de corrélation. multiple sources, single event Le troisième niveau de corrélation regroupe des alertes provenant de plusieurs analyseurs, fournies à partir de sources de données différentes. Ceci peut être comparé de manière macroscopique à l écoute du dialogue entre cible et attaquant en plusieurs points. Dans cette optique, le gestionnaire est la localisation privilégiée de cette fonction de corrélation. 4

5 multiple sources, multiple events C est le dernier niveau de corrélation. Là encore, le gestionnaire est la localisation privilégiée de cette fonction de corrélation. Lorsque l on parle de corrélation, il est donc important de préciser la cible visée pour positionner l outil à l endroit le plus approprié. L ordre de la liste précédente n est pas innocent; en effet du point de vue du standard l analyseur n est pas capable de recevoir des alertes de la part du gestionnaire. 1.2 Objectifs de la correlation d alertes Réduction du volume d information Le premier objectif de la corrélation d alerte en détection d intrusions est de réduire la quantité d alerte que l opérateur doit traiter. En effet, une sonde de détection d intrusions peut générer un grand nombre d alertes par unité de temps, alors que la capacité de traitement d un opérateur est limitée. Cette réduction est d autant plus importante que l expérience montre que dans chaque environnement, un certain nombre d alertes surviennent fréquement, pour des raisons liées à la configuration et au fonctionnement du système d information surveillé. Ces alertes peuvent être désactivées dans la configuration du système de détection d intrusions, mais cela n est pas désirable si des attaques peuvent ensuite ne plus être détectées. Un outil de corrélation peut donc automatiser le contrôle des alertes recues pour vérifier si elles sont intéressantes ou si elles correspondent à des cas connus pour lesquels l automatisation du traitement est possible et a été réalisée. La réduction du volume d information peut être réalisée par différent moyens: Duplication Plusieurs alertes peuvent être générées par une ou plusieurs sondes de détection d intrusions, se rapportant au même événemenent dans la source d informations. Par exemple, une requête HTTP peut donner lieu à plusieurs alertes si plusieurs vulnérabilités sont détectées dans la même requête ou si plusieurs sondes les détectent simultanément. Fusion Plusieurs alertes peuvent être fusionnées en une seule qui contient l ensemble des informations portées par ces alertes. Par exemple, certaines attaques se caractérisent par des rafales d événements. Certains systèmes de détection d intrusions génère une alerte par événement dans la rafale. Il est donc souhaitable de fusionner les alertes liées à cette rafale pour faciliter le traitement de l information. Aggregation Face à un grand nombre d alertes, il est parfois possible de dégager des caractéristiques majoritaires communes à un sous-ensemble de ces alertes. Ces caractéristiques majoritaires peuvent par exemple être l adresse de l attaquant, l adresse de la cible ou le type d attaque pratiqué. L information présentée par l ensemble aggrégé permet de faire un traitement d ensemble sans s intéresser individuellement à chaque alerte. Déduction Plusieurs alertes peuvent être liées par exemple par des régles logiques explicites ou par des lois statistiques apprises. Il est possible en utilisant cette connaissance de déduire à partir d un ensemble d alertes une alerte résumant cette connaissance et de la traiter en lieu et place des alertes sous-jacentes Augmentation de la qualité du diagnostic Une alerte fournie par un système de détection d intrusions aujourd hui est souvent de très bas niveau et contient peu d information au sujet de la vulnérabilité ou de l anomalie qu elle décrit. En particulier, les types d information suivants sont intéressants et souvent ne sont pas intégrés à une alerte: Vulnérabilité effective L action de l attaquant correspond à une vulnérabilité effectivement présente sur le système d information. Vunnérabilité passée L action de l attaquant correspond à une vunnérabilité présente sur le système d information dans le passé; cette vulnérabilité a été supprimée, par exemple suite à une mise-à-jour et le système d information n est plus vulnérable au moment ou l attaque est exécutée. Vulnérabilité impossible Le système attaqué n a aucune relation avec la tentative de l attaquant. Par exemple, la vulnérabilité concerne un serveur IIS et le système attaqué est un serveur Apache. 5

6 Prise d empreinte L action de l attaquant lui permet de déterminer si le système d information est vulnérable ou non. Attaque caractérisée L action de l attaquant est une tentative avérée de compromettre le système d information. Réussite L attaquant a obtenu ce qu il cherchait par son action, soit l information recherchée soit la compromission du système visé. Cette augmentation de la qualité du diagnostic peut en particulier être réalisée par les techniques d aggrégation et de déduction décrites ci-dessus Prise en compte de l évolution du diagnostic Une attaque est rarement un événement isolé. Un attaquant cherche en général à obtenir des renseignements sur le système d information cible, ses différents composants physiques et logiques, les services qu il publie officiellement à l extérieur et ceux qui peuvent exister par ailleurs. En fonction de ces informations, il va choisir un certain nombre de cibles, les attaquer et obtenir des résultats qui guideront son évolution. Dans cette optique, l objectif de la corrélation d alerte est d abord d identifier les attaquants ou les groupes d attaquant. Cette identification doit être à la fois rapide (pour permettre d aggréger un petit nombre d alertes) et robuste (pour résister aux mutations de l apparence de cette identité réalisées intentionnellement par l attaquant ou imposées par son environnement). Pour chaque attaquant identifié, la corrélation d alertes doit permettre d historiser les actions réalisées, les informations accumulées sur l attaquant et les informations que les cibles ont fourni. A ce niveau, la notion d incident peut être prise en compte. Un incident est constitué d un ensemble d alertes correspondant à une menace sérieuse pour l entité cible de l attaque. Un incident contient des données sensibles, mais doit aussi pouvoir être partagé avec l extérieur, pour comparer les différents aspects de l activité d un attaquant contre plusieurs domaines et consolider pour chacun des domaines le diagnostic et sa connaissance de l attaquant Prise en compte des contre-mesures et de leurs effets Dans le cadre de l historique du suivi d un attaquant identifié, il est vraissemblable que des contre-mesures sont prises pour limiter les effets de l attaque. Les technologies actuelles n offrent que peu de moyens pour vérifier que les contre-mesures sont effectivement appliquées; si un paquet de coupure de connexion est envoyé il est vraissemblable qu il sera détecté par les logiciels d écoute réseau et qu il fera l objet d une alerte, mais d autres actions comme la reconfiguration de garde-barrière ou le blocage d un compte ne font en général pas l objet d alerte faute de moyen de surveillance adéquat. L objectif de la corrélation d alertes dans ce cadre est d améliorer le suivi des contre-mesures et de vérifier leur efficacité, c est à dire que l attaque en cours ne se produit plus, ou en tout cas plus sous la forme détectée. La corrélation d alertes doit aussi aider à la gestion de ces contre-mesures en permettant de les supprimer lorsqu elles ne sont plus nécessaires. D autre part, ces contre-mesures peuvent avoir des effets non désirés et donc être supprimées par des systèmes de gestion autres que le système de détection d intrusions. 2 Cartographie de sites (BM) La cartographie sert à inventorier les propriétés d un système d informations, c est à dire sa structure, ses éléménts constitutifs et leur configuration. Ces informations sont indispensables à la corrélation d alertes. Dans ce document, nous présentons d abord l apport d informations cartographiques dans le cadre de la corrélation d alertes, puis nous divisons la cartographie en deux aspects auxquels sont consacrés les deux sections suivantes: l aspect topologique, qui désigne la structure du réseau informatique d un système d informations (SI) et l aspect applicatif, qui désigne l ensemble des composants logiques du SI. 6

7 2.1 Intérêt de la cartographie pour la corrélation Pour être pertinente, la corrélation d alertes ne doit pas se cantonner aux informations liées aux alertes et aux événements. Elle doit aussi prendre en compte les propriétés du système d information considéré [2], c est à dire la structure du réseau, la nature et la configuration des composants physiques et logiques du réseau. En effet, les composants physiques et logiques d un système d informations présentent des erreurs de conception, implémentation ou configuration (des vulnérabilités) et constituent des cibles pour les attaquants. Les cibles des attaques sont désignées sous des formes abstraites et variées dans les alertes. Il est indispensable d identifier la cible réelle d une attaque à l aide d un modèle de SI, obtenu par la cartographie. En la couplant avec des informations propres aux vulnérabilités connues, la cartographie permet aussi d estimer la menace que représente une attaque vis à vis des cibles réelles du système d informations en comparant les conditions de vulnérabilité avec l état effectif de la cible. La cartographie doit aussi permettre de connaître la visibilité topologique d un IDS, c est à dire l aptitude d un IDS à détecter les manifestations d une attaque de par sa position dans le SI. La visibilité topogique permet de rendre la couverture des IDS efficace (la maximiser et éviter les redondances pour limiter les doublons d alertes). Elle permet aussi de gérer des conflits entre IDS : il est normal qu un IDS ne réagisse pas si les manifestations d une attaque ne lui étaient pas accessibles. Enfin, la topologie doit permettre de rendre compte de la propagation au sein d un réseau d attaques particulières de type ver, par exemple. 2.2 Topologie Au sens conventionnel du terme, la topologie désigne la topologie physique, c est à dire la façon dont sont physiquement interconnectés les éléments du réseau d un SI. Il faut toutefois bien noter que la notion de topologie s applique à tous les niveaux des couches OSI (physique à applicative) et la modélisation correspondante diffère à chaque niveau [5]. La littérature du domaine concerne essentiellement les topologies des couches 2 et 3, à savoir respectivement la topologie physique (liens de données, ethernet par exemple) et la topologie logique (réseau, routage, IP par exemple). En soi, l adoption d un modèle de topologie est utile, mais diffcile à établir et surtout à maintenir dans des réseaux dont la taille et la complexité croissent en permanence et où les administrateurs n ont pas toujours une maitrise totale des éléments du réseau. Un processus automatisé, appelé découverte topologique est nécessaire pour constituer le modèle à partir du réseau. Nous rappelons en annexe A différents concepts liés à la topologie physique des réseaux, en particulier les périphériques typiquement rencontrés ainsi que les différentes structures d interconnexion. Il faut noter que les informations topologiques nécessaires à la corrélation d alertes doivent être d un niveau d abstraction plus élevé que les considérations techniques évoquées en annexe A. Dans la suite de cette section, nous présentons des travaux sur les types de topologies existants et en particulier le problème de la découverte topologique. Nous présentons aussi un modèle de topologie existant, utilisé dans un contexte de détection d intrusions Types de topologies Même si les modèles topologiques varient en fonction de la couche OSI considérée, la majorité des modèles exploitent assez naturellement des graphes pour modéliser les réseaux. C est la sémantique associée aux noeuds et arcs du graphe qui apportent aux réseaux leur spécificité. Dans le cas des modèles topologiques physiques, les nœuds du graphe représentent les équipements réseau (hôtes, routeurs, hubs, switchs) ; les arcs représentent les connexions physiques entre les équipements. Dans le cas des modèles topologiques logiques, les nœuds du graphe représentent les adresses IP du réseau. Il existe alors un arc entre deux nœuds si les deux adresses IP se situent à un hop l une de l autre [8]. Le choix du modèle est donc dicté par le type de topologie requis. La topologie logique ne permet pas de connaître les détails complexes des interconnexions physiques. Dans le cadre de la corrélation d alertes, 7

8 les informations de topologie physique sont indispensables. En effet la capacité d un IDS réseau 2 à voir des événements dépend entre autre du type d équipements physiques utilisés dans le réseau. Les informations topologiques physiques sont donc indispensables. Elles n excluent toutefois pas des informations sur la topologies logique. Topologies physiques Les travaux concernant la caractérisation des relations de connexion physique entre les entités d un réseau sont relativement récentes. Les travaux de découverte topologique concernent en effet surtout la topologie logique (voir ci-après). Breitbart et al proposent un algorithme de découverte de topologie physique [2]. Cet algorithme repose sur SNMP (voir annexe B) et permet d opérer une découverte de réseaux hétérogènes. Lowekamp propose un autre algorithme de découverte de topologie physique qui ne repose pas sur SNMP, mais sur des heuristiques exploitant des fonctionnalités d outils standard (ping, traceroute, transfers de zone DNS, par exemple) [4]. En effet, une critique possible des approches de découvertes topologiques (physiques ou logiques) basées sur SNMP est que, pour que la découverte soit efficace, tous les nœuds du réseau doivent être équipés d agents SNMP, ce qui est rarement le cas [8]. Il faut noter que les outils utilisés dans cet algorithme effectuent des actions similaires à celles recontrées dans le cadre d attaques. La corrélation des alertes doit donc prendre en compte les fausses alertes liées à des actions légitimes d outils de découverte de la topologie. Complémentaire aux algorithmes présentés ci-dessus, l IETF propose une RFC contenant les MIB correspondant aux informations nécessaires à la découverte de topologies physiques [1]. Les algorithmes de Breitbar et Lowcamp permettent de modéliser les VLAN, ce qui est une fonctionnalité intéressante car ce genre de technique est de plus en plus exploitée dans les réseaux d entreprise. Topologies logiques Contrairement aux outils d interconnexion de niveau 2 (comme les switchs ou les hubs) qui n ont pas connaissance de leurs voisins, les outils d interconnexion de niveau 3 (les routeurs) ont explicitement connaissance de leurs voisins afin d effectuer leur fonction de routage. La découverte de topologies logiques - et la consitution du graphe sous-jacent - est donc un problème relativement simple, puisque l information se trouve au sein des routeurs. Outils de découverte topologique Qu elles soient logique ou physique, les découvertes topologiques effectuées par les outils existants exploitent majoritairement SNMP. Les outils commerciaux modélisent essentiellement les topologies logiques. Citons les outils suivants : HP OpenView (Hewlett-Packard) 3 Tivoli (IBM) 4 Discovery Protocol (Cisco) 5 VitalSuite (Lucent) 6 Patrol DashBoard 7 NetAlly (Omegon) 8 Felix (Telcordia Technologies) 9 Optimal Surveyor (Actualit) 10 Intermapper NIDS, Network-based Intrusion Destection System

9 Tivoli et OpenView découvrent la topologie logique en se basant sur SNMP. Discovery Protocol découvre la topologie physique avec SNMP mais utilise des MIBs propriétaires inadaptées aux réseaux hétérogènes Modèle de réseau Les algorithmes de découverte topologique constituent le modèle du réseau sous la forme d un graphe simple. Nous présentons ici un modèle de réseau un peu plus complexe, qui présente non seulement l avantage d être défini formellement mais aussi d être élaboré dans un contexte de détection d intrusions. Il est d ailleurs utilisé dans l outil NetStat. Ce modèle doit cependant être amélioré, à la lumière des travaux récents sur la découverte topologique et des avancées techniques en matière de réseaux 12. Le modèle de Vigna [10] est un modèle de topologie physique, même si la distinction entre topologie physique et logique n est pas explicitement faite par l auteur. Dans ce modèle, un réseau est un hypergraphe sur l ensemble des interfaces réseau du réseau. Les interfaces constituent les sommets du graphe, les hôtes et les liens constituent les arcs. Dans un graphe conventionnel, les arcs sont des couples de sommets ; dans un hypergraphe, les arcs sont des sous-ensembles de sommets. Par conséquent, hôtes et liens sont des ensembles d interfaces. Un lien peut être un hub dans une topologie en étoile ou un cable dans une topologie de type bus. En revanche, un switch doit être vu comme un hôte du système. I = {i 1,i 2,i 3,i 4,i 5,i 6,i 7 } H = {H 1,H 2,H 3,H 4,H 5,H 6 } L = {L 1,L 2 } L 2 = {i 5,i 6,i 7 } i 7 H 6 = {i 6 } i 6 H 5 = {i 5 } L 1 = {i 1,i 2,i 3,i 4 } i 5 i 4 H 4 = {i 4,i 5 } i 1 i2 i 3 H 1 = {i 1 } H 2 = {i 2 } H 3 = {i 3 } Fig. 2 Un exemple de réseau La figure 2 présente un exemple de réseau. I est l ensemble des interfaces, H l ensemble des hôtes et L l ensemble des liens. Les interfaces sont symbolisées par des points, les hôtes par des cercles et les liens par des segments de droite. La formalisation du modèle est donné en annexe C. A partir de ce modèle formel de réseau physique, Vigna modélise différents concepts liés à la topologie, à savoir : réseau IP, messages, routes, datagrammes, sessions. Il faut noter que, bien que les adresses IP soient évoquées, le modèle n est pas un modèle de topologie logique ; les informations de routage de paquets ne sont pas modélisées. Un réseau IP est une injection de l ensemble des interfaces dans l ensemble des adresses IP. Une route est une séquence d arcs, où alternent hôtes et liens. Un message est un triplet contenant l adresse de l interface émettrice, l adresse de l interface destinatrice et un contenu (payload). Un datagramme est une séquence de messages, chaque message corresondant à un segment de la route de l interface émettrice à l interface destinatrice. Dans le cas d un réseau IP, le payload de chaque message du datagramme est un triplet contenant les adresses IP source et destination ainsi qu un contenu. De la même manière, des sessions TCP ou UDP sont des datagrammes IP dont le contenu est un tuple contenant un sous ensemble des informtions contenues dans les entêtes de protocoles TCP et UDP (port source, port destination, numéro de séquence, etc.), ainsi qu un contenu. En outre, les datagrammes IP constitutifs d une session possèdent certaines propriétés, notemment en ce qui concernent les numéros de séquence de sessions TCP. Pour plus d informations sur le modèle et en particulier sur sa formalisation, se reférer à [10]. Cet outil est utilisé dans l outil NetStat [11] pour modéliser la topologie du réseau surveillé. Initialement, il est concu 12. ce modèle date de 1996, alors que les travaux de découverte topologique s étalent de 1996 à

10 pour modéliser certaines attaques orientées réseau (sniffing, spoofing, hijacking). Les données exploitées par un NIDS (Network-based IDS) sont les celle qui transitent sur les liens d un réseau, un NIDS réseau agissant comme un sniffer pour capter les données à analyser. Vigna propose une modélisation du sniffing en tant qu attaque, mais le modèle peut être utilisé pour évaluer la visibilité topologique d un NIDS, c est à dire être capable de dire si un datagramme transite par un lien du réseau sur lequel un IDS donné écoute. Savoir qu un IDS a accès ou non aux événements potentiellement litigieux permet ensuite de gérer d éventuels conflits entre IDS. Le modèle de Vigna est donc intéressant car il répond dans une certaine mesure aux besoins topologiques de la corrélation d alertes Conclusion Pour répondre aux besoins de la détection d intrusions, la topologie doit vraisemblablement prendre en compte la topologie physique et logique. En effet, l évaluation de la visibilité topologique d un IDS requiert la connaissance de la localisation de l IDS dans la topologie physique mais aussi avoir des informations sur le routage des messages. La modélisation d informations topologique est un problème difficile qui fait appel à un ensemble d informations complexes, volumineuses, hétérogènes et de plus en plus dynamiques, comme nous l illustrons par ces quelques exemples : L affectation dynamique d adresses IP : le protocole DHCP (Dynamic Host Configuration Protocol) affecte entre autres une adresse IP aux hôtes qui peut changer rapidement dans le temps. La relation injective qui à une interface fait correspondre une adresse IP est donc dynamique. Notons tout de même que la topologie physique change moins que la topologie physique. une même interface réseau peut recevoir plusieurs adresses IP, auquel cas l injection précédement évoquée n est plus qu une relation, le modèle de Vigna sous entend que la route suivie par un datagramme au sein d un réseau est connue afin de connaitre l ensemble des hôtes qui y ont accès ; cette information n est pas triviale, la visibilité topologique d un NIDS ne dépend pas uniquement de sa position dans le réseau et de la route empruntée par un datagramme : par exemple, les pare-feux filtrent le trafic à destination de certains hôtes et peut expliquer l émission d une alerte par un NIDS, alors qu un autre ne réagit pas. des techniques de translation d adresses (NAT, Network Address Translation) changent les adresses IP des hôtes d un sous réseau, vis à vis d autres hôtes du réseau ; une telle technique peut poser un problème de modélisation. de plus en plus, les réseaux d entreprise adoptent des technologies de type VLAN qui déplacent la topologie physique à un niveau logique et ajoutent un degré de complexité supplémentaire pour modéliser les réseaux En outre, d autres informations sont indispensables à la corrélation des alertes. Prenons par exemple les informations de nommage des hôtes. Les IDS désignent les hôtes du système d information en fonction de la nature des informations utilisées pour détecter les attaques. La cible d une attaque constitue une information privilégiée pour identifier les alertes corrélables. Identifier fiablement la cible d une attaque est donc indispensable. Les NIDS utilisent souvent des adresses IP, parfois le nom sous lequel l hôte destination (éventuellement source) est connu dans le domaine (DNS, Domain Name Service). Les IDS orientés système (HIDS Host-based IDS) utilisent le nom local de l hôte. Ces deux systèmes de nommage n ont pas les mêmes propriétés : un nom réseau est associé à une seule adresse IP, mais une adresse IP peut être connue sous plusieurs noms (et d autre part un hôte peut avoir plusieurs adresses IP). Un hôte a un et un seul nom local, mais rien n empêche un deux hôtes d avoir le même nom local. A travers ces quelques exemple, nous voyons que les informations topologiques sont de nature variées et une modélisation homogène de l ensemble de ces informations n est pas triviale. 10

11 2.3 Eléments logiques Une majorité d attaques exploitent des vulnérabilités liées à des erreurs d implémentation, de configuration ou de conception des outils logiciels. La cartographie doit permettre de faire un inventaire des outils logiciels présents sur les hôtes du système d informations, c est à dire recueillir les informations relatives à la nature, la version, la localisation, la configuration des outils logiciels présents dans un système d information. La politique de sécurité appliquée à un SI doit être formalisée pour s intégrer dans la corrélation des alertes. Elle doit permettre d exprimer des spécifications de configuration des logiciels et, à l inverse, devrait aussi permettre de formaliser une configuration existante. La configuration des logiciels est donc à la frontière entre cartographie et politique de sécurité. La cartographie doit permettre de fournir les éléments nécessaires à leur formalisation en terme de politique de sécurité. Nous ne parlerons donc pas de polique de sécurité dans ce document car la politique de sécurité devrait faire l objet d un document à part entière. Dans ce qui suit, nous nous cantonons à une présentation de l existant en matière d inventaire logiciel. Si la formalisation des politiques de sécurité pose des problèmes théoriques relativement complexes, la problématique associée à l inventaire logiciel est essentiellement technique. Le principal problème posé par l inventaire logiciel réside dans l identification précise des logiciels : il n existe pas de notation canonique des versions de logiciels. Les informations relatives aux version de logiciels vulnérables présentes dans les bases de données de vulnérabilités sont le plus souvent fantaisistes. Un certain nombre d outils fournissent des informations sur la présence et la configuration des outils logiciels en se basant sur des heuristiques. Nmap 13, par exemple, permet de deviner le système d exploitation d un hôte. En effet, le flou entourant certaines spécifications de TCP/IP donnent lieu à des implémentation différentes en fonction des systèmes d exploitation, ce qui permet à des outils comme Nmap de deviner la version d un système d exploitation en soumettant à l hôte des datagrammes particuliers et en analysant la réponse. Il faut malgré tout noter que d une part ces outils ont un comportement intrusif, d autre part ils utilisent des heuristiques plus ou moins pertinentes pour fournir des informations sur les hôtes du SI. Enfin, le spectre d informations fournis par ce type d outil est assez limité (il ne peuvent référencer que les logiciels de type serveur). Ces outils ne suffisent pas pour l inventaire logiciel. Des outils d administration réseau spécialisés dans l inventaire logiciel sont vraisemblablement plus adéquats. Citons les outils suivants : NetSaint (GNU) 14 : outil destiné à des hôtes UNIX System Management Server (SMS) (Microsoft) 15 : outil destiné à des hôtes Windows. OpenView (HP) 16 Tivoli (IBM) 17 L ensemble de ces outils sont du type client/serveur : à l image de SNMP, un client d administration interroge des agents (serveurs) disséminés sur l ensemble des hôtes du SI qui maintiennent une base de données d informations de l hôte concerné. 2.4 Modèles unificateurs Dans [7], Morin et al. proposent un modèle formel des données nécessaires à la corrélation des alertes en détection d intrusions, baptisé M2D2. Ce modèle est schématisé en figure 3. Les sommets désignent les entités manipulées dans le modèle et les liens le type de relations qui les lient entre eux. Ce modèle comprend quatre grandes familles d informations : les événements (dont font partie les alertes des IDS), les vulnérabilités, les outils de sécurité et la cartographie. Le modèle topologique utilisé dans la cartographie est inspiré de celui proposé par Vigna (voir section 2.2.1). Les outils logiciels sont modélisés sous la forme de produits (P, voir figure). Un produit est un n-uplet contenant un nom de vendeur, un nom de

12 partof Events (E) causes UDP Events (E UDP ) HTTP Events (E HTTP ) IP Events (E IP ) TCP Events (E TCP ) equiv Vulnerability Names (V N ) Reports (R) refersto canraise reportname reportname canraise IDS (D) Alerts (E A ) alert generator Scans (E S ) scan generator Scanners (S) ip dst, ip src vulname NIDS (D N ) HIDS (D H ) Vulnerabilities (V) monitored interface monitored host scans N A affects Interfaces (I) addr Products (P) configuration Hosts (H) Links (L) Fig. 3 M2D2 produit, une version et un type. Vendeur et nom de produit sont des chaînes de caractères, la version est une suite d entier et le type étant un type énuméré pouvant prendre une valeur parmis plusieurs, du type {OperatingSystem, HTTPServer, SMTPserver, LocalApplication,...}. Les vulnérabilités (V et affects, voir figure), affectent une conjonction de produits. Les hôtes hébergent un ensemble de produit (H et configuration, voir figure). Ces informations permettent entre autres d évaluer les risques associés à une attaque. Le sous ensemble de produits vulnérables à la vulnérabilité exploitée est comparé avec avec le sous ensemble de produits réellement présents sur la cible. Par exemple une attaque exploitant une vulnérabilité propre à Apache sous Unix ne fonctionne pas contre un serveur web IIS sur Windows. Il est donc possible de mitiger les degrés de gravité des alertes émises par les IDS. Ni les politiques de sécurité, ni les configurations des logiciels ne sont modélisés dans ce modèle. Ils constitueront une amélioration significative du modèle. Au sein du projet IRM (Intrusion Reference Model), Goldman et al. proposent aussi un modèle de ce type [6]. Les informations cartographiques sont représentées sous forme d une base de donnée baptisée NERD (Network Entity Relationship Database). NERD semble relativement complet, mais peu structuré. 2.5 Conclusion Nous avons présenté dans ce document un état de l art des techniques de cartographie de sites. La cartographie comprend deux aspects : la topologie et l inventaire logiciel. La topologie concerne la découverte automatique de la structure des réseaux et leur modélisation sous forme de graphe. La majorité des outils découvrent la topologie logique des réseaux, mais la corrélation d alertes nécessite aussi des informations sur la topologie physique. A cet effet, au moins deux algorithmes existent. La majorité des algorithmes exploitent SNMP pour découvrir la topologie. Un standard IETF commence d ailleurs à voir le jour dans cet optique. L objectif de l inventaire logiciel est de référencer la nature, la localisation et la configuration des outils 12

13 logiciels dans le SI. Il s agit d un problème essentiellement technique. Les aspects théoriques résident dans la formalisation de politiques de sécurité qui peuvent à la fois exploiter ou générer des informations sur la configuration des logiciels. La formalisation de politiques de sécurité n est pas du ressort de ce document. Peu d outils existent pour constituer l inventaire logiciel. Toutefois l inventaire logiciel constitue une source d informations pertinentes pour la corrélation car elle permet de mesurer la menace réelle que représente une attaque. 3 Corrélation á partir des marqueurs (FC) 4 Corrélation á partir des marqueurs et des scénarios (LM) 4.1 Introduction On appelle marqueur la trace d une attaque telle qu elle apparait au niveau du flux d information que remonte une sonde réseau, système ou applicative. Le niveau sémantique d un marqueur dépend donc du niveau d analyse pratiquée par la sonde sur les données d audit brutes. La plupart du temps, la sonde se contente d un simple filtrage ; elle analyse le flux d événements à la recherche d un événement particulier et émet alors une alerte. Un marqueur est donc une alerte (par exemple au format IDMEF) qui correspond ici à l occurrence d un événement particulier. D autres sondes réalisent aussi des actions de comptage (premier niveau d aggrégation d événements) et émettent une alerte si le nombre d événements d un type donné dépasse un certain seuil. Le marqueur est alors un peu plus riche sémantiquement, mais reste une alerte correspondant à un simple comptage d événements particuliers. L objectif que l on poursuit est la détection de scénarios d attaque complexes, c est-à-dire impliquant un enchainement d actions de la part de l attaquant. Les sondes en place sur le système attaqué émettent des marqueurs pour tout ou partie de ces actions. Pour détecter l attaque, il faut donc être capable de corréler ces marqueurs. A cette fin, l idée de base consiste à confronter le flux de marqueurs à des scenarios d attaques connus a priori. Afin d illustrer cet approche, nous décrivons dans ce paragraphe ce que font les outils G a ssata et G n G. 4.2 Utilisation d algorithmes génétiques (G a ssata) L outil G a ssata 18 développé à Supélec a proposé dés 1994 une forme de corrélation de marqueurs. Le but de G a ssata est déterminer la présence ou l absence, dans des fichiers d audit système, d ensembles prédéfinis d événements, révélateurs de tentatives d intrusions. Le principal inconvénient de l utilisation de fichiers d audit est la masse très importante de données générées qui rend difficile une analyse rapide et efficace. La complexité non polynomiale du problème et le nombre d informations à traiter entrainent rapidement les algorithmes classiques de pattern matching vers des temps de traitement trop important. Cela a conduit au développement d un algorithme génétique destiné à cette recherche. 18. Genetic Algorithm for Simplified Security Audit Trail Analysis 13

14 Dans la suite, nous présentons rapidement les algorithmes génétiques, nous expliquons comment les appliquer au problème posé, puis nous décrivons l architecture de l outil G a ssata Présentation rapide des algorithmes génétiques Les algorithmes génétiques, technique heuristique d optimisation de fonctions, s inspirent de l évolution génétique des espèces, plus précisément de la sélection naturelle. La nature ayant conduit à des organismes robustes et adaptables, on essaye de la copier pour obtenir des algorithmes de recherche d optimum. Ces algorithmes associent la survie de structures chainées les plus adaptées à leur environnement à un mécanisme d échange de l information contenue dans ces chaînes. L environnement est déterminé par la fonction dont on recherche l optimum (la fonction objectif). Pour résoudre un problème quelconque il faut donc exprimer ce problème sous la forme d une fonction objectif, ce qui est parfois difficile. Un algorithme génétique manipule une population de taille λ constante. Cette population est formée d individus. Chaque individu représente une solution potentielle au problème à résoudre, donnée sous la forme d une chaîne de caractères. Chaque chaîne de caractères correspond à un chromosome (le génotype de l individu), chaque caractère à un gène et chaque lettre de l alphabet à un allèle. L alphabet peut être binaire (les deux valeurs possibles sont 0 et 1) ou de cardinalité supérieure. La population évolue en générations successives (la création d une nouvelle génération s appelle la reproduction). Les individus les plus forts survivent et se reproduisent entre eux pour créer de nouveaux individus, tandis que les plus faibles disparaissent petit à petit. De plus, lors des reproductions, des mutations génétiques se produisent (modification d un caractère dans la chaîne). Les trois opérateurs génétiques de base sont donc la sélection, le croisement (crossover) et la mutation. La traduction algorithmique des adjectifs faible et fort appliqués aux individus conduit à définir une fonction sélective (fitness function) qui permet d associer une valeur, dite valeur sélective, à chaque individu de la population. La fonction sélective est souvent une transformation de la fonction objectif. L application des opérateurs génétiques sur des individus jugés par une fonction sélective particulière, permet d explorer l espace des solutions à la recherche d un extremum. La structure générale d un algorithme génétique est la suivante : Générer aléatoirement une population d individus de taille donnée; Répéter Sélectionner et apparier les individus; Recombiner deux individus appariés pour créer deux nouveaux individus; Faire muter certains individus; Créer une nouvelle génération en remplaçant tout ou partie des anciens individus par les nouveaux; Jusqu à ce qu un individu s impose (critère d arrêt à définir) La sélection est la première étape du fonctionnement d un algorithme génétique. Il s agit du processus selon lequel les chaînes représentant les individus sont retenues. Les individus sont sélectionnés avec d autant plus de chances que leur santé est bonne. Le mécanisme de sélection est que le nombre d occurences espéré pour un individu dans la génération suivante est le quotient de sa valeur sélective par la moyenne des valeurs 14

15 sélectives sur la population. Le mécanisme de sélection conduit à une population formée d un seul individu : l optimum de la fonction sélective sur l ensemble des λ individus de départ. Mais on veut trouver l optimum de la fonction sur l espace complet. Il faut donc être capable de créer de nouveaux individus. C est le rôle de l opérateur de recombinaison. Deux parents sont choisis aléatoirement parmi la population sélectionnée (appariement). Le crossover combine ces deux individus avec une probabilité P c. Deux enfants sont créés qui contiennent chacun une partie différente du chromosome de chaque parent. Le remplacement de l ancienne génération se fait généralement par remplacement de la totalité des parents par les descendants. Pour éviter que certaines informations (un allèle à un emplacement précis) ne disparaissent de la population lors de la sélection, un troisième mécanisme a été défini : la mutation. Cet opérateur ne crée généralement pas de meilleur individu, mais évite l établissement de populations uniformes incapables d évoluer. Il permet un déplacement aléatoire dans l espace des solutions. La pratique montre que sans lui, il y a un risque de convergence prématuré vers un extremum local. La version de base de la mutation consiste à modifier avec une probabilité faible P m les allèles des gènes des chromosomes. Il existe également des opérateurs génétiques plus évolués que ceux décrits plus haut. Nous ne les décrivons pas ici. Les deux conditions incontournables à l utilisation d un algorithme génétique pour la résolution d un problème sont de pouvoir coder les solutions de ce problème par une chaîne finie de caractères, et d être capable d attribuer une valeur sélective à chaque chaîne. L efficacité de la recherche d optimum par algorithme génétique permet d envisager le traitement de problème de complexité non polynomiale de taille importante en un temps raisonnable Principe de fonctionnement Le but de G a ssata est déterminer la présence ou l absence, dans des fichiers d audit système, d ensembles prédéfinis d événements (chaque ensemble constitue une signature d attaques), révélateurs de tentatives d intrusions. Lorsque le même type d événement apparaît dans plusieurs signatures, se pose un problème. En effet, que faire lorsque cet événement est délivré par une sonde? Faut-il considérer cet événement révélateur d une action de chacun des scénarios modélisé par chacune des signatures, ou faut-il le considérer comme une action d un seul scénario? Dans ce dernier cas, quel scénario faut-il retenir? Pour répondre à ces questions, il convient de revenir sur les besoins d un officier de sécurité en matière d outils de détection d intrusion. En considérant que l événement est élément de chacun des scénarios, on peut arriver à une situation où de nombreuses attaques sont déclarées présentes dans les traces d audit (nombreux faux positifs). Or, dans les faits, il est possible que l attaque a 1 ne puisse être réellement déclarée présente que si l on considère qu une autre attaque a 2 ne l est pas. En outre, cette exclusion entre attaque n est pas forcément limitée à deux attaques. En effet, considérer qu une attaque est présente peut en exclure plusieurs et considérer que plusieurs attaques sont présentes peut en exclure une seule. Considérons par exemple les trois signatures s 1 = abc, s 2 = cde et s 3 = ef. Si l on considère une suite d événement d audit abcde, faut-il déclarer présente l attaque a 1 de signature s 1 ou l attaque a 2 de signature s 2? De plus, si l on considère la chaîne d audit abcdef, faut-il déclarer présentes les attaques a 1 et a 3 ou la seule attaque a 2? Dans la réalité, la situation peut être encore plus complexe puisqu il peut se produire des exclusions en cascade. Nous considérons que dans de telles situations, le résultat de l analyse livré à l officier de sécurité 15

16 n est pas assez synthétique. En particulier, il interdit toute prise de décision rapide. Pour répondre à se problème, G a ssata utilise une stratégie simple : lorsqu un événement apparaîssant dans plusieurs signatures se présente, on considére qu il a été généré par l attaque dont les conséquences sont les plus graves pour le système (approche pessimiste). Cette approche peut conduire à des erreurs de diagnostics (faux positifs et faux négatifs). Cependant, dans la pratique, elle peut sembler réaliste. En outre, dans un souci d efficacité, les événements des signatures ne sont pas ordonnés temporellement, c est-à-dire qu on ne tient pas compte de l ordre d apparition des événements. La perte de l ordre temporel altère la pertinence du diagnostic (risque de faux positifs) mais peut constituer un avantage dans la pratique si l ordonnancement total des événements est impossible. Une attaque est donc définie comme un ensemble de couples (E i,n i ) où E i représente un événement et N i le nombre d occurences de cet événement dans l attaque. Le fichier d audit peut être exprimé sous la forme d un vecteur d entiers de dimension N e, où N e est le nombre d événements auditables. C est le vecteur d audit, noté O, dont le i eme élément représente le nombre d occurences de l événement i observé durant la session d audit. Si on appelle N a le nombre d attaques définies, on peut construire une matrice N a N e appelée matrice Attaque-Evénement, dans laquelle AE ij représente le nombre d occurences de l événement i dans l attaque j. On introduit également la notion de risque, qui est un poids donné à une attaque. Soit R la matrice-ligne de dimension N a où R i donne le poids de l attaque i. Soit H une matrice-colonne binaire, de dimension N a, dans laquelle H i vaut 1 si on émet l hypothèse que l attaque i s est produite, et 0 sinon. L analyse du fichier d audit consiste à déterminer la matrice H maximisant le produit matriciel R.H, tout en respectant la contrainte (AE.H) i O i. On recherche donc la combinaison d attaques qui, tout en étant possible au regard du nombre d événements de chaque type dans le fichier d audit, maximise le risque encouru par le système (voir figure 4). Ce problème est NP complet si bien que le temps de traitement nécessaire à sa résolution est prohibitif si N a ou N e sont trop grands (ce qui est le cas dans la pratique, notamment pour N a ). L utilisation d un algorithme génétique est donc tout à fait pertinente. Le codage des individus est évident : on veut déterminer la meilleure matrice-colonne binaire H, un individu est donc une suite de N a gènes pouvant prendre les valeurs 0 et 1. Chaque individu correspond à une occurence de la matrice H. Le problème à résoudre est de trouver le maximum du produit matriciel R.H, tout en respectant l inégalité : (AE.H) i O i. La fonction sélective proposée est : ( Na ) F (I) = α + R i.i i β.te p i=1 où T e est le nombre d éléments tels que (AE.H) i > O i. La valeur sélective d un individu est proportionnelle au produit R.H et elle décroît si l individu code une combinaison d attaque irréaliste au regard de ce qui a été observé (c-à-d si le nombre d événement d un type donné est plus important dans l hypothèse que dans la réalité). Les valeurs choisies pour les paramètres sont 200 pour α, 2 pour β et 2 pour p. Ces valeurs sont celles qui ont donné les meilleurs résultats lors des expérimentations mais restent modifiables lors de l utilisation 16

17 1 1 i R i N a H j j = Maximum? N a j 1 i N a 1 1 AE ij H i i = 1 j Na Σ i=1 H j. AE i j? > i 1 j O j N e N a N e N e Fig. 4 Analyse d un fichier d audit de sécurité de l outil G a ssata Architecture de l IDS G a ssata G a ssata permet la détection d attaques dans un réseau de machines UNIX, conformément à la méthode exposée dans la section précédente. La figure 5 résume l architecture présentée dans la suite de ce paragraphe. Ce type d architecture (sondesmanagers) est aujourd hui celle de quasiment tous les IDS. On veut pouvoir étudier dans une seule et même analyse des traces d audit provenant de machines différentes et donc potentiellement de systèmes différents (on parle de sources d audit différentes). Le principe est de calculer un vecteur d audit à partir d un fichier dans lequel auront été rassemblées les traces d audit provenant des différentes sources. Ce vecteur permettra la recherche d attaques, préalablement définies par l administrateur de sécurité, sur un ensemble de sources, par un seul passage de l algorithme génétique. G a ssata doit pouvoir être utilisé sur un nombre illimité de types de sources d audit. C est la raison pour laquelle il est important de mettre en œuvre une architecture ouverte permettant d inclure de nouvelles sources. G a ssata comprend donc un module dit traducteur, interface entre le reste de l outil (indépendant des types de sources) et les sources elles-mêmes. En fait, un traducteur n est rien d autre qu une sonde qui prend l audit système brut et génère des alertes correspondantes dans un format fédérateur (format de Bishop ou format IDMEF, selon les versions de l outil). Il y a autant de traducteurs que de types de sources d audit 19. Les traducteurs communiquent avec le manager (machine sur laquelle se fait l analyse des alertes) par l intermédiaire d un module nommé interface réseau chargé de regrouper toutes les informations reçues des traducteurs et de leur transmettre des requêtes provenant du panneau de configuration. Un protocole de com- 19. Pour l instant, nous disposons d un traducteur pour audit système AIX et d un traducteur pour audit BSM. 17

18 munications entre les différentes parties a été élaboré afin d uniformiser le comportement des traducteurs face à l interface. Un panneau de configuration permet la configuration de l outil et le lancement de l analyse des audits enregistrés. Le travail de configuration est triple : La définition des événements G a ssata. Les enregistrements d audits sont des suites de champ indiquant, outre l événement détecté, des renseignements tels que le processus à l origine de l événement, le résultat obtenu par la requête qui a généré l événement, etc. Pour l administrateur de sécurité, il peut être intéressant de regrouper ces informations en événements plus synthétiques appelés événements G a ssata. Par exemple : un événement login avec echec à répétition pourra être généré si N événements login avec echec sont rencontrés (fonction classique de comptage, réalisé ici sur le manager et non dans une sonde) ; un événement connexion distante pourra être généré si telnet ou ssh est remonté. application de la règle telnet ou ssh. Ce sont ces événements qui seront recherchés dans les fichiers d audit. L analyse des alertes envoyées par les traducteur permettent la génération des événements G a ssata. Les événements G a ssata sont les marqueurs définis précédemment. La création des événements G a ssata se fait par analyse syntaxique des champs des enregistement d audit qui remontent des sondes. L analyseur est configuré par des règles logiques. Par exemple : RemoteCnxFailed ::= (event=ftpcnxfailed) or (event=telnetcnxfailed) (event étant un champ des événements au format Bishop). Il faut notre que dans la plupart des autres IDS, ce premier travail de regroupement d événements est plutôt fait dans les sondes. La définition des matrices attaque-événement. Les attaques sont définies comme des ensembles d événements G a ssata. La configuration des traducteurs. Afin de limiter la taille des audits à manipuler, le traducteur effectue un premier filtrage sur les événements à transmettre (fonction classique de filtrage des sondes). La configuration lui indique ces événements. 4.3 Alternative à l algorithme génétique (G n G) Dans le cadre du projet MIRADOR 20, une nouvelle version de G a ssata a été développée. Pour la distinguer de la version précédente, nous l appelerons G n G, pour Gassata new Generation. Tout comme dans la version précédente, on définit une matrice d attaque qui contient les nombres d occurences de chaque type d événement pour chaque attaque. Les sondes (traducteurs) envoient des événements (messages en XML au format IDMEF) au manager qui fabrique le vecteur d audit en comptant ces événements. Outre la matrice d attaque, G n G se configure par l intermédiaire d un langage de description d attaques baptisé ADeLe [?]. Ce langage permet d exprimer des contraintes sur l ordre temporel des événements et sur les valeurs des champs de ces événements. Les contraintes définies en ADeLe portent sur les valeurs contenues dans les champs XML des instances d événements. Si l on prend l exemple d une attaque qui serait définie à partir des événements E0, E1, E2 et E3, on pourra écrire en ADeLe dans la section adéquate de la description : <CONTEXT> 20. PEA de la DGA/CELAR/CASSI piloté par Alcatel et impliquant Supélec, l ONERA et l ENSTB. 18

19 Machines auditées Manager Machine d analyse des audits Machine 1 Source d Audit Traducteur (sonde) réseau Analyseur Syntaxique Evénements GASSATA (marqueurs) Algo. Génétique Source d Audit Traducteur (sonde) Interface réseau Règles d agrégation Signatures d attaques Machine 2 Concaténation Envoi config. Source d Audit Traducteur (sonde) Config des machines Panneau de configuration Fig. 5 Architecture de l outil G a ssata E0.Source.User.name == "guest" E1.Target.User.name == E2.Target.User.name == E3.Target.User.name </CONTEXT> La stratégie de l ancienne version présentée dans le paragraphe est modifiée. Pour G n G, on ne doit pas trancher. Reprenons l exemple du paragraphe : trois signatures s 1 = abc, s 2 = cde et s 3 = ef ; une suite d événement abcde. Pour G n G, l attaque 1 et l attaque 2 doivent être déclarées présentes. En d autres termes, on renonce ici à l aspect synthétique du diagnostic, en considérant que le risque de faux diagnostic est trop important. En conséquence, G n G travaille en 2 passes : La première passe remplace l algorithme génétique. Par simple comparaison des composantes du vecteur d audit et de ceux des différentes attaques spécifiées dans la matrice d attaque, elle détermine quelles attaques sont potentiellement présentes dans les traces d audit (on parle de pré-diagnostic). Contrairement à ce que faisait l algorithme génétique, c est-à-dire considérer les attaques dans leur ensemble, cette première passe considére chaque attaque indépendemment. C est la traduction de la nouvelle stratégie adoptée. En d autres termes, quand l algorithme génétique donnait comme diagnostic : attaque1 ET attaque2 ET attaque5 (avec l hypothèse que les instances d événements ne sont 21. lorsqu un événement apparaîssant dans plusieurs signatures se présente, on considére qu il a été généré par l attaque dont les conséquences sont les plus graves pour le système. 19

20 -construction d un tableau des différentes valeurs E0.Source.User.name prises par les différentes instances de E0 -comparaison avec la valeur "guest" -SI correspondance ALORS on appelle récursivement l algorithme sur la ligne de contrainte suivante (mais avec un E0 figé) -construction d un tableau des valeurs E1.Target.User.name -comparaison de chaque valeur avec chaque E2.Target.User.name -SI correspondance ALORS -comparaison avec chaque E3.Target.User.name -SI correspondance ALORS on a un trouvé un vecteur (E0,E1,E2,E3) => attaque présente SINON on passe au E3 suivant SINON on passe au E2 suivant SINON échec => cette attaque n est pas présente Fig. 6 Algorithme de corrélation de G n G. pas partagés par les différentes attaques), la première passe de G n G donne attaque1 OU attaque2 OU attaque5 (dans ce cas, les instances d événements peuvent être partagées). La seconde passe constitue une post-analyse des attaques indiquées comme potentiellement présentes par la première passe. On vérifie dans cette post-analyse que toutes ces contraintes supplémentaires spécifées dans la description ADeLe de l attaque sont bien vérifiées. Il s agit donc d une corrélation d événements permettant d infirmer ou de confirmer le pré-diagnostic de détection de la première phase. Note : la vérification de l ordre temporel des événements n est actuellement pas mise en œuvre dans G n G. L algorithme de corrélation est une fonction récursive qui va rechercher les instances qui vérifient simultanément chaque ligne de contrainte. Il doit donc extraire les valeurs des champs concernés contenues dans les instances d événements pour faire des comparaisons. Dès qu une contrainte n est pas vérifiée, il revient en arrière et essaie une autre instance pour voir si elle a des valeurs qui correspondent. Lorsque l algorithme trouve un vecteur (E0,E1,E2,E3) qui satisfait toutes les contraintes à la fois, on estime qu on a détecté une attaque réelle (et non plus potentielle). Si, après le parcours en profondeur de l arbre des contraintes, on n a pas trouvé de combinaison satisfaisante d instances d événements alors on estime que ces événements n ont rien à voir entre eux et que l attaque considérée n était finalement pas présente. La figure 6 donne l algorithme simplifié appliqué à l exemple précédent. D une manière générale, lorsqu un (ou des) événement(s) vérifient une ligne de contrainte, on réappelle récursivement l algorithme avec la ligne de contrainte suivante (mais avec les événements précédents figés). De même, pour chaque ligne de contrainte, on extrait les valeurs du premier champ de la contrainte et on les compare itérativement avec les valeurs des champs qui suivent dans la ligne. L algorithme se termine soit par un échec (pas de vecteur d événements qui correspond), soit par un ou plusieurs vecteurs qui conviennent (auquel cas on a trouvé une ou plusieurs possibilités pour que cette attaque soit présente). G n G donne des diagnostics plus précis que G a ssata (moins de faux positifs et de faux négatifs), mais n a été pour le moment expérimenté qu avec une base de quelques signatures. Reste à évaluer les performances de la seconde passe dans le cas ou la base de signatures est importante. 20