FR3131647A1 - Procédé de détection d'une anomalie dans un système électronique en fonctionnement - Google Patents
Procédé de détection d'une anomalie dans un système électronique en fonctionnement Download PDFInfo
- Publication number
- FR3131647A1 FR3131647A1 FR2114743A FR2114743A FR3131647A1 FR 3131647 A1 FR3131647 A1 FR 3131647A1 FR 2114743 A FR2114743 A FR 2114743A FR 2114743 A FR2114743 A FR 2114743A FR 3131647 A1 FR3131647 A1 FR 3131647A1
- Authority
- FR
- France
- Prior art keywords
- hardware
- detection method
- electronic system
- measurement
- blocks
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 47
- 238000005259 measurement Methods 0.000 claims abstract description 90
- 238000001514 detection method Methods 0.000 claims abstract description 62
- 230000003993 interaction Effects 0.000 claims abstract description 23
- 230000015654 memory Effects 0.000 claims description 49
- 238000004364 calculation method Methods 0.000 claims description 34
- 238000012545 processing Methods 0.000 claims description 27
- 238000004590 computer program Methods 0.000 claims description 17
- 238000004458 analytical method Methods 0.000 claims description 15
- 230000002123 temporal effect Effects 0.000 claims description 12
- 238000013519 translation Methods 0.000 claims description 6
- 238000005265 energy consumption Methods 0.000 claims description 4
- 230000007257 malfunction Effects 0.000 claims description 4
- 239000000463 material Substances 0.000 claims description 2
- 238000009826 distribution Methods 0.000 description 9
- 238000004891 communication Methods 0.000 description 8
- 230000008569 process Effects 0.000 description 8
- 230000002776 aggregation Effects 0.000 description 7
- 238000004220 aggregation Methods 0.000 description 7
- 230000006399 behavior Effects 0.000 description 6
- 230000006870 function Effects 0.000 description 6
- 230000002159 abnormal effect Effects 0.000 description 5
- 238000012360 testing method Methods 0.000 description 5
- 238000013461 design Methods 0.000 description 4
- 238000010801 machine learning Methods 0.000 description 4
- 238000012549 training Methods 0.000 description 4
- 238000012544 monitoring process Methods 0.000 description 3
- 238000005070 sampling Methods 0.000 description 3
- 238000003860 storage Methods 0.000 description 3
- 206010000117 Abnormal behaviour Diseases 0.000 description 2
- 238000013528 artificial neural network Methods 0.000 description 2
- 230000003542 behavioural effect Effects 0.000 description 2
- 239000011449 brick Substances 0.000 description 2
- 230000015556 catabolic process Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000010354 integration Effects 0.000 description 2
- 238000002955 isolation Methods 0.000 description 2
- 238000007726 management method Methods 0.000 description 2
- 230000002829 reductive effect Effects 0.000 description 2
- 238000007619 statistical method Methods 0.000 description 2
- 230000001052 transient effect Effects 0.000 description 2
- PXFBZOLANLWPMH-UHFFFAOYSA-N 16-Epiaffinine Natural products C1C(C2=CC=CC=C2N2)=C2C(=O)CC2C(=CC)CN(C)C1C2CO PXFBZOLANLWPMH-UHFFFAOYSA-N 0.000 description 1
- 230000004913 activation Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000012512 characterization method Methods 0.000 description 1
- 239000000470 constituent Substances 0.000 description 1
- 238000005520 cutting process Methods 0.000 description 1
- 238000003066 decision tree Methods 0.000 description 1
- 230000007123 defense Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000007667 floating Methods 0.000 description 1
- 230000002045 lasting effect Effects 0.000 description 1
- 230000000670 limiting effect Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000005055 memory storage Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000036961 partial effect Effects 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 230000003449 preventive effect Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 230000011218 segmentation Effects 0.000 description 1
- 238000000638 solvent extraction Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 230000008685 targeting Effects 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 238000012800 visualization Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/55—Detecting local intrusion or implementing counter-measures
- G06F21/552—Detecting local intrusion or implementing counter-measures involving long-term monitoring or reporting
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/55—Detecting local intrusion or implementing counter-measures
- G06F21/554—Detecting local intrusion or implementing counter-measures involving event detection and direct action
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/55—Detecting local intrusion or implementing counter-measures
- G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
- G06F21/566—Dynamic detection, i.e. detection performed at run-time, e.g. emulation, suspicious activities
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/55—Detecting local intrusion or implementing counter-measures
- G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
- G06F21/567—Computer malware detection or handling, e.g. anti-virus arrangements using dedicated hardware
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1433—Vulnerability analysis
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Computer Hardware Design (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Virology (AREA)
- Computing Systems (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Debugging And Monitoring (AREA)
Abstract
Titre : Procédé de détection d’une anomalie dans un système électronique en fonctionnement L’invention concerne un procédé de détection (200) d’une anomalie dans un système électronique en fonctionnement, en particulier une attaque informatique, le système électronique comprenant des processeurs composés chacun de blocs matériels, le processeur étant adapté pour exécuter une application (A) par interactions de l’application avec lesdits blocs matériels. Le procédé de détection comprend au moins les étapes suivantes : mesure (210), lors du fonctionnement du système électronique, d’au moins un paramètre représentatif des interactions de l’application avec l’un des blocs matériels,pour chaque mesure, comparaison (220) avec un ensemble de données de référence (J) associé pour détecter d’éventuelles incohérences entre la mesure et l’ensemble de données de référence, ledit ensemble de données de référence étant représentatif du fonctionnement du système électronique sans anomalies, etémission (230) d’une alerte selon un critère d’alerte portant sur la ou les incohérences détectées. Figure pour l'abrégé : Figure 5
Description
La présente invention porte sur un procédé de détection d’une anomalie dans un système électronique en fonctionnement, en particulier une attaque informatique contre le système électronique.
L’invention s’applique en particulier au domaine des calculateurs embarqués critiques tels que ceux présents dans l'avionique, le spatial, le ferroviaire, l'automobile, le maritime, le médical ou l’IIoT (« Industrial Internet of Things » en anglais ou « Internet industriel des objets » en français), traditionnellement confrontés à des problématiques de sûreté de fonctionnement, dont le rôle est de protéger ces systèmes et leurs utilisateurs des défaillances et des pannes.
De nombreux standards de certification liés à ces industries tels que la norme DO178C/DO254 pour le domaine avionique, la norme IEC61508 pour le secteur industriel, la norme EN5012x pour le secteur ferroviaire, la norme ECSSx pour le domaine spatial permettent d'obtenir les garanties de sûreté nécessaires sur la fiabilité et la disponibilité de ces systèmes. Cependant les systèmes deviennent de plus en plus connectés, ce qui introduit de nouvelles problématiques liées à la cyber-sécurité et à la résistance aux attaques malveillantes.
A titre d’exemple, dans le domaine avionique, il est prévu la possibilité que le contrôle aérien, qui a une meilleure vue d'ensemble, puisse piloter les avions depuis le sol lors des phases d'approche des aéroports, introduisant de nouvelles problématiques d’authentification, de confidentialité et d'intégrité.
L’IIoT reprend les principes de l'internet des objets (ou « IoT » pour « Internet of Things » en anglais) pour les appliquer au secteur industriel, partageant les capteurs de données des différents systèmes, et maximisant les communications machines-machines sans intervention humaine. L’IIoT favorise la communication constante entre les différents systèmes pour augmenter l’efficacité opérationnelle, mais il est confronté à la nécessité d'une part de sécuriser ces communications, et d'autre part de s'assurer de la sécurité de chacun des systèmes le constituant, afin qu'il ne puisse pas servir de porte dérobée pour entrer dans le système de manière malveillante.
Le domaine des ordinateurs portatifs (« wearable computing » en anglais) et des systèmes médicaux implantés, en plus des problèmes de sécurité classiques, est également confronté à des problématiques de confidentialité et d'intégrité des données.
En outre, les systèmes sécurisés sont traditionnellement mis à jour dès qu'une faille de sécurité est découverte et corrigée. Cependant, les systèmes à haut niveau de sûreté de fonctionnement sont rarement mis à jour, car ceci implique généralement de certifier à nouveau tout le système ce qui peut avoir de très lourds coûts financiers. Une sécurisation efficace des systèmes embarqués critiques ne peut donc pas uniquement recourir à des défenses ad-hoc à chaque type d'attaque nécessitant chacune une mise à jour, mais doit également permettre la détection proactive de nouvelles attaques malveillantes.
On connait en cyber-sécurité des systèmes de détection d'intrusion (IDS pour « Intrusion Detection System » en anglais). Ces systèmes sont classés généralement en deux catégories, à savoir les NIDS (pour « Network Intrusion Detection System » ou « Système de détection d’intrusion réseau » en français) et les HIDS (pour « Host Intrusion Detection System » ou « Système de détection d’intrusion de l’hôte » en français). Les NIDS se focalisent sur l'analyse des communications réseau. Il s'agit de capturer le trafic en un point particulier d'un réseau, et d'analyser les paquets en les comparant à une base de données de motifs d'attaque. Si un ensemble de paquets correspond à un motif d'attaque connu, une alerte est levée. Les HIDS se focalisent sur un ordinateur, au niveau de son système d'exploitation. Il s'agit de détecter des comportements anormaux, en surveillant les processus en cours d'exécution, les allocations de mémoire, les utilisateurs connectés, etc. Une alerte est générée quand une des grandeurs surveillées s'éloigne d'une norme prédéfinie.
Tous ces systèmes se focalisent sur des problèmes de sécurité soit au niveau logiciel, soit au niveau des communications. Toutefois, les attaques les plus récentes ont commencé à exploiter des vulnérabilités matérielles au niveau du processeur, qui sont bien plus complexes et coûteuses à corriger.
Par exemple, l'attaque Spectre exploite une vulnérabilité matérielle de certaines implémentations de la prédiction de branchement de microprocesseurs dotés d'exécution spéculative. Alors qu'au niveau fonctionnel, une erreur de prédiction est annulée dès qu'elle est constatée, l'exécution spéculative peut cependant, comme effet secondaire, permettre d'accéder arbitrairement à des emplacements de la mémoire vive, les données utilisées par le code ayant été exécuté "au cas où" restant stockées dans le cache.
L’attaque Meltdown exploite également une vulnérabilité liée à la spéculation utilisée pour l'exécution dans le désordre des instructions dans le processeur, incluant les mémoires caches et le TLB (de l’anglais « Translation Lookaside Buffer » ou « mémoire tampon d'anticipation de traduction » en français). Contrairement à l’attaque Spectre, l’attaque Meltdown utilise des mécanismes plus spécifiques à l'architecture du processeur, et permet d'une part d'accéder à des données sans les droits d'accès correspondants, mais également de faire de l'escalade de privilèges.
L’attaque Rowhammer exploite un effet secondaire imprévu des mémoires dynamiques à accès aléatoire (DRAM pour « Dynamic Random Access Memory » en anglais) provoquant une fuite de charge électrique dans des cellules de mémoire adjacentes, ce qui permet de modifier le contenu mémorisé dans ces cellules voisines sans disposer du droit d'accès.
Ainsi, les méthodes connues de détection sont devenues insuffisantes devant cette nouvelle génération d’attaques informatiques.
Il existe donc un besoin pour un procédé capable de mieux détecter et de se prémunir contre des anomalies affectant le système électronique, en particulier des attaques informatiques.
A cet effet, il est proposé un procédé de détection d’une anomalie dans un système électronique en fonctionnement, en particulier une attaque informatique contre le système électronique, le système électronique comprenant un ou plusieurs processeurs composés chacun d’une pluralité de blocs matériels , le processeur étant adapté pour exécuter au moins une application par interactions de l’application avec lesdits blocs matériels, le procédé de détection comprenant au moins les étapes suivantes :
- mesure, lors du fonctionnement du système électronique, d’au moins un paramètre représentatif des interactions de l’application avec l’un des blocs matériels pour obtenir des mesures dudit paramètre représentatif,
- pour chaque mesure, comparaison de ladite mesure avec un ensemble de données de référence associé pour détecter d’éventuelles incohérences entre la mesure et l’ensemble de données de référence, ledit ensemble de données de référence étant représentatif du fonctionnement du système électronique sans anomalies, et
- émission d’une alerte selon un critère d’alerte portant sur la ou les incohérences détectées.
Suivant d’autres modes de réalisation, le procédé comprend une ou plusieurs des caractéristiques suivantes, prise(s) isolément ou suivant toutes les combinaisons techniquement possibles :
- le procédé de détection comprend, en outre, au moins une étape choisie parmi le groupe constitué de :
- analyse de la nature du bloc matériel associé à chaque incohérence,
- analyse de la fréquence temporelle des incohérences, et
- analyse de l’écart de chaque mesure associée aux incohérences à l’ensemble de données de référence ;
le procédé de détection comprenant une étape de détection, en fonction de la ou chaque analyse d’une anomalie, en particulier une attaque informatique ou une défaillance matérielle de l’un des blocs matériels.
- lorsqu’au moins une alerte associée à l’un des blocs matériels est émise, une nouvelle itération des étapes du procédé de détection à partir de l’étape de mesure est mise en œuvre, l’ensemble des blocs matériels dont une mesure de paramètre représentatif est effectuée étant, à chaque itération, inclus dans l’ensemble des blocs matériels de la précédente itération, l’ensemble des blocs matériels étant notamment inclus dans l’ensemble des blocs matériels associés à la ou les alertes.
- chaque critère d’alerte dépend d’au moins une condition sur les paramètres représentatifs, le procédé de détection comprenant, lorsqu’une alerte associée à l’un des blocs matériels est émise, une nouvelle itération des étapes du procédé de détection à partir de l’étape de mesure, le critère d’alerte comprenant, à chaque itération, un nombre croissant de conditions.
- chaque paramètre représentatif associé à l’un des blocs matériel est choisi parmi le groupe constitué de :
- le type de données traitées par le bloc matériel;
- le type d’instructions exécutées par le bloc matériel;
- le nombre d’accès au bloc matériel;
- le nombre de calcul exécutés et/ou le temps de calcul du bloc matériel;
- le nombre de dysfonctionnements du bloc matériel, et
- le nombre d’interactions sur un réseau d’interconnexion interne au processeur impliquant le bloc matériel, et
- le nombre d’interactions avec l’extérieur du processeur par le bloc matériel.
- chaque bloc matériel est choisi parmi le groupe constitué de :
- une ou plusieurs unités de calcul,
- une ou plusieurs unités de prédiction de branchement,
- un ou plusieurs registres de mémoire interne du processeur,
- une ou plusieurs mémoires caches,
- une ou plusieurs mémoires vives,
- une ou plusieurs chaines de traitement,
- une ou plusieurs unités de protection mémoire ou de traduction d’adresse,
- un ou plusieurs bus ou réseaux d’interconnexion,
- une ou plusieurs unités d'entrée-sortie
chaque paramètre représentatif du fonctionnement de l’un des blocs matériels étant choisi parmi le groupe constitué de :
- le nombre de données d’un même type traitées par la ou les unités de calcul, le ou les réseaux d’interconnexion ou la ou les mémoires,
- le nombre d’instructions d’un même type exécutées par la ou les unités de calcul,
- la consommation d’énergie de la ou des unités de calcul,
- la température de la ou des unités de calcul,
- le nombre de réussites et/ou d’erreurs de prédiction de l’unité de prédiction de branchement,
- le nombre d’accès aux mémoires,
- le nombre de réussites et/ou d’erreurs de sollicitations de la mémoire cache,
- le nombre de réussites et/ou d’erreurs de sollicitations de l’unité de protection mémoire,
- le temps d’exécution d’une instruction dans la chaine de traitement,
- le nombre d’échanges d’information via le ou les réseaux d’interconnexion interne(s) au processeur,
- le nombre d’échanges d’information via le ou les réseaux d’interconnexion obtenus par une source donnée,
- le nombre d’échanges d’information via le ou les réseaux d’interconnexion envoyés à une destination donnée, et
- le nombre d’échanges d’informations via l’unité d'entrée-sortie.
- le système électronique comprend une pluralité de blocs matériels de comptage configurés chacun pour mesurer l’un des paramètres représentatifs, l’étape de mesure comprenant la mesure d’une pluralité de paramètres représentatifs, notamment entre quatre et six, par exemple les paramètres représentatifs mesurés par une partie des blocs matériels de comptage.
- le procédé de détection comprend, en outre, une étape de :
- comparaison de la ou de chaque incohérence associée à l’alerte émise avec un ensemble d’anomalies connues prédéterminées, et
- catégorisation de l’alerte lorsque la ou chaque incohérence correspond à l’une des anomalies connues dudit ensemble d’anomalies.
- le système électronique est un calculateur embarqué dans une plateforme de transport.
- le procédé de détection est mis en œuvre par un système choisi dans le groupe constitué de :
- un circuit logique programmable dédié formant l’un desdits blocs matériels du processeur ;
- un logiciel d’un système d’exploitation du système électronique configuré pour interagir avec une mémoire protégée par une unité de protection mémoire, et
- une application propre à être mise en œuvre par le système électronique par adjonction d’un pilote contrôlant les blocs matériels.
Il est aussi proposé un produit programme d’ordinateur comportant un support lisible d’informations, sur lequel est mémorisé un programme d’ordinateur comprenant des instructions de programme, le programme d’ordinateur étant chargeable sur une unité de traitement de données et adapté pour entraîner la mise en œuvre d’un procédé de détection tel que défini ci-dessus lorsque le programme d’ordinateur est mis en œuvre sur l’unité de traitement des données.
L’invention concerne également un support lisible d’informations sur lequel est mémorisé un produit programme d’ordinateur tel que défini ci-dessus.
Il est proposé en outre un calculateur embarqué dans une plateforme de transport configuré pour mettre en œuvre le procédé de détection tel que défini ci-dessus, le système électronique étant le calculateur embarqué.
L’invention concerne également une plateforme de transport comprenant le calculateur tel que défini ci-dessus.
L’invention concerne également un procédé de génération d’un jeu de référence, le jeu de référence étant représentatif du fonctionnement d’un système électronique en fonctionnement sans anomalies,
le système électronique comprenant un ou plusieurs processeurs composés chacun d’une pluralité de blocs matériels, les blocs matériels comprenant des blocs matériels d’exécution et des blocs matériels de comptage, le processeur étant adapté pour exécuter au moins une application par interactions de l’application avec lesdits blocs matériels d’exécution, chaque bloc matériel de comptage étant adapté pour mesurer un paramètre de fonctionnement représentatif des interactions de l’application avec l’un des blocs matériels d’exécution pour obtenir des mesures dudit paramètre représentatif,
le procédé de génération comprenant au moins les étapes suivantes :
- exécution de l’application sur un banc de test en fonction d’une pluralité de données d’entrée prédéterminées, lesdites données d’entrée étant représentatives du fonctionnement en exploitation du système électronique sans anomalies,
- mesures par au moins l’un des blocs matériels de comptage d’au moins un paramètre de fonctionnement représentatif des interactions de l’un des blocs matériels d’exécution lors de l’étape d’exécution avec l’application, pour obtenir des mesures,
- traitement des mesures de l’au moins un paramètre de fonctionnement, pour obtenir des données traitées, et
- génération du jeu de référence à partir des données traitées.
Suivant d’autres modes de réalisation, le procédé comprend une ou plusieurs des caractéristiques suivantes, prise(s) isolément ou suivant toutes les combinaisons techniquement possibles :
- lors de l’étape de mesures, les mesures obtenues sont des mesures d’une pluralité de paramètres de fonctionnement, notamment d’un nombre de paramètres de fonctionnement compris entre quatre et six, l’ensemble des mesures obtenues étant, par exemple, uniquement les paramètres de fonctionnement mesurés par une partie des blocs matériels de comptage.
- au moins une nouvelle itération des étapes du procédé de génération est mise en œuvre, l’étape de mesures d’une itération étant mise en œuvre par au moins un bloc matériel de comptage différent de l’au moins un bloc matériel de comptage mettant en œuvre l’étape de mesures d’une autre itération.
- chaque paramètre de fonctionnement représentatif des interactions de l’un des blocs matériel d’exécution avec l’application est choisi parmi le groupe constitué de :
- le type de données traitées par le bloc matériel considéré,
- le type d’instructions exécutées par le bloc matériel considéré;
- le nombre d’accès au bloc matériel considéré,
- le nombre de calcul exécutés et/ou le temps de calcul du bloc matériel considéré,
- le nombre de dysfonctionnements du bloc matériel considéré,
- le nombre d’interactions sur un réseau d’interconnexion interne au processeur impliquant le bloc matériel, et
- le nombre d’interactions avec l’extérieur du processeur par le bloc matériel d’exécution considéré.
- chaque bloc matériel d’exécution est choisi parmi le groupe constitué par :
- une ou plusieurs unités de calcul,
- une ou plusieurs unités de prédiction de branchement,
- un ou plusieurs registres de mémoire,
- une ou plusieurs mémoires caches,
- une ou plusieurs mémoires vives,
- une ou plusieurs chaînes de traitement,
- une ou plusieurs unités de protection mémoire ou de traduction d’adresse,
- un ou plusieurs bus ou réseaux d’interconnexion, et
- une ou plusieurs unités d'entrée-sortie,
chaque paramètre représentatif du fonctionnement de l’un des blocs matériels d’exécution étant choisi parmi le groupe constitué par :
- le nombre de données d’un même type traitées par la ou les unités de calcul, le ou les réseaux d’interconnexion ou la ou les mémoires,
- le nombre d’instructions d’un même type exécutées par l’unité de calcul,
- la consommation d’énergie de la ou des unités de calcul,
- la température de la ou des unités de calcul,
- le nombre de réussites et/ou d’erreurs de prédiction de l’unité de prédiction de branchement,
- le nombre d’accès aux mémoires,
- le nombre de réussites et/ou d’erreurs de sollicitations de la mémoire cache,
- le nombre de réussites et/ou d’erreurs de sollicitations de l’unité de protection mémoire,
- le temps d’exécution d’une instruction dans la chaîne de traitement,
- le nombre d’échanges d’informations sur le ou les réseaux d’interconnexions interne du processeur,
- le nombre d’échanges d’information via le ou les réseaux d’interconnexion par source,
- le nombre d’échanges d’information via le ou les réseaux d’interconnexion par destination, et
- le nombre d’échanges d’informations via l’unité d'entrée-sortie.
- l’exécution de l’application est mise en œuvre selon au moins deux phases temporelles successives, l’étape de traitement étant mise en œuvre par application d’opérations respectives sur les mesures de chaque phase
- l’application est configurée pour mettre en œuvre au moins deux fonctions, chaque fonction étant mise en œuvre durant une phase temporelle propre.
- chaque phase temporelle correspond à un intervalle de temps prédéterminé d’exécution de l’application, notamment un intervalle de temps inférieur à 300 millisecondes.
- l’étape de traitement comprend une agrégation des mesures pour chaque paramètre de fonctionnement pour obtenir une base de données propre à chaque paramètre de fonctionnement.
- l’ensemble de mesures et l’ensemble des données traitées occupent une taille respective sur une mémoire, l’étape de traitement comprenant l’application d’une opération permettant que la taille de l’ensemble des données traitées soit inférieure à la taille de l’ensemble de mesures.
- l’opération est mise en œuvre par une technique d’apprentissage automatique comprenant un entraînement à partir de l’ensemble de mesures.
- la technique d’apprentissage automatique comprend l’entraînement d’un réseau de neurones à partir de l’ensemble de mesures.
- l’opération est une opération d’analyse statistique telle que l’ensemble des données traitées est une distribution statistique de l’ensemble de mesures.
- un nombre prédéterminé d’itérations de l’étape de mesure est mis en œuvre afin d’obtenir un premier ensemble de mesures et un premier ensemble de données traitées, le procédé de génération comprenant, en outre, les étapes suivantes :
- deuxième mise œuvre du nombre prédéterminé d’itérations de l’étape de mesure pour obtenir un deuxième ensemble de mesures et un deuxième ensemble de données traitées,
- comparaison du premier ensemble de données traitées et du deuxième ensemble de données traitées en fonction d’un critère de convergence prédéterminé,
- lorsque le critère de convergence n’est pas respecté, mise en œuvre d’un nombre d’itérations de l’étape de mesure supérieur au nombre d’itérations prédéterminé, et
- lorsque le critère de convergence est respecté, génération du jeu de référence à partir des premier et deuxième ensembles de données traitées.
L’invention concerne également un jeu de référence susceptible d’être obtenu par un procédé de génération tel que défini ci-dessus.
L’invention concerne également l’utilisation du jeu de référence tel que défini ci-dessus pour détecter une anomalie dans le système électronique en fonctionnement, en particulier une attaque informatique contre le système électronique, par comparaison d’au moins une mesure d’au moins l’un des paramètres de fonctionnement lors du fonctionnement du système électronique et par comparaison de ladite mesure avec le jeu de référence pour détecter d’éventuelles incohérences entre la mesure et ledit jeu de référence.
L’invention concerne également un produit programme d’ordinateur comportant un support lisible d’informations, sur lequel est mémorisé un programme d’ordinateur comprenant des instructions de programme, le programme d’ordinateur étant chargeable sur une unité de traitement de données et adapté pour entraîner la mise en œuvre d’un procédé de génération tel que défini ci-dessus lorsque le programme d’ordinateur est mis en œuvre sur l’unité de traitement des données.
L’invention concerne également un support lisible d’informations sur lequel est mémorisé un programme d’ordinateur comprenant des instructions de programme, le programme d’ordinateur étant chargeable sur une unité de traitement de données et adapté pour entraîner la mise en œuvre d’un procédé de génération tel que défini ci-dessus lorsque le programme d’ordinateur est mis en œuvre sur l’unité de traitement des données.
L’invention sera mieux comprise à l’aide de la description qui va suivre, donnée uniquement à titre d’exemple non limitatif et faite en se référant aux dessins annexés, sur lesquels :
La représente un système électronique 10.
Le système électronique 10 est embarqué dans une plateforme de transport 12. La plateforme de transport 12 est notamment propre à transporter des passagers et/ou des marchandises.
La plateforme de transport 12 est, en particulier, une plateforme de transport avionique telle qu’un avion, un hélicoptère ou un drone.
En variante, la plateforme de transport 12 est une plateforme de transport spatiale comme par exemple un satellite ou une navette spatiale ; une plateforme de transport ferroviaire, notamment un train ; une plateforme de transport maritime telle qu’un navire ou un sous-marin ou une plateforme de transport automobile comme par exemple une voiture autonome ou un bus.
En variante encore, l’invention s’applique à tout domaine dans lequel sont présents des calculateurs embarqués critiques. Notamment, en variante, le système électronique 10 est embarqué dans un dispositif médical, dans un ordinateur portatif, dans un système domotique ou dans un système industriel.
La plateforme 12 comprend éventuellement une pluralité de systèmes électroniques 10. Par exemple, lorsque la plateforme de transport 12 est un aéronef, la plateforme comprend un système de décollage, un système de pilotage, un système de communication, un système d’alerte, etc.
Comme visible sur la , le système électronique 10 comprend un ou plusieurs processeurs 14, un système d’exploitation 16 et une mémoire 18.
Le système d'exploitation 16 (souvent appelé OS de l'anglais « Operating System ») est un ensemble de programmes qui dirige l'utilisation des ressources du système électronique 10 par des applications.
Chaque processeur 14 est composé d’une pluralité de blocs matériels.
Les blocs matériels comprennent des blocs matériels d’exécution 20 et des blocs matériels de comptage 22.
Un bloc matériel d’exécution 20 est un composant électronique configuré pour exécuter une fonction élémentaire du processeur 14 telle que le calcul, le stockage mémoire ou le transfert de données.
En particulier, le processeur 14 est adapté pour exécuter au moins une application par interactions de l’application avec les blocs matériels d’exécution 20.
L’application est un programme propre à réaliser une tâche, ou un ensemble de tâches élémentaires. L’application s'exécute en utilisant les services du système d'exploitation pour utiliser les ressources matérielles fournies par les blocs matériels d’exécution 20.
En particulier, chaque bloc matériel d’exécution 20 est choisi parmi le groupe constitué de :
- une ou plusieurs unités de calcul,
- une ou plusieurs unités de prédiction de branchement,
- un ou plusieurs registres de mémoire interne du processeur 14,
- une ou plusieurs mémoires caches,
- une ou plusieurs mémoires vives,
- une ou plusieurs chaînes de traitement,
- une ou plusieurs unités de protection mémoire ou de traduction d’adresse,
- un ou plusieurs bus ou réseaux d’interconnexion, et
- une ou plusieurs unités d'entrée-sortie.
Ces différents blocs matériels d’exécution 20 permettent de fournir les ressources matérielles nécessaires à l’exécution des différentes applications.
Chaque bloc matériel de comptage 22 est adapté pour mesurer un paramètre de fonctionnement représentatif des interactions de l’application avec l’un des blocs matériels d’exécution 20 avec l’application pour obtenir des mesures dudit paramètre représentatif.
Avantageusement, le système électronique 10 comprend une pluralité de blocs matériels de comptage 22 propres à mesurer chacun un paramètre de fonctionnement propre.
Le système électronique 10 comprend notamment entre quatre et six blocs matériels de comptage 22.
En variante, le système électronique 10 comprend plus de six blocs matériels de comptage 22.
Chaque paramètre représentatif associé à l’un des blocs matériel d’exécution 20 est choisi parmi le groupe constitué de :
- le type de données traitées par le bloc matériel d’exécution 20 ;
- le type d’instructions exécutées par le bloc matériel d’exécution 20;
- le nombre d’accès au bloc matériel d’exécution 20;
- le nombre de calcul exécutés et/ou le temps de calcul du bloc matériel d’exécution 20;
- le nombre de dysfonctionnements du bloc matériel d’exécution 20, et
- le nombre d’interactions sur un réseau d’interconnexion interne au processeur impliquant le bloc matériel d’exécution 20, et
- le nombre d’interactions avec l’extérieur du processeur 14 par le bloc matériel d’exécution 20.
Les différents types de données sont par exemple un type booléen, un type entier, un type réel à virgule flottante, un type caractère, etc.
Les différentes instructions sont par exemple une instruction de calcul, une instruction d’envoi de données, une instruction de mise en mémoire, etc.
Chaque réseau d’interconnexion interne du processeur 14 forme une passerelle permettant la communication entre différentes entités du processeur, notamment entre les différents blocs matériels.
Plus spécifiquement, chaque paramètre représentatif du fonctionnement de l’un des blocs matériels d’exécution 20 est choisi parmi le groupe constitué de :
- le nombre de données d’un même type traitées par la ou les unités de calcul, le ou les réseaux d’interconnexion ou la ou les mémoires,
- le nombre d’instructions d’un même type exécutées par la ou les unités de calcul,
- la consommation d’énergie de la ou des unités de calcul,
- la température de la ou des unités de calcul,
- le nombre de réussites et/ou d’erreurs de prédiction de l’unité de prédiction de branchement,
- le nombre d’accès aux mémoires,
- le nombre de réussites et/ou d’erreurs de sollicitations de la mémoire cache,
- le nombre de réussites et/ou d’erreurs de sollicitations de l’unité de protection mémoire,
- le temps d’exécution d’une instruction dans la chaîne de traitement,
- le nombre d’échanges d’information via le ou les réseaux d’interconnexion interne(s) au processeur 14,
- le nombre d’échanges d’information via le ou les réseaux d’interconnexion interne(s) obtenus par une source donnée,
- le nombre d’échanges d’information via le ou les réseaux d’interconnexion interne(s) envoyés à une destination donnée, et
- le nombre d’échanges d’informations via l’unité d'entrée-sortie.
La mémoire 18 stocke un ensemble de données de référence, ou aussi appelé jeu de référence par la suite.
L’ensemble de données de référence est représentatif du fonctionnement du système électronique 10 sans anomalies.
On entend par « fonctionnement sans anomalies », un fonctionnement du système électronique 10 tel que prévu et envisagé lors de sa conception et de son exploitation. Un fonctionnement anormal est donc un fonctionnement s’écartant de ce qui était envisagé durant l’exploitation du système électronique 10, dû par exemple à une attaque informatique ou à une défaillance matérielle et/ou logicielle. En particulier, il est défini une marge de fonctionnement sans anomalie autour des valeurs de fonctionnement prévues lors de la conception du système. A titre d’exemple, un intervalle de température de fonctionnement sans anomalies des unités de calcul est déterminé à la conception. Un fonctionnement anormal est détecté quand la température est par exemple 10°C plus chaud que la borne maximale de l’intervalle de fonctionnement sans anomalies.
Comme cela sera expliqué par la suite, l’ensemble de données de référence, ou jeu de référence, permet de détecter d’éventuelles incohérences entre la mesure d’un paramètre de fonctionnement et l’ensemble de données de référence.
Un procédé de génération 100 d’un tel jeu de référence va maintenant être décrit, en référence à la représentant un organigramme dudit procédé de génération 100.
Le procédé de génération 100 comprend une étape d’exécution 120 de l’application A sur un banc de test en fonction d’une pluralité de données d’entrée E prédéterminées.
On entend par banc de test, un environnement d’essais permettant de mettre le système électronique 10 en conditions d'utilisation paramétrables et contrôlées afin d'observer et mesurer son comportement. L’exécution sur banc de test est donc différente de l’utilisation opérationnelle en exploitation par la suite du système électronique 10.
Les données d’entrée E sont représentatives du fonctionnement en exploitation du système électronique 10 sans anomalies.
Ces données d’entrées E sont déterminées en fonction de l’utilisation envisagée pour le système électronique 10 en exploitation. Le retour d’expérience issu de l’exploitation de systèmes électroniques semblables est également utilisé. Ces données d’entrées sont choisies afin de couvrir une grande variété d'évènements susceptibles d’être rencontrés par le système électronique 10 lors de son exploitation en fonctionnement normal, sans anomalies.
L’application A est configurée pour mettre en œuvre au moins deux fonctions, chaque fonction étant mise en œuvre durant une phase P temporelle propre.
A titre d’exemple, l’application A comprend une phase initiale d’acquisition des données, une phase de traitement des données, une phase de mise en mémoire et une phase d’envoi des données.
Ainsi, l’exécution de l’application A est mise en œuvre selon au moins deux phases P temporelles successives.
Le procédé de génération 100 comprend donc une étape préalable de découpage 110 en phases P de l’application A.
En effet, comme cela sera expliqué plus en détail par la suite, un traitement global de l'ensemble d'une application dont le comportement varierait significativement au cours de l'exécution de l’application risquerait d’entraîner la création d’un jeu de référence insuffisamment sélectif, ce qui rendrait difficile la détection de comportements anormaux.
Selon le type d'application, le découpage est un découpage temporel ou un découpage fonctionnel.
En particulier, la présente un arbre de décision permettant de choisir le type de découpage de l’application A.
Ainsi, le découpage temporel est choisi lorsque le code source de l’application A n’est pas connu ou maitrisé et que l’identification des phases n’est pas aisée.
A l’inverse, quand le code source est maîtrisé et que le comportement de l’application A n’est pas dépendant des données d’entrées, il est possible d’identifier des phases P de l’application A et le découpage fonctionnel sera privilégié.
En effet, la réalisation d’un découpage fonctionnel et une identification des phases P comportementales d’une application requiert une certaine maîtrise de l’application, ce qui n’est pas toujours le cas lorsque l’on intègre des applications tierces. Dans ce contexte « boîte-noire », des solutions de profilage classique (comme par exemple en utilisant le logiciel connu Gprof) ou d’analyse statique de code peuvent aider à identifier les phases applicatives, et permettre un tel découpage fonctionnel. Ce profilage recherche notamment les boucles régulières, c’est-à-dire des ensembles d’instructions dont les conditionnelles et les bornes de boucles peuvent s’exprimer sous la forme de fonctions affines des itérateurs englobants.
Toutefois, si le comportement de l’application A dépend fortement des données, comme cela peut être le cas par exemple pour des applications de cryptographie, un découpage fonctionnel comportemental n’est pas possible, car non répétable d’une exécution à l’autre.
Dans ce cas, le découpage est un découpage temporel qui requiert une étape supplémentaire de sélection de la fréquence d’échantillonnage.
Ce choix a un impact sur le nombre total de phases P et est déterminé en cherchant un compromis entre la finesse de la caractérisation de ces phases et la taille du jeu de référence obtenu.
Par exemple, dans le cadre des applications embarquées périodiques, le découpage est effectué sur la base de cette période.
Toutefois, si l’activation d’une tâche est elle-même composée de phases comme par exemple une phase de récupération des données, une phase de calcul et une phase de fourniture du résultat, la fréquence d’échantillonnage est plus importante.
En particulier, chaque phase P temporelle correspond à un intervalle de temps prédéterminé d’exécution de l’application, notamment un intervalle de temps inférieur à 300 millisecondes, typiquement 200 millisecondes.
Le procédé de génération 100 comprend une étape de mesures 130 par au moins l’un des blocs matériels de comptage 22 d’au moins un paramètre de fonctionnement représentatif des interactions de l’un des blocs matériels d’exécution 20 lors de l’étape d’exécution avec l’application, pour obtenir des mesures. Les mesures obtenues sont donc des mesures d’une pluralité de paramètres de fonctionnement tels que définis ci-dessus.
La illustre notamment cette étape de mesures 130.
Ces mesures sont réalisées phase par phase afin d’obtenir un ensemble de mesures des paramètres de fonctionnement par phase.
Au moins une nouvelle itération I des étapes du procédé de génération 100 est mise en œuvre, l’étape de mesures 130 d’une itération étant mise en œuvre par au moins un bloc matériel de comptage 22 différent de l’au moins un bloc matériel de comptage 22 mettant en œuvre l’étape de mesures d’une autre itération I.
Un ensemble de blocs matériels de comptage 22 mesurant les paramètres de fonctionnement lors d’une itération I est appelé configuration C des blocs matériels de comptage 22.
Comme expliqué ci-dessus, il n’est pas possible de déterminera prioriquels événements matériels seront visés et donc sollicités par les éventuelles futures attaques informatiques, et ne disposant que d'un nombre de blocs matériels de comptage 22 réduit par rapport au grand nombre d'événements, il est donc intéressant de parcourir équitablement l'ensemble des événements matériels et de varier les configurations des blocs matériels de comptage 22.
De manière à collecter des données statistiquement significatives, l’application A est exécutée sur un nombre important d'itérations I, avec des données d’entrées différentes, pour capturer des distributions des valeurs possibles des différents paramètres de fonctionnement en fonctionnement nominal.
Le procédé de génération 100 comprend alors une étape de traitement 140 des mesures des paramètres de fonctionnement, pour obtenir des données traitées.
En particulier, l’étape de traitement 140 est mise en œuvre par application d’opérations respectives sur les mesures de chaque phase.
L’étape de traitement 140 comprend notamment une agrégation des mesures pour chaque paramètre de fonctionnement pour obtenir une base de données propre à chaque paramètre de fonctionnement.
En particulier, le traitement 140 comprend une agrégation des mesures par phase P, des mesures par configuration C, et des mesures par itération I pour obtenir un ensemble des données statistiques collectées. À la fin de chacune de ces étapes, les valeurs collectées sont agrégées comme suit.
Lors d’une phase, l’ensemble des couples (évènement, valeur) sont collectés tel que l’évènement appartienne à la configuration de blocs matériels de comptage 22 courante.
L’agrégation par phase P consiste à regrouper dans un tableau indexé par phase l’ensemble des valeurs mesurées.
L’agrégation par configuration C étend l’ensemble des évènements au-delà de la configuration courante pour couvrir l’ensemble des configurations nécessaire pour couvrir tous les évènements matériels envisagés en fonctionnement normal.
L’agrégation par itération I diffère de l’agrégation précédente en remplaçant les couples (évènement, valeur) par des couples (évènement, ensemble des valeurs observées au cours des différentes itérations).
L’ensemble des mesures collectées pour l’application A est susceptible d’être ainsi très important et représenter typiquement plusieurs giga-octets de données collectées.
Il est alors utile de faire une réduction de ces données pour obtenir un jeu de référence J de taille réduite, intégrable dans la mémoire 18 du système électronique 10.
L’étape de traitement 140 comprend alors l’application d’une opération permettant que la taille en mémoire de l’ensemble des données traitées soit inférieure à la taille en mémoire de l’ensemble de mesures.
En particulier, l’opération est mise en œuvre par une technique d’apprentissage automatique comprenant un entraînement à partir de l’ensemble de mesures.
La technique d’apprentissage automatique est notamment implémentée par l’entraînement d’un réseau de neurones à partir de l’ensemble de mesures. Le jeu de référence deviendrait alors ce réseau une fois entrainé. Des techniques d’apprentissage symbolique ou de segmentation sont utilisées en variante.
En variante, l’opération de réduction est une opération d’analyse statistique telle que l’ensemble des données traitées est une distribution statistique de l’ensemble de mesures.
Cette opération est similaire à celle couramment réalisée pour permettre la visualisation des données statistiques avec des histogrammes ou des boîtes à moustaches pas exemple.
La distribution statistique comprend une pluralité de valeurs donnant des informations clefs sur la distribution statistique telles que le minimum, le maximum, la moyenne, la médiane, l’écart-type, des déciles, des quartiles, etc. Par exemple, ces valeurs sont les différents intervalles (« bins » en anglais) d’un histogramme ou les quartiles pour les boîtes à moustaches.
Cette pluralité de valeurs devient alors le jeu de référence J.
Il est donc nécessaire de réduire la taille des données collectées mais il est également important de s’assurer que les données collectées sont statistiquement représentatives de l’application. Il est ainsi nécessaire d’évaluer la couverture statistique des données collectées.
Ainsi, un nombre prédéterminé d’itérations de l’étape de mesure 130 est mis en œuvre afin d’obtenir un premier ensemble de mesures et un premier ensemble de données traitées.
Le procédé de génération 100 comprend alors en outre une deuxième mise œuvre du nombre prédéterminé d’itérations de l’étape de mesure 130 pour obtenir un deuxième ensemble de mesures et un deuxième ensemble de données traitées.
Puis, le premier ensemble de données traitées est comparé au deuxième ensemble de données traitées en fonction d’un critère de convergence prédéterminé.
Le critère de convergence permet de déterminer si ces deux distributions sont statistiquement similaires. La littérature propose différentes solutions à ce problème comme par exemple la comparaison d’histogrammes en calculant la distance de Bhattacharyya, la divergence de Kullback-Leiber ou la distance de Hellinger.
Lorsque le critère de convergence n’est pas respecté, le procédé de génération 100 comprend la mise en œuvre d’un nombre d’itérations de l’étape de mesure 130 supérieur au nombre d’itérations prédéterminé.
Autrement dit, les deux distributions statistiques collectées sont concaténées et on réitère la collection d’une distribution de taille supérieure, par exemple d’une taille double.
Cette étape est réitérée jusqu’à obtenir une convergence de la distribution statistique.
Lorsque le critère de convergence est respecté, le procédé de génération 100 comprend la génération du jeu de référence J à partir des premier et deuxième ensembles des données traitées.
On obtient ainsi un jeu de référence J à partir des données traitées. Comme cela sera expliqué par la suite, ce jeu de référence est notamment utilisé pour détecter une anomalie dans le système électronique 10 en fonctionnement, en particulier une attaque informatique contre le système électronique 10, par comparaison d’au moins une mesure d’au moins l’un des paramètres de fonctionnement lors du fonctionnement du système électronique 10 et par comparaison de ladite mesure avec le jeu de référence pour détecter d’éventuelles incohérences entre la mesure et le jeu de référence.
Toutefois, d’autres applications du jeu de référence J ainsi généré sont possibles.
En effet, dans les domaines critiques tels que l'automobile, le ferroviaire, l'avionique ou le spatial, la tendance actuelle des systèmes électronique/informatiques embarqués est de s’orienter vers l’utilisation de plateformes de calcul génériques assurant à la fois la fonctionnalité et les propriétés de sûreté de fonctionnement et de sécurité.
Ces plateformes de calcul possèdent un ensemble de ressources matérielles limitées et doivent exécuter un ou plusieurs logiciels applicatifs, de niveaux de criticité différents et provenant de fournisseurs différents.
La complexité des nouveaux systèmes embarqués pour les domaines critiques et le partage du marché entre les différents acteurs économiques a nécessité la modification du processus industriel en redéfinissant les rôles et responsabilités entre les différents intervenants lors de la conception d’un système. Chacun de ces acteurs est responsable de fournir les briques technologiques qui lui sont attribuées et d’appliquer les contraintes qui lui sont imposées par les exigences de fonctionnement du système.
Le fournisseur de plateforme matérielle livre le calculateur ainsi que toute l’électronique nécessaire au bon fonctionnement des applications logicielles qui seront susceptibles de lui être attribuées.
Le fournisseur du système d’exploitation fournit le système d’exploitation qui va permettre d’assurer la gestion de l’exécution des différents logiciels applicatifs en fonction de leurs besoins en terme de priorité, de temps et de fréquence d’exécution, d’espace mémoire, etc.
Le fournisseur de logiciels applicatifs est responsable du bon fonctionnement de ses applications tout en respectant les consignes fournies par l’intégrateur du système concernant les règles d’utilisation des ressources matérielles du système.
Enfin, l’intégrateur système se voit confier le rôle central. Il assemble les différentes briques technologiques, à la fois matérielles et logicielles du système tout en allouant l’ensemble des ressources nécessaires aux fournisseurs des applications logicielles. De plus, il est responsable de la consolidation des exigences de fonctionnement et de la prise en compte des interactions des différentes briques technologiques vis-à-vis des ressources du système. Il est celui qui doit garantir la sureté de fonctionnement et sécurité globale du système.
La maitrise du système implique tous les participants chacun à son niveau de responsabilité mais c’est à l’intégrateur système qu’incombe la définition et la validation de l’ensemble du système en cours de construction en s’assurant que les applications s’exécutant sur les plateformes de calcul du système respectent à tout instant les spécifications non fonctionnelles tels que le temps, l’énergie et le partage des ressources nécessaire au calcul, la sûreté, la sécurité, etc.
Dans ce contexte, le jeu de référence J est avantageusement utilisé pour transmettre les exigences de l’intégrateur système vers les autres acteurs et la transmission des propriétés non-fonctionnelles des applications vers l’intégrateur comme le besoin effectif en termes de ressources matérielles partagées.
En effet, en fournissant avec son application le jeu de référence correspondant, le fournisseur de logiciel fournit bien des informations liées à l’utilisation des ressources matérielles par son application, et donc un taux d’utilisation des différentes ressources partagées.
Le jeu de référence J est également un moyen pour l’intégrateur système de traduire ses exigences sous forme d’une enveloppe maximale d’utilisation des ressources pour chaque application, de manière à garantir leur coexistence dans de système intégré final.
Le jeu de référence J représentant le comportement matériel des applications a donc plusieurs domaines d’applicabilité.
Le jeu de référence J peut être utilisé dans un cadre cyber-sécurité, comme cela sera expliqué par la suite, pour se prémunir de cyber-attaques externes.
Dans un cadre sûreté de fonctionnement, le jeu de référence J peut être également utilisé pour participer à la surveillance du système, détecter les cas anormaux liés aux défaillances et déclencher les mesures visant à un retour à un état stable.
Le jeu de référence J peut être également utilisé comme moyen de transmission des exigences non-fonctionnelles. En effet, dans le cadre des processeurs multi-cœurs, eux-mêmes des systèmes complexes provenant de fournisseurs tiers et possédant le plus souvent des spécifications partielles, la technique usuelle du partitionnement temporel est devenue insuffisante.
Le jeu de référence J peut être également utilisé pour faciliter l’intégration des applications en prenant en compte leur spécificité d’utilisations des ressources matérielles partagées. La technique usuelle se basant sur des modèles abstraits n’étant plus adaptée aux multi-cœurs.
Le jeu de référence J peut être également utilisé pour construire une bibliothèque d’applications représentatives d’un domaine en les caractérisant via la distance entre leurs jeux de référence respectifs.
Dans un cadre de certification incrémentale, le jeu de référence J peut être également utilisé pour anticiper l’impact de l’intégration d’une nouvelle application dans le système connaissant son jeu de référence.
Un procédé de détection 200 d’une anomalie dans un système électronique 10 en fonctionnement va maintenant être décrit en référence à la représentant un organigramme dudit programme de détection 200.
Le procédé de détection 200 est réalisé en utilisant un jeu de référence tel que généré ci-dessus.
En particulier, le procédé 200 vise à détecter une attaque informatique contre le système électronique 10.
Toutefois, le procédé de détection 200 est également propre à détecter une défaillance matérielle et/ou logicielle du système électronique 10.
Plusieurs modes de réalisation sont possibles pour la mise en œuvre du procédé de détection, comme illustré sur la .
Selon un premier mode de réalisation, le procédé de détection est mis en œuvre par un circuit logique programmable dédié formant l’un desdits blocs matériels d’exécution 20 du processeur 14.
Ainsi, cette mise en œuvre est réalisée au niveau matériel sous forme d'un composant dédié, comme représenté schématiquement sur la avec la référence numérique 1. Ce composant pourrait ainsi reprogrammer et exploiter les blocs matériels de comptage 22 sans se soucier des niveaux de privilèges nécessaires au niveau logiciel. Un composant matériel permet également de disposer facilement d'une mémoire dédiée pour stocker les jeux de référence au sein même du composant.
Ce mode de réalisation offre donc une solution hautement sécurisée.
Selon un deuxième mode de réalisation, le procédé de détection est mis en œuvre par un logiciel d’un système d’exploitation 16 du système électronique 10 configuré pour interagir avec une mémoire protégée par une unité de protection mémoire.
Ce mode de réalisation est représenté schématiquement sur la avec la référence numérique 2.
Dans ce cas, le jeu de référence est stocké au niveau de la mémoire principale. Le logiciel bénéficiera des niveaux de privilège élevés du système d'exploitation pour configurer et lire les blocs matériels de comptage 22. La zone de stockage des jeux de références est protégée via l’unité de gestion mémoire (ou MMU de l’anglais « memory management unit »).
Selon un troisième mode de réalisation, le procédé de détection est mis en œuvre par une application propre à être mise en œuvre par le système électronique 10 par adjonction d’un pilote contrôlant les blocs matériels, comme représenté schématiquement sur la avec la référence numérique 3.
Ainsi, le procédé est mis en œuvre sous la forme d'une application tournant au même niveau que les applications à surveiller.
Ce mode de réalisation est le plus facile à implémenter.
En variante encore, le procédé de détection est mis en œuvre via une implémentation hybride, à la fois logicielle et matérielle, comme par exemple une réalisation au niveau logiciel qui stocke les jeux de référence dans une mémoire flash matérielle dédiée, pour protéger l’espace mémoire des jeux de références.
Dans l’état initial du procédé de détection 200, le système électronique 10 est en fonctionnement opérationnel.
Par exemple, le système électronique 10 est embarqué dans un aéronef en train de voler à destination un aéroport. Le système électronique 10 est alors par exemple un système avionique de communication, de pilotage, etc.
Le procédé de détection 200 comprend une première étape de mesure 210, lors du fonctionnement du système électronique 10, d’au moins un paramètre représentatif des interactions de l’application A avec l’un des blocs matériels d’exécution 20 pour obtenir des mesures dudit paramètre représentatif.
Les paramètres représentatifs sont tels que définis ci-dessus. Ils correspondent en particulier à ceux pour lesquels des mesures ont été effectuées lors du procédé de génération du jeu de référence associé.
Pour chaque mesure, le procédé de détection 200 comprend la comparaison 220 de la mesure avec l’ensemble de données de référence associé, ou jeu de référence, pour détecter d’éventuelles incohérences entre la mesure et l’ensemble de données de référence.
Une incohérence est un écart statistique de la mesure par rapport au jeu de référence. Par exemple, la mesure n’est pas comprise dans l’enveloppe formée par le jeu de référence.
Tout écart indique un comportement anormal de l’application qui pourrait être lié à une cyber-attaque.
Ainsi, le procédé de détection 200 comprend une étape d’émission 230 d’une alerte W selon un critère d’alerte portant sur la ou les incohérences détectées.
Chaque critère d’alerte dépend d’au moins une condition sur les paramètres représentatifs. Chaque critère d’alerte est par exemple une valeur seuil du paramètre mesuré.
Lors de la phase de génération 100 du jeu de référence J, il est possible de construire un jeu de référence exhaustif, au prix de nombreuses exécutions de l'application, avec un jeu d'événements différents. Au contraire, lors de la phase de détection 200, il n’est pas possible d'exécuter plusieurs fois l’application dans le but de détecter une attaque. La détection doit avoir lieu directement, lors de l'exécution.
Ainsi, seul un nombre limité de paramètres est mesuré à partir de blocs matériels de comptage 22 afin de minimiser le temps de détection.
Selon un mode de réalisation, les paramètres mesurés sont alternés rapidement afin de couvrir dans une courte période de temps l'ensemble des événements significatifs par échantillonnage.
En variante, les paramètres mesurés sont choisis au moyen d’une sélection hiérarchique des événements surveillés.
Lorsqu’au moins une alerte W associée à l’un des blocs matériels d’exécution 20 est émise, une nouvelle itération des étapes du procédé de détection 200 à partir de l’étape de mesure 210 est mise en œuvre.
L’ensemble des blocs matériels d’exécution 20 dont une mesure de paramètre représentatif est effectuée étant, à chaque itération, inclus dans l’ensemble des blocs matériels d’exécution 20 de la précédente itération, l’ensemble des blocs matériels d’exécution 20 étant notamment inclus dans l’ensemble des blocs matériels d’exécution 20 associés à la ou les alertes.
Ainsi, un petit nombre d'événements est choisi, correspondant au nombre de blocs matériels de comptage 22 disponibles et couvrant les différents blocs matériels d’exécution 20 du processeur 14, afin de constituer un premier niveau de surveillance.
En cas de dépassement d'un ou plusieurs de ces événements par rapport à des seuils issus du jeu de référence, une suspicion d'attaque est levée et les paramètres mesurés sont reconfigurés pour se focaliser sur le bloc matériel d’exécution 20 concerné afin de confirmer ou infirmer la suspicion.
Les étapes de mesure 210 sont ainsi répétées avantageusement sur plusieurs niveaux hiérarchiques. Cette méthode permet d'améliorer la fiabilité de la détection malgré le nombre limité de blocs matériels de comptage 22.
Le procédé de détection 200 comprend, lorsqu’une alerte W associée à l’un des blocs matériels d’exécution 20 est émise, une nouvelle itération des étapes du procédé de détection 200 à partir de l’étape de mesure 210, le critère d’alerte comprenant, à chaque itération, un nombre croissant de conditions.
Ainsi, il est possible d’affiner l’alerte et de caractériser plus précisément la suspicion d’attaque.
Par exemple, une première condition d’alerte est le dépassement d’un seuil d’accès mémoire d’un bloc matériel. A la prochaine itération, la condition d’alerte comprend en plus de ce seuil, le dépassement d’un seuil de calculs exécutés par ce bloc matériel.
Le procédé 200 comprend ensuite l’analyse 240 de la nature du bloc matériel d’exécution 20 associé à chaque incohérence, l’analyse de la fréquence temporelle des incohérences, et/ou l’analyse de l’écart de chaque mesure associée aux incohérences à l’ensemble de données de référence.
Le procédé de détection 200 comprend alors une étape de détection 250, en fonction de la ou chaque analyse d’une anomalie, en particulier une attaque informatique ou une défaillance matérielle de l’un des blocs matériels.
En effet, en fonction de la fréquence, du type et de la gravité des évènements anormaux, il est possible de distinguer une attaque informatique d’une défaillance matérielle. En particulier, les évènements transitoires liés à la sûreté de fonctionnement sont essentiellement ponctuels, et se traduisent au niveau des blocs matériels de comptage 22 par un pic.
Les évènements liés à la cyber-sécurité au contraire durent le temps de l'attaque, et les attaques ont généralement un effet plus durable sur les blocs matériels de comptage 22.
En comparant l’incohérence associée à l’alerte émise avec un ensemble d’anomalies connues prédéterminées, le procédé comprend la catégorisation de l’alerte lorsque la ou chaque incohérence correspond à l’une des anomalies connues dudit ensemble d’anomalies.
Il est ainsi possible de connaitre la nature de l’anomalie rencontrée, notamment le type d’attaque informatique, et de réagir en fonction.
Toutefois, le procédé de détection 200 ne dépend pas du type d'attaque. Le procédé permet de détecter également des nouvelles classes d'attaques ciblant le matériel ou le logiciel.
Finalement, lors du vieillissement des composants, la fréquence des évènements transitoires augmente progressivement jusqu’à une défaillance permanente. Le procédé de détection, via cette analyse, permet d’observer cette variation de fréquence, pour participer à la maintenance préventive des composants et prévenir ce type de défaillances.
Claims (14)
- Procédé de détection (200) d’une anomalie dans un système électronique (10) en fonctionnement, en particulier une attaque informatique contre le système électronique (10), le système électronique (10) comprenant un ou plusieurs processeurs (14) composés chacun d’une pluralité de blocs matériels (20, 22), le processeur (14) étant adapté pour exécuter au moins une application (A) par interactions de l’application (A) avec lesdits blocs matériels (20), le procédé de détection (200) comprenant au moins les étapes suivantes :
- mesure (210), lors du fonctionnement du système électronique (10), d’au moins un paramètre représentatif des interactions de l’application (A) avec l’un des blocs matériels (20) pour obtenir des mesures dudit paramètre représentatif,
- pour chaque mesure, comparaison (220) de ladite mesure avec un ensemble de données de référence (J) associé pour détecter d’éventuelles incohérences entre la mesure et l’ensemble de données de référence (J), ledit ensemble de données de référence (J) étant représentatif du fonctionnement du système électronique (10) sans anomalies, et
- émission (230) d’une alerte (W) selon un critère d’alerte portant sur la ou les incohérences détectées.
- Procédé de détection (200) selon la revendication 1, dans lequel le procédé de détection (200) comprend, en outre, au moins une étape choisie parmi le groupe constitué de :
- analyse (240) de la nature du bloc matériel (20) associé à chaque incohérence,
- analyse (240) de la fréquence temporelle des incohérences, et
- analyse (240) de l’écart de chaque mesure associée aux incohérences à l’ensemble de données de référence (J) ;
- Procédé de détection (200) selon la revendication 1 ou 2, dans lequel lorsqu’au moins une alerte (W) associée à l’un des blocs matériels (20) est émise, une nouvelle itération des étapes du procédé de détection (200) à partir de l’étape de mesure (210) est mise en œuvre, l’ensemble des blocs matériels (20) dont une mesure de paramètre représentatif est effectuée étant, à chaque itération, inclus dans l’ensemble des blocs matériels (20) de la précédente itération, l’ensemble des blocs matériels (20) étant notamment inclus dans l’ensemble des blocs matériels (20) associés à la ou les alertes (W).
- Procédé de détection (200) selon l’une quelconque des revendications 1 à 3, dans lequel chaque critère d’alerte dépend d’au moins une condition sur les paramètres représentatifs, le procédé de détection (200) comprenant, lorsqu’une alerte (W) associée à l’un des blocs matériels (20) est émise, une nouvelle itération des étapes du procédé de détection (200) à partir de l’étape de mesure (210), le critère d’alerte comprenant, à chaque itération, un nombre croissant de conditions.
- Procédé de détection (200) selon l’une quelconque des revendications 1 à 4, dans lequel chaque paramètre représentatif associé à l’un des blocs matériel (20) est choisi parmi le groupe constitué de :
- le type de données traitées par le bloc matériel (20);
- le type d’instructions exécutées par le bloc matériel (20);
- le nombre d’accès au bloc matériel (20);
- le nombre de calcul exécutés et/ou le temps de calcul du bloc matériel (20);
- le nombre de dysfonctionnements du bloc matériel(20), et
- le nombre d’interactions sur un réseau d’interconnexion interne au processeur (14) impliquant le bloc matériel (20), et
- le nombre d’interactions avec l’extérieur du processeur par le bloc matériel (20).
- Procédé de détection (200) selon l’une quelconque des revendications 1 à 5, dans lequel chaque bloc matériel (20) est choisi parmi le groupe constitué de :
- une ou plusieurs unités de calcul,
- une ou plusieurs unités de prédiction de branchement,
- un ou plusieurs registres de mémoire interne du processeur,
- une ou plusieurs mémoires caches,
- une ou plusieurs mémoires vives,
- une ou plusieurs chaines de traitement,
- une ou plusieurs unités de protection mémoire ou de traduction d’adresse,
- un ou plusieurs bus ou réseaux d’interconnexion,
- une ou plusieurs unités d'entrée-sortie
- le nombre de données d’un même type traitées par la ou les unités de calcul, le ou les réseaux d’interconnexion ou la ou les mémoires,
- le nombre d’instructions d’un même type exécutées par la ou les unités de calcul,
- la consommation d’énergie de la ou des unités de calcul,
- la température de la ou des unités de calcul,
- le nombre de réussites et/ou d’erreurs de prédiction de l’unité de prédiction de branchement,
- le nombre d’accès aux mémoires,
- le nombre de réussites et/ou d’erreurs de sollicitations de la mémoire cache,
- le nombre de réussites et/ou d’erreurs de sollicitations de l’unité de protection mémoire,
- le temps d’exécution d’une instruction dans la chaine de traitement,
- le nombre d’échanges d’information via le ou les réseaux d’interconnexion interne(s) au processeur,
- le nombre d’échanges d’information via le ou les réseaux d’interconnexion obtenus par une source donnée,
- le nombre d’échanges d’information via le ou les réseaux d’interconnexion envoyés à une destination donnée, et
- le nombre d’échanges d’informations via l’unité d'entrée-sortie.
- Procédé de détection (200) selon l’une quelconque des revendications 1 à 6, dans lequel le système électronique (10) comprend une pluralité de blocs matériels de comptage (22) configurés chacun pour mesurer l’un des paramètres représentatifs, l’étape de mesure (210) comprenant la mesure d’une pluralité de paramètres représentatifs, notamment entre quatre et six, par exemple les paramètres représentatifs mesurés par une partie des blocs matériels de comptage (22).
- Procédé de détection (200) selon l’une quelconque des revendications 1 à 7, dans lequel le procédé de détection (200) comprend, en outre, une étape de :
- comparaison de la ou de chaque incohérence associée à l’alerte (W) émise avec un ensemble d’anomalies connues prédéterminées, et
- catégorisation de l’alerte (W) lorsque la ou chaque incohérence correspond à l’une des anomalies connues dudit ensemble d’anomalies.
- Procédé de détection (200) selon l’une quelconque des revendications 1 à 8, dans lequel le système électronique (10) est un calculateur embarqué dans une plateforme de transport (12).
- Procédé de détection (200) selon l’une quelconque des revendications 1 à 9, dans lequel le procédé de détection (200) est mis en œuvre par un système choisi dans le groupe constitué de :
- un circuit logique programmable dédié formant l’un desdits blocs matériels (20) du processeur ;
- un logiciel d’un système d’exploitation (16) du système électronique (10) configuré pour interagir avec une mémoire protégée par une unité de protection mémoire, et
- une application propre à être mise en œuvre par le système électronique (10) par adjonction d’un pilote contrôlant les blocs matériels (20).
- Produit programme d’ordinateur comportant un support lisible d’informations, sur lequel est mémorisé un programme d’ordinateur comprenant des instructions de programme, le programme d’ordinateur étant chargeable sur une unité de traitement de données et adapté pour entraîner la mise en œuvre d’un procédé de détection (200) selon l’une quelconque des revendications 1 à 10 lorsque le programme d’ordinateur est mis en œuvre sur l’unité de traitement des données.
- Support lisible d’informations sur lequel est mémorisé un produit programme d’ordinateur selon la revendication 11.
- Calculateur embarqué dans une plateforme de transport (12) configuré pour mettre en œuvre le procédé de détection (200) selon l’une quelconque des revendications 1 à 10, le système électronique étant le calculateur embarqué.
- Plateforme de transport (12) comprenant le calculateur selon la revendication 13.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2114743A FR3131647B1 (fr) | 2021-12-31 | 2021-12-31 | Procédé de détection d'une anomalie dans un système électronique en fonctionnement |
| PCT/EP2022/088064 WO2023126512A1 (fr) | 2021-12-31 | 2022-12-30 | Procédé de détection d'une anomalie dans un système électronique en fonctionnement |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2114743 | 2021-12-31 | ||
| FR2114743A FR3131647B1 (fr) | 2021-12-31 | 2021-12-31 | Procédé de détection d'une anomalie dans un système électronique en fonctionnement |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3131647A1 true FR3131647A1 (fr) | 2023-07-07 |
| FR3131647B1 FR3131647B1 (fr) | 2024-01-26 |
Family
ID=81648777
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR2114743A Active FR3131647B1 (fr) | 2021-12-31 | 2021-12-31 | Procédé de détection d'une anomalie dans un système électronique en fonctionnement |
Country Status (2)
| Country | Link |
|---|---|
| FR (1) | FR3131647B1 (fr) |
| WO (1) | WO2023126512A1 (fr) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR3103038B1 (fr) * | 2019-11-07 | 2021-11-19 | Thales Sa | Procede et dispositif electronique de surveillance d'une application logicielle avionique via des compteurs d'appel(s) systeme, programme d'ordinateur et systeme avionique associes |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20160328561A1 (en) * | 2015-05-08 | 2016-11-10 | Mcafee Inc. | Hardened event counters for anomaly detection |
| WO2021089357A1 (fr) * | 2019-11-07 | 2021-05-14 | Electricite De France | Detection d'attaques a l'aide de compteurs de performances materiels |
-
2021
- 2021-12-31 FR FR2114743A patent/FR3131647B1/fr active Active
-
2022
- 2022-12-30 WO PCT/EP2022/088064 patent/WO2023126512A1/fr unknown
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20160328561A1 (en) * | 2015-05-08 | 2016-11-10 | Mcafee Inc. | Hardened event counters for anomaly detection |
| WO2021089357A1 (fr) * | 2019-11-07 | 2021-05-14 | Electricite De France | Detection d'attaques a l'aide de compteurs de performances materiels |
Non-Patent Citations (2)
| Title |
|---|
| ALIÉNOR DAMIEN ET AL: "Anomaly Based Intrusion Detection for an Avionic Embedded System", 8 November 2018 (2018-11-08), Warrendale, PA, pages 1967646, XP055715503, Retrieved from the Internet <URL:https://hal.laas.fr/hal-01967646/document> [retrieved on 20190101], DOI: 10.4271/2018-01-1941 * |
| ZECHENG HE ET AL: "CloudShield: Real-time Anomaly Detection in the Cloud", ARXIV.ORG, CORNELL UNIVERSITY LIBRARY, 201 OLIN LIBRARY CORNELL UNIVERSITY ITHACA, NY 14853, 20 August 2021 (2021-08-20), XP091036846 * |
Also Published As
| Publication number | Publication date |
|---|---|
| FR3131647B1 (fr) | 2024-01-26 |
| WO2023126512A1 (fr) | 2023-07-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3156931B1 (fr) | Procédé de détection de vulnerabilités dans un serveur virtuel de production d'un système informatique virtuel ou en nuage | |
| KR20210099564A (ko) | 인공 지능을 이용한 보안 시스템 | |
| Ding et al. | DeepPower: Non-intrusive and deep learning-based detection of IoT malware using power side channels | |
| CN117056951B (zh) | 一种数字平台的数据安全管理方法 | |
| CN110678864A (zh) | 危害和取证数据的plc指标的收集 | |
| Taveras | SCADA live forensics: real time data acquisition process to detect, prevent or evaluate critical situations | |
| US20210026969A1 (en) | Detection and prevention of malicious script attacks using behavioral analysis of run-time script execution events | |
| CN117879970B (zh) | 一种网络安全防护方法及系统 | |
| US11550965B2 (en) | Analytics processing circuitry for mitigating attacks against computing systems | |
| Benmalek | Ransomware on cyber-physical systems: Taxonomies, case studies, security gaps, and open challenges | |
| CN112637108A (zh) | 一种基于异常检测和情感分析的内部威胁分析方法及系统 | |
| JP2023046293A (ja) | システム、コンピュータ実装方法、および強化学習フォールトインジェクションを介して訓練データ生成を促進するためのコンピュータプログラム製品（強化学習フォールトインジェクションを介した訓練データ生成） | |
| WO2023126512A1 (fr) | Procédé de détection d'une anomalie dans un système électronique en fonctionnement | |
| McHugh | Quality of protection: measuring the unmeasurable? | |
| CN117370701A (zh) | 浏览器风险检测方法、装置、计算机设备和存储介质 | |
| Williams et al. | Discovery of AI/ML supply chain vulnerabilities within automotive cyber-physical systems | |
| Annamalai et al. | FP-Fed: privacy-preserving federated detection of browser fingerprinting | |
| Oswal et al. | Deep learning-based anomaly detection in cyber-physical system | |
| Yang et al. | Towards a Resilient Machine Learning Classifier--a Case Study of Ransomware Detection | |
| Shieh et al. | Reliability Engineering in a Time of Rapidly Converging Technologies | |
| Marinova et al. | Hardware Solution for Cybersecurity of Unmanned Systems Critical Infrastructure | |
| US12118088B2 (en) | Moderator system for a security analytics framework | |
| Martin | Implementing effective controls in a mobile, agile, cloud-enabled enterprise | |
| Mokhtari et al. | A Machine Learning Approach for Anomaly Detection in Industrial Control Systems Based on Measurement Data. Electronics 2021, 10, 407 | |
| Rana et al. | A comprehensive framework for quantitative risk assessment of organizational networks using FAIR-modified attack trees |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20230707 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |