Les exigences applicables en 2018

En vous plongeant dans la version du chapitre 3.2, vous avez dû remarquer que plusieurs exigences restaient optionnelles…jusqu’en 2018.

Des chantiers techniques ont été menés pour certaines (mise en place d’une authentification double facteur) et des processus récurrents ont été mis en place pour d’autres exigences afin de pouvoir répondre à ces nouvelles règles.

Reprenons la liste de ces dernières afin d’éclaircir le sujet, en espérant que vous avez pu déjà anticiper les actions associées 🙂

Exigences applicables au 31 janvier 2018 :

3.5.1 : Maintenir un document décrivant l’architecture cryptographique (Service Provider seulement)

Une mise à jour de la politique de chiffrement et de gestion des clés de chiffrement doit être faite afin d’inclure les éléments suivants :

• Rôle de chaque serveur et logiciels de l’architecture de chiffrement
• Description des algorithmes de chiffrement pour les données de carte, mais également pour les clés (DEK et KEK)
• Description du rôle de chaque type de clés cryptographiques
• Inventaire des HSM et autres SCD (si applicable)

6.4.6 : En cas de changement significatif, l’ensemble des exigences PCI DSS doit être implémenté et vérifié

La procédure de gestion du changement (présent dans la politique de gestion des changements) doit être enrichie afin d’y inclure des points de contrôle à vérifier en cas de changement significatif, et ce, afin de s’assurer que l’ensemble des exigences sont encore respectées suite à ce changement. Cette procédure doit contenir des éléments techniques, comme l’application des standards de sécurité, l’installation des FIM, antivirus, etc., mais aussi des éléments documentaires, comme la mise à jour du schéma réseau.

Pour exemple :

• Le changement concerne l’architecture réseau :
• Le schéma réseau doit être tenu à jour ;
• La matrice jusitifiant les flux réseau doit être tenue à jour ;
• Les règles de filtrage réseau doivent être modifiées en fonction du changement ;
• Des tests d’intrusion des éléments de segmentation doivent être réalisés;
• Le changement concerne l’installation d’un nouveau système :
• Les standards de configuration doivent être appliqués ;
• L’inventaire du périmètre PCI DSS doit être mis à jour ;
• Le nouveau système doit être inclus dans le périmètre des scans internes ;
• S’il s’agit d’un nouveau type de serveur, des tests d’intrusion à l’encontre de celui-ci doivent être réalisés;
• Le changement concerne un système, une base de données ou un média qui stocke des données de carte :
• La politique de rétention et suppression des données de carte doit être mise à jour ;
• Si l’équipement concerné est décommissionné, les données de carte doivent être supprimées de manière sécurisée conformément à la procédure définie ;

8.3.1 : Un mécanisme d’authentification multi-facteurs (MFA) doit être mis en place sur l’ensemble des accès d’administration au CDE

L’administration des systèmes, interfaces d’administration, équipements réseau, bases de données, etc. doit obligatoirement être effectuée au travers d’un mécanisme d’authentification multi-facteurs (MFA).
La politique de gestion des identités et des mots de passe doit être mise à jour afin d’y intégrer l’obligation de l’utilisation d’un mécanisme de MFA pour tous les accès administratifs et non-console au CDE (local et distant), ainsi que la description du mécanisme mis en place.

Ce point pouvant être complexe à mettre en place, n’hésitez pas à nous contacter afin d’en parler et de trouver la solution la plus adaptée à votre contexte.

Pour information, le PCI SSC a émis un document présentant l’authentification multi-facteurs : https://www.pcisecuritystandards.org/pdfs/Multi-Factor-Authentication-Guidance-v1.pdf

10.8, 10.8.1 : Mettre en place une procédure permettant de détecter les dysfonctionnements critiques des éléments de sécurité en temps réel (Service Provider seulement)

Une procédure de détection des dysfonctionnements critiques des éléments de sécurité doit être mise en place. Les éléments de sécurité comprennent, par exemple, les firewalls, les IDS/IPS, le logiciel d’intégrité, les antivirus, les mécanismes d’audit, les contrôles de segmentation, etc. La procédure doit quant à elle inclure la détection de ces dysfonctionnements, ainsi qu’un plan de réponse comprenant la restauration des fonctions de sécurité, l’identification de la durée et la cause de ces dysfonctionnements, la mise à jour de l’analyse de risque, etc.

Le document décrivant les procédures de surveillance quotidienne doit être modifié afin d’y intégrer ces éléments.

Concrètement, le fonctionnement de ces éléments de sécurité doit être supervisé en permanence. En complément, des contrôles ponctuels (revue mensuelle) peuvent être mis en place.

11.3.4.1 : Les tests d’intrusion des points de segmentation doivent être réalisés tous les 6 mois (Service Provider seulement)

Les tests d’intrusion sur les points de segmentation sont désormais à réaliser tous les 6 mois et après chaque changement significatif. La Politique de tests d’intrusion et de scans de vulnérabilités doit être mise à jour afin d’y intégrer la réalisation de ces tests.

12.4.1: Un responsable du programme PCI DSS doit être désigné (Service Provider seulement)

Une personne responsable du programme de conformité PCI DSS doit être clairement identifiée. Celle-ci devra établir une charte du programme de conformité PCI DSS et sera en charge de la communication avec les responsables de la société (Executive Management).

Une Charte de conformité PCI DSS doit être créée. Le document doit indiquer que la responsabilité de la conformité PCI DSS de l’entreprise doit être assignée par le comité de direction à un individu ou à une équipe. Celui-ci doit également décrire l’organisation du programme de conformité PCI DSS et les indicateurs de conformité à communiquer au comité de direction, afin que ce dernier puisse avoir une visibilité sur l’état du programme de conformité PCI DSS.

12.11, 12.11.1 : Une revue trimestrielle doit être effectuée afin de s’assurer que les employés suivent bien la politique de sécurité (Service Provider seulement)

Une procédure doit être définie pour confirmer que le personnel réalise bien la revue journalière des logs, la revue des règles de firewall, l’application des standards de sécurité ou encore la procédure de changement. Cette revue devra être documentée et signée par le responsable du programme de conformité (exigence 12.4.1). Le document décrivant les procédures de surveillance quotidienne doit être modifié afin d’y intégrer ces éléments.

Exigences applicables au 30 juin 2018 :

Au 30 juin 2018, l’utilisation de SSL3.0 et TLS1.0 sera proscrite. L’ensemble des services internes et externes devront proposer à minima du TLS1.1 et TLS1.2. Pour les POS/POI, l’utilisation de SSLV3 ou TLS1.0 sera encore autorisée si des vérifications ont été réalisées, prouvant qu’aucune exploitation des faiblesses de ces protocoles n’est possible. Ces changements étant prévus depuis 4 ans, il est primordial de s’assurer que la migration a été effectuée au 30 juin 2018.

Vos partenaires et vos clients doivent très rapidement être contactés pour qu’ils puissent anticiper ce changement majeur.

Toute l’équipe QSA d’XMCO reste bien entendu à votre disposition pour parler de ces changements et vous guider dans leur mise en oeuvre.

Annexes

Sources/références

• FAQ du PCI SSC sur l’implémentation de l’authentification multi-facteur :
  • https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/In-what-circumstances-is-multi-factor-authentication-required
  • https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Is-two-step-authentication-the-same-as-two-factor-or-multi-factor-authentication
  • https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/What-is-the-difference-between-multi-factor-authentication-and-two-factor-authentication
  • https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Is-two-step-authentication-acceptable-for-PCI-DSS-Requirement-8-3