Conformité PCI DSS 4.0 : ce que vous devez savoir

Conformité PCI

Conformité PCI DSS 4.0 : ce que vous devez savoir

Le 31 mars 2024, la version 3.2.1 de la norme PCI DSS a officiellement pris fin. Si votre entreprise accepte, traite, transmet ou stocke des données de titulaires de carte, vous devez désormais vous conformer à la norme PCI DSS version 4.0, la refonte la plus importante de la norme de sécurité des données de l'industrie des cartes de paiement en plus d'une décennie. Manquer cette transition n'est pas simplement une question de paperasse; la non-conformité peut entraîner des amendes des réseaux de cartes, des frais de transaction plus élevés et, dans les cas graves, la perte de la capacité de traiter les paiements par carte.

Ce guide décortique tout ce que les marchands, facilitateurs de paiement, plateformes SaaS et institutions financières doivent comprendre au sujet de PCI DSS 4.0, de ce qui a changé jusqu'à la façon de réduire considérablement votre fardeau de conformité.

Ce qui a changé dans PCI DSS 4.0

PCI DSS 4.0 a été publiée en mars 2022, donnant aux organisations un délai de transition de deux ans. Cette révision a été motivée par l'évolution du paysage des menaces, la prolifération des environnements infonuagiques et le besoin d'une plus grande flexibilité dans la façon dont les organisations démontrent leur sécurité. Voici les principaux changements :

• Approche personnalisée : Pour la première fois, les organisations peuvent utiliser une « approche personnalisée » pour répondre à l'intention d'une exigence à l'aide de contrôles alternatifs, plutôt que de suivre des approches définies et normatives. Cela offre une flexibilité aux programmes de sécurité matures, mais exige beaucoup plus de documentation et d'évaluation.
• Analyse de risque ciblée (TRA) : De nombreuses exigences qui avaient auparavant des fréquences fixes (par exemple, « réviser les journaux tous les X jours ») exigent désormais que les organisations effectuent une analyse de risque ciblée pour déterminer une fréquence appropriée selon leur profil de risque spécifique.
• Refonte de l'authentification : L'authentification multifacteur (MFA) est désormais requise pour tout accès à l'environnement des données des titulaires de carte (CDE), et non plus seulement pour l'accès à distance. Les mots de passe doivent compter au moins 12 caractères (contre 8 auparavant) et les règles de complexité ont été resserrées.
• Accent sur le commerce électronique et l'hameçonnage : De nouvelles exigences portent sur la sécurité des scripts des pages de paiement, la protection contre les attaques d'écrémage web (de type Magecart) et des contrôles anti-hameçonnage renforcés.
• Rôles et responsabilités : Chaque exigence exige désormais explicitement que les organisations documentent qui est responsable de la remplir, ce qui représente un effort de documentation important pour bien des entreprises.

Échéancier de conformité

Comprendre l'échéancier de PCI DSS 4.0 est essentiel, car la norme a introduit une approche par phases pour certaines de ses nouvelles exigences :

• 31 mars 2022 : PCI DSS v4.0 est publiée et disponible.
• 31 mars 2024 : PCI DSS v3.2.1 prend fin. Toutes les évaluations doivent désormais se faire selon la v4.0.
• 31 mars 2025 : Toutes les exigences « à date future » de la v4.0 deviennent obligatoires. Il s'agissait d'exigences désignées comme meilleures pratiques dans la publication initiale de la 4.0 afin de donner aux organisations le temps de se préparer.

L'échéance de mars 2025 est la plus importante. Environ 64 exigences avaient été désignées comme « meilleure pratique jusqu'au 31 mars 2025 ». Si votre organisation a complété une évaluation 4.0 avant cette date, vous avez peut-être réussi sans même les avoir mises en place. À partir du 1er avril 2025, les 64 exigences sont pleinement obligatoires et seront testées lors des évaluations.

Les 12 exigences fondamentales

La norme PCI DSS est organisée autour de 12 exigences de haut niveau, qui demeurent dans la v4.0, mais avec des changements importants aux sous-exigences :

Principales nouvelles exigences de PCI DSS 4.0

Au-delà des changements structurels, voici les nouvelles exigences précises qui toucheront la plupart des organisations :

Protection contre l'écrémage web (exigences 6.4.3 et 11.6.1)

Pour les marchands en commerce électronique qui utilisent des pages de paiement, PCI DSS 4.0 introduit deux nouvelles exigences visant les attaques d'écrémage par JavaScript, soit des scripts malveillants injectés dans les pages de paiement pour voler les données de carte. Les organisations doivent désormais tenir un inventaire de tous les scripts chargés sur les pages de paiement, justifier la nécessité de chacun et détecter les modifications non autorisées des en-têtes HTTP et du contenu des pages de paiement. Il s'agit d'un changement important pour toute entreprise utilisant des scripts tiers, des gestionnaires de balises ou des CDN sur ses pages de paiement.

MFA pour tout accès au CDE (exigence 8.4.2)

L'authentification multifacteur est désormais requise pour tout accès administratif hors console et tout accès utilisateur à l'environnement des données des titulaires de carte. Auparavant, la MFA n'était exigée que pour l'accès à distance. Cela signifie que même les utilisateurs internes qui accèdent aux systèmes du CDE depuis le réseau corporatif doivent utiliser la MFA.

Exigences de mot de passe renforcées (exigence 8.3.6)

Les mots de passe doivent désormais compter un minimum de 12 caractères (contre 8 auparavant), ou au moins 8 caractères si le système ne prend pas en charge 12 caractères. Ce changement en apparence simple exige des mises à jour des systèmes de gestion des identités, de la formation des utilisateurs et potentiellement des déploiements de gestionnaires de mots de passe.

Analyse de risque ciblée (plusieurs exigences)

De nombreuses exigences auparavant normatives incluent désormais une option de « réaliser une analyse de risque ciblée », permettant aux organisations d'établir leurs propres fréquences pour des activités comme la révision des journaux, les analyses de vulnérabilité et les révisions d'accès, à condition de documenter leur raisonnement fondé sur le risque. Cela accroît la flexibilité, mais aussi le fardeau documentaire.

Questionnaires d'auto-évaluation dans PCI DSS 4.0

Toutes les organisations n'ont pas besoin d'un évaluateur de sécurité qualifié (QSA) pour réaliser un audit complet. La plupart des marchands de petite et moyenne taille peuvent utiliser un questionnaire d'auto-évaluation (SAQ). PCI DSS 4.0 a mis à jour tous les formulaires SAQ pour les harmoniser avec les nouvelles exigences. Les principaux types de SAQ sont :

• SAQ A : Pour les marchands de commerce électronique ou de commande par courrier/téléphone qui ont entièrement confié toutes les fonctions liées aux données des titulaires de carte. Les données de carte sont entièrement gérées par un tiers conforme PCI. C'est le SAQ le plus simple, avec le moins d'exigences.
• SAQ A-EP : Pour les marchands de commerce électronique qui confient le traitement des paiements à un tiers, mais dont le site web influence la sécurité de la transaction (p. ex., redirection vers une page de paiement). Inclut désormais les exigences d'écrémage web.
• SAQ B : Pour les marchands utilisant uniquement des machines à imprimer ou des terminaux autonomes par composition téléphonique, sans stockage électronique des données de titulaires de carte.
• SAQ B-IP : Pour les marchands utilisant des terminaux de paiement autonomes approuvés PTS connectés par IP.
• SAQ C : Pour les marchands dont les systèmes d'application de paiement sont connectés à Internet, mais sans stockage électronique des données de titulaires de carte.
• SAQ D : Pour tous les autres marchands et tous les fournisseurs de services. Le SAQ le plus complet.

Le choix du bon SAQ dépend entièrement de votre environnement d'acceptation des paiements. L'utilisation d'une solution de paiement intégrée qui garde les données des titulaires de carte entièrement hors de vos systèmes peut vous permettre de vous qualifier pour le SAQ A, la voie la plus simple vers la conformité.

Comment TIB Finance réduit votre périmètre PCI

La stratégie la plus efficace pour la conformité PCI DSS n'est pas de devenir expert des plus de 300 exigences, c'est de réduire autant que possible le périmètre de votre environnement de données des titulaires de carte. Réduire le périmètre signifie moins de systèmes, moins d'exigences et moins de risque.

TIB Finance a été conçue avec la réduction du périmètre PCI comme principe architectural fondamental :

• Champs de paiement hébergés : Les champs de paiement JavaScript de TIB Finance capturent les données de carte directement dans l'infrastructure conforme PCI de TIB Finance. Les numéros de carte bruts ne touchent jamais vos serveurs, ce qui signifie que votre application web et vos serveurs de base de données sont hors périmètre pour la plupart des exigences PCI.
• Tokenisation : Une fois qu'une carte est traitée, TIB Finance renvoie un jeton de paiement réutilisable. Vous pouvez stocker ce jeton en toute sécurité pour facturer les clients de nouveau plus tard, sans jamais stocker les données réelles de la carte. Pour en savoir plus, consultez notre guide sur la tokenisation par rapport au chiffrement.
• Traitement prêt pour le P2PE : Pour les environnements avec carte présente, TIB Finance prend en charge les solutions de chiffrement point à point (P2PE) qui chiffrent les données de carte directement à l'appareil avant qu'elles n'entrent dans votre réseau, réduisant considérablement le périmètre PCI de votre environnement de point de vente.
• Admissibilité au SAQ A : En s'intégrant à la page de paiement hébergée ou aux champs hébergés de TIB Finance, la plupart des marchands en commerce électronique deviennent admissibles au SAQ A, le questionnaire d'auto-évaluation le plus simple et le plus court.
• Contrôles de sécurité intégrés : L'infrastructure de TIB Finance est évaluée annuellement par un QSA et maintient une attestation de conformité (AOC) à jour. Lorsque vos données de titulaires de carte se trouvent dans notre environnement, vous bénéficiez de notre programme de conformité.

Votre plan d'action

Si vous n'êtes pas certain de votre statut de conformité actuel, voici un point de départ concret :

1. Définissez votre environnement de données des titulaires de carte. Où circulent les données de carte? Cartographiez chaque système qui touche, stocke, traite ou transmet des données de titulaires de carte.
2. Déterminez votre niveau de marchand. Votre volume de transactions détermine si vous avez besoin d'une évaluation QSA ou si vous pouvez utiliser un SAQ. Consultez le guide de conformité PCI pour les propriétaires d'entreprise pour un aperçu des niveaux de marchand.
3. Choisissez le bon SAQ. Selon la façon dont vous acceptez les paiements, sélectionnez le SAQ qui s'applique à votre environnement.
4. Comblez les écarts liés à la version 4.0. Passez en revue le document de résumé des changements du PCI SSC et déterminez quelles nouvelles exigences s'appliquent à votre environnement, en particulier les exigences d'écrémage web et de MFA.
5. Mettez en œuvre la réduction de périmètre. Si vous utilisez une intégration de paiement qui fait transiter des données de carte par votre environnement, évaluez si une solution tokenisée ou hébergée d'un processeur comme TIB Finance pourrait sortir ces systèmes du périmètre.
6. Complétez votre évaluation. Remplissez votre SAQ ou retenez les services d'un QSA, documentez vos contrôles et soumettez votre attestation de conformité à votre banque acquéreuse.

PCI DSS 4.0 constitue une mise à niveau importante des normes de sécurité des paiements, et bien que l'effort de conformité soit réel, l'objectif sous-jacent est de protéger vos clients et votre entreprise du coût bien réel d'une brèche de données. Le coût moyen d'une brèche de données de carte de paiement se chiffre en millions de dollars en amendes, en correctifs et en atteinte à la réputation.

Pour un aperçu plus large des pratiques de sécurité des paiements, consultez notre guide sur les meilleures pratiques de sécurité des paiements pour 2025. Si vous intégrez les paiements dans une plateforme logicielle, notre guide d'intégration de l'API de paiement couvre les détails techniques de la mise en place d'une intégration sécurisée et conforme.