FR 3089648 A1 20200612 FR 1872609 A 20181210 Description Titre de l'invention : PROCEDE DE DETECTION NON SUPERVISE D'ATTAQUES INTERNES ET SYSTEME ASSOCIE Domaine technique [0001] Le domaine technique de l'invention est celui de la détection d'attaques internes à un système d'information. La présente invention concerne un procédé de détection non supervisé d'attaques internes à un système d'information par modélisation automatique du comportement des utilisateurs du système d'information. ARRIERE-PLAN TECHNOLOGIQUE DE L'INVENTION [0002] L'objectif de la surveillance de systèmes d'information est de détecter les attaques à l'encontre d'un ou plusieurs systèmes d'information. [0003] Ces attaques peuvent être diffuses, c'est-à-dire sans cible précise, ne ciblant pas un système d'information en particulier voire même le grand public, comme par exemple les vers, les spains, les virus. [0004] Mais ces attaques peuvent aussi être ciblées vers un système d'information en par- ticulier, le plus souvent de gnuides organisations comme des entreprises, pour récupérer des informations sensibles ou pour les détruire. L'attaquant analyse alors le système d'information et cherche les failles qui lui permettraient de le pénétrer. Il peut par exemple mettre en oeuvre une menace persistante avancée (« APT » selon la dénomination anglo-saxonne « Advanced Persistent Threat »), un type d'attaque furtif et continu. L'objectif est alors d'effectuer des tâches spécifiques comme récupérer des données sensibles le plus longtemps possible et rester inaperçu pendant cette période. Une attaque interne peut même être mise en oeuvre par un employé, qui enverrait alors des informations sensibles par mail ou en copierait sur des supports de stockage amovibles. 100051 Ces attaques sont ainsi caractérisées par des signaux faibles, difficilement dé- tectables. Lorsqu'elles sont mises en oeuvre par un employé, il n'est pas non plus possible de détecter une présence étrangère au sein du système. De plus, ces attaques étant le résultat d'analyses poussées du système d'information, et donc de son dispositif de détection, elles sont souvent inconnues de celui-ci. 100061 Pour détecter ce type d'attaques internes, l'emploi massif de cyber analystes capturant des évènements spécifiques est couramment mis en oeuvre. Cependant cette solution coûte cher et ne permet pas de détecter tous les signaux faibles à tout moment de la journée. Des règles métiers complexes couvrant spécifiquement un type d'attaque sont aussi utilisées dans l'état de la technique, mais il est alors nécessaire de connaître le type d'attaque pour la détecter, ce qui n'est pas toujours le cas. Une autre solution 2 mise en oeuvre est l'implémentation d'un système automatique analysant différentes variables du système d'information clans le temps permettant de détecter une divergence. Cependant, ces systèmes sont conçus pour analyser des données provenant de sources prédéfinies, et ne sont donc pas capable de gérer des sources de données inconnues. [0007] Toutes ces solutions sont réalisées sur mesures, elles dépendent des sources, sont souvent limitées par leurs capacités de traitement et ne savent pas bien identifier les attaques non répertoriées par le système. [0008] TI existe donc un besoin de mettre en place un procédé de détection d'attaques internes capable de détecter des attaques internes non répertoriées, d'être utilisé dans plusieurs système d'information aux topologies et aux données et types de données traités différents, et de s'adapter à de grandes quantités de données. Résumé de l'invention [0009] L'invention offre une solution aux problèmes évoqués précédemment, en proposant un procédé de détection d'attaques internes capable de s'adapter à différents systèmes d'information, de traiter de gros volumes de données de manière exhaustive, de détecter des signaux faibles et des attaques jusqu'alors inconnues en modélisant automatiquement le comportement des utilisateurs du système d'information. [0010] Pour cela, un aspect de l'invention concerne un procédé de détection d'attaques internes à au moins un système d'information comprenant : Une étape de réception de fichiers d'évènements ; Une étape de distribution des fichiers d'évènements reçus entre plusieurs modules de traitement de fichiers d'évènements ; Une étape de traitement de fichiers d'évènements, comprenant : - Une sous-étape de synchronisation des fichiers d'évènements dans une même fenêtre de temps et - Une sous-étape d'extraction de caractéristiques des fichiers d'évènements synchronisés pour créer une matrice ; Une étape de sélection de caractéristiques comprenant : - Une sous-étape de calcul de moments statistiques de la matrice pour obtenir un premier jeu de caractéristiques ; Une étape de détection d'attaques internes en utilisant un réseau de neurones récurrents et le jeu de caractéristiques précédemment créé comprenant la classification des caractéristiques du jeu de caractéristiques comme appartenant à une classe « comportement normal » ou comme appartenant à une classe « comportement suspect » et le calcul d'un score d'anomalie du jeu de caractéristiques ; 3 Une étape d'analyse de la cause de la détection d'attaque pour déterminer au moins une caractéristique du jeu de caractéristiques à partir de laquelle la détection d'attaque a eu lieu. [0011] La présente invention utilise avantageusement les fichiers d'évènements créés par les différentes applications employées par un utilisateur d'un système d'information pour décrire le comportement de l'utilisateur. Cela implique un volume de données important à traiter, car les fichiers d'évènements sont très nombreux. [0012] Ainsi, l'étape de distribution des fichiers d'évènements entre différents modules de traitement en parallèle permet avantageusement la scalabilité du procédé, c'est-à-dire de s'adapter aux volumes de fichiers d'évènements reçus, évitant ainsi la création de goulot d'étranglement à l'étape de traitement, qui est la plus utilisatrice de ressources. Cela permet avantageusement de détecter une attaque dans un intervalle de temps le moins long possible, car la durée de prise de décision sur chaque donnée en entrée n'augmente pas avec le volume de données en entrée. [0013] De plus, l'étape de sélection de caractéristiques comprend une première étape de calcul de moments statistiques, permettant avantageusement de décrire dans un premier temps les fichiers d'évènements reçus. L'étape de sélection de caractéristiques comprend en outre une seconde étape de réduction de dimensionalité, permettant avantageusement la scalabilité du procédé, puisque les caractéristiques sélectionnées décrivent les fichiers d'évènements reçus tout en réduisant la volumétrie de données à analyser. Les moments statistiques et les caractéristiques sélectionnées forment un ensemble de variables explicatives des données reçues, permettant une prise de décision sur des données ayant subi le moins de perte d'informations possible tout en ayant une dimensionalité réduite. [0014] L'étape de détection d'attaques internes utilise un réseau de neurones récurrent, permettant avantageusement de détecter des signaux faibles sur une longue durée ou des attaques jusqu'alors inconnues. En effet, de tels réseaux de neurones sont capables d'analyser des séries temporelles. Ainsi, en fournissant en entrée un jeu de fichiers d'évènements correspondant à une série temporelle, et en supposant que le réseau de neurones a déjà appris de séries temporelles précédentes, celui-ci sera capable de détecter une déviation dans le comportement des utilisateurs. [0015] En outre, le procédé selon l'invention est capable de déterminer la ou les caracté- ristiques à l'origine de la détection d'attaque et donc de caractériser l'attaque de manière précise. [0016] Outre les caractéristiques qui viennent d'être évoquées dans le paragraphe précédent, le procédé de détection d'attaques internes selon un aspect de l'invention peut présenter une ou plusieurs caractéristiques complémentaires parmi les suivantes, considérées individuellement ou selon toutes les combinaisons techniquement possibles : Le procédé comprend en outre : Une sous-étape de réduction de dimensionalité de la matrice pour obtenir un second jeu de caractéristiques ; Une sous-étape de création d'un jeu de caractéristiques comprenant le premier et le second jeu de caractéristiques précédemment créés ; Une étape d'entraînement du réseau de neurones récurrents pour estimer un modèle à partir d'un jeu de données divisé en données d'entraînement et en données de test comprenant : une sous-étape de recherche d'hyperparamètres à partir des données d'entraînement ; sous-étape de stockage des hyperparamètres trouvés ; une sous-étape d'estimation du modèle à partir des hyperparamètres stockés précédemment et des données d'entraînement ; une sous-étape de stockage du modèle estimé ; Une étape de test du modèle stocké, en utilisant des données de test provenant du jeu de données comprenant : - une sous-étape de classification les données de test comme appartenant à une classe « comportement normal » ou comme appartenant à une classe « comportement suspect » par le réseau de neurones récurrents en utilisant le modèle estimé ; - une sous-étape de calcul d'au moins une métrique permettant d'évaluer la performance de classification du réseau de neurones récurrents utilisant le modèle estimé ; - une sous-étape de validation du modèle estimé par un opérateur. Le réseau de neurones récurrents est de type réseau Long short-terni memory « LSTM ». L'étape de recherche d'hyperparamètres comprend l'utilisation d'un algorithme d'optimisation bayésienne par processus gaussien implémenté par un module de recherche d'hyperparamètres ; Les métriques d'évaluation de performance sont choisies parmi les métriques de précision et rappel au rang k, d'aire sous la courbe d'efficacité du récepteur, de F-Score. Les moments statistiques calculés sont choisis parmi les moments statistiques de somme des occurrences pour un intervalle de temps, valeur moyenne, écart type, coefficient d'asymétrie statistique, degré de voussure. La sous-étape de réduction de dimensionalité comprend l'utilisation d'une analyse en composantes principales. - - - - [0017] Un autre aspect de l'invention concerne un système mettant en oeuvre le procédé selon l'invention comprenant : Un module de réception et de distribution de fichiers d'évènements issus du système d'information comprenant : - Un sous-module de réception de fichiers d'évènements ; - Un sous-module de distribution de fichiers d'évènements, configuré pour distribuer les fichiers d'évènements entre une pluralité de modules de traitement ; Une pluralité de modules de traitement des fichiers d'évènement en parallèle, chaque module de traitement comprenant : - Un sous-module de traitement configuré pour réaliser l'étape de traitement des fichiers d'évènements et - Un sous-module de sélection de caractéristiques, chaque module de sélection étant configuré pour réaliser l'étape de sélection de caractéristiques ; Un module de détection d'attaques internes implémentant un réseau de neurones récurrent, configuré pour réaliser l'étape de classification ; Un module d'analyse configuré pour réaliser l'étape d'analyse de la cause de la détection d'attaque. [0018] Outre les caractéristiques qui viennent d'être évoquées dans le paragraphe précédent, le système de détection d'attaques internes selon un aspect de l'invention peut présenter une ou plusieurs caractéristiques complémentaires parmi les suivantes, considérées individuellement ou selon toutes les combinaisons techniquement possibles : [0019] Le système comporte en outre : Un module de stockage, configuré pour stocker des données d'apprentissage et des données d'évaluation, lesdites données d'apprentissage et d'évaluation provenant d'un même jeu de fichiers d'évènements ; Un module d'entraînement du réseau de neurones récurrents, comprenant : - Un sous-module de recherche d'hyperparamètres, à partir des données d'apprentissage ; - Un sous-module de stockage des hyperparamètres trouvés ; - Un sous-module d'estimation de modèle avec les données d'apprentissage et les hyperparamètres stockés ; Un module de stockage du modèle créé, pour permettre au réseau de neurones de l'utiliser ; Un module de test du modèle estimé comprenant : - Un sous-module de classification configuré pour réaliser l'étape de 6 classification des données de test; - Un sous-module de calcul configuré pour réaliser l'étape de calcul de métriques ; - Un sous-module de validation configuré pour réaliser l'étape de validation du modèle estimé. [0020] L'invention et ses différentes applications seront mieux comprises à la lecture de la description qui suit et à l'examen des figures qui l'accompagnent. Brève description des dessins [0021] Les figures sont présentées à titre indicatif et nullement limitatif de l'invention. La figure 1 montre une représentation schématique du procédé selon l'invention. La figure 2 montre une représentation schématique d'une première étape du procédé selon l'invention. La figure 3 montre une représentation schématique d'une seconde étape du procédé selon l'invention. La figure 4 montre une représentation schématique d'une cinquième étape du procédé selon l'invention. La figure 5 montre une représentation schématique d'une sixième étape du procédé selon l'invention. La figure 6 montre une représentation schématique du système selon l'invention. La figure 7 montre une représentation schématique d'un module dc réception et distribution de données du système selon l'invention. La figure 8 montre une représentation schématique d'un module dc traitement de données du système selon l'invention. La figure 9 montre une représentation schématique d'un module d'entraînement du système selon l'invention. La figure 10 montre une représentation schématique d'un module dc test du système selon l'invention. Description des modes de réalisation 100221 Les figures sont présentées à titre indicatif et nullement limitatif de l'invention. 100231 Ifig.11 montre une représentation schématique du procédé selon l'invention. 100241 Ifig.21 montre une représentation schématique d'une première étape du procédé selon l'invention. 100251 Ifig.31 7 montre une représentation schématique d'une seconde étape du procédé selon l'invention. [0026] [fig.4] montre une représentation schématique d'une cinquième étape du procédé selon l'invention. [0027] [fig.5] montre une représentation schématique d'une sixième étape du procédé selon l'invention. [0028] [fig.6] montre une représentation schématique du système selon l'invention. [0029] [fig.7] montre une représentation schématique d'un module de réception et distribution de données du système selon l'invention. [0030] [fig.8] montre une représentation schématique d'un module de traitement de données du système selon l'invention. [0031] [fig.9] montre une représentation schématique d'un module d'entraînement du système selon l'invention. [0032] [fig.10] montre une représentation schématique d'un module de test du système selon l'invention. [0033] Sauf précision contraire, un même élément apparaissant sur des figures différentes présente une référence unique. [0034] Un mode de réalisation du procédé de détection d'attaques internes à un système d'information selon l'invention est représenté schématiquement Figure 1. [0035] Par « système d'information » on entend un ensemble organisé de ressources permettant la collecte, le stockage, le traitement et la distribution de l'information au sein d'une organisation. Un système d'information a pour objectif de restituer une information à une personne à un moment donné, sous le format approprié. Il peut être un réseau composé par exemple de terminaux utilisateurs et d'équipement d'interconnexion réseau. [0036] Le procédé 100 de détection d'attaques internes à un système d'information comprend une étape 10 d'entraînement d'un réseau de neurones récurrent, une étape 20 de test d'un modèle estimé, une étape 30 de réception de fichiers d'évènements, une étape 40 de distribution de fichiers d'évènements entre une pluralité de modules de traitement, une étape 50 de traitement des fichiers d'évènements, une étape 60 de sélection de caractéristiques, une étape 70 de détection d'attaques internes et une étape 8 80 d'analyse de cause. [0037] La première étape 10 d'entraînement d'un réseau de neurones récurrents représentée schématiquement Figure 2, comprend quatre sous-étapes. [0038] Par « réseau de neurones » on entend une structure complexe formée d'une pluralité de couches, chaque couche comportant une pluralité de neurones artificiels. Un neurone artificiel est un processeur élémentaire, qui calcule une sortie unique sur la hase des informations qu'il reçoit du neurone précédent. Chaque neurone d'une couche est relié à au moins un neurone d'une couche voisine via une synapse artificielle à laquelle est affectée un coefficient synaptique ou poids, mis à jour pendant l'étape d'entraînement. C'est lors de cette étape d'entraînement que le poids de chaque synapse artificielle va être déterminé à partir de données d'entraînement non annotées, l'ensemble des poids ainsi déterminés formant un modèle. Ce modèle estimé est ensuite testé et validé puis utilisé pour classifier des données non annotées. C'est pourquoi on dit que le procédé de détection d'attaques est « non supervisé » : il est entraîné avec des données non annotées et ne sait donc pas à l'entraînement à quelle classe correspondent les données d'entraînement qu'il reçoit. En fait, l'expert métier ne pourrait pas définir cela non plus, il ne pourrait donc pas annoter ces données d'entraînement, puisqu'il n'est pas possible de définir à l'avance l'attaque qui va être perpétrée, surtout dans le cas d'attaques internes comme expliqué précédemment. [0039] Les neurones d'un réseau de neurones sont dits « récurrents » lorsque le réseau de neurones comprend des interconnexions (synapses artificielles) récurrentes, c'est-à-dire lorsqu'il existe au moins un cycle dans la structure du réseau de neurones. Cela permet au réseau de neurones de mémoriser des états passés et ainsi de traiter des séries temporelles. [0040] Un cas particulier de ces réseaux de neurones récurrents est le réseau « LSTM » (selon la dénomination anglo-saxonne « Long Short-Terni Memory »), qui est un réseau de neurones récurrents dont les unités computationnelles (les neurones artificiels) sont composées d'une cellule, d'une porte d'entrée, d'une porte de sortie et d'une porte dite « d'oubli ». La cellule prend une donnée d'entrée et la stocke pour un certain temps. La porte d'entrée, ou de mise à jour, contrôle les données qui entrent dans la cellule, la porte de sortie contrôle à quel moment les données stockées doivent être utilisées en sortie de la cellule, et la porte d'oubli contrôle dans quelle mesure la donnée reste stockée dans la cellule. Les LSTM sont particulièrement adaptés pour traiter des séries temporelles de données. Ils permettent notamment, grâce à la porte de mise à jour, de résoudre le problème des réseau de neurones récurrents classiques qui est celui de la disparition du gradient, qui les empêche de modifier le poids de leurs synapses artificielles en fonction d'évènement passés. [0041] Le procédé 100 reçoit en entrée des fichiers d'évènement. Ainsi, le jeu de données 1 9 comprenant les jeux de données d'entraînement 2 et de test 3 comprend des fichiers d'évènements. Tous les fichiers d'évènements compris dans les jeux de données 2 et 3 ont été préalablement traités et des caractéristiques en ont été sélectionnées. Ces étapes de traitement et dc sélection de caractéristiques auxquelles ont été soumis les fichiers d'évènements sont similaires aux étapes 40 de distribution, 50 de traitement et 60 de sélection de caractéristiques du procédé 100 décrites par la suite. Par « caractéristiques » on entend un ensemble de variables explicatives des données. Par exemple, pour une image, des caractéristiques peuvent être un décompte d'occurrence des couleurs dominantes, la moyenne, la variance et l'asymétrie des couleurs dans chaque plan dc l'image. Ainsi, chacune des étapes 10 et 20 traite un jeu de caractéristiques et non un jeu de fichiers d'évènement. Le jeu de données d'entrée 4 comprend aussi des fichiers d'évènement. [0042] Par « fichier d'évènements » on entend un fichier relatant d'un évènement sur l'environnement de travail informatique d'un utilisateur du système d'information tel qu'un fichier log. Un fichier log est un fichier regroupant l'ensemble des évènements survenus sur un logiciel, une application, un serveur. Par exemple, un fichier d'évènements peut comprendre plusieurs lignes correspondant à plusieurs évènements, possédant chacun une date, une courte description de l'évènement, ainsi que des informations sur l'évènement. Par exemple, pour un fichier d'évènements d'application mail, une ligne pourra correspondre à l'envoi d'un mail et comprendre la date et l'heure d'envoi, l'objet du mail, le ou les destinataires, l'expéditeur, le nombre de pièces jointes et leurs noms. [0043] Une première sous-étape 11 comprend la recherche d'hyperparamètres du réseau de neurones. Les hyperparamètres sont des paramètres du réseau de neurones pour lesquels la valeur est fixée avant estimation du modèle de réseau de neurones. Ces hypeiparamètres peuvent être par exemple la longueur des séries temporelles à fournir en entrée du réseau de neurones, le nombre de neurones, le nombre de couches par cellule LSTM, le taux d'apprentissage (valeur qui contrôle la taille des ajustements effectués durant l'étape d'estimation du modèle). [0044] Cette sous-étape 11 d'estimation d'hyperparamètres est réalisée en utilisant un al- gorithme d'optimisation bayésienne par processus gaussien, expliqué dans le document [« Practical Bayesian Optimization of Machine Learning Algorithms », Jasper Snoek ET AL [US], Advances in Neural Information Processing Systems, 2012] et des données d'entraînement 2. Les données d'entraînement 2 proviennent d'un jeu de données 1 (représenté Figure 1) sélectionné par un expert métier. Les données d'entraînement 2 peuvent par exemple comprendre 80% du jeu de données 1. Les données d'entraînement 2 ne sont pas annotées comme appartenant à une classe comportement normal » ou à une classe « comportement suspect » par un expert métier car les types d'attaques ne sont pas forcément connus à l'avance, les déviations pas encore détectées. C'est pourquoi on dit que le système est « non supervisé » : il apprend à partir d'exemples d'utilisation normale et décidera par la suite de cc qui n'appartient pas à ce comportement normal. Les hyperparamètres sélectionnés sont ceux qui optimisent la fonction objectif (selon la dénomination anglo-saxonne « loss function »). La fonction objectif compare la sortie du réseau de neurones pour une donnée d'entraînement 2 en entrée, à la sortie attendue pour cette même donnée d'entraînement 2. Cette fonction objectif peut être par exemple la distance euclidienne au carré, ou l'entropie croisée. En minimisant cette fonction objectif, on s'approche le plus possible de la sortie attendue. On cherche donc les hyperparamètres qui minimisent cette fonction objectif. [0045] La seconde sous-étape 12 est une étape de stockage des hyperparamètres trouvés. [0046] La troisième sous-étape 13 est une étape d'estimation du modèle de réseau LSTM. Cette étape d'entraînement est effectuée en utilisant les mêmes caractéristiques extraites des données d'entraînement 2 que lors de l'étape 11 de recherche d' hyperparamètres, et les hyperparamètres trouvés lors de cette même étape 11, stockés à l'étape 12. Ainsi, cette troisième sous-étape 13 comprend l'estimation de poids des synapses artificielles du réseau LSTM. L'estimation des poids est ajustée à chaque itération, en comparant les données en sortie à partir d'une donnée d'entraînement 2 en entrée, à la donnée en sortie attendue. A la fin de cette sous-étape 13, un modèle est estimé. [0047] La quatrième sous-étape 14 est une étape de stockage du modèle estimé pour pouvoir le réutiliser par la suite. [0048] Une deuxième étape 20 du procédé 100 selon l'invention est une étape de test du modèle estimé. Cette étape 20 est représentée schématiquement Figure 3 et comprend trois sous-étape 21, 22 et 23. [0049] Une première sous-étape 21 de classification de données de test 3 permet de tester le modèle estimé. Les données de test 3 proviennent du même jeu de données 1 (représenté schématiquement Figure 1) que les données d'entraînement 2 utilisées à l'étape précédente 10. Les données de test 3 comprennent par exemple 20% du jeu de données 1. Les données de test 3 sont donc classifiées soit comme appartenant à une classe « comportement suspect » soit comme appartenant à une classe « comportement normal ». [0050] On entend par « classifiées comme appartenant à une classe » l'ajout d'un label à la donnée indiquant sa classe. [0051] Une fois les données de test 3 classifiées, lors de la sous-étape 22, des métriques sont calculées automatiquement. Ces métriques d'évaluation de performance peuvent comprendre les métriques de précision et rappel au rang k, d'aire sous la courbe 11 d'efficacité du récepteur, de F-Score. La métrique de précision et rappel au rang k comprend le calcul des métriques de précisions et de rappel. La métrique de précision détermine le taux de positifs qui ont été classés correctement : [0052] [Math .1] VP VP + FP' [0053] où VP désigne « vrais positifs », le taux de « comportement normal » ayant été classés dans la classe « comportement normal » et où FP désigne « Faux positifs le taux de « comportement suspect » réels ayant été classés dans la classe « comportement normal ». La métrique de rappel détermine le taux de vrais positifs : [0054] [Math.2] P VP + EN [0055] où VP désigne « vrais positifs », le taux de « comportement normal » ayant été classés dans la classe « comportement normal » et où FN désigne « Faux négatifs », le taux de « comportement normal » réels ayant été classés dans la classe « comportement suspect »). La métrique de précision et rappel est ainsi une courbe traçant la précision en fonction du rappel. La métrique de précision et rappel au rang k ne prend en compte que les k premières données. Dans un réseau de neurones récurrents classant les données dans un ordre particulier, cette métrique est particulièrement intéressante pour connaître la performance du réseau de neurones sur les k premières données, généralement les plus importantes. Cette métrique se calcule à partir de la précision au rang k et du rappel au rang k. Ces métriques se calculent de la façon suivante : [0056] Pour la précision : [Math.3] Précision sur les k premières données Précision sur toutes les données [0057] Pour le rappel : [Math.4] Rappel sur les k premières données Rappel sur toutes les données [0058] La métrique d'aire sous la courbe d'efficacité du récepteur (« ROC AUC » selon la dénomination anglo-saxonne « Receiver Operating Characteristic Area Under Curve ») est la mesure de l'aire sous une courbe qui trace le taux de « comportement normal » classifiés en tant que tel en fonction du taux de « comportement suspect » classifiés en tant que tel. [0059] La métrique de F-Score (ou F-Mesure) est une métrique qui combine la précision et le rappel, pondérées de façon égale. Ainsi, le F-Score F se calcule comme suit : [0060] 12 [Math.5] Précision x Rappel F - Précision + Rappel [0061] Ces métriques permettent à l'expert métier, dans une sous-étape 23 de validation, de prendre une décision éclairée quant à la fiabilité du modèle estimé. Cette décision peut être prise grâce à l'affichage des métriques calculées sur un écran. Lorsque le modèle estimé est validé, il peut être utilisé pour classifier des données non sélectionnées précédemment par un expert métier. [0062] Dans l'étape 30 de réception de fichiers d'évènements 4, le modèle a été validé et le système passe dans un mode « flux continu ». Les données 4 sont réceptionnées lors de l'étape 30 sans être sélectionnées par un expert métier comme auparavant. [0063] Dans une étape 40, les fichiers d'évènements 4 reçus sont distribués entre une pluralité de modules de traitement. Selon le volume de fichiers d'évènements reçus, un ou plusieurs modules de traitement peuvent être sélectionnés comme récepteurs de ces fichiers. Cela permet la répartition de charge entre les modules de traitement, et ainsi la capacité de traiter de plus gros volumes de données. Cela permet aussi d'économiser du temps en traitant les données en parallèles et d'économiser des ressources en utilisant seulement le nombre de modules de traitement nécessaire. [0064] Dans une étape 50, les fichiers d'évènements 3 distribués à l'étape 40 sont reçus par les différents modules de traitement. L'étape 50 est représentée schématiquement Figure 4 et comporte deux sous-étapes 51 et 52. [0065] Lors de la première sous-étape 51 de synchronisation, les fichiers d'évènements sont synchronisés dans une même fenêtre de temps. C'est-à-dire que les lignes du fichier d'évènement correspondant à des dates antérieures ou postérieures à une fenêtre de temps donnée que l'on veut étudier ne seront pas prises en compte. Ainsi seuls les évènements ayant eu lieu dans la fenêtre de temps d'intérêt sont gardés, pour ne pas fausser la détection d'attaque avec des signaux ne correspondant pas au comportement actuel de l'utilisateur. 100661 La seconde sous-étape 52 d'extraction de caractéristiques comprend par exemple, dans le cas d'un fichier d'évènements d'une application mail, l'extraction de caractéristiques telles que le nombre de destinataires, le nombre de pièces jointes, leurs types, la date et l'heure de l'envoi, le nombre de caractères du corps du texte, les mots récurrents. Ces caractéristiques peuvent être mises sous forme de matrice comprenant une étiquette définissant la caractéristique et la ou les valeurs correspondant à cette caractéristique. Ces caractéristiques peuvent être en nombre très important et donc représenter une volumétrie très importante de données à traiter. 100671 Pour pallier cela, l'étape 60 de sélection de caractéristiques représentée schéma- tiquement Figure 5 comprend trois sous-étape 61, 62 et 63. 13 [0068] La sous-étape 61 est une étape de calcul de moments statistiques sur la matrice des caractéristiques. Ces moments statistiques sont définis à l'avance par un expert métier. Ils peuvent être choisis parmi les moments statistiques de somme des occurrences pour un intervalle de temps, valeur moyenne, écart type, coefficient d'asymétrie statistique, degré de voussure. Par exemple, dans le cas d'un fichier d'évènement, le calcul de la somme des occurrences peut correspondre au calcul de la somme des occurrences de la caractéristique « nombre de mails envoyés » sur une période donnée (par exemple une journée). La valeur moyenne peut alors être le nombre moyen de mails envoyés chaque jour. L'écart type, le degré d'asymétrie statistique et le degré de voussure (aussi nommé kurtosis) permettent de définir au mieux une caractéristique avec le moins de perte d'information possible. Bien entendu, tout type de moment statistique connu de l'homme du métier peut être utilisé lors de cette sous-étape 61 tant qu'il permet de définir une caractéristique. [0069] La sous-étape 62 est une étape optionnelle de réduction de dimensionalité de la matrice de caractéristiques. Cette réduction de dimensionalité peut être effectuée par exemple par une Analyse en Composantes Principales (« ACP »), permettant de transformer les caractéristiques (qui sont corrélées entre elles puisque liées aux mêmes évènements) en nouvelles caractéristiques décorrélées les unes des autres. Ces nouvelles caractéristiques, dites composantes principales, sont en nombre moins important et permettent donc une réduction de la dimensionalité. Cela permet d'extraire des variables explicatives d'une grande volumétrie de données, donc de réduire la dimensionalité des données à traiter avec le moins de perte d'information possible. L'exemple de l'ACP a été pris, mais toute technique de réduction de dimensionalité de matrice connue de l'homme du métier peut être utilisée ici telles que l'analyse discriminante linéaire, l'analyse canonique des corrélations. [0070] La sous-étape 63 comprend la création d'un jeu de caractéristiques comprenant les moments statistiques calculés à la sous-étape 61 et les caractéristiques créées à la sous-étape optionnelle 62 si cette étape a eu lieu. Ainsi, on obtient un jeu de caractéristiques décrivant au mieux le jeu de données 4, permettant une réduction importante de la volumétrie de données à analyser tout en perdant le moins d'informations possibles du jeu de données 4 d'entrée. [0071] L'étape 70 de détection d'attaques internes comprend la classification du jeu de ca- ractéristiques compris dans un intervalle de temps donné (par exemple une journée) comme appartenant à une classe « comportement normal » ou comme appartenant à une classe « comportement suspect ». Cette classification est réalisée en utilisant un réseau de neurones (par exemple un LSTM) selon le modèle estimé à l'étape 10 d'entraînement. Ce modèle, entraîné à l'étape 10 et testé à l'étape 20, est capable de classifier des données de même nature que celles avec lesquelles il a été entraîné et 14 testé (c'est-à-dire des jeux de caractéristiques extraites à partir de fichiers d'évènements sur un intervalle de temps donné), car, comme expliqué précédemment, il peut mémoriser des séquences de données sur un intervalle de temps passé, et comparer les séquences de données reçues à ces séquences passées. Il peut ainsi comparer l'évolution des caractéristiques dans le temps et détecter des signaux faibles, des déviations d'un comportement « normal ». Cette étape 70 comprend de plus le calcul d'un score d'anomalie en comparant le jeu de caractéristiques présent (l'observation) et une prédiction basée sur les jeux de caractéristiques connus passés. Ce score d'anomalie peut être déterminé par exemple à partir du calcul d'une distance euclidienne entre l'observation et la prédiction ou par exemple à partir du logarithme négatif de la loi gaussienne multidimensionnelle appliqué à l'observation. Dans cc deuxième cas, la loi gaussienne multidimensionnelle est donnée par la prédiction et la matrice de covariance entre prédiction et observation. Une attaque est détectée lorsqu'un jeu de données est classé dans la classe « comportement suspect » et que le score d'anomalie dépasse un seuil prédéfini. [0072] La dernière étape 80 du procédé 100 comprend l'analyse de la cause de la détection d'attaque de l'étape 70. Cette analyse comprend l'isolation des caractéristiques ayant déclenché la détection d'attaque, en comparant chacune des caractéristiques du jeu de caractéristiques avec sa valeur moyenne sur un intervalle de temps donné passé. Les caractéristiques isolées pourront permettre à un expert métier de comprendre la cause de la détection d'attaque et donc potentiellement le type d'attaque dont il est question et le profil de l'attaquant. Par exemple, la détection d'attaque impliquant les fichiers d'évènements d'une application mail peut comprendre l'isolation des caractéristiques suivantes : nombre de nouveaux destinataires (les destinataires inconnus jusqu'à présent), nombre de mails envoyés sur la période étudiée, nombre et type des pièces jointes. Ces trois caractéristiques sont isolées car leurs valeurs sur la période étudiée sont plus élevées que la valeur moyenne sur les périodes précédentes. Elles permettent de décrire une attaque de type vol de données, où un attaquant ayant accès à l'ordinateur source transfère des données sensibles à un destinataire avec lequel il n'avait pas l'habitude de communiquer. [0073] La Figure 6 représente schématiquement un système 600 selon l'invention, mettant en oeuvre le procédé 100. Le système 600 comprend un module de réception et de distribution de fichiers d'évènements 610, une pluralité de modules de traitement 620, un module de stockage de données de test et d'entraînement 630, un module d'entraînement d'un réseau de neurones récurrents 640, un module de stockage de modèle estimé 650, un module de test du modèle estimé 660, un module de détection d'attaques internes 670 et un module d'analyse de cause de la détection 680. La Figure 6 représente aussi schématiquement un pluralité de sources de données 690, d'où pro- viennent les fichiers d'évènements. Une source de données peut être toute entité produisant des fichiers d'évènement, par exemple une application mail. [0074] La Figure 7 représente schématiquement le module 610 de réception et de dis- tribution des fichiers d'évènements 4. Ces fichiers d'évènements proviennent des sources 690. Le module 610 comprend deux sous-modules : un sous-module 611 de réception de fichiers d'évènements, et un sous-module 612 de distribution de fichiers d'évènements. [0075] Le premier sous-module 611 est configuré pour réaliser l'étape 30 de réception des fichiers d'évènements 4 depuis les sources 690. Il les transmet ensuite au sous-module 612. [0076] Le second sous-module 612 est configuré pour réaliser l'étape 40 de distribution de fichiers d'évènements 4 entre une pluralité de modules de traitement 620 en parallèle. En fonction de la volumétrie des données à distribuer, le sous-module 612 sélectionne un ou plusieurs modules de traitement 620 destinataires des fichiers d'évènements 4. [0077] La Figure 8 représente schématiquement le module 620 de traitement. Le module 620 de traitement comprend deux sous-modules 621 et 622. Le premier sous-module 621 est un sous-module de synchronisation configuré pour réaliser la sous-étape 51 de synchronisation des fichiers d'évènements. Le second sous-module 622 est un sous-module d'extraction de caractéristiques, configuré pour réaliser la sous-étape 52 d'extraction de caractéristiques. [0078] Une fois le jeu de caractéristiques, comprenant les moments statistiques calculés et les caractéristiques sélectionnées, créé à partir des fichiers d'évènements, un expert métier sélectionne les données d'entraînement et de test qui seront stockées par le module de stockage 630. Les données non sélectionnées comme étant des données d'entraînement et de test sont envoyées pour classification par le module de détection d'attaques internes 670. C'est le cas de toutes les données une fois qu'un modèle a été estimé à l'étape 20. [0079] La Figure 9 représente schématiquement le module 640 d'entraînement du réseau de neurones récurrent. Le module 640 est configuré pour réaliser l'étape 10 d'entraînement en utilisant les données d'entraînement 2 stockées par le module de stockage de données d'entraînement et de test 630. Le module 640 comprend trois sous-modules 641, 642 et 643. Le sous-module 641 est configuré pour réaliser la sous-étape 11 de recherche d'hypeiparamètres à partir des données d'entraînement 2. Le sous-module de stockage 642 est configuré pour réaliser l'étape 12 de stockage des hyperparamètres trouvés. Le sous-module 643 est configuré pour réaliser l'étape 13 d'estimation du modèle à partir des hyperparamètres stockés par le sous-module 642 et des données d'entraînement 2 stockées par le module 630. [0080] Le modèle estimé par le sous-module d'estimation de modèle 643 est ensuite stocké 16 par un module 650 de stockage de modèle configuré pour réaliser la sous-étape 14. [0081] Le module de test 660 représenté schématiquement Figure 10 est configuré pour réaliser l'étape 20 de test du modèle estimé en utilisant le modèle estimé stocké par le module 650 et les données de test 3 stockées par le module 630. Le module de test 660 comprend trois sous-modules 661, 662 et 663. Le sous-module 661 de test est configuré pour réaliser la sous-étape 21 de test du modèle estimé. Le sous-module 662 est configuré pour réaliser la sous-étape 22 de calcul de métriques. Le sous-module 663 est configuré pour réaliser la sous-étape 23 de validation du modèle estimé par un expert métier. Une fois le modèle estimé validé par l'expert métier, il est accessible par le module de détection d'attaques internes 670 pour classifier les jeux de caractéristiques entrants. [0082] Le module 670 de détection d'attaques internes est configuré pour réaliser l'étape 70 de détection d'attaques internes, en utilisant les jeux de caractéristiques sélectionnées à partir des fichiers d'évènements traités et le modèle estimé stocké par le module de stockage 650. Quand un jeu de données est classé comme appartenant à la classe « comportement suspect » et qu'un seuil prédéfini de score d'anomalie est dépassé, le module 670 envoie le jeu de caractéristiques classé comme appartenant à la classe « comportement suspect » au module 680 d'analyse de cause de la détection. [0083] Le module 680 d'analyse de cause de la détection est configuré pour réaliser l'étape 80 d'analyse de cause de la détection. Ce module 680 peut comprendre un écran d'affichage de la détection d'attaque et de l'analyse de la cause pour un expert métier. 17 [Revendication I] [Revendication 2]