FR 3135337 A1 20231110 FR 2204382 A 20220509 L’invention propose de détecter les flux toxiques générés sur chaque réseau tiers connecté au réseau d’intérêt et d’analyser la nature des flux toxiques détectés afin de transmettre uniquement une alerte à un administrateur du réseau d’intérêt lorsque des flux toxiques détectés sont potentiellement préjudiciables pour le réseau d’intérêt. METHODE D’ANALYSE DU RISQUE INFORMATIQUE D’UN RESEAU D’INTERET LIE AUX ECHANGES AVEC AU MOINS UN RESEAU TIERS L’invention concerne une méthode permettant de détecter les risques informatiques qui pourraient être engendrés sur un réseau d’intérêt en raison des flux réseau échangés entre ce réseau d’intérêt et au moins un réseau tier, dont on ne connait pas nécessairement le niveau de sécurité informatique. Par exemple, le réseau d’intérêt peut correspondre à un réseau d’une société, d’une administration ou d’une université, et le réseau tiers peut correspondre au réseau d’un sous-traitant direct ou indirect, ou un organisme collaborant avec la société, l’administration ou l’université. De nos jours, un grand nombre d’organismes ont désormais une politique efficace de sécurité informatique. Cependant, d’autre organismes n’ont pas toujours les moyens financiers, l'intérêt ou même la motivation d'assurer une sécurité informatique minimum. Or, la collaboration croissante des organismes impose un grand nombre d’échanges entre les sociétés, les administrations ou encore les universités. Lors de ces échanges, les organismes utilisant une politique de sécurité informatique stricte sont inquiets de la résilience des systèmes d’information de leurs sous-traitants ou collaborateurs face aux attaques informatiques. Dans le cadre de l’invention, il est possible de distinguer deux types de réseaux, le réseau d’intérêt et les réseaux tiers. Le réseau d’intérêt correspond typiquement au réseau d’un organisme utilisant une politique de sécurité informatique stricte et pour lequel un administrateur réseau souhaite estimer le risque informatique lié aux échanges avec des réseaux externes, appelés réseaux tiers. Ces réseaux tiers correspondent classiquement à des réseaux informatiques de sous-traitants, directs ou indirects ou de collaborateurs. Pour analyser un risque informatique d’un réseau, la société SERENICITY propose des dispositifs appelés « Detoxio », « Probio » et « Cymealog » intégrants un organe de supervision des flux réseau entrants et sortants de chaque périphérique depuis et vers Internet. Tel que décrit dans le brevet FR2006068, en comparant les adresses IP des flux réseau avec une base de données comportant une liste d’adresses IP toxiques, il est possible de détecter des flux réseau toxiques. Cette base de données comportant une liste d’adresses IP toxiques peut être obtenue par une solution de captation d’adresses IP par des serveurs leurres, tel que décrit dans le brevet FR 1852752. Ensuite, un score de vulnérabilité de chaque périphérique est calculé en appliquant un facteur de dix aux flux toxiques sortants par rapport aux flux toxiques entrants. Ce score de vulnérabilité permet d’identifier et de classer le risque informatique lié à chaque périphérique d’un réseau. Cette innovation pourrait être déployée directement sur tous les réseaux tiers connectés à un réseau d’intérêt afin qu’un administrateur du réseau d’intérêt puisse vérifier que les réseaux tiers présentent un risque informatique limité. Cependant, avec cette solution, l’administrateur du réseau d’intérêt recevrait un grand nombre d’alertes, notamment lorsque le réseau d’intérêt est connecté à plusieurs réseaux tiers. Le problème technique de l’invention consiste donc à fournir une alerte à un administrateur d’un réseau d’intérêt concernant le risque informatique lié à au moins un réseau tiers connecté au réseau d’intérêt, tout en limitant le nombre d’alertes et sans dégrader la pertinence des alertes. Pour résoudre ce problème technique, l’invention propose de détecter les flux toxiques générés sur chaque réseau tiers connecté au réseau d’intérêt et d’analyser la nature des flux toxiques détectés afin de transmettre uniquement une alerte à un administrateur du réseau d’intérêt lorsque des flux toxiques détectés sont potentiellement préjudiciables pour le réseau d’intérêt. Par exemple, si un réseau tiers subit une attaque par déni de service de son site Internet, ce type d'attaque informatique est préjudiciable pour les activités commerciales du réseau tier, mais ne remet pas en cause la sécurité informatique du réseau d’intérêt. Au contraire, si le réseau tiers subit une attaque par prise de contrôle à distance d'un poste et que ce poste est couramment utilisé pour échanger des informations avec le réseau d’intérêt, ce type d'attaque peut présenter un risque informatique préjudiciable pour le réseau d’intérêt. Pour limiter un tel risque informatique, un administrateur du réseau d’intérêt peut imposer aux administrateurs des réseaux tiers de lui transmettre, ou de transmettre à un tiers de confiance comme SERENICITY, les flux réseau captés par leurs pare-feu. Ces pare-feu sont classiquement appelés « firewall » dans la littérature anglo-saxonne. L’invention propose d’analyser les flux réseau captés par les pare-feu des réseaux tiers, de détecter les flux toxiques parmi l’ensemble de ces flux réseau et la nature des échanges associés à ces flux toxiques afin de détecter les flux toxiques potentiellement préjudiciables pour le réseau d’intérêt. Ainsi, l’invention permet d’alerter un administrateur du réseau d’intérêt dans le cas où une attaque informatique détectée sur un réseau tiers peut atteindre à la sécurité du réseau d’intérêt. Au sens de l’invention, un flux toxique correspond à un flux provenant ou à destination d'une adresse IP toxique, c'est-à-dire d'une adresse IP référencée dans une base de données et associée à un pirate informatique ou présentant un risque de vulnérabilité fort. Cette base de données est classiquement constituée et mise à jour régulièrement par des acteurs de la sécurité informatique. Elle peut être téléchargée périodiquement et stockée en interne ou consultée sur une plateforme externe. Cette base de données est préférentiellement obtenue par des serveurs leurres permettant de capter des adresses IP toxiques, tel que décrit dans le brevet FR 1852752. La illustre un exemple d’architecture réseau dans lequel l’invention peut être implémentée. Dans cet exemple, plusieurs réseaux 20 , 30 , 40 et 50 communiquent entre eux. Plus précisément, le réseau 20 échange des flux réseau 11a avec les réseaux 30 et 40 alors que le réseau 50 échange des flux réseau 11b avec le réseau 40 . Le réseau 20 peut correspondre au réseau d’une grande société, alors que les réseaux 30 et 40 sont les réseaux de sous-traitants directs de cette grande société, et que le réseau 50 est un réseau d’un sous-traitant indirect. Au sens de l’invention, le réseau 20 correspond au réseau d’intérêt alors que les réseaux 30 , 40 et 50 sont des réseaux tiers, directs ou indirects. Par exemple, le réseau tiers 30 peut correspondre au réseau d’un prestataire en charge de gérer les différentes imprimantes du réseau d’intérêt 20 , notamment pour déployer à distance les mises à jour de celles-ci. Pour ce faire, le prestataire utilise un serveur 31 du réseau tiers 30 pour se connecter à un périphérique 2 4 du réseau d’intérêt 20 . L’invention vise notamment à vérifier qu’une attaque informatique réalisée sur le réseau tiers 30 ne puisse entraîner une vulnérabilité du réseau d’intérêt 20 par l’intermédiaire des flux réseau existants 11a entre le réseau tiers 30 et le réseau d’intérêt 20 . Le réseau tiers 40 peut correspondre au réseau d’un prestataire en charge de la gestion des postes téléphoniques 25 des différents bureaux du réseau d’intérêt 20 . Pour ce faire, le prestataire utilise un serveur 41 du réseau tiers 40 pour se connecter aux postes téléphoniques 2 5 du réseau d’intérêt 20 . L’invention vise également à vérifier qu’une attaque informatique réalisée sur le réseau tiers 40 ne puisse entraîner une vulnérabilité du réseau d’intérêt 20 par l’intermédiaire des flux réseau existants 11a entre le réseau tiers 40 et le réseau d’intérêt 20 . Le réseau tiers 50 peut correspondre au réseau d’un prestataire en charge de la gestion de systèmes de climatisation 44 connectés du réseau tiers 40 . Pour ce faire, des flux réseau 11b sont générés entre un serveur 51 du réseau tiers 50 et les systèmes de climatisation 44 du réseau tiers 40 . En ce qui concerne les réseaux tiers indirects, l’invention peut également être implémentée pour vérifier qu’une attaque informatique réalisée sur le réseau tiers 50 ne puisse entraîner une vulnérabilité du réseau tiers 40 et propager la vulnérabilité sur le réseau d’intérêt 20 , par l’intermédiaire des flux réseau 11 a et 11 b . Par ailleurs, chaque réseau tiers 30 , 40 et 50 est protégé par un pare-feu dédié 32 , 42 et 52 , géré classiquement par plusieurs administrateurs réseau distincts. Ces pare-feu 32 , 42 et 52 intègrent des fichiers de contrôle 33 , 43 , 53 permettant de retracer un historique des flux réseau 11a , 11b traversant le pare-feu. Ces fichiers de contrôle 33 , 43 , 53 sont également appelés « logs » dans la littérature anglo-saxonne. Tel qu’illustré sur la , les pare-feu 32 , 42 , et 52 des réseaux tiers 30 , 40 , 50 sont en outre configurés pour transmettre les fichiers de contrôle 33 , 43 , 53 . Ces fichiers de contrôle 33 , 43 , 53 peuvent être transmis à un administrateur du réseau d’intérêt 20 ou à un tiers de confiance. Pour ce faire, un message sécurisé directe 12a peut être transmis entre les pare-feu 32 , 42 et un organe d’analyse 61 d’un réseau 60 du tiers de confiance. Pour le réseau tiers indirect 50 , le pare-feu 52 peut être configuré pour transmettre le fichier de contrôle 53 directement au tiers de confiance 60 , ou indirectement en passant par un administrateur du réseau tiers 40 auquel il est connecté. Dans l’exemple de la , un message sécurisé 12b est transmis entre le pare-feu 52 et un organe d’analyse 61 d’un réseau 60 du tiers de confiance en passant par le réseau tiers 40 . Plus précisément, cet organe d’analyse 61 parcours les fichiers de contrôle 33 , 43 , 53 , détecte des flux toxiques parmi l’ensemble des flux réseau présents dans ces fichiers de contrôle 33 , 43 , 53 et recherche la nature des échanges associés à ces flux toxiques afin de détecter les flux toxiques potentiellement préjudiciables pour le réseau d’intérêt 20 . Lorsqu’au moins un flux toxique potentiellement préjudiciable pour le réseau d’intérêt 20 est détecté, l’organe d’analyse 61 génère une alerte 13 à destination d’un administrateur du réseau d’intérêt 20 . Cette alerte 13 peut contenir des informations contextualisées en fonction des besoins de l’administrateur du réseau d’intérêt 20 . Un exemple de mise en place de la méthode d’analyse du risque informatique est décrit en référence à la . Dans une première étape 10 0 , le tiers de confiance ou un administrateur du réseau d’intérêt 20 récupère les flux réseau captés par au moins un pare-feu 32 , 4 2 , 5 2 appartenant à un réseau tiers 30 , 40 , 50 , par exemple en recevant les fichiers de contrôle 33 , 43 , 53 des pare-feu 3 2 , 4 2 , 5 2 . Ces fichiers de contrôle 33 , 43 , 53 contiennent classiquement un ensemble de flux réseau avec, pour chaque flux réseau, au moins : - une adresse IP de provenance ; - une adresse IP de destination ; - un sens de trafic du flux ; - un type de port utilisé pour la connexion ; et - un horodatage du flux réseau, typiquement la date et l’heure de début et de fin du flux réseau. Lorsque les flux réseau des réseaux tiers sont récupérés, chaque adresse IP de destination et de provenance est comparée, une à une, à la base de données comprenant les adresses IP toxiques 64 , dans une étape 101 . Chaque flux réseau lié à une adresse IP toxique est alors stocké dans un fichier de flux toxique 63 intégrant, pour chaque période de temps, par exemple pour chaque jour ou pour chaque heure, l’ensemble des flux toxiques. Ensuite, dans une étape 102 , l’identification de la nature du risque est effectuée pour détecter si chaque flux toxique présente un risque pour la sécurité informatique du réseau d’intérêt 20 ou simplement pour la sécurité informatique d’un réseau tiers 30 , 40 , 50 . Pour ce faire, l’organe d’analyse 61 tente de caractériser chaque type d’attaque informatique sur la base de scénarii utilisant des informations obtenues à partir des flux toxiques détectés. Par exemple, une attaque de type « force brute » peut être caractérisée lorsque plusieurs flux toxiques sont détectés dans des intervalles de temps très proches, typiquement si la même adresse IP toxique à communiqué avec la même adresse IP attaquée plus de deux cent fois dans la même journée. De plus, les heures d’attaques peuvent être utilisées comme indice pour caractériser les attaques de type « compromission », par exemple la compromission d’un système de fermeture de porte. Typiquement, si une adresse IP toxique communique avec un système de fermeture de porte en dehors des heures habituelles, alors l’organe d’analyse 61 peut catégoriser une attaque de type « compromission ». Il est également possible d’utiliser des informations connues sur l’adresse IP toxique détectée, telles que le type d’attaque généralement associées à cette adresse IP toxique détectée. Ces informations peuvent être intégrées dans la base de données d’adresses IP toxiques ou accessibles sur un serveur externe. Par exemple, s’il est connu que l’adresse IP toxique détectée est basée sur un complexe militaire, il est possible de caractériser le type d’attaque informatique comme une attaque de type « militaire ». Selon un autre exemple, s’il est connu que l’adresse IP toxique détectée héberge un nœud du réseau Tor, permettant d’accéder au réseau internet connu sous le nom de « DarkNet », alors il est possible de caractériser le type d’attaque informatique comme une attaque de type « masquée ». Selon un autre exemple, s’il est connu que l’adresse IP toxique détectée héberge un serveur de commande et contrôle d’un programme malveillant de chiffrement de données, également connu sous les termes « command-and-control » » dans la littérature anglo-saxonne, alors il est possible de caractériser le type d’attaque informatique comme une attaque de type « command center ». Par ailleurs, les ports utilisés pour les attaques peuvent également permettre de caractériser le type d’attaque. Typiquement, le port TCP/IP « 22 » correspond au port SSH, ou « Secure Shell » dans la littérature anglo-saxonne. Ce port « 22 » est utilisé pour prendre le contrôle des machines distantes. Ainsi, si un pirate informatique arrive à prendre le contrôle d’un périphérique d’un réseau tiers 30 , 40 , 50 , il est possible de caractériser le type d’attaque informatique comme une attaque de type « cheval de Troie ».Ainsi, un grand nombre de scenarii peuvent être implémentés pour caractériser chaque type d’attaque informatique. A l’aide de cette caractérisation, un grand nombre d’attaques informatiques peuvent être supprimées du fichier de flux toxiques 63 car elles ne sont pas potentiellement préjudiciables pour le réseau d’intérêt 20 . Pour les flux toxiques potentiellement préjudiciables pour le réseau d’intérêt 20 , une alerte 13 peut être transmisse à l’administrateur du réseau d’intérêt 20 , dans une étape 103 . Pour limiter le nombre d’alertes reçues, l’administrateur du réseau d’intérêt 20 peut avoir une interface permettant de sélectionner les types d’attaque, par exemple « force brute », « compromission », « militaire », « masquée », « command center » et « cheval de Troie », pour lesquelles il souhaite recevoir une alerte 13 . Ainsi, si une attaque de type « force brute » est caractérisée dans l’étape 102 et que l’administrateur ne souhaite pas recevoir ce type d’information, alors aucune alerte ne sera transmise à l’administrateur du réseau d’intérêt 20. Cette alerte 13 peut prendre différentes formes en fonction des besoins de l’administrateur du réseau d’intérêt 20 . Par exemple, l’alerte 13 peut être affichée sur une carte en utilisant la géolocalisation de l’adresse IP toxique détectée, de l’adresse IP attaquée ou encore d’une adresse IP du réseau d’intérêt 20 qui a communiqué avec l’adresse IP attaquée. En outre, chaque alerte 13 peut présenter une forme différente en fonction de la nature de l’attaque. Ainsi, à la réception de l’alerte 13 , l’administrateur du réseau d’intérêt 20 peut facilement voir les réseaux tiers 30 , 40 , 50 directement ou indirectement attaqués, le type d’attaque que ces réseaux ont subi et le sens de trafique du flux de ces attaques. Pour conclure, l’invention permet de fournir une alerte 13 à un administrateur d’un réseau d’intérêt 20 concernant le risque informatique lié à au moins un réseau tiers 30 , 40 , 50 connecté directement ou indirectement au réseau d’intérêt 20 . Par ailleurs, l’invention propose également de limiter les informations transmises à l’administrateur du réseau d’intérêt 20 afin de lui transmettre uniquement des alertes 13 pertinentes. En recevant une ou plusieurs adresses IP du réseau d’intérêt 20 pour lesquelles il existe un risque informatique, l’administrateur peut agir en conséquence. Par exemple, il peut mener des investigations et éventuellement déconnecter un périphérique du réseau. [néant]