Extraction de la signature

Le but de cette fonction est d’extraire de l’information sur l’application afin de créer une signature de l’alerte. Pour ce faire, plusieurs données de nature différente peuvent être considérées. Notamment, ces données peuvent être divisées en trois catégories :

— Données relatives à l’alerte : Ces données représentent les informations

qui découlent directement de l’alerte levée. Ici, ces données correspondent donc directement aux anomalies relevées par le détecteur d’anomalies.

— Données d’exécution de l’application : Ces données correspondent aux

informations qui sont enregistrées pendant l’exécution de l’application sous surveillance. C’est par exemple le cas des données brutes enregistrées par le

Moniteur de SDA. Pour le moment, ces données sont utilisées uniquement pour déterminer s’il y a des anomalies, puis elles sont supprimées. Il serait donc possible de conserver tout ou partie de ces informations, voir d’introduire de nouvelles données enregistrées par leMoniteur de SDA, afin de construire une signature d’alerte.

— Données de contexte de l’application : Cette dernière catégorie

repré-sente les données qui sont observables pendant l’exécution de la partition HIDS, c’est-à-dire entre deux cycles d’exécution de la partition surveillée. La Table 6.1 donne plusieurs exemples d’informations pouvant entrer dans la construction d’une signature, en fonction de leur catégorie. Chaque catégorie amène un niveau différent d’information. Dans le cas de données relatives à l’alerte, les don-nées sont directement liées aux résultats de la détection d’anomalies. Elles sont donc

Table 6.1 – Exemples de données pouvant entrer dans la composition d’une signa-ture d’alerte

Nom Catégorie Description

Vecteur de

don-nées anormal ^{Alerte La donnée brute ayant donné l’anomalie} Distance de

l’ano-malie au modèle ^{Alerte La distance observée entre la donnée anormale et}le modèle Distribution des

anomalies ^{Alerte La façon dont l’ensemble des anomalies sont répar-}ties (par exemple, les appels impactés, les séquences impactées, ou les zones de code impactées)

Registres

géné-raux ^{Exécution Valeur des registres généraux à chaque point d’ob-}servation (représentent notamment les paramètres d’appel de fonctions)

Adresse de retour Exécution Valeur des adresses de retour de fonction à chaque point d’observation

Contenu de la pile Exécution Valeurs contenues dans la pile à chaque point d’ob-servation

Registres

spéci-fiques ^{Exécution Valeur des registres spécifiques à chaque point d’ob-}servation (par exemple, les compteurs de perfor-mance, compteur général, registre de conditions) État des registres

généraux ^{Contexte Valeur des registres généraux à la fin de l’exécu-}tion de la partition (notamment, le registre poin-teur d’instruction courante)

État de la

confi-guration mémoire ^{Contexte Droits d’accès enregistrés dans la MMU pour la}partition surveillée État de la pile Contexte Valeurs contenues dans la pile à la fin de l’exécution

de la partition

très ciblées sur l’anomalie elle-même et devraient permettre de bien comprendre l’impact relatif à l’alerte. Les données d’exécution sont beaucoup plus générales et peuvent donc permettre de mieux comprendre l’origine de l’alerte, mais elles peuvent représenter une très grande quantité de données à enregistrer, ce qui n’est pas forcément adapté au contexte embarqué. Enfin, les données de contexte peuvent être observées ponctuellement par la partition d’HIDS sans impacter l’exécution temps-réel de l’ensemble. Cependant, l’information disponible est limitée puisque les partitions tâchent généralement de finir leur exécution avant la fin du temps qui leur est alloué. Dans ce cas, il peut être très difficile de déterminer précisément pourquoi une alerte a eu lieu, en étudiant uniquement l’état de la partition une fois son exécution terminée. Cependant, une déviation de cet état par rapport à un état normal peut amener des éléments clés pour un diagnostic, par exemple si l’état de la pile est très différent de l’état habituel, ou si une partie du code a été modifiée.

6.1. Principe 121

au diagnostic. Cependant, il est important de prendre en compte que 1) l’espace mémoire disponible à bord est limité et 2) les moments d’observation restent limités, pour réduire l’impact de l’HIDS sur le calculateur et les applications qui y sont hébergées.

Afin de sélectionner les informations parmi ces exemples, il est important de déterminer précisément l’objectif du traitement de ces données. En particulier, le but de ces travaux est de déterminer la classe d’attaque correspondant à l’alerte levée, ou de déterminer si cette alerte correspond à un cas non pris en compte lors de la modélisation du SDA (cas de défaillance ou faux positif). Il faut donc que les informations contenues dans la signature soient capables de différencier une attaque, un évènement desafety, et un faux positif. Ces différents cas peuvent être caractérisés comme suit :

— Attaque : De façon générale, une attaque devrait se caractériser par un

impact spécifique (une attaque a un but précis), qui peut se traduire au travers du flot d’exécution de l’application, de ses permissions, de sa configuration, de l’utilisation de ses registres, etc.

— Défaillance : Dans ce cas, un impact devrait être clairement observé, mais

celui-ci doit être corrélé avec des alertes des moniteurs desafety.

— Faux positif : Ce cas très rare est caractérisé par le fait qu’il n’y a aucun

impact sur l’application (anomalies très proches du comportement normal, pas de liens entre elles, état général connu).

Au regard de ces trois cas, il est donc important de traduire dans la signature les 3 caractéristiques suivantes : 1) la corrélation avec une alerte relative à lasafety, 2) l’état de l’environnement de l’application (en particulier, s’il correspond à un état connu), 3) un potentiel impact sur l’application.

Concernant la corrélation avec une alertesafety, plusieurs niveaux peuvent être envisagés. Tout d’abord, les informations enregistrées depuis les moniteurs safety

peuvent être récupérés localement via le RTOS ou l’application surveillée. Les mes-sages de maintenance peuvent également être récupérés localement au travers de la fonction BITE. Ensuite, une corrélation à un niveau plus global (par exemple, au niveau de la suite avionique) peut permettre de donner plus de contexte à l’alerte levée par l’HIDS (par exemple, si une suite de défaillances sur la suite avionique a mené à une modification du comportement de l’application surveillée, ayant dé-clenché ensuite l’alerte de l’HIDS). On prend ici l’hypothèse que cette corrélation est faite directement lors du Traitement du message d’alerte à bord.

L’état de l’environnement de l’application peut être représenté à l’aide des don-nées de contexte, mais également par certaines dondon-nées d’exécution comme les adresses de retour de fonction, qui peuvent par exemple démontrer une utilisation détournée du code de l’application. Dans ce cadre, nous proposons ici d’enregistrer les adresses de retour de fonction aux points d’observation (donc, à chaque appel API ARINC 653 effectué par la partition surveillée), afin de repérer une utilisation détournée du code de l’application.

Enfin, renseigner des informations relatives au potentiel impact sur l’application permet de redonner un premier sens fonctionnel à l’alerte levée. Plusieurs éléments peuvent être considérés ici. Dans un premier temps, la distance des anomalies au modèle et la variabilité entre les anomalies sont des caractéristiques clés pour déter-miner un faux positif. Dans le cas où les anomalies traduisent un impact précis sur le fonctionnement de l’application (attaque ou défaillance), on peut définir plusieurs types d’impacts potentiels sur le flot d’exécution de l’application, et en extraire des caractéristiques permettant de qualifier ces impacts. Ce travail nous a permis de mettre en évidence des caractéristiques telles que la ressemblance entre anoma-lies, l’aspect consécutif de l’occurrence des anomaanoma-lies, ou le fait d’avoir plusieurs anomalies dans un même cycle d’exécution.

Pour conclure, nous avons choisi de baser la définition d’une signature sur les éléments suivants :

— Corrélation avec une alerte safety (reporté au Traitement du message

d’alerte à bord, qui ne sera donc pas traité ici)

— Enregistrement des adresses de retour de fonction lors de la collecte de données (par le moniteur de SDA, pendant l’exécution de la partition surveillée) — Corrélation entre les anomalies (distance entre les anomalies et le modèle,

ressemblance entre anomalies, occurrence d’anomalies consécutives, appari-tion de multiples anomalies sur un même cycle)