TL;DR

Si vous traitez des données de cartes de crédit, la norme PCI DSS est obligatoire. C'est un point important. Elle couvre la manière de sécuriser les données des titulaires de cartes (CHD) et les données d'authentification sensibles (SAD) - cryptage, pare-feu, contrôle d'accès, journalisation, analyse, tout ce qu'il faut.

Si vous n'en tenez pas compte, vous risquez des amendes, des violations, des poursuites judiciaires et de vous faire couper l'herbe sous le pied par les organismes de paiement. La conformité n'est pas facultative, c'est une question de survie.

Résumé de la fiche d'évaluation PCI DSS :

• Effort du développeur : Modéré à élevé (nécessite un codage et une configuration sécurisés, une manipulation prudente des données des titulaires de cartes, le respect des contrôles d'accès, la prise en charge de l'analyse et de l'enregistrement des vulnérabilités).
• Coût de l'outillage : Modéré à élevé (pare-feu, scanners de vulnérabilité (scans ASV), contrôle de l'intégrité des fichiers, journalisation/SIEM, outils de cryptage, éventuellement solutions de tokenisation/P2PE).
• Impact sur le marché : Critique (obligatoire pour toute entité traitant des données de cartes de paiement ; la non-conformité peut entraîner l'impossibilité de traiter les paiements par carte).
• Flexibilité : Faible à modérée (les exigences de base sont normatives, mais les méthodes de mise en œuvre spécifiques peuvent varier ; la version 4.0 introduit plus de flexibilité avec l'"approche personnalisée").
• Intensité de l'audit : Élevée (nécessite une validation annuelle par le biais d'un questionnaire d'auto-évaluation (SAQ) ou d'un rapport officiel de conformité (ROC) par un évaluateur de sécurité qualifié (QSA), ainsi que des analyses de vulnérabilité trimestrielles).

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é de l'information conçue pour prévenir la fraude à la carte de crédit grâce à des contrôles accrus de la manipulation et du stockage des données. Elle s'applique à toute organisation, quelle que soit sa taille ou sa localisation, qui accepte, traite, stocke ou transmet des données relatives aux titulaires de cartes (CHD) ou des données d'authentification sensibles (SAD).

Le CHD comprend le numéro de compte principal (PAN), le nom du titulaire de la carte, la date d'expiration et le code de service. Le DAU comprend les données de suivi complètes, les codes de vérification de la carte (CVV2, CVC2, etc.) et les codes PIN - le DAU ne doit jamais être stocké après autorisation.

La norme PCI DSS a été créée par les principales marques de cartes de paiement (Visa, Mastercard, American Express, Discover, JCB) qui ont formé le PCI Security Standards Council (PCI SSC) pour gérer la norme. La conformité est assurée par les différentes marques de cartes et les banques acquéreuses, et non directement par le PCI SSC.

La norme s'articule autour de 6 objectifs qui se traduisent par 12 exigences fondamentales (celles-ci restent cohérentes dans le concept de la nouvelle version PCI DSS v4.0) :

1. Construire et maintenir un réseau et des systèmes sécurisés :
   
   • Exigence 1 : Installer et maintenir les contrôles de sécurité du réseau (pare-feu).
   • Exigence 2 : appliquer des configurations sécurisées à tous les composants du système.
2. Protéger les données du compte :
   
   • Exigence 3 : protéger les données stockées sur les comptes (par exemple, crypter le PAN).
   • Exigence 4 : Protéger les données des titulaires de cartes par une cryptographie forte lors de leur transmission sur des réseaux ouverts et publics.
3. Maintenir un programme de gestion des vulnérabilités :
   
   • Exigence 5 : protéger tous les systèmes et réseaux contre les logiciels malveillants.
   • Exigence 6 : développer et maintenir des systèmes et des logiciels sécurisés (correctifs, codage sécurisé).
4. Mettre en œuvre des mesures de contrôle d'accès rigoureuses :
   
   • Exigence 7 : Restreindre l'accès aux composants du système et aux données des titulaires de cartes en fonction du besoin de savoir de l'entreprise.
   • Exigence 8 : identifier les utilisateurs et authentifier l'accès aux composants du système.
   • Exigence 9 : Restreindre l'accès physique aux données des titulaires de cartes.
5. Contrôler et tester régulièrement les réseaux :
   
   • Exigence 10 : Enregistrer et surveiller tous les accès aux composants du système et aux données des titulaires de cartes.
   • Exigence 11 : tester régulièrement la sécurité des systèmes et des réseaux (analyse des vulnérabilités, tests de pénétration).
6. Maintenir une politique de sécurité de l'information :
   
   • Exigence 12 : Soutenir la sécurité de l'information à l'aide de politiques et de programmes organisationnels.

La validation de la conformité varie en fonction du volume de transactions traitées annuellement (niveaux 1 à 4 pour les commerçants, niveaux 1 à 2 pour les prestataires de services), allant des questionnaires d'auto-évaluation annuels (SAQ) aux audits formels sur site par un évaluateur de sécurité qualifié (QSA), qui donnent lieu à un rapport de conformité (ROC). Des analyses de vulnérabilité externes trimestrielles effectuées par un fournisseur de services d'analyse agréé (ASV) sont généralement exigées. La version 4.0 de la norme PCI DSS est la version actuelle, dont les exigences deviendront obligatoires d'ici le 31 mars 2025.

Pourquoi est-ce important ?

Pour toute entreprise qui touche des données de cartes de paiement, la conformité à la norme PCI DSS est absolument essentielle :

• Requis pour l'acceptation de la carte : Elle est imposée par les grandes marques de cartes dans le cadre de contrats avec les banques acquéreuses. La non-conformité peut entraîner l'impossibilité d'accepter les paiements par carte.
• Prévention des violations de données : La mise en œuvre des contrôles PCI DSS réduit considérablement le risque de violations coûteuses des données des titulaires de cartes.
• Éviter de lourdes pénalités : La non-conformité peut entraîner des amendes mensuelles substantielles de la part des banques acquéreuses/marques de cartes (de 5 000 à plus de 100 000 dollars par mois), même si aucune infraction n'a été commise.
• Réduction de l'impact de la violation : En cas de violation, le fait d'être conforme à la norme PCI DSS démontre une diligence raisonnable et peut potentiellement réduire les amendes, la responsabilité juridique et les coûts d'indemnisation (tels que les frais de réémission des cartes).
• Renforcement de la confiance des clients : La conformité montre aux clients que vous prenez au sérieux la sécurité de leurs données de paiement, ce qui favorise la confiance et la fidélité.
• Protection de la réputation de la marque : Une violation des données de cartes bancaires nuit gravement à la réputation d'une entreprise. La norme PCI DSS permet d'éviter cela.
• Fournit une base de sécurité : Offre un cadre de sécurité de base solide qui améliore la posture de sécurité globale de l'organisation, et pas seulement pour les données de paiement.

Ignorer la norme PCI DSS n'est tout simplement pas une option pour les entreprises qui souhaitent accepter les cartes de paiement.

Quoi et comment mettre en œuvre (technique et politique)

La mise en œuvre de la norme PCI DSS implique la prise en compte des 12 exigences fondamentales par le biais de contrôles techniques et de politiques/procédures documentées. Les domaines clés ayant un impact sur le développement et les opérations sont les suivants :

1. Réseau sécurisé (Req 1 & 2) :
   
   • Mettre en œuvre et maintenir des pare-feu pour séparer l'environnement des données du titulaire de la carte (CDE) des autres réseaux.
   • Utiliser des configurations sécurisées : modifier les paramètres par défaut du fournisseur, désactiver les services/ports inutiles, durcir les systèmes. Preuves : Règles de pare-feu, normes de configuration, diagrammes de réseau.
2. Protéger les données des détenteurs de cartes (exigences 3 et 4) :
   
   • Minimiser le stockage : Ne stockez pas les données des titulaires de cartes, sauf en cas d'absolue nécessité. Ne jamais stocker les DAU après autorisation.
   • Masquer PAN : masque le numéro de compte primaire (PAN) lorsqu'il est affiché (seuls les 6 premiers et les 4 derniers chiffres sont visibles).
   • Chiffrer le PAN : rendre le PAN stocké illisible à l'aide d'une cryptographie forte (par exemple, AES-256) et d'une gestion robuste des clés.
   • Cryptage de la transmission : Crypter la CHD lors de sa transmission sur des réseaux ouverts/publics (utiliser des versions TLS robustes, des protocoles sécurisés). Preuves : Politique de conservation des données, diagrammes de flux de données, configuration de cryptage, procédures de gestion des clés.
3. Gestion des vulnérabilités (Req 5 & 6) :
   
   • Lutte contre les logiciels malveillants : Déployer et mettre à jour régulièrement des solutions anti-programmes malveillants sur les systèmes couramment affectés par des programmes malveillants.
   • Correctifs : mettre en œuvre un processus permettant d'identifier et d'appliquer rapidement les correctifs de sécurité (dans des délais définis pour les correctifs critiques).
   • Codage sécurisé : Développer des applications logicielles (internes ou sur mesure) sur la base de lignes directrices en matière de codage sécurisé (par exemple, OWASP), former les développeurs, traiter les vulnérabilités courantes en matière de codage (injection, XSS, etc.). Éléments de preuve : Dossiers de gestion des correctifs, politique de codage sécurisé, dossiers de formation des développeurs, résultats SAST/DAST.
4. Contrôle d'accès (Req 7, 8, 9) :
   
   • Le moindre privilège/besoin de savoir : Restrict access to CHD and system components based on job role and minimum necessary permissions.
   • Identifiants uniques et authentification : Attribuer des identifiants uniques pour l'accès ; mettre en œuvre une authentification forte (mots de passe/phrases de passe complexes, MFA - en particulier pour l'accès au CDE).
   • Sécurité physique : Sécuriser l'accès physique aux systèmes de stockage/traitement de la DCH. Éléments de preuve : Politiques de contrôle d'accès, configuration RBAC, paramètres MFA, politique de mot de passe, registres d'accès physique.
5. Contrôle et test (Req 10 & 11) :
   
   • Journalisation : Mettre en place un système de journalisation d'audit détaillé pour tous les composants du système ; suivre l'accès aux ressources du réseau et au CHD. Protéger les journaux contre la falsification. Utiliser la synchronisation du temps (NTP).
   • Examen des journaux : Examinez régulièrement les journaux pour détecter toute activité suspecte.
   • Analyse de la vulnérabilité : Effectuer tous les trimestres des analyses ASV externes et des analyses de vulnérabilité internes. Traiter les vulnérabilités.
   • Tests de pénétration : Effectuer chaque année des tests de pénétration internes/externes (et après des changements importants).
   • Détection/prévention des intrusions : Mise en œuvre de l'IDS/IPS.
   • Détection des modifications : Utiliser la surveillance de l'intégrité des fichiers (FIM) pour les fichiers critiques. Éléments de preuve : Procédures d'examen des journaux, configuration SIEM, rapports d'analyse ASV, rapports de pentest, journaux FIM.
6. Politique de sécurité de l'information (Req 12) :
   
   • Maintenir une politique globale de sécurité de l'information, la réviser annuellement et la distribuer au personnel concerné.
   • Définir les responsabilités en matière de sécurité, organiser une formation de sensibilisation.
   • Mettre en œuvre un plan de réponse aux incidents et le tester. Preuves : Document de politique InfoSec, dossiers de formation, plan de réponse aux incidents et résultats des tests.

La norme PCI DSS v4.0 introduit des mises à jour telles que des exigences plus strictes en matière de mots de passe/MFA, une applicabilité plus large des contrôles, de nouvelles exigences en matière de prévention du phishing et de sécurité des scripts sur les pages de paiement, et permet une "approche personnalisée" pour satisfaire aux exigences dans des conditions spécifiques, parallèlement à l'"approche définie" traditionnelle.

Les erreurs courantes à éviter

Atteindre et maintenir la conformité à la norme PCI DSS est souvent un défi. Évitez ces erreurs courantes :

1. Une délimitation incorrecte du champ d'application : Ne pas identifier avec précision tous les systèmes, réseaux et applications qui stockent, traitent ou transmettent des DCH, ou qui pourraient avoir un impact sur la sécurité du CDE. Il s'agit de l'erreur la plus grave.
2. Stockage de données d'authentification sensibles (SAD) : Stockage illégal de données CVV2, de données de suivi complet ou de données PIN après autorisation.
3. Protection inadéquate des données : Stockage de PANs non cryptés, utilisation d'un faible cryptage/gestion des clés, ou transmission de CHD sur des canaux non sécurisés.
4. Contrôle d'accès faible : Utilisation d'informations d'identification partagées/par défaut, absence d'AMF pour l'accès au CDE, absence d'application du principe du moindre privilège, absence de révocation rapide de l'accès.
5. Insuffisance de l'enregistrement et de la surveillance : Ne pas enregistrer les événements pertinents, ne pas examiner régulièrement les journaux, ou ne pas protéger les journaux contre la falsification.
6. Ignorer la gestion des vulnérabilités : Sauter les analyses ASV trimestrielles, échouer les analyses internes, ne pas corriger rapidement les vulnérabilités critiques.
7. Mauvaises pratiques de codage sécurisé : Développement d'applications présentant des vulnérabilités courantes (SQLi, XSS) qui exposent la CHD.
8. Négliger les politiques et les procédures : Absence de politiques, de procédures ou d'un plan d'intervention en cas d'incident documentés, ou absence de formation des employés.
9. Conformité des fournisseurs : Supposer que les fournisseurs de services tiers sont conformes sans vérifier ou sans disposer d'accords contractuels appropriés.
10. Traiter la conformité comme un processus annuel : Considérer la norme PCI DSS comme un simple audit/QSA annuel au lieu d'un processus de sécurité continu.

Ce que les auditeurs/QSAs pourraient demander (Developer Focus)

Un évaluateur de sécurité qualifié (QSA) effectuant un audit pour PCI DSS examinera les pratiques de développement liées à l'exigence 6 (systèmes et logiciels sécurisés) :

• (Req 6.2) "Décrivez vos processus de cycle de développement de logiciels sécurisés (SSDLC)".
• (Req 6.2.1) "Comment les logiciels personnalisés et sur mesure sont-ils développés sur la base des normes industrielles et/ou de la norme PCI DSS (par exemple, les directives de codage sécurisé comme OWASP) ?"
• (Req 6.2.2) "Comment les développeurs sont-ils formés aux techniques de codage sécurisé ?" (Montrer les dossiers de formation)
• (Req 6.2.3) "Comment les modifications du code sont-elles examinées pour détecter les vulnérabilités de sécurité avant la publication ?" (Décrire le processus de révision du code)
• (Req 6.2.4) "Comment assurez-vous la séparation des tâches entre les environnements de développement/test et de production ?"
• (Req 6.3) "Comment identifiez-vous et inventoriez-vous les logiciels sur mesure et personnalisés ?"
• (Req 6.4 - v4.0) "Comment gérez-vous les scripts des pages de paiement pour garantir l'intégrité et autoriser les scripts ?" (pertinent pour les développeurs web)
• (Req 6.5 - v3.2.1 / divers dans v4.0) "Comment vous protégez-vous contre les vulnérabilités de codage courantes telles que les failles d'injection, les débordements de mémoire tampon, le stockage cryptographique non sécurisé, les XSS, etc. (Nécessite de montrer des exemples de code, l'utilisation d'outils - SAST/DAST)
• (Req 3) "Montrer comment les données sensibles (PAN) sont protégées dans le stockage (cryptage, hachage, troncature) au sein de l'application."
• (Exigence 4) "Démontrer comment les données sensibles sont cryptées lors de la transmission".
• (Req 8) "Comment l'application applique-t-elle la complexité du mot de passe et les exigences de l'AMF ?"

Les QSA ont besoin de preuves concernant les processus documentés, la formation des développeurs, le respect des normes de codage sécurisé, les revues de code, les résultats des tests de sécurité (SAST/DAST) et la configuration sécurisée au sein de l'application.

Des gains rapides pour les équipes de développement

Les développeurs peuvent contribuer de manière significative à la conformité à la norme PCI DSS:

1. NE JAMAIS stocker le DAU : s'assurer que le code n'enregistre, ne stocke ou ne conserve jamais le CVV2, les données de suivi ou les codes PIN après autorisation.
2. Minimiser le traitement des CHD : Si possible, utilisez des processeurs de paiement tiers ou des passerelles qui évitent à la CHD d'entrer dans vos systèmes (ce qui réduit le champ d'application). Si vous devez les traiter, réduisez au minimum les endroits où ils circulent et sont stockés.
3. Bases du codage sécurisé : Se concentrer sur la prévention des vulnérabilités du Top 10 de l'OWASP, en particulier l'injection (SQLi, injection de commande) et le Cross-Site Scripting (XSS), grâce à la validation des entrées et à l'encodage des sorties.
4. Paramétrer les requêtes de la base de données : Utilisez toujours des instructions préparées ou des requêtes paramétrées pour éviter les injections SQL.
5. Cryptage, hachage et tokenisation du PAN : si vous stockez le PAN, utilisez un cryptage fort et standard (AES-256) avec une gestion appropriée des clés, ou envisagez des solutions de tokenisation. N'utilisez pas votre propre cryptographie.
6. Utiliser un protocole TLS solide : s'assurer que toutes les transmissions de CHD utilisent des versions TLS actuelles et sécurisées et des suites de chiffrement solides.
7. Mettre en œuvre la validation des entrées : Validez rigoureusement toutes les entrées provenant des utilisateurs ou des systèmes externes.
8. Appliquer les en-têtes de sécurité : Utiliser les en-têtes de sécurité HTTP (comme Content-Security-Policy) pour limiter les attaques XSS et autres attaques côté client, ce qui est particulièrement important pour la Req 6.4 dans la v4.0.

Ignorez ceci et... (Conséquences de la non-conformité)

Ignorer la norme PCI DSS peut s'avérer financièrement handicapant et dévastateur pour la réputation de l'entreprise :

• Amendes mensuelles : Les banques acquéreuses imposent de lourdes amendes en cas de non-conformité, allant généralement de 5 000 à plus de 100 000 dollars par mois, et augmentant en fonction du niveau de conformité et de la durée de la non-conformité.
• Augmentation des frais de transaction : Les banques peuvent augmenter les frais de transaction pour les commerçants qui ne respectent pas les règles.
• Pénalités imposées par la marque de la carte : Les marques de cartes peuvent imposer directement des pénalités supplémentaires.
• Cessation du traitement des cartes : Les banques peuvent révoquer entièrement la capacité d'accepter les cartes de paiement, ce qui a pour effet d'interrompre les flux de revenus liés aux paiements par carte.
• Coûts des violations de données : Si la non-conformité conduit à une violation, les coûts montent en flèche. Cela comprend les enquêtes judiciaires, les coûts de remplacement des cartes (3-5+ par carte), la surveillance du crédit pour les victimes, les frais juridiques, les amendes réglementaires (par exemple, GDPR si applicable), et les poursuites potentielles.
• Atteinte à la réputation : La divulgation publique d'un cas de non-conformité ou d'une violation des données d'une carte porte gravement atteinte à la confiance des clients et à l'image de la marque.
• Une surveillance accrue : En cas de non-conformité ou de violation, les organisations sont soumises à une surveillance accrue de la part des banques et des sociétés émettrices de cartes.

FAQ

Qui doit se conformer à la norme PCI DSS ?

Toute organisation qui accepte, traite, stocke ou transmet des données de titulaires de cartes des principales marques de cartes (Visa, Mastercard, American Express, Discover, JCB). Cela inclut les commerçants, les fournisseurs de services (comme les processeurs de paiement, les fournisseurs d'hébergement) et les institutions financières.

Quelle est la différence entre PCI DSS v3.2.1 et v4.0 ?

La version 4.0 de la norme PCI DSS est la plus récente et remplace la version 3.2.1 (qui prend fin le 31 mars 2024, bien que les nouvelles exigences de la version 4.0 soient considérées comme des bonnes pratiques jusqu'au 31 mars 2025). Les principaux changements apportés par la version 4.0 sont les suivants : mise à jour des exigences relatives aux mots de passe et à l'AMF, élargissement de l'applicabilité des contrôles de sécurité, nouvelles exigences ciblant les attaques par hameçonnage et par écrémage du commerce électronique, orientations plus claires et introduction d'une "approche personnalisée" comme moyen alternatif de satisfaire aux objectifs des exigences, parallèlement à l'"approche définie" traditionnelle.

Qu'est-ce que les niveaux des marchands et des fournisseurs de services ?

Ils classent les organisations en fonction du volume annuel de transactions par carte qu'elles traitent. Le niveau 1 (volume le plus élevé) présente les exigences de validation les plus strictes (ROC annuel par QSA, scans ASV trimestriels). Les niveaux 2, 3 et 4 ont des volumes progressivement plus faibles et sont généralement validés par des SAQ annuels et des scans ASV trimestriels.

Qu'est-ce qu'un QSA et un ASV ?

Un QSA (Qualified Security Assessor) est une personne certifiée par le PCI SSC pour effectuer des évaluations PCI DSS sur site et produire des rapports de conformité (ROC) pour les commerçants/fournisseurs de services de niveau 1. Un ASV (Approved Scanning Vendor) est une organisation certifiée par le PCI SSC pour effectuer les analyses trimestrielles de vulnérabilité du réseau externe.

Qu'est-ce que l'environnement des données des titulaires de cartes (CDE) ?

Le CDE comprend les personnes, les processus et la technologie qui stockent, traitent ou transmettent les données des titulaires de cartes ou les données d'authentification sensibles. La définition précise de la portée de l'EDC est la première étape critique de la conformité à la norme PCI DSS, car les exigences s'appliquent principalement à cet environnement. La segmentation du réseau peut être utilisée pour réduire la portée de l'EDC.

Peut-on stocker le code CVV2 ?

Les données d'authentification sensibles (DAS), qui comprennent le code de vérification de la carte à 3 ou 4 chiffres (CVV2, CVC2, CID, CAV2), les données complètes de la bande magnétique et les codes PIN, ne doivent jamais être stockées une fois que l'autorisation de la transaction est terminée. Le stockage du DAU constitue une violation majeure de la conformité.

La conformité à la norme PCI DSS est-elle une obligation légale ?

Bien que PCI DSS soit une norme industrielle créée par les marques de cartes, la conformité est généralement imposée par contrat dans le cadre d'accords entre les commerçants, les banques acquéreuses et les marques de cartes. Le non-respect de ces accords constitue une violation de ces contrats, ce qui entraîne des pénalités appliquées par les banques/marques. Il peut également y avoir un chevauchement avec des exigences légales telles que le GDPR si des données personnelles sont impliquées.