FR3089648A1 - Procede de detection non supervise d’attaques internes et systeme associe - Google Patents
Procede de detection non supervise d’attaques internes et systeme associe Download PDFInfo
- Publication number
- FR3089648A1 FR3089648A1 FR1872609A FR1872609A FR3089648A1 FR 3089648 A1 FR3089648 A1 FR 3089648A1 FR 1872609 A FR1872609 A FR 1872609A FR 1872609 A FR1872609 A FR 1872609A FR 3089648 A1 FR3089648 A1 FR 3089648A1
- Authority
- FR
- France
- Prior art keywords
- sub
- module
- data
- event files
- neural network
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 49
- 238000001514 detection method Methods 0.000 title claims abstract description 34
- 238000012545 processing Methods 0.000 claims abstract description 39
- 238000013528 artificial neural network Methods 0.000 claims abstract description 37
- 230000000306 recurrent effect Effects 0.000 claims abstract description 25
- 238000004364 calculation method Methods 0.000 claims abstract description 13
- 239000011159 matrix material Substances 0.000 claims abstract description 13
- 238000012549 training Methods 0.000 claims description 46
- 230000006399 behavior Effects 0.000 claims description 34
- 238000012360 testing method Methods 0.000 claims description 34
- 230000008569 process Effects 0.000 claims description 11
- 230000009467 reduction Effects 0.000 claims description 8
- 238000010200 validation analysis Methods 0.000 claims description 8
- 238000011156 evaluation Methods 0.000 claims description 7
- 238000004422 calculation algorithm Methods 0.000 claims description 4
- 238000005457 optimization Methods 0.000 claims description 4
- 238000000513 principal component analysis Methods 0.000 claims description 3
- 230000006403 short-term memory Effects 0.000 claims description 3
- 230000001360 synchronised effect Effects 0.000 claims description 3
- 238000004590 computer program Methods 0.000 claims 1
- 210000002569 neuron Anatomy 0.000 description 10
- 230000006870 function Effects 0.000 description 7
- 210000004027 cell Anatomy 0.000 description 6
- 210000000225 synapse Anatomy 0.000 description 5
- 230000000875 corresponding effect Effects 0.000 description 4
- 238000000605 extraction Methods 0.000 description 4
- 239000003086 colorant Substances 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 238000002955 isolation Methods 0.000 description 2
- 230000002085 persistent effect Effects 0.000 description 2
- 241000700605 Viruses Species 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 230000002596 correlated effect Effects 0.000 description 1
- 238000010219 correlation analysis Methods 0.000 description 1
- 230000008034 disappearance Effects 0.000 description 1
- 230000010365 information processing Effects 0.000 description 1
- 238000010801 machine learning Methods 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000001537 neural effect Effects 0.000 description 1
- 238000003062 neural network model Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000000946 synaptic effect Effects 0.000 description 1
- 230000008685 targeting Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
- H04L63/1425—Traffic logging, e.g. anomaly detection
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/55—Detecting local intrusion or implementing counter-measures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/55—Detecting local intrusion or implementing counter-measures
- G06F21/552—Detecting local intrusion or implementing counter-measures involving long-term monitoring or reporting
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/55—Detecting local intrusion or implementing counter-measures
- G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
- G06F21/566—Dynamic detection, i.e. detection performed at run-time, e.g. emulation, suspicious activities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
- H04L63/1416—Event detection, e.g. attack signature detection
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Computer Hardware Design (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computing Systems (AREA)
- Health & Medical Sciences (AREA)
- General Health & Medical Sciences (AREA)
- Virology (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Abstract
PROCEDE DE DETECTION NON SUPERVISE D’ATTAQUES INTERNES ET SYSTEME ASSOCIE Un aspect de l’invention concerne un procédé de détection d’attaques internes à au moins un système d’information comprenant les étapes de : réception de fichiers d’évènements ; distribution des fichiers d’évènements reçus entre plusieurs modules de traitement; traitement des fichiers d’évènements, comprenant : la synchronisation des fichiers d’évènements et l’extraction de caractéristiques des fichiers d’évènements pour créer une matrice ; sélection de caractéristiques comprenant : calcul de moments statistiques de la matrice pour obtenir un premier jeu de caractéristiques ; 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 et le calcul d’un score d’anomalie du jeu de caractéristiques ; d’analyse de la cause de la détection d’attaque pour déterminer au moins une caractéristique du jeu de caractéristiques à l’origine de la détection d’attaque. Figure à publier avec l’abrégé : [Fig. 1]
Description
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 spams, les virus.
[0004] Mais ces attaques peuvent aussi être ciblées vers un système d’information en particulier, le plus souvent de grandes 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 œuvre 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 œuvre par un employé, qui enverrait alors des informations sensibles par mail ou en copierait sur des supports de stockage amovibles.
[0005] Ces attaques sont ainsi caractérisées par des signaux faibles, difficilement détectables. Lorsqu’elles sont mises en œuvre 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.
[0006] Pour détecter ce type d’attaques internes, l’emploi massif de cyber analystes capturant des évènements spécifiques est couramment mis en œuvre. 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 mise en œuvre est l’implémentation d’un système automatique analysant différentes variables du système d’information dans 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] Il 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 ;
- 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-term 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 L-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]
[0018]
[0019]
Un autre aspect de l’invention concerne un système mettant en œuvre 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.
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 :
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 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 de 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 de 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 de test du système selon l’invention.
Description des modes de réalisation
[0022] Les figures sont présentées à titre indicatif et nullement limitatif de l’invention.
[0023] [fig.l] montre une représentation schématique du procédé selon l’invention.
[0024] [fig.2] montre une représentation schématique d’une première étape du procédé selon l’invention.
[0025] [fig.3] 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 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 base 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-Term 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 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 de 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 de 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 hyperparamè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 algorithme 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é Ligure 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 ce 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 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.l]
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]
VP
VP + F N
[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 1’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]
[Math.5]
P _ Précision x Rappel r ~ 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 Ligure 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.
[0066] 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.
[0067] Pour pallier cela, l’étape 60 de sélection de caractéristiques représentée schématiquement Ligure 5 comprend trois sous-étape 61, 62 et 63.
[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 caracté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 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 ce 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 Ligure 6 représente schématiquement un système 600 selon l’invention, mettant en œuvre 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 Ligure 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 distribution 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 Ligure 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 sousmodule 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 Ligure 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’hyperparamè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é 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 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.
Claims (1)
-
Revendications [Revendication 1] 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 ; - 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. [Revendication 2] Procédé de détection d’attaques internes selon la revendication 1 caractérisé en ce que l’étape de sélection de caractéristiques comporte 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 ; [Revendication 3] Procédé de détection d’attaques internes selon 1’ une quelconque des revendications 1 ou 2 caractérisé en ce qu’il comporte en outre : - 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 ; • une 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. [Revendication 4] Procédé de détection d’attaques internes selon l’une quelconque des revendications précédentes caractérisé en ce que le réseau de neurones récurrents est de type réseau Long short-term memory « LSTM ». [Revendication 5] Procédé de détection d’attaques internes selon la revendication 3 caractérisé en ce que 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 ; [Revendication 6] Procédé de détection d’attaques internes selon l’une quelconque des revendications 3 ou 5 caractérisé en ce que 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. [Revendication 7] Procédé de détection d’attaques internes selon l’une quelconque des revendications précédentes caractérisé en ce que 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. [Revendication 8] Procédé de détection d’attaques internes selon l’une quelconque des revendications précédentes caractérisé en ce que la sous-étape de réduction de dimensionalité comprend l’utilisation d’une analyse en composantes principales. [Revendication 9] Système de détection d’attaques internes à au moins un système d’information mettant en œuvre le procédé selon l’une quelconque des revendications précédentes 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. [Revendication 10] Système de détection d’attaques internes selon la revendication 8, caractérisé en ce qu’il 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 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é.[Revendication 11] Programme d’ordinateur comportant des moyens pour l’exécution des étapes du procédé selon l’une quelconque des revendications 1 à 8 lorsque ledit programme est exécuté sur un ordinateur.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1872609A FR3089648A1 (fr) | 2018-12-10 | 2018-12-10 | Procede de detection non supervise d’attaques internes et systeme associe |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1872609A FR3089648A1 (fr) | 2018-12-10 | 2018-12-10 | Procede de detection non supervise d’attaques internes et systeme associe |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR3089648A1 true FR3089648A1 (fr) | 2020-06-12 |
Family
ID=67810630
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1872609A Pending FR3089648A1 (fr) | 2018-12-10 | 2018-12-10 | Procede de detection non supervise d’attaques internes et systeme associe |
Country Status (1)
| Country | Link |
|---|---|
| FR (1) | FR3089648A1 (fr) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11470106B1 (en) * | 2020-02-03 | 2022-10-11 | Rapid7, Inc. | Exploitability risk model for assessing risk of cyberattacks |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20140165207A1 (en) * | 2011-07-26 | 2014-06-12 | Light Cyber Ltd. | Method for detecting anomaly action within a computer network |
| US20170169360A1 (en) * | 2013-04-02 | 2017-06-15 | Patternex, Inc. | Method and system for training a big data machine to defend |
| US20180176243A1 (en) * | 2016-12-16 | 2018-06-21 | Patternex, Inc. | Method and system for learning representations for log data in cybersecurity |
-
2018
- 2018-12-10 FR FR1872609A patent/FR3089648A1/fr active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20140165207A1 (en) * | 2011-07-26 | 2014-06-12 | Light Cyber Ltd. | Method for detecting anomaly action within a computer network |
| US20170169360A1 (en) * | 2013-04-02 | 2017-06-15 | Patternex, Inc. | Method and system for training a big data machine to defend |
| US20180176243A1 (en) * | 2016-12-16 | 2018-06-21 | Patternex, Inc. | Method and system for learning representations for log data in cybersecurity |
Non-Patent Citations (1)
| Title |
|---|
| JASPER SNOEK ET AL.: "Practical Bayesian Optimization of Machine Learning Algorithms", ADVANCES IN NEURAL INFORMATION PROCESSING SYSTEMS, 2012 |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11470106B1 (en) * | 2020-02-03 | 2022-10-11 | Rapid7, Inc. | Exploitability risk model for assessing risk of cyberattacks |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FR3082963A1 (fr) | Systeme et procede d'evaluation et de deploiement de modeles d'apprentissage automatique non supervises ou semi-supervises | |
| EP3767467A1 (fr) | Procédé et dispositif de détermination d'une valeur d'indice de performance de prédiction d anomalies dans une infrastructure informatique à partir de valeurs d'indicateurs de performance | |
| EP3767558B1 (fr) | Procede et dispositif de determination d'une duree estimee avant un incident technique dans une infrastructure informatique a partir de valeurs d'indicateurs de performance | |
| EP3489831A1 (fr) | Procédé et dispositif de surveillance d'un processus générateur de données d'une métrique pour la prédiction d'anomalies | |
| WO2019129977A1 (fr) | Detection d'anomalies par une approche combinant apprentissage supervise et non-supervise | |
| WO2016012972A1 (fr) | Procede pour detecter des anomalies dans un reseau de distribution, en particulier d'eau potable | |
| WO2016075409A1 (fr) | Procédé de surveillance d'un moteur d'aéronef en fonctionnement dans un environnement donné | |
| FR3098940A1 (fr) | Procédé et dispositif de détermination d’une valeur de risque d’incident technique dans une infrastructure informatique à partir de valeurs d’indicateurs de performance | |
| EP4124942A1 (fr) | Procédé et système de traitement de données personnelles utilisant un chiffrement homomorphique | |
| EP1792278B1 (fr) | Procede de detection et de pistage de cibles ponctuelles, dans un systeme de surveillance optronique | |
| EP1820170A1 (fr) | Suppression de fausses alertes parmi les alertes produites dans un systeme d'informations surveille | |
| FR3089648A1 (fr) | Procede de detection non supervise d’attaques internes et systeme associe | |
| WO2024126521A1 (fr) | Méthode et système de détection d'intrusions dans un réseau informatique par apprentissage automatique | |
| Kusumaputri et al. | Anomaly Detection based on NSL-KDD using XGBoost with Optuna Tuning | |
| EP2353272B1 (fr) | Procede de caracterisation d'entites a l'origine de variations dans un trafic reseau | |
| FR3103039A1 (fr) | Détection d’attaques à l'aide de compteurs de performances matériels | |
| Al Balushi et al. | The use of machine learning in digital forensics | |
| EP4099228A1 (fr) | Apprentissage automatique sans annotation ameliore par regroupements adaptatifs en ensemble ouvert de classes | |
| WO2021122291A1 (fr) | Procede et dispositif de detection d'equipement intrus | |
| EP3729768A1 (fr) | Procédé de construction automatique de scénarios d'attaques informatiques, produit programme d'ordinateur et système de construction associés | |
| Erokhin et al. | The Dataset Features Selection for Detecting and Classifying Network Attacks | |
| WO2019211367A1 (fr) | Procede de generation automatique de reseaux de neurones artificiels et procede d'evaluation d'un risque associe | |
| Viktorov | Detecting phishing emails using machine learning techniques | |
| FR3117597A1 (fr) | Procédé de contrôle non destructif pour une pièce aéronautique | |
| FR3066289A1 (fr) | Procede, mise en oeuvre par ordinateur, de recherche de regles d'association dans une base de donnees |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20200612 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |
|
| PLFP | Fee payment |
Year of fee payment: 5 |
|
| PLFP | Fee payment |
Year of fee payment: 6 |