En savoir plus

Transcription

Payment Card Industry (PCI)
Normes en matière de sécurité
des données
Version 1.1
Date de publication : septembre 2006
Mettre en place et gérer un réseau sécurisé
1ère exigence :
installer et gérer une configuration de pare-feu afin de protéger les
données des titulaires de carte
2ème exigence :
ne pas utiliser les paramètres par défaut du fournisseur pour les mots de
passe et les autres paramètres de sécurité du système
Protéger les données des titulaires de carte
3ème exigence :
protéger les données des titulaires de carte stockées
4ème exigence :
crypter la transmission des données des titulaires de carte sur les
réseaux publics ouverts
Disposer d’un programme de gestion de la vulnérabilité
5ème exigence :
6
ème
exigence :
utiliser et mettre à jour régulièrement un logiciel antivirus
développer et gérer des applications et systèmes sécurisés
Mettre en œuvre des mesures de contrôle d'accès efficaces
7ème exigence :
limiter l’accès aux données des porteurs de carte aux cas de nécessité
professionnelle absolue
8ème exigence :
attribuer une identité d’utilisateur unique à chaque personne disposant
d’un accès informatique
9ème exigence :
limiter l’accès physique aux données des titulaires de carte
Surveiller et tester régulièrement les réseaux
10ème exigence :
suivre et surveiller tous les accès aux ressources du réseau et aux
11ème exigence :
tester régulièrement les systèmes et procédures de sécurité
Disposer d’une politique en matière de sécurité de l’information
12ème exigence :
disposer d’une politique régissant la sécurité de l’information
Payment Card Industry (PCI) Data Security Standard
1
Préface
Ce document décrit les 12 exigences des Normes en matière de sécurité des données (Data Security
Standard, DSS) de l’industrie des cartes de crédit (Payment Card Industry, PCI). Les exigences PCI DSS
s'organisent en 6 groupes logiques liés, qui sont des « objectifs de contrôle ».
Le tableau ci-dessous présente un certain nombre d’éléments communément utilisés des données de
titulaire de carte et d’authentification sensibles ; indique si le stockage de chaque élément de données
est autorisé ou interdit et précise si chaque élément de données doit être protégé. Ce tableau n’est
pas exhaustif, mais il est présenté de manière à illustrer les divers types d’exigences qui s’appliquent à
chaque élément de données.
Les exigences PCI DSS s’appliquent si un Numéro de compte primaire (Primary Account Number, PAN)
est stocké, traité ou transmis. En l’absence de stockage, de traitement ou de transmission de PAN, les
exigences PCI DSS ne s’appliquent pas.
Élément de
données
Données de titulaire
Numéro de cpte
primaire (PAN)
Exig. 3.4
PCI DSS
OUI
OUI
OUI
OUI
OUI*
NON
Code service*
OUI
OUI*
NON
Date d’expiration*
OUI
OUI*
NON
Nom du titulaire*
Données d’authentification
sensibles**
Archivage Protection
autorisé
requise
Bande magnétique
complète
CVC2/CVV2/CID
PIN/bloc PIN
NON
s.o.
s.o.
NON
s.o.
s.o.
NON
s.o.
s.o.
* Ces éléments de données doivent être protégés s’ils sont stockés conjointement avec le PAN. Cette protection doit
être conforme aux exigences PCI DSS en liaison avec la protection générale de l’environnement des titulaires de
carte. En outre, d’autres lois (par exemple, relatives à la protection des données personnelles des consommateurs,
de vie privée, de vol d'identité ou de sécurité des données) peuvent imposer une protection spécifique de ces
données, ou une divulgation adéquate des pratiques de la société dès lors que des données à caractère personnel
sont collectées dans le cadre de l’activité. Toutefois, les PCI DSS ne s'appliquent pas si des PAN ne sont pas
stockés, traités ou transmis.
** Aucune donnée d’authentification sensible ne doit être stockée après autorisation (même cryptée).
Ces exigences en matière de sécurité s'appliquent à l'ensemble des « composantes du système ». Ces
composantes sont définies comme toute composante, tout serveur ou toute application du réseau, inclus
dans l’environnement de données du titulaire de carte, ou connecté à celui-ci. L’environnement de
données du titulaire de carte est la partie du réseau qui possède des données de titulaires de carte ou
des données d’authentification sensibles. Une segmentation adéquate du réseau, qui isole des systèmes
stockant, traitant ou transmettant des données de titulaire de carte de ceux qui ne le font pas peut réduire
le périmètre de l’environnement de données du titulaire de carte. Au nombre des composantes de réseau
2
figurent notamment les pare-feux, commutateurs, routeurs, points d'accès sans fil, appareils de réseau et
autres dispositifs de sécurité. Les divers types de serveur incluent notamment les suivants : Internet,
base de données, authentification, courrier, mandataire, network time protocol (NTP) et serveur de nom
de domaine (domain name server, DNS). Les applications englobent l’ensemble des applications
achetées et personnalisées, y compris internes et externes (Internet).
3
Mettre en place et gérer un réseau sécurisé
1ère exigence : installer et gérer une configuration de pare-feu afin de protéger les
Les pare-feux sont des dispositifs informatiques qui contrôlent le trafic autorisé à entrer sur le réseau de
la société, ou à en sortir, ainsi que le trafic dans des secteurs plus sensibles du réseau interne d'une
société. Un pare-feu vérifie la totalité du trafic du réseau et bloque les transmissions non-conformes aux
critères de sécurité édictés.
Tous les systèmes doivent être protégés contre tout accès non autorisé par Internet, qu’il s’agisse
d’accès au système aux fins de commerce électronique, d’accès Internet par des employés, grâce au
navigateur de leur poste de travail, ou d’accès par le biais du courrier électronique des employés. Il arrive
fréquemment que des chemins apparemment insignifiants, vers et depuis l’Internet, puissent constituer
des voies d’accès non protégées à des systèmes clés. Les pare-feux sont un mécanisme de protection
essentiel de tout réseau informatique.
1.1
1.2
1.3
Mettre en place des normes de configuration de pare-feu incluant les aspects suivants :
1.1.1 un processus formel d’approbation et de test de toutes les connexions externes de
réseau, ainsi que de l’ensemble des modifications apportées à la configuration du parefeu ;
1.1.2 un diagramme du réseau à jour, avec toutes les connexions à des données de titulaires
de carte, y compris tous réseaux sans fil ;
1.1.3 la nécessité d’un pare-feu pour chaque connexion Internet et entre toute zone d'accueil
(demilitarized zone, DMZ) et la zone de réseau interne ;
1.1.4 la description des groupes, rôles et responsabilités en matière de gestion logique des
composants de réseau ;
1.1.5 une liste écrite des services et ports nécessaires à l’activité ;
1.1.6 la justification et la consignation par écrit de tous protocoles disponibles en dehors des
protocoles http (hypertext transfer protocol, HTTP), SSL (secure sockets layer, SSL),
SSH (secure shell, SSH) et de réseau privé virtuel (virtual private network, VPN) ;
1.1.7 la justification et la consignation par écrit de tous protocoles à risque autorisés (par
exemple, un protocole de transfert de fichiers (file transfer protocol, FTP), avec les
raisons de l’utilisation du protocole, et les mesures de sécurité utilisées) ;
1.1.8 un examen trimestriel des ensembles de règles applicables aux pare-feux et aux
routeurs ;
1.1.9 des normes de configuration pour les routeurs ;
Développer une configuration de pare-feu bloquant tout trafic en provenance de réseaux et
d'hôtes « non sécurisés », à l’exception des protocoles nécessaires à l’environnement des
données de titulaire de carte.
Élaborer une configuration de pare-feu limitant les connexions entre des serveurs accessibles
publiquement et des composantes de système stockant des données de titulaire de carte, y
compris toute connexion depuis un réseau sans fil. Cette configuration de pare-feu doit en
principe englober les aspects suivants :
1.3.1 la restriction du trafic Internet entrant vers des adresses Internet dans la zone d'accueil
(filtres d'entrée) ;
1.3.2 ne pas laisser des adresses internes passer de l’Internet à la zone d’accueil ;
4
1.3.3
1.4
1.5
la mise en œuvre d’une inspection dynamique, également désignée filtre dynamique à
paquets (ce qui signifie que seule les connexions « établies » sont autorisées dans le
réseau) ;
1.3.4 le positionnement de la base de données dans une zone de réseau interne, distincte de
la zone d’accueil ;
1.3.5 la limitation du trafic entrant et sortant à ce qui est nécessaire à l'environnement des
données de titulaires de carte ;
1.3.6 la sécurisation et la synchronisation de fichiers de configuration de routeur. Les fichiers
de configuration d'exécution (pour le fonctionnement normal des routeurs) et les fichiers
de configuration de démarrage (lors du redémarrage des machines) doivent par exemple
présenter une configuration sécurisée identique ;
1.3.7 l'interdiction de tout autre trafic, entrant ou sortant, dans la mesure où il n’a pas été
spécifiquement autorisé ;
1.3.8 l'installation de pare-feux de périmètre entre tous réseaux sans fil et l’environnement de
données de titulaires de carte, et la configuration de ces pare-feux de manière à bloquer
tout trafic provenant de l'environnement sans fil, ou pour contrôler tout trafic (lorsqu’il est
nécessaire à des fins commerciales) ;
1.3.9 l'installation d’un logiciel pare-feu personnel sur un ordinateur portable ou un ordinateur
appartenant à un employé disposant d'une connectivité directe à l'Internet (par exemple,
les ordinateurs portables utilisés par les employés), utilisés pour accéder au réseau de
l'organisation.
Interdire l’accès public direct entre les réseaux externes et toute composante du système
stockant des données de titulaire de carte (par exemple, les fichiers de base de données, journal
et trace).
1.4.1 Mettre en place une zone d’accueil pour filtrer et vérifier l’ensemble du trafic, ainsi que
pour interdire les routes directes pour le trafic Internet entrant et sortant.
1.4.2 Restreindre le trafic sortant des applications de carte de paiement vers des adresses
Internet situées dans la zone d’accueil.
Mettre en œuvre un déguisement d’adresse Internet, pour éviter que les adresses internes ne
soient traduites et divulguées sur Internet. Utilisation de technologies mettant en œuvre l’espace
adresse RFC 1918, telles qu'une traduction d’adresse de port (port address translation, PAT) ou
une traduction d’adresse de réseau (network address translation, NAT).
2ème exigence : ne pas utiliser les paramètres par défaut du fournisseur pour les mots de
passe et les autres paramètres de sécurité du système
Les pirates informatiques (externes et internes à une société) utilisent fréquemment des mots de passe
par défaut du fournisseur et d’autres paramètres par défaut du fournisseur pour s'introduire dans les
systèmes. Ces mots de passe et paramètres sont bien connus des communautés de pirates et facilement
déterminés au moyen des informations publiques.
2.1
Il est impératif de toujours modifier les réglages par défaut du fournisseur avant d’installer un
système sur le réseau (par exemple, inclure des mots de passe, des chaînes communautaires de
protocole de gestion de réseau simple (simple network management protocol, SNMP) et la
suppression de comptes inutiles).
2.1.1 Dans le cas des environnements sans fil, modifier les réglages par défaut du
fournisseur sans fil, y compris notamment les clés Wired Equivalent Privacy (WEP), le
Service Set IDentifier (SSID) par défaut, les mots de passe et les chaînes
communautaires SNMP. Désactiver les émissions en clair du SSID sur le réseau. Mettre
5
2.2
2.3
2.4
en place une technologie d’accès WiFi protégé (WPA et WPA2) pour le cryptage et
l’authentification lorsqu’il existe une capacité WPA.
Développer des normes de configuration pour l’ensemble des composants du système. Faire en
sorte que ces normes prennent en compte l’ensemble des vulnérabilités connues en matière de
sécurité et soient cohérentes avec des normes de renforcement de la sécurité du système
acceptées par l’industrie, telles que définies, par exemple par le SysAdmin Audit Network
Security Network (SANS), le National Institute of Standards Technology (NIST) et le Center for
Internet Security (CIS).
2.2.1 Mettre en œuvre uniquement une section primaire par serveur (ainsi, les serveurs
Internet, de base de données et DNS doivent être mis en place sur des serveurs
distincts)
2.2.2 Désactiver tous les services et protocoles inutiles et non sécurisés (les services et
protocoles qui ne sont pas directement nécessaires à l’exécution de la fonction spécifiée
des appareils)
2.2.3 Configurer les paramètres de sécurité du système pour prévenir toute utilisation
frauduleuse
2.2.4 Supprimer toutes les fonctionnalités inutiles, telles que les scripts, lecteurs, dispositifs,
sous-systèmes, systèmes de fichiers et serveurs Internet inutiles.
Crypter tous les accès administratifs non-console. Utiliser des technologies telles que SSH, VPN
ou SSL/TLS (transport layer security) pour la gestion par Internet et les autres accès
administratifs non-console.
Les fournisseurs d’hébergement doivent protéger les données et l’environnement hébergé de
chaque entité. Ces fournisseurs doivent se conformer à des instructions spécifiques figurant en
Annexe A : « Application des normes PCI en matière de sécurité des données (DSS) des
fournisseurs d’hébergement ».
6
Protéger les données des titulaires de carte
3ème exigence : protéger les données des titulaires de carte en stock
Le cryptage est une composante essentielle de la protection des données de titulaires de carte. Si un
intrus parvient à franchir les autres contrôles de sécurité du réseau et à accéder à des données cryptées,
sans les clés de cryptographie adéquates, les données ne sont pas lisibles ni utilisables par lui. D’autres
méthodes efficaces de protection des données stockées doivent également être envisagées comme des
opportunités d’atténuation possible du risque. Ainsi, au nombre des méthodes de minimisation des
risques figurent notamment le non-stockage des données de carte de crédit à moins que cela ne soit
absolument nécessaire, le fait de tronquer les données du titulaire de carte si un PAN complet n’est pas
nécessaire, ainsi que la transmission des PAN exclusivement par courrier électronique crypté.
3.1
3.2
Le stockage des données de titulaire de carte doit être limité au minimum. Élaborer une politique
en matière de conservation et d’élimination de données. Limiter les quantités stockées et les
délais de conservation des données au strict nécessaire au plan économique, légal et/ou
réglementaire, comme prévu dans la politique en matière de conservation des données.
Ne pas stocker de données d’authentification sensibles après autorisation (même si elles sont
cryptées).
Au nombre des données d’authentification sensibles figurent les données indiquées dans les
Exigences 3.2.1 à 3.2.3 ci-après :
3.2.1 Ne jamais stocker la totalité du contenu d’une quelconque piste de la bande magnétique
(au dos d'une carte, sur une puce ou ailleurs). Les données sont alternativement
désignées piste complète, piste 1, piste 2 et données de bande magnétique.
Dans le cours normal de l’activité, il est possible qu’il soit nécessaire de conserver les
éléments de données de la bande magnétique ci-après : le nom du titulaire du compte, le
numéro de compte primaire (primary account number, PAN), la date d’expiration et le
code de service. Afin de minimiser le risque, stocker uniquement les éléments de
données nécessaires à l'activité. NE JAMAIS stocker le code de vérification de la carte,
ni la valeur, ni non plus des éléments de données de valeur de vérification du code PIN.
Remarque : pour plus d’information, se reporter au « Glossaire ».
Ne pas stocker de code de validation de carte, ni de valeur (à trois ou quatre chiffres,
imprimés sur le côté face ou au verso d'une carte de paiement) utilisée pour vérifier des
transactions cartes absente (card-not-present, CNP).
Remarque : pour plus d’information, se reporter au « Glossaire ».
3.2.2
3.2.3 Ne pas stocker le numéro d’identification personnel (personal identification number, PIN),
3.3
3.4
ni le bloc PIN crypté.
Masquer le PAN lorsqu’il s’affiche (les six premiers chiffres et les quatre derniers sont le nombre
maximum de chiffres affichés).
Remarque : cette exigence ne s’applique pas aux employés et aux autres parties ayant
spécifiquement besoin d’avoir connaissance de la totalité du PAN ; de même, cette exigence ne
remplacera-t-elle pas des obligations plus rigoureuses existantes applicables à l’affichage de
données de titulaire de carte (par exemple, dans le cas de reçus de point de vente [point of sale,
POS]).
Rendre le PAN, au minimum, illisible où qu’il soit stocké (y compris des données sur support
numérique portable, support de sauvegarde, journaux et données reçues de, ou stockées par des
réseaux sans fil), en utilisant l'une ou l'autre des approches suivantes :
•
des fonctions efficaces de hachage à sens unique (index hachés) ;
7
•
une troncature ;
•
des jetons et pads index (les pads doivent être stockés de manière sécurisée) ;
•
une cryptographie performante, avec des processus et procédures de gestion clés
associés.
En ce qui concerne les coordonnées de compte, au MINIMUM, le PAN doit être rendu
illisible.
Si, pour une raison ou pour une autre, une société n’est pas en mesure de crypter des données
de titulaire de carte, se reporter à l'Annexe B : « Contrôles destinés à suppléer au défaut de
cryptage des données stockées ».
3.4.1 Si un cryptage par disque est utilisé (au lieu d’un cryptage par fichier ou base de
données au niveau colonne), l'accès logique doit être géré indépendamment des
mécanismes de contrôle d'accès au système d'exploitation natif (par exemple, en
n'utilisant pas un système local, ni des comptes Active Directory). Les clés de décryptage
ne doivent pas être liées à des comptes d’utilisateur.
3.5
3.6
Protéger les clés de cryptage utilisées pour le cryptage des données de titulaire de carte, à la fois
contre la divulgation et l’utilisation illicite.
3.5.1 limiter l’accès aux clés au plus petit nombre possible de dépositaires, en fonction
des nécessités ;
3.5.2 stocker les clés, de manière sécurisée, en un nombre de lieux et de formes aussi réduit
que possible.
Consigner et mettre en œuvre complètement l’ensemble des processus et procédures de gestion
de clés pour les clés utilisées pour le cryptage des données des titulaires de carte, y compris les
suivantes :
3.6.1 génération de clés performantes ;
3.6.2 distribution de clé sécurisée ;
3.6.3 stockage de clé sécurisé ;
3.6.4 changement périodique des clés :
•
comme tenu pour nécessaire et recommandé par l’application associée (par
exemple, le changement de clé, ou re-keying), de préférence automatiquement ;
• au moins annuellement ;
3.6.5 destruction des anciennes clés ;
3.6.6 répartition des informations et mise en place d’un double système de contrôle des clés
(de manière à ce que deux ou trois personnes, chacune d’elles connaissant une partie de
la clé, reconstituent la clé dans son intégralité) ;
3.6.7 la prévention des substitutions de clés non autorisées ;
3.6.8 le remplacement des clés dont compromises ou suspectées de l’être ;
3.6.9 l'annulation des clés anciennes ou invalides ;
3.6.10 l'obligation, pour les principaux dépositaires de clés, de signer un formulaire indiquant
qu’ils comprennent et acceptent les responsabilités liées à leurs fonctions de dépositaire.
4ème exigence : crypter la transmission des données des titulaires de carte sur les
réseaux publics ouverts
Les informations sensibles doivent être cryptées lors de leur transmission sur des réseaux permettant
aux pirates, ainsi qu’ils le font couramment, d’intercepter, de modifier et de détourner des données en
cours de transit.
8
4.1
Utiliser des techniques de cryptographie et des protocoles de sécurité performants, comme par
exemple des protocoles SSL (Secure Sockets Layer)/TLS (Transport layer security) et IPSEC
(Internet Protocol Security) pour protéger les données sensibles des titulaires de carte lors de
leur transmission sur des réseaux publics ouverts.
L’Internet, le WiFi (IEEE 802.11x), le réseau de téléphonie mobile (Global System for Mobile
Communications, GSM) et le General Packet Radio Service (GPRS) sont des exemples de
réseaux publics ouverts relevant du périmètre des normes PCI DSS.
4.1.1
Dans le cas des réseaux sans fil transmettant des données de titulaire de carte,
crypter les transmissions en utilisant la technologie d’accès protégé au WiFi (WPA ou
WPA2), IPSEC VPN ou SSL/TLS. Ne jamais se fier uniquement au protocole WEP
(Wired Equivalent Privacy) pour protéger la confidentialité et l’accès à un réseau LAN
sans fil. En cas d’utilisation de WEP, prendre les mesures suivantes :
•
4.2
utiliser avec une clé de cryptage d’au moins 104 bits et une valeur d’initialisation de 24
bits au minimum ;
• utiliser UNIQUEMENT en liaison avec la technologie d’accès protégé au WiFi (WPA
ou WPA2), VPN ou SSL/TLS ;
• permuter les clés WEP partagées une fois par trimestre (ou automatiquement si la
technologie le permet) ;
• permuter les clés WEP partagées en cas de changement des personnels disposant
d’un accès aux clés ;
• restreindre l’accès basé sur l'adresse MAC (media access code).
Ne jamais envoyer de PAN non cryptés par courrier électronique.
Disposer d’un programme de gestion de la vulnérabilité
5ème exigence : utiliser et mettre à jour régulièrement un logiciel ou des programmes
antivirus
Nombre de vulnérabilités et de virus dangereux entrent dans le réseau par le biais des activités e-mail
des employés. Un logiciel anti-virus doit être utilisé sur tous les systèmes ordinairement affectés par les
virus afin de protéger les systèmes contre les logiciels dangereux.
5.1
5.2
Déployer un logiciel anti-virus sur tous les systèmes généralement affectés par les virus (en
particulier les ordinateurs personnels et les serveurs)
Remarque : les systèmes d’exploitation sous UNIX et les ordinateurs centraux ne figurent pas au
nombre des systèmes couramment affectés par les virus.
5.1.1 Faire en sorte que les programmes anti-virus soient capables de détecter d’autres formes
de logiciels nuisibles, y compris les logiciels d’espionnage (ou « spyware ») et
publicitaires, de les supprimer et d'assurer une protection contre ceux-ci.
Faire en sorte que tous les mécanismes anti-virus soient à jour, qu’ils fonctionnent activement et
qu'ils soient capables de générer des listes de contrôle.
6ème exigence : développer et gérer des applications et systèmes sécurisés
Il arrive que des individus peu scrupuleux utilisent les vulnérabilités en matière de sécurité pour accéder
aux systèmes. Il est remédié à nombre de ces vulnérabilités par des correctifs de sécurité mis à
disposition par le fournisseur. Tous les systèmes doivent être équipés des correctifs appropriés les plus
récents, afin de les protéger des intrusions d'employés ou de pirates informatiques, ainsi que contre les
virus. Remarque : les correctifs appropriés sont ceux qui ont été suffisamment évalués et testés pour
déterminer qu’ils n’entrent pas en conflit avec les configurations de sécurité en place. En ce qui concerne
9
les applications développées en interne, de nombreuses vulnérabilités peuvent être évitées par des
processus de développement de système standard, ainsi que par des techniques de codage sécurisées.
6.1
6.2
6.3
6.4
6.5
S'assurer que toutes les composantes et tous les logiciels du système disposent des correctifs de
sécurité les plus récents mis à disposition par le fournisseur. Installer les correctifs de sécurité
dans un délai d’un mois suivant leur publication.
Mettre en place un processus destiné à identifier les vulnérabilités en matière de sécurité
nouvellement identifiées (par exemple, souscrire un abonnement à des services d’alerte
disponibles gratuitement sur l'Internet). Mettre les normes à jour afin de faire face aux nouveaux
problèmes de vulnérabilité.
Développer des applications logicielles sur la base des meilleures pratiques sectorielles et
intégrer la sécurité de l’information dans l’ensemble du cycle de développement de logiciel.
6.3.1 Tester tous les correctifs de sécurité, ainsi que toutes modifications de configuration de
système ou de logiciel avant déploiement.
6.3.2 Séparer les environnements de développement, de test et de production.
6.3.3 Séparation des obligations entre les environnements de développement, de test et de
production.
6.3.4 Les données de production (PAN actifs) ne sont pas utilisées aux fins de test ou de
développement.
6.3.5 Suppression des données et comptes de tests avant que les systèmes de production ne
deviennent actifs.
6.3.6 Suppression des comptes d’application, noms d’utilisateur et mots de passe usuels avant
que les applications ne deviennent actives ou ne soient mises à la disposition de clients.
6.3.7 Examen du code personnalisé avant de mettre à la disposition de la production ou de
clients afin d’identifier toute vulnérabilité de cryptage éventuelle.
Se conformer aux procédures en matière de contrôle des changements pour toutes les
modifications apportées au système et au logiciel. Les procédures doivent inclurent les éléments
suivants :
6.4.1 consignation écrite de l’impact ;
6.4.2 approbation par signature de la direction par les parties appropriées ;
6.4.3 vérification de la fonctionnalité opérationnelle ;
6.4.4 procédures de sauvegarde.
Développer toutes les applications Internet sur la base de principes directeurs en matière de
codage sécurisé tels que ceux de l'Open Web Application Security Project (OWASP). Étudier un
code d’application personnalisé, afin d’identifier les vulnérabilités en matière de codage. Prévenir
les vulnérabilités de codage courantes dans les processus de développement de logiciel, afin
d’inclure les éléments suivants :
6.5.1 les entrées non validées ;
6.5.2 un contrôle d’accès compromis (par exemple, une utilisation malveillante d’identités
d’utilisateur) ;
6.5.3 une authentification et une gestion de session compromises (l’utilisation d'éléments
d’authentification de compte et les cookies de session) ;
6.5.4 les attaques par Cross-Site Scripting (XSS ou CSS) ;
6.5.5 les attaques par débordement de tampon ;
6.5.6 les attaques par injection (par exemple, une injection de commandes SQL (Structured
Query Language)) ;
6.5.7 une gestion d’erreur inadéquate ;
10
6.5.8 un stockage non sécurisé ;
6.5.9 un refus de service ;
6.5.10 une gestion de configuration non sécurisée.
6.6
Faire en sorte que toutes les applications d’interface Internet soient protégées contre les attaques connues
grâce à l’une ou l’autre des méthodes suivantes :
•
faire contrôler par une organisation spécialisée dans la sécurité des applications, tout code d'application
personnalisé aux fins de détection des vulnérabilités courantes ;
•
Installer un pare-feu de couche application qui protège les applications d’interface Internet.
Remarque : cette méthode est considérée comme une « meilleure pratique » jusqu’au 30 juin 2008, après
quoi, elle devient obligatoire.
Mettre en œuvre des mesures de contrôle d'accès efficaces
7ème exigence : limiter l’accès aux données des porteurs de carte aux cas de nécessité
professionnelle absolue
Cette exigence est destinée à garantir que seuls les personnels autorisés peuvent accéder aux données
critiques.
7.1
7.2
Limiter l’accès aux ressources de calcul et aux informations des titulaires de carte aux seules
personnes qui, en raison de leurs fonctions, sont tenues d'y accéder.
Mettre en place un mécanisme pour les systèmes avec de multiples utilisateurs limitant l’accès
en fonction du besoin de l'utilisateur d'en avoir connaissance et réglé sur « interdire à tous », sauf
autorisation spécifique.
11
8ème exigence : attribuer une identité d’utilisateur unique à chaque personne disposant
d’un accès informatique
L’attribution d’un identifiant unique (identité d’utilisateur) à chaque personne disposant d’un accès garantit
que les actions concernant des données et systèmes critiques seront exécutées par des utilisateurs
connus et dûment autorisés, et en assure la traçabilité.
8.1
Identifier tous les utilisateurs par un nom d’utilisateur unique avant de les autoriser à accéder aux
composants du système ou aux données de titulaires de carte.
En plus de l’attribution d’une identité d’utilisateur unique, employer au moins l’une des méthodes
ci-après pour identifier l’ensemble des utilisateurs :
8.2
•
mot de passe ;
•
jetons (par exemple, SecureID, certificats ou clé publique) ;
•
8.3
8.4
8.5
biométrie.
Mettre en œuvre une authentification à deux facteurs pour l'accès distant au réseau par des
employés, administrateurs et tiers. Utiliser des technologies telles que l’authentification à distance
et un service de renseignement par téléphone (RADIUS) ou un système de contrôle d’accès de
contrôleur d’accès au terminal (Terminal Access Controller Access Control System, TACACS)
avec des jetons ; ou VPN (basé sur SSL/TLS ou IPSEC) avec des certificats individuels.
Crypter tous les mots de passe pour leur transmission et leur stockage sur toutes les
composantes du système.
Assurer une gestion adéquate de l’identification et des mots de passe d’utilisateur pour des
utilisateurs non consommateurs et des administrateurs sur toutes les composantes du système,
comme suit :
8.5.1 contrôler l’ajout d'identités d’utilisateur, d’identifiants et d’autres éléments d’identification,
leur suppression et leur modification ;
8.5.2 vérifier l’identité de l’utilisateur avant de procéder à une réinitialisation de mot de passe ;
8.5.3 mettre en place un mot de passe initial, avec une valeur unique, pour chaque utilisateur
et le modifier immédiatement après la première utilisation ;
8.5.4 mettre fin immédiatement à l’accès des utilisateurs ayant cessé d’être employés par
l’entreprise ;
8.5.5 supprimer les comptes d’utilisateur inactifs au moins tous les 90 jours ;
8.5.6 activer les comptes utilisés par des fournisseurs aux fins de maintenance à distance
uniquement durant la période nécessaire ;
8.5.7 communiquer les procédures et politiques en matière de mot de passe à tous les
utilisateurs ayant accès aux données de titulaires de carte ;
8.5.8 ne pas utiliser de comptes et mots de passe collectifs, partagés ou génériques ;
8.5.9 changer les mots de passe d’utilisateur au moins tous les 90 jours ;
8.5.10 exiger que les mots de passe comptent au moins sept caractères ;
8.5.11 utiliser des mots de passe contenant des caractères à la fois numériques et
alphabétiques ;
8.5.12 ne pas autoriser une personne à soumettre un nouveau mot de passe identique à l’un ou
l’autre des quatre derniers mots de passe utilisés par elle ;
8.5.13 limiter le nombre de tentatives d’accès en verrouillant l’identité d’utilisateur après au plus
6 tentatives ;
8.5.14 fixer la période de verrouillage à trente minutes, ou jusqu'à ce qu'un administrateur active
l'identité d'utilisateur ;
12
8.5.15 si une session est inactive depuis plus de 15 minutes, imposer à l’utilisateur de saisir à
nouveau son mot de passe pour réactiver le terminal ;
8.5.16 authentifier tous les accès à toute base de données contenant des données de titulaire
de carte. Ceci inclut les accès par les applications, administrateurs et tous les autres
utilisateurs.
13
9ème exigence : limiter l’accès physique aux données des titulaires de carte
Tout accès physique à des données ou systèmes contenant des données de titulaires de carte est
l’occasion, pour des individus, d'accéder à des dispositifs ou données et de s'emparer de systèmes ou
d'exemplaires papier, et doit de ce fait être limité de manière appropriée.
9.1
Utiliser des contrôles d’entrée dans les installations appropriés, afin de limiter et de contrôler
l’accès physique à des systèmes qui stockent, traitent ou transmettent des données de porteur
de carte.
9.1.1 Utiliser des caméras pour surveiller les zones sensibles. Vérifier les données collectées
9.2
9.3
9.4
9.5
9.6
9.7
9.8
9.9
et les mettre en relation avec d’autres. Sauf interdiction légale, stocker ces données
durant au moins 3 mois.
9.1.2 Limiter l’accès physique aux prises du réseau accessibles publiquement.
9.1.3 Limiter l’accès physique aux points d’accès sans fil, portails et périphériques portables.
Développer des procédures destinées à aider l’ensemble des personnels à faire une distinction
entre les employés et les visiteurs, en particulier dans les zones où des données de titulaires de
carte sont accessibles.
« Employé » désigne les employés à temps plein et partiel, les salariés et personnels à temps
partiel, ainsi que les consultants ayant la qualité de « résident » sur le site de l'entité. Le terme
« visiteur » fait référence aux fournisseurs, invités d’un employé, personnels de service ou à toute
personne ayant besoin d’accéder aux locaux pour une brève période, n’excédant généralement
pas une journée.
Faire en sorte que tous les visiteurs soient gérés comme suit :
9.3.1 que, le cas échéant, une autorisation leur soit délivrée pour leur permettre d’accéder à
des zones dans lesquelles des données de titulaire de carte sont traitées ou conservées ;
9.3.2 que, le cas échéant, leur soit remis un « laisser-passer » (par exemple, un badge ou un
dispositif d’accès) ayant une heure et une date d’expiration, et identifiant les visiteurs
comme n'étant pas des employés de l'entreprise ;
9.3.3 qu'il leur soit demandé de restituer leur « laisser-passer » avant de quitter les
installations ou à la date d’expiration.
Utiliser un registre des visiteurs afin de conserver une piste de vérification physique de l’activité
du visiteur. À moins que le droit en vigueur ne l’interdise, conserver ce registre durant une
période d’au moins trois mois.
Stocker les sauvegardes en lieu sûr, de préférence dans des installations hors site, par exemple,
sur un site alternatif ou de sauvegarde, ou une installation de stockage commercial.
Assurer la sécurité physique de tous documents papier et supports électroniques (y compris les
ordinateurs, supports électroniques, matériel de réseau et de communication, lignes de
télécommunications, reçus papier, rapports papier et télécopies) contenant des données de
titulaires de carte.
Assurer un contrôle rigoureux sur la diffusion interne ou externe de tous types de support
contenant des données de titulaires de carte, et notamment comme suit :
9.7.1 classifier le support pour qu’il puisse être identifié comme confidentiel ;
9.7.2 envoyer le support par service de coursier sécurisé, ou par tout autre mode de livraison
permettant un suivi exact.
Faire en sorte que la direction autorise la sortie de tout support placé dans une zone sécurisée
(en particulier lorsque ce support est destiné à être communiqué à des personnes).
Maintenir un contrôle strict sur le stockage et l'accessibilité des médias contenant des données
de titulaire de carte.
14
9.10
9.9.1 Inventorier strictement tous les supports et s’assurer qu’ils sont stockés en sécurité.
Détruire les supports contenant des données de titulaire de carte lorsqu’ils ne sont plus
nécessaires, pour des raisons commerciales ou juridiques, comme suit :
9.10.1 déchiqueter, incinérer ou réduire en pulpe les documents ;
9.10.2 éliminer, démagnétiser, déchiqueter ou détruire de toute autre manière tout support
électronique, de manière à ce que les données de titulaire de carte ne puissent être
reconstruites.
15
Surveiller et tester régulièrement les réseaux
10ème exigence : suivre et surveiller tous les accès aux ressources du réseau et aux
Les mécanismes de connexion et la capacité à suivre les activités de l’utilisateur sont critiques.
L'existence de journaux dans tous les environnements permet une analyse et un suivi complets si quoi
que ce soit tourne mal. Il est très difficile de déterminer la cause d’une atteinte à la sécurité sans journaux
d’activité du système.
10.1
10.2
10.3
10.4
10.5
10.6
Mettre en place un processus destiné à lier tous les accès à des composants du système (en
particulier un accès avec des privilèges administratifs, par exemple, de base) à chaque utilisateur
individuel.
Mettre en œuvre, pour toutes les composantes du système, des pistes d’audit automatisées afin
de reconstituer les événements ci-après :
10.2.1 tous les accès d’un utilisateur individuel aux données d’un titulaire de carte ;
10.2.2 toutes les actions effectuées par une personne jouissant d'avantages de base ou
administratifs ;
10.2.3 l'accès à toutes les pistes de vérification ;
10.2.4 les tentatives d’accès logique invalides ;
10.2 5 l'utilisation des mécanismes d’identification et d’authentification ;
10.2.6 l'initialisation des journaux de vérification ;
10.2.7 la création et la suppression d’objets de niveau système.
Enregistrer au moins les entrées de liste de piste de vérification ci-après pour l’ensemble des
composantes du système et pour chaque événement :
10.3.1 l'identification de l’utilisateur ;
10.3.2 le type d’événement ;
10.3.3 la date et le lieu ;
10.3.4 une indication de succès ou d’échec ;
10.3.5 l'origine de l’événement ;
10.3.6 l'identité ou le nom des données, composants de système ou ressources affectés.
Synchroniser toutes les horloges et heures critiques du système.
Sécuriser les piste de vérification afin qu’elles ne puissent être détruites.
10.5.1 Limiter la consultation des pistes de vérification aux personnes ayant, du fait de leurs
fonctions, besoin d’y avoir accès.
10.5.2 Protéger les fichiers des pistes de vérification des modifications non autorisées.
10.5.3 Sauvegarder promptement les fichiers des pistes de vérification sur un serveur registre
centralisé, ou un support difficile à modifier.
10.5.4 Copier les journaux relatifs aux réseaux sans fil sur un serveur registre du LAN interne.
10.5.5 Utiliser, avec les journaux, un logiciel de contrôle de l’intégrité des fichiers et de détection
des modifications, pour que les données de journal existantes ne puissent être modifiées
sans que cela n’entraîne le déclenchement d’alertes (bien que l'ajout de nouvelles
données ne déclenche en principe pas d'alertes).
Examiner les journaux pour toutes les composantes des systèmes au moins quotidiennement.
Les examens de journaux doivent englober les serveurs remplissant des fonctions de sécurité,
16
tels que les systèmes de détection d’intrusion (Intrusion Detection System, IDS) et les serveurs
authentification, d’autorisation et de protocole comptable (AAA) (par exemple, RADIUS).
Remarque : des outils d'exploitation de journal, d'analyse et d’alerte peuvent être utilisés pour
assurer la conformité à l'Exigence 10.6.
10.7
Conserver l’historique de piste de vérification durant au moins un an, avec un minimum de trois
mois de disponibilité en ligne.
17
11ème exigence : tester régulièrement les systèmes et procédures de sécurité
Des vulnérabilités sont constamment découvertes par des pirates et chercheurs et sont introduites par de
nouveaux logiciels. Les systèmes, procédés et logiciels personnalisés doivent être testés fréquemment
pour vérifier que la sécurité est assurée dans la durée, ainsi qu'en liaison avec toutes modifications du
logiciel.
11.1
11.2
11.3
11.4
11.5
Tester annuellement les contrôles de sécurité, limitations, connexions de réseau et restriction
pour assurer la capacité à identifier de manière adéquate et à bloquer toutes tentatives d’accès
non autorisé. Utiliser un analyseur sans fil au moins une fois par trimestre afin d’identifier tous les
dispositifs sans fil utilisés.
Réaliser des balayages de vulnérabilité de réseau, internes et externes, au moins une fois par
trimestre, ainsi qu’après toute modification importante du réseau (telles que l’installation de
nouvelles composantes de système, les modifications de la topologie du réseau, les
changements des règles du pare-feu, les mises à jour de produit).
Remarque : les balayages de vulnérabilité externe doivent être assurés par un prestataire agréé
par l'industrie de la carte de paiement. Les balayages réalisés après des modifications apportées
au réseau peuvent être effectués par les collaborateurs internes de la société.
Réaliser des tests de pénétration au moins une fois par an, ainsi qu’après toute modification ou
actualisation significative de l'infrastructure ou de l'application (par exemple, une mise à jour du
système d'exploitation, ou l'ajout d'un sous-réseau ou serveur Internet à l'environnement). Ces
tests de pénétration doivent inclure les suivants :
11.3.1 des tests de pénétration de couche de réseau ;
11.3.2 des tests de pénétration de couche d’application.
Utiliser des systèmes de détection d’intrusion, des systèmes de détection d’intrusion gérés par le
système central et des systèmes de prévention d'intrusion, afin de surveiller la totalité du trafic du
réseau et de prévenir le personnel en cas d'éventuelles atteintes à la sécurité. Tenir à jour tous
les moteurs de détection et de prévention d'intrusions.
Déployer un logiciel de surveillance d’intégrité de fichier afin d’alerter les personnels en cas de
modification non autorisée d’un système critique ou de fichiers de contenu ; et configurer le
logiciel pour la réalisation, au moins une fois par semaine, d'une comparaison de fichiers
critiques.
Les fichiers critiques ne sont pas nécessairement uniquement ceux qui contiennent des données
de titulaire de carte. Aux fins de surveillance de l’intégrité des fichiers, les fichiers critiques sont
d’ordinaire ceux qui ne changent pas régulièrement, mais dont la modification pourrait indiquer
une atteinte à la sécurité du système, ou un risque d’atteinte. Les produits de surveillance de
l’intégrité de fichier sont généralement livrés pré-configurés, avec les fichiers critiques pour le
système d'exploitation lié. D’autres fichiers critiques, tels que ceux se rapportant à des
applications personnalisées, peuvent être évalués et définis par l'entité (qu'il s'agisse d'un
commerçant ou d'un prestataire de services).
18
Disposer d’une politique en matière de sécurité de l’information
12ème exigence : disposer d’une politique prenant en compte la sécurité de l’information
pour les employés et sous-traitants
Une solide politique en matière de sécurité donne le ton à l’ensemble de la société et indique aux
employés ce qui est attendu d’eux. Tous les employés doivent être conscients de la sensibilité des
données et des responsabilités qui leur incombent en liaison avec leur protection.
12.1
Édicter, publier, maintenir en vigueur et diffuser une politique de sécurité correspondant aux
caractéristiques ci-après :
12.1.1 prenant en compte l’ensemble des exigences contenues dans les présentes
spécifications ;
12.1.2 comportant un processus annuel d’identification des menaces et vulnérabilités, qui
débouche sur une évaluation formelle du risque ;
12.1.3 incluant un examen au moins annuel, ainsi que des mises à jour lorsque l’environnement
change.
12.2
Développer des procédures de sécurité opérationnelles quotidiennes conformes aux exigences
des présentes spécifications (par exemple, des procédures de maintenance de compte
d’utilisateur et de vérification de journal).
12.3
Élaborer des politiques d’utilisation pour les technologies critiques d’interface avec des employés
(comme, par exemple, les modems et appareils sans fil) afin de définir une bonne utilisation de
ces technologies à l’intention de l’ensemble des employés et sous-traitants. S’assurer que ces
politiques régissant l’utilisation comportent les obligations ci-après :
12.3.1 l'accord explicite de la direction ;
12.3.2 une obligation d’authentification pour utiliser la technologie ;
12.3.3 une liste de la totalité des dispositifs et personnels disposant d’un accès ;
12.3.4 un étiquetage des appareils indiquant l’identité du propriétaire, ses coordonnées et le
but de leur utilisation ;
12.3.5 les utilisations acceptables des technologies ;
12.3.6 les emplacements de réseau acceptables pour les technologies ;
12.3.7 une liste des produits approuvés par la société ;
12.3.8 une interruption automatique de la session après une période d’inactivité spécifique ;
12.3.9 l'activation des modems fournisseurs uniquement lorsque ces derniers en ont besoin,
avec désactivation immédiate après utilisation ;
12.3.10 en cas d’accès distant aux données de titulaire de carte via modem, l’interdiction de
stocker ces données de titulaire sur disque dur local, disquette ou autre support
externe. Indisponibilité des fonctions copier/coller et d’impression lors de l’accès
distant.
12.4
Faire en sorte que les politiques et procédures en matière de sécurité définissent clairement les
responsabilités en matière de sécurité de l’information telles qu’elles s’appliquent à l’ensemble
des employés et sous-traitants.
12.5
Attribuer à un individu ou à une équipe les responsabilités ci-après en matière de gestion de la
sécurité de l'information :
12.5.1 mettre en place, consigner par écrit et diffuser les politiques et procédures en matière de
sécurité ;
19
12.5.2 surveiller et analyser les informations et alertes dans le domaine de la sécurité, et en
assurer la diffusion auprès des collaborateurs compétents ;
12.5.3 élaborer, consigner par écrit et diffuser des procédures d’intervention en cas d’incident et
de remontée des paliers de décisions en matière de sécurité, afin d’assurer une gestion
ponctuelle et efficace de toutes situations ;
12.5.4 administrer les comptes d’utilisateur, y compris tous ajouts et toutes suppressions ou
modifications ;
12.5.5 surveiller et contrôler tous les accès à des données.
12.6
Mettre en œuvre un programme formel de sensibilisation à la sécurité pour que tous les
employés soient pleinement conscients de l’importance de la sécurité des données des titulaires
de carte.
12.6.1 Former les employés lors de leur recrutement et, par la suite, au moins annuellement
(par exemple, par courrier, voie d’affichage, mémorandums, réunions et promotions).
12.6.2 Exiger les employés qu’ils reconnaissent formellement, par écrit, avoir lu et compris la
politique et les procédures de la société en matière de sécurité.
12.7
Soumettre les employés éventuels à des vérifications afin de minimiser le risque d’attaques de
sources internes.
En ce qui concerne les salariés tels que les personnels de caisse de point de vente, qui ont
seulement accès à un numéro de carte à la fois, lors de la réalisation d’une transaction, cette
exigence a uniquement valeur de recommandation.
12.8
Si des données de titulaire de carte sont communiquées à des prestataires de services, les
mesures ci-après sont impératives :
12.8.1 les prestataires de services doivent se conformer aux exigences des Normes PCI DSS ;
12.8.2 un accord comportant une attestation certifiant que le prestataire de services est
responsable de la sécurité des données de titulaire de carte en la possession du
fournisseur/prestataire.
12.9
Mettre en œuvre un plan d’intervention en cas d’incident. Être prêt à intervenir sur-le-champ en
cas de violation de la sécurité du système.
12.9.1 Élaborer le plan d’intervention en cas d’incident destiné à être appliqué lors d’une atteinte
à la sécurité du système. Faire en sorte que le plan prenne en compte, au moins, les
procédures spécifiques d’intervention en cas d’incident, de reprise et de continuité de
l’activité, de sauvegarde, les rôles et responsabilités, ainsi que les stratégies de
communication et de contact (par exemple, en informant les Acquéreurs et les
associations de carte de crédit).
12.9.2 Tester le plan au moins une fois par an.
12.9.3 Désigner des collaborateurs spécifiques, qui devront être disponibles 24 heures sur 24, 7
jours sur 7, pour répondre aux alertes.
12.9.4 Fournir une formation appropriée aux collaborateurs en charge de l’intervention en cas
d’atteinte à la sécurité.
12.9.5 Inclure les alertes suite à une détection d’intrusion, de prévention d’intrusion et des
systèmes de surveillance de l’intégrité des fichiers.
12.9.6 Développer des processus de modification et d’évolution du plan d'intervention en cas
d’incident, en fonction des leçons apprises, ainsi que dans le but de tenir compte des
évolutions du secteur.
12.10 Toutes les entités de traitement et prestataires de services doivent disposer de, et appliquer des
politiques et procédures de gestion d’entités liées incluant ce qui suit :
12.10.1. gérer une liste d’entités liées ;
20
12.10.2. faire en sorte qu’une vérification préalable soit effectuée avant la connexion de toute
entité ;
12.10.3. s’assurer que l’entité est conforme aux Normes PCI DSS ;
12.10.4. connecter et déconnecter les entités conformément à une procédure établie.
21
Annexe A : Application des normes PCI DSS des fournisseurs d’hébergement
Exigence A.1 : les fournisseurs d’hébergement protègent l’environnement des données de
titulaire de carte
Comme indiqué dans l’Exigence 12.8, tous prestataires de service disposant d’un accès à des données de
titulaire de carte (y compris les fournisseurs d’hébergement) doivent se conformer aux Normes PCI DSS. En
outre, l’Exigence 2.4 prévoit que les fournisseurs d’hébergement doivent protéger l’environnement et les
données hébergés de chaque entité. De ce fait, ils doivent accorder une attention particulière aux aspects
suivants :
A.1
Protéger les données et l’environnement hébergés de chaque entité (qu’il s’agisse d’un commerçant,
d’un prestataire de services ou de toute autre entité), comme indiqué dans les points A.1.1 à A.1.4 :
A.1.1 faire en sorte que chaque entité ait uniquement accès à l’environnement de données de son
propre titulaire de carte ;
A.1.2 limiter l’accès et les privilèges de chaque entité exclusivement à l’environnement de données
de son propre titulaire de carte ;
A.1.3 faire en sorte que les pistes de connexion et de vérification soient activées et uniques à
l’environnement de données de titulaire de carte de chaque entité, et conformément à
l'Exigence 10 des Normes PCI DSS ;
A.1.4 mettre en place des processus destinés à permettre des investigations technico-légales
ponctuelles en cas d'atteinte à la sécurité d'une entité marchande ou d'un prestataire de
services hébergé.
Un fournisseur hébergé doit se conformer à ces obligations, ainsi qu’à toutes autres sections pertinentes des
Normes PCI DSS. Remarque : même s'il est possible qu'un fournisseur d'hébergement se conforme à ces
exigences, la conformité de l'entité utilisant le fournisseur d'hébergement n’est pas nécessairement garantie.
Chaque entité doit impérativement se conformer aux Normes PCI DSS et, le cas échéant, valider la conformité.
Payment Card Industry (PCI) Data Security Standard v 1.1
22
Annexe B : Contrôles correctifs
Contrôles correctifs – Dispositions générales
Des contrôles correctifs peuvent être envisagés en liaison avec la plupart des exigences des Normes PCI DSS,
lorsqu’une entité n’est pas en mesure de se conformer aux spécifications techniques relatives à une exigence,
mais a suffisamment atténué le risque associé. Pour la définition complète des contrôles correctifs, voir le
Glossaire des Normes PCI DSS.
L’efficacité d’un contrôle correctif est fonction des spécificités de l’environnement dans lequel le contrôle de
sécurité est réalisé, des contrôles de sécurité environnants et de la configuration du contrôle. Les sociétés
doivent savoir qu’un contrôle correctif donné ne saurait être efficace dans tous les environnements. Chaque
contrôle correctif doit donner lieu à une évaluation approfondie après sa mise en œuvre, afin d’en garantir
l’efficacité.
Les principes directeurs ci-après prévoient des contrôles correctifs lorsque les sociétés ne sont pas en mesure
de rendre illisibles les données de titulaire de carte, conformément aux dispositions de l’exigence 3.4.
Contrôles correctifs afférents à l’Exigence 3.4.
Lorsqu’une société n’est pas en mesure de rendre illisible des données de titulaire de carte (par exemple, par
cryptage) en raison de contraintes techniques ou de limitations commerciales, des contrôles correctifs pourront
être envisagés. Seules les sociétés ayant entrepris une analyse de risque et soumises à des contraintes
technologiques ou commerciales documentées légitimes peuvent envisager le recours à des contrôles correctifs
aux fins de mise en conformité.
Les sociétés envisageant de recourir à des contrôles correctifs dans le but de rendre illisibles les données de
titulaire de carte doivent comprendre les risques constitués par la conservation de données de titulaire de carte
lisibles. De manière générale, les contrôles doivent fournir une protection supplémentaire dans le but d’atténuer
tous risques supplémentaires liés à la conservation de données de titulaire de carte lisibles. Les contrôles
envisagés doivent être en plus de ceux prévus par les Normes PCI DSS et doivent être conformes à la définition
des « Contrôles correctifs » contenue dans le Glossaire des Normes PCI DSS. Les contrôles correctifs peuvent
inclure un dispositif, ou une combinaison de dispositifs, d’applications et de commandes remplissant toutes les
conditions ci-après :
1. assurer une segmentation/abstraction supplémentaire (par exemple, au niveau de la couche de
réseau) ;
2. offrir l’aptitude à limiter l’accès aux données de titulaire de carte ou aux bases de données, sur la base
des critères suivants :
• adresses Internet/MAC ;
• application/service ;
• comptes/groupes d’utilisateur ;
• type de données (filtre dynamique à paquets) ;
3. limiter l’accès logique à la base de données ;
• accès par contrôle logiciel à la base de données indépendante d’Active Directory ou de Lightweight
Directory Access Protocol (LDAP) ;
4. prévenir/détecter les attaques courantes contre des applications ou bases de données (par exemple,
injection de commandes SQL).
Payment Card Industry (PCI) Data Security Standard v 1.1
23

En savoir plus

Transcription

Documents pareils

VigiTrust PCI DSS Paris Roadshow 2015

Télécharger le formulaire d`inscription au Challenge (PDF

aureon5.1pci

Carte Réseau PCI Express à 1 port Gigabit Ethernet

magasin de pièces détachées d`occasion

Circulaire mouvement - 2010-2011

Adoption de la composition de la Commission - CCI

Fiche technique du Mac Pro Nv

PMM159

commune de le soler - Centre de Gestion des Pyrénées Orientales

Plaquette BAC PRO SPVL