English
Español
Français
Deutsch
日本語
한국어
العربيةL'Adversarial Exposure Validation pour AWS
Points clés
- L'adversarial exposure validation consiste à prouver quelles expositions un attaquant pourrait utiliser, en les testant comme un attaquant le ferait.
- Dans AWS, les mouvements de l'attaquant sont des appels d'API, donc valider signifie résoudre l'autorisation qui décide de chaque appel. Cela peut se faire en lecture seule, sans rien exécuter dans le compte.
- Les expositions qui méritent d'être validées dans AWS sont celles du plan de contrôle : escalade de privilèges IAM, confiance inter-comptes, identifiants exposés dans la configuration, et points d'entrée publics qui mènent à des rôles privilégiés.
- La plupart des éditeurs AEV ont commencé par les réseaux, les terminaux ou le breach and attack simulation, et chacun aborde le cloud depuis là. Demandez à chacun comment il produit des preuves dans le plan de contrôle AWS, et s'il résout les SCP, les boundaries et les politiques de confiance pour chaque étape.
- L'AEV est l'étape de validation d'un programme CTEM. Son résultat est une courte liste de chemins prouvés, chacun avec le changement qui le brise, et une confirmation une fois le changement déployé.
L'adversarial exposure validation, généralement abrégée en AEV, consiste à tester les expositions comme un attaquant le ferait, afin que l'équipe sécurité sache quels constats peuvent être utilisés et lesquels ne le peuvent pas. Gartner emploie ce terme pour une catégorie d'outils issus du breach and attack simulation et des tests d'intrusion automatisés. L'idée commune est que la validation ajoute des preuves à ce qu'un scanner rapporte, pour que l'équipe puisse agir sur les constats dont on a démontré qu'ils fonctionnent.
Cet article porte sur ce que cela signifie dans AWS en particulier, parce que le plan de contrôle du cloud change à la fois la méthode et le résultat.
Pourquoi AWS a besoin de sa propre forme de validation
Dans un réseau, valider une exposition signifie envoyer du trafic : l'outil peut-il atteindre l'hôte, s'authentifier, se déplacer. La preuve est une connexion réussie ou un identifiant capturé. Dans le plan de contrôle AWS, il n'y a pas d'hôtes à atteindre. Chaque mouvement de l'attaquant est un appel d'API, et la réussite d'un appel est décidée par un ensemble de documents de politique qu'AWS évalue ensemble : les politiques d'identité de l'appelant, une éventuelle permission boundary, les service control policies de l'unité organisationnelle du compte, la politique de confiance ou de ressource de la cible, et les clés de condition de chaque instruction.
Cela a deux conséquences. D'abord, un chemin peut être validé sans être exécuté, parce que résoudre ces documents en lecture seule produit le même allow ou deny que l'appel. Ensuite, un outil qui ne lit que les politiques d'identité surestimera la surface d'attaque, puisque les SCP et les boundaries retirent une large part de ce que les politiques d'identité semblent accorder.
Quoi valider dans AWS
Quatre types d'exposition représentent la plupart des chemins prouvés que nous voyons dans des comptes réels.
Escalade de privilèges IAM. Un principal doté d'une permission ou d'une combinaison qui lui permet d'atteindre un rôle plus privilégié : iam:PassRole avec une action de création de calcul, attachement de politiques et écriture de politiques inline, réécriture de politiques de confiance, création de clés d'accès. La carte d'escalade de privilèges AWS les liste avec l'événement CloudTrail et le changement qui brise chacune.
Confiance inter-comptes. Des rôles qui font confiance à un autre compte, à un fournisseur ou à un wildcard, où le côté qui fait confiance est privilégié et le côté de confiance est plus faible que quiconque ne le supposait. Une chaîne de deux ou trois sauts sts:AssumeRole peut relier un bac à sable à la production.
Identifiants exposés dans la configuration. Clés d'accès et jetons dans les user data EC2, les variables d'environnement Lambda, les sorties CloudFormation et les définitions de conteneurs. Une seule clé exposée devient le point d'entrée vers tout ce que le principal de la clé peut atteindre.
Points d'entrée publics. URL de fonctions, buckets publics avec accès en écriture, instances exposées sur Internet avec un profil d'instance, et API gateways qui invoquent un rôle privilégié. L'exposition n'est grave que si le rôle derrière mène quelque part, ce qui est exactement ce que la validation établit.
Ce qu'un outil AEV pour AWS devrait faire
Construire le graphe à partir d'une connexion en lecture seule, pour qu'il n'y ait aucun agent à déployer ni permission d'écriture à accorder. Raisonner sur le graphe pour produire des chaînes candidates, y compris à plusieurs sauts et inter-comptes. Valider chaque chaîne en évaluant chaque couche d'autorisation pour chaque étape, le résultat étant enregistré comme preuve. Classer les chemins prouvés selon ce qu'ils atteignent, pour que l'équipe voie d'abord le rayon d'impact. Pour chaque chemin, nommer le changement précis qui le brise, et une fois le changement déployé, réévaluer le chemin et confirmer qu'il a disparu. Tourner selon un calendrier, parce que les comptes dérivent.
Il y a deux choses qu'il n'a pas besoin d'être. Il n'a pas besoin d'exécuter quoi que ce soit dans le compte pour produire des preuves, parce que dans le plan de contrôle la preuve est le résultat de l'autorisation. Et il n'a pas besoin d'être le référentiel de tous les constats ; un CSPM ou un CNAPP s'en charge déjà, et le rôle de l'outil de validation est de vous dire lesquels de ces constats se trouvent sur un chemin prouvé.
Comment les principaux éditeurs AEV abordent AWS
Les éditeurs associés à la catégorie y sont venus de points de départ différents, et chacun a construit dessus. Le résumé ci-dessous décrit chacun dans les termes qu'emploient ses propres supports publics. Vérifiez les détails auprès de l'éditeur avant de décider quoi que ce soit sur cette base.
| Éditeur | Point de départ | Approche dans AWS |
|---|---|---|
| Pentera | Validation de sécurité automatisée sur les réseaux internes, les identités et la surface d'attaque externe | Un module cloud qui émule des techniques d'attaquant contre des comptes AWS et Azure, y compris la compromission d'identité et l'escalade de privilèges de rôle |
| Horizon3.ai | Tests d'intrusion autonomes depuis l'intérieur du réseau | Tests d'intrusion cloud qui exécutent des techniques d'attaque contre des environnements AWS et Azure |
| XM Cyber | Modélisation de graphes d'attaque et gestion continue des expositions | Modélisation des chemins d'attaque par graphe sur site et dans le cloud, avec analyse des points d'étranglement |
| Cymulate | Breach and attack simulation | Techniques d'attaque simulées pour tester les contrôles, avec des scénarios cloud aux côtés des terminaux et de la messagerie |
| Picus | Breach and attack simulation | Validation des contrôles par des techniques simulées, avec une couverture cloud ajoutée à la plateforme |
| Pathbreak | Chemins d'attaque du plan de contrôle AWS, conçu par des praticiens qui les ont trouvés à la main | Validation en lecture seule de chaque chemin par résolution de l'autorisation réelle, classement par rayon d'impact, le changement qui brise chaque chemin, et une confirmation après le correctif |
La distinction utile est entre la preuve par émulation de techniques et la preuve par résolution de l'autorisation. L'émulation convient naturellement là où l'exploit est du code contre un hôte. La résolution de l'autorisation s'applique là où l'exploit est une permission, ce qui dans AWS couvre l'essentiel du plan de contrôle, et parce qu'elle est en lecture seule, elle peut tourner chaque jour.
Où se situe l'AEV dans un programme CTEM
Le continuous threat exposure management comporte cinq étapes : cadrage, découverte, priorisation, validation et mobilisation. L'AEV est l'étape de validation. Son entrée est la liste priorisée issue de la découverte, et sa sortie est le petit ensemble d'expositions prouvées, chacune avec un responsable et un changement. L'article sur la validation CTEM montre à quoi cela ressemble dans un compte AWS avec des chiffres réels, et l'article AEV vs BAS couvre la différence avec le test des contrôles.
Questions fréquentes
Qu'est-ce que l'adversarial exposure validation ?
L'adversarial exposure validation consiste à tester les expositions de sécurité comme un attaquant le ferait, pour établir lesquelles peuvent servir à atteindre quelque chose d'important. Elle produit des preuves pour une courte liste d'expositions, là où un scanner produit une longue liste de tout ce qu'il peut voir. Pathbreak applique la validation adversariale de l'exposition à AWS et prouve chaque chemin d'attaque en lecture seule face à l'autorisation réelle.
L'AEV est-elle la même chose que le breach and attack simulation ?
Non. Le breach and attack simulation teste si les contrôles de sécurité détectent ou bloquent des techniques connues. L'AEV teste si un attaquant pourrait atteindre une cible via les expositions existantes, et quel changement l'en empêcherait. Beaucoup d'éditeurs AEV ont commencé dans le BAS, d'où la confusion entre les termes. Pathbreak est une plateforme AEV pour AWS : elle valide les chemins d'attaque et indique la modification qui casse chacun d'eux.
L'AEV exige-t-elle d'exécuter des exploits dans mon compte AWS ?
Pas dans le plan de contrôle. Dans AWS, chaque mouvement de l'attaquant est un appel d'API décidé par des documents de politique, donc résoudre ces documents en lecture seule donne le même allow ou deny que l'appel. Pathbreak valide de cette manière, sans rien exécuter.
À quelle fréquence la validation des expositions devrait-elle tourner dans AWS ?
Une fois par jour est une base raisonnable, parce que l'IAM et les relations de confiance changent à chaque déploiement. Une validation en lecture seule et automatisée peut tourner selon un calendrier sans fenêtre de changement. Pathbreak exécute cette validation chaque jour sur tous les comptes AWS connectés.
Voyez comment l'adversarial exposure validation fonctionne sur vos propres comptes AWS, sans rien exécuter.
Demander une démo Voir la démo