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 :

• Conçu en interne ou provenant de sources 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

Nombre d’organisations rencontreront des difficultés à étendre la sécurité et la conformité PCI DSS des logiciels personnalisés jusqu’au navigateur web du consommateur (exigences 6.4.1 ; 11.6.1). Assurer la sécurité des transactions oblige désormais à protéger non seulement le serveur, mais aussi à surveiller et sécuriser le navigateur web du consommateur contre les logiciels personnalisés que vous avez déployés. S’approvisionner en logiciel personnalisé (par exemple, JavaScript) pour le navigateur client auprès d’un tiers ne vous exonère pas de la responsabilité de le surveiller et de le protéger. Chercher à rejeter la faute sur la source ne convaincra pas 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.