Dans le cadre de nos échanges réguliers avec le PCI SSC, organisme en charge de la gestion du PCI DSS, XMCO a assisté à une présentation concernant les prochaines évolutions du standard.
La version 3.2 du standard PCI DSS sera publiée au mois d’avril et contiendra de légères évolutions.
Quel est l’objet de ces changements ?
Nous ne connaissons pas encore tous les détails, mais nous pouvons déjà vous communiquer quelques éléments.
– Le principal ajout majeur concerne l’utilisation d’une authentification « multifacteur » pour les connexions à l’ensemble des éléments du CDE. Cette exigence sera obligatoire pour le mois de février 2018, au plus tard, et sera applicable pour tous les accès (ce qui inclue également les accès console).
– La date limite pour la migration des protocoles considérés comme obsolètes (SSL, TLS 1.0) est toujours maintenue pour juin 2018.
– Les règles concernant l’affichage des PANs seront modifiées, aucune information complémentaire n’a été donnée.
En ce qui concerne les prestataires de service (Service Provider), quelques nouvelles contraintes ont également été ajoutées :
– Rédaction d’une documentation permettant de présenter clairement l’architecture et les mécanismes de chiffrement utilisés.
– Réalisation de contrôles de segmentation tous les 6 mois.
– Lecture des politiques et des procédures par les employés tous les 3 mois.
Enfin, tous les documents officiels liés au standard (SAQ, AOC, ROC et la FAQ) seront mis à jour en même temps que la sortie de la nouvelle version.
Quel est le délai ?
La version 3.1 du PCI DSS reste effective 6 mois après la publication de la version 3.2 (donc jusqu’en octobre 2016) ce qui signifie que les audits en cours pourront toujours être réalisés sur la version 3.1.
Toutes les nouvelles exigences introduites seront considérées comme des « Meilleures Pratiques » puis obligatoires à partir du 1er février 2018.
Avis XMCO
Bien qu’elle soit déjà effective pour les accès réseau distants, nous pouvons déjà imaginer que cette nouvelle méthode d’authentification « multifacteur » risque de poser un grand nombre de problèmes en termes d’implémentation. Elle se doit donc d’être anticipée.
L’utilisation d’un bastion avec une double authentification (certificat, smart-card, token) serait certainement la solution la plus simple pour répondre à cette exigence. Cette approche permettrait de centraliser l’authentification « multifacteur » sur un élément central unique, en amont des serveurs, afin d’en faciliter la mise en oeuvre.
Une autre piste consisterait à utiliser un VPN basé sur une authentification à double facteur pour tous les accès au CDE (même locaux).
La publication définitive de la version 3.2 d’ici quelques semaines nous permettra de statuer sur ce point.
