EP4457672A1 - 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

Info

Publication number
EP4457672A1
EP4457672A1 EP22840223.6A EP22840223A EP4457672A1 EP 4457672 A1 EP4457672 A1 EP 4457672A1 EP 22840223 A EP22840223 A EP 22840223A EP 4457672 A1 EP4457672 A1 EP 4457672A1
Authority
EP
European Patent Office
Prior art keywords
hardware
detection method
electronic system
blocks
measurement
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.)
Pending
Application number
EP22840223.6A
Other languages
German (de)
English (en)
Inventor
Sylvain GIRBAL
Jimmy Alain Daniel LE RHUN
David José Faura
Daniel GRACIA PÉREZ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thales SA
Original Assignee
Thales SA
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Thales SA filed Critical Thales SA
Publication of EP4457672A1 publication Critical patent/EP4457672A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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

Definitions

  • TITLE Method for detecting an anomaly in an electronic system in operation
  • the present invention relates to a method for detecting an anomaly in an electronic system in operation, in particular a computer attack against the electronic system.
  • the invention applies in particular to the field of critical on-board computers such as those present in avionics, space, rail, automobile, maritime, medical or IloT ("Industrial Internet of Things” in English or “Industrial Internet of Things” in French), traditionally confronted with operational safety issues, the role of which is to protect these systems and their users from failures and breakdowns.
  • the IloT takes the principles of the Internet of Things (or "loT” for "Internet of Things” in English) to apply them to the industrial sector, sharing the data sensors of the different systems, and maximizing machine-machine communications without human intervention.
  • the IloT promotes constant communication between the different systems to increase operational efficiency, but it is confronted with the need on the one hand to secure these communications, and on the other hand to ensure the security of each of the systems. the constituent, so that it cannot serve as a backdoor to enter the system maliciously.
  • the field of portable computers (“wearable computing” in English) and implanted medical systems, in addition to the classic security problems, is also confronted with problems of confidentiality and data integrity.
  • NIDS Network Intrusion Detection System
  • HIDS “Host Intrusion Detection System” or “System of detection Host Intrusion” in French.
  • NIDS focus on analyzing network communications. It involves capturing traffic at a particular point in a network, and analyzing the packets by comparing them to a database of attack patterns. If a set of packets matches a known attack pattern, an alert is raised.
  • HIDS focus on a computer, at the level of its operating system. This is to detect abnormal behavior, by monitoring running processes, memory allocations, logged in users, etc. An alert is generated when one of the monitored quantities deviates from a predefined standard.
  • the Specter attack exploits a hardware vulnerability in some branch prediction implementations of microprocessors with speculative execution. While at the functional level, a prediction error is canceled as soon as it is observed, speculative execution can however, as a side effect, allow arbitrary access to RAM locations, with data used by code that was executed "just in case” remaining stored in the cache.
  • the Meltdown attack also exploits a speculation vulnerability used for out-of-order instruction execution in the processor, including caches and the Translation Lookaside Buffer (TLB). of translation” in French). Unlike the Specter attack, the Meltdown attack uses mechanisms more specific to the architecture of the processor, and allows on the one hand to access data without the corresponding access rights, but also to make privilege escalation.
  • TLB Translation Lookaside Buffer
  • DRAM Dynamic Random Access Memory
  • the electronic system comprising one or more processors each composed of a plurality of hardware blocks, the processor being suitable for executing at least one application by interactions of the application with said hardware blocks, the detection method comprising at least the following steps:
  • the method comprises one or more of the following characteristics, taken in isolation or in all technically possible combinations:
  • the detection method further comprises at least one step chosen from the group consisting of: analysis of the nature of the hardware block associated with each inconsistency, analysis of the temporal frequency of the inconsistencies, and analysis of the deviation of each measurement associated with inconsistencies to the reference data set; the detection method comprising a detection step, depending on the or each analysis of an anomaly, in particular a computer attack or a hardware failure of one of the hardware blocks.
  • each alert criterion depends on at least one condition on the representative parameters, the detection method comprising, when an alert associated with one of the hardware blocks is emitted, a new iteration of the steps of the detection method starting from the measurement step, the alert criterion comprising, at each iteration, an increasing number of conditions.
  • each representative parameter associated with one of the hardware blocks is chosen from the group consisting of: the type of data processed by the hardware block; the type of instructions executed by the hardware block; the number of accesses to the hardware block; the number of calculations executed and/or the calculation time of the hardware block; the number of hardware block malfunctions, and the number of interactions on an interconnect network internal to the processor involving the hardware block, and the number of interactions with the exterior of the processor by the hardware block.
  • each hardware block is chosen from the group consisting of: one or more calculation units, one or more branch prediction units, one or more processor internal memory registers, one or more cache memories, one or more random access memories, one or more processing chains, one or more memory protection or address translation units, one or more buses or interconnection networks, one or more input-output units each parameter representative of the operation of one of the hardware blocks being chosen from the group consisting of: the number of data of the same type processed by the calculation unit(s), the interconnection network(s) or the memory(s), the number of instructions of the same type executed by the computing unit(s), the power consumption of the computing unit(s), the temperature of the computing unit(s), the number of successes and/or prediction errors of the branch prediction, the number of memory accesses, the number of successes and/or errors of requests for the cache memory, the number of successes and/or errors of requests for the memory protection unit, the execution time of an instruction in the processing chain, the number of information exchanges via the interconnection network(s) internal to the processor, the number of information exchanges
  • the electronic system comprises a plurality of counting hardware blocks each configured to measure one of the representative parameters, the measurement step comprising the measurement of a plurality of representative parameters, in particular between four and six, for example the representative parameters measured by a part of the counting hardware blocks.
  • the detection method further comprises a step of: comparing the or each inconsistency associated with the alert sent with a set of predetermined known anomalies, and categorizing the alert when the or each inconsistency corresponds to the one of the known anomalies of said set of anomalies.
  • the electronic system is a computer embedded in a transport platform.
  • the detection method is implemented by a system chosen from the group consisting of: a dedicated programmable logic circuit forming one of said hardware blocks of the processor; software of an operating system of the electronic system configured to interact with a memory protected by a memory protection unit, and an application suitable for being implemented by the electronic system by adding a driver controlling the hardware blocks.
  • a computer program product comprising a readable information medium, on which is stored a computer program comprising program instructions, the computer program being loadable on a data processing unit and suitable for cause the implementation of a detection method as defined above when the computer program is implemented on the data processing unit.
  • the invention also relates to a readable information medium on which is stored a computer program product as defined above.
  • an on-board computer in a transport platform configured to implement the detection method as defined above, the electronic system being the on-board computer.
  • the invention also relates to a transport platform comprising the computer as defined above.
  • the invention also relates to a method for generating a reference set, the reference set being representative of the operation of an electronic system in operation without anomalies, the electronic system comprising one or more processors each composed of a plurality of blocks hardware, the hardware blocks comprising hardware execution blocks and hardware counting blocks, the processor being suitable for executing at least one application by interactions of the application with said hardware execution blocks, each hardware counting block being adapted to measure an operating parameter representative of the interactions of the application with one of the execution hardware blocks to obtain measurements of said representative parameter, the generation method comprising at least the following steps:
  • the method comprises one or more of the following characteristics, taken in isolation or according to all the technically possible combinations: during the measurement step, the measurements obtained are measurements of a plurality of operating parameters, in particular a number of operating parameters comprised between four and six, the set of measurements obtained being, for example, only the operating parameters measured by a part of the counting hardware blocks.
  • each operating parameter representative of the interactions of one of the hardware execution blocks with the application is chosen from the group consisting of: the type of data processed by the hardware block considered, the type of instructions executed by the hardware block considered; the number of accesses to the hardware block considered, the number of calculations executed and/or the calculation time of the hardware block considered, the number of malfunctions of the hardware block considered, the number of interactions on an interconnection network internal to the processor involving the hardware block, and the number of interactions with the exterior of the processor by the considered execution hardware block.
  • each hardware execution block is chosen from the group consisting of: one or more calculation units, one or more branch prediction units, one or more memory registers, one or more cache memories, one or more random access memories, a or more processing chains, one or more memory protection or address translation units, one or more interconnecting buses or networks, and one or more input-output units, each parameter representative of the operation of one of the hardware execution blocks being chosen from the group consisting of: the number of data of the same type processed by the calculation unit(s), the interconnection network(s) or the memory(s), the number of instructions of the same type executed by the calculation unit, the energy consumption of the calculation unit(s), the temperature of the calculation unit(s), the number of successes and/or prediction errors of the branch prediction unit, the number of memory accesses, the number of successes and/or errors of cache memory requests, the number of successes and/or errors of memory protection unit requests, the execution time of an instruction in the chain of processing, the number of information exchanges on the processor's internal interconnection network(s), the number of information exchanges via
  • the processing step comprises an aggregation of the measurements for each operating parameter to obtain a database specific to each operating parameter.
  • the set of measurements and the set of processed data occupy a respective size on a memory, the processing step comprising the application of an operation allowing the size of the set of processed data to be less than the size of the set of measures.
  • the operation is implemented by a machine learning technique including training from the set of measurements.
  • the machine learning technique includes training a neural network from the set of measurements.
  • the operation is a statistical analysis operation such that the data set processed is a statistical distribution of the measurement set.
  • a predetermined number of iterations of the measurement step is implemented in order to obtain a first set of measurements and a first set of processed data
  • the generation method further comprising the following steps: second implementation of the predetermined number of iterations of the measurement step to obtain a second set of measurements and a second set of processed data,
  • the invention also relates to a reference set that can be obtained by a generation method as defined above.
  • the invention also relates to the use of the reference set as defined above to detect an anomaly in the electronic system in operation, in particular a computer attack against the electronic system, by comparing at least one measurement of at at least one of the operating parameters during operation of the electronic system and by comparing said measurement with the reference set to detect any inconsistencies between the measurement and said reference set.
  • the invention also relates to a computer program product comprising a readable information medium, on which is stored a computer program comprising program instructions, the computer program being loadable on a data processing unit and adapted to cause the implementation of a generation method as defined above when the computer program is implemented on the data processing unit.
  • the invention also relates to a readable information medium on which is stored a computer program comprising program instructions, the computer program being loadable on a data processing unit and adapted to cause the implementation of a generation method as defined above when the computer program is implemented on the data processing unit.
  • FIG. 1 is a schematic representation of an electronic system according to the invention embedded in a transport system
  • FIG 2 is a flowchart of a method, according to the invention, for generating a reference set
  • FIG 3 is a flowchart of the splitting step of the generation process
  • FIG 4 is a flowchart of the measurement and processing steps of the generation process
  • Figure 5 is a flowchart of a method, according to the invention, for detecting an anomaly
  • Figure 6 is a schematic representation of a processor embedded in the electronic system of Figure 1.
  • Figure 1 shows an electronic system 10.
  • the electronic system 10 is embedded in a transport platform 12.
  • the transport platform 12 is in particular suitable for transporting passengers and/or goods.
  • the transport platform 12 is, in particular, an avionic transport platform such as an airplane, a helicopter or a drone.
  • the transport platform 12 is a space transport platform such as for example a satellite or a space shuttle; a rail transport platform, in particular a train; a maritime transport platform such as a ship or a submarine or an automobile transport platform such as an autonomous car or a bus.
  • the invention applies to any field in which critical on-board computers are present.
  • the electronic system 10 is embedded in a medical device, in a portable computer, in a home automation system or in an industrial system.
  • the platform 12 possibly comprises a plurality of electronic systems 10.
  • the platform comprises a take-off system, a piloting system, a communication system, an alert system, etc. .
  • the electronic system 10 comprises one or more processors 14, an operating system 16 and a memory 18.
  • the operating system 16 (often referred to as OS for “Operating System”) is a set of programs which directs the use of the resources of the electronic system 10 by applications.
  • Each processor 14 is made up of a plurality of hardware blocks.
  • the hardware blocks include 20 execution hardware blocks and 22 counter hardware blocks.
  • a hardware execution block 20 is an electronic component configured to execute an elementary function of the processor 14 such as calculation, memory storage or data transfer.
  • the processor 14 is suitable for executing at least one application by interactions of the application with the hardware execution blocks 20.
  • the application is a program capable of carrying out a task, or a set of elementary tasks.
  • the application runs using operating system services to utilize the hardware resources provided by the 20 runtime hardware blocks.
  • each hardware execution block 20 is chosen from the group consisting of:
  • processing chains one or more memory protection or address translation units, one or more interconnecting buses or networks, and
  • Each counting hardware block 22 is adapted to measure an operating parameter representative of the interactions of the application with one of the execution hardware blocks 20 with the application to obtain measurements of said representative parameter.
  • the electronic system 10 comprises a plurality of hardware counting blocks 22 capable of each measuring a specific operating parameter.
  • the electronic system 10 notably comprises between four and six hardware counting blocks 22.
  • the electronic system 10 comprises more than six counting hardware blocks 22.
  • Each representative parameter associated with one of the hardware execution blocks 20 is chosen from the group consisting of: the type of data processed by the hardware execution block 20; the type of instructions executed by the hardware execution block 20; the number of accesses to the execution hardware block 20;
  • the number of calculations executed and/or the calculation time of the hardware execution block 20 the number of malfunctions of the execution hardware block 20, and the number of interactions on an internal processor interconnect network involving the execution hardware block 20, and the number of interactions with the exterior of the processor 14 by the execution hardware block 20.
  • the different data types are, for example, a boolean type, an integer type, a floating-point real type, a character type, etc.
  • the different instructions are for example a calculation instruction, a data sending instruction, a storing instruction, etc.
  • Each internal interconnection network of the processor 14 forms a gateway allowing communication between different entities of the processor, in particular between the different hardware blocks.
  • each parameter representative of the operation of one of the hardware execution blocks 20 is chosen from the group consisting of: the number of data of the same type processed by the calculation unit(s), the network(s) of interconnection or the memory(ies), the number of instructions of the same type executed by the calculation unit(s), the energy consumption of the calculation unit(s),
  • the memory 18 stores a set of reference data, or also called a reference set hereafter.
  • the reference data set is representative of the operation of the electronic system 10 without anomalies.
  • “Operation without anomalies” means operation of the electronic system 10 as provided and envisaged during its design and operation. Abnormal operation is therefore operation deviating from what was envisaged during the operation of the electronic system 10, due for example to a computer attack or to a hardware and/or software failure. In particular, an operating margin without anomaly is defined around the operating values planned during the design of the system. By way of example, an operating temperature interval without anomalies of the calculation units is determined at the design stage. Abnormal operation is detected when the temperature is, for example, 10°C warmer than the maximum limit of the operating interval without anomalies.
  • the reference data set or reference set, makes it possible to detect possible inconsistencies between the measurement of an operating parameter and the reference data set.
  • a generation method 100 of such a reference set will now be described, with reference to Figure 2 representing a flowchart of said generation method 100.
  • the generation method 100 includes a step 120 of executing the application A on a test bench according to a plurality of predetermined input data E.
  • test bench is meant a test environment making it possible to put the electronic system 10 under configurable and controlled conditions of use in order to to observe and measure its behavior. The execution on a test bench is therefore different from the operational use in operation thereafter of the electronic system 10.
  • the input data E are representative of the operation in operation of the electronic system 10 without anomalies.
  • These input data E are determined according to the use envisaged for the electronic system 10 in operation. Experience feedback from the operation of similar electronic systems is also used. These input data are chosen in order to cover a wide variety of events likely to be encountered by the electronic system 10 during its operation in normal operation, without anomalies.
  • Application A is configured to implement at least two functions, each function being implemented during its own time phase P.
  • application A includes an initial data acquisition phase, a data processing phase, a storage phase and a data sending phase.
  • the execution of the application A is implemented according to at least two successive temporal phases P.
  • the generation method 100 therefore includes a prior step 110 of dividing the application A into phases P.
  • the slicing is a temporal slicing or a functional slicing.
  • Figure 3 presents a decision tree allowing to choose the type of splitting of the application A.
  • time slicing is chosen when the source code of application A is not known or mastered and the identification of the phases is not easy.
  • the slicing is a time slicing that requires an additional step of sample rate selection.
  • This choice has an impact on the total number of phases P and is determined by seeking a compromise between the fineness of the characterization of these phases and the size of the reference set obtained.
  • the breakdown is performed on the basis of this period.
  • the sampling frequency is higher.
  • each temporal phase P corresponds to a predetermined time interval of execution of the application, in particular a time interval of less than 300 milliseconds, typically 200 milliseconds.
  • the generation method 100 comprises a measurement step 130 by at least one of the counting hardware blocks 22 of at least one operating parameter representative of the interactions of one of the execution hardware blocks 20 during the step running with the app, to get measurements.
  • the measurements obtained are therefore measurements of a plurality of operating parameters as defined above.
  • Figure 4 illustrates in particular this measurement step 130.
  • At least one new iteration I of the steps of the generation method 100 is implemented, the measurement step 130 of an iteration being implemented by at least one counting hardware block 22 different from the at least one hardware block counter 22 implementing the measurement step of another iteration I.
  • a set of counting hardware blocks 22 measuring the operating parameters during an iteration I is called configuration C of the counting hardware blocks 22.
  • the application A is executed over a large number of iterations I, with different input data, to capture distributions of the possible values of the different operating parameters in nominal operation.
  • the generation method 100 then comprises a step 140 of processing the measurements of the operating parameters, to obtain processed data.
  • processing step 140 is implemented by applying respective operations to the measurements of each phase.
  • the processing step 140 includes in particular an aggregation of the measurements for each operating parameter to obtain a database specific to each operating parameter.
  • the processing 140 comprises an aggregation of the measurements per phase P, measurements per configuration C, and measurements per iteration I to obtain a set of collected statistical data.
  • the collected values are aggregated as follows.
  • Aggregation by phase P consists of grouping together all the measured values in a table indexed by phase.
  • Aggregation by configuration C extends the set of events beyond the current configuration to cover the set of configurations necessary to cover all hardware events considered in normal operation.
  • the aggregation by iteration I differs from the previous aggregation by replacing the pairs (event, value) by pairs (event, set of values observed during the different iterations).
  • the set of measurements collected for application A is thus likely to be very large and typically represent several gigabytes of data collected.
  • the processing step 140 then comprises the application of an operation allowing the size in memory of the set of processed data to be less than the size in memory of the set of measurements.
  • the operation is implemented by a machine learning technique including training from the set of measurements.
  • the machine learning technique is notably implemented by training a neural network from the set of measurements.
  • the reference game would then become this network once trained.
  • symbolic learning or segmentation techniques are used.
  • the reduction operation is a statistical analysis operation such that the processed data set is a statistical distribution of the measurement set.
  • This operation is similar to that commonly performed to allow the visualization of statistical data with histograms or box plots for example.
  • the statistical distribution includes a plurality of values giving key information about the statistical distribution such as minimum, maximum, mean, median, standard deviation, deciles, quartiles, etc. For example, these values are the different bins of a histogram or the quartiles for boxplots.
  • This plurality of values then becomes the reference set J.
  • a predetermined number of iterations of the measurement step 130 is implemented in order to obtain a first set of measurements and a first set of processed data.
  • the generation method 100 then further comprises a second implementation of the predetermined number of iterations of the measurement step 130 to obtain a second set of measurements and a second set of processed data. Then, the first set of processed data is compared to the second set of processed data according to a predetermined convergence criterion.
  • the convergence criterion makes it possible to determine whether these two distributions are statistically similar.
  • the literature proposes different solutions to this problem such as the comparison of histograms by calculating the Bhattacharyya distance, the Kullback-Leiber divergence or the Hellinger distance.
  • the generation method 100 comprises the implementation of a number of iterations of the measurement step 130 greater than the predetermined number of iterations.
  • the two statistical distributions collected are concatenated and the collection is reiterated of a distribution of greater size, for example of a double size.
  • This step is repeated until a convergence of the statistical distribution is obtained.
  • the generation method 100 includes the generation of the reference set J from the first and second sets of processed data.
  • a reference set J is thus obtained from the processed data.
  • this reference set is used in particular to detect an anomaly in the electronic system 10 in operation, in particular a computer attack against the electronic system 10, by comparing at least one measurement of at least one of the operating parameters during the operation of the electronic system 10 and by comparing said measurement with the reference set to detect any inconsistencies between the measurement and the reference set.
  • the hardware platform supplier delivers the computer as well as all the electronics necessary for the proper functioning of the software applications that may be assigned to it.
  • the operating system supplier provides the operating system which will make it possible to manage the execution of the various application software according to their needs in terms of priority, time and frequency of execution, memory space, etc.
  • the application software supplier is responsible for the proper functioning of its applications while respecting the instructions provided by the system integrator concerning the rules for the use of the system's hardware resources.
  • the system integrator is given the central role. It assembles the various technological bricks, both hardware and software of the system while allocating all the necessary resources to the suppliers of the software applications. In addition, he is responsible for consolidating the operating requirements and taking into account the interactions of the various technological bricks with respect to the resources of the system. He is the one who must guarantee the operational safety and overall security of the system.
  • Control of the system involves all the participants, each at their own level of responsibility, but it is the system integrator who is responsible for defining and validating the entire system under construction, ensuring that the applications running on the system's computing platforms comply at all times with non-functional specifications such as time, energy and the sharing of resources necessary for computing, safety, security, etc.
  • the reference set J is advantageously used to transmit the requirements of the system integrator to the other actors and the transmission of the non-functional properties of the applications to the integrator such as the effective need in terms of shared hardware resources.
  • the software supplier provides information related to the use of hardware resources by its application, and therefore a rate of use of the various shared resources.
  • the J reference set is also a way for the system integrator to translate their requirements into a maximum resource utilization envelope. for each application, so as to guarantee their coexistence in the final integrated system.
  • the reference set J representing the hardware behavior of applications therefore has several domains of applicability.
  • the reference set J can be used in a cyber-security context, as will be explained later, to guard against external cyber-attacks.
  • the reference set J can also be used to participate in the monitoring of the system, to detect abnormal cases linked to failures and to trigger measures aimed at a return to a stable state.
  • the J reference set can also be used as a means of transmitting non-functional requirements. Indeed, in the context of multi-core processors, themselves complex systems coming from third-party suppliers and most often having partial specifications, the usual technique of time partitioning has become insufficient.
  • the J reference set can also be used to facilitate the integration of applications by taking into account their specific use of shared hardware resources.
  • the usual technique based on abstract models is no longer suitable for multi-cores.
  • the reference set J can also be used to build a library of representative applications of a domain by characterizing them via the distance between their respective reference sets.
  • the reference set J can also be used to anticipate the impact of integrating a new application into the system knowing its reference set.
  • a method 200 for detecting an anomaly in an electronic system 10 in operation will now be described with reference to Figure 5 representing a flowchart of said detection program 200.
  • the detection method 200 is performed using a reference set as generated above.
  • the method 200 aims to detect a computer attack against the electronic system 10.
  • the detection method 200 is also suitable for detecting a hardware and/or software failure of the electronic system 10.
  • the detection method is implemented by a dedicated programmable logic circuit forming one of said hardware execution blocks 20 of processor 14.
  • this implementation is carried out at the hardware level in the form of a dedicated component, as shown schematically in Figure 6 with the numerical reference 1.
  • This component could thus reprogram and exploit the counting hardware blocks 22 without worrying about the levels necessary privileges at the software level.
  • a hardware component also makes it easy to have a dedicated memory to store the reference sets within the component itself.
  • This embodiment therefore offers a highly secure solution.
  • the detection method is implemented by software of an operating system 16 of the electronic system 10 configured to interact with a memory protected by a memory protection unit.
  • the benchmark set is stored in main memory.
  • the software will benefit from the high privilege levels of the operating system to configure and read the hardware blocks counting 22.
  • the storage area of the reference sets is protected via the memory management unit (or MMU from English management unit”).
  • the detection method is implemented by an application capable of being implemented by the electronic system 10 by adding a driver controlling the hardware blocks, as represented schematically in FIG. 6 with the reference digital 3.
  • the method is implemented in the form of an application running at the same level as the applications to be monitored.
  • This embodiment is the easiest to implement.
  • the detection method is implemented via a hybrid implementation, both software and hardware, such as for example a software-level implementation which stores the reference games in a dedicated hardware flash memory, to protect the space memory of reference sets.
  • the electronic system 10 is in operational operation.
  • the electronic system 10 is on board an aircraft in the process of flying to an airport.
  • the electronic system 10 is then for example an avionics system for communication, piloting, etc.
  • the detection method 200 comprises a first measurement step 210, during the operation of the electronic system 10, of at least one parameter representative of the interactions of the application A with one of the execution hardware blocks 20 to obtain measurements said representative parameter.
  • Representative parameters are as defined above. They correspond in particular to those for which measurements were made during the process for generating the associated reference set.
  • the detection method 200 includes comparing 220 the measurement with the associated reference data set, or reference set, to detect any inconsistencies between the measurement and the reference data set.
  • An inconsistency is a statistical deviation of the measurement from the reference set.
  • the measurement is not included in the envelope formed by the reference set.
  • the detection method 200 comprises a step 230 of issuing an alert W according to an alert criterion relating to the inconsistency or inconsistencies detected.
  • Each alert criterion depends on at least one condition on the representative parameters.
  • Each alert criterion is for example a threshold value of the measured parameter.
  • the measured parameters are alternated rapidly in order to cover all the significant events by sampling in a short period of time.
  • the measured parameters are chosen by means of a hierarchical selection of the monitored events.
  • the measured parameters are chosen by means of a hierarchical selection of the monitored events.
  • the set of hardware execution blocks 20 for which a representative parameter measurement is performed being, at each iteration, included in the set of hardware execution blocks 20 of the previous iteration, the set of hardware execution blocks 20 being in particular included in the set of hardware execution blocks 20 associated with the alert or alerts.
  • the measurement steps 210 are thus advantageously repeated over several hierarchical levels. This method improves the reliability of detection despite the limited number of counting hardware blocks 22.
  • the detection method 200 comprises, when an alert W associated with one of the hardware execution blocks 20 is emitted, a new iteration of the steps of the detection method 200 starting from the measurement step 210, the criterion of alert comprising, at each iteration, an increasing number of conditions.
  • a first alert condition is the exceeding of a memory access threshold of a hardware block.
  • the alert condition includes in addition to this threshold, the exceeding of a threshold of calculations executed by this hardware block.
  • the method 200 then comprises the analysis 240 of the nature of the execution hardware block 20 associated with each inconsistency, the analysis of the temporal frequency of the inconsistencies, and/or the analysis of the deviation of each measurement associated with the inconsistencies. to the reference data set.
  • the detection method 200 then comprises a detection step 250, depending on the or each analysis of an anomaly, in particular a computer attack or a hardware failure of one of the hardware blocks. Indeed, depending on the frequency, type and severity of abnormal events, it is possible to distinguish a computer attack from a hardware failure.
  • the transient events linked to operational safety are essentially one-off, and are reflected at the level of the hardware counting blocks 22 by a peak.
  • Cybersecurity events on the contrary last for the duration of the attack, and attacks generally have a longer lasting effect on 22-count hardware blocks.
  • the method comprises categorizing the alert when the or each inconsistency corresponds to one of the known anomalies of said set of anomalies.
  • the detection method 200 does not depend on the type of attack.
  • the method also makes it possible to detect new classes of attacks targeting hardware or software.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (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

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.

Description

DESCRIPTION
TITRE : Procédé de détection d’une anomalie dans un système électronique en fonctionnement
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’IloT (« 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’IloT reprend les principes de l'internet des objets (ou « loT » 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’IloT 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 connaît 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 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, 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 : [Fig 1] la Figure 1 est une représentation schématique d’un système électronique selon l’invention embarqué dans un système de transport,
[Fig 2] la Figure 2 est un organigramme d’un procédé, selon l’invention, de génération d’un jeu de référence,
[Fig 3] la Figure 3 est un organigramme de l’étape de découpage du procédé de génération,
[Fig 4] la Figure 4 est un organigramme des étapes de mesures et de traitement du procédé de génération,
[Fig 5] la Figure 5 est un organigramme d’un procédé, selon l’invention, de détection d’une anomalie,
[Fig 6] la Figure 6 est une représentation schématique d’un processeur embarqué dans le système électronique de la Figure 1 .
La figure 1 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 figure 1 , 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 Figure 2 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 Figure 3 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 Figure 4 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éterminer a priori quels é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 sûreté de fonctionnement et sécurité globale du système.
La maîtrise 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 Figure 5 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 Figure 6. 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 Figure 6 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 Figure 6 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 Figure 6 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

26 REVENDICATIONS
1. 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.
2. 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) ; le procédé de détection (200) comprenant 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 (20).
3. 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).
4. 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.
5. 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).
6. 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 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,
- une ou plusieurs unités d'entrée-sortie chaque paramètre représentatif du fonctionnement de l’un des blocs matériels (20) é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.
7. 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).
8. 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 : 29 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.
9. 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).
10. 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).
11. 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.
12. Support lisible d’informations sur lequel est mémorisé un produit programme d’ordinateur selon la revendication 11 .
13. 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é.
14. Plateforme de transport (12) comprenant le calculateur selon la revendication 13.
EP22840223.6A 2021-12-31 2022-12-30 Procédé de détection d'une anomalie dans un système électronique en fonctionnement Pending EP4457672A1 (fr)

Applications Claiming Priority (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

Publications (1)

Publication Number Publication Date
EP4457672A1 true EP4457672A1 (fr) 2024-11-06

Family

ID=81648777

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22840223.6A Pending EP4457672A1 (fr) 2021-12-31 2022-12-30 Procédé de détection d'une anomalie dans un système électronique en fonctionnement

Country Status (4)

Country Link
US (1) US20250278480A1 (fr)
EP (1) EP4457672A1 (fr)
FR (1) FR3131647B1 (fr)
WO (1) WO2023126512A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
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
CN119271504B (zh) * 2024-12-12 2025-03-18 新瑞数城技术有限公司 一种数据交互方法以及物联网协作一体机

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2928062B1 (fr) * 2008-02-26 2010-02-26 Thales Sa Procede de gestion dans les equipements de securite et entite de securite
US9842209B2 (en) * 2015-05-08 2017-12-12 Mcafee, Llc Hardened event counters for anomaly detection
US11188643B2 (en) * 2018-12-27 2021-11-30 Intel Corporation Methods and apparatus for detecting a side channel attack using hardware performance counters
US11194902B2 (en) * 2018-12-27 2021-12-07 Intel Corporation Side-channel attack detection using hardware performance counters
JP7226103B2 (ja) * 2019-05-29 2023-02-21 オムロン株式会社 制御システム、サポート装置およびサポートプログラム
US12165067B2 (en) * 2019-06-25 2024-12-10 The Board Of Trustees Of The Leland Stanford Junior University Anomaly augmented generative adversarial network
US11409995B2 (en) * 2019-08-28 2022-08-09 Nxp B.V. Anomaly detection by classifying past behavior
FR3103039B1 (fr) * 2019-11-07 2021-12-03 Electricite De France Détection d’attaques à l'aide de compteurs de performances matériels
WO2021118788A1 (fr) * 2019-11-20 2021-06-17 University Of Tennessee Research Foundation Procédés de détection de fonctionnement anormal de systèmes industriels et de systèmes de commande respectifs, ainsi que systèmes et articles de fabrication associés
US11521084B2 (en) * 2020-03-12 2022-12-06 Nxp B.V. Anomaly detection in a data processing system
US12500899B2 (en) * 2021-02-03 2025-12-16 Sc Networks, Incorporated Satellite communications network intrusion detection systems and methods

Also Published As

Publication number Publication date
FR3131647B1 (fr) 2024-01-26
US20250278480A1 (en) 2025-09-04
WO2023126512A1 (fr) 2023-07-06
FR3131647A1 (fr) 2023-07-07

Similar Documents

Publication Publication Date Title
CN117056951B (zh) 一种数字平台的数据安全管理方法
US10057144B2 (en) Remote system data collection and analysis framework
US20210026969A1 (en) Detection and prevention of malicious script attacks using behavioral analysis of run-time script execution events
US20170111384A1 (en) Method for detecting vulnerabilities in a virtual production server of a virtual or cloud computer system
Taveras SCADA live forensics: real time data acquisition process to detect, prevent or evaluate critical situations
US20250291896A1 (en) Method and system for analyzing embedded systems
WO2021121382A1 (fr) Gestion de sécurité d'un véhicule autonome
CN104243445A (zh) 用于分析航空平台中的网络安全威胁的方法和系统
CN109564609A (zh) 利用先进计算机决策平台的计算机攻击的检测缓和与矫正
EP4457672A1 (fr) Procédé de détection d'une anomalie dans un système électronique en fonctionnement
Williams et al. Discovery of AI/ML supply chain vulnerabilities within automotive cyber-physical systems
Shieh et al. Reliability engineering in a time of rapidly converging technologies
Zuo et al. Secure data sharing for autonomous vehicles in mobile blockchain networks
Ghorbanian et al. Signature-based hybrid Intrusion detection system (HIDS) for android devices
CN115698992A (zh) 用于安全分析框架的仲裁器系统
US12189755B2 (en) Automated system for program identity-driven program access control
US20250260708A1 (en) System and method for training a generative adverserial model in a cybersecurity range
US12518073B2 (en) Artificial aging of digital twin to simulate cybersecurity issue associated with infrastructure
Kundu et al. Collaborative and accountable hardware governance using blockchain
Islam Confidential Computing with Trusted Execution Environments
FR3103038A1 (fr) 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
CN117370701A (zh) 浏览器风险检测方法、装置、计算机设备和存储介质
Martin Implementing effective controls in a mobile, agile, cloud-enabled enterprise
Daponte et al. Hardware solution for cybersecurity of unmanned systems critical infrastructure
Rashid et al. Lifecycle-Integrated Security for AI-Cloud Convergence in Cyber-Physical Infrastructure

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20240627

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR

P01 Opt-out of the competence of the unified patent court (upc) registered

Free format text: CASE NUMBER: APP_61935/2024

Effective date: 20241120

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)