Prioriser les risques avec un attaquant simulé : Security Command Center et son jumeau numérique

Le scénario de départ est de ceux qu'on reconnaît immédiatement. Une entreprise de e-commerce en pleine croissance, Cymbal, lit dans les actualités comment les attaquants enchaînent plusieurs configurations incorrectes mineures pour finir par accéder à une base de données clients critique. Le CISO, Ira, demande à son ingénieure cloud sécurité, Ariel, une question très précise : existe-t-il une ligne directe depuis l'extérieur jusqu'aux bijoux de la couronne ? Et un délai tout aussi précis : un risk report le même jour.

La source de ce texte est « Security Command Center: Identify and Prioritize Risks », de Google Skills, et ce qu'il enseigne sert pour tout environnement Google Cloud où la liste des vulnérabilités est plus longue que le temps de l'équipe. Le fil qui suit est le parcours d'Ariel : déclarer quels actifs valent de l'or, laisser une simulation d'attaque tourner contre un jumeau numérique de l'environnement, lire les routes qu'elle renvoie et remédier par ordre d'impact.

Virtual red teaming : l'attaquant qui ne se repose jamais

Le moteur de tout est le virtual red teaming de Security Command Center (SCC, le service de sécurité de Google Cloud) : une simulation qui imite un attaquant externe motivé et expérimenté cherchant quatre choses — un point d'entrée, des ressources affectées et exploitables, des ressources de haute valeur exposées, et le rayon d'explosion possible d'une attaque.

La première décision de conception porte sur ce sur quoi cela tourne. La simulation crée un modèle de jumeau numérique de l'environnement cloud avec les informations de configuration, les données de vulnérabilités et les permissions des comptes de service. Sans applications ni données réelles. Le matériel l'insiste : zéro impact sur la performance ou les opérations. Générer le modèle prend entre 6 et 24 heures selon la taille et la complexité de l'environnement, et à partir de là la simulation tourne en continu sur le modèle, avec des cycles du même ordre.

flowchart TD
    O[Organisation avec politiques et rôles IAM] --> T[Niveau Premium ou Enterprise]
    T --> M[Jumeau numérique : configuration, vulnérabilités et permissions]
    M --> C[Cycle de simulation toutes les 6 à 24 heures]
    C --> R[Routes d'attaque avec exposure score]
    R --> M

La seconde décision est l'échelle. Une fois le modèle généré, la simulation exécute l'attaquant avec les dernières tactiques, techniques et procédures (TTP) à l'échelle de la machine, en calculant des millions de permutations d'attaque. Aucune personne ne peut parcourir cela à la main, et c'est exactement le point : la priorisation cesse de dépendre de quelles vulnérabilités quelqu'un a réussi à regarder avec la liste ouverte.

Ce qu'il faut pour l'activer

Trois prérequis, et aucun n'est mineur. Niveau Premium ou Enterprise de Security Command Center, pour les capacités complètes du modèle de cloud et du virtual red teaming. Une organisation avec des politiques d'organisation définies, car la fonction travaille au niveau organisation et non au niveau projet. Et un ensemble précis de rôles IAM dans l'organisation pour travailler avec la resource value configuration ; sans les bons rôles, certaines fonctions de l'interface ne sont tout simplement pas disponibles.

Déclarer ce qui a de la valeur

C'est la partie qui décide si la simulation sert à quelque chose. Sans configuration propre, SCC utilise un ensemble prédéfini de ressources de haute valeur comme ligne de base, avec une priorité LOW pour tout cet ensemble ; si le service de découverte Sensitive Data Protection est activé, les ressources avec des données de sensibilité moyienne ou élevée reçoivent MEDIUM ou HIGH. L'avertissement du matériel est direct : les résultats peuvent ne pas s'aligner sur les actifs réels de l'entreprise.

La configuration personnalisée (resource value configuration) définit les ressources de haute valeur par attributs : type de ressource, tag, label de projet et projet, dossier ou organisation parent. Les types de ressources du déployable sont peuplés depuis Cloud Asset Inventory, de sorte que la liste démarre avec ce que l'environnement possède réellement.

Et apparaît ici la limite dure : 1 000 ressources de haute valeur. La simulation ordonne les ressources de haute à moyenne puis basse priorité, et rejette tout ce qui dépasse la limite. La bonne pratique est de maintenir la liste concise et ciblée, d'utiliser une stratégie de tagging et de définir la liste par type d'actif, environnement ou besoins réglementaires, plutôt que par configuration.

Les valeurs de priorité reflètent l'importance : élevé pour les charges de travail critiques du métier, moyen ou bas pour les autres ressources importantes. Et il y a « none », la décision dont il faut être très sûr : la ressource cesse d'être considérée comme de haute valeur et SCC annule toute autre configuration de valeur qu'elle aurait.

L'erreur typique que le matériel nomme explicitement : inclure des ressources adjacentes, comme un jump server, dans la liste de haute valeur. La simulation prend déjà en compte ces ressources en calculant les routes ; les designer de haute valeur rend la priorisation des problèmes moins efficace.

Dans la console, le parcours est Security Command Center → Settings → SCC Settings → onglet Attack Path Simulations, créer la configuration, fixer les valeurs de priorité et, optionnellement, utiliser Discovery insights avec Sensitive Data Protection pour attribuer des priorités automatiques aux ressources de données compatibles.

Lire le modèle de routes d'attaque

Les résultats arrivent en attack paths. Le Risk Engine génère le réseau de routes d'attaque potentielles et assigne à chacune un exposure score basé sur les valeurs de priorité définies.

La lecture se fait sur la page Risk Overview, qui montre les cinq problèmes les plus critiques, ordonnés selon les valeurs de priorité, sur une représentation visuelle de l'environnement. En cliquant sur un problème, le modèle se concentre sur ce constat et sa route ; les icônes de ressource montrent des détails et les lignes montrent comment l'attaquant voyagerait.

Deux façons de regarder le graphe résolvent presque tout ce qu'il faut décider. Beaucoup de lignes vers une seule ressource indiquent un chokepoint : un présent sur plusieurs routes d'attaque. Beaucoup de ressources groupées indiquent une combinaison toxique : un groupe de problèmes qui crée un chemin pour l'attaquant vers les ressources de haute valeur, comme des bases de données avec des informations clients sensibles ou des machines virtuelles avec des applications critiques.

La sévérité (critique, élevée ou moyenne) est attribuée selon le nombre de ressources de haute valeur exposées, leur priorité et la probabilité qu'un attaquant donné y parvienne via un chokepoint ou une combinaison toxique, et les chokepoints sont toujours considérés comme critiques. L'exposure score combine les valeurs de priorité avec le nombre de fois où l'attaquant simulé est arrivé à la ressource de haute valeur.

Un détail opérationnel qui évite des discussions : les changements de priorité ou d'actifs critiques ne se voient pas avant le cycle suivant. La simulation tourne sur le modèle, pas sur la console en direct.

flowchart LR
    P1[1. Chokepoints] -->|réduisent drastiquement le risque| E[Ressources de haute valeur]
    P2[2. Combinaisons toxiques] -->|ferment les chemins| E
    P3[3. Issues individuelles] -->|réduisent la surface| E

L'ordre de remédiation

Avec les constats en main, l'ordre compte autant que le constat. Les chokepoints d'abord : ils sont présents sur plusieurs routes d'attaque, leur élimination réduit drastiquement le risque et peuvent résoudre plusieurs combinaisons toxiques d'un coup. Ensuite, les combinaisons toxiques. Et à la fin, les issues individuelles : des occurrences isolées de risques significatifs avec sévérité moyenne, élevée ou critique, y compris les security graph-based issues, qui sont des combinaisons statiques prédéfinies et éditées.

L'affirmation contraire — résoudre les issues individuelles avant les combinaisons toxiques et les chokepoints — apparaît dans le matériel marquée comme fausse. C'est la preuve que l'ordre est une doctrine et non une suggestion de style.

Remédier sur la page Issues

La page Issues mène de la constatation à l'action. Son onglet Overview explique ce que l'attaquant a accompli, avec une section Evidence sur l'impact et le lien Explore full attack paths pour voir la route complète. L'onglet How to fix ? liste des recommandations de remédiation ordonnées de la plus simple à la plus complexe, avec des liens vers la documentation du Help Center pour approfondir chaque étape.

Cet ordre des recommandations est pratique : on peut enchaîner les remédiations fiables pendant que la plus complexe attend son tour d'examen.

Le risk report pour les parties prenantes

La demande d'Ira se conclut par un artefact concret. Le risk report se télécharge depuis le bas du menu de navigation gauche (Download Risk Report) et s'ouvre en PDF dans une nouvelle fenêtre, prêt à partager avec des parties prenantes qui ne vont pas naviguer la console.

Deux prérequis valent la peine d'être connus avant la réunion. Le premier est les permissions : il faut le rôle Risk report viewer (securitycenter.riskReportsViewer). Le second est la sensibilité : le rapport contient des données sensibles, chiffrer à la génération est donc recommandé.

Le rapport a cinq sections. Risk Engine introduction, avec le type de configuration utilisé, le type et le nombre de ressources de haute valeur et un résumé de l'exposition globale avec sa ventilation. Entry points and chokepoints, avec des graphes des points d'entrée communs, leur fréquence et les ressources exposées, plus le top des chokepoints. Toxic combination details, avec une combinaison toxique spécifique et des suggestions de remédiation. Toxic combinations, avec la vue d'ensemble et la ventilation des méthodes d'attaque les plus fréquentes. Et System attack exposure, avec l'exposure score et le pourcentage de ressources exposées dans le temps.

Cette structure est ce qui transforme une simulation technique en conversation d'affaires : le rapport commence par l'exposition globale et se termine par l'évolution dans le temps, ce qu'un CISO peut porter en comité.

Ce que le cadrage laisse et ce qui est resté non exécuté

Ce qui survit à tout changement d'interface, c'est la logique de priorisation : regarder où les routes convergent (chokepoints), ce qui se regroupe en chemin vers l'or (combinaisons toxiques) et ce qui reste isolé (issues), et résoudre dans cet ordre. La liste des vulnérabilités existe toujours ; ce qui change, c'est qu'elle a désormais le critère d'un attaquant devant elle.

Ce qui est resté non exécuté dans cette documentation : les quizzes n'ont ni été ouverts ni soumis ; les articles du Help Center mentionnés par le matériel (service tiers, ensemble prédéfini de ressources de haute valeur, Before you begin, valeurs de priorité et règles prédéfinies du security graph) n'ont pas été téléchargés, il faut donc les vérifier à la source officielle avant d'exploiter un tenant réel ; et les vidéos du cas s'appuient sur leurs transcriptions incluses dans les leçons.

---

*Source : « Security Command Center: Identify and Prioritize Risks », de Google Skills (cours google.scc-risks).*