WO2007020361A2 - Etablissement d'alertes par detection d'anomalies statique et dynamique dans le trafic d'une entite de service - Google Patents

Abstract

Pour établir des alertes par évaluations périodiques de paramètres d'évaluation relatifs au trafic d'au moins une entité de service (SE), des détecteurs d'anomalies statiques (DDs) et dynamiques (DDd) pour détection d'attaques de type déni des entités par inondation contribue à constituer une alerte globale incluant les paramètres d'évaluation et une date d'évaluation courante lorsqu'un niveau d'alerte excède un seuil minimal. Les alertes globales des entités associées à la date d'évaluation courante sont agrégées en une alerte agrégée courante (AA). Si la plus petite des distances de similarité entre l'alerte agrégée courante et des alertes agrégées à des dates d'évaluation proches de la date courante est inférieure à un seuil de similarité, les identifiants des alertes agrégées séparées par la plus petite distance sont fusionnés ce qui signale une attaque déjà détectée. Sinon un identifiant est attribué à l'alerte agrégée courante.

Description

Etablissement d'alertes par détection d'anomalies statique et dynamique dans le trafic d'une entité de service

La présente invention se rapporte au domaine de la sécurité des réseaux et aux attaques de type déni de service par inondation. Plus particulièrement elle a trait à un procédé et un système d'établissement d'alertes de détection d'attaques de type déni de service par inondation relativement au trafic d'au moins une entité de service supporté par une liaison de transmission.

Les réseaux de télécommunications, comme 1' internet, transmettent des données 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 de 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 ou de streaming proposant un téléchargement de fichiers multimédias ou diffusant des fichiers multimédias, un serveur de messagerie électronique qui relaie des messages, ou un serveur de noms de domaine DNS qui fournit des adresses IP correspondant à des noms de domaine. Ces entités de service sont, dans certains cas, des extrémités du réseau et sont localisées chez des clients d'un opérateur, tandis que d'autres entités de service, tels les serveurs DNS, sont gérées par l'opérateur du réseau lui-même.

Une attaque par déni de service est une attaque qui vise à rendre indisponible une entité de service. Il existe plusieurs types d'attaques par déni de service, par exemple des requêtes spécifiques qui attaquent directement le fonctionnement de l'entité de service en lui demandant d'effectuer une action "non conforme" . Parmi les attaques par déni de service, les attaques de type déni de service par inondation consistent à dépasser, et donc à "inonder" la capacité réseau de l'entité de service ou de la liaison de transmission par laquelle l'entité de service est reliée au réseau. Dans les deux cas, des caractéristiques volumiques du trafic réseau à destination de l'entité de service augmentent soudainement .

Afin de détecter les attaques par déni de service, il existe deux grandes familles de procédés de détection.

La première famille est relative aux détections par signature. Elle consiste à observer de manière continue le trafic à proximité d'une entité de service potentielle, et à comparer les observations avec des motifs de trafic conservés en mémoire et qui caractérisent des attaques connues. Les procédés de détection de la première famille sont particulièrement adaptés à la détection d'intrusion et la détection de dénis de service non basés sur l'inondation des entités de service.

L'invention concerne davantage la deuxième famille qui est relative aux détections d'anomalies. Une anomalie est 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 règles et de connaissances expertes. Il existe plusieurs types de règles telles qu'une liste de contrôle d'accès et des politiques de sécurité, fixées par l'opérateur ou le client qui possède une entité de service. Ces règles définissent des caractéristiques que le trafic normal doit satisfaire ou au contraire ne pas satisfaire. Cependant, ces règles sont insuffisantes : les entités de service les plus sensibles et les plus visées par la cyber-criminalité sont aussi les plus difficiles à protéger a priori ; en particulier, on traite le trafic d'entités de service dont les clients ne sont pas connus à l'avance, et les règles que l'on peut fixer a priori sont limitées. Une attaque peut en effet se conformer à la plupart des règles fixées a priori dans la forme du trafic que l'attaque envoie pour inonder l'entité de service. Pour éviter cela, il est nécessaire de fixer en plus des règles de type "seuil" sur des composantes volumiques du trafic. Pour une bonne qualité de détection, ces seuils doivent prendre en compte le trafic de l'entité de service en temps normal, ce qui implique une phase d'apprentissage du trafic normal par le procédé de détection, le succès de l'attaque étant fondé sur la quantité de trafic d'attaque effectivement parvenu à l'entité de service pour traitement. Si les règles sont des seuils de trafic, leur efficacité et leur pertinence dépend de la différence entre ces seuils et l'activité du service au moment de l'attaque. Il est donc important que de telles règles prennent en compte l'activité du service, et des règles définies a priori sont insuffisantes .

La détection d'anomalies comportementales consiste à modéliser l'activité de l'entité de service à protéger en l'observant et en modélisant son comportement. Peu de procédés de détection d'anomalies connus sont orientés spécifiquement vers les attaques par inondation. Etant donné des évaluations et un modèle de comportement de l'entité de service, ces procédés font appel à des variables statistiques pour prédire la ou les prochaines évaluations . Si les prochaines évaluations effectives divergent significativement des évaluations prédites, alors une alerte est signalée. Cependant ces procédés de détection d'anomalies détectent également des attaques autres que les attaques par inondation, induisant une perte de temps de traitement par l'opérateur de sécurité.

Par ailleurs sont connus des détections d'anomalies dédiées à la détection d'attaques par inondation. Mais leur coût est élevé et leurs algorithmes sont maintenus confidentiels. Certains de ces procédés de lutte contre les attaques par inondation sont conçus pour être installés au cœur de réseau et/ou se basent sur des informations basées sur un mécanisme de comptage installé dans des routeurs, lesquelles informations ne caractérisent que très grossièrement les attaques.

Certains procédés de détection dite "statique" d'anomalies comportementales consistent à modéliser le trafic d'une entité de service protégée, puis à le découper en périodes pendant lesquelles le trafic a un comportement stable. La modélisation se fait pendant une durée relativement longue, et la détection consiste à vérifier que le trafic observé à une période temporelle donnée possède le même comportement que le trafic observé à cette période pendant la modélisation.

D'autres procédés de détection d'anomalies comportementales consistent au contraire à n'effectuer que des comparaisons locales entre quelques évaluations consécutives du trafic observé, sans mémoire ni apprentissage. On peut ajouter préalablement à ces procédés un apprentissage qui consiste à mémoriser le résultat des comparaisons locales et les extrema de ces comparaisons. La détection d'anomalies est alors "dynamique" en ce sens que les résultats des comparaisons locales sont comparés aux extrema obtenus par la modélisation du trafic lors de l'apprentissage.

Mais aucun système de détection d'anomalies ne réunit une détection statique et une détection dynamique .

Un objectif de la présente invention est de combiner automatiquement des détections d'anomalies statiques et/ou dynamiques relatives au trafic d'une ou plusieurs entités de service pour fournir une alerte globale.

Un autre objectif de la présente invention est d'identifier des ressemblances entre des alertes successives. D'une part, si l'on se limite aux alertes récentes, on peut ainsi regrouper des alertes causées par une même vague d'attaques, et par exemple leur attribuer un identifiant commun. D'autre part, si l'on corrèle des alertes sur une longue durée, on peut ainsi identifier des comportements d'attaques résurgents, et associer une attaque courante à l'un desdits comportements identifiés de manière à pouvoir prendre les mesures de protection requises plus rapidement .

Pour atteindre ces objectifs, un procédé pour établir des alertes par évaluations périodiques de paramètres d'évaluation relatifs au trafic d'au moins une entité de service, est caractérisé en ce qu'il comprend à chaque évaluation les étapes de: déterminer pour au moins une entité de service un niveau d'alerte dépendant de la valeur d'au moins un paramètre d'évaluation relatif au trafic de l'entité de service afin de constituer une alerte globale incluant les paramètres d'évaluation et une date d'évaluation courante lorsque le niveau d'alerte excède un seuil minimal, agréger les alertes globales des entités de service associées à la date d'évaluation courante en une alerte agrégée courante et sélectionner des alertes agrégées antérieures, déterminer des distances de similarité entre l'alerte agrégée courante et lesdites alertes agrégées antérieures en fonction d'au moins l'un des paramètres d'évaluation relatifs à des entités de service qui sont communes à l'alerte agrégée courante et à chaque alerte agrégée antérieure, et si la plus petite des distances est inférieure à un seuil de similarité, fusionner des identifiants des alertes agrégées séparées par la plus petite distance, et sinon attribuer un identifiant à l'alerte agrégée courante.

La fusion des identifiants des alertes agrégées séparées par la plus petite distance signale une attaque déjà détectée pour les entités de service.

Selon une première réalisation, le niveau d'alerte ne dépend que de paramètres d'évaluation évalués à la date d'évaluation courante. L'étape de déterminer un niveau d'alerte pour au moins une entité de service comprend alors une détermination d'un score de sévérité en fonction de déviations de composantes volumiques relatives au trafic de l'entité de service, et une quantification du score de sévérité en le niveau d'alerte en comparant le score de sévérité à des niveaux d'alerte prédéterminés .

Selon une deuxième réalisation, le niveau d'alerte dépend également de paramètres d'évaluation évalués antérieurement à la date d'évaluation courante. L'étape de déterminer un niveau d'alerte pour au moins une entité de service comprend alors en outre une détermination d'un score global en fonction de scores de sévérité de ladite au moins une entité de service résultant d'évaluations dans une fenêtre temporelle immédiatement antérieure à la date d'évaluation courante, et une quantification du score global en le niveau d'alerte en comparant le score global à des deuxièmes niveaux d'alerte prédéterminés .

Le procédé d'établissement d'alertes selon l'invention peut comprendre une détection statique d'anomalies et/ou une détection dynamique d'anomalies dans le trafic de chaque entité de service, préalablement à l'étape de déterminer un niveau d'alerte pour au moins une entité de service. Ainsi l'invention peut mettre avantageusement en commun et synthétiser des alertes de deux types différents, à savoir des alertes par détection statique d'anomalies comportementales et des alertes par détection dynamique d'anomalies comportementales. L'invention contribue ainsi à détecter et caractériser une attaque de type déni de service par inondation afin de protéger des entités de service d'un opérateur ou des terminaux de ses clients par exemple, ce qui évite la surcharge d'un superviseur humain par un trop grand nombre d'événements à traiter. La détection de ces attaques est cruciale dans la lutte contre la cyber-criminalité dont elles sont une composante couramment utilisée. L'alerte agrégée selon l'invention corrèle les alertes de la détection statique et les alertes de la détection dynamique et est alors de meilleure qualité qu'une seule alerte statique ou qu'une seule alerte dynamique.

Selon une réalisation préférée, la détection statique d'anomalies peut inclure une modélisation de l'activité normale de l'entité de service pour fournir au moins un modèle pour une composante volumique du trafic de l'entité de service, chaque modèle comprenant une période de validité, des valeurs statistiques relatives à ladite composante volumique pendant ladite période de validité et un seuil de conformité dépendant des valeurs statistiques, et pour au moins une évaluation de composante volumique à une date ultérieure à la modélisation, une détermination d'une grandeur d'alerte statique, en tant que paramètre d'évaluation, relative à une déviation de la composante volumique évaluée par rapport au modèle relatif à la composante volumique et ayant une période de validité incluant sensiblement la date de l'évaluation, et une détermination d'une valeur d'alerte statique en fonction de la déviation d'au moins une composante volumique pour signaler une alerte statique représentative d'une activité anormale dans le trafic de l'entité de service et continuer par l'étape de déterminer un niveau d'alerte.

Selon une réalisation préférée, la détection dynamique d'anomalies peut inclure une modélisation de l'activité normale de l'entité de service pour fournir des modèles pour des composantes volumiques du trafic de l'entité de service évaluées périodiquement pendant une durée prédéterminée, un modèle relatif à une composante volumique comprenant des coefficients de déviation évalués en fonction d'une moyenne mobile de la composante volumique évaluée pendant la durée prédéterminée, et pour au moins une évaluation ultérieure de coefficients de déviation relatifs aux composantes volumiques, une incrémentation d'au moins une grandeur d'alerte dynamique respective, en tant que paramètre d'évaluation, pour au moins un coefficient de déviation si une nouvelle valeur du coefficient de déviation est supérieure à une valeur de seuil respective incluse dans le modèle, et une détermination d'une valeur d'alerte dynamique en fonction de la grandeur d'alerte dynamique d'au moins une composante volumique pour signaler une alerte dynamique représentative d'une activité anormale dans le trafic de l'entité de service et continuer par l'étape de déterminer un niveau d'alerte.

Le niveau d'alerte peut dépendre de la plus grande valeur de grandeurs d'alerte statique déterminées au cours de la détection statique pour l'entité de service, et de la plus grande valeur de grandeurs d'alerte dynamique déterminées au cours de la détection dynamique pour l'entité de service.

L'invention concerne également un système pour établir des alertes par évaluations périodiques de paramètres d'évaluation relatifs au trafic d'au moins une entité de service. Le système est caractérisé en ce qu'il comprend pour chaque évaluation : un moyen pour déterminer pour au moins une entité de service un niveau d'alerte dépendant de la valeur d'au moins un paramètre d'évaluation relatif au trafic de l'entité de service afin de constituer une alerte globale incluant les paramètres d'évaluation et une date d'évaluation courante lorsque le niveau d'alerte excède un seuil minimal, un moyen pour agréger les alertes globales des entités de service associées à la date d'évaluation courante en une alerte agrégée courante et sélectionner des alertes agrégées antérieures, un moyen pour déterminer des distances de similarité entre l'alerte agrégée courante et lesdites alertes agrégées antérieures en fonction d'au moins l'un des paramètres d'évaluation relatifs à des entités de service qui sont communes à l'alerte agrégée courante et à chaque alerte agrégée antérieure, et un moyen pour fusionner des identifiants des alertes agrégées séparées par la plus petite distance si celle-ci est inférieure à un seuil de similarité, et un moyen pour attribuer un identifiant à l'alerte agrégée courante si la plus petite distance est supérieure au seuil de similarité.

Enfin, l'invention se rapporte à un programme d'ordinateur apte à être mis en œuvre dans un système d'établissement d'alertes selon l'invention. Le programme comprend des instructions qui, lorsque le programme est chargé et exécuté dans ledit dispositif, réalisent les étapes du procédé d'établissement d'alertes selon 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 préférées de l'invention, données à titre d'exemples non limitatifs, en référence aux dessins annexés correspondants dans lesquels :

- la figure 1 est un bloc-diagramme schématique d'un système d'établissement d'alertes selon l'invention, par détection d'anomalies statique et dynamique dans le trafic relatif à au moins une entité de service;

- la figure 2 est un bloc-diagramme schématique d'un dispositif de détection d'anomalies statique inclus dans le système d'établissement d'alertes;

- la figure 3 est un algorithme d'un procédé de détection d'anomalies mis en œuvre dans le dispositif de détection d'anomalies statique;

- la figure 4 est un bloc-diagramme schématique d'un dispositif de détection d'anomalies dynamique inclus dans le système d'établissement d'alertes;

- la figure 5 est un algorithme d'un procédé de détection d'anomalies mis en œuvre dans le dispositif de détection d'anomalies dynamique; et la figure 6 est un algorithme du procédé d'établissement d'alertes selon l'invention.

Comme montré à la figure 1, le système d'établissement d'alertes SA selon l'invention comprend au moins un dispositif de détection d'anomalies statique DDs qui donne des alertes de détection statique et/ou au moins un dispositif de détection d'anomalies dynamique DDd qui donne des alertes de détection dynamique, un dispositif d'établissement d'alertes DEA concernant plus particulièrement l'invention, et une interface homme - machine de management IHM locale ou éloignée. Par conséquent, le dispositif DEA s ' interface avec un ou plusieurs dispositifs de détection d'anomalies statique et/ou un ou plusieurs dispositifs de détection d'anomalies dynamique. L'interface homme - machine IHM inclut notamment un clavier et un écran, pour activer le dispositif automatiquement ou manuellement par un opérateur et saisir notamment des identificateurs et caractéristiques d'entité de service, sélectionner des données pour la détection et lire des alertes . Le système SA peut être autonome sous la forme d'un ordinateur ou d'une station de travail, ou d'un système informatique local ou réparti et être activé automatiquement ou par un opérateur.

Le système SA est inclus dans une sonde de mesure de trafic et fait office d'agent essentiellement logiciel pour inhiber des attaques contre des entités de service SE dans un réseau de télécommunications par paquets à débit élevé RT géré par un opérateur selon le protocole IP ("Internet Protocol") . Des données sont transmises dans une liaison de transmission LT du réseau RT constituant une partie de l' internet. Les données sont par exemple contenues dans des paquets transmis par des terminaux de client TC et destinées aux entités de service SE comprenant des serveurs web. La liaison de transmission LT est située à proximité des entités de service SE dont le trafic est à surveiller par la sonde afin que celle-ci détecte des anomalies dans le trafic qui caractérisent des comportements anormaux des clients des entités de service, particulièrement des attaques par inondation des entités de service.

Par exemple, la liaison de transmission LT à laquelle le système SA est connecté en écoute selon la figure 1, est située dans le réseau RT au point d'entrée d'une ou plusieurs entités de service sur le réseau, entre le réseau RT et le dernier routeur RO de l'opérateur du réseau RT précédant un routeur relié à une entité de service SE. Le système n'est pas connecté à une liaison du client entre le routeur RO et l'entité de service SE dont le trafic pourrait être déjà congestionné à cause de la capacité limitée de la liaison du client.

En variante, le système est connecté en coupure à la liaison de transmission LT de manière également à retirer des paquets anormaux destinés à une ou plusieurs entités de service surveillées.

Le système d'établissement d'alertes SA signale une alerte à partir de l'observation du trafic relatif à l'entité ou les entités de service dans la liaison LT afin que l'opérateur prenne des mesures adéquates pour contrer une attaque dirigée vers l'entité ou les entités de service.

Dans la réalisation décrite ci-après montrée à la figure 1, le système SA est supposé comprendre un dispositif de détection d'anomalies dynamique DDs et un dispositif de détection d'anomalies dynamique DDd pour détecter des anomalies dans le trafic d'une entité de service à protéger SE. Les dispositifs de détection DDs et DDd évaluent des composantes volumiques qui, dans le cadre de l'invention, peuvent porter sur le trafic à destination de l'entité de service à protéger, ou sur le trafic provenant de cette entité de service, ou sur ces deux trafics à la fois .

Quelle que soit l ' implémentation du système SA, il émet des alertes à partir de l'écoute du trafic en au moins un point appartenant préférablement au réseau RT.

Dans une réalisation plus générale, le système d'établissement d'alertes comprend plusieurs dispositifs de détection d'anomalies statique identiques ou différents et/ou plusieurs dispositifs de détection d'anomalies dynamique identiques ou différents qui sont répartis en plusieurs emplacements de préférence dans le réseau RT, par exemple au cœur du réseau, au niveau de routeurs du réseau et à la périphérie du réseau afin de tracer une attaque d'une ou plusieurs entités de service.

Comme montré à la figure 2, le dispositif de détection statique DDs comprend les modules suivants : un module de déclaration d'entité de service DECs pour sélectionner une partie du trafic à surveiller dans la liaison LT qui est destinée à des entités de service SE à protéger; un module de médiation MEDs connecté en écoute selon la figure 2, ou en coupure en variante, à la liaison de transmission LT afin d'évaluer des composantes volumiques de trafic; un module de modélisation MODs qui construit des modèles d'activité normale pour les entités de service à protéger en fonction de valeurs de composantes volumiques de trafic évaluées par le module de médiation MEDs afin de produire des modèles de comportement statique pour chaque entité de service protégée et pour chaque composante volumique; une base de données DBs pour enregistrer des modèles relatifs aux composantes volumiques des entités de service; un module expert EXPs pour introduire des connaissances expertes sur les modèles relatifs à chaque entité de service; un module de détection d'anomalies DETs détectant des anomalies dans le trafic observé destiné aux entités de service à protéger, anomalies qui sont décelées sous forme de déviations anormales de composantes volumiques de trafic évaluées par le module de médiation MEDs par rapport à des modèles d'activité normale; et un module d'alerte ALEs délivrant des alertes statiques suite à des déviations anormales de composantes volumiques .

La détection statique d'anomalies de trafic est mise en œuvre dans le dispositif de détection DDs et comprend trois étapes principales EIs, E2s et E3s, comme montré à la figure 3. Les étapes EIs, E2s et E3s comprennent respectivement des sous-étapes ElOs à El2s, E20s à E29s et E30s à E35s. Des sous-étapes sont également indiquées dans la figure 2 au niveau de liens entre des modules du dispositif de détection DDS intervenant pour l'exécution de ces sous-étapes.

La première étape EIs comporte une déclaration des entités de service SE à protéger explicitement par l'opérateur, ce qui définit un ensemble de services à protéger dispensés par ces entités.

La deuxième étape E2s modélise l'activité statique des entités de service SE à protéger. Elle construit des modèles de comportement qui reflète une activité normale des entités de service suite à une utilisation normale de celles-ci par leurs clients. L'étape E2s considère donc des spécificités de chacune des entités de service à protéger. Des composantes volumiques prédéterminées pour la détection d'anomalies sont prédéterminées pour chaque entité de service à protéger. Puis, l'activité normale de chaque entité de service est modélisée selon les composantes volumiques prédéterminées qui sont évaluées en dépendance du trafic réel et conservées dans la base DBs . Cette première modélisation considère chaque "évaluation" ou "agrégation d'évaluations" comme un point dans un espace ayant pour dimension le nombre de composantes volumiques considérées pour une entité de service donnée. Puis, l'activité de chaque entité de service est "découpée" en plusieurs modèles temporels pendant lesquels l'activité de l'entité de service est considérée comme stable, et qui sont associés à des clusters (nuages) séparés de points présents dans un espace de dimension P.

La troisième étape E3s détecte une activité anormale dans le trafic surveillé dans la liaison LT relatif aux entités de service. L'étape E3s teste si les évaluations des composantes volumiques de trafic correspondent bien à des modèles. L'étape E3s peut aussi tester si l'apparition des évaluations des composantes volumiques notamment par rapport à un ordre des évaluations dans les modèles et des repères temporels, par exemple exprimées en heure, jour de la semaine et mois, est admissible ou non à l'aide de graphes définissant des transitions admissibles ou non entre deux modèles et de données contenues dans les modèles produits à l'étape de modélisation E2s. L'étape de détection E3s fournit un vecteur d'alerte représentatif de déviations par rapport aux valeurs modélisées .

A la première sous-étape ElOs de l'étape de déclaration d'entité de service EIs, l'opérateur définit des entités de service SE qu'il souhaite protéger dans le module de déclaration DECs via l'interface homme - machine IHM. Le module DECs sélectionne ainsi une partie du trafic dans la liaison LT qui est destinée à chaque entité de service déclarée. L'opérateur définit explicitement des entités de service en saisissant des identificateurs et des caractéristiques des entités de service à protéger transmis au module DECs, ou bien en saisissant des identificateurs des entités de service transmis au module DECs qui lit des caractéristiques des entités de service sélectionnées en correspondance aux identificateurs des entités dans une liste préenregistrée dans une base en relation avec la liaison LT. Les caractéristiques identifiant une entité de service sont par exemple des triplets . Typiquement le triplet de caractéristiques d'une entité de service inclut une adresse de destination ou classe d'adresse de destination IP, un protocole de transport et un port. Les identificateurs ISE d'entités de service SE peuvent aussi être spécialisés, par exemple être les triplets de caractéristiques eux-mêmes.

Par exemple, une entité de service déclarée a pour triplet de caractéristiques (adresse de destination IP, protocole (s) de transport T, port (s)

P) : une adresse de destination IP qui est au format 'w.x.y.z/m', avec w, x, y et z compris entre 0 et 255, et m compris entre 0 et 32, et éventuellement affectée d'un masque selon la notation CIDR (Classless Internet Domain Routing) ; par exemple: 159.151.254.0/25 signifie de l'adresse 159.151.254.0 à l'adresse 159.151.254.127 puisque 2³² - 2²⁵ - 1 = 127; une liste de protocoles de transport qui est au format ^fpl;p2' avec pi, p2, ... des valeurs en nombre fini prises dans des mots-clés tels que 'tcp', 'udp', ' ip ' , 'icmp', la valeur 'ip' recouvrant à la fois 'tcp' et 'udp'; et une liste de ports qui est au format ^fpl;p2;p3- p4 ' avec pi, p2, p3, p4, ... des valeurs entières comprises entre 0 et 65535 et pouvant être incluses dans une plage de valeurs entières, par exemple '3200-3299', ou dans une liste de valeurs entières, par exemple '3200; 3202; 3208'.

Des entités de service "complémentaires" peuvent être implicitement déclarées à la suite de la déclaration explicite des entités de service à protéger. Une entité de service complémentaire implicite peut être une entité de service déclarée par défaut afin de recouvrir des attaques sur des protocoles spécifiques, comme les trafics indésirables selon le protocole de paquet de commande 'icmp' (Internet Control Message Protocol). Une entité de service complémentaire implicite peut être construite comme un complément à au moins une entité de service déclarée ayant une adresse IP, et relative à des trafics autres que ceux qui concernent des services hébergés par l'entité de service déclarée mais ayant ladite adresse IP et par exemple des ports différents .

Les entités de service "complémentaires" sont inférées automatiquement des caractéristiques des entités de service déclarées pour synthétiser l'activité de la liaison LT du réseau qui n'est pas explicitement déclarée par l'opérateur. Les entités de service complémentaires à protéger ont des triplets de caractéristiques (adresse de destination IP, protocole (s) de transport T, tous ports sauf P) et (adresse de destination IP, protocole (s) de transport sauf T, port (s) P) .

En variante, à une étape ElOas pouvant être conjointe à l'étape ElOs ou la remplacer pour certaines entités de service, la déclaration d'entités de service est automatique grâce à une écoute du trafic dans la liaison LT par le module de déclaration DECs. Dans cette variante, le module DECs est connecté en écoute selon la figure 2. Le module DECs établit une liste des entités de service demandées par les paquets qui passent dans la liaison LT et classe ces entités de service par fréquence d'apparition des paquets destinés à ces entités, afin d'obtenir une pré-liste des entités de service. Ensuite, cette liste est réduite automatiquement afin par exemple de ne conserver en mémoire du module DECs que les entités de service demandées par plus de 1% des paquets, ou bien est modifiée par l'opérateur. La liste ainsi établie est la liste des entités de service à protéger.

Après l'étape ElOs ou ElOas, les entités de service à protéger par le dispositif DDs sont bien identifiées .

Le module de modélisation MODs est initialisé en recevant la liste des identificateurs ISE des entités de service SE à protéger fournie par le module de déclaration DECs. Le module MODs reçoit la liste automatiquement à la sous-étape Elis, ou en variante après validation de l'opérateur via l'interface IHM à la sous-étape Elias.

A chaque entité de service à protéger, le module de modélisation MODs associe des paramètres de trafic par défaut qui sont une granularité fixée g et une liste par défaut de composantes volumiques de trafic à destination, et/ou éventuellement en provenance, de l'entité de service SE.

La granularité définit une période d'évaluation du trafic de l'entité de service et peut être une valeur par défaut dépendant d'une caractéristique de l'entité de service. Par exemple, la granularité est 10 secondes si le port P de l'entité de service est 80 (HTTP) , ou 1 minute si le port est 23 (Telnet) .

Les composantes volumiques de trafic dans la liste par défaut correspondent à des caractéristiques pouvant être relevées à partir d'informations des couches de réseau et de transport et agrégées sous forme de comptes de compteurs remis à zéro à chaque période d'évaluation de trafic définie par la granularité. Les composantes volumiques sont par exemple : au niveau de la couche de réseau IP : la volumétrie exprimée par un débit de trafic en octets par seconde, la volubilité exprimée par un débit de trafic en paquets par seconde, la connexité exprimée par un nombre d'adresses de source différentes dans des paquets destinés à l'entité de service, et la fragmentation exprimée par un taux de paquets à destination et/ou en provenance de l'entité de service SE et fragmentés en fonction des bits DF et MF dans le champ drapeau de l'entête d'un paquet IP; et au niveau de la couche de transport TCP ("Transmission Control Protocol", mots anglais signifiant "Protocole de Commande de Transmission") : l'ouverture de connexion exprimée par un taux de paquets incluant un bit de contrôle SYN à "1", le "stress" exprimé par un taux de paquets incluant un bit de contrôle PUSH à "1" indiquant que les données sont à transférer à la couche supérieure, l'urgence exprimée par un taux de paquets incluant un bit de contrôle de message urgent URG à "1", et la volatilité exprimée par un nombre de ports différents sollicités.

A la liste par défaut de composantes volumiques de trafic peut être ajoutée une liste d'autres composantes volumiques spécifiques qui dépendent de l'entité de service, comme des grandeurs propres à un protocole applicatif utilisé. Par exemple une composante volumique à évaluer sur un service HTTP (HyperText Transfer Protocol) est le nombre de requêtes sur une méthode spécifique, comme la méthode 'GET', le nombre de requêtes vers des pages CGI (Common Gateway Interface) , PHP (Personal Home Page) , JSP (Java Server Page), ou un code d'erreur de type 2xx, 3xx, 4xx ou 5xx renvoyé par le serveur impliquant une mesure du trafic retour, ou la version du protocole utilisée (0.9, 1.0, 1.1).

Cependant à la sous-étape Elias, via l'interface IHM, l'opérateur peut modifier manuellement la liste de composantes volumiques ainsi que tout autre paramètre de trafic qui a pris une valeur par défaut, comme la granularité.

A la sous-étape El2s, le module MODs transmet une liste des entités de service, éventuellement après validation de l'opérateur, au module de médiation MEDs du dispositif DDs. Pour l'activité normale de chaque entité de service à protéger que le module MODs doit modéliser, la liste d'entités de service comprend l'identificateur ISE et les caractéristiques de l'entité de service SE et les composantes volumiques de trafic nécessaires à la modélisation afin qu'à partir de ces composantes volumiques, le module MODs produise un modèle de comportement statique de l'entité de service. Au début E20s de l'étape de modélisation d'activité d'entité de service E2s, le module de médiation MEDs extrait de chaque paquet pertinent capturé dans la liaison LT et destiné à une entité de service identifiée à protéger, notamment l'adresse de source IP, l'adresse de destination IP, la valeur du champ de protocole de transport, le port source, le port destination, la longueur totale du paquet en octets, le champ drapeau avec les bits de fragmentation, et la liste des drapeaux TCP, afin d'évaluer les composantes volumiques .

Pour chaque entité de service, le module MEDs comprend des compteurs COMs qui respectivement comptent par exemple des octets, des paquets, des adresses de source prédéterminées et des bits de contrôle prédéterminés pour exprimer les composantes volumiques, et qui sont ainsi assignés à l'évaluation des composantes volumiques de l'entité de service. Les compteurs sont réinitialisés régulièrement à la période d'évaluation selon la granularité, par exemple de l'ordre de quelques secondes, typiquement 10 secondes. Chaque évaluation des composantes volumiques est horodatée avec la date t de début de la période. Au cours de la sous-étape E20s et à l'expiration de chaque période d'évaluation, les comptes des compteurs constituent des valeurs des composantes volumiques de trafic demandées qui sont agrégées, formatées et fournies par le module MEDs au module MODs .

Les composantes volumiques fournies par le module MEDs sont conservées temporairement dans une base d'évaluations incluse dans le module MODs. Pour l'entité de service donnée, le module MODs traite une suite d'ensembles de valeurs de composantes volumiques qui ont été évaluées pendant une durée prédéterminée qui est très supérieure à la période d'évaluation de granularité retenue pour l'agrégation des composantes volumiques, ou bien définie par l'opérateur. En particulier, les modèles étant établis avec une période de validité de l'ordre de l'heure dans la journée, voire de la journée dans le mois, la durée prédéterminée pour relever les composantes volumiques est comprise entre une semaine et au moins un mois. L'ensemble des durées prédéterminées pendant lesquelles les comptes des compteurs COMs sont lus et fournis au module MODs pour effectuer la première modélisation lors de la mise en marche du dispositif de détection DDS s'appelle phase d'apprentissage. A partir de ces composantes volumiques évaluées pendant la phase d'apprentissage pour les entités de service à protéger, le module MODs produit des modèles de comportement statique de chaque entité de service protégée, comme expliqué ci-après.

Pour modéliser le comportement du trafic à destination de l'entité de service donnée SE et ainsi l'activité normale de celle-ci, le module MODs détermine récursivement des points de rupture dans la suite d'ensembles de composantes volumiques pendant la phase d'apprentissage, afin de déterminer des périodes d'activité stable appelées clusters, à la sous-étape E21s. Pour chaque entité de service, le module de modélisation MODs définit des périodes d'activité stable sur lesquelles les clusters s ' étendent .

Par exemple, la modélisation est fondée sur une approche hybride reposant à la fois sur une définition a priori et une définition a posteriori de la période de comportement des clusters . Les composantes volumiques évaluées sont d'abord regroupées a priori en clusters distincts en fonction de leur jour de semaine. Puis pour chaque jour de la semaine, une analyse par partitionnement découvre les périodes d'activité distinctes, avec une limite élevée sur le nombre de clusters ainsi découverts qui sont suffisamment distincts les uns des autres. Cette limite découle de la finesse de modélisation souhaitée. Ainsi, le nombre de clusters possibles dans un jour peut être limité à un nombre minimum, et/ou la durée de chaque cluster au niveau temporel peut être limitée à une durée minimum.

La récursivité de la modélisation comprend par exemple un centrage - réduction de chacune x des composantes volumiques évaluées dans le cluster initial d'une journée en déterminant des valeurs statistiques de la composante volumique, comme la moyenne des valeurs évaluées de la composante volumique et l'écart-type de la composante volumique, et en remplaçant chaque valeur de la composante volumique par un rapport d'évaluation de la différence entre ladite valeur et la moyenne sur l'écart-type afin que la moyenne des rapports relatifs à la composante volumique soit nulle et leur écart-type soit égal à 1. Des distances euclidiennes entre des rapports de deux évaluations pour toutes les composantes volumiques sont déterminées .

Puis de manière récursive, le cluster initial est partitionné en des clusters dont le plus hétérogène est partitionné en d'autres clusters, et ainsi de suite. Pour chaque cluster à partitionner, des fonctions signées sont évaluées chacune égale à une somme des rapports pour toutes les composantes volumiques relatives aux évaluations incluses dans le cluster. Chaque changement de signe dans la série chronologique des fonctions signées relatives aux évaluations incluses dans le cluster est caractérisé par un produit des fonctions signées relatives à deux évaluations successives qui est négatif. Le changement de signe indique une séparation rompant la série entre la fin d'un nouveau cluster et le début d'un nouveau cluster suivant dans le cluster à partitionner. Pour chaque nouveau cluster, une hétérogénéité est estimée égale à la somme des carrés des distances euclidiennes entre le centre de ce nouveau cluster et les rapports relatifs à toutes les composantes volumiques et aux évaluations dans ce nouveau cluster. Le cluster ayant l'hétérogénéité la plus élevée est alors sélectionné pour être partitionné en des clusters afin d'y sélectionner comme précédemment le cluster le plus hétérogène, jusqu'à ce que l'hétérogénéité d'un cluster sélectionné soit inférieure à un seuil d'hétérogénéité prédéterminé.

Le module MODs produit un ensemble de clusters qui comprennent des ensembles de composantes volumiques évaluées consécutivement ayant une hétérogénéité admissible. La reconnaissance préliminaire des comportements stables sépare ainsi le cluster initial des valeurs des composantes volumiques évaluées en phase d'apprentissage en des clusters les plus homogènes possibles. Chaque cluster correspond à une période de validité incluse dans une période prédéterminée telle qu'une journée. En conséquence, pour une phase d'apprentissage sur plusieurs semaines, chaque journée dispose d'un ensemble de clusters .

A la sous-étape E22s, pour chacun des clusters ainsi déterminés et pour chacune x des composantes volumiques, le module MODs calcule des valeurs statistiques, par exemple la moyenne μ_x, l'écart-type σ_x, la population égale au nombre d'évaluations dans le cluster et un seuil de conformité Ssx dépendant des valeurs statistiques précédentes calculées. Le seuil de conformité Ssx pour une composante volumique x est par exemple égal à la somme de la moyenne μ_x de la composante volumique et du produit de l'écart-type σ_x de la composante volumique par la racine carrée du rapport de l'hétérogénéité du cluster à la fin du partitionnement sur le nombre d'évaluations dans le cluster.

Finalement à la sous-étape E23s, le module MODs rassemble chaque cluster et chaque composante volumique x pour produire un modèle de comportement normal qui est une liste comprenant l'identificateur ISE de l'entité de service SE, une période de validité calculée à partir des dates de début et de fin des évaluations qui se trouvent dans le cluster, par exemple le lundi entre 9 h et 10 h 30 ou tous les jours de la semaine de 14 h à 16 h, la granularité dans le cluster, la date de création du modèle, la désignation de la composante volumique x et les valeurs statistiques, comme la moyenne μ_x et l'écart- type O_x, relatives à la composante volumique x dans le cluster, et le seuil de conformité Ssx dépendant des valeurs statistiques précédentes et relatif à la composante volumique. Le cluster est ainsi défini par les données des modèles des différentes composantes volumiques, et les évaluations qui ont présidé à sa création peuvent être effacées dans le module MODs . Les modèles de tous les clusters sont transférés à la base de données DBs qui les enregistre à la sous- étape E24s et/ou au module expert EXPs décrit plus loin à la sous-étape E25s. Le module de modélisation MODs comprend un sous- module d'actualisation de modèles MAMs qui périodiquement lit les modèles anciens courants relatifs à une entité de service donnée dans la base DBs pour fournir des modèles actualisés remplaçant les modèles anciens courants . Ce remplacement de modèles vise à refléter l'évolution potentielle des usages des clients en matière de communication avec les entités de service protégées SE et donc l'évolution du trafic réel dans la liaison LT entre les terminaux TC et les entités de service protégées . La période d'actualisation peut être une durée sensiblement égale à celle de la phase d' apprentissage .

Pour une actualisation de modèles E26s répétant au moins les sous-étapes E20s à E25s, le module MODs produit des modèles actualisés en fonction de valeurs récentes des composantes volumiques associées à l'entité de service, évaluées avec la granularité définie dans lesdits modèles courants et fournies par le module MEDs depuis la dernière actualisation, comme à l'étape E20s. Les valeurs récentes des composantes volumiques évaluées sont d'abord conservées temporairement dans la base d'évaluations, puis épurées de toute valeur ayant conduit à la génération d'une alerte et donc au signalement d'une activité anormale de l'entité de service, en vérifiant que ces valeurs récentes sont conformes aux modèles anciens existants, c'est-à-dire qu'elles ne déclenchent pas d'alerte en leur appliquant une fonction de détection détaillée plus loin.

L'épuration peut cependant être sautée par décision de l'opérateur ou conformément à la définition de différents modes d'actualisation : par exemple un mode "obsolète" pour lequel l'épuration est sautée, et un mode "normal" pour lequel l'épuration est exécutée.

Ensuite, le sous-module MAMs introduit la valeur récemment évaluée de la composante volumique dans l'ensemble des valeurs de la composante volumique de tout modèle associé dont la période de validité inclut sensiblement la date d'évaluation de la valeur récente de la composante volumique. Les valeurs statistiques de la composante volumique, comme la moyenne, la dispersion représentée par l'écart-type et la population, et le seuil de conformité relatifs à la composante volumique associée au modèle sont actualisés par le sous-module MAMs en fonction de la valeur récente de la composante volumique.

De préférence le sous-module d'actualisation de modèles MAMs actualise les valeurs statistiques y compris le seuil de conformité en appliquant une pondération aux valeurs de la composante volumique du modèle ancien courant. La pondération dépend de la population des valeurs de la composante volumique du modèle ancien qui est a priori différente de la population des valeurs de composante volumique récemment évaluées, à cause de l'épuration. Avantageusement, la pondération dans le sous-module MAMs dépend de la date de création du modèle ancien courant pour conférer moins de poids au modèle ancien courant; par exemple, le paramètre de trafic "population" est divisé par un coefficient qui croit avec un âge du modèle ancien courant.

En conséquence le module MODs établit un âge de chaque modèle enregistré exprimé en nombre de jours, en association à l'identificateur ISE de l'entité de service SE, à la période de validité (heures de début et fin d'un jour de la semaine ou du mois) et à un code entier de phase indiquant si le modèle est en cours de construction pendant la phase apprentissage, en cours d'utilisation pour la détection, ou invalide temporairement, ou encore a généré une alerte récente .

Après l'actualisation, les modèles actualisés sont transférés à la base DBs qui les enregistre comme à la sous-étape E24s et/ou au module expert EXPs comme à la sous-étape E25s, pour remplacer et supprimer les modèles anciens courants .

A la fin de chaque modélisation E23s sont éventuellement introduites des connaissances expertes par le module expert EXPs. A une sous-étape E27s succédant à la sous-étape E25s, le module expert EXPs traite les modèles transmis par module MODs après la modélisation et concernant une entité de service ou plusieurs entités de service ayant des caractéristiques communes comme par exemple une adresse IP. Le module EXPs crée, à partir des modèles courants, des schémas de conformité avancés qui sont utilisés conjointement aux modèles dans l'étape de détection E3s.

Par exemple, pour chaque entité de service et chaque granularité, le module EXPs crée un automate dont les sommets du graphe d'admissibilité sont les modèles relatifs à l'entité de service et la granularité et dont les arêtes orientées du graphe d'admissibilité constituent une base de règles. Par exemple une arête entre des états de modèle ETa et ETb est associée à une règle du type "il y a une transition de l'état ETa vers l'état ETb si la période de validité du modèle associé à l'état ETa précède immédiatement la période de validité associée à l'état ETb". A travers l'interface homme - machine IHM, l'opérateur peut modifier l'automate en ajoutant d'autres arêtes. L'automate ainsi obtenu est associé à chaque modèle de l'entité de service pour la granularité et est enregistré dans la base de données DBs à une sous-étape E28s.

Alternativement à la sous-étape E27s, le module EXPs n'est activé que lorsque l'opérateur active le module de détection DETs . Le module EXPs lit alors dans la base DBs les modèles associés aux paramètres de trafic de la détection demandée, et requiert les modifications et la validation du graphe d'admissibilité par l'opérateur, avant d'envoyer les automates associés au module DETs à la sous-étape E29s.

L'étape de détection d'activité anormale E3s comprend des sous-étapes d'initialisation E30s à E32s et des sous-étapes de comparaison aux modèles E33s à E35s.

Le module de détection d'anomalies DETs est activé soit automatiquement après les sous-étapes E24s et E25s de la phase d'apprentissage, c'est-à- dire après la première modélisation, soit par l'opérateur via l'interface homme - machine IHM. A la sous-étape E30s, le module DETs reçoit du module de déclaration DECs et/ou de l'opérateur via l'interface IHM la liste des identificateurs ISE et caractéristiques des entités de service à protéger, et éventuellement la liste des paramètres de trafic, notamment la granularité des évaluations, pour chaque entité de service. Le module DETs lit dans la base de données DBs tous les modèles courants correspondant aux paramètres de trafic, et si pour une entité de service aucune granularité n'est mentionnée, le module DETs appelle dans la base DBs les modèles courants et donc les plus récents pour cette entité de service et lit leurs granularités . Ainsi, le module DETs dispose de la liste des entités de service à protéger et des modèles courants pertinents pour la détection. Le module DETs charge et conserve en mémoire vive tous ces modèles courants .

Pour chaque entité de service SE que le dispositif DDs doit protéger, l'identificateur ISE et les caractéristiques de l'entité de service et les paramètres de trafic de cette entité nécessaires à la détection et contenus dans les modèles sont, après modification et validation éventuelles par l'opérateur, appliqués ensuite par le module DETs au module de médiation MEDs, à la sous-étape E31s.

En réponse aux caractéristiques et paramètres de l'entité de service, le module de médiation MEDs délivre périodiquement au module de détection DETs une évaluation du trafic destiné à l'entité de service, à la sous-étape E32s. Cette évaluation comprend les comptes des compteurs COM qui sont assignés à l'évaluation des composantes volumiques de l'entité de service et qui sont réinitialisés régulièrement à la période d'évaluation selon la granularité demandée pour l'entité de service.

Les composantes volumiques évaluées de l'entité de service ont des valeurs "instantanées" exprimées par les comptes des compteurs respectifs COM qui sont délivrés par le module MEDs pour être traités par le module de détection DETs. Suite à l'évaluation, le module DETs appelle les modèles courants relatifs aux composantes volumiques . Chaque composante volumique peut être associée à au moins un modèle courant d'activité normale transféré de la base BD dans la mémoire vive. Le modèle courant d'activité normale est considéré comme pertinent s'il a une période de validité incluant la date t de l'évaluation des composantes volumiques, avec plus ou moins une fenêtre temporelle, et donc pendant laquelle l'évaluation a été réalisée à la fenêtre temporelle près . La fenêtre temporelle permet de pallier une activité de trafic a priori normale qui intervient de manière sensiblement décalée dans le temps, et ainsi évite des fausses alertes.

A la sous-étape E33s, pour chaque composante volumique x, le module DETs détermine une déviation D_x de l'évaluation par rapport à chaque modèle d'activité courant pertinent. La déviation D_x est par exemple le rapport entre la distance (valeur absolue de la différence) entre la valeur instantanée x de la composante volumique évaluée et sa moyenne μ_x dans le modèle, et la distance (valeur absolue de la différence) entre le seuil de conformité Ss_x dans le modèle et la moyenne μ_x dans le modèle. Le module DETs détermine aussi une déviation globale DG en fonction des déviations pour les composantes volumiques évaluées, par exemple égale à la moyenne quadratique des valeurs des déviations .

Si des connaissances expertes ont été introduites selon la sous-étape E29s, le module DETs bénéficie des connaissances expertes pour réduire le nombre de faux positifs qui devraient conduire à des alertes qui n'en sont pas. Par exemple, lorsqu'un graphe d'admissibilité a été créé par le module expert EXPs comme décrit à la sous-étape E27s, les connaissances expertes dépendent des valeurs statistiques de modèles proches, c'est-à-dire dont la distance dans le graphe audit modèle courant est faible, comme par exemple les modèles séparés du modèle courant par une arête, et dont les périodes de validité sont peu éloignées de la date d'évaluation de la valeur de déviation de la composante volumique associée au modèle courant, afin que les connaissances expertes soient utilisées pour affiner, par exemple diminuer, la valeur de déviation. Pour le calcul du rapport entre les distances pour la valeur de déviation D_x, la valeur du seuil de conformité S_c du modèle peut être par exemple remplacée par le plus grand des seuils de conformité dans les modèles proches dudit modèle courant.

Puis à la sous-étape E34s, pour chaque évaluation, le module DETs regroupe les valeurs de grandeurs physiques d'alerte statique comprenant des déviations D_x des composantes volumiques x et de la déviation globale DG dans un vecteur d'alerte statique VAs qui représente ainsi la similarité plus ou moins prononcée de l'évaluation aux modèles courants pertinents pour cette évaluation. Le vecteur d'alerte statique VAs est délivré au module d'alerte ALEs chargé de la sortie des alertes .

Finalement à la sous-étape E35s, le module d'alerte ALEs décide si le vecteur d'alerte statique VAs doit engendrer une alerte statique ou non. Pour cela, le module ALEs examine ledit vecteur d'alerte statique VAs, et détermine en fonction de ce vecteur d'alerte statique VAs une valeur d'alerte statique globale. Si la valeur d'alerte statique globale excède un niveau d'alerte statique prédéterminé, le module ALEs signale une alerte relative à une activité anormale dans le trafic de l'entité de service SE en transmettant le vecteur d'alerte statique VAs au dispositif d'établissement d'alertes DEA. Le vecteur d'alerte statique VAs transmis est accompagné de l'identificateur ISE de l'entité de service SE, des valeurs des composantes volumiques x de l'évaluation courante qui a déclenché l'alerte, de la date t de l'évaluation, des seuils de conformité pertinents au moment de l'évaluation, et d'un type d'alerte dépendant des valeurs des déviations et des déviations globales des composantes volumiques afin que toutes ces données soient affichées dans 1 ' interface homme - machine de management IHM à la demande de l'opérateur.

Si la valeur d'alerte statique globale est inférieure au niveau d'alerte statique prédéterminé, le module d'alerte ALEs met à zéro les deux grandeurs d'alerte statique dans le vecteur d'alerte statique VAs transmis au dispositif DEA ce qui signifie que le trafic pour l'entité de service SE est normal et donc qu'il n'y a aucune alerte statique.

Comme montré à la figure 4, le dispositif de détection dynamique DDd comprend les modules suivants : un module de déclaration d'entité de service DECd pour sélectionner une partie du trafic à surveiller dans la liaison LT qui est destinée à des entités de service SE à protéger; un module de médiation MEDd connecté en écoute selon la figure 4, ou en coupure en variante, à la liaison de transmission LT afin d'évaluer des composantes volumiques de trafic; un module de modélisation MODd qui construit des modèles d'activité normale pour les entités de service à protéger en fonction de valeurs de composantes volumiques de trafic évaluées par le module de médiation MEDd afin de produire des modèles de comportement dynamique pour chaque entité de service protégée et pour chaque composante volumique; une base de données DBd pour enregistrer des modèles relatifs aux composantes volumiques des entités de service; un module de détection d'anomalies DETd détectant des anomalies dans le trafic observé destiné aux entités de service à protéger, anomalies qui sont décelées sous forme de franchissements anormaux de valeurs de seuil des modèles d'activité normale par des coefficients de déviation évalués en fonction des composantes volumiques; et un module d'alerte ALEd délivrant des alertes dynamiques suite à des franchissements anormaux des coefficients de déviation.

Bien que les dispositifs de détection DDs et DDd, qui présentent des agencements analogues des modules, soient montrés séparément dans la figure 1, au moins les modules de déclaration d'entité de service DECs et DECd, les modules de médiation MEDs et MEDd et les bases de données DBs et DBd sont préférablement réunis deux à deux respectivement dans une réalisation plus concise du système d'établissement d'alertes SA de l'invention.

La détection dynamique d'anomalies de trafic est mise en œuvre dans le dispositif de détection DDd et comprend trois étapes principales EId, E2d et E3d, comme montré à la figure 5. Les étapes EId, E2d et E3d comprennent respectivement des sous-étapes ElOd à El2d, E20d à E26d et E30d à E35d. Des sous-étapes sont également indiquées dans la figure 4 au niveau de liens entre des modules du dispositif de détection DD intervenant pour l'exécution de ces sous-étapes.

La première étape EId comporte une déclaration des entités de service SE à protéger explicitement par l'opérateur, ce qui définit un ensemble de services à protéger dispensés par ces entités.

A la première sous-étape ElOd de l'étape de déclaration d'entité de service EId, l'opérateur définit des entités de service SE qu'il souhaite protéger dans le module de déclaration DECd via l'interface homme - machine IHM. Le module DECd sélectionne ainsi une partie du trafic dans la liaison LT qui est destinée à chaque entité de service déclarée.

L'opérateur définit explicitement des entités de service pour une détection dynamique d'anomalies dans leurs trafics, comme il l'a défini pour une détection statique d'anomalies dans les trafics de ces entités. Il est également prévu en variante, à une étape ElOad pouvant être conjointe à l'étape ElOd ou la remplacer pour certaines entités de service, que la déclaration d'entités de service soit automatique grâce à une écoute du trafic dans la liaison LT par le module de déclaration DECd. Dans cette variante, le module DECd est connecté en écoute selon la figure 4. Le module DECd établit une liste des entités de service comme le module DECs à l'étape ElOas.

Après l'étape ElOd ou ElOad, les entités de service à protéger par le dispositif DDd sont bien identifiées .

Le module de modélisation MODd est initialisé en recevant la liste des identificateurs ISE des entités de service SE à protéger fournie par le module de déclaration DECd. Le module MODd reçoit la liste automatiquement à la sous-étape ElId, ou en variante après validation de l'opérateur via l'interface IHM à la sous-étape Ellad.

A chaque entité de service à protéger, le module de modélisation MODd associe, comme dans le module de modélisation MODs, des paramètres de trafic par défaut qui sont la granularité fixée g et la liste par défaut de composantes volumiques de trafic à destination, et/ou éventuellement en provenance, de l'entité de service SE.

Pour chacune x des composantes volumiques de trafic dans la liste par défaut, un seuil Sd_x, que ne doit pas dépasser la composante volumique, et un plancher P_x, au-dessous duquel les évaluations des composantes volumiques sont considérées comme non pertinentes, sont définis a priori par l'opérateur ou bien par défaut suivant les capacités des entités de service protégées .

A la liste par défaut de composantes volumiques de trafic peut être ajoutée la liste des autres composantes volumiques spécifiques qui dépendent de l'entité de service, comme des grandeurs propres à un protocole applicatif utilisé.

Cependant à la sous-étape Ellad, via l'interface IHM, l'opérateur peut modifier manuellement la liste de composantes volumiques ainsi que tout autre paramètre de trafic qui a pris une valeur par défaut, comme la granularité.

A la sous-étape El2d, le module MODd transmet une liste des entités de service, éventuellement après validation de l'opérateur, au module de médiation MEDd du dispositif DDd. Pour l'activité normale de chaque entité de service à protéger que le module MODd doit modéliser, la liste d'entités de service comprend l'identificateur ISE et les caractéristiques de l'entité de service SE et les composantes volumiques de trafic nécessaires à la modélisation afin qu'à partir de ces composantes volumiques, le module MODd produise un modèle de comportement dynamique de l'entité de service.

Au début E20d de l'étape de modélisation d'activité d'entité de service E2d, le module de médiation MEDd extrait de chaque paquet pertinent capturé dans la liaison LT et destiné à une entité de service identifiée à protéger, notamment l'adresse de source IP, l'adresse de destination IP, la valeur du champ de protocole de transport, le port source, le port destination, la longueur totale du paquet en octets, le champ drapeau avec les bits de fragmentation, et la liste des drapeaux TCP, afin d'évaluer les composantes volumiques .

Pour chaque entité de service, le module MEDd comprend, comme le module MEDs, des compteurs COMd qui respectivement comptent par exemple des octets, paquets, adresses de source prédéterminées et bits de contrôle prédéterminés pour exprimer les composantes volumiques et qui sont ainsi assignés à l'évaluation des composantes volumiques de l'entité de service. Au cours de la sous-étape E20d, les compteurs COMd comptent respectivement comme les compteurs COMs au cours de la sous-étape E20s.

Les composantes volumiques fournies par le module MEDd sont conservées temporairement dans une base d'évaluations incluse dans le module MODd. Pour l'entité de service donnée SE, le module MODd traite une suite d'ensembles de valeurs de composantes volumiques qui ont été évaluées pendant une durée prédéterminée qui est très supérieure à la période d'évaluation de granularité retenue pour l'agrégation des composantes volumiques, ou bien définie par l'opérateur. En particulier, pour l'entité de service donnée, les modèles dépendent de valeurs des composantes volumiques qui sont établies consécutivement au cours d'une durée prédéterminée propre à l'entité de service, pendant laquelle l'entité de service passe par tous les comportements d'activité normale que l'entité de service aura lors de la phase de détection. Par conséquent, compte tenu des variations de l'activité des terminaux de client TC, la durée prédéterminée est par exemple au moins une semaine ou un mois et est définie par l'opérateur. La modélisation dynamique selon l'invention ne détermine pas ainsi des périodes d'activité stable divisant une longue durée de fonctionnement de l'entité de service protégée. La durée prédéterminée pendant laquelle les comptes des compteurs COMd sont lus et fournis au module MODd pour effectuer la première modélisation relativement à plusieurs entités de service à protéger supposées en activité normale après la mise en marche du dispositif de détection DDd constitue une phase d'apprentissage. A partir de ces composantes volumiques évaluées pendant la phase d'apprentissage pour les entités de service à protéger, le module MODd produit des modèles de comportement dynamique de chaque entité de service protégée, comme expliqué ci- après .

Pour modéliser le comportement du trafic à destination de l'entité de service donnée SE et ainsi l'activité normale de celle-ci en des modèles, le module MODd évalue des coefficients de comportement dynamique admissibles appelés coefficients de déviation CD utilisés par la suite pour la détection dynamique d'anomalies par comparaison.

A cette fin, à la sous-étape E21d le module de modélisation MOD évalue en temps réel plusieurs variables à partir des évaluations des composantes volumiques . Pour chaque composante volumique surveillée x relative à l'entité de service donnée, le module MODd actualise une ou plusieurs moyennes mobiles à pondération exponentielle pendant la durée prédéterminée en fonction d'un ou plusieurs coefficients de moyenne choisis.

On considère la valeur M_n calculée par récurrence à partir de valeurs xo à x_n de la manière suivante :

M_n = xo, et pour n > 0: M_n = C x_n + (l - C) M_n_i , où C est une constante judicieusement choisie. On dit alors que M_n est la "moyenne mobile à pondération exponentielle", à coefficient de pondération C, des valeurs xo à x_n.

On choisit C = 2/ (1+c) e [0, 1], où c est un coefficient de moyenne, par exemple choisi préalablement par défaut pour un modèle dans une liste de coefficients de moyenne {1, 3, 9, 27} dont dispose le module MODd et qui peut être modifiée par 1 ' opérateur.

On montre que la moyenne Mj avec I ≥ n+1 ne dépend que des I-n moyennes évaluations précédentes selon la relation :

Mi = £ C (1 - C)^1"1 Xi + (1 - C)^1"11 M_n i=n+l

si les coefficients (1 - C) pour k ≥ I-n sont négligeables .

La moyenne mobile Mj dépend ainsi mathématiquement des I-n dernières évaluations, c'est-à-dire "a une mémoire" de I-n évaluations, bien que son actualisation par le module MOD ne nécessite, outre l'ancienne valeur Mj-i de la moyenne, que la mémorisation de la valeur de la dernière évaluation de la composante volumique xi .

Le module MODd actualise une moyenne à pondération exponentielle MM_n des valeurs Mi à M_n de la moyenne mobile de la même manière selon la formule :

MM_n = C M_n + (1 - C)MM_n-I.

Outre la moyenne mobile à pondération exponentielle et la moyenne de la moyenne mobile, le module MODd détermine aussi d'autres variables parmi lesquelles une "dérivée première" discrète de composante volumique d_n = C (x_n - M_n-i) proportionnelle à la différence de la nouvelle valeur de la composante volumique et de la moyenne mobile courante M_n-I, une "dérivée seconde" discrète de composante volumique dd_n = d_n - d_n-i égale à la différence de la nouvelle valeur de la dérivée première d_n et de la valeur courante de la dérivée première d_n-i, une moyenne mobile à pondération

2 2 exponentielle des carrés xo à x_n des valeurs de la

2 composante volumique N_n = C X_n + (1 - C)N_n-I , et une déviation mobile SD_n égale à la racine carrée de la valeur absolue N_n - M_n I de la différence de la moyenne mobile des carrés et du carré de la moyenne mobile. Cette déviation est strictement positive dès qu'au moins une valeur non nulle de la composante volumique a été observée. En particulier un mécanisme de plancher décrit plus loin assure que tous les calculs faisant intervenir ladite déviation mobile ne sont effectués que lorsque ladite déviation mobile est strictement positive.

En fonction des valeurs de ces variables courantes (M_n-I, MM_n-I, d_n-i, dd_n-i, N_n_i, SD_n-I) déterminées à l'évaluation courante précédente n-1 de la composante volumique et (M_n, MM_n, d_n, dd_n, N_n, SD_n) déterminées à la nouvelle évaluation de la composante volumique n, le module MODd évalue des coefficients de déviation d'un premier type CDl et des coefficients de déviation d'un deuxième type CD2 pour conférer un caractère dynamique à la détection d'anomalies de trafic, aux sous-étapes courantes E22d et E23d.

Les coefficients de déviation CDl du premier type relatifs à une composante volumique x et à un coefficient de moyenne c dépendent de certaines variables, comme la composante volumique, la moyenne mobile à pondération exponentielle, la moyenne à pondération exponentielle de valeurs de la moyenne mobile, et la moyenne à pondération exponentielle des carrés de valeurs de la composante volumique. Les coefficients de déviation CDl servent à vérifier la conformité de l'évaluation courante des composantes volumiques de l'entité de service par rapport à des évaluations précédentes. Selon un premier exemple, un coefficient de déviation CDl_n du premier type relatif à la composante volumique x est égal au rapport (x_n - M_n) /SD_n entre la différence entre la composante volumique évaluée X_n et la moyenne mobile M_n, et la déviation mobile SD_n. Selon un deuxième exemple, lorsque le coefficient de pondération C est choisi différent de 1, un coefficient de déviation CDl_n du premier type relatif à la composante volumique x est déduit de la formule :

CDl_n = [x_n - 2M_n + MM_n - C(M_n - MM_n) / (1 - C) ] /SD_n Dans ces deux exemples, les coefficients de déviation CDl_n sont choisis égaux à 0 si la déviation mobile SD_n est nulle.

A la sous-étape E22d, le module MODd compare l'ancienne valeur courante CDl_n-I du coefficient de déviation à la nouvelle valeur du coefficient de déviation CDl_n, et actualise la valeur courante suivant une règle qui peut être par exemple : si la nouvelle valeur CDl_n du coefficient de déviation est supérieure à la valeur courante CDl_n-I du coefficient de déviation, remplacer ladite valeur courante par la moyenne suivante de celle-ci et de ladite nouvelle valeur :

(CDl_n + (T - I) CDl_n-I) /T, où T est une constante entière, par exemple égale à la durée exprimée en jours de l'apprentissage, arrondie à l'entier supérieur.

A la sous-étape E23d le module de modélisation MODd évalue les coefficients de déviation d'un deuxième type CD2 qui relativement à une composante volumique dépendent de certaines variables, comme la composante volumique, la moyenne mobile à pondération exponentielle, la moyenne à pondération exponentielle de valeurs de la moyenne mobile, la dérivée première discrète de composante volumique proportionnelle à la différence de la composante volumique évaluée et de la moyenne mobile, la dérivée seconde discrète de composante volumique égale à la différence d'une nouvelle valeur et d'une valeur courante de la dérivée première, et un seuil commun respectif Sd_x. Les coefficients de déviation CD2 servent à prédire la conformité de prochaines évaluations de chaque composante volumique succédant à l'évaluation courante, par rapport au seuil commun Sd_x qui est fixé pour la composante volumique, en dépendance d'évaluations courante et nouvelle de celle-ci. A cette fin, le module MODd effectue en outre de plusieurs manières une modélisation par prédiction d'une durée nécessaire pour que la composante volumique traitée x excède le seuil respectif Sd_x qui lui a été attribué initialement et qui est une valeur maximale de la composante volumique admissible par l'entité de service donnée SE. Selon deux exemples pour ce deuxième type de coefficient de déviation, un coefficient de déviation CD2_n relatif à la composante volumique x est déduit de la formule :

CD2_n = (Sd_x - M_n) /d_n, ou de la formule :

CD2_n = (d_n ² + 2 dd_n (Sd_x - M_n) ).

A la sous-étape E23d, le module MODd compare l'ancienne valeur courante CD2_n-i du coefficient de déviation à la nouvelle valeur du coefficient de déviation CD2_n, et actualise la valeur courante suivant une règle qui peut être par exemple : si la nouvelle valeur du coefficient de déviation CD2_n est inférieure à la valeur courante CD2_n-i du coefficient de déviation, remplacer ladite valeur courante par la moyenne

(CD2_n + (T - I) CD2_n-_l)/T , de celle-ci et ladite nouvelle valeur.

Une autre mode de modélisation par prédiction consiste en ce que le module MODd possède initialement une liste de constantes appelées coefficients temporels et, par exemple {10, 30, 60}, et détermine des valeurs de la composante volumique prédites à des dates postérieures à la date courante de l'évaluation de composante volumique, augmentées respectivement de coefficients temporels de la liste. La règle d'actualisation du coefficient de déviation est par exemple : si la nouvelle valeur du coefficient de déviation est supérieure à la valeur courante du coefficient de déviation, remplacer ladite valeur courante par la moyenne de celle-ci et ladite nouvelle valeur.

Avantageusement pour éviter d'obtenir des coefficients de déviation admissibles trop élevés, les valeurs des coefficients de déviation ne sont actualisées que si la composante volumique correspondante x venant d'être évaluée est supérieure à un plancher P_x qui constitue une valeur minimale en dessous de laquelle les valeurs de la composante volumique sont considérées comme non significatives pour la détection dynamique selon l'invention. Par exemple le plancher est par défaut 6 koctet/s pour la volumétrie, ou 10 paquets par seconde pour la volubilité, ou 3 adresses de source par seconde pour la connexité. Les valeurs des coefficients de déviation ne sont pas non plus actualisées lors de la transmission des premières évaluations de la composante volumique par le module MEDd au module MODd. Par exemple les 30 premières évaluations définissant une période d'amortissement préalable à une modélisation servent à actualiser les variables uniquement afin que les variables de type "moyenne" se stabilisent. Le module MOD transforme enfin chacun des coefficients de déviation ainsi obtenus à l'aide de coefficients d'élasticité par défaut, afin d'éviter de potentielles fausses alarmes positives.

Finalement, à la sous-étape E24d après la durée prédéterminée de modélisation au cours de laquelle les divers coefficients de déviation fixent un comportement normal de changement d'activité de l'entité de service SE, le module MODd fournit pour chaque composante volumique x et chaque coefficient de moyenne c, un modèle dynamique. Ce modèle dynamique est une liste comprenant l'identificateur ISE de l'entité de service donnée SE, la granularité, les valeurs de seuil Sd_x et plancher P_x, la date de création du modèle, la désignation de la composante volumique x et les valeurs des coefficients de déviation CDl, CD2 ainsi qu'éventuellement des paramètres supplémentaires comme par exemple un coefficient temporel et si celui-ci intervient dans le mode de modélisation par prédiction choisi. Les évaluations consécutives des composantes volumiques sont alors résumées par les données dans les modèles des différentes composantes volumiques.

Chaque évaluation, lorsqu'elle a été traitée par le module MODd, peut être effacée. En fin de modélisation, le module MODd enregistre chaque modèle dans la base DBd à la sous-étape E25d.

Le module de modélisation MODd comprend un sous- module d'actualisation de modèles MAMd qui périodiquement lit les modèles anciens courants relatifs à une entité de service donnée dans la base DBd pour fournir des modèles actualisés remplaçant les modèles anciens courants. Le sous-module d'actualisation de modèles MAMd fonctionne d'une manière similaire au sous-module d'actualisation de modèles MAMs dans le module de modélisation MODs. Comme à l'étape E26s, pour une actualisation de modèles E26d répétant au moins les sous-étapes E20d à E25d, le module MODd produit des modèles actualisés en fonction de valeurs récentes des composantes volumiques associées à l'entité de service, évaluées avec la granularité définie dans lesdits modèles courants et fournies par le module MEDd depuis la dernière actualisation, comme à l'étape E20d. Les valeurs récentes des composantes volumiques évaluées sont d'abord conservées temporairement dans la base d'évaluations, puis épurées Ainsi à l'étape E26d, un coefficient de déviation n'est actualisé que si la composante volumique évaluée correspondante n'a pas été épurée et donc n'a conduit à aucun signalement d'une activité anormale dans le trafic de l'entité de service SE. Comme déjà dit, l'épuration peut cependant être sautée. Ensuite, pour chaque composante volumique surveillée x relative à l'entité de service donnée et pour chaque coefficient de moyenne c, le sous-module MAMd actualise le modèle correspondant en déterminant à nouveau les variables précitées en fonction de leurs valeurs courantes anciennes et de la valeur récemment évaluée de la composante volumique. Le module MODd détermine les valeurs des coefficients de déviation CDl, CD2 dans les modèles de manière semblable à la phase d'apprentissage.

De préférence le sous-module d'actualisation de modèles MAMd actualise les valeurs des coefficients de déviation CDl, CD2 dans chaque modèle en appliquant une pondération aux valeurs des coefficients de déviation du modèle ancien courant. La pondération peut dépendre de la durée et de la date de création du modèle ancien courant pour conférer moins de poids au modèle ancien courant ou créé très rapidement. Par exemple, les valeurs des coefficients de déviation du modèle ancien sont pondérées par la durée de la modélisation et l'inverse de l'âge du modèle ancien courant.

En conséquence le module MODd établit un âge de chaque modèle enregistré exprimé en nombre de jours, en association à l'identificateur ISE de l'entité de service SE, la date de création du modèle et un nombre entier prédéterminé, servant de code de phase, indiquant si le modèle est en cours de construction pendant la phase apprentissage, en cours d'utilisation pour la détection, ou invalide temporairement, ou encore a généré une alerte récente .

Après l'actualisation, les modèles actualisés sont transférés à la base DBd qui les enregistre comme à la sous-étape E25d pour remplacer et supprimer les modèles anciens courants .

L'étape de détection d'activité anormale E3d comprend des sous-étapes d'initialisation E30d à E32d et des sous-étapes de comparaison aux modèles E33d à E35d.

Le module de détection d'anomalies DETd est activé soit automatiquement après la sous-étape E25d de la phase d'apprentissage, c'est-à-dire après la première modélisation, soit par l'opérateur via l'interface homme - machine IHM. Les sous-étapes E30d, E31d et E32d sont analogues aux sous-étapes E30s, E31s et E32s pour que le module DETd reçoive la liste des identificateurs et caractéristiques des entités de service à protéger, et éventuellement la liste des paramètres de trafic, notamment la granularité des évaluations, pour chaque entité de service, ainsi que les modèles courants pertinents pour la détection, et applique l'identificateur et les caractéristiques de l'entité de service SE et les paramètres de trafic de cette entité nécessaires à la détection et contenus dans les modèles au module de médiation MEDd qui délivre périodiquement au module de détection DETd une évaluation du trafic destiné à l'entité de service en fonction des comptes des compteurs COMd.

A la sous-étape E33d, à chaque évaluation de chaque composante volumique x, le module de détection DETd évalue les mêmes variables dont les moyennes, les dérivées et la déviation, et les mêmes coefficients de déviation CDl, CD2 que ceux évalués par le module de modélisation MODd, selon les paramètres contenus dans le modèle de la composante volumique, comme le coefficient de moyenne c et l'éventuel coefficient temporel et.

De la même manière que le module MODd ne modélise qu'après une période d'amortissement et pour des évaluations supérieures au plancher P_x, le module DETd n'effectue pas de détection par utilisation des coefficients de déviation, lors desdites premières évaluations ou lorsque la valeur de la composante volumique évaluée x est inférieure au plancher P_x. Pour au moins l'un des coefficients de déviation CDl du premier type dans un modèle, le module DETd compare la valeur respective du coefficient de déviation incluse dans le modèle à la nouvelle valeur du coefficient de déviation venant d'être évaluée et incrémente une grandeur d'alerte dynamique respective Al_x si la nouvelle valeur du coefficient de déviation est supérieure à la valeur du coefficient de déviation incluse dans le modèle. Pour au moins l'un des coefficients de déviation CD2 du deuxième type dans un modèle, représentatifs de prédictions de durée nécessaire à un dépassement de seuil, le module DETd combine la valeur du coefficient de déviation CD2 incluse dans le modèle à des variables venant d'être évaluées pour déterminer une valeur de prédiction. Le module DETd compare la valeur de prédiction au seuil Sd_x de la composante volumique x incluse dans le modèle et incrémente une grandeur d'alerte dynamique respective A2_X si la valeur de prédiction est supérieure à la valeur de seuil Sd_x.

Finalement à la sous-étape E34d, le module DETd détermine une déviation d'alerte dynamique globale DA en fonction des grandeurs d'alerte dynamique Al_x correspondant aux coefficients de déviation CDl, et des grandeurs d'alerte dynamique A2_X correspondant aux coefficients de déviation CD2, pour les composantes volumiques évaluées . Ladite déviation DA est par exemple égale à la moyenne quadratique des valeurs d'alerte. Pour chaque composante volumique x et pour chaque modèle et donc pour chaque coefficient de moyenne et, optionnellement, chaque coefficient temporel (c, et) , le module DETd regroupe les grandeurs d'alerte dynamique Al_x et les grandeurs d'alerte dynamique A2_X ainsi que la déviation d'alerte dynamique globale DA relatives respectivement aux coefficients de déviation dans un vecteur d'alerte dynamique VAd. Le vecteur d'alerte dynamique VAd représente ainsi la similarité plus ou moins prononcée de l'évaluation aux modèles courants pertinents pour cette évaluation. Le vecteur d'alerte dynamique VAd est délivré au module d'alerte ALEd chargé de la sortie des alertes .

Finalement à la sous-étape E35d, le module d'alerte ALEd décide si le vecteur d'alerte dynamique VAd doit engendrer une alerte dynamique ou non. Pour cela, le module ALEd examine ledit vecteur d'alerte dynamique VAd, et détermine en fonction de ce vecteur d'alerte dynamique VAd une valeur d'alerte dynamique globale. Si la valeur d'alerte dynamique globale excède un niveau d'alerte dynamique prédéterminé, le module ALEd signale une alerte relative à une activité anormale dans le trafic de l'entité de service SE en transmettant le vecteur d'alerte dynamique VAd au dispositif d'établissement d'alertes DEA. Le vecteur d'alerte dynamique VAd transmis est accompagné de l'identificateur ISE de l'entité de service SE, des valeurs des composantes volumiques x de l'évaluation qui a déclenché l'alerte, de la date t de l'évaluation, des seuils de coefficient de déviation pertinents au moment de l'évaluation, et d'un type d'alerte dépendant des valeurs des grandeurs d'alerte dynamique relatives aux composantes volumiques afin que toutes ces données soient affichées dans l'interface homme - machine de management IHM à la demande de l'opérateur.

Si la valeur d'alerte dynamique globale est inférieure au niveau d'alerte dynamique prédéterminé, le module d'alerte ALEd met à zéro les trois grandeurs d'alerte dynamique dans le vecteur d'alerte dynamique VAd transmis au dispositif DEA ce qui signifie que le trafic pour l'entité de service SE est normal et donc qu'il n'y a aucune alerte dynamique .

En pratique, les détections d'anomalies sont prévues pour pouvoir détecter des anomalies relatives au trafic de plusieurs entités de service supporté par la liaison de transmission. Préalablement, chaque entité de service est déclarée par une adresse de destination, au moins un protocole de transport et au moins un port et une liste de composantes volumiques à évaluer selon une période d'évaluations prédéterminée .

Selon d'autres réalisations, les dispositifs de détection d'anomalies statique et dynamique DDs et DDd sont des dispositifs de détection d'anomalies connus qui délivrent chacun un vecteur d'alerte statique dont les grandeurs d'alerte statique ont des significations similaires aux déviations D_x et DG, ou un vecteur d'alerte dynamique dont les grandeurs d'alerte dynamique ont des significations similaires aux grandeurs d'alerte Al_x et A2_X et à la déviation d'alerte globale DA.

En se référant à nouveau à la figure 1, le dispositif d'établissement d'alertes DEA comprend en cascade en sortie des dispositifs de détection d'anomalies statique et dynamique DDs et DDd : un collecteur d'alertes CA, un module de consolidation d'alertes CON, optionnellement un module d' intra-dépendance d'alertes IDP, un module de corrélation d'alertes COR relié à 1 ' interface homme - machine de management IHM locale ou éloignée, et une base de données d'alertes DBA.

En variante, le module de corrélation COR et la base de données DBA sont déportés à l'extérieur du dispositif DEA, par exemple dans un serveur connecté au système d'établissement d'alerte SA.

Le procédé d'établissement d'alertes selon l'invention est mis en œuvre dans le dispositif DEA et comprend des étapes ETIs, ETId et ET2 à ET16 montrées à la figure 6, dont certaines sont également indiquées dans la figure 1 au niveau de liens entre des modules du dispositif DEA intervenant pour l'exécution de ces étapes.

Le collecteur d'alertes CA dans le dispositif DEA est connecté au moins au dispositif de détection d'anomalies statique DDs et/ou au dispositif de détection d'anomalies dynamique DDd qui évaluent des composantes volumiques du trafic à destination et/ou en provenance de l'entité de service SE à protéger. Ces composantes volumiques sont des nombres tels que des débits ou des taux mesurés par les compteurs COMs, COMd sur la granularité fixée g définissant la période d'évaluation du trafic. Pour l'entité de service SE, on définit une alerte courante à une date d'évaluation t par un vecteur d'alerte statique VAs(D_x, DG) et un vecteur d'alerte dynamique VAd(Al_x, A2_X, DA) résultant du traitement des valeurs des compteurs des composantes volumiques dans les dispositifs de détection d'anomalies DDs et DDd.

On rappelle que le module de détection d'anomalies DETs produit une alerte statique sous la forme d'un vecteur d'alerte statique VAs qui représente la similarité plus ou moins prononcée de l'évaluation des composantes volumiques du trafic relatives à l'entité de service SE aux modèles d'activité courants qui sont pertinents pour cette évaluation et qui comprennent notamment des valeurs statistiques pour chaque composante volumique. Le vecteur d'alerte statique VAs pour l'entité de service SE a une taille égale au nombre de composantes volumiques plus un. Il contient la grandeur d'alerte statique D_x pour chaque composante volumique x et la déviation globale DG. La déviation D_x est égale au rapport entre la distance (valeur absolue de la différence) entre la valeur instantanée x de la composante volumique évaluée et sa moyenne μ_x dans le modèle d'activité courant pertinent, et la distance (valeur absolue de la différence) entre le seuil de conformité Ss_x dans le modèle et la moyenne μ_x dans le modèle. La déviation globale DG est fonction des déviations D_x pour les composantes volumiques évaluées. Le dispositif de détection DDs délivre au dispositif DEA, outre le vecteur d'alerte statique VAs (D_x, DG) , des valeurs des composantes volumiques x, l'identificateur ISE de l'entité de service SE et la date t de l'évaluation.

On rappelle également que le module de détection d'anomalies DETd produit une alerte dynamique sous la forme d'un vecteur d'alerte dynamique VAd qui représente la similarité plus ou moins prononcée de l'évaluation des composantes volumiques du trafic relatives à l'entité de service SE aux modèles d'activité courants qui sont pertinents pour cette évaluation et qui comprennent notamment des coefficients de déviation CDl et des coefficients de déviation CD2 pour chaque composante volumique. Le vecteur d'alerte dynamique VAd pour l'entité de service SE a une taille égale au double du nombre de composantes volumiques multiplié par la somme des nombres de coefficients de premier type CDl et de deuxième type CD2 par composante volumique, plus un. Il contient des grandeurs d'alerte dynamique Al_x et A2_X correspondant aux différents coefficients de déviation CDl et CD2 respectivement pour chaque composante volumique x et la déviation d'alerte dynamique globale DA. Chaque grandeur d'alerte dynamique respective Al_x résulte de la comparaison de la dernière évaluation du coefficient de déviation correspondant CDl du premier type au coefficient de déviation CDl dans le modèle. Chaque grandeur d'alerte dynamique respective A2_X résulte de la comparaison de la valeur de prédiction dépendant de la valeur du coefficient de déviation correspondant CD2 du deuxième type incluse dans le modèle et de variables venant d'être évaluées, au seuil Sd_x de la composante volumique x incluse dans le modèle. La déviation d'alerte dynamique globale DA est fonction des valeurs d'alerte de premier type Al_x et de deuxième type A2_X. Le dispositif de détection DDd délivre au dispositif DEA, outre le vecteur d'alerte dynamique VAd(Al_x, A2_X, DA), des valeurs des composantes volumiques x, l'identificateur ISE de l'entité de service SE et la date t de l'évaluation.

A la périodicité définie par la granularité g, le collecteur d'alertes CA peut recevoir un vecteur d'alerte statique VAs du dispositif de détection d'anomalies statique DDs signalant une alerte statique lorsque le vecteur d'alerte statique VAs a l'une des grandeurs D_x et DG non nulle, et un vecteur d'alerte dynamique VAd(Al_x, A2_X, DA) du dispositif de détection d'anomalies dynamique DDd signalant une alerte dynamique lorsque le vecteur d'alerte dynamique VAd a l'une des grandeurs Al_x, A2_X et DA non nulle. Cependant le collecteur d'alertes peut recevoir un vecteur d'alerte VAs, VAd dont les grandeurs d'alerte ont toutes une valeur nulle s'il n'y a pas d'alerte.

A l'étape ETIs, ETId, lorsque le dispositif de détection DDs, DDd détecte une attaque, il notifie au dispositif DEA un vecteur d'alerte VAs, VAd qui comprend au moins une grandeur d'alerte non nulle, correspondant à une composante volumique non conforme au modèle d'activité courant pertinent. Puis à l'étape ET2, le collecteur d'alertes CA normalise le vecteur d'alerte notifié en assurant que la grandeur d'alerte relative à une composante volumique dans le vecteur d'alerte ait la même valeur que la même grandeur d'alerte dans le même vecteur d'alerte relativement à une autre composante volumique. Les grandeurs d'alerte contenues dans le vecteur d'alerte sont des valeurs positives et croissent avec la valeur des déviations observées . Elles sont normalisées par rapport à une valeur maximale de grandeur d'alerte. La normalisation des grandeurs d'alerte dans les vecteurs à l'étape ET2 assure également qu'une grandeur d'alerte dans un vecteur d'alerte dynamique et une grandeur d'alerte dans un vecteur d'alerte statique aient la même valeur si les grandeurs d'alerte sont identiques. Par exemple, à la fin de la normalisation est prévue une quantification des grandeurs d'alerte en six valeurs discrètes entières 0, 1, 2, 3, 4 et 5. Selon un autre exemple plus simple de quantification, chaque grandeur d'alerte normalisée dans un vecteur d'alerte VAs, VAd présente deux états : l'état "0" lorsque la grandeur d'alerte non normalisée indique qu'il n'y a pas d'alerte, et l'état "1" lorsque la grandeur d'alerte non normalisée indique qu'il y a une alerte.

En variante, la normalisation du vecteur d'alerte statique VAs et la normalisation du vecteur d'alerte dynamique VAd, c'est-à-dire une normalisation (ET2) de paramètres d'évaluation relatifs au trafic de plusieurs entités de service et servant à déterminer des niveaux d'alerte statique et/ou dynamique, sont respectivement effectuées dans le dispositif de détection d'anomalies statique DDs et le dispositif de détection d'anomalies dynamique DDd.

Pour une date d'évaluation donnée t, le dispositif DEA peut donc recevoir par le collecteur d'alertes CA à la fois une alerte statique à l'étape ETIs et une alerte dynamique à l'étape ETId relatives à la même entité de service. Des vecteurs d'alerte VAs et VAd relatifs à cette même entité de service et produits à une date d'évaluation courante t sont donc fondés sur le même trafic observé relatif à l'entité de service.

Le module de consolidation d'alertes CON reçoit pour chaque entité de service SE à la période d'évaluation du trafic définie par la granularité g, un vecteur d'alerte statique normalisé et/ou un vecteur d'alerte dynamique normalisé, à l'étape ET3. Le module CON consolide les vecteurs d'alerte notifiés à la même date d'évaluation courante t pour produire des niveaux de sévérité d'alerte respectivement pour les entités de service surveillées .

Pendant les périodes égales à la granularité g, on supposera que le module de consolidation CON reçoit un vecteur d'alerte statique normalisé VAs et un vecteur d'alerte dynamique normalisé VAd par entité de service SE. Toutefois en variante, le module de consolidation ne reçoit qu'un vecteur d'alerte statique normalisé VAs si aucun dispositif de détection DDd n'est prévu, ou qu'un vecteur d'alerte dynamique normalisé VAd si aucun dispositif de détection DDs n'est prévu.

A l'étape ET4, le module de consolidation CON consolide chaque alerte représentée par un couple de vecteurs d'alerte normalisés VAs et VAd relatifs à l'entité de service SE et associés à la même date d'évaluation courante t, en déterminant un score de sévérité SS en fonction des valeurs des grandeurs d'alerte statique incluses dans les vecteurs d'alerte VAs et VAd. Selon un premier exemple, le score de sévérité SS dépend de la plus grande valeur des grandeurs d'alerte statique D_x et DG dans le vecteur d'alerte statique normalisé VAs et de la plus grande valeur des grandeurs d'alerte dynamique Al_x, A2_X et DA dans le vecteur d'alerte dynamique normalisé VAd relativement à toutes les composantes volumiques pour l'entité de service SE. Dans cet exemple, le score de sévérité SS peut être égal à la somme des deux plus grandes valeurs de grandeur d'alerte précédentes, ou à la moyenne des deux plus grandes valeurs des grandeurs d'alerte précédentes.

Ensuite à l'étape ET5, après une éventuelle normalisation du score de sévérité déterminé SS(VAs, VAd) , celui-ci est quantifié par le module de consolidation en un niveau de sévérité NS en comparant le score de sévérité à des niveaux d'alerte prédéterminés NA d'une table TNA et en ne retenant que le niveau d'alerte immédiatement inférieur au score de sévérité. Par exemple, la table TNA suivante mémorisée dans le module de consolidation a cinq niveaux d'alerte :

Sévérité NS NA

Bénigne B 0

Faible F 1

Moyenne M 4

Elevée E

Critique C 16

Le score de sévérité déterminé SS et le niveau de sévérité NS de l'entité de service SE accompagnés d'autres paramètres comprenant les grandeurs d'alerte dans les vecteurs d'alerte VAs, VAd et les composantes volumiques évaluées x ainsi que de la date t de l'évaluation sont fournis par le module CON au module d' intra-dépendance d'alertes IDP, à l'étape ET6.

Toutefois dans une variante indiquée à une étape ET51 à la figure 6, si le niveau de sévérité NS, en tant que niveau d'alerte, excède le niveau critique prédéterminé C le plus élevé, l'entité de service SE est considérée comme attaquée et le module de consolidation CON attribue à l'entité de service et transmet un identifiant d'alerte IA à l'interface homme - machine de management IHM qui affiche notamment divers paramètres relatifs à l'alerte tels que SS, NS, VAs, VAd, x, t.

Le module d' intra-dépendance d'alertes IDP détermine un score global affinant le score de sévérité SS d'une alerte consolidée de l'entité de service SE, en fonction de scores de sévérité de l'entité de service SE résultant d'évaluations antérieures. Le module IDP établit l ' intra-dépendance entre des scores de sévérité successifs de manière séparée pour chaque entité de service. Cette intra- dépendance modifie le score de sévérité courant SS pour l'entité de service en l'augmentant en un score global SG lorsque plusieurs scores de sévérité concernant l'entité de service ont été reçus dans une fenêtre temporelle limitée FT immédiatement antérieure à la dernière date d'évaluation courante. En outre, le module d' intra-dépendance d'alertes IDP filtre en sortie les scores globaux si bien que des scores de sévérité SS d'alertes consolidées ayant des niveaux faibles pour une entité de service peuvent générer une alerte pour cette entité de service alors qu'individuellement, sans traitement de leur intra- dépendance dans le module IDP, ils n'auraient généré aucune alerte.

Pour chaque entité de service SE, le module IDP dispose d'une fenêtre temporelle FT = bxg égale à b fois la granularité d'évaluation g et modélisée sous la forme d'une pile FIFO (en anglais "First in, First out"; premier entré, premier sorti) PI mémorisée dans le module IDP. En effet, le module de consolidation CON délivre, pour l'entité de service donnée SE, des scores de sévérité d'alertes consolidées SS associés à des dates d'évaluation séparées de la granularité g définissant la période d'échantillonnage d'évaluation. Pour l'entité de service SE, le module d' intra-dépendance d'alertes IDP conserve donc dans la pile PI un tableau des b derniers scores de sévérité SSl à SSb déterminés à des dates d'évaluation incluses dans la fenêtre temporelle FT immédiatement antérieure à la date d'évaluation courante pour l'entité de service, à l'étape ET7. Le tableau est initialisé avec tous ses éléments à 0. Par exemple, la valeur de b est choisie en fonction de la valeur de la granularité g, et peut être comprise entre 5 et 10. Typiquement pour g = 10 secondes, la fenêtre temporelle FT est de 60 secondes si b est fixé à 6.

Le module IDP conserve également la date courante t de la dernière évaluation ayant conduit au score de sévérité SS et reçue en association aux vecteurs d'alerte VAs et VAd. Au fur et à mesure des évaluations successives des composantes volumiques pour l'entité de service, le score de sévérité SS de chaque évaluation est entré dans la pile PI de scores (SSl - SSb}, descend dans la pile à chaque évaluation suivante et sort de la pile après b évaluations successives, en ayant participé à la détermination de b scores globaux suivants.

A l'occurrence d'une évaluation pour l'entité de service SE à une date courante t et avec un score de sévérité courant SS, le tableau (SSl - SSb} est actualisé en y effaçant le plus ancien score de sévérité, décalant d'une ligne les b-1 scores de sévérité précédents et écrivant le score de sévérité courant SS. Le tableau contient donc les b derniers scores de sévérité pour l'entité de service.

Puis à l'étape ET8, le module IDP détermine le score global SG en dépendance des b scores de sévérité SSl à SSb lus contenus dans la pile PI. Par exemple, le score global SG pour l'entité de service est la somme des b scores de sévérité lus.

A la fin de la période d'évaluation à l'étape ET9, le module IDP quantifie le score global déterminé SG en le comparant à des deuxièmes niveaux d'alerte global prédéterminés NG et en ne retenant que le niveau d'alerte global immédiatement inférieur au score global. Les niveaux d'alerte globaux NG sont des valeurs numériques classées dans une table mémorisée dans le module IDP et présentent une distribution de niveaux différente de celle de la table TNA des niveaux d'alerte NA dans le module CON. Si pour l'entité de service SE le score global déterminé SG excède un seuil minimal NGM, par exemple égal à un niveau global moyen, le module IDP crée à l'étape ETlO une alerte globale AG de l'entité de service comprenant le niveau d'alerte global NG, l'identificateur ISE de l'entité de service SE et la date t de l'évaluation. Dans le cas contraire, la date d'évaluation courante t pour l'entité de service SE n'est associée à aucune alerte globale et le niveau d'alerte global NG est égal à zéro.

Selon une variante simple de quantification du score global déterminé SG dans le module IDP, les niveaux d'alerte globaux prédéterminés NG sont au nombre de deux : un niveau "0" si le score global SG est inférieur ou égal au seuil minimal NGM ce qui présume à ce stade aucune alerte globale, et l'état "1" si le score global SG excède le seuil minimal NGM ce qui présume à ce stade une alerte globale.

Le module d' intra-dépendance IDP délivre ensuite des alertes globales AG des entités de service. Une alerte globale AG relative à une entité de service inclut divers "paramètres d'évaluation" relatifs au trafic en général et donc aux alertes de l'entité de service, comme les composantes volumiques, les grandeurs d'alerte dans les vecteurs d'alarme VAs, VAd, le score de sévérité SS et le niveau de sévérité NS, le score global SG et le niveau d'alerte globale NG, ainsi que l'identificateur d'entité de service ISE et la date d'évaluation courante t, au module de corrélation COR, à l'étape ETlO.

Les alertes globales AG des entités de service associées à la date d'évaluation courante t sont enregistrées dans la base de données DBA sous la commande du module de corrélation COR, à l ' étape ETlI. Le module COR agrège à la date courante t les alertes globales qui viennent d'être enregistrées en une alerte agrégée AA qui est identifiée par un identifiant IA attribué par le module COR selon les étapes ET12 à ET16. La base de données DBA conserve les alertes globales de manière à les utiliser dans l'attribution d'identifiants d'alertes agrégées associées à des dates d'évaluation postérieures à la date d'évaluation courante t et à les consulter depuis l'interface homme - machine de management IHM.

A l'étape ET12, le module COR sélectionne parmi des alertes agrégées enregistrées dans la base de données DBA, des alertes agrégées antérieures AAa associées à des dates d'évaluation antérieures proches de la date d'évaluation courante t de l'alerte agrégée courante AA. Les dates d'évaluation antérieures proches sont comprises par exemple dans un intervalle de temps de 10 minutes immédiatement antérieur à la date d'évaluation courante t.

A l'étape ET13, le module COR compare l'alerte agrégée courante AA à chacune des alertes agrégées antérieures AAa en déterminant des similarités par évaluation de distances de similarité d(AA, AAa) entre l'alerte agrégée courante AA et chacune des alertes agrégées antérieures AAa. Pour cela, le module COR se fonde sur des paramètres d'évaluation relatifs au trafic d'entités de service communes à l'alerte agrégée courante AA et chaque alerte agrégée antérieure AAa, pour lesquelles des niveaux de score globaux non nuls SG ont été déterminés (étape ET9) . On rappelle que chaque entité de service est définie par son identificateur ISE sous forme de triplets de caractéristiques pouvant chacun comporter une adresse de destination IP, un protocole de transport et un port (sous-étape ElOs, ElOd) . Le module COR ne retient que les distances de similarité d supérieures à une borne BO pour laquelle les alertes agrégées correspondantes sont considérées comme distinctes.

Par exemple, la distance de similarité entre l'alerte agrégée courante AA et une alerte agrégée antérieure AAa dépend du rapport de deux cardinaux. Le premier cardinal est relatif à l'ensemble des entités de service qui sont communes à l'alerte agrégée courante AA et à l'alerte agrégée antérieure AAa et dépend du nombre de paramètres d'évaluation relatifs au trafic desdites entités de service communes satisfaisant simultanément pour chacune des alertes agrégées AA et AAa au moins une condition prédéterminée. Le deuxième cardinal est relatif à l'ensemble de toutes les entités de service concernées par l'alerte agrégée courante AA et/ou l'alerte agrégée antérieure AAa et dépend du nombre de paramètres d'évaluation satisfaisant la condition prédéterminée pour au moins l'une des deux alertes agrégées AA et AAa. Le ou les "paramètres d'évaluation" d'une entité de service qui sont appliqués à la condition prédéterminée peuvent être choisis parmi le niveau global NG et le score global SG délivrés par le module d' intra-dépendance IDP, ou en variante le niveau de sévérité NS et le score de sévérité SS délivrés par le module de consolidation CON, ou peut être encore une composante volumique, une grandeur d'alerte de vecteur d'alerte, ou bien un ensemble prédéterminé de ces paramètres d'évaluation.

Selon une autre réalisation, le module d'intra- dépendance IDP est supprimé et le paramètre d'évaluation d'une entité de service peut être un niveau global égal au niveau de sévérité NS ou un score de sévérité SS délivré par le module de consolidation CON. Dans cette réalisation, les opérations de l'étape ET9 sont déportées à l'étape ET6 dans le module de consolidation CON. Si pour une entité de service SE le score de sévérité déterminé NS excède un seuil minimal, par exemple correspondant au niveau de sévérité moyen M dans la table TNA, la date d'évaluation courante t pour l'entité de service SE n'est associée à aucune alerte globale et le niveau d'alerte global NG est égal à zéro. L'étape ET6 est alors suivie par l'étape ETlI.

Puis après l'étape ET13, le module COR sélectionne l'alerte agrégée antérieure AAas présentant la plus petite distance déterminée d_mi_n et en cas d'égalité de plusieurs distances, l'alerte agrégée antérieure la plus récente.

Si à l'étape ET14 la distance d_mi_n séparant l'alerte agrégée courante AA de l'alerte agrégée antérieure sélectionnée AAas est inférieure ou égale à un seuil de similarité prédéterminé SIM, c'est-à- dire présente une similarité relativement élevée, le module COR attribue l'identifiant global IAas de l'alerte AAas à l'alerte agrégée courante AA, et donc fusionne leurs identifiants globaux, soit IA ≡ IAas. Un lien de corrélation entre l'alerte agrégée courante AG et au moins une alerte agrégée antérieure préexistante dans la base d'alertes DBA est ainsi établi dans le module de corrélation. Ce lien traduit l'actualisation de l'alerte agrégée courante en corrélation d'une alerte antérieure et signale une attaque déjà détectée pour les entités de service surveillées dans la liaison de transmission LT.

Si la distance d_mi_n est supérieure au seuil de similarité SIM à l'étape ET14, le module COR crée et attribue un nouvel identifiant IA à l'alerte agrégée courante AA ce qui signale une nouvelle attaque dans la liaison de transmission LT.

Le module de corrélation COR inscrit alors à l'étape ET15 l'alerte agrégée courante AA avec son identifiant IA dans la base de données DBA.

Puis à l'étape ET16, le module de corrélation COR transmet l'alerte agrégée courante AA avec son identifiant IA à l'interface homme - machine de management IHM qui affiche les divers paramètres d'évaluation de l'alerte agrégée courante AA avec un qualificatif qui dépend de l'identifiant IA.

L'invention décrite ici concerne un procédé et un système informatique SA pour établir des alertes relatives à des anomalies dans le trafic supporté par la liaison de transmission LT et relatif à une ou plusieurs entités de service SE. Selon une implémentation préférée, les étapes du procédé de l'invention sont déterminées par les instructions d'un programme d'ordinateur incorporé dans le système informatique. Le programme comporte des instructions de programme qui, lorsque ledit programme est chargé et exécuté dans le système, 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 sur ou dans un support d'informations, adapté à mettre en œuvre l'invention. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable pour implémenter le procédé selon l'invention.

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

D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type internet .

Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé selon 1 ' invention .

Claims

REVENDICATIONS

1 - Procédé pour établir des alertes par évaluations périodiques de paramètres d'évaluation relatifs au trafic d'au moins une entité de service, caractérisé en ce qu'il comprend à chaque évaluation les étapes de: déterminer (ET4 - ET9) pour au moins une entité de service (SE) un niveau d'alerte (NG) dépendant de la valeur d'au moins un paramètre d'évaluation relatif au trafic de l'entité de service afin de constituer une alerte globale (AG) incluant les paramètres d'évaluation et une date d'évaluation courante lorsque le niveau d'alerte excède un seuil minimal, agréger (ETlI) les alertes globales des entités de service associées à la date d'évaluation courante en une alerte agrégée courante (AA) et sélectionner (ET12) des alertes agrégées antérieures (AAa), déterminer (ET13) des distances de similarité entre l'alerte agrégée courante (AA) et lesdites alertes agrégées antérieures en fonction d'au moins l'un des paramètres d'évaluation relatifs à des entités de service qui sont communes à l'alerte agrégée courante et à chaque alerte agrégée antérieure, et si la plus petite des distances est inférieure à un seuil de similarité, fusionner (ET14) des identifiants des alertes agrégées (AA, AAas) séparées par la plus petite distance, et sinon attribuer un identifiant (IA) à l'alerte agrégée courante (AA).

2 - Procédé conforme à la revendication 1, selon lequel la distance de similarité entre l'alerte agrégée courante (AA) et l'une des alertes agrégées antérieures (AAa) dépend du rapport d'un premier cardinal relatif à l'ensemble des entités de service qui sont communes à l'alerte agrégée courante et l'alerte agrégée antérieure et dépend du nombre de paramètres d'évaluation relatifs au trafic desdites entités de service communes satisfaisant simultanément pour chacune des alertes agrégées courante (AA) et antérieure (AAa) au moins une condition prédéterminée, et d'un deuxième cardinal relatif à l'ensemble de toutes les entités de service concernées par l'alerte agrégée courante et l'alerte agrégée antérieure et dépend du nombre de paramètres d'évaluation satisfaisant la condition prédéterminée pour au moins l'une des deux alertes agrégées courante et antérieure.

3 - Procédé conforme à la revendication 1 ou 2, selon lequel l'étape de déterminer un niveau d'alerte pour au moins une entité de service (SE) comprend une détermination (ET4) d'un score de sévérité (SS) en fonction de déviations de composantes volumiques relatives au trafic de l'entité de service, et une quantification (ET5) du score de sévérité en le niveau d'alerte en comparant le score de sévérité à des niveaux d'alerte prédéterminés (NA) .

4 - Procédé conforme à la revendication 3, selon lequel l'étape de déterminer un niveau d'alerte pour au moins une entité de service (SE) comprend en outre une détermination (ET8) d'un score global (SG) en fonction de scores de sévérité de l'entité de service résultant d'évaluations dans une fenêtre temporelle immédiatement antérieure à la date d'évaluation courante, et une quantification (ET9) du score global en le niveau d'alerte en comparant le score global à des deuxièmes niveaux d'alerte prédéterminés (NG) .

5 - Procédé conforme à l'une quelconque des revendications 1 à 4, comprenant une normalisation (ET2) du paramètre d'évaluation relatif au trafic des entités de service qui sert à déterminer les niveaux d' alerte .

6 - Procédé conforme à l'une quelconque des revendications 1 à 5, comprenant une détection statique d'anomalies (EIs, E2s, E3s, ETIs) dans le trafic de chaque entité de service (SE) , préalablement à l'étape de déterminer (ET4 - ET9) un niveau d'alerte pour chaque entité de service (SE) .

7 - Procédé conforme à la revendication 6, selon lequel la détection statique d'anomalies inclut une modélisation (E2s) de l'activité normale de l'entité de service pour fournir au moins un modèle pour une composante volumique du trafic de l'entité de service, chaque modèle comprenant une période de validité, des valeurs statistiques relatives à ladite composante volumique pendant ladite période de validité et un seuil de conformité dépendant des valeurs statistiques, et pour au moins une évaluation de composante volumique à une date ultérieure à la modélisation, une détermination (E31s - E33s) d'une grandeur d'alerte statique (D_x), en tant que paramètre d'évaluation, relative à une déviation de la composante volumique évaluée par rapport au modèle relatif à la composante volumique et ayant une période de validité incluant sensiblement la date de l'évaluation, et une détermination (E34s, E35s) d'une valeur d'alerte statique en fonction de la déviation d'au moins une composante volumique pour signaler une alerte statique représentative d'une activité anormale dans le trafic de l'entité de service.

8 - Procédé conforme à la revendication 7, selon lequel la déviation de la composante volumique dans un modèle est le rapport entre la distance entre la composante volumique évaluée et la moyenne de la composante volumique dans le modèle, et la distance entre le seuil de conformité dans le modèle et la moyenne .

9 - Procédé conforme à l'une quelconque des revendications 1 à 8, comprenant une détection dynamique d'anomalies (EId, E2d, E3d, ETId) dans le trafic de chaque entité de service (SE) , préalablement à l'étape de déterminer (ET4d - ET9d) un niveau d'alerte pour chaque entité de service

(SE) .

10 - Procédé conforme à la revendication 9, selon lequel la détection dynamique d'anomalies inclut une modélisation (E2d) de l'activité normale de l'entité de service pour fournir des modèles pour des composantes volumiques du trafic de l'entité de service évaluées périodiquement pendant une durée prédéterminée, un modèle relatif à une composante volumique comprenant des coefficients de déviation évalués en fonction d'une moyenne mobile de la composante volumique évaluée pendant la durée prédéterminée, et pour au moins une évaluation ultérieure de coefficients de déviation relatifs aux composantes volumiques, une incrémentation (E31d - E33d) d'au moins une grandeur d'alerte dynamique respective (Al_x et/ou A2_X) , en tant que paramètre d'évaluation, pour au moins un coefficient de déviation si une nouvelle valeur du coefficient de déviation est supérieure à une valeur de seuil respective incluse dans le modèle, et une détermination (E34d, E35d) d'une valeur d'alerte dynamique en fonction de la grandeur d'alerte dynamique d'au moins une composante volumique pour signaler une alerte dynamique représentative d'une activité anormale dans le trafic de l'entité de service et continuer par l'étape de déterminer (ET4 - ET9) un niveau d'alerte.

11 - Procédé conforme à la revendication 10, selon lequel des coefficients de déviation d'un premier type relatifs à une composante volumique dépendent, outre de la composante volumique et de la moyenne mobile qui est une moyenne mobile à pondération exponentielle, d'une moyenne à pondération exponentielle de la moyenne mobile, et d'une moyenne à pondération exponentielle des carrés de valeurs de la composante volumique.

12 - Procédé conforme à la revendication 10 ou 11, selon lequel des coefficients de déviation d'un deuxième type relatifs à une composante volumique dépendent, outre de la composante volumique et de la moyenne mobile qui est une moyenne mobile à pondération exponentielle, d'une moyenne à pondération exponentielle de valeurs de la moyenne mobile, d'une dérivée première discrète de composante volumique proportionnelle à la différence de la composante volumique évaluée et de la moyenne mobile, d'une dérivée seconde discrète de composante volumique égale à la différence d'une nouvelle valeur et d'une valeur courante de la dérivée première, et d'un seuil commun.

13 - Procédé conforme à la revendication 7 ou 8 et à l'une quelconque des revendications 10 à 12, selon lequel le niveau d'alerte (NS, NG) dépend de la plus grande valeur de grandeurs d'alerte statique

(D_x, DG) déterminées au cours de la détection statique pour l'entité de service, et de la plus grande valeur de grandeurs d'alerte dynamique (Al_x, A2_X, DA) déterminées au cours de la détection dynamique pour l'entité de service.

14 - Système pour établir des alertes par évaluations périodiques de paramètres d'évaluation relatifs au trafic d'au moins une entité de service, caractérisé en ce qu'il comprend pour chaque évaluation : un moyen (CON, IDP) pour déterminer pour au moins une entité de service (SE) un niveau d'alerte

(NG) dépendant de la valeur d'au moins un paramètre d'évaluation relatif au trafic de l'entité de service afin de constituer une alerte globale (AG) incluant les paramètres d'évaluation et une date d'évaluation courante lorsque le niveau d'alerte excède un seuil minimal, un moyen (COR, DBA) pour agréger les alertes globales des entités de service associées à la date d'évaluation courante en une alerte agrégée courante

(AA) et sélectionner des alertes agrégées antérieures

(AAa), un moyen (COR) pour déterminer des distances de similarité entre l'alerte agrégée courante (AA) et lesdites alertes agrégées antérieures en fonction d'au moins l'un des paramètres d'évaluation relatifs à des entités de service qui sont communes à l'alerte agrégée courante et à chaque alerte agrégée antérieure, et un moyen (COR, DBA) pour fusionner (ET14) des identifiants des alertes agrégées (AA, AAas) séparées par la plus petite distance si celle-ci est inférieure à un seuil de similarité, et un moyen (COR) pour attribuer un identifiant (IA) à l'alerte agrégée courante (AA) si la plus petite distance est supérieure au seuil de similarité .

15 - Système conforme à la revendication 14, comprenant en outre un dispositif de détection statique (DDs) détectant des anomalies dans le trafic d'au moins une entité de service (SE) .

16 - Système conforme à la revendication 14 ou 15, comprenant en outre un dispositif de détection dynamique (DDd) détectant des anomalies dans le trafic d'au moins une entité de service (SE) .

17 - Programme d'ordinateur apte à être mis en œuvre dans un système (DD) pour établir des alertes par évaluations périodiques de paramètres d'évaluation relatifs au trafic d'au moins une entité de service, ledit programme comprenant des instructions qui, lorsque le programme est chargé et exécuté dans ledit dispositif, réalisent les étapes consistant à : déterminer (ET4 - ET9) pour au moins une entité de service (SE) un niveau d'alerte (NG) dépendant de la valeur d'au moins un paramètre d'évaluation relatif au trafic de l'entité de service afin de constituer une alerte globale (AG) incluant les paramètres d'évaluation et une date d'évaluation courante lorsque le niveau d'alerte excède un seuil minimal, agréger (ETlI) les alertes globales des entités de service associées à la date d'évaluation courante en une alerte agrégée courante (AA) et sélectionner (ET12) des alertes agrégées antérieures (AAa) , déterminer (ET13) des distances de similarité entre l'alerte agrégée courante (AA) et lesdites alertes agrégées antérieures en fonction d'au moins l'un des paramètres d'évaluation relatifs à des entités de service qui sont communes à l'alerte agrégée courante et à chaque alerte agrégée antérieure, et si la plus petite des distances est inférieure à un seuil de similarité, fusionner (ET14) des identifiants des alertes agrégées (AA, AAas) séparées par la plus petite distance, et sinon attribuer un identifiant (IA) à l'alerte agrégée courante (AA).