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

Fabien Charmet (discuter) Étoffer le résumé introductif, présenter le plan

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.

Définition

Fabien Charmet (discuter) Moins de liste à puce, plus de rédaction

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

• 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 et Michel, 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.

Deux points de vue différents apparaissent dans la littérature:

• Un langage ne doit pas permettre d’ambiguïté entre deux attaques différentes
• Un langage doit pouvoir représenter une attaque sans avoir à représenter manuellement toutes ses variantes

Types de détection possibles

D'après Rouached, les types de détection possibles utilisés par un langage dédié à la détection d'intrusion peuvent être catégorisés en trois groupes principaux:

• 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.

Fabien Charmet (discuter) Utilisation de définition: ;nom : définitiion

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

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 ?

Concepts

Les concepts sont les différentes méthodes et principes utilisés par les langages dédiés à la détection d'intrusion.

Utilisation de règles

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

• 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.

Selon Cuppens, 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.

Transition d'états lors d'une authentification

Description des états d'un système

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

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

Utilisation de scénarios

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é. 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.

Alertes

Selon Cuppens, 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 si il souhaite être informé, selon la nature des évènements qui sont la cause de l'alerte.

Réponse automatique à une intrusion

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:

• 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
• Executer un script contenant les actions à réaliser

Utilisation de graphes d'attaques

Selon Chen , un graphe d'attaques peut être partiel ou total. 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

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. Il existe trois classes de méthodes de corrélation:

• 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 attaques ont rendues vraies les préconditions d'une autre.

Ning propose une méthode de corrélation chronologique . 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. A 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 attribut ainsi que leurs ensembles de valeurs, Précondition et postcondition sont des fonctions booléennes dont les variables appartiennent à celles décrites dans fait.

Approche par la corrélation des alertes

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 à deux fausses alertes.

Le graphe sous forme de file d'attente (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, c'est à dire si :

• la vulnérabilité relevée par ces alertes est la même.
• la machine hôte (la provenance) des attaques est la même.
• la machine cible (la destination) de ces mêmes attaques est la même.

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

Langages existants

Fabien Charmet (discuter) Ajouter une description plus poussée, quels concepts sont utilisés, quels points forts sont mis en avant, quelles faiblesses sont données par les autres ?

• ADeLe : 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.
• STATL : langage de description basé sur les transitions d'états et conçu pour la détection d'intrusions. Il permet de décrire plusieurs pénétrations sous forme de séquences.
• LAMBDA : langage de description d'attaques déclaratif conçu afin de modéliser une base de données pour la détection des attaques.
• Binder : langage orienté logique qui code les déclarations de sécurité en des composants de programmes logiques communicants et distribués.
• CISL : Langage de Spécifications d'Intrusion Communes, produit par le Framework de Détection d'Intrusions Communes (CIDF), permettant la génération et l'encodage des expressions concernant les attaques, les anomalies, et des réponses adéquates à ces problèmes.

Conférences relatives à la détection d'intrusions

Fabien Charmet (discuter) trouver la conf en général, pas une année particulière

Fabien Charmet (discuter) décrire la conf, ajouter lien, dire qui y participe

• HSC : Sécurité TCP/IP, filtrage IP et détection d'intrusion
• JDIR 2000 : Un système multi-agents pour la détection d'intrusions
• HackFest 2010 : La détection d'intrusions est elle morte en 2003 ?
• RAID International Symposium on Research in Attacks, Intrusions and Defenses
• Conference on Detection of Intrusions and Malware & Vulnerability Assessment (DIMVA)

Liens externes

Lien vers le site du RAID Symposium

Lien vers le site de la conférence DIMVA

Bibliographie

• (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,‎ 2000, 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,‎ 2002, 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,‎ 2009, 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,‎ 2001, 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,‎ 2005, 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,‎ 2003, 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,‎ 2002, 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,‎ 2005, 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,‎ 2000, 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,‎ 2012, 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,‎ 2010, 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,‎ 1998 (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,‎ 1999 (lire en ligne)

• (en) Feng Chen, JinshuAnyi Su et Yi Zhang, « A Scalable Approach to Full Attack Graphs Generation », Engineering Secure Software and Systems,‎ 2009, 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,‎ 2002, p. 245-254 (ISBN 1-58113-612-9, DOI 10.1145/586110.586144)