Évaluation du taux de détection

Maintenant que nous savons construire un modèle de faute permettant de simuler les caractéristiques des attaques contres les données de calcul, nous devons aborder la problématique suivante : comment utiliser ce modèle de faute dans le cadre de l’évaluation d’un système de détection d’intrusion ? En effet, pour l’instant le mécan-isme d’injection qui utilise le modèle de faute que nous proposons dans ce chapitre reste relativement générique. Certes il est conçu pour ne viser que les cibles po-tentielles pour un utilisateur malveillant cherchant à réaliser une attaque contre les données de calcul, mais il n’impose ni le nombre d’injections qui doivent être réal-isées à chaque exécution, ni le nombre de cibles à corrompre à chaque injection, ni la valeur à injecter pour chaque cible.

Pour répondre à cette problématique, des choix doivent donc être faits. Ce sont ces choix que nous allons présenter dans la suite de cette section. Pour comprendre la démarche que nous avons entreprise pour nous guider dans ces choix, il faut se rappeler que ces décisions ont été prises sous la contrainte d’une exigence bien particulière : nous cherchons à placer le système de détection d’intrusion en cours de test dans la situation qui lui est la moins favorable. Ceci nous assurera une sur-approximation de l’estimation du taux de faux négatifs. À noter que pour répondre à ce critère, les choix ont été faits en fonction spécifiquement de notre approche pour la détection et ces derniers pourraient être totalement différents pour l’évaluation d’un tout autre mécanisme de détection.

3.1.2.1 Choix du nombre d’injections

Nous allons maintenant déterminer combien d’injections doivent être réalisées durant l’exécution du programme. Pour cela, nous devons considérer deux cas. Soit l’attaquant a la possibilité de modifier toutes les variables nécessaires à la réalisation de l’intrusion en une seule fois, soit il lui est nécessaire d’exploiter la vulnérabilité à plusieurs reprises. C’est dans le second cas que la probabilité de détection par notre mécanisme est la plus élevée.

En effet, plus l’attaque nécessite d’exploiter la ou les vulnérabilités présentes dans le programme plus grande est la quantité de code exécuté dans un état illégal et donc plus grande est la probabilité de violer au moins un invariant. Afin de nous placer dans la situation la moins favorable pour le mécanisme de détection que nous

proposons, nous choisissons donc d’effectuer la simulation d’une attaque contre les données de calcul en une seule injection.

3.1.2.2 Choix du nombre de cibles

Nous devons aussi déterminer combien de variables à la fois doivent être cor-rompues par une injection. Nous faisons ici, dans le cas de notre approche pour la détection, l’hypothèse suivante : plus une injection modifie de variables à la fois, plus elle a de chance de provoquer la levée d’alertes par notre système de détection d’intrusion. Nous allons donc vérifier cette hypothèse sur un exemple pour notre système de détection d’intrusion.

Pour cela, nous allons d’abord poser un certain nombre de notations et de défini-tions. Soient n variables locales à une fonction, notées X₁, X₂, . . ., X_n, dont les do-maines de définition sont respectivement les ensembles D1, D2, . . ., Dn. On suppose que, pour un point donné de l’exécution du programme, nous pouvons déterminer par analyse statique un ensemble V ⊆ D₁× D₂× . . . D_n qui correspond à l’ensemble des vecteurs possibles du n-uplet constitué par les n valuations des variables X1, . . ., Xnau point considéré. Cet ensemble est appelé domaine de variation et il s’agit d’un sur-ensemble de S, l’ensemble des n-uplets valides du point de vue de la spécification du programme analysé.

Cela signifie que pour toute exécution de ce programme, lors du passage au point d’exécution choisi, le vecteur x = (x1, . . . , xn) constitué par les valuations des variables X1, X2, . . ., Xn est un élément de S ⊆ V . Le mécanisme de détection d’intrusion que nous proposons insère avant le point d’exécution considéré des asser-tions exécutables visant à vérifier que le n-uplet constitué par les n valuaasser-tions des variables X1, . . ., Xn forme bien un élément de l’ensemble V . Dans le cas contraire une alerte est levée.

Prenons comme exemple le cas simple où n = 2 et où, au point considéré, la variable X₁ a pour domaine de variation I₁un intervalle continu sur D₁ et la variable X2 a pour domaine de variation I2 un intervalle continu sur D2. Nous pouvons en déduire que V = I1× I₂ représente l’ensemble des valeurs possibles pour le vecteur x = (x₁, x₂). Cet ensemble est représenté par le rectangle central de la figure 3.2(a). Lorsqu’une injection modifie seulement la valeur de x1, une alerte est levée si la nouvelle valeur n’est pas dans l’ensemble I1 (tandis que la valeur de x2 reste dans l’ensemble I₂). De même, lorsqu’une injection modifie seulement la valeur de x₂, une alerte est levée si la nouvelle valeur n’est pas dans l’ensemble I2 (tandis que la valeur de x1 reste dans l’ensemble I1).

Au final, l’ensemble des injections qui provoquent la levée d’une alerte correspond à l’ensemble (D1× I₂) ∪ (D2× I₁) \ (I1× I₂). Cet ensemble est représenté par l’espace de couleur gris foncé de la figure 3.2(b). Lorsqu’une injection modifie à la fois les valeurs de x1 et de x2, une alerte est levée si le nouveau couple de valeurs n’est pas dans l’ensemble I1 × I₂. Cette fois, l’ensemble des injections qui provoquent la levée

x2 D1 x₁ I₁ I₂ D₂ (a) x₂ D1 x1 I1 I2 D2 (b) x2 D1 x₁ I₁ I₂ D₂ (c)

Figure3.2 – Domaine de détection d’une injection à deux variables

d’une alerte correspond à l’ensemble (D1 × D2) \ (I1 × I2) Cet ensemble est représenté par l’espace de couleur gris foncé de la figure 3.2(c).

Si maintenant nous comparons ces deux situations, nous pouvons voir que le dernier ensemble, celui qui correspond à l’injection de deux variables simultanément, inclut le précédent ensemble, celui qui correspond à l’injection d’une seule variable à la fois. Ainsi, sur cet exemple, en augmentant le nombre de variables modifiées par une injection, on augmente effectivement la surface de détection de notre approche, et dont on réduit le taux de faux négatifs de notre système de détection d’intrusion. Au final, cet exemple illustre bien le fait qu’afin de placer notre approche pour la détection dans la situation la moins favorable, il ne faut donc modifier qu’une seule variable par injection. Une preuve de cette affirmation pour n et V quelconques est disponible en annexe.

3.1.2.3 Choix du type de corruption

Maintenant que nous savons que nous n’allons réaliser qu’une seule injection par exécution du programme à tester et que cette injection ne va cibler qu’une seule donnée, il nous faut choisir la valeur à fournir au mécanisme d’injection pour la corruption de la variable. Lors des situations réelles d’attaque que nous avons

présentées dans la section 2.3.1.1, les valeurs utilisées pour une attaque donnée sont liées au fonctionnement interne du programme ciblé. Il nous est donc impossible de connaître ces valeurs de manière automatique.

De plus, nous avons vu dans la section 3.1.1.4 que pour respecter la contrainte de ne simuler que des attaques réalisables grâce à une seule et unique exploitation de la vulnérabilité présente dans le programme, nous ne pouvons pas tenir compte de la valeur initialement contenue par la donnée ciblée. C’est pourquoi nous faisons le choix de ne pas émettre d’hypothèse sur ces dernières et de les tirer aléatoirement parmi la plage de valeur de l’élément ciblé lors de l’injection. Au final, lors d’une injection, nous allons donc choisir aléatoirement la nouvelle valeur parmi toute la plage de valeur possible de l’élément ciblé et ce sans tenir compte de la valeur originalement contenue.

3.1.2.4 Avantages et limites du modèle

Nous avons choisi de simuler la situation la moins favorable pour notre système de détection d’intrusion : nous allons simuler la présence en tout point du programme d’une vulnérabilité permettant un accès direct à l’ensemble de l’espace mémoire du processus en cours d’exécution et les attaques qui exploitent cette vulnérabilité n’ont besoin pour être réalisées que d’une seule exploitation et de ne corrompre qu’une seule donnée. Le modèle de faute que nous proposons dans ces travaux de thèse permet effectivement de simuler le résultat d’attaques contre les données de calcul ayant ce niveau de sévérité.

Cependant, nous avons pu voir au chapitre précédent dans la section 2.3.1.1, où nous illustrions le déroulement d’une attaque contre les données de calcul, que la corruption résultant de l’exploitation d’une vulnérabilité peut aussi bien nécessiter une valeur quelconque (cas de l’attaque contre la variable de boucle ok) qu’une valeur bien précise (cas de l’attaque contre la variable pwd). Nous n’avons pas moyen de déterminer automatiquement pour chacune des cibles si toute la plage de valeur est représentative d’une attaque contre les données de calcul ou bien si seule une liste de valeurs bien précises est pertinente. Notre modèle de faute ne permet donc pas à coup sûr de simuler une attaque nécessitant de corrompre sa cible avec une valeur bien précise.

Toutefois, plus nous effectuons de simulations d’attaque à l’aide de notre modèle de faute, plus nous avons de chance de simuler des états internes erronés représentat-ifs des situations réelles d’attaques contre les données de calcul. Afin de compléter l’évaluation de notre mécanisme de détection d’intrusion, nous proposons également d’estimer le taux de faux négatifs pour les simulations d’attaques qui ont sans le moindre doute provoqué une déviation comportementale.

Pour déterminer cela, nous proposons d’analyser les traces d’exécution du pro-gramme en cours de test. Cette analyse des résultats peut effectivement nous per-mettre d’identifier des simulations d’attaque qui sont représentatives des situations

réelles d’attaques contre les données de calcul. Mais en aucun cas cette analyse ne peut nous permettre de toutes les identifier. Cela est dû au fait qu’une sim-ulation d’attaque, bien que représentative d’une attaque réelle, ne provoque pas nécessairement une déviation comportementale observable (voir la problématique du masquage d’erreurs à la section 3.1.1.3). Nous aborderons ceci plus en détails dans la section 4.2.2.1 où nous présentons l’outil que nous avons utilisé pour mettre en évidence les déviations comportementales produites par les injections.