Soutenance mémoire
Définitions
La sûreté de fonctionnement définit les termes de sécurité-innocuité (safety) et de sécurité-immunité (security). Mes travaux se placent dans le cadre de la sécuritéimmunité (security). Cette partie donne le vocabulaire relatif à la sûreté de fonctionnement, puis plus précisément celui relatif à la sécurité-immunité. Enfin, les principaux standards et autorités du domaine avionique sont présentés.
La sûreté de fonctionnement
[Laprie 1996] définit la sûreté de fonctionnement d’un système informatique comme étant la propriété qui permet à ses utilisateurs de placer une confiance justifiée dans le service qu’il délivre. Le service délivré par un système est son comportement tel qu’il est perçu par son (ou ses) utilisateur(s), l’utilisateur étant un autre système (humain ou physique) qui interagit avec le système considéré. La sûreté de fonctionnement, représentée en arbre sur la Figure 1.1, est décrite selon trois notions : les attributs (définition d’un comportement sûr), les entraves (circonstances indésirables correspondant aux causes ou résultats de la non sûreté de fonctionnement) et les moyens (moyens contribuant à assurer un fonctionnement sûr en dépit des entraves). Les attributs représentent les différentes propriétés selon lesquelles la sûreté de fonctionnement peut être perçue :
— Disponibilité : aptitude du système à être prêt à l’utilisation,
— Fiabilité : continuité du service,
— Sécurité-innocuité : absence de conséquences catastrophiques pour l’environnement,
— Confidentialité : absence de divulgations non autorisées de l’information,
— Intégrité : absence d’altérations inappropriées de l’information,
— Maintenabilité : aptitude aux réparations et aux évolutions.
Les entraves sont les circonstances indésirables mais non inattendues, causes ou résultats de la non sûreté de fonctionnement, car la confiance n’est plus assurée dans le système. On distingue trois types d’entraves : les défaillances, les erreurs et les fautes. Leur relation peut être illustrée de la façon suivante :
… → Défaillance → Faute → Erreur → Défaillance → Faute → …
Un défaillance (ou défaillance du système) survient lorsqu’un service délivré dévie de l’accomplissement de sa fonction. Une erreur est la partie d’un état d’un système qui est susceptible d’entraîner une défaillance. Par propagation, plusieurs erreurs peuvent être créées avant qu’une défaillance ne survienne. La cause adjugée ou supposée d’une erreur est une faute. Les sources des fautes sont très diverses et peuvent être classées selon différents points de vue :
— la phase de création (fautes de développement ou fautes opérationnelles)
— la situation par rapport aux frontières du système (internes ou externes)
— la cause phénoménologique (naturelle ou humaine)
— l’objectif (faute malicieuse ou non)
— la dimension (faute matérielle ou logicielle)
— l’intention (faute délibérée ou non)
— la capacité (faute accidentelle ou non)
— la persistance (faute permanente ou temporaire) .
Enfin, les moyens permettant d’assurer un fonctionnement sûr en dépit des entraves sont définis selon quatre catégories :
— Prévention des fautes : empêcher l’occurrence ou l’introduction d’une faute
— Tolérance aux fautes : fournir un service qui remplit la fonction du système en dépit de fautes
— Elimination des fautes : réduire le nombre et la sévérité des fautes
— Prévision des fautes : estimer la présence, la création et les conséquences des fautes .
La sécurité-immunité
Les attributs de la sûreté de fonctionnement permettent de différencier les termes de safety et de security. La safety (sécurité-innocuité) définit les propriétés selon lesquelles un système est dit « sûr » (sans défaillance catastrophique pouvant conduire à des pertes de vies humaines ou des conséquences économiques importantes). La security (sécurité-immunité) définit les propriétés selon lesquelles un système est dit « sécurisé » (protégé contre les fautes intentionnelles, dites malveillances). La security est liée aux trois attributs disponibilité, confidentialité, et intégrité, et permet de prendre en compte les menaces informatiques tels que les virus, vers, bombes logiques, etc. Dans la suite de ce manuscrit, les termes sécurité, sécurité informatique ou security feront référence à la sécurité-immunité. Le projet MAFTIA [Powell 2001] précise le concept de faute due à l’homme pour la sécurité immunité et décrit deux catégories de fautes associées : les fautes logiques malignes et les intrusions. Les fautes logiques malignes sont des fautes intentionnelles conçues pour provoquer des dégâts (bombes logiques) ou pour faciliter les futures intrusions par l’introduction de vulnérabilités. Les fautes logiques malignes peuvent être présentes dès la première utilisation du système ou durant son exploitation par l’installation d’un cheval de Troie ou par une intrusion. Les intrusions sont définies conjointement à deux causes :
— Une attaque est une faute d’interaction externe au système, dont le but est de violer un ou plusieurs des attributs de sécurité. Elle peut aussi être définie comme une tentative d’intrusion.
— Une vulnérabilité est une faute qui peut être accidentelle, intentionnelle malveillante ou non malveillante placée dans les exigences, la spécification, la conception ou la configuration du système, ou dans la manière dont il est utilisé.
— Une intrusion est déclenchée par l’exploitation d’une vulnérabilité au cours d’une attaque. C’est donc une faute malveillante, initiée depuis l’extérieur pendant l’utilisation du système.
L’écosystème avionique
Le transport aérien a une forte culture safety. En effet, les conséquences d’une défaillance en vol peuvent avoir des conséquences dramatiques sur la vie des passagers. Aujourd’hui, lorsqu’un constructeur souhaite lancer un nouveau programme d’aéronef sur le marché, celui-ci doit satisfaire les exigences d’un processus de certification. Ceci implique de se conformer à des règles de conception strictes, selon un processus de certification surveillé puis validé par une autorité nationale de l’aviation civile. En France, c’est la Direction Générale de l’Aviation Civile (DGAC) qui délivre cette autorisation. En 2002, une autorité européenne a vu le jour sous le nom d’EASA (European Union Aviation Safety Agency), afin d’éditer des certificats de navigabilité pour l’ensemble du territoire de l’union européenne. Son équivalent américain est la FAA (Federal Aviation Administration).
A partir des règles de navigabilité énoncées par les autorités de certification, plusieurs normes et recommandations ont vu le jour afin d’aider les constructeurs à respecter ces règles. Parmi les organismes responsables de la rédaction de ces normes et recommandations, on retrouve notamment : SAE , RTCA pour les Etats-Unis et EUROCAE pour l’Europe. Ils fournissent respectivement des documents nommés ARP (Aerospace Recommended Practice), DO (DOcument), et ED (Eurocae Documents). Aujourd’hui, les organismes EUROCAE et RTCA travaillent ensemble afin d’harmoniser leurs recommandations, c’est pourquoi la plupart des documents cités dans ce manuscrit feront référence conjointement à des documents ED et DO. Ces différentes recommandations (ARP, ED, DO) sont devenues des normes avioniques au fil des années. L’entreprise ARINC (Aeronautical Radio INCorporated), créée en 1929 et détenue jusqu’en 2013 par les principales compagnies aériennes et divers constructeurs aéronautiques américains, propose également les principaux standards de communications à l’intérieur des aéronefs et entre les aéronefs et le sol.
L’avionique modulaire intégrée (IMA)
Le terme « système avionique » désigne les éléments électroniques et informatiques embarqués à bord d’un aéronef. Ces éléments assurent différentes fonctionnalités parmi lesquelles on peut par exemple citer le traitement des informations provenant des capteurs, le pilotage automatique, la gestion du carburant, les communications bord/sol, ou le contrôle des moteurs. Ces équipements représentent une part importante des coûts de développement d’un aéronef, de l’ordre de 30 à 35% pour un avion commercial [PIPAME 2009].
D’une architecture fédérée à une architecture IMA
Historiquement, les systèmes avioniques étaient construits selon une architecture dite fédérée (cf Figure 1.2), c’est-à-dire qu’une fonction était hébergée sur un calculateur dédié (i.e., un matériel spécifique). Cette architecture permet une gestion simple et efficace des équipements pour répondre aux exigences de sûreté du milieu avionique. Elle facilite notamment la redondance des équipements et minimise les dépendances entre fonctions, ce qui limite d’une part les risques de propagation d’erreurs, et qui permet d’autre part d’isoler les fonctions défaillantes du reste du système [Gatti 2016]. Cependant, ce type d’architecture implique une forte dépendance entre le matériel et le logiciel, ce qui induit par exemple des systèmes de communication très dépendants des applications mais aussi du matériel, un parc de matériel très hétérogène au sein d’un même aéronef, et d’importants coûts de mise à jour, aussi bien logicielle que matérielle.
|
Table des matières
Introduction
1 Contexte et concepts fondamentaux
1.1 Définitions
1.1.1 La sûreté de fonctionnement
1.1.2 La sécurité-immunité
1.1.3 L’écosystème avionique
1.2 L’avionique modulaire intégrée (IMA)
1.2.1 D’une architecture fédérée à une architecture IMA
1.2.2 Principes fondamentaux de l’IMA
1.2.3 Acteurs impliqués
1.3 Problématiques de sécurité dans l’avionique
1.3.1 Contexte actuel
1.3.2 Contraintes spécifiques à l’embarqué critique temps-réel
1.4 Objectifs de la thèse
2 État de l’art
2.1 La sécurité dans les systèmes avioniques
2.1.1 Les mesures de sécurité-innocuité
2.1.2 Les mesures de sécurité-immunité
2.2 Les systèmes de détection d’intrusion
2.2.1 Principe général et classification
2.2.2 Les données d’entrée
2.2.3 Les techniques de détection d’anomalie
2.2.4 L’évaluation des HIDS
2.3 Contributions de cette thèse
3 Approche générale de l’HIDS avionique
3.1 Vue générale de l’approche
3.1.1 Composants de l’approche
3.1.2 Domaine de Sécurité de l’Application
3.2 Description des composants
3.2.1 Analyse de sécurité statique
3.2.2 Modélisation du SDA
3.2.3 Validation du SDA
3.2.4 Détection d’anomalies
3.2.5 Confirmation d’attaque et investigation au sol
3.3 Définition de l’outil d’injection d’attaque
3.3.1 Vue d’ensemble
3.3.2 Composants de l’outil
3.3.3 Définition des opérateurs d’attaque
3.4 Conclusion
4 Implémentation de l’approche pour l’évaluation de l’efficacité de détection
4.1 Implémentation de l’approche
4.1.1 Environnement d’étude
4.1.2 Outil d’analyse de l’utilisation des ressources
4.1.3 Moniteur de SDA
4.1.4 Prétraitement des données
4.1.5 Modélisation du SDA
4.1.6 Injection d’attaque
4.1.7 Vérification du SDA
4.2 Implémentation de l’outil d’injection
4.2.1 Ajout de code
4.2.2 Contrôle de l’activation de la charge malveillante
4.2.3 Opérateurs d’attaque implémentés
4.2.4 Gestion de la campagne d’injection
4.3 Expérimentations
4.3.1 Processus d’évaluation de l’HIDS
4.3.2 Expérimentation 1 : pertinence de l’outil
4.3.3 Expérimentation 2 : efficacité de détection de l’HIDS
4.4 Conclusion
Conclusion
