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 :

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.