Questionnaire d`auto-évaluation D

Transcription

Payment Card Industry (PCI)
Data Security Standard
Questionnaire d'auto-évaluation D
et attestation de conformité
Tous les autres commerçants et prestataires de
services qualifiés SAQ
Version 2.0
Octobre 2010
Modifications apportées au document
Date
Version
Description
1er Octobre 2008
1.2
Harmonisation du contenu avec la nouvelle norme PCI DSS v1.2 et
implémentation des changements mineurs notés depuis la v1.1
d'origine.
28 Octobre 2010
2.0
Harmonisation du contenu avec les conditions de la nouvelle norme
PCI DSS et des procédures de test.
SAQ D PCI DSS, v2.0, Modifications apportées au document
Copyright 2010 PCI Security Standards Council LLC
Octobre 2010
Page i
Table des matières
Modifications apportées au document......................................................................... i
Norme de sécurité des données du PCI : Documents connexes............................ iv
Avant de commencer .................................................................................................... v
Compléter le questionnaire d'auto-évaluation.......................................................................v
Étapes de mise en conformité avec la norme PCI DSS ........................................................v
Directives de non-applicabilité de certaines conditions particulières ..............................vii
Attestation de conformité, SAQ D – Version commerçant ........................................ 1
Attestation de conformité, SAQ D – Version prestataire de services....................... 1
Questionnaire d’auto-évaluation D .............................................................................. 1
Création et gestion d’un réseau sécurisé ..............................................................................1
Condition 1 : Installer et gérer une configuration de pare-feu pour protéger les données ......1
Condition 2 : Ne pas utiliser les mots de passe système et autres paramètres de sécurité
par défaut définis par le fournisseur ..........................................................4
Protection des données des titulaires de carte de crédit .....................................................7
Condition 3 : Protéger les données de titulaires de cartes stockées.......................................7
Condition 4 : Crypter la transmission des données des titulaires de carte sur les réseaux
publics ouverts.........................................................................................12
Gestion d’un programme de gestion des vulnérabilités.....................................................13
Condition 5 : Utiliser des logiciels ou des programmes antivirus et les mettre à jour
régulièrement...........................................................................................13
Condition 6 : Développer et gérer des systèmes et des applications sécurisés ...................13
Mise en œuvre de mesures de contrôle d’accès strictes ...................................................18
Condition 7 : Restreindre l'accès aux données des titulaires de carte aux seuls individus qui
doivent les connaître................................................................................18
Condition 8 : Affecter un ID unique à chaque utilisateur d’ordinateur ...................................19
Condition 9 : Restreindre l’accès physique aux données des titulaires de carte ..................22
Surveillance et test réguliers des réseaux ...........................................................................25
Condition 10 : Effectuer le suivi et surveiller tous les accès aux ressources réseau et aux
données des titulaires de carte................................................................25
Condition 11 : Tester régulièrement les processus et les systèmes de sécurité...................27
Gestion d’une politique de sécurité des informations........................................................31
Condition 12 : Gérer une politique de sécurité des informations pour l'ensemble du
personnel .................................................................................................31
Annexe A :
Autres conditions de la norme PCI DSS s’appliquant aux
prestataires de services d’hébergement partagé ..................................................... 35
Condition A.1 : Les prestataires de services d’hébergement partagé doivent protéger
l’environnement des données de titulaires de cartes...............................35
Annexe B :
Contrôles compensatoires ............................................................. 37
Annexe C :
Fiche de contrôles compensatoires .............................................. 39
Fiche de contrôles compensatoires – Exemple complété..................................................40
SAQ D PCI DSS, v2.0, Table des matières
Octobre 2010
Page ii
Annexe D :
Explication de non applicabilité..................................................... 41
SAQ D PCI DSS, v2.0, Table des matières
Octobre 2010
Page iii
Norme de sécurité des données du PCI : Documents connexes
Les documents suivants ont été élaborés pour aider les commerçants et les prestataires de services à
comprendre la norme PCI DSS et le SAQ PCI DSS.
1
Document
Public visé
Norme de sécurité des données du PCI :
Conditions et procédures d'évaluation de sécurité
Tous les commerçants et les
prestataires de services
le document « Navigation dans la norme PCI DSS :
Comprendre l'objectif des conditions
Instructions et directives relatives à l'auto-évaluation
Questionnaire d’auto-évaluation A et attestation
Commerçants qualifiés1
Questionnaire d’auto-évaluation B et attestation
Questionnaire d’auto-évaluation C-VT et attestation
Questionnaire d’auto-évaluation C et attestation
Questionnaire d’auto-évaluation D et attestation
Commerçants qualifiés et
prestataires de services1
Norme de sécurité des données du PCI et norme de sécurité
des données d'application de paiement :
Glossaire des termes, abréviations et acronymes
Pour définir le questionnaire d’auto-évaluation approprié, consulter le document Normes de sécurité
des données du PCI : Instructions et directives relatives à l'auto-évaluation, « Sélection du SAQ et de
l’attestation les plus appropriés pour l'organisation ».
SAQ D PCI DSS, v2.0, Normes de sécurité des données PCI : Documents connexes
Octobre 2010
Page iv
Avant de commencer
Compléter le questionnaire d'auto-évaluation
Le SAQ D a été élaboré pour tous les prestataires de services qualifiés SAQ et pour tous les
commerçants ne répondant pas aux descriptions des SAQ A à C décrites brièvement dans le tableau cidessous et en intégralité dans les instructions et directives relatives au questionnaire d'auto-évaluation
PCI DSS.
SAQ
Description
A
Commerçants carte absente (commerce électronique ou commande par
courrier/téléphone), sous-traitance de toutes les fonctions de données des titulaires
de carte. Ceci ne s'appliquera jamais aux commerçants traditionnels.
B
Commerçants utilisant des périphériques d'impression uniquement, ou des
terminaux autonomes à ligne directe, sans stockage électronique de données de
titulaires de carte.
C-VT
Commerçants utilisant uniquement des terminaux virtuels basés sur le Web, sans
stockage électronique de données de titulaires de carte.
C
Commerçants possédant des systèmes d'application de paiement connectés à
Internet, sans stockage électronique de données de titulaires de carte.
D
Tous les autres commerçants (non compris dans les descriptions des SAQ A à C
ci-dessus) et tous les prestataires de services qualifiés pour remplir un SAQ par
une marque de carte de paiement.
Le SAQ D s'applique aux commerçants qualifiés SAQ ne satisfaisant pas aux critères des types de SAQ
A à C ci-dessus, et à tous les prestataires de services qualifiés pour remplir un SAQ par une marque de
carte de paiement. Les prestataires de services et les commerçants SAQ D valident leur conformité en
complétant un SAQ D et l'attestation de conformité associée.
Alors que la plupart des organisations complétant un SAQ D auront besoin de valider leur conformité à
toutes les conditions PCI DSS, certaines ayant des modèles commerciaux très particuliers ne seront pas
concernées par certaines conditions. Par exemple, une société qui n'utilise en aucun cas la technologie
sans fil n'est pas contrainte de se conformer aux rubriques de la norme PCI DSS spécifiques à la gestion
de la technologie sans fil. Voir les directives ci-dessous pour plus d'informations concernant l'exclusion de
la technologie sans fil et de certaines autres conditions particulières.
Chaque rubrique de ce questionnaire se concentre sur un domaine particulier de sécurité, en fonction des
conditions de la norme PCI DSS.
Étapes de mise en conformité avec la norme PCI DSS
1. Évaluer la conformité d'un environnement à la norme PCI DSS.
2. Compléter le questionnaire d'auto-évaluation D (SAQ D) conformément aux instructions du
document Instructions et directives relatives au questionnaire d'auto-évaluation.
3. Passer avec succès une analyse des vulnérabilités avec un prestataire de services d’analyse
agréé (ASV, Approved Scanning Vendor) par le PCI SSC et se procurer auprès de ce dernier la
preuve de l'exécution réussie de ces analyses.
4. Compléter l'attestation de conformité dans son intégralité.
SAQ D PCI DSS, v2.0, Avant de commencer
Octobre 2010
Page v
5. Envoyer le SAQ, la preuve de l’analyse réussie et l’attestation de conformité, ainsi que toute
autre documentation requise, à l’acquéreur (dans le cas des commerçants), à la marque de carte
de paiement ou à tout autre demandeur (dans le cas de prestataires de services).
Octobre 2010
Page vi
Directives de non-applicabilité de certaines conditions particulières
Exclusion : s'il faut répondre au SAQ D pour valider la conformité à la norme PCI DSS, les exceptions
suivantes sont à prendre en considération. Voir « Non-applicabilité » ci-dessous pour la réponse SAQ
appropriée.

Il est demandé de répondre aux questions spécifiques à la technologie sans fil uniquement si cette
dernière existe à un endroit du réseau (par exemple, les conditions 1.2.3, 2.1.1 et 4.1.1). Noter qu'il
est nécessaire de répondre à la condition 11.1 (utilisation d'un processus pour identifier les points
d'accès sans fil non autorisés) même si la technologie sans fil n'est pas utilisée par le réseau car ce
processus détecte les périphériques malveillants ou non autorisés qui peuvent avoir été ajoutés à
l'insu de l'organisation.

Il est nécessaire de répondre aux questions spécifiques aux applications et codes personnalisés
(conditions 6.3 et 6.5) uniquement si l'organisation conçoit ses propres applications personnalisées.

Il est nécessaire de répondre aux questions concernant les conditions 9.1 à 9.4 uniquement pour les
installations possédant des « zones sensibles » définies ici. Par « zones sensibles », nous entendons
tout centre de données, salle de serveur ou zone abritant des systèmes qui stockent, traitent ou
transmettent des données de titulaires de cartes. Cela exclut les zones où seuls des terminaux pointde-vente sont présents, comme les zones de caisse dans un magasin de vente au détail, mais
comprennent les salles de serveurs administratifs d'un tel magasin qui stocke des données des
titulaires de carte et possède des zones de stockage pour de grandes quantité de données de
titulaires de carte.
Non-applicabilité : ces conditions et d'autres jugées non applicables à un environnement doivent être
indiquées par la mention « s.o. » dans la colonne « Spécial » du SAQ. En conséquence, compléter la
fiche « Explication de non applicabilité » dans l'annexe D pour chaque entrée « s.o. ».
Octobre 2010
Page vii
Attestation de conformité, SAQ D – Version commerçant
Instructions de transmission
Le commerçant doit remplir cette attestation de conformité, qui atteste du respect par le commerçant des Conditions
et procédures d'évaluation de sécurité de la norme de sécurité des données du secteur des cartes de paiement (PCI
DSS) . Compléter toutes les rubriques pertinentes et se reporter aux instructions de transmission présentées sous le
titre « Étapes de mise en conformité avec la norme PCI DSS » dans ce document.
Partie 1. Informations sur l'évaluateur de sécurité qualifié et le commerçant
Partie 1a. Informations sur le commerçant
Nom de la société :
DBA(s) :
Poste
occupé :
Nom du contact :
Téléphone :
E-mail :
Adresse professionnelle :
Ville :
État/province :
Code
postal :
Pays :
URL :
Partie 1b. Informations sur la société QSA (le cas échéant)
Nom du principal contact
QSA :
Poste
occupé :
PCI DSS SAQ D, v2.0, Attestation de conformité, Version commerçant
Octobre 2010
Page 1
Téléphone :
E-mail :
Ville :
État/province :
Code
postal :
Pays :
URL :
Partie 2 Type d’entreprise du commerçant (cocher toutes les cases concernées) :
Détaillant
Télécommunications
Pétrole
Commerce électronique
Épiceries et supermarchés
Commande
par
courrier/téléphone
Autres (préciser) :
Indiquer les installations et les sites compris dans l'examen PCI DSS :
Partie 2a. Relations
La société entretient-elle une relation avec un ou plusieurs agents tiers (par exemple,
passerelles, société d’hébergement sur le Web, tour opérateurs, agents de programmes
de fidélisation, etc.) ?
La société entretient-elle une relation avec plusieurs acquéreurs ?
Oui
Non
Oui
Non
Partie 2b. Traitement des transactions
Comment et dans quelle mesure l'entreprise stocke-t-elle, traite-t-elle et/ou transmet-elle des données de
titulaires de carte ?
Fournir les informations suivantes concernant les applications de paiement utilisées par l'organisation :
Application de paiement utilisée :
Numéro de
version
Dernière validation selon les normes
PABP/PA-DSS.
Octobre 2010
Page 2
Partie 3. Validation de la norme PCI DSS
En se basant sur les résultats mentionnés dans le questionnaire SAQ D du (date d'achèvement), (Nom de la société
du commerçant) certifie l'état de conformité suivant (cocher une seule réponse) :
Conforme : toutes les rubriques du SAQ PCI sont renseignées, toutes les questions ont une réponse
affirmative, ce qui justifie sa classification globale CONFORME et une analyse réussie a été effectuée par un
prestataire de services d'analyse agréé (ASV) PCI SSC, (Nom de la société du commerçant) ayant ainsi
apporté la preuve de sa pleine conformité à la norme PCI DSS.
Non conforme : les rubriques du SAQ PCI DSS ne sont pas toutes renseignées ou les questions n'ont pas
toutes une réponse affirmative, ce qui justifie sa classification globale comme NON CONFORME, ou une
analyse réussie n'a pas été effectuée par un prestataire de services d'analyse agréé PCI SSC, (Nom de la
société du commerçant) n'ayant ainsi pas apporté la preuve de sa pleine conformité à la norme PCI DSS.
Date cible de mise en conformité :
Une entité qui soumet ce formulaire avec l’état Non conforme peut être invitée à compléter le plan d’action
décrit dans la Partie 4 de ce document. Vérifier cette information auprès de l’acquéreur ou de la marque de
carte de paiement avant de compléter la Partie 4, puisque toutes les marques de cartes de paiement ne
l’exigent pas.
Partie 3a. Confirmation de l’état de conformité
Le commerçant confirme ce qui suit :
Le questionnaire d'auto-évaluation D PCI DSS, version (numéro de version du SAQ), a été complété
conformément aux instructions fournies.
Toutes les informations présentes dans le SAQ susmentionné ainsi que dans cette attestation illustrent
honnêtement les résultats de mon évaluation à tous points de vue.
J'ai vérifié auprès de mon fournisseur d'application de paiement que mon système de paiement ne stocke
pas de données d'authentification sensibles après autorisation.
J'ai lu la norme PCI DSS et je reconnais être tenu de maintenir la pleine conformité avec cette norme à tout
moment.
Aucune indication de stockage de données sur bande magnétique (piste)2, données CAV2, CVC2, CID ou
3
4
CVV2 ou données PIN après autorisation de transaction n'a été trouvée sur AUCUN système examiné au
cours de cette évaluation.
Partie 3b. Reconnaissance par le commerçant
2
Données encodées sur la bande magnétique ou données équivalentes sur une puce utilisées pour une autorisation lors d’une
transaction carte présente. Les entités ne peuvent pas conserver l’ensemble des données sur bande magnétique après
autorisation des transactions. Les seuls éléments de données de piste pouvant être conservés sont le numéro de compte, la
date d'expiration et le nom du détenteur.
3
La valeur à trois ou quatre chiffres imprimée sur l’espace réservé à la signature ou à droite de celui-ci ou sur le verso d’une carte
de paiement, utilisée pour vérifier les transactions en carte absente.
4
Les données PIN (Personal Identification Number, numéro d’identification personnel) saisies par le titulaire de la carte lors d’une
transaction carte présente et/ou le bloc PIN crypté présent dans le message de la transaction.
Octobre 2010
Page 3
Signature du représentant du commerçant Ç
Date Ç
Nom du représentant du commerçant Ç
Poste occupé Ç
Société du commerçant représentée Ç
Partie 4. Plan d’action en cas d’état Non conforme
Sélectionner l’état de conformité approprié pour chaque condition. Si la réponse « NON » est donnée à la moindre
condition, indiquer la date à laquelle la société devra se mettre en conformité et une brève description des actions
à mettre en œuvre à cette fin. Vérifier cette information auprès de l’acquéreur ou de la marque de carte de
paiement avant de compléter la Partie 4, puisque toutes les marques de cartes de paiement ne l’exigent pas.
État de conformité
(cocher une seule
option)
Condition
PCI DSS
1
2
Description de la condition
OUI
NON
Date et actions de mise en
conformité
(si l’état de conformité est
« NON »)
Installer et gérer une configuration de
pare-feu pour protéger les données des
titulaires de carte
Ne pas utiliser les mots de passe
système et autres paramètres de
sécurité par défaut définis par le
fournisseur
3
Protéger les données des titulaires de
carte stockées
4
Crypter la transmission des données des
titulaires de carte sur les réseaux publics
ouverts
5
Utiliser des logiciels antivirus et les
mettre à jour régulièrement
6
Développer et gérer des systèmes et des
applications sécurisés
7
Restreindre l'accès aux données des
titulaires de carte aux seuls individus qui
doivent les connaître
8
Affecter un ID unique à chaque
utilisateur d’ordinateur
Octobre 2010
Page 4
(cocher une seule
option)
9
Restreindre l’accès physique aux
données des titulaires de carte
10
Effectuer le suivi et surveiller tous les
accès aux ressources réseau et aux
11
Tester régulièrement les processus et les
systèmes de sécurité
12
Gérer une politique de sécurité des
informations pour l'ensemble du
personnel
Octobre 2010
Page 5
Attestation de conformité, SAQ D – Version prestataire de services
Instructions de transmission
Le prestataire de services doit remplir cette attestation de conformité, qui atteste de son respect des Conditions et
procédures d'évaluation de sécurité de la norme de sécurité des données du secteur des cartes de paiement (PCI
DSS). Compléter toutes les rubriques pertinentes et se reporter aux instructions de transmission présentées sous le
titre « Étapes de mise en conformité avec la norme PCI DSS » dans ce document.
Partie 1. Informations sur l'évaluateur de sécurité qualifié et le prestataire de services
Partie 1a. Informations sur le prestataire de services
DBA(s) :
Poste
occupé :
Nom du contact :
Téléphone :
E-mail :
Ville :
État/province :
Pays :
Code
postal :
URL :
Partie 1b. Informations sur la société QSA (le cas échéant)
Octobre 2010
Page 1
Nom du principal contact
QSA :
Poste
occupé :
Téléphone :
E-mail :
Ville :
État/province :
Code
postal :
Pays :
URL :
Partie 2. Informations relatives à l'évaluation PCI DSS
Partie 2a. Services fournis COMPRIS dans le champ d'application de l'évaluation PCI DSS
(cocher toutes les cases concernées)
Prestataire
de
d'hébergement sécurisé 3D
services
Gestion des comptes
Prestataire
de
d'hébergement –Matériel
services
Traitement des paiements –
GAB
Prestataire
de
d'hébergement – Web
services
MOTO
Autorisation
Traitement des émetteurs
Internet
Services administratifs
Programmes de fidélité
Point de vente
Gestion de la facturation
Services gérés
Services prépayés
Compensation et règlement
Services aux commerçants
Gestion des dossiers
Préparation des données
Services des fraudes et rejets de
débit
Prestataire
réseau/Transmetteur
Passerelle
paiement/Commutateur
Paiements
gouvernement
des
impôts/du
de
Indiquer les installations et les sites compris dans l'examen PCI DSS :
Octobre 2010
Page 2
Partie 2b. Si des services indiqués sont fournis par le prestataire de services mais NE SONT PAS
COMPRIS dans le champ d'application de l'évaluation PCI DSS, les cocher ci-dessous :
Prestataire
de
d'hébergement sécurisé 3D
services
Gestion des comptes
Prestataire
de
d'hébergement –Matériel
services
GAB
Prestataire
de
d'hébergement – Web
services
MOTO
Autorisation
Traitement des émetteurs
Internet
Services administratifs
Programmes de fidélité
Point de vente
Gestion de la facturation
Services gérés
Services prépayés
Compensation et règlement
Services aux commerçants
Gestion des dossiers
Préparation des données
Services des fraudes et rejets de
débit
Prestataire
réseau/Transmetteur
Passerelle
paiement/Commutateur
Paiements
gouvernement
des
impôts/du
de
Partie 2c. Relations
La société entretient-elle une relation avec un ou plusieurs prestataires de services tiers (par
exemple, passerelles, prestataires de services d’hébergement sur le Web, tour opérateurs,
agents de programmes de fidélisation, etc.) ?
Oui
Non
Partie 2d. Traitement des transactions
Comment et dans quelle mesure l'entreprise stocke-t-elle, traite-t-elle et/ou transmet-elle des données de titulaires
de carte ?
Application de paiement utilisée :
Numéro de
version
Dernière validation selon les normes
PABP/PA-DSS.
Fournir les informations suivantes concernant les applications de paiement utilisées par l'organisation :
Partie 3. Validation de la norme PCI DSS
En se basant sur les résultats mentionnés dans le questionnaire SAQ D du (date d'achèvement du SAQ), (Nom de la
société du prestataire de services) certifie l'état de conformité suivant (cocher une seule réponse) :
Octobre 2010
Page 3
Conforme : toutes les rubriques du questionnaire SAQ PCI sont renseignées et toutes les questions ont pour
réponse « Oui », ce qui justifie sa classification globale comme CONFORME, et une analyse réussie a été
effectuée par un prestataire de services d'analyse agréé PCI SSC, (Nom de la société du prestataire de
services) ayant ainsi apporté la preuve de sa pleine conformité à la norme PCI DSS.
Non conforme : les rubriques du questionnaire SAQ PCI ne sont pas toutes renseignées ou certaines
questions ont pour réponse « non », ce qui justifie sa classification globale comme NON CONFORME, ou une
analyse réussie n'a pas été effectuée par un prestataire de services d'analyse agréé PCI SSC, (Nom de la
société du prestataire de services) n'ayant ainsi pas apporté la preuve de sa pleine conformité à la norme PCI
DSS.
Date cible de mise en conformité :
Une entité qui soumet ce formulaire avec l’état Non conforme peut être invitée à compléter le plan d’action
décrit dans la Partie 4 de ce document. Vérifier cette information auprès de l’acquéreur ou de la marque de
carte de paiement avant de compléter la Partie 4, puisque toutes les marques de cartes de paiement ne
l’exigent pas.
Octobre 2010
Page 4
Partie 3a. Confirmation de l’état de conformité
Le prestataire de services confirme ce qui suit :
Le questionnaire d'auto-évaluation D PCI DSS, version (insérer le numéro de version), a été complété
conformément aux instructions fournies.
Toutes les informations présentes dans le SAQ susmentionné ainsi que dans cette attestation illustrent
honnêtement les résultats de mon évaluation.
J'ai lu la norme PCI DSS et je reconnais être tenu de maintenir la pleine conformité avec cette norme à tout
moment.
Aucune indication de stockage de données sur bande magnétique (piste)5, données CAV2, CVC2, CID ou
CVV26ou données PIN7 après autorisation de transaction n'a été trouvée sur AUCUN système examiné au
cours de cette évaluation.
Partie 3b. Reconnaissance par le prestataire de services
Signature du représentant du prestataire de services Ç
Date Ç
Nom du représentant du prestataire de services Ç
Poste occupé Ç
Entreprise prestataire de services représentée Ç
Partie 4. Plan d’action en cas d’état Non conforme
Sélectionner l’état de conformité approprié pour chaque condition. Si la réponse « NON » est donnée à la moindre
condition, indiquer la date à laquelle la société devra se mettre en conformité et une brève description des actions
à mettre en œuvre à cette fin. Vérifier cette information auprès de l’acquéreur ou de la marque de carte de
paiement avant de compléter la Partie 4, puisque toutes les marques de cartes de paiement ne l’exigent pas.
5
Données encodées sur la bande magnétique ou données équivalentes sur une puce utilisées pour une autorisation lors d’une
transaction carte présente. Les entités ne peuvent pas conserver l’ensemble des données sur bande magnétique après
autorisation des transactions. Les seuls éléments de données de piste pouvant être conservés sont le numéro de compte, la
date d'expiration et le nom du détenteur.
6
La valeur à trois ou quatre chiffres imprimée sur l’espace réservé à la signature ou à droite de celui-ci ou sur le verso d’une carte
de paiement, utilisée pour vérifier les transactions en carte absente.
7
Les données PIN (Personal Identification Number, numéro d’identification personnel) saisies par le titulaire de la carte lors d’une
transaction carte présente et/ou le bloc PIN crypté présent dans le message de la transaction.
Octobre 2010
Page 5
(cocher une seule
option)
Condition
PCI DSS
1
2
3
Description de la condition
NON
Installer et gérer une configuration de
pare-feu pour protéger les données des
titulaires de carte
Ne pas utiliser les mots de passe
système et autres paramètres de
sécurité par défaut définis par le
fournisseur
Protéger les données des titulaires de
carte stockées
4
Crypter la transmission des données des
titulaires de carte sur les réseaux publics
ouverts
5
Utiliser des logiciels antivirus et les
mettre à jour régulièrement
6
Développer et gérer des systèmes et des
applications sécurisés
7
OUI
Date et actions de mise en
conformité
(si l’état de conformité est
« NON »)
Restreindre l'accès aux données des
titulaires de carte aux seuls individus
qui doivent les connaître
8
Affecter un ID unique à chaque
utilisateur d’ordinateur
9
Restreindre l’accès physique aux
10
Effectuer le suivi et surveiller tous les
accès aux ressources réseau et aux
11
Tester régulièrement les processus et les
systèmes de sécurité
12
Gérer une politique de sécurité des
informations pour l'ensemble du
personnel
Octobre 2010
Page 6
Questionnaire d’auto-évaluation D
Remarque : les questions suivantes sont numérotées conformément aux conditions PCI DSS et aux
procédures de test, comme défini dans le document Conditions et procédures d'évaluation de sécurité de
la norme PCI DSS.
Date de réalisation :
Création et gestion d’un réseau sécurisé
Condition 1 : Installer et gérer une configuration de pare-feu pour protéger les données
Question PCI DSS
1.1
Réponse :
Oui
Non
Spécial*
Les normes de configuration des pare-feu et des routeurs établies
comprennent-elles les éléments suivants :
1.1.1
Un processus formel existe-t-il pour l'approbation et le test de
toutes les connexions réseau externes et des changements
apportés aux configurations des pare-feu et des routeurs ?
1.1.2
(a) Existe-t-il un schéma de réseau actif (par exemple,
illustrant les flux des données des titulaires de carte)
indiquant toutes les connexions aux données des titulaires
de carte, y compris tous les réseaux sans fil ?
(b) Ce schéma est-il tenu à jour ?
1.1.3
(a) Les normes de configuration des pare-feu comprennentelles la condition d’un pare-feu pour chaque connexion
Internet et entre toute zone démilitarisée (DMZ) et la zone
de réseau Internet ?
(b) Le schéma de réseau actuel est-il conforme aux normes
de configuration des pare-feu ?
1.1.4
Les normes de configuration des pare-feu et des routeurs
comprennent-elles une description des groupes, des rôles et
des responsabilités pour la gestion logique des composants
réseau ?
1.1.5
(a) Les normes de configuration des pare-feu et des routeurs
comprennent-elles une liste détaillée des services,
protocoles et ports nécessaires à la conduite des activités
de l’entreprise (par exemple, les protocoles HTTP
[Hypertext Transfer Protocol], SSL [Secure Sockets
Layer], SSH [Secure Shell] et VPN [Virtual Private
Network]) ?
(b) Tous les services, protocoles et ports non sécurisés
permis sont-ils nécessaires, et les fonctions de sécurité
sont-elles détaillées et déployées pour chacun ?
Remarque : les protocoles FTP, Telnet, POP3, IMAP et
SNMP sont des exemples de services, protocoles ou ports
non sécurisés, mais ne sont pas les seuls.
SAQ D PCI DSS, v2.0, Questionnaire d'auto-évaluation
Octobre 2010
Page 1
Question PCI DSS
1.1.6
Réponse :
Oui
Non
Spécial*
(a) Les normes de configuration des pare-feu et des routeurs
exigent-elles l’examen des règles des pare-feu et des
routeurs au moins tous les six mois ?
(b) Toutes les règles des pare-feu et des routeurs sont-elles
vérifiées au moins tous les six mois ?
1.2
Les configurations de pare-feu restreignent-elles les connexions
entre les réseaux non approuvés et les composants du système
dans l’environnement des données des titulaires de carte comme
suit :
Remarque : un « réseau non approuvé » est un réseau externe aux
réseaux appartenant à l’entité sous investigation et/ou qui n’est pas
sous le contrôle ou la gestion de l’entité.
1.2.1
(a) Les trafics entrant et sortant sont-ils restreints au trafic
nécessaire à l’environnement des données des titulaires
de carte et les restrictions sont-elles détaillées ?
(b) Tous les autres trafics entrants et sortants sont-ils
explicitement refusés (par exemple à l’aide d’une
instruction « refuser tout » explicite ou d’un refus implicite
après une instruction d’autorisation) ?
1.3
1.2.2
Les fichiers de configuration du routeur sont-ils sécurisés et
synchronisés ?
1.2.3
Des pare-feu de périmètre sont-ils installés entre tous les
réseaux sans fil et l’environnement des données des titulaires
de carte, et ces pare-feu sont-ils configurés pour refuser ou
contrôler le trafic (si celui-ci est nécessaire à des fins
professionnelles) de l’environnement sans fil vers
l’environnement des données des titulaires de carte ?
La configuration du pare-feu empêche-t-elle l’accès public direct
entre Internet et les composants du système dans l’environnement
des données de titulaire de carte comme suit :
1.3.1
Une zone démilitarisée (DMZ) est-elle en place pour
restreindre le trafic entrant aux seuls composants du
système fournissant des services, protocoles et ports
autorisés, accessibles au public ?
1.3.2
Le trafic Internet entrant est-il restreint aux adresses IP dans
la zone démilitarisée ?
1.3.3
Les connexions directes sont-elles interdites pour le trafic
entrant ou sortant entre Internet et l’environnement des
données des titulaires de carte ?
1.3.4
Le passage d'adresses internes est-il interdit depuis Internet
vers la zone démilitarisée ?
1.3.5
Le trafic sortant de l'environnement des données des
titulaires de carte vers Internet est-il explicitement autorisé ?
Octobre 2010
Page 2
Question PCI DSS
Réponse :
1.3.6
Un contrôle avec état, également connu comme filtrage des
paquets dynamique, est-il en place (c'est-à-dire, seules les
connexions établies sont autorisées sur le réseau) ?
1.3.7
Les composants du système qui stockent les données de
titulaires de cartes (comme une base de données) se
trouvent-ils dans une zone de réseau interne, isolée de la
zone démilitarisée et des autres réseaux non approuvés ?
1.3.8
(a) Des moyens sont-ils en place pour prévenir la
divulgation d'adresses IP et d'informations
d'acheminement confidentielles sur Internet ?
Oui
Non
Spécial*
Remarque : voici quelques exemples de méthodes pour
dissimuler les adresses IP :
• traduction d'adresse réseau (Network Address
Translation – NAT) ;
• protéger les serveurs contenant des données de
titulaires de cartes derrière des serveurs proxy/parefeu ou des caches de contenu ;
• retrait ou filtrage des annonces d'acheminement pour
les réseaux privés employant des adresses
enregistrées ;
• utilisation interne de l'espace d'adresse RFC1918 au
lieu d'adresses enregistrées.
(b) La divulgation d'adresses IP et d'informations
d'acheminement confidentielles à des entités externes
est-elle autorisée ?
1.4
(a) Un logiciel pare-feu personnel est-il installé sur les ordinateurs
portables et/ou ordinateurs appartenant à des employés équipés
d’une connexion directe à Internet (par exemple, ordinateurs
portables dont se servent les employés), qui sont utilisés pour
accéder au réseau de l’organisation ?
(b) Le logiciel pare-feu personnel est-il configuré selon des normes
particulières et cette configuration ne peut-elle pas être modifiée
par les utilisateurs d'ordinateurs portables et/ou appartenant à
des employés ?
Octobre 2010
Page 3
Condition 2 : Ne pas utiliser les mots de passe système et autres paramètres de sécurité
par défaut définis par le fournisseur
Question PCI DSS
2.1
Réponse :
Oui
Non
Spécial*
Les paramètres par défaut définis par le fournisseur sont-ils toujours
changés avant l'installation d'un système sur le réseau ?
Les paramètres par défaut définis par le fournisseur comprennent,
entre autres, des mots de passe, des chaînes de communauté SNMP
(Simple Network Management Protocol), et l'élimination des comptes
qui ne sont pas nécessaires.
2.1.1
Pour les environnements sans fil connectés à
l'environnement des données des titulaires de carte ou
transmettant ces données, les paramètres par défaut sont-ils
changés comme suit :
(a) Les clés de cryptage par défaut sont-elles modifiées à
l'installation et à chaque fois qu'un employé qui les
connaît quitte la société ou change de poste ?
(b) Les chaînes de communauté SNMP par défaut sur les
périphériques sans fil sont-elles modifiées ?
(c) Les mots de passe/locutions de passage par défaut des
points d’accès sont-ils modifiés ?
(d) Le firmware des périphériques sans fil est-il mis à jour de
manière à prendre en charge un cryptage robuste pour
l'authentification et la transmission sur les réseaux sans
fil ?
(e) Les autres paramètres par défaut liés à la sécurité,
définis par le fournisseur des équipements sans fil sontils modifiés, le cas échéant ?
2.2
(a) Des normes de configurations sont-elles conçues pour tous les
composants du système et sont-elles cohérentes avec les normes
renforçant les systèmes en vigueur dans le secteur ?
Les sources des normes renforçant les systèmes en vigueur dans
le secteur peuvent comprendre, entre autres, l'Institut SANS
(SysAdmin Audit Network Security), le NIST (National Institute of
Standards Technology), l'ISO (International Organization for
Standardization), et le CIS (Center for Internet Security).
(b) Les normes de configuration du système sont-elles mises à jour
au fur et à mesure de l'identification de nouvelles vulnérabilités,
comme indiqué dans la condition 6.2 ?
(c) Les normes de configuration du système sont-elles appliquées
lorsque de nouveaux systèmes sont configurés ?
(d) Les normes de configuration du système comprennent-elles ce qui
suit :
Octobre 2010
Page 4
Question PCI DSS
2.2.1
Réponse :
Oui
Non
Spécial*
(a) Une seule fonction principale est-elle déployée par
serveur afin d'éviter la coexistence, sur le même serveur,
de fonctions exigeant des niveaux de sécurité différents ?
(Par exemple, les serveurs Web, les serveurs de bases de
données et les serveurs DNS doivent être déployés sur des
serveurs distincts).
(b) Si des technologies de virtualisation sont utilisées, une
seule fonction principale est-elle déployée par composant
de système ou périphérique virtuels ?
2.2.2
(a) Seuls les services, protocoles, démons, etc. nécessaires
sont-ils activés pour le fonctionnement du système (les
services et protocoles qui ne sont pas directement
nécessaires pour exécuter la fonction du périphérique
sont désactivés) ?
(b) Tous les services, protocoles ou ports non sécurisés
activés sont-ils justifiés, et les fonctions de sécurité sontelles détaillées et déployées pour chacun ?
(Par exemple, des technologies sécurisées, SSH, S-FTP,
SSL ou IPSec VPN, sont utilisées pour protéger des services
non sécurisés comme NetBIOS, le partage de fichiers,
Telnet, FTP, etc.).
2.2.3
(a) Les administrateurs système et/ou le personnel
paramétrant les composants du système connaissent-ils
la configuration des paramètres de sécurité courants
pour ces composants du système ?
(b) La configuration des paramètres de sécurité courants estelle comprise dans les normes de configuration du
système ?
(c) La configuration des paramètres de sécurité est-elle
installée de manière appropriée sur les composants du
système ?
2.2.4
(a) Toutes les fonctionnalités qui ne sont pas nécessaires,
par exemple scripts, pilotes, fonctions, sous-systèmes,
systèmes de fichiers et serveurs Web superflus, ont-elles
été supprimées ?
(b) Les fonctions activées sont-elles détaillées et prennentelles en charge une configuration sécurisée ?
(c) Seule la fonctionnalité documentée est-elle présente sur
les composants de système ?
2.3
L'accès administratif non-console est-il crypté de manière à :
utiliser des technologies telles que SSH, VPN ou SSL/TLS pour la
gestion via le Web et autres accès administratifs non-console.
Octobre 2010
Page 5
Question PCI DSS
Réponse :
Oui
Non
Spécial*
(a) Tous les accès administratifs non-console sont-ils cryptés avec
une cryptographie robuste, et une méthode de cryptographie
robuste est-elle invoquée avant de demander le mot de passe
administrateur ?
(b) Tous les fichiers de services du système et de paramètres sont-ils
configurés afin de prévenir l'utilisation de Telnet et d'autres
commandes de connexions à distances non sécurisées ?
(c) L’accès administrateur aux interfaces de gestion Web est-il crypté
au moyen d’une méthode de cryptage robuste ?
2.4
Pour les prestataires de services d’hébergement partagé, les
systèmes sont-ils configurés de manière à protéger l'environnement
hébergé et données de titulaires de carte de chaque entité ?
Voir l’Annexe A : Conditions supplémentaires de la norme PCI DSS
s’appliquant aux prestataires de services d’hébergement partagé afin
de satisfaire à des conditions particulières.
Octobre 2010
Page 6
Protection des données des titulaires de carte de crédit
Condition 3 : Protéger les données de titulaires de cartes stockées
Question PCI DSS
3.1
Réponse :
Oui
Non
Spécial*
Les politiques et procédures de conservation et d'élimination sontelles déployées comme suit :
3.1.1
(a) Des politiques et procédures de conservation et
d'élimination sont-elles déployées et comprennent-elles
des conditions particulières pour la conservation de
données de titulaires de carte à des fins professionnelles,
légales et/ou réglementaires ?
Par exemple, les données de titulaires de carte doivent être
détenues durant une période X pour des raisons
professionnelles Y.
(b) Les politiques et les procédures comprennent-elles des
dispositions sur l'élimination sécurisée des données qui
ne sont plus requises à des fins légales, réglementaires
ou professionnelles, notamment la suppression des
(c) Les politiques et les procédures couvrent-elles l'intégralité
du stockage des données des titulaires de carte ?
(d) Les processus et procédures comprennent-ils au moins
l'un des points suivants ?
• Un processus programmé (automatique ou manuel)
pour supprimer, au moins une fois par trimestre, les
données de titulaires de cartes stockées, excédant les
conditions définies dans la politique de conservation
des données.
• L'obligation d'une vérification, au moins trimestrielle,
afin de contrôler que les données de titulaires de
cartes stockées n'excèdent pas les conditions définies
dans la politique de conservation des données.
(e) Toutes les données des titulaires de carte stockées
satisfont-elles aux conditions définies dans la politique de
conservation des données ?
3.2
(a) Dans le cas des émetteurs et/ou des sociétés qui prennent en
charge les services d'émission et stockent des données
d'authentification sensibles, ce stockage est-il justifié du point
de vue professionnel et ces données sont-elles protégées ?
(b) Pour toutes les autres entités, si des données d’authentification
sensibles sont reçues et supprimées, des processus sont-ils en
place pour sécuriser la suppression des données afin de vérifier
que ces dernières sont irrécupérables ?
(c) Tous les systèmes adhèrent-ils aux conditions suivantes
concernant le non stockage de données d'authentification
sensibles après autorisation (même si elles sont cryptées) :
Octobre 2010
Page 7
Question PCI DSS
3.3
Réponse :
3.2.1
La totalité du contenu d’une quelconque piste sur la bande
magnétique (située au verso d'une carte, sur une puce ou
ailleurs) n'est-elle stockée en aucune circonstance ?
Ces données sont également désignées piste complète,
piste, piste 1, piste 2 et données de bande magnétique.
Remarque : dans le cadre normal de l'activité, il est parfois
nécessaire de conserver les éléments de données de la
bande magnétique suivants :
le nom du titulaire de la carte ;
le numéro de compte primaire (PAN, Primary Account
Number),
la date d'expiration,
le code de service.
Afin de réduire le risque autant que possible, stocker
uniquement les éléments de données nécessaires à l'activité.
3.2.2
Le code ou la valeur de vérification de carte (nombre à trois
ou quatre chiffres figurant au recto ou au verso de la carte de
paiement) ne sont-ils stockés en aucune circonstance ?
3.2.3
Le code PIN (Personal Identification Number, numéro
d'identification personnel) ou le bloc PIN crypté ne sont-ils
stockés en aucune circonstance ?
Oui
Non
Spécial*
Le PAN est-il masqué lorsqu'il s'affiche (les six premiers chiffres et
les quatre derniers sont le maximum de chiffres affichés) ?
Remarques :
Cette condition ne s'applique pas aux employés et autres ayant
un besoin spécifique de voir l'intégralité du PAN.

Cette condition ne se substitue pas aux conditions plus strictes
qui sont en place et qui régissent l’affichage des données des
titulaires de carte, par exemple, pour les reçus des points de
vente.
Octobre 2010
Page 8
Question PCI DSS
Réponse :
Oui
Non
Spécial*
Le PAN est-il rendu illisible où qu'il soit stocké (y compris les
données sur support numérique portable, support de sauvegarde et
journaux), en utilisant l'une des approches suivantes :
hachage unilatéral s'appuyant sur une méthode
cryptographique robuste (la totalité du PAN doit être haché) ;
troncature (le hachage ne peut pas être utilisé pour remplacer
le segment tronqué du PAN) ;
tokens et pads d'index (les pads doivent être stockés de
manière sécurisée) ;
cryptographie robuste associée aux processus et procédures
de gestion des clés.
Remarque : il s'agit d'un effort relativement peu important pour un
individu malveillant de reconstruire les données du PAN d'origine,
s'il a à la fois accès à la version tronquée et hachée d'un PAN.
Lorsque les versions hachée et tronquée du même PAN sont
présentes dans l'environnement de l'entité, des contrôles
supplémentaires doivent être en place pour garantir que les
versions hachée et tronquée ne peuvent pas être corrélées pour
reconstituer le PAN d'origine.
3.4
3.4.1
Si un cryptage par disque est utilisé (plutôt qu'un cryptage de
base de données au niveau fichier ou colonne), l'accès est-il
géré comme suit :
(a) L'accès logique aux systèmes de fichier cryptés est-il
géré indépendamment des mécanismes de contrôle
d'accès au système d'exploitation natif (par exemple, en
n'utilisant pas des bases de données de comptes
d'utilisateur locales) ?
(b) Les clés cryptographiques sont-elles stockées de manière
sécurisée (par exemple, sur des supports amovibles
correctement protégés avec des contrôles d'accès
stricts) ?
(c) Les données des titulaires de carte sur les supports
amovibles sont-elles cryptées où qu'elles soient
stockées ?
Remarque : si le cryptage de disque n'est pas utilisé pour
crypter les supports amovibles, les données stockées sur ce
support devront être rendues illisibles par une autre
méthode.
Les clés utilisées pour sécuriser des données des titulaires de carte
sont-elles protégées contre la divulgation et l'utilisation illicites
comme suit :
Remarque : cette condition s'applique également aux clés de
cryptage de clés utilisées pour protéger les clés de cryptage de
données. Ces clés de cryptage de clés doivent être au moins aussi
robustes que la clé de cryptage de données.
3.5
3.5.1
L'accès aux clés cryptographiques est-il restreint au plus petit
nombre d’opérateurs possible ?
Octobre 2010
Page 9
Question PCI DSS
3.5.2
Réponse :
Oui
Non
Spécial*
(a) Les clés sont-elles stockées en format crypté et les clés
de cryptage de clés sont-elles stockées à un
emplacement différent des clés de cryptage de
données ?
(b) Les clés cryptographiques sont-elles stockées de manière
sécurisée dans aussi peu d’endroits et de formes que
possible ?
3.6
(a) Tous les processus et les procédures de gestion des clés
cryptographiques sont-ils intégralement détaillés et déployés
pour les clés cryptographiques servant au cryptage des
(b) Pour les prestataires de services uniquement : si des clés sont
partagées avec des clients pour la transmission ou le stockage
de données de titulaires de cartes, une documentation est-elle
fournie aux clients avec les instructions sur la manière de
sécuriser la transmission, le stockage et la mise à jour des clés
conformément aux conditions 3.6.1 à 3.6.8 ci-dessous ?
(c) Des processus et procédures de gestion des clés sont-ils
déployés pour exiger ce qui suit :
3.6.1
Les procédures de clés cryptographiques comprennent-elles
la génération de clés cryptographiques robustes ?
3.6.2
la distribution sécurisée de clés cryptographiques ?
3.6.3
le stockage sécurisé de clés cryptographiques ?
3.6.4
des changements pour les clés ayant atteint la fin de leur
cryptopériode (par exemple, après la fin d'une période définie
et/ou après la production d'une certaine quantité de
cryptogrammes par une clé donnée), comme l'a défini le
fournisseur de l'application associée ou le propriétaire de la
clé, et selon les meilleures pratiques et directives du secteur
(par exemple, la publication spéciale NIST 800-57) ?
3.6.5
(a) Les procédures de clés cryptographiques comprennentelles le retrait ou le changement des clés (par exemple,
en les archivant, détruisant, et/ou révoquant selon le
cas), lorsque le degré d'intégrité d'une clé est affaibli (par
exemple, le départ d'un employé ayant connaissance du
texte clair d'une clé) ?
(b) Les procédures de clés cryptographiques comprennentelles le remplacement des clés compromises ou
suspectées de l'être ?
(c) Si des clés cryptographiques retirées ou remplacées sont
conservées, ces clés sont-elles utilisées uniquement à
des fins de décryptage/vérification (et non pour des
opérations de cryptage) ?
Octobre 2010
Page 10
Question PCI DSS
Réponse :
3.6.6
le fractionnement des connaissances et un double contrôle
(par exemple, exigeant deux ou trois personnes, chacune
connaissant uniquement sa propre fraction de la clé, pour
reconstituer la clé entière) pour des opérations de gestion de
clés en texte clair ?
Remarque : la génération, la transmission, le chargement, le
stockage et la destruction de clés sont quelques-uns des
exemples d'interventions de gestion manuelle des clés.
3.6.7
la prévention d'une substitution non autorisée des clés
cryptographiques ?
3.6.8
Les opérateurs chargés de la gestion de clés
cryptographiques doivent-ils reconnaître (par écrit ou de
manière électronique) formellement qu’ils comprennent et
acceptent leurs responsabilités ?
Oui
Non
Spécial*
Octobre 2010
Page 11
Condition 4 : Crypter la transmission des données des titulaires de carte sur les réseaux
publics ouverts
Question PCI DSS
4.1
Réponse :
Oui
Non
Spécial*
(a) Des protocoles de cryptographie et de sécurité robustes, SSL/TLS
ou IPSEC par exemple, sont-ils déployés pour protéger les
données des titulaires de carte sensibles lors de leur transmission
sur des réseaux publics ouverts ?
Voici des exemples de réseaux publics ouverts dans le champ
d'application de la norme PCI DSS : Internet, WiFi, GSM (Global
System For Mobile Communications) et GPRS (General Packet Radio
Service).
(b) Seuls des clés/certificats approuvés sont-ils acceptés ?
(c) Des protocoles de sécurité sont-ils déployés pour utiliser
uniquement des configurations sécurisées et ne pas prendre en
charge des versions ou configurations non sécurisées ?
(d) Un niveau de cryptage approprié est-il mi en place pour la
méthodologie de cryptage employée (se reporter aux
recommandations/meilleures pratiques du fournisseur) ?
(e) Pour les implémentations SSL/TLS :
•
•
4.1.1
4.2
La mention HTTPS apparaît-elle dans l'adresse URL
(Universal Record Locator) du navigateur ?
Les données des titulaires de carte sont-elles requises
uniquement lorsque la mention HTTPS apparaît dans
l'adresse URL ?
Les meilleures pratiques du secteur (par exemple, IEEE
802.11i) sont-elles déployées pour appliquer un cryptage
robuste à l'authentification et la transmission pour des
réseaux sans fil transmettant des données de titulaires de
carte ou connectés à l'environnement des données des
Remarque : l'utilisation du protocole WEP comme contrôle
de sécurité est interdit depuis le 30 juin 2010.
(a) Les PAN sont-ils rendus illisibles ou sécurisés avec une méthode
de cryptographie robuste chaque fois qu'ils sont envoyés par des
technologies de messagerie pour utilisateurs finaux (par exemple,
les e-mails, la messagerie instantanée, le chat) ?
(b) Des politiques sont-elles déployées pour interdire la transmission
de PAN non protégés à l’aide de technologies de messagerie pour
utilisateurs finaux ?
Octobre 2010
Page 12
Gestion d’un programme de gestion des vulnérabilités
Condition 5 : Utiliser des logiciels ou des programmes antivirus et les mettre à jour
régulièrement
Question PCI DSS
5.1
Oui
Non
Spécial*
Des logiciels antivirus sont-ils déployés sur tous les systèmes
régulièrement affectés par des logiciels malveillants ?
5.1.1
5.2
Réponse :
Tous les programmes antivirus détectent-ils et éliminent-ils
tous les types de logiciels malveillants connus (par exemple,
virus, chevaux de Troie, vers, spyware, adware et
dissimulateurs d’activités), et constituent-ils une protection
efficace contre ces fléaux ?
Tous les logiciels antivirus sont-ils à jour, en cours d'exécution et
génèrent-ils des journaux d'audit en procédant comme suit :
(a) La politique anti-virus requiert-elle de mettre à jour le logiciel
anti-virus et les définitions ?
(b) L'installation principale du logiciel est-elle activée pour des
mises à jour et analyses automatiques ?
(c) Les mises à jour et les analyses périodiques automatiques sontelles activées ?
(d) Tous les mécanismes anti-virus génèrent-ils des journaux
d'audit et les journaux sont-ils conservés conformément à la
condition 10.7 de la norme PCI DSS ?
Condition 6 : Développer et gérer des systèmes et des applications sécurisés
Question PCI DSS
6.1
Réponse :
Oui
Non
Spécial*
(a) Tous les logiciels et les composants du système sont-ils dotés
des derniers correctifs de sécurité développés par le
fournisseur, afin de les protéger des vulnérabilités connues ?
(b) Les correctifs de sécurité essentiels sont-ils installés dans le
mois qui suit leur publication ?
Remarque : une entreprise peut envisager la mise en œuvre d'une
approche en fonction du risque pour définir la priorité des correctifs
à installer. Par exemple, en accordant aux infrastructures
stratégiques (par exemple, bases de données, périphériques et
systèmes orientés public) une priorité supérieure à celle des
périphériques internes moins cruciaux, de sorte que les systèmes et
les périphériques hautement prioritaires soient traités dans un délai
d'un mois, tandis que les périphériques et systèmes moins
stratégiques le soient dans un délai de trois mois.
Octobre 2010
Page 13
Question PCI DSS
6.2
Réponse :
Oui
Non
Spécial*
(a) Existe-t-il un processus pour identifier les vulnérabilités de
sécurité nouvellement découvertes, notamment un classement
des risques assigné à ces vulnérabilités ? (Au minimum, les
vulnérabilités de plus haut risque, les plus critiques, doivent être
classées comme « à haut risque »).
Remarque : le classement des risques doit se baser sur les
meilleures pratiques du secteur. Par exemple, les critères de
classement des vulnérabilités à « haut » risque peuvent comprendre
un score CVSS (Common Vulnerability Scoring System, système de
notation de vulnérabilité commun) de 4.0 ou plus, et/ou un correctif
proposé par le fournisseur, classé comme « critique », et/ou une
vulnérabilité affectant un composant essentiel du système.
Le classement des vulnérabilités est considéré comme une
meilleure pratique jusqu'au 30 juin 2012, après quoi ce sera une
obligation.
(b) Des processus pour identifier les nouvelles vulnérabilités de
sécurité comprennent-ils l'utilisation des sources externes
d'information sur la vulnérabilité de sécurité ?
6.3
(a) Les processus de conception de logiciel sont-ils basés sur les
normes/meilleures pratiques du secteur ?
(b) La sécurité des informations est-elle intégrée à l'ensemble du
cycle de vie de la conception d'un logiciel ?
(c) Les applications logicielles sont-elles conçues conformément à
la norme PCI DSS (par exemple, authentification et connexion
sécurisées) ?
(d) Les processus de conception de logiciel garantissent-ils ce qui
suit ?
6.3.1
Les comptes d’application personnalisés, ID d’utilisateur et
mots de passe sont-ils éliminés avant l’activation des
applications ou leur mise à la disposition des clients ?
Octobre 2010
Page 14
Question PCI DSS
6.3.2
6.4
Réponse :
Oui
Non
Spécial*
Tous les changements des codes d'application personnalisés
sont-ils révisés (par l'utilisation de processus manuels ou
automatiques) avant leur mise en production ou leur mise à la
disposition des clients afin d’identifier toute vulnérabilité de
codage éventuelle comme suit :
• Les changements de code sont-ils révisés par des
individus autres que l’auteur initial du code, qui
doivent être compétents en la matière et maîtriser les
pratiques de codage sécurisées ?
• La révision du code garantit-elle que le code est
conçu conformément aux directives de codage
sécurisé (voir la condition 6.5 de la norme PCI DSS) ?
• Les corrections appropriées sont-elles déployées
avant la publication ?
• Les résultats de la révision du code sont-ils passés en
revue et approuvés par les responsables avant la
publication ?
Remarque : cette condition s’applique à l'intégralité du code
personnalisé (aussi bien interne qu’orienté public), dans le
cadre du cycle de conception du système. Les révisions du
code peuvent être réalisées par le personnel interne
compétent ou par des tiers. Les applications Web font
également l'objet de contrôles supplémentaires si elles sont
orientées public afin de résoudre les menaces et les
vulnérabilités éventuelles après leur déploiement, comme
défini par la condition 6.6 de la norme PCI DSS.
Les processus et procédures de contrôle des modifications sont-ils
suivis pour tous les changements des composants du système de
manière à comprendre ce qui suit :
6.4.1
Les environnements de test/conception sont-ils distincts de
l’environnement de production, et existe-t-il un contrôle
d’accès pour garantir la séparation ?
6.4.2
Existe-t-il une distinction entre les missions des collaborateurs
affectés aux environnements de conception/test et celles du
personnel affecté à l'environnement de production ?
6.4.3
Les données de production (PAN actifs) ne sont-elles pas
utilisées à des fins de test ou de conception ?
6.4.4
Les données et les comptes de test sont-ils tous éliminés
avant que les systèmes de production ne deviennent actifs ?
6.4.5
(a) Les procédures de contrôle des modifications liées à
l'application des correctifs de sécurité et des modifications
logicielles sont-elles détaillées et stipulent-elles les
points 6.4.5.1 à 6.4.5.4 ci-dessous ?
(b) Les points suivants sont-ils exécutés pour toutes les
modifications :
6.4.5.1
L'impact est-il documenté ?
Octobre 2010
Page 15
Question PCI DSS
6.4.5.2
6.4.5.3
Réponse :
Oui
Non
Spécial*
Le changement détaillé est-il approuvé par les responsables
appropriés ?
(a) Un test de fonctionnalité est-il réalisé pour vérifier que le
changement ne compromet pas la sécurité du système ?
(b) Pour les changements de code personnalisé, les mises à
jour sont-elles testées du point de vue de la conformité à
la condition 6.5 de la norme PCI DSS avant leur mise en
production ?
6.4.5.4
6.5
Des procédures de suppression sont-elles préparées pour
chaque changement ?
(a) Les applications sont-elles conçues en fonction des directives
de codage sécurisé ?
(Par exemple, les guide OWASP [Open Web Application Security
Project], Top 25 SANS CWE, codage sécurisé CERY, etc.) ?
(b) Les concepteurs sont-ils expérimentés en techniques de
codage sécurisé ?
(c) La prévention des vulnérabilités de codage communes est-elle
couverte par les processus de conception de logiciel pour
garantir que les applications ne sont pas vulnérables au
minimum à ce qui suit :
Remarque : les vulnérabilités décrites aux points 6.5.1 à 6.5.9
faisaient partie des meilleures pratiques du secteur au moment de
la publication de cette version de la norme PCI DSS. Les meilleures
pratiques de gestion des vulnérabilités du secteur étant actualisées,
se reporter aux meilleures pratiques actuelles pour ces conditions.
6.5.1
Attaques par injection, notamment les injections de
commandes SQL ? (valider l'entrée pour vérifier que les
données utilisateur ne peuvent pas modifier le sens des
commandes et des requêtes, utiliser des requêtes
paramétrées, etc.).
Envisager également les attaques par injection OS, LDAP et
Xpath ainsi que les autres attaques par injection.
6.5.2
Saturation de la mémoire tampon ? (valider les limites de la
mémoire tampon et tronquer les chaînes d'entrée)
6.5.3
Stockage cryptographique non sécurisé ? (Prévenir les
défauts cryptographiques)
6.5.4
Communications non sécurisées ? (Crypter correctement
toutes les communications authentifiées et sensibles)
6.5.5
Traitement inapproprié des erreurs ? (Ne laisser filtrer aucune
information par le biais de messages d'erreur)
Octobre 2010
Page 16
Question PCI DSS
6.5.6
Réponse :
Oui
Non
Spécial*
Toutes les vulnérabilités à « haut risque » sont-elles
identifiées dans le processus d'identification de vulnérabilité
(définies par la condition 6.2 de la norme PCI DSS) ?
Remarque : cette condition est considérée comme une
meilleure pratique jusqu'au 30 juin 2012, après quoi ce sera
une obligation.
Dans le cas des applications Web et des interfaces d'application
(internes ou externes), les vulnérabilités supplémentaires suivantes
s'appliquent également :
6.6
6.5.7
Attaques XSS (Cross-Site Scripting) (Valider tous les
paramètres avant l'inclusion, utiliser un mécanisme
d'échappement sensible au contexte, etc.)
6.5.8
Contrôle d'accès inapproprié comme des références d'objet
directes non sécurisées, impossibilité de restreindre l'accès
URL, et survol de répertoire ? (Authentifier correctement les
utilisateurs et expurger l'entrée. Ne soumettre en aucun cas
les références à des objets internes aux utilisateurs)
6.5.9
Attaques CSRF (Cross-Site Request Forgery). (Ne pas se fier
aux éléments d'authentification et tokens automatiquement
soumis par les navigateurs)
Pour les applications Web orientées public, les nouvelles menaces
et vulnérabilités sont-elles traitées régulièrement et ces applications
sont-elles protégées contre les attaques connues à l'aide de l’une
des méthodes suivantes ?
Réviser les applications Web orientées public à l’aide d'outils
ou de méthodes d'évaluation de la sécurité et de la
vulnérabilité des applications automatiques ou manuels,
comme suit :
o au moins une fois par an ;
o après toute modification ;
o par une société spécialisée dans la sécurité des
applications ;
o toutes les vulnérabilités sont corrigées ;
o l’application est réévaluée après les corrections.
– ou –
Installer un pare-feu de couche application Web devant les
applications Web orientées public pour détecter et prévenir les
attaques basées sur le Web.
Remarque : « une organisation spécialisée dans la sécurité des
applications » peut être une autre société ou une entité interne,
l’essentiel étant que le personnel chargé de réaliser la vérification
soit spécialisé dans la sécurité des applications et puisse attester
de sa totale indépendance vis-à-vis de l’équipe de conception.
Octobre 2010
Page 17
Mise en œuvre de mesures de contrôle d’accès strictes
Condition 7 : Restreindre l'accès aux données des titulaires de carte aux seuls individus
qui doivent les connaître
Question PCI DSS
7.1
Réponse :
Oui
Non
Spécial*
L'accès aux composants du système et aux données des titulaires
de carte est-il restreint aux seuls individus qui doivent y accéder
pour mener à bien leur travail, comme suit :
7.1.1
Les droits d'accès pour les ID utilisateurs privilégiés sont-ils
restreints aux privilèges les plus faibles nécessaires pour la
réalisation du travail ?
7.1.2
Les privilèges sont-ils octroyés aux individus sur la base de
leur classification et de leur fonction professionnelles (cette
approche est également appelée « contrôle d'accès en
fonction du rôle » ou RBAC, Role-Based Access Control) ?
7.1.3
Une approbation détaillée par les responsables est-elle
exigée (par écrit ou par voie électronique) spécifiant les
privilèges requis ?
7.1.4
Les contrôles d’accès sont-ils déployés par le biais d’un
système de contrôle d’accès automatique ?
7.2
Un système de contrôle d’accès est-il en place pour les systèmes
comptant plusieurs utilisateurs, afin de restreindre l'accès aux seuls
utilisateurs qui doivent accéder aux données et est-il configuré pour
« refuser tous » les accès à moins qu'ils ne soient explicitement
autorisés, comme suit :
7.2.1
Des systèmes de contrôle d’accès sont-ils déployés sur tous
les composants du système ?
7.2.2
Les systèmes de contrôle d’accès sont-ils configurés pour
octroyer les privilèges aux individus en fonction de leur
classification et fonction professionnelles ?
7.2.3
Les systèmes de contrôle d’accès intègrent-ils un paramètre
par défaut « Refuser tout » ?
Remarque : sur certains systèmes de contrôle d’accès, le
paramètre « Autoriser tout » est configuré par défaut. Par
conséquent, l’accès est autorisé à tous, à moins qu'une règle
écrite ne précise explicitement le refus de l’accès.
Octobre 2010
Page 18
Condition 8 : Affecter un ID unique à chaque utilisateur d’ordinateur
Question PCI DSS
Réponse :
8.1
Tous les utilisateurs se voient-ils assigner un ID unique avant
d'être autorisés à accéder aux composants du système ou aux
données de titulaires de cartes ?
8.2
Outre l'assignation d'un ID unique, l'une ou plusieurs des
méthodes suivantes sont-elles employées pour authentifier tous
les utilisateurs ?
Quelque chose de connu du seul utilisateur, comme un mot
de passe ou une locution de passage.
Quelque chose de détenu par l'utilisateur, comme un
dispositif token ou une carte à puce.
Quelque chose concernant l'utilisateur, comme une mesure
biométrique.
L’authentification à deux facteurs est-elle intégrée pour l’accès à
distance (accès au niveau du réseau depuis l'extérieur du réseau)
des employés, des administrateurs et de tiers au réseau ?
(Par exemple, authentification à distance et service de
renseignements par téléphone [RADIUS] avec tokens ; système
de contrôle d'accès au contrôleur d'accès du terminal [TACACS]
avec tokens ; ou autres technologies permettant une
authentification à deux facteurs)
Remarque : l'authentification à deux facteurs requiert d'utiliser
deux des trois méthodes d'authentification (voir la condition 8.2
pour la description des méthodes d'authentification). L'utilisation à
deux reprises d'un facteur (par exemple, l'utilisation de deux mots
de passe distincts) ne constitue pas une authentification à deux
facteurs.
8.3
8.4
Oui
Non
Spécial*
(a) Tous les mots de passe sont-ils rendus illisibles pendant la
transmission et le stockage sur tous les composants du
système à l’aide d’une méthode de cryptographie robuste ?
(b) Pour les prestataires de services uniquement : Les mots de
passe des clients sont-ils cryptés ?
8.5
Des contrôles de gestion appropriée des mots de passe et de
l’authentification des utilisateurs sont-ils déployés pour les
utilisateurs non-consommateurs et les administrateurs sur tous les
composants du système comme suit :
8.5.1
Des compléments, suppressions et modifications des ID et
des informations utilisateur, et autres éléments identifiants
sont-ils contrôlés, de manière à n'appliquer les ID
utilisateurs qu'en fonction de leurs autorisations (notamment
avec les privilèges spécifiés) ?
8.5.2
L'identité de l'utilisateur est-elle vérifiée avant d'exécuter la
réinitialisation du mot de passe pour les demandes
d'utilisateur réalisée par des moyens indirects (par exemple,
téléphone, courriel ou Web) ?
Octobre 2010
Page 19
Question PCI DSS
Réponse :
8.5.3
Les mots de passe initiaux et de réinitialisation sont-ils
définis sur une valeur unique pour chaque utilisateur et
chaque utilisateur doit-il modifier son mot de passe
immédiatement après la première utilisation ?
8.5.4
L'accès des utilisateurs qui ne travaillent plus pour la société
est-il immédiatement désactivé ou révoqué ?
8.5.5
Les comptes utilisateurs inactifs depuis plus de 90 jours
sont-ils supprimés ou désactivés ?
8.5.6
(a) Les comptes utilisés par les fournisseurs pour un accès
à distance, la maintenance ou une assistance sont-ils
activés pendant la période nécessaire uniquement ?
Oui
Non
Spécial*
(b) Les comptes d'accès à distance des fournisseurs sont-ils
surveillés lorsqu'ils sont utilisés ?
8.5.7
Les politiques et les procédures sont-elles communiquées à
tous les utilisateurs qui ont accès aux données de titulaires
de cartes ?
8.5.8
Les comptes et mots de passe ou autres méthodes
d'authentification collectifs, partagés ou génériques sont-ils
interdits comme suit :
• les ID d’utilisateur et les comptes génériques sont
désactivés ou supprimés ;
• il n’existe pas d’ID d’utilisateur partagés pour les
activités d’administration du système et d’autres
fonctions stratégiques ;
• aucun ID d’utilisateur partagé ou générique n’est utilisé
pour l’administration d'aucun composant du système.
8.5.9
(a) Les mots de passe utilisateurs sont-ils changés au moins
tous les 90 jours ?
(b) Pour les prestataires de services uniquement : les mots
de passe utilisateur non consommateur doivent-ils être
changés régulièrement et les utilisateurs non clients se
voient-ils indiquer la fréquence et les circonstances
dans lesquelles les mots de passe doivent être
changés ?
8.5.10
(a) Les mots de passe doivent-ils comporter au moins sept
caractères ?
de passe utilisateur non consommateur doivent-ils
respecter des conditions de longueur minimum ?
8.5.11
(a) Les mots de passe doivent-ils comporter des caractères
alphanumériques ?
de passe utilisateur non consommateur doivent-ils
comporter des caractères alphanumériques ?
Octobre 2010
Page 20
Question PCI DSS
8.5.12
Réponse :
Oui
Non
Spécial*
(a) Un individu doit-il soumettre un nouveau mot de passe
différent des quatre derniers utilisés ?
(b) Pour les prestataires de services uniquement : les
nouveaux mots de passe utilisateur non consommateur
doivent-ils être différents des quatre derniers utilisés ?
8.5.13
(a) Les tentatives d’accès répétées sont-elles restreintes en
verrouillant l’ID utilisateur après six tentatives au
maximum ?
de passe utilisateur non consommateur sont-ils
temporairement verrouillés après plus de six tentatives
non valides ?
8.5.14
Une fois un compte utilisateur verrouillé, la durée de
verrouillage est-elle réglée sur 30 minutes au moins ou
jusqu’à ce que l’administrateur active l’ID utilisateur ?
8.5.15
Si une session reste inactive plus de 15 minutes, est-il
demandé à l'utilisateur de se ré-authentifier (par exemple,
en saisissant de nouveau son mot de passe) pour réactiver
le terminal ou la session ?
8.5.16
(a) Tous les accès aux bases de données contenant des
données de titulaires de cartes sont-ils authentifiés ?
(Cette condition concerne les accès des applications,
des administrateurs et de tous les autres utilisateurs)
(b) Tous les accès aux bases de données, toutes les
consultations et actions exécutées par les utilisateurs
dans celles-ci (par exemple, déplacement, copie,
suppression d’informations) s’effectuent-ils
exclusivement au moyen de méthodes programmées
(par exemple, par le biais de procédures stockées) ?
(c) L'accès direct des utilisateurs ou les requêtes aux bases
de données sont-ils restreints aux seuls administrateurs
de bases de données ?
(d) Les ID d'application avec accès à la base de données
peuvent-ils être utilisés par les applications seulement
(et non par des utilisateurs individuels ou autres
processus) ?
Octobre 2010
Page 21
Condition 9 : Restreindre l’accès physique aux données des titulaires de carte
Question PCI DSS
9.1
Réponse :
Oui
Non
Spécial*
Des contrôles d’accès aux installations appropriés sont-ils en
place pour restreindre et surveiller l’accès physique aux systèmes
installés dans l’environnement des données de titulaires de carte ?
9.1.1
(a) Des caméras vidéo et/ou d’autres mécanismes de
contrôle d’accès sont-ils utilisés pour surveiller l’accès
physique des individus aux zones sensibles ?
Remarque : par « zones sensibles », nous entendons
centre de données, salle de serveur ou zone abritant des
systèmes qui stockent des données de titulaires de cartes.
Ceci exclut les zones où ne sont installés que des terminaux
de point de vente, comme les zones de caisse dans un
magasin.
(b) Les caméras vidéo et/ou autres mécanismes de
contrôle d’accès sont-ils protégés contre la falsification
ou la désactivation ?
(c) Des données sont-elles recueillies à partir des caméras
vidéo et/ou mécanismes de contrôle d'accès puis
vérifiées et corrélées avec d'autres entrées, et ces
données sont-elles stockées pour au moins 3 mois, sauf
si la loi en décide autrement ?
9.2
9.1.2
L'accès physique aux prises réseau accessibles au public
est-il restreint (par exemple, les zones accessibles aux
visiteurs ne doivent pas comporter de prises réseau
activées à moins que l'accès réseau ne soit explicitement
autorisé) ?
Sinon, les visiteurs sont-ils accompagnés à tout moment
dans les zones comportant des prises réseau actives ?
9.1.3
L'accès physique aux points d'accès, passerelles,
périphériques portables, matériel réseau/communications et
lignes de télécommunication sans fil est-il restreint ?
Des procédures sont-elles élaborées pour distinguer facilement le
personnel du site des visiteurs, comme suit :
Dans le cadre de la condition 9, le terme « personnel du site »
désigne les employés à temps plein et à temps partiel, les
intérimaires ainsi que les sous-traitants et les consultants qui
« résident » sur le site de l'entité. Un « visiteur » est défini comme
un fournisseur, l’invité du personnel du site, le personnel de
service ou tout individu présent au sein des locaux pendant une
période courte, n'excédant généralement pas une journée.
(a) Les processus et les procédures pour l'assignation de badges
au personnel du site et aux visiteurs comprennent-ils ce qui
suit :
• la remise de nouveaux badges ;
• le changement des conditions d'accès ;
• la révocation des badges du personnel ne travaillant plus
sur le site et des badges visiteurs périmés.
Octobre 2010
Page 22
Question PCI DSS
Réponse :
Oui
Non
Spécial*
(b) L'accès au système de badges est-il restreint au seul
personnel autorisé ?
(c) Les badges identifient-ils clairement les visiteurs et est-il facile
de distinguer ces derniers du personnel du site ?
9.3
Tous les visiteurs sont-ils traités de la manière suivante :
9.3.1
Une autorisation d’accès leur est-elle donnée avant de
pénétrer dans les zones où sont traitées et conservées les
données de titulaires de cartes ?
9.3.2
Reçoivent-ils un dispositif physique (par exemple, badge ou
dispositif d’accès) qui identifie bien les visiteurs comme
ne faisant pas partie du personnel ?
(b) Les badges visiteurs expirent-ils ?
9.1.3
9.4
Est-il demandé aux visiteurs de rendre le dispositif physique
avant de quitter les locaux ou à la date d’expiration ?
(a) Un registre des visites est-il utilisé pour consigner l’accès
physique aux locaux ainsi qu’aux salles informatiques et aux
centres de données où sont stockées ou transmises les
(b) Ce registre comporte-t-il le nom du visiteur, l’entreprise qu’il
représente et le personnel du site qui autorise son accès
physique, et ce document est-il conservé pendant au moins
trois mois ?
9.5
(a) Les sauvegardes sur support sont-elles rangées en lieu sûr, de
préférence hors de l’installation, par exemple sur un autre site
ou un site de secours, ou encore un site de stockage
commercial ?
(b) La sécurité du site est-elle inspectée au moins une fois par
an ?
9.6
Tous les supports sont-ils physiquement sécurisés (entre autres,
ordinateurs, supports électroniques amovibles, réseaux, reçus et
rapports sur papier, et fax) ?
Dans le cadre de la condition 9, « support » se rapporte à tout
support papier ou électronique contenant des données de
titulaires de cartes.
9.7
(a) Un contrôle strict s'applique-t-il à la distribution interne ou
externe d'un type de support ?
(b) Les contrôles comprennent-ils les éléments suivants :
9.7.1
Les supports sont-ils classés afin de déterminer la
sensibilité des données qu'ils contiennent ?
9.7.2
Les supports sont-ils envoyés par coursier ou toute autre
méthode d’expédition qui peut faire l’objet d’un suivi ?
Octobre 2010
Page 23
Question PCI DSS
Réponse :
9.8
Les registres sont-ils gérés pour suivre tous les supports déplacés
d'une zone sécurisée et une approbation des responsables estelle obtenue avant le déplacement du support (notamment lorsque
le support est distribué aux individus) ?
9.9
Un contrôle strict est-il réalisé sur le stockage et l’accessibilité des
supports ?
9.9.1
9.10
Oui
Non
Spécial*
Les registres d'inventaires de tous les supports sont-ils
correctement gérés et un inventaire périodique des supports
est-il conduit au moins une fois par an ?
Tous les supports sont-ils détruits lorsqu'ils ne sont plus utiles
pour des raisons professionnelles ou légales ?
La destruction est-elle réalisée comme suit :
9.10.1
Les documents papier sont-ils déchiquetés, brûlés ou
réduits en pâte de sorte que les données de titulaires de
carte ne puissent pas être reconstituées ?
(b) Les contenants qui stockent des informations à détruire
sont-ils sécurisés pour prévenir l'accès à leur contenu ?
(Par exemple, un contenant de « documents à
déchiqueter » dispose d'une serrure pour prévenir
l'accès à son contenu)
9.10.2
Les données de titulaires de cartes sur support électronique
sont-elles rendues irrécupérables à l’aide d’un programme
de nettoyage sécurisé, conformément aux normes du
secteur en matière d’élimination sécurisée des informations,
ou à l’aide de tout autre procédé de destruction physique
des supports (par exemple, par démagnétisation), de sorte
que les données des titulaires de carte ne puissent être
reconstituées ?
Octobre 2010
Page 24
Surveillance et test réguliers des réseaux
Condition 10 : Effectuer le suivi et surveiller tous les accès aux ressources réseau et aux
Question PCI DSS
Réponse :
10.1
Un processus est-il en place pour associer chaque accès aux
composants du système (en particulier les accès avec des droits
administrateur, tels que root) à un utilisateur individuel ?
10.2
Des journaux d'audit automatisés sont-ils en place pour tous les
composants du système afin de reconstituer les événements
suivants :
10.3
10.4
10.2.1
Tous les accès des utilisateurs aux données des titulaires de
carte.
10.2.2
Toutes les actions exécutées par des utilisateurs ayant des
droits root ou administrateur.
10.2.3
Les accès à tous les journaux d'audit.
10.2.4
Les tentatives d’accès logique non valides.
10.2.5
L'utilisation des mécanismes d’identification et
d’authentification.
10.2.6
L'initialisation des registres d'audit.
10.2.7
La création et l'élimination d’objets au niveau système.
Oui
Non
Spécial*
Les journaux d’audit comprennent-ils au moins les entrées
suivantes pour chaque événement :
10.3.1
Identification des utilisateurs
10.3.2
Type d’événement
10.3.3
Date et heure
10.3.4
Indication de succès ou d’échec
10.3.5
Origine de l’événement
10.3.6
Identité ou nom des données, du composant du système ou
de la ressource affectés
(a) Toutes les horloges et heures du système essentiel sont-elles
synchronisées par l'utilisation d'une technologie de
synchronisation temporelle, et cette technologie est-elle
maintenue à jour ?
Remarque : le protocole Network Time Protocol (NTP) est un
exemple de technologie de synchronisation temporelle.
(b) Les contrôles suivants sont-ils en place pour l'acquisition, la
distribution, et le stockage de l'heure :
Octobre 2010
Page 25
Question PCI DSS
10.4.1
Réponse :
Oui
Non
Spécial*
(a) Les serveurs temporels centraux désignés reçoivent-ils
seuls des signaux de sources externes, et tous les
systèmes essentiels ont-ils une heure correcte et
cohérente en fonction de l'échelle de temps TAI (Temps
atomique international) ou UTC ?
(b) Les serveurs temporels centraux désignés se consultentils mutuellement pour maintenir l'exactitude de l'heure et
les autres serveurs internes reçoivent-ils l'heure
uniquement de ces serveurs temporels centraux ?
10.4.2
Les données temporelles sont-elles protégées comme suit :
(a) L'accès aux données temporelles est-il restreint au seul
personnel ayant un besoin professionnel d'accéder à de
telles données ?
(b) Les changements des réglages de l'heure sur les
systèmes essentiels sont-ils connectés, surveillés et
révisés ?
10.4.3
10.5
Les paramètres temporels sont-ils reçus de sources
temporelles spécifiques reconnues par le secteur ?
(Cela permet de prévenir le changement de l'heure par un
individu malveillant) Il est également possible de crypter ces
mises à jour avec une clé symétrique, et de créer des listes
de contrôle d’accès qui indiquent les adresses IP des
machines clientes qui recevront les mises à jour temporelles
(afin d'empêcher toute utilisation non autorisée des serveurs
temporels internes).
Les journaux d'audit sont-ils sécurisés de manière à ne pas pouvoir
être altérés, comme suit :
10.5.1
L’affichage des journaux d’audit est-il restreint aux
utilisateurs qui en ont besoin pour mener à bien leur travail ?
10.5.2
Les fichiers journaux d’audit existants sont-ils protégés
contre toute modification non autorisée par des mécanismes
de contrôle d’accès, leur isolation physique et/ou l’isolation
du réseau ?
10.5.3
Les fichiers journaux d’audit sont-ils sauvegardés rapidement
sur un serveur centralisé réservé à la journalisation ou sur
des supports difficiles à altérer ?
10.5.4
Les registres des technologies orientées vers l’extérieur (par
exemple, sans fil, pare-feu, DNS, messagerie) sont-ils vidés
ou copiés sur un serveur de journalisation ou un support
centralisés sécurisés du réseau interne ?
10.5.5
Un logiciel de contrôle de l’intégrité des fichiers ou de
détection des modifications est-il utilisé sur les registres pour
s’assurer que les données qu'ils contiennent ne peuvent pas
être modifiées sans entraîner le déclenchement d’une alerte
(alors que l’ajout de nouvelles données ne doit pas entraîner
d’alerte) ?
Octobre 2010
Page 26
Question PCI DSS
Réponse :
10.6
Les registres pour tous les composants du système sont-ils révisés
au moins une fois par jour, avec une obligation de suivi des
anomalies ?
La révision des registres doit comprendre les serveurs exécutant
des fonctions de sécurité, tels que les serveurs IDS (système de
détection d'intrusion) et AAA (Authentication, Authorization, and
Accounting) (par exemple, RADIUS).
Remarque : les outils de journalisation, d’analyse et d’alerte
peuvent être utilisés conformément à la condition 10.6.
10.7
(a) Des politiques et procédures de conservation des registres
d'audit sont-elles en place et requièrent-elles que l'historique
des journaux d'audit soit conservé au moins un an ?
Oui
Non
Spécial*
(b) Les registres d’audit sont-ils disponibles pendant un an au
moins et des processus sont-ils en place pour restaurer
immédiatement les registres des trois derniers mois au moins,
pour analyse ?
Condition 11 : Tester régulièrement les processus et les systèmes de sécurité
Question PCI DSS
11.1
Réponse :
Oui
Non
Spécial*
(a) Un processus documenté est-il déployé pour détecter et
identifier les points d'accès sans fil, tous les trimestres ?
Remarque : les analyses de réseau sans fil, les inspections
logiques/physiques des composants du système et de
l'infrastructure, le contrôle d'accès réseau (NAC) ou les systèmes
de détection et/ou de prévention d’intrusions sans fil sont
quelques exemples de méthodes pouvant être utilisées pour ce
processus.
Quelle que soit la méthode utilisée, elle doit être suffisante pour
détecter et identifier tous les périphériques non autorisés.
(b) La méthodologie détecte-t-elle et identifie-t-elle les points
d'accès sans fil non autorisés, notamment au moins ce qui
suit :
•
des cartes WLAN insérées dans les composants du
système ;
•
des périphériques sans fil portatifs connectés aux
composants du système (par exemple, par USB, etc.) ;
•
des périphériques sans fil branchés sur un port réseau ou
à un périphérique réseau.
(c) Le processus d'identification des points d'accès sans fil non
autorisés est-il exécuté au moins chaque trimestre pour tous
les composants du système et toutes les installations.
(d) En cas d'utilisation d'une surveillance automatisée (par
exemple systèmes de détection et/ou de prévention
d’intrusions sans fil, NAC, etc.), la surveillance est-elle
configurée pour déclencher des alertes pour le personnel ?
Octobre 2010
Page 27
Question PCI DSS
Réponse :
Oui
Non
Spécial*
(e) Le plan de réponse aux incidents (condition 12.9) prévoit-il une
réaction en cas de détection de périphériques sans fil non
autorisés ?
11.2
Des analyses des vulnérabilités potentielles des réseaux internes
et externes sont-elles réalisées au moins une fois par trimestre et
après un changement significatif du réseau (par exemple,
l'installation de nouveaux composants du système, la modification
de la topologie du réseau ou des règles des pare-feu, la mise à
niveau de produits) ?
Remarque : il n'est pas obligatoire que quatre analyses
trimestrielles aient été réalisées avec succès pour la vérification
de conformité à la norme PCI DSS initiale si 1) le résultat de la
dernière analyse était réussi, 2) l’entité a détaillé les politiques et
les procédures exigeant l’exécution d’analyses trimestrielles, et 3)
toutes les vulnérabilités relevées dans les résultats ont été
corrigées, comme indiqué lors de la réexécution de l'analyse.
Pendant les années qui suivent la vérification PCI DSS initiale,
quatre analyses trimestrielles réussies doivent avoir été réalisées.
11.2.1
(a) Des analyses trimestrielles de vulnérabilité interne sontelles réalisées ?
(b) Le processus d'analyse comprend-il les nouvelles
analyses jusqu'à obtenir un résultat satisfaisant ou
jusqu'à ce que toutes les vulnérabilités à « haut
risque », définies à la condition 6.2 de la norme PCI
DSS, aient été résolues ?
(c) Les analyses sont-elles effectuées par une ou plusieurs
ressources internes ou un tiers externe qualifié et, le cas
échéant, le testeur appartient-il à une organisation
indépendante (il ne doit pas obligatoirement être un
QSA ou un ASV) ?
11.2.2
(a) Des analyses trimestrielles de vulnérabilité externe sontelles réalisées ?
(b) Les résultats des analyses trimestrielles satisfont-ils aux
conditions du guide de programme ASV (par exemple,
pas de vulnérabilité supérieure à la note 4.0 du CVSS et
aucune défaillance automatique) ?
c) Les analyses trimestrielles de vulnérabilité externe sontelles effectuées par un prestataire de services d’analyse
agréé (ASV) par le PCI SSC (conseil des normes de
sécurité du secteur des cartes de paiement) ?
Octobre 2010
Page 28
Question PCI DSS
11.2.3
Réponse :
Oui
Non
Spécial*
(a) Des analyses internes et externes sont-elles réalisées
après un changement significatif (par exemple,
l'installation de nouveaux composants du système, la
modification de la topologie du réseau ou des règles des
pare-feu, la mise à niveau de produits) ?
Remarque : les analyses réalisées après la modification
des réseaux peuvent être effectuées par le personnel
interne.
(b) Le processus d'analyse comprend-il de nouvelles
analyses jusqu'à ce que :
•
aucune vulnérabilité supérieure à la note 4.0 du
CVSS ne soit détectée pour les analyses externes ;
•
un résultat satisfaisant soit obtenu ou jusqu'à ce que
toutes les vulnérabilités à « haut risque », définies
dans la condition 6.2 de la norme PCI DSS, aient
été résolues, pour les analyses internes.
(c) Les analyses sont-elles effectuées par une ou plusieurs
ressources internes ou un tiers externe qualifié et, le cas
échéant, le testeur appartient-il à une organisation
indépendante (il ne doit pas obligatoirement être un
QSA ou un ASV) ?
11.3
(a) Des tests de pénétration externe et interne sont-ils réalisés au
moins une fois par an et après toute mise à niveau
significative de l’infrastructure ou des applications (par
exemple, mise à niveau du système d’exploitation ou ajout
d’un sous-réseau ou d’un serveur Web dans
l’environnement) ?
(b) Les vulnérabilités relevées et exploitables ont-elles été
corrigées et les tests ont-ils été ré-exécutés ?
(c) Les tests ont-ils été effectués par une ressource interne ou un
tiers externe qualifié et, le cas échéant, le testeur appartient-il
à une organisation indépendante (il ne doit pas
obligatoirement être un QSA ou un ASV) ?
Ces tests de pénétration comprennent-ils ce qui suit :
11.4
11.3.1
Tests de pénétration de la couche Réseau
Remarque : les tests doivent comprendre les composants
qui prennent en charge les fonctions réseau, tels que les
systèmes d’exploitation.
11.3.2
Tests de pénétration de la couche application
Remarque : les tests doivent comprendre au minimum les
vulnérabilités répertoriées dans la condition 6.5.
(a) Des systèmes de détection d’intrusions et/ou des systèmes de
prévention d’intrusions sont-ils utilisés pour contrôler
l'intégralité du trafic, ainsi que les points critiques, dans le
périmètre de l’environnement des données de titulaires de
cartes ?
Octobre 2010
Page 29
Question PCI DSS
Réponse :
Oui
Non
Spécial*
(b) Les systèmes de détection et/ou de prévention d’intrusions
sont-ils configurés pour signaler au personnel tous les
soupçons portant sur des altérations potentielles ?
(c) Tous les moteurs de détection et de prévention des intrusions,
les références et les signatures sont-ils tenus à jour ?
11.5
(a) Des outils de contrôle de l'intégrité des fichiers sont-ils
déployés au sein de l'environnement des données des
Exemples de fichiers devant être contrôlés :
• exécutables du système ;
• exécutables des applications ;
• fichiers de configuration et de paramètres ;
• fichiers d'historique, d’archive, de registres et d’audit
stockés à un emplacement centralisé.
(b) Les outils sont-ils configurés pour alerter le personnel de toute
modification non autorisée des fichiers de configuration ou des
fichiers de contenu, et les outils effectuent-ils des
comparaisons entre les fichiers stratégiques au moins une fois
par semaine ?
Remarque : pour le contrôle de l’intégrité des fichiers, les fichiers
stratégiques sont généralement ceux qui ne changent pas
régulièrement, mais dont la modification pourrait indiquer une
altération du système ou son exposition à des risques. Les
produits de contrôle de l’intégrité des fichiers sont généralement
préconfigurés avec les fichiers stratégiques pour le système
d’exploitation associé. D’autres fichiers stratégiques, tels que ceux
associés aux applications personnalisées, doivent être évalués et
définis par l’entité (c’est-à-dire le commerçant ou le prestataire de
services).
Octobre 2010
Page 30
Gestion d’une politique de sécurité des informations
Condition 12 : Gérer une politique de sécurité des informations pour l'ensemble du
personnel
Question PCI DSS
12.1
Réponse :
Oui
Non
Spécial*
Une politique de sécurité est-elle établie, publiée, gérée et diffusée
à tout le personnel compétent ?
Dans le cadre de la condition 12, le terme « personnel » désigne
les employés à temps plein et à temps partiel, les intérimaires ainsi
que les sous-traitants et les consultants qui « résident » sur le site
de l'entité ou ont accès d'une manière ou d'une autre à
l'environnement des données des titulaires de carte de la société.
12.1.1
La politique satisfait-elle à toutes les conditions de la norme
PCI DSS ?
12.1.2
(a) Un processus annuel d'évaluation des risques qui identifie
les menaces et les vulnérabilités est-il documenté, et
débouche-t-il sur une évaluation formelle des risques ?
(les directives OCTAVE, ISO 27005 and NIST SP 800-30
sont des exemples de méthodologies d'évaluation du risque)
(b) Le processus d'évaluation des risques est-il effectué au
moins une fois par an ?
12.1.3
La politique de sécurité des informations est-elle passée en
revue au moins une fois par an et est-elle mise à jour le cas
échéant pour tenir compte des modifications apportées aux
objectifs de l’entreprise ou à l’environnement de risque ?
12.2
Des procédures de sécurité opérationnelles quotidiennes
conformes aux conditions de cette spécification (par exemple, des
procédures de gestion des comptes d’utilisateur et des procédures
d’examen des registres) sont-elles élaborées et comprennent-elles
des procédures administratives et techniques pour chacune des
conditions ?
12.3
Des politiques d’utilisation des technologies stratégiques (par
exemple, technologies d’accès à distance, technologies sans fil,
supports électroniques amovibles, ordinateurs portables, assistants
numériques personnels [PDA], utilisation du courrier électronique et
d’Internet) sont-elles élaborées pour définir l'usage approprié de
ces technologies, et requièrent-elles ce qui suit :
12.3.1
Approbation explicite par les parties autorisées de l'usage
des technologies
12.3.2
Authentification de l'utilisation des technologies
12.3.3
Liste de tous les périphériques et employés disposant d'un
accès
12.3.4
Indication sur les périphériques du nom de leur propriétaire,
de ses coordonnées et de leur usage
12.3.5
Usages acceptables des technologies
Octobre 2010
Page 31
Question PCI DSS
Réponse :
12.3.6
Emplacements acceptables des technologies sur le réseau
12.3.7
Liste des produits approuvés par la société
12.3.8
Déconnexion automatique des sessions des technologies
d’accès à distance après une période d'inactivité spécifique
12.3.9
Activation des technologies d’accès à distance pour les
fournisseurs et les partenaires commerciaux, uniquement
lorsque cela est nécessaire, avec désactivation immédiate
après usage
12.3.10
(a) Lors de l’accès aux données de titulaires de cartes au
moyen de technologies d’accès à distance, interdire la
copie, le déplacement et le stockage de données de
titulaires de cartes sur des disques durs locaux et des
supports électroniques amovibles, sauf autorisation
expresse pour des besoins professionnels.
Oui
Non
Spécial*
(b) Pour le personnel dûment autorisé, vérifier que les
politiques d'utilisation exigent la protection des données
des titulaires de carte conformément aux conditions de
la norme PCI DSS.
12.4
La politique et les procédures de sécurité définissent-elles
clairement les responsabilités de tout le personnel en la matière ?
12.5
La responsabilité de la sécurité des informations est-elle
formellement assignée à un chef de la sécurité ou tout autre
responsable compétent ?
Les responsabilités suivantes de gestion de la sécurité des
informations sont-elles assignées à un individu ou à une équipe :
12.6
12.5.1
Définir, renseigner et diffuser les politiques et les procédures
de sécurité.
12.5.2
Contrôler et analyser les informations et les alertes de
sécurité, et les diffuser au personnel compétent.
12.5.3
Définir, renseigner et diffuser les procédures de remontée et
de réponse aux incidents liés à la sécurité pour garantir une
gestion rapide et efficace de toutes les situations.
12.5.4
Administrer les comptes d’utilisateur, notamment l’ajout, la
suppression et la modification de comptes.
12.5.5
Surveiller et contrôler tous les accès aux données.
(a) Un programme formel de sensibilisation à la sécurité est-il en
place pour sensibiliser les employés à l'importance de la
sécurité des données de titulaires de cartes ?
(b) Les procédures du programme de sensibilisation à la sécurité
comprennent-elles ce qui suit :
Octobre 2010
Page 32
Question PCI DSS
12.6.1
Réponse :
Oui
Non
Spécial*
(a) Le programme de sensibilisation à la sécurité comprend-il
plusieurs méthodes de sensibilisation et de formation du
personnel (par exemple, affiches, lettres, mémos,
formations sur le Web, réunions et promotions) ?
Remarque : les méthodes varient selon les postes occupés
et le niveau d'accès du personnel aux données des titulaires
de carte.
(b) Le personnel est-il formé au moment du recrutement et
au moins une fois par an ?
12.6.2
Est-il exigé du personnel de reconnaître au moins une fois
par an avoir lu et compris les procédures et la politique de
sécurité ?
12.7
Les antécédents des employés potentiels (voir la définition du
terme « employé » au point 9.2 ci-dessus) sont-ils contrôlés avant
leur recrutement afin de réduire les risques d'attaques par des
sources internes ? (Ces contrôles devraient inclure, par exemple,
les antécédents professionnels, le casier judiciaire, les
renseignements de solvabilité et la vérification des références)
Remarque : pour le personnel dont l'embauche potentielle
concerne des postes tels que celui de caissier dans un magasin,
qui n’a accès qu’à un numéro de carte à la fois à l'occasion du
traitement d'une transaction, cette condition n'est qu'une
recommandation.
12.8
Si les données de titulaires de cartes sont partagées avec des
prestataires de services, des politiques et procédures sont-elles en
place et maintenues pour gérer les prestataires de services comme
suit :
12.9
12.8.1
Une liste des prestataires de services est-elle tenue ?
12.8.2
Fait-on signer un accord écrit aux prestataires de services,
par lequel ils se reconnaissent responsables de la sécurité
des données de titulaires de cartes en leur possession ?
12.8.3
Existe-t-il un processus de sélection des prestataires de
services, comprenant notamment des contrôles préalables à
l'engagement ?
12.8.4
Existe-t-il un programme qui contrôle la conformité des
prestataires de services à la norme PCI DSS au moins une
fois par an ?
Un plan de réponse aux incidents a-t-il été mis en place afin de
répondre immédiatement à une faille du système, comme suit :
12.9.1
(a) Un plan de réponse aux incidents a-t-il été créé pour être
implémenté en cas d'intrusion dans le système ?
(b) Le plan répond-il au minimum aux éléments suivants :

rôles, responsabilités et stratégies de communication
et de contact en cas d’incident, notamment notification
des marques de cartes de paiement, au minimum ;
Octobre 2010
Page 33
Question PCI DSS
Réponse :

procédures de réponse aux incidents spécifiques ;

procédures de continuité et de reprise des affaires ;

processus de sauvegarde des données ;

analyse des conditions légales en matière de
signalement des incidents ;

couverture et réponses de tous les composants
stratégiques du système ;

référence ou inclusion des procédures de réponse aux
incidents des marques de cartes de paiement.
12.9.2
Le plan est-il testé au moins une fois par an ?
12.9.3
Des membres spécifiques du personnel sont-ils désignés
pour répondre aux alertes 24 heures sur 24 et sept jours sur
sept ?
12.9.4
Une formation appropriée est-elle fournie au personnel
chargé de la réponse aux violations de la sécurité ?
12.9.5
Des alertes des systèmes de détection et de prévention des
intrusions, et de contrôle de l’intégrité des fichiers sont-elles
comprises dans le plan de réponse aux incidents ?
12.9.6
Un processus est-il conçu et déployé afin de modifier et
développer le plan de réponse aux incidents en fonction des
leçons apprises, et en tenant compte de l'évolution du
secteur ?
Oui
Non
Spécial*
Octobre 2010
Page 34
Annexe A :
Autres conditions de la norme PCI DSS
s’appliquant aux prestataires de services
d’hébergement partagé
Condition A.1 : Les prestataires de services d’hébergement partagé doivent protéger
l’environnement des données de titulaires de cartes
Question PCI DSS
A.1
Réponse :
Oui
Non
Spécial*
Les données et l’environnement hébergés de chaque entité
(c’est-à-dire le commerçant, le prestataire de services ou toute
autre entité), sont-ils protégés conformément aux
conditions A.1.1 à A.1.4 comme suit :
Un prestataire de services d’hébergement doit satisfaire à ces
conditions ainsi qu’aux conditions de toutes les autres rubriques
pertinentes de la norme PCI DSS.
Remarque : même si un prestataire de services d’hébergement
peut satisfaire à ces conditions, la conformité de l'entité qui a
recours au prestataire de services d’hébergement n'est pas
garantie. Chaque entité doit se conformer à la norme PCI DSS et
doit valider cette conformité comme applicable.
A.1.1
A.1.2
Chaque entité applique-t-elle les processus qui ont accès
uniquement à l'environnement des données des titulaires
de carte qui la concerne, et ces processus d'application
sont-ils exécutés en utilisant l'ID unique de l'entité?
Par exemple :
•
aucune entité sur le système ne peut utiliser un ID
d’utilisateur partagé sur le serveur Web.
•
Tous les scripts CGI utilisés par une entité doivent
être créés et exécutés sous l’ID d’utilisateur
unique de l’entité.
L'accès et les privilèges de chaque entité sont-ils limités à
son propre environnement de données des titulaires de
carte comme suit :
(a) L'ID d’utilisateur de processus d’application n’est-il pas
un utilisateur avec des privilèges (root/admin) ?
(b) Chaque entité a-t-elle des autorisations de lecture,
d’écriture ou d’exécution uniquement sur les fichiers et
les dossiers qui lui appartiennent ou sur les fichiers
système nécessaires (restreints au moyen
d'autorisations sur le systèmes de fichiers, de listes de
contrôle d’accès, chroot, jailshell, etc.) ?
Important : les fichiers d'une entité ne peuvent pas être
partagés par groupe.
(a) Les utilisateurs d'une entité n’ont-ils pas un accès en
écriture aux fichiers binaires d’un système partagé ?
SAQ D PCI DSS, v2.0, Questionnaire d'auto-évaluation, annexe A
Octobre 2010
Page 35
Question PCI DSS
Réponse :
Oui
Non
Spécial*
(d) L’affichage des entrées des registres est-il restreint à
l’entité propriétaire de ces derniers ?
(e) Des restrictions sont-elles déployées pour l'utilisation
de ces ressources du système ?
• Espace disque
• Bande passante
• Mémoire
• Processeur
Cela garantit que chaque entité ne puisse pas monopoliser
des ressources serveur en vue d'exploiter des
vulnérabilités (notamment, erreur, concurrence critique et
conditions de reprise entraînant, par exemple, la saturation
de la mémoire tampon).
A.1.3
A.1.4
La journalisation et les journaux d'audit sont-ils activés,
uniques à l’environnement des données de titulaires de
carte de chaque entité et conformes à la condition 10 de la
norme PCI DSS ?
La journalisation est-elle activée comme suit pour chaque
environnement de commerçant ou de prestataire de
services :
•
les registres sont activés pour les applications
courantes de tiers ;
•
les registres sont activés par défaut ;
•
les registres peuvent être consultés par l'entité à
laquelle ils appartiennent ;
•
les emplacements des registres sont clairement
communiqués à l'entité propriétaire.
Les processus et procédures écrites sont-ils activés pour
permettre une enquête légale rapide en cas d'incident
dans l’environnement d’un commerçant ou d’un prestataire
de services hébergé ?
SAQ D PCI DSS, v2.0, Questionnaire d'auto-évaluation, annexe A
Octobre 2010
Page 36
Annexe B :
Contrôles compensatoires
Des contrôles compensatoires peuvent être envisagés lorsqu'une entité ne peut pas se conformer aux
conditions PCI DSS telles qu’elles sont stipulées, en raison de contraintes commerciales documentées
ou de contraintes techniques légitimes, mais qu'elle a parallèlement suffisamment atténué les risques
associés par la mise en œuvre d'autres contrôles, appelés « contrôles compensatoires ».
Les contrôles compensatoires doivent satisfaire aux critères suivants :
1. Respecter l’intention et la rigueur de la condition initiale de la norme PCI DSS.
2. Fournir une protection similaire à celle de la condition initiale de la norme PCI DSS, de sorte que le
contrôle compensatoire compense suffisamment le risque prévenu par la condition initiale (Pour plus
d'informations sur chaque condition PCI DSS, voir Navigation dans la norme PCI DSS).
3. Aller au-delà des autres conditions PCI DSS (Les contrôles compensatoires ne consistent pas
simplement en la conformité à d’autres conditions PCI DSS).
Lors de l'évaluation de la portée des contrôles compensatoires, considérer les points suivants :
Remarque : les points a) à c) ci-dessous sont cités à titre d'exemple seulement. L'évaluateur
qui effectue l'examen de la norme PCI DSS doit déterminer et valider la suffisance de tous les
contrôles compensatoires. L'efficacité d’un contrôle compensatoire dépend des
caractéristiques spécifiques de l’environnement dans lequel il est mis en œuvre, des
contrôles de sécurité associés et de la configuration du contrôle proprement dit. Les sociétés
doivent avoir conscience qu’un contrôle compensatoire particulier ne sera pas efficace dans
tous les environnements.
a) Les conditions existantes de la norme PCI DSS NE PEUVENT PAS être considérées comme des
contrôles compensatoires si elles sont déjà exigées pour l'élément examiné. Par exemple, les
mots de passe pour l’accès administrateur non-console doivent être transmis sous forme cryptée
afin de limiter les risques d'interception des mots de passe administrateur en texte clair. Une
entité ne peut pas utiliser d'autres conditions de mot de passe de la norme PCI DSS (blocage
des intrus, mots de passe complexes, etc.) pour compenser l'absence de mots de passe cryptés,
puisque celles-ci ne limitent pas les risques d'interception des mots de passe en texte clair. Par
ailleurs, les autres contrôles de mots de passe sont déjà exigés par la norme PCI DSS pour
l’élément examiné (à savoir les mots de passe).
b) Les conditions existantes de la norme PCI DSS PEUVENT être considérées comme des
contrôles compensatoires si elles sont exigées dans un autre domaine, mais pas pour l'élément
examiné. Par exemple, l’authentification à deux facteurs est exigée par la norme PCI DSS pour
l’accès à distance. L’authentification à deux facteurs à partir du réseau interne peut aussi être
considérée comme un contrôle compensatoire de l’accès administrateur non-console lorsque la
transmission des mots de passe cryptés ne peut pas être prise en charge. L’authentification à
deux facteurs peut être un contrôle compensatoire acceptable dans les conditions suivantes : (1)
elle satisfait l’intention de la condition initiale en résolvant les risques d’interception des mots de
passe administrateur en texte clair, et (2) elle est correctement configurée et elle est déployé
dans un environnement sécurisé.
c) Les conditions existantes de la norme PCI DSS peuvent être associées à de nouveaux contrôles
et constituer alors un contrôle compensatoire. Par exemple, si une société n'est pas en mesure
de rendre les données de titulaires de cartes illisibles conformément à la condition 3.4 (par
exemple, par cryptage), un contrôle compensatoire pourrait consister en un dispositif ou un
ensemble de dispositifs, d'applications et de contrôles qui assurent : (1) la segmentation du
réseau interne ; (2) le filtrage des adresses IP ou MAC ; et (3) l’authentification à deux facteurs à
partir du réseau interne.
4. Correspondre aux risques supplémentaires qu'implique la non conformité à la condition de la norme
PCI DSS.
SAQ D PCI DSS, v2.0, Annexe B : Contrôles compensatoires
Octobre 2010
Page 37
L’évaluateur doit évaluer soigneusement les contrôles compensatoires pendant chaque évaluation
annuelle de la norme PCI DSS afin de confirmer que chaque contrôle compensatoire couvre de manière
appropriée le risque ciblé par la condition initiale de la norme PCI DSS, conformément aux points 1 à 4
présentés ci-dessus. Pour maintenir la conformité, des processus et des contrôles doivent être en place
pour garantir que les contrôles compensatoires restent efficaces après l'évaluation.
SAQ D PCI DSS, v2.0, Annexe B : Contrôles compensatoires
Octobre 2010
Page 38
Annexe C :
Fiche de contrôles compensatoires
Se référer à cette fiche pour définir des contrôles compensatoires pour toute condition où la case « Oui »
a été cochée et où des contrôles compensatoires ont été mentionnés dans la colonne « Spécial ».
Remarque : seules les sociétés qui ont procédé à une analyse des risques et ont des contraintes
commerciales documentées ou des contraintes technologiques légitimes peuvent envisager l’utilisation
de contrôles compensatoires pour se mettre en conformité.
Numéro et définition des conditions :
Informations requises
1. Contraintes
Répertorier les contraintes qui
empêchent la conformité à la condition
initiale.
2. Objectif
Définir l’objectif du contrôle initial ;
identifier l’objectif satisfait par le
contrôle compensatoire.
3. Risque identifié
Identifier tous les risques
supplémentaires qu’induit l'absence du
contrôle initial.
4. Définition des
contrôles
compensatoires
Définir les contrôles compensatoires et
expliquer comment ils satisfont les
objectifs du contrôle initial et résolvent
les risques supplémentaires éventuels.
5. Validation des
contrôles
compensatoires
Définir comment les contrôles
compensatoires ont été validés et
testés.
6. Gestion
Définir les processus et les contrôles en
place pour la gestion des contrôles
compensatoires.
SAQ D PCI DSS, v2.0, Annexe C : Fiche de contrôles compensatoires
Explication
Octobre 2010
Page 39
Fiche de contrôles compensatoires – Exemple complété
Se référer à cette fiche pour définir des contrôles compensatoires pour toute condition où la case « Oui »
a été cochée et où des contrôles compensatoires ont été mentionnés dans la colonne « Spécial ».
Numéro de condition : 8.1 –Tous les utilisateurs sont-ils identifiés avec un nom d'utilisateur unique
avant d'être autorisés à accéder aux composants du système ou aux données de titulaires de cartes ?
Informations requises
Explication
1. Contraintes
Répertorier les contraintes
qui empêchent la conformité
à la condition initiale.
La société XYZ utilise des serveurs Unix
autonomes sans LDAP. Par conséquent,
chacun requiert un nom d’utilisateur « root ».
La société XYZ ne peut pas gérer le nom
d’utilisateur « root » ni consigner toutes les
activités de chaque utilisateur « root ».
2. Objectif
Définir l’objectif du contrôle
initial ; identifier l’objectif
satisfait par le contrôle
compensatoire.
L’exigence de noms d’utilisateur uniques vise
un double objectif. Premièrement, le partage
des informations d'identification n'est pas
acceptable du point de vue de la sécurité.
Deuxièmement, le partage des noms
d'utilisateur rend impossible l'identification de
la personne responsable d'une action
particulière.
3. Risque identifié
Identifier tous les risques
supplémentaires qu’induit
l'absence du contrôle initial.
L’absence d’ID d’utilisateur uniques et le fait
de ne pas pouvoir tracer les informations
d'identification introduisent des risques
supplémentaires dans le système de contrôle
d’accès.
4. Définition des
contrôles
compensatoires
Définir les contrôles
compensatoires et expliquer
comment ils satisfont les
objectifs du contrôle initial et
résolvent les risques
supplémentaires éventuels.
Une société XYZ va demander à tous les
utilisateurs de se connecter aux serveurs à
partir de leur bureau à l’aide de la
commande SU. Cette commande autorise les
utilisateurs à accéder au compte « root » et à
exécuter des actions sous ce compte, tout en
permettant de consigner leurs activités dans
le répertoire du journal SU. Il est ainsi
possible de suivre les actions de chaque
utilisateur par le biais du compte SU.
5. Validation des
contrôles
compensatoires
Définir comment les
contrôles compensatoires
ont été validés et testés.
La société XYZ démontre à l'évaluateur
l’exécution de la commande SU et lui montre
que celle-ci permet d’identifier les utilisateurs
connectés qui exécutent des actions sous le
compte « root ».
6.
Définir les processus et les
contrôles en place pour la
gestion des contrôles
compensatoires.
La société XYZ décrit les processus et les
procédures mis en place pour éviter la
modification, l’altération ou la suppression des
configurations SU de sorte que des
utilisateurs individuels puissent exécuter des
commandes root sans que leurs activités
soient consignées ou suivies.
Gestion
SAQ D PCI DSS, v2.0, Annexe C : Fiche de contrôles compensatoires
Octobre 2010
Page 40
Annexe D :
Explication de non applicabilité
Si les mentions « s.o.» ou « sans objet » ont été saisies dans la colonne « Spécial », utiliser cette fiche
de travail pour expliquer pourquoi la condition relative n'est pas applicable à l'organisation.
Condition
Raison pour laquelle la condition n'est pas applicable
Exemple :
9.3.1
Les visiteurs ne sont pas autorisés dans des zones où les données des titulaires de
carte sont traitées ou conservées.
SAQ D PCI DSS, v2.0, Annexe D : Explication de non applicabilité
Octobre 2010
Page 41