Brevet FR3139965A1 — publié le 20240322

L’invention concerne un dispositif d’analyse de la conformité informatique d’un ensemble de systèmes d’information (38-40) distincts, chaque système d’information (38-40) comportant un ensemble de périphériques (41-44) sur lesquels un agent (30) est installé ; le dispositif d’analyse comportant : - un serveur général (50) sur lequel est stocké plusieurs collecteurs (25-26), chaque collecteur (25-26) correspondant à un programme informatique exécutable, par un agent (30), sur un périphérique (41-44) avec une configuration matérielle et/ou logicielle spécifique afin d’automatiser la recherche de plusieurs informations de conformité informatique en fonction des paramètres appliqués au collecteur (25-26) ; et - au moins une unité de centralisation (20) pour chaque système d’information (38-40), chaque unité de centralisation (20) étant connectée aux différents agents (30) de son système d’information (38-40) et au serveur général (50), l’unité de centralisation (20) étant configurée pour détecter de nouveaux périphériques (41-44), rechercher les collecteurs (5) et commander les agents (30). Figure pour abrégé : figure 1. DISPOSITIF D’ANALYSE DE LA CONFORMITE INFORMATIQUE D’UN ENSEMBLE DE SYSTEMES D’INFORMATION DISTINCTS Domaine de l’invention L’invention concerne le domaine de la sécurité informatique et, elle vise plus particulièrement, l’analyse du niveau de sécurité informatique d’un ensemble de systèmes d’information afin de permettre à des opérateurs de mettre en place les éventuels correctifs de sécurités nécessaires. Au sens de l’invention, un « système d’information » est un ensemble organisé de ressources qui permet de collecter, stocker, traiter et distribuer de l’information, grâce à un réseau de périphériques, par exemple des ordinateurs. Un opérateur peut correspondre à un responsable de la sécurité des systèmes d’information, ou RSSI, également appelé CISO pour « Chief Information Security Officer » dans la littérature anglo-saxonne, ou tout autre personne en charge de la sécurité d’un système d’information. La sécurité informatique des systèmes d’information connait un besoin croissant avec le développement du numérique et de la dématérialisation. Ainsi, la problématique d’analyse de la conformité des périphériques d’un système d’information concerne désormais tous les secteurs. Par exemple, l’invention peut être utilisée pour analyser la conformité des équipements informatique d’un système d’information d’une entreprise ou d’une collectivité territoriale. Art antérieur Il existe plusieurs solutions permettant d’analyser la conformité des périphériques d’un système d’information à des objectifs de sécurité. Certaines solutions utilisent des logiciels malveillants pour tester la résistance des ordinateurs d’un système d’information aux tentatives d’intrusions, de manière analogue aux pratiques qui pourraient être utilisées par un pirate informatique. Pour ce faire, le document EP 3643036 propose d'utiliser un agent installé sur chaque ordinateur d’un système d’information. L’agent est utilisé pour lancer des attaques préprogrammées sur les différents ordinateurs afin d'obtenir un score de vulnérabilité en fonction des failles détectées lors de ces attaques. Par exemple, une attaque consiste à lancer un programme malveillant de collecte des mots de passe administrateur des périphériques. Cependant, ces solutions utilisant des simulations d’attaques sont peu fiables pour analyser la résistance d’un système d’information aux attaques que peuvent mener les pirates informatiques car les stratégies d’attaques des pirates informatiques évoluent constamment. En outre, ces solutions doivent présenter des algorithmes très distincts d’un système d’exploitation à un autre. Or, dans un système d’information, plusieurs systèmes d’exploitation peuvent cohabiter, qui plus est avec des versions différentes. Par exemple, le réseau d’une entreprise peut permettre l’accès à des téléphones fonctionnant avec le système d’exploitation de Google ou d’Apple alors que les ordinateurs et les serveurs peuvent présenter des systèmes d’exploitation de Microsoft avec plusieurs version distinctes. Dans ces conditions, un agent réalisant des simulations d’attaques sur ces différents systèmes d’exploitation serait très complexe à mettre en œuvre car il devrait intégrer les possibilités d’inspection de tous les systèmes, ou il devrait être différent d’un système à un autre. En tous les cas, il serait nécessaire de mettre à jour l’agent à chaque modification des composants matériels et/ou logiciels. Une autre solution consiste à détecter les modifications réalisées par les utilisateurs ou les logiciels malveillants présents sur les ordinateurs d’un système d’information. Pour ce faire, chaque système d’exploitation du système d’information est dupliqué sous la forme d’une configuration de référence stockée sur un serveur. Un agent installé sur les ordinateurs du système d’information est configuré pour comparer périodiquement la configuration de l’ordinateur sur lequel il est installé avec la configuration de référence pour détecter des éventuelles failles de sécurité. Cette solution est par exemple décrite dans le document US 10,412,120. Cette solution pose encore le problème de l’interopérabilité de la solution car il convient d’utiliser un grand nombre de configurations de référence et de les mettre à jour régulièrement pour pouvoir détecter les éventuelles failles de sécurités d’un ensemble de périphériques présentant des systèmes d’exploitation et/ou des versions distincts. Dans tous les cas, avec ces deux premières solutions, des failles de sécurités peuvent être exploitées lorsqu’un ordinateur est connecté sur le réseau sans que l’agent ne soit installé. Pour résoudre ce problème, une autre solution consiste à analyser l’ensemble des informations transmises par le réseau d’un système d’information pour détecter des communications provenant éventuellement d’un logiciel malveillant. En effet, un logiciel malveillant est souvent configuré pour communiquer avec un pirate informatique distant. Pour ce faire, des communications réseaux génèrent classiquement un trafic réseau à des heures inattendues, à destination ou en provenance d’adresses réseaux suspectes. Par exemple, lorsqu’un trafic réseau important est constaté entre 23h et minuit alors que l’utilisateur de l’ordinateur n’est pas présent dans une entreprise, il peut être considéré que ce trafic provient d’un logiciel malveillant si l’adresse réseau à destination de ce trafic ne correspond pas à une adresse connue, typiquement l’adresse d’un serveur de mis à jour. Une telle solution est par exemple décrite dans le document US 10,686,825. Cependant, cette solution permet uniquement de détecter, au cours du temps, l’utilisation d’une faille de sécurité mais elle ne permet pas de traiter les causes de cette faille de sécurité. De nos jours, la solution la plus efficace pour traiter les causes des failles de sécurité est encore de faire une analyse de la conformité de l’ensemble des périphériques d’un système d’information avec un ensemble de recommandations de sécurité. Ces recommandations sont classiquement fournies dans un référentiel qui peut prendre la forme d'une norme ou d'un guide rédigé par un organisme agréé, par exemple en France, l'Autorité Nationale en matière de Sécurité et de défense des Systèmes d'Information (ANSSI). L’ANSSI propose 40 mesures principales visant à garantir la sécurité d’un système d’information, ainsi que deux mesures facultatives. La catégorie « SENSIBILISER ET FORMER » regroupe les trois mesures suivantes : 1. Former les équipes opérationnelles à la sécurité des systèmes d'information ; 2. Sensibiliser les utilisateurs aux bonnes pratiques élémentaires de sécurité informatique ; et 3. Maîtriser les risques de l'infogérance. La catégorie « CONNAITRE LE SYSTEME D'INFORMATION » regroupe les quatre mesures suivantes : 4. Identifier les informations et serveurs les plus sensibles et maintenir un schéma du réseau ; 5. Disposer d’un inventaire exhaustif des comptes privilégiés et le maintenir à jour ; 6. Organiser les procédures d’arrivée, de départ et de changement de fonction des utilisateurs ; et 7. Autoriser la connexion au réseau de l’entité aux seuls équipements maîtrisés. La catégorie « AUTHENTIFIER ET CONTRÔLER LES ACCES » regroupe les onze mesures suivantes : 8. Identifier nommément chaque personne accédant au système et distinguer les rôles utilisateur/administrateur ; 9. Attribuer les bons droits sur les ressources sensibles du système d’information ; 10. Définir et vérifier des règles de choix et de dimensionnement des mots de passe ; 11. Protéger les mots de passe stockés sur les systèmes ; 12. Changer les éléments d’authentification par défaut sur les équipements et services ; 13. Privilégier lorsque c’est possible une authentification forte ; 14. Mettre en place un niveau de sécurité minimal sur l’ensemble du parc informatique ; 15. Se protéger des menaces relatives à l’utilisation de supports amovibles ; 16. Utiliser un outil de gestion centralisée afin d’homogénéiser les politiques de sécurité ; 17. Activer et configurer le pare-feu local des postes de travail ; et 18. Chiffrer les données sensibles transmises par voie Internet. La catégorie « SECURISER LE RESEAU » regroupe les huit mesures suivantes : 19. Segmenter le réseau et mettre en place un cloisonnement entre ces zones ; 20. S’assurer de la sécurité des réseaux d’accès Wi-Fi et de la séparation des usages ; 21. Utiliser des protocoles réseaux sécurisés dès qu’ils existent ; 22. Mettre en place une passerelle d’accès sécurisé à Internet ; 23. Cloisonner les services visibles depuis Internet du reste du système d’information ; 24. Protéger sa messagerie professionnelle ; 25. Sécuriser les interconnexions réseau dédiées avec les partenaires ; et 26. Contrôler et protéger l’accès aux salles serveurs et aux locaux techniques. La catégorie « SECURISER L'ADMINISTRATION » regroupe les trois mesures suivantes : 27. Interdire l’accès à Internet depuis les postes ou serveurs utilisés pour l’administration du système d’information ; 28. Utiliser un réseau dédié et cloisonné pour l’administration du système d’information ; et 29. Limiter au strict besoin opérationnel les droits d’administration sur les postes de travail. La catégorie « GERER LE NOMADISME » regroupe les quatre mesures suivantes : 30. Prendre des mesures de sécurisation physique des terminaux nomades ; 31. Chiffrer les données sensibles, en particulier sur le matériel potentiellement perdable ; 32. Sécuriser la connexion réseau des postes utilisés en situation de nomadisme ; et 33. Adopter des politiques de sécurité dédiées aux terminaux mobiles. Pour finir, la catégorie « MAINTENIR LE SYSTEME D'INFORMATION A JOUR » regroupe les sept mesures suivantes : 34. Définir une politique de mise à jour des composants du système d’information ; 35. Anticiper la fin de la maintenance des logiciels et systèmes et limiter les adhérences logicielles ; 36. Activer et configurer les journaux des composants les plus importants ; 37. Définir et appliquer une politique de sauvegarde des composants critiques ; 38. Procéder à des contrôles et audits de sécurité réguliers puis appliquer les actions correctives associées ; 39. Désigner un référent en sécurité des systèmes d’information et le faire connaître auprès du personnel ; et 40. Définir une procédure de gestion des incidents de sécurité. Pour analyser la sécurité informatique d’un système d’information à partir de ce guide de l’ANSSI, un RSSI analyse la structure et la gestion du réseau du système d’information, ainsi que les mesures de sécurité mises en place sur chaque périphérique du système d’information. Pour ce faire, le RSSI doit donc se connecter sur chaque périphérique pour rechercher, par exemple, si l’accès au périphérique est protégé par un mot de passe (mesure 11) ou si le système d’exploitation du périphérique est à jour (mesure 34). Classiquement, cette analyse est réalisée tous les 6 mois ou tous les ans, compte tenu du temps nécessaire pour rechercher toutes les informations requises. En fonction de la conformité ou non du système d’information à l’ensemble des recommandations de l’ANSSI, il est possible d’obtenir un score de sécurité informatique. La définition de ce score peut prendre en compte différents poids en fonction de l’importance de chaque catégorie. Par exemple, le document US 10,592,938 propose de calculer un score de sécurité informatique d’un système d’information en fonction de réponses fournies sur la base d’un questionnaire reprenant une grande partie des recommandations de l’ANSSI. Le problème de cette solution réside dans le temps d’analyse, qui empêche que l’analyse ne soit réalisée suffisamment souvent, si bien que des failles de sécurité peuvent apparaitre entre deux analyses et il est possible de devoir attendre plusieurs mois avant de détecter ces failles de sécurité lors de la prochaine analyse. En outre, la stratégie de recherche des vulnérabilités d’un système d’information peut également évoluer à mesure de la détection de nouvelles failles de sécurité sur les systèmes d’exploitation. Par exemple, il peut être détecté qu’un logiciel malveillant utilise une communication à travers un navigateur avec un port spécifique. Suite à cette détection, la stratégie de recherche des vulnérabilités d’un système d’information peut être mise à jour pour rechercher si les périphériques du système d’information autorisent ou non l’utilisation de ce port avec ce navigateur afin de vérifier si ces périphériques sont sensibles à ce type de logiciel malveillant. En mettant en œuvre une analyse tous les ans, une telle faille de sécurité peut nécessiter un temps long avant d’être détectée. Pour limiter ce temps de détection et obtenir une interface de gestion centralisée de plusieurs périphériques de plusieurs réseaux, le document WO2009/101155 propose d’utiliser un agent de sécurisation installé sur chaque périphérique des différents réseaux. Cet agent de sécurisation effectue une recherche des configurations matérielles et logicielles de chaque périphérique pour définir un profil du périphérique. Ce profil est transmis à un serveur de sécurisation, externe aux différents réseaux, qui émet des requêtes de sécurité à exécuter par l’agent de sécurisation en fonction du profil. Il est ainsi possible de mettre à jour de manière centralisée les recherches des vulnérabilités à réaliser par les différents agents et d’effectuer ces recherches très régulièrement, par exemple tous les jours. Cependant, cette gestion centralisée ne permet pas de détecter des périphériques présents sur un des différents réseaux et sur lequel l’agent n’est pas installé. Par exemple, l’ajout d’une nouvelle imprimante sur un réseau peut présenter une faille de sécurité informatique si un logiciel malveillant est présent sur le système d’exploitation de cette imprimante. Avec cette gestion centralisée, tant qu’un opérateur ne procède pas à l’installation d’un agent sur l’imprimante, le logiciel malveillant ne peut pas être détecté. De plus, les échanges périodiques entre tous les agents et le serveur de sécurisation externe aux différents réseaux nécessitent de nombreuses communications réseaux, augmentant le vieillissement des équipements réseaux, le risque de piratage informatique et dégradant le bilan carbone de l’ensemble de la solution de gestion centralisée. Le problème technique de l’invention est donc d’obtenir une analyse de la conformité informatique d’un ensemble de périphériques de systèmes d’information distincts, permettant une gestion centralisée et une détection plus efficace de vulnérabilités, notamment des vulnérabilités associées à des nouveaux périphériques. Pour répondre à ce problème technique, l’invention propose d’utiliser des agents installés sur chaque périphérique des systèmes d’information, une unité de centralisation présente dans chaque système d’information pour détecter de nouveaux périphériques sans agent installé, et un serveur général connecté aux différentes unités de centralisation des différents systèmes d’information pour mettre à jour les recherches de vulnérabilité lors de la détection d’une nouvelle faille de sécurité. Pour limiter les communications réseaux, les différentes unités de centralisation commandent les différents agents de leurs systèmes d’information en utilisant un collecteur stocké sur le serveur général. Au sens de l’invention, un « collecteur » correspondant à un programme informatique exécutable, par un agent, sur un périphérique avec une configuration matérielle et/ou logicielle spécifique. Un collecteur peut être créé pour exécuter une ou plusieurs mesures. Les agents sont des programmes qui permettent de détecter la configuration matérielle et/ou logicielle des périphériques, d’installer les collecteurs et d’exécuter les collecteurs en fonction de paramètres spécifiques. Ainsi, l’invention propose d’automatiser les mesures pour simplifier l’analyse de la conformité informatique d’un ensemble de systèmes d’informations. Il s’ensuit que les mesures attendues peuvent être réalisées très souvent, par exemple une fois par jour ou une fois par heure, et que les collecteurs réalisant ces mesures peuvent être mis à jour de manière centralisée lorsqu’une nouvelle faille est détectée. A cet effet, l’invention concerne un dispositif mis en œuvre par ordinateur d’analyse de la conformité informatique d’un ensemble de systèmes d’information distincts, chaque système d’information comportant un ensemble de périphériques sur lesquels un agent est installé ; le dispositif d’analyse comportant : - un serveur général sur lequel est stocké plusieurs collecteurs, chaque collecteur correspondant à un programme informatique exécutable, par un agent, sur un périphérique avec une configuration matérielle et/ou logicielle spécifique afin d’automatiser la recherche de plusieurs informations de conformité informatique en fonction des paramètres appliqués au collecteur ; et - au moins une unité de centralisation pour chaque système d’information, chaque unité de centralisation étant connectée aux différents agents de son système d’information et au serveur général ; chaque unité de centralisation intégrant : - un module de détection de nouveaux périphériques présents sur son système d’information et ne disposant pas d’agent installé ; - un module de récupération des configurations matérielles et/ou logicielles des périphériques pour lesquels des agents sont installés ; - un module de recherche et de transmission aux agents des collecteurs stockés sur le serveur général et associés aux configurations matérielles et/ou logicielles des périphériques sur lesquels les agents sont installés ; - un module d’exécution d’une stratégie de recherche, le module commandant les différents agents afin qu’ils exécutent leurs collecteurs avec des paramètres spécifiques définis dans la stratégie de recherche ; et - un module de centralisation des résultats des différents agents obtenus suite à l’exécution de leurs collecteurs avec les paramètres spécifiques. Ainsi, l’unité de centralisation de chaque système d’information peut récupérer le ou les collecteurs nécessaires pour son système d’information et les transmettre aux différents agents. Pour propager des mises à jour de ces collecteurs, l’unité de centralisation peut rechercher périodiquement si des mises à jour des collecteurs ont été effectuées. En variante, le serveur général peut informer les différentes unités de centralisation lorsqu’une mise à jour est réalisée. Par ailleurs, la stratégie de recherche peut également être centralisée sur le serveur général. La stratégie de recherche intègre préférentiellement la liste des commandes à appliquer aux agents avec la fréquence d’exécution de chaque commande, la destination, et la description du collecteur et des paramètres à utiliser. Lorsque la stratégie de recherche est stockée sur le serveur général, le module d’exécution de chaque unité de centralisation récupère la stratégie de recherche sur le serveur général afin de déterminer comment commander les différents agents. Pour ce faire, le serveur général peut comporter un espace dédié à chaque unité de centralisation intégrant une stratégie de recherche et au moins un collecteur associé aux configurations matérielles et/ou logicielles des périphériques du système d’information de l’unité de centralisation. De préférence, le serveur général intègre un collecteur par mesure à réaliser. Les résultats des différentes recherches peuvent être stockés sur l’unité de centralisation de chaque système d’information et/ou sur le serveur général. Lorsque les résultats des différentes recherches sont stockés sur le serveur général, l’espace dédié à chaque unité de centralisation intègre également un fichier référentiel ; le module de centralisation des résultats des différents agents obtenus automatiquement suite à l’exécution de leurs collecteurs retransmettant périodiquement les résultats collectés au fichier référentiel. Par exemple, les résultats peuvent être retransmis une fois par jour pour limiter les échanges réseaux entre l’unité de centralisation de chaque système d’information et le serveur général. Outre ces mesures automatisées, le serveur général comporte préférentiellement une interface de modification manuelle de chaque fichier référentiel de sorte qu’un administrateur d’un système d’information puisse renseigner des informations obtenues manuellement sur le système d’information et/ou les périphériques du système d’information. Ces mesures obtenues manuellement correspondent à des mesures déclaratives qui s’appliquent à un périphérique ou tout autre organe (routeur, pare-feu) d’un système d’information ou encore à un élément de la composante humaine de ce même système. Par exemple, une mesure déclarative peut correspondre à une information selon laquelle la personne associée au profil utilisateur d’un périphérique a pris connaissance et signé une charte informatique. Pour un autre exemple, une mesure déclarative peut correspondre à des informations sur un routeur de connexion sans fil : niveau de sécurité, périodicité de modification des mots de passe, affichage ou non du réseau, filtrage par adresse physique… De préférence, lorsqu’un nouveau périphérique est détecté par le module de détection d’une unité de centralisation, une demande est transmise à un opérateur afin qu’une mesure déclarative soit réalisée en parallèle de l’installation de l’agent et des mesures automatisées. En ce qui concernent les mesures automatisées, il est possible de mettre en place des sécurités pour garantir la conformité de ces mesures. De préférence, la communication établie entre chaque agent et chaque unité de centralisation et entre chaque unité de centralisation et le serveur général correspond à une communication utilisant un protocole sécurisé, par exemple le protocole SFTP, SSH. En outre, le module de récupération des configurations matérielles et/ou logicielles des périphériques pour lesquels des agents sont installés peut réaliser un contrôle d’intégrité des agents. De la même manière, le module d’exécution d’une stratégie de recherche peut réaliser un contrôle d’intégrité des agents avant de commander l’exécution des collecteurs. L’agent peut correspondre à un service Microsoft Windows ou un daemon Linux installé sur un système d’exploitation d’un périphérique. Bien entendu, d’autres systèmes d’exploitation peuvent être utilisés sans changer l’invention et en adaptant l’agent. Pour installer l’agent sur chaque périphérique du réseau, un opérateur peut se déplacer physiquement au niveau de chaque périphérique pour installer cet agent. De préférence, l’agent est déployé depuis l’unité de centralisation. Par exemple, l’opérateur peut commander manuellement le déploiement de l’agent par l’intermédiaire d’une commande depuis l’unité de centralisation. L’agent peut également être déployé automatiquement, par exemple au moyen d’un paquet d’installation transmis selon une stratégie de groupe d’une forêt Microsoft Active Directory. En effet, une stratégie de groupe, également appelée GPO pour « Group Policy Objects » dans la littérature anglo-saxonne, permet de transmettre automatiquement des paquets d’installation, par exemple en utilisant le protocole installateur Windows ou « Windows Installer » dans la littérature anglo-saxonne. L’unité de centralisation peut également être configurée pour mettre à jour l’agent. Ce processus de mise à jour peut également être utilisé par l’unité de centralisation pour installer automatiquement une nouvelle version de l’agent. L’unité de centralisation correspond préférentiellement à un boitier physique connecté sur le réseau avec une carte mère, un processeur et une carte réseau connectée sur le réseau du système d’information. En variante, l’unité de centralisation peut être implémentée sous la forme d’un logiciel sur un périphérique du système d’information, par exemple un serveur physique ou virtuel. L’unité de centralisation et/ou le serveur général comporte ou a accès à une mémoire de stockage permettant de regrouper les résultats des différentes mesures. De préférence, pour interpréter ces mesures, le module d’estimation est configuré pour associer un score à chaque mesure de chaque périphérique ; un objectif de sécurité pour une recommandation précise étant obtenu en calculant la somme des valeurs des mesures des périphériques divisée par le nombre de périphériques mesurés. A partir de ces mesures, l’unité de centralisation et/ou le serveur général peut directement intégrer une interface de visualisation de la conformité de chaque périphérique d’un système d’information avec un ensemble de recommandations. Cette interface est alors accessible à un opérateur, par exemple un responsable de la sécurité du système d’information. En outre, l’unité de centralisation et/ou le serveur général peut également être configuré pour déclencher automatiquement une alerte lorsqu’un ou plusieurs périphériques ne sont pas conformes à une recommandation de sécurité. Description sommaire des figures La manière de réaliser l’invention ainsi que les avantages qui en découlent, ressortiront bien des modes de réalisation qui suivent, donnés à titre indicatif mais non limitatif, à l’appui des figures 1 et 2 dans lesquelles : est une représentation schématique d’un dispositif d’analyse de la conformité informatique d’un ensemble de systèmes d’information distincts selon un mode de réalisation de l’invention ; et est une représentation schématique d’une unité de centralisation associée à trois agents d’un dispositif d’analyse selon la . Description détaillée de l’invention La illustre un dispositif d’analyse 10 de trois systèmes d’information 38 - 40 , par exemple des systèmes d'information 38 - 40 d'entreprises et/ou de collectivités. Chaque système d'information 38 - 40 comporte, par exemple, un firewall, un routeur, des ordinateurs et d'autres périphériques, tels que des copieurs ou des serveurs. Ainsi, chaque système d'information 38 - 40 peut être composé d'un ensemble de périphériques 41-44 divers et variés fonctionnant avec des moyens matériels et logiciels divers. Ces périphériques 41-44 sont connectés sur un réseau ou une pluralité de sous réseaux connectés entre eux. Plusieurs périphériques 41-44 intègrent un agent 30 . Tel qu'illustré sur la , il n'est pas nécessaire qu’un agent 30 soit installé sur tous les périphériques 41-44 même si cette configuration est préférable pour avoir une supervision complète du niveau de sécurité informatique d'un système d'information 38 - 40 . Par exemple, un périphérique tel qu’une imprimante 44 ou un climatiseur peut être connecté au réseau sans qu’il ne soit possible d’installer un agent car ce matériel peut être géré par une société externe. Outre les agents 30 , le dispositif d’analyse 10 comporte également une unité de centralisation 20 connectée à l’intérieur de chaque système d'information 38 - 40 . L'unité de centralisation 20 peut correspondre à un boîtier physique intégrant une carte mère, un processeur, de la mémoire et une carte réseau. En variante, l'unité de centralisation 20 peut correspondre à un logiciel installé sur un périphérique 41-44 , par exemple sur le firewall ou sur le routeur. L'agent 30 correspond préférentiellement à des moyens logiciels, par exemple un service Microsoft Windows ou un daemon Linux. Contrairement aux solutions de l'état de la technique utilisant des agents très complexes, l’invention permet d'utiliser un agent 30 très simple comportant uniquement, tel qu'illustré sur la , un module de communication 21 , un module d'identification 22 , et un module d'exécution 23 . Ces différents modules 21 à 23 peuvent correspondre à des fonctions d'un programme informatique par exemple. Le module de communication 21 est connecté à la carte réseau du dispositif périphérique 41-43 sur lequel l'agent 30 est installé et il permet de communiquer avec l’unité de centralisation 20 . Le module d'identification 22 permet de détecter les composants matériels et/ou logiciels du périphériques 41-43 sur lequel l'agent 30 est installé. Par exemple, lorsqu'une connexion est réalisée entre un agent 30 et le l'unité de centralisation 20 , l'agent 30 peut afficher le code « WIN » si le système d'exploitation sur lequel l'agent 30 est installé correspond un système d’exploitation Windows ou le code « LIN » lorsque le système d'exploitation sur lequel l'agent 30 est installé correspond à un système d'exploitation Linux. Outre le module d'identification 22 , l'agent 30 comporte également un module d'exécution 23 configuré pour exécuter des requêtes transmises par l'unité de centralisation 20 et pour envoyer, à l'unité de centralisation 20 , le résultat de ces requêtes. L’unité de centralisation 20 comporte quant à elle un module 31 de détection de nouveaux périphériques. Ce module 31 est connecté sur le port réseau 36 de l’unité de centralisation 20 et observe les communications échangées sur le réseau pour vérifier que les adresses utilisées pour ces communications présentent un émetteur et/ou un destinataire connu. Pour ce faire, le module 31 peut utiliser un fichier ConfAgents intégrant les adresses physiques Add des périphériques 41-43 sur lesquels l'agent 30 est installé. Lorsqu’une adresse physique d’une communication n’est pas associée à une adresse physique Add du fichier ConfAgents , le module 31 tente d'établir une connexion, de préférence une connexion sécurisée, avec un agent 30 installé sur le nouveau périphérique détecté. Si l'unité de centralisation 20 détecte qu'aucun agent 30 est installé sur ce périphérique, l'unité de centralisation 20 peut tenter d'installer automatiquement cet agent 30 ou tenter d'identifier plus précisément le périphérique détecté. Pour ce faire, l'unité de centralisation 20 peut tenter d'identifier, l'adresse Internet, l'adresse MAC et le nom NetBIOS du périphérique. Ainsi, l'unité de centralisation 20 peut transmettre une alerte à un opérateur indiquant les informations identifiées sur le périphérique détecté pour demander à cet opérateur qu'il intervienne pour installer l'agent 30 ou pour désactiver l’accès au réseau de ce périphérique. Lorsque qu'un agent 30 a été détecté pour un périphérique nouvellement identifié par l'unité de centralisation 20 , l'unité de centralisation 20 utilise un module 32 de récupération des configurations matérielles et/ou logicielles pour envoyer des requêtes à l'agent 30 afin d'identifier plus précisément le périphérique nouvellement détecté. Par exemple, lorsque l'agent 30 envoie à l'unité de centralisation 20 l'information selon laquelle le système d'exploitation du périphérique détecté correspond un système d'exploitation Windows, l’unité de centralisation 20 peut alors transmettre les commandes permettant d’obtenir l'adresse Internet, l'adresse MAC, le nom NetBIOS, le type de système d’exploitation ou encore la version du système d’exploitation du périphérique. Evidemment, d’autres informations peuvent ainsi être collectées dans cette phase d’identification d’un nouveau périphérique. Si la version du système d’exploitation est Microsoft Server, alors une commande pour détecter la présence d’une organisation Microsoft Active Directory peut être nécessaire. Si la version du système d’exploitation est Microsoft 10, alors la recherche de l’appartenance des utilisateurs à un groupe de sécurité sera faite sur les groupes de sécurité locaux. Si la version du système d’exploitation est Microsoft Server et si une organisation Microsoft Active Directory est détectée, alors la recherche de l’appartenance des utilisateurs à un groupe de sécurité sera faite sur les groupes de sécurité globaux. Ces différentes informations sont stockées dans le fichier ConfAgents intégrant, par exemple, la dernière date DconfA de récupération des configurations matérielles et/ou logicielles, le type de système d’exploitation OSconfA , le type de périphérique TconfA , la version du système d’exploitation VconfA et l’adresse MAC Add . En outre, le module 32 peut également mettre en œuvre un contrôle d’intégrité des agents 30 , par exemple un contrôle périodique tous les mois. À partir de toutes les informations associées à un périphérique et stockées dans la mémoire, un module 33 de recherche et de transmission est capable de communiquer avec un serveur général 50 pour récupérer des collecteurs 25 - 26 afin de les transmettre aux agents 30 . En effet, lors de la création ou de l’installation de l'unité de centralisation 20 , un fichier de configuration ConfCloud est installé afin de définir comment l'unité de centralisation 20 peut communiquer avec le serveur général 50 . Par exemple, les flux réseaux entre l'unité de centralisation 20 et le serveur général 50 peuvent être bidirectionnels en utilisant un serveur général 50 de type SSH. Ainsi, le fichier ConfCloud peut intégrer une l’adresse IP publique du serveur général 50 , un identifiant de l'unité de centralisation 20 , et une clé de chiffrage des communications. Le serveur général 50 comporte préférentiellement un espace dédié à chaque unité de centralisation 20 intégrant une stratégie de recherche 10 - 12 et au moins un collecteur 25 - 26 associé aux configurations matérielles et/ou logicielles des périphériques 41 - 43 du système d’information 38 - 40 de l’unité de centralisation 20 . Cette communication entre l'unité de centralisation 20 et le serveur général 50 permet de récupérer les collecteurs 25 - 26 nécessaires pour les configurations des agents 30 détectés. Ces collecteurs 25 - 26 sont envoyés au module d'exécution 23 des agents 30 pour qu’ils soient installés sur les périphériques 41 - 44 des agents 30 , s’ils n’ont pas été préalablement installés sur ces périphériques 41 - 44 . Par exemple, ces collecteurs 25 - 26 sont téléchargés et installés lorsqu’une mise à jour de ces collecteurs 25 - 26 est détectée. De préférence, le serveur général 50 intègre un collecteur 25 - 26 par mesure à réaliser. Lorsque les collecteurs 25 - 26 sont correctement installés sur les périphériques 41 - 44 , le module 34 d’exécution d’une stratégie de recherche 10 - 12 peut procéder à des recherches automatisées. Pour ce faire, la stratégie de recherche 10 - 12 peut être définie dans un fichier de l’unité de centralisation 20 . Cette stratégie de recherche 10 - 12 peut également être stockée sur l’espace dédié à chaque unité de centralisation 20 du serveur général 50 , le module 34 récupère alors cette stratégie de recherche 10 - 12 lorsqu’elle est mise à jour. La stratégie de recherche 10 - 12 intègre la liste des commandes à appliquer aux agents 30 avec, par exemple, le numéro de la recherche Num , la fréquence d’exécution de chaque commande Fe , la destination Dest , et la description du collecteur Type et des paramètres Param à utiliser. La fréquence d’exécution de chaque commande Fe peut correspondre à une valeur en seconde après laquelle la recherche doit être renouvelée. La destination Dest peut cibler tous les périphériques 41 - 44 d’un système d’information 38 - 40 , avec l’instruction « * », ou simplement un ou plusieurs périphériques 41 - 44 en indiquant leurs adresses MAC. La description du type de collecteur Type permet d’indiquer quel programme informatique installé sur le périphérique doit être exécuter, permettant ainsi d’installer plusieurs programmes distincts pour réaliser des mesures distinctes. Lorsque le module 34 d’exécution de l'unité de centralisation 20 établi une connexion préférentiellement sécurisée avec un agent 30 , le module 34 transmet les paramètres Param à exécuter par le collecteur 25 - 26 installé sur l’agent 30 . De préférence, le module 34 peut mettre en œuvre un contrôle d’intégrité des agents 30 avant de transmettre les paramètres Param à exécuter par le collecteur 25 - 26 . Lorsque le collecteur 25 - 26 est exécuté, l’agent 30 retourne le résultat de la mesure et le module 35 peut collecter et centraliser l’ensemble des résultats dans un fichier Mes de l'unité de centralisation 20 . Tel qu’illustré sur la , les résultats peuvent être stockés sous la forme d’un fichier Mes intégrant la date de la mesure Dmes , l’adresse MAC Add du périphérique sur lequel la mesure a été réalisée, le paramètre utilisé Param et le résultat Res de la mesure. De préférence, le résultat Res correspond à un booléen pouvant prendre la valeur « 0 » ou « 1 ». Par exemple, en considérant les recommandations de l’ANSSI, un grand nombre de recommandations précédemment décrites peuvent être automatisées. L’automatisation de ces recommandations est décrite ci-après. Pour la mesure 5, « Disposer d’un inventaire exhaustif des comptes privilégiés et le maintenir à jour », l’objectif de cette mesure peut être simplement de déterminer si l’utilisateur d’un périphérique est administrateur. Cette mesure se déroule par exemple en trois étapes successives. Une première étape consiste à obtenir le nom de l’utilisateur connecté en utilisant par exemple la requête « quser ». Cette requête retourne la liste des utilisateurs de l’ordinateur. Dans une deuxième étape, pour obtenir la liste des administrateurs, la requête « net localgroup Administrateurs » (ou « net localgroup Administrators ») peut être utilisée. Cette requête permet d’obtenir les noms des utilisateurs inscrits dans ce groupe local. Ces groupes permettent de regrouper les comptes créés sur une machine dans différentes catégories, comme Administrateurs, Utilisateurs ou encore Invités, pour les plus connus. La troisième étape vise à rechercher, dans la liste, si le nom d’utilisateur est présent. Si c’est le cas alors l’utilisateur en question est bien administrateur. Le caractère associé à la mesure se mettra à “1” si l’utilisateur n’est pas administrateur et à “0” s’il l’est. “1” correspond à une mesure valide tandis que “0” correspond à une mesure défaillante, plus schématiquement “1” est un voyant vert alors que “0” est un voyant rouge. Pour la mesure 8, « Identifier nommément chaque personne accédant au système et distinguer les rôles utilisateur/administrateur », l’objectif de cette mesure peut être de déterminer si le nom de l’utilisateur est conforme à certaines exigences ; c'est-à-dire qu’il porte un nom bien défini et non pas un nom par défaut. Cette mesure se déroule en trois étapes successives : - définir un dictionnaire contenant des noms d’utilisateurs triviaux comme Admin, Administrateur, Utilisateur, User et leur équivalent anglais ; - obtenir le nom de l'utilisateur connecté ; et - vérifier que le nom d’utilisateur n’est pas compris dans la liste. Si c’est le cas, alors le nom de l’utilisateur est considéré comme conforme. Le caractère associé à la mesure se mettra à “0” si le nom de l’utilisateur contient un terme trivial et à “1” s’il n’en contient pas, comme c’est le cas de noms d’utilisateur type “nom prénom”. Pour la mesure 9, « Attribuer les bons droits sur les ressources sensibles du système d’information », l’objectif de cette mesure peut être de vérifier si l’ordinateur possède des dossiers partagés. Si c’est le cas, il convient de vérifier si de nouveaux groupes locaux ont été créés. Cette mesure se déroule donc en deux étapes dont la deuxième dépend de l’état de la première. La première étape consiste à vérifier s’il existe des partages autres que les partages administratifs en faisant appel, par exemple, à la requête « net view \\localhost » qui permet d’obtenir le nom des partages. Si c’est le cas, il faut vérifier s’il existe de nouveaux groupes locaux. En utilisant par exemple la requête « net localgroup », qui permet d’obtenir une liste des groupes présents sur la machine. Le caractère associé à la mesure se mettra à “1” s’il n’existe pas de partages ou s’il existe des partages associés à des groupes locaux et à “0” s’il existe des partages sans nouveaux groupes locaux. Pour la mesure 10, « Définir et vérifier des règles de choix et de dimensionnement des mots de passe », l’objectif de cette mesure peut être de déterminer si les mots de passe respectent les exigences de complexité comme l’intégration de caractères spéciaux. Cette mesure se déroule en deux étapes successives : - Générer un fichier de configuration de sécurité, par exemple avec la commande « secedit /export /cfg » sous Windows permettant de générer le fichier « securityconfig.txt » ; et - Rechercher la complexité de mot de passe imposée par le système dans le fichier de configuration de sécurité généré, par exemple, dans la section [System Access], le ficher « securityconfig.txt » comporte une valeur binaire associée à la variable « PasswordComplexity ». Le caractère associé à la mesure se mettra à “1” si le paramètre est activé, c’est-à-dire s’il est imposé à l’utilisateur d’utiliser des mots de passe complexes, et à “0” s’il ne l’est pas, c’est-à-dire s’il n’est pas imposé à l’utilisateur d’utiliser des mots de passe complexes. Pour la mesure 14, « Mettre en place un niveau de sécurité minimal sur l’ensemble du parc informatique », l’objectif de cette mesure peut être de déterminer si une machine est portable. Dans le cas présent, il faut vérifier que le disque dur soit chiffré et que les supports USB sont interdits. Cette mesure se déroule en trois étapes dont les deux dernières sont conditionnelles : - Vérifier que les supports USB sont interdits ; - Si ce n’est pas le cas, le programme s’arrête, sinon il se poursuit et détermine si la machine est portable ou non ; - Si la machine est portable, on cherche si le disque dur est chiffré, c'est-à-dire qu’on regarde l’état du bitlocker. Dans le cas où la machine est fixe, le programme s’arrête à l’étape précédente. Le caractère associé à la mesure se mettra à “0” dans les cas suivants : - L’utilisation de support USB est interdite alors que la machine est fixe ; et - L’utilisation de support USB est interdite, la machine est portable mais le disque dur n’est pas chiffré. Elle se mettra à “1” si elle regroupe le fait que la machine soit portable et qu’elle possède un disque dur chiffré ainsi qu’une interdiction des supports USB. Pour la mesure 15, « Se protéger des menaces relatives à l’utilisation de supports amovibles », l’objectif de cette mesure peut être de vérifier que les supports USB sont interdits. On utilise la même méthode que pour la mesure précédente. Le caractère associé à la mesure se mettra à “1” si l’utilisation de supports USB est autorisée et à “1” si elle est interdite. Pour la mesure 16, « Utiliser un outil de gestion centralisée afin d’homogénéiser les politiques de sécurité », l’objectif de cette mesure peut être de vérifier l’utilisation d’un outil de gestion centralisé, c’est-à-dire vérifier que les politiques de sécurité soient homogènes. Cette mesure se déroule donc en deux étapes successives conditionnelles ; - Vérifier si l’ordinateur est intégré à un annuaire Active Directory ayant pour objectif de centraliser l’identification ainsi que l’authentification d’un réseau de machine Windows. Celui-ci contient les ressources, c’est-à-dire les postes de travail, imprimante ou encore les dossiers partagés ; les utilisateurs ; les services (courrier électronique…). - Si c’est le cas alors le programme s’arrête sinon il vérifie que le navigateur web est en lien avec un proxy. Le caractère associé à la mesure se mettra à “0” si les deux points ne sont pas respectés et à “1” si un des deux points est vérifié. Pour la mesure 17, « Activer et configurer le pare-feu local des postes de travail », l’objectif de cette mesure peut être de vérifier que les pares feux sont activés. Cette mesure se déroule en une seule étape qui consiste à vérifier que tous les pares feux sont actifs en utilisant par exemple la requête « netsh advfirewall show allprofil », permettant d’obtenir des relations relatives aux pares feux, notamment leurs états. Le caractère associé à la mesure se mettra à “0” si les pares feux sont inactifs et à “1” s’ils sont actifs. Pour la mesure 19, « Segmenter le réseau et mettre en place un cloisonnement entre ces zones », l’objectif de cette mesure peut être de vérifier la segmentation et le cloisonnement des réseaux. Cette mesure se déroule en deux étapes successives : - Scanner le réseau pour identifier la liste des sous réseaux IP ; et - Scanner les ports ouverts sur les autres ordinateurs. Le caractère associé à la mesure se mettra à “0” en cas de présence de ports ouverts sur les sous réseaux IP et à “1” si l’ensemble des ports est fermé. Pour la mesure 21, « Utiliser des protocoles réseaux sécurisés dès qu’ils existent », l’objectif de cette mesure peut être de vérifier si certains périphériques utilisent les protocoles sécurisés HTTPS (TCP 443), SSH (TCP 22) IMAPS (TCP 993), SMTPS (TCP 465 ou 587) ou POP3S (TCP 995) à destination d’un service Internet. Le caractère associé à la mesure se mettra à “1” si l’un de ces protocoles est utilisé et à “0” dans le cas où aucun de ces protocoles n’est utilisé. Pour la mesure 22, « Mettre en place une passerelle d’accès sécurisé à Internet », l’objectif de cette mesure peut être de vérifier si un serveur proxy est utilisé, avec la même technique que pour la deuxième étape de la mesure 16. Le caractère associé à la mesure se mettra à “1” s’il y a un serveur proxy et à “0” dans le cas contraire. Pour la mesure 27, « Interdire l’accès à Internet depuis les postes ou serveurs utilisés pour l’administration du système d’information », l’objectif de cette mesure peut être de refuser l’accès à Internet des postes utilisés pour l’administration du système d’information. Cette mesure se déroule donc en deux étapes successives conditionnelles : - Identifier si le système d’exploitation est de type serveur (Windows Server) ; - Si c’est le cas, le programme vérifie qu’un proxy est activé. Un proxy est un composant logiciel ayant pour objectif de sécuriser les échanges entre deux hôtes. Le caractère associé à la mesure se mettra à “0” si le proxy est non activé avec un système d’exploitation Windows Server et à “1” si les systèmes d’exploitation est autre que Windows Server ou si le proxy est activé avec Windows Server. Pour la mesure 29, « Limiter au strict besoin opérationnel les droits d’administration sur les postes de travail », le code de cette mesure peut être identique à celui de la mesure 8 qui a pour objectif de vérifier qu’un utilisateur n’est pas administrateur. Pour la mesure 34, « Définir une politique de mise à jour des composants du système d’information », l’objectif de cette mesure peut être de vérifier la mise en place des mises à jour automatiques. Cette mesure se déroule par exemple en deux étapes successives conditionnelles : - Déterminer si le service Windows update est actif. Il a pour objectif d’activer la détection, le téléchargement et l’installation des mises à jour de Windows. - S’il est actif, il faut vérifier que le type de démarrage est automatique. Le caractère associé à la mesure se mettra à “0” si le service Windows Update n’est pas activé ou s’il est activé sans le mode automatique et à “1” si Windows update est activé avec un type de démarrage automatique. Pour la mesure 35, « Anticiper la fin de la maintenance des logiciels et systèmes et limiter les adhérences logicielles », l’objectif de cette mesure peut être de vérifier si le système d'exploitation est encore pris en charge par Microsoft. Le caractère associé à la mesure se mettra par exemple à “0” si le système d’exploitation est une version antérieure à Windows 8 et Windows Server 2012 et à “1” dans les autres cas. Pour la mesure 36, « Activer et configurer les journaux des composants les plus importants », l’objectif de cette mesure peut être de vérifier que le service “Journal des événements" est lancé. Ce service gère les événements ainsi que les journaux d’événements. Il prend en charge l’enregistrement des événements significatifs sur une machine, comme l’ouverture d’une session, ou encore lorsqu’un programme rencontre une erreur. Le caractère associé à la mesure se mettra à “0” si le service n’est pas activé et à “1” s’il l’est. Pour la mesure 37, « Définir et appliquer une politique de sauvegarde des composants critiques », l’objectif de cette mesure peut être de vérifier la présence d’un système de sauvegarde. Cette mesure se déroule en deux étapes successives conditionnelles : - Déterminer si le système d’exploitation est de type Microsoft Windows Server ; - Si ce n’est pas le cas, le programme s’arrête sinon il vérifie que les services de sauvegarde soient lancés, comme le service "sauvegarde Windows”. Le caractère associé à la mesure se mettra à “0” en cas d’absence d’activation de “Windows Server Backup” lorsque le système d’exploitation de la machine est Microsoft Windows Server et à “1” si les services de sauvegarde sont activés sous Microsoft Windows Server ou si le système d’exploitation est différent de Windows Server. Les paragraphes ci-dessus illustrent les recommandations de l’ANSSI qui peuvent être automatisées avec l’invention. Bien entendu, les recommandations de sécurité peuvent évoluer et la liste des mesures automatisées également. En outre, les requêtes peuvent être formulées différemment pour répondre à chaque recommandation, notamment lorsque les composants matériels et/ou logicielles du périphérique sont spécifiques. Les résultats Res de ces différentes mesures sont préférentiellement stockés dans l’unité de centralisation 20 et dans l’espace dédié à chaque unité de centralisation 20 sur le serveur général 50 . Pour ce faire, le module 35 de l’unité de centralisation 20 retransmet les résultats Res des mesures dans un fichier référentiel Ref de l’espace dédié à chaque unité de centralisation 20 sur le serveur général 50 . Par exemple, ces résultats Res peuvent être retransmis tous les jours ou toutes les semaines pour limiter les communications réseau. Ensuite, sur la base du fichier référentiel Ref , un module de l’unité de centralisation 20 ou du serveur général 50 peut détecter si l'ensemble des périphériques répond à des objectifs de sécurité. Pour ce faire, l’unité de centralisation 20 ou le serveur général 50 peut supporter un tableau de bord accessible par un opérateur permettant d'indiquer, pour l'ensemble des périphériques 41 - 44 , si chaque périphérique 41 - 44 répond à chaque recommandation de sécurité. En outre, d'autres recommandations de sécurité peuvent être analysées sans qu'il soit possible d'automatiser ces mesures. Pour ce faire, il est possible d'utiliser le serveur général 50 avec un module de collecte fournissant une interface graphique pour qu'un opérateur puisse répondre à des questions relatives à la sécurité informatique de son système d'information 38 - 40 . Par exemple, pour la mesure 2 visant à sensibiliser les utilisateurs aux bonnes pratiques élémentaires de sécurité informatique, une question peut simplement demander si l'entreprise comporte une charte informatique. Si l'opérateur indique que l'entreprise ne comporte pas de charte informatique, le caractère associé à cette information sera par exemple fixé à “0” alors que si l'opérateur indique que l'entreprise possède une charte informatique, le caractère associé sera fixé à “1”. Pour un autre exemple, pour la mesure 20 visant à s'assurer de la sécurité des réseaux d'accès Wi-Fi et de la séparation des usages, une question peut simplement rechercher si le réseau du système d'information 38 - 40 comporte une solution Wi-Fi sécurisée. Si l'opérateur répond à cette question par oui le caractère de cette mesure sera fixé à “1” alors que si l'opérateur répond à cette question par non le caractère associé sera fixé à “0”. Ainsi, le module de collecte du serveur général 50 permet à un opérateur de répondre à des questions génériques sur son système d'information 38 - 40 . Outre ces questions génériques, le serveur général 50 comporte également un module de calcul permettant de récupérer les réponses des périphériques 41 - 44 aux recommandations obtenues par l’unité de centralisation 20 . Pour agréger les mesures de l’unité de centralisation 20 avec celles obtenues en réponse aux questions du module de collecte du serveur général 50 , il est possible de moyenner le score de l'ensemble des périphériques en faisant la somme des caractères associés à chaque mesure divisée par le nombre de périphériques 41 - 44 utilisés pour cette mesure. Ainsi, le serveur général 50 permet d'obtenir un score sur la conformité aux recommandations de sécurité informatique d'un système d'information 38 - 40 . Ce score peut être mis à jour périodiquement en utilisant l’unité de centralisation 20 pour tester régulièrement les recommandations qui peuvent être automatisées. Ainsi, les mesures qui peuvent être automatisées peuvent être mises à jour régulièrement, par exemple tous les jours toutes les semaines, alors que les mesures découlant d'une réponse à un questionnaire peuvent être mise à jour moins souvent, par exemple les six mois ou tous les ans. L'ensemble de ces mesures permet de soulever des alertes dans différents scénarii que l'opérateur peut préprogrammer sur l’unité de centralisation 20 ou le serveur général 50 . Par exemple, une alerte peut être soulevée lorsqu'un nouveau périphérique est détecté sans qu'un agent 30 soit installé sur ce périphérique. Cette alerte peut être transmise au moyen d'un voyant lumineux ou d'un message envoyé à l'opérateur. Une autre alerte peut être transmise à un opérateur lorsque les mesures de la conformité d’un système d'information 38 - 40 sont inférieures à une valeur seuil. Par exemple, si l'ensemble d’un système d'information 38 - 40 présente un taux de conformité inférieure à 50 %, l'opérateur peut en être informé. En variante, pour une recommandation de sécurité particulière, l’opérateur peut configurer également une alerte lorsqu'un périphérique n'est pas conforme à cette revendication précise, par exemple un besoin d'activer le pare-feu. Toutes ces méthodes de détection et d'alerte permettent ainsi à l'opérateur d'avoir une gestion plus efficace et plus facilitée de la sécurité informatique du réseau d'un système d'information 38 - 40 . Il peut donc appliquer les correctifs de sécurité nécessaires en fonction des alertes soulevées. Par ailleurs, les mesures peuvent être recensées dans un tableau de bord permettant à l'opérateur de réfléchir régulièrement à la stratégie qu'il conviendrait de mettre en œuvre pour améliorer la sécurité du réseau système d'information 38 - 40 . Ainsi, l’invention permet d’obtenir une analyse de la conformité informatique d’un ensemble de périphériques 41 - 44 de systèmes d’information distincts 38 - 40 , permettant une gestion centralisée au niveau du serveur général 50 et une détection plus efficace de vulnérabilités au moyen des différentes unités de centralisation 20 . Dispositif mis en œuvre par ordinateur (10) d’analyse de la conformité informatique d’un ensemble de systèmes d’information (38-40) distincts, chaque système d’information (38-40) comportant un ensemble de périphériques (41-44) sur lesquels un agent (30) est installé ; le dispositif d’analyse comportant : - un serveur général (50) sur lequel est stocké plusieurs collecteurs (25-26), chaque collecteur (25-26) correspondant à un programme informatique exécutable, par un agent (30), sur un périphérique (41-44) avec une configuration matérielle et/ou logicielle spécifique afin d’automatiser la recherche de plusieurs informations de conformité informatique en fonction des paramètres (Param) appliqués au collecteur (25-26) ; et - au moins une unité de centralisation (20) pour chaque système d’information (38-40), chaque unité de centralisation (20) étant connectée aux différents agents (30) de son système d’information (38-40) et au serveur général (50) ; chaque unité de centralisation (20) intégrant : - un module (31) de détection de nouveaux périphériques (41-44) présents sur son système d’information (38-40) et ne disposant pas d’agent installé ; - un module (32) de récupération des configurations matérielles et/ou logicielles des périphériques (41-44) pour lesquels des agents (30) sont installés ; - un module (33) de recherche et de transmission aux agents (30) des collecteurs (25-26) stockés sur le serveur général (50) et associés aux configurations matérielles et/ou logicielles des périphériques (41-44) sur lesquels les agents (30) sont installés ; - un module (34) d’exécution d’une stratégie de recherche (10-12), le module (34) commandant les différents agents (30) afin qu’ils exécutent leurs collecteurs (25-26) avec des paramètres (Param) spécifiques définis dans la stratégie de recherche (10-12) ; et - un module (35) de centralisation des résultats (Mes) des différents agents (30) obtenus suite à l’exécution de leurs collecteurs (25-26) avec les paramètres (Param) spécifiques. Dispositif d’analyse de la conformité informatique d’un ensemble de systèmes d’information selon la revendication 1, dans lequel la stratégie de recherche (10-12) intègre la liste des commandes à appliquer aux agents (30) avec la fréquence d’exécution de chaque commande (Fe), la destination (Dest), et la description du collecteur (Type) et des paramètres (Param) à utiliser. Dispositif d’analyse de la conformité informatique d’un ensemble de systèmes d’information selon la revendication 1 ou 2, dans lequel la stratégie de recherche (10-12) est stockée sur le serveur général (50), le module d’exécution (34) de chaque unité de centralisation (20) récupérant la stratégie de recherche (10-12) sur le serveur général (50) afin de déterminer comment commander les différents agents (30). Dispositif d’analyse de la conformité informatique d’un ensemble de systèmes d’information selon la revendication 3, dans lequel le serveur général (50) comporte un espace dédié à chaque unité de centralisation (20) intégrant une stratégie de recherche (10-12) et au moins un collecteur (25-26) associé aux configurations matérielles et/ou logicielles des périphériques (41-44) du système d’information (38-40) de l’unité de centralisation (20). Dispositif d’analyse de la conformité informatique d’un ensemble de systèmes d’information selon la revendication 4, dans lequel l’espace dédié à chaque unité de centralisation (20) intègre également un fichier référentiel (Ref) ; le module (35) de centralisation des résultats des différents agents (30) obtenus automatiquement suite à l’exécution de leurs collecteurs (25-26) retransmettant périodiquement les résultats (Mes) collectés au fichier référentiel (Ref). Dispositif d’analyse de la conformité informatique d’un ensemble de systèmes d’information selon la revendication 5, dans lequel le serveur général (50) comporte une interface de modification manuelle de chaque fichier référentiel (Ref) de sorte qu’un administrateur d’un système d’information (38-40) puisse renseigner des informations obtenues manuellement sur le système d’information (38-40) et/ou les périphériques (41-44) du système d’information (38-40). Dispositif d’analyse de la conformité informatique d’un ensemble de systèmes d’information selon l’une des revendications 1 à 6, dans lequel les modules (32-35) de chaque unité de centralisation (20) établissent une connexion sécurisée avec les agents (30) avant de transmettre ou de récupérer des informations des agents (30). Dispositif d’analyse de la conformité informatique d’un ensemble de systèmes d’information selon l’une des revendications 1 à 7, dans lequel le module (32) de récupération des configurations matérielles et/ou logicielles des périphériques (41-44) pour lesquels des agents (30) sont installés réalise un contrôle d’intégrité des agents (30). Dispositif d’analyse de la conformité informatique d’un ensemble de systèmes d’information selon l’une des revendications 1 à 8, dans lequel le module (34) d’exécution d’une stratégie de recherche (10-12) réalise un contrôle d’intégrité des agents (30) avant de commander l’exécution des collecteurs (25-26). Dispositif d’analyse de la conformité informatique d’un ensemble de systèmes d’information selon l’une des revendications 1 à 9, dans lequel l’agent (30) correspond à un service Microsoft Windows ou un daemon Linux installé sur un système d’exploitation d’un périphérique (41-44).