FR3111443A1 - Dispositif d’analyse du risque informatique d’un ensemble de périphériques connectés sur un réseau - Google Patents
Dispositif d’analyse du risque informatique d’un ensemble de périphériques connectés sur un réseau Download PDFInfo
- Publication number
- FR3111443A1 FR3111443A1 FR2008929A FR2008929A FR3111443A1 FR 3111443 A1 FR3111443 A1 FR 3111443A1 FR 2008929 A FR2008929 A FR 2008929A FR 2008929 A FR2008929 A FR 2008929A FR 3111443 A1 FR3111443 A1 FR 3111443A1
- Authority
- FR
- France
- Prior art keywords
- risk
- network
- toxic
- category
- flows
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
- H04L63/1416—Event detection, e.g. attack signature detection
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
Abstract
L’invention concerne un dispositif d’analyse du risque informatique (13) d’un ensemble de périphériques (14-16) connectés sur un réseau (101), ledit dispositif comportant : un organe de supervision des flux entrants (17a) et sortants (17c) de chaque périphérique (14-16) depuis et vers Internet (11) ; un détecteur des flux toxiques comparant l’adresse de provenance et de destination de ces flux entrants (17a) et sortants (17c) avec une base de données comportant une liste d’adresses toxiques ; un compteur (19) des flux toxiques détectés pour chaque périphérique (14-16) du réseau (101), ledit compteur (19) appliquant un facteur de dix aux flux toxiques sortants par rapport aux flux toxiques entrants ; et une unité de caractérisation du risque informatique associé à chaque périphérique (14-16) configurée pour classer chaque périphérique (14-16) entre une catégorie de risque limitée et une catégorie de risque important. Figure pour l’abrégé : Fig. 1
Description
L'invention concerne un dispositif permettant de fournir un indicateur illustrant le risque informatique lié à un ensemble de périphériques connectés sur un réseau. Le réseau peut correspondre à un réseau informatique d'une entreprise, d'une collectivité, d'une association, d'un particulier ou à l’ensemble du réseau d’un opérateur.
L’invention trouve une application particulièrement avantageuse pour détecter des failles de sécurité existantes sur un réseau ou pour valider la conformité d'une installation réseau avec des préconisations de sécurité.
Plus généralement, l’invention peut être utilisée pour détecter des failles de sécurité à partir d’un fichier d’enregistrement des flux réseau captés par un pare-feu, par exemple le pare-feu d’un opérateur.
Art antérieur
Une architecture réseau se compose classiquement d'un pare-feu connecté entre Internet et au moins un concentrateur réseau. Plusieurs périphériques sont connectés sur le concentrateur réseau de sorte à former un réseau informatique local.
Le pare-feu permet de déterminer quels sont les types de communications autorisés sur le réseau local. En effet, le pare-feu assure la liaison entre Internet et le réseau local en filtrant les protocoles utilisés pour les communications entrantes. Si un protocole n’est pas autorisé sur le réseau local, le pare-feu bloque tous les paquets réseau liés à ce protocole.
Par exemple, lorsqu'une structure comporte un serveur de courriel, les paquets utilisant le protocole SMTP sont automatiquement redirigés depuis le pare-feu sur le serveur de courriel. De nombreux autres protocoles peuvent être ouverts et routés par le pare-feu en fonction des besoins, notamment des protocoles de contrôle à distance.
Toutes les fonctionnalités ouvertes sur les différents périphériques d’un réseau engendrent des risques pour la sécurité informatique du réseau si ces protocoles ne sont pas correctement gérés par un administrateur réseau compétent et réactif. Par exemple, un serveur Web peut être attaqué par une attaque de type DDOS ou un serveur IPBX peut être utilisé pour créer de la surfacturation lorsqu'un pirate arrive à prendre le contrôle sur ce serveur afin de détourner un service de voix sur IP.
Pour limiter les possibilités d'action des pirates informatiques, il existe des pare-feu très évolués, par exemple utilisant les technologies IPS et IDS pour filtrer les adresses IP toxiques pouvant traverser le pare-feu.
Au sens invention, une adresse IP « toxique » est une adresse IP qui a été référencée dans une base de données comme provenant d'un pirate informatique et qu’il est préférable de bloquer au niveau du pare-feu pour garantir la sécurité informatique sur le réseau local.
Cependant, seuls les pare-feu de très haute gamme possèdent des fonctionnalités de blocage des adresses IP toxiques. Ainsi, ces fonctionnalités sont rarement présentes dans les petites et moyennes structures.
En outre, le blocage des adresses IP toxiques entrantes sur un réseau local ne permet pas de prévenir les actions que peuvent mener les pirates informatiques en pénétrant sur le réseau local par d’autres canaux que le pare-feu, par exemple en implantant un virus sur une clé USB d’un salarié.
Pour remédier à ces failles de sécurité, il est possible d’utiliser un antivirus déployé sur chaque périphérique du réseau. Par exemple, pour éviter la mise en œuvre d’une rançon logicielle de la part d'un pirate qui aurait réussi à se connecter sur un périphérique, il est possible de limiter les possibilités de modification des fichiers à certains programmes.
Cependant, comme pour les pare-feu, l’efficacité d’un antivirus dépend de la qualité de l’anti-virus et de son administration si bien que les plus petites structures, par exemple les entreprises avec les moyens les plus limités attribués à la gestion du réseau, présentent souvent des antivirus peu efficaces et/ou qui ne sont pas à jour.
Ainsi, il existe un grand nombre de stratégies de défense contre les pirates informatiques mais ces stratégies de défense sont souvent coûteuses et nécessitent des équipements très évolués et de la supervision si bien que les petites structures, telles que les sociétés unipersonnelles ou de petites tailles, sont généralement dépourvues de ce type d’outils. En outre, même les sociétés comportant des moyens de défense très évolués peuvent présenter des failles de sécurité inconnues dues à des erreurs de gestion liées à la complexité des besoins des grandes structures.
Pour conclure, chaque structure doit faire un choix stratégique dans la sécurisation de son réseau informatique en fonction des besoins de sécurité et des budgets disponibles. Si une structure veut améliorer la sécurité de son réseau local, elle procède généralement à l’acquisition d’un pare-feu ou d’un antivirus plus performant alors qu’en modifiant les configurations existantes, il est souvent possible de renforcer la sécurité du réseau à moindres coûts.
Pour ce faire, il existe un besoin de caractérisation du risque informatique d'une structure au cours du temps qui soit plus simple et facilement accessible que les composants existants.
Pour répondre à ce problème, l'invention propose un dispositif d'analyse des flux réseaux permettant de comptabiliser les flux entrants et sortants toxiques liés à chaque périphérique d’un réseau local de sorte à fournir un indicateur de risque lié à chaque périphérique.
La complexité d’implémentation de ce type de dispositif provient du fait que les flux toxiques entrants et sortants d’un périphérique sont de natures très différentes et résultent de failles de sécurité présentant des risques plus ou moins importants. Au sens de l’invention, un flux toxique correspond à un flux dirigé au 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.
Par exemple, il est possible d’obtenir une base de données d’adresses IP toxiques au moyen d’une API fournie par l’un de ces sites internet : https://auth0.com/signals/ip;
https://scamalytics.com/; ou https://www.abuseipdb.com/.
Pour pouvoir analyser un risque informatique global en prenant en compte les adresses IP toxiques entrantes et sortantes d’un périphérique, l'invention est issue d'une observation des situations critiques liées aux flux toxiques recensés sur plus de 100 entreprises permettant d'obtenir un échantillon de plus de 3 600 000 flux toxiques analysés. Pour chacun de ces flux toxiques, il a été possible de comptabiliser le nombre de flux toxiques entrants et le nombre de flux toxiques sortants il est apparu que plus de 98 % des flux toxiques correspondaient à des flux toxiques entrants.
Il a également été observé le risque informatique lié à ces différents flux toxiques entrants et sortants par l'analyse des situations vécues par les entreprises après la survenue de ces flux toxiques. Plus pratiquement, les dommages informatiques subies par les sociétés ont été chiffrés en fonction du nombre de flux toxiques subis par ces sociétés.
À l'issue de cette phase d'analyse, il a été observé que la survenue d'un flux toxique sortant était aussi dommageable que la survenue de dix flux toxiques entrants pour un même périphérique alors même que la proportion de flux entrants par rapport aux flux sortants est bien différente.
Ainsi, l'invention est issue d'une observation selon laquelle il est possible de caractériser un risque informatique global lié à chaque périphérique d'un réseau en analysant les flux toxiques entrants et sortants et en pondérant des flux toxiques sortants par un facteur dix par rapport aux flux toxiques entrants.
Fort de cette observation, l'invention permet d'obtenir un score de vulnérabilité associé à chaque périphérique reflétant le risque informatique lié à ce périphérique. Ce score de vulnérabilité peut être mis à jour périodiquement, par exemple par jour, par mois ou par heure en fonction des besoins de sécurité recherchés.
En outre, à partir de ce score de vulnérabilité, il est possible de caractériser le risque informatique en deux catégories distinctes, une première catégorie dans laquelle le risque informatique lié au périphérique est limité lorsque le score de vulnérabilité est compris entre 0 et X une deuxième catégorie lorsque le score de vulnérabilité associé au périphérique est supérieur à X correspondant à une catégorie dans laquelle le risque informatique est important.
Les études précédentes ont également montré que la valeur de X pour séparer ces deux catégories devait être comprise entre 1 et 9 dans le score de vulnérabilité associé à chaque périphérique car, au-delà de neuf, c'est-à-dire si le périphérique a subi au moins un flux toxique sortant ou au moins dix flux toxiques entrants, de forts dommages informatiques ont été constatés suite à la survenue de ce type de scenarii.
L’invention concerne donc un dispositif d’analyse du risque informatique d’un ensemble de périphériques connectés sur un réseau, ledit dispositif comportant :
- un organe de supervision des flux entrants et sortants de chaque périphérique du réseau depuis et vers Internet ;
- un détecteur des flux toxiques comparant l’adresse de provenance et de destination de ces flux entrants et sortants avec une base de données comportant une liste d’adresses toxiques ;
- un compteur des flux toxiques détectés pour chaque périphérique du réseau, ledit compteur étant configuré pour déterminer un score de vulnérabilité associé au périphérique en appliquant un facteur de dix aux flux toxiques sortants par rapport aux flux toxiques entrants ; et
- une unité de caractérisation du risque informatique associé à chaque périphérique en fonction du score de vulnérabilité de chaque périphérique, ladite unité de caractérisation étant configurée pour classer chaque périphérique entre au moins deux catégories :
- un organe de supervision des flux entrants et sortants de chaque périphérique du réseau depuis et vers Internet ;
- un détecteur des flux toxiques comparant l’adresse de provenance et de destination de ces flux entrants et sortants avec une base de données comportant une liste d’adresses toxiques ;
- un compteur des flux toxiques détectés pour chaque périphérique du réseau, ledit compteur étant configuré pour déterminer un score de vulnérabilité associé au périphérique en appliquant un facteur de dix aux flux toxiques sortants par rapport aux flux toxiques entrants ; et
- une unité de caractérisation du risque informatique associé à chaque périphérique en fonction du score de vulnérabilité de chaque périphérique, ladite unité de caractérisation étant configurée pour classer chaque périphérique entre au moins deux catégories :
* une catégorie de risque limitée lorsque le score de vulnérabilité est compris entre 0 et X ; et
* une catégorie de risque important lorsque le score de vulnérabilité est supérieur à X ; avec X compris entre 1 et 9.
* une catégorie de risque important lorsque le score de vulnérabilité est supérieur à X ; avec X compris entre 1 et 9.
L'invention permet ainsi d'afficher le risque informatique de chaque périphérique d'une structure afin de permettre au gestionnaire réseau d'adapter sa stratégie en fonction des vulnérabilités constatées. Ainsi, en connaissant les vulnérabilités, le gestionnaire du réseau peut tenter de combler certaines failles de sécurité en modifiant la configuration de l’installation existante, par exemple en limitant les protocoles autorisés par le pare-feu.
L’analyse des flux réseau peut être réalisée au moyen d’un boitier physiquement implanté sur le réseau local ou en utilisant un outil d’enregistrement des flux réseau intégré dans le pare-feu. Dans le cas d’un boitier d’analyse implanté sur le réseau local, préférentiellement entre le pare-feu et le concentrateur réseau, le boitier d’analyse peut intégrer une base de données d’adresses toxiques et réaliser, de manière autonome, le comptage du score de vulnérabilité de chaque périphérique.
En variante, le boitier d’analyse peut capter l’ensemble des flux réseau entrants et sortants du pare-feu afin de transmettre les informations de ces flux à un serveur distant intégrant la base de données d’adresses toxiques et effectuant le comptage du score de vulnérabilité de chaque périphérique.
De la même manière, un utilisant un outil d’enregistrement des flux réseau intégré dans le pare-feu, cet outil d’enregistrement peut être utilisé pour transmettre les informations de ces flux à un serveur distant effectuant le comptage du score de vulnérabilité de chaque périphérique. Ainsi, ledit organe de supervision des flux entrants et sortants de chaque périphérique peut correspondre à un journal de connexions d’un pare-feu.
Par exemple, un pare-feu d’un opérateur réseau peut enregistrer les flux réseaux traversant le pare-feu dans son journal de connexions, également appelé fichier de « log » dans la littérature anglo-saxonne. Typiquement, un journal de connexions stocke périodiquement, par exemple tous les jours, l’ensemble des connexions traversant le pare-feu. Ainsi, un journal de connexions d’un opérateur réseau se présente classiquement sous la forme d’un fichier de plusieurs millions de lignes intégrant, pour chaque connexion : la date, l’heure, l’adresse entrante, l’adresse sortante, le service utilisé, le volume de données reçues et le volume de données transmisses.
En connaissant le formalisme du journal de connexions, il est possible d’extraire rapidement les adresses entrantes et sortantes de l’ensemble des connexions pour comparer ces adresses avec les adresses toxiques. Bien que l’extraction puisse être réalisée rapidement en connaissant le formalisme du journal de connexions, il est préférable de limiter la mémoire utilisée pour effectuer cette extraction en utilisant un buffer pour analyser le journal de connexions par parties.
Pour l’analyse d’un journal de connexions d’un opérateur réseau, l’étape la plus complexe en temps de calcul consiste à comparer les millions de lignes du journal de connexions avec les millions de lignes que peut contenir le fichier comportant les adresses toxiques. Pour ce faire, il est possible d’utiliser deux boucles imbriquées en balayant l’ensemble des du journal de connexions et en comparant chaque adresse avec l’ensemble des adresses toxiques. Cette technique de traitement est particulièrement longue. Pour limiter ce temps de calcul, il est possible de mémoriser toutes les adresses du journal de connexions et les adresse toxiques dans deux tableaux et d’utiliser les requêtes imbriquées pour détecter une correspondance.
Pour améliorer encore le temps de comparaison, il est préférable de créer un tableau particulier intégrant toutes les adresses toxiques. Un tableau est classiquement constitué d’une clé et d’une valeur. Les clés sont classiquement incrémentales alors que les valeurs sont enregistrées au niveau de clés distinctes. Pour constituer un tableau classique, une première valeur est enregistrée au niveau de la clé 1, une seconde valeur est enregistrée au niveau de la clé 2… Ainsi, pour obtenir la première valeur, il suffit de rechercher, dans le tableau, la valeur associée à la clé 1 et ainsi de suite.
Pour ce tableau particulier, la clé de chaque ligne ne sera pas une clé incrémentale mais directement une adresse toxique. La valeur associée à chaque clé peut ensuite correspondre à un booléen ou à une recopie de l’adresse toxique. Le tableau est créé en mémoire vive et alimenté par les adresses toxiques.
Avec ce tableau particulier montée en mémoire vive, pour rechercher si une adresse détectée dans le journal de connexions correspond à une adresse toxique présente dans le tableau particulier, il suffit de faire une requête sur le tableau particulier au niveau de la clé correspondant à l’adresse détectée. Si cette requête ne donne aucune réponse, alors l’adresse détectée ne correspond pas à une adresse toxique. Au contraire, si la requête donne comme réponse un booléen ou l’adresse toxique recopiée au niveau des valeurs, alors l’adresse détectée correspond à une adresse toxique.
Ainsi, selon un mode de réalisation, ledit détecteur des flux toxiques est implémenté sur un système d’exploitation d’analyse du journal de connexions du pare-feu ; ladite base de données comportant une liste d’adresses toxiques étant stockée dans un tableau particulier ayant pour clés les adresses toxiques ; ledit tableau particulier étant monté en mémoire vive du système d’exploitation.
Par ailleurs, lorsque le détecteur des flux toxiques est implémenté sur un système d’exploitation d’analyse d’un journal de connexions d’un pare-feu, il peut être complexe de déterminer si une adresse détectée correspond à une adresse entrante ou sortante, par exemple dans l’exemple d’un pare-feu d’un opérateur réseau.
Les adresses d’un réseau peuvent être soit privées soit publiques. Si l’adresse est privée il est aisé de déterminer le sens du flux vis-à-vis de l’adresse publique du flux. Si l’adresse est publique, la détection révèle deux adresses publiques, une pour le réseau et une associée au flux, et la détermination du sens du flux nécessite d’autres informations que le type d’adresse, publique ou privée.
Pour ce faire, chaque flux réseau associé à une adresse toxique peut être comparé à une liste d’adresses présentes sur le réseau. A cet effet, un opérateur peut également fournir un fichier indiquant la liste des adresses de son réseau. A partir de cette liste d’adresses du réseau, il est possible de déterminer si l’adresse détectée à partir du journal de connexions correspond à un flux entrant ou sortant. En outre, il est également possible de regrouper les vulnérabilités détectées pour différents clients de l’opérateur afin que l’opérateur puisse connaître les entreprises ou les particuliers présentant un risque informatique important. L’opérateur peut ainsi prévenir les entreprises ciblées suite à la détection d’une menace de vulnérabilité importante ou régulière.
Pour analyser ces flux réseau à partir d’un serveur distant, chaque flux réseau est préférentiellement capté avec une information d’horodatage de ce flux réseau. L’évolution du risque informatique peut ainsi être analysée au cours du temps en regroupant les flux réseau associés à une même plage d’horodatage. Pour ce faire, ledit score de vulnérabilité est remis à zéro périodiquement et enregistré pour chaque période de temps entre deux remises à zéro. Ainsi, lorsque le gestionnaire du réseau détecte une nouvelle faille de sécurité, il peut retracer les modifications apportées avant la date de détection de la faille de sécurité pour contrôler la pertinence des modifications effectuées dernièrement. Par exemple, lorsque le gestionnaire du réseau doit configurer l’accès à un nouveau protocole sur le réseau, il peut utiliser le dispositif de l’invention après le déploiement des modifications du pare-feu pour contrôler que les restrictions nécessaires ont été mises en place.
Pour faciliter l’analyse des mises à jours passées, ledit score de vulnérabilité est préférentiellement remis à zéro une fois par jour. En variante, le score de vulnérabilité peut être remis à zéro toutes les heures ou toutes les 12 heures en fonction des besoins du gestionnaire réseau. En outre, le score de vulnérabilité peut également être remis à zéro manuellement par le gestionnaire réseau de sorte à mesurer directement l’impact d’une correction de vulnérabilité ou d’une modification effectuée sur le pare-feu.
Par ailleurs, le seuil de l’unité de caractérisation peut également être modifié par le gestionnaire du réseau en fonction des besoins de sécurité. De préférence, ladite unité de caractérisation est configurée avec une valeur de X égale à 6. En effet, lors de l’étude des entreprises effectuée dans le cadre de la présente invention, il a été observé que cette valeur particulière de X est la plus pertinente pour l’unité de caractérisation.
De plus, il a été observé que cinq catégories distinctes de sinistres peuvent être regroupés en fonction de la valeur des sinistres observés suite à l’observation des flux toxiques. De préférence, ladite unité de caractérisation est configurée pour classer chaque périphérique en cinq catégories :
- une catégorie de risque inexistant lorsque le score de vulnérabilité est de 0 ;
- une catégorie de risque faible lorsque le score de vulnérabilité est compris entre 1 et 5 ; ladite catégorie de risque limitée correspondant à l’association des catégories de risques inexistant et faible ;
- une catégorie de risque fort lorsque le score de vulnérabilité est compris entre 6 et 10 ;
- une catégorie de risque inexistant lorsque le score de vulnérabilité est de 0 ;
- une catégorie de risque faible lorsque le score de vulnérabilité est compris entre 1 et 5 ; ladite catégorie de risque limitée correspondant à l’association des catégories de risques inexistant et faible ;
- une catégorie de risque fort lorsque le score de vulnérabilité est compris entre 6 et 10 ;
- une catégorie de risque majeur lorsque le score de vulnérabilité est compris entre 11 et 99 ; et
- une catégorie de risque ultime lorsque le score de vulnérabilité est supérieur à 100 ; ladite catégorie de risque important correspondant à l’association des catégories de risques fort, majeur et ultime.
- une catégorie de risque ultime lorsque le score de vulnérabilité est supérieur à 100 ; ladite catégorie de risque important correspondant à l’association des catégories de risques fort, majeur et ultime.
Ces cinq catégories permettent d’indiquer rapidement à un gestionnaire de réseau les périphériques les plus sensibles. De préférence, pour faciliter l’analyse des résultats, ledit dispositif d’analyse comporte une interface de visualisation des catégories de risque associées à chaque périphérique et obtenues par ladite unité de caractérisation.
Cette interface de visualisation révèle la catégorie de risque associée à chaque périphérique. De préférence, l’évolution de la catégorie de risque est affichée en indiquant la catégorie de risque analysée sur les derniers jours.
Cette affichage peut prendre différentes formes sans changer l’invention. Par exemple, un code couleur peut être utilisé pour caractériser les différentes catégories de risque. De préférence, ladite interface de visualisation est configurée pour afficher chaque catégorie de risque associée à chaque périphérique sous la forme de pictogrammes météorologiques. Cette information simple permet d’informer efficacement le gestionnaire du réseau des risques associés à chaque périphérique du réseau.
Par exemple, ladite interface de visualisation est configurée pour afficher :
- ladite catégorie de risque inexistant par un soleil ;
- ladite catégorie de risque faible par un ciel nuageux ;
- ladite catégorie de risque fort par un orage ;
- ladite catégorie de risque majeur par un orage menaçant ; et
- ladite catégorie de risque ultime par une tornade.
- ladite catégorie de risque inexistant par un soleil ;
- ladite catégorie de risque faible par un ciel nuageux ;
- ladite catégorie de risque fort par un orage ;
- ladite catégorie de risque majeur par un orage menaçant ; et
- ladite catégorie de risque ultime par une tornade.
En plus d’afficher la vulnérabilité associée à chaque périphérique du réseau, l’interface de visualisation peut, en variante, afficher un pictogramme associé à la vulnérabilité globale du réseau.
En pratique, ladite interface de visualisation est configurée pour calculer un score global de vulnérabilité dudit réseau en sommant les scores de vulnérabilité de chaque périphérique dudit réseau.
Outre la fonction d’analyse des flux toxiques, le dispositif peut également assurer d’autres fonctions, tels que le blocage des flux toxiques. De préférence, ledit dispositif d’analyse comporte une unité d’analyse du volume de données consommées par chaque périphérique.
Description sommaire des figures
La manière de réaliser l’invention, ainsi que les avantages qui en découlent, ressortiront bien de la description des modes de réalisation qui suivent, à l’appui des figures annexées dans lesquelles :
la figure 1 est une représentation schématique d’une architecture réseau selon un mode de réalisation de l’invention ;
Description détaillée de l’invention
La description qui suit présente un mode de réalisation dans lequel l’analyse des flux réseau est réalisée au moyen d’un boitier physiquement implanté dans un réseau local et effectuant tous les traitements permettant d’analyser le risque informatique d’un ensemble de périphériques connectés sur le réseau local.
En variante, le boitier d’analyse peut capter l’ensemble des flux réseau entrants et sortants du pare-feu afin de transmettre les informations de ces flux à un serveur distant intégrant la base de données d’adresses toxiques et effectuant le comptage du score de vulnérabilité de chaque périphérique.
De la même manière, un utilisant un outil d’enregistrement des flux réseau intégré dans le pare-feu, cet outil d’enregistrement peut être utilisé à la place du boitier d’analyse pour transmettre les informations de ces flux à un serveur distant effectuant le comptage du score de vulnérabilité de chaque périphérique.
L’outil d’enregistrement des flux réseau intégré dans le pare-feu peut correspondre à un journal de connexions et l’invention peut être réalisée en analysant ce journal de connexions.
En référence à la figure 1, une architecture réseau 100 émet et reçoit des flux d’informations vers et depuis Internet 11 avec des origines et des destinations diverses. Au sens de l’invention, un flux d’information correspond à un ensemble de paquets réseau échangés entre deux périphériques. Pour ce faire, une communication est mise en place entre les deux périphériques au moyen d’un protocole spécifique lié à la nature de la communication. La suite de protocoles TCP/IP rassemble tous les protocoles permettant de transférer des données internet.
Ces protocoles peuvent être séparés en différentes couches selon leur nature. Par exemple, les protocoles d’application (HTTP, HTTPS…) ou de réseau (IPV4, IPV6, ICMP…).
A titre d’exemple, pour afficher une page internet depuis un ordinateur personnel, une requête est formulée sur un navigateur. La requête se traduit sous la forme d’une adresse internet comportant des informations sur :
- le protocole d’application, typiquement HTTP ou HTTPS ;
- l’hôte, c’est-à-dire le serveur sur lequel est hébergé l’information ; et
- la page demandée.
- le protocole d’application, typiquement HTTP ou HTTPS ;
- l’hôte, c’est-à-dire le serveur sur lequel est hébergé l’information ; et
- la page demandée.
Le navigateur applique le protocole IP pour identifier ces informations et retrouver l’adresse IP du serveur en question en appliquant le protocole d’application DNS.
Une fois cette information trouvée, le protocole TCP permet d’envoyer la requête sur un port (80 pour le protocole HTTP et 442 pour le protocole HTTPS) du serveur 14. Le serveur 14 répond à la requête en recherchant la page demandée et en transmettant le contenu de la page, sous format HTML par exemple, au navigateur. Enfin, le navigateur lit le contenu de la page et l’affiche sur l’ordinateur personnel.
Un pare-feu 12 est classiquement positionné entre les deux périphériques communiquant, par exemple pour protéger un réseau local 101 dans lequel un serveur 14 est disposé. Le réseau local 101 est formé par au moins un concentrateur réseau 18, aussi appelé « switch » dans la littérature anglo-saxonne, permettant de concentrer les communications réseau de plusieurs équipements appartenant au réseau local 101, tels que les serveurs 14, les ordinateur 15 ou les imprimantes 16. Ce pare-feu 12 est en charge de déterminer quels protocoles sont autorisés sur le réseau local 101. Plus précisément, pour chaque flux entrant 17a sur le réseau local 101, le pare-feu 12 identifie la suite de protocoles utilisée par le flux entrant 17a et bloque le flux entrant 17a si un des protocoles utilisés ne correspond pas à une liste de protocoles autorisés.
Si le protocole est autorisé, le pare-feu 12 peut transmettre le flux entrant 17a à un périphérique 14-16 du réseau local 101 au moyen d’un flux interne 17b.
De plus, la pare-feu 12 peut également être configuré pour bloquer les protocoles de certains flux sortants 17c émis par un périphérique 14-16 du réseau local 101.
Selon l’invention, un dispositif d’analyse du risque informatique 13 est intégré dans l’architecture réseau 100 entre le pare-feu 12 et le concentrateur réseau 18. Ce dispositif d’analyse du risque informatique 13 est configuré pour :
- surveiller les flux d’informations 17b qui sont entrés dans le réseau local 101 après avoir passé le pare-feu 12 ; et
- surveiller les flux d’informations 17c qui sont sortis d’un périphérique 14-16 en direction d’Internet 11 avant de passer le pare-feu 12.
- surveiller les flux d’informations 17b qui sont entrés dans le réseau local 101 après avoir passé le pare-feu 12 ; et
- surveiller les flux d’informations 17c qui sont sortis d’un périphérique 14-16 en direction d’Internet 11 avant de passer le pare-feu 12.
Tel qu’illustré sur les figure 2 et 3, lorsque le pare-feu 12 détecte un flux d’information 21 utilisant un protocole non-autorisé sur le réseau local 101, les paquets réseau appartenant à ce flux d’information sont bloqués et ils ne sont pas transmis au réseau local 101.
Cependant, certains flux d’informations potentiellement dangereux 22-23 parviennent à franchir le pare-feu 12. Pour chaque ensemble de paquets réseau composant le flux d’information entrant ou sortant de l’architecture réseau 100, le dispositif d’analyse du risque informatique 13 identifie l’adresse IP du périphérique émetteur et du périphérique destinataire. Par exemple, pour un flux d’informations entrant, le dispositif d’analyse du risque informatique 13 identifie comme émetteur l’adresse IP du serveur externe au réseau local 101 et comme destinataire, l’adresse IP de l’ordinateur 15 appartenant au réseau local 101. Pour un flux d’informations sortant, le dispositif d’analyse du risque informatique 13 identifie comme émetteur l’adresse IP de l’ordinateur 15 appartenant au réseau local 101 et comme destinataire l’adresse IP du serveur externe au réseau local 101.
Le dispositif d’analyse du risque informatique 13 communique avec une base de données comportant des adresses IP potentiellement dangereuses.
Cette base de données peut être externe ou interne. Dans ce dernier cas de figure, la base de données doit être mise à jour périodiquement.
Si l’émetteur ou le destinataire du flux d’information possède une adresse IP contenue dans cette base de données, le dispositif d’analyse du risque informatique 13 est en charge d’incrémenter un compteur 19 associé au périphérique 14-16, appartenant au réseau local 101, qui est impliqué dans l’échange de flux d’informations.
Tel qu’illustré sur la figure 2, lorsque le dispositif d’analyse du risque informatique 13 identifie une flux d’informations entrant 22 dont le périphérique émetteur possède une adresse IP toxique, le compteur 19 est incrémenté d’une valeur égale à +1.
Tel qu’illustré sur la figure 3, lorsque le dispositif d’analyse du risque informatique 13 identifie une flux d’informations sortant 23 dont le périphérique destinataire possède une adresse IP toxique, le compteur 19 est incrémenté d’une valeur égale à +10.
Généralement, les informations sortantes potentiellement dangereuses 23 sont plus rares que les informations entrantes potentiellement dangereuses 22. Cependant, l’analyse de ces flux potentiellement dangereux 22-23 a permis de mettre en évidence que les mécanismes malveillants associés à un humain ou à un logiciel malveillant venant de l’intérieur sont beaucoup plus préjudiciables pour une entreprise, car ils contournent les mécanismes de sécurité en place. Par exemple, la perte du fichier commercial suite au licenciement d’un commercial ou la retro ingénierie à partir d’un carnet d’adresse Microsoft Outlook ont un impact économique sur l’entreprise qui justifie que le poids accordé à la sortie d’informations potentiellement dangereuses 23 soit dix fois supérieur au poids d’une information entrante potentiellement dangereuse 22.
De manière périodique, typiquement tous les jours ou toutes les semaines, un relevé est effectué sur le dispositif d’analyse du risque informatique 13.
En référence à la figure 4, la vulnérabilité d’un périphérique 14-16 peut être analysée grâce au compteur interne 19 au dispositif d’analyse du risque informatique 13, associé à chaque périphérique 14-16 du réseau local 101.
Deux catégories de valeurs sont à distinguer. La première catégorie I comprend des valeurs du compteur 19 comprises entre 0 et 5. Cette première catégorie I ne comprend que des informations entrantes potentiellement dangereuses 22.
La second catégorie II comprend des valeurs supérieures à 5. Cette seconde catégorie comprend potentiellement des informations sortantes potentiellement dangereuses 23 dont l’impact peut être largement plus préjudiciable à l’entreprise.
Typiquement, un score de 10 peut correspondre à 10 informations entrantes potentiellement dangereuses 22 ou 1 information sortante potentiellement dangereuse 23.
En plus de ces deux catégories I et II, des sous-intervalles de valeurs sont définis. Afin de permettre une meilleure visualisation de la vulnérabilité d’un périphérique, des pictogrammes météorologiques 31-35 sont utilisés.
Par exemple, pour un score de 0 information sortante et/ou entrante potentiellement dangereuse, un soleil 31 apparaît à côté du périphérique concerné. Pour un score compris entre 1 et 5, le pictogramme associé est un nuage pluvieux 32. Pour un score compris entre 6 et 10, le pictogramme associé est un nuage orageux avec un seul éclair 33. Pour un score compris entre 11 et 99, le pictogramme est un nuage orageux avec trois éclairs 34. Et enfin, pour un score supérieur à 100, le pictogramme associé est une tornade 35.
Tel qu’illustré sur la figure 5, la vulnérabilité des périphériques 14a, 14b, 15a, 15b, 16 du réseau local 101 peut être résumée sur une interface de visualisation 102.
Par exemple, l’interface de visualisation 102 peut correspondre à un tableau à double entrées avec en entête de colonne, la date du relevé de vulnérabilité et en entête de ligne, le périphérique 14a, 14b, 15a, 15b, 16 concerné. Pour chaque périphérique 14a, 14b, 15a, 15b, 16 et à chaque date de relevé, un pictogramme 31-35 est associé au périphérique 14a, 14b, 15a, 15b, 16 en fonction du score déterminé par le compteur du dispositif d’analyse du risque informatique 13.
De préférence, chaque flux réseau capté est associé à une information d’horodatage de sorte que les flux réseau toxiques puissent être regroupés et que le score de vulnérabilité puisse être calculé selon une échelle de temps, par exemple par jour.
Cette représentation permet avantageusement de suivre l’évolution dans le temps de la vulnérabilité de chaque périphérique 14a, 14b, 15a, 15b, 16 et d’identifier d’éventuels schémas d’action employés par les pirates informatiques.
La dernière ligne du tableau de la figure 5 correspond à l’état de vulnérabilité de l’ensemble du réseau local 101. Ce score est calculé en effectuant la somme des scores de chaque périphérique 14a, 14b, 15a, 15b, 16 constituant le réseau local 101. Un pictogramme 31-35 est également attribué en fonction du score obtenu.
En variante, le dispositif d’analyse du risque informatique 13 peut bloquer les flux d’informations entrants et/ou sortants 22-23 dont l’émetteur et/ou le destinataire possède une adresse IP toxique.
De même, le dispositif d’analyse du risque informatique 13 peut permettre de rendre compte de la consommation des données de chaque périphérique 14a, 14b, 15a, 15b, 16 du réseau local 101.
Pour conclure, les différents modes de réalisation de l’invention permettent de caractériser de manière visuelle et facilement compréhensible le risque informatique encouru par une structure au cours du temps.
Claims (12)
- Dispositif d’analyse du risque informatique (13) d’un ensemble de périphériques (14, 14a, 14b, 15, 15a, 15b, 16) connectés sur un réseau (101), ledit dispositif comportant :
- un organe de supervision des flux entrants (17a, 22) et sortants (17c, 23) de chaque périphérique (14, 14a, 14b, 15, 15a, 15b, 16) du réseau (101) depuis et vers Internet (11) ;
- un détecteur des flux toxiques (22-23) comparant l’adresse de provenance et de destination de ces flux entrants (17a, 22) et sortants (17c, 23) avec une base de données comportant une liste d’adresses toxiques ;
- un compteur (19) des flux toxiques (22-23) détectés pour chaque périphérique (14, 14a, 14b, 15, 15a, 15b, 16) du réseau (101), ledit compteur (19) étant configuré pour déterminer un score de vulnérabilité associé au périphérique (14, 14a, 14b, 15, 15a, 15b, 16) en appliquant un facteur de dix aux flux toxiques sortants (23) par rapport aux flux toxiques entrants (22) ; et
- une unité de caractérisation du risque informatique associé à chaque périphérique (14, 14a, 14b, 15, 15a, 15b, 16) en fonction du score de vulnérabilité de chaque périphérique (14, 14a, 14b, 15, 15a, 15b, 16), ladite unité de caractérisation étant configurée pour classer chaque périphérique (14, 14a, 14b, 15, 15a, 15b, 16) entre au moins deux catégories (I-II) :
* une catégorie de risque limitée (I) lorsque le score de vulnérabilité est compris entre 0 et X ; et
* une catégorie de risque important (II) lorsque le score de vulnérabilité est supérieur à X ; avec X compris entre 1 et 9. - Dispositif d’analyse du risque informatique selon la revendication 1, dans lequel chaque flux réseau est capté avec une information d’horodatage de ce flux réseau.
- Dispositif d’analyse du risque informatique selon la revendication 1 ou 2, dans lequel ledit score de vulnérabilité est calculé par jour.
- Dispositif d’analyse du risque informatique selon l’une des revendications 1 à 3, dans lequel ladite unité de caractérisation est configurée avec une valeur de X égale à 6.
- Dispositif d’analyse du risque informatique selon la revendication 4, dans lequel ladite unité de caractérisation est configurée pour classer chaque périphérique (14, 14a, 14b, 15, 15a, 15b, 16) en cinq catégories :
- une catégorie de risque inexistant lorsque le score de vulnérabilité est de 0 ;
- une catégorie de risque faible lorsque le score de vulnérabilité est compris entre 1 et 5 ; ladite catégorie de risque limitée (I) correspondant à l’association des catégories de risques inexistant et faible ;
- une catégorie de risque fort lorsque le score de vulnérabilité est compris entre 6 et 10 ;
- une catégorie de risque majeur lorsque le score de vulnérabilité est compris entre 11 et 99 ; et
- une catégorie de risque ultime lorsque le score de vulnérabilité est supérieur à 100 ; ladite catégorie de risque important (II) correspondant à l’association des catégories de risques fort, majeur et ultime. - Dispositif d’analyse du risque informatique selon l’une des revendications 1 à 5, dans lequel ledit dispositif d’analyse comporte une interface de visualisation (102) des catégories de risque (I-II) associées à chaque périphérique (14, 14a, 14b, 15, 15a, 15b, 16) et obtenues par ladite unité de caractérisation.
- Dispositif d’analyse du risque informatique selon la revendication 6, dans lequel ladite interface de visualisation (102) est configurée pour afficher chaque catégorie de risque associée à chaque périphérique sous la forme de pictogrammes météorologiques (31-35).
- Dispositif d’analyse du risque informatique selon les revendication 5 et 7, dans lequel ladite interface de visualisation est configurée pour afficher :
- ladite catégorie de risque inexistant par un soleil (31) ;
- ladite catégorie de risque faible par un ciel nuageux (32) ;
- ladite catégorie de risque fort par un orage (33) ;
- ladite catégorie de risque majeur par un orage menaçant (34) ; et
- ladite catégorie de risque ultime par une tornade (35). - Dispositif d’analyse du risque informatique selon l’une des revendications 1 à 8, dans lequel ledit dispositif d’analyse comporte une unité d’analyse du volume de données consommées par chaque périphérique (14, 14a, 14b, 15, 15a, 15b, 16).
- Dispositif d’analyse du risque informatique selon l’une des revendications 1 à 9, dans lequel ladite interface de visualisation est configurée pour calculer un score global de vulnérabilité dudit réseau (101) en sommant les scores de vulnérabilité de chaque périphérique (14, 14a, 14b, 15, 15a, 15b, 16) dudit réseau (101).
- Dispositif d’analyse du risque informatique selon l’une des revendications 1 à 10, dans lequel ledit organe de supervision des flux entrants (17a, 22) et sortants (17c, 23) de chaque périphérique correspond à un journal de connexions d’un pare-feu.
- Dispositif d’analyse du risque informatique selon la revendication 11, dans lequel ledit détecteur des flux toxiques (22-23) est implémenté sur un système d’exploitation d’analyse du journal de connexions du pare-feu ; ladite base de données comportant une liste d’adresses toxiques étant stockée dans un tableau particulier ayant pour clés les adresses toxiques ; ledit tableau particulier étant monté en mémoire vive du système d’exploitation.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2006068A FR3111442B1 (fr) | 2020-06-10 | 2020-06-10 | Dispositif d’analyse du risque informatique d’un ensemble de périphériques connectés sur un réseau |
| FR2006068 | 2020-06-10 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3111443A1 true FR3111443A1 (fr) | 2021-12-17 |
| FR3111443B1 FR3111443B1 (fr) | 2023-03-24 |
Family
ID=72885653
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR2006068A Active FR3111442B1 (fr) | 2020-06-10 | 2020-06-10 | Dispositif d’analyse du risque informatique d’un ensemble de périphériques connectés sur un réseau |
| FR2008929A Active FR3111443B1 (fr) | 2020-06-10 | 2020-09-03 | Dispositif d’analyse du risque informatique d’un ensemble de périphériques connectés sur un réseau |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR2006068A Active FR3111442B1 (fr) | 2020-06-10 | 2020-06-10 | Dispositif d’analyse du risque informatique d’un ensemble de périphériques connectés sur un réseau |
Country Status (1)
| Country | Link |
|---|---|
| FR (2) | FR3111442B1 (fr) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR3135336A1 (fr) * | 2022-05-09 | 2023-11-10 | Serenicity | Methode d’analyse du risque informatique d’un reseau d’interet lie aux echanges avec au moins un reseau tiers |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030105976A1 (en) * | 2000-11-30 | 2003-06-05 | Copeland John A. | Flow-based detection of network intrusions |
| US20040193943A1 (en) * | 2003-02-13 | 2004-09-30 | Robert Angelino | Multiparameter network fault detection system using probabilistic and aggregation analysis |
| US20130117812A1 (en) * | 2010-07-13 | 2013-05-09 | Cassidian Sas | Supervision of the security in a computer system |
| US20160156644A1 (en) * | 2011-05-24 | 2016-06-02 | Palo Alto Networks, Inc. | Heuristic botnet detection |
-
2020
- 2020-06-10 FR FR2006068A patent/FR3111442B1/fr active Active
- 2020-09-03 FR FR2008929A patent/FR3111443B1/fr active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030105976A1 (en) * | 2000-11-30 | 2003-06-05 | Copeland John A. | Flow-based detection of network intrusions |
| US20040193943A1 (en) * | 2003-02-13 | 2004-09-30 | Robert Angelino | Multiparameter network fault detection system using probabilistic and aggregation analysis |
| US20130117812A1 (en) * | 2010-07-13 | 2013-05-09 | Cassidian Sas | Supervision of the security in a computer system |
| US20160156644A1 (en) * | 2011-05-24 | 2016-06-02 | Palo Alto Networks, Inc. | Heuristic botnet detection |
Non-Patent Citations (2)
| Title |
|---|
| MENG WEIZHI: "Intrusion Detection in the Era of IoT: Building Trust via Traffic Filtering and Sampling", COMPUTER, IEEE COMPUTER SOCIETY, USA, vol. 51, no. 7, 1 July 2018 (2018-07-01), pages 36 - 43, XP011687691, ISSN: 0018-9162, [retrieved on 20180727], DOI: 10.1109/MC.2018.3011034 * |
| SUHAS MATHUR ET AL: "Detecting hidden enemy lines in IP address space", NEW SECURITY PARADIGMS WORKSHOP, ACM, 2 PENN PLAZA, SUITE 701 NEW YORK NY 10121-0701 USA, 9 September 2013 (2013-09-09), pages 19 - 30, XP058036087, ISBN: 978-1-4503-2582-0, DOI: 10.1145/2535813.2535816 * |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR3135336A1 (fr) * | 2022-05-09 | 2023-11-10 | Serenicity | Methode d’analyse du risque informatique d’un reseau d’interet lie aux echanges avec au moins un reseau tiers |
Also Published As
| Publication number | Publication date |
|---|---|
| FR3111443B1 (fr) | 2023-03-24 |
| FR3111442B1 (fr) | 2023-07-28 |
| FR3111442A1 (fr) | 2021-12-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8205259B2 (en) | Adaptive behavioral intrusion detection systems and methods | |
| US20070139231A1 (en) | Systems and methods for enterprise-wide data identification, sharing and management in a commercial context | |
| EP3731166A1 (fr) | Regroupement de donnèes | |
| US20040098623A1 (en) | Intrusion detection system | |
| Sibiya et al. | Digital forensic framework for a cloud environment | |
| US20120011590A1 (en) | Systems, methods and devices for providing situational awareness, mitigation, risk analysis of assets, applications and infrastructure in the internet and cloud | |
| US20120246303A1 (en) | Log collection, structuring and processing | |
| US20080159146A1 (en) | Network monitoring | |
| US8577680B2 (en) | Monitoring and logging voice traffic on data network | |
| WO2016085412A1 (fr) | Systèmes et procédés d'interception, filtrage et blocage en temps réel de contenu internet | |
| FR3111443A1 (fr) | Dispositif d’analyse du risque informatique d’un ensemble de périphériques connectés sur un réseau | |
| Lubis et al. | Network forensic application in general cases | |
| EP3343423A1 (fr) | Systeme de securisation d´un reseau informatique local | |
| US9497205B1 (en) | Global commonality and network logging | |
| Krishnan | Role and Impact of Digital Forensics in Cyber Crime Investigations | |
| WO2007081960A2 (fr) | Systèmes et procédés d'identification, partage et gestion des données à l'échelle de l'entreprise dans un contexte commercial | |
| FR3135337A1 (fr) | Methode d’analyse du risque informatique d’un reseau d’interet lie aux echanges avec au moins un reseau tiers | |
| EP3035639B1 (fr) | Procédé de détection de balayage de ports non-autorisé dans un réseau informatique, produit programme d'ordinateur et dispositif associés | |
| FR3135336A1 (fr) | Methode d’analyse du risque informatique d’un reseau d’interet lie aux echanges avec au moins un reseau tiers | |
| Nehinbe et al. | Audit and research challenges in digital forensics | |
| Submitter et al. | The Effects of Volatile Features on Digital Evidence Preservation | |
| Xynos et al. | D1: Design Specification of the| Digital Forensics Toolset | |
| Chikuruwo et al. | The Effects of Volatile Features on Digital Evidence Preservation | |
| Casey | Applying Forensic Science to Networks | |
| Srivastav et al. | Network Forensics an emerging approach to an network analysis. |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20211217 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |