Brevet FR3094506A1 — publié le 20201002

Description Titre de l'invention : Système embarqué à bord d'un aéronef de détection et de réponse aux incidents avec enregistrement de logs [0001] La présente invention concerne un système embarqué à bord d'un aéronef de détection et réponse aux incidents avec enregistrement/journalisation de logs à bord d'un aéronef [0002] Un aéronef comprend au moins un calculateur comprenant une pluralité d'applications utilisant et générant des données. La réception_ l'émission de données, le changement d'état d'une application, la réception-émission d'un signal analogique ou discret constitue du point de vue du destinataire un évènement. [0003] Plus précisément, un événement est défini comme étant un flot entrant, c'est-à-dire une donnée, un signal, une interruption vers une application qui peut la détourner de son traitement en cours. [0004] Il est souhaitable de détecter parmi ces événements ceux qui pourraient affecter la sûreté du vol de l'aéronef et qui sont appelés incidents de sécurité. [0005] Un incident est défini comme un ou plusieurs évènements avec un flot, format, contenu, timing ou fréquence non conforme à la spécification ou l'attendu. Un incident peut avoir plusieurs origines : dysfonctionnement de composant matériel ou logiciel, conditions de fonctionnement hors normes, configuration erronée, malveillance, etc. [0006] Parmi les incidents, les incidents de sécurité sont en particulier des incidents d'origine malveillante ou non perturbant les systèmes d'information de l'aéronef et pour lesquels une réponse est souhaitée pour des raisons de sûreté de fonctionnement et de maintien de l'opérabilité de l'aéronef. [0007] Par exemple, les événements peuvent être reliés à des incidents de sécurité tels que des attaques informatiques (symptômes, traces ou résultats recherchés par l'attaquant) introduisant des dysfonctionnements de l'aéronef [0008] La capacité à détecter ces incidents de sécurité et à y répondre au plus près et donc au plus vite permet d'assurer la sûreté de fonctionnement en prenant donc en compte la sécurité des systèmes d'informations embarqués, c'est le concept communément appelé dans le domaine de l'aéronautique « security for safety » qui veut dire en français la « sécurité pour la sûreté ». [0009] Il est souhaitable de détecter en temps réels, parmi les événements, les incidents de sécurité afin d'en informer le cas échéant l'équipage de l'aéronef. [0010] Dans le domaine des technologies de l'information, il existe des logiciels adaptés pour la surveillance de la sécurité de l'information et de gestion des événements qui sont connus sous l'acronyme SIEM qui signifie en anglais « Security Information and 2 Event Management ». [0011] Ces logiciels sont effectifs à partir de l'analyse de l'ensemble des logs issus des ap- plications constituant les systèmes d'information à surveiller. Ils sont nourris par un grand nombre d'informations, normalisées ou non, et offrent des fonctionnalités d'agrégation, collecte, normalisation analyse et corrélation de ces informations pour identifier une intrusion, un usage illicite du système ou tout autre acte malveillant. Ces dispositifs peuvent être mis à contribution pour effectuer des enregistrements dits à valeurs probantes pour les systèmes d'information le requérant, notamment ceux avec facturation électronique. [0012] De tels logiciels ne peuvent pas actuellement être embarqués à bord des aéronefs pour la surveillance des moyens informatiques alloués au domaine de contrôle du vol, (connu sous l'acronyme ACD qui signifie « Aircraft Control Domain ») non seulement puisqu'ils requièrent des ressources conséquentes de stockage et de puissance de calcul niais surtout puisqu'ils ne disposent pas encore suffisamment de matière (les logs) analysables. En effet, la production de logs par les calculateurs embarqués du domaine du contrôle de vol est inexistante suivant les aéronefs. [0013] Un log est un enregistrement persistant horodaté par un système ou une application d'événements et de leur conséquence qui inclure des données contextuelles et un niveau de sévérité. [0014] Cette production nécessite des moyens informatiques tels qu'une unité centrale de traitement aussi connu sous l'acronyme CPU qui signifie en anglais « Central Processing Unit » ou encore des mémoires non volatiles disponibles de façon limitée pour des raisons de coûts et d'emport. Cela est donc un frein. Il faut ajouter aussi la nécessité d'assurer un haut niveau de qualification des produits issus des exigences de sûreté de fonctionnement comme cela est défini par certaines normes telles que la norme DO 178C. [0015] En outre, ces logiciels demandent de fréquentes mises à jour ou une modification de leur paramétrage nécessitant une maintenance importante qui n'est pas souhaitable. [0016] 11 en résulte qu'actuellement les événements détectés lors du vol de l'aéronef et qui pourraient porter atteinte à la sûreté du vol sont traités mais non enregistrés et encore moins signalés que ce soit au SOC (Acronyme pour « Security Operation Center » en anglais qui signifie en français « centre des opérations de sécurité ») ou à l'équipage. [0017] Le SOC est un centre des opérations de sécurité au sol d'une compagnie aérienne. [0018] La présente invention a pour but de répondre aux problèmes posés en proposant un système embarqué de détections et réponses aux incidents à bord d'un aéronef avec enregistrement d'incidents notamment peu gourmand en termes de puissance de calcul, d'espace de stockage. En outre, l'invention permet de mettre en oeuvre le système embarqué sur les nouveaux aéronefs comme les aéronefs déjà en service. 3 [0019] A cet effet, l'invention concerne un système embarqué à bord d'un aéronef de détection et réponse aux incidents avec enregistrement de logs, l'aéronef comprenant au moins un calculateur comprenant une pluralité d'applications utilisant et générant des données, chaque application étant configurée pour détecter des événements sur la hase des données utilisées et générées par cette application et d'informations pré-définies spécifiant ces événements, le système comprenant pour le ou chaque calculateur un agent et un collecteur, l'agent étant un composant applicatif dédié à une application identifiée du calculateur et étant configure pour appliquer une logique de détection d'incidents aux événements détectés par l'application identifiée afin de détecter parmi ces événements au moins un incident et pour transmettre au collecteur par messages de détection chaque incident détecté suivant une logique de transmission paramétrable, et le collecteur étant configuré pour recevoir les messages de détection en provenance de l'agent pour chaque incident détecté et pour appliquer aux messages de détection une logique d'enregistrement paramétrable des messages de détection en un ou plusieurs log(s). [0020] Suivant d'autres aspects avantageux de l'invention, le système comprend une ou plusieurs des caractéristiques suivantes, prise(s) isolément ou suivant toutes les combinaisons techniquement possibles : [0021] - l'agent et le collecteur sont configurés de sorte que la détection des incidents en fonction de la logique de détection et l'enregistrement des messages de détection en un ou plusieurs log(s) en fonction de la logique d'enregistrement soient mises en oeuvre de manière indépendante au sein du système embarqué. [0022] - la logique de détection définit au moins un seuil spécifié de la fréquence de détection des événements et/ou au moins un seuil spécifié du nombre d'occurrences des événements afin de détecter au moins un incident. [0023] - le système comprend une pluralité d'agents, chaque agent étant analogue audit agent et, de préférence, correspond à l'un des agents de la liste suivante : un agent intégré dans une application opérationnelle du calculateur, un agent intégré dans une application support du calculateur, un agent intégré dans une application en charge des téléchargements et de la configuration du calculateur, un agent de surveillance d'un protocole spécifique d'échanges de données entre deux applications du même calculateur ou entre le calculateur et un autre calculateur distant. [0024] - l'agent est un agent intégré dans une application en charge des téléchargements et de la configuration du calculateur et fait partie du collecteur. [0025] - la logique de transmission définit des paramètres et l'agent est configuré pour agréger les messages de détection de cet incident en fonction des paramètres de la logique de transmission. [0026] - pour chaque incident détecté, la logique de transmission définit au moins un seuil du nombre d'occurrences de détection de cet incident et/ou au moins un seuil de fréquence de détection de cet incident pour le déclenchement de la transmission des messages de détection de cet incident au collecteur. [0027] - la logique d'enregistrement définit des paramètres et, pour chaque incident détecté, le collecteur est configure pour agréger les messages de détection de cet incident en fonction des paramètres de la logique d'enregistrement. [0028] - pour chaque incident détecté, la logique d'enregistrement définit au moins un seuil du nombre d'occurrences de messages de détection de cet incident et/ou au moins un seuil de fréquence de réception des messages de détection de cet incident. [0029] - le collecteur dispose de données de contexte relatives à l'aéronef et/ou au vol de l'aéronef et est configure pour enrichir les logs avec les données de contexte. [0030] - le collecteur est configuré pour enregistrer le ou les log(s) sous un format normalisé prédéfini. [0031] - au moins un incident détecté correspond à une attaque informatique de l'aéronef. [0032] - le système comprend, en outre, une unité d'alerte destinée à émettre une ou plusieurs alertes en temps réel sur la hase du ou des log(s), les alertes étant destinées à un équipage de l'aéronef. [0033] - le système de détection comprend des moyens de transmission configurés pour transférer le ou les log(s) à un centre de sécurité au sol. [0034] Les caractéristiques et avantages de l'invention apparaitront à la lecture de la des- cription qui va suivre, donnée uniquement à titre d'exemple non limitatif, et faite en référence aux dessins annexés, sur lesquels : [0035] - [fig.1] la figure 1 est un schéma synoptique du système selon l'invention, et [0036] - [fig.2] la figure 2 est une vue de détail d'une partie de la figure 1. [0037] Un système 10 embarqué à bord d'un aéronef de détection et réponse aux incidents avec enregistrement de logs est illustré sur la figure 1. [0038] L'aéronef comprend au moins un calculateur comprenant une pluralité d'applications utilisant et générant des données. Par exemple, l'aéronef comprend une pluralité de calculateurs. [0039] Chaque application est configurée pour détecter des événements sur la base des données utilisées et générées par cette application et d'informations prédéfinies spécifiant ces événements. [0040] Un événement est défini au sens générique comme un flot entrant tel qu'une donnée, un signal, une interruption vers une opération, un système et/ou une application pouvant détourner cette opération, ce système ou cette application de son traitement en cours. [0041] Dans la présente demande le flot entrant correspond aux données utilisées et générées par chaque application 30, 32, 34, 36. [0042] Un seul calculateur 12 est représenté sur la figure 1. [0043] Le système 10 comprend pour le ou chaque calculateur 12 une pluralité d'agents A, B, C, F et au moins un collecteur 22. Chaque agent A, B, C, F est connecté au collecteur 22. Le système 10 comprend, en outre, une unité de centralisation 24, unc unité d'alerte 26, unc unité d'affichage d'informations 27, une connexion data-link 28 et un serveur sécurisé 29. [0044] Chaque agent A, B, C, F est un composant applicatif dédié à une application identifiée 30, 32, 34, 36 du calculateur 12. [0045] Chaque agent A, B, C, F est configuré pour analyser les événements détectés par les différentes applications 30, 32, 34, 36. [0046] Chaque agent A, B, C, F est configuré pour appliquer une logique de détection d'incidents aux événements détectés par l'application 30, 32, 34, 36 qui lui est dédiée afin de détecter au moins un incident. [0047] Chaque agent A, B, C, F est en outre configuré pour transmettre au collecteur 22 par messages de détection chaque incident détecté suivant une logique de transmission paramétrable. [0048] Le collecteur 22 est configuré pour recevoir les messages de détection en provenance des agents A, B, C, F pour chaque incident détecté et pour appliquer aux messages de détection une logique d'enregistrement paramétrable des messages de détection en un ou plusieurs log(s). [0049] Un incident détecté correspond à un ou plusieurs évènements avec un flot, format, contenu, timing ou fréquence non conforme à la spécification ou l'attendu. [0050] Les incidents peuvent être liés à une attaque contre l'aéronef ou encore être liées à une défaillance d'un matériel de l'aéronef ou encore à une erreur humaine. [0051] 11 est souhaitable de déterminer parmi l'ensemble des incidents 42 détectés ceux qui sont des « incidents de sécurité ». [0052] Les incidents de sécurité sont des incidents d'origine malveillante ou non perturbant les systèmes d'information de l'aéronef et pour lesquels une réponse est souhaitée pour des raisons de sûreté de fonctionnement et de maintien de l'opérabilité de l'aéronef. [0053] Ainsi, au moins un incident détecté 42 peut correspondre à une attaque, par exemple une attaque informatique de l'aéronef [0054] Les attaques informatiques sont par exemple des incidents de sécurité d'origine mal- veillante. [0055] Comme indiqué précédemment, un log est un enregistrement persistant horodaté par un système ou une application d'événements et de leur conséquence qui inclut des données contextuelles et un niveau de sévérité. [0056] Dans le présent exemple de réalisation, le système comprend quatre agents A, B. C, F. 6 [0057] Un premier d'agent est aussi connu sous l'appellation « agent cyher A ». L'agent cyber A est un composant applicatif intégré dans une application opérationnelle 30 du calculateur 12 couplée aux mécanismes de sûreté de fonctionnement du calculateur 12. [0058] L'agent cyher A est configure pour surveiller des données sensibles. Par donnée sensible, on entend une donnée relative à la sécurité de l'aéronef [0059] Un deuxième agent est aussi connu sous l'appellation « agent cyher B ». L'agent cyber B est un agent applicatif intégré dans une application support 32 du calculateur 12 au plus près des mécanismes de vérification de domaines d'usage. [0060] L'agent cyher B est configuré pour surveiller les domaines d'usage du système d'exploitation par les applications (traitement des erreurs API (acronyme pour « Application Programming Interface » en anglais qui signifie en français « interface de programmation applicative »), droits d'accès, etc.), les domaines d'usage des applications supports (protocoles de communication, c'est-à-dire par exemple la fréquence de messages et la conformité de ces protocoles) et/ou les domaines d'usage du calculateur 12 (« watch dog » qui signifie littéralement en français « chien de garde », « rcset » qui signifie en français « réinitialisation »). [0061] Un troisième agent est connu sous l'appellation « agent cyber C ». L'agent cyher C est un composant applicatif intégré dans une application 34 en charge des téléchargements et de la configuration du calculateur 12. [0062] L'agent cyber C est configuré pour surveiller les échecs de vérification (authentification, intégrité, complétude) et les défauts d'utilisation (compatibilité, conformité, pertinence). [0063] Selon un exemple de réalisation particulier, l'agent cyber C fait partie du collecteur 22. [0064] Un quatrième agent est aussi connu sous l'appellation « agent cyber F ». L'agent cyber F est intégré dans une application 36 configurée pour surveiller un protocole spécifique d'échange de données entre deux applications du même calculateur 12 ou entre le calculateur 12 et un autre calculateur distant. [0065] En référence à la figure 2, l'agent cyber A, le collecteur 22 et les logs 56 sont détaillés. Les autres agents cyber B, C, F sont structurellement analogues à l'agent cyber A et ne seront donc pas détaillés par la suite. [0066] Comme indiqué précédemment, l'agent cyber A est dédié à l'application 30. [0067] L'agent cyber A est associé à une mémoire volatile 31 du calculateur 12. [0068] Les données utilisées et générées par l'application 30 sont repérées par la référence numérique 40. [0069] Les données utilisées et générées 40 comprennent des événements 41. [0070] L'application 30 est configurée pour détecter les événements 41 sur la base des données utilisées et générées 40 et d'informations prédéfinies spécifiant ces 7 événements. [0071] L'agent cyber A est configure pour appliquer une logique de détection 46 d'incidents aux événements détectés 41 par l'application 30 afin de détecter au moins un incident 42 [0072] La logique de détection 46 définit au moins un seuil spécifié de la fréquence de détection des événements 41 détectés et/ou au moins un seuil spécifié du nombre d'occurrences d'événements 41 détectés afin de détecter au moins un incident 42. [0073] A titre d'exemple, la logique de détection 46 définit un flot, un format, un contenu, un timing et/ou une fréquence spécifié(s) relatif(s)s aux événements 41 détectés. [0074] La logique de détection 46 est adaptée pour comparer le flot, le format, le contenu, le timing et/ou la fréquence relatif(s) aux événements détectés 41 au flot, au format, au contenu, au timing et/ou à la fréquence spécifié(s). [0075] Les événements 41 qui ne sont pas conformes à la spécification, c'est-à-dire au flot, au format, au contenu, au timing et/ou à la fréquence spécifié(s) forment des incidents 42. [0076] La mémoire volatile 31 est configurée pour mémoriser les incidents 42 détectés par l'agent cyber A. [0077] Les incidents 42 sont identifiés par un identifiant unique qui est représentatif, par exemple, de l'application 30, de l'agent dédié à cette application qui est dans le cas présent l'agent cyber A et d'un type d'incident. [0078] L'agent cyber A est en outre configuré pour transmettre au collecteur 22 par messages de détection 42A chaque incident 42 détecté suivant la logique de transmission 48. [0079] Par exemple, chaque message de détection 42A d'un incident 42 détecté comprend une donnée représentative d'un numéro d'identification de cet incident 42, une donnée représentative de l'occurrence de cet incident 42 ou de la fréquence de détection de cet incident 42, et d'une donnée représentative de la date UTC de génération du message de détection 42A et/ou de la date UTC de détection de l'incident 42. [0080] Plus précisément, pour chaque incident 42 détecté, l'agent cyber A est configuré pour agréger dans la mémoire volatile 31 les messages de détection 42A de cet incident 42 en fonction des paramètres de la logique de transmission 48. [0081] Ce mécanisme d'agrégation permet de réduire au minimum la perturbation du fonc- tionnement opérationnel de l'application 30 et évite d'introduire de nouvelles vulnérabilités notamment à des attaques en disponibilité. [0082] Par exemple, pour chaque incident 42 détecté, la logique de transmission 48 définit au moins un seuil du nombre d'occurrences de détection de cet incident 42 et/ou au moins un seuil de fréquence de détection de cet incident 42 pour le déclenchement de la transmission des messages de détection 42A de cet incident 42 au collecteur 22. 8 [0083] Autrement dit, pour chaque incident 42 détecté, il est défini au minimum un seuil en termes du nombre d'occurrences de détection de cet incident 42 et/ou au minimum un seuil de fréquence de détection de cet incident 42 qui permet de déclencher la transmission des messages de détection 42A de cet incident 42 de l'agent cyher A vers le collecteur 22. [0084] Ainsi, le dépassement du ou des seuils défini(s) par la logique de transmission est propre à déclencher la transmission des messages de détection 42A au collecteur 22. [0085] A titre d'exemple, dans le cas d'une comptabilisation du nombre d'occurrences de détection d'un incident 42, les paramètres de la logique de transmission 48 définissent un premier seuil du nombre occurrences de cet incident 42 et un deuxième seuil du nombre d'occurrences de cet incident 42. [0086] Lorsque le premier seuil est atteint, l'agent cyher A est configuré pour effectuer une première transmission des messages de détection 42A dudit incident 42 au collecteur 22. Lorsque le deuxième seuil est atteint, l'agent cyher A est configuré pour effectuer une deuxième transmission des messages de détection 42A dudit incident 42. [0087] Selon un exemple particulier de réalisation, les paramètres de la logique de transmission 48 définissent également pour chaque incident 42 détecté un premier mode de transmission des messages de détection 42A ou un deuxième mode de transmission des messages de détection 42A vers le collecteur 22. [0088] Le mode de transmission appliqué dépend de l'incident 42 détecté. [0089] Le premier mode de transmission correspond à la transmission des messages de détection dans le flux d'exécution en cours de l'application 31. Le premier mode de transmission est appliqué pour des incidents détectés 42 qui sont dits « majeurs ». [0090] Le second mode de transmission est un mode de transmission en temps disponible dans une trame temporelle dédiée (mise en cache, traitement en léger différé). [0091] Le collecteur 22 est configuré pour recevoir les messages de détection 42A pour chaque incident détecté 42. [0092] Le collecteur 22 est un composant applicatif. En particulier, le collecteur 22 est configuré pour analyser les messages de détection 42A, les mettre en cache, décider si et quand les enregistrer et avec quelles données. [0093] En outre, le collecteur 22 dispose de données de contexte 44 relatives à l'aéronef et/ ou au vol de l'aéronef. [0094] Ainsi, le collecteur 22 est configuré pour associer aux messages de détection 42A reçus les données de contexte 44. [0095] Les données de contexte 44 sont par exemple des données représentatives de l'aéronef et/ou du vol de l'aéronef. Plus précisément, les données de contexte sont par exemple représentatives de la phase de vol courante de l'aéronef, de l'identité de l'aéronef et/ou encore de données représentatives d'un début ou d'une fin de traitement 9 opérationnel sensible. [0096] Le collecteur 22 est en outre configuré pour appliquer aux messages de détection 42A une logique d'enregistrement 50 paramétrable pour enregistrer les messages de détection 42A en un ou plusieurs log(s) 56. [0097] En particulier, pour chaque incident 42 détecté, la logique d'enregistrement 50 définit des paramètres qui définissent au moins un seuil du nombre occurrences de réception des messages de détection 42A de cet incident 42 et/ou au moins un seuil de fréquence de réception des messages de détection 42A de cet incident 42. [0098] Les seuils définis pour la logique de transmission 48 et pour la logique d'enregistrement 50 permettent d'exclure un phénomène accidentel ou transitoire et d'une autre origine qu'un incident de sécurité à l'encontre de l'aéronef. [0099] Pour chaque incident 42 détecté, le collecteur 22 est configuré pour agréger les messages de détection 42A de cet incident 42 en fonction des paramètres de la logique d'enregistrement 50. [0100] Par exemple, le collecteur 22 est associé à une mémoire volatile 57 du calculateur 12. [0101] Par exemple, le collecteur 22 est configuré pour agréger les messages de détection 42 dans la mémoire volatile 57 en fonction des paramètres de la logique d'enregistrement 50 et d'associer à ces messages de détection 42 agrégés les données de contexte 44. [0102] Le collecteur 22 est alors configuré pour enregistrer, pour chaque incident 42 détecté, les messages de détection 42A de cet incident 42 et pour enrichir ces messages de détection 42A avec les données de contexte 44 sous la forme d'un ou plusieurs log(s) 56 dans une mémoire non volatile 53 du calculateur 12 associée au collecteur 22. [0103] Seul le collecteur 22 présente des droits d'accès à la mémoire non volatile 53. [0104] Selon un exemple de réalisation particulier, le collecteur 22 est également configuré pour corréler différents incidents 42 détectés et des données de contexte connues 44. [0105] Par exemple, le collecteur 22 mémorise une table de corrélation qui associe entre eux différents incidents 42 détectés, par exemple en fonction des types d'incidents détectés ou qui associe entre eux différents incidents 42 détectés entre eux et des données de contexte 44 données. [0106] En fonction de la table de corrélation, le collecteur 22 est alors configuré pour corréler plusieurs messages de détection 42A de différents incidents 42 détectés enrichis des données de contexte 44 et de les enregistrer en un ou plusieurs log(s) 56 dans la mémoire non volatile 53. [0107] Le collecteur 22 est configuré pour enregistrer les logs 56 sous un format normalisé prédéfini. [0108] Les logs 56 sont représentatifs d'un ou plusieurs incident(s) de sécurité pour l'aéronef [0109] Ainsi, le système 10 permet de déterminer parmi les incidents, les incidents de sécurité. [0110] Par exemple, les logs 56 correspondent à une ou plusieurs attaque(s) informatique de l'aéronef. [0111] En référence à la figure 1, l'unité de centralisation 24 est reliée au collecteur 22. Le collecteur 22 est en outre configuré pour transférer les logs 56 enregistrés à l'unité de centralisation 24. [0112] L'unité de centralisation 24 est configurée pour recevoir les logs 56 enregistrés et pour les transférer à un centre des opérations de sécurité (SOC) 60 situe au sol de la compagnie aérienne par l'intermédiaire de la connexion data-link 28 et/ou du serveur de sécurité 29. [0113] L'unité d'alerte 26 est destinée à émettre une ou plusieurs alertes sur la base du ou des log(s) 56 enregistrés, les alertes étant destinées à un équipage 58 de l'aéronef, par exemple, le pilote ou le personnel navigant. [0114] L'unité d'alerte 26 est connectée au collecteur 22. [0115] L'unité d'affichage d'informations 27 est aussi connectée au collecteur 22 et est configure° pour recevoir les logs 56 et délivrer un affichage représentatif de ceux-ci à destination de l'équipage 58 de l'aéronef [0116] En variante, le système 10 est dépourvu d'unité de centralisation 24. Dans un tel cas, le collecteur 22 est configuré pour transmettre les logs 56 vers le centre sécurité au sol 60. [0117] Ainsi, le collecteur 22 est par exemple propre à mémoriser une logique de transmission prédéfinie et paramétrable des logs 56 vers le centre de sécurité au sol 60. [0118] Le fonctionnement du système 10 selon l'invention est décrit dans la suite. [0119] Le fonctionnement du système 10 est décrit dans la suite en relation avec l'application opérationnelle 30 et l'agent cyber A. [0120] Le système embarqué d'ern-egistrement 10 présente un fonctionnement analogue avec les autres agents B, C, et F, la seule différence étant la nature des données utilisées et générées par les agents B, C, F. [0121] En référence à la figure 2, l'application opérationnelle 30 détecte des événements 41 en fonction des données utilisées et générées 40 par cette application 30 et d'informations prédéfinies spécifiant ces événements 41. [0122] L'agent cyber A reçoit les événements 41 et applique la logique de détection 46 d'incidents aux événements 41 afin de détecter parmi ces événements 41 au moins un incident 42. [0123] Puis, pour chaque incident 42 détecté, l'agent cyber A génère des messages de détection 42A de cet incident 42. [0124] En outre, pour chaque incident 42 détecté, l'agent cyber A, agrège les messages de détection 42A générés en fonction des paramètres de la logique de transmission 48 11 dans la mémoire volatile 31. [0125] Cc mécanisme de mise en cache optimisé permet d'agréger localement les messages de détection 42A avec la possibilité de vérifier le nombre d'occurrences de détection de l'incident 42 ou la fréquence de détection de l'incident 42 par comparaison aux seuils définis par les paramètres de la logique de transmission 48. [0126] Ce mécanisme de mise en cache optimisée permet alors de vérifier le nombre d'occurrences d'un d'incident 42 et/ou la fréquence de détection de l'incident 42 et de comparer ce nombre et/ou cette fréquence aux seuils définis par les paramètres de la logique de transmission 48 avant de transmettre les messages de détection 42A au collecteur 22. [0127] Selon un exemple de réalisation particulier, pour chaque incident 42 détecté, la logique de transmission 48 défini un premier seuil et un deuxième seuil du nombre d'occurrences de détection de cet incident 42, comme cela a été décrit précédemment. Alors, pour chaque incident 42 détecté, lorsque le premier seuil du nombre d'occurrences de détection de cet incident 42 est atteint et l'agent cyber A transmet les messages de détection 42A agrégés via une première transmission au collecteur 22. En outre, lorsque le deuxième seuil du nombre d'occurrences de détection de cet incident 42 est atteint, l'agent cyber A transmet via une deuxième transmission les messages de détection 42A agrégés au collecteur 22. [0128] Lorsque le collecteur 22 reçoit les messages de détection 42A, le collecteur 22 enrichit les messages de détection 42A reçus avec les données de contexte 44. [0129] Puis, le collecteur 22 applique la logique d'enregistrement 50 aux messages de détection 42A reçus de l'agent cyber A. [0130] Pour chaque incident 42 détecté, l'agent cyber A, agrège les messages de détection 42A en fonction des paramètres de la logique d'enregistrement 50 enrichis des données de contexte 44. [0131] Plus précisément et selon un mode de réalisation particulier, pour chaque incident 42 détecté, lorsque le seuil du nombre d'occurrences de messages de détection 42A de cet incident 42 et/ou lorsque le seuil de fréquence de réception des messages de détection 42A de cet incident 42 défini(s) pour la logique d'enregistrement 50 est atteint, le collecteur 22 enregistre les messages 42A agrégés et enrichis des données de contexte 44 sous la forme d'un ou plusieurs log(s) 56 dans la mémoire non-volatile 53. [0132] Selon un exemple de réalisation particulier, le collecteur 22 effectue une corrélation entre les messages de détection 42A de plusieurs incidents 42 différents et les données d'état connues 44 qui sont également enregistrés en un ou plusieurs log(s) 56. [0133] Par exemple, cette corrélation est effectuée par l'intermédiaire de la table de cor- rélation mémorisée dans la mémoire non-volatile du collecteur 22. [0134] En référence à la figure 1, les logs 56 sont transmis à l'unité de centralisation 24 via 12 le collecteur 22 qui est connecté à l'unité de centralisation 24. [0135] Sur la hase des logs 56, le collecteur 22 active l'unité d'alerte 26 à destination de l'équipage 58 de l'aéronef et/ou l'unité d'affichage 27. [0136] En outre, l'unité de centralisation 24 transmet les logs 56 au centre de sécurité 60 au sol via la connexion data-link 28 et/ou via le serveur sécurisé 29. [0137] Le système embarqué 10 selon l'invention permet l'identification et l'enregistrement d'incidents de sécurité à bord de l'aéronef en temps réel et est peu coûteux en capacité de stockage et en puissance de calcul. [0138] En effet, grâce au système selon l'invention, il est possible de déterminer parmi les incidents, les incidents de sécurité. [0139] En particulier, le fait que les agents cybcr A, B, C, F et le collecteur 22 soient configurés de sorte que la détection des incidents 42 et l'enregistrement des logs 56 soient indépendantes permet de ne pas entraîner une surcharge des applications et de ne pas dérouter l'application de sa tâche courante. [0140] En outre, les deux niveaux d'agrégation, l'un au niveau des agents A, B, C, F et l'autre au niveau du collecteur 22 permet d'obtenir un système 10 embarqué résilient à la survenue massives d'incidents, qu'ils soient malveillants, c'est-à-dire symptomatique d'une attaque, ou associés à des défaillances. [0141] La logique de transmission 48 et la logique d'enregistrement mises en oeuvre permettent d'exclure un phénomène accidentel ou transitoire et d'une autre origine qu'un incident de sécurité à l'encontre de l'aéronef. Ainsi, l'invention permet de déterminer parmi les événements, les incidents de sécurité et de générer des logs relatifs à ces incidents de sécurité. [0142] En outre, le fait que l'équipage peut être alerté en temps réel de l'enregistrement de logs 56 et donc de la survenue d'incidents de sécurité, cela permet à l'équipage de prendre le plus rapidement possible des mesures adéquates relatives à ces incidents de sécurité. [0143] Par ailleurs, l'octroi des accès en mémoire non volatile 53 au seul collecteur 22 permet de limiter l'introduction de nouvelles vulnérabilités. [0144] En outre, le système 10 selon l'invention peut être mis en oeuvre sur les nouveaux aéronefs. Il permet le traitement des architectures dites « legacy », c'est-à-dire qu'il peut être introduit sur des aéronefs en exploitation au fur et à mesure. [0145] Le système 10 selon l'invention est également adaptable. Il peut être introduit dans l'aéronef de manière incrémentale. Autrement dit, des applications dépourvues d'agent peuvent cohabiter avec des applications comprenant des agents A, B, C, F sur le même calculateur 12. [0146] Encore un autre avantage du système selon l'invention concerne l'intégration de la solution dans les procédures opérationnelles existantes issues de l'application des re- 13 commandations sur la maintenance ARINC 624-1. [0147] Le système selon l'invention n'a aucun impact sur les procédés opérationnels (suivi des recommandations ARINC 811). [0148] En outre, grâce au système selon l'invention, aucune compétence cyber n'est requise à bord de l'aéronef ou en MRO (acronyme qui signifie en anglais « Maintenance, Repair, and Overhaul » et qui signifie en français « Maintenance, Réparation et Révision ». 14 [Revendication 1] [Revendication 2] [Revendication 3] [Revendication 4] REVENDICATIONSSystème (10) embarqué à bord d'un aéronef de détection et réponse aux incidents avec enregistrement de logs, l'aéronef comprenant au moins un calculateur (12) comprenant une pluralité d'applications (30, 32, 34, 36) utilisant et générant des données (40), chaque application (30, 32, 34, 36) étant configurée pour détecter des événements (41) sur la hase des données utilisées et générées (40) par cette application (30, 32, 34, 36) et d'informations prédéfinics spécifiant ces événements (41), le système (10) comprenant pour le ou chaque calculateur (12) un agent (A, B, C. F) et un collecteur (22), l'agent (A, B, C, F) étant un composant applicatif dédié à une application identifiée (30, 32, 34, 36) du calculateur (12) et étant configuré pour appliquer une logique de détection (46) d'incidents aux événements détectés (41) par l'application identifiée (30, 32, 34, 36) afin de détecter parmi ces événements au moins un incident (42) et pour transmettre au collecteur (22) par messages de détection (42A) chaque incident (42) détecté suivant une logique de transmission (48) paramétrable. et le collecteur (22) étant configuré pour recevoir les messages de détection (42A) en provenance de l'agent (A, B. C, F) pour chaque incident détecté (42) et pour appliquer aux messages de détection (42A) une logique d'enregistrement (50) paramétrable des messages de détection (42A) en un ou plusieurs log(s) (56). Système selon la revendication 1, dans lequel l'agent (A, B. C, F) et le collecteur (22) sont configurés de sorte que la détection des incidents (42) en fonction de la logique de détection (46) et l'enregistrement des messages de détection (42A) en un ou plusieurs log(s) (56) en fonction de la logique d'enregistrement (50) soient mises en oeuvre de manière indépendante au sein du système (10) embarqué. Système selon la revendication 1 ou 2, dans lequel la logique de détection (46) définit au moins un seuil spécifié de la fréquence de détection des événements (41) et/ou au moins un seuil spécifié du nombre d'occurrences des événements (41) afin de détecter au moins un incident (42). Système selon l'une quelconque des revendications précédentes, comprenant une pluralité d'agents (A, B, C, F), chaque agent étant analogue audit agent et, de préférence, correspondant à l'un des agents 15 [Revendication 5] [Revendication 6] [Revendication 7] [Revendication 8] [Revendication 9] [Revendication 10] de la liste suivante : - un agent (A) intégré dans une application opérationnelle (30) du calculateur (12), - un agent (B) intégré dans une application support (32) du calculateur (12), - un agent (C) intégré dans une application (34) en charge des téléchargements et de la configuration du calculateur (12), - un agent (F) de surveillance d'un protocole spécifique d'échanges de données entre deux applications du même calculateur (12) ou entre le calculateur (12) et un autre calculateur distant. Système selon l'une quelconque des revendications précédentes, dans lequel l'agent est un agent (C) intégré dans une application (34) en charge des téléchargements et de la configuration du calculateur (12) et fait partie du collecteur (22). Système selon l'une quelconque des revendications précédentes, dans lequel la logique transmission (48) définit des paramètres et dans lequel l'agent (A, B, C, F) est configuré pour agréger les messages de détection (42A) de cet incident (42) en fonction des paramètres de la logique de transmission (48). Système selon l'une quelconque des revendications précédentes, dans lequel pour chaque incident (42) détecté, la logique de transmission (48) définit au moins un seuil du nombre d'occurrences de détection de cet incident (42) et/ou au moins un seuil de fréquence de détection de cet incident (42) pour le déclenchement de la transmission des messages de détection (42A) de cet incident (42) au collecteur (22). Système selon l'une quelconque des revendications précédentes, dans lequel la logique d'enregistrement (50) définit des paramètres et dans lequel, pour chaque incident (42) détecté, le collecteur (22) est configuré pour agréger les messages de détection (42A) de cet incident (42) en fonction des paramètres de la logique d'enregistrement (50). Système selon l'une quelconque des revendications précédentes, dans lequel, pour chaque incident (42) détecté, la logique d'enregistrement (50) définit au moins un seuil du nombre d'occurrences de messages de détection (42A) de cet incident (42) et/ou au moins un seuil de fréquence de réception des messages de détection (42A) de cet incident (42). Système selon l'une quelconque des revendications précédentes, dans lequel le collecteur (22) dispose de données de contexte (44) relatives à 16 [Revendication 11] [Revendication 12] [Revendication 13] [Revendication 14] l'aéronef et/ou au vol de l'aéronef et est configure pour enrichir le ou les log(s) (56) avec les données de contexte (44). Système selon l'une quelconque des revendications précédentes, dans lequel le collecteur (22) est configure pour enregistrer le ou les log(s) (56) sous un format normalisé prédéfini. Système selon l'une quelconque des revendications précédentes, dans lequel au moins un incident détecté (42) correspond à une attaque informatique de l'aéronef. Système selon l'une quelconque des revendications précédentes, comprenant, en outre, une unité d'alerte (26) destinée à émettre une ou plusieurs alertes en temps réel sur la hase du ou des log(s) (56), les alertes étant destinées à un équipage (58) de l'aéronef. Système de détection selon l'une quelconque des revendications précédentes, comprenant des moyens de transmission (22, 24) configurés pour transférer le ou les log(s) (56) à un centre de sécurité au sol (60).