Lorsque j’ai reçu la notification de publication de la norme, le 31 mars 2022, j’ai cru à un poisson d’avril. Je laisse donc la journée passée pour vérifiée le lendemain et bien non — La norme a bel et bien été publiée!
Période de transition
La période de transition est du 31 mars 2022 au 31 mars 2024, vous avez ce délai pour modifier les documentations, les rapports et autres formulaires ou registres afin d’être conforme aux nouvelles exigences. La norme PCIDSS 3.2.1 reste valide durant cette période, pour ceux qui détiennent déjà la certification. Les nouveaux pourraient s’y glisser le temps que les QSA (Qualified security assessor) obtiennent leurs formations.
Certaines des nouvelles exigences de la version 4.0 ne deviendront pas obligatoires avant le 31 mars 2025. Jusqu’à cette date, ces exigences sont considérées comme de “meilleures pratiques”.
Il est toutefois recommandé de débuter leurs mises en œuvre afin de ne pas se retrouver à la dernière minute face à des exigences qui pourraient d’avérer difficile à mettre en œuvre rapidement ou simplement.
Afin de comprendre les changements, j’ai regardé la norme elle-même ainsi et surtout le nouveau ROC (Report on compliance). D’après moi, c’est là que se situent les changements, mais surtout les nuances de ces changements, car c’est là qu’on retrouve les exigences que doivent les auditeurs(QSA) pour auditer les firmes.
Approche personnalisée
Le standard ajoute une nouvelle manière d’être conforme à une mesure de sécurité par une mise en œuvre personnalisée (Customized implementation). Attention, cette approche n’est pas possible pour certaines mesures de sécurité.
Ce changement a pour objectif de permettre une plus grande flexibilité des entreprises, puisqu’une bonne solution pour entreprise A ne l’est pas pour entreprise B.
Cela dit, la nouvelle version de la norme rajoute beaucoup(trop) de nouveaux éléments. Quelques exemples:
- Au moins tous les 12 mois et lors d’un changement significatif, documenter et confirmer le champ d’application (Portée/Scope) PCI DSS de l’environnement dans le champ d’application (PCI DSS 12.5.2);
- Une analyse des risques ciblée pour tout contrôle utilisant l’approche personnalisée au moins tous les 12 mois avec des approbations écrites de la direction générale (PCI DSS 13.3.2);
- Au moins une analyse des risques annuels pour tous les contrôles qui ont une flexibilité pour la fréquence des contrôles(PCI DSS 13.3.1);
- Au moins une révision annuelle des suites de chiffrement et des protocoles(PCI DSS 12.3.3);
- Au moins une révision annuelle des technologies matérielles et logicielles utilisées, avec un plan de remédiation des technologies obsolètes approuvé par la direction générale (PCI DSS 12.3.4);
Importance de la gestion des accès
De plus, la version 4.0 du standard PCI DSS augmente l’importance du contrôle des accès par les contraintes suivantes:
- Utilisation de l’authentification multifacteur pour tous les comptes qui ont accès aux données des titulaires de cartes, et pas seulement pour les administrateurs qui accèdent à l’environnement des données des titulaires de cartes.
- Les mots de passe des comptes utilisés par les applications et les systèmes doivent être modifiés au moins tous les 12 mois et en cas de suspicion de compromission.
- Utilisation de mots de passe forts pour les comptes utilisés par les applications et les systèmes, qui doivent contenir au moins 15 caractères, y compris des caractères numériques et alphabétiques.
- PCI DSS exige maintenant que les mots de passe soient comparés à la liste des mauvais mots de passe connus.
- Les privilèges d’accès doivent être revus au moins une fois tous les six mois.
- Les comptes de fournisseurs ou de tiers ne peuvent être activés que si nécessaire et surveillés lorsqu’ils sont utilisés.
Plus concrètement, voici les changements listés par exigences. Il est à noter que les numéros ont été modifiés,soit dans l’ordre ou les sous-points.
Les exigences 1 et 2 ne comportent pas de changement majeur.
Pour chaque section — Une politique doit être à définir ainsi qu’un responsable est assigné.
Exigence 3 — Protection des données de compte stockées
- Les données d’authentification sensible, “SAD — Sensitive authentification data” stockées électroniquement avant l’autorisation (pour la durée du traitement informatique) de transaction doit être cryptées avec une cryptographie forte(le chiffrement n’était pas spécifié avant).
- Ajout de contrôles techniques pour empêcher la copie et/ou la relocalisation du PAN lors de l’utilisation de technologies d’accès à distance. (La session RDP doit prévenir les “copie/collé”)
- Lors du hachage, une valeur secrète (ou clef) doit être ajoutée au processus afin de rendre le PAN (Primary account number) illisible.
- Le cryptage du disque ou des partitions est uniquement utilisé pour rendre le PAN illisible sur des supports électroniques amovibles ou, s’il est utilisé sur des supports électroniques non amovibles, le PAN est également rendu illisible par un mécanisme identifié au point plus haut.
- L’utilisation des mêmes clés cryptographiques dans les environnements de production et de test est interdite.
Exigence 4 — Protéger les données du titulaire de carte par une cryptographie forte pendant la transmission sur des réseaux ouverts et publics
- Confirmer que les certificats utilisés pour les transmissions PAN sur des réseaux ouverts et publics sont valides et n’ont pas expiré ou ont été révoqués.
- Maintenir un inventaire des clés et des certificats de confiance.
Exigence 5 — Protéger tous les systèmes et réseaux contre les logiciels malveillants
- Définir la fréquence des évaluations périodiques des composants du système qui ne sont pas exposés à des logiciels malveillants dans l’analyse des risques ciblée pour l’entreprise. (Attention aux virtualisations telles que ESXi qui reposent sur Linux et qui comportent depuis récemment des virus spécifiques — voir: Lockbit et Hellokitty. )
- Définissez la fréquence des analyses périodiques des logiciels malveillants dans l’analyse des risques ciblée de l’entité.
- Une solution pour les logiciels malveillants sur les supports électroniques amovibles
- Détecter et protéger le personnel contre les attaques d’hameçonnage
Exigence 6 — Développer et maintenir des systèmes et des logiciels sécurisés
- Maintenir un inventaire des logiciels sur mesure et personnalisés.
- Déployer une solution technique automatisée pour les applications web tournées vers le public, qui détecte et prévient en permanence les attaques basées sur le web.
- Gestion de tous les scripts des pages de paiement qui sont chargés et exécutés dans le navigateur du consommateur.
Exigence 7 — Restreindre l’accès aux composants du système et aux données des titulaires de cartes par besoin professionnel d’information
- Examen de tous les comptes d’utilisateur et des privilèges d’accès associés
- Affectation et gestion de tous les comptes d’application et de système et des privilèges d’accès associés
- Examiner tous les accès par les comptes d’application et de système et les privilèges d’accès associés.
Exigence 8 — Identifier les utilisateurs et authentifier l’accès aux composants du système
- Augmenter la longueur des mots de passe d’une longueur minimale de sept caractères à une longueur minimale de 12 caractères (ou si le système ne prend pas en charge 12 caractères, une longueur minimale de huit caractères).
- Si les mots de passe/phrases de passe sont le seul facteur d’authentification pour l’accès des utilisateurs clients, alors les mots de passe/phrases de passe sont soit changés au moins une fois tous les 90 jours, soit l’accès aux ressources est automatiquement déterminé par une analyse dynamique de la posture de sécurité des comptes. (Passer au passwordless)
- Mettre en œuvre l’authentification multifactorielle (MFA) pour tous les accès au CDE.
- Gestion des comptes de systèmes ou d’applications qui peuvent être utilisés pour une connexion interactive
- Ne pas coder en dur les mots de passe/phrases de passe dans les fichiers ou les scripts pour les comptes d’applications et de systèmes qui peuvent être utilisés pour une connexion interactive.
- Protection des mots de passe/phrases de passe pour les comptes d’applications et de systèmes contre les abus.
Exigence 9 — Limiter l’accès physique aux données des titulaires de cartes
- Définir la fréquence des inspections périodiques des terminaux, point de paiement, en fonction de l’analyse de risque ciblée de l’entité.
Exigence 10 — Consigner et surveiller tous les accès aux composants du système et aux données des titulaires de cartes
- Utilisation de mécanismes automatisés pour effectuer des examens des journaux d’audit
- Analyse ciblée des risques pour définir la fréquence des examens périodiques des journaux pour tous les autres composants du système.
- Détecter, alerter et traiter rapidement les défaillances des systèmes de contrôle de sécurité critiques.
- Réagir rapidement aux défaillances de tout contrôle de sécurité critique.
Exigence 11 — Tester régulièrement la sécurité des systèmes et des réseaux
- Gérez toutes les autres vulnérabilités applicables (celles qui ne sont pas classées comme à haut risque ou critiques) découvertes lors des analyses de vulnérabilité internes.
- Effectuer des analyses de vulnérabilité interne avec un compte valide. (Authentification)
- Exigence pour les fournisseurs de services hébergés/cloud tiers de soutenir leurs clients pour les tests de pénétration externes.
- Utiliser des techniques de détection et/ou de prévention des intrusions pour détecter, alerter/prévenir et traiter les canaux de communication clandestins des logiciels malveillants.
- Déployer un mécanisme de détection des modifications et des altérations pour signaler les modifications non autorisées des en-têtes HTTP et du contenu des pages de paiement reçues par le navigateur du consommateur.
Exigence 12 — Soutenir la sécurité des informations avec des politiques et des programmes organisationnels
- Effectuer une analyse des risques ciblée pour toute exigence PCI DSS qui offre une certaine flexibilité quant à la fréquence de son exécution.
- Documentez et révisez les suites de chiffrement et les protocoles cryptographiques utilisés au moins une fois tous les 12 mois.
- Passer en revue les technologies matérielles et logicielles utilisées au moins une fois tous les 12 mois.
- Documenter et confirmer le champ d’application de la norme PCI DSS au moins une fois tous les 12 mois pour Marchant et 2 fois par année pour fournisseurs de services. Ainsi que lors de changement significatif de l’environnement concerné.
- Examen documenté de l’impact sur le champ d’application de la norme PCI DSS et l’applicabilité des contrôles lors de changements significatifs de la structure organisationnelle, tel que lors de réorganisation ou fusion d’entreprise.
- Réviser et mettre à jour (si nécessaire) le programme de sensibilisation à la sécurité au moins une fois tous les 12 mois.
- Formation de sensibilisation à la sécurité incluant une sensibilisation aux menaces et aux vulnérabilités qui pourraient avoir un impact sur la sécurité du CDE.
- La formation de sensibilisation à la sécurité doit inclure une sensibilisation à l’utilisation acceptable des technologies de l’utilisateur final.
- Soutenir les demandes d’information des clients pour répondre aux exigences 12.8.4 et 12.8.5.
- Réaliser une analyse de risque ciblée pour définir la fréquence des formations périodiques du personnel de réponse aux incidents.
- Obligation de mettre en place des procédures de réponse aux incidents et de les déclencher dès la détection d’un PAN stocké dans un endroit où l’on ne s’y attend pas.
À lire le blogue : PCI Guru pour une opinion, il a une opinion bien tranchée sur la nouvelle norme 4 du PCI DSS
Je vous invite à cliquer sur “Follow” pour continuer d’en apprendre plus sur le domaine de la sécurité de l’information.
