DÉTECTION D ANOMALIES COMPORTEMENTALES APPLIQUÉE À LA VISION GLOBALE. le grade de docteur

Transcription

1 Numéro d ordre 2008-ISAL-XXX Année 2008 Thèse DÉTECTION D ANOMALIES COMPORTEMENTALES APPLIQUÉE À LA VISION GLOBALE présentée devant L Institut National des Sciences Appliquées de Lyon pour obtenir le grade de docteur Ecole doctorale : Informatique et Information pour la Société soumis le 30 Octobre 2008 Par Jacques Saraydaryan Soutenue le 12 décembre 2007 devant la Commission d examen Jury Benferhat Salem Professeur des Universités Rapporteur Université d Artois Zeghlache Djamal Professeur des Universités Rapporteur Ducassé Mireille Morin Benjamin Ubéda Stéphane Legrand Véronique Université Paris 6 Professeur des Universités INSA de Rennes Enseignant Chercheur Supelec de Rennes Professeur des Universités INSA de Lyon (Directeur de thèse). Ingénieur de recherche, Professeur associé Exaprotect Cette thèse a été préparée au Centre d Innovation en Télécommunications et Intégration de Services (CITI), INSA de Lyon - INRIA Rhône-Alpes

2

3 Remerciements Je tiens tout d abord à remercier Salem Benferhat et Djamal Zeghlache d avoir accepté d être mes rapporteurs, ainsi que Mireille Ducassé et Benjamin Morin qui m ont fait l honneur d être dans mon jury. Je souhaite remercier Jean-François Dechant et Chritophe Briguet de l entreprise Exaprotect qui m ont accordé leur confiance et permis que cette collaboration se fasse dans les meilleurs conditions possibles. Je souhaite aussi remercier l ensemble de l équipe Exaprotect pour leur bonne humeur quotidienne, leurs conseils avisés et leur disponibilité. Je remercie tout particulièrement Laurent pour ces nombreux conseils pertients, Anne et Gilles pour leur aide précieuse et Luc pour ces moments de collaboration plein de bonne humeur et pour ces remarques pointues qui ont contribué à l aboutissement des mes travaux. Je souhaite aussi exprimer toute ma gratitude envers Stéphane Ubéda et Véronique Legrand pour leur patience, leur aide, leurs conseils indispensables ainsi que pour leurs qualités relationnelles exceptionnelles qui m ont permis d effectuer cette thèse dans les meilleurs conditions possibles. Merci à l ensemble des membres du CITI pour leur convivialité et leur aide tout au long du déroulement de cette thèse et tout particulièrement Fatiha avec qui j ai partagé ces années de recherche. Je ne serais oublier l ensemble de mes amis Julien, Aline, Pierre, Gess, Benjamin, Chérif, Marc, Fred, Lili qui a leur manière ont aussi contribué à cette thèse tout particulièrement pour leur soutient moral indispensable au bon déroulement de ces années. Je tiens à remercier tout particulièrement mes parents pour leur soutien inconditionnel durant toutes ces années, ma soeur pour son assistance et sa présence de chaque instant ainsi que l ensemble de ma famille qui ont contribué de près ou de loin à cette thèse. Enfin, je terminerais par remercier chaleureusement Stéphanie qui m a supporté et encouragé durant ces trois années. Je la remercie pour sa joie de vivre et son soutient de chaque instant qui ont fait de ces trois années, trois années de partage et de réussite. iii

4

5 Table des matières Remerciements iii 1 Introduction Contexte général de la thèse Objet de nos travaux La détection d Intrusion Nature des données analysées Nature de l apprentissage des outils Vers une Vision Globale du Système d Information Les enjeux des nouvelles menaces Problématiques liées à la vision globale Architectures et processus de traitement appliqués à la vision globale Sujet détaillé et contributions État de l Art Introduction Architectures appliquées à la vision globale Architectures distribuées Centralisées Architecture Distribuée Collaborative Algorithmes d analyses Conclusion Collecte et Fusion d information Introduction Architecture de collecte d informations Hiérarchie et communication Rôle des agents Rôle du serveur d analyse Homogénéisation des données Homogénéisation de la syntaxe des données Homogénéisation de la sémantique des données : vers une Ontologie comportementale Conclusion v

6 4 Analyse des démarches utilisateurs Introduction Notion d indicateurs Description d un SI Démarche des acteurs du système Démarche Utilisateur Démarche Administrateur Démarche Système d Information Démarche Attaquant Synthèse : sélection des informations à observer Indicateurs pour le compteur de gain/perte d accès (Confidentialité) Indicateurs pour le compteur de gain/perte de privilège (Intégrité) Indicateurs pour le compteur de gain/perte d utilisation du système (Disponibilité) Sélection d Indicateurs Focalisation sur les Points de Passage Obligatoires Périmètre de surveillance (Risque) Conclusion Corrélation et Reconnaissance d Anomalies Comportementales Introduction Choix du Modèle Propriétés Les techniques de modélisation existantes Introduction aux réseaux Bayésiens Les réseaux Bayésiens dans la détection d intrusion Apprentissage : Réalisation d un profil de comportement normal Règles de regroupement Graphe d activités des utilisateurs Modélisation des profils utilisateurs par Réseaux Bayésiens Gestion des cycles dans la structure de base du réseau Bayésien Apprentissage : Enrichissement du modèle, Modélisation de la temporalité Analyse des dépendances temporelles Besoins Modélisation de la temporalité Construction des noeuds temporels Amélioration du processus de Modélisation Définition du modèle final Exploitation : détection de déviances comportementales Classes d anomalies Graphe de détection Détection d anomalies Contrôle : Évaluation des évènements déviants et mise à jour du modèle de référence 96

7 5.7.1 Qualification d un élément déviant Module de décision Conclusion Extraction de règles de corrélation Introduction Définition Les Chroniques Génération automatiques de règles Sélection des évènements appartenant à une même Chronique Chronique unique par chemin Chroniques hiérarchiques par chemin Utilisation des chroniques hiérarchiques Sélection des séquences les plus probables Labélisation automatique des règles de corrélation Définition d un utilisateur du Système d Information Détermination de la signification d une séquence Détermination des cibles : Technical Services/Business Services Rôle des Assets dans le nommage des séquences Expérimentation Conclusion Expérimentation Introduction Jeu de tests simple : banc de tests Composition du jeu de tests Modélisation des activités utilisateurs Résultat de la détection d anomalies Jeu de test réel : grand compte Composition du jeu de tests Périmètre des tests Modélisation des activités utilisateurs Résultat de la détection d anomalies Conclusion Conclusion Contributions Perspectives Amélioration de la détection Amélioration de la modélisation Contrôle de l évasion de notre moteur Discussion

8 9 Annexes PPOs Remote to Local PPOs Denial of service PPOs Surveillance/probe PPOs System Access/Alter data PPOs Règles de nommages Même cibles Cibles Différentes Classification des Business Service Bibliographie 159 Liste de publications 167

9 Liste des tableaux 2.1 Architecture HIDE à base d agents Apprentissage semi-explicite des scénarios d attaques Recherche de causes de XMeta Description des ensembles des objets utilisés Représentation des dépendances temporelles Action user evaluation Evaluation de l exposition aux attaques des zones du SI Description des scénarios Remote to Local Description des scénarios User to Root Description des scénarios System Access/Alter Data Évolution des taux de détection pour les différents seuils d évaluation ix

10

11 Table des figures 1.1 Rémunération d activités malicieuses Évolution des vulnérabilités découvertes Production de nouveaux codes malicieux Evolution des Systèmes de Détection d Intrusion Architecture Centralisée Architecture Distribuée Processus pour la détection comportementale sur la vision globale Exemple d architecture GrIDS (Graph-based Intrusion Detection System) Architecture du moteur de détection d anomalies Architecture de détection coopérative hiérarchique Architecture de détection d intrusion à l aide d agents mobiles Répartition d alertes dans le temps sur des scénarios d attaques de DEFCON Exemple type de graphe d attaques Architecture Hiérarchique centralisée Architecture Fonctionnelle Structure d un message IDMEF Sémantique d un message de sécurité Caractérisation d un indicateur Relations acteurs-composants d un SI Démarche utilisateur Démarche administrateur Démarche Système Démarche d un attaquant Points de passage obligatoires Classification des actions d attaques Sélection des indicateurs par PPOs et par nature d équipement Exemple de Réseau Bayésien Rebond d un utilisateur Exemple de corrélation d évènements Correspondance entre le graphe G (S, E ) et le réseau Bayésien BN(G ) xi

12 5.5 Propagation de probabilité dans un graphe cyclique Exemple de changement de représentation Transformation du graphe cyclique en graphe acyclique Analyse des séquences présentant des cycles Représentation des intervalles de temps séparant des évènements corrélés Illustration des différentes dépendances temporelles Exemple de réseau Bayésien dynamique LOF des points de différentes communautés Intervalles de temps entre deux évènements corrélés Évolution de la population Noeuds temporels du réseau Bayésien (noeuds de liens absorbés) Différentes transformations pour la construction du réseau Bayésien de référence Taxonomie des comportements de sécurité des utilisateurs finaux Classification des résultats avec un noyau radial Classification SVM Classification SVM par Régression Prédicats Transformation d un chemin en chronique unitaire Chronique hiérarchique : chroniques de composition et de conception Détail de l Identité d un User Détail des objectifs d un User Détail des composants d intérêt utilisé par un User Détail des activités d un User Détail des compétences d un utilisateur Sémantique d une séquence Exemple de règles de nommage Représentation des besoins de l entreprise et ceux du SI (Cobit) Classification des Business Services Classification des services techniques Business Services Spécification Processus de labélisation Répartition du nombre de catégories d évènements par Chronique Répartition des catégories d évènements par chroniques Exemple de génération automatique de Chronique Architecture du banc de tests Jeu de tests d apprentissage Résultats de la détection d anomalies Jeu de données collectées réparties sur 25 jours Évolution de la structure du réseau du Bayésien Évolution des états des noeuds Visualisation de la Réduction du modèle

13 7.8 Taux de détection de notre approche sans Evaluation Evolution de la probabilité de l état d un noeud lors de l apprentissage Règles de nommages pour des évènements provenant d un même composant Règles de nommages pour des évènements provenant de composants différents Caractérisation des classes de Business Services

14 1 Introduction 1.1 Contexte général de la thèse L évolution fulgurante des réseaux informatiques et d Internet ces vingts dernières années a modifié le paysage économique ainsi que les différents modes de communication et d échanges sur la planète. Attirée par une flexibilité de services et de nouvelles niches économiques, la majorité des organismes privés et gouvernementaux utilisent les ressources d Internet aussi bien pour inter-connecter des sites distants que pour proposer des services en ligne. Avec plus d un milliard d utilisateurs d Internet, la croissance des transactions économiques sur la toile est en pleine essor. Selon [1], le volume de transaction en ligne du Canada a augmenté de 38% en 2006 pour un montant de plus de 40 milliards de dollars d échange. Constat similaire pour les Etats Unis avec une hausse de 25% des activités e-commerces et près de 108 milliards de dollars générés ou échangés. Cet essor rapide modifie l impact des technologies orientées Web sur l activité des entreprises. Tout d abord, l augmentation des activités business des organismes autour du e-commerce entraine une forte dépendance de leur économie à la disponibilité et la sureté des services fournis. De plus en plus d entreprises focalisent leur activité sur des services rendus ou fournis par Internet. Une perte de l un de ces critères de sécurité (Disponibilité, Intégrité, Sureté) peut avoir des répercutions directes sur les chiffres d affaires des entreprises. Du fait de la globalisation et mondialisation du commerce et des échanges, les entreprises actuelles bâtissent des architectures de Système d Information toujours plus complexes afin de permettre l inter-connection des différents services ou sites distants. Cette mutualisation des informations et ces architectures 1

15 2 Contexte général de la thèse d échange entraine une dépendance toujours croissante des entreprises aux Systèmes d Information. Face à cette augmentation d échanges et de transactions lucratives sur le net, le visage de la cybercriminalité se modifie profondément. Dès les débuts d Internet, des premières attaques ont été menées par des experts disposant de grandes compétences techniques. Ces premiers Hackers, avait plus comme objectif d accomplir des exploits techniques que d attaquer ou pénaliser des organisations particulières. Ce profil d attaquant a peu à peu évolué avec l évolution des technologies et du nombre d internautes et organismes connectés. Des années 1990 aux années 2000, de nouveaux profils de cybercriminels sont apparus. De nouvelles communautés aux objectifs et techniques différents se sont formées, se regroupant en organisation ou se scindant en plus petits groupes opérant individuellement. [2] a différencié au sein d une taxonomie sept groups distincts de Hackers : newbie/toolkit, cyber-punks, internals, coders, old guard hackers, professional criminals et cyber-terrorists. Newbie/toolkit s apparente à des utilisateurs non expérimentés qui s initient aux attaques utilisant des outils fournis par des attaquants plus expérimentés (coders ou old guard hackers). Ce groupe d attaquants réalise des attaques par pur loisir, sans intention de nuire à des organismes particuliers ou de voler des informations confidentielles. Cyber-punks ont des connaissances techniques plus poussées et tentent d utiliser leur connaissance pour effectuer des actions malicieuses (défacement de site web, vol de carte de crédit) pour leur propre usage. La catégorie internals possède des objectifs différents. Cette catégorie de Hackers regroupe des employés ou anciens employés mécontents qui utilisent leurs privilèges sur le Système d Information pour mener à bien leur attaque. Les coders et old guard hackers définissent un groupe possédant une très grande expertise et forment une communauté de passionnés réalisant des outils d attaques. Ces individus privilégient les prouesses techniques et la reconnaissance au sein de leur communauté plutôt que les vols et les attaques ciblées pour leur propre intérêt. Les deux dernières catégories représentent les groupes les plus dangereux et virulents de la toile. Les professional criminals et cyber-terrorists constituent des groupes d individus de forte expertise technique qui utilisent leur savoir faire afin de réaliser des profis pour eux même ou pour des commanditaires. Cette dernière catégorie (professional criminals) a fortement évolué depuis ces dernières années. Selon plusieurs rapports sur la cybercriminalité [1], [3], [4], les professional criminals sont structurés et alimentent une véritable économie souterraine. [1] estime qu en 2007, 5% des clients de banques en ligne Nord Américaine (2 millions de personnes) ont été victimes d attaques sur leur compte pour une perte moyenne de 1200 dollars soit une perte totale de 2 milliards de dollars. La professionnalisation de la cibercriminalité encourage le dévellopement de nouvelles attaques de plus en plus complexes. Equipés d une armée de bots/botnets (programmes dormants sur des miliers de postes infectés) ou de rootkits (boite à outils permettant de prendre les privilèges d administrateur sur une machine) de plus en plus performant, les professional criminals sont rémunérés pour des opérations financées par des commenditaires (figure 1.1).

16 Introduction 3 Fig. 1.1 Rémunération d activités malicieuses Cette augmentation d attaques ainsi que cette professionnalisation du piratage à grandement été facilité par l augmentation des vulnérabilités sur les composants des différents Systèmes d Information. L augmentation de la complexité des composants et des infrastructures des Systèmes d Informations a engendré une augmentation croissante des vulnérabilités [5] (figure 1.2). Fig. 1.2 Évolution des vulnérabilités découvertes Ces vulnérabilités offrent aux communautés d attaquant un large panel d exploits possibles pour parvenir à leurs objectifs. Chaque vulnérabilité peut aboutir à des effets différents allant de la divulgation d information à l accès au système. Malgré une faible diminution des vulnérabilités en 2007, les conséquences de l exploitation de failles de sécurité possèdent une sévérité beaucoup plus élevées. [6] nous indique que la sévérité moyenne d une faille de sécurité a doublé durant les douze derniers mois passant de 2.6 à 4.8 sur une échelle de 10. De plus, la production de nouveaux codes malicieux a triplé en moins d un an entre 2006 et 2007 [4] (figure 1.3). La sécurité des Systèmes d Information déjà incontournable devient un enjeu majeur pour

17 4 Contexte général de la thèse Fig. 1.3 Production de nouveaux codes malicieux la majorité des organismes privés et gouvernementaux. Avec l émergence de communautés d attaquants de plus en plus professionnelles, réalisant des attaques toujours plus sophistiquées et dévastatrices, la sécurité des Systèmes d Information se dote d outils visant à sécuriser les applications du e-commerce ainsi que les Systèmes d Information (SI) dans leur ensemble. Les premières générations de mécanismes de sécurité ont vite été submergées face à l augmentation de nouveaux scénarios d attaques complexes. Les firewalls toujours garant des flux au sein des SI ainsi que les antivirus indispensables à la détection de codes ou programmes malicieux se sont vus renforcés par des Systèmes de détection d intrusion permettant la découverte de parties de scénarios d attaques. Ces équipements de sécurité viennent compléter l arsenal défensif du SI analysant trafics ou applications à la recherche de traces d attaques Objet de nos travaux C est face à cette évolution des différentes menaces sur les SI et des limites actuelles des équipements de sécurité que nous avons travaillé ces trois dernières années à l élaboration d une technique de détection d anomalies comportementales appliquée à la vision globale. La notion d apprentissage nécessaire à tout système de détection a été un élément incontournable pour la réalisation de profils d utilisateurs normaux. Afin de garantir la détection d intrusion, les systèmes de sécurité se doivent d apprendre des traces leur permettant de détecter des intrusions (signatures d attaques) ou des comportements normaux leur permettant de mesurer des déviances (détection d anomalies). Dans la suite de ce document nous appellerons nature d apprentissage le mode opératoire permettant à ces systèmes d apprendre leur pre-requis. La forte interaction avec l entreprise Exaprotect éditeur de logiciels de sécurité a permis de concrétiser nos travaux par l évaluation de notre méthode à l aide de données réelles. Nous présenteront un bref tour d horizon des différentes techniques de détection d intrusion avant d introduire et de définir la vision globale. Les différents processus utilisés par notre méthode seront décrits plus précisément dans la section 1.4.

18 Introduction La détection d Intrusion Les premières briques de sécurité ont tenté de maitriser l ensemble des interactions dans les Systèmes d Information. La mise en place de politiques de sécurité a constitué la première étape vers la réduction des risques au sein du SI. Des équipements de sécurité contrôlant les flux de données tels que les firewalls, ainsi les programmes ou services présents sur les composants du SI (antivirus) ont été élaborés dans une optique similaire. Néanmoins face à la création de systèmes toujours plus complexes avec une connectivité toujours croissante, la maitrise de tels environnements est devenue rapidement difficile laissant place à des failles de sécurité organisationnelles et logicielles (vulnérabilités). Ce constat a engendré l émergence des systèmes de détection d intrusion (Intrusion Detection System IDS) capable de détecter des tentatives d activités malicieuses sur le système. L intérêt autour des systèmes de détection d intrusion a débuté dès les années 80 comme précisé dans [7], par un premier rapport de James Anderson, Computeur Security Threat Monitoring and surveillance. [7] précise que les fichiers d audit du SI contiennent des informations vitales pour la compréhension et l étude des comportements utilisateurs et la détection de comportements déviants. Suite à ces travaux Dorothy Denning a réalisé pour un projet gouvernemental le premier système d analyse d audit en Elle publia par la suite le premier modèle de détection d intrusion à base de système expert [8]. Contribuant à la mise en oeuvre d un système d analyse de données d audit d authentification des utilisateurs d ARPANET (premier réseau à transfert de paquets, Internet originel), elle publia un article décisif sur les informations nécessaires pour le développement de Système de Détection d Intrusion commercial en Dès lors plusieurs projets et travaux ont vu le jour faisant évoluer la notion de détection d intrusion et les méthodes de mise en oeuvre. S inpirant des premiers travaux sur la détection d intrusion, un projet des laboratoires Lawrence Livermore a conduit à la création d un Système de Détection d Intrusion pour l US Air Force comparant les données d audit à des patterns prédéfinis (la première détection par signature). Les premières notions de Système de Détection d Intrusion Distribuée (Distributed Intrusion Detection System DIDS) sont apparues en Les DIDS améliorent les principes de détection précédant en analysant des informations contenues sur plusieurs machines. L analyse des informations a été étendue à l ensemble des postes clients et ne se restreint plus à l analyse d un seul serveur (Haystack Lab). Ce n est qu en 1990 que la notion Système de Détection d Intrusion Réseau a été abordée [9]. Heberlien, qui a également contribué à l évolution du projet DIDS, est le premier a avoir introduit la notion de système de détection d intrusion hybride, utilisant à la fois comme source de données les informations provenant de l activité réseaux et celle de l activité du système. La commercialisation des Systèmes de Détection d Intrusion a débuté dans les années 1990 avec l apparition du premier Système de Détection d Intrusion Réseau en 1994 (NetRanger de Wheel Group). Le cycle de mise en oeuvre et d investigation des solutions de détection d intrusion s étend sur près de 15 ans (figure 1.4) et ce n est que ces cinq dernières années que ces outils de sécurité apparaissent comme indispensables à la sécurisation des systèmes. Ces systèmes permettent en

19 6 La détection d Intrusion effet de jauger les différentes menaces pesant sur des composants sensibles du SI et de déceler des traces d attaques au sein des systèmes. Fig. 1.4 Evolution des Systèmes de Détection d Intrusion La plupart des études sur les IDS classe ces systèmes suivant deux caractéristiques principales, la nature des données observées et la méthode d analyse. Deux familles de natures de données se distinguent, les données provenant d une machine ou d un composant appelées données systèmes et les données provenant des échanges au sein du SI appelées données réseaux. Les méthodes d analyses, quant à elles, sont traditionnellement divisées en deux catégories distinctes : les systèmes de détection à base de signature (misuse detection) et les systèmes de détection comportementale (anomaly detection). Les systèmes de détection par signature permettent de déceler des patterns connus dans les données analysées. Les systèmes de détection comportementale, pour leur part, tentent de détecter les déviances d un comportement vis à vis d un profil normal. Quelque soit la nature de l IDS utilisé, il compare les données analysées à une référence décrite par une signature, ou un profil normal (ou anormal). La réalisation de cette référence et son maintien nécessite de la part de l IDS un apprentissage particulier. Cet apprentissage constitue un critère supplémentaire permettant de différencier les méthodes d analyse Nature des données analysées Les différents Systèmes de Détection d Intrusion se différentient principalement par la nature des éléments observés et analysés. Comme le montre l évolution des IDSs, plusieurs éléments des SI sont analysés. La littérature a introduit plusieurs types d observations autour des IDS. Trois grandes familles peuvent être distinguées, les observations portant sur les composants du système (Host Intrusion Detection System HIDS) les observations portant sur le trafic réseau du système (Network Intrusion Detection System NIDS) et les observations portant sur des alertes d IDS (meta IDS).

20 Introduction 7 a) Données Système (pour HIDS) Les HIDS traditionnels focalisent leur analyse sur des points particuliers du SI. [10] a réalisé un état de l art des HIDSs ainsi que la nature des sources de leur observation. Les auteurs ont distingué cinq grandes sources d observation de ces systèmes : les accès au système d information, l utilisation du système d information, l utilisation des fichiers du système d information, l utilisation des applications et la violation des politiques de sécurité. Nous garderons cette classification pour présenter les différentes natures de données analysées par les HIDS. Source d observation : Accès au SI. Les informations d accès au SI décrivent comment un utilisateur, ou une machine a accédé au SI. Ces informations sont particulièrement utilisées dans les IDSs comportementaux qui cherchent à déceler des accès anormaux. Ces derniers portent leur analyse sur des attributs particuliers relatifs à l authentification (nom du user ou id du processus, le mode de connexion, le temps relatif entre deux connexions) et tentent de détecter des anomalies dans cette combinaison de données. Les IDS par signature utilisent également cette source d information afin de s assurer que des tentatives d exploits de gain d accès ne sont par réalisées. Pour cela leur étude se focalise sur les noms d utilisateur et mots de passe possédant des caractères spéciaux ou une taille excessive. Source d observation : Utilisation du SI. Les informations de l utilisation du SI se focalisent sur les interactions utilisateurs/si. Plusieurs IDS comportementaux utilisent cette source d information pour refléter le comportement des utilisateurs. [11] détermine la fréquence de chaque utilisation de commandes d un utilisateur. Les noms d utilisateurs, le type de commandes utilisées et la date d utilisation constituent les principales propriétés d une commande utilisée. [12] modélise les séquences de commandes systèmes. Chaque commande est définie par des pré et post conditions (nom du fichier, adresse et nom de la machine, port source, etc.). Une fois ce prétraitement effectué, les auteurs génèrent des graphes de séquences de commandes. [13] détermine des anomalies au sein de proxylets (des petits fragments de code installés sur un Open Pluggable Edge Service - OPES) en surveillant les variations de charge de CPU et de mémoire. Les IDS par signature, quant à eux, vont cibler leur analyse, sur la forme et le contenu des requêtes ou commandes utilisées pour manipuler le système. Toujours à la recherche d exploits prédéfinis, ils traquent les requêtes et commandes malformées. Source d observation : Utilisation des fichiers du SI. Les informations sur l utilisation des fichiers du SI, tels que la date d accès, le type d accès (lecture, écriture, ouverture, fermeture, etc.) sont particulièrement utiles pour la protection de données sensibles. Comme précisé dans [14], les actions usuelles d un intrus sont visibles par l observation de la manipulation des fichiers. Un intrus qui réussit à s introduire dans le SI modifiera la plupart du temps des données. [14] définit quatre catégories de signes alarmants (warning signs) : la modification de données ou d attributs, la mise à jour de patterns (modification de la rotation des fichiers de logs ou des fichiers de logs eux même), la modification de l intégrité du contenu et le contenu suspicieux (virus, code exécutable suspect, etc.). Cette source de données est utilisée principalement par les IDS comportementaux.

21 8 La détection d Intrusion Source d observation : Utilisation des applications. Les informations portées par l utilisation de l application donnent des détails sur le type d applications installées sur un composant du SI ainsi qu un ensemble d opérations effectuées sur ces derniers. Les IDS comportementaux aussi bien que les IDS par signatures traitent ce type d information. Des informations telles que le démarrage/l arrêt d une application, les données d entrées/sorties ainsi que les différents modules exécutés sont révélateurs du comportement d une application et utilisés par les IDS comportementaux. [15] ont focalisé leurs travaux sur la modélisation des appels systèmes durant l exécution d une application. En modélisant les appels systèmes, cette approche permet de découvrir des abus de fonctionnement d application (buffer overflow, élévation de privilège). [16] ont modélisé les relations temporelles entre l utilisation de chaque application. Après une phase d apprentissage, les auteurs modélisent les interactions temporelles entre les applications du système observé. Ce haut niveau d abstraction permet de découvrir des séquences d utilisation d applications inhabituelles. L utilisation des applications comme source d information par les IDS par signature est étudiée de la même façon que pour l utilisation du SI, par analyse du contenu et de la forme des commandes et requêtes effectuées sur une application. [17], par exemple, décrit les attaques les plus fréquentes sur les applications web et explique comment détecter ces attaques. Il liste le contenu de requêtes potentiellement malicieuses comme par exemple l utilisation de../../.. permettant à un attaquant de naviguer dans le système de fichiers de la machine ciblée, ou encore l utilisation du caractère (Pipe des systèmes Unix/Linux) permettant à un attaquant d inclure plusieurs commandes dans une seule requête. Source d observation : Violation des politiques de sécurité. Les informations relatives à la violation de politique de sécurité définissent les comportements anormaux comme des violations de politiques de sécurité. [18] définissent des politiques de sécurité spécifiques afin de régulariser l accès aux ressources du SI. Certains points stratégiques tels que l accès à des fichiers système ou l exécution d une commande avec des privilèges inappropriés sont révélateurs de comportements suspicieux. Cette source d information est particulièrement exploitée par les analyses comportementales. Les sources d observation des HIDS actuels sont diverses et permettent l analyse de points spécifiques de nos systèmes. Les HIDS vont focaliser leurs études sur une seule et même propriété d un composant du système, ne prenant pas en compte les interactions entre plusieurs composants au sein du SI. La plupart des sources d observation sont exploitées aussi bien par les HIDS comportementaux que par signature ce qui favorise la détection d attaques connues ou inconnues. b) Données Réseau (NIDS) Les Systèmes de Détection d Intrusion réseau s attachent à observer le flux réseaux et à en déceler des anomalies ou des patterns d attaques prédéfinis. Cette détection porte essentiellement sur l analyse des entêtes des paquets des couches réseau et transport mais également sur le contenu des paquets. La principale différence avec l étude des données système réside dans le fait que les données ne portent pas sur un composant unique du système comme un serveur, mais sur l interaction et les échanges réalisés par plusieurs processus distribués dans le SI. Les

22 Introduction 9 analyses vont porter sur des attributs des paquets transitant dans le SI. Des informations telles que les adresses IP sources et destinations, les ports sources et destinations et le volume de données échangées par type de flux vont servir d indicateurs du comportement du trafic réseau. [19] propose une classification des paquets TCP (Transmission Control Protocol) en activité normale et attaques avérées. Ils utilisent les connexions TCP comme grain de base. Une connexion TCP est identifiée à travers six principaux attributs, le temps de connexion, l adresse IP source/destination, le port source/destination et le statut de la connexion. Un ensemble de règles détermine comment classer chaque paquet en fonction de ces propriétés. Ces règles ont été intégrées à un circuit intégré programmable (Field-Programmable Gate Array FPGA) garantissant des vitesses de traitement élevées (gigabit par seconde). Toutes nouvelles connexions s écartant de ces groupes sont considérées comme anormales. [20] propose une architecture pour la classification des paquets IP. Ils utilisent principalement 5 paramètres de l entête IP : adresse IP source/destination, protocole, port source/destination. Les paquets sont classés grâce à des règles définies au préalable. Ces règles associées les unes aux autres vont permettre de déterminer des séquences paquets/connections nécessaires pour la mise en oeuvre de scénarios d attaques. Ces séquences sont modélisées à l aide d un réseau de Pétri coloré. [21] étudie également le comportement des paquets IP. Cette approche traite le flot de paquets IP comme un signal électrique et va s attacher à le décomposer en différentes fréquences (wavelet). Après une période d apprentissage et avoir réaliser un modèle de fréquences des paquets IP, [21] considère comme une anomalie tout signal de paquet IP ayant des propriétés différentes (de fréquence) du modèle appris. D autres travaux proposent une approche similaire en enrichissant leur détection à l aide des adresses IP source et destination des paquets réseau. L entropie (quantité d information contenue dans une variable) habituelle des adresses IP est calculée et constitue un modèle normal de référence. L entropie permet de connaitre la quantité d information contenue dans un ensemble de données. Plus l ensemble observé possèdera d éléments similaires, plus l entropie sera basse. Dans le cas contraire, plus les informations seront différentes plus l entropie sera élevée. Ces informations permettent de déceler des types d attaques portés par le réseau ; un DDoS (Distributed Denial of Service) produira une entropie des adresses source élevée (des milliers de postes impliqués dans l attaque) et une entropie des adresses destination faible (un seul composant du réseau ciblé). Enfin [22], a permis la mise à disposition de signatures d attaques réseaux, portant sur des critères aussi variés que le contenu du paquet, la forme du paquet ou des séquences de paquets. Ces signatures sont générées dynamiquement pour des systèmes de détection différents. Chaque signature sera stockée dans une base de données et transformée dans le format approprié lorsqu un système de détection réseau souhaitera se mettre à jour. c) IDS/Sondes La collaboration des sondes de détection d intrusion devient une nouvelle évolution des IDS. Des travaux récents utilisent des sondes déployées sur un SI, collectent les alertes provenant de ces sondes afin d identifier des scénarios d attaques. Cette coopération de sondes permet potentiellement de détecter la progression d une attaque sur le système surveillé mais également

23 10 La détection d Intrusion de confirmer une attaque détectée (si plusieurs sondes détectent une même attaque alors sa véracité est renforcée). [23] a exposé l intérêt de réaliser une détection d intrusion à l aide d agents distribués, organisés de façon hiérarchique et collaborant entre eux. Chaque agent assure la détection de patterns d attaques définis ou la remonté d informations spécifiques. La détection de scénarios d attaques sera réalisée par l échange d information entre les agents qui utiliseront leurs propres connaissances (données collectées) ainsi que les connaissances de leur entourage (données reçues par d autres agents) pour déceler un scénario d attaques prédéfini. [24] s appuie également sur des agents plus particulièrement des IDAs (Intrusion Detection Agent). Chaque IDA détecte des attaques réseaux locales utilisant un prétraitement statistique et une classification par réseau de neurones. Ces informations locales sont transmises à un agent plus élevé hiérarchiquement qui permettra de classer et identifier les attaques distribuées sur l ensemble du système Nature de l apprentissage des outils Quelque soit la nature des données observées ou même la méthode de détection (par signature ou comportementale), les IDS utilisent des mécanismes d apprentissage permettant de générer des profils normaux ou des signatures d attaques. [25] propose une catégorisation des IDS suivant deux critères principaux, la nature de la détection et le mode d apprentissage. [25] expose trois classes de natures différentes : détection d anomalies (Anomaly-based), détection par signatures (Signature-based) et détection par signatures automatiquement générées (Signature-inspired). Chacune de ces classes possède des modes d apprentissage différents. Anomaly-based possède deux catégories d apprentissage, un apprentissage automatique (selflearning) et un apprentissage prédéfini (programmed). Signature-based exploite un apprentissage prédéfini (programmed) alors que la catégorie Signature-inspired possède une phase d apprentissage automatique (self-learning). Les auteurs ont défini une nouvelle catégorie d IDS, les Signature-inspired. Cette classe a été crée afin d exprimer un apprentissage automatique réalisé par des IDSs basés signatures. Cette catégorisation d IDS met en avant deux principales caractéristiques qui définissent les systèmes de détection d intrusion ; la nature de la détection (comportementale ou par signatures) et la nature de l apprentissage (automatique, explicite ou plus récemment semi-explicite). Nous avons choisi ce second critère pour présenter les différences entre les systèmes de détection d intrusion car il nous permet d identifier plus clairement les types d attaques détectés par les systèmes. a) L apprentissage Explicite L apprentissage le plus répandu dans les solutions IDS restent l apprentissage explicite. Comme l indique son nom, cet apprentissage nécessite une description complète d un ou plusieurs patterns. Ces patterns (comportement normaux, anormaux ou signatures d attaques) sont recherchés dans les données analysées et permettent de classer ces données comme appartenant ou non aux patterns définis. La réalisation de patterns d attaques ou de signatures d attaques est fréquemment utilisée dans les IDS systèmes (Log Analysis using OSSEC) ou réseaux (Snort). Cette méthode d apprentissage est également utilisée par des analyses comportementales. Récemment de nombreux travaux ont porté sur la détection de scénario d attaques. La majorité de

24 Introduction 11 ces travaux [26, 27, 28, 29, 30, 31], propose une modélisation explicite des scénarios d attaques. Ces approches modélisent des scénarios d attaquant comme étant un ensemble de successions d actions. Ces approches sont qualifiés d apprentissage explicite car les modèles de scénarios d attaques sont décrits explicitement par un expert de sécurité. Ces approches vont ensuite comparer les différentes actions utilisateurs aux scénarios d attaques afin de détecter la présence d activités malicieuses. D autres analyses comportementales réalisent des patterns de comportements normaux. [15], par exemple défini par un automate d état l ensemble des appels système des applications. Ces automates d appels système définissent les comportements normaux des applications. Tout nouvel appel système est ensuite comparé aux patterns de référence, en cas d anomalie le système remonte une alerte. Ces méthodes d apprentissage permettent une recherche rapide d éléments malicieux et offrent de grandes performances d analyse. Ces types d apprentissage sont particulièrement utilisés pour traiter de très grand volume de données, comme dans l analyse de flux réseau par exemple. Mais ils ne permettent pas la détection de nouvelles attaques ou la mise à jour des références normales de comportement. b) L apprentissage Automatique Les mécanismes d apprentissage automatique tentent d apporter des solutions pour générer automatiquement des signatures ou pour suivre l évolution des comportements normaux par la mise à jour des modèles de référence. L apprentissage automatique est le terrain de prédilection des IDS comportementaux. Cet apprentissage peut être divisé en deux phases. Une première permet de créer une référence normale ou anormale à partir d un jeu de données. Les approches par modèle checking [32, 27] sont capables de modéliser tous les états possibles du système et d en détecter les variations normales ou anormales. Ces approches nécessitent une connaissance exacte de chaque configuration et chaque politique des composants du Système d Information. [33] utilise un ensemble de données d apprentissage afin d apprendre automatiquement des scénarios d attaques. [34] utilise les traces d audit des programmes afin d extraire des caractéristiques décrivant chaque connexion réseau ou chaque session utilisateur. Après l application d algorithme de traitement datamining, des règles définissant le comportement des utilisateurs normaux et des attaquants sont alors générées. L ensemble de ces règles peuvent ensuite être utilisé pour la détection d intrusion par signature ou comportementale. c) L apprentissage Semi-Explicite Un nouveau type d apprentissage a été défini dans les années 2002 [35, 12] avec l apparition d un apprentissage semi-explicite pour la génération de scénarios d attaques. Grâce à la modélisation des données d entrée à l aide de prédicats (causes et conséquences d un évènement), des scénarios d attaques sont automatiquement construits par l assemblage de ces modèles unitaires. La notion semi-explicite est justifiée par la non modélisation des scénarios d attaques (Automatique) mais par la description de chaque cause et conséquence des évènements du SI (Explicite).

25 12 Vers une Vision Globale du Système d Information 1.3 Vers une Vision Globale du Système d Information La mise en oeuvre d outils de protection et détection sur l ensemble du SI permet de sécuriser des points stratégiques. Malheureusement, les scénarios d attaques deviennent de plus en plus sophistiqués et tentent de s insinuer dans les comportements normaux d utilisateurs. Face à cette nouvelle menace grandissante, la détection et sécurisation de points spécifiques deviennent insuffisantes pour détecter des attaques coordonnées ou des sessions d utilisateurs corrompues. De plus en plus de travaux récents tentent d apporter des réponses à ces nouvelles menaces en proposant des modèles de scénarios d attaques. Cette analyse globale du SI est réalisée à partir d une multitude d équipements de sécurité déployés. La gestion de l ensemble de ces données devient également un enjeu majeur pour la surveillance globale du SI Les enjeux des nouvelles menaces La cybercriminalité a considérablement évoluée depuis l explosion d Internet et de l informatique. Les modes opératoires ont changé, les communautés de pirates se sont structurées et l ensemble des réseaux informatiques mondiaux doit faire face à une véritable armée d attaquants. Les attaques distribuées sont omniprésentes sur Internet et présentent des enjeux politiques et économiques évidents. Des armées de bots ou zombies investissent les réseaux d entreprises afin de détruire des serveurs exposés tels que les serveurs Web ou encore de permettre une diversion facilitant l insertion des pirates dans les systèmes. Ces attaques distribuées ne sont actuellement détectées que par leur effet direct (arrêt d un d un serveur, inondation de requètes HTML). L absence de collecte d information sur l ensemble des systèmes ne permet pas la découverte de ce genre de scénarios d attaques avant leurs effets destructeurs. Le manque de coordination et coopération des éléments de contrôle des SI ne permet pas la détection de scénarios d attaques complexes. Les communautés d attaquants tissent de véritables réseaux de connaissances leur permettant d échanger rapidement leur expérience ainsi que des informations sur les systèmes attaqués. Le contournement des mécanismes de sécurité est rapidement connu de ces communautés qui arrivent à se faufiler à l intérieur des systèmes. Les techniques d évasion des mécanismes de sécurité consistent à rendre inopérant un mécanisme de contrôle en le saturant d information ou en lui transmettant de fausses informations. Une fois le mécanisme de contrôle bloqué, les attaquants agissent en tout anonymat dans les systèmes. Ces techniques d évasion sont facilitées par l émergence continuelle de vulnérabilités. Ces vulnérabilités continuent d apparaitre dans l ensemble des composants du SI (organisationnelle, logicielle). Ces vulnérabilités présentent de véritables portes dérobées pour des attaquants. Ces attaquants infiltrent les systèmes et s insinuent dans les comportements d utilisateurs autorisés du SI. Les communautés d attaquants ne représentent pas la seule menace pour les SI. Des menaces beaucoup plus délicates à traiter et à détecter peuvent émerger à l intérieur même des SI. La menace intérieur ou encore insider thread provoquée par un utilisateur légitime du système contourne la plupart des mécanismes de sécurité existants. Seule l analyse des comportements des utilisateurs du SI permet de déceler des traces de comportements suspects.

26 Introduction 13 L implication légale d une entreprise ou d un organisme dans une attaque distribuée ou dans l utilisation frauduleuse de leur système d information est délicate à définir. Aussi les organismes gouvernementaux ont pris les devants en imposant une collecte d information sur les SI. Ces dispositions légales imposent la collecte d information relative aux accès et à l utilisation des ressources du SI. Ces informations peuvent servir de preuves en cas de litiges ou de fraudes constatées. La science de la forensic se développe naturellement autour de cette évolution juridique en tentant de trouver des causes à des erreurs ou attaques constatées. Ces analyses de preuves s opèrent sur l ensemble des d informations disponibles logicielles, humaines ou matérielles. Face à la présence de ces nouvelles menaces et des nouvelles dispositions, la coopération des sondes de management, sécurité et système devient une évolution logique des mécanismes de sécurité. Cette coopération va permettre la mise en place de nouveaux systèmes de contrôle visant à étudier l ensemble des actions opérées sur le système ainsi que les états du système dans un contexte de vision globale Problématiques liées à la vision globale La vision globale présente deux problématiques majeures ; l une liée à la collecte et au traitement de l ensemble des données du système, l autre liée à la détection de scénarios d attaques. Afin d obtenir un maximum d information sur le système, la collecte de données portant sur différents composants est indispensable. Cette collecte nécessite la mise en place de systèmes spécifiques permettant soit à un processus de récupérer des informations sur les composants/sondes du réseau (recherche d information), soit des processus permettant aux composants/sondes de transférer les informations entre eux ou à un système central. Plusieurs types d architecture ont vu le jour afin de répondre à cette première difficulté. Les solutions commerciales proposent pour la plupart des solutions centralisées déléguant le traitement de l information à une seule et même entité. Les principales divergences entre ces solutions portent sur le mode de collecte des informations. Certaines approches comme [30, 36] favorisent la recherche d information sur le SI en interrogeant ou testant les composants du SI. D autres, quant à elles, récupèrent les données fournies par des sondes déployées sur le SI. Plus récemment certaines architectures liées à la mobilité proposent des architectures collaboratives permettant à la fois l échange d information entre plusieurs composants du SI mais également la répartition du traitement de l information. Quelque soit le mode de collecte d information, la gestion de la temporalité est une difficulté incontournable à la vision globale. [37] précise l importance de l ordonnancement temporelle. Cet ordonnancement, essentiel pour la détection de mouvements d utilisateurs ou de processus système, est nécessaire à la détermination de la direction d un mouvement dans le système étudié ainsi qu a la détermination d une succession d évènements. [38] et [39] décrivent les difficultés de traitements d information de données collectées sur des sondes désynchronisées et les problèmes liés aux délais de propagation. Malgré des efforts constant de synchronisation d horloge de différents composants, des dérives internes à chaque horloge restent imprévisibles. Les délais de propagation des évènements ou de leur collecte influent directement sur l ordre d arrivé et de traitement de ces derniers.

27 14 Vers une Vision Globale du Système d Information Chaque sonde ou composant déployé dans le SI dispose d une syntaxe et d une sémantique qui lui est propre pour décrire les évènements constatés ou observés. Chaque composant va décrire les évènements en lui associant des informations sur la nature de l évènement (nom de l évènement) et des informations complémentaires permettant d identifier le contexte de cet évènement. L organisation de l ensemble de ces informations (Syntaxe) est dans la plupart des cas dépendant du type de composants remontant l évènements (réseau, sécurité, système). De plus, chaque constructeur possède sa propre sémantique permettant de décrire les évènements produits (Windows wmi, Linux Syslog, Cisco netflow). Avec une absence de langage commun, le traitement d évènements hétérogènes est impossible. La collecte de l ensemble des évènements provenant du SI va produire un volume de données très important pouvant atteindre plus de mille évènements par seconde. Ce volume engendre des problèmes de traitement de l information. La réalisation d analyse de patterns d attaques ou la modélisation de comportements normaux est rendu très difficile et engendre des temps de traitement long. La multiplication des sondes sur un SI peut engendrer de la redondance d information et venir alourdir le volume de données déjà élevé. Certains évènements peuvent être perçus par deux sondes ou composants différents et remontés par ces derniers. La section suivante va définir le processus actuel mis en place pour répondre à ces problématiques Architectures et processus de traitement appliqués à la vision globale Les infrastructures de supervision des Systèmes d Information utilisent les informations provenant de divers composants du SI. Face aux problématiques liées à la vision globale 1.3.2, de multiples processus sont à mettre en oeuvre afin de garantir le traitement des diverses informations. [40] explique la nécessité de réduire la quantité d information à traiter sachant que près de 90% des évènements reçus sont des fausses alertes (ou faux positifs). Les principaux objectifs de ces processus sont de réduire la quantité de faux positifs, d étudier la cause de ces fausses alertes, de créer une vision de haut niveau des attaques potentielles survenant sur le système et enfin de fournir les informations nécessaires pour contrer les attaques en analysant les relations entre les différents évènements analysés. Nous distinguons quatre types de processus impliqués dans l analyse globale d information du SI ; la collecte d information, la fusion des données, l aggrégation des informations et la corrélation des informations collectées. a) Collecte d information Le premier processus impliqué dans l analyse globale des informations du SI est la collecte d information. Ce processus est principalement mis en oeuvre par le biais de l architecture adoptée. Deux grandes familles d architecture peuvent être mises en avant ; les architectures centralisées et les architectures distribuées. La plupart des systèmes d analyses utilisent une architecture centralisée. Dans ce type d architecture, l ensemble des informations issues du système observé est accumulé sur un seul et même composant. C est ce composant unique qui traitera les informations du système. Deux principaux modes de collecte sont utilisés au sein d une telle architecture, la recherche d information ou la collecte d information.

28 Introduction 15 La recherche d information est principalement utilisée par les outils de détection de vulnérabilités (Nessus, Qualys). Ces outils vont vérifier chaque composant du système à la recherche de failles de sécurité. Un serveur central, qui possède une base de données contenant des vulnérabilités connues, va tenter de découvrir des vulnérabilités sur les composants ciblés en faisant réagir ces derniers. La détection de vulnérabilités peut être obtenue aussi bien par des requêtes récoltant des versions de services que par des tentatives d exploits (DOS, bufferoverflow). Une fois les tests effectués, le serveur central analyse les réponses reçues et détermine si le composant ciblé possède ou non des vulnérabilités. La collecte d informations, pour sa part, ne fait pas réagir le système mais récupère les données de management ou de sécurité fournies par les composants eux-même (syslog, trap snmp). Chaque système possède des informations de management et/ou de fonctionnement et les stocke dans des fichiers d audit spécifiques. Certains composants peuvent rediriger les informations d audit vers des machines distantes (syslog). Dans la plupart des cas, les systèmes d analyse globale des SI disposent d agents distribués sur les composants observés qui remontent au serveur de traitement central, en temps réel ou non, les informations d audit (figure 1.5). Fig. 1.5 Architecture Centralisée Le traitement de l ensemble des informations par un serveur central, n est pas toujours possible notamment dans des contextes de collaboration entre plusieurs organismes ou pays, ou plus simplement dans un contexte de réseau mobile. [41] présente l intérêt de répartir le traitement d information lors de l apparition de vers dans différents SI. Dans cet article, les auteurs répartissent la charge de traitement au travers différents IDSs. Cette architecture collaborative (appelée Collaborative Intrusion Detection System CIDS) va permettre un échange d information entre les différents Systèmes de Détection d Intrusion et ainsi réduire le risque de saturation des IDSs les plus faibles (exposition importante, ressources limitées). Ici les informations sont collectées par chaque IDS déployé (comparable à des agents distribués) et réparti suivant diverses algorithmes. Ainsi les informations sont d abord triées en fonction de leur contenu et signification et renvoyées à l entité de traitement appropriée 1.6. Le traitement d informations réparties favorise la résilience 1 du système globale de détection ainsi que la délégation d analyse 1 La résilience d un système peut être définie comme la continuité du système et sa capacité à endurer les changements et perturbations tout en conservant le même niveau de disponibilité, d intégrité et de confidentialité.

29 16 Vers une Vision Globale du Système d Information aux entités les plus appropriées. Fig. 1.6 Architecture Distribuée b) Fusion [40] spécifie trois processus de traitement impliqués dans la corrélation de données ; une phase de prétraitement, une phase d analyse des alarmes et enfin une phase de corrélation des alarmes. La phase de pré traitement décrite dans cet article est réalisée afin d homogénéiser les données et de les traduire dans un langage ou forme spécifique. Cette phase primordiale pour la réalisation de traitement des données, va prétraiter les données issues de la collecte. Nous avons rebaptisé ce prétraitement en processus de fusion. En effet l homogénéisation des données (sémantique et syntaxe) permet non seulement de garantir des données uniformes pour les autres processus de traitement mais également de qualifier les évènements de la même façon. En standardisant l ensemble des évènements collectés, il est possible d éliminer les doublons d information représentant le même évènement (même sémantique et même attributs) plusieurs fois. Ces données vont être regroupées, fusionnées en un seul et même évènement. Ce mécanisme de fusion va permettre de réduire les informations collectées et de supprimer des informations inutiles. c) Agrégation Le second processus de traitement de l information, décrit comme analyse des alarmes par [40], va permettre de regrouper les évènements reçus sur des critères particuliers prédéfinis (règle d Aggrégation exemple : même adresse IP source) ou calculés (recherche des paramètres importants par datamining). Le rôle de ce processus est essentiellement de réduire l information reçue afin de pourvoir effectuer des calculs plus complexes. Ce processus de traitement va sélectionner un groupe d informations importantes à conserver pour la suite du traitement. Le processus d agrégation est un processus à perte d information. Le choix des règles d agrégation regroupant les évènements et conservant des attributs particuliers est déterminant pour la suite du traitement. C est durant cette phase que seront déterminés les champs sur lesquels l analyse sera faite.

30 Introduction 17 d) Corrélation Le processus de corrélation représente le dernier maillon de la chaine d analyse globale d information. C est ce processus, en utilisant des algorithmes et des méthodes de traitement particuliers, qui permettra la détection d erreurs, de vulnérabilités, de scénarios d attaques ou d anomalies dans les données traitées. La corrélation dispose d informations homogènes d une volumétrie réduite et également de données de configuration. Ces données de configuration vont permettre de déterminer les patterns à détecter ou les références standards à ne pas dépasser. Les informations de configuration peuvent être déterminées explicitement, automatiquement, semi-explicitement (section 1.2.2) et définir des patterns à détecter, des modèles de référence, des informations relatives au contexte d étude (topologie du système observé, actifs de l entreprise, composants sensibles). Ces quatre principaux processus (collecte, fusion, agrégation, corrélation) sont indispensables à l analyse globale des information du SI. Les informations provenant du moteur de détection servent à la mise en oeuvre de contre-mesures ou de plan de réorganisation de politiques de sécurité ou de management. Cette réaction est, dans la plupart des cas, déclenchée par un analyste de sécurité et mis en oeuvre manuellement. La gestion de réaction sur l ensemble du système d information nécessite la coordination de plusieurs entités et corps de métier rendant délicate la mise en oeuvre de réponse automatique. 1.4 Sujet détaillé et contributions L objectif de nos travaux a été de permettre une analyse comportementale de l ensemble du SI afin de détecter des comportements malicieux, indices d intrusion. La détection d intrusion comportementale propose une approche complémentaire aux outils existants observant la totalité du système à la recherche de patterns de scénarios d attaques inconnus. Outre la découverte de scénarios d attaques inconnus notre approche permet également de détecter des erreurs ou incidents modifiant le comportement usuel du système et des utilisateurs. Nous avons choisi de modéliser les comportements des utilisateurs du système par le biais de leurs interactions avec le système. En observant ces interactions, il nous est possible de bâtir un profil statistique d interactions utilisateurs-système garant des comportements normaux propres à chaque infrastructure et compagnie. Conscients du caractère dynamique des utilisateurs et des systèmes d information, chaque déviance de comportant sera étudiée et différentiée en évolution normale du système ou activité intrusive. Enfin notre modèle comportemental permet non seulement la détection de comportements anormaux mais également la création de règles de corrélation comportementales permettant d identifier des scénarios d usage du système et de restituer les règles de corrélation explicites nécessaires à leur détection. La figure 1.7 décrit l ensemble des processus mis en oeuvre pour la réalisation de détection d intusion comportementale et la génération de règles de corrélation comportementales. Le chapitre 2 va présenter les différentes approches et études effectuées sur la vision globale des Systèmes d Information. Nous présenterons dans le chapitre 3 nos processus de collecte et de fusion d information indispensables à tout traitement d information. L étude des différentes démarches utilisateurs sur le SI nous renseignera sur le type d information à traiter (sélection

31 18 Sujet détaillé et contributions Fig. 1.7 Processus pour la détection comportementale sur la vision globale

32 Introduction 19 des évènements) et sera développée dans le chapitre 4. C est dans le chapitre 5 que sera présentée notre méthode de modélisation des comportements d interactions utilisateurs-système (corrélation). Le chapitre 6 présentera une méthode de génération de règles explicites de corrélation de scénarios d usage en utilisant notre modèle comportementale. Enfin, nous présenteront nos expérimentations et nos résultats portant sur notre méthode de détection d intrusion comportementale dans le chapitre 7.

33 20 Sujet détaillé et contributions

34 2 État de l Art 2.1 Introduction La plupart des travaux récents sur la détection d intrusion s intéresse particulièrement à l analyse globale du système. Les nouvelles problématiques posées par l évolution des systèmes et leur utilisation ont poussé la communauté scientifique ainsi que les éditeurs de solutions de sécurité à trouver des solutions permettant de répondre à ces nouvelles attentes (section 1.3.2). Le contrôle de l ensemble du Système d Information est devenu un enjeu prioritaire pour la plupart des grands groupes. Cette nécessité de contrôle a entrainé la prolifération des sources d information à observer. Conscient de cette nouvelle attente et problématique, de nombreux travaux de recherche ont vu le jour, mettant en oeuvre des architectures et des algorithmes d analyses toujours plus innovants permettant de répondre aux nouvelles problématiques complexes de distribution des données à observer (section 2.2 et 2.3). Les éditeurs de solutions de sécurité se sont également appuyés sur ces architectures et proposent des outils de management des évènements de sécurité (SIM Security Information Management) afin de gérer et analyser cette masse de données hétérogènes. 2.2 Architectures appliquées à la vision globale Face à la multiplication des sondes de sécurité et de management dans l ensemble des SI, des solutions d architectures distribuées ont vu le jour pour recueillir et traiter l ensemble de ces informations. 21

35 22 Architectures appliquées à la vision globale La notion d architecture distribuée ou plus précisément de DIDS (Distributed Intusion Detection System) est apparue en 1989 avec l analyse de données sur plusieurs composants du SI (voir section 1.2). Cette première analyse d information distribuée ne possédait pas d architecture à part entière mais collectait simplement les données de journaux d audit présents sur des machines du SI. L observation globale des SI actuels rend de plus en plus complexe la collecte et l analyse des données distribuées. La quasi totalité des approches analysant des données distribuées dans le système d information possède une architecture basée sur des agents (Agent-Based). Cette architecture est majoritairement reprise dans les projets de recherche ainsi que dans diverses solutions commerciales (Arcsight, Netforensic, Intellitactics, Exaprotect). Un agent est une application autonome avec des objectifs prédéfinis [42]. Ces objectifs peuvent être divers : surveiller un environnement, mettre en oeuvre des contre-mesures ou des actions spécifiques. Les agents peuvent également détecter des évènements malicieux et prendre des décisions face à des situations déterminées. L autonomie des agents varie en fonction du type d architecture mise en place. Dans le cadre d architectures collaboratives les agents sont qualifiés d agents intelligents possédant un mécanisme de décision propre. Les agents des architectures distribuées centralisées possèdent un fonctionnement prédéfini guidé par un module de décision hiérarchiquement plus élevé Architectures distribuées Centralisées Les architectures centralisées sont apparues naturellement dans la mise en place de récupération d informations. Dans les premiers temps, les agents utilisés dans ces architectures ont principalement servi à collecter les données et à les retransmettre à une entité centrale de traitement. Ces solutions prenaient en compte, pour la plupart, des données de même type (journaux d audit) et se contentaient de retransmettre l information. Ces agents sont devenus de plus en plus spécialisés, notamment avec l arrivée des Systèmes de Détection d Intrusion. Les agents se sont vu attribuer des fonctionnalités supplémentaires telles que la détection de signatures d attaques ou d anomalies comportementales et l agrégation d informations. Les premières approches ont collecté les informations issues des sondes IDS déployées dans le système (voir la section c)). [24] a mis en oeuvre une architecture hiérarchique centralisée pour la détection d attaques réseaux utilisant un prétraitement statistique et une classification des évènements par réseau de neurones. L architecture proposée dans cette approche repose sur plusieurs couches de traitement appelées tiers (figure a). Chaque tiers contient plusieurs agents de détection (Intrusion Detection Agents IDAs) qui effectueront des analyses différentes en fonction de leur position hiérarchique. Les agents du tiers 1 ont comme activité principale de surveiller et remonter des informations des différents serveurs et passerelles surveillés. Ces agents génèrent périodiquement des rapports qu ils transmettent aux agents du tiers 2. Les agents du tiers 2 définissent le statut de la section du réseau surveillé et génèrent également des rapports transmis aux agents hiérarchiquement plus élevés. Enfin les agents du tiers 3 collectent les données des agents du tiers 1 disposés sur les équipements de concentration réseau (firewall, routeur) et les données des agents du

36 État de l Art 23 tiers 2. Grâce à l ensemble des données collectées, ces agents effectuent une détection globale d anomalies. FIG : (a) Architecture hiérarchique HIDE FIG : (b) Intrusion Detection Agent (IDA) Tab. 2.1 Architecture HIDE à base d agents Chaque agent (IDA) possède une structure similaire composée de plusieurs fonctionnalités (figure b) : Le sondage : cette fonctionnalité collecte les informations sur le trafic réseau d une machine ou d une section réseau. Le prétraitement des évènements : les informations et les rapports de statuts réseaux collectés sont convertis dans un format spécifique pour le traitement statistique. Le traitement statistique : cette fonctionnalité maintient un modèle de l activité réseau habituelle et compare les informations issues du prétraitement des évènements au modèle de référence ; cette fonctionnalité va également générer des vecteurs de stimuli pour la classification. La classification par réseau de neurones : le réseau de neurones va analyser les stimuli reçus et décider si le trafic réseau est considéré comme normal ou non. Le post-traitement : cette fonctionnalité génère des rapports transmis au tiers de plus haut niveau. Le traitement statistique des données se base sur un algorithme statistique inspiré du test de χ 2. Ce test permet de mesurer les similarités entre les profils courts terme et longs terme. Partant du postula que les applications temps réelles ne suivent pas nécessairement une distribution statistique de χ 2, les auteurs ont construit empiriquement la distribution statistique des données traitées et la mettent à jour régulièrement. Afin de garder les propriétés du test de χ 2 (similarités court et long terme), les auteurs ont mis en oeuvre un modèle leur permettant d analyser le trafic suivant différentes fenêtres temporelles. Chaque nouvel évènement sera d abord stocké dans un premier buffer représentant une fenêtre de temps (première couche) et comparé au modèle statistique correspondant à cette fenêtre de temps. Une fois le buffer plein, l évènement sera transmis dans un second buffer et comparé à un nouveau modèle statistique. Ce processus se répètera jusqu à ce que le nombre de fenêtres temporelles soit atteint.

37 24 Architectures appliquées à la vision globale Plusieurs types de réseaux de neurones ont été utilisés pour classer le trafic réseau. Ces derniers, préalablement entrainés à détecter différents types de scénarios, vont évaluer les données issues du traitement statistique et classer les évènements réseaux en activité normale ou anormale. La structure hiérarchique centralisée de cette approche permet de détecter des anomalies sur l ensemble des sections réseaux et sur l ensemble du réseau. Grâce à l analyse successive des données par les différents IDAs (tiers 1, tiers 2 et tiers 3), il est possible de détecter des attaques réseaux distribuées. Cette approche permet une détection efficace en cascade des anomalies à différents niveaux (tiers 1, tiers 2 et tiers 3) permettant de suivre l évolution d attaques réseaux. L entrainement des réseaux de neurones par la réalisation d attaques prédéfinies rend le paramétrage des réseaux de neurones propre à l infrastructure étudiée et non réutilisable. Cette approche propose néanmoins une méthode originale pour la détection des attaques connues rejouables. Une architecture similaire a été proposée dans [43] qui permet la construction de graphes d activités révélant une structure causale de l activité réseau. Cette approche utilise une architecture hiérarchique pour la surveillance de réseaux larges. Cette approche focalise son étude sur la détection de la propagation de vers dans un réseau et propose une architecture hiérarchique centralisée composée de quatre modules pour la construction des graphes d activités. Chaque section du réseau du Système d Information observé sera composé d un module de management, d un module générateur de graphe. De plus chaque poste ou serveur d une section réseau contiendra un module de contrôle et un module source de données (figure 2.1). Le module de contrôle va démarrer, arrêter et contrôler les modules présents sur la machine surveillée. Les modules de sources de données ont a leur charge la collecte d information sur l activité système (HIDS) et réseau (Sniffer). Les activités des systèmes surveillés sont retranscrites sous forme de noeuds ou de liens au module générateur de graphe. Ce dernier construit des graphes d activités à partir des données reçues (noeuds et liens) et propage un résumé de graphes d activités au module de construction de graphe hiérarchiquement supérieur. Enfin le module de management va contrôler et gérer la hiérarchie de l architecture et de la topologie des modules distribués. La figure 2.1 présente une architecture comprenant deux sections réseaux composées respectivement de une et trois machines. Les graphes construits correspondent à des noeuds connectés par des liens orientés. Chaque graphe va représenter un ensemble connecté de causes d évènements réseaux. Plusieurs types d activités malicieuses peuvent être détectés par GrIDS (Graph-based Intrusion Detection System), chaque type d activités malicieuses étant identifié par un graphe. Les règles de construction des graphes sont spécifiées au sein de fichiers de configuration (composition de règles incluant par exemple des pré-conditions, des conditions d initialisation et des règles de combinaisons de graphe). Les modules générateurs de graphes vont contrôler l activité de la section réseau à leur charge. La superposition hiérarchique de modules générateurs de graphes permet à cette architecture de réaliser une observation de l activité globale du réseau (à l aide de l ensemble des résumés d activité collectés). Cette méthode permet l observation globale et locale des graphes d activités des différentes

38 État de l Art 25 Fig. 2.1 Exemple d architecture GrIDS (Graph-based Intrusion Detection System) sections réseaux. Cependant, la mise en place de cette approche nécessite une forte expertise pour la réalisation des fichiers de configuration nécessaires à la construction des graphes d activités spécifiques. La découverte d anomalies à l aide d agents est également abordée dans des domaines connexes à la détection d intrusion. [44] propose une architecture hiérarchique centralisée pour la détection d anomalies sur les moteurs. L utilisation d agents distribués par des applications est de plus en plus répandue dans l industrie de l énergie, dans le cas présent ces agents permettent de mesurer différents paramètres tels que la température, les vibrations, la pression etc.. L architecture d analyse se décompose en trois couches, une couche d agents responsables de la conversion des logs bruts en format standardisé (Data Abstraction Agents), une couche d agents en charge de l analyse des paramètres individuels (Data Processing Agents) et une couche d agents pour le traitement global des anomalies et la présentation des données (Analysis and Présentation Agents) (figure 2.2). Une autre couche d agents est présente au sein de cette architecture (Administration Agents) et permet la configuration de chaque agent à l aide des outils JADE (Java Agent Development framework). Les agents responsables de la conversion des données brutes observent chacun un seul paramètre. Ces agents (Data Abstraction Agents) ont à leur charge plusieurs tâches : collecter des informations d une ou plusieurs sources, avertir l utilisateur ou d autres agents que les données sont disponibles, formater les données et fournir,à la demande, des données à d autres agents. Ce sont les agents d analyse des paramètres (Data Processing Agents) qui vont effectuer des calculs sur les données collectées. La nature des calculs dépend des paramètres observés (moyenne, taux, minimum, maximum). Chacun de ces calculs s effectue dans une fenêtre glissante prédéterminée. Les agents de traitement global et de présentation (Analysis and Presentation Agents) vont respectivement détecter des anomalies au sein des indicateurs fournis par les agents d analyse et afficher l ensemble des mesures. La détection d anomalies se déroule en deux phases, une phase d apprentissage et une phase d exploitation. La phase d apprentissage consiste à déterminer une normalité de chaque mesure

39 26 Architectures appliquées à la vision globale Fig. 2.2 Architecture du moteur de détection d anomalies qui sera stockée par l agent de traitement global. Durant la phase d exploitation, les données reçues sont comparées à leur référence. Les architectures hiérarchiques centralisées permettent d avoir un point de vue global sur données présentes dans le système observé. Simples et robustes, ces architectures sont cependant limitées lors de la mise en place d analyse de systèmes larges. Le traitement des données par un point central peut en effet entrainer des problèmes de puissance de traitement et également un point unique de rupture du système de surveillance (si le serveur de traitement s arrête, la détection n est plus assurée). Les architectures collaboratives tentent de répondre à ces contraintes Architecture Distribuée Collaborative Les traitements d information hiérarchiques centralisés (clients-serveur) sont décrites dans certaines approches comme limités et restrictifs. [45] précise que dans les architectures clientsserveur, les communications doivent être établies entre le client et le serveur. Ce type d architecture rencontre de nombreux problèmes lorsque l infrastructure est largement distribuée notamment lorsque les connections réseaux sont lentes (de faible qualité) mais également lorsque de nombreuses maintenances sont effectuées sur le parc (changement de machines, mise à jour de services, applications). Dans les systèmes possédant un seul serveur de traitement, des contraintes de passage à l échelle apparaissent rapidement pour l étude de systèmes de grande taille. Malgré la mise en place de serveurs multiples de traitements, le passage à l échelle reste délicat. Dans cette configuration chaque client devra maintenir des connexions avec plusieurs serveurs pouvant entrainer des pertes de performances de traitement. La mise en place de traitement des données distribuées à l aide d architectures collaboratives a émergé pour pallier à ces problématiques. [42] et [23] ont défini des caractéristiques indispensables pour des agents intelligents impliqués dans une architecture collaborative de détection d intrusion : La distribution : afin de déceler les comportements anormaux ou malicieux d attaquant

40 État de l Art 27 sur le système, il est très important de distribuer les fonctions de détection à plusieurs agents qui surveillent différents points du réseau. L autonomie : un agent doit être capable d effectuer des tâches par lui-même. Des échanges excessifs d information entre les agents distribués peuvent congestionner le réseau. L adaptabilité / la délégation : les réseaux et systèmes d information évoluent sans cesse. Afin de suivre cette dynamique, il est nécessaire de pourvoir modifier les fonctions de détection des agents pour les adapter aux changements du système surveillé. Le principe de délégation permet cette flexibilité en transmettant aux agents autonomes des tâches spécifiques à effectuer. La communication et coopération : l observation d un point unique du Système d Information ne permet pas la détection d attaques complexes. La vue restreinte de chaque agent ne permet pas de détecter ces types d attaques. Les différents agents doivent échanger leur analyse et coopérer afin de détecter efficacement les scénarios d attaques complexes. La réactivité : pour réduire les conséquences des attaques, les agents doivent réagir rapidement afin d enrayer les effets des attaques. L intelligence : un agent doit pouvoir surveiller un système, interpréter les données collectées et prendre des décisions appropriées. [23] propose une architecture collaborative permettant la détection d intrusion sur un Système d Information. Les auteurs de cette approche ont décliné les rôles des différents agents suivant deux couches de traitement (voir figure 2.3) ; une couche de management en charge de la sécurité globale du SI et une couche locale en charge de la sécurité locale d un domaine. La couche locale est composée d agents locaux responsables de la surveillance de composants spécifiques. Les agents locaux sont différentiés suivant le type d information supervisé. Il existe trois classes d agents locaux : Les agents surveillant local extranet englobent les fonctions de surveillance des informations externes au réseau local (surveillance du trafic extérieur). Les agents surveillant local intranet assurent la surveillance interne du réseau local (surveillance du réseau interne). Les agents surveillant local interne possèdent les fonctions de surveillance locale (surveillance de composants internes spécifiques). La seconde couche de management est constituée d agents possédant trois rôles différents chargés de contrôler les informations collectées et d effectuer une analyse globale du système. Les agents de management intranet contrôlent plusieurs agents locaux et collectent les informations pertinentes sur ces derniers. Les agents de management extranet collectent des jeux de données présents sur les agents de management intranet et effectuer une analyse globale des informations pour détecter d éventuelles attaques. Ces agents s assurent également de la véracité des informations recueillies et peuvent demander d autres traitements si les informations sont incomplètes. Les agents de management des politiques de sécurité gèrent les politiques de sécurité à appliquer sur le système surveillé (politique de surveillance). Ils font office d interface avec l analyste de sécurité. La couche de management va interagir avec la couche locale en : spécifiant les objectifs à atteindre par l envoi de messages (dérivés des politiques de sécurité

41 28 Architectures appliquées à la vision globale Fig. 2.3 Architecture de détection coopérative hiérarchique spécifiées dans la couche gestionnaire), déléguant les fonctions de surveillance spécifiques, recevant des rapports de résultat d analyse. La communication entre ces deux couches permet la détection d attaques globales en corrélant les différentes analyses collectées. Les agents d un même niveau vont également échanger des informations (connaissances et analyses) afin de détecter des activités intrusives de manière coopérative. Chaque agent possède une fonction de délibération lui permettant de raisonner et d extrapoler en se basant sur ses aptitudes mentales (croyances, suspicions, buts et intentions), ses connaissances (celles de ces voisins) et son expérience. Le principe de coopération réside principalement dans la définition des croyances d un agent. Trois types de croyances sont possédées par un agent : Les croyances personnelles qui expriment la connaissance de l agent sur son propre état. Les croyances relationnelles qui expriment ce que l agent connait sur les autres agents avec qui il communique. Les croyances environnementales qui définissent les croyances locales de l agent et celles des autres agents sur l état de sécurité du réseau. Pour assurer la détection d intrusion, chaque agent possède une description des schémas d attaques (signatures d attaques) à détecter et une liste d évènements collectés sur le réseau ou le composant surveillé. La fonction de délibération de chaque agent va ainsi utiliser les croyances sur les scénarios détectés localement et par les agents voisins afin de les comparer aux schémas d attaques à détecter. L architecture spécifique développée dans [23] met en oeuvre une détection d intrusion multiniveaux, permettant à la fois la détection des scénarios d attaques locales et la détection d attaques distribuées globales. Cependant, avec une forte interaction entre les agents de la même couche (échange de croyances) et entre les couches (envoi de rapports d analyses), le volume des échanges des informations peut entrainer des pertes de performances réseaux et engorger certains noeuds sensibles d observation (NIDS par exemple). Le type de détection proposé permet de détecter des scénarios d attaques locaux et globaux par le biais d un descriptif des séquences d évènements à détecter (forte expertise nécessaire). [46] utilise également la coopération d agents distribués afin de détecter les activités de machines détournées par un attaquant (présence de zombies par exemple). Les méthodes classiques de détection d anomalies comportementales présentent de forts taux de fausses alertes

42 État de l Art 29 (faux positifs). [46] propose de réduire ce taux en utilisant un mécanisme de confiance et de réputation afin d affiner la qualité de la détection de chaque agent. L architecture de chaque agent utilisé est divisée en trois couches : une couche d acquisition du trafic réseau : cette couche permet la collecte du trafic réseau, le pré-traitement des données et la distribution des informations aux couches supérieures. Cette couche utilise uniquement les informations de flux contenues dans l entête des paquets. [46] utilise une version accélérée des sondes NetFlow (FlowMon) pour collecter les données. Les sondes déployées peuvent être reconfigurées afin de collecter de nouvelles informations. Une couche de détection coopérative d attaques : cette couche permet de détecter des attaques réseaux et de les considérer uniquement si la confiance calculée est suffisamment haute. Une couche de visualisation : cette couche composée d un agent visio assure la présentation des données. Lorsque des comportements réseaux suspicieux sont détectés, des rapports sont transmis à la couche de visualisation qui récupère les données correspondantes à ces anomalies et les affiche. La couche de détection coopérative d attaques est composée d un mécanisme de détection d anomalies et utilise des modèles de confiance. Le mécanisme de détection d anomalies de chaque agent appartient à l une des méthodes suivantes : MINDS agents qui permet l étude d informations provenant des flux réseaux machines ou inter-machines et qui détecte les divergences entre le trafic passé et le trafic courant. Xu agents qui analyse le trafic des machines individuellement en se basant sur des entropies et des règles. Lakhina Entropy qui construit des modèles afin de prédire l entropie des adresses IP du trafic par machines, Ainsi que Lakhina volume agent qui utilise une méthode similaire s appliquant aux volumes de trafic. Chaque agent va recevoir trois types de données d entrées provenant de la couche d acquisition ; une entrée relative aux détections d anomalies, une à la mise à jour de la confiance et une entrée pour la conclusion collective de confiance. Durant la phase de détection, chaque agent va utiliser son mécanisme de détection d anomalies et qualifier chaque type de flux par un degré d anomalies compris entre [0, 1]. Ces valeurs d anomalies sont ensuite partagées avec l ensemble des autres agents. La seconde phase de traitement, la mise à jour de confiance, consiste à intégrer les valeurs d anomalies de l ensemble des agents. Chaque agent possède un modèle de confiance pour des exemples de familles de flux. Les valeurs de confiance attribuées à ces flux sont mises à jour avec les anomalies détectées. Le poids utilisé pour la mise à jour de ces valeurs de confiance va décroitre avec la distance entre l anomalie détectée et la normalité du flux. La fonction de calcul de distances entre les évènements détectés et la référence sera différente pour chaque agent qui possède un point de vue différent sur les problèmes détectés. La dernière étape de traitement pour chaque agent consiste à déterminer le niveau de confiance à accorder à un flux. Chaque agent échange son opinion sur les flux et cet agrégat de niveaux de confiance peut être utilisé pour filtrer le trafic.

43 30 Architectures appliquées à la vision globale Les méthodes de coopération et de réputation proposées dans [46] sont convaincantes et semblent réduire par 2 le taux de faux positifs en prenant en compte les mécanismes de détection d anomalies individuellement. Cette méthode de coopération est prometteuse pour la réduction des fausses alarmes dans les NIDS. Par la mise en place d une distribution des anomalies de chaque agent, cette approche permet de détecter des signes d attaques complexes ou distribuées. Cette observation globale n est malheureusement applicable qu à l observation de source de données identiques (flux réseaux). [45] présente la problématique de distribution des connaissances différemment en réalisant une architecture à base d agents mobiles. Les auteurs préconisent que les agents traditionnels peuvent utiliser la mobilité pour voyager 1 au travers différentes sources de données et d exécuter leurs tâches à distance afin d assurer une distribution des analyses. [45] défini ces agents comme des agents légers qui accomplissent des tâches essentielles avec un minimum de code. Pour que la détection d intrusion soit efficace, il faut que les agents mobiles aient la capacité de traiter les informations sur le système où ils ont migré et de transporter les règles de détection à appliquer. Pour garder leur caractéristique de légerté 2, les agents mobiles ne vont pas contenir l ensemble des règles de corrélation mais seulement leurs caractéristiques essentielles et une fois arrivé à destination, ils mettront à jour et étendront leur fonctionnalité en fonction de la situation. Ces agents sont autonomes et choisissent eux-mêmes où et quand ils migreront. La mise en place d agents mobiles permet d éviter les limites des architectures clients-serveur. Le flux de contrôle va se déplacer à travers le réseau au lieu d utiliser les questions/réponses classiques des architectures clients-serveur. Dans le cas présent, chaque noeud est un serveur dans le réseau d agents et les agents se déplacent à l endroit où ils pourront trouver les services dont ils ont besoin. La figure 2.4 présente l architecture multi-couches surlaquelle s appuie les agents mobiles : Des agents de filtrage statiques qui collectent les informations d audit, de log, des statistiques opérationnelles et les normalisent dans un format commun. Des agents de bas-niveau (agents mobiles) qui surveillent et classent les activités, les évènements et transmettent leurs résultats aux médiateurs. Chaque agent bas-niveau possède plusieurs facettes 3 lui permettant de coopérer avec les autres agents. Des agents de traitement assurant un management et les analyses complémentaires à la détection d intrusion. Cette couche d agents va permettre de guider les agents bas-niveau et leur indiquer les systèmes à visiter (Mediators) mais également de fusionner les données reçues par les agents bas-niveau et d enrichir la connaissance de la base de données (DataFusion). Ces informations concentrées seront utilisées par des machines d apprentissage pour la génération des règles prédictives (Datamining). Ces règles s appuient sur une base de données qui stocke les données pour l apprentissage et la détection hors ligne (Database). Les agents mobiles constituent la première ligne de défense pour la détection d intrusion. Ils se déplacent périodiquement sur chaque agent de filtrage lui étant associé, collectent les informations récentes, classent les données et déterminent si une intrusion particulière a eu lieu. 1 Un ensemble de code se déplacera sur les différents composants de l architecture. 2 Afin de permettre aux agents de voyager ces derniers doivent possèder une taille la plus petite possible. 3 Ensemble de plusieurs ports de communication.

44 État de l Art 31 Fig. 2.4 Architecture de détection d intrusion à l aide d agents mobiles La coopération inter-agents bas-niveau est assurée par la mise en place conjointe de mécanismes d agrégation dynamique, de concept de sensibilité et de l utilisation de facettes. L agrégation dynamique est réalisée par chaque agent de bas-niveau et permet de partager les informations collectées par un agent avec les autres sans surcharger la bande passante réseau. Cette agrégation dynamique permet aux agents de bas-niveau d informer les autres agents de toutes activités intrusives en utilisant les facettes comme moyen de communication. Chaque facette permet d échanger des informations relatives à un type d activité d intrusion spécifique et de mettre à jour le niveau de sensibilité d un agent. Cette sensibilité permet à chaque agent de faire varier leurs seuils de normalité et prendre en considération de nouveaux évènements lorsque la sensibilité de l agent est élevée. Lorsqu un agent mobile détecte une intrusion, il informe les autres agents qui changent alors leur niveau de sensibilité. Dans le cas où la sensibilité d un agent est élevée, des évènements qui précédemment étaient perçus comme normaux (succession de login failed) sont alors perçus comme des traces d intrusion (si un autre agent à détecter une tentative de reconnaissance sur la même machine par exemple). L architecture à base d agents mobiles proposée par [45] présente plusieurs avantages par rapport aux architectures de détection classiques. Plusieurs niveaux de détection d intrusion sont possibles ; la détection de différents types d intrusions sur plusieurs machines (chaque agent étant en charge d un type d intrusion), l ajout d information contextuelle globale (coopération entre les agents mobiles), l apprentissage de nouveaux patterns de détection (assuré par les agents de haut niveau lors de la détection globale hors ligne). Enfin l utilisation d agents mobiles permet de ne pas utiliser continuellement les ressources des composants surveillés et évite une surcharge de la bande passante réseau. Les architectures de détection d intrusion collaboratives permettent d améliorer les architectures centralisées classiques en terme d efficacité et de fiabilité. Au contraire des architectures classiques centralisées qui présentent un point unique de panne et une cible unique pour un

45 32 Algorithmes d analyses attaquant, les approches coopératives assurent une disponibilité du système de détection d intrusion. Grâce à l analyse distribuée de ces approches, les architectures collaboratives assurent un maintien de la détection d intrusion même si un agent de détection devient inopérationnel. De plus, l utilisation de la coopération par les modèles de confiances permet de diminuer de façon significative les fausses alertes générées par les systèmes de détection d intrusion. Enfin, la quantité d informations échangées peut être réduite en utilisant des agents mobiles légers qui ne surchargent pas la bande passante du réseau surveillé. 2.3 Algorithmes d analyses De nombreux travaux ont été menés afin de déceler des scénarios d attaques sur l ensemble du SI. La majorité d entre eux tentent de modéliser des scénarios d attaques afin d en retrouver des traces dans l ensemble des données collectées. Ces approches peuvent se distinguer principalement par leur méthode de génération des scénarios d attaques. [28, 31, 29] proposent une modélisation explicite des scénarios d attaques. Dans la plus part de cas, les scénarios d attaques sont exprimés à l aide de graphes d attaques qui représentent l enchainement de l ensemble des étapes nécessaires à la mise en oeuvre du scénario. La description des attaques contient beaucoup d informations. Comme le précise [28], six types d informations doivent être décrites lors de la représentation d une attaque : le séquencement des actions, les interdépendances des étapes d attaque, les pré-conditions à une attaque, les post-conditions d une attaque, les actions et les capacités de l attaquant ainsi que les ressources utilisées. Le séquencement des actions et leur ordre temporel permettent de définir le cheminement logique d une attaque. Cet ordre temporel permet d introduire la notion d interdépendance des étapes d un attaquant. L exécution de certaines actions d un attaquant nécessite des prérequis fournis par l exécution d autres actions. Par exemple, l exécution d un bruteforce sur /etc/passwd nécessite que /etc/passwd soit connu et lisible par l attaquant, qu il contienne des mots de passe et que certains de ces mots de passe soient faibles (mot de passes courts par exemple). Les pré-conditions d une attaque regroupent l ensemble des hypothèses nécessaires pour atteindre l objectif final d un attaquant. Pour effectuer un exploit et élever ces privilèges sur une machine distante par exemple, il est nécessaire qu une vulnérabilité produisant cet effet soit présent sur le système ciblé. Les post-conditions d une attaque expriment le gain obtenu par un attaquant après avoir effectué une action. Ainsi après avoir lancé un Nmap (scan de machine) sur un système, un attaquant aura gagné la connaissance des différentes machines du réseau ciblé. Enfin, les actions de l attaquant, coeur du graphe d attaque, doivent faire partie intégrantes de l information décrite. Une dernière catégorie d information est présentée par [28], les capacités et les ressources nécessaires pour la réalisation d une attaque. Cette catégorie d information se distingue des interdépendances et des pré-requis en se focalisant sur les ressources possédées par l attaquant. Une grande puissance de calcul et la possession de dictionnaires efficaces peuvent constituer les capacités et ressources nécessaires à un attaquant pour réaliser un bruteforce. [28] défini deux catégories de graphe d attaques : les graphes d attaques basés sur les arbres

46 État de l Art 33 de fautes (Fault Tree) et les graphes d attaques orientés réseau de Petri. Bruce Schneier [47] fut le premier à associer la notion de graphe d attaques aux arbres de fautes. Les arbres d attaques décrivent les différentes étapes d un attaquant et leurs dépendances. Les noeuds des arbres représentent dans la plupart des cas des actions de l attaquant. Chaque racine des différents arbres représentent l objectif final d un attaquant. Les interdépendances entre les différents objectifs d un attaquant seront représentées par un arbre hiérarchique. Chaque étape d un attaquant doit être atteinte pour que la prochaine puisse s effectuer. De plus, les dépendances entre chaque étape seront enrichies par l ajout d opérateurs logiques ET, OU permettant de définir les conditions pour atteindre une étape. La structure hiérarchique permet de simplifier le parcours des différentes branches de l arbre. [47] a proposé également d introduire des étiquettes permettant de préciser si les étapes de l attaquant sont réalisables ou non (exemple : pour l exploitation d une vulnérabilité particulière il est nécessaire que cette vulnérabilité soit présente sur le système visé). Ces étiquettes reflètent indirectement les propriétés du système. [48, 20] utilisent les réseaux de Petri afin de décrire les graphes d attaques. Un réseau de Petri est un graphe orienté comprenant deux types de sommets, reliés par des arcs, des places et des transitions. A un instant donné, une place contient un certain nombre de jetons évoluant au cours du temps. Ces jetons décrivent la quantité de ressource présente dans une place. Dans une représentation de graphe d attaques par un réseau de Pétri, les étapes d attaques sont représentées par des places de façon similaire à [47]. Dans ce contexte, chaque jeton présent dans une place (étape d un attaquant) représente le niveau d avancement de l attaquant. Les transitions vont conditionner le passage d un jeton entre plusieurs places et vont nous indiquer les pré-requis nécessaires pour atteindre une étape du scénario d attaques. La modélisation des graphes d attaques par réseaux de Petri ne restreint pas la structure du graphe à une arborescence permettant la réutilisation de sous graphes dans différents contextes. Cette représentation permet la modélisation de situation plus complexe autorisant boucles et retours en arrière. Ces graphes d attaques sont largement réutilisés par les Systèmes de Détection d Intrusion afin de déceler des étapes d attaquants dans les informations collectées sur le SI. D autres approches dérivent des méthodes automatiques de génération de scénarios d attaques ou d erreurs. [32, 27] utilisent les models checker afin de générer des scénarios d attaques automatiquement. Les models checker sont des méthodes permettant de vérifier automatiquement le bon fonctionnement d un système. Le model checking est également défini comme une technique automatique utilisée pour la vérification des systèmes critiques. Le système étudié est dynamique (il évolue au cours du temps) et réactif (il interagit avec d autres systèmes et avec son environnement). Un model checker reçoit typiquement en entrée un modèle du système étudié ainsi que les politiques de fonctionnement décrivant le bon fonctionnement attendu. Afin de prévoir des failles de sécurité ainsi que des pannes de fonctionnement, les models checker permettent d observer l ensemble des éléments de dysfonctionnement. Pour ce faire le fonctionnement des models checker peut être divisé en trois étapes. La première étape consiste à modéliser le système étudié à l aide d un graphe orienté composé de noeuds et de transitions. Chaque noeud représente un état du système et chaque transition les évolutions possibles du système à partir d un état donné. Ce graphe orienté d automate fini

47 34 Algorithmes d analyses utilisé pour la représentation du comportement d un système est appelé structure de Kripke Une seconde modélisation du système est effectuée en décrivant la négation du comportement logique attendu (cette description est à définir explicitement). Cette modélisation est transcrite à l aide d une structure de Kripke et permet de reconnaitre exactement l ensemble des exécutions satisfaisant la négation du comportement attendu. C est dans une dernière étape que les models checker effectuent le produit cartésien (synchrone) des deux structures de Kripke obtenues précédemment. Si le résultat obtenu est vide alors le comportement logique attendu est vérifié. Dans le cas contraire l ensemble des contres exemples seront contenus dans ce produit cartésien. [32, 27] appliquent le principe du Model checking à la détection d intrusion en générant des scénarios d attaques à partir d un modèle du SI et les politiques de sécurité que l on souhaite mettre en place. Grâce à des algorithmes performants, ces approches permettent de générer les scénarios possibles dans le système observé menant au contournement des politiques de sécurité visées. L objectif de ces approches est de générer automatiquement des graphes d attaques. Ces graphes d attaques constituent l assemblage de vulnérabilités locales découvertes sur des composants du SI à l aide des connectivités existantes entre ces composants. Ces graphes d attaques sont des séries d exploits entrainant le système dans des états indésirables. [32] défini un modèle d attaques comme un automate fini M = (S, τ, s 0 ) ou S est un ensemble d états, τ S S une relation de transition et s 0 S l état initial. L espace d état S représente un ensemble de trois agents I = {E, D, T } tels que E représente un Attaquant, D un défenseur et T le système attaqué. Chaque agent i I possède ces propres états S i, ainsi S = x i I S i. Chaque agent i I est associé à un ensemble d action. Les auteurs exposent un exemple précis de modèle pour un graphe d attaques réseau, E sera représenté par un modèle d attaquant, D par un ensemble d IDSs et enfin S par la combinaison de machines H, des connexions réseaux C et des relation de confiance entre les machines T r. Chaque composante des agents doit être définie, H par exemple est défini par un identifiant, par un ensemble de services/ports disponibles, par un ensemble de programmes installés et par une liste de vulnérabilités portées par ce composant. Enfin chaque action réalisée sur le système sera définie comme un triplet (r, H s, H t ) ou H s, H t représentent respectivement la machine source et destination affectées par l action et r une règle décrivant comment l attaquant peut modifier le système ou sa connaissance du système (ensemble de pré-conditions et d effets relatifs à l attaquant et au système). Les models checker construisent un graphe de scénarios d attaques à partir de l association de l ensemble de ces éléments. Les approches par Models Checking sont particulièrement utilisées pour vérifier des modèles, des protocoles ou encore découvrir des erreurs lors de la mise en place de politiques de sécurités. Malheureusement la découverte de l ensemble des scénarios d attaques sur un système à un prix important. Sans la connaissance explicite de l ensemble des informations du système observé (machines, services, programmes, vulnérabilités, connectivités) et des actions (pré-conditions et effets), la modélisation de ces graphes d attaques est impossible. L application des Models Checker à une vision globale pour la découverte de scénarios d attaques est délicate. Cependant son intérêt reste entier pour une utilisation sur un périmètre restreint.

48 État de l Art 35 [33] propose une approche différente permettant de construire par apprentissage un modèle de détection de scénarios d attaques sur un SI. La construction de leur modèle est divisée en deux phases distinctes : une phase d apprentissage et une phase d exploitation. La phase d apprentissage consiste à apprendre des règles de classifications à partir d une base de scénarios d attaques. Cette base contient l ensemble des évènements composants les scénarios ainsi que le type de scénarios d attaque auquel ils appartiennent. Les données sources utilisées pour cet apprentissage ont été récupérées lors d une conférence de Hackers, DEFCON 8. Lors de cette conférence, les participants avaient pour objectifs de corrompre plusieurs serveurs. Cette manifestation a donné lieu à la production de plusieurs scénarios d attaques, qui ont été collectés au travers de sondes et labelisés (cf. figure 2.5). Fig. 2.5 Répartition d alertes dans le temps sur des scénarios d attaques de DEFCON [33] va réaliser un modèle de détection de scénarios d attaques en précisant comment les alertes des ces scénarios peuvent être reliées entre elles. Les auteurs ont définis trois critères principaux leur permettant de qualifier une relation entre les alertes des scénarios. Le premier critère correspond à la probabilité que deux alertes soient successives dans le temps. Cette probabilité propre à chaque scénario d attaques est extraite de l apprentissage. Un second paramètre est utilisé pour identifier la durée séparant deux alertes. Cette durée est exprimée par une fonction sigmoïde σ ij ( t) = 1 1+e α+β t où les paramètres α, β sont propres à chaque type de transition (les types de transition étant spécifiques aux scénarios d attaques). Un dernier critère permet d identifier la proximité des adresses IP de deux alertes. Cette proximité est calculée en convertissant chaque adresse IP en binaire et en réalisant un et logique entre les deux adresses. Le nombre de 1 contenu dans le masque résultant déterminera la proximité des deux adresses IP. Une fois les trois paramètres évalués pour chaque type de scénarios d attaques, de nouvelles alertes seront utilisées dans une phase d exploitation. Durant cette phase, les alertes provenant du système observé seront évaluées suivant leur proximité (par comparaison des adresses IP), les écarts de temps respectifs entre chaque alerte et la probabilité

49 36 Algorithmes d analyses de succession des différents types d alertes. Une fois ces alertes évaluées leurs propriétés seront comparées aux propriétés des scénarios d attaques apprises dans la phase d apprentissage. L apprentissage de caractéristiques propres à chaque type de scénarios d attaques permet de classer les nouvelles alertes dans les différentes catégories et scénarios d attaques. Si cette classification a échoué alors les alertes sont jugées comme étant un comportement normal du système. Les paramètres utilisés afin de caractériser chaque scénarios d attaques sont convaincants et les résultats de la classification pertinents. Néanmoins, des données telles que la proximité de deux adresses IP vont fortement dépendre de la tolopogie utilisée lors de la période d apprentissage. De plus, la probabilité de succession des différentes actions définissant un scénario vont également dépendre du cadre d étude. Les modèles réalisés dans [33] vont permettre de détecter les types de scénarios appris dans un contexte d étude particulier (objectif des scénarios d attaques, topologie et composants du SI étudié) et ne pourront pas être aisément appliqués sur d autres SI. Enfin [35, 12, 49] définissent un apprentissage semi-explicite des scénarios d attaques. Ces trois approches ont focalisé leurs modélisations sur les différents évènements du SI. Partant du constat que chaque évènement peut être modélisé par ces causes/pré-requis et ces conséquences, ils ont défini chaque évènement à l aide de pré-conditions et post-conditions. Les pré-conditions d un évènement sont un ensemble de compositions d état du SI nécessaires à la présence d un évènement. Par exemple les pré-requis d un exploit de vulnérabilité Déni de Service sur un service sont : le service est démarré et la présence de vulnérabilité DOS sur le service. Les post-conditions d un évènement vont définir les conséquences de cet évènement sur le SI. Si l on reprend l exemple précédent d un exploit de DOS sur un service, la post-condition de cet évènement est le service est arrêté. Une fois l ensemble des évènements définis un moteur basé sur les systèmes experts construit l ensemble des scénarios possibles en imbriquant les post conditions des évènements appropriés aux pre-conditions d autres évènements. Une fois ces scénarios construits, le système de détection permet de placer les nouveaux évènements dans les scénarios appropriés. La figure 2.3 (a) décrit la modélisation d évènements en Lambda (language de corrélation [50]) impliqués dans un scénario d attaque Accès illégal à un fichier. Le graphe d attaque généré à partir de ces éléments est présenté dans la figure 2.3 b. FIG :(a) Modelisation d un accès illégal à un fichier FIG : (b) Graphe accès illégal à un fichier Tab. 2.2 Apprentissage semi-explicite des scénarios d attaques [12]

50 État de l Art 37 La figure 2.6 présente la mise un place d un zombie sur un système. Dans ce cas, les pré et post-conditions sont portées par les arcs du graphe. Fig. 2.6 Exemple type de graphe d attaques [35] Ces nouvelles méthodes apparaissent comme très prometteuses au regard des scénarios obtenus sur quelques évènements modélisés. La possibilité de générer automatiquement des scénarios d attaques ainsi que leurs variantes offre de bonnes perspectives pour la détection de scénarios d attaques. Les auteurs [35, 12] ont également développé les aspects de réaction en proposant des mécanismes permettant d inhiber des liens entre certains évènements. Malheureusement la modélisation massive de plusieurs dizaines de milliers d évènements est longue et délicate. La description de ces prédicats nécessite une connaissance experte, ainsi qu une grande rigueur de réalisation, indispensable pour la modélisation des évènements. Chaque évènement doit être scrupuleusement défini de façon identique aux autres afin d assurer une génération correcte de scénarios d attaques. Ainsi la moindre erreur réalisée sur un évènement peut entrainer la perte de création de plusieurs scénarios. La détection de scénarios d attaques entraine plusieurs difficultés. Tout d abord il est nécessaire de modéliser les scénarios d attaques ou les éléments qui les composent. De plus chaque attaque, élément d un scénario, peut être distribuée dans le temps ou topologiquement. Les scénarios d attaques peuvent également inclure de nombreuses variantes et les évolutions rendent leur détection complexe. Enfin certaines attaques constituant un scénario peuvent être transparentes au système de détection. Quelques travaux ont été menés afin de construire des scénarios d usage normal du SI. Ces travaux sont majoritairement issus de l analyse forensic des évènements. L étude des causes d évènements suspicieux ou des erreurs sur un système d information se base sur l analyse d évènements qui se sont produits sur l ensemble du système. Ces approches construisent majoritairement des arbres de causes à l aide d outil tels que les réseaux Bayésiens. Les réseaux Bayésiens sont des graphes acycliques orientés qui permettent d établir l ensemble des probabilités conditionnelles de chaque noeud. Ils présentent également l avantage d ajouter des preuves au sein du réseau afin de connaitre les probabilités conditionnelles des autres noeuds associés à cet évènement.

51 38 Algorithmes d analyses XMeta [30] est une approche de recherche de causes utilisant les réseaux Bayésiens afin d automatiser les recherches informatiques. Les auteurs proposent un réseau Bayésien composé de plusieurs entités (figure 2.3) ; le système cible (TH), les logiciels cibles (TS), les dégâts observés (RD), des attaques génériques (GA), les actions complémentaires (AA) pouvant accompagner une attaque, la source de l attaque (SA), les techniques d investigations à utiliser (IT). L ensemble des liens de causalité liant ces entités et les probabilités associées sont issues des résultats des enquêtes précédentes. Cette modélisation va présenter les séquences de l ensemble des éléments impactés lors d une attaque (actions et ressources). Les informations recueillies par les administrateurs de sécurité pourrons être injectées dans le réseau fournissant ainsi des probabilités de scénarios exécutés. Les logiciels (TS) et systèmes cibles (TH) qui correspondent aux informations propres au système surveillé sont saisis par l enquêteur. L enquêteur va ensuite saisir les dégâts observés (RD). Les valeurs de ces paramètres sont choisies parmi les informations contenues dans les bases de vulnérabilités (ICAT). Le réseau va ensuite formuler des hypothèses sur des liens les plus probables entre les dégâts observés (RD) et les attaques génériques (GA) (inférence). FIG : (a) Plan d investigation FIG : (b) Exemple d un Réseau instancié Tab. 2.3 Recherche de causes de XMeta [30] La nature de l apprentissage de cette approche est probabiliste et issue de l inférence. Ainsi grâce à un jeu de données, il sera possible de déduire des connexions entre les différentes entités (inférence) mais aussi de calibrer les probabilités de séquences. Cette approche va fournir des probabilités de scénarios et aiguiller l analyste pour la recherche de causes d erreurs ou d attaques. [51] propose une approche différente à base de DataMining pour la mise en place de profils utilisateurs utilisés par un moteur forensic. Les auteurs vont s attacher à définir des quatruplets sujet, action, objet, date qui définissent chaque évènement qui s est produit sur le système observé. Le sujet définit la personne ou le composant à l origine de ce comportement, l action correspond à une famille d action réalisée par le sujet, l objet à la cible de cette action et la date (date et heure ) à laquelle a été effectuée l action. [51] définit comme profil toutes séquences d évènements possédant un même sujet. Lors

52 État de l Art 39 de l apprentissage des séquences, des variantes peuvent apparaitre ; soient trois évènements A, B, C constituant une séquence habituelle tels que A > B > C. Les trois évènements sont ordonnés dans le temps. Soit un évènement D peu probable qui appartient à une séquence A > B > D > C formant une variante de la séquence précédente. Cette variante est prise en compte en explicitant une séquence générale comme suit A > B > > C ou représente n importe quel évènement. La génération de séquences d évènements peut produire des sous séquences récurrentes tels que A > B > A > B. Afin d éviter cette redondance d information les auteurs ont spécifié une taille maximale de répétition. Si la taille maximale de répétition est égale à 1 alors la séquence A > A sera accepté et la séquence A > A > A rejetée. Chaque séquence générée définit un profil normal d utilisation du système observé. Afin de caractériser chaque profil, les auteurs déterminent la plus grande séquence non-répétitive comme différenciateur fort. Enfin, pour fournir des profils compacts à un analyste, les séquences de plusieurs sujets différents seront regroupées en fonction de leur similarité. Les profils générés dans cette approche permettent la différentiation de profils usuels des profils déviants. Leur mise en oeuvre sur les séquences d actions décrit bien le comportement des utilisateurs ou des composants du système. Les mécanismes de regroupement par similarité offrent la possibilité d identifier des groupes de comportements différents au sein du système observé. Cependant la gestion des répétitions des sous-séquences est délicate et peut entrainer une exposition de la complexité des séquences d évènements. L introduction de notions de fréquence de séquences d actions est pertinente et permet d entrevoir les possibilités d identification des séquences les plus probables. Cet aspect, peu développé dans cette approche, semble indispensable à la création de profils normaux sur le système d information. 2.4 Conclusion Dans cet état de l art, nous avons présenté les différentes approches formulées dans les travaux de recherche pour le traitement d information de sécurité avec un vision globale. Ces approches se distinguent par leur regard différent sur la problématique de la vision globale. Certains répondent par le biais d architectures distribuées permettant de collecter et analyser des données distribuées (section 2.2) d autres proposent des algorithmes d analyse des données distribuées tentant de modéliser les scénarios d attaques sur l ensemble du système ou les comportements normaux pour la détection d anomalies (section 2.3). Les architectures distribuées se distinguent par leur mode d analyse des données. Les architectures centralisées vont analyser l ensemble des données collectées et les analyser sur un seul et même serveur alors que les architectures collaboratives répartissent cette analyse au sein d agents distribués. Malgré des arguments de poids pour pallier les problèmes de performance, de passage à l échelle et de disponibilité, les architectures collaboratives restent couteuses à mettre en place et à intégrer aux infrastructures existantes. Aussi malgré ces limites connues, les architectures centralisées à base d agents distribués restent les architectures les plus simples à mettre en oeuvre pour l exploitation des connaissances distribuées dans le système d information. De nombreux modèles de description/détection de scénarios d attaques ont vu le jour ces dernières années. Malgré des approches innovantes permettant la description semi-explicite ou

53 40 Conclusion automatique des signatures de scénarios d attaques, ces approches nécessitent une expertise forte pour la génération des scénarios (description explicite des scénarios, ou pré-traitement lourd pour la génération automatique ou semi-explicite) et ne permettent pas la détection de nouveaux scénarios d attaques. La détection d anomalies comportementales appliquées à la vision globale, encore peu étudié et qui est le thème de cette thése, laisse entrevoir des méthodes de détection d intrusion complémentaires aux approches existantes de détection de scénarios d attaques. Nous développerons dans la suite de ce document notre moteur de détection d anomalies comportementales appliqué à la vision globale.

54 3 Collecte et Fusion d information 3.1 Introduction La détection d anomalies proposée dans notre approche va consister à récupérer l ensemble des évènements générés par le système afin d étudier et de modéliser des profils de comportements normaux. La majorité des systèmes actuels possède de nombreux composants et informations largement distribués. La récupération des informations nécessaires à l étude des comportements globaux du système doit se faire par le biais d architectures spécifiques (voir section 2.2). Comme décris dans la section 1.3.3, plusieurs processus sont indispensables pour l observation globale du système. Les processus d agrégation et de corrélation représentent le coeur de notre étude et seront développés dans les chapitres suivants. Les phases de collecte et de fusion des informations seront développées dans la suite de ce chapitre. Notre approche s appuie sur une architecture particulière permettant la collecte d information sur les différents composants du système. Cette architecture est composée d agents distribués dans le système et d un serveur d analyse qui recevra l ensemble des informations collectées. Chaque composant du système génère un certain nombre d informations relatives à son comportement et aux échanges et interactions effectués avec son environnement. Ces informations sont, dans la plus part des cas, concentrées dans des fichiers d audit ou de logs permettant d enregistrer une entrée par évènement survenu sur le composant. Ces informations, indispensables à la modélisation du comportement du système, seront récupérées par les agents distribués. Ces agents peuvent être assimilés à des programmes présents sur les composants étudiés qui remonteront les évènements contenus dans les fichiers d audits ou de logs des composants au serveur central d analyse. 41

55 42 Architecture de collecte d informations 3.2 Architecture de collecte d informations Dans la section 2.2 plusieurs architectures existantes ont été présentées différentiant les architectures centralisées des architectures collaboratives. Comme nous l avons vu dans cette section, les architectures collaboratives répondent parfaitement aux problématiques d étude de larges systèmes distribués mais restent très couteuses à mettre en place sur des infrastructures existantes. Malgré leurs limites (voir section 2.4) les architectures centralisées restent les plus simples à mettre en oeuvre. Nous allons décrire dans cette section l architecture réalisée pour la collecte et le traitement des données Hiérarchie et communication Tous systèmes d information étudiés possèdent des connaissances distribuées au sein de l ensemble des composants utilisés. Afin de collecter ces connaissances et de les interpréter, notre architecture est composée d agents distribués sur le système permettant de collecter et d analyser les connaissances distribuées. Ces agents ont pour rôle de collecter les données, d effectuer des pré-traitements nécessaires à leur étude et de retransmettre les données à un serveur central d analyse. Ce serveur central possède les informations nécessaires pour le traitement des données et la détection de déviances de comportement du système global. L architecture utilisée est une architecture hiérarchique centralisée (figure 3.1). Chaque agent effectue un pré-traitement des données collectées et les met à disposition sur serveur central d analyse. Ces données sont soit remontées périodiquement au serveur d analyse, soit délivrées à la demande du serveur. Fig. 3.1 Architecture Hiérarchique centralisée Rôle des agents Les agents distribués dans le système d information possèdent deux fonctionnalités principales :

56 Collecte et Fusion d information 43 Une fonctionnalité de collecte d information récupérant les informations disponibles sur le composant surveillé, Une fonctionnalité d homogénéisation et de fusion permettant de standardiser les informations collectées et de concentrer les informations essentielles à remonter. Notre architecture utilise trois types d agents différents : les agents basés constructeurs, les agents multi-collecteur et les agents multi-services (figure 3.1). Chaque agent basé constructeur est spécialisé dans la collecte d information provenant d un type d équipement. Les équipements utilisés par le SI possèdent des fonctions différentes (routeur, firwall, serveur) qui peuvent être utilisées par des équipements de différents constructeurs. Par exemple, dans le cas des firewalls, plusieurs produits commerciaux (Cisco-Pix, Checkpoint, Juniper) ou open source (IpTable, IpChain) existent générant des informations différentes. Ces agents sont spécialisés dans l étude et la collecte d informations d un équipement possédant une fonction spécifique (ex : Firwall) et un constructeur unique (ex : Juniper). Les agents multi-collecteur permettent la collecte d informations situées sur plusieurs équipements. Ce mode de collecte d information est utilisé pour des équipements de fonctions différentes ou communes possédant une redirection de leur information d audit (sys log). Chaque équipement pris en charge par un agent multi-collecteur redirige sont flux de logs vers l agent en question. Enfin, les agents multi-services collectent des informations sur des équipements possédant plusieurs fonctions. Par exemple, un serveur Web génère des informations d audit sur l activité du service Web mais le système d exploitation utilisé par ce serveur va également générer des logs de différentes natures. Les agents multi-services contiennent plusieurs fichiers de configuration leur permettant de collecter les informations spécifiques à chaque fonction. Chaque donnée collectée par un agent correspond à un évènement survenu sur l équipement surveillé. Un évènement est composé d un identifiant correspondant à sa signification et d un ensemble d attributs correspondant aux informations de contexte dans lequel c est effectué l évènement. L ensemble des évènements collectés par les agents possède une signification (sémantique) et une structure (syntaxe) différentes dépendantes de la fonction et du type d équipements. Chaque constructeur d équipement possède son propre format de description d évènement. Un évènement peut être décrit par un langage formel 1 (facilement lisible par une machine) ou en langage naturel (facilement lisible par un utilisateur). Par exemple, les évènements remontés par les postes Windows Microsoft en WMI (Windows Management Instrumentation) vont utiliser un langage naturel pour exprimer un évènement ; exemple de message : Cannot start a new logon session with an ID that is already in use. D autres équipements tels que Scanmail vont utiliser un langage beaucoup plus structuré ( 10/25/ :00 :19 /F10/25/ :00 :42 /TInternet/S/CIncomplete /RUpdate : Generic source network failure /D ). Les agents ont pour rôle de récupérer ces informations hétérogènes et de leur apporter une sémantique et syntaxe commune. Les processus de fusion des agents vont s appuyer sur cette normalisation des évènements afin de concentrer les données reçues. Chaque agent possède un mécanisme de fusion qui va lui permettre de regrouper l ensemble des évènements possédant la même signification et les mêmes attributs. 1 Un langage formel est un langage qui est défini à partir d un alphabet et d un certain nombre de règles formelles

57 44 Architecture de collecte d informations Les données remontées au serveur d analyse seront donc constituées de groupes d évènements (même identifiant même attributs) possédant une occurrence et une date de détection. L homogénéisation des données sera développée dans la section Rôle du serveur d analyse Le serveur d analyse est le centre névralgique de notre architecture. L ensemble des traitements complexes sont concentrés dans ce serveur qui aura à sa charge la gestion des agents, la récupération des informations renvoyées par les agents, l analyse comportementale globale et la présentation des résultats. Chaque agent déployé sur les composants du système observé établit une connexion avec le serveur d analyse. Le serveur d analyse spécifie le type de communications effectué par les agents (agents vers serveur ou serveur vers agents) ainsi que le mode de remontée d information (remontée d information périodiquement ou à la demande). Les données provenant des agents sont ensuite analysées puis stockées dans une base de données sur le serveur d analyse. Cette base de données est utilisée pour l apprentissage éventuel des comportements, la détection forensic et sert également de preuves légales en cas de nécessité. L analyse comportementale des évènements collectés s effectue lors de deux périodes ; une période d apprentissage permettant la réalisation de profils normaux de comportements et une période d exploitation permettant la détection d anomalies comportementales. La période d apprentissage peut utiliser des informations à la volée pour construire les profiles normaux ou des informations stockées en base. La figure 3.2 résume les différentes fonctions des éléments de notre architecture. Fig. 3.2 Architecture Fonctionnelle

58 Collecte et Fusion d information Homogénéisation des données Comme précisé précédemment, les évènements collectés proviennent d équipements de constructeur et nature différents. L information portée dans la description d un évènement peut varier. Cette description peut contenir plus ou moins de détail sur l évènement (informations de contexte) et exprimer un sens commun mais de différentes manières en fonction du langage utilisé. Par exemple l expression d une authentification peut varier en fonction de l équipement impliqué dans cet évènement : "Account Locked" (Serveur d authentification Radius) "Started to accept connection" (Serveur base de données Oracle) "Cannot start a new logon session with an ID that is already in use"(poste de travail ou serveur Windows WMI) "Login success" (poste de travail ou serveur Solaris) "Administrator Logon Failed 0x40705a00" (Antivirus McAfee) Pour pouvoir traiter efficacement les données hétérogènes, il est nécessaire de normaliser la sémantique et la syntaxe de tout évènement collecté. L homogénéisation de la syntaxe permet de définir une structure stable à chaque évènement et permet de récupérer toutes les informations de contexte nécessaires. L homogénéisation de la sémantique permet d extraire le sens de chaque évènement et de l exprimer dans un langage commun Homogénéisation de la syntaxe des données Nous avons choisi de regrouper l ensemble des informations de contexte (attributs) dans une structure dédiée à la remontée d informations relatives à la détection d intrusion. Le format d échange IDMEF (Intrusion Detection Exchange Format) [52] est un standard IETF (Internet Engineering Task Force) utilisé pour standardiser les syntaxes des alertes issues de la détection d intrusion. Afin de standardiser ces alertes, le format IDMEF se veut générique pour toutes les méthodes de détection existantes. Basées sur une représentation orienté-objet, les alertes standardisées sont envoyées depuis les systèmes de détection vers un moniteur de supervision. Le modèle IDMEF se veut flexible pour s adapter à tout type d évènements qui peut survenir, et entre lesquels le niveau de détail d information ne sera pas forcément identique. Ce modèle présente l avantage de pouvoir définir des classes génériques ou spécifiques. De cette façon la notion de source ou de destination peut totalement diverger suivant le type de système. Des représentations par utilisateur, noeud réseau, processus ou encore service peuvent ainsi traduire la source d une attaque. La figure 3.3 décrit la structure d un message IDMEF. Cette structure est divisée en deux classes distinctes : Alert et heartbeat. La classe heatbeat contient l ensemble des informations relatives au principe de disponibilité des équipements. Cette classe permet aux agents IDMEF d avertir régulièrement le moniteur de supervision. La classe Alert contient les détails des informations de l évènement détecté. Pour décrire l évènement sept catégories de sous-classes sont utilisées. Tout d abord un message IDMEF contient des informations temporelles relatives à l apparition de l évènement et à sa détection (CreateTime, AnalyzerTime). Le type d équipement ayant remonté l évènement est spécifié dans Analyzer.

59 46 Homogénéisation des données Fig. 3.3 Structure d un message IDMEF La source à l origine de l évènement ainsi que la cible de ce dernier sont spécifiées dans des classes génériques Source, Target qui contiennent un ou plusieurs types d informations fonction de l équipement et de l évènement (Node, User, Process, Service). Le modèle IDMEF prend également en considération le risque associé à l évènement qui s est produit (Assessment) et des informations complémentaires décrivant le contexte de l évènement (AdditionalData). Enfin la signification de l évènement est contenue dans le champ Classification Text. IDMEF ne propose pas de standard pour le contenu du Classification Text. La signification de chaque évènement dépend toujours du langage utilisé par l équipement ayant remonté les évènements. L ontologie décrite dans permet d uniformiser la sémantique des évènements collectés. Nous avons utilisé le standard IDMEF pour l homogénéisation de la syntaxe des évènements car, issu d un effort d interopérabilité des systèmes de détection d intrusion, il offre une généricité dans la définition de la structure d un évènement Homogénéisation de la sémantique des données : vers une Ontologie comportementale Outre la définition d un standard de syntaxe commun, il faut également définir la sémantique des évènements à l intérieur de cette syntaxe. Pour résoudre le problème d hétérogénéité des formats des évènements, il est nécessaire de transformer les évènements bruts (issus d un équipement sans transformation) dans une représentation uniforme, c est à dire de définir des catégories communes et de procéder ensuite à la classification des évènements bruts dans ces catégories. Nous avons utilisé une ontologie [53] qui décrit d une manière uniforme toutes les actions qui peuvent être effectuées par des utilisateurs du SI. De plus chaque langage utilisé par les équipements sont différents, focalisant leur description sur des aspects particuliers d un évènement. L ontologie utilisée nous garantira une abstraction de ces langages et s intéressera aux concepts manipulés par ces derniers.

60 Collecte et Fusion d information 47 La description d un évènement est fortement liée à l action perçue par le système. Une action peut être observée à tout moment de son cycle de vie, depuis son déclenchement jusqu à sa fin ou son interruption. Un évènement peut porter l information d une action qui vient de démarrer, en court, échouée ou finie. L évènement dépend du niveau d avancement de l exécution de l action. [53] a utilisé la modélisation des évènements via le concept d actions observées. Cette modélisation s adapte ainsi à tout type d observations quelque soit l équipement l ayant remonté. [53] précise que l analyse conceptuelle est un champ de la philosophie, tout autant qu un outil, permettant d aborder ces problèmes. Plus précisément, la théorie de l action [54, 55] issue des réflections philosophiques est utilisée pour définir ces concepts. Le rapprochement entre la théorie de l action et l évènement a permis à [53] de définir une catégorie de l ontologie à l aide de quatre concepts : l intention de l utilisateur, le mouvement effectué, la cible de l action effectuée et le gain. La figure 3.4 illustre ces concepts de l ontologie. Le concept Intention décrit la raison pour laquelle l utilisateur effectue son action. Les intentions ont été définies après l étude de la démarche de l attaquant dans [53]. Un utilisateur du SI possède 4 types d intentions : la collecte d information sur la cible (Recon), l accès au SI (Authentication), l accès à une ressource du SI (Authorization) et la modification de la disponibilité des ressources du SI (System). Le mouvement est le moyen utilisé pour réaliser l objectif de l utilisateur. Le mouvement est exprimé dans l ontologie par le concept Movement. Les actions sont différentiées suivant leurs modes (Activity, Config, Attack,...) et suivant leurs natures (Login, Read, Execute,...). Le mode et la nature de l action définissent le mouvement effectué. Chaque mode de mouvement identifie une catégorie de moyen employé par un utilisateur : Activity : décrit tous les mouvements relatifs à une action qui ne change pas la configuration du SI, Config : correspond à tous les mouvements de changement de configuration, Attack : définit tous les mouvements relatifs à une attaque, Malware : correspond à des mouvements de malwares, Suspicious : décrit tous les mouvements détectés comme suspect par une sonde (la notion de suspicion étant attribuée directement par la sonde ) Vulnerability : correspond aux mouvements relatifs aux vulnérabilités, Information : correspond à l observation d états du système. La cible est l objet vers lequel l action est dirigée, elle définit l ensemble des ressources du SI. Ces cibles sont exprimées dans l ontologie par le concept Target. Enfin chaque action produit un résultat. Le résultat correspond au gain de l utilisateur ayant effectué une action. Le gain est symbolisé par la réussite ou l échec de l action réalisée. Ce gain est exprimé dans l ontologie par le concept Gain.

61 48 Conclusion Par exemple, pour une action d administrateur d ouverture de session sur un firewall, l ontologie décrit cette action par les 4-uplets : Authentication (se refère à l intention de l utilisateur), Activity Login (se réfère au mouvement effectué par l utilisateur), Firewall Admin (se réfère à la cible de l action effectuée) et Success (se réfère au résultat de l action). La catégorie d évènement de cette action est : Authentication_Activity Login_Firewall Admin_Success. Fig. 3.4 Sémantique d un message de sécurité La catégorie d évènement possède donc un schéma de classification décrit par les 4-uplets (Intention, Movement, Target, Gain). Les catégories de l ontologie expriment le sens de l évènement et le vocabulaire que nous devons respecter pour exprimer les évènements bruts. Ce vocabulaire est composé de 4 Intention, 7 modes de Movement, 52 natures de Movement, 70 Target et de 13 Gain. Une catégorie d évènement est constituée d une instance de chacun de ces concepts. L évènement brut est ainsi classé dans une des catégories de l ontologie qui porte la sémantique, le sens de ce dernier. 3.4 Conclusion Afin de collecter, d homogénéiser et de fusionner des évènements collectés sur le système d information, nous utilisons une architecture à base d agents distribués. Chaque agent collecte des informations sur un ou plusieurs équipements et effectue un pré-traitement avant de transmettre ces informations au serveur central d analyse. Ce pré-traitement va consister tout d abord à homogénéiser les évènements collectés et à leur fournir une syntaxe (IDMEF) et une sémantique commune (l ontologie [53]). Cette homogénéisation des données va permettre de fusionner des évènements identiques (possédant une signification et un certain nombre d attributs communs). Ce chapitre nous a donné les bases indispensables à l analyse des comportements du système. Le chapitre suivant va définir les types de comportements à observer et à modéliser.

62 4 Analyse des démarches utilisateurs 4.1 Introduction Un Système d Information peut générer plus de mille évènements par seconde. L étude et le traitement d un tel volume d information nécessite des processus de pré-traitement particuliers permettant d homogénéiser les évènements et de fusionner des informations redondantes. Le chapitre 3 a défini le cadre technique de notre analyse comportementale incluant ces processus. Avant toute modélisation ou analyse, il est indispensable de connaitre l environnement et les objets que l on souhaite observer. Un Système d Information est composé de plusieurs entités physiques considérées comme des composants actifs (machines, services, protocoles) qui interagissent entre eux mais également avec des acteurs du Système d Information. Un utilisateur est un acteur du Système d Information humain ou non interagissant avec le système. Cette interaction va modifier les propriétés du système (Disponibilité, Intégrité, Confidentialité) mais également les propriétés de l utilisateur (gain d authentification, gain d autorisation et gain d utilisation du système, voir section 3.3.2). Un acteur du système utilise les entités actives pour atteindre des objectifs de différentes natures (personnel, professionnel ou malicieux). L interaction entre les entités actives et les acteurs du Système d Information est réalisée par le biais d infrastructures techniques (communication, sécurité). Dans ce chapitre nous étudierons les interactions entre les acteurs (utilisateurs) et le système (entités actives et infrastructures techniques). Cette étude va permettre de préciser les informations que l on souhaite modéliser afin de détecter des déviances de normalité. Ces informations devront mettre en avant les évènements indispensables à la détection d intrusion. 49

63 50 Notion d indicateurs 4.2 Notion d indicateurs L observation des comportements d un Système d Information est réalisée à partir des évènements remontés par les agents. L analyse comportementale porte sur des groupes d évènements révélateurs d un type de comportement. Ces groupes constituent des indicateurs qui représentent des points d observation du Système d Information. Un indicateur reflète un point d observation d une action sur une cible (différentes fonctions d équipements). Dans le contexte de l analyse comportementale, nous allons mesurer la normalité d un indicateur à l aide de plusieurs mesures. Ces mesures, appelées métriques, dans la suite du document, produisent des grandeurs (transformées ou non par des outils mathématiques) mesurant la normalité de l indicateur. Les différentes notions utilisées telles que les indicateurs, les cibles, les métriques et les grandeurs interagissent entre elles (voir figure 4.1) permettant d associer à un indicateur donné une valeur. Fig. 4.1 Caractérisation d un indicateur 4.3 Description d un SI Pour définir le périmètre de notre étude, nous avons étudié les différents éléments composant un système. Un SI est généralement décrit suivant deux composantes : les états des composants du système (appelé également états du système) et les actions modifiant ces états. Les états du système sont souvent perçus comme les propriétés d un système à un instant t. Ils permettent de déterminer quelles sont les caractéristiques des services, composants, données présents sur un Système d Information. Chaque type de ressources possèdent ces propres caractéristiques d états. Ainsi les états d un service peuvent être démarré, arrêté, redémarré, inaccessible, accessible tant dis que les états d un fichier, sont accessible en lecture, accessible en écriture, accessible en modification, ouvert, fermé, corrompu. Les états du système constituent la connaissance que l on possède sur un système observé à un instant donné. L ensemble de ces états sont dynamiques et évoluent au cours du temps. Ce dynamisme est dû aux différentes actions effectuées sur le système qui vont modifier son état. Ces différentes actions sont produites par des acteurs extérieurs au SI (utilisateur ou processus) ou produites par le système lui-même. Ces acteurs ont été différenciés en plusieurs catégories comprenant les utilisateurs classiques (section 4.4.1), les administrateurs du système (section 4.4.2), les attaquants (section 4.4.4) et le SI lui-même (section 4.4.3). La figure 4.2 présente les interactions entre les actions opérées sur le SI et les états du système. Chaque composant d un SI est habituellement évalué suivant trois critères de sécurité (appelé métriques de sécurité) :

64 Analyse des démarches utilisateurs 51 La disponibilité qui décrit le niveau de maintien du bon fonctionnement d un composant ; L intégrité qui décrit le niveau de garantie que les informations transmises ou stockées n ont pas été modifiées. La confidentialité qui décrit le respect des politiques de consultation des ressources (une personne non autorisée ne dispose pas d accès à des ressources protégées). Chaque acteur qui interagit avec le système modifie ces métriques de sécurité en réalisant un gain ou une perte pour chacune des ces propriétés. Par exemple un individu accédant à des ressources protégées sans droit particulier réalise une perte de confidentialité sur cette ressource. Enfin un acteur particulier (le système lui-même) tente de maintenir les métriques de sécurité de l ensemble de ces composants. Fig. 4.2 Relations acteurs-composants d un SI Dans la suite de ce chapitre nous allons étudier plus en détail les différentes démarches des acteurs du SI et déterminer les indicateurs indispensables à la détection d intrusion comportementale. 4.4 Démarche des acteurs du système Tous les acteurs ne présentent pas la même utilisation des ressources du SI. Quatre grandes familles d acteurs ont été identifiées suivant leurs objectifs et leurs utilisations des ressources : Les utilisateurs classiques qui ont comme objectif d utiliser les ressources du système à des fins professionnelles ou personnelles non frauduleuses, Les administrateurs du SI qui assurent le bon fonctionnement des ressources et qui définissent les règles d interactions utilisateurs-ressources, Les attaquants qui tentent de nuire au système ou de l utiliser à des fins frauduleuses, Le système lui-même qui assurent les communications et interactions entre les composants actifs, les composants techniques et les acteurs. Dans les sections suivantes, les grandes phases des démarches des acteurs du système seront spécifiées à l aide des intentions et des mouvements de l ontologie [53] présentée dans la section Les autres concepts de l ontologie ne sont pas utilisés car ils sont trop spécifiques à un évènement donné et ne caractérisent pas une démarche globale. L ontologie utilisée permet de normaliser les évènements collectés sur un SI. Chaque évènement représente une action

65 52 Démarche des acteurs du système d un utilisateur ou d un processus sur une cible particulière. En ne spécifiant que les concepts d intention et de mouvement de l ontologie, nous décrivons des familles d actions réalisées par des acteurs du SI Démarche Utilisateur Nous avons effectué notre étude des utilisateurs classiques du SI en nous basant sur les travaux de [56] qui décrivent une analyse des comportements utilisateurs sur les réseaux Wifi. Un utilisateur classique souhaite utiliser le système à des fins professionnelles ou personnelles mais toujours dans le cadre des politiques de sécurité du système. Pour atteindre ces objectifs un utilisateur classique possède trois types d intentions : l authentification (Authentication), l autorisation (Authorization) et l utilisation des ressources (System). L authentification et l autorisation qui définissent les intentions d accès et de droits sur les ressources du SI, sont généralement effectuées lors de l authentification de l utilisateur. C est lors de sa connexion au SI qu un utilisateur reçoit des droits sur les composants du SI. Dans notre étude nous avons regroupé ces deux intentions. Bien que l ontologie utilisée présente plusieurs types de mouvements (voir section 3.3.2) un utilisateur classique n effectue que des mouvements de mode Activity, les autres mouvements étant relatifs à des comportements d administrateurs ou d attaquants. Les mouvements de mode Activity correspondent à une activité d utilisation des ressources n altérant pas la configuration du système. Toutes actions modifiant la configuration d un composant du SI (modification de règles de firewall, modification de la base de registre d une station de travail) appartiennent à un autre mouvement appelé Config. L activité d un utilisateur sur un système peut être résumée par deux familles d actions principales : la connexion/authentification locale ou distante (service, applications du SI...) et l utilisation des ressources locales ou distantes. La figure 4.3 résume les combinaisons de l ensemble de ces actions. Elle décrit une séquence d actions locales (authentification locale, utilisation locale des ressources, déconnexion) et une séquence d actions distantes (authentification locale suivit d une authentification distante, connexion distante, utilisation ressource distante, déconnexion du service distant, déconnexion du système). [56] confirme notre approche en montrant qu après s être connecté, les utilisateurs utilisent des ressources locales (consultation de site web, mail) ou des services distants (18% des utilisateurs étudiés utilisent des connections SSH) Démarche Administrateur Un administrateur est un utilisateur particulier du Système d Information. Il hérite des différentes actions de la démarche d un utilisateur classique mais possède des propriétés particulières. Outre son activité d utilisateur normal, un administrateur a pour rôle de configurer et de maintenir le Système d Information. De part son activité, il réalise des actions et utilise des cibles particulières, inaccessibles à des utilisateurs normaux. Afin de prendre en compte ces activités, le mouvement Config de l ontologie est utilisé pour décrire les actions de modification des configurations et des politiques d un composant. L intention Recon est également utilisée afin de modéliser les activités des tests effectuées par l administrateur. La figure 4.4 reprend

66 Analyse des démarches utilisateurs 53 Fig. 4.3 Démarche utilisateur l ensemble des activités administrateur. On y retrouve les actions usuelles d un utilisateur ainsi que des actions de configuration et de maintenance. L administrateur possède une authentification particulière (accès Root) lui donnant les pleins droits sur le système. Pour maintenir et mettre à jour le SI, l administrateur effectue des actions de modification de configuration (mise à jour des composants, ajout de nouveaux services) et de changement de politique (modification des règles du firwall, création de compte utilisateur). Afin de parfaire la disponibilité et la sécurité du système, un administrateur réalise périodiquement des tests sur celui-ci (tests d accessibilité, tests de vulnérabilité). Fig. 4.4 Démarche administrateur

67 54 Démarche des acteurs du système Démarche Système d Information La démarche du SI a pour objectif de maintenir son niveau de Disponibilité, Intégrité et Confidentialité. Les activités du SI représentent des actions internes effectuées par le système lui-même et non par un utilisateur ou processus externe. Les actions du SI sont décrites par un mouvement particulier de l ontologie appelé Information. En effet les différentes actions réalisées par le système lui-même sont perçues comme une information collectée et non une action à proprement parlée au sein de l ontologie. L ensemble des actions réalisées par le système-lui même est considéré comme des actions possédant un mouvement Information. Toutes les actions réalisées sur le SI par des acteurs différents (utilisateurs, administrateurs, attaquants) et qui engendrent une réactivité du système sont perçues comme un mouvement d activité (Activity). Chaque comportement de composants du SI peut être modélisé comme décrit dans la figure 4.5. Après le démarrage physique du composant Système, ce dernier lance les services nécessaires à son fonctionnement ou cherche à importer ou charger des informations depuis l extérieur (DCHP récupération d adresse, chargement de la liste des services à démarrer,...). Les services démarrés entrainent un changement de la configuration interne en fonction des politiques du SI (modification des paramètres réseaux, blocage de certaines fonctionnalités). Après cette étape de lancement, le composant système entre en attente d une interaction avec son environnement extérieur. La première action suivant cette interaction est la vérification des droits sur l opération demandée. Cette vérification peut être effectuée localement ou à distance. Une fois les droits vérifiés, l opération est effectuée. L évolution des états des composants n est pas uniquement liée à une interaction, le composant système peut effectuer des opérations qui sont de son ressort comme, le transfert d information, la réception et l envoi de mails, paquets, etc... Enfin la démarche classique d un système s achève par l arrêt du composant et de l ensemble de ces services. Cette procédure peut résulter d une intervention extérieures (System.Activity.Stop) ou du système lui-même (System.Information.Stop) Démarche Attaquant Le comportement le plus complexe et le plus imprévisible au sein d un SI est le comportement d un attaquant. L objectif final d un attaquant est variable et difficile à déterminer. Cependant certaines étapes sont nécessaires pour arriver à ses objectifs finaux. Pour se dissimuler, un attaquant tente de se fondre dans un comportement utilisateur. Le comportement d un attaquant hérite donc des actions utilisateur. L un des objectifs intermédiaire indispensable à un attaquant est d obtenir des droits similaires à ceux d un administrateur afin de modifier, récupérer ou altérer des données ou paramètres du SI. La figure 4.6 présente l ensemble des actions possibles d un attaquant sur le système. Nous distinguons cinq classes d objectifs pour un attaquant ; le gain de privilège, le gain d accès, le déni de service, le rebond et l espionnage. Pour arriver à ses fins, trois ou quatre étapes (selon le scénario utilisé) sont indispensables. Tout d abord l attaquant doit localiser le système à attaquer. Ensuite, il doit

68 Analyse des démarches utilisateurs 55 Fig. 4.5 Démarche Système récupérer des informations concernant ce système. Une fois la cible localisée et le système analysé (connaissance de l environnement et de ces vulnérabilités) l attaquant utilise une faille du système permettant d atteindre ses objectifs. Un autre processus parallèle existe consistant à utiliser des outils automatiques (virus) qui tentent d exploiter automatiquement une faille. Une fois le système pénétré, l attaquant possède un comportement proche de celui de l utilisateur ou de l administrateur. Bien que les actions d un attaquant ne soient pas toujours détectables (nouvelles attaques, absence de sondes), des déviances significatives de comportement lors de l utilisation d actions d utilisateur ou d administrateur peuvent être décelées. C est pour cette raison que les actions partagées entre les utilisateurs légitimes (utilisateur classique, administrateur) et les attaquants sont particulièrement importantes pour détection d anomalies comportementales. 4.5 Synthèse : sélection des informations à observer L analyse des démarches des utilisateurs du SI nous a permis de définir notre périmètre d étude. Pour mettre en oeuvre notre système de détection d anomalies comportementales, nous observerons et modéliserons les actions des utilisateurs légitimes du SI. Ces actions constituent nos indicateurs de comportement des utilisateurs du SI. L ensemble de ces indicateurs se regroupent autour de quatre familles distinctes : Authentication/Autorization.Activity : Activité d authentification et d utilisation de droits, System.Activity : Activité d utilisation ou d observation du système, Authentication/Autorization.Config : Activité de configuration et de changement de la politique d authentification ou de droit,

69 56 Synthèse : sélection des informations à observer Fig. 4.6 Démarche d un attaquant System.Config : Activité de modification de configuration et mise à jour des composants ou services du système, Recon.activity : Activité de recherche d information sur une cible particulière du système. Chaque indicateur observé représente un gain ou une perte sur les métriques de sécurité de Disponibilité, Intégrité, Confidentialité des ressources ciblées. L étude des déviances comportementales de ces familles d indicateurs permet de déterminer l évolution des métriques de sécurité. Nous avons redéfini ces familles d indicateurs autour des métriques de sécurité mises en jeu. Chacun des trois groupes d indicateurs représente un compteur d évolution d une métrique de sécurité Indicateurs pour le compteur de gain/perte d accès (Confidentialité) Les activités d authentification sont reflétées au travers 3 types d informations différentes : les d activités d authentification, les activités de connexion et les activités de modification d authentification. Les activités d authentification correspondent aux accès au système des utilisateurs et des administrateurs et à la validation de leur identité par un gestionnaire d authentification. Les activités de connexion reflètent les activités du système durant le processus d authentification. Ces activités inclues les connexions à des services extérieurs d authentification si nécessaire et l ensemble des transactions indispensables à l identification de l utilisateur connecté. Enfin, la surveillance des modifications des comptes d accès (Authentication_Config) est essentielle à la détection d intrusion potentielle puisque celle ci correspond au point d entrée de chaque utilisateur. Toutes les actions relatives à la modification de configuration d authentification seront prises en compte. L évolution de ce compteur conditionne la confidentialité du système observé. Si une déviance

70 Analyse des démarches utilisateurs 57 comportementale est constatée sur un accès d un utilisateur, la confidentialité du système sera impactée Indicateurs pour le compteur de gain/perte de privilège (Intégrité) Les activités de privilège reflètent toutes les actions utilisant ou modifiant des droits nécessaires à l utilisation de ressources du SI. Ces activités comprennent les activités de privilège et leur modification. Les activités de privilège décrivent l utilisation de droits particuliers d un utilisateur pour réaliser une opération. Les modifications de privilège correspondent à des modifications par un utilisateur de ces propres droits ou des droits d un autre utilisateur ou objet. Considérant que l utilisation de droits conditionne la modification des ressources et des données du système, ce compteur est rattaché à la métrique d intégrité. La détection d une anomalie comportementale lors de l utilisation d un droit de modification de fichier va impacter la métrique de sécurité d intégrité Indicateurs pour le compteur de gain/perte d utilisation du système (Disponibilité) Chaque acteur utilise les ressources du SI pour atteindre ses objectifs. Les fichiers ou les autres objets sont effectivement lus, écrits, supprimés, mais d autres opérations particulières peuvent être effectuées comme l exécution d une commande, le lancement d une application, le démarrage/redémarrage/arrêt d un service. Nous différencions deux types d activité système ; les activités liées aux interactions utilisateurs et les activités du SI lui même (actions automatiques). Comme précisé précédemment, les ressources du système peuvent être utilisées soit par des acteurs externes au système qui utilisent et/ou modifient les services et les applications, soit par le système lui même qui effectue des transactions d information ou encore des chargements de configuration. Ce compteur est associé à la métrique de la disponibilité. Toutes utilisations anormales des ressources du système engendre une modification de la métrique de disponibilité. Afin de mettre en avant la disponibilité des ressources du SI, nous avons également intégré le niveau des ressources du SI comme indicateur de l utilisation du système. Ainsi toute consommation excessive de mémoire ou arrêt intempestif d un service va diminuer la métrique de disponibilité. 4.6 Sélection d Indicateurs Les démarches des différents utilisateurs du système utilisent de multiples actions comme défini dans la section 4.5. L analyse globale des comportements des utilisateurs d un système est complexe et la multitude d actions qui composent les démarches des utilisateurs rend la modélisation des comportements normaux délicate. Dans cette section, nous allons présenter des processus de sélection d actions à observer indispensables à la détection d intrusion. Ces processus vont permettre de réduire la complexité de la modélisation des comportements normaux

71 58 Sélection d Indicateurs décrits dans les chapitres suivants. L étude des comportements des utilisateurs du Système d Information nous a permis de déceler les points de passage obligatoires de l attaquant dans la démarche de comportement normal pour atteindre son objectif. Les points de passage obligatoires constituent des goulets d étranglement par lesquels un attaquant passera obligatoirement. Ces points définissent des zones d observations incontournables pour l étude d un comportement déviant susceptible d appartenir à un attaquant. Fig. 4.7 Points de passage obligatoires La figure 4.7 nous montre les interactions entre les démarches des utilisateurs légitimes du système (utilisateur classique et administrateur) et la démarche d un attaquant. Les flèches reliant les deux démarches représentent les types d actions partagées par les deux approches. Deux types de Points de Passage Obligatoires (PPO) peuvent être différentiés. Les actions relatives aux connexions au SI dans la démarche utilisateur définissent le premier PPO. Afin d atteindre les ressources du système, un attaquant ne possède pas d autres alternatives que de passer par un point d authentification pour pénétrer le système. Le second PPO correspond à la transition de la démarche utilisateur vers la démarche de l attaquant à la fin d un scénario d attaque. L objectif final d un attaquant consiste à altérer, modifier ou étudier les ressources du SI. Pour parvenir à ces fins, un attaquant dévira son comportement du comportement usuel d utilisateurs ou d administrateurs. Le second PPO est moins révélateur que le premier car la détection de déviance lors de cette étape n est pas nécessairement possible. Dans la plupart des cas, des déviations minimes de comportement sur le Système ne sont pas détectables et seulement les effets de ses actions peuvent différentiées un attaquant d un utilisateur légitime.

72 Analyse des démarches utilisateurs Focalisation sur les Points de Passage Obligatoires Les actions d un attaquant passent par des goulets d étranglement appelés Points de Passage Obligatoires (PPO). Afin de sélectionner les indicateurs les plus pertinents nous nous attacherons à définir les PPOs de chaque type de scénarios d attaques. Pour être le plus exhaustif possible, nous avons combiné les différents moyens d attaques décrits dans l ontologie (voir figure 4.8) avec la classification des attaques par leur effet de la DARPA [attack-centric taxonomy Lincoln Laboratory 1998 DARPA]. L ontologie utilisée [53] a défini 25 types d attaques possibles utilisées comme moyen par les attaquants pour atteindre leur objectif. Cet ensemble d attaques représente l arsenal utilisé par un attaquant pour atteindre les effets désirés sur le système. La DARPA a défini une classification des attaques autour de ces effets. Elle préconise de décomposer tout type d attaques en cinq catégories : User to Root qui définit un effet d élévation de privilège depuis un compte connu vers un compte aux privilèges supérieurs, Remote to local qui définit l effet d obtenir un accès à un compte, composant ou service local depuis une connexion distante, Denial of service qui définit l effet de perte de disponibilité sur un composant ou service du système, Surveillance/probe qui définit l effet de collecte d information sur le système ciblé, System Access/Alter data qui définit l effet de perte d intégrité et de confidentialité des données du système. En associant les différents moyens d attaques et les effets attendus, nous décrivons un ensemble varié de sénarios d attaques types (voir figure 4.8). Fig. 4.8 Classification des actions d attaques Nous avons étudié l ensemble des points de passage obligatoires (PPOs) pour chaque variante de chaque type d attaque. Afin d illustrer notre travail, nous présentons dans la section suivante la définition des PPOs pour le type d attaques User to Root. L étude de l ensemble des points de passage obligatoires est disponibles en annexe 9.1.

73 60 Sélection d Indicateurs a) Exemple de PPOs pour User to Root L un des objectifs principaux d un attaquant est d obtenir les droits administrateur sur une machine du Système d Information. L authentification et la connexion au SI sont deux pré-requis à l obtention d un tel effet. Une fois l attaquant connecté plusieurs actions sont possibles pour la réalisation d un exploit. Des PPOs existent pour chacune des actions possibles. Six actions sont susceptibles de conduire une attaque à un effet de User to Root. L action de gain consiste à modifier les droits d une session en cours. Le PPO associé correspond à la modification des droits sur une session. Une autre alternative pour obtenir une élévation de privilège est de réaliser une injection de code. Cette injection consiste à effectuer une opération au travers d un service ou d une session démarrée. Le PPO nécessaire à la réalisation de cette opération est l exécution d une commande. L utilisation d un overflow (saturation d un buffer) qui surcharge un service afin d exécuter une commande peut également entrainer l élévation de privilèges. En noyant ainsi le buffer d un service, un attaquant a la possibilité d écraser un autre segment mémoire et d exécuter des commandes ou un script. Pour réaliser cela, une commande ou une requête doivent être lancées à la suite des paquets envoyés pour la surcharge. L action bypass d un attaquant qui consiste à contourner une authentification ou une politique de droits par un exploit, est plus difficile à détecter. Habituellement, l exécution d une commande est réalisée avant un exploit. Enfin, un attaquant peut élever ces privilèges en utilisant un Virus ou un Trojan. Ces Malwares (programme malicieux) sont des programmes installés sur le système avec des droits plus élevés et nécessitent évidement l installation de programme comme point de passage obligatoire Périmètre de surveillance (Risque) Un second processus de sélection des actions à observer consiste à focaliser l observation d indicateurs sur des composants particuliers du SI. La pertinence de chaque indicateur dépend également de la fonction et de la localisation de l équipement où il est collecté. Nous avons décomposé les équipements d un SI en trois classes : les composants actifs portant sur les services ou applications métiers de l organisme, les équipements d infrastructures techniques utilisés pour la communication (interconnexions techniques des autres équipements) et les équipements focalisés sur la sécurisation du SI. Nous avons différentié les composants actifs en fonction de leurs positions sur le SI et de leurs impacts sur l activité business de l organisme. Nous avons ainsi distingué trois classes d équipements : les postes utilisateurs : utilisés par le personnel d une entreprise pour effectuer des tâches courantes (bureautique) et accéder au système, les serveurs classiques du système : assurant le fonctionnement des activités de base de l entreprise et qui en cas de perte de disponibilité ou d intégrité affectent peu l activité de l organisme (serveur mail serveur). les serveurs sensibles du système : assurant le fonctionnement des activités majeures de l entreprise et qui en cas de perte de disponibilité ou d intégrité affectent grandement l activité de l organisme (serveur de données).

74 Analyse des démarches utilisateurs 61 Tous les équipements du Système d Information ne sont pas exposés de la même façon aux risques extérieurs. Plus un équipement est visible depuis l extérieur du SI de l organisme, plus ce composant est exposé aux attaques et aux intrusions. Nous distinguons quatre types d expositions différentes des équipements. La zone la moins exposée aux attaques restent le coeur d un SI, son réseau interne (LAN Local Area Network). Ce réseau possède effectivement des mécanismes de sécurité importants et n interagit pas directement avec l extérieur. A contrario, les utilisateurs mobiles (nomades), qui utilisent le Système d Information à distance, possèdent des équipements qui sont fortement exposés aux attaques et aux intrusions car ils ne sont pas rattachés à une architecture sécurisée. Afin d ouvrir le SI aux utilisations extérieures (clients, fournisseurs, nomades) une zone spéciale a été créée appelée DeMiliatry Zone (DMZ). Cette zone peut être découpée en deux groupes, les DMZ publiques qui sont accessibles depuis l extérieur et les DMZ privées qui contiennent les ressources et fonctionnalités importantes utilisées par les équipements de la DMZ publique. Les équipements des infrastructures techniques sont composés de l ensemble des équipements nécessaires au management et au maintien de l activité réseau (équipements réseau). Ces équipements vont constituer le support indispensables aux flux réseaux du SI. Ces différents types de trafic réseaux, témoins des échanges d information dans le SI, constituent également des classes d observations particulières (trafic réseau LAN, Trafic réseau entre le LAN et les DMZ, Trafic réseau entre le LAN et Internet, Trafic réseau entre les DMZ et Internet). Enfin les équipements impliqués dans le management, la détection et la configuration de la sécurité du système composent le groupe d équipements focalisé sur la sécurité. La différentiation des équipements, composants du SI, nous permet de définir les informations pertinentes à observer en fonction de la nature des équipements sur lesquels elles ont été collectées. La figure 4.9 présente les différentes informations observées en fonctions des PPOs définis dans la section ainsi que la nature des équipements. 4.7 Conclusion La détection comportementale d intrusion nécessite la modélisation au préalable d une référence des comportements normaux. Avant de modéliser cette référence, nous avons, dans ce chapitre, étudié les comportements génériques des différents acteurs du SI. Cette étape nous a permis de cibler les éléments à modéliser et de déterminer des points d observation indispensables à la détection d activités intrusives. Nous avons déterminé trois grandes classes d observation à prendre en compte autour des gains/pertes d accès, de privilège et d utilisation du SI. L étude de la démarche de l attaquant ainsi que de différentes variantes de scénarios a permis d affiner ces compteurs d observations et de sélectionner l ensemble des points de passage obligatoires de l attaquant dans les démarches d utilisateurs légitimes.

75 62 Conclusion Fig. 4.9 Sélection des indicateurs par PPOs et par nature d équipement

76 5 Corrélation et Reconnaissance d Anomalies Comportementales 5.1 Introduction Ce chapitre va présenter les différents éléments et processus utilisés pour la détection d intrusion comportementale appliquée à la vision globale. Plusieurs travaux de la littérature ont proposé différents modèles de détection d anomalies ; notre approche se différentie de ces méthodes par la nature des sources d observations (ensemble d évènements détectés par les composants du SI) et la volonté de modéliser les séquences d activités utilisateurs dans l ensemble du SI. Les méthodes d analyses comportementales se différentient des méthodes de détection classiques (par signature) par la construction d une référence (normale ou non) au préalable. Cette référence permettra par la suite la détection de comportements anormaux. Les méthodes de détection d anomalies classiques utilisent trois phases distinctes pour réaliser leurs analyses. Tout d abord une phase d apprentissage leur permet de créer un modèle de référence. C est dans une seconde phase d exploitation que ces moteurs d analyse vont comparer le modèle de référence aux nouvelles données et détecter des anomalies. Enfin, ces approches utilisent une dernière phase qui leur permet de mettre à jour leur modèle afin de suivre les évolutions du système observé ; cette phase sera appelée phase de contrôle dans la suite de notre document. L étude des comportements et des acteurs du SI définie dans le chapitre 4 a permis de délimiter le cadre d étude de notre analyse comportementale et les données essentielles à surveiller pour la modélisation des comportements des utilisateurs du système. 63

77 64 Choix du Modèle La section 5.2 va présenter les différentes méthodes de modélisation utilisées dans les systèmes de détection d anomalies et expliquer le choix du modèle retenu pour la modélisation des comportements utilisateurs. Nous présenterons également dans cette section un bref aperçu des différentes approches dans la détection d intrusion qui utilisent le modèle choisi. Enfin, les trois phases de fonctionnement de notre moteur de détection d anomalies, Apprentissage, Exploitation, Contrôle, seront développées respectivement dans les sections 5.3, 5.6, 5.7. Dans la suite de ce chapitre nous utiliserons différentes notations permettant de présenter les étapes nécessaires à la construction de notre modèle de référence. Trois principaux types d objets seront manipulés : un graphe orienté d évènements noté G(S, E) un graphe orienté de catégories d évènements noté G (S, E ) un réseau Bayésien des interactions entre les catégories d évènements noté BN(G ) Les processus de traitement mis en oeuvre manipulent différents ensembles décrits dans le tableau 5.1. Ensemble Description A Ensemble des évènements collectés et normalisés. G Graphe d évènements. S Ensemble des sommets d un graphe d évènement G. E Ensemble des arcs d un graphe d évènement G. G Graphe de catégories d évènements. S Ensemble des sommets d un graphe de catégories d évènements G. E Ensemble des arcs d un graphe de catégories d évènements G. Tab. 5.1 Description des ensembles des objets utilisés 5.2 Choix du Modèle La modélisation des comportements à largement été couverte dans la littérature. De nombreuses méthodes de modélisation et d apprentissage peuvent être citées pour la définition de comportements usuels. Cependant, la modélisation des comportements d utilisateurs légitimes sur l ensemble du SI devra respecter des propriétés propres à notre problématique Propriétés Comme présenté dans le chapitre 4, les démarches des différents utilisateurs sont des séquences d évènements. La technique de modélisation utilisée doit permettre de modéliser des séquences d évènements et de surcroit permettre d identifier chaque classe d évènements. Chaque évènement est produit et réalisé par un utilisateur ou un processus unique. Afin de garantir la modélisation des comportements d un même utilisateur, il est indispensable de déterminer des relations d associations d évènements et d identifier chaque évènement non seulement par sa classe (normalisation de sa sémantique) mais également par des attributs identifiant l origine et l auteur de l action.

78 Corrélation et Reconnaissance d Anomalies Comportementales 65 De plus, les comportements des utilisateurs légitimes du système peuvent être assimilés à des systèmes dynamiques évoluant en permanence. Cette évolution constante fait apparaitre des éléments représentant des habitudes ou des actions isolées dans les démarches utilisateurs. Notre technique de modélisation doit être capable de différentier les habitudes des actions sporadiques. Enfin, la modélisation des comportements doit être lisible et interprétable par un humain. Les comportements d utilisateurs renferment des informations importantes sur l utilisation du SI et le respect des politiques de sécurité. L analyse de ces modèles par un expert va permettre de vérifier le respect des politiques de sécurité mises en place, elle lui offrira également la possibilité d ajuster le modèle, d éliminer les comportements qui lui semblent trop sporadiques et d ajouter des informations éventuelles sur des évolutions à venir des politiques de fonctionnement Les techniques de modélisation existantes Les approches de détection d anomalies comportementales utilisent des techniques de modélisation variées pour assurer la modélisation des comportements normaux qu ils souhaitent observer. Ces techniques qui répondent toutes à des problématiques différentes proposent néanmoins un panel de méthodes et de retours d expérience que nous avons étudié pour choisir notre technique de modélisation. Nous avons décliné ces techniques en sept classes présentées ci-après. Tout d abord, les réseaux de neurones ont particulièrement été exploités pour la modélisation de règles différentiant les flux réseaux normaux des flux divergeant. [57] utilise les réseaux de neurones afin d identifier les connections anormales aux réseaux du SI. Après une période d apprentissage contenant des connections identifiées comme normales et anormales, [57] entraine le réseau de neurones afin de classer de nouvelles connexions dans la classe appropriée. Le pouvoir de généralisation des réseaux de neurones permet de créer des règles de regroupement efficaces (dépendant du type de réseau de neurones utilisé). Cet outil est particulièrement adapté lorsque l on possède des données étiquetées (normales et anormales). Malheureusement les règles générées ne sont pas interprétables par un humain et elles ne permettent pas la modélisation de séquences. Les techniques de DataMining (ECD Extraction de Connaissances à partir de Données) offrent également des propriétés intéressantes en terme de généralisation de règles. Ces techniques ont pour objectif d extraire un savoir ou une connaissance d une grande masse d informations. En d autres termes, les méthodes de DataMining permettent de déceler des relations entre des données (corrélation d information) et de les regrouper suivant ces critères. De nombreuses méthodes sont utilisées pour permettre l extraction de ces connaissances (Machines à Support de Vecteur, k-means, Local Outlier Factor, différentes méthodes de regression, K-NN). [58] s appuie sur une modélisation des processus (clusterisation) et de leurs appels systèmes correspondant. Tout comme les réseaux de neurones (que certains considèrent également comme une méthode de DataMining), ces techniques de modélisation permettent la génération de règles génériques à l aide de données d apprentissage. Néanmoins ces techniques présentent l avantage d avoir une meilleure lisibilité des règles générées et peuvent également être utilisées pour détecter des éléments déviants rares. Associées à des modèles probabilistes, ces techniques peuvent également déterminer les regroupements les plus fréquents. Cependant, les techniques de DataMining ne permettent pas de représenter directement des séquences d évènements mais plus

79 66 Choix du Modèle des groupes d évènements. D autres approches se focalisent sur cet aspect en générant des séquences d évènements par le biais d automates d états. [59] a utilisé les automates d états afin de déterminer les séquences d appels systèmes utilisées habituellement dans les programmes. Cette technique de modélisation lui permet de définir des séquences d appels systèmes comprenant un état de départ, un état d arrivée et des boucles possibles au sein de la séquence. L utilisation d automates d états est bien adaptée pour la modélisation de séquences. Chaque noeud ne représentant qu un seul et même état, les graphes générés pour la modélisation complète d une séquence peuvent vite atteindre des tailles non lisibles par un analyste. De plus, les automates d états ne permettent pas de déterminer les chemins les plus probables au sein du graphe généré. Les Réseaux de Pétri (RdP) permettent de modéliser des séquences d actions ou/et d états. Ces RdP permettent de modéliser aussi bien des comportements de systèmes dynamiques que des évènements discrets. Cette approche réalise une description des relations existantes entre des conditions et des évènements. [20] utilise les arbres de fautes et les réseaux de Pétri colorés pour créer, générer (arbres de fautes) et représenter (RdP) des scénarios d attaques. Les réseaux de Pétri colorés permettent d identifier l ensemble des états et des actions nécessaires à la réalisation d un scénario d attaques. Cette modélisation permet de décrire des séquences d actions et l ajout de la coloration permet de différentier les différents évènements indépendamment des uns des autres. Les réseaux de Petri colorés ne permettent pas de déterminer des séquences de chemins les plus probables. Les réseaux de Pétri stochastiques constituent cependant une alternative pour l ajout de probabilités dans les chemins des graphes générés. Les probabilités de séquences d actions constituent une problématique récurrente dans la modélisation de comportement normaux. Les chaines de Markov et les chaines de Markov cachées (Hidden Markov Model HMM) sont particulièrement adaptées pour cette représentation. [60] a utilisé les chaines de Markov pour modéliser les séquences de commandes utilisées par les utilisateurs. Dans cette approche, un graphe de chaine de Markov est utilisé pour représenter chaque utilisateur. [61] a utilisé les chaines de Markov dans une directive similaire pour modéliser des séquences d appels système réalisées par les utilisateurs. Si un utilisateur effectue une succession d appels système peu fréquente alors son activité sera considérée comme anormale. [62] modélise les processus de traitement des paquets de flux TCP par des HMMs et utilise cette modélisation afin de classer les nouveaux flux TCP et de détecter d éventuelles anomalies. Les chaines de Markov sont adaptées pour modéliser des séquences d évènements et déterminer leur probabilité. Néanmoins, chaque noeud représente un état observé. L étude de systèmes complexes peut aboutir à la création de graphes complexes. Enfin, les réseaux Bayésiens constituent la dernière classe de méthodes de modélisation de comportements normaux. Les réseaux Bayésiens sont des modèles probabilistes graphiques permettant d acquérir, de capitaliser et d exploiter des connaissances. S appuyant sur la loi de Bayes, les réseaux Bayésiens permettent de calculer l ensemble des probabilités conditionnelles des variables des noeuds qui le composent. Nous présenterons plus en détail dans la section suivante le fonctionnement des réseaux Bayésiens. [63, 13], par exemple, exploitent les réseaux Bayésiens afin de modéliser respectivement

80 Corrélation et Reconnaissance d Anomalies Comportementales 67 les probabilités conditionnelles de liens entre des données d audit et des groupes de proxylet 1 différentiés par leur utilisation de la mémoire et du processeur. Tout comme les chaines de Markov et les réseaux de Petri stochastiques, les réseaux Bayésiens permettent de modéliser parfaitement les séquences d évènements ou des groupes de propriétés. Les réseaux Bayésiens modélisent les probabilités des différentes séquences d évènements en se différentiant des chaines de Markov par la représentation de plusieurs états d une variable sur un même noeud du graphe. Afin de répondre à nos propriétés définies dans la section 5.2.1, trois techniques de modélisation se distinguent, les réseaux de Petri stochastiques, les chaines de Markov et les réseaux Bayésiens. Les Chaines de Markov ainsi que les réseaux de Petri stochastiques peuvent modéliser parfaitement des séquences d évènements et associer des probabilités à chaque chemin. Dans ces deux méthodes, chaque noeud modélisé dans une séquence représentera un état ou un évènement unique. L utilisation de telles modélisations pour l observation globale des comportements utilisateurs peut aboutir à la génération de larges graphes complexes. Les réseaux Bayésiens, pour leur part, permettent de catalyser plusieurs éléments différents sur un même noeud et de ce fait réduire le graphe généré. De plus, la détermination des probabilités conditionnelles de chaque état de chaque noeud offre une précision de modélisation supplémentaire. Néanmoins les réseaux Bayésiens présentent certaines limites pour la modélisation de séquences d évènements, particulièrement dues à la génération unique de graphe acyclique. Afin de modéliser les comportements des utilisateurs du SI, nous avons choisi les réseaux Bayésiens pour leur qualité de représentation des séquences et également pour leur concentration de connaissances. Avec une optimisation de l inférence de probabilités, les réseaux Bayésiens faciliteront la détection d anomalies par l ajout de preuves au sein du réseau. Les difficultés de modélisation des cycles au sein des comportements seront explicitées dans les parties suivantes Introduction aux réseaux Bayésiens La plupart des problèmes posés s articulent autour de questions visant à lever des incertitudes. Quel temps va-t-il faire demain? Pouvons-nous affirmer qu une feuille est verte?... [64] présente cette notion d incertitude suivant deux axes : intensionnelle (qui ne satisfait pas à toutes les propriétés énoncées dans un domaine conceptuel) et extensionnelle (qui satisfait à toutes les propriétés énoncées dans un domaine conceptuel). Les systèmes extensionnels (aussi appelés systèmes à base de règles) sont généralement rapides et efficaces mais leur mesure de l incertitude est pauvre sémantiquement. Les systèmes intensionnels pour leur part utilisent des algorithmes lents et complexes mais possèdent une sémantique forte. Dans les domaines probabilistes, les variables aléatoires sont utilisées pour représenter les évènements ainsi que les objets du monde. En assignant des valeurs à ces variables aléatoires, il est possible de modéliser l état courant d un monde et d attribuer des poids aux états en fonction de leurs probabilités conjointes. Plusieurs modèles probabilistes ont été proposés dans la littérature, mais si l on se focalise ici sur les probabilités, les représentations de Réseaux Bayésiens (Bayesian Network BN), de Logique floue, et de chaines de Markov Cachées constituent les modèles les plus appropriés. 1 Petits fragments de code installés sur un Open Pluggable Edge Service - OPES

81 68 Choix du Modèle Les Réseaux Bayésiens sont les plus adaptés à la représentation des influences relatives parmi les faits du monde réel. C est pourquoi ils sont beaucoup utilisés tout particulièrement dans la représentation de l incertitude. On peut trouver plusieurs définitions des réseaux Bayésiens dans la littérature qui dépendent des orientations du domaine d étude : Un système expert à base de connaissance, Un graphe d états contenant des probabilités conditionnelles, Un modèle probabiliste graphique, Quelque soit la définition utilisée, les Réseaux Bayésiens sont des graphes acycliques orientés où chaque noeud représente une variable et chaque arc des probabilités conditionnelles liant ces variables. Les BN utilisent la loi initiale de Bayes 2 pour déterminer les probabilités conditionnelles. La définition présente le théorème de Bayes à savoir la probabilité d observer A sachant B. Définition La probabilité de A sachant B est défini par : P (A B) = [65] définit plus précisément un réseau Bayésien par la définition : P (B A)P (A) P (B) Définition B = (G, θ) est un réseau Bayésien si G = (X, E) est un graphe acyclique orienté dont les sommets représentent un ensemble de variables aléatoires X = x 1,..., x n, et si θ i = [P (x i /x P a(xi))] est la matrice des probabilités conditionnelles du noeud i connaissant l état de ses parents P a (x i ) dans G. La distribution de probabilité admet la loi jointe suivante : Définition La distribution de probabilité sur X d un réseau Bayésien B est définie par : P (x 1, x 2,..., x n ) = n i=1 P (x i/x P a(xi)) Cette loi jointe permet au BN d inférer les probabilités et de déterminer les nouvelles probabilités des variables lors de l ajout de preuves dans le BN. L inférence correspond à la mise à jour de l ensemble des probabilités conditionnelles d un graphe Bayésien lors de l observation d une valeur d un état d un noeud ( preuve observée). Un réseau Bayésien permet, à l aide de graphes de causalité, d apporter des réponses à des incertitudes par la présentation de solutions vraisemblables (probabilité). Par exemple, si l on souhaite savoir pourquoi un arbre perd ces feuilles, deux causes sont possibles : à cause d une maladie ou à cause de l automne. La représentation graphique de BN résultant est présentée dans la figure 5.1. Chaque noeud du réseau porte plusieurs valeurs possibles de la variable modélisée. Tous les noeuds du réseau Bayésien vont également décrire les probabilités conditionnelles des valeurs de leurs variables. Dans le cas des noeuds Automne et Maladie les probabilités représentent les probabilités d apparition des phénomènes (pas de parents). Le noeuds perte, symbolisant la perte des feuilles d un arbre, va contenir l ensemble des probabilités conditionnelles relatives aux différentes causes possibles. La construction d un réseau Bayésien se distingue généralement en trois étapes : 2 Thomas Bayes

82 Corrélation et Reconnaissance d Anomalies Comportementales 69 Fig. 5.1 Exemple de Réseau Bayésien La définition de la structure du graphe, La définition des tables de probabilités, L inférence des probabilités, La structure du graphe des réseaux Bayésiens détermine les relations de causalité entre les évènements. Cette structure peut être soit construite par un expert qui définira les variables impliquées ainsi que leurs relations de causalité, soit automatiquement par des algorithmes d apprentissage. Plusieurs méthodes d apprentissage existent pour la recherche et création de structure des réseaux Bayésiens : Recherche de causalité (IC/PC, IC*/FCI) : Les méthodes de recherche de causalité consistent à construire un graphe initial non dirigé contenant les relations entre les variables (test d indépendance conditionnelle du χ 2 par exemple), à détecter des variables latentes et à détecter des V-structures (différents types de connexions orientées entre les variables). Recherche par calcul de score (entropie, AIC, BIC, MDL) : ces méthodes se focalisent sur le principe de rasoir d Occam 3 et tentent de trouver le modèle qui correspond le plus aux données étudiées et qui soit le plus simple possible. Ainsi tous les graphes construits sont évalués en fonction de ces deux critères. Le graphe final choisi est le graphe qui maximise ces propriétés. Parcours de Recherche (MWST,K2, EM) : ces approches s attachent à trouver le meilleur arbre passant par tous les noeuds, à savoir l arbre de recouvrement maximal. La définition des tables de probabilités peut être également créée de façon similaire, explicitement ou par apprentissage. Les algorithmes EM, par exemple, permettent d estimer les probabilités du graphe. Ces algorithmes alternent une étape de prévision (Expectation E) qui calcule une prévision de la probabilité en incluant des variables latentes, et une étape de Maximisation (M) qui maximise les probabilités attendues dans l étape E. Les paramètres trouvés dans l étape M sont ensuite utilisés pour commencer une autre étape E et le processus se répète. Des algorithmes tels que les algorithme d arbre de Jonction, les Loopy belid propagation ou encore les chaines de Monte Carlo permettent d optimiser l inférence des probabilités et de mettre à jour l ensemble des probabilités conditionnelles suite à l injection de preuves au sein 3 le principe du rasoir d Occam, du nom du franciscain d origine anglaise Guillame d Occam, stipule qu il ne faut pas multiplier les entités sans nécessité. C est-à-dire qu il est inutile de chercher une explication ou méthode complexe, faisant appel à des principes hors du champ de l expérience, quand une explication simple, à partir de ce que nous connaissons déjà, suffit à rendre compte d un phénomène.

83 70 Choix du Modèle du réseau. Les réseaux Bayésiens sont des outils puissants de modélisation qui permettent, par la création de graphes de causalité, de déterminer l ensemble des probabilités conditionnelles des variables entre elles. La construction d un réseau Bayésien peut aussi bien être réalisée manuellement par un expert que par l utilisation d algorithmes d apprentissage pour la découverte de structure ou pour la détermination des tables de probabilités Les réseaux Bayésiens dans la détection d intrusion Les Réseaux Bayésiens (Bayesian Network BN) ont déjà été utilisés dans le contexte de détection d intrusion. Ainsi des mécanismes de détection d intrusion par signature [66], d analyse forensic [30, 26] et détection d anomalies [11, 63, 13] utilisent des BNs. [66] utilise les Réseaux Bayésiens afin de détecter des Dénis de Service Distribués. Le BN est automatiquement construit à l aide d un ensemble de données d apprentissage composé de flux réseaux normaux et de flux réseaux d attaques identifiées. Les auteurs utilisent un algorithme d apprentissage afin de déterminer la structure de leur réseau Bayésien et de leur permettre de détecter des connexions au réseau du SI déviantes. Chaque noeud du réseaux constitue une propriété du flux intercepté (type de protocole, durée, taux d erreur, service,...). L ensemble des données traitées dans cette approche est labelisé comme appartenant à un type d attaques ou non. Des noeuds représentant chaque type d attaques sont alors ajoutés au réseau globale. La période d apprentissage de cette approche va non seulement permettre l extraction de liens entre les propriétés mais également le calcul des probabilités conditionnelles de l ensemble des données du réseaux. Cette technique de classification est particulièrement adaptée lorsque des données normales et anormales sont disponibles et labélisées. Malheureusement, de telles données ne sont pas disponibles dans notre cas. [63, 13] proposent une classification d évènements, comme des données d audit numériques ou des proxylets 4. Ces approches utilisent les réseaux Bayésiens naïfs (un seul père et plusieurs fils ou inversement) afin de rattacher chaque évènement à un groupe. La construction de la structure du BN est faite explicitement et la période d apprentissage permet de déterminer l ensemble des probabilités. [13] par exemple va regrouper chaque proxylet en groupe autour de propriétés telles que la consommation mémoire et l usage du processeur. Dans ces approches les BNs sont utilisés d une façon similaire aux méthodes de DataMining par la clusterisation d information. Ces approches apportent, en plus des regroupements classiques des méthodes de DataMining, les probabilités particulières de chaque cluster. [11] utilise les réseaux Bayésiens d une manière différente en modélisant les séquences de commandes réalisées par chaque utilisateur. Les auteurs construisent, dans une période d apprentissage, les graphes de séquences de commandes de chaque utilisateur et déterminent la fréquence d utilisation de chacune d elles. Une fois le BN entrainé, les nouvelles séquences de commandes de l utilisateur sont évaluées, si les probabilités de séquences sont en dessous d un seuil alors la séquence de commandes est considérée comme anormale. [67, 30, 26] construisent des graphes causaux sur des évènements antérieurs afin de trouver l origine d une erreur ou d une attaque sur un Système d Information. La construction du 4 Petits fragments de code installés sur un Open Pluggable Edge Service - OPES

84 Corrélation et Reconnaissance d Anomalies Comportementales 71 graphe de causalité dans les analyses Forensic peut être réalisée soit explicitement par des expert du domaine, soit par apprentissage à l aide de données d enquêtes précédemment réalisées. Les relations entre les différents services, machines et attaques sont extraites, par l expert ou par apprentissage, pour définir la structure du BN. Les probabilités du BN sont souvent extraites d expériences précédentes et vont venir orienter la recherche de cause. Ainsi dans [30], les auteurs vont générer une structure de BN en utilisant un algorithme d apprentissage (k2), les différents noeuds du BN obtenu étant ensuite regroupés par catégories d informations comprenant le système cible (Targeted Hardware TH), les logiciels cibles (Apache par exemple), les dégâts observés (Défacement, DoS, Root privilège), les attaques génériques (Exploit, Usurpation), les actions complémentaires (suppression des données, installer un nouveau compte utilisateur,...), la source de l attaque ainsi que les techniques d investigation utilisées (NetLog, SysLog). Les nouvelles preuves collectées sont ensuite introduites dans le réseau Bayésien qui par inférence des probabilités conditionnelles indiquent les causes les plus probables d un fait. Les approches Forensic sont proches de notre problématique car elles adressent des modélisations de comportements globaux du système. La modélisation par Réseaux Bayésiens est appropriée pour la modélisation de comportements, mais la plupart des systèmes de détection d intrusion actuels ne sont pas adaptés à l observation globale d un Système d Information. Les approches Forensic proposent des méthodes de modélisation intéressantes pour l observation globale de faits post mortem. Nous nous sommes inspirés de ces approches pour la modélisation des comportements des utilisateurs du SI. 5.3 Apprentissage : Réalisation d un profil de comportement normal La phase d apprentissage met en oeuvre des processus permettant la construction d une référence décrivant les comportements normaux des utilisateurs du SI. Cet apprentissage va permettre à la phase d exploitation de bâtir un raisonnement en s appuyant sur les données et configurations apprises. La nature de l apprentissage dépend directement du type de raisonnement proposé par le moteur. Il existe cinq types de raisonnement en intelligence artificielle : raisonnement déductif : le raisonnement déductif ou logique peut se traduire par l enchainement de plusieurs règles définies au préalable, ainsi : si A est vrai et A B est vrai alors on en déduit que B est vrai. Procédé de pensée par lequel on conclut de propositions prises pour prémisses, à une proposition qui en résulte, en vertu des règles de la logique. Louise Bérubé, 1991 raisonnement inductif : le raisonnement inductif peut se traduire par la généralisation de règles apprises au préalable. Soit un ensemble d objets a, b, c, d,..., si une propriété P est vrai pour des objets a, b, c,... de l ensemble, on induit que P est vraie pour tout x de l ensemble. Opération intellectuelle par laquelle on étend à l ensemble d une classe, ou d un groupe, les propriétés et caractères observés sur un nombre limité de cas individuels. Louise Bérubé., raisonnement abductif : le raisonnement abductif permet d inférer les causes possibles à

85 72 Apprentissage : Réalisation d un profil de comportement normal partir des effets. On peut la définir comme une inférence plausible. Si B est vrai et A B est vrai alors on abduit que A est vrai. raisonnement par analogie : le raisonnement par analogie consiste à tirer une conséquence à partir de la définition de caractères communs. Faire une analogie entre deux situations, c est rechercher les similarités et différences. Par exemple, l analogie entre la foudre et une étincelle électrique : identité entre les deux phénomènes, découverte de Franklin. raisonnement par sens commun : le raisonnement de sens commun s appuie sur l expérience de l expert, sur la notion de bon jugement, plus que sur la logique (notion d heuristique). Comme défini dans la section 5.2.3, la première étape de la modélisation des comportements utilisateurs par un modèle Bayésien consiste à construire la structure du réseau. Cette construction est semi automatique et guidée par la spécification de règles de regroupement (section 5.3.1). Une fois la structure créée à l aide des règles et entrainée par des données d apprentissage (section 5.3.2, 5.3.3), notre moteur de détection va déceler des comportements d utilisateurs déviants. La nature de notre moteur est déductif (mise en place de règles logiques pour la construction de la structure du BN), abductif (prise en considération des éléments manquants dans un scénario) et par analogie (comparaison des similitudes des scénarios appris avec les scénarios ou alertes découverts). La phase d apprentissage devra mettre en oeuvre les mécanismes permettant la réalisation des raisonnements utilisés et de répondre aux questions : Apprendre, oui mais à partir de quoi? De quelles informations dispose-t-on? Règles de regroupement L utilisation des réseaux Bayésiens comme méthode de modélisation est souvent associée à de l apprentissage non supervisé de structure à l aide d algorithmes tels que l algorithme k2. Dans notre étude, nous n utiliserons pas ces algorithmes à proprement parlé. La principale raison repose sur le fait que notre étude analyse des évènements provenant de l ensemble du système qui comportent de nombreuses variables. Sans orientation de l apprentissage, notre structure risque fortement de rapprocher des évènements qui dépendent de causes complètement différentes. L étude des démarches des différents utilisateurs du SI (section chapitre 4) nous a permis d orienter l apprentissage de la structure de notre réseau Bayésien. La création de cette structure est réalisée à partir d un graphe de séquences d interactions Utilisateurs-Système. Ce graphe est composé de noeuds et de liens où chaque lien va représenter une relation de causalité entre les noeuds. Un lien entre deux noeuds est déterminé à partir de règles qui définissent des conditions particulières liant certains attributs spécifiques des noeuds (appelés connecteurs). Avant de détailler notre choix, il est utile de rappeler le contexte d étude ainsi que les différents attributs associés à chaque évènement. Tout d abord nos séquences portent sur des évènements normalisés provenant du Système d Information. Ces évènements sont au format IDMEF et possèdent leur Classification Text (champ de labelisation d un évènement du format IDMEF) normalisé au travers de l ontologie [53] (voir chapitre 3). Le format IDMEF offre la possibilité de spécifier de nombreux attributs de contexte permettant d enrichir l information portée par chaque évènement. Les principaux attributs sont portés

86 Corrélation et Reconnaissance d Anomalies Comportementales 73 par les sous-classes d Alert d IDMEF telles que Source et Target. Comme rappelé dans la section 3.3.1, chacune de ces sous-classes contient des attributs permettant d identifier la source et la destination d un évènement observé sur le SI. Ces classes contiennent des informations aussi variées que le noeud, l utilisateur, le processus, le service, les listes de fichiers etc... Pour modéliser les enchainements d évènements d un même utilisateur, nous nous sommes focalisés sur les démarches des différents utilisateurs du SI définies dans le chapitre 4. Le premier choix de nos connecteurs a porté sur des paramètres d un évènement permettant d identifier un utilisateur. Classiquement un utilisateur est identifié par son nom d utilisateur (Login) et/ou par son adresse IP source. Le nom d utilisateur est un identifiant unique d un utilisateur sur le SI qui est généralement associé à un groupe et à des droits particuliers. Ce paramètre n est malheureusement pas toujours présent dans les attributs des évènements collectés. L association d un Login à une adresse IP permet généralement d identifier l auteur d un évènement. D autres paramètres tels que l adresse MAC 5 (identifiant unique des cartes réseaux utilisées) peuvent également enrichir cette identification. Néanmoins les évènements transitant dans plusieurs réseaux et sous-réseaux différents ne possèdent pas nécessairement l adresse MAC source de leur émission, mais l adresse MAC des équipements les ayant retransmis. L utilisation de ces deux attributs va permettre de suivre l activité d un utilisateur sur un même composant du SI (poste de travail, serveur). Cependant un utilisateur peut être amené à effectuer des actions sur des ressources ou des services distants et à effectuer des rebonds pour y parvenir. Afin de suivre les mouvements d un utilisateur, notre modèle doit être capable de modéliser ces rebonds. Pour cela, nous allons utilisé l adresse IP source ainsi que l adresse IP destination pour suivre ce mouvement. En effet, dans le cas d un rebond, l adresse IP destination d un utilisateur devient l adresse source d une action effectuée sur un serveur distant (figure 5.2). Fig. 5.2 Rebond d un utilisateur Un autre type de mouvement peut être réalisé par un utilisateur ; un utilisateur peut physiquement se déplacer d un poste à un autre et donc changer d adresse comme source d évènements. Pour suivre ce déplacement seul l attribut Login peut être utilisé. Grâce à ces trois informations, l adresse IP source, l adresse IP destination et le login utilisateur, il est possible de suivre le comportement d un utilisateur dans le Système d Information. Ces trois informations constituent nos connecteurs permettant de lier les évènements (actions au travers des alertes) au sein de séquences (scénarios d usage). Les différents connecteurs utilisés pour la construction du graphe sont : Adresse IP Source, Adresse IP Destination, 5 Media Access Control address

87 74 Apprentissage : Réalisation d un profil de comportement normal Login User. Ces connecteurs constituent les variables de base des liens entre les activités d un utilisateur. Des règles utilisent ces connecteurs afin de déterminer les conditions nécessaires pour que deux évènements différents soient liés. Ces règles simples reflétent les étapes de traçabilité des actions de l utilisateur. Soit deux évènements A et B, A plus récent que B, A et B sont reliés entre eux tels que A B si et seulement si au moins une des trois règles est vérifiée : Adresse IP source de A est égale à Adresse IP source de B, Login User de A est égale à Login user de B, Adresse IP Destination de A est égale à Adresse source de B. La construction du graphe de séquences d évènements ainsi que l utilisation des règles de liaisons sont plus formellement décrites dans la section Graphe d activités des utilisateurs Nos travaux se sont focalisés sur les interactions entre le Système d Information et les utilisateurs. En collectant les informations provenant des agents déployés, notre algorithme modélise les interactions utilisateurs. L algorithme ci-dessous décrit la création de la structure du réseau Bayésien. Ce dernier est construit à partir des évènements (management et sécurité) provenant du Système d Information. Ces évènements sont structurés par le modèle de données IDMEF (Intrusion Detection Message Exchange Format), décrit dans [52]. L objectif d IDMEF est de définir le format des données ainsi que les procédures d échange afin de partager de l information dans le contexte de la détection d intrusion et des contre-mesures. Chaque évènement est composé de différents attributs tels que l adresse source, l adresse destination, le Classification Text etc. Les attributs Classification Text (champ de labelisation d un évènement du format IDMEF) sont normalisés. Dans notre cas, un sous-ensemble d attributs basés sur la démarche utilisateur est utilisé (voir section 5.3.1). Soit A un ensemble d évènements chronologiquement ordonnées a 0, a 1, a 2,..., a N 1. Cinq attributs IDMEF sont utilisés : att CT est l attribut Classification Text, att DT est l attribut représentant le Temps de Détection, att SIP est l attribut de l adresse IP Source, att DIP est l attribut de l adresse IP Destination, att L est l attribut de Login. Ici a i.att Name représente la valeur de l attribut de l évènement a i tel que : Name {att CT, att DT, att SIP, att DIP, att L } Dans cette section, un algorithme est utilisé afin de créer un graphe orienté qui contiendra l ensemble des évènements reflètant les activités utilisateurs. Dans ce graphe, chaque noeud représente un évènement et chaque arc décrit la relation entre deux évènements. Cette relation est basée sur la corrélation (noté " ") et est définie comme suit : Définition L évènement a i est corrélé à l évènement a j, noté a i a j, a i, a j A A, a i a j ssi (Card(Evaluation(a i, a j )) 1) (a i.att DT < a j.att DT )

88 Corrélation et Reconnaissance d Anomalies Comportementales 75 Où Evaluation(a i, a j ) est une fonction retournant un sous-ensemble de l ensemble {SIP, DIP, L} calculé en utilisant les règles suivantes : si a i.att SIP = a j.att SIP (ex : les évènements provenant de la même adresse source) alors SIP Evaluation(a i, a j ). si a i.att DIP = a j.att SIP (ex : l adresse destination d un évènement devient l adresse source d une autre) alors DIP Evaluation(a i, a j ). si a i.att L = a j.att L (ex : les évènements possédant le même "Login") alors L Evaluation(a i, a j ). Fig. 5.3 Exemple de corrélation d évènements La figure 5.3 présente la corrélation de deux évènements. Evaluation(a 1, a 2 ) = L car a i.att DT < a j.att DT et la troisième règle de la définition de la corrélation est validée. Ainsi a i est corrélée à a j : (a i a j ). Cette définition de la corrélation est proche de celle de [68] : dans cette approche, chaque évènement est associé à des pré-conditions et des post-conditions. Ces prédicats décrivent les états du système avant (pré-condition) et après (post-condition) l apparition d un évènement. Ces prédicats sont composés d attributs. Deux évènements sont corrélés si un possède une postcondition identique à une pré-condition d un autre évènement et si un des attributs de ces prédicats est identique. Le mécanisme de prédicats permet de générer des règles de connexion entre chaque évènement. Malheureusement, la description de chaque prédicat de chaque évènement requière beaucoup de temps ainsi que la connaissance de toutes les causes et conséquences de chaque évènement. N utilisant pas ce mécanisme à base de prédicats, notre définition de la corrélation est plus générique et fournit une plus grande flexibilité. La complexité des algorithmes est plus faible et un plus grand nombre de liens est généré. Par ailleurs, notre méthode ne nécessite pas de phase importante de pré-traitement consistant à décrire tous les prédicats de chaque alerte. Le mécanisme de corrélation est maintenant utilisé afin de créer un graphe de corrélation d évènements. Ce graphe est utilisé dans le prochain paragraphe afin de construire la structure d un réseau Bayésien. Le graphe de corrélation d évènements est défini comme suit : Définition Soit G(S, E) un graphe tel que chaque sommet s i S correspond à un évènement unique a i A et E = (s {(a i,s j) S S i, a j ) a i a j }. Chaque sommet s S héritera des attributs de son évènement correspondant a A. Les sommets et les arcs du graphe sont respectivement étiquetés avec le nom de l évènement correspondant pour les noeuds et avec e.rules = Evaluation(a i, a j ) pour un arc e = (s i, s j ). A cette étape, chaque évènement et ces interactions sont représentés dans le graphe construit G(S, E). Un grand Système d Information peut produire plusieurs milliers d évènements par

89 76 Apprentissage : Réalisation d un profil de comportement normal seconde et le graphe résultant d une journée d évènements comporte environ huit millions de noeuds. Le graphe généré est trop complexe pour être facilement manipulable (temps de détection, création du Réseau Bayésien). Le processus de fusion, défini dans la section suivante, réalise une réduction du graphe significative permettant la construction du réseau Bayésien de référence Modélisation des profils utilisateurs par Réseaux Bayésiens Pour finaliser la construction du Réseau Bayésien, un ensemble de données d apprentissage composé d évènements journaliers est utilisé. Ces données d apprentissage sont utilisées à la fois pour construire la structure de notre Réseau Bayésien et pour le calcul des probabilités conditionnelles. Le graphe d activité des utilisateurs G fourni par la corrélation conjointes des évènements, trop large et trop fortement maillé, ne permet pas la réalisation d une structure d un BN efficace. Le paragraphe suivant va présenter le processus de fusion permettant de transformer un graphe G(S, E) en graphe réduit G (S, E ). Dès cette transformation effectuée, le réseau Bayésien de référence pourra être construit. a) Fusion du graphe d évènements G(S, E) Une étape de réduction et de simplification du graphe est nécessaire pour adapter G à une structure de graphe BN plus souple. Cette étape consiste à fusionner tous les mêmes types d évènements (même Classification Text ) au travers d un processus de contraction de graphe. Notre processus de fusion utilise la contraction de noeuds qui est une variante de la contraction d arc définie dans [69]. La contraction d une pair de sommets s i et s j du graphe G 1 (noté Contraction(G, s i, s j )) produit un graphe G 2 dans lequel les deux sommets s 1 et s 2 sont remplacés par un sommet s unique tel que s est adjacent aux voisins des sommets desquels s 1 et s 2 étaient originellement adjacents. Dans la contraction de sommet, il n y a pas d importance si s 1 et s 2 sont connectés par un arc ; si tel est le cas, cet arc est simplement supprimé par la contraction. Afin de ne pas perdre les informations des évènements fusionnés, les informations sont conservées sur le graphe G. Concernant le noeud s, contraction de s i, s j, ce dernier est défini tel que : s.att SIP = s i.att SIP s j.att SIP, s.att DIP = s i.att DIP s j.att DIP, s.att L = s i.att L s j.att L, s.att CT = s i.att CT = s j.att CT sinon la contraction n a pas de sens, s.att DT = s j.att DT s i.att DT < s j.att DT. De même, l information portée par les arcs du graphe G(S, E) devra être conservée pour tout s i et s j contracté possédant un prédécesseur ou successeur commun x tel que : Soit e i = (x, s i ) et e j = (x, s j ) e i, e j E de G(S, E),e.rules = e i.rules e j.rules Notre processus de fusion contracte les sommets correspondant aux évènements ayant un même Classification Text. L ordre de la contraction n a pas d importance, la contraction arc/sommet respecte la propriété de commutativité. Notre processus de fusion qui transforme

90 Corrélation et Reconnaissance d Anomalies Comportementales 77 un graphe d évènements G(S, E) en graphe de catégorie d évènements G (S, E ) est défini comme suit : Algorithm 1 Algorihtme de fusion : Fusion(Graphe d évènements G(S, E)) Hypothèses Considérons les sommets S comme étant stockés dans une liste chainée L, les sommets étant ordonnés par date croissante (le champ att DT ). s 1 = P remier(l) Tant que s 1 nil Faire temps 1 = s 1.suivant s 2 = temps 1 contract = faux Tant que contract ET s 2 nil Faire Si s 1.att CT = s 2.att CT Alors contract = V RAI G = Contraction(G, s i, s j ) (cohérent avec l ordre des dates croissantes) s 2 = s (résultat de la contraction) s 1 est supprimé de L Sinon s 2 = s 2.suivant Fin Si Fin Tant que s 1 = temps 1 Fin Tant que Le graphe résultant du processus de fusion, noté G, refléte les tendances des activités de chaque utilisateur sur l ensemble du SI. Grâce au regroupement des évènements par leur signification (même sémantique), le graphe obtenu va refléter les différentes successions de types d actions d un utilisateur sur le Système. Ce graphe constitue la base de la structure de notre réseau Bayésien. b) Création du réseau Bayésien de référence BN Notre Réseau Bayésien (BN) décrit toutes les interactions utilisateurs possibles et évalue les probabilités de chaque situation. Le BN dont la structure repose sur G (S, E ) est composé de plusieurs types de noeuds différents. Nous appellerons noeud d Alerte de fusion (noté an) tout noeud représentant une catégorie d évènement. Les différents états de ce noeud correspondent chacun aux couples d attributs adresse IP source et Login utilisateur du sommet de cette catégorie. Chaque noeud an correspond à un sommet s S du graphe G (S, E ) et les états de ce noeud correspondent aux couple de valeurs de s.att SIP et s.att L. Chaque lien e E du graphe G (S, E ) est représenté par un noeud particulier dans le réseau Bayésien appelé noeud de Lien (noté ln). Chaque état de ln correspond aux types de règles de corrélation utilisés pour lier deux catégories d évènements à savoir {SIP, DIP, L} : SIP : les deux catégories d évènements possèdent une adresse IP source identique, DIP : l adresse IP destination de la première catégorie correspond à l adresse IP source de la seconde, L : les deux catégories d évènements possèdent un login utilisateur identique.

91 78 Apprentissage : Réalisation d un profil de comportement normal Ainsi tout élément s i, s j S et e E tel que e = (s i, s j ) sera représenté dans le BN par la séquence de noeuds an i, ln et an j liés comme précisé dans la figure 5.4. Fig. 5.4 Correspondance entre le graphe G (S, E ) et le réseau Bayésien de référence BN(G ). Note : les noeuds an possèdent plusieurs couples de valeurs issues de s Le réseau Bayésien de référence sera noté BN(G ).Après la création du BN, les probabilités conditionnelles sont calculées afin de compléter le BN. L ensemble des données d apprentissage est utilisé pour calculer ces probabilités. Ces données sont réorganisées afin de correspondre à la structure du BN créé. Dans notre cas, nous utilisons l algorithme counter-learning [70] afin de calculer les probabilités conditionnelles Gestion des cycles dans la structure de base du réseau Bayésien Le graphe fourni par G peut être en désaccord avec les propriétés d un réseau Bayésien en particulier en ce qui concerne la nature acyclique du graphe d un BN. Les activités des utilisateurs peuvent évidement inclure des cycles qui sont présents dans le graphe G. Les mécanismes traditionnels d inférence utilisés dans les BN interdisent toute présence de boucle dans le graphe de structure du BN. Deux familles d approches récentes se distinguent tout de même pour lever cette contrainte. Tout d abord, bien que la plupart des mécanismes d inférence des BN prohibent la présence de boucle au sein du graphe initial, des mécanismes d inférence de propagation de cycle ont été proposés dès 1997 [71]. La principale difficulté d inférence de probabilités (propagation des probabilités) lors de l utilisation de graphe avec des cycles vient du fait que les cycles vont générer une boucle de propagation des probabilités. Ces boucles vont constamment modifier les probabilités des états des noeuds impliqués dans l inférence (figure 5.5). Plusieurs algorithmes sont apparus proposant une inférence tolérante aux cycles. Parmi eux, on peut citer [72, 73] qui proposent des mécanisme d inférence de probabilité acceptant des cycles en proposant une convergence de la propagation des probabilités (état stable de chaque probabilité du réseau). Plus récemment, [74] a proposé une amélioration de l algorithme "Bethe free energy" 6 afin d optimiser la convergence de cette solution. D autres approches telles que [75] proposent une transformation du graphe Bayésien initial pour tolérer des graphes cycliques. Cette famille d approche nommée Réseau Bayésiens Aplatis (RBA) décompose chaque dépendance multiple des variables par l ajout de variables additionnelles (figure 5.6). Ainsi, un arc reliant un noeud A et un noeud B est modélisé par 6 Algorithme définit par Hans Bethe en L approximation de Bathe définit la perte d énergie par ionisation de particules chargées. Ce principe a été repris notamment dans l inférence des réseaux Bayésiens afin d exprimer la perte progressive d influence de l inférence d une probabilité dans un graphe cyclique.

92 Corrélation et Reconnaissance d Anomalies Comportementales 79 Fig. 5.5 Propagation de probabilité dans un graphe cyclique une variable booléenne artificiellement observée. Ces variables booléennes introduites sur les relations de dépendances permettent de conserver la présence de cycles dans le graphe initiale. Fig. 5.6 Exemple de changement de représentation Bien que ces approches permettent efficacement de modéliser les cycles dans le graphe initial d un BN, l introduction de variables supplémentaires peut grandement complexifier un BN comportant de nombreux noeuds ainsi que de nombreux liens. Malgré des temps de propagation de probabilité plus lents pour obtenir une convergence des probabilités du réseau, les méthodes d inférences tolérantes aux cycles semblent plus adaptées à notre problématique. Malheureusement, les logiciels Bayésiens actuels ne supportent pas encore ce type de méthodes. Conscient de cette contrainte technique, nous avons pris le parti de transformer le graphe orienté cyclique G(S, E ) en graphe acyclique tout en conservant l information de cycle. Nous avons défini une règle de gestion de cycle spécifique. Lorsqu un cycle apparait dans G, au lieu de créer un arc au sommet, nous créons un sommet particulier auquel correspond un nouveau noeud appelé noeud de cycle dans le réseau Bayésien de référence BN(G ). Après cette modification, dès qu un nouveau cycle apparait dans G sur ce même sommet, un arc est créé dans la direction du sommet de cycle correspondant. Le réseau Bayésien correspondant décrit l ensemble des probabilités d enchainement des catégories d évènements. Ces séquences de catégories d évènements vont représenter l ensemble des séquences d actions utilisateurs non répétitives. Les informations contenues dans les noeuds de cycle nous permettrons tout de même

93 80 Apprentissage : Réalisation d un profil de comportement normal de vérifier la position des cycles de séquences. Ce type de noeud va permettre de nous renseigner sur la probabilité que possède une séquence de boucler sur elle-même. Fig. 5.7 Transformation du graphe cyclique en graphe acyclique La figure 5.7 illustre notre transformation de graphe permettant de transposer un graphe cyclique en un graphe acyclique. Toute présence de cycle sera représentée par un noeud puits symbolisant la présence de boucle dans le graphe. Lors de la phase de détection, décrite en détail dans la section 5.6.3, chaque séquence détectée dans la fenêtre de détection sera évaluée, élément par élément dans le modèle Bayésien. Pour ce faire, les éléments d une séquence observée seront injectés un à un dans le modèle de référence. L inférence des probabilités des réseaux Bayésiens nous permettra alors de calculer la probabilité de l élément suivant de la séquence. En cas de boucle, notre modèle va permettre de calculer la probabilité de boucle en fonction des évènements préalablement injectés. Si la séquence analysée présente des cycles suivit d autres évènements (comme illustré dans la figure 5.8), l ensemble des éléments injectés préalablement sont retirés du modèle, et seule la séquence de la catégorie de l évènement boucle est injectée dans le modèle. Le test de la partie de la séquence de l évènement de boucle et des évènements suivants sera alors perçu comme une séquence indépendante. Fig. 5.8 Analyse des séquences présentant des cycles

94 Corrélation et Reconnaissance d Anomalies Comportementales 81 Cette gestion des cycles dans les réseaux Bayésiens reste une alternative propre à notre problématique qui nous permet d identifier la position des cycles dans des séquences de catégories d évènements. 5.4 Apprentissage : Enrichissement du modèle, Modélisation de la temporalité Notre modèle permet de décrire les différentes relations de causalité entre différents types d évènements réalisés par un utilisateur. Cette modélisation s appuie sur une fonction de corrélation permettant de lier deux évènements. Après avoir étudié et analysé différentes méthodes de corrélation, nous nous sommes aperçus que malgré l utilisation de techniques différentes, toutes ces méthodes soulignent l importance de la temporalité pour la corrélation de plusieurs évènements. Ainsi la notion de temporalité peut être sommaire et se cantonner à la description de précédence entre les évènements [68], ou plus complexe par la description de la durée des évènements et l ordonnancement de ceux-ci [76]. Dans tous les cas, modéliser la temporalité permet d enrichir les conditions de corrélation d évènements et par conséquent de définir plus finement les différentes séquences d évènements utilisateurs. L introduction ou l utilisation de temporalité suscite certaines problématiques d homogénéité des références temporelles. L utilisation d informations distribuées sur différents composants du SI introduit des problèmes de référence temporelle et de délais de propagation. Des approches telles que [77] et [38] ont proposé des mécanismes et architectures permettant de limiter les effets de telles contraintes. [38] propose une méthode d évaluation des délais de propagation et de compensation de ces délais par l ajout de temps flexible ( slack time ) aux différents évènements collectés. [77] a déterminé un ordonnancement local et global des évènements. S appuyant sur une horloge locale physique et une horloge virtuelle synchronisée au niveau global. Les auteurs déterminent l ordonnancement dans le temps global des différents évènements. Compte tenue de la tolérence du décalage temporel autorisé dans notre problématique (de l ordre de la seconde), chaque agent de notre approche récoltant les informations sur un composant du SI se synchronise (synchronisation faible ) sur le serveur d analyse central. Ainsi, l analyse des évènements peut utiliser l ordre des évènements pour bâtir des graphes d usage. Dans cette partie, nous allons présenter une extension de notre modélisation des comportements utilisateurs par la modélisation des dépendances temporelles inter-évènements Analyse des dépendances temporelles Bien que les mécanismes de corrélation traditionnels prennent en considération les informations temporelles, peu d entre eux décrivent précisément les contraintes temporelles. B. Morin [76] a défini un langage détaillé afin de corréler des séquences d évènements durant des fenêtres de temps appelées chroniques. L auteur définit une chronique comme étant une description de contraintes entre des évènements possédant un objectif commun. Ces contraintes constituent un ensemble de règles de corrélation fondées sur les attributs des évènements, les

95 82 Apprentissage : Enrichissement du modèle, Modélisation de la temporalité délais inter-évènements ainsi que la durée globale de la chronique (cette approche est plus détaillée au chapitre 6). Malgré une bonne description des dépendances temporelles, cette approche reste déterministe et explicite pour la description et définition de ces chroniques. [16] propose une approche explicite différente en représentant chaque évènement observé par des intervalles de temps. Dans cette approche, les auteurs utilisent l algèbre d Allen [78] afin de découvrir des relations entre ces intervalles de temps. Les évènements système observés sont représentés en trois couches hiérarchiques : une couche élémentaire events qui représente les évènements unitaires présents dans un journal d audit (exemples d events : login, debut consultation mail, fin consultation mail, logout), une couche actions qui représente une combinaison de plusieurs évènements de la couche events (ex : actions : mail{debut, f in consulation mail}), une couche activities qui représente une combinaison d actions (ex : activity sessions utilisateur {action mail1, action mail2, action Login Logout }). Cette description hiérarchique des évènements met en avant les relations entre les intervalles de temps des objets de chaque couche. Une fois les éléments du SI représentés, un apprentissage est effectué pour déterminer les intervalles de temps les plus probables pour la réalisation d actions ou d activités. Bien que ces travaux introduisent et décrivent les dépendances temporelles entre les évènements du SI, la description de chaque action et activité doit être définie explicitement ce qui nécessite l implication d une expertise humaine. Afin d exprimer convenablement les relations entre les évènements d un point de vue spatial (évènements partageant des mêmes attributs) et temporel (relations temporelles liant deux évènements) nous allons utiliser une sémantique particulière permettant d exprimer ces relations qui sera également reprise dans le chapitre 6. Plusieurs sémantiques ont été utilisées dans la littérature pour définir les règles de corrélation dans le temps et l espace. [37] propose une sémantique unifiée pour ces deux orientations. Les auteurs introduisent la notion d une sémantique décrivant des contraintes d intervalles de temps afin de définir les contraintes temporelles complexes parmi les évènements corrélés. Des considérations importantes comme la composition d opérateurs d évènements ont été définies. Les notions de conjonction, disjonction de séquences ou de restriction temporelle permettent une représentation complète des dépendances temporelles (voir table 5.10). Certains de ces opérateurs utilisent des conditions et contraintes temporelles entre les évènements qui seront détaillées par la suite et visibles dans la figure L introduction de la temporalité dans notre modèle permet d exprimer les activités utilisateurs par le biais d informations spatiales (attributs de évènements) et temporelles (durée inter-évènements) Besoins La modélisation des activités utilisateurs normales décrite dans la partie permet de définir les différentes relations de causalité entre les actions utilisateurs. Les règles de corrélation de deux évènements s articulent autour d attributs liés principalement à la localisation des évènements. La contrainte temporelle symbolisée par une règle de précédence simple entre deux

96 Corrélation et Reconnaissance d Anomalies Comportementales 83 Opération Sémantique Signification Conjonction A + B A et B se produisent dans n importe quel ordre. Disjonction A B A ou B se produisent. Concaténation AB A se produit avant B tels que A meet B et A overlaps B, A finishes B et A start B. Séquence A; B A se produit avant B tels que et A before B, A meet B. Concurrence A B A et B se produisent se produisent en parallèle. Itération A Toute occurrence de l évènement A (quelque soit le nombre de A). Négation A T Aucun A se produit dans l intervalle T. Sélection A N N occurrences de A. Restriction Spatiale A S A se produit uniquement si la restriction S est respectée. Restriction Temporelle A T A se produit dans l intervalle T. Tab. 5.2 Représentation des dépendances temporelles évènements peut être enrichie par la modélisation statistique des dépendances temporelles entre évènements corrélés. Suivant les principes de la théorie de l action et de la description des habitudes définies dans [79], les Humains réalisent des actions ou des séquences d actions de manière périodique. Nous avons pu corroborer ces faits en étudiant les relations temporelles entre une classe d actions et les différentes classes d actions corrélées à celles-ci. La figure 5.9 présente les différents intervalles de temps séparant une classe d évènement d utilisation d application et ses évènements corrélés. Ces évènements décrivent respectivement les classes de connexions d administrateur réussies/ échouées, de déconnections d administrateur et des évènements relatifs au redémarrage de service. L axe des abscisses de ce graphe correspond à la durée de l intervalle de temps séparant l évènement père (classe utilisation d application ) des évènements corrélés fils. Chaque pic des différentes courbes présentées dans cette figure représente un pic de fréquence de corrélation de deux évènements dans une fenêtre de temps précise. Dans cette figure, on peut distinguer aisément les différents cycles de corrélation des évènements dans des intervalles de temps donnés. Ces cycles représentent des durées régulières séparant deux évènements corrélés. Fig. 5.9 Représentation des intervalles de temps séparant des évènements corrélés ( d utilisation d application et ces fils)

97 84 Apprentissage : Enrichissement du modèle, Modélisation de la temporalité Fig Illustration des différentes dépendances temporelles La modélisation des durées inter-évènements permet de mettre en avant ces phénomènes et de décrire plus précisément les activités utilisateurs dans l espace et le temps. Cette modélisation plus précise caractérise également plus finement les comportements anormaux. Les relations temporelles vont être particulièrement utiles pour déceler des activités de robots au sein du système qui effectuent une succession de tâches suivant des périodes régulières Modélisation de la temporalité Lorsque l on considère la temporalité des évènements, plusieurs configurations possibles peuvent se produire au regard de la disposition des évènements dans le temps [37]. La figure 5.10 regroupe l ensemble des situations possibles. Dans notre cas d étude, des agents déployés sur les composants du SI vont collecter des évènements. Nous avons choisi de collecter les évènements comme Point-based (un évènement ne possède pas de durée) comme défini dans [37]. Bien que nos agents se resynchronisent, la notion de durée d évènements peut être assujettie à de nombreuses erreurs et imprécisions et complexifier grandement les relations entre évènements. La représentation des évènements par une durée nulle simplifiera le nombre de situations à modéliser (figure 5.10). Plusieurs approches ont été utilisées pour enrichir les réseaux Bayésiens par la description des relations temporelles. Ces solutions se distinguent en deux classes distinctes ; les réseaux Bayésiens dynamiques (Dynamic Bayesian Network DBN) et les réseaux probabilistes temporels (Temporal Functional Dependencies and Temporal Nodes Bayesian Networks TNBN). Les réseaux Bayésiens dynamiques offrent un large panel de méthodes permettant de modéliser une structure de réseau changeant dans le temps. Ces approches modélisent pour chaque fenêtre temporelle les relations d une structure de réseau à t 1 avec la structure de réseau à t. Dans la plupart de ces approches, les éléments (noeuds) de la structure de base sont identiques ainsi que les relations de causalité qui les lient. Les évolutions de structure dans le temps sont modélisées par des arcs liant des noeuds de la structure à t 1 avec les noeuds de la structure à t. La figure 5.11 illustre cette représentation. Les DBN permettent une modélisation complète des relations temporelles entre les différentes variables d un modèle. Néanmoins cette modélisation possède un coup élevé en terme de complexité et les intervalles de temps séparant plusieurs variables ne sont pas aisément perceptibles. Cette propriété est bien exploitée par les réseaux probabilistes temporels qui vont enrichir

98 Corrélation et Reconnaissance d Anomalies Comportementales 85 Fig Exemple de réseau Bayésien dynamique la sémantique des noeuds des réseaux Bayésiens par des notions de durées et précédences. Dans ce type de réseau, chaque noeud représente une variable, chaque valeur un état d une variable dans une fenêtre de temps donnée et chaque lien des relations causales et temporelles. Cette approche permet ainsi de spécifier les relations temporelles entre deux évènements ainsi que la probabilité que ces évènements soient liés dans une fenêtre temporelle spécifique. Pour modéliser les relations temporelles entre les évènements collectés, nous avons utilisé une approche similaire à [80] et introduit la notion de noeud temporel. Afin de rendre notre processus de modélisation le plus flexible possible, nous nous sommes différentiés de [80] par l introduction d un noeud temporel comprenant uniquement les intervalles de temps et indépendant des autres variables et de leurs états. Ce choix a été motivé par deux raisons principales. Tout d abord, nous avons souhaité fournir un système de modélisation modulaire permettant de bénéficier ou non de l extension de la temporalité. La concentration des états des variables et des intervalles temporels dans un seul et même noeud (comme stipulé dans [80]) ne permet pas cette modularité. De plus, utiliser un noeud unique limite grandement la visibilité du réseau Bayésien lorsque de nombreux intervalles de temps et d états d une variable sont présents. Ainsi, nous avons transformé chaque lien du graphe G (S, E ) initial en un noeud temporel, au sein du graphe Bayésien final, regroupant les intervalles de temps relatifs au temps de corrélation entre deux évènements. Nous définissons la notion d intervalle de temps entre deux évènements corrélés comme suit : Définition Soit a i, a j deux évènements correspondant aux sommet s i et s j, e = (s i, s j ) E (évènements corrélés par construction) on appelle intervalle de temps la valeur e.time telle que e.time = s j.att DT s i.att DT. Afin de concaténer ces informations dans le réseau Bayésien final, nous avons également complété notre processus de fusion. Le processus de fusion va transformer le graphe G(S, E) en G (S, E ). Définition Les informations d intervalles de temps sont conservées lors du processus de Fusion pour tout s i et s j contracté possédant un prédécesseur ou successeur commun x telles que : Soit e i = (x, s i ) et e j = (x, s j ) e i, e j E de G(S, E),e.time = e i.time e j.time Ainsi les arcs E du graphe fusionné G (S, E ) portent les informations relatives aux types de règles à l origine de chaque lien et l ensemble des intervalles de temps des éléments corrélés. Pour

99 86 Apprentissage : Enrichissement du modèle, Modélisation de la temporalité conserver ces informations temporelles dans le réseau Bayésien final BN(G ), un nouveau type de noeud est introduit, le noeud temporel. Ces noeuds vont fournir l ensemble des probabilités relatives aux intervalles de temps séparant la corrélation de deux évènements Construction des noeuds temporels Un noeud temporel est un noeud possédant comme état des intervalles de temps bornés (délimités par des frontières). Chaque état représente la probabilité que deux évènements soient corrélés durant un intervalle de temps. Afin de définir l intervalle de temps couvert par chaque état, nous avons utilisé l ensemble des informations portées par les arcs E et extrait des intervalles génériques recoupant au mieux les informations observées. Pour ce faire, les intervalles de temps observés contenus par les éléments de E sont regroupés en communauté. Notre problématique de création de communautés est un problème classique de classification de données. La première étape pour la classification des données consiste à lisser le corpus d apprentissage. Tout corpus d apprentissage comporte des exceptions représentées par des points déviants isolés. Afin de ne pas parasiter la classification de données, l ensemble de ces exceptions n est pas pris en compte. Nous avons utilisé le facteur local d éloignement (Local Outlier Factor LOF) pour identifier les points déviants. Les LOFs [81] permettent d assigner à chaque point un degré d éloignement par rapport à ces voisins en fonction de la densité locale de ceux-ci. Une fois chaque point pondéré, un seuil a été fixé afin de permettre l élimination des points déviants. L élimination des points possédant un LOF élevé permet ainsi de lisser le corpus de traitement. La plupart des techniques de classification automatiques d informations sont issues des domaines de reconnaissance de forme en imagerie ou du DataMining (Extraction des Connaissances à partir des données). Ces méthodes de classification sont généralement regroupées autour de deux familles : les classifications hiérarchiques et les classifications non hiérarchiques. D une part, les classifications non hiérarchiques créent à partir des points de départ un nombre n de classes de même niveau. Elles permettent de traiter des ensembles de points élevés en optimisant les critères discriminants (méthodes de nuée dynamique k-means, ou des moindres carrés less square ). Cette famille possède comme hypothèse initiale le nombre de classes que l on souhaite découvrir. Cette information n est pas disponible dans notre cas. D autre part, les approches de classifications hiérarchiques, quant à elles, permettent de créer un ensemble de partitions plus ou moins fines. Cette famille se compose de deux méthodes, les méthodes de division et d agglomération. Les méthodes de division consistent à construire des communautés à partir d une grande classe contenant tous les objets. A chaque étape, elles divisent une classe en deux classes plus petites jusqu à ce que les classes ne contiennent plus qu un seul élément. Ceci veut dire que pour N objets la hiérarchie est construite en N 1 étapes. Dans la première étape, les données sont divisées en deux classes au moyen des dissimilarités. Dans chaque étape suivante, la classe possédant l écart type le plus élevé se divise de façon similaire. L ensemble des objets sont séparés au bout de n 1 étapes. L algorithme peut être arrêté avant l obtention de classes unitaires en se basant sur des critères comme la distance minimale interclasse. A contrario, les méthodes agglomératives procédent par regroupement successif des points

100 Corrélation et Reconnaissance d Anomalies Comportementales 87 les plus proches les uns des autres. Ces regroupements forment des classes qui sont à leur tour regroupées avec les classes les plus proches et ce jusqu a ce qu une condition soit atteinte. Au regard de la consommation de ressources (mémoire, CPU) utilisée pour la construction de notre modèle, nous avons choisi la méthode agglomérative (dont l algorithme est défini dans l algorithme 2), plus rapide, afin de déterminer nos communautés de fenêtres temporelles. L algorithme d agglomération va utiliser plusieurs fonctions permettant respectivement de définir la distance entre deux points (noté δ(x, y)), de déterminer la distance minimale entre deux communautés (d min (C i, C j ) = Min{δ(x, y) x C i, y C j }) et de déterminer la distance minimum entre le barycentre d une communauté C i et un point d une communauté C j (noté d minorigine (C i, C j )). Algorithm 2 Algorihtme d Agglomération : AggFunct(Ensemble de points X, s, Seui1,Seuil2) Hypothèses La partition est composée initialement de singletons n : Nombre de singletons, s : Distance maximale à atteindre entre les partitions, C i = {x i } x X : chaque point représente une communauté de points, Répéter Choisir un couple C i, C j tels que : -d min (C i, C j ) = Min(d min (C l, C k )) C l, C k C et -d min (C i, C j ) < Seuil1 et -d minorigine (C i, C j ) < Seuil2 Fusionner C i et C j en une seule partition C i n := n 1 Jusqu à - n = 1 OU - Distance maximale entre les partitions atteintes s Min(d min (C l, C k )) OU - intervention manuelle Dans notre contexte d étude, chaque objet x représenté dans l algorithme 2 correspond à un intervalle de temps séparant deux catégories d évènements, à savoir un élément de e.time e E. Le présent algorithme permet de déterminer des groupes de durée d évènements corrélés. Ces groupes doivent être enrichis par des séparateurs (frontières) délimitant chaque communauté pour définir des intervalles de temps. Afin de prendre en compte les densités des différentes communautés, nous considérons qu une communauté possédant un faible nombre d éléments éloignés (LOF faible) possède des bornes proches du centre de gravité de la communauté alors que des communautés présentant un nombre élevé d éléments éloignés (LOF élevé) auront des bornes plus éloignées. Bien que des méthodes efficaces existent pour déterminer des frontières entre des communautés (Support Vector Machine), nous avons choisi d utiliser une méthode de calcul rapide compte tenu de la complexité (chaque intervalle de temps n est composé que d une variable). Nous avons donc combiné le LOF calculé au préalable de chaque point avec les distances intercommunautés. La moyenne des LOFs des points d une communautés permet de déterminer la proximité relative d une frontière et la distance inter-communautés détermine concrètement les frontières entre ces communautés. Ainsi, nous déterminons le LOF d une communauté C i composé de x n points comme suit :

101 88 Apprentissage : Enrichissement du modèle, Modélisation de la temporalité C i.lof = x j.lof C i x j C i (5.1) Les frontières séparant deux communautés C a et C b où C a < C b sont définies par : C a.lof f a = x a + d min (C a, C b ) ( C a.lof + C b.lof ) (5.2) Où x a est le plus proche élément de C b x a C a et d min (C a, C b ) est la distance minimale séparant C a de C b. Les figures 5.12 et 5.13 nous montrent un exemple de répartition des communautés et des LOFs de chaque point. Fig LOF de chaque point de chaque communauté symbolisant les intervalles de temps séparant les évènements de type "Application user" et "Admin Connected" Amélioration du processus de Modélisation Bien que l algorithme de classification agglomératif soit particulièrement approprié lorsque le nombre de communauté n est pas connu, des paramètres initiaux sont nécessaires pour déterminer efficacement des communautés. La distance minimale entre deux singletons (paramètre Seuil1) et la distance maximale entre un singleton et le centre d une communauté (paramètres Seuil2) sont à déterminer. Ces valeurs ne peuvent pas être définies apriori, elles doivent être ajustées pour chaque couple de catégories d évènements corrélés. Pour optimiser notre méthode de classification, nous avons proposé un moteur d algorithme génétique permettant de déterminer les couples de paramètres les plus appropriés pour la détermination de communautés. Plusieurs mécanismes peuvent être utilisés afin d optimiser des fonctions. Cependant, les algorithmes génétiques présentent comme caractéristique la détermination d optimums ou minimums globaux d une fonction sans connaissance au préalable de

102 Corrélation et Reconnaissance d Anomalies Comportementales 89 Fig Intervalles de temps déterminés par des communautés entre les évènements de type "Application user" et "Admin Connected" cette fonction. Basés sur la théorie de l évolution de Darwing, les paramètres recherchés, représentés comme des gènes d un individu, évoluent en vue d atteindre l optimum d une fonction. Pour ce faire, chaque individu (représentant un couple de paramètres Seuil1 et Seuil2 instanciés) est différentié par un processus d évaluation. Ce processus a comme objectif de trouver le meilleur ensemble d individus vis à vis des résultats attendus (fonction mathématique ou constat). Une fois chaque individu évalué, un processus de sélection distingue les individus candidats pour la création d une nouvelle génération assurée par le processus de reproduction. Durant cette reproduction, un processus aléatoire vient garantir la diversité de la nouvelle génération par la mutation de gènes de certains individus. Un algorithme génétique utilise quatre fonctions, évaluation, sélection, reproduction, mutation, pour sélectionner les paramètres optimaux. Ces quatre blocks basés sur une population initiale sont exécutés récursivement (suivant un nombre de cycles prédéfinis). Le processus d évaluation décrit les conditions qui déterminent la qualité d un individu. Dans notre cas de configuration, la population initiale est constituée de l ensemble des intervalles de temps séparant deux catégories d évènements corrélés contenu dans e E. La fonction d évaluation utilisée est un compromis entre deux critères. La moyenne de LOF (noté LOF ) qui décrit le degré d éléments potentiellement déviants au sein d une communauté constitue le premier critère. Plus le LOF d une communauté est bas, plus la communauté est représentative. Dans certain cas, une communauté possédant un LOF bas peut être disséminée sur une grande période de temps. Afin d éviter ces communautés monolithiques, les points d une communauté doivent être le plus proche possible de son barycentre. par : En considérant ces contraintes, la fonction d évaluation f(seuil1, Seuil2) peut être définie

103 90 Apprentissage : Enrichissement du modèle, Modélisation de la temporalité f(seuil1, Seuil2) = 1 K K 1/ LOF ( Max(distG(C i, x j )) ) x j C i (5.3) i=1 où LOF est la moyenne des LOFs d une communauté C (C étant obtenu par AggF ct (X, s, Seuil1,Seuil2)), K est le nombre de communauté, distg(c, x) est la distance entre un point x et le centre de gravité de sa communauté C. Le processus de sélection va supprimer la moitié de la population possédant l évaluation la plus basse. Après cette sélection, le processus de reproduction est lancé. Ce processus de reproduction combine les individus possédant l évaluation la plus haute aux individus possédant l évaluation la plus faible. Chaque reproduction crée deux nouveaux individus. Les gènes de ces nouveaux individus proviennent de la combinaison des gènes des deux parents. La combinaison de ces gènes est réalisée par une fonction de crossover 7 (croisement). Cette fonction va simplement échanger les parties des gènes des deux parents, le point d échange ou locus est défini aléatoirement. Durant ce processus de reproduction, un évènement peut modifier une partie d un gène d un fils. Cette évènement appelé mutation permet d éviter la convergence des individus vers un optimum local. Cet évènement aléatoire va inverser la valeur d un gène. En faisant cela, il garantit la diversité des individus créés. Nous avons réalisé plusieurs tests afin de trouver le couple de paramètres optimums pour notre algorithme agglomératif 2. Les tests ont été réalisés sur les informations temporelles des évènements de types utilisation d application et des évènements corrélées de connexions d administrateur réussies. La figure 5.14 nous présente l évolution de la population initiale convergeant vers un optimum global. Cette figure présente les cycles de l algorithme génétique de la population initiale (en haut à gauche) à la situation finale (en bas à droite). Les étapes intermédiaires peuvent se lire de la gauche vers la droite et de haut en bas. Nous pouvons voir l évolution de la population où les points (individus) convergent d abord vers des optimums locaux pour atteindre un optimum global. A la fin de cet algorithme, le meilleur individu est sélectionné. Les paramètres (gènes) de cet individu sont utilisés pour configurer notre algorithme agglomératif 2. Dès que toutes les frontières des intervalles de temps ont été calculées la construction des noeuds temporels (noté tn) au sein de notre réseau Bayésien est possible. Leurs états sont composés des différentes bornes des intervalles de temps calculés. Par l ajout d informations temporelles, notre modèle Bayésien est composé de trois types de noeuds : noeuds d Alerte de fusion (noté an), noeuds de liens (noté ln) et noeuds temporels (noté tn) composés d intervalles temporelles entre deux catégories d évènements corrélées. La figure 5.15 nous présente les noeuds temporels d un noeud utilisation d application et de ces fils. L ajout de temporalité dans la modélisation des comportements utilisateurs permet une modélisation plus précise des comportements et des éléments supplémentaires pour déceler des activités intrusives. 7 un crossover est un mécanisme naturel qui contribue au brassage génétique lors de la reproduction.

104 Corrélation et Reconnaissance d Anomalies Comportementales 91 Fig Évolution de la population Fig Noeuds temporels du réseau Bayésien (noeuds de liens absorbés)

105 92 Définition du modèle final 5.5 Définition du modèle final En prenant en considération l ensemble des définitions des sections et ainsi que l amélioration proposée en section 5.4, le réseau Bayésien modélisant les comportements des utilisateurs du système est défini comme suit : Soit BN(G ) avec G (S, E ) Pour tous s i, s j S et e E e = (s i, s j), il existe : deux noeuds an i et an j de nom respectif s i.att CT, s j.att CT et d états correspondant aux couples de valeurs de s i.att SIP et s i.att L, s j.att SIP et s j.att L, un noeud ln correspondant à l arc e et possédant comme états l ensemble {SIP, DIP, L}, un noeud tn correspondant à l arc e et d états correspondant aux valeurs de e.time. L ensemble de ces noeuds sont liés comme présentés dans la figure 5.16 On notera la probabilité que deux catégories d évènements s i, s j S soient corrélées suivant une règle x telle que : ln.proba(x). De façon similaire la probabilité que deux catégories d évènements s i, s j S soient corrélées dans un intervalle de temps y sera définie par tn.proba(y). Enfin la probabilité d obtenir un évènement a A sera notée an.proba(a.att SIP, a.att L ). La modélisation des activités utilisateurs va entrainer la construction successive : d un graphe d activité utilisateur G(S, E) qui décrit toutes les relations entre les évènements des données d apprentissage, d un graphe de fusion G (S, E ) qui décrit les relations de causalités entre les différentes classes d évènements, d un réseau Bayésien BN(G ) qui décrit l ensemble des probabilités conditionnelles liant chaque classe d évènements. La figure 5.16 illustre les transformations successives de graphes. 5.6 Exploitation : détection de déviances comportementales L apprentissage des activités utilisateurs habituelles sur le SI nous permet d avoir en notre possession un modèle de comportement normal du système observé. Ce modèle va nous servir de référentiel dans la phase d exploitation et nous permettra de détecter des anomalies comportementales au sein des évènements collectés Classes d anomalies La détection d anomalies comportementales s appuie sur les propriétés du modèle et définit différents types d anomalies. Notre modèle est un réseau Bayésien contenant trois types de noeuds différents, des noeuds d Alerte de fusion contenant les différentes classes d évènements, les noeuds de Liens décrivant comment deux évènements ont été liés et des noeuds Temporels modélisant les intervalles de temps séparant deux classes d évènements associées. Les différentes anomalies détectables se scindent en deux familles. Notre moteur de détection d anomalies vérifie à la fois la cohérence des nouveaux évènements collectés avec la structure du réseau Bayésien et les probabilités d apparition de ces évènements. Si les évènements possèdent

106 Corrélation et Reconnaissance d Anomalies Comportementales 93 Fig Différentes transformations pour la construction du réseau Bayésien de référence

107 94 Exploitation : détection de déviances comportementales une structure connue, notre moteur va alors évaluer la probabilité d apparition de l évènement collecté en fonction du contexte (évènements collectés précédents). Tout évènement possédant une probabilité inférieure à un seuil est qualifié de déviance comportementale statistique. Les déviances comportementales de structure peuvent être de trois natures. Nous distinguons les déviances de structure de noeuds qui vont représenter l apparition de nouveau noeud d Alerte de fusion (nouvelle classe d évènement) dans les évènements analysés. Chaque évènement collecté va posséder des attributs permettant d identifier l émetteur de ce dernier. Comme précisé dans la section 5.3.3, chaque noeud d Alerte de fusion contient comme état (différentes valeurs possibles) des couples d attributs permettant de conserver les différents auteurs de la classe d évènement représentés par ce noeud. Si la classe d un évènement existe mais que le couple d attributs associé à l auteur n appartient pas aux attributs du noeud de référence correspondant, alors nous parlons de déviance de structure d état. Enfin si parmi les évènements collectés apparaissent des liens entre des classes d évènements qui n existent pas dans la structure du réseau Bayésien, il sera question de déviance de structure de lien. Une fois la structure des nouveaux évènements vérifiée, la probabilité de chaque évènement sera évaluée. Après avoir injecté les informations de contexte (évènements précédents) dans notre modèle, l inférence des probabilités nous permet de connaitre la probabilité conditionnelle de l évènement analysé. Trois types de déviances de probabilité sont distinguées, associées respectivement aux trois types de noeuds présents dans le réseau Bayésien. Les différentes déviances de probabilités sont : L apparition d un type d évènement réalisé par un utilisateur peu probable (noeud d Alerte de fusion), L association de deux types d évènements différents suivant des règles de corrélation peu probable (noeud de Liens), Une durée séparant deux types d évènements peu probable (noeuds Temporels). L ensemble des anomalies détectées par notre système se basent sur l analyse d un graphe de détection défini dans la section suivante Graphe de détection Afin de tirer profit au mieux de notre modèle de référence, les évènements collectés lors de la phase d exploitation seront traités et transformés en graphe de détection. Le graphe de détection est un graphe de corrélation d évènements comme défini dans la section où le corpus de construction de départ va varier dans le temps. La construction du graphe de détection va s appuyer sur les évènements collectés durant une fenêtre de détection glissante. Le graphe est construit de façon identique à la section à la différence que chaque noeud du graphe représentant un évènement unitaire possède une durée de vie identique à la taille de la fenêtre de détection (noté a i.t T L). Lorsque la durée de vie d un noeud du graphe a été atteinte le noeud ainsi que les différents arcs correspondant seront supprimés du graphe. Chaque nouvel évènement arrivant dans la fenêtre de détection va venir enrichir le graphe de détection.

108 Corrélation et Reconnaissance d Anomalies Comportementales Détection d anomalies Comme il l a été défini dans la section 5.6.1, plusieurs types d anomalies peuvent être décelées. La détection de ces anomalies va se baser sur le graphe de détection et comparer les évènements de ce graphe à notre réseau Bayésien de référence. La première phase de détection consiste à comparer les deux structures de graphe. Tout élément du graphe de détection déviant de la structure du réseau Bayésien sera considéré comme une déviance de structure. Soit G D (S, E) un graphe de détection où chaque évènement de A correspond à un sommet de S et BN(G ) notre réseau Bayésien associé à un graphe G (S, E ), une déviance de structure est définie comme suit : Définition Une déviance de strucutre de noeud est définie par : Si pour un a i A, a i.att CT s j.att CT s j S alors a i est une déviance de structure de noeud. Définition Une déviance de structure d état est définie par : Si pour un a i A, a i.att SIP a i.att L / s j.att SIP s j.att L s j S alors a i est une déviance de structure d état. Définition Une déviance de structure de lien est définie par : Si pour un lien e E, e = (s i1, s i2 ) tels que s i1.att CT = s j1.att CT et s i2.att CT = s j2.att CT, il n existe pas de lien e = (s j1, s j2 ) alors e est une déviance de structure de lien. Une fois que la structure du graphe de détection a été vérifiée, chaque élément non déviant de la structure du graphe de détection sera utilisé pour une analyse probabiliste. Pour ce faire, les éléments du graphe de détection seront injectés un par un par ordre croissant de leur T T L dans le réseau Bayésien de référence. En utilisant le mécanisme d inférence des probabilités, le réseau Bayésien nous fournira l ensemble des probabilités (Probabilité conditionnelle) de tous les éléments du réseau tenant compte de l élément injecté. Pour le premier élément seul la probabilité d apparition dans le réseau Bayésien de cet élément sera utilisée, pour tous les autres ils suivront l algorithme suivant : Algorithm 3 Parcours des évènements du graphe de détection (G D (S, E),BN(G ),T h a,t h l,t h t ) Hypothèses. Soit un graphe de détection G D (S, E) et un modèle de référence BN(G ), Soit trois seuil de probabilité T h a, T h l, T h t Pour Tout s i S trié par ordre croissant Faire anodetect(s i,g D (S, E),BN(G ),T h a,t h l,t h t ) Fin Pour La terminaison de l algorithme 4 récursif est garantie par la nature acyclique du graphe G D (S, E). La contrainte de règle de corrélation imposant que deux évènements ne peuvent être corrélés que si le premier possède un temps supérieur au second permet de produire un graphe G D (S, E) acyclique.

109 96 Contrôle : Évaluation des évènements déviants et mise à jour du modèle de référence Algorithm 4 Algorithme de détection d anomalies probabilistes Fontion anodetect(s i, G D (S, E), BN(G ), T h a, T h l, T h t ) { Si an i.proba(s i.att SIP, s i.att L ) < T h a Alors Génération d une alerte de déviance probabiliste de noeud. Fin Si Injection de la preuve s i dans BN(G ) Pour Tout s j S tel que e = (s i, s j ) E Faire Si ln i.proba(e i.rules) < T h l Alors Génération d une alerte de déviance probabiliste de lien. Fin Si Si tn i.proba(s i.att DT s j.att DT ) < T h t Alors Génération d une alerte de déviance probabiliste de temps. Fin Si anodetect(s j, G D (S, E), BN(G )) Fin Pour La preuve s i est retirée de BN(G ) } 5.7 Contrôle : Évaluation des évènements déviants et mise à jour du modèle de référence Les systèmes de détection d anomalies comportementales possèdent des limites connues telles que la génération de de nombreuses fausses alertes (faux positifs) et une interprétation délicate des anomalies détectées. Un taux de faux positifs élevé est souvent dû à une modélisation imprécise des référentiels normaux conséquence d un système étudié en perpétuel évolution. Cette lacune a bien été identifiée dans les articles [82] et [63] qui précisent deux difficultés particulières concernant la construction d un modèle de référence. Les systèmes de détection d anomalies s appuient, dans la majorité des cas, sur la modélisation de systèmes dynamiques. Pour ne pas devenir obsolète, les modèles de référence créés doivent s adapter et évoluer en même temps que le système observé. Cette mise à jour de modèles présente deux difficultés majeures. Tout d abord, le choix des périodes de mise à jour d un modèle est crucial pour suivre l évolution d un système [82]. Si la période de mise à jour du modèle est trop grande, des évolutions rapides du système risquent de ne pas être prises en compte. Dans le cas contraire, si la période de mise à jour du système est trop petite, les évolutions sur le long terme ne seront pas détectées. [82] a proposé un mécanisme de fenêtres glissantes pour la mise à jour de leur modèle. Dans cette approche, le modèle de référence est défini par un ensemble de règles. Les fenêtres glissantes utilisées vont définir quelles parties des règles seront supprimées, modifiées et ajoutées. Les règles qui n ont pas été réutilisées récemment seront supprimées. Les règles qui sont exploitées régulièrement seront modifiées et recevront un niveau de confiance plus élevé. De nouvelles règles qui apparaissent seront quand à elles ajoutées. Dans notre cas de figure, les évolutions de notre modèle vont suivre les évolutions des comportements des utilisateurs sur le SI. La mise à jour en temps réel des évolutions de tels comportements nécessite un temps de traitement non négligeable et une perte de repère vis à vis d évolutions graduelles ou de long

110 Corrélation et Reconnaissance d Anomalies Comportementales 97 terme. Afin de garantir une période de mise à jour la plus significative et adaptée possible, nous nous sommes basés sur des études d ergonomies qui nous indiquent que les rythmes de comportements humains se basent sur des cycles journaliers. Une mise à jour journalière des évolutions des interactions Utilisateurs-Système constitue un bon compromis entre une modélisation des activités utilisateurs adaptée et un temps de traitement d évolution du modèle convenable. La seconde difficulté majeure pour la mise à jour d un modèle réside dans la sélection des éléments pertinents. Dès qu un élément déviant a été détecté, le processus de mise à jour devra différentier les évolutions légitimes du système des attaques ou anomalies avérées. Cette problématique sera développée dans la suite de cette section Qualification d un élément déviant Analyser et choisir des évènements déviants significatifs pour la mise à jour du modèle de référence nécessite d enrichir les informations portées par un évènement. Notre qualification des éléments déviants s est basée sur une analyse des utilisateurs finaux d un SI ( end user ) proposée par [83]. Les auteurs de cette approche présentent une taxonomie des comportements de sécurité des utilisateurs finaux d un SI. Cette taxonomie classe les comportements à l aide de deux propriétés principales, l intention et l expertise d un utilisateur. L intention d un utilisateur va différentier les intentions bénéfiques, neutres et malicieuses. L expertise va exprimer le niveau d expertise technique d un utilisateur (faible ou élevé). La combinaison de telles propriétés a abouti à la création de de six classes de comportements relatifs à la sécurité (voir figure 5.17) Fig Taxonomie des comportements de sécurité des utilisateurs finaux Nous nous sommes basés sur les propriétés de cette taxonomie pour qualifier les anomalies comportementales détectées par notre approche. Par l utilisation de plusieurs critères définis dans les sections suivantes, nous proposons une méthode de calcul des propriétés d intention et

111 98 Contrôle : Évaluation des évènements déviants et mise à jour du modèle de référence d expertise. Nous avons également étendu les propriétés de taxonomie de [83] par l ajout d information de contexte. En effet, les propriétés d intention et d expertise décrivent parfaitement le comportement d un utilisateur vis à vis de la sécurité. Néanmoins, l interprétation de ces comportements va fortement dépendre du contexte d étude. Un comportement de sécurité d un utilisateur possédant une intention Neutre et une expertise Haute sera interprété différemment si l utilisateur interagit avec un poste de travail sécurisé où avec un serveur Web exposé. C est pour prendre en compte cette notion de contexte que nous avons défini une troisième propriété portant sur le composant du SI ciblé par l utilisateur. Cette troisième propriété, Cible, va définir la sensibilité d une cible d un utilisateur en terme d exposition aux attaques et d impact stratégique pour l organisme. Chaque évènement détecté comme déviant sera qualifié par trois type de propriétés (appelées dimensions) Intention, Expertise, Cible. a) Dimension d Intention La dimension d Intention exprime l intention, notée R int, portée par un évènement dans le SI. Cette intention va définir les tendances des objectifs de l utilisateurs à l origine de l évènement déviant. L intention d un évènement sera déterminée et calculée à partir de trois critères : l information d intention portée par la catégorie de l évènement et plus particulières son mouvement (noté Rint m ), le degré de déviance associé à l évènement par notre moteur de détection d anomalies (noté Rint dev ) et les intentions portées par des évènements passés liés à l évènement déviant courant (noté Rint ant). L intention d un évènement est exprimée par la sémantique utilisée pour décrire l évènement (voir section 3.3.2). C est tout particulièrement la notion de mouvement utilisée qui nous renseignera sur type d intention. Utilisant l ontologie définie dans [53] chaque évènement collecté sera associé à une classe d évènement possédant l un de ces trois mouvements : Les mouvements de configuration qui définissent des intentions bénéfiques visant à améliorer le système, Les mouvements d activité qui représentent les activités usuelles d un utilisateur sur le SI et une intention neutre, Les mouvements d attaques symbolisant les intentions malicieuses. En fonction de ce contexte, les critères d intention de mouvements Rint m recevront respectivement les valeurs de 1 pour une intention bénéfique, 2 pour une intention neutre et 3 pour une intention malicieuse. L utilisation des mouvements des classes d évènements n est pas suffisante pour déterminer l intention d un évènement. Ces mouvements doivent être combinés avec des informations relatives aux types de déviance d un élément (voir section 5.6). Nous sommes partis du postula que plus la déviance est importante plus l intention est susceptible d être malicieuse. Si l évènement considéré possède une déviance de structure (état jamais vu au préalable) Rint dev prendra la valeur de 1 symbolisant une déviance forte. Si l évènement considéré possède une déviance statistique (évènement existant portant une probabilité basse) alors Rint dev prendra une valeur comprise entre [0, 1] proportionnellement à la déviance constatée. Une déviance probabiliste sera évaluée par 1 P e où P e est la probabilité d un évènement déviant. L intention d un comportement n est pas toujours perceptible sur un évènement isolé. La

112 Corrélation et Reconnaissance d Anomalies Comportementales 99 prise en compter d actions passées peut nous aider à compléter notre jugement sur l intention de l évènement étudié. Afin d améliorer notre qualification de l intention, nous avons pris en considération les antécédents de l évènement courant. Les évènements antécédents constituent l ensemble des évènements liés à l évènement courant dans le graphe de détection (voir section 5.6). Les antécédents d un évènement peuvent être directement ou indirectement 8 liés à l évènement courant. Cette recherche d antécédent sera effectuée dans la fenêtre de temps de détection. Nous avons défini l impact des évènements antécédents (notée Rint ant ) sur l intention d un évènement en cours comme suit : Pour tout antécédent d un évènement (noté Ev ant ) : R ant int = Max(R int(ev ant )) En regroupant l ensemble des critères utilisés, nous définissons l intention d un évènement déviant par : Définition L intention portée par un évènement détecté comme déviant est définie telle que : R int = R m int + Rdev int + erf(rant int 2,5)+1 2 où R int [1, 5] Traditionnellement la sévérité des évènements, des équipements ou des vulnérabilités est évaluées sur une échelle de 0 à 5 dans le domaine de la sécurité des SI afin de permettre aux analystes une lisibilité commune du niveau de sévérité. L intention fournie par le mouvement est la plus importante car elle décrit un fait et non une interprétation ; c est pourquoi sa valeur est comprise entre 1 et 3. Le type de déviance de l évènement va orienter l intention finale portée par l évènement. Le type de déviation peut ainsi transposer l intention finale d une catégorie (de neutre à malicieuse par exemple). D une manière semblable, l intention portée par les antécédents peut guider l intention finale. Nous avons utilisé la fonction erf afin d accorder plus d importance à R ant dans une fenêtre de valeur de transition. La fonction erf atténue les variations des grandes et petites valeurs et amplifie les variations intermédiaires. Les valeurs grandes (au delà de 4) et faibles de R ant (autour de 1) sont moins révélatrices que les valeurs intermédiaires. Les grandes valeurs vont déterminer que les évènements antécédents portent une intention malicieuse. De faible variation autour des grandes valeurs ne vont pas apporter plus d information dans la mesure ou l on sait que l intention des antécédents est malicieuse. Les variations intermédiaires, quant à elles, vont rendre compte des nuances d intentions portées par les évènements antécédents. b) Dimension d Expertise Chaque individu réalise une succession d actions pour parvenir à ces objectifs. Ces actions vont dépendre des moyens en possession de l individu. Dans le contexte de l utilisation d un SI, ces moyens vont se regrouper autour de l expertise technique de l individu. La dimension d Expertise va déterminer les capacités techniques d un utilisateur à l origine de l évènement déviant. Le degré d expertise d un utilisateur implique trois critères : Les types activités de l utilisateur, 8 un chemin contenant des évènements existe entre l antécédent et l évènement courant

113 100 Contrôle : Évaluation des évènements déviants et mise à jour du modèle de référence La cible impactée par l évènement (la notion de cible est uniquement utilisée pour définir les capacités techniques et non la sensibilité de la cible), Le niveau de droits de l utilisateur à l origine de l évènement. L ontologie [53] a défini sept classes de mouvements décrites dans la section (Activity, Config, Malware, Suspicious, Vulnerability, Information). Chacune de ces classes va refléter une expertise technique différente notée Ex act. Les classes Vulnerably et Information reflètent des informations additionnelles sur la cible elle-même, aucune information relative à l expertise n est contenue dans ces deux classes. De plus, aucun utilisateur n est associé à ce type de classe. Les classes Attack et Malware reflètent les activités utilisateurs qui impliquent un fort niveau d expertise pour mener à bien une action d attaque. La classe Suspicious ne donne pas d information détaillée a propos de l expertise. Les deux dernières classes sont plus révélatrices. Tout d abord, la classe Activity correspond à l utilisation des ressources par l évènement sans modification de ces dernières. Cette classe correspond à une utilisation normale du SI sans connaissance particulière requise. A contrario, la classe Config correspond aux actions de modifications des informations systèmes ce qui implique un degré d expertise plus élevé. La table 5.3 nous présente un récapitulatif des expertises associées aux classes d évènements. Actions Ex act value Activity class 0 Suspicious class 0.5 Config class 1 Malware class 1 Attack class 1 Tab. 5.3 Action user evaluation L expertise relative à une activité dépend également fortement du type d équipement manipulé. Tout SI utilise des composants spécifiques afin de garantir des fonctionnalités essentielles et additionnelles. Ces composants ne sont pas accessibles par des utilisateurs standards et nécessitent des permissions et une expertise particulière pour leur utilisation. Par exemple, la configuration d un routeur requière plus d expertise que la configuration d un poste de travail. Chaque composant est pondéré de 0 (expertise faible) à 1 (expertise élevée) afin de déterminer le degré de capacité technique d un utilisateur à l origine de l évènement déviant. L association de l expertise d activité et de celle de la cible définit l expertise requise pour effectuer l action réalisée par l évènement. Le dernier critère permettant de définir l expertise est fourni par le niveau de droit de l utilisateur à l origine de l évènement (noté Ex user ). Ce critère va nous renseigner sur l étendue des actions réalisables à l aide des droits de l utilisateur. Ce critère peut varier en fonction des informations que l on possède. Dans notre cas d étude, nous différentions uniquement les utilisateurs classiques des administrateurs. Cette classification d utilisateurs peut être étendue en respectant le fait que les utilisateurs classiques possèdent un niveau d expertise faible alors que les administrateurs possèdent le niveau d expertise le plus haut. Ainsi, d autres groupes d utilisateurs possédant des droits différents peuvent également être différentiés (groupe administratif, groupe sécurité, etc).

114 Corrélation et Reconnaissance d Anomalies Comportementales 101 Ex user sera compris entre 0.25 et 0.5. Cet intervalle de définition va homogénéiser les valeurs finales de Ex dans [0, 1] suivant la définition suivante : Définition L expertise nécessaire à la réalisation d un évènement détecté comme déviant est définie telle que : Ex = (Ex act + Ex target ) Ex user Les expertises relatives aux classes de mouvements et aux cibles possèdent une même importance. Ces critères représentent l expertise nécessaire pour produire l évènement en question. Le type d utilisateur exprime l étendue des actions possibles à l aide des droits particuliers de chaque groupe. Ce critère est essentiel car il nous renseigne sur le pouvoir potentiel de l utilisateur à l origine de l évènement. Ce critère sera exprimé sous forme de multiplicateur. c) Dimension de Cible La sensibilité des cibles à été exprimée dans de nombreuses approches. Nous pouvons cité par exemple [84] qui se focalise sur la mesure de la sécurité et des risques associés à un composant. La sensibilité d une cible va s exprimer par la combinaison de son importance pour l organisme (importance business) et de son exposition aux attaques potentielles. Le risque est défini par l ISO (ISO/IEC FDIS 17799) comme étant la combinaison d un évènement et de ces conséquences. Le calcul de la sensibilité d une cible sera donc évaluée par la combinaison des évènements potentiellement dangereux pouvant se produire sur la cible et des conséquences fonctionnelles et économiques pour l organisme si un évènements dangereux se produit. Nous allons utiliser trois critères pour calculer la sensibilité d une Cible. Les vulnérabilités présentes sur la cible (R vul ) ainsi que l exposition de la cible dans le SI (R loc ) vont permettre de préciser les probabilités d attaques ou de défaillance sur la cible. Les conséquences de tels évènements seront définis par le critère d estimation de l importance business d une cible pour un organisme noté R ba (business assessment). Tous les composants d un SI peuvent être vulnérables à différentes attaques et exploits. La multiplication des interactions composants logicielles dans les SI continue de faire apparaitre de nouvelles vulnérabilités chaque jour (voir chapitre 1.1). Ces vulnérabilités peuvent être détectées par des équipements de surveillance appelés scanner de vulnérabilités. Ces scanners vont détecter des vulnérabilités connues et référencées sur l ensemble des composants d un SI. La majorité des scanners de vulnérabilités possèdent une base de données où les vulnérabilités connues sont normalisées suivant différents formats de référence tels que le format CVE (Common Vulnerabilities and Exposures) [85] et associées à une sévérité définie par CVSS (Common Vulnerability Scoring System)[86]. Le CVSS prend en compte plusieurs facteurs pour le calcul de sévérité qui se déclinent en trois principaux groupes : les métriques de base, les métriques temporelles et les métriques environnementales. Les métriques de base regroupent les caractéristiques fondamentales d une vulnérabilité constante dans le temps et dans l environnement utilisateur. Cette classe regroupe des informations telles que les impactes sur la confidentialité, intégrité et disponibilité, les vecteurs et complexité d accès à la vulnérabilité etc... Le groupe de métriques temporelles va définir les caractéristiques des vulnérabilités changeant dans le temps en déterminant l exploitabilité de

115 102 Contrôle : Évaluation des évènements déviants et mise à jour du modèle de référence Position de la Cible R loc value Zone locale protégée 1 Zone distante protégée 2 DMZ privée 3 DMZ Public 4 Client mobile 5 Tab. 5.4 Evaluation de l exposition aux attaques des zones du SI cette vulnérabilité, le niveau de rémédiation nécessaire pour contrer cette vulnérabilité ainsi que le niveau de confiance vis à vis de la vulnérabilité elle-même (confiance sur son existence réelle ou non). Enfin les métriques environnementales vont caractériser toutes les informations de contexte autour d une vulnérabilité telles que les dommages collatéraux engendrés si la vulnérabilité est exploitée, la proportion de systèmes vulnérables ainsi que les impactes sur la confidentialité, intégrité et disponibilité de l ensemble du système. Ce calcul de sévérité de vulnérabilité regroupant ces informations est particulièrement important pour le calcul de sensibilité de la cible. Afin de graduer le risque associé aux vulnérabilités présentes sur la cible, nous avons pris en compte le type de vulnérabilité (V ) et sa sévérité associée V S ainsi que le nombre d occurrence de ce type de vulnérabilité (n). Nous avons défini le risque R vul associé à la présence de vulnérabilité sur la cible d un évènement déviant comme suit : Définition La risque associé aux vulnérabilités présentent sur un composant du SI est défini telle que : R vul = N i=1 n(v Si) Afin de manipuler des valeurs de risques homogènes, les valeurs de R vul seront comprises entre 0 (aucune vulnérabilité présente) et 5. De lors qu une cible possède de nombreuses vulnérabilités de sévérité élevée (R vul > 5), le risque associé au composant recevra la valeur maximale à savoir R vul = 5. La probabilité d exploiter ces vulnérabilités va dépendre du niveau d exposition de la cible dans le SI. Nous avons basé notre niveau d exposition sur des architectures de sécurité classiques. Ces architectures délimitent cinq régions différentes de niveaux de sécurité distinctes. Tout d abord, le réseau local d un organisme représente le coeur de l architecture et regroupe les postes de travail et serveurs sécurisés. A l opposé, nous trouvons les utilisateurs mobiles à l extérieur du SI qui sont considérés comme non sécurisés. Afin d ouvrir le SI pour une utilisation extérieure (utilisateurs moblies, clients, fournisseurs), une zone particulière a été délimitée afin de permettre les échanges entre les membres extérieurs du SI et les ressources intérieures de ce dernier. Cette zone est appelée Zone DéMilitarisée (DMZ). Ces DMZ sont généralement sous-divisées en deux zones distinctes ; les DMZ publiques accessibles depuis l extérieur et les DMZ privés contenant les ressources importantes utilisées par la DMZ publique (Bases de données,...). Chaque position d une cible R loc sera pondérée en fonction du risque d exposition aux dangers extérieurs suivant les différentes zones précisées dans le tableau 5.4.

116 Corrélation et Reconnaissance d Anomalies Comportementales 103 Enfin, un dernier critère va venir définir l impact sur le SI si la cible vient à subir une attaque ou un exploit. Chaque cible possède une importance différente au regard des impactes sur le SI. Suivant la nature de la cible, l impacte sur l activité de l organisation peut varier. Plusieurs travaux ont été menés afin de décrire différentes méthodologies pour qualifier les risques business associés à une cible [87, 88]. Nous avons inclus ce risque (R ba [1, 5]) comme un critère déterminant pour l évaluation de la sensibilité d une cible. L expression finale de la sensibilité d une cible d un élément déviant composé des différents critères R vul, R loc and R ba est définie par : Définition La sensibilité d une cible d un évènement détecté comme déviant est définie tel que : R target = Max(R vul, R loc, R ba ) L ensemble des critères influent de façon identique sur la sensibilité de la cible. Dès qu un facteur atteint une valeur élevée, la sensibilité globale de la cible doit être modifiée. La fonction Max nous permet d extraire le cas le plus critique (la valeur la plus grande) de ces trois critères Module de décision La qualification des évènements déviants est primordiale pour permettre tout raisonnement et post-traitement sur les anomalies détectées. L Intention, l Expertise et la sensibilité d une Cible vont permettre de visualiser les évènements déviants sur un graphe possédant ces trois dimensions et faciliter la lecture et la prise de décision sur ces évènements. Grâce à cette qualification des évènements déviants, la sélection des éléments pour la mise à jour du modèle de référence pourra être réalisée plus facilement. Afin d automatiser en partie l évolution de notre moteur de détection d anomalies, nous proposons d utiliser une méthode de classification qui à l aide des informations d Intention, d Expertise et de Cible différentiera les évolutions du SI des évènements intrusifs. Pour ce faire, nous nous appuyons sur un ensemble de données de tests composé d évènements déviants détectés et classés par des experts de sécurité comme appartenant à une activité intrusive ou comme étant une évolution normale du système. Ces données de tests vont servir d ensemble d apprentissage à un moteur de classification supervisé afin de lui permettre de détecter automatiquement les évènements candidats à la mise à jour du modèle des anomalies comportementales. a) Moteur de classification Plusieurs méthodes de classification de données permettent d identifier un ou plusieurs groupes de points. Néanmoins peu d entre eux garantissent une bonne généralisation des règles de classification. Le principe de généralisation permet aux différents algorithmes de ne pas uniquement classer correctement les données d apprentissage (over training) mais au contraire de fournir une généralisation des règles de classification permettant d étendre la classification de données apprises lors de l apprentissage. Peu de méthode classification permettent de fournir cette généralisation. Les Machines à Support de Vecteurs (Support Vector Machine SVM) sont l une de ces méthodes [89]. Les SVMs tentent de trouver des séparateurs optimisant la généralisation et donnent de meilleurs résultats que d autres approches dans des domaines aussi

117 104 Contrôle : Évaluation des évènements déviants et mise à jour du modèle de référence variés que des processus décisionnels [90], de la classification de texte [91] ou encore de la reconnaissance optique de caractères [92]. En déterminant des séparateurs les plus équidistants possible de différentes classes, les SVMs assurent le processus de généralisation. les SVMs possèdent un bon processus de généralisation. Si les SVMs ne trouvent pas de séparateurs linéaires entre plusieurs classes dans un espace, alors ils projettent les données dans un espace de dimension plus élevé et tentent de trouver les meilleurs séparateurs dans ce nouvel espace. Quelque soit la situation, séparable linéairement 9 ou non dans l espace initial, les SVMs vont tenter de maximiser les marges entre les différentes classes. L idée principale des SVMs consiste à dériver un hyperplan séparateur unique qui maximise les marges de séparation entre plusieurs classes. Les points qui longent les marges de séparation sont appelés, dans le jargon de l algèbre linéaires, les vecteurs de support. Une fonction notée ϕ transforme le vecteur initial (les données initiales) en un vecteur dans un espace de dimension plus grande et introduit une correspondance non linéaire entre les données initiales et les données transformées. La fonction de transformation ϕ(x i ) ne doit pas être nécessairement connue. Le mécanisme d optimisation utilise simplement les produits scalaires < ϕ(x).ϕ(z) > où ϕ(x) est la transformation des données dans un nouvel espace et ϕ(z) la transformation des vecteurs inconnus à classer. Cette fonction est appelée fonction noyau (kernel function) noté k. Ici nous avons ϕ(x).ϕ(z) = k(x, z). En fonction du noyau choisi pour la classification SVM, les séparateurs générés seront de différentes natures. La détermination d un noyau le plus adapté ainsi que de ces paramètres de configuration est généralement effectuée par des méthodes heuristiques durant des challenges d essais erreurs. Quatre principales familles de noyaux se distinguent : les noyaux linéaires, les noyaux polynomiaux, les noyaux radiales (gaussien, exponentiel,...) et les noyaux sigmoïdes. Afin de choisir au mieux notre noyau pour notre problématique, nous nous sommes appuyés sur un outil fourni par by H.Serce 10 qui permet de générer plusieurs jeux de données de distribution différentes et d appliquer des noyaux SVMs différents pour séparer les différentes classes. Ne connaissant pas au préalable le type de distribution de nos données, nous avons testé les quatre types de noyaux sur l ensemble des exemples de jeux de tests disponibles. Seul les noyaux radiales permettent de différentier correctement les différentes classes de chaque jeux de tests (voir figure 5.18). Grâce à la classification SVM à base de noyau radial, nous pouvons distinguer deux classes par exemple ou chaque point de chaque classe sera respectivement labelisé par 1 ou 1. Cette classification binaire ne nous donne par d information sur les distances d un point relatives aux autres classes. Cette information peut nous être donnée par l utilisation des SVMs régressifs [93] qui définissent des distances relatives d un point entre les deux classes. Les données ne sont plus labelisées 1 ou 1 mais recevront un degré d appartenance à une classe et seront labelisées par une valeur comprise entre 1 et 1 en fonction de leur position. Cette labélisation continue 9 On dit qu un problème de classification est linéairement séparable lorsqu il existe des séparateurs linéaires (droite affine) permettant de séparer les différents éléments de chaque classe. 10 http :// alatan/courses/demo/appletsvm.html

118 Corrélation et Reconnaissance d Anomalies Comportementales 105 Fig Classification des résultats avec un noyau radial permet de définir plus finement les informations portées par chaque point et permet de définir un degré d appartenance à un groupe. En ce qui concerne notre problématique, nous souhaitons différentier les évènements déviants considérés comme des évolutions normales du système des anomalies ou activités intrusives. Nous avons appliqué la classification SVM à notre jeu de données de tests où chaque évènement déviant est identifié par trois coordonnées représentant respectivement l Intention, l Expertise et la sensibilité de la Cible. Les SVMs vont nous permettre de définir des frontières relatives entre des évènements déviants de mise à jour et des alertes réelles identifiées dans notre jeu de tests par un expert de sécurité. En utilisant cette régression, nous avons défini une zone de marge de séparation entre les classes de mise à jour du système et les anomalies avérées. Les évènements en dessous de cette marge seront candidats pour la mise à jour de notre modèle de référence, les évènements au dessus seront qualifiés d anomalies comportementales. Les évènements contenus dans la marge recevront un indicateur représentant la position relative de l évènement vis à vis des deux classes. Ces évènements qualifiés de suspicieux seront relayés à un analyste. b) Experimentation Afin d entrainer notre classification SVM, nous avons analysé une centaine d évènements déviants. Ce jeu de tests provient de la collecte d anomalies comportementales détectées par notre approche (section 5.6). Chaque évènement déviant a ensuite été qualifié suivant les critères d Intention, Expertise et de sensibilité de la Cible. En analysant chaque évènement déviant, les experts en sécurité ont déterminé les points candidats à la mise à jour du modèle et les évènements anormaux.

119 106 Conclusion (a) Update alerts and deviant alerts areas (b) Only deviant alerts area Fig Classification SVM Nous avons déterminé des séparateurs hyperplans en utilisant une classification SVM à base de noyau radial. La figure b) nous montre la construction des différents séparateurs par l intermédiaire de plusieurs points aléatoires classés par notre moteur de SVM. Dans ce cas de figure, chaque point appartient à une classe et ne contient pas d information sur son éloignement des séparateurs (pas d utilisation de la régression). Nous pouvons distinguer que la zone d anomalies comportementales (zone rouge) présente une incursion dans la zone de mise à jour pour des valeurs de sensibilité de cibles élevées, de faible intention et ce quelque soit la valeur de l expertise. Cette région représente typiquement des actions déviantes d utilisateurs sur des ressources critiques du SI. Nous pouvons également noté qu une région de zone de mise à jour apparait pour des valeurs de faible expertise, de haute intention et de sensibilité de cible moyenne. Cette région provient d un effet de bord du processus de généralisation des SVMs. Dans le cas où le jeu de tests ne contient pas suffisamment de données diversifiées, des résultats incohérents peuvent apparaitre. Ce phénomène peut être facilement inhibé par l ajout de points d ajustement à des coordonnées spécifiques sensibles. L utilisation d une classification SVM binaire (1 et 1) n est pas adaptée à notre problématique. Aussi, afin d améliorer notre processus de décision et aider l intervention d un expert, chaque évènement déviant devra recevoir une position relative vis à vis des deux classes. Cette propriété a été obtenue par l utilisation de la régression, les résultats obtenus sont présentés par la figure Ces résultats présentent des informations supplémentaires sur chaque évènement déviant. En associant un degré minimal pour une mise à jour automatique du modèle de référence, ce processus d évaluation et de décision permet de réduire l implication d un analyste avec le système de détection et d enrichir les informations portées par chaque évènement déviant. 5.8 Conclusion Dans cette section nous avons décrit le coeur de notre moteur de détection d anomalies comportementales. Basé sur les données collectées et homogénéisées comme défini dans le chapitre 3, notre moteur réalise un modèle des activités utilisateurs usuelles lors d une période d apprentissage. Grâce à la sélection d évènements pertinents fournis par le chapitre 4, notre

120 Corrélation et Reconnaissance d Anomalies Comportementales 107 Fig Classification SVM par Régression modèle de comportement par réseau Bayésien identifie l ensemble des relations de causalité inter-évènements et les probabilités conditionnelles qui en découlent. Les attributs contenus par chaque noeud de classe d évènements permettent de différentier le comportement de chaque utilisateur sur le SI. C est lors de la phase d exploitation que notre système utilisera le modèle de référence pour détecter des anomalies comportementales. Cette détection permet de déceler des anomalies de structure qui identifient l apparition de nouveaux états, de nouveaux types d évènements ou encore de nouvelles relations causales entre les classes d évènements. La modélisation des intervalles de temps entre les évènements corrélées ainsi que les différents types de relations de causalité vont permettre une détection plus fine des anomalies de probabilité détectées par notre approche. Tout évènement détecté possédant une probabilité inférieur à celle attendue sera considérée comme une déviance probabiliste. Enfin, notre approche possède également un module d évaluation des évènements déviants qui permet d enrichir l information portée par les évènements déviants et de déterminer les évènements candidats pour la mise à jour du modèle de référence. Bien que notre approche puisse détecter des anomalies d activités utilisateurs sur l ensemble du SI, nous devons également fournir des solutions utilisant les systèmes existants au sein des organismes. Pour se faire, nous avons réalisé un module d extraction de règles de corrélation dites comportementales à partir de notre modèle d activité utilisateurs. Ces règles de corrélation pourront ainsi être utilisées par les méthodes classiques de corrélation explicite d évènements. Ce processus est développé en détail dans le chapitre 6. Enfin, nous avons réalisé un ensemble de tests sur notre approche et obtenus des résultats présentés dans le chapitre 7.

121 108 Conclusion

122 6 Extraction de règles de corrélation 6.1 Introduction Les mécanismes de corrélation, principalement utilisés dans la vision globale, permettent de réduire le volume de données et de créer des groupes d informations partageant un même objectif. La plupart des mécanismes de corrélation existant sont élaborés à partir d une connaissance experte et décrivent explicitement les règles de regroupement des informations. En modélisant les activités des utilisateurs sur le SI, nous disposons d un ensemble de règles décrivant des groupes d information. En utilisant notre modèle comme source d information, nous générons des règles de corrélation comportementales (extraite de l étude des comportements) pouvant être exportées et appliquées à tous autres mécanismes de corrélation explicite. Dans ce chapitre, nous allons définir une méthode permettant de générer des règles de corrélation en utilisant tout particulièrement les chroniques [76] comme langage de description. Regrouper automatiquement des évènements n est pas suffisant pour faciliter la tâche d un analyste de sécurité. Sans précision sur l objectif commun partagé par un groupe d actions corrélées, l analyste de sécurité ne pourra que difficilement utiliser efficacement ces informations. Pour cela, nous proposons un mécanisme de labélisation automatique des groupes de corrélations afin de garantir une utilisation rapide et adaptée des groupes générés. Après avoir rappelé la définition de la corrélation dans la section 6.2, nous allons décrire plus en détail le langage de corrélation utilisé pour décrire les règles de corrélation comportementales (section 6.3). Nous présenterons ensuite notre mécanisme de génération automatique de règles dans la section 6.4. Enfin nous finirons par la description de notre méthode de labélisation des groupes de corrélation (section 6.5). 109

123 110 Définition 6.2 Définition Les opérations de corrélation ont été définies de manières différentes suivant leur contexte d étude. Cette section va rappeler les différentes définitions des opérations de corrélation et définir cette notion dans notre problématique. La notion de corrélation a été principalement employée pour définir des relations mathématiques entre plusieurs variables. En probabilités et en statistique, étudier la corrélation entre deux ou plusieurs variables aléatoires ou statistiques, correspond à mesurer l intensité de la liaison qui peut exister entre ces variables. La liaison recherchée est une relation affine. Dans le cas de deux variables, il s agit de la régression linéaire. Une mesure de cette corrélation est obtenue par le calcul du coefficient de corrélation linéaire. Ce coefficient est égal au rapport de leur covariance et du produit non nul de leurs écarts types. Le coefficient de corrélation est compris entre 1 et 1. D une manière plus générale, la corrélation dans les sciences de l information peut être définie comme une méthode/fonction permettant de regrouper plusieurs évènements possédant des causes ou conséquences communes. Ce regroupement s opère au travers de règles définies explicitement (par un analyste), semi-explicitement (évènements pré-traités par un analyste) ou automatiquement (découvertes des règles par processus). Comme nous l avons précisé dans la section 1.3.3, nous différentions plusieurs processus de regroupement d information. [94] définit plusieurs catégories de corrélation : la compression, le comptage, la suppression et la généralisation. La compression consiste à regrouper des occurrences multiples d un même évènement au sein d un même groupe ; le comptage est la substitution d un nombre spécifique d occurrences d évènements similaires ou de même catégorie par un nouveau groupe ; la suppression est l inhibition des évènements possédant une priorité basse en cas de présence d un évènement de forte priorité et la généralisation détermine des groupes d évènements décrits par une connaissance experte. Nous nous différentions de cette définition de la corrélation en considérant que chacune de ces catégories correspond à des processus différents : le processus de fusion correspond à la compression, l agrégation au comptage et la corrélation à la généralisation. 6.3 Les Chroniques [76] a défini un langage de corrélation permettant de définir les règles de corrélation à partir de chroniques. Ces chroniques peuvent être définies comme des patterns temporels représentant les évolutions possibles d un système observé. Les chroniques sont principalement utilisées pour modéliser les systèmes dynamiques. Une chronique est définie dans [76] comme un ensemble d évènements ponctuels, liés entre eux par des contraintes temporelles, et dont l occurrence peut être soumise à un certain contexte. Un modèle de chronique est composé de : Un ensemble de patterns d évènements, Un ensemble de patterns d assertion représentant l occurrence des évènements,

124 Extraction de règles de corrélation 111 Un ensemble d actions extérieures qui vont être réalisées par le système lorsqu une chronique est détectée. Les informations composant une chronique sont reliées aux informations temporelles par l utilisation de prédicats qui qualifient temporellement les règles ou patterns atemporels (Figure 6.1). Fig. 6.1 Prédicats La détection de chroniques peut engendrer plusieurs problèmes tels que la duplication entrainant l instanciation de chroniques de façon cyclique. C est pour cette raison qu il est nécessaire de déterminer les modèles de chroniques avec attention afin de ne pas produire ces phénomènes. L ajout de contraintes portant sur des prédicats (hold, noevents) ou l ajout de seuils déterminés (t1 t2 < 2) permet d éviter ces phénomènes. Chaque évènement survenu sur un SI est défini par : Soit p P un ensemble de catégories d évènements du SI tel que p P, p est défini par : Un ensemble d attributs noté p Name avec Name {SIP, DIP, L} décrivant respectivement le Classification Text, l adresse IP source, l adresse IP destination et le login utilisateur, Une valeur noté p : v, où v est la valeur correspondante, Les occurences notées p n, où n est le nombre d occurences. Un intervalle de temps dans lequel se produit l évènement p, cet intervalle peut être soit réduit à un point noté p t où conserver les bornes de l intervalle noté p (t1 t 2). Dans la suite de ce chapitre nous définirons une chronique avec la sémantique spatiale et temporelle décrite dans la section : Définition Une chronique Ch est un 3 uplets Ch(P r, R att, R temp ) telle que : P r est un ensemble de prédicats, chaque prédicat indiquant des conditions particulières sur des types d évènements p P. R att est un ensemble de conditions sur les attributs des évènements p P. R temp est un ensemble de conditions sur les temps d apparition des évènements.

125 112 Génération automatiques de règles Les attributs des évènements impactés par les conditions de R att seront notés?p Name où p P et Name {CT, SIP, DIP, L}. Le titre d une chronique contiendra également les relations générales temporelles entre les évènements p P impactés dans la chronique. Par exemple une chronique Ch possèdera comme titre Ch(A; B; C)[?A SIP,?B SIP,?C SIP ]. La chronique Ch spécifie les interactions entre les actions successives A puis B puis C sur les attributs A SIP, B SIP, C SIP. 6.4 Génération automatiques de règles Comme il l a été précisé dans la partie précédente, la génération de modèles de chroniques nécessite certaines informations : Une normalisation des évènements impliqués. Des relations temporelles entre les évènements. Des relations de similitude ou non sur des attributs d évènements. Des règles et spécifications empêchant les duplications des chroniques. L ensemble des évènements traités par le moteur d apprentissage de la section 5.3 est normalisé suivant une ontologie comportementale. Cette ontologie permet de réaliser une fusion des évènements et de réduire les évènements portant la même information. Les relations temporelles nécessaires à la réalisation des chroniques sont disponibles dans le modèle final. Ces informations nous renseignent sur la probabilité que deux éléments soient liés dans un intervalle de temps défini. Un intervalle de temps séparant la corrélation de deux types d évènements (en pourcentage de réussite) pourra être extraite de ce modèle. Comme il l a été précisé dans la section 5.3.1, le modèle des activités utilisateurs analyse les différents évènements au travers de trois attributs (l adresse Ip source, l adresse Ip destination, et le login user) qui permettrons d établir des relations de similitude dans les chroniques. Enfin, des règles spécifiques interdisant la duplication de chroniques devront être élaborées à partir notamment des informations de temporalité entre les évènements Sélection des évènements appartenant à une même Chronique Le moteur d apprentissage va générer des graphes de catégories d évènements. Ces graphes sont constitués de noeuds ou sommets dit sources (qui ne possèdent pas de lien entrant) et de noeuds dit puits (qui ne possèdent aucun lien sortant). L objectif final est de fournir des règles de corrélation (par le biais des chroniques) permettant de représenter tous les chemins entre un noeud source et ces noeuds puits. Afin de parvenir à générer des règles représentant ces chemins nous allons modéliser chaque couple d évènements par une chronique et créer des métas chroniques liant l ensemble de ces éléments. Deux approches peuvent être menées pour extraire des chroniques des graphes d évènements. Une approche consiste à extraire une chronique par chemin (d une source vers un puits). En procédant ainsi, la chronique sera activée 1 uniquement lorsque l ensemble des éléments constituant ce chemin sera apparu en concordance avec les contraintes spécifiques. L avantage de 1 On considère qu une chronique est activée lorsque que l ensemble des conditions décrites par celles-ci sont remplies.

126 Extraction de règles de corrélation 113 cette approche est de fournir une description unique d un chemin et de faire remonter un seul groupe corrélé par chemin. Le principal inconvénient est que certains chemins possèdent des éléments peu probables et que la durée d ouverture 2 d une ou plusieurs chroniques pour activer totalement cette dernière peut être importante. La seconde approche consiste à découper un chemin en éléments de base, à savoir par couple d évènements. Ainsi chaque couple d évènements sera modélisé par une chronique. L ensemble de ces couples sera ensuite regroupé par une chronique de plus haut niveau appelée méta chronique. Cette approche présente l avantage d effectuer des pré-regroupement d évènements et de s affranchir des évènements peu probables. L inconvénient majeur de cette approche est la gestion d une hiérarchie de chroniques et la multiplication de groupes de chroniques en attente. Quelques soient les séquences prises en compte pour la création de chroniques, le passage de notre modèle d activités utilisateurs à une chronique est défini comme suit : Soit un modèle de comportement utilisateur comme défini dans la section 5 tel que BN(G ) et G (S, E ) où tout s S correspond à une catégorie d évènements, nous définissons une séquence de catégorie d évènements dans BN(G ) telle que : Une séquence Sq est définie telle que Sq = {s 0, s 1,..., s n} où s i S et s i Sq, s j Sq e i E tel que e i = (s i, s j ). Une chronique associée à une séquence est définie par : Définition Une chronique correspondant à la séquence Sq est définie par Ch(P r, R att, R temp ) de titre ch(s 0; s 1;... ; s n) [?p 0SIP,?p 0DIP,?p 0L,...,?p nsip,?p ndip,?p nl ] où pour un G (S, E ) donné s i S et pour tout p i P correspond une catégorie d évènement s i. Pour cette chronique il existe un ensemble de prédicats noté pr(p, p t ), pr P r, un ensemble de règles noté R att portant sur les attributs telles que p i, p j P e = (s i, s j ) E, {p isip = p jsip p idip = p jsip p il = p jl } R att et un ensemble de conditions temporelles noté R temp Chronique unique par chemin La création d une chronique par chemin va traduire l ensemble des contraintes d un chemin d évènements d un graphe par une chronique unique. Cette chronique va devoir décrire les contraintes temporelles liant l ensemble des évènements (précédence et temps de corrélation entre les évènements) et également les contraintes sur les attributs liant les éléments du chemin entre eux. Le modèle d activités utilisateurs va contenir des informations relatives aux probabilités de liaison des évènements suivant trois critères (même adresse IP, adresse IP destination l adresse IP source, même login user) et également des probabilités d intervalles de temps séparant deux évènements corrélés. Deux solutions sont envisageables pour définir les contraintes de cette chronique. Tout d abord, une hypothèse peut être de déterminer les contraintes sur les temps de corrélation et les attributs de corrélation afin de s assurer que 100% des éléments seront détectés par 2 Une chronique est dite ouverte lorsque le premier évènement correspondant à la séquence modélisée apparait. Dès lors, les données reçues sont analysées afin de vérifier les conditions décrites dans la chroniques.

127 114 Génération automatiques de règles cette chronique. Cette hypothèse est risquée et peut engendrer une multiplication de chroniques en attente d être activées. Une autre hypothèse peut être formulée visant à détecter un pourcentage donné d évènements (ex : on souhaite que la chronique détecte 90% des évènements). Fig. 6.2 Transformation d un chemin en chronique unitaire La figure 6.2 présente une représentation d un chemin d évènements par une chronique unitaire. Les éléments de représentation du chemin (temps et connexion) ont été traduits par des contraintes au sein de la chronique. L utilisation de l opérateur logique OR lors de la définition de contraintes non temporelles ne présente pas de problème majeur lors de détection d une chronique. Cette contrainte n est en effet vérifiée qu une fois l évènement apparu dans sa fenêtre de temps donnée. Néanmoins, des contraintes disjonctives 3 peuvent apparaitre lorsque les probabilités de temps entre deux évènements ne sont pas nécessairement regroupées autour d une même fenêtre de temps. [95] propose des solutions afin de résoudre la détection de chronique proposant des contraintes temporelles disjonctives. Ces contraintes restent une source de complexité supplémentaire et doivent être contournées si possible Chroniques hiérarchiques par chemin Les chroniques hiérarchiques représentent la fusion de modèles de chroniques préalablement décrits en une chronique plus importante. Ainsi cette dernière sera la conjonction de toutes les contraintes des sous modèles. L avantage d utiliser une telle approche est de permettre la détection de chroniques intermédiaires et ainsi d effectuer une pré-corrélation des évènements. Cette pré-corrélation permettra de regrouper des évènements et d éviter des temps d attente longs de certains évènements peu probables. Trois types de chroniques différentes peuvent être distingués, des chroniques de conceptions 3 Ces contraintes spécifient que deux tâches ne peuvent pas avoir lieu en même temps

128 Extraction de règles de corrélation 115 qui représentent une composition de règles portant sur les éléments d une séquence, des chroniques de compositions liant des chroniques de conception entre elles et des chroniques hybrides associant à la fois des chroniques de conception et des éléments d une séquence. Chronique de conception : les chroniques de conception vont définir les propriétés permettant de lier des éléments d une séquence avec un ensemble réduit d évènements. Ces chroniques représentent le plus bas niveau de modélisation. Il modélisera les contraintes d attributs et les contraintes temporelles. Tout comme il l a été défi dans la section 6.4.2, ces contraintes peuvent être disjonctives. Chroniques de compositions : les chroniques de compositions vont représenter l assemblage de sous modèles. Ces chroniques de haut niveau vont définir des groupes de corrélation représentant la totalité ou une partie d un chemin d évènements. Chroniques hybrides : les chroniques hybrides définissent l association de sous modèles et d évènements simples. Ces modèles présentent une grande utilité pour isoler des évènements de faible probabilité. En dissociant les éléments les plus probables d une séquence des évènements de faible probabilité, les chroniques hybrides permettent de générer une règle de corrélation pour les évènements les plus probables et une règle de corrélation incluant la règle des évènements les plus probable et un ou plusieurs évènements de faible probabilité Utilisation des chroniques hiérarchiques La notion de probabilité de sous-séquences est importante pour le choix d utilisation de chroniques hiérarchiques. Ainsi si une séquence d évènements présente des sous parties probables et d autre peu probables, il est important de dissocier leur analyse. La figure 6.3 présente un exemple de chroniques hiérarchiques d une séquence de quatre évènements. La sous-séquence A, B, C est une séquence fortement probable. Cette séquence sera regroupée sous une même chronique de composition. La sous séquence C, D est beaucoup moins probable. Afin de ne pas freiner ou empêcher la détection de la séquence totale, cette sous séquence est modélisée à part dans une autre chronique de composition. La totalité du chemin d évènements reste un regroupement remarquable, c est à dire la totalité du chemin fournira des informations à un analyste. Une chronique de composition va permettre de remonter cette information en associant les modèles des deux sous séquences. Cette chronique de composition va incorporer les chroniques de conception des sous-séquences. Cette composition de chroniques permet de dissocier les séquences les plus probables des séquences plus rares d un même chemin tout en gardant la possibilité de modéliser le chemin complet Sélection des séquences les plus probables Ainsi la modélisation des chemins à partir des chroniques nécessite l extraction des séquences les plus probables de chaque chemin. Comme il a été défini dans la section 5.3, le moteur d apprentissage utilise un réseau Bayésien pour modéliser les comportements utilisateurs. Ce moteur offre la possibilité de calculer des probabilités conditionnelles de différents évènements. Il est ainsi possible de calculer les séquences les plus probables au sein d un graphe. Il est utile de

129 116 Labélisation automatique des règles de corrélation Fig. 6.3 Chronique hiérarchique : chroniques de composition et de conception rappeler que la réalisation d un tel calcul est identique à un problème connu (voyageur de commerce) pour être NP-Complet. Il faut donc être prudent pour l utilisation de tels mécanismes. Cependant, les différents tests pratiques opérés pour l apprentissage de scénarios d usage ont mis en avant que les différents graphes ont un diamètre dépassant rarement trois niveaux ce qui rend le problème traitable. La recherche du chemin le plus probable va vérifier à chaque étape la plus grande probabilité d apparition d un évènement. L algorithme 5 décrit notre méthode de sélection. On note proba(an) la probabilité que la catégorie d évènements représentée par le noeud an du réseau Bayésien existe, où le réseau Bayésien est bâti à partir d un graphe d évènements G(S, E). Cette probabilité est définie telle que : proba(an)= s j S an i.proba(s j.att SIP, s j.att L ) où l ensemble des couples s j.att SIP, s j.att L représente les couples d attributs contenus dans an et an i.proba(s j.att SIP, s j.att L ) la probabilité que le couple d attributs s j.att SIP, s j.att L de la catégorie d évènements an existe. Pour l algorithme 5, nous définissons un chemin C de BN(G ), G (S, E ) tel que C = {s 0, s 1,..., s n} tels que s 0, s 1,..., s n S où s 0 représente le sommet source de la séquence et s n représente la fin de la séquence (appelé aussi puits). La sélection des chemins les plus probables permet de déterminer les chroniques de conception à modéliser et comment les modéliser (isolation des segments les moins probables). Une fois les chroniques de conception crées, les chroniques de composition peuvent être mises en place. 6.5 Labélisation automatique des règles de corrélation Par la transposition du modèle d activités utilisateurs en chroniques de conception et/ou de composition, les mécanismes de corrélation existant peuvent utiliser ces informations pour

130 Extraction de règles de corrélation 117 Algorithm 5 Algorithme de sélection des séquences les plus probables (Chemin C, Seuil th, Réseau Bayésien BN(G )) k init = 0 th représente une probabilité d existence an i représente le noeud Bayésien de BN(G ) correspondant à s i. 1 proba(an) représente la probabilité que la catégorie d évènements s i représentée par an n existe pas. Tant que s i s n Faire Si 1 proba(an) < th Alors Création d une chronique Ch sur les sommets s k tels que k [k init; i] k init = i Fin Si Injection de la preuve s i existe dans BN(G ) Fin Tant que enrichir leur base de règles de corrélation. Néanmoins, la génération automatique de règles de corrélation comportementales n attribut pas de nom ou de sémantique aux différents groupes réalisés. Sans signification, ces groupes de corrélation perdent de leur intérêt pour le management du SI. Nous proposons dans cette partie de fournir une méthode de labélisation automatique de ces groupes de corrélation. Cette labélisation passe par l étude des objectifs et des centres d intérêts des utilisateurs du système nécessaire pour connaitre la signification d une séquence Définition d un utilisateur du Système d Information Chaque règle de corrélation générée reflète une séquence d actions d un utilisateur. Dans le chapitre 4, nous avons décrit les démarches des différents utilisateurs du SI. Cette étude nous a permis de comprendre les différentes actions d un utilisateur du SI. Ici nous souhaitons analyser plus en détail les propriétés des utilisateurs, leurs objectifs ainsi que leurs centres d intérêt. Ces informations vont nous permettre à partir d une séquence d actions de déterminer l objectif et l intérêt d un utilisateur à effectuer cet enchainement d actions. Dans cette section, nous allons définir l ensemble des propriétés d un utilisateur afin de déterminer les paramètres indispensables pour la labélisation d une séquence. Nous nous sommes inspirés des travaux de [83] qui analysent les utilisateurs finaux des SI suivant leur intention et leurs compétences techniques. Nous avons décliné les intentions des utilisateurs suivant deux critères différents, les objectifs généraux des utilisateurs et leurs centres d intérêts. Les objectifs généraux vont présenter des tendances globales des utilisateur sur le SI. Les centres d intérêts, pour leurs parts, reflètent l ensemble des moyens fournis par le SI pour atteindre un objectif. Cette notion de centre d intérêt va également exprimer les habitudes et préférences des utilisateurs du SI vis à vis des moyens utilisés. Nous avons également utilisé l ontologie [53] qui décrit l ensemble des activités réalisable par un utilisateur. Enfin nous avons complété notre représentation des propriétés d un utilisateur par la définition d une classe d identité qui défini les affiliations et les identifiants d un utilisateur comme il l est spécifié dans [96].

131 118 Labélisation automatique des règles de corrélation a) Identité Avant tout, un utilisateur est identifié par une identité. Cette Identité représente un ensemble d informations permettant de caractériser un utilisateur. L identité d un utilisateur est composée d Identifiants personnels, de Groupe d affiliation et d Identifiant de Sécurité. Les Identifiants personnels sont un ensemble d informations caractérisant l individu. Dans la majeure partie des cas, les identifiants sont une composition de nom de login et de domaine. Des informations qualifiant l individu sont également indispensables afin d attribuer une valeur juridique à l utilisateur. Chaque utilisateur du Système d Information est affilié à un ou plusieurs groupes. Ces groupes définissent une structure organisationnelle ou logique au sein de laquelle est rattaché un utilisateur. Enfin, la sécurité des Système d Information impose la mise en place d informations complémentaires caractérisant l individu et lui permettant d accéder et d utiliser les ressources du SI. Ces informations peuvent être de différentes natures en fonction des outils utilisés et du niveau de sécurité demandé. Il peut s agir : Un badge ou d une clé permettant à l individu d accéder physiquement aux ressources de SI, Un certificat et/ou des clés de chiffrement permettant à un utilisateur d accéder aux ressources, de signer des documents électroniques et d assurer la non-répudiation de ses activités, D un mot de passe personnel permettant à l individu d accéder au système ou à des ressources. Fig. 6.4 Détail de l Identité d un User b) Objectifs Chaque utilisateur du Système d Information utilise des ressources afin d atteindre un objectif. Chaque utilisateur est tenu d utiliser le SI à des fins professionnelles. Tout comme la classification des entreprises par leur activité 4, les objectifs professionnels des utilisateurs peuvent se regrouper également par leur activité : 4 Code APE, http ://

132 Extraction de règles de corrélation 119 Réaliser une production (production de bien, de logiciel...), Fournir un service (comptabilité, administration du parc, administratif), Manager une équipe (gestion d une équipe, de plusieurs entités). L utilisation des ressources pour des fins personnelles est tolérée dans le respect d une certaine charte d étique. L étude des comportements utilisateurs de [56] décrit également cette utilisation de ressource pour des fins personnelles avec l utilisation, par exemple, de protocoles réseaux relatif à une utilisation personnelle sur SI : http (utilisation de l internet), gnutella (téléchargement de fichier non professionnel ), Real Audio (flux multimédia audio), etc... Dans ce cadre d utilisation, les objectifs personnels peuvent variés. Nous proposons trois catégories d objectifs personnels : la formation, l apprentissage, le loisir (video, musique), la réalisation d un projet personnel (recherche de travail, associations). Dans ce cadre d utilisation, certains utilisateurs peuvent tenter d attaquer le Système d Information. [97] décrit ce problème en précisant que prêt de 87% des intrusions identifiées au sein des SI du DoD (Departement of Defense) sont dues à des personnes internes à l organisation. Cet objectif d attaque fait parti des objectifs personnels possible d un utilisateur. Fig. 6.5 Détail des objectifs d un User c) Intérêts Les utilisateurs du SI exploitent régulièrement des équipements et services du SI afin d atteindre leurs objectifs. De part leur activité, ces utilisateurs utilisent plus fréquemment certains types d équipements ou services. Nous avons décrit ces préférences comme des intérêts particuliers des utilisateurs envers certains équipements ou services. Pour prendre en compte ces intérêts nous avons défini différents types d objets utilisés par les utilisateurs. Cette classification s est basée sur la description du management des ressources techniques pour atteindre les objectifs visés décrits dans [98]. Les différents objets du SI utilisés peuvent portés sur : Des Business Services. Cette catégorie représente les services de hauts niveaux utilisés de préférence par un utilisateur pour atteindre ces objectifs. Les Business Services utilisent

133 120 Labélisation automatique des règles de corrélation des services techniques pour fonctionner. Des services techniques qui représentent un ensemble de moyens techniques permettant la réalisation de Business Services. Ces services techniques représentent une interface indispensable entre les Business Services et les données utilisées. Des données utilisées qui correspondent aux types de données consultées ou modifiées par les services techniques et business. Des informations et protocoles réseaux. Cette catégorie représente un support indispensable aux services techniques afin de permettre une communication et un échange d information. Des composants physiques (Hardware) particuliers impliqués dans l utilisation des ressources. Fig. 6.6 Détail des composants d intérêt utilisé par un User d) Activités Les activités d un utilisateur représentent l ensemble des actions réalisées par un utilisateur pour atteindre un objectif. Comme défini dans [53], les actions d un utilisateurs se définissent à l aide de deux composants : les moyens de l actions (le type d actions réalisées ) et l objectif visé (reflétant l intention de l utilisateur au travers d une action). Ici la notion d objectif d activité se distingue de l objectif défini dans la section b) et représentant un objectif spécifique à l utilisation du SI (Accès au SI, utilisation des ressources Systèmes) et non un objectif plus général comme défini dans b). Les différents objectifs et types de moyens utilisés correspondant aux classes définies dans [53]. Fig. 6.7 Détail des activités d un User e) Compétences [83] présente un taxonomie des utilisateurs finaux d un SI suivant deux critères, l intention de l utilisateur et son expertise technique. Nous avons utilisé cette notion d expertise technique

134 Extraction de règles de corrélation 121 définissant le degré de connaissance technique d un utilisateur et l avons rebaptisé en Compétences. Nous avons complété la notion d expertise techniques de [83] en spécifiant trois différents types de compétences : Compétence Applicative. Les compétences applicatives reflètent le niveau de connaissance et d utilisation d un individu des applications particulières ou générales. Compétence Réseau. Cette compétence définie le niveau de connaissance et d expertise de l utilisateur vis-à-vis des équipements et des protocoles réseaux. Compétence en Sécurité. Cette compétence définie le niveau de connaissance, d expertise et de sensibilisation d un utilisateur à la sécurité (physique et de l information). Fig. 6.8 Détail des compétences d un utilisateur Détermination de la signification d une séquence Les chaines d évènements constituent des scénarios spécifiques visant à la réalisation d un objectif. Cette section va s attacher à définir une méthode d étiquetage automatique de ces scénarios. Chaque scénario d usage ou d attaque peut être défini au travers de quatre critères. Chaque scénario sera réalisé en vue d atteindre un objectif, par une succession d activités sur des cibles ou centre d intérêts particuliers à l aide de compétences d un utilisateur. L ensemble des propriétés, centres d intérêts, activités, compétences et objectifs définit la catégorie d utilisateur effectuant le scénario en question. Un scénario va être déterminé par la succession d activités portant sur des cibles particulières. Ces cibles peuvent être identifiées par deux catégories principales, les Business Service (BS) et les Technical Service (TS) qui seront définies dans la section Les BS constituent la cible principale d un scénario, les TS représentant des étapes intermédiaires pour atteindre un BS. a) Modélisation d une séquence : vers une ontologie Chaque séquence est vue comme une succession d actions sur des cibles particulières. Ces actions représentent des successions de moyens utilisés pour atteindre un objectif. Ces moyens peuvent être de plusieurs natures, il peut s agir de moyens techniques ou de moyens de plus haut niveau appelés moyens business. L ensemble des actions d une séquence étant préalablement modélisées par un quadruplet intention, mouvement, cible, résultat, il en sera de même pour les différents moyens utilisés. L objectif d une séquence sera également modélisé par le quadruplet intention mouvement cible résultat et sera déterminé par le jeu de règles déterminé dans la suite de cette section (voir graphe 6.9).

135 122 Labélisation automatique des règles de corrélation Fig. 6.9 Sémantique d une séquence b) Règles de nommages Plusieurs configurations de scénarios sont possibles mêlant différentes actions, intentions et cibles. Un utilisateur U exploitant soit des BS soit des TS peut aboutir à la création de différentes combinaisons de séquences d actions qui possèderont des noms différents : L utilisateur exploite un BS au travers d un T S (exemple : authentification puis utilisation d une application métier). L intérêt de l utilisateur porte toujours sur le BS, pour spécifier les étapes de l utilisateur, le scénario sera nommé : BS via T S. L utilisateur exploite le BS au travers de T S 1. BS utilise un autre T S 2 pour fournir la ressource nécessaire à l utilisateur. Les T S 2 services exploités par le BS n identifient pas l objectif d un utilisateur normal mais des dépendances techniques de services. L intérêt de l utilisateur sera donc donné par : BS via T S 1. L utilisateur exploite toujours le BS 1 au travers T S 1, BS 1 va utiliser BS 2 par l intermédiaire de T S 2 afin de fournir les ressources demandées à l utilisateur. L intérêt de l utilisateur va toujours porté sur BS 1 mais la demande d information ou de ressource de BS 1 à BS 2 devra être soulignée. Ainsi, l intérêt de l utilisateur sera donné par : BS 1 via BS 2. L utilisateur exploite BS 2 au travers T S 1, BS 1 et T S 2. Seules les dépendances les plus révélatrices seront conservées. L intérêt de l utilisateur sera noté BS 2 par BS 1. Le type d activité d un évènement d un scénario permet également de qualifier les relations d un intérêt entre les TS/BS et BS/BS. L ensemble des règles permet de résumer et de mettre en avant la nomination de scénarios d évènements. L ensemble des règles d étiquetage des scénarios est disponibles en annexe 9.2. Ces règles s appuient sur la nature des cibles (TS et BS) ainsi que la nature des activités (Usage, Configuration, Attaque). La figure 6.10 présente un jeu de règles pour une séquence d évènements portant sur des cibles différentes représentant une combinaison de TS.

136 Extraction de règles de corrélation 123 Fig Exemple de règles de nommage Détermination des cibles : Technical Services/Business Services Comme déterminé dans la section 6.5.2, le nom/étiquette d une séquence est une composition de cibles et d actions. La principale difficulté de la mise en place d un tel système réside dans la détermination des cibles comme étant des services techniques ou des services Business. Cette distinction est réalisée par la mise en oeuvre de plusieurs étapes : la détermination et classification des business services, la classification des services techniques et la détermination des dépendances Business Services/ Technical Services. a) Description des Business Services Les cibles du système peuvent être regroupées suivant plusieurs critères. Nous nous sommes attachés sur des propriétés du service rendu par chaque cible. Ces cibles sont regroupées autour de Business Services représentant des groupes de services de haut niveau. Le document Cobit [98] confronte les besoins stratégiques et business des compagnies aux besoins et objectifs du SI nécessaires pour accomplir les objectifs de l entreprise (voir figure 6.11). Fig Représentation des besoins de l entreprise et ceux du SI (Cobit) Les objectifs business vont influencer la compositions des SI. Ces objectifs buisness impliquent nécessairement des besoins et objectifs techniques. Ces objectifs techniques vont dépendre de processus techniques délivrant une information, utilisant des applications qui s appuient sur une infrastructure et du personnel.

137 124 Labélisation automatique des règles de corrélation Ainsi le principal challenge est de déterminer les processus techniques indispensables pour la réalisation d objectifs business. Chaque business service possède un ensemble de services techniques permettant son bon fonctionnement. Par exemple le business service visant à assurer le E-commerce de l entreprise peut être réparti sur plusieurs services assurant la sécurité du service web/base de données, la gestion de la base de données, la gestion d une DMZ, la gestion de l interface Web et la gestion de l application de paiement en ligne. Des services techniques utilisés par le Business service Ecommerce seront partagés par d autres BS (serveur d authentification, firewall), tant dis que d autres seront spécifiques aux services (Front et Back Web). L utilisation d un service technique partagé par plusieurs business services ne permettra pas nous renseigner sur la nature de l objectif de cette action. Néanmoins lorsqu un service technique qui est propre à un BS (exemple : Front Web) est utilisé dans un scénario particulier alors le scénario contenant cette information pourra être nommé. Dans le cas particulier ou un scénario ne contient que des services techniques partagés, le dernier service technique ciblé représentera l objectif du scénario (se référer à la section pour plus d information sur le nommage des scénarios). Les équipements d un Système d Information peuvent assurer une ou plusieurs fonctions. Certains, particulièrement critiques pour l entreprise, sont dédiés à une activité particulière permettant d assurer une activité business. Ces équipements vont héberger l ensemble des services techniques indispensables au fonctionnement du business service. Ainsi nous pouvons considérer que tout évènement provenant d un équipement spécifique et interagissant avec un TS assurant le BS de l équipement peut être identifié comme interagissant avec le BS. Dans le cas contraire l utilisation des T S pour l étiquetage des règles de corrélation est plus complexe voir (annexe 9.2) b) Classification des Business Services Les business services d une entreprise représentent les activités majeures de cette dernière. Une compagnie pouvant posséder plusieurs business service, il est indispensable de proposer une classification permettant d identifier chaque business service ainsi que des services techniques nécessaires à leur exploitation. Nos travaux se sont basés sur une classification des business services proposés par [99]. Cette classification est axée sur trois critères de différentiation des business services : Standardized ou Customized. Ce critère permet de spécifier le type d utilisation du Produit (produit ou service) du business service. Soit le Produit est un standard distribué (Standardized), soit il représente un Produit particulier destiné à une utilisation unique et spécifique (Customized). Manual services ou knowledge services. Ce critère spécifie la nature du service rendu. Le service peut être la production physique d objets ou des services de conseil impliquant des connaissances expertes. High labour intensity ou High capital intensity. Ce critère permet d identifier la part d implication de l expertise ou du savoir faire humain vis à vis de l exploitation et de la

138 Extraction de règles de corrélation 125 production réalisée. Un business service est qualifié de High labour intensity si il utilise des moyens non technologique, tels que l expertise, le talent humain. Un business service est qualifié de High capital intensity si il utilise des moyens technologiques (machines-outils, informatique, électronique). La Figure 6.12 expose l ensemble des critères de qualification d un Business service. Fig Classification des Business Services Cette figure présente huits classes différentes de Business service (de A à H). Chaque classe présente des propriétés différentes exposées en annexe 9.3. Les Business Services décrit dans cette classification ne possédent pas tous d interaction avec le Système d Information. Les classes Labour intensive Repetitive Processing (A) et Labour intensive Tailored Processing (B) représentent l ensemble des activités (spécialisées ou non) permettant de produire des objets grâce à la seule expertise, savoir faire du personnel. Les Business Services Capital Intensive Networked Production (E) et Capital Intensive Tailored Production (F), quant à eux, vont fournir un service direct ou un produit à l aide de moyen technologique. Ces classes n interagiront avec le SI qu au travers d Applications ou Services très spécifiques (ex : machines-outils commandées). Les services Information Intensive Repetitive Porcessing (C), Tailored Managerial Problem Solving (D), Scale Intensive Networked Processing (G) et Tailored Technical Problem Solving (H) possèdent des interactions complexes avec le Système d Information. Chacune de ces classes de Business services va utiliser des services techniques afin de fournir le résultat escompté. Ces services techniques pourront être exploités localement ou à distance et impacter un ou plusieurs types d équipements du SI.

139 126 Labélisation automatique des règles de corrélation c) Classification des Services techniques Afin de définir avec précision les services techniques impactés dans les activités business, ces derniers doivent être regroupés en fonction des fonctionnalités fournies. Nous nous sommes inspirés des taxonomies des approches [100] et de [101] pour identifier les différentes classes de services techniques. La Figure 6.13 décrie une taxonomie des différents services techniques. Cinq classes différentes ont été mises en avant : Les services techniques de Communication, Les services techniques de Transaction, Les services techniques de Management, Les services techniques de Manipulation (processing services), Les services techniques de Loisir/Publicité (Entertainment). Fig Classification des services techniques Les services techniques de Communication regroupent l ensemble des applications/services nécessaires pour échanger des informations, dialoguer avec une autre entité, avec d autres individus. Nous retrouvons les services de messageries, téléphonies et de messageries instantanées. L ensemble des applications collaboratives permettant de partager des points de vus et des informations est également pris en compte. Enfin, des services techniques supplémentaires nécessaires aux communications sont également présents, tels que les annuaires et services de nommage. Les services techniques assurant les transactions commerciales sont décrits dans les services techniques de Transaction. Ces services comportent des services/application de paiement et de vente ainsi que les services relatifs au portail Web, socle des transactions. La gestion des problèmes ou erreur de transaction est également représentée par les services de ticketing. L ensemble des services de techniques nécessite une administration et un maintien de leur bon fonctionnement. Ces fonctionnalités sont assurées par les services techniques de Management. Trois grandes catégories de management sont différentiées, le management de la sécurité du SI (assurant le maintien de l intégrité, la confidentialité et la disponibilité des services et des données), le management réseau (assurant le bon fonctionnement et les qualités de services nécessaires aux bon fonctionnements des échanges d information dans le SI) et le management d applications (assurant la mise à jour et la bonne configuration des applications et services du SI).

140 Extraction de règles de corrélation 127 Une catégorie de services techniques particulière, Processing services, représente l ensemble des services nécessaires pour la manipulation/création des données ou produits. Cette catégorie regroupe les services applications propre à un poste client Desktop Services/software (regroupant l ensemble des services d administration locale, des applications d assistances, des applications générales telles que les applications word processing, les applications utilitaires de compression,etc..) des services/applications commerciaux standards (serveur et client), des services/applications métiers standard et des services/applications métiers spécifiques. Enfin, une dernière catégorie permet d identifier les services techniques utilisés pour le loisir ou pour la communication marketing (Entertainment). L ensemble des services/applications de jeux, d utilisation de vidéo et audio est regroupé dans cette catégorie. La consultation de site Web externe est également présente dans cette catégorie. Ces cinq classes de services techniques sont manipulées par les différentes classes de business services pour atteindre les objectifs souhaités. d) Définition des interactions Business Services - Technical Services La Figure 6.14 présente les différents Business Services impactant les services techniques (technologique). Les classes de business services décrites ci-dessus (C, D, G, H, E, F) vont utiliser certains services techniques particuliers, plus ou moins fréquemment et localisés différemment. Les classes (A, B) ne sont pas prises en compte car elles n utilisent pas de ressources technologiques. La classe de business service C représente une activité de forte valeur ajoutée standard sans utilisation nécessaire de ressources technologiques (exemple de business services : training). Cette classe va utiliser des ressources techniques afin de communiquer le savoir faire produit. Afin de rendre les formations interactives cette classe de business service va également utiliser des ressources multimédias (Entertainment). Une utilisation ponctuelle des logiciels pour créer un support de contenu est à envisager (Processing Services). Cette classe business peut utiliser les services techniques localement ou à distance. La classe de business service D concerne les activités de fortes valeurs ajoutées spécifiques à un problème ou à un contexte sans utilisation nécessaire de ressources technologiques (exemple de business services : Marketing). Cette classe utilisera les mêmes services techniques que la classe C à la différence que l utilisation des logiciels/services pour créer résoudre des problèmes spécifiques ou réaliser des rapports précis (Processing Services) sera plus fréquente. Cette classe business peut utiliser les services techniques localement ou à distance. La classe de business service G représente une activité de forte valeur ajoutée utilisant massivement des ressources technologiques (Banking, Internet Services). Cette classe va utiliser massivement les services techniques de transaction afin de fournir les informations et contenus nécessaires à un maximum de clients (exemple de services techniques de transaction : Web portal, Application Payment). Cette classe utilisera rarement les services techniques Processing services, les services fournis étant déjà développés (des mises à jour sont tout de même envisageables). Un management de l ensemble des services fournis est à réaliser ce qui justifie l utilisation modérée des services techniques de management. Enfin les services techniques de Communication peuvent être utilisés (rarement) afin d effectuer des réponses personnalisées

141 128 Labélisation automatique des règles de corrélation à des clients. L ensemble des données fournies à ces services sera essentiellement local et les données et services rendus seront consultés à distance. La classe de business service H représente une activité de création/management de forte valeur ajoutée utilisant massivement des ressources technologiques (R&D, Tailored Soft). Cette classe va utiliser fréquemment les services techniques Processing Services afin de produire, créer renouveler et mettre à jour des services. Cette classe utilise également pleinement les services techniques liés au management (sécurité, réseau, Application). Les services techniques de communication ne sont que rarement utilisés, l activité se cantonnant à la création/management se différenciant de la vente (classe business Service D ou G). Ces services techniques ne sont utilisés que localement. Les deux dernières classes de services techniques représentent des activités à faible valeur ajoutée mais utilisant massivement des ressources technologiques. Ces deux classes vont utilisées toutes deux fréquemment des services techniques Processing Services afin de réaliser/fournir leur produit/service. Le management de ces activités est primordial pour leur bon fonctionnement, les services techniques de management sont donc impliqués. Enfin les services techniques de communication ne sont que rarement utilisés. La classe F qui fournir des produits/services spécifiques n utilisera ces services techniques que localement. La classe E, quant à elle, recevra des informations localement et mettra à disposition ces produits services à un très grand nombre de clients (accessible donc à distance). Fig Business Services Spécification Rôle des Assets dans le nommage des séquences Comme il l a été évoqué dans la section 6.5.3, les Business services d une entreprise peuvent impliquer plusieurs composants du SI. Certains composants seront assignés à l hébergement

142 Extraction de règles de corrélation 129 des services techniques dépendant d un Business Service. La spécification de tels équipements permet de qualifier les évènements provenant de ces derniers comme appartement à un Business service particulier. Grâce à la détermination des services techniques spécifiques à un business service, les évènements d équipements du SI hébergeant ces services pourront être identifiés. La Figure 6.15 illustre l étiquetage d une séquence à l aide d une qualification des équipements par des classes de business services. La première étape consiste à identifier si les évènements de la séquence proviennent d un équipement important. Si c est le cas, une deuxième vérification s impose afin d identifier le service technique utilisé par un équipement qui peut être impliqué dans plusieurs Business Services. Cette deuxième vérification effectuée, chaque évènement de la séquence peut être étiqueté comme correspondant à un business service particulier ou un service technique. La séquence d évènements étiquetée est ensuite analysée par un moteur de règles définies dans la section qui nommera la séquence. Fig Processus de labélisation 6.6 Expérimentation Nous avons créé un module automatique d extraction de règles de corrélation du modèle d activité utilisateur. Notre module va utiliser notre modélisation par réseau Bayésien défini dans le chapitre 5 et implanté (voir le chapitre 7). Notre module s est basé sur une modélisation de comportements provenant d un banc de tests et composés de 26 types d évènements différents. Ce jeu de tests est décrit en détail dans la section 7. Notre module d extraction automatique

143 130 Expérimentation de règles de corrélation a utilisé des chroniques uniques comme défini dans la section Pour ce jeu de tests, 39 chroniques unitaires ont été créées regroupant de 2 à 5 classes d évènements et étant composées de entre 3 et 4 classes d évènements en moyenne. La figure 6.16 nous montre la répartition des nombres de catégories d évènements par chronique. Fig Répartition du nombre de catégories d évènements par Chronique. Les différentes chroniques vont décrire l ensemble des séquences de catégories d évènements contenues dans notre modèle d activité utilisateur. Ces chroniques ont été construites à l aide des informations portées par chaque utilisateur dans notre modèle de réseau Bayésien de référence. Les différentes chroniques comprennent 18 catégories d évènements différentes. Les catégories d évènements restantes n ont pas été prises en compte car elles représentaient des séquences d évènements d états du système (découverte de vulnérabilité) où d éléments d attaques (détection de virus ou d attaques). La figure 6.17 nous montre la répartition des différentes catégories dans les chroniques créées. Fig Répartition des catégories d évènements par chroniques. Cette figure nous présente la variété des différentes catégories d évènements utilisées lors de la création de chronique. Des similarités peuvent être constatées entre ces chroniques. L utilisation de chroniques hiérarchique peut réduire cette redondance d information. Le nombre de chroniques peut paraitre important car dans ce module nous n avons pas intégré la notion de plus grande séquence possible et de ce fait chaque étape intermédiaire de séquence est modélisée par une chronique. On peut estimer que 30% des chroniques générées pourront être réduites par une modélisation hiérarchique permettant d éviter le phénomène de

144 Extraction de règles de corrélation 131 redondance de l information et également d isoler les évènements peu probables. La figure 6.18 présente le résultat d une chronique générée automatiquement à partir de notre module. Fig Exemple de génération automatique de Chronique 6.7 Conclusion Dans cette partie nous avons présenté un module d extraction automatique de règles de corrélation. En nous basant sur le modèle des activités utilisateurs, nous générons des règles de corrélation comportementales à l aide de chroniques comme langage de description. Pour parfaire les groupes de corrélation extraits, nous avons proposé un étiquetage automatique des groupes de corrélation en s appuyant sur la description d un utilisateur ainsi que des taxonomies de Service Business et Technique. Ce module d extraction de règles de corrélation a été développé et des premiers tests ont permis d extraire plusieurs règles de corrélation unitaire d un jeu de tests. La génération automatique de règles de corrélation va permettre d enrichir les bases de connaissance des moteurs de corrélation explicite actuel. La complémentarité des règles de corrélation explicites regroupant des évènements d attaque et des règles comportementales va permettre de présenter à un analyse de sécurité un concentré d informations pertinentes.

145 132 Conclusion

146 7 Expérimentation 7.1 Introduction L expérimentation est un élément indispensable pour mesurer de la qualité de tout système. Dans la détection d intrusion, deux types d expérimentations sont généralement menées. En effet, nous distinguons les jeux de tests expérimentaux qui se rapprochent le plus possible des conditions d utilisation réelle, des jeux de tests unitaires ( cas d écoles ) qui représentent généralement des données choisies permettant d illustrer les approches utilisées. Les Systèmes de Détection d Intrusion possédant une vision locale du SI utilisent ces différents jeux de tests pour valider leur approche. Des jeux de tests comme ceux fournis par la DARPA 1 ou encore collectés lors de congrès spécialisés comme DEF CON 2, sont adaptés pour tester des systèmes de détection locale. Cependant peu de jeux de tests concernant la vision globale sont disponibles. La plupart des systèmes de détection ayant une vue globale du système utilisent uniquement des jeux de tests unitaires permettant d illustrer leur approche. Enfin, peu d entre eux positionnent leurs tests dans un contexte d utilisation réelle. Dans le cas de notre approche, nous avons validé notre système grâce à un jeu de tests unitaires provenant d un banc de tests et à un jeu de tests expérimentaux issu d un Système d Information d un grand compte. L utilisation de ces deux jeux de données va permettre de mettre en avant les forces d une modélisation précise des comportements utilisateurs ainsi que 1 Dans les années 1998 et 1999, le laboratoire Lincoln du MIT financé par la DARPA (Defense Advanced Research Projects Agency) a mené des travaux visant à réaliser une évaluation comparative de système de détection d intrusion. Cette étude a abouti à la construction d un jeu de données de tests permettant de comparer les systèmes de détection d intrusion. 2 DEFCON est une Convention de Hackers durant laquelle plusieurs équipes s affrontent en vue de compromettre le plus rapidement un SI 133

147 134 Jeu de tests simple : banc de tests leurs limites lors du passage à l échelle. Comme précisé dans le chapitre 3, notre architecture est constituée d agents répartis sur des équipements du SI. Ces agents collectent les données et homogénéisent leur syntaxe et leur sémantique. Un serveur central d analyse est utilisé pour modéliser les comportements normaux dans une phase d apprentissage et détecter des anomalies comportementales durant une phase d exploitation. Les agents vont collecter des données sur une variété de composants tels que les postes de travail, les serveurs, les bases de données, les antivirus, les firewalls, les VPNs, les proxy, les serveurs Mail/Web, les IDS, les routeurs/switch,... Notre approche se différentie des Systèmes de Détection d Intrusion traditionnels car elle collecte à la fois des informations brutes (syslog de station de travail redhat par exemple) et des données analysées (alerte IDMEF Snort). L utilisation de ces données analysées permet de réduire le volume de données traitées et d utiliser des équipements spécialisés dans la détection de phénomènes locaux (HIDS, NDS, firwall) pour effectuer une analyse globale des activités utilisateurs. Notre architecture a été déployée à la fois sur un banc de tests (ensemble de composants réellement déployés) et sur un Système d Information réel. Les différents jeux de données ainsi que les résultats obtenus sont présentés respectivement dans la section 7.2 et Jeu de tests simple : banc de tests Ce premier jeu de tests unitaires illustre nos processus de modélisation et montre la détection de différentes anomalies liées à nos scénarios d attaques. Notre premier jeu de données est basé sur un banc de tests composé de plusieurs équipements et mettant en jeu des interactions entre différents sites distants. L architecture du banc de tests est composée de trois DMZs public hébergeant des serveur Linux, Windows, plusieurs serveurs de mail Sendmail, des serveurs d applications, des scanners de vulnérabilité Qualys, Nessus, d un serveur Web, de firewalls Checkpoint, d un serveur mandataire (proxy) Squid et d un antivirus Trend-antivirus (voir figure 7.1). Plusieurs agents ont été déployés sur ce système surveillant tout particulièrement les équipements cités auparavant Composition du jeu de tests Notre système de détection d anomalies fonctionne en deux phases distinctes permettant respectivement d apprendre le comportement normal des utilisateurs (phase d apprentissage) et de détecter des anomalies comportementales (phase d exploitation). Deux jeux de tests ont été collectés pour permettre l illustration de chacune de ces phases. Notre jeu de données d apprentissage est composé d une journée de collecte sur le banc de tests. Durant cette journée plusieurs activités ont été réalisées telles que l envoi/réception de mail, la découverte de vulnérabilités, des connexions/déconnexions d utilisateurs, etc. Le jeu de tests d apprentissage est composé de 1500 évènements collectés comprenant 26 catégories d évènements différents. La figure 7.2 nous présente la répartition des différents types d évènements. La plupart des échanges effectués dans ces jeux de données correspond à des activités d authentification et à de l échange de données essentiellement applicatif ( ).

148 Expérimentation 135 Fig. 7.1 Architecture du banc de tests Fig. 7.2 Jeu de tests d apprentissage

149 136 Jeu de tests simple : banc de tests Nous avons constitué un second jeu de tests pour la phase d exploitation. Ce dernier est composé de 60 évènements usuels collectés dans une période différente de celle du jeu de données d apprentissage et de trois types de scénarios d attaques représentant un total de 24 évènements. Ces scénarios sont respectivement un scénario de déni de service (DoS), un scénario de Brute Force et un scénario de contamination par un cheval de Troie. Ces scénarios sont constitués à la fois d évènements usuels (ex : paquets reçus, mails envoyés) et d évènements anormaux (signature de DoS, Virus détecté). Six évènements sont venus compléter ce jeu de données représentant des évènements non-usuels, mais légaux, des comportements utilisateurs. Ce jeu de données est utilisé dans la phase d exploitation de notre modèle Modélisation des activités utilisateurs La modélisation des activités utilisateurs est basée sur le jeu de tests de la phase d apprentissage. L ensemble des données a été traité en une seule fois et a permis la création d un réseau Bayésien composé de 35 noeuds d alertes de fusion, de 43 liens représentés chacun pas un noeud de lien et un noeud temporel (soit 35 noeuds de lien et 35 noeuds temporels). Par l analyse de notre modèle de référence un analyste différentiera rapidement 4 scénarios d usage (Utilisation du serveur Web, Connexions VPN, Connexions d administrateurs et scénarios de Connexions distantes et locales), 2 scénarios d attaques (Contamination d un Virus, Exploitation d une vulnérabilité de DoS) et 1 scénario de vulnérabilités. La modélisation de scénarios d attaques et de vulnérabilités dans le réseau Bayésien peut être gérée de différentes façons. Tout d abord ces scénarios peuvent être écartés du référentiel normal par l utilisation de la sélection des évènements pertinents à modéliser décrits dans la section 4.6. Néanmoins, ces informations peuvent être utiles pour de futures évolutions et notamment la modélisation des comportements anormaux (signature de scénarios d attaques) qui sera détaillée dans les perspectives de la section 8.2. Dans le cas où l on souhaite conserver ces informations, ces dernières n interfèreront pas avec la détection d anomalies de la phase d exploitation car elles présentent des occurrences faibles dans le jeu de données. Ainsi tout évènement appartenant à ces scénarios est qualifié d anomalie probabiliste Résultat de la détection d anomalies La phase d apprentissage a permis la construction d un référentiel de comportement normal. Dans cette section nous allons présenter les résultats des tests effectués sur notre modèle. Ces tests ont été réalisés à l aide du second jeu de tests dédiés à la phase d exploitation. Nous avons choisi un seuil afin d identifier les évènements ayant une probabilité inférieure à un pour cent. Ce seuil a été sélectionné en calculant la moyenne et la variance des probabilités de l ensemble des évènements. Les évènements du jeu de tests d exploitation ont généré un graphe de détection comme défini dans la section 5.6 et plusieurs anomalies ont été détectées comme présenté dans la figure 7.3. Pour chaque scénario d attaques, notre moteur a détecté plus de 50% des évènements les composant. La plupart de ces déviances sont des déviances de structure. Nous pouvons estimer

150 Expérimentation 137 Fig. 7.3 Résultats de la détection d anomalies qu avec une période de données d apprentissage plus longue, l ensemble des déviances de structure serait grandement diminué au dépend des déviances probabilistes. De plus, seulement 6 évènements normaux ont été considérés comme suspicieux. Ainsi au moins 4 évènements d un scénario d attaques ont été détectés comme suspicieux permettant d assurer la détection de la totalité des scénarios d attaques. Autour de 75% des évènements appartenant à un scénario d attaques ou d anomalies ont été détectés et 10% de fausses alarmes ont été générées. Les déviances temporelles, pour leur part, ne constituent pas une détection d évènements suspicieux supplémentaires. Ces déviances constituent des informations additionnelles permettant de corroborer des déviances détectées et de ce fait d enrichir les informations portées par les déviances comportementales. Bien que notre modélisation des activités utilisateurs permette de détecter la quasi totalité des anomalies comportementales, trois points restent encore à approfondir. Tout d abord le nombre de faux positifs est encore élevé, l utilisation de notre module d évaluation des déviances comportementales devrait nous aider à diminuer le nombre de ces fausses alarmes. De plus, la quasi totalité des déviances sont des déviances de structure, il est nécessaire d effectuer des tests sur des jeux de données plus importants pour permettre une validation de notre moteur de détection. Enfin, le taux de détection d anomalies reste faible. Une période d apprentissage plus longue devrait permettre d obtenir un modèle de référence plus précis et par conséquent des résultats plus pertinents. Afin de répondre à l ensemble de ces constats, des tests de plus grandes ampleurs ont été menés. Ces tests unitaires ont permis de valider le processus de modélisation des comportements utilisateurs et nous ont assuré du bon fonctionnement de la détection d anomalies. 7.3 Jeu de test réel : grand compte Nous avons pu déployer notre architecture sur le réseau d un grand compte et effectuer des tests sur celui-ci. Pour des raisons de sécurité et confidentialité évidentes, aucune information relative à l architecture du SI, ni aucun login utilisateur et adresse IP ne seront présentés dans cette partie. Les données collectées sur ce SI proviennent de plusieurs centaines de postes clients, de plusieurs firewalls, serveurs, et systèmes de détection d intrusion.

151 138 Jeu de test réel : grand compte Composition du jeu de tests Les informations ont été collectées durant 25 jours et ont été réparties suivant deux jeux de données : un d apprentissage et un de test. Le jeu de données d apprentissage a été collecté pendant 23 jours, soit un total d environ évènements. Ce jeu de données regroupe un total de 68 catégories différentes d évènements allant des évènements d authentification aux évènements d utilisation du système. La figure 7.4 nous montre la répartition des différentes classes d évènements. La plupart des informations collectées sont des informations portant sur le serveur Web et sur les authentifications. Nous pouvons remarquer que durant la période de collecte, certaines classes d évènements sont périodiques ( Authentication_Activity.Login.SysAuth.Account.Success) et d autres sporadiques (System_Conf ig.m odif y.ip sec _P olicy.success). Afin de valider notre approche, nous avons constitué, comme préalablement, un jeu de tests composé de deux jours de collecte extraits hors de la période du jeu de données d apprentissage pour un total de évènements. Afin de s assurer du bon fonctionnement de notre moteur de détection dans un contexte réel, nous avons ajouté 410 évènements représentant différents scénarios d attaques. Ces scénarios vont refléter trois types d effets d attaques comme défini dans la taxonomie des attaques par leur effet de la DARPA ; Remote to Local, User to Root, System Access/Alter Data. D autres classes d attaques sont définies par la DARPA mais ne font pas parti de nos problématiques de vision globale. En effet, les classes Surveillance/Probe et Denial of Service sont parfaitement détectées par de nombreuses approches de détection d intrusion locale positionnées stratégiquement (à l entrée du SI ou sur un concentrateur réseau). Plusieurs variantes de scénarios des classes d attaques sélectionnées sont injectées dans le jeu de tests et définies comme suit : Les scénarios d attaques Remote to Local sont composés de deux variantes. La première représente l exploitation distante d une vulnérabilité afin d obtenir une connexion locale au SI. La seconde correspond à l exploitation d une faille locale avec un compte utilisateur valide permettant à l attaquant de se connecter au SI. Ces scénarios d attaques sont décrits dans le tableau 7.1. Variante Type d évènements Nombre d évènements 1 Authentication_Activity.Login.SSH_Account.Success 1 Authentication_Activity.Login.SysAuth_Account.Success 1 2 Authentication_Activity.Login.SSH_Account.success 1 Authentication_Config.Modify.SysAuth_Account.Success 1 Authentication_Activity.Login.SysAuth_Account.Success 1 Tab. 7.1 Description des scénarios Remote to Local Les scénarios d attaques User to Root sont composés de trois variantes. La première reflète un Bruteforce sur un compte d administrateur au travers d un compte utilisateur valide. La seconde variante représente un exploit de vulnérabilités permettant de changer les privilèges d un utilisateur en privilège d administrateur. Enfin la dernière variante de scénario définit l exploitation d une vulnérabilité d un service et de l exécution d une commande avec des droits administrateurs. Ces scénarios d attaques sont décrits dans le

152 Expérimentation 139 Fig. 7.4 Jeu de données collectées réparties sur 25 jours

153 140 Jeu de test réel : grand compte tableau 7.2. Variante Type d évènements Nombre d évènements 1 Authentication_Activity.Login.SysAuth_Account.Success 1 Authentication_Activity.Login.SysAuth_Admin.F ailed 10 Authentication_Activity.Login.SysAuth_Admin.Success 1 2 Authentication_Activity.Login.SysAuth_Account.Success 1 Authentication_Config.Add.SysAuth_Account.Success 1 Authentication_Activity.Login.SSH_Admin.Success 1 System_Activity.Stop.Audit_N.Success 1 3 Authentication_Activity.Login.SysAuth_Account.Success 1 System_Activity.Started.Service_N.Success 1 System_Activity.Execute.Command_Admin.Success 1 Tab. 7.2 Description des scénarios User to Root Deux types de scénarios permettent de représenter la classe d attaques System Access/Alter Data. La modification de la configuration du système par un utilisateur valide va constituer notre premier scénario. Le second est composé d une modification de configuration par un utilisateur ayant élevé ces privilèges. Ces scénarios d attaques sont décris dans le tableau 7.3. Variante Type d évènements Nombre d évènements 1 Authentication_Activity.Login.SysAuth_Account.success 1 System_Config.Modify.Audit_N.Success 1 2 Authentication_Activity.Login.SysAuth_Account.Success 1 Authentication_Activity.Login.SSH_Admin.Success 1 Authentication_Config.Modify.SysAuth.Account.Success 1 1 Tab. 7.3 Description des scénarios System Access/Alter Data Chacun de ces scénarios a été reproduit dix fois, en utilisant à chaque fois des attributs différents. Ces attributs (login utilisateur, adresse IP source, adresse IP destination) sont extraits du jeu de données d apprentissage et sont renouvelés à chaque itération Périmètre des tests Lors de ces tests, nous n avons pas modélisé l ensemble des dépendances temporelles et des règles comme stipulé dans la section 5.5. La section 7.2 nous a montré que les informations liées aux noeuds de lien et aux noeuds temporels constituent un complément d information pour la détection d anomalies. Afin d assurer un test efficace et une modélisation réaliste nous n avons pas modélisé ces deux types d informations pour ne par alourdir le modèle. De plus, face au nombre important d éléments dans le jeux de données utilisés, nous avons utilisé la sélection d indicateurs définie dans la section 4.6 qui nous permet d extraire uniquement les informations indispensables pour la détection d anomalies.

154 Expérimentation Modélisation des activités utilisateurs Afin d assurer une construction dynamique de notre modèle de référence, la conception de ce dernier s est effectué en plusieurs étapes. Le corpus de tests a été divisé en 440 étapes afin de rendre l apprentissage et la construction du réseau Bayésien plus pratique (consommation mémoire et CPU réduite). Chaque élément de la structure du réseau Bayésien (noeuds, liens et états) ont évolué différemment durant ces étapes et ont atteint leur stabilité à des instants différents (voir figure 7.5). Fig. 7.5 Évolution de la structure du réseau du Bayésien L évolution des noeuds (représentant les différentes classes d évènements) est stationnaire autour de l étape 330 tant dis que l évolution des liens (représentant les relations entre les classes d évènements) continue à évoluer jusqu à l étape 360. Seule l évolution des états (attributs identifiant l auteur d un évènement) semble ne jamais atteindre une stabilité. Afin de comprendre plus en détail ce phénomène, nous avons analysé en profondeur les évolutions des états de chaque classe d évènements (voir figure 7.6). Nous avons constaté que le nombre d états d un noeud particulier, le noeud Authentication _Activity.Login.SysAuth_Account.Success, continue de croitre sans cesse. Après avoir analysé ces informations avec les membres de l équipe du SI surveillé, nous avons compris que la compagnie observée possède un site de e-commerce où chaque nouveau client se voit affecter un login utilisateur sur le site. C est pourquoi, alors que le nombre d états des autres noeuds cesse de croitre autour de l étape 390, celui du noeud Authentication _Activity.Login.SysAuth_Account.Success continue d augmenter. Pour prendre en compte ce phénomène et éviter une explosion de complexité de notre modèle, nous avons ajouté une contrainte supplémentaire sur les états de ce noeud permettant de spécifier une durée de vie à tous ces états (login utilisateur). Cette durée de vie est remise à 0 pour toute réutilisation de l état concerné.

155 142 Jeu de test réel : grand compte Fig. 7.6 Évolution des états des noeuds L utilisation de la sélection des indicateurs et des séquences a permis de réduire considérablement la complexité du réseau Bayésien généré. Cette sélection a ainsi permis de réduire de 24% les noeuds de la structure et près de 60% de liens. (voir figure 7.7) Fig. 7.7 Visualisation de la Réduction du modèle Le modèle d activités utilisateurs final est un réseau Bayésien comportant 32 noeuds (hors noeuds boucles) composés de 2441 états liés entre eux par 35 liens Résultat de la détection d anomalies Une fois le modèle réalisé et entrainé, les données de tests ont été injectées dans notre moteur de détection d anomalies. Les premiers résultats relatif aux taux de détection d attaques et de faux positif sont présentés dans la figure 7.8. Cette figure distingue le taux de détection de chaque scénario en fonction de différents seuils de probabilité. Ces seuils peuvent être choisis en fonction des besoins des entreprises ou organismes. Dans le cas d un SI très sensible, le taux de détection d attaques doit être aussi élevé que possible. Un seuil de probabilité de permettant d obtenir un taux de détection d attaques de 90% avec un taux de faux positif de 14.5% est envisageable pour ce cas de figure. Dans le cas d une utilisation plus transversale de notre approche, les organismes préfèrent trouver un compromi entre le taux de faux positifs et le taux de détection d attaques. Dans ce

156 Expérimentation 143 Fig. 7.8 Taux de détection de notre approche sans Evaluation. Note : les éléments des lignes en gras correspondent respectivement au taux de faux positif pour la ligne du haut et au taux de détection d attaques pour la ligne du bas. cas de configuration, un seuil de probabilité de permet d obtenir un taux de détection d attaques de près de 79% avec un taux de faux positif en dessous de 6%. L utilisation du module d évaluation a permis de réduire sensiblement les faux positifs en altérant que très légèrement les taux de détection. Ainsi avec l utilisation d un seuil d évaluation (séparateur de communauté) de 0.614, le taux de faux positif est passé de 14.5 à 14% pour un seuil de probabilité de et conservé un taux de détection de 90%. le constat est similaire pour un seuil de probabilité de où le taux de faux positifs est passé de moins de 6% à moins de 5% sans altération du taux de détection de près de 79%. La figure 7.4 illustre les modifications des taux de détection en fonction du seuil d évaluation pour un seuil de probabilité de Ces anomalies comportementales permettent de déterminer les actions effectuées sur le SI suivant les compteurs de gain/perte d accès, de droits et d utilisation du système comme précisé dans la section 4.5. Ainsi notre système a évalué pour le jeu de tests injecté dans notre moteur que les évènements déviants concernent 172 gains d accès, 205 pertes d accès, aucun gain ou perte droits et 30 gains d utilisation du système. Ces compteurs permettent de présenter des bilans de haut niveau sur les conséquences des évènements déviants sur l ensemble du SI. a) Taux de détection d attaques b) Taux de détection de faux positifs Tab. 7.4 Évolution des taux de détection pour les différents seuils d évaluation

157 144 Conclusion La mise à jour de notre modèle permet de suivre les évolutions du système. Comme précisé dans la section 5.7.2, les éléments déviants sont évalués à l aide des évaluations de l intention, de l expertise, et de la sensibilité de la cible. Le pattern SVM mis en place permet d automatiser la mise à jour de notre modèle en stipulant un seuil d évaluation en dessous duquel les évènements déviants seront automatiquement appris. Nous avons fixé un seuil très proche du centre de la communauté des évènements normaux afin que notre système ne subisse pas d évasion du modèle (apprentissage de comportement d attaquant). Ainsi, seuls les éléments déviants possédant une évaluation très proche des comportements normaux définis dans le module de décision seront utilisés pour mettre à jour notre système. Nous avons simulé l apprentissage automatique d un évènement déviant de faible probabilité et mesuré l évolution des probabilités affectées au noeud et à l état représentant cet évènement. La figure 7.9 montre l évolution de la probabilité pour un apprentissage régulier sur 20 jours. Fig. 7.9 Evolution de la probabilité de l état du noeud Authentication_Activity.Login.SysAuth_Account.Success pour une mise à jour régulière du modèle sur une période de 20 jours Sur cette figure la probabilité de l évènement croit progressivement lors de chaque mise à jour. Dans la pratique plus l évènement va posséder une probabilité haute moins il sera considéré comme suspect. Cette figure nous montre que lorsqu un évènement déviant de faible probabilité est détecté comme appartenant à la communauté des comportements normaux, il est appris par notre modèle. Dans le cas d un seuil de probabilité de détection de 10%, l évènement déviant sera considéré comme normal après 6 apprentissages. Il faut également noté que l ensemble des évènements détectés comme normaux par notre moteur d analyse modifie les probabilités de notre modèle afin de suivre les évolutions d utilisation du système. 7.4 Conclusion Notre Système de Détection d Intrusion d anomalies comportementales appliqué vision globale permet de modéliser une activité de SI réelle et fournit un modèle humainement lisible aux analystes de sécurité. Les deux séries de tests ont permis respectivement de montrer l intérêt d un modèle complet et le passage à l échelle de notre approche. L utilisation d un modèle complet incluant les informations de temporalité entre les évènements ainsi que les types de liaisons

158 Expérimentation 145 utilisées (règles de corrélation utilisées) permet d enrichir les informations relatives aux évènements déviants et de faciliter leur interprétation. Ces informations additionnelles peuvent être utilisées pour affiner la détection d anomalies. Notre second jeu de tests a permis de mettre en avant le passage à l échelle de notre approche, avec l utilisation de notre sélection d indicateurs et de séquences nous avons pu réduire la complexité du modèle généré et construire un modèle d activités utilisateurs portant sur plus de 7 millions d évènements. Les taux de détection d attaques peuvent paraitre identiques voir légèrement inférieurs aux taux de détection des Systèmes de Détection d Intrusion comportementale. Il est vrai que certains systèmes de détection d intrusion présentent des taux de détection d attaques de l ordre de 95%, mais dans notre contexte, tous les scénarios d attaques testés sont composés d évènements qui appartiennent aux comportements normaux du système. Ces évènements ne se différentient pas nécessairement du comportement normal du SI, aussi nos taux de détection paraissent légèrement inférieurs à ceux existants. Nous pouvons estimer que près de 10% des évènements appartenant aux différents scénarios d attaques appartiennent à des comportements normaux (classe d évènements et attributs légitimes). Malgré ce constat nous atteignons des taux de détection allant de 80% à 90%. Notre module d évaluation des évènements déviants et de décision permet de qualifier les évènements déviants, de réduire les faux positifs et d automatiser l apprentissage de certaines évolutions du SI.

159 146 Conclusion

160 8 Conclusion Les outils de détection d intrusion permettent de déceler efficacement des activités malicieuses. Ces activités s insinuent dans les SI en contournant les dispositifs de sécurité. La plupart de ces systèmes de détection observent une partie locale des activités du système et ne permettent pas de détecter des activités intrusives survenues sur plusieurs éléments et parties du SI. De nouvelles architectures et algorithmes ont vus le jour pour permettre de détecter des scénarios d attaques sur la totalité du SI. Ces approches sont orientées signatures et nécessitent une description explicite des éléments recherchés. Les travaux présentés dans cette thèse portent sur la résolution de cette contrainte en proposant une détection d anomalies comportementales portant sur une vision globale du SI. Nous résumons ici les contributions de cette thèse et les perspectives liées à nos travaux. 8.1 Contributions La plupart des classifications ou taxonomies des Système de Détection d Intrusion utilise deux critères discriminant pour différentier ces systèmes : la nature des données traitées (NIDS, HIDS, méta-ids) et le mode de détection (par signature ou par détection d anomalies). Nous avons introduit un nouveau critère (section 1.2.2) permettant de différentier ces systèmes à l aide de la nature d apprentissage de ces outils de détection (Explicite, semi-explite, automatique). Ce nouveau critère de classification des Systèmes de Détection d Intrusion qui permet de spécifier comment ces systèmes génèrent leurs profils normaux ou leurs signatures d attaques constitue notre première contribution. Les systèmes de détection actuels peuvent combiner à la fois la détection d attaques connues et la détection de nouvelles attaques. La construction automatique 147

161 148 Contributions de signatures d attaques, par exemple, va permettre cette détection duale. Avec l utilisation des critères traditionnels de mode de détection ou de nature des données traitées, cette dualité n est pas identifiable. L ajout de la nature de l apprentissage comme critère va permettre cette distinction. Ainsi ces systèmes de détection d intrusion seront considérés comme des systèmes à base de signatures et d apprentissage automatique. Notre seconde contribution nous a permis de modéliser la démarche générique d un attaquant. L utilisation de l ontologie et des démarches des utilisateurs légitimes a permis de décrire la stratégie d un attaquant en modélisant ces différents objectifs et en différentiant ces actions légitimes de ces actions malicieuses. Cette description de la démarche de l attaquant permet de différentier l ensemble des étapes d un attaquants, de la reconnaissance d une cible à l utilisation d une machine compromise. Nous nous différentions des descriptions des démarches d attaquant existantes en différentiant les étapes d attaques ou de reconnaissance des actions légitimes détournées. De plus nous décrivons l inoculation d un virus dans un SI comme une étape alternative de la démarche de l attaquant. Afin de modéliser correctement les activités normales du SI, nous nous sommes particulièrement attachés à étudier le comportement des différentes entités légitimes d un SI (utilisateur classique, administrateur et système). La plupart des analyses de comportements réalisées se focalise soit sur la démarche de l attaquant, soit sur l utilisation d un composant particulier (recherche WEB, navigation WEB). Par la mise en avant des démarches génériques des utilisateurs légitimes et de l attaquant par le biais de l ontologie [53], nous avons déterminé les points de passage obligatoires d un attaquant. Cette étude permet de spécifier le type d information nécessaire à collecter ainsi que les différents composants fournissant ces informations. Cette étude a déterminé des indicateurs indispensables à la détection d anomalies comportementales sur une vision globale et à ainsi permis de délimiter le périmètre d analyse des informations. Cette sélection d indicateurs à considérablement réduit le volume d information à traiter. Cette réduction d information nous a permis de bâtir une analyse comportementale des utilisateurs sur l ensemble des SI et d expérimenter notre approche sur des données réelles. L utilisation conjointe de la normalisation des évènements collectés et de la sélection des indicateurs à observer nous a garanti un passage a l échelle de notre approche. Cette étude de comportements constitue notre troisième contribution. Notre principale contribution a été de fournir une nouvelle méthode de détection d anomalies comportementales appliquées à la vision globale. Notre approche se différentie des approches actuelles par la nature des données analysées. Basé sur l ontologie [53] décrivant tout évènement survenu sur le SI, nous modélisons l ensemble des actions des utilisateurs d un SI. Cette modélisation est réalisée à l aide des réseaux Bayésiens permettant de concentrer les différentes informations et de proposer un modèle humainement lisible. La plupart des solutions de détection de scénarios d attaques utilisent des modèles à bases d automates d états, de méthodes de DataMining, des réseaux de Pétri ou encore des chaines de Markov. En utilisant les réseaux Bayésiens comme technique de modélisation des comportements normaux des utilisateurs, nous pouvons modéliser les probabilités des séquences d actions dans un graphe réduit concentrant l ensemble des informations. L utilisation des réseaux Bayésiens dans la détection d anomalies

162 Conclusion 149 s est souvent cantonnée à l utilisation de modèle simple (réseau Bayésien naïf) ou à la modélisation de comportement déterminés (analyse de protocole). En réduisant le volume d information à traiter, nous avons pu modéliser les relations de causes à effet liant les catégories d évènements des utilisateurs d un SI. De plus, grâce à l inférence des probabilités fournies par les réseaux Bayésiens, nous pouvons déterminer les séquences de types d actions attendues en fonction des éléments observés. Ce mécanisme nous offre une détection prévisionnelle sur les évènements attendus. Notre approche se différentie également des autres par son passage à l échelle et la modélisation d interactions entre plus de 7 millions d évènements d utilisateurs. La grande partie des Systèmes de Détection d Intrusion existants permettent d effectuer des modélisation passant l échelle en modélisant uniquement des regroupements d informations (DataMining) et non des séquences. Dans notre étude, nous avons eu l opportunité de déployer notre architecture sur un SI d un grand compte et de modéliser les comportements des utilisateurs de ce système. Grâce à cette expérimentation, nous avons démontré la viabilité de notre système lors d un passage à l échelle sur des données réelles. De plus nous avons pu nous rendre compte des différents impacts d une modélisation complète sur un système réel et adapter notre système aux contraintes rencontrées (ajout d un TTL aux différents identifiant des utilisateurs, utilisation de la modélisation de la temporalité uniquement comme complément d information). Nous avons testé notre approche avec des données réelles et plusieurs scénarios d attaques couvrant trois types d effet d attaques définis par la DARPA (User to Root, Remote to Local, System Access/Alter Data). Malgré la présence de comportements normaux dans les scénarios d attaques nous arrivons à des taux de détection de 80% à 90%. Afin de rendre notre système autonome et de permettre de suivre l évolution du SI, nous avons réalisé un module d évaluation et de décision des évènements déviants. Notre module d évaluation constitue notre cinquième contribution en proposant de caractériser un évènement déviant au travers de trois propriétés, l intention de l utilisateur ayant produit l évènement, l expertise nécessaire pour produire un tel évènement ainsi que la sensibilité du composant du SI ciblé par cet évènement. C est sur ces trois critères que nous avons bâti un schéma (pattern) de décision à base de SVM. Ce pattern a été construit à l aide de données d apprentissage fournies par des analystes de sécurité qui ont classé différents évènements déviants suivant deux catégories, les évolutions normales du SI et les évènements suspicieux. La méthode de classification par SVM à construit des frontières séparant ces deux catégories d évènements. En utilisant ces frontières, nous pouvons déterminer quel évènement déviant est considéré comme une évolution du système. Cet évènement viendra alors enrichir les données du modèle de référence. Cette évaluation des éléments déviant n est que trop souvent laissé à la charge d un analyste. Utilisant des méthodes complexes, les alertes des systèmes de détection d anomalies sont bien souvent pauvres sémantiquement et difficiles à interpréter. En évaluant chaque anomalies par les trois dimensions intention, expertise et sensibilité de la cible nous accompagnons les analystes en leur proposant une représentation simple des anomalies détectées. L ajout du pattern de décision à base de SVM va également accompagner l analyste pour différentier les anomalies dangereuses des évolutions normales du système.

163 150 Perspectives Enfin, en utilisant les informations de notre modèle d activités utilisateurs, nous pouvons extraire automatiquement des règles de corrélation explicites sous forme de chroniques. Ces règles seront réutilisables par des moteurs de corrélation explicite. La création explicite de règles de corrélation est la plus part du temps focalisée sur la description de scénarios d attaques. En extrayant des règles de corrélation de scénarios d usage, notre système permet de fournir une base de règles de corrélation comportementale qui réduira sensiblement le volume d information. Afin d assurer une bonne lisibilité des règles comportementales nous avons également décrit un procédé d étiquetage permettant d extraire l objectif commun des actions contenues dans ces règles. Notre extraction de règles de corrélation semi-explicite constitue notre dernière contribution. 8.2 Perspectives Nos travaux de thèse ont abouti à la réalisation d un système de détection d anomalies comportementales appliquée à la vision globale et ont ouvert des perspectives d améliorations court terme et moyen terme. En en effet, des améliorations courts termes peuvent être apportées en ce qui concerne la détection d anomalies. Certains aspects tels que la détermination de fenêtres temporelles de détection ou l optimisation du parcours du graphe de détection pourront améliorer les performances de notre système. D autres axes de recherche restent également à dégager à moyen terme. Ainsi la réalisation d un modèle regroupement conjointement à la modélisation des activités normales et des scénarios d attaques laisse entrevoir la possibilité d une détection prévisionnelle attractive. Le contrôle de l évasion de notre moteur de détection est également un point réflexion important à prendre en considération Amélioration de la détection a) Fenêtre de détection Les premières perspectives d évolution consistent à déterminer une taille de fenêtre de détection optimale permettant de modéliser à la fois les séquences long termes des séquences plus rapides. La détection d anomalies ou de scénarios d attaques est toujours confrontée à la problématique de la taille des fenêtres de détection. Une fenêtre de détection courte va permettre une analyse rapide (voir temps réelle) des scénarios d attaques mais ne prendra pas en compte les évolutions ou les scénarios plus répartis dans le temps. A contrario, la mise en place d une fenêtre de détection longue va permettre de suivre les évolutions ou les scénarios répartis dans le temps mais nécessitera une détection plus longue qui ne pourra pas déceler des scénarios ou anomalies rapides. Deux pistes peuvent être abordées dans cette problématique. Tout d abord il est possible de calculer la taille de fenêtre de détection optimale permettant de couvrir le plus de séquences possibles. Ce calcul peut se baser sur les informations de temporalité contenues dans le modèle. Cette méthode offrira un compromis entre les séquences longues et rapides. Une autre approche consiste à différentier deux fenêtres temporelles ; une permettant de construire un graphe de détection focalisé sur les séquences d évènements rapides et l autre

164 Conclusion 151 sur des séquences plus long terme. La différentiation de ces deux graphes permettraient de couvrir la totalité des actions séquences d évènements possibles. Une gestion de cycles de vie plus complexe des évènements devra alors être mise en place pour ne pas aboutir à la création d un graphe de détection trop volumineux. Ainsi, l attribution de deux TTL différents aux évènements observés correspondant respectivement à un TTL pour la détection des séquences rapides et un TTL pour la détection des séquences longues est une piste envisageable. b) Exploration du graphe de détection Les graphes de détection sont actuellement exploités pour vérifier les probabilités conditionnelles de chaque évènement collecté dans la fenêtre de détection. Chaque séquence du graphe de détection est extraite pour déterminer sa validité. Des algorithmes d exploration de graphes existent et permettraient d optimiser la détection et l analyse des séquences d évènements. Cette optimisation permettrait de vérifier plus rapidement les relations entre les évènements et autoriseraient des fenêtre de détection plus grandes. De plus l introduction de fenêtres de détection différentes peut également alourdir le parcours du graphe de détection. La mise ne place d un algorithme optimisant le parcours du graphe de détection en permettant la détection conjointe des séquence rapides et longues est une perspective à étudier Amélioration de la modélisation L une des perspectives principales envisagée pour notre moteur est la modélisation des comportements anormaux. En choisissant de modéliser les comportements anormaux dans notre modèle, nous aurions la possibilité d anticiper des attaques éventuelles. Ces comportements anormaux pourraient être déterminés explicitement (structure et probabilité) où extraits au fur et à mesure des différents éléments observés. De cette façon notre modèle serait composé conjointement des séquences d activités normale des utilisateurs mais aussi de scénarios d attaques. L introduction des scénarios d attaques dans notre modèle nous permettrais de déterminer lorsqu un utilisateur s apprête à réaliser une attaque. Cette détection prédictive permettrait d envisager des alertes de prédiction permettant soit à un analyste de sécurité de prendre les mesures nécessaires, soit à un automate de réaction de contrer l attaque à venir. Afin de différentier les scénarios d attaques des activités légitimes, notre réseau Bayésien pourrait se voir enrichi d un nouveau type de noeud permettant de différentier le lien de causalité liant deux classes d évènements comme appartenant à l un des trois profils utilisateurs, administrateurs où attaquant. Ainsi pour tout évènement lié, nous aurions la possibilité de déterminer la probabilité d appartenance de cette séquence à l une des trois démarches utilisateurs Contrôle de l évasion de notre moteur Bien que la mise à jour de notre modèle de référence soit indispensable, cette dernière peut être utilisée par un attaquant afin de détourner notre système. Les mécanismes de mise à jour automatiques ou semi-automatiques peuvent en effet apprendre une succession de comportements déviants guidant le système afin de ne pas détecter des comportements particuliers

165 152 Discussion d attaquants. La mise en place d un système de contrôle tout particulièrement dédié à la surveillance de la mise à jour du système doit être mise en place. Pour ce faire, chaque séquence pourrait être pondérée afin de déterminer la dangerosité qu elle représente vis à vis du SI. Les propriétés d évaluation des évènements déviant décrit dans nos travaux pourraient être adaptées afin de fournir un niveau de dangerosité d une séquence apprise dans le modèle de référence. En possédant un mécanisme d analyse de l évolution de notre modèle, il nous serait possible de vérifier que les séquences contenues dans ce modèle ne tendent pas vers des comportements illégitimes. 8.3 Discussion Comme nous l avons introduit, la vision globale est devenue un enjeu majeure pour la sécurité des SI. L utilisation conjointes de systèmes de détection d intrusion par signature et de systèmes de détection d anomalies est primordiale pour, d une part détecter rapidement des scénarios d attaques connues et des utilisations anormales du système (traces d intrusion) et d autre part réduire les faux positifs des deux méthodes de détection. En recoupant les informations reçues par chaque méthode de détection, il sera possible de valider ou d infirmer la présence d attaques ou de suspicions d intrusion. Le modèle présenté est parfaitement adapté aux organismes fortement structurés. Les nouvelles architectures (pervasives, ah hoc) portent des contraintes supplémentaires telles que la non connaissance des voisins et l impossibilité de mettre en place une surveillance centrale. Notre modèle à base de réseau Bayésien pourrait être réutilisé dans ces architectures de coopération en modifiant les informations traitées. Nous pouvons envisager que chaque entité d un réseau possède deux modèles de comportement. Un modèle décrivant les activités normal d échanges avec d autres entités et un modèle global partagé avec les voisins décrivant les comportements normaux des échanges dans le réseau. Par la mise en place d une telle structure, chaque entité aurait la possibilité d identifier si les échanges avec une entité voisine comme correspondent à un activité normale vis à vis de sa propre connaissance mais également vis à vis de la connaissance globale partagée dans le réseau.

166 9 Annexes 9.1 PPOs Remote to Local PPOs L une action les plus intéressante pour un attaquant est de pouvoir effectuer des opérations autorisées localement sur un SI à Distance. Cette classe d attaque à comme pré requis générale l établissement d une connexion depuis un poste distant vers une machine locale. 153

167 154 PPOs Denial of service PPOs La perte de disponibilité de composant du système d information constitue l un des enjeux de certains attaquants. Saturant le service ou la machine cible par des paquets ou des requêtes, l attaquant vise l arrêt de fonctionnement du système ou des services visés Surveillance/probe PPOs L étape de reconnaissance (défini dans la section 5.2.3) est une étape élémentaire et indispensable pour cibler et connaître le composant du SI. Les différentes techniques citées ci-dessous permettent de récupérer des informations du SI.