La norme PCI DSS est un ensemble de normes de sécurité établies en 2004 par les principales sociétés de cartes de crédit, car, sans surprise, les applications qui traitent les paiements sont des cibles très attrayantes pour les pirates et les acteurs malveillants.
La mission de la norme PCI DSS est de sécuriser les transactions par carte de crédit et de débit, non seulement pour limiter les pertes pour les banques et le secteur des cartes de paiement, mais également pour augmenter la confiance et la sécurité des consommateurs. Cela est possible grâce à un ensemble de contrôles de sécurité qui protègent la confidentialité, l’intégrité et l’exactitude des données de carte. Cette norme de conformité s'applique à toutes les organisations qui stockent, traitent et transmettent des données de carte de crédit. Contrairement au NIST, qui est un cadre que vous êtes fortement encouragé, mais que vous n’êtes pas obligé de suivre, vous devez absolument vous conformer à la norme PCI DSS.
La norme PCI DSS comprend 12 exigences regroupées en six objectifs de contrôle, garantissant que les organisations qui traitent, stockent ou transmettent les données de carte de crédit maintiennent un environnement sécurisé. La conformité contribue à protéger les informations des titulaires de carte et à renforcer les mesures de sécurité globales.
Règle n° 5 : Protection contre les malware
Il existe également quatre niveaux de conformité, en fonction du nombre annuel de transactions par carte de crédit/débit traitées. La classification détermine ce que l’organisation doit faire pour rester conforme :
Tous les membres de l’organisation jouent un rôle dans le maintien de la conformité. Cela commence en haut avec les DSSI, puis se répercute sur les équipes SecOps et DevOps. Dans un monde DevSecOps idéal, il n'existe pas de hiérarchie en matière de responsabilité de sécurité entre les deux équipes, elles travaillent de concert. Les SecOps doivent aider les équipes DevOps à comprendre ce qu’elles doivent faire, et les développeurs doivent exécuter cela au niveau de l’application.
En suivant les 12 exigences de la norme PCI DSS, voici quelques exemples de la manière dont la conformité continue est un effort d’équipe :
Tout cela, c'est-à-dire que tout le monde joue un rôle dans la conformité. Non seulement pour le bien de l’organisation, mais pour que vous puissiez créer et déployer efficacement et en toute confiance, vous ne recevrez pas 10 000 alertes SOS Slack après le lancement de votre application.
Comme nous l'avons dit, votre responsabilité repose principalement sur le niveau de l'application. Cela inclut l'utilisation d'un code source sécurisé, la garantie de configurations appropriées pour votre pipeline CI/CD, et plus encore. Vous vous demandez peut-être : D’accord, mais comment suis-je censé savoir comment faire ? La bonne nouvelle, c’est que vous n’avez pas besoin d’être un expert en sécurité ou en conformité, tout comme vous n’avez pas besoin d’être un neurochirurgien pour mettre un pansement sur une coupure. Il s’agit de connaître et d’appliquer les ressources appropriées (comme un pansement au lieu de coller une serviette sur la plaie).
Pour éviter les erreurs de configuration, vous pouvez consulter le site de documentation de votre fournisseur de services cloud (CSP). Cependant, la lecture de toutes ces informations peut prendre trop de temps. Si tel est le cas pour vous, nous vous suggérons (plutôt fortement recommandé) d'utiliser une solution de sécurité avec automatisation.
La première violation qui peut vous venir à l’esprit est le piratage de Capital One qui a exposé 106 millions de demandes de carte de crédit et a entraîné une amende de 80 millions USD de la part des régulateurs américains. Examinons d'autres violations et comment elles auraient pu être évitées en nous référant aux règles et objectifs PCI DSS.
Début 2021, Hobby Lobby a été piraté. Un chercheur indépendant qui utilise la poignée Boogeyman a identifié la violation. Il a découvert une base de données accessible au public sur Amazon Web Services (AWS) qui contenait des informations sensibles provenant de plus de 300 000 clients Hobby Lobby. La base de données avait une taille de 138GB et comportait les noms, adresses, numéros de téléphone et informations partielles des clients. Le code source de l'application de l'entreprise était étrangement présent dans la même base de données, ce qui constitue un autre problème.
La violation est le résultat d'une base de données cloud mal configurée, accessible au public. Il s'agit d'une violation claire des règles PCI DSS n° 3, n° 7 et n° 9, car les données de carte de paiement étaient stockées sur un serveur ouvert. Hobby Lobby n'a pas non plus respecté la règle n° 10, qui stipule que l'accès aux données des titulaires de carte et aux ressources réseau pertinentes doit être suivi et surveillé. Cela ne se produisait clairement pas, sinon la mauvaise configuration aurait été corrigée et l'ensemble de l'opération aurait finalement été évité.
Le grand détaillant a subi une violation en octobre 2019, qui a exposé les numéros de carte de paiement, les codes de sécurité et les dates d’expiration des clients qui ont utilisé le système de paiement en ligne avec la page Mon compte portefeuille. Bien que Macy’s n’ait pas révélé le nombre de clients touchés, le détaillant a enregistré 55,7 millions de visites mensuelles en ligne jusqu’en avril de cette année-là. Et pour être franc, voler les informations d'un seul client est une préoccupation.
La violation s'est produite en raison d'une attaque Magecart ciblée qui a injecté des malware dans les pages de paiement et de portefeuille. Macy’s a manifestement enfreint une série de règles PCI DSS, et ce qui est plus inquiétant, c’est que Magecart est bien connu. En fait, Macy’s n’était qu’une des nombreuses victimes cette année-là, notamment FILA, Ticketmaster, British Airways et d’autres. Les attaques précédentes contre d’autres grands détaillants auraient dû motiver Macy’s à effectuer des audits de sécurité et à corriger les vulnérabilités, comme l’exige la norme PCI DSS.