FR 2910204 A1 20080620 FR 0655521 A 20061214 SYSTEME ET PROCEDE DE SURVEILLANCE PASSIVE D'UN RESEAU DE COMMUNICATION La présente invention a pour objet un système et un procédé de surveillance passive d'un réseau de communication. Elle trouve notamment son application à tous les systèmes et procédés de détection et de prévention d'intrusions dans un réseau de communication. Par systèmes et/ou entités présentes sur un réseau de communication, on entend tout système ou service, par exemple de type zo système d'exploitation ou serveur (web, d'application, de messagerie, de base de données, etc...). Par souci de simplification, dans toute la suite de la description, on utilisera l'expression entités présentes sur le réseau de communication au lieu de l'expression systèmes et/ou services présents sur le réseau de communication . 15 On connaît des systèmes de surveillance d'un réseau de communication, basés sur l'exécution de tests en vue d'établir l'existence d'un risque ou d'une vulnérabilité sur ce réseau de communication. Une des difficultés de mise en oeuvre de ces systèmes réside dans la définition des tests et leur mise à jour 20 Par ailleurs, les performances de ces systèmes sont primordiales. Ces systèmes nécessitent en effet une analyse rapide dans la mesure où le traitement du trafic sur le réseau se fait en temps réel. Enfin, la question de la consommation mémoire se pose également. En effet, de tels systèmes sont généralement embarqués sur du matériel à 25 faible capacité mémoire. On distingue généralement entre les systèmes dits actifs qui vont initier les connexions vers les machines analysées, et les systèmes passifs qui se contentent d'analyser le trafic du réseau qu'ils protègent. Un système passif est tout particulièrement intéressant pour 30 l'intégration dans un système plus général de détection et de prévention des intrusions dans un réseau de communication. 2910204 2 Les performances de ces systèmes reposent donc essentiellement sur leur capacité à reconnaître une vulnérabilité d'un service ou d'un système donné, donc d'une entité donnée, en temps réel. Or, les systèmes classiques utilisant des tests exécutés sur le trafic 5 du réseau n'atteignent pas les performances optimales, en raison notamment de la complexité des règles de vulnérabilité. De plus, ces systèmes classiques n'exécutent pas et n'intègrent pas les résultats des tests de détection de vulnérabilité dans le contexte des machines suivies, ce qui rend les résultats plus difficiles à analyser. Tous ces inconvénients rendent les systèmes compliqués et souvent peu performants. Le problème qui se pose alors est donc de disposer d'un système de surveillance passive d'un réseau de communication dans lequel les règles de vulnérabilités à évaluer par un moteur d'inférence soient plus simples à mettre en place et à mettre à jour, avec un résultat d'évaluation plus facile à analyser. L'objet de l'invention est donc d'apporter une solution au problème précité parmi d'autres problèmes. L'invention se rapporte donc, selon un premier aspect, à un système passif de surveillance d'un réseau de communication comprenant une base de faits contenant une ou plusieurs données dynamiques représentant le suivi du réseau, une base de connaissances contenant au moins une règle de vulnérabilité des entités présentes sur le réseau de communication, et un moteur d'inférence pour l'évaluation de la règle de vulnérabilité à partir d'un ou plusieurs faits stockés dans la base de faits. De façon caractéristique, la règle de vulnérabilité est définie par une ou plusieurs conditions de présence d'une vulnérabilité donnée, une ou plusieurs actions à déclencher dans le cas où les conditions de présence de la vulnérabilité donnée sont remplies et le contexte 3o d'évaluation. Ainsi, il est possible de procéder à l'évaluation d'une règle en 2910204 3 rattachant le résultat de cette évaluation à son contexte, par exemple un système donné ou un service donné. Le résultat des actions à déclencher dans le cas où les conditions de présence de la vulnérabilité donnée sont remplies peut alors être 5 stocké dans le contexte spécifié. Il est ainsi possible de maintenir à jour, en continu, une liste des équipements du réseau qui présentent des vulnérabilités. Dans une variante de réalisation, les conditions de présence d'une vulnérabilité donnée sont définies par un opérateur de test, une clé à 1 o tester par ledit opérateur de test, une valeur à tester, et une portée de test. Ainsi, lorsqu'une clé change (un service ou un système par exemple), toutes les conditions de présence d'une vulnérabilité, aussi appelées hypothèses, demandant cette clé en entrée sont réévaluées. De préférence, la valeur à tester est un nom d'entité présente sur le 15 réseau de communication ou un texte libre. De préférence encore, les entités présentes sur le réseau de communication étant hiérarchiquement classées selon une relation d'ordre, l'opérateur de test est un opérateur de test relatif à cette relation d'ordre. 20 De la sorte, la lecture et l'écriture d'une règle de vulnérabilité s'en trouvent facilitées. Dans une autre variante, éventuellement en combinaison avec la précédente, la base de connaissances contient également des règles de traitement de messages en provenance du réseau de communication, et 25 l'inventaire des entités présentes sur le réseau de communication. Dans encore une autre variante, éventuellement en combinaison avec l'une quelconque ou les deux précédentes, les données dynamiques représentatives du réseau de communication contenues dans la base de faits comprennent des adresses réseau et/ou des noms ou numéros de ports et ou des noms ou numéros d'entités et/ou des vulnérabilités. L'invention se rapporte également, selon un deuxième aspect, à un 2910204 4 système de détection et de prévention d'intrusions dans un réseau de communication. De façon caractéristique, il comprend un système passif de surveillance tel que présenté ci-dessus. De préférence, le système de détection et de prévention 5 d'intrusions dans le réseau de communication comprend un module de détection automatique de protocole et d'analyse protocolaire, destiné notamment à extraire l'information utile pour le système passif de surveillance. L'acuité d'un tel système de détection et de prévention d'intrusions 10 dans un réseau de communication s'en trouve améliorée. Avec les services identifiés par le système de surveillance passive du réseau, le système de détection et de prévention d'intrusions dans ce réseau applique les signatures de détection d'attaque dans le contexte des services qu'il protège. 15 L'invention se rapporte également, selon un troisième aspect, à un procédé de détection et de prévention d'intrusions dans un réseau de communication mis en oeuvre par le système de détection et de prévention d'intrusions tel que présenté ci-dessus. L'invention se rapporte enfin, selon un quatrième aspect, à un 20 procédé de surveillance passive d'un réseau de communication dans lequel un message provenant du réseau de communication est analysé par un moteur d'inférence. De façon caractéristique en ce que l'analyse comprend une étape d'extraction au cours de laquelle la signature de l'entité et/ou de la version 25 d'entité concernée par le message, est extraite du message. L'analyse comprend également une étape de recherche de la signature dans un inventaire des entités. L'analyse comprend également une étape d'évaluation d'une règle de vulnérabilité à partir de l'entité obtenue à l'étape de recherche, la règle 30 de vulnérabilité étant définie par une ou plusieurs conditions de présence d'une vulnérabilité donnée, une ou plusieurs actions à déclencher dans le 2910204 5 cas où les conditions de présence de la vulnérabilité donnée sont remplies, et le contexte d'évaluation, l'étape d'évaluation consistant au moins en la vérification des conditions de présence de la vulnérabilité donnée. 5 L'analyse comprend encore une étape d'insertion de la vulnérabilité donnée dans une liste des vulnérabilités en fonction du résultat de l'étape d'évaluation. Dans une première variante, la vulnérabilité donnée est insérée dans la liste des vulnérabilités lorsque toutes les conditions de présence 1 o de la vulnérabilité donnée sont vérifiées. Dans une autre variante, éventuellement en combinaison avec la précédente, lorsque toutes les conditions de présence d'une vulnérabilité donnée sont vérifiées, les actions sont déclenchées dans le contexte d'évaluation de la règle de vulnérabilité. 15 Dans encore une autre variante, éventuellement en combinaison avec l'une quelconque ou les deux précédentes, le message provenant du réseau de communication et analysé par le moteur d'inférence contient une bannière, et l'étape d'extraction extrait la signature de l'entité concernée et/ou de la version d'entité concernée, de la bannière. 20 D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement et de manière complète à la lecture de la description ci-après des variantes préférées de réalisation, lesquelles sont données à titres d'exemples non limitatifs, et en référence aux figures annexées suivantes. 25 figure 1 : représente schématiquement une application du système de surveillance passive d'un réseau de communication de l'invention, - figure 2a à 2c : représentent schématiquement et respectivement trois exemples de règles de vulnérabilité. 30 La figure 1 représente schématiquement l'application du système de surveillance passive d'un réseau de communication de l'invention, au 2910204 6 domaine de la détection et prévention d'intrusion dans ce réseau de communication. Le réseau de communication peut par exemple être constitué d'un réseau de type Internet 1 et/ou d'un réseau interne 2. 5 Classiquement, un système de détection et de prévention d'intrusion dans le réseau de communication 1, 2 pourra comporter un pare-feu qui intègre un moyen de prévention des intrusions par détection des connexions, sur un point central et avant chaque branche du réseau. On pourra par exemple se référer au dispositif décrit dans le 1 o document FR 2 868 230. Ce système comprend un module 6 de détection automatique de protocole et d'analyse protocolaire. Ce module analyse le flux du réseau et envoie les messages à un système passif de surveillance du réseau de communication 1, 2 selon l'invention. 15 Les messages envoyés contiennent des champs protocolaires intéressants, notamment des en-têtes et/ou bannières. La détection automatique des protocoles réalisée par le module 7 est obtenue grâce à l'analyse protocolaire qui repose sur plusieurs modules de type plugins d'analyse de protocoles dédiés à un 2 o protocole donné (http, ftp, smtp, ...). Chacun de ces modules d'analyse de protocole peut effectuer les opérations suivantes : -reconnaissance automatique du protocole, analyse du flux pour vérification de la conformité au protocole (pour 25 générer d'éventuelles alarmes) et pour extraction des données protocolaires (pour envoi des messages au système passif de surveillance du réseau de communication 1, 2). Quand le module 6 de détection automatique de protocole et d'analyse protocolaire rencontre une nouvelle connexion, il interroge 30 chacun des modules d'analyse de protocole donné pour déterminer si l'un de ces modules reconnaît le protocole en question. Ainsi, tout le contrôle 2910204 7 et l'analyse du trafic d'une connexion donnée sont délégués à un module d'analyse de protocole donné. Le module 6 de détection automatique de protocole et d'analyse protocolaire extrait donc l'information utile pour le système passif de 5 surveillance. Les messages envoyés à ce système passif de surveillance peuvent contenir l'adresse réseau (adresse IP) et/ou le numéro de port de la machine impactée, un identifiant de message, et éventuellement des données d'extraction du protocole. Les messages émis par le module 6 de détection automatique de 10 protocole et d'analyse protocolaire sont reçus par le moteur d'inférence 5 du système passif de surveillance. Ce moteur d'inférence 5 gère les contextes des machines suivies dans une base de faits 3. En particulier, sont stockés les messages reçus préalablement épurés, les faits (par exemple port, service, système 15 d'exploitation) et les vulnérabilités. Ce moteur d'inférence 5 est le composant central du système passif de surveillance. Il réalise l'évaluation des hypothèses des règles stockées dans une base de connaissances 4. Ces règles sont des règles d'épuration des bannières de messages, de création de faits (port, service, 20 système d'exploitation) et de vulnérabilité. Ces règles de traitement des messages décrivent donc les actions à effectuer lors de la réception d'un message en provenance du module 6 de détection automatique de protocole et d'analyse protocolaire. Ces règles permettent de définir des actions de prétraitement des 25 messages avant leur stockage. Les règles de vulnérabilité stockées dans la base de connaissances 4 décrivent les conditions de présence d'une vulnérabilité. Le moteur d'inférence 5 est donc chargé du déclenchement d'actions spécifiques à effectuer en fonction du résultat de l'évaluation des 30 règles. Les résultats de l'évaluation sont intégrés dans les contextes dans 2910204 8 la base de faits 3. Par ailleurs, les résultats sont propagés par l'intermédiaire de l'évaluation d'autres règles impactées par les nouveaux faits. Le moteur d'inférence 5 se charge également de l'envoi des 5 résultats pour affichage sur des consoles d'administration, non représentées sur la figure 1. De préférence, les messages ont une durée limitée et expirent au bout d'un certain nombre de jours, par exemple sept jours. Si, au bout de ce nombre de jours, un message n'a pas été réémis, tous les faits 1 o présents dans la base de faits 3 découlant de ce message sont effacés. Les mises à jour des messages sont gérées de la façon suivante. Un fait peut avoir des valeurs multiples, par exemple service = Apache_1.3.31, Apache . Mais à un instant donné, seule la valeur plus précise est prise en compte, dans cet exemple service = 15 Apache_1.3.31 . Lorsque la valeur d'un fait vient à expiration, le fait prend alors la valeur la plus précise parmi les valeurs récentes. Le moteur d'inférence 5 se charge également de l'extraction des parties pertinentes des bannières envoyées par le module 6 de détection automatique de protocole et d'analyse protocolaire, encore appelée 20 épuration des bannières. Ainsi, il est possible de ne réévaluer les règles qui découlent des bannières que si des informations pertinentes concernant le service ont changé (par exemple la version). Par ailleurs, l'épuration des bannières permet de diminuer la taille des messages stockés. 25 A titre d'exemple, les bannières peuvent être épurées de la façon suivante. Exemple 1 : bannière en entrée : 220 www.comp.com SMTP Server (Microsoft Exchange Internet 30 Mail Service 5.5.2448.0) bannière épurée : 2910204 9 MS Exchange 5.5.2448.0 . Exemple 2 : bannière en entrée : 220-toto.com Microsoft SMTP MAIL ready at Thu, 7 Apr 2005 5 01:49:01 Version: 5.5.1877.197.19 bannière épurée : MS IIS 5.5.1877.197.19 . La base de faits 3 contient des données dynamiques représentatives du réseau de communication 1, 2 surveillé. Par exemple, 10 elle contient les numéros d'adresse réseau (adresse IP), les noms et/ou numéros de port, les entités (service et système) et les vulnérabilités. La base de connaissances 4 contient par ailleurs un système de stockage d'un inventaire des entités présentes sur le réseau de communication 1, 2. Ce système contient une arborescence hiérarchique 15 des entités présentes sur le réseau de communication 1, 2. Les figures 2a à 2c représentent schématiquement et respectivement trois exemples de règles de vulnérabilité. Les règles de vulnérabilité sont repérées par un identifiant 8. Elles sont définies par une ou plusieurs conditions 9 de présence d'une 20 vulnérabilité donnée, encore appelées hypothèses, et une ou plusieurs actions 10 à déclencher dans le cas où les hypothèses 9 sont vérifiées, et par le contexte d'évaluation 11. Ces actions 10 peuvent éventuellement être paramétrées. Les conditions 9 de présence d'une vulnérabilité donnée, ou 25 hypothèses 9, sont quant à elles définies par un opérateur de test 13, une clé à tester 14 par cet opérateur de test 13, une valeur à tester 15, et une portée de test 16, ou portée de l'hypothèse. La valeur à tester 15 peut être un nom d'entité présente sur le réseau de communication 1, 2, ou un texte libre. 30 Dans le cas où les entités présentes sur le réseau de communication 1, 2 sont hiérarchiquement classées, par exemple dans 2910204 10 une structure hiérarchique arborescente, selon une certaine relation d'ordre, l'opérateur de test 13 est un opérateur de test relatif à ladite relation d'ordre. Par exemple, si les entités sont classées dans la structure hiérarchique arborescente selon leur version, l'opérateur de test 13 pourra 5 être du type opérateur d'appartenance, de comparaison (version antérieure à/inférieure à ou postérieure à/supérieure à ). Ainsi, dans l'exemple de la figure 2a, le contexte 11, donc la portée du résultat, est noté S pour service. L'identifiant 8 est vuln_5477 O. Cette règle de vulnérabilité comprend deux hypothèses 9, chacune définie par Zo une clé à tester 14, un opérateur de test 13, et une valeur à tester 15, avec une certaine portée 16. La première hypothèse 9 teste si la version du service service est inférieure ou égale à Apache_2.0.43, alors que la deuxième hypothèse 9 teste si la version du système os est Microsoft Windows. 15 Autrement dit, dans cet exemple, l'action 10 vuln(5477,service) ne sera déclenchée que si la version du service surveillé est inférieure ou égale à Apache_2.0.43, et si la version du système est Microsoft Windows. Les figures 2b et 2c montrent deux autres exemples de règles de 20 vulnérabilité, avec une ou plusieurs hypothèses 9 dont la portée, ou contexte d'évaluation 11, se situe au niveau du système d'exploitation ou host H, ou du service S. Ainsi, dans le système de l'invention, la veille sécurité se limite à l'écriture de nouvelles règles de vulnérabilités, en respectant un 25 formalisme simple et très lisible. De la sorte, les messages provenant du réseau de communication 1, 2 sont analysés par le moteur d'inférence 5 de la figure 1. La signature de l'entité et/ou de la version d'entité concernée par un message est tout d'abord extraite de ce message, puis cette signature 30 est recherchée dans un inventaire ou une liste des entités. L'entité ainsi obtenue constitue un fait stocké dans la base de faits 2910204 11 3, et constitue une entrée pour l'évaluation d'une règle de vulnérabilité définie tel qu'expliqué ci-dessus. L'évaluation consiste au moins en la vérification des conditions 9 de présence de la vulnérabilité. 5 En fonction du résultat de l'évaluation, la vulnérabilité est insérée dans une liste 17, à l'attention de l'administrateur du réseau qui surveille celui-ci par exemple par l'intermédiaire d'une console d'administration. Plus précisément, une vulnérabilité est insérée dans la liste 17 des vulnérabilités lorsque toutes les conditions 9 de présence de cette lo vulnérabilité sont vérifiées. Comme il vient d'être expliqué, le moteur d'inférence 5 décrit relativement à la figure 1, se charge également de l'envoi des résultats pour affichage sur une console d'administration. Ces résultats peuvent être une liste 17 donnant une visibilité des 15 équipements réseau et présentant des vulnérabilités, un suivi des vulnérabilités client-serveur. Contrairement aux systèmes actifs de surveillance et systèmes à audit récurrent, dans le système de l'invention, le contrôle des vulnérabilités est continu. 20 Intégré dans un système de prévention et détection des intrusions dans le réseau, le système de surveillance passif de l'invention basé sur l'utilisation de règles de vulnérabilités telles que décrites plus haut, permet l'application des signatures de détection d'attaque dans le contexte des services protégés. A titre d'exemple, les alarmes d'exploitation de 25 vulnérabilité de type IlS seront uniquement générées si le système de prévention et de détection des intrusions protège un service de type IIS. II est rappelé que l'ensemble de la description ci-dessus est donné à titre d'exemple et n'est donc pas limitatif de l'invention. REVENDICATIONS 1. Système passif de surveillance d'un réseau de communication (1, 2), comprenant une base de faits (3) contenant une ou plusieurs données dynamiques représentant le suivi dudit réseau, une base de connaissances (4) contenant au moins une règle de vulnérabilité des entités présentes sur ledit réseau de communication (1, 2), et un moteur d'inférence (5) pour l'évaluation de ladite règle de vulnérabilité à partir d'un ou plusieurs faits stockés dans ladite base 1 o de faits (3), caractérisé en ce que ladite règle de vulnérabilité est définie par une ou plusieurs conditions 9 de présence d'une vulnérabilité donnée, une ou plusieurs actions 10 à déclencher dans le cas où lesdites conditions 9 de présence de ladite vulnérabilité donnée sont remplies et le contexte d'évaluation 11. 15 2. Système selon la revendication 1, caractérisé en ce que les conditions (9) de présence d'une vulnérabilité donnée sont définies par un opérateur de test (13), une clé à tester (14) par ledit opérateur de test (13), une valeur à tester (15), et une portée de test (16). 20 3. Système selon la revendication 2, caractérisé en ce que ladite valeur à tester (15) est un nom d'entité présente sur le réseau de communication (1, 2), ou un texte libre. 4. Système selon l'une quelconque des revendications 2 à 3, caractérisé en ce que, les entités présentes sur le réseau de 25 communication (1, 2) étant hiérarchiquement classées selon une relation d'ordre, l'opérateur de test est un opérateur de test relatif à ladite relation d'ordre. 5. Système selon l'une quelconque des revendications 1 à 4, caractérisé en ce que la base de connaissances (4) contient 30 également des règles de traitement de messages en provenance du réseau de communication (1, 2), et l'inventaire des entités 2910204 13 présentes sur ledit réseau de communication (1, 2). 6. Système selon l'une quelconque des revendications 1 à 5, caractérisé en ce que les données dynamiques représentatives du réseau de communication (1, 2) contenues dans la base de faits (3) 5 comprennent des adresses réseau et/ou des noms ou numéros de ports et ou des noms ou numéros d'entités et/ou des vulnérabilités. 7. Système de détection et de prévention d'intrusions dans un réseau de communication (1, 2), caractérisé en ce qu'il comprend un système passif de surveillance selon l'une quelconque des revendications 1 à 6. 8. Système selon la revendication 7, caractérisé en ce qu'il comprend un module (6) de détection automatique de protocole et d'analyse protocolaire, destiné notamment à extraire l'information utile pour le système passif de surveillance. 9. Procédé de détection et de prévention d'intrusions dans un réseau de communication (1, 2) mis en oeuvre par le système selon l'une quelconque des revendications 7 et 8. 10. Procédé de surveillance passive d'un réseau de communication (1, 2) dans lequel un message provenant du réseau de communication (1, 2) est analysé par un moteur d'inférence (5), caractérisé en ce que ladite analyse comprend : - une étape d'extraction au cours de laquelle la signature de l'entité et/ou de la version d'entité concernée par ledit message, est extraite dudit message, - une étape de recherche de ladite signature dans un inventaire des entités, - une étape d'évaluation d'une règle de vulnérabilité à partir de l'entité obtenue à ladite étape de recherche, ladite règle de vulnérabilité étant définie par une ou plusieurs conditions (9) de présence d'une vulnérabilité donnée, une ou plusieurs actions (10) à déclencher dans le cas où lesdites conditions 2910204 14 (9) de présence de ladite vulnérabilité donnée sont remplies, et le contexte d'évaluation (11), ladite étape d'évaluation consistant au moins en la vérification desdites conditions (9) de présence de ladite vulnérabilité donnée, 5 - une étape d'insertion de ladite vulnérabilité donnée dans une liste (17) des vulnérabilités en fonction du résultat de ladite étape d'évaluation. 11. Procédé selon la revendication 10, caractérisé en ce que la vulnérabilité donnée est insérée dans la liste (17) des vulnérabilités 10 lorsque toutes les conditions (9) de présence de ladite vulnérabilité donnée sont vérifiées. 12. Procédé selon l'une quelconque des revendications 10 et 11, caractérisé en ce que lorsque toutes les conditions (9) de présence d'une vulnérabilité donnée sont vérifiées, les actions (10) sont 15 déclenchées dans le contexte d'évaluation (11) de la règle de vulnérabilité. 13. Procédé selon l'une quelconque des revendications 10 à 12, dans lequel le message provenant du réseau de communication (1, 2) et analysé par le moteur d'inférence (5), contient une bannière, 20 caractérisé en ce que l'étape d'extraction extrait la signature de l'entité concernée et/ou de la version d'entité concernée, de ladite bannière.