La norme de sécurité des données de l’industrie des cartes de paiement (PCI DSS) v3.2.1 n’est-elle pas arrivée à expiration le 31 mars 2024 et n’a-t-elle pas été remplacée par la norme PCI DSS v4.0 ?
Oui, et oui.
Toutefois, afin de répondre aux commentaires et aux questions reçus après la publication de PCI DSS v4.0, le Conseil des normes de sécurité PCI (PCI SSC) a décidé de publier une révision limitée de la norme : PCI DSS v4.0.1. (Lorsque PCI DSS v4.0 sera retirée le 31 décembre 2024, la version 4.0.1 deviendra la seule norme active prise en charge par le PCI SSC.)
La norme PCI DSS v4.0.1 comporte plusieurs changements importants que vous devez connaître lorsque vous mettez à jour ou développez vos dispositifs de sécurité et de conformité des transactions. Par souci de concision, cet article de blog présente les changements et mises à jour pris en charge par les solutions de sécurité des applications et des API de F5. Vous trouverez une liste plus complète des changements sur le site Web du PCI SSC.
Les mises à jour les plus pertinentes incluses dans la norme PCI DSS v4.0.1 visent à clarifier la portée des exigences de sécurité côté client.
Qui est responsable de quoi ?
Exigence 6.4.3
Cette exigence stipule que tous les scripts des pages de paiement chargés et exécutés dans le navigateur du consommateur doivent être 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, accompagné d’une justification métier ou technique écrite expliquant pourquoi chacun d’eux est nécessaire.
En règle générale, les commerçants font appel à des prestataires de services de paiement ou à des prestataires de services tiers (PSP ou TPSP) pour traiter les paiements, ce qui détermine la manière dont le consommateur règle les biens ou services achetés. Cette exigence PCI a suscité une certaine confusion quant au modèle de responsabilité applicable lorsque les commerçants utilisaient des cadres intégrés (iframes) de PSP/TPSP contenant la page de paiement. Une iframe est essentiellement une petite page web affichée pour assurer une fonctionnalité spécifique. Des scripts peuvent également s’y exécuter, ce qui l’expose aux mêmes risques que les pages web parentes. Les iframes doivent-elles donc respecter les mêmes exigences PCI que les pages parentes ?
La mise à jour v4.0.1 précise que les commerçants sont uniquement responsables des scripts exécutés sur leur propre page (la page parente), et non de ceux exécutés dans les iframes des PSP/TPSP.
Bonne pratique : Il incombe au commerçant de collaborer avec le fournisseur des pages intégrées dans des iframes PSP/TPSP afin de s’assurer qu’elles sont conformes et sécurisées. Si le commerçant ne satisfait pas à cette exigence, il s’expose à des fraudes au paiement, susceptibles d’entraîner des pertes commerciales et un contrôle approfondi de la part du PCI.
Exigence 11.6.1
Des clarifications similaires ont été apportées concernant l’exigence 11.6.1, en mettant l’accent sur le système d’en-têtes HTTP et de scripts reçus par le navigateur du consommateur qui ont une incidence sur la sécurité. Il s’agit d’un changement important, car la norme PCI indique clairement qu’elle se concentre sur les risques associés à cette exigence, plutôt que d’imposer une protection plus large contre les incidents liés aux en-têtes HTTP et aux scripts sans rapport avec la sécurité.
Le modèle de responsabilité applicable aux iframes intégrées par les PSP/TPSP a également été mis à jour afin de préciser que le commerçant est uniquement responsable de la page web parente, tandis que le prestataire PSP/TPSP est responsable des en-têtes HTTP et des scripts ayant une incidence sur la sécurité qui sont affichés dans ses iframes.
Le temps presse
À moins de neuf mois de l’échéance de mars 2025 fixée pour la mise en œuvre des nouvelles exigences, les organisations doivent gérer toutes les complexités liées aux changements proposés et à la conformité à la norme PCI DSS v4.0.1.
F5 et PCI DSS v4.0.1
Protection des applications web et des API F5 Distributed Cloud (WAAP), Distributed Cloud Bot Defense, Distributed Cloud Client-Side Defense, ainsi que Suite de sécurité des applications mobiles de F5 Distributed Cloud Services constituent le socle de la protection de l’ensemble des transactions entre les entreprises et les consommateurs. Pour les scripts côté client, Distributed Cloud Client-Side Defense peut offrir la visibilité et le contrôle nécessaires pour assurer la conformité. F5 Distributed Cloud Services est actuellement conforme à la norme PCI DSS v4.0 et fait régulièrement l’objet d’audits de conformité réalisés par un cabinet d’audit agréé. Les organisations doivent être conformes à la norme PCI DSS v4.0.1 d’ici au 1er janvier 2025, et les questionnaires d’auto-évaluation doivent être mis à jour en conséquence.
Enfin, les organisations soumises aux exigences de la norme PCI DSS peuvent s’attendre à des modifications des documents suivants au cours des prochains trimestres civils :
- Questionnaires d’auto-évaluation (SAQ)
- Rapport de conformité (ROC)
- Attestations de conformité (AOC)
Bonne pratique : Surveillez https://blog.pcisecuritystandards.org pour vous tenir informé des mises à jour ou des révisions des normes, et échangez avec votre auditeur PCI DSS afin de vous assurer que votre organisation est en bonne voie pour satisfaire aux exigences de la norme PCI DSS.
Pour en savoir plus, consultez f5.com/products/distributed-cloud-services.
À 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.