Evaluation des systèmes de détection d'intrusions

30/08/2017
Publication REE REE 2006-6
OAI : oai:www.see.asso.fr:1301:2006-6:19705
DOI :

Résumé

Evaluation des systèmes de détection d'intrusions

Métriques

11
4
2.37 Mo
 application/pdf
bitcache://38bd106c96a176e986553f4fc7b97de2cc925ce0

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-6/19705</identifier><creators><creator><creatorName>Anas Abou el Kalam</creatorName></creator><creator><creatorName>Mohammed Gad el Rab</creatorName></creator></creators><titles>
            <title>Evaluation des systèmes de détection d'intrusions</title></titles>
        <publisher>SEE</publisher>
        <publicationYear>2017</publicationYear>
        <resourceType resourceTypeGeneral="Text">Text</resourceType><dates>
	    <date dateType="Created">Wed 30 Aug 2017</date>
	    <date dateType="Updated">Wed 30 Aug 2017</date>
            <date dateType="Submitted">Mon 15 Oct 2018</date>
	</dates>
        <alternateIdentifiers>
	    <alternateIdentifier alternateIdentifierType="bitstream">38bd106c96a176e986553f4fc7b97de2cc925ce0</alternateIdentifier>
	</alternateIdentifiers>
        <formats>
	    <format>application/pdf</format>
	</formats>
	<version>33477</version>
        <descriptions>
            <description descriptionType="Abstract"></description>
        </descriptions>
    </resource>
.

Dossier J RISQUES ET SÉCURITÉDES RÉSEAUX ET DES SYSTÈMES À COMPOSANTE LOGICIELLE (l'ce partie) Evaluation des systèmes de détection d'intrusions 0 Anas ABOU EL KALAM, Mohammed GAD EL RAB et L/FO-ENSI de Bourges Mots clés Sécuritédessystèmes, Détectiond'intrusions, Evaluation, Test Arbrededéfaillance Si aujourd'hui les produits de détection d'intrusion sont légion, les techniques d'éva- luation des " systèmes de détection d'intrusion " (IDS pour " Intrusion Detection Systems ") sont encore dans un état embryonnaire. Pourtant, l'étude de ce problème fondamental devrait nous aider à identifier les points les plus critiques à surveiller ou à corriger dans les IDS, à pouvoir comparer les fonctionnalités, les performances ainsi que les caractéristiques de plusieurs IDS, et à estimer s'il est rentable de mettre en oeuvre telle ou telle défense supplémentaire. 1. Introduction Les systèmesactuels sont de plus en plus complexes et ouverts sur Internet. Il en découle un nombre croissant d'attaques. D'ailleurs, selon des études récentes en France, les dépensesen solutions de sécurité ont connu une croissance de 15,5 % entre 2003 et 2004 ; cette hausse se confirme pour l'année 2005 (1 113 millions d'euros) pour atteindre une croissancede 17,4 % par rap- port à 2004. Néanmoins, alors que les " systèmesde détection d'in- trusion " (IDS) sont indispensablesau sein d'une architec- ture de sécurité, environ 60 % des administrateurs réseau n'en avaient pas encore installé un. Cela peut s'expliquer par la complexité desIDS, leurs faiblesses, mais aussi par le manque de critères de choix et d'évaluation de ces outils. En effet, il est important de définir des métriques, des modèles ainsi que des méthodes d'évaluation (quan- titatives et qualitatives) des IDS. Très peu de recherchessesont intéresséesà ce thème. Quelques tentatives de grande envergure ont bien été entreprises [1, 2, 3, 4] mais elles possèdentplusieurs fai- blesses,notamment : le manque de donnéesréalistes qui peuvent être utilisées pour modéliser le problème et vali- der les expériences ; et l'absence de méthodologie systé- matique pour l'évaluation. Tandis que le premier point devrait profiter des données collectées par les systèmes dits de pots de miel qui commencent à être déployés dans le monde entier [5], le deuxième point reste un axe sérieux de recherche à explorer. Le restede cet article est ai-ticulécomme suit : le cha- pitre 2 dressel'état de l'art ; le chapitre 3 présenteles tech- niques usuelles d'évaluation des IDS ; le chapitre 4 pro- pose un ensemble de métriques ainsi qu'une nouvelle méthode systématiquepour l'évaluation des IDS ; le cha- pitre 5 centre l'étude sur l'évaluation du point de vue du " concepteur " ; enfin, le chapitre 6 identifie les enjeux majeurs liés à ce domaine. 2. Les systèmes de détection d'intrusion La détection d'intrusion peut être définie comme l'en- semble des pratiques et mécanismes qui participent au ESSENTIEL SYNOPSIS Cetarticleproposedenouvellesmétriquesainsiqu'uneméthode génériquepourl'évaluationdesIDS.Notreapprochecombineles techniquesdesécurité(test,analysedumodèle)et desûretéde fonctionnement(arbresdedéfaillances).Danslebutd'assisterles développeursdesIDSpourlocaliserlescausesdesdéfaillances, et pourinterpréterlecomportementdecesoutils,nouscentrons notreétudesuruneévaluationorientée"composants " Thispaperproposesnewmetricsaswella diagnosticevaluation ofIDS.Ourapproachcombinesthefaulttreeanalysiswiththeeva- luationbytest.Thegoalis to identifysourcesof failurewith res- pectof IDSarchitecturesandcomponentsinorderto repairoralle- viatethemandto provideadeveloperorientedevaluation REE N'6/7 Jtiiii/jiiillet 2006 1 Dossier RISQUES ET SÉCURITÉ DES RÉSEAUX ET DES SYSTÈMES A COMPOSANTE LOGICIELLE ! " partie) diagnostic des attaques ou à la détection des erreurs qui peuvent mener à la défaillance d'un système de sécurité. Un IDS n'est rien d'autre que l'implémentation des prati- ques et mécanismes de détection d'intrusion [6]. Le but étant de signaler toute tentative de s'introduire dans un système informatique. On parle d'ISP ou système de pré- vention d'intrusion lorsque j'IDS possède la capacité de réagir (prendre des contre-mesures automatiquement). Actuellement, on dispose d'une large panoplie de techniques, projets (IDES, NIDES, DISCOVE RY, NSM, Securenet), et produits (tels que snort, stick et sneeze) liés aux IDS. Décrire l'état de l'art de l'existant, ne serait ce que brièvement, serait illusoire. Le lecteur pourra se référer à [6, 7] pour une description historique ou une caractérisa- tion riche des différentes solutions de détection d'intrusion. Dans cet article, nous nous limiterons volontairement à décrire quelques points essentiels. Rappelons tout d'abord qu'il existe deux types d'IDS : . les IDS sur réseau (NIDS, pourNetworkBasedIDS, qui observent les paquets circulant sur le réseau ; ce sont des machines indépendantes dédiées à la détection d'intrusions ; . les IDS sur hôte (HIDS, pour Host Based IDS), qui observent le comportement du système, en particu- lier les appels systèmes, ou qui analysent les infor- mations d'audit ; il s'agit alors de fonctions inté- grées au système qu'ils observent. En outre, les techniques de détection d'intrusions se répartissent en deux classes : détection d'anomalies, aussi appelée approche comportementale, et détection par signature, dite détection de mauvais usage, détection par l'apparence ou encore approche par scénario (fig. 1) [8]. La détection d'anomalies consiste à comparer le com- portement observé d'un utilisateur à une référence de comportement normal de cet utilisateur. Toute déviation entre les deux comportements déclenche une alerte. Différentes méthodes ont été proposées pour définir ce qui est normal : des outils statistiques, des systèmes experts, des méthodes inspirées de l'immunologie, des approches bayésiennes, etc. La détection par signature est fondée sur la comparai- son du comportement observé avec une référence corres- pondant à des scénarios d'attaques connus. Le principe consiste à considérer que tout ce qui est décrit dans la base d'attaques est reconnu comme intrusif ; le reste est considéré comme normal. De nombreux outils utilisent cette approche, on peut citer à titre d'exemple, Re (ilSecure, NFR, Dragon et Snort [9, 10]. Ces deux types de détection se distinguent par leurs taux - théoriques - de fausses alertes (faux positifs) et de non-détections (faux négatifs) [6, 8]. La principale faiblesse de l'approche comportemen- tale réside dans la construction de la " référence de com- portement normal ". Souvent, on passe par une phase d'apprentissage qui peut se dérouler en environnement (-), 1]:1l , l) rIlli-1tUr" ali - (-i'i (j ,-, -1u 1 f oLervc '. (- , , 1 -.1 i Il .i,i f, % +el* \,-.-.-- !.idl«F.ltlli:vt " > .1 1> [-1- t 1 1 1 (_jeIttiiil,ld'c!LrJ._;JuS Figtrre 1. Techniquesde détection d'intrusion. réel ou artificiel. Dans le premier cas, il faut être sûr qu'aucune intrusion n'ait lieu durant cette phase ; dans le deuxième cas, tout comportement normal invisible à ce moment qui se révélerait ensuite en exploitation donnera lieu à une fausse alerte (faux positij). Une autre faiblesse est liée à la capacité de s'adapter aux évolutions et varia- tions que le système peut subir. Si le modèle est trop strict, toute déviation légère, non due à une intrusion, générera une fausse alerte. Par contre, si le modèle est trop lâche, il laisse passer les attaques qui sont très pro- ches du comportement normal (faux négati L'approche basée sur la connaissance a l'avantage d'identifier quel type d'attaque est en cours (avec relati- vement peu de faux positifs, du moins en théorie), mais ne permet de détecter que les symptômes d'attaques connues. De plus, cette méthode est très coûteuse dans la mesure où il faut tenir compte non seulement de toutes les attaques et vulnérabilités existantes ou possibles, mais aussi de la manière avec laquelle elles peuvent être exploitées et implémentées par les attaquants. Pour pallier les problèmes liés à chacune de ces méthodes, des travaux plus récents tentent de disposer d'un système de détection d'intrusions qui prend en entrée aussi bien des données réseaux (provenant des NIDS) que des données systèmes (provenant des HIDS), en les analysant selon une méthode croisée utilisant à la fois les approches comportementale et par signature. Ces travaux font coopérer différents outils afin de corréler les alarmes, et de limiter ainsi les taux de faux négatifs et de faux positifs. D'un point de vue historique, Anderson (en 1980) puis Denning (projets IDES et NIDES pour Intrusion Detection Expert System et Network IDES) furent les pre- miers à utiliser des méthodes d'analyse statistique du comportement pour la détection d'intrusions. A la fin des années 80, le système MIDAS (Monitoring, Intrusion Detection, Administration System) et le projet NSM (Network Security Monitor) ont combiné les techniques comportementale et par scénario. En France, Debar et Me sont les premiers à proposer respectivement l'utilisation des réseaux neuronaux et des algorithmes génétiques dans ce domaine. REE W6/7 Jtiin/juillet 2006 Evaluation des systèmes de détection d'intrusions Au niveau des produits commerciaux, on a tout d'abord vu apparaître des HIDS basés sur la connaissance des attaques (comme AAFIX et ASAV), puis des NIDS (tels que snot, stick, sneeze), puis des IDS hybrides (tel que Prelude). On remarque ainsi que, certes, il existe une multitude d'outils, mais aucune méthode pour le choix de l'IDS le mieux adapté. Il semble donc nécessaire d'exa- miner et d'évaluer les IDS, aussi bien d'un point de vue " utilisateur final " que " constructeur ". 3. Évaluation des IDS Nous distinguons deux grandes classes d'évaluation des IDS : évaluation analytique et évaluation par test. 3.1. Évaluation par test L'un des plus anciens travaux d'évaluation par test est celui de Puketza et al. [1]. La procédure de test suivie vise trois objectifs de performances : identification des intru- sions, utilisation des ressources et test de charge Il stress test ". Pour cela, ce travail se base sur la politique de sécu- rité (ensemble de règles précisant les propriétés de sécurité à satisfaire, ainsi que les actions permises ou interdites), et utilise un ensemble de scripts simulant des cas de test pour des sessions normales et intrusives. Il met en oeuvre non seulement des attaques séquentielles provenant d'une seule session, mais aussi des attaques concurrentes prove- nant de plusieurs machines ou sessions. Un autre travail significatif, dont le but est l'évalua- tion comparative de plusieurs HIDS, a été réalisé par IBM en 98 [3]. Arrivant au constat qu'il est difficile de modé- liser le comportement des utilisateurs, ce travail génère le trafic de fond (trafic normal et événements non intrusifs) en utilisant des jeux de tests construits par les dévelop- peurs du système d'exploitation, tandis que les attaques sont sélectionnées dans une base de données propre à IBM. La plate-forme de tests est générique et utilise des clients et serveurs contrôlés par une station unique. Ce travail, certes important, souffre des limites suivantes : le test ne concernait que des HIDS et ne s'intéressait qu'aux attaques FTP ; même si le rapport final indique que quatre HIDS ont été comparés, rien n'a été dit sur les métriques ni sur les résultats et leurs interprétations. Par ailleurs, en collaboration avec le laboratoire MIT, le DARPA a sponsorisé deux projets ambitieux sur l'éva- luation des IDS en 1998 puis en 1999 [2]. Le but était de fournir un recueil de données de test (i.e., trafic de fond et activités intrusives) pouvant être utilisé par les évalua- teurs des IDS. La première idée était de reprendre le tra- fic normal du réseau opérationnel de l'Air Force ; néan- moins, les craintes d'utiliser les " vraies " données person- nelles ou d'endommager le réseau opérationnel ont poussé le DARPA à ne considérer que des données stati- tiques collectées sur le réseau des bases de l'Air Force. Les attaques étaient sous forme de scripts nouveaux ou collectés à travers des sites spécialisés sur Internet. DARPA 98 a utilisé 300 instances d'attaques appartenant à 38 " classes d'attaques ", tandis que DARPA 99 en énumé- rait 50 classes. Globalement ces attaques sont du type : écoute sur le réseau ; utilisateur distant qui se fait passer par un utilisateur local ; utilisateur qui essaye d'obtenir les droits " root " ; déni de service. Notons également que les données collectées concernaient à la fois HIDS (e.g., données d'audit de stations Solaris, disk dump de machi- nes UNIX), et des NIDS (e.g., en capturant des paquets). Les travaux du DARPA ont utilisé les métriques : taux de détection et le taux de fausses alarmes. Afin de repré- senter le résultat de l'évaluation, ils ont repris les courbes ROC (pour Receiver Operational Curves), initialement utilisées dans le domaine de détection de signaux (par les radars, par exemple). Dans ces courbes, le taux de fausses alarmes est représenté sur l'axe des abscisses tandis que le taux de détection est dessiné sur l'axe des ordonnées. Au niveau des outils de test, iperf et tcpreplay ont été utilisés pour la génération de trafic capturé par tcpdump ; Frageroute pour la génération des attaques par fragmen- tation et des techniques d'évasion, nessus et nmap pour le scanne et l'analyse de vulnérabilités ; snot pour la génération de trafic pour snort. John McHugh a critiqué, à raison, les évaluations de DARPA. Il a surtout insisté sur trois problèmes essentiels : génération des données de test, métriques utilisées et pré- sentation des résultats [12]. 3.2. Évaluation analytique Contrairement à l'évaluation par test, l'évaluation analytique porte sur la définition de méthodes permettant de maîtriser le modèle. Le travail le plus important dans ce domaine est celui d'Alessandri. Il propose un modèle descriptif du IDS [11] visant à pallier les problèmes cités précédemment et à fournir une documentation aux concepteurs (des IDS). L'évaluation consiste ainsi à : classifier les attaques selon leurs caractéristiques observables par le IDS, . décrire le comportement du IDS, notamment la manière avec laquelle il collecte et analyse les infor- mations ; déterminer si un certain type d'attaques sera détec- table par le IDS ou pas. Le tableau 1 dresse une comparaison des principales caractéristiques des deux techniques d'évaluation des IDS. 3.3. Discussion De manière globale, nous pouvons identifier plusieurs faiblesses dans les méthodes classiques d'évaluation. Le premier point est l'utilisation d'approches non sys- tématigues. En effet, la plupart des méthodes de test des IDS sont des approches plutôt " ad-hoc " : la sélection des paramètres du système, des métriques et des données de REE N 6/7 Juin/juillet 2006 Dossier RISQUES ET SÉCURITÉ DES RÉSEAUX ET DES SYSTÈMES À COMPOSANTE LOGICIELLE (ieepartie) Place dans le cycle de vie Cible Entrées Caractéristiques évaluées Effets de l'environ- nement Niveau de connaissances requis Évaluationpar test 1 Évaluation analytique Aprèsl'implémeritation Implémentation Donnéesréelles ou synthétisées Performances,capacités de détection Peuventêtre considérés Connaissancesur le IDS nonobligatoire, évalua- tion boîtenoire Spécification et conception ModèteduiDS Modèle/classe d'attaques Capacitésde détection Ne sont pasconsidérés Bonneconnaissancesur le IDS, évaluationboîte blanche Tableau 1. Description des niéthodes d'évaluation des IDS. test est souvent arbitraire et non justifiée. Le deuxième point est la " non-représentativité " des données de test. Ni le trafic de fond (généralement de quelques kbit/s, ni les données d'attaques ne correspon- dent à la réalité d'Internet (plusieurs Mbits/s). L'IDS éva- lué se comporte ainsi différemment quand il est déployé dans un environnement réel. Le troisième point est la sensibilité des données de test aux variations de l'environnement. Malheureusement, le comportement des algorithmes de détection d'anomalies (probabilités, réseaux de neurones, etc.) est étroitement lié à l'environnement. Par conséquent, la nature, la régularité ainsi que la variation des données collectées lors de la phase d'apprentissage (ou des données de test) auront un impact important sur les performances de l'IDS. La dernière faiblesse que nous soulevons est la non- pertinence des métriques. Les gens ont souvent tendance à sélectionner des métriques faciles à mesurer, sans voir l'étendue réelle de leurs efficacités. Prenons à titre d'exemple le taux de fausses alarmes ; il peut être le nom- bre de fausses alarmes divisé par le nombre de sessions ou divisé par le nombre de paquets. Néanmoins, si ce deuxième dénominateur peut suffire lors de l'évaluation d'un IDS simple, ce n'est pas le cas pour un IDS à états qui analyse des sessions. Pour pallier certaines de ces limitations, le chapitre suivant propose une nouvelle méthodologie générique pour l'évaluation des IDS. 4. Méthode pour l'évaluation des IDS La figure 2 présente, de manière globale, une métho- Besoin des'utilisateurs Bnt d'Evalnation Eii'ii-oiiiieiiieiit SF)SDI Phcl-e 1 Technique d'évaluation Paranatres >Istèiile et cliai£e; ge (Work] f î Factems ilétiiqiies (IOTS) Sélection de charge (DOTS) f ._._---_. Plia.PC2 Expérimentation ---- Analyse et inteyrétation des domiées T Présentation des resrdtaîs Reconuuencer, si nécessaire Figure 2. Méthodologie pour 1,évaluation des IDS. REE No 6/7 Juin/juillet 2006 dologie dont l'objectif principal est le développement d'une évaluation systématique suivant des étapes précises. Deux grandes phases peuvent être identifiées : une phase de préparation et une phase d'expérimentation. Tout d'abord l'évaluateur (utilisateur final, construc- teur, développeur) exprime un certain nombre de critères (fiabilité, détection, réactivité, facilité de mise en oeuvre et adaptabilité, performance, plusieurs canaux d'alerte) ; ceux-ci devront nécessairement être pondérés en fonction du contexte de l'étude. En effet, alors que les besoins fonctionnels concernent essentiellement la détection, les besoins de performances traitent des aspects liés à la vitesse, l'utilisation de la mémoire, la charge CPU, et les besoins d'utilisation concernent les problèmes liés à la facilité de configuration, mise à jour et utilisation, ergo- nomie, etc. Il est donc nécessaire de clarifier les besoins et de les traduire en exigences des IDS : avoir une bonne détection ; générer peu de fausses alarmes ; résister aux attaques visant le IDS lui-même ; nécessiter peu de res- sources ; être tolérant aux fautes (par exemple par la redondance de certains composants). Il faut également prendre en considération des carac- téristiques de l'IDS. En effet les algorithmes, ainsi que les techniques utilisées dans la conception et l'implémenta- tion de l'IDS (réseaux de neurones, algorithmes généti- ques), peuvent influencer l'évaluation. Ensuite il faut tenir compte de l'environnement. Par exem- ple, les caractéristiques d'un réseau académique sont dif- férentes de celles d'un réseau militaire ou commercial. Des connaissances sur le système d'exploitation, les ser- veurs, les fichiers, les bases de données, etc. peuvent éga- lement être pertinentes dans la procédure d'évaluation. Bien évidemment, on ne considère que les facteurs (à savoir les paramètres ajustables et contrôlables) les plus pertinents pour l'étude. Par exemple, pour les NIDS, ces facteurs peuvent être liés au trafic (type de trafic, lon- gueur des paquets, bande passante). Pour les HIDS, il serait intéressant d'identifier le système (plate-forme, version), les applications et les services qui tournent sur la machine, les vulnérabilités non encore corrigées, etc. On peut également considérer les facteurs reliés au IDS lui-même comme les règles de signature, et l'algorithme de détection ; pour un IDS basé anomalie, on peut identi- fier par exemple l'algorithme d'apprentissage et le seuil du profil. Notons que, moyennant des modifications mineures, le résultat de cette phase peut être réutilisé plusieurs fois ; en effet, les besoins des utilisateurs et les caractéristiques de l'environnement ou de l'IDS peuvent être identiques dans différentes évaluations. La deuxième phase de notre méthodologie commence par choisir la technique d'évaluation (analytique ou par test). Celle-ci dépend de l'objectif de l'évaluation, de l'étape dans laquelle on l'applique et de notre connais- Métriquesmacroscopiques reliéesà ladétection Detectionratio False Alarm ratio Métriquesmicroscopiques de détection Detectionratioperattacktype False Alarm ratio per attack type Evénements capturés/ attaquesnondétectés Événementsnoncapturés/ attaquesdétectés IntrusiveEventsDropRatio Métriquesreliées auxressources UtilisationduCPU Utilisation mémoire Définition DR= Nombre(nbre)d'attaquesdétectées /nbre totald'attaques FAR=Nbredefaussesalarmesgénérées/ nbretotal d'alarmesgénérées Définition Nbred'attaquesdétectéesd'uncertain type/nbretotald'attaquesdecetype Nbredefaussesalarmesgénéréesd'un certaintyped'attaques/nbretotalde faussesalarmesgénérées Nbred'attaquesnondétectéesdontles événementsontétécapturés/nbretota d'attaquesnondétectées Nbred'attaquesdontlesévénements n'ontpasétécapturés/nbretotal d'atta quesnondétectées Nbred'événementsintrusifsnoncapturés/ nbred'événementsintrusifs Définition PourcentageduCPUutiliséparleIDS Pourcentagedelamémoireutilisé Tableau 2. Proposition et caractérisation de niétriques. sance sur le IDS (tableau 1). Ensuite, il faut construire les données de test, en tenant compte du type des fonctions qui seront testées (telles que la capacité du NIDS à détec- ter les attaques par fragmentation) ; du niveau de détail (certains algorithmes sont sensibles au contenu de la charge des paquets) ; les facilités de reproduction et d'ex- ploitation. Vient ensuite la pierre angulaire du processus d'évalua- tion : la définition des métriques. En effet, si elles sont mal définies, les résultats de l'évaluation peuvent être faux ou biaisés. Dans le tableau 2 nous proposons un ensemble de métriquespouvant être utilisé dansce domaine. Nous pro-metriques pouvant e e posons également quelques recommandations qui peuvent être intéressantes dans cette étape : iln'y a pas de métriques absolues, mais seulement des métriques relatives à chaque cas de test ; ils dépendent de l'objectif et de la cible de l'évaluation ; . pour plus d'expressivité, les résultats de l'évaluation doivent être spécifiés à travers plusieurs métriques ; . nous évitons les métriques ou dénuées de sens (e.g., taux de détection) ou génériques et ambiguës (e.g., résistance aux attaques de déni de service). La méthodologie ainsi développée sera recentrée dans le chapitre suivant sur les besoins des développeurs. REE N 6/7 Juin/juillet 2006 Dossier RISQUES ET SÉCURITÉ DES RÉSEAUX ET DES SYSTÈMES À COMPOSANTE LOGICIELLE (1'epartieJ 1 5. Evaluation orientée " composant " Afin d'aider les développeurs à interpréter les com- portements de leurs IDS, à découvrir les causes de défail- lance et à les localiser au niveau des composants, nous proposons dans ce paragraphe une évaluation orientée " composant". En effet cette tâche nous paraît importante, d'autant plus qu'actuellement, excepté quelques travaux s'intéressant aux algorithmes de détection, très peu de tra- vaux se sont intéressés à relier le comportement de l'IDS au composant défaillant. L'idée est de combiner les techniques d'évaluations (par test et par analyse du modèle), les informations four- nies par les pots de miel ainsi que les méthodes de la sûreté de fonctionnement, en particulier, les arbres de défaillance, appelés aussi arbres de fautes (AdF). Rappelons tout d'abord ces deux notions : Un pot de miel est un système informatique public volontairement vulnérable à des failles connues visant à attirer les pirates, afin d'étudier leurs stratégies. Le port ciblé par l'attaque, les ports scannés, les outils et les sour- ces d'attaques sont des exemples de données actuelle- ment collectées par les pots de miel. Un AdF est un diagramme logique utilisant une struc- ture arborescente pour représenter les causes de défaillan- ces et leurs combinaisons conduisant à un événement redouté (racine de l'arbre). Le calcul des coupes minima- les permet d'identifier les chemins critiques, et donc de déduire les éléments matériels et logiciels du système dont la défaillance contribue le plus à la réalisation de l'événement redouté. La quantification des AdF permet de calculer l'indisponibilité, la fiabilité ou les performan- ces. Dans l'annexe, nous présentons un AdF générique pour les IDS. Dans un premier temps, nous avons défini l'événement redouté, puis nous avons représenté les rela- tions de cause à effet par des portes logiques (ET, OU) qui permettent de spécifier le type de combinaison entre les événements intermédiaires qui conduisent à l'événement analysé. Dans ce travail, nous proposons de combiner les pots de miel et les AdF. En effet, d'une part les informations recueillies par les pots de miel peuvent aider à guider les processus de sélection des attaques, à construire les don- nées de test et à fournir des données quantitatives à l'AdF. D'autre part l'AdF peut aider à mieux interpréter le com- portement du IDS, à localiser la source de défaillance et à guider la sélection des cas de test. Par ailleurs, pour une analyse qualitative des défail- lances de l'IDS, on peut réaliser une analyse des modes de défaillances et de leurs effets (FMEA : " Failure Modes and Effects Analysis "). Le FMEA est une méthode d'analyse de la fiabilité d'un système par la définition des effets de chaque mode de défaillance et leur criticité. Ainsi, dans notre étude, une FMEA permettrait l'identification des défaillances poten- ComposantMode de Cause Effet j i'7nf jr Cause jT&fde l'IDS défaillance Sonde Non-capture Événementsmalicieux Intrusionnon desévéntementshorsdelaportéede vue intrusifs la sonde. Evénements masqués Suppression Intrusionsnon d'événements vuesouvues partiellement Pré-proces-Suppression Formatnonapproprié.Défaillance seur d'informations Informationinsuffisantedudétecteur utiles delapartdelasonde Détecteur Non-détection Défaillanceduprépro- Fauxnégatifs desévénements cesseur.Défaillance intrusifs del'algorithmede capturés détection Evénementsnon Défaillance Fauxpositifs intrusifs del'algorithmede considérés détection commeintrusifs Mauvaise Rapport identification incorrect Rapporteur Alarmenon Mauvaise Fauxnégatifs générée configuration Tableau 3. FMEA générique pour les IDS. tielles de chaque composant de l'IDS, et de donner une idée sur la cause, tandis que l'arbre de défaillances faci- lite l'identification des combinaisons de défaillances des composants qui pourrait conduire à une défaillance totale du IDS. Le tableau 3 fournit une structure générique d'une FMEA pour les IDS où nous avons identifié les défaillances, les causes ainsi que les effets. 6. Conclusion Les IDS sont actuellement des composants essentiels dans l'architecture des systèmes sécurisés. Néanmoins, le choix ou le déploiement de telle ou telle solution est confronté à plusieurs enjeux majeurs, notamment [6] : . la volatilité du problème : les méthodes et outils de détection sont en perpétuelle évolution ; . la complexité algorithmique : il faut tenir compte de toutes les vulnérabilités et de la manière avec laquelle elles peuvent être exploitées, y compris les attaques non encore connues (zo-y) ; . la réactivité due au caractère malveillant de l'adver- saire qui ne cesse de trouver comment déjouer les méthodes de détection ; REE No 6/7 Juin/juillet 2006 Evaluation des systèmes de détection d'intrusions le manque de méthodes et outils pour évaluer les IDS : nous sommes actuellement incapables d'éva- luer de façon satisfaisante les mérites des différentes solutions qui existent. Dans cet article, nous nous sommes intéressés à ce dernier point. Malheureusement, force est de constater que les travaux concernant l'évaluation des IDS sont encore embryonnaires. Deux problèmes fondamentaux peuvent être dégagés : l'absence de données réalistes qui puissent être utilisées pour modéliser les problèmes à résoudre et valider expérimentalement les solutions, et le manque de méthodes rigoureuses pour l'évaluation, notamment pour : . identifier les points les plus critiques à surveiller ou à corriger dans les IDS étudiés ; . estimer s'il est rentable de mettre en oeuvre telle ou telle défense supplémentaire ; . pouvoir comparer les fonctionnalités, les performan- ces et les caractéristiques de plusieurs IDS ; prouver si on a obtenu un niveau de sécurité satisfai- sant vis-à-vis de la politique visée. Dans ce sens, notre contribution consistait à : . proposer une nouvelle méthode systématique : . décrire de nouvelles métriques ; . détailler l'évaluation orientée composants, afin d'aider les développeurs à évaluer leurs IDS, à inter- préter leur comportement, à découvrir et à localiser les éventuelles causes de leurs défaillances. Ce travail permet de conclure qu'il faut plutôt opter pour la diversification des techniques de capture et de détection, pour la combinaison et le déploiement de plu- sieurs IDS sur un même système ou réseau, et faire appel aux techniques de tolérance aux intrusions. Enfin, il est important de noter que cette contribution n'est qu'un début et que pour aboutir aux résultats escomptés, on doit sans doute combiner des techniques de modélisation, de sécurité, de sûreté de fonctionnement et de sénie loiciel. Annexe A : Arbre de faute générique de l'IDS : IJd'1i1l'II',','II) S Ûci.H.tc.'cit'-L't ! !' D 1 \ 1 1, 11<1,1 ,]E n .\' nm 1 ël ". ",Il " Ili 11 !."li 1il o ID w ,4 l " I'l'Il Il 1,1lé I\Wena·m1 é..........1 hOl'",h;imp 1 i....d'httin'.n!!) !'.(! !!'\f1j!\' Û if'\naiy; û l lc, < : 1,11 . :[, 1, IkL\]:Li:1 () ci,,, ,1,Jcnmnon \cti\ " - m:d\ié " l ! : m1é ", 6. liL.tPc O" Sts 1 1)1 o !' d.asc'ml\bgc' Pilv dC 1,.Il , F miant 0 .\ " : A " \I;ituln,·clu: [1 Si,N1;I !lIi'.. %1,1 ; 1, uGtfe 1[) 1- \ L'h ! ! ! lC I-Wncmnu 1 \ ! t'u''.-' -n't'c Références [11 N. J. PUKETZA, K. ZHANG, M. CHUNG, B. MUKHERJEE, et R. A. OLSSON, " A Methodology for Testing Intrusion Detection Systems ;' IEFE Trans. On Software Engineering, vot. 22, pp. 19 - 29, october 1996. [21 R. LIPPMANN, D. FRIED, 1. GRAF, J. HAINES, K. KENDALL, D. MCCLUNG, D. WEBER, S. WEBSTER, D. WYSCHOROD, R CUNNINGHAM et M. ZISSMAN, " Evaluating Intrusion Detection Systems : The 1998 DARPA Off-Line Intrusion Detection Evaluation ;' D/SCFXW - DARPA Information Survivability Conference & Exposition, vol. 2, pp. 12-26, 2000 ; IEEE Computer Society Press, 2000. REE No 6/7 Jiiin/juillet 2006 Dossier RISQUES ET SÉCURITÉ DES RÉSEAUX ET DES SYSTÈMES A COMPOSANTE LOGICIELLE (7'epartieJ [31 H. DEBAR, M. DACIER, A. WESPI, S. LAMPART, "An Experimentation Workbench for Intrusion Détection Systems' ; esearch eporf RZ2998, IBM Zurich Research Division, Sep 1998. [4] R. LIPPMANN, J. HAINES, D. FRIED, J. KORBA et K. DAS. " The 1999 Darpa Otf-Line Intrusion Evaluation :' Computer Networks, 34 (2) 579-595, 2000. [51 E ALATA, M. DACIER, Y DESWARTE, M. KAANICHE, K. KORTCHINSKY V NICOMETTE, VH. PHAM et F POUGET Collection and Analysis of Attack Data Based on Honeypots Deployed on the Internet. In Actes de OOP'05 (lst Workshop on Ouality of Protection), Milan, Italie, September 15, 2005. [6] M. DACIER, " Détection d'intrusion' ; in Secué des systè- mes d'information V2, Traité IC2, série Réseaux et télécom- munications, dir Ludovic Me & Yves Deswarte, ISBN 2-7462-1259-5, à paraître (juin 2006). [7] H. DEBAR, M. DACIER ET A. WESPI. "A Revised Taxonomy for Intrusion Détection Systems' : Annales des Télécom- munications, 55 :361-378, 2000. [81 Y DESWARTE, " La sécurité des systèmes d'information et de communication','in Sécurité des réseaux et des systè- mes répartis, (Yves Deswarte & Ludovic Me, eds), Traité IC2, Hermès, ISBN : 02-7462-0770-2, 264 pp, octobre 2003. [9] T EVANGELISTA, " Les IDS ", Edition Dunod/01 Infor- matique ISBN : 2100072579, février 2004. [101 vvvvw. e-atla ntide.com/secu rite/detection_i ntrus ions. htm [11] D. ALESSANDRI, " Attack-Class-BasedAnalysis of IDS " PhD thesis, Université de Newcastle upon Tyne, School of Computer Science, mai 2004. [12] J. MCHUGH, " Testing Intrusion Detection Systems : A Critique of the 1998 and 1999 DARPA Intrusion Detection System Evaluations as Performed by Lincoln Laboratory' : ACM Transactions on Information and System Security, Vol 3, No. 4, pp. 262-294, Nov. 2000. Les auteurs Anas Abou El Kalam est maître de conférence à l'Ecole Nationale Supérieure de Bourges. Depuis son affectation à l'ENSI, il a occupé la responsabilité de la spécialité " sécurité des systèmes et des réseaux' ; et depuis 2005, il est responsable du département d'in- formatique. Ses principaux centres d'intérêts sont la sécurité des systèmes informatiques répartis, les politiques et modèles de sécurité, la protection de la vie privée et la détection d'intrusion. Il a obtenu son doctorat en 2003 à t'hstitut Nationat Poiytechnique de Toulouse (INPT) et au Laboratoire dgnalyse et dArchitecture des Systèmes (LAAS-CNRS). Mohammed S. Gad El Rab est actuellement doctorant au LIFO (Laboratoire d'Informatique Fondamentale d'Orléans). Il travaille dans le cadre de sa thèse sur les systèmes de détection d'intru- sion. En 2004, il a obtenu le diplôme des études approfondies : DEA Systèmes Informatiques, université Paul Sabatier, Toulouse, France. Au cours de son DEA et pendant neuf mois, il a travaillé au LAAS (Laboratoire dArchitecture et dAnalyse des Systèmes) sur " les techniques de la métrologie active dans les réseaux IP'.'II a reçu en 1998 son diplôme d'ingénieurs : ingénierie des systèmes informatique de la faculté d'ingénieur, université AI-Azhar au Caire, Egypte. Pendant les années 2000-2003, il a fait partie de l'Institut National de Standard en Egypte en qualité de chercheur assistant REE W 6/7 Juin/juillet 2006