Analyse approfondie de la conformité PCI DSS

1. Aperçu

Qu'est-ce que la norme PCI DSS

La norme de sécurité des données de l'industrie des cartes de paiement (PCI DSS) est une norme mondiale de sécurité des informations maintenue par le Conseil des normes de sécurité PCI (PCI SSC). Elle s'applique à toute organisation qui stocke, traite ou transmet des données de titulaire de carte (CHD) ou des données d'authentification sensibles (SAD), ou qui peut avoir un impact sur la sécurité de l'environnement des données de titulaire de carte (CDE). La version actuelle est PCI DSS v4.0.1, publié en juin 2024 en tant que révision clarificatrice de la v4.0. La conformité avec la version 3.2.1 a pris fin le 31 mars 2024 ; les exigences futures de la v4.0 sont devenues obligatoires le 31 mars 2025.

À qui s’applique-t-il

Commerçants, prestataires de services, processeurs de paiement, acquéreurs, émetteurs, passerelles et tout fournisseur qui touche aux données des titulaires de carte au nom d'un commerçant. L’applicabilité est indépendante de la taille de l’entreprise : un petit site de commerce électronique acceptant les cartes est concerné, tout comme un processeur mondial gérant des milliards de transactions.

Résultat

• Questionnaire d'auto-évaluation (SAQ) — pour les commerçants et prestataires de services en dessous des seuils de volume. Neuf types de SAQ (A, A-EP, B, B-IP, C, C-VT, D-Merchant, D-Service Provider, P2PE) correspondent aux canaux courants d'acceptation de cartes.
• Rapport de conformité (ROC) — produit par un Évaluateur de sécurité qualifié (QSA) ou un évaluateur de sécurité interne (ISA) pour les commerçants de niveau 1 et les prestataires de services de niveau 1/niveau 2. Le ROC est le document d’évaluation complet ; une attestation de conformité (AOC) résume le résultat pour les parties utilisatrices.

PCI DSS n'est pas une réglementation gouvernementale : il s'agit d'une obligation contractuelle imposée par les marques de cartes (Visa, Mastercard, American Express, Discover, JCB) via les banques acquéreuses. Le non-respect est sanctionné par des amendes, des frais de transaction accrus et, finalement, la suspension des privilèges d'acceptation de carte.

Objectifs de haut niveau

• Protégez les données des titulaires de carte partout où elles sont stockées, traitées ou transmises
• Réduisez la portée de l’environnement des données des titulaires de cartes grâce à la segmentation et à la tokenisation
• Maintenir un programme de gestion des vulnérabilités et une surveillance continue
• Démontrer l’efficacité opérationnelle des contrôles à une cadence annuelle

Clarify Consult Partner assure la préparation à la norme PCI DSS, une stratégie de réduction de la portée et une gestion continue du programme grâce au Service de conformité PCI DSS. Les analyses externes ROC émises par QSA et par le fournisseur d'analyse agréé (ASV) sont effectuées par des tiers — nous coordonnons et préparons les clients pour les deux.

2. Portée et applicabilité

Ce qui est couvert

• Tout composant du système qui stocke, traite ou transmet CHD ou SAD
• Tout composant du système qui est connecté ou peut avoir un impact sur la sécurité du CDE (systèmes dits « connectés » ou « ayant un impact sur la sécurité »).
• Périphériques réseau, serveurs, applications, plates-formes de virtualisation et charges de travail cloud au sein du CDE
• Personnes ayant un accès logique ou physique au CDE
• Fournisseurs de services qui traitent, stockent ou transmettent des CHD pour le compte de l'entité (la gestion des risques liés aux tiers est un domaine d'intervention de la version 4.0)

Ce qui peut être hors de portée

• Les systèmes qui ont pas de connectivité au CDE et ne peut pas impacter sa sécurité
• Zones de réseau correctement segmentées (validées par des tests d'intrusion selon l'exigence 11.4.5 pour les fournisseurs de services, 11.4.6 pour les commerçants)
• Fonctions externalisées pour lesquelles un prestataire de services a fourni son propre AOC couvrant les exigences pertinentes

Segmentation

La segmentation est le principal outil de réduction de la portée. La norme PCI DSS ne nécessite pas de segmentation, mais les réseaux non segmentés incluent chaque système connecté dans son champ d'application. La segmentation doit être vérifiée par des tests d'intrusion au moins tous les 12 mois pour les prestataires de services et au moins tous les 24 mois pour les commerçants, ainsi qu'après tout changement significatif.

Données du titulaire de carte et données d'authentification sensibles

• CHD: Numéro de compte principal (PAN), nom du titulaire de la carte, date d'expiration, code de service. Peut être stocké s’il est correctement protégé.
• TRISTE: données de piste complètes, CAV2/CVC2/CVV2/CID, bloc PIN/PIN. Ne doit pas être stocké après autorisation, même crypté.

Niveaux de rapport

• Marchand Niveau 1: plus de 6 millions de transactions par marque et par an — ROC annuel par QSA, scans ASV trimestriels.
• Niveaux marchands 2/3/4 : SAQ adapté au canal d'acceptation, analyses ASV trimestrielles le cas échéant.
• Fournisseur de services niveau 1: plus de 300 000 transactions par marque et par an — ROC annuel par QSA.
• Fournisseur de services niveau 2: moins de 300 000 — SAQ D pour les prestataires de services.

Approche personnalisée

PCI DSS v4.0 a introduit le approche personnalisée aux côtés du traditionnel approche définie. L’approche définie utilise textuellement les procédures de test spécifiées. Une approche personnalisée permet à une entité de concevoir des contrôles alternatifs pour répondre à un objectif déclaré. Objectif de l'approche personnalisée, validé par une QSA utilisant une Matrice de Contrôles et une Analyse de Risque Ciblée. L'approche personnalisée n'est pas disponible pour les déclarants SAQ et ajoute des efforts d'évaluation, mais elle donne aux entités matures la flexibilité d'utiliser des architectures modernes (par exemple, le calcul éphémère ou la télémétrie de maillage de services) qui peuvent ne pas s'aligner clairement sur la formulation des exigences d'origine.

3. Principes fondamentaux

La norme PCI DSS organise 12 exigences de haut niveau en six objectifs de contrôle. La version 4.0.1 contient environ 300 exigences de base, s'étendant à plus de 500 sous-exigences lorsque les notes d'applicabilité et les procédures de test sont prises en compte.

Construire et maintenir un réseau et des systèmes sécurisés — Les exigences 1 et 2 couvrent les contrôles de sécurité du réseau (pare-feu, NSC) et la configuration sécurisée des composants du système.

Protéger les données du compte — Les exigences 3 et 4 couvrent la protection des données des comptes stockés (cryptographie forte, gestion des clés, limites de conservation) et la sécurité de la transmission (TLS, cryptage de bout en bout).

Maintenir un programme de gestion des vulnérabilités — Les exigences 5 et 6 couvrent le développement de logiciels anti-malware et sécurisés, y compris la nouvelle version 4.0 qui met l'accent sur la modélisation des menaces et l'analyse authentifiée des vulnérabilités.

Mettre en œuvre des mesures strictes de contrôle d’accès — Les exigences 7, 8 et 9 couvrent l'accès basé sur les rôles, l'identité et l'authentification (MFA sur tous les accès au CDE sous v4.0) et l'accès physique.

Surveiller et tester régulièrement les réseaux — Les exigences 10 et 11 couvrent la journalisation, la surveillance, les analyses de vulnérabilité, les tests de segmentation et les tests d'intrusion.

Maintenir une politique de sécurité des informations — L'exigence 12 couvre la gouvernance, l'évaluation des risques, le risque lié aux tiers, la réponse aux incidents et le programme d'analyse ciblée des risques, nouveau dans la version 4.0.

4. Panne du contrôle

Exigence 1 — Contrôles de sécurité du réseau

But: Limitez le trafic entrant et sortant à ce qui est nécessaire pour le CDE.
Attentes minimales : Ensembles de règles documentées de contrôle de sécurité du réseau, examinées au moins tous les six mois ; posture de refus par défaut ; diagrammes de flux de données documentés couvrant tous les flux CHD.
Preuve: Configurations de pare-feu et de groupes de sécurité, enregistrements d'examen des ensembles de règles, diagrammes de réseau, diagrammes de flux de données.
Lacunes courantes : Règles de pare-feu obsolètes, diagrammes de flux de données manquants, accès CDE latéral depuis les réseaux d'entreprise.

Exigence 2 — Configurations sécurisées

But: Éliminez les défauts des fournisseurs et renforcez les composants du système.
Attentes minimales : Normes de configuration alignées sur une source industrielle (CIS, benchmarks des fournisseurs) ; inventaire des composants du système ; exceptions documentées.
Preuve: Listes de contrôle de renforcement, exportations d'outils de gestion de configuration, inventaire des actifs.

Exigence 3 – Protéger les données de compte stockées

But: Minimisez le PAN stocké et protégez ce qui doit être stocké.
Attentes minimales : Politique documentée de conservation et d’élimination des données ; PAN rendu illisible (troncation, tokenisation, cryptographie forte) ; SAD n'a jamais stocké la post-autorisation ; cycle de vie documenté de la gestion des clés (3.6, 3.7).
Preuve: Analyses de découverte de données, inventaire des clés, configurations KMS, attestations de calendrier de conservation.
Lacunes courantes : PAN détecté dans les tickets d'assistance, les journaux d'applications ou les sauvegardes en dehors du CDE : une découverte fréquente qui étend la portée de manière inattendue.

Exigence 4 — Protéger les données des titulaires de carte en transit

But: Empêchez l’interception sur les réseaux publics ouverts.
Attentes minimales : TLS 1.2 ou supérieur avec des suites de chiffrement puissantes ; inventaire documenté des certificats ; protection des PAN envoyés via les technologies de messagerie de l'utilisateur final.
Preuve: Analyses de configuration TLS, inventaires de certificats, politique de messagerie.

Exigence 5 — Défenses contre les logiciels malveillants et le phishing

But: Détectez et prévenez les logiciels malveillants.
Attentes minimales : Solution anti-malware sur les systèmes « couramment affectés par des logiciels malveillants » (la formulation de la version 4.0 est basée sur les risques et non sur une couverture globale) ; évaluation périodique; La version 4.0 ajoute des contrôles anti-phishing explicites (5.4.1).
Preuve: Rapports de couverture, tickets de gestion des alertes, configurations de passerelle de messagerie.

Exigence 6 — Développer et maintenir des systèmes et des logiciels sécurisés

But: Protégez-vous contre les vulnérabilités logicielles tout au long du SDLC.
Attentes minimales : SDLC sécurisé documenté ; La version 4.0 ajoute des contrôles d'intégrité des pages de paiement (6.4.3) et un inventaire documenté de logiciels sur mesure et personnalisés avec un processus d'identification des vulnérabilités (6.3.2) ; gérer les vulnérabilités des applications Web destinées au public (6.4.1, 6.4.2).
Preuve: Procédures SDLC, enregistrements de révision de code, sorties SAST/DAST, politique de sécurité du contenu de la page de paiement.
Lacunes courantes : Contrôles d'écrémage des pages de paiement (classe Magecart) sous-développés – accent mis sur la version 4.0. Voir notre service de tests d'intrusion pour les tests d'applications Web authentifiées.

Exigence 7 – Restreindre l’accès selon le besoin de savoir de l’entreprise

But: Appliquer le moindre privilège.
Attentes minimales : Contrôle d'accès basé sur les rôles ; matrice d'accès documentée ; révisé au moins tous les six mois (exigence 7.2.4 de la version 4.0).
Preuve: Attestations d'examen d'accès, définitions de rôles, provisionnement basé sur des tickets.

Exigence 8 — Identifier les utilisateurs et authentifier l'accès

But: Identification unique et authentification forte.
Attentes minimales : identifiants uniques ; MFA pour tous les accès au CDE (8.4.2, postdaté au 31 mars 2025) ; Mot de passe de 12 caractères minimum si les mots de passe sont utilisés comme seul facteur (8.3.6) ; réauthentification périodique des comptes système ou application (8.6).
Preuve: Configuration IdP, rapports d'inscription MFA, politique de mot de passe.

Exigence 9 — Restreindre l'accès physique

But: Limitez l’accès physique au CDE et aux médias.
Attentes minimales : Journaux des visiteurs, contrôles des badges, gestion et destruction des supports, inventaire des appareils POI et inspections de falsification (9.5).
Preuve: Journaux des installations, enregistrements d'élimination des supports, journaux d'inspection des POI.

Exigence 10 – Enregistrer et surveiller tous les accès

But: Contrôle de détective grâce à une journalisation d’audit complète.
Attentes minimales : Contenu du journal selon 10.2 ; conservation des journaux pendant au moins 12 mois, dont trois mois immédiatement disponibles ; examen quotidien automatisé lorsque cela est possible (10.4.1.1, v4.0) ; synchronisation de l'heure entre les composants.
Preuve: Inventaire des règles SIEM, configurations de conservation des journaux, tickets de révision quotidiens.

Exigence 11 – Tester régulièrement la sécurité

But: Validez que les contrôles fonctionnent.
Attentes minimales : Analyses trimestrielles des vulnérabilités internes et externes ; analyses externes par un ASV; test d'intrusion annuel (interne et externe) avec tests de segmentation par périmètre ; La v4.0 ajoute des analyses internes authentifiées (11.3.1.2) et une détection des modifications de page de paiement (11.6.1).
Preuve: Rapports d'analyse ASV, rapports pentest, résultats des tests de segmentation, journaux d'intégrité des pages de paiement.

Exigence 12 — Maintenir une politique de sécurité de l'information

But: Gouvernance, risques et gestion des tiers.
Attentes minimales : Politique de sécurité de l'information révisée annuellement ; rôles et responsabilités documentés ; évaluation annuelle des risques ; Analyses de risques ciblées pour toute flexibilité utilisée sous la v4.0 (12.3.1, 12.3.2) ; surveillance des fournisseurs de services tiers (12.8, 12.9) ; plan de réponse aux incidents testé annuellement.
Preuve: Politiques, évaluations des risques, inventaire des fournisseurs et AOC, plan IR et enregistrements sur table.
Cartographie : Chevauchement important avec ISO 27001 SMSI, en particulier les clauses 6.1, 7.5 et 8.1. Voir notre service d'évaluation des risques pour les analyses de risques ciblées requises par la v4.0.

5. Exigences minimales (non négociables)

Documents obligatoires

• Définition du périmètre et diagramme CDE
• Diagramme de réseau montrant tous les composants concernés
• Diagrammes de flux de données couvrant chaque flux CHD
• Politique de sécurité de l’information et politiques connexes
• Normes de configuration et de renforcement par type de système
• Évaluation des risques et analyses de risques ciblées (v4.0)
• Plan de réponse aux incidents
• Inventaire des fournisseurs avec AOC et matrice de responsabilité
• Inventaire des logiciels sur mesure et personnalisés (6.3.2)
• Inventaire des clés cryptographiques et procédures de gestion des clés

Processus obligatoires

• Analyses ASV externes trimestrielles (réussite)
• Scans de vulnérabilités internes trimestriels (authentifiés sous v4.0)
• Tests d'intrusion internes et externes annuels avec validation de segmentation
• Examen semestriel des règles de pare-feu et examen des accès des utilisateurs
• Évaluation annuelle des risques et table RI
• Surveillance continue et examen quotidien des journaux
• Formation annuelle de sensibilisation à la sécurité et formation ciblée pour les développeurs et les intervenants en cas d'incident

Contrôles techniques (référence)

• MFA sur tous les accès au CDE
• Cryptographie forte pour PAN au repos et en transit
• Limites de réseau renforcées et surveillées
• Journalisation complète et corrélation SIEM
• Protection des points finaux sur les composants système pertinents
• Protections des applications Web, y compris la surveillance de l'intégrité des pages de paiement

Récurrence

• Trimestriel : analyses ASV, analyses internes
• Semestriel : révisions des règles de pare-feu, révisions des accès
• Annuel : test d'intrusion, ROC ou SAQ, évaluation des risques, étude de table IR, examen des politiques
• Continu : surveillance, remédiation des vulnérabilités

6. Conseils de mise en œuvre technique

Réduction de la portée

• Tokenisez le PAN dès le premier point de capture et supprimez le PAN en texte clair des systèmes en aval.
• Utilisez une iframe de passerelle de paiement ou une page de paiement hébergée pour conserver votre application en dehors du CDE lorsque cela est possible (modèle SAQ A)
• Segmentez le CDE avec des contrôles matériels ou réseau cloud validés par des tests d'intrusion indépendants

Découverte des données des titulaires de carte

• Exécutez des analyses de découverte de données authentifiées sur les partages de fichiers, les bases de données, les boîtes aux lettres, les systèmes de billetterie et les environnements de développement
• Documenter la correction pour tout PAN trouvé en dehors du CDE et réanalyser après la correction
• Répéter au moins une fois par an

Cryptographie

• Utiliser des algorithmes approuvés par le NIST (AES-256, RSA-3072, ECDSA P-256)
• Gérer les clés avec un cycle de vie documenté : génération, distribution, stockage, rotation, retrait, destruction
• Utilisez un KMS géré (AWS KMS, Azure Key Vault, GCP KMS) ou un HSM lorsque cela est possible
• Mettre en œuvre la reconnaissance du dépositaire clé (3.7.3)

Contrôle d'accès

• Appliquer MFA au niveau du fournisseur d'identité pour tous les accès CDE, y compris les administrateurs
• Évitez les comptes partagés ; lorsque cela est inévitable, documenter la justification et surveiller
• Désactivez les comptes de service qui ne nécessitent pas de connexion interactive et alternez les informations d'identification selon un calendrier documenté.

Surveillance

• Centralisez les journaux des appareils réseau, des serveurs, des applications, des IDPS et des fournisseurs d'identité CDE
• Configurez des alertes sur les événements critiques : élévation de privilèges, falsification de journaux, désactivation de l'anti-malware, modification de la page de paiement
• Synchronisez temporellement tous les composants avec une source NTP validée

Gestion des vulnérabilités et des correctifs

• Classer les vulnérabilités par gravité et y remédier de manière critique et élevée dans les 30 jours (6.3.3 basé sur le risque)
• Suivez les correctifs des fournisseurs de services et les mesures correctives prédéfinies pour les composants non pris en charge
• Utiliser l'analyse authentifiée pour les cibles internes

7. Exigences en matière de politiques et de procédures

Ensemble de documents PCI DSS typique :

• Politique de sécurité des informations
• Politique d'utilisation acceptable
• Politique de contrôle d'accès
• Politique de cryptographie et de gestion des clés
• Normes de configuration et de durcissement
• Norme de sécurité réseau
• Norme de journalisation, de surveillance et d'alerte
• Procédure de gestion des vulnérabilités et des correctifs
• Norme de développement de logiciels sécurisés
• Politique de conservation et de suppression des données
• Politique de gestion des risques liés aux tiers
• Plan de réponse aux incidents
• Registre d'analyse des risques ciblés (v4.0)
• Plan de continuité des activités et de reprise après sinistre
• Procédure annuelle d’évaluation des risques

Chacun doit définir la portée, la propriété, la fréquence d'examen et le lien avec le contrôle technique sous-jacent. Pour les programmes double standard combinant PCI DSS avec ISO 27001 ou SOC 2, la plupart des politiques répondent aux deux normes avec des ajouts mineurs de portée.

8. Éléments probants et vérification

Les QSA évaluent chaque exigence en utilisant les procédures de test de la norme. Pour chaque contrôle, ils s'attendent à voir la politique, la procédure de support, les preuves de configuration et les preuves de l'efficacité opérationnelle au cours de la période d'évaluation.

Catégories de preuves typiques

• Documentation : politiques, procédures, diagrammes de réseau et de flux de données, énoncé du périmètre, évaluation des risques, analyses de risques ciblées
• Configuration : règles de pare-feu, exportations de renforcement, exportations IAM, configurations KMS, jeux de règles SIEM
• Observations : parcours d'actions administratives, démonstrations de pages de paiement, tests de segmentation
• Enregistrements : rapports d'analyse ASV, rapports de tests d'intrusion, tickets de modification, enregistrements d'incidents, tickets d'examen des journaux quotidiens, achèvement de la formation
• Entretiens : avec des administrateurs, des développeurs, des intervenants en cas d'incident, des responsables de fournisseurs

Échantillonnage

Les QSA échantillonnent les composants du système, les utilisateurs et les périodes. La taille des échantillons évolue en fonction de la population ; pour les grandes populations, un échantillon typique est de 25 personnes plus une justification de couverture pour tous les types de systèmes et zones géographiques.

Éléments de correction courants

• Résultats de la découverte de PAN en dehors du CDE
• Diagrammes de flux de données incomplets
• Règles de pare-feu obsolètes sans justification commerciale
• Analyses de risques ciblées manquantes pour toute flexibilité utilisée
• Contrôles d'intégrité des pages de paiement pas encore mis en œuvre
• Preuve insuffisante de l'examen quotidien du journal
• AOC du fournisseur de services manquants ou obsolètes

Examen indépendant de pré-évaluation par le biais de notre service d'audit interne ou l'examen de l'état de préparation les détecte avant l'arrivée du QSA.

9. Considérations sur le calendrier de mise en œuvre

Durée typique

• ROC pour la première fois (contrôles matures) : 4 à 6 mois entre le lancement et l'émission du ROC
• ROC pour la première fois (réhabilitation substantielle): 9 à 18 mois, y compris la réduction de la portée, le déploiement de la tokenisation et la mise en œuvre du contrôle v4.0 à date ultérieure
• SAQ A ou A-EP: 4 à 8 semaines si l'architecture s'aligne sur une page de paiement hébergée
• Recertification annuelle : 6 à 10 semaines de travail sur le terrain QSA et collecte continue de preuves

Jalons

• Portée et découverte PAN
• Évaluation des écarts par rapport à la version 4.0.1
• Conception de réduction de portée (tokénisation, segmentation)
• Contrôler la remédiation
• Collecte de preuves et finalisation de la politique
• Préparation à l'analyse ASV
• Test d'intrusion et test de segmentation
• Travail de terrain QSA et rédaction du ROC
• Émission d’AOC et soumission à la banque acquéreuse

Dépendances

• Coopération de la passerelle de paiement et du fournisseur de tokenisation
• Capacité de l’équipe réseau et plateforme cloud pour le travail de segmentation
• Capacité de l’équipe de développement en matière d’intégrité des pages de paiement et d’inventaire de logiciels sur mesure
• vCISO ou responsable du programme pour coordonner la collecte de preuves (voir Service vCISO)

10. Exigences continues du BAU en matière de sécurité

• Analyses ASV trimestrielles soumises via le portail des acquéreurs
• Analyses internes authentifiées trimestrielles avec suivi des mesures correctives
• Examen quotidien des journaux et gestion des alertes SIEM
• Ensemble de règles de pare-feu et examens d'accès semestriels
• Surveillance continue de l'intégrité des pages de paiement
• Test d'intrusion annuel et validation de la segmentation
• Évaluation annuelle des risques, actualisation de l'analyse des risques ciblée et examen des politiques
• Test annuel IR sur table et BCP
• Suivi des AOC des fournisseurs et suivi du renouvellement
• Découverte des données du titulaire de carte au moins une fois par an et après un changement important

11. Niveaux de maturité

Conformité minimale

• Approche définie utilisée tout au long
• Dépôt SAQ là où admissible ; ROC si nécessaire
• Collecte manuelle de preuves et cycles de remédiation trimestriels
• Outils de base pour les analyses, la journalisation et l'AMF

Intermédiaire

• La tokenisation a été déployée ; PAN largement retiré des systèmes internes
• SIEM centralisé avec des règles de corrélation adaptées aux événements CDE
• Validation continue de la configuration (Terraform + politique en tant que code)
• Analyses de risques ciblées et documentées favorisant la flexibilité

Avancé

• Approche personnalisée utilisée pour des exigences sélectionnées avec des matrices de contrôle validées QSA
• Posture de conformité continue, preuves collectées automatiquement
• Chiffrement de bout en bout (P2PE) le cas échéant
• Collecte de preuves PCI DSS, SOC 2 et ISO 27001 intégrée avec bibliothèque de contrôle partagée

12. FAQ

La norme PCI DSS est-elle obligatoire ?

La norme PCI DSS n'est pas une réglementation gouvernementale, mais sa conformité est exigée par les marques de cartes via la banque acquéreuse. Le non-respect entraîne des amendes, une augmentation des frais de transaction et, finalement, la suspension de l'acceptation de la carte. Plusieurs États américains ont également incorporé la norme PCI DSS par référence dans leurs lois sur la protection des données.

Quelle version s'applique actuellement ?

PCI DSS v4.0.1, publié en juin 2024 en tant que révision clarifiante de la v4.0. La version 3.2.1 a été retirée le 31 mars 2024 et les exigences futures de la version 4.0 sont devenues obligatoires le 31 mars 2025. Toute évaluation effectuée aujourd'hui doit être par rapport à la version 4.0.1.

Qui délivre mon rapport de conformité ?

Une société QSA (Qualified Security Assessor) répertoriée sur le site Web PCI SSC, ou un évaluateur de sécurité interne (ISA) pour les entités disposant d'un programme ISA interne. Clarify Consult Partner n'est pas une société QSA : nous préparons les clients à l'évaluation QSA, gérons la portée et les mesures correctives, et représentons le programme par le biais de travaux sur le terrain.

Avons-nous besoin d’analyses ASV trimestrielles ?

Si vous disposez d’un composant système orienté vers l’extérieur dans le CDE, oui. Les analyses ASV sont effectuées par un fournisseur d'analyse agréé répertorié sur le site Web PCI SSC. Les analyses internes doivent également être trimestrielles et, sous la version 4.0, authentifiées lorsque cela est possible.

Quelle est la différence entre la SAQ et le ROC ?

SAQ est un questionnaire d'auto-évaluation éligible aux volumes de transactions inférieurs et à des canaux d'acceptation spécifiques (neuf types de SAQ). ROC est un rapport formel produit par un QSA ou un ISA par rapport à l'ensemble des exigences, requis pour les commerçants de niveau 1 et les prestataires de services de niveau 1/niveau 2.

Quelle est l’approche personnalisée dans la v4.0 ?

Une alternative à l’approche définie. Pour les exigences applicables, l'entité conçoit ses propres contrôles pour répondre à un objectif d'approche personnalisée déclaré, documente une analyse de risque ciblée et produit une matrice de contrôles que le QSA valide. L’approche personnalisée n’est pas disponible pour les déclarants SAQ et augmente les efforts QSA.

Comment réduire la portée ?

Les deux leviers les plus efficaces sont la tokenisation (remplacer PAN par un token non sensible en dehors du CDE) et la segmentation (isoler le CDE afin que les systèmes non liés ne puissent pas l'atteindre). Une page de paiement hébergée ou une capture basée sur une iframe peut exclure un site marchand de la plupart des exigences en matière de données de titulaire de carte (modèle SAQ A).

Que coûte la norme PCI DSS ?

Coûts répartis en frais QSA, frais ASV, tests d'intrusion et conseil. Pour un premier ROC de taille moyenne, attendez-vous à des coûts totaux du programme compris entre 80 000 $ et 250 000 $ au cours de la première année, en fonction de l'étendue des mesures correctives. La recertification annuelle dure généralement 50 à 70 % de la première année, une fois les contrôles opérationnels.

Pouvons-nous utiliser les mêmes contrôles pour ISO 27001 et PCI DSS ?

Oui – un chevauchement important existe, en particulier entre les exigences 1, 2, 6, 7, 8, 10, 11 et 12. Un ISMS partagé prend en charge les deux normes avec des extensions spécifiques à PCI pour la tokenisation, l'intégrité des pages de paiement, les analyses ASV et la documentation de l'approche personnalisée.

Que se passe-t-il en cas de violation des données des titulaires de carte ?

Informez immédiatement votre acquéreur, engagez un enquêteur judiciaire PCI (PFI) de la liste PCI SSC, conservez les preuves et suivez votre plan de réponse aux incidents. Les marques de cartes peuvent imposer des amendes et exiger un ROC amélioré pendant plusieurs années après l'incident.

Quel est le lien entre PCI DSS et PCI PIN, P2PE et 3DS ?

Il s'agit de normes PCI SSC distinctes pour des scénarios spécifiques : dispositifs de saisie de code PIN, solutions de chiffrement point à point et serveurs de contrôle d'accès 3-D Secure. Ils partagent l'infrastructure et les principes avec PCI DSS mais sont évalués séparément. La réalisation du P2PE réduit souvent considérablement la portée de la norme PCI DSS du commerçant.

13. Résumé

PCI DSS v4.0.1 est la norme régissant toute organisation qui touche aux données des titulaires de cartes. La conformité est un programme pluriannuel fondé sur une gestion disciplinée du périmètre, une cryptographie solide, une surveillance continue et une validation indépendante annuelle par un QSA ou via un dépôt SAQ. Les modifications de la version 4.0 – MFA dans le CDE, intégrité des pages de paiement, analyse interne authentifiée, analyses de risques ciblées et approche personnalisée – placent la barre plus haut en matière de sophistication des contrôles tout en ouvrant plus de flexibilité aux programmes matures.

Pour définir un engagement, réservez un appel depuis le Page du service de conformité PCI DSS, ou parlez-nous de la combinaison de PCI DSS avec ISO 27001, SOC 2 ou un complet Programme vCISO pour la gestion continue du programme. Pour les tests d'intrusion conformes aux exigences PCI DSS 11.4.x, consultez notre service de tests d'intrusion.