Langage dédié à la détection d'intrusion

Ajouter des liens
Un article de Wikipédia, l'encyclopédie libre.
Articles principaux : système de détection d'intrusion et langage dédié.

Un langage dédié à la détection d'intrusion est un langage dédié qui permet de spécifier les règles d'un système de détection d'intrusion, IDS en anglais, dans le domaine de la sécurité informatique. Ces règles décrivent l'architecture des systèmes à protéger, quelles règles de sécurité l'administrateur souhaite que ces systèmes respectent ou quelles contre-mesures faut il prendre. Un langage permet de détecter des attaques selon plusieurs angles d'attaque, en analysant le comportement du système, ou son écart par rapport à son état normal. La détection des intrusions est réalisée en se basant sur plusieurs techniques comme la mise en place de règles, la description de scénarios et l'utilisation d'alertes. Il existe plusieurs langages qui ont été développés, ainsi que des conférences qui traitent le sujet de la détection d'intrusion.

Définition[modifier | modifier le code]

Un langage dédié à la détection d'intrusion peut définir plusieurs éléments[1]. Il peut définir les événements qui se produisent sur le système à protéger, qu'ils soient internes ou externes ainsi que la manière de réaliser cette détection. Le langage peut permettre de représenter les réponses aux différents événements ou la manière de journaliser les alertes qui ont été générées à cause des événements. Certains langages définissent des corrélations entre les alertes pour affiner la détection, tandis que d'autres offrent la possibilité d'établir des scénarios d'attaque ou de détection.

Description d'un évènement en utilisant le langage ADeLE[2]

Selon Eckmann[3] et Michel[4], un langage efficace dédié à la détection d'intrusions doit posséder plusieurs qualités. Tout d'abord, le langage doit être simple à utiliser, et donc, seules les fonctionnalités nécessaires doivent être présentes. Pour autant, l'expressivité, l'éventail de possibilités offert par le langage pour décrire une attaque est important : il doit être à la fois possible de représenter n'importe quelle attaque détectable par le langage avec la syntaxe du code, mais aussi de pouvoir distinguer tous les aspects d'un événement, tant du point de vue du système de détection d'intrusion que de l'attaquant. Ainsi, le langage doit permettre de décrire des attaques modulaires, c'est-à-dire comme un enchaînement d’événements qui caractérisent un scénario spécifique. Pour finir, deux points essentiels qui garantissent une certaine qualité concernant le langage: les spécifications et la portabilité.

Passage des règles au programme de détection d'intrusions

Les spécifications doivent être utilisables soit directement par un IDS, soit une fois traduites par un outil spécifique et automatique. La portabilité du langage consiste à pouvoir disposer des outils de traitement facilement sur plusieurs environnements différents.

Deux points de vue différents apparaissent dans la littérature concernant la précision avec laquelle il est possible de décrire une attaque: soit le langage ne doit pas permettre d’ambiguïté entre deux attaques différentes[3], soit il doit pouvoir représenter une attaque sans avoir à représenter manuellement toutes ses variantes[4].

Types de détection possibles[modifier | modifier le code]

D'après Rouached, un langage dédié à la détection d'intrusion peut détecter des intrusions selon trois axes différents[5]:

  • La détection d'anomalies, lorsque l'état courant du système sera comparé avec l'état dans lequel il est supposé être.
  • La détection d'abus, permettant d'identifier les d'attaques connues à partir de schémas préenregistrés, encore appelés signatures ou scénarios.
  • La détection basée sur des spécifications, qui consiste à analyser le comportement du programme et ses déviations.
Détection d'anomalies

La détection d'anomalies repose sur la description préétablie de l'état normal de fonctionnement du système. Son avantage majeur réside dans le fait qu'elle ne nécessite aucune connaissance préalable des attaques pour détecter un comportement malicieux[5]. En revanche, c'est à l'utilisateur de définir quel est le seuil de tolérance qui distingue l'état normal de l'état compromis du système, et donc la détection d'anomalies est source de nombreux faux positifs.

Détections d'abus

La détection d'abus nécessite de connaitre les signatures des attaques que le système pourrait subir. Ceci pose trois problèmes, d'une part il faut connaître les signatures des attaques, et donc en collecter un maximum, et d'autre part, cette détection ne permet pas d'identifier des attaques nouvelles ou encore inconnues. Enfin, les signatures enregistrées dans le système de détection ne permettent pas forcément de les adapter facilement aux possibles variantes qu'elles représentent[5]. On se sert entre autres de Honeypot pour collecter des signatures d'attaque.

Détection basée sur des spécifications

Ce type de détection consiste à déclarer au préalable, à l'aide des spécifications, le comportement attendu du système à protéger. Ainsi, en surveillant l'évolution du comportement du programme, il est possible de détecter si une attaque a lieu ou non. L'un des avantages de cette méthode est qu'il n'est pas nécessaire de connaître la signature de l'attaque car c'est la variation du comportement du système qu'elle implique qui est analysée. Ainsi, il est possible de générer un nombre de faux positifs comparable à celui d'une détection d'abus[5].

Il est en revanche, dans le cadre d'une utilisation basée sur des spécifications, nécessaire de prendre en compte certains éléments[5]. Tout d'abord, d'un point de vue économique, il faut clarifier le coût de l’implémentation des spécifications du comportement du système. Autre point relatif au coût, il faut veiller à ce que les efforts mis en œuvre ne soient pas trop importants, par rapport à ceux qui seraient requis, pour le système de détection d'anomalies.

D'autres éléments à prendre en compte concernent purement la sécurité mis en œuvre. Ainsi il faut veiller à ce que certaines attaques ne soient pas uniquement détectables non pas par des spécifications mais par des systèmes de détections d'anomalies (et vice versa). Toujours dans un souci de sécurité, mais cette fois-ci visant sur le long terme, il faut quantifier l'efficacité de ce système face à des attaques encore inconnues, afin de savoir si oui ou non ils seraient tout de même prêts à les détecter. Pour finir, il faut aussi prendre en compte le problème des faux positifs qui pollueraient les résultats. De ce fait, ils sont tolérés s'ils sont comparables à ceux obtenus sur des systèmes de détection basés sur les signatures.

Concepts[modifier | modifier le code]

Les concepts sont les différentes méthodes et principes utilisés par les langages dédiés à la détection d'intrusion, par exemple, la description des règles à suivre, de l'état dans lequel se trouve le système ou encore comment l'IDS doit-il réagir quand il fait face à une certaine intrusion.

Utilisation de règles[modifier | modifier le code]

Les règles permettent de définir la méthode qui aboutit à la détection d'une attaque. Par exemple, l'enchainement d'actions de détection qui selon certains critères, eux aussi définis dans la règle, permet de savoir qu'une attaque est en cours.

La description de règles peut être vue comme une fonction écrite en langage C, caractérisée par un nom ainsi que par des paramètres (facultatifs)[4] :

  • le nom représente ladite intrusion lorsqu'elle a lieu, permettant son identification;
  • les paramètres représentent les entrées et sorties de données, permettant le plus souvent de réutiliser en partie l'exploit concerné.

Une description de règles peut être définie par d'autres descriptions écrites avec le langage, auquel cas leurs noms doivent être référencés dans les paramètres[4].

Cette instruction dans Snort permet de détecter qu'un accès au service mount a été effectué à distance: 

alert tcp any any -> 192.168.1.0/24 111 (content:"|00 01 86 a5|"; msg: "mountd access";)

Selon Cuppens[6], une règle doit comporter une description de préconditions et postconditions. Les préconditions décrivent l'état dans lequel le système doit être pour qu'une attaque particulière soit réalisable. Les postconditions décrivent les effets d'une attaque réussie sur le système. Ces conditions peuvent être décrites à l'aide de fonctions logiques. Ces fonctions logiques représentent l'état des cibles potentielles concernées par l'attaque, mais représentent aussi l'état de l'attaquant, comme les informations qu'il connait ou ses droits. Le langage ADeLE utilise la syntaxe suivante: <PRECOND> 

 FileStatus=="Exist"

</PRECOND>

<POSTCOND> 

 FileStatus=="Not Found"

</POSTCOND>

Description des états d'un système[modifier | modifier le code]

Transition d'états lors d'une authentification

La détection d'une attaque repose en partie sur l'analyse des états du système à protéger. Ces états sont décrits en utilisant des prédicats logiques[7]. Les prédicats sont ensuite combinés en utilisant des opérateurs de logique booléenne. Par exemple, concernant une attaque réseau, une combinaison intéressante de prédicat pour un système particulier serait serviceActif(telnet)∧portOuvert(telnet, 23,tcp)[7]. Cependant, il est parfois possible qu'une attaque ne concerne que le gain d'information, ceci est différent d'une altération du système, ce qui implique d'avoir un prédicat concernant la connaissance d'une information donnée par une personne particulière.

Principe de vérification[modifier | modifier le code]

Lorsque des préconditions et des postconditions ont été définies pour une attaque, il est nécessaire de mettre en place des moyens de vérification. Les préconditions décrivant l'état dans lequel le système doit se trouver pour être vulnérable et les postconditions décrivant l'état dans lequel le système est après que l'attaque ait été réussie, des actions d'audit permettent de vérifier si ces préconditions ou postconditions sont vérifiées. Ces vérifications correspondent à un point de vue opérationnel, et doivent décrire les actions à réaliser de manière concrète[8] pour s'assurer que l'alerte générée n'est pas un faux positif[9]. Par exemple, une analyse des ports ouverts sur un système ou l'analyse des journaux d'un service donné sont des exemples de vérifications à mettre en place. ADeLE définit des fonctions booléennes telles que la vérification des hash des fichiers, la disponibilité d'une machine à ajouter dans une section particulière. 

<CONFIRM>
Wrong_Hashes("/etc/passwd")
Unreachable_Machine("192.168.12.5")
</CONFIRM>

Utilisation de scénarios[modifier | modifier le code]

Cette section est vide, insuffisamment détaillée ou incomplète. Votre aide est la bienvenue ! Comment faire ?

D'après Raihan, un scénario est une succession d’événements qui amène un système d'un état normal à un état attaqué[10]. Par exemple, une attaque énumérative pour deviner le mot de passe d'un utilisateur. Un système d'authentification possède deux états, authentifié ou verrouillé. Un évènement d'un scénario peut aussi bien être une action élémentaire qu'une attaque de plus bas niveau[11]. ADeLE offre une syntaxe d'enchainement d'évènements en utilisant des combinaisons parmi les évènements prédéfinis[12] 

<ENCHAIN>
 E0 ; Non_Ordered{E1,E2};E3;One_Among{E4,E5}, E6
</ENCHAIN>

Alertes[modifier | modifier le code]

Exemple résumé d'alerte avec le langage ADeLE

Une alerte est un message qui a pour but de prévenir le système de gestion de la sécurité informatique qu'un évènement important vient de se produire en utilisant par exemple IDMEF. Une alerte peut soit déclencher automatiquement une série de contre-mesures, si elles ont été définies ou alors être transmises à un utilisateur pour une gestion manuelle de l'incident ou pour une analyse ultérieure[13]. Selon Cuppens[6], une alerte devrait être générée uniquement quand le système de détection d'intrusion détecte une tentative, fructueuse ou non, d'exécution d'une action frauduleuse. Dans la pratique, des alertes générées ne concernent pas directement la sécurité du système. On parle alors de faux positifs. Cuppens ajoute que c'est à l'administrateur de décider s'il souhaite être informé, selon la nature des évènements qui sont la cause de l'alerte.

Réponse automatique à une intrusion[modifier | modifier le code]

Dans la littérature, il n'y a pas de langage spécialement conçu pour permettre une réponse automatique à une attaque qui a été détectée. Michel propose une liste non exhaustive de réponses possibles à une intrusion[14]:

  • Fermer port utilisé pour une attaque
  • Ajouter à une Liste noire l'adresse IP de l'attaquant
  • Réinitialiser une connexion TCP
  • Tuer le ou les processus d'un utilisateur
  • Exécuter un script contenant les actions à réaliser

Utilisation de graphes d'attaques[modifier | modifier le code]

Cette section est vide, insuffisamment détaillée ou incomplète. Votre aide est la bienvenue ! Comment faire ?

Selon Chen, un graphe d'attaques peut être partiel ou total[15]. Un graphe partiel a pour objectif d'évaluer les relations entre les vulnérabilités connues par rapport à une attaque pour un système donné. Un graphe total a pour objectif d'évaluer les relations entre toutes les vulnérabilités connues pour un système donné.

Utilisation de graphes d'alertes[modifier | modifier le code]

Selon Ning, une faiblesse des systèmes de détection d'intrusion réside dans le fait que bien qu'ils détectent une action malicieuse ou une attaque, ils n'ont pas la capacité à la relier à une autre attaque détectée et donc ratent potentiellement une attaque de plus haut niveau. Les graphes d'alertes permettent de corréler différentes alertes générées, en utilisant une représentation graphique des liens entre ces alertes [16]. Il existe trois classes de méthodes de corrélation [16]:

  • Une méthode probabiliste, basée sur les ressemblances entre les alertes. Cette méthode bien qu'effective ne permet pas de découvrir complètement la cause des alertes;
  • Une corrélation basée sur le data mining, à l'aide de scénarios préenregistrés, i.e. signatures;
  • Une corrélation chronologique, détectant si les postconditions d'une attaque ont rendu vraies les préconditions d'une autre.

Ning propose une méthode de corrélation chronologique [17]. La corrélation chronologique des alertes n'impose pas que les préconditions d'une attaque doivent être satisfaites par les postconditions d'une autre attaque. À partir des préconditions et postconditions, des hyper-alertes sont définies. Une hyper-alerte est un triplet <fait, précondition, postcondition>. fait décrit les différents attributs ainsi que leurs ensembles de valeurs, Précondition et postcondition sont des fonctions booléennes dont les variables appartiennent à celles décrites dans fait.

L’intérêt d'établir ces corrélations vient lors d'une situation de crise, puisque de trop nombreuses alertes rendent leur propre gestion difficile, d'autant plus si elles sont couplées à d'autres alertes conduites par des faux positifs.

Le graphe sous forme de file d'attente[18] (Queue Graphs) est une structure de données qui peut intervenir pour l'établissement d'une corrélation entre plusieurs alertes relevées. Il peut y avoir une corrélation entre elles lorsqu'elles répondent toutes au même exploit. À savoir que les alertes correspondent au même exploit selon trois critères, mais qu'un seul suffit : il faut que soit la vulnérabilité relevée, soit la machine hôte (la provenance) des attaques, soit la machine cible (la destination) des attaques soit la même pour les alertes en question.

La corrélation entre ces alertes est aussi envisageable en se basant sur de possible prérequis concernant les attaques, ainsi que sur les conséquences qu'elles engendrent[19]. D'ailleurs, l'approche par graphes sous forme de file d'attente permet de faire des suppositions sur les alertes manquées par les IDS. Il est ainsi davantage possible de prévoir les conséquences que peuvent avoir les intrusions[20].

Langages existants[modifier | modifier le code]

ADeLe[modifier | modifier le code]

ADeLE[2] est un langage de description d'attaques procédural, conçu afin de modéliser une base de données de scénarios d'attaques connus, et permettant ainsi de tester l'efficacité d'un IDS avec du code malveillant. Ce langage permet plusieurs choses, notamment de décrire les différents événements conduisant à une intrusion, d'analyser les alertes de plusieurs IDS afin de générer des meta-alertes de par leur corrélation, et enfin d'énoncer des contre-mesures à prendre après la détection d'une attaque. Les descriptions des attaques sont écrites avec des tags (comme XML) pour faciliter la compréhension. Aussi, il est possible de décrire tous les aspects de l'attaque autant du point de vue de l'attaque qu'au niveau de la défense par rapport à l'attaque, le tout dans une seule et même description. De plus, il faut y écrire du code générique afin de pouvoir représenter, toujours en une seule description, différentes variantes. Enfin, il est possible de combiner des descriptions pour en faire une nouvelle, garantissant ainsi une certaine modularité[21].

STATL[modifier | modifier le code]

STATL[22] est un langage de description basé sur les transitions d'états et conçu pour la détection d'intrusions. L'état caractérise un point de contrôle d'un système durant l'évolution de l'attaque, alors qu'une transition est une action[3] qui, mises bout-à-bout conduisent à une intrusion. La description d'une pénétration est donc réalisée sous forme d'une séquence, caractérisant un scénario d'attaque. Les descriptions venant de ce langage peuvent par la suite être analysés avec un IDS afin d'analyser de possibles intrusions selon un environnement cible défini[1].

LAMBDA[modifier | modifier le code]

LAMBDA[23] est un langage de description d'attaques déclaratif conçu afin de modéliser une base de données pour la détection des attaques. Ici, contrairement à AdeLe, les différents points de vue d'une attaque sont écrits séparément. L'un concerne le processus de détection et l'on y trouve donc toutes les actions élémentaires qui relèvent de la détection de l'attaque en question. Une description permettant de définir la combinaison des différentes actions de détection est nécessaire. Enfin, la troisième description dite de vérification permet de compléter la détection. Elle permet tout d'abord de vérifier si l'attaque a été bloquée, et, le cas échéant, d'évaluer l'impact des dégâts de la machine cible. Ce dernier type de description peut aussi indiquer si la machine est exposée à une vulnérabilité connue[24].

Binder[modifier | modifier le code]

Binder[25] est un concept de langage de sécurité basé sur la programmation déclarative et l'enregistrement des données. Sa plus grande particularité est le fait qu'il vise les systèmes distribués[25]. Chacune des composantes du système distribué possède ainsi son propre contexte de Binder en local avec son propre programme Binder. Ces différents programmes sont capables de communiquer ensemble grâce à un système de certificats signés[26].

CISL[modifier | modifier le code]

Le CISL[27] est l'acronyme de Common Intrusion Specification Language, soit le Langage de Spécifications d'Intrusion Commun. Il s'agit de la principale composante du CIDF, le Common Intrusion Detection Framework (Framework de Détection d'Intrusions Commun), créé par DARPA. Leur vocation est de pouvoir partager les informations concernant les intrusions grâce aux IDS. Ce partage aurait ainsi pour but de prévenir les attaques à grande échelle, ou de limiter les dégâts pour les systèmes déjà attaqués. Ainsi, un flux entrant d'un composant permet de recevoir des informations concernant une attaque. Ces informations sont travaillées en interne, et un flux sortant permet de renvoyer le résultat à d'autres composants faisant partie du groupe qui réanalyseront. Ces composants peuvent être aussi bien des générateurs d’événements, des moyens d'analyses, des générateurs de contre-mesures, ou des bases de données[28]. Pour cela, il faut un langage compris par tous et qui serait précis, c'est-à-dire que le même message ne doit pas donner de conclusions contradictoires selon le composant qui le traite. L'un de ces langages est proposé : S-expressions. Il est similaire à ce que peut être l'anglais de par le fait qu'il permet de créer des expressions de manière récursive. Les S-expressions comprennent des tags et des données entourés par des parenthèses à la manière du langage Lisp, et qui caractérisent de l'information relative aux intrusions[29]. Chaque S-expression commence par un tag nommé le SID (Semantic IDentifier), servant à donner un indice par rapport à l’interprétation qui doit être faite de l'expression.

Liens externes[modifier | modifier le code]

Références[modifier | modifier le code]

  1. ↑ a et b Eckmann 2002, p. 4
  2. ↑ a et b Michel et Mé 2001, p. 1
  3. ↑ a b et c Eckmann 2002, p. 6
  4. ↑ a b c et d Michel et Mé 2001, p. 4
  5. ↑ a b c d et e Rouached 2010, p. 1
  6. ↑ a et b Cuppens 2000, p. 5
  7. ↑ a et b Cuppens 2000, p. 7
  8. ↑ Cuppens 2000, p. 10
  9. ↑ Michel et Mé 2001, p. 10
  10. ↑ Raihan 2005, p. 1
  11. ↑ Cuppens 2000, p. 3
  12. ↑ Michel et Mé 2001, p. 7
  13. ↑ Bolzoni 2009, p. 2
  14. ↑ Michel 2001, p. 11
  15. ↑ Chen 2009, p. 1
  16. ↑ a et b Ning 2002, p. 1
  17. ↑ Ning 2002, p. 2
  18. ↑ Wang, Liu et Jajodia 2005, p. 7
  19. ↑ Ning, Cui et Reeves 2002, p. 1
  20. ↑ Wang, Liu et Jajodia 2005, p. 12
  21. ↑ Michel et Mé 2001, p. 3
  22. ↑ Eckmann 2002, p. 1
  23. ↑ Cuppens 2000, p. 1
  24. ↑ Cuppens 2000, p. 199
  25. ↑ a et b Detreville 2002, p. 1
  26. ↑ Detreville 2002, p. 3
  27. ↑ Kahn et al. 1999, p. 1
  28. ↑ Kahn et al. 1999, p. 2
  29. ↑ Kahn et al. 1999, p. 3

Bibliographie[modifier | modifier le code]

  • (en) F. Cuppens et R. Ortalo, « LAMBDA: A Language to Model a Database for Detection of Attacks », RAID '00 Proceedings of the Third International Workshop on Recent Advances in Intrusion Detection,‎ , p. 197-216 (ISBN 978-3-540-41085-0, DOI 10.1109/4434.806977)
  • (en) Steven T. Eckmann, Giovanni Vigna et Richard A. Kemmerer, « STATL: An attack language for state-based intrusion detection », Journal of Computer Security, vol. 10,‎ , p. 71-103 (ISSN 1875-8924)
  • (en) Damiano Bolzoni, Sandro Etalle et Pieter H. Hartel, « Panacea: Automating Attack Classification for Anomaly-Based Network Intrusion Detection Systems », Recent Advances in Intrusion Detection,‎ , p. 1-20 (ISBN 978-3-642-04342-0, ISSN 0302-9743, DOI 10.1007/978-3-642-04342-0_1)
  • (en) Cedric Michel et Ludovic Mé, « ADeLe: An Attack Description Language for Knowledge-Based Intrusion Detection », Trusted Information,‎ , p. 353-368 (ISBN 978-0-306-46998-5, ISSN 1571-5736, DOI 10.1007/0-306-46998-7_25)
  • (en) Lingyu Wang, Anyi Liu et Sushil Jajodia, « An Efficient and Unified Approach to Correlating, Hypothesizing, and Predicting Intrusion Alerts », Computer Security – ESORICS 2005, vol. 3679,‎ , p. 247-266 (ISBN 978-3-540-31981-8, DOI 10.1007/11555827_15)
  • (en) Giovanni Vigna, W. Robertson, V. Kher et Richard A. Kemmerer, « A stateful intrusion detection system for World-Wide Web servers », Computer Security Applications Conference, 2003. Proceedings. 19th Annual,‎ , p. 34-43 (ISBN 0-7695-2041-3, DOI 10.1109/CSAC.2003.1254308)
  • (en) J. Detreville, « Binder, a logic-based security language », Proceedings of the 2002 IEEE Symposium on Security and Privacy,‎ , p. 105-113 (ISBN 0-7695-1543-6, ISSN 1081-6011, DOI 10.1109/SECPRI.2002.1004365)
  • (en) M.F. Raihan et M. Zulkernine, « Detecting intrusions specified in a software specification language », Computer Software and Applications Conference, 2005. COMPSAC 2005. 29th Annual International, vol. 2,‎ , p. 143-148 (ISBN 0-7695-2413-3, ISSN 0730-3157, DOI 10.1109/COMPSAC.2005.69)
  • (en) B. Tung, « The Common Intrusion Specification Language: a retrospective », DARPA Information Survivability Conference and Exposition, 2000. DISCEX '00. Proceedings, vol. 2,‎ , p. 36-45 (ISBN 0-7695-0490-6, DOI 10.1109/DISCEX.2000.821507)
  • (en) Nirnay Ghosh et S.K. Ghosh, « A planner-based approach to generate and analyze minimal attack graph », Applied Intelligence, vol. 36,‎ , p. 369-390 (ISSN 1573-7497, DOI 10.1007/s10489-010-0266-8)
  • (en) Mohsen Rouached, Hassen Sallay, Ouissem Ben Fredj, Adel Ammar, Khaled Al-Shalfan et Majdi Ben Saad, « Formal analysis of intrusion detection systems for high speed networks », Proceeding ISPACT'10 Proceedings of the 9th WSEAS international conference on Advances in e-activities, information security and privacy,‎ , p. 109-114 (ISBN 978-960-474-258-5)
  • (en) Clifford Kahn, Phillip A. Porras, Stuart Staniford-Chen et Brian Tung, « A Common Intrusion Detection Framework », Journal of Computer Security,‎ (lire en ligne)
  • (en) Clifford Kahn, Phillip A. Porras, Stuart Staniford-Chen, Brian Tung et Dan Schnackenberg, « A Common Intrusion Specification Language », CIDF Specification Documents,‎ (lire en ligne)
  • (en) Feng Chen, JinshuAnyi Su et Yi Zhang, « A Scalable Approach to Full Attack Graphs Generation », Engineering Secure Software and Systems,‎ , p. 150-163 (ISBN 978-3-642-00199-4, ISSN 0302-9743, DOI 10.1007/978-3-642-00199-4_13)
  • (en) Peng Ning, Yun Cui et Douglas S. Reeves, « Constructing attack scenarios through correlation of intrusion alerts », CCS '02 Proceedings of the 9th ACM conference on Computer and communications security,‎ , p. 245-254 (ISBN 1-58113-612-9, DOI 10.1145/586110.586144)
Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Langage_dédié_à_la_détection_d%27intrusion&oldid=179255065 ».