« Norme de sécurité de l'industrie des cartes de paiement » : différence entre les versions

Un article de Wikipédia, l'encyclopédie libre.
Modification suivante →
Contenu supprimé Contenu ajouté
VisuelWikicode
Aliaecca (discuter | contributions)
18 modifications
Créé en traduisant la page « Payment Card Industry Data Security Standard »
Balises : Nowiki dans un article [de contenu]
(Aucune différence)

Version du 26 novembre 2015 à 23:39

Le Payment Card Industry Data Security Standard (PCI DSS) ou Norme de Sécurité des Données des Cartes de Paiement est un standard de sécurité des données pour les principaux groupes de cartes de paiement que sont Visa, MasterCard, American Express, Discover et JCB. Les autres groupes ne font pas partie de cette norme.

Le PCI DSS est établi par les fournisseurs de cartes de paiement et il est géré par le Conseil des normes de sécurité PCI. 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.

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ère un grand nombre de transactions, ou un questionnaire d’auto-évaluation (SAQ) pour les entreprises ayant un plus petit volume de transactions.

Historique

Le PCI DSS était, à l’origine, différent selon le fournisseur, nous avions donc 5 programmes différents :    - Visa’s Cardholder Information Security Program

   - MasterCard’s Site Date Protection

   - American Express’ Data Security Operating Policy

   - Discover’s Information Security and Compliance

   - JCB’s Data Security Program.


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 marchands d’assurer un niveau minimum 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és leur politique respective établissant, de ce fait, 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 mineurs.

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 marchands et les services fournisseurs 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.

Conditions

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

Mises à jour et supplément d’informations

Le Conseil des normes de sécurité PCI 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]

Conformité et validation de conformité

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.[6]

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

Obligations de certification

La conformité avec la norme PCI DSS n’est pas requise par la loi fédérale aux États-Unis. Cependant dans certains Etats la loi se réfère à la norme directement ou émet des propos similaires.

En 2007, l’Etat du Minnesota décrète une loi qui interdit la conservation des informations contenu dans les cartes de paiement.[7]

En 2009, l’Etat du Nevada a promulgué le standard dans la loi, 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é.[8]

En 2010, 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 normes mais les entités conformes seront protégées dans le cas d’une faille dans les données.[9]

Certification et réseau local sans fils

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 recommence 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 sans-fil s’applique dans la norme PCI DSS 1.2. [10]

Ces recommandations s’appliquent au déploiement des réseaux locaux sans fil (WLAN) dans l'environnement du titulaire 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.[11]

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

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

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

Les conditions pour le 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.

  • 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 cryptage 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 minimum de numérisation pour les réseaux locaux sans fil

Ces exigences minimum 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.[12] 
  • 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

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 Centre d'appel posent.[13][14]

Dans un centre d’appel, les clients transmettent leurs informations sur leurs cartes de crédit, les Cryptogramme visuel et les dates d’expirations pour appeler les agents du centre. Il y a quelques contrôles qui empêchent l’utilisation frauduleuse de cette information avec un appareil d’enregistrement ou avec un ordinateur ou encore un bloc-notes. 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ées et ne sont généralement pas sous les normes PCI DSS.[15] Les agents téléphoniques à domicile posent un défi supplémentaire en demandant aux entreprises de sécuriser le canal de l’agent à domicile à travers le hub du centre d’appels pour les applications de détaillants.[16]

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 de centres d’appels, le 18 Mars 2011.[17] Les entreprises ne peuvent plus stocker des enregistrements numériques qui incluent des données sensibles de cartes si ces enregistrements peuvent être demandés.

Les 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.[18] Cela protège les informations sensibles mais peut gêner l'interaction avec le client. Des 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 clavier de 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ées 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ées par l'enregistreur d'appels hébergé du site. 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 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 clavier de téléphone.[19]

Pas plus tard qu'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 crédit pour aider les commerçants, mais vont également au-delà.[20]

Critiques et controverses

Selon Stephen et Theodora « Cissy » Mccomb, propriétaire du Cisero’s Restaurant et de la 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 perte ou de fraude, mais simplement parce que les amendes sont rentables pour eux.[21]

Michael Jones, directeur (CEO) des magasins "Michaels", témoigne devant un comité duCongrès américain au sujet de la norme PCI DSS, « [...] les exigences PCI DSS [...] sont très coûteuses à mettre en œuvre, elles sont source de confusion pour se conformer, et finalement subjective, à la fois dans leurs interprétations et dans leurs applications. On dit souvent qu'il n'y a que douze «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 ».[22]

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 assez pour éradiquer complètement les problèmes de sécurité.

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 expiration dates des clients.

Conformité et compromis

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é PCI DSS, à compromis 100 millions de numéros de cartes bancaires.[23] Au même moment, chez Hannaford Brothers [24] et TJX, également certifié PCI DSS, ont eu des failles similaires, sous l'effet coordonné d'Albert "Segvec" Gonzalez et de deux autres hackers anonymes russes.[25]

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 t. 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 service 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.[26]

Bien que, toutes les entités exposées à une faille et qui ne sont pas en conformité avec la norme PCI DSS au moment de celle-ci, doivent s’acquitter d’une amende, Hannaford Bothers a reçu sa certification PCI DSS un jour après qu'elle ait été mise au courant de la faille dans son système interne.[27] 

Conformité en continue

Le fait d'être conforme à la norme PCI DSS semblent avoir une certaine continuité dans le temps, surtout du point de vue du commerçant. En revanche, 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.[28]

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

Voir aussi

Références

  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. ↑ "PCI Compliance scan".
  7. ↑ "Minnesota Session Laws - CHAPTER 108--H.F.No. 1758". 
  8. ↑ Nevada Revised Statutes, Chap. 603A §215.
  9. ↑ "Wash.
  10. ↑ "Don’t Let Wireless Detour your PCI Compliance" (PDF).
  11. ↑ "Payment Card Industry (PCI) Data Security Standard Glossary, Abbreviations and Acronyms".
  12. ↑ "Walk Around Wireless Security Audits – The End Is Near" (PDF).
  13. ↑ Little, Allan (March 19, 2009).
  14. ↑ Loviglio, Joann (March 2012).
  15. ↑ "PCI Compliance in the Call Center a Headache for Many". searchcrm.com.
  16. ↑ "PCI Compliance: What it Means to the Call Center Industry". tmcnet.com.
  17. ↑ "Call Center FAQ Significantly Changes". 
  18. ↑ "Restructuring the Contact Center for PCI Compliance". tmcnet.com.
  19. ↑ "Our Solution". 
  20. ↑ Adsit, Dennis (February 21, 2011).
  21. ↑ Zetter, Kim (January 11, 2012).
  22. ↑ Jones, Michael (2009-03-31).
  23. ↑ "Heartland data breach sparks security concerns in payment industry". 
  24. ↑ McGlasson, Linda (2008-04-04).
  25. ↑ Goodin, Dan (2009).
  26. ↑ Spier, Peter (2010-03-22).
  27. ↑ Vijayan, Jaikumar (2009-01-04).
  28. ↑ "Q and A: Head of PCI council sees security standard as solid, despite breaches".
  29. ↑ "Best Practice For Implementing PCI DSS In To Your Organisation".

Livres sur PCI DSS

Liens externes

Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Norme_de_sécurité_de_l%27industrie_des_cartes_de_paiement&oldid=120834484 ».