FR2944117A1 - Procedes et dispositifs de gestion d'evenements lies a la securite des systemes informatiques d'aeronefs - Google Patents

Abstract

L'invention a notamment pour objet des procédés et des dispositifs de gestion d'événements liés à la sécurité des systèmes informatiques d'aéronefs. Après avoir reçu au moins une information relative à la détection (110) d'au moins un événement, ce dernier est caractérisé (125) selon au moins une règle d'une pluralité de règles prédéterminées, pouvant être mise à jour, pour permettre l'établissement d'un rapport de sécurité selon ladite caractérisation dudit au moins un événement détecté. De façon avantageuse, ledit au moins un événement est détecté selon un ensemble d'événements prédéterminés, ledit ensemble d'événements prédéterminés étant mis à jour selon un événement préalablement détecté.

Description

La présente invention concerne la sécurité des aéronefs et plus particulièrement des procédés et dispositifs de gestion d'événements liés à la sécurité des systèmes informatiques d'aéronefs. De façon générale, la majorité des aéronefs intègre, aujourd'hui, des procédures et des mécanismes de gestion de leur maintenance. Plus précisément, les mécanismes de détection des événements pouvant jouer un rôle dans les opérations de maintenance, les procédures et les mécanismes permettant de corréler ces événements pour identifier ou anticiper des pannes éventuelles ainsi que les procédures permettant de réparer ou d'effectuer les opérations de maintenance préventives sont définis durant la phase de conception des aéronefs. Cependant, jusqu'à un passé très récent, la conception des aéronefs n'intégrait pas la définition des mécanismes de détection des événements pouvant avoir un rôle vis-à-vis de la sécurité des systèmes informatiques et, par conséquent, n'intégrait pas la définition des procédures et des mécanismes permettant de les traiter. Bien que cet aspect doive désormais être pris en considération, il pose de nombreux problèmes liés à la nature des systèmes informatiques. En particulier, cette nouvelle contrainte de conception fait apparaître trois types de difficultés : - la difficulté de spécifier les événements devant être détectés ; - la difficulté de définir des règles de corrélation à mettre en oeuvre sur les événements détectés ; et, - la difficulté de définir un processus cohérent de traitement des résultats issus de l'application de ces règles de corrélation afin de maintenir un aéronef dans un état opérationnel. Ces difficultés sont essentiellement liées au fait que les événements de sécurité qui doivent être traités ne cessent d'évoluer, indépendamment de leur définition fonctionnelle, car la nature des atteintes potentielles à la sécurité des systèmes informatiques des aéronefs ne cesse d'évoluer. Les difficultés liées à la spécification des événements devant être détectés et à la définition des règles de corrélation à mettre en oeuvre sur les événements détectés ne peuvent pas être définies pour toute la durée de vie d'un aéronef. En effet, elles sont directement liées aux types d'attaques informatiques pouvant être effectuées. Ces spécifications et ces définitions ne peuvent donc être données dans l'absolu. Par ailleurs, la difficulté de définir un processus cohérent de traitement des résultats issus de l'application de ces règles de corrélation afin de maintenir un aéronef dans un état opérationnel est, quant à elle, liée à la complétude de la définition du processus de traitement des sorties des règles de corrélation. En effet, ce processus doit être capable, à tout instant, de traiter le fait que les événements détectés et les règles de corrélation définies ne sont pas complets tout en assurant une durée de remise en condition opérationnelle acceptable. L'invention permet de résoudre au moins un des problèmes exposés précédemment. L'invention a ainsi pour objet un procédé pour ordinateur de gestion 20 d'au moins un événement lié à la sécurité d'au moins un système informatique d'un aéronef, ce procédé comprenant les étapes suivantes, - réception d'au moins une information relative à la détection dudit au moins un événement ; - caractérisation dudit au moins un événement détecté selon au 25 moins une règle d'une pluralité de règles prédéterminées ; et, - établissement d'un rapport de sécurité selon ladite caractérisation dudit au moins un événement détecté. Le procédé selon l'invention contribue ainsi à l'évaluation du niveau de menace d'un aéronef en permettant l'établissement d'un rapport de sécurité 30 des systèmes informatiques de l'aéronef selon des événements détectés et des règles prédéterminés. Le procédé selon l'invention permet en outre, en particulier, d'améliorer la réactivité des membres d'équipage et/ou des équipes de maintenance face aux risques auxquels sont exposés les systèmes informatiques en identifiant au plus tôt les événements douteux, c'est-à-dire les événements caractérisant des risques particuliers. De façon avantageuse, le procédé comprend en outre une étape de mise à jour de ladite pluralité de règles selon un événement préalablement détecté. Le procédé selon l'invention est ainsi évolutif et permet notamment de limiter la détection d'événements ne constituant pas de risques réels pour l'aéronef, d'améliorer la base de connaissances utilisée en consolidant la base de règles et d'affiner l'analyse automatique en vol par une analyse au sol. Selon un mode de réalisation particulier, le procédé comprend en outre une étape de détection dudit au moins un événement, ledit au moins un événement étant détecté selon un ensemble d'événements prédéterminés, ledit ensemble d'événements prédéterminés étant mis à jour selon un événement préalablement détecté. Le procédé selon l'invention est ainsi adapté à évoluer pour détecter de nouveaux risques selon des événements détectés. Le procédé comprend en outre, de préférence, une étape d'analyse dudit rapport pour déterminer si les événements détectés sont associés à un fonctionnement nominal du système ou non.

Selon un mode de réalisation particulier, le procédé comprend en outre une étape de détermination d'au moins une nouvelle règle en réponse à ladite analyse dudit rapport, ladite pluralité de règles prédéterminées étant mise à jour selon ladite au moins une nouvelle règle déterminée. Le procédé selon l'invention est ainsi adapté à évoluer pour détecter de nouveaux risques et/ou éviter la détection erronée de risques. Le procédé comprend en outre, avantageusement, une étape de vérification et de validation d'au moins une information dudit rapport pour améliorer l'efficacité du procédé et la pertinence du rapport de sécurité. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape d'insertion dans ledit rapport d'au moins une indication relative au contexte associé audit un moins un événement détecté pour permettre, le cas échéant, d'affiner la détection de risques selon le contexte. Le procédé comprend en outre, de préférence, une étape de mise à jour de la définition de l'aéronef afin que celle-ci soit conforme à l'aéronef après une modification d'un élément de ce dernier ayant pour objet la mise en oeuvre d'une solution de sécurité permettant de supprimer des menaces détectées. L'invention a également pour objet un dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé décrit précédemment ainsi qu'un programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé décrit précédemment lorsque ledit programme est exécuté sur un ordinateur. D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, au regard des dessins annexés dans lesquels : - la figure 1 représente schématiquement un exemple d'algorithme de détection et de corrélation d'événements issus de systèmes informatiques d'un aéronef ; - la figure 2 illustre un exemple d'algorithme de maintenance en condition opérationnelle des systèmes informatiques d'un aéronef suite à la détection d'événements issus de ces systèmes informatiques ainsi que d'amélioration de la conception des aéronefs ; - la figure 3 représente schématiquement un exemple d'algorithme mis en oeuvre dans le moteur de corrélation illustré sur la figure 1 pour appliquer des règles sur des événements détectés ; - la figure 4 illustre un exemple de traitement d'événements détectés aux fins d'obtenir un rapport et un reliquat d'informations non traitées à analyser et à valider ; - la figure 5 illustre un exemple de dispositif adapté à mettre en oeuvre l'invention ou une partie de l'invention.

Selon l'invention, la gestion d'événements liés à la sécurité des systèmes informatiques d'aéronefs comprend, d'une part, un mécanisme de détection et de corrélation des événements détectés et, d'autre part, un mécanisme de maintenance en condition opérationnelle des systèmes informatiques d'un aéronef suite à la détection d'événements issus de ces systèmes informatiques ainsi que d'amélioration de la conception des aéronefs visant, en particulier, l'adaptation des paramètres utilisés par le mécanisme de détection et de corrélation. La figure 1 représente schématiquement un exemple d'algorithme 100 de détection et de corrélation d'événements issus de systèmes informatiques d'un aéronef. Selon un premier mode de réalisation, l'identification d'événements peut être réalisée au niveau de chacun des systèmes informatiques 105-1 à 105-n. Une information représentative de ces événements identifiés est alors transmise à un module 110 de détection des événements qui compare les événements identifiés avec une liste d'événements prédéterminés, mémorisée, par exemple, dans la base de données 115. Les événements identifiés appartenant à la liste des événements prédéterminés sont alors mémorisés, par exemple, dans la base de données 120. Ces événements sont appelés les événements détectés. Alternativement, selon un autre mode de réalisation, chacun des systèmes informatiques 105-1 à 105-n transmet des informations relatives à son état et à son activité au module 110 de détection des événements. Le module 110 comprend ici un moteur d'analyse pour identifier des événements à partir des informations reçues. Les événements identifiés sont alors comparés à une liste d'événements prédéterminés, mémorisée, par exemple, dans la base de données 115. Comme précédemment, les événements identifiés appartenant à la liste des événements prédéterminés sont alors mémorisés, par exemple, dans la base de données 120. A nouveau, ces événements sont appelés les événements détectés. Un événement à détecter est, par exemple, la connexion ou la déconnexion d'un système utilisateur à un système informatique de l'aéronef.

Les événements détectés sont utilisés par le moteur de corrélation 125 mettant en oeuvre des règles mémorisées, par exemple, dans la base de données 130. De façon avantageuse, le moteur de corrélation 125 se fonde également sur le contexte de l'aéronef comprenant, par exemple, la phase de vol. Ces données de contexte peuvent être obtenues directement auprès des systèmes concernés ou via une base de données 135. Il convient de noter que la liste des événements prédéterminés, c'est- à-dire la liste des événements à détecter, ainsi que les règles utilisées par le moteur de corrélation sont liées à un standard aéronef définissant un ensemble cohérent d'éléments matériels et logiciels définis pour une version donnée. A titre d'illustration, un standard aéronef peut être défini par une liste d'éléments matériels notés HW et d'éléments logiciels notés SWi. Chaque élément est référencé par un numéro de pièce, appelé PNR (sigle de Part NumbeR en terminologie anglo-saxonne). A chaque élément est associée une version. Par exemple, HW_V; désigne la version associée à l'élément matériel HW; et SW_Vi désigne la version de l'élément logiciel SWi. Un élément logiciel SWi peut être associé à un élément matériel HW;.

Le résultat de corrélation des événements détectés est ici mémorisé sous la forme d'un rapport dans la base de données 140. Ce rapport est, de préférence, constitué de deux parties : un rapport comprenant des informations traitées et un reliquat d'informations non traitées. Ces deux parties peuvent se présenter sous la forme de deux fichiers distincts. Un niveau de criticité, déterminé par le moteur de corrélation, est avantageusement associé à chaque événement détecté ou à chaque information résultant du traitement d'au moins un événement détecté. Selon un mode de réalisation particulier, les données issues du moteur de corrélation sont réparties entre le rapport et le reliquat d'informations non traitées selon les critères suivants, - les événements détectés pour lesquels aucune règle n'a permis d'identifier une cause particulière sont ajoutés au reliquat d'informations non traitées. Ces événements doivent faire l'objet d'une analyse fine dont l'objectif est de les associer à de nouvelles règles afin que la base de règles consolidée permette de ne plus voir apparaître de tels événements dans le reliquat d'informations non traitées (un objectif étant de réduire le fichier de reliquat d'informations non traitées à une taille proche de zéro) ; - les événements qui correspondent à des événements normaux, sans impact sur la sécurité des systèmes informatiques de l'aéronef, et dont le niveau de criticité est inférieur ou égal à un seuil prédéterminé, par exemple 50, sont mémorisés dans le rapport. Ces événements ne demandent aucune action particulière de la part des équipes de maintenance. Un tel événement correspond, par exemple, au chargement d'un fichier (fonction Joad) dans un système informatique 105-i. Le niveau de criticité associé à un tel événement est, à titre d'illustration, 10 ; - les événements identifiés par une règle, notamment une règle de type contextuel, et dont le niveau de criticité est supérieur au seuil prédéterminé, par exemple 50, sont ajoutés au rapport. Ces événements doivent, de préférence, être vérifiés et validés. A titre d'illustration, la mise en oeuvre d'un système de détection d'intrusion réalisée hors du contexte prévu peut entraîner un événement dont le niveau de criticité est 60. Ces événements peuvent nécessiter une action de la part de l'équipe de maintenance. De façon avantageuse, deux phases de vérification sont prévues : une première phase, juste après le vol durant lequel l'événement a été détecté, selon laquelle la vérification est effectuée selon les informations contenues dans le journal de bord, appelé logbook en terminologie anglo-saxonne, et les informations communiquées par le pilote ; et, une seconde phase, effectuée après la phase de maintenance suivant la détection de cet événement, selon laquelle la vérification est effectuée selon les informations contenues dans le journal de bord et les informations fournies par l'équipe de maintenance ; Il est observé ici que les événements vérifiés doivent faire l'objet d'un commentaire de la part du vérificateur, c'est-à-dire, a priori, l'équipe de maintenance. Ce dernier doit indiquer dans le rapport pourquoi l'événement est normal ou préciser qu'une analyse détaillée est nécessaire. Dans ce dernier cas, l'information sera remontée avec le reliquat d'informations non traitées, avec une priorité haute. - les événements identifiés par le moteur de corrélation à l'aide d'une règle non contextuelle et pour lesquels le niveau de criticité est supérieur au seuil prédéterminé, par exemple 50, sont mémorisés dans le rapport. A titre d'illustration, un tel événement peut être la demande d'ouverture de session, depuis un système particulier, qui a été formulée 35 000 fois durant les deux dernières heures. Le niveau de criticité d'un tel événement est, par exemple, 70. Une analyse fine est ici nécessaire pour expliquer le problème. La figure 2 illustre un exemple d'algorithme 200 de maintenance en condition opérationnelle des systèmes informatiques d'un aéronef suite à la détection d'événements issus de ces systèmes informatiques ainsi que d'amélioration de la conception des aéronefs visant, en particulier, l'adaptation des paramètres utilisés par les mécanismes de détection et de corrélation. L'algorithme 200 a pour objet de traiter les informations issues du moteur de corrélation 125, c'est-à-dire les informations contenues dans le rapport et dans le reliquat d'informations non traitées, mémorisées ici dans la base de données 140. Ces informations sont consolidées au regard des informations du journal de bord, pouvant être mémorisées, par exemple, dans la base de données 205, et les données de documentation de l'aéronef, mémorisés ici dans la base de données 210. Cette consolidation peut être réalisée automatiquement dans le module 215 ou être effectuée par un opérateur. Les informations consolidées sont alors analysées pour déterminer si les événements détectés sont associés à un fonctionnement nominal du système ou non. A nouveau, cette analyse peut être réalisée automatiquement dans le module 220 ou être effectuée par un opérateur. Si les événements détectés sont associés à un fonctionnement nominal du système, cette information est ajoutée à la définition du standard de l'aéronef par le module 225. En d'autres termes, une ou plusieurs nouvelles règles sont créées et ajoutées à la base de données 130 de telle sorte que lorsqu'un événement similaire sera détecté, celui-ci sera considéré comme normal par le moteur de corrélation 125.

Si, au contraire, les événements détectés ne sont pas associés à un fonctionnement nominal du système, c'est-à-dire si les événements détectés sont associés à une défaillance ou à une nouvelle attaque des systèmes informatiques, des actions sont prises, de préférence en deux phases : - dans une première étape, une définition d'une solution rapidement diffusable vers l'aéronef, permettant de contourner la nouvelle attaque, est déterminée dans le module 230. Cette définition consiste par exemple à modifier la documentation de l'aéronef, mémorisée ici dans la base de donnée 210, afin d'indiquer une parade au pilote et/ou aux équipes de maintenance ; et, - dans une seconde étape, une solution définitive est identifiée dans le module 235 pour contourner l'attaque. Cette solution consiste par exemple à modifier la liste des événements à détecter, mémorisée ici dans la base de données 115, les règles utilisées par le moteur de corrélation 125, mémorisées ici dans la base de données 130, et/ou la documentation de l'aéronef, mémorisée ici dans la base de donnée 210. La définition de l'aéronef, c'est-à-dire le standard aéronef, peut également être modifiée suite, par exemple, à l'implémentation de solutions de sécurité permettant de supprimer des menaces détectées. L'analyse réalisée dans le module 220 et la définition de solution dans les modules 225, 230 et 235 sont des activités de conception. Elles ne font pas partie de la définition du standard aéronef. Il convient de remarquer ici que l'analyse réalisée dans le module 220 peut comporter des actions annexes de coordination avec les compagnies aériennes pour confirmer ou infirmer des opérations permettant d'affiner l'analyse.

Chaque ligne du rapport généré par le moteur de corrélation est, de préférence, relative à une information résultant du traitement d'un ou de plusieurs événements traités. Un niveau de criticité dont la valeur est, par exemple, comprise entre 1 et 100, est associé à chaque ligne générée dans le rapport. Le niveau 1 correspond ici à des informations sans danger tandis que le niveau 100 indique un niveau d'alerte maximum. De façon générale, des niveaux supérieurs à 50 indiquent un danger potentiel. Au delà de 80, les événements correspondent à des événements, notamment des événements rapprochés dans le temps, pour lesquels l'aéronef n'est pas protégé. Le niveau de criticité est déterminé par la ou les règles à partir desquelles sont déterminées les informations du rapport. Comme indiqué précédemment, ce niveau de criticité est notamment utilisé pour déterminer les événements à vérifier et à valider. A titre d'illustration, les événements à vérifier et à valider peuvent être ceux associés à un niveau de criticité supérieur à 50. La détermination du niveau de criticité par les règles est ici prédéterminée. Cependant, une table dynamique de criticité peut être gérée au sol en tenant compte du retour d'expérience. Ainsi, un événement jugé critique peut voir son niveau de criticité diminuer. Les valeurs d'une telle table peuvent être transmises à un aéronef lors des mises à jour de celui-ci (changements de standard). De façon avantageuse, plusieurs types de règles sont utilisées pour structurer, organiser et clarifier la base de données des règles et afin d'ordonner le traitement des événements détectés. Chaque type de règle apporte des éléments pour obtenir un rapport consolidé et limiter le reliquat d'informations non traitées. Les types de règles utilisées sont, par exemple, les suivants, - les règles de définition de contexte : ce sont les règles qui permettent de définir les contextes utilisés par les règles contextuelles. Ces règles permettent en particulier d'identifier les phases de vol ainsi que des contextes spécifiques. A titre d'illustration, ce type de règle peut comprendre la règle d'identification du passage d'une interface de communication sécurisée en mode unidirectionnel. Ce type de règle permet d'initialiser le rapport avec les changements de contexte. Bien que les lignes correspondantes dans le rapport ne soient pas directement liées à des anomalies, elles sont néanmoins présentes (et conservées) pour faciliter l'interprétation du reliquat d'informations non traitées ; - les règles de type action : elles sont ici classées selon les trois types suivants, type 1 : règles concernant plusieurs événements détectés qui peuvent être regroupées en une seule ligne dans le rapport. A titre d'illustration, lorsque plusieurs événements détectés sont liés à la désinstallation d'une application, une seule ligne peut être générée dans le rapport, regroupant toutes les informations utiles, par exemple la ligne suivante, date/heure/n° de vol/phase de vol : désinstallation de l'application X (criticité 40) type 2 : règles concernant un seul événement mais dont l'importance nécessite d'être soulignée par l'utilisation d'une ligne dans le rapport. A titre d'illustration, le blocage d'une adresse peut être indiqué de la façon suivante, date/heure/n° de vol/phase de vol : flux issu de l'adresse 123.056.189.012 bloqué par règle 65000 (criticité 60) type 3 : règles concernant un événement lié à un seuil de performance. A titre d'illustration, si un événement est détecté parce que le taux d'occupation d'une partition excède 95%, la ligne suivante peut être générée dans le rapport, date/heure/n° de vol/phase de vol : partition /var sur X atteint 96% d'occupation (criticité 55) - les règles de type occurrence : elles concernent un même événement détecté à plusieurs reprises sur une période de temps limitée. L'événement en cause peut également correspondre aux résultats obtenus par l'application de règles de type action (en particulier lorsque plusieurs groupes d'événements détectés sont représentés sous forme de plusieurs lignes dans le rapport). Il convient de remarquer ici que plusieurs règles de type occurrence peuvent concerner un même événement, selon différent niveaux de criticité, en fonction du nombre d'occurrences. A titre d'illustration, si une règle a pour objet de contrôler le nombre de demandes d'ouverture de session formulées par minute, une règle d'occurrence peut générer la ligne suivante dans le rapport, date/heure/n° de vol/phase de vol : demande d'ouverture de session depuis adresse X formulée 35 000 fois durant les 2 dernières heures (criticité 70) - les règles de type contextuel : elles concernent un ou plusieurs événements correspondant à des actions ne pouvant survenir que dans un certain contexte. A titre d'illustration, la règle contextuelle selon laquelle la vérification par un système de détection d'intrusion ne doit pas s'effectuer avant la phase de vol n°6 peut générer la ligne suivante dans le rapport, date/heure/n° de vol/phase de vol : vérification par système de détection d'intrusion réalisée hors contexte, phase de vol n°5 (criticité 60) - les règles de type suppression : elles ont pour objet de supprimer des événements détectés correspondant à des messages connus, sans conséquence. A titre d'illustration, un événement détecté lié à l'ajustement de l'heure tel que Time jump detected û_ -5.438359141 seconds n'est pas pris en compte. Cependant, ce type de règle génère une ligne dans le rapport afin d'indiquer le nombre d'événements supprimés. Une telle ligne générée dans le rapport est, par exemple, la suivante, Pour information, 250 lignes d'information, sans impact, supprimées - les règles sur les règles : elles visent à préciser l'ordre d'exécution de certains types de règles. A titre d'illustration, une opération anodine telle que l'ouverture de session peut être problématique si elle est exécutée un nombre anormal de fois. Ainsi, les règles d'occurrences doivent être exécutées avant les règles suppression. De même, la transcription d'une règle action peut être un élément déclencheur d'une règle contextuelle. A titre d'illustration, une règle de type action peut remplacer plusieurs éléments détectés par une seule indication de chargement d'une application logicielle, ce qui peut déclencher une règle de type contextuel. Par conséquent, les règles de type contextuel doivent être exécutées après les règles de type action. Ainsi, la génération du rapport et du reliquat d'informations non traitées est réalisée dans le moteur de corrélation 125 par l'application des règles de la base de données 130. La figure 3 représente schématiquement un exemple d'algorithme mis en oeuvre dans le moteur de corrélation pour appliquer les règles de la base de données 130 sur les événements détectés mémorisés ici dans la base de données 120 afin d'obtenir un rapport mémorisé ici dans la base de données 140. Dans un premier temps, les règles de définition de contexte sont mises en oeuvre (étape 300). Pour chaque règle de définition de contexte identifiée, les dates et heures de début et de fin de contexte sont enregistrées pour être utilisées par les règles contextuelles. Le rapport comprend, de préférence, les informations suivantes, - un en-tête avec le nom de la compagnie aérienne exploitant l'aéronef, le numéro de vol, la date et l'heure du début de la première phase de vol ; - pour chaque phase de vol, l'identification de la phase de vol ainsi que l'heure de début et de fin de la phase de vol ; - pour chaque changement de contexte, l'identification des modifications de contexte ainsi que les heures correspondantes ; et, - une marque de fin de vol avec le nom de la compagnie aérienne, le numéro de vol, la date et l'heure de fin de la dernière phase de vol. Les règles de type action sont ensuite prises en compte (étape 305). Pour chaque règle action identifiée, l'action globale correspondant à un ensemble d'événements détectés est insérée, avec la date et l'heure, dans la phase de vol correspondante, dans le rapport. Il convient de remarquer ici que les événements détectés dans la base de données des événements détectés, correspondant aux règles de type action identifiées, ne sont pas supprimées immédiatement pour permettre l'exécution correcte des règles de type occurrence et de type contextuel.

Ensuite, les règles de type occurrence sont appliquées (étape 310). Pour chaque règle de type occurrence identifiée, l'événement associé est ajouté dans le rapport avec la date et l'heure, dans la phase de vol correspondante. Les règles de type contextuel sont alors prises en compte (étape 315). Pour chaque règle de type contextuel identifiée, l'événement associé est ajouté dans le rapport avec la date et l'heure, dans la phase de vol correspondante.

Enfin, les règles de type suppression sont appliquées (étape 320). Une ligne est ajoutée en fin de rapport pour préciser le nombre d'événements détectés, sans impact, qui n'on pas été mentionnés dans le rapport. La figure 4 illustre un exemple de traitement d'événements détectés aux fins d'obtenir un rapport et un reliquat d'informations non traités à analyser et à valider. Les événements détectés sont ici mémorisés dans la base de données 120 sous forme d'un fichier. Celui-ci est traité à partir des règles mémorisées dans la base de données 130 et des informations de contexte (non représentées).

Une première étape a pour objet l'application (400) des règles de définition de contexte au fichier représentant les événements détectés. Cette étape permet d'insérer les mentions décrites précédemment dans le fichier contenant les événements détectés pour obtenir le fichier 402, appelé fichier reliquat. Cette étape permet également d'initialiser le rapport, représenté ici sous la forme du fichier 404. Les règles de type action sont ensuite appliquées (406) au fichier résultant de l'étape précédente. Les événements détectés dans le fichier reliquat, correspondant à une action globale, sont marqués dans le fichier reliquat pour être supprimés ultérieurement. Ce fichier prend alors la référence 408. Les actions globales identifiées sont simultanément ajoutées au rapport dont le fichier correspondant prend la référence 410. De façon avantageuse, les événements marqués dans le fichier reliquat sont remplacés par des références aux actions globales correspondantes (412). Le fichier reliquat prend alors la référence 414.

Les règles de type occurrence sont ensuite appliquées (416). Les événements détectés dans le fichier 414, satisfaisant aux règles de type occurrence, sont marqués et une indication correspondante est générée dans le fichier représentant le rapport. Le fichier reliquat prend alors la référence 418 tandis que le fichier représentant le rapport prend la référence 420.

De façon similaire, les règles de type contextuel sont appliquées (422). Les événements détectés dans le fichier 418, satisfaisant aux règles de type contextuel, sont marqués et une indication correspondante est générée dans le fichier représentant le rapport. Le fichier reliquat prend alors la référence 424 tandis que le fichier représentant le rapport prend la référence 426. Les événements détectés marqués comme satisfaisant aux règles de type action, occurrence et contextuel sont alors supprimés du fichier reliquat (428) qui prend la référence 430. Les règles de type suppression sont ensuite appliquées (432). Les événements détectés, sans impact sur la sécurité des systèmes informatiques de l'aéronef, sont alors identifiés et marqués dans le fichier reliquat 430 qui prend la référence 434. Une indication correspondante est ajoutée dans le fichier représentant le rapport. Ce dernier prend la référence 436. Ces événements sont alors supprimés du fichier reliquat qui prend la référence 440. Les fichiers 440 et 436 sont mémorisés dans la base de données 140. Le fichier 440 correspond au reliquat d'informations non traitées tandis que le fichier 436 correspond au rapport. La mise en oeuvre des mécanismes selon l'invention, tels qu'illustrés sur les figures 1 et 2, peut être réalisée partiellement dans un aéronef et partiellement au sol. Selon un premier mode de réalisation, les modules 110, 125 et 215 ainsi que l'ensemble des bases de données 115, 120, 130, 135, 140, 205 et 210 sont implémentés dans des systèmes informatiques de l'aéronef tandis que les modules 220, 225, 230 et 235 sont implémentés dans des systèmes informatiques au sol. Les données issues du module 215 sont temporairement mémorisées dans une base de données de l'aéronef et transférées au sol.

Cependant, selon une telle implémentation, une analyse systématique au sol est nécessaire après chaque vol. Celle-ci ne peut être totalement différée. Par ailleurs, la mise en oeuvre de nouvelles versions du moteur de corrélation et de nouvelles règles de corrélation doit suivre le processus de mise à jour de configuration de l'aéronef. Néanmoins, le transfert sécurisé des données entre l'aéronef et le sol est facile à mettre en oeuvre dès que l'aéronef est au sol.

Alternativement, selon un seconde mode de réalisation, seuls le module 110 ainsi que l'ensemble des bases de données 115 et 120 sont implémentés dans des systèmes informatiques de l'aéronef, les modules 125, 215, 220, 225, 230 et 235 ainsi que les bases de données 130, 135, 140, 205 et 210 étant implémentés dans des systèmes informatiques au sol. La base de données 120 est transférée de l'aéronef au sol. Selon ce mode de réalisation, il n'est pas nécessaire d'analyser systématiquement les données au sol après chaque vol. L'analyse complémentaire au sol peut être différée. De même, la mise en oeuvre de nouvelles versions du moteur de corrélation et de nouvelles règles de corrélation ne requiert pas de suivre le processus de mise à jour de configuration de l'aéronef. Cependant, une telle implémentation nécessite des moyens de transmission sécurisée des événements détectés dans l'aéronef vers le sol, durant les phases de vol de l'aéronef.

Il est observé ici que, quel que soit le mode de réalisation, les mécanismes de détection et de corrélation des événements détectés ainsi que de maintenance en condition opérationnelle des systèmes informatiques d'un aéronef suite à la détection d'événements issus de ces systèmes informatiques et d'amélioration de la conception des aéronefs permettent de supporter les évolutions des attaques visant la sécurité des systèmes informatiques de l'aéronef par la mise à jour des systèmes de détection et d'analyse des événements. De même, ces mécanismes permettent de définir un processus cohérent de traitement des résultats issus de l'application des règles de corrélation afin de maintenir un aéronef dans un état opérationnel car ils s'intègrent dans des processus standard de maintenance des aéronefs. Un dispositif adapté à mettre en oeuvre l'invention ou une partie de l'invention est illustré sur la figure 5. Le dispositif représenté est, de préférence, un dispositif standard, par exemple un calculateur. Le dispositif 500 comporte ici un bus interne de communication 505 30 auquel sont reliés : - une unité centrale de traitement ou microprocesseur 510 (CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ; - une mémoire morte 515 (ROM, acronyme de Read Only Memory en terminologie anglo-saxonne) pouvant comporter les programmes nécessaires à la mise en oeuvre de l'invention ; - une mémoire vive ou mémoire cache 520 (RAM, acronyme de Random Access Memory en terminologie anglo-saxonne) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes précités ; - une interface de communication 540 adaptée à transmettre et à recevoir des données vers et depuis un réseau de communication, par exemple un réseau Ethernet communté de type AFDX (sigle de Avionics Full DupleX en terminologie anglo-saxonne). Le dispositif 500 dispose également, de préférence, des éléments suivants : - un disque dur 525 pouvant comporter les programmes précités et 15 des données traitées ou à traiter selon l'invention ; et - un lecteur de cartes mémoires 530 adapté à recevoir une carte mémoire 535 et à y lire ou à y écrire des données traitées ou à traiter selon l'invention. Le bus interne de communication permet la communication et 20 l'interopérabilité entre les différents éléments inclus dans le dispositif 500 ou reliés à lui. La représentation du bus interne n'est pas limitative et, notamment, le microprocesseur est susceptible de communiquer des instructions à tout élément du dispositif 500 directement ou par l'intermédiaire d'un autre élément 25 du dispositif 500. Le code exécutable de chaque programme permettant au dispositif programmable de mettre en oeuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 525 ou en mémoire morte 515. Selon une variante, la carte mémoire 535 peut contenir des données 30 ainsi que le code exécutable des programmes précités qui, une fois lu par le dispositif 500, est stocké dans le disque dur 525.

Selon une autre variante, le code exécutable des programmes pourra être reçu, au moins partiellement, par l'intermédiaire de la première interface de communication 540, pour être stocké de façon identique à celle décrite précédemment.

De manière plus générale, le ou les programmes pourront être chargés dans un des moyens de stockage du dispositif 500 avant d'être exécutés. Le microprocesseur 510 va commander et diriger l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 525 ou dans la mémoire morte 515 ou bien dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 525 ou la mémoire morte 515, sont transférés dans la mémoire vive 520 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention. L'appareil de communication comportant le dispositif selon l'invention peut également être un appareil programmé. Cet appareil contient alors le code du ou des programmes informatiques par exemple figé dans un circuit intégré à application spécifique, aussi appelé ASIC (acronyme d'Application-Specific Integrated Circuit en terminologie anglo-saxonne). Naturellement, pour satisfaire des besoins spécifiques, une personne compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente.

Claims (10)

1. REVENDICATIONS1. Procédé pour ordinateur de gestion d'au moins un événement lié à la sécurité d'au moins un système informatique d'un aéronef, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, - réception d'au moins une information relative à la détection (110) dudit au moins un événement ; - caractérisation (125) dudit au moins un événement détecté selon au moins une règle d'une pluralité de règles prédéterminées ; et, - établissement d'un rapport de sécurité selon ladite caractérisation dudit au moins un événement détecté.
2. 2. Procédé selon la revendication 1 comprenant en outre une étape de mise à jour de ladite pluralité de règles selon un événement préalablement détecté.
3. 3. Procédé selon la revendication 1 ou la revendication 2 comprenant en outre une étape de détection dudit au moins un événement, ledit au moins un événement étant détecté selon un ensemble d'événements prédéterminés, ledit ensemble d'événements prédéterminés étant mis à jour selon un événement préalablement détecté.
4. 4. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape d'analyse (220) dudit rapport.
5. 5. Procédé selon la revendication précédente comprenant en outre une étape de détermination (235) d'au moins une nouvelle règle en réponse à ladite analyse dudit rapport, ladite pluralité de règles prédéterminées étant mise à jour selon ladite au moins une nouvelle règle déterminée.
6. 6. Procédé selon la revendication 4 ou la revendication 5 comprenant en outre une étape de vérification et de validation d'au moins une information dudit rapport.
7. 7. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape d'insertion dans ledit rapport d'au moins une indication relative au contexte associé audit un moins un événement détecté.
8. 8. Procédé selon l'une quelconque des revendications précédente comprenant en outre une étape de mise à jour de la définition de l'aéronef.
9. 9. Dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications précédentes.
10. 10. Programme d'ordinateur comprenant des instructions adaptées à 10 la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 8 lorsque ledit programme est exécuté sur un ordinateur.