FR2896897A1 - Detection d'incidents de securite dans un reseau de telecommunications - Google Patents

Abstract

Pour détecter un incident de sécurité dans un réseau de télécommunications (RT), des flux de requête (REQ) à l'origine de communications dans le réseau sont déterminés au moyen de sondes (SD). Chaque flux de requête inclut des adresses de source et destination de dispositifs de réseau entre lesquels sont transmis des paquets. Un dispositif (DTD) construit au moins un graphe orienté comprenant des arcs orientés reliant chacun des adresses de source et destination d'un flux de requête déterminé et identifie dans le graphe orienté au moins une composante connexe comprenant une adresse racine et des adresses de destination reliées chacune à l'adresse racine par un ensemble d'arcs orientés. Au moins un indicateur d'incident est déterminé en fonction des adresses de destination de la composante connexe identifiée. Si l'indicateur est supérieur à un seuil, l'incident de sécurité est signalé.

Description

Détection d'incidents de sécurité dans un réseau de télécommunications

La présente invention concerne la sécurité dans un réseau de télécommunications et en particulier des analyses de paquets transmis dans le réseau pour détecter des incidents de sécurité dans le réseau.

Des incidents de sécurité surviennent dans un réseau à la suite d'actions hostiles telles qu'une propagation de code malveillant comme un "vers" ou un "virus" dans le réseau, ou un "scan" du réseau, ou encore une exploitation de vulnérabilités d'un dispositif à une attaque depuis un autre dispositif connecté au réseau. Un ver est un programme capable de se propager dans le réseau sans intervention et à l'insu des utilisateurs des machines successives sur lesquelles il s'exécute. Pour s'exécuter sur une première machine, un virus nécessite quant à lui l'intervention d'un utilisateur de la première machine, par exemple l'ouverture d'un fichier reçu. Le virus attaque ensuite de la même façon une deuxième machine connectée à la première machine. Un scan du réseau est une technique pour découvrir quels dispositifs connectés au réseau présentent des faiblesses au niveau de la sécurité. Généralement, la propagation d'un ver à travers un réseau qui n'est pas protégé par un système de sécurité adéquat, est rapide et efficace.

Il existe donc un besoin de disposer d'un système de sécurité capable de repérer rapidement et efficacement tout incident de sécurité intervenant sur un réseau informatique. Ceci est d'autant plus vrai que les propagations virales sont généralement extrêmement rapides et détériorent la qualité de

service du réseau. Seule une détection fine et rapide de tout type d'incident de sécurité permet de choisir la réaction la plus adéquate en fonction du type d'incident détecté.

Plusieurs techniques de détection d'incidents de sécurité dans un réseau sont connues. Par exemple, un pare-feu situé en périphérie d'un réseau applique une politique de sécurité sur des paquets transmis par d'autres réseaux et entrant dans le réseau de manière à empêcher des actions non autorisées. Dans ce cas, un ver réalisant une action non autorisée pourrait être détecté par le pare-feu. Cependant, à cause de la position du pare -feu en coupure dans le réseau pour retirer des paquets anormaux, le pare-feu ne peut pas détecter toutes les actions non autorisées. Par exemple si le ver est déjà entré dans le réseau protégé, le pare-feu ne peut contrôler le trafic interne au réseau et n'est alors plus efficace pour détecter la propagation du ver. Cette faiblesse de principe du pare-feu est en partie compensée par des sondes de détection d'intrusion IDS ("Intrusion Detection System" en anglais) qui sont connectées en écoute au réseau pour analyser le trafic en des noeuds définis du réseau tels que des interconnexions de réseaux, des routeurs ou des commutateurs. Les sondes identifient des transmissions de paquets malveillantes, essentiellement grâce à des techniques à base de signature de ver. Certaines techniques de détection d'incidents de sécurité reposent sur une analyse de données collectées par un équipement de réseau, telles que des adresses IP ("Internet Protocol" en anglais) de dispositifs très actifs dans l'émission de paquets de

données, des protocoles et ports de destination de dispositifs qui sont les plus souvent utilisés, ou encore des taux de non-réponse de dispositifs à des réceptions de paquet. Ces techniques utilisent généralement des parcours des données collectées dans des bases de données, telles que des journaux d'activité indiquant qu'un premier dispositif a envoyé à tel instant un paquet de tel type vers un deuxième dispositif, pour réaliser des statistiques simples. Cependant, ces techniques sont fortement sujettes à des "faux positifs". Par exemple, une adresse IP très active n'est pas obligatoirement à l'origine d'un incident de sécurité. Dans un réseau informatique, les adresses IP les plus actives peuvent être interprétées comme des informations sur des usagers qui utilisent le plus souvent les services du réseau, tels que l'envoi de courriels, mais pas forcément des informations sur des incidents de sécurité. Actuellement, des sondes IDS utilisent des techniques de détection de type pattern matching pour détecter une signature de ver connu, ladite signature étant par exemple une suite d'octets qui permet d'identifier le ver avec plus ou moins de précision. L'efficacité des sondes IDS dépend grandement du type des signatures et de la rapidité des mises à jour des techniques de détection. Ces techniques de détection ont notamment pour inconvénients d'être susceptibles de fournir des "faux négatifs" et des "faux positifs". Les faux négatifs résultent de l'incapacité à identifier des vers dont la signature n'a pas été préalablement répertoriée. Les faux positifs peuvent avoir des taux élevés induits par des signatures de ver

insuffisamment précises, ce qui rend les techniques de détection particulièrement inefficaces. Par conséquent, les techniques de détection à base de signature de ver sont très perfectibles et ne peuvent détecter tout type d'incident de sécurité avec finesse et efficacité.

Pour remédier aux inconvénients évoqués ci-dessus, un procédé selon l'invention pour détecter un incident de sécurité dans un réseau de télécommunications, comprenant une détermination de flux de requête qui sont à l'origine de communications dans le réseau, chaque flux de requête incluant une adresse de source et une adresse de destination de dispositifs de réseau entre lesquels sont transmis des paquets dans le réseau, est caractérisé en ce qu'il comprend les étapes de : construire au moins un graphe orienté comprenant des arcs orientés reliant chacun une adresse de source à une adresse de destination d'un flux de requête déterminé, identifier dans le graphe orienté au moins une composante connexe comprenant une adresse racine et des adresses de destination reliées chacune à l'adresse racine par un ensemble d'arcs orientés, déterminer au moins un indicateur d'incident en fonction des adresses de destination de la composante connexe identifiée, et signaler l'incident de sécurité si l'indicateur d'incident est supérieur à un seuil choisi. Avantageusement, l'invention détecte avec précision et rapidement tout type d'incident afin de choisir l'action la plus adéquate pour traiter l'incident détecté.

L'invention détecte notamment des propagation s de vers dans un réseau par une analyse des transmissions de paquets dans le réseau, sans avoir recours à une base de données de signatures de vers.

Par conséquent, l'invention ne dépend pas de mises à jour externes pour des outils de sécurité ou des bases de données de signatures, et peut détecter de nouveaux incidents relatifs à des vers sans nécessiter de signatures spécifiques, ou bien détecter des incidents de sécurité non malveillants, tels qu'une surcharge de trafic dans le réseau suite à une configuration inadéquate du réseau. La construction de graphes orientés et l'identification de composantes connexes dans les graphes construits permettent de déterminer un ou plusieurs indicateurs d'incident, apportant à la fois une grande souplesse et une grande efficacité à la détection d'incident. La construction des graphes est en outre indépendante des indicateurs d'incident et les graphes servent à détecter, en fonction des indicateurs déterminés, des familles d'incidents très diverses telles qu'une propagation virale, un scan rapide, ou un scan lent, contrairement à la plupart des outils actuels, qui ne détectent qu'un type de famille d'incidents. Par ailleurs, la détection d'incident selon l'invention peut être utilisée sur tout type de réseau, tel qu'un intranet d'entreprise. L'invention n'a pas d'impact sur l'architecture et le fonctionnement global du réseau, les équipements déjà déployés dans le réseau tels que des routeurs ou des sondes de trafic pouvant récupérer des informations sur des transmissions de paquets dans le réseau selon tout type de protocole, notamment tout type de protocole de transport.

L'invention concerne également un dispositif de détection pour détecter un incident de sécurité dans un réseau de télécommunications, comprenant un moyen pour déterminer des flux de requête qui sont à l'origine de communications dans le réseau, chaque flux de requête incluant une adresse de source et une adresse de destination de dispositifs de réseau entre lesquels sont transmis des paquets lors d'une communication dans le réseau. Le dispositif de détection est caractérisé en ce qu'il comprend : - un moyen pour construire au moins un graphe orienté comprenant des arcs orientés reliant chacun une adresse de source à une adresse de destination d'un flux de requête déterminé, - un moyen pour identifier dans le graphe orienté au moins une composante connexe comprenant une adresse racine et des adresses de destination reliées chacune à l'adresse racine par un ensemble d'arcs orientés, - un moyen pour déterminer au moins un indicateur d'incident en fonction des adresses de destination de la composante connexe identifiée, et - un moyen pour signaler l'incident de sécurité si l'indicateur d'incident est supérieur à un seuil choisi.

L'invention se rapporte encore à un programme d'ordinateur apte à être mis en oeuvre dans un dispositif de détection d'incident de sécurité dans un réseau de télécommunications, ledit programme comprenant des instructions qui, lorsque le programme est exécuté dans ledit dispositif, réalisent les étapes selon le procédé de l'invention.35

D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description suivante de plusieurs réalisations de l'invention données à titre d'exemples non limitatifs, en référence aux dessins annexés correspondants dans lesquels : - la figure 1 est un bloc-diagramme schématique d'un système de télécommunications comprenant un dispositif selon l'invention pour détecter un incident de sécurité dans un réseau de télécommunications ; -la figure 2 est un algorithme d'un procédé de détection d'incident de sécurité dans un réseau de télécommunications selon l'invention ; et - les figures 3 et 4 sont des graphes orientés selon l'invention reliant des adresses de source et des adresses de destination.

En référence à la figure 1, le système de télécommunications comprend des sondes de détection SD1 à SDN, un collecteur de flux CF et un dispositif de traitement de données DTD en relation avec une base de données BD. Les sondes et le collecteur de flux communiquent entre eux à travers un réseau de télécommunications RT. Le réseau de télécommunications RT est par exemple un réseau informatique, tel qu'un intranet d'une entreprise ou l'Internet. Une sonde de détection SDn est un équipement de réseau par exemple relié à un noeud du réseau RT, tel qu'un routeur ou une passerelle, à travers lequel des paquets de données sont acheminés depuis des dispositifs du réseau, dits également machines ou stations, et redirigés vers d'autres dispositifs du réseau. Afin de ne pas surcharger la figure 1, on n'a

représenté seulement trois sondes de détection SD1, SDn et SDN, avec l'indice n tel que 1 n <_ N. Une sonde de détection SDn produit des flux de réseau RES comportant des informations prélevées dans des champs de paquets transmis dans le réseau. Un flux de réseau RES relatif à des paquets transmis depuis un premier dispositif du réseau vers un deuxième dispositif du réseau comprend les champs d'information suivants . - une adresse IP d'un premier dispositif du réseau qui est la source d'une transmission de paquets, appelée par la suite adresse de source AS, - une adresse IP d'un deuxième dispositif du réseau qui est la destination d'une transmission de paquets, appelée par la suite adresse de destination AD, -un type de protocole de transport TYP, - un port logique de source PS associé à un processus dans le premier dispositif produisant des paquets à transmettre, et un port logique de destination PD associé à un processus dans le deuxième dispositif traitant des paquets reçus, les processus dans les deux dispositifs utilisant le type de protocole de transport TYP pour la transmission de paquets entre le dispositif d'adresse de source AS et le dispositif d'adresse de destination AD, un paquet à transmettre depuis le premier dispositif vers le deuxième dispositif incluant des champs identifiant le type de protocole de transport TYP et le port logique de destination PD; - une date de début de transmission de paquets DATD et une date de fin de transmission de 25 30 35

paquets DATF pour la transmission de paquets entre le dispositif d'adresse de source AS et le dispositif d'adresse de destination AD. Les adresses IP identifient des dispositifs du réseau et sont par exemple au format "w.x.y.z" où w, x, y et z sont des entiers compris entre 0 et 255. Les types de protocole de transport TYP sont par exemple le protocole de transport TCP ("Transport Control Protocol" en anglais) ou le protocole de transport UDP ("User Datagram Protocol" en anglais). Chaque sonde de détection SDn transmet des flux de réseau RES au collecteur de flux CF via le réseau de télécommunications RT au moyen d'un protocole spécifique, tel que le protocole NetFlow de la société CISCO. Le collecteur de flux CF transmet alors les flux de réseau RES au dispositif de traitement de données DTD pour l'analyse des flux de réseau. Le collecteur de flux C F selon l'invention est un ordinateur du type ordinateur personnel, ou serveur, ou terminal. Selon la figure 1, le collecteur de flux CF et le dispositif de traitement de données DTD communiquent entre eux par un réseau local ou par des lignes spécialisées. Dans une variante, le collecteur CF et le dispositif DTD peuvent communiquer entre eux à travers le réseau de télécommunications RT du type intranet. Dans une autre variante, le collecteur CF et le dispositif DTD sont confondus en ou intégrés dans un unique dispositif.

Le dispositif de traitement de données DTD selon l'invention comprend une unité centrale UC, un module de corrélation COR, un module de construction de graphe orienté MGO, un module de détermination de

composantes connexes M CC et un module d'indicateur d'incident MII. Le dispositif de traitement de données DTD selon l'invention est un ordinateur du type ordinateur personnel, ou serveur, ou terminal. La base de données BD est liée au dispositif de traitement de données DTD, c'est-à-dire elle est soit intégrée dans le dispositif de traitement de données, soit incorporée dans un serveur de gestion de base de données et reliée au dispositif de traitement de données par une liaison locale ou distante. La base de données BD comprend notamment des informations nécessaires au fonctionnement du dispositif DTD de l'invention telles que des flux de réseau RES, des flux de requête REQ et des graphes orientés GO.

En référence à la figure 2, le procédé selon l'invention comprend des étapes El à E7 exécutées automatiquement et cycliquement sous le contrôle de l'unité centrale UC dans le dispositif de traitement de données DTD et mises en oeuvre par des instructions d'un programme d'ordinateur enregistré sur un support d'enregistrement lisible par le dispositif de traitements de données DTD.

A une étape initiale E0, les sondes de détection SDn du système de télécommunications selon l'invention analysent des paquets transmis entre des dispositifs du réseau de télécommunications RT et produisent des flux de réseau RES en fonction des paquets analysés. Les sondes de détection transmettent alors les flux de réseau produits RES au dispositif de traitement de données DTD via le collecteur de flux CF à travers le réseau de télécommunications RT. Les flux de réseau RES sont par exemple mémorisés dans la base de données BD.

A l'étape El, le module de corrélation COR établit une corrélation entre les flux de réseau RES reçus par le dispositif DTD. Par exemple, le module de corrélation COR analyse les champs des flux de réseau RES et classent dans un premier temps les flux de réseau RES par type de protocole de transmission TYP. Pour chaque type de protocole TYP, un premier flux de réseau est associé à un deuxième flux de réseau pour former une paire de flux lorsque les adresses de source AS et de destination AD et les ports de source PS et de destination PD du premier flux sont respectivement les adresses de destination et de source et les ports de destination et de source du deuxième flux. Une paire de flux est ainsi relative à une communication entre deux dispositifs du réseau selon un protocole de transport. Pour chaque paire de flux, la date de début DATD de la transmission d'un paquet donnant naissance au premier flux de réseau est comparée à celle du deuxième flux de réseau. Le module de corrélation COR détermine alors un flux de requête REQ qui reproduit le flux de réseau ayant la date de début de transmission DATD la plus ancienne et qui est complété par un indicateur de direction DIR. Un état logique "1" est attribué à l'indicateur de direction DIR du flux de requête REQ par le module de corrélation COR et signifie que le flux de requête REQ est à l'origine d'une communication bidirectionnelle entre les deux dispositifs du réseau relatifs à la paire de flux. Par ailleurs, tout flux de réseau non associé à un autre flux est reproduit dans un flux de requête REQ incluant un indicateur de direction DIR auquel le module de corrélation COR a attribué l'état logique "0". L'indicateur DIR à l'état "0" signifie que le flux de requête REQ est à l'origine d'une communication monodirectionnelle entre un dispositif du réseau identifié par 1' adresse de source AS du flux REQ et un autre dispositif du réseau identifié par l'adresse de destination AD du flux REQ. Par exemple, les champs d'une paire de flux de réseau sont représentés dans le tableau 1 suivant: TABLEAU 1 DATD DATF PS PD TYP 192.168.0.45 11574 11628 80 64143 6 (TCP) 192.168.0.194 192.168.0.194 11548 11632 64143 80 6 (TCP) 192.168.0.45 Les champs du premier flux et du deuxième flux de la paire de flux de réseau sont par exemple représentés respectivement à la première ligne et à la deuxième ligne du tableau 1. La comparaison des dates de début de transmission DATD, qui sont par exemple des estampilles temporelles calculées à partir d'une date universelle de référence, indique que le deuxième flux est le flux de requête REQ qui est à l'origine d'une communication bidirectionnelle entre le dispositif ayant l'adresse IP "192.168.0.194" égale à l'adresse de source AS du flux de requête REQ et le dispositif ayant l'adresse IP "192.168.0.45" égale à l'adresse de destination AD du flux de requête REQ.

A des étapes E21 à E25 composant l'étape E2, le module de construction de graphe MGO construit ou actualise au moins un graphe orienté GO en fonction des flux de requête REQ déterminés par le module de corrélation COR. Par exemple, un graphe orienté GO est construit ou actualisé dès qu'un flux de requête

REQ a été déterminé, ou à l'expiration d'une période prédéterminée. Le module MGO analyse les champs des flux de requête REQ afin d'identifier des couples composés d'un type de protocole TYP et d'un port de destination PD. Pour chaque couple identifié, un graphe orienté GO est à construire. Un graphe orienté comprend des noeuds qui sont les adresses IP de dispositifs du réseau et qui sont reliés entre eux par des arcs orientés. Un arc orienté relie un noeud source à un noeud cible du graphe et correspond à un flux de requête REQ dont l'adresse de source AS est représentée par le noeud source et l'adresse de destination AD est représentée par le noeud cible. L'arc orienté est alors orienté selon l'indicateur de direction DIR attribué au flux de requête REQ. L'arc orienté est également associé aux dates de début de transmission DATD et de fin de transmission DATF relatives au flux de requête REQ. A la figure 3 est représenté un exemple de graphe orienté GO comprenant des noeuds qui sont des adresses IP quelconques de dispositifs du réseau, pour un couple composé d'un type de protocole donné TYP et d'un port de destination donné PD. Les arcs orientés associés à des indicateurs de direction DIR à l'état "1", donc à des communications bidirectionnelles, sont représentés par des traits continus, et les arcs orientés associés à des indicateurs de direction DIR à l'état "0", donc à des communications monodirectionnelles, sont représentés par des traits discontinus. Dans le graphe orienté, une adresse IP peut être une adresse de source AS et/ou une adresse de destination AD.

Les graphes orientés GO sont par exemple construits informatiquement au moyen d'un langage de programmation orienté objet, comme le langage de programmation Java, C++ ou Perl, définissant des classes d'objets relatives aux graphes orientés et aux noeuds auxquels est associé un ensemble de propriétés et de méthodes, les noeuds et les arcs étant des représentations visuelles des flux de requête REQ.

A l'étape E21, pour chaque flux de requête REQ, le module de construction de graphe MGO analyse les champs du flux de requête REQ afin d'identifier le couple composé du type de protocole TYP et du port de destination PD relatif au flux de requête REQ, et vérifie si un graphe orienté GO existe pour le couple identifié. Si le graphe orienté GO n'existe pas, le module MGO le crée en instanciant un objet d'une classe relative au graphe orienté GO.

A l'étape E22, le module MGO recherche dans le graphe orienté existant GO un noeud représentant l'adresse de source AS du flux de requête REQ et un noeud représentant l'adresse de destination AD du flux de requête REQ. Si au moins l'un des noeuds n'existe pas, le module MGO le crée en instanciant un objet d'une classe relative au noeud. A l'étape E23, le module MGO vérifie dans le graphe orienté GO si les noeuds représentant l'adresse de source AS et l'adresse de destination AD relatives au flux de requête REQ sont reliés par un arc orienté. Si l'arc orienté n'existe pas, le module MGO le crée par l'intermédiaire de méthodes de dépendance entre les objets de noeuds relatifs aux adresses de source AS et de destination AD.

A l'étape E24, le module MGO associe à l'arc orienté les dates de début de transmission DATD et de fin de transmission DATF relatives au flux de requête REQ. Si à l'étape E23 l'arc orienté existe déjà, le module MGO actualise périodiquement au moins la date de fin de transmission DATF à l'étape E24. Par exemple, si deux dispositifs identifiés respectivement par les adresses de source AS et de destination AD sont en cours de communication, seule la date de fin de transmission DATF est actualisée. A l'étape E25, le module MGO associe également à l'arc orienté l'indicateur de direction DIR attribué au flux de requête REQ. Si à l'étape E23 l'arc orienté existe déjà, le module MGO actualise l'indicateur de direction DIR précédemment associé à l'arc orienté. L'état de l'indicateur de direction DIR est par exemple actualisé si un dispositif identifié par l'adresse de destination AD du flux de requête ne transmet plus de paquets en réponse à un autre dispositif identifié par l'adresse de source AS. A l'issue de l'étape E25, le graphe orienté GO construit ou actualisé est mémorisé dans la base de données BD.

Par exemple, lorsqu'un nouveau couple composé du type de protocole TYP et du port de destination PD relatif à un flux de requête REQ est identifié, le module MGO construit un nouveau graphe orienté GO comprenant seulement deux noeuds et un arc orienté représentant le flux de requête REQ. Selon un autre exemple, des premier et deuxième dispositifs ont communiqué avec au moins un troisième dispositif selon un même type de protocole TYP et vers un même port de destination PD. Par conséquent, deux flux de requête ont été déterminés et un graphe

orienté a été créé comprenant un premier noeud représentant l'adresse IP du premier dispositif et un deuxième noeud représentant l'adresse IP du deuxième dispositif. Puis les premier et deuxième dispositifs communiquent entre eux des paquets selon le type de protocole TYP et vers le port de destination PD et donc incluant des champs identifiant le type de protocole et le port de destination précédents, ce qui conduit à la construction d'un arc orienté pour relier les premier et deuxième noeuds, à l'issue de l'étape E2.

A l'étape E3, le module de construction de graphe MGO analyse les dates de fin de transmission DATF relatives aux flux de requêtes REQ et associées aux arcs orientés des graphes GO de manière périodique afin de supprimer des arcs relatifs à des flux de requête anciens. Un délai d'inactivité DIA est préalablement défini et mémorisé par exemple dans la base de données BD. Pour chaque arc orienté, le module MGO compare le délai d'inactivité DIA à la différence entre une date d'exécution EXE et la date de fin de transmission DATF associée à l'arc orienté. La date d'exécution EXE est une date courante du dispositif de traitement de données DTD au même format que la date de fin de transmission DATF. Lorsque la différence entre la date d'exécution EXE et la date de fin de transmission DATF relative à l'arc orienté est supérieure au délai d'inactivité DIA, l'arc orienté est supprimé du graphe orienté GO auquel il appartient. Par conséquent, le module MGO actualise régulièrement les graphes orientés par la suppression d'arcs orientés relatifs à des flux de requête qui ont été capturés à une date suffisamment ancienne pour ne plus être considérés comme

pertinents dans la détection d'incidents de sécurité, les dispositifs relatifs aux flux de requête correspondant aux arcs orientés supprimés ne communiquant alors plus entre eux.

A l'étape E4, le module de détermination de composantes connexes MCC analyse tous les graphes orientés GO construits ou actualisés. Dans chaque graphe orienté GO, le module MCC identifie au moins une composante connexe CC comprenant une adresse racine AR qui est une adresse de source ou une adresse de destination et des adresses de destination AD reliées chacune à l'adresse racine AR par un ensemble d'arcs orientés.

Dans un premier temps, le module MCC identifie une adresse racine AR, correspondant à un noeud dit racine, d'une composante connexe dans un graphe orienté selon les deux cas suivants. Dans un premier cas, l'adresse racine AR est une adresse IP qui est seulement une adresse de source AS, et non une adresse de destination AD, le noeud représentant l'adresse IP n'étant pas un noeud cible et n'ayant pas d'antécédent. Dans un deuxième cas, l'adresse racine AR est une adresse IP qui est à la fois une adresse de source AS et une adresse de destination AD. Dans ce cas, le flux de requête associé à l'adresse de source AS, c'est-à-dire relatif à des paquets en provenance de l'adresse racine AR, est indépendant du flux de requête associé à l'adresse de destination AD, c'est-à-dire relatif à des paquets à destination de l'adresse racine AR. De manière générale, si la plus récente des dates de fin de transmission DATF relatives à des flux de requête en provenance d'une adresse IP est antérieure à la plus ancienne des

dates de début de transmission DATD des flux de requête à destination de l'adresse IP, alors l'adresse IP est une adresse racine d'une composante connexe.

Dans un deuxième temps, le module MCC détermine les noeuds cibles reliés directement et indirectement par des arcs orientés au noeud racine de la composante connexe. La composante connexe CC comprend alors le noeudracine et les noeuds cibles déterminés, c'est-à- dire l'adresse racine AR et les adresses de destination AD reliées chacune à l'adresse racine AR par un ensemble d'arcs. A la figure 4 est illustré un exemple de graphe orienté GO comprenant cinq noeuds appelés A, B, C, D et E, reliés par quatre arcs orientés correspondant à quatre flux de requête. Les noeuds A et B sont des adresses de source AS, les noeuds C et D sont à la fois des adresses de source AS et de destination AD, et le noeud E est une adresse de destination AD.

Chaque arc orienté est annoté d'un intervalle [x ; y] où x est une date de début de transmission DATD et y est une date de fin de transmission DATF. Les flux de requête à destination du noeud C ont des dates de début DATD égales à "5" et "6" alors que le flux de requête en provenance du noeud C vers le noeud D a une date de fin DATF égale à "4" antérieure aux dates "5" et "6". Par conséquent, les flux de requête provenant des noeuds A et B ne peuvent être à l'origine du flux de requête du noeud C vers le noeud D, et le noeud C est considéré comme une adresse racine AR d'une composante connexe CC comprenant les noeuds C, D et E.

A l'étape E5, le module d'indicateur d'incidents MII détermine des indicateurs d'incident en fonction

des adresses de destination AD de chaque composante connexe identifiée CC. Par exemple, cinq types d'indicateurs d'incidents INC1, INC2, INC3, INC4, INC5 sont déterminés pour une composante connexe identifiée CC selon des étapes E51 à E55. A l'étape E51, un premier indicateur d'incident INC1 est déterminé en fonction du nombre de noeuds, en particulier du nombre des adresses de destination AD appartenant à la composante connexe CC. Le premier indicateur d'incident INC1 est par exemple égal au nombre d'adresses de destination AD de la composante connexe CC, l'adresse racine AR n'étant pas prise en compte.

A l'étape E52, un deuxième indicateur d'incident INC2 est déterminé en fonction de la profondeur de la composante connexe CC. La profondeur de la composante connexe CC correspond alors au plus long des chemins entre le noeud racine et les autres noeuds de la composante connexe. En d'autres termes, la profondeur de la composante connexe CC est le nombre maximal d'arcs orientés reliant l'adresse racine à l'une quelconque des adresses de destination AD appartenant à la composante connexe.

Selon l'exemple du graphe orienté illustré à la figure 3, les adresses de source AS identifiées par "10.240.10.01" et "10.240.10.02 sont respectivement des adresses racines AR de composantes connexes ayant les mêmes adresses de destination. Tous les noeuds appartenant à la composante connexe CC ayant l'adresse racine AR identifiée par "10.240.10.01" sont représentés par des ellipses pleines grisées sur la figure 3.

Le nombre d'adresses de destination AD de la composante connexe CC, et par conséquent le premier indicateur d'incident INC1, sont égaux à 8. La profondeur de la composante connexe CC, et par conséquent le deuxième indicateur d'incident INC2, sont égaux à 4. En effet, le nombre maximal d'arcs pour relier l'adresse racine "10.240.10.01" à l'adresse de destination "10.240.14.01", ou encore l'adresse de destination "10.240.14.02", est égal à 4. A l'étape E53, un troisième indicateur d'incident INC3 est déterminé en fonction de l'accroissement du nombre de noeuds, c'est-à-dire du nombre d'adresses de destination AD, de la composante connexe CC au cours du temps. Le troisième indicateur d'incident INC3 est par exemple égal à l'approximation d'une pente d'une courbe représentant le nombre de noeuds de la composante connexe CC en fonction du temps. Une pente de la courbe est par exemple la pente de la corde entre deux points de la courbe respectivement associés à deux bornes d'un intervalle de temps prédéfini. A l'étape E54, un quatrième indicateur d'incident INC4 est déterminé en fonction de l'accroissement de la profondeur de la composante connexe CC au cours du temps. Le quatrième indicateur d'incident INC4 est par exemple égal à l'approximation d'une pente d'une courbe représentant la profondeur de la composante connexe CC en fonction du temps. De même, une pente de la courbe est par exemple la pente de la corde entre deux points de la courbe respectivement associés à deux bornes d'un intervalle de temps prédéfini. A l'étape E55, un cinquième indicateur d'incident INC5 est déterminé en fonction du nombre

d'adresses de destination AD associées respectivement à des flux de requête auxquels est attribué un indicateur de direction à l'état "0" dans la composante connexe CC. Le cinquième indicateur d'incident INC5 est par exemple égal au rapport du nombre d'arcs associés à des indicateurs de direction DIR à l'état "0" sur le nombre d'arcs associés à des indicateurs de direction DIR à l'état "1". Pour la composante connexe CC montrée à la figure 3, le cinquième indicateur d'incident INC5 est égal à 3/8.

A l'étape E6, le module d'indicateur d'incidents MII compare au moins l'un des indicateurs d'incident INC1, INC2, INC3, INC4, INC5 à un seuil choisi respectif SPI, SP2, SP3, SP4, SP5, qui peut être soit un seuil prédéterminé, soit un seuil déterminé dynamiquement au moyen d'un algorithme adéquat. A l'étape E7, le module d'indicateur d'incidents MII signale par une alarme un incident de sécurité si l'indicateur d'incident INC1, INC2, INC3, INC4, INC5 est supérieur au seuil choisi respectif SPI, SP2, SP3, SP4, SP5. Le premier indicateur d'incident INC1 peut être révélateur d'une activité illégitime telle qu'un scan de réseau effectué par un ver cherchant à se propager dans le réseau. Un scan d'un réseau consiste à balayer des plages d'adresses ou de ports dans le réseau afin de découvrir la topologie du réseau et les services applicatifs activés sur des dispositifs du réseau. Par exemple, un ver qui cherche à infecter des dispositifs du réseau effectue au préalable un scan du réseau qui engendre la création de nombreux arcs orientés entre une adresse racine d'une composante connexe, qui correspond à un dispositif "infecté", et des adresses de destination de la

composante connexe, qui correspondent à des dispositifs "scannés" par le ver. Par exemple, un scan de réseau est susceptible d'être à l'origine d'un nombre d'adresses de destination d'une composante connexe supérieur à 100. Le deuxième indicateur d'incident INC2 peut être révélateur d'une activité illégitime telle qu'une propagation d'un ver dans le réseau. En effet, un ver exploite généralement une faille de sécurité d'un dispositif vulnérable sur un service donné qui est identifié par un couple composé d'un type de protocole et d'un port de destination. Lorsqu'un dispositif vulnérable est identifié par le ver, ce dernier "infecte" le dispositif et se propage depuis le dispositif infecté vers un autre dispositif vulnérable. La propagation d'un ver dans le réseau est donc susceptible d'être à l'origine d'une composante connexe de grande profondeur. Le troisième indicateur d'incident INC3 peut être révélateur d'une activité illégitime telle qu'une propagation élargie et soutenue d'un ver dans le réseau au cours du temps. En effet, l'accroissement du nombre d'adresses de destination d'une composante connexe peut être le fruit d'une activité illégitime d'un ou plusieurs dispositifs infectés par un ver dans le réseau qui exploitent des vulnérabilités sur un grand nombre de dispositifs. Une propagation rapide du ver nécessite un scan élargi du réseau pour infecter un grand nombre de dispositifs qui infectent chacun un grand nombre de dispositifs. Dans ce cas, une courbe représentant le nombre de noeuds de la composante connexe CC en fonction du temps a une forte pente. Le quatrième indicateur d'incident INC4 peut être révélateur d'une activité illégitime telle

qu'une infiltration progressive d'un ver dans le réseau au cours du temps. Un ver qui effectue un scan lent du réseau peut infecter quelques dispositifs qui infectent chacun d'autres dispositifs en petit nombre également au moyen d'un scan lent. Dans ce cas, une courbe représentant la profondeur de la composante connexe CC en fonction du temps peut avoir une pente sensiblement constante au cours du temps. Ainsi, un ver peut infiltrer le réseau sans infecter un grand nombre de dispositifs, l'accroissement du nombre d'adresses de destination de la composante connexe étant faible. Le cinquième indicateur d'incident INC5 est typiquement révélateur d'une activité illégitime telle qu'un scan de réseau effectué par un ver cherchant à se propager dans le réseau. Le cinquième indicateur d'incident INC5 représente un taux de non-réponse relatif à une composante connexe, ou en d'autres termes un taux d'adresses de destination ne donnant aucune réponse à des transmissions de paquets en provenance d'une adresse de source. Ainsi, un taux élevé de non-réponses peut être le résultat soit de dispositifs effectuant des scans "aveugles", émettant ainsi un grand nombre de requêtes vers des dispositifs qui n'existent pas, soit de requêtes de dispositifs filtrés par des pare-feu du réseau.

En variante, un incident est détecté en fonction d'au moins deux des cinq indicateurs d'incident INC1 à INC5. Par exemple, l'incident est détecté lorsque les premier et cinquième indicateurs d'incident INC1 et INC5 sont respectivement supérieurs aux seuils choisis SPI et SP5. Le premier indicateur INC1, excédant le seuil SPI, est révélateur d'une activité illégitime telle qu'un scan de réseau. Si le

cinquième indicateur d'incident INC5, typiquement révélateur d'un scan de réseau, excède également le seuil SP5, un scan de réseau est détecté sans ambiguïté.

Tout type d'incident peut être détecté au moyen des indicateurs d'incident INC1, INC2, INC3, INC4 et INC5. Par conséquent, lorsque l'incident est détecté, le dispositif de traitement de données DTD peut déclencher automatiquement des procédures de sécurité adéquates pour traiter l'incident détecté.

L'invention décrite ici concerne un procédé et un dispositif pour détecter un incident de sécurité dans un réseau de télécommunications. Selon une mise en oeuvre, les étapes du procédé de l'invention sont déterminées par les instructions d'un programme d'ordinateur incorporé dans le dispositif tel que le dispositif de traitement de données DTD. Le programme comporte des instructions de programme qui, lorsque ledit programme est exécuté dans un processeur du dispositif dont le fonctionnement est alors commandé par l'exécution du programme, réalisent les étapes du procédé selon l'invention. En conséquence, l'invention s'applique également à un programme d'ordinateur, notamment un programme d'ordinateur enregistré sur ou dans un support d'informations lisible par un ordinateur et tout dispositif de traitements de données, adapté à mettre en oeuvre l'invention. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable pour implémenter le procédé selon l'invention.

Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage ou support d'enregistrement sur lequel est enregistré le programme d'ordinateur selon l'invention, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore une clé USB, ou un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque dur.

D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé selon l'invention.

Claims (12)

REVENDICATIONS

1 - Procédé pour détecter un incident de sécurité dans un réseau de télécommunications (RI), comprenant une détermination (E0, El) de flux de requête (REQ) qui sont à l'origine de communications dans le réseau, chaque flux de requête incluant une adresse de source (AS) et une adresse de destination (AD) de dispositifs de réseau entre lesquels sont transmis des paquets dans le réseau, caractérisé en ce qu'il comprend les étapes de : construire (E2) au moins un graphe orienté (GO) comprenant des arcs orientés reliant chacun une adresse de source (AS) à une adresse de destination (AD) d'un flux de requête déterminé (REQ), identifier (E4) dans le graphe orienté (GO) au moins une composante connexe (CC) comprenant une adresse racine (AR) et des adresses de destination (AD) reliées chacune à l'adresse racine (AR) par un ensemble d'arcs orientés, déterminer (E5) au moins un indicateur d'incident en fonction des adresses de destination (AD) de la composante connexe identifiée (CC), et signaler (E7) l'incident de sécurité si l'indicateur d'incident est supérieur à un seuil choisi.

2 - Procédé conforme à la revendication 1, selon lequel un graphe orienté (GO) est construit en fonction de flux de requête incluant un type de protocole de transport respectif (TYP) et un port de destination respectif (PD) et relatifs à des paquets transmis selon ledit protocole de transport respectif et vers ledit port de destination (PD).35

3 - Procédé conforme à la revendication 1 ou 2, selon lequel chaque flux de requête (REQ) inclut une date de début de transmission (DATD) et une date de fin de transmission (DATF) relatives aux paquets transmis entre les dispositifs de réseau dont les adresse de source et de destination sont incluses dans le flux de requête, et chaque arc orienté est associé à la date de début de transmission (DATD) et à la date de fin de transmission (DATF) de l'un des flux de requête (REQ).

4 - Procédé conforme à la revendication 3, comprenant une suppression (E3) d'un arc orienté lorsque la différence entre une date courante et la date de fin de transmission (DATF) associée à l'arc orienté est supérieure à un délai d'inactivité (DIA) prédéterminé.

5 - Procédé conforme à l'une quelconque des revendications 1 à 4, selon lequel l'indicateur d'incident (INC1) est déterminé en fonction du nombre des adresses de destination de la composante connexe (CC).

6 - Procédé conforme à l'une quelconque des revendications 1 à 5, selon lequel l'indicateur d'incident (INC2) est déterminé en fonction d'un nombre maximal d'arcs orientés reliant l'adresse racine (AR) à l'une quelconque des adresses de destination (AD) de la composante connexe (CC).

7 - Procédé conforme à l'une quelconque des revendications 1 à 6, selon lequel l'indicateur d'incident (INC3) est déterminé en fonction de l'accroissement du nombre d'adresses de destination (AD) de la composante connexe (CC) au cours du temps.

8 - Procédé conforme à l'une quelconque des revendications 1 à 7, selon lequel l'indicateur d'incident (INC4) est déterminé en fonction de l'accroissement d'un nombre maximal d'arcs orientés reliant l'adresse racine (AR) à l'une quelconque des adresses de destination (AD) de la composante connexe (CC).

9 - Procédé conforme à l'une quelconque des revendications 1 à 8, selon lequel l'indicateur d'incident (INC5) est déterminé en fonction du nombre d'adresses de destination (AD) dans la composante connexe (CC) associées respectivement à des flux de requête à l'origine de communications monodirectionnelles entre des dispositifs de réseau dont les adresses de source (AS) et les adresses de destination (AD) sont respectivement reliées par des arcs orientés.

10 - Dispositif pour détecter un incident de sécurité dans un réseau de télécommunications (RI), comprenant un moyen (COR) pour déterminer des flux de requête (REQ) qui sont à l'origine de communications dans le réseau, chaque flux de requête incluant une adresse de source (AS) et une adresse de destination (AD) de dispositifs de réseau entre lesquels sont transmis des paquets dans le réseau, caractérisé en ce qu'il comprend : -un moyen (MGO) pour construire au moins un graphe orienté (GO) comprenant des arcs orientés reliant chacun une adresse de source (AS) à une adresse de destination (AD) d'un flux de requête déterminé (REQ), - un moyen (MCC) pour identifier dans le graphe orienté (GO) au moins une composante connexe (CC) comprenant une adresse racine (AR) et des adresses de destination (AD) reliées chacune à l'adresse racine (AR) par un ensemble d'arcs orientés, - un moyen (MII) pour déterminer au moins un indicateur d'incident en fonction des adresses de destination (AD) de la composante connexe identifiée (CC), et - un moyen (MII) pour signaler l'incident de sécurité si l'indicateur d'incident est supérieur à un seuil choisi.

11 - Programme d'ordinateur apte à être mis en oeuvre dans un dispositif (DTD) pour détecter un incident de sécurité dans un réseau de télécommunications (RT), ledit programme comprenant des instructions qui, lorsque le programme est chargé et exécuté dans ledit dispositif (DTD), réalisent une détermination (E0, El) de flux de requête (REQ) qui sont à l'origine de communications dans le réseau, chaque flux de requête incluant une adresse de source (AS) et une adresse de destination (AD) de dispositifs de réseau entre lesquels sont transmis des paquets dans le réseau, ledit programme étant caractérisé en ce que les instructions de programme réalisent les étapes de : construire (E2) au moins un graphe orienté (GO) comprenant des arcs orientés reliant chacun une adresse de source (AS) à une adresse de destination (AD) d'un flux de requête déterminé (REQ), identifier (E4) dans le graphe orienté (GO) au moins une composante connexe (CC) comprenant une adresse racine (AR) et des adresses de destination (AD) reliées chacune à l'adresse racine (AR) par un ensemble d'arcs orientés, déterminer (E5) au moins un indicateur d'incident en fonction des adresses de destination (AD) de la composante connexe identifiée (CC), et signaler (E7) l'incident de sécurité si l'indicateur d'incident est supérieur à un seuil choisi.

12 - Support d'enregistrement lisible par un dispositif de détection d'incident de sécurité (DTD) sur lequel est enregistré un programme d'ordinateur pour détecter un incident de sécurité dans un réseau de télécommunications (RT), ledit programme comportant des instructions pour une détermination (E0, El) de flux de requête (REQ) qui sont à l'origine de communications dans le réseau, chaque flux de requête incluant une adresse de source (AS) et une adresse de destination (AD) de dispositifs de réseau entre lesquels sont transmis des paquets dans le réseau, ledit programme comportant des instructions pour l'exécution des étapes suivantes : construire (E2) au moins un graphe orienté (GO) comprenant des arcs orientés reliant chacun une adresse de source (AS) à une adresse de destination (AD) d'un flux de requête déterminé (REQ), identifier (E4) dans le graphe orienté (GO) au moins une composante connexe (CC) comprenant une adresse racine (AR) et des adresses de destination (AD) reliées chacune à l'adresse racine (AR) par un ensemble d'arcs orientés, déterminer (E5) au moins un indicateur d'incident en fonction des adresses de destination (AD) de la composante connexe identifiée (CC), etsignaler (E7) l'incident de sécurité si l'indicateur d'incident est supérieur à un seuil choisi.