Le standard PCI-DSS

À travers le consortium PCI SSC, les réseaux bancaires imposent leur standard de sécurité des données, plus connu sous le nom de PCI-DSS, aux banques qui l’imposent à leur tour, par contrat, à leurs prestataires et commerçants. Le but est simple, en cas de compromission chez un commerçant, le réseau concerné pourra infliger une lourde amende à la banque acquéreur – qui se défaussera éventuellement sur ledit commerçant – s’il y a manquement au référentiel PCI-DSS. Autant le dire, PCI-DSS résonne dans la tête de la plupart des acteurs monétiques de par son principe pyramidal. Mais au fait, qu’est-ce que le PCI-DSS ? Est-ce compliqué d’être certifié ? Devient-on sécurisé lorsqu’on est compliant PCI-DSS ? Autant de bonnes questions auxquelles cet article tâchera de répondre, en démontant au passage quelques mythes qui ont la vie dure.

Note : ce billet est une sous-partie de l’article PCI que vous pouvez relire pour avoir une vision plus générale.

PCI-DSS, pour Payment Card Industry – Data Security Standard, fait la distinction entre 2 types de données :

• les données du porteur – CHD (CardHolder Data) : numéro de carte (PAN : Primary Account Number), nom du titulaire, date d’expiration et code service ;
• les données d’identification sensibles – SAD (Sensitive Authentication Data) : données complètes de la bande magnétique, cryptogramme visuel, codes / blocs PIN.

Note : le code service est un code de 3 chiffres décrivant les utilisations possibles de la carte (paiement / retrait, domestique / à l’étranger, autorisation systématique, …). Ce code est considéré comme sensible parce qu’il intervient entre autres dans le calcul du cryptogramme de la piste.

Qu’est-ce que PCI-DSS ?

PCI-DSS est un standard de sécurité des données visant à limiter les risques de fuites des données bancaires comme le numéro de carte. Actuellement à sa version 3.1, ce standard est rédigé par les membres de PCI SSC, autrement dit par les réseaux bancaires (American Express, Discover, JCB, MasterCard et Visa). Ces derniers ont donc réussi à s’accorder sur un programme de sécurité qu’elles souhaitent voir appliquer dans la communauté.

Quand s’applique PCI-DSS ?

Un commerçant ou prestataire de services doit appliquer le standard PCI-DSS dès lorsque cela est stipulé dans son contrat avec sa banque acquéreur. Il peut toutefois négocier avec sa banque quant à l’application du standard en fonction de sa volumétrie de transaction. En effet, le risque n’est pas le même entre un commerçant acceptant plus d’1 million de transaction par an et un petit commerçant.

Le standard s’applique à la partie du système d’information par lequel passe le numéro de carte et/ou les données sensibles. Tous les composants du système d’information communiquant avec celui-ci sont également contaminés. Par ailleurs, PCI-DSS impose une transitivité, c’est-à-dire qu’une entité soumise à PCI-DSS est responsable aussi de l’application du standard chez ses sous-traitants. Vous voyez d’ores et déjà l’intérêt de segmenter son système d’information afin de réduire son périmètre. La 1ère étape qui vient très logiquement est donc la définition du périmètre d’application du standard.

Est-ce compliqué à mettre en œuvre ?

Le programme PCI-DSS se présente comme suit :

Programme détaillé de PCI-DSS [extrait du standard PCI-DSS]

Il s’agit d’exigences classiques et de bons sens.

Concentrons-nous uniquement sur le chapitre « Protection des données du titulaire ». En effet, nul besoin de s’attarder sur les autres qui s’éloignent de la monétique.

2 conditions sont à respecter pour être conforme avec la protection des données du titulaire :

• protéger les données du titulaire stockées ;
• chiffrer la transmission des données du titulaire sur les réseaux publics ouverts.

Protéger les données du titulaires stockées

L’idée sous-jacente est de ne pas stocker les données sensibles comme le cryptogramme visuel, de ne stocker les données d’identification du porteur comme le numéro de carte que si nécessaire, et le cas échéant de le protéger (troncature, hachage, chiffrement, tokenisation, …).

En outre, les données d’identification du porteur doivent être supprimées régulièrement et de manière sécurisée.

D’aucuns objecteront que le ticket du commerçant contient pourtant le numéro de carte en clair… C’est en effet une exigence du groupement des Cartes Bancaires CB afin de permettre aux commerçants de prouver une transaction en cas de litige. Que les commerçants se rassurent ! Contrairement à ce qu’on entend, PCI-DSS permet quand même de stocker ces données si cela est nécessaire dans le cadre de l’activité.

Chiffrer la transmission des données du titulaire sur les réseaux publics ouverts

Les flux véhiculant des informations relatives à la carte doivent être chiffrés au moyen d’algorithmes robustes. Exit donc les protocoles non sécurisés comme le ftp. Il faut privilégier leur homologue sécurisé comme le secure ftp dans le cas présent.

Par ailleurs, les numéros de carte ne devraient pas être envoyés via les messageries comme les mails, messageries instantanées, etc. À défaut, les numéros devront être rendus illisibles (troncature, hachage, etc.) ou chiffrés de manière robuste.

Une fois ces exigences respectées, suis-je conforme à PCI-DSS ?

Une fois les exigences du référentiel respectées, il convient de se faire auditer. Pour cela, et toujours en fonction de la volumétrie, plusieurs cas se présentent. QSA or not QSA, that is the question.

Cas où un auditeur QSA (Qualified Security Assessor) est requis

Si le nombre de transaction est supérieur à 6 millions par an (resp. 300 000), si le commerçant (resp. le prestataire de services) a été victime l’année précédente d’un piratage ou si la banque l’exige tout simplement, un audit sur site par un QSA sera obligatoire.

Note : pour rappel, un QSA est un auditeur qui a obtenu une accréditation PCI-DSS auprès de PCI SSC et appartenant à une entreprise elle-même accréditée QSA (on parle de QSA company).

Concrètement, le QSA viendra sur site afin de réaliser un audit et vérifiera si l’audité respecte bien le standard. Il commencera par en définir le périmètre (accordez donc bien vos violons avant de commencer les travaux pour éviter toute déconvenue…).

Ensuite, plusieurs points de contrôles précisés par le PCI SSC sont à faire par le QSA. Pour justifier son travail et surtout se couvrir (vous le serez aussi de facto), le QSA récoltera également des preuves. Toutes ces données seront consignées dans un document appelé ROC (Report On Compliance). Ce document long de plus de 200 pages explique en partie les coûts importants d’un audit PCI-DSS.

S’il s’agit de la première fois que le commerçant se fait auditer, il est conseillé de faire un audit à blanc. Le QSA détectera en effet très probablement, des manquements à certaines exigences. Selon la complexité de son système d’information, il peut également être intéressant de se faire accompagner par un QSA. Ce dernier vous orientera vers les solutions qui lui semblent les plus adéquates vis-à-vis de PCI-DSS. Pratique ! puisque c’est aussi lui qui auditera.

Par ailleurs, l’audité devra subir trimestriellement un scan de vulnérabilité par un prestataire certifié (ASV). Pas grand chose à dire « monétiquement » parlant. Cela a pour but de détecter les failles de sécurité à distance sur le site.

Le ROC, ainsi qu’une attestation de conformité (AOC – Attestation Of Compliance) signée conjointement entre le QSA et l’audité seront envoyés à la banque.

Cas où un auditeur QSA (Qualified Security Assessor) n’est pas requis

Pour les autres commerçants ou prestataires de services, ils pourront s’autocertifier. C’est-à-dire qu’ils n’auront qu’à remplir un simple document, appelé SAQ (Self-Assessment Questionnaire) ainsi que l’AOC et l’ASV.

Maintenant que je suis PCI-DSS, mon système d’information est donc sécurisé ?

Objection votre honneur ! Pour rappel, tout le système d’information ne fait pas partie du périmètre PCI-DSS. Aussi faut-il s’assurer de la sécurité sur les composants exclus. De plus, si la conformité à PCI-DSS est un bon pas vers la sécurisation de son système d’information, elle n’est clairement pas suffisante. ISO 27001 et ISO 27002 ont encore de beaux jours devant eux !

Publicité