L'horloge PCI DSS 3.2.1 a atteint minuit... Êtes-vous prêt pour la version 4.0 ?

Le dimanche 31 mars 2024, une date importante à l’échelle mondiale est arrivée et repartie. Pourquoi je dis ça ? Pour toute organisation acceptant les paiements des consommateurs, il s'agit de la date à laquelle la norme de conformité PCI DSS 3.2.1 a été retirée (du 1er mai 2018 au 31 mars 2024). Votre organisation est désormais sur la chronologie PCI DSS 4.0 et devra avoir complété un SAQ conforme à la norme 4.0 et un audit par un organisme externe d'ici mars 2025. Le non-respect de la norme PCI DSS 4.0 n’est pas une option si vous souhaitez générer des revenus via les paiements des consommateurs.

La spécification PCI DSS 4.0 est une mise à niveau majeure de la version 3.2.1 et vous pouvez trouver le résumé des modifications ici . La version 4.0 introduit de nombreux changements ( ainsi qu'un SAQ mis à jour ), mais il existe deux nouveaux domaines qui doivent être sécurisés dans la structure globale afin d'atteindre et de maintenir la conformité :

• Interface de programmation d'application (API) [2.2.7; 6.2.3; 6.2.4]
• Logiciel sur mesure [6.X; 8.6.2; 12.8.1]

Par souci de simplicité, nous allons approfondir un peu une partie du « logiciel sur mesure » uniquement. Il s’agit d’un logiciel personnalisé conçu par l’organisation pour faciliter le paiement des consommateurs. Le logiciel sur mesure est le suivant :

• Développé en interne ou à partir de sources tierces externes
• Logiciel développé pour l'application de paiement (côté serveur de la transaction) ou déployé sur le navigateur Web du consommateur (côté client de la transaction) pour piloter la collecte de données

Pour de nombreuses organisations, le défi consistera à étendre la sécurité et la conformité PCI DSS des logiciels sur mesure au navigateur Web du consommateur (Exigences 6.4.1 ; 11.6.1). Sécuriser les transactions signifie désormais non seulement sécuriser le côté serveur, mais également surveiller et protéger le navigateur Web du consommateur contre les « logiciels sur mesure » qu’ils ont déployés. Et l’obtention d’un logiciel sur mesure (par exemple, JavaScript) pour le navigateur Web du client auprès d’un tiers ne dispense pas le collecteur de paiement de devoir le surveiller et le protéger. Tenter de pointer du doigt la source ne vous mènera nulle part auprès de l’auditeur.

Alors, quelles sont les exigences pour un logiciel sur mesure côté client ? À partir de la section 6.4.1, cela se résume à ceci :

Tous les scripts de page 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 implémentée pour confirmer que chaque script est autorisé.
• Une méthode est implémentée pour assurer l'intégrité de chaque script.
• Un inventaire de tous les scripts est maintenu avec une justification écrite expliquant pourquoi chacun est nécessaire.

Cela signifie que tous les logiciels (scripts) déployés doivent être inventoriés, justifiés et surveillés avec un plan de jeu pour remédier à une violation identifiée. Votre personnel chargé de la sécurité des applications et de l’informatique est-il prêt à gérer, surveiller et rendre compte de cette exigence ? Avez-vous et votre équipe eu une conversation avec votre auditeur PCI DSS sur la planification d'un examen de conformité 4.0 ? Il est temps de vous assurer que votre plan de sécurité et de conformité PCI DSS est sur la bonne voie et ne perturbe pas vos opérations de sécurité et, plus important encore, la collecte des revenus de votre organisation. Parce que sécuriser le côté client de vos transactions pour répondre à la conformité PCI DSS 4.0 est beaucoup plus proche que vous ne l'imaginez.