Énoncé du problème :

Les outils de sécurité infonuagique promettent souvent une meilleure visibilité, mais créent plutôt une fatigue des alertes. Lors de notre déploiement initial de CSPM, 6 000 constatations ont été générées, dont 95 % étaient acceptées comme risques ou atténuées dans le contexte, plutôt que des risques exploitables. Le coût le plus élevé n'était pas le volume d'alertes, mais l'érosion de la confiance entre les équipes de sécurité et d'ingénierie.

Impact sur l'entreprise

• Efficacité opérationnelle : Le temps passé par l'équipe de sécurité sur des faux positifs est passé d'environ 40 heures par semaine à moins de 2 heures, ce qui a considérablement réduit la fatigue des alertes pour les équipes de sécurité et d'ingénierie
• Optimisation des coûts : Environ 1 000 $ par mois de dépenses évitables ont été éliminés grâce à la suppression de règles redondantes et d'outils dupliqués. Un montant supplémentaire de 8 000 $ par mois a été économisé en ressources cloud inutilisées, dont des passerelles NAT inactives et des instances EC2 et RDS dormantes
• Position de conformité : L'effort de préparation aux audits a été considérablement réduit, avec des améliorations correspondantes dans les résultats de conformité

Perspective stratégique : La maturité en sécurité infonuagique ne se mesure pas au volume d'alertes, mais à la qualité des signaux, à la qualité de la collaboration avec les équipes d'ingénierie et à la capacité de la sécurité à soutenir les objectifs d'affaires. Les outils de sécurité devraient accélérer la vélocité de développement, pas l'entraver.

Pourquoi est-ce important pour les organisations ?

Pour les dirigeants technologiques, il ne s'agit pas seulement d'un défi de sécurité, mais aussi d'un frein direct à la vélocité des affaires.

• Taxe sur la productivité des développeurs : Les ingénieurs passent 15 à 20 % de leur temps sur des faux positifs de sécurité
• Retards de migration vers le cloud : Les résultats de sécurité bloquent les déploiements en production
• Risque d'audit : Les outils trop ajustés passent à côté de vraies menaces tout en générant des alertes sur des enjeux mineurs ou peu significatifs
• Rétention des talents : À long terme, cette érosion de la collaboration peut aussi avoir un impact négatif sur la rétention des talents et l'efficacité organisationnelle

Jour zéro

L'activation d'une solution de gestion de posture de sécurité cloud (CSPM) semble simple en principe, mais présente en pratique une complexité importante. Lorsque l'outil X a été activé dans l’environnement AWS couvrant plus de 90 comptes, le déploiement initial, malgré les mesures de précaution, a généré environ 6 000 alertes.

Pourquoi nous en avions besoin :

Nous avions :

• 90+ comptes AWS couvrant des environnements de dev à production
• Architecture multi-région (États‑Unis principal, Singapour et Francfort pour les clients internationaux)
• Principaux services : EC2, RDS, Lambda, S3, ECS, EKS
• AWS Config et un outil CSPM tiers partiellement intégrés, mais pas adéquatement surveillés
• Nuage principal : AWS, avec une petite présence sur GCP

Les signaux de sécurité étaient fragmentés entre plusieurs outils, nécessitant une approche unifiée. En conséquence, les mauvaises configurations étaient souvent identifiées uniquement lors des audits, des semaines ou des mois après le déploiement, ce qui posait un risque inacceptable dans la gestion de renseignements de santé protégés.

Après avoir évalué plusieurs plateformes, nous avons choisi X (un pseudonyme, car ces apprentissages s'appliquent à n'importe quel outil). Cet outil a été retenu pour son balayage sans agent et, surtout, sa capacité à comprendre les contrôles natifs AWS mieux que les autres outils. Il offre aussi des capacités multicloud intégrées.

Bien que cet article fasse référence à une solution CSPM tierce, les services de sécurité AWS ont beaucoup évolué et constituent maintenant une solide alternative native. AWS Security Hub évolue pour devenir une plateforme unifiée d’opérations de sécurité, intégrant des services comme Amazon GuardDuty, Amazon Inspector, Security Hub CSPM et Amazon Macie afin d’analyser continuellement les menaces, vulnérabilités, mauvaises configurations et données sensibles. La plateforme élargit également son soutien aux environnements multicloud.

Mois un :

Environ 70 % des alertes étaient liées à IAM. X signalait des rôles comme « trop permissifs », « peuvent escalader les privilèges » ou « inutilisés depuis x jours », entre autres. Ces alertes étaient techniquement exactes mais pratiquement inadaptées.

Nous avons collaboré avec l’équipe Customer Success de X pour activer l’« analyse des permissions effectives ». Cette fonctionnalité a permis à X de comprendre notre modèle de sécurité par couches. Rapidement, nous sommes passés de 4 200 alertes IAM à 750 ; la plupart portaient sur des rôles inutilisés. Nous avons fourni des rôles standards et des utilisateurs IAM aux équipes applicatives, avec des garde-fous comme les boundaries de permissions et les SCP. Leur sévérité a été réduite et elles ont été éliminées progressivement après analyse approfondie.

Les seaux S3 :

Nous avions environ 300 alertes pour des « seaux S3 accessibles publiquement ».

Ces constatations relèvent de quatre catégories :

• Seaux de comptes sandbox étiquetés DataClassification : Public utilisés pour des ensembles de données de démonstration
• Seaux d’hébergement de sites statiques : Plusieurs ont été nettoyés par la suite, et un processus de nettoyage a été mis en place
• Seaux d’origine CloudFront, où l’accès public n’était pas nécessaire. Pour les distributions CloudFront utilisant Origin Access Control (ou l’ancien Origin Access Identity), les seaux d’origine S3 devaient demeurer privés, avec un accès restreint à CloudFront via des politiques de seaux. Tout accès public détecté sur de tels seaux était donc une mauvaise configuration légitime et non un faux positif, et a été corrigé
• Seaux de production exposés publiquement par inadvertance, traités comme des découvertes critiques et corrigés immédiatement

Nous avons personnalisé la politique pour ajouter du contexte :

SI le seau est une origine CloudFront ET possède OAI/OAC → Sévérité moyenne

SI le seau est un site web statique ou est dans un sandbox ET étiqueté Public → Info seulement

SI le seau est en production ET public → Critique

Ce raffinement des politiques a considérablement réduit le bruit tout en maintenant des protections là où c’était essentiel. Ces alertes concernaient des ressources créées dans quelques comptes ayant permis l’accès public ; il s’agissait de comptes DMZ dotés de mécanismes comme Shield Advanced. La majorité des comptes AWS demeuraient strictement privés.

Le combat du chiffrement :

X exigeait que tous les volumes EBS soient chiffrés avec des clés gérées par le client (CMK). Cependant, la norme de l’organisation est d’activer par défaut le chiffrement géré par AWS au niveau du compte pour tous les comptes privés ; c’est sécuritaire et économique.

Compte tenu de la classification des données et des contrôles compensatoires, le chiffrement géré par AWS offrait une protection adéquate et les avantages additionnels des CMK ont été évalués et acceptés comme risque résiduel par l’organisation.

Nous avons désactivé les politiques qui contredisaient nos standards de sécurité documentés. Quelques autres politiques similaires visant d’autres ressources ont aussi été désactivées.

Mois deux :

Nettoyer l’arriéré était une chose. Prévenir son retour en était une autre.

• Le correctif Terraform :

  Nous avons observé un motif : plus de 40 nouvelles alertes par semaine pour « seaux S3 sans versionnage activé ».

  La cause principale était que le module Terraform S3 rendait le versionnage optionnel. Les développeurs créaient des seaux et oubliaient d’activer le versionnage, générant une alerte. Pour corriger, le code a été modifié afin de rendre le versionnage par défaut.

  Les seaux sont sécurisés par défaut. Les développeurs doivent explicitement désactiver (ce qui nécessite une approbation sécurité). Flux d’alertes : arrêté.

  Le versionnage augmente aussi les coûts. Nous avons également ajouté une politique de cycle de vie par défaut pour supprimer les anciennes versions, laquelle tenait compte de l’étiquette d’environnement et était harmonisée avec la politique de sauvegarde de l’organisation.

  C’est devenu la norme. Corriger l’usine, pas les produits.

• Sync bi-hebdomadaire :

  Nous avons démarré des réunions bi-hebdomadaires avec l’ingénierie plateforme et DevOps pour repérer des motifs, corriger les modules et arrêter les alertes. Cela a évolué vers un modèle opérationnel de sécurité et fait partie intégrante du cadre de gouvernance.

• Détection des menaces :

  Nous avons activé la détection des menaces de X et avons aussitôt été bombardés d’alertes « emplacement de connexion inhabituel ». Nous n’étions pas compromis. C’était Zscaler.

  Nos portables corporatifs passent par la passerelle web sécurisée mondiale de Zscaler. Les journaux CloudTrail montraient nos ingénieurs « se connecter » depuis l’un ou l’autre des nœuds de sortie Zscaler, ce qui était normal.

  La solution a été de mettre sur liste blanche les plages IP de Zscaler, ce qui a éliminé plus de 100 faux positifs hebdomadaires.

Les erreurs :

• Suppression automatisée de rôles

  On a supprimé :

  • Un rôle de rapport financier trimestriel (dernière exécution : il y a 58 jours)
  • Un rôle de pipeline de publication mensuel

  Même si ceci a été fait après de multiples courriels à une DL où étaient les équipes applicatives, les gens n’y ont pas prêté attention. C’est un autre défi : obtenir l’engagement des gens, que nous avons résolu par des réunions bi-hebdomadaires.

  Leçon : période d’ancienneté minimale de 90 jours. Balises d’exclusion pour les rôles critiques. « Suppression douce » de 14 jours (désactiver, ne pas supprimer), avec notifications.

• La base de données non chiffrée oubliée

  Toutes nos instances RDS sont chiffrées parce que nous appliquons un SCP. Nous avons rétrogradé toutes les constatations de chiffrement de élevé à faible.

  Nous avions une instance RDS dans un compte sandbox datant d’avant l’existence du SCP. Elle contenait une copie de données production non chiffrées. Un ingénieur avait certes examiné cela avec Config, mais manqué cette instance ; en fait, le compte sandbox n’était pas correctement intégré à Control Tower, ce que nous avons découvert durant un audit.

  C’était aussi un échec au niveau du balisage et de la gouvernance des données : cette RDS n’avait pas la bonne étiquette DataClassification.

Phase de rationalisation :

Après trois mois, les choses se sont rationalisées.

• ~10 nouvelles constatations par semaine (contre plus de 200)
• ~1 alerte critique par semaine en moyenne, enquêtée et traitée immédiatement
• ~1-2 alertes de haute sévérité traitées rapidement
• Alertes moyennes/faibles groupées en sprints de remédiation bi-hebdomadaires
• Les billets étaient automatiquement dirigés vers diverses équipes via l’outil de gestion des billets. Tout le monde a été sensibilisé aux politiques de sécurité via les réunions bi-hebdomadaires

Pré-requis :

• AWS Organizations avec une structure de comptes claire
• Stratégie de balisage de base (environnement, application, propriétaire, classification des données au minimum)
• Processus de gestion du changement

Fortement recommandé :

• Politiques de contrôle de service
• Infrastructure as Code (Terraform/CloudFormation)
• Journalisation centralisée

À avoir idéalement :

• Limites d’autorisations
• Métriques de sécurité existantes (pour comparaison avant/après)

À noter

• Le contexte l’emporte sur la couverture. N’activez pas toutes les politiques dès le jour 1. Commencez avec la production et les contrôles critiques, puis élargissez graduellement
  • Contexte des contrôles (SCP, limites d’autorisations)
  • Contexte des données (balises de classification)
  • Contexte de l’environnement (prod vs sandbox)
  • Contexte du réseau (DMZ vs privé)
• Un haut volume d’alertes n’indique pas nécessairement une meilleure gestion du risque. Moins d’alertes avec une densité de signaux de risque plus élevée est signe de maturité
• Bâtissez une relation avec Customer Success. Nous faisions des rencontres mensuelles avec X pour voir les nouvelles fonctionnalités et donner de la rétroaction
• Corrigez les usines, pas les produits. La mise à jour des modules Terraform prévient des milliers d’alertes futures. L’envoi individuel de tickets de remédiation ne le fait pas
• Automatisez avec précaution. Nous remédions automatiquement aux tâches à faible risque (groupes de sécurité inutilisés après 90 jours). Les humains doivent toujours approuver les changements IAM et les modifications en production
• La culture l’emporte sur la technologie. Le meilleur outil de sécurité au monde échoue si les ingénieurs ne vous font pas confiance. Avoir des discussions ciblées est essentiel

La sécurité est plus efficace lorsqu’elle est fiable, discrète et cohérente. L’objectif n’est pas l’élimination des alertes, mais la livraison de signaux précis à des degrés de sévérité appropriés, avec une responsabilisation claire pour la remédiation.