Expérimentation 2 : efficacité de détection de l’HIDS

Cette deuxième expérimentation cherche à caractériser plus précisément les ré-sultats de détection, par rapport aux opérateurs d’attaque utilisés. Elle a été menée sur la deuxième application d’affichage cockpit, appelée IHM-DV. Cette application donne des informations de vol au pilote, comme sa vitesse ou son cap. Les fichiers suivants ont été générés à l’aide de l’outil d’injection :

— 20 exemples d’attaques pour chacun des 9 opérateurs implémentés, soit 180 fichiers de données d’attaque, d’une durée de 20 secondes chacun,

— 51 fichiers de données normaux, d’une durée de 10 à 30 secondes.

Pour cette expérimentation, chaque opérateur d’attaque a donc été utilisé 20 fois avec des paramètres choisis aléatoirement. A titre informatif, la Table 4.6 donne

4.3. Expérimentations 91

Table4.6 – Caractéristiques de l’application IHM-DV observées à partir des fichiers de données normaux

Nombre d’appels API effectués par slot d’exécution 173 Proportion d’appels API relatifs aux communications 82.1%

Nombre d’appels API différents 30

Nombre de séquences d’appels API différentes tous (communications)

taille des séquences = 2 43 (25)

taille des séquences = 3 90 (56)

taille des séquences = 4 124 (88)

taille des séquences = 5 145 (106)

Table 4.7 – Scores d’évaluation obtenus pour les cinq expérimentations réalisées N° Durée du

fichier d’entraîne-ment

Taille des

séquences ^Précision(Test) ^Rappel(Test) ^Précision(Évaluation) ^Rappel(Évaluation)

1 30s 3 100% 100% 100% 84.57%

2 25s 3 100% 100% 99.30% 87.04%

3 30s 3 100% 100% 100% 85.80%

4 30s 3 100% 100% 100% 87.65%

5 30s 3 100% 94.44% 100% 84.57%

quelques caractéristiques de l’application IHM-DV observées dans les fichiers de données normaux, relatives à son utilisation normale des appels API.

Pour les deux phases d’entraînement et de test, un total de 23 fichiers sont utilisés : 5 fichiers normaux sont sélectionnés aléatoirement parmi les 51 fichiers de données normaux, et 10% des fichiers d’attaque sont également utilisés (18 fichiers). De la même manière que la première expérimentation, les paramètres de l’HIDS sont optimisés sur ces 23 fichiers (1 fichier normal utilisé pour la phase d’entraînement, et les 22 fichiers restants utilisés pour la phase de test).

L’évaluation est ensuite réalisée sur l’ensemble des fichiers restants, soit 46 fi-chiers normaux et 162 contenant une attaque. Cette expérimentation a été menée 5 fois, avec à chaque fois une séparation différente entre les fichiers utilisés pour les phases d’entraînement et de test, et les fichiers utilisés pour la phase d’évaluation. La Table 4.7 résume les résultats obtenus pour chacune de ces 5 expérimentations, en précisant la durée du fichier d’entraînement sélectionné pour l’évaluation, la taille de séquence sélectionnée pour l’évaluation, et les valeurs de précision et rappel ob-tenues lors des phases de test et d’évaluation.

Pour chaque expérimentation, plusieurs jeux de paramètres ont donné les meilleurs résultats (100% de précision et meilleur rappel). Pour sélectionner le jeu de paramètres final, la stratégie appliquée a été de choisir le plus grand fichier

d’entraî-Table 4.8 – Détail du score de détection par classes d’attaque (+ : Nombre de fichiers détectés comme normaux,-: Nombre de fichiers détectés comme anormaux)

(a) Classement des fichiers de données normaux (46 au total)

N° 1 N° 2 N° 3 N° 4 N° 5 Taux de + - + - + - + - + - faux positifs Normal (10s) 20 0 21 0 19 0 20 0 21 0 0% Normal (15s) 4 0 5 0 4 0 4 0 5 0 0% Normal (20s) 14 0 13 1 16 0 15 0 13 0 1.54% Normal (25s) 4 0 2 0 3 0 3 0 4 0 0% Normal (30s) 4 0 4 0 4 0 4 0 3 0 0%

(b) Classement des fichiers de données contenant une attaque (162 au total)

N° 1 N° 2 N° 3 N° 4 N° 5 Taux de + - + - + - + - + - vrais positifs Attaque (MIA) 3 15 2 17 2 17 2 18 2 16 88.23% Attaque (MI) 5 13 3 17 2 15 0 19 2 15 86.74% Attaque (MS_1) 2 16 1 16 1 17 1 16 2 17 92.21% Attaque (MS_2) 3 16 1 16 1 15 0 17 4 14 89.97% Attaque (MR) 5 13 5 11 6 13 5 13 5 11 70.07% Attaque (MV) 4 13 4 15 6 12 6 13 6 13 71.79% Attaque (AI) 3 16 4 14 4 14 4 14 4 14 79.06% Attaque (SI) 0 18 1 17 1 18 1 17 0 20 96.73% Attaque (SF) 0 17 0 18 0 18 2 14 0 17 97.50%

nement, puis la plus grande taille de séquences, et enfin la tolérance maximale. C’est pourquoi la taille de séquence choisie a été systématiquement 3 pour chaque expé-rimentation, et que la durée du fichier d’entraînement varie entre 25 et 30 secondes. Concernant les résultats de l’évaluation, la précision reste très bonne (>99%), seul un cas d’expérimentation ayant relevé un faux positif (N°2). Par contre, le rappel est moins bon que celui obtenu pendant la phase de test, tout en restant significa-tivement élevé (entre 84.57% et 87.65% pour la phase d’évaluation, contre un score de 94.44% à 100% sur la phase de test). Ce résultat peut s’expliquer par le peu d’exemples utilisés pour la phase de test comparé au nombre d’exemples utilisés pour la phase d’évaluation.

La Table 4.8 détaille les résultats obtenus à l’évaluation, par classe de fichier, pour chacune des 5 expérimentations. Les fichiers normaux ont été détaillés en fonction de leur durée (Table 4.8a), tandis que les fichiers d’attaque ont été détaillés en fonction de l’opérateur d’attaque utilisé pour les générer (Table 4.8b).

Deux tendances ressortent des résultats moyens de détection, par type d’opéra-teur d’attaque. D’abord, les attaques basées sur les opérad’opéra-teurs de modification de registre (MR) et de modification de valeur en mémoire (MV) affichent le taux de détection le plus bas, suivi par l’opérateur de duplication d’instruction (AI). Ces

4.4. Conclusion 93

performances peuvent être expliquées par un manque d’impact de l’attaque, cou-plé avec un très faible nombre d’instructions supcou-plémentaires injectées pour réaliser l’attaque (moins de 30 instructions assembleur). Également, le niveau d’observation utilisé ici (les appels API avec leur type et leur horodatage) n’est peut-être pas le plus adapté pour repérer des modifications dans la zone de données de l’application ou dans ses registres. L’observation de l’utilisation de la mémoire pourrait être un bon complément pour améliorer ces résultats.

Deuxièmement, les attaques basées sur les opérateurs de suppression d’instruc-tion et de suppression de foncd’instruc-tion sont très bien détectées (respectivement 96.73% et 97.50% des attaques sont repérées). En effet, ces opérateurs impactent fortement le fonctionnement de l’application, d’un point de vue temporel (pour l’opérateur

SF) et d’un point de vue fonctionnel (pour les deux opérateursSI etSF).

4.4 Conclusion

Ce chapitre a présenté une implémentation complète de l’approche et de l’outil d’injection d’attaque décrits dans le Chapitre 3. L’implémentation de l’approche se base sur la collecte de données réelles observées au travers de l’instrumentation d’une application avionique exécutée sur un calculateur avionique réel (moniteur de SDA). Ces données sont ensuite traitées hors du calculateur, sur une station de prototypage, afin de définir au mieux le SDA au travers des étapes deprétraitement des données, modélisation du SDA, et vérification du SDA. Un outil d’analyse de l’utilisation des ressources a également été développé pour proposer des pistes de réflexion quant à la réutilisation des informations disponibles dans le processus de développement IMA actuel, pour réaliser l’étape d’Analyse statique de sécurité. Concernant l’implémentation de l’outil d’injection d’attaque, 9 opérateurs d’at-taque ont été implémentés afin de représenter les trois stratégies de mutation de code définies au Chapitre 3. Ces 9 opérateurs cherchent également à représenter différentes possibilités en terme d’injection d’attaque, en intégrant pour certains les moyens d’ajouter du code et/ou de contrôler le moment d’activation de la charge malveillante (en terme temporel et/ou fréquentiel). L’outil proposé est capable de conserver l’exécution temps-réel à l’intérieur du calculateur cible, s’il n’interagit pas avec l’extérieur (pilote ou I/O). Sa configuration lui permet d’être facilement adap-table à d’autres applications. L’implémentation des opérateurs a été réalisée pour une architecture cible PowerPC. Cependant, le concept des opérateurs reste le même d’une architecture à une autre. Le portage sur une autre architecture est également facilité par l’utilisation de la liaison client-serveur GDB, qui est standardisée.

Deux types d’expérimentations viennent compléter la description de l’implémen-tation de l’approche. La première a démontré la pertinence de l’outil d’injection d’attaque pour le calibrage d’un HIDS efficace. En effet, cette expérimentation a montré que l’on est capable de calibrer un HIDS sans exemple d’attaque réel, qui soit efficace face à des attaques ayant un réel impact sur l’application cible. La deuxième expérimentation va plus loin en recherchant des tendances relatives à l’efficacité de

détection de l’HIDS en fonction des opérateurs d’attaque implémentés. En particu-lier, ces tendances pourraient permettre de réorienter les choix des caractéristiques à observer dans le SDA. Par exemple, sur l’application étudiée pendant cette seconde expérimentation, les attaques relatives aux modifications dans la mémoire ou les registres sont les plus difficiles à repérer. Il pourrait donc être intéressant d’ajouter un capteur pour observer l’utilisation de la mémoire par l’application.

Pour conclure, l’implémentation de l’approche proposée dans ce chapitre s’est concentrée sur les activités liées à la phase d’intégration. Dans ce cadre, cette im-plémentation n’a pas été réalisée entièrement sur un calculateur avionique réel, mais elle permet néanmoins de valider l’efficacité de détection de l’HIDS à partir de données réelles. Le prototype utilisé pour la phase d’intégration étant mainte-nant complètement défini, le chapitre suivant propose d’évaluer différentes solutions d’HIDS et d’implémenter sur calculateur les solutions les plus prometteuses.

Chapitre 5

Implémentation de l’HIDS

embarqué pour l’évaluation des

performances

Sommaire

5.1 Alternatives étudiées . . . . 95 5.1.1 Description des alternatives . . . . 96 5.1.2 Détail de l’implémentation de chaque solution . . . . 98 5.1.3 Conclusion . . . 103 5.2 Évaluation de l’efficacité des alternatives . . . 103 5.3 Implémentation de la partie embarquée . . . 105 5.3.1 Architecture implémentée sur cible . . . 106 5.3.2 Solution embarquée 1 : AT_comms . . . 107 5.3.3 Solution embarquée 2 : OCSVM_seq_freq . . . 110 5.4 Expérimentations . . . 111 5.4.1 Temps de calcul pour leMoniteur de SDA . . . 111 5.4.2 Temps de calcul pour laPartition HIDS . . . 111 5.5 Conclusion . . . 115

Ce chapitre aborde la partie opérationnelle de l’HIDS, et notamment la partie qui sera embarquée à bord d’un calculateur avionique. Dans un premier temps, il est important de bien choisir les différents éléments de l’HIDS, à savoir les données observées et l’algorithme utilisé pour les traiter. C’est l’objectif des travaux présen-tés dans la première partie de ce chapitre. Plus précisément, plusieurs alternatives sont proposées, chacune présentant ses avantages et inconvénients, puis elles sont évaluées en terme d’efficacité grâce à l’utilisation du prototype lié aux activités d’intégration. La deuxième partie de ce chapitre présente l’implémentation de deux solutions HIDS embarquées, qui ont permis d’évaluer précisément les ressources nécessaires pour la partie embarquée de l’HIDS.

5.1 Alternatives étudiées

Dans le Chapitre 4, une première solution basée sur l’observation de séquences d’appels API ARINC 653 avec leur durée, modélisées sous la forme d’unOne-Class

Support Vector Machine (OCSVM), a été proposée. Cette solution a permis de développer un premier prototype pour les activités de l’approche liées à l’intégra-tion, et de valider l’intérêt d’une telle approche d’HIDS avionique. Également, cette première solution a permis de valider l’intérêt de l’outil d’injection d’attaque.

Cependant, cette solution présente une possible limitation pour être embarquée dans un calculateur en vol. Par exemple, si l’application observée effectue des ap-pels API en boucle, la fenêtre de logs nécessaire pour conserver l’ensemble des traces émises par l’application durant un cycle d’exécution peut être très large. Dans cette section, plusieurs alternatives sont donc proposées dans le but d’étudier des variantes plus adaptées à ce type de contraintes. Les deux axes étudiés sont notamment la réduction du nombre de logs, et une mise en forme permettant la génération d’un log de taille fixe à chaque cycle d’exécution.

Le choix de l’algorithme utilisé est également remis en cause. En effet, le modèle OCSVM est plus adapté pour généraliser et représenter des données avec des valeurs continues, plutôt que la présence ou l’absence d’une caractéristique. En ce sens, il est très adapté pour représenter la durée des séquences, mais il l’est moins pour représenter l’identifiant de la séquence considérée. Pour cela, l’utilisation du one-hot encoding est nécessaire, mais entraîne une augmentation de la taille des données pré-traitées. D’après les conclusions de l’état de l’art présenté dans le Chapitre 2, il parait important de tester également les automates temporisés, qui semblent parfaitement adaptés au problème considéré.