Passer au contenu
Français
Portail client
Contact
  • Il n'y a aucune suggestion car le champ de recherche est vide.

PCI DSS – Guide de conformité et de validation

1.  Comprendre la norme de sécurité des données de l’industrie des cartes de paiement

1.1. Qu’est-ce que la norme PCI DSS ?

La norme de sécurité des données de l’industrie des cartes de paiement (PCI DSS – Payment Card Industry Data Security Standard) est un ensemble de critères qui a été développé par le Conseil des normes de sécurité PCI (PCI SSC – PCI Security Standards Council), organisme indépendant fondé en septembre 2006 par cinq grands réseaux de paiement par carte : American Express, Discover, JCB International, Mastercard et Visa Inc. Le PCI SSC est chargé de l’élaboration et de l’évolution constante des normes de sécurité pour la protection des données de compte.

Cet ensemble de critères à respecter est imposé par l’industrie et s’applique à toute entreprise qui gère, traite ou stocke des données de carte, indépendamment de sa localisation ou de sa taille. Il a été créé pour déceler les vulnérabilités dans les processus de sécurité, les procédures et les configurations de sites Web.

Être en conformité avec la norme PCI DSS aide toutes les parties prenantes à se protéger contre les brèches portant atteinte à la sécurité des données, tout en renforçant la confiance des consommateurs et en préservant l’intégrité générale du système de paiement.

Tous les serveurs hébergeant des sites Web marchands qui acceptent les cartes Mastercard et/ou Visa doivent se conformer à la norme PCI DSS, même si les serveurs Web ne stockent pas, ne traitent pas et ne transmettent pas les données des titulaires de carte (vu qu’ils déterminent comment ces données sont traitées et peuvent par conséquent compromettre la sécurité des transactions).

 

2.  Niveaux et conditions de validation

2.1. Conformité ou validation

La conformité et la validation sont deux processus distincts.

 

Conformité :     

  • La conformité à la norme PCI DSS est requise pour toute entreprise qui gère, traite ou stocke des données de paiement, indépendamment de sa localisation ou de sa taille.

         Ces entreprises doivent être en conformité en tout temps.

  • Il s’agit d’un exercice continu, non ponctuel.

 

Validation :       

  • Visa et Mastercard exigent des marchands qu’ils apportent la preuve de leur statut de conformité en fonction du niveau auquel ils appartiennent.

 

Chaque marchand appartient en effet à l’un des quatre niveaux soumis à des conditions de validation qui sont définis par Visa et Mastercard selon les volumes de transactions sur 12 mois, le risque potentiel et le degré d’exposition.

Le volume de transactions est fonction du nombre total de transactions Visa ou Mastercard traitées par une personne morale pour l’ensemble de ses marchands faisant affaire sous une raison sociale (DBA – « doing business as »). Si la personne morale ne stocke pas, ne traite pas et ne transmet pas les données des titulaires de carte pour le compte de multiples marchands faisant affaire sous une raison sociale, le volume de transactions individuel de ces derniers détermine le niveau de validation.

 

2.2. Conditions de validation

Les marchands peuvent valider leur conformité à la norme PCI DSS de deux façons :

  • en obtenant un rapport de conformité (ROC – Report on Compliance) délivré par un évaluateur de sécurité interne (ISA – Internal Security Assessor) agréé par le PCI SSC ou par un évaluateur de sécurité qualifié (QSA – Qualified Security Assessor)

– obligatoire pour les marchands de niveau 1 et facultatif pour ceux de niveau 2 ; 

OU

  • en remplissant un questionnaire d’auto-évaluation (SAQ – Self-Assessment Questionnaire)

– pour les marchands qui sont admissibles (le type de formulaire SAQ dépend du type d’intégration choisi) ;

ET

  • en effectuant une analyse de vulnérabilité de leur réseau par l’intermédiaire d’un prestataire de services d’analyse agréé (ASV – Approved Scanning Vendor) par le PCI SSC

– obligatoire pour les niveaux 1 à 3, recommandé pour le niveau 4.

 

Pour s’aligner sur les directives du réseau de paiement par carte, HiPay exige des marchands qu’ils valident leur conformité à la norme PCI DSS :

  • au moment de leur intégration administrative dans le cadre du processus de souscription ;
  • pour les lancements de nouveaux projets, notamment les changements d’intégration, la personnalisation des pages de paiement, l’ajout des méthodes de paiement Visa et/ou Mastercard;
  • chaque année par la suite.

 

Le tableau suivant[1] indique le volume de transactions et les conditions applicables à chaque niveau dans le cadre de la validation annuelle de la conformité à la norme PCI DSS.

NIVEAU
DESCRIPTION (VISA OU MASTERCARD)
PAGE DE REDIRECTION (HÉBERGÉE) IFRAME CHAMPS HÉBERGÉS (HOSTED FIELDS)
DIRECT POST
API ONLY
CONDITIONS DE VALIDATION DE LA CONFORMITÉ À LA NORME PCI DSS
1
Plus de 6 millions Tout marchand qui, à l’entière discrétion de Visa ou Mastercard, doit se conformer aux exigences applicables aux marchands de niveau 1. Tout marchand ayant subi une violation des données causant une compromission des données de compte peut passer à un niveau supérieur.
Rapport de conformité (ROC)
Rapport de conformité (ROC)
Rapport de conformité (ROC)
Évaluation annuelle sur place par un évaluateur de sécurité qualifié (QSA – Qualified Security Assessor) ou un membre du personnel accrédité par le PCI SSC (accréditation annuelle) Analyse de vulnérabilité effectuée chaque trimestre par un prestataire de services d’analyse agréé (ASV – Approved Scanning Vendor)
2
1 – 6 millions
SAQ A
SAQ A-EP
SAQ D
Questionnaire d’auto-évaluation annuelle (SAQ – Self-Assessment Questionnaire). ou évaluation annuelle sur place à la discrétion du marchand Formulaire d’attestation de conformité (AOC – Attestation of Compliance) Analyse de vulnérabilité effectuée chaque trimestre par un prestataire de services d’analyse agréé (ASV – Approved Scanning Vendor)
3
20 000 – 1 million
SAQ A
SAQ A-EP
SAQ D
Questionnaire d’auto-évaluation annuelle (SAQ – Self-Assessment Questionnaire) Formulaire d’attestation de conformité (AOC – Attestation of Compliance) Analyse de vulnérabilité effectuée chaque trimestre par un prestataire de services d’analyse agréé (ASV – Approved Scanning Vendor)
4
Moins de 20 000
SAQ A
SAQ A-EP
SAQ D
Recommandé : questionnaire d’auto-évaluation annuelle (SAQ – Self-Assessment Questionnaire) Recommandé : analyse de vulnérabilité effectuée chaque trimestre par un prestataire de services d’analyse agréé (ASV – Approved Scanning Vendor)

[1] Sources : Visa et Mastercard

 

3.  Questionnaires d’auto-évaluation (SAQ)

3.1. Quel formulaire SAQ dois-je remplir ?

Le questionnaire d’auto-évaluation (SAQ – Self-Assessment Questionnaire) est un document servant à valider la conformité à la norme PCI DSS pour les marchands et les prestataires de services de paiement (PSP) qui ne sont pas obligés d’effectuer des évaluations sur place afin de se mettre en conformité avec la norme PCI DSS.

Les renseignements qui suivent vous aideront à déterminer quel formulaire SAQ s’applique à la méthode de traitement que vous avez mise en place.

 

3.2. HiPay, votre prestataire de services conforme à la norme PCI DSS

HiPay figure parmi les fournisseurs de services tiers en conformité avec la norme PCI DSS répertoriés par Visa et Mastercard.

Si l’externalisation peut simplifier le cadre de mise en conformité à la norme PCI DSS pour les marchands, cela n’élimine pas le risque ni leur responsabilité d’assurer des mesures de sécurité élémentaires.

Quel que soit le degré d’externalisation avec un fournisseur de services tiers, le marchand reste responsable de s’assurer de la protection des données de carte de paiement. Les connexions et les redirections entre le marchand et le prestataire de services de paiement (PSP) tiers peuvent en effet faire l’objet d’une compromission donnant lieu à un accès non autorisé au site du marchand. Les hackers changent alors le chemin d’accès relatif au paiement entre le marchand et le PSP, qui pensent être en communication directe. C’est pourquoi les marchands doivent surveiller leurs systèmes afin de déceler tout changement inattendu et de s’assurer du maintien de l’intégrité des connexions et des redirections en tout temps. 

Les conditions de validation de la conformité à la norme PCI DSS qui vous incombent en tant que marchand dépendent de la méthode que vous avez choisie pour intégrer HiPay comme PSP.

HiPay propose les méthodes d’intégration suivantes :

 

3.3. SAQ A

  • Le marchand ne stocke pas, ne traite pas et ne transmet pas les données des titulaires de carte électroniquement.
  • Toutes les fonctions de traitement des paiements sont entièrement externalisées, hébergées et gérées par HiPay.

OU

  • Le site Web du marchand fournit une iFrame ou URL qui redirige les clients vers une page HiPay, qui ne contient aucun élément provenant du site Web du marchand.

 

3.4. SAQ A-EP

  • Le site Web du marchand ne stocke pas, ne traite pas et ne transmet pas les données des titulaires de carte, mais contrôle comment les données sont collectées.
  • Le site Web du marchand fournit une iFrame ou URL qui redirige les clients vers HiPay, MAIS certains éléments de la page de paiement proviennent du site Web du marchand (JavaScript, feuilles de style CSS ou toute fonctionnalité permettant la création de la page de paiement).

OU

  • Le site Web du marchand génère un formulaire de paiement et utilise une intégration Direct Post pour envoyer les données à HiPay.

 

3.5. SAQ D

  • Le site Web du marchand stocke, traite ou transmet les données des titulaires de carte.
  • Toutes les conditions de validation de la conformité à la norme PCI DSS s’appliquent.

 


4.  Que faire en cas de compromission de données ?

Les entités doivent analyser les cas présumés ou avérés de perte, vol, compromission ou fraude concernant les données des comptes ou des titulaires de carte.

Toute entité ayant subi une brèche de sécurité présumée ou avérée doit agir rapidement afin d’aider à empêcher des risques d’exposition supplémentaires des données des titulaires de carte et d’assurer la conformité à la norme PCI DSS.

Pour ce faire :

  1. Immédiatement contenir et limiter l’exposition des données afin de minimiser leur perte. Empêcher toute perte de données supplémentaire en cessant de traiter les transactions par carte et en redirigeant les paiements vers un canal reconnu comme étant sûr.
  2. Signaler immédiatement toute brèche de sécurité présumée ou avérée directement à son chargé de compte HiPay attitré.
  3. Les réseaux de paiement peuvent exiger des marchands qu’ils engagent un enquêteur judiciaire PCI (PFI – PCI Forensic Investigator) accrédité afin d’effectuer une enquête judiciaire approfondie sur la brèche de sécurité présumée ou avérée. Il est crucial que l’environnement ou le canal de paiement compromis reste intact afin de conserver les preuves et de faciliter l’enquête.

 

Veuillez suivre les directives suivantes :

  • Ne pas accéder au(x) système(s) compromis ni le(s) modifier (c.-à-d. ne pas se connecter du tout au(x) système(s) compromis ni changer le(s) mot(s) de passe ; ne pas se connecter en tant qu’administrateur (root)).
  • Ne pas éteindre le(s) système(s) compromis. Isoler plutôt le(s) système(s) compromis du réseau (par exemple en débranchant le câble de réseau).
  • Conserver les fichiers journaux (« logs») (par exemple : journal des évènements de sécurité, Web, base de données, pare-feu, etc.). Consigner toutes les mesures prises.
  • Si un réseau sans fil est utilisé, changer son nom (Service Set Identifier – SSID) sur le point d’accès sans fil (Wireless Access Point – WAP) et les autres systèmes susceptibles d’utiliser cette connexion (à l’exception des systèmes que l’on soupçonne d’être compromis).
  • Rester sur ses gardes et surveiller avec vigilance les flux sur tous les systèmes traitant les données des titulaires de carte.

 

Veuillez vous référer à ce document pour de plus amples renseignements sur quoi faire en cas de compromission.

 

 

5.  Violations de données en fonction du type d’intégration[2]

5.1. Intégration avec redirection/en mode hébergé

Le PSP crée le formulaire de paiement et l’envoie à l’appareil du client. Le PSP reçoit les données de carte envoyées directement au système de paiement pour autorisation. Le marchand ne reçoit pas les données de carte.

Lorsque les pirates attaquent les intégrations en mode hébergé
Comment font-ils ?
En utilisant la technique d’attaque de l’intercepteur/homme du milieu (« man-in-the-middle attack » – MITM), les cybercriminels piratent la sécurité du site Web du marchand et changent le programme qui envoie les instructions de redirection à l’appareil du client, lui indiquant de demander le formulaire de paiement au site du cybercriminel au lieu de celui du PSP. Les données de carte fournies par le client sont envoyées au cybercriminel et non au PSP. Parfois, le site Web du pirate recueille les données de carte et les envoie au PSP ; parfois, il intercepte les données de carte, indique au client qu’il y a eu un problème et envoie à l’appareil du client l’instruction d’obtenir le « vrai » formulaire de paiement venant du PSP.
Que voit le titulaire de la carte ?
Le formulaire de paiement du cybercriminel, conçu pour être identique à celui du PSP, peut demander d’autres informations telles que le NIP du titulaire de la carte. En fonction du type d’attaque, il se peut que le titulaire de la carte soit sollicité de saisir ses données de carte deux fois.
Que voit le marchand ?
Il se peut que le marchand constate une baisse de ses ventes causée par une hausse des transactions abandonnées lorsque les clients ne se sont pas laissé tromper par le formulaire de paiement du cybercriminel ou ne veulent pas saisir leurs données de carte deux fois.
Comment le marchand peut-il détecter cette attaque ?
Les marchands du e-commerce doivent veiller à ce que leur site Web soit régulièrement vérifié en cas de pages ou fichiers nouvellement ajoutés ou inconnus. En particulier, ils doivent régulièrement vérifier que le code redirigeant les clients vers la page de paiement hébergée chez un fournisseur tiers est le même que celui fourni par ce dernier et qu’il n’a pas été changé.   • Si le code redirigeant vers la page de paiement hébergée est intégré dans le panier d’achat sur le site du marchand, les marchands du e-commerce doivent veiller à ce que l’application du panier d’achat soit mise à jour avec les tout derniers correctifs. • Les marchands du e-commerce doivent vérifier les questions de sécurité avec leur hébergeur Web afin de s’assurer que leurs systèmes sont convenablement sécurisés. Les serveurs Web et de base de données doivent être renforcés pour désactiver les paramètres par défaut et les services inutiles. Il existe de nombreuses normes internationales de renforcement des systèmes informatiques, comme celles mises à disposition par le Center for Internet Security : les marchands doivent inciter leur hébergeur Web à adopter ces normes.   • Les marchands du e-commerce qui utilisent des hébergeurs Web ou des fournisseurs de services de paiement tiers qui stockent, traitent ou transmettent les données des titulaires de carte doivent continuellement maintenir leur conformité à la norme de sécurité des données de l’industrie des cartes de paiement (PCI DSS). Les marchands du e-commerce doivent veiller à ce que tout contrat avec des entités stockant, traitant ou transmettant pour leur compte les données des titulaires de carte fasse état du langage pour la sécurité des données. Ce type de contrat doit clairement établir les rôles et les responsabilités concernant la protection des données des titulaires de carte.
Niveau de risque
Bas – Cette méthode de traitement des paiements pour l’e-commerce représente le niveau de risque le plus bas pour les marchands.

Pour de plus amples informations, veuillez consulter la documentation technique HiPay sur notre portail pour développeurs.

 

5.2. Intégration en iFrame

Les intégrations en iFrame permettent aux titulaires de carte de saisir leurs données de carte sur une page de paiement sécurisée hébergée par le PSP et affichée dans une iFrame sur la page de paiement des marchands.

Lorsque les cybercriminels attaquent les intégrations en iFrame
Comment font-ils ?
En utilisant la technique d’attaque de l’intercepteur/homme du milieu (« man-in-the-middle attack » – MITM), les attaques contre les intégrations en iFrame sont très semblables à celles contre les intégrations en mode hébergé. Les cybercriminels piratent la sécurité du site Web du marchand et changent le programme qui crée la page mère envoyée à l’appareil du client. Au lieu d’indiquer à l’appareil du client de demander une sous-page contenant un formulaire de paiement venant du PSP, l’instruction envoyée est de demander un formulaire de paiement venant du site Web du cybercriminel. Lorsque le client saisit ses données de carte, celles-ci sont ainsi envoyées au site Web du pirate informatique et non à celui du PSP. Parfois, le site Web du pirate recueille les données de carte et les envoie au PSP ; parfois, il intercepte les données de carte, indique au client qu’il y a eu un problème et envoie à l’appareil du client l’instruction d’obtenir le « vrai » formulaire de paiement venant du PSP.
Que voit le titulaire de la carte ?
Le formulaire de paiement du cybercriminel, conçu pour être identique à celui du PSP, peut demander d’autres informations telles que le NIP du titulaire de la carte. En fonction du type d’attaque, il se peut que le titulaire de la carte soit sollicité de saisir ses données de carte deux fois.
Que voit le marchand ?
Il se peut que le marchand constate une baisse de ses ventes causée par une hausse des transactions abandonnées lorsque les clients ne se sont pas laissé tromper par le formulaire de paiement du cybercriminel ou ne veulent pas saisir leurs données de carte deux fois.
Comment le marchand peut-il détecter cette attaque ?
Les marchands du e-commerce doivent veiller à ce que leur site Web soit régulièrement vérifié en cas de pages ou fichiers nouvellement ajoutés ou inconnus. En particulier, ils doivent régulièrement vérifier que le code redirigeant les clients vers la page de paiement hébergée chez un fournisseur tiers est le même que celui fourni par ce dernier et qu’il n’a pas été changé.   • Si le code redirigeant vers la page de paiement hébergée est intégré dans le panier d’achat sur le site du marchand, les marchands du e-commerce doivent veiller à ce que l’application du panier d’achat soit mise à jour avec les tout derniers correctifs. • Les marchands du e-commerce doivent vérifier les questions de sécurité avec leur hébergeur Web afin de s’assurer que leurs systèmes sont convenablement sécurisés. Les serveurs Web et de base de données doivent être renforcés pour désactiver les paramètres par défaut et les services inutiles. Il existe de nombreuses normes internationales de renforcement des systèmes informatiques, comme celles mises à disposition par le Center for Internet Security : les marchands doivent inciter leur hébergeur Web à adopter ces normes.   • Les marchands du e-commerce qui utilisent des hébergeurs Web ou des fournisseurs de services de paiement tiers qui stockent, traitent ou transmettent les données des titulaires de carte doivent continuellement maintenir leur conformité à la norme de sécurité des données de l’industrie des cartes de paiement (PCI DSS). Les marchands du e-commerce doivent veiller à ce que tout contrat avec des entités stockant, traitant ou transmettant pour leur compte les données des titulaires de carte fasse état du langage pour la sécurité des données. Ce type de contrat doit clairement établir les rôles et les responsabilités concernant la protection des données des titulaires de carte.
Niveau de risque
Bas – Cette méthode de traitement des paiements pour l’e-commerce représente un niveau de risque bas, bien qu’elle soit plus fréquemment attaquée par les cybercriminels que les intégrations en mode hébergé. Les marchands doivent se renseigner auprès de leur PSP sur les mesures techniques à leur disposition pour sécuriser au mieux une iFrame.

Pour de plus amples informations, veuillez consulter la documentation technique HiPay sur notre portail pour développeurs.

 

5.3. Intégration en Direct Post

Avec JavaScript, les intégrations en Direct Post permettent aux marchands de créer leur propre formulaire de paiement, hébergé sur leur serveur. Une fois le formulaire validé par les clients, les données de carte sont envoyées au PSP, qui renvoie un jeton (« token »). Les marchands peuvent alors traiter les paiements avec ce jeton sur leur serveur. De cette façon, les données de paiement (ex. : numéro de carte, code de vérification de carte…) n’arrivent jamais sur le serveur des marchands puisqu’elles restent dans le navigateur et sont envoyées directement dans l’espace de stockage sécurisé du PSP.

Lorsque les cybercriminels attaquent les intégrations en Direct Post
Comment font-ils ?
Les cybercriminels piratent la sécurité du site Web du marchand et changent le programme qui crée le formulaire de paiement. Les pirates informatiques ajoutent du script afin que les données de carte saisies par les clients leur soient automatiquement envoyées en même temps qu’au PSP.
Que voit le titulaire de la carte ?
Le formulaire de paiement original. Le titulaire de la carte ne remarque pas le script exécuté en arrière-plan, qui envoie les données de carte au cybercriminel.
Que voit le marchand ?
Le marchand ne voit aucun effet de cette attaque sur ses activités quotidiennes.
Comment le marchand peut-il détecter cette attaque ?
Cette attaque étant très difficile à détecter par le marchand, celui-ci doit mettre en place les moyens de contrôle appropriés à la norme PCI DSS, décrits dans le formulaire SAQ A-EP afin d’aider à déceler et à éviter cette attaque.
Niveau de risque
Modéré – Cette méthode de traitement des paiements pour l’e-commerce représente un niveau de risque plus élevé que le mode hébergé ou iFrame.

Pour de plus amples informations, veuillez consulter la documentation technique HiPay sur notre portail pour développeurs.

 

5.4. Intégration en JavaScript

Lorsque les cybercriminels attaquent les intégrations en JavaScript
Comment font-ils ?
Les cybercriminels piratent la sécurité du site Web du marchand et changent le programme qui crée le formulaire de paiement envoyé à l’appareil du client. Ils modifient la page pour que l’appareil du client fasse une requête JavaScript au site Web du pirate en plus de la requête JavaScript faite au PSP afin que lorsque le client saisit ses données de carte, elles soient automatiquement envoyées aux cybercriminels en même temps qu’au PSP.
Que voit le titulaire de la carte ?
Le formulaire de paiement. Le titulaire de la carte ne remarque pas le script additionnel exécuté en arrière-plan du formulaire de paiement sur son ordinateur, qui envoie les données de carte au cybercriminel.
Que voit le marchand ?
Le marchand ne voit aucun effet de cette attaque sur ses activités quotidiennes.
Comment le marchand peut-il détecter cette attaque ?
Cette attaque étant très difficile à détecter par le marchand, celui-ci doit mettre en place les moyens de contrôle appropriés à la norme PCI DSS, décrits dans le formulaire SAQ A-EP afin d’aider à déceler et à éviter cette attaque.
Niveau de risque
Modéré

Pour de plus amples informations, veuillez consulter la documentation technique HiPay sur notre portail pour développeurs.

 

5.5. Intégration par API

Avec l’intégration par API, le site Web du marchand crée un formulaire de paiement et l’envoie à l’appareil du client. Les données de carte sont ensuite envoyées à partir de l’appareil du client au serveur du marchand avant d’être transmises au PSP. Le site Web du marchand peut également stocker ces informations.

Lorsque les cybercriminels attaquent les intégrations par API
Comment font-ils ?
Les cybercriminels piratent la sécurité du site Web du marchand et changent le programme qui reçoit les données de carte du formulaire de paiement afin qu’elles soient aussi stockées sur le disque dur du site Web du marchand. Les pirates retournent ensuite sur le site Web du marchand pour télécharger les données de carte.
Que voit le titulaire de la carte ?
Le formulaire de paiement. Le titulaire de la carte ne remarque aucune différence.
Que voit le marchand ?
Le marchand ne voit aucun effet de cette attaque sur ses activités quotidiennes, mais il est normalement possible de se rendre compte des attaques des pirates en inspectant le site Web.
Comment le marchand peut-il détecter cette attaque ?
Les conditions 10 et 11 de la norme PCI DSS ont pour but de détecter les cybercriminels essayant d’entrer dans un système par effraction et de le modifier.
Niveau de risque
Élevé – Il est fort probable que les cybercriminels attaquent les sites Web des marchands qui traitent les données des titulaires de carte. La plupart des compromissions de données concernent les sites Web des marchands qui utilisent ce type d’intégration.

Pour de plus amples informations, veuillez consulter la documentation technique HiPay sur notre portail pour développeurs.

[2] Source: Visa

 

6.  Liens utiles et connexes

Pour plus de renseignements sur les normes de sécurité PCI et les programmes de conformité du réseau de paiement par carte, veuillez visiter les sites suivants (en anglais).

 

Sites Web de l’industrie :

Visa Europe Payment Security

Mastercard Worldwide SDP Program

Mastercard propose gratuitement une série de feuillets informatifs sur la norme PCI DSS sur le site du programme de formation PCI 360.

Discover Information Security & Compliance (DISC)

 

Documents du Conseil des normes de sécurité PCI (PCI SSC) :

Conditions et procédures d’évaluation de sécurité

Veuillez consulter la bibliothèque du site Web du Conseil des normes de sécurité PCI pour obtenir les documents les plus récents.

 

Documentation utile sur la norme PCI DSS :

Understanding the SAQs for PCI DSS version 3

PCI DSS 3.2: What’s New?

MOTO – Protecting Telephone-based Payment Card Data

PCI DSS Quick Reference Guide – Understanding the Payment Card Industry Data Security Standard version 3.1

 

7.  Glossaire

Prestataire de services d’analyse agréé (Approved Scanning Vendor – ASV)

Prestataire fournissant les outils logiciels pour effectuer les analyses de vulnérabilité pour les réseaux et les systèmes (ordinateur, serveur et routeur). Ce prestataire décèle et signale toute vulnérabilité susceptible de donner au pirate informatique facilement accès aux serveurs du marchand. [3]

Vous trouverez de plus amples renseignements ainsi qu’une liste des prestataires de services d’analyse agréés sur le site Web du Conseil des normes de sécurité PCI.

 

Attestation de conformité (Attestation of Compliance – AOC)

Formulaire devant être rempli par tous les prestataires de services validant leur conformité à la norme PCI DSS.

Veuillez visiter le site Web du Conseil des normes de sécurité PCI pour télécharger les documents appropriés.

 

Environnement des données de titulaires de carte (Cardholder Data Environment – CDE)

Personnes, processus et technologies stockant, traitant ou transmettant les données de titulaires de carte ou des données d’authentification sensibles.

 

Évaluation sur place ou auto-évaluation

Évaluation détaillée effectuée soit par un évaluateur de sécurité qualifié (Qualified Security Assessor – QSA) accrédité par le PCI SSC, soit par un évaluateur de sécurité interne agréé (certified Internal Security Assessor – ISA). Cette évaluation confirme à l’acquéreur que l’organisation traite les données de carte conformément à la norme de sécurité des données de l’industrie des cartes de paiement (PCI DSS).

 

Norme de sécurité des données de l’industrie des cartes de paiement (PCI DSS)

Émanant du Conseil des normes de sécurité PCI (PCI Security Standards Council – PCI SSC), la norme PCI DSS comprend 12 conditions destinées à toute entreprise stockant, traitant ou transmettant des données de carte ou des données de compte. Ces conditions précisent le cadre d’un environnement de paiement sécurisé. 

 

Conseil des normes de sécurité PCI (PCI Security Standards Council – PCI SSC)

Le PCI SSC a été fondé par Visa Inc., Mastercard, JCB International, Discover et American Express.

Pour plus d’informations, veuillez visiter le site du Conseil des normes de sécurité PCI.

 

Point de vente (Point Of Sale – POS)

Matériel et/ou logiciel utilisé pour traiter les transactions par carte chez les marchands. 

 

Évaluateur de sécurité qualifié (Qualified Security Assessor – QSA)

Expert indépendant fournissant des services-conseils pour les évaluations PCI. Les sociétés d’évaluateurs de sécurité qualifiés disposent de personnel bien formé et de processus pour évaluer et attester la conformité à la norme PCI DSS.

Pour obtenir plus d’informations ainsi qu’une liste d’évaluateurs de sécurité qualifiés, veuillez visiter le site Web du Conseil des normes de sécurité PCI.

 

Rapport de conformité (Report on Compliance – ROC)

Document PCI DSS contenant des informations détaillées qui renseignent sur le statut de conformité d’une entreprise en ce qui concerne les conditions requises pour la norme PCI DSS.

Ce rapport est établi par un évaluateur de sécurité qualifié lorsqu’une évaluation sur place est effectuée.

 

Questionnaire d’auto-évaluation (Self-Assessment Questionnaire – SAQ)

Document PCI DSS servant d’outil de validation aux marchands et aux prestataires de services qui ne sont pas tenus d’effectuer des évaluations sur place pour la conformité à la norme PCI DSS.

Pour obtenir plus d’informations et télécharger ce formulaire, veuillez visiter le site Web du Conseil des normes de sécurité PCI.

 

[3] Condition 11.2 de la norme PCI DSS

 

Veuillez consulter le site Web du PCI SSC pour obtenir plus de renseignements.

 

8.  Questions fréquemment posées

Mon processeur de paiements est en conformité avec la norme PCI DSS : dois-je l’être aussi ?

Oui. On pense souvent, à tort, que le fait d’externaliser le traitement des paiements en passant par un prestataire de services conforme à la norme PCI DSS rend également le marchand conforme et élimine la nécessité d’être en conformité.

Bien que les services de paiement de HiPay simplifient le cadre de mise en conformité à la norme PCI DSS en traitant les données de carte en toute sécurité, il reste nécessaire pour tous les marchands de valider leur conformité à la norme PCI DSS.

L’externalisation vers un prestataire de services de paiement conforme à la norme PCI DSS ne rend donc pas automatiquement le marchand conforme ni n’élimine la responsabilité et l’obligation qu’ont les marchands de s’assurer que les données de carte de paiement sont protégées.

 

Les conditions de validation de la conformité à la norme PCI DSS sont-elles déterminées par HiPay ?

Non, ce sont les réseaux de paiement et les acquéreurs qui définissent les conditions imposées aux marchands en fonction des différents niveaux.

 

À quelle fréquence dois-je valider auprès de HiPay ma conformité à la norme PCI DSS ?

Conformément aux conditions de validation des réseaux de paiement, la validation de la conformité à la norme PCI DSS est requise par HiPay au moment de l’intégration administrative des marchands et, par la suite, chaque année pour les marchands traitant des transactions Visa et/ou Mastercard (niveaux 1 à 3). La validation est recommandée pour les marchands de niveau 4.

 

Quelle est la différence entre validation et conformité à la norme PCI DSS ?

La conformité est un exercice continu, non ponctuel. Les formulaires SAQ sont des outils de validation pour les marchands et prestataires de services admissibles et servent à prouver qu’ils ont évalué leur conformité à la norme PCI DSS par le biais d’une auto-évaluation.

  • Ils donnent une représentation de la situation au moment de l’auto-évaluation et des analyses de vulnérabilité.
  • Une simple modification apportée au système peut engendrer de nouvelles vulnérabilités et, par conséquent, la non-conformité.
  • Par la suite, seule une autre évaluation ou une enquête judiciaire après une violation de données peut prouver la conformité à la norme PCI DSS.

 

Quelles sont les conséquences de la non-conformité à la norme PCI DSS ?

Les conséquences associées au fait de ne pas être en conformité avec la norme PCI DSS sont déterminées et imposées respectivement par les réseaux de paiement.

  • Les données de vos clients peuvent être exposées à un risque de compromission et d’utilisation frauduleuse.
  • Une enquête judiciaire peut coûter des milliers d’euros. Les marchands non conformes à la norme PCI DSS encourent des amendes pouvant s’élever à des dizaines, voire des centaines de milliers d’euros. Ces frais vous incombent s’il est prouvé qu’il y a eu violation de données. Les amendes sont imposées par les réseaux de paiement par carte à l’acquéreur/PSP, puis transférées au marchand.
  • À la suite d’une violation de données, le marchand est tenu de valider sa conformité à la norme PCI DSS en fonction du niveau et des conditions requises, quel que soit son niveau actuel.
  • Suspension éventuelle de l’acceptation des cartes de crédit par les réseaux de paiement.
  • Atteinte à la réputation et perte d’activité. À la suite d’une violation de données, les entreprises se retrouvent face au défi de conserver la confiance de leurs clients.