FR 3135335 A1 20231110 FR 2205294 A 20220601 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é. Le réseau d’intérêt peut également correspondre au réseau d’un opérateur ou au réseau d’un fournisseur de solution de sécurité. Dans ce cas, la méthode peut être utilisée pour détecter la propagation de flux toxiques. 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. De plus, avec le déploiement d’outils de sécurité informatique avancés, les pirates informatiques utilisent de plus en plus souvent des voies détournées pour attaquer un système d’information en propageant des attaques à travers plusieurs réseaux. 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. En variante, dans le cadre de la détection de la propagation de flux toxiques, le réseau d’intérêt correspond typiquement à un réseau d’opérateur ou un réseau de fournisseur de solution de sécurité. Les réseaux tiers correspondent alors à des réseaux de clients appartenant au réseau de l’opérateur ou au réseau de fournisseur de solution de sécurité. 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. En variante, cette innovation pourrait être déployée sur tous les réseaux tiers connectés au même opérateur ou au même fournisseur de solution de sécurité afin d’alerter et/ou d’informer visuellement les réseaux concernés par une attaque informatique. 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. Le problème technique de l’invention peut donc également consister à fournir une alerte à plusieurs réseau tiers appartenant au même opérateur ou au même fournisseur de solution de sécurité. Cette alerte peut contenir plusieurs informations, telles que le type d’attaque, l’étendue de la propagation et les vecteurs de cette propagation. Ces informations peuvent être transmises à chaque réseau tiers concerné par cette attaque et à l’opérateur ou au fournisseur de solution de sécurité. 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. Dans un autre exemple, si un réseau tiers subit une attaque par prise de contrôle à distance d'un poste et que ce poste est utilisé pour des échanges entre réseaux tiers appartenant au même opérateur ou au même fournisseur de solution de sécurité, alors ce type d’attaque peut se propager dans plusieurs autres réseaux tiers et ainsi créer une propagation du flux toxique. 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. L’exemple de la illustre une architecture réseau dans laquelle l’invention peut être implémentée pour détecter la propagation de flux toxiques. Dans cet exemple, plusieurs réseaux 30 , 40 et 50 correspondent à des réseaux tiers de clients appartenant au réseau d’un opérateur ou au réseau d’un fournisseur de solution de sécurité 20 . Ainsi, le réseau 20 illustré sur la ne correspond pas à un réseau physique mais à plusieurs réseaux distants qui utilisent un boitier similaire d’un même opérateur ou qui intègrent un dispositif matériel et/ou logiciel d’un même fournisseur de solution de sécurité. Pour les réseaux tiers 30 , 40 , 50 , des flux réseaux 11a sont émis pour accéder à internet, par exemple pour accéder à un serveur 71 du réseau externe 70 . Plus précisément, lorsqu’un serveur 31 , 41 , 51 appartenant à un réseau tiers 30 , 40 , 50 souhaite accéder à internet, un flux réseaux 11a traverse un pare-feu 32 , 42 , 52 du réseau tiers 30 , 40 , 50 ainsi qu’un boitier 22 d’un opérateur ou un dispositif 22 matériel et/ou logiciel d’un fournisseur de solution de sécurité. Tel qu’illustré sur la , un tier de confiance ou un administrateur du réseau 20 peut récupérer les fichiers de contrôle 33 , 43 , 53 des pare-feu 32 , 42 , 52 des réseaux tiers 30 , 40 , 50 ou capter ces flux réseaux au niveau des boitiers ou des dispositifs 22 . Pour ce faire, tel que décrit précédemment, un message sécurisé directe 12a peut être transmis entre les pare-feu 32 , 42 , 52 , 72 et un organe d’analyse 61 d’un réseau 60 du tiers de confiance. Par ailleurs, un ou plusieurs réseaux externes 70 peuvent également transmettre leurs fichiers de contrôle 73 des pare-feu 72 dans un message sécurisé 12c . Cet organe d’analyse 61 parcours les fichiers de contrôle 33 , 43 , 53 , 73 , détecte des flux toxiques parmi l’ensemble des flux réseau présents dans ces fichiers de contrôle 33 , 43 , 53 , 73 , recherche la nature des échanges associés à ces flux toxiques, et caractériser les flux toxiques propagés dans les réseaux tiers 30 , 40 , 50 . Lorsqu’au moins un flux toxique propagés dans les réseaux tiers 30 , 40 , 50 , est détecté, l’organe d’analyse 61 génère une alerte 13 à destination de l’administrateur du réseau d’intérêt 20 et éventuellement les administrateurs des réseaux tiers 30 , 40 , 50 , concernés par cette attaque propagée. 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 de détection de la propagation de flux toxiques est décrit en référence à la . Dans une première étape 110 , 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 , 42 , 52 et 72 appartenant à un réseau tiers 30 , 40 , 50 , ou à un réseau externe 70 . Par exemple en recevant les fichiers de contrôle 33 , 43 , 53 , 73 des pare-feu 32 , 42 , 52 , 72 . Ces fichiers de contrôle 33 , 43 , 53 , 73 contiennent classiquement un ensemble de flux réseau. Dans une étape 111 , de la même manière que dans l’étape 101 de la , 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 . 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 112 , l’identification de la nature du risque est effectuée pour rechercher si chaque flux toxique présente un risque de propagation dans le 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, tels que les ports utilisés pour les attaques ou l’horodatage et le volume de données des attaques. Ces scénarii permettent de rechercher les attaques avec un risque fort de propagation et les attaque avec un risque faible de propagation. A l’issue de cette étape 112 , les attaques avec un risque faible de propagation sont supprimées du fichier de flux toxique 63 . L’étape 113 vise ensuite à caractériser si ces attaques restantes dans fichier de flux toxique 63 se sont réellement propagées dans le réseau d’intérêt 20 . Pour ce faire, l’organe 61 recherche si les adresse IP toxiques des différentes attaques restantes dans le fichier de flux toxique 63 ont ciblé plusieurs adresses IP attaquées différentes. Si tel est le cas, une propagation d’une attaque est caractérisée si plusieurs adresses IP attaquées ont subi une attaque du même type et provenant de la même IP toxique. Une propagation se définie donc par un regroupement de flux toxiques comportant une adresse IP toxique, un type d’attaque informatique, et une liste d’adresses IP attaquées. Pour identifier plus précisément la propagation, il est possible de classer les flux toxiques en fonction de leurs horodatages. Le flux toxique qui dispose de l’horodatage le plus ancien peut donc être identifiée comme le point d’entrée de la propagation de l’attaque. A partir de l’ensemble des flux toxiques, il est également possible de caractériser le type de propagation, point à point si les horodatages sont successifs ou multidiffusion si plusieurs attaques simultanées sont détectées à des intervalles de temps très proches et à destination d’un grand nombre d’adresse IP attaquée. Suite à la caractérisation de la propagation, une alerte peut être émise à destination de l’administrateur du réseau d’intérêt 20 et aux administrateurs des réseau tier 30 , 40 , 50 , dans une étape 114 . L’alerte peut prendre la même forme que l’alerte définie dans la en ajoutant une représentation visuelle de la propagation du flux toxique sur les différents réseaux concernés. Par exemple, une représentation chronologique de la propagation sur la base des horodatages des flux toxiques, de la géolocalisation des adresses IP attaquées et de l’adresse IP toxique de chaque propagation peut être générée. Ainsi, à la réception de l’alerte 13 , l’administrateur du réseau d’intérêt 20 et les administrateurs des réseau tiers 30 , 40 , 50 peuvent facilement identifier les réseaux tiers 30 , 40 , 50 attaqués, le type d’attaque que ces réseaux ont subi, la nature et la vitesse de la propagation. [néant]