PCI DSS version 3, les nouveautés attendues en 2013

Comme chaque année le PCI SSC a rassemblé « sa communauté » autour de son Community Meetings, événement majeur pour échanger avec les QSAs, les réseaux cartes, les clients, fournisseurs et tout autre acteur concerné par PCI. La cinquième édition de cet événement s’est clôturée en octobre 2012 à Dublin avec son lot de nouveautés pour 2013.

La publication officielle de la version 3 de PCI DSS est attendue pour octobre 2013 (la version intermédiaire devrait être disponible en avril 2013).  Cette version devrait clarifier (un peu plus) le périmètre PCI DSS alors que la communauté non PCI a déjà pris les devants avec l’initiative de l'Open PCI DSS Scoping toolkit.

La version 3 de PCI DSS fournira des orientations précises sur la définition du périmètre et la segmentation réseau requise. Notamment les règles suivantes issues principalement de retour d’expérience QSAs :

• Tout système impactant la sécurité de l’environnement de données porteurs est considéré dans le périmètre PCI,
• Pour être complètement hors périmètre PCI, un réseau ou un système doit être isolé de l’environnement de données porteurs sans aucune connectivité à ce dernier,
• La mise en œuvre de liste de contrôle d’accès (au niveau IP ou port) peut  limiter l’exposition de l’environnement de données porteurs mais ne supprime pas automatiquement les systèmes et les réseaux du périmètre si une connectivité existe,
• Dans le cas ou des connections à l’environnement de données porteurs sont limitées à des ports ou des services spécifiques, les systèmes concernés sont à prendre en compte dans le périmètre afin de vérifier que les exigences PCI DSS sont en place,
• Le QSA ou l’ISA doit également déterminer si les systèmes connectés ouvrent la porte ou fournissent un chemin vers d’autres systèmes dans l’environnement de données porteurs,
• Les exigences PCI DSS applicables peuvent varier et dépendre de la fonction du système et de la présence d’autres mesures en place,
• Les systèmes qui assurent des fonctions de troncage, masquage, tokénisation ou « hachage » des numéros de cartes sont dans le périmètre PCI et doivent être isolés de ceux qui les conservent,
• Les QSAs devront confirmer qu’un système ne peut pas impacter la sécurité de l’environnement de données porteurs afin de déterminer qu’il est hors périmètre.

Le PCI SSC devait en effet apporter plus de clarification sur le sujet du périmètre PCI car c’est un indispensable et surtout un axe stratégique à tout projet PCI DSS. Il est pour ma part un peu dommage de ne pas avoir clarifié le périmètre PCI dans les premières itérations de PCI DSS. L’inconvénient majeur qu’on peut attendre et clairement de ne pas avoir pris en compte ces mesures et d’avoir à inclure dans le périmètre des composants auxquels ont auraient jamais pensé à prendre en compte, l’Active Directory par exemple accompagné de la solution de sauvegarde entreprise !

Plus de clarifications des exigences PCI concernant le chiffrement des données porteurs :

• Les données porteurs chiffrées restent dans le périmètre PCI dans la mesure où ces données peuvent être déchiffrées avec une clé disponible au sein de l’entité,
• D’une manière générale les données chiffrées sont de la responsabilité de l’entité qui contrôles et ou dispose d’un accès aux données chiffrées et aux clés,
• Les données porteurs chiffrées peuvent être considérées hors périmètre PCI dans le cas uniquement où l’entité ne dispose pas des clés pour les déchiffrer (Il est donc possible de mettre hors périmètre des données chiffrées, c’est généralement déjà le cas lors de l’archivage de données ou de sauvegarde de données en reste au niveau d’une base de données par exemple),
• Les systèmes assurant les fonctions de chiffrement et déchiffrement de données porteurs, ainsi que tout système assurant des fonctions de gestion de clés sont toujours considéré dans le périmètre PCI.

Autres tendances discutés lors du PCI SSC Community Meetings :

• Exigence d’utiliser des fournisseurs de scans ASVs pour la réalisation des scans internes (pré-requis 11.2),
• Clarification des termes « si les données de titulaires de cartes sont partagés avec des prestataires de services » et fournir davantage de prescriptions standardisés d’accords écrits qui s'appliquent aux fournisseurs de services (pré-requis 12.8),
• Mise à jour des questionnaires d’auto-évaluation (SAQs) trop complexes,  difficile à comprendre ou pas assez détaillé,
• Mise à jour des exigences de mot de passe (et l’étendre au-delà des mots de passe). Les exigences de mot de passe actuelles sont soit trop stricte ou pas assez strict selon le PCI SSC (pré-requis 8.5),
• Etendre le périmètre d’éligibilité des exigences PA-DSS aux applications qui n’assurent pas de fonction de paiement, applications sur mesures ou embarquées dans les terminaux, 
• Développement d’exigences PA-DSS en réponse aux différentes technologies tel que tel le terminal mobile, EMV … 
• Tokenization : un nouveau standard (et sans doute une nouvelle certification de solutions à l’image de P2PE) devrait voir le jour en 2013.

Sécurité physique PCI

• Il n’est pas exclut de voir apparaitre de nouvelles exigences de sécurité physique dans la version 3 de PCI DSS (sans doute en réponse à la vague "skimming" qui ne cesse d'augmenter depuis plusieurs mois).

Une boite à outils pour définir son périmètre PCI

Une initiative intéressante de « l’Open Scoping Framework Group » qui à travers une démarche structurée et sa boite à outils vous accompagne dans la définition de votre périmètre PCI.

Les auteurs rappellent néanmoins que la démarche n’est à utiliser qu’à l’issue d’une première identification des données porteurs au sein de l’entreprise, rappelant que cette dernière doit être documentée et permettre d’identifier où les données porteurs sont conservées, transmises et traitées. Cette boite à outils peut être utilisé par les grandes et les petites avec comme différence évidente le nombre de systèmes retenus dans le périmètre PCI.

 

L’on retrouve dans la démarche proposée les grands principes d’une définition de périmètre très orientée QSAs à mon sens avec notamment une catégorisation des systèmes du périmètre PCI en fonction :

• Du type de traitement des systèmes dans le périmètre PCI, à savoir si les systèmes traitent, stockent ou transmettent des données porteurs,
• La fonction et le rôle des systèmes dans le périmètre PCI (exemple : système d’autorisation, d’authentification, de surveillance …),
• La connectivité entre les systèmes et l’environnement de données porteurs.

Outre le fait que cela permettra de faciliter le travail fastidieux de la définition du périmètre, cette boite à outils ne couvre que partiellement le périmètre PCI qui doit également inclure les processus, le personnel … en charge de l’environnement de données porteurs conformément aux conditions PCI DSS.

Pour ma part c’est une initiative intéressante, également pour les QSAs car une finalité même si elle n’est pas clairement exprimée est de faciliter la rédaction du ROC (Report On Compliance) requis pour valider la conformité PCI DSS. Il est dommage cependant que le PCI SSC ne soit pas plus impliqué dans cette initiative.

La démarche va plus loin que le standard PCI DSS qui catégorisent les composants soit dans le périmètre ou soit à l’extérieur avec une notion de système connecté qui reste à l’appréciation et la compréhension du QSA de votre environnement de données porteurs. 

Afin de faciliter la définition du périmètre PCI « l’Open Scoping Framework Group » a définit trois catégories de composants, et met en évidence les différents types de risques associés à chaque catégorie. Cela permet de mettre en avant les systèmes les plus importants à protéger à travers une approche par les types de risques qu'elles posent aux données porteurs. 

Chaque système au sein de l'environnement informatique d'une entreprise peut être classé en une seule opération :

• Catégorie 1 : les systèmes qui traitent, stockent et transmettent les données porteurs  ou non isolés ou limités par un accès contrôlé à partir d'autres systèmes de cette même catégorie,
• Catégorie 2 : les systèmes qui ont un accès contrôlé aux systèmes de la catégorie 1,
• Catégorie 3 : les systèmes isolés de tout système de la catégorie 1.