Test d'intrusion continu : modèles, fréquence et coût

Le terme décrit un résultat, des tests qui suivent le rythme des changements, plutôt qu'une méthode. En pratique, on vous proposera l'un de trois modèles :

• PTaaS (penetration testing as a service). Des testeurs humains qui travaillent via une plateforme : vous réservez des tests, voyez les constats au fil de l'eau, échangez avec les testeurs et obtenez des retests dans une fenêtre donnée. Cobalt, Synack, HackerOne, NetSPI, Bishop Fox et BreachLock vendent ce modèle, souvent enrichi d'automatisation et désormais d'agents IA.
• Test continu autonome. Un logiciel qui mène lui-même l'attaque, selon un calendrier, sans testeur à chaque exécution. Horizon3.ai NodeZero, Pentera et XBOW en sont des exemples, tout comme Zero Hunt. Voir le test d'intrusion autonome et les agents IA de pentest.
• Hybride. Une plateforme exécute en continu des tests automatisés ou pilotés par l'IA, et des testeurs humains vérifient les constats ou testent ce que le logiciel ne peut pas tester.

Les termes voisins se recouvrent : le continuous automated red teaming (CART) désigne généralement la même idée appliquée à la surface externe, et l'Adversarial Exposure Validation de Gartner regroupe le pentest automatisé et la simulation de brèches et d'attaques.

Si vous cherchiez l'OWASP Continuous Penetration Testing Framework : la page du projet existe, mais elle se limite à exprimer l'intention de standardiser la pratique, et son dépôt n'a pas changé depuis 2022. Il n'existe aucun document de référence à suivre.

• Le changement. Chaque nouveau serveur, règle de pare-feu, compte cloud ou version logicielle peut ouvrir un chemin que le rapport de l'an dernier n'a jamais vu.
• Les nouvelles vulnérabilités. Équipements de bordure, VPN et serveurs de transfert de fichiers reçoivent régulièrement des CVE critiques exploitées dans les jours qui suivent leur divulgation. Un test réalisé en mars ne dit rien d'une CVE publiée en juin.
• La dérive. Des corrections sont annulées, des exceptions temporaires deviennent permanentes, et des identifiants sont réutilisés.
• La preuve de remédiation. Sans nouveau test, un ticket clos est une affirmation, pas une preuve.

Rien de tout cela ne rend inutile le test annuel mené par des humains. Cela en fait le contrôle approfondi, et non le seul.

La plupart des règles fixent un minimum et ajoutent un déclencheur lié au changement, et c'est à ce second volet que répond le test continu :

• PCI DSS v4.0.1, exigence 11.4 : tests d'intrusion internes et externes au moins une fois tous les 12 mois et après toute mise à niveau ou modification significative de l'infrastructure ou d'une application. Voir PCI DSS 11.3 et 11.4.
• DORA, art. 24(6) : des tests appropriés au moins une fois par an sur tous les systèmes et applications TIC qui soutiennent des fonctions critiques ou importantes ; l'art. 26 ajoute un TLPT au moins tous les trois ans pour les entités identifiées. Voir les tests d'intrusion DORA au-delà du TLPT.
• NIS2, art. 21(2)(f) : des politiques et procédures pour évaluer l'efficacité des mesures de gestion des risques, sans fréquence fixée. En Italie, l'Allegato 2 de l'ACN impose aux entités essentielles de réaliser périodiquement et avant la mise en production des évaluations de vulnérabilités et/ou des tests d'intrusion. Voir obligations et échéances NIS2.
• NIST SP 800-53 Rev. 5, CA-8 : des tests d'intrusion à une fréquence définie par l'organisation.

Le schéma : un plancher annuel, et des tests après tout changement significatif. Si les changements sont hebdomadaires, les tests doivent l'être aussi.

1. 1Surface d'attaque externe : chaque semaine. Les services exposés à Internet changent le plus vite et sont attaqués en premier.
2. 2Réseau interne et Active Directory : chaque mois, depuis une position de compromission présumée (assumed breach) avec un compte utilisateur ordinaire (boîte grise).
3. 3Après chaque changement significatif : nouveau site, fusion, version majeure, changement de pare-feu ou de fournisseur d'identité.
4. 4Après une inscription KEV pertinente : testez les systèmes concernés tant que le correctif est en attente, puis à nouveau après son application. Voir le playbook de correctif d'urgence KEV.
5. 5Avant la mise en production d'un système pertinent, comme les règles NIS2 italiennes l'exigent des entités essentielles.
6. 6Après chaque correction : relancez le même test pour clore le constat avec des preuves.
7. 7Une fois par an : un test mené par des humains sur la logique métier, les applications sur mesure et tout ce que la réglementation réserve à des testeurs qualifiés.

Les prix publics sont rares, mais les modèles sont clairs et déterminent ce que vous coûtera le test continu :

• Crédits ou heures de testeur (PTaaS). Vous achetez une réserve de temps de test. Cobalt, par exemple, vend des crédits valant chacun huit heures de pentest. Tester plus souvent signifie acheter davantage de crédits.
• Abonnements par fenêtre de test. Un nombre fixe de tests ou une période de test par an, parfois avec une surveillance continue entre les deux.
• Licence annuelle (plateformes autonomes). Tarifée par actifs, adresses IP ou sites, avec des exécutions illimitées. Ici, tester chaque semaine coûte autant que tester chaque mois, ce qui rend une fréquence élevée abordable.

Lorsque vous comparez des devis, chiffrez la fréquence dont vous avez besoin, pas celle de la brochure : 52 exécutions externes et 12 exécutions internes par an, plus les retests. Plus de détails dans le coût du pentest automatisé.

• Qui ou quoi exécute chaque test ? Une personne, un logiciel, ou un logiciel dont une personne vérifie les résultats ?
• Que signifie « continu » dans le contrat ? Nombre d'exécutions par mois, retests inclus, tests après changement sur demande ?
• Peut-il tester le réseau interne et Active Directory, ou seulement les actifs exposés à Internet ?
• Où vont les constats, les identifiants et les preuves ? Cloud du fournisseur, région de votre choix, ou vos propres locaux ?
• Comment le périmètre est-il appliqué, et qui peut arrêter un test immédiatement ?
• Quelles preuves accompagnent chaque constat, et un retest prouve-t-il la correction ?
• À quelles réglementations les rapports sont-ils rattachés, et cela inclut-il celles auxquelles vous êtes soumis ?

Le guide d'évaluation transforme ces questions en plan de pilote.

Quelle est la différence entre le test d'intrusion continu et le PTaaS ? Le PTaaS est un mode de livraison : des testeurs humains sur une plateforme, achetés sous forme d'abonnement. Le test d'intrusion continu est l'objectif de tester aussi souvent que les choses changent ; le PTaaS est une façon d'y parvenir, un logiciel de test autonome en est une autre.

Le test d'intrusion continu est-il la même chose qu'un scan de vulnérabilités ? Non. Un scanner liste ce qui pourrait être vulnérable. Un test d'intrusion, continu ou non, tente de l'exploiter et d'enchaîner les constats en chemins d'attaque. Voir évaluation des vulnérabilités ou test d'intrusion.

Le test continu remplace-t-il le pentest annuel ? Pour la couverture et la fréquence, il le peut ; pour la profondeur sur la logique métier et les applications sur mesure, et là où une règle exige des testeurs qualifiés ou un TLPT, conservez un test mené par des humains.

Existe-t-il un standard pour le test d'intrusion continu ? Non. Le projet OWASP qui porte ce nom n'a rien publié depuis 2022. Pour les plateformes autonomes, l'OWASP Autonomous Penetration Testing Standard couvre le périmètre, la sécurité, la supervision humaine et les preuves.

Comment Zero Hunt réalise-t-il le test d'intrusion continu ? Zero Hunt est une red team IA autonome pour les réseaux et les infrastructures, sur une appliance on-premise dotée de ses propres modèles, de sorte qu'aucune donnée client n'en sort. Les campagnes s'exécutent une fois, chaque jour, chaque semaine, chaque mois ou selon un calendrier personnalisé, en boîte noire ou en boîte grise, et un opérateur peut en lancer une après un changement. Une nouvelle exécution après correction démontre la clôture avec des preuves signées. Cinq niveaux d'autonomie déterminent quelles actions attendent un opérateur, le périmètre est validé sur les appels d'outils et dans les scripts générés, et les constats sont mis en correspondance avec 34 référentiels de conformité dans le monde. Zero Hunt ne publie pas encore de résultats de benchmark ; sa méthodologie d'évaluation est en préparation.