Tests d’intrusion : le contrat, gage d’une mission réussie

Régulièrement utilisés par les responsables de la sécurité des systèmes d’information pour mettre à l’épreuve et évaluer la résistance de leur environnement à un certain niveau d’attaque, les tests d’intrusion et le contrat qui les formalise ne doivent pas être considérés de façon anodine. Les règles juridiques à respecter.

Sans une compréhension exacte de leurs tenants et aboutissants, que ce soit au regard de l’interprétation de leurs résultats, des risques induits ou encore des obligations et responsabilités respectives du prestataire et de son client, les opérations de tests intrusifs ne doivent pas être autorisées ou engagées sans un encadrement et une préparation minutieuse. De ce point de vue, le contrat de test d’intrusion, qui prévoit également l’organisation et les modalités de la mission, est sans nul doute un des éléments déterminants dans le succès futur d’une prestation de tests intrusifs.

Les risques des tests d’intrusion

Les tests d’intrusion comportent intrinsèquement de nombreux risques de différentes natures :• Les évènements liés au système d’information (SI) cible et au périmètre d’intervention, conduisant en particulier le prestataire à réaliser (dans cette hypothèse, illégalement) des tests d’intrusion sur une partie du système se situant en dehors du périmètre contractuel ou qui n’appartient pas ou ne relève pas de la responsabilité du client mais d’une entité juridique autonome ou d’un tiers hébergeur par exemple, dont les ressources sont mutualisées au profit de différentes organisations ; dans ce dernier cas de figure, les risques induits par la réalisation de tests d’intrusion sur des serveurs partagés par différents clients sont évidemment démultipliés dans l’hypothèse de la réalisation de dommages au cours des opérations de tests ;• les évènements liés à la maîtrise des outils ou aux méthodes employées pour la conduite des tests d’intrusion, causant des dommages sur le SI cible (atteintes par exemple à l’intégrité ou de la confidentialité des données et surtout, à la disponibilité du système engendrant un déni de service) ou permettant la réalisation d’attaques opportunistes, éventuellement par rebond, au cours de la période des tests (porte dérobée installée par le prestataire, vulnérabilité non corrigée permettant d’atteindre des ressources critiques de l’environnement cible ou d’affecter des SI tiers, …) ;• les évènements liés aux résultats des tests, conduisant par exemple au déclenchement d’une fausse alerte et à un dépôt de plainte contre le prestataire, ou bien surtout, de façon plus réaliste, à une perturbation du fonctionnement du SI cible ou encore à l’accès à des données « sensibles », qu’elles soient confidentielles, personnelles ou révélatrices de contenus pénalement répréhensibles.

Le contrat vise à appréhender tous les risques

Face à ces différentes hypothèses, le contrat, qui a vocation à anticiper les risques, doit fixer un cadre strict pour l’intervention du prestataire et permettre, dans le même temps, au client de prendre conscience aussi bien de la démarche à respecter et de ses objectifs, que des précautions nécessaires au bon déroulement des opérations.Pour parer aux différents évènements envisagés plus haut, la première étape clé dans la préparation d’une mission de tests intrusifs consistera d’abord à recueillir toutes les autorisations de test nécessaires en fonction à la fois du périmètre technique des opérations envisagées et de l’existence ou non de prestataires externes. Ainsi, pour ne pas tomber sous le coup de l’article 323-1 du Code pénal (qui punit, rappelons-le, tout accès frauduleux à un « système de traitement automatisé de données » [1]), la signature du contrat par le client ne suffira pas toujours et il conviendra encore d’obtenir l’autorisation spécifique, d’une part, des sociétés détenues par le client – mais dont il ne détient pas la majorité du capital et pour lesquelles il n’est pas décisionnaire – et d’autre part, de ses sociétés partenaires (fournisseurs, hébergeurs, …) qui sont compris dans le périmètre des tests prévus au contrat [2]. Bien entendu, force est de rappeler également la nécessité de vérifier la qualité et la capacité à engager l’organisation cliente du signataire du contrat ou de l’autorisation. Par ailleurs, relevons ici que les délais de réalisation, qui conditionnent quant à eux la période de légalité des tests – ou bien, s’agissant d’une approche « boîte blanche », la période d’attribution des droits et habilitations sur le système d’information client – devront eux aussi être définis avec la plus grande précision, ainsi que l’obligation, le cas échéant, de respecter certaines dates et plages horaires pour la conduite des tests.Ensuite, le contrat comprendra, tantôt dans son préambule (trop souvent négligé), tantôt dans le corps de ses dispositions, un « avertissement » au client, qui n’est pas en principe ici considéré, au regard de la loi, comme un professionnel du domaine de la sécurité des systèmes d’information mais bien comme un profane, et qui doit, en conséquence du devoir d’information, de conseil et d’alerte du prestataire, être éclairé en particulier sur les risques induits et les limites des objectifs que peuvent remplir des tests d’intrusion. A cet égard, il soulignera notamment l’absence d’exhaustivité des tests d’une part – dont l’objectif n’est pas de révéler toutes les vulnérabilités d’un système mais bien plutôt de démontrer la possibilité d’en exploiter certaines – et l’erreur d’interprétation qui conduirait à considérer l’échec d’un test d’intrusion (au sens où le système aurait résisté à toutes les tentatives d’attaques menées par les pentesteurs) comme constituant la preuve de la sécurité du système d’autre part – en effet, pour obtenir un niveau d’assurance suffisant sur la sécurité d’un environnement informatique, un audit de sécurité prenant en compte les aspects organisationnels et procéduraux en plus des questions techniques doit permettre de mieux répondre à ces attentes.

Le contrat informe, responsabilise et organise

Le client ainsi informé des risques et limites des opérations de test, le contrat pourra formaliser un ensemble d’obligations respectives des parties. Pour sa part, le client devra notamment s’engager à prendre toutes les mesures nécessaires pour protéger les données, informations et programmes présents sur son système d’information. Il sera le garant de l’application effective d’une politique de sauvegarde adéquate pour la conservation et la restauration (« back up ») nécessaire à la sécurité de toutes ses données, informations et programmes. Le prestataire, de son côté, s’engagera en particulier à informer sans délai le client de tout dysfonctionnement résultant directement ou indirectement de la session de tests intrusifs qu’il réalise. Lorsqu’il constatera l’existence d’une vulnérabilité critique sur le système d’information du client, il prendra immédiatement contact avec le responsable projet du client pour lui indiquer les mesures correctives à appliquer et parer ainsi à une éventuelle attaque réelle qui pourrait survenir à tout moment.Les modalités de réalisation de la mission propres à garantir le bon déroulement des opérations de tests seront également spécifiées dans le contrat qui désignera en particulier les outils et techniques autorisés (mention le plus souvent générique) ainsi que les prestations « exclues », telles que le social engeeneering [3]. En effet, à la différence des attaques logiques réelles, Patrick Chambet souligne dans un article [4], qu’il convient, en principe, dans le cadre d’opérations de tests intrusifs, de se garder notamment de perturber le système cible, ce qui exclut par exemple, sauf l’autorisation préalable du client, la technique du déni de service, même lorsque celle-ci vise à faciliter une autre attaque, ou d’implanter une charge utile : rootkit, cheval de Troie, code hostile, bombe logique, …, qui comportent un risque fort d’atteinte au fonctionnement du système ou à ses données. De même, l’auteur recommande de ne jamais modifier les données sur la cible (dans la pratique, on relève que la modification de certaines configurations – SGBDR par exemple – pourra être permise, pour démontrer une faiblesse exploitable telle que l’élévation de privilèges à un niveau administrateur), et en particulier, les chargés de test ne doivent pas tenter d’effacer leurs traces dans les logs. A l’inverse, de ce point de vue, il faudra au contraire toujours avancer « à visage découvert » et préserver la traçabilité des actions effectuées sur le système en communiquant au client les adresses sources utilisées par les chargés de tests, afin que ceux-ci puissent être identifiés et permettre le cas échéant de qualifier un incident intervenant pendant la période de test.Le contrat prévoira également des étapes de validation au cours de la mission, notamment, suivant les recommandations émises par le Clusif [5] :

une étape de validation du périmètre de l’intrusion : le prestataire fournira par exemple le schéma de topologie du réseau vu de l’extérieur et demandera au client de valider que les éléments identifiés lui appartiennent bien et sont inclus dans la couverture du contrat ;
une étape de validation après la phase de recherche de vulnérabilités : lorsqu’une vulnérabilité majeure est identifiée, pouvant atteindre le fonctionnement du système ou l’intégrité des données, le prestataire sollicite une autorisation expresse du client pour pouvoir l’exploiter et tester plus en profondeur le système d’information cible.

Le contrat, objet d’une relation de confiance

En dernier lieu, s’agissant des ressources mises à disposition par le prestataire, force est de souligner que le succès d’une campagne de tests repose pour une part essentielle sur la relation de confiance avec les pentesteurs et leur savoir-faire, ce qui justifie que le contrat soit le plus souvent signé intuitu personae. Ainsi, s’agissant en particulier de tests dits « en aveugle » (type boîte noire), où le chargé de test est placé dans une position presque identique à celle d’une personne malintentionnée (la différence ici, c’est le respect de règles de moralité, de transparence, de confidentialité et de probité, qui sont rappelées dans le dispositif du contrat), Bernard Foray (RSSI) témoigne [6] que ces tests sont l’affaire de spécialistes ayant « l’expérience et aussi l’instinct, qui leur permet d’interpréter toute modification ou variation dans le contenu d’une trame réseau, (…) ». Cette catégorie de tests vient donc pour lui en complément des audits internes et ils ne peuvent être réalisés sans l’aide externe de professionnels du domaine appliquant une méthodologie et des principes déontologiques établis et partagés.Marie Barel, Consultant SSI chez Orange, Expertise juridique TIC[1] Cet accès frauduleux se caractérise, suivant les termes de la jurisprudence, par un accès « sans droit et en connaissance de cause », c’est-à-dire que l’on se sait dépourvu d’habilitation ou d’autorisation d’une part, et que l’on a pas agi par erreur mais de façon consciente et délibérée d’autre part. Sur ces éléments constitutifs de l’infraction visée, voir en particulier l’arrêt de la Cour d’appel de Paris, 5 avril 1994.[2] On notera ici, de façon incidente, que le périmètre à tester doit être déterminé non pas en fonction de la valeur que vous accordez à un système, mais de la valeur que les attaquants peuvent leur accorder.[3] Conformément aux règles de déontologie contenues dans la Charte des Professionnels des Tests Intrusifs (Charte FPTI) : http://www.freesec.net/pro_charte.htm [4] Les tests d’intrusion externes : tests d’intrusion réseau, système, applicatifs – Patrick Chambet (MISC 11) : http://www.chambet.com/publications/ Les%20tests%20d’intrusion.pdf[5] Test d’intrusion – Document technique du CLUSIF (mars 2004) : http://www.clusif.fr/fr/production/ouvrages/pdf/TestIntrusion.pdf [6] Bernard Foray, La fonction RSSI: guide des pratiques et retoursd’expérience – Editions Dunod / 01 Informatique (2007) ; EAN13 : 9782100502189

Les autres articles du dossier