Utilisateur:Dufourj/Brouillon

Une page de Wikipédia, l'encyclopédie libre.

Langages de détections d'intrusions[modifier | modifier le code]

Définition[modifier | modifier le code]

Un langage dédié à la détection d'intrusion peut définir[1]:

  • Les évènements qui se produisent
  • Les réponses à ces évènements
  • La journalisation des alertes déclenchées par des évènements
  • Les corrélations relatives aux alertes
  • Les combinaisons d'évènement résultant en une attaque
  • Les moyens de détection d'un évènement

Selon Eckmann[2] et Michel[3], un langage dédié à la détection efficace possède les qualités suivantes:

  • Simplicité, seules les fonctionnalités nécessaires sont présentes
  • Expressivité de la syntaxe, il doit être possible de représenter n'importe quelle attaque détectable
  • Expressivité des méthodes, tous les aspects d'un évènement doivent être représentables, que ce soit du point de vue du système de détection d'intrusion que de celui de l'attaquant
  • Modularité, le langage doit pouvoir décrire des enchainements d'évènements (scénarios)
  • Exécutabilité, les spécifications doivent être utilisables par un IDS soit directement, soit une fois traduites par un outil spécifique.
  • Portabilité, les outils de traitement doivent être facilement adaptables sur différents environnements.

Définition (réécrite)[modifier | modifier le code]

Un langage dédié à la détection d'intrusion peut définir plusieurs choses[1] selon le langage ciblé. L'une d'entre-elles consiste à rapporter les différents évènements qui se produisent, ainsi que les réponses que l'on peut y apporter. Toutefois, il est possible que ce soit la chaine de plusieurs évènements qui résulte en une seule attaque, et l'on parle alors de combinaisons d'évènements. Des alertes peuvent être déclenchées lorsque des évènements ont lieu, et donc certains langages peuvent offrir une journalisation ainsi que de possible corrélations entre ces différentes alertes.

Selon Eckmann[2] et Michel[3], 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é doit être de mise : il doit être à la fois possible de représenter n'importe quelle attaque détectable de part la synthaxe du code, mais aussi de pouvoir distinguer tous les aspects d'un evênement, autant du point de vue du système de détection d'intrusion que de l'attaquant. Aussi, le langage doit pouvoir donner le choix d'écrire des attaques modulaires de part un enchainement d'évènements, afin de caractériser un scénario spécifique. Pour finir, deux points essentiels qui garantissent une certaine simplicité concernant l'utilisation du langage doivent être présentes. Tout d'abord, les spécifications doivent être utilisables par un IDS soit directement, soit une fois traduites par un outil spécifique. Enfin, les outils de traitement doivent être facilement adaptables sur différents environnements.

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

Détection basée sur des spécifications[modifier | modifier le code]

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[4]. Il est en revanche, dans le cadre d'une utilisation basée sur des spécification, de pouvoir répondre à certaines questions[4]:

Fabien Charmet (discuter) Transformer les questions en affirmations

  • Quel est le coût d'implémentation des spécifications du comportement du système ?
  • Ces efforts sont ils plus importants que ceux requis pour un système de détection d'anomalies ?
  • Quelle est l'efficacité de ce système quant à la détection d'attaques inconnues ?
  • Existe-t-il des types d'attaques détectables uniquement par des systèmes basés sur des spécifications et d'autres détectables uniquement par des systèmes de détection d'anomalies ?
  • Les taux de faux positifs sont ils comparables à ceux obtenus sur des systèmes exploitant des signatures ?


Détection basée sur des spécifications (réécrite)[modifier | modifier le code]

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[4]. Il est en revanche, dans le cadre d'une utilisation basée sur des spécification, nécessaire de prendre en comptes certains éléments[4]. Tout d'abord, d'un point de vue économique, il faut clarifier le coût de l'implementation des spécifications du comportement du système. Autre point relatif au coût, il faut veiller à ce que les efforts mis en oeuvre ne sont 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 concerne purement la sécurité mis en oeuvre. Ainsi il faut veiller à ce que certaines attaques ne seraient 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 soucis 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.

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

  1. a et b Eckmann 2002, p. 4
  2. a et b Eckmann 2002, p. 6
  3. a et b Michel et Mé 2001, p. 4
  4. a b c et d Erreur de référence : Balise <ref> incorrecte : aucun texte n’a été fourni pour les références nommées FormalAnalysisIDS_p1_1


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) 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) 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) 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)