Qu'est-ce que la norme PCI DSS ?

Certification PCI DSS

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. 

Exigences 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.

Objectif n° 1 : Construire un réseau sécurisé  

  • Règle n° 1 : Installer et maintenir un pare-feu 
  • Règle n° 2 : N’utilisez pas les mots de passe ou configurations par défaut du fournisseur

Objectif n° 2 : Protéger les données des titulaires de carte  

  • Règle n° 3 : Protéger les données de titulaires de carte stockées 
  • Règle n° 4 : Chiffrer les données de titulaires de carte transmises

Objectif n° 3 : Maintenir un programme de gestion des vulnérabilités  

  • Règle n° 5 : Protection contre les malware

  • Règle n° 6 : Développer et maintenir des systèmes sécurisés 

Objectif n° 4 : Gérer le contrôle d'accès  

  • Règle n° 7 : Restreindre l’accès aux données de titulaires de carte 
  • Règle n° 8 : Identifiez de manière unique toutes les personnes qui ont accès aux données de titulaires de carte 
  • Règle n° 9 : Restreindre l’accès physique aux données de titulaires de carte

Objectif n° 5 : Surveiller et tester les réseaux  

  • Règle n° 10 : Suivez et surveillez tous les accès aux données de titulaires de carte 
  • Règle n° 11 : Tester la sécurité du système

Objectif n° 6 : Maintenir une politique de sécurité des informations

  • Règle n° 12 : Créer et appliquer une politique de sécurité des informations au sein de l’organisation

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 : 

  • Niveau 1 : Plus de 6 millions de transactions/an - Exigence : Audit interne annuel mené par un auditeur PCI autorisé. De plus, ils doivent effectuer une analyse PCI par un fournisseur d'analyse approuvé (ASV) une fois par trimestre. 
  • Niveau 2 : 1 à 6 millions de transactions/an : - Exigence : Effectuez une évaluation annuelle à l’aide d’un questionnaire d’auto-évaluation (SAQ). Une analyse PCI trimestrielle peut être requise. 
  • Niveau 3 : 20 000 à 1 million de transactions/an - Exigence : Auto-évaluation annuelle et éventuellement une analyse PCI trimestrielle. 
  • Niveau 4 : Moins de 20 000 transactions/an - Exigence : Auto-évaluation annuelle et éventuellement une analyse PCI trimestrielle.

Pourquoi la conformité PCI DSS est importante

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 : 

  • Règle n° 6 : Les développeurs doivent créer des systèmes en gardant la sécurité à l’esprit 
  • Règle n° 8 : La gestion des identités et des accès doit attribuer à chaque utilisateur un identifiant unique, requis huit 
  • Règle n° 9 : Le service de sécurité physique doit s'assurer que l'accès au bâtiment et aux salles de serveurs est contrôlé 
  • Règle n° 10 : Les opérations de sécurité doivent s'assurer que des journaux sont créés pour enregistrer et suivre l'accès aux données de titulaires de carte 
  • Règle n° 11 : Les équipes d'exploitation et de développement doivent travailler ensemble pour tester les serveurs et les logiciels 
  • Règle n° 12 : La direction doit élaborer des politiques et des documents associés pour détailler le niveau de sécurité et de conformité des informations qui doit être atteint dans son activité 

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.

Violations liées à la norme PCI DSS

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.

Hobby Lobby

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é.

Macy’s

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.

PCI DSS Compliance

Related Articles