Vers une détection d'intrusions à fiabilité et pertinence prouvables

28/08/2017
Publication REE REE 2006-8
OAI : oai:www.see.asso.fr:1301:2006-8:19682
DOI : You do not have permission to access embedded form.

Résumé

Vers une détection d'intrusions à fiabilité et pertinence prouvables

Métriques

13
4
3.13 Mo
 application/pdf
bitcache://b94618c887a73b92692d28870c6a32c5b18d4b36

Licence

Creative Commons Aucune (Tous droits réservés)
<resource  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xmlns="http://datacite.org/schema/kernel-4"
                xsi:schemaLocation="http://datacite.org/schema/kernel-4 http://schema.datacite.org/meta/kernel-4/metadata.xsd">
        <identifier identifierType="DOI">10.23723/1301:2006-8/19682</identifier><creators><creator><creatorName>Christophe Bidan</creatorName></creator><creator><creatorName>Guillaume Hiet</creatorName></creator><creator><creatorName>Ludovic Mé</creatorName></creator><creator><creatorName>Benjamin Morin</creatorName></creator><creator><creatorName>Jacob Zimmermann</creatorName></creator></creators><titles>
            <title>Vers une détection d'intrusions à fiabilité et pertinence prouvables</title></titles>
        <publisher>SEE</publisher>
        <publicationYear>2017</publicationYear>
        <resourceType resourceTypeGeneral="Text">Text</resourceType><dates>
	    <date dateType="Created">Mon 28 Aug 2017</date>
	    <date dateType="Updated">Mon 28 Aug 2017</date>
            <date dateType="Submitted">Sat 17 Feb 2018</date>
	</dates>
        <alternateIdentifiers>
	    <alternateIdentifier alternateIdentifierType="bitstream">b94618c887a73b92692d28870c6a32c5b18d4b36</alternateIdentifier>
	</alternateIdentifiers>
        <formats>
	    <format>application/pdf</format>
	</formats>
	<version>33439</version>
        <descriptions>
            <description descriptionType="Abstract"></description>
        </descriptions>
    </resource>
.

Repères -1 RISQUES ET SÉCURITÉ DES RÉSEAUX ET DES SYSTÈMES A COMPOSANTE LOGICIELLE (2',partie Vers une détection d'intrusions à fiabilité et pertinence prouvables . Christophe BIDAN', Guillaume HIET 1, Ludovic ME 1, Benjamin MORIN 1, Jacob ZIMMERMANN 1 Supélec, Campus de Rennes', Oueensland Uni'versi'ty of Technology, A ustrall'e' r'Innr Sécuritédessystèmes d'information, Détectiond'intrusions, Approcheparamétrée par la politique, Modélisationformelle 1. Introduction Dans la « société de l'information », la sécurité des systèmes informatiques constitue un enjeu crucial. Le contrôle de l'information traitée et partagée au sein de ces systèmes est un problème d'autant plus délicat que le nombre d'utilisateurs de ces systèmes est important. Relier ces systèmes entre eux au sein de réseaux informa- tiques, eux-mêmes interconnectés, complexifie donc la tâche des responsables sécurité. La sécurité d'un système informatique repose en pre- mier lieu sur la mise en place d'une politique de sécurité. Celle-ci peut être définie comme un ensemble de règles permettant d'assurer trois propriétés : . la confidentialité des données : seuls les utilisateurs autorisés peuvent consulter une information donnée ; . l'intégrité des données : seuls les utilisateurs autori- sés peuvent modifier une information donnée ; . la disponibilité du système : le système doit être capa- ble de rendre le service prévu en un temps borné. Une fois la politique de sécurité définie, il convient de la mettre en oeuvre au sein du système informatique. Deux approches non exclusives sont envisageables : la prévention des attaques et leur détection. La première approche, en appliquant un contrôle a priori sur les actions effectuées au sein du système, s'assure que les utilisateurs ne pourront violer la politique. Cette approche évite que le système ne se trouve dans un état corrompu, nécessitant une analyse et une correction. De ce fait, des mécanismes de prévention sont présents sur les systèmes informatiques ; il s'agit souvent de contrôle d'accès. Cependant, de tels mécanismes possèdent leurs propres limitations, qui peuvent porter sur des aspects théoriques des modèles sous-jacents ou sur leur implémentation. Ces limitations justifient le recours à des mécanismes de détection Intrusion Detection Systems (LDS). La détection d'intrusion est née, au début des années 80, de la nécessité d'automatiser les tâches d'audit des systèmes informatiques. En effet, il est parfois possible, pour un utilisateur malveillant, de contourner les méca- nismes de prévention et donc de violer la politique de sécurité que mettent en oeuvre ces mécanismes. Une telle violation de politique engendre généralement des effets de bords sur le système. Il est donc du ressort de l'admi- nistrateur du système d'analyser régulièrement l'état du système et de vérifier qu'il n'a pas été compromis. Cette tâche d'audit suppose un mécanisme d'enregistrement des événements du système au sein de « journaux » et une phase d'analyse des journaux afin d'identifier une éven- tuelle violation. L'objectif de la détection d'intrusions est d'automati- ser la tâche d'audit. Il s'agit bien, théoriquement, de détecter de manière automatique les violations de politi- SSENTIEL Les outils de détection d'intrusions actuels reposent essentielle- ment sur l'analyse du contenu de paquetsréseau,à la recherche de trace d'attaques connues. Dans cet article, nous présentons une approchealternative, ladétection comportementaleou détec- tion d'anomalies, et nous présentons l'approcheparflux de réfé- rences, forme particulièrede détection d'anomaliesimplantée au niveaudu système d'exploitation. Le mécanismede détection est ici paramétré directement par la politique de sécurité en vigueur sur le système surveillé. Une approcheformelle permet de prou- ver la fiabilité et la pertinencethéoriques de i' ! DS. SYNOPSIS Current Intrusion Detection Systems mainly relies on on-the-fly analysisof network traffic, lookingfor some know attackpatterns. In this article, we follow an alternative approach, policy-based misuse detection, and we present an approachnamed "referen- ces flow,which can be implemented within an operatingsystem. The intrusiondetection system is here directly configuredby the security policy enforced on the monitored environment.A formal modelis usedto provethe theoreticalaccuracyandcompleteness of the approach. REE NI 9 Octobre2006 1 Repères RISQUES ET SÉCURITÉDES RÉSEAUXET DES SYSTÈMES / A COMPOSANTE LOGICIELLE partie) Faux Approche positif par scénarios Actions illégales ..,..... Modèle de Base de \Modè) ede. Basede\ comportement Faux signatures i jy Faux11 negatif Faux positif. < 1 1 1r t l r Actions \. . légales lfaux negatif Approche comportementale Figiti-e 1. Pi-oblèiiies des IDS. que de sécurité, qu'on appelle intrusions. Dans la prati- que, les outils actuels ne sont cependant pas configurés directement par la politique. Aussi, s'ils détectent certai- nes intrusions, ils détectent aussi des tentatives d'intru- sions infructueuses, ce qui peut être souhaité, ou non. En outre, la relative naïveté des algorithmes de détection conduit à un nombre élevé d'alertes, dont une part signi- ficative esten fait constituée de faussesalertes(faux posi- tifs). Enfin, certaines intrusions peuvent nepasêtre détec- tées (faux négatifs). Afin de qualifier un IDS, on s'intéresseà safiabilité, qui est sa capacité à émettre une alerte pour toute viola- tion de la politique de sécurité, et à sapertinence, qui est sa capacité à n'émettre une alerte qu'en cas de violation de la politique de sécurité. Un IDS estparfaitement fiable en absencede faux négatif ; il est parfaitement pertinent en l'absence de faux positif. Comme nous l'avons mentionné ci-dessus, les IDS actuels ne sont ni fiables ni pertinents. Notre conviction est qu'une des causes essentielles de cet état de fait est l'empirisme qui préside à la conception de ces outils. Notre objectif est donc de proposer une approche for- melle, dans laquelle le modèle de détection implanté dans l'IDS présente des capacités que l'on peut prouver. En d'autres termes, notre objectif estde construire un modèle de détection formel dont on prouvera la fiabilité et la per- tinence théoriques. Dès lors, on implantera ce modèle, la conformité de cette implémentation au modèle restant à prouver. Cet article est organisé comme suit. Dans la section 1, nous présentonsl'architecture classique des IDS actuelle- ment utilisés. Dans la section 2, nous nous intéressonsà une méthode particulière de détection, l'approche com- portementale (ou détection d'anomalie). Enfin, dans la section 3, nous présentons de manière informelle une approche comportementale particulière, développée au sein de notre équipe : l'approche par flux de références. 2. Architecture classique d'IDS Nous décrivons dans cette section les trois compo- santsqui constituent classiquement un système de détec- tion d'intrusions [1]. La figure 2 illustre les interactions entre cestrois composants.Un capteur est chargéde col- lecter des informations sur l'évolution de l'état du sys- tème et de fournir une séquenced'événements qui carac- térise cetteévolution. Un analyseur détermine si un sous- ensemble des événements produits par le capteur est caractéristique d'une activité malveillante. Un manager collecte les alertes produites par le capteur, les met en forme et les présente à l'opérateur. Éventuellement, le manager est chargé de la réaction à adopter. Nous détail- lons ici chacun de ces trois composants. 2.1. Le capteur Le capteurobservel'activité du systèmepar le biaisd'une sourcededonnéeset fournit à l'analyseuruneséquenced'évé- nementsqui renseignentsurl'évolution del'état du système. 1 REE N'9 Octobre2006 Vers une détection d'intrusions à fiabilité et pertinence prouvables Source de données Atitité " \ -- Sonde \1 1 1 alerte Capteur 7--7vénement --*- Analyseur alerte - -- ManagerManager Figure2.Ai-chilecttii-e classiclite d'iii7 IDS. Le capteur peut se contenter de transmettre directe- ment ces données brutes, mais en général un prétraite- ment est effectué. Ce traitement permet, par exemple, de filtrer un certain nombre de données considéréescomme non pertinentes, afin de limiter la quantité des informa- tions à analyser par la suite. De plus, le capteur réalise généralement une mise en forme des données brutes acquises afin de présenterà l'analyseur des donnéesutili- sant un certain format d'événements. Ces fonctions sont par exemple réalisées par les modules Preprocessors et Decoder de l'IDS open-source SNORT. On distingue classiquementtrois types de capteursen fonction des sources de données utilisées pour observer l'activité du système : . Les capteurssystèmecollectent des donnéesprodui- tes par les systèmes d'exploitation des machines, notammentpar le biais desjournaux d'audit système ou par celui des appels systèmes invoqués par les applications.On désigneles IDS utilisant descapteurs systèmepar l'acronyme HIDS (Host-based IDS). . Les capteursréseaucollectent les données en écou- tant le trafic réseauentre les machines, par le biais d'une interface spécifique. On parle alors de NIDS (Network-based IDS). . Les capteursapplicatifs collectent les donnéesprodui- tes par une application particulière, avec laquelle des utilisateurs sont susceptibles d'interagir, comme un serveurWeb ou un serveurde basede données.L'ap- plication doit bien sûr être instrumentéeà cet effet. L'avantage principal des capteurs réseauréside dans leur capacitéà surveiller un grand ensemblede machines. Cette caractéristique simplifie le déploiement et la main- tenance d'une solution de détection visant à garantir une couverture optimale du réseau surveillé. L'approche sys- tème est plus complexe à déployer car elle nécessiteune multiplication du nombre de capteurs dans le réseau.De plus, la complexité de la collecte desdonnéespar cescap- teurs peut dégrader sensiblement les performances des systèmessur lesquels ils sont installés. Cependant, on peut s'interroger sur la pérennité des capteurs réseaux pour trois raisons principales. Premièrement la montée en débit des réseaux contraint fortement les capacités de collecte de l'intégralité du tra- fic. Les constructeurs de NIDS ont recours à descapteurs matériels spécifiques pour accélérer la collecte, mais la détection d'intrusions dans le coeurde réseaupeut poser problème. Deuxièmement, les capteursréseaune peuvent analyser le trafic chiffré. Or, la prise en compte progres- sive desproblèmes de sécurité tend à généraliserl'utilisa- tion du chiffrement dans les protocoles réseaux,rendant à terme les capteurs réseau inopérants. Enfin, l'analyse seule du trafic réseau s'avère souvent insuffisante pour assurerune détection fiable et pertinente desviolations de politique de sécurité, l'IDS ne disposant que de trop peu d'information sur les systèmes attaqués. 2.2. L'analyseur L'objectif del'analyseurestdedéterminersi le flux d'évé- nementsfourni parle capteurcontientdesélémentscaractéris- tiques d'une activité malveillante. Deux grandesapproches REE W9 Octobre2006 1 Repères RISQUES ET SÉCURITÉDES RÉSEAUX ET DES SYSTÈMES A COMPOSANTE LOGICIELLE(2' partie) ont été proposées: l'approche comportementale(anomal y detection)et l'approchepar scénarios(misusedetection). . Dans l'approche comportementale, une attaque est qualifiée par la mesure d'une déviation sensible du système surveillé par rapport à un comportement de référence, réputé sain et défini auparavant. . Dans l'approche par sénarios, le système de détec- tion possèdeune base de signatures qui modélisent les différents scénarios, c'est-à-dire les différentes attaques connues. L'analyse consiste à rechercher l'occurrence d'un motif caractéristique d'une atta- que dans le flux d'événements. L'approche par scénarios est actuellement la plus commune. Elle s'appuie sur une base de signatures d'at- taque. Le systèmede détection consiste alors à reconnaî- tre la présencede signaturesparmi les traces d'audit four- nies par les observateurs. Plusieurs techniques ont été proposéesqui reposenten général sur desmécanismesde reconnaissancede motif (pattern matching). Le pattern matching possède l'avantage d'être une méthode fiable car déterministe. Cependant, la difficulté vient de la définition desmotifs. En effet, ceux-ci doivent être suffisamment précis pour pouvoir discriminer les dif- férents types d'attaques, mais suffisamment génériques pour pouvoir détecterles différentes variantes d'un même type d'attaque. Une signature trop générique conduira à l'augmentation du nombre de faux positifs, diminuant par là même la fiabilité. La technique de détection par scénarios nécessiteen outre une maintenanceactive du systèmepour mettre àjour régulièrement la basede signatures.En effet, le systèmene peut détecterquedesattaquesconnuesa priori : il faut donc pouvoir réactualiser cette connaissance. Ceci implique notamment un coût de maintenanceimportant. De plus, se pose le problème du choix du langage de signaturespour lequel il n'existe pour l'instant pas de standard, même si l'on peut considérer,dansla pratique, que les signatures« à la SNORT » constituentun standardde facto. En théorie, cetteapprochedevrait produire peu de faux positifs car le systèmeutilise uneconnaissanceapriori sur les attaques.Cependant,la mise en place de signaturestrop génériquesconduit souventàuneprésencede faux positifs. Les IDS utilisant ce type de technique restent toutefois faciles et rapidesà mettre en oeuvre. Nous nous intéresseronsdans la suite de cet article à l'approche comportementale. Notre objectif est de con- tourner les difficultés de l'approche par scénarios. On peut noter que les deux approches de détection ne sont pas exclusives, car un même manager peut être ali- menté par des analyseurs implantant les deux approches, puis combiner les résultats à l'aide d'un mécanisme de corrélation d'alertes [2]. Cependant,cettepossibilité n'est guère utilisée dans la pratique. 2.3. Le manager Le manager est responsable de la présentation des alertes à l'opérateur (fonction de console de manage- ment). Comme expliqué précédemment, il est aussi le composant qui réalisera les fonctions de corrélation d'alertes, dans la mesure de leur disponibilité. Enfin, il pourra assurerle traitement de l'incident, par exemple au travers des fonctions suivantes : . confinement de l'attaque, qui a pour but de limiter les effets de l'attaque ; . éradication de l'attaque, qui tented'arrêter l'attaque ; . recouvrement, qui est l'étape de restaurationdu sys- tème dans un état sain ; . diagnostic,qui estla phased'identification duproblème, decescauseset qui peutéventuellementêtresuivi d'ac- tions contrel'attaquant(fonction deréaction). Du fait du manque de fiabilité des systèmesde détec- tion d'intrusions actuels, les réactions sont rarement auto- matisées,car elles peuvent setraduire par un dénis de ser- vice en casde faux positif. 3. Approche comportementale Cette approche repose sur la modélisation d'un « comportement normal », appelé profil, et la détection des écartspar rapport à ce profil. Il en découle deux pro- blèmes majeurs : . la définition du « comportement normal » et la construction du profil de référence ; . la définition des critères de déviation et la fixation des seuils associés. Plusieurs méthodes ont été proposéespour construire le profil de référence : on distinguera ici les méthodesuti- lisant des mécanismes d'apprentissage (section 2.1) de celles qui n'en utilisent pas (approche par spécification, section 2.2, et approche paramétrée par la politique, sec- tion 2.3). 3.1. Profil généré par apprentissage Classiquement, la détection d'une anomalie repose sur un modèle statistique du comportement des utilisa- REE N-9-70 tt78 Octobre 2006 Vers une détection d'intrusions à fiabilité et pertinence prouvables teurs. Denning a ainsi identifié trois familles de modèles statistiques [3] : . les modèles simples utilisant des seuils sur des variables. Ces variables peuvent correspondre à la fréquence d'apparition d'un événement. Ce modèle simple est parfois utilisé par d'autres composants logiciels comme les mécanismes d'authentification qui considèrent comme anormal un nombre d'échecs successifsdonné lors de la phased'authen- tification par identifiant et mot de passe ; . les modèles utilisant les moments statistiques (moyenne, écart-type...). Ces modèles offrent plus de souplesseet permettent de mieux discriminer les comportements anormaux. Cependant, ils reposent sur l'hypothèse que le comportement « normal » d'un utilisateur peut être modélisée par une loi sta- tistique, ce qui n'est pas toujours le cas ; . les modèlesdérivés du modèle de Markov. Les évé- nements ne sont alors plus considérés indépendam- ment les uns desautresmais en séquence.Le modèle considère en effet les différents états successifsdu système. Lorsque le système change d'état, l'IDS vérifie la probabilité d'occurrence de cette transition. Si cette dernière est suffisamment faible, le compor- tementobservéest considéré comme anormal. Les deux premières catégories permettent d'établir facilement un modèle comportemental. Néanmoins, leur pouvoir de discrimination est relativement limité et les nouveaux modèles comportementaux d'IDS appartien- nent généralementà la dernière catégorie. Forrest propose par exemple de s'intéresser aux séquencesd'appels sys- tème [4]. L'auteur utilise l'exemple du système immuni- taire qui est capable chez les êtres vivants de distinguer les cellules appartenant à l'individu des corps étrangers. Bien que les différentes cellules possèdentdescaractéris- tiques variables du fait de la diversité des fonctions assu- rées, le système immunitaire dispose d'une définition assezprécise du « soi », c'est-à-dire de l'ensemble des caractéristique définissant les cellules appartenant à un même individu. Un tel système peut efficacement détec- ter des corps étrangers, même s'il ne les a jamais vus auparavant. L'auteur a établi expérimentalement que des séquences courtes d'appels système (typiquement 6 appels successifs) constituent de bonnes signatures com- portementales d'un processus donné. Cette signature varie d'un processus à un autre, mais reste spécifique à chaquetype d'application. Une intrusion setraduit par un comportement anormal d'un programme donné qui voit sa signature évoluer sensiblement. L'auteur a expérimenté cette approche en développant un prototype d'HIDS. La source d'information est consti- tuée des traces d'appels système qui sont systématique- ment analysées.L'IDS implémentant cettetechnique fonc- tionne alors en deux temps : . dans un premier temps, l'IDS constitue une base de données d'apprentissage. Les signatures sont obte- nues par une technique de fenêtres glissantes ; . dans un deuxième temps, l'IDS compare les séquen- ces d'appels systèmesobservéesavec les signatures de la base et comptabilise le nombre de disparités. Au delà d'un certain seuil de concordance, l'IDS considère le comportement du systèmecomme anor- mal et lève une alerte. Cette approche constitue un moyen simple pour éta- blir un profil de référence et mettre en oeuvreun méca- nisme de détection comportemental. Toutefois, les perfor- mances de cette technique restent difficiles à prévoir car beaucoup de paramètressont fixés de manière empirique. Ce problème est d'ailleurs caractéristique des modèles comportementaux qui établissent le profil de référence par apprentissage.Cesmodèlesconsidèrent de plus qu'un comportement anormal au sens statistique du terme caractérise une intrusion. Or ce n'est pas toujours le cas et cela conduit à un nombre important de faux positifs. La phase d'apprentissage s'effectue sur des données enregistrées avant la mise en place de l'IDS : se pose le problème de l'apprentissage d'éventuelles intrusions. En effet, cette phase requiert une base de données à la fois saine et exhaustive par rapport au comportement attendu des utilisateurs dans l'environnement réel. Pour éviter la mise en place d'un profil trop rigide et pour pouvoir s'adapter aux changementsde comportement des utilisa- teurs, certains IDS proposent des phasesde réapprentis- sage au cours de l'utilisation de l'IDS. Il reste tout de même un risque qu'un attaquant arrive à modifier le pro- fil de référence à son avantagepar déviation progressive. De manière générale,fixer desseuils peut s'avérer délicat et les résultats peuvent être pénalisés par un sur-appren- tissage. L'approche comportementale est intéressante car, ne faisant aucune hypothèsesur les comportements illégaux, elle permet en théorie de détecter de nouvelles formes d'intrusions (attaques dites zero-day). La définition du profil de référence par apprentissagerestant délicate, il a alors été proposé de définir le profil de référence en excluant toute forme d'apprentissage : le comportement est défini au travers d'une « spécification de comporte- ment d'un applicatif » (voir section 2.2) ou au travers de la définition d'une politique de sécurité (voir section 2.3). 3.2. Modèle par spécificationde comportement La spécification de comportement est une perspective REE N,9 Octobre2006 1 Repères RISQUESET SÉCURITÉDES RÉSEAUX ET DES SYSTÈMES A COMPOSANTE LOGICIELLE (2- partie) qui nous paraît prometteuse. Cette approche initialement proposée par Ko [5], s'appuie sur une spécification du comportement attendu du système (en fait de chaque applicatif) et sur l'analyse de traces d'audit au niveau des appels système. Un travail amont d'analyse et de forma- lisation de la spécification du comportement desapplica- tions est donc nécessaire.L'auteur insiste cependant sur le fait que seuls certains programmes dits « sensibles », c'est-à-dire susceptibles de modifier l'état de sûreté du système, doivent être surveillés. Pour l'environnement UNIX, cela setraduit souvent par desprogrammes exécu- tés en mode privilégiés (SUID). La spécification du comportement des programmes correspond à l'expression, pour ce programme, des contraintes imposéespar la politique de sécurité. C'est la politique qui permet de déterminer les traces légales de l'application. La miseaupoint desspécificationssetraduit alorspar la définition d'un langageformel dont plusieurs modèlesont étéproposés.Ko proposeainsi l'utilisation d'une grammaire adaptéeaux environnementsdistribués (Parallel Environe- ment Grammars).Sekardéfinit un langagede spécifications à base d'expressions rationnelles (regular expression) constituéderèglesde la forme « pattern action » [6]. Chaqueaction est ainsi réaliséelorsquele motif pattern estvérifié. L'ensemblede cesrègles permet alors de spéci- fier le comportementattendudesprogrammes,mais permet égalementd'exprimer dessignaturesd'attaquesconnuesen termesde comportement.L'auteur proposeen effet decom- pléter l'approche par spécification avec des méthodespar scénariosd'attaques. La spécification de comportement constitue une approche relativement récente qui permet une prise en compte explicite de la politique de sécurité. Elle permet la détection d'attaques inconnues et propose une bonne couverture tout en générant, au moins en théorie, peu de faux positifs. Cette approche, encore jeune, n'a encore donné lieu qu'à peu d'implémentations dansdesoutils de détection. Deux implémentations ont été proposées par Ko et Sekar pour valider leurs modèles. Plus récemment, la société NOVELL a proposé Apparmor, un systèmede détection/prévention utilisant un modèle comportemen- tale à basede spécification de comportements. Le principal inconvénient de cette approche est qu'elle nécessite un effort lors de la mise en place des spécifications, et ceci pour chaque application à surveil- ler. Une autre approche a été proposée par Ko, dans laquelle la politique n'est plus exprimée en termesde spé- cification explicite pour chaque application : on parle alors d'approche paramétrée par la politique de sécurité (policy-based IDS). Nous la présentons dans la section suivante. 3.3. Approche paramétrée par la politique de sécurité Un modèle d'IDS paramétré par la politique de sécu- rité repose sur : . un modèle du systèmesurveillé ; . un modèle de la politique de sécurité en vigueur sur ce système ; . un modèle de détection, c'est-à-dire de l'algorithme de détection. L'utilisation de méthodesformelles permet de prouver, par un théorème, que le comportementde l'IDS est cohé- rent vis-à-vis de la modélisation du systèmeet de la politi- que. Cette cohérencedu comportementde l'IDS s'exprime au traversdespropriétésde fiabilité et de pertinence. Le premier modèle d'IDS paramétré par la politique de sécurité a été proposé par Ko [7]. Celui-ci s'est inté- resséaux problèmes de violation d'une politique d'inté- grité par attaquede type race-condition. Cette forme d'at- taque correspond en fait à un problème particulier de syn- chronisation : l'attaquant profite d'un problème de syn- chronisation entre les opérations d'un processus« privilé- gié » pour amener le systèmedans un état non sûr. Ko et al. modélisent le système par une machine à état et la politique de sécurité par une propriété de « non-interfé- rence ». Ils montrent ensuite que la détection en temps réels des violations de cette politique peut être réalisée par un algorithme prouvé par un théorème de déroule- ment. Cet algorithme a été implémenté au sein d'un HIDS sous Linux. Les expérimentations réalisées ont montré que l'IDS est alors capable de détecter les violations de politique d'intégrité résultant d'une attaquede type race- condition. Ces travaux sont intéressants et sont parmi les pre- miers à proposer un modèle théorique prouvé de détec- tion. L'avantage par rapport à la spécification de compor- tement réside dans le fait qu'il n'est pas nécessaire de spécifier un profil par application, la politique étant spé- cifiée globalement pour le système.Le principal inconvé- nient est que les hypothèsesde ce modèle sont assezres- trictives. Le spectre des attaquesprises en compte par le modèle est donc assezrestreint : seulesles attaquesvio- lant les politiques d'intégrité par race-condition sont détectées.Nous présentons en section 3 un modèle plus générique, le modèle à flux de références, conçu au sein de notre équipe. 4. Flux de références L'idée principale de notre approche est de doter les systèmes d'exploitation utilisés couramment (Windows et la famille UNIX) d'un dispositif de détection d'intru- 1 REE N,9 Octobre2006 Vers une détection d'intrusions à fiabilité et pertinence prouvables sions qui réponde aux principes suivants : * ta détection des violations de la politique de sécurité doit être fiable et pertinente. Le but est de limiter autant que possible le nombre de faux positifs et celui de faux négatifs. La pertinence est une pro- priété qui nous intéresseparticulièrement, car le fai- ble niveau de pertinence constitue une limitation importante des IDS actuels. On cherche à détecter des violations effectives de la politique : les tentati- ves infructueuses, inévitables et nombreuses, ne nous intéressent pas. . l'approche doit être indépendante des modèles ou connaissancesa priori sur les attaques.Le but est de faire le moins d'hypothèses possibles sur la manière dont la politique pourra être violée par un attaquant, pour se donner toutes les chances de détecter ces violations. L'efficacité globale de l'IDS doit également dépendre le moins possible de l'expertise de l'utilisateur ou admi- nistrateur du système. Les tâches de paramétrages ou administration doivent être réduites. Ceci exclut donc le recours à un mécanismesd'apprentissage, de mise àjour de basede donnée, etc. Seule la politique de sécurité, en termes de propriété d'intégrité et de confidentialité des données,est prise en compte par notre approche. Sur les systèmesd'exploita- tion qui nous intéressent, le mécanismede contrôle d'ac- cès discrétionnaire définit les droits des utilisateurs sur les fichiers. La configuration même de ce mécanisme de contrôle d'accès (c'est-à-dire les droits et les ACL UNIX ou Windows) peut être considérée,pour notre mécanisme de détection, comme la spécification d'une politique de sécurité. Nous considérons que l'interprétation de la poli- tique par le contrôle d'accès discrétionnaire pose pro- blème du fait que ce mécanisme contrôle l'accès au conteneur d'information, sans tenir compte de l'évolution potentiel du contenu effectif. Notre idée est donc de bâtir un IDS permettant de vérifier la légalité des flux d'infor- mation au sein du systèmed'exploitation. Pour cela il est nécessaired'effectuer un contrôle sur les conteneursd'in- formation du système tout en tenant compte de l'évolu- tion du contenu. Le contrôle mixte conteneur/contenu constitue le coeurde notre approche. Comme indiqué ci-dessus, une approche paramétrée par la politique de sécurité supposeune modélisation du système, de la politique de sécurité et du processus de détection. Notre approche repose sur la formalisation de ces modèle, permettant une preuve des propriétés de fia- bilité et de pertinence de la détection. Dans la suite de cet article, nous ne présentons qu'une brève approche infor- melle. Le lecteur intéresséseréférera à [8]. Notre modèle du systèmed'exploitation est constitué : . d'objets, conteneursd'information du système, qui modélisent les fichiers, page mémoires ou socket réseaux ; . d'opérations qui permettent de faire évoluer l'état du système et qui modélisent les appels système engendrantdes flux d'information entre objets. Un systèmeest donc constitué d'un ensembled'objets qui, à un instant donné, contiennent une information par- ticulière qui caractérise leur valeur. L'ensemble des valeurs desobjets détermine l'état global du système: on parle d'état systèmestructuré. L'évolution de la valeur des objets, donc de l'état du système, est réalisée par le biais d'opérations exécutées au sein du système. Ces opérations sont observables et c'est l'observation de la successiondes exécutions de ces opérations, appelée trace, qui permet au mécanisme de détection de suivre l'évolution de l'état du système. Le but du mécanisme de détection est alors de déterminer si l'évolution de l'état du système observé est légale au regard de la politique de sécurité. Cela supposebien sur une modélisation de la politique. Notre approcheconsisteessentiellementà suivre les flux d'informations entreobjetsdu système.Il esten effet possi- ble d'interpréterunepolitique d'intégrité et deconfidentialité en termes de flux légaux entre objets. Intuitivement, si un mêmeutilisateurpeutd'une part lire un objet (parexemplele fichier « fichier_lu ») et d'autre part écrire dans un autre objet (par exemplele fichier « fichier_ecrit »), alors le flux d'information de « fichierju » vers« fichier_écrit » estpos- sible. Inversement,s'il n'existe pasd'utilisateur, au sein du système, disposant à la fois d'un droit de lecture sur « fichier_lu » et d'un droit d'écriture sur « fichier_écrit », alors le flux d'information de « fichier lu » vers « fichier_écrit » estillégal. Il estpossibled'inférer automati- quementl'ensemble des flux légaux d'information à partir des droits du mécanisme de contrôle d'accès. Etant donné une séquenced'opérations observéeset une politique de sécurité définie en termes de flux légaux, le mécanisme de détection d'intrusion doit pourvoir : . identifier les flux d'informations crééspar les opéra- tions, . vérifier la légalité de chacun des flux d'informations identifiés. Afin de satisfaire ces deux objectifs, les notions de méthode et d'invocations ont été introduites dans le modèle de détection. Fondamentalement, on identifie chaque opération par les accèsaux objets effectués. Pour REE NI 9 Octobre2006 1 Repères -.11- RISQUES ET SÉCURITÉ DES RÉSEAUX ET DES SYSTÈMES A COMPOSANTE LOGICIELLE (21-1 partie) w 0.' " 1\w ü r (9 1 " 1 "'\. /- " < ( :) Ill) 1 .\, W2 i// 0 : Fi,-ure 3. Exeiiple de séqttence d'ol ? éi-ation. différencier les types d'accès sur les objets (lecture ou écriture), on fait appel à la notion de méthode telle que définie dans l'approche orientée objet : les objets, conte- neurs d'informations, disposent également de primitives permettant d'accéder au contenu de l'objet. On distingue deux types de méthodes : read pour accéder à ? - lité de l'objet contenu de l'objet et write pour modifier l'intégralité du contenu de l'objet. On appelle invocation l'appel d'une méthode sur un objet. Dès lors, une opéra- tion est vue comme un ensemble d'invocations. Ceci per- met d'identifier une opération comme un flux d'informa- tion entre objets. On suppose que les opérations sont connues (ainsi, la table des appels système sous Linux est connue) : il est donc possible de modéliser chaque opération par un ensemble d'invocations. L'observation d'une séquence d'opération permet alors de déduire les flux d'informa- tion créés comme le montre l'exemple suivant. On suppose que l'on observe une séquence d'opérations t = [Wl, W2] avec Wl - 01-read, 02.read, 03.write et W2= to3.ead, 04.read, o5.write) comme indiqué sur la figure 3. De cette observation, on peut déduire l'existence d'un flux direct d'information entre (ol, o2) et 03. De même, il existe un flux indirect entre (ol, 0 ?, 04) et 05. Cet exem- ple amène un certain nombre de remarques : . la notion de flux ne se limite pas a des couples sour- ces/destination, c'est dans le cas général un pro- blème mufti-sources ; . l'exécution en séquence d'opération crée par com- position des flux d'information, comme c'est le cas ici par l'intermédiaire de l'objet 03. Afin de traiter les différents cas, on introduit la notion d'interférence entre invocations. Un ensemble d'invoca- tion interfèrent dans une trace s'il existe un objet, au sein du système, dont la valeur dépend de l'exécution de ces invocations. Plus précisément, l'exécution de ces invoca- tions est absolument nécessaire pour que cet objet prenne cette valeur. Dans l'exemple de la figure 3, on peut remar- quer que l'ensemble ol.read, o2.read, 03-write interfère de même que {oj.read, o2.read, 04.read, ou {°l'read, o ?.read, 04.read, 05-write). En revanche, to.read, o2.read, 03.read ou ol.read, 02.read, 03.read, 04.read n'interfèrent pas. En effet seule la valeur d'un autre objet 06 pourrait dépendre de ces invocations. Or l'objet 03 n'est qu'un intermédiaire vis-à-vis de la valeur finale de 05 qui pourrait être obtenu sans invocation de 03.read, par exemple à l'aide d'une unique opération {oj.read, 02.read, 04.read, 05.write. Cette opération est, du point de vue de la valeur finale de 05, équivalente à la séquence d'opérations t. Dès lors, il est possible d'exprimer une politique de sécurité en termes d'interférences légales entre invoca- tions. Une opération est alors légale si les invocations qui la composent peuvent légalement interférer. Un problème se pose alors si l'on étudie la légalité d'une trace. Il a en effet été montré dans l'exemple précé- dent que l'exécution d'opérations en séquence créait des interférences par composition. Il faut alors vérifier égale- ment la légalité de ces interférences naissant de la com- position des opérations. On pourrait envisager de stocker en mémoire l'historique des opérations observées, mais cela pose bien sûr le problème de l'explosion de l'occu- pation mémoire. Nous avons donc proposé une autre solution afin de tenir compte de l'évolution du contexte, 1 REE NI 9 Octobre2006 donc de l'historique des opérations exécutées. L'idée intuitive consiste à faire évoluer les règles de légalité des opérations, afin d'appliquer la politique de flux définie initialement. Ceci nous conduit aux notions de domaine et de référence. Considérons une politique autorisant l'ensemble d'in- vocations ol.read, 02-read, 03-write) à interférer ainsi que l'ensemble (oj.read, 04.read, 05-write). Supposons qu'en revanche l'interférence de 02.read, o.wr//e/soit illégale. Si l'on reprend l'exemple de la figure 3, en observant séparément chacune des opérations, chacune apparaît comme étant légale. Or la composition de ces deux opérations fait apparaître une interférence entre 02.read et 05.write qui est interdite par la politique de sécurité. Il convient donc de modifier les règles de léga- lité des opérations de telle sorte que W2 soit considérée comme illégale lorsqu'elle est exécutée en séquence après W j. Ceci est pris en compte au sein de notre modèle par les fonctions de référence. Afin d'exprimer la politi- que de sécurité à l'instant initial (c'est-à-dire lors de l'ins- tallation de l'IDS), on associe un domaine à chaque ensemble d'invocations pouvant interférer. Afin de connaître les domaines associés à chaque invocation, on fait appel à une fonction de référence qui renvoie, pour une invocation donnée, l'ensemble des domaines asso- ciés. Une invocation peut en effet interférer avec plu- sieurs ensembles d'invocations et dans le cas général, plusieurs domaines peuvent donc être associés à une même invocation, on appelle alors « références » les ima- ges de la fonction de référence. Dans la pratique, on asso- cie un identifiant numérique unique à chaque domaine et la fonction de référence est implantée en mémorisant pour chaque objet les identifiants associés. La règle de légalité d'une opération peut alors s'expri- mer de la façon suivante : pour qu'une opération soit légale au regard d'une politique de sécurité exprimée par une fonction de référence, il faut que les invocations qui constituent cette opération possèdent au moins une réfé- rence en commun. Cela revient à exprimer le fait qu'il existe un domaine commun associé à toutes les invoca- tions de l'opération et donc que l'ensemble de ces invo- cations peuvent interférer au vu de la politique de sécu- rité. En reprenant toujours l'exemple de la figure 3, on définit deux domaines dj " ol.read, 02.read, 03.write et d2 = 03-read, 04-read, °s.write). La fonction de référence associée ro donne ainsi ro (ol.read) - dl, ro (o4.read) = d2l, etc. D'après la règle de légalité des opérations, l'opération Wj ol.read, 02.read, 03.write) est donc légale car les invocations de cette opération possèdent un domaine commun : dl. Considérons maintenant la deuxième opération : W2 = 03- read, 04. read, 05- write. Si l'on applique telle quelle la règle de légalité des opéra- tions, W2sera considérée comme légale. Or nous avons vu précédemment que cette opération est illégale du fait de l'exécution préalable de wl. La nécessaire prise en compte de ce contexte est réalisée en modifiant la fonc- tion de référence afin que l'opération w2 soit considérée comme illégale. Cette modification ne doit être réalisée que sur les objets dont l'état à été modifié par l'opération précédente. De plus, seul le contenu de l'objet ayant évo- lué, ce sont les références de l'invocation en lecture qui doivent être modifiées. Dans l'exemple de la figure 3, suite à l'exécution de l'opération wh seules les références de o3.read doivent ainsi être modifiées. Cette modification doit traduire le fait que le contenu de l'objet en question dépend de l'ensemble des contenus des objets lus dans la précédente opération. La règle de modification des références est donc la suivante : Suite à l'exécution d'une opération wn'étant donnée une .fonction de référence r,, il convient de définir une nou- vellefonction de référence rr,,, telle que.- -pour tous les objets o accédés en écriture par w,,, r,,+] (o.read) est égale à l'ensemble des références communes à toutes les invocations en lecture de Wn ; . dans tous les autres cas, les références restent inchangées. Ainsi, en revenant à l'exemple, suite à l'exécution de w, les références restent inchangées sauf pour l'invoca- tion Oj.rea. Étant donné que ro (o.read) _ (dl) et ro(02.read) - dj), nous avons rl (o3 read) - dl. Dès lors, la règle de légalité des opérations nous permet d'af- firmer que W2 est illégale au vue de la fonction de réfé- rence ri car il n'existe plus de domaine commun à toutes les invocations de w ?. Un théorème de détection nous permet d'affirmer que les règles de légalité des opérations et de modification de la fonction de référence permettent d'assurer une détec- tion théoriquement fiable et pertinente. Cette approche a été implantée sur un HOST IDS sous Linux, BLARE. L'algorithme de détection fonctionne en deux temps : . pour chaque opération observée, c'est-à-dire pour chaque appel système, la règle de légalité des opéra- tions est vérifiée et une alerte est éventuellement émise ; . les références associées aux objets accédées sont ensuite mises à jour selon la règle de modification des références. REE N'9 Octobre2006 1 Repères RISQUES ET SÉCURITÉ DES RÉSEAUX ET DES SYSTÈMES A COMPOSANTE LOGICIELLE (2 " " partie) 5. Conclusion Nous avons présenté dans cet article une approche de détection d'intrusions dite comportementale. Les diffé- rentes formes que peut prendre cette approche ont été expliquées, puis une approche originale, paramétrée par la politique de sécurité, a été détaillée. Une formalisation de cette approche, non présentée dans cet article, a été réalisée. Elle permet de prouver la fiabilité et la perti- nence du modèle de détection. En d'autres termes, une intrusion implique la levée d'une alerte ; une alerte impli- que qu'une intrusion a effectivement eu lieu. Références il] H DE BAR, M. DACIER et A. \NESPI -'A RevisedTaxonomy for Intrusion-Detection Systems " - Annales des Télécom- munications, 55, n'7-8, 2000 [2] L. ME, Z. MARRAKCHI, C. MICHEL, H. DEBAR et F CUPPENS. " La détection d'Intrusions, les outils dOIVent coopérer " - Revue de l'Electricité et de l'Electronique. pp5O-55. No 5, mai 2001, [31 DE DENNING -'An Intrusion-Detection Model " - IEEE transac- tion on Software Engineering - 13, 2, pp. 222-232, 1987 [4] S. FORREST, S.A. HOFMEYR et A. SOMAYAJI - " Computer Immunology - Communications of the ACM ", 40, 10, pp. 88-96, October 1997. 151 C. KO, M. RUSCHITZKA et K. N. LEVITT - " Execution Mom toring of Security-Critical Programs in a Distributed System A Specification-based Approach " - Proceedings of the 1997 IEEE Symposium on Security and Privacy, pp. 175-187, May 1997 [6] R. SEKAR, Y CAI et M. SEGAL'A Specification-Based Approach for Building Survivable Systems " - Proceedings of the 21 st National Information Systems Security Conference NISSC'98), pp. 338-347, October 1998. [7] C. KO et T REDMOND - "Nonnterference and Intrusion Detec- tion " - Proceedings of the IEEE Symposium on Security and Privacy, 2002. [81 J. ZIMMERMANN, L. ME et C. BIDAN -'An Improved Reference Flow Control Model for Policy-Based Intrusion Detection " - Proceedings of the 8th European Symposium on Research in Computer Secunty (ESOR ! CS). October 2003. Les auteurs Christophe Bidan a obtenu le titre de docteur en informatique de l'Université de Rennes 1 en 1998 sur le thème de la sécurité dans les systèmes d'information. II a ensuite effectué un séjour post- doctoral à l'Imperial College de Londres, puis rejoint, début 1999, le groupe sécurité de Gemplus en tant qu'architecte de sécurité. Depuis août 2000, Il occupe un poste d'enseignant-chercheur à Supélec, dans l'équipe de recherche SSIR (Sécurité des Systèmes d'informat on et Réseaux). Ses domaines de recherche sont la sécu- rité dans les réseaux et la détection des intrusions paramétrée par la politique de sécurité Il est membre du comité d'organisation de SSTIC (Symposium sur la Sécurité desTechnologies de l'information et des Communications), et co-responsable du Mastère Spécialisé en Sécurité des Systèmes d'Information de Supélec et de l'ENST de Bretagne Il est Professeur de l'Enseignement Supérieur à l'Ecole Nationale d'Ingénieurs deTunis et à l'Ecole Centrale de Lille. Ses activités de recherche et d'enseignement relèvent du domaine de l'automatique et portent sur la modélisation, l'analyse et la synthèse des systèmes continus certains ou incertains, par approches conventionnelles ou non conventionnelles, et concernent, plus récemment les systèmes discrets. Guillaume Hiet est ingénieur ENSAM et Supélec 2005). Il est depuis 2005 doctorant dans l'équipe SSIR de Supélec, grâce à une bourse DGA/CNRS. Guillaume travaiiie sur le diagnostic des alertes émises par les outils de détection d'intrusions comportementaux. Ludovic Me est ingénieur Supélec 87), docteur de l'Université de Rennes 1 (94) et titulaire d'une HDR de cette même Université (2003 Il est depuis 1988 enseignant-chercheur à Supélec, où il anime depuis 1997 l'équipe de recherche en sécurité des systèmes d'information et réseaux (équipe SSiR). Son domaine de prédilec- tion est la détection d'intrusions, mais Il s'intéresse aussi à la sécu- rrté des réseaux auto-organisés (ad hoc, P2P). Il est membre du comité de pilotage du symposium RAID (Recent Advances in Intrusion Detection) dont Il a co-présidé l'édition 2001. Il est auteur ou co-auteur d'une trentaine de communications internationales. Il est ce- responsable des traités IC2 sur la sécur té des systèmes dis- tribués. Il participe régulièrement à des comités de programme de conféren- ces internationales et est membre du comité éditorial de la revue " European Research Journal in Computer Virology " Il est membre du conseil d'évaluation du domaine SSI du CELAR/DGA, du comité d'experts SSI du CNRS, des comités d'évaluation de projets des programmes " Télécom " et " Sécurité et Informatique de IANR. II enseigne ! a détection d'intrusions et la sécurité dans plusieurs orga- nismes d'enseignement supérieur (Universités de Rennes 1, de Tours et de Limoges, ENSTB, ESAT ESEO, StCyr, ENSAI et, bien sûr, Supéiec). Benjamin Morin après l'obtention d'un dlplôme d'ingénieur en informatique de l'INSA de Rennes, a soutenu une thèse de doctorat sur le thème de la corrélation d'alertes dans le domaine de la détec- tion d'intrusions. Il a ensuite poursuivi ses travaux de recherche pendant deux ans au sein du laboratoire " Network and Services Security " de France Télécom, en tant que responsable technique d'un projet dont l'ob- jectif était de développer une ptate-formeSiM (Security information Managementl opérationnelle. Depuis octobre 2005, il travaille comme enseignant-chercheur au sein de l'équipe sécurité des sys- tèmes et des réseaux de Supélec. Ses sujets de recherche portent sur la sécurité des systèmes d'informations, en particulier la détec, tion d'intrusions. Jacob Zimmermann est titulaire d'un DEA de l'Université de Paris, d'un mastère de Supélec et d'un doctorat de l'Université de Rennes 1, réalisé dans l'équipe SSIR de Supélec. Son travail a porté sur l'étude d'un système de détection d'intrusions paramétré par la poli- tique de sécurité. Jacob a ensuite effectué un séjour post- doctoral à Brisbane, Australie, dans la Queensland University of Technology. Il est actuellement chercheur dans cette même Université. 1 REE W9 Octobre 2006