Perspective QSA : Évaluer les environnements CI/CD lors des évaluations PCI DSS
Alors que les Qualified Security Assessors (QSA) rencontrent des pipelines CI/CD avec une fréquence croissante dans les évaluations PCI DSS, le défi n’est pas de savoir si ces systèmes sont dans le périmètre — mais comment les évaluer efficacement. Les méthodologies d’évaluation traditionnelles étaient conçues pour des processus manuels de gestion des changements et une infrastructure statique. Les pipelines modernes de livraison logicielle nécessitent que les évaluateurs comprennent les contrôles automatisés, évaluent les preuves générées par le système et vérifient que les mécanismes d’application technique atteignent les objectifs de sécurité requis par PCI DSS.
Cet article fournit une approche structurée pour les QSA évaluant les environnements CI/CD et pour les responsables conformité préparant leurs organisations à de telles évaluations.
Périmètre CI/CD pour PCI DSS : Quand les pipelines sont dans le périmètre
Un pipeline CI/CD est dans le périmètre de PCI DSS lorsqu’il répond à l’un des critères suivants :
- Déploie vers l’environnement de données des titulaires de cartes (CDE) : Tout pipeline qui déploie du code, de la configuration ou de l’infrastructure vers des systèmes qui traitent, stockent ou transmettent des données de titulaires de cartes
- Manipule des données de titulaires de cartes : Pipelines qui traitent des données de test contenant des PAN réels, ou qui gèrent des clés de chiffrement ou des systèmes de tokenisation
- Pourrait affecter la sécurité du CDE : Pipelines déployant vers des systèmes connectés au CDE, même s’ils ne manipulent pas directement les données de titulaires de cartes
- Gère les contrôles de sécurité : Pipelines qui déploient ou configurent des pare-feux, WAF, IDS/IPS ou autres contrôles de sécurité protégeant le CDE
Principe clé de périmétrage : Si une compromission du pipeline pourrait conduire à un accès non autorisé aux données de titulaires de cartes, le pipeline est dans le périmètre.
Méthodologie d’évaluation pour les contrôles CI/CD
Une évaluation CI/CD efficace suit une approche structurée combinant revue de documentation, examen de configuration, échantillonnage de preuves et entretiens avec le personnel.
Phase 1 : Revue de documentation
Demander et revoir : politique SDLC, procédures de gestion des changements, schémas d’architecture du pipeline, documentation RBAC et procédures de réponse aux incidents couvrant le CI/CD.
Phase 2 : Examen de configuration
Examiner directement : règles de protection de branche, configurations des portes de sécurité du pipeline, paramètres RBAC, politiques d’application du MFA, configurations de journalisation et contrôles de ségrégation des environnements.
Phase 3 : Échantillonnage de preuves
Sélectionner des échantillons sur la période d’évaluation pour vérifier que les contrôles ont fonctionné de manière cohérente. L’échantillonnage doit couvrir la période complète et inclure différents types de changements (normal, urgence, haut risque).
Phase 4 : Entretiens avec le personnel
Interviewer les responsables d’équipe de développement, les ingénieurs sécurité et les administrateurs de pipeline pour vérifier la compréhension et l’application cohérente des contrôles.
Domaines d’évaluation : Quoi demander, tester et évaluer
| Domaine d’évaluation | Quoi demander | Quoi tester | Critères de réussite/échec |
|---|---|---|---|
| Preuves de développement sécurisé | Documentation SDLC, enregistrements de formation, standards de codage sécurisé | Vérifier que la formation est à jour ; confirmer que le SDLC traite le CI/CD ; vérifier que les standards de codage sont appliqués via le pipeline | Réussite : SDLC documenté, formation à jour, application automatisée. Échec : Pas de documentation SDLC, formation obsolète, pas d’application par le pipeline |
| Gestion des vulnérabilités | Configurations d’analyse, rapports de vulnérabilités, enregistrements de remédiation, artefacts SBOM | Vérifier que les analyses s’exécutent à chaque build ; échantillonner les vulnérabilités pour la rapidité de remédiation ; valider la complétude du SBOM | Réussite : Couverture d’analyse à 100%, remédiation dans les SLA, SBOM à jour. Échec : Analyses manquées, violations de SLA, pas de SBOM |
| Contrôle des changements | Configuration du pipeline, journaux de déploiement, enregistrements d’approbation, journal des changements d’urgence | Échantillonner les déploiements pour l’approbation ; vérifier l’application SoD ; examiner les changements d’urgence pour la documentation appropriée | Réussite : Tous les changements approuvés avant déploiement, SoD appliquée, changements d’urgence documentés. Échec : Déploiements non approuvés, auto-approbations, urgences non documentées |
| Contrôles d’accès | Configuration RBAC, enregistrements de revue d’accès, inventaire des comptes de service, rapports d’inscription MFA | Vérifier le moindre privilège ; confirmer l’application du MFA ; revoir la complétion des revues d’accès et la remédiation | Réussite : Moindre privilège appliqué, MFA universel, revues à jour avec remédiation. Échec : Permissions excessives, lacunes MFA, revues manquées |
| Journalisation et surveillance | Configuration des journaux, paramètres de rétention, règles d’alerte, entrées de journal échantillonnées | Vérifier la complétude de la journalisation ; confirmer que la rétention répond aux exigences ; tester la fonctionnalité des alertes | Réussite : Tous les événements journalisés, rétention adéquate, alertes fonctionnelles. Échec : Lacunes de journalisation, rétention insuffisante, pas d’alertes |
| Chiffrement | Configuration de chiffrement pour les secrets, paramètres de chiffrement en transit, procédures de gestion des clés | Vérifier que les secrets sont chiffrés au repos ; confirmer TLS pour toutes les communications du pipeline ; revoir la gestion des clés | Réussite : Tous les secrets chiffrés, TLS appliqué, gestion des clés documentée. Échec : Secrets en clair, communications non chiffrées, pas de gestion des clés |
| Ségrégation des environnements | Schémas d’architecture, configuration réseau, preuves de séparation des identifiants | Vérifier l’isolation réseau ; confirmer les identifiants séparés par environnement ; vérifier que les contrôles de données de test sont appliqués | Réussite : Isolation réseau vérifiée, identifiants séparés, pas de données réelles en test. Échec : Réseaux partagés, identifiants partagés, PAN réels en test |
Questions d’entretien pour les équipes de développement
Lors des entretiens avec le personnel de l’équipe de développement, les QSA doivent explorer les domaines suivants pour vérifier que les contrôles documentés sont compris et suivis en pratique :
Gestion des changements
- Décrivez le processus de déploiement d’un changement en production. Quelles étapes sont requises ?
- Que se passe-t-il si vous devez déployer un correctif d’urgence en dehors des heures normales ?
- Pouvez-vous déployer en production sans revue de code ? Si oui, dans quelles circonstances ?
- Qui a l’autorité d’approuver les déploiements vers l’environnement de données des titulaires de cartes ?
Contrôles de sécurité
- Quelles analyses de sécurité s’exécutent dans le cadre de votre pipeline ? Que se passe-t-il lorsqu’une analyse trouve une vulnérabilité critique ?
- Comment gérez-vous les secrets et identifiants utilisés par le pipeline ?
- Comment les environnements de développement, test et production sont-ils séparés ?
- Avez-vous déjà dû contourner une porte de sécurité ? Quel était le processus ?
Accès et authentification
- Comment l’accès aux systèmes du pipeline est-il demandé et approuvé ?
- Quand a eu lieu votre dernière revue d’accès ? Des changements ont-ils été effectués en conséquence ?
- Le MFA est-il requis pour tout accès aux systèmes du pipeline ? Y a-t-il des exceptions ?
Réponse aux incidents
- Décrivez ce qui se passerait si une vulnérabilité de sécurité était découverte dans une application déployée
- Y a-t-il eu des incidents de sécurité impliquant le pipeline ? Comment ont-ils été gérés ?
Stratégie d’échantillonnage des preuves pour le CI/CD
Un échantillonnage efficace pour les évaluations CI/CD nécessite de prendre en compte le volume élevé et la nature automatisée des activités du pipeline.
Directives d’échantillonnage
| Taille de la population (changements sur la période) | Taille d’échantillon recommandée | Méthode d’échantillonnage |
|---|---|---|
| 1-50 | Tous les éléments | Examen complet |
| 51-250 | 25-30 éléments | Sélection aléatoire sur toute la période |
| 251-1 000 | 30-40 éléments | Aléatoire stratifié : distribution égale sur les mois plus sélection ciblée des changements à haut risque |
| 1 000+ | 40-60 éléments | Aléatoire stratifié sur les mois plus tous les changements d’urgence plus sélection ciblée à haut risque |
Ce qu’il faut vérifier dans chaque échantillon
- La revue de code a été complétée par un réviseur qualifié qui n’est pas l’auteur
- L’approbation a été accordée avant le déploiement par une personne autorisée
- Les analyses de sécurité ont été exécutées et réussies (ou les échecs ont été traités avant le déploiement)
- La documentation du changement est complète (description, impact, preuves de test)
- La séparation des tâches a été maintenue tout au long du cycle de vie du changement
Signaux d’alerte indiquant la non-conformité
Lors de l’évaluation, les constats suivants doivent susciter une préoccupation immédiate :
- Horodatages d’approbation postérieurs aux horodatages de déploiement : Indique une approbation rétroactive — changements déployés avant autorisation
- Même individu comme auteur et approbateur : Violation de la séparation des tâches
- Résultats d’analyse de sécurité montrant des contournements systématiques : Suggère que les contrôles existent mais sont systématiquement contournés
- Pas de documentation de changement d’urgence malgré des preuves de déploiements hors heures : Indique des contournements non documentés des procédures normales de changement
- Comptes de service avec accès administratif à plusieurs environnements : Viole le moindre privilège et la ségrégation des environnements
- Lacunes dans la journalisation pendant la période d’évaluation : Peut indiquer une falsification de preuves ou des défaillances de configuration
- Revues d’accès ne montrant aucun changement nécessaire : Peut indiquer que les revues sont superficielles plutôt que substantielles
- Changements de configuration du pipeline non soumis à la gestion des changements : L’environnement de contrôle lui-même n’est pas contrôlé
- Développeurs avec accès direct à la production en dehors du pipeline : Indique que le pipeline peut être entièrement contourné
Contrôles compensatoires et considérations d’approche personnalisée
Contrôles compensatoires
Lorsqu’une organisation ne peut pas répondre à une exigence PCI DSS telle qu’énoncée, les contrôles compensatoires peuvent être acceptables s’ils :
- Répondent à l’intention et à la rigueur de l’exigence originale
- Fournissent un niveau de défense similaire
- Vont au-delà des autres exigences PCI DSS
- Sont proportionnés au risque supplémentaire causé par le non-respect de l’exigence originale
Exemple : Si un outil de pipeline legacy ne peut pas appliquer techniquement la séparation des tâches, les contrôles compensatoires pourraient inclure une revue post-déploiement obligatoire par une partie indépendante, une journalisation améliorée avec alertes en temps réel sur les changements auto-approuvés et un audit mensuel de tous les enregistrements de déploiement.
Approche personnalisée (v4.0)
L’approche personnalisée permet aux organisations de répondre à l’objectif de sécurité par des moyens alternatifs. Pour les environnements CI/CD, cela offre de la flexibilité mais nécessite :
- Une analyse ciblée des risques documentée pour chaque contrôle personnalisé
- Une articulation claire de la manière dont le contrôle alternatif atteint l’objectif de sécurité
- Des preuves que le contrôle personnalisé est au moins aussi efficace que l’approche définie
- Des tests plus rigoureux par le QSA pour valider le contrôle personnalisé
Documentation du rapport de conformité (ROC) pour les contrôles CI/CD
Lors de la documentation des contrôles CI/CD dans le ROC, les QSA doivent s’assurer :
- Définition du périmètre : Documenter clairement quels composants du pipeline sont dans le périmètre et la justification des décisions de périmétrage
- Descriptions des contrôles : Décrire comment les contrôles CI/CD satisfont chaque exigence pertinente, incluant les mécanismes d’application technique
- Références de preuves : Référencer les preuves spécifiques examinées, incluant les journaux générés par le système, les captures d’écran de configuration et les enregistrements échantillonnés
- Procédures de test : Documenter la méthodologie d’évaluation utilisée, incluant l’approche d’échantillonnage et les tailles d’échantillon
- Constats et observations : Documenter toute exception, contrôle compensatoire ou domaine où l’approche personnalisée a été utilisée
- Résumés d’entretiens : Documenter les constats clés des entretiens avec le personnel, en particulier lorsque les réponses aux entretiens ont confirmé ou contredit les preuves documentaires
Ressources connexes
- Hub de conformité PCI DSS
- Signaux d’alerte d’audit CI/CD — Ce qui préoccupe immédiatement les auditeurs
Ressources connexes pour les auditeurs
- Glossaire — Définitions en langage clair des termes techniques
- Comment les auditeurs examinent le CI/CD
- Checklist de préparation à l’audit
- Guide du jour d’audit
Nouveau dans l’audit CI/CD ? Commencez par notre Guide de l’auditeur.
