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
Un langage dédié à la détection d'intrusion peut définir plusieurs éléments. 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. thumb|upright 2|Description d'un évènement en utilisant le langage ADeLE
Selon Eckmann et Michel, 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é. thumb|400 px|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, soit il doit pouvoir représenter une attaque sans avoir à représenter manuellement toutes ses variantes.
Types de détection possibles
D'après Rouached, un langage dédié à la détection d'intrusion peut détecter des intrusions selon trois axes différents:
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. 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écifications, nécessaire de prendre en compte certains éléments. 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
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 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.
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, 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: FileStatus=="Exist"
FileStatus=="Not Found"
Description des états d'un système thumb|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. 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 pour s'assurer que l'alerte générée n'est pas un faux positif. 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
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. ADeLE offre une syntaxe d'enchainement d'évènements en utilisant des combinaisons parmi les évènements prédéfinis <ENCHAIN> E0 ; Non_Ordered{E1,E2};E3;One_Among{E4,E5}, E6 </ENCHAIN>
Alertes thumb|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. 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 s'il souhaite être informé, selon la nature des évènements qui sont la cause de l'alerte.
Réponse automatique à une intrusion