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

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"

 FileStatus=="Not Found"

</POSTCOND>

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.

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>

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>

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.

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

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

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

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

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.