Brevet FR3135545A1 — publié le 20231117

Titre de l'invention : 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. Fig. 2 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 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 , 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 . 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 Script1 k , 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 Script2 k 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 Script1 k et Script2 k 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 Script1 k 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 Script2 k 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 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). Procédé selon la revendication 1 dans lequel ledit processus de référence (PrT) est le processus de base de ladite combinaison (CNS). 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. 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). 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. 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). 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. 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). 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). 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). 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. Support d’enregistrement, lisible par un ordinateur (EQn) et/ou un dispositif informatique (CNode), comprenant un programme informatique selon la revendication 11.