Domaine de Sécurité de l’Application

Le concept de Domaine de Sécurité de l’Application (SDA) s’inspire du Do-maine d’Usage défini pour un calculateur. Ce domaine d’usage définit un ensemble de règles qui, si elles sont respectées, garantissent le bon fonctionnement du calcula-teur. Ici, nous avons défini le SDA comme un ensemble de règles qui caractérisent le fonctionnement "normal" d’une application, c’est à dire le fonctionnement d’une ap-plication non corrompue. Par exemple, une règle peut correspondre à "l’application ne doit pas faire plus de 100 appels API pendant un cycle d’exécution". Ces règles se basent sur l’utilisation des ressources du calculateur par l’application. Dans le contexte avionique, une application et son écosystème ne sont pas supposés évoluer dans le temps. Par conséquent, l’application devrait utiliser les ressources qui lui sont allouées de la même façon tout au long du cycle de vie de l’aéronef. En cas de mise à jour de l’application (qui est très rare pour la plupart des applications), le SDA évolue également en fonction de cette nouvelle version d’application.

Le SDA doit être adapté à la cible sur laquelle l’HIDS va s’exécuter, pour prendre en compte sa consommation de ressources (mémoire, CPU, bande passante), les éventuelles sources d’information déjà existantes (alertes safety, moyens d’instru-mentation, informations de maintenance), et ses potentielles évolutions (le calcula-teur est-il en développement ou finalisé, peut-on effectuer des modifications). Pour cela, il est nécessaire de sélectionner un ensemble de paramètres pertinents pour définir le cadre du SDA. Dans l’idéal, il faudrait sélectionner le plus petit ensemble de données observables pour lequel la détection est efficace et adaptée à tout type d’application, pour un système donné. Plusieurs approches permettent d’explorer la sélection de ces paramètres, parmi lesquelles :

1. Sélectionner uniquement les informations déjà disponibles, par exemple pour être applicable à des aéronefs déjà en circulation,

2. Effectuer une analyse de risques et une analyse des effets des attaques sur un système, afin de sélectionner les informations les plus critiques,

3. Sélectionner les paramètres les plus communément surveillés par des HIDS dans la littérature (du domaine avionique ou d’autres domaines),

4. Sélectionner les informations les plus pertinentes après avoir expérimenté dif-férents paramètres face à des attaques.

Dans notre cas, les approches 2 et 3 ont été utilisées pour orienter le choix des paramètres. Plus particulièrement, une analyse générale des risques sur une

3.1. Vue générale de l’approche 47

Table 3.1 – Exemples de niveaux d’observation possibles du comportement d’une application avionique

Appels API Lever un évènement à chaque fois qu’un appel API ARINC 653 est effectué par l’application Code exécuté Lever un évènement à chaque instruction

exécu-tée par l’application

Communications Lever un évènement à chaque fois qu’un message est envoyé ou reçu par l’application

Compteurs CPU Lire les compteurs de performance du processeur Mémoire Lever un évènement à chaque fois que

l’applica-tion fait un accès mémoire

Erreurs OS Lever un évènement à chaque fois qu’une erreur est levée par l’OS

application avionique, et leurs effets sur le système, nous a permis de mettre en évidence six niveaux d’observations qui pourraient avoir un intérêt dans le domaine avionique, listés dans la Table 3.1.

Ces niveaux d’observation ne présentent pas les mêmes caractéristiques. Par exemple, il est probable que l’observation desCompteurs CPU ou des Erreurs OS

soit plus facile à implémenter, puisque ces éléments sont déjà utilisés pour d’autres activités indépendantes de la sécurité (par exemple, pour évaluer les performances d’une application, ou pour la surveiller d’un point de vue safety). Au contraire, l’observation du Code exécuté semble beaucoup plus complexe à mettre en place, même s’il permettrait une observation très fine du comportement de l’application, qui serait très efficace dans un environnement statique. La surveillance des Commu-nications permet de se concentrer sur l’utilisation des interfaces, qui représentent un accès privilégié pour un attaquant. L’observation des Appels API permet d’ob-tenir des informations assez variées sur l’exécution de l’application ou l’utilisation de ses interfaces, et a pour avantage de s’appuyer sur le standard ARINC 653. Par conséquent, le développement d’une solution sur un calculateur donné pourrait être plus facilement réutilisé sur un autre type de calculateur. Enfin, l’observation de la Mémoire, si elle semble assez complexe à mettre en place, permettrait toutefois de surveiller avec précision l’exécution d’une application, et serait très efficace pour repérer des attaques visant l’intégrité de l’application (et notamment des données qu’elle manipule).

Une fois le ou les niveau(x) d’observation choisi(s), il existe plusieurs façons d’ob-server les informations correspondantes. La Table 3.2 en propose quelques exemples, également basés sur notre analyse générale des risques sur une application avionique et de leurs effets sur le système.

Selon la quantité d’information observable, on peut envisager à minima de comp-ter simplement le Nombre d’évènements, quel que soit le niveau d’observation. Si l’on est capable de différencier des évènements selon un niveau d’observation ou

Table 3.2 – Exemples de caractérisations possibles d’informations observées pour la modélisation du comportement d’une application avionique

Diversité Nombre d’évènements différents ayant été levés Nombre Nombre d’évènements ayant été levés

Séquence Séquences des évènements ayant été levés Paramètres Paramètres de l’évènement

Charge utile Valeur manipulée lors de l’évènement Horodatage Horodatage de l’évènement

Type Type de l’évènement, selon une typologie prédéfinie

selon un Type, il est envisageable de relever la Diversité d’évènements levés sur une période de temps donnée. L’observation de Séquences d’évènements nécessi-tera généralement un espace mémoire de stockage plus important mais donne des informations supplémentaires. L’observation desParamètresd’un évènement est in-téressant dans un contexte statique si l’on est capable de dénombrer les différents paramètres possibles pour un évènement. La Charge utile représente quant à elle des valeurs de paramètres avec plus de variabilité, comme des chaînes de caractères. Enfin, quelle que soit la connaissance sur un évènement, il est néanmoins possible de conserver des méta-données relatives à cet évènement telles qu’un Horodatage.

Ces tableaux n’ont pas vocation à proposer une classification exhaustive des informations pouvant entrer dans la définition du SDA, ni d’être efficaces de la même façon. Ils résultent d’une analyse générale et probablement incomplète, et cherchent avant tout à proposer des pistes quant à la sélection de paramètres à observer pour définir un HIDS avionique. Dans cette optique, chaque information surveillée devrait être composée d’un niveau d’observation et d’une caractéristique à observer. Par exemple, un SDA pourrait être composé de règles relatives au nombre d’appels API effectués par une application pendant un cycle d’exécution, au temps pour effectuer une séquence précise de communications, à la valeur des données lues ou écrites dans un segment mémoire spécifique, ou à la diversité des types d’instructions exécutées.

Dans nos travaux, nous avons décidé de nous concentrer sur la modélisation des appels API ARINC 653 effectués par l’application pour construire le SDA. En effet, de nombreux travaux ont démontré l’intérêt de l’observation des appels système pour effectuer de la détection d’intrusion (voir Chapitre 2), et cette ob-servation peut facilement être réalisée au niveau du système d’exploitation. De plus, [Yoon 2013] a montré l’intérêt d’observer le temps d’exécution dans des sys-tèmes temps-réel. Ces résultats sont notamment dûs au comportement périodique des applications observées. Dans notre contexte, cela peut se traduire par l’observa-tion directe de l’horodatage, par le système d’exploital’observa-tion, des appels API ARINC 653 effectués par l’application surveillée. Les travaux présentés dans ce manuscrit se sont donc concentrés sur l’observation destypeset de l’horodatagedesappels