Les tests d'intrusion autonomes peuvent-ils répondre aux exigences de conformité ?
Depuis deux décennies, les « tests d’intrusion » reviennent toujours au même : une fois par an, vous faites appel à un cabinet, un testeur passe une semaine ou deux à examiner vos systèmes, et vous recevez un fichier PDF. La plupart des cadres de conformité ont été élaborés autour de ce rituel précis : une intervention lente, manuelle et ponctuelle.
Les logiciels ne sont plus commercialisés une fois par an. Ils le sont plusieurs fois par jour. Le test d'intrusion annuel n'était déjà qu'un instantané qui perdait toute pertinence dès sa validation ; dans un monde de déploiement continu, il s'agit d'un instantané d'un système qui n'existe plus.
Les tests d'intrusion Aikidol'IA Aikidosont conçus pour répondre à cette réalité : des tests continus et autonomes qui s'exécutent sur vos applications et vos API au fur et à mesure de leur évolution, et qui génèrent un rapport que vous pouvez remettre à un auditeur. La question que se posent tous les RSSI ou responsables de la conformité est la suivante : ce rapport sera-t-il accepté aux fins de conformité ?
En bref , la réponse est la suivante : « Pour la plupart des référentiels, oui ; pour quelques-uns qui exigent l'intervention d'un professionnel agréé, non. » Cet article passe en revue les principaux référentiels de conformité et apporte une réponse claire.
Fonctionnement du test d'intrusion autonome Aikido
Aikido une flotte d'agents IA par les mêmes étapes que celles suivies par un testeur d'intrusion humain :
- Validation du périmètre et de la propriété. Les cibles sont définies dès le départ et classées en deux catégories : celles pouvant faire l'objet d'une attaque et celles accessibles. Afin d'éviter tout abus, nous vérifions que vous êtes bien le propriétaire des ressources concernées (par exemple, via la vérification des enregistrements DNS) avant d'envoyer le moindre trafic de test.
- Énumération et modélisation des menaces. Les agents répertorient toutes les fonctionnalités, tous les points de terminaison et toutes les API concernés. Dans le cadre d'interventions de type « boîte blanche », le code source lui-même constitue la source d'énumération et les agents établissent un rapport de reconnaissance ainsi qu'un plan d'attaque. Dans le cadre d'interventions de type « boîte grise » ou « boîte noire », ils s'appuient sur l'exploration, le fuzzing et la génération de listes de mots.
- Identification et exploitation des vulnérabilités. Les agents recherchent et exploitent activement les failles, mais uniquement dans la mesure nécessaire pour démontrer l'impact. Ils ne tentent pas d'obtenir un accès persistant à vos systèmes, ce qui signifie : aucune destruction de données, aucun déni de service, aucun déplacement latéral au sein de l'infrastructure, aucune porte dérobée.
- Validation. Des agents de validation spécialisés reproduisent chaque résultat afin de confirmer qu’il est bien réel et exploitable, ce qui distingue un test d’intrusion d’un scanner de vulnérabilités. Une fois le test d’intrusion terminé, toutes les données et tous les artefacts générés au cours de l’évaluation sont supprimés de nos systèmes.
- Rapports. Vous recevez un résumé ainsi que des informations techniques complètes : description, niveau de gravité, évaluation de l'impact, étapes de reproduction et recommandations de correction pour chaque anomalie confirmée.
- Correction. Au lieu de se contenter de vous fournir une liste de tâches, correction automatique par IA Aikidogénère correction automatique par IA des pull requests ou des correctifs pour les vulnérabilités confirmées (dans la mesure du possible). Cela vous permet de corriger instantanément les problèmes détectés et de procéder immédiatement à de nouveaux tests pour vérifier que le risque a bien disparu.
Ce que nous testons. Notre méthodologie couvre (sans s’y limiter) le Top 10 OWASP, Top 10 OWASP les applications agentiques et le sécurité des API 10 OWASP sécurité des API , y compris les catégories que les scanners automatisés ne détectent pas : contrôle d’accès défaillant autorisation au niveau des objets (BOLA), failles d’authentification, injection, SSRF, configuration de sécurité inadéquate et exploitation de la logique métier. Comme les agents sont de type « agentic » plutôt que basés sur des signatures, ils enchaînent les étapes et raisonnent sur le contexte à la manière d’un attaquant, puis s’arrêtent à la preuve d’impact.
Pourquoi ce rapport constitue-t-il une preuve d'audit ?
Un outil autonome n'est utile en matière de conformité que si l'on peut se fier à son comportement et en apporter la preuve. Les tests Aikidos'appuient sur une méthodologie structurée et un ensemble de garde-fous techniques visant à garantir la sécurité, les limites et l'auditabilité des tests autonomes.
Concrètement, cela se traduit par des contrôles qui intéressent les auditeurs :
- Des barrières de sécurité strictes, pas de simples invites. Le périmètre d'application est imposé au niveau du réseau, et tout ce qui en sort est automatiquement bloqué. Ces barrières sont techniquement mises en œuvre via un bac à sable au niveau du noyau, dont l'agent ne dispose d'aucun identifiant pour escape, et jamais par le biais d'instructions « souples » sous forme d'invites.
- Confinement et sécurité. Les agents s'exécutent dans des environnements isolés (sandboxes), sont soumis à des restrictions de débit et disposent de ressources limitées ; de plus, une liste d'actions interdites (outils de déni de service, exfiltration de données, opérations destructrices, attaques par force brute sur les identifiants) est appliquée par défaut.
- Un « kill switch » et une piste d'audit immuable. Chaque action, commande, requête et raisonnement de l'agent est consigné dans une piste d'audit inviolable et conservé pendant au moins un an. Le trafic comporte un en-tête HTTP unique et provient d'adresses IP statiques dédiées, ce qui le rend traçable et permet de l'ajouter à une liste blanche.
- Précision. Les résultats sont validés afin d'éviter les faux positifs, et toute modification apportée au modèle d'IA fait l'objet de tests comparatifs approfondis avant sa mise en production, ce qui garantit une amélioration continue du système.
- Une transparence totale et une couverture vérifiable. Nous offrons aux clients comme aux auditeurs une visibilité complète sur l’ensemble du processus de test grâce à des captures d’écran, un aperçu détaillé de la couverture et le raisonnement explicite qui sous-tend chaque action de l’agent. Contrairement aux tests d’intrusion traditionnels menés par des humains, qui ne fournissent souvent que les conclusions finales sans preuve de ce qui a réellement été exécuté, Aikido vous Aikido une preuve complète du travail effectué afin que vous puissiez vérifier exactement ce qui a été testé.
Cette combinaison constitue la preuve exigée par la plupart des audits : des tests réalisés par un tiers indépendant, des résultats reproductibles, une piste d'audit transparente et un rapport structuré accompagné de recommandations correctives.
Un test d'intrusion adapté à l'échelle de l'entreprise peut-il servir de preuve ?
Un test d'intrusion sur mesure est une évaluation basée sur l'IA qui adapte dynamiquement sa portée et son prix en fonction de la taille exacte et de la complexité architecturale de votre application. Aikido vos dépôts, vos points de terminaison et vos rôles, puis définit automatiquement la portée appropriée. Petite application, petit prix. Plateforme complexe, couverture exhaustive.
Fondamentalement, un test d’intrusion « rightsized » ne diffère pas beaucoup de nos tests d’intrusion « classiques ». La principale différence réside dans le fait que le périmètre est défini automatiquement plutôt que manuellement. Il incombe toujours au client de vérifier et de s’assurer que ce périmètre est correctement défini. À ce titre, les tests d’intrusion « rightsized » répondent toujours aux exigences des cadres de conformité autorisant les tests d’intrusion autonomes.
Ce que recherchent les auditeurs
Il est utile de savoir ce que les auditeurs ou les normes recherchent réellement lors d'un test d'intrusion :
- Une méthodologie documentée et reproductible : pas une approche au petit bonheur la chance.
- Indépendance: l'équipe chargée des tests n'est pas la même que celle qui développe ou exploite le système.
- Un véritable test d'efficacité : aller au-delà de l'analyse automatisée des vulnérabilités.
- Éléments de preuve: constatations, gravité et preuves.
- Mesures correctives et nouveaux contrôles des anomalies constatées.
Remarquez ce qui n' est généralement pas précisé : le fait qu'une personne doit appuyer sur les touches. Certains frameworks exigent effectivement des tests effectués par une personne ou de manière manuelle ; ce sont ceux-là qu'il faut surveiller de près.
Aperçu
Conclusion : les normes sont en retard par rapport à la technologie
Les normes qui préconisent de « tester régulièrement l’efficacité de vos contrôles » (RGPD, CRA, NIS2, SOC 2, ISO 27001, HIPAA, les recommandations de la FDA, CEI 81001-5-1, le SSDF) ont été rédigées en fonction d’un résultat visé et s’adaptent sans difficulté à des tests continus et autonomes . On peut même affirmer que plusieurs d’entre elles y sont favorables.
Les normes qui posent problème sont celles qui ont intégré le modèle de mise en œuvre de 2010 au cœur même du contrôle : une intervention annuelle, manuelle et certifiée par des experts (accréditation 3PAO, équipes rouges TLPT, « techniques manuelles » de la norme PCI). Ces normes n’ont pas tort de valoriser l’expertise humaine. Elles ont simplement été rédigées à une époque où la seule façon de mener des tests d’intrusion consistait à engager une personne pendant une semaine, une fois par an. Elles n’étaient pas préparées à l’avènement de systèmes autonomes qui testent chaque version, vérifient chaque résultat, enregistrent chaque action, puis corrigent et retestent ce qu’ils détectent.
Particularités du secteur
Secteur financier
PCI DSS
Exigence : la norme PCI DSS constitue le cadre le plus contraignant en la matière. Elle impose une méthodologie documentée de tests d’intrusion, la réalisation de tests d’intrusion internes et externes au moins une fois par an et après toute modification importante, la vérification des corrections apportées, ainsi que des tests distincts des contrôles assurant la segmentation de l’environnement des données des titulaires de cartes (plus fréquents pour les prestataires de services). Le test doit être réalisé par un testeur qualifié, indépendant sur le plan organisationnel des systèmes testés.
Les tests autonomes peuvent-ils répondre à cette exigence ? Non. Les directives du PCI relatives aux tests d’intrusion établissent une distinction claire entre un test d’intrusion et un scan de vulnérabilités : un scan est automatisé, tandis qu’un test d’intrusion est un processus manuel d’exploitation qui repose sur les compétences d’un testeur qualifié et indépendant. Les outils automatisés peuvent apporter une aide, mais les directives considèrent que le travail manuel constitue le test lui-même. Un test d’intrusion autonome ne sera pas accepté comme test d’intrusion PCI.
Les outils Aikidoexploitent effectivement la logique métier, les failles BOLA et les failles en chaîne ; il est donc judicieux de les exécuter dans le cadre de tests de sécurité continus aux interventions obligatoires, y compris après des modifications importantes. Il s’agit là d’un avantage en matière de sécurité et d’une source de preuves de correction, et non d’une validation PCI. Prévoyez séparément un test d’intrusion humain qualifié.
Conclusion : ne répond pas aux exigences. Le test d'intrusion doit être réalisé par un testeur humain qualifié. Les tests automatisés ne seront pas acceptés comme test d'intrusion PCI.
Référence : Norme PCI DSS v4.0.1, exigence 11.4 (11.4.1 à 11.4.6) ; Guide du PCI SSC sur les tests d'intrusion.
DORA
Les exigences : la loi DORA prévoit deux niveaux de tests. Le niveau général consiste en un programme de tests de résilience opérationnelle numérique que chaque entité financière doit mettre en place, et les tests d'intrusion font partie des méthodes qu'elle doit utiliser. Le niveau avancé impose aux entités financières importantes de réaliser des tests d'intrusion axés sur les menaces (TLPT) au moins une fois tous les trois ans, avec des règles strictes concernant les personnes autorisées à les mener.
Les tests autonomes peuvent-ils répondre à cette exigence ? Oui pour le programme général, non pour le TLPT. Le programme général offre une grande souplesse en matière de méthodes et inclut notamment les tests d’intrusion ; les tests autonomes continus y sont donc adaptés et vont au-delà du minimum périodique requis. Le TLPT est différent. Il s’inspire du cadre TIBER-EU de la BCE et exige le recours à des « red-teamers » externes qualifiés ainsi qu’à un prestataire externe spécialisé dans le renseignement sur les menaces, les établissements de crédit importants étant tenus de faire appel exclusivement à des testeurs externes. Il s’agit donc, de par sa conception, d’une intervention humaine de type « red team ».
Conclusion : Oui pour le programme de tests général. Il ne répondra pas aux exigences du TLPT, qui impose le recours à des testeurs externes jouant le rôle d’adversaires (red team). Utilisez Aikido exécuter et documenter le programme général. Le TLPT constitue une mission distincte qui doit être réalisée par des personnes physiques.
Référence : DORA (règlement (UE) 2022/2554), articles 24 et 25 (programme d'essais), articles 26 et 27 (TLPT).
Règle de la FTC relative aux mesures de protection
Exigence : la règle « Safeguards Rule » de la FTC régit la manière dont les établissements financiers protègent les informations de leurs clients. Elle impose de tester régulièrement l'efficacité de vos mesures de sécurité et vous propose deux méthodes pour ce faire : surveillance continue ou, à défaut, un test d'intrusion annuel assorti d'évaluations de vulnérabilité au moins tous les six mois. Des tests sont également requis à la suite de changements majeurs apportés aux opérations.
Les tests autonomes peuvent-ils répondre à cette exigence ? Oui. surveillance continue présentée comme une alternative directe au test d’intrusion annuel, ce que permettent justement les tests autonomes continus. Pour un établissement qui préfère une approche périodique, un seul programme autonome permet de réaliser à la fois le test annuel et les évaluations semestrielles. La règle n’impose aucune exigence en matière de personnel ni d’accréditation pour le testeur.
Conclusion : Oui. surveillance continue clairement le test d'intrusion annuel.
Référence : Règle relative aux mesures de protection de la FTC, 16 CFR 314.4(d) et 314.4(d)(2).
Réglementation du NYDFS en matière de cybersécurité
Exigence : la réglementation new-yorkaise en matière de cybersécurité dans le secteur des services financiers s'applique aux banques, aux assureurs et aux autres entités titulaires d'une licence dans l'État de New York ; elle sert de référence au-delà des frontières de l'État en tant que norme de base pour le secteur financier. Sa section consacrée aux tests d'intrusion impose la mise en place de tests articulés autour de votre évaluation des risques, organisés soit sous la forme surveillance continue sous la forme d'un test d'intrusion annuel accompagné d'évaluations de vulnérabilité semestrielles.
Les tests autonomes peuvent-ils répondre à cette exigence ? Oui. À l'instar de la règle de la FTC, le règlement considère surveillance continue le test d'intrusion annuel comme des alternatives. Les tests autonomes continus s'inscrivent dans la voie de la surveillance continue, et pour les entités qui optent pour la voie périodique, ils donnent également lieu au test annuel et aux évaluations semestrielles. Le règlement n'impose aucune exigence d'accréditation des testeurs.
Conclusion : Oui. surveillance continue à elle seule surveillance continue cette exigence.
Référence : Règlement du NYDFS sur la cybersécurité, 23 NYCRR 500.5 (deuxième amendement, 2023).
Secteur de la santé
HIPAA
L'exigence : la règle de sécurité de la loi HIPAA ne mentionne pas explicitement les tests d'intrusion. Sa norme d'évaluation impose une évaluation périodique, tant technique que non technique, de vos mesures de sécurité, ce qui correspond généralement au cadre dans lequel s'inscrivent les tests d'intrusion. Une proposition de mise à jour datant de décembre 2024 rendrait cette exigence explicite, en imposant un scan de vulnérabilités au moins tous les six mois et des tests d'intrusion au moins une fois par an. À la mi-2026, cette mise à jour n'est pas encore définitive, mais l'orientation est claire.
Les tests autonomes peuvent-ils répondre à cette exigence ? Oui. Ni la norme d'évaluation actuelle ni la mise à jour proposée n'imposent le recours à un testeur humain. Un rapport autonome constitue aujourd'hui la preuve d'une évaluation technique périodique, et il permettrait demain de satisfaire à l'obligation proposée de test d'intrusion annuel, les tests continus dépassant une fréquence annuelle.
Conclusion : Oui, et prêt pour le projet de règlement.
Référence : Règle de sécurité HIPAA, 45 CFR 164.308(a)(8) ; projet de règlement de 2024 (RIN 0945-AA22).
HITRUST CSF
Exigence : le HITRUST CSF est un référentiel certifiable utilisé par les organismes de santé américains et leurs fournisseurs pour démontrer la protection des informations de santé protégées (PHI). Les tests d’intrusion font partie intégrante de ses exigences en matière de conformité technique et d’évaluation de la sécurité. Pour obtenir la certification de niveau supérieur (r2), les tests doivent s’inscrire dans une période glissante de 12 mois et s’inscrire dans le cadre d’un programme continu plutôt que d’un événement annuel ponctuel ; les résultats doivent faire l’objet d’un suivi et faire l’objet de nouveaux tests.
Les tests autonomes peuvent-ils répondre à cette exigence ? Oui, HITRUST n'exige pas la présence d'un testeur humain ou agréé pour le test d'intrusion, et sa préférence pour un programme continu plutôt que pour un événement annuel s'inscrit dans la logique des tests autonomes continus. Un rapport de test d'intrusion autonome constitue une preuve valable pour l'évaluateur.
Conclusion : Oui, en ce qui concerne l'exigence relative aux tests d'intrusion. La validation par l'évaluateur externe constitue une étape d'audit distincte.
Référence : contrôle 06.h du cadre de conformité HITRUST (vérification de la conformité technique).
Recommandations de la FDA en matière de cybersécurité avant la mise sur le marché
Exigence : le guide de la FDA intitulé « Cybersécurité des dispositifs médicaux : considérations relatives au système qualité et contenu des dossiers de demande d'autorisation de mise sur le marché » recommande une approche de tests de sécurité à plusieurs niveaux, mais exige en pratique la présentation d'un rapport de test d'intrusion lors du dépôt des dossiers de demande d'autorisation de mise sur le marché.
Les tests autonomes peuvent-ils répondre à ces exigences ? Oui. Les recommandations sont axées sur les résultats : elles exigent des preuves attestant que les tests ont bien été effectués, en précisant qui les a réalisés, quelle était leur portée, ce qui a été détecté et, surtout, quelles mesures ont été prises en conséquence. En fin de compte, l’objectif est de s’assurer que les risques liés à la sécurité sont maîtrisés. Le rapport de test d’intrusion basé sur l’IA Aikidorépond à ces attentes.
Conclusion : Oui, mais précisez dans votre dossier la portée du document, les méthodes utilisées et son caractère indépendant.
Référence : section 524B de la loi FD&C ; lignes directrices de la FDA relatives à la cybersécurité avant la mise sur le marché (2025).
Règlement de l'UE sur les dispositifs médicaux (MDR)
Exigence : les exigences générales de sécurité et de performance du RDM prévoient que les logiciels destinés aux dispositifs médicaux soient développés selon l’état de l’art, et qu’ils fassent l’objet d’une vérification et d’une validation, ainsi que de mesures minimales de sécurité informatique tout au long du cycle de vie du produit. Les lignes directrices de l’UE sur la cybersécurité des dispositifs médicaux (MDCG 2019-16) mentionnent les tests d’intrusion comme faisant partie intégrante de cette vérification et validation, au même titre que les tests des fonctionnalités de sécurité, le fuzzing et l’analyse des vulnérabilités.
Les tests autonomes peuvent-ils répondre à cette exigence ? Oui. Le règlement MDR et ses lignes directrices ne prescrivent aucune méthode particulière, et un test d’intrusion autonome constitue une preuve valable de vérification et de validation. Les tests continus s’inscrivent également mieux dans l’approche axée sur le cycle de vie qu’un test ponctuel. À l’instar des lignes directrices de la FDA, il s’agit en fin de compte de démontrer que les risques pour la sécurité sont maîtrisés.
Conclusion : Oui.
Référence : Règlement (UE) 2017/745 (MDR) de l’UE, annexe I, GSPR 17.2 et 17.4 ; lignes directrices MDCG 2019-16.
IEC 81001-5-1
Exigence : Il s’agit de la norme relative au cycle de vie sécurisé des logiciels de santé, qui sera harmonisée avec le RDM. Les activités de test des systèmes logiciels qu’elle prévoit comprennent les tests des exigences de sécurité, les tests d’atténuation des menaces, les tests de vulnérabilité et les tests d’intrusion. La norme exige que les tests d’intrusion soient réalisés par un service ou un organisme indépendant des développeurs, et elle comporte une disposition distincte concernant la gestion des conflits d’intérêts entre les testeurs et les développeurs.
Les tests autonomes peuvent-ils répondre à cette exigence ? Oui, et cette exigence d'indépendance joue en votre faveur. Ce que la norme exige, c'est une indépendance organisationnelle vis-à-vis des développeurs, et non vis-à-vis d'un testeur humain. En tant que tiers externe, Aikido cette exigence d'indépendance, tandis que la méthodologie autonome et la piste d'audit fournissent l'activité documentée et reproductible attendue par la norme.
Conclusion : Oui, l'indépendance vis-à-vis des tiers répond à cette exigence.
Référence : norme CEI 81001-5-1:2021, clauses 5.7.4 (correspondant à la norme SVV-4) et 5.7.5.
Automobile
ISO/SAE 21434
Exigence : la cybersécurité automobile repose sur la norme ISO/SAE 21434, norme technique relative à la cybersécurité des véhicules, ainsi que sur sa méthodologie de gestion des risques et sur l’analyse des menaces et l’évaluation des risques (« TARA »). Cette norme désigne les tests d’intrusion comme un moyen de vérifier que les objectifs de cybersécurité ont été atteints.
Les tests autonomes peuvent-ils répondre à cette exigence ? Oui, pour les parties auxquelles ils ont accès. La norme est axée sur les résultats. Les tests d’intrusion constituent l’une des nombreuses méthodes de validation (par exemple, le fuzzing, SAST, DAST, etc.), et un rapport de test d’intrusion autonome constitue une preuve valable, les tests continus s’inscrivant également dans la logique du cycle de vie. Une mise en garde toutefois : les véhicules reposant sur des composants embarqués, les tests de sécurité physique au niveau matériel ne peuvent pas être effectués à l’aide de méthodes autonomes.
Conclusion : Oui, en ce qui concerne la surface d'attaque connectée et back-end. La norme offre une grande souplesse en matière de méthodes et accepte les tests autonomes comme preuve de validation.
Référence : norme ISO/SAE 21434:2021 relative à la validation de la cybersécurité (clause 11, RQ-11-01).
Gouvernement et secteur public
ENS
Exigence : le « Esquema Nacional de Seguridad » espagnol mentionne explicitement les tests d'intrusion parmi les mesures de sécurité. Ceux-ci sont obligatoires pour les systèmes de catégorie élevée et recommandés pour ceux de catégorie moyenne ; les résultats récents alimentent l'audit périodique prévu par ce cadre réglementaire.
Les tests autonomes peuvent-ils répondre à cette exigence ? Oui. L'ENS précise que ce sont les tests qui comptent, et non la personne qui les effectue. Les résultats des tests d'intrusion autonomes satisfont à cette exigence, et les tests continus dépassent les fréquences recommandées (annuelle pour le niveau « élevé » et bisannuelle pour le niveau « moyen »).
Conclusion : Oui, les tests d'intrusion autonomes répondent à cette exigence.
Référence : ENS (décret royal 311/2022), annexe II, mesure mp.s.3 ; audit périodique prévu à l'article 31.
NIST SP 800-53
Exigence : la norme NIST 800-53 comporte une mesure de contrôle spécifique aux tests d'intrusion. Elle prévoit la réalisation de tests d'intrusion à une fréquence définie par l'organisation, fait appel à un agent ou à une équipe de test d'intrusion indépendante, et ajoute des exercices de type « red team » à titre de mesure complémentaire. La mesure précise explicitement que les tests d'intrusion vont au-delà de l'analyse automatisée des vulnérabilités et sont menés par des agents et des équipes disposant de compétences avérées.
Les tests autonomes peuvent-ils répondre à cette exigence ? Dans une large mesure, oui, bien plus que le PCI. La mesure de contrôle s’articule autour de l’indépendance et du fait d’aller au-delà de la simple analyse, deux critères auxquels Aikido : il s’agit d’un tiers indépendant, et il exploite et valide les systèmes plutôt que de se contenter de les analyser. La mesure de contrôle utilise même le terme « agents ». Le jugement résiduel, à savoir si un agent autonome fait preuve des « compétences » requises, revient à l’autorité d’évaluation ; veillez donc à confirmer l’acceptation auprès de votre évaluateur.
Conclusion : Oui, avec l'accord de l'évaluateur. Les critères d'indépendance et de « va-au-delà de la simple analyse » sont clairement remplis.
Référence : NIST SP 800-53, rév. 5, mesure CA-8 (avec CA-8(1) et CA-8(2)).
Décret présidentiel américain n° 14028
Exigence : ce décret américain a donné naissance au « Secure Software Development Framework » (SSDF). Ce cadre prévoit une procédure de test du code exécutable visant à détecter les vulnérabilités, qui englobe les tests dynamiques, le fuzzing et les tests d'intrusion. Les fournisseurs des agences fédérales américaines s'engagent par écrit à respecter ce cadre en remplissant un formulaire d'attestation de la CISA.
Les tests autonomes peuvent-ils répondre à cette exigence ? Oui. Le cadre est neutre sur le plan technologique. Un test d'intrusion autonome constitue un moyen légitime de se conformer à la pratique de test du code, et votre rapport sert de preuve à l'appui de votre auto-attestation.
Conclusion : Oui, aucun test manuel n'est nécessaire.
Référence : décret présidentiel n° 14028, section 4(e) ; NIST SSDF (SP 800-218), pratiques PW.8 et PW.8.2 ; formulaire d’attestation de développement logiciel sécurisé de la CISA (OMB M-22-18).
FedRAMP
Exigence : FedRAMP impose la réalisation d'un test d'intrusion annuel conforme à ses critères de référence, portant sur un ensemble obligatoire de vecteurs d'attaque et mené par un organisme d'évaluation tiers accrédité (3PAO) pour les systèmes classés « modérés » et « élevés ».
Un test autonome peut-il répondre à cette exigence ? Non. Le test d'intrusion qui sous-tend une autorisation FedRAMP, ainsi que le test d'intrusion annuel qui permet de la maintenir, doivent être réalisés par un organisme 3PAO accrédité. Un test autonome effectué par un organisme non 3PAO ne sera pas accepté dans le cadre d'un dossier d'autorisation ou d'une évaluation annuelle. Il peut être réalisé entre ces deux interventions à titre de test de sécurité supplémentaire, mais il ne constitue pas une preuve d'autorisation.
Conclusion : ne répond pas à l'exigence. Les tests d'intrusion doivent être réalisés par un organisme tiers agréé.
Référence : Lignes directrices FedRAMP relatives aux tests d'intrusion ; contrôle CA-8 de la norme NIST SP 800-53 ; accréditation 3PAO par l'A2LA.
FISMA
Exigence : la norme FISMA reprend les exigences en matière de tests définies dans la norme NIST 800-53, appliquées dans le cadre du référentiel de gestion des risques du NIST. Le périmètre et le niveau de rigueur sont déterminés par l'agence et la classification du système.
Les tests autonomes peuvent-ils répondre à cette exigence ? En général, oui, selon la même logique que la mesure de contrôle NIST 800-53, sous réserve des exigences d’évaluation de l’agence. Pour les systèmes qui visent également une autorisation externe régie par les règles d’un évaluateur accrédité (comme FedRAMP), il convient de se conformer aux contraintes de ce programme.
Conclusion : Oui, mais à la discrétion de l'agence.
Référence : FISMA via les normes NIST SP 800-53 (CA-8) et NIST SP 800-37 (cadre de gestion des risques).
Normes internationales
SOC 2
Exigence : la norme SOC 2 n’impose pas explicitement la réalisation d’un test d’intrusion, mais les critères « Trust Services » de l’AICPA (l’organisme de référence derrière la norme SOC 2) y font référence : le critère de surveillance mentionne les tests d’intrusion comme une méthode d’évaluation acceptable, et le critère relatif à la détection de nouvelles vulnérabilités s’appuie sur des tests actifs. Dans la pratique, les auditeurs s’attendent à recevoir des preuves issues de tests d’intrusion, en particulier pour un rapport de type II, au cours de la période d’audit, accompagnées de preuves des mesures correctives mises en œuvre et des nouveaux tests effectués.
Les tests autonomes peuvent-ils répondre à cette exigence ? Oui. Un test réalisé par un tiers indépendant constitue une preuve plus solide qu’un test interne, et la mention « évaluations continues ou distinctes » suggère la mise en place de tests continus.
Conclusion : Oui. Les tests continus correspondent directement aux « évaluations continues ».
Référence : Critères de l'AICPA relatifs aux services fiduciaires CC4.1 et CC7.1
ISO/IEC 27001
L'exigence : certaines mesures de contrôle de l'annexe A de la norme ISO 27001 constituent des points clés : l'une concerne la gestion des vulnérabilités techniques, qui exige « des tests d'intrusion ou des évaluations de vulnérabilité planifiés, documentés et reproductibles, réalisés par des personnes compétentes et autorisées » ; une autre porte sur les tests de sécurité au cours des phases de développement et de réception ; et une dernière concerne le cycle de vie du développement sécurisé.
Les tests autonomes peuvent-ils répondre à cette exigence ? Oui. Le libellé de la norme correspond pratiquement à une description des tests autonomes, et la reproductibilité est intégrée au fonctionnement même des agents. Les auditeurs acceptent ici les tests automatisés et continus réalisés par des tiers comme preuve, tandis que le rapport et la piste d'audit constituent la partie « documentée ».
Conclusion : Oui. Les tests « reproductibles » s’intègrent parfaitement dans ce contexte.
Référence : ISO/IEC 27001:2022, annexe A ; ISO/IEC 27002:2022, mesures de contrôle 8.8, 8.25 et 8.29.
Règlements européens
Directive NIS2
Exigence : la directive NIS 2 impose aux organisations concernées de gérer les vulnérabilités et de disposer de politiques permettant d'évaluer l'efficacité de leurs mesures de sécurité. Le règlement d'application précise ces gestion des vulnérabilités en matière de gestion des vulnérabilités et prévoit des tests de sécurité automatisés ou manuels, des tests d'intrusion et des analyses de vulnérabilité, qui doivent être effectués régulièrement et à la suite de modifications importantes.
Les tests autonomes peuvent-ils répondre à cette exigence ? Oui, tout à fait. Le règlement d’application de la directive NIS2 est l’un des rares textes à mentionner explicitement les tests automatisés et les tests d’intrusion comme méthodes acceptables. Les tests autonomes continus répondent à l’exigence de « régularité et après des changements significatifs », et le rapport constitue une preuve valable tant pour l’obligation de gestion des vulnérabilités que pour celle d’évaluation de l’efficacité.
Conclusion : Oui. Les tests automatisés et les tests d'intrusion sont expressément prévus.
Référence : directive NIS2 (UE) 2022/2555, article 21, paragraphe 2, points e) et f) ; règlement d'exécution (UE) 2024/2690, annexe, points 6.10 et 7.1.
RGPD
Exigence : le RGPD impose la mise en place d'un processus permettant de tester, d'analyser et d'évaluer régulièrement l'efficacité de vos mesures de sécurité techniques et organisationnelles.
Les tests autonomes peuvent-ils répondre à cette exigence ? Oui. Le RGPD ne prescrit pas de méthode particulière et met l'accent sur la régularité des tests ; ainsi, des tests autonomes continus constituent une preuve plus solide d'un processus en cours qu'un rapport PDF annuel. Le rapport atteste à la fois de la boucle de test et de celle de correction.
Conclusion : Oui, cela favorise les tests continus.
Référence : RGPD (règlement (UE) 2016/679), article 32, paragraphe 1, point d).
Cyber Resilience Act
Exigence : L'Autorité de régulation des télécommunications (CRA) exige que les produits comportant des éléments numériques soient mis sur le marché sans présenter de vulnérabilités exploitables connues et que, dans le cadre de la gestion des vulnérabilités tout au long du cycle de vie du produit, des tests et des contrôles efficaces et réguliers soient effectués pour évaluer la sécurité du produit.
Les tests autonomes peuvent-ils répondre à cette exigence ? Oui. Les tests « efficaces et réguliers » sont précisément ce pentest autonome continu pentest autonome tout au long du cycle de vie du produit, et le rapport valide à la fois l’obligation de test et le critère « aucune vulnérabilité exploitable connue » au moment de la mise sur le marché.
Conclusion : Oui, les tests « réguliers » favorisent les tests d'intrusion autonomes.
Référence : Cyber Resilience Act règlement (UE) 2024/2847), annexe I (partie I et partie II, point 3) ; article 13.
