Navigation dans la norme PCI DSS v2.0

Transcription

Payment Card Industry (PCI)
Data Security Standard
Navigation dans la norme PCI DSS
Comprendre l'objectif des conditions
Version 2.0
Octobre 2010
Modifications apportées au document
Date
Version
Description
1er Octobre 2008
1.2
Harmonisation du contenu avec la nouvelle procédure PCI DSS v1.2 et implémentation des
changements mineurs notés depuis la v1.1 d'origine.
28 Octobre 2010
2.0
Harmonisation du contenu avec la nouvelle norme PCI DSS v2.0
Navigation dans la norme PCI DSS : comprendre l'objectif des conditions v2.0
Copyright 2010 PCI Security Standards Council LLC
Octobre 2010
Page 2
Table des matières
Modifications apportées au document..............................................................................................................................2
Préambule............................................................................................................................................................................4
Virtualisation ............................................................................................................................................................................................................ 5
Éléments de données de titulaires de cartes et de données d'authentification sensibles...........................................6
Emplacement des données de titulaires de cartes et des données d'authentification sensibles............................................................................ 8
Données de piste 1 et de piste 2 ............................................................................................................................................................................. 9
Directives relatives à la norme PCI DSS .........................................................................................................................10
Directives relatives aux conditions 1 et 2 : création et gestion d’un réseau sécurisé................................................11
Condition 1 : Installer et gérer une configuration de pare-feu pour protéger les données des titulaires de cartes .............................................. 11
Condition 2 : Ne pas utiliser les mots de passe système et autres paramètres de sécurité par défaut définis par le fournisseur ....................... 17
Directives relatives aux conditions 3 et 4 : Protection des données des titulaires de cartes de crédit ....................20
Condition 3 : Protéger les données de titulaires de cartes stockées .................................................................................................................... 20
Condition 4 : Crypter la transmission des données des titulaires de cartes sur les réseaux publics ouverts....................................................... 28
Directives relatives aux exigences 5 et 6 : Gestion d’un programme de gestion des vulnérabilités ........................30
Condition 5 : Utiliser des logiciels antivirus et les mettre à jour régulièrement ..................................................................................................... 30
Condition 6 : Développer et gérer des systèmes et des applications sécurisés ................................................................................................... 32
Directives relatives aux conditions 7, 8 et 9 : Mise en œuvre de mesures de contrôle d’accès strictes ..................40
Condition 7 : Restreindre l'accès aux données des titulaires de cartes aux seuls individus qui doivent les connaître ........................................ 40
Condition 8 : Affecter un ID unique à chaque utilisateur d’ordinateur ................................................................................................................... 42
Condition 9 : Restreindre l’accès physique aux données des titulaires de cartes ................................................................................................ 47
Directives relatives aux conditions 10 et 11 : Surveillance et test réguliers des réseaux..........................................51
Condition 10 : Effectuer le suivi et surveiller tous les accès aux ressources réseau et aux données des titulaires de cartes............................. 51
Condition 11 : Tester régulièrement les processus et les systèmes de sécurité .................................................................................................. 55
Directives relatives à la condition 12 : Gestion d’une politique de sécurité des informations ..................................61
Condition 12 : Gérer une politique de sécurité des informations pour l'ensemble du personnel .......................................................................... 61
Directives relatives à la condition A.1 : Autres conditions de la norme PCI DSS s’appliquant aux fournisseurs
d’hébergement partagé………………………….................................................................................................................67
Annexe A :
Norme de sécurité des données PCI : documents connexes................................................................69
Octobre 2010
Page 3
Préambule
Le présent document décrit les 12 conditions de la norme de sécurité des données du secteur des cartes de paiement (PCI DSS), en explique les
objectifs et fournit des directives. Ce document est destiné à aider les commerçants, les prestataires de services et les institutions financières qui
souhaitent comprendre clairement la norme PCI DSS, la signification et l'intention des conditions détaillées de protection des composants de
système (serveurs, réseau, applications, etc.) qui prennent en charge les environnements des données des titulaires de cartes.
REMARQUE : le document « Navigation dans la norme PCI DSS : comprendre l'objectif des conditions » est fourni à titre indicatif
seulement. Pour une évaluation PCI DSS sur site ou remplir un questionnaire d'auto-évaluation, se reporter aux Conditions et
procédures d’évaluation de sécurité de la norme PCI DSS et aux Questionnaires d'auto-évaluation PCI DSS.
Les conditions de la norme PCI DSS s'appliquent à tous les composants du système. Dans le cadre de la norme PCI DSS, les « composants du
système » désignent tout composant réseau, serveur ou application inclus dans, ou connectés à, l’environnement des données des titulaires de
cartes. Les « composants du système » comprennent également tous les composants de virtualisation comme les machines,
commutateurs/routeurs, outils, applications/bureaux virtuels ainsi que les hyperviseurs. L'environnement des données de titulaires de cartes est
constitué d'individus, de processus et de technologies qui gèrent les données de titulaires de cartes ou des données sensibles d'authentification.
Les composants réseau comprennent notamment les pare-feu, les commutateurs, les routeurs, les points d’accès sans fil, les
équipements réseau et d'autres appareils de sécurité.
Les types de serveur comprennent, sans s'y limiter : les serveurs Web, d’application, de base de données, d’authentification, de
messagerie, proxy, NTP (Network Time Protocol) et DNS (Domain Name Server).
Les applications comprennent toutes les applications achetées et personnalisées, notamment les applications internes et externes (par
exemple Internet).
La première étape d'une évaluation PCI DSS est de correctement déterminer le champ d'application de la vérification. Au moins une fois par an, et
avant l'évaluation annuelle, l'entreprise évaluée doit confirmer l'exactitude de son champ d'application PCI DSS en identifiant tous les
emplacements et flux des données de titulaires de cartes et s'assurer qu'ils sont compris dans le champ d'application. Pour confirmer l'exactitude
et l'adéquation du champ d'application PCI DSS, procéder comme suit :
L'entreprise évaluée identifie et documente l'existence de toutes les données de titulaires de cartes dans son environnement, afin de
vérifier qu'aucune donnée n'existe en dehors de l'environnement de titulaires de cartes (CDE) actuellement défini.
Une fois tous les emplacements de données de titulaires de cartes identifiés et documentés, l'entreprise utilise les résultats pour vérifier
que le champ d'application PCI DSS est approprié (par exemple, les résultats peuvent être un diagramme ou un inventaire des
emplacements des données de titulaires de cartes).
L'entreprise tient compte des données de titulaires de cartes qui se trouvent dans le champ d'application de l'évaluation PCI DSS et font
partie du CDE, sauf si lesdites données sont supprimées ou transférées/regroupées dans le CDE actuellement défini.
L'entreprise conserve la documentation montrant comment le champ d'application PCI DSS a été confirmé et les résultats, pour l'examen
de l'évaluateur et/ou pour référence au cours de l'activité annuelle de confirmation du champ d'application PCI DSS.
Octobre 2010
Page 4
La segmentation réseau, ou isolation, de l’environnement des données des titulaires de cartes par rapport au reste du réseau de l’entreprise n’est
pas une condition de la norme PCI DSS. Elle est cependant vivement recommandée comme méthode pour réduire le champ d'application de
l’environnement des données des titulaires de cartes. Un évaluateur de sécurité qualifié (QSA) peut aider à déterminer le champ d'application au
sein de l'environnement des données de titulaires de cartes d'une entreprise et à réduire celui d'une évaluation PCI DSS en appliquant une
segmentation réseau appropriée.
En cas de questions concernant la compatibilité ou la conformité d'une application spécifique à la norme, ou à une condition en particulier, le PCI
SSC recommande aux sociétés de consulter un QSA pour valider leur mise en œuvre de la technologie et des processus, ainsi que leur
conformité à la norme PCI DSS. Grâce à son expérience des environnements réseau complexes, l'évaluateur est à même de recommander les
meilleures pratiques et de conseiller le commerçant ou le prestataire de services pour se conformer aux normes. La liste des évaluateurs de
sécurité qualifiés du PCI SSC est disponible sur : https://www.pcisecuritystandards.org.
Virtualisation
Si la virtualisation est mise en œuvre, tous les composants au sein de l'environnement virtuel devront être identifiés et pris en compte dans le
champ d'application de l'évaluation, y compris les hôtes virtuels individuels ou les dispositifs, les ordinateurs invités, les applications, les interfaces
de gestion, les consoles de gestion centrale, les hyperviseurs, etc. Tous les flux de données et les communications au sein de l'hôte doivent être
identifiés et documentés, de même que ceux existant entre le composant virtuel et les autres composants du système.
La mise en œuvre d'un environnement virtuel doit remplir l'objectif de toutes les conditions, afin que les systèmes virtualisés puissent être
effectivement considérés comme un matériel distinct. Par exemple, il doit exister une claire segmentation des fonctions et une séparation des
réseaux de différents niveaux de sécurité. La segmentation doit empêcher le partage des environnements de production et de
test/développement. La configuration virtuelle doit être sécurisée de sorte que les vulnérabilités d'une fonction ne puissent affecter la sécurité des
autres fonctions. D'autre part, l'ensemble des instances virtuelles ne doivent pas pouvoir accéder aux dispositifs annexes, comme les
périphériques série/USB.
En outre, tous les protocoles d'interface de gestion virtuelle doivent être inclus dans la documentation du système, et les rôles et les autorisations
doivent être définis pour gérer les réseaux et composants de système virtuels. Les plates-formes de virtualisation doivent avoir la capacité
d'appliquer la séparation des tâches et des privilèges, afin de séparer la gestion de réseau virtuel de celle du serveur virtuel.
Un soin particulier est également nécessaire pour la mise en œuvre de contrôles d'authentification afin de garantir que les utilisateurs
s'authentifient auprès des composants de système virtuels appropriés et de distinguer les ordinateurs virtuels invités de l'hyperviseur.
Octobre 2010
Page 5
Éléments de données de titulaires de cartes et de données d'authentification
sensibles
La norme PCI DSS s'applique partout où des données de compte sont stockées, traitées ou transmises. Les données de compte regroupent les
données du titulaires de cartes plus les données d'authentification sensibles, indiquées ci-dessous :
Les données du titulaires de cartes
comprennent :
•
•
•
•
Numéro de compte primaire (PAN)
Nom du titulaire de la carte
Date d'expiration
Code service
Les données d'authentification
sensibles comprennent :
•
•
•
Données de bande magnétique
complètes ou leur équivalent sur une
puce
CAV2/CVC2/CVV2/CID
Codes/blocs PIN
Le numéro de compte primaire est le facteur déterminant de l'applicabilité des conditions PCI DSS. Les conditions PCI DSS sont
applicables si un PAN est stocké, traité ou transmis. Si le PAN n'est pas stocké, traité ni transmis, les conditions PCI DSS ne s'appliquent pas.
Si le nom du titulaire de carte, le code de service, et/ou la date d'expiration sont stockés, traités ou transmis avec le PAN, ou existent d'une façon
ou d'une autre dans l'environnement des données des titulaires de cartes, ils doivent être protégés conformément à toutes les conditions PCI DSS
sauf les conditions 3.3 et 3.4, qui s'appliquent uniquement au PAN.
La norme PCI DSS représente un ensemble minimum d'objectifs de contrôle qui peut être renforcé par des lois et règlements locaux, régionaux
ou sectoriels. En outre, la législation ou la réglementation peuvent exiger une protection spécifique des informations personnelles identifiables ou
d'autres éléments de données (par exemple, le nom du titulaires de cartes), ou définir les pratiques de divulgation d'une entité, relatives aux
informations concernant le consommateur. La législation relative à la protection des données des consommateurs, à la confidentialité, au vol
d'identité, ou à la sécurité des données en est un exemple. Le PCI DSS ne supplante pas les lois locales ou régionales, réglementations
gouvernementales ou autres obligations légales.
Le tableau suivant illustre les éléments courants des données des titulaires de cartes et des données 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 est présenté de manière à illustrer les différentes conditions qui s'appliquent à chaque élément de données.
Octobre 2010
Page 6
Stockage
autorisé
Rendre illisibles les
données de compte
stockées selon la
condition 3.4
Numéro de compte primaire
(PAN)
Oui
Oui
Nom du titulaire de la carte
Oui
Non
Code service
Oui
Non
Date d'expiration
Oui
Non
Données complètes de la bande
2
magnétique
Non
Stockage interdit selon
condition 3.2
CAV2/CVC2/CVV2/CID
Non
condition 3.2
Code/bloc PIN
Non
condition 3.2
Données de compte
Élément de données
Données du
titulaire de la
carte
Données
d'authentification
1
sensibles
Les conditions 3.3 et 3.4 de la norme PCI DSS ne s'appliquent qu'au PAN. Si le PAN est stocké avec d'autres données du titulaires de cartes, seul
le PAN doit être rendu illisible selon la condition 3.4 de la norme PCI DSS.
La norme PCI DSS s'applique uniquement si les PAN sont stockés, traités et/ou transmis.
1
2
Une fois le processus d’autorisation terminé, les données d'authentification sensibles ne doivent plus être stockées (même si elles sont cryptées).
Données de piste complètes extraites de la bande magnétique, données équivalentes de la puce, ou d'un autre support.
Octobre 2010
Page 7
Emplacement des données de titulaires de cartes et des données d'authentification sensibles
3
Les données d'authentification sensibles correspondent aux données de la bande magnétique (ou piste) , au code ou à la valeur de validation de
4
5
la carte , et les données PIN . Le stockage des données d'authentification sensibles n'est pas autorisé ! Ces données sont précieuses pour
les individus malveillants car elles leur permettent de créer de fausses cartes de paiement et de procéder à des transactions frauduleuses. Voir le
Glossaire des termes, abréviations et acronymes PCI DSS et PA-DSS pour la définition complète des « données d'authentification sensibles ».
Les illustrations du recto et du verso d'une carte de crédit ci-dessous, montrent l'emplacement des données du titulaire de carte et des données
d'authentification sensibles.
Remarque : la puce contient des données équivalentes aux données de piste ainsi que d'autres données sensibles, notamment la valeur de
vérification de carte à puce à circuit intégré (également appelée puce CVC, iCVV, CAV3 or iCSC).
3
4
5
Données codées sur la bande magnétique utilisée pour une autorisation lors d’une transaction en carte présente. Ces données peuvent également se trouver sur une puce ou
ailleurs sur la carte. Les entités ne peuvent pas conserver l’ensemble des données sur bande magnétique après autorisation des transactions. Les seuls éléments de données de
piste pouvant être conservés sont le numéro de compte primaire, le nom du titulaire de carte, la date d'expiration et le code de service.
La valeur à trois ou quatre chiffres imprimée sur l’espace réservé à la signature ou à droite de celui-ci ou sur le verso d’une carte de paiement, utilisée pour vérifier les transactions
en carte absente.
Les données PIN (Personal Identification Number, numéro d’identification personnel) saisies par le titulaire de la carte lors d’une transaction carte présente et/ou le bloc PIN crypté
présent dans le message de la transaction.
Octobre 2010
Page 8
Données de piste 1 et de piste 2
Si les données complètes de piste (piste 1 ou piste 2, de la bande magnétique, image de la bande magnétique sur une puce, ou autre) étaient
stockées, les individus malveillants qui parviendraient à se les procurer pourraient reproduire et vendre des cartes de paiement dans le monde
entier. Le stockage de données de piste complètes enfreint également les réglementations sur les activités des marques de cartes de paiement et
peut donner lieu à des amendes et pénalités. L'illustration ci-dessous fournit des informations sur les données de piste 1 et piste 2, décrivant leurs
différences et la manière dont elles sont stockées sur la bande magnétique.
Piste 1
Contient tous les champs des deux pistes, 1 et 2
Jusqu'à 79 caractères de longueur
Piste 2
Temps de traitement plus court pour les anciennes
transmissions par accès commuté
Jusqu'à 40 caractères de longueur
Remarque : les champs de données discrétionnaires sont définis par l'émetteur de la carte et/ou la marque de carte de paiement. Les champs
définis par l'émetteur contiennent des données qui ne sont pas considérées comme des données d'authentification sensibles par l'émetteur/la
marque de carte de paiement et qui peuvent être incluses dans la portion des données discrétionnaires de la piste, et il peut être légitime de
stocker ces données particulières dans des circonstances et sous des conditions spécifiques, déterminées par l'émetteur et/ou la marque de carte
de paiement.
Toute donnée considérée comme une donnée d'authentification sensible, qu'elle se trouve sur un champ de données discrétionnaires ou ailleurs,
ne doit toutefois pas être stockée après autorisation.
Octobre 2010
Page 9
Directives relatives à la norme PCI DSS
Création et gestion d’un réseau sécurisé
Condition 1 :
Installer et gérer une configuration de pare-feu pour protéger les données des titulaires de cartes
Condition 2 :
Ne pas utiliser les mots de passe système et autres paramètres de sécurité par défaut définis par le
fournisseur
Protection des données des titulaires de cartes de crédit
Condition 3 :
Protéger les données de titulaires de cartes stockées
Condition 4 :
Crypter la transmission des données des titulaires de cartes sur les réseaux publics ouverts
Gestion d’un programme de gestion des vulnérabilités
Condition 5 :
Utiliser des logiciels ou des programmes antivirus et les mettre à jour régulièrement
Condition 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
Condition 7 :
Restreindre l'accès aux données des titulaires de cartes aux seuls individus qui doivent les connaître
Condition 8 :
Affecter un ID unique à chaque utilisateur d’ordinateur
Condition 9 :
Restreindre l’accès physique aux données des titulaires de cartes
Surveillance et test réguliers des réseaux
Condition 10 :
Effectuer le suivi et surveiller tous les accès aux ressources réseau et aux données des titulaires de cartes
Condition 11 :
Tester régulièrement les processus et les systèmes de sécurité
Gestion d’une politique de sécurité des informations
Condition 12 :
Gérer une politique de sécurité des informations pour l'ensemble du personnel
Octobre 2010
Page 10
Directives relatives aux conditions 1 et 2 : création et gestion d’un réseau sécurisé
Condition 1 : Installer et gérer une configuration de pare-feu pour protéger les données des titulaires de cartes
Les pare-feu sont des dispositifs qui contrôlent le trafic autorisé entre le réseau d'une entreprise (interne) et les réseaux non approuvés (externes),
ainsi que le trafic entrant et sortant dans des zones plus sensibles du réseau approuvé interne d’une société. L’environnement des données des
titulaires de cartes est un exemple de zone plus sensible au sein du réseau approuvé d’une entreprise.
Un pare-feu examine l'ensemble du trafic réseau et bloque les transmissions qui ne satisfont pas aux critères de sécurité définis.
Tous les systèmes doivent être protégés contre les accès non autorisés depuis un réseau non approuvé, que ce soit en entrée via Internet (par
exemple e-commerce, accès des employés à Internet à partir de leurs navigateurs, accès des employés à la messagerie électronique, connexions
dédiées telles que les connexions interentreprises) ou bien via les réseaux sans fil ou d’autres sources. Les chemins d’accès de/vers des réseaux
non approuvés, en apparence insignifiants, peuvent souvent constituer des chemins d’accès non protégés à des systèmes critiques. Les pare-feu
sont des mécanismes de protection essentiels sur tout réseau informatique.
D'autres composants du système peuvent assurer une fonctionnalité pare-feu, à condition de remplir les conditions minimum des pare-feu
indiquées dans la condition 1. Lorsque d'autres composants du système sont utilisés dans l'environnement des données de titulaires de cartes
pour assurer une fonctionnalité pare-feu, ces dispositifs doivent être inclus dans le champ d'application de l'évaluation de la condition 1.
Condition
Directive
1.1 Définir des normes de configuration des pare-feu et des
routeurs incluant les éléments suivants :
Les pare-feu et les routeurs sont les composants essentiels de l'architecture
contrôlant les entrées et les sorties d'un réseau. Il s'agit de dispositifs logiciels ou
matériels qui bloquent les accès indésirables et gèrent l'accès autorisé vers et hors
du réseau. Sans la mise en place de politiques et de procédures documentant la
manière dont le personnel doit configurer les pare-feu et les routeurs, une
entreprise pourrait facilement perdre sa première ligne de défense en matière de
protection des données. Ces politiques et procédures lui permettront de conserver
une première ligne de défense robuste.
Les environnements virtuels où les flux de données ne transitent pas par un
réseau physique doivent être évalués afin de garantir que la segmentation du
réseau est réalisée de la manière appropriée.
1.1.1 Processus formel d'approbation et de test de toutes les
connexions réseau et des modifications apportées aux
configurations des pare-feu et des routeurs
Une politique et un processus d'approbation et de test de toutes les connexions et
des modifications apportées aux configurations des pare-feu et des routeurs
permettront d'éviter les problèmes de sécurité dus aux erreurs de configuration du
réseau, du routeur ou du pare-feu.
Cette politique et ce processus doivent également englober les flux de données
entre ordinateurs virtuels.
Octobre 2010
Page 11
Condition
1.1.2 Schéma de réseau actuel indiquant toutes les connexions
aux données des titulaires de cartes, notamment tous les
réseaux sans fil
Directive
Les schémas de réseau permettent à l'entreprise d'identifier l'emplacement de tous
ses périphériques réseau. En outre, ce schéma peut servir au mappage des flux
des données de titulaires de cartes à travers le réseau et entre les dispositifs
individuels, afin de bien comprendre le champ d'application de l'environnement des
données de titulaires de cartes. Sans les schémas de réseau et des flux de
données en cours, les dispositifs comprenant des données de titulaires de cartes
peuvent être négligés et échapper sans le savoir aux contrôles de sécurité mis en
place dans le cadre de la norme PCI DSS, et par conséquent être très vulnérables.
Les schémas de réseau et des flux de données doivent comprendre les
composants du système virtuel et indiquer les flux de données au sein de l'hôte.
1.1.3 Exigence d’un pare-feu au niveau de chaque connexion
Internet et entre toute zone démilitarisée (DMZ) et la zone de
réseau interne
L'utilisation d'un pare-feu sur chaque connexion entrante (et sortante) du réseau
permet à l'entreprise de surveiller et de contrôler les accès entrants et sortants, et
de réduire les risques qu'un individu malveillant parvienne à accéder au réseau
interne.
1.1.4 Description des groupes, des rôles et des responsabilités
pour la gestion logique des composants réseau
Cette description des rôles et des responsabilités garantit qu'une personne est
clairement désignée comme responsable de la sécurité de tous les composants et
en a parfaitement conscience, et qu'aucun appareil n'y échappe.
1.1.5 Documentation et justification professionnelle de
l’utilisation de tous les services, protocoles et ports autorisés, y
compris la documentation des fonctions de sécurité mises en
œuvre pour les protocoles considérés comme étant non
sécurisés.
Les protocoles FTP, Telnet, POP3, IMAP et SNMP sont des
exemples de services, protocoles ou ports non sécurisés, mais
ne sont pas les seuls.
Les risques sont souvent dus à la présence de services et de ports non utilisés ou
non sécurisés, dont les vulnérabilités sont souvent connues. De nombreuses
entreprises sont vulnérables à ces types de risques car elles n'appliquent pas les
correctifs de sécurité aux services, protocoles et ports qu'elles n'utilisent pas
(même si les vulnérabilités existent bien). Chaque entreprise doit clairement
déterminer les services, les protocoles et les ports nécessaires à la conduite de
ses activités, les consigner dans ses archives et veiller à ce que tous les autres
services, protocoles et ports soient désactivés ou supprimés. Les entreprises
doivent également envisager de bloquer l'ensemble du trafic et de ne rouvrir ces
ports qu'une fois le besoin déterminé et documenté.
En outre, nombreux sont les services, protocoles ou ports dont une entreprise peut
avoir besoin (ou qui ont été activés par défaut), qui sont fréquemment utilisés par
les individus malveillants pour compromettre un réseau. Si ces services,
protocoles ou ports non sécurisés sont nécessaires à l'entreprise, le risque
inhérent à l'utilisation de ces protocoles doit être clairement compris et admis par
l'entreprise. L'utilisation du protocole doit être justifiée et les fonctions de sécurité
permettant son utilisation sécurisée doivent être documentées et appliquées. Si
ces services, protocoles ou ports non sécurisés ne sont pas nécessaires à
l'entreprise, ils doivent être désactivés ou supprimés.
Octobre 2010
Page 12
Condition
1.1.6 Nécessité d’examiner les règles des pare-feu et des
routeurs au moins tous les six mois
Directive
Cet examen donne à l'entreprise une occasion, au moins tous les six mois,
d'éliminer les règles superflues, obsolètes ou incorrectes, et de s'assurer que
toutes les règles n'admettent que les services et les ports autorisés
correspondants aux besoins de l'activité.
Il est recommandé d'effectuer ces examens plus souvent, par exemple une fois
par mois, pour s'assurer que les règles prévalent et satisfont aux besoins de
l'entreprise, sans ouvrir de brèche de sécurité ni courir de risques inutiles.
1.2 Créer une configuration de pare-feu qui limite les connexions
entre les réseaux non approuvés et tous les composants du
système dans l’environnement des données des titulaires de
cartes.
Remarque : un « réseau non approuvé » est tout réseau externe
aux réseaux appartenant à l’entité sous investigation et/ou qui
n’est pas sous le contrôle ou la gestion de l’entité.
1.2.1 Restreindre le trafic entrant et sortant au trafic nécessaire
à l’environnement des données des titulaires de cartes.
Il est essentiel d'installer une protection réseau, à savoir un composant réseau
avec, au minimum, une capacité pare-feu avec contrôle d'état, entre le réseau
approuvé interne et tout autre réseau non approuvé externe et/ou échappant au
contrôle ou à la gestion de l'entreprise. Si cette mesure n'est pas correctement
mise en place, le réseau de l'entreprise sera exposé au risque d'intrusion
d'individus ou de logiciels malveillants.
Si un pare-feu est installé mais ne comporte pas de règles contrôlant ou limitant
certains trafics, des individus malveillants peuvent toujours être en mesure
d'exploiter les protocoles et les ports vulnérables pour attaquer le réseau.
Cette condition est destinée à empêcher les individus malveillants de pénétrer le
réseau de l'entreprise par le biais d'adresses IP non autorisées, ou d'utiliser des
services, protocoles ou ports de manière non autorisée (par exemple, pour
transmettre des données obtenues sur le réseau vers un serveur non approuvé).
Tous les pare-feu doivent comprendre une règle refusant tout trafic entrant ou
sortant qui ne soit pas spécifiquement nécessaire. Cela évitera les brèches par
négligence pouvant permettre l'entrée et la sortie d'un trafic malveillant, indésirable
ou autre.
1.2.2 Sécuriser et synchroniser les fichiers de configuration des
routeurs.
Bien que les fichiers de configuration d'exécution soient généralement mis en
place avec des paramètres sécurisés, les fichiers de démarrage (les routeurs
n'exécutant ces fichiers qu'au redémarrage) peuvent ne pas disposer de ces
mêmes paramètres sécurisés, en raison de leur exécution occasionnelle.
Lorsqu'un routeur redémarre sans les mêmes paramètres sécurisés que ceux des
fichiers de configuration d'exécution, cela peut entraîner un affaiblissement des
règles dont un individu malveillant peut profiter pour s'introduire dans le réseau, en
raison du manque de protection des fichiers de démarrage.
Octobre 2010
Page 13
Condition
1.2.3 Installer des pare-feu de périmètre entre tous les réseaux
sans fil et l’environnement des données des titulaires de cartes,
et configurer ces pare-feu pour refuser ou contrôler le trafic (si
celui-ci est nécessaire à des fins professionnelles) de
l’environnement sans fil vers l’environnement des données des
titulaires de cartes.
Directive
La mise en œuvre et l'exploitation connues (ou inconnues) de la technologie sans
fil sur un réseau sont souvent la voie qu'utilisent les individus malveillants pour
accéder au réseau et aux données des titulaires de cartes. Si un périphérique ou
un réseau sans fil est installé à l'insu d'une entreprise, un individu malveillant peut
facilement s'introduire dans le réseau sans être détecté. Si les pare-feu ne
restreignent pas l'accès à l'environnement des cartes de paiement par des réseaux
sans fil, les individus malveillants qui accèdent au réseau sans autorisation
peuvent facilement se connecter à cet environnement et compromettre les
informations de comptes.
Des pare-feu doivent être installés entre tous les réseaux sans fil et
l'environnement des données de titulaires de cartes, indépendamment de l'objectif
de l'environnement auquel le réseau sans fil est connecté. Ceci peut inclure, sans
s'y limiter, les réseaux d'entreprise, les magasins de détails, les environnements
d'entrepôt, etc.
1.3 Interdire l’accès public direct entre Internet et tout composant
du système dans l’environnement des données des titulaires de
cartes.
L'objectif d'un pare-feu est de gérer et contrôler toutes les connexions entre les
systèmes publics et les systèmes internes (en particulier ceux qui stockent, traitent
et transmettent des données de titulaires de cartes). Si un accès direct est autorisé
entre les systèmes publics et l'environnement des données de titulaire de carte,
les protections assurées par le pare-feu sont contournées et les composants du
système stockant les données de titulaires de cartes peuvent être compromis.
1.3.1 Déployer une zone démilitarisée pour limiter le trafic
entrant aux seuls composants du système fournissant des
services, protocoles et ports autorisés, accessibles au public.
La zone démilitarisée est la partie du réseau qui gère les connexions entre Internet
(ou tout autre réseau non approuvé) et les services internes qu'une entreprise doit
mettre à la disposition du public (comme un serveur Web). Il s'agit de la première
ligne de défense pour isoler et séparer le trafic qui doit communiquer avec le
réseau interne de ceux qui n'y sont pas autorisés.
Cette fonction est destinée à empêcher des individus malveillants d'accéder au
réseau de l'entreprise par le biais d'adresses IP non autorisées ou d'utiliser des
services, des protocoles ou des ports de manière non autorisée.
1.3.2 Limiter le trafic Internet entrant aux adresses IP dans la
zone démilitarisée.
Le fait que les connexions IP aboutissent à la zone démilitarisée permet
d'inspecter et de restreindre la source/destination et/ou d'inspecter/bloquer le
contenu, empêchant ainsi un accès non filtré entre environnements approuvés et
non approuvés.
1.3.3 N’autoriser aucune connexion directe entrante ou sortante
de trafic entre Internet et l’environnement des données des
L'aboutissement des connexions IP entrantes et sortantes à cette zone permet
d'inspecter et de restreindre la source/destination et/ou d'inspecter/bloquer le
contenu, empêchant ainsi un accès non filtré entre environnements approuvés et
non approuvés. Ceci permet, par exemple, d'empêcher des individus malveillants
d'acquérir des données au sein du réseau de l'entreprise, et de les envoyer à un
serveur externe non approuvé d'un réseau qui ne l'est pas non plus.
Octobre 2010
Page 14
Condition
1.3.4 Ne pas autoriser le passage des adresses internes
d’Internet dans la zone démilitarisée.
Directive
Un paquet contient normalement l'adresse IP de l'ordinateur à l'origine de l'envoi.
Ceci permet aux autres ordinateurs connectés au réseau de savoir d'où provient le
paquet. Dans certains cas, cette adresse IP d'expédition est usurpée par des
individus malveillants.
Ils peuvent par exemple, envoyer un paquet à partir d'une fausse adresse de sorte
que, sauf si le pare-feu l'en empêche, il pénètre dans le réseau depuis Internet,
comme s'il s'agissait d'un trafic interne, et donc, légitime. Une fois que l'individu
malveillant a pénétré le réseau, il peut commencer à compromettre les systèmes.
Le filtrage d'entrée est une technique qui peut être appliquée sur un pare-feu pour
filtrer les paquets entrants sur le réseau afin de garantir, entre autres, qu'ils ne
sont pas falsifiés pour ressembler à ceux provenant du réseau interne.
Pour plus d'informations sur le filtrage des paquets, essayer d'obtenir des
informations sur une technique corollaire appelée « filtrage de sortie ».
1.3.5 Ne pas autoriser le trafic sortant non autorisé de
l’environnement des données des titulaires de cartes vers
Internet.
Tout le trafic sortant, issu de l'intérieur de l'environnement des données de
titulaires de cartes, doit être contrôlé afin de s'assurer qu'il suit toutes les règles
établies et autorisées. Les connexions doivent subir une inspection afin de
restreindre le trafic aux seules communications autorisées (par exemple en limitant
les adresses/ports sources ou de destination et/ou en bloquant le contenu).
Lorsque les environnements ne comportent pas de connectivité entrante autorisée,
les connexions sortantes peuvent s'établir par le biais d'architectures ou de
composants système qui interrompent et inspectent la connectivité IP.
1.3.6 Implémenter le contrôle avec état, également appelé
« filtrage des paquets dynamique » (seules les « connexions
établies » sont autorisées sur le réseau).
Un pare-feu qui effectue un contrôle des paquets avec état maintient « l'état » (ou
le statut) de chaque connexion au pare-feu. En maintenant « l'état », le pare-feu
sait si ce qui semble être une réponse à une connexion antérieure est
véritablement une réponse (puisqu'il mémorise la connexion antérieure) ou s'il
s'agit d'un individu ou d'un logiciel malveillants qui essaient de le tromper pour
autoriser la connexion.
1.3.7 Placer les composants du système qui stockent les
données de titulaires de cartes (comme une base de données)
dans une zone de réseau interne, isolée de la zone
démilitarisée et des autres réseaux non approuvés.
Les données de titulaires de cartes exigent le niveau de protection des
informations le plus élevé. Si les données de titulaires de cartes se trouvent dans
la zone démilitarisée, il est plus facile pour pirate externe d'y accéder puisqu'il a
moins de couches à pénétrer.
Remarque : cette condition ne recouvre pas le stockage de données sur une
mémoire volatile.
Octobre 2010
Page 15
Condition
1.3.8 Ne pas divulguer les adresses IP et les informations
d'acheminement confidentielles à des tiers non autorisés.
Remarque : voici quelques exemples de méthodes pour
dissimuler les adresses IP :
traduction d'adresse réseau (Network Address Translation
– NAT) ;
protéger les serveurs contenant des données de titulaires
de cartes derrière des serveurs proxy/pare-feu ou des
caches de contenu ;
retrait ou filtrage des annonces d'acheminement pour les
réseaux privés employant des adresses enregistrées ;
utilisation interne de l'espace d'adresse RFC1918 au lieu
d'adresses enregistrées.
Directive
Restreindre la diffusion des adresses IP est essentiel pour empêcher un hacker
« d'apprendre » les adresses IP du réseau interne et de les utiliser pour accéder
au réseau.
Les moyens éprouvés pour remplir cette condition varient en fonction de la
technologie réseau spécifique utilisé dans l'environnement de l'entreprise. Par
exemple, les contrôles utilisés pour satisfaire à cette condition peuvent différer
entre des réseaux IPv4 et IPv6.
Sur un réseau IPv4, une technique permettant de prévenir la découverte des
informations d'une adresse IP est de faire appel à la méthode dite de traduction
d'adresse réseau (Network Address translation – NAT). Cette méthode,
généralement gérée par le pare-feu, permet à une entreprise d'avoir des adresses
internes, visibles uniquement au sein du réseau, et des adresses externes, visibles
depuis l'extérieur. Si un pare-feu ne masque pas les adresses IP du réseau
interne, un individu malveillant peut découvrir les adresses IP internes et tenter
d'accéder au réseau par le biais d'une fausse adresse IP.
Dans le cas des réseaux IPv4, l'espace d'adresse RFC1918 est réservé aux
adresses internes et ne doit pas être retracé sur Internet. Il est donc privilégié pour
les adresses IP des réseaux internes. Certaines organisation peuvent toutefois
avoir des raisons d'utiliser un espace d'adresses autre que le RFC1918 sur leur
réseau interne. Dans ces cas-là, utiliser la prévention de publication du routage ou
d'autres techniques pour empêcher la diffusion sur Internet de l'espace d'adresses
interne, et sa divulgation à des tiers non autorisés.
1.4 Installer un logiciel pare-feu personnel sur tout ordinateur
portable et/ou ordinateur appartenant à un employé équipé d’une
connexion directe à Internet (par exemple, ordinateurs portables
utilisés par les employés), qui est utilisé pour accéder au réseau
de l’entreprise.
Si un ordinateur ne comporte pas de pare-feu ou de programme antivirus, des
logiciels espions, des chevaux de Troie, des virus, des vers et des outils de
dissimulation d'activité (programmes malveillants) peuvent être téléchargés et/ou
installés à l'insu de tous. L'ordinateur est encore plus vulnérable s'il est
directement connecté à Internet et n'est pas protégé par le pare-feu de l'entreprise.
Lorsque l'ordinateur est reconnecté au réseau de l'entreprise, les programmes
malveillants, chargés sur l'ordinateur pendant qu'il n'était pas protégé par un parefeu, peuvent alors cibler les informations du réseau avec des intentions criminelles.
Remarque : cette condition s'applique aux ordinateurs avec accès à distance,
qu'ils appartiennent à la société ou à l'employé. Les systèmes qui ne peuvent pas
être gérés selon la politique de l'entreprise introduisent une faiblesse dans le
périmètre et procurent aux individus malveillants des opportunités à exploiter.
Octobre 2010
Page 16
Condition 2 : Ne pas utiliser les mots de passe système et autres paramètres de sécurité par défaut définis par le
fournisseur
Les individus malveillants (à l'intérieur ou à l’extérieur d'une entreprise), utilisent souvent les mots de passe et autres paramètres par défaut du
fournisseur pour s’infiltrer dans les systèmes en vue de les endommager. Ces mots de passe et paramètres sont bien connus des communautés
de pirates et sont facilement détectables à partir d'informations publiques.
Condition
Directive
2.1 Changer systématiquement les paramètres par défaut définis
par le fournisseur avant d’installer un système sur le réseau ; par
exemple, inclure des mots de passe et des chaînes de
communauté SNMP (Simple Network Management Protocol), et
éliminer les comptes qui ne sont pas nécessaires.
Les individus malveillants, qu’ils soient à l'intérieur ou à l’extérieur d'une entreprise,
utilisent souvent les paramètres par défaut définis par le fournisseur, noms de
compte et mots de passe, pour endommager les systèmes. Ces paramètres sont
biens connus des communautés de hackers et rendent le système extrêmement
vulnérables aux attaques.
2.1.1 Pour les environnements sans fil connectés à
l’environnement des données des titulaires de cartes ou la
transmission de données des titulaires de cartes, modifier les
paramètres par défaut définis par le fournisseur des
équipements sans fil, notamment les mots de passe, les
chaînes de communauté SNMP et les clés de cryptage sans fil
par défaut.
2.2 Élaborer des normes de configuration pour tous les
composants du système. S’assurer que ces normes couvrent
toutes les vulnérabilités de la sécurité et sont compatibles avec
toutes les normes renforçant les systèmes en vigueur dans le
secteur.
Les sources des normes renforçant les systèmes en vigueur dans
le secteur, comprennent, sans s'y limiter, les organismes
suivants :
Center for Internet Security (CIS – Centre de sécurité
Internet)
International Organization for Standardization (ISO –
Organisation des normes internationales)
SysAdmin Audit Network Security (SANS) Institute (Institut
SANS)
National Institute of Standards Technology (NIST – Institut
national des standards et de la technologie)
De nombreux utilisateurs installent ces équipements sans l'approbation de la
direction et ne modifient pas les paramètres par défaut, ni ne configurent des
paramètres de sécurité. Si les réseaux sans fil ne sont pas déployés avec une
sécurité suffisante (y compris par la modification des paramètres par défaut), des
renifleurs sans fil peuvent intercepter le trafic, capturer facilement des données et
des mots de passe, pénétrer sans difficultés le réseau et l'attaquer. En outre, le
protocole d'échange de clés de l'ancienne version de cryptage 802.11x (WEP) a
été décrypté et peut rendre le cryptage inutile. Vérifier que le firmware des
dispositifs est mis à jour pour prendre en charge des protocoles plus sécurisés
(par ex., WPA2).
De nombreux systèmes d'exploitation, bases de données et applications
d'entreprise présentent des points faibles connus et il existe des moyens
également connus de les configurer pour résoudre les vulnérabilités de sécurité.
Pour aider ceux qui manquent d'expertise en sécurité, les entreprises de sécurité
ont défini des recommandations visant à renforcer les systèmes, indiqua la
manière de corriger ces faiblesses. Si les systèmes sont laissés tels quels, par
exemple avec des paramétrages de fichier faibles ou des services et des
protocoles par défaut (services ou protocoles qui sont souvent superflus), un pirate
sera capable d'exploiter les nombreuses failles connues pour attaquer les services
et protocoles vulnérables, et accéder ainsi au réseau de l'entreprise. Les sites
Web suivants, entre autres, fournissent des informations sur les meilleures
pratiques du secteur qui peuvent être utiles pour la mise en place des normes de
configuration : www.nist.gov, www.sans.org, www.cisecurity.org, www.iso.org.
Les normes de configuration de système doivent également être gardées à jour
afin de garantir que les faiblesses récemment identifiées sont corrigées avant
l'installation du système sur un réseau.
Octobre 2010
Page 17
Condition
2.2.1 N'appliquer qu'une fonction principale par serveur afin
d'éviter la coexistence, sur le même serveur, de fonctions
exigeant des niveaux de sécurité différents (Par exemple, les
serveurs Web, les serveurs de bases de données et les
serveurs DNS doivent être déployés sur des serveurs distincts).
Remarque : lorsque des technologies de virtualisation sont
utilisées, n'appliquer qu'une fonction principale par composant
de système virtuel.
Directive
Ceci permet de garantir que les normes de configuration et les processus associés
de l'entreprise prennent en charge les fonctions de serveur devant posséder
différents niveaux de sécurité, ou pouvant, du point de vue de la sécurité, fragiliser
d'autres fonctions du même serveur. Par exemple :
1. une base de données, qui doit posséder des mesures de sécurité robustes,
serait vulnérable si elle partageait un serveur avec une application Web, qui
doit être ouvert et directement orienté vers Internet.
2. Ne pas appliquer un correctif à une fonction en apparence mineure peut
compromettre d'autres fonctions plus importantes (comme une base de
données) du même serveur.
Cette condition concerne tous les serveurs au sein de l'environnement des
données de titulaires de cartes (s'appuyant généralement sur des systèmes Unix,
Linux ou Windows). Elle peut ne pas s'appliquer aux systèmes possédant une
capacité native pour mettre en œuvre des niveaux de sécurité sur un serveur
unique (par ex., mainframe).
Lorsque l'on utilise des technologies de virtualisation, chaque composant virtuel
(par ex., ordinateur ou commutateur virtuels, équipements de sécurités virtuels,
etc.) doit être considéré comme une limite de« serveur ». Les hyperviseurs
peuvent, à titre individuel, prendre en charge diverses fonctions, mais un
ordinateur virtuel unique doit adhérer à la règle de la « fonction principale unique ».
Dans un tel cas, si l'hyperviseur est compromis, cela peut compromettre
l'ensemble des fonctions du système. En conséquence, on doit donc également
tenir compte du niveau de risque en appliquant de multiples fonctions ou
composants à un système matériel unique.
2.2.2 N'activer que les services, protocoles, démons, etc.,
nécessaires et sécurisés pour le fonctionnement du système.
Mettre en place des fonctions de sécurité pour tout service,
protocole ou démon nécessaires que l'on estime non sécurisés.
Utiliser par exemple des technologies sécurisées, SSH, S-FTP,
SSL ou IPSec VPN, pour protéger des services non sécurisés
comme NetBIOS, le partage de fichiers, Telnet, FTP, etc.
2.2.3 Configurer les paramètres de sécurité du système pour
empêcher les actes malveillants.
Comme indiqué à la condition 1.1.5, une entreprise peut avoir besoin de nombreux
protocoles (ou les avoir activés par défaut) et ceux-ci sont fréquemment utilisés
par les individus malveillants pour endommager un réseau. Pour s'assurer que
seuls les services et protocoles nécessaires soient activés et que tous les services
et protocoles non sécurisés le soient correctement avant le déploiement de
nouveaux serveurs, cette condition doit faire partie des normes de configuration et
processus associés de l'entreprise.
Ceci est destiné à garantir que les normes de configuration et les processus
associés de l'entreprise répondent aux paramètres et configuration de sécurité
dont on connaît les implications pour la sécurité.
Octobre 2010
Page 18
Condition
Directive
2.2.4 Supprimer toutes les fonctionnalités qui ne sont pas
nécessaires, par exemple scripts, pilotes, fonctions, soussystèmes, systèmes de fichiers et serveurs Web superflus.
Les normes renforçant les serveurs doivent inclure des processus pour répondre
aux fonctionnalités inutiles avec une implications spécifique pour la sécurité (par
exemple, suppression/désactivation de la fonction FTP ou du serveur Web si celuici n'exécute pas ces fonctions).
2.3 Crypter tous les accès administratifs non console, à l'aide
d'une cryptographie robuste. Utiliser des technologies telles que
SSH, VPN ou SSL/TLS pour la gestion sur le Web et autres
accès administratifs non-console.
Si l'administration à distance ne s'effectue pas par le biais d'une authentification
sécurisée et de communications cryptées, les informations administratives ou de
niveau opérationnel sensibles (comme les mots de passe de l'administrateur)
peuvent être interceptées. Un individu malveillant pourrait utiliser ces informations
pour accéder au réseau, se substituer à l'administrateur et subtiliser des données.
2.4 Les fournisseurs d’hébergement partagé doivent protéger
l'environnement hébergé et les données des titulaires de cartes
de chaque entité. Ces fournisseurs doivent satisfaire aux
exigences spécifiques décrites dans l’Annexe A : Autres
conditions de la norme PCI DSS s’appliquant aux fournisseurs
d’hébergement partagé.
Ceci est destiné aux fournisseurs d’hébergement qui proposent des
environnements d'hébergement partagé à des clients multiples sur le même
serveur. Lorsque toutes les données se trouvent sur le même serveur, sous le
contrôle d' un environnement unique, les paramètres des serveurs partagés ne
sont généralement pas gérables par les clients à titre individuel, et permettent aux
clients d'ajouter des fonctions et des scripts non sécurisés susceptibles d'affecter
la sécurité des environnements de tous les autres clients et, par conséquent,
permettent à un individu malveillant de compromettre les données d'un client, et
par là, d'accéder à toutes les données des autres clients. (Voir l’Annexe A.
Octobre 2010
Page 19
Directives relatives aux conditions 3 et 4 : Protection des données des titulaires de cartes de crédit
Condition 3 : Protéger les données de titulaires de cartes stockées
Les méthodes de protection, telles que le cryptage, la troncature, le masquage et le hachage, sont des composants stratégiques de la protection
des données des titulaires de cartes. Si un intrus parvient à contourner les autres contrôles de sécurité et à accéder aux données cryptées, il ne
pourra pas les lire ni les utiliser s’il n’a pas les clés cryptographiques appropriées. D’autres méthodes efficaces de protection des données
stockées doivent être envisagées pour limiter les risques. Par exemple, pour minimiser les risques, éviter de stocker les données des titulaires de
cartes à moins que cela ne soit absolument nécessaire, tronquer les données des titulaires de cartes si un PAN complet n’est pas requis et éviter
d’envoyer un PAN non protégé par les technologies pour utilisateur final, comme les e-mails ou les messageries instantanées.
Pour obtenir la définition d’une « cryptographie robuste » et d’autres termes relatifs à PCI DSS, consulter le Glossaire des termes, abréviations et
acronymes PCI DSS.
Condition
Directive
3.1 Garder le stockage de données de titulaires de cartes à un
niveau minimum en appliquant des politiques, procédures et
processus de conservation et d'élimination des données, comme
suit.
Une politique officielle de conservation des données identifie les données qui
doivent être conservées, leur lieu de conservation afin de pouvoir les détruire en
toute sécurité dès qu'elles ne sont plus nécessaires. Afin de définir les conditions
appropriées de conservation, une entreprise doit d'abord comprendre les besoins
de son activité ainsi que les obligations légales et réglementaires qui s'appliquent
à son secteur et/ou au type de données conservées.
3.1.1 Appliquer une politique de conservation et d'élimination
des données qui comprenne :
la limitation de la quantité de données stockées et du délai
de conservation restreints aux obligations professionnelles,
légales et réglementaires ;
des processus pour l'élimination sécurisée des données
devenues inutiles ;
des conditions de conservation spécifiques pour les
données de titulaires de cartes ;
un processus trimestriel automatique ou manuel pour
l'identification et l'élimination sécurisée des données de
titulaires de cartes stockées excédant les conditions de
conservation définies.
Le stockage de données de titulaires de cartes excédant les besoins de
l'entreprise, entraîne des risques superflus. Les seules données de titulaires de
cartes à stocker après autorisation sont le numéro de compte primaire ou PAN
(rendu illisible), la date d'expiration, le nom du titulaire de la carte et le code de
service.
La mise en œuvre de méthodes de destruction sécurisées garantit que les
données ne pourront pas être récupérées une fois qu'elles ne seront plus
nécessaires.
Il ne faut pas oublier qu'il est inutile de stocker ce dont on n'a pas besoin !
Octobre 2010
Page 20
Condition
Directive
3.2 Ne stocker aucune donnée d’authentification sensible après
autorisation (même cryptée).
Les données d'authentification sensibles correspondent au données de la bande
magnétique (ou piste)6, au code ou à la valeur de validation de la carte7, et
données PIN8. Le stockage des données d'authentification sensibles n'est
pas autorisé ! Ces données sont précieuses pour les individus malveillants car
elles leur permettent de créer de fausses cartes de paiement et de procéder à des
transactions frauduleuses. Voir le Glossaire des termes, abréviations et acronymes
PCI DSS et PA-DSS pour la définition complète des « données d'authentification
sensibles ».
Les données d'authentification sensibles concernées sont
mentionnées dans les conditions 3.2.1 à 3.2.3 suivantes :
Remarque : les émetteurs et les sociétés qui prennent en charge
les services d'émissions peuvent stocker des données
d'authentification sensibles s'il existe une justification économique
et que ces données sont stockées de manière sécurisée.
6
Remarque : les entreprises peuvent exécuter, permettre ou prendre en charge
des services de stockage des données d'authentification sensibles UNIQUEMENT
SI elles en ont un besoin professionnel légitime. Il faut remarquer que l'ensemble
des conditions de la norme PCI DSS s'applique aux émetteurs et que la seule
exception les concernant, ainsi que leurs processeurs, est que les données
d'authentification sensibles peuvent être conservées s'il existe une raison légitime
pour ce faire. Une raison légitime est une raison nécessaire pour
l'accomplissement de la fonction fournie pour l'émetteur et non une raison de pure
convenance.
De telles données doivent être stockées en sécurité, conformément aux conditions
de la norme PCI DSS et à aux conditions spécifiques de la marque de la carte de
paiement.
Données encodées sur la bande magnétique utilisée pour une autorisation lors d’une transaction carte présente. Ces données peuvent également se trouver sur la puce, ou ailleurs
sur la carte. Les entités ne peuvent pas conserver l’ensemble des données sur bande magnétique après autorisation des transactions. Les seuls éléments de données de piste
pouvant être conservés sont le numéro de compte primaire, le nom du titulaire de carte, la date d'expiration et le code de service.
7
La valeur à trois ou quatre chiffres imprimée sur l’espace dédié à la signature ou à droite de celui-ci ou encore sur la face avant d’une carte de paiement, utilisée pour vérifier les
transactions carte absente.
8
Les données PIN (Personal Identification Number, numéro d’identification personnel) saisies par le titulaire de la carte lors d’une transaction carte présente et/ou le bloc PIN crypté
présent dans le message de la transaction.
Octobre 2010
Page 21
Condition
3.2.1 Ne jamais stocker la totalité du contenu d’une quelconque
piste (sur la bande magnétique au verso d'une carte, sur une
puce ou ailleurs). Les données sont alternativement désignées
piste complète, piste, piste 1, piste 2 et données de bande
magnétique.
Directive
Si les données complètes de piste étaient stockées, les individus malveillants qui
parviendraient à se les procurer pourraient reproduire et vendre des cartes de
paiement dans le monde entier.
Remarque : dans le cadre normal de l'activité, il est parfois
nécessaire de conserver les éléments de données de la bande
magnétique suivants :
le nom du titulaire de la carte ;
le numéro de compte primaire (PAN) ;
la date d'expiration ;
le code de service.
Afin de réduire le risque autant que possible, stocker
uniquement les éléments de données nécessaires à l'activité.
3.2.2 Ne pas stocker le code ou la valeur de vérification de
carte (nombre à trois ou quatre chiffres figurant au recto ou au
verso de la carte de paiement), utilisé pour vérifier les
transactions carte absente.
Le code de validation des cartes est destiné à protéger les transactions « carte
absente », transactions effectuées via Internet ou ordre de paiement par email/téléphone (MOTO), en l'absence du consommateur et de la carte. Ces types
de transactions ne peuvent être authentifiés comme émanant du titulaire de la
carte qu'en demandant le code de validation de cette carte, puisque le titulaire a la
carte en main et peut le lire. Si ces données étaient stockées malgré l'interdiction
et étaient subtilisées, des individus malveillants pourraient exécuter des
transactions, MO/TO et par Internet, frauduleuses.
3.2.3 Ne pas stocker de code PIN (Personal Identification
Number) ni de bloc PIN crypté.
Ces valeurs ne doivent être connues que du titulaire de la carte ou de la banque
émettrice de la carte. Si ces données étaient stockées malgré l'interdiction et
étaient subtilisées, des individus malveillants pourraient exécuter des transactions
de débit à l'aide du code PIN (par exemple, retraits à un GAB).
3.3 Masquer le PAN lorsqu'il s'affiche (les six premiers chiffres et
les quatre derniers sont le maximum de chiffres affichés).
Remarques :
Cette condition ne s'applique pas aux employés et autres
parties qui ont un besoin professionnel légitime de voir
l'intégralité du PAN.
Cette exigence ne se substitue pas aux exigences plus
strictes qui sont en place et qui régissent l’affichage des
données des titulaires de cartes, par exemple, pour les
reçus des points de vente (POS).
Grâce à l'affichage du PAN intégral sur un écran d'ordinateur, un reçu de carte de
paiement, un fax ou un rapport sur papier, des individus non autorisés pourraient y
avoir accès et l'utiliser de manière frauduleuse. Le PAN peut être indiqué
intégralement sur la « copie commerçant » des tickets de paiement. Toutefois, ces
reçus papier doivent être soumis aux mêmes critères de sécurité que les copies
électroniques et suivre les directives de la norme PCI DSS, en particulier la
condition sur la sécurité physique. Le PAN intégral peut aussi être visible pour les
utilisateurs qui ont un besoin professionnel légitime de le connaître.
Cette condition traite de la protection du PAN visible sur les écrans, reçus papier,
etc., et ne doit pas être confondue avec la condition 3.4 de protection du PAN
lorsqu'il est stocké dans des fichiers, des bases de données, etc.
Octobre 2010
Page 22
Condition
Directive
3.4 Rendre le PAN illisible où qu'il soit stocké (y compris les
données sur support numérique portable, support de sauvegarde
et journaux), en utilisant l'une des approches suivantes :
hachage unilatéral s'appuyant sur une méthode
cryptographique robuste (la totalité du PAN doit être haché) ;
troncature (le hachage ne peut pas être utilisé pour
remplacer le segment tronqué du PAN) ;
tokens et pads d'index (les pads doivent être stockés de
manière sécurisée) ;
cryptographie robuste associée à des processus et des
procédures de gestion des clés.
L'absence de protection des PAN peut permettre à des individus malveillants de
voir ou de télécharger ces données. Les PAN stockés sur les supports de
stockage principal (bases de données ou fichiers plats comme les feuilles de
calcul) et autres supports secondaires (sauvegardes ou journaux d'audit,
d'anomalies ou de dépannage) doivent tous être protégés. Le préjudice résultant
du vol ou de la perte des bandes de sauvegarde pendant le transport peut être
réduit en s'assurant de rendre les PAN illisibles par cryptage, troncature ou
hachage. Les journaux d'audit, de dépannage et d'anomalies devant être
conservés, il est possible d'empêcher la divulgation des données qui y sont
contenues en rendant les PAN illisibles (ou en les supprimant).
Remarque : il s'agit d'un effort relativement peu important pour
un individu malveillant de reconstruire les données du PAN
d'origine, s'il a à la fois accès à la version tronquée et hachée
d'un PAN. Lorsque les versions hachée et tronquée du même
PAN sont présentes dans l'environnement de l'entreprise, des
contrôles supplémentaires doivent être en place pour garantir que
les versions hachée et tronquée ne peuvent pas être corrélées
pour reconstituer le PAN d'origine.
Hachage unilatéral s'appuyant sur une méthode
cryptographique robuste (la totalité du PAN doit être haché)
En corrélant les versions hachée et tronquée d'un PAN donné, un individu
malveillant peut facilement reconstituer le PAN d'origine. Des contrôles empêchant
la corrélation de ces données permettront de garantir que le PAN d'origine reste
illisible.
Pour obtenir la définition d’une « cryptographie robuste », consulter le Glossaire
des termes, abréviations et acronymes PCI DSS et PA-DSS.
Les fonctions de hachage unilatéral comme l'algorithme de hachage sécurisé
(SHA) reposant sur une cryptographie robuste peuvent être utilisées pour rendre
les données de titulaires de cartes illisibles. Ces fonctions sont appropriées
lorsqu'il n'est pas nécessaire de récupérer le numéro d'origine (le hachage
unilatéral est irréversible).
Pour compliquer la création d'une table arc-en-ciel, il est recommandé, mais ce
n'est pas une condition, d'entrer une valeur expresse dans la fonction de hachage,
en sus du PAN.
Troncature (le hachage ne peut pas être utilisé pour
remplacer le segment tronqué du PAN)
La troncature vise à ne stocker qu'une partie seulement (sans dépasser les six
premiers et les quatre derniers chiffres) du PAN. Ceci diffère du masquage, avec
lequel le PAN intégral est stocké, mais masqué lorsqu'il est affiché (une partie
seulement du PAN est indiquée à l'écran, dans les rapports, les reçus, etc.).
Cette condition traite de la protection du PAN lorsqu'il eststocké dans des fichiers,
des bases de données, etc., et ne doit pas être confondue avec la condition 3.3 de
protection du PAN lorsqu'il est visible sur les écrans, reçus papier, etc.
Octobre 2010
Page 23
Condition
Directive
Tokens et pads d'index (les pads doivent être stockés de
manière sécurisée)
Il est également possible d'utiliser des tokens et pads d'index pour rendre les
données de titulaire de carte illisibles. Un « token d'index » est un élément
cryptographique qui remplace le PAN en fonction d'un indice donné, par une
valeur imprévisible. Un pad ponctuel est un système dans lequel une clé privée,
générée de façon aléatoire, est utilisée une seule fois pour crypter un message qui
est ensuite décrypté à l'aide d'une clé et du pad ponctuel correspondant.
Cryptographie robuste associée à des processus et des
procédures de gestion des clés.
L'objectif de la cryptographie robuste (voir la définition et les longueurs de clé dans
le Glossaire des termes, abréviations et acronymes PCI DSS et PA-DSS) est de
fonder le cryptage sur un algorithme testé et accepté par le secteur (non pas un
algorithme exclusif ou « développé en interne »).
3.4.1 Si un cryptage par disque est utilisé (au lieu d'un cryptage
de base de données au niveau fichier ou 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 des bases de données de comptes
d'utilisateur locales). Les clés de décryptage ne doivent pas être
liées à des comptes d'utilisateur.
Le but de cette condition est de répondre à l'acceptabilité du cryptage par disque
pour rendre les données de titulaire de carte illisibles. Cette méthode crypte les
données stockées sur l'espace de stockage de masse d'un ordinateur et décrypte
automatiquement les informations à la demande d'un utilisateur autorisé. Les
systèmes de cryptage par disque interceptent les opérations de lecture et
d'écriture du système d'exploitation et exécutent les transformations
cryptographiques appropriées sans autre action particulière de l'utilisateur que la
saisie d'un mot de passe au début d'une session. Compte tenu de ces
caractéristiques du cryptage par disque, pour être conforme à cette condition, la
méthode de cryptage par disque ne peut pas avoir :
1) une association directe avec le système d'exploitation, ni
2) de clés de décryptage associées à des comptes d'utilisateur.
3.5 Protéger les clés utilisées pour protéger les données de
titulaires de cartes de la divulgation et de l'utilisation illicites :
Remarque : cette condition s'applique également aux clés de
cryptage de clés, utilisées pour protéger les clés de cryptage de
données – ces clés de cryptage de clés doivent être au moins
aussi robustes que la clé de cryptage de données.
3.5.1 Restreindre l'accès aux clés cryptographiques au plus
petit nombre d’opérateurs possible.
Les clés cryptographiques doivent être parfaitement bien protégées, car tout
individu qui parviendrait à y accéder pourrait décrypter les données. Les clés de
cryptage de clés, si elles sont utilisées, doivent au moins être aussi robustes que
les clés de cryptage de données afin de garantir une protection adéquate de la clé
qui crypte les données aussi bien que des données cryptées à l'aide de la clé.
L'obligation de protéger les clés d'une divulgation et d'une utilisation illicites
s'applique aux clés de cryptage des données comme à celles assurant le cryptage
des clés. Une seule clé de cryptage de clé pouvant permettre d'accéder à de
nombreux clés de cryptage de données, il est nécessaire d'appliquer des mesures
robustes pour protéger les clés de cryptage de clés. Les modules de sécurité
matériels (HSM) et le stockage inviolable à double contrôle et fractionnement des
connaissances sont des méthodes de stockage sécurisé des clés de cryptage de
clés, mais ne sont pas les seules.
Un petit nombre de personnes seulement doit avoir accès aux clés
cryptographiques, en général ceux qui sont chargés de la gestion de ces clés.
Octobre 2010
Page 24
Condition
Directive
3.5.2 Stocker les clés cryptographiques de manière sécurisée
dans aussi peu d’emplacements et de formes que possible.
Les clés cryptographiques doivent être stockées de manière sécurisée, cryptées
généralement à l'aide de clés de cryptage de clés et stockées dans très peu
d'endroits. Il n'est pas prévu de crypter les clés de cryptage de clés, mais celles-ci
doivent cependant être protégées de la divulgation et de l'utilisation illicites comme
le définit la condition 3.5 La conservation des clés de cryptage des clés dans des
endroits matériels et/ou logiciels distincts de ceux des clés de cryptage de
données réduit le risque d'accès non autorisé à ces deux types de clés.
3.6 Documenter en détail et déployer les processus et les
procédures de gestion des clés cryptographiques servant au
cryptage des données des titulaires de cartes, notamment ce qui
suit :
La manière dont les clés cryptographiques sont gérées est un aspect essentiel de
la sécurité permanente de la solution de cryptage. Un bon processus de gestion
des clés, qu'il soit manuel ou automatique dans le cadre du produit de cryptage,
répond aux normes du secteur et prend en charge tous les éléments essentiels
décrits aux points 3.6.1 à 3.6.8.
Remarque : de nombreuses normes du secteur pour la gestion
des clés sont disponibles auprès de diverses ressources,
notamment le NIST, à l’adresse suivante : http://csrc.nist.gov.
3.6.1 Génération de clés cryptographiques robustes
La solution de cryptage doit générer des clés robustes, aux termes du Glossaire
des termes, abréviations et acronymes PCI DSS et PA-DSS, à « cryptographie
robuste ».
3.6.2 Sécuriser la distribution des clés cryptographiques
La solution de cryptage doit distribuer les clés de manière sécurisée, c'est-à-dire
que les clés ne sont pas distribuées en texte clair et seulement aux individus
chargés de leur gestion, identifiés au point 3.5.1.
3.6.3 Sécuriser le stockage des clés cryptographiques
La solution de cryptage doit stocker les clés de manière sécurisée, c'est-à-dire que
les clés ne sont pas stockées en texte clair (mais cryptées à l'aide d'une clé de
cryptage de clés).
Octobre 2010
Page 25
Condition
3.6.4 Changements de clé cryptographique pour les clés ayant
atteint la fin de leur cryptopériode (par exemple, après la fin
d'une période définie et/ou après la production d'une certaine
quantité de cryptogrammes par une clé donnée), comme l'a
défini le fournisseur de l'application associée ou le propriétaire
de la clé, et selon les meilleures pratiques et directives du
secteur (par exemple, la publication spéciale NIST 800-57).
Directive
Une cryptopériode est la période durant laquelle une clé cryptographique donnée
peut être utilisée dans le but pour lequel elle est prévue. Les facteurs à prendre en
compte pour définir la cryptopériode sont, sans s'y limiter, la complexité de
l'algorithme sous-jacent, la taille ou la longueur de la clé, le risque de
compromission de la clé, et la sensibilité des données cryptées.
Il est impératif de changer les clés de cryptage une fois leur cryptopériode écoulée,
afin de réduire le risque qu'un tiers se les procure et soit en mesure de décrypter
les données.
Si l'application de cryptage provient d'un fournisseur, suivre tous les processus ou
recommandations du fournisseur concernant le changement périodique de clés. Le
propriétaire ou le responsable désignés de la clé peuvent également consulter les
meilleures pratiques en matière d'algorithmes cryptographiques et de gestion des
clés, notamment la publication spéciale NIST 800-57,, pour des directives sur la
cryptopériode appropriée selon les divers algorithmes et longueurs de clés.
Cette condition s'applique aux clés utilisées pour crypter les données de titulaires
de cartes stockées et aux clés de cryptage de clés associées.
3.6.5 Retrait ou remplacement des clés (par exemple, en les
archivant, détruisant, et/ou en les révoquant), si nécessaire
lorsque le degré d'intégrité d'une clé est affaibli (par exemple,
départ d'un employé ayant connaissance du texte clair d'une
clé) ou lorsque des clés sont susceptibles d'avoir été
compromises.
Remarque : si les clés cryptographiques retirées ou
remplacées doivent être conservées, ces clés doivent être
archivées de manière sécurisée (par exemple, en utilisant une
clé de cryptage de clé). Les clés cryptographiques archivées
doivent être utilisées uniquement pour un décryptage ou une
vérification.
3.6.6 Si des opérations de gestion manuelle de clés
cryptographiques en texte clair sont utilisées, elles doivent être
gérées par le fractionnement des connaissances et un double
contrôle (par exemple, exigeant deux ou trois personnes,
chacune connaissant uniquement sa propre fraction de la clé,
pour reconstituer la clé entière).
Les clés obsolètes, qui ne sont plus utilisées ni nécessaires, doivent être retirées
et détruites afin de s'assurer qu'elles ne puissent plus être utilisées. Si les
anciennes clés doivent être conservées (par exemple, pour accéder à des
données cryptées archivées), elles doivent être parfaitement bien protégées. (Voir
le point 3.6.6 ci-dessous.) La solution de cryptage doit également permettre un
processus de remplacement des clés dont on sait, ou dont on soupçonne, qu'elles
sont compromises.
Le fractionnement des connaissances et le double contrôle des clés permettent
d'éliminer la possibilité qu'une seule personne puisse accéder à l'intégralité d'une
clé. Ce contrôle s'applique généralement aux systèmes manuels de cryptage des
clés ou si la gestion des clés n'est pas prise en charge par la solution de cryptage.
Remarque : la génération, la transmission, le chargement, le
stockage et la destruction de clés sont quelques-uns des
exemples d'interventions de gestion manuelle des clés.
Octobre 2010
Page 26
Condition
Directive
3.6.7 Prévenir la substitution non autorisée des clés
cryptographiques.
La solution de cryptage ne doit pas autoriser ni accepter la substitution de clés de
la part de sources non autorisées ou de processus inattendus.
3.6.8 Exiger des opérateurs chargés de la gestion de clés
cryptographiques qu'ils reconnaissent formellement qu’ils
comprennent et acceptent leurs responsabilités.
Ce processus garantit que les individus chargés de la gestion des clés
comprennent bien leurs responsabilités et assument pleinement leur rôle.
Octobre 2010
Page 27
Condition 4 : Crypter la transmission des données des titulaires de cartes sur les réseaux publics ouverts
Les informations sensibles doivent être cryptées pendant leur transmission sur des réseaux accessibles à des individus malveillants. Les réseaux
sans fil mal configurés et les vulnérabilités dans les protocoles traditionnels de cryptage et d'authentification sont les cibles permanentes des
individus malveillants qui profitent de ces faiblesses pour obtenir un accès privilégié aux environnements des données des titulaires de cartes.
Condition
Directive
4.1 Utiliser des protocoles de sécurité et de cryptographie
robustes (par exemple, SSL/TLS, IPSEC, SSH, etc.) afin de
protéger les données sensibles des titulaires de cartes durant la
transmission sur des réseaux publics ouverts.
Voici quelques exemples de réseaux publics ouverts couverts par
la norme PCI DSS :
Internet,
technologies sans fil,
communications GSM (Global System for Mobile),
GPRS (General Packet Radio Service).
Les informations sensibles doivent être cryptées durant leur transmission sur des
réseaux publics, car il est facile et courant qu'un individu malveillant les intercepte
et/ou les détourne pendant cette opération.
Par exemple, le protocole SSL (Secure Sockets Layer) crypte les pages Web et
les données qui y sont saisies. Lors de l'utilisation de sites Web sécurisés à l'aide
du protocole SSL, s'assurer que l'URL contienne « https ».
Noter que l'on a signalé et documenté des vulnérabilités de certaines
implémentations du protocole SSL (versions SSL 2.0 et SSH 1.0), comme la
saturation de la mémoire tampon, qu'un pirate peut exploiter pour prendre le
contrôle du système concerné. Quel que soit le protocole de sécurité utilisé,
s'assurer qu'il est configuré de manière à n'utiliser que des configurations et
versions sécurisées pour empêcher toute connexion non sécurisée.
Octobre 2010
Page 28
Condition
4.1.1 S’assurer que les réseaux sans fil sur lesquels sont
transmises les données des titulaires de cartes ou qui sont
connectés à l’environnement des données des titulaires de
cartes mettent en œuvre les meilleures pratiques du secteur
(par exemple, IEEE 802.11i) pour appliquer un cryptage robuste
pour l'authentification et la transmission.
Remarque : l'utilisation du protocole WEP comme contrôle de
sécurité est interdit depuis le 30 juin 2010.
Directive
Les utilisateurs malveillants emploient des outils gratuits et largement répandus
pour écouter les communications sans fil. L'utilisation d'une cryptographie robuste
limite la divulgation d'informations sensibles sur le réseau. Dans de nombreux cas,
des données de titulaires de cartes stockées exclusivement sur le réseau câblé ont
été compromises par des utilisateurs malveillants qui se sont servis d'un réseau
sans fil non sécurisé pour y accéder. Les systèmes GPRS, GSM, WIFI, satellite et
Bluetooth constituent quelques exemples d'implémentations sans fil exigeant une
robuste cryptographie.
Une cryptographie robuste pour l'authentification et la transmission des données
de titulaires de cartes est obligatoire pour empêcher les utilisateurs malveillants
d'accéder au réseau sans fil, et à ses données, ou d'utiliser les réseaux sans fil
pour accéder à d'autres données ou réseaux internes. Le cryptage WEP ne doit
jamais être utilisé comme unique moyen de cryptage de données sur un canal
sans fil car il n'est pas considéré comme une cryptographie robuste, sa
vulnérabilité étant due à de faibles vecteurs d'initialisation dans le processus
d'échange de clés WEP ; il manque en outre d'un processus de rotation des clés.
Un pirate peut utiliser des outils d'attaque par force brute, disponibles
gratuitement, pour décrypter aisément le cryptage WEP.
Les actuels dispositifs sans fil doivent être mis à niveau (par exemple, mise à
niveau du firmware de point d'accès à WPA2) afin de prendre en charge un
cryptage robuste. Si les dispositifs en cours d'utilisation ne peuvent être mis à
niveau, il faut acquérir de nouveaux équipements ou mettre en œuvre des
contrôles compensatoires pour assurer un cryptage robuste.
4.2 Ne jamais envoyer de PAN non protégé à l'aide de
technologies de messagerie pour les utilisateurs finaux (par
exemple e-mail, messagerie instantanée, chat, etc.).
La messagerie électronique, la messagerie instantanée et le chat peuvent être
facilement interceptés par reniflage de paquets durant le survol des échanges sur
les réseaux internes et publics. Ne jamais envoyer de PAN à l'aide de ces outils de
messagerie à moins qu'ils n'intègrent des fonctions de cryptage robustes.
Octobre 2010
Page 29
Directives relatives aux exigences 5 et 6 : Gestion d’un programme de gestion des vulnérabilités
Condition 5 : Utiliser des logiciels antivirus et les mettre à jour régulièrement
Des logiciels malicieux, généralement appelés « programmes malveillants », par exemple virus, vers et chevaux de Troie, sont infiltrés dans le
réseau dans le cadre d'activités professionnelles approuvées, notamment l'échange d’e-mails et l’accès à Internet des employés ainsi que
l’utilisation de périphériques de stockage et d’ordinateurs portables. Les vulnérabilités des systèmes peuvent alors être exploitées à des fins
malveillantes. Des logiciels antivirus doivent être installés sur tous les systèmes régulièrement affectés par des programmes malveillants afin de
les protéger contre les menaces logicielles actuelles et futures.
Condition
Directive
5.1 Déployer des logiciels antivirus sur tous les systèmes
régulièrement affectés par des logiciels malveillants (en
particulier PC et serveurs).
Les systèmes normalement sécurisés sont l'objet d'attaques constantes utilisant les
codes d'exploitation largement publiés, souvent de type « jour 0 » (ou 0 day) (publiés
et diffusés sur les réseaux une heure après leur découverte). En l'absence de
logiciels antivirus régulièrement mis à jour, ces nouvelles formes de logiciels
malveillants peuvent attaquer et désactiver votre réseau.
Les logiciels malveillants peuvent être téléchargés et/ou installés depuis Internet
sans le savoir, mais les ordinateurs sont également vulnérables lors de l'utilisation de
périphériques de stockage amovibles, CD et DVD, clés USB et disques durs,
appareils photo numériques, assistants numériques personnels (PDA) et autres
périphériques. Sans un logiciel antivirus installé, ces ordinateurs peuvent devenir des
points d'accès au réseau et/ou cibler à des fins malveillantes les informations
disponibles sur le réseau.
Les systèmes généralement affectés par les logiciels malveillants ne comprennent
généralement pas les systèmes mainframe et la plupart des systèmes Unix (voir les
détails ci-dessous), chaque entité doit disposer d'un processus conforme à la
condition 6.2 de la norme PCI DSS, afin d'identifier et de résoudre les nouvelles
vulnérabilités de sécurité, et de mettre à jour ses processus et ses normes de
configuration en conséquence. Si un autre type de solution répond à des menaces
identiques par une méthodologie différente qu'une approche par signature, elle peut
convenir pour rester conforme à la condition.
Les tendances liées aux logiciels malicieux qui affectent les systèmes d'exploitation
utilisés par une entité doivent être inclus dans l'identification des nouvelles
vulnérabilités en matière de sécurité et les méthodes de résolution correspondantes
doivent être intégrées aux normes de configuration et aux mécanismes de protection
de l'entreprise, comme requis.
D'une manière générale, les systèmes d'exploitation suivants ne sont pas
couramment affectés par les logiciels malveillants : systèmes de type mainframe et
certains serveurs Unix (AIX, Solaris et HP-Unix). Toutefois, les tendances du secteur
concernant les logiciels malveillants peuvent changer rapidement et chaque
Octobre 2010
Page 30
Condition
5.1.1 S’assurer que tous les programmes antivirus sont
capables de détecter et d'éliminer tous les types de logiciels
malveillants connus, et de constituer une protection efficace
contre ce fléau.
5.2 S’assurer que tous les mécanismes antivirus sont à jour, en
cours d'exécution et génèrent des journaux d’audit.
Directive
entreprise doit se conformer à la condition 6.2 pour identifier et répondre aux
nouvelles vulnérabilités de sécurité, et mettre à jour ses processus et ses normes de
configuration en conséquence.
Il est important de se protéger contre TOUS les types et formes de logiciels
malveillants.
L'efficacité des meilleurs logiciels antivirus est limitée si les signatures antivirus ne
sont pas à jour ou si le logiciel n'est pas activé sur le réseau ou l'ordinateur d'un
utilisateur.
Les journaux d'audit permettent de surveiller l'activité des virus et les réactions
antivirus. Par conséquent, il est impératif que le logiciel antivirus soit configuré pour
générer des journaux d'audit et de gérer ces derniers conformément à la
condition 10.
Octobre 2010
Page 31
Condition 6 : Développer et gérer des systèmes et des applications sécurisés
Des individus sans scrupules peuvent exploiter les points faibles de la sécurité pour obtenir un accès privilégié aux systèmes. Bon nombre de ces
vulnérabilités sont résolues par les correctifs de sécurité développés par les fournisseurs. Ceux-ci doivent être installés par les entités chargées
de la gestion des systèmes. Tous les systèmes stratégiques doivent être dotés des correctifs logiciels appropriés les plus récents afin d’empêcher
l’exploitation et l'altération des données des titulaires de cartes par des individus et des logiciels malveillants.
Remarque : les correctifs logiciels appropriés sont ceux qui ont été suffisamment évalués et testés pour déterminer qu’ils ne présentent aucun
conflit avec les configurations de sécurité existantes. De nombreuses vulnérabilités peuvent être évitées dans les applications développées en
interne grâce à l'utilisation de processus de développement système standard et de techniques de codage sécurisées.
Condition
Directive
6.1 S’assurer que tous les logiciels et les composants du système
sont dotés des derniers correctifs de sécurité développés par le
fournisseur, afin de les protéger des vulnérabilités connues.
Installer les correctifs de sécurité stratégiques dans le mois qui
suit leur commercialisation.
Les systèmes normalement sécurisés sont l'objet d'attaques constantes utilisant
les codes d'exploitation largement publiés, souvent de type « jour 0 » (ou 0 day)
(publiés dans l'heure). Sans l'installation des correctifs les plus récents sur les
systèmes stratégiques dans les meilleurs délais, un individu malveillant peut
utiliser ces codes d'exploitation pour attaquer le réseau et le désactiver. Tenir
compte de la priorité des changements à effectuer afin de pouvoir installer, dans
les 30 jours, les correctifs de sécurité essentiels sur les systèmes stratégiques ou
à risque, et de procéder aux modifications moins cruciales dans un délai de deux à
trois mois.
Remarque : une entreprise peut envisager la mise en œuvre
d'une approche en fonction du risque pour définir la priorité des
correctifs à installer. Par exemple, en accordant aux
infrastructures stratégiques (par exemple, bases de données,
périphériques et systèmes orientés public) une priorité supérieure
à celle des périphériques internes moins cruciaux, de sorte que
les systèmes et les périphériques hautement prioritaires soient
traités dans un délai d'un mois, tandis que les périphériques et
systèmes moins stratégiques le soient dans un délai de trois
mois.
Octobre 2010
Page 32
Condition
Directive
6.2 Établir un processus pour identifier et assigner une catégorie
de risque aux nouvelles vulnérabilités de sécurité découvertes.
L'objectif de cette condition est de faire en sorte que les organisations restent
vigilantes et se tiennent au courant des nouvelles vulnérabilités pouvant affecter
leur environnement.
Remarques :
Le classement des risques doit se baser sur les meilleures
pratiques du secteur. Par exemple, les critères de classement
des vulnérabilités à « haut » risque peuvent comprendre un score
CVSS (Common Vulnerability Scoring System, système de
notation de vulnérabilité commun) de 4.0 ou plus, et/ou un
correctif proposé par le fournisseur, classé comme « critique »,
et/ou une vulnérabilité affectant un composant essentiel du
système.
Le classement des vulnérabilités tel qu'il est défini au point 6.2
est considéré comme une meilleure pratique jusqu'au
30 juin 2012, après quoi ce sera une obligation.
Bien qu'il soit important de surveiller les annonces d'un fournisseur en matière de
nouvelles vulnérabilités et de correctifs relatifs à leurs produits, il est tout aussi
important de surveiller les nouveaux groupes de vulnérabilité courants du secteur,
ainsi que les listes de publipostage sur des vulnérabilités et d'éventuels
contournements que le fournisseur peut encore ignorer ou qu'il n'a pas encore
résolus.
Une fois qu'une organisation identifie une vulnérabilité qui pourrait affecter son
environnement, il lui faut évaluer et classer le risque que pose cette vulnérabilité.
Ceci implique que l'organisation applique uniformément la même méthode pour
évaluer les vulnérabilités et attribuer un classement de risque. Chaque
organisation utilisera probablement des méthodes différentes pour l'évaluation des
vulnérabilités et le classement du risque en se basant sur son CDE unique, mais il
est possible de s'appuyer sur les systèmes de classement du risque couramment
acceptés par le secteur, comme le système CVSS. 2.0, NIST SP 800-30, etc.
Établir un classement du risque (par exemple, « élevé » (à haut risque), « moyen »
et « faible ») permet aux organisations d'identifier et de répondre plus rapidement
aux éléments de risque de priorité élevée, et de réduire la probabilité que les
vulnérabilités impliquant les risques les plus élevés soient exploitées.
6.3 Développer des applications logicielles (internes et externes,
y compris l'accès administratif aux applications par le Web)
conformément à la norme PCI DSS (par exemple, authentification
et connexion sécurisées), basées sur les meilleures pratiques du
secteur, et intégrer la sécurité de l'information à tout le cycle de
vie du développement de logiciel. Ces processus doivent inclure
ce qui suit :
Faute d'intégrer la sécurité aux phases de définition des conditions, de conception,
d'analyse et de test du développement d'un logiciel, des vulnérabilités de sécurité
peuvent être introduites, accidentellement ou par malveillance, dans
l'environnement de production.
6.3.1 La suppression des comptes d’application personnalisés,
des noms d’utilisateur et des mots de passe avant l’activation
des applications ou leur mise à la disposition des clients.
Les comptes d'application personnalisés, les ID utilisateur et les mots de passe
doivent être supprimés du code de production avant l'activation de l'application ou
sa mise à la disposition des clients puisque ces éléments peuvent révéler des
informations sur le fonctionnement de l'application. La possession de ces
informations permet de compromettre plus facilement l'application et les données
de titulaires de cartes associées.
Octobre 2010
Page 33
Condition
Directive
6.3.2 L'examen du code personnalisé avant sa mise en
production ou sa mise à la disposition des clients afin
d’identifier toute vulnérabilité éventuelle du codage.
Les vulnérabilités de sécurité du code personnalisé sont généralement exploitées
par les individus malveillants pour accéder à un réseau et compromettre les
données de titulaires de cartes.
Remarque : cette condition s’applique à l'intégralité du code
personnalisé (aussi bien interne qu’orienté public), dans le
cadre du cycle de développement du système. Les examens
du code peuvent être réalisés par le personnel interne
compétent ou par des prestataires tiers. Les applications Web
font également l'objet de contrôles supplémentaires si elles sont
orientées public afin de résoudre les menaces et les
vulnérabilités éventuelles après leur déploiement, comme défini
par la condition 6.6 de la norme PCI DSS.
Les vérifications de code peuvent être exécutées manuellement ou à l'aide d'outils
automatisés. Les outils de contrôle automatisés possèdent des fonctionnalités qui
vérifient les vulnérabilités et les erreurs de codage les plus courantes. Bien que la
vérification automatisée soit utile, on ne doit cependant pas s'y fier comme seul
moyen de contrôle du code. Il convient de faire appel à individu expérimenté,
familiarisé au contrôle du code, pour procéder à la vérification, afin d'identifier les
problèmes de code difficiles voire impossibles à identifier avec les seuls outils
automatisés. Charger une personne, autre que le développeur du code, de
procéder à sa vérification, permet d'exécuter un contrôle indépendant et objectif.
6.4 Suivre les processus et procédures de contrôle des
changements pour toutes les modifications apportées à des
composants du système. Ces processus doivent inclure ce qui
suit :
Sans un contrôle approprié des modifications, les fonctions de sécurité peuvent
être accidentellement ou délibérément omises ou rendues inopérantes, des
irrégularités de traitement peuvent se produire ou un code malveillant peut être
introduit.
6.4.1 Séparation des environnements de développement/test
et de production.
En raison de leur évolution constante, les environnements de développement et de
test tendent à être moins sécurisés que les environnements de production. Sans
une séparation appropriée des environnements, un environnement de production,
et les données de titulaires de cartes qu'il contient, pourrait être compromis en
raison des vulnérabilités existant dans l'environnement de test ou de
développement.
6.4.2 Séparation des obligations entre les environnements de
développement/test et de production.
Réduire le nombre de personnes ayant accès à l'environnement de production et
aux données de titulaires de cartes minimise le risque et permet de garantir que
l'accès est limité aux seuls individus ayant un besoin professionnel d'en connaître.
Cette condition est destinée à garantir la séparation des fonctions de
test/développement et des fonctions de production. Par exemple, un développeur
peut utiliser un compte de niveau administrateur avec des privilèges de haut rang
dans un environnement de développement et posséder un compte distinct avec un
accès de niveau utilisateur pour l'environnement de production.
Dans les environnements où un même individu assume des fonctions multiples
(par exemple, développement d'application et mise en œuvre des mises à jour des
systèmes de production), les tâches doivent être assignées de telle sorte qu'un
seul individu ne soit pas en mesure d'exercer un contrôle de bout en bout sur un
processus, sans un point de contrôle indépendant. Par exemple, charger des
individus différents d'assumer le développement, l'autorisation et la surveillance.
Octobre 2010
Page 34
Condition
6.4.3 Les données de production (PAN actifs) ne sont pas
utilisées à des fins de test ou de développement.
Directive
Les contrôles de sécurité ne sont généralement pas aussi stricts dans
l'environnement de développement. L'utilisation des données de production donne
aux individus malveillants la possibilité d'y accéder (données de titulaire de carte)
sans y être autorisés.
Les marques de cartes de paiement et de nombreux émetteurs sont à même de
fournir des numéros de comptes convenant au test dans le cas où un PAN réaliste
est nécessaire pour tester la fonctionnalité d'un système avant sa diffusion.
6.4.4 Suppression des données et comptes de tests avant que
les systèmes de production ne deviennent actifs.
Les comptes et les données de test doivent être supprimés du code de production
avant l'activation de l'application, puisque ces éléments peuvent divulguer des
informations sur le fonctionnement de l'application. Grâce à la possession de ces
informations, il est plus facile de compromettre l'application et les données de
titulaires de cartes associées.
6.4.5 Procédures de contrôle de modifications pour la mise en
œuvre de correctifs de sécurité et de modifications du logiciel.
Les procédures doivent inclure ce qui suit :
Sans un contrôle approprié des modifications, les fonctions de sécurité peuvent
être accidentellement ou délibérément omises ou rendues inopérantes, des
irrégularités de traitement peuvent se produire ou un code malveillant peut être
introduit. De la même manière, une modification peut compromettre la fonction de
sécurité d'un système, rendant indispensable la suppression de la modification.
6.4.5.1 Documentation de l'impact
L'impact de la modification doit être documenté de sorte que toutes les parties
concernées soient en mesure d'établir un plan approprié pour tout changement du
traitement.
6.4.5.2 Documentation du changement approuvée par les
responsables appropriés.
L'approbation par les responsables autorisés indique que la modification est
légitime et que son approbation est ratifiée par l'organisation.
5.4.5.3 Test de fonctionnalité pour vérifier que le
changement ne compromet pas la sécurité du système.
Un test approfondi doit être effectué afin de vérifier que la sécurité de
l'environnement n'est pas diminuée par la mise en œuvre d'une modification. Le
test doit valider que tous les contrôles de sécurité existants restent en place, sont
remplacés par des contrôles de force équivalente, ou sont renforcés après toute
modification de l'environnement.
Pour les modifications de code personnalisé, le test comporte la vérification
qu'aucune vulnérabilité de codage n'a été introduite par la modification.
6.4.5.4 Procédures de suppression.
Pour chaque modification, il doit exister des procédures de retrait au cas où la
modification échouerait, afin de permettre de restaurer le système à son état
antérieur.
Octobre 2010
Page 35
Condition
Directive
6.5 Développer des applications basées sur les directives de
codage sécurisé. Prévenir les vulnérabilités de codage courantes
dans les processus de développement de logiciel, afin d'inclure
les éléments suivants :
La couche application comporte un risque élevé et peut être la cible de menaces
internes et externes. Sans une sécurité appropriée, les données de titulaires de
cartes et autres informations confidentielles de la société peuvent être exposées,
nuisant ainsi à l'entreprise et à sa réputation, ainsi qu'à ses clients.
Remarque : les vulnérabilités décrites aux points 6.5.1 à 6.5.9
faisaient partie des meilleures pratiques du secteur au moment
de la publication de cette version de la norme PCI DSS.
Cependant, comme les meilleures pratiques de gestion de la
vulnérabilité du secteur sont actualisées (par exemple, le guide
OWASP, le Top 25 SANS CWE, le codage sécurisé CERT, etc.),
se reporter aux meilleures pratiques actuelles pour ces
conditions.
Comme pour toutes les conditions de la norme PCI DSS, les conditions 6.5.1
à 6.5.5 et 6.5.7 à 6.5.9 indiquent les contrôles minimums à mettre en place. Cette
liste est composée des pratiques de codage sécurisé les plus courantes et
acceptées au moment de la publication de cette version de la norme PCI DSS.
Lorsque les pratiques de codage sécurisé, acceptées par le secteur, changent, les
pratiques de codage de l'organisation doivent elles aussi être mises à jour en
conséquence.
Les exemples fournis de ressources de codage sécurisé (SANS, CERT et
OWASP) sont suggérées comme sources de référence et ont été mentionnées à
titre indicatif seulement. Une organisation doit intégrer les pratiques de codage
sécurisé pertinentes, dans la mesure où elles sont applicables à la technologie
particulière de son environnement.
Octobre 2010
Page 36
Condition
Directive
6.5.1 Attaques par injection, notamment les injection de
commandes SQL Envisager également les attaques par
injection OS, LDAP et Xpath ainsi que les autres attaques par
injection.
Valider l'entrée pour vérifier que les données utilisateur ne peuvent pas modifier le
sens des commandes et des requêtes. Les attaques par injection, en particulier
injection de commandes SQL, sont une méthode couramment utilisée pour
compromettre des applications. Une attaque par injection se produit lorsque les
données saisies par un utilisateur sont transmises à un programme d'interprétation
dans le cadre d'une commande ou d'une requête. Les données hostiles du pirate
trompent le programme d'interprétation pour lui faire exécuter des commandes non
prévues ou modifier les données, permettant au pirate d'attaquer les composants
du réseau par le biais de l'application, de lancer des attaques comme la saturation
de la mémoire tampon, ou de révéler des informations confidentielles ainsi que la
fonctionnalité de l'application serveur. C'est également un moyen courant de
réaliser des transactions frauduleuses sur les sites Web de commerce en ligne.
Les informations provenant des requêtes Web doivent être validées avant d'être
transmises à l'application, par exemple en vérifiant tous les caractères
alphabétiques, le mélange de caractères alphanumériques, etc.
6.5.2 Saturation de la mémoire tampon
S'assurer que les applications ne sont pas vulnérables aux attaques par saturation
de la mémoire tampon. Ceci se produit lorsqu'une application ne dispose pas de
contrôles de limites sur l'espace de sa mémoire tampon. Pour exploiter la
vulnérabilité de saturation de la mémoire tampon, un pirate envoie à l'application
une quantité d'informations plus importante que ce que l'une de ses mémoires
tampons particulières est capable de gérer. Ceci a pour résultat de pousser les
informations de la mémoire tampon en dehors de son espace et dans l'espace
exécutable de la mémoire. Lorsque cela se produit, le pirate a la possibilité
d'insérer un code malveillant à une extrémité de la mémoire puis de le pousser
dans l'espace exécutable de la mémoire en saturant la mémoire tampon. Le code
malveillant est ensuite exécuté et permet souvent l'accès à distance du pirate, à
l'application et/ou au système infecté.
6.5.3 Stockage cryptographique non sécurisé
Il faut prévenir les défauts cryptographiques. Les applications qui n'utilisent pas
correctement de robustes fonctions cryptographiques pour stocker des données,
présentent un risque accru d'être compromises et d'exposer les données de
titulaires de cartes. Si un pirate est en mesure d'exploiter une faiblesse des
processus cryptographiques, il peut accéder au texte clair des données cryptées.
5.2.4 Communications non sécurisées
Crypter correctement toutes les communications authentifiées et sensibles. Les
applications qui ne réussissent pas à correctement crypter le trafic réseau à l'aide
d'une cryptographie robuste présentent un risque accru d'être compromises et
d'exposer les données de titulaires de cartes. Si un pirate est en mesure
d'exploiter une faiblesse des processus cryptographiques, il peut se retrouver en
mesure de prendre le contrôle de l'application ou même d'accéder au texte clair
des données cryptées.
Octobre 2010
Page 37
Condition
Directive
6.5.5 Traitement inapproprié des erreurs
Ne laisser filtrer aucune information par le biais de messages d'erreur ni par aucun
autre moyen. Les applications peuvent accidentellement laisser filtrer des
informations sur leur configuration ou leurs mécanismes internes, ou enfreindre la
confidentialité en raison de divers problèmes de l'application elle-même. Les
pirates exploitent cette faiblesse pour subtiliser des données sensibles ou lancer
des attaques plus sérieuses. La mauvaise gestion des erreurs fournit des
informations permettant à un individu malveillant de compromettre le système. Si
un individu malveillant peut créer des erreurs que l'application ne gère pas
correctement, il peut alors obtenir des informations système détaillées, créer des
interruptions par déni de service, mettre la sécurité en échec ou entraîner une
panne de serveur. Par exemple, le message selon lequel le « mot de passe saisi
est incorrect » indique que l'ID utilisateur fourni est correct et qu'il doit concentrer
ses efforts sur le décryptage du mot de passe seulement. Utiliser des messages
d'erreur plus génériques, comme « Impossible de vérifier les données ».
6.5.6 Toutes les vulnérabilités à « haut risque », identifiées
dans le processus d'identification de vulnérabilité (selon la
condition 6.2 de la norme PCI DSS).
Toute vulnérabilité de haut risque, notée selon la condition 6.2, qui pourrait affecter
l'application, doit être prise en charge durant la phase de développement. Par
exemple, une vulnérabilité, identifiée dans une bibliothèque partagée ou dans le
système d'exploitation sous-jacent, doit être évaluée et résolue avant que
l'application ne passe au stade de production.
Remarque : cette condition est considérée comme une
meilleure pratique jusqu'au 30 juin 2012, après quoi ce sera
une obligation.
Dans le cas des applications Web et des interfaces
d'application (internes ou externes) les conditions
supplémentaires suivantes s'appliquent :
Les applications Web, internes et externes (orientées public), comportent des
risques de sécurité uniques dus à leur architecture, à leur manque de difficulté
relatif et aux possibilités de les compromettre.
5.2.7 Attaques par script intersite (XSS)
Tous les paramètres doivent être validés avant leur inclusion. Des attaques XSS
se produisent chaque fois qu'une application extrait les données fournies par un
utilisateur et les transmet à un navigateur Web sans d'abord les valider ou coder le
contenu. Une attaque XSS permet aux pirates d'exécuter, dans le navigateur de la
victime, un script qui peut détourner des sessions utilisateur, rendre des sites Web
illisibles, introduire éventuellement des vers, etc.
Octobre 2010
Page 38
Condition
6.5.8 Contrôle d'accès inapproprié (comme des références
d'objet directes non sécurisées, impossibilité de limiter l'accès
URL, et survol de répertoire)
Directive
Ne soumettre en aucun cas les références à des objets internes aux utilisateurs.
Une référence d'objet directe existe lorsqu'un développeur expose la référence à
un objet d'implémentation interne, par exemple un fichier, un répertoire, un
enregistrement de base de données ou une clé, comme une adresse URL ou un
paramètre de formulaire. Les pirates peuvent manipuler ces références pour
accéder à d'autres objets sans autorisation.
Appliquer uniformément le contrôle d'accès au niveau de la couche présentation et
des modèles de traitement pour toutes les URL. Fréquemment, le seul moyen
qu'une application protège la fonctionnalité sensible est d'empêcher l'affichage des
liens ou des URL aux utilisateurs non autorisés. Les pirates peuvent exploiter cette
faiblesse pour accéder à des opérations non autorisées et les exécuter en
accédant directement à ces URL.
Se protéger contre le survol de répertoire. Un pirate peut être en mesure de
détailler la structure du répertoire d'un site Web et de le parcourir, obtenant ainsi
accès à des informations non autorisées ainsi que la compréhension du
fonctionnement du site qu'il exploitera plus tard.
6.5.9 Attaques CSRF (Cross-site request forgery)
6.6 Pour les applications Web orientées public, traiter les
nouvelles menaces et vulnérabilités de manière régulière et
veiller à ce que ces applications soient protégées contre les
attaques connues à l'aide de l’une des méthodes suivantes :
Examen des applications Web orientées public à l’aide
d'outils ou de méthodes d'évaluation de la sécurité et de la
vulnérabilité des applications automatiques ou manuels, au
moins une fois par an et après toute modification.
Installation d'un pare-feu pour applications Web devant les
applications Web orientées public.
Ne pas se fier aux éléments d'authentification et tokens automatiquement soumis
par les navigateurs. Une attaque CSRF force le navigateur d'une victime
connectée à envoyer une requête pré-authentifiée à une application Web
vulnérable, qui force à son tour le navigateur concerné à exécuter une action
hostile au profit du pirate. Les attaques CSRF peuvent être aussi puissantes que
l'application Web attaquée.
Les attaques des applications orientées vers le Web sont courantes, souvent
couronnées de succès, et sont la conséquence de médiocres pratiques de codage.
Cette condition de vérification des applications ou d'installation de pare-feu pour
les applications Web est destinée à réduire considérablement le nombre
d'attaques des applications Web orientées public qui entraînent la violation des
Il est possible d'utiliser des outils ou des méthodes manuels ou automatiques
d'évaluation de la sécurité et de la vulnérabilité, examinant et/ou analysant les
vulnérabilités de l'application pour satisfaire à cette condition
Les pare-feu pour applications Web filtrent et bloquent le trafic non essentiel
au niveau de la couche application. Utilisé conjointement à un pare-feu
réseau, un pare-feu pour application Web correctement configuré empêche les
attaques de la couche application si les applications sont mal codées ou mal
configurées.
Octobre 2010
Page 39
Directives relatives aux conditions 7, 8 et 9 : Mise en œuvre de mesures de contrôle d’accès strictes
Condition 7 : Restreindre l'accès aux données des titulaires de cartes aux seuls individus qui doivent les connaître
Pour garantir que les données stratégiques ne soient accessibles qu'au personnel autorisé, des systèmes et des processus doivent être mis en
place pour restreindre l'accès à ces données aux seuls individus qui doivent les connaître et en fonction de leurs responsabilités professionnelles.
En d'autres termes, les droits d'accès ne sont accordés qu’au plus petit nombre de données nécessaires et privilèges nécessaires pour les tâches
à effectuer.
Condition
Directive
7.1 Restreindre l'accès aux composants du système et aux
données des titulaires de cartes aux seuls individus qui doivent y
accéder pour mener à bien leur travail. Les restrictions d'accès
doivent inclure ce qui suit :
Plus le nombre de personnes ayant accès aux données de titulaires de cartes est
élevé, plus il y a de risques que le compte d'un utilisateur soit utilisé de manière
frauduleuse. Restreindre l'accès aux seuls individus qui doivent y accéder pour
une raison professionnelle légitime aide l'entreprise à prévenir la manipulation des
données de titulaires de cartes par des utilisateurs inexpérimentés ou malveillants.
L'octroi de droits d'accès à la plus petite quantité de données nécessaires et au
niveau le plus faible requis pour la réalisation du travail est appelé « séparation
des privilèges » et « besoin d'en connaître ». Lorsque ces privilèges sont octroyés
à des individus en fonction de la classification de leur poste et de leur fonction, le
modèle est appelé « contrôle d'accès à base de rôles » (ou RBAC, Role-Based
Access Control). La mise en vigueur d'un contrôle d'accès à base de rôles n'est
pas limité à une couche application ni à une solution d'autorisation spécifique. Par
exemple, les technologies comportant, entre autres, des services de répertoire,
comme Active Directory ou LDAP, des listes de contrôle d'accès (ACL) et
TACACS, sont des solutions viables tant qu'elles sont correctement configurées
pour appliquer les principes de séparation des privilèges et du besoin d'en
connaître.
7.1.1 Restriction des droits d’accès accordés aux ID
d’utilisateur privilégiés en octroyant les privilèges les plus
faibles qui sont nécessaires pour la réalisation du travail
7.1.2 L’octroi des privilèges se fait sur la base de la
classification et de la fonction professionnelles de chaque
employé
7.1.3 Obligation d'une approbation documentée par les
responsables spécifiant les privilèges requis.
7.1.4 Mise en œuvre d’un système de contrôle d'accès
automatique
Les organisations doivent mettre en place une politique et des processus clairs
pour contrôler l'accès aux données en fonction des principes du besoin d'en
connaître et du contrôle d'accès à base de rôles, afin de définir comment et à qui
accorder l'accès, notamment par des processus d'autorisation de gestion
appropriés.
Octobre 2010
Page 40
Condition
Directive
7.2 Définir un système de contrôle d’accès pour les composants
de systèmes comptant plusieurs utilisateurs, qui limite l'accès aux
seuls utilisateurs qui doivent accéder aux données et qui est
configuré pour « refuser tous les accès » à moins qu'ils ne soient
explicitement autorisés.
Sans un mécanisme de restriction de l'accès en fonction du besoin d'en connaître
d'un utilisateur, celui-ci peut, sans le savoir, se voir accorder l'accès aux données
de titulaires de cartes. L'usage d'un système ou d'un mécanisme de contrôle
d'accès automatisé est essentiel pour gérer des utilisateurs multiples. Ce système
doit être établi conformément à la politique et aux processus de contrôle d'accès
de l'organisation (notamment « besoin d'en connaître » et « contrôle d'accès à
base de rôles »), gérer l'accès à tous les composants du système et intégrer un
paramètre par défaut « Refuser tout » pour garantir que personne ne se verra
accorder un accès à moins qu'une règle ne soit établie pour accorder
spécifiquement cet accès.
Ce système de contrôle d’accès doit inclure les éléments
suivants :
7.2.1 Couverture de tous les composants du système
7.2.2 L’octroi de privilèges aux individus repose sur leur
classification et leur fonction professionnelles
7.2.3 Configuration par défaut du paramètre « Refuser tout »
Remarque : sur certains systèmes de contrôle d’accès, le
paramètre « Autoriser tout » est configuré par défaut. Par
conséquent, l’accès est autorisé à tous, à moins qu'une règle
écrite ne précise explicitement le refus de l’accès.
Octobre 2010
Page 41
Condition 8 : Affecter un ID unique à chaque utilisateur d’ordinateur
En affectant un identifiant (ID) unique à chaque utilisateur, on s’assure que chacun sera personnellement responsable de ses actes. Les actions
sur des données et des systèmes stratégiques peuvent alors être exécutées par des utilisateurs clairement identifiés et habilités à le faire.
Remarque : ces obligations concernent tous les comptes, y compris ceux des points de vente, avec une capacité administrative, et tous les
comptes utilisés pour voir ou accéder aux données de titulaires de carte ou pour accéder à des systèmes comportant ce type de données.
Cependant, les conditions 8.1, 8.2 et 8.5.8 à 8.5.15 ne sont pas destinées aux comptes utilisateurs au sein d'une application de paiement de point
de vente, qui n'ont accès qu'à un numéro de carte à la fois afin de permettre une transaction unique (comme les comptes de caisse).
Condition
Directive
8.1 Affecter à tous les utilisateurs un ID unique avant de les
autoriser à accéder à des composants du système ou aux
En s'assurant que chaque utilisateur est identifié de manière unique, au lieu
d'utiliser un ID unique pour plusieurs employés, une entreprise peut gérer la
responsabilité des actes de chaque individu et effectuer une vérification à rebours
efficace par employé. Cela accélérera la résolution des problèmes et en limitera
les conséquences en cas d'erreur ou d'intentions malveillantes.
8.2 Outre l’affectation d’un ID unique, employer au moins l’une
des méthodes suivantes pour authentifier tous les utilisateurs :
quelque chose de connu du seul utilisateur, comme un mot
de passe ou une locution de passage ;
quelque chose de détenu par l'utilisateur, comme un
dispositif token ou une carte à puce ;
quelque chose concernant l'utilisateur, comme une mesure
biométrique.
Ces éléments d'authentification, lorsqu'ils sont utilisés en plus des ID uniques,
protègent les ID uniques des utilisateurs et évitent qu'ils ne soient compromis
(puisque la personne qui en responsable de cette tentative doit connaître l'ID
unique et le mot de passe ou tout autre élément d'authentification).
Un certificat numérique est une option valable comme forme d'authentification du
type « quelque chose de détenu », tant qu'il reste unique.
Octobre 2010
Page 42
Condition
Directive
8.3 Intégrer l’authentification à deux facteurs pour l’accès à
distance (accès au niveau du réseau depuis l'extérieur du réseau)
des employés, des administrateurs et de tiers au réseau (par
exemple, authentification à distance et service de
renseignements par téléphone (RADIUS) avec tokens ; système
de contrôle d'accès au contrôleur d'accès du terminal (TACACS)
avec tokens ; ou autres technologies permettant une
authentification à deux facteurs).
L'authentification à deux facteurs requiert deux formes d'authentification pour les
accès à haut risque, comme ceux provenant de l'extérieur du réseau. Pour plus de
sécurité, l'organisation peut également envisager de recourir à une authentification
à deux facteurs pour accéder à des réseaux de sécurité supérieure depuis des
réseaux de sécurité inférieure, par exemple l'accès aux serveurs de
production/bases de données contenant les données de titulaires de cartes
(niveau de sécurité élevé) depuis les ordinateurs de bureau de l'entreprise (niveau
de sécurité inférieur).
Remarque : l'authentification à deux facteurs exige d'utiliser deux
des trois méthodes d'authentification (voir la condition 8.2 pour la
description des méthodes d'authentification). L'utilisation à deux
reprises d'un facteur (par exemple, l'utilisation de deux mots de
passe distincts) ne constitue pas une authentification à deux
facteurs.
Cette condition s'applique aux utilisateurs ayant un accès à distance au réseau,
lorsque cet accès à distance peut permettre de pénétrer dans l'environnement des
Dans ce contexte, accès à distance se réfère à un accès de niveau réseau,
provenant de l'extérieur du réseau propre de l'entreprise, qu'il s'agisse d'Internet,
ou d'un réseau ou d'un système « non approuvé », comme lorsqu'un tiers ou un
employé accède au réseau de l'entreprise à l'aide de son ordinateur portable.
L'accès interne LAN à LAN (par exemple entre deux bureaux par le biais d'un
réseau virtuel privé sécurisé) n'est pas considéré comme un accès à distance
dans le cadre de cette condition.
Si un accès à distance s'effectue sur le réseau d'une entreprise possédant une
segmentation appropriée, ces utilisateurs à distance ne peuvent accéder ni
affecter l'environnement des données des titulaires de carte et une authentification
à deux facteurs pour l'accès à distance à ce réseau ne sera pas exigée par la
norme PCI DSS. Cependant, l'authentification à deux facteurs est exigée pour tout
accès à distance à des réseaux ayant eux-mêmes accès à l'environnement des
données de titulaires de cartes et elle est recommandée pour tout accès à
distance aux réseaux de l'entreprise.
8.4 Rendre tous les mots de passe illisibles pendant la
transmission et le stockage sur tous les composants du système
à l’aide d’une méthode de cryptographie robuste.
De nombreux dispositifs et applications réseau transmettent l'ID utilisateur et le
mot de passe non crypté sur le réseau et/ou stockent également les mots de
passe sans cryptage. Un individu malveillant peut facilement intercepter l'ID
utilisateur et le mot de passe non cryptés ou lisibles durant leur transmission à
l'aide d'un « renifleur », ou directement accéder aux ID utilisateur et aux mots de
passe non cryptés, dans les fichiers où ils sont stockés, et utiliser ces données
volées pour accéder sans autorisation au réseau. Durant la transmission, les
éléments d'authentification de l'utilisateur ou le tunnel peuvent être cryptés.
8.5 S’assurer qu’une gestion appropriée des mots de passe et de
l’authentification des utilisateurs est mise en œuvre pour les
utilisateurs non-consommateurs et les administrateurs sur tous
les composants du système comme suit :
L'une des premières mesures qu'un individu malveillant prendra pour
compromettre un système étant d'exploiter la faiblesse ou l'absence de mots de
passe, il est important de mettre en place des processus appropriés pour
l'identification des utilisateurs et la gestion de l'authentification.
Octobre 2010
Page 43
Condition
Directive
8.5.1 Contrôler l’ajout, la suppression et la modification d’ID
d’utilisateur, d’informations d’identification et d’autres objets
identifiant.
Pour s'assurer que les utilisateurs ajoutés au système sont tous valides et
reconnus, l'ajout, la suppression et la modification d'ID utilisateurs doivent être
gérés et contrôlés par un groupe restreint disposant d'une autorité spécifique. La
gestion de ces ID utilisateur doit être limitée à ce seul petit groupe.
8.5.2 Vérifier l’identité des utilisateurs avant de réinitialiser leur
mot de passe.
De nombreux individus malveillants utilisent « l'ingénierie sociale », par exemple
en appelant un service d'assistance et en agissant comme un utilisateur légitime,
afin d'obtenir un changement de mot de passe de sorte qu'ils puissent utiliser un
ID utilisateur. Envisager l'utilisation d'une « question secrète » à laquelle seul
l'utilisateur lui-même peut répondre, afin d'aider les administrateurs à identifier
l'utilisateur avant de reconfigurer les mots de passe. Veiller à protéger
correctement ces questions, sans qu'elles puissent être communiquées à
quiconque.
8.5.3 Définir des mots de passe initiaux uniques pour chaque
utilisateur et les modifier immédiatement après la première
utilisation.
Si le même mot de passe est utilisé pour chaque nouvelle configuration
d'utilisateur, un utilisateur interne, un ancien employé ou un individu malveillant
peuvent connaître ou facilement découvrir ce mot de passe et l'utiliser pour
accéder aux comptes.
8.5.4 Révoquer immédiatement l'accès de tout utilisateur qui ne
travaille plus pour la société.
Si un employé ayant quitté la société avait toujours accès au réseau par son
compte d'utilisateur, il aurait la possibilité d'accéder aux données de titulaires de
cartes sans nécessité ou pourrait les compromettre. Ceci peut se produire
lorsqu'un ancien employé ou un utilisateur malveillant exploitent les anciens
comptes et/ou les comptes inutilisés. Envisager de mettre en place, en
concertation avec le service des ressources humaines, un processus de
notification immédiate lorsqu'un employé quitte la société afin que son compte
d'utilisateur soit rapidement désactivé.
8.5.5 Supprimer/désactiver les comptes d’utilisateur inactifs au
moins tous les 90 jours.
L'existence de comptes inactifs permet à un utilisateur non autorisé d'exploiter les
comptes non utilisés pour accéder aux données de titulaires de cartes.
8.5.6 Activer les comptes utilisés par les fournisseurs pour un
accès à distance pendant la période nécessaire seulement.
Surveiller les compte d'accès à distance du fournisseur pendant
leur utilisation.
Autoriser les fournisseurs (par ex. les fournisseurs de points de vente) à accéder à
un réseau 24 h/24 et 7 jours sur 7 au cas où ils auraient besoin d'intervenir sur les
systèmes, augmente les risques d'accès non autorisé, de la part d'un utilisateur
appartenant à l'environnement du fournisseur ou d'un individu malveillant qui
découvre et exploite ce point d'entrée toujours disponible sur le réseau.
La surveillance de l'accès du fournisseur à l'environnement des données de
titulaires de cartes s'applique de la même façon que pour les autres utilisateurs,
comme le personnel de l'organisation. Ceci comprend la surveillance et la
consignation des activités comme l'exigent les conditions 10.1 et 10.2 de la norme
PCI DSS, et le contrôle que le fournisseur utilise les comptes à distance
conformément à la politique définie dans les conditions 12.3.8 et 12.3.9.
Octobre 2010
Page 44
Condition
Directive
8.5.7 Communiquer les politiques et procédures
d'authentification à tous les utilisateurs qui ont accès aux
Communiquer les procédures relatives aux mots de passe et à l'authentification à
tous les utilisateurs leur permet de comprendre et respecter ces politiques, et de
rester vigilants au cas où un individu malveillant tenterait d'exploiter leurs mots de
passe pour accéder aux données de titulaires de cartes (par exemple, en appelant
un employé pour lui demander son mot de passe en vue de « résoudre un
problème »).
8.5.8 Ne pas utiliser de comptes, de mots de passe ni d'autres
méthodes d'authentification collectifs, partagés ou génériques.
Si plusieurs utilisateurs partagent les mêmes éléments d'authentification (par
exemple, mêmes compte utilisateur et mot de passe), il est alors impossible de
déterminer leurs responsabilités ni de consigner efficacement leurs actes
individuels, puisque ceux-ci peuvent avoir été exécutés par n'importe quel membre
du groupe.
Cette condition d'ID unique et de mots de passe complexes est souvent remplie au
sein des fonctions administratives en utilisant par exemple, une commande sudo
ou un protocole SSH de sorte que l'administrateur se connecte d'abord avec ses
propres ID unique et mot de passe, puis se connecte ensuite au compte
administrateur à l'aide d'une commande sudo ou d'un protocole SSH. Souvent les
connexions root directes sont neutralisées pour empêcher l'utilisation de ce
compte administrateur partagé. De cette manière, les responsabilités individuelles
et les vérifications à rebours restent valides. Toutefois, même avec l'utilisation
d'outils comme une commande sudo ou un protocole SSH, les ID et mots de
passe de l'administrateur réel doivent également remplir les conditions de la norme
PCI DSS (si de tels comptes ne sont pas désactivés), afin d'en prévenir l'utilisation
illicite.
8.5.9 Modifier les mots de passe utilisateur au moins tous les
90 jours.
8.5.10 Exiger des mots de passe comportant au moins sept
caractères.
8.5.11 Définir des mots de passe comportant des caractères
alphanumériques.
8.5.12 Interdire à un utilisateur de soumettre un nouveau mot
de passe identique à l’un de ses quatre derniers mots de
passe.
8.5.13 Limiter les tentatives d’accès répétées en verrouillant l’ID
d’utilisateur après six tentatives au maximum.
Des mots de passe robustes sont la première ligne de défense d'un réseau,
puisque souvent, un individu malveillant recherchera d'abord les comptes dont les
mots de passe sont faibles ou inexistants. Si les mots de passe sont courts, faciles
à deviner ou restent valides durant une période prolongée sans être modifiés, un
individu malveillant n'aura guère de peine à les découvrir et à compromettre un
réseau sous l'identité d'un ID utilisateur valide. Des mots de passe robustes
peuvent être appliqués et gérés conformément à ces conditions en activant les
fonctions de sécurité de mot de passe et de compte, intégrées au système
d'exploitation (par exemple, Windows), aux réseaux, bases de données et autres
plates-formes.
Sans des mécanismes de blocage de compte, un pirate peut en permanence
tenter de deviner un mot de passe à l'aide d'outils manuels ou automatiques (par
exemple, craquage de mots de passe), jusqu'à ce qu'il réussisse et l'utilise pour
accéder au compte d'un utilisateur.
Octobre 2010
Page 45
Condition
Directive
8.5.14 Régler la durée de verrouillage sur 30 minutes au moins
ou jusqu’à ce que l’administrateur active l’ID d’utilisateur.
Si un compte est bloqué parce que quelqu'un a essayé à plusieurs reprises d'en
deviner le mot de passe, des contrôles retardant la réactivation de ce compte
empêchent l'individu malveillant de poursuivre (il devra s'arrêter pendant au moins
30 minutes jusqu'à la réactivation du compte). En outre, si une réactivation doit
être demandée, l'administrateur ou le service d'assistance peuvent confirmer que
le titulaire du compte est à l'origine du verrouillage (par exemple, en raison d'une
erreur de saisie).
8.5.15 Si une session reste inactive pendant plus de
15 minutes, demander à l'utilisateur de s'authentifier de
nouveau pour réactiver le terminal ou la session.
Lorsque les utilisateurs s'éloignent de leur ordinateur allumé ayant accès au
réseau critique ou aux données de titulaires de cartes, d'autres utilisateurs peuvent
profiter de leur absence pour accéder sans autorisation à un compte et/ou l'utiliser
à des fins frauduleuses.
8.5.16 Authentifier tous les accès aux bases de données
contenant des données de titulaires de cartes. Cette condition
concerne les accès des applications, des administrateurs et de
tous les autres utilisateurs.
Restreindre l'accès direct des utilisateurs ou les requêtes aux
bases de données aux seuls administrateurs de bases de
données.
Sans une authentification des utilisateurs pour accéder aux bases de données et
aux applications, les risques d'accès non autorisés ou à des fins malveillantes
augmentent et ceux-ci ne peuvent pas être consignés dans les journaux puisque
l'utilisateur n'a pas été authentifié et, par conséquent, est inconnu du système. En
outre, l'accès aux bases de données doit être autorisé par un programme
seulement (par exemple, par le biais de procédures stockées), plutôt que un accès
direct des utilisateurs finaux à la base de données (à l'exception des
administrateurs de base de données, qui y ont un accès direct dans le cadre de
leurs tâches administratives).
Octobre 2010
Page 46
Condition 9 : Restreindre l’accès physique aux données des titulaires de cartes
Dans la mesure où tout accès physique à des données ou à des systèmes hébergeant des données de titulaires de cartes permet à des individus
d'accéder à des périphériques ou à des informations, et de supprimer des systèmes ou des copies papier, cet accès doit être restreint de façon
appropriée. Dans le cadre de cette condition 9, le terme « personnel du site » désigne les employés à temps plein et à temps partiel, les
intérimaires ainsi que les sous-traitants et les consultants qui « résident » sur le site de l'entité. Un « visiteur » est défini comme un fournisseur,
l’hôte du personnel du site, le personnel de service ou tout individu présent au sein des locaux pendant une période courte, n'excédant
généralement pas une journée. « Support » se rapporte à tout support papier ou électronique contenant des données de titulaires de cartes.
Condition
Directive
9.1 Utiliser des contrôles d’accès aux installations appropriés
pour restreindre et surveiller l’accès physique aux systèmes
installés dans l’environnement des données de titulaires de
cartes.
Sans des contrôles d'accès physiques, des personnes non autorisées pourraient
accéder aux locaux et aux informations sensibles, et modifier les configurations du
système, introduire des vulnérabilités dans le réseau, ou détruire ou dérober des
équipements.
9.1.1 Installer des caméras vidéo et/ou d’autres mécanismes de
contrôle d’accès pour surveiller l’accès physique des individus
aux zones sensibles. Examiner les données enregistrées et les
mettre en corrélation avec d'autres informations. Les conserver
pendant trois mois au minimum, sauf stipulation contraire de la
loi.
Remarque : par « zones sensibles », nous entendons tout
centre de données, salle de serveur ou zone abritant des
systèmes qui stockent, traitent ou transmettent des données de
titulaires de cartes. Cette définition exclut les zones où ne sont
installés que des terminaux de point de vente, comme dans les
zones de caisse dans un magasin.
9.1.2 Restreindre l’accès physique aux prises réseau
accessibles au public.
Par exemple, les zones accessibles aux visiteurs ne doivent
pas comporter de prises réseau activées à moins que l'accès
réseau ne soit explicitement autorisé.
Lors d'enquêtes sur les violations physiques, ces contrôles peuvent permettre
d'identifier les individus qui accèdent physiquement aux zones stockant les
données de titulaires de cartes. Les zones sensibles sont, entre autres exemples,
les salles des serveurs de base de données de l'entreprise, la salle du serveur de
données d'un point de vente au détail contenant des données de titulaires de
cartes et les lieux de stockage physique d'un volume important de données de
Restreindre l'accès aux prises réseau empêchera les individus malveillants de se
brancher aux prises réseau disponibles qui leur donneraient accès aux ressources
des réseaux internes. Envisager de désactiver les prises réseau lorsqu'elles ne
sont pas utilisées et de ne les réactiver que lorsque c'est nécessaire. Dans les
espaces publics, comme les salles de conférence, mettre en place des réseaux
privés afin de permettre aux fournisseurs et aux visiteurs d'accéder à Internet
seulement, sans pouvoir accéder au réseau interne.
Octobre 2010
Page 47
Condition
9.1.3 Restreindre l'accès physique aux points d'accès,
passerelles, dispositifs portables, matériel
réseau/communications et lignes de télécommunication sans fil.
Directive
Sans mécanismes de sécurité couvrant les composants et les équipements sans
fil, des utilisateurs malveillants pourraient utiliser les équipements sans fil de
l'entreprise, laissés sans surveillance, pour accéder aux ressources du réseau et
même connecter leurs propres équipements au réseau sans fil, obtenant ainsi un
accès non autorisé. En outre, la sécurisation du réseau et du matériel de
communications empêche les individus malveillants d'intercepter le trafic sur le
réseau ou de connecter physiquement leurs propres dispositifs aux ressources
réseau câblées de l'entreprise.
Envisager de placer les passerelles et points d'accès sans fil et le matériel de
communication/réseau dans des zones de stockage sécurisées, par exemple
armoires ou salles de serveurs verrouillées. Dans le cas des réseaux sans fil,
s'assurer qu'un cryptage robuste est activé. Envisager également d'activer le
verrouillage automatique des dispositifs portables sans fil lorsqu'ils restent inactifs
durant une période prolongée et de les configurer pour qu'ils exigent la saisie d'un
mot de passe au démarrage.
9.2 Élaborer des procédures qui aident à faire facilement la
distinction entre le personnel du site et les visiteurs, en particulier
dans les zones où sont accessibles les données de titulaires de
cartes.
Sans systèmes de badge et de contrôles aux portes, des utilisateurs non autorisés
et malveillants peuvent facilement accéder aux installations pour dérober,
désactiver, désorganiser ou détruire des systèmes critiques et les données de
titulaires de cartes. Pour un contrôle optimal, envisager de mettre un système
d'accès par badge ou carte à l'entrée et à la sortie des zones de travail contenant
des données de titulaires de cartes.
Identifier les visiteurs autorisés de manière à les distinguer facilement du
personnel du site empêche les visiteurs non autorisés de bénéficier d'un accès à
des zones contenant des données de titulaires de cartes.
9.3 S’assurer que tous les visiteurs sont traités de la manière
suivante :
9.3.1 Une autorisation d’accès leur est donnée avant de
pénétrer dans les zones où sont traitées et conservées les
données de titulaires de cartes
9.3.2 Ils reçoivent un dispositif physique (par exemple, badge
ou dispositif d’accès) doté d’une date d’expiration, qui identifie
bien les visiteurs comme ne faisant pas partie du personnel.
Le contrôle des visiteurs est essentiel pour réduire la capacité des personnes non
autorisées ou malveillantes à accéder aux installations (et éventuellement aux
données de titulaires de cartes).
Le contrôle des visiteurs est essentiel pour s'assurer que ceux-ci ne peuvent
pénétrer que dans les zones autorisées, qu'ils sont identifiables en tant que
visiteurs, de sorte que le personnel puisse surveiller leurs activités, et que leur
accès est limité à la durée de leur visite légitime.
9.3.3 Il leur est demandé de rendre le dispositif physique avant
de quitter les locaux ou à la date d’expiration
Octobre 2010
Page 48
Condition
Directive
9.4 Utiliser un registre des visites pour tenir un contrôle physique
de la circulation des visiteurs. Y consigner le nom du visiteur,
l’entreprise qu’il représente et le personnel du site qui autorise
son accès physique. Conserver ce registre pendant trois mois au
minimum, sauf stipulation contraire de la loi.
Il est facile et peu coûteux de tenir un registre des visiteurs comportant un
minimum d'informations les concernant et permet, en cas de violation de la
sécurité des données, d'identifier les accès physiques à un bâtiment ou une salle
et les accès éventuels aux données de titulaires de cartes. Envisager de mettre en
place des registres à l'entrée des locaux, en particulier dans les zones où se
trouvent des données de titulaires de cartes.
9.5 Ranger les sauvegardes sur support en lieu sûr, de
préférence hors de l’installation, par exemple sur un autre site ou
un site de secours, ou encore un site de stockage commercial.
Inspecter la sécurité du site au moins une fois par an.
Si elles sont stockées dans un local non sécurisé, les sauvegardes contenant les
données de titulaires de cartes peuvent être facilement perdues, volées ou copiées
à des fins malveillantes. Pour en sécuriser le stockage, envisager de faire appel
aux services d'une entreprise de stockage de données commerciales OU, dans le
cas d'une petite entreprise, envisager la location d'un coffre-fort dans une banque.
9.6 Assurer la sécurité physique de tous les supports.
Les données de titulaires de cartes sont susceptibles d'être consultées, copiées ou
scannées sans autorisation si elles se trouvent sur un support portable ou
amovible, sont imprimées ou sont laissées sur le bureau d'un employé, sans
protection.
9.7 Assurer un contrôle strict de la distribution interne ou externe
de tout type de support, notamment ce qui suit :
Envisager de mettre en place des procédures et des processus de protection des
données de titulaires de cartes se trouvant sur les supports distribués à des
utilisateurs internes et/ou externes. En l'absence de telles procédures, ces
données peuvent être perdues, volées ou utilisées à des fins frauduleuses.
9.7.1 Classer les supports afin de déterminer la sensibilité des
données qu'ils contiennent.
Il est important que les supports soient identifiés afin de discerner facilement leur
statut de classification. S'ils ne sont pas identifiés comme confidentiels, les
supports peuvent ne pas être protégés de la manière appropriée ou être perdus ou
volés.
9.7.2 Envoyer les supports par coursier sécurisé ou toute autre
méthode d’expédition qui peut faire l’objet d’un suivi précis.
S'ils sont envoyés sans suivi, par exemple par courrier postal normal, les supports
risquent d'être perdus ou volés. Faire appel aux services d'un coursier sécurisé
pour l'envoi de tout support contenant des données de titulaires de cartes, de
manière à pouvoir utiliser son système de suivi afin d'inventorier et localiser
chaque envoi.
9.8 S’assurer que les responsables approuvent tous les supports
déplacés d’une zone sécurisée (en particulier s’ils sont distribués
à des individus).
Sans un processus approuvé par les responsables, les données de titulaires de
cartes peuvent être perdues ou dérobées hors des zones sécurisées. Sans un
processus strict, il n'est pas possible de suivre l'emplacement des supports, ni de
savoir où se rendent les données ni la manière dont elles sont protégées.
9.9 Assurer un contrôle strict du stockage et de l’accessibilité des
supports.
Sans des méthodes d'inventaire et de contrôles du stockage méticuleux, le vol ou
l'absence de supports pourraient passer inaperçus pendant une période
indéterminée.
Octobre 2010
Page 49
Condition
9.9.1 Tenir de manière appropriée les journaux d’inventaire de
tous les supports et effectuer un inventaire des supports au
moins une fois par an.
9.10 Détruire les supports lorsqu'ils ne sont plus nécessaires à
des fins professionnelles ou légales comme suit :
9.10.1 Déchiqueter, brûler ou réduire en pâte les documents
papier de sorte que les données de titulaires de cartes ne
puissent pas être reconstituées.
9.10.2 Rendre les données de titulaires de cartes sur support
électronique irrécupérables de sorte que les informations ne
puissent pas être reconstituées.
Directive
Si les supports ne font pas l'objet d'un inventaire, leur vol ou leur absence
pourraient passer inaperçus pendant une période indéterminée ou même jamais.
Si les mesures nécessaires ne sont pas prises pour détruire les informations
contenues sur les supports, disques durs, lecteurs portables, CD ou DVD ou
papier, avant leur élimination, des individus malveillants peuvent être en mesure
de récupérer des informations sur les supports éliminés et la sécurité des données
s'en trouverait compromise. Par exemple, des individus malveillants peuvent
utiliser la technique dite du « dumpster diving », qui consiste à fouiller les
poubelles et les corbeilles, afin d'y rechercher des informations utiles pour lancer
une attaque.
L'effacement, la démagnétisation ou la destruction physique (comme le broyage
ou l'effacement définitif du disque dur) sont des exemples de méthodes permettant
la destruction sécurisée de supports électroniques.
Octobre 2010
Page 50
Directives relatives aux conditions 10 et 11 : Surveillance et test réguliers des réseaux
Condition 10 : Effectuer le suivi et surveiller tous les accès aux ressources réseau et aux données des titulaires de cartes
Les mécanismes de journalisation et la possibilité de suivre les activités des utilisateurs sont essentiels pour prévenir, détecter ou minimiser
l'impact d'une altération des données. La présence de journaux dans tous les environnements permet de suivre de près, d'émettre des alertes et
d'analyser les incidents éventuels. En l'absence de journaux retraçant les activités du système, il est très difficile, sinon impossible, de déterminer
la cause d’une anomalie.
Condition
Directive
10.1 Définir un processus pour associer chaque accès aux
composants du système (en particulier les accès avec des droits
administrateur, tels que root) à chaque utilisateur individuel.
Il est essentiel de disposer d'un processus ou d'un système qui établisse le lien
entre l'accès d'un utilisateur et les composants du système auxquels il a accédé,
en particulier pour les utilisateurs disposant de privilèges administratifs. Ce
système génère des registres d'audit et permet de retracer les activités suspectes
jusqu'à un utilisateur particulier. Les équipes d'enquête après incident dépendent
principalement de ces registres pour lancer leur investigation.
10.2 Mettre en œuvre des vérifications à rebours automatisées
pour tous les composants du système afin de reconstituer les
événements suivants :
La vérification à rebours des activités suspectes alertent l'administrateur système,
envoie les données à d'autres mécanismes de surveillance (comme des systèmes
de détection d'intrusion) et établissent un historique pour le suivi après incident.
Consigner les événements suivants permet à l'organisation d'identifier et de
retracer des activités potentiellement malveillantes.
10.2.1 Tous les accès des utilisateurs aux données des
titulaires de cartes
Les individus malveillants peuvent avoir connaissance d'un compte utilisateur et
obtenir l'accès aux systèmes de l'environnement des données de titulaires de
cartes ou créer un nouveau compte, non autorisé, afin d'accéder à ces données.
Enregistrer tous les accès individuels aux données de titulaires de cartes permet
d'identifier les comptes compromis ou utilisés de manière illicite.
10.2.2 Toutes les actions exécutées par tout utilisateur avec
des droits root ou administrateur
Les comptes possédant des privilèges accrus, comme les comptes
« administrateur » ou « root », sont potentiellement plus dangereux pour la
sécurité ou la fonctionnalité opérationnelle d'un système s'ils venaient à être
compromis. Sans un journal des activités exécutées, une organisation est
incapable de remonter à un acte spécifique individuel en cas de problème résultant
d'une erreur administrative ou d'une utilisation illicite d'un privilège.
10.2.3 Accès à toutes les vérifications à rebours
Des utilisateurs malveillants tentent souvent de modifier les journaux d'audit afin
de dissimuler leurs activités et un enregistrement des accès permet à une
organisation de retracer toutes les incohérences ou altérations potentielles des
journaux pour un compte individuel.
Octobre 2010
Page 51
Condition
Directive
10.2.4 Tentatives d’accès logique non valides
Les individus malveillants font souvent plusieurs tentatives pour accéder aux
systèmes ciblés. De nombreuses tentatives infructueuses de connexion peuvent
indiquer qu'un utilisateur non autorisé tente d'utiliser la « force brute » ou de
deviner un mot de passe.
10.2.5 Utilisation des mécanismes d’identification et
d’authentification
Si l'on ne dispose pas du moyen de savoir qui était connecté au moment de
l'incident, il est impossible d'identifier les comptes qui ont pu être utilisés. En outre,
les utilisateurs malveillants peuvent tenter de manipuler les contrôles
d'authentification avec l'intention de les contourner ou d'usurper un compte valide.
Les activités comprenant, sans y être limitées, un accroissement de privilège ou
des modifications des autorisations d'accès peuvent indiquer une utilisation non
autorisée des mécanismes d'authentification du système.
10.2.6 Initialisation des journaux d’audit
Désactiver les journaux d'audit avant de se livrer à des activités illicites est un
objectif courant des individus mal intentionnés souhaitant éviter d'être détectés.
L'initialisation des journaux d'audit peut indiquer que la fonction de journalisation a
été désactivée par un utilisateur pour dissimuler son activité.
10.2.7 Création et suppression d’objets au niveau système
Souvent, un logiciel malveillant crée ou remplace des objets au niveau système,
sur le système visé, afin de prendre le contrôle d'une fonction particulière ou de
l'activité de ce système.
Pour obtenir la définition de « objets au niveau système », consulter le Glossaire
des termes, abréviations et acronymes PCI DSS et PA-DSS.
10.3 Consigner dans les vérifications à rebours au moins les
entrées suivantes pour chaque événement :
10.3.1 Identification de l'utilisateur
Enregistrer ces détails pour les événements vérifiables au point 10.2 permet
d'identifier rapidement une intrusion éventuelle, avec suffisamment de détails pour
connaître l'auteur, l'objet, l'emplacement, le moment et la méthode employée.
10.3.2 Type d’événement
10.3.3 Date et heure
10.3.4 Indication de succès ou d'échec
10.3.5 Origine de l’événement
10.3.6 Identité ou nom des données, du composant du système
ou de la ressource affectés
Octobre 2010
Page 52
Condition
Directive
10.4 À l'aide d'une technologie de synchronisation temporelle,
synchroniser tous les systèmes d'horloge et temporels critiques et
s'assurer que les éléments suivants sont mis en œuvre pour
l'acquisition, la distribution et l'enregistrement du temps.
La technologie de synchronisation temporelle permet de synchroniser les horloges
de systèmes multiples. Lorsqu'elle est correctement déployée, cette technologie
permet de synchroniser les horloges sur un grand nombre de systèmes avec une
précision de l'ordre de la fraction de seconde. Lorsque les horloges ne sont pas
correctement synchronisées, cela peut entraîner divers problèmes, entre autres,
rendre difficile voire impossible la comparaison des fichiers journaux de systèmes
différents et l'établissement de la séquence exacte d'un événement (un point
crucial pour les analyses légales en cas de violation du système), ou encore
empêcher le fonctionnement correct de protocoles cryptographiques, comme SSH,
qui s'appuient sur le temps absolu. Pour les équipes légales enquêtant après un
incident, la précision et l'uniformité de l'heure sur l'ensemble des systèmes et celle
de chaque activité sont essentielles pour déterminer la manière dont les systèmes
ont été compromis.
Remarque : le protocole Network Time Protocol (NTP) est un
exemple de technologie de synchronisation temporelle.
10.4.1 L'heure des systèmes critiques est correcte et la même
pour tous
10.4.2 Les données temporelles sont protégées
10.4.3 Les paramètres temporels sont reçus de sources
temporelles reconnues par le secteur
Afin de garantir une heure uniforme, l'idéal serait qu'il n'existe que peu de serveurs
temporels internes centraux) au sein d'une entreprise. Ces serveurs reçoivent les
données UTC (temps universel coordonné) directement de serveurs temporels
externes, fiables et connus, par radio spéciale, satellites GPS ou toute autre
source réseau externe, et se consultent mutuellement pour s'assurer de maintenir
l'exactitude de l'heure. Les autres systèmes reçoivent alors l'heure de ces
serveurs.
Si un individu malveillant pénètre sur le réseau, il tentera souvent de modifier
l'horodatage de ses actes dans les journaux d'audit afin d'empêcher la détection
de ses activités. Un individu malveillant peut également tenter de changer
directement l'horloge sur un composant système afin de masquer sa présence, par
exemple en réglant l'horloge du système sur une heure antérieure. Pour ces
raisons, il est important que l'heure soit exacte sur l'ensemble des systèmes et que
les données temporelles soient protégées de tout accès et modifications non
autorisés. Les données temporelles comprennent les paramètres et les méthodes
utilisés pour régler l'horloge de chaque système.
Plus d'informations sur le protocole NTP sont disponibles sur www.ntp.org,
notamment des informations sur l'heure, le temps de référence et les serveurs.
10.5 Protéger les vérifications à rebours de sorte qu'elles ne
puissent pas être modifiées.
Un individu malveillant, ayant pénétré sur le réseau, tentera souvent de modifier
les journaux d'audit afin de dissimuler ses activités. Sans une protection adéquate
des journaux d'audit, il ne sera pas possible d'en garantir l'intégralité, l'exactitude
et l'intégrité et ils seront inutiles en tant qu'outil d'investigation une fois le système
compromis.
Octobre 2010
Page 53
Condition
10.5.1 Limiter l’affichage des vérifications à rebours aux
utilisateurs qui en ont besoin pour mener à bien leur travail.
10.5.2 Protéger les fichiers de vérifications à rebours contre
toute modification non autorisée.
10.5.3 Sauvegarder rapidement les fichiers de vérifications à
rebours sur un serveur centralisé réservé à la journalisation ou
sur des supports difficiles à altérer.
Directive
La protection adéquate des journaux d'audit comprend un contrôle d'accès robuste
(accès limité aux journaux en fonction du « besoin d'en connaître ») et l'utilisation
d'un mécanisme d'isolation interne (pour qu'il soit plus difficile de trouver et
modifier les journaux). Renseigner les journaux depuis des technologies orientées
vers l'extérieur, comme le sans fil, les pare-feu, les serveurs DNS et les serveurs
de messagerie, réduit les risques de perte ou de modification de ces journaux, car
ils sont mieux protégés au sein du réseau interne.
10.5.4 Enregistrer les journaux des technologies orientées vers
l’extérieur sur un serveur réservé à la journalisation sur le
réseau local (LAN) interne.
10.5.5 Analyser les journaux à l’aide d’un logiciel de contrôle de
l’intégrité des fichiers ou de détection des modifications pour
s’assurer que les données contenues dans les journaux ne
peuvent pas être modifiées sans entraîner le déclenchement
d’une alerte (alors que l’ajout de nouvelles données ne doit pas
entraîner d’alerte).
Les systèmes de contrôle de l'intégrité des fichiers vérifient et signalent les
modifications apportées aux fichiers stratégiques. Pour contrôler l'intégrité des
fichiers, une entreprise vérifie généralement les fichiers qui ne sont pas
régulièrement modifiés, mais dont la modification indique une intrusion possible.
Dans le cas des fichiers journaux (qui changent fréquemment), ce qu'il faut
contrôler, c'est par exemple leur suppression, une augmentation ou une réduction
soudaine et importante de leur volume et toute autre indication qu'un individu
malveillant les a falsifiés. Il existe des outils prêts à l'emploi et à code source libre
pour le contrôle de l'intégrité des fichiers.
10.6 Passer en revue les journaux relatifs à tous les composants
du système au moins une fois par jour. L’examen des journaux
doit inclure les serveurs exécutant des fonctions des sécurité, tels
que les serveurs IDS (système de détection d'intrusion) et AAA
(Authentication, Authorization, and Accounting) (par exemple,
RADIUS).
De nombreuses violations se produisent des jours ou des mois avant d'être
détectées. La vérification quotidienne des journaux réduit la durée et l'exposition à
une violation potentielle. Le processus d'examen des journaux ne doit pas
forcément être manuel. Les entreprises possédant un grand nombre de serveurs,
en particulier, peuvent envisager d'utiliser des outils de journalisation, d'analyse et
d'alerte.
Remarque : les outils de journalisation, d’analyse et d’alerte
peuvent être utilisés conformément à la condition 10.6.
10.7 Conserver l’historique des vérifications à rebours pendant
une année au moins, en gardant immédiatement à disposition les
journaux des trois derniers mois au moins, pour analyse (par
exemple, disponibles en ligne, dans des archives ou restaurables
à partir d’une sauvegarde).
Les journaux doivent être conservés pendant une année au moins puisqu'il faut un
certain temps avant de s'apercevoir d'une violation et cela permet de donner aux
enquêteurs un historique des informations de volume suffisant pour déterminer la
durée d'une violation potentielle et du ou des systèmes éventuellement affectés.
En gardant immédiatement à disposition les journaux des trois derniers mois au
moins, une analyse peut rapidement identifier et minimiser l'impact d'une violation
des données. Le stockage des bandes de sauvegarde hors site peut retarder la
restauration des données, l'exécution d'analyses et l'identification des systèmes ou
des données affectés.
Octobre 2010
Page 54
Condition 11 : Tester régulièrement les processus et les systèmes de sécurité
Des vulnérabilités sont sans cesse découvertes par des individus malveillants et des chercheurs, et sont introduites avec tout nouveau logiciel.
Les composants du système, les processus et les logiciels personnalisés doivent être fréquemment testés afin de s'assurer que les contrôles de
sécurité reflètent toujours les nouveaux environnements.
Condition
Directive
11.1 Tester la présence de points d'accès
sans fil et détecter les points d'accès sans fil
non autorisés tous les trimestres.
La mise en place et/ou l'exploitation de la technologie sans fil sur un réseau sont l'une des voies les
plus fréquentes utilisées par les utilisateurs malveillants pour accéder au réseau et aux données de
titulaires de cartes. Si un périphérique ou un réseau sans fil est installé à l'insu d'une société, il peut
permettre à un pirate de pénétrer facilement sur le réseau, à l'insu de tous.
Remarque : les analyses de réseau sans fil,
les inspections logiques/physiques des
composants du système et de l'infrastructure,
le contrôle d'accès réseau (NAC) ou les
systèmes de détection et/ou de prévention
d’intrusions sans fil sont quelques exemples
de méthodes pouvant être utilisées pour ce
processus.
Quelle que soit la méthode utilisée, elle doit
être suffisante pour détecter et identifier tous
les dispositifs non autorisés.
Des dispositifs sans fil non autorisés peuvent être dissimulés dans, ou connectés à, un ordinateur ou
à un autre composant du système, ou encore être directement connectés à un port ou à un dispositif
du réseau, comme un commutateur ou un routeur. Un tel dispositif non autorisé peut constituer un
point d'accès non autorisé à l'environnement.
En raison de la facilité avec laquelle un point d'accès sans fil peut être connecté à un réseau, de la
difficulté à détecter leur présence et du risque accru associé aux équipements sans fil non autorisés,
ces processus doivent être exécutés même s'il existe une politique interdisant l'usage de la
technologie sans fil.
La taille et la complexité d'un environnement particulier déterminent les outils et processus appropriés
à utiliser afin de fournir une garantie suffisante qu'un point d'accès mal intentionné n'a pas été installé
dans l'environnement.
Par exemple : dans le cas d'un simple terminal autonome dans un centre commercial, où tous les
composants de communication sont contenus dans des boîtiers inviolables et comportant des
dispositifs pour rendre les effractions évidentes, une inspection physique détaillée du terminal luimême peut suffire à s'assurer qu'aucun point d'accès frauduleux n'y a été branché ni installé.
Cependant, dans un environnement comportant des nœuds multiples (comme un grand magasin de
détail, un centre d'appels, une salle de serveur ou un centre de données), il est plus difficile
d'effectuer une inspection physique détaillée en raison du nombre de composants du système et des
points réseau où un dispositif d'accès malveillant pourrait avoir été installé ou dissimulé. Dans ce cas,
diverses méthodes peuvent être combinées afin de remplir les conditions, par exemple, effectuer des
inspections physiques du système conjointement aux résultats d'un analyseur sans fil.
Les solutions de contrôle d'accès au réseau (Network access control – NAC) peuvent gérer
l'authentification et la configuration du dispositif afin d'empêcher des systèmes non autorisés de se
connecter au réseau, ou des dispositifs non autorisés de se connecter à des systèmes autorisés du
réseau.
Une entreprise doit disposer, dans le cadre de son plan de réponse aux incidents, de procédures
documentées à suivre en cas de détection d'un point d'accès sans fil non autorisé. Un système de
détection et/ou de prévention des intrusions (IDS/IPS) sans fil doit être configuré pour générer
automatiquement une alerte, mais le plan doit également comporter des procédures de réponse en
Octobre 2010
Page 55
Condition
Directive
cas de détection d'un équipement non autorisé au cours d'une analyse manuelle.
11.2 Analyser les vulnérabilités potentielles
des réseaux internes et externes au moins
une fois par trimestre et après tout
changement significatif des réseaux (par
exemple, installation de nouveaux
composants du système, modification de la
topologie du réseau ou des règles des parefeu, mise à niveau de produits).
L'analyse des vulnérabilités est un outil automatisé exécuté sur les équipements et les serveurs
réseau internes et externes, conçu pour exposer les vulnérabilités potentielles des réseaux qui
pourraient être détectés et exploités par des individus malveillants. Une fois ces faiblesses identifiées,
l'entreprise doit y remédier et répéter l'analyse afin de vérifier qu'elles ont bien été résolues.
Remarque : il n'est pas obligatoire que quatre
analyses trimestrielles aient été réalisées avec
succès pour la vérification de conformité PCI
DSS initiale si l’évaluateur vérifie que 1) le
résultat de la dernière analyse était réussi, 2)
l’entité a documenté les politiques et les
procédures exigeant l’exécution d’analyses
trimestrielles, et 3) toutes les vulnérabilités
relevées dans les résultats ont été corrigées,
comme indiqué lors de la réexécution de
l'analyse. Pendant les années qui suivent la
vérification PCI DSS initiale, quatre analyses
trimestrielles réussies doivent avoir été
réalisées.
Lors de l'évaluation PCI DSS initiale de l'entreprise, il est possible que les quatre analyses
trimestrielles n'aient pas encore été exécutées. Si les résultats de l'analyse la plus récente satisfont
aux critères et si des politiques et des procédures sont en place pour les futures analyses
trimestrielles, cette condition est considérée comme remplie. Il n'est donc pas nécessaire, dans le
cadre de cette condition, de différer l'évaluation sur site parce que les quatre analyses trimestrielles
n'ont pas été effectuées.
Octobre 2010
Page 56
Condition
11.2.1 Effectuer des analyses trimestrielles
de vulnérabilité interne.
Directive
Un processus établi, destiné à identifier les vulnérabilités de systèmes internes à l'environnement des
données de titulaires de cartes, exige que des analyses de vulnérabilité soient effectuées
trimestriellement. Identifier les vulnérabilités et y remédier en temps opportun réduit la probabilité
qu'elles soient exploitées et permettent de compromettre un composant de système ou des données
des titulaires de cartes.
Les vulnérabilités constituant le risque le plus important pour l'environnement (par exemple, celles
classées à « haut risque » aux termes de la condition 6.2) doivent être résolues en priorité absolue.
Les réseaux internes changeant constamment au cours de l'année, il est possible qu'une entreprise
n'applique pas régulièrement des analyses de vulnérabilités internes. L'objectif est de faire en sorte
qu'une entreprise dispose d'un programme robuste de gestion des vulnérabilités pour remédier aux
vulnérabilités décelées dans un délai raisonnable. Au minimum, les vulnérabilités à « haut risque »
doivent être résolues dans les meilleurs délais.
Les analyses de vulnérabilités internes peuvent être exécutées par un personnel interne qualifié,
raisonnablement indépendant du ou des composants de système analysés (par exemple, un
administrateur de pare-feu ne doit pas être chargé d'analyser le pare-feu), mais une entreprise peut
choisir de faire exécuter ces analyses par un prestataire de services d’analyse agréé (ASV, Approved
Scanning Vendor) par le PCI SSC, un QSA ou toute autre firme spécialisée dans l'analyse des
vulnérabilités.
11.2.2 Des analyses de vulnérabilité externe
doivent être effectuées une fois par trimestre
par un prestataire de services d’analyse
agréé par le PCI SSC (Payment Card
Industry Security Standards Council).
Les réseaux externes étant plus exposés, l'analyse trimestrielle de vulnérabilités externes doit être
exécutées par un prestataire de services d’analyse agréé (ASV) par le PCI SSC.
Ces prestataires doivent suivre un ensemble de critères d'analyse et de compte-rendu, établis par le
PCI SSC dans son guide programme des prestataires de services d’analyse agréés.
Remarque : des analyses de vulnérabilité
externe doivent être effectuées une fois par
trimestre par un prestataire de services
d’analyse agréé (ASV) par le PCI SSC
(Payment Card Industry Security Standards
Council). Les analyses réalisées après la
modification des réseaux peuvent être
effectuées par le personnel interne.
11.2.3 Effectuer des analyses internes et
externes après tout changement
d'importance.
Remarque : les analyses réalisées après un
changement peuvent être effectuées par le
personnel interne.
L'analyse d'un environnement, après avoir apporté des modifications d'importance à ce dernier,
garantit que les modifications ont été réalisées de la manière appropriée et que la sécurité de
l'environnement n'a pas été compromise à la suite de ces modifications. Il n'est pas toujours
nécessaire d'analyser la totalité de l'environnement après une modification. Tous les composants du
système affectés par les modifications doivent cependant être analysés.
Octobre 2010
Page 57
Condition
Directive
11.3 Effectuer des tests de pénétration
externe et interne au moins une fois par an et
après tout changement ou mise à niveau
significatif de l’infrastructure ou des
applications (par exemple, mise à niveau du
système d’exploitation ou ajout d’un sousréseau ou d’un serveur Web dans
l’environnement). Ces tests de pénétration
doivent inclure ce qui suit :
L'objectif d'un test de pénétration est de simuler une attaque en conditions réelles dans le but
d'identifier jusqu'où un pirate pourrait pénétrer dans un environnement donné. Ceci permet à une
entreprise d'avoir une meilleure compréhension de son exposition éventuelle au risque et de
développer une stratégie de défense contre les attaques.
11.3.1 Tests de pénétration de la couche
réseau
11.3.2 Tests de pénétration de la couche
application
Un test de pénétration diffère d'une analyse de vulnérabilité, car le test est un processus actif pouvant
comprendre l'exploitation de vulnérabilités identifiées. Souvent, exécuter une analyse de vulnérabilité
est l'une des premières étapes du test de pénétration afin d'intégrer une stratégie d'attaque. Même si
l'analyse de vulnérabilité ne détecte pas de vulnérabilités connues, la personne exécutant le test de
pénétration obtiendra suffisamment d'informations sur le système pour identifier les lacunes
éventuelles dans la sécurité.
Le test de pénétration est généralement un processus en grande partie manuel. Bien qu'il existe
certains outils automatisés, la personne réalisant le test doit utiliser sa connaissance des systèmes
pour pénétrer dans un environnement. Souvent elle appliquera plusieurs types d'exploits ensemble
dans le but de franchir plusieurs couches de défenses. Par exemple, si elle trouve un moyen
d'accéder à un serveur d'application, elle utilisera ensuite le serveur compromis comme point de
départ pour lancer une nouvelle attaque en fonction des ressources auxquelles le serveur a accès. De
cette manière, la personne effectuant le test est en mesure de simuler les méthodes utilisées par un
pirate afin d'identifier les zones de faiblesse potentielles de l'environnement, auxquelles il faut
remédier.
Octobre 2010
Page 58
Condition
Directive
11.4 Utiliser des systèmes de détection
d’intrusions et/ou des systèmes de prévention
d’intrusions pour contrôler l'intégralité du trafic,
ainsi que les points critiques, dans
l’environnement des données de titulaires de
cartes et signaler au personnel tous les
soupçons portant sur des altérations
potentielles.
Les outils de détection d’intrusions et/ou de prévention d’intrusions (IDS/IPS) comparent le trafic
entrant sur le réseau aux « signatures » connues et/ou aux comportements de milliers de types de
violations (outils de piratage, chevaux de Troie et autres programmes malveillants), envoient des
alertes et/ou bloquent la tentative. Sans une approche préventive de la détection des activités non
autorisées à l'aide de ces outils, les attaques (ou l'utilisation frauduleuse) des ressources d'un
ordinateur pourraient passer inaperçues au moment où elles se produisent. Les alertes de sécurité
générées par ces outils doivent être contrôlées de manière à pouvoir bloquer les tentatives d'intrusion.
Tenir à jour tous les moteurs de détection et
de prévention des intrusions, les références et
les signatures.
Les dispositifs IDS/IPS doivent être déployés de manière à surveiller le trafic entrant et sortant du
périmètre de l'environnement des données des titulaires de cartes, ainsi que les points critiques de ce
dernier. Les points critiques à l'intérieur de l'environnement des données de titulaires de cartes
peuvent comprendre les serveurs de base de données, le lieu de stockage des clés cryptographiques,
les réseaux de traitement ou tout autre composant de système sensible, déterminés par
l'environnement de l'entreprise et documentés dans son évaluation des risques.
Alors que de nombreux dispositifs IDS/IPS sont aujourd'hui capables de surveiller des points multiples
à l'intérieur de l'environnement des données de titulaires de cartes grâce à un seul dispositif, il est
important de rappeler l'exposition accrue en cas de défaillance de ce seul dispositif. Il est donc
important d'intégrer les redondances appropriées dans l'infrastructure IDS/IPS.
Il existe des milliers de types de violations et chaque jour, on en découvre de nouvelles. Les
signatures périmées et les moteurs d'analyse des dispositifs IDS/IPS n'auront pas la capacité
d'identifier les nouvelles vulnérabilités pouvant conduire à une effraction non détectée. Les
fournisseurs de ces produits publient des mises à jour fréquentes, souvent quotidiennes, qui doivent
être évaluées et appliquées régulièrement.
Octobre 2010
Page 59
Condition
Directive
11.5 Déployer des logiciels de contrôle de
l’intégrité des fichiers pour alerter le personnel
de toute modification non autorisée des
fichiers de configuration, des fichiers de
contenu ou des fichiers système stratégiques,
et configurer ces logiciels pour effectuer des
comparaisons entre les fichiers stratégiques
au moins une fois par semaine.
Les outils de contrôle de l'intégrité des fichiers (FIM) vérifient et signalent les modifications apportées
aux fichiers stratégiques. Il existe des outils prêts à l'emploi et à code source libre pour le contrôle de
l'intégrité des fichiers. S'ils ne sont pas correctement appliqués et les résultats FIM contrôlés, un
individu malveillant pourrait modifier le contenu des fichiers de configuration, les programmes du
système d'exploitation ou les fichiers exécutables des applications. Ces modifications non autorisées,
si elles ne sont pas détectées, peuvent rendre inutiles les contrôles de sécurité existants et/ou aboutir
au vol des données de titulaires de cartes sans aucun impact perceptible au niveau du traitement
normal.
Remarque : pour le contrôle de l’intégrité des
fichiers, les fichiers stratégiques sont
généralement ceux qui ne changent pas
régulièrement, mais dont la modification
pourrait indiquer une altération du système ou
son exposition à des risques. Les produits de
contrôle de l’intégrité des fichiers sont
généralement préconfigurés avec les fichiers
stratégiques pour le système d’exploitation
associé. D’autres fichiers stratégiques, tels
que ceux associés aux applications
personnalisées, doivent être évalués et définis
par l’entité (c’est-à-dire le commerçant ou le
prestataire de services).
Octobre 2010
Page 60
Directives relatives à la condition 12 : Gestion d’une politique de sécurité des informations
Condition 12 : Gérer une politique de sécurité des informations pour l'ensemble du personnel
Une politique de sécurité robuste définit la sécurité mise en œuvre à l'échelle de l'entreprise et indique aux employés ce que l'on attend d’eux.
Tout le personnel doit être sensibilisé au caractère confidentiel des données et à ses responsabilités dans la protection de ces informations. Dans
le cadre de cette condition 12, le terme « personnel » désigne les employés à temps plein et à temps partiel, les intérimaires ainsi que les soustraitants et les consultants qui « résident » sur le site de l'entité ou ont accès d'une manière ou d'une autre à l'environnement des données des
Condition
Directive
12.1 Définir, publier, gérer et diffuser une politique de sécurité qui
remplit les fonctions suivantes :
La politique de sécurité des informations d'une entreprise génère la feuille de route
de l'application des mesures de sécurité afin de protéger ses ressources les plus
précieuses. Une politique de sécurité robuste définit la sécurité mise en œuvre à
l'échelle de la société et indique au personnel ce que l'on attend de lui. Tout le
personnel doit être sensibilisé au caractère confidentiel des données et à ses
responsabilités dans la protection de ces informations.
12.1.1 Satisfait à toutes les conditions de la norme PCI DSS.
12.1.2 Inclut un processus annuel qui identifie les menaces et
les vulnérabilités, et débouche sur une évaluation formelle des
risques (les directives OCTAVE, ISO 27005 and NIST SP 80030 sont des exemples de méthodologies d'évaluation du
risque).
Une évaluation du risque permet à une organisation d'identifier les menaces et les
vulnérabilités associées, pouvant avoir un impact négatif potentiel sur son activité.
Des ressources peuvent alors être effectivement affectées pour mettre en place
des contrôles qui réduisent la probabilité et/ou l'impact potentiel de la menace.
12.1.3 Comprend au moins un examen annuel avec une mise à
jour chaque fois que l’environnement change.
Les menaces concernant la sécurité et les méthodes de protection changent
rapidement tout au long de l'année. Sans une mise à jour de la politique de
sécurité afin de refléter ces changements, les nouvelles mesures de protection
contre ces menaces sont inutiles.
12.2 Élaborer des procédures de sécurité opérationnelles
quotidiennes conformes aux exigences de cette spécification (par
exemple, des procédures de gestion des comptes d’utilisateur et
des procédures d’examen des journaux).
Effectuer annuellement des évaluations du risque permet à l'organisation de rester
à jour en ce qui concerne les changements organisationnels et l'évolution des
menaces, des tendances et des technologies.
Les procédures de sécurité opérationnelles quotidiennes font office « d'instructions
générales » que le personnel doit suivre dans le cadre de ses activités
quotidiennes d'administration et de maintenance des systèmes. Si les procédures
de sécurité opérationnelles ne sont pas documentées, le personnel ne connaît pas
le champ d'application global de ses tâches, les processus ne peuvent pas être
reproduits facilement par les nouvelles recrues et les lacunes potentielles de ces
processus peuvent être exploitées par un individu malveillant pour accéder aux
ressources et aux systèmes stratégiques.
Octobre 2010
Page 61
Condition
Directive
12.3 Élaborer les politiques d’utilisation des technologies
stratégiques (par exemple, technologies d’accès à distance,
technologies sans fil, supports électroniques amovibles,
ordinateurs portables, assistants numériques personnels (PDA),
utilisation du courrier électronique et d’Internet) et définir l'usage
approprié de ces technologies. S’assurer que ces politiques
d’utilisation exigent ce qui suit :
Les politiques d'utilisation par le personnel peuvent interdire l'usage de certains
équipements et autres technologies si c'est la politique de la société, ou donner au
personnel des directives d'utilisation et d'application appropriées. Si ces politiques
d'utilisation n'existe pas, le personnel peut utiliser des technologies enfreignant la
politique de la société, permettant ainsi à des individus malveillants d'accéder aux
systèmes stratégiques et aux données de titulaires de cartes. Par exemple, ils
peuvent configurer sans le savoir des réseaux sans fil n'intégrant aucun
mécanisme de sécurité. Pour garantir que les normes de la société sont
respectées et que seules les technologies approuvées sont appliquées, envisager
de restreindre leur déploiement aux équipes d'exploitation et d'interdire au
personnel non spécialisé/général d'installer ces technologies.
12.3.1 Approbation explicite des responsables
Si l'approbation appropriée d'application de ces technologies n'est pas exigée, un
employé peut, en toute innocence, installer une solution dont il estime avoir besoin
pour son activité, mais ouvrir en même temps une brèche importante qui expose
les données et les systèmes stratégiques à des individus malveillants.
12.3.2 Authentification pour l'utilisation des technologies
Si la technologie est mise en œuvre sans une authentification appropriée (ID
utilisateur et mots de passe, tokens, VPN, etc.), des individus malveillants peuvent
facilement utiliser cette technologie non protégée pour accéder aux systèmes
stratégiques et aux données de titulaires de cartes.
12.3.3 Liste de tous les périphériques et du personnel
disposant d'un accès
Des individus malveillants peuvent violer la sécurité physique et placer leurs
propres équipements sur le réseau sous forme de « porte dérobée ». Le personnel
peut également contourner les procédures et installer ses propres dispositifs.
L'inventaire précis des équipements, avec un étiquetage approprié, permet
d'identifier rapidement les installations non approuvées. Envisager d'établir une
convention de dénomination officielle des équipements et de tous les étiqueter et
de les consigner conjointement aux contrôles d'inventaires mis en place.
L'étiquetage logique peut également être utilisé pour des informations comme des
codes pouvant établir le lien entre un dispositif et son propriétaire, indiquer ses
coordonnées et son objectif.
12.3.4 Indication sur les périphériques du nom de leur
propriétaire, de ses coordonnées et de leur usage
12.3.5 Usages acceptables de la technologie
12.3.6 Emplacements acceptables des technologies sur le
réseau
12.3.7 Liste des produits approuvés par la société
12.3.8 Déconnexion automatique des sessions des
technologies d’accès à distance après une période d'inactivité
spécifique
En définissant l'usage professionnel acceptable et l'emplacement des équipements
et des technologies approuvés par la société, cette dernière pourra mieux gérer et
contrôler les failles des configurations et des contrôles opérationnels, afin de
s'assurer qu'aucune « porte dérobée » n'est ouverte pour permettre l'accès d'un
individu malveillant aux systèmes stratégiques et aux données de titulaires de
cartes.
Les technologies d'accès à distance constituent souvent des « portes dérobées »
vers les ressources stratégiques et données de titulaires de cartes. Déconnecter
ces technologies à distance lorsqu'elles ne sont pas utilisées (par exemple, celles
Octobre 2010
Page 62
Condition
Directive
12.3.9 Activation des technologies d’accès à distance pour les
fournisseurs et les partenaires commerciaux, uniquement
lorsque c'est nécessaire, avec désactivation immédiate après
usage
utilisées pour la maintenance des systèmes par les fournisseurs de points de
vente et autres ou les partenaires commerciaux), permet de réduire l'accès au
réseau et le risque afférent. Envisager de mettre en place des contrôles pour
déconnecter les équipements après 15 minutes d'inactivité. Consulter également
la condition 8.5.6 pour plus d'informations à ce sujet.
12.3.10 Interdire au personnel accédant aux données de
titulaire de carte au moyen de technologies d'accès à distance
la copie, le déplacement et le stockage de données de titulaires
de cartes sur des disques durs locaux et des supports
électroniques amovibles, sauf autorisation expresse pour des
besoins professionnels.
Pour s'assurer que l'ensemble du personnel est bien conscient qu'il ne doit pas
stocker ni copier les données de titulaires de cartes sur un ordinateur local
personnel ni sur aucun autre support, la politique de l'entreprise doit clairement
interdire ces activités, sauf pour le personnel qui y est expressément autorisé. Ce
personnel autorisé a la responsabilité de garantir que les données de titulaires de
cartes en sa possession sont gérées conformément à toutes les conditions de la
norme PCI DSS, puisque l'environnement de ce personnel à distance est
maintenant considéré comme partie intégrante de l'environnement des données de
titulaires de cartes de l'organisation.
12.4 S’assurer que la politique et les procédures de sécurité
définissent clairement les responsabilités de tout le personnel en
la matière
Sans une définition claire des responsabilités et des rôles en matière de sécurité,
l'interaction avec le groupe chargé de la sécurité peut être incohérente, conduisant
alors au déploiement non sécurisé de technologies ou à l'usage de technologies
obsolètes ou non sécurisées.
12.5 Attribuer à un individu ou à une équipe les responsabilités
suivantes de gestion de la sécurité des informations :
Chaque individu ou équipe responsable de la gestion de la sécurité des
informations doit avoir parfaitement conscience de ses responsabilités et des
tâches associées, grâce à une politique spécifique. Sans cette responsabilisation,
les lacunes dans les processus peuvent donner accès aux ressources stratégiques
et aux données de titulaires de cartes.
12.5.1 Définir, documenter et diffuser les politiques et les
procédures de sécurité.
12.5.2 Contrôler et analyser les informations et les alertes de
sécurité, et les diffuser au personnel compétent.
12.5.3 Définir, documenter et diffuser les procédures de
remontée et de réponse aux incidents liés à la sécurité pour
garantir une gestion rapide et efficace de toutes les situations.
12.5.4 Administrer les comptes d’utilisateur, notamment l’ajout,
la suppression et la modification de comptes
12.5.5 Surveiller et contrôler tous les accès aux données.
12.6 Mettre en œuvre un programme formel de sensibilisation à
la sécurité pour sensibiliser les employés à l'importance de la
sécurité des données de titulaires de cartes.
Si le personnel n'est pas sensibilisé à ses responsabilités en matière de sécurité,
les processus et les protections mis en place peuvent s'avérer inefficaces en
raison des erreurs commises ou d'actes délibérés.
Octobre 2010
Page 63
Condition
12.6.1 Sensibiliser le personnel au moment du recrutement et
au moins une fois par an.
Remarque : les méthodes varient selon les postes occupés et
le niveau d'accès du personnel aux données des titulaires de
cartes.
Directive
Si le programme de sensibilisation à la sécurité ne comporte pas de sessions
annuelles de mise à niveau, les processus et procédures essentiels de sécurité
pourront être oubliés ou ignorés, exposant alors des ressources stratégiques et
des données de titulaires de cartes. L'orientation et l'importance des formations
initiale et de remise à niveau varient en fonction des postes occupés par le
personnel et doivent être adaptés comme il convient selon les personnes
auxquelles elles sont destinées. Par exemple, des sessions destinées à des
administrateurs de bases de données doivent se concentrer sur des contrôles
techniques spécifiques, alors que la formation de caissiers de détail s'attachera
aux procédures de transactions sécurisées.
Envisager d'intégrer des mises à jour permanentes de sensibilisation afin que le
personnel reste au courant des politiques et procédures en cours. La méthode de
formation peut également varier pour s'adapter à un public particulier. Par
exemple, les formations initiale et annuelle peuvent être effectuées par le biais
d'ateliers pratiques ou par des sessions de formation assistées par ordinateur, tout
en délivrant des mises à jour périodiques permanentes par courrier électronique,
des affiches ou des bulletins d'information, etc.
12.6.2 Exiger que le personnel reconnaisse au moins une fois
par an avoir lu et compris les procédures et la politique de
sécurité.
12.7 Effectuer une sélection préalable à l'embauche du personnel
pour minimiser les risques d'attaques par des sources internes
(Ces contrôles devraient inclure, par exemple, les antécédents
professionnels, le casier judiciaire, les renseignements de
solvabilité et la vérification des références).
Remarque : pour le personnel dont l'embauche potentielle
concerne des postes tels que celui de caissier dans un magasin,
et qui n’a accès qu’à un numéro de carte à la fois à l'occasion du
traitement d'une transaction, cette condition n'est qu'une
recommandation.
Exiger une reconnaissance écrite ou par voie électronique permet de s'assurer
que les politiques et procédures de sécurité ont bien été lues et comprises et de
l'engagement passé et futur du personnel à les respecter.
La vérification approfondie des antécédents avant toute embauche de personnel
amené à accéder aux données de titulaires de cartes réduit le risque d'une
utilisation non autorisée des PAN et autres données de titulaires de cartes par des
individus avec des antécédents criminels ou discutables. Une entreprise doit
disposer d'une politique et d'un processus de vérification des antécédents du
personnel, y compris un processus de décision qui lui est propre concernant les
résultats pouvant affecter la décision d'embauche (et lui permettant d'en
déterminer l'impact).
Pour être efficace, le degré de vérification des antécédents doit être adapté au
poste concerné. Par exemple, les postes impliquant une plus grande
responsabilité ou ayant un accès administratif à des données ou à des systèmes
critiques peuvent mériter une vérification plus approfondie que les postes dont les
responsabilités et les niveaux d'accès sont moindres. Il peut également être
approprié que le processus couvre les mutations internes, lorsqu'un employé,
occupant un poste de risque moins élevé sans avoir jamais subi une vérification
détaillée de ses antécédents, est promu ou muté à un poste avec une
responsabilité ou un accès plus important.
Octobre 2010
Page 64
Condition
Directive
12.8 Si les données de titulaires de cartes sont partagées avec
des prestataires de services, gérer et mettre en œuvre des
politiques et des procédures de gestion de ces derniers, de
manière à inclure :
Si un commerçant ou un prestataire de services partage des données de titulaires
de cartes avec un autre prestataire de services, certaines conditions s'appliquent
afin de garantir que chacun d'eux appliquera une protection permanente de ces
données.
12.8.1 Tenir une liste des prestataires de services.
Conserver un suivi de tous les prestataires de services permet d'identifier jusqu'où
s'étendent les risques potentiels à l'extérieur de l'entreprise.
12.8.2 Faire signer aux prestataires de services un accord écrit
par lequel ils se reconnaissent responsables de la sécurité des
données de titulaires de cartes en leur possession.
Par cet accord, les prestataires de services reconnaissent leur engagement à
assurer la sécurité appropriée des données de titulaires de cartes obtenues auprès
de leurs clients, et leurs responsabilités à cet égard.
12.8.3 S’assurer que le processus de sélection des prestataires
de services est bien défini, et qu’il inclut notamment des
contrôles préalables à l'engagement.
Ce processus garantit que le choix du prestataire de services a été vérifié en
interne par l'organisation, et doit comporter une analyse des risques avant d'établir
une relation formelle quelconque avec ce prestataire.
12.8.4 Mettre en place un programme qui contrôle la conformité
des prestataires de services à la norme PCI DSS au moins une
fois par an.
Connaître le statut du prestataire de services en termes de conformité à la norme
PCI DSS garantit qu'il respecte les mêmes conditions que celles à laquelle
l'entreprise est assujettie.
Si le prestataire de services offre des services divers, cette condition s'applique
uniquement aux services réellement fournis au client et aux services qui sont dans
le champ d'application de l'évaluation PCI DSS du client. Par exemple, si un
prestataire de services propose des pare-feu et des services IDS et ISP, un client
n'utilisant que le pare-feu et le service IDS ne devra inclure que ces services dans
le champ d'application de leur évaluation PCI DSS.
12.9 Mettre en œuvre un plan de réponse aux incidents. Être prêt
à réagir immédiatement à toute intrusion dans le système.
Sans un plan détaillé de réponse aux incidents, correctement diffusé, lu et compris
par les parties responsables, une certaine confusion et l'absence de réponses
unifiées pourraient entraîner une interruption des activités de l'entreprise, avec une
publicité inutile de la part des médias publics, ainsi que de nouvelles
responsabilités légales.
Octobre 2010
Page 65
Condition
Directive
12.9.1 Élaborer le plan de réponse aux incidents à mettre en
place en cas d'intrusion dans le système. S’assurer que le plan
prévoit au moins les points suivants :
rôles, responsabilités et stratégies de communication et de
contact en cas d’incident, notamment notification des
marques de cartes de paiement, au minimum ;
les procédures de réponse aux incidents spécifiques ;
les procédures de continuité et de reprise des affaires ;
processus de sauvegarde des données ;
analyse des exigences légales en matière de signalement
des incidents ;
couverture et réponses de tous les composants
stratégiques du système ;
la référence ou l’inclusion des procédures de réponse aux
incidents des marques de cartes de paiement.
Le plan de réponse aux incidents doit être complet et comporter tous les éléments
essentiels permettant à la société de réagir efficacement en cas de violation
susceptible d'affecter les données de titulaires de cartes.
12.9.2 Tester le plan au moins une fois par an.
Sans des tests appropriés, des étapes essentielles peuvent être omises et
entraîner une exposition accrue durant un incident.
Si, au cours de l'année écoulée, le plan de réponse aux incidents a été activé dans
son intégralité, couvrant tous les composants de ce plan, un examen détaillé de
l'incident réel et de sa réponse peut suffire à fournir un test convenable. Si seuls
certains composants du plan ont été récemment activés, les composants restants
devront encore être testés. Si aucun composant du plan n'a été activé au cours
des 12 derniers mois, le test annuel devra englober tous les composants du plan.
12.9.3 Désigner le personnel spécifique disponible 24 heures
sur 24 et sept jours sur sept pour répondre aux alertes.
12.9.4 Organiser la formation appropriée du personnel en
charge de la réponse aux violations de la sécurité.
Sans une équipe de réponse aux incidents bien formée et disponible à tout
moment, le réseau peut être gravement endommagé, et les données et les
systèmes stratégiques peuvent être « pollués » par une manipulation inappropriée
des systèmes ciblés. Cela peut empêcher l'enquête réalisée après un incident
d'aboutir. S'il n'existe pas de ressources internes, envisager de sous-traiter ce
service auprès d'un prestataire compétent.
12.9.5 Inclure des alertes des systèmes de détection et de
prévention des intrusions, et de contrôle de l’intégrité des
fichiers.
Ces systèmes de contrôle, axés sur les risques potentiels encourus par les
données, sont essentiels pour agir rapidement afin de prévenir une violation et ils
doivent être intégrés aux processus de réponse aux incidents.
12.9.6 Définir un processus de modification et de
développement du plan de réponse aux incidents en fonction
des leçons apprises, et tenir compte de l'évolution du secteur.
Intégrer au plan de réponse aux incidents les « leçons tirées » après un problème
permet de garder ce plan à jour et de réagir face aux nouvelles menaces et
tendances en matière de sécurité.
Octobre 2010
Page 66
Directives relatives à la condition A.1 : Autres conditions de la norme PCI DSS s’appliquant aux
fournisseurs d’hébergement partagé
Condition A.1 : Les prestataires de services d’hébergement partagé doivent protéger l’environnement des données de
titulaires de cartes
Comme indiqué dans la condition 12.8, tous les prestataires de services qui ont accès aux données de titulaires de cartes (notamment les
prestataires de services d’hébergement partagé) doivent respecter la norme PCI DSS. En outre, la condition 2.4 stipule que les prestataires de
services d’hébergement partagé doivent protéger les données et l'environnement hébergés de chaque entité. En conséquence, les prestataires de
services d’hébergement partagé doivent par ailleurs se conformer aux exigences définies dans cette annexe.
Condition
Directive
A.1 Protéger l’environnement hébergé et les données de chaque
entreprise (c’est-à-dire le commerçant, le prestataire de
services ou toute autre entité), conformément aux
conditions A.1.1 à A.1.4 :
Un prestataire de services d’hébergement doit satisfaire à
ces exigences ainsi qu’aux conditions de toutes les autres
sections pertinentes de la norme PCI DSS.
Remarque : même si un prestataire de services
d’hébergement peut satisfaire ces exigences, le respect par
l'entité qui a recours au prestataire de services
d’hébergement n'est pas garanti. Chaque entité doit se
conformer à la norme PCI DSS et doit valider cette
conformité comme applicable.
L'Annexe A de la norme PCI DSS est destinée aux prestataires de services
d'hébergement partagé qui souhaitent fournir à leurs clients commerçants et/ou
prestataires de services un environnement d'hébergement conforme à cette
norme. Ces étapes doivent être remplies, de même que toutes les autres
conditions concernées de la norme PCI DSS.
A.1.1 S’assurer que chaque entité ne met en œuvre que des
processus n'ayant accès qu'à l'environnement des
données de titulaires de cartes qui la concerne.
Si un commerçant ou un prestataire de services est autorisé à exécuter ses
propres applications sur le serveur partagé, il doit le faire avec l'ID utilisateur du
commerçant ou du prestataire de services, et non en tant qu'utilisateur privilégié.
Un utilisateur privilégié aurait accès aux environnements des données de titulaires
de cartes de tous les autres commerçants et prestataires de services en plus du
sien propre.
A.1.2 Restreindre l'accès et les privilèges de chaque entité à
son seul environnement de données de titulaires de
cartes.
Pour s'assurer que l'accès et les privilèges sont restreints de telle sorte que
chaque commerçant et prestataire de services ne puisse accéder qu'à son propre
environnement de données de titulaires de cartes, tenir compte des facteurs
suivants : (1) privilèges de l'ID utilisateur du serveur Web du commerçant ou du
prestataire de services ; (2) autorisations de lecture, écriture et exécution de
fichiers, éventuellement accordées ; (3) autorisations d'accès en écriture sur les
fichiers binaires du système, éventuellement accordées ; (4) autorisations d'accès
aux fichiers journaux du commerçant et du prestataire de services, éventuellement
accordées ; et (5) contrôles garantissant qu'aucun commerçant ni prestataire de
Octobre 2010
Page 67
Condition
Directive
services ne peut monopoliser les ressources du système.
A.1.3 S’assurer que la journalisation et les vérifications à
rebours sont activées, uniques à l’environnement des
données de titulaires de cartes de chaque entité et
conformes à la condition 10 de la norme PCI DSS.
Dans un environnement d'hébergement partagé, des journaux doivent être
disponibles afin que les commerçants et les prestataires de services puissent
accéder et examiner les journaux spécifiques à leur environnement de données de
A.1.4 Activer les processus d'investigation légale rapide en
cas d'incident dans l’environnement d’un commerçant
ou d’un prestataire de services.
Les fournisseurs d'hébergement partagé doivent disposer de processus
permettant une réponse rapide et simple en cas d'enquête légale après incident, et
permettant un niveau de détail approprié, allant jusqu'à comprendre les
informations sur le commerçant ou le prestataire de services à titre individuel.
Octobre 2010
Page 68
Annexe A :
Norme de sécurité des données PCI : documents connexes
Les documents suivants ont été élaborés pour aider les commerçants et les prestataires de services à comprendre la norme PCI DSS, les
conditions de conformité et leurs responsabilités en la matière.
9
Document
Public visé
Conditions et procédures d'évaluation de sécurité de la norme PCI DSS
Tous les commerçants et les prestataires de services
Navigation dans la norme PCI DSS : comprendre l'objectif des
conditions
Norme de sécurité des données du PCI : Instructions et directives
relatives aux questionnaires d'auto-évaluation
Norme de sécurité des données du PCI : Questionnaire d’autoévaluation A et attestation
Commerçants qualifiés
9
Norme de sécurité des données du PCI : Questionnaire d’autoévaluation B et attestation
9
Norme de sécurité des données du PCI : Questionnaire d’autoévaluation C-VT et attestation
9
Norme de sécurité des données du PCI : Questionnaire d’autoévaluation C et attestation
9
Norme de sécurité des données du PCI : Questionnaire d’autoévaluation D et attestation
Commerçants qualifiés et prestataires de services
Glossaire des termes, abréviations et acronymes PCI DSS et PA-DSS
9
Pour définir le questionnaire d’auto-évaluation approprié, consultez le document Normes de sécurité des données du PCI : Instructions et directives pour le questionnaire d’autoévaluation, « Sélection du SAQ et de l’attestation les plus appropriés pour l'entreprise ».
Octobre 2010
Page 69

Navigation dans la norme PCI DSS v2.0

Transcription

Documents pareils

ADDI DATA

Announcement: Payment Credit Card Industry (PCI)

MT5634ZPX-PCI-U (Page 1)

TÜV SÜD Acertigo Compliance Services - Certificate

Norme de sécurité des données de l`industrie

la version pdf corrigée de cette page

Payvision entre en partenariat avec ControlScan

Carte PCI téléfax / Modem, EXSYS 33149 Carte PCI fax / modem

Spécifications techniques

Psychothérapie Corporelle Intégrée (PCI)