FR2917556A1 - Detection d'anomalie dans le trafic d'entites de service a travers un reseau de paquets - Google Patents

Detection d'anomalie dans le trafic d'entites de service a travers un reseau de paquets Download PDF

Info

Publication number
FR2917556A1
FR2917556A1 FR0755800A FR0755800A FR2917556A1 FR 2917556 A1 FR2917556 A1 FR 2917556A1 FR 0755800 A FR0755800 A FR 0755800A FR 0755800 A FR0755800 A FR 0755800A FR 2917556 A1 FR2917556 A1 FR 2917556A1
Authority
FR
France
Prior art keywords
entity
packet
rule
intercepted
type
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.)
Pending
Application number
FR0755800A
Other languages
English (en)
Inventor
Patrick Battistello
Stephane Tuffin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Priority to FR0755800A priority Critical patent/FR2917556A1/fr
Priority to PCT/FR2008/051067 priority patent/WO2009004234A1/fr
Publication of FR2917556A1 publication Critical patent/FR2917556A1/fr
Pending legal-status Critical Current

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

Abstract

Pour détecter des anomalies dans le trafic émis par une entité (EC; ES) vers une autre entité, un dispositif (DD) intercepte un paquet du trafic (PAQ) émis par l'entité et détermine un contexte de l'entité en fonction du paquet intercepté. Un module d'analyse de conformité (AC) sélectionne au moins l'une de premières règles (RAC) en fonction du contexte de l'entité, contenant par exemple un type de l'entité, et de ressources disponibles du dispositif ayant intercepté ledit paquet. Le module d'analyse décide la conformité du paquet intercepté à la première règle sélectionnée, la conformité du paquet intercepté étant indéterminée si la première règle sélectionnée est inapplicable au paquet intercepté. Le module d'analyse détecte une anomalie si le paquet intercepté n'est pas conforme à la première règle sélectionnée.

Description

Détection d'anomalie dans le trafic d'entités de service à travers un
réseau de paquets
La présente invention concerne la sécurité dans un réseau de paquets basée sur des analyses de paquets transmis dans le réseau. Plus particulièrement, elle a trait à une détection d'anomalies ou d'incidents de sécurité dans le trafic supporté par une liaison de transmission et relatif à au moins une entité de service dans le réseau de paquets.
Un réseau de paquets, comme l'internet, transmet des paquets entre différentes entités de service, via une infrastructure commune. Une entité de service connectée à un tel réseau répond à des requêtes d'entités clientes, telles que des terminaux de clients, en leur fournissant un service, c'est-à-dire en effectuant des actions bien définies et demandées par les clients. Des entités de service sont par exemple un serveur web, un serveur de contenus proposant un téléchargement de fichiers multimédias, un serveur de messagerie électronique, ou un serveur d'applications de voix sur IP VoIP ("Voice Over IP" en anglais). Les entités de service peuvent être confrontées à divers types de problèmes relatifs au trafic des paquets, tels que des attaques ou des anomalies qui dégradent la qualité du service offert par les entités de service.
Une anomalie peut être considérée comme une évaluation de trafic non conforme à un ensemble d'évaluations de trafic normal admissibles. L'ensemble des évaluations admissibles est déterminé a priori à l'aide de connaissances expertes et de
règles, définissant par exemple des caractéristiques que le trafic normal doit satisfaire. En particulier, des réseaux offrant un service de voix sur IP VoIP sont en pleine expansion. De tels réseaux sont amenés à remplacer à terme les réseaux de téléphonie classique et à supporter de nouvelles applications multimédia telles que la visioconférence, alors que des efforts limités sont entrepris pour la sécurité de ces applications. Or, avec l'augmentation du nombre de clients et d'interconnexions entre des réseaux de différents opérateurs, il est prévisible que les réseaux de voix sur IP soient soumis dans un futur proche à des actes malveillants tels que des usurpations d'identité, des envois de messages polluants, ou des tentatives de mise hors service des entités de service, par exemple dans un but de dégradation de l'image de marque. Dans l'état de la technique, il existe des équipements de protection de réseau, tels que des pare-feu ou des dispositifs de voix sur IP, qui bloquent ou rejettent du trafic anormal. Ces équipements n'établissent pas de cartographie des entités générant du trafic anormal, pour prévenir d'éventuelles attaques du réseau depuis de telles entités. Il est donc difficile de détecter des comportements anormaux du trafic avant que ces derniers ne soient dangereux pour le réseau, et que les paquets ne soient bloqués. Les équipements actuels sont davantage orientés sur le blocage de paquets non-conformes ou hostiles que sur une détection en amont des comportements anormaux. La finesse et la complexité des analyses effectuées par de tels équipements sont limitées à l'analyse portant sur des paquets du trafic en cours
de traitement et éventuellement sur le contexte applicatif associé au trafic. D'autres équipements de protection de réseau, tels que des sondes de détection d'intrusion IDS ("Intrusion Detection System" en anglais) ou des pots de miel, ne distinguent pas les traitements effectués en fonction du type de l'entité à l'origine du trafic. Par exemple, les "pots de miel" effectuent des traitements uniquement sur le trafic qu'ils attirent et n'analysent pas le trafic destiné à des entités de service. Par ailleurs, des équipements de protection traitant de grands volumes de trafic ont un niveau d'analyse limité qui ne permet pas de prendre en compte les spécificités du service voix sur IP. De tels équipements offrant un niveau d'analyse approfondi sont limités par des capacités de traitement et par les débits supportés.
Pour remédier aux inconvénients évoqués ci-dessus, un procédé selon l'invention pour détecter une anomalie dans le trafic émis par une entité, comprenant une récupération d'un contexte de l'entité en fonction d'un paquet intercepté dans le trafic, caractérisé en ce qu'il comprend : une sélection d'au moins l'une de premières règles prédéterminées en fonction du contexte de l'entité récupéré et de ressources disponibles d'un dispositif ayant intercepté ledit paquet, et une décision sur la conformité du paquet intercepté à ladite au moins une première règle sélectionnée, la conformité du paquet intercepté étant indéterminée si ladite au moins une première règle sélectionnée est inapplicable au paquet intercepté.
Une anomalie peut alors être détectée si le paquet intercepté n'est pas conforme à ladite au moins une première règle sélectionnée. L'invention détecte avantageusement près d'une entité à protéger, telle qu'une entité de service, des anomalies comportementales aussi bien dans le trafic dirigé vers cette entité que dans le trafic qui en provient, de manière à signaler très rapidement et précisément une attaque ou une anomalie dans le trafic analysé. L'invention détecte en outre des comportements malveillants avant qu'une éventuelle attaque ne survienne. En effet, toute attaque contre une entité de service est généralement précédée d'une phase d'investigation durant laquelle l'attaquant recherche les limites de sécurité de l'entité de service. Le procédé selon l'invention détecte ainsi des comportements malveillants intentionnels, résultant par exemple directement de l'action d'un attaquant à l'extérieur du réseau auquel est rattachée l'entité de service, ainsi que des comportements malveillants non intentionnels, résultant par exemple de l'action d'un terminal client infecté par un ver qui émet des paquets en grande quantité. De même, un terminal de client mal configuré non intentionnellement peut être détecté, idéalement avant que le client n'appelle un centre d'assistance technique. Le procédé selon l'invention distingue des entités non fiables, telles que des entités clientes, d'entités fiables, telles que des entités de service, en sélectionnant des règles en fonction du contexte de l'entité, comprenant par exemple un type ou un sous-type de l'entité, et des ressources disponibles du dispositif afin de ne pas exposer ce dernier à des attaques par saturation de ressources. Cette
distinction permet d'analyser plus précisément des paquets émis par des entités considérées non fiables. Outre la détection d'anomalies et de comportements malveillants, le procédé selon l'invention permet à un dispositif de détection d'anomalie de réagir à l'anomalie détectée par exemple en mémorisant les anomalies, en levant une alarme ou en bloquant le trafic présentant une anomalie.
Par ailleurs, l'invention adapte l'analyse effectuée sur le paquet intercepté en fonction des ressources du dispositif par exemple en fonction d'un compromis entre un temps d'exécution nécessaire à l'application d'une règle sélectionnée au paquet intercepté, un risque relatif au paquet reçu dépendant d'anomalies déjà détectées pour l'entité et des ressources disponibles du dispositif de détection d'anomalie.
Selon une autre caractéristique de l'invention, si le type de l'entité n'est pas défini et si le paquet intercepté est conforme à ladite au moins une premiere regle sélectionnée, le procédé peut comprendre en outre une actualisation du contexte de l'entité en fonction du paquet intercepté et d'au moins un autre paquet intercepté dans le trafic émis par l'entité. La profondeur d'analyse est ainsi adaptée au type de l'entité et éventuellement à un historique d'analyse des paquets émis par l'entité. Selon une autre caractéristique de l'invention, si un type de l'entité est défini dans le contexte de l'entité, la sélection de ladite au moins une première règle peut dépendre d'un niveau de conformité de l'entité contenu dans le contexte de
l'entité, ledit niveau de conformité dépendant de la conformité d'au moins un autre paquet de l'entité intercepté préalablement audit paquet intercepté à au moins une autre première règle.
Les premières règles sont ainsi sélectionnées en fonction du type de l'entité et du niveau de conformité de cette dernière, afin d'analyser plus précisément des entités considérées non-conformes et peu fiables. Une fois que le type de l'entité est défini, l'invention applique des règles plus précises à des paquets émis ultérieurement par l'entité, afin de détecter éventuellement d'autres types d'anomalie. Selon une autre caractéristique de l'invention, le contexte de l'entité peut être actualisé en fonction de la conformité du paquet intercepté à ladite au moins une première règle sélectionnée. Le niveau de conformité de l'entité est actualisé après l'analyse de chaque paquet intercepté. Par conséquent, le contexte de l'entité est également actualisé, et les premières règles sélectionnées en fonction du contexte de l'entité peuvent être différentes pour chaque paquet intercepté.
Selon une autre caractéristique de l'invention, le procédé peut comprendre en outre, si le type de l'entité est défini et si le paquet intercepté n'est pas conforme à ladite au moins une première règle sélectionnée, une sélection d'au moins une deuxième règle en fonction du contexte de l'entité et de ladite au moins une première règle à laquelle n'est pas conforme le paquet intercepté et une détection d'une anomalie en fonction d'une conformité du paquet intercepté et d'au moins un autre paquet intercepté dans le trafic émis par l'entité à ladite au moins une deuxième règle sélectionnée.
Selon l'invention, d'autres anomalies, telles que des attaques réparties dans le temps, sont détectées ultérieurement à l'analyse du paquet reçu, en considérant un ensemble de paquets qui sont non conformes aux règles sélectionnées et émis par la même entité.
Selon une autre caractéristique de l'invention, le procédé peut comprendre en outre, si le type de l'entité est défini et si le paquet intercepté est conforme à ladite au moins une première règle sélectionnée, une extraction d'attributs du paquet intercepté et une mémorisation des attributs extraits dans le contexte de l'entité. De plus, le procédé peut comprendre en outre une actualisation d'attributs de type d'entité en fonction des attributs extraits mémorisés et d'autres attributs extraits de paquets interceptés émis par d'autres entités de même type que celui de ladite entité, et une détection d'anomalie si la valeur de l'un des attributs extraits est exclue d'un intervalle prédéterminé dépendant des attributs extraits. L'invention récupère des informations relatives au paquet qui est émis par une entité fiable pour enrichir une base de données comprenant des attributs relatifs au type de l'entité, de manière à déterminer ultérieurement plus précisément d'autres entités indéfinies. Selon l'invention, le dispositif de détection d'anomalie apprend ainsi des caractéristiques communes et utiles à la détection d'entités de même type.
Selon encore une autre caractéristique de l'invention, les premières règles sélectionnées
peuvent comprendre des règles critiques et des règles non-critiques, les règles critiques étant appliquées au paquet intercepté de manière prioritaire par rapport aux règles non-critiques, et la conformité du paquet intercepté peut être indéterminée si au moins une des règles critiques n'a pas pu être appliquée au paquet intercepté pendant un temps de traitement prédéterminé. Les règles critiques visent la détection d'anomalies ou d'attaques ayant un impact critique et immédiat sur le service contrôlé, et sont appliquées en priorité au paquet intercepté. Les règles non-critiques ont un impact moins fort ou moins immédiat et sont par exemple appliquées au paquet intercepté en fonction des ressources disponibles du dispositif. Par exemple, la dichotomie entre les règles critiques et non-critiques est réalisée par l'expert du domaine. Selon l'invention, le nombre de règles sélectionnées peut dépendre du niveau de conformité de l'entité. L'invention analyse les paquets interceptés d'une entité d'autant plus précisément que l'entité est considérée comme non conforme Par exemple, le nombre de règles sélectionnées est d'autant plus élevé que le niveau de conformité est faible, c'est-à-dire que l'entité n'est pas fiable.
L'invention concerne également un dispositif pour détecter une anomalie dans le trafic émis par une entité présentant un contexte récupéré en fonction d'un paquet intercepté dans le trafic, caractérisé en ce qu'il comprend : - un moyen pour sélectionner au moins l'une de premières règles prédéterminées en fonction du
contexte de l'entité récupéré et de ressources disponibles du dispositif, et - un moyen pour décider la conformité du paquet intercepté à ladite au moins une première règles sélectionnée, la conformité du paquet intercepté étant indéterminée si ladite au moins une première règle sélectionnée est inapplicable au paquet intercepté.
Selon une autre caractéristique de l'invention, le dispositif peut comprendre : - un moyen pour détecter une anomalie en fonction de la conformité du paquet intercepté à ladite au moins une première règle sélectionnée, - un moyen pour détecter une anomalie en fonction d'au moins une deuxième règle qui est sélectionnée en fonction du contexte de l'entité et d'au moins une première règle à laquelle n'est pas conforme le paquet intercepté, - un moyen pour détecter une anomalie si un type de l'entité contenu dans le contexte de l'entité est indéterminable, et - un moyen pour détecter une anomalie en fonction d'attributs extraits du paquet intercepté et d'autres attributs extraits de paquets interceptés émis par d'autres entités de même type que celui de ladite entité, si la valeur de l'un des attributs extraits est exclue d'un intervalle prédéterminé dépendant des attributs extraits.
Selon une autre caractéristique de l'invention, le dispositif peut est lié à une base de données comprenant le contexte de l'entité et les attributs extraits des paquets interceptés, et lié en outre à une autre base de données comprenant des attributs de type d'entité qui sont actualisés en fonction des
attributs extraits des paquets interceptés et qui servent à déterminer le type de l'entité.
Enfin, l'invention se rapporte à un programme d'ordinateur apte à être mis en oeuvre dans un processeur, comme celui dans un dispositif pour détecter des anomalies dans le trafic émis par une entité vers une autre entité, ledit programme comprenant des instructions qui, lorsque le programme est exécuté dans le processeur, réalisent les étapes conformes au procédé de l'invention.
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 : - les figures 1A et 1B sont des blocs-diagrammes schématiques d'un système selon respectivement des première et deuxième réalisations de l'invention ; - la figure 2 est un bloc-diagramme schématique d'un dispositif de détection d'anomalie selon l'invention ; et - la figure 3 est un bloc-diagramme schématique de bases de données relatives au dispositif de détection d'anomalie selon l'invention ; et - les figures 4 et 5 sont un algorithme d'un procédé de détection d'anomalie selon l'invention. 30 En référence aux figures 1A et 1B, un dispositif de détection d'anomalie DD selon l'invention est par exemple inclus dans une sonde et fait office d'agent essentiellement logiciel pour protéger des entités de 35 service ES reliées entre elles via un réseau de
paquets RI interne à un réseau transmission par paquets plus global comme l'internet. Par exemple, les entités de service sont des serveurs web reliés entre eux par l'intermédiaire d'un ou plusieurs routeurs. Le réseau de paquets interne RI est par exemple un réseau informatique, tel qu'un intranet d'une entreprise ou une partie de l'internet, géré par un opérateur selon le protocole IP ("Internet Protocol" en anglais). Le réseau de paquets interne RI offre un ou plusieurs services, tel que la voix sur IP, supportant chacun un ou plusieurs protocoles, tel que le protocole d'initiation de session SIP ("Session Initiation Protocol" en anglais) pour le service de voix sur IP, ou des protocoles privés tels que le protocole IPX ("Inter-network Packet eXchanqe" en anglais). Des paquets sont transmis aux entités de service ES via une liaison de transmission LT depuis des entités clientes EC reliées entre elles via un réseau de paquets RE externe au réseau de paquets interne RI regroupant les entités de service dans l'internet. Les entités clientes sont par exemples des terminaux d'usager ou des serveurs. La liaison de transmission LT est située à proximité des entités de service ES dont le trafic est à surveiller par le dispositif de détection DD afin que ce dernier détecte des anomalies dans le trafic qui caractérisent par exemple des comportements anormaux ou malveillants des entités clientes, tels que des attaques par inondation des entités de service. Par exemple, la liaison de transmission LT à laquelle le dispositif de détection DD est connecté en écoute selon la figure 1A ou en coupure selon la figure 1B, est située au point d'entrée d'une ou
plusieurs entités de service ES, entre le réseau externe RE et le réseau interne RI, par exemple entre un routeur en bordure réseau externe RE et un routeur du réseau interne RI relié à une ou plusieurs entités de service ES. Selon une première réalisation de l'invention en référence à la figure 1A, le dispositif de détection DD est placé en écoute ou en dérivation et a pour fonction principale de détecter du trafic suspect.
Par exemple, le dispositif DD enregistre des caractéristiques du trafic suspect, déclenche des alarmes selon des caractéristiques du trafic suspect et optionnellement commande des équipements de protection aptes à bloquer du trafic suspect, tel qu'un pare-feu connecté en bordure du réseau de paquets interne RI. Le dispositif DD signale une alerte à partir de l'observation du trafic relatif à des entités de service dans la liaison LT afin que l'opérateur prenne des mesures adéquates pour contrer une éventuelle attaque dirigée vers les entités de service.
Selon une deuxième réalisation de l'invention en référence à la figure 1B, le dispositif de détection DD est placé en coupure et a pour fonction principale de détecter et bloquer du trafic suspect. Le dispositif DD placé en coupure a, outre les mêmes fonctionnalités que le dispositif DD placé en écoute, la fonctionnalité de bloquer directement le trafic suspect. Dans tous les cas, le dispositif de détection DD analyse la conformité du trafic de manière bidirectionnelle, c'est-à-dire à la fois le trafic émis par les entités clientes EC potentiellement malveillantes vers les entités de service ES à
protéger et le trafic émis par les entités de service ES à protéger vers les entités clientes EC potentiellement malveillantes. En variante, le dispositif de détection DD analyse seulement la conformité du trafic émis par les entités clientes EC vers les entités de service ES, le trafic émis par les entités de service ES étant considéré comme non malveillant.
En référence à la figure 2, le dispositif de détection DD peut être sous la forme d'un ordinateur ou d'une station de travail, ou d'un système informatique local ou réparti. Le dispositif DD reçoit des paquets PAQ transmis via la ligne de transmission LT. Optionnellement, les paquets reçus sont préalablement filtrés par une entité en amont, indépendante du procédé, par exemple une entité de type pare-feu. Ce filtrage en amont porte par exemple sur des adresses IP et sur des protocoles de transmission, afin de ne pas surcharger le dispositif DD. En relation avec l'invention, le dispositif de détection DD comprend un système de traitement de bas niveau TBN, opérant idéalement à la vitesse de la liaison de transmission LT, incluant un module de décodage DEC, un module de filtrage FIL et un module de récupération de type d'entité REC. Le module de décodage DEC extrait de chaque paquet reçu PAQ certains éléments d'information utiles au procédé. Ces éléments sont prédéterminés en fonction des protocoles supervisés et optionnellement, pour un protocole donné, du type de paquet reçu. Le module de filtrage FIL filtre des paquets PAQ, en fonction de règles de filtrage s'appliquant
aux éléments d'information extraits par le module de décodage DEC. Le module de récupération de type d'entité REC récupère en fonction des éléments d'information extraits de chaque paquet reçu par le module de décodage DEC les types des entités émettrice et destinatrice du paquet reçu au moyen d'une fonction de récupération de type d'entité fREC• Le module REC récupère le cas échéant des contextes associés aux entités déterminées, en particulier des informations sur le type d'entité, cette information de type étant structurée hiérarchiquement en un ou plusieurs sous-types. En sortie du module de récupération de type d'entité REC, les éléments d'information extraits par le module de décodage DEC, les éléments d'information récupérés par le module REC, et le paquet reçu, sont fournis à un module de temporisation TEM qui place ces éléments en file d'attente avant qu'ils ne soient traités par un système de traitement de haut niveau THN du dispositif de détection DD. Le système de traitement de haut niveau THN inclut un module d'analyse de conformité AC, un module de caractérisation du type d'entité CTE, un module de collecte d'informations de caractérisation du type d'entité COL et un module d'analyse de non-conformité ANC. Le module d'analyse de conformité AC détecte des comportements anormaux ou malveillants du trafic sur une échelle de temps court-terme, en analysant chaque paquet reçu PAQ au moyen d'une fonction d'analyse de conformité fAC. Par défaut, le module AC effectue une analyse de conformité seulement sur les paquets émis depuis le réseau externe RE vers le réseau interne RI, les paquets reçus du réseau interne RI étant
supposés non malveillants. De manière symétrique, l'analyse de conformité peut être effectuée également sur les paquets émis depuis le réseau interne RI vers le réseau externe RE. Des traitements relatifs à l'analyse de conformité sont basés notamment sur le type des entités qui sont la source ou la destination du paquet reçu PAQ. Le module de caractérisation du type d'entité CTE détermine, sur une échelle de temps moyen-terme, le type et/ou les sous-types d'une entité en provenance de laquelle a été reçu un ensemble de paquets PAQ au moyen d'une fonction de caractérisation fCTE. Le module CTE effectue une caractérisation d'entité qui s'applique aussi bien aux entités du réseau interne RI qu'à celles du réseau externe RE. Lorsqu'une nouvelle entité est rattachée au réseau interne RI ou au réseau externe RE, le module CTE détermine le type de cette nouvelle entité ou signale une anomalie dans le cas où la détermination échoue. Le module de collecte d'informations de caractérisation du type d'entité COL collecte des attributs de type d'entité ATT en fonction des informations contenues dans les paquets reçus PAQ au moyen d'une fonction de collecte fCOL. Le module COL effectue un premier niveau d'apprentissage sur les attributs collectés pour chaque type d'entité. Cet apprentissage s'applique à la fois aux entités du réseau interne RI qu'à celles du réseau externe RE.
L'apprentissage est effectué sur des paquets dits conformes pour lesquels l'analyse de conformité a donné un résultat positif. Le module d'analyse de non-conformité ANC analyse des paquets dits non-conformes pour lesquels l'analyse de conformité a donné un résultat négatif,
au moyen d'une fonction d'analyse de non-conformité fANC. Le module ANC effectue une analyse de non-conformité qui corrèle un ensemble de paquets non-conformes émis par une entité donnée afin d'en déduire un type de comportement non-conforme ou malveillant. Par rapport à l'analyse de conformité, qui fournit un résultat pour chaque paquet reçu, l'analyse de non-conformité traite un ensemble de paquets non-conformes pendant une période plus longue. Le dispositif DD comprend en outre une ou plusieurs unités de traitement UT qui sont définies chacune comme un ensemble de ressources matérielles du dispositif DD, telles qu'un processeur, une mémoire et un bus de communication, qui sont dédiées au traitement des paquets reçus. Les unités de traitement sont supposées indépendantes les unes des autres, c'est-à-dire que le traitement d'un paquet par une unité de traitement UT n'a pas d'influence sur les ressources dont disposent les autres unités de traitement. Par exemple, une unité de traitement est dédiée à l'exécution de la fonction fAC. Le nombre d'unités de traitement dépend de l'implémentation du dispositif DD et de plusieurs critères tels que l'architecture matérielle du dispositif comprenant un ou plusieurs processeurs, le débit maximal des paquets à traiter, le service considéré et un nombre de règles à appliquer par différentes fonctions de traitement.
Les modules du système THN coopèrent avec un système de traitements secondaires TS du dispositif de détection DD incluant un module de gestion des traitements GES, un module de corrélation COR et un
module d'apprentissage d'informations de caractérisation du type d'entité APP. Le module de gestion des traitements GES régule des temps de traitement relatifs à chacun des modules du dispositif de détection DD notamment en fonction des ressources de ce dernier. Le module de corrélation COR établit une corrélation entre des premiers paquets émis depuis le réseau externe RE vers le réseau interne RI, ou inversement, et des deuxièmes paquets émis depuis le réseau interne RI vers le réseau externe RE, ou inversement, en réponse aux premiers paquets, au moyen d'une fonction de corrélation fCOR. Cette corrélation est appliquée seulement aux paquets pour lesquels une réponse d'une entité du réseau interne ou externe est nécessaire à des traitements du dispositif DD. Le module de corrélation COR est sollicité indifféremment et indépendamment par le module d'analyse de conformité AC, le module de caractérisation du type d'entité CTE, et le module d'analyse de non-conformité ANC. La fonction de corrélation fCOR est exécutée de manière asynchrone par rapport aux autres fonctions de traitement des modules du dispositif DD.
Le module d'apprentissage d'informations de caractérisation du type d'entité APP coopère avec le module de collecte COL. Le module APP agrège des attributs ATT de type et de sous-type d'entité collectés par le module COL au moyen d'une fonction d'apprentissage fApp, dès lors qu'un nombre suffisant d'attributs est collecté pour un nombre suffisant d'entités. Le module APP fournit des attributs de caractérisation pour différents types et sous-types d'entités qui sont utilisés par le module de caractérisation du type d'entité CTE.
Les modules du dispositif de détection DD ont des temps impartis d'exécution et de fourniture de résultats, qui peuvent être de type court-terme, moyen-terme ou long-terme. Le module d'analyse de conformitéAC et le module de corrélation COR ont des temps de réponse de type court-terme, puisque le module AC fournit un résultat après l'analyse de chaque paquet reçu, et le module COR établit un lien entre des requêtes et des réponses qui sont généralement proches dans le temps. Le module de caractérisation du type d'entité CTE et le module d'analyse de non-conformité ANC ont des temps de réponse de type moyen-terme puisqu'ils requièrent un ensemble de paquets avant de fournir un résultat. Le module de collecte COL et le module d'apprentissage APP ont des temps de réponse de type long-terme puisqu'ils requièrent un grand nombre de paquets relatifs à un ensemble représentatif d'entités avant de pouvoir consolider des attributs de caractérisation. Les modules du système de traitement de haut niveau THN et du système de traitements secondaires TS exécutent des traitements dits de haut niveau.
Lorsque le dispositif DD est placé en coupure, ces traitements engendrent des délais de transfert des paquets reçus et traités. Afin que ces délais restent dans des limites acceptables pour ne pas dégrader la qualité du service, le dispositif DD adapte dynamiquement ces traitements de haut niveau au contexte dudit service en fonction notamment de l'origine du paquet, du type de l'entité, d'un niveau de conformité de l'entité et des ressources du dispositif DD. Par exemple, l'analyse de conformité
invoque un ensemble de règles qui dépend du type d'entité considérée pour chaque paquet traité. Afin d'optimiser l'utilisation des ressources du dispositif, des traitements sont exécutés en fonction d'un niveau d'analyse du paquet reçu et de l'entité associée qui n'est pas constant. Par exemple, un niveau de conformité de l'entité est utilisé pour adapter les traitements exécutés par la fonction d'analyse de conformité fAC, Plus les ressources du dispositif DD diminuent, plus ce dernier réduit la quantité de traitements exécutés par entité ou par paquet reçu. Cette adaptation dynamique des ressources du dispositif DD est faite en fonction de l'entité, en s'assurant que des règles de contrôle dites critiques soient appliquées pour chaque paquet traité quel que soit le niveau de conformité de l'entité. Une limitation de ressources en fonction de l'entité évite par exemple une situation où un comportement malveillant abusif d'une entité empêche l'application de règles de contrôles pour d'autres entités. Cette adaptation dynamique du dispositif DD évite une vérification systématique de mêmes règles pour toutes les entités et pour tous les paquets reçus, qui est très consommatrice de ressources et qui limite le degré d'analyse des paquets. Ainsi, une entité dont le comportement vérifie un gabarit prédéfini subira un minimum de contrôles, tandis qu'une entité dont le comportement est éloigné du gabarit prédéfini subira de plus en plus de contrôles au fur et à mesure que le niveau de conformité de l'entité diminue. Cette adaptation dynamique garantit au dispositif DD de faire des contrôles suffisamment fins sur des entités présentant un comportant suspect ou anormal, tout en économisant des ressources de
traitement grâce à des contrôles critiques basés sur un nombre minimal de règles appliquées sur les entités conformes au gabarit. Toutefois, quel que soit le niveau de conformité de l'entité, les contrôles critiques sont toujours réalisés en priorité pour la sécurité du réseau interne et d'autres contrôles plus fins sont conditionnels aux ressources du système, au type de l'entité et au niveau de conformité de cette dernière.
En référence à la figure 3, les informations manipulées par le dispositif de détection DD sont organisées et mémorisées dans un ensemble de différentes bases de données comprenant une base de caractérisation de type d'entité BCTE, une base d'identification d'entité BIE, une base de contexte d'entité BCE et une base de règles BR. Cette organisation est de nature logique et n'est pas limitée à une implémentation particulière.
Les bases de données BCTE, BIE, BCE et BR sont liées au dispositif de détection DD, c'est-à-dire elles sont soit intégrées dans le dispositif de détection DD, soit incorporées dans un ou plusieurs serveurs de gestion de base de données et reliées au dispositif de détection par une liaison locale ou distante. Les bases BCTE, BIE et BCE sont en lecture et en écriture, tandis que la base BR est seulement en lecture, par exemple pour des fonctions de traitement de traitement de haut niveau. La base de caractérisation de type d'entité BCTE contient des attributs ATT qui sont des informations descriptives sur différents types et sous-types d'entités des réseaux RI et RE définis dans le dispositif DD et qui permettent au module de
caractérisation CTE de déterminer le type et éventuellement un ou des sous-types d'une entité en fonction des paquets reçus de l'entité. Une entité est définie par un type, et éventuellement par un ou plusieurs sous-types de manière hiérarchique. Par défaut, un sous-type d'entité hérite de manière récursive des attributs du sous-type supérieur jusqu'au type d'entité racine. Par contre, un attribut du type d'entité peut être redéfini dans l'un quelconque des sous-types d'entité. Les attributs mémorisés dans la base BCTE sont lus par la fonction de caractérisation du type d'entité fCTE. Ces attributs peuvent être écrits de manière dynamique par la fonction d'apprentissage fApp du module APP, ou par un administrateur du dispositif DD au moyen d'un plan de gestion, en particulier lors de l'initialisation du dispositif DD pendant laquelle certains attributs sont configurés par défaut. La base d'identification d'entité BIE contient des informations ou clés primaires permettant à la fonction de récupération de type d'entité fREC du module REC de récupérer le type de chacune des entités émettrice et destinatrice en fonction de l'analyse de chaque paquet reçu. Les informations contenues dans la base BIE sont segmentées en deux parties. Une première partie de base comprend des informations d'index {IDX} incluant une clé primaire ou un ensemble de clés primaires identifiant une entité appartenant au réseau interne RI ou au réseau externe RE. Ces premières informations correspondent à un sous-ensemble des informations décodées par le module DEC. Une deuxième partie de base comprend des informations descriptives de chaque entité, c'est-à-dire un identificateur d'entité IE qui est unique, un type d'entité <TE>, éventuellement un ou des sous-
types d'entité associés <STE> et un niveau de conformité de l'entité <NCE>. En particulier l'identificateur d'entité IE pointe sur le contexte d'entité correspondant contenu dans la base BCE.
Lorsque la fonction de récupération de type d'entité fREC détecte une nouvelle entité émettrice dans l'un des réseaux RI et RE, cette fonction crée dans la base un nouvel identificateur d'entité auquel sont associées les informations d'index {IDX} correspondant. Par ailleurs, la fonction de caractérisation fCTE du module CTE actualise le type d'entité <TE> et éventuellement un ou des sous-types d'entité associés <STE> dès lors que la fonction fCTE a déterminé le type ou le sous-type d'une entité précédemment indéfinie. La base de contexte d'entité BCE contient, pour un identificateur d'entité IE donné, mémorisé dans la base d'identification d'entité BIE, un contexte d'entité {IE} associé à cet identificateur. Le contexte d'une entité désigne un ensemble d'informations propres à l'entité. Comme il existe une bijection entre l'identificateur d'entité IE et le contexte d'entité, la notation {IE} désignera par la suite indifféremment le contexte d'entité ou bien l'agrégation de l'identificateur d'entité et du contexte de l'entité. La base BCE contient, pour chaque entité, des informations de conformité, de caractérisation et d'historique. Les informations de conformité indiquent le comportement observé d'une entité par les fonctions fAC et fANC des modules AC et ANC qui lisent, écrivent ou modifient ces informations. Les informations de caractérisation décrivent des caractéristiques de l'entité, et sont initialement lues et modifiées par la fonction de caractérisation fCTE du module CTE, puis par la
fonction de collecte fCOL du module COL. Ces informations de caractérisation sont également lues par la fonction d'apprentissage fApp du module APP. Les informations d'historique agrègent sur le long terme différentes anomalies ou alarmes détectées par les fonctions fAC, fCTE, fANC ou fApp. La base de règles BR décrit de manière statique des règles d'analyse de conformité, des règles de caractérisation des types d'entité, des règles de collecte d'attributs de caractérisation, des règles d'analyse de non-conformité et des règles de corrélation. La base BR contient des modules de règles composés chacun d'un ensemble de règles appelées par une fonction de traitement particulière, telles que des règles d'analyse de conformité {RAC}, des règles de caractérisation du type d'entité {RCTE}, des règles de collecte d'attributs de caractérisation {RCOL}, des règles d'analyse de non-conformité {RANC} et des règles de corrélation {RCOR}. Chaque règle définit une action ou une vérification en fonction de paramètres d'entrée propres à la règle et retourne une ou plusieurs valeurs vers la fonction de traitement appelante, c'est-à-dire au module exécutant cette fonction appelante. Pour chaque combinaison possible de paramètres de sélection, propres à chacune des fonctions fAC, fCTE, fCOL et fANC, la base BR pointe respectivement sur l'ensemble {RAC}, {RCTE}, {RCOL} et {RANC} de regles à invoquer pour cette combinaison. L'ensemble des combinaisons possibles des paramètres d'entrée de ces fonctions est discret et borné. Les règles d'analyse de conformité sont invoquées par le module AC et consistent à vérifier qu'un paquet est conforme à un certain nombre de
règles de sécurité, en particulier les règles identifiées comme critiques relativement à l'application ou des protocoles supervisés. Chaque règle retourne un résultat du type "0K" si le paquet est conforme aux règles invoquées, "NOK" si le paquet est non-conforme aux règles invoquées, ou "IND" si le résultat est indéfini, c'est-à-dire si le module AC ne peut statuer sur la conformité du paquet. Ces règles d'analyse de conformité sont classées en deux catégories : les règles "critiques" et les règles "non-critiques". Les règles de caractérisation du type d'entité sont invoquées par le module CTE et évaluent une ressemblance entre une entité dont le type est indéfini et les différents types et sous-types d'entité définis dans le dispositif DD. Pour chaque paquet auquel elles sont appliquées, ces règles comparent certaines informations extraites du paquet aux attributs ATT définis dans la base de caractérisation de type d'entité BCTE et font évoluer des indicateurs de vraisemblance pour les différents types et sous-types d'entité possibles. Les règles de collecte d'attributs de caractérisation sont invoquées par le module COL et définissent des paramètres à ajouter ou modifier, en fonction des paquets reçus, parmi les attributs de caractérisation associés à l'entité et stockés dans son contexte {IE}. Les règles d'analyse de non-conformité sont invoquées par le module ANC et sont appliquées aux paquets détectés non-conformes par la fonction fAC. Ces règles visent à déterminer plus finement un type ou une logique d'attaque sur une période de temps moyen-terme.35
En référence aux figures 4 et 5, le procédé de détection d'anomalie selon l'invention comprend des étapes El à E11 exécutées dans le dispositif de détection DD.
On suppose que les entités de service ES du réseau RI ne sont pas malveillantes et le dispositif DD réalise une analyse de conformité seulement sur le trafic émis par les entités clientes EC du réseau RE vers les entités de service ES du réseau RI. Par symétrie, les étapes du procédé peuvent être exécutées de manière similaire pour une analyse du trafic émis par les entités de service ES vers les entités clientes EC. Le dispositif DD intercepte et reçoit des paquets PAQ transmis dans des messages via la ligne de transmission LT entre les réseaux RI et RE.
A l'étape El, le module de décodage DEC extrait un ensemble d'informations {IAD} à décoder pour chaque paquet reçu PAQ, généralement structurées sous forme de champs dans le paquet. Par exemple, le paquet reçu contient des champs d'information relatifs au protocole supporté par le routage, tel que le protocole IP, au protocole supporté par le transport, tel que le protocole UDP ("User Datagram Protocol" en anglais), et aux protocoles supportés par l'application relative au service offert par le réseau RI. Le module DEC traite tous les paquets reçus, de manière adaptée au débit supporté par la ligne de transmission, de sorte que le nombre d'informations à décoder est relativement faible. Selon les capacités du dispositif DD, les informations à décoder peuvent dépendre du type de paquet reçu, par exemple un paquet relatif à une requête ou une réponse. Si le
dispositif DD dispose de peu de capacités, les informations à décoder {IAD} ont avantage à être identiques quel que soit le type de paquet reçu. Dans le cas où le service contrôlé par le dispositif DD comporte plusieurs protocoles applicatifs ou de transport, une information extraite par le module DEC est le protocole associé au paquet reçu, appelé par la suite protocole de paquet <P> et pouvant désigner indifféremment un protocole applicatif ou de transport. Comme chaque protocole est généralement structuré en plusieurs types de messages, une autre information extraite par le module DEC est le type de message, pour un protocole donné, associé à chaque paquet reçu, appelé par la suite type de message reçu <TM>. De manière générale, d'autres informations extraites par le module de décodage sont définies en fonction du service contrôlé. Par exemple, l'ensemble d'informations extraites {IAD} comprend le protocole de paquet <P> et le type de message reçu <TM>. Si le décodage du paquet reçu échoue, un drapeau <NDEC> indique le niveau de décodage qui a pu être atteint parmi les valeurs ordonnées de manière croissante correspondant aux couches du modèle OSI (Open Systems Interconnection" en anglais): nul, réseau, transport ou application. Un niveau de décodage est considéré atteint si toutes les informations de l'ensemble {IAD} relatives à ce niveau ont pu être décodées. Par exemple, si l'ensemble {IAD} contient l'adresse IP de source et l'adresse IP de destination du paquet reçu, et que seule l'adresse IP de source a pu être décodée, alors le niveau de décodage réseau n'est pas atteint et le drapeau <NDEC> est positionné à la valeur "nul". Par conséquent, si un niveau de décodage n'a pu être
atteint, les niveaux suivants n'ont également pas pu être atteints. Par convention, un paquet décodé complètement par rapport à l'ensemble d'informations {IAD} est associé à un drapeau <NDEC> ayant une valeur "total", qui est équivalent au niveau "application". Le module DEC fournit un ensemble d'informations décodées {ID}, contenant par exemple toute information décodée autre que le protocole de paquet <P>, le type de message reçu <TM> et le drapeau <NDEC>. Les informations décodées contenues dans l'ensemble {ID} peuvent être la valeur d'un champ du paquet, le nombre d'occurrences d'un champ du paquet, ou la longueur d'un champ du paquet, ou bien toute combinaison de ces trois types d'informations précitées. Le module de décodage DEC fournit les informations {ID}, <P>, <TM> et <NDEC>, ainsi que le paquet reçu PAQ au module de filtrage FIL.
A l'étape optionnelle E2, le module de filtrage FIL reçoit les informations {ID}, <P>, <TM> et <NDEC>, ainsi que le paquet reçu et applique le cas échéant des règles de filtrage statiques et/ou dynamiques dont les critères de filtrage portent sur les informations {ID}, <P>, <TM> ou <NDEC>. Les règles de filtrage statiques sont configurées et activées via un plan de gestion supervisé par un administrateur, par exemple dans le cadre d'une procédure d'interception légale. Les règles de filtrage dynamiques sont configurées et activées par les fonctions de traitement haut niveau. Le module de filtrage FIL applique des règles de filtrage dont les critères de filtrage portent sur les informations {ID}, <P>, <TM> ou <NDEC> extraites
par le module de décodage DEC, et n'analyse pas l'ensemble du paquet reçu, de manière à optimiser l'utilisation des ressources du dispositif DD. En variante, le module FIL applique des règles de filtrage statiques à d'autres informations contenues dans le paquet reçu. Les règles de filtrage sont appliquées en fonction du drapeau <NDEC>. Si le paquet reçu n'a pas été entièrement décodé, c'est-à-dire que le drapeau <NDEC> est différent de "total", des règles de filtrage sont appliquées en fonction du niveau de décodage atteint. Par exemple, si le niveau atteint est "transport", seules des règles de filtrage relatives aux niveaux "réseau" et "transport" sont appliquées, tandis que les règles de filtrage relatives au niveau "application" ne sont pas appliquées. Une règle de filtrage dynamique, contrairement à une règle de filtrage statique, est associée à un contexte géré par une fonction de traitement haut niveau qui a créé la règle dynamique. Lorsque ce contexte disparaît, la règle dynamique associée est supprimée par le module FIL. Afin d'éviter des attaques par saturation de ressources, le module FIL peut refuser la création d'une nouvelle règle de filtrage dynamique dès lors qu'un seuil de nombre de règles est atteint. Par ailleurs, le module de filtrage peut supprimer une règle de filtrage dynamique qui a été inopérante pendant une durée prédéterminée, c'est-à-dire qu'aucun paquet reçu pendant la durée prédéterminée considérée n'a satisfait des critères d'utilisation de la règle de filtrage dynamique. Chaque règle de filtrage appliquée aux paquets reçus peut exécuter les actions suivantes :
- suppression d'un paquet reçu, par exemple lorsque le dispositif est en coupure pour éviter les attaques de type déni de service en provenance d'une source donnée; - comptage des paquets reçus, par exemple pour informer le module de gestion des traitements GES du volume de données en provenance d'une entité donnée; et - marquage d'un paquet reçu, par exemple pour appliquer à ce dernier une fonction de traitement spécifique telle que l'enregistrement de flux dans le cas d'une procédure d'interception légale. Le module FIL filtre ainsi les paquets reçus et fournit ceux qui n'ont pas été supprimés au module de récupération de type d'entité REC, avec les informations {ID}, <P>, <TM> et <NDEC>. Par souci de simplification dans la suite de la description, les informations <P>, <TM> et <NDEC> sont supposées incluses dans l'ensemble {ID}.
A l'étape E3, le module de récupération de type d'entité REC reçoit les informations {ID} et le paquet reçu correspondant et applique à ces derniers la fonction de récupération de type d'entité fREC afin de déterminer, pour chaque paquet reçu, l'entité émettrice et l'entité destinatrice du paquet reçu. La fonction de récupération de type d'entité fREC retourne les informations suivantes qui sont un type d'entité <TE>, un sous-type d'entité <STEm,TE>, avec 1 m M, et un ensemble {IE} d'un identificateur et d'un contexte associés à l'entité. Le type d'entité <TE> prend la valeur "inconnu" = "NC", ou "indéfini" = "IND" ou bien est l'un parmi plusieurs types prédéfinis par
l'administrateur du dispositif. Des types prédéfinis sont par exemple <TE> = "terminal mobile", "serveur", ou "terminal fixe". Le cas "inconnu" = "NC" ne peut s'appliquer qu'à une entité destinatrice.
Le sous-type d'entité <STEm,TE> caractérise plus précisément une entité d'un type donné <TE>. Par exemple, si <TE> = "terminal mobile", deux premiers sous-types peuvent être <STE1,TE> = "mobile GSM" et <STE2,TE> = "mobile UMTS". Par ailleurs, pour le sous-type <STE2,TE> = "mobile UMTS", il est possible de définir deux deuxièmes sous-types <STE1,2,TE> = "téléphone mobile UMTS" et <STE2,2,TE> = "PDA mobile UMTS". De manière récursive, il est possible de définir des sous-types de sous-type d'entité pour caractériser plus précisément une entité d'un type donné TE. Chaque entité du réseau RI ou RE dispose d'un identificateur unique et d'un contexte associé, formant l'ensemble d'informations {IE} propre à cette entité. La fonction de récupération de type d'entité fREC exécute une recherche de correspondance à une sous-étape E31 et une récupération de contexte à une sous-étape E32.
A la sous-étape E31, le module de récupération REC lance une recherche de correspondance basée sur un ensemble d'informations {IDX} qui constitue un sous-ensemble total ou partiel de l'ensemble des informations {ID} décodées par le module DEC. Par exemple, l'ensemble d'informations {IDX} est fixe, c'est-à-dire la recherche de correspondance porte toujours sur des mêmes paramètres. En variante, si les ressources de traitement du dispositif DD sont suffisantes, l'ensemble d'informations {IDX} peut être variable, c'est-à-dire la recherche de
correspondance porte sur des paramètres différents selon le type de protocole <P> ou le type de message <TM>. La recherche de correspondance consiste à comparer l'ensemble {IDX} à des informations ou clés primaires mémorisées dans la base d'identification d'entité BIE. Si la base BIE ne contient pas d'informations coïncidant avec l'ensemble {IDX}, la recherche de correspondance est un échec et la sous-étape E32 de récupération de contexte n'est pas exécutée. Si la base BIE contient des informations coïncidant avec l'ensemble {IDX}, la recherche de correspondance est un succès et la sous-étape E32 de récupération du contexte est exécutée. Par exemple si l'ensemble {IDX} est constitué d'une adresse réseau et d'un port de transport et la base BIE contient les informations suivantes . {1.2.3.4 ; 5060}, {1.2.3.4 ; 5100}, {1.2.3.6 ; 5200}, alors la recherche de correspondance est un succès pour un paquet reçu tel que {IDX} = {1.2.3.6 ; 5200}, et est un échec pour un paquet reçu tel que {IDX} = {1.2.3.4 ; 5200}. La recherche de correspondance peut être un échec selon les deux cas suivants. L'échec de la recherche de correspondance portant sur l'entité destinatrice signifie que le paquet reçu est destiné à une entité qui n'est pas connue du dispositif DD, et la fonction fREC retourne les informations <TE> = "NC", <STE> = "IND" et {IE} = "IND". L'échec de la recherche de correspondance portant sur l'entité émettrice signifie que le paquet reçu est le premier paquet en provenance d'une nouvelle entité, et la fonction fREC crée alors un nouvel ensemble {IE} d'identificateur et de contexte pour cette entité
dans les bases BIE et BCE, et retourne les informations associées <TE> = "IND" et <STE> = "IND". A la sous-étape E32, exécutée si la recherche de correspondance à la sous-étape E31 est un succès, le module de récupération REC lit dans la base d'identification d'entité BIE l'identificateur correspondant aux informations coïncidant avec l'ensemble {IDX}. Puis le module REC récupère le contexte associé à cet identificateur dans la base de contexte d'entité BCE, en notant {IE} l'ensemble constitué de l'identificateur et du contexte associé. Le module REC récupère ainsi les informations <TE>, <STE> et {IE} qui sont disponibles par la suite pour des fonctions de traitement haut niveau, à la fois par rapport à l'entité émettrice et à l'entité destinatrice du paquet reçu. Par souci de simplification dans la suite de la description, les informations <TE>, <STE> sont supposées incluses dans l'ensemble {IE}.
L'information de type d'entité <TE> permet à des modules du système THN, tels que les modules d'analyse de conformité AC et de collecte COL, d'adapter des traitements au type d'entité considéré. Lorsqu'un paquet reçu n'a pu être totalement décodé par le module de décodage DEC, c'est-à-dire lorsque le drapeau associé <NDEC> est différent de "total", le module REC effectue des actions selon deux cas. Dans un premier cas, si les informations de l'ensemble {IDX} font partie des informations qui ont pu être décodées, alors la fonction fREC est exécutée selon les principes décrits ci-dessus. Dans un deuxième cas, si certaines informations de l'ensemble {IDX} n'ont pu être décodées, alors la fonction fREC n'est pas exécutée selon les principes
décrits ci-dessus et effectue un marquage spécifique au paquet reçu en assignant une valeur "IND" aux informations <TE> et {IE}, indiquant aux fonctions en aval que la récupération du type d'entité a échoué.
Le module de récupération REC fournit l'ensemble {IE}, ainsi que le paquet reçu PAQ au module de temporisation TEM, en complément de l'ensemble {ID} fourni par le module de décodage DEC. Par ailleurs le module REC indique si le paquet est transmis du réseau RE vers RI ou inversement.
A l'étape E4, le module de temporisation TEM mémorise les ensembles {IE}, {ID} et le paquet reçu PAQ en file d'attente dans une mémoire temporaire. Le module TEM coopère avec le module de gestion GES afin qu'une fonction de gestion fGES détermine un temps de traitement <TT> à allouer à des fonctions des modules du système THN en fonction de caractéristiques de l'entité émettrice du paquet reçu.
La fonction de gestion des traitements fait partie des fonctions de traitement haut niveau. Plus précisément, cette fonction intervient à l'interface entre les modules du système TBN qui opèrent au débit de la ligne de transmission et les modules du système THN qui effectuent des opérations beaucoup plus longues, engendrant un délai et/ou de la gigue dans le traitement des paquets reçus. La fonction de gestion fGES prend en entrée les différents paramètres suivants : - le paquet reçu et les informations {ID} et <NDEC> fournies par le module de décodage DEC; - le sens de transmission du paquet reçu, par exemple du réseau RE vers le réseau RI, fourni par le module de récupération de type d'entité REC;
- l'ensemble {IE} contenant l'identificateur et le contexte associés à l'entité émettrice, fourni par le module REC, cet ensemble {IE} pouvant contenir outre les informations <TE> et <STE> une information <NCE> désignant un niveau de conformité de l'entité émettrice; - une connaissance des unités de traitements UT du dispositif DD et des fonctions de traitement haut niveau qui sont rattachées à ces unités; -pour chaque unité de traitement, un niveau de remplissage de la file d'attente FIFO(UT) et des ressources disponibles CPU(UT); et - pour chaque unité de traitement, une priorité relative pFj(UT) de la fonction Fj au sein de l'unité de traitement UT, avec 1 j J et J étant le nombre de fonctions rattachées à l'unité de traitement. Par exemple, une unité de traitement peut inclure les fonctions de collecte fCOL et de caractérisation du type d'entité fCTE
La fonction de gestion fGES régule des temps de traitement relatifs à chacun des modules du dispositif de détection DD, pour chaque unité de traitement indépendamment des autres unités de traitement, à intervalle régulier et de manière atemporelle selon des sous-étapes de déterminationdu temps moyen de traitement E41, de détermination du temps de référence par fonction E42, et d'ajustement du temps de référence par fonction E43. A la sous-étape E41, le module de gestion GES détermine un temps moyen de traitement par paquet <Tm> à allouer à une unité UT en fonction de la charge CPU(UT) de l'unité UT : <Tm> = f1 (CPU(UT)), avec
CPU(UT) qui est un nombre compris entre 0 et 1, où 0 correspond à la charge la plus faible, et f1 est une fonction qui prend des valeurs entre 0 et 1 et fournit un résultat également compris entre 0 et 1. Dans le cas le plus simple, f1 est une fonction linéaire d'une inconnue x, définie par exemple par fl(x) = 0,1 + 0,9 x (1 - x). La fonction f1 fournit ainsi un résultat <Tm> proche de 0,1 lorsque l'unité UT est saturée, et un résultat <Tm> proche de 1 lorsque l'unité UT est très faiblement chargée. Optionnellement, le module GES ajuste le temps moyen <Tm> au nombre de paquets en attente pour l'unité de traitement UT en un temps moyen ajusté <Tma>, c'est-à-dire au niveau de remplissage de la file d'attente FIFO(UT) en entrée de l'unité UT : <Tma> = f2 (<Tm>, FIFO(UT)), avec FIFO(UT) est un nombre compris entre 0 et 1, où 0 est par convention le niveau de remplissage le plus faible de la file d'attente, et f2 est une fonction qui prend des valeurs entre 0 et 1 pour les paramètres <Tm> et FIFO(UT) et fournit un résultat également compris entre 0 et 1. Par exemple, la fonction f2 est définie de la manière suivante f2 (<Tm>, FIFO(UT)) = min (<Tm> x (1 - FIFO(UT)), 0,1). La fonction f2 fournit ainsi un résultat <Tma> proche de <Tm> lorsque la file d'attente est quasiment vide, et un résultat <Tma> proche de 0,1 lorsque la file d'attente est quasiment pleine. Par conséquent, le module GES évite une saturation globale du dispositif DD, pouvant entraîner par exemple des durées de traitement inacceptables ou une impossibilité de filtrer des paquets malicieux.
La sous-étape E41 est exécutée à intervalles de temps réguliers par le module GES afin de mettre à jour le temps moyen <Tm> et le cas échéant le temps moyen ajusté <Tma> en fonction des variations de la charge du dispositif ou du niveau de remplissage des files d'attente. A la sous-étape E42, le module de gestion GES détermine un temps de référence <TmFj> pour chaque fonction Fj rattachée à l'unité de traitement considérée, avec 1 j J et J étant le nombre de fonctions rattachées à l'unité de traitement. Le temps de référence <TmFj> d'une fonction Fj est déterminé en fonction du temps moyen de traitement <Tm> ou <Tma> et de la priorité relative <pFj> de cette fonction au sein de l'unité de traitement UT, la priorité relative <pFj> étant fixée pour une implémentation donnée du dispositif DD. Le temps de référence <TmFj> est déterminé en outre en fonction d'un nombre de paquets <npFj> destinés à la fonction Fj. Ce nombre de paquets <npFj> est par exemple déterminé par le module de récupération d'entité REC qui, en fonction du type de l'entité et du sens du paquet, en déduit les fonctions traversées et comptabilise le nombre de paquets destinés à chacune de ces fonctions.. Le temps de référence <TmFj> est par exemple déterminé selon la relation suivante : J J <Tm> = (1 <npFj>.<TmFj>) / <npFj> (1). j=1 j=1 Le temps de référence <TmFj> peut être écrit comme le produit d'un temps unitaire TU pour toutes les fonctions et de la priorité relative <pFj> : <TmFj> = TU.<pFj> (2). Par la combinaison des relations (1) et (2), le temps unitaire TU peut s'écrire ainsi : J J TU = (<Tm>. 1 <npFj>) / <npFj>.<pFj> (3). j=1 j=1 Puisque les valeurs de <Tm>, <npFj> et <pFj> sont connues du module GES, ce dernier en déduit la valeur de TU selon la relation (3), puis les valeurs de <TmFj> selon la relation (2). Par conséquent, le module GES maintient un temps moyen de traitement par paquet Tm prédéterminé, pour une unité de traitement donnée, et répartit équitablement les temps de traitement par fonction d'une unité de traitement, selon la priorité relative de chaque fonction au sein de l'unité de traitement, et du nombre de paquets destinés à cette fonction. Par exemple, une unité de traitement exécute de manière répartie quatre fonctions d'analyse de conformité relatives à la fonction fAC du module AC de la manière suivante : - fonction F1 pour des paquets du réseau RE vers le réseau RI dont le type d'entité est défini, avec une priorité relative <pFl> = 0,8; - fonction F2 pour des paquets du réseau RE vers le réseau RI dont le type d'entité est indéfini, avec une priorité relative <pF2> = 1; - fonction F3 pour des paquets du réseau RI vers le réseau RE dont le type d'entité est défini, avec une priorité relative <pF3> = 0,4; et - fonction F4 pour des paquets du réseau RI vers le réseau RE dont le type d'entité est non-défini, avec une priorité relative <pF4> = 0,6. Si, sur une période d'itération donnée de la fonction fGES, le temps moyen de traitement de l'unité de traitement vaut <Tm> = 0,4 et la file d'attente contient respectivement <npFl> = 600, <npF2> = 500, <npF3> = 200 et <npF4> = 400 paquets pour les fonctions F1, F2, F3 et F4, alors le temps unitaire vaut TU = 0,52 et les temps de référence par fonction valent respectivement <TmF1> = 0,41, <TmF2> = 0,52, <TmF3> = 0,20 et <TmF4> = 0,31 pour les fonctions F1, F2, F3 et F4. En corollaire, s'il n'existe qu'une seule fonction F1 pour l'unité de traitement considérée, alors <TmF1> = <Tm>, ce qui revient à court-circuiter la sous-étape E42.
La sous-étape E42 est exécutée à intervalles de temps réguliers par le module GES afin de mettre à jour les valeurs <TmFj> en fonction des variations de <Tm> ou <Tma> et du nombre de paquets <npFj> destinés à chacune des fonctions au sein de l'unité de traitement.
A la sous-étape E43, le module de gestion GES ajuste le temps de référence par fonction <TmFj> en fonction du contexte de l'entité relative au paquet reçu, et notamment d'un niveau de conformité <NCE> de l'entité. Par exemple, pour une fonction Fj utilisée par l'unité de traitement, le module de gestion GES compte un nombre de paquets <npFj,k> dans la file d'attente qui est destiné à la fonction Fj et dont l'entité émettrice a un niveau de conformité <NCE> égal à k, 1 k K et K étant le nombre des différents niveaux de conformité possibles pour les différentes entités émettrices. Par construction, la relation suivante est vérifiée : K <npFj> = <npFj,k> (4). k=1 Le temps de référence par fonction <TmFj> est ajusté en un temps de référence ajusté <TmFj,k>, qui est un temps moyen de traitement des paquets de l'entité dont le niveau de conformité est égal à k, en fonction d'une priorité relative <pFj,k> de la fonction Fj pour des entités de niveau de conformité égal à k. Le temps de référence ajusté <TmFj,k> est par exemple déterminé selon la relation (5) suivante : K K <TmFj> = ( <npFj,k> x <TmFj,k>) / <npFj,k>. k=1 k=1 Le temps de référence ajusté <TmFj,k> pour un niveau de conformité égal à k peut être écrit comme le produit d'un temps de référence ajusté moyen IRMA de la fonction Fj pour tous les niveaux de conformité et de la priorité relative <pFj,k> pour un niveau de conformité égal à k : <TmFj,k> = TRMA.<pFj,k> (6).
Par la combinaison des deux relations précédentes, le temps de référence ajusté moyen IRMA peut s'écrire ainsi selon la relation (7) suivante: K K IRMA = (<TmFj>. <npFj,k>) / <npFj,k>.<pFj,k>. k=1 k=1 Puisque les valeurs de <TmFj>, <npFj,k> et <pFj,k> sont connues du module GES, ce dernier en déduit la valeur de IRMA selon la relation (7), puis de <TmFj,k> selon la relation (6). Par exemple, une fonction Fj ayant un temps de référence <TmFj> égal à 0,41 et un nombre de paquets <npFj> en file d'attente égal à 600, a respectivement <npFj,l> = 100, <npFj,2> = 200, <npFj,3> = 250 et <npFj,4> = 50 paquets en file d'attente <npFj,k> et des priorités relatives valant respectivement <pFj,l> = 1, <pFj,2> = 0,8, <pFj,3> = 0, 6 et <pFj,4> = 0,4 pour des niveaux de conformité respectivement égaux à 1, 2, 3 et 4. Alors le temps de référence ajusté moyen IRMA vaut 0,57 et la fonction Fj a des temps de référence ajustés
<TmFj,1> = 0,57, <TmFj,2> = 0,46, <TmFj,3> = 0,34 et <TmFj,4> = 0,23 pour des niveaux de conformité respectivement égaux à 1, 2, 3 et 4.
A l'issue des sous-étapes E41 à 43, le module de gestion GES détermine un temps de traitement <TT>, relatif ou absolu, alloué à une fonction utilisé par une unité de traitement UT traitant le paquet reçu PAQ.
Si l'unité UT ne comporte qu'une seule fonction, alors le temps de traitement <TT> est égal au temps moyen de traitement <Tm>, ou le cas échéant au temps moyen ajusté <Tma>, déterminés à la sous-étape E41. Si l'unité UT comporte plusieurs fonctions, alors le temps de traitement <TT> d'un paquet destiné à une fonction Fj est égal au temps de référence <TmFj> de la fonction Fj déterminé à la sous-étape E42. Indépendamment du nombre de fonctions utilisées par l'unité UT, le module GES adapte éventuellement le temps de traitement <TT> au niveau de conformité <NCE> de l'entité, et le temps de traitement <TT> d'un paquet émis par l'entité de niveau de conformité k destiné à une fonction Fj est égal au temps de référence ajusté <TmFj,k> de la fonction Fj déterminé à la sous-étape E43. Le module GES commande alors le module de temporisation TEM de fournir les ensembles {IE} et {ID} et le paquet reçu PAQ au module d'analyse de conformité AC en allouant un temps de traitement <TT> pour le paquet reçu PAQ à la fonction d'analyse de conformité fAC. Dans la suite de la description, le temps de traitement <TT> désigne indifféremment un temps de traitement absolu, par exemple une durée de 10 millisecondes, ou un temps de traitement relatif
qui est utilisé par les fonctions du système THN en amont pour ajuster le nombre de règles sélectionnées. Le temps de traitement <TT> alloué à chacune des fonctions du système THN n'est pas forcément identique, et dépend directement de l'implémentation et du flux de paquets reçus. Ces différents temps de traitement sont notés <TAC>, <TCTE>, <TCOL> et <TANC> respectivement pour les fonctions fAC, fCTE, fco', et f AN C A l'étape E5, le module d'analyse de conformité AC reçoit les informations {ID} et <NDEC> fournies par le module de décodage DEC, ainsi que le paquet reçu PAQ correspondant, et applique à ces derniers la fonction d'analyse de conformité fAC afin d'analyser le paquet reçu en fonction de règles de conformité mémorisées dans la base de règles BR. La fonction fAC prend également en entrée les différents paramètres suivants : - des ensembles {IE} contenant l'identificateur et le contexte respectivement associés aux entités émettrice et destinatrice, contenant notamment les informations <TE> et <STE>; et le temps de traitement <TT> alloué par la fonction de gestion fGES. Par la suite, on note {IE}E et {IE}D les ensembles contenant l'identificateur et le contexte respectivement associés aux entités émettrice et destinatrice, et ces ensembles sont appelés contexte d'émission {IE}E et contexte de destination {IE}D. Par extension, on note respectivement <TE>E, <STEm,TE>E et <NCE>E le type, le sous-type et le niveau de conformité de l'entité émettrice, et respectivement <TE>D et <STEm,TE>D le type et le sous-type de l'entité destinatrice. Par ailleurs, le
temps de traitement <TT>, relatif ou absolu, alloué à la fonction fAC est notée <TAC>. Le module AC lit le type d'entité <TE>E de l'entité émettrice. Si le type d'entité <TE>E est indéfini (<TE>E = IND), alors le module AC exécute une analyse de conformité pour entité indéfinie à l'étape E6. Si le type d'entité <TE>E est défini, alors le module AC exécute une analyse de conformité pour entité définie à l'étape E8. Par conséquent, le module AC adapte des contrôles de conformité sur le paquet reçu selon que l'entité émettrice est définie ou non définie. Par définition, le type d'entité <TE>E ne peut pas prendre la valeur "inconnu" = "NC". En variante, le module AC exécute une analyse de conformité pour entité définie à l'étape E8 seulement si le type <TE>E de l'entité émettrice sont définis. Dans le cas contraire, l'étape E6 est exécutée.
A l'étape E6, le module d'analyse de conformité AC sélectionne un ensemble de règles d'analyse de conformité {RAC1} mémorisées dans la base de règles BR, pour les entités de type non défini, en fonction notamment du temps de traitement de paquet <TAC>, et optionnellement du protocole de paquet <P> et du type de message reçu <TM>. Le module AC sélectionne en priorité des règles d'analyse de conformité critiques, et optionnellement des règles d'analyse de conformité non-critiques, selon un ordre de priorité de manière à ce que les règles les plus prioritaires soient appliquées au paquet reçu pendant le temps de traitement de paquet <TAC> alloué à la fonction fAC. En particulier, les règles d'analyse de conformité critiques sont prioritaires devant les règles non-critiques.
De manière générale, une règle d'analyse de conformité sélectionnée RAC1 est appliquée au paquet reçu PAQ, et le module AC prend une décision sur la conformité du paquet PAQ en fonction d'un résultat RES1 fourni par la règle d'analyse : RES1 = RAC1(PAQ). Par exemple, la règle RAC1 vérifie que l'entité émettrice transmet des requêtes vers un port de destination autorisé de l'entité destinatrice. A cette fin, la règle compare le port de destination contenu dans le paquet reçu PAQ de la requête courante avec une liste des ports de destination autorisés de l'entité destinatrice et mémorisé dans la base de contexte d'entité BCE.
Par convention, le résultat RES1 prend la valeur OK si le paquet est conforme à la règle considérée, la valeur NOK si le paquet est non-conforme. Le résultat RES1 prend la valeur IND (indéfini) si la règle n'a pu déterminer si le paquet est conforme ou non, c'est-à-dire si la règle est inapplicable au paquet. Selon l'exemple précédent, le décodage du port de destination contenu dans le paquet reçu PAQ peut être erroné et ininterprétable pour être comparé avec une liste des ports de destination autorisés.
Dans ce cas, la conformité du paquet à la règle est indéterminée. Dans un autre exemple, la conformité du paquet à la règle peut être indéterminée lorsque la règle nécessite une information de caractérisation de type ou de sous-type qui n'est pas encore renseignée dans la base BCTE lorsque la règle est exécutée. Le module d'analyse de conformité AC fournit un résultat global RESG1 dépendant des résultats RES1 retournés respectivement par les règles RAC1.
Si au moins une règle fournit un résultat RES1 égal à NOK, alors le résultat global RESG1 est égal à NOK et le paquet reçu est non-conforme. Si aucune règle ne fournit de résultat RES1 égal à NOK, mais au moins une règle fournit un résultat RES1 égal à IND, alors le résultat global RESG1 est égal à IND. Le résultat global RESG1 est aussi égal à IND si au moins une règle critique sélectionnée n'a pu être appliquée au paquet pendant le temps <TAC>.
Dans tous les autres cas, c'est-à-dire si aucune règle n'a fourni un résultat égal à NOK ou à IND et si toutes les règles critiques sélectionnées ont été exécutées, alors le résultat global RESG1 est égal à OK et le paquet reçu est considéré conforme.
A l'issue de l'exécution des règles, le module AC met à jour les informations de conformité relatives à l'entité émettrice considérée dans le contexte {IE}E. En complément, selon le résultat global RESG1, plusieurs actions de sortie peuvent être exécutées . Si le résultat global RESG1 est égal à NOK, le module AC exécute une étape de traitement d'anomalie EA1. Si le résultat global RESG1 est égal à NOK ou à IND, le module AC enregistre optionnellement des informations d'historique dans le contexte {IE}E de l'entité émettrice. Si le résultat global RESG1 est égal à OK, le module AC fournit une copie du paquet reçu PAQ et les informations associées au module de caractérisation du type d'entité CTE. Le paquet reçu PAQ, considéré comme conforme, est transmis par le dispositif DD au réseau RI. Indépendamment du résultat global RESG1, une requête de corrélation peut être adressée au module
COL afin de mettre à jour des informations dans le contexte de l'entité, en fonction de la réponse éventuelle retournée relativement au paquet analysé.
A l'étape EA1, le module d'analyse de conformité AC détecte une anomalie par exemple en fonction du résultat global RESG1 relatif au paquet reçu PAQ. Le module AC peut alors émettre une alarme selon le niveau de l'anomalie observée, en particulier dans le cas où au moins une règle critique d'analyse de conformité a fourni un résultat négatif. Si le paquet reçu représente un danger élevé pour le service, le module AC peut supprimer le paquet ou commander la suppression de ce dernier par le dispositif DD. Par ailleurs, le module AC peut ajouter des informations d'historique au contexte d'émission {IE}E dans la base de contexte d'entité BCE. Enfin, le module AC peut commander l'ajout d'une règle de filtrage dynamique au niveau du module FIL, relative à l'entité émettrice considérée, afin de se protéger de paquets pouvant être émis ultérieurement par cette entité.
A l'étape E7, lorsque le résultat global RESG1 est égal à OK, le module de caractérisation du type d'entité CTE reçoit les informations {ID} et <NDEC> fournies par le module de décodage DEC, ainsi que le paquet reçu PAQ correspondant, et applique à ces derniers la fonction de caractérisation fCTE afin de déterminer le type <TE>E de l'entité émettrice et les sous-types éventuels, à partir d'un nombre maximal NMPAQ de paquets reçus consécutivement en provenance de la même entité émettrice de type indéfini.
La fonction fCTE prend également en entrée les contextes d'émission {IE}E et de destination {IE}D et un temps de traitement <TCTE> alloué par la fonction de gestion fGES. La fonction fCTE initialise des variables à une sous-étape E71, détermine des règles de caractérisation à une sous-étape E72 et exécute ces règles déterminées à une sous-étape E73. A la sous-étape E71, pour le premier paquet reçu PAQ en provenance de l'entité émettrice, le module CTE initialise à zéro un nombre de paquets analysés <NPA>. Le type de l'entité émettrice est supposé appartenir à un ensemble de P types d'entité possibles. Le module CTE initialise à zéro un compteur <CVTp>, avec 1 p P, indiquant la vraisemblance que le type de l'entité émettrice corresponde au type "p" d'une entité, parmi les P types d'entité possibles. Par convention, plus la valeur du compteur <CVTp> est élevée, plus la vraisemblance est forte, et inversement. Par extension, le module CTE initialise à zéro un compteur <CVTm,p>, avec 1 m M et M le nombre de sous-types de l'entité émettrice, indiquant la vraisemblance que le sous-type de l'entité émettrice corresponde au sous-type "m" du type "p" d'une entité. Les P types d'entité possibles sont supposés suffisamment dissemblables les uns des autres, afin que l'un des compteurs <CVTp> prenne une valeur plus élevée relativement aux autres compteurs lorsque le nombre de paquets reçus et analysés augmente. A la sous-étape E72, le module CTE sélectionne un ensemble de règles de caractérisation de type d'entité {RCTE} et/ou un sous-ensemble de règles de caractérisation de sous-type d'entité {RSCTE} parmi
un ensemble de règles de caractérisation mémorisées dans la base de règles BR. Pour optimiser les ressources du dispositif DD, le module CTE sélectionne les règles de caractérisation en fonction du temps de traitement <TCTE> alloué par le module GES, du nombre de paquets reçus <NPA>, et d'un vecteur de vraisemblance <VV> dont les composantes sont les compteurs <CVTp> et <CVTm,p>.
De manière formelle, l'ensemble de règles sélectionnées peut s'écrire ainsi : ({RCTE}, {RSCTE}) = fCTE (<TCTE>, <NPA>, <VV>). Par construction, les paramètres de sélection <TCTE>, <NPA> et <VV> sont ramenés à des espaces discrets et bornés, de telle sorte que les règles puissent être sélectionnées en utilisant une matrice statique ou des règles logiques simples. Plus le temps <TCTE> est élevé, plus le nombre de règles sélectionnées pour un paquet donné est élevé, et inversement. Plus le nombre de paquets reçus <NPA> est élevé et tend vers le nombre maximal NMPAQ, plus le cardinal de l'ensemble {RSSTE} est grand par rapport au cardinal de l'ensemble {RCTE}, signifiant que les premiers paquets servent à déterminer le type de l'entité et les paquets suivants servent à déterminer le ou les sous-types associés. Plus l'une des composantes <CVTp> du vecteur <VV> est grande par rapport aux autres, plus il est vraisemblable que l'entité soit de type "p", ce qui se traduit par l'augmentation du nombre de règles sélectionnées relatives au type d'entité "p" et au(x) sous-type(s) associé(s). A la sous-étape E73, le module CTE exécute les règles de caractérisation sélectionnées, en
privilégiant les règles de l'ensemble {RCTE} dans le respect du temps de traitement alloué <TCTE>. Chaque règle de caractérisation porte sur des informations sélectionnées parmi les ensembles {ID}, {IE}E et {IE}D fournis par les fonctions de traitement en amont. Optionnellement, la règle de caractérisation peut porter sur des informations contenues dans le paquet reçu, hors de celles extraites par le module de décodage DEC. Chaque règle de caractérisation compare des informations sélectionnées, telles que des attributs du paquet reçu, à celles mémorisées dans la base de caractérisation de type d'entité BCTE. Par exemple, une règle de caractérisation sélectionnée RCTE compare la longueur ou la valeur d'un champ dans le paquet reçu à une longueur ou une valeur de référence contenue dans la base BCTE. Selon d'autres exemples, la règle sélectionnée RCTE compare la position d'un champ relativement à d'autres champs dans le paquet reçu par rapport à une position de référence, ou compare le nombre d'occurrences d'un champ dans le paquet reçu à un nombre maximal d'occurrences. Suite à l'exécution de chacune des règles sélectionnées, le module CTE modifie le vecteur <VV> en incrémentant certaines composantes <CVTp> ou <CVTm,p>, et décrémentant d'autres composantes. Lorsque le nombre de paquets reçus atteint le nombre maximal NMPAQ, le module CTE vérifie si l'une des composantes <CVTp> a atteint une valeur suffisamment élevée par rapport aux autres composantes pour déterminer le type de l'entité émettrice. Si ce dernier est déterminé, alors le module CTE actualise la valeur du type <TE>E mémorisée dans la base d'identification d'entité BIE,
et actualise ainsi le contexte d'émission {IE}E. Par extension, si le type de l'entité émettrice a pu être déterminé, le module CTE vérifie si l'une des composantes <CVTm,p> a atteint une valeur suffisamment élevée par rapport aux autres pour déterminer le ou les sous-types de l'entité émettrice. Par contre, si le type de l'entité émettrice n'a pu être déterminé après un nombre NMPAQ de paquets reçus, le type de l'entité reste à l'état indéfini "IND", ce qui entraîne une nouvelle phase de caractérisation de type d'entité et l'étape E7 est répétée. Optionnellement, le module CTE mémorise des informations d'historique dans le contexte de l'entité dans la base de contexte d'entité BCE. En outre, le module CTE peut émettre une alarme à une étape EA2 si le type de l'entité émettrice n'a pu être déterminé. Le module CTE détecte alors une anomalie relative aux paquets PAQ de l'entité émettrice, signifiant par exemple que l'entité est de type inconnu et potentiellement dangereuse.
A l'étape E8, si le type d'entité <TE>E est considéré comme défini par le module d'analyse de conformité AC à l'issue de l'étape E5, la fonction d'analyse de conformité fAC du module AC détermine des règles d'analyse de conformité à une sous-étape E81 et exécute ces règles déterminées à une sous-étape E82.
A la sous-étape E81, le module AC sélectionne un ensemble de règles d'analyse de conformité {RAC2} mémorisées dans la base de règles BR, en fonction notamment du niveau de conformité <NCE>E de l'entité émettrice, du temps de traitement de paquet <TAC>, du type d'entité <TE>E de l'entité émettrice, et
éventuellement du protocole de paquet <P> et du type de paquet reçu <TM>. De manière formelle, l'ensemble de règles sélectionnées peut s'écrire ainsi : {RAC2} = fAC (<NCE>E, <Tac>, <TE>E, <P>, <TM>). Plus le niveau de conformité <NCE>E est faible, plus le nombre de règles sélectionnées {RAC2} est élevé. Par ailleurs, pour un niveau de conformité <NCE>E donné, plus le temps <TAC> est élevé, plus le nombre de règles sélectionnées {RAC2} est élevé. Ainsi, bien qu'une entité émettrice ait un niveau de conformité élevé pour lequel le nombre de règles sélectionnées est faible, la valeur élevée du temps de traitement de paquet alloué <TAC> permet de sélectionner un plus grand nombre de règles d'analyse de conformité. La fonction fAC adapte ainsi l'analyse de conformité au niveau de conformité de l'entité émettrice et aux ressources disponibles du dispositif de détection.
En particulier, l'ensemble de règles d'analyse de conformité {RAC2} comprend les deux types de règles suivants : des règles critiques et des règles non-critiques. Les règles critiques d'analyse de conformité sont prioritaires par rapport aux règles non-critiques. Par ailleurs, les règles critiques servent à détecter des anomalies ou des attaques estimées critiques, c'est-à-dire dangereuses par rapport au service contrôlé.
Par exemple, pour un service de voix sur IP offert par le réseau RI supportant le protocole d'initiation de session SIP, chaque paquet reçu contient des champs "From" et "To" qui désignent respectivement des identificateurs logiques d'émission et de destination et qui sont décodés par
le module de décodage DEC. Une règle critique vérifie alors que l'entité émettrice émettant un paquet qui est un message de type "INVITE" a un identificateur d'émission désigné dans le champ "From" du paquet qui est présent dans la base de contexte d'entité BCE. Par exemple, cet identificateur d'émission a été mémorisé dans la base BCE par la fonction de corrélation fCOR ayant établi une corrélation entre une requête de type "REGISTER" émise depuis l'entité émettrice et une réponse à cette requête par l'entité destinatrice, la réponse contenant cet identificateur d'émission dans un champ "Tou. Dans un autre exemple, une règle critiquevérifie que l'entité émettrice n'émet pas de requête interdite selon le type <TE>E de l'entité. A cette fin, la règle critique compare le type de la requête courante avec une liste de requêtes interdites associées au type <TE>E de l'entité et mémorisée dans la base BCE.
Les règles non-critiques d'analyse de conformité sont moins prioritaires que les règles critiques, et portent sur des anomalies ou des attaques qui sont supposées possibles par l'administrateur du dispositif DD, mais dont les conséquences sont moindres que celles d'une attaque critique. Par exemple, pour un service de voix sur IP supportant le protocole SIP, une règle non-critique vérifie que le paquet reçu PAQ émis par l'entité émettrice est un message de type "SIP" qui est autorisé pour l'entité émettrice selon le type et/ou au moins un sous-type de cette dernière. A cette fin, la règle non-critique compare le type de message "SIP" avec une liste de types de message associée à l'entité émettrice et mémorisée dans la base BCTE.
Par exemple, cette liste a été mémorisée dans la base BCTE par la fonction d'apprentissage fApp. De manière plus générale, les règles critiques peuvent porter sur des attaques de type déni de service ou usurpation d'identité, tandis que les règles non-critiques peuvent porter sur des attaques de type collecte d'information. Par ailleurs, les règles critiques, respectivement non-critiques, peuvent être ordonnées entre elles par niveau de priorité.
A la sous-étape E82, le module AC applique les règles d'analyse de conformité sélectionnées au paquet reçu.
Optionnellement, le module AC coopère avec le module de corrélation COR afin d'établir des corrélations entre des paquets reçus. Toutefois, le résultat fourni par la fonction fAC ne peut pas dépendre de règles de corrélation utilisées par le module COR puisque le module AC a besoin de donner un résultat pour chaque paquet reçu. En outre, des règles de corrélation appelées par la fonction fAC servent à actualiser des informations mémorisées dans la base BCE qui sont éventuellement utilisées ultérieurement par le module AC. Une règle d'analyse de conformité sélectionnée RAC2 est exécutée en fonction du paquet reçu PAQ et des contextes d'émission {IE}E et de destination {IE}D, et le module AC prend une décision sur la conformité du paquet PAQ en fonction d'un résultat RES2 fourni par la règle d'analyse : RES2 = RAC2(PAQ, {IE}E, {IE}D). Comme à l'étape E6, le résultat RES2 prend la valeur OK si le paquet est conforme à la règle considérée, la valeur NOK si le paquet est non-
conforme, et la valeur IND (indéfini) si la règle n'a pu déterminer si le paquet est conforme ou non, c'est-à-dire si la règle est inapplicable au paquet. Le résultat RES2 prend la valeur IND par exemple lorsque la règle fait référence à un attribut de type d'entité qui n'est pas encore défini lorsque la règle est exécutée. Le module AC exécute tout ou partie des règles sélectionnées selon un ordre de priorité de manière à ce que les règles les plus prioritaires, en l'occurrence les règles critiques, soient appliquées au paquet reçu pendant le temps de traitement de paquet <TAC> alloué à la fonction fAC. En particulier, même si une règle fournit un résultat négatif, les règles suivantes sont exécutées. Le module d'analyse de conformité AC fournit un résultat global RESG2 dépendant des résultats RES2 retournés respectivement par les règles RAC2. Comme à l'étape E6, si au moins une règle fournit un résultat RES2 égal à NOK, alors le résultat global RESG2 est égal à NOK et le paquet reçu est non-conforme. Si aucune règle ne fournit de résultat RES2 égal à NOK, mais au moins une règle fournit un résultat RES2 égal à IND ou si au moins une règle critique sélectionnée n'a pu être appliquées au paquet pendant le temps <TAC>, alors le résultat global RESG2 est égal à IND. Dans tous les autres cas, c'est-à-dire si aucune règle n'a fourni un résultat égal à NOK ou à IND et si toutes les règles critiques sélectionnées ont été exécutées, alors le résultat global RESG2 est égal à OK et le paquet reçu est considéré conforme. Dans tous les cas, le module d'analyse de conformité AC actualise éventuellement le contexte d'émission {IE}E et le niveau de conformité <NCE>E de
l'entité émettrice. Plus le nombre de règles ayant donné un résultat non-conforme pour une entité émettrice est élevé, plus le niveau de conformité <NCE>E diminue, et inversement. Dans un premier exemple, le niveau de conformité diminue, respectivement augmente, lorsqu'au moins une règle fournit un résultat négatif, respectivement positif, pour un paquet reçu. Dans un deuxième exemple, le niveau de conformité diminue, respectivement augmente, si un nombre prédéterminé de règles fournit un résultat négatif, respectivement positif, pour un paquet donné, ou pour plusieurs paquets consécutifs, ou encore pour plusieurs paquets reçus parmi un nombre de paquets prédéterminé.
Si le résultat global RESG2 est égal à OK, le module AC fournit une copie du paquet reçu PAQ et les informations associées au module de collecte COL, et le procédé passe à l'étape E9. Le paquet reçu PAQ, considéré comme conforme, est transmis par le dispositif DD au réseau RI. Si le résultat global RESG2 est égal à NOK, c'est-à-dire le paquet reçu est non-conforme, le module AC fournit le paquet reçu PAQ et les informations associées au module d'analyse de non-conformité ANC, et le procédé passe à l'étape E11. Optionnellement, le module AC émet une alerte comme décrit à l'étape d'alerte EA1. En variante, le module AC ajoute une règle de filtrage dynamique à celles gérées par le module de filtrage FIL afin de bloquer des flux comprenant des paquets similaires au paquet reçu PAQ ou de compter les paquets émis par l'entité émettrice. Dans tous les cas, en plus du résultat global RESG2, le module AC fournit l'ensemble {RES2}
contenant les résultats de chaque règle d'analyse de conformité qui a pu être exécutée, afin d'informer les fonctions de traitement en aval, notamment des modules COL et ANC, sur des détails observés sur le paquet reçu PAQ.
A l'étape E9, si le paquet reçu est considéré conforme par le module AC à l'étape E8, le module de collecte COL reçoit les informations {ID} et <NDEC> fournies par le module de décodage DEC, ainsi que le paquet reçu PAQ correspondant, et applique à ces derniers la fonction de collecte fCOL afin d'extraire du paquet reçu des attributs de caractérisation de type d'entité destinés à actualiser la base de caractérisation de type d'entité BCTE, via la fonction fApp. La fonction fCOL prend également en entrée le contexte d'émission {IE}E récupéré par le module REC et un temps de traitement <TCOL> alloué par la fonction de gestion fGES. La fonction fCOL détermine des règles de collecte à appliquer à une sous-étape E91 et exécute ces règles déterminées à une sous-étape E92. A la sous-étape E91, le module de collecte COL sélectionne un ensemble de règles de collecte {RCOL} mémorisées dans la base de règles BR, en fonction notamment du type <TE>E de l'entité émettrice et du temps de traitement <TCOL>. La fonction fCOL adapte ainsi un niveau de collecte au type de l'entité émettrice et aux ressources disponibles du dispositif DD. De manière formelle, l'ensemble de règles sélectionnées peut s'écrire ainsi {RCOL} = fCOL (<TE>E, <TCOL>)
Une règle de collecte RCOL désigne un ensemble {AA} d'attributs de caractérisation de type ou sous-type à collecter pour le paquet reçu, chaque attribut étant associé à une méthode de collecte.
Par ailleurs, dans le cas où le service contrôlé repose sur plusieurs protocoles, et éventuellement sur plusieurs types de messages par protocole, les règles de collecte peuvent être sélectionnées en outre en fonction du protocole de paquet <P> et du type de message reçu <TM> contenus dans l'ensemble {ID}, dans quel cas : {RCOL} = f COL (<TE>E, <TCOL>, <P>, <TM>). Par exemple, pour un service de voix sur IP, des règles de collecte spécifiques sont sélectionnées pour un paquet PAQ reçu selon le protocole d'initiation de session SIP, le paquet pouvant être un message de type "REGISTER" ou de type "INVITE". A la sous-étape E92, le module de collecte COL exécute les règles de collecte sélectionnées, selon un ordre de priorité prédéfini dans le respect du temps de traitement alloué <TCOL>• Chaque attribut à collecter AA, contenu dans l'ensemble {AA}, est extrait du paquet reçu, puis soumis à la méthode de collecte correspondante.
De manière non exhaustive, un attribut à collecter AA peut désigner la présence, la valeur, la longueur ou le nombre d'occurrences d'un champ dans le paquet reçu, ou bien la longueur ou l'heure de réception du paquet reçu.
En corollaire, une méthode de collecte peut consister à compter un nombre d'évènements ou une valeur moyenne sur une période prédéterminée, à déterminer une valeur maximale par exemple du débit de paquets reçus, ou bien à actualiser un attribut déjà appris.
La fonction de collecte fCOL fournit un résultat d'erreur si au moins une règle de collecte RCOL n'a pu être exécutée correctement, c'est-à-dire un attribut à collecter AA n'a pu être extrait du paquet reçu, ou que la méthode de collecte correspondante a échoué. Le résultat d'erreur est fourni à titre indicatif au dispositif DD, par exemple pour déceler des entités dont le type a été incorrectement déterminé ou qui présentent un comportement anormal, mais n'entraîne pas la suppression du paquet reçu. Chaque règle de collecte actualise des informations de caractérisation contenues dans le contexte d'émission {IE}E, pouvant porter indifféremment sur le type ou des sous-types de l'entité. Ces informations de caractérisation collectées par la fonction de collecte fCOL sont uniquement initialisées, écrites ou actualisées dans le contexte d'émission {IE}E contenu dans la base de contexte d'entité BCE, mais ne sont pas reportées dans la base de caractérisation de type d'entité BCTE.
A l'étape E10, le module d'apprentissage APP actualise des attributs de type ou de sous-type d'entité ATT mémorisés dans la base de caractérisation de type d'entité BCTE. Le module APP fonctionne de manière asynchrone par rapport aux autres modules du dispositif DD, et sur une période de temps beaucoup plus longue, par exemple de plusieurs heures ou de plusieurs jours. Le fonctionnement asynchrone du module APP dépend directement des ressources disponibles du dispositif DD. A l'expiration d'une période de rafraîchissement, la fonction d'apprentissage fApp
collecte des attributs de type ou de sous-type d'entité à une sous-étape E101 et agrège les attributs collectés à une sous-étape E102. A la sous-étape E101, le module d'apprentissage APP sélectionne des attributs de type d'entité ATT contenus dans la base de contexte d'entité BCE correspondant à un type ou sous-type d'entité prédéterminé. Les attributs collectés doivent constituer un ensemble homogène, c'est-à-dire correspondre chacun à une même information de caractérisation, portée par un ensemble d'entités de même type ou sous-type. Si un nombre d'entités correspondant aux attributs sélectionnés ou un nombre d'attributs sélectionnés pour une entité donnée est inférieur à un seuil prédéterminé, la sous-étape de collecte E101 se termine par un échec et la sous-étape d'agrégation E102 n'est pas exécutée. L'étape E10 est alors réitérée à la prochaine expiration de la période de rafraîchissement. A la sous-étape E102, le module d'apprentissage APP applique des méthodes d'analyse statistique à l'ensemble d'attributs sélectionnés. Une méthode d'analyse statistique est utilisée en fonction du type ou sous-type d'information de caractérisation constituant l'ensemble d'attributs sélectionnés. Par exemple, si l'information de caractérisation est une longueur moyenne d'un champ particulier d'un paquet reçu pour des entités de type <TE> et de sous- type <STE> donnés, alors la méthode calcule la moyenne des attributs sélectionnés correspondant chacun à une longueur du champ particulier d'un paquet reçu. Chaque méthode fournit ainsi un résultat qui est un attribut vraisemblable pour un type d'entité.
Le module APP actualise des attributs de caractérisation de type d'entité dans la base de caractérisation de type d'entité BCTE en fonction des résultats fournis par les méthodes d'analyse statistique, ou bien crée de tels attributs dans la base BCTE lorsque ces derniers n'existent pas. Le module APP actualise donc les attributs de caractérisation de type d'entité en fonction des attributs à apprendre AA extraits du paquet reçu et d'autres attributs extraits de paquets interceptés par le dispositif DD et précédemment émis par d'autres entités de même type que celui de l'entité émettrice. Ces attributs actualisés permettent ainsi au module de caractérisation du type d'entité CTE de préciser la détermination du type d'une autre entité dont des paquets sont ultérieurement reçus par le dispositif DD et dont le type est indéfini. En outre, le module APP peut émettre une alarme à une étape EA3 en fonction des attributs sélectionnés. Le module APP peut détecter des valeurs anormales d'attributs sélectionnés. Par exemple, une valeur anormale est une valeur exclue d'un intervalle prédéterminé incluant une valeur de référence prédéterminée, telle qu'une moyenne de valeurs d'un ensemble d'attributs sélectionnés. Le module APP détecte ainsi une anomalie relative à l'entité dont un attribut a une valeur anormale. La détection d'une valeur anormale d'attribut suppose généralement une anomalie relative à l'entité ayant émis le paquet. Cette anomalie peut provenir d'une entité présentant un comportement malveillant non détecté par le module d'analyse de conformité AC, d'une entité mal configurée, ou bien d'une entité dont le type ou le sous-type a été mal déterminé par le module de caractérisation d'entité CTE.
Ainsi, la fonction d'apprentissage, fApp dont l'exécution est de type long-terme, est complémentaire de la fonction d'analyse de conformité fAC exécutée pour chaque paquet reçu, et de la fonction de caractérisation d'entité fCTE exécutée pour un faible nombre de paquets reçus. Par conséquent, si au moins une valeur anormale est détectée par le module APP, ce dernier peut alors émettre une alarme selon l'anomalie observée et l'entité y relative, ou ajouter des informations d'historique à la base de contexte d'entité BCE.
A l'étape E11, si le paquet reçu est considéré comme non-conforme par le module AC à l'étape E8, le module d'analyse de non-conformité ANC reçoit les informations {ID} et <NDEC> fournies par le module de décodage DEC, les contextes {IE}E et {IE}D, le niveau de conformité <NCE>E et le paquet reçu PAQ correspondants, ainsi que les résultats RES2 de chaque règle d'analyse de conformité fournis par le module AC, et applique à ces derniers la fonction d'analyse de non-conformité fANC afin d'établir une corrélation entre des paquets non-conformes émis par l'entité émettrice. Cette corrélation est utile pour caractériser sur le moyen terme un type d'attaque ou de comportement malveillant de l'entité, relativement à un ensemble de paquets non-conformes reçus de cette entité. La fonction d'analyse de non-conformité fANC prend également en entrée un temps de traitement <TANC> alloué par la fonction de gestion fGES. La fonction fANC détermine des règles d'analyse de non-conformité à une sous-étape E111 et exécute ces règles déterminées à une sous-étape E112.
A la sous-étape E111, le module ANC sélectionne un ensemble de règles d'analyse de non-conformité {RANC} mémorisées dans la base de règles BR, en fonction notamment d'un ensemble {RES2}NC des résultats non conformes retournés par les règles d'analyse de conformité et du temps de traitement <TANC>. L'ensemble {RES2}NC dépend donc de règles d'analyse de conformité auxquelles ne sont pas conformes respectivement le paquet reçu et d'autres paquets également émis par l'entité. De manière formelle, l'ensemble de règles sélectionnées peut s'écrire ainsi : {RANC} = fANC ({{RES2}NC}, <TANC>)• Pour optimiser l'utilisation des ressources du dispositif DD, la fonction fANC est décrite par exemple sous forme d'expressions régulières basées sur des opérateurs logiques simples tels que "AND", "OR" ou "NOT". Chaque expression régulière porte sur tout ou partie de l'ensemble {RES2}NC et, si cette dernière est vérifiée, ajoute une ou plusieurs règles d'analyse de non-conformité à l'ensemble {RANC}. L'ensemble {RANC} peut alors être réduit en fonction des ressources disponibles du dispositif DD et donc du temps de traitement alloué <TANC>.
Par exemple, la base de règles BR contient K règles d'analyse de conformité RACk, avec 1 k K et K = 15. L'ensemble {RES2}NC contient M identificateurs de règles RES2m, avec 1 m M et M K, ayant donné un résultat NOK pour le paquet analysé. La base de règles BR contient N règles d'analyse de non-conformité RANCn, avec 1 n N et N = 5. Par exemple, la fonction fANC peut être décrite sous la forme suivante : RES210 OR RES212 - RANCI, RES23 - RANC2,
RES25 AND (NOT RES210) H> RANC3, RANC4, et RES21 OR RES22 OR RES24 OR RES25 OR RES210 H> RANC5. Selon ces hypothèses, les ensembles {RANC} de règles d'analyse de non-conformité suivants sont sélectionnés en fonction des ensembles {RES2}NC reçus de la fonction d'analyse de conformité : si {RES2}NC = {RES23, RES24}, alors {RANC} = fANC ({RES23, RES24}) = {RANC2, RANC5}, si {RES2}NC = {RES25, RES210, RES212}, alors {RANC} = fANC ({RES25, RES210, RES212}) = {RANCI, RANC5}, et si {RES2}NC = {RES22, RES25}, alors {RANC} = fANC ({RES22, RES25}) = {RANC3, RANC4, RANC5}.
A la sous-étape E112, le module ANC applique chaque règle d'analyse de non-conformité sélectionnées RANC de l'ensemble {RANC} au paquet reçu PAQ et aux contextes d'émission {IE}E et de destination {IE}D associés, et fournit un résultat d'exécution RESC : RESC = RANC(PAQ, {IE}E, {IE}D). Le résultat RESC indique par exemple si la règle d'analyse de non-conformité a pu être correctement exécutée ou si d'autres actions sont nécessaires.
Une règle de non-conformité RANC est exécutée selon les trois phases suivantes : - une première phase où la règle est invoquée une première fois pour être associée à des informations de conformité contenu dans le contexte d'émission {IE}E, et le paquet reçu correspondant est analysé; -une deuxième phase où la règle est invoquée à chaque fois qu'un paquet reçu non-conforme engendre la sélection de la règle dans l'ensemble {RANC}; et
- une troisième phase où la règle devient inactive, par exemple à l'expiration d'une temporisation, et les informations de conformité associées à la règle sont supprimées.
Une information de conformité est par exemple le temps écoulé entre l'émission d'une requête et la réception d'une réponse à la requête. Lorsque des informations de conformité contenues dans un contexte d'émission {IE}E sont associées à une règle RANC, cela signifie que la règle RANC est active et exécutée. Le module ANC exécute les règles sélectionnées RANC en tout ou en partie, par exemple selon un ordre de priorité, pendant le temps de traitement <TANC> alloué à la fonction d'analyse de non-conformité fANC. Le module ANC actualise éventuellement des informations de conformité du contexte d'émission {IE}E et le niveau de conformité <NCE>E de l'entité émettrice. Pendant la deuxième phase d'exécution ou à la fin d'exécution d'une règle RANC, le module ANC peut ajouter des informations d'historique à la base de contexte d'entité BCE, ou coopérer avec le module de corrélation COR afin d'établir des corrélations entre le paquet reçu analysé et d'autres paquets reçus. Optionnellement, le module ANC ajoute une règle de filtrage dynamique à celles gérées par le module de filtrage FIL afin de bloquer par exemple des flux comprenant des paquets similaires au paquet reçu.
En outre, le module ANC peut émettre une alarme à une étape EA4 en fonction des règles sélectionnées RANC. Par exemple, le module ANC détecte une anomalie si l'une des règles sélectionnées RANC fournit un résultat négatif.
Ainsi, la fonction fANC, dont l'exécution est de type moyen-terme, est complémentaire de la fonction d'analyse de conformité fAC exécutée pour chaque paquet reçu et permet de détecter des attaques discrètes qui sont réparties sur une plus longue période de temps, par exemple de quelques minutes ou de quelques heures.
En variante, les étapes du procédé selon l'invention sont exécutées pour une analyse de conformité du trafic émis à la fois par les entités de service ES vers les entités clientes EC et par les entités clientes EC vers les entités de service ES. L'analyse de conformité du trafic émis par les entités de service ES vers les entités clientes EC permet notamment d'initialiser de nouvelles entités de service ES rattachées au réseau interne RI et de détecter éventuellement un comportement malveillant ou une mauvaise configuration de ces dernières.
L'invention décrite ici concerne un procédé et un dispositif pour détecter des anomalies dans le trafic émis par une entité vers une autre entité. Selon une implémentation, les étapes du procédé de l'invention sont déterminées par les instructions d'un programme d'ordinateur incorporé dans un processeur du dispositif de détection selon l'invention. Le programme comporte des instructions de programme qui, lorsque ledit programme est exécuté dans le processeur 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'enregistrement 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'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage 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'enregistrement 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'enregistrement 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 (14)

REVENDICATIONS
1 - Procédé pour détecter une anomalie dans le trafic émis par une entité (EC; ES), comprenant une récupération (E3) d'un contexte de l'entité en fonction d'un paquet (PAQ) intercepté dans le trafic, caractérisé en ce qu'il comprend : une sélection (E6; E81) d'au moins l'une de premières règles prédéterminées (RAC1; RAC2) en fonction du contexte de l'entité récupéré et de ressources disponibles d'un dispositif (DD) ayant intercepté ledit paquet, et une décision (E6; E82) sur la conformité du paquet intercepté à ladite au moins une première règle sélectionnée, la conformité du paquet intercepté étant indéterminée si ladite au moins une première règle sélectionnée est inapplicable au paquet intercepté.
2 - Procédé conforme à la revendication 1, comprenant en outre, si le type de l'entité n'est pas défini et si le paquet intercepté est conforme à ladite au moins une première règle sélectionnée, une actualisation (E7) du contexte de l'entité en fonction du paquet intercepté et d'au moins un autre paquet intercepté dans le trafic émis par l'entité.
3 - Procédé conforme à la revendication 2, comprenant en outre une détermination (E7) du type de l'entité en fonction du paquet intercepté et d'autres paquets interceptés dans le trafic émis par l'entité, et une détection (EA2) d'une anomalie si le type de l'entité est indéterminable.
4 - Procédé conforme à la revendication 1, selon lequel si un type de l'entité est défini dans le contexte de l'entité, la sélection de ladite au moins une première règle dépend d'un niveau de conformité de l'entité contenu dans le contexte de l'entité, ledit niveau de conformité dépendant de la conformité d'au moins un autre paquet de l'entité intercepté préalablement audit paquet intercepté à au moins une autre première règle.
5 - Procédé conforme à la revendication 4, selon lequel le contexte de l'entité est actualisé en fonction de la conformité du paquet intercepté à ladite au moins une première règle sélectionnée.
6 - Procédé conforme à la revendication 4 ou 5, comprenant en outre, si le type de l'entité est défini et si le paquet intercepté n'est pas conforme à ladite au moins une première règle sélectionnée, une sélection (E111) d'au moins une deuxième règle en fonction du contexte de l'entité et de ladite au moins une première règle à laquelle n'est pas conforme le paquet intercepté et une détection (EA4) d'une anomalie en fonction d'une conformité du paquet intercepté et d'au moins un autre paquet intercepté dans le trafic émis par l'entité à ladite au moins une deuxième règle sélectionnée.
7 - Procédé conforme à la revendication 4 ou 5, comprenant en outre, si le type de l'entité est défini et si le paquet intercepté est conforme à ladite au moins une première règle sélectionnée, une extraction (E9) d'attributs (AA) du paquet intercepté et une mémorisation des attributs extraits dans le contexte de l'entité.
8 - Procédé conforme à la revendication 7, comprenant en outre une actualisation (E10) d'attributs de type d'entité (ATT) en fonction des attributs extraits mémorisés (AA) et d'autres attributs extraits de paquets interceptés émis par d'autres entités de même type que celui de ladite entité, et une détection (EA3) d'anomalie si la valeur de l'un des attributs extraits est exclue d'un intervalle prédéterminé dépendant des attributs extraits.
9 - Procédé conforme à l'une quelconque des revendications 1 à 8, selon lequel les premières règles sélectionnées comprennent des règles critiques et des règles non-critiques, les règles critiques étant appliquées au paquet intercepté de manière prioritaire par rapport aux règles non-critiques, et selon lequel la conformité du paquet intercepté est indéterminée si au moins une des règles critiques n'a pas pu être appliquée au paquet intercepté pendant un temps de traitement prédéterminé.
10 - Dispositif pour détecter une anomalie dans le trafic émis par une entité (EC; ES) présentant un contexte récupéré en fonction d'un paquet (PAQ) intercepté dans le trafic, caractérisé en ce qu'il comprend : - un moyen (AC) pour sélectionner au moins l'une de premières règles prédéterminées (RAC1; RAC2) en fonction du contexte de l'entité récupéré et de ressources disponibles du dispositif (DD), et - un moyen (AC) pour décider la conformité du paquet intercepté à ladite au moins une première règle sélectionnée, la conformité du paquet intercepté étant indéterminée si ladite au moins une première règle sélectionnée est inapplicable au paquet intercepté.
11 - Dispositif conforme à la revendication 10, comprenant . - un moyen (AC) pour détecter une anomalie en fonction de la conformité du paquet intercepté à ladite au moins une première règle sélectionnée, - un moyen (ANC) pour détecter une anomalie en fonction d'au moins une deuxième règle qui est sélectionnée en fonction du contexte de l'entité et d'au moins une première règle à laquelle n'est pas conforme le paquet intercepté, - un moyen (CTE) pour détecter une anomalie si un type de l'entité contenu dans le contexte de l'entité est indéterminable, et - un moyen (APP) pour détecter une anomalie en fonction d'attributs (AA) extraits du paquet intercepté et d'autres attributs extraits de paquets interceptés émis par d'autres entités de même type que celui de ladite entité, si la valeur de l'un des attributs extraits est exclue d'un intervalle prédéterminé dépendant des attributs extraits.
12 - Dispositif conforme à la revendication 11, lié à une base de données (BCE) comprenant le contexte de l'entité et les attributs (AA) extraits des paquets interceptés, et lié en outre à une autre base de données (BCTE) comprenant des attributs de type d'entité (ATT) qui sont actualisés en fonction des attributs extraits des paquets interceptés et qui servent à déterminer le type de l'entité.
13 - Programme d'ordinateur caractérisé en ce qu'il comprend des instructions pour la mise en oeuvre du procédé selon l'une quelconque des revendications 1 à 9, lorsque le programme est exécuté par un processeur.
14 - Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé selon l'une quelconque des revendications 1 à 9.
FR0755800A 2007-06-15 2007-06-15 Detection d'anomalie dans le trafic d'entites de service a travers un reseau de paquets Pending FR2917556A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR0755800A FR2917556A1 (fr) 2007-06-15 2007-06-15 Detection d'anomalie dans le trafic d'entites de service a travers un reseau de paquets
PCT/FR2008/051067 WO2009004234A1 (fr) 2007-06-15 2008-06-13 Detection d'anomalie dans le trafic d'entites de service a travers un reseau de paquets

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0755800A FR2917556A1 (fr) 2007-06-15 2007-06-15 Detection d'anomalie dans le trafic d'entites de service a travers un reseau de paquets

Publications (1)

Publication Number Publication Date
FR2917556A1 true FR2917556A1 (fr) 2008-12-19

Family

ID=39246756

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0755800A Pending FR2917556A1 (fr) 2007-06-15 2007-06-15 Detection d'anomalie dans le trafic d'entites de service a travers un reseau de paquets

Country Status (2)

Country Link
FR (1) FR2917556A1 (fr)
WO (1) WO2009004234A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111417116B (zh) * 2020-03-10 2023-09-19 国家体育总局体育科学研究所 通过att、读写和异常处理来适配的通信方法及系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6279113B1 (en) * 1998-03-16 2001-08-21 Internet Tools, Inc. Dynamic signature inspection-based network intrusion detection
US20050044406A1 (en) * 2002-03-29 2005-02-24 Michael Stute Adaptive behavioral intrusion detection systems and methods
US20070074272A1 (en) * 2005-09-29 2007-03-29 Fujitsu Limited Network security apparatus, network security control method and network security system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6279113B1 (en) * 1998-03-16 2001-08-21 Internet Tools, Inc. Dynamic signature inspection-based network intrusion detection
US20050044406A1 (en) * 2002-03-29 2005-02-24 Michael Stute Adaptive behavioral intrusion detection systems and methods
US20070074272A1 (en) * 2005-09-29 2007-03-29 Fujitsu Limited Network security apparatus, network security control method and network security system

Also Published As

Publication number Publication date
WO2009004234A1 (fr) 2009-01-08

Similar Documents

Publication Publication Date Title
EP3479285B1 (fr) Procédé et dispositif de surveillance de la sécurité d&#39;un système d&#39;information
US11310201B2 (en) Network security system with enhanced traffic analysis based on feedback loop
US20160261612A1 (en) Fuzzy hash of behavioral results
US8775521B2 (en) Method and apparatus for detecting zombie-generated spam
US10135785B2 (en) Network security system to intercept inline domain name system requests
EP3087701A1 (fr) Procede de diagnostic de fonctions service dans un reseau ip
EP3556130B1 (fr) Procédé de surveillance d&#39;un réseau de télécommunications mis en oeuvre par un point d&#39;accès
FR3106914A1 (fr) Procédé de surveillance de données échangées sur un réseau et dispositif de détection d’intrusions
FR2974965A1 (fr) Procede de detection d&#39;intrusions
US10003602B2 (en) Determining email authenticity
US11743272B2 (en) Low-latency identification of network-device properties
FR3012643A1 (fr) Systeme de detection d&#39;intrusion dans un dispositif comprenant un premier systeme d&#39;exploitation et un deuxieme systeme d&#39;exploitation
EP3205068B1 (fr) Procede d&#39;ajustement dynamique d&#39;un niveau de verbosite d&#39;un composant d&#39;un reseau de communications
FR2917556A1 (fr) Detection d&#39;anomalie dans le trafic d&#39;entites de service a travers un reseau de paquets
EP4066461B1 (fr) Procédé de coordination de la mitigation d&#39;une attaque informatique, dispositif et système associés
EP4009584A1 (fr) Procédé de détermination de classifieurs pour la détection d&#39;attaques dans un réseau de communication, dispositif de détermination associé
EP3375143B1 (fr) Analyse asynchrone d&#39;un flux de données
US8996690B1 (en) Time-based analysis of data streams
EP3869368A1 (fr) Procede et dispositif de detection d&#39;anomalie
FR3079642A1 (fr) Capteur d&#39;intrusion informatique et procede de creation d&#39;un capteur d&#39;intrusion
WO2007006995A2 (fr) Detection dynamique d&#39;anomalies dans le trafic relatif a une entite de service
FR3093258A1 (fr) Procede de protection d’un reseau prive d’ordinateurs
EP3035639B1 (fr) Procédé de détection de balayage de ports non-autorisé dans un réseau informatique, produit programme d&#39;ordinateur et dispositif associés
WO2023036847A1 (fr) Procede et système de surveillance et gestion du trafic de données
EP4009209A1 (fr) Procédé de détermination de quantités pour la détection d&#39;attaques dans un réseau de communication, dispositif de détermination associé