Pci DSS

LES DOSSIERS TECHNIQUES
PCI DSS : une prsentation
Novembre 2009
Groupe de travail PCI DSS
CLUB DE LA SECURITE DE LINFORMATION FRANAIS

30, rue Pierre Smard, 75009 PARIS
Tl. : +33 1 53 25 08 80 Fax : +33 1 53 25 08 88 e-mail : clusif@clusif.asso.fr
Web : http://www.clusif.asso.fr
La loi du 11 mars 1957 n'autorisant, aux termes des alinas 2 et 3 de l'article 41, d'une part, que les "copies ou reproductions
strictement rserves l'usage priv du copiste et non destines une utilisation collective" et, d'autre part, que les analyses
et les courtes citations dans un but d'exemple et d'illustration, "toute reprsentation ou reproduction intgrale, ou partielle,
faite sans le consentement de l'auteur ou de ayants droit ou ayants cause est illicite" (alina 1er de l'article 40)
Cette reprsentation ou reproduction, par quelque procd que ce soit, constituerait donc une contrefaon sanctionne par les
articles 425 et suivants du Code Pnal
REMERCIEMENTS
Le CLUSIF tient mettre ici l'honneur les personnes qui ont rendu possible la ralisation de
ce document, tout particulirement :
AUTRET Thierry
GIE Cartes-Bancaires
BRISSE Franois
Capgemini
DI GIAMBATTISTA Vincent Egencia Europe

GREMY Jean-Marc
Cabestant Consultants
GREVREND Grald
Altran
LATRECHE Abdelbaset
Verizon Business
LUPONIS David
Mazars
MARET Vincent
E&Y
MEYNARD Samuel
Integralis
NABET Benjamin
Accor
PIEDERRIERE Yann
BT Services
SCHAUER Herv
Herv Schauer Consultants
SIMONETTI Rodolphe
Verizon Business
Nous remercions aussi les adhrents du CLUSIF ayant particip la relecture.
3/46
CLUSIF 2009
SOMMAIRE
I - INTRODUCTION............................................................................................................................................ 6
II - NOTIONS DE DONNEES PORTEUR ......................................................................................................... 7
III - PRESENTATION DES ACTEURS ............................................................................................................. 8
III.1 - LE PCI SECURITY STANDARDS COUNCIL (PCI-SSC)................................................................................ 8
III.2 - LES RESEAUX CARTES ............................................................................................................................... 9
III.3 - REPORTS DES CONTRAINTES PCI DSS ENTRE LES ACTEURS (SCHEMA)................................................... 12
III.4 - APERU ET COHERENCE DES STANDARDS PCI ........................................................................................ 13
III.4.1 - PCI PED........................................................................................................................................ 13
III.4.2 - PCI PA-DSS .................................................................................................................................. 13
III.4.3 - PCI DSS......................................................................................................................................... 13
IV - CYCLE DE VIE DU STANDARD PCI DSS............................................................................................. 15
IV.1 - ETAPE 1 IMPLEMENTATION MOIS 1 A 9 .............................................................................................. 15
IV.2 - ETAPE 2 RETOURS DEXPERIENCE MOIS 10 A 12................................................................................ 15
IV.3 - ETAPE 3 REVUE DES RETOURS DEXPERIENCE MOIS 13 A 20.............................................................. 15
IV.4 - ETAPE 4 ELABORATION ET FINALISATION DE LA NOUVELLE VERSION MOIS 21 A 24.......................... 16
IV.5 - ETAPE 5 PUBLICATION DE LA NOUVELLE VERSION DU STANDARD ....................................................... 16
V - PERIMETRE DAPPLICATION DU STANDARD PCI DSS ................................................................. 17
V.1 - DEFINITION DU PERIMETRE PCI DSS ....................................................................................................... 17
V.2 - ECHANTILLONNAGE ................................................................................................................................. 17
V.3 - LES SCANS ASV....................................................................................................................................... 18
VI - REDUCTION DU PERIMETRE PCI DSS ............................................................................................... 20
VI.1 - PRINCIPES DE REDUCTION DU PERIMETRE PCI DSS ................................................................................ 20
VI.2 - NOTION DE SEGMENTATION RESEAU APPROPRIEE ................................................................................... 21
VI.3 - FOURNISSEURS DE SERVICES ET REPORTS DE RESPONSABILITES ............................................................. 22
VI.4 - DEROGATION POUR CERTIFICATIONS DE PERIMETRES SPECIFIQUES ........................................................ 23
VI.5 - AUTRES ASPECTS CONCERNANT LA REDUCTION DU PERIMETRE .............................................................. 23
VI.6 - RESPONSABILITE VIS-A-VIS DES PRESTATAIRES ...................................................................................... 24
VII - STRATEGIE DE CONSERVATION DES DONNEES CARTE ........................................................... 25
VII.1 - QUELLES DONNEES CONSERVER ?.......................................................................................................... 25
VII.2 - MOTIVATION ET DUREE DE STOCKAGE DE CES DONNEES ....................................................................... 25
VII.3 - CONDITIONS DE STOCKAGE ET DUTILISATION DE CES DONNEES ........................................................... 25
VIII - LES MESURES COMPENSATOIRES................................................................................................... 27
VIII.1 - QUEST CE QUUNE MESURE COMPENSATOIRE ? ................................................................................... 27
VIII.2 - CONDITIONS DE LEGITIMITE DUNE MESURE COMPENSATOIRE ............................................................. 27
VIII.3 - CONDITIONS DE VALIDITE DUNE MESURE COMPENSATOIRE ................................................................. 28
VIII.4 - ILLUSTRATION DUNE MESURE COMPENSATOIRE .................................................................................. 28
IX - PCI DSS, VERITES ET CONTRE VERITES .......................................................................................... 30
4/46
CLUSIF 2009
IX.1 - MATERIEL OU LOGICIEL CERTIFIE PCI DSS ...................................................................................... 30

IX.2 - DEBAT EMV CONTRE PCI DSS .............................................................................................................. 30
IX.3 - FRAUDE DECLAREE ................................................................................................................................. 30
X - LIENS AVEC LES AUTRES NORMES, STANDARDS, REFERENTIELS ET
REGLEMENTATIONS ..................................................................................................................................... 31
X.1 - ISO 27001................................................................................................................................................ 31
X.2 - COBIT, ITIL ET ISO 27002....................................................................................................................... 31
X.3 - CNIL ET AUTRES LOIS .............................................................................................................................. 32
X.4 - REFERENTIELS TECHNIQUES ..................................................................................................................... 32
XI - AVANTAGES, DIFFICULTES ET LIMITES DUNE DEMARCHE PCI DSS ................................... 34
XI.1 - AVANTAGES............................................................................................................................................ 34
XI.2 - DIFFICULTES ........................................................................................................................................... 34
XI.3 - LIMITES................................................................................................................................................... 34
XII - CONCLUSION DU DOCUMENT ............................................................................................................ 35
XIII - ANNEXE 1 : GLOSSAIRE....................................................................................................................... 36
XIII.1 - TERMES PCI DSS ................................................................................................................................. 36
XIII.2 - TERMES LIES A DAUTRES NORMES, STANDARDS OU REFERENTIELS ..................................................... 37
XIII.3 - TERMES DE MONETIQUE........................................................................................................................ 37
XIII.4 - AUTRES TERMES ................................................................................................................................... 38
XIV - ANNEXE 2 : ANALYSE COMPARATIVE PCI DSS, ISO 27001, COBIT......................................... 39
XV - ANNEXE 3 : BIBLIOGRAPHIE .............................................................................................................. 45
5/46
CLUSIF 2009
I - Introduction
En France, dbut 2009, les acteurs bancaires ont clairement annonc leur soutien au standard
PCI DSS, tel cet extrait du site Web du Groupement des Cartes Bancaires CB :
La communaut bancaire franaise et le Groupement Cartes Bancaires CB partagent
les objectifs du standard PCI DSS, eux-mmes dclins partir des standards ISO 27001
de scurit des systmes dinformation, en visant un haut niveau de protection des
donnes sensibles des cartes. La communaut considre que les objectifs de scurit
dfinis par le rfrentiel PCI DSS correspondent ltat de lart de ce que recommandent
aujourdhui les experts pour scuriser les bases de donnes, les changes dinformations,
pour protger les contrles daccs, Depuis plusieurs annes, tous les acteurs
concerns ont lanc des programmes de scurisation de ces donnes sensibles ; ce jour,
de nombreux commerants et prestataires de services ont dj termin ou sont sur le point
de finaliser leur mise en conformit PCI DSS.
Visa, MasterCard, American Express, Discover et JCB ont fond en 2006 le Payment Card
Industry Security Standards Council (PCI SSC) avec pour objectif de dfinir un rfrentiel de
scurisation des donnes carte bancaires sappuyant sur des bonnes pratiques : PCI DSS. Ce
rfrentiel sapplique toute entit qui traite et/ou stocke de la donne carte.
Si les chances donnes par les organismes cartes concernant la conformit sont chues,
lapplication des pnalits est envisage au cas par cas dans les relations contractuelles entre
les diffrents acteurs. A titre indicatif les pnalits publies par VISA Inc. sont de lordre de
25 000$ mensuels en cas de non-conformit et de 500 000$ damende en cas de
compromission avre.
En effet, depuis la fin des annes 1990, plusieurs fraudes massives ont touch les systmes
dinformations qui traitent des donnes carte, en voici quelques exemples :
CardSystems Solutions Inc (Fournisseur de service de paiements)

Une faille de scurit a entran la compromission de 40 millions de cartes en 2005, cette
socit a fait faillite depuis.
http://www.ftc.gov/opa/2006/02/cardsystems_r.shtm
TJX : Groupe de distribution (commerce) prsent aux Etats-Unis et en Europe.

Une faille concernant un rseau sans fil aurait conduit la compromission de 45,6
millions de numros de cartes en 2006.
http://www.securityfocus.com/news/11455
Royal Bank of Scotland WorldPay Inc. : activit fournisseur de services de paiement aux
Etats-Unis de la banque anglaise RBS.
Une fraude concernant potentiellement 1,5 million de numros de cartes a t identifie
en 2008.
http://www.rbslynk.com/RBS_WorldPay_Press_Release_Dec_23.pdf
Heartland Payment Systems Inc. (Fournisseur de service de paiements).

De multiples systmes dcoutes ont t trouvs sur les systmes de la socit Heartland
en 2008, compromettant ainsi environ 130 millions de cartes.
http://www.2008breach.com
6/46
CLUSIF 2009
II - Notions de donnes porteur

Les donnes porteur correspondent aux donnes lies au porteur de la carte de paiement qui
sont fournies au commerant ou rcupres par le commerant lors dune transaction de
paiement.
Celles-ci sont constitues des informations
suivantes :
Donnes des porteurs de carte devant faire

lobjet dune protection :
1. Numro de compte primaire (PAN,
Primary Account Number) ;
6
3, 5, 7
2. Nom du titulaire de la carte de crdit ;

3. Code de service ;
4. Date d'expiration.
Donnes dauthentification sensibles dont le

stockage est interdit aprs lautorisation de
la transaction :
5. Donnes de bandes magntiques

compltes ou leur quivalent stock sur
la puce ;
6. Le code CAV2/CVC2/CVV2/CID (appel galement cryptogramme visuel): code 3
chiffres au dos de la carte utilise pour les transactions distance, type Internet (le
nom diffre selon la marque de la carte) ;
7. Bloc PIN (qui est une version chiffre du code PIN).
Les donnes porteur sont sensibles pour plusieurs raisons :
Elles peuvent permettre de passer des transactions de paiement (numro, nom du porteur,
date de validit, CVV2, PIN), et donc entraner des fraudes. Parfois un simple PAN
permet de raliser une transaction ;
Elles peuvent permettre didentifier le porteur (nom du porteur, numro de carte) et sont
donc considres comme des informations indirectement nominatives par la CNIL ;
Le numro de carte est parfois utilis comme identifiant dans des applications, ce qui peut
permettre de faire le lien avec des personnes ;
Elles peuvent permettre de rcolter des informations sur les cartes de paiement (type de
transactions autorises, pays metteur, etc.) et donc de cibler des utilisations
malveillantes.
Il est important davoir lesprit que ces donnes nappartiennent ni au porteur ni au

commerant, mais lmetteur de la carte conformment au contrat porteur.
7/46
CLUSIF 2009
III - Prsentation des acteurs
III.1 - Le PCI Security Standards Council (PCI-SSC)

En 2006, Visa, MasterCard, American Express, Discover et JCB ont fond le Payment Card
Industry Security Standards Council (PCI SSC) afin de maintenir des rfrentiels communs
tels que les rfrentiels dexigences des programmes PCI DSS, PCI PA-DSS et PCI PED.
Figure 1 : source PCI SSC
Les exigences de conformit PCI sont en alignement avec les programmes de gestion des
risques des rseaux cartes :
American Express :
Data Security Operating Policy (DSOP);
Discover :
Discover Information Security Compliance (DISC);
JCB :
Data Security Program ;
MasterCard :
Site Data Protection (SDP);
Visa USA :
Cardholder Information Security Program (CISP);
Visa Europe :
Account Information Security Program (AIS).
Si les rseaux se sont entendus pour dfinir une norme commune, ils gardent chacun la
matrise de leurs risques. Chaque rseau a ainsi mis en place, dans le cadre de ses programmes
8/46
CLUSIF 2009
de gestion des risques, un programme spcifique charg de la mise en application de la norme

PCI-DSS au sein de son primtre
Les objectifs du PCI SSC sont :
Emettre et grer le cycle de vie des standards PCI (PCI DSS, PCI PA-DSS, PCI PED) ;
Amliorer la scurit des paiements ;
Susciter une prise de conscience et acclrer ladoption des standards PCI ;
Favoriser la participation des banques, marchands et Payment Service Providers ;
Grer le processus de qualification et de validation des QSA (Qualified Security

Assesor), ASV (Approved Scan Vendor), et des laboratoires PED (Pin Entry Device) ;
Maintenir les listes des QSA, ASV et PED certifis.
Les ressources mises disposition par le PCI SSC sont :
Les standards PCI DSS, PCI-PA-DSS et PED-DSS et la documentation lie ceux-ci :
PCI Data Security Standard ;
PCI DSS Security Audit Procedures ;
PCI DSS Security Scanning Procedures ;
PCI DSS Self Assessment Questionnaires (SAQ) ;
PCI PED Standard ;
PCI Payment Application Data Security Standard (PA-DSS).
PCI SSC FAQ ;
PCI SSC Education, ces cours sadressent lensemble des acteurs concerns ;
Participation au PCI SSC (rgles de fonctionnement, formulaire dadhsion) ;
Ces documents sont disponibles sur le site Web du PCI SCC :

https://www.pcisecuritystandards.org
III.2 - Les rseaux cartes

Les rseaux cartes grent directement :
Les modalits dapplication des standards PCI ;
Les frais, pnalits et chances pour la conformit ;
Le processus de validation ;
Lapprobation et publication des entits conformes PCI DSS et PCI-PA-DSS ;
La dfinition des niveaux des marchands et fournisseurs de services ;
Les investigations (Forensics) et rponses aux compromissions.
9/46
CLUSIF 2009
Ces documents sont disponibles sur les sites Web des metteurs de cartes :
http://www.visaeurope.com/aboutvisa/security/ais/aisprogramme.jsp
http://usa.visa.com/merchants/risk_management/cisp.html
http://www.mastercard.com/sdp/
http://www.americanexpress.com
http://www.discovernetwork.com/fraudsecurity/disc.html
http://www.jcb-global.com/english/jdsp/index.html
Voici une prsentation synthtique des niveaux de marchands et de fournisseurs de services
de paiement pour Visa, MasterCard et American Express prenant en compte les critres, les
lments ncessaires la conformit ainsi que les acteurs qui doivent fournir ou valider ces
lments. Ces critres tant sujets volution, il est conseill de se rfrer aux sites de
diffrents rseaux cartes.
En cas de doute, un marchand ne doit pas hsiter contacter sa ou ses banque(s) acqureur(s).
10/46
CLUSIF 2009
Marchands :
Type
Critres
Marchand
Visa: plus
transactions
(niveau 1)
Elments ncessaires
la conformit :
de
(Millions)
de
Qui doit
fournir/raliser ces
lments :
Audit sur site annuel

rcurrent
QSA
(Qualified
Security Assessor )
Scan ASV trimestriel
ASV (Approved
Scan Vendor)
Questionnaire annuel
dauto
valuation
(SAQ)
Marchand
JCB: moins de 1 M de transactions
ASV (Approved
Scan Vendor)
Visa: e-commerce de 0,02 M 1 M de

transactions annuelles
dauto
valuation
(SAQ)
Marchand
AMEX: moins de 0,05 M de transactions
ASV (Approved
Scan Vendor)
Visa: moins de 1M de transactions tous

canaux confondus ou moins de 0,02 M de
transactions e-commerce.
dauto
valuation
(SAQ)
Marchand
ASV (Approved
Scan Vendor)
MasterCard: plus de 6 M de transactions

AMEX: plus de 2,5 M de transactions
JCB : plus de 1 M de transactions
DISCOVER : plus de 6 M de transactions
Marchand
Visa: 1 6 M de transactions
(niveau 2)
MasterCard: 1 6 M de transactions
AMEX: 0,05 M 2.5 M de transactions
Marchand
(niveau 3)
MasterCard: e-commerce de 0,02 M 1

M de transactions annuelles
Marchand
(niveau 4)
MasterCard: tous les autres marchands.
11/46
CLUSIF 2009
Fournisseurs de services de paiement (PSP) :

Type
Critres
PSP
Visa: plus de 0,3 M de transactions
(niveau 1)
MasterCard: plus de 1M de transactions
Elments ncessaires
la conformit :
AMEX : tous les PSP
Qui doit
fournir/raliser ces
lments :
Audit sur site annuel

rcurrent
QSA (Qualified
Security Assessor)
ASV (Approved
Scan Vendor)
Questionnaire dauto
valuation (SAQ)
PSP
JCB: tous les PSP

Discover: tous les PSP
PSP
Visa: moins de 0,3 M de transactions
(niveau 2)
MasterCard: moins de 1 M de transactions
ASV
III.3 - Reports des contraintes PCI DSS entre les acteurs (schma)
Les flches indiquent le report de responsabilit dun acteur sur un autre. Le rle du QSA peut
tre daccompagner ce report.
12/46
CLUSIF 2009
III.4 - Aperu et cohrence des standards PCI

Le PCI Standard Security Council labore et maintient lensemble de la documentation
relative la protection des donnes carte bancaires sur lensemble de la chane de paiement.
Cette chane est diffrente selon que la carte est prsente ou non et elle utilise diffrents
maillons chez laccepteur (le commerant), lacqureur (la banque ou le fournisseur de
services) ou le rseau de transport de la transaction.
A la fin 2009, PCI SSC maintient trois rfrentiels principaux qui sappliquent aux trois
maillons que sont le dispositif de saisie du code confidentiel, lapplication de paiement et le
systme dinformation grant les donnes sensibles du porteur de carte bancaire.
Leurs dnominations sont les suivantes : (Cf. Fig1)
PCI PED : PIN Entry Device ;
PCI PA-DSS : Payment Application Data Security Standard ;
PCI DSS : Data Security Standard.
III.4.1 - PCI PED

Le rfrentiel PCI PED concerne les caractristiques de lquipement physique qui impactent
la scurit de la saisie du code confidentiel du porteur (PIN) lors dune transaction de
paiement. Ce rfrentiel concerne uniquement les constructeurs de dispositifs de saisie de
code.
Les caractristiques de scurit portent principalement sur le clavier de saisie du code,
lenceinte contenant les cls cryptographiques, lintgrit du firmware et lafficheur.
Un constructeur de terminaux de paiement ou de bornes de distribution de produits peut
intgrer un dispositif certifi PCI PED.
III.4.2 - PCI PA-DSS
Le rfrentiel PA-DSS sapplique aux socits ou prestataires qui dveloppent des
applications de paiement qui conservent, traitent ou transportent des donnes porteur dans le
contexte des transactions dautorisation ou de rglement, quand ces applications sont vendues
ou distribues des tierces parties (il ne concerne pas les applications dveloppes en un seul
exemplaire pour un usage interne).
Ce rfrentiel rassemble un ensemble de rgles de scurit qui visent minimiser les brches
de scurit potentielles des applications de paiement.
Une application de paiement peut sappuyer, entre autres, sur des composants de saisie de
code PCI PED.
Lutilisation par un commerant dune application de paiement certifie PA-DSS peut laider
mais ne suffit pas devenir conforme aux exigences PCI DSS.
III.4.3 - PCI DSS
Le rfrentiel PCI DSS sapplique aux systmes dinformation des diffrents acteurs de la
chane de paiement, commerant, banque acqureur ou prestataire de services de paiement. Le
SI concern est celui qui conserve, traite ou transporte des donnes sensibles du porteur de
carte. Lacteur concern peut utiliser une application de paiement dj certifie PA-DSS afin
de faciliter sa mise en conformit mais ceci ne suffit pas car des exigences complmentaires
13/46
CLUSIF 2009
portent en particulier sur les aspects de politique de scurit de lorganisation et sur les
habilitations des personnels.
Le rfrentiel PCI DSS V1.2 est constitue de 12 sries de clauses (exigences) rparties en 6
sections, formant ainsi 252 procdures de test avec contrles (en place - pas en place - date
cible / commentaires).
Cration et gestion dun rseau scuris

1. Installer et grer une configuration de pare-feu pour protger les donnes des titulaires de cartes.
2. Ne pas utiliser les mots de passe systme et autres paramtres de scurit par dfaut dfinis par le
fournisseur.
Protection des donnes des titulaires de cartes de crdit

3. Protger les donnes des titulaires de cartes stockes.
4. Crypter la transmission des donnes des titulaires de cartes sur les rseaux publics ouverts.
Mise jour dun programme de gestion des vulnrabilits

5. Utiliser des logiciels antivirus et les mettre jour rgulirement.
6. Dvelopper et grer des systmes et des applications scuriss.
Mise en oeuvre de mesures de contrle daccs strictes

7. Restreindre l'accs aux donnes des titulaires de cartes aux seuls individus qui doivent les connatre.
8. Affecter un ID unique chaque utilisateur dordinateur.
9. Restreindre laccs physique aux donnes des titulaires de cartes.
Surveillance et test rguliers des rseaux

10. Effectuer le suivi et surveiller tous les accs aux ressources rseau et aux donnes des titulaires de cartes.
11. Tester rgulirement les processus et les systmes de scurit.
Gestion dune politique de scurit des informations

12. Grer une politique qui assure la scurit des informations des employs et des sous-traitants.
Figure 2 : Les 6 sections et les 12 sries de clauses de PCI DSS version 1.2
Figure 3 : extrait des Conditions et procdures d'valuation de scurit PCI DSS version 1.2 (source :
https://www.pcisecuritystandards.org/pdfs/pci_dss_french.pdf )
14/46
CLUSIF 2009
IV - Cycle de vie du standard PCI DSS

Le standard PCI DSS est actuellement dans sa rvision 1.2 qui date doctobre 2008.
Le standard PCI DSS suit des cycles de 24 mois qui se dcomposent comme suit :
IV.1 - Etape 1 Implmentation mois 1 9

pour PCI DSS 1.2 : du 1/10/08 au 30/06/09
Les neuf premiers mois qui suivent la dernire rvision du standard PCI DSS permettent la
mise en place de celui-ci.
Cette priode permet aux organisations dadresser les changements apports par cette
nouvelle rvision du standard. Cest durant cette tape que le PCI Council met jour
lensemble des documents en support du standard.
IV.2 - Etape 2 Retours dexprience mois 10 12

pour PCI DSS 1.2 : du 1/07/09 au 30/09/09
Cette tape permet de prendre en compte des retours dexprience qui participeront
lvolution du standard travers un processus formel.
IV.3 - Etape 3 Revue des retours dexprience mois 13 20

pour PCI DSS 1.2 : du 1/10/09 au 31/05/10
15/46
CLUSIF 2009
Durant cette tape qui dure 8 mois, le PCI SSC compile des retours de la part de toutes les
parties prenantes (organisations participantes, QSA, ASV, Board of Advisor, communaut).
Le groupe de travail technique du PCI SSC analyse ces retours et en fonction de ceux-ci prend
lune des mesures suivantes :
Aucune action : si le retour nest pas jug pertinent ;
Ralisation de documents complmentaires permettant de supporter la version actuelle

(complment de FAQ, whitepaper, supplments dinformations ) ;
Edition dune nouvelle rvision de PCI DSS (eg : version 1.3) ;
Edition dune nouvelle version de PCI DSS (eg : version 2.0).
IV.4 - Etape 4 Elaboration et finalisation de la nouvelle version

mois 21 24
pour PCI DSS 1.2 : du 1/06/10 au 30/09/10
Cette quatrime tape permet au PCI SSC de finaliser la nouvelle version ou rvision de PCI
DSS en vue de sa publication. Le PCI SSC fournit une liste des modifications (summary of
changes) la communaut ainsi que la date de publication de cette nouvelle version ou
rvision.
IV.5 - Etape 5 Publication de la nouvelle version du standard

Cette dernire tape clt le cycle par la publication de la nouvelle version du standard. Le
cycle peut reprendre pour une nouvelle version.
16/46
CLUSIF 2009
V - Primtre dapplication du standard PCI DSS
V.1 - Dfinition du primtre PCI DSS

Pour les entreprises soumises au standard PCI DSS, le primtre dapplication inclut tous les
composants rseaux, systmes et applicatifs qui traitent, stockent ou supportent les donnes
des porteurs de carte ainsi que les lments connects ceux-ci.
De ce fait, les lments suivants sont impacts :
Tous les systmes, les serveurs, les applications ou les composants rseaux inclus dans,
ou relis l'environnement de donnes de dtenteurs de carte :
o Les composants rseau, notamment les firewalls, les commutateurs, les routeurs,
les points d'accs sans fil, les quipements de rseau, et les autres quipements de
scurit ;
o Les serveurs, notamment les serveurs Web, de bases de donnes,
dauthentification, de DNS, de courrier, et de synchronisation horaire (NTP) ;
o Les applications, que ce soit les applications dveloppes en interne ou les
progiciels, quelles soient accessibles en interne ou externe.
Tous les utilisateurs et postes utilisateurs accdant ces composants, que ce soit pour des
besoins mtiers ou informatiques, depuis les points de vente, les datacenter ou des
bureaux ;
Tous les raccordements lenvironnement des donnes de porteur de carte, par exemple :
accs distance des employs, passerelles de paiement, banques, entreprises de cartes de
paiement, centres dappels, accs de tiers pour traitement, et tierce maintenance.
Ce dernier point fait apparatre la notion dentreprises externes (type fournisseurs, partenaires,
mainteneurs rseau/systme/applicatif) qui peuvent accder logiquement ou physiquement
lenvironnement des donnes des porteurs de cartes et peuvent donc ventuellement en
affecter la scurit en accdant par exemple des numros de cartes. Si ces entreprises ne
respectaient pas les rgles de scurit demandes par le standard, elles pourraient constituer
un maillon faible. Ces entreprises sont donc incluses dans le primtre PCI DSS sous la
notion de Fournisseurs de Services dcrite plus loin.
V.2 - Echantillonnage
Les audits sur site et les scans depuis Internet ne portent pas sur la totalit du primtre PCI
DSS de lentreprise, notamment pour des raisons de cot. Il existe donc la notion de
primtre PCI DSS dj aborde et la notion dchantillon daudit que nous allons
maintenant prsenter.
Voici la dfinition de lchantillonnage, telle quelle est propose dans la version 1.2 du PCI
DSS :
Lvaluateur peut slectionner des chantillons reprsentatifs des installations de
lentreprise et des composants du systme en vue dvaluer leur conformit aux clauses du
standard PCI DSS.
17/46
CLUSIF 2009
Ces chantillons doivent inclure aussi bien des installations de lentreprise que des
composants du systme, ils doivent reprsenter une slection de tous les types et
emplacements des installations de lentreprise ainsi que des types de composants du systme,
et ils doivent tre suffisamment nombreux pour garantir lvaluateur que les mesures de
scurits sont mises en uvre comme prvu.
Les installations de lentreprise comprennent, par exemple, les bureaux, les magasins, les
commerants franchiss et les installations diffrents emplacements. Lchantillonnage doit
inclure les composants du systme de chaque installation de l'entreprise. Par exemple, pour
chaque installation de lentreprise, il convient dinclure divers systmes d'exploitation,
fonctions et applications lis au domaine valu. Au sein de chaque installation de
lentreprise, lexaminateur peut choisir les serveurs Sun excutant le navigateur Web Apache,
les serveurs Windows excutant Oracle, les systmes mainframe excutant les applications
traditionnelles de traitement de cartes, les serveurs de transfert de donnes excutant HP-UX
et les serveurs Linux excutant MYSQL. Si toutes les applications sexcutent partir dun
systme dexploitation unique (par exemple, Windows ou Sun), l'chantillon doit tout de
mme inclure diverses applications (par exemple, serveurs de bases de donnes, serveurs
Web et serveurs de transfert de donnes).
Lorsquils choisissent des chantillons dinstallations dentreprise et de composants de
systme, les valuateurs doivent prendre en compte les facteurs suivants :
Si chaque installation est tenue de respecter des processus PCI DSS obligatoires
standard, l'chantillon peut tre plus petit que celui ncessaire en labsence de
processus standard, afin de garantir que chaque installation est configure
conformment au processus standard.
Si plusieurs types de processus standard sont en place (par exemple, pour diffrents
types de composants du systme ou dinstallations), lchantillon doit alors tre
suffisamment diversifi pour inclure les composants du systme ou les installations
scuriss avec chaque type de processus.
Si aucun processus PCI DSS standard nest en place et si chaque installation est
responsable de ses propres processus, l'chantillon doit tre encore plus important de
manire sassurer que chaque installation comprend et applique correctement les
clauses du standard PCI DSS.
Luniformisation des configurations et des architectures prend alors toute sa valeur,

puisquelle permet de dmontrer beaucoup plus simplement la conformit du primtre PCI
DSS de lentreprise.
Il est galement noter que lchantillon peut tre revu la hausse en cours daudit si
lauditeur dcouvre un niveau dhomognit moindre que celui initialement escompt.
Il est important de noter que le choix de lchantillon et de la taille de lchantillon est de la
responsabilit de lauditeur. Le rapport de conformit doit prciser lchantillon retenu et les
raisons du choix de cet chantillon dans le respect du cadre dfini par le standard.
V.3 - Les scans ASV

Ces scans doivent tre raliss par une entreprise agre ASV (Approved Scan Vendor). La
liste de ces entreprises est disponible sur le site du PCI SSC.
Le standard PCI DSS prvoit que toutes les adresses IP de lentreprise visibles depuis Internet
doivent faire l'objet d'un scan trimestriel destin dtecter les vulnrabilits potentielles.
18/46
CLUSIF 2009
Lobjectif est de minimiser les risques dintrusion depuis Internet vers les systmes contenant
les donnes carte.
De manire gnrale, les mthodes de segmentation ci-aprs peuvent tre utilises pour
rduire le primtre du scan de scurit ASV :
la mise en uvre dune sparation physique entre le segment grant les donnes de
titulaire de carte et d'autres segments ;
le recours une segmentation logique approprie lorsque tout trafic est interdit entre le
segment ou rseau grant des donnes de porteur de carte et d'autres rseaux ou segments.
Il incombe en dernier ressort aux commerants et aux fournisseurs de services de valider le

primtre de leur scan de scurit PCI en cohrence avec les procdures de scans.
Si une atteinte la scurit des donnes dun compte survient par le biais dune adresse IP ou
dun composant qui nest pas inclus dans le balayage, le commerant ou le prestataire de
services est responsable.
19/46
CLUSIF 2009
VI - Rduction du primtre PCI DSS
VI.1 - Principes de rduction du primtre PCI DSS

La rduction du primtre dapplication du standard PCI-DSS consiste identifier les 5 10%
des composants du SI qui manipulent rellement des donnes sensibles de faon rduire le
primtre du SI auditer.
Afin de rduire le primtre de PCI DSS, plusieurs actions sont mises en uvre sparment
ou conjointement :
Isoler les applications et composants qui manipulent des donnes sensibles laide dun
cloisonnement appropri (voir plus loin) ;
Chiffrer les flux afin de permettre d'exclure tous les composants intermdiaires du rseau
(switchs, routeurs) du primtre. Exemples : IPSec ou SSL utiliss pour chiffrer les
changes entre serveurs ou entre les postes clients et les serveurs ;
Tronquer le PAN de faon le rendre inexploitable (supprimer du PAN les chiffres

significatifs) ou le remplacer par un identifiant unique (par exemple un hash). Les
applications qui utilisent ou stockent cette valeur tronque sont alors exclues du primtre
PCI DSS. En France, pour tronquer un PAN, il faut garder les six premiers chiffres et les
quatre derniers, ce qui peut tre diffrent pour dautres rglementations ;
Masquer laffichage du PAN aux utilisateurs pour une application qui le stocke de faon
intgrale (en France, n'afficher que les six premiers chiffres et les quatre derniers) permet
dexclure lenvironnement des postes clients qui nont alors plus accs aux donnes
sensibles ;
Chiffrer les donnes dans les bases de donnes d'un point de vue applicatif permet de
rduire le primtre concernant les administrateurs. Lapplication est toujours incluse
dans le primtre mais son exploitation est carte ;
Chiffrer ou tronquer les donnes dans les sauvegardes permet d'exclure le stockage des
sauvegardes du primtre daudit ;
Transfrer le risque vers des prestataires externes en externalisant certaines prestations.

Lentit doit nanmoins sassurer contractuellement et par contrle de la conformit de
son prestataire. Il est important de vrifier que la responsabilit ainsi transfre au
prestataire na plus besoin dtre assure en interne. Dans le cadre dun audit, le QSA
devra pouvoir auditer le prestataire ;
Utiliser des matriels et logiciels certifis (essentiellement pour les terminaux de

saisie des codes PIN ou certaines applications de paiement) afin de reporter la
responsabilit sur ce prestataire (en ayant pris soin de formaliser sa conformit et un droit
daudit).
Pour rappel, le standard PCI DSS se focalise sur les risques de capture en masse de donnes
sensibles. C'est--dire quun poste isol en centre dappel qui ne peut capturer quune donne
isole suite lappel dun utilisateur mais ne peut pas extraire des donnes dune application
est exclu du primtre daudit.
20/46
CLUSIF 2009
La rduction du primtre implique de revoir les processus mtiers car trs souvent le
numro de carte est utilis par commodit ou habitude et non par besoin.
La mise en uvre de PCI DSS est lopportunit de revoir cette utilisation et de
remplacer le PAN par un masquage (relation client en gnral) ou bien par un hash
unique (rconciliation financire ou Back Office par exemple) et par l mme de rduire
les risques.
VI.2 - Notion de segmentation rseau approprie

Le primtre PCI DSS inclut donc tous les systmes connects au mme segment rseau que
lenvironnement des donnes porteur. Ceci peut ventuellement inclure des systmes
annexes qui ne traiteraient aucunement de donnes cartes mais qui seraient simplement
sur le mme LAN.
On comprend quavec cette dfinition, si une entreprise dispose dun rseau interne plat
(i.e. non cloisonn), alors la totalit de son systme dinformation pourrait se retrouver inclus
dans le primtre PCI DSS. Ceci nest absolument pas le but recherch par le standard.
Rappelons que lobjectif de ce standard est de scuriser les donnes cartes contenues
dans le systme dinformation et non lintgralit de celui-ci.
Alors pourquoi imposer toutes les exigences du standard ces systmes annexes alors
quils ne traitent pas de donnes cartes et ne risquent donc pas de se les faire voler ? En
ralit, lobjectif est de limiter les risques de rebond depuis ces systmes annexes vers les
systmes manipulant les donnes cartes.
En effet, dans de nombreux cas rels de compromissions de donnes par des pirates, ceux-ci
sont passs dans un premier temps par des serveurs annexes moins scuriss pour rebondir
ensuite vers les serveurs manipulant les donnes cartes.
Ceci est par exemple le cas des codes malveillants cibls (vers) ayant pour but de chercher
linformation (coordonnes bancaires) et de la transfrer vers des personnes malintentionnes.
Nanmoins, la mise en conformit de ces systmes annexes nest pas toujours souhaite (pour
des raisons de cot, contraintes mtier) et le standard offre la possibilit de les exclure du
primtre PCI DSS en mettant en place une segmentation rseau approprie entre ces
systmes et les systmes contenants les donnes de porteur de carte. Cette segmentation doit
permettre disoler les serveurs PCI DSS sensibles de ces autres systmes annexes. Les risques
de rebond prcdemment mentionns sont alors rduits.
Sous rserve de la mise en place dune segmentation rseau approprie, lexprience

montre que le primtre PCI DSS ne devrait reprsenter plus de 5 10% du systme
dinformation de lentreprise.
21/46
CLUSIF 2009
Nanmoins, ce cloisonnement peut reprsenter lui seul des chantiers trs consquents. Les
firewalls ont un cot initial et rcurrent (maintien jour des quipements et gestion des rgles
de filtrage) non ngligeable. Certaines structures avec de nombreux points de vente peuvent
tre confrontes de trs gros chantiers. Il est alors parfois tentant dutiliser des systmes
existants en leur rajoutant quelques rgles de filtrage pour apporter un premier niveau de
cloisonnement. Jusquo peut-on aller dans les compromis technologiques tout en restant dans
les limites dune segmentation rseau approprie demande par le standard sans pour
autant se laisser aller des solutions rustines difficilement maintenables dans le temps ?
Le standard ne prcise pas techniquement cette notion de segmentation rseau approprie
et laisse une part importante lapprciation de lauditeur sur lefficacit des technologies
pouvant tre employes pour atteindre ce but.
Parmi les technologies envisageables, on retrouve les firewalls dits stateful , les proxy
applicatifs, les routeurs avec ACL, les VLAN, les VRF pour les rseaux MPLS, voire des
tunnels IPSEC/SSL pour chiffrer les donnes sur un segment du rseau qui naurait pas besoin
daccder aux donnes en clair Toutes ces technologies nont pas les mmes objectifs, ni le
mme niveau de scurit et lvaluation de leur efficacit pour raliser une segmentation
rseau approprie est trs spcifique au contexte du marchand. Le standard conseille de se
rapprocher dun auditeur certifi QSA pour faire valider que la mthodologie de mise en
uvre des solutions permet de rpondre aux exigences du standard.
VI.3 - Fournisseurs de services et reports de responsabilits

Le marchand peut sous-traiter certaines tches une entreprise externe telles que :
Oprations lies la montique : le stockage, le traitement ou la transmission des donnes

des titulaires de cartes. Ceci inclut les fournisseurs, partenaires, fournisseurs de services
montiques, passerelles de paiement, services postaux en charge de version papier des
donnes cartes, entreprise stockant les sauvegardes sur bande ;
Oprations pouvant impacter la scurit de lenvironnement des donnes de porteur de

carte : ceci inclut les fournisseurs de services manags en charge de lexploitation et
surveillance des firewalls, IDS, rseaux, systmes, applicatifs, bases de donnes
Globalement, ceci inclut tous les tiers qui accdent lenvironnement des donnes de
porteurs de cartes.
Si ces fournisseurs de service ne respectaient pas les rgles de scurit demandes par le
standard, ils pourraient constituer un maillon faible dans la scurit des donnes des porteurs
de carte. Ces entreprises sont donc incluses dans le primtre PCI DSS sous la notion de
Fournisseurs de Services . Elles ont lobligation de se mettre en conformit avec le
standard dans le cadre de leurs interventions sur le marchand en question. Cette obligation
doit apparatre formellement dans le contrat de services avec le marchand.
Il existe deux options de validation de la conformit des prestataires de services tiers :
ils peuvent procder leur propre valuation PCI DSS et en apporter la preuve leurs
clients pour dmontrer leur conformit ;
sils ne procdent pas leur propre valuation PCI DSS, ils devront faire examiner leurs
services pendant les valuations PCI DSS de chacun de leurs clients.
En outre, les commerants et les prestataires de services doivent grer et contrler la

conformit au standard PCI DSS de tous les prestataires tiers qui ont accs aux donnes des
titulaires de cartes auxquels ils sont associs.
22/46
CLUSIF 2009
En raison de ce caractre transitif ( les fournisseurs de mes fournisseurs sont mes

fournisseurs ) et de la dfinition large du fournisseur de services ( toute entreprise qui
pourrait accder aux donnes cartes du marchand ), leur nombre peut devenir rapidement
trs important. Lidentification de ces fournisseurs et le suivi de leur mise en conformit sont
un chantier part entire. Cette notion de fournisseur de services peut rapidement devenir un
point majeur dans la mise en conformit de lentreprise, surtout si ceux-ci ne sont pas trs
enclins se mettre en conformit.
VI.4 - Drogation pour certifications de primtres spcifiques

Contrairement la norme ISO 27001 qui permet de dfinir un primtre du SMSI1 comme un
sous-ensemble d'une entreprise, la notion de primtre dans PCI DSS est dfinie par des
rgles qui ne permettent pas de faire moins que le primtre entrant dans le scope, ou a
minima son environnement PCI ventuellement cloisonn.
Au sens strict du standard, il nest donc pas possible pour une entreprise de faire certifier un
certain produit ou service seul en marge du reste de lentreprise. Une entreprise ne peut pas
non plus commencer par certifier telle ou telle partie de son SI puis aborder la certification
du reste ultrieurement.
Nanmoins, si on considre ces approches pragmatiques comme transitoires vers la
certification totale, il apparat quelles ont un sens puisquelles contribuent diminuer les
risques de fraude. Il y a donc un mcanisme prvu pour pouvoir aborder cette approche : il
sagit des ngociations avec les banques acqureur.
En effet, lacceptation de ces certifications partielles relve de la notion de mise en
application du standard ( enforcement en anglais). Ce sont les banques et les rseaux
internationaux qui sont responsables de cette partie du programme PCI DSS. Ce sont donc ces
entits qui peuvent dcider daccepter une mise en conformit partielle de faon temporaire.
Ce caractre transitoire est trs important : il est fortement conseill dadjoindre un planning
de mise en conformit totale de lentreprise ces demandes de drogation.
VI.5 - Autres aspects concernant la rduction du primtre

La mise en place d'un chiffrement impose de mettre en place une organisation pour grer les
cls de chiffrement. Pour cela, on peut par exemple s'appuyer sur une Infrastructure de
Gestion de Cls Publiques (PKI en anglais).
La gestion des droits applicatifs permet de mettre en uvre le cloisonnement oprationnel des
rles. Elle doit tre prcise et si possible spare des droits daccs au rseau hors du
primtre de PCI DSS.
En cas dutilisation de comptes gnriques, des mesures compensatoires doivent tre mises en
uvre pour matriser les risques lis labsence de traabilit de ces comptes (par exemple :
connatre un moment donn les oprateurs pouvant utiliser des comptes gnriques).
Lapplication de PCI DSS est compatible avec les environnements virtualiss qui doivent
faire lobjet dune dmarche adapte auprs du QSA. Des mesures de scurit doivent tre
mises en uvre sur les interconnexions entre environnements virtualiss, les systmes htes
Systme de management de la scurit de linformation
23/46
CLUSIF 2009
(hyperviseurs) et les systmes de contrle (consoles). En particulier lenvironnement hte et

les consoles de contrles sont incluses dans le primtre.
VI.6 - Responsabilit vis--vis des prestataires

Dans le cadre dune externalisation des problmatiques de systmes dinformation, un grand
nombre de socits (en particulier les marchands) se tourne aujourdhui vers des prestataires
offrant des services allant de lhbergement linstallation, en passant par le support de
premier niveau, le dveloppement et le maintien en condition oprationnelle.
Les engagements entre le prestataire et son client sont en gnral couverts par des clauses de
confidentialit, sans pour le moment, et si ncessaire, intgrer systmatiquement des clauses
ou des rfrences PCI DSS, ce qui va lencontre du standard. En effet, le standard
mentionne dans sa condition 12.8.2 que laccord de prestation doit intgrer la reconnaissance
de responsabilits sur les donnes traites.
On voit, dans des pays anglo-saxons, des offres Data Center PCI Compliant qui
permettraient de rassurer les ventuels clients concernant les mesures prises par le Data
Center pour hberger et traiter des donnes carte, tant sur les aspects organisationnels que sur
les aspects techniques.
Cette rfrence de conformit permet aux prestataires de dmontrer leurs clients la gestion
approprie des informations cartes sensibles au sein de lenvironnement externalis.
Cependant la conformit dun prestataire de services ne ddouane pas le marchand de sa
responsabilit sur le sujet, il doit notamment rfrencer, sur le processus de gestion des cartes,
la liste des prestataires, leurs champs dactivit, etc. tout cela tant vrifi dans le cadre de
laudit annuel ralis par le QSA au travers des conditions 12.8.x.
A ce jour, un prestataire (hbergeur par exemple) peut faire raliser en son nom propre une
valuation de conformit quil peut prsenter ses clients comme preuve de sa gestion
approprie du processus de traitement cartes et qui sert de base lauditeur QSA ou en cas
de non validation ou conformit PCI DSS, le prestataire doit rpondre chaque demande de
ses clients concernant ses processus de traitements des donnes carte dans le cadre des
valuations des marchands.
En bout de chane, lapprciation du niveau de scurit dun environnement carte externalis
ou non, en reviendra toujours au QSA qui a la charge et la responsabilit dans son valuation.
Le marchand qui externalise ce type de services porte toujours la responsabilit de la mise en
conformit de la tierce partie un QSA notant des faiblesses ou des contre-mesures non
appropries lors de son valuation le reporte au client qui doit de son propre chef intervenir
auprs de son prestataire pour que celui-ci se mette en conformit sous peine de non
validation PCI DSS.
Pour mmoire, les contrles sappliquant un marchand ayant externalis des oprations
incluant des processus cartes, sont prsents au chapitre 12.8 de la norme PCI DSS v1.2.
24/46
CLUSIF 2009
VII - Stratgie de conservation des donnes carte

La conservation des donnes carte est au cur de PCI DSS, ainsi un pr-requis spcifique
traite de ce sujet, il sagit du chapitre 3 du standard.
VII.1 - Quelles donnes conserver ?

Les donnes autorises en termes de stockage ainsi que les donnes dont le stockage est
prohib ont dj t mentionnes dans le chapitre Notions de donnes porteur . Plusieurs
points du chapitre 3 de PCI DSS concernent la vrification de ce principe au niveau
documentaire mais aussi de son application sur le systme dinformation.
VII.2 - Motivation et dure de stockage de ces donnes

Sil est possible de conserver certaines donnes carte comme le PAN ou la date dexpiration
de la carte, il est ncessaire de rduire cette conservation ce qui est strictement
ncessaire et de justifier la dure de celle-ci.
Ainsi le pr-requis 3.1 du standard PCI DSS demande que la politique de conservation des
donnes sensibles traite des points suivants :
Motivation du stockage et de sa dure en prcisant le type de contrainte associe quelle

soit lgale, rglementaire ou lie lactivit de lentreprise (contrainte business forte) ;
Prcision sur la ncessit de supprimer la donne une fois que celle-ci nest plus
ncessaire aux besoins cits ;
Vrification que la politique de stockage adresse lensemble des stockages raliss par
lentreprise ;
Vrification que la politique prvoit un processus automatis de suppression des donnes

une fois que celles-ci ne sont plus ncessaires et que celui-ci est appliqu au moins
trimestriellement.
VII.3 - Conditions de stockage et dutilisation de ces donnes

Les donnes doivent tre accdes conformment au strict besoin den connatre des
utilisateurs du systme dinformation et tre protges de manire efficace.
Les donnes carte doivent tre protges ds lors quelles sont stockes, ainsi la mesure de
scurit 3.4 prcise les mesures de protection acceptables pour ces donnes :
Hachage unilatral sappuyant sur une mthode cryptographique robuste (one way strong
hash including salt) ;
Troncature : il sagit ici de ne stocker que les donnes en respectant la mme rgle que
pour le masquage ;
Index tokens et Index pads (les pads doivent tre stocks de manire scurise) ;
Chiffrement robuste associ des processus et des procdures de gestion de cls.
25/46
CLUSIF 2009
Il faut donc privilgier le masquage, la troncature, et le hachage dj voqus dans le chapitre

traitant de la rduction du primtre car le stockage permettant une rcupration de la donne
utilisable pour un paiement soulve un niveau de risque plus important et impose des
contraintes strictes en particulier en termes de procdures de gestion de cls et de secrets.
26/46
CLUSIF 2009
VIII - Les mesures compensatoires
VIII.1 - Quest ce quune mesure compensatoire ?

Conscient du caractre trs prescriptif du standard PCI DSS, le PCI SSC a prvu un
mcanisme permettant aux entits concernes de rpondre aux objectifs de scurit recherchs
avec la mme rigueur, en utilisant une autre approche que lapproche initiale.
Les mesures compensatoires peuvent tre utilises lorsquun pr-requis est inapplicable pour
une raison technique forte ou remet en cause le modle conomique de lentreprise.
Il est en effet possible dutiliser une mesure compensatoire pour toutes les exigences du
standard, except la clause 3.2 : Ne stocker aucune donne dauthentification sensible aprs
autorisation (mme chiffre) .
Le principe est de proposer, pour certaines exigences juges inapplicables dans un contexte
particulier, des mesures de scurit diffrentes et qui iraient globalement plus loin que les
mesures initiales.
La validit dune mesure compensatoire dans un contexte donn est encadre par 4 conditions
(voir ci-dessous) et est laisse lapprciation de lauditeur QSA qui value la capacit de la
mesure compensatoire couvrir les risques.
Cette notion de mesure compensatoire renforce donc la notion danalyse de risques dans la
mise en uvre et lvaluation de la conformit PCI DSS.
Une fois par an, toutes les mesures compensatoires doivent tre documentes, examines et
valides par lauditeur, puis incluses dans le Rapport sur la Conformit. Les rsultats de
lvaluation annuelle de ces mesures compensatoires doivent tre documents dans le Rapport
de Conformit, dans la section de lexigence PCI DSS correspondante. Ils font partie des
informations pouvant tre passes en revue dans le cadre des contrles Qualit effectus par le
PCI SSC.
VIII.2 - Conditions de lgitimit dune mesure compensatoire

Premirement, des mesures compensatoires peuvent tre envisages lorsqu'une entit ne peut
pas se conformer aux exigences PCI DSS telles quelles sont stipules, soit :
1.
en raison de contraintes commerciales documentes (cot excessif de la mise

en uvre face au risque couvrir)
2.
de contraintes techniques lgitimes et documentes.
ou
Lune de ces raisons devra donc tre dmontre lors de laudit et rvalue annuellement. En
effet, le contexte peut changer et une contrainte lgitime une anne, peut disparatre lanne
suivante. Lexigence initiale du standard PCI DSS devra alors tre applique.
27/46
CLUSIF 2009
VIII.3 - Conditions de validit dune mesure compensatoire

Ensuite, les mesures compensatoires doivent satisfaire aux 4 critres suivants :
1.
Respecter lintention et la rigueur de la clause initiale du standard PCI DSS ;
2.
Fournir une protection similaire celle de la clause initiale du standard PCI

DSS, de sorte que le contrle compensatoire compense suffisamment le risque
prvenu par la clause initiale. On retrouve ici la notion danalyse du risque
initial ;
3.
Aller au-del des autres clauses PCI DSS. Les mesures compensatoires ne
consistent pas simplement en la conformit avec dautres clauses PCI DSS, il
faut aller au-del ;
4.
tre proportionnelles aux risques supplmentaires qu'implique le non-respect

de la clause PCI DSS. On retrouve ici le besoin de savoir calculer le risque
rsiduel.
VIII.4 - Illustration dune mesure compensatoire

Il est trs important de comprendre que lexemple ci-dessous est une illustration en dehors de
tout contexte.
Une apprciation des risques est spcifique une entreprise, un contexte, un moment, et
ce titre, nest pas transposable automatiquement dune entit une autre. De mme, une
mesure compensatoire nest pas valable pour toute entit indpendamment de son contexte, ni
transposable aveuglment. Il ne semble pas pertinent ce titre de construire un rfrentiel
des mesures compensatoires avec des formules clefs en mains valables partout. Cest
galement pourquoi une mesure compensatoire peut tre valable pour un concurrent et pas
pour votre entit.
Cest pour cela que le PCI SSC nendosse aucune mesure compensatoire gnrique, et laisse
systmatiquement lauditeur QSA les valuer dans le contexte de leur client.
Voici donc un exemple de mesure compensatoire qui pourrait tre valide dans un certain
contexte : (extrait de PCI DSS 1.2)
Exigence impacte : 8.1 - Tous les utilisateurs sont-ils identifis avec un nom d'utilisateur
unique qui les autorise accder aux composants du systme ou aux donnes de titulaires de
cartes ?
1.
Contraintes La socit XYZ utilise des serveurs Unix autonomes sans LDAP.
Par consquent, chacun requiert un nom dutilisateur root . La socit XYZ
ne peut pas grer le nom dutilisateur root ni consigner toutes les activits
de chaque utilisateur root ;
2.
Objectif - Lexigence de noms dutilisateur uniques vise un double objectif.

Premirement, le partage des informations d'identification n'est pas acceptable
du point de vue de la scurit. Deuximement, le partage des noms d'utilisateur
rend impossible l'identification de la personne responsable d'une action
particulire ;
28/46
CLUSIF 2009
3.
Risque identifi - Labsence didentifiant utilisateur unique et le fait de ne pas

pouvoir tracer les informations d'identification introduisent des risques
supplmentaires dans le systme de contrle daccs ;
4.
Dfinition des mesures compensatoires - Une socit XYZ va demander tous

les utilisateurs de se connecter aux serveurs partir de leur environnement
laide de la commande SU. Cette commande autorise les utilisateurs accder
au compte root et excuter des actions sous ce compte, tout en permettant
de consigner leurs activits dans le rpertoire du journal SU. Il est ainsi
possible de suivre les actions de chaque utilisateur utilisant le compte root
par ce biais ;
5.
Validation des mesures compensatoires - La socit XYZ dmontre

l'valuateur lexcution de la commande SU et lui montre que celle-ci permet
didentifier les utilisateurs connects qui excutent des actions sous le compte
root ;
6.
Gestion - La socit XYZ dcrit les processus et les procdures mis en place
pour viter la modification, laltration ou la suppression des configurations
SU de sorte que des utilisateurs individuels puissent excuter des commandes
root sans que leurs activits soient consignes ou suivies .
29/46
CLUSIF 2009
IX - PCI DSS, vrits et contre vrits
IX.1 - Matriel ou logiciel certifi PCI DSS

Si des logiciels ou des quipements sont vendus comme conformes PCI DSS, cela nimplique
pas une conformit automatique pour celui qui utilise ces lments.
En effet, si le matriel ou le logiciel ne doit pas intrinsquement empcher la conformit, cest
lutilisation de celui-ci qui est soumise aux mesures de scurit, il est donc impropre de dire
quun logiciel ou matriel est PCI DSS.
A noter que dans certains cas trs prcis le matriel est soumis PCI-PED, et le logiciel PADSS.
IX.2 - Dbat EMV contre PCI DSS

EMV a t mis en place pour rduire la fraude au niveau des points de paiement vis--vis des
cartes contrefaites (Fraudes technologiques, celles-ci concernent des volumes plutt faibles).
PCI DSS a t mis en place dans la mme optique pour la partie piste, mais adresse surtout la
fraude lie au traitement (pendant et surtout aprs transaction). PCI DSS adresse des fraudes
massives.
Les risques identifis par chaque standard tant diffrents, les mesures demandes le sont
galement, mme si un certain niveau de recouvrement peut-tre identifi (protection des
donnes lors de la transaction carte prsente).
Un systme de paiement EMV nest pas exempt de la protection des donnes carte hors du
point de paiement.
Concernant la comptabilisation des transactions, le principe de dduire le nombre de
transactions EMV du nombre total de transactions pour valuer le niveau de marchand peuttre pertinent dans le cas ou ces donnes ne sont pas stockes. Aucun organisme carte na ce
jour statu clairement concernant ce point.
Si ce dbat peut se comprendre concernant les motivations des investissements lis la
scurit ces dernires annes, il nest techniquement pas fond.
IX.3 - Fraude dclare

Les informations obtenues sur les fraudes de type vol de donnes cartes sont biaises du fait
que certains pays ont lobligation lgale de dclarer ce type de fraude, ce qui nest pas le cas
en France.
Des fraudes avres de type vol de donnes carte existent en France et en Europe, cependant
ces informations ne sont pas divulgues et aucune statistique officielle nest disponible jour.
30/46
CLUSIF 2009
X - Liens avec les autres normes, standards, rfrentiels et

rglementations
X.1 - ISO 27001

PCI DSS la diffrence de lISO 27001 peut tre considr comme le rsultat d'une analyse
de risques effectue par les organismes cartes. L'ISO est assez souple quant au primtre, aux
mesures de scurit, la conformit et la mise en place. En effet, il a t construit de faon
pouvoir s'adapter des entreprises d'activits trs diffrentes et des risques varis. Son but
premier est dadresser lorganisation de la scurit. PCI DSS concerne quant lui le niveau de
scurit li la carte bancaire.
Les exigences et pr-requis PCI DSS sont obligatoires, alors qu'avec ISO 27001 les mesures
de scurit sont suggres - laissant ainsi chaque organisation - la possibilit de dcider des
mesures de scurit mettre en place en fonction de sa sensibilit aux risques. Compares aux
mesures de scurit de l'ISO 27001, celles de PCI DSS sont plus spcifiques. En thorie cette
granularit permet un audit plus simple sur PCI DSS que pour ISO 27001.
Quand on se pose la question d'une certification ISO 27001, le planning peut permettre
dobtenir une conformit ISO et PCI avec un seul effort de mise en place. En effet, il existe un
certain nombre de complmentarits entre ces deux approches pour autant que le primtre du
SMSI englobe au moins celui de PCI DSS et que les mesures de scurit slectionnes lors de
llaboration de la Dclaration dApplicabilit (DdA) contiennent celles de PCI DSS. Ainsi
une dmarche commune permettra un grand nombre de synergies et donc des conomies
importantes condition de bien comprendre et de matriser les diffrences entre les deux
approches.
Diffrences entre ISO 27001 et PCI DSS
Diffrences
PCI DSS
ISO 27001
Slection des mesures de

scurit
Impose
Principalement base sur

l'apprciation des risques
Niveau de granularit
Important
Libre
Niveau de flexibilit
Faible
Important
Primtre
Dfini par le standard
Dfini par laudit
Exigibilit
Contrainte externe
Dmarche spontane
Objectif principal
Niveau de scurit de la carte bancaire
Organisation de la scurit
Aide au management du SI Faible contribution
Contribution majeure
X.2 - Cobit, ITIL et ISO 27002

Cobit nest en effet pas comparer PCI DSS, mais peut en revanche tre utilis pour mettre
en uvre un modle de maturit et mesurer ltat de sa conformit aux exigences PCI DSS.
Outre la capacit de mesurer sa conformit, les processus Cobit identifis peuvent tre
31/46
CLUSIF 2009
intgrs dans une dmarche daudit interne dans le cadre du maintien de sa conformit aux
exigences par exemple, et ou mutualiss une dmarche existante pour rpondre aux
exigences de contrles internes.
Le tableau de lannexe 2 permet didentifier quels contrles ou mesures de scurit Cobit,
ITIL et ISO 27002 couvrent les exigences PCI DSS afin de rationnaliser ces dernires (et de
ne pas crer de nouveaux contrles et donc de rationnaliser les cots de mise en conformit
par exemple). Enfin une dmarche Cobit permet dadopter la dmarche processus absente de
PCI DSS, et de bnficier de lorganisation et du pilotage de la scurit que peut apporter
Cobit dans une dmarche globale.
X.3 - CNIL et autres lois

Le vol de donnes informatiques est encadr sur le plan lgal par la loi Loi n 88-19 du 5
Janvier 1988 - dite loi Godfrain - qui a modifi le code pnal dans le titre II du livre III en
insrant un chapitre III, articles 462-2 462-9 sur les infractions en matire informatique.
Au titre de ces articles, laccs et le maintien dans un systme dinformation dune entit non
autorise est rprhensible en particulier sagissant de la modification ou de la suppression.
Le vol en lui mme, savoir une copie naltrant pas les donnes, nest abord quau sens de
larticle 162-6 en voquant [] lusage de documents informatiss [] de nature causer un
prjudice autrui.
La loi n 78-17 du 6 Janvier 1978, modifie par la loi n 88-227 du 11 mars 1988, article 13
relative la transparence financire de la vie politique (J.O. du 12 mars 1988), concerne la
protection des donnes personnelles. Cette loi est la plus proche des intentions du programme
PCI DSS sachant que les donnes sensibles cartes bancaires sont bien considres par la
CNIL comme des donnes indirectement nominatives.
Quiconque ayant vol des donnes carte tombe donc sous le coup de ces deux lois.
Notons quen aucun cas les exigences de PCI DSS, rgles purement de droit priv, ne peuvent
se substituer la loi en vigueur sur le sol franais. A ce titre le dpositaire des donnes
sensibles doit se conformer aux exigences dictes par la CNIL afin de protger, selon les
critres clairement tablis, les donnes sensibles des porteurs de cartes.
X.4 - Rfrentiels techniques

De nombreux organismes fournissent des rfrentiels de scurit et en particulier des
procdures de scurisation techniques des systmes d'exploitation, des serveurs d'application
et des applications et rseaux.
Ce chapitre prsente quelques uns de ces organismes qui proposent des documents de
scurisation utiles pour votre dmarche PCI DSS.
L'OWASP (Open Web Application Security Project) est une organisation but non
lucratif dont l'objectif est la promotion de mthodes et d'outils de conception et de
dveloppement scuriss dont des outils daudit et de formation. Elle maintient en
particulier un top 10 des principales erreurs de dveloppement rencontres avec les
mesures de scurit associes.
https://www.owasp.org/images/a/a4/OWASP_Top_10_2007_-_French.doc
32/46
CLUSIF 2009
http://www.owasp.org/
Le SANS (SysAdmin, Audit, Network, Security) Institute : organisme qui fournit des
ressources et des formations de scurit informatique
www.sans.org.
le NIST (Network Information Security & Technology News) : site de nouvelles sur les
technologies et la scurit des SI
http://www.nist.org/
le CIS (Center for Internet Security) : entreprise but non lucratif de promotion de la
scurit sur Internet
http://www.cisecurity.org/
Les principaux constructeurs et diteurs (ex : Cisco, IBM, Microsoft, Oracle, SAP, Sun)
fournissent galement des documentations pour leurs solutions, parfois ils ont mme t
jusqu faire valuer celles-ci. A noter, comme cela a dj t voqu que cest
limplmentation de la solution qui est conforme et non une brique logicielle ou
matrielle en elle-mme.
33/46
CLUSIF 2009
XI - Avantages, difficults et limites dune dmarche PCI DSS

PCI DSS est un standard de conformit, son application par les socits est le fruit d'une
relation le plus souvent contractuelle entre les diffrents acteurs. Conformit n'est pas
forcment synonyme de scurit; comme les autres standards, normes ou rfrentiels, il doit
tre mani avec doigt; dfaut il risque d'tre dtourn de son but initial et pourrait mme
savrer contre productif.
XI.1 - Avantages
Plusieurs avantages lis une telle dmarche peuvent tre identifis, on peut citer par
exemple :
Le caractre obligatoire et la rigidit des mesures peut permettre de dbloquer des projets
de scurit dj identifis par les oprationnels et RSSI mais jusque l repousss pour des
raisons d'conomies plus lies au contexte conomique qu' la gestion des risques.
Comme cela a t identifi dans le chapitre traitant des normes, standards, rfrentiels et
rglementation, PCI DSS peut sinscrire dans une dmarche globale et cohrente de
scurisation des systmes dinformation.
Dans le cadre de systmes dinformation jeunes ou btir, PCI DSS prsente un
rfrentiel de scurit montique.
XI.2 - Difficults
Les difficults lies l'implmentation de PCI DSS sont de plusieurs ordres parmi lesquels :
Le dlai exig par les organismes ne permet pas forcment d'inscrire les contraintes lies
PCI DSS dans le cycle de vie initial des projets de l'entreprise. Il faut alors s'engager
dans une ngociation qui peut s'avrer plus ou moins complexe avec celui qui exige cette
conformit ;
PCI DSS ncessite parfois une adaptation non ngligeable du systme dinformation et
des mtiers, comme cela a dj voqu dans le chapitre traitant de la rduction du
primtre ;
Les mesures compensatoires ncessitent une anticipation en amont de laudit, car les
conditions de validit sont strictes et values par le QSA, dans le cadre de laudit, qui
engage sa responsabilit.
XI.3 - Limites
Comme toute dmarche de standardisation, PCI DSS a ses limites :
PCI DSS est un standard unique qui sapplique lensemble des entreprises qui traitent
des donnes carte indpendamment de leur secteur dactivit ;
Lagrment nest pas une garantie absolue contre lensemble des menaces de vol,
compromission ou fraude.
34/46
CLUSIF 2009
XII - Conclusion du document

Ce document de prsentation du standard PCI-DSS vise apporter la comprhension
ncessaire pour aborder un tel projet dans son entreprise.
Les sujets orients mise en uvre pratique ont t volontairement carts, tel que lapproche
par priorit ou des aspects techniques qui pourront tre dvelopp ultrieurement.
Le groupe de travail
doc-pcidss@clusif.asso.fr.
accueillera
toute
35/46
remarque
ou
suggestion
ladresse :
CLUSIF 2009
XIII - Annexe 1 : Glossaire
XIII.1 - Termes PCI DSS
ASV (Approved Scanning Vendor) : prestataire autoris par le PCI SSC pour la
ralisation de recherches automatises de vulnrabilits sur des machines connectes un
rseau public ;
PCI (Payment Card Industry) : acteurs qui interviennent dans l'industrie de paiement par
carte (banques, prestataires de paiement, metteurs de carte, commerants) ;
PCI SSC (PCI Security Standards Council) : organisme responsable du maintien des
standards PCI DSS, de leur promotion et de leur encadrement ;
PCI DSS (PCI Data Security Standard) : standard de scurit qui s'applique aux systmes
d'informations qui manipulent des donnes sensibles au sens PCI (essentiellement les
donnes des porteurs de carte comme le numro de carte) ;
PCI PA-DSS (ou appel PA-DSS) (PCI Payment Application Data Security Standard) :
variante du standard PCI DSS qui s'applique aux applications de paiement ;
PCI PED (PCI Pin Entry Device Data Security Standard) : variante du standard PCI DSS
qui s'applique aux priphriques de saisie du code PIN qui protge les cartes de
paiement ;
PSP (Payment Service Provider) : prestataire qui joue le rle d'intermdiaire entre les
commerants, les banques et les metteurs de cartes pour raliser (traiter et/ou stocker
et/ou transmettre et/ou en support) des oprations de paiement par carte ;
QSA (Qualified Security Assessor) : prestataire habilit par le PCI SSC pour raliser des
audits PCI DSS ;
RoC (Report on Compliance) : rapport dcrivant le niveau de conformit d'une entit vis-vis de PCI DSS ;
RoV (Report on Validation) : rapport dcrivant le niveau de conformit d'une application

de paiement vis--vis de PCI-PA-DSS ;
SAQ (Self Auditing Questionnaire) : questionnaire d'auto valuation de la conformit

PCI DSS. Il permet toute entit d'auto valuer le niveau de conformit de son systme
d'information PCI DSS. Il est destin aux entits qui n'ont pas l'obligation d'tre
values par un auditeur QSA.
Source : https://www.pcisecuritystandards.org/security_standards/docs/glossary_fr.pdf
36/46
CLUSIF 2009
XIII.2 - Termes lis dautres normes, standards ou rfrentiels
DdA (Dclaration dApplicabilit) : Terme utilis dans la norme ISO 27001, qui dsigne
le document listant et justifiant les mesures de scurit applicables et non applicables au
SMSI dun organisme. La DdA est souvent appele SoA (Statement of Applicability) qui
vient de la version anglaise de la norme ISO 27001 ;
EMV (Europay MasterCard Visa) : Standard international de scurit des cartes de

paiement puce. EMV est rgi par lEMVCo, organisme administr par American
Express, JCB, MasterCard et Visa.
XIII.3 - Termes de montique
Accepteur : Entit ayant pass un accord avec un acqureur pour accepter les cartes
bancaires et qui prsente lacqureur les donnes des transactions faites avec ces cartes.
En paiement de proximit laccepteur est le commerant avec son TPE, en relation
VAD/MOTO cest le commerant via linterface Web ou le PSP qui agit pour le compte
du commerant. En retrait cest le DAB/GAB de la banque ;
Acqureur : Organisme financier ou assimil ayant pass un accord avec un accepteur en

vue de l'acquisition des donnes des transactions faites par carte, qui introduit ces
donnes dans les systmes d'changes des metteurs. Cest la banque domiciliataire du
commerant. Un organisme financier peut tre la fois acqureur et metteur ;
CHD (CardHolder Data) : Ce sont les donnes du porteur de carte. Elles comprennent en
particulier le PAN, la date de fin de validit de la carte et le CVx2 ;
CNP (Card Non Present) : Situation dans laquelle linitialisation de la transaction de

paiement est ralise sans que la carte soit physiquement prsente au point dacceptation.
Cette situation correspond au paiement sur internet ou en VAD/MOTO ;
Commerant : Cest lentit qui dlivre un bien ou un service en change dun paiement,
dans notre cas par carte bancaire. Il a sign un contrat commerant avec son acqureur
qui dcrit les rgles et responsabilits mutuelle pour lacceptation dun paiement par carte
bancaire ;
CVx : (CVC, CVC) Cet acronyme dsigne les codes CVV (Card Verification Value pour
Visa) ou CVC (Card Verification Code pour MasterCard) inscrit dans les donnes
discrtionnaires de la piste ISO 2 pour sceller celle-ci ;
CVx2 : (CVC2, CVV2) cryptogramme visuel Le CVx2 est un numro spcifique

chaque carte, correspondant aux 3 derniers chiffres du numro inscrit au verso sur le
panneau de signature. Le CVx2 est utilis en paiement sur internet ;
DAB/GAB : Distributeur de billets, guichet automatique de banque ;
Donnes discrtionnaires : Champ des pistes ISO 1 et 2 contenant des donnes relatives
aux contrles de scurit ;
Emetteur : Organisme financier ou assimil qui met une carte au profit d'un porteur.
Cest la banque du porteur. Un organisme financier peut tre la fois metteur et
acqureur ;
37/46
CLUSIF 2009
Montique : (Source : Wikipdia) La montique dsigne l'ensemble des traitements

lectroniques, informatiques et tlmatiques ncessaires la gestion de cartes bancaires
ainsi que des transactions associes ;
PAN : Personal Account Number Cest ce quon appelle le numro de carte bancaire
compos gnralement de 16 chiffres. Il est emboss sur la face avant de la carte, il fait
partie des donnes figurant sur la piste ISO2 au dos de la carte et galement dans les
donnes de la puce ;
Pistes (ISO 1, ISO 2) (F) : Pistes magntiques au dos de la carte (partie fonce)
comportant des informations sur la carte et sur le porteur. Elles sont utilises pour
l'international et les retraits :
ISO 1: utilise l'tranger ;
ISO 2: lments fixes d'identification du numro du porteur, date de validit et valeurs

de rfrence ;
TPE: Terminal de paiement lectronique De nombreuses variantes existent selon les

types de commerants, terminaux grapps, terminaux points de vente ;
VAD/MOTO: Vente distance Mail Order Telephone Order. Situation dans laquelle la
carte nest pas prsente lors de ltablissement de la transaction de paiement ;
POS : Point of sale, point de vente ;
TPE : terminal de paiement lectronique.
XIII.4 - Autres termes
Forensics (investigations aprs incident) : ensemble des oprations ralises la suite

d'un incident ou d'une fraude pour en dterminer la cause, l'origine, l'historique et toutes
les informations utiles ;
Compromission : vnement qui se produit lorsqu'une personne non autorise a eu accs

des informations sensibles.
38/46
CLUSIF 2009
XIV - Annexe 2 : Analyse comparative PCI DSS, ISO 27001,

COBIT
Le tableau suivant permet de voir que la majeure partie des exigences PCI DSS v1.2 est
couverte par les mesures de scurit dcrites dans les paragraphes A10 (Gestion de
lexploitation et des tlcommunications), A11 (contrle daccs) et A12 (acquisition,
dveloppement et maintenance des systmes dinformation) de lannexe 1 de lISO
27001:2005.
Annexe A de lISO 27001

PCI DSS
A
.
5
A
.
6
A
.
7
A
.
8
A
.
9
Exigence 1
A
.
10
A
.
11
A
.
12
Exigence 2
Exigence 3
Exigence 4
A
.
13
A
.
14
A
.
15
Exigence 5
Exigence 6
Exigence 7
Exigence 8
Exigence 9
Exigence 10
Exigence 11
Exigence 12
Figure 4 : Matrice des Relations PCI DSS & ISO 27001
39/46
CLUSIF 2009
Le tableau suivant prsente les correspondances entre PCI DSS v1.2, ISO/IEC 27001:2005 et
CobiT v 4.1 :
PCI DSS
ISO/IEC
27001
(Clauses 4 8)
Exigence 1
Installer et grer une

configuration de parefeu pour protger les
donnes des titulaires
de cartes.
ISO/IEC 27001 (Annexe A)
CobiT (version 4.1)
A.11.4.1 Politique relative lutilisation

des services en rseau
AI3.3
maintenance
A.10.1.2
modifications
AI6.1 Change standards and

procedures
Management
des
Infrastructure
A.10.6.1 Mesures sur les rseaux
AI7.6 Testing of changes
A.11.4.6 Mesure relative la connexion

rseau
AI7.7 Final acceptance test

DS5.10 Network security
A.11.4.5 Cloisonnement des rseaux

A.10.6.2 Scurit des services rseau
A.11.4.1 Politique relative lutilisation
des services en rseau
A.7.1.2 Proprit des actifs
A.12.4.1 Mesure relative aux logiciels
en exploitation
A.11.4.5 Cloisonnement des rseaux
A.11.7.1
Informatique
communications mobiles
et
A.11.7.2 Tltravail
A.11.6.2
sensibles
Exigence 2
Ne pas utiliser les

mots de passe systme
et autres paramtres
de scurit par dfaut
dfinis
par
le
fournisseur.
Isolement
des
systmes
A.11.2.3 Gestion du mot de passe

utilisateur
en exploitation
A.12.6.1
Mesure
relative
vulnrabilits techniques
A.11.6.2
sensibles
Isolement
des
aux
systmes
A.11.4.4 Protection des ports de

diagnostic et de configuration distance
A.11.1.1 Politique de contrle daccs
A.11.2.2 Gestion des privilges
A.11.5.4 Emploi des utilitaires systme
40/46
CLUSIF 2009
PCI DSS
ISO/IEC
27001
(Clauses 4 8)
Exigence 3
Protger les donnes

des titulaires de cartes
stockes.
CobiT (version 4.1)
A.15.1.1 Identification de la lgislation

en vigueur
PO2.3 Data
scheme
A.15.1.4 Mesure prventive lgard

du mauvais usage des moyens de
traitement de linformation
DS5.8 Cryptographic
management
A.15.2.1 Conformit avec les politiques

et les normes de scurit
classification
key
DS11.2 Storage and retention

arrangements
DS11.4 Disposal
A.15.2.2 Vrification de la conformit

technique
A.15.1.6 Rglementation relative aux
mesures cryptographiques
A.12.3.2 Gestion des cls
A.8.1.1 Rles et responsabilits
Exigence 4
Chiffrer
la
transmission
des
donnes des titulaires
de cartes sur les
rseaux
publics
ouverts.
Exigence 5
Utiliser des logiciels
antivirus et les mettre
jour rgulirement.
Exigence 6
Dvelopper et grer
des systmes et des
applications scuriss.
A.7.2.2 Marquage et manipulation de

l'information
DS5.11 Exchange of sensitive

data
A.12.3.1 Politique dutilisation des

mesures cryptographiques
A.10.4.1 Mesures contre les codes

malveillants
DS5.9 Malicious software

prevention, detection and
correction
A.12.6.1
Mesure
relative
vulnrabilits techniques
PO4.11 Segregation of duties
aux
A.12.5.2 Rexamen technique des

applications aprs modification du
systme dexploitation
en exploitation
A.12.5.5
Externalisation
dveloppement logiciel
du
A.10.1.4 Sparation des quipements de

dveloppement, d'essai et dexploitation
A.10.1.3 Sparation des tches
DS5.9 Malicious software

prevention, detection and
correction
AI2.3 Application control and
auditability
AI2.4 Application security and
availability
AI3.3
maintenance
Infrastructure
AI3.4
Feasibility
environment
test
donnes
AI6.1 Change standards and

procedures
A.12.5.1 Procdures de contrle des

modifications
AI6.2 Impact assessment,

prioritisation and authorisation
A.12.2.1 Validation des donnes en

entre
AI7.2 Test plan
A.12.4.2 Protection
systme dessai
des
AI7.4 Test environment

AI7.6 Testing of changes
AI7.7 Final acceptance test
41/46
CLUSIF 2009
PCI DSS
ISO/IEC
27001
(Clauses 4 8)
CobiT (version 4.1)
Exigence 7
A.11.1.1 Politique de contrle daccs
Restreindre
l'accs
aux
donnes
des
titulaires de cartes aux
seuls individus qui
doivent les connatre.
Exigence 8
A.11.2.1
Utilisateurs
Affecter un ID unique
chaque utilisateur
dordinateur.
A.11.2.4 Rexamen des droits daccs

utilisateurs
A.11.6.1
Restriction
linformation
daccs
Enregistrement
des
A.11.5.2
Identification
authentification de lutilisateur
et
PO7.8 Job
termination
Change
DS5.4
User
management
and
account
A.11.2.3 Gestion du mot de passe

utilisateur
A.11.4.2
lutilisateur
externes
Authentification
de
pour les connexions
A.11.5.1 Ouverture
Scurises
de
sessions
A.11.5.3 Systme de gestion des mots

de passe
A.8.3.3 Retrait des droits daccs
A.11.2.4 Rexamen des droits daccs
utilisateurs
A.11.5.6 Limitation du temps de
connexion
A.11.3.1 Utilisation du mot de passe
A.11.5.5 Dconnexion automatique des
sessions inactives
Exigence 9
Restreindre
laccs
physique aux donnes
des titulaires de cartes.
A.9.1.2 Contrles physiques des accs

A.9.1.5 Travail
scurises
dans
les
zones
A.9.1.3 Scurisation des bureaux, des

salles et des quipements
PO7.8 Job
termination
Change
DS11.3
Media
management system
and
library
DS11.4 Disposal
A.9.1.4 Protection contre les menaces

extrieures et environnementales
DS12.2 Physical
measures
security
A.10.5.1 Sauvegarde des Informations
DS12.3 Physical access

A.11.3.3 Politique du bureau propre et
de lcran vide
A.10.7.1
Gestion
amovibles
des
supports
A.10.8.1 Politiques et procdures

dchange des informations
A.10.8.2 Accords dchange
A.10.7.3 Procdures de manipulation
42/46
CLUSIF 2009
PCI DSS
ISO/IEC
27001
(Clauses 4 8)
CobiT (version 4.1)
des informations
A.10.8.3 Supports physiques en transit
A.7.1.1 Inventaire des actifs
A.10.7.3 Procdures de manipulation
des informations
A.10.7.2 Mise au rebut des supports
Exigence 10
A.10.10.1 Journaux daudit

A.10.10.2 Surveillance de lexploitation
du systme
Effectuer le suivi et
surveiller tous les
accs aux ressources
rseau et aux donnes
des titulaires de cartes.
A.10.10.4 Journal administrateur et

journal des oprations
AI2.3 Application control and

auditability
DS5.5
Security
testing,
surveillance and monitoring
A.10.10.3 Protection des informations

Journalises
A.10.10.6
Horloges
Synchronisation
des
A.15.1.3 Protection des enregistrements

de lorganisme
Exigence 11
A.15.2.2 Vrification de la conformit

technique
DS5.5
Security
testing,
surveillance and monitoring
A.10.4.1 Mesures contre les codes

malveillants
Tester rgulirement
les processus et les
systmes de scurit.
A.10.6.1 Mesures sur les rseaux

A.10.6.2 Scurit des services rseau
A.10.9.3 Informations disposition du
public
Exigence 12
Grer une politique

qui assure la scurit
des informations des
employs et des soustraitants.
4.2.1 d) identifier les

risques : 1) 3)
4.2.1 e) analyser et
valuer les risques :
1) 4)
4.2.1
c)
dfinir
l'approche
d'apprciation
du
risque
de
l'organisme : 1) 2)
4.2.3 d) rexaminer
les apprciations du
risque intervalles
planifis
et
rexaminer le niveau
de risque rsiduel et
le niveau de risque
A.5.1.1 Document de politique de

scurit de linformation
PO4.8 Responsibility for risk,

security and compliance
A.5.1.2 Rexamen de la politique de

scurit de linformation
PO6.3 IT policies management
A.10.1.1 Procdures
documentes
dexploitation
PO7.3 Staffing of roles
A.15.1.5 Mesure prventive lgard

du mauvais usage des moyens de
traitement de linformation
A.7.1.3 Utilisation correcte des actifs
A.11.5.2
Identification
authentification de lutilisateur
A.11.4.2
lutilisateur
externes
PO6.4 Policy, standard and

procedures rollout
et
Authentification
de
pour les connexions
PO7.4 Personnel training

PO7.6 Personnel
procedures
clearance
PO9.4 Risk assessment

AI1.2 Risk analysis report
AI5.2
Supplier
management
contract
A.7.1.1 Inventaire des actifs
DS2.1 Identification of all

supplier
relationships
A.11.5.5 Dconnexion automatique des
DS5.1
43/46
Management
of
IT
CLUSIF 2009
PCI DSS
ISO/IEC
27001
(Clauses 4 8)
acceptable identifi,
compte tenu des
changements
apports : 1) 6)
CobiT (version 4.1)
sessions inactives
security

en exploitation
DS5.2 IT security plan
A.8.1.1 Rles et responsabilits

4.2.3 b)
A.8.2.1 Responsabilits de la direction

A.6.1.2 Coordination de la scurit de
l'information
DS5.6
Security
definition
incident
DS11.6 Security requirements

for data
Management
A.13.1.1 Remonte des vnements lis

la scurit de linformation
A.6.1.7 Relations avec des groupes de
spcialistes
A.13.2.1 Responsabilits et procdures
A.8.2.2 Sensibilisation, qualification et
formations en matire de scurit de
linformation
A.8.1.3 Conditions dembauche
A.8.1.2 Slection
A.6.2.1 Identification
provenant des tiers
des
risques
A.6.2.3 La scurit dans les accords

conclus avec des tiers
A.6.1.5 Engagements de Confidentialit
A.13.2.2 Exploitation des incidents lis
la scurit de linformation dj
survenus
44/46
CLUSIF 2009
XV - Annexe 3 : Bibliographie
http://www.cartes-bancaires.com/spip.php?article28
http://www.cartes-bancaires.com/spip.php?article20&var_recherche=pci
https://www.pcisecuritycouncil.org
http://www.visaeurope.com/aboutvisa/security/ais/aisprogramme.jsp
http://usa.visa.com/merchants/risk_management/cisp.html
http://www.mastercard.com/sdp/
http://www.americanexpress.com
http://www.discovernetwork.com/fraudsecurity/disc.html
http://www.jcb-global.com/english/jdsp/index.html
45/46
CLUSIF 2009
LESPRIT DE LCHANGE
CLUB DE LA SCURIT DE L'INFORMATION FRANAIS

30, rue Pierre Smard
75009 Paris
01 53 25 08 80
clusif@clusif.asso.fr
Tlchargez les productions du CLUSIF sur
www.clusif.asso.fr

Pci DSS

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Pci DSS

Transféré par

Droits d'auteur :

Formats disponibles

LES DOSSIERS TECHNIQUES

PCI DSS : une prsentation

Groupe de travail PCI DSS

CLUB DE LA SECURITE DE LINFORMATION FRANAIS

DI GIAMBATTISTA Vincent Egencia Europe

Herv Schauer Consultants

Nous remercions aussi les adhrents du CLUSIF ayant particip la relecture.

PCI DSS : une prsentation

PCI DSS : une prsentation

IX.1 - MATERIEL OU LOGICIEL CERTIFIE PCI DSS ...................................................................................... 30

PCI DSS : une prsentation

CardSystems Solutions Inc (Fournisseur de service de paiements)

TJX : Groupe de distribution (commerce) prsent aux Etats-Unis et en Europe.

Heartland Payment Systems Inc. (Fournisseur de service de paiements).

PCI DSS : une prsentation

II - Notions de donnes porteur

Donnes des porteurs de carte devant faire

2. Nom du titulaire de la carte de crdit ;

Donnes dauthentification sensibles dont le

5. Donnes de bandes magntiques

Il est important davoir lesprit que ces donnes nappartiennent ni au porteur ni au

PCI DSS : une prsentation

III - Prsentation des acteurs

III.1 - Le PCI Security Standards Council (PCI-SSC)

Figure 1 : source PCI SSC

Data Security Operating Policy (DSOP);

Discover Information Security Compliance (DISC);

Data Security Program ;

Site Data Protection (SDP);

Cardholder Information Security Program (CISP);

Account Information Security Program (AIS).

PCI DSS : une prsentation

de gestion des risques, un programme spcifique charg de la mise en application de la norme

Amliorer la scurit des paiements ;

Susciter une prise de conscience et acclrer ladoption des standards PCI ;

Favoriser la participation des banques, marchands et Payment Service Providers ;

Grer le processus de qualification et de validation des QSA (Qualified Security

Maintenir les listes des QSA, ASV et PED certifis.

Les ressources mises disposition par le PCI SSC sont :

Les standards PCI DSS, PCI-PA-DSS et PED-DSS et la documentation lie ceux-ci :

PCI Data Security Standard ;

PCI DSS Security Audit Procedures ;

PCI DSS Security Scanning Procedures ;

PCI DSS Self Assessment Questionnaires (SAQ) ;

PCI PED Standard ;

PCI Payment Application Data Security Standard (PA-DSS).

PCI SSC FAQ ;

Participation au PCI SSC (rgles de fonctionnement, formulaire dadhsion) ;

Ces documents sont disponibles sur le site Web du PCI SCC :

III.2 - Les rseaux cartes

Les modalits dapplication des standards PCI ;

Les frais, pnalits et chances pour la conformit ;

Lapprobation et publication des entits conformes PCI DSS et PCI-PA-DSS ;

La dfinition des niveaux des marchands et fournisseurs de services ;

Les investigations (Forensics) et rponses aux compromissions.

PCI DSS : une prsentation

PCI DSS : une prsentation

Audit sur site annuel

Scan ASV trimestriel

JCB: moins de 1 M de transactions

Scan ASV trimestriel

Visa: e-commerce de 0,02 M 1 M de

AMEX: moins de 0,05 M de transactions