Les attaques contre les applications 

La détection d’intrusion hôte

La politique de sécurité d’un système d’information définit les propriétés de confidentialité, d’intégrité et de disponibilité que ce dernier doit respecter. Le respect de la confidentialité implique que seules les personnes autorisées ont accès en lecture aux éléments considérés. De même, le respect de l’intégrité implique que seules les personnes autorisées ont accès en écriture aux éléments considérés et que ces derniers sont modifiés de manière correcte. Enfin, le respect de la disponibilité implique que ces éléments considérés puissent être accessibles par les personnes autorisées au moment voulu. Une attaque contre un système d’information a pour but de violer ces propriétés. Si une telle attaque réussit alors l’intrusion est effective. Une intrusion dans un système d’information peut donc être défini comme une violation de sa politique de sécurité [And80].
Les systèmes de détection d’intrusion sont des outils permettant aux administrateurs de systèmes d’information d’être alertés en cas d’intrusion ou même de tentative d’intrusion afin de pouvoir réagir de manière adéquate. Certains outils, nommés systèmes de réaction, permettent d’aller plus loin dans l’automatisme [Tho07]. En effet, en plus de lever une alerte lorsqu’une intrusion est détectée, ces mécanismes prennent des mesures pouvant aboutir au blocage de l’intrusion (exemple : bannir l’adresse IP de l’attaquant).
Les mécanismes de détection d’intrusion reposent sur l’utilisation de sondes.
Celles-ci ont la capacité de collecter des informations qui, par une analyse ultérieure vont permettre de mettre en évidence la présence d’une attaque connue ou l’absence de comportement normal (voir section 1.1.2). Ces sondes peuvent être naturellement présentes sur le système d’information (par exemple, les différents fichiers journaux maintenus par le système d’exploitation ou par les applications). Elles peuvent aussi être fournies par le mécanisme de détection (par exemple, un renifleur de paquets réseaux ou encore un module spécifique à charger par le système d’exploitation ou par une application).
En fonction du placement de ces sondes, on distingue deux grandes catégories de système de détection d’intrusion : les systèmes de détection réseaux et les systèmes de détection hôtes. Dans le premier cas, les sondes sont placées au niveau des équipement réseaux et collectent les informations qui transitent sur le réseau. Dans le second cas, les sondes sont placées sur les machines qui exploitent le réseau et collectent les informations qui transitent au niveau du système d’exploitation ou au niveau des applications. Suivant le type de système de détection d’intrusion utilisé, il est plus ou moins facile de détecter certaines intrusions (par exemple, une attaque de type déni de service par syn flooding est plus facilement détectable au niveau réseau [Edd07]).
Dans les deux cas, les informations collectées par les sondes peuvent être utilisées par le mécanisme de détection de deux manières différentes : pour détecter des malveillances ou pour détecter des anomalies. Il s’agit respectivement des approches par signature et des approches comportementales. Le premier type d’approche repose sur la connaissance que l’on a des attaques tandis que dans le second sur la connaissance que l’on a du comportement de l’entité surveillée en situation de fonctionnement normal. Dans cette thèse, c’est un mécanisme de détection hôte que nous proposons. Nous allons donc maintenant présenter plus en détails ces deux approches dans le cadre de la détection hôte.

Modèles de détection par signature

Les détecteurs d’intrusion par signature reposent sur la création a priori d’une base de motifs représentant des scénarios d’attaque connus au préalable. Cette base de signature est ensuite utilisée, le plus souvent en temps réel, sur les informations fournies par les sondes de détection. C’est un système de reconnaissance de motifs qui permet de mettre en évidence dans ces informations la présence d’une intrusion connue de la base de signature.
Ces mécanismes de reconnaissance sont souvent peu consommateur de ressources et la pertinence de la détection de ce type d’approche est élevée. C’est pour ces deux raisons que ce type de système est souvent choisi pour être utilisé en production [PREL]. Cette démarche est similaire à celle employée par les mécanismes de détection des programmes malveillants. Par exemple, l’outil Hancock [GSHC09] propose d’extraire automatiquement à partir d’un ensemble de programmes malveillants des séquences d’octets ayant une très faible probabilité d’apparaître dans d’autres programmes.
Dans le cas des intrusions, les signatures sont créées à l’aide de langage de description d’attaque [lLWJ98, PD01, EVK02]. Leur création relève le plus souvent d’une tâche manuelle. Toutefois, des méthodes ont été proposées pour générer ces signatures de manière automatique [NS05, MG00]. Ces deux approches sont présentées plus en détails dans la suite de cette section. Le taux de couverture de ce type d’approche repose principalement sur la complétude de la base de signature ainsi que sur la qualité des motifs qui y sont contenus. En effet, le plus souvent une signature est associée à une attaque particulière. De ce fait, seules les attaques dont la signature est présente dans la base sont détectées. Cette approche présente donc deux inconvénients majeurs.
D’une part, elle ne permet pas de détecter des attaques inconnues. Cela signifie qu’entre le moment où une nouvelle attaque est conçue et le moment où celle-ci est connue, le système d’information est vulnérable malgré la présence d’un mécanisme de détection. Notons qu’il est possible de chercher à généraliser les signatures afin qu’il ne suffise pas de légèrement modifier une attaque pour réussir à contourner le mécanisme de détection. Toutefois, cette généralisation des signatures risque de faire augmenter le taux de faux positifs [PD00]. Notons aussi qu’une autre manière de généraliser une signature n’est pas de décrire l’exploitation de la vulnérabilité mais la vulnérabilité elle même [BNS + 06].
D’autre part, la base de signature doit être régulièrement mise à jour. Comme pour les mécanismes de détection des programmes malveillants, cette tâche est consommatrice en ressources. En effet, cela nécessite de la part des personnes chargées de la maintenance de la base de veiller en permanence à l’apparition de nouvelles attaques puis de prendre le temps d’écrire les signatures correspondantes. Cette fois, cela signifie qu’entre le moment où une nouvelle attaque est connue et le moment où la base est mise à jour, là encore le système d’information est vulnérable malgré la présence d’un mécanisme de détection.

Langages de description d’attaques

L’approche par signature se base sur la connaissance a priori du mode opératoire des attaques et par conséquent sur la connaissance d’activités caractéristiques à chacune de ces attaques. Ces activités caractéristiques se traduisent sur le système ciblé par des évènements observables eux aussi potentiellement caractéristiques de ces attaques. Pour décrire précisément une attaque, il faut pouvoir décrire ces différents évènements observables. Pour cela, il est nécessaire de disposer de langages adaptés à cette tâche.
Des langages ont été proposés avec pour objectif de se concentrer sur l’exploitation des failles. Ils permettent de décrire une à une les étapes nécessaires à l’exploitation d’une faille particulière [VEK00, EVK00]. Certains de ces langages ont d’ailleurs été proposés originalement pour automatiser l’exploitation des failles dans le cadre des tests d’intrusions [Sec98, Der99]. Cependant, il est important de pouvoir préciser l’état du système avant la réalisation de l’attaque. En effet, pour être réalisées, certaines attaques nécessitent qu’un certain nombre de conditions soit réu- nies (type de matériel ciblé, version du système d’exploitation, version de l’application, etc.). Des langages permettent explicitement d’exprimer ce genre de conditions [LMPT98, CO00, MM01].
D’autre langages choisissent de se concentrer sur les évènements observables au niveau du système. Par exemple, c’est notamment le cas des signatures des projets ORCHIDS [OGl05, GO08] et GnG [TVM04]. Des évènements tels que les appels système ou l’activation de certaines fonctions du noyau sont utilisés pour décrire les attaques. Ces évènements sont utilisés pour créer des automates décrivant les états et les transitions du système qui permettent de reconnaître la présence d’une intrusion en cours de réalisation. De plus, pour les évènements qui possèdent des paramètres, il est possible d’utiliser des opérateurs sur ces paramètres pour simplifier la description de l’attaque mais aussi pour exprimer des contraintes complexes sur ces derniers [PD00].

Découverte de signature d’attaques

Des travaux ont cherché à découvrir de manière automatique des signatures d’attaques [MG00]. Ces derniers se basent sur l’exploration de données. L’objectif de ces travaux est de réussir à caractériser un type de comportement bien précis pour les applications. Concrètement, cette approche repose sur l’utilisation d’une machine à états finis pour apprendre le type de comportement d’un groupe d’applications similaires dans le but de pouvoir ensuite reconnaître si une application donnée appartient ou non à ce groupe.
Par exemple, en effectuant la phase d’apprentissage sur un ensemble de traces d’exécution de différents navigateurs web, l’automate est ensuite capable de reconnaître la présence d’un navigateur web (qui ne faisait pas partie de la phase d’apprentissage) parmi un ensemble quelconque de traces d’exécution. En utilisant cette méthode d’apprentissage sur un ensemble de traces d’exécution d’applications différentes mais toutes compromises par un même type d’attaque, l’automate est alors capable de détecter sur d’autres applications une attaque similaire bien que celle-ci soit encore inconnue au moment de l’apprentissage si l’entrée qui leur est fournie est correcte ou non. Il est donc possible de modéliser un flot d’exécution à l’aide d’un automate de ce type, celui-ci pouvant ensuite être utilisé durant une phase de détection pour déterminer si le flot d’exécution observé est correct ou non.
Ce type de modélisation a été utilisé au niveau des appels système des processus [SBDB01]. Chaque état de l’automate représente le couple (numéro de l’appel système, adresse de l’appel). La phase d’apprentissage se fait à l’aide de traces d’exécution obtenues en utilisant l’outil strace qui permet notamment de connaître pour chaque appel le compteur ordinal du processus. C’est ce dernier qui contient l’adresse à partir de laquelle l’appel système a été effectué. Durant la phase de détection, à chaque fois qu’un appel système est effectué, on récupère le compteur ordinal du processus afin de construire un nouvel état. Puis, on regarde s’il existe au sein de l’automate à états fini une transition possible depuis l’état courant vers ce nouvel état. Si ce n’est pas le cas une alerte est alors levée. Enfin, le nouvel état construit devient le dernier état connu. Si celui-ci n’est pas présent dans l’automate, alors il est remplacé par un nœud initial à partir duquel tous les états valides sont atteignables.
Ainsi, le processus normal de vérification reprendra au prochain état valide.

Modèle statistique

Un modèle de Markov caché est un modèle statistique décrivant l’évolution d’une variable aléatoire selon un processus de paramètres inconnus où il n’est pas nécessaire de connaître l’ensemble des états passés de la variable pour prédire probabilistiquement son prochain état. Il est donc possible d’utiliser un modèle de Markov caché pour modéliser l’enchaînement des appels système exécutés. Pour réaliser la modélisation, on analyse un grand nombre de traces d’exécution des programmes durant une fenêtre de temps où l’on considère que ces derniers sont en situation de fonctionnement normal. Le modèle ainsi créé est ensuite utilisé à l’exécution durant la phase de détection afin de lever une alerte lorsque qu’un appel système observé n’a pas été prédit. Notons que puisqu’il s’agit d’un modèle statistique, un seuil doit donc être défini pour savoir à partir de quelle probabilité une alerte doit être levée.
Ce paramètre influence donc le taux de faux positifs et de faux négatifs de ce type d’approche.
Les travaux en détection d’intrusion qui reposent sur les modèles de Markov cachés [GRS06] ont montré que ce type de modélisation permet d’obtenir un taux de détection comparable à celui obtenu par les approches précédentes mais avec une surcharge à l’exécution plus faible. Notons également que des travaux ont cherché à utiliser ce type de modélisation pour détecter spécifiquement des élévations illégales du niveau de privilèges [CP03]. Le niveau de privilèges fait effectivement partie des informations connues du système d’exploitation à propos d’un processus.
Ce mécanisme de détection cible les programmes capables d’élever eux-même leur niveau de privilèges. Comme les autres mécanismes de détection en boîte noire, il ne détecte donc que les intrusions qui modifient l’enchaînement des appels système exécutés. Toutefois, le taux de détection des intrusions est bien meilleur en comparaison lorsque celles-ci aboutissent à une élévation illégale du niveau de privilèges.

Les approches de type boîte grise

Les approches de type boîte grise consistent à compléter les informations accessibles au niveau de l’interface entre les processus et le système d’exploitation par l’adjonction d’informations issues du fonctionnement interne des processus mais néanmoins aisément accessible au niveau du système. C’est par exemple le cas du contexte d’exécution ou encore des arguments passés en paramètres aux appels système. Par rapport aux approches de type boîte noire, ce type d’information va rendre plus difficile l’utilisation de mécanisme de contournement mais aussi permettre de détecter des attaques qui ne modifient pas l’enchaînement des appels système exécutés. L’amélioration de la détection va bien sûr dépendre du type d’information utilisé pour compléter le modèle de référence.
En pratique, la plupart des approches en boîte grise cherchent à compléter le contrôle des séquences d’appels système présenté par Forrest et al. [FHSL96, HFS98].
En effet, cette approche s’est déjà vu proposer des améliorations mais celles-ci constituaient toujours en une approche de type boîte noire (voir section 1.2.1.2). C’est pourquoi, même améliorés, ces modèles de détection restent peu efficaces contre les attaques qui ne modifient pas l’enchaînement des appels système exécutés et peuvent toujours être attaqués via des mécanismes de contournement, notamment par des attaques de type mimétisme [KKMR05, PSJ07]. Nous allons maintenant présenter plusieurs méthodes de modélisation comportementale en boîte grise et leurs apports respectifs en terme de détection cette vulnérabilité au travers d’une attaque. Puis, l’état erroné du processus en cours d’exécution va permettre une intrusion au sein du système sur lequel celui-ci s’exécute, le plaçant ainsi dans un état de défaillance intentionnel.
Dans le cadre des systèmes distribués, le projet MAFTIA [AAC + 03, VNC03, WWRS03, SWWR04] présente une approche pour la tolérance aux fautes qui est adaptée aux contraintes de la sécurité. En effet, le modèle de fautes ainsi proposé permet de prendre en compte les fautes accidentelles mais aussi les fautes intentionnelles. Dans ces travaux, nous proposons de détecter les erreurs à l’origine des intrusions. Plus précisément, pour détecter une intrusion, ou une tentative d’intrusion, nous proposons de détecter l’état erroné du programme suite à l’exploitation de la vulnérabilité par un utilisateur malveillant. À l’instar des travaux du projet MAFTIA, nous allons donc nous reposer sur un mécanisme de détection d’erreurs.
Nous présentons donc dans la section suivante un mécanisme de détection d’erreur issu du domaine de la sûreté de fonctionnement et qui a inspiré le mécanisme de détection que nous proposons ici.

Contrôles de vraisemblance

Les contrôles de vraisemblance consistent en l’évaluation des objets manipulés en interne par le programme. Ces évaluations sont effectuées pendant l’exécution du programme et ont pour objectif de vérifier une expression logique. Si l’expression logique n’est pas vérifiée, alors le programme est considéré comme étant dans un état erroné et une alerte est émise.
Le principal avantage des contrôles de vraisemblance est de ne générer qu’un faible sur-coût à l’exécution. Ceci est dû au fait que le nombre d’instructions nécessaires pour vérifier l’ensemble des expressions logiques d’un composant est le plus souvent faible par rapport au nombre total d’instructions de ce même composant.
Ils peuvent être utilisés pour détecter un grand nombre de types de fautes différents mais leur couverture est généralement faible.
Les contrôles de vraisemblance peuvent être implémentés à différents niveaux, soit par des composants matériels, soit par des composants logiciels. Dans les composants matériels, ces contrôles permettent de détecter des erreurs dans les données utilisées à bas niveau, tel que le code d’une instruction ou une adresse mémoire, ou des violations de la segmentation des espaces mémoires mis en œuvre par des composants tels qu’une unité de gestion de mémoire. Dans les composants logiciels, ces contrôles permettent de détecter des erreurs dans les données utilisées à plus haut niveau, telles que les données de calcul, par exemple en vérifiant la conformité de ces dernières vis-à-vis d’invariants.

Modèle de détection d’intrusion

Pour détecter une intrusion au sein d’un programme, nous proposons dans ces travaux de thèse une approche de type comportementale. Située au niveau applicatif, ce type d’approche requiert donc la construction préalable d’un modèle du comportement normal des programmes à surveiller et ceci afin de pouvoir mettre en évidence, pour chacun d’eux, les éventuelles déviations comportementales engendrées par une intrusion ou une tentative d’intrusion. Dans le cadre de l’approche que nous proposons, la construction de ce modèle est effectuée à partir du code source des applications concernées et celle-ci repose sur des techniques issues du domaine de l’analyse statique.
Notons que les techniques d’analyse statique sur lesquelles nous avons choisi de nous reposer nous assurent que les résultats obtenus sont des sur-approximations.
Cette méthode de construction permet donc de générer un modèle qui est complet, c’est-à-dire un modèle qui inclut tous les comportements possibles du programme.
Par conséquent, notre approche ne peut pas générer de fausse alerte. Cependant, si le modèle ainsi obtenu est complet celui-ci n’est pas correct. En effet, ce dernier représente une sur-approximation du comportement normal des programmes considérés. Par conséquent, il y a un risque avec notre approche que certaines intrusionsne soient pas détectées.
Dans ce chapitre, nous présentons l’approche comportementale que nous proposons pour détecter une intrusion dans un programme. Pour cela, nous abordons d’abord les différents types d’attaques dont peut être la cible un programme particulier et parmi celles-ci lesquelles notre approche cherche spécifiquement à détecter.
Nous abordons ensuite en détails la méthode que nous proposons pour détecter le type d’attaques que nous avons identifié comme étant la cible de notre approche.
Nous verrons notamment comment nous pouvons construire le modèle de comportement normal associé à notre approche pour la détection. Enfin, nous présentons aussi l’outil que nous avons développé pour valider et tester notre approche ainsi que lesoutils d’analyse statique sur lesquels nous avons fondé notre implémentation.

Les attaques contre les applications

Une intrusion est le résultat d’une attaque réalisée avec succès sur le système d’information ciblé. Si l’attaque échoue, on dit alors qu’une tentative d’intrusion a eu lieu. Au niveau d’un hôte appartenant au système d’information, une attaque peut viser son système d’exploitation ou bien les applications qui s’exécutent au dessus de ce dernier. Quelle que soit la cible, une attaque peut chercher soit à épuiser les ressources du composant ciblé soit à exploiter une vulnérabilité dans sa conception.
Dans le premier cas, l’attaque a nécessairement pour but de violer la propriété de disponibilité (on parle alors d’attaque par déni de service [Gli84, Ove99, Cri00]).
Au niveau du système d’exploitation, un déluge de paquet réseau est un exemple de déni de service par épuisement de ressource [Edd07].
Dans le second cas, l’attaque cherche en priorité à violer les contraintes de confidentialité et d’intégrité. Au niveau du système d’exploitation, la corruption des données d’un pilote de périphérique mal conçu est un exemple d’exploitation de vulnérabilité permettant de violer l’intégrité du système [But07, Bul07]. Dans le cas où un utilisateur malveillant cherche à attenter à l’intégrité d’une application, l’attaque peut être réalisée à un moment donné en corrompant une ou plusieurs données dans l’espace mémoire du processus en cours d’exécution. Ceci est vrai quelle que soit la vulnérabilité exploitée par l’attaque : dépassement de tampon sur la pile ou sur le tas, dépassement de la capacité d’un entier, dépassement de chaîne formatée, etc.
Ces données peuvent être classées en deux catégorie : les données de contrôle et les données de calcul. Une attaque contre les données de contrôle cherche à corrompre les données utilisées par le processus pour contrôler son flot d’exécution. Une adresse de retour sur la pile ou un pointeur de fonction dans le gestionnaire d’exception sont des exemples de données prises pour cible par de telles attaques. En modifiant ces données, il est possible de forcer l’exécution du processus vers du code injecté ou hors contexte. Dans les deux cas, le code exécuté est illégal et se trouve sur un chemin invalide.

Table des matières
Introduction 
1 État de l’art 
1.1 La détection d’intrusion hôte
1.1.1 Modèles de détection par signature
1.1.1.1 Langages de description d’attaques
1.1.1.2 Découverte de signature d’attaques
1.1.2 Modèles de détection comportementaux
1.1.2.1 Méthodes construite par une phase d’apprentissage
1.1.2.2 Méthodes paramétrées par la politique de sécurité
1.1.3 Positionnement des travaux
1.2 Les modèles comportementaux applicatifs
1.2.1 Les approches de type boîte noire
1.2.1.1 Réseau de neurones artificiel
1.2.1.2 Approche immunologique
1.2.1.3 Machine à états finis
1.2.1.4 Modèle statistique
1.2.2 Les approches de type boîte grise
1.2.2.1 Contrôle des appels aux bibliothèques
1.2.2.2 Contrôle des paramètres
1.2.2.3 Contrôle du contexte d’exécution
1.2.3 Les approches de type boîte blanche
1.2.3.1 Analyse de la spécification
1.2.3.2 Analyse du code source
1.2.4 Positionnement des travaux
1.3 La détection d’erreur
1.3.1 Définitions de la sûreté de fonctionnement
1.3.1.1 Faute
1.3.1.2 Erreur
1.3.1.3 Défaillance
1.3.2 Contrôles de vraisemblance
1.3.2.1 Utilisation d’un moniteur externe
1.3.2.2 Programmation défensive
1.3.3 Positionnement des travaux
1.4 L’injection de fautes logicielle
1.4.1 Procédure d’injection
1.4.1.1 Phase d’injection
1.4.1.2 Phase de surveillance
1.4.2 Génération des données
1.4.2.1 Modèle aveugle
1.4.2.2 Modèle spécifique
1.4.2.3 Modèle en mémoire
1.4.3 Positionnement des travaux
2 Modèle de détection d’intrusion 
2.1 Les attaques contre les applications
2.1.1 Les attaques ciblant les données de contrôle
2.1.1.1 Exécution de code injecté
2.1.1.2 Exécution de code hors contexte
2.1.2 Les attaques ciblant les données de calcul
2.1.2.1 Corruption des informations d’authentification
2.1.2.2 Corruption des informations de configuration
2.1.2.3 Corruption des informations de vérification
2.1.2.4 Corruption des informations de branchement
2.2 Un modèle de détection déduit du code source
2.2.1 La logique de Hoare
2.2.1.1 Les triplets de Hoare
2.2.1.2 Les règles d’inférence
2.2.2 Détection des attaques contre les données de calcul
2.2.2.1 Exploitation de la vulnérabilité
2.2.2.2 Application de la logique de Hoare
2.3 Un modèle orienté autour des variables
2.3.1 Présentation du modèle sur un exemple
2.3.1.1 Description de la vulnérabilité
2.3.1.2 Les scénarios d’attaque
2.3.1.3 La détection de l’intrusion
2.3.1.4 Formalisation du modèle
2.3.2 Découverte des variables à surveiller
2.3.2.1 Localisation des contrôles
2.3.2.2 La coupe de programme
2.3.2.3 Le graphe de dépendance du programme
2.3.3 Découverte des contraintes à vérifier
2.3.3.1 Les domaines de variation
2.3.3.2 L’interprétation abstraite
2.4 Implémentation du système de détection
2.4.1 Construction du modèle
2.4.1.1 Frama-C
2.4.1.2 Calcul des ensembles de variables
2.4.1.3 Calcul des contraintes sur les ensembles de variables
2.4.2 Instrumentation du programme
2.4.2.1 Écriture des fonctions stub
2.4.2.2 Pré-traitement des fichiers sources
2.4.2.3 Ajout des assertions exécutables
2.5 Résumé et discussion
3 Modèle de simulation d’attaque 
3.1 Simulation d’erreurs sur les données de calcul
3.1.1 Modèle de fautes
3.1.1.1 Caractéristiques à simuler
3.1.1.2 Impact des fautes sur le programme
3.1.1.3 Détection et caractérisation des erreurs
3.1.1.4 Construction du modèle d’injection
3.1.2 Évaluation du taux de détection
3.1.2.1 Choix du nombre d’injections
3.1.2.2 Choix du nombre de cibles
3.1.2.3 Choix du type de corruption
3.1.2.4 Avantages et limites du modèle
3.2 Implémentation du mécanisme d’injection
3.2.1 Instrumentation du programme
3.2.1.1 Calcul de l’ensemble des cibles
3.2.1.2 Ajout des mécanismes d’injection
3.2.2 Déroulement de la procédure
3.2.2.1 La fonction d’injection
3.2.2.2 Le paramétrage de l’injection
3.3 Résumé et discussion
4 Protocole de tests et analyse des résultats 
4.1 La plateforme de tests
4.1.1 Scénarios d’exécution
4.1.1.1 Scénario d’exécution du serveur
4.1.1.2 Scénario d’exécution du client
4.1.1.3 Cas problématiques
4.1.2 Informations collectées
4.1.2.1 Les traces d’exécutions
4.1.2.2 L’état d’arrêt du scénario
4.2 Résultat de l’évaluation
4.2.1 Évaluation de l’instrumentation
4.2.1.1 Performance de l’analyse
4.2.1.2 Surcharge à l’exécution
4.2.2 Évaluation du taux de couverture
4.2.2.1 Détection de la déviation comportementale
4.2.2.2 Présentation et analyse des résultats
4.3 Résumé et discussion
Conclusion 
Bibliographie 
Appendices 
A Comparaison pour n et V quelconques

Lire le rapport complet