Payment Card Industry (PCI) Data Security Standard ... · Dernière validation selon les normes...

Payment Card Industry (PCI) Data Security Standard Questionnaire d'auto-évaluation C et attestation de conformité

Application de paiement connectée à Internet, aucun stockage électronique de données de titulaires de carte Version 2.0 Octobre 2010

SAQ C PCI DSS, v2.0, Modifications apportées au document Octobre 2010 Copyright 2010 PCI Security Standards Council LLC Page i

Modifications apportées au document

Date Version Description

1er Octobre 2008 1.2 Harmonisation du contenu avec la nouvelle procédure 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 C PCI DSS, v2.0, Table des matières Octobre 2010 Copyright 2010 PCI Security Standards Council LLC Page ii

Table des matières

Modifications apportées au document......................................................................... i Norme de sécurité des données du PCI : documents connexes ............................ iii Avant de commencer ................................................................................................... iv

Compléter le questionnaire d'auto-évaluation......................................................................iv Étapes de mise en conformité avec la norme PCI DSS ........................................................v Directives de non-applicabilité de certaines conditions particulières ................................v

Attestation de conformité, SAQ C................................................................................ 1

Questionnaire d’auto-évaluation C.............................................................................. 7 Création et gestion d’un réseau sécurisé ..............................................................................7

Condition 1 : Installer et gérer une configuration de pare-feu pour protéger les données .......7 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..................................................................8 Protection des données des titulaires de cartes de crédit ...................................................9

Condition 3 : Protéger les données de titulaires de cartes stockées........................................9 Condition 4 : Crypter la transmission des données des titulaires de cartes sur les réseaux

publics ouverts ..........................................................................................10 Gestion d’un programme de gestion des vulnérabilités.....................................................11

Condition 5 : Utiliser des logiciels ou des programmes antivirus et les mettre à jour régulièrement............................................................................................11

Condition 6 : Développer et gérer des systèmes et des applications sécurisés ...................11 Mise en œuvre de mesures de contrôle d’accès strictes ...................................................12

Condition 7 : Restreindre l'accès aux données des titulaires de cartes aux seuls individus qui doivent les connaître.................................................................................12

Condition 8 : Affecter un ID unique à chaque utilisateur d’ordinateur ...................................12 Condition 9 : Restreindre l’accès physique aux données des titulaires de cartes.................12

Surveillance et test réguliers des réseaux...........................................................................14 Condition 11 : Tester régulièrement les processus et les systèmes de sécurité...................14

Gestion d’une politique de sécurité des informations........................................................16 Condition 12 : Gérer une politique de sécurité des informations pour l'ensemble du

personnel ..................................................................................................16 Annexe A : (non utilisée) ............................................................................................ 18

Annexe B : Contrôles compensatoires ..................................................................... 19

Annexe C : Fiche de contrôles compensatoires ...................................................... 21 Fiche de contrôles compensatoires – Exemple complété..................................................22

L'Annexe D : Explication de non applicabilité .......................................................... 23

SAQ C PCI DSS, v2.0, Norme de sécurité des données du PCI : Documents connexes Octobre 2010 Copyright 2010 PCI Security Standards Council LLC 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 de sécurité des données du secteur des cartes de paiement (PCI DSS) et le SAQ PCI DSS.

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

Navigation dans la norme PCI DSS : Comprendre l'objectif des conditions


Norme de sécurité des données du PCI : Instructions et directives relatives à l'auto-évaluation


Norme de sécurité des données du PCI : Questionnaire d’auto-évaluation A et attestation

Commerçants qualifiés1

Norme de sécurité des données du PCI : Questionnaire d’auto-évaluation B et attestation


Norme de sécurité des données du PCI : Questionnaire d’auto-évaluation C-VT et attestation


Norme de sécurité des données du PCI : Questionnaire d’auto-évaluation C et attestation


Norme de sécurité des données du PCI : 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


1 Pour définir le questionnaire d’auto-évaluation approprié, consulter le document Norme de sécurité des

données du PCI : Instructions et directives relatives à l'auto-évaluation, « Sélectionner le SAQ et l’attestation les plus appropriés à l'organisation ».

SAQ C PCI DSS, v2.0, Avant de commencer Octobre 2010 Copyright 2010 PCI Security Standards Council LLC Page iv

Avant de commencer

Compléter le questionnaire d'auto-évaluation Le SAQ C a été élaboré pour satisfaire aux conditions applicables aux commerçants qui traitent des données de titulaires de carte par des applications de paiement (par exemple, des systèmes points de vente) connectées à Internet (par exemple, par DSL, câble modem, etc.), mais qui ne stockent aucune donnée de titulaires de carte sur un quelconque système informatique. Ces applications de paiement sont connectées à Internet parce que :

1. l'application de paiement se trouve sur un ordinateur personnel connecté à Internet, ou

2. l'application de paiement est connectée à Internet pour transmettre des données de titulaires de carte.

Les commerçants SAQ C sont définis ici et dans le document Instructions et directives relatives au questionnaire d'auto-évaluation. Les commerçants SAQ C traitent les données de titulaires de carte par des appareils de point de vente ou d'autres systèmes d'application de paiement connectés à Internet, ne stockent pas de telles données sur des systèmes informatiques, et peuvent être soit des commerçants artisans (carte présente), soit des commerçants de vente par courrier/téléphone ou commerce électronique (carte absente). De tels commerçants valident leur conformité en complétant un SAQ C et l'attestation de conformité associée, confirmant que :

la société possède un système d'application de paiement et une connexion Internet sur le même périphérique et/ou le même réseau local (LAN) ;

le système d'application de paiement/périphérique Internet n'est pas connecté à d'autres systèmes de l'environnement (cela peut être effectué par une segmentation de réseau en isolant le système d'application de paiement/périphérique Internet de tous les autres systèmes) ;

le magasin de la société n'est pas connecté à d'autres magasins et un LAN correspond uniquement à un magasin ;

la société conserve uniquement des rapports ou copies papier des reçus ;

la société ne stocke pas de données de titulaires de carte sous forme électronique ; et

le fournisseur de l'application de paiement de la société utilise des techniques sécurisées pour fournir une assistance à distance au système de paiement.

Chaque rubrique de ce questionnaire se concentre sur un domaine particulier de sécurité, en fonction des conditions du document Conditions et procédure d'évaluation de sécurité de la norme PCI DSS. Cette version abrégée du SAQ comprend des questions s'appliquant à un type particulier d'environnement de petit commerçant, tel qu'il est défini dans les critères de qualification ci-dessus. S'il existe des conditions PCI DSS applicables à l'environnement qui ne sont pas couvertes par ce SAQ, cela peut être une indication du fait que ce SAQ n'est pas adapté à cet environnement. En outre, il faut se conformer à toutes les conditions PCI DSS applicables afin d'être conforme à la norme PCI DSS.

SAQ C PCI DSS, v2.0, Avant de commencer Octobre 2010 Copyright 2010 PCI Security Standards Council LLC Page v

É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 (SAQ C) conformément aux instructions du document Instructions et directives relatives au questionnaire d'auto-évaluation.

3. Passer avec succès des analyses 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é.

5. Envoyer le questionnaire, une preuve de la réussite de l'analyse et l'attestation de conformité ainsi que tout autre documentation requise par l'acquéreur.

Directives de non-applicabilité de certaines conditions particulières Exclusion : s'il faut répondre au SAQ C pour valider la conformité à la norme PCI DSS, l'exception suivante est à prendre en considération. Voir « Non-applicabilité » ci-dessous pour la réponse SAQ appropriée.

Il est demandé de répondre aux questions particulières à 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.

Non-applicabilité : cette condition 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. ».

SAQ C PCI DSS, v2.0, Attestation de conformité Octobre 2010 Copyright 2010 PCI Security Standards Council LLC Page 1

Attestation de conformité, SAQ C Instructions de transmission Le commerçant doit compléter 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 :

Nom du contact : Poste occupé :

Téléphone : E-mail :

Adresse professionnelle :

Ville :

État/province : Pays : Code postal :

URL :

Partie 1b. Informations sur la société QSA (le cas échéant)

Nom de la société :

Nom du principal contact QSA :

Poste occupé :

Téléphone : E-mail :

Adresse professionnelle :

Ville :

État/province : Pays : Code postal :

URL :

Partie 2. Type d’entreprise du commerçant (cocher toutes les cases concernées) :

Détaillant Télécommunications Épiceries et supermarchés Pétrole Commerce électronique Commande par courrier/téléphone Autres

(préciser) : Indiquer les installations et les sites inclus 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

Oui Non


fidélisation, etc.) ?

La société entretient-elle une relation avec plusieurs acquéreurs ? 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 cartes ?

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.

Partie 2c. Admissibilité à participer au questionnaire SAQ C

Le commerçant certifie son admissibilité à remplir cette version abrégée du Questionnaire d'auto-évaluation pour les motifs suivants :

Le commerçant a un système d'application de paiement et une connexion à Internet ou à un réseau public sur le même appareil et/ou le même réseau local (LAN) ;

Le système d'application de paiement/périphérique Internet n'est relié à aucun autre système de l'environnement du commerçant ;

le magasin du commerçant n'est pas connecté à d'autres magasins et un LAN correspond uniquement à un magasin ;

Le commerçant ne stocke pas de données sur les titulaires de cartes sous forme électronique ; Si le commerçant stocke des données sur les titulaires de cartes, ces données ne sont que des rapports

imprimés ou des copies de bordereaux et ne sont pas reçues par voie électronique et Le fournisseur du logiciel d'application de paiement du commerçant utilise des techniques sécurisées pour

fournir un support à distance au système d'application de paiement du commerçant. Partie 3. Validation des normes PCI DSS

En se basant sur les résultats mentionnés dans le questionnaire SAQ C du (date d'achèvement), (Nom de la société du commerçant) certifie l'état de conformité suivant (cocher une seule case) :

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 commerçant) 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 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 PCI DSS C, version (n° 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 dernière à

tout moment. Aucune indication de stockage de données sur bande magnétique (par ex., piste)2, données CAV2, CVC2,

CID ou CVV23ou données PIN4 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

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

2 Données encodées sur la bande magnétique ou données équivalente 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.


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 Description de la condition OUI NON

Date et actions de mise en conformité

(si l’état de conformité est « NON »)

1

Installer et gérer une configuration de pare-feu pour protéger les données des titulaires de cartes

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

3 Protéger les données de titulaire de carte stockées

4 Crypter la transmission des données des titulaires de cartes 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 cartes aux seuls individus qui doivent les connaître

8 Affecter un ID unique à chaque utilisateur d’ordinateur

9 Restreindre l’accès physique aux données des titulaires de cartes

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

SAQ C PCI DSS, v2.0, Questionnaire d'auto-évaluation Octobre 2010 Copyright 2010 PCI Security Standards Council LLC Page 7

Questionnaire d’auto-évaluation C

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 Réponse : Oui Non Spécial*

1.2 Les configurations de pare-feu restreignent-elles les connexions entre les réseaux non approuvés et tous les composants du système dans l’environnement des données des titulaires de cartes 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.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 ?

1.3 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.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.5 Le trafic sortant de l'environnement des données des titulaires de carte vers Internet est-il explicitement autorisé ?

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) ?


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


2.1 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 sont-ils modifiés, le cas échéant ?

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 non requis directement pour exécuter la fonction du périphérique sont désactivés) ?

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.

(a) Tous les accès administratifs non-console sont-ils cryptés avec une cryptographie robuste, et une méthode de cryptographie robuste a-t-elle été 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 ?

2.3

(c) L’accès administrateur aux interfaces de gestion Web est-il crypté au moyen d’une méthode de cryptage robuste ?


Protection des données des titulaires de cartes de crédit Condition 3 : Protéger les données de titulaires de cartes stockées

Question PCI DSS Réponse : Oui Non

Spécial*

(b) 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 ?

3.2

(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) :

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. 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 ?

3.3 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 qui ont 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 (POS).


Condition 4 : Crypter la transmission des données des titulaires de cartes sur les réseaux publics ouverts


(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) ?

4.1

(e) Pour les implémentations SSL/TLS : • La mention HTTPS apparaît-elle dans l'adresse URL

(Universal Record Locator) du navigateur ? • Les données de titulaires de carte sont-elles requises

uniquement lorsque la mention HTTPS apparaît dans l'adresse URL ?

4.1.1 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 titulaires de carte ? Remarque : l'utilisation du protocole WEP comme contrôle de sécurité est interdit depuis le 30 juin 2010.

4.2 (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 ?


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


5.1

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 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 ?

5.2 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 sont-elles 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


(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 ?

6.1

(b) Les correctifs de sécurité essentiels sont-ils installés dans le mois qui suit leur publication ?


Mise en œuvre de mesures de contrôle d’accès strictes Condition 7 : Restreindre l'accès aux données des titulaires de cartes aux seuls individus qui doivent les connaître


7.1 (a) L'accès aux composants du système et aux données des titulaires de cartes 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) ?

Condition 8 : Affecter un ID unique à chaque utilisateur d’ordinateur


8.3 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.

(a) Les comptes utilisés par les prestataires pour un accès à distance, la maintenance ou une assistance sont-ils activés pendant la période nécessaire uniquement ?

8.5.6

(b) Les comptes d'accès à distance des fournisseurs sont-ils surveillés lorsqu'ils sont utilisés ?

Condition 9 : Restreindre l’accès physique aux données des titulaires de cartes


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.



(a) Un contrôle strict s'applique-t-il à la distribution interne ou externe d'un type de support ?

9.7

(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 ?

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 de gestion est-elle obtenue avant le déplacement du support (particulièrement lorsque le support est distribué aux individus) ?

9.8 Un contrôle strict est-il réalisé sur le stockage et l’accessibilité des supports ?

Tous les supports sont-ils détruits lorsqu'ils ne sont plus utiles pour des raisons professionnelles ou légales ?

9.10

La destruction est-elle réalisée comme suit :

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 cartes ne puissent pas être reconstituées ?

9.10.1

(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)


Surveillance et test réguliers des réseaux Condition 11 : Tester régulièrement les processus et les systèmes de sécurité


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 pour identifier les points d'accès sans fil non autorisés est-il exécuté au moins chaque trimestre ?

(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 ?

11.1

(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) comme suit : 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 renseigné 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 sont-elles réalisées ?



Spécial*

(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) ?

(a) Des analyses trimestrielles de vulnérabilité externe sont-elles 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) ?

11.2.2

c) Les analyses trimestrielles de vulnérabilité externe sont-elles 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) ?

(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.

11.2.3

(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) ?


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 Réponse : Oui Non Spécial*

12.1 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 cartes de la société.

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.3 (a) 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.5 Usages acceptables des technologies

12.3.6 Emplacements acceptables des technologies sur le réseau

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.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 Les responsabilités suivantes de gestion de la sécurité des informations sont-elles assignées à un individu ou à une équipe :

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.6 (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 ?

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.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 ?

SAQ C PCI DSS, v2.0, Annexe A : (non utilisée) Octobre 2010 Copyright 2010 PCI Security Standards Council LLC Page 18

Annexe A : (non utilisée)

Page laissée volontairement vide

SAQ C PCI DSS, v2.0, Annexe B : Contrôles compensatoires Octobre 2010 Copyright 2010 PCI Security Standards Council LLC Page 19

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 renseigné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 restreindre 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ée 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 périphérique ou un ensemble de périphériques, 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. Être proportionnels aux risques supplémentaires qu'implique la non conformité à la condition de la norme PCI DSS.

SAQ C PCI DSS, v2.0, Annexe B : Contrôles compensatoires Octobre 2010 Copyright 2010 PCI Security Standards Council LLC Page 20

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 C PCI DSS, v2.0, Annexe C : Fiche de contrôles compensatoires Octobre 2010 Copyright 2010 PCI Security Standards Council LLC Page 21

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 Explication

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 déployés pour la gestion des contrôles compensatoires.

SAQ C PCI DSS, v2.0, Annexe C : Fiche de contrôles compensatoires Octobre 2010 Copyright 2010 PCI Security Standards Council LLC Page 22

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. Gestion Définir les processus et les contrôles déployés 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 l'élimination 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.

SAQ C PCI DSS, v2.0, Annexe D : Explication de non applicabilité Octobre 2010 Copyright 2010 PCI Security Standards Council LLC Page 23

L'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 : 12.8

Les données de titulaires de carte ne sont jamais partagées avec des prestataires de services.

Payment Card Industry (PCI) Data Security Standard ... · Dernière validation selon les normes...

Documents

Transcript of Payment Card Industry (PCI) Data Security Standard ... · Dernière validation selon les normes...