Secteur de la carte de paiement (Payment Card Industry, PCI) Normes de sécurité des données (Data Security Standard, DSS)

Transcription

1 Secteur de la carte de paiement (Payment Card Industry, PCI) Normes de sécurité des données (Data Security Standard, DSS) Conditions et procédures d'évaluation de sécurité Version 2.0 Octobre 2010

2 Copyright 2010 PCI Security Standards Council LLC Page 2

3 Modifications apportées au document Version Description Pages Octobre Juillet Octobre Pour introduire les normes PCI DSS v1.2 comme «Conditions et procédure d'évaluation de sécurité PCI DSS», éliminer les redondances entre les documents, et faire des changements à la fois généraux et spécifiques à partir des procédures de vérification de sécurité PCI DSS v1.1. Pour des renseignements complets, voir le récapitulatif des changements des normes de sécurité des données PCI de la version 1.1 à la version 1.2 des normes PCI DSS. Ajouter une phrase qui a été supprimée de manière incorrecte entre les versions 1.1 et 1.2 des normes PCI DSS. Corriger «puis» par «que» dans les procédures de test a et b. 32 Retirer les marques grisées des colonnes «en» et «pas en» dans la procédure de test 6.5.b. Pour des fiches de contrôles compensatoires Exemple rempli, formulation correct en haut de page pour dire «Utiliser cette fiche pour définir les contrôles compensatoires d'une exigence notée comme «en» par les contrôles compensatoires». Mettre à jour et mettre en œuvre les changements v Pour plus de détails, consulter «PCI-DSS Récapitulatif des changements à partir des normes PCI-DSS, versions à 2.0» Copyright 2010 PCI Security Standards Council LLC Page 3

4 Table des matières Modifications apportées au document... 3 Introduction et présentation des normes de sécurité des données PCI... 6 Renseignements relatifs aux conditions d application des normes PCI DSS... 8 Relation entre PCI DSS et PA-DSS Portée de l'évaluation de conformité aux exigences PCI DSS Segmentation de réseau Sans fil Tierce partie/externalisation Échantillonnage des installations commerciales/composants du système Contrôles compensatoires Instructions et contenu du rapport sur la conformité Contenu et format du rapport Revalidation des éléments en instance Étapes de mise en conformité avec les normes PCI DSS Conditions et procédures d évaluation de sécurité détaillées des normes PCI DSS Création et gestion d un réseau sécurisé Exigence 1 : installer et gérer une configuration de pare-feu pour protéger les données de titulaire de carte Exigence 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 26 Protection des données de titulaire de carte de crédit Exigence 3 : Protéger les données de titulaire de carte stockées Exigence 4 : Crypter la transmission des données de titulaire de carte sur les réseaux publics ouverts Gestion d un programme de gestion des vulnérabilités Exigence 5 : Utiliser des logiciels ou des programmes antivirus et les mettre à jour régulièrement Exigence 6 : Développer et gérer des systèmes et des applications sécurisés Mise en œuvre de mesures de contrôle d accès strictes Exigence 7 : Restreindre l accès aux données de titulaire de carte aux seuls individus qui doivent les connaître Exigence 8 : Affecter un ID unique à chaque utilisateur d ordinateur Exigence 9 : Restreindre l accès physique aux données de titulaire de carte Surveillance et test réguliers des réseaux Copyright 2010 PCI Security Standards Council LLC Page 4

5 Exigence 10 : Effectuer le suivi et surveiller tous les accès aux ressources réseau et aux données de titulaire de carte..61 Exigence 11 : Tester régulièrement les processus et les systèmes de sécurité Gestion d une politique de sécurité des informations Exigence 12 : Gérer une politique qui assure la sécurité des informations au niveau de l'ensemble du personnel Annexe A : Autres exigences des normes PCI DSS s appliquant aux fournisseurs d hébergement partagé Annexe B : Contrôles compensatoires Annexe C : Fiche de contrôles compensatoires Fiche de contrôles compensatoires Exemple complété Annexe D : Segmentation et échantillonnage des installations commerciales/composants système Copyright 2010 PCI Security Standards Council LLC Page 5

6 Introduction et présentation des normes de sécurité des données PCI Les normes de sécurité des données (DSS) du secteur des cartes de paiement (PCI) ont été développées pour encourager et renforcer la sécurité des données de titulaire de carte et permettre l'adoption généralisée des mesures mondiales de sécurité des données cohérentes. Les normes PCI DSS fournissent un plan de départ des exigences techniques et opérationnelles désignées pour protéger les données de titulaire de carte. Les normes PCI DSS s'appliquent à toutes les entités impliquées dans le processus de carte de paiement comme les commerçants, les processeurs, les acquéreurs, les émetteurs et les prestataires de services ainsi que toute autre entité qui stocke, traite ou transmet des données de titulaire de carte. Les normes PCI DSS consistent en un ensemble minimum d'exigences pour la protection des données de titulaires de carte, et peuvent être améliorées par des contrôles et pratiques suppléme pour atténuer davantage les risques. Ci-dessous se trouve une présentation de haut niveau des 12 exigences des normes PCI DSS. Ce document, Conditions et procédures d'évaluation des normes de sécurité des données PCI, combine les 12 exigences PCI DSS et les procédures de test correspondantes dans un outil d'évaluation de sécurité. Il est conçu pour être utilisé lors des évaluations de conformité aux normes PCI DSS comme partie du processus du test de validation de la conformité d'une entité. Les sections suivantes fournissent des directives détaillées et les meilleures pratiques pour aider les entités à se préparer pour conduire et reporter les résultats d'une évaluation PCI DSS. Les conditions et procédures de test des normes PCI DSS commencent à la page 19. Copyright 2010 PCI Security Standards Council LLC Page 6

7 Le site Web du Conseil des normes de sécurité du secteur des cartes de paiement (PCI DSS) ( contient un certain nombre de ressources suppléme comme : l'attestation de conformité; Parcourir les normes PCI DSS : comprendre l objectif des exigences; le glossaire des termes, abréviations et acronymes des normes PCI DSS et PA- DSS; la foire aux questions (FAQ); les suppléments d'information et les directives. Remarque : des suppléments d'information complètent les normes PCI DSS et identifient les considérations et recommandations suppléme pour satisfaire les exigences des normes PCI DSS; ils ne changent, éliminent ni ne remnt les normes PCI DSS ou l'une de leurs exigences. Se reporter au site pour plus de renseignements. Copyright 2010 PCI Security Standards Council LLC Page 7

8 Renseignements relatifs aux conditions d application des normes PCI DSS Les normes PCI DSS s'appliquent partout où des données de compte sont stockées, traitées ou transmises. Les données de compte se composent des données de titulaire de carte et des données d'authentification sensibles, comme suit : Les données du titulaire de carte comprennent : le numéro de compte principal (Primary Account Number, PAN) le nom du titulaire de carte; la date d'expiration; le code de service. Les données d'authentification sensibles comprennent : des données de bande magnétique complètes ou équivalentes sur une puce; les CAV2/CVC2/CVV2/CID; les codes/blocs NIP Le numéro de compte principal (PAN) est le facteur déterminant des conditions d'application des exigences PCI DSS. Les exigences PCI DSS sont applicables si le PAN est stocké, traité ou transmis. Si le PAN n'est pas stocké, traité ou transmis, les exigences PCI DSS ne s'appliquent pas. Si le nom du titulaire de carte, le code de service, et/ou la date d'expiration sont stockés, traités ou transmis avec le PAN, ou sont par ailleurs présents dans l'environnement des données du titulaire de carte, ils doivent être protégés conformément à toutes les exigences PCI DSS excepté les exigences 3.3 et 3.4, qui s'appliquent uniquement au PAN. Les normes PCI DSS représente un ensemble minimum d'objectifs de contrôle qui peuvent être améliorés par des lois et règlements locaux, régionaux ou de secteur. En outre, les exigences de la législation ou la réglementation peuvent exiger une protection spécifique des renseignements identifiables personnels ou d'autres éléments de données (par exemple, le nom du titulaire de carte), ou définir des pratiques de divulgation d'une entité relatives aux renseignements des consommateurs. Les exemples comprennent la législation relative à la protection des données des consommateurs, à la vie privée, au vol d'identité, ou à la sécurité des données. Les normes PCI DSS ne remnt pas les lois locales ou régionales, les réglementations gouvernementales ou d'autres exigences légales. Le tableau suivant présente des éléments couramment utilisés de données de titulaire de carte et d authentification sensibles, et indique si le stockage de chaque élément est autorisé ou interdit, et précise si chaque élément de données doit être protégé. Ce tableau n'est pas exhaustif, mais il est présenté de manière à illustrer les divers types d'exigences qui s'appliquent à chaque élément de données. Copyright 2010 PCI Security Standards Council LLC Page 8

9 Données de compte Données de titulaire de carte de crédit Données d authentification sensibles 1 Élément de données Numéro de compte principal (PAN) Stockage autorisé Oui Rendre les données de compte stockées illisibles selon l'exigence 3.4 Oui Nom du titulaire de carte Oui Non Code de service Oui Non d'expiration Oui Non Données de bande magnétique complètes 2 Non Ne peut pas stocker selon l'exigence 3.2 CAV2/CVC2/CVV2/CID Code/bloc PIN Non Non Ne peut pas stocker selon l'exigence 3.2 Ne peut pas stocker selon l'exigence 3.2 Les exigences 3.3 et 3.4 des normes PCI DSS s'appliquent uniquement au PAN. Si le PAN est stocké avec d'autres éléments de données du titulaire de carte, seul le PAN doit être rendu illisible selon l'exigence 3.4 des normes PCI DSS. Les normes PCI DSS s'appliquent uniquement si les PAN sont stockés, traités et/ou transmis. 1 Les données d'authentification sensibles ne doivent plus être stockées après autorisation (même si elles sont cryptées). 2 2 Données de piste complètes extraites de la bande magnétique, de données équivalentes sur la puce, ou d un autre support. 2 Copyright 2010 PCI Security Standards Council LLC Page 9

10 Relation entre PCI DSS et PA-DSS L'utilisation d'une application conforme à la norme PA-DSS par elle-même n'en fait pas une entité conforme aux normes PCI DSS, car cette application doit être mise en œuvre dans un environnement conforme aux normes PCI DSS et conformément au Guide de mise en œuvre de la norme PA-DSS proposé par le fournisseur d'applications de paiement (conformément l'exigence 13.1 de la norme PA-DSS). Les exigences de la norme PA-DSS (Payment Application Data Security Standard, normes de sécurité des données d'applications de paiement) sont issues des conditions et procédures d évaluation de sécurité des normes PCI DSS(ce document). La norme PA-DSS Error! Hyperlink reference not valid.détaille ce qu'une application de paiement doit prendre en charge pour permettre la conformité aux normes PCI DSS d'un client. Les applications de paiement sécurisées, lorsqu'elles sont mises en œuvre dans un environnement conforme aux normes PCI DSS, réduisent autant que possible le risque de voir les failles de sécurité compromettre les données de bande magnétique complètes, les codes et valeurs de vérification de carte (CAV2, CID, CVC2, CVV2), les codes et les blocs NIP, ainsi que la fraude résultant de ces failles. Seules certaines des applications de paiement peuvent empêcher la conformité, comme : le stockage des données de bande magnétique et/ou de données équivalentes provenant de la puce sur le réseau du client après autorisation; les applications nécessitant que les clients désactivent d'autres fonctions exigées par les normes PCI DSS, comme les programmes antivirus ou les pare-feu, afin que l'application de paiement fonctionne correctement; l'utilisation des fournisseurs de méthodes non sécuritaires pour connecter une application afin de fournir une assistance au client. La norme PA-DSS s'applique aux fournisseurs de logiciels et autres qui développent des applications de paiement qui stockent, traitent ou transmettent des données de titulaire de carte dans le cadre d'une autorisation ou d'un règlement, lorsque ces applications de paiement sont vendues, distribuées ou cédées sous licence à des parties tierces. Noter ce qui suit concernant les conditions d'application de la norme PA-DSS : la norme PA-DSS s'applique aux applications de paiement généralement vendues «prêtes à l'emploi» sans modification apportée par les fournisseurs de logiciels; la norme PA-DSS ne s'applique pas aux applications de paiement développées par des commerçants et des prestataires de services si elles sont utilisées en interne uniquement (non vendues, distribuées ou cédées sous licence à une partie tierce), puisque de telles applications de paiement doivent être couvertes dans le cadre de la conformité normale du prestataire de services aux PCI DSS. Pour des directives détaillées sur la manière de déterminer si la norme PA-DSS s'applique à une application de paiement donnée, se reporter aux conditions et procédures d'évaluation de sécurité PCI DSS, qui peuvent être trouvées à l'adresse Copyright 2010 PCI Security Standards Council LLC Page 10

11 Portée de l'évaluation de conformité aux exigences PCI DSS Les exigences de sécurité des normes PCI DSS s'appliquent à tous les composants du système. Dans le contexte des normes PCI DSS, les «composants du système» sont définis comme les composants de réseau, de serveur ou d'application qui sont compris dans ou connectés à l'environnement des données de titulaire de carte. Les «composants du système» comprennent également les composants de virtualisation comme les machines virtuelles, les commutateurs/routeurs virtuels, les appareils virtuels, les applications/bureaux virtuels, et les hyperviseurs. L'environnement des données de titulaire de carte est composé de personnes, processus et technologies qui stockent, traitent ou transmettent des données de titulaires de cartes ou des données d'authentification sensibles. Les composants du réseau peuvent comprendre, mais sans s'y limiter, les pare-feu, les commutateurs, les routeurs, les points d accès sans fil, les équipements de réseau et d'autres appareils de sécurité. Les types de serveurs comprennent, mais sans s'y limiter, les éléments suivants : le Web, l'application, la base de données, l authentification, le courriel, les serveurs proxy, le protocole de synchronisation réseau (Network Time Protocol, NTP) et le serveur de noms de domaine (DNS). Les applications comprennent toutes les applications achetées et personnalisées, y compris les applications internes et externes (par exemple, Internet). La première étape de l'évaluation PCI DSS est de déterminer avec précision la portée de la vérification. Au moins chaque année et avant l'évaluation annuelle, les entités évaluées doivent confirmer l'exactitude de la portée des normes PCI DSS en identifiant tous les emments et flux de données de titulaire de carte et en s'assurant qu'ils sont compris dans cette portée. Pour confirmer l'exactitude et la pertinence de la portée des normes PCI DSS, procéder comme suit : L'entité évaluée identifie et documente l'existence de toutes les données de titulaire de carte dans leur environnement, pour vérifier qu'aucune donnée de titulaire de carte n'existe en dehors de l'environnement de données de titulaire de carte (CDE) défini. Une fois que tous les emments des données de titulaire de carte sont identifiés et documentés, l'entité utilise les résultats pour vérifier que la portée des normes PCI DSS est approprié (par exemple, les résultats peuvent être un schéma ou un inventaire des emments des données de titulaire de carte). L'entité considère les données de titulaire de carte se trouvant dans la portée de l'évaluation PCI DSS et dans le cadre du CDE sauf si de telles données sont supprimées ou déplacées/consolidées dans le CDE défini actuellement. L'entité conserve la documentation qui montre comment la portée des normes PCI DSS a été confirmée et les résultats, pour l'examen de l'évaluateur et/ou pour référence lors de la prochaine activité de confirmation de la portée des normes PCI DSS annuelle. Segmentation de réseau La segmentation de réseau, ou l'isolement (segmentation), de l'environnement des données de titulaire de carte depuis le reste du réseau de l'entité n'est pas une exigence PCI DSS. Cependant, elle est fortement recommandée comme méthode pouvant réduire : la portée de l'évaluation PCI DSS; le coût de l'évaluation PCI DSS; le coût et la difficulté de la mise en œuvre et de la gestion des contrôles PCI DSS; Copyright 2010 PCI Security Standards Council LLC Page 11

12 le risque pour une organisation (réduit par la consolidation des données de titulaire de carte dans le moins d'endroits possible et mieux contrôlés). Sans segmentation du réseau adéquate (parfois nommé «réseau plat»), le réseau entier se trouve dans la portée de l'évaluation PCI DSS. La segmentation du réseau peut être réalisée à travers un nombre de significations physiques ou logiques, comme des pare-feu de réseau internes configurés correctement, des routeurs ayant des listes de contrôles d'accès performants, ou d'autres technologies qui restreignent l'accès à un segment particulier d'un réseau. Une condition préalable à la réduction de la portée de l'environnement des données de titulaire de carte est une compréhension claire des besoins de l'activité et des processus relatifs au stockage, au traitement ou à la transmission des données de titulaire de carte. La restriction des données de titulaire de carte dans le moins d'endroits possibles par l'élimination des données non nécessaires, et la consolidation des données nécessaires, peut exiger la réingénierie de pratiques commerciales de longue date. La documentation des flux de données de titulaire de carte par un schéma de flux de données aide à comprendre entièrement tous les flux de données de titulaire de carte et assure que les segmentations de réseau sont efficaces pour l'isolement de l'environnement des données de titulaire de carte. Si une segmentation de réseau est en et est utilisée pour réduire la portée de l'évaluation PCI DSS, l'évaluateur doit vérifier que la segmentation est adéquate pour réduire cette portée. À un haut niveau, une segmentation réseau adéquate isole les systèmes qui stockent, traitent ou transmettent les données de titulaire de carte de ceux qui ne le font pas. Cependant, l'adéquation d'une mise en œuvre spécifique d'une segmentation de réseau est hautement variable et dépend d'un certain nombre de facteurs, comme une configuration de réseau donnée, les technologies déployées, et des autres contrôles qui peuvent être mis en œuvre. L'Annexe D : Segmentation et échantillonnage des installations commerciales/composants du système fournit davantage de renseignements sur les effets d'une segmentation de réseau et d'un échantillonnage sur la portée de l'évaluation PCI DSS. Sans fil Si une technologie sans fil est utilisée pour stocker, traiter ou transmettre des données de titulaire de carte (par exemple, des transactions en point de vente, ou l'enregistrement des données en situation de mobilité, dit «line-busting»), ou si un réseau local sans fil (WLAN) est connecté à, ou fait partie de l'environnement des données de titulaire de carte (par exemple, parce qu'il n'est pas clairement séparé par un pare-feu), les exigences et procédures de test PCI DSS pour des environnements sans fil s'appliquent et doivent être mises en œuvre (par exemple, les exigences 1.2.3, et 4.1.1). Avant qu'une technologie sans fil soit mise en œuvre, une entité doit évaluer soigneusement la nécessité de la technologie par rapport aux risques. Envisager le déploiement d'une technologie sans fil uniquement pour la transmission des données nonsensibles. Tierce partie/externalisation Pour les prestataires de services devant se soumettre à une évaluation annuelle sur site, une validation de la conformité doit être réalisée sur tous les composants du système dans l'environnement des données de titulaire de carte. Copyright 2010 PCI Security Standards Council LLC Page 12

13 Un prestataire de services ou un commerçant peut faire appel à un prestataire de services tiers pour stoker, traiter ou transmettre des données de titulaire de carte en son nom, ou pour gérer des composants comme des routeurs, des pare-feu, des bases de données, la sécurité physique, et/ou des serveurs. Si c'est le cas, il peut exister un impact sur la sécurité de l'environnement des données de titulaire de carte. En ce qui concerne les entités qui externalisent leur stockage, traitement ou transmission de données de titulaire de carte à des fournisseurs de service tiers, le rapport sur la conformité (ROC) doit renseigner le rôle de chaque fournisseur de service, en identifiant clairement quelles exigences s'appliquent aux entités évaluées et celles qui s'appliquent au prestataire de services. Deux options se présentent aux prestataires de services tiers pour valider la conformité : 1) Ils peuvent se soumettre d'eux-mêmes à une évaluation PCI DSS et fournir des justificatifs à leurs clients pour démontrer leur conformité. 2) S'ils ne se soumettent pas d'eux-mêmes à une évaluation PCI DSS, ils devront faire examiner leurs services lors de chacune des évaluations PCI DSS de leurs clients. Voir le point commençant par «Pour les vérifications auprès des prestataires de services gérés (MSP)», dans l'élément 3, «Détails concernant l'environnement évalué», dans la section «Instructions et contenu pour le Rapport sur la conformité» ci-dessous, pour plus de renseignements. En outre, les commerçants et prestataires de services doivent gérer et surveiller la conformité PCI DSS de tous les prestataires de services tiers associés ayant un accès aux données de titulaire de carte. Se reporter à l'exigence 12.8 de ce document pour les détails. Échantillonnage des installations commerciales/composants du système L'échantillonnage n'est pas une exigence PCI DSS. Toutefois, après avoir examiné la portée globale et la complexité de l'environnement en cours d'évaluation, l'évaluateur peut sélectionner indépendamment des échantillons représentatifs des installations commerciales/composants du système afin d'évaluer les exigences PCI DSS. Ces échantillons peuvent être définis dans un premier temps pour les installations commerciales, puis pour les composants du système au sein de chaque installation commerciale. Les échantillons doivent être une sélection représentative de tous les types et emments d'installations commerciales, ainsi que des types de composants système au sein des installations commerciales sélectionnées. Les échantillons doivent être suffisamment larges pour fournir à l'évaluateur l'assurance que les contrôles ont été réalisés comme prévu. L'échantillonnage des installations commerciales/composants du système pour une évaluation ne doit pas réduire la portée de l'environnement des données de titulaire de carte ou des conditions d'application des exigences PCI DSS. Que l'échantillonnage soit utilisé ou non, les exigences PCI DSS s'appliquent à l'environnement des données de titulaire de carte entier. Si l'échantillonnage est utilisé, chaque échantillon doit être évalué par rapport à toutes les exigences PCI DSS applicables. L'échantillonnage des exigences PCI DSS elles-mêmes n'est pas permis. Des exemples d'installations commerciales comprennent, mais sans s'y limiter : des bureaux d'entreprise, des magasins, des magasins franchisés, des installations de traitement, des centres de données, et d'autres types d'installation dans différents endroits. L'échantillonnage doit comprendre des composants du système au sein de chaque installation commerciale sélectionnée. Par exemple, pour chaque installation commerciale sélectionnée, comprendre une variété de systèmes d'exploitation, de fonctions et d'applications qui sont applicables à la zone sous vérification. À titre d'exemple, l'évaluateur peut définir un échantillon d'une installation commerciale pour comprendre des serveurs Sun fonctionnant sous Apache WWW, des serveurs Windows fonctionnant sous Oracle, des systèmes mainframe fonctionnant sous des applications de traitement de carte existantes, des serveurs de transfert de données fonctionnant sous HP-UX, ainsi que des serveurs Linux fonctionnant sous MYSQL. Si Copyright 2010 PCI Security Standards Council LLC Page 13

14 toutes les applications fonctionnent à partir d'une seule version d'un système d'exploitation (par exemple, Windows 7 ou Solaris 10), l'échantillon doit néanmoins comporter une multiplicité d'applications (par exemple, des serveurs de base de données, des serveurs Web, des serveurs de transfert de données). Lorsque les évaluateurs sélectionnent indépendamment des échantillons d'installations commerciales/composants du système, ils doivent prendre en compte ce qui suit : S'il existe des processus et contrôles opérationnels et de sécurité PCI DSS centralisés standards en qui assurent la cohérence et auxquels chaque installation commerciale/composant système doit se conformer, l'échantillon peut être plus petit que s'il n'existe pas de processus/contrôles en. L'échantillon doit être suffisamment important pour fournir à l'évaluateur l'assurance nécessaire que toutes les installations commerciales ou tous les composants du système sont configurés selon les processus standards. S'il existe plus d'un type de processus opérationnel et/ou de sécurité standards en (par exemple, pour différents types d'installations commerciales ou de composants du système), l'échantillon doit être suffisamment important pour comprendre des installations commerciales/composants du système sécurisés avec chaque type de processus. S'il n'existe pas de processus ou de contrôle standards en PCI DSS et que chaque installation commerciale et composant du système sont gérés par des processus non standards, l'échantillon doit être plus important pour que l'évaluateur soit assuré que chaque installation commerciale/composant du système met en œuvre les exigences de la norme PCI DSS de manière appropriée. Pour chaque cas où l'échantillon est utilisé, l'évaluateur doit : documenter la justification de la technique d'échantillonnage et la taille de l'échantillon; documenter et valider les processus et contrôles standardisés aux normes PCI DSS, utilisés pour déterminer la taille de l'échantillon; expliquer comment l'échantillon est approprié et représentatif de la population globale. Les évaluateurs doivent valider de nouveau la justification de l'échantillonnage pour chaque évaluation. Si un échantillonnage est utilisé, différents échantillons d'installations commerciales et de composants du système doivent être sélectionnés pour chaque évaluation. Contrôles compensatoires Sur une base annuelle, tous les contrôles compensatoires doivent être documentés, révisés et validés par l'évaluateur et joints à la soumission du Rapport sur la conformité, comme indiqué en Annexe B : Contrôles compensatoires et en Annexe C : Fiche de contrôles compensatoires. Pour chacun des contrôles compensatoires, la fiche de contrôle compensatoire (Annexe C) doit être complétée. En outre, les résultats des contrôles compensatoires doivent être documentés dans le rapport sur la conformité dans la section correspondant à l'exigence de la norme PCI DSS. Voir les Annexes B et C mentionnées ci-dessus pour plus de renseignements sur les «contrôles compensatoires». Se reporter également à : Annexe D : Segmentation et échantillonnage des installations commerciales/composants du système. Copyright 2010 PCI Security Standards Council LLC Page 14

15 Instructions et contenu du rapport sur la conformité Ce document doit être utilisé comme modèle pour la création du rapport sur la conformité. L'entité évaluée doit suivre les exigences de rapport respectives de chaque marque de carte de paiement pour garantir que chaque marque de carte de paiement reconnaît le statut de conformité de l'entité. Contacter chaque marque de carte de paiement pour déterminer les exigences de rapport et les instructions. Contenu et format du rapport Suivre ces instructions pour le contenu et le format du rapport en complétant le rapport sur la conformité : 1. Résumé Inclure les éléments suivants : Décrire l'activité de carte de paiement de l'entité, y compris : - son rôle commercial avec les cartes de paiement, c'est-à-dire comment et pourquoi elle stocke, traite et/ou transmet des données de titulaire de carte; Remarque : cela ne doit pas être un couper-coller sur le site Web de l'entité, mais doit être une description sur mesure qui montre que l'évaluateur comprend le paiement et le rôle de l'entité. - comment elle traite le paiement (directement, indirectement, etc.); - quels types de chaînes de paiement elle dessert, comme les transactions avec carte absente (par exemple, commande par courriel ou par téléphone [CCTC], commerce électronique) ou avec carte présente; - toutes les entités qui se connectent pour une transmission ou un traitement de paiement, y compris les relations processeurs. Un schéma de réseau de haut niveau (obtenu de l'entité ou crée par l'évaluateur) de la topographie des réseaux de l'entité qui comprend : - les connexions internes et externes du réseau; - les composants essentiels au sein de l'environnement des données de titulaire de carte, comprenant des dispositifs points de vente, des systèmes, des bases de données, et des serveurs Web, le cas échéant; - d'autres composants de paiement, le cas échéant. Copyright 2010 PCI Security Standards Council LLC Page 15

16 2. Description de la portée des travaux et de l'approche adoptée Décrire la portée, conformément à la section Portée de l'évaluation, y compris ce qui suit : Documenter la manière dont l'évaluateur a validé la précision de la portée des normes PCI DSS pour l'évaluation, y compris : - les méthodes ou processus utilisés pour identifier et documenter toutes les existences des données de titulaire de carte; - la manière dont les résultats ont été évalués et documentés; - la manière dont l'efficacité et la précision des méthodes utilisées ont été vérifiées; - que l'évaluateur valide le fait que la portée de l'évaluation est exacte et appropriée. L'environnement sur lequel l'évaluation est axée (par exemple, les points d'accès Internet du client, le réseau interne de l'entreprise, les connexions de traitements) Si la segmentation de réseau est en et a été utilisée pour réduire la portée de la vérification PCI DSS, expliquer brièvement la segmentation et la manière dont l'évaluateur a validé son efficacité. Si un échantillonnage est utilisé lors de l'évaluation, pour chaque ensemble d'échantillons sélectionné (d'installations commerciales/composants du système), documenter ce qui suit : - la population totale; - le nombre échantillonné; - la justification de l'échantillon sélectionné; - la description des processus et contrôles opérationnels et de sécurité PCI DSS standardisés utilisés pour déterminer la taille de l'échantillon, et comment les processus/contrôles ont été validés; - à quel point l'échantillon est approprié et représentatif de la population globale; - la description des emments ou environnements qui stockent, traitent ou transmettent des données de titulaire de carte, EXCLUS de la portée de la vérification, et pourquoi ils l'ont été. Répertorier les entités à part entière qui exigent une conformité aux normes PCI DSS, et si elles ont été examinées séparément ou dans le cadre de l'évaluation. Répertorier toutes les entités internationales qui exigent une conformité aux normes PCI DSS, et si elles ont été examinées séparément ou dans le cadre de l'évaluation. Répertorier tous les réseaux locaux et/ou toutes les applications de paiement sans fil (par exemple, les terminaux points de vente) qui sont connectés à l'environnement des données de titulaire de carte, ou pourraient avoir un impact sur sa sécurité, et décrire la sécurité en pour ces environnements sans fil. La version du document Conditions et procédures d'évaluation de sécurité PCI DSS utilisée pour conduire l'évaluation. Copyright 2010 PCI Security Standards Council LLC Page 16

17 3. Détails concernant l'environnement examiné Joindre les détails suivants dans cette section : Un schéma de chaque élément de la liaison de communication, notamment un LAN, un WAN ou une connexion Internet. Une description de l'environnement des données de titulaire de carte, par exemple : - documenter la transmission et le traitement des données de titulaire de carte, y compris l'autorisation, la capture, le règlement, rejet de débit, et d'autres flux le cas échéant; - une liste des fichiers et tableaux qui stockent les données de titulaire de carte, prises en charge par un inventaire créé (ou obtenu de la part du client) et conservé par l'évaluateur dans les documents de travail. Cet inventaire doit comprendre, pour chaque donnée de titulaire de carte stockée (fichier, tableau, etc.) : une liste de tous les éléments des données de titulaire de carte stockées; la méthode de sécurisation des données; la méthode de journalisation de l'accès au stockage de données. Une liste du matériel et des logiciels essentiels en usage dans l'environnement des données de titulaire de carte, ainsi qu'une description de la fonction/utilisation de chacun d'eux. Une liste des prestataires de services et autres tiers avec qui l'entité partage des données de titulaire de carte. Remarque : ces entités sont assujetties à l'exigence 12.8 des normes PCI DSS. Une liste des produits d'application de paiement de tiers et des numéros de versions en usage, notamment si chaque application de paiement a été validée conformément à la norme PA-DSS. Même si une application de paiement a été validée comme conforme à la norme PA-DSS, l'évaluateur doit encore vérifier que l'application a été mise en œuvre de manière, et dans un environnement, conformes aux normes PCI DSS, et conformément au Guide de mise en œuvre de la norme PA-DSS du fournisseur d'applications de paiement. Remarque : l'utilisation d'applications validées conformes à la norme PA-DSS n'est pas une exigence des normes PCI DSS. Consulter chaque marque de carte de paiement individuellement pour comprendre leurs exigences PA-DSS. Une liste des individus interrogés, leurs organisations, leurs titres et les sujets couverts. Liste de la documentation vérifiée Pour les examens des prestataires de services gérés (MSP), l'évaluateur doit clairement identifier quelles exigences de ce document s'appliquent au MSP concerné (et sont prises en compte dans la vérification), et celles qui ne sont pas comprises dans la vérification, et qu'il incombe aux clients du MSP de joindre dans leurs vérifications. Joindre les renseignements concernant les adresses IP du MSP faisant l'objet d'une analyse dans le cadre des analyses de vulnérabilité trimestrielles du MSP, et indiquer les adresses IP qu'il incombe aux clients du MSP de joindre dans leurs propres analyses trimestrielles. Copyright 2010 PCI Security Standards Council LLC Page 17

18 4. Coordonnées et date du rapport Joindre : les coordonnées des commerçants ou prestataires de services et de l'évaluateur; le calendrier d'évaluation préciser la durée et la période auxquelles l'évaluation a lieu; la date du rapport. 5. Résultats de l'analyse trimestrielle Récapituler les quatre résultats d'analyses ASV (prestataire de services d'analyse agréé) trimestrielles les plus récents dans le résumé ainsi que dans les comme de l'exigence Remarque : il n'est pas nécessaire que quatre analyses trimestrielles soient réalisées pour la conformité aux normes PCI DSS initiale si l'évaluateur vérifie que : 1) le plus récent résultat d'analyse a été une analyse réussie, 2) l'entité a documenté les politiques et procédures nécessitant une analyse trimestrielle, 3) les vulnérabilités notées dans l'analyse initiale ont été corrigées, comme confirmé par une nouvelle analyse. Lors des années suivant la vérification PCI DSS initiale, quatre analyses trimestrielles doivent être réalisées. L'analyse doit couvrir toutes les adresses IP accessibles depuis l'extérieur (interface Internet) existant chez l'entité, conformément au Guide du programme du prestataire de services d'analyses agréé (ASV) de PCI. 6. Conclusions et observations Récapituler dans le résumé les conclusions qui pourraient ne pas être compatibles avec le format du modèle standard de rapport sur la conformité. Tous les évaluateurs doivent : utiliser le modèle détaillé des conditions et procédures de sécurité PCI DSS pour fournir des descriptions et des conclusions de rapport détaillé sur chaque exigence et section d'une exigence; s'assurer que toutes les réponses sans objet (S.O.) sont clairement expliquées; examiner et documenter les contrôles compensatoires envisagés pour conclure qu'un contrôle est en. Voir la section«contrôles compensatoires» ci-dessus et les annexes B et C pour plus de détails concernant les contrôles compensatoires. Revalidation des éléments en instance Un rapport de «contrôles en» est nécessaire pour vérifier la conformité. Le rapport est considéré non conforme s'il contient des «éléments en instance», ou des éléments qui se termineront à une date ultérieure. Le commerçant/prestataire de services doit traiter ces éléments avant la fin de la validation. Une fois que des éléments ouverts sont traités par le commerçant/prestataire de services, l'évaluateur doit alors réévaluer pour valider la correction et garantir que toutes les exigences ont été satisfaites. Après la revalidation, l'évaluateur émet un nouveau rapport sur la Copyright 2010 PCI Security Standards Council LLC Page 18

19 conformité, vérifiant que l'environnement des données de titulaires de carte est entièrement conforme, et le soumet conformément aux instructions (voir ci-dessous). Étapes de mise en conformité avec les normes PCI DSS 1. Remplir le rapport sur la conformité (ROC) conformément à la section ci-dessus intitulée «Instructions et contenu du rapport sur la conformité». 2. S'assurer qu'une ou plusieurs analyses réussies des vulnérabilités ont été réalisées par un prestataire de services d analyse agréé (ASV) par le PCI SSC et se procurer des preuves de l exécution de ces analyses auprès de l'asv. 3. Remplir l'attestation de conformité pour les prestataires de services ou les commerçants, le cas échéant, dans son intégralité. Les attestations de conformité sont disponibles sur le site Web du PCI SSC ( 4. Envoyez le ROC, le justificatif d analyse réussie et l attestation de conformité, avec un quelconque autre document requis, à l'acquéreur (pour les commerçants) ou à la marque de carte de paiement ou à tout autre demandeur (pour les prestataires de services). Copyright 2010 PCI Security Standards Council LLC Page 19

20 Conditions et procédures d évaluation de sécurité détaillées des normes PCI DSS Pour les conditions et procédures de sécurité PCI DSS, l'élément suivant définit les en-têtes de colonnes du tableau : Exigences PCI DSS Cette colonne définit les normes de sécurités des données et répertorie les exigences de conformité aux normes PCI DSS; la conformité sera validé en fonction de ces exigences. Procédures de test Cette colonne montre les processus à suivre par l'évaluateur afin de valider que les exigences PCI DSS sont «en». En Cette colonne doit être utilisée par l'évaluateur pour fournir une brève description des contrôles qui ont été validés comme «en» pour chaque exigence, y compris des descriptions de contrôles jugés en à la suite de contrôles compensatoires ou à la suite d'une exigence «Sans objet». Remarque : cette colonne ne doit pas être utilisée pour des contrôles qui ne sont pas encore en ou pour des éléments en instance à terminer à une date future. Cette colonne doit être utilisée par l'évaluateur pour fournir une brève description des contrôles qui ne sont pas en. Noter qu'un rapport non conforme ne doit pas être soumis à une marque de carte de paiement ou à un acquéreur, sauf sur demande spécifique. Pour plus de renseignements sur les rapports non conformes, se reporter aux attestations de conformité disponibles sur le site Web du PCI SSC ( Pour ces contrôles qui ne sont «pas en», l'évaluateur peut indiquer une date cible à laquelle le commerçant ou le prestataire de services doivent avoir ces contrôles «en». Des notes ou comme suppléme peuvent également être joints ici. Copyright 2010 PCI Security Standards Council LLC Page 20

21 Création et gestion d un réseau sécurisé Exigence 1 : installer et gérer une configuration de pare-feu pour protéger les données de titulaire de carte Les pare-feu sont des dispositifs qui contrôlent le trafic autorisé d'un ordinateur entre les réseaux d'une entité (internes) et les réseaux non approuvés (externes), ainsi que le trafic entrant et sortant dans des zones plus sensibles du réseau interne approuvé d'une entité. L'environnement des données de titulaire de carte est un exemple de zone plus sensible au sein du réseau approuvé d'une entité. Un pare-feu examine l'ensemble du trafic réseau et bloque les transmissions qui ne satisfont pas aux critères de sécurité définis. Tous les systèmes doivent être protégés contre les accès non autorisés depuis des réseaux non approuvés, que ce soit en entrée du système par Internet, comme le commerce électronique, l'accès des employés à Internet à partir de leurs navigateurs, l'accès des employés à la messagerie électronique, les connexions dédiées telles que les connexions interentreprises, ou par les réseaux sans fil ou d'autres sources. Les chemins d'accès de/vers des réseaux non approuvés, en apparence insignifiants, peuvent souvent constituer des chemins d'accès non protégés à des systèmes critiques. Les pare-feu sont des mécanismes de protection essentiels sur un réseau informatique. D'autres composants du système peuvent fournir une fonctionnalité pare-feu, à condition qu'ils respectent les exigences minimales pour les parefeu comme prévu dans l'exigence 1. Lorsque d'autres composants du système sont utilisés au sein d'un environnement de données de titulaire de carte pour fournir une fonctionnalité de pare-feu, ces dispositifs doivent être compris dans la portée et l'évaluation de l'exigence 1. Exigences PCI DSS Procédures de test En 1.1 Définir des normes de configuration des pare-feu et des routeurs, y compris ce qui suit : Processus formel d'approbation et de test de toutes les connexions réseau et des changements apportés aux configurations des pare-feu et des routeurs Schéma du réseau actuel indiquant toutes les connexions aux données de titulaire de carte, notamment tous les réseaux sans fil Exigences d'un pare-feu au niveau de chaque connexion Internet et entre une zone démilitarisée (DMZ) et 1.1 Obtenir et inspecter les normes de configuration des pare-feu et des routeurs et toute autre documentation spécifiée ci-dessous pour vérifier que les normes sont remplies. Remplir les éléments suivants : Vérifier qu'il existe un processus formel d'approbation et de test de toutes les connexions réseau et des changements apportés aux configurations des pare-feu et des routeurs a Vérifier qu'un schéma de réseau actuel (par exemple, montrant les flux de données de titulaire de carte sur le réseau) existe et qu'il documente toutes les connexions aux données de titulaire de carte, y compris les réseaux sans fil b Vérifier que le schéma est tenu à jour a Vérifier que les normes de configuration des pare-feu comprennent les exigences d'un pare-feu à chaque connexion Internet et entre une DMZ et la zone de réseau interne. Copyright 2010 PCI Security Standards Council LLC Page 21

22 Exigences PCI DSS Procédures de test En la zone de réseau interne Description des groupes, des rôles et des responsabilités pour la gestion logique des composants de réseau Documentation et justification professionnelle de l'utilisation de tous les services, protocoles et ports autorisés, y compris la documentation des fonctions de sécurité mises en œuvre pour les protocoles considérés comme étant non sécurisés. Des exemples de services, protocoles, ou ports non sécurisés comprennent, mais sans s'y limiter, FTP, Telnet, POP3, IMAP et SNMP Exigence d'un examen des règles des pare-feu et des routeurs au moins tous les six mois 1.2 Établir des configurations de pare-feu et de routeurs qui restreignent les connexions entre les réseaux non approuvés et les composants du système dans l'environnement des données de titulaire de carte. 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é Restreindre le trafic entrant et sortant au trafic nécessaire à l'environnement des données de b Vérifier que le schéma de réseau actuel est cohérent avec les normes de configuration de pare-feu Vérifier que les normes de configuration des pare-feu et des routeurs comprennent une description des groupes, des rôles et des responsabilités pour la gestion logique des composants de réseau a Vérifier que les normes de configuration des pare-feu et des routeurs comprennent une liste documentée des services, protocoles et ports nécessaires à l'activité par exemple, le protocole de transfert hypertexte (HTTP), le protocole SSL, le protocole SSH, et les protocoles de réseaux privés virtuels (VPN) b Identifier les services, protocoles et ports autorisés non sécurisés et vérifier qu'ils sont nécessaires et que les fonctions de sécurité sont documentées et mises en œuvre, en inspectant les normes de configuration des pare-feu et des routeurs et les paramétrages pour chaque service a Vérifier que les normes de configuration des pare-feu et des routeurs exigent un examen des règles des pare-feu et des routeurs au moins tous les six mois b Obtenir et examiner la documentation pour vérifier que les règles sont examinées au moins tous les six mois. 1.2 Examiner les configurations de pare-feu et de routeurs pour vérifier que les connexions sont restreintes entre les réseaux non approuvés et les composants du système dans l'environnement des données de titulaire de carte, comme suit : a Vérifier que le trafic entrant et sortant est restreint au trafic nécessaire à l'environnement des données de titulaire de carte, et que ces restrictions sont documentées. Copyright 2010 PCI Security Standards Council LLC Page 22

23 Exigences PCI DSS Procédures de test En titulaire de carte Sécuriser et synchroniser les fichiers de configuration des routeurs Installer des pare-feu de périmètre entre les réseaux sans fil et l environnement des données de titulaire de carte, et configurer ces parefeu 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 de titulaire de carte. 1.3 Interdire l'accès public direct entre Internet et les composants du système dans l'environnement des données de titulaire de carte Mettre en œuvre une DMZ pour limiter le trafic entrant aux seuls composants du système qui fournissent les services, les protocoles, et les ports autorisés accessibles au public Limiter le trafic Internet entrant aux adresses IP dans la zone démilitarisée N'autoriser aucune connexion directe entrante ou sortante du trafic entre Internet et l'environnement des b Vérifier que tout autre trafic entrant et sortant est spécifiquement refusé, par exemple en utilisant un paramètre «refuser tout» explicite ou un refus implicite après une autorisation Vérifier que les fichiers de configuration des routeurs sont sécurisés et synchronisés par exemple, les fichiers de configuration de l'exécution (utilisés pour une exécution normale des routeurs) et les fichiers de configuration de démarrage (utilisés lorsque les dispositifs sont redémarrés), ont les mêmes configurations sécurisées Vérifier qu'il existe des pare-feu de périmètre installés entre les réseaux sans fil et les systèmes qui stockent les données de titulaire de carte, et que ces pare-feu refusent ou contrôlent le trafic (si celui-ci est nécessaire à des fins professionnelles) de l environnement sans fil vers l environnement des données de titulaire de carte. 1.3 Examiner les configurations des pare-feu et des routeurs y compris, mais sans s'y limiter, le routeur-goulet sur Internet, le routeur et le pare-feu dans la zone démilitarisée (DMZ), le segment de titulaire de carte dans la DMZ, le routeur de périmètre, et le segment interne de réseau de titulaire de carte pour déterminer qu'il n'existe aucun accès direct entre Internet et les composants du système dans le segment interne de réseau de titulaire de carte, comme détaillé ci-dessous Vérifier qu'une DMZ est mise en œuvre pour limiter le trafic entrant aux seuls composants du système qui fournissent les services, les protocoles, et les ports autorisés accessibles au public Vérifier que le trafic Internet entrant est limité aux adresses IP dans la zone démilitarisée Vérifier que les connexions entrantes ou sortantes directes du trafic ne sont pas autorisées entre Internet et l'environnement Copyright 2010 PCI Security Standards Council LLC Page 23