WO2023222330A1 - Procédé et module de détection de vulnérabilités informatiques dans un parc d'ordinateurs - Google Patents

Procédé et module de détection de vulnérabilités informatiques dans un parc d'ordinateurs Download PDF

Info

Publication number
WO2023222330A1
WO2023222330A1 PCT/EP2023/060555 EP2023060555W WO2023222330A1 WO 2023222330 A1 WO2023222330 A1 WO 2023222330A1 EP 2023060555 W EP2023060555 W EP 2023060555W WO 2023222330 A1 WO2023222330 A1 WO 2023222330A1
Authority
WO
WIPO (PCT)
Prior art keywords
computer
vulnerability
cvek
program
combination
Prior art date
Application number
PCT/EP2023/060555
Other languages
English (en)
Inventor
Maxime BELAIR
Sylvie Laniepce
Adam OUOROU
Original Assignee
Orange
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 Orange filed Critical Orange
Publication of WO2023222330A1 publication Critical patent/WO2023222330A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577—Assessing vulnerabilities and evaluating computer system security
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine

Definitions

  • the invention relates to the general field of securing computer programs.
  • the invention aims more particularly at a method for managing the IT security of an IT equipment infrastructure using computer vulnerability detection programs.
  • the term vulnerability designates a flaw in a computer process, this flaw allowing, if exploited, to override the security rules of the computer system on which the program of this process is executed.
  • the CVE-2021-44228 vulnerability called “Log4Shell” is present in the Log4J logging software component.
  • the Log4J component is used by many applications using the Java language.
  • This vulnerability allows a remote attacker in the most severe cases to execute arbitrary code on the target machine.
  • a technical means that allows an attacker to exploit this vulnerability is called an attack vector.
  • Such a technical means is for example an instruction in a computer program.
  • Such a vulnerability requires the presence of software and/or hardware resources or means presenting weaknesses.
  • the exploitation of a vulnerability may correspond to sending instructions to a particular server. If a process does not have resources allowing such a sending, then this vulnerability cannot be exploited in that process. Conversely, the process may have such resources, in which case the vulnerability is exploitable provided that no security program blocks attacks aimed at exploiting this vulnerability.
  • process refers to an internal representation of a program running in computer memory. Each time a program is executed, one or more processes are created.
  • the invention aims to facilitate the management of the security of a fleet of computers by detecting exploitable computer vulnerabilities on these computers. As a corollary, the invention makes it possible to strengthen the security of a computer fleet.
  • the invention proposes to evaluate the exploitability of vulnerabilities at the level of namespace combinations.
  • kernel-level namespaces of an operating system.
  • Namespaces therefore provide a resource isolation mechanism.
  • the Linux operating system offers several namespaces (for example: Network, IPC (for Inter Process Communication in English), PID (for Process IDentifier in English), User, etc.) to isolate sets of processes.
  • namespaces for example: Network, IPC (for Inter Process Communication in English), PID (for Process IDentifier in English), User, etc.
  • the invention relates to a detection method implemented by a computer to detect the exploitability of a computer vulnerability in a set of processes associated with a combination of namespaces, said method comprising, for a reference process of said set, steps of: - initialization from the reference process and execution of a test process associated with said combination and executing a detection program, the execution of said program producing an indicator of the exploitability of said vulnerability in said set of processes; - sending to a security management device at least one signal comprising said indicator.
  • the invention proposes a detection module in a computer for detecting the exploitability of a computer vulnerability in a set of processes associated with a combination of namespaces, said module comprising, for a reference process of said set: - a submodule for initializing from the reference process and executing a test process associated with said combination and executing a detection program, the execution of said program producing an indicator of the exploitability of said vulnerability in said set of processes; - a submodule for sending at least one signal comprising said indicator to a security management device.
  • the invention makes it possible to identify the processes on which computer vulnerabilities can be exploited.
  • the method makes it possible to identify processes with weaknesses that allow these vulnerabilities to be exploited. Such weaknesses result, for example, from particular software or hardware resources.
  • the combination of namespaces associated with a process is the set of namespaces associated with this process.
  • a process may be associated with a namespace combination that currently (as of May 2022) contains 9 namespaces of distinct types.
  • Each combination of namespaces on the computer can be identified automatically.
  • the method advantageously makes it possible to determine an indicator of the exploitability of a vulnerability in an identified combination, without having to test this exploitability for each process in this combination of namespaces.
  • the invention proposes using a single process in this combination.
  • This process is called the combination reference process since it is used to initialize a test process to implement exploitability detection in this combination.
  • the test process is created as a process identical to the reference process.
  • initialization of a process we mean here the creation followed by the triggering of the execution of this process.
  • the testing process has access to the same resources allocated by the namespace combination as all other processes in that combination.
  • the test process inherits, at the time of its creation, the environment variables of the reference process.
  • said reference process is the basic process of said combination.
  • environment variables refers to types of values that can be used by processes. In particular, these values can give access to certain resources.
  • the ⁇ PATH> environment variable corresponds to the list of directories in which executable files are located.
  • a first set of processes is associated with the same value of the ⁇ PATH> variable, which will allow these processes to use the executable files located by this value without using the absolute paths to these files.
  • a second set of processes is associated with a different value of the ⁇ PATH> variable. The first and second sets of processes will therefore not have access to the same executable files.
  • the invention proposes to ignore this possible change, and to consider as an approximation, that if a vulnerability is exploitable with the environment variables of a process of a combination of namespaces (hereinafter, a (such vulnerability will be designated as exploitable in this process), then this vulnerability is exploitable with the environment variables of any process in the same namespace combination, including if those environment variables have changed over time. during the life of this process.
  • the invention proposes to consider, as an approximation, that if a vulnerability cannot be exploited with the environment variables of a process of a combination of namespaces, then this vulnerability cannot be exploited with the variables environment of no process of the same namespace combination.
  • the detection by the testing process of the exploitability of the vulnerability is a reliable indicator of the actual exploitability of the vulnerability in the namespace combination.
  • the testing process runs a program to detect the exploitability of the vulnerability.
  • the information generated by running the detection program indicates the exploitability of the vulnerability in the namespace combination. This information, in the form of an indicator, goes back to a security management device and in particular allows the user of this device to choose the appropriate security programs to install.
  • This indicator includes at least one piece of data making it possible to identify the vulnerability, for example an identifier of this vulnerability.
  • the security management device is a server.
  • the invention can be implemented by a plurality of computers in a computer park, each of these computers being able to report, to the security management server, information on the exploitability of a vulnerability in their combinations of respective namespaces.
  • the security management server can be controlled by a central administrator who has a security orchestration role on the computer fleet.
  • this embodiment of the detection method makes it possible to automatically and centrally identify which security programs to install and where to install them.
  • security program we mean a program whose execution prevents the exploitation of a computer vulnerability.
  • the invention also allows the central administrator to free himself from the need to manually consult each administrator of each computer so that each of them, for example, manually and locally checks whether a vulnerability is present in the software. of their machine, and where applicable whether measures have been taken to render it harmless.
  • the execution of the detection program comprises: - a determination of the presence of one or more means of exploiting said vulnerability in an environment defined by at least said combination of namespaces and the environment variables of said reference process; and, if one or more said means of exploitation are detected: - a test of exploitation of said vulnerability with this or these means of exploitation.
  • the evaluation, by the detection program, of the exploitability of the computer vulnerability is carried out in two stages.
  • a first determination step it is determined whether the resource(s) necessary for exploiting the IT vulnerability are present in the process environment.
  • the environment of a process includes the hardware and software resources accessible to the process to execute a program. In this case, it is defined at least by the combination of namespaces and by the environment variables with which this process is associated.
  • a second step it is tested whether the vulnerability is actually exploitable.
  • This step can for example correspond to the execution of an attack vector targeting said vulnerability. If this attack vector is consumed, it means that the vulnerability is exploitable. Otherwise, the vulnerability cannot be exploited.
  • test attack is executed. The success or failure of this test attack determines whether the computer vulnerability is exploitable or not.
  • the detection method comprises steps of: - reception, from said security management device, of an identifier of said vulnerability; - installation, in said computer, of said detection program corresponding to said identifier.
  • the invention makes it possible to manage the selection of computer vulnerabilities to be detected with the security management device.
  • the security management device is a server connected to a fleet of computers
  • executions of the detection programs on each computer can then be managed centrally, without requiring the contribution of the administrators of at least certain computers. of the park, which makes it possible to avoid the manual installation of detection programs on at least some, for example on all the machines in the park.
  • the steps of initializing a test process and sending a signal to the security management device are carried out for several reference processes respectively associated with several combinations of namespaces.
  • the detection method can advantageously be carried out in parallel for all combinations of namespaces of one or more computers, and thus ensure the security of all the processes of this or these computers.
  • the step of installing the detection program comprises sub-steps of: - sending, to a security server, a request including said vulnerability identifier; - reception, in response to the request, of said detection program.
  • This use of a security server advantageously saves memory space on the computer.
  • This embodiment also makes it possible to make available to the computer a database comprising a plurality of computer vulnerability exploitability detection programs which can be installed if necessary, upon decision of the security management server.
  • this external database can be updated independently of the administrators of the computers in the park.
  • said at least one signal further comprises: - an identifier of said computer; And - data representative of said at least one combination.
  • This data allows a central administrator to map computer vulnerabilities and their exploitability.
  • the detection method is characterized in that said computer comprises a protection program against the exploitation of said vulnerability and in that said protection program is neutralized during the execution of said program detection.
  • This embodiment makes it possible to more precisely assess vulnerabilities on the computer. In particular, it makes it possible to test whether a given protection program effectively protects against the exploitation of a given computer vulnerability.
  • the invention proposes an identification method implemented by a security management device, to identify the exploitability of a computer vulnerability in at least one computer, said method comprising steps of: - reception from said at least one computer, of a signal comprising an indicator of the exploitability of said vulnerability in a set of processes associated with a combination of namespaces of said at least one computer; - addition to a list of said signal.
  • the invention proposes an identification module in a security management device, to identify the exploitability of a computer vulnerability in at least one computer, said module comprising: - a submodule for receiving, from said at least one computer, a signal comprising an indicator of the exploitability of said vulnerability in a set of processes associated with a combination of namespaces of said at least one computer; - a submodule for adding said signal to a list.
  • the invention proposes a method making it possible to identify, from a device (for example a server), a given computer vulnerability in a computer or a fleet of computers, as well as the combinations of namespaces in which this vulnerability is exploitable.
  • the steps of the identification process described above can be repeated for a plurality of given computer vulnerabilities.
  • the invention proposes to pool messages coming from computers in which one or more exploitable vulnerabilities have been detected, by adding these messages to a list.
  • This list allows the administrator to make decisions regarding security management in the computer fleet. For example, the presence of certain vulnerabilities in particular namespaces may prompt the installation of security programs to enhance the security of processes associated with those namespaces.
  • the identification method comprises a step of sending an identifier of said vulnerability to said at least one computer.
  • This sending allows the administrator of the security management device to decide which detection programs will be executed on the computers in the IT fleet. Indeed, this embodiment allows, in one embodiment of the detection method described above, to install and execute the detection program in response to the sending of the vulnerability identifier by the management device. security.
  • the invention also relates to a computer program on a recording medium, this program being capable of being implemented in a computer device or more generally in a computer.
  • This program includes instructions allowing the implementation of a process as described above.
  • This program may use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other desirable shape.
  • the invention also relates to an information medium or a recording medium readable by a computer and/or a computing device, and comprising instructions for a computer program as mentioned above.
  • the information or recording medium can be any entity or device capable of storing programs.
  • the media may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or even a magnetic recording means, for example a hard disk, or a flash memory.
  • the information or recording medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio link, by wireless optical link or by other ways.
  • the program according to the invention can in particular be downloaded onto an Internet type network.
  • the information or recording medium may be an integrated circuit in which a program is incorporated, the circuit being adapted to execute or to be used in the execution of one of the methods as described above.
  • Appendix 1 represents a first part of a detection program that can be used in a particular embodiment
  • Appendix 2 represents a second part of a detection program that can be used in a particular embodiment
  • the detection and identification methods are implemented respectively by computers EQ1-EQ2 and a security management device CNode.
  • the CNode security management device has the hardware architecture of a computer server.
  • the invention is carried out for two computers EQ1 and EQ2, but the invention does not limit the number of computers. It can also be applied to a single computer or any number of computers, for example in a computer park.
  • the details of the EQ2 computer are not detailed on the , but this includes, like the EQ1 computer, the components making it possible to implement the vulnerability exploitability detection method within the meaning of the invention.
  • the computers EQ1 and EQ2 include in particular a processor 10, a RAM type random access memory 11, a ROM type read only memory 12, communication means 13 and a non-volatile rewritable memory, for example a hard disk 14.
  • Each EQn computer includes a SYSn software system.
  • the software system SYS1 of the computer EQ1 includes: - an MDET1 detection module according to the invention; - an ADM1 administration tool associated with administrator level rights; - a first CNS combination of namespaces with which a basic process PrR is associated, that is to say the first process created in this combination of namespaces; - a second combination CNS' of namespaces with which a basic process PrR' is associated; And - a directory Rep allowing detection programs P1, Pk, Pm to be recorded, and on which the programs P1 and Pk are recorded.
  • the test processes PrT and PrT' executing the program Pk in their respectively associated CNS and CNS' namespace combinations are created during an implementation of the detection method.
  • the CNode security management device is equipped with means of communication 13' with the computers EQ1 and EQ2 and a COM module for communication with a user, for example an administrator of the set of computers EQ1-EQ2.
  • the CNode security management device also includes a MIDA identification module conforming to the invention.
  • the implementation of the detection method by a single computer is shown.
  • Such an example on a single computer EQn is shown for the sake of simplicity but is in no way limiting the invention.
  • the detection and identification methods can be implemented for several computers in parallel.
  • the MIDA module sends and receives signals or messages via the aforementioned communications means 13'.
  • the MDETn module sends and receives signals or messages via the aforementioned communications means 13.
  • Computers EQ1 and EQ2 are configured to be able to communicate with an SRV_SEC security server via a NET communication network.
  • This SRV_SEC security server includes a BD database.
  • This BD database includes a set of vulnerability identifiers IF_CVE1, ID_CVEk, and ID_CVEm, each identifier being respectively associated with a detection program P1, Pk or Pm configured to produce an indicator of the exploitability of a vulnerability, when the corresponding detection program is executed by a test process within the meaning of the invention.
  • the detection program Pk is for example directly sent by the server SRV_SEC to a computer EQn in the form of an executable program, or is, in another example, sent in the form of a description file then transformed into an executable file by the 'computer.
  • a vulnerability identifier ID_CVEk is for example of the form CVE-AAAA-IIII, where AAAA is the year of publication and IIII a unique number.
  • the steps of the detection processes carried out by the MDETn module of the EQn computer are as follows: - identification F0 of CNS-CNS' combinations of name spaces and the associated PrR-PrR' reference processes; - F10 reception of an ID_CVEk identifier of the CVEk vulnerability from the CNode security management device; - F20 installation of a Pk detection program for the exploitability of the CVEk vulnerability, this installation comprising the sub-steps: (i) sending F201 to the SRV_SEC server of a REQ request including the identifier ID_CVEk; (ii) reception F202, from the server SRV_SEC, of the program Pk in response to sending F201; (iii) recording F203 of the program Pk in a directory Rep of the software system SYSn of the computer EQn; - initialization F30 of a test process PrT in the same combination of CNS namespaces as the reference process PrR, and execution of the program Pk
  • the Pk program includes instructions for implementation: (i) an F301 detection of means of exploiting the CVEk vulnerability among resources, these resources being those allocated to the process which will execute this program Pk (test process within the meaning of the invention); And (ii) an F302 test of exploitability of the CVEk vulnerability if such means are detected.
  • the MIDA module of the CNode device performs the following steps according to one embodiment of the identification method: - sending E10 of the identifier ID_CVEk to the computer EQn; - reception E40 of the Log signal coming from the computer EQn; And - addition E50 of the signal in a list.
  • the steps of initializing a test process F30 and sending F40 by the computer EQn are repeated or carried out in parallel for one or more other combinations of namespaces.
  • these steps F30 and F40 are carried out for all the CNS-CNS' combinations of namespaces identified during step F0.
  • a Linux operating system registered trademark
  • we typically obtain a combination of namespaces per container in English “container”.
  • the namespace combinations identified are all the namespace combinations accessible via administrator-level rights of the computer EQn, these rights being provided by the ADMn module of the computer.
  • these namespace combinations are obtained from obtaining the list of namespaces and associated processes, accessible via administrator rights. For each namespace thus obtained, a single process, among the processes associated with this namespace, is selected as the reference process. For each selected reference process, the different namespaces associated with this process are identified. As explained above, the different namespaces associated with a process form the combination of namespaces with which this process is associated. Consequently, the namespace combinations and the reference processes respectively associated with these combinations are thus identified.
  • each reference process PrR-PrR' of a namespace combination CNS-CNS' is the base process of this combination, i.e. the first process created in this combination .
  • the basic process of a namespace can, for example, be identified using the lsns command in the case of a Linux system.
  • step F30 of a test process PrT from a reference process PrR associated with a CNS combination helps detect the exploitability of the CVEk vulnerability in the CNS namespace combination.
  • step F30 makes it possible to indicate whether the resources allocated to the processes of this CNS combination make it possible to exploit the CVEk vulnerability.
  • the PrT test process is initialized in the same combination of CNS namespaces as the PrR reference process.
  • the PrT test process is created such that it has the same environment variables as the reference process.
  • the test process PrT is, for example, created as identical to the reference process, and thus generally inherits its environment variables.
  • the PrT test process is initialized with the fork() function applied to the reference process.
  • the PrT testing process runs a Pk detection program that can detect the exploitability of the CVEk vulnerability.
  • this program is composed of two parts.
  • the first part Script1 k whose execution corresponds to step F301, checks whether the test process has the means to implement an attack exploiting the CVEk vulnerability.
  • These means correspond, among other things, to the resources isolated by the combination of CNS namespaces as well as the resources made accessible by the environment variables of the PrT test process.
  • security programs can be implemented in the CNS namespace combination such that an attack to exploit the CVEk vulnerability would be blocked. Whether such an attack is blocked or not, in other words the actual exploitability of the vulnerability, is determined by the second part of the Pk detection program.
  • the second Script2 k part of the Pk program whose execution corresponds to step F302, tests the exploitability of the CVEk vulnerability. This part aims to exploit the vulnerability similar to an attack, but without harmful consequences on the EQn computer.
  • the example of the CVE-2021-3156 vulnerability illustrates the execution of a detection program.
  • This vulnerability affecting the sudo command is particularly critical given that sudo is used in so many environments.
  • the command arguments are first concatenated and the metacharacters are escaped with a backslash (for example, " ⁇ " becomes " ⁇ ").
  • a special character for example [, ⁇ ,(, ⁇ or ⁇ , is read as a regular character and not as a special character, it can be preceded by a backslash ⁇ . This is called escaping a character.
  • the escaping described here is not performed when sudo is run via the sudoedit -s symlink. Therefore, if an argument of the sudoedit command ends with a single backslash, the arguments not being escaped by sudo, the program will copy characters outside the limits of the memory buffer ("buffer" in English), which will cause a buffer overflow.
  • Appendices 1 and 2 correspond respectively to the first and second parts Script1 k and Script2 k of the Pk detection program in the case where the CVEk vulnerability is the CVE-2021-3156 vulnerability.
  • the detection program Pk is coded in bash language, which in no way represents a limitation of the invention.
  • the invention makes it possible to use any programming language allowing those skilled in the art to code a detection program conforming to the invention.
  • Executing the Script1 k code in Appendix 1 checks for the presence of the sudoedit symbolic link for executing the sudo binary and records a “Might be vulnerable” message in an “interface” file if this presence is detected.
  • Executing the Script2 k code in Appendix 2 launches the execution of the “exploit” file which corresponds to the use of the sudoedit command with a single backslash. If this execution fails, for example because of a security program blocking any use of the sudoedit command with a backslash, no message is produced. Otherwise, a “Vulnerable” message is saved in the “interface” file.
  • the “interface” file contains an IEXk indicator of the exploitability of the CVEk vulnerability. If this IEXk flag contains the message "Might be vulnerable” but does not contain the message "Vulnerable”, then it indicates that means to exploit the CVEk vulnerability are available to processes in the CNS namespace combination, but that this vulnerability is not effectively exploitable. If the IEXk flag contains "Vulnerable”, it indicates that the CVEk vulnerability is indeed exploitable, and infers that such a vulnerability should be addressed, for example by installing an additional security program, adding upstream network protection , or by disabling the vulnerable functionality upstream. If the IEXk flag does not contain either of the two messages mentioned above, then it indicates that the means to exploit the CVEk vulnerability are not available to processes in the CNS namespace combination.
  • the IEXk indicator contains information making it possible to identify the CVEk vulnerability tested, for example the ID_CVEk identifier. This information can in particular be placed as a header in this indicator.
  • the attack vector is network type.
  • an attack exploiting this vulnerability is sent, coming from the network, to the IP address used by the process.
  • Such an attack vector can be reproduced locally with the second part of the detection program by sending network traffic to the local IP address 127.0.0.1.
  • the usability indicator IEXk as well as an IPn identifier of the computer EQn and an ICNS identifier of the CNS combination of namespaces are sent in the form of a Log signal, during step F40, to the device CNode for security management.
  • the Log signal is then received by the MIDA module of the CNode security management device which adds it to an LVNS list.
  • the steps described above are performed in parallel for a plurality of namespace combinations in each of these computers.
  • the steps described above are implemented for a plurality of CVE1-CVEm vulnerabilities and their corresponding P1-Pm detection programs.
  • the LVNS list thus constructed indicates in which combinations of namespaces and in which computers different given vulnerabilities can be exploited. This list then constitutes a map of vulnerabilities on a fleet of computers. It allows a central administrator to manage the security of the computer fleet. In particular, the central administrator can, from the LVNS list, determine in which namespaces to install security programs.
  • an MDETn module for detecting the exploitability of a vulnerability, conforming to a particular embodiment of the invention. It comprises : - an MD0 submodule for identifying a plurality of combinations of namespaces and respectively associated reference processes; - an MD10 submodule to receive an identifier of a computer vulnerability; - an MD20 submodule to install a program for detecting the exploitability of a vulnerability; - an MD30 submodule for creating a test process executing a program for detecting the exploitability of the vulnerability producing an indicator of this exploitability; - an MD40 submodule for sending, to a security management device, a signal including this indicator.
  • a MIDA module for identifying the exploitability of a vulnerability in a CNS combination of name spaces of a computer EQn, in accordance with a particular embodiment of the invention. It comprises : - an MS10 submodule to send an identifier of a computer vulnerability; - an MS40 submodule for receiving a signal comprising an IEXk indicator of the exploitability of the vulnerability, an ICNS identifier of the CNS combination and an IPn identifier of the computer EQn; - an MS50 submodule to record the signal in a list.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Procédé et module de détection de vulnérabilités informatiques dans un parc d'ordinateurs Procédé de détection mis en œuvre par un ordinateur (EQn) pour détecter l'exploitabilité d'une vulnérabilité informatique (CVEk) dans un ensemble de processus associés à une combinaison d'espaces de nommage, ledit procédé comportant, pour un processus de référence dudit ensemble, des étapes de : - initialisation (F30) à partir du processus de référence et exécution d'un processus de test associé à ladite combinaison et exécutant un programme (Pk) de détection, l'exécution (F30) dudit programme produisant un indicateur (IEXk) de l'exploitabilité de ladite vulnérabilité dans ledit ensemble de processus; - envoi (F40) à un dispositif de gestion de sécurité (CNode) d'au moins un signal (Log) comprenant ledit indicateur.

Description

Procédé et module de détection de vulnérabilités informatiques dans un parc d’ordinateurs
L’invention se rapporte au domaine général de la sécurisation des programmes informatiques.
L’invention vise plus particulièrement un procédé pour gérer la sécurité informatique d’une infrastructure d’équipements informatiques à l’aide de programmes de détection de vulnérabilités informatiques.
On rappelle que le terme vulnérabilité désigne une faille dans un processus informatique, cette faille permettant, si elle est exploitée, d’outrepasser des règles de sécurité du système informatique sur lequel le programme de ce processus est exécuté. Par exemple la vulnérabilité CVE-2021-44228 baptisée « Log4Shell » est présente dans le composant logiciel de journalisation Log4J. Le composant Log4J est utilisé par de nombreuses applications utilisant le langage Java. Cette vulnérabilité permet à un attaquant distant dans les cas les plus sévères de faire exécuter un code arbitraire par la machine cible. Un moyen technique qui permet à un attaquant d’exploiter cette vulnérabilité est appelé vecteur d’attaque. Un tel moyen technique est par exemple une instruction dans un programme informatique.
Une telle vulnérabilité, pour être exploitée, requiert la présence de ressources ou moyens logiciels et/ou matériels présentant des faiblesses. Par exemple, l’exploitation d’une vulnérabilité peut correspondre à l’envoi d’instructions sur un serveur particulier. Si un processus ne dispose pas de ressources permettant un tel envoi, alors cette vulnérabilité ne peut pas être exploitée dans ce processus. Le processus peut à l’inverse disposer de telles ressources, auquel cas la vulnérabilité est exploitable à condition qu’aucun programme de sécurité ne bloque les attaques visant à exploiter cette vulnérabilité.
Le terme processus désigne une représentation interne d’un programme en cours d’exécution dans la mémoire de l’ordinateur. Chaque fois qu’un programme est exécuté, un ou plusieurs processus sont créés.
De façon connue, les failles de sécurité sont répertoriées dans une liste publique accessible à l’adresse https://www.cve.org/ en mai 2022, chaque vulnérabilité référencée dans la liste étant identifiée par un identifiant unique CVE (pour Common Vulnerabilities and Exposures en anglais).
Des milliers d’identifiants CVE sont émis chaque année, et un logiciel complexe peut être concerné par des centaines de CVE.
La gestion des CVE pour maintenir la sécurité d’un parc d’équipements informatiques peut donc s’avérer excessivement complexe.
L’état de l’art ne permet pas, de manière satisfaisante d’établir, de connaître les failles exploitables et susceptibles de porter atteinte à la sécurité des ordinateurs.
L’invention vise à faciliter la gestion de la sécurité d’un parc d’ordinateurs en détectant les vulnérabilités informatiques exploitables sur ces ordinateurs. Corollairement, l’invention permet de renforcer la sécurité d’un parc d’ordinateurs.
Comme expliqué ci-après, l’invention propose d’évaluer l’exploitabilité des vulnérabilités au niveau des combinaisons d’espaces de nommage.
Dans le contexte de l’invention, on désigne ci-après par « espaces de nommage » des espaces de nommage de niveau noyau d’un système d’exploitation.
On rappelle qu’un espace de nommage isole, dans une abstraction, une instance d’une ressource système globale pour les processus associés à cet espace de nommage. Les modifications apportées à la ressource système dans un espace de nommage sont appliquées à tous les processus associés à cet espace de nommage, mais sont invisibles pour tous les autres processus. Les espaces de nommage offrent donc un mécanisme d’isolation des ressources.
De façon connue, le système d’exploitation Linux propose plusieurs espaces de nommage (par exemple : Network, IPC (pour Inter Process Communication en anglais), PID (pour Process IDentifier en anglais), User…) pour isoler des ensembles de processus.
Plus précisément, et selon un premier aspect, l’invention concerne un procédé de détection mis en œuvre par un ordinateur pour détecter l’exploitabilité d’une vulnérabilité informatique dans un ensemble de processus associés à une combinaison d’espaces de nommage, ledit procédé comportant, pour un processus de référence dudit ensemble, des étapes de :
- initialisation à partir du processus de référence et exécution d’un processus de test associé à ladite combinaison et exécutant un programme de détection, l’exécution dudit programme produisant un indicateur de l’exploitabilité de ladite vulnérabilité dans ledit ensemble de processus;
- envoi à un dispositif de gestion de sécurité d’au moins un signal comprenant ledit indicateur.
Corrélativement, l’invention propose un module de détection dans un ordinateur pour détecter l’exploitabilité d’une vulnérabilité informatique dans un ensemble de processus associés à une combinaison d’espaces de nommage, ledit module comportant, pour un processus de référence dudit ensemble :
- un sous-module d’initialisation à partir du processus de référence et d’exécution d’un processus de test associé à ladite combinaison et exécutant un programme de détection, l’exécution dudit programme produisant un indicateur de l’exploitabilité de ladite vulnérabilité dans ledit ensemble de processus;
- un sous-module d’envoi à un dispositif de gestion de sécurité d’au moins un signal comprenant ledit indicateur.
Ainsi, l’invention permet d’identifier les processus sur lesquels des vulnérabilités informatiques peuvent être exploitées. En particulier, le procédé permet d’identifier les processus présentant des faiblesses qui permettent à ces vulnérabilités d’être exploitées. De telles faiblesses résultent par exemple de ressources logicielles ou matérielles particulières.
Dans cette demande, on appelle combinaison d’espaces de nommage associée à un processus l’ensemble des espaces de nommage associés à ce processus. Par exemple, dans un système Linux, un processus peut être associé à une combinaison d’espaces de nommage contenant actuellement (en mai 2022) 9 espaces de nommage de types distincts.
Par la suite, on utilisera indifféremment les expressions « processus associé à une combinaison d’espaces de nommage » et « processus dans une combinaison d’espaces de nommage ».
Chaque combinaison d’espaces de nommage de l’ordinateur peut être identifiée de manière automatique. Le procédé permet avantageusement de déterminer un indicateur de l’exploitabilité d’une vulnérabilité dans une combinaison identifiée, sans avoir à tester cette exploitabilité pour chaque processus dans cette combinaison d’espaces de nommage.
Pour détecter l’exploitabilité d’une vulnérabilité (notamment une vulnérabilité CVE) dans une combinaison d’espaces de nommage, l’invention propose d’utiliser un seul processus dans cette combinaison. Ce processus est appelé processus de référence de la combinaison puisqu’il est utilisé pour initialiser un processus de test permettant de mettre en œuvre la détection d’exploitabilité dans cette combinaison. Le processus de test est par exemple créé comme un processus identique au processus de référence. Par initialisation d’un processus on entend ici la création suivie du déclenchement de l’exécution de ce processus.
Le processus de test a accès aux mêmes ressources attribuées par la combinaison d’espaces de nommage que tous les autres processus dans cette combinaison. De plus, le processus de test hérite, au moment de sa création, des variables d’environnement du processus de référence.
Dans un mode de mise en œuvre particulier du procédé de détection, ledit processus de référence est le processus de base de ladite combinaison.
Dans cette demande, le terme « processus de base de la combinaison » désigne le premier processus créé dans cette combinaison.
Le terme « variables d’environnement » désigne des types de valeurs pouvant être utilisées par des processus. Notamment, ces valeurs peuvent donner accès à certaines ressources. À titre d’exemple, sur un système Linux, la variable d’environnement <PATH> correspond à la liste du ou des répertoires dans lesquels sont situés des fichiers exécutables. Par exemple, un premier ensemble de processus est associé à une même valeur de la variable <PATH>, ce qui permettra à ces processus d’utiliser les fichiers exécutables localisés par cette valeur sans utiliser les chemins absolus vers ces fichiers. Dans ce même exemple, un deuxième ensemble de processus est associé à une valeur différente de la variable <PATH>. Les premier et deuxième ensembles de processus n’auront ainsi pas accès aux mêmes fichiers exécutables.
Par la suite, on utilisera indifféremment les expressions « variables d’environnement d’un processus » et « valeurs des variables d’environnement d’un processus », par souci de simplicité.
Cependant, bien qu’au moment de sa création, un processus donné d’une combinaison d’espaces de nommages hérite généralement des variables d’environnement du processus de base de cette combinaison, les variables d’environnement associées à ce processus donné peuvent changer au cours de sa vie.
Mais l’invention propose de faire abstraction de ce possible changement, et de considérer en approximation, que si une vulnérabilité est exploitable avec les variables d’environnement d’un processus d’une combinaison d’espaces de nommage (ci-après, un telle vulnérabilité sera désignée comme étant exploitable dans ce processus), alors cette vulnérabilité est exploitable avec les variables d’environnement de n’importe quel processus de la même combinaison d’espaces de nommage, y compris si ces variables d’environnement ont changé au cours de la vie de ce processus.
Inversement, l’invention propose de considérer en approximation, que si une vulnérabilité n’est pas exploitable avec les variables d’environnement d’un processus d’une combinaison d’espaces de nommage, alors cette vulnérabilité n’est exploitable avec les variables d’environnement d’aucun processus de la même combinaison d’espaces de nommage.
Les inventeurs ont constaté que les changements de variables d’environnement associées à un processus au cours de sa vie étaient peu courants, et n’affectaient généralement pas l’exploitabilité de ladite vulnérabilité.
Ainsi, la détection par le processus de test, de l’exploitabilité de la vulnérabilité est un indicateur fiable de l’exploitabilité réelle de la vulnérabilité dans la combinaison d’espaces de nommage.
Le processus de test exécute un programme de détection de l’exploitabilité de la vulnérabilité. Les informations générées par l’exécution du programme de détection indiquent l’exploitabilité de la vulnérabilité dans la combinaison d’espaces de nommage. Ces informations, sous forme d’un indicateur, remontent à un dispositif de gestion de sécurité et permettent notamment à l’utilisateur de ce dispositif de choisir les programmes de sécurité adéquats à installer.
Cet indicateur comprend au moins une donnée permettant d’identifier la vulnérabilité, par exemple un identifiant de cette vulnérabilité.
Dans un mode de réalisation de l’invention, le dispositif de gestion de sécurité est un serveur. Ainsi, l’invention peut être mise en œuvre par une pluralité d’ordinateurs dans un parc informatique, chacun de ces ordinateurs pouvant remonter, au serveur de gestion de sécurité, les informations sur l’exploitabilité d’une vulnérabilité dans leurs combinaisons d’espaces de nommage respectives.
Dans ce cas, le serveur de gestion de sécurité peut être contrôlé par un administrateur central qui a un rôle d’orchestration de la sécurité sur le parc d’ordinateurs.
Ainsi, ce mode de réalisation du procédé de détection permet d’identifier automatiquement et de façon centralisée quels programmes de sécurité installer et où les installer. Par programme de sécurité il est entendu un programme dont l’exécution empêche l’exploitation d’une vulnérabilité informatique.
L’invention permet aussi à l’administrateur central de s’affranchir de la nécessité de consulter de manière manuelle chaque administrateur de chaque ordinateur pour que chacun d’entre eux, par exemple, vérifie manuellement et localement si une vulnérabilité est présente dans les logiciels de leur machine, et le cas échéant si des mesures ont été prises pour la rendre inoffensive.
Selon un mode de réalisation du procédé de détection, l’exécution du programme de détection comporte :
- une détermination de la présence d’un ou plusieurs moyens d’exploitation de ladite vulnérabilité dans un environnement défini par au moins ladite combinaison d’espaces de nommage et les variables d’environnement dudit processus de référence ;
et, si un ou plusieurs dits moyens d’exploitation sont détectés :
- un test d’exploitation de ladite vulnérabilité avec ce ou ces moyens d’exploitation.
Dans ce mode de réalisation, l’évaluation, par le programme de détection, de l’exploitabilité de la vulnérabilité informatique est effectuée en deux temps.
Dans une première étape de détermination, il est déterminé si la ou les ressources nécessaires à l’exploitation de la vulnérabilité informatique sont présentes dans l’environnement du processus. L’environnement d’un processus comporte les ressources matérielles et logicielles accessibles au processus pour exécuter un programme. En l’occurrence, il est défini à minima par la combinaison d’espaces de nommage et par les variables d’environnement auxquelles ce processus est associé.
Si cette étape de détermination n’aboutit à la détection d’aucun moyen pour exploiter la vulnérabilité informatique, cela signifie que la vulnérabilité est considérée, en raison de l’approximation mentionnée ci-avant, comme non présente et donc non exploitable dans la combinaison d’espaces de nommage dans laquelle s’exécute le programme de détection.
Cependant, si la présence de tels moyens est détectée, cela n’implique pas forcément que la vulnérabilité est effectivement exploitable. Notamment, des programmes de sécurité peuvent empêcher l’exploitation de la vulnérabilité.
Ainsi, dans une deuxième étape, il est testé si la vulnérabilité est effectivement exploitable. Cette étape peut par exemple correspondre à l’exécution d’un vecteur d’attaque visant ladite vulnérabilité. Si ce vecteur d’attaque est consommé, cela signifie que la vulnérabilité est exploitable. Dans le cas contraire, la vulnérabilité n’est pas exploitable.
Autrement dit, dans cet exemple, une attaque test est exécutée. La réussite ou l’échec de cette attaque test détermine si la vulnérabilité informatique est exploitable ou non.
Dans un mode de réalisation particulier, le procédé de détection comporte des étapes de :
- réception, en provenance dudit dispositif de gestion de sécurité, d’un identifiant de ladite vulnérabilité ;
- installation, dans ledit ordinateur, dudit programme de détection correspondant audit identifiant.
Ainsi l’invention permet de gérer la sélection des vulnérabilités informatiques à détecter avec le dispositif de gestion de sécurité.
Dans le cas où le dispositif de gestion de sécurité est un serveur relié à un parc d’ordinateurs, des exécutions des programmes de détection sur chaque ordinateur peuvent alors être gérées de façon centralisée, sans demander la contribution des administrateurs d’au moins certains ordinateurs du parc, ce qui permet d’éviter l’installation manuelle de programmes de détection sur au moins certaines, par exemple sur toutes les machines du parc.
En outre, selon un mode de réalisation du procédé, les étapes d’initialisation d’un processus de test et d’envoi d’un signal au dispositif de gestion de sécurité sont réalisées pour plusieurs processus de référence respectivement associés à plusieurs combinaisons d’espaces de nommage.
Par conséquent, le procédé de détection peut avantageusement être réalisé en parallèle pour l’ensemble des combinaisons d’espaces de nommage d’un ou plusieurs ordinateurs, et ainsi assurer la sécurité de l’ensemble des processus de ce ou de ces ordinateurs.
Dans un mode particulier de mise en œuvre du procédé de détection, l’étape d’installation du programme de détection comporte des sous-étapes de :
- envoi, à un serveur de sécurisation, d’une requête comportant ledit identifiant de la vulnérabilité ;
- réception, en réponse à la requête, dudit programme de détection.
Cette utilisation d’un serveur de sécurisation permet avantageusement d’économiser de l’espace mémoire sur l’ordinateur.
Ce mode de réalisation permet également de mettre à disposition de l’ordinateur une base de données comportant une pluralité de programmes de détection d’exploitabilité de vulnérabilité informatique pouvant être installés au besoin, sur décision du serveur de gestion de sécurité.
Avantageusement, cette base de données externe peut être mise à jour indépendamment des administrateurs des ordinateurs du parc.
Dans un mode de réalisation particulier du procédé de détection, ledit au moins un signal comporte en outre :
- un identifiant dudit ordinateur ; et
- une donnée représentative de ladite au moins une combinaison.
Ces données permettent notamment à un administrateur central de cartographier des vulnérabilités informatiques et leur exploitabilité.
Selon un mode de réalisation de l’invention, le procédé de détection est caractérisé en ce que ledit ordinateur comprend un programme de protection contre l’exploitation de ladite vulnérabilité et en ce que ledit programme de protection est neutralisé lors de l’exécution dudit programme de détection.
Ce mode de réalisation permet d’évaluer plus précisément les vulnérabilités sur l’ordinateur. En particulier, il permet de tester si un programme de protection donné protège effectivement contre l’exploitation d’une vulnérabilité informatique donnée.
Si plusieurs programmes de protection sont installés, cela permet en outre d’identifier les programmes de protection inefficaces.
Selon un deuxième aspect, l’invention propose un procédé d’identification mis en œuvre par un dispositif de gestion de sécurité, pour identifier l’exploitabilité d’une vulnérabilité informatique dans au moins un ordinateur, ledit procédé comportant des étapes de :
- réception en provenance dudit au moins un ordinateur, d’un signal comprenant un indicateur de l’exploitabilité de ladite vulnérabilité dans un ensemble de processus associés à une combinaison d’espaces de nommage dudit au moins un ordinateur ;
- ajout à une liste dudit signal.
Corrélativement, l’invention propose un module d’identification dans un dispositif de gestion de sécurité, pour identifier l’exploitabilité d’une vulnérabilité informatique dans au moins un ordinateur, ledit module comportant :
- un sous-module de réception, en provenance dudit au moins un ordinateur, d’un signal comprenant un indicateur de l’exploitabilité de ladite vulnérabilité dans un ensemble de processus associés à une combinaison d’espaces de nommage dudit au moins un ordinateur ;
- un sous-module d’ajout à une liste dudit signal.
L’invention propose un procédé permettant d’identifier, à partir d’un dispositif (par exemple un serveur), une vulnérabilité informatique donnée dans un ordinateur ou un parc d’ordinateurs, ainsi que les combinaisons d’espaces de nommage dans lesquelles cette vulnérabilité est exploitable.
Les étapes du procédé d’identification décrit ci-dessus peuvent être répétées pour une pluralité de vulnérabilités informatiques données.
Cette identification de vulnérabilités informatiques et de leur exploitabilité permet avantageusement de faciliter l’orchestration de la sécurité sur le parc d’ordinateurs par un administrateur central contrôlant le dispositif de gestion de sécurité.
À cet effet, l’invention propose de mettre en commun les messages provenant des ordinateurs dans lesquels une ou plusieurs vulnérabilités exploitables ont été détectées, en ajoutant ces messages dans une liste.
Cette liste permet notamment à l’administrateur de prendre des décisions concernant la gestion de la sécurité dans le parc d’ordinateurs. Par exemple, la présence de certaines vulnérabilités dans des espaces de nommage particuliers peut inciter à installer des programmes de sécurité pour renforcer la sécurité des processus associés à ces espaces de nommage.
Selon un mode de réalisation de l’invention, le procédé d’identification comporte une étape d’envoi audit au moins un ordinateur, d’un identifiant de ladite vulnérabilité.
Cet envoi permet à l’administrateur du dispositif de gestion de sécurité de décider quels programmes de détection seront exécutés sur les ordinateurs du parc informatique. En effet, ce mode de réalisation permet, dans un mode de réalisation du procédé de détection décrit précédemment, d’installer et d’exécuter le programme de détection en réponse à l’envoi de l’identifiant de vulnérabilité par le dispositif de gestion de sécurité.
Chacun des procédés décrits ci-dessus peut être mis en œuvre par un programme informatique.
Par conséquent, l’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un dispositif informatique ou plus généralement dans un ordinateur. Ce programme comporte des instructions permettant la mise en œuvre d’un procédé tel que décrit ci-dessus.
Ce programme peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.
L’invention vise aussi un support d'informations ou un support d’enregistrement lisibles par un ordinateur et/ou un dispositif informatique, et comportant des instructions d’un programme d'ordinateur tel que mentionné ci-dessus.
Le support d'informations ou d’enregistrement peut être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, les supports peuvent comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur, ou une mémoire flash.
D'autre part, le support d'information ou d’enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par lien radio, par lien optique sans fil ou par d'autres moyens.
Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations ou d’enregistrement peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution de l’un des procédés tels que décrits précédemment.
Brève description des annexes et des figures
D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif.
Sur les annexes :
[Annexe. 1] L’annexe 1 représente une première partie d’un programme de détection pouvant être utilisé dans un mode particulier de réalisation ;
[Annexe. 2] L’annexe 2 représente une deuxième partie d’un programme de détection pouvant être utilisé dans un mode particulier de réalisation ;
Sur les figures :
la représente des dispositifs de détection et d’identification conformes à un mode particulier de réalisation ;
la représente sous forme d’ordinogramme les principales étapes de procédés de détection et d’identification pouvant être mis en œuvre dans un mode particulier de réalisation ;
la représente l’architecture fonctionnelle d’un module de détection conforme à un mode particulier de réalisation de l’invention ;
la représente l’architecture fonctionnelle d’un module d’identification conforme à un mode particulier de réalisation de l’invention.
 Description détaillée
La représente un mode particulier de réalisation de l’invention dans lequel les procédés de détection et d’identification sont mis en œuvre respectivement par des ordinateurs EQ1-EQ2 et un dispositif CNode de gestion de sécurité. Dans ce mode de réalisation, le dispositif CNode de gestion de sécurité a l’architecture matérielle d’un serveur informatique.
Dans cet exemple, l’invention est réalisée pour deux ordinateurs EQ1 et EQ2, mais l’invention ne limite pas le nombre d’ordinateurs. Elle peut être également appliquée à un unique ordinateur ou n’importe quel nombre d’ordinateurs, par exemple dans un parc informatique.
Par soucis de clarté, les détails de l’ordinateur EQ2 ne sont pas détaillés sur la , mais celui-ci comporte comme l’ordinateur EQ1 les composants permettant de mettre en œuvre le procédé de détection d’exploitabilité de vulnérabilité au sens de l’invention.
Les ordinateurs EQ1 et EQ2 comportent notamment un processeur 10, une mémoire vive de type RAM 11, une mémoire morte de type ROM 12, des moyens de communication 13 et une mémoire réinscriptible non volatile, par exemple un disque dur 14.
Chaque ordinateur EQn comporte un système logiciel SYSn. Dans cet exemple, le système logiciel SYS1 de l’ordinateur EQ1 comporte :
- un module de détection MDET1 conforme à l’invention ;
- un outil d’administration ADM1 associé à des droits de niveau administrateur ;
- une première combinaison CNS d’espaces de nommage à laquelle est associé un processus de base PrR, c’est-à-dire le premier processus créé dans cette combinaison d’espaces de nommage ;
- une deuxième combinaison CNS’ d’espaces de nommage à laquelle est associé un processus de base PrR’ ; et
- un répertoire Rep permettant d’enregistrer des programmes de détections P1, Pk, Pm, et sur lequel sont enregistrés les programmes P1 et Pk.
Les processus de test PrT et PrT’ exécutant le programme Pk dans leurs combinaisons d’espaces de nommage CNS et CNS’ respectivement associées sont créés lors d’une mise en œuvre du procédé de détection.
Le dispositif de gestion de sécurité CNode est doté de moyens de communication 13’ avec les ordinateurs EQ1 et EQ2 et d’un module COM de communication avec un utilisateur, par exemple un administrateur de l’ensemble d’ordinateurs EQ1-EQ2.
Le dispositif de gestion de sécurité CNode comporte également un module d’identification MIDA conforme à l’invention.
La représente sur un ordinogramme un mode de réalisation des étapes d’un procédé de détection et d’un procédé d’identification réalisées conjointement par le module MDETn de l’ordinateur EQn et le module MIDA du dispositif de gestion de sécurité.
Sur l’exemple représenté par la , la mise en œuvre du procédé de détection par un seul ordinateur est représentée. Un tel exemple sur un seul ordinateur EQn est représenté par soucis de simplicité mais n’est en rien limitatif de l’invention. En particulier, les procédés de détection et d’identification peuvent être mis en œuvre pour plusieurs ordinateurs en parallèle.
Le module MIDA envoie et reçoit des signaux ou des messages par l’intermédiaire des moyens de communications 13’ précités. Le module MDETn envoie et reçoit des signaux ou des messages par l’intermédiaire de moyens de communications 13 précités.
Les ordinateurs EQ1 et EQ2 sont configurés pour pouvoir communiquer avec un serveur de sécurisation SRV_SEC via un réseau de communication NET. Ce serveur de sécurisation SRV_SEC comporte une base de données BD. Cette base de données BD comporte un ensemble d’identifiants IF_CVE1, ID_CVEk, et ID_CVEm de vulnérabilités, chaque identifiant étant respectivement associé avec un programme de détection P1, Pk ou Pm configuré pour produire un indicateur de l’exploitabilité d’une vulnérabilité, lorsque le programme de détection correspondant est exécuté par un processus de test au sens de l’invention.
Le programme de détection Pk est par exemple directement envoyé par le serveur SRV_SEC vers un ordinateur EQn sous forme d’un programme exécutable, ou est, dans un autre exemple, envoyé sous forme d’un fichier de description puis transformé en fichier exécutable par l’ordinateur.
Un identifiant ID_CVEk de vulnérabilité est par exemple de la forme CVE-AAAA-IIII, où AAAA est l'année de publication et IIII un numéro unique.
Dans le mode de réalisation représenté sur la , les étapes des procédés de détections réalisées par le module MDETn de l’ordinateur EQn sont les suivantes :
- identification F0 de combinaisons CNS-CNS’ d’espaces de nommage et des processus de référence PrR-PrR’ associés ;
- réception F10 d’un identifiant ID_CVEk de la vulnérabilité CVEk en provenance du dispositif de gestion de sécurité CNode ;
- installation F20 d’un programme de détection Pk de l’exploitabilité de la vulnérabilité CVEk, cette installation comprenant les sous-étapes :
(i) d’envoi F201 au serveur SRV_SEC d’une requête REQ comprenant l’identifiant ID_CVEk ;
(ii) de réception F202, en provenance du serveur SRV_SEC, du programme Pk en réponse à l’envoi F201 ;
(iii) d’enregistrement F203 du programme Pk dans un répertoire Rep du système logiciel SYSn de l’ordinateur EQn ;
- initialisation F30 d’un processus de test PrT dans la même combinaison d’espaces de nommage CNS que le processus de référence PrR, et exécution du programme Pk par le processus de test PrT ; et
- envoi F40 vers le dispositif CNode d’un signal Log comportant un identifiant IPn de l’ordinateur EQn, un identifiant ICNS de la combinaison CNS d’espaces de nommage et un indicateur IEXk de l’exploitabilité de la vulnérabilité CVEk produit lors de l’exécution du programme Pk.
Dans ce mode de réalisation, le programme Pk comprend des instructions pour la mise en œuvre :
(i) d’une détection F301 de moyens d’exploiter la vulnérabilité CVEk parmi des ressources, ces ressources étant celles attribuées au processus qui exécutera ce programme Pk (processus de test au sens de l’invention) ; et
(ii) d’un test F302 d’exploitabilité de la vulnérabilité CVEk si de tels moyens sont détectés.
Dans ce mode de réalisation, et de façon conjointe, le module MIDA du dispositif CNode réalise des étapes suivantes selon un mode de réalisation du procédé d’identification :
- envoi E10 de l’identifiant ID_CVEk à l’ordinateur EQn ;
- réception E40 du signal Log en provenance de l’ordinateur EQn ; et
- ajout E50 du signal dans une liste.
Dans un mode de réalisation, les étapes d’initialisation d’un processus test F30 et d’envoi F40 par l’ordinateur EQn sont répétées ou effectuées en parallèle pour une ou plusieurs autres combinaisons d’espaces de nommage.
En particulier, dans un mode de réalisation, ces étapes F30 et F40 sont effectuées pour toutes les combinaisons CNS-CNS’ d’espaces de nommage identifiées lors de l’étape F0. Dans un mode particulier de mise en œuvre de l’invention dans le contexte d’un système d’exploitation Linux (marque déposée), on obtient typiquement une combinaison d’espaces de nommage par conteneur (en anglais « container »).
Dans un mode de réalisation, les combinaisons d’espaces de nommage identifiées sont toutes les combinaisons d’espaces de nommage accessibles via des droits de niveau administrateur de l’ordinateur EQn, ces droits étant procurés par le module ADMn de l’ordinateur.
Dans un mode de réalisation, ces combinaisons d’espaces de nommage sont obtenues à partir de l’obtention de la liste des espaces de nommage et les processus associés, accessibles via des droits administrateur. Pour chaque espace de nommage ainsi obtenu, un unique processus, parmi les processus associés à cet espace de nommage, est sélectionné comme processus de référence. Pour chaque processus de référence sélectionné, les différents espaces de nommage associés à ce processus sont identifiés. Comme expliqué ci-avant, les différents espaces de nommage associés à un processus forment la combinaison d’espaces de nommage à laquelle ce processus est associé. En conséquent, les combinaisons d’espaces de nommage et les processus de référence respectivement associés à ces combinaisons sont ainsi identifiés.
Dans un mode de réalisation, chaque processus de référence PrR-PrR’ d’une combinaison d’espaces de nommage CNS-CNS’ est le processus de base de cette combinaison, c’est-à-dire le premier processus créé dans cette combinaison.
Le processus de base d’un espace de nommage est par exemple identifiable à l’aide de la commande lsns dans le cas d’un système Linux.
Dans la suite de la description, on décrit, dans un mode de réalisation, l’étape d’initialisation F30 d’un processus de test PrT à partir d’un processus de référence PrR associé à une combinaison CNS. Cette étape permet de détecter l’exploitabilité de la vulnérabilité CVEk dans la combinaison d’espaces de nommage CNS. En particulier, l’étape F30 permet d’indiquer si les ressources allouées aux processus de cette combinaison CNS, permettent d’exploiter la vulnérabilité CVEk.
Le processus de test PrT est initialisé dans la même combinaison d’espaces de nommage CNS que le processus de référence PrR. Dans un mode de réalisation, le processus de test PrT est créé de telle sorte à disposer des mêmes variables d’environnement que le processus de référence. À cette fin, le processus de test PrT est par exemple créé comme identique au processus de référence, et hérite ainsi généralement de ses variables d’environnement.
Par exemple, dans un système Linux, le processus de test PrT est initialisé avec la fonction fork() appliquée au processus de référence.
Le processus de test PrT exécute un programme de détection Pk qui permet de détecter l’exploitabilité de la vulnérabilité CVEk. Dans un mode de réalisation, ce programme est composé de deux parties.
La première partie Script1k, dont l’exécution correspond à l’étape F301, vérifie si le processus de test dispose des moyens permettant de mettre en œuvre une attaque exploitant la vulnérabilité CVEk. Ces moyens correspondent entre autres aux ressources isolées par la combinaison d’espaces de nommage CNS ainsi que les ressources rendues accessibles par les variables d’environnement du processus de test PrT.
Quand bien même de tels moyens sont présents, la vulnérabilité peut ne pas être effectivement exploitable. Par exemple, des programmes de sécurité peuvent être mis en place dans la combinaison d’espaces de nommage CNS, de telle sorte qu’une attaque visant à exploiter la vulnérabilité CVEk serait bloquée. Le fait qu’une telle attaque soit bloquée ou non, autrement dit l’exploitabilité effective de la vulnérabilité, est déterminée par la seconde partie du programme de détection Pk.
La seconde partie Script2k du programme Pk, dont l’exécution correspond à l’étape F302, teste l’exploitabilité de la vulnérabilité CVEk. Cette partie vise à exploiter la vulnérabilité similairement à une attaque, mais sans conséquence nuisible sur l’ordinateur EQn.
L’exemple de la vulnérabilité CVE-2021-3156 permet d’illustrer l’exécution d’un programme de détection. Cette vulnérabilité qui affecte la commande sudo est particulièrement critique étant donné que sudo est utilisé dans de très nombreux environnements. Lorsqu’une commande est passée avec sudo, les arguments de la commande sont d’abord concaténés et les métacaractères sont échappés avec un antislash (par exemple, "\" devient "\\"). Lorsqu’un caractère spécial, par exemple [,{,(,\ ou ^, est lu en tant que caractère normal et non en tant que caractère spécial, il peut être précédé d’un antislash \. On appelle cela échapper un caractère.
En particulier, l’échappement décrit ici n’est pas effectué lorsque sudo est exécuté via le lien symbolique sudoedit -s. De ce fait, si un argument de la commande sudoedit se termine par un seul antislash, les arguments n’étant pas échappés par sudo, le programme va copier des caractères hors des limites du tampon mémoire (« buffer » en anglais), ce qui entraînera un dépassement de la mémoire tampon (« buffer overflow » en anglais).
Les annexes 1 et 2 correspondent respectivement aux première et deuxième parties Script1k et Script2k du programme de détection Pk dans le cas où la vulnérabilité CVEk est la vulnérabilité CVE-2021-3156. Dans cet exemple, le programme de détection Pk est codé en langage bash, ce qui ne représente en rien une limitation de l’invention. L’invention permet d’utiliser tout langage de programmation permettant à l’homme du métier de coder un programme de détection conforme à l’invention.
L’exécution du code Script1k dans l’annexe 1 vérifie la présence du lien symbolique sudoedit d’exécution du binaire sudo et enregistre un message « Might be vulnerable » dans un fichier « interface » si cette présence est détectée.
L’exécution du code Script2k dans l’annexe 2 lance l’exécution du fichier « exploit » qui correspond à l’utilisation de la commande sudoedit avec un seul antislash. Si cette exécution échoue, par exemple à cause d’un programme de sécurité bloquant toute utilisation de la commande sudoedit avec un antislash, aucun message n’est produit. Sinon, un message « Vulnerable » est enregistré dans le fichier « interface ».
Suite à l’exécution du programme de détection Pk, le fichier « interface » contient un indicateur IEXk de l’exploitabilité de la vulnérabilité CVEk. Si cet indicateur IEXk contient le message « Might be vulnerable » mais ne contient pas le message « Vulnerable », il indique alors que des moyens pour exploiter la vulnérabilité CVEk sont accessibles aux processus de la combinaison d’espaces de nommage CNS, mais que cette vulnérabilité n’est pas effectivement exploitable. Si l’indicateur IEXk contient « Vulnerable », il indique que la vulnérabilité CVEk est effectivement exploitable, et permet de déduire qu’une telle vulnérabilité doit être traitée, par exemple en installant un programme de sécurité supplémentaire, en ajoutant une protection réseau en amont, ou en désactivant la fonctionnalité vulnérable en amont. Si l’indicateur IEXk ne contient aucun des deux messages mentionnés ci-avant, alors il indique que les moyens d’exploiter la vulnérabilité CVEk ne sont pas accessibles aux processus de la combinaison d’espaces de nommage CNS.
En outre, l’indicateur IEXk contient une information permettant d’identifier la vulnérabilité CVEk testée, par exemple l’identifiant ID_CVEk. Cette information peut notamment être placée en en-tête dans cet indicateur.
Il est à noter que l’exemple ci-dessus ne limite en rien les contenus possibles d’un indicateur d’exploitabilité conforme à l’invention. Tout contenu donnant une indication claire sur l’exploitabilité de la vulnérabilité peut être choisi par l’homme du métier.
Dans un autre exemple de vulnérabilité, le vecteur d’attaque est de type réseau. Autrement dit, une attaque exploitant cette vulnérabilité est envoyée, en provenance du réseau, sur l’adresse IP utilisée par le processus. Un tel vecteur d’attaque peut être reproduit localement avec la deuxième partie du programme de détection par envoi du trafic réseau sur l’adresse IP locale 127.0.0.1.
L’indicateur IEXk d’exploitabilité ainsi qu’un identifiant IPn de l’ordinateur EQn et un identifiant ICNS de la combinaison CNS d’espaces de nommage sont envoyés sous forme d’un signal Log, lors de l’étape F40, au dispositif CNode de gestion de sécurité.
Le signal Log est ensuite reçu par le module MIDA du dispositif de gestion de sécurité CNode qui l’ajoute à une liste LVNS.
Dans un mode de réalisation, les étapes décrites précédemment sont effectuées en parallèle pour une pluralité de combinaisons d’espaces de nommage dans chacun de ces ordinateurs.
En outre, dans un mode de réalisation, les étapes décrites précédemment sont mises en place pour une pluralité de vulnérabilités CVE1-CVEm et leurs programmes de détection P1-Pm correspondant.
La liste LVNS ainsi construite indique dans quelles combinaisons d’espaces de nommage et dans quels ordinateurs différentes vulnérabilités données peuvent être exploitées. Cette liste constitue alors une cartographie des vulnérabilités sur un parc d’ordinateurs. Elle permet à un administrateur central de gérer la sécurité du parc d’ordinateurs. Notamment, l’administrateur central peut, à partir de la liste LVNS, déterminer dans quels espaces de nommage installer des programmes de sécurité.
La représente l’architecture fonctionnelle d’un module MDETn de détection d’exploitabilité d’une vulnérabilité, conforme à un mode particulier de réalisation de l’invention. Il comporte :
- un sous-module MD0 pour identifier un pluralité de combinaisons d’espaces de nommage et des processus de référence respectivement associés ;
- un sous-module MD10 pour recevoir un identifiant d’une vulnérabilité informatique ;
- un sous-module MD20 pour installer un programme de détection de l’exploitabilité d’une vulnérabilité ;
- un sous-module MD30 pour créer un processus de test exécutant un programme de détection de l’exploitabilité de la vulnérabilité produisant un indicateur de cette exploitabilité ;
- un sous-module MD40 pour envoyer, à un dispositif de gestion de sécurité, un signal comprenant cet indicateur.
La représente l’architecture fonctionnelle d’un module MIDA d’identification d’exploitabilité d’une vulnérabilité dans une combinaison CNS d’espaces de nommage d’un ordinateur EQn, conforme à un mode particulier de réalisation de l’invention. Il comporte :
- un sous-module MS10 pour envoyer un identifiant d’une vulnérabilité informatique ;
- un sous-module MS40 pour recevoir un signal comprenant un indicateur IEXk de l’exploitabilité de la vulnérabilité, un identifiant ICNS de la combinaison CNS et un identifiant IPn de l’ordinateur EQn ;
- un sous-module MS50 pour enregistrer le signal dans une liste.
[Annexe. 1]
ret=$(which sudoedit)
if [ ! –z $ret ]
then
echo "Might be vulnerable to $CVEID">>interface
fi
[Annexe. 2]
If [ $(echo "pwd"| ./exploit) = $(pwd) ] ; then ; echo "Vulnerable" >> ${interface}; fi

Claims (13)

  1. Procédé de détection mis en œuvre par un ordinateur (EQn) pour détecter l’exploitabilité d’une vulnérabilité informatique (CVEk) dans un ensemble de processus associés à une combinaison d’espaces de nommage (CNS), ledit procédé comportant, pour un processus de référence (PrR) dudit ensemble, des étapes de :
    - initialisation (F30) à partir du processus de référence (PrR) et exécution d’un processus de test (PrT) associé à ladite combinaison (CNS) et exécutant un programme (Pk) de détection, l’exécution (F30) dudit programme (Pk) produisant un indicateur (IEXk) de l’exploitabilité de ladite vulnérabilité (CVEk) dans ledit ensemble de processus ;
    - envoi (F40) à un dispositif de gestion de sécurité (CNode) d’au moins un signal (Log) comprenant ledit indicateur (IEXk).
  2. Procédé selon la revendication 1 dans lequel ledit processus de référence (PrT) est le processus de base de ladite combinaison (CNS).
  3. Procédé selon la revendication 1 ou 2 dans lequel l’exécution du programme (Pk) de détection comporte :
    - une détermination (F301) de la présence d’un ou plusieurs moyens d’exploitation de ladite vulnérabilité (CVEk) dans un environnement défini par au moins ladite combinaison d’espaces de nommage et au moins une variable d’environnement dudit processus de référence (PrR);
    et, si un ou plusieurs dits moyens d’exploitation sont détectés :
    - un test d’exploitation (F302) de ladite vulnérabilité (CVEk) avec ce ou ces moyens d’exploitation.
  4. Procédé selon l’une des revendications 1 à 3 comportant des étapes de :
    - réception (F10), en provenance dudit dispositif de gestion de sécurité (CNode), d’un identifiant (ID_CVEk) de ladite vulnérabilité (CVEk) ;
    - installation (F20), dans ledit ordinateur (EQn), dudit programme de détection (Pk) correspondant audit identifiant (ID_CVEk).
  5. Procédé selon la revendication 4 dans lequel ladite étape d’installation (F20) comporte des sous-étapes de :
    - envoi (F201), à un serveur de sécurisation (SRV_SEC), d’une requête (REQ) comportant ledit identifiant (ID_CVEk) de la vulnérabilité (CVEk) ;
    - réception (F202), en réponse à la requête (REQ), dudit programme (Pk) de détection.
  6. Procédé selon l’une des revendications 1 à 5, caractérisé en ce que ledit ordinateur (EQn) comprend un programme de protection (PMk) contre l’exploitation de ladite vulnérabilité (CVEk) et en ce que ledit programme de protection (PMk) est neutralisé lors de l’exécution dudit programme de détection (Pk).
  7. Procédé de détection selon l’une des revendications 1 à 6 dans lequel lesdites étapes d’initialisation (F30) et d’envoi (F40) sont réalisées pour chacun des processus de référence associés à une pluralité de combinaisons d’espaces de nommage.
  8. Procédé d’identification mis en œuvre par un dispositif de gestion de sécurité (CNode), pour identifier l’exploitabilité d’une vulnérabilité informatique (CVEk) dans au moins un ordinateur (EQn), ledit procédé comportant des étapes de :
    - réception (E40) en provenance dudit au moins un ordinateur (EQn), d’un signal (Log) comprenant un indicateur (IEXk) de l’exploitabilité de ladite vulnérabilité (CVEk) dans un ensemble de processus associés à une combinaison (CNS) d’espaces de nommage dudit au moins un ordinateur (EQn) ;
    - ajout (E50) à une liste (LVNS) dudit signal (Log).
  9. Procédé d’identification selon la revendication 8, dans lequel le dispositif de gestion de sécurité (CNode) effectue au moins une action parmi :
    - une installation d’au moins un programme de sécurité dans au moins un espace de nommage ;
    - un traitement de ladite vulnérabilité ;
    - une désactivation d’une fonctionnalité vulnérable ;
    - une mise en œuvre d’une politique de mitigation.
  10. Module de détection (MDETn) dans un ordinateur (EQn) pour détecter l’exploitabilité d’une vulnérabilité informatique (CVEk) dans un ensemble de processus associés à une combinaison d’espaces de nommage (CNS), ledit module comportant, pour un processus de référence (PrR) dudit ensemble :
    - un sous-module d’initialisation (MD30) à partir du processus de référence (PrR) et d’exécution d’un processus de test (PrT) associé à ladite combinaison (CNS) et exécutant un programme (Pk) de détection, l’exécution dudit programme (Pk) produisant un indicateur (IEXk) de l’exploitabilité de ladite vulnérabilité (CVEk) dans ledit ensemble de processus ;
    - un sous-module d’envoi (MD40) à un dispositif de gestion de sécurité (CNode) d’au moins un signal (Log) comprenant ledit indicateur (IEXk).
  11. Module d’identification (MIDA) dans un dispositif de gestion de sécurité (CNode), pour identifier l’exploitabilité d’une vulnérabilité informatique (CVEk) dans au moins un ordinateur (EQn), ledit module comportant :
    - un sous-module de réception (MS40), en provenance dudit au moins un ordinateur (EQn), d’un signal (Log) comprenant un indicateur (IEXk) de l’exploitabilité de ladite vulnérabilité (CVEk) dans un ensemble de processus associés à une combinaison (CNS) d’espaces de nommage dudit au moins un ordinateur (EQn) ;
    - un sous-module d’ajout (MS50) à une liste dudit signal (Log).
  12. Programme d'ordinateur comprenant des instructions qui, lorsque le programme est exécuté par un ordinateur, met en œuvre des étapes d’un procédé selon l’une des revendications 1 à 8.
  13. Support d’enregistrement, lisible par un ordinateur (EQn) et/ou un dispositif informatique (CNode), comprenant un programme informatique selon la revendication 12.
PCT/EP2023/060555 2022-05-16 2023-04-23 Procédé et module de détection de vulnérabilités informatiques dans un parc d'ordinateurs WO2023222330A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FRFR2204607 2022-05-16
FR2204607A FR3135545A1 (fr) 2022-05-16 2022-05-16 Procédé et module de détection de vulnérabilités informatiques dans un parc d’ordinateurs.

Publications (1)

Publication Number Publication Date
WO2023222330A1 true WO2023222330A1 (fr) 2023-11-23

Family

ID=84331511

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2023/060555 WO2023222330A1 (fr) 2022-05-16 2023-04-23 Procédé et module de détection de vulnérabilités informatiques dans un parc d'ordinateurs

Country Status (2)

Country Link
FR (1) FR3135545A1 (fr)
WO (1) WO2023222330A1 (fr)

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "Detecting the Exploitation of "Baron SamEdit" (CVE-2021-3156)", 5 February 2021 (2021-02-05), pages 1 - 6, XP093026226, Retrieved from the Internet <URL:https://www.anvilogic.com/learn/detecting-the-exploitation-of-baron-samedit-cve-2021-3156> [retrieved on 20230222] *
NOAM MOSCOVICH ET AL: "Autosploit: A Fully Automated Framework for Evaluating the Exploitability of Security Vulnerabilities", ARXIV.ORG, CORNELL UNIVERSITY LIBRARY, 201 OLIN LIBRARY CORNELL UNIVERSITY ITHACA, NY 14853, 30 June 2020 (2020-06-30), XP081701249 *
REEVES MICHAEL ET AL: "Towards Improving Container Security by Preventing Runtime Escapes", 2021 IEEE SECURE DEVELOPMENT CONFERENCE (SECDEV), IEEE, 18 October 2021 (2021-10-18), pages 38 - 46, XP034059497, DOI: 10.1109/SECDEV51306.2021.00022 *
ROJA C ET AL: "Syslog Daemon for Security Event Monitoring using UDP Protocol", 2019 3RD INTERNATIONAL CONFERENCE ON ELECTRONICS, COMMUNICATION AND AEROSPACE TECHNOLOGY (ICECA), IEEE, 12 June 2019 (2019-06-12), pages 1349 - 1354, XP033611278, DOI: 10.1109/ICECA.2019.8821956 *

Also Published As

Publication number Publication date
FR3135545A1 (fr) 2023-11-17

Similar Documents

Publication Publication Date Title
US10834108B2 (en) Data protection in a networked computing environment
Alrawi et al. The betrayal at cloud city: An empirical analysis of {Cloud-Based} mobile backends
US10771477B2 (en) Mitigating communications and control attempts
EP2705644B1 (fr) Procede et dispositif de detection d&#39;intrusions sur un ensemble de ressources virtuelles
US20160140209A1 (en) Categorising software application state
EP3063693A1 (fr) Systeme de detection d&#39;intrusion dans un dispositif comprenant un premier systeme d&#39;exploitation et un deuxieme systeme d&#39;exploitation
US10003602B2 (en) Determining email authenticity
WO2023222330A1 (fr) Procédé et module de détection de vulnérabilités informatiques dans un parc d&#39;ordinateurs
FR3057123A1 (fr) Procede et systeme de detection d&#39;intrusions sur un reseau
WO2022184998A1 (fr) Procede et module d&#39;installation d&#39;un programme de mitigation dans le noyau d&#39;un equipement informatique
WO2023161105A1 (fr) Procédé et module de détection de tentatives d&#39;attaques informatiques dans un parc d&#39;ordinateurs
EP3871381B1 (fr) Technique de collecte d&#39;informations relatives à un flux acheminé dans un réseau
EP3644146B1 (fr) Dispositif d&#39;enregistrement d&#39;intrusion informatique
EP3931694A1 (fr) Procédé d&#39;évaluation des dispositifs d&#39;une infrastructure de réseau en vue du déploiement d&#39;une fonction virtualisée
FR2864658A1 (fr) Controle d&#39;acces aux donnees par verification dynamique des references licites
FR3120143A1 (fr) Procédés de commande d’un dispositif de protection d’un élément d’un réseau, entité de commande et dispositif de protection
CN116132126A (zh) 恶意请求检测方法、装置、处理器及电子设备
WO2015067892A1 (fr) Procédé de protection de métadonnées
WO2021105617A1 (fr) Procede d&#39;assistance pour la gestion d&#39;une attaque informatique, dispositif et systeme associes
EP4367854A1 (fr) Procede et dispositif de configuration d&#39;une unite d&#39;acces dans un environnement virtualise
FR3137238A1 (fr) Procédé de suspension d’un jeton de certification permettant d’authentifier l’établissement d’une connexion entre deux équipements de communication, dispositifs et programmes d’ordinateur correspondants
FR2942053A1 (fr) Procede et systeme de validation d&#39;une commande de suspension d&#39;activite d&#39;au moins une ressource d&#39;un terminal
FR2901941A1 (fr) Procede, dispositif et systeme de diagnostique d&#39;un poste de travail informatique banalise
FR2929428A1 (fr) Procede et dispositif de detection de vers passifs dans un reseau de pairs

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23721399

Country of ref document: EP

Kind code of ref document: A1