Pourquoi la validation de sécurité devient-elle agentique?
Les faits
Dans de nombreuses grandes organisations, l'architecture de sécurité ressemble à un assemblage d'outils spécialisés qui cohabitent sans parler entre eux. Il y a des solutions BAS pour l'émulation d'attaques, des pentests ponctuels, des outils de pentesting automatisés, et des scanners de vulnérabilités qui alimentent des plateformes de gestion de la surface d'attaque. Chaque élément montre une partie du tableau, mais l'absence d'interopérabilité crée des angles morts. C'est dans ce contexte qu'apparaissent des plateformes de validation capables d'agir de manière autonome pour combler ces lacunes.
Observations clés :
- Les plateformes modernes centralisent l'émulation d'attaques, les tests de configuration et la vérification des contrôles de détection, et automatisent les corrections via API et agents déployés en cloud et on-prem.
- L'approche "agentic" regroupe des systèmes qui orchestrent, déclenchent et parfois remettent en état, avec des boucles de rétroaction automatisées, au-delà de la simple génération de rapports¹.
- La matrice MITRE ATT&CK sert de langage commun pour définir des scénarios d'adversaire, ce qui facilite l'automatisation et la comparaison entre outils et équipes².
Exemple opérationnel :
- Déclenchement : un pipeline CI/CD lance un jeu d'émulation basé sur ATT&CK après chaque déploiement.
- Observation : l'EDR et le SIEM collectent la télémétrie en temps réel.
- Orchestration : la plateforme corrèle événements et règles pour vérifier que les détecteurs ont levé des alertes pertinentes.
- Remédiation : si une règle est insuffisante, un runbook SOAR propose ou applique une correction testée sur un environnement canari.
Contexte

Pourquoi cette transformation survient maintenant
- Accumulation d'outils point à point : les équipes sécurité ont empilé des solutions pour la découverte, le scanning, le pentest et la gestion de la surface d'attaque, engendrant des silos exploitables par des attaquants.
- Besoin de validation continue : les architectures cloud et les cadences de livraison rapides rendent la validation ponctuelle obsolète ; l'infrastructure dérive et change trop vite pour s'en remettre à des audits sporadiques.
- Standardisation des techniques d'émulation : l'adoption de matrices comme MITRE ATT&CK a permis de normaliser les scénarios d'attaque et de les automatiser².
Technologies qui ont rendu l'agentic possible
- API et orchestration : l'usage généralisé d'API REST/GraphQL et d'outils d'infrastructure as code facilite l'intégration des tests dans les pipelines CI/CD.
- Agents légers : les agents EDR/XDR peuvent être utilisés en mode lecture-écriture dans des environnements isolés pour simuler des comportements d'attaquants.
- IA et corrélation dynamique : des modèles de corrélation et de machine learning aident à réduire le bruit et à prioriser les scénarios à exécuter.
Impact économique et risques
- Coût des incidents : le coût moyen d'une violation reste élevé, poussant les organisations vers des validations continues. Selon IBM, le coût moyen d'une brèche en 2023 était d'environ 4,45 millions de dollars³.
- Risques opérationnels : un agent mal configuré peut entraîner des tests destructifs, exposer des identifiants de test ou déclencher des mécanismes de résilience, provoquant des effets en cascade.
Réactions et conséquences
Fournisseurs et pratiques opérationnelles
- Évolution des produits : les éditeurs de BAS étendent leurs plateformes avec des connecteurs pour SIEM, SOAR et CMDB, des catalogues de scénarios ATT&CK et des API d'atténuation automatisée.
- Gouvernance renforcée : les équipes ajoutent des couches de gouvernance autour des agents, exigeant des approbations humaines pour les actions effectives, et exécutent les scénarios à portée restreinte sur des environnements canaris.
Conséquences opérationnelles
- Gains : une validation intégrée à la chaîne de déploiement et à l'observabilité réduit le temps de détection et de remédiation (MTTR) lorsque les scénarios sont bien calibrés.
- Limites : sans télémétrie suffisante ou calibration fine, la multiplication des faux positifs et faux négatifs reste un problème. Réglages continus entre équipes red, blue et DevOps sont nécessaires.
Conséquences réglementaires et juridiques
- Traçabilité : les actions automatisées doivent être horodatées et auditées ; en l'absence de preuves, les audits peuvent devenir compliqués.
- Protection des données : les tests ne doivent jamais exposer de données réelles ; l'utilisation d'environnements et d'identifiants éphémères est impérative pour rester conforme.
Nouvelles menaces
- Compromission d'un agent : un agent de validation compromis offre un vecteur d'orchestration à un attaquant. Limiter les privilèges et segmenter l'accès sont indispensables.
- API comme cible : les interfaces d'orchestration doivent être protégées par une authentification forte, des quotas, et des journaux immuables.
Mesures opérationnelles recommandées
Principes de gouvernance
- Registre des agents : cataloguez les agents, leurs permissions et leurs cas d'usage autorisés.
- Séparation des modes : distinguez clairement "simulation" et "action". Le mode action requiert une approbation humaine ou un seuil de confiance multiple.
- Isolation des tests destructifs : exécutez-les uniquement sur canaris ou sur des répliques contrôlées.
- Gestion des secrets : utilisez des coffres temporaires et générez des identifiants éphémères pour les exercices.
- Boucle de purple teaming : intégrez les retours des exercices à la définition des règles de détection et aux playbooks SOAR.
Contrôles techniques
- Principe du moindre privilège pour les agents.
- Journaux immuables et horodatés pour toute action déclenchée par un agent.
- Revue et tests réguliers des API d'orchestration pour détecter les abus.