Brevet FR3038187A1 — publié le 20161230

Procédé de détection d'anomalies dans l'exécution d'un service La présente invention concerne un procédé de détection d'anomalies dans l'exécution d'un service. Elle trouve une application particulièrement intéressante dans la détection d'attaques contre des services accédés via le web, notamment dans la détection de nouvelles attaques, c'est-à-dire d'attaques non référencées a priori. De nombreuses méthodes de détection d'anomalies lors de l'exécution de services existent. Il est habituel que ces méthodes s'appuient sur une modélisation de requêtes malveillantes afin de définir un ou des modèles d'attaque, puis une détection de ces modèles parmi des requêtes de service. De telles méthodes reposent habituellement sur l'utilisation d'un outil de gestion de journaux d'événements (on parle de « logs » en anglais) et de corrélation des informations de ces journaux. Un tel outil est connu sous le nom de « SIEM » (de l'anglais « Security Information and Event Management »). Les journaux contiennent pour un équipement donné la liste de tous les événements qui se sont déroulés : réussite ou échec d'une connexion utilisateur, redémarrage d'une machine, saturation de la mémoire, etc. Le SIEM propose des méthodes et outils pour agréger des alertes et pour identifier des attaques par corrélations des informations des journaux. Un tel outil repose sur des métriques statistiques et/ou des règles statiques de corrélation. Cependant, l'efficacité d'un tel outil est conditionnée par une connaissance préalable de la façon dont l'attaque va se manifester. En effet, un outil SIEM requiert une connaissance a priori des possibilités d'attaquer le service. Un tel outil construit un modèle de requêtes malveillantes à partir d'un ensemble de requêtes malveillantes. Il détecte des profils d'attaque basés sur une observation statistique des événements liés au service ou à la machine, par exemple, une anomalie dans le nombre de requêtes en provenance d'un utilisateur ou dans le nombre de biens achetés par un utilisateur dans le cas d'un service d'achat en ligne. Une telle méthode ne permet cependant pas de détecter des profils d'attaque non référencés initialement. Un des buts de l'invention est de remédier à des insuffisances/inconvénients de l'état de la technique et/ou d'y apporter des améliorations. A cette fin, l'invention propose un procédé de détection d'anomalies dans l'exécution d'un service, comprenant : - une obtention d'une liste ordonnée d'au moins deux transactions élémentaires pour une session courante, lors d'une exécution du service par une entité, 3038187 2 - une construction pour la session courante d'un vecteur de distribution (va) dont les entrées correspondent aux entrées d'au moins un vecteur de référence, une entrée du vecteur de référence correspondant à un segment élémentaire de taille fixe d'au moins une transaction élémentaire, et association à une entrée du vecteur de distribution d'un nombre d'occurrences 5 du segment élémentaire correspondant dans la liste ordonnée, ledit vecteur de référence étant représentatif d'un profil de comportement normal d'utilisation du service, - une identification de la session courante comme normale lorsque la distance entre le vecteur de distribution et le vecteur de référence est inférieure à une valeur seuil associée au vecteur de référence. 10 Par rapport aux méthodes connues de détection de comportements malveillants, le procédé propose de comparer une session d'exécution courante à un ensemble de modèles de comportements normaux d'utilisation d'un service et d'identifier la session d'exécution courante comme normale dès lors que la session d'exécution courante est proche d'au moins un modèle de comportement normal. En d'autres termes, la session courante est assimilée à une 15 anomalie dès lors qu'elle s'écarte de l'ensemble des modèles de comportements normaux. Ainsi, contrairement aux méthodes connues, le procédé permet de détecter des anomalies correspondant à des attaques qui n'ont pas été identifiées jusqu'à présent. Par ailleurs le procédé permet la détection d'anomalies dans l'exécution de services complexes, c'est-à-dire de services qui comprennent de nombreuses fonctionnalités, et pour 20 lesquels une session peut comprendre un nombre important de transactions élémentaires. Dans ce cas, la vulnérabilité peut ne pas être liée à une fonctionnalité de service particulière mais à un enchaînement particulier de fonctionnalités. Avantageusement, le procédé comprend un remplacement d'au moins une valeur spécifique contenue dans les transactions élémentaires par une valeur générique. 25 Le remplacement de valeurs spécifiques par des valeurs génériques dans les transactions élémentaires permet de faire abstraction de valeurs non représentatives pour l'identification de comportements normaux d'utilisation du service. Il permet de généraliser des transactions en fonction de la sémantique propre à des valeurs spécifiques. Il permet ainsi de construire des modèles de comportements normaux qui regroupent des sessions d'exécution qui diffèrent par 30 des valeurs spécifiques non significatives. De façon avantageuse, la liste ordonnée d'au moins deux transactions élémentaires est obtenue au moyen d'une analyse n-grammes des transactions élémentaires. Habituellement l'analyse n-grammes est utilisée sur des unités lexicales. L'utilisation de l'analyse n-grammes a été observée dans le cadre d'une détection de code malveillant. Cependant cette approche consistait à faire une analyse syntaxique de requêtes de services afin 3038187 3 d'identifier des attaques qui se rapprochaient le plus d'attaques préalablement identifiées. Cela rentre dans la catégorie des méthodes basées sur du filtrage de motifs (ou « pattern matching » en anglais). Ici, on utilise une analyse n-grammes sur des transactions élémentaires représentatives des interactions entre une entité et un service. Cette analyse permet une analyse 5 de sessions de service qui tient compte de l'enchaînement des transactions élémentaires par l' entité. Le choix de n pour l'analyse n-grammes dépend du service. Elle est fixée de manière empirique à une valeur qui génère le moins de faux-positifs. Dans un exemple de réalisation, le procédé détecte une anomalie lorsque le segment 10 élémentaire de la session courante ne figure pas parmi les entrées du vecteur de référence. Dans cet exemple, une anomalie est détectée dans une session courante d'utilisation du service dès lors qu'un nouveau segment élémentaire est rencontré. « Nouveau » signifie qu'il n'a pas été rencontré durant la phase d'apprentissage. Une telle anomalie est détectée relativement tôt au cours de l'analyse de la session. Elle peut être consécutive à une évolution 15 du service. Par exemple une nouvelle fonctionnalité a été définie et mise en service. Dans ce cas, il est nécessaire de mettre en oeuvre une nouvelle phase d'apprentissage afin d'intégrer cette nouvelle fonctionnalité dans les modèles de comportements normaux. Selon un exemple de réalisation, la distance entre le vecteur de distribution et le vecteur de référence est la distance Euclidienne. 20 Dans un exemple de réalisation, le procédé comprend une phase d'apprentissage mise en oeuvre sur un ensemble de sessions d'apprentissage, comprenant pour une desdites sessions d'apprentissage associée à une exécution du service : - une obtention d'une liste ordonnée d'apprentissage d'au moins deux transactions élémentaires d'apprentissage, 25 - une construction d'un vecteur de distribution d'apprentissage dont les entrées correspondent aux entrées du vecteur de référence, à une entrée du vecteur de distribution d'apprentissage on associe un nombre d'occurrences du segment élémentaire d'apprentissage correspondant dans la liste ordonnée d'apprentissage, - une construction d'une matrice de distribution par ajout dudit vecteur de distribution 30 d'apprentissage, ladite matrice d'observation comprenant en i-ième ligne un i-ième vecteur de distribution d' apprentissage, et, - une modification de l'ordre des colonnes et des lignes de la matrice de distribution obtenues pour l'ensemble des sessions d'apprentissage, pour constituer des groupements de 3038187 4 valeurs autour de la diagonale de la matrice, et une obtention pour chaque groupement de valeurs, du vecteur de référence et de la valeur seuil associée. Le procédé définit une phase d'apprentissage durant laquelle sont construits les modèles de comportement normaux auxquels sont comparés les sessions courantes d'exécution du 5 service. Selon un exemple de réalisation, les groupements de valeurs sont obtenus durant la phase d'apprentissage par application d'un algorithme de classification double, ou de « coclustering », à la matrice de distribution. La classification double, ou co-clustering, permet de caractériser des sessions de service 10 et de les regrouper en fonction des seuls paramètres qu'elles ont en commun Cette classification est donc plus fine que des classifications qui travaillent sur l'ensemble des paramètres. Ainsi, elle permet d'obtenir plusieurs clusters, ou regroupements de données, dont chacun regroupe des paramètres communs. L'invention concerne également un dispositif de détection d'anomalies, comprenant : 15 - un module d'obtention d'une liste ordonnée, agencé pour obtenir une liste ordonnée d'au moins deux transactions élémentaires pour une session courante, lors d'une exécution du service par une entité, - un module de construction et d'association, agencé pour construire pour la session courante un vecteur de distribution dont les entrées correspondent aux entrées d'au moins un 20 vecteur de référence, une entrée du vecteur de référence correspondant à un segment élémentaire de taille fixe d'au moins une transaction élémentaire, et pour associer à une entrée du vecteur de distribution d'un nombre d'occurrences du segment élémentaire correspondant dans la liste ordonnée, ledit vecteur de référence étant représentatif d'un profil de comportement normal d'utilisation du service, 25 - un module d'identification, agencé pour identifier la session courante comme normale lorsque la distance entre le vecteur de distribution et le vecteur de référence est inférieure à une valeur seuil associée au vecteur de référence. L'invention porte également sur un programme d'ordinateur sur un support de données et chargeable dans la mémoire d'un ordinateur, le programme comprenant des instructions de 30 code pour l'exécution des étapes du procédé de détection d'anomalies, lorsque le programme est exécuté sur ledit ordinateur. L'invention concerne aussi sur un support de données dans lequel est enregistré le programme tel que décrit précédemment. 3038187 5 D'autres caractéristiques et avantages de la présente invention seront mieux compris de la description et des dessins annexés parmi lesquels : - la figure 1 présente les étapes de la phase d'apprentissage du procédé de détection d'anomalie lors de l'utilisation d'un service, selon un exemple de réalisation ; 5 - la figure 2 présente les étapes du procédé de détection d'anomalies ; - la figure 3 présente à titre d'exemple, une matrice sur laquelle est mise en oeuvre une classification double et la matrice résultante obtenue ; - la figure 4 est une représentation schématique d'un dispositif de détection d'anomalie selon un exemple de réalisation. 10 Les étapes d'un procédé de détection d'anomalies lors de l'exécution d'un service, selon un exemple de réalisation vont être décrites en relation avec les figures 1 à 3. Le procédé propose de construire de manière statistique, à partir d'une observation d'exécutions normales du service, c'est-à-dire exemptes d'anomalies, un ou des profils de 15 comportement normal afin d'identifier des exécutions de service qui dévient de ce comportement normal, et que l'on assimile de ce fait à des anomalies On s'intéresse ici à l'exécution de services dits « complexes » dans le sens où ils comprennent potentiellement l'exécution de plusieurs services élémentaires, tels qu'un service d'authentification, un service de constitution d'un panier, un service de paiement, etc. Un tel 20 service est typiquement un service d'achat sur Internet. Lors de l'exécution du service d'achat, un utilisateur va effectuer ce que l'on appelle un « parcours client » allant de l'accès au service jusqu'à la réception d'une confirmation d'un paiement de biens, en passant par une authentification, la constitution d'un panier, une validation du panier, la fourniture de coordonnées bancaires pour le paiement, etc. En ce sens, le service est qualifié de complexe. 25 Le parcours client intègre des échecs éventuels de l'authentification, le surf sur différentes pages du site marchand, etc., qui correspondent à autant d'interactions avec le service. Un tel parcours client est associé à une session d'exécution. La session comprend un ensemble de transactions élémentaires correspondant aux différentes interactions de l'utilisateur avec le service. Une transaction élémentaire comprend une requête au service et une réponse associée. 30 A noter qu'un tel service peut faire intervenir plusieurs prestataires de services : un premier fournisseur de services pour l'authentification, un deuxième fournisseur de service pour l'affichage d'un catalogue et la sélection d'articles et un troisième fournisseur pour le paiement. Dans une phase PO d'apprentissage, décrite en relation avec le figure 1, il est construit des profils de comportement modélisant des parcours client normaux, c'est-à-dire exempts 35 d'anomalies, similaires à partir d'une base de données d'observations BdO qui mémorise un 3038187 6 échantillon important de sessions utilisateur. Par exemple, la base d'observation BdO mémorise plus de 100000 sessions. A noter que la base de données d'observation BdO peut être également un enregistrement de trafic brut, tel que des traces « HTTP » (de l'anglais « HyperText Transfer Protocol ») ou un journal d'événements (ou « log » en anglais). Un nombre important 5 d'échantillons dans la base d'observations permet d'avoir une méthode de détection d'anomalies plus précise. Dans une phase suivante P1 de détection, des sessions d'exécution courantes sont comparées aux profils de comportement normal construits durant la phase d'apprentissage PO et assimilées à des exécutions normales de service ou à des anomalies, selon le résultat de la comparaison. 10 Dans l'exemple décrit ici, on considère un service accédé à travers le réseau Internet. Une session utilisateur, composée de transactions élémentaires, est alors décrite au moyen d'une succession de requêtes d' « URL » (pour « Uniform Resource Locator), ou URL, ou d'adresses web, représentatives de toutes les interactions de l'utilisateur avec le service. Dans cet exemple, on peut ne retenir dans la base d'observation BdO que les requêtes associées à une réponse 15 positive. La construction des profils de comportement modélisant des parcours client normaux va consister à comparer des enchaînements de transactions élémentaires dans des sessions et à dégager des profils de comportement similaires auxquelles les différentes sessions peuvent être assimilées. La structure d'une URL est définie dans la « RFC » 2616 (pour « Request For 20 Comment »). Une URL définit au moyen d'un nom, d'une localisation et éventuellement d'autres caractéristiques, une ressource accessible à travers le réseau Internet. Plus précisément, une URL est structurée en plusieurs champs : - un nom complètement qualifié (ou « FQDN » pour « Fully Qualified Domain Name »), qui fournit l'emplacement du service hébergeant une ressource sur un espace réseau global, 25 - le nom absolu de la ressource ou de l'application fournie par le service, et - des paramètres supplémentaires optionnels qui peuvent être composés de clés et de valeurs. Un exemple d' URL est : URL = https://perso.orange.fr/maf.php?contract=123456&page=svc-mobile 30 Une URL peut contenir des attributs spécifiques à un utilisateur, dans l'exemple ci- dessus un numéro de contrat dont la valeur est « 123456 ». Afin de comparer des URL issues de sessions différentes qui concernent par exemple des utilisateurs différents et dont certains paramètres, bien que spécifiques ne sont pas significatifs pour la comparaison puisque la sémantique de la transaction associée peut être la 35 même dans ce cas, il faut faire abstraction de ces paramètres spécifiques. En effet, à défaut, une 3038187 7 URL qui contient des paramètres spécifiques est unique dans le contexte d'une session ou d'un utilisateur donné et une comparaison de deux URL sémantiquement équivalentes ne permet pas d'identifier de similitude. Dans une étape initiale EO, on obtient pour une session de la base d'observation BdO 5 une liste ordonnée de transactions élémentaires. Dans une étape suivante El de remplacement de paramètres spécifiques, il est procédé, pour la session, à l'identification et au remplacement de paramètres spécifiques dans les URL représentatives de transactions élémentaires par des paramètres génériques. La spécificité d'une URL peut apparaître au niveau des paramètres supplémentaires optionnels. En effet, les deux 10 premiers champs, en l'espèce le nom complètement qualifié et le nom absolu de la ressource ou de l'application fournie par le service concernent des ressources spécifiques ou des applications fournies par le service et ne concernent pas de paramètres spécifiques de l'utilisateur. Les paramètres supplémentaires optionnels peuvent indiquer des attributs spécifiques au service qui permettent de rediriger des utilisateurs vers des applications web spécifiques. Dans ce cas ils 15 sont équivalents s'ils partagent la même clé et la même valeur. Les paramètres supplémentaires optionnels peuvent également indiquer des paramètres spécifiques à l'utilisateur qui permettent au service de préciser le contenu qui doit être délivré à l'utilisateur, par exemple un contenu qui spécifie un numéro de contrat. Des paramètres spécifiques à des utilisateurs qui figurent dans deux URL distinctes sont équivalents s'ils partagent la même clé et la même sémantique. Ces 20 paramètres ne déterminent cependant pas la session de l'utilisateur. Il est donc nécessaire dans ce dernier cas de rendre générique la valeur qui est associée à une clé afin de généraliser un paramètre spécifique à l'utilisateur. Dans cet exemple, il est proposé de généraliser des paramètres spécifiques d'utilisateurs en des paramètres sémantiquement équivalents et de remplacer dans une URL chaque 25 occurrence d'un paramètre spécifique de l'utilisateur par son équivalent générique. Prenons l'exemple d'une série d'URL représentatives de l'exécution d'un service qui permet à un utilisateur d'accéder une page afin de changer de terminal mobile. Les transactions élémentaires correspondant aux requêtes élémentaires mises en oeuvre lors de l'exécution du service par l'utilisateur sont par exemple les suivantes, dans cet ordre : 30 URL1 : http ://moteur. orange. fr/?kw=replace+mobile &bhv=fr&module=orange URL2 : http://moteur.orange.fr/?kw=change+mobile&bhv=fr&module=orange URL3 : https ://auth. orange. fr/auth.cgi?origin=wg&tgt=open. orange. fr URL4 : https ://open.orange.fr/perso/mobiles.aspx?appli=changeMobile&user=bob&bran d=iphone&rdt=fr 35 URL5 : https ://perso.orange.fr/maf.php?contract=123456&page=svc-mobile. 3038187 8 Cette séquence ordonnée d'URL est transformée en la suite ordonnée de transactions élémentaires suivantes par remplacement de paramètres spécifiques à des utilisateurs en paramètres génériques : Ta : http://moteur. orange. fr/?kw= [literai] &bhv= [ccode] &module=orange 5 Ta : http://moteur. orange. fr/?kw= [literai] &bhv= [ccode]fr&module=orange Tb : https://auth.orange.fr/auth.cgi?origin=wg&tgt=open.orange.fr Tc : haps ://open. orange. fr/perso/mobiles . aspx?appli=changeMobile&user= [userId] &bra nd= [item] &rdt= [ccode] Td : https://perso.orange.fr/maf.php?contract=[userId] &page= svc-mobile. 10 La liste ordonnée de transactions élémentaires ainsi obtenue est notée . A noter que pour certains services, les requêtes élémentaires mises en oeuvre lors de l'exécution du service ne contiennent pas de paramètres spécifiques. La liste de transactions élémentaires ne nécessite donc aucun remplacement de paramètre. Lors de cette transformation, un identifiant de connexion spécifique à l'utilisateur, par 15 exemple « bob » ou « 12345 », est remplacé par un identifiant de connexion générique « userId ». La langue, ou le pays de l'endroit où se trouve le terminal de l'utilisateur, ici « fr » est remplacé par une valeur générique « Ccode ». Dans cet exemple de service, on utilise également le paramètre générique noté « Item » pour remplacer un identifiant de base associé à une donnée sélectionnée par un utilisateur, un paramètre générique noté « Timestamp » pour 20 remplacer une date locale sur le terminal de l'utilisateur, un paramètre générique noté « Cookie » pour remplacer une signature ou un condensé pour un cookie délivré par le service. On suppose que pour un service donné, les paramètres génériques à utiliser pour remplacer des paramètres spécifiques ont été définis. D'autres paramètres génériques peuvent être ajoutés en fonctions de caractéristiques propres à un service. Par ailleurs, dans un exemple où les requêtes 25 http comprennent des informations de contexte au niveau l'entête http, on peut envisager d'exploiter les données échangées via ces entêtes. Au terme de l'étape El de remplacement de paramètres spécifiques, les transactions élémentaires associées à l'exécution du service ont ainsi été généralisées en remplaçant des paramètres spécifiques d'utilisateur par des paramètres génériques, représentatifs de leur 30 sémantique. Dans une étape suivante E2 d'analyse, il est appliqué une méthode d'analyse statistique connue appelée n-grammes à la liste ordonnée de transactions élémentaires d'une session i obtenues au cours de l'étape précédente. Un n-grammes est une sous-séquence de n éléments de construite à partir d'une séquence donnée. Les n-grammes sont très utilisés en traitement 35 automatique du langage naturel et en traitement du signal. 3038187 9 Dans le procédé décrit ici, on applique de façon originale la méthode d'analyse n-grammes à des listes ordonnées de transactions élémentaires représentatives de sessions d'exécution de service afin de caractériser des sessions légitimes d'utilisateurs, c'est-à-dire sans anomalie, en termes d'enchaînement ordonné de transactions élémentaires. Ici, la valeur de n 5 correspond à un nombre de transactions élémentaires. L'utilisation des n-grammes permet de tenir compte de la relation d'ordre entre n transactions élémentaires consécutives représentées dans un n-grammes Le n-grammes est alors considéré ensuite comme un donnée élémentaire et indivisible, qui représente une séquence de n transactions qui apparaissent dans cet ordre durant la session de service. 10 L'utilisation des n-grammes repose sur l'hypothèse simplificatrice que, étant donnée une séquence de k éléments, k> n, la probabilité d'apparition d'un élément en position i ne dépend que des n - 1 éléments précédents. Parmi les applications récentes des n-grammes on trouve des travaux sur l'indexation de documents, l'hyper-textualisation automatique multilingue qui à partir de grandes collections de textes construit des interfaces de navigation hypertextuelles, etc. 15 Dans ces travaux, les n-grammes sont des n-grammes de caractères qui sont définis par une suite de n caractères. Dans une sous-étape E21 de l'étape E2 d'analyse n-grammes, les transactions élémentaires relatives à une session sont représentées au moyen d'un n-grammes Si l'on considère la liste ordonnée de transactions élémentaires suivante : représentative, moyennant le remplacement de paramètres spécifiques par des paramètres génériques, d'une navigation d'un utilisateur sur le service, on obtient pour n = 2 une décomposition en le n-grammes suivant : . On appelle un élément élémentaire du n-gramme, par exemple TaTb, un segment (ou « token » en anglais). Pour un n donné, les segments sont de taille fixe en termes de nombre de 25 transactions élémentaires, 2 dans l'exemple ci-dessus et induisent un ordre entre les transactions élémentaires qui le composent. On construit également un vecteur d'apprentissage v, propre à la session i qui comprend autant de colonnes que de segments élémentaires possibles dans un espace des transactions élémentaires du service. Dans un autre exemple où la valeur choisie pour n est 3, on obtient le n-grammes suivant : . Le choix de n dépend du service, et cette valeur est fixée de manière empirique ; elle est fixée à une valeur qui génère le moins de faux-positifs. A noter que si l'on choisit n = 1, le modèle est très générique mais des informations relatives à la séquence et à l'ordonnancement des transactions élémentaires dans cette séquence sont perdues. A noter également que pour 35 n = 1, le système de détection d'anomalie est capable d'identifier durant la phase de détection 3038187 10 P1 des comportements anormaux comme des attaques par force brute dans lesquelles un utilisateur envoie un nombre important de requêtes correspondant à une ou quelques transactions élémentaires. Le système peut également détecter des attaques spécifiques dans lesquelles un utilisateur injecte du code malicieux dans une requête URL. En effet, dans ce cas, 5 la transaction élémentaire ne correspond à aucun segment identifié lors de la phase d'apprentissage P0. La requête est alors identifiée comme anomalie. Cependant, avec n = 1, il n'est pas possible de détecter des attaques de type « Cross-Site Request Forgery » dans lesquelles un attaquant amène une victime à réaliser une action malveillante sur un site sur lequel la victime bénéficie d'une session authentifiée en cours. A contrario, si l'on choisit une 10 valeur de n trop grande, le modèle construit durant la phase d'apprentissage PO est très fermé dans le sens où, durant la phase d'apprentissage P0, très peu de sessions partagent les mêmes segments. Même si l'on considère qu'une valeur de n élevée réduit considérablement le nombre de faux négatifs, ils peuvent contribuer à augmenter le nombre de faux positifs. En effet, il y a de fortes chances de rencontrer lors de la phase de détection P1 des séquences d'utilisation du 15 service qui n'ont pas été observées durant la phase d'apprentissage PO et qui ont donc de fortes chances d'être assimilées à des anomalies alors qu'elles représentent des comportements normaux. Dans une sous-étape E22 suivante de mesure de fréquence, on mesure pour la séquence obtenue et pour les différents segments élémentaires qui la composent, la fréquence de chacun 20 des segments élémentaires. Ainsi, pour le n-grammes , la fréquence du segment TaTb est 2, la fréquence du segment TbT. est 2, la fréquence du segment TcTa est 2, la fréquence du segment TaTa est 1, la fréquence du segment TaTd est 1 et aucun autre segment élémentaire n'apparaît. On reporte dans le vecteur de distribution d'apprentissage v, la fréquence ainsi mesurée pour les segments élémentaires qui composent la 25 séquence. Dans une étape suivante E23 de construction d'une matrice de distribution, le vecteur de distribution d'apprentissage v, propre à la session i est reporté dans une matrice de distribution MD, qui comprend autant de colonnes que de segments élémentaires possibles dans le cadre de l'utilisation du service et autant de lignes que de sessions analysées. La matrice d'observation 30 MD comprend ainsi en i-ième ligne le vecteur de distribution d'apprentissage v1. A noter que le n-grammes de la session i peut ne pas comprendre tous les segments possibles. Pour le n-grammes présenté ci-dessus, ne figurent pas par exemple les segments TbTb, T,Tc, etc. Ces segments apparaissent dans la matrice d'observation avec une fréquence égale à zéro pour la session i. On remarque que la matrice d'observation obtenue MD est une matrice très grande et 35 clairsemée. On est en effet sur un espace d'observation très grand en termes de nombre de 3038187 11 sessions analysées, de l'ordre de plus de 100000, les sessions ne sont pas limitées par le nombre de transactions élémentaires mises en oeuvre par l'utilisateur qui sont propres à chaque utilisateur. Par ailleurs la matrice MD comprend beaucoup d'éléments à 0, une exécution de service explorant rarement l'ensemble des options possibles de ce service. 5 Les étapes E0, El et les sous-étapes E21, E22 et E23 de l'étape d'analyse sont itérées sur l'ensemble des sessions de la base d'observation BdO. Au terme de l'étape E2 d'analyse, on dispose d'une matrice d'observation MD représentative des sessions comprises dans la base d'observation BdO et plus précisément de l'enchaînement de transactions élémentaires dans les sessions, le nombre de transactions d'un 10 enchaînement dépendant de la valeur n choisie pour l'analyse n-grammes Dans une étape suivante E3 de classification double (ou « co-clustering », ou « biclustering » en anglais), il est procédé à une classification double sur la matrice de distribution MD, afin de regrouper des sessions qui représentent le même comportement. La classification double est une technique d'apprentissage non-supervisée (on parle de « machine 15 learning » en anglais) permettant de segmenter simultanément les lignes et les colonnes d'une matrice. Le principe de la classification double consiste à déplacer les lignes et les colonnes d'une matrice suivant un algorithme défini de co-clustering afin d'identifier dans la matrice des zones de densité. Un n-grammes intègre la notion d'ordre dans les n transactions qui le composent, et cet ordre est préservé au sein d'un même n-grammes lors de l'étape E3 de double 20 classification. On considère que le n-grammes permet de travailler sur des séquences partielles suffisantes pour détecter des anomalies. Ainsi, le déplacement des lignes et des colonnes, qui rompt en quelque sorte le séquencement d'une session d'utilisation analysée, n'est pas pénalisant pour la détection d'anomalies. La matrice de distribution résultante se rapproche d'une matrice diagonale ; elle comprend m regroupements de données f C1171 (ou « cluster » en 25 anglais) visibles. Chacun de ces clusters Cj, ou regroupement de données, représente un profil de comportement similaire en termes de transactions élémentaires mises en oeuvre durant l'exécution du service, par exemple, achat d'un jeu puis consultation d'e-mail, recherche dans un catalogue sans achat, recherche dans un catalogue avec achat, etc. La double classification produit également pour chaque regroupement de données Cr un 30 vecteur de référence Cj et un rayon Ti du regroupement de données. Le vecteur de référence Cj correspond au centre du cluster Cr ou centroïde ; il est représentatif d'un profil de comportement normal associé au regroupement de données, et le rayon Ti délimite une zone de densité autour du vecteur de référence. Le rayon Ti détermine une valeur seuil destinée à 3038187 12 déterminer si une nouvelle session fait ou non partie du cluster Cj, représentative d'un profil d'exécution normal. A titre d'exemple, la figure 3 présente une classification double mise en oeuvre sur une première matrice, à gauche sur la figure, et la matrice résultante, à droite sur la figure où 5 apparaissent clairement plusieurs regroupements de données. Pour mettre en oeuvre l'étape E3 de classification double, on utilise par exemple l'algorithme de co-clusterisation défini dans l'article « Co-clustering documents and words using bipartite spectral graph partitioning », I.S. Dillon, in Proceedings of SIGKDD, 2001. L'invention n'est pas limitée à cet algorithme et tout algorithme de double classification qui 10 produit un centroïde et un rayon par cluster peut être utilisé. Au terme de l'étape E3, on dispose d'une matrice de distribution MD qui modélise l'ensemble des comportements normaux d'utilisateurs du service. Dans l'exemple décrit ici, on a considéré que le peuplement de la base de données d'observation BdO s'effectuait dans un environnement sécurisé. L'invention n'est pas limitée à 15 un contexte sécurisé et dans un autre exemple, le peuplement de la base d'observations BdO s'effectue dans un environnement opérationnel. On considère en effet que globalement le ratio de comportements malhonnêtes par rapport aux comportements honnêtes est infime et qu'avec la procédé décrit ici, des comportements malhonnêtes enregistrés durant la phase d'apprentissage n'impacteront pas la construction du modèle et seront même susceptibles d'être 20 identifiés au terme de cette phase. En effet, la phase d'apprentissage et base d'observations reposent sur une quantité très importante de sessions utilisateur. On considère que les anomalies y sont peu nombreuses. Dans la phase suivante P1 de détection, décrite en relation avec la figure 2, toute 25 nouvelle session utilisateur, ou session courante, est analysée de la même manière qu'une session l'a été durant la phase d'apprentissage PO de manière à construire un vecteur de distribution n-grammes courant propre à la session courante. Le vecteur de distribution courant est alors comparé aux m clusters [C1171 obtenus lors de l'étape E3 de classification double de manière à être associé à un profil d'utilisation du service correspondant. Si le vecteur courant ne 30 correspond à aucun profil d'utilisation recensé durant la phase d'apprentissage Pl, la session courante est assimilée à une anomalie. La session courante comprend une liste ordonnée de transactions élémentaires courantes représentatives d'interactions entre l'utilisateur et le service. Dans une étape initiale E10, la session courante d'exécution du service est représentée sous forme d'une liste ordonnée de transactions élémentaires. 3038187 13 Dans une étape suivante Ell de remplacement de paramètres spécifiques, comparable à l'étape E0 de remplacement de paramètres spécifiques mise en oeuvre durant la phase d'apprentissage P0, des paramètres spécifiques de l'utilisateur des transactions élémentaires de la session courante sont remplacés par des paramètres génériques, représentatifs de leur 5 sémantique. Dans une étape suivante E12 d'analyse, la méthode statistique n-grammes telle qu'appliquée au cours de l'étape E2 d'analyse est appliquée aux transactions élémentaires obtenues au cours de l'étape Ell précédente. La valeur de n est identique à celle utilisée au cours de la phase PO d'apprentissage. L'application de la méthode n-grammes permet d'obtenir 10 une séquence de segments associée à la session courante. Il est mesuré ensuite la fréquence d'occurrence des segments différents de la séquence. Il est ensuite construit, de manière comparable à la sous-étape E23, un vecteur de distribution courant vc propre à la session courante. Ce vecteur vc comprend les mêmes colonnes que la matrice de distribution obtenue au terme de l'étape E3 de double classification et en j-ième position vc(j) la fréquence d'occurrence 15 du segment de la j-ième colonne. Au terme de l'étape E12 d'analyse, on dispose du vecteur de distribution vc propre à la session courante. A noter qu'il est possible que la session courante comprenne un segment courant qui n'a jamais été rencontré durant la phase d'apprentissage. Il n'est donc référencé ni dans les colonnes 20 de la matrice de distribution MD, ni dans les colonnes du vecteur de distribution vc. Cela peut correspondre à une anomalie Cela peut également correspondre à une évolution du service qui intègre de nouvelles fonctionnalités et qui peut donc être à l'origine de nouvelles transactions élémentaires. Dans ce cas, il est nécessaire de mettre en oeuvre de nouveau la phase d'apprentissage PO afin de mettre à jour la matrice de distribution MD et de tenir ainsi compte 25 des évolutions du service. Dans une étape suivante E13 d'évaluation, le vecteur de distribution courant vc est comparé aux m regroupements de données fC1171, représentatifs de profils de comportements normaux d'utilisation du service, afin d'identifier un profil Ck correspondant au comportement représenté par le vecteur de distribution courant vc. A cette fin, la distance entre le vecteur de 30 distribution vc et chacun des m vecteurs de référence {CJ}71 des m regroupements de données est comparée à chacune des valeurs seuil frj171 des regroupements de données représentative du rayon de chacun des cluster {CJ}71. Dans un premier cas (branche « ok » sur la figure 1) où la distance entre le vecteur de distribution vc et au moins un vecteur de référence Ck du cluster Ck est inférieure à la valeur seuil rk représentative du rayon du cluster Ck, alors la session 35 courante, associée au vecteur de distribution vc, est assimilée dans une étape E14 à un 3038187 14 comportement normal. Dans le cas contraire (branche « nok » sur la figure X), la session courante est assimilée à une anomalie dans une étape E15 d'anomalie Dans l'exemple décrit ici, les interactions de l'utilisateur avec le service sont décrites par une succession de requêtes d'URL. Une URL constitue un standard de fait utilisé pour 5 localiser des ressources sur Internet. L'utilisation des URL est donc applicable à tous les types de protocoles Internet, tels que http, « P2P » (de l'anglais « Peer To Peer »), et « FTP » (de l'anglais « File Transfer Protocol »). L'invention n'est cependant pas limitée aux requêtes d'URL pour la description de sessions utilisateur et s'applique également à des requêtes qui englobent d'autres entêtes http. Par ailleurs, d'autres types d'informations représentatives des 10 interactions de l'utilisateur avec un service et que l'on peut trouver dans les fichiers de logs peuvent être utilisés. Dans l'exemple décrit ici, les interactions sont décrites sous forme de transactions élémentaires entre un utilisateur et un service. L'invention n'est pas limitée à cet exemple et peut s'appliquer à un cas ou un premier service interagit avec un deuxième service au cours 15 d'une session. Les interactions entre les deux services durant la session se présentent sous la forme de transactions élémentaires. Les étapes du procédé décrit précédemment s'appliquent alors de la même façon. Le procédé trouve une application intéressante pour la détection d'anomalies dans des services complexes. De tels services sont par exemple des services d'achat en ligne, des services 20 opérateur de gestion d'abonnements mobiles et Internet. Il trouve également une application intéressante pour la configuration d'environnements en cloud computing. En effet, une telle configuration qui consiste à configurer des machines de virtuelles en termes de nombre de machines, de ressources, à bouger de telles machines s'effectue au moyen de transactions Internet. Chacune des opérations effectuées constitue un service compris dans le service de 25 configuration. Un dispositif 40 de détection d'anomalies dans l'exécution d'un service va maintenant être décrit en relation avec la figure 4. Le dispositif de détection d'anomalies est un équipement informatique, tel qu'un 30 serveur, agencé pour identifier qu'une session courante d'utilisateur comprenant des transactions élémentaires relatives à l'exécution d'un service correspond à une anomalie ou à un comportement normal d'utilisateur. A cette fin, le dispositif de détection 4 comprend une application autonome d'analyse de journaux d'exécution. Le module d'analyse comprend des instructions logicielles agencées pour mettre en oeuvre les étapes du procédé de détection 35 d'anomalies tel que décrit précédemment. 3038187 15 Le dispositif 40 comprend : - une unité de traitement 41, ou « CPU » pour « Central Processing Unit », - un ensemble de mémoires, dont une mémoire volatile 42, ou « RAM » (pour « Random Access Memory ») et une mémoire morte 43 de type « ROM » (de l'anglais « Read 5 Only Memory ») et une mémoire de stockage 44 de type mémoire flash ou « EEPROM » (pour « Electrically-Erasable Programmable Read Only Memory). La mémoire volatile 42 est agencée pour exécuter des instructions de code, stocker des variables, etc. La mémoire de stockage 44 est agencée pour mémoriser des données. En particulier, la mémoire de stockage 44 mémorise l'application de détection d'anomalies qui comprend des instructions de code pour mettre en 10 oeuvre les étapes du procédé de détection d'anomalies tel que décrit précédemment ; Des interfaces de communication 45, agencées pour accéder aux données issues de l'étape de de double classification, en l'espèce les vecteurs de référence des groupements de données et les valeurs seuil. Le dispositif comprend également : 15 - un module 46 d'obtention d'une liste ordonnée d'au moins deux transactions élémentaires pour une session courante d'exécution d'un service par une entité. L'entité peut être un utilisateur ou un autre service. Le module 46 d'obtention d'une liste est agencé pour mettre en oeuvre l'étape E10 du procédé de détection d'anomalie tel que décrit précédemment ; - un module 47 de construction d'un vecteur de distribution et d'association, agencé 20 pour construire, pour la session courante un vecteur de distribution vc dont les entrées correspondent aux entrées d'au moins un vecteur de référence Cj, une entrée du vecteur de référence correspondant à un segment élémentaire de taille fixe d'au moins une transaction élémentaire. Le module 46 est également agencé pour associer à une entrée du vecteur de distribution un nombre d'occurrences du segment élémentaire correspondant dans la liste 25 ordonnée, ledit vecteur de référence étant représentatif d'un profil de comportement normal d'utilisation du service. Le module 47 de construction d'un vecteur de distribution et d'association est agencé pour mettre en oeuvre l'étape Ell du procédé de détection d'anomalies décrit précédemment ; et - un module d'identification 48, agencé pour identifier la session courante comme 30 normale lorsque la distance entre le vecteur de distribution et le vecteur de référence est inférieure à une valeur seuil Ti associée au vecteur de référence. La valeur seuil Ti correspond au rayon d'un cluster ou groupement de données C1 dont le vecteur de référence est Cj. Le module d'identification 48 est agencé pour mettre en oeuvre l'étape E13 du procédé de détection d'anomalies décrit précédemment. 3038187 16 Le module 46 d'obtention d'une liste ordonnée d'au moins deux transactions élémentaires, le module 47 de construction d'un vecteur de distribution et d'association et le module d'identification 48 sont de préférence des modules logiciels comprenant des instructions logicielles pour faire exécuter les étapes de la phase Pl de détection d'anomalies du procédé 5 décrit précédemment. L'invention concerne donc aussi : - un programme d'ordinateur comportant des instructions pour la mise en oeuvre du procédé de détection d'anomalies tel que décrit précédemment lorsque ce programme est exécuté par un processeur du dispositif 40 de détection d'anomalies, et 10 - un support d'enregistrement lisible sur lequel est enregistré le programme d'ordinateur décrit ci-dessus. Les modules logiciels peuvent être stockés dans, ou transmis par un support de données. Celui-ci peut être un support matériel de stockage, par exemple un CD-ROM, une disquette magnétique ou un disque dur, ou bien un support de transmission tel qu'un signal ou un réseau 15 de télécommunication. Dans un exemple de réalisation, correspondant au cas où le dispositif 40 de détection d'anomalies est agencé pour mettre en oeuvre la phase PO d'apprentissage, le dispositif 40 comprend également les modules suivants (non représentés sur la figure 4): - une deuxième interface de communication, agencée pour accéder à la base 20 d'observations Bd0 ; - un module d'obtention d'une liste ordonnée d'apprentissage d'au moins deux transactions élémentaires d'apprentissage, - un module de construction d'un vecteur de distribution d'apprentissage v, dont les entrées correspondent aux entrées du vecteur de référence, à une entrée du vecteur de 25 distribution d'apprentissage on associe un nombre d'occurrences du segment élémentaire d'apprentissage correspondant dans la liste ordonnée d'apprentissage, - un module de construction d'une matrice de distribution par ajout dudit vecteur de distribution d'apprentissage, ladite matrice d'observation comprenant en i-ième ligne un i-ième vecteur de distribution d'apprentissage, 30 et, - un module de modification et d'obtention, agencé pour modifier l'ordre des colonnes et des lignes de la matrice de distribution obtenue pour l'ensemble des sessions d'apprentissage pour constituer des groupements de valeurs autour de la diagonale de la matrice, et pour obtenir pour chaque groupement de valeurs, du vecteur de référence et de la valeur seuil associée. 3038187 17 Ces modules sont de préférence des modules logiciels, agencés pour mettre en oeuvre les étapes de la phase d'apprentissage du procédé d'aide à l'analyse de l'exécution d'une machine virtuelle tel que décrit précédemment. 5 REVENDICATIONS1. Procédé de détection d'anomalies dans l'exécution d'un service, comprenant : - une obtention (E10) d'une liste ordonnée d'au moins deux transactions élémentaires pour une session courante, lors d'une exécution du service par une entité, - une construction (El 1) pour la session courante d'un vecteur de distribution (va) dont les entrées correspondent aux entrées d'au moins un vecteur de référence (Cj), une entrée du vecteur de référence correspondant à un segment élémentaire de taille fixe d'au moins une transaction élémentaire, et association à une entrée du vecteur de distribution d'un nombre d'occurrences du segment élémentaire correspondant dans la liste ordonnée, ledit vecteur de référence étant représentatif d'un profil de comportement normal d'utilisation du service, - une identification (E13) de la session courante comme normale lorsque la distance entre le vecteur de distribution et le vecteur de référence est inférieure à une valeur seuil (Ti) associée au vecteur de référence. 2. Procédé selon l'une des revendications précédentes, comprenant un remplacement (El) d'au moins une valeur spécifique contenue dans les transactions élémentaires par une valeur générique. 3. Procédé selon l'une des revendications précédentes, dans lequel la liste ordonnée d'au moins deux transactions élémentaires est obtenue au moyen d'une analyse n-grammes des transactions élémentaires. 4. Procédé selon l'une des revendications précédentes comprenant une détection d'anomalie lorsque le segment élémentaire de la session courante ne figure pas parmi les entrées du vecteur de référence. 5. Procédé selon l'une des revendications précédentes, dans lequel la distance entre le vecteur de distribution et le vecteur de référence est la distance Euclidienne. 30 6. Procédé selon l'une des revendications précédentes, comprenant une phase d'apprentissage mise en oeuvre sur un ensemble de sessions d'apprentissage, comprenant pour une desdites sessions d'apprentissage associée à une exécution du service : - une obtention (E10) d'une liste ordonnée d'apprentissage d'au moins deux 35 transactions élémentaires d'apprentissage, 3038187 19 - une construction (E21) d'un vecteur de distribution d'apprentissage (vi) dont les entrées correspondent aux entrées du vecteur de référence, à une entrée du vecteur de distribution d'apprentissage on associe (E22) un nombre d'occurrences du segment élémentaire d'apprentissage correspondant dans la liste ordonnée d'apprentissage, 5 - une construction (E23) d'une matrice de distribution (MD) par ajout dudit vecteur de distribution d'apprentissage, ladite matrice d'observation comprenant en i-ième ligne un i-ième vecteur de distribution d'apprentissage, et, - une modification (E3) de l'ordre des colonnes et des lignes de la matrice de 10 distribution obtenues pour l'ensemble des sessions d'apprentissage, pour constituer des groupements de valeurs autour de la diagonale de la matrice, et une obtention pour chaque groupement (Cj) de valeurs, du vecteur de référence (Cj) et de la valeur seuil (Ti) associée. 7. Procédé selon la revendication 6, dans lequel les groupements de valeurs sont obtenus 15 par application d'un algorithme de classification double, ou de « co-clustering », à la matrice de distribution. 8. Dispositif de détection d'anomalies, comprenant : - un module (46) d'obtention d'une liste ordonnée, agencé pour obtenir une liste 20 ordonnée d'au moins deux transactions élémentaires pour une session courante, lors d'une exécution du service par une entité, - un module (47) de construction et d'association, agencé pour construire pour la session courante un vecteur de distribution (va) dont les entrées correspondent aux entrées d'au moins un vecteur de référence (Cj), une entrée du vecteur de référence correspondant à un 25 segment élémentaire de taille fixe d'au moins une transaction élémentaire, et pour associer à une entrée du vecteur de distribution d'un nombre d'occurrences du segment élémentaire correspondant dans la liste ordonnée, ledit vecteur de référence étant représentatif d'un profil de comportement normal d'utilisation du service, - un module (48) d'identification, agencé pour identifier la session courante comme normale lorsque la distance entre le vecteur de distribution et le vecteur de référence est inférieure à une valeur seuil associée au vecteur de référence. 9. Programme d'ordinateur sur un support de données et chargeable dans la mémoire d'un ordinateur, le programme comprenant des instructions de code pour l'exécution des étapes 3038187 20 du procédé de détection d'anomalies selon l'une des revendications 1 à 7, lorsque le programme est exécuté sur ledit ordinateur. 10. Support de données dans lequel est enregistré le programme selon la revendication 5 9. 10