FR 2838535 A1 20031017 FR 0204652 A 20020412 Procédé et dispositif d'optimisation d'un audit de sécurité dans un réseau de télécommunication, plate-forme et système correspondants. La présente invention se rapporte au domaine de la sécurité dans les réseaux de télécommunication. Plus précisément, l'invention concerne le test de vulnérabilité de dispositifs connectés à un ou plusieurs réseaux de télécommunication. Les systèmes connectés à un réseau de communication de type Internet sont régulièrement soumis à divers types d'attaques sous forme notamment d'intrusion ou de virus. Des listes d'attaques sont, par exemple, répertoriées sur des sites internet tel que le site www. cert.com (CERT (marque déposée) (de l'anglais Computer Emergency Response Team ) de l'université de Carnegie Mellon, ou Equipe de réponse aux urgences informatiques ). La consultation de ce site permet d'obtenir rapidement des informations sur les nouvelles vulnérabilités et des statistiques consolidées sur la découverte des vulnérabilités. Selon l'état de la technique, une première parade est basée sur le renforcement de la qualité des logiciels et des services opérés par les machines directement accessibles à tout internaute. Selon une autre technique connue, une seconde parade, couramment pratiquée et actuellement recommandée, repose sur l'utilisation de composants actifs pour protéger plusieurs machines dans un ensemble de réseaux. Il s'agit des routeurs filtrants ou des pare-feu (ou firewalls en anglais), ainsi que des systèmes de détection d'intrusion dans un réseau et des composants assurant une sécurité applicative comme la sécurisation de messagerie, les anti-virus... Si elles permettent une réduction certaine des risques liés à Internet, ces techniques présentent l'inconvénient de ne pas offrir une protection absolue. Au moins deux situations présentent encore un danger important : - la mauvaise configuration des composants actifs ou des services résidant sur les machines du réseau. Il peut s'agir, classiquement, de mots de passe trop faciles à deviner, de politique de sécurité externe trop permissive, d'options de configuration laissées à leurs valeurs par défaut alors qu'il aurait fallu les changer... ; et - l'apparition de vulnérabilités sur les systèmes, les services et les architectures en contact avec l'Internet ainsi que l'apparition de vulnérabilités sur les protocoles de transport des données, voire sur les chemins empruntés. Chaque jour, plusieurs nouvelles vulnérabilités sont trouvées dans le monde et certaines de ces vulnérabilités peuvent être exploitées à distance. Pour ces deux raisons, il est souhaitable de vérifier le plus souvent possible l'état du périmètre Internet ou de demander à un tiers de le faire. C'est le domaine des audits de sécurité Internet. Les premiers audits ont été manuels et consistaient essentiellement à vérifier les options de configuration, l'implantation correcte des logiciels dans le système d'exploitation et à dérouler des tests de vulnérabilité, avec ordre et méthode pour vérifier et/ou déduire la présence de failles. Il existe aujourd'hui un grand nombre de méthodes manuelles standardisées ou en cours de standardisation. (Par exemple, les méthodes du Club de la sécurité des systèmes d'information français (ou CLUSIF) disponible à l'adresse https://www.clusif.asso.fr/ ou la méthode décrite dans le manuel The open source security testing methodology manual (ou manuel de méthodologie de test de sécurité de source libre en français) disponible sur le site http ://www.ideahamster.org/osstmm-description.htm. Au cours du temps, certains tests ont été programmés puis regroupés sous forme d'outils intégrés. En parallèle, les méthodes d'audit ont été formalisées. Ces deux phénomènes ensemble ont rendu possible les audits de sécurité semiautomatisés. Pour l'essentiel, la semi-automatisation permet : - une diminution des coûts d'audit et de la durée d'intervention ; - une certaine répétabilité si la partie automatique est lancée dans des conditions comparables d'un audit sur l'autre ; et - une meilleure exhaustivité des tests lorsque les outils utilisés sont correctement mis à jour . Les audits semi-automatisés présentent de nombreux inconvénients notamment : - des actions manuelles résiduelles restent nécessaires ; - la maintenance et la mise à jour d'un grand nombre d'outils intégrés nécessitent un travail important ;. - les tests par des outils différents se recouvrent ; et - les outils qui ne sont pas conçus pour une utilisation conjointe se complètent mal. De tels outils sont par exemple : - le logiciel SATAN disponible sur le site www.fish.com/satan qui est un logiciel de détection de vulnérabilités à distance ; - le projet Nessus décrit sur le site www.nessus.org ; - les outils de détection de la société Internet Security Systems (marque déposée) illustrés sur le site www.iss.net. Ces outils présentent cependant l'inconvénient de nécessiter une intervention humaine, ce qui limite le nombre et la fréquence des audits de sécurité. Aussi, pour permettre une importante baisse des coûts rapportés au nombre d'audits et donc une augmentation de la fréquence des audits dans le temps, des systèmes entièrement automatisés sont proposés selon l'état de la technique. En outre, grâce à ces systèmes, un audit quasi simultané d'un très grand nombre de cibles est devenu possible, là où l'audit manuel nécessitait un échantillonnage statistique. L'intervention humaine étant totalement exclue du processus de détection, l'acuité des tests et le bien fondé de la méthodologie de test sont des paramètres cruciaux pour la qualité et la crédibilité du rapport d'audit. Le document Executive Brief: Managing Internet Vulnerability (ou Gérer la vulnérabilité d'Internet en français) diffusé par la société Sunbelt Software (marque déposée) (sur le site http://www.sunbelt- software.com/evaluation/545/web/documents/executive brief.pdf) indique un ensemble de critères qu'une offre d'audit Internet automatisé doit satisfaire, notamment : - une identification rapide de tous les équipements visibles sur le périmètre Internet ; - un audit non-intrusif et générant peu de charge réseau ; - une possibilité de lancer des audits à demande ou de façon planifiée ; - un bénéfice des mises à jour rapide de la base de vulnérabilité sans effort de la part du consommateur ; - des rapports concis et orientés vers l'action ; - une complétude de la base des vulnérabilités et des mesures correctives ; - une infrastructure sécurisée ; et - une grande fiabilité. Les paramètres indiqués dans cet article, sont aujourd'hui considérés comme une bonne description de l'état de l'art ; En particulier, un produit ne permettant pas de satisfaire tous ces critères aurait peu de chances de séduire les utilisateurs actuels. Néanmoins, les techniques connues de l'art antérieur présentent encore plusieurs inconvénients, notamment : - des vulnérabilités ne sont pas détectées, une vulnérabilité non détectée étant appelée faux négatif ; il s'agit des cas où une vulnérabilité est effectivement présente sur le système audité, mais n'est pas détectée par le processus d'audit. Une présence de trop de faux négatifs peut conduire à un sentiment de sécurité illusoire ; - des fausses alarmes peuvent être générées. Ce sont les faux positifs ; il s'agit des cas où une vulnérabilité n'est pas présente sur le système audité, mais pourtant le processus d'audit croit détecter une vulnérabilité ; trop de faux positifs conduit à un manque de confiance dans le processus d'audit et à une perte de temps pour corriger des vulnérabilités en fait inexistantes ; - des tests sont lancés inutilement ou abusivement. Chaque test consomme un peu des ressources des systèmes audités (comme la bande passante réseau et le temps machine). Le nombre de tests pouvant être de l'ordre de quelques milliers, chaque test lui-même pouvant être lancé plusieurs fois selon les méthodologies, le stress engendré sur les systèmes audités est parfois significatif. Ce phénomène est particulièrement critique sur les éléments de sécurité actifs en coupure, tels que les routeurs filtrants ou les pare-feu, qui par nature sont traversés par le flux réseau à destination de plusieurs machines protégées. L'invention selon ses différents aspects a notamment pour objectif de pallier ces inconvénients de l'art antérieur. Plus précisément, un premier objectif d'améliorer globalement l'acuité de systèmes de test (par exemple, par réduction des faux négatifs et/ou des faux positifs). Un autre objectif de l'invention est de réduire le stress provoqué par l'audit sur les équipements de sécurisation et les équipements terminaux, sans augmenter globalement la durée de l'audit (la vitesse d'audit étant un paramètre important, un tel audit pouvant cependant durer typiquement entre quelques minutes pour un audit léger d'un système isolé à deux heures pour l'audit lourd d'un réseau contenant des centaines de systèmes actifs). Dans ce but, l'invention propose un procédé d'optimisation d'un audit de sécurité dans un réseau de communication comprenant au moins un terminal, comprenant : - une étape de transmission d'une requête de lancement de tests de sécurité, d'une plate-forme d'audit de sécurité vers un des terminaux, dit terminal cible ; - une étape d'exécution des tests de sécurité par le terminal cible ; et une étape de transmission d'au moins un résultat des tests de sécurité par le terminal cible à la plate-forme d'audit de sécurité, remarquable en ce que les tests de sécurité sont sélectionnés en fonction d'une analyse de l'environnement de la machine cible. Selon une caractéristique particulière, le procédé est remarquable en ce qu'il comprend une phase préalable comprenant : - une étape d'analyse d'un environnement de la machine cible, dit périmètre audité ; - une étape de détermination d'un contexte de lancement d'un test sur la machine cible en fonction du résultat de l'analyse, le contexte de lancement d'un test comprenant des conditions de lancement du test ; et - une étape de sélection de tests destinés à la machine cible en fonction du contexte. Selon une caractéristique particulière, le procédé est remarquable en ce que l'étape de sélection inhibe parmi un ensemble de tests prédéfinis, chaque test pour lequel le contexte correspondant indique qu'il ne peut pas parvenir à la machine cible. Selon une caractéristique particulière, le procédé est remarquable en ce que l'étape de sélection inhibe parmi un ensemble de tests prédéfinis, chaque test pour lequel le contexte correspondant indique que le test produit nécessairement un résultat non significatif. Selon une caractéristique particulière, le procédé est remarquable en ce que l'étape de sélection inhibe parmi un ensemble de tests prédéfinis, chaque test pour lequel le contexte correspondant indique que le test rend la machine cible indisponible, l'indisponibilité de la machine cible étant supérieure à un niveau prédéterminé d'usage de la machine cible. Selon une caractéristique particulière, le procédé est remarquable en ce qu'il comprend, en outre, une étape de sélection du niveau prédéterminé. Ainsi, on peut définir un niveau d'indisponibilité en deçà duquel la machine cible n'est pas perturbée de manière significative par les tests de sécurité. De cette manière, l'audit n'est pas plus perturbateur qu'un trafic important mais normal pour la machine cible ainsi que pour services offerts par cette machine et/ou le service offert par la machine. En outre, l'utilisateur de la machine, notamment, peut sélectionner le niveau de perturbation admissible, par exemple en choisissant parmi une liste de niveaux proposés ou en indiquant lui-même un niveau d'indisponibilité. De cette façon, l'invention permet une adaptation de l'audit aux besoins de l'utilisateur. Selon une caractéristique particulière, le procédé est remarquable en ce que l'étape de sélection inhibe, parmi un ensemble de tests prédéfinis, chaque test pour lequel le contexte correspondant indique que le test produit nécessairement un résultat prédictible. Ainsi, la détermination d'un contexte permet avantageusement de limiter le nombre de faux-positifs et de faux-négatifs. Selon une caractéristique particulière, le procédé est remarquable en ce que le contexte comprend un ensemble d'au moins un couple comprenant lui-même une valeur générique de clé et une valeur d'instantiation associée à la valeur générique de clé. Une clé peut notamment être du type variable d'état, décrivant un élément d'un contexte associée à une valeur correspondant à une instantiation de la clé. Selon une caractéristique particulière, le procédé est remarquable en ce que la valeur d'instantiation associée à une valeur générique de clé fait partie du groupe de valeurs comprenant : la valeur précise de la clé pour la machine cible ; - des valeurs générales de la clé regroupant chacune une pluralité de valeurs précises de clé pour la machine cible ; et - des valeurs particulières regroupant chacune une partie d'au moins une des valeurs précises de la clé appartenant à une des valeurs générales. Ainsi la valeur n'est pas nécessairement instanciée avec une valeur précise mais peut également être instanciée avec une valeur générale ou particulière pouvant comprendre plusieurs valeurs précises. Cela permet notamment de simplifier la mise en #uvre du contexte. Par ailleurs, on note qu'une première valeur générale peut être considérée comme particulière vis-à-vis d'une seconde valeur générale qui correspondrait à un sur-ensemble de l'ensemble de valeurs précises associé à la première valeur générale. Ainsi, les valeurs peuvent être représentées sous forme d'arbres ou de graphes permettant une économie de ressources matérielles et notamment d'espace mémoire. Selon une caractéristique particulière, le procédé est remarquable en ce qu'il comprend une étape appartenant au groupe comprenant : - une affectation d'une valeur à au moins une des clés ; - une vérification de l'existence d'une valeur quelconque associée à une des clés dans un des couples ; et/ou - une vérification de l'existence d'une valeur déterminée, associée à une des clés dans un des couples. Ainsi, le procédé met en #uvre plusieurs opérations permettant de manipuler simplement et efficacement des contextes. Selon une caractéristique particulière, le procédé est remarquable en ce qu'il comprend une étape de vérification de la validité d'au moins une partie du contexte, la plate-forme requérant le lancement de tests correspondant une partie de contexte valide, sur la machine cible sans requérir le lancement de tests correspondant à une partie de contexte non valide. Ainsi, l'invention permet une économie de tests et donc de ressources à la fois sur la plate-forme d'audit, le réseau et la machine cible. Selon une caractéristique particulière, le procédé est remarquable en ce qu'il comprend, en outre, les étapes suivantes : - première étape de mémorisation des contextes ayant déjà permis au moins un lancement d'un premier test sur la machine cible ; seconde étape de mémorisation des résultats obtenus lors du ou des premiers tests ; - étape de comparaison d'au moins un contexte courant avec les contextes enregistrés lors de la première étape de mémorisation, lorsque le ou les premiers tests sont à nouveau sélectionnés ; et - production des résultats enregistrés lors de la seconde étape de mémorisation, de sorte que le ou les premiers tests ne sont pas lancés sur la machine cible. Ainsi, l'invention permet une économie de tests en simulant un test déjà effectué et dont le résultat est prédictible avec une forte probabilité de succès de la prédiction. Selon une caractéristique particulière, le procédé est remarquable en ce qu'il comprend, en outre, - une étape d'identification d'au moins une vulnérabilité pour la machine cible ; et - une étape d'association de chaque vulnérabilité parmi la ou les vulnérabilités et d'un statut indiquant la probabilité d'occurrence de la ou des vulnérabilités. Selon une caractéristique particulière, le procédé est remarquable en ce qu'il comprend une étape de résolution de conflit entre des résultats contradictoires fournis par la machine cible pour au moins une des vulnérabilités, prenant en compte le statut associé à chaque vulnérabilité pour laquelle des résultats contradictoires ont été fournis. Ainsi, la prise en compte d'un statut associé à chaque vulnérabilité permet une mise en #uvre relativement simple et efficace de l'invention. Selon une caractéristique particulière, le procédé est remarquable en ce que, lors de l'étape de résolution de conflit tient compte pour chaque vulnérabilité de sa probabilité d'occurrence, en hiérarchisant les probabilités d'occurrence associées aux vulnérabilités. Ainsi, en hiérarchisant les statuts, on facilite la mise en #uvre de la résolution des conflits. Selon une caractéristique particulière, le procédé est remarquable en ce que, lors de l'étape de résolution de conflit, pour chaque vulnérabilité, un statut indiquant que la vulnérabilité a une probabilité d'occurrence supérieure à 0,8 prévaut sur un autre statut associé à la vulnérabilité. Selon une caractéristique particulière, le procédé est remarquable en ce que, lors de l'étape de résolution de conflit, pour chaque vulnérabilité, un statut indiquant que la vulnérabilité est absente prévaut sur un autre statut associé à la vulnérabilité et indiquant que la vulnérabilité a une probabilité d'occurrence inférieure à 0,2. L'invention concerne également un dispositif d'optimisation d'audit de sécurité comprenant des moyens adaptés à la mise en #uvre d'un procédé d'optimisation tel que précédemment décrit. L'invention concerne aussi une plate-forme d'audit de sécurité destinée à un réseau de communication comprenant au moins un terminal, la plate-forme comprenant : - des moyens de transmission d'une requête de lancement de tests de sécurité de la plate-forme vers un des terminaux dit un terminal cible, le terminal cible comprenant des moyens d'exécution des tests de sécurité ; et - des moyens de réception de résultat des tests de sécurité transmis par le terminal cible, remarquable en ce que la plate-forme comprend, en outre, des moyens de sélection de tests destinés à la machine cible en fonction d'une analyse de l'environnement de la machine cible. L'invention concerne, en outre, un système comprenant au moins une plate-forme telle que décrite précédemment et au moins un terminal relié à la plate-forme par au moins une ligne de communication. Les avantages du système et du dispositif d'optimisation d'un audit de sécurité, ainsi que de la plate-forme sont les mêmes que ceux du procédé d'optimisation d'un audit de sécurité , ils ne sont pas détaillés plus amplement. D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : - la figure 1 présente une infrastructure de réseau audité par une plate- forme d'audit, conforme à l'invention selon un mode particulier de réalisation ; - la figure 2 illustre une machine de sélection mise en oeuvre dans la plate-forme de la figure 1 ; - la figure 3 décrit une machine scanner mise en oeuvre dans la plate- forme de la figure 1 ; - la figure 4 illustre un traitement effectué par la machine de sélection de la figure 2 ; - les figures 5 et 6 présentent une opération de sélection mise en oeuvre dans le traitement décrit en regard de la figure 4 ; - la figure 7 présente un processus de communication avec la machine scanner de la figure 3, ce processus étant mis en #uvre dans le traitement décrit en regard de la figure 4 ; - la figure 8 décrit un protocole de communication entre des machines illustrées en regard de la figure 1. Le principe général de l'invention repose sur la notion de contexte de lancement d'un test et de pertinence d'un test relativement à un contexte de lancement. Pour un rendement optimal de l'invention, chaque test de vulnérabilité nécessite la vérification d'un certain nombre de conditions. Selon l'état de la technique, un test lancé malgré l'existence d'une condition non vérifiée peut induire : - une impossibilité de lancer le test (l'impossibilité s'entend essentiellement au sens réseau, c'est-à-dire que le test n'arrivera pas jusqu'à la cible). - un résultat nécessairement non significatif ou erratique conduisant à des faux positifs ou faux négatifs ; - un danger pour le système qui subit le test (le danger porte le plus souvent sur la disponibilité du système, qui peut être ralenti ou arrêté à cause du test, et parfois sur le service rendu, qui peut être modifié à la suite du test) ; et/ouun lancement inutile lorsque l'absence d'une condition permet de prédire absolument le résultat du test. L'invention permet de disposer, d'une part, d'un moyen uniforme d'expression de l'ensemble des conditions nécessaires au lancement d'un test et, d'autre part, d'un moyen rapide de vérification de ces conditions. Selon l'invention, l'information déduite du résultat d'un test lancé dans des conditions optimales est mieux utilisable dans le cadre d'un audit de sécurité : 1) Si le test conclu à la présence d'une vulnérabilité, celle-ci est très probablement présente car le test a été lancé dans des conditions optimales. 2) Si le test conclut à l'absence d'une vulnérabilité, celle-ci est très probablement absente car - même dans les conditions optimales - il a été impossible de la détecter. Le deuxième point est important et conduit à la notion de réfutation de vulnérabilité, permettant d'éliminer de nombreux faux positifs. Plusieurs tests peuvent exister pour détecter une même vulnérabilité, chacun nécessitant un jeu de conditions différentes, ce qui se produit souvent dans le domaine des audits de sécurité entièrement automatisés. Lorsque les résultats ne coïncident pas, c'est-à-dire quand certains tests concluent à la présence et d'autres à l'absence d'une même vulnérabilité, il est possible de privilégier les réponses des tests ayant demandé les conditions les plus restrictives. C'est la phase de résolution de conflit, décrite ci-après. L'invention permet de codifier avec différentes valeurs de statut de vulnérabilité, la résolution de conflit de la manière suivante : I. Certains tests, nécessitant peu de conditions préalables, concluent à la présence d'une vulnérabilité, avec le statut DEDUITE. II. D'autres tests, nécessitant peu de conditions préalables, concluent à l'absence d'une vulnérabilité, avec le statut REFUTEE. III. D'autres tests, nécessitant beaucoup de conditions préalables, concluent à la présence d'une vulnérabilité, avec le statut PROUVEE. IV. D'autres tests, nécessitant beaucoup de conditions préalables, concluent à l'absence d'une vulnérabilité, avec le statut REFUTEE, i. e. le même statut que pour le cas II. Les conflits sont alors résolus par l'application de la règle de précédence : - le statut PROUVEE indique une vulnérabilité à très forte probabilité ; - le statut REFUTEE indique une absence de vulnérabilité, le statut PROUVEE l'emportant néanmoins sur le statut REFUTEE en cas de tests conduisant respectivement aux deux statuts pour une vulnérabilité donnée ; et le statut DEDUITE indique une vulnérabilité à faible probabilité, le statut PROUVEE ou REFUTEE l'emportant sur le statut DEDUITE en cas de tests donnant des statuts différents pour une vulnérabilité donnée. En d'autres termes : - toute vulnérabilité ayant le statut PROUVEE au moins une fois est réputée présente, même si d'autres tests ont fourni un statut REFUTEE; - toute vulnérabilité avec le statut REFUTEE au moins une fois et sans statut PROUVEE est réputée absente, même si d'autres tests lui ont conféré un statut DEDUITE ; et - toute vulnérabilité avec le statut DEDUITE et sans statut REFUTEE ou PROUVEE est réputée présente, avec une mention particulière dans le rapport indiquant son statut. On présente, en relation avec la figure 1, un mode de réalisation d'une infrastructure de réseau audité par une plate-forme d'audit, conforme à l'invention. L'infrastructure illustrée comprend notamment : - un réseau 11de type Internet ; - une plate forme d'audit 10 ; - un terminal 13 ; - un périmètre audité 12. La plate-forme d'audit 10 effectue les traitements pour la réalisation de l'audit du périmètre audité 12. Elle lance, notamment, les tests du périmètre audité 12 et reçoit les résultats de tests via le réseau 11. Le bénéficiaire de l'audit a un accès au rapport d'audit effectué par la plate-forme 10 via le terminal 13 qui communique avec la plate-forme 10 à travers le réseau 11. Une ligne de communication directe 14 relie le terminal 13 au périmètre audité 12. Cette ligne 14 permet notamment la transmission d'actions correctives au sein du périmètre audité 12. La plate-forme d'audit 10 comprend elle-même : - une machine scanner 101 chargée notamment de l'analyse du périmètre audité 12 ; - une machine de sélection 102 permettant de sélectionner des tests pertinents. Ces deux machines 101 et 102 sont reliées afin que des processus mis en #uvre sur chacune de ces machines puissent échanger des informations et se synchroniser. Le terminal 13 est, par exemple, de type micro-ordinateur possédant une interface homme-machine et de communication avec le réseau 11 et le périmètre audité 12. Le périmètre audité 12 comprend : - un réseau audité 123 ; - une sécurité active 122 (pare-feu ou firewall en anglais) ; et - un accès 121 au réseau 11(routeur). Les données en provenance du réseau 11et destinées au réseau audité 123 transitent d'abord par l'accès 121, puis sont filtrées par la sécurité active 122 avant de parvenir au réseau audité 123. Le réseau audité 123 comprend plusieurs terminaux 125,126 dont un terminal cible 124. La figure 2 illustre schématiquement la machine de sélection 102 mise en oeuvre dans la plate-forme de la figure 1. la machine de sélection 102 comprend reliés entre eux par un bus d'adresses et de données 24 : - une unité de traitement 21 qui comprend elle-même deux processeurs 211 et 212 ; - une mémoire centrale 22 ; - une mémoire de masse 23 ; - une interface réseau 25 permettant de communiquer avec le réseau 11 ; et - une interface 26 permettant de communiquer avec des périphériques et notamment la machine scanner 101. La mémoire de masse 23 conserve dans des registres qui par commodité possèdent les mêmes noms que les données qu'ils conservent : - un programme de fonctionnement des processeurs 211et 212 destiné à la sélection des tests, dans un registre prog sélection 231 sous forme d'un fichier du code exécutable du système de sélection , - des règles 232 du système de sélection ; - un programme de fonctionnement des processeurs 211 et 212 destiné à la commande de scanner, dans un registre prog commande scanner 233 sous forme d'un fichier du code exécutable du système de commande de la machine scanner 101 , - des fichiers de configuration de sélection dans un registre config. sélection 234 ; et - des fichiers de stockage des résultats formatés dans un registre résultats 235. La mémoire centrale 22 conserve des données, des variables et des résultats intermédiaires de traitement et comprend notamment : - une copie 221 du programme prog sélection 231 , - une copie 222 des règles 232 du système de sélection ; - une copie 223 du programme prog commande scanner 233 , et - des fichiers de configuration de sélection dans un registre config. sélection 234 ; et - une zone de stockage des contextes 224. Chacun des éléments illustrés en figure 2 est bien connu de l'homme du métier. Ces éléments communs ne sont pas décrits ici. On observe en outre que le mot registre utilisé dans toute la description désigne dans chacune des mémoires mentionnées, aussi bien une zone de mémoire de faible capacité (quelques données binaires) qu'une zone mémoire de grande capacité (permettant de stocker un programme entier ou l'intégralité d'une séquence de données de transactions). Les algorithmes mettant en #uvre les étapes des procédés décrits ci-après notamment en regard des figures 4 à 7 sont stockés dans mémoire de masse 23 associé à la machine de sélection 102 mettant en #uvre ces étapes. A la mise sous tension, l'unité de traitement 21 de la machine de sélection 102 charge et exécute les instructions de ces algorithmes. Cette structure ne sera donc pas décrite plus amplement. La figure 2 illustre schématiquement la machine scanner 101 mise en oeuvre dans la plate-forme de la figure 1. La machine scanner 101 possède une structure tout à fait similaire à la machine de sélection 102, avec un contenu de mémoire de masse et de mémoire centrale approprié à l'analyse de périmètres audités. La machine scanner 101 comprend reliés entre eux par un bus d'adresses et de données 34 : - une unité de traitement 31qui comprend elle-même un processeur 311 ; - une mémoire centrale 32 ; - une mémoire de masse 33 ; - une interface réseau 35 permettant de communiquer avec le réseau 11 ; et - une interface 36 permettant de communiquer avec des périphériques et notamment la machine de sélection 101. La mémoire de masse 33 conserve dans des registres qui par commodité possèdent les mêmes noms que les données qu'ils conservent : - un programme de fonctionnement du processeur 311 destiné notamment, à l'analyse du périmètre audité 12, dans un registre prog processus commande scanner 331 sous forme d'un fichier du code exécutable du processus de commande des processus de scanner, - un programme de fonctionnement du processeur 311 destiné au processus de scanner, dans un registre prog processus scanner 332 sous forme d'un fichier du code exécutable du processus scanner , et - des fichiers de configuration du scanner dans un registre config. scanner 333. La mémoire centrale 33 conserve des données, des variables et des résultats intermédiaires de traitement et comprend notamment : - une copie 321 du programme prog processus commande scanner 331 , et - une copie 322 à 324 du programme prog processus scanner 332 par audit demandé. Chacun des éléments illustrés en figure 3 est bien connu de l'homme du métier. Ces éléments communs ne sont pas décrits ici. Les algorithmes mis en #uvre par la machine scanner 101 sont stockés dans mémoire de masse 33 associé à la machine scanner 101. A la mise sous tension ou lorsqu'un audit est demandé, l'unité de traitement 31 de la machine scanner 101 charge et exécute les instructions de ces algorithmes. La figure 4 illustre un traitement effectué par la machine de sélection 102 Le traitement débute par une étape 40, au cours de laquelle, pour chaque audit demandé, l'unité de traitement 21 créée trois processus légers ou threads en anglais nécessaires à la suite du traitement. Ainsi, pour l'audit du paramètre 12, l'unité de traitement créée trois processus en parallèle : - un premier processus 41 destiné à la sélection de tests exécuté dans le paramètre 12 et illustré en regard des figures 5 et 6 ; - un deuxième processus 42 destiné à la communication avec la machine scanner 101 et illustré en regard de la figure 7 ; -un troisième processus 43 d'attente et de stockage des résultats de tests. Le troisième processus 43 débute par une étape 431, au cours de laquelle, l'unité de traitement 101 se met en attente de résultats formatés avec lancement d'une temporisation d'attente (par exemple d'une durée égale à 2 heures) : le délai d'attente est dépassé, les résultats sont considérés comme nuls. Une alarme ou une indication appropriées dans les journaux (ou logs en anglais) du processus peuvent signaler un problème lors de l'audit. Lorsque les résultats sont obtenus avant expiration du délai l'exécution ou lorsque la temporisation a expiré, au cours d'une étape 432, les résultats formatés sont stockés dans la mémoire de masse 23 sur la machine de sélection 102. Puis, au cours d'une étape 433, le processus 43 s'achève pour l'audit correspondant. La figure 5 illustre le premier processus 41. Le processus 41 débute par une étape 410, au cours de laquelle, l'unité de traitement 101 lance le processus de sélection 41 pour l'audit considéré. La zone de stockage 224 des contextes est initialisée avec un seul contexte, contenant la liste des adresses IP (de l'anglais Internet Protocole ou adresses internet) à auditer. Puis, au cours d'une étape, 411, les règles contenues dans le fichier des règles du système de sélection 232 sont toutes chargées en mémoire centrale 22 (fichier 222) pour un accès et des traitements plus rapides. Ensuite, au cours d'une étape 412 illustrée plus en détails en regard de la figure 6, des tests sont sélectionnés et des règles pertinentes relativement aux contextes courants sont retenues. Les tests préconisés par ces règles sont réputés valides (les tests sont pertinents relativement à un contexte) et sont mémorisés. Puis, au cours d'un test 413, l'unité de traitement 12 détermine si au moins un test valide a été mémorisé lors de l'étape 412. Ce test est atteint depuis une étape 4122 (illustrée en regard de la figure 6) lorsque tous les tests ont été traités. Cette étape utilise également l'ensemble des informations mémorisées à une étape 4127 (illustrée également en regard de la figure 6). Dans l'affirmative, au cours d'une étape 414, une ou plusieurs demandes de lancement des tests mémorisés sont effectuées par le processus 41 auprès du processus 42 de communication avec le scanner. A chaque demande de lancement effectuée au cours de l'étape 414 est associée une attente avec délai et, au cours d'une étape 415, le processus 41 lance une temporisation et se met en attente de résultats en provenance du processus 42 : si les résultats correspondant à une demande lancée lors de l'étape 414 sont obtenus, les contextes 224 sont mis à jour en concordance ; - si le délai d'attente associé à une demande est dépassé, tous les résultats correspondants à cette demande sont considérés comme négatifs, et les contextes 224 sont mis à jour en concordance . La valeur du délai d'attente est fonction de la durée maximale des tests, de la vitesse de traitement de la machine de sélection 102, de la vitesse de traitement de la machine scanner 101, du nombre de processus parallèles dans ces machines au moment de l'audit, de la vitesse des accès au réseau 11 et du trafic moyen au moment de l'audit et de la vitesse de réponse des machines cibles 124. La valeur de ce délai sera, par exemple, prise égale à une heure. Après l'exécution de l'étape 415 pour toutes les demandes effectuées lors de l'étape 414, l'étape 412 est réitérée. Si le résultat du test 413 est négatif, le processus 41 déduit que tous les tests pertinents ont été lancés et qu'aucun autre test n'est pertinent, et au cours d'une étape, les contextes sont soumis à la règle de précédence permettant la résolution des conflits, précédemment décrite. Ainsi, à l'issue de ce traitement, tous les contextes en conflit avec un autre contexte ayant une plus forte précédence sont retirés de la zone 224 de stockage des contextes. Ensuite, lors d'une étape 417, les résultats sont formatés, c'est-à-dire que les contextes sont interprétés relativement à un format de sortie défini (par exemple en langage de type XML ou eXtensible Markup Language ). Le processus 41 s'achève par l'étape 417. La figure 6 décrit l'étape 412 du premier processus 41. L'étape 412 débute par une opération 4120, qui est déclenchée : - par l'étape 411, auquel cas un seul contexte contenant la liste des adresses à auditer est stocké dans le registre 224 ; - par l'étape 415, auquel cas la zone 224 mémoire de stockage des contextes contient tous les contextes générés par des résultats de test précédents, plus le contexte initial contenant la liste des adresses à auditer. Ensuite, au cours d'une étape 4121, le processus 41 collecte tous les tests possibles a priori, leur affecte un numéro pour traitement ultérieur et les marque tous comme non-traité Puis, au cours d'un test 4122, le processus 41 détermine si des tests sont à traiter. Dans la négative, il ne reste plus de test à traiter et l'étape 412 s'achève. Dans l'affirmative, il reste un ou plusieurs tests à traiter et le test non traité de plus petit numéro est choisi puis marqué traité . Puis, au cours d'une étape 4123, le processus 41 recherche les conditions de lancement : pour chaque test, il existe un ensemble de conditions de lancements, notamment, un test ne sera pas lancé si : - il ne peut parvenir à la cible, dans le contexte courant (c'est-à-dire dans les conditions de lancements sélectionnées à l'étape 4123) ; - il produit nécessairement à un résultat nécessairement non significatif ou erratique conduisant à des faux positifs ou faux négatifs, dans le contexte courant ; - il constitue un danger pour le système qui subit le test (le danger porte le plus souvent sur la disponibilité du système, qui peut être ralenti ou arrêté à cause du test, et parfois sur le service rendu, qui peut être modifié à la suite du test) , dans le contexte courant ; et/ou - le résultat du test est prédictible de manière certaine, dans le contexte courant. La liste des conditions associées au test concerné est extraite, et chaque condition est numérotée de façon unique pour traitement dans les étapes ultérieures. Toutes les conditions sont marquées comme non-traitée . Puis, au cours d'un test 4124, le processus 41 vérifie s'il reste au moins une condition à traiter. Dans la négative, le test 4122 est réitéré. Dans l'affirmative, il reste une ou plusieurs conditions à traiter et, au cours du test 4124, la condition non-traitée de plus petit numéro est choisie et elle est marquée traitée . La condition choisie comprend un nombre arbitraire de couples (clé, valeur), la partie valeur pouvant être instanciée ou non, conformément à la description donnée ci-après. Chaque couple clé valeur est numéroté pour traitement ultérieur et est marqué comme non-traité . Une clé est une variable d'état, décrivant un élément d'un contexte. Les opérations possibles sur une clé sont : - l'affectation d'une valeur ; - la vérification de l'existence d'une valeur quelconque ; - la vérification de l'existence d'une valeur précise ; et/ou - la vérification de l'existence d'une valeur généralisant ou particularisant une valeur précise (les notions de généralisation et particularisation sont abordées au prochain paragraphe). Un ensemble de couples (clé, valeur), avec des valeurs définies, forme un CONTEXTE. L'exemple suivant montre deux contextes simples : - Contextel : (adresse, '10.0.0.1'), (port, '80'), (ipproto, 'tcp'), (protocol, 'http') - Contexte2 : (adresse, '10.0.0.1'), (ipproto, 'tcp') La signification du couple (ipproto, 'tcp') dans le contextel n'est pas la même que dans le contexte2 (La clé ipproto signifiant protocole internet utilisé ou utilisable ) : - dans le contextel, l'indication est que le port 80 ouvert sur la machine 10.0.0.1est ouvert selon un protocole TCP ou Transmission Control Protocol ( et comprend le protocole HTTP ou Hyper Text Transfer Protocol ) ; - dans le contexte2, l'indication est seulement que la machine 10.0.0.1 est capable d'accepter une connexion TCP (mais le port n'est pas précisé). Au cours d'un audit réel, la taille d'un contexte peut atteindre plusieurs dizaines de couples (clé, valeur). Selon une variante de la notion de couple(clé,valeur), on étend les possibilités d'affectation possible pour le champ valeur. Ainsi, pour toute valeur mentionnée dans un couple (clé, valeur) au sein d'un contexte, on peut généraliser ou particulariser la valeur en lui affectant : - un objet généralisateur d'au moins un second objet, l'objet généralisateur correspondant à une famille d'objets englobant, sans ambiguïté le ou les seconds objets ; ou - un objet particularisateur d'un second objet, l'objet particularisateur faisant partie, sans ambiguïté, du second objet. Ainsi, si un objet 01 est un généralisateur d'un objet 02,02 est un particularisateur de l'objet 01 et 02 fait partie, sans ambiguïté, de l'objet 01. On utilise cette notion, par exemple, pour les valeurs décrivant : - des systèmes d'exploitation (tels que, par exemple, Windows (Marque déposée), UNIX (marque déposée), MacOS (marque déposée)) ; - des logiciels offrant des services Internet (par exemple, Apache (marque déposée), IIS (marque déposée), Bind (marque déposée)) ; et/ou - des architectures (par exemple, de type Alpha (marque déposée), Sparc (marque déposée), Intel (marque déposée)). Les informations de généralisation et de particularisation sont stockées sous forme de Graphe Orienté Sans Circuit (GOSC). Un mode de stockage possible pour ce graphe est la liste des couples père-fils (ou ( généralisateur - particularisateur ) orientés, selon par exemple : - graphe (O1, 02) ; - graphe (03, 04) ; - graphe (05, 06) ; Ainsi, dans cet exemple, les objets 01, 02 et 05 sont respectivement généralisateurs des objets 02,04 et 05. A titre illustratif, l'objet Linux qui représente un système d'exploitation est un généralisateur des objets RedHat et SuSE (qui concernent des fournisseurs différents de Linux) et qui sont eux-mêmes des généralisateurs respectivement des versions RedHat 4. 2 et RedHat 7. 2 d'une part et SuSE 5. 3 et SuSE 6. 4 d'autre part. Selon cet exemple, les couples père-fils sont donc les suivants : (Linux, RedHat), (Linux, SuSE), (RedHat, RedHat 4. 2), (RedHat, RedHat 7.2), (SuSE, SuSE 5. 3) et (SuSE, SuSE 6. 4). Selon un mode de réalisation de la variante de la notion de couple(clé,valeur), la clôture transitive de la relation graphe n'est pas stockée en mémoire. Elle est calculée dès que nécessaire par l'appel d'une routine de parcours de graphe. Selon les différents modes de réalisation de l'invention, La possibilité de lancer un test de vulnérabilité est décrite par des CONDITIONS sur les contextes connus au moment où le système sélectionne les tests. Ces conditions sont de trois types : 1. Indifférence vis-à-vis d'une clé : présence ou l'absence de la clé dans le contexte n'influe pas sur le lancement du test. 2. Existence d'une clé avec valeur libre : la clé doit être présente dans le contexte ET doit avoir une valeur (non précisée). Sans la validité de ces deux prémisses, le lancement du test n'est pas pertinent. 3. Existence d'une clé avec une valeur imposée : la clé doit être présente dans le contexte ET au moins une de ses occurrences doit avoir la valeur demandée. Sans la validité de ces deux prémisses, le lancement du test n'est pas pertinent. Après un résultat positif du test 4124, au cours d'une étape 4125 de recherche des contextes disponibles, le processus 41 sélectionne tous les contextes connus au moment de l'entrée à cette étape 4125 et les numérote pour un traitement ultérieur relativement à la condition sélectionnée lors de l'étape 4124. Ensuite, tous les contextes sont marqués comme non-traité , et, au cours d'un test 4126, le processus détermine s'il reste au moins un contexte non traité. S'il reste au moins un contexte non traité, le contexte non-traité de plus petit numéro est choisi, puis marqué traité , et, au cours d'une étape 4128, le processus 41 recherche des couples (clé, valeur) dans la condition choisie au cours de l'étape 4124. Puis, au cours d'un test 4129, le processus 41 détermine s'il reste un couple (clé, valeur) à traiter pour le contexte considéré lors de l'étape 4126. Dans l'affirmative, il reste un ou plusieurs couples (clé, valeur) à traiter, le couple (clé, valeur) non-traité de plus petit numéro est choisi et marqué traité , puis, au cours d'un test 41210, le processus détermine si le couple choisi est valide dans le contexte considéré à l'issue de l'étape 4126. Plusieurs cas sont à considérer à cette étape 41210 : i. Soit, d'une part le couple (clé, valeur) choisi à l'étape 4129 contient une valeur instanciée et d'autre part le contexte choisi à l'étape4126 contient le même couple (clé, valeur). Alors le couple (clé, valeur) est réputé valide dans le contexte. ii. Soit, d'une part le couple (clé, valeur) choisi à l'étape 4129 contient une valeur instanciée et d'autre part le contexte choisi à l'étape 4126 ne contient pas le même couple (clé, valeur). Alors le couple (clé, valeur) est réputé non valide dans le contexte. iii. Soit, d'une part le couple (clé, valeur) choisi à l'étape 4129 contient une valeur non-instanciée et d'autre part le contexte choisi à l'étape 4126 contient un couple (clé, valeur2) avec la même clé et une valeur déterminée, valeur2. Alors le couple (clé, valeur) est remplacé par le couple (clé, valeur2) et est réputé valide dans le contexte. iv. Soit, d'une part le couple (clé, valeur) choisi à l'étape 4129 contient une valeur non-instanciée et d'autre part le contexte choisi à l'étape 4126 ne contient aucun couple (clé, valeur2) avec la même clé. Alors le couple (clé, valeur) est réputé non valide dans le contexte. En résumé, un test est valide lorsque toutes les conditions du test sont rendues valides par un même contexte. Dans tous les autres cas, le test n'est pas valide. On note qu'un même test peut-être valide plusieurs fois, notamment, quand il existe plusieurs contextes qui valident chacun l'ensemble des conditions du test. Par ailleurs, pour chacun des tests valides, tous les couples (clé, valeur) ont des valeurs instanciées. Soit elles l'étaient dès le départ, dans l'expression des conditions du test, soit elles ont été instanciées à l'étape 41210 selon le cas iii présenté. Si, selon les cas illustrés précédemment, le couple (clé,valeur) ou (clé, valeur2) est réputé valide, l'étape 4129 est réitérée. Sinon, le test 4126 est réitéré. Ainsi, tous les éléments non valides sont éliminés au plus tôt par l'algorithme, ce qui fait gagner du temps. Si le résultat du test 4126 ou du test 4128 est négatif, au cours d'une étape 4127 de mémorisation de test, de la condition et du contexte qui la valide, le processus 41 mémorise la condition choisie à l'étape 4124 et le contexte choisi à l'étape 4126. Puis, l'étape 4124 est réitérée. Un test éligible à une étape de la sélection peut rester éligible dans la suite du processus, si aucun conflit ne réfute les contextes autorisant le lancement du test. Dans ce cas, fréquent en pratique, il n'est pas utile de lancer le test à nouveau : les contextes n'ayant pas changé, il est très probable que les résultats du test resteront stables d'un lancement sur l'autre. Pour éviter de lancer ces tests, selon une variante du mode de réalisation, on met en #uvre les étapes suivantes : - mémorisation des contextes ayant déjà permis le lancement. - mémorisation de l'identifiant du test. - mémorisation des résultats obtenus lors du premier lancement. Lorsqu'un tel test est sélectionné à nouveau, il y a comparaison des contextes courants de sélection avec les contextes précédemment mémorisés. En cas d'égalité, les résultats mémorisés sont restitués à suite de la chaîne de traitement, exactement comme si le test avait été lancé une deuxième fois. Selon cette variante du mode de réalisation, le reste du processus n'a pas besoin de faire la différence entre le lancement effectif d'un test, et le lancement simulé de ce même test en l'absence d'évolution des contextes ayant autorisé le lancement. Ainsi, selon cette variante, le lancement d'un test est toujours effectif la première fois que le test est sélectionné et est toujours simulé les fois suivantes. La figure 7 illustre le deuxième processus 42 de communication avec la machine scanner 101. Le processus 42 commence par une étape 421 de lancement du processus 42 qui est en charge de prendre en compte les demandes de lancement émises à l'étape 414, de les sérialiser et de renvoyer les résultats attendus à l'étape 415 Puis, au cours d'une étape 422, le processus 42 se met en attente des demandes de lancement émises à l'étape 414. Cette étape 422 est protégée par une temporisation (par exemple de l'ordre d'une heure). Lorsque le délai d'attente des demandes est dépassé, l'exécution du processus 42 est arrêtée. Une alarme ou une indication appropriée dans les journaux (ou logs en anglais) du processus 42 peuvent signaler un problème lors de l'audit. Puis, après réception des demandes de lancement, au cours d'une étape 423 de lancement de test, le processus 42 génère un numéro de demande (correspondant à l'une des demandes reçues et non traitées), unique au cours d'un audit et transmet la demande de lancement numérotée à la machine scanner 101. Ensuite, au cours d'un test 424, le processus 42 détermine s'il reste au moins un test à effectuer. Dans l'affirmative, l'étape 423 est réitérée. L'ensemble des étapes 423 et 424 permet le lancement rapide des tests, qui s'exécutent par la suite en parallèle sur la machine scanner. S'il ne reste plus de test à effectuer, au cours d'une étape 425 d'attente de résultats, les résultats de chacun des tests précédemment lancés est collecté. La durée effective de chaque test peut varier en fonction de nombreux paramètres : nature du test, charge du réseau 11et des machines, nombre de processus en cours d'exécution. Il est donc probable que les résultats des tests n'arrivent pas dans le même ordre que celui des demandes de lancement de test correspondant. Le numéro de demande attribué à l'étape 414 est donc utilisé pour garantir un bon réordonnancement des résultats. La durée de l'attente mise en #uvre lors de l'étape 425 est limitée pour chaque test par une temporisation propre au test concerné et égale, par exemple, à 5 minutes. Le réglage précis du délai doit prendre en compte la temporisation choisie à l'étape 415 et le nombre maximal de tests lancés en parallèle (qui est, par exemple, fixé à 5). Afin d'améliorer la robustesse du système, une temporisation globale (égale par exemple à une heure) est mise en oeuvre Après réception d'un résultat ou lorsque la temporisation de l'étape 425 ne s'est pas écoulée, au cours d'un test 426, le processus 42 détermine si tous les résultats attendus sont reçus ou si les temporisations propres à chaque test ou globale ont expiré. Si des résultats sont encore attendus (temporisation propre à au moins un test non écoulée) et que la temporisation globale de l'étape 425 ne s'est pas écoulée, l'étape 425 est réitérée (sans réinitialisation de la temporisation globale). Sinon, au cours d'une étape 427, le processus 42 transmet au processus de sélection 41, les résultats reconstitués grâce au numéro d'ordre attribué et traités dans les étapes 425 et 426. On note que le délai d'attente fixé pour l'étape 415 prend en compte le délai d'attente maximal dans la boucle formée par les étapes 425 et 426. Les résultats ayant dépassé le délai d'attente de l'étape 425 sont renvoyés comme des résultats négatifs. En effet, le test ayant été lancé dans des conditions optimales, il est très peu probable qu'il échoue alors que la vulnérabilité est présente. Dans ce cadre, conclure à l'absence d'une vulnérabilité est très pertinent, et le nombre de faux négatifs s'en trouve réduit. La figure 8 décrit un protocole de communication entre la machine de sélection 102, la machine scanner 101 et la cible 124. La figure 8 illustre notamment la succession temporelle des actions principales effectuées par les dispositifs 101,102 et 124 ainsi que des échanges correspondants. Après une sélection de tests effectuée lors d'une étape 412 précédemment décrite, la machine de sélection 101 transmet à la machine scanner 101 une demande 414 de plusieurs lancements. Puis, au cours d'une étape 803, la machine scanner 101 traite cette demande et, au cours d'une étape 804, transmet une demande de lancement à la machine cible 124 pour chaque test devant être lancé. Les demandes sont envoyées successivement avec une identification de chaque test permettant d'identifier la correspondance entre un test et son résultat. Simultanément, la machine scanner lance une temporisation 805 égale, par exemple, à une heure et se met en attente des résultats. Puis, des tests 806,807, 810,813 et 814 sont successivement mis en #uvre sur la machine cible 124. Lorsqu'un test a fourni un résultat, la machine cible 124 le transmet à la machine scanner 101. Un test peut fournir plusieurs résultats ou aucun suivant sa nature et sa mise en #uvre sur la machine cible 124. Ainsi, à titre illustratif, le test 807 fourni d'abord deux résultats que la machine cible 124 transmet à la machine scanner successivement à la machine scanner lors de deux étapes 808 et 809. Puis, la machine cible transmet successivement à la machine scanner 101 : - un résultat 811 issu du test 806 ; - un résultat 816 fourni par letest 810 ; et un résultat 815 issu du test 814. A l'écoulement de la temporisation 805 ou avant si tous les résultats attendus sont reçus, lors d'une étape 817 la machine scanner 101 transmet les résultats bruts avec l'identification du test effectué et de la machine cible 124 à la machine de sélection 102. Lors de l'étape 415 précédemment décrite, la machine de sélection 102 enrichit le contexte de l'audit associé à la machine cible 124 et/ou au réseau audité 123 et/ou au périmètre audité 12. Puis, lors d'une nouvelle étape 412 précédemment décrite, la machine 102 sélectionne les tests valides en fonction du contexte enrichi. Ensuite, une nouvelle phase de tests valides est mise en #uvre similaire à ce qui a été précédemment illustré. Cette phase comprend notamment : - une demande de lancements de tests valides 414 par la machine de sélection 102 à la machine scanner 101 ; - un traitement 821 de la demande similaire à 'l'étape 813 , effectué par la machine scanner 101; - des demandes 822 de lancements de tests valides transmis par la machine scanner 101 à la machine cible 124 avec lancement d'une temporisation 828 ; - des tests valides 823 et 825 mis en #uvre successivement par la machine cible 124 qui transmet les résultats à la machine scanner 121 ; - lors d'une étape 827, la machine scanner 101 ayant reçu dans cet exemple tous les résultats attendus avant l'écoulement de la temporisation 828 transmet les résultats à la machine de sélection 102 qui enrichit le contexte correspondant lors d'une étape 415 et sélectionne des nouveaux tests valides lors d'une étape 412. Ainsi, le contexte s'enrichit au fur et à mesure que des résultats parviennent à la machine de sélection. Les tests sont donc de plus en plus adéquats et les résultats de plus en plus pertinents, les avantages de l'invention apparaissant clairement ici. Bien entendu, l'invention n'est pas limitée aux exemples de réalisation mentionnés ci-dessus. En particulier, l'homme du métier pourra apporter toute variante dans la structure de la plate-forme d'audit. Ainsi, une variante consiste en l'utilisation de plusieurs machines scanner, pour une seule machine de sélection. Le choix de plusieurs machines scanner permet, notamment : - d'étaler la charge générée par le lancement des tests, en particulier pour les audits de grandes plages d'adresses IP (par exemple, de l'ordre que quelques centaines) ; et/ou - d'assurer une meilleure robustesse en cas de panne ou de défaillance logicielle d'une des machines scanner. L'usage de plusieurs machines scanner nécessite une modification dans le système de commande de la machine scanner. Un mode de réalisation simple consiste à adresser les demandes de test alternativement à chacune des machines scanner disponibles. On note également que la plate-forme ne se limite pas à l'audit d'un seul périmètre audité mais permet d'auditer plusieurs périmètres indépendamment les uns des autres. En outre, le ou les périmètres audités peuvent prendre des formes multiples. Ils peut notamment s'agir d'une machine unitaire connecté à un réseau internet, mais également de plusieurs machines reliées entre elles par un ou plusieurs réseaux locaux ou distants. Par ailleurs, la nature même des machines testées est très variables : il peut s'agir, par exemple, de micro-ordinateurs, de routeurs, de serveurs, de terminaux mobiles, ... Ainsi, l'invention s'étend à toute machine ou système pouvant nécessiter un audit de sécurité et relié à un réseau. Le réseau lui-même peut être de nature variable : il est par exemple, et non limitativement de type internet, intranet, mobile,... On notera que l'invention ne se limite pas à une implantation purement matérielle mais qu'elle peut aussi être mise en #uvre sous la forme d'une séquence d'instructions d'un programme informatique ou toute forme mixant une partie matérielle et une partie logicielle. Dans le cas où l'invention est implantée partiellement ou totalement sous forme logicielle, la séquence d'instructions correspondante pourra être stockée dans un moyen de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM ou une mémoireflash) ou non, ce moyen de stockage étant lisible partiellement ou totalement par un ordinateur ou un microprocesseur. REVENDICATIONS 1. Procédé d'optimisation d'un audit de sécurité dans un réseau de communication (126) comprenant au moins un terminal (124,125,126), comprenant : - une étape de transmission (804) d'une requête de lancement de tests de sécurité, d'une plate-forme d'audit de sécurité (10) vers un desdits terminaux, dit terminal cible (124) ; - une étape d'exécution (806,807, 810,813, 814,823, 825) desdits tests de sécurité par ledit terminal cible ; et - une étape de transmission (808,809, 811,816, 815,822, 824,826) d'au moins un résultat desdits tests de sécurité par ledit terminal cible à ladite plate-forme d'audit de sécurité, caractérisé en ce que lesdits tests de sécurité sont sélectionnés (412) en fonction d'une analyse de l'environnement de ladite machine cible. 2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend une phase préalable comprenant : - une étape d'analyse (4123) d'un environnement de ladite machine cible, dit périmètre audité ; une étape de détermination (4123,4126) d'un contexte de lancement d'un test sur ladite machine cible en fonction du résultat de ladite analyse, ledit contexte de lancement d'un test comprenant des conditions de lancement dudit test ; et - une étape de sélection (4122) de tests destinés à ladite machine cible en fonction dudit contexte. 3. Procédé selon la revendication 2, caractérisé en ce que ladite étape de sélection inhibe parmi un ensemble de tests prédéfinis, chaque test pour lequel le contexte correspondant indique qu'il ne peut pas parvenir à ladite machine cible. 4. Procédé selon l'une quelconque des revendications 2 et 3, caractérisé en ce que ladite étape de sélection inhibe parmi un ensemble de tests prédéfinis, chaque test pour lequel le contexte correspondant indique que ledit test produit nécessairement un résultat non significatif. 5. Procédé selon l'une quelconque des revendications 2 à 4, caractérisé en ce que ladite étape de sélection inhibe parmi un ensemble de tests prédéfinis, chaque test pour lequel le contexte correspondant indique que ledit test rend la machine cible indisponible, l'indisponibilité de ladite machine cible étant supérieure à un niveau prédéterminé d'usage de ladite machine cible. 6. Procédé selon la revendication 5, caractérisé en ce qu'il comprend, en outre, une étape de sélection dudit niveau prédéterminé. 7. Procédé selon l'une quelconque des revendications 2 à 6, caractérisé en ce que ladite étape de sélection inhibe, parmi un ensemble de tests prédéfinis, chaque test pour lequel le contexte correspondant indique que ledit test produit nécessairement un résultat prédictible. 8. Procédé selon l'une quelconque des revendications 2 à 7, caractérisé en ce que ledit contexte comprend un ensemble d'au moins un couple comprenant luimême une valeur générique de clé (clé) et une valeur d'instantiation (valeur) associée à ladite valeur générique de clé. 9. Procédé selon la revendication 8, caractérisé en ce que ladite valeur d'instantiation associée à une valeur générique de clé fait partie du groupe de valeurs comprenant : - la valeur précise de ladite clé pour ladite machine cible ; - des valeurs générales (généralisateur) de ladite clé regroupant chacune une pluralité de valeurs précises de clé pour ladite machine cible ; et - des valeurs particulières (particularisateur)regroupant chacune une partie d'au moins une des valeurs précises de ladite clé appartenant à une desdites valeurs générales. 10. Procédé selon l'une quelconque des revendications 8 et 9, caractérisé en ce qu'il comprend une étape appartenant au groupe comprenant : - une affectation d'une valeur à au moins une desdites clés ; - une vérification de l'existence d'une valeur quelconque associée à une desdites clés dans un desdits couples ; et/ou - une vérification de l'existence d'une valeur déterminée, associée à une desdites clés dans un desdits couples. 11. Procédé selon l'une quelconque des revendications 1 à 10, caractérisé en ce qu'il comprend une étape de vérification (4126) de la validité d'au moins une partie du contexte, ladite plate-forme requérant le lancement de tests correspondant une partie de contexte valide, sur ladite machine cible sans requérir le lancement de tests correspondant à une partie de contexte non valide. 12. Procédé selon l'une quelconque des revendications 1 à 11, caractérisé en ce qu'il comprend, en outre, les étapes suivantes : - première étape de mémorisation des contextes ayant déjà permis au moins un lancement d'un premier test sur ladite machine cible ; - seconde étape de mémorisation des résultats obtenus lors dudit au moins un premier test ; - étape de comparaison d'au moins un contexte courant avec lesdits contextes enregistrés lors de ladite première étape de mémorisation, lorsque ledit premier test est à nouveau sélectionné ; et - production desdits résultats enregistrés lors de ladite seconde étape de mémorisation, de sorte que ledit premier test n'est pas lancé sur ladite machine cible. 13. Procédé selon l'une quelconque des revendications 1 à 12, caractérisé en ce qu'il comprend, en outre, - une étape d'identification d'au moins une vulnérabilité pour ladite machine cible ; et - une étape d'association de chaque vulnérabilité parmi lesdites au moins une vulnérabilité et d'un statut indiquant la probabilité d'occurrence de ladite vulnérabilité. 14. Procédé selon la revendication 13, caractérisé en ce qu'il comprend une étape de résolution de conflit entre des résultats contradictoires fournis par ladite machine cible pour au moins une desdites vulnérabilités, prenant en compte le statut associé à chaque vulnérabilité pour laquelle des résultats contradictoires ont été fournis. 15. Procédé selon la revendication 14, caractérisé en ce que ladite étape de résolution de conflit tient compte pour chaque vulnérabilité de sa probabilité d'occurrence, en hiérarchisant les probabilités d'occurrence associées auxdites vulnérabilités. 16. Procédé selon l'une quelconque des revendications 14 et 15, caractérisé en ce que, lors de ladite étape de résolution de conflit, pour chaque vulnérabilité, un statut indiquant que ladite vulnérabilité a une probabilité d'occurrence supérieure à 0,8 prévaut sur un autre statut associé à ladite vulnérabilité. 17. Procédé selon l'une quelconque des revendications 14 à 16, caractérisé en ce que, lors de ladite étape de résolution de conflit, pour chaque vulnérabilité, un statut indiquant que ladite vulnérabilité est absente prévaut sur un autre statut associé à ladite vulnérabilité et indiquant que ladite vulnérabilité a une probabilité d'occurrence inférieure à 0,2. 18. Dispositif d'optimisation d'audit de sécurité caractérisé en ce qu'il comprend des moyens adaptés à la mise en #uvre d'un procédé d'optimisation d'audit de sécurité dans un réseau de communication selon l'une quelconque des revendications 1 à 17. 19. Plate-forme d'audit (10) de sécurité destinée à un réseau de communication comprenant au moins un terminal (124 à 126), ladite plate-forme comprenant : des moyens de transmission d'une requête de lancement de tests de sécurité de ladite plate-forme vers un desdits terminaux dit un terminal cible, ledit terminal cible comprenant des moyens d'exécution desdits tests de sécurité ; et - des moyens de réception de résultat desdits tests de sécurité transmis par ledit terminal cible, caractérisé en ce que ladite plate-forme comprend, en outre, des moyens de sélection de tests destinés à ladite machine cible en fonction d'une analyse de l'environnement de ladite machine cible. 20. Système caractérisé en ce qu'il comprend au moins une plate-forme (10) à selon la revendication 19 et au moins un terminal (124 à 126) relié à ladite plateforme par au moins une ligne de communication (11).