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 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).
Aucun commentaire:
Enregistrer un commentaire