Les procédures de contrôles récurrents

Maintenir une certification PCI DSS demande la mise en place de procédures de contrôles récurrents, à effectuer tout au long d’une année, et ce, jusqu’à sa prochaine certification.

Ces procédures jouent un rôle majeur, car elles permettent de maintenir un niveau de sécurité de l’environnement certifié.

Nous proposons dans ce billet de lister et décrire toutes les procédures récurrentes attendues par le standard.

Nous ne le préciserons pas à chaque fois, mais souvenez-vous que l’exécution de ces procédures doit être tracée afin de pouvoir être auditée, à minima, par votre QSA. Ainsi, la production de rapports, de compte-rendu, de tickets, d’e-mails, de feuilles d’émargement ou autres preuves est plus que recommandée.

Récapitulons !

Récapituler avant d’entrer dans le vif du sujet ? Eh bien oui. Pour ceux qui n’auraient pas le courage de parcourir en détail les contrôles récurrents, nous vous proposons dès le début de ce billet un tableau récapitulatif des attentes du standard :

Contrôles quotidiens
6.1/6.2 Faire de la veille en vulnérabilité
10.6.1 Revoir (à minima) :
– Les évènements de sécurité
– Les journaux des systèmes qui transmettent, manipulent ou stockent des données de carte
– Les journaux des systèmes critiques
– Les journaux des composants de sécurité (Firewalls, IDS, FIM, Antivirus, AD, LDAP, etc.)
Contrôles mensuels
6.2 Installer les correctifs de sécurité critiques
Contrôles trimestriels
3.1 Identifier et supprimer les données de cartes qui excèdent la durée de rétention
6.2 Installer les correctifs de sécurité non-critiques
11.1 Détecter la présence de points d’accès sans-fil non autorisés / Revue physique des équipements (dongles, point d’accès, etc.)
11.2 Réaliser un scan interne et externe (ASV)
12.11 Vérifier que le personnel respecte bien les procédures de sécurité, dont :
– Revue quotidienne des journaux
– Revue semestrielle des règles de filtrage
– Respect des standards de sécurité lors du déploiement d’un nouveau système ou composant
– Réponse aux alertes de sécurité dans un temps approprié
– Respect de la procédure de gestion du changement
Contrôles semestriels
1.1.7 Revoir les règles de filtrage des firewalls
11.3.4.1 Réaliser un test d’intrusion sur les mécanismes de segmentation
Contrôles annuels (ou plus)
3.6.4 Renouveler les clés de chiffrement expirées (Tous Les 2 ans en moyenne)
6.5 Former les développeurs au développement sécurisé
9.7.1 Inventorier les médias sensibles
11.3 Réaliser un test d’intrusion interne et externe
12.1.1 Revoir la politique de sécurité
12.2 Faire une analyse de risques
12.6.1 Sensibiliser le personnel aux procédures de sécurité
12.6.2 Faire reconnaitre formellement aux collaborateurs qu’ils ont bien lu et compris les politiques et procédures de sécurité
12.8.4 Vérifier la conformité PCI DSS des prestataires de service sensibles
12.10.2 Revoir et tester le plan de réponse aux incidents
Contrôles à effectuer suite à un changement significatif
6.3.2 Revoir et valider les changements du code source des applications Avant chaque mise en production
6.4.5 Documenter, approuver et tester le changement A chaque changement
6.6 Faire un audit de sécurité de l’application (manuellement ou automatiquement) A chaque changement d’une application web exposée publiquement
6.4.6 Vérifier que toutes les exigences PCI DSS applicables ont été appliquées et que la documentation a été maintenue à jour A chaque changement significatif
11.2 Réaliser un scan interne et externe (ASV) A chaque changement significatif
11.3 Réaliser un test d’intrusion interne et externe A chaque changement significatif
12.2 Faire une analyse de risque A chaque changement significatif
12.1.1 Revoir la politique de sécurité A chaque changement de l’environnement
Contrôles à appliquer suite à l’arrivée ou au départ d’un collaborateur
3.6.8 Faire reconnaitre formellement au maître de clés leurs responsabilités Embauche d’un collaborateur qui aura accès à des clés de chiffrement
7.1.4 Faire approuver les accès d’un collaborateur Embauche d’un nouveau collaborateur ou évolution d’un collaborateur
8.1.3 Révoquer immédiatement les accès d’un collaborateur Départ d’un collaborateur
12.6.1 Sensibiliser les nouveau collaborateurs aux procédures de sécurité à l’embauche
12.6.2 Faire reconnaitre formellement aux nouveaux collaborateurs qu’ils ont bien lu et compris les politiques et procédures de sécurité
Contrôles dont la récurrence est à définir par l’entité certifiée
3.6.5 Remplacer la ou les clé(s) de chiffrement Lorsque l’intégrité de la clé a été compromise
9.9.1 Mettre à jour l’inventaire des lecteurs de carte A chaque changement qui intervient sur un lecteur de carte
9.9.2 Inspecter les lecteurs de carte A définir
9.9.3 Former les personnels aux points de vente à la protection des lecteurs de carte Au moins 1 fois
10.8 Détecter et répondre aux erreurs de fonctionnement des composants de sécurité :
– Firewalls
– IPS/IDS
– FIM
– Antivirus
– Mécanisme de contrôle d’accès physique
– Mécanisme de contrôle d’accès logique
– Mécanisme de journalisation et de centralisation des logs
– Mécanisme de segmentation
Dans un temps approprié
12.10.4 Entrainer le personnel qui joue un rôle dans le plan de réponse aux incidents A définir

Les contrôles récurrents

Vous trouverez ci-dessous l’ensemble des exigences qui imposent la mise en place d’un contrôle récurrent :

Les contrôles quotidiens

  • Exigence 6.1 – Une procédure de veille en vulnérabilité doit être en place afin de pouvoir identifier les derniers correctifs de sécurité publiés. La récurrence de cette procédure doit permettre d’installer un patch de sécurité jugé critique dans le mois qui suit sa publication.
  • Exigence 10.6.1 – Les journaux produits par les différents composants de l’environnement certifié doivent être revus quotidiennement. Cette procédure doit à minima inclure les journaux suivants :
    • Les journaux de sécurité ;
    • Les journaux de tous les composants qui stockent, manipulent ou transmettent des données de cartes. Cela peut inclure les journaux des systèmes d’exploitation, des applications, des bases de données, des équipements d’infrastructure (Parefeu, répartiteur de charge, proxy et reverse-proxy, etc.) ;
    • Les journaux des composants qui jouent un rôle important dans l’environnement (Serveur de Log, NAS/SAN, Gateway VPN, serveur de rebond, serveur de mise à jour, etc.) ;
    • Les journaux des composants qui jouent un rôle de sécurité (pare-feu, IPS/IDS, serveur d’authentification, console antivirus, application de contrôle d’intégrité, WAF, etc.) ;

    Notez que cette revue ne doit pas être manuelle. En effet, afin de rendre cette revue efficiente, l’utilisation d’outils de corrélation de log et de dashboard est plus que recommandée (Suite ELK, OSSEC, Splunk, etc.).

Les contrôles mensuels

  • Exigence 6.2 – Les patchs de sécurité qui corrigent des vulnérabilités jugées critiques doivent être installés dans le mois qui suit leur publication.

Les contrôles trimestriels

  • Exigence 3.1 – Une procédure trimestrielle doit être en place afin d’identifier et de supprimer toutes les données de carte qui excèdent la période de rétention définie.
  • Exigence 6.2 – Les patchs de sécurité qui corrigent des vulnérabilités jugées importantes ou inférieures doivent être installés dans un temps acceptable. XMCO recommande d’installer ces correctifs dans une période n’excédant pas 3 mois.
  • Exigence 11.1 – Une procédure pour détecter la présence des points accès sans-fil doit être en place. Cette procédure doit permettre d’identifier :
    • Les cartes WLAN
    • Les points d’accès WiFi
    • Les clés USB
    • Les clés 3G, Bluetooth, Infra-rouge, etc.
    • Les ordinateurs portables ou smartphones

    Vous l’aurez compris, l’utilisation d’un scanner pour identifier la présence des réseaux WiFi est une solution, mais elle n’est pas suffisante. Nous recommandons de mettre en place une revue physique des équipements du périmètre.

    Cette procédure peut être déléguée à un prestataire de service ou aux équipes locales des data-centres.

    Dans tous les cas, elle devra être formalisée au sein d’une documentation interne et/ou d’un contrat et devra donner lieu à un compte-rendu.

  • Exigence 11.2 – Des scans de sécurité internes et externes doivent être lancés tous les 3 mois. Les scans externes doivent être réalisés par un prestataire ASV (i.e. Approved Scanning Vendor), c’est-à-dire approuvés par le PCI SCC puis validés.Note : ne sous-estimez pas le temps nécessaire pour obtenir un scan validé. Entre le lancement, les actions correctrices, le contre-scan et la validation par l’ASV, le délai peut être plus long que prévu et donc engendrer des problèmes dans l’obtention de ces scans trimestriels.La liste des prestataires ASV est disponible ici : Prestataires ASV
  • Exigence 12.11 (applicable aux prestataires de services seulement) – Une personne ou une équipe doit être en charge d’assurer que les politiques et les procédures de l’entreprise (ou à minima, celles listées dans ce billet) sont bien appliquées par le personnel désigné. Cette procédure devra, à minima, inclure la revue des procédures suivantes :
    • La procédure quotidienne de revue des journaux (cf 10.6.1)
    • La revue semestrielle des règles de filtrage (cf. 1.1.7)
    • L’application des standards de sécurité sur les derniers systèmes installés
    • La réponse à toutes les alertes de sécurité (IDS/IPS, Antivirus, violation de l’intégrité d’un fichier sur un système, intrusion physique, etc.)
    • La procédure de gestion des changements

    Les résultats de cette revue devront être documentés ; ce document devra être signé par le responsable de la conformité PCI DSS.

Les contrôles semestriels

  • Exigence 1.1.7 – Les règles appliquées par les équipements de filtrage (routeurs et parefeu) doivent être revues semestriellement.
  • Exigence 11.3.4.1 (applicable aux prestataires de services seulement) – Des tests d’intrusion semestriels devront être menés sur les mécanismes de segmentation afin de confirmer que le périmètre PCI DSS défini est bien isolé des équipements hors-scope. En d’autres mots, l’objectif de ces tests est de confirmer que les règles de filtrage sont correctement définies.Nous avons détaillé la nature de ces tests au sein de la section « Les tests de segmentation » du billet Les tests d’intrusion PCI DSS.

Les contrôles annuels (ou plus)

  • Exigence 3.6.4 – Les clés de chiffrement qui ont excédé leur crypto-periode doivent être renouvelées. La crypto-période d’une clé de chiffrement dépend de plusieurs facteurs (sa taille, de l’environnement où elle est utilisée, du volume d’informations chiffrées, etc). Pour faire simple, la crypto-période d’une clé doit être comprise entre 1 et 2 ans (cf. NIST SP 800-57 Pt. 1 Rev. 4.).
  • Exigence 6.5 – Les développeurs doivent être formés/entrainés aux techniques de développement sécurisé. Cette formation doit être renouvelée chaque année.
  • Exigence 6.6 – Les applications web accessibles publiquement et qui ne sont pas protégées par un WAF doivent être auditées ou scannées, à minima, annuellement.
  • Exigence 9.7.1 – Tous les médias (physiques ou électroniques) sur lesquels sont stockées des données de cartes doivent être inventoriés. Cet inventaire doit être revu chaque année afin de confirmer qu’il est à jour et que tous les médias sortants ont bien été nettoyés conformément à la procédure de mise au rebut des médias.
  • Exigence 11.3 – Des tests d’intrusion internes et externes doivent être menés.Nous avons développé ce point au sein d’un autre billet
  • Exigence 12.1.1 – La politique de sécurité doit être revue annuellement afin d’intégrer les derniers changements de l’entreprise ou de l’environnement certifié.
  • Exigence 12.2 – Une analyse de risques doit être effectuée annuellement.
  • Exigence 12.6.1 – Le personnel doit être sensibilisé à la sécurité au moins une fois par an.
  • Exigence 12.6.2 – Le personnel doit reconnaitre qu’il a lu et compris les politiques et procédures applicables à l’entreprise et/ou à l’environnement certifié, à minima une fois par an.
  • Exigence 12.8.4 – La conformité de tous les prestataires de services certifiés PCI DSS doit être revue annuellement, avant la date d’anniversaire de la certification de chaque prestataire de services. L’objectif de ce contrôle est de s’assurer qu’un prestataire de service certifié le demeure tant que le service est délivré.
  • Exigence 12.10.2 – Le plan de réponse sur incident doit être testé chaque année.

Les procédures et contrôles à effectuer lors d’un évènement

A chaque changement significatif

Le terme significatif peut avoir différentes définitions en fonction de l’entreprise, de l’environnement, de l’équipe, voire de la personne. Il incombe donc à l’entité certifiée de définir ce terme.

Un changement significatif peut avoir lieu à différents niveaux :

  • Au niveau de l’entreprise : changement de direction/rachat, changement d’équipe, changement d’objectifs, changement de moyens (financier, temporelle ou humain), contractualisation avec un nouveau prestataire de services, changement de datacenter, etc.
  • Au niveau réseau : ajout d’une interconnexion ou d’un nouveau segment réseau, modification massive des règles de filtrages, ajout d’un nouvel équipement d’infrastructure, modification de l’architecture réseau, extension vers des services Cloud, etc.
  • Au niveau système : ajout d’un nouveau serveur, utilisation d’un nouveau système d’exploitation, modification de la configuration d’un composant middleware, changement de l’infrastructure de sauvegarde, etc.
  • Au niveau applicatif : mise en production d’une nouvelle application ou version dans le périmètre, exposition d’une application sur internet, utilisation d’une nouvelle bibliothèque applicative, etc.
  • Au niveau métier : stockage des informations de cartes bancaires, modification des flux de réception ou d’envoi de cartes, etc.
  • etc.

En fonction du changement et de son impact, les contrôles suivants doivent être exécutés :

  • Exigence 6.4.6 – Vérifier que toutes les exigences PCI DSS applicables ont bien été respectées suite au changement et que la conformité PCI DSS est maintenue.
  • Exigence 6.6 – Les applications web accessibles publiquement et qui ne sont pas protégées par un WAF doivent être auditées ou scannées.
  • Exigence 11.2 – Des scans de sécurité internes et/ou externes doivent être lancés.
  • Exigence 11.3 – Des tests d’intrusion internes et externes doivent être menés.
  • Exigence 12.1.1 – La politique de sécurité doit être revue afin d’intégrer les derniers changements.
  • Exigence 12.2 – Une analyse de risques doit être effectuée.

Contrôles à appliquer suite à l’arrivée ou au départ d’un collaborateur

  • Exigence 3.6.8 – Si le nouveau collaborateur peut avoir accès à des clés de chiffrement, il doit reconnaitre formellement qu’il comprend et accepte les responsabilités associées.
  • Exigence 7.1.4 – Les accès des nouveaux collaborateurs doivent être approuvés.
  • Exigence 8.1.3 – Les accès des collaborateurs sortants doivent être révoqués.
  • Exigence 12.6.1 – Les nouveaux collaborateurs doivent être sensibilisés à la sécurité à l’embauche.
  • Exigence 12.6.2 – Les nouveaux collaborateurs doivent reconnaitre qu’ils ont lu et compris les politiques et procédures applicables à l’entreprise et/ou à l’environnement certifié.

Contrôles dont la récurrence est à définir par l’entité certifiée

  • Exigence 9.9.2 – Les appareils dans lesquels les cartes de paiement sont insérées (Lecteur de carte, Terminal de paiement, etc.) doivent être inspectés de manière récurrente.
  • Exigence 9.9.3 – Le personnel doit être entraîné/sensibilisé aux attaques qui peuvent être menées à l’encontre des appareils dans lesquels les cartes de paiement sont insérées (ex: Skimming).
  • Exigence 12.10.4 – Le personnel qui joue un rôle dans le plan de réponse à incidents doit être entrainé. Cet entrainement peut avoir lieu lors du test du plan de réponse à incidents qui doit avoir lieu annuellement.
  • Exigence 10.8 et 10.8.1 (applicable aux prestataires de services seulement) – Une procédure doit être définie afin de détecter et de répondre aux dysfonctionnements des équipements de sécurité :
    • Parefeu
    • IDS/IPS
    • Outil de contrôle d’intégrité (i.e. FIM)
    • Antivirus
    • Mécanisme de contrôle d’accès physique
    • Mécanisme de contrôle d’accès logique
    • Mécanisme de journalisation
    • Mécanisme de segmentation

    Pour répondre à cette exigence, nous vous recommandons d’inclure ces contrôles à vos outils de monitoring temps réel. En outre, des outils comme Nagios peuvent être utilisés pour répondre à cette exigence.

Les autres contrôles

  • Exigence 6.3.2 – avant la mise en production d’un code applicatif, ce dernier doit être revu par une personne différente de(s) auteur(s) dudit code. En outre, la revue du code source doit être approuvée avant la mise en production.
  • Exigence 6.4.5 – Chaque changement qui a lieu sur l’environnement certifié doit être tracé (ex: ticket). Cette trace doit inclure :
    • La description du changement
    • La documentation de l’impact du changement
    • L’approbation du changement par une personne autorisée
    • Le résultat des tests fonctionnels qui démontrent que le changement n’engendre pas de défaut de sécurité
    • La procédure de retour arrière

Conclusion

Ces contrôles récurrents ne sont pas toujours si simples à mettre en œuvre et requièrent une grande rigueur tout au long de l’année avec une forte implication des équipes de production.

Néanmoins, il est important de ne pas les négliger afin de maintenir sa certification PCI DSS. Nous espérons que cet article vous aidera dans cette tâche.

Adrien Guinault

Découvrir d'autres articles

  • PCI DSS

    PCI v4.0 – 6.3.2 : Comment automatiser l’inventaire et la veille sur les bibliothèques tierces ?

    Lire l'article
  • Conférences

    Retour sur le PCI Community Meeting 2023 à Dublin

    Lire l'article
  • paiement
    PCI DSS

    PCI DSS en version 4, quels sont les changements apportés au SAQ-P2PE ?

    Lire l'article