PCI DSS 3.0 : les trois principaux changements
PCI DSS 3.0 n’est pas une révision complète. Mais selon Ed Moyle, expert PCI, ceux qui sont soumis à ce standard devraient engager immédiatement la migration.
Comme le savent sans aucun doute tous les RSSI devant se conformer à PCI DSS, le conseil des standards de sécurité (SSC) de l’industrie des cartes de paiement (PCI) a présenté la version 3.0 de PCI DSS.
Comme il l’a déjà fait par le passé, le SSC a fourni une synthèse des changements soulignant les différences entre les versions 2.0 et 3.0 du standard. Lorsqu’il a présenté PCI DSS 2.0 en 2010, le conseil a choisi de considérer qu’avec la maturité du standard en évolution, celui-ci nécessitera de moins en moins de changements. Ce n’est donc pas une surprise si la majorité des évolutions de PCI DSS 3.0 relèvent de clarifications, de complétements, plutôt que de nouvelles exigences.
Pour autant, et contrairement à la transition de PCI DSS 1.2.1 à 2.0, de nouvelles exigences émergent du fait des évolutions de la manière dont la technologie est utilisée tant par les commerçants que par les attaquants. Dans le détail, alors que passer de PCI DSS 1.2.1 à 2.0 n’impliquait que deux nouvelles exigences, passer à la version 3.0 en impliquera 20. Dans cinq domaines, ceux-ci auront un impact tout particulier pour les commerçants.
Tests d’infiltration
Le changement le plus visible concerne probablement les nouvelles exigences relatives aux tests d’infiltration (ou pentesting), ainsi qu’à la vérification des méthodes utilisées pour isoler l’environnement des données de porteurs de cartes des autres domaines du système d’information. La principale difficulté tiendra à l’impératif pour les commerçants, de suivre, pour leurs tests d’infiltration, une « méthodologie de test d’infiltration acceptée par l’industrie », telle que celle référencée NIST SP 800-115.
La bonne nouvelle est que cette exigence n’est qu’une « bonne pratique ». Mais uniquement jusqu’au 30 juin 2015. Las, malgré ce délai, se conformer à cette exigence risque d’être difficile, tout particulièrement car le pentesting est une activité très spécialisée, et que de nombreux commerçants ne disposent pas, en interne, des compétences requises. Ceux-ci font ainsi généralement appel à des prestataires tiers. Mais nombre d’entre eux ne basent pas encore leurs offres sur une méthodologie formalisée. Certes, certains ont déjà adopté NIST SP 800-115, ou s’appuient sur des standards tels que Penetration Testing Execution Standard ou l’OWASP Testing Guide. Mais ce n’est généralement pas le cas.
Dès lors, les marchants doivent être extrêmement scrupuleux dans le choix de leur prestataire de services de pentesting et s’assurer qu’il suit une méthodologie approuvée par l’industrie.
Inventorier les composants de l’infrastructure
La nouvelle exigence (2.4) a fait l’objet de moins de commentaires. Mais celle-ci, consistant au maintien d’un inventaire des composants de l’infrastructure dans le périmètre du standard, risque d’avoir un impact considérable. Dans ce contexte, un « composant » est défini en page 10 du standard. Pour l’essentiel, il s’agit de tout composant matériel ou logiciel situé dans l’environnement de données de porteurs de cartes (CDE).
Là, il s’agit de « vérifier qu’une liste des composants matériels et logiciels est tenue à jour et inclut la description de la fonction et de l’usage de chacun ». Dès lors, les commerçants ne doivent pas seulement documenter tous les composants du CDE ; ils doivent également documenter ce que font ces composants et pourquoi. L’exigence 11.1.1 dispose en outre que les commerçants doivent « maintenir un inventaire des points d’accès sans fil autorisés, en incluant une justification métier. »
Maintenir un inventaire n’est pas trivial. Historiquement, de telles exigences ont régulièrement été difficiles à satisfaire. Pourquoi ? Parce les éléments d’inventaire changent régulièrement. Et en tenir une liste à jour demande un effort manuel important. Dès lors, tenir à jour un inventaire complet des composants logiciels et matériels du CDE est pour ainsi dire impossible sans automatisation. Et même avec celle-ci, cela reste difficile.
La complexité augmente en outre avec l’ajout de la virtualisation ou lorsque l’environnement s’étend sur plusieurs régions géographiques. C’est également le cas lorsque des systèmes propriétaires, fournis par des équipementiers, sont maintenus par des tiers, qu’il s’agisse d’éditeurs ou d’intégrateurs systèmes. Il ne fait pas de doute que les équipes de conformité des commerçants vont passer beaucoup de temps à créer et gérer ces inventaires.
Relations avec les fournisseurs
Les exigences 12.8.5 et 12.9 appellent désormais à la documentation des exigences du standard qui sont placées sous la responsabilité de tiers et de celles qui restent gérées par l’organisation. Ainsi, pour une organisation utilisant un fournisseur de services de centre de calcul hébergé, les restrictions d’accès physique au centre de calcul sont susceptibles d’être gérées par son fournisseur, tandis que l’accès logique peut rester sous la compétence de l’entreprise. Dans ce cas, avec PCI DSS 3.0, le commerçant doit explicitement documenter la ségrégation des responsabilités entre lui et son prestataire.
Ainsi, il n’est plus seulement nécessaire de tenir à jour une liste de fournisseurs, comme c’était le cas précédemment, et de suivre leur conformité lorsque leurs services touchent au CDE. Il faut également maintenir une matrice des exigences PCI DSS et de l’attribution de responsabilité pour chaque fournisseur.
Etablir et gérer ces diverses matrices sera probablement difficile, pour deux raisons. Tout d’abord, cela suppose d’examiner tous les fournisseurs qui touchent au CDE. Mais cela suppose surtout d’analyser précisément le recours qu’il est fait de chacun. En pratique, les commerçants doivent savoir exactement ce que fait chacun de leurs prestataires et fournisseurs, et sous quelle responsabilité, puis créer un document décrivant tout cela. Le plus délicat peut-être ? Obtenir de chacun de ces prestataires d’engager formellement, par écrit, sa responsabilité. Et négocier cela s’avère généralement chronophage et difficile.
Protection contre les logiciels malveillants
L’exigence 5.1.2 entend désormais que les commerçants doivent « identifier et évaluer les menaces de logiciels malveillants » pour les « systèmes considérés comme n’étant pas communément affectés par des logiciels malicieux ». En d’autres termes, même pour un système qui n’est généralement pas affecté par des logiciels malveillants, il est nécessaire de disposer d’un processus garantissant qu’il en sera durablement ainsi. Ou qu’en cas d’infection, celle-ci sera détectée. De la même manière, l’exigence 5.3 demande désormais que des autorisations spécifiques soient délivrées par le management pour affecter, même temporairement, le fonctionnement des antivirus.
Suivant les entreprises, ces exigences devraient avoir un impact, notamment la seconde. Sous PCI DSS 2.0, le standard spécifiait uniquement l’impératif de l’installation d’un antivirus, opérationnel, à jour, et générant des logs. Des propriétés dont la présence était hautement probable. Désormais, il faut plus, et notamment que l’antivirus puisse empêcher l’utilisateur d’interrompre son fonctionnement. Ce qui se traduira par plus de planification technique et par une stratégie de déploiement plus fine pour vérifier le respect de cette exigence sur tout le CDE.
Accès physique et point de vente
La disposition 9.3 du standard exige désormais des commerçants qu’ils contrôlent l’accès physique des personnels sur site, suivant des autorisations spécifiques basées sur les fonctions des individus, et révoquées immédiatement en cas de départ. La disposition 9.9 exige pour sa part que les commerçants « protègent les terminaux captant les données de cartes bancaires »… contre les modifications et la substitution. La plupart des commerçants sont probablement déjà conformes aux exigences de la disposition 9.3, mais si certains utilisent leur local serveur en point de vente pour stocker des serviettes en papier, il est peut-être temps qu’ils arrêtent.
La conformité avec la disposition 9.9 est probablement plus délicate. Du point de vue du commerçant, elle n’est d’ailleurs par toujours applicable. Il suffit de penser aux petites échoppes, aux cabinets médicaux, aux taxis, etc. Toutes ces personnes sont-elles habituées à inspecter « périodiquement » leurs terminaux de point de vente ? C’est peu probable. Et l’impact d’une telle disposition est probablement considérable pour des activités commerciales très étendues géographiquement. En outre, les procédures de test disposent que les commerçants doivent maintenir la liste de leurs terminaux de points de vente. Probablement une bonne pratique, mais sûrement peu en vigueur aujourd’hui. Bref, tout cela sera très certainement complètement nouveau pour les administrateurs de sites et les gestionnaires de points de vente…
Conclusion
Pour certains commerçants, respecter ces nouvelles exigences demandera d’importants efforts. Et encore, celles-ci ne sont pas les seules. Et le contexte et la culture des entreprises joueront également un rôle dans l’adoption de PCI DSS 3.0. De quoi encourager à préparer la transition au plus vite. Sinon, les premières évaluations de conformité ne seront pas très plaisantes.
Adapté de l'anglais par la rédaction.
