Temps de calcul pour la Partition HIDS

Pour capturer le temps de calcul nécessaire à la partition HIDS, deux points d’arrêt ont également été utilisés autour du code de la partition. Si l’on schématise la structure de cette partition, elle commence par une phase d’initialisation puis une boucle infinie qui va s’occuper du traitement à chaque cycle d’exécution. C’est la durée de ce traitement qui est capturée ici. Cette structure et les deux points d’arrêt utilisés pour effectuer les captures de durée de la partition HIDS sont décrits par le Listing 5.3.

(a) Solution AT_comms

(b) Solution OCSVM_seq_freq

5.4. Expérimentations 113

(a) Solution AT_comms (services de communications et autres services)

(b) Solution OCSVM_seq_freq (tous les services)

Figure 5.6 – Distribution globale du temps d’exécution, avec ou sans instrumen-tation

# Phase d'initialisation de la partition init();

# Boucle infinie while(1) {

# Premier point d'arrêt # Traitement périodique do_stuff();

# Deuxième point d'arrêt

# Attendre le prochain cycle d'exécution PERIODIC_WAIT();

}

Listing 5.3 – Structure d’une partition avionique et emplacement des points d’arrêts permettant de capturer la durée d’exécution de cette partition (Code C)

(a) Solution AT_comms (b) Solution OCSVM_seq_freq Figure 5.7 – Distribution du temps d’exécution de la partition HIDS sur plus de 7000 captures

Une capture de plus de 7000 cycles d’exécution a été réalisée pour chacune des solutions (AT_comms et OCSVM_seq_freq). La distribution de durée pour chaque solution est donnée sur les Figures 5.7a et 5.7b.

Pour la solution AT_comms, on observe une durée d’exécution médiane de 524 tics d’horloge, ce qui correspond à 0.014ms, soit 0.21% du temps d’exécution alloué à la partition surveillée IHM-DV, ce qui est un excellent résultat. Cependant, ce résultat concerne le cas d’utilisation moyen de l’application. Pour ces captures, entre 136 et 158 logs étaient traités, pour une médiane de 140 logs traités par cycle. Si l’on considère le pire cas, l’application pourrait faire des appels API en boucle pendant toute sa durée d’exécution. Ce comportement peut être légitime pour cer-taines applications, par exemple, elles peuvent exécuter un service de lecture de message jusqu’à obtenir un message (la non disponibilité du message est un retour possible du service). Dans ce cas, on peut estimer le nombre maximal de logs

gé-5.5. Conclusion 115

nérés pendant 6.7ms (temps d’exécution de la partition surveillée), en considérant qu’elle peut faire au maximum un appel tous les 50 tics d’horloge. Dans ce cas, le nombre maximal de log généré est de 5025. On peut raisonnablement considérer que le temps d’exécution de la partition HIDS, pour la solution AT_comms, est linéairement proportionnel au nombre de logs à traiter. Dans ce cadre, on peut es-timer le pire temps d’exécution à 18.864 tics d’horloge, soit 0.50ms, soit 7.5% du temps alloué à la partition surveillée, ce qui dépasse le budget alloué à la partition HIDS. Néanmoins, cette solution peut être très efficace pour des applications qui n’ont pas ce type de comportement, à condition de borner le nombre de logs pos-sible par cycle d’exécution. Dans ce cas, un débordement du nombre de logs peut représenter en lui-même une anomalie de comportement.

Pour la solution OCSVM_seq_freq, la durée d’exécution médiane observée est de 3557 tics, soit 0.095ms, soit 1.42% du temps alloué à la partition IHM-DV. Cette solution respecte largement le budget alloué à la partition HIDS. Elle est moins efficace sur le cas observé que la solution AT_comms, cependant ce temps est garanti quel que soit le nombre d’appels API effectués par l’application surveillée. En effet, dans tous les cas, un seul log sera à traiter. Si l’on reprend le pire cas évoqué précédemment, le temps de traitement de l’HIDS, pour la solution

OCSVM_seq_freq, restera autour de 0.095ms.

5.5 Conclusion

Dans ce chapitre, nous avons proposé différentes alternatives de solution afin de concentrer les efforts liés au portage des développements sur la cible, aux so-lutions les plus prometteuses. Dans ce cadre, sept alternatives ont été proposées, faisant varier 1) les données utilisées et 2) le type de modèle utilisé pour la détec-tion d’anomalie. Concernant les données, nous avons proposé d’observer de façon séquentielle tous les appels API ou seulement ceux relatifs aux communications, ou d’observer de façon fréquentielle (sur un cycle d’exécution) les appels API effectués ou les séquences d’appels API effectuées avec leur durée. Concernant le modèle, un OCSVM, un automate, et un automate temporisé ont été utilisés, de façon à obtenir une bonne généralisation des données ou un modèle adapté aux données séquentielles plus ou moins simples.

L’efficacité de chaque solution a ensuite été évaluée sur deux applications diffé-rentes, IHM-DA et IHM-DV. La comparaison de ces résultats a permis de mettre en évidence deux alternatives très efficaces (score de détection de plus de 90% sur chaque application test), qui ont été implémentées sur cible par la suite. L’implé-mentation sur cible a permis d’évaluer précisément les ressources nécessaires à la mise en place de ces solutions, qui sont résumées dans la Table 5.5.

Ces résultats ont montré que la consommation de ressources de ces solutions remplit les objectifs fixés, à savoir utiliser moins de 5% des ressources disponibles, excepté pour la solution AT_commsdans le pire cas estimé.

Table 5.5 – Récapitulatif des résultats obtenus (consommation de ressources sur cible)

Solution Taille du code Temps de calcul

(.elf) Moniteur

de SDA ^PartitionHIDS ^PartitionHIDS

(par appel) (pire cas)

AT_comms 28.4ko (0.11%) +3% 0.21% 7.5%

OCSVM_seq_freq 63.9ko (0.24%) +3% 1.42% 1.42%

d’un système de Détection d’anomalie embarqué sur un calculateur avionique. Le chapitre suivant propose des pistes pour traiter les deux autres activités liées à la phase d’opération, à savoir la Confirmation d’attaque et l’Investigation au sol.

Chapitre 6

Aide au diagnostic

Ce chapitre présente quelques pistes de réflexion relatives aux parties dédiées à la

Confirmation d’attaqueet à l’Investigation au sol de l’approche générale d’introduc-tion d’un HIDS avionique proposée dans cette thèse. Dans les chapitres précédents, l’approche a été évaluée de façon globale au regard des exigences du domaine avio-nique, et plus particulièrement concernant l’efficacité de détection de la partie de

Détection d’anomalie, et sa compatibilité à un environnement embarqué. Ce cha-pitre propose d’aller un peu plus loin, en proposant d’adjoindre aux alertes envoyées par la partie de Détection d’anomalie des informations supplémentaires, qui per-mettront de caractériser l’alerte d’une part (Confirmation d’attaque), et d’aider le diagnostic ultérieur au sol d’autre part (Investigation au sol).

Ce chapitre se découpe en quatre sections. La première présente le principe d’aide au diagnostic proposé dans cette thèse, et notamment l’architecture envisagée pour la réaliser. La deuxième section détaille l’implémentation de ces travaux dans

notre environnement d’étude. La troisième section décrit plusieurs expérimentations réalisées afin d’évaluer l’intérêt de cette partie d’aide au diagnostic et sa capacité à être embarquée dans un calculateur avionique. Enfin, la dernière section termine ce chapitre en résumant les pistes explorées pour réaliser l’activité d’aide au diagnostic, les conclusions associées, et les perspectives relatives à ces travaux plus prospectifs que ceux présentés aux chapitres précédents.

6.1 Principe

Les chapitres précédents se sont concentrés sur la partie deDétection d’anoma-lie, dont le but est de lever une alerte lorsqu’un comportement anormal survient. Le principe proposé ici cherche à construire un message relatif à cette alerte, qui apporte suffisamment d’information pour faciliter le traitement de l’alerte à bord d’une part, et pour aider un acteur au sol à réaliser un diagnostic suite à cette alerte d’autre part. Une première partie présente une vue globale des activités liées à la construction finale d’un message d’alerte au sein de l’HIDS. Cette approche se base sur la définition d’une signature de l’alerte, qui est ensuite comparée à une base de connaissances embarquée afin de sélectionner les informations essentielles à transmettre au travers du message d’alerte. Elle se découpe en quatre composants (Extraction de la signature, Recherche dans la base de connaissances, Construc-tion du message d’alerte, et InvestigaConstruc-tion au sol), qui sont détaillés dans les parties suivantes.