Brevet FR2983992A1 — publié le 20130614

Procédé de surveillance d'un message associé à une action produite par un élément ou utilisateur d'un SI, produit programme d'ordinateur, moyen de stockage et dispositif correspondants. 1 - Domaine de l'invention L'invention concerne le domaine des systèmes d'information (ci-après désigné par SI). L'invention trouve tout particulièrement, mais non exclusivement, son application dans la surveillance d'un SI notamment afin de détecter des intrusions et/ou de produire des rapports d'activité. 2 - Art Antérieur Les outils de surveillance dans le domaine de la détection d'intrusions dans les SI se sont dirigés ces dernières années vers un déploiement d'équipements de sécurité ou de surveillance encore appelés sources d' informations. Les sources d'informations sont nombreuses et variées, elles peuvent aussi bien être des sondes de détection de présence, des caméra vidéo, des capteurs de température, ... On distingue les catégories de sources d'informations qui agissent comme des outils d'audit remontant les messages de toute sorte dans des journaux d'audit (logs) et les catégories de sources d'informations plus spécialisées comme les sondes de détection d'intrusions chargées de détecter des attaques connues (signatures). Les sources d'informations remontent des messages spécifiques, par exemple, une source d'audit réseau détecte des messages sur le comportement du réseau et ne peut détecter des comportements intrusifs. Dans l'exemple ci- dessous, on illustre la diversité des langages (on parle de langages hétérogènes) utilisés par différentes sources d'informations d'un SI. On présente des premier et second messages (référencés a et b) délivrés par deux sources d'informations distinctes et qui expriment une même ouverture de session par un administrateur. a) premier message collecté dans le journal d'audit SYSLOG d'une source d'informations d'audit d'un système d'exploitation Linux. : « Authentication succeeded » b) second message collecté dans le journal d'audit d'une source d'informations Netscreen : « user login» La source d'informations surveille des actions. Les actions qu'elle observe sont menées par des agents qui peuvent être des humains (usagers, administrateurs ou attaquants) ou des processus du SI. Le fonctionnement d'une source d'informations est celui d'un filtre. Elle intercepte, collecte et analyse un flux sous forme d'une donnée qu'elle compare avec une valeur qu'elle a apprise au préalable. Ces valeurs connues sont des signatures pour une sonde de détection d'intrusion ou des métriques et des seuils pour une sonde réseau, applicative ou système. Son principe de fonctionnement est d'émettre un message (ou évènement brut ou log brut pour informer l'analyste du résultat de son analyse. Par exemple, une sonde réseau va alerter l'analyste réseau que la bande passante est à 63% d'utilisation ce qui est au-delà du seuil appris à 60%. L'analyste de sécurité est chargé de surveiller les différents assets (ou actifs) du SI. Il utilise sa connaissance experte pour l'interprétation des messages issus directement des sources d'informations. Il se sert du sens du message pour reconnaître, interpréter, comparer ou regrouper plusieurs messages. La précision du message influe fortement sur l'efficacité de la contre mesure menée par l'analyste. Le message fournit à l'analyste des indications afin d'appliquer la contre mesure adaptée au problème détecté par la source de surveillance. Un message décrit les actions observées au sein du SI par une phrase ou une expression du langage pseudo-naturel. La sémantique est l'ensemble des éléments clés de la phrase ou de l'expression que va reconnaître l'analyste pour interpréter et traiter le message. Le message et sa sémantique sont spécifiques aux sources d'information et ne donnent qu'une observation partielle de ce qui s'est passé. Le système de surveillance fournit au contraire la vision globale. Il regroupe tous ces messages spécifiques grâce à la coopération des sources d'informations qui transmettent leurs messages vers une base centralisée. Il prend en compte les messages issus d'autres équipements de supervision systèmes, réseau (associés à des messages de supervision des activités du SI) ou d'applications (associés à des messages de supervision d'application) qui apportent des indications fondamentales pour la détection d'une intrusion ou pour reconstituer ce qui s'est passé. Pour une centaine de modèles de sources d'informations, le regroupement représente un volume de messages différents à analyser de plus de 30 000. Dans les entreprises, la totalité des messages collectés représentent une quantité moyenne journalière de 1 go à 100 go par jour. Le rythme d'entrée des messages dans la base peut atteindre plusieurs milliers de 1 000 messages par seconde. Comme vu précédemment, le corpus de messages bruts du système de surveillance contient une quantité énorme de messages hétérogènes. Le but de la normalisation est de structurer ces messages : pour ce faire, elle transforme le message en une expression structurée appelée évènement normalisé. Le principe d'une normalisation est celui d'un traducteur qui s'appuie sur une classification, une ontologie ou une taxonomie. Une classification a pour but de faciliter le regroupement des messages présentant des caractères communs. Une taxonomie est une classification simple de classes décrites en extension (avec des listes de termes) et une ontologie est une classification en compréhension, qui fournit une sémantique des messages exploitable par des automates. Chaque source qui observe une action émet un message naturel transformé en évènement normalisé. Pour transformer une phrase naturelle en une phrase structurée, l'expert de sécurité érige des règles linguistiques, lexicales, syntaxiques ou sémantiques utilisées par le processus de normalisation. Les règles lexicales définissent un ensemble de termes, les règles sémantiques définissent le sens des mots dans leur contexte et les règles syntaxiques définissent l'organisation des termes dans la phrase. Cependant, trois défauts sont susceptibles de se produire lors de la transformation effectuée par le processus de normalisation parmi les redondances et omissions. 1) Lorsque plusieurs sources observent une même action, elles émettent chacune leur propre message. Comme vu précédemment, le rôle de la normalisation est de transformer chacun de ces messages en évènement normalisé ; dans ce cas, plusieurs évènements normalisés seront obtenus alors qu'ils représentent la même action (redondance). 2) Lorsque plusieurs experts émettent des règles de normalisation pour un message donné, ils doivent produire les mêmes règles et les mêmes termes, les experts doivent donc se mettre d'accord pour qu'un même message émis plusieurs fois produise toujours le même évènement normalisé ; dans le cas contraire, ces messages similaires par leur sens seront normalisés avec des termes différents (redondance par manque de consensus). Par exemple, « maison » et « résidence » représente le même concept « immeuble », leur normalisation est « immeuble ». Souvent, la traduction « terme à terme ne définit pas la notion de concept et favorise des déviances en créant un concept pour chaque terme. 3) à contrario, il faut que chaque message trouve un concept ou un terme qui lui corresponde : c'est l'exhaustivité. Si par manque d'exhaustivité certaines règles de normalisation ne sont pas présentes, les messages ne seront pas traduits et ne seront pas remontés à l'analyste. En cas de terme nouveau, si le concept n'est pas présent, de nouvelles règles devront être érigées. En résumé, les systèmes de normalisation doivent au travers de mécanismes de classification ou de codification être consensuels et exhaustifs. Sur le marché des systèmes de gestion des informations de sécurité (SIM) les constructeurs ou éditeurs de logiciels font face à l'hétérogénéité des sources en définissant une normalisation ad hoc qui effectue une traduction simple, « terme à 30 terme ». Ce principe garantit à l'analyste la remontée de chaque message dont les termes sont connus au préalable mais ne vérifie pas que l'action traduite a déjà été codifiée (redondance). Pour guider l'expert qui crée les règles de normalisation, une table prédéfinie lui est fournie, obtenue à l'aide d'une classification qui peut être une taxonomie ou une ontologie pour associer facilement un message à un évènement normalisé. Ces classifications propres à chaque éditeur de SIM ou d'IDS se rangent dans les taxonomies d'attaque, les langages de description d'attaques et les ontologies sur les attaques. Il en résulte une normalisation sous forme de signatures d'attaque pour des équipements de sécurité (IDS pour Intrusion Detection System), limitée au traitement de données de détection d'intrusion. Le document « Modeling computer attacks an ontology for intrusion detections » publié en 2003 dans LNCS-2516, editor, « The Sixth International Symposium on Recent Advances in Intrusion Detection », propose une ontologie pour décrire les attaques. En conclusion, l'état actuel de la technique porte sur la corrélation et l'agrégation, la majorité des outils de surveillance des SI actuels buttent sur les difficultés d'élaborer des scenarii d'attaques ; en revanche aucune solution ne résout le problème de l'hétérogénéité des messages liée à la coopération des différentes sources d'information. De même, les travaux des éditeurs de SIM n'ont pas élargi la normalisation aux informations autres que les informations de sécurité. Or, la performance des processus d'agrégation et de corrélation est étroitement liée à la normalisation des messages, ne serait ce que par la réduction incontestable du nombre des messages issus de la centralisation ou encore par la réduction de la complexité engendrée par leur diversité et leurs redondances limitant de ce fait les traitements par un humain : les processus de normalisation doivent améliorer ces deux aspects. 3 - Objectifs de l'invention L'invention a pour objectif de pallier les inconvénients de l'art antérieur. Plus précisément, un objectif de l'invention, dans au moins un de ses 30 modes de réalisation, est de fournir une technique de gestion de messages obtenus par au moins une source d'informations d'un SI à base d'une normalisation de messages, ladite normalisation tenant compte non seulement des messages de sécurité mais également de l'ensemble des messages liés aux activités surveillées du SI que ce soit au niveau système ou au niveau applicatif. Un autre objectif de l'invention, dans au moins un de ses modes de réalisation, est de fournir une telle technique qui n'impose pas à l'analyste de sécurité de connaître le langage de chaque source d'informations. Un autre objectif de l'invention, dans au moins un de ses modes de réalisation, est de fournir une telle technique dont la normalisation basée sur une ontologie reflète la réalité et qui permet de faire abstraction des sources d'informations. L'invention, dans au moins un de ses modes de réalisation, a encore pour objectif de fournir une telle technique qui soit simple à mettre en oeuvre et pour un faible coût. 4 - Exposé de l'invention Ces objectifs, ainsi que d'autres qui apparaîtront par la suite, sont atteints à l'aide d'un procédé de surveillance d'au moins un message, chaque message étant associé à une action produite par au moins un élément ou utilisateur d'un système d'information (SI), le ou lesdits message(s) étant collecté(s) par au moins un dispositif de collecte de message du SI. Selon l'invention, le procédé comprend les étapes suivantes : - définition d'une pluralité de catégories d'évènements de référence associées, chacune, à au moins une action de référence à partir d'une ontologie basée sur une classe d'intention qui caractérise le but de chaque action de référence, une classe de type d'activité qui qualifie la nature de chaque action de référence, une classe de mouvement qui caractérise les moyens permettant la mise en oeuvre de chaque action de référence, une classe de cible qui caractérise l'objet de chaque action de référence et une classe de gain qui caractérise la résultat de chaque action de référence ; et pour chaque message donné, - décomposition dudit message donné dans une base formée par la classe d'intention, la classe de type d'activité, la classe de mouvement, la classe de cible et la classe de gain ; - comparaison du message décomposé avec au moins une catégorie d'événement de référence ; - génération d'au moins un événement normalisé représentatif d'une correspondance entre le message décomposé et la catégorie d'événement de référence. Le principe général de l'invention consiste à normaliser des messages 10 collectés en les comparant à des messages préalablement décomposés dans une table formée par des classes de catégories issues d'une ontologie basée sur la théorie de l'action. Ainsi, un tel procédé permet de réduire la quantité de message collecté mais aussi de les rendre plus intelligibles et pertinents. Plus globalement les 15 traitements effectués par le procédé permettent de réaliser des opérations de filtrage, d'agrégation ou de corrélation. Il n'existe pas aujourd'hui de mécanismes de corrélation traitant de telles catégories d'évènements normalisés. Ainsi, on obtient une technique de traitement de messages obtenus par au moins une source d'informations d'un SI à base d'une normalisation de messages, 20 ladite normalisation tenant compte non seulement des messages de sécurité mais également de l'ensemble des messages liés aux actions surveillées du SI notamment : actions applicatives, système réseaux, matérielles, normales, anormales, suspicieuses. Par ailleurs, cette normalisation qui reflète la réalité n'impose pas à 25 l'analyste de connaître le langage de chaque source d'informations en faisant abstraction des sources d'informations. Ainsi, on obtient une normalisation des messages qui guide le processus de classification, qui couvre l'ensemble des actions surveillées du SI et qui lève l'ambiguïté pour classer un message, une normalisation avec une sémantique qui peut être implantée dans une application afin que l'application puisse mener un raisonnement. Une fois normalisés, les messages sont donnés en entrée du moteur de corrélation afin de reconstituer ce qui s'est passé mais aussi pour générer des rapports et des statistiques. Le procédé de normalisation des messages fonctionne de manière automatique et doit pouvoir raisonner sur ces données. Préférentiellement, si le message décomposé correspond à une catégorie d'évènements de référence, alors le procédé comprend les étapes suivantes : - vérification que la catégorie d'évènements de référence n'est pas 10 déjà présente dans un premier moyen de stockage ; - dans le cas d'une vérification positive, stockage de ladite catégorie d'évènements de référence dans ledit premier moyen de stockage. Avantageusement, si le message décomposé ne correspond à aucune desdites catégories d'événement de référence, alors le procédé comprend l'étape 15 suivante : - stockage du message dans un second moyen de stockage. Selon une caractéristique avantageuse de l'invention, lors de l'étape de définition d'une pluralité de catégories d'événement de référence, au moins une desdites catégorie d'évènements de référence est définie à partir d'au moins une 20 autre desdites catégorie d'évènements de référence et d'au moins une règle appartenant au groupe comprenant : - des règles syntaxiques ; - des règles lexicales ; - des règles sémantiques. 25 Préférentiellement, pour au moins une desdites catégories d'évènements de référence, il comprend une étape de comptage d'un nombre de message(s) décomposé(s) qui correspond(ent) à ladite catégorie d'événement de référence. Avantageusement, ladite classe d'intention comprend les intentions suivantes : - les intentions de découvrir et/ou de collecter au moins une information sur au moins une cible du SI ; - les intentions d'accéder au SI au moyen d'au moins une procédure d'authentification mettant en oeuvre au moins une information d'identification ; - les intentions d'accéder à au moins une ressource du SI au moyen d'au moins une procédure exigeant des droits ; - les intentions d'accéder à une disponibilité d'au moins une ressource du SI. Selon une caractéristique avantageuse de l'invention, ladite classe de 10 mouvement comprend les mouvements suivants : - les mouvements liés à au moins une action qui n'affecte pas la configuration du SI ; -les mouvements liés à au moins une action qui affecte la configuration du SI ; 15 -les mouvements liés à au moins une attaque ; -les mouvements liés à au moins un logiciel malveillant développé dans le but de nuire au SI ; -les mouvements liés à au moins une action suspecte détectée par au moins une sonde de détection d'action du SI ; 20 -les mouvements liés à au moins une vulnérabilité du SI ; -les mouvements reflétant un état constaté du SI. Selon un mode de réalisation avantageux de l'invention, ladite classe de gain comprend : -pour les intentions correspondants aux mouvements liés à au moins une 25 action qui n'affecte pas la configuration du SI et aux mouvements liés à au moins une action qui affecte la configuration du SI : - les succès ; - les échecs ; - les refus ; 30 - les erreurs ; -pour les intentions correspondants aux mouvements liés à au moins une attaque, aux mouvements liés à au moins un logiciel malveillant développé dans le but de nuire au SI, aux mouvements liés à au moins une vulnérabilité du SI et aux mouvements liés à au moins une action suspecte détectée par au moins une sonde de détection d'action du SI : - les détections ; -pour les intentions correspondant aux mouvements reflétant un état constaté du SI : les gains des intentions correspondant à au moins un mouvement 10 reflétant au moins une action d'au moins une cible du SI ; - les gains des intentions correspondant à au moins un mouvement reflétant au moins une utilisation d'au moins un seuil sur au moins une cible du SI. Avantageusement, les gains des intentions correspondant aux mouvements 15 reflétant des actions des cibles du SI comprennent : - les états valides suite à au moins un contrôle ; - les états invalides suite à au moins un contrôle ; - les notifications sur au moins une cible suite à au moins un contrôle. 20 Préférentiellement, les gains des intentions correspondant aux mouvements reflétant des utilisations de seuils sur des cibles du SI : les dépassements d'au moins un seuil temporel ; les dépassements d'au moins un seuil qui n'est pas lié au temps ; les utilisations basses d'au moins un seuil ; 25 les utilisation normales d'au moins un seuil ; les utilisation hautes d'au moins un seuil. L'invention concerne également un produit programme d'ordinateur, téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre du procédé de surveillance tel que précédemment décrit. L'invention concerne également un moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé de surveillance tel que précédemment décrit. L'invention concerne également un dispositif de surveillance d'au moins un message, chaque message étant associé à une action produite par au moins un élément ou utilisateur d'un système d'information (SI), le ou lesdits message(s) étant collecté(s) par au moins un dispositif de collecte de message du SI. Selon l'invention, le dispositif comprend : - des moyens de définition d'une pluralité de catégories d'évènements de référence associées, chacune, à au moins une action de référence à partir d'une ontologie basée sur une classe d'intention qui caractérise le but de chaque action de référence, une classe de type d'activité qui qualifie la nature de chaque action de référence, une classe de mouvement qui caractérise les moyens permettant la mise en oeuvre de chaque action de référence, une classe de cible qui caractérise l'objet de chaque action de référence et une classe de gain qui caractérise la résultat de chaque action de référence ; et pour chaque message donné, - des moyens de décomposition dudit message donné dans une base formée par la classe d'intention, la classe de type d'activité, la classe de mouvement, la classe de cible et la classe de gain ; - des moyens de comparaison du message décomposé avec au moins une catégorie d'événement de référence ; - des moyens de génération d'au moins un événement normalisé représentatif d'une correspondance entre le message décomposé et la catégorie d'événement de référence. 5 - Liste des figures D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante de plusieurs modes de réalisation préférentiels, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels: - La figure 1 présente un schéma d'un SI selon un mode de réalisation particulier de l'invention ; - La figure 2 présente une vue de haut niveau de l'ontologie à base des classes d'intention, d'activité, de mouvement, de cible et de gain selon le mode de réalisation particulier de l'invention ; il s'agit de la description d'une action grâce aux cinq classes précitées : l'intention (Intention ou Objectif) de type (Activity-Type) dirigée vers une cible (ou Target), en utilisant un mouvement qui en définitive produit un gain (Recuit); - La figure 3 présente à titre d'exemple l'ensemble des types d'intention, également appelés instances ou sous classe de la classe Intention selon le mode de réalisation particulier de l'invention ; - La figure 4 présente à titre d'exemple l'ensemble des types d'activité, selon le mode de réalisation particulier de l'invention ; - Les figures 5A et 5B présentent des valeurs lexicales possibles de chacun 20 des concepts (Objective, Activity-Type, Movement, Target Type, Target Detail et Resuit) selon le mode de réalisation particulier de l'invention ; - La figure 6 illustre les différentes valeurs possibles du gain en fonction des types d'activité selon le mode de réalisation particulier de l'invention ; - La figure 7 illustre la transformation d'un message constitué d'une 25 phrase en langage naturelle émise par une sonde de détection en une catégorie d'événement de référence ; - La figure 8 présente un algorithme exprimant l'un des modes de décomposition explicite d'un message en un message décomposé selon un premier exemple conforme au mode de réalisation particulier de l'invention ; - La figure 9 présente l'ensemble des méthodes de décompositions disponibles, lexicales, sémantiques et syntaxique d'un message en un message décomposé selon le mode de réalisation particulier de l'invention ; - La figure 10 présente une des méthodes de présentation graphique particulière de l'ensemble catégories d'évènements normalisés de la normalisation ExaProtect sous forme d'une mire graphique selon le mode de réalisation particulier de l'invention. 6 - Description d'un mode de réalisation de l'invention On décrit dans la suite un procédé de surveillance d'au moins un message, chaque message étant associé à une action produite par au moins un élément ou utilisateur d'un SI 1000 (tel que décrit en relation avec la figure 1), le ou lesdits message(s) étant collecté(s) par au moins un dispositif de collecte de message du SI selon un mode de réalisation particulier de l'invention. Les messages émis par les sources d'informations, une fois transformés par le procédé de transformation (qui comprend des étapes de décomposition, comparaison et génération précitées) sont appelés des événements normalisés. Le SI 1000 comprend au moins un réseau hébergeant des entités munies d'au moins une source d'information (poste de travail 1001, serveur d'impression 1002, serveur de fichiers 1003a, serveur d'application 1003b) relié à Internet 1006 par le biais d'un routeur 1005 et d'une zone démilitarisée (DMZ) visant le contrôle de tous les flux entrant et sortants ; la DMZ met en oeuvre des sources d'informations de sécurité, à savoir 1) au moins un système de filtrage, comme un pare-feu (ou Firewall) 1004 pour le filtrage des flux, ou 2) au moins un système de détection d'intrusions (réseau 1007a , système 1007b et applicatif 1007c), ou 3) au moins un ensemble de passerelles dédiées aux opérations de déverminage (antivirus) 1008a et 1008b comme par exemple des passerelles WEB, SMTP et DNS. L'ensemble des sources d'informations du SI citées précédemment ont accès à une base de donnée 1009 gérée par le serveur du procédé de surveillance 1010 Ainsi, le SI 1000 fait coopérer tout type de sources d'informations que ce soit au niveau système ou au niveau applicatif. Bien entendu, l'invention s'applique à tous les types de système d'informations qu'ils soient des réseaux informatiques ou même des systèmes de surveillance de sites tels que des musées, des sites industriels,.... Le procédé de surveillance selon l'invention met en oeuvre un mécanisme de normalisation pour collecter, structurer et regrouper les messages de même nature remontés par les sources d'informations précitées. L'analyste de sécurité a une vision de toutes les actions en cours et ne reçoit pour chacune d'elles qu'un et un seul évènement normalisé. Cette vision est indispensable pour anticiper et réagir devant un incident ou une attaque en cours. Le procédé de normalisation au sens de la présente invention codifie des évènements normalisés à l'aide d'une sémantique afin qu'ils soient structurés et compréhensibles par tous les mécanismes automatisés dans le but de traiter ou 15 manipuler un grand volume de messages. Le procédé de normalisation comprend une étape de modélisation (qui comprend une étape de définition des concepts de l'ontologie pour exprimer la sémantique du message -intention, activity-type, movement, target, gain- et une étape de définition linguistique pour définir les termes et syntaxes de 20 chacun de ces concepts) et de transformation (qui comprend des étapes de décomposition, comparaison et génération précitées) - Modélisation par la définition d'une pluralité de catégories d'évènements de référence associées, chacune, à au moins une action de référence à partir d'une ontologie basée sur une classe d'intention (ou objective) qui caractérise le but 25 de chaque action de référence, une classe d'activité qui qualifie la nature de l'intention, une classe de mouvement qui caractérise les moyens permettant la mise en oeuvre de chaque action de référence, une classe de cible (ou target) qui caractérise l'objet de chaque action de référence et une classe de gain (ou resuit) qui caractérise la résultat de chaque action de référence ; 30 et pour chaque message donné, - Décomposition dudit message donné dans une base formée par la classe d'intention, la classe activité, la classe de mouvement, la classe de cible et la classe de gain ; - Comparaison du message décomposé avec au moins une catégorie d'événement de référence ; - Génération d'au moins un événement normalisé représentatif d'une correspondance entre le message décomposé et la catégorie d'événement de référence. La modélisation (qui comprend l'étape de définition précitée) selon le mode de réalisation particulier de l'invention fournit la structure et la sémantique pour normaliser un message en évènement normalisé compréhensible par un automate ou nu analyste de sécurité. L'expert de sécurité réalise cette étape grâce à un outil d'aide à la normalisation. La transformation selon l'invention (qui comprend des étapes de décomposition, comparaison et génération précitées) est réalisée par un expert de sécurité qui définit les règles de transformation d'un message en événement normalisé grâce à des outils linguistiques issus de l'intelligence artificielle pour assister pleinement son travail d'expertise. La connaissance experte peut être à ce stade indispensable pour apporter ou compléter les règles de transformation. Dans le cadre du présent mode de réalisation de l'invention, l'ensemble des messages utilisés pour la classification des informations de sécurité est recueilli par le logiciel SMS commercialisé sous la référence ExaProtect SMP300, SMP-500 SMP-1200 et SMA-50 produit et édité par la société EPT. Les formats utilisés pour structurer les évènements normalisés sont nombreux sur le marché (IDMEF, CIM, IODEF, SNMP...). La standardisation des évènements de sécurité proposée au travers de l'IDMEF (« Intrusion Detection Message Exchange Format ») par le groupe de travail IDWG (« Intrusion Detection Working Group ») à l'IETF. (« Internet Engineering Task Force ») et a été retenue actuellement comme base de la structure des messages normalisés par les logiciels ExaProtect. 6.1 Introduction à la normalisation selon le mode de réalisation particulier de l'invention On décrit maintenant le processus de normalisation selon le mode de réalisation particulier de la présente invention. La normalisation comprend le processus de modélisation et de transformation précités. Les systèmes de surveillance collectent et centralisent des informations dans une base de messages appelée corpus brut. Il se compose de messages hétérogènes, non classifiés, non structurés et avec des sémantiques spécifiques selon le rôle de la source : certains messages décrivent la même action mais avec des expressions ou des termes propres à chaque source (redondance, pertinence), d'autres décrivent la même action mais observée à différents stades : début ou fin de l'action, etc., (granulométrie : agrégation et corrélation). L'humain, l'analyste de sécurité qui analyse message par message, ne peut connaître la totalité de ces messages et est impuissant pour discerner les messages pertinents : il doit se faire assister de mécanismes automatisés. Il n'existe pas de format universel des données hétérogènes, ni de standard pour normaliser la sémantique globale des messages. Les automates ne sont pas opérationnels sur des données non structurées et sans sémantique. Les messages requièrent cependant un système de normalisation. La normalisation définit une structure des messages afin que des automates de corrélation et d'agrégation puissent opérer et une sémantique pour reconnaître et regrouper les messages qui représentent les mêmes actions. La normalisation définit une sémantique et une structure associées à chaque messages tel que 1) chaque message ait une codification pertinente et compréhensible par un automate, 2) il existe au moins une codification par message présent (exhaustivité) sinon on crée un faux négatif, 3) il existe au plus une codification par message de même sens (consensus), quelque soit le processus de traduction de messages utilisé. La normalisation définit une codification de l'ensemble des actions réelles 30 sous la forme d'un ensemble de catégories d'évènements de référence. La normalisation traduit le message avec la codification de l'action qu'il représente ; de cette manière il n'y existe qu'une traduction possible par message : l'action qu'il représente. Le centre de l'invention est de définir au préalable l'ensemble des actions réelles pertinentes (codification) ainsi que les règles de transformation pour guider l'expert ou les automates lors de la normalisation des messages. L'objectif de la phase de modélisation est de définir l'ensemble des catégories d'évènements de références représentatives des actions réelles (codification) qui intéressent le système de surveillance. Comme il n'existe qu'une catégorie d'évènements de référence par action, l'avantage est qu'il y aura qu'un seul évènement normalisé pour chaque message de cette action. Le message n'est plus associé à une structure construite à partir du message mais à un code d'action prédéfini et unique. Le rôle de la modélisation conforme au mode de réalisation particulier de l'invention est d'identifier et définir l'ensemble des actions de référence, cette étape est clé et est réalisé à l'aide d'une ontologie pour construire la sémantique de chaque message et regrouper ceux de même sens (ou logs bruts) par cette sémantique. La normalisation se compose d'une phase de modélisation s'appuyant sur une ontologie, composée de concepts extraits à partir de la théorie de l'action et de règles définies selon les classes de profils présentes au sein du SI. 6.2 La modélisation selon le mode de réalisation particulier de l'invention La modélisation répond aux besoins d'exhaustivité et de consensus précités. L'ontologie définit l'ensemble des actions en compréhension, c'est-à-dire qu'elle définit les concepts et les règles linguistiques tel que le processus de transformation ne puisse associer qu'une et une seule catégorie d'évènement de référence à un message donné. L'ontologie est conçue tel que toutes les actions importantes vis-à-vis de la sécurité du SI soient présentes sous forme d'une catégorie d'évènement de référence et que toutes les actions possèdent une définition linguistique non ambiguë pour qu'il ne puisse exister deux catégories d'évènements normalisés qui expriment une même action. 6.2.1 - Les concepts de l'ontologie selon le mode de réalisation particulier de l'invention Il n'est pas trivial de trouver une modélisation commune et non ambiguë pour l'ensemble des actions. Les principes énoncés par Davidson dans la théorie de l'action de ont permis d'extraire 5 concepts: 1) intention, 2) activité, 3) mouvement, 4) cible et 5) résultat, consolidés ensuite par la connaissance experte et l'analyse du corpus brut réel. Davidson, dans son ouvrage philosophique « Actions, Reasons, and Causes », « Journal of Philosophy pp 685-700 (Reprinted in Davidson 1980, pp 3- 19.), 1963 » énonce que connaître la raison d'une action revient à savoir quelle intention l'a suscitée. La modélisation selon le mode de réalisation particulier de l'invention a tout d'abord retenu deux concepts « intention » et « type d'activité », le premier définit l'intention qu'à un agent lorsqu'il franchit une étape appartenant à un plan construit dans un but final, et le second évalue si ce type d'action est normal, suspect ou anormal par son intention et sa conformité au plan de l'agent. La modélisation définit un troisième concept de « mouvement » pour préciser l'intention et le type d'activité. Plusieurs auteurs (Mele, 1992, Bratman, 1987, Brand, 1984) ont souligné que la plupart de nos actions fait intervenir des mouvements. Israel, Perry et Tutiya (David Israel et al., n.d.) ont remarqué que l'explication de l'action est incomplète sans introduire le concept de mouvement présent dans chaque action. Si on n'a pas la moindre idée du mouvement, rien ne pourrait constituer le fait de réaliser l'action. La modélisation ExaProtect intègre un quatrième concept, le « résultat ». Il est difficile de penser que l'on puisse avoir l'intention de faire une action si l'on n'attend pas un résultat qui rapproche l'agent de son but final. Certaines actions définissent une étape dans le plan de l'agent (l'accès à un serveur est un exemple d'étape franchie) alors que d'autres actions sont descriptives et évaluent les états de l'environnement de l'agent (un certificat est requis à l'ouverture de session ou le certificat est périmé sont des exemples de description). La réussite ou l'échec de chaque étape évalue la progression de l'agent dans son plan, c'est le concept de « gain ». Au contraire, le concept de « contrôle » est introduit pour évaluer l'environnement de l'agent, il n'exprime pas de progression ou de gain. Le contrôle est quantitatif (concept de « seuil ») ou qualitatif (conforme ou non) : par exemple, le certificat est invalide (qualitatif) ou périmé (quantitatif)). En résumé, la modélisation retient cinq concepts ontologiques fondamentaux pour décomposer une action. Ces cinq concepts créent les catégories d'événements de référence qui représentent l'ensemble des actions de l'ontologie des actions. Ces cinq concepts interagissent entre eux de telle sorte qu'il ne puisse exister qu'une et une seule relation permettant d'exprimer l'ensemble de toutes les actions réelles du SI: La généralisation d'une catégorie d'événements de référence s'exprime : « Un mouvement M sur la cible C a un résultat R pour une intention I de type d'Activité A». 6.2.2 - Le langage et les règles de l'ontologie selon le mode de réalisation particulier de l'invention La définition des règles réduit le nombre des actions à modéliser (qui est théoriquement infini) tout en préservant la pertinence de chaque message et tout en couvrant toutes les actions devant être présentes du point de vue du système de surveillance. Les règles définissent le langage ExaProtect où chaque concept et chaque relation est exprimée par des règles linguistiques communes : des règles lexicales, syntaxiques et sémantiques. Les règles sémantiques : le langage ExaProtect construit la sémantique de chaque catégorie d'événement de référence. La sémantique sera transmise au message lors de sa transformation en évènement normalisé : l'évènement normalisé hérite de cette sémantique. Les règles sémantiques sont transmises à l'expert de sécurité et à l'outil d'aide à la normalisation pour choisir, lors de la traduction du message en évènement normalisé, le modèle ExaProtect qui lui convient. Les règles sémantiques sont également transmises à l'analyste ou aux automates pour leur permettre l'interprétation ou le raisonnement sur le sens des évènements normalisés. Sans cette connaissance, ni l'analyste ni les automates chargés de regrouper les évènements par leur sens, ne pourraient fonctionner. Une règle sémantique dans la modélisation est définie par une collection d'objets qui répondent à des règles fonctionnelles communes : par exemple, l'ensemble des étapes du plan de l'attaquant qui définissent un comportement attaquant ou bien l'ensemble des composants du système d'authentification de l'utilisateur ou encore l'ensemble des vulnérabilités du SI qui définissent des chemins d'attaques. Ces règles sont décrites dans la suite du document. Tout modèle ExaProtect est défini par une règle sémantique qui généralise la définition d'une action selon les 5 concepts énoncés ci-dessus. Les règles lexicales : elles définissent la liste de termes et leur description dans le langage ExaProtect; c'est un dictionnaire ; cette description exprime chacun des 5 concepts intention, activity-type, movement, target et gain avec des termes définis et appropriés au domaine de la sécurité: la liste est consensuelle et validée par des experts. Le lexique ExaProtect est composé actuellement de plus de 100 mots naturels. Cette liste s'enrichit au fur et à mesure et ne doit pas créer de nouvelle catégorie de référence qui ne respecte pas les règles sémantiques. Nous décrivons en figure 5b une première liste utilisée pour nos conversions. Les règles syntaxiques : elles sont simples et se représentent en organisant les 5 concepts tels qu'ils soient séparés par le caractère « » : ( IntentionActivity-TypeMovementTargetl_petail2_Result ) 6.2.3 - Description de l'ontologie selon le mode de réalisation particulier de l'invention On décrit maintenant les règles linguistiques de chacun des 5 concepts. 6.2.3.1 - Les intentions des agents et leur progression selon le mode de réalisation particulier de l'invention Certains messages expriment la progression de l'agent mais cette valeur est difficile à extraire si l'on ne donne pas les jalons pour la détecter. Deux jalons sont nécessaires pour situer l'action par rapport à la progression de l'agent dans son plan: 1) la connaissance des étapes du plan pour situer l'action et l'étape dans le plan (concept « Intention »), 2) la connaissance des types d'agents, de leur plan, selon qu'ils représentent une activité normale, anormale, suspicieuse (concept « Activity-Type »). 6.2.3.1.1 Règle sémantique du concept « Intention » Pour attaquer un SI, un attaquant prépare un plan d'attaque ; chaque étape du plan correspond à la réalisation d'un but. De la même manière, un agent, qu'il soit un attaquant ou un usager, évolue au travers d'un plan : plan d'attaque ou plan d'usage. Il passe d'un but à un autre jusqu'à l'obtention d'un but final. Les intentions sont les buts des étapes. La notion d'intention est bien adaptée car la reconnaissance des intentions permet de reconstituer le plan ainsi que d'évaluer la progression de l'agent dans le SI. Dans la modélisation ExaProtect, la progression n'est définie qu'au travers des intentions d'accès, les autres intentions ne sont pas détectables. L'agent quel qu'ils soit, attaquant ou utilisateur, suit un plan dans l'intention d'accéder à sa cible en utilisant des mécanismes d'accès correspondant à 4 intentions d'accès : 1-L'intention d'accès aux informations environnementales du SI via des actions de collecte d'informations. Cette phase est spécifique à l'attaquant, la première phase de l'attaque, incluant le repérage des caractéristiques du système cible. Les informations collectées durant cette première phase déterminent les vulnérabilités et facilitent l'étape suivante du plan : l'authentification. 2-L'intention d'accès au SI par des actions d'authentification, déclinant son identité au SI validée par des mécanismes d'authentification. Cette phase est commune à l'ensemble des plans et est un pré-requis pour l'étape suivante d' autorisation. 3-L'intention d'accès aux ressources du SI par des actions d'utilisation de droits validés par des mécanismes de droits. Cette phase est aussi commune à l'ensemble des plans et constitue une étape préalable mais optionnelle à l'accès aux fonctions vitales du système. 4-L'intention d'accès à la disponibilité du SI par des actions de manipulation du système pour exécuter des commandes, lancer des services, etc. C'est une étape commune menée généralement par un administrateur ou un attaquant. Elle constitue généralement la phase finale du plan puisqu'elle a permis d'accéder aux fonctions vitales du système. Elle peut cependant ne constituer qu'une étape intermédiaire à un plan plus ambitieux, reconduisant alors l'agent aux étapes précédentes mais appliquées à d'autres cibles. Nous précisons l'intention d'accès sous la forme d'une première règle. Règle 1, Intention : Chacun profil d'usage distinguera 4 intentions, représentant chacune une étape dans la progression sur une cible donnée et se distinguant chacune selon qu'elle vise un accès aux informations via des actions de repérage ou de reconnaissance, un accès au SI via des actions d'authentification, un accès aux ressources via des actions de privilège et un accès aux fonctions vitales du système via des actions systèmes. 6.2.3.1.2 Règle syntaxique des intentions La syntaxe du concept intention utilise le premier champ du modèle Exa : (IntentionActivity-TypeMovementTargetl_Detail2_Result ) 6.2.3.1.3 Règle lexicale des intentions Ces types d'intention 3000 (illustrées par la figure 3) correspondent à : 1-INFORMATION GATHERING 3002 ou RECON : les intentions de découvrir et/ou de collecter au moins une information contextuelle sur au moins une cible du SI par la collecte et le repérage. 2-AUTHENTICATION 3003 : Les intentions d'accès au SI au moyen d'au moins une procédure d'authentification à travers le service d'authentification mettant en oeuvre au moins une information d'identification (une identité avec ou non la connaissance d'un secret). (Ci-après référencées par intention AUTHENTICATION 3003). Parmi les messages classés dans l'intention AUTHENTICATION, nous pouvons citer l'accès au SI réussi ou échoué d'un utilisateur ou encore une erreur sur le service d'authentification lors de cet accès ; nous pouvons encore citer les intentions d'attaques utilisant des moyens de type « bruteforce » pour accéder au SI ainsi que les messages des scanners de vulnérabilités décrivant les failles exploitables de système d'authentification ou encore les messages des sources d'informations qui décrivent les états du système comme un « port réseau ouvert ». 3- RIGHTS 3004 : Les intentions d'accéder à au moins une ressource du SI au moyen d'au moins une procédure exigeant des droits (ci-après référencées par intention RIGHTS 3004). Il s'agit des messages pour lesquelles il y a eu un accès à une ressource via une autorisation ou une tentative d'accès à une ressource du système sans que cet accès ne soit autorisé par des règles préétablies. Parmi ces messages, nous pouvons citer les mouvements qui permettent : l'accès à un fichier; l'exécution ou tentative d'exécution d'une application dans un mode privilégié, l'utilisation ou la tentative d'utilisation de certaines commandes du système réservées à des utilisateurs privilégiés, les changements des droits d'accès à des fichiers sensibles, les signatures d'attaques qui ont l'intention d'accéder au ressources; 4- SYSTEM 3001 : les intentions d'accéder à la disponibilité d'au moins une ressource du SI (ci-après référencées par intention SYSTEM 3001). Il s'agit des messages pour lesquels les mouvements d'accès aux fonctions vitales des systèmes, leurs composants ou leurs ressources système (sYsTEm) ont été utilisés. Parmi ces messages, nous pouvons citer les mouvements d'exécution d'une application ou d'un service ou encore d'un processus, le démarrage, le redémarrage ou l'arrêt d'une application ou d'un service ou d'un composant système ou encore d'un processus, le changement de configuration des systèmes, leurs composants ou applications, l'envoi et la réception de paquets, de fichiers, etc., les signatures d'attaques qui ont l'intention d'accéder aux fonctions vitales du SI sont aussi classées sous ce modèle. 6.2.3.2 - Les types d'activité selon le mode de réalisation particulier de l'invention Le concept « Activity-Type » est le second jalon pour évaluer la progression de l'attaquant. 6.2.3.2.1 Règle sémantique du concept « Activity-Type » Nous avons choisi de modéliser les évènements qui décrivent une progression dans le SI des évènements ayant une valeur informative. La modélisation ExaProtect retient deux catégories d'évènement de référence selon qu'elles représentent des actions de progression d'un agent dans le SI ou selon qu'elles représentent l'état du SI ou de ses composants. Règle 2 : Sur l'ensemble des actions observées (surveillées,) il y a deux types d'actions : celles qui décrivent l'environnement ou « état du système » et celles qui décrivent une « progression » vers une cible. 6.2.3.2.1.1 Les agents et le type d'activité Il est difficile, s'il n'est pas impossible, de pouvoir différencier les actions d'un attaquant de celles d'un utilisateur légitime s'il ne s'agit pas clairement d'une signature d'attaque. Une fois l'attaquant à l'intérieur du système, il est vu par le système comme un utilisateur légitime et les messages ne pourront pas remonter l'indication de normalité ou non. Certaines actions sont des étapes spécifiques à des plans d'attaques ou d'administration et d'autres sont communes à tous les plans. La modélisation ExaProtect définit trois profils d'usage qualifiant les étapes de normales, anormales ou suspectes: - Profil « UTILISATEUR » : représente l'ensemble des actions d'usage normales de l'activité d'un utilisateur qui ne modifient pas les configurations des ressources et des services d'un SI. Ces actions entreprises dans le SI peuvent être menées par tout type d'utilisateur pour utiliser le système. - Profil «ADMINISTRATEUR » représente l'ensemble des actions d'exploitation et de maintenance normales d'un administrateur qui modifient les configurations des ressources et des services d'un SI dans le cadre d'actions. Ces actions sont utiles à l'administrateur amené à modifier tout ou partie du SI. L'administrateur évolue dans le SI aussi avec des actions d'usage. - Profil «ATTAQUANT » représente l'ensemble des actions anormales dites « à signatures », « anormales » et « suspicieuses». Certains messages n'affichent aucun doute quant à leur appartenance à l'ensemble des actions offensives ou suspicieuses car ils portent des signatures ou des termes « attack » dans leur contenu. Les actions anormales sont des actions de repérage, de collecte d'informations, d'exploitation de ces informations ou encore de propagation de l'attaque dans le système. Règle 3 : Activité : L'ensemble des actions observées décrivant une progression fera partie de l'ensemble des actions classé en trois catégories de profils d'usage : attaquant, utilisateur ou administrateur. Règle 3a: Une activité anormale regroupe l'ensemble des actions suspicieuses, d'attaques ou de malware marquées par une signature ou un mot clé signalant respectivement leur type : attack, suspicious, ou malware est présent. Règle 3b: Une activité normale regroupe l'ensemble des actions menées par un usager et n'apportant pas de modifications du SI ou celles menées par un administrateur apportant des modifications de configurations.. Remarques : Dans le cas où le système de surveillance focaliserait sa surveillance sur des utilisateurs particuliers comme un administrateur réseau par exemple, il est possible d'instancier chaque profil afin de porter la surveillance non plus sur les seuls 3 profils précités mais sur des instances, par exemple l'instance « profil administrateur réseau » pour la surveillance des actions réseau, idem pour un utilisateur d'une base de donnée Oracle, etc... Par ailleurs, il ne pourra être déduit qu'une action du profil « utilisateur» ou « administrateur » n'est pas offensive; il faudra seulement déduire qu'elle constitue une étape légitime d'un comportement qui peut s'inscrire aussi bien dans un plan d'attaque que dans un plan d'usage. 6.2.3.2.1.2 Les états du système Certains messages décrivent l'environnement de l'agent, l'état du système. Ces types de messages apportent des indices à l'analyste pour lui révéler la présence masquée d'une action en cours ou au contraire pour démontrer qu'elle a été réalisée. Il peut s'agir d'un seuil dépassé par exemple comme l'augmentation anormale de la bande passante réseau démontrant une attaque masquée par virus. Il peut encore s'agir de la découverte de vulnérabilités qui confirme à l'analyste qu'une attaque a été possible. Pour exprimer les états du système, la modélisation ExaProtect distingue deux notions liées au type de l'«activité »: 1- Les vulnérabilités sont des faiblesses du SI, ou de ses composants, détectées par une source d'informations spécifique appelée « scanner de vulnérabilité » ; la plupart du temps, les vulnérabilités sont des conditions de réalisation d'un exploit ; les vulnérabilités représentent un sous ensemble des états du système qui ont la particularité d'être connues de ces outils spécifiques comme étant les causes directes d'un exploit donné : ce sont des signatures; la connaissance des vulnérabilités est généralement une aide précieuse pour anticiper la compromission d'un système. 2- Les états du système informent l'analyste sur la situation en cours du système qu'il surveille ; il s'agit des autres faiblesses qui ne sont pas des 20 vulnérabilités connues comme l'état d'un service, d'un paramètre ou d'une configuration. Que ce soit les vulnérabilités ou les états du système, ces informations ne révèlent pas la progression de l'agent sur un accès mais remontent un état. La connaissance de cet état facilite la compréhension de ce qui s'est passé ou 25 explique une compromission : ce sont des indices ou des témoignages utiles à l'analyste de sécurité. 6.2.3.2.2 Règle linguistique du concept « Activity-Type» Nous avons vu qu'il existe 3 types de valeurs : les actions de progression, les informations sur les états du système et les actions décrivant les vulnérabilités. La figure 4 présente à titre d'exemple l'ensemble des types d'activité, selon le mode de réalisation particulier de l'invention. 6.2.3.2.2.1 Les actions de progression La modélisation des actions de progression se présentera sous la forme suivante : (IntentionActivity-TypeMovementTargetl_Detail2_Gain ) 1- ACTIONS NORMALES : Les messages pour décrire des actions normales selon le présent mode de réalisation particulier de l'invention distinguent : 1 a)-Profil « UTILISATEUR » : Les profils UTILISATEUR n'agissent pas sur le système par des opérations de modification de celui-ci ; les actions menées par des profils UTILISATEUR ont la forme : (IntentionActivity MovementTargetl_Detail2_Gain ) et s'exprimeront selon l'intention par l'expression ACTIVITY (référencé 4002) ou par l'expression CONFIG (référencé 4001) : -Pour les actions d'authentification ou AUTHENTICATION ACTIVITY ; -Pour les actions liées au droits ou RIGHTs ACTIVITY ; -Pour les actions du système ou SYSTEM ACTIVITY ; 1 b)-Profil « ADMINISTRATEUR » : Les profils ADMINISTRATEUR n'agissent pas sur le système par des opérations de configuration de celui-ci ; les actions menées par des profils ADMINISTRATEUR ont la forme : (Intention_Config MovementTargetl_Detail2_Gain ) Et s'exprimeront selon l'intention : -Pour les actions d'authentification ou AUTHENTICATION CONFIG ; -Pour les actions liées au droits ou RIGHTS CONFIG ; -Pour les actions du système :ou SYSTEM CONFIG ; 2-LES ACTIONS ANORMALES Les messages pour décrire des actions anormales selon le présent mode de réalisation particulier de l'invention définissent un profil ATTAQUANT et s'exprimeront sur le second champ : 2 a) Attaques non avérées mais supposées, représentées par l'expression SUSPICIOUS (référencé 4006) : ( Intention_Suspi ci ousMovementTargetl_Detail2_Detected) 2 b) Attaques avérées représentées par l'expression ATTACK (référencé 4005): (IntentionAttack_Movement_Targetl_Detail2Detected ) 2 c) Nuisances avérées représentées par l'expression MALWARE (référencé 4004): (Intention_Malware_Movement_Targetl_Detail2Detected) Les actions anormales s'exprimeront sur le premier champ selon qu'elles montrent une intention : -de gain d'authentification OU AUTHENTICATION_ ATTACK ; -de gain de droits OU RIGHTS_ATTACK ; -de gain système SYSTEM ATTACK ; Les actions anormales et suspectes s'exprimeront sur le premier champ selon qu'elles montrent une intention : -de gain d'authentification AUTHENTICATION_ SUSPICIOUS ; -de gain de droits RIGHTS_SUSPICIOUS -de gain système SYSTEM SUSPICIOUS Les actions anormales issues d'un logiciel malveillant s'exprimeront sur le 25 premier champ selon qu'elles montrent une intention : -de gain d'authentification: AUTHENTICATION MALWARE ; -de gain de droits : RIGHTS_MALWARE ; -de gain système/ SYSTEM MALWARE ; 6.2.3.2.2.2 Les états du système Les messages visant la description des états du système sont décrits dans le paragraphe suivant et se présenteront sous la forme : (Intention_Information_Control_Targetl_Detail2_Resu/t) Tel qu'expliqué (et ci-après référencées par l'activité « INFORMATION » 4007), ces catégories d'évènements de références utilisent les mêmes concepts que les modèles ExaProtect d'action. En revanche, ils se modélisent par une phrase générique qui sera adaptée à l'observation de l'environnement par l'agent selon des critères 1) quantitatifs ou 2) qualitatifs. 6.2.3.2.2.2.1 Quantitatif : La modélisation ExaProtect définit le concept « seuil » pour modéliser des critères quantitatifs temporels ou spatiaux: « Une Information de l'intention I quantifie un état E selon le contrôle de seuil de la cible C» La modélisation précise les critères quantitatifs par l'emploi de deux champs : Threshold-Type et Exceed-Value (Intention_Information_Thresho/d Targetl_Threshold-Type Exceed- Value) La figure 6 illustre les différentes valeurs possibles du gain en fonction des types d'activité selon le mode de réalisation particulier de l'invention. On distingue les dépassements de seuil ci-après désignés par l'activité « INFORMATION » (7005 et 7007) : d'au moins un seuil temporel (ou Expired) ; d'au moins un seuil qui n'est pas lié au temps (ou Exceeded) ; les utilisations basses d'au moins un seuil (ou Low) ; les utilisation normales d'au moins un seuil (ou Normal). les utilisation hautes d'au moins un seuil (ou Hie). 6.2.3.2.2.2.2 Qualitatif La modélisation ExaProtect définit le concept « control » pour exprimer des critères qualitatifs qui modélisent la description conforme de l'environnement. « Une Information de l'intention I qualifie un état E du contrôle de la cible C» La modélisation retient les critères qualitatifs ci-après désignés par l'activité « INFORMATION » (7005 et 7006) : Notify, Valid, Invalid (ces états sont décrits ci-après au paragraphe 6.2.3.4 ): (Intention_Information_Control_Targetl_Detail2_Result ) Plus précisément on distingue : -les informations d'authentification OU AUTHENTICATION INFORMATION ; -les informations Sur les droits OU RIGHTS INFORMATION -les informations SUT le système OU SYSTEM INFORMATION ; Par exemple, l'information de contrôle indiquant que la méthode du système d'exploitation n'a pas été validée pour l'intention « authentification » qui correspond au message : unauthorized authentication method peut être modélisée par : Authentication Information :ontrol SysAuth Method Invalid Et l'information de seuil indiquant que le compte du service d'authentification a expiré pour l'intention « authentification» qui correspond 20 aux messages : NetScreen : session timeout Received certificate expired Restricted hours dial-in access peut être modélisée par : 25 Authentication Information Threshold SystAuth Account exceeded 6.2.3.2.2.3 Les vulnérabilités Les messages décrivant les vulnérabilités se présenteront sous la forme : (Intention_Vulnerability MovementTargetl_Detail2_Detected) ) Il s'agit ici de modéliser une vulnérabilité du SI (ci-après référencées par 5 activité VULNERABILITY 4003) obtenue par au moins une source d'informations spécifique appelée scanner de vulnérabilité : Plus précisément on distingue : - les informations sur la vulnérabilité du système d'authentification noté AUTHENTICATION VULNERABILITY; 10 - les informations sur la vulnérabilité du système d'autorisation noté RIGHTS VULNERABILITY ; - les informations sur la vulnérabilité du système noté SYSTEM _ VULNERABILITY. Vis-à-vis du SI, l'évaluation des vulnérabilités est simple du fait qu'elle est 15 réalisée par l'outil de vulnérabilités: la vulnérabilité existe et a permis ou non un exploit ou elle n'existe pas : le seul état correspondant est : « détectées ou non ». En ce sens l'évaluation d'une vulnérabilité se rapproche de l'évaluation d'une attaque et prendra la valeur « detected »pour le champ « result » (ci-après référencés par 7003 et 7004). 20 6.2.3.3 - Mouvement selon le mode de réalisation particulier de l'invention Dans un SI les mouvements observés par les sources d'informations sont trop nombreux (illimités). Ils sont parfois proches et peuvent se ressembler si bien qu'ils sont difficiles à déceler. Un même message peut comprendre plusieurs 25 mouvements. Dans l'exemple suivant où le message remonté décrit l'échec d'ouverture de session d'un utilisateur, deux actions sont exprimées : non-conformité du nom de l'utilisateur et refus de son accès. « un nom d'utilisateur est invalide et la requête d'authentification est refusée». Dans la modélisation ExaProtect, le mouvement est défini comme le moyen utilisé pour accomplir l'intention. Le mouvement est lié à l'auteur « supposé » de l'action, il est dirigé contre une cible et guidé par une intention. La modélisation ExaProtect adapte ces définitions à la notion de mouvement pour déterminer les règles sémantiques d'un mouvement. 6.2.3.3.1 Règle sémantique du concept « mouvement » Le mouvement qui intéresse le dispositif de surveillance conforme au mode de réalisation particulier de l'invention s'intéresse aux mouvements qui permettent l'obtention d'un gain ou d'un échec lors des opérations d'accès aux différents composants du SI. Dans l'exemple ci-dessus, c'est le refus de l'accès au SI conforme à l'intention « AUTHENTICATION » qui intéresse le système de surveillance et non la cause du refus. Règle 4 : L'ensemble des mouvements représente l'ensemble des moyens mis en oeuvre par un attaquant, un utilisateur, un administrateur dans un but ou une intention 1) d'accès par entrée/sortie, 2) de modification (par ajout, suppression, mise à jour) ou 3) de mise à disponibilité de ressources (démarrage de service, etc..). 6.2.3.3.2 Règle linguistique mouvement La syntaxe du concept mouvement utilise le troisième champ du modèle Exa : (Intention_Activity-Type_Movement_Targetl_Detail2_Result ) La modélisation ExaProtect a retenu comme mouvements pertinent les mouvements d'accès aux différents mécanismes du SI entraînant un gain. Ces 25 mouvements sont normaux ou anormaux et sont regroupés selon les règles décrites ci-après. 6.2.3.3.2.1 Activités normales d'un agent - Les mouvements d'entrée/sortie d'un agent ayant une activité normale sur le SI et pour une intention: - d'authentification sur le SI. Les mouvements d'entrée comme (login), ou de sortie comme la déconnexion (logout), le verrouillage de compte (locked)) - d'accès à une ressource en entrée (gain, read) - d'accès aux fonctions du systèmes : les mouvements d'entrée (read, gain, receive, connection) ou de sortie (send, forward) - Les mouvements de « mise à disponibilité » effectués par un agent ayant une activité normale sur le SI et pour une intention : - d'authentification sur le SI comme la disponibilité d'un compte via des procédures de : (backup, restore, lock, unlock) - d'accès à une ressource du SI comme la disponibilité de fichiers, répertoires, etc. par des opérations de (backup, restore, control) - d'accès aux fonctions du systèmes comme la disponibilité de services, applications, composants ou processus : (backup, restore, execute, started, up, ended, restarted, stopped, down, control) - Les mouvements de modification effectués par un agent ayant une activité normale de configuration sur le SI et pour une intention: - d'accès au SI comme la modification de comptes (add, delete, modify), - d'accès à une ressource comme la modification de privilèges, etc. add, delete, modify), ou comme l'ajout de fichiers (write, delete) -, ou encore - d'accès aux fonctions du systèmes comme la modification d'un fichier de configuration, etc. (write, delete) ou son ajout (add, modify,delete). 6.2.3.3.2.2 Activités anormales d'un agent - Les mouvements d'entrée/sortie d'un agent ayant une activité anormale sur le SI et pour une intention soit d'accès au SI, d'accès à une ressource ou d'accès aux fonctions système comme les mouvements : - d'entrée (bruteforce, backdoor, bypass, evasion, gain, hijacking, informationleak, informationgathering, phishing, violation' spoofing,) et, - de sortie par des actions d'attaque (concealment, steal, informationleak) Ou de malware (spyware, trojan). - Les mouvements de modifications d'un agent ayant une activité anormale pour une intention d'accès soit au SI, soit à une ressource ou soit aux fonctions système comme la modification de privilèges, etc. , des entrées (injection,), ou des malware (spyware) - Les mouvements de « mise à disponibilité » effectués par un agent ayant une activité anormale sur le SI et quelque soit l'intention (dos, overflow, 15 spam) Par exemple, le MOUVEMENT d'ouverture de session d'un compte Administrateur du service SSH a réussi pour l'intention « accès via authentification » qui correspond aux messages : SSH Remote root login 20 User admin login successfully from SSH peut être modélisé par : Authentication Activity Login SSH Admin success Le MOUVEMENT de modifications de la configuration d'un groupe a échoué pour l'intention « modification via autorisation » qui correspond aux messages : 25 User cannot be removed from a group Member could not be added to or removed from the local group peut être modélisé par : Rights Config Modify OS AccountGroup failed 6.2.3.4 - Gain selon le mode de réalisation particulier de l'invention La figure 2 montre qu'un message exprime le résultat ou le gain d'une action (ou Result 2005) selon le mouvement 2003, l'intention 2001, la cible 2002 et le type d'activité 2006. La réussite ou l'échec d'une action sur le SI dépend de certaines conditions. Si ces conditions ne sont pas conformes aux règles qui gèrent l'accès au SI ou aux ressources du SI ou si les informations collectées ne sont pas conformes aux informations environnementales, l'action est un échec ou dans le cas contraire, une réussite. 6.2.3.4.1 Règle sémantique du concept « gain » Dans la présente ontologie, le concept de « gain » évalue la progression de l'agent selon les trois catégories principales: - l'agent (quel qu'il soit) : l'agent a progressé vers la cible au travers de son action : success, s'il est un attaquant au sens de la présente invention : detected. - l'agent (quel qu'il soit) n'a pas été admis à progresser vers la cible du fait du refus d'un mécanisme d'accès (authentification, privilèges ou fonction système) : failed ou denied. - l'agent (quel qu'il soit) n'a pas progressé vers la cible au travers de son action:du fait d'un dysfonctionnement du système qu'il utilise pour accomplir son action error. La réussite ou l'échec d'une action dépend aussi de l'observateur : du point de vue du système de surveillance, une attaque réussie est detected alors que par un attaquant elle représente une étape réussie dans son plan d'attaque. Une action normale peut être un gain si la progression pour l'administrateur est réussie ou si la progression de l'usager a atteint son objectif. De même pour les utilisateurs, chaque utilisateur a l'intention d'obtenir un gain sur une ressource, chaque mouvement s'accomplit dans cette intention. Enfin du point de vue du système, parvenir à maintenir sa disponibilité constitue une réussite. Par exemple, le démarrage d'un service constitue un gain de disponibilité pour le système, l'authentification d'un utilisateur constitue un gain d'accès pour l'utilisateur, la détection d'une attaque constitue un gain de « détection » pour le système, Règle 5 : Les actions de progression : à chacune des étapes du plan, le résultat est un gain (succès ou échec) afin d'évaluer la progression des agents vers les cibles visées. Règle 5a : Les états du système : le résultat exprime une évaluation quantitative ou qualitative de la cible. Un résultat qualitatif exprime la conformité alors qu'un résultat quantitatif exprime un dépassement de seuil. Règle 5b : Les vulnérabilités : le résultat est un contrôle effectué par un scanner de vulnérabilité dont le message résultant exprime la détection de celle-ci.. 6.2.3.4.2 Règle linguistique du concept « gain » La syntaxe du concept « résultat » utilise le dernier champ du modèle Exa : (IntentionActivity-TypeMovementTargetl_Detail2_Resu/t) On distingue les gains pour les intentions correspondants aux mouvements normaux, anormaux ou d'état. 6.2.3.4.2.1 NORMAUX Ce sont les intentions correspondant aux mouvements liés à au moins une action qui n'affecte pas la configuration du SI ou qui affecte la configuration du SI (référencées 7001 et 7002): - les succès (ci-après référencées par gains success) ; - les échecs (ci-après référencées par gains Failed) ; - les refus (ci-après référencées par gains Denied); - les erreurs (ci-après référencées par gains Error) ; 6.2.3.4.2.2 ANORMAUX Ce sont les intentions correspondant aux mouvements liés à au moins une attaque ou à au moins un logiciel malveillant développé dans le but de nuire au SI ou à au moins une vulnérabilité du SI ou à au moins une action suspecte détectée par au moins une sonde de détection d'action du SI : On évite d'exprimer le gain dans ces cas par un succès, car sémantiquement, le succès d'une attaque représente sa réalisation sans qu'elle ne soit détectée par une source d'informations. De ce fait, le terme « detected» est utilisé (référencé 7003 et 7004). 6.2.3.4.2.3 ETATS Ce sont les intentions correspondant aux mouvements reflétant un état constaté du SI dont les gains : 1- liés aux informations de contrôle des actions des cibles pour des intentions correspondant à au moins un mouvement reflétant au moins une action d'au moins une cible du SI qui comprennent : - les états valides suite à au moins un contrôle (ci-après référencé par Valid) ; - les états invalides suite à au moins un contrôle (ci-après référencé par invalid) ; - les notifications sur au moins une cible suite à au moins un contrôle (ci-après référencé par Notify). 2- liés aux informations de contrôle de l'utilisation des seuils sur les cibles pour des intentions correspondant à au moins un mouvement reflétant au moins une utilisation d'au moins un seuil sur au moins une cible du SI qui comprennent : - les dépassements d'au moins un seuil temporel (ci-après référencé par Expired) ; - les dépassements d'au moins un seuil qui n'est pas lié au temps (ci- après référencé par Exceeded) ; - les utilisations basses d'au moins un seuil (ci-après référencé par Low), les seuils peuvent être une limite sur des droits, ou peuvent exprimer le manque de privilège d'un utilisateur ; - les utilisation normales d'au moins un seuil (ci-après référencé par Normal); - les utilisation hautes d'au moins un seuil (ci-après référencé par High). 6.2.3.5 - Cible selon le mode de réalisation particulier de l'invention Toutes les ressources du système représentent une cible. Les cibles sont des entités logiques, représentant des actifs du SI - utilisateur, données, processus, protocole - ou des entités physiques - composants, équipements, interconnexions 6.2.3.5.1 Règle sémantique du concept « Target » La particularité d'un système de surveillance est d'évaluer toutes les actions dangereuses potentiellement produites sur la cible au cas où elles atteindraient leur but: la cible est donc au coeur de l'action. De cette manière, la prise en compte des cibles se rapproche des modèles de risque où toute valeur de la cible varie suivant l'intention portée par l'évènement normalisé. Par ailleurs, les actions réelles observées par le système de surveillance sont le résultat des interactions entre les acteurs et les actifs du SI. C'est pourquoi notre modélisation des cibles va dépendre de l'une ou m'autres des 4 composantes « intention ». La surveillance met en interaction l'agent et l'actif, ce qui s'exprimera souvent par le couple (acteur, actif) désigné (Target Type, Target Detail). 6.2.3.5.2 Règle linguistique du concept « Target » 1) Dans le cas d'une intention Authentication, les éléments Target Type et Target Detail du couple (Target Type, Target Detail) concernent respectivement le mécanisme d'authentification et l' authentifié qui représente le compte qui a ouvert une session dans le SI. 2) Dans le cas d'une intention Rights, le couple (Target Type, Target Detail) concerne respectivement le propriétaire de la ressource et la ressource dont les droits ont été utilisés pour y accéder. 3) Dans le cas d'une intention System ou Information_Gathering, le couple concerne respectivement le composant système et son attribut comme par exemple les deux composants physiques (Ilote , cPu) où CPU est un attribut de Host ou deux composants logiques (wEB , URL)où URL est l'attribut de Web. 6.3 Conclusion Les concepts de l'ontologie ont été extraits via la théorie de l'action. Cependant, afin de les valider, une approche classique fondée sur la connaissance experte a permis de confronter les premiers résultats de la théorie de l'action. Ainsi, les normes «ISO/IEC 15408 Information Technology - Security techniques » - « Evaluation criteria for IT security » ainsi que les « Critères Communs » ont permis de consolider la modélisation. L'ontologie selon le mode de réalisation particulier de l'invention a été vérifiée sur un corpus de 20182 messages issus de sources d'informations hétérogènes Ainsi, le nombre de messages destinés à l'analyste peut être réduit de 20182 à 1734 (cibles comprises). Cette ontologie peut être appliquée dans un contexte de détection d'intrusions coopérative car elle permet l'interopérabilité entre les différentes sources d'informations et le traitement automatique de la sémantique du message par des programmes automatiques. La détection d'intrusions est donc efficace dans le cas de coopération entre sources d'informations pour la surveillance des intentions et des mouvements. 6.4 Exemple de modélisation Voici quelques exemples de la formulation générique que propose la normalisation : Un déni de service a été détecté pour une attaque d'authentification AUTHENTICATION ATATCK DOS SERVICE DETECTED _ _ Un login d'un utilisateur du service d'authentification a réussi pour une activité d'authentification AUTHENTICATION ACTIVITY LOGIN SERVICE USER SUCCESS Un ajout du compte utilisateur du service d'authentification a réussi pour une activité de configuration d'authentification AUTHENTICATION CONFIG ADD SERVICE USER SUCCESS _ Une réception de paquets du protocole a réussi pour une activité système SYSTEM ACTIVITY RECEIVE PROTOCOLE PAQUET SUCCESS Une réception de paquets du protocole a été refusée pour une activité système SYSTEM ACTIVITY RECEIVE PROTOCOLE PAQUET DENIED Une injection de code du service http a été détectée pour une attaque système. SYSTEM ATTACK CODEINJECTION SERVICE DETECTED _ 6.5 La transformation selon le mode de réalisation particulier de l'invention On décrit ci-après la transformation qui comprend des étapes de décomposition, comparaison et génération précitées, (tel qu'illustrées par les figure 7 et 9), par des moyens de transformation 8002, d'un message 8001 constitué d'une phrase en langage pseudo-naturel (appelée couramment un message, un événement brut ou un log brut) émise par n'importe qu'elle source d'informations (ou sonde de détection) en un événement normalisé par comparaison avec une catégorie d'événement de référence 8003 (qui est une phrase normalisée). Il est important en outre que le processus de transformation respecte et préserve le sens initial du message (ou événement brut), c'est à dire l'action qu'il modélise, L'étape de décomposition, qui s'appuie sur la modélisation précitée, selon le mode de réalisation particulier de l'invention permet comme nous l'avons vu d'obtenir des premier, second, troisième, quatrième, cinquième, sixième et septième messages décomposés (tels que ceux présentés dans les tableaux des figures 5A ou 5B) à partir de ces premier, second, troisième quatrième, cinquième, sixième et septième messages. a) premier message collecté dans le journal d'audit SYSLOG d'une source d'informations d'un système d'exploitation Solaris : SU : command success b) second message collecté dans le journal d'audit d'une source d'informations d'un système d'exploitation AIX : Rshd : Root login success c) troisième message collecté dans le journal d'audit d'une source d'informations de type équipement réseau (switch, routeur,...) : Admin login d) quatrième, cinquième, sixième et septième message collectés dans le journal d'audit d'une source d'informations de type équipement de sécurité (firewall, IDS,...) : User admin login successfully from GUI Root login Admin Connection SMB: Administrator Logon Success 0x40705a00. La tâche de l'expert de sécurité consiste en la décomposition (qui fait partie du processus de transformation) d'un message (ou log brut) afin d'obtenir un message décomposé caractérisé par les différentes composantes (INTENTION, MOUVEMENT, TARGET TYPE, TARGET DETAIL et GAIN). L'expert obtient les valeurs suivantes des composantes : INTENTION = Authentication ; MOUVEMENT =Authentication_Activity_Login ; TARGET TYPE = choix dans la liste des services d'authentifications 25 définis pour Authentication_Activity_Login TARGET DETAIL = choix dans la liste des utilisateurs définis pour Authentication_Activity_Login ; GAIN = choix dans la liste résultat : failed/success. L'expert de sécurité utilise un outil de transformation afin de faire correspondre un message brut en un message décomposé. La décomposition sémantique permet d'appliquer les règles des modèles précitées, la décomposition syntaxique applique le modèle générique ExaProtect et la décomposition lexicale les termes correspondant du lexique ExaProtect. Puis, le processus de transformation comprend une étape de comparaison des premier, second, troisième, quatrième, cinquième, sixième et dernier messages décomposés avec des catégories d'événement de référence à la suite de laquelle sont générés des premier, second, troisième et quatrième événement normalisés. 6.5.1 - L'étape de décomposition selon le mode de réalisation particulier de l'invention L'expert de sécurité recherche des valeurs sémantiques ou/et syntaxiques ou/et lexicales des 5 concepts dans un message. Le schéma 11000 décrit la démarche de l'expert de sécurité dans l'objectif de la décomposition du message (à décomposer) 11001. L'expert travaille selon son choix sur l'un des 3 processus de reconnaissance, ce raisonnement est assisté d'un outil linguistique pour faciliter tout ou partie de la recherche. L'étude ci-après détermine que reconnaître un mouvement est déterminant : mouvement est un concept de poids fort. 6.5.1.1 - Mouvement, un concept de poids fort Le tableau ci-après montre que le concept « mouvement » est un concept de poids fort car la connaissance de celui-ci permet à l'expert de déduire (implicite) les autres concepts. Dans le cadre de la transformation selon le mode de réalisation particulier de l'invention, DETECTER UN MOUVEMENT c'est TRANSFORMER. Dans le cas contraire, la démarche de l'expert sera de détecter l'un des autres concepts en suivant le questionnement sémantique précédent détaillée dans la figure (11002). Le tableau ci-dessous montre cinq cas de messages pour lesquels l'expert a successivement la connaissance de la valeur de certaines composantes 30 (Movement, Intention, Target Type, Target Detail et Gain) et pour lesquels il est possible de réaliser une décomposition selon le mode de réalisation particulier de l'invention ou non. Pour le premier message (qui correspond à la première ligne), l'expert détecte immédiatement le mouvement, puis la Target Detail, puis le gain. La reconnaissance de l'intention et de la Target Type est implicite, ce qui lui permet de décomposer le message correspondant. Pour les second, troisième et quatrième messages (qui correspondent respectivement aux seconde, troisième et quatrième lignes), l'expert ne détecte pas le mouvement, ce qui ne lui permet pas de décomposer ces messages. Pour le cinquième message (qui correspond à la cinquième ligne), l'expert détecte plusieurs valeurs pour les composantes précitées, ces ambiguïtés ne permettent pas de décomposer le message correspondant. Si l'expert reconnaît le Si l'expert reconnaît Si l'expert La transformation mouvement ou/et une cible ? reconnaît est-elle possible ? l'intention Target un gain ? Movement Intention Type Detail Gain TRANSFORMATION 1 Oui Implicite Implicite Oui Oui Oui 2 Non Plusieurs Plusieurs Plusieurs Oui Non 3 Non Non Oui Oui Oui Selon la cible 4 Non Plusieurs Oui Plusieurs Oui Non 5 Plusieurs Plusieurs Plusieurs Plusieurs Oui Non Par le biais des règles et par la modélisation selon le mode de réalisation particulier de l'invention, l'expert est guidé pour détecter les autres composantes (Intention, Activity Type, Movement, Target Type, Target Detail et Gain) présentes dans le message qu'il lit et pour identifier au mieux la catégorie d'événement de référence qui lui correspond le cas échéant. 6.5.1.2 - Couples de cible, des concepts de poids forts Pour certains messages la connaissance de la cible donne implicitement la valeur de l'intention. Ceci est logique puisque certaines cibles ne sont compatibles qu'avec certaines intentions. Nous pouvons citer les cas suivants : La cible « compte utilisateur » est liée à (car ne se rencontre qu'avec) l'intention « authentification » : ceci s'explique car du point de vue technique le mécanisme d'authentification lié à l'intention « authentication » requiert toujours un compte user pour fonctionner. La cible « groupe » est liée à l'intention « rights », ceci s »explique car du point de vue technique les mécanismes d'autorisation sont les seuls 5 mécanismes à manipuler des groupes utilisateur. La cible « memory » est liée à « system » ceci s'explique car du point de vue technique les mécanismes système sont les seuls à manipuler les composants physiques du SI. 6.5.1.3 - Traitement des concepts de poids faible 10 Dans le processus de transformation selon le mode de réalisation particulier de l'invention, l'obtention du MOUVEMENT n'est pas toujours possible ou précise, l'expert doit alors utiliser d'autres « points d'entrée » pour extraire la sémantique du message. Par exemple, en cas de difficulté pour identifier le MOUVEMENT, il peut extraire l'intention, la cible ou le gain. 15 Par exemple, sur 12 messages comprenant la cible « anonymous », 100% comprennent l'intention « authentication », sur 28 messages comprenant la cible « memory », 100% comprennent l'intention « system » (et correspondent soit à des informations soit à des attaques), sur 40 messages comprenant la cible « group », 100% comprennent l'intention « rights », sur 135 messages comprenant 20 la cible « user », 77% comprennent l'intention « authentication ». Nous distinguons les : -cibles qui vont permettre de définir l'intention, le type d'activité ou le mouvement ; -cibles qui permettent plusieurs choix ; 25 -cibles démunies de toute sémantique vis-à-vis de l'intention ou du mouvement. 6.5.1.4 - Application des règles sémantiques, syntaxiques et linguistiques pour la décomposition d'un message selon le mode de réalisation particulier de l'invention Le raisonnement ci-dessous est initialisé par une requête de décomposition du message. Chacune des étapes de décomposition peut être menées indépendamment de l'ordre d'exécution de chacune. L'expert va mener une recherche sémantique (référencé 10002 sur la figure 9) ou une recherche lexicale (référencé 10003) ou une recherche syntaxique (référencé 10004). I- L'expert reconnaît les 5 concepts : intention activité mouvement cible 1-a il identifie à l'aide de la recherche lexicale les termes correspondant à l'un des 5 CONCEPTS. 1-b Il applique la syntaxe générique du modèle Exa 2- L'expert ne reconnaît qu'un concept de poids fort 2-a Il déduit les autres concepts 2-b Il réalise les étapes à partir de 1.a 3- L'expert reconnaît au moins un des 4 concepts : intention, activite'cible, résultat. 3-a Il ne possède aucun concept de poids fort 3-b Il s'aide de la recherche lexicale pour détecter l'un des cinq concepts 3-c Il détecte un concept de poids fort 3-d Il réalise les étapes à partir de 2 puis 1. 4- L'expert ne reconnaît aucun des 5 concepts : intention, activité, mouvement, cible, résultat, 4-a Il ne possède aucun concept de poids fort 4-b Il ne peut pas s'aider de la recherche lexicale pour détecter l'un des cinq concepts 4-c Il définit si le message est une étape ou un état ou une vulnérabilité 4-d Il détecte le concept étape 4-d-i) Il décompose le message brut selon la forme syntaxique (la phrase générique adaptée au message étape) 4-d-ii) Il détecte selon la position du terme dans la phrase le concept associé devenu concept de poids fort 4-d-iii) Il détecte par exemple un concept de poids fort « mouvement ». 4-d-iv) Il définit la sémantique par le biais des règles sémantiques : 4-d-iv-(1) est ce un mouvement d'accès au SI, 4-d-iv-(2) un mouvement de modification, ... ? 4-d-iv-(3) un mouvement d'accès aux fonctions vitales du SI ? 4-d-iv-(4) est ce une intention authentification ou rights ou system ? 4-d-iv-(5) Il réalise les étapes à partir de 1.a 4-d-v) Il détecte par exemple un concept « intention » 4-d-vi) Il définit la sémantique par le biais des règles sémantiques, est ce une intention d'accès: 4-d-vi-(1) via un mécanisme d'authentification ? 4-d-vi-(2) via un mécanisme de privilège ? 4-d-vi-(3) via un mécanisme système ? 4-d-vi-(4) Il réalise les étapes pour les autres concepts à partir de 2 puis 3 puis 4 et 1.a 4-d-vii) Il détecte par exemple un concept « activity » 4-d-viii) Il définit la sémantique par le biais des règles sémantiques, est ce une action normale ou anormale ou suspicieuse: 4-d-viii-(1) Il détecte une activité anormale ou suspicieuse 4-d-viii-(2) Il définit la sémantique de l'attack ou du malware ou de la suspicion en retournant à l'étape 1.a 4-d-viii-(3) est ce une intention authentification ou rights ou system ? 4-d-viii-(4) Il réalise les étapes pour les pour les concepts cibles à partir de 4 puis 1.a 4-e Il détecte un concept d'activité d'état 4-e-i) Il décompose le message brut selon la forme syntaxique (la phrase générique adaptée au message état) 4-e-ii) Il définit la sémantique de l'activité d'état : 4-e-ii-(1) Est-ce une information qualitative ? 4-e-ii-1-(a) est ce une intention authentification ou rights ou system ? 4-e-ii-1-(b) Il réalise les étapes à partir de 1.a 4-e-ii-1-(c) Il réalise les étapes pour les pour les concepts cibles à partir de 4 puis 1.a 4-e-ii-(2) Est-ce une information quantitative ? 4-e-ii-2-(a) est ce une intention authentification ou rights ou system ? 4-e-ii-2-(b) Il réalise les étapes à partir de 1.a 4-e-ii-2-(c) Il réalise les étapes pour les pour les concepts cibles à partir de 4 puis 1.a 4-f Il détecte un concept d'activité de vulnérabilité 4-f-i) Il décompose le message brut selon la forme syntaxique (la phrase générique adaptée au message vulnérabilité) 4-f-ii) Il définit la sémantique de la vulnérabilité : 4-f-ii-(1) Est-ce une vulnérabilité d'intention authentification ou rights ou system ? 4-f-ii-(2) Il réalise les étapes pour les pour les concepts cibles à partir de 4 puis 1.a 4-g Il réalise les étapes à partir de 1.a 5- L'expert ne reconnaît que l'un ou plusieurs des 5 concepts intention, activité, mouvement, cible, résultat. 5-a Il ne possède aucun concept de poids fort 5-b Il ne peut pas s'aider de la recherche lexicale pour détecter l'un des cinq concepts 5-c Il ne peut pas définir si le message est une étape ou un état ou une vulnérabilité 5-d Il ne peut pas décomposer le message brut selon la forme syntaxique (la phrase générique adaptée au message état ou étape) 5-e Il ne peut associer de concept à la position du terme dans la phrase 5-f Il explore les bases de connaissances expertes pour déterminer l'un des 5 concepts. 5-g Il réalise les étapes pour les pour chaque concept à partir de 2,3,4, 5 pour les autres concepts puis 1.a 6- L'expert ne peut normaliser le message 6.5.1.5 - Décomposition d'un message à partir du concept « mouvement » On présente en relation avec la figure 8, les étapes principales d'un algorithme de décomposition (ou d'extraction de la sémantique) explicite d'un 20 message 9001 en un message décomposé 9005 selon un premier exemple conforme au mode de réalisation particulier de l'invention. Le message 9001 est « User admin login successfully from SSH». Par exemple, lors d'une première étape 9002, l'expert de sécurité extrait le MOUVEMENT que ce message exprime. Par exemple, le message 9001 permet 25 sans ambiguïté de modéliser un MOUVEMENT d'ouverture de session (« login »). De même, il est facile, dans une seconde étape 9003, d'extraire le gain (« success ») et, dans une troisième étape 9004, les cibles « admin » et « SSH » de ce message 9001. Ainsi, l'extraction du sens du message 9001 permet de décomposer le message 9001: « User admin login successfully from SSH» en le 30 message décomposé 9005 qui prend la forme suivante : 6.5.1.6 - L'étape de comparaison et de génération selon le mode de réalisation particulier de l'invention Une fois que l'on a construit, dans l'étape de définition précitée, les catégories d'événement de référence, 1746 telles catégories ont par exemple été construite, à partir de l'ontologie et des « wokflow » selon l'invention (en définissant un ensemble de valeurs d'intention, de mouvement, d'activité, de cible et de gain pour chacune d'entre elles), par les inventeurs de la présente invention. Ainsi, un message (ou événement brut), une fois décomposé en message décomposé par le processus de transformation selon le présent mode de réalisation particulier de l'invention, peut : - correspondre à une (parmi les 1746) catégorie d'événement de référence donnée, et alors préférentiellement, il est vérifié que la catégorie d'évènements de référence donnée n'est pas déjà présente dans une première base de données (premier moyen de stockage) et dans le cas d'une vérification positive, cette catégorie donnée est stockée dans la première base de données ; - ne correspondre à aucune catégorie d'événement de référence (parmi les 1746 catégories), et alors préférentiellement, le message décomposé est stocké dans une seconde base de données (second moyen de stockage). 6.5.2 - Interprétation et représentation de la connaissance selon le mode particulier de réalisation de l'invention L'analyste de sécurité doit tout d'abord comprendre les messages, puis, il lui faut acquérir la connaissance qui lui permettra de créer des règles de traitement (normalisation, agrégation, corrélation). Ainsi, le travail de l'analyste de sécurité présente deux aspects que sont l'analyse des messages et la création de scenarii de normalisation, d'agrégation ou de corrélation. 6.5.2.1 - Représentation graphique de la normalisation Afin de fournir une vue synthétique des actions modélisées nous avons présenté les 5 concepts et leurs instances sous forme d'une mire (illustrée par la figure 10) décrivant ainsi les différentes combinaisons d'actions possibles. Afin d'exprimer la notion de progression (les étapes du profil), nous avons construit la mire selon trois zones concentriques tel que les actions les plus éloignées de la cible telle que les « AUTHENTICATION » (référencées 11001) soient en zone verte clair, les actions d'accès aux fonctions vitales du SI « SYSTEM » (référencées 11003), soient en zone rouge clair, et les actions d'accès aux ressources «RIGHTS » (référencées 11002) soient en zone orange. Le type des activités est exprimé par des parts dans le graphique: « vert foncé » représente des activités normales (référencées 11005), « rouge foncé » des anomalies (référencées 11004) et « transparents » des informations d'états ou de vulnérabilités (référencées 11006). 6.5.2.2 - Représentation graphique de la phase de génération d'évènements normalisés Les évènements normalisés sont représentés sous forme tabulaire et caractérisés par la date, le nom, la source et la destination et le message brut dont le nom possèdent la structure de la catégorie d'évènement de référence.15 REVENDICATIONS1. Procédé de surveillance d'au moins un message, chaque message étant associé à une action produite par au moins un élément ou utilisateur d'un système d'information (1000) ci-après désigné par SI, le ou lesdits message(s) étant collecté(s) par au moins un dispositif de collecte de message du SI, caractérisé en ce qu'il comprend les étapes suivantes : - définition d'une pluralité de catégories d'évènements de référence associées, chacune, à au moins une action de référence à partir d'une ontologie basée sur une classe d'intention (2001) qui caractérise le but de chaque action de référence, une classe de type d'activité (2006) qui qualifie la nature de chaque action de référence, une classe de mouvement (2003) qui caractérise les moyens permettant la mise en oeuvre de chaque action de référence, une classe de cible (2002) qui caractérise l'objet de chaque action de référence et une classe de gain (2005) qui caractérise la résultat de chaque action de référence ; et pour chaque message donné, - décomposition dudit message donné dans une base formée par la classe d'intention, la classe de type d'activité, la classe de mouvement, la classe de cible et la classe de gain ; comparaison du message décomposé avec au moins une catégorie 20 d'événement de référence ; - génération d'au moins un événement normalisé représentatif d'une correspondance entre le message décomposé et la catégorie d'événement de référence. 2. Procédé de surveillance selon la revendication 1, caractérisé en ce que si le 25 message décomposé correspond à une catégorie d'évènements de référence, alors le procédé comprend les étapes suivantes : - vérification que la catégorie d'évènements de référence n'est pas déjà présente dans un premier moyen de stockage ; - dans le cas d'une vérification positive, stockage de ladite catégorie 30 d'évènements de référence dans ledit premier moyen de stockage. 3. Procédé de surveillance selon l'une quelconque des revendications 1 et 2, caractérisé en ce que si le message décomposé ne correspond à aucune desdites catégories d'événement de référence, alors le procédé comprend l'étape suivante : - stockage du message dans un second moyen de stockage. 4. Procédé de surveillance selon l'une quelconque des revendications 1 à 3, caractérisé en ce que, lors de l'étape de définition d'une pluralité de catégories d'événement de référence, au moins une desdites catégorie d'évènements de référence est définie à partir d'au moins une autre desdites catégorie d'évènements de référence et d'au moins une règle appartenant au groupe comprenant : des règles syntaxiques ; des règles lexicales ; des règles sémantiques. 5. Procédé de surveillance selon l'une quelconque des revendications 1 à 4, caractérisé en ce que, pour au moins une desdites catégories d'évènements de 15 référence, il comprend une étape de comptage d'un nombre de message(s) décomposé(s) qui correspond(ent) à ladite catégorie d'événement de référence. 6. Procédé de surveillance selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ladite classe d'intention (2001) comprend les intentions suivantes : 20 - les intentions de découvrir et/ou de collecter au moins une information sur au moins une cible du SI (1000) ; - les intentions d'accéder au SI au moyen d'au moins une procédure d'authentification mettant en oeuvre au moins une information d'identification ; - les intentions d'accéder à au moins une ressource du SI au moyen d'au 25 moins une procédure exigeant des droits ; - les intentions d'accéder à une disponibilité d'au moins une ressource du SI. 7. Procédé de surveillance selon l'une quelconque des revendications 1 à 6, caractérisé en ce que ladite classe de mouvement (2003) comprend les 30 mouvements suivants :- les mouvements liés à au moins une action qui n'affecte pas la configuration du SI ; -les mouvements liés à au moins une action qui affecte la configuration du SI ; -les mouvements liés à au moins une attaque ; -les mouvements liés à au moins un logiciel malveillant développé dans le but de nuire au SI ; -les mouvements liés à au moins une action suspecte détectée par au moins une sonde de détection d'action du SI ; -les mouvements liés à au moins une vulnérabilité du SI ; -les mouvements reflétant un état constaté du SI. 8. Procédé de surveillance selon l'une quelconque des revendications 1 à 7, caractérisé en ce que ladite classe de gain (2005) comprend : -pour les intentions correspondants aux mouvements liés à au moins une action qui n'affecte pas la configuration du SI et aux mouvements liés à au moins une action qui affecte la configuration du SI : - les succès ; - les échecs ; - les refus ; - les erreurs ; -pour les intentions correspondants aux mouvements liés à au moins une attaque, aux mouvements liés à au moins un logiciel malveillant développé dans le but de nuire au SI, aux mouvements liés à au moins une vulnérabilité du SI et aux mouvements liés à au moins une action suspecte détectée par au moins une sonde de détection d'action du SI : - les détections ; -pour les intentions correspondant aux mouvements reflétant un état constaté du SI : - les gains des intentions correspondant à au moins un mouvement 30 reflétant au moins une action d'au moins une cible du SI ;- les gains des intentions correspondant à au moins un mouvement reflétant au moins une utilisation d'au moins un seuil sur au moins une cible du SI. 9. Procédé de surveillance selon la revendication 8, caractérisé en ce que les gains (2005) des intentions (2001) correspondant aux mouvements (2003) reflétant des actions des cibles (2002) du SI comprennent : - les états valides suite à au moins un contrôle ; - les états invalides suite à au moins un contrôle ; - les notifications sur au moins une cible suite à au moins un 10 contrôle. 10. Procédé de surveillance selon l'une quelconque des revendications 8 et 9, caractérisé en ce que les gains (2005) des intentions (2001) correspondant aux mouvements (2003) reflétant des utilisations de seuils sur des cibles (2002) du SI : les dépassements d'au moins un seuil temporel ; 15 les dépassements d'au moins un seuil qui n'est pas lié au temps ; les utilisations basses d'au moins un seuil ; les utilisation normales d'au moins un seuil ; - les utilisation hautes d'au moins un seuil. 11. Produit programme d'ordinateur, téléchargeable depuis un réseau de 20 communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre du procédé de surveillance selon l'une au moins des revendications 1 à 10. 12. Moyen de stockage, éventuellement totalement ou partiellement amovible, 25 lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé de surveillance selon l'une au moins des revendications 1 à 10. 13. Dispositif de surveillance d'au moins un message, chaque message étant associé à une action produite par au moins un élément ou utilisateur d'un systèmed'information (1000) ci-après désigné par SI, le ou lesdits message(s) étant collecté(s) par au moins un dispositif de collecte de message du SI, caractérisé en ce qu'il comprend : - des moyens de définition d'une pluralité de catégories d'évènements de référence associées, chacune, à au moins une action de référence à partir d'une ontologie basée sur une classe d'intention (2001) qui caractérise le but de chaque action de référence, une classe de type d'activité (2006) qui qualifie la nature de chaque action de référence, une classe de mouvement (2003) qui caractérise les moyens permettant la mise en oeuvre de chaque action de référence, une classe de cible (2002) qui caractérise l'objet de chaque action de référence et une classe de gain (2005) qui caractérise la résultat de chaque action de référence ; et pour chaque message donné, - des moyens de décomposition dudit message donné dans une base formée par la classe d'intention, la classe de type d'activité, la classe de mouvement, la classe de cible et la classe de gain ; - des moyens de comparaison du message décomposé avec au moins une catégorie d'événement de référence ; - des moyens de génération d'au moins un événement normalisé représentatif d'une correspondance entre le message décomposé et la catégorie 20 d'événement de référence.