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

24 Exigences PCI DSS Procédures de test En données de titulaire de carte Ne pas autoriser le passage d'adresses internes d'internet à la zone démilitarisée Ne pas autoriser le trafic sortant non autorisé de l'environnement des données de titulaire de carte vers Internet Mettre en œuvre le contrôle avec état, également appelé «filtrage dynamique à paquets». (Seules les connexions «établies» sont autorisées sur le réseau) Placer les composants du système qui stockent les données de titulaire de carte (comme une base de données) dans une zone de réseau interne, distincte de la zone démilitarisée et d'autres réseaux non approuvés Ne pas divulguer les adresses IP et les renseignements d'acheminement aux parties non approuvées. Remarque : les méthodes pour rendre les adresses IP illisibles peuvent comprendre, mais sans s'y limiter : des données de titulaire de carte Vérifier que les adresses internes ne sont pas autorisées à passer d'internet à la zone démilitarisée Vérifier que le trafic sortant de l'environnement des données de titulaire de carte vers Internet est explicitement autorisé Vérifier que le pare-feu exécute le contrôle avec état (filtrage dynamique à paquets). (Seules les connexions établies doivent être autorisées, et uniquement si elles sont associées à une session préalablement établie) Vérifier que les composants du système qui stockent les données de titulaire de carte se trouvent dans une zone de réseau interne, distincte de la zone démilitarisée et d'autres réseaux non approuvés a Vérifier que les méthodes sont en pour empêcher la divulgation d'adresses IP privées et de renseignements d'acheminement des réseaux internes vers Internet. Copyright 2010 PCI Security Standards Council LLC Page 24

25 Exigences PCI DSS Procédures de test En la traduction d'adresse de réseau (NAT); la mise en de serveurs contenant des données de titulaire de carte derrière des serveurs/pare-feu proxy ou des caches de contenu; l'enlèvement ou le filtrage des avertissements d'acheminement pour les réseaux privés qui emploient des adresses enregistrées; l'usage interne de l'espace adresse RFC1918 au lieu d'adresses enregistrées. 1.4 Installer un logiciel pare-feu personnel sur un ordinateur portable et/ou ordinateur appartenant à un employé équipé d'une connexion directe à Internet (par exemple, ordinateurs portables utilisés par les employés), utilisé pour accéder au réseau de l'entreprise b Vérifier que la divulgation d'adresses IP privées et de renseignements d'acheminement aux entités externes est autorisée. 1.4.a Vérifier qu'un ordinateur portable et/ou ordinateur appartenant à un employé équipé d'une connexion directe à Internet (par exemple, ordinateurs portables utilisés par les employés), utilisé pour accéder au réseau de l'entreprise, possède un logiciel pare-feu personnel installé et actif. 1.4.b Vérifier que le logiciel pare-feu personnel est configuré par l'entreprise aux normes spécifiques et ne peut pas être altéré par les utilisateurs d'ordinateurs portables et/ou ordinateurs appartenant à un employé. Copyright 2010 PCI Security Standards Council LLC Page 25

26 Exigence 2 : fournisseur Ne pas utiliser les mots de passe système et autres paramètres de sécurité par défaut définis par le Les individus malveillants (externes ou internes à l'entité), utilisent souvent les mots de passe et autres paramètres par défaut définis par le fournisseur pour s'infiltrer dans les systèmes en vue de les endommager. Ces mots de passe et paramètres sont bien connus des communautés de pirates informatiques et sont facilement déterminés par des renseignements publics. Exigences PCI DSS Procédures de test En 2.1 Changer systématiquement les paramètres par défaut définis par le fournisseur avant d'installer un système sur le réseau, y compris, mais sans s'y limiter, les mots de passe et les protocoles de gestion de réseau simples (SNMP), et éliminer les comptes qui ne sont pas nécessaires Pour les environnements sans fil connectés à l'environnement des données de titulaire de carte ou la transmission de données de titulaire de carte, modifier les paramètres par défaut définis par le fournisseur des équipements sans fil, y compris, mais sans s'y limiter, les clés de cryptage sans fil, les mots de passe et les chaînes de communauté SNMP par défaut. 2.1 Choisir un échantillon de composants du système, et tenter de se connecter (avec l'aide de l'administrateur du système) aux dispositifs utilisant des comptes et des mots de passe définis par le fournisseur, pour vérifier que ces comptes et mots de passe par défaut ont bien été changés (Utiliser les manuels du fournisseur et les sources sur Internet pour trouver les comptes/mots de passe définis par le fournisseur) Vérifier les éléments suivants concernant les paramètres par défaut du fournisseur pour les environnements sans fil : a Vérifier que les clés de cryptage ont été changées, par rapport aux paramètres par défaut à l'installation, et sont changées chaque fois que quelqu'un ayant connaissance de ces clés quitte la société ou change de poste b Vérifier que les chaînes de communauté SNMP par défaut sur les dispositifs sans fil ont été changées c Vérifier que les mots de passe/phrases passe par défaut sur les points d'accès ont été changés d Vérifier que le micrologiciel sur les dispositifs sans fil est mis à jour pour prendre en charge le cryptage de l'authentification et de la transmission sur les réseaux sans fil e Vérifier que les valeurs par défaut du fournisseur de dispositif sans fil, relatives à la sécurité, ont été changées, le cas échéant. Copyright 2010 PCI Security Standards Council LLC Page 26

27 Exigences PCI DSS Procédures de test En 2.2 Élaborer des normes de configuration pour tous les composants du système. S'assurer que ces normes couvrent toutes les vulnérabilités de la sécurité et sont compatibles avec toutes les normes renforçant les systèmes en vigueur dans le secteur. Les sources des normes renforçant les systèmes, en vigueur dans le secteur, peuvent comprendre, mais sans s'y limiter : le centre de sécurité Internet (CIS); l'organisation internationale de normalisation (ISO); l'institut SANS (SysAdmin Audit Network Security); l'institut national des normes et de la technologie (NIST) Mettre en œuvre uniquement une fonction primaire par serveur pour empêcher les fonctions nécessitant différents niveaux de sécurité de coexister sur le même serveur (par exemple, les serveur Web, les serveurs de base de données, et les serveurs de nom de domaine (DNS) doivent être mis en œuvre sur des serveurs séparés). Remarque : lorsque les technologies de virtualisation sont en cours d'utilisation, mettre en œuvre uniquement une fonction primaire par composant du système virtuel. 2.2.a Examiner les normes de configuration du système de l'organisation pour tous les types de composants du système et vérifier que les normes de configuration du système sont cohérentes avec les normes renforçant les systèmes en vigueur dans le secteur. 2.2.b Vérifier que les normes de configuration du système sont mises à jour et que les nouvelles vulnérabilités sont identifiées, comme défini dans l'exigence c Vérifier que les normes de configuration du système sont appliquées lorsque de nouveaux systèmes sont configurés. 2.2.d Vérifier que les normes de configuration du système comprennent chaque élément ci-dessous (2.2.1 à 2.2.4) a Pour un échantillon de composants du système, vérifier que seule une fonction primaire est mise en œuvre par serveur b Si des technologies de virtualisation sont utilisées, vérifier que seule une fonction primaire est mise en œuvre par composant du système ou par dispositif virtuels. n taires Copyright 2010 PCI Security Standards Council LLC Page 27

28 Exigences PCI DSS Procédures de test En Activer uniquement les services, protocoles, démons, etc. nécessaires et sécurisés, exigés pour la fonction du système. Mettre en œuvre les fonctions de sécurité pour chaque service, protocole ou démon exigés, considérés comme non sécurisés par exemple, utiliser des technologies sécurisées comme SSH, S-FTP, SSL ou IPSec VPN pour protéger les services non sécurisés comme NetBIOS, le partage de fichier, Telnet, FTP, etc Configurer les paramètres de sécurité du système pour empêcher les actes malveillants Supprimer toutes les fonctionnalités qui ne sont pas nécessaires, comme les scripts, pilotes, fonctions, sous-systèmes, systèmes de fichiers et serveurs Web superflus a Pour un échantillon de composants du système, inspecter les services, démon et protocoles de système activés. Vérifier que seuls les services et protocoles nécessaires sont activés b Identifier chaque service, démon ou protocole non sécurisé désactivé. Vérifier qu'ils soient justifiés et que les fonctions de sécurité sont documentées et mises en œuvre a S'entretenir avec les administrateurs du système et/ou les responsables de la sécurité pour vérifier qu'ils ont connaissance des réglages de paramètres de sécurité communs pour les composants du système b Vérifier que les réglages de paramètres de sécurité communs sont compris dans les normes de configuration du système c Pour un échantillon de composants du système, vérifier que les paramètres de sécurité communs sont définis de manière appropriée a Pour un échantillon de composants du système, vérifier que toutes les fonctionnalités qui ne sont pas nécessaires (par exemple scripts, pilotes, fonctions, sous-systèmes, systèmes de fichier etc.) sont supprimées b. Vérifier que les fonctions activées sont documentées et prennent en charge une configuration sécurisée c. Vérifier que seule la fonctionnalité documentée est présente dans les composants du système échantillonnés. n taires Copyright 2010 PCI Security Standards Council LLC Page 28

29 Exigences PCI DSS Procédures de test En 2.3 Crypter tous les accès administratifs non-console en utilisant une cryptographie performante. Utiliser des technologies telles que SSH, VPN ou SSL/TLS pour la gestion par le Web et autres accès administratifs nonconsole. 2.4 Les fournisseurs d'hébergement partagé doivent protéger l'environnement hébergé et les données de titulaire de carte de chaque entité. Ces fournisseurs doivent satisfaire aux exigences spécifiques décrites dans l'annexe A : Autres exigences des PCI DSS s appliquant aux fournisseurs d hébergement partagé. 2.3 Pour un échantillon de composants du système, vérifier que l'accès administratif non-console est crypté en exécutant les éléments suivants : 2.3.a Observer la connexion d'un administrateur à chaque système pour vérifier qu'une méthode de cryptage performante est utilisée avant que le mot de passe de l'administrateur ne soit exigé. 2.3.b Vérifier les fichiers de services et de paramètres sur les systèmes pour établir que Telnet et d'autres commandes de connexion à distance ne sont pas disponibles pour un usage interne. 2.3.c Vérifier que l'accès de l'administrateur aux interfaces de gestion basées sur le Web est crypté avec une cryptographie performante. 2.4 Exécuter les procédures de test de A.1.1 à A.1.4 détaillées dans l'annexe A : Autres exigences des normes PCI DSS s'appliquant aux fournisseurs d'hébergement partagé pour les évaluations PCI DSS de ces fournisseurs, afin de vérifier que ces derniers protègent l'environnement et les données partagées de leurs entités (commerçants et prestataires de services). n taires Copyright 2010 PCI Security Standards Council LLC Page 29

30 Protection des données de titulaire de carte de crédit Exigence 3 : Protéger les données de titulaire de carte stockées Les méthodes de protection, telles que le cryptage, la troncature, le masquage et le hachage, sont des composants essentiels de la protection des données de titulaire de carte. Si un intrus parvient à contourner les autres contrôles de sécurité et à accéder aux données cryptées, il ne pourra pas les lire ni les utiliser s'il n'a pas les clés cryptographiques appropriées. D'autres méthodes efficaces de protection des données stockées doivent être envisagées pour limiter les risques. Par exemple, les méthodes pour réduire au minimum les risques comprennent de ne pas stocker les données de titulaire de carte à moins que cela ne soit absolument nécessaire, de tronquer les données de titulaire de carte si un numéro de compte principal (PAN) complet n'est pas requis et de ne pas envoyer un PAN non protégé en utilisant des technologies de messagerie pour les utilisateurs finaux, comme des courriels et une messagerie instantanée. Pour obtenir la définition d une «cryptographie performante» et d'autres termes relatifs à PCI DSS, consultez le Glossaire des termes, abréviations et acronymes PCI DSS et PA-DSS. Exigences PCI DSS Procédures de test En 3.1Réduire le stockage des données de titulaire de carte au minimum en mettant en des politiques, des procédures et des processus de conservation et d'élimination des données comme suit Mettre en œuvre une politique de conservation et d'élimination des données qui comprend : la limitation de la quantité des données stockées et des délais de conservation aux conditions requises par la loi, les réglementations, et l'entreprise; les processus de suppression des données qui ne sont plus nécessaires; les exigences de conservation spécifiques aux données de titulaire 3.1 Obtenir et examiner les politiques, les procédures et les processus pour la conservation et l'élimination des données, et effectuer ce qui suit : a Vérifier que des politiques et procédures sont mises en œuvre et comprennent des exigences légales, régleme et commerciales pour la conservation des données, notamment des exigences spécifiques, relatives à la conservation de données de titulaire de carte (par exemple, les données de titulaire de carte doivent être détenues durant une période X ou pour des raisons commerciales Y) b Vérifier que les politiques et procédures comprennent des dispositions relatives à l'élimination sécurisée des données lorsqu'il n'existe plus de raison légale, réglementaire ou commerciale, y compris pour les données de titulaire de carte c Vérifier que les politiques et procédures comprennent le stockage de toutes les données de titulaire de carte. Copyright 2010 PCI Security Standards Council LLC Page 30

31 Exigences PCI DSS Procédures de test En de carte; un processus trimestriel automatique ou manuel pour identifier et supprimer de manière sécurisée les données de titulaire de carte stockées qui dépassent les exigences de conservation définies. 3.2 Ne stocker aucune donnée d'authentification sensible après autorisation (même cryptée). Les données d'authentification sensibles concernées sont mentionnées dans les exigences à suivantes : Remarque : il est permis aux émetteurs et sociétés, qui prennent en charge les services d'émission, de stocker des données d'authentification sensibles s'il existe une justification commerciale et que ces données sont stockées de manière sécurisée d Vérifier que les politiques et procédures comprennent au moins l'un des éléments suivants : un processus pragmatique (automatique ou manuel) destiné à supprimer, au moins chaque trimestre, les données de titulaire de carte stockées qui dépassent les exigences définies dans la politique de conservation des données; des exigences pour une vérification, au moins trimestrielle, afin de vérifier que les données de titulaire de carte stockées ne dépassent pas les exigences définies dans la politique de conservation des données e Pour un échantillon de composants du système qui stockent des données de titulaire de carte, vérifier que les données stockées ne dépassent pas les exigences définies dans la politique de conservation des données. 3.2.a Pour les émetteurs et/ou sociétés qui prennent en charge les services d'émissions et stockent des données d'authentification sensibles, vérifier qu'il existe une justification commerciale au stockage de ces données, et que ces dernières sont sécurisées. 3.2.b Pour toutes les autres entités, si des données d'authentification sensibles sont reçues et supprimées, obtenir et examiner le processus de suppression sécurisée des données pour vérifier que les données sont irrécupérables. 3.2.c Pour chaque élément de données d'authentification sensibles ci-dessous, exécuter les étapes suivantes : Copyright 2010 PCI Security Standards Council LLC Page 31

32 Exigences PCI DSS Procédures de test En Ne jamais stocker la totalité du contenu d une quelconque piste (de la bande magnétique au verso d'une carte, de données équivalentes sur une puce ou d'ailleurs). Ces données sont également désignées piste complète, piste, piste 1, piste 2 et données de bande magnétique. Remarque : dans le cadre normal de l'activité, il est parfois nécessaire de conserver les éléments de données de la bande magnétique ci-après : le nom du titulaire de la carte; le numéro de compte principal (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é Pour un échantillon de composants du système, examiner les sources de données, y compris les suivantes, mais sans s'y limiter, et vérifier que la totalité du contenu d'une quelconque piste de bande magnétique au verso d'une carte ou de données équivalentes sur une puce, ne sont stockées en aucun cas : données de transaction entrantes ; tous les journaux (par exemple, transactions, historique, débogage, erreur) ; fichiers d'historique ; fichiers trace ; plusieurs schémas de base de données; contenu des bases de données Ne pas stocker le code ou la valeur de validation de la carte (nombre à trois ou quatre chiffres figurant au recto ou au verso de la carte de paiement), utilisé pour vérifier les transactions en carte absente Ne pas stocker de numéro d'identification personnel (NIP) ou de Pour un échantillon de composants du système, examiner les sources de données, y compris les suivantes, mais sans s'y limiter, et vérifier que le code ou la valeur de validation de la carte à trois ou à quatre chiffres imprimé sur le devant de la carte ou dans l'espace signature (données CVV2, CVC2, CID, CAV2) n'est stocké en aucun cas : données de transaction entrantes ; tous les journaux (par exemple, transactions, historique, débogage, erreur) ; fichiers d'historique ; fichiers trace ; plusieurs schémas de base de données; contenu des bases de données Pour un échantillon de composants du système, examiner les sources de données, y compris les suivantes, mais sans s'y limiter, et vérifier que les codes et les blocs NIP cryptés ne sont Copyright 2010 PCI Security Standards Council LLC Page 32

33 Exigences PCI DSS Procédures de test En bloc NIP crypté. stockés en aucun cas : données de transaction entrantes ; tous les journaux (par exemple, transactions, historique, débogage, erreur) ; fichiers d'historique ; fichiers trace ; plusieurs schémas de base de données; contenu des bases de données. 3.3 Masquer le PAN lorsqu'il s'affiche (les six premiers chiffres et les quatre derniers sont le maximum de chiffres affichés). Remarques : Cette exigence ne s'applique pas aux employés et autres parties qui ont un besoin professionnel légitime de voir l'intégralité du PAN. Cette exigence ne se substitue pas aux exigences plus strictes qui sont en et qui régissent l affichage des données de titulaire de carte, par exemple, pour les reçus des points de vente (POS). 3.4 Rendre le PAN illisible partout où il est stocké (y compris sur support numérique portable, support de sauvegarde et journaux), en utilisant l'une des approches suivantes : hachage unilatéral s'appuyant sur une méthode cryptographique performante (le PAN entier doit être haché); troncature (le hachage ne peut pas être utilisé pour remr le segment tronqué du PAN) 3.3 Obtenir et examiner les politiques écrites et examiner les affichages du PAN (par exemple, sur un écran ou un reçu papier) pour vérifier que les PAN sont masqués lors de l'affichage des données de titulaire de carte, excepté pour les personnes ayant un besoin professionnel légitime de voir le PAN complet. 3.4.a Obtenir et examiner la documentation concernant le système utilisé pour protéger le PAN, notamment les algorithmes du fournisseur, du type de système/processus, et de cryptage (le cas échéant). Vérifier que le PAN est rendu illisible en utilisant l'une des méthodes suivantes : hachage unilatéral s appuyant sur une méthode cryptographique robuste ; troncature ; index des jetons et pads, les pads devant être stockés de manière sécurisée; cryptographie performante associée à des processus et des procédures de gestion des clés. Copyright 2010 PCI Security Standards Council LLC Page 33

34 Exigences PCI DSS Procédures de test En index des jetons et pads (les pads doivent être stockés de manière sécurisée); cryptographie performante associée à des processus et des procédures de gestion des clés. Remarque : il s'agit d'un effort relativement mineur pour un individu malveillant de reconstruire les données du PAN d'origine s'il possède à la fois l'accès à la version tronquée et hachée d'un PAN. Lorsque les versions hachée et tronquée du même PAN sont présentes dans l'environnement d'une entité, des contrôles suppléme doivent être en pour assurer que les versions hachée et tronquée ne peuvent pas être corrélées pour la reconstruction du PAN original Si un cryptage par disque est utilisé (au lieu d'un cryptage de base de données au niveau fichier ou colonne), l'accès logique doit être géré indépendamment des mécanismes de contrôle d'accès au système d'exploitation natif (par exemple, en n'utilisant pas les bases de données de comptes d'utilisateur locales). Les clés de décryptage ne doivent pas être liées à des comptes d'utilisateur. 3.4.b Examiner plusieurs tableaux ou fichiers à partir d'un échantillon de référentiels de données pour vérifier que le PAN est rendu illisible (c'est à dire, non stocké en texte clair). 3.4.c Examiner un échantillon de support amovible (par exemple, des bandes de sauvegarde) pour confirmer que le PAN est rendu illisible. 3.4.d Examiner un échantillon de journaux de vérification pour confirmer que le PAN est rendu illisible ou supprimé des journaux a Si un cryptage par disque est utilisé, vérifier que l'accès logique aux systèmes de fichiers cryptés est mis en œuvre par un mécanisme qui est distinct du mécanisme des systèmes d'exploitation natifs (par exemple, en n'utilisant pas les bases de données locales de comptes utilisateurs) b Vérifier que les clés cryptographiques sont stockées de manière sécurisée (par exemple, stockée sur des supports amovibles qui sont adéquatement protégés avec des contrôles d'accès stricts) c Vérifier que les données du titulaire de carte sur support amovible sont cryptées à l'endroit où elles sont stockées. Remarque : si un cryptage par disque n'est pas utilisé pour crypter un support amovible, les données stockées sur ce support devront être rendues illisibles par une autre méthode. Copyright 2010 PCI Security Standards Council LLC Page 34

35 Exigences PCI DSS Procédures de test En 3.5 Protéger les clés utilisées pour sécuriser des données de titulaire de carte contre la divulgation et l'utilisation illicites : Remarque : cette exigence s'applique également aux clés de cryptage de clés utilisées pour protéger les clés de cryptage de données de telles clés de cryptage de clés doivent être au moins aussi performantes que la clé de cryptage de données Restreindre l'accès aux clés cryptographiques au plus petit nombre d'opérateurs possible Stocker les clés cryptographiques de manière sécurisée dans aussi peu d'emments et de formes que possible. 3.6 Documenter en détail et mettre en œuvre tous les processus et les procédures de gestion des clés cryptographiques servant au cryptage des données de titulaire de carte, notamment ce qui suit : Remarque : de nombreuses normes du secteur pour la gestion de clés sont disponibles sur diverses ressources, y compris la publication NIST. sur le site Générer des clés cryptographiques performantes 3.5 Vérifier les processus pour protéger les clés utilisées pour le cryptage de données de titulaire de carte contre la divulgation et le mauvais usage en effectuant ce qui suit : Examiner les listes d'accès utilisateur pour vérifier que l'accès aux clés est restreint au plus petit nombre d'opérateurs possible b Examiner les fichiers de configuration du système pour vérifier que les clés sont stockées en format crypté et que les clés de cryptage de clés sont stockées séparément des clés de cryptage des données b Identifier les emments de stockage pour vérifier que les clés sont stockées dans le minimum d'emments et de formes possible. 3.6.a Vérifier l'existence de procédures de gestion de clés pour les clés servant au cryptage des données de titulaire de carte. 3.6.b Pour les prestataires de services uniquement : si le prestataire de services partage des clés avec ses clients pour la transmission ou le stockage des données de titulaire de carte, vérifier que le prestataire de services fournit une documentation aux clients qui comprend des directives sur la manière de transmettre, de stocker ou de mettre à jour de façon sécurisée les clés du client, conformément aux exigences à ci-dessous. 3.6.c Examiner les procédures de gestion des clés et effectuer ce qui suit : Vérifier que des procédures de gestion de clés sont mises en œuvre pour exiger la génération de clés performantes. Copyright 2010 PCI Security Standards Council LLC Page 35

36 Exigences PCI DSS Procédures de test En Sécuriser la distribution des clés cryptographiques Sécuriser le stockage des clés cryptographiques Changement de clé cryptographique pour les clés qui ont atteint la fin de leur cryptopériode (par exemple, après une période définie écoulée et/ou après qu'une certaine quantité de cryptogramme a été produite par une clé donnée), comme défini par le fournisseur d'applications associées ou le propriétaire de la clé, et basé sur les meilleures pratiques et directives du secteur (par exemple, publication spéciale NIST ) Retrait ou remment (par exemple, l'archivage, la destruction, et/ou la révocation) des clés si nécessaire, lorsque l'intégrité de la clé a été affaiblie (par exemple, le départ d'un employé ayant connaissance d'une clé en texte clair, etc.), ou que les clés sont suspectées d'être compromises. Remarque : si les clés cryptographiques retirées ou remplacées doivent être conservées, ces clés doivent être archivées de manière sécurisée (par exemple, en utilisant une clé de cryptage de clé). Les clés cryptographiques archivées doivent être utilisées uniquement à des fins de décryptage/vérification Vérifier que des procédures de gestion de clés sont mises en œuvre pour exiger la distribution des clés de manière sécurisée Vérifier que des procédures de gestion de clés sont mises en œuvre pour exiger le stockage des clés de manière sécurisée Vérifier que des procédures de gestion de clés sont mises en œuvre pour exiger les changements de clés à la fin de la cryptopériode définie a Vérifier que des procédures de gestion de clés sont mises en œuvre pour exiger le retrait des clés lorsque l'intégrité de ces clés a été affaiblie b Vérifier que des procédures de gestion de clés sont mises en œuvre pour exiger le remment des clés compromises ou présumées compromises c Si des clés cryptographiques retirées ou remplacées sont conservées, vérifier que ces clés ne sont pas utilisées pour des opérations de cryptage. Copyright 2010 PCI Security Standards Council LLC Page 36

37 Exigences PCI DSS Procédures de test En Si des opérations de gestion manuelle de clés cryptographiques en texte clair sont utilisées, ces opérations doivent être gérées en utilisant le fractionnement de connaissance et le double contrôle (par exemple, la nécessité de deux ou trois personnes, chacune connaissant uniquement sa propre partie de la clé, pour reconstruire la clé entière). Remarque : des exemples d'opérations de gestion manuelle de clés comprennent, mais sans s'y limiter : la génération de clés, la transmission, le chargement, le stockage et la destruction Empêcher la substitution non autorisée des clés cryptographiques Exiger des opérateurs chargés de la gestion de clés cryptographiques de reconnaître qu'ils comprennent et acceptent leurs responsabilités Vérifier que les procédures de gestion manuelle de clés en texte clair exigent un fractionnement des connaissances et un double contrôle des clés Vérifier que des procédures de gestion de clé sont mises en œuvre pour exiger d'empêcher la substitution non autorisée de clés Vérifier que des procédures de gestion de clés sont mises en œuvre pour exiger des opérateurs qu'ils reconnaissent (par écrit ou de manière électronique) qu'ils comprennent et acceptent leurs responsabilités en tant que gestionnaires de clés. Copyright 2010 PCI Security Standards Council LLC Page 37

38 Exigence 4 : Crypter la transmission des données de titulaire de carte sur les réseaux publics ouverts Les renseignements sensibles doivent être cryptés pendant leur transmission sur des réseaux facilement accessibles par des individus malveillants. Les réseaux sans fil mal configurés et les vulnérabilités dans les protocoles traditionnels de cryptage et d'authentification continus d'être les cibles des individus malveillants qui profitent de ces faiblesses pour obtenir un accès privilégié aux environnements des données de titulaire de carte. Exigences PCI DSS Procédures de test En 4.1 Utiliser une cryptographie et des protocoles de sécurité performants (par exemple, SSL/TLS, IPSEC, SSH, etc.) pour protéger les données de titulaire de cartes sensibles lors d'une transmission sur des réseaux publics ouverts. Des exemples de réseaux publics ouverts couverts par les normes PCI DSS comprennent, mais sans s'y limiter : Internet; les technologies sans fil; les communications GSM (Global System for Mobile, réseau mondial de téléphonie mobile); le GPRS (General Packet Radio Service, service général de paquets radio). 4.1 Vérifier l'utilisation de protocoles de sécurité partout où des données de titulaire de carte sont transmises ou reçues sur des réseaux publics ouverts. Vérifier qu'une cryptographie performante est utilisée pour la transmission des données, comme suit : 4.1.a Sélectionner un échantillon de transactions lorsqu'elles sont reçues et observer les transactions pour vérifier que les données de titulaire de carte sont cryptées lors du transit. 4.1.b Vérifier que seuls les clés et/ou certificats approuvés sont acceptés. 4.1.c Vérifier que le protocole est mis en œuvre pour utiliser uniquement les configurations sécurisées et ne pas prendre en charge les versions ou configurations non sécurisées. 4.1.d Vérifier que la puissance de cryptage adéquate est mise en œuvre au regard de la méthodologie de cryptage utilisée. (Vérifier les recommandations du fournisseur/meilleures pratiques). 4.1.e Pour les mises en œuvre SSL/TLS : vérifier que HTTPS apparaît dans l'adresse URL; vérifier qu'aucune donnée de titulaire de carte n'est requise lorsque HTTPS n'apparaît pas dans l'adresse URL. Copyright 2010 PCI Security Standards Council LLC Page 38

39 Exigences PCI DSS Procédures de test En S'assurer que les réseaux sans fil transmettant les données de titulaire de carte ou qui sont connectés à l'environnement des données de titulaire de carte utilisent les meilleures pratiques du secteur (par exemple, IEEE i) pour mettre en œuvre un cryptage performant pour l'authentification et la transmission. Remarque : l'utilisation du protocole WEP comme contrôle de sécurité est interdit depuis le 30 juin Ne jamais envoyer de PAN non cryptés à l'aide de technologies de messagerie pour les utilisateurs finaux (par exemple, courriel, messagerie instantanée, un clavardage, etc.) Pour les réseaux sans fil transmettant les données de titulaire de carte ou qui sont connectés à l'environnement des données de titulaire de carte, vérifier que les meilleures pratiques du secteur (par exemple, IEEE i) sont utilisées pour mettre en œuvre un cryptage performant pour l'authentification et la transmission. 4.2.a Vérifier que le PAN est rendu illisible ou est sécurisé grâce à une cryptographie performante chaque fois qu'il est envoyé par des technologies de messagerie pour les utilisateurs finaux. 4.2.b Vérifier l'existence d'une politique précisant que les PAN non protégés ne doivent pas être envoyés par des technologies de messagerie pour les utilisateur finaux. Copyright 2010 PCI Security Standards Council LLC Page 39

40 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 Des logiciels malicieux, généralement appelés «programmes malveillants», par exemple, des virus, des vers informatiques et des chevaux de Troie, s'infiltrent dans le réseau dans le cadre de nombreuses activités professionnelles approuvées, notamment l'échange de courriels et l'accès à Internet des employés ainsi que l'utilisation de périphériques de stockage et d'ordinateurs portables résultant par l'exploitation des vulnérabilités du système. Des logiciels antivirus doivent être utilisés sur tous les systèmes régulièrement affectés par des programmes malveillants afin de les protéger contre les menaces logicielles actuelles et futures. Exigences PCI DSS Procédures de test En 5.1 Déployer des logiciels antivirus sur tous les systèmes régulièrement affectés par des logiciels malveillants (en particulier les ordinateurs personnels et les serveurs) S'assurer que tous les programmes anti-virus sont capables de détecter, d'éliminer et de protéger contre tous les types de logiciels malveillants connus. 5.2 S'assurer que tous les mécanismes antivirus sont à jour, en cours d'exécution et génèrent des journaux de vérification. 5.1 Pour un échantillon de composants du système comprenant tous les types de systèmes d'exploitation communément affectés par des logiciels malveillants, vérifier qu'un logiciel anti-virus est déployé et, le cas échéant, qu'une technologie anti-virus existe Pour un échantillon de composants du système, vérifier que tous les programmes anti-virus détectent, éliminent et protègent contre les logiciels malveillants (par exemple, les virus, les cheveux de Troie, les vers informatiques, les logiciels espions, les logiciels de publicité et les programmes malveillants furtifs). 5.2Vérifier que le logiciel anti-virus est à jour, en cours d'exécution et génère des journaux en effectuant ce qui suit : 5.2.a Obtenir et examiner la politique et vérifier qu'il est exigé de mettre à jour les logiciels anti-virus de définir le terme virus. 5.2.b Vérifier que l'installation principale du logiciel est activée pour des mises à jour automatiques et des analyses périodiques. 5.2.c Pour un échantillon de composants du système comprenant tous les types de systèmes d'exploitation communément affectés par des logiciels malveillants, vérifier que les mises à jour et les analyses automatiques sont activées. 5.2.d Pour un échantillon de composants du système, vérifier que la génération du journal du logiciel anti-virus est activée et que de tels journaux sont tenus conformément à l'exigence 10.7 des normes PCI DSS. Copyright 2010 PCI Security Standards Council LLC Page 40

41 Exigence 6 : Développer et gérer des systèmes et des applications sécurisés Des individus sans scrupules utilisent les vulnérabilités de la sécurité pour obtenir un accès privilégié aux systèmes. Bon nombre de ces vulnérabilités sont résolues par les correctifs de sécurité développés par les fournisseurs. Ceux-ci doivent être installés par les entités chargées de la gestion des systèmes. Tous les systèmes stratégiques doivent être dotés des correctifs logiciels appropriés les plus récents afin d'empêcher l'exploitation et l'altération des données de titulaire de carte par des individus et des logiciels malveillants. Remarque : Les correctifs logiciels appropriés sont ceux qui ont été suffisamment évalués et testés pour déterminer qu'ils ne présentent aucun conflit avec les configurations de sécurité existantes. De nombreuses vulnérabilités peuvent être évitées dans les applications développées en interne grâce à l'utilisation de processus de développement de système standard et de techniques de codage sécurisé. Exigences PCI DSS Procédures de test En 6.1 S'assurer que tous les logiciels et composants du système sont protégés des vulnérabilités connues en étant dotés des derniers correctifs de sécurité développés par le fournisseur. Installer les correctifs de sécurité essentiels dans le mois qui suit leur commercialisation. Remarque : une entreprise peut envisager la mise en œuvre d'une approche en fonction du risque pour définir la priorité des correctifs à installer. Par exemple, en accordant aux infrastructures essentielles (par exemple, bases de données, périphériques et systèmes orientés public) une priorité supérieure à celle des dispositifs internes moins cruciaux, de sorte que les systèmes et les dispositifs hautement prioritaires soient traités dans un délai d'un mois, tandis que les dispositifs et systèmes moins essentiels le soient dans un délai de trois mois. 6.1.a Pour un échantillon de composants du système et des logiciels connexes, comparer la liste des correctifs de sécurité installés sur chaque système à la liste de correctifs de sécurité du fournisseur la plus récente, pour vérifier que les correctifs du fournisseur à jour sont installés. 6.1.b Examiner les politiques relatives à l'installation des correctifs de sécurité afin de vérifier qu'elles exigent l'installation de tous les nouveaux correctifs de sécurité essentiels dans un délai d'un mois. Copyright 2010 PCI Security Standards Council LLC Page 41

42 Exigences PCI DSS Procédures de test En 6.2 Établir un processus afin d'identifier et attribuer un classement des risques aux vulnérabilités de sécurité récemment découvertes. Remarques : Les classements de risques doivent être basés sur les meilleures pratiques du secteur. Par exemple, les critères pour un classement des vulnérabilités à «haut» risque peuvent comprendre un score de 4.0 ou plus basé sur le CVSS (Common Vulnerability Scoring System, système de notation de vulnérabilité commun), et/ou un correctif proposé et classé par le fournisseur comme «critique», et/ou une vulnérabilité affectant un composant essentiel du système. Le classement des vulnérabilités défini par le point 6.2.a est considéré comme une meilleure pratique jusqu'au 30 juin 2012, après quoi, il deviendra une exigence. 6.3 Développer des applications logicielles (internes et externes, y compris l'accès administratif aux applications basé sur le Web) conformément aux normes PCI DSS (par exemple, l'authentification et la connexion sécurisées), basées sur les meilleures pratiques du secteur. Intégrer la sécurité des renseignements dans le cycle de vie du développement de logiciel. Ces processus doivent inclure ce qui suit : 6.2.a S'entretenir avec le personnel responsable pour vérifier que des processus sont mis en œuvre pour identifier les nouvelles vulnérabilités de sécurité, et qu'un classement des risques est assigné à de telles vulnérabilités. (Au minimum, les vulnérabilités de plus haut risque, plus critiques, doivent être classées comme «à haut risque»). 6.2.b Vérifier que les processus identifient les nouvelles vulnérabilités de sécurité, y compris, les sources externes pour les renseignements de vulnérabilité de sécurité. 6.3.a Obtenir et examiner les processus de développement de logiciel écrits pour vérifier que les processus sont basés sur les normes et/ou sur les meilleures pratiques du secteur. 6.3.b Examiner les processus écrits de développement de logiciel pour vérifier que la sécurité des renseignements est comprise dans le cycle de vie du développement de logiciel. 6.3.c Examiner les processus écrits de développement de logiciel pour vérifier que les applications logicielles sont conformes aux normes PCI DSS. 6.3.d À partir de l'examen des processus écrits de développement de logiciel, et des entrevues avec les développeurs de logiciels, vérifier : Copyright 2010 PCI Security Standards Council LLC Page 42

43 Exigences PCI DSS Procédures de test En Suppression des comptes d'application personnalisés, des noms d'utilisateur et des mots de passe avant l'activation des applications ou leur mise à la disposition des clients Vérification du code personnalisé avant sa mise en production ou sa mise à la disposition des clients afin d'identifier une vulnérabilité éventuelle du codage. Remarque : cette exigence de vérification de code s applique à l'intégralité du code personnalisé (aussi bien interne qu orienté vers le public), dans le cadre du cycle de vie du développement du système. Les vérifications du code peuvent être réalisées par le personnel interne compétent ou par des fournisseurs tiers. Les applications Web font également l'objet de contrôles suppléme si elles sont orientées vers le public afin de résoudre les menaces et les vulnérabilités éventuelles après leur déploiement, comme défini par l exigence 6.6 des normes PCI DSS. 6.4 Suivre les processus et les procédures de contrôle des changements pour tous les changements apportés à des composants du système. Les processus doivent comprendre ce qui suit : Séparation des environnements de développement/test et de production Les comptes d'application personnalisés, les noms d'utilisateur et les mots de passe sont supprimés avant que le système ne soit produit ou remis au client a Obtenir et examiner les politiques pour confirmer que tous les changements de code d'application personnalisé doivent être vérifiés (en utilisant des processus manuels ou automatiques) comme suit : Les modifications de code sont examinées par des individus autres que l auteur initial du code, qui doivent être compétents en la matière et maîtriser les pratiques de codage sécurisées. La révision de code assure que le code est développé selon les directives de codage sécurisé (voir l'exigence 6.5 des normes PCI DSS). Les corrections appropriées sont implémentées avant la publication. Les résultats de l examen du code sont passés en revue et approuvés par les responsables avant la publication b Sélectionner un échantillon des changements d'application personnalisée récents et vérifier que le code d'application personnalisé est révisé conformément à l'exigence a ci-dessus. 6.4 À partir de l'examen des processus de contrôle de changements, des entrevues avec les administrateurs de système et de réseau, et de l'examen des données pertinentes (documentation sur la configuration du réseau, production et données test, etc.), vérifier ce qui suit : Les environnements de test/développement sont distincts de l environnement de production, et il existe un contrôle d accès pour garantir la séparation. Copyright 2010 PCI Security Standards Council LLC Page 43

44 Exigences PCI DSS Procédures de test En Séparation des obligations entre les environnements de développement/test et de production Les données de production (PAN actifs) ne sont pas utilisées à des fins de test ou de développement Suppression des données et comptes de tests avant que les systèmes de production ne deviennent actifs Procédures de contrôle des changements pour la mise en œuvre des correctifs de sécurité et des changements du logiciel. Les procédures doivent comprendre ce qui suit : Il existe une séparation des tâches du personnel affecté aux environnements de développement/test et de celui affecté à l'environnement de production Les données de production (PAN actifs) ne sont pas utilisées à des fins de test ou de développement Les données et les comptes de test sont supprimés avant que le système de production ne devienne actif a Vérifier que les procédures de contrôle des changements relatives à la mise en œuvre des correctifs de sécurité et des changements du logiciel sont documentées et exigent les points à ci-dessous b Pour un échantillon de composants du système et les changements/correctifs de sécurité récents, remonter à la documentation de contrôle des changements connexe. Pour chaque changement examiné, effectuer ce qui suit : Documentation de l'impact Vérifier que la documentation de l'impact est comprise dans la documentation de contrôle des changements, et ce pour chaque changement Approbation documentée du changement par les parties autorisées appropriées Test de fonctionnalité pour vérifier que le changement ne porte pas atteinte à la sécurité du système Vérifier que l'approbation documentée par les parties autorisées existe pour chaque changement échantillonné a Pour chaque changement échantillonné, s'assurer que le test de fonctionnalité est exécuté pour vérifier que le changement ne porte pas atteinte à la sécurité du système b Pour les changements de code personnalisé, vérifier que toutes les mises à jour sont testées du point de vue de la conformité à l'exigence 6.5 des normes PCI DSS avant d'être déployées à la production Procédures de suppression Vérifier que des procédures de suppression sont préparées pour chaque changement échantillonné. Copyright 2010 PCI Security Standards Council LLC Page 44

45 Exigences PCI DSS Procédures de test En 6.5 Développer des applications basées sur des directives de codage sécurisé. Prévenir les vulnérabilités de codage courantes dans les processus de développement de logiciel, afin de comprendre les éléments suivants : Remarque : les vulnérabilités répertoriées aux points à étaient compatibles avec les meilleures pratiques du secteur lorsque cette version des normes PCI DSS a été publiée. Cependant, comme les meilleures pratiques du secteur pour la gestion de la vulnérabilité sont actualisées (par exemple, le guide OWASP, les 25 plus grands risques selon SANS CWE, le codage sécurisé CERT, etc.), les meilleures pratiques actuelles doivent être utilisées pour ces exigences Attaques par injection, notamment les injections de commandes SQL. Prendre également en considération les injections de commande OS, les attaques par injection LDAP et XPath ainsi que les autres attaques par injection. 6.5.a Obtenir et examiner les processus de développement de logiciel. Vérifier que le processus exige une formation aux techniques de codage sécurisé pour les développeurs, basée sur les directives et les meilleures pratiques du secteur. 6.5.b S'entretenir avec un échantillon de développeurs et obtenir la preuve qu'ils sont bien informés concernant les techniques de codage sécurisé. 6.5.c Vérifier que des processus sont en pour garantir que les applications ne sont pas vulnérables, au minimum à ce qui suit : Attaques par injection, notamment les injections de commandes SQL. (Validez les données entrées pour vérifier que les données utilisateur ne peuvent pas modifier le sens des commandes et des requêtes, utiliser des requêtes paramétrées, etc.) Saturation de la mémoire Saturation de la mémoire (valider les limites de la mémoire et tronquer les chaînes d'entrée) Stockage cryptographique non sécurisé Stockage cryptographique non sécurisé (éviter les défauts cryptographiques) Communications non sécurisées Communications non sécurisées (crypter correctement toutes les communications authentifiées et sensibles) Traitement inapproprié des erreurs Traitement inapproprié des erreurs (ne pas laisser échapper de renseignements par les messages d'erreurs) Copyright 2010 PCI Security Standards Council LLC Page 45

46 Exigences PCI DSS Procédures de test En Toutes les vulnérabilités à «haut risque» identifiées dans le processus d'identification des vulnérabilités (défini dans l'exigence 6.2 des normes PCI DSS). Remarque : ce point est considéré comme une meilleure pratique jusqu'au 30 juin 2012, après quoi il sera considéré comme une exigence. Remarque : les exigences à 6.5.9, ci-dessous, s'appliquent aux applications Web et aux interfaces d'application (internes ou externes) : Toutes les vulnérabilités à «haut risque» identifiées identifiées dans l'exigence 6.2 des normes PCI DSS Les attaques par script intersites (XSS) Contrôle d'accès inapproprié (comme des références d'objet directes non sécurisées, impossible de limiter l'accès aux URL, et aux échanges) Les attaques CSRF (Cross-Site Request Forgery) Attaques par script intersites (XSS) (valider tous les paramètres avant l'inclusion) Contrôle d'accès inapproprié, comme des références d'objet directes non sécurisées, impossible de limiter l'accès aux URL, et aux échanges (correctement authentifier les utilisateurs et nettoyer l'entrée. N'exposez en aucun cas les références d'objets internes aux utilisateurs) Les attaques CSRF (Cross-Site Request Forgery). (Ne répondez pas aux renseignements d'autorisation ni aux jetons automatiquement envoyés par les navigateurs). Copyright 2010 PCI Security Standards Council LLC Page 46

47 Exigences PCI DSS Procédures de test En 6.6 Pour les applications Web orientées public, traiter les nouvelles menaces et vulnérabilités de manière régulière et veiller à ce que ces applications soient protégées contre les attaques connues à l'aide de l'une des méthodes suivantes : Examen des applications Web orientées public à l'aide d'outils ou de méthodes d'évaluation de la sécurité et de la vulnérabilité des applications automatiques ou manuels, au moins une fois par an et après toute modification Installation d'un pare-feu pour applications Web devant les applications Web orientées public 6.6 Pour les applications Web orientées public, s'assurer que l'une des méthodes suivantes est en comme suit : Vérifier que les applications Web orientées public sont révisées (en utilisant des outils ou des méthodes d'évaluation de sécurité des vulnérabilités automatiques ou manuels), comme suit : - au moins une fois par an; - après un changement; - par une organisation qui est spécialisée en sécurité d'application; - que toutes les vulnérabilités sont corrigées; - que l'application est réévaluée après les corrections. Vérifier que le pare-feu d'application Web est en face aux applications Web orientées public pour détecter et empêcher les attaques basées sur le Web. Remarque : «une organisation qui est spécialisée en sécurité d'application» peut être soit un tiers, soit une société, soit une organisation interne, aussi longtemps que les examinateurs sont spécialisés dans la sécurité des applications, et peuvent démontrer leur indépendance par rapport à l'équipe de développement. Copyright 2010 PCI Security Standards Council LLC Page 47

48 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 Pour veiller à ce que les données stratégiques ne soient accessibles qu'au personnel autorisé, des systèmes et des processus doivent être mis en pour restreindre l'accès à ces données aux seuls individus qui doivent les connaître et en fonction de leurs responsabilités professionnelles. En d'autres termes, les droits d'accès ne sont accordés qu'au plus petit nombre de données nécessaires et en fonction des tâches à effectuer. Exigences PCI DSS Procédures de test En 7.1 Restreindre l'accès aux composants du système et aux données de titulaire de carte aux seuls individus qui doivent y accéder pour mener à bien leur travail. Les restrictions d'accès doivent comprendre ce qui suit : Restriction des droits d'accès accordés aux ID d'utilisateurs privilégiés en octroyant les privilèges les plus faibles qui sont nécessaires pour la réalisation du travail L'octroi des privilèges se fait sur la base de la classification et de la fonction professionnelles de chaque employé(e) Exigence d'une approbation documentée par les parties autorisées spécifiant les privilèges exigés Mise en œuvre d'un système de contrôle d'accès automatique 7.1 Obtenir et examiner la politique écrite pour le contrôle de données, et vérifier qu'elle comprend les éléments suivants : Confirmer que les droits d'accès accordés aux ID d'utilisateurs privilégiés sont restreints en octroyant les privilèges les plus faibles nécessaires pour la réalisation du travail Confirmer que les privilèges sont octroyés aux employés sur la base de la classification et de la fonction professionnelles (également nommée «contrôle d'accès basé sur les fonctions» ou RBAC) Confirmer que l'approbation documentée par les parties autorisées est exigée (par écrit ou de manière électronique) pour tous les accès, et qu'elle doit spécifier les privilèges requis Confirmer que les contrôles d'accès sont mis en œuvre par un système de contrôle d'accès automatique. Copyright 2010 PCI Security Standards Council LLC Page 48

49 Exigences PCI DSS Procédures de test En 7.2 Établir un système de contrôle d'accès pour les composants du système comptant plusieurs utilisateurs, qui limite l'accès aux seuls utilisateurs qui doivent accéder aux données et qui est configuré pour «refuser tous les accès» à moins qu'ils ne soient explicitement autorisés. Ce système de contrôle d'accès doit inclure les éléments suivants : Couverture de tous les composants du système L'octroi de privilèges aux individus repose sur leur classification et leur fonction professionnelles Configuration par défaut du paramètre «Refuser tout» Remarque : certains systèmes de contrôle d'accès sont paramétrés par défaut sur «Accepter tout», permettant ainsi l'accès à moins/jusqu'à ce qu'une règle soit écrite pour le refuser. 7.2 Examiner les paramètres du système et la documentation du fournisseur pour vérifier qu'un système de contrôle d'accès est mis en œuvre comme suit : Confirmer que les systèmes de contrôle d'accès sont en sur tous les composants du système Confirmer que les systèmes de contrôle d'accès sont configurés pour mettre en vigueur les privilèges octroyés aux employés sur la base de la classification et de la fonction professionnelles Confirmer que les systèmes de contrôle d'accès ont un paramètre «Refuser tout» par défaut. Copyright 2010 PCI Security Standards Council LLC Page 49

50 Exigence 8 : Affecter un ID unique à chaque utilisateur d ordinateur Affecter un identifiant (ID) unique à chaque personne avec un accès assure que chaque individu sera personnellement responsable de ses actes. Les actions sur des données et des systèmes stratégiques peuvent alors être exécutées par des utilisateurs clairement identifiés et habilités à le faire. Remarque : ces exigences sont applicables à tous les comptes, y compris aux comptes de point de vente, ayant les capacités administratives et tous les comptes utilisés pour voir ou accéder aux données de titulaire de carte ou aux systèmes avec des données de titulaire de carte. Cependant, les exigences 8.1, 8.2 et de à ne s'appliquent pas aux comptes utilisateurs au sein d'une application de paiement de point de vente qui a uniquement accès à un numéro de carte à la fois, dans le but de faciliter une transaction unique (comme des comptes de caisse). Exigences PCI DSS Procédures de test En 8.1 Affecter à tous les utilisateurs un ID unique leur permettant d'accéder à des composants du système ou aux données de titulaire de carte. 8.2 Outre l'affectation d'un ID unique, employer au moins l'une des méthodes suivantes pour authentifier tous les utilisateurs : quelque chose de connu, comme un mot de passe ou une phrase passe; quelque chose de détenu, comme un dispositif à jetons ou une carte à puce; quelque chose que vous êtes, comme une biométrie. 8.1 Vérifier que tous les utilisateurs ont un ID unique assigné leur permettant d'accéder à des composants du système ou aux données de titulaire de carte. 8.2 Pour vérifier que les utilisateurs sont authentifiés grâce à un ID unique et à une authentification supplémentaire (par exemple, un mot de passe) pour accéder à l'environnement de données de titulaire de carte, effectuer ce qui suit : obtenir et examiner la documentation décrivant la ou les méthodes d'authentification utilisées; pour chaque type de méthode d'authentification utilisée et pour chaque type de composant du système, observer une authentification pour vérifier que l'authentification fonctionne de manière cohérente avec la ou les méthodes d'authentification documentées. Copyright 2010 PCI Security Standards Council LLC Page 50

51 Exigences PCI DSS Procédures de test En 8.3 Intégrer une authentification à deux facteurs 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, le service d'authentification à distance et de service téléphonique (RADIUS) avec jetons; le protocole d'authentification TACACS (terminal access controller access control system, système de contrôle d'accès du contrôleur d'accès au terminal) avec jetons; ou d'autres technologies qui permettent l'authentification à deux facteurs). Remarque : l'authentification à deux facteurs exige que deux des trois méthodes d'authentification (voir l'exigence 8.2 pour des descriptions des méthodes d'authentification) soient utilisées pour l'authentification. L'utilisation à deux reprise d'un facteur (par exemple, l'utilisation de deux mots de passe séparés) n'est pas considérée comme une authentification à deux facteurs. 8.4 Rendre tous les mots de passe illisibles pendant la transmission et le stockage sur tous les composants du système à l'aide d'une cryptographie performante. 8.5 S'assurer qu'une gestion appropriée de l'identification et de l'authentification des utilisateurs est mise en œuvre pour les utilisateurs non-consommateurs et les administrateurs sur tous les composants du système comme suit : 8.3 Pour vérifier qu'une authentification à deux facteurs est mise en œuvre pour tous les réseaux d'accès à distance, observer un employé (par exemple, un administrateur) se connectant à distance au réseau et vérifier que deux des trois méthodes d'authentification sont utilisées. 8.4.a Pour un échantillon de composants du système, examiner les fichiers de mots de passe pour vérifier que ceux-ci sont illisibles lors de la transmission et du stockage. 8.4.b Pour les prestataires de services uniquement, observer les fichiers de mots de passe pour vérifier que les mots de passe du client sont cryptés. 8.5 Réviser les procédures et s'entretenir avec le personnel pour vérifier que des procédures sont mises en œuvre pour la gestion d'identification et d'authentification des utilisateurs, en effectuant ce qui suit : Copyright 2010 PCI Security Standards Council LLC Page 51

52 Exigences PCI DSS Procédures de test En Contrôler l'ajout, la suppression et la modification d'id d'utilisateur, de renseignements d'identification et d'autres objets identifiant Vérifier l'identité des utilisateurs avant de réinitialiser leur mot de passe Définir des mots de passe initiaux uniques pour chaque utilisateur et les modifier immédiatement après la première utilisation Révoquer immédiatement l'accès des utilisateurs qui ne travaillent plus pour la société Supprimer/désactiver les comptes d'utilisateurs inactifs au moins tous les 90 jours Activer les comptes utilisés par les fournisseurs pour l'accès à distance pendant la période nécessaire uniquement. Surveiller les comptes d'accès à distance des fournisseurs lorsqu'ils sont utilisés Sélectionner un échantillon d'id d'utilisateur, comprenant à la fois des administrateurs et des utilisateurs généraux. Vérifier que chaque utilisateur est autorisé à utiliser le système conformément à la politique, en effectuant ce qui suit : obtenir et examiner un formulaire d'autorisation pour chaque ID; vérifier que les ID d'utilisateurs échantillonnés sont mis en œuvre conformément au formulaire d'autorisation (comportant les privilèges spécifiés et toutes les signatures obtenues), en suivant les renseignements du formulaire d'autorisation jusqu'au système Examiner les procédures de mot de passe/authentification et observer le personnel de sécurité pour vérifier que si un utilisateur demande une réinitialisation de mot de passe par téléphone, courriel, Web, ou autre méthode sans face-à-face, l'identité de l'utilisateur est vérifiée avant que le mot de passe ne soit réinitialisé Examiner les procédures de mots de passe et observer le personnel de sécurité pour vérifier que des mots de passe initiaux pour les nouveaux utilisateurs, et des mots de passe de réinitialisation pour les utilisateurs existants sont définis sur une valeur unique pour chaque utilisateur et changés après la première utilisation Sélectionner un échantillon d'utilisateurs ayant arrêté de travailler pour la société au cours de six derniers mois, et réviser les listes d'accès des utilisateurs actuels pour vérifier que leurs ID ont été désactivées ou supprimées Vérifier que les comptes inactifs depuis plus de 90 jours sont supprimés ou désactivés a Vérifier que les comptes utilisés par les fournisseurs pour accéder, prendre en charge et maintenir les composants du système sont désactivés, et activés uniquement lorsque le fournisseur en a besoin b Vérifier que les comptes d'accès à distance des fournisseurs sont surveillés lorsqu'ils sont utilisés. Copyright 2010 PCI Security Standards Council LLC Page 52

53 Exigences PCI DSS Procédures de test En Communiquer les procédures et politiques d'authentification à tous les utilisateurs qui ont accès aux données de titulaire de carte Ne pas utiliser des comptes et des mots de passe collectifs, partagés ou génériques, ou d'autre méthode d'authentification S'entretenir avec les utilisateurs d'un échantillon d'id d'utilisateurs, pour vérifier qu'ils sont familiarisés avec les procédures et politiques d'authentification a Pour un échantillon de composants du système, examiner les listes d'id d'utilisateurs pour vérifier ce qui suit : les comptes et ID d'utilisateurs génériques sont désactivés ou supprimés; les ID d'utilisateurs partagés pour les activités administratives du système et d'autres fonctions essentielles n'existent pas; les ID génériques et partagés ne sont pas utilisés pour administrer les composants du système b Examiner les politiques/procédures d'authentification pour vérifier que les mots de passes collectifs et partagés et autres méthodes d'authentification sont interdits de manière explicite Modifier les mots de passe utilisateur au moins tous les 90 jours Exiger que les mots de passe comportent au moins sept caractères c S'entretenir avec les administrateurs du système pour vérifier que les mots de passe collectifs ou partagés ou autres méthodes d'authentification ne sont pas distribués, même s'ils sont demandés a Pour un échantillon de composants du système, obtenir et inspecter les paramètres de configuration du système pour vérifier que les paramètres de mot de passe utilisateur sont définis pour exiger de changer les mots de passe au moins tous les 90 jours b Pour les prestataires de services uniquement, examiner les processus internes et la documentation du client/utilisateur pour vérifier que des mots de passe utilisateurs non-clients doivent être changés périodiquement et que les utilisateurs nonclients reçoivent des instructions sur la fréquence et les circonstances du changement des mots de passe a Pour un échantillon de composants du système, obtenir et inspecter les paramètres de configuration du système pour vérifier que les paramètres de mots de passe sont définis pour exiger de comporter au moins sept caractères. Copyright 2010 PCI Security Standards Council LLC Page 53

54 Exigences PCI DSS Procédures de test En Définir des mots de passe comportant à la fois des caractères numériques et alphabétiques Interdire à un utilisateur de soumettre un nouveau mot de passe identique à l'un de ses quatre derniers mots de passe Limiter les tentatives d'accès répétées en verrouillant l'id d'utilisateur après six tentatives au maximum Régler la durée de verrouillage sur 30 minutes au moins ou jusqu'à ce que l'administrateur active l'id d'utilisateur b Pour les prestataires de services uniquement, réviser les processus internes et la documentation du client/utilisateur pour vérifier que les mots de passe utilisateurs non-clients doivent satisfaire aux exigences de longueur minimum a Pour un échantillon de composants du système, obtenir et inspecter les paramètres de configuration du système pour vérifier que les paramètres de mots de passe sont définis pour exiger que les mots de passe comportent à la fois des caractères numériques et alphabétiques b Pour les prestataires de services uniquement, réviser les processus internes et la documentation du client/utilisateur pour vérifier que les mots de passe utilisateurs non-clients doivent comporter des caractères numériques et alphabétiques a Pour un échantillon de composants du système, obtenir et inspecter les paramètres de configuration du système pour vérifier que les paramètres de mots de passe sont définis pour exiger que les nouveaux mots de passe soient différents des quatre derniers utilisés b Pour les prestataires de services uniquement, réviser les processus internes et la documentation du client/utilisateur pour vérifier que les nouveaux mots de passe des utilisateurs nonclients sont différents des quatre derniers a Pour un échantillon de composants du système, obtenir et inspecter les paramètres de configuration du système pour vérifier que les paramètres d'authentification sont définis pour exiger qu'un compte utilisateur soit verrouillé après six tentatives infructueuses au maximum b Pour les prestataires de services uniquement, examiner les processus internes et la documentation du client/utilisateur pour vérifier que des comptes utilisateurs non-clients sont temporairement verrouillés après six tentatives infructueuses au maximum Pour un échantillon de composants du système, obtenir et inspecter les paramètres de configuration du système pour vérifier que les paramètres de mots de passe sont définis pour exiger qu'une fois qu'un compte utilisateur est verrouillé, il le reste pour un minimum de 30 minutes ou jusqu'à ce que l'administrateur Copyright 2010 PCI Security Standards Council LLC Page 54

55 Exigences PCI DSS Procédures de test En Si une session reste inactive pendant plus de 15 minutes, demander à l'utilisateur de s'authentifier de nouveau pour réactiver le terminal ou la session Authentifier tous les accès aux bases de données contenant des données de titulaire de carte. Cette exigence concerne les accès des applications, des administrateurs et de tous les autres utilisateurs. Restreindre l'accès direct des utilisateurs ou les requêtes aux bases de données, aux administrateurs de base de données. réinitialise le compte Pour un échantillon de composants du système, obtenir et inspecter les paramètres de configuration du système pour vérifier que les fonctions d'inactivité du système/session ont été définies à 15 minutes ou moins a Réviser les paramètres de configuration des bases de données et des applications et vérifier que tous les utilisateurs sont authentifiés avant l'accès b Vérifier que les paramètres de configuration de la base de données et de l'application garantissent que tous les accès, toutes les requêtes et toutes les actions des utilisateurs (par exemple, dér, copier, supprimer) sur la base de données, se font à travers des méthodes de programmation uniquement (par exemple, à travers des procédures stockées) c Vérifier que les paramètres de configuration de la base de données et de l'application restreignent l'accès direct des utilisateurs, ou des requêtes aux bases de données, aux administrateurs de base de données d Réviser les applications de base de données et les ID d'applications connexes pour vérifier que les ID d'application peuvent uniquement être utilisés par les applications (et non par des utilisateurs individuels ou d'autres processus). Copyright 2010 PCI Security Standards Council LLC Page 55

56 Exigence 9 : Restreindre l accès physique aux données de titulaire de carte Dans la mesure où tout accès physique à des données ou à des systèmes hébergeant des données de titulaire de carte permet à des individus d'accéder à des dispositifs ou à des renseignements, et de supprimer des systèmes ou des copies papier, cet accès doit être restreint de façon appropriée. Dans le cadre de l'exigence 9, le terme «employés sur site» désigne les employés à temps plein et à temps partiel, les intérimaires ainsi que les sous-traitants et les consultants qui sont physiquement présents sur le site de l'entité. Un «visiteur» est défini comme un fournisseur, un invité d un(e) employé(e) sur site, le personnel de service ou tout individu présent au sein des locaux pendant une période courte, n'excédant généralement pas une journée. Le terme «support» concerne tous les documents papier et les supports électroniques contenant des données de titulaire de carte. Exigences PCI DSS Procédures de test En 9.1 Utiliser des contrôles appropriés d'accès aux installations pour limiter et surveiller l'accès physique aux systèmes installés dans l'environnement des données de titulaire de carte Utiliser des caméras vidéo et/ou d autres mécanismes de contrôle d accès pour surveiller l accès physique des individus aux zones sensibles. Examiner les données enregistrées et 9.1 Vérifier l'existence de contrôles de sécurité physiques pour chaque salle informatique, centre de données et autres zones physiques équipées de systèmes dans l'environnement de données de titulaire de carte. Vérifier que l'accès est contrôlé avec des lecteurs de badges ou d'autres dispositifs, notamment des badges autorisés, un verrouillage et des clés. Observer une tentative d'administrateur de système pour se connecter à des consoles de systèmes sélectionnés de manière aléatoire dans l'environnement des données de titulaire de carte et vérifier qu'ils sont «verrouillés» de manière à empêcher toute utilisation non autorisée a Vérifier que des caméras vidéo et/ou des mécanismes de contrôle d'accès sont en pour surveiller les points d'entrée et de sortie des zones sensibles b Vérifier que les caméras vidéo et/ou des mécanismes de contrôle d'accès sont protégés de l'altération et de l'inhibition. Copyright 2010 PCI Security Standards Council LLC Page 56

57 Exigences PCI DSS Procédures de test En les mettre en corrélation avec d'autres informations. Les conserver pendant trois mois au minimum, sauf stipulation contraire de la loi. Remarque : par «zones sensibles», nous entendons tout centre de données, salle de serveurs ou zone abritant des systèmes qui stockent, traitent ou transmettent des données de titulaire de carte. Cette définition exclut les zones où ne sont installés que des terminaux de point de vente, telles que les zones de caisse dans un magasin de vente au détail Restreindre l'accès physique aux prises réseau accessibles au public. Par exemple, les zones accessibles aux visiteurs ne doivent pas comporter de ports réseau activés à moins que l'accès au réseau ne soit autorisé de manière explicite Restreindre l'accès physique aux points d'accès sans fil, passerelles, dispositifs portables, matériel de communication/mise en réseau, et lignes de télécommunications. 9.2 Élaborer des procédures qui facilitent la distinction entre les employés sur site et les visiteurs, en particulier dans les zones où les données de titulaire de carte sont accessibles c Vérifier que les caméras vidéo et/ou des mécanismes de contrôle d'accès sont surveillés et que les données des caméras ou d'autres mécanismes sont stockées pour trois mois au minimum Vérifier par une entrevue avec les administrateurs de réseau et par l'observation, que les prises réseau sont activées uniquement lorsque les employés autorisés sur site en ont besoin. Autrement, vérifier que les visiteurs sont accompagnés à tout moment dans les zones comportant des prises réseau actives Vérifier que l'accès physique aux points d'accès sans fil, passerelles, dispositifs portables, matériel de communication/mise en réseau, et lignes de télécommunications est restreint de manière appropriée. 9.2.a Réviser les processus et procédures pour assigner des badges aux employés sur site et aux visiteurs, et vérifier que ces processus comprennent ce qui suit : l'octroi de nouveaux badges; la modification des exigences d'accès; la révocation des badges d'employés sur site ne travaillant plus pour l'entreprise, ou des badges de visiteur expirés. 9.2.b Vérifier que l'accès au système de badge est limité au personnel autorisé. Copyright 2010 PCI Security Standards Council LLC Page 57

58 Exigences PCI DSS Procédures de test En 9.3 S'assurer que tous les visiteurs sont traités de la manière suivante : Une autorisation d'accès leur est donnée avant de pénétrer dans les zones où sont traitées et conservées les données de titulaire de carte Ils reçoivent un jeton physique (par exemple, un badge ou un dispositif d'accès) doté d'une date d'expiration, qui identifie distinctement les visiteurs des employés sur site Il leur est demandé de rendre le jeton physique avant de quitter les locaux ou à la date d'expiration. 9.2.c Examiner l'utilisation des badges pour vérifier qu'ils identifient clairement les visiteurs et qu'il est facile de distinguer les employés sur site des visiteurs. 9.3 Vérifier que les contrôles des visiteurs sont en comme suit : Observer l'utilisation des badges ID des visiteurs pour vérifier qu'un badge ID visiteur ne permet pas l'accès non accompagné aux zones physiques où sont stockées les données de titulaire de carte a Observer les personnes au sein de l'installation pour vérifier l'utilisation des badges ID des visiteurs, et que les visiteurs sont facilement distingués des employés sur site b Vérifier que les badges des visiteurs comportent une date d'expiration Observer les visiteurs quittant l'installation pour vérifier qu'il leur est demandé de rendre leur badge ID lors du départ ou à la date d'expiration. Copyright 2010 PCI Security Standards Council LLC Page 58

59 Exigences PCI DSS Procédures de test En 9.4 Utiliser un journal des visites pour tenir une historique de vérification physique de l'activité des visiteurs. Y consigner le nom du visiteur, l'entreprise qu'il représente et l'employé sur site qui autorise son accès physique. Conserver ce journal pendant trois mois au minimum, sauf stipulation contraire de la loi. 9.5 Stocker les sauvegardes sur support en lieu sûr, de préférence hors de l'installation, par exemple sur un autre site ou un site de secours, ou encore un site de stockage commercial. Inspecter la sécurité du site au moins une fois par an. 9.6 Sécuriser physiquement tous les supports. 9.7 Assurer un contrôle strict de la distribution interne ou externe d un quelconque type de support, notamment ce qui suit : Classifier le support pour que la confidentialité des données puisse être déterminée Envoyer les supports par coursier ou toute autre méthode d'expédition qui peut faire l'objet d'un suivi précis. 9.8 S'assurer que les responsables approuvent tous les supports déplacés d'une zone sécurisée (en particulier s'ils sont distribués à des individus). 9.4.a Vérifier qu'un journal des visiteurs est utilisé pour enregistrer l'accès physique à l'installation ainsi qu'aux salles informatiques, et aux centres de données où sont stockées ou transmises les données de titulaire de carte. 9.4.b Vérifier que le journal contient le nom du visiteur, l'entreprise représentée et l'employé sur site qui autorise son accès physique, et que ce journal est conservé au moins trois mois. 9.5.a Observer la sécurité physique de l'emment de stockage pour confirmer que les supports de sauvegarde sont stockés de manière sécurisée. 9.5.b Vérifier que la sécurité de l'emment de stockage est révisée au moins une fois par an. 9.6 Vérifier que les procédures de protection des données de titulaire de carte comprennent des contrôles pour sécuriser physiquement tous les supports (comprenant, mais sans s'y limiter, les ordinateurs, les supports électroniques amovibles, les reçus papier, les rapports papier et les télécopies). 9.7 Vérifier qu'une politique existe pour contrôler la distribution des supports, et que cette politique couvre tous les supports distribués, notamment ceux distribués aux individus Vérifier que tous les supports sont classifiés pour pouvoir déterminer la confidentialité des données Vérifier que tous les supports envoyés hors de l'installation sont consignés dans un journal et autorisés par la direction, puis envoyés par des services de coursiers ou toute autre méthode d'expédition pouvant faire l'objet d'un suivi précis. 9.8 Sélectionner un échantillon récent de plusieurs jours de journaux de suivi hors site pour tous les supports, et vérifier la présence dans les journaux des détails de suivi et d'autorisation adéquate de la direction. Copyright 2010 PCI Security Standards Council LLC Page 59

60 Exigences PCI DSS Procédures de test En 9.9 Assurer un contrôle strict du stockage et de l'accessibilité des supports Tenir de manière appropriée les journaux d'inventaire de tous les supports et effectuer un inventaire des supports au moins une fois par an Détruire les supports lorsqu'ils ne sont plus nécessaires à des fins commerciales ou légales comme suit : Déchiqueter, brûler ou réduire en pâte les documents papier de sorte que les données de titulaire de carte ne puissent pas être reconstituées Rendre les données de titulaire de carte sur support électronique irrécupérables de sorte que les informations ne puissent pas être reconstituées. 9.9 Obtenir et examiner la politique pour le contrôle du stockage et la conservation de tous les supports et vérifier que la politique exige des inve de support périodiques Obtenir et réviser le journal d'inventaire des supports pour vérifier que des inve périodiques des supports sont réalisés au moins une fois par an Obtenir et examiner la politique de destruction périodique des supports et vérifier qu'elle couvre tous les supports, et confirmer ce qui suit : a Vérifier que les documents papiers sont découpés, déchiquetés, brûlés ou réduits en pâte de manière à ce qu'il existe une assurance raisonnable que les documents papier ne puissent pas être reconstitués b Examiner les conteneurs de stockage utilisés pour la destruction des renseignements pour vérifier qu'ils sont sécurisés. Par exemple, vérifier qu'un conteneur de «documents à déchiqueter» possède une serrure empêchant l'accès à son contenu Vérifier que les données de titulaire de carte sur support électronique sont rendues irrécupérables par un programme d'effacement sécurisé, conformément aux normes du secteur sur la suppression sécurisée, ou sur la destruction physique du support (par exemple, la démagnétisation). Copyright 2010 PCI Security Standards Council LLC Page 60

61 Surveillance et test réguliers des réseaux Exigence 10 : Effectuer le suivi et surveiller tous les accès aux ressources réseau et aux données de titulaire de carte Les mécanismes de connexion et la possibilité de suivre les activités des utilisateurs sont essentiels pour prévenir, détecter ou minimiser l'impact d'une altération des données. La présence de journaux dans tous les environnements permet de suivre de près, d'émettre des alertes et d'analyser les incidents éventuels. En l'absence de journaux retraçant les activités du système, il est très difficile, voire impossible, de déterminer la cause d'une anomalie. Exigences PCI DSS Procédures de test En 10.1 Définir un processus pour associer tous les accès aux composants du système (en particulier les accès avec des droits d'administrateur, tels qu'un segment racine) à un utilisateur individuel Mettre en œuvre des historiques de vérification automatiques pour tous les composants du système afin de reconstituer les événements suivants : Tous les accès individuels aux données de titulaire de carte Toutes les actions exécutées par un individu ayant des privilèges de segment racine ou d'administrateur Accès à tous les historiques de vérification 10.1 Vérifier à travers l'observation et l'entrevue avec l'administrateur du système, que l'historique de vérification est activé et actif pour les composants du système À travers des entrevues, l'examen des journaux de vérification et de leurs paramètres, exécuter ce qui suit : Vérifier que tous les accès individuels aux données de titulaire de carte sont enregistrés Vérifier que les actions exécutées par un individu ayant des privilèges de segment racine ou d'administrateur sont enregistrées Vérifier que l'accès à tous les historiques de vérification est enregistré Tentatives d'accès logique non valides Vérifier que les tentatives d'accès logique non valides sont enregistrées Utilisation des mécanismes d'identification et d'authentification Initialisation des journaux de vérification Vérifier que l'utilisation des mécanismes d'identification et d'authentification est enregistrée Vérifier que l'initialisation des journaux de vérification est enregistrée. Copyright 2010 PCI Security Standards Council LLC Page 61

62 Exigences PCI DSS Procédures de test En Création et suppression d'objets au niveau du système 10.3 Consigner, dans les historiques de vérification, au moins les entrées suivantes pour chaque événement : Vérifier que la création et la suppression d'objets au niveau du système sont enregistrées À travers des entrevues et des observations, pour chaque événement devant donner lieu à vérification (selon l'exigence 10.2), effectuer ce qui suit : Identification de l'utilisateur Vérifier que l'identification de l'utilisateur est comprise dans les entrées du journal Type de l'événement Vérifier que le type de l'événement est compris dans les entrées du journal et heure Vérifier que la date et l'heure sont comprises dans les entrées du journal Indication de succès ou d'échec Vérifier que l'indication de succès ou d'échec est comprise dans les entrées du journal Origine de l'événement Vérifier que l'origine de l'événement est comprise dans les entrées du journal Identité ou nom des données, du composant du système ou de la ressource affecté En utilisant une technologie de synchronisation horaire, synchroniser toutes les horloges et l'heure du système essentiel et s'assurer que ce qui suit est mis en œuvre pour acquérir, distribuer et stocker l'heure. Remarque : un exemple de technologie de synchronisation horaire est le protocole de synchronisation réseau (protocole NTP) Vérifier que l'identité ou le nom des données, du composant du système ou de la ressource affectés sont compris dans les entrées du journal a Vérifier que la technologie de synchronisation horaire est mise en œuvre et gardée à jour conformément aux exigences 6.1 et 6.2 des normes PCI DSS b Obtenir et réviser le processus pour acquérir, distribuer et stocker l'heure correcte au sein de l'organisation, et réviser les réglages des paramètres du système, relatifs au temps pour un échantillon de composants du système. Vérifier que ce qui suit est compris dans le processus et mis en œuvre : Copyright 2010 PCI Security Standards Council LLC Page 62

63 Exigences PCI DSS Procédures de test En Les systèmes essentiels ont une heure correcte et cohérente Les données horaires sont protégées Paramètres horaires reçus à partir de sources horaires acceptées par le secteur Sécuriser les historiques de vérification de sorte qu'ils ne puissent pas être altérés Limiter l'affichage des historiques de vérification aux utilisateurs qui en ont besoin pour mener à bien leur travail Protéger les fichiers des historiques de vérification contre tout changement non autorisé a Vérifier que seuls les serveurs horaires centraux reçoivent les signaux horaires émanant de sources extérieures, et que les signaux horaires sont basés sur le temps atomique universel ou sur le temps universel coordonné (UTC) b Vérifier que les serveurs horaires centraux désignés sont couplés l'un à l'autre pour garder l'heure exacte, et que les autres serveurs internes reçoivent l'heure uniquement à partie des serveurs horaires centraux a Réviser les configurations du système et les paramètres de synchronisation horaire pour vérifier que l'accès aux données horaires est restreint au personnel ayant besoin d'avoir accès à ces données pour des raisons professionnelles b Réviser les configurations du système, les paramètres de synchronisation horaire et les processus pour vérifier que les changements de paramètres horaires sur des systèmes essentiels sont enregistrés, surveillés et révisés Vérifier que les serveurs horaires acceptent les mises à jour horaires depuis des sources externes spécifiques, acceptées par le secteur (pour empêcher un individu malveillant de changer l'horloge). Ces mises à jour peuvent être cryptées de manière facultative par une clé symétrique, et des listes de contrôle d'accès peuvent être créées, spécifiant les adresses IP des équipements des clients qui seront fournies avec les mises à jour horaires (pour empêcher l'utilisation non autorisée des serveurs horaires internes) S'entretenir avec l'administrateur de système et examiner les autorisations pour vérifier que les historiques de vérification sont sécurisés et ne peuvent donc pas être altérés, comme suit : Vérifier que seuls les individus qui en ont besoin à des fins professionnelles peuvent voir les fichiers d'historiques de vérification Vérifier que les fichiers d'historiques de vérification en cours sont protégés contre tout changement non autorisé par des mécanismes de contrôles d'accès, une séparation physique, et/ou une ségrégation de réseau. Copyright 2010 PCI Security Standards Council LLC Page 63

64 Exigences PCI DSS Procédures de test En Sauvegarder rapidement les fichiers d'historiques de vérification sur un serveur centralisé réservé à la consignation ou sur des supports difficilement altérables Enregistrer les journaux des technologies orientées vers l'extérieur sur un serveur réservé à la consignation sur le réseau local (LAN) interne Analyser les journaux à l'aide de logiciels de contrôle de l'intégrité des fichiers et de détection des changements pour s'assurer que les données contenues dans les journaux ne peuvent pas être modifiées sans déclencher une alerte (alors que l'ajout de nouvelles données ne doit pas entraîner d'alerte) Réviser les journaux relatifs à tous les composants du système au moins une fois par jour. L examen des journaux doit comprendre les serveurs exécutant des fonctions de sécurité, tels que les systèmes IDS (système de détection d'intrusion) et les protocoles AAA (authentification, autorisation et comptabilité) (par exemple, RADIUS). Remarque : les outils de consignation, d'analyse et d'alerte peuvent être utilisés conformément à l exigence Conserver l'historique des vérifications pendant une année au moins, en gardant immédiatement disponibles les journaux des trois Vérifier que les fichiers d'historiques de vérification sont sauvegardés rapidement sur un serveur centralisé réservé à la consignation ou sur des supports difficilement altérables Vérifier que les journaux des technologies orientées vers l'extérieur (par exemple, sans fil, pare-feu, serveurs de nom de domaine (DNS), courriels) sont téléchargés ou copiés sur un serveur réservé à la consignation interne centralisée ou sur un support Vérifier l'utilisation de la surveillance de l'intégrité d'un fichier ou le logiciel de détection de changement pour les journaux en examinant les paramètres de système, les fichiers surveillés et les résultats des activités de surveillance a Obtenir et examiner les politiques et procédures de sécurité pour vérifier qu'elles comprennent des procédures pour réviser les journaux de sécurité au moins une fois par jour et exiger un suivi des anomalies b À travers une observation et des entrevues, vérifier que les examens de journaux réguliers sont réalisés pour tous les composants du système a Obtenir et examiner les politiques et procédures de sécurité et vérifier qu'elles comprennent des politiques de conservation de journaux de vérification et exigent une conservation de ces journaux d'un an au minimum. Copyright 2010 PCI Security Standards Council LLC Page 64

65 Exigences PCI DSS Procédures de test En derniers mois au moins, pour analyse (par exemple, disponibles en ligne, dans des archives ou restaurables à partir d'une sauvegarde) b Vérifier que les journaux de vérifications sont disponibles au moins un an et que les processus sont en pour restaurer immédiatement au moins les journaux des trois derniers mois pour analyse. Copyright 2010 PCI Security Standards Council LLC Page 65

66 Exigence 11 : Tester régulièrement les processus et les systèmes de sécurité. Des vulnérabilités sont sans cesse découvertes par des individus malveillants et des chercheurs, et sont introduites avec tout nouveau logiciel. Les composants du système, les processus et les logiciels personnalisés doivent être fréquemment testés afin de s'assurer que les contrôles de sécurité reflètent toujours les nouveaux environnements. Exigences PCI DSS Procédures de test En 11.1 Tester la présence de points d'accès sans fil et détecter les points d'accès sans fil non autorisé sur une base trimestrielle. Remarque : les méthodes qui peuvent être utilisées dans le processus comprennent, mais sans s'y limiter, les analyses de réseau sans fil, les inspections physiques/logiques des composants du système et des infrastructures, les contrôles d'accès au réseau (NAC), ou les IDS (systèmes de détection d'intrusion) et les IPS (systèmes de prévention d'intrusion) sans fil. Quelles que soient les méthodes utilisées, elles doivent être suffisantes pour détecter et identifier les dispositifs non autorisés a Vérifier que l'entité possède un processus documenté pour détecter et identifier les points d'accès sans fil sur une base trimestrielle b Vérifier que la méthodologie est adéquate pour détecter et identifier les points d'accès sans fil non autorisés, y compris au moins les points suivants : des cartes de réseau local sans fil (WLAN) insérées dans des composants du système; des dispositifs sans fil portables connectés aux composants du système (par exemple, par USB, etc.); des dispositifs sans fil reliés à un port réseau ou à un dispositif réseau c Vérifier que le processus documenté pour identifier les points d'accès sans fil non autorisés est exécuté au moins tous les trimestres pour tous les composants du systèmes et toutes les installations d Si une surveillance automatique est utilisée (par exemple, IDS/IPS, NAC, est.), vérifier que la configuration génèrera des alertes pour le personnel e Vérifier que le plan de réponse aux incidents de l'organisation (exigence 12.9) comprend une réponse dans le cas où des dispositifs sans fil non autorisés sont détectés. Copyright 2010 PCI Security Standards Council LLC Page 66

67 Exigences PCI DSS Procédures de test En 11.2 Analyser les vulnérabilités des réseaux internes et externes au moins une fois par trimestre et après un changement significatif dans le 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). 11.2Vérifier que des analyses de vulnérabilités internes et externes sont réalisées comme suit : Remarque : il n'est pas exigé que quatre analyses trimestrielles soient réalisées et réussies 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 exigeant l'analyse trimestrielle, et 3) les vulnérabilités notées ont été corrigées, ce qui sera confirmé par une nouvelle analyse. Lors des années suivant la vérification PCI DSS initiale, quatre analyses trimestrielles doivent être réalisées et réussies Exécuter des analyses de vulnérabilité interne trimestrielles a Réviser les rapports d'analyses et vérifier que quatre analyses internes trimestrielles apparaissent au cours des 12 derniers mois b Réviser les rapports d'analyses et vérifier que le processus d'analyse comprend de nouvelles analyses jusqu'à ce que des résultats satisfaisants soient obtenus, ou que toutes les vulnérabilités à «haut risque», définies dans l'exigence 6.2 des normes PCI DSS, soient résolues c Valider le fait que l'analyse a été effectuée par une ou plusieurs ressources internes qualifiées ou un tiers externe qualifié, et le cas échéant, l'indépendance organisationnelle de la personne qui a effectué le test (il n'est pas exigé d'être un QSA ou un ASV). Copyright 2010 PCI Security Standards Council LLC Page 67

68 Exigences PCI DSS Procédures de test En Effectuer des analyses des vulnérabilités externes une fois par trimestre par un prestataire de services d analyse agréé (ASV) approuvé par le PCI SSC (conseil de normes de sécurité du secteur des cartes de paiement). Remarque : des analyses des vulnérabilités externes doivent être effectuées une fois par trimestre par un prestataire de services d analyse agréé (ASV) par le PCI SSC (conseil de normes de sécurité du secteur des cartes de paiement). Les analyses réalisées après la modification des réseaux peuvent être effectuées par le personnel interne Effectuer des analyses internes et externes après un changement significatif. Remarque : les analyses réalisées après des changements peuvent être effectuées par le personnel interne a Réviser les résultats sur les quatre trimestres les plus récents d'analyses de vulnérabilité externe et vérifier que quatre analyses trimestrielles ont été effectuées au cours des 12 derniers mois b Réviser les résultats de chaque analyse trimestrielle pour s'assurer qu'ils satisfassent aux exigences du guide du programme ASV (par exemple, aucune vulnérabilité nominale supérieure à 4.0 selon le CVSS et aucune défaillance automatique) c Réviser les rapports d'analyses pour vérifier que les analyses ont été exécutées par un prestataire de services agréé par le PCI SSC a Inspecter la documentation sur le contrôle des changements et les rapports d'analyses pour vérifier que les composants du système, assujettis aux changements significatifs, ont été analysés b Réviser les rapports d'analyses et vérifier que le processus d'analyse comprend de nouvelles analyses jusqu'à ce que : il n'existe aucune vulnérabilité avec un score supérieur à 4.0 selon le CVSS, pour les analyses externes; un résultat réussi soit obtenu ou que toutes les vulnérabilités à «haut risque» définies dans l'exigence 6.2 des normes PCI DSS, soient résolues, pour les analyses internes c Valider le fait que l'analyse a été effectuée par une ou plusieurs ressources internes qualifiées ou un tiers externe qualifié, et le cas échéant, l'indépendance organisationnelle de la personne qui a effectué le test (il n'est pas exigé d'être un QSA ou un ASV). Copyright 2010 PCI Security Standards Council LLC Page 68

69 Exigences PCI DSS Procédures de test En 11.3 Effectuer des tests de pénétration externe et interne au moins une fois par an et après un changement ou une mise à niveau significatifs de l'infrastructure ou de l'application (par exemple, mise à niveau du système d'exploitation ou ajout d'un sous-réseau ou d'un serveur Web dans l'environnement). Ces tests de pénétration doivent comprendre ce qui suit : Tests de pénétration de la couche réseau Tests de pénétration de la couche application 11.4 Utiliser des systèmes de détection d'intrusion et/ou des systèmes de prévention d'intrusion pour surveiller l'intégralité du trafic dans l'environnement des données de titulaire de carte, ainsi que les points essentiels de cet environnement, et signaler au personnel tous les soupçons portant sur des altérations potentielles. Tenir à jour tous les moteurs de détection et de prévention des intrusions, les références et les signatures a Obtenir et examiner les résultats du test de pénétration le plus récent pour vérifier qu'il est effectué au moins une fois par an et après tout changement significatif de l'environnement b Vérifier que les vulnérabilités exploitables notées ont été corrigées et le test répété c Valider le fait que l'analyse a été effectuée par une ou plusieurs ressources internes qualifiées ou un tiers qualifiée, et le cas échéant, l'indépendance organisationnelle de la personne qui a effectué le test (il n'est pas exigé d'être un QSA ou un ASV) Vérifier que le test de pénétration comprend des tests de pénétration de la couche réseau. Ces tests doivent comprendre les composants qui prennent en charge les fonctions réseau ainsi que les systèmes d'exploitation Vérifier que le test de pénétration comprend des tests de pénétration de la couche application. Ces tests doivent comprendre au minimum des vulnérabilités répertoriées dans l'exigence a Vérifier l'utilisation des systèmes de détection d'intrusion et/ou des systèmes de prévention d'intrusion et que l'intégralité du trafic dans l'environnement des données de titulaire de carte, ainsi que les points essentiels de cet environnement, sont surveillés b Confirmer que les IDS et/ou IPS sont configurés pour alerter le personnel si l'on suspecte des altérations potentielles c Examiner les configurations des IDS/IPS et confirmer que les dispositifs IPS/IPS sont configurés, maintenus et mis à jour conformément aux instructions du fournisseur pour assurer une protection optimale. Copyright 2010 PCI Security Standards Council LLC Page 69

70 Exigences PCI DSS Procédures de test En 11.5 Déployer des outils de contrôle de l'intégrité des fichiers pour signaler au personnel toute modification non autorisée des fichiers du système, des fichiers de configuration, ou fichiers de contenu essentiels, et configurer le logiciel pour effectuer des comparaisons entre les fichiers essentiels au moins une fois par semaine. Remarque : pour le contrôle de l intégrité des fichiers, les fichiers stratégiques sont généralement ceux qui ne changent pas régulièrement, mais dont la modification pourrait indiquer une altération du système ou son exposition à des risques. Les produits de contrôle de l intégrité des fichiers sont généralement préconfigurés avec les fichiers stratégiques pour le système d exploitation associé. D autres fichiers essentiels, tels que ceux associés aux applications personnalisées, doivent être évalués et définis par l entité (c est-à-dire le commerçant ou le prestataire de services) a Vérifier l'utilisation des outils de contrôle de l'intégrité des fichiers au sein de l'environnement des données de titulaire de carte en observant les paramètres du système et les fichiers surveillés, ainsi que les examens de résultats des activités surveillées. Exemples de fichiers qui doivent être surveillés : les fichiers exécutables du système; les fichiers exécutables de l'application; les fichiers de configuration et de paramètres; les journaux ou fichiers de vérification historiques ou archivés, stockés de manière centralisée b Vérifier que les outils sont configurés pour alerter le personnel de toute modification non autorisée des fichiers essentiels, et pour effectuer des comparaisons de fichiers essentiels au moins une fois par semaine. Copyright 2010 PCI Security Standards Council LLC Page 70

71 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. Une politique de sécurité solide définit la sécurité mise en œuvre à l'échelle de l'entité et indique au personnel ce qu'on attend de lui. Tout le personnel doit être sensibilisé au caractère confidentiel des données et à ses responsabilités dans la protection de ces renseignements. Dans le cadre de l'exigence 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 qui ont accès à l'environnement des donnés de titulaire de carte. Exigences PCI DSS Procédures de test En 12.1 Définir, publier, gérer et diffuser une politique de sécurité qui remplit les fonctions suivantes : Satisfait à toutes les exigences des normes PCI DSS Comprend un processus annuel qui identifie les menaces et les vulnérabilités, et débouche sur une évaluation formelle des risques (Des exemples des méthodologies d'évaluation des risques comprennent, mais sans s'y limiter, OCTAVE, ISO et NIST SP ) Comprend au moins un examen annuel avec mise à jour chaque fois que l'environnement change Élaborer des procédures de sécurité opérationnelles quotidiennes conformes aux exigences de cette spécification (par exemple, des procédures de gestion des comptes d'utilisateur et des procédures d'examen des journaux) Examiner la politique de sécurité des renseignements et vérifier que la politique est publiée et diffusée à tout le personnel concerné (y compris les fournisseurs et les partenaires commerciaux) Vérifier que la politique satisfait à toutes les exigences des normes PCI DSS a Vérifier qu'un processus annuel d'évaluation des risques est documenté pour identifier les menaces et les vulnérabilités, et débouche sur une évaluation formelle des risques b Réviser la documentation d'évaluation des risques pour vérifier que le processus est effectué au moins une fois par an Vérifier que la politique de sécurité des renseignements est révisée au moins une fois par an et mise à jour le cas échéant, pour refléter les changements des objectifs commerciaux ou de l'environnement à risque Examiner les procédures de sécurité opérationnelles quotidiennes. Vérifier qu'elles sont conformes aux spécifications, et comprennent des procédures administratives et techniques pour chacune des exigences. Copyright 2010 PCI Security Standards Council LLC Page 71

72 Exigences PCI DSS Procédures de test En 12.3 Élaborer les politiques d'utilisation des technologies essentielles (par exemple, les technologies d'accès à distance, les technologies sans fil, les supports électroniques amovibles, les ordinateurs portables, les tablettes, les assistants numériques personnels (PDA), l'utilisation de courriels et l'utilisation d'internet) et définir l'usage approprié de ces technologies. S'assurer que ces politiques d'utilisation exigent ce qui suit : Approbation explicite par les parties autorisées Authentification de l'utilisation de la technologie Liste de tous les dispositifs et du personnel disposant d'un accès Marquage des dispositifs pour déterminer leur propriétaire, ses coordonnées et leur usage Usages acceptables des technologies Emments du réseau acceptables pour les technologies Liste des produits approuvés par la société Déconnexion automatique des sessions des technologies d'accès à distance après une période d'inactivité spécifique 12.3 Obtenir et examiner les politiques d'utilisation des technologies essentielles et effectuer ce qui suit : Vérifier que les politiques d'utilisation exigent une approbation explicite des parties autorisées pour utiliser les technologies Vérifier que les politiques d'utilisation exigent que toute utilisation de technologie soit authentifiée avec un ID utilisateur et un mot de passe ou par un autre élément d'authentification (par exemple, un jeton) Vérifier que les politiques d'utilisation exigent une liste de tous les dispositifs et du personnel autorisé à utiliser les dispositifs Vérifier que les politiques d'usage exigent un marquage des dispositifs avec des renseignements indiquant le propriétaire, ses coordonnées et l'usage Vérifier que les politiques d'utilisation exigent des usages acceptables des technologies Vérifier que les politiques d'utilisation exigent des emments de réseau acceptables pour les technologies Vérifier que les politiques d'utilisation exigent une liste des produits approuvés par la société Vérifier que les politiques d'utilisation exigent une déconnexion automatique des sessions des technologies d'accès à distance après une période d'inactivité spécifique. Copyright 2010 PCI Security Standards Council LLC Page 72

73 Exigences PCI DSS Procédures de test En Activation des technologies d'accès à distance pour les fournisseurs et les partenaires commerciaux uniquement lorsqu'ils en ont besoin, avec une désactivation immédiate après utilisation Lors de l'accès du personnel aux données de titulaire de carte au moyen de technologies d'accès à distance, interdire la copie, le dément et le stockage de données de titulaire de carte sur des disques durs locaux et des supports électroniques amovibles, à moins d'une autorisation explicite pour des besoins professionnels définis S'assurer que la politique et les procédures de sécurité définissent clairement les responsabilités de tout le personnel en matière de sécurité des renseignements Attribuer à un individu ou à une équipe les responsabilités suivantes pour la gestion de la sécurité des renseignements : Définir, documenter et diffuser les politiques et les procédures de sécurité Contrôler et analyser les renseignements et les alertes de sécurité, et les diffuser au personnel compétent Vérifier que les politiques d'utilisation exigent une activation des technologies d'accès à distance utilisées par les fournisseurs et les partenaires commerciaux uniquement lorsqu'ils en ont besoin, avec une désactivation immédiate après utilisation a Vérifier que les politiques d'utilisation interdisent la copie, le dément et le stockage de données de titulaire de carte sur des disques durs locaux et des supports électroniques amovibles lors de l'accès à de telles données au moyen de technologies d'accès à distance b Pour le personnel possédant une autorisation adéquate, vérifier que les politiques d'utilisation exigent la protection des données de titulaire de carte conformément aux exigences PCI DSS Vérifier que les politiques de sécurité des renseignements définissent clairement les responsabilités de tout le personnel Vérifier l'attribution formelle de la sécurité des renseignements à un chef de la sécurité ou à un autre membre compétent en sécurité de la direction. Obtenir et examiner les politiques et les procédures de sécurité de l'information pour vérifier que les responsabilités suivantes en la matière sont attribuées de manière spécifique et formelle : Vérifier que la responsabilité de la création et de la diffusion des politiques et des procédures de sécurité est attribué de manière formelle Vérifier que la responsabilité de la surveillance et de l'analyse des alertes de sécurité ainsi que la diffusion des renseignements au personnel approprié de gestion des unités fonctionnelles et de sécurité de l'information est attribuée de manière formelle. Copyright 2010 PCI Security Standards Council LLC Page 73

74 Exigences PCI DSS Procédures de test En Définir, documenter 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 Administrer les comptes d'utilisateur, notamment l'ajout, la suppression et la modification de comptes Surveiller et contrôler tous les accès aux données Mettre en œuvre un programme formel de sensibilisation à la sécurité pour sensibiliser le personnel à l'importance de la sécurité des données de titulaire de carte Sensibiliser le personnel au moment de son recrutement et au moins une fois par an. Remarque : les méthodes peuvent varier en fonction du rôle du personnel et de son niveau d'accès aux données de titulaire de carte Exiger que le personnel reconnaisse au moins une fois par an avoir lu et compris les procédures et la politique de sécurité Vérifier que la responsabilité de la création et de la diffusion des procédures de remontée et de réponse aux incidents liés à la sécurité est attribué de manière formelle Vérifier que la responsabilité de l'administration des comptes et de la gestion de l'authentification est attribuée de manière formelle Vérifier que la responsabilité de la surveillance et du contrôle de tous les accès aux données est attribuée de manière formelle a Vérifier l'existence d'un programme formel de sensibilisation à la sécurité pour tout le personnel b Obtenir et examiner les procédures et la documentation du programme de sensibilisation à la sécurité et effectuer ce qui suit : a Vérifier que le programme de sensibilisation à la sécurité comporte diverses méthodes pour sensibiliser et former le personnel (par exemple, des affiches, des lettres, des mémos, une formation basée sur le Web, des réunions et des promotions) b Vérifier que le personnel suive une formation de sensibilisation dès son embauche et au moins une fois par an Vérifier que le programme de sensibilisation à la sécurité exige du personnel de reconnaître, au moins une fois par an, par écrit ou de manière électronique, qu'il a lu et compris la politique de sécurité des renseignements. Copyright 2010 PCI Security Standards Council LLC Page 74

75 Exigences PCI DSS Procédures de test En 12.7 Passer au crible le personnel potentiel avant de le recruter afin de réduire au minimum les risques d'attaques provenant de sources internes (Des exemples de vérifications d'antécédents comprennent, la vérification des antécédents professionnels, du casier judiciaire, des antécédents en matière de crédit, et des références). Remarque : pour le personnel potentiel à embaucher à certains postes, comme caissier dans un magasin, qui n ont accès qu à un numéro de carte à la fois à l'occasion du traitement d'une transaction, cette exigence n'est qu'une recommandation Si les données de titulaire de carte sont partagées avec des prestataires de services, gérer et mettre en œuvre les politiques et les procédures de gestion de ces derniers, de manière à comprendre : Gérer une liste des prestataires de services Faire signer aux prestataires de services un accord écrit par lequel ils se reconnaissent responsables de la sécurité des données de titulaire de carte en leur possession S'assurer que le processus de sélection des prestataires de services est bien défini, et qu'il comprend notamment des contrôles préalables avant de les engager Se renseigner auprès de la gestion du service des ressources humaines et vérifier que la vérification des antécédents a été effectuée (en respectant les contraintes de la législation locale) pour le personnel potentiel qui aura accès aux données de titulaire de cartes ou à leur environnement, avant son embauche Si l'entité partage des données de titulaire de carte avec des prestataires de services (par exemple, les installations de stockage de bande de sauvegarde, des prestataires de services gérés comme les sociétés d'hébergement sur le Web ou des prestataires de services de sécurité, ou ceux qui reçoivent les données à des fins de modélisation de la fraude), à travers une observation, un examen des politiques et procédures, et un examen de la documentation à l'appui, effectuer ce qui suit : Vérifier qu'une liste des prestataires de services est tenue Vérifier que l'accord écrit comprend la reconnaissance par les prestataires de services de leurs responsabilités de sécuriser les données de titulaire de carte Vérifier que les politiques et procédures sont documentées et ont été suivies, notamment les contrôles préalables à l'engagement d'un fournisseur de service. Copyright 2010 PCI Security Standards Council LLC Page 75

76 Exigences PCI DSS Procédures de test En Gérer un programme qui contrôle la conformité des prestataires de services aux normes PCI DSS au moins une fois par an Mettre en œuvre un plan de réponse aux incidents. Être prêt à réagir immédiatement à toute intrusion dans le système Créer le plan de réponse aux incidents à mettre en œuvre en cas d'intrusion dans le système. S'assurer que le plan prévoit au moins les points suivants : rôles, responsabilités et stratégies de communication et de contact en cas d incident, notamment notification des marques de cartes de paiement, au minimum; procédures de réponse aux incidents spécifiques; procédures de continuité et de reprise des affaires; processus de sauvegarde des données; analyse des exigences légales en matière de signalement des incidents; couverture et réponses de tous les composants stratégiques du système; référence ou inclusion des procédures de réponse aux incidents des marques de cartes de paiement Vérifier que l'entité gère un programme qui contrôle la conformité des prestataires de services aux normes PCI DSS au moins une fois par an Obtenir et examiner le plan de réponse aux incidents et les procédures connexes et effectuer ce qui suit : a Vérifier que le plan de réponse aux incidents comprend : les rôles, les responsabilités et les stratégies de communication en cas d incident, notamment notification des marques de cartes de paiement, au minimum; les procédures de réponse aux incidents spécifiques; les procédures de continuité et de reprise des affaires; les processus de sauvegarde des données; l'analyse des exigences légales pour le report d'incident (par exemple, California Bill 1386 qui exige une notification des clients affectés dans le cas d'un incident réel ou suspecté pour les activités commerciales avec les résidents de Californie, dans leur base de donnés); la couverture et les réponses de tous les composants essentiels du système; la référence ou l'inclusion des procédures de réponse aux incidents des marques de cartes de paiement b Réviser la documentation d'un incident ou d'une alerte précédemment rapportée pour vérifier que les procédures et le plan de réponse aux incidents documenté ont été suivis. Copyright 2010 PCI Security Standards Council LLC Page 76

77 Exigences PCI DSS Procédures de test En Tester le plan au moins une fois par an Vérifier que le plan est testé au moins une fois par an Désigner le personnel spécifique disponible 24 heures sur 24 et sept jours sur sept pour répondre aux alertes Organiser la formation appropriée du personnel en charge de la réponse aux failles de la sécurité Inclure des alertes des systèmes de détection et de prévention des intrusions, et de contrôle de l'intégrité des fichiers Élaborer un processus de modification et un plan de réaction aux incidents en fonction des leçons apprises, et tenir compte de l'évolution du secteur Vérifier par une observation et un examen des politiques, que le personnel désigné est disponible 24 heures sur 24 et 7 jours par semaine pour répondre aux incidents et surveiller la couverture pour toute preuve d'activité non autorisée, une détection de points d'accès sans fil non autorisés, des alertes IDS critiques, et/ou des rapports de systèmes essentiels non autorisés ou de changements du contenu de fichiers Vérifier par l'observation et l'examen des politiques que le personnel ayant la responsabilité de la réponse aux failles de la sécurité est formé périodiquement Vérifier par l'observation et l'examen des processus que la surveillance et la réponse aux alertes par les systèmes de sécurité, comprenant la détection de points d'accès sans fil non autorisés, sont couvertes dans le plan de réponse aux incidents Vérifier par l'observation et l'examen des politique qu'il existe un processus de modification et un plan de réaction aux incidents en fonction des leçons apprises, et tenir compte de l'évolution du secteur. Copyright 2010 PCI Security Standards Council LLC Page 77

78 Annexe A : Autres exigences des normes PCI DSS s appliquant aux fournisseurs d hébergement partagé Exigence A.1 : Les fournisseurs d hébergement partagé doivent protéger l environnement des données de titulaire de carte Comme indiqué dans l exigence 12.8, tous les prestataires de services qui ont accès aux données de titulaire de carte (notamment les prestataires de services d'hébergement partagé) doivent respecter les normes PCI DSS. En outre, l exigence 2.4 stipule que les prestataires de services d'hébergement partagé doivent protéger les données et l'environnement hébergés de chaque entité. En conséquence, les prestataires de services d'hébergement partagé doivent par ailleurs se conformer aux exigences définies dans cette annexe. Exigences Procédures de test En A.1 Protéger les données et l'environnement hébergé de chaque entité (c'est-à-dire le commerçant, le prestataire de services ou toute autre entité), conformément aux exigences A.1.1 à A.1.4 : Un prestataire de services d hébergement doit satisfaire à ces exigences ainsi qu aux autres sections pertinentes des normes PCI DSS. Remarque : même si un prestataire de services d hébergement peut satisfaire à ces exigences, le respect par l'entité qui a recours au prestataire de services d hébergement n'est pas garanti. Chaque entité doit se conformer aux normes PCI DSS et doit valider cette conformité, le cas échéant. A.1 En particulier pour l'évaluation PCI DSS du fournisseur d'hébergement partagé, afin de vérifier que les fournisseurs d'hébergement partagé protègent les données et l'environnement hébergé de l'entité (commerçants et prestataires de services), sélectionner un échantillon des serveurs (Microsoft Windows et Unix/Linux) sur un échantillon représentatif des commerçants et prestataires de services hébergés, et effectuer les points A.1.1 à A.1.4 ci-dessous : ntair es Copyright 2010 PCI Security Standards Council LLC Page 78

79 Exigences Procédures de test En A.1.1 S'assurer que chaque entité ne met en œuvre que les processus qui ont accès à l'environnement des données de titulaire de carte qui la concerne. A.1.2 Restreindre l'accès et les privilèges de chaque entité à son propre environnement de données de titulaire de carte. A.1.1 Si un fournisseur d'hébergement partagé permet aux entités (par exemple, commerçants ou prestataires de services) de mettre en œuvre leurs propres applications, vérifier que ces processus d'application sont mis en œuvre en utilisant l'id unique de l'entité. Par exemple : aucune entité sur le système ne peut utiliser un ID utilisateur de serveur Web partagé. Tous les scripts CGI utilisés par une entité doivent être créés et fonctionner en tant qu'id d'utilisateur unique de l'entité. A.1.2.a Vérifier que l'id d'utilisateur d'un processus d'application n'est pas un utilisateur privilégié (segment racine/admin). A.1.2.b Vérifier que chaque entité (commerçant, prestataire de services) possède les autorisations de lecture, écriture ou d'exécution, uniquement pour les fichiers et répertoires qu'elle possède ou pour des fichiers systèmes nécessaires (restreints par l'autorisation d'un système de fichiers, des listes de contrôle d'accès, de commande chroot, d'interpréteur de commandes extrêmement limité, etc.) Important : les fichiers d'une entité ne peuvent pas être partagés par groupe. A.1.2.c Vérifier que les utilisateurs d'une entité n'ont pas d'accès d'écriture aux données binaires d'un système partagé. A.1.2.d Vérifier que la consultation des entrées du journal est restreinte à l'entité propriétaire. A.1.2.e Pour garantir que chaque entité ne peut pas monopoliser les ressources de serveur pour exploiter les vulnérabilités (par exemple, erreur, fonctionnement et conditions de redémarrage entraînant, par exemple, la saturation de la mémoire tampon), vérifier que des restrictions sont en pour l'utilisation de ces ressources de système : espace de disque; bande passante; mémoire; unité centrale. ntair es Copyright 2010 PCI Security Standards Council LLC Page 79

80 Exigences Procédures de test En A.1.3 S'assurer que la consignation et les journaux de vérification sont activés, uniques à l'environnement des données de titulaire de carte de chaque entité et conformes à l exigence 10 des normes PCI DSS. A.1.4 Activer les processus d'investigation légale rapide en cas d'incident dans l'environnement d'un commerçant ou d'un prestataire de services. A.1.3 Vérifier que le fournisseur d'hébergement partagé possède une journalisation activée comme suit, pour chaque environnement de commerçant et prestataire de services : les journaux sont activés pour des applications courantes de tiers; les journaux sont activés par défaut; les journaux sont disponibles pour révision par l'entité propriétaire; les emments des journaux sont clairement communiqués à l'entité propriétaire. A.1.4 Vérifier que le fournisseur d'hébergement partagé possède des politiques écrites qui autorisent une investigation légale rapide des serveurs connexes en cas d'intrusion. ntair es Copyright 2010 PCI Security Standards Council LLC Page 80

81 Annexe B : Contrôles compensatoires Des contrôles compensatoires peuvent être envisagés lorsqu'une entité ne peut pas se conformer aux exigences PCI DSS telles qu elles sont stipulées, en raison de contraintes commerciales documentées ou de contraintes techniques légitimes, mais qu'elle a parallèlement suffisamment atténué les risques associés par la mise en œuvre d'autres contrôles, appelés «contrôles compensatoires». Les contrôles compensatoires doivent satisfaire aux critères suivants : 1. Respecter l intention et la rigueur de l exigence initiale des normes PCI DSS. 2. Fournir une protection similaire à celle de l exigence initiale des normes PCI DSS, de sorte que le contrôle compensatoire compense suffisamment le risque prévenu par l exigence initiale (Pour plus d'informations sur chaque exigence PCI DSS, voir Parcourir les normes PCI DSS). 3. Aller au-delà des autres exigences PCI DSS (Les contrôles compensatoires ne consistent pas simplement à se trouver en conformité à d autres exigences PCI DSS). Lors de l'évaluation de la portée des contrôles compensatoires, il est essentiel de 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 des normes 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 entreprises doivent avoir conscience qu un contrôle compensatoire particulier ne sera pas efficace dans tous les environnements. a) Les exigences existantes des normes PCI DSS NE PEUVENT PAS être considérées comme des contrôles compensatoires si elles sont déjà exigées pour l'élément examiné. Par exemple, les mots de passe pour l accès administrateur non-console doivent être transmis sous forme cryptée afin de limiter les risques d'interception des mots de passe administrateur en texte clair. Une entité ne peut utiliser d'autres exigences PCI DSS relatives aux mots de passe (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 les normes PCI DSS pour l élément examiné (à savoir les mots de passe). b) Les exigences existantes des normes 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 faisant l'objet d'une vérification. Par exemple, l authentification à deux facteurs est exigée par les normes PCI DSS pour l accès à distance. L authentification à deux facteurs depuis le 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 si : (1) elle satisfait à l intention de l exigence initiale en résolvant les risques d interception des mots de passe administrateur en texte clair, et (2) elle est correctement configurée et mise en œuvre dans un environnement sécurisé. c) Les exigences existantes des normes 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 titulaire de carte illisibles conformément à l exigence 3.4 (par exemple, par cryptage), un contrôle compensatoire pourrait consister en un dispositif ou un ensemble de dispositifs, d'applications et de contrôles qui assurent : (1) la segmentation du réseau interne; (2) le filtrage des adresses IP ou MAC; et (3) l authentification à deux facteurs à partir du réseau interne. 4. Être proportionnels aux risques suppléme qu implique le non-respect de l exigence PCI DSS. Copyright 2010 PCI Security Standards Council LLC Page 81

82 L évaluateur doit évaluer soigneusement les contrôles compensatoires lors de chaque évaluation annuelle des normes PCI DSS afin de confirmer que chaque contrôle compensatoire couvre de manière appropriée le risque ciblé par l exigence initiale des normes 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 pour garantir que les contrôles compensatoires restent efficaces après l'évaluation. Copyright 2010 PCI Security Standards Council LLC Page 82

83 Annexe C : Fiche de contrôles compensatoires Utiliser cette fiche pour définir les contrôles compensatoires pour toute exigence où les contrôles compensatoires sont utilisés pour satisfaire aux exigences PCI DSS. Noter que les contrôles compensatoires doivent également être documentés dans le rapport sur la conformité dans la section de l'exigence PCI DSS correspondante. Remarque : seules les entreprises 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 exigences : Informations requises 1. Contraintes Répertorier les contraintes qui empêchent la conformité avec l exigence 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éme qu induit l'absence du contrôle initial. 4. Définition des contrôles compensatoires 5. Validation 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éme éventuels. Définir comment les contrôles compensatoires ont été validés et testés. 6. Gestion Définir les processus et les contrôles en pour la gestion des contrôles compensatoires. Explication PCI DSS Conditions et procédures d évaluation de sécurité v.2.0 Octobre 2010 Copyright 2010 PCI Security Standards Council LLC Page 83

84 Fiche de contrôles compensatoires Exemple complété Utiliser cette fiche pour définir les contrôles compensatoires pour une exigence notée comme «en» par les contrôles compensatoires. Numéro d exigence : 8.1 Tous les utilisateurs sont-ils identifiés avec un nom d'utilisateur unique qui les autorise à accéder aux composants du système ou aux données de titulaire de carte? Informations requises 1. Contraintes Répertorier les contraintes qui empêchent la conformité avec l exigence 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éme qu induit l'absence du contrôle initial. 4. Définition des contrôles compensatoires 5. Validation 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éme éventuels. Définir comment les contrôles compensatoires ont été validés et testés. 6. Maintenance Définir les processus et les contrôles en pour la maintenance des contrôles compensatoires. Explication La société XYZ utilise des serveurs Unix autonomes sans LDAP. Par conséquent, chacun requiert un nom d utilisateur «racine». La société XYZ ne peut pas gérer le nom d utilisateur «racine» ni consigner toutes les activités de chaque utilisateur «racine». 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. L absence d ID d utilisateur unique et le fait de ne pas pouvoir consigner les informations d'identification introduisent des risques suppléme dans le système de contrôle d accès. 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 «racine» 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. 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 «racine». La société XYZ décrit les processus et les procédures mis en pour éviter la modification, l altération ou la suppression des configurations SU de sorte que des utilisateurs individuels puissent exécuter des commandes de segment racine sans que leurs activités soient consignées ou suivies. PCI DSS Conditions et procédures d évaluation de sécurité v.2.0 Octobre 2010 Copyright 2010 PCI Security Standards Council LLC Page 84

85 PCI DSS Conditions et procédures d évaluation de sécurité v.2.0 Octobre 2010 Copyright 2010 PCI Security Standards Council LLC Page 85

86 Annexe D : Segmentation et échantillonnage des installations commerciales/composants système. Conditions et procédures d évaluation de sécurité PCI DSS version 2.0 Octobre 2010 Copyright 2010 PCI Security Standards Council LLC Page 86