Cet article décrit comment les Normes de sécurité sur les données de l’industrie des cartes de paiement (PCI DSS) doivent être satisfaites pour utiliser la plate Genesys Cloud forme Genesys Cloud manière conforme à la norme PCI. Conformément à l’exigence 12.8.5, cet article indique où le client, Genesys Cloud ou les deux ont la responsabilité de satisfaire à chaque exigence PCI DSS. Les responsabilités indiquées dans matrice extensible ci-dessous ne remplacent ni ne remplacent les exigences PCI DSS préexistantes déjà applicables par les clients et applicables à leurs propres systèmes et pratiques.*

* Par exemple, dans la matrice extensible ci-dessous, la section 5 traite de la responsabilité de protéger tous les systèmes et réseaux contre les logiciels malveillants. Cette section de la matrice s’applique aux systèmes contrôlés par Genesys Cloud. Comme le montre la section 5.2.1, Genesys Cloud est responsable du déploiement du logiciel antivirus sur les systèmes contrôlés par Genesys Cloud. Les clients n’ont aucune responsabilité supplémentaire pour déployer un logiciel antivirus sur les systèmes contrôlés par Genesys Cloud. Toutefois, les clients ont toujours la responsabilité de déployer un logiciel anti-virus sur des systèmes que ceux qu’ils contrôlent.

La plate-forme Genesys Cloud a obtenu une évaluation PCI DSS en tant que fournisseur de services de niveau 1 en utilisant la version 4.0 de la norme PCI DSS. L'attestation de conformité sera fournie aux clients en vertu d'un accord de non-divulgation. Seules les fonctionnalités Genesys Cloud indiquées dans le rapport de conformité comme étant certifiées PCI peuvent être utilisées pour traiter, transmettre ou stocker des informations de carte de crédit. Les exigences PCI DSS qui s’appliquent uniquement à une fonctionnalité Genesys Cloud donnée sont indiquées dans la matrice responsabilité. Si un client n’utilise que notamment Genesys Cloud fonctionnalité, ces exigences ne sont pas applicables.

La matrice applique ci - dessous pour les clients utilisant le natif Genesys Cloud - Genesys Cloud fonctionnalité. Lorsqu'un client utilise un produit tiers, comme des applications du AppFoundry ou des technologies utilisant le Apportez votre propre modèle de services technologiques, le client et le fournisseur de services tiers peuvent avoir des responsabilités partagées supplémentaires. Ces responsabilités sont partagées entre le client et le prestataire de services tiers. Le client doit vérifier auprès du fournisseur de services tiers la conformité PCI DSS et les responsabilités partagées. Genesys Cloud ne partage aucune responsabilité PCI DSS supplémentaire dans cette situation.

Pour plus d’informations, voir Conformité PCI DSS.

Exigence PCI DSS -- Genesys Cloud Client caractéristique Notes
1.1 Les processus et les mécanismes d'installation et de maintien des contrôles de sécurité du réseau sont définis et compris. X
1.1.1 Toutes les politiques de sécurité et les procédures opérationnelles identifiées dans l'exigence 1 sont : Documenté, tenu à jour, utilisé, connu de toutes les parties concernées. X
1.1.2 Les rôles et responsabilités pour la réalisation des activités de l'exigence 1 sont documentés, attribués et compris. X
1.2 Les contrôles de sécurité du réseau sont configurés et maintenus. X
1.2.1 Les normes de configuration pour les ensembles de règles NSC sont les suivantes Défini, mis en œuvre et maintenu. X
1.2.2 Toutes les modifications apportées aux connexions réseau et aux configurations des NSC sont approuvées et gérées conformément au processus de contrôle des modifications défini dans l'exigence 6.5.1. X
1.2.3 Un ou plusieurs diagrammes de réseau précis sont tenus à jour et indiquent toutes les connexions entre le CDE et d'autres réseaux, y compris les réseaux sans fil. X
1.2.4 Un ou plusieurs diagrammes de flux de données précis sont tenus à jour et répondent aux critères suivants : Indique tous les flux de données de compte à travers les systèmes et les réseaux. Mise à jour si nécessaire en fonction de l'évolution de l'environnement. X
1.2.5 Tous les services, protocoles et ports autorisés sont identifiés, approuvés et répondent à un besoin professionnel défini. X
1.2.6 Des dispositifs de sécurité sont définis et mis en œuvre pour tous les services, protocoles et ports utilisés et considérés comme peu sûrs, de manière à atténuer le risque. X Aucun service, protocole ou port non sécurisé n'est autorisé dans l'environnement.
1.2.7 Les configurations des CSN sont réexaminées au moins une fois tous les six mois pour confirmer qu'elles sont pertinentes et efficaces. X
1.2.8 Les fichiers de configuration des NSC sont les suivants Sécurisé contre les accès non autorisés, cohérent avec les configurations actives du réseau. X
1.3 L'accès au réseau depuis et vers l'environnement des données du titulaire de la carte est limité. X
1.3.1 Le trafic entrant vers le CDE est limité comme suit : Ne faire circuler que ce qui est nécessaire. Tout autre trafic est spécifiquement refusé. X
1.3.2 Le trafic sortant du CDE est limité comme suit : Ne faire circuler que ce qui est nécessaire. Tout autre trafic est spécifiquement refusé. X

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.
X Aucune technologie sans fil n'est autorisée dans l'environnement.
1.4 Les connexions entre réseaux fiables et non fiables sont contrôlées. X
1.4.1 Les NSC sont mis en œuvre entre les réseaux de confiance et les réseaux non fiables. X

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é.
X
1.4.3 Des mesures anti-spoofing sont mises en œuvre pour détecter et bloquer les adresses IP source falsifiées afin qu'elles n'entrent pas dans le réseau de confiance. X
1.4.4 Les composants du système qui stockent les données des titulaires de cartes ne sont pas directement accessibles à partir de réseaux non fiables. X Genesys n'enregistre pas les données des titulaires de cartes.
1.4.5 La divulgation des adresses IP internes et des informations de routage est limitée aux seules parties autorisées. X
1.5 Les risques pour le CDE provenant de dispositifs informatiques capables de se connecter à la fois à des réseaux non fiables et au CDE sont atténués. X

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

Exigence PCI DSS -- Genesys Cloud Client caractéristique Notes
2.1 Les processus et les mécanismes permettant d'appliquer des configurations sécurisées à tous les composants du système sont définis et compris. X
2.1.1 Toutes les politiques de sécurité et les procédures opérationnelles identifiées dans l'exigence 2 sont : Documenté. Tenue à jour. En cours d'utilisation. Connu de toutes les parties concernées. X
2.1.2 Les rôles et responsabilités pour la réalisation des activités de l'exigence 2 sont documentés, attribués et compris. X  
2.2 Les composants du système sont configurés et gérés en toute sécurité. X

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

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).
X

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é.
X
2.2.4 Seuls les services, protocoles, démons et fonctions nécessaires sont activés, et toutes les fonctionnalités inutiles sont supprimées ou désactivées. X

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.
X
2.2.6 Les paramètres de sécurité du système sont configurés pour éviter les abus. X
2.2.7 Tous les accès administratifs non-consoles sont cryptés à l'aide d'une cryptographie forte. X
2.3 Les environnements sans fil sont configurés et gérés en toute sécurité. X

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é.
X Aucune technologie sans fil n'est autorisée dans l'environnement.

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.
X Aucune technologie sans fil n'est autorisée dans l'environnement.

Exigence PCI DSS -- Genesys Cloud Client caractéristique Notes
3.1 Les processus et les mécanismes de protection des données stockées sur les comptes sont définis et compris. X Genesys Cloud ne stocke pas les données du titulaire de carte.
3.1.1 Toutes les politiques de sécurité et les procédures opérationnelles identifiées dans l'exigence 3 sont : Documenté. Tenue à jour. En cours d'utilisation. Connu de toutes les parties concernées. X X  
3.1.2 Les rôles et responsabilités pour la réalisation des activités de l'exigence 3 sont documentés, attribués et compris. X X  
3.2 Le stockage des données de compte est réduit au minimum. X Genesys Cloud ne stocke pas les données du titulaire de carte.
3.2.1 Le stockage des données relatives aux comptes est réduit au minimum grâce à la mise en œuvre de politiques, de procédures et de processus de conservation et d'élimination des données qui comprennent au moins les éléments suivants :
  • 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.
X Genesys Cloud ne stocke pas les données du compte.
3.3 Les données d'authentification sensibles (SAD) ne sont pas stockées après autorisation. X Genesys Cloud ne stocke pas les données du titulaire de carte.
3.3.1 Le DAU n'est pas conservé après autorisation, même s'il est crypté. Toutes les données d'authentification sensibles reçues sont rendues irrécupérables à l'issue de la procédure d'autorisation. X Genesys ne stocke pas les données des titulaires de cartes.
3.3.1.1 Le contenu intégral d'une piste n'est pas conservé à l'issue de la procédure d'autorisation. X Genesys ne stocke pas les données des titulaires de cartes.
3.3.1.2 Le code de vérification de la carte n'est pas conservé à l'issue de la procédure d'autorisation. X Genesys ne stocke pas les données des titulaires de cartes.
3.3.1.3 Le numéro d'identification personnel (PIN) et le bloc PIN ne sont pas conservés à l'issue de la procédure d'autorisation. X Genesys ne stocke pas les données des titulaires de cartes.
3.3.2 Les DAU stockés électroniquement avant l'achèvement de l'autorisation sont cryptés à l'aide d'une cryptographie forte. X Genesys ne stocke pas les données des titulaires de cartes.

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.
X Genesys n'est pas un émetteur.
3.4 L'accès à l'affichage du PAN complet et la possibilité de copier le PAN sont restreints. X Genesys Cloud ne stocke pas les données du titulaire de carte.
3.4.1 Le PAN est masqué lorsqu'il est affiché (le BIN et les quatre derniers chiffres sont le nombre maximum de chiffres à afficher), de sorte que seul le personnel ayant un besoin professionnel légitime peut voir plus que le BIN et les quatre derniers chiffres du PAN. X Genesys Cloud ne stocke pas les données du titulaire de carte.
3.4.2 Lors de l'utilisation de technologies d'accès à distance, les contrôles techniques empêchent la copie et/ou le déplacement du PAN pour l'ensemble du personnel, sauf pour les personnes disposant d'une autorisation explicite et documentée et d'un besoin professionnel légitime et défini. X Genesys ne stocke pas les données des titulaires de cartes.
3.5 Le numéro de compte primaire (PAN) est sécurisé quel que soit l'endroit où il est stocké. X Genesys Cloud ne stocke pas les données du titulaire de carte.

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.
X Genesys Cloud ne stocke pas les données du titulaire de carte.
3.5.1.1 Les hachages utilisés pour rendre le PAN illisible (conformément au premier point de l'exigence 3.5.1) sont des hachages cryptographiques à clé de l'ensemble du PAN, avec des processus et des procédures de gestion des clés associés, conformément aux exigences 3.6 et 3.7. X Genesys Cloud ne stocke pas les données du titulaire de carte.
3.5.1.2 Si le chiffrement au niveau du disque ou de la partition (plutôt que le chiffrement de la base de données au niveau du fichier, de la colonne ou du champ) est utilisé pour rendre le PAN illisible, il est mis en œuvre uniquement de la manière suivante : Sur des supports électroniques amovibles OU S'il est utilisé pour des supports électroniques non amovibles, le PAN est également rendu illisible par un autre mécanisme répondant à l'exigence 3.5.1. X Genesys Cloud ne stocke pas les données du titulaire de carte.

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é.
X Genesys Cloud ne stocke pas les données du titulaire de carte.
3.6 Les clés cryptographiques utilisées pour protéger les données stockées sur les comptes sont sécurisées. X Genesys Cloud ne stocke pas les données du titulaire de carte.

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.
X Genesys Cloud ne stocke pas les données du titulaire de carte.

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.
X Genesys Cloud ne stocke pas les données du titulaire de carte.

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.
X Genesys Cloud ne stocke pas les données du titulaire de carte.
3.6.1.3 L'accès aux composants des clés cryptographiques en clair est limité au plus petit nombre possible de dépositaires. X Genesys Cloud ne stocke pas les données du titulaire de carte.
3.6.1.4 Les clés cryptographiques sont stockées dans le moins d'endroits possibles. X Genesys Cloud ne stocke pas les données du titulaire de carte.
3.7 Lorsque la cryptographie est utilisée pour protéger les données des comptes stockés, des processus et des procédures de gestion des clés couvrant tous les aspects du cycle de vie des clés sont définis et mis en œuvre. X Genesys Cloud ne stocke pas les données du titulaire de carte.
3.7.1 Des politiques et des procédures de gestion des clés sont mises en œuvre pour inclure la génération de clés cryptographiques fortes utilisées pour protéger les données des comptes stockés.
X Genesys Cloud ne stocke pas les données du titulaire de carte.
3.7.2 Des politiques et des procédures de gestion des clés sont mises en œuvre pour assurer la distribution sécurisée des clés cryptographiques utilisées pour protéger les données stockées sur les comptes.
X Genesys Cloud ne stocke pas les données du titulaire de carte.
3.7.3 Des politiques et des procédures de gestion des clés sont mises en œuvre afin d'inclure le stockage sécurisé des clés cryptographiques utilisées pour protéger les données stockées sur les comptes.
X Genesys Cloud ne stocke pas les données du titulaire de carte.

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.
X Genesys Cloud ne stocke pas les données du titulaire de carte.

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.
X Genesys Cloud ne stocke pas les données du titulaire de carte.
3.7.6 Lorsque des opérations manuelles de gestion de clés cryptographiques en clair sont effectuées par le personnel, les politiques et procédures de gestion des clés mises en œuvre comprennent la gestion de ces opérations en utilisant une connaissance partagée et un double contrôle.
X Genesys Cloud ne stocke pas les données du titulaire de carte.
3.7.7 Les politiques et procédures de gestion des clés sont mises en œuvre de manière à prévenir la substitution non autorisée des clés cryptographiques.
X Genesys Cloud ne stocke pas les données du titulaire de carte.
3.7.8 Les politiques et procédures de gestion des clés sont mises en œuvre de manière à ce que les détenteurs de clés cryptographiques reconnaissent formellement (par écrit ou par voie électronique) qu'ils comprennent et acceptent leurs responsabilités en tant que détenteurs de clés.
X Genesys Cloud ne stocke pas les données du titulaire de carte.
3.7.9 Exigence supplémentaire pour les fournisseurs de services uniquement : Lorsqu'un prestataire de services partage des clés cryptographiques avec ses clients pour la transmission ou le stockage de données de compte, des orientations sur la transmission, le stockage et la mise à jour sécurisés de ces clés sont documentées et distribuées aux clients du prestataire de services.
X Genesys Cloud ne stocke pas les données du titulaire de carte.

Exigence PCI DSS -- Genesys Cloud Client caractéristique Notes
4.1 Les processus et les mécanismes de protection des données des titulaires de cartes par une cryptographie forte lors de la transmission sur des réseaux ouverts et publics sont définis et documentés.
X
4.1.1 Toutes les politiques de sécurité et les procédures opérationnelles identifiées dans l'exigence 4 sont : Documenté. Tenue à jour. En cours d'utilisation. Connu de toutes les parties concernées. X
4.1.2 Les rôles et responsabilités pour la réalisation des activités de l'exigence 4 sont documentés, attribués et compris. X  

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

X

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.
X
4.2.1.1 Un inventaire des clés et des certificats de confiance de l'entité utilisés pour protéger le PAN pendant la transmission est tenu à jour. X
4.2.1.2 Les réseaux sans fil transmettant le PAN ou connectés au CDE utilisent les meilleures pratiques de l'industrie pour mettre en œuvre une cryptographie forte pour l'authentification et la transmission. X Aucune technologie sans fil n'est présente dans l'environnement.
4.2.2 Le PAN est sécurisé par une cryptographie forte chaque fois qu'il est envoyé via les technologies de messagerie de l'utilisateur final. X

Exigence PCI DSS -- Genesys Cloud Client caractéristique Notes
5.1 Les processus et les mécanismes de protection de tous les systèmes et réseaux contre les logiciels malveillants sont définis et compris. X
5.1.1 Toutes les politiques de sécurité et les procédures opérationnelles identifiées dans l'exigence 5 sont : Documenté. Tenue à jour. En cours d'utilisation. Connu de toutes les parties concernées. X
5.1.2 Les rôles et responsabilités pour la réalisation des activités de l'exigence 5 sont documentés, attribués et compris. X
5.2 Les logiciels malveillants sont évités, ou détectés et traités.
X
5.2.1 Une ou plusieurs solutions anti-malware sont déployées sur tous les composants du système, à l'exception des composants identifiés lors des évaluations périodiques prévues par l'exigence 5.2.3, qui concluent que les composants du système ne sont pas menacés par des logiciels malveillants. X

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

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.
X
5.2.3.1 La fréquence des évaluations périodiques des composants du système identifiés comme ne présentant pas de risque de logiciels malveillants est définie dans l'analyse de risque ciblée de l'entité, qui est réalisée conformément à tous les éléments spécifiés dans l'exigence 12.3.1. X
5.3 Les mécanismes et processus de lutte contre les logiciels malveillants sont actifs, maintenus et surveillés. X
5.3.1 La (les) solution(s) anti-malware est (sont) maintenue(s) à jour par des mises à jour automatiques. X

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.
X
5.3.2.1 Si des analyses périodiques de logiciels malveillants sont effectuées pour répondre à l'exigence 5.3.2, la fréquence des analyses est 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. X
5.3.3 Pour les supports électroniques amovibles, la ou les solutions antimalware : Effectue des analyses automatiques lorsque le support est inséré, connecté ou monté logiquement, OU Effectue une analyse comportementale continue des systèmes ou des processus lorsque le support est inséré, connecté ou monté logiquement. X
5.3.4 Les journaux d'audit de la ou des solutions anti-malware sont activés et conservés conformément à l'exigence 10.5.1. X
5.3.5 Les mécanismes anti-programmes malveillants ne peuvent pas être désactivés ou modifiés par les utilisateurs, sauf si cela est spécifiquement documenté et autorisé par la direction au cas par cas pour une période de temps limitée. X
5.4 Les mécanismes anti-hameçonnage protègent les utilisateurs contre les attaques d'hameçonnage. X
5.4.1 Des processus et des mécanismes automatisés sont en place pour détecter et protéger le personnel contre les attaques par hameçonnage. X

Exigence PCI DSS -- Genesys Cloud Client caractéristique Notes
6.1 Les processus et les mécanismes de développement et de maintenance de systèmes et de logiciels sûrs sont définis et compris. X
6.1.1 Toutes les politiques de sécurité et les procédures opérationnelles identifiées dans l'exigence 6 sont : Documenté. Tenue à jour. En cours d'utilisation. Connu de toutes les parties concernées.
X
6.1.2 Les rôles et responsabilités pour la réalisation des activités de l'exigence 6 sont documentés, attribués et compris. X
6.2 Les logiciels sur mesure et personnalisés sont développés en toute sécurité. X

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

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

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

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

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.
X
6.3 Les vulnérabilités en matière de sécurité sont identifiées et traitées. X

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.
X
6.3.2 Un inventaire des logiciels sur mesure et personnalisés, ainsi que des composants logiciels tiers incorporés dans les logiciels sur mesure et personnalisés, est tenu à jour afin de faciliter la gestion des vulnérabilités et des correctifs. X

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).
X
6.4 Les applications web destinées au public sont protégées contre les attaques. X

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

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

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.
X Genesys n'utilise pas de scripts pour les pages de paiement.
6.5 Les modifications apportées à tous les composants du système sont gérées en toute sécurité. X

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.
X
6.5.2 À l'issue d'un changement important, il est confirmé que toutes les exigences PCI DSS applicables sont en place sur tous les systèmes et réseaux nouveaux ou modifiés, et la documentation est mise à jour le cas échéant. X
6.5.3 Les environnements de pré-production sont séparés des environnements de production et cette séparation est assurée par des contrôles d'accès. X
6.5.4 Les rôles et les fonctions sont séparés entre les environnements de production et de pré-production afin de garantir que seules les modifications examinées et approuvées sont déployées. X
6.5.5 Les Live PANs ne sont pas utilisés dans les environnements de pré-production, sauf si ces environnements sont inclus dans le CDE et protégés conformément à toutes les exigences PCI DSS applicables. X
6.5.6 Les données et les comptes de test sont retirés des composants du système avant que celui-ci ne soit mis en production. X

Exigence PCI DSS -- Genesys Cloud Client caractéristique Notes
7.1 Les processus et les mécanismes permettant de restreindre l'accès aux composants du système et aux données des titulaires de cartes en fonction du besoin d'en connaître sont définis et compris. X X  
7.1.1 Toutes les politiques de sécurité et les procédures opérationnelles identifiées dans l'exigence 7 sont : Documenté. Tenue à jour. En cours d'utilisation. Connu de toutes les parties concernées.
X X  
7.1.2 Les rôles et responsabilités pour la réalisation des activités de l'exigence 7 sont documentés, attribués et compris. X X  

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

X X

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

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.
X X
7.2.3 Les privilèges requis sont approuvés par le personnel autorisé. X X

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é.
X X

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

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é.
X X

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.
X Genesys ne stocke pas les données des titulaires de cartes.
7.3 L'accès aux composants et aux données du système est géré par un ou plusieurs systèmes de contrôle d'accès.
X X
7.3.1 Il existe un ou plusieurs systèmes de contrôle d'accès qui limitent l'accès en fonction du besoin de savoir de l'utilisateur et qui couvrent tous les composants du système.
X X
7.3.2 Le(s) système(s) de contrôle d'accès est (sont) configuré(s) pour appliquer les autorisations attribuées aux individus, aux applications et aux systèmes sur la base de la classification des emplois et des fonctions.
X X
7.3.3 Le(s) système(s) de contrôle d'accès est(sont) réglé(s) par défaut sur "refuser tout".
X X

Exigence PCI DSS -- Genesys Cloud Client caractéristique Notes
8.1 Les processus et mécanismes d'identification des utilisateurs et d'authentification de l'accès aux composants du système sont définis et compris. X X
8.1.1 Toutes les politiques de sécurité et les procédures opérationnelles identifiées dans l'exigence 8 sont : Documenté. Tenue à jour. En cours d'utilisation. Connu de toutes les parties concernées. X X
8.1.2 Les rôles et responsabilités pour la réalisation des activités de l'exigence 8 sont documentés, attribués et compris. X X  
8.2 L'identification de l'utilisateur et les comptes associés pour les utilisateurs et les administrateurs sont strictement gérés tout au long du cycle de vie d'un compte. X X
8.2.1 Tous les utilisateurs se voient attribuer un identifiant unique avant de pouvoir accéder aux composants du système ou aux données du titulaire de la carte. X X

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

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.

X X

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.
X X
8.2.5 L'accès des utilisateurs dont l'emploi a pris fin est immédiatement révoqué. X X
8.2.6 Les comptes d'utilisateurs inactifs sont supprimés ou désactivés dans les 90 jours d'inactivité. X X

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.
X   Les tiers n'ont pas accès au CDE.
8.2.8 Si une session utilisateur est restée inactive pendant plus de 15 minutes, l'utilisateur doit s'authentifier à nouveau pour réactiver le terminal ou la session. X  
8.3 L'authentification forte des utilisateurs et des administrateurs est établie et gérée. X

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.
X
8.3.2 Une cryptographie forte est utilisée pour rendre tous les facteurs d'authentification illisibles lors de la transmission et du stockage sur tous les composants du système. X
8.3.3 L'identité de l'utilisateur est vérifiée avant de modifier tout facteur d'authentification.  X

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

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

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.
X
8.3.7 Les personnes ne sont pas autorisées à soumettre un nouveau mot de passe/une nouvelle phrase de passe identique aux quatre derniers mots de passe/phrases de passe utilisés.  X

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

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.
X Les mots de passe ne sont pas utilisés comme seul facteur d'authentification. Pour accéder à l'environnement concerné, les utilisateurs sont tenus de toujours utiliser l'AMF.

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.
X Les mots de passe ne sont pas utilisés comme seul facteur d'authentification. Pour accéder à l'environnement concerné, les utilisateurs sont tenus de toujours utiliser l'AMF.

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. 
X Les mots de passe ne sont pas utilisés comme seul facteur d'authentification. Pour accéder à l'environnement concerné, les utilisateurs sont tenus de toujours utiliser l'AMF.

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.
X Genesys n'utilise pas de jetons de sécurité, de cartes à puce ou de certificats comme facteurs d'authentification.

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

X  

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.

X  

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

X  

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

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

X

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é.
X

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

X Aucun compte de système ou d'application n'est utilisé pour la connexion interactive à l'heure actuelle.

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.
X Aucun compte de système ou d'application n'est utilisé pour la connexion interactive à l'heure actuelle.

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.

X Aucun compte de système ou d'application n'est utilisé pour la connexion interactive à l'heure actuelle.

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.
X Aucun compte de système ou d'application n'est utilisé pour la connexion interactive à l'heure actuelle.

Exigence PCI DSS -- Genesys Cloud Client caractéristique Notes
9.1 Les processus et les mécanismes de restriction de l'accès physique aux données des titulaires de cartes sont définis et compris. X Les bureaux Genesys ne sont pas concernés.
9.1.1 Toutes les politiques de sécurité et les procédures opérationnelles identifiées dans l'exigence 9 sont : Documenté. Tenue à jour. En cours d'utilisation. Connu de toutes les parties concernées.
X X  
9.1.2 Les rôles et responsabilités pour la réalisation des activités de l'exigence 9 sont documentés, attribués et compris. X
9.2 Les contrôles d'accès physique permettent de gérer l'entrée dans les installations et les systèmes contenant des données relatives aux titulaires de cartes.
X  
9.2.1 Des contrôles d'entrée appropriés sont en place pour restreindre l'accès physique aux systèmes du CDE. X

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.
X
9.2.2 Des contrôles physiques et/ou logiques sont mis en œuvre pour restreindre l'utilisation des prises réseau accessibles au public dans l'établissement. X
9.2.3 L'accès physique aux points d'accès sans fil, aux passerelles, au matériel de réseau/communication et aux lignes de télécommunication à l'intérieur de l'établissement est limité. X
9.2.4 L'accès aux consoles dans les zones sensibles est limité par un verrouillage lorsqu'elles ne sont pas utilisées. X

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

X  

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é.
X

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

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.
X
9.3.3 Les badges ou pièces d'identité des visiteurs sont remis ou désactivés avant que les visiteurs ne quittent l'établissement ou à la date d'expiration. X

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.
X
9.4 Les supports contenant les données des titulaires de cartes sont stockés, consultés, distribués et détruits en toute sécurité. X
9.4.1 Tous les supports contenant des données relatives aux titulaires de cartes sont physiquement sécurisés. X
9.4.1.1 Les sauvegardes des supports hors ligne contenant les données des titulaires de cartes sont stockées dans un endroit sûr. X
9.4.1.2 La sécurité des supports de sauvegarde hors ligne contenant les données des titulaires de cartes est examinée au moins une fois tous les 12 mois. X
9.4.2 Tous les supports contenant des données relatives aux titulaires de cartes sont classés en fonction de la sensibilité des données. X

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

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

X

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

X

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.

X

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

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.
X
9.5 Les dispositifs de point d'interaction (POI) sont protégés contre la falsification et la substitution non autorisée. X

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

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.
X
9.5.1.2 Les surfaces des dispositifs de la POI sont périodiquement inspectées afin de détecter les altérations et les substitutions non autorisées. X
9.5.1.2.1 La fréquence des inspections périodiques des dispositifs d'IOP et le type d'inspections effectuées sont définis dans l'analyse de risque ciblée de l'entité, qui est réalisée conformément à tous les éléments spécifiés dans l'exigence 12.3.1. X

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

Exigence PCI DSS -- Genesys Cloud Client caractéristique Notes
10.1 Les processus et les mécanismes d'enregistrement et de contrôle de tous les accès aux composants du système et aux données des titulaires de cartes sont définis et documentés. X
10.1.1 Toutes les politiques de sécurité et les procédures opérationnelles identifiées dans l'exigence 10 sont : Documenté. Tenue à jour. En cours d'utilisation. Connu de toutes les parties concernées. X
10.1.2 Les rôles et responsabilités pour la réalisation des activités de l'exigence 10 sont documentés, attribués et compris. X
10.2 Les journaux d'audit sont mis en œuvre pour faciliter la détection des anomalies et des activités suspectes, ainsi que l'analyse médico-légale des événements. X
10.2.1 Les journaux d'audit sont activés et actifs pour tous les composants du système et les données des titulaires de cartes. X
10.2.1.1 Les journaux d'audit enregistrent tous les accès individuels des utilisateurs aux données des titulaires de cartes. X
10.2.1.2 Les journaux d'audit enregistrent toutes les actions entreprises par toute personne disposant d'un accès administratif, y compris toute utilisation interactive des comptes d'application ou de système. X
10.2.1.3 Les journaux d'audit capturent tous les accès aux journaux d'audit. X
10.2.1.4 Les journaux d'audit enregistrent toutes les tentatives d'accès logique non valides. X

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.
X
10.2.1.6 Les journaux d'audit enregistrent les éléments suivants : Toutes les initialisations de nouveaux journaux d'audit et tous les démarrages, arrêts ou mises en pause des journaux d'audit existants. X
10.2.1.7 Les journaux d'audit enregistrent toutes les créations et suppressions d'objets au niveau du système. X

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).
X
10.3 Les journaux d'audit sont protégés contre la destruction et les modifications non autorisées. X
10.3.1 L'accès en lecture aux fichiers d'audit est limité aux personnes qui en ont besoin dans le cadre de leur travail. X
10.3.2 Les fichiers d'audit sont protégés afin d'empêcher toute modification par des individus. X
10.3.3 Les fichiers journaux d'audit, y compris ceux des technologies externes, sont rapidement sauvegardés sur un ou plusieurs serveurs centraux internes sécurisés ou sur d'autres supports difficiles à modifier. X
10.3.4 Le contrôle de l'intégrité des fichiers ou les mécanismes de détection des modifications sont utilisés sur les journaux d'audit pour s'assurer que les données existantes ne peuvent pas être modifiées sans générer d'alertes. X
10.4 Les journaux d'audit sont examinés afin d'identifier les anomalies ou les activités suspectes. X

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).
X
10.4.1.1 Des mécanismes automatisés sont utilisés pour examiner les journaux d'audit.
X
10.4.2 Les journaux de tous les autres composants du système (ceux qui ne sont pas spécifiés dans l'exigence 10.4.1) sont examinés périodiquement. X
10.4.2.1 La fréquence des revues périodiques des journaux pour tous les autres composants du système (non définis dans l'exigence 10.4.1) est 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.
X
10.4.3 Les exceptions et les anomalies identifiées au cours du processus d'examen sont traitées. X
10.5 L'historique des journaux d'audit est conservé et disponible pour analyse. X
10.5.1 Conserver l'historique des journaux d'audit pendant au moins 12 mois, les trois derniers mois au moins étant immédiatement disponibles pour analyse. X
10.6 Les mécanismes de synchronisation temporelle permettent de régler l'heure de manière cohérente dans tous les systèmes. X

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.

X

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

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.
X
10.7 Les défaillances des systèmes de contrôle de sécurité critiques sont détectées, signalées et traitées rapidement. X

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).
X

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).
X

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é.
X

Exigence PCI DSS -- Genesys Cloud Client caractéristique Notes
11.1 Les processus et les mécanismes permettant de tester régulièrement la sécurité des systèmes et des réseaux sont définis et compris. X
11.1.1 Toutes les politiques de sécurité et les procédures opérationnelles identifiées dans l'exigence 11 sont : Documenté. Tenue à jour. En cours d'utilisation. Connu de toutes les parties concernées. X X
11.1.2 Les rôles et responsabilités pour la réalisation des activités de l'exigence 11 sont documentés, attribués et compris. X X  
11.2 Les points d'accès sans fil sont identifiés et surveillés, et les points d'accès sans fil non autorisés sont traités. X X

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.
X X L'AWS est responsable de ce contrôle car tous les sites physiques sont gérés par l'AWS.
AWS.
11.2.2 Un inventaire des points d'accès sans fil autorisés est tenu à jour, avec une justification commerciale documentée. X X Aucune technologie sans fil n'est autorisée dans l'environnement.
11.3 Les vulnérabilités externes et internes sont régulièrement identifiées, classées par ordre de priorité et traitées. X X

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

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

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

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).
X X

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

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).
X X

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.

X X

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

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

X

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

X X

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.

X X

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).
X X

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).
X X

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.

X N'est pas un fournisseur de services multi-locataires
11.5 Les intrusions dans le réseau et les modifications inattendues de fichiers sont détectées et font l'objet d'une réponse. X

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.
X
11.5.1.1 Exigence supplémentaire pour les fournisseurs de services uniquement : Les techniques de détection et/ou de prévention des intrusions détectent, alertent, préviennent et traitent les canaux de communication clandestins des logiciels malveillants.
X

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.
X
11.6 Les modifications non autorisées des pages de paiement sont détectées et font l'objet d'une réponse. X Genesys n'utilise pas/ne reçoit pas de pages de paiement du navigateur du consommateur.

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).
X

Exigence PCI DSS -- Genesys Cloud Client caractéristique Notes
12.1 Une politique globale de sécurité de l'information qui régit et oriente la protection des actifs informationnels de l'entité est connue et actualisée. 12.10 Les incidents de sécurité suspectés et confirmés qui pourraient avoir un impact sur le CDE font l'objet d'une réponse immédiate. X
12.1.1 Une politique globale de sécurité de l'information est : Établi. Publié. Maintenu. Diffusion à l'ensemble du personnel concerné, ainsi qu'aux fournisseurs et partenaires commerciaux concernés. X
12.1.2 La politique de sécurité de l'information est la suivante Révision au moins une fois tous les 12 mois. Mis à jour si nécessaire pour refléter les changements dans les objectifs de l'entreprise ou les risques pour l'environnement. X
12.1.3 La politique de sécurité définit clairement les rôles et les responsabilités de l'ensemble du personnel en matière de sécurité de l'information, et tous les membres du personnel sont conscients de leurs responsabilités en matière de sécurité de l'information et les reconnaissent. X
12.1.4 La responsabilité de la sécurité de l'information est officiellement confiée à un responsable de la sécurité de l'information ou à un autre membre de la direction générale compétent en matière de sécurité de l'information. X

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

X

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.
X
12.3 Les risques pour l'environnement des données des titulaires de cartes sont formellement identifiés, évalués et gérés. X

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

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

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

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".
X
12.4 La conformité à la norme PCI DSS est gérée. X

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

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

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.
X
12.5 Le champ d'application de la norme PCI DSS est documenté et validé. X
12.5.1 Un inventaire des composants du système qui entrent dans le champ d'application de la norme PCI DSS, y compris une description de la fonction/de l'utilisation, est tenu à jour. X

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

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.
X
12.5.3 Exigence supplémentaire pour les fournisseurs de services uniquement : Les changements importants apportés à la structure organisationnelle donnent lieu à un examen (interne) documenté de l'impact sur le champ d'application de la norme PCI DSS et sur l'applicabilité des contrôles, dont les résultats sont communiqués à la direction générale. X
12.6 La sensibilisation à la sécurité est une activité permanente. X
12.6.1 Un programme formel de sensibilisation à la sécurité est mis en œuvre pour faire connaître à l'ensemble du personnel la politique et les procédures de l'entité en matière de sécurité de l'information, ainsi que leur rôle dans la protection des données des titulaires de cartes. X
12.6.2 Le programme de sensibilisation à la sécurité est : Révisé au moins une fois tous les 12 mois, et mis à jour si nécessaire pour tenir compte des nouvelles menaces et vulnérabilités susceptibles d'avoir une incidence sur la sécurité du CDE de l'entité, ou sur les informations fournies au personnel concernant son rôle dans la protection des données des titulaires de cartes. X

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.
X
12.6.3.1 La formation de sensibilisation à la sécurité comprend la sensibilisation aux menaces et aux vulnérabilités qui pourraient avoir un impact sur la sécurité du CDE, y compris, mais sans s'y limiter : Phishing et attaques connexes. Ingénierie sociale. X
12.6.3.2 La formation de sensibilisation à la sécurité comprend une sensibilisation à l'utilisation acceptable des technologies de l'utilisateur final conformément à l'exigence 12.2.1. X
12.7 Le personnel est contrôlé afin de réduire les risques liés aux menaces internes.
X
12.7.1 Le personnel potentiel qui aura accès au CDE est contrôlé, dans les limites des lois locales, avant d'être embauché afin de minimiser le risque d'attaques provenant de sources internes.
X
12.8 Les risques liés aux actifs informationnels associés aux relations avec les fournisseurs de services tiers sont gérés. X
12.8.1 Une liste de tous les prestataires de services tiers (TPSP) avec lesquels les données de compte sont partagées ou qui pourraient affecter la sécurité des données de compte est maintenue, y compris une description de chacun des services fournis. X

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é.
X
12.8.3 Une procédure établie est mise en œuvre pour l'engagement de prestataires de services de transfert de technologie, y compris une diligence raisonnable avant l'engagement. X
12.8.4 Un programme est mis en œuvre pour contrôler la conformité des TPSP à la norme PCI DSS au moins une fois tous les 12 mois. X
12.8.5 Des informations sont conservées sur les exigences PCI DSS gérées par chaque TPSP, sur celles gérées par l'entité et sur celles qui sont partagées entre le TPSP et l'entité. X

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

X

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.

X

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).
X
12.10 Les incidents de sécurité suspectés ou confirmés qui pourraient avoir un impact sur le CDE font l'objet d'une réponse immédiate. X

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

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.
X
12.10.3 Du personnel spécifique est désigné pour être disponible 24 heures sur 24 et 7 jours sur 7 afin de répondre aux incidents de sécurité suspectés ou confirmés. X
12.10.4 Le personnel chargé de réagir aux incidents de sécurité suspectés ou confirmés reçoit une formation appropriée et périodique sur ses responsabilités en matière de réaction aux incidents. X
12.10.4.1 La fréquence de la formation périodique du personnel de réponse aux incidents est définie dans l'analyse de risque ciblée de l'entité, qui est réalisée conformément à tous les éléments spécifiés dans l'exigence 12.3.1.
X

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.
X
12.10.6 Le plan d'intervention en cas d'incident de sécurité est modifié et évolué en fonction des enseignements tirés et de l'évolution du secteur. X

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

Exigence PCI DSS -- Genesys Cloud Client caractéristique Notes
A1.1 Les fournisseurs de services multi-locataires protègent et séparent tous les environnements et données des clients. X
A1.1.1 La séparation logique est mise en œuvre comme suit : Le fournisseur ne peut pas accéder aux environnements de ses clients sans autorisation. Les clients ne peuvent pas accéder à l'environnement du fournisseur sans autorisation.
X
A1.1.2 Les contrôles sont mis en œuvre de façon à ce que chaque client n'ait accès qu'à ses propres données de titulaire de carte et CDE.
X
A1.1.3 Les contrôles sont mis en œuvre de manière à ce que chaque client ne puisse accéder qu'aux ressources qui lui sont allouées.
X
A1.1.4 L'efficacité des contrôles de séparation logique utilisés pour séparer les environnements des clients est confirmée au moins une fois tous les six mois par des tests de pénétration.
X
A1.2 Les fournisseurs de services multi-locataires facilitent la journalisation et la réponse aux incidents pour tous les clients. X
A1.2.1 La fonction de journal d'audit est activée pour l'environnement de chaque client, conformément à l'exigence 10 de la norme PCI DSS, y compris Les journaux sont activés pour les applications tierces courantes. Les journaux sont actifs par défaut. Les journaux ne peuvent être consultés que par le client propriétaire. L'emplacement des grumes est clairement communiqué au client propriétaire. Les données et la disponibilité des journaux sont conformes à l'exigence 10 de la norme PCI DSS.
X
A1.2.2 Des processus ou des mécanismes sont mis en œuvre pour soutenir et/ou faciliter des enquêtes judiciaires rapides en cas d'incident de sécurité suspecté ou confirmé pour tout client.
X
A1.2.3 Des processus ou des mécanismes sont mis en œuvre pour signaler et traiter les incidents de sécurité et les vulnérabilités suspectés ou confirmés, y compris Les clients peuvent signaler en toute sécurité les incidents de sécurité et les vulnérabilités au fournisseur. Le fournisseur traite les incidents de sécurité et les vulnérabilités suspectés ou confirmés et y remédie conformément à l'exigence 6.3.1. X

Date Révision
Novembre 15, 2023 Suppression des responsabilités non pertinentes pour les normes PCI DSS 4.0. Remise à niveau des responsabilités pour plus de précision.
Octobre 18, 2023 Mise à jour des responsabilités et ajout de nouvelles responsabilités conformément aux normes PCI DSS 4.0.
22 mars 2023 Ajout de nouvelles responsabilités conformément aux normes PCI DSS 4.0.