Norme de sécurité de l'industrie des cartes de paiement

La norme de sécurité de l’industrie des cartes de paiement (Payment Card Industry Data Security Standard ou PCI DSS) est un standard de sécurité des données qui s'applique aux différents acteurs de la chaîne monétique.

La norme PCI DSS est établie par les cinq principaux réseaux cartes (Visa, MasterCard, American Express, Discover Card et JCB) et est gérée par le Conseil des normes de sécurité PCI (forum international ouvert pour l'amélioration, la diffusion et la mise en œuvre de normes de sécurité pour la protection des données de comptes). Ce standard a été créé afin d’augmenter le contrôle des informations du titulaire de la carte dans le but de réduire l'utilisation frauduleuse des instruments de paiement.

Historique

[modifier | modifier le code]

Le PCI DSS à l’origine, était différent selon le fournisseur, il y avait 5 programmes différents :

Chaque groupe avait approximativement les mêmes objectifs, c’est-à-dire de créer un niveau supplémentaire de protection pour les émetteurs de cartes qui permettrait aux commerçants d’assurer un niveau maximum de sécurité quand ils stockent, traitent et transmettent les informations du titulaire de la carte. Le conseil des normes de sécurité PCI (PCI SSC) a été créé le 15 décembre 2004. Les groupes précédemment cités ont aligné leur politique respective et ont établi la première version (1.0) du PCI DSS.

En septembre 2006 la version est mise à jour (1.1) intégrant des clarifications et des révisions mineures.

La version 1.2 est paru le 1er octobre 2008, elle ne change pas les prérequis mais améliore la clarté, la flexibilité et distingue les risques ainsi que les menaces. En août 2009, le conseil des normes de sécurité PCI a annoncé le passage à la version 1.2.1 dans le but de réaliser des corrections mineures pour améliorer, encore une fois, la clarté et la cohérence parmi les standards et les documents supports[1]. La version 2.0 est publiée en octobre 2010 mais n’a été promulguée chez les commerçants et les fournisseurs de services qu’à partir du 1er janvier 2011 jusqu’au 31 décembre 2014.

La version 3.0 est paru en novembre 2013 et est active depuis le 1er janvier 2014 jusqu’au 31 décembre 2017.

La version 3.1 a été mise en place en avril 2015.

La version 3.2 a été mise en place en avril 2016.

La version 4 a été mise en place en mars 2022.

Conditions

[modifier | modifier le code]

Le PCI DSS spécifie 12 conditions de conformité, regroupées dans 6 groupes appelés «objectifs de contrôle».

Ces 12 conditions ont été divisées en sous-conditions plus précises mais celles-ci n'ont pas changé depuis la création du standard.

Objectif de contrôle Conditions du PCI DSS
Création et gestion d’un réseau et d’un système sécurisé 1. Installer et gérer une configuration de pare-feu pour protéger les données du titulaire de carte
2. Ne pas utiliser les mots de passe et autres paramètres de sécurité par défaut définis par le fournisseur
Protection des données du titulaire 3. Protéger les données stockées du titulaire
4. Chiffrer la transmission des données du titulaire sur les réseaux publics ouverts
Maintenir un programme de gestion des vulnérabilités 5. Protéger tous les systèmes contre les logiciels malveillants et mettre à jour régulièrement les logiciels anti-virus ou programmes
6. Développer et gérer des systèmes et des applications sécurisés
Mise en œuvre de mesures de contrôle d’accès strictes 7. Restreindre l’accès aux données du titulaire aux seuls individus qui doivent les connaître
8. Identifier et authentifier l’accès aux composants du système
9. Restreindre l’accès physique aux données du titulaire
Surveillance et test réguliers des réseaux 10. Suivre et surveiller tous les accès aux ressources réseau et aux données du titulaire
11. Tester régulièrement les processus et les systèmes de sécurité
Maintenir une politique de sécurité des informations 12. Maintenir une politique qui adresse des informations de sécurité pour l’ensemble du personnel

Chaque année est établi un certificat de conformité par une entité externe que l’on appelle l’évaluateur de sécurité qualifié (QSA), qui va ensuite réaliser un rapport de conformité (ROC) pour les organisations qui gèrent un grand nombre de transactions, ou un questionnaire d’auto-évaluation (SAQ) pour les entreprises ayant un plus petit volume de transactions.

Mises à jour et supplément d’informations

[modifier | modifier le code]

Le Conseil des normes de sécurité PCI (PCI SSC) a publié des informations complémentaires pour clarifier certaines des conditions. Ces informations sont incluses dans les documents suivants :

  • Supplément d'informations : Exigence 11.3 Test de pénétration[2]
  • Supplément d'informations : Exigence 6.6 Revue du code et pare-feu d'application clarifié[3]
  • Navigation dans le PCI DSS : Comprendre l'objectif des exigences[4]
  • Supplément d'informations : Guide de la norme PCI DSS[5]
  • Supplément d’informations : Migration depuis SSL et les premières versions de TLS[6] et son changement de date[7] (PCI DSS 3.2)

Conformité et validation de conformité

[modifier | modifier le code]

La conformité à la norme PCI DSS permet de vérifier que les points de contrôles sont bien mis en œuvre et qu’ils sont efficaces pour la protection des données de cartes bancaires.

Bien que la norme de sécurité des données des cartes de paiement (PCI DSS) devrait être utilisée dans toutes les entreprises qui traitent, stockent et transmettent les informations du titulaire de la carte de paiement, la validation formelle de cette norme n’est pas obligatoire dans toutes les organisations. Actuellement, seuls Visa et MasterCard demandent aux commerçants et fournisseurs de services d’être en conformité avec la norme. Les plus petites entités n’en ont pas l'obligation, mais doivent cependant mettre en œuvre tous les contrôles nécessaires afin d'éviter d'engager leur responsabilité dans le cas où une fraude, associée à un vol des données du titulaire de la carte, aurait lieu.

Les banques émettrices ne sont pas obligées de valider la norme PCI DSS, mais elles doivent cependant sécuriser les données sensibles d’une manière conforme à la norme. Les banques d’acquisitions doivent remplir les conditions de la norme et cette conformité doit être validée par un audit[8].

Dans le cas d’une faille de sécurité, toutes les entités exposées qui ne sont pas en conformité avec la norme PCI DSS au moment de la faille devront s’acquitter d’une amende.

Obligation de certification

[modifier | modifier le code]

Être conforme à la norme PCI DSS n’est pas requis par la loi fédérale aux États-Unis. Cependant dans certains États la loi se réfère à la norme directement ou émet des propos similaires.

En 2007, l’État du Minnesota décrète une loi interdisant la conservation des informations contenues dans les cartes de paiement[9].

En 2009, l’État du Nevada a promulgué la norme, requérant la conformité avec la norme de sécurité pour les commerçants réalisant des affaires dans l’État, elle protège également les entités conformes de toute responsabilité[10].

En 2012, l’État de Washington a également incorporé la norme dans sa propre loi. Cependant, contrairement à la loi présente au Nevada, les entités ne sont pas obligées d’être en conformité avec la norme mais les entités conformes seront protégées dans le cas d’une faille dans les données[11].

Certification et réseau local sans fil

[modifier | modifier le code]

En juillet 2009, le conseil des normes de sécurité PCI a publié un guide [5] pour expliquer le fonctionnement de la norme PCI DSS dans un réseau sans fil. Ce guide recommande l’utilisation du système de prévention des intrusions dans les réseaux sans fil (WIPS) pour automatiser le scan des réseaux sans fil dans les grandes organisations. Le guide définit clairement comment la sécurité du réseau sans-fil s’applique avec la norme PCI DSS 1.2. [12]

Ces recommandations s’appliquent au déploiement des réseaux locaux sans fil (WLAN) dans l'environnement des titulaires de cartes de paiement, aussi connu sous le nom de CDE. Un CDE est défini comme un environnement informatique qui possède ou transmet des données de cartes de crédit[13].

Réseau local sans fil et classification de l'environnement informatique des titulaires de cartes de paiement (CDE)

[modifier | modifier le code]

Le guide concernant la norme PCI DSS dans les réseaux sans fil classe le CDE dans 3 scénarios qui dépendent du déploiement du réseau local sans fil.

  • L’organisation n’a pas encore déployé de réseau local sans fil, dans ce cas, 3 conditions de la norme PCI DSS sont requises (sections 11.1, 11.4 et 12.9).
  • L’organisation a déployé le réseau local sans fil en dehors du domaine des données du titulaire. Ces réseaux sont segmentés par un pare-feu. S’il n’y a pas de réseaux sans fil connu dans le CDE, alors 3 conditions de la norme PCI DSS sont requises (sections 11.1, 11.4 et 12.9).
  • L’organisation a déployé un réseau local dans le CDE. Dans ce cas 3 conditions sont requises (Conditions 11.1, 11.4 et 12.9) ainsi que 6 conditions de sécurité du déploiement (conditions 2.1.1, 4.1.1, 9.1.3, 10.5.4, 1.6 et 12.3) de l’application de la norme PCI DSS.

Conditions d’un déploiement sécurisé pour un réseau local sans fil

[modifier | modifier le code]

Les conditions pour un déploiement sécurisé ne s’appliquent qu’aux organisations qui ont un réseau local sans fil connu dans le CDE. Le but de ces conditions est de déployer un réseau avec ses propres protections.

Les conditions clefs de la norme version 1.2 qui sont en rapport avec la sécurité des réseaux sans fil sont classées ci-dessous :

  • Section 2.1.1 Changement des paramètres par défaut : changer les mots de passe par défaut et le SSID sur les appareils sans fil. Activer la sécurité WPA ou WPA2.
  • Section 4.1.1 Sécurité : S’assurer que les réseaux sans-fil sur lesquels sont transmises les données du titulaire ou les données qui sont connectés au CDE, mettent en œuvre les meilleures pratiques du secteur (par exemple, IEEE 802.11i) pour appliquer un chiffrement robuste pour l’authentification et la transmission. L’utilisation du protocole WEP n’est plus autorisée comme contrôle de sécurité depuis le 30 juin 2010.
  • Section 9.1.3 Sécurité physique : Restreindre l’accès physique aux appareils sans fil.
  • Section 10.5.4 Journaux : Les registres des technologies orientées vers l'extérieur sont écrits sur un serveur de journal interne centralisé et sécurisé ou sur un dispositif de support.
  • Section 10.6 Examen des journaux : Examiner les journaux et évènements de sécurité des composants pour repérer des anomalies ou des activités suspectes.
  • Section 12.3 Politiques d’usage : Développer les politiques d’utilisation des technologies critiques et définir l’utilisation adéquate de ces technologies

Exigences minimales de numérisation pour les réseaux locaux sans fil

[modifier | modifier le code]

Ces exigences minimales de numérisation s’appliquent à toutes les organisations indépendamment du type de réseau local sans fil dans le CDE. Le but de ces exigences est d’éliminer tous les éléments indésirables ou non autorisés dans le CDE.

  • Section 11.1 Vérification trimestrielle : Tester la présence des points d’accès sans fil, détecter et identifier les points d’accès autorisés et non autorisés trimestriellement[14]. 
  • Section 11.4 Alertes de sécurité : Mettre en place des systèmes de prévention instantanée pour prévenir les utilisateurs d’une présence d’appareils indésirables ou de connexions sans fils non autorisées dans le CDE.
  • Section 12.9 Elimination des menaces : Préparer un plan de réponse en cas d’incident pour gérer et répondre aux alertes des systèmes de prévention. Mettre en place un mécanisme de confinement automatique sur les alertes pour bloquer les indésirables et autres connexions sans fil non autorisées.

La conformité PCI dans les centres d’appels

[modifier | modifier le code]

Bien que les normes PCI DSS soient très explicites sur les exigences de stockage et d’accès des données personnelles, le Conseil des normes de sécurité PCI dit très peu de choses sur la collecte de ces informations, que ce soit à travers les sites Web, les systèmes de serveur vocal interactif ou des agents de centres d’appels. Cela est surprenant, étant donné le potentiel de menace élevée pour la fraude des cartes de crédit et de la mise en danger des données que les Centres d'appels posent[15],[16].

Le défi des centres d'appels

[modifier | modifier le code]

Dans un centre d’appel, les clients transmettent leurs informations sur leurs cartes de crédit (Cryptogrammes visuel, numéro de carte, date d’expiration). Ces informations sont réceptionnées avec un appareil d’enregistrement, un ordinateur ou encore un bloc-note. Il y a quelques contrôles qui empêchent l’utilisation frauduleuse de ces informations.

De plus, presque tous les centres d’appels déploient une sorte de "logiciel d’enregistrement d’appels" qui capture et stocke toutes les données sensibles du consommateur. Ces enregistrements sont accessibles par une grande partie du personnel des centres d’appels, ne sont pas chiffrés et ne sont généralement pas sous les normes PCI DSS[17]. Les agents téléphoniques à domicile posent donc un défi supplémentaire. Cela demande aux entreprises de sécuriser le canal de l’agent à domicile à travers le hub du centre d’appels[18].

Sécurité dans les centres d'appels

[modifier | modifier le code]

Pour répondre à certaines de ces préoccupations, le Conseil des normes de sécurité PCI a émis une version mise à jour de FAQ à propos des enregistrements des centres d’appels, le 18 mars 2011[19]. Désormais, les entreprises ne peuvent plus stocker des enregistrements numériques qui incluent des données sensibles de cartes si ces mêmes enregistrements peuvent être demandés.

Des solutions techniques peuvent également prévenir l'utilisation frauduleuse des instruments de paiement par les agents. Au moment de la transaction, où l'agent a besoin de recueillir les informations relatives à la carte de crédit, l'appel peut être transféré à un serveur vocal interactif[20]. Cela protège les informations sensibles mais peut gêner l'interaction avec le client.

D'autres solutions peuvent être envisagées telles que l'automatisation assistée par un agent qui permet de récupérer les informations relatives à la carte de crédit tout en évitant la gêne précédemment évoquée. L'agent garde son rôle de correspondant téléphonique et les clients entrent directement, avec leur téléphone, les informations de leur carte de crédit dans le logiciel de gestion de la relation client. Les codes DTMF sont ainsi supprimés intégralement ou bien juste converties en monotones, l'agent ne peut donc pas les reconnaître et ne pas les enregistrer.

Certaines plates-formes de paiement sécurisé permettent de masquer ces codes DTMF, mais celles-ci sont toujours enregistrés par l'enregistreur d'appels. Traditionnellement, l'unique façon de supprimer les codes DTMF est d'intercepter l'appel au niveau du tronc en utilisant des serveurs sophistiqués. Cette pratique permet de supprimer ou de masquer les codes DTMF auprès de l'enregistreur téléphonique ainsi qu'auprès de l'agent.

L'entreprise anglo-américaine Semafone a mis au point un brevet concernant une méthode de paiement liée à l'utilisation des codes DTMF qui capture, en direct d'un appel téléphonique, les données de la carte de paiement d'un client depuis le centre de contact pour les transmettre au système de paiement. Les agents du centre de contact maintiennent la communication vocale pendant le processus de paiement, y compris pendant que le client entre les détails de sa carte par le biais de son téléphone[21].

En juin 2014, nous avons pu voir l'introduction de nouvelles solutions de paiement téléphonique sur ce marché avec le déploiement de techniques telles que l'acheminement des appels vers les plates-formes avant même leur traitement en centre d'appel. Ceci est fait de sorte que le serveur puisse intercepter l'appel et contrôler les codes DTMF afin de sécuriser leur masquage. Au sein du réseau, aucun matériel ou logiciel n'a besoin d'être mis en place par l'organisation elle-même, bien que cela reste un problème de logistique et d'intégration allant à l'encontre des fournisseurs.

Les avantages de l'augmentation de la sécurité autour de la collecte de données personnelles sont d'éviter la fraude de carte de paiement pour aider les commerçants, mais vont également au-delà[22].

Critiques et controverses

[modifier | modifier le code]

Selon Stephen et Theodora « Cissy » Mccomb, propriétaires du Cisero’s Restaurant et d'une discothèque dans le centre de Park City (Utah) « le système PCI est moins un système de sécurisation des données des cartes des clients, qu'un système pour générer des bénéfices pour les sociétés de cartes, via les amendes et les pénalités. Visa et MasterCard imposent des amendes aux commerçants sans qu'il y ait de fraude, mais simplement parce que les amendes sont rentables pour eux » [23].

Michael Jones, directeur des magasins "Michaels", témoigne devant un comité du Congrès des États-Unis au sujet de la norme PCI DSS, « [...] les exigences PCI DSS [...] sont très coûteuses à mettre en œuvre, elles sont sources de confusion pour s'y conformer et finalement subjectives, à la fois dans leur interprétation et dans leur application. On dit souvent qu'il n'y a que 12 « exigences » pour la conformité PCI, en fait, il y a plus de 220 sous-exigences ; dont certaines peuvent être un poids pour un commerçant et un grand nombre de ces sous-exigences sont sujettes à interprétation »[24].

En revanche, d’autres ont suggéré que la norme PCI DSS est une étape vers la prise de conscience que les entreprises sont prêtes à accorder plus d’attention à la sécurité, même si les normes minimales ne sont pas suffisantes pour éradiquer complètement les problèmes de sécurité.

Conformité et compromissions

[modifier | modifier le code]

Selon le directeur de la gestion des risques de Visa, Ellen Richey, « … aucune des entités compromises n'étaient en conformité avec la norme de sécurité PCI DSS au moment de la faille ». En 2008, une brèche dans le système de paiement d'Heartland, une organisation certifiée PCI DSS, a compromis 100 millions de numéros de cartes bancaires[25]. Au même moment, Hannaford Brothers [26] et TJX, également certifiés PCI DSS, ont eu des failles similaires, sous l'effet coordonné d'Albert "Segvec" Gonzalez et de deux autres hackers anonymes russes[27].

Les évaluations ont pour but de vérifier la certification avec la norme de sécurité PCI DSS chez les commerçants et fournisseurs de services, à un instant donné. Ils utilisent fréquemment une méthodologie d'échantillonnage pour démontrer la conformité à travers des processus et systèmes représentatifs. C'est la responsabilité des commerçants et des fournisseurs de services de réaliser, démontrer et de maintenir leur conformité à tout moment par le biais de la validation annuelle ou du cycle d'évaluation de la globalité de leur système[28].

Bien que toutes les entités exposées à une faille et non conformes à la norme PCI DSS au moment où celles-ci doivent s’acquitter d’une amende, Hannaford Bothers a reçu sa certification PCI DSS un jour après qu'elle a été mise au courant de la faille dans son système interne[29].

Autre exemple avec la chaîne d'hôtel Starwood qui a annoncé le 20 novembre 2015, que 54 de ses hôtels avaient été touchés par des logiciels malveillants conçus pour recueillir les données de carte de crédit tels que des noms, des numéros, des codes de sécurité et les dates d'expiration des cartes des clients. 

Conformité en continu

[modifier | modifier le code]

Être conforme à la norme PCI DSS doit être un effort continu dans le temps, surtout du point de vue du commerçant. Le directeur général du Conseil des normes de sécurité PCI, Bob Russo, a indiqué que les responsabilités pourraient changer en fonction de l'état de l’organisation au moment où une faille se produit[30].

Pour la conformité PCI DSS, il est préférable d’améliorer continuellement les processus afin d'assurer le respect permanent du standard, plutôt que de traiter la conformité à un moment t du projet[31].

Articles connexes

[modifier | modifier le code]

Références

[modifier | modifier le code]
  1. ↑ "PCI SECURITY STANDARDS COUNCIL RELEASES VERSION 2.0 OF THE PCI DATA SECURITY STANDARD AND PAYMENT APPLICATION DATA SECURITY STANDARD" (PDF).
  2. ↑ "Information Supplement: Requirement 11.3 Penetration Testing" (PDF).
  3. ↑ "Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified" (PDF).
  4. ↑ "Navigating the PCI DSS - Understanding the Intent of the Requirements" (PDF).
  5. ↑ a et b "PCI DSS Wireless Guidelines" (PDF).
  6. ↑ (en) « INFORMATION SUPPLEMENT Migrating from SSL and Early TLS », sur pcisecuritystandards.org (consulté le )
  7. ↑ (en) « Date Change for Migrating from SSL and Early TLS », sur blog.pcisecuritystandards.org, (consulté le )
  8. ↑ "PCI Compliance scan".
  9. ↑ "Minnesota Session Laws - CHAPTER 108--H.F.No. 1758".
  10. ↑ Nevada Revised Statutes, Chap. 603A §215.
  11. ↑ "Wash.
  12. ↑ "Don’t Let Wireless Detour your PCI Compliance" (PDF).
  13. ↑ "Payment Card Industry (PCI) Data Security Standard Glossary, Abbreviations and Acronyms".
  14. ↑ "Walk Around Wireless Security Audits – The End Is Near" (PDF).
  15. ↑ Little, Allan (March 19, 2009).
  16. ↑ Loviglio, Joann (March 2012).
  17. ↑ "PCI Compliance in the Call Center a Headache for Many". searchcrm.com.
  18. ↑ "PCI Compliance: What it Means to the Call Center Industry". tmcnet.com.
  19. ↑ "Call Center FAQ Significantly Changes".
  20. ↑ "Restructuring the Contact Center for PCI Compliance". tmcnet.com.
  21. ↑ "Our Solution".
  22. ↑ Adsit, Dennis (February 21, 2011).
  23. ↑ Zetter, Kim (January 11, 2012).
  24. ↑ Jones, Michael (2009-03-31).
  25. ↑ "Heartland data breach sparks security concerns in payment industry".
  26. ↑ McGlasson, Linda (2008-04-04).
  27. ↑ Goodin, Dan (2009).
  28. ↑ Spier, Peter (2010-03-22).
  29. ↑ Vijayan, Jaikumar (2009-01-04).
  30. ↑ "Q and A: Head of PCI council sees security standard as solid, despite breaches".
  31. ↑ "Best Practice For Implementing PCI DSS In To Your Organisation".

Liens externes

[modifier | modifier le code]

Bibliographie

[modifier | modifier le code]