Responsabilité client PCI DSS métrique

1.3.3 Les NSC sont installés entre tous les réseaux sans fil et le CDE, que le réseau sans fil soit ou non un CDE, de telle sorte que :

• Tout le trafic sans fil des réseaux sans fil vers le CDE est refusé par défaut.
• Seul le trafic sans fil ayant une finalité professionnelle autorisée est autorisé à pénétrer dans le CDE.

1.4.2 Le trafic entrant des réseaux non approuvés vers les réseaux approuvés est limité à :

• Communications avec des composants du système autorisés à fournir des services, des protocoles et des ports accessibles au public.
• Réponses à des communications initiées par des composants du système dans un réseau de confiance.
• Tout autre trafic est refusé.

1.5.1 Les contrôles de sécurité sont mis en œuvre sur tous les dispositifs informatiques, y compris les dispositifs appartenant à l'entreprise et aux employés, qui se connectent à la fois à des réseaux non fiables (y compris l'Internet) et au CDE, comme suit :

• Des paramètres de configuration spécifiques sont définis pour empêcher l'introduction de menaces dans le réseau de l'entité.
• Les contrôles de sécurité sont en cours.
• Les contrôles de sécurité ne sont pas modifiables par les utilisateurs des dispositifs informatiques, à moins qu'ils ne soient spécifiquement documentés et autorisés par la direction, au cas par cas et pour une période limitée.
  

2.2.1 Des normes de configuration sont élaborées, mises en œuvre et maintenues pour :

• Couvrir tous les composants du système.
• Remédier à toutes les vulnérabilités connues en matière de sécurité.
• être conforme aux normes de durcissement des systèmes acceptées par l'industrie ou aux recommandations de durcissement des fournisseurs.
• être mis à jour au fur et à mesure de l'identification de nouveaux problèmes de vulnérabilité, conformément à l'exigence 6.3.1.
• être appliqué lorsque de nouveaux systèmes sont configurés et vérifiés comme étant en place avant ou immédiatement après la connexion d'un composant du système à un environnement de production.

2.2.2 Les comptes par défaut des fournisseurs sont gérés comme suit :

• Si le(s) compte(s) par défaut du fournisseur est (sont) utilisé(s), le mot de passe par défaut est modifié conformément à l'exigence 8.3.6.
• Si le(s) compte(s) par défaut du fournisseur n'est (ne sont) pas utilisé(s), il(s) est (sont) supprimé(s) ou désactivé(s).

2.2.3 Les fonctions primaires nécessitant différents niveaux de sécurité sont gérées comme suit :

• Il n'existe qu'une seule fonction primaire sur un composant du système, OU
• Les fonctions primaires de niveaux de sécurité différents qui existent sur le même composant du système sont isolées les unes des autres, OU
• Les fonctions primaires ayant des niveaux de sécurité différents sur le même composant du système sont toutes sécurisées au niveau requis par la fonction ayant le besoin de sécurité le plus élevé.

2.2.5 Si des services, des protocoles ou des démons non sécurisés sont présents :

• La justification commerciale est documentée.
• Des fonctions de sécurité supplémentaires sont documentées et mises en œuvre pour réduire le risque d'utilisation de services, de protocoles ou de démons non sécurisés.

2.3.1 Pour les environnements sans fil connectés au CDE ou transmettant des données de compte, toutes les valeurs par défaut du fournisseur de services sans fil sont modifiées lors de l'installation ou sont confirmées comme étant sûres, y compris, mais sans s'y limiter, les éléments suivants :

• Clés de cryptage sans fil par défaut.
• Mots de passe des points d'accès sans fil.
• Défauts SNMP.
• Toute autre défaillance du fournisseur de services sans fil liée à la sécurité.

2.3.2 Pour les environnements sans fil connectés au CDE ou transmettant des données de compte, les clés de cryptage sans fil sont modifiées comme suit :

• Chaque fois que le personnel ayant connaissance de la clé quitte l'entreprise ou le rôle pour lequel cette connaissance était nécessaire.
• Chaque fois qu'une clé est suspectée ou connue pour être compromise.

• Couverture de tous les lieux où sont stockées les données des comptes.
• Couverture de toutes les données d'authentification sensibles (DAS) stockées avant l'achèvement de l'autorisation. Ce point est une meilleure pratique jusqu'au 31 mars 2025, après quoi il sera exigé dans le cadre de l'exigence 3.2.1 et devra être pleinement pris en compte lors d'une évaluation PCI DSS.
• Limiter la quantité de données stockées et la durée de conservation à ce qui est nécessaire pour répondre aux exigences légales ou réglementaires et/ou commerciales.
• Exigences spécifiques en matière de conservation des données stockées sur les comptes, qui définissent la durée de la période de conservation et comprennent une justification commerciale documentée. Procédures de suppression sécurisée ou d'irrécupération des données de compte lorsqu'elles ne sont plus nécessaires, conformément à la politique de conservation des données.
• Une procédure permettant de vérifier, au moins une fois tous les trois mois, que les données de compte stockées dépassant la période de conservation définie ont été supprimées en toute sécurité ou rendues irrécupérables.

3.3.3 Exigence supplémentaire pour les émetteurs et les entreprises qui soutiennent les services d'émission et stockent des données d'authentification sensibles : Tout stockage de données d'authentification sensibles est interdit :

• Limité à ce qui est nécessaire pour répondre à un besoin légitime de l'entreprise émettrice et qui est sécurisé.
• Cryptée à l'aide d'une cryptographie forte.

3.5.1 Le PAN est rendu illisible partout où il est stocké en utilisant l'une des approches suivantes :

• Hachures à sens unique basées sur une cryptographie forte de l'ensemble du PAN.
• Troncature (le hachage ne peut pas être utilisé pour remplacer le segment tronqué de PAN).
  • Si des versions hachées et tronquées du même PAN, ou différents formats de troncature du même PAN, sont présents dans un environnement, des contrôles supplémentaires sont mis en place afin que les différentes versions ne puissent pas être corrélées pour reconstruire le PAN d'origine.
• Jetons d'index. Une bonne connaissance de la cryptographie et des processus et procédures de gestion des clés qui y sont associés.

3.5.1.3 Si le chiffrement au niveau du disque ou de la partition est utilisé (plutôt que le chiffrement de la base de données au niveau du fichier, de la colonne ou du champ) pour rendre le PAN illisible, il est géré comme suit :

• L'accès logique est géré séparément et indépendamment des mécanismes d'authentification et de contrôle d'accès du système d'exploitation.
• Les clés de décryptage ne sont pas associées à des comptes d'utilisateurs.
• Les facteurs d'authentification (mots de passe, phrases de passe ou clés cryptographiques) qui permettent d'accéder à des données non chiffrées sont stockés en toute sécurité.

3.6.1 Des procédures sont définies et mises en œuvre pour protéger les clés cryptographiques utilisées pour protéger les données des comptes stockés contre la divulgation et l'utilisation abusive :

• L'accès aux clés est limité au plus petit nombre possible de gardiens.
• Les clés de chiffrement sont au moins aussi puissantes que les clés de chiffrement des données qu'elles protègent.
• Les clés de chiffrement des clés sont stockées séparément des clés de chiffrement des données.
• Les clés sont conservées en toute sécurité dans le moins d'endroits et sous les formes les plus diverses.

3.6.1.1 Exigence supplémentaire pour les fournisseurs de services uniquement : Une description documentée de l'architecture cryptographique est maintenue et comprend :

• Détails de tous les algorithmes, protocoles et clés utilisés pour la protection des données des comptes stockés, y compris la force de la clé et la date d'expiration.
• Empêcher l'utilisation des mêmes clés cryptographiques dans les environnements de production et de test. Ce point est une meilleure pratique jusqu'au 31 mars 2025, après quoi il sera exigé dans le cadre de l'exigence 3.6.1 et devra être pleinement pris en compte lors d'une évaluation PCI DSS.
• Description de l’utilisation de la clé pour chaque clé.
• Inventaire de tous les modules de sécurité matériels (HSM), systèmes de gestion des clés (KMS) et autres dispositifs cryptographiques sécurisés (SCD) utilisés pour la gestion des clés, y compris le type et l'emplacement des dispositifs, conformément à l'exigence 12.3.4.

3.6.1.2 Les clés secrètes et privées utilisées pour crypter/décrypter les données des comptes stockés sont conservées à tout moment sous l'une (ou plusieurs) des formes suivantes :

• Cryptée avec une clé de cryptage au moins aussi puissante que la clé de cryptage des données et stockée séparément de la clé de cryptage des données.
• dans un dispositif cryptographique sécurisé (DSC), tel qu'un module de sécurité matériel (HSM) ou un dispositif de point d'interaction approuvé par le STP.
• Sous la forme d’au moins deux composants clés de pleine longueur ou actions clés, conformément à une méthode acceptée par l’industrie.

3.7.4 Des politiques et des procédures de gestion des clés sont mises en œuvre pour les changements de clés cryptographiques pour les clés qui ont atteint la fin de leur cryptopériode, telle que définie par le fournisseur de l'application associée ou le propriétaire de la clé, et basée sur les meilleures pratiques et lignes directrices de l'industrie, y compris les suivantes :

• Une cryptopériode définie pour chaque type de clé utilisé.
• Une procédure de changement de clé à la fin de la cryptopériode définie.
  

3.7.5 Les procédures relatives aux politiques de gestion des clés sont mises en œuvre pour inclure le retrait, le remplacement ou la destruction des clés utilisées pour protéger les données stockées sur les comptes, lorsque cela est jugé nécessaire :

• La clé a atteint la fin de sa période de cryptage définie.
• L'intégrité de la clé a été affaiblie, notamment lorsque le personnel ayant connaissance d'un élément de clé en clair quitte l'entreprise ou le rôle pour lequel l'élément de clé était connu.
• La clé est soupçonnée ou connue pour être compromise.
• Les clés retirées ou remplacées ne sont pas utilisées pour les opérations de chiffrement.
  

4.2 Le PAN est protégé par une cryptographie forte pendant la transmission.

4.2.1 De solides protocoles de cryptographie et de sécurité sont mis en œuvre comme suit pour protéger le PAN lors de sa transmission sur des réseaux ouverts et publics :

• Seules les clés de confiance et les certificats sont acceptés.Les certificats utilisés pour protéger le PAN pendant la transmission sur des réseaux ouverts et publics sont confirmés comme étant valides et n'ont pas expiré ou été révoqués.
• Le protocole utilisé ne prend en charge que des versions ou des configurations sécurisées et ne permet pas de revenir à des versions, des algorithmes, des tailles de clés ou des implémentations non sécurisés, ni de les utiliser.
• Le niveau de cryptage est approprié pour la méthodologie de cryptage utilisée.

5.2.2 La ou les solutions anti-malware déployées :

• Détecte tous les types de logiciels malveillants connus.
• Supprime, bloque ou contient tous les types de logiciels malveillants connus.

5.2.3 Tous les composants du système qui ne sont pas menacés par des logiciels malveillants font l'objet d'une évaluation périodique :

• Une liste documentée de tous les composants du système qui ne sont pas menacés par des logiciels malveillants.
• Identification et évaluation de l'évolution des menaces liées aux logiciels malveillants pour ces composants du système.
• Confirmation que ces composants du système ne nécessitent toujours pas de protection contre les logiciels malveillants.

5.3.2 La (les) solution(s) anti-malware :

• Effectue des analyses périodiques et des analyses actives ou en temps réel.

ou

• Effectuer une analyse comportementale continue des systèmes ou des processus.

6.2.1 Les logiciels sur mesure et personnalisés sont développés en toute sécurité, comme suit :

• Basé sur les normes industrielles et/ou les meilleures pratiques pour un développement sécurisé.
• Conformément à la norme PCI DSS (par exemple, sécurisez authentification et journalisation)
• Intégrer la prise en compte des questions de sécurité de l'information à chaque étape du cycle de développement des logiciels.

6.2.2 Le personnel chargé du développement de logiciels sur mesure et personnalisés est formé au moins une fois tous les 12 mois comme suit :

• Sur la sécurité des logiciels en rapport avec leur fonction et les langages de développement.
• Y compris la conception de logiciels sécurisés et les techniques de codage sécurisées.
• Y compris, si des outils de test de sécurité sont utilisés, comment utiliser les outils pour détecter les vulnérabilités dans les logiciels.

6.2.3 Les logiciels sur mesure et personnalisés sont examinés avant d'être mis en production ou transmis aux clients, afin d'identifier et de corriger les vulnérabilités potentielles du codage, comme suit :

• Les révisions de code garantissent que le code est développé conformément aux directives de codage sécurisé.
• Les examens de code visent à détecter les vulnérabilités existantes et émergentes des logiciels.
• Les corrections appropriées sont mises en œuvre avant la publication.

6.2.3.1 Si des revues de code manuelles sont effectuées pour les logiciels sur mesure et personnalisés avant la mise en production, les modifications de code sont

• Révisé par des personnes autres que l'auteur du code d'origine, et qui connaissent les techniques de révision de code et les pratiques de codage sécurisé.
• Examiné et approuvé par la direction avant sa diffusion.

6.2.4 Des techniques de génie logiciel ou d'autres méthodes sont définies et utilisées par le personnel chargé du développement des logiciels pour prévenir ou atténuer les attaques logicielles courantes et les vulnérabilités connexes dans les logiciels sur mesure et personnalisés, y compris, mais sans s'y limiter, les éléments suivants :

• Les attaques par injection, y compris SQL, LDAP, XPath ou d'autres commandes, paramètres, objets, fautes ou failles de type injection.
• Attaques contre les données et les structures de données, y compris les tentatives de manipulation des tampons, des pointeurs, des données d'entrée ou des données partagées.
• Attaques contre l'utilisation de la cryptographie, y compris les tentatives d'exploitation d'implémentations cryptographiques, d'algorithmes, de suites de chiffrement ou de modes de fonctionnement faibles, peu sûrs ou inappropriés.
• Attaques contre la logique d'entreprise, y compris les tentatives d'abus ou de contournement des caractéristiques et fonctionnalités de l'application par la manipulation des API, des protocoles et canaux de communication, des fonctionnalités côté client, ou d'autres fonctions et ressources du système/de l'application. Il s'agit notamment de scripts intersites (XSS) et de falsifications de requêtes intersites (CSRF). Les attaques contre les mécanismes de contrôle d'accès, y compris les tentatives de contournement ou d'abus des mécanismes d'identification, d'authentification ou d'autorisation, ou les tentatives d'exploitation des faiblesses dans la mise en œuvre de ces mécanismes.
• Attaques par l'intermédiaire de toute vulnérabilité "à haut risque" identifiée dans le cadre du processus d'identification des vulnérabilités, tel que défini dans l'exigence 6.3.1.

6.3.1 Les failles de sécurité sont identifiées et gérées comme suit :

• Les nouvelles failles de sécurité sont identifiées à l'aide de sources d'information sur les failles de sécurité reconnues par l'industrie, notamment les alertes des équipes d'intervention en cas d'urgence informatique nationales et internationales (Certus).
• Les vulnérabilités sont classées par ordre de risque sur la base des meilleures pratiques de l'industrie et en tenant compte de l'impact potentiel.
• Les classements des risques identifient, au minimum, toutes les vulnérabilités considérées comme présentant un risque élevé ou comme critiques pour l'environnement.
• Les vulnérabilités des logiciels sur mesure et personnalisés, ainsi que des logiciels tiers (par exemple les systèmes d'exploitation et les bases de données) sont couvertes.

6.3.3 Tous les composants du système sont protégés contre les vulnérabilités connues en installant les correctifs/mises à jour de sécurité applicables comme suit :

• Les correctifs/mises à jour critiques ou de haute sécurité (identifiés selon le processus de classement des risques de l'exigence 6.3.1) sont installés dans le mois qui suit la publication.
• Tous les autres correctifs ou mises à jour de sécurité applicables sont installés dans un délai approprié déterminé par l'entité (par exemple, dans les trois mois suivant la publication).
  

6.4.1 Pour les applications web destinées au public, les nouvelles menaces et vulnérabilités sont traitées en permanence et ces applications sont protégées contre les attaques connues de la manière suivante :

• Examiner les applications web destinées au public au moyen d'outils ou de méthodes d'évaluation manuelle ou automatisée de la sécurité et de la vulnérabilité des applications, comme suit :
  • Au moins une fois tous les 12 mois et après des changements importants.
  • Par une entité spécialisée dans la sécurité des applications.
  • Y compris, au minimum, toutes les attaques logicielles courantes visées à l'exigence 6.2.4.
  • Toutes les vulnérabilités sont classées conformément à l'exigence 6.3.1.
  • Toutes les vulnérabilités sont corrigées.
  • La demande est réévaluée après les corrections.

ou

• Installer une (des) solution(s) technique(s) automatisée(s) qui détecte(nt) et prévient(nt) en permanence les attaques basées sur le web, comme suit :
  • Installé devant les applications web en contact avec le public, il permet de détecter et de prévenir les attaques basées sur le web.
  • En cours d'exécution et mis à jour le cas échéant.
  • Générer des journaux d'audit.
  • Configuré pour bloquer les attaques basées sur le web ou pour générer une alerte qui sera immédiatement examinée.

6.4.2 Pour les applications web orientées vers le public, une solution technique automatisée est déployée pour détecter et prévenir en permanence les attaques basées sur le web, avec au moins les éléments suivants :

• Il est installé devant les applications web qui font face au public et est configuré pour détecter et prévenir les attaques basées sur le web.
• En cours d'exécution et mis à jour le cas échéant.
• Générer des journaux d'audit.
• Configuré pour bloquer les attaques basées sur le web ou pour générer une alerte qui sera immédiatement examinée.

6.4.3 Tous les scripts des pages de paiement qui sont chargés et exécutés dans le navigateur du consommateur sont gérés comme suit :

• Une méthode est mise en œuvre pour confirmer que chaque script est autorisé.
• Une méthode est mise en œuvre pour garantir l'intégrité de chaque script.
• Un inventaire de tous les scripts est tenu à jour, accompagné d'une justification écrite de la nécessité de chacun d'entre eux.

6.5.1 Les modifications apportées à tous les composants du système dans l'environnement de production sont effectuées conformément aux procédures établies qui comprennent :

• Raison et description du changement.
• Documentation de l'impact sur la sécurité.
• 6.4.5.2 Approbation de changement documentée par les parties autorisées.
• Test pour vérifier que le changement n'a pas d'impact négatif sur la sécurité du système.
• Pour les modifications apportées aux logiciels sur mesure et personnalisés, toutes les mises à jour sont testées pour vérifier leur conformité à l'exigence 6.2.4 avant d'être déployées en production.
• Procédures permettant de remédier aux défaillances et de revenir à un état sûr.

7.2 L'accès aux composants du système et aux données est défini et attribué de manière appropriée.

7.2.1 Un modèle de contrôle d'accès est défini et comprend l'octroi d'un accès comme suit :

• Accès approprié en fonction des activités de l'entité et de ses besoins en matière d'accès.
• L'accès aux composants du système et aux ressources de données est basé sur la classification des emplois et les fonctions des utilisateurs.
• Les privilèges les moins élevés requis (par exemple, utilisateur, administrateur) pour exécuter une fonction.

7.2.2 L'accès est attribué aux utilisateurs, y compris aux utilisateurs privilégiés, sur la base des critères suivants :

• Classification et fonction des emplois.
• Les moindres privilèges nécessaires à l'exercice des responsabilités professionnelles.

7.2.4 Tous les comptes d'utilisateurs et les privilèges d'accès correspondants, y compris les comptes de tiers/fournisseurs, sont examinés comme suit : Au moins une fois tous les six mois.

• Veiller à ce que les comptes d'utilisateur et l'accès restent appropriés en fonction de la fonction.
• Tout accès inapproprié est traité.
• La direction reconnaît que l'accès reste approprié.

7.2.5 Tous les comptes d'application et de système, ainsi que les privilèges d'accès correspondants, sont attribués et gérés comme suit :

• Sur la base des privilèges les plus bas nécessaires au fonctionnement du système ou de l'application.
• L'accès est limité aux systèmes, applications ou processus qui requièrent spécifiquement leur utilisation.

7.2.5.1 Tous les accès par les comptes d'application et de système, ainsi que les privilèges d'accès correspondants, sont examinés comme suit :

• Périodiquement (à la fréquence définie dans l'analyse de risque ciblée de l'entité, qui est effectuée conformément à tous les éléments spécifiés dans l'exigence 12.3.1).
• L'accès à l'application/au système reste adapté à la fonction exercée.
• Tout accès inapproprié est traité.
• La direction reconnaît que l'accès reste approprié.

7.2.6 L'accès de tous les utilisateurs aux référentiels d'interrogation des données stockées sur les titulaires de cartes est limité comme suit :

• Par le biais d'applications ou d'autres méthodes programmatiques, l'accès et les actions autorisées étant basés sur les rôles des utilisateurs et les moindres privilèges.
• Seuls les administrateurs responsables peuvent accéder directement aux référentiels de DCH stockés ou les interroger.

8.2.2 Les comptes de groupe, partagés ou génériques, ou d'autres identifiants d'authentification partagés ne sont utilisés qu'à titre exceptionnel et sont gérés comme suit :

• L'utilisation du compte est interdite, sauf en cas de circonstances exceptionnelles.
• L'utilisation est limitée au temps nécessaire pour la circonstance exceptionnelle.
• La justification de l'utilisation est documentée.
• L'utilisation est explicitement approuvée par la direction. L'identité de chaque utilisateur est confirmée avant que l'accès à un compte ne soit accordé.
• Chaque action entreprise est attribuable à un utilisateur individuel.

8.2.3 Exigence supplémentaire pour les fournisseurs de services uniquement : Les fournisseurs de services ayant un accès à distance aux locaux des clients utilisent des facteurs d'authentification uniques pour chaque local de client.

8.2.4 L'ajout, la suppression et la modification d'identifiants d'utilisateur, de facteurs d'authentification et d'autres objets d'identification sont gérés comme suit :

• Autorisé avec l'approbation appropriée.
• Mis en œuvre avec les seuls privilèges spécifiés dans l'approbation documentée.

8.2.7 Les comptes utilisés par des tiers pour accéder aux composants du système, en assurer l'assistance ou la maintenance à distance, sont gérés comme suit :

• Activé uniquement pendant la période nécessaire et désactivé lorsqu’il n’est pas utilisé.
• L'utilisation est surveillée pour détecter toute activité inattendue.

8.3.1 Tous les accès des utilisateurs et des administrateurs aux composants du système sont authentifiés par au moins l'un des facteurs d'authentification suivants :

• Quelque chose que vous connaissez, tel qu’un mot de passe ou une phrase secrète.
• Quelque chose que vous avez, comme un jeton ou une carte à puce.
• Quelque chose que vous êtes, comme un élément biométrique.

8.3.4 Les tentatives d'authentification non valides sont limitées par :

• Verrouillage de l'identifiant de l'utilisateur après 10 tentatives au maximum.
• Fixer la durée du verrouillage à un minimum de 30 minutes ou jusqu'à ce que l'identité de l'utilisateur soit confirmée.

8.3.5 Si des mots de passe sont utilisés comme facteurs d'authentification pour satisfaire à l'exigence 8.3.1, ils sont définis et réinitialisés pour chaque utilisateur comme suit :

• Réglé sur une valeur unique lors de la première utilisation et lors de la réinitialisation.
• Obligation de changer immédiatement après la première utilisation. 

8.3.6 Si des mots de passe sont utilisés comme facteurs d'authentification pour satisfaire à l'exigence 8.3.1, ils doivent respecter le niveau de complexité minimal suivant :

• Une longueur minimale de 12 caractères (ou si le système ne prend pas en charge 12 caractères, une longueur minimale de huit caractères).
• Contient des caractères numériques et alphabétiques.

8.3.8 Les politiques et procédures d'authentification sont documentées et communiquées à tous les utilisateurs, y compris :

• Conseils pour la sélection de facteurs d'authentification forte.
• Des conseils sur la manière dont les utilisateurs doivent protéger leurs facteurs d'authentification.
• Instructions de ne pas réutiliser les mots de passe/phrases de passe déjà utilisés.
• Instructions pour changer les mots de passe/phrases de passe si l'on soupçonne ou si l'on sait que les mots de passe/phrases de passe ont été compromis et comment signaler l'incident.

8.3.9 Si les mots de passe sont utilisés comme seul facteur d'authentification pour l'accès de l'utilisateur (c'est-à-dire dans toute mise en œuvre d'une authentification à facteur unique), alors soit

• Les mots de passe sont modifiés au moins une fois tous les 90 jours, OU
• Le niveau de sécurité des comptes est analysé de manière dynamique et l'accès aux ressources en temps réel est automatiquement déterminé en conséquence.

8.3.10 Exigence supplémentaire pour les fournisseurs de services uniquement :

Si les mots de passe sont utilisés comme seul facteur d'authentification pour l'accès des utilisateurs du client aux données du titulaire de la carte (c'est-à-dire dans le cadre d'une authentification à facteur unique), des instructions sont fournies aux utilisateurs du client, notamment :

• Conseils aux clients pour qu'ils modifient périodiquement leurs mots de passe/phrases de passe.
• Des conseils sur le moment et les circonstances dans lesquels les mots de passe/phrases de passe doivent être modifiés.

8.3.10.1 Exigence supplémentaire pour les fournisseurs de services uniquement :

Si les mots de passe sont utilisés comme seul facteur d'authentification pour l'accès des utilisateurs des clients (c'est-à-dire dans toute mise en œuvre d'une authentification à facteur unique), alors soit

• Les mots de passe sont modifiés au moins une fois tous les 90 jours, OU
• Le niveau de sécurité des comptes est analysé de manière dynamique et l'accès aux ressources en temps réel est automatiquement déterminé en conséquence. 

8.3.11 Lorsque des facteurs d'authentification tels que des jetons de sécurité physiques ou logiques, des cartes à puce ou des certificats sont utilisés :

• Les facteurs sont attribués à un utilisateur individuel et ne sont pas partagés entre plusieurs utilisateurs.
• Les contrôles physiques et/ou logiques garantissent que seul l'utilisateur prévu peut utiliser ce facteur pour obtenir l'accès.

8.4 L'authentification multifactorielle (AMF) est mise en œuvre pour sécuriser l'accès au CDE.

8.4.1 L'AMF est mise en œuvre pour tous les accès non-consoles au CDE pour le personnel disposant d'un accès administratif.

8.4.2 L'AMF est mise en œuvre pour tous les accès au CDE.

8.4.3 L'AMF est mise en œuvre pour tous les accès au réseau à distance provenant de l'extérieur du réseau de l'entité et susceptibles d'accéder au CDE ou d'avoir un impact sur celui-ci, comme suit :

• Tous les accès à distance de l'ensemble du personnel, utilisateurs et administrateurs, provenant de l'extérieur du réseau de l'entité.
• Tous les accès à distance par des tiers et des vendeurs.

8.5 Les systèmes d'authentification multi-facteurs (MFA) sont configurés pour éviter les abus.

8.5.1 Les systèmes d'AMF sont mis en œuvre comme suit :

• Le système d'AMF n'est pas susceptible de faire l'objet d'attaques par rejeu.
• Les systèmes d'AMF ne peuvent être contournés par aucun utilisateur, y compris les utilisateurs administratifs, sauf si cela est spécifiquement documenté et autorisé par la direction à titre exceptionnel, pour une période de temps limitée.
• Au moins deux types différents de facteurs d'authentification sont utilisés.
• La réussite de tous les facteurs d'authentification est requise pour que l'accès soit accordé.

8.6 L'utilisation des comptes d'application et de système et des facteurs d'authentification associés est strictement gérée.

8.6.1 Si les comptes utilisés par les systèmes ou les applications peuvent être utilisés pour la connexion interactive, ils sont gérés comme suit :

• L'utilisation interactive est interdite, sauf en cas de circonstances exceptionnelles.
• L'utilisation interactive est limitée au temps nécessaire pour la circonstance exceptionnelle.
• La justification commerciale de l'utilisation interactive est documentée.
• L'utilisation interactive est explicitement approuvée par la direction.
• L'identité de l'utilisateur est confirmée avant que l'accès au compte ne soit accordé.
• Chaque action entreprise est attribuable à un utilisateur individuel.

8.6.2 Les mots de passe/phrases de passe pour tous les comptes d'application et de système qui peuvent être utilisés pour une connexion interactive ne sont pas codés en dur dans des scripts, des fichiers de configuration/propriétés ou des codes sources personnalisés.

8.6.3 Les mots de passe/phrases de passe de tous les comptes d'application et de système sont protégés contre les abus de la manière suivante :

• Les mots de passe sont modifiés périodiquement (à la fréquence définie dans l'analyse ciblée des risques de l'entité, qui est effectuée conformément à tous les éléments spécifiés dans l'exigence 12.3.1) et en cas de suspicion ou de confirmation d'une compromission.
• Les mots de passe/phrases de passe sont construits avec une complexité suffisante pour la fréquence à laquelle l'entité modifie les mots de passe/phrases de passe.

9.2.1.1 L'accès physique individuel aux zones sensibles du CDE est surveillé par des caméras vidéo ou des mécanismes de contrôle d'accès physique (ou les deux) comme suit :

• Les points d'entrée et de sortie des zones sensibles du CDE sont surveillés.
• Les dispositifs ou mécanismes de surveillance sont protégés contre la falsification ou la mise hors service.
• Les données collectées sont examinées et mises en corrélation avec d'autres entrées.
• Les données collectées sont conservées pendant au moins trois mois, sauf restrictions légales.

9.3 L'accès physique du personnel et des visiteurs est autorisé et géré.

9.3.1 Des procédures sont mises en œuvre pour autoriser et gérer l'accès physique du personnel au CDE, y compris :

• Identification du personnel.
• Gérer les modifications des conditions d'accès physique d'une personne.
• Révoquer ou mettre fin à l'identification du personnel.
• Limiter l'accès au processus ou au système d'identification au personnel autorisé.

9.3.1.1 L'accès physique du personnel aux zones sensibles du CDE est contrôlé comme suit :

• L'accès est autorisé et basé sur la fonction individuelle.
• L'accès est révoqué immédiatement en cas de résiliation.
• Tous les mécanismes d'accès physique, tels que les clés, les cartes d'accès, etc. sont restitués ou désactivés à la fin du contrat.

9.3.2 Des procédures sont mises en œuvre pour autoriser et gérer l'accès des visiteurs au CDE, notamment :

• Les visiteurs sont autorisés à entrer.
• Les visiteurs sont escortés en permanence.
• Les visiteurs sont clairement identifiés et reçoivent un badge ou une autre pièce d'identité qui expire.
• Des badges pour les visiteurs ou d'autres moyens d'identification permettent de distinguer visiblement les visiteurs du personnel.

9.3.4 Un registre des visiteurs est utilisé pour conserver un enregistrement physique de l'activité des visiteurs dans l'établissement et dans les zones sensibles, y compris :

• Le nom du visiteur et l'organisation représentée.
• La date et l'heure de la visite.
• Le nom du personnel autorisant l'accès physique.
• conserver le journal pendant au moins trois mois, sauf restrictions légales.

9.4.3 Les supports contenant des données relatives aux titulaires de cartes et envoyés en dehors de l'établissement sont sécurisés comme suit :

• Les médias envoyés à l'extérieur de l'établissement sont enregistrés.
• Les médias sont envoyés par un service de messagerie sécurisé ou par une autre méthode de livraison qui peut être suivie avec précision.
• Les journaux de suivi hors site contiennent des informations sur l'emplacement des supports.

9.4.4 La direction approuve tous les supports contenant des données relatives aux titulaires de cartes qui sont déplacés en dehors de l'établissement (y compris lorsque les supports sont distribués à des particuliers).

9.4.5 Des registres d'inventaire de tous les supports électroniques contenant des données relatives aux titulaires de cartes sont tenus.

9.4.5.1 Des inventaires des supports électroniques contenant des données relatives aux titulaires de cartes sont réalisés au moins une fois tous les 12 mois.

9.4.6 Les documents papier contenant des données relatives aux titulaires de cartes sont détruits lorsqu'ils ne sont plus nécessaires pour des raisons commerciales ou juridiques, comme suit :

• Les matériaux sont déchiquetés, incinérés ou réduits en pâte de manière à ce que les données des détenteurs de cartes ne puissent pas être reconstituées.
• Les matériaux sont stockés dans des conteneurs sécurisés avant d'être détruits.

9.4.7 Les supports électroniques contenant des données relatives aux titulaires de cartes sont détruits lorsqu'ils ne sont plus nécessaires pour des raisons commerciales ou juridiques, par l'un des moyens suivants :

• Les supports électroniques sont détruits.
• Les données relatives au titulaire de la carte sont rendues irrécupérables, de sorte qu'il est impossible de les reconstituer.

9.5.1 Les dispositifs d'IOP qui saisissent les données des cartes de paiement par interaction physique directe avec le facteur de forme de la carte de paiement sont protégés contre la falsification et la substitution non autorisée, y compris les éléments suivants :

• Gestion d'une liste d'adresses utiles. Inspecter périodiquement les dispositifs de la POI afin de détecter toute altération ou substitution non autorisée.
• Former le personnel pour qu'il soit conscient des comportements suspects et qu'il signale les altérations ou les substitutions non autorisées de dispositifs.

9.5.1.1 Une liste actualisée des dispositifs de POI est tenue à jour, y compris :

• Marque et modèle de l'appareil.
• Emplacement de l'appareil.
• Numéro de série de l'appareil ou autres méthodes d'identification unique.

9.5.1.3 Une formation est dispensée au personnel travaillant dans les environnements d'IOP afin qu'il soit conscient des tentatives d'altération ou de remplacement des dispositifs d'IOP :

• Vérifier l'identité de toute personne tierce prétendant être du personnel de réparation ou de maintenance, avant de lui donner accès à la modification ou au dépannage des appareils.
• Procédures visant à garantir que les dispositifs ne sont pas installés, remplacés ou renvoyés sans vérification.
• Être attentif aux comportements suspects autour des appareils.
• Signaler au personnel compétent tout comportement suspect et toute indication de falsification ou de substitution de dispositifs.

10.2.1.5 Les journaux d'audit enregistrent toutes les modifications apportées aux informations d'identification et d'authentification, y compris, mais sans s'y limiter, les éléments suivants

• Création de nouveaux comptes.
• L'élévation des privilèges.
• Toutes les modifications, ajouts ou suppressions de comptes avec accès administratif.

10.2.2 Les journaux d'audit enregistrent les détails suivants pour chaque événement contrôlable :

• Notification à l'utilisateur
• Type d'événement.
• Date et heure
• Indication de réussite et d'échec. Origine de l'événement.
• Identité ou nom des données, du composant du système, de la ressource ou du service affecté (par exemple, nom et protocole).

10.4.1 Les journaux d'audit suivants sont examinés au moins une fois par jour :

• Tous les événements de sécurité.
• Journaux de tous les composants du système qui stockent, traitent ou transmettent des données CHD et / ou SAD.
• Journaux de tous les composants critiques du système.
• Journaux de tous les serveurs et composants du système qui remplissent des fonctions de sécurité (par exemple, contrôles de sécurité du réseau, systèmes de détection des intrusions/systèmes de prévention des intrusions (IDS/IPS), serveurs d'authentification).

10.6.1 Les horloges et l'heure du système sont synchronisées à l'aide de la technologie de synchronisation du temps.10.6.1 Les horloges et l'heure du système sont synchronisées à l'aide de la technologie de synchronisation du temps.

10.6.2 Les systèmes sont configurés à l'heure correcte et cohérente comme suit :

• Un ou plusieurs serveurs de temps désignés sont utilisés.
• Seul le(s) serveur(s) horaire(s) central(aux) désigné(s) reçoit(vent) l'heure de sources externes.
• L'heure reçue de sources externes est basée sur le temps atomique international ou le temps universel coordonné (UTC).
• Le(s) serveur(s) de temps désigné(s) n'accepte(nt) que les mises à jour de temps provenant de sources externes spécifiques acceptées par l'industrie.
• Lorsqu'il y a plus d'un serveur de temps désigné, les serveurs de temps s'appuient l'un sur l'autre pour maintenir une heure précise.
• Les systèmes internes ne reçoivent les informations temporelles que du ou des serveurs centraux de temps désignés.

10.6.3 Les paramètres et les données de synchronisation temporelle sont protégés comme suit :

• L'accès aux données temporelles est limité au personnel qui en a besoin.
• Toute modification des paramètres horaires des systèmes critiques est enregistrée, contrôlée et examinée.

10.7.1 Exigence supplémentaire pour les fournisseurs de services uniquement :

Les défaillances des systèmes de contrôle de sécurité critiques sont détectées, signalées et traitées rapidement, y compris, mais sans s'y limiter, les défaillances des systèmes de contrôle de sécurité critiques suivants :

• Contrôles de sécurité des réseaux. IDS/IPS. FIM. Solutions anti-malware.
• Contrôles d'accès physiques.
• Contrôles d'accès logiques.
• Mécanismes d'enregistrement des audits.
• Contrôles de segmentation (si utilisés).

10.7.2 Les défaillances des systèmes de contrôle de sécurité critiques sont détectées, signalées et traitées rapidement, y compris, mais sans s'y limiter, les défaillances des systèmes de contrôle de sécurité critiques suivants :

• Contrôles de sécurité des réseaux.
• IDS/IPS.
• Mécanismes de détection des changements.
• Solutions anti-malware.
• Contrôles d'accès physiques.
• Contrôles d'accès logiques.
• Mécanismes d'enregistrement des audits.
• Contrôles de segmentation (si utilisés).
• Mécanismes d'examen du journal d'audit.
• Outils de test de sécurité automatisés (s'ils sont utilisés).

10.7.3 Les défaillances de tout système de contrôle de sécurité critique font l'objet d'une réaction rapide, y compris, mais sans s'y limiter :

• Restauration des fonctions de sécurité.
• Identifier et documenter la durée (date et heure du début à la fin) de la défaillance de sécurité.
• Identifier et documenter la ou les causes de la défaillance et documenter les mesures correctives requises.
• Identifier et résoudre les problèmes de sécurité survenus pendant la défaillance.
• Déterminer si d'autres actions sont nécessaires à la suite de la défaillance de sécurité.
• Mettre en place des contrôles pour éviter que la cause de l'échec ne se reproduise.
• Reprise de surveillance des contrôles de sécurité.

11.2.1 Les points d'accès sans fil autorisés et non autorisés sont gérés comme suit :

• La présence de points d'accès sans fil (Wi-Fi) est testée, Tous les points d'accès sans fil autorisés et non autorisés sont détectés et identifiés, Le test, la détection et l'identification ont lieu au moins une fois tous les trois mois.
• En cas de surveillance automatisée, le personnel est prévenu par des alertes générées.

11.3.1 Les analyses de vulnérabilité internes sont effectuées comme suit : Au moins une fois tous les trois mois.

• Les vulnérabilités à haut risque et les vulnérabilités critiques (selon le classement des risques de vulnérabilité de l'entité défini à l'exigence 6.3.1) sont résolues.
• Des rescans sont effectués pour confirmer que toutes les vulnérabilités critiques et à haut risque (comme indiqué ci-dessus) ont été résolues.
• L'outil de balayage est mis à jour avec les dernières informations sur les vulnérabilités.
• Les analyses sont effectuées par du personnel qualifié et le testeur jouit d'une indépendance organisationnelle.

11.3.1.1 Toutes les autres vulnérabilités applicables (celles qui ne sont pas classées comme étant à haut risque ou critiques selon le classement des vulnérabilités de l'entité défini à l'exigence 6.3.1) sont gérées comme suit :

• Traitée en fonction du risque défini dans l'analyse de risque ciblée de l'entité, qui est effectuée conformément à tous les éléments spécifiés dans l'exigence 12.3.1.
• Des rescans sont effectués si nécessaire.
  

11.3.1.2 Les analyses de vulnérabilité internes sont effectuées par le biais d'une analyse authentifiée, comme suit :

• Les systèmes qui ne sont pas en mesure d'accepter des informations d'identification pour un balayage authentifié sont documentés.
• Des privilèges suffisants sont utilisés pour les systèmes qui acceptent des informations d'identification pour l'analyse.
• Si les comptes utilisés pour l'analyse authentifiée peuvent être utilisés pour la connexion interactive, ils sont gérés conformément à l'exigence 8.2.2.

11.3.1.3 Les analyses de vulnérabilité internes sont effectuées après tout changement important, comme suit :

• Les vulnérabilités à haut risque et les vulnérabilités critiques (selon le classement des risques de vulnérabilité de l'entité défini à l'exigence 6.3.1) sont résolues.
• Des rescans sont effectués si nécessaire. Les analyses sont effectuées par du personnel qualifié et le testeur jouit d'une indépendance organisationnelle (il n'est pas nécessaire d'être un QSA ou un ASV).

11.3.2 Les analyses de vulnérabilité externes sont effectuées comme suit : Au moins une fois tous les trois mois.

• Par un fournisseur de services d'analyse approuvé par le PCI SSC (ASV).
• Les vulnérabilités sont résolues et les exigences du guide du programme ASV pour une analyse réussie sont respectées.
• Des rescans sont effectués si nécessaire pour confirmer que les vulnérabilités ont été résolues conformément aux exigences du guide du programme ASV pour une analyse réussie.

11.3.2.1 Les analyses de vulnérabilité externes sont effectuées après toute modification importante, comme suit :

• Les vulnérabilités notées 4.0 ou plus par le CVSS sont résolues.
• Des rescans sont effectués si nécessaire.
• Les analyses sont effectuées par du personnel qualifié et le testeur jouit d'une indépendance organisationnelle (il n'est pas nécessaire d'être un QSA ou un ASV).
  

11.4 Des tests de pénétration externes et internes sont régulièrement effectués, et les vulnérabilités exploitables et les faiblesses en matière de sécurité sont corrigées.

11.4.1 Une méthodologie de test de pénétration est définie, documentée et mise en œuvre par l'entité, et comprend :

• Méthodes de test de pénétration acceptées par l'industrie.
• Couverture de l'ensemble du périmètre du CDE et des systèmes critiques.
• Tests effectués à l'intérieur et à l'extérieur du réseau.
• Test de validation des contrôles de segmentation et de réduction du champ d'application.
• des tests de pénétration de la couche applicative pour identifier, au minimum, les vulnérabilités énumérées dans l'exigence 6.2.4.
• Tests de pénétration de la couche réseau qui englobent tous les composants qui prennent en charge les fonctions du réseau ainsi que les systèmes d'exploitation.
• Examen et prise en compte des menaces et des vulnérabilités survenues au cours des 12 derniers mois.
• Approche documentée pour évaluer et traiter le risque posé par les vulnérabilités exploitables et les faiblesses de sécurité découvertes lors des tests de pénétration.
• Conservation des résultats des tests de pénétration et des activités de remédiation pendant au moins 12 mois.

11.4.2 Des tests de pénétration internes sont effectués : Selon la méthodologie définie par l'entité, au moins une fois tous les 12 mois Après toute mise à niveau ou modification importante de l'infrastructure ou de l'application Par une ressource interne qualifiée ou un tiers externe qualifié L'indépendance organisationnelle du testeur existe (il n'est pas nécessaire d'être un QSA ou un ASV).

11.4.3 Des tests de pénétration externes sont effectués : Selon la méthodologie définie par l'entité Au moins une fois tous les 12 mois Après toute mise à niveau ou modification importante de l'infrastructure ou de l'application Par une ressource interne qualifiée ou un tiers externe qualifié L'indépendance organisationnelle du testeur existe (il n'est pas nécessaire d'être un QSA ou un ASV).

11.4.4 Les vulnérabilités exploitables et les faiblesses de sécurité découvertes lors des tests de pénétration sont corrigées comme suit : Conformément à l'évaluation par l'entité du risque posé par le problème de sécurité, tel que défini dans l'exigence 6.3.1. Les tests de pénétration sont répétés pour vérifier les corrections.

11.4.5 Si la segmentation est utilisée pour isoler le CDE des autres réseaux, les tests de pénétration sont effectués sur les contrôles de segmentation comme suit :

• Au moins une fois tous les 12 mois et après toute modification des contrôles/méthodes de segmentation Couvrant tous les contrôles/méthodes de segmentation utilisés.
• Selon la méthodologie de test de pénétration définie par l'entité.
• Confirmer que les contrôles/méthodes de segmentation sont opérationnels et efficaces, et isoler le CDE de tous les systèmes hors du champ de l'audit.
• Confirmation de l'efficacité de toute utilisation de l'isolation pour séparer les systèmes ayant des niveaux de sécurité différents (voir l'exigence 2.2.3).
• Effectué par une ressource interne qualifiée ou une tierce partie externe qualifiée.
• L'indépendance organisationnelle du testeur existe (il n'est pas nécessaire d'être un QSA ou un ASV).

11.4.6 Exigence supplémentaire pour les fournisseurs de services uniquement :

• Si la segmentation est utilisée pour isoler le CDE des autres réseaux, les tests de pénétration sont effectués sur les contrôles de segmentation comme suit : Au moins une fois tous les six mois et après toute modification des contrôles/méthodes de segmentation.
• Couvrir tous les contrôles/méthodes de segmentation utilisés.
• Selon la méthodologie de test de pénétration définie par l'entité.
• Confirmer que les contrôles/méthodes de segmentation sont opérationnels et efficaces, et isoler le CDE de tous les systèmes hors du champ de l'audit.
• Confirmation de l'efficacité de toute utilisation de l'isolation pour séparer les systèmes ayant des niveaux de sécurité différents (voir l'exigence 2.2.3).
• Effectué par une ressource interne qualifiée ou une tierce partie externe qualifiée. L'indépendance organisationnelle du testeur existe (il n'est pas nécessaire d'être un QSA ou un ASV).

11.4.7 Exigence supplémentaire pour les fournisseurs de services multi-locataires uniquement : Les fournisseurs de services multi-locataires aident leurs clients à effectuer des tests de pénétration externes conformément aux exigences 11.4.3 et 11.4.4.

11.5.1 Les techniques de détection et/ou de prévention des intrusions sont utilisées pour détecter et/ou empêcher les intrusions dans le réseau comme suit :

• L'ensemble du trafic est contrôlé au périmètre du CDE.
• L'ensemble du trafic est contrôlé à des points critiques du CDE.
• Le personnel est alerté en cas de suspicion de compromission.
• Tous les moteurs de détection et de prévention des intrusions, les lignes de base et les signatures sont tenus à jour.

11.5.2 Un mécanisme de détection des changements (par exemple, des outils de surveillance de l'intégrité des fichiers) est déployé comme suit :

• Alerter le personnel en cas de modification non autorisée (y compris les changements, les ajouts et les suppressions) de fichiers critiques.
• Effectuer des comparaisons de fichiers critiques au moins une fois par semaine.
  

11.6.1 Un mécanisme de détection des modifications et des manipulations est déployé comme suit :

• Alerter le personnel en cas de modification non autorisée (y compris les indicateurs de compromission, les changements, les ajouts et les suppressions) des en-têtes HTTP et du contenu des pages de paiement telles qu'elles sont reçues par le navigateur du consommateur.
• Le mécanisme est configuré pour évaluer l'en-tête HTTP et la page de paiement reçus.
• Les fonctions du mécanisme sont exécutées comme suit :
  • Au moins une fois tous les sept jours OU
  • Périodiquement (à la fréquence définie dans l'analyse de risque ciblée de l'entité, qui est effectuée conformément à tous les éléments spécifiés dans l'exigence 12.3.1).
    

12.2 Des politiques d'utilisation acceptable des technologies destinées aux utilisateurs finaux sont définies et mises en œuvre.

12.2.1 Les politiques d'utilisation acceptable des technologies destinées aux utilisateurs finaux sont documentées et mises en œuvre :

• 12.3.1 Approbation explicite des parties autorisées.
• 12.3.5 Utilisations acceptables de la technologie.
• Liste des produits approuvés par l'entreprise pour l'utilisation par les employés, y compris le matériel et les logiciels.

12.3.1 Chaque exigence de la norme PCI DSS qui offre une certaine souplesse quant à la fréquence d'exécution (par exemple, les exigences à exécuter périodiquement) est étayée par une analyse de risque ciblée, documentée et comprenant les éléments suivants :

• Identification des actifs à protéger.
• Identification de la (des) menace(s) contre laquelle (lesquelles) l'exigence est protégée.
• Identification des facteurs qui contribuent à la probabilité et/ou à l'impact de la réalisation d'une menace.
• L'analyse qui en résulte détermine, en la justifiant, la fréquence à laquelle l'exigence doit être satisfaite pour réduire au minimum la probabilité que la menace se concrétise.
• Examen de chaque analyse de risque ciblée au moins une fois tous les 12 mois afin de déterminer si les résultats sont toujours valables ou si une analyse de risque actualisée est nécessaire.
• Réalisation d'analyses de risques actualisées en cas de besoin, tel que déterminé par l'examen annuel.

12.3.2 Une analyse ciblée des risques est effectuée pour chaque exigence de la norme PCI DSS à laquelle l'entité satisfait grâce à l'approche personnalisée :

• Des preuves documentées détaillant chaque élément spécifié à l'annexe D : Approche personnalisée (comprenant, au minimum, une matrice des contrôles et une analyse des risques).
• Approbation des preuves documentées par la direction générale.
• Réalisation de l'analyse ciblée des risques au moins une fois tous les 12 mois.

12.3.3 Les suites de chiffrement et les protocoles cryptographiques utilisés sont documentés et examinés au moins une fois tous les 12 mois, et comprennent au minimum les éléments suivants :

• Un inventaire actualisé de toutes les suites de chiffrement et de tous les protocoles cryptographiques utilisés, avec indication de l'objectif et du lieu d'utilisation.
• Suivi actif des tendances de l'industrie en ce qui concerne la viabilité continue de toutes les suites de chiffrement et de tous les protocoles cryptographiques utilisés.
• Une stratégie documentée pour répondre aux changements anticipés dans les vulnérabilités cryptographiques.

12.3.4 Les technologies matérielles et logicielles utilisées sont réexaminées au moins une fois tous les 12 mois, en tenant compte au minimum des éléments suivants :

• Analyse que les technologies continuent à recevoir rapidement des correctifs de sécurité de la part des fournisseurs.
• Analyse que les technologies continuent à soutenir (et n'empêchent pas) la conformité de l'entité à la norme PCI DSS.
• Documentation de toute annonce ou tendance industrielle liée à une technologie, par exemple lorsqu'un fournisseur a annoncé des plans de "fin de vie" pour une technologie.
• Documentation d'un plan, approuvé par la direction générale, visant à remédier aux technologies obsolètes, y compris celles pour lesquelles les fournisseurs ont annoncé des plans de "fin de vie".

12.4.1 Exigence supplémentaire pour les fournisseurs de services uniquement :

• La direction générale est responsable de la protection des données des titulaires de cartes et d'un programme de conformité à la norme PCI DSS :
• Responsabilité globale du maintien de la conformité à la norme PCI DSS.
• Définir une charte pour un programme de conformité PCI DSS et une communication à la direction.

12.4.2 Exigence supplémentaire pour les fournisseurs de services uniquement :

• Des examens sont effectués au moins une fois tous les trois mois pour confirmer que le personnel accomplit ses tâches conformément à l'ensemble des politiques de sécurité et des procédures opérationnelles.
• Les révisions sont effectuées par des personnes autres que celles chargées de l'exécution de la tâche en question et comprennent, sans s'y limiter, les tâches suivantes :
  • Examens quotidiens du journal. Examiner la configuration des contrôles de sécurité du réseau.
  • Appliquer les normes de configuration aux nouveaux systèmes.
  • Répondre aux alertes de sécurité. Processus de gestion du changement.

12.4.2.1 Exigence supplémentaire pour les fournisseurs de services uniquement : Les examens réalisés conformément à l'exigence 12.4.2 sont documentés de manière à inclure :

• Résultats des examens.
• Mesures correctives documentées prises pour toutes les tâches dont il a été constaté qu'elles n'étaient pas exécutées conformément à l'exigence 12.4.2.
• Examen et approbation des résultats par le personnel responsable du programme de conformité à la norme PCI DSS.

12.5.2 Le champ d'application de la norme PCI DSS est documenté et confirmé par l'entité au moins une fois tous les 12 mois et en cas de modification importante de l'environnement concerné. La validation du champ d'application comprend au minimum les éléments suivants

• Identifier tous les flux de données pour les différentes étapes du paiement (par exemple, l'autorisation, le règlement de la capture, les rétrocessions et les remboursements) et les canaux d'acceptation (par exemple, les cartes présentes, les cartes non présentes et le commerce électronique).
• Mise à jour de tous les diagrammes de flux de données conformément à l'exigence 1.2.4.
• Identifier tous les lieux où les données du compte sont stockées, traitées et transmises, y compris, mais sans s'y limiter : 1) tout lieu situé en dehors du CDE actuellement défini, 2) les applications qui traitent les CHD, 3) les transmissions entre systèmes et réseaux, et 4) les sauvegardes de fichiers.
• Identifier tous les composants du système dans le CDE, connectés au CDE, ou qui pourraient avoir un impact sur la sécurité du CDE.
• Identifier tous les contrôles de segmentation utilisés et le ou les environnements à partir desquels le CDE est segmenté, y compris la justification des environnements hors champ.
• Identifier toutes les connexions d'entités tierces ayant accès au CDE.
• Confirmer que tous les flux de données identifiés, les données de compte, les composants du système, les contrôles de segmentation et les connexions de tiers ayant accès au CDE sont inclus dans le champ d'application.

12.5.2.1 Exigence supplémentaire pour les fournisseurs de services uniquement :

• Le champ d'application de la norme PCI DSS est documenté et confirmé par l'entité au moins une fois tous les six mois et en cas de modification importante de l'environnement concerné.
• La validation du champ d'application comprend au minimum tous les éléments spécifiés dans l'exigence 12.5.2.

12.6.3 Le personnel reçoit une formation de sensibilisation à la sécurité comme suit :

• Dès l'embauche et au moins une fois tous les 12 mois. Plusieurs méthodes de communication sont utilisées.
• Le personnel reconnaît au moins une fois tous les 12 mois qu'il a lu et compris la politique et les procédures en matière de sécurité de l'information.

12.8.2 Les accords écrits avec les TPSP sont maintenus comme suit :

• Des accords écrits sont conclus avec tous les TPSP avec lesquels des données de compte sont partagées ou qui pourraient affecter la sécurité du CDE.
• Les accords écrits comprennent la reconnaissance par les TPSP qu'ils sont responsables de la sécurité des données de compte qu'ils possèdent ou qu'ils stockent, traitent ou transmettent pour le compte de l'entité, ou dans la mesure où ils pourraient avoir une incidence sur la sécurité du CDE de l'entité.

12.9 Les fournisseurs de services tiers (TPSP) aident leurs clients à se conformer à la norme PCI DSS.

12.9.1 Exigence supplémentaire pour les fournisseurs de services uniquement : Les TPSP reconnaissent par écrit aux clients qu'ils sont responsables de la sécurité des données de compte que le TPSP possède ou stocke, traite ou transmet pour le compte du client, ou dans la mesure où elles pourraient avoir un impact sur la sécurité du CDE du client.

12.9.2 Exigence supplémentaire pour les fournisseurs de services uniquement : Les TPSP répondent aux demandes d'information de leurs clients pour satisfaire aux exigences 12.8.4 et 12.8.5 en fournissant les éléments suivants à la demande du client :

• Informations sur le statut de conformité PCI DSS pour tout service que le TPSP effectue pour le compte de clients (exigence 12.8.4).
• Informations sur les exigences PCI DSS qui relèvent de la responsabilité du TPSP et sur celles qui relèvent de la responsabilité du client, y compris les responsabilités partagées (exigence 12.8.5).

12.10.1 Un plan d'intervention en cas d'incident existe et est prêt à être activé en cas d'incident de sécurité suspecté ou confirmé. Le plan comprend, entre autres, les éléments suivants

• Rôles, responsabilités et stratégies de communication et de contact en cas d'incident de sécurité suspecté ou confirmé, y compris la notification des sociétés de paiement et des acquéreurs, au minimum.
• Procédures de réponse aux incidents avec des activités spécifiques de confinement et d'atténuation pour différents types d'incidents.
• Procédures de reprise et de continuité des activités.Processus de sauvegarde de données.
• Analyse des exigences légales pour signaler les compromis.
• Couverture et réponses de tous les composants critiques du système.
• Référence ou inclusion des procédures d’incident réponse des marques de paiement.

12.10.2 Au moins une fois tous les 12 mois, le plan d'intervention en cas d'incident de sécurité est examiné :

• Le contenu est revu et mis à jour si nécessaire.
• Testé, y compris tous les éléments énumérés dans l'exigence 12.10.1.

12.10.5 Le plan d'intervention en cas d'incident de sécurité comprend la surveillance et la réponse aux alertes provenant des systèmes de surveillance de la sécurité, y compris, mais sans s'y limiter :

• Systèmes de détection et de prévention des intrusions.
• Contrôles de sécurité des réseaux.
• Mécanismes de détection des modifications pour les fichiers critiques.
• Mécanisme de détection des modifications et des manipulations pour les pages de paiement. Ce point est une meilleure pratique jusqu'à sa date d'entrée en vigueur.

12.10.7 Des procédures d'intervention en cas d'incident ont été mises en place et doivent être déclenchées dès la détection d'un PAN stocké dans un endroit où il n'est pas attendu :

• Déterminer ce qu'il convient de faire si le PAN est découvert en dehors du CDE, y compris sa récupération, sa suppression sécurisée et/ou sa migration dans le CDE actuellement défini, le cas échéant.
• Déterminer si des données d'authentification sensibles sont stockées avec le PAN.
• Déterminer d'où proviennent les données du compte et comment elles se sont retrouvées là où elles n'étaient pas attendues.
• Remédier aux fuites de données ou aux lacunes dans les processus qui ont fait que les données du compte se sont retrouvées là où elles n'étaient pas attendues.