2.2 Les systèmes de détection d’intrusion
2.2.4 L’évaluation des HIDS
Cette section présente dans un premier temps les métriques utilisées pour éva-luer des techniques de détection d’anomalie, puis présente différentes techniques d’évaluation des HIDS.
2.2. Les systèmes de détection d’intrusion 37
Table 2.2 – Matrice de confusion Positif réel Négatif réel
Positif prédit TP FP
Négatif prédit FN TN
2.2.4.1 Métriques utilisées
La détection d’anomalies consiste à classer des observations comme normales ou anormales, selon un modèle donné. Dans le domaine de l’apprentissage automa-tique, cette classification consiste à prédire un label pour une observation, qui sera positif ou négatif selon la prédiction donnée par l’algorithme de détection. Dans ces travaux, les observations ditesNégativesreprésentent des comportements normaux, tandis que les observations ditesPositives représentent des anomalies. Une matrice de confusion, représentée par la Table 2.2, permet de caractériser les résultats pré-dits par rapport aux résultats attendus. Plus précisément, on retrouve les quatre catégories suivantes :
— Vrai Positif ou True Positive (TP) : l’observation d’une anomalie est prédite correctement comme une anomalie.
— Vrai Négatif ouTrue Negative(TN) : l’observation d’un comportement normal est prédite correctement comme un comportement normal.
— Faux Positif ouFalse Positive(FP) : l’observation d’un comportement normal est prédite de façon erronée comme une anomalie.
— Faux Négatif ouFalse Negative(FN) : l’observation d’une anomalie est prédite de façon erronée comme un comportement normal.
A partir de ces métriques de base, plusieurs métriques ont été développées pour représenter différentes caractéristiques de la détection d’anomalie. Les plus couram-ment utilisées sont l’exactitude ou accuracy, la précision ou precision, et le rappel ou recall.
L’exactitude représente le taux d’observations qui ont été classées correctement.
Exactitude:E = T P +T N
T P +F N +F P +T N (2.1)
Elle permet d’avoir une vue générale de l’efficacité d’un détecteur d’anomalies, mais est très sensible au nombre d’observations de chaque classe (normale ou anormale). Par exemple, s’il y a beaucoup plus d’exemples négatifs réels, l’exactitude d’un système prédisant systématiquement les observations comme négatives pourra être excellente. Dans ce cas, il est important de vérifier la valeur d’autres métriques.
La précision représente le taux d’observations classées positives qui sont réelle-ment positives.
P récision:P = T P
Elle permet notamment de vérifier l’absence de faux positif, donc d’observation normale classée comme anormale. L’absence de faux positif est une contrainte forte dans le domaine avionique, notamment pour construire un haut niveau de confiance dans un équipement. En effet, de fausses alertes pourraient avoir de graves consé-quences pour une compagnie aérienne (avions cloués au sol, image de marque). A terme, si ces alertes sont suivies d’une réaction automatique directement dans les calculateurs, de fausses alertes pourraient également avoir un impact sur la sûreté du vol.
Enfin, le rappel représente le taux de positifs réels qui ont été correctement prédits comme positifs.
Rappel:R= T P
T P +F N (2.3)
Cette métrique renseigne sur le taux d’anomalies qui ont été correctement clas-sées comme telles. Généralement, les constructeurs d’IDS cherchent à maximiser ce taux, sans impacter trop fortement le nombre de faux positifs. En effet, les systèmes d’information classiques profitent de systèmes de supervision ou Security Opera-tions Center (SOC) qui leur permettent de traiter chaque alerte par des opérateurs qualifiés. En avionique, même si la détection de tout évènement de sécurité est im-portante pour la sécurité du vol, on ne peut pas se permettre de traiter des faux positifs. En effet, un faux diagnostic peut mener à réagir d’une façon non conforme au problème à résoudre, et engendrer ensuite d’autres erreurs au sein de l’aéronef. Pour un système critique, il est donc très important de donner des résultats pré-cis. Au-delà d’un impact potentiel sur la sûreté du vol, de fausses alertes peuvent impacter directement l’économie d’une compagnie aérienne, par exemple si celle-ci est obligée de clouer une flotte entière au sol par prévention. Les travaux présentés dans ce manuscrit se concentrent donc d’abord sur l’objectif d’atteindre un taux
de faux positifs nul.
Ces métriques sont utilisées ici pour évaluer l’efficacité d’un HIDS applicatif. Dans ce cas, une observation positive correspond à une observation durant laquelle une attaque a été exécutée. Une observation négative représente quant à elle une observation durant laquelle l’application surveillée s’est exécutée de façon normale.
2.2.4.2 Techniques d’évaluation des HIDS
Les métriques présentées précédemment supposent toutes la manipulation d’ob-servations anormales afin d’être évaluées. L’évaluation de l’efficacité d’un HIDS né-cessite donc l’accès à des données d’attaque. Aujourd’hui, ces données peuvent être effectivement observées dans le cas de bases de données d’attaques utilisables, ou générées artificiellement. Afin de tester au mieux l’efficacité d’un HIDS, ces données d’attaques doivent être aussi exhaustives que possible. Le MITRE [MITRE 2018] propose en ce sens une classification d’attaques visant des systèmes informatiques traditionnels. Certaines classifications, comme [Gadelrab 2007], ont été proposées spécifiquement pour construire des campagnes de test pour évaluer l’efficacité de systèmes de détection d’intrusion. Cependant, peu d’études abordent les attaques
2.2. Les systèmes de détection d’intrusion 39
informatiques applicables aux systèmes avioniques et à leurs contraintes, comme la classification proposée dans [Dessiatnikoff 2012].
Généralement, la collecte de données réelles d’attaque s’avère complexe, d’au-tant plus pour des systèmes spécifiques comme les systèmes embarqués critiques. Plusieurs études proposent une alternative en focalisant sur des données géné-rées expérimentalement, par exemple via l’utilisation de techniques d’injection de fautes [Arlat 1990]. Le but de ces injections est d’émuler des comportements mal-veillants représentatifs de la manifestation d’une attaque réelle sur le système ciblé. Par exemple, des outils de découverte de vulnérabilités tel que [Dessiatnikoff 2011] pourraient être utilisés afin de générer des comportements malveillants, mais égale-ment pour découvrir des vulnérabilités et définir des attaques réalistes en consé-quence. Sans impacter la cible, l’outil ID2T [Vasilomanolakis 2016] injecte des paquets représentatifs d’une attaque dans une capture réseau effectuée sur le ré-seau réel d’une entreprise. Cet outil permet donc de créer artificiellement des données d’attaque représentatives de l’environnement, sans attaquer directement celui-ci. L’injection de vulnérabilités et d’attaques associées est également explorée dans [Fonseca 2009] sur des services web. Un module d’injection de vulnérabilité modifie le code du service web, tandis qu’un module d’injection d’attaque effectue des injections SQL sur ce service web pour exploiter la vulnérabilité introduite. Il n’y a pas à notre connaissance d’outil équivalent, permettant d’injecter du code malveillant, sur des applications avioniques.
Au contraire, les techniques d’injection de fautes ont été largement étudiées pour valider les mécanismes de tolérance aux fautes développés pour les systèmes critiques, dont les systèmes avioniques. Une étude de l’état de l’art sur l’injection de fautes par émulation logicielle a été proposée récemment dans [Natella 2016]. Cette étude présente en particulier les injections de mutations de code permettant d’émuler des fautes logicielles. Des mécanismes similaires pourraient être développés pour émuler du code malveillant. Il faut cependant prendre en compte quelques spécificités de l’injection d’attaques par rapport à l’injection de faute logicielle :
— Les instructions injectées dans le code binaire ne doivent pas forcément être représentatives d’erreurs réalisées dans le code source.
— La gestion du moment de l’exécution de la charge malveillante est directement géré par le code malveillant, et pas par un système extérieur. En ce sens, du code malveillant peut être exécuté sans activer sa charge malveillante direc-tement. Il est cependant nécessaire de détecter cette exécution, avec ou sans activation de la charge malveillante.
— Les distributions de fautes proposées dans des études telles que [Duraes 2006] ne sont pas toujours directement applicables à des fautes intentionnelles. En effet, [Duraes 2006] propose un ensemble de 18 opérateurs permettant de couvrir 68% des fautes logicielles les plus fréquentes. Ces opérateurs ont été revus et étendus par [Cerveira 2017] pour prendre en compte non pas les fautes (safety) mais les vulnérabilités (security) les plus fréquentes. Ces opérateurs ont permis de couvrir environ 57% des vulnérabilités relevées sur plusieurs projets open-source. Ils
ont également mis en évidence les difficultés à représenter des vulnérabilités à l’aide d’un seul opérateur. Ces opérateurs, s’ils permettent d’émuler des vulnérabilités logicielles, ne sont pas pour autant forcément représentatifs d’un morceau de code malveillant. L’émulation d’attaques, et d’autant plus sur des systèmes avioniques, reste donc un domaine de recherche peu exploré.