*Par [Sila Ozeren Hacioglu](https://www.linkedin.com/in/silaozeren/), ingénieure en recherche de sécurité chez **Picus Security**.* L'enthousiasme initial entourant les outils automatisés de tests d'intrusion est souvent suivi d'une période de rendements décroissants. Le tableau de bord s'illumine initialement de découvertes critiques, de chemins de mouvement latéral et de vulnérabilités de comptes de services hérités. L'équipe Rouge se sent habilitée, et le CISO pense que "l'élément humain" a été automatisé. Mais la lune de miel prend fin. Dès la quatrième ou cinquième exécution, les nouvelles découvertes se font rares. L'outil commence à signaler les mêmes problèmes obsolètes, et le tableau de bord autrefois brillant devient juste une autre source de bruit. Ce phénomène est connu sous le nom de **Fossé de Validation** : la disparité croissante entre ce que les organisations valident réellement et ce qu'elles déclarent comme validé. Si votre outil de tests d'intrusion automatisé semble promettre plus qu'il ne livre, vous êtes témoin d'un changement sur le marché. L'industrie réalise que si les tests d'intrusion automatisés sont une *fonctionnalité* puissante, c'est une *stratégie dangereuse lorsqu'elle est utilisée isolément*. ## Le précipice du POC : où la découverte va mourir Le schéma d'une première exécution passionnante suivie de rendements significativement décroissants n'est pas anecdotique. Les professionnels de la sécurité appellent cela le **Précipice de la Preuve de Concept (PoC)** : la chute abrupte de nouvelles découvertes une fois que l'outil a épuisé son périmètre fixe. Ce n'est pas un problème de réglage. Par conception, les solutions de tests d'intrusion automatisés donnent leurs meilleurs résultats lors de la première exécution. En quelques cycles, les chemins exploitables dans leur périmètre sont épuisés. Cependant, cela ne signifie pas que votre environnement est sécurisé ; cela signifie simplement que l'outil a atteint ses limites, tandis que des problèmes plus profonds restent non testés. C'est le plafond structurel d'un outil opérant contre une surface déterministe. C'est une limitation architecturale, pas opérationnelle. Les tests d'intrusion automatisés enchaînent leurs étapes. L'étape B dépend de l'étape A, et l'étape C dépend de l'étape B. Une fois que vous corrigez le chemin spécifique que l'outil privilégie, il est bloqué à l'étape A, et les étapes B à Z ne s'exécutent jamais. L'outil peut tester 20 techniques de mouvement latéral, mais s'il est bloqué tôt dans la chaîne, ces techniques restent dans l'ombre. Vous avez le faux sentiment "mission accomplie" pendant que le reste de votre surface d'attaque reste inexploré. C'est là que la **Simulation d'Attaques et de Compromissions (BAS)** trace une ligne dure. La BAS ne fait pas de chaînage ; elle exécute des milliers de simulations atomiques indépendantes. Chaque technique bénéficie de sa propre exécution propre. Un test d'exfiltration bloqué via DNS n'empêche pas de tester l'exfiltration via HTTPS ensuite. Une technique de mouvement latéral échouée n'empêche pas l'outil de tester 19 autres. L'un teste le chemin. L'autre teste le bouclier. ## Clarifier les choses : BAS vs. Tests d'intrusion automatisés Pour mieux comprendre le "pourquoi" du précipice du PoC, nous devons aborder un point de confusion croissant dans l'industrie. Bien que la Simulation d'Attaques et de Compromissions (BAS) et les tests d'intrusion automatisés partagent l'objectif général de validation, ils utilisent des méthodes différentes pour répondre à des questions différentes. Considérez la BAS comme une série de mesures indépendantes. Elle émule en continu et en toute sécurité des techniques d'adversaires, des payloads de malware, des mouvements latéraux et des exfiltrations, pour vérifier si vos contrôles de sécurité spécifiques (pare-feux, WAF, EDR, SIEM) font réellement leur travail. Sa mission principale est de tester si vos défenses bloquent ou alertent sur les comportements de menace connus. Chaque test est indépendant pour vérifier la force de votre défense. Les tests d'intrusion automatisés, en revanche, sont directionnels. Ils adoptent une approche plus chirurgicale et adversariale en chaînant des vulnérabilités et des mauvaises configurations comme le ferait un véritable attaquant. Ils excellent à exposer des chemins d'attaque complexes, tels que le Kerberoasting dans **Active Directory** ou l'escalade de privilèges pour atteindre un compte d'administrateur de domaine. Bien que les deux soient souvent considérés comme des "méthodes de validation", les deux sont fondamentalement différents dans leur mission et leurs résultats. L'un vous dit à quel point vos défenses individuelles sont solides ; l'autre vous dit jusqu'où un attaquant peut aller malgré elles. ## Le piège de la "simplicité" : pourquoi les tests d'intrusion ne sont pas la BAS Récemment, certains fournisseurs ont proposé l'idée que les tests d'intrusion automatisés peuvent, et devraient, remplacer la BAS. Sur le papier, cela semble formidable. En réalité, ce n'est pas une amélioration ; c'est une régression de couverture déguisée en simplification. Comme nous venons de le voir, les tests d'intrusion automatisés et les outils BAS répondent à des questions fondamentalement différentes. Pour sécuriser une entreprise moderne, vous avez besoin des réponses aux deux : * **La BAS demande :** "Mes pare-feux, EDR, WAF et SIEM font-ils réellement leur travail sur l'ensemble du framework **MITRE ATT&CK** ?" Elle se concentre sur l'*efficacité* de vos contrôles défensifs. * **Les tests d'intrusion automatisés demandent :** "Un attaquant peut-il aller du point A au point B en utilisant des exploits connus ?" Elle se concentre sur le *succès* de chemins d'attaque spécifiques.  **Figure 1. Exemple de scénario de chaîne d'attaque : ce que valident les tests d'intrusion automatisés et la BAS** Si vous remplacez les évaluations BAS par des tests d'intrusion automatisés, vous cessez de valider votre pile de prévention et de détection. Vous pourriez savoir qu'un attaquant ne peut pas atteindre votre base de données via un exploit spécifique, mais vous n'avez aucune visibilité sur le fait que votre EDR réagirait, même si l'attaquant essayait une technique différente, non exploitable. ## Les six angles morts de la surface d'attaque moderne Bien que les supports marketing promettent une couverture "complète", la réalité est que les tests d'intrusion automatisés ne font généralement qu'effleurer la surface des chemins d'infrastructure et d'application.  **Figure 2. Six couches de la surface d'attaque d'une organisation** Comme illustré ci-dessus, deux surfaces ne reçoivent aucune couverture de la part des tests d'intrusion automatisés. Quatre reçoivent une couverture partielle au mieux. Pas une seule surface n'est entièrement couverte. Cela représente 0 sur 6 validés complètement. Cela crée un fossé de validation massif où se produisent les brèches actuelles : 1. **Contrôles réseau et terminaux :** Les chemins d'exploit sont identifiés, mais il n'y a aucune confirmation que les pare-feux, WAF, IPS, DLP ou EDR bloquent réellement les menaces qu'ils sont censés arrêter. Les contrôles échouent silencieusement, et "configuré" est confondu avec "efficace". 2. **Pile de détection et de réponse :** Les tests d'intrusion automatisés n'ont aucune visibilité sur le fait que les règles SIEM et la logique de détection EDR se déclenchent réellement. L'outil agit comme l'attaquant, il ne peut pas observer le défenseur. La couverture de détection est supposée, pas mesurée. 3. **Chemins d'attaque d'infrastructure et d'applications :** Ces tests atteignent souvent un "précipice du PoC". Bien que les chemins d'infrastructure soient cartographiés, les chaînes d'attaque complexes au niveau des applications varient en couverture et restent souvent ouvertes et disponibles pour les adversaires. 4. **Identité et privilèges :** Les chemins existants sont parcourus, mais il n'y a pas de validation systématique des configurations Active Directory, des politiques IAM et des limites de privilèges. 5. **Environnements cloud et conteneurs :** Les politiques dynamiques Kubernetes et les contrôles de sécurité cloud restent souvent dans l'ombre et non revalidés à mesure que les configurations changent. La visibilité sur les mauvaises configurations et les dérives de politiques est supposée, pas testée activement. 6. **IA et apprentissage automatique :** Les tests d'intrusion automatisés ne valident pas l'efficacité des outils de sécurité pilotés par l'IA ni n'identifient les vulnérabilités dans les modèles d'IA. Cela laisse un angle mort important face aux attaques de plus en plus sophistiquées basées sur l'IA.