Le dimanche 31 mars 2024, une date importante à l’échelle mondiale, est désormais derrière nous. Pourquoi dis-je cela ? Pour toute organisation acceptant des paiements de consommateurs, c’est 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 soumise au calendrier de mise en conformité PCI DSS 4.0 et devra avoir rempli un questionnaire SAQ conforme à la version 4.0 et fait réaliser un audit par un organisme externe d’ici mars 2025. Le non-respect de la norme PCI DSS 4.0 n’est pas envisageable si vous souhaitez comptabiliser des revenus issus des paiements de consommateurs.
La spécification PCI DSS 4.0 constitue une évolution majeure par rapport à la version 3.2.1. Vous pouvez consulter le récapitulatif des changements ici. La version 4.0 introduit de nombreux changements (ainsi qu’un SAQ mis à jour). Toutefois, deux domaines entièrement nouveaux doivent être sécurisés dans l’architecture 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 légèrement une partie seulement des « logiciels sur mesure ». Il s’agit de logiciels personnalisés développés par l’organisation afin de faciliter les paiements des consommateurs. Les logiciels sur mesure sont les suivants :
- 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 envoyé au navigateur web du consommateur (côté client de la transaction) afin de permettre la collecte de données
Pour de nombreuses organisations, l’un des défis consistera à étendre au navigateur web du consommateur la sécurité et la conformité à la norme PCI DSS des logiciels sur mesure (exigences 6.4.1 et 11.6.1). Sécuriser les transactions implique désormais non seulement de sécuriser le côté serveur, mais aussi de surveiller et de protéger le navigateur web du consommateur contre les « logiciels sur mesure » qui y ont été déployés. En outre, le fait d’obtenir auprès d’un tiers le logiciel sur mesure (par exemple, JavaScript) destiné au navigateur web du client ne dispense pas l’entité qui collecte les paiements de le surveiller et de le protéger. Rejeter la faute sur le fournisseur ne vous mènera à rien auprès de l’auditeur.
Alors, quelles sont les exigences applicables aux logiciels sur mesure côté client ? D’après la section 6.4.1, elles se résument à ceci :
Tous les scripts de la page de paiement chargés et exécutés dans le navigateur du consommateur sont gérés comme suit :
- Une méthode est mise en œuvre pour confirmer que chaque script est autorisé.
- Une méthode est mise en œuvre pour garantir l’intégrité de chaque script.
- Un inventaire de tous les scripts est tenu à jour, avec une justification écrite expliquant pourquoi chacun d’eux est nécessaire.
Cela signifie que tous les logiciels (scripts) déployés doivent être inventoriés, justifiés et surveillés, et qu’un plan d’action doit être prévu pour remédier à toute faille détectée. Votre personnel chargé de la sécurité des applications et des systèmes informatiques est-il prêt à gérer, surveiller et documenter cette exigence ? Votre équipe et vous-même avez-vous discuté avec votre auditeur PCI DSS de la planification de l’évaluation de conformité à la version 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 qu’il ne perturbe ni vos opérations de sécurité ni, surtout, la collecte des revenus de votre organisation. Car l’échéance pour sécuriser le côté client de vos transactions afin de respecter les exigences de la norme PCI DSS 4.0 est bien plus proche que vous ne le pensez.
À propos de l’auteur
Articles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.