Comprendre l'objectif des conditions

Transcription

1 Payment Card Industry (PCI) Data Security Standard Navigation dans la norme PCI DSS Comprendre l'objectif des conditions Version 2.0 Octobre 2010

2 Modifications apportées au document Date Version Description 1er Octobre 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 Harmonisation du contenu avec la nouvelle norme PCI DSS v2.0 Copyright 2010 PCI Security Standards Council LLC Page 2

3 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 s relatives à la norme PCI DSS...10 s 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 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 s 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 Condition 4 : Crypter la transmission des données des titulaires de cartes sur les réseaux publics ouverts s 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 Condition 6 : Développer et gérer des systèmes et des applications sécurisés s 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 Condition 8 : Affecter un ID unique à chaque utilisateur d ordinateur Condition 9 : Restreindre l accès physique aux données des titulaires de cartes s 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 Condition 11 : Tester régulièrement les processus et les systèmes de sécurité s 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 s 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 Copyright 2010 PCI Security Standards Council LLC Page 3

4 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. Copyright 2010 PCI Security Standards Council LLC Page 4

5 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 : 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. Copyright 2010 PCI Security Standards Council LLC Page 5

6 É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. Copyright 2010 PCI Security Standards Council LLC Page 6

7 Données de compte Données du titulaire de la carte Élément de données Numéro de compte primaire (PAN) Stockage autorisé Oui Rendre illisibles les données de compte stockées selon la condition 3.4 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 magnétique 2 Non Stockage interdit selon condition 3.2 Données d'authentification CAV2/CVC2/CVV2/CID Non sensibles 1 Code/bloc PIN Non Stockage interdit selon condition 3.2 Stockage interdit selon condition 3.2 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. Copyright 2010 PCI Security Standards Council LLC Page 7

8 Emplacement des données de titulaires de cartes et des données d'authentification sensibles Les données d'authentification sensibles correspondent aux données de la bande magnétique (ou piste) 3, au code ou à la valeur de validation de la carte 4, et les données PIN 5. 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 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. 4 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. 5 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. Copyright 2010 PCI Security Standards Council LLC Page 8

9 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 Piste 2 Contient tous les champs des deux pistes, 1 et 2 Jusqu'à 79 caractères de longueur 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. Copyright 2010 PCI Security Standards Council LLC Page 9

10 s relatives à la norme PCI DSS Création et gestion d un réseau sécurisé Condition 1 : Condition 2 : Installer et gérer une configuration de pare-feu pour protéger les données des titulaires de cartes 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 : Condition 4 : Protéger les données de titulaires de cartes stockées 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 : Condition 6 : Utiliser des logiciels ou des programmes antivirus et les mettre à jour régulièrement 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 : Condition 8 : Condition 9 : Restreindre l'accès aux données des titulaires de cartes aux seuls individus qui doivent les connaître Affecter un ID unique à chaque utilisateur d ordinateur Restreindre l accès physique aux données des titulaires de cartes Surveillance et test réguliers des réseaux Condition 10 : Condition 11 : Effectuer le suivi et surveiller tous les accès aux ressources réseau et aux données des titulaires de cartes 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 Copyright 2010 PCI Security Standards Council LLC Page 10

11 s 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 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 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. Copyright 2010 PCI Security Standards Council LLC Page 11

12 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 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 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 Description des groupes, des rôles et des responsabilités pour la gestion logique des composants réseau 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. 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. 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. 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. Copyright 2010 PCI Security Standards Council LLC Page 12

13 1.1.6 Nécessité d examiner les règles des pare-feu et des routeurs au moins tous les six mois 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é Restreindre le trafic entrant et sortant au trafic nécessaire à l environnement des données des titulaires de cartes Sécuriser et synchroniser les fichiers de configuration des routeurs. 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. 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. 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. Copyright 2010 PCI Security Standards Council LLC Page 13

14 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. 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 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 Limiter le trafic Internet entrant aux adresses IP dans la zone démilitarisée N autoriser aucune connexion directe entrante ou sortante de trafic entre Internet et l environnement des données des titulaires de cartes. 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. 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. 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. 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. 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. Copyright 2010 PCI Security Standards Council LLC Page 14

15 1.3.4 Ne pas autoriser le passage des adresses internes d Internet dans la zone démilitarisée Ne pas autoriser le trafic sortant non autorisé de l environnement des données des titulaires de cartes vers Internet Implémenter le contrôle avec état, également appelé «filtrage des paquets dynamique» (seules les «connexions établies» sont autorisées sur le réseau) 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. 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». 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. 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. 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. Copyright 2010 PCI Security Standards Council LLC Page 15

16 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. 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. Copyright 2010 PCI Security Standards Council LLC Page 16

17 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 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 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) 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. 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 x (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 : 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. Copyright 2010 PCI Security Standards Council LLC Page 17

18 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. 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 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 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é. Copyright 2010 PCI Security Standards Council LLC Page 18

19 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. 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. 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é. 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). 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. 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. Copyright 2010 PCI Security Standards Council LLC Page 19

20 s 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 s 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 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 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. 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. 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! Copyright 2010 PCI Security Standards Council LLC Page 20

21 3.2 Ne stocker aucune donnée d authentification sensible après autorisation (même cryptée). Les données d'authentification sensibles concernées sont mentionnées dans les conditions à 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. 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 carte 7, et données PIN 8. 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». 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. 6 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. Copyright 2010 PCI Security Standards Council LLC Page 21

22 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. 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é 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 Ne pas stocker de code PIN (Personal Identification Number) ni de bloc PIN crypté. 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). Le code de validation des cartes est destiné à protéger les transactions «carte absente», transactions effectuées via Internet ou ordre de paiement par e- mail/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. 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). 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. Copyright 2010 PCI Security Standards Council LLC Page 22

23 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. 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é) Troncature (le hachage ne peut pas être utilisé pour remplacer le segment tronqué du PAN) 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). 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. 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. Copyright 2010 PCI Security Standards Council LLC Page 23

24 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 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. 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. 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»). 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 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. Copyright 2010 PCI Security Standards Council LLC Page 24

25 3.5.2 Stocker les clés cryptographiques de manière sécurisée dans aussi peu d emplacements et de formes que possible. 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 : 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 : 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. 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 à 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» 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 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). Copyright 2010 PCI Security Standards Council LLC Page 25

26 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 ) 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 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). 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. 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 ,, 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. 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 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. Copyright 2010 PCI Security Standards Council LLC Page 26

27 3.6.7 Prévenir la substitution non autorisée des clés cryptographiques 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. 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. 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. Copyright 2010 PCI Security Standards Council LLC Page 27

28 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 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. Copyright 2010 PCI Security Standards Council LLC Page 28

29 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 i) 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 Ne jamais envoyer de PAN non protégé à l'aide de technologies de messagerie pour les utilisateurs finaux (par exemple , messagerie instantanée, chat, etc.). 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. 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. Copyright 2010 PCI Security Standards Council LLC Page 29

30 s 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 s 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 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 Copyright 2010 PCI Security Standards Council LLC Page 30

31 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. 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. Copyright 2010 PCI Security Standards Council LLC Page 31

32 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 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. 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. 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. Copyright 2010 PCI Security Standards Council LLC Page 32

33 6.2 Établir un processus pour identifier et assigner une catégorie de risque aux nouvelles vulnérabilités de sécurité découvertes. 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. 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. 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 , 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 : 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. 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. 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. Copyright 2010 PCI Security Standards Council LLC Page 33

34 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. 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. 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 : Séparation des environnements de développement/test et de production Séparation des obligations entre les environnements de développement/test et de production. 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. 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. 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. 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. 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. Copyright 2010 PCI Security Standards Council LLC Page 34

35 6.4.3 Les données de production (PAN actifs) ne sont pas utilisées à des fins de test ou de développement Suppression des données et comptes de tests avant que les systèmes de production ne deviennent actifs 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 : 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. 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. 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 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 Documentation du changement approuvée par les responsables appropriés Test de fonctionnalité pour vérifier que le changement ne compromet pas la sécurité du système. L'approbation par les responsables autorisés indique que la modification est légitime et que son approbation est ratifiée par l'organisation. 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 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. Copyright 2010 PCI Security Standards Council LLC Page 35

36 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 : Remarque : les vulnérabilités décrites aux points à 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. 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. Comme pour toutes les conditions de la norme PCI DSS, les conditions à et à 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. Copyright 2010 PCI Security Standards Council LLC Page 36

37 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 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é 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 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. Copyright 2010 PCI Security Standards Council LLC Page 37

38 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» 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). 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 : 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. 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 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. Copyright 2010 PCI Security Standards Council LLC Page 38

39 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) 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 Attaques CSRF (Cross-site request forgery) 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. 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. 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 données de titulaires de cartes. 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. Copyright 2010 PCI Security Standards Council LLC Page 39

40 s 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 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 : 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 L octroi des privilèges se fait sur la base de la classification et de la fonction professionnelles de chaque employé Obligation d'une approbation documentée par les responsables spécifiant les privilèges requis Mise en œuvre d un système de contrôle d'accès automatique 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. 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. Copyright 2010 PCI Security Standards Council LLC Page 40

41 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. Ce système de contrôle d accès doit inclure les éléments suivants : Couverture de tous les composants du système L octroi de privilèges aux individus repose sur leur classification et leur fonction professionnelles 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. 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. Copyright 2010 PCI Security Standards Council LLC Page 41

42 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 à 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 8.1 Affecter à tous les utilisateurs un ID unique avant de les autoriser à accéder à des composants du système ou aux données de titulaires de cartes. 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. 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. 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. Copyright 2010 PCI Security Standards Council LLC Page 42

43 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). 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. 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. 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'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). 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 titulaires de cartes. 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. 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. 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. Copyright 2010 PCI Security Standards Council LLC Page 43

44 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 Vérifier l identité des utilisateurs avant de réinitialiser leur mot de passe Définir des mots de passe initiaux uniques pour chaque utilisateur et les modifier immédiatement après la première utilisation Révoquer immédiatement l'accès de tout utilisateur qui ne travaille plus pour la société Supprimer/désactiver les comptes d utilisateur inactifs au moins tous les 90 jours 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. 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. 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. 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. 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é. 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. 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 et Copyright 2010 PCI Security Standards Council LLC Page 44

45 8.5.7 Communiquer les politiques et procédures d'authentification à tous les utilisateurs qui ont accès aux données de titulaires de cartes Ne pas utiliser de comptes, de mots de passe ni d'autres méthodes d'authentification collectifs, partagés ou génériques Modifier les mots de passe utilisateur au moins tous les 90 jours Exiger des mots de passe comportant au moins sept caractères Définir des mots de passe comportant des caractères alphanumériques Interdire à un utilisateur de soumettre un nouveau mot de passe identique à l un de ses quatre derniers mots de passe Limiter les tentatives d accès répétées en verrouillant l ID d utilisateur après six tentatives au maximum. 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»). 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. 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. Copyright 2010 PCI Security Standards Council LLC Page 45

46 Régler la durée de verrouillage sur 30 minutes au moins ou jusqu à ce que l administrateur active l ID d utilisateur 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 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. 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). 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. 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). Copyright 2010 PCI Security Standards Council LLC Page 46

47 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 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 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 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é. 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. 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 titulaires de cartes. 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. Copyright 2010 PCI Security Standards Council LLC Page 47

48 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. 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. 9.3 S assurer que tous les visiteurs sont traités de la manière suivante : 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 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 Il leur est demandé de rendre le dispositif physique avant de quitter les locaux ou à la date d expiration 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. 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. 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. Copyright 2010 PCI Security Standards Council LLC Page 48

49 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. 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. 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. 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 : Classer les supports afin de déterminer la sensibilité des données qu'ils contiennent 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. 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). 9.9 Assurer un contrôle strict du stockage et de l accessibilité des supports. 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. 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. 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. 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. 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. Copyright 2010 PCI Security Standards Council LLC Page 49

50 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 Détruire les supports lorsqu'ils ne sont plus nécessaires à des fins professionnelles ou légales comme suit : 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 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. 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. Copyright 2010 PCI Security Standards Council LLC Page 50

51 s 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 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 Mettre en œuvre des vérifications à rebours automatisées pour tous les composants du système afin de reconstituer les événements suivants : Tous les accès des utilisateurs aux données des titulaires de cartes Toutes les actions exécutées par tout utilisateur avec des droits root ou administrateur 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. 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. 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. 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 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. Copyright 2010 PCI Security Standards Council LLC Page 51

52 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 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 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é 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 Consigner dans les vérifications à rebours au moins les entrées suivantes pour chaque événement : Identification de l'utilisateur Type d événement Date et heure Indication de succès ou d'échec Origine de l événement Identité ou nom des données, du composant du système ou de la ressource affectés 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. 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. Copyright 2010 PCI Security Standards Council LLC Page 52

53 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. Remarque : le protocole Network Time Protocol (NTP) est un exemple de technologie de synchronisation temporelle L'heure des systèmes critiques est correcte et la même pour tous Les données temporelles sont protégées Les paramètres temporels sont reçus de sources temporelles reconnues par le secteur 10.5 Protéger les vérifications à rebours de sorte qu'elles ne puissent pas être modifiées. 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. 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 notamment des informations sur l'heure, le temps de référence et les serveurs. 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. Copyright 2010 PCI Security Standards Council LLC Page 53

54 Limiter l affichage des vérifications à rebours aux utilisateurs qui en ont besoin pour mener à bien leur travail Protéger les fichiers de vérifications à rebours contre toute modification non autorisée Sauvegarder rapidement les fichiers de vérifications à rebours sur un serveur centralisé réservé à la journalisation ou sur des supports difficiles à altérer 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 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) 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). Remarque : les outils de journalisation, d analyse et d alerte peuvent être utilisés conformément à la condition 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). 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. 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. 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. 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. Copyright 2010 PCI Security Standards Council LLC Page 54

55 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 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. 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. 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. 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 Copyright 2010 PCI Security Standards Council LLC Page 55

56 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). 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. cas de détection d'un équipement non autorisé au cours d'une analyse manuelle. 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. 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. Copyright 2010 PCI Security Standards Council LLC Page 56

57 Effectuer des analyses trimestrielles de vulnérabilité interne 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). 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 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. 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. 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. 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. Copyright 2010 PCI Security Standards Council LLC Page 57

58 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 : Tests de pénétration de la couche réseau Tests de pénétration de la couche application 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. 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. Copyright 2010 PCI Security Standards Council LLC Page 58

59 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. Tenir à jour tous les moteurs de détection et de prévention des intrusions, les références et les signatures. 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. 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. Copyright 2010 PCI Security Standards Council LLC Page 59

60 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. 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). 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. Copyright 2010 PCI Security Standards Council LLC Page 60

61 s 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 titulaires de cartes. Condition 12.1 Définir, publier, gérer et diffuser une politique de sécurité qui remplit les fonctions suivantes : Satisfait à toutes les conditions de la norme PCI DSS 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 and NIST SP sont des exemples de méthodologies d'évaluation du risque) Comprend au moins un examen annuel avec une mise à jour chaque fois que l environnement change É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). 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. 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. 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 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. 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. Copyright 2010 PCI Security Standards Council LLC Page 61

62 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 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 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 Liste de tous les périphériques et du personnel disposant d'un accès Indication sur les périphériques du nom de leur propriétaire, de ses coordonnées et de leur usage Usages acceptables de la technologie Emplacements acceptables des technologies sur le réseau Liste des produits approuvés par la société Déconnexion automatique des sessions des technologies d accès à distance après une période d'inactivité spécifique 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. 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 Copyright 2010 PCI Security Standards Council LLC Page 62

63 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 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 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 12.5 Attribuer à un individu ou à une équipe les responsabilités suivantes de gestion de la sécurité des informations : Définir, documenter et diffuser les politiques et les procédures de sécurité Contrôler et analyser les informations et les alertes de sécurité, et les diffuser au personnel compétent 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 Administrer les comptes d utilisateur, notamment l ajout, la suppression et la modification de comptes Surveiller et contrôler tous les accès aux données 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. 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 pour plus d'informations à ce sujet. 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. 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. 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. 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. Copyright 2010 PCI Security Standards Council LLC Page 63

64 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 Exiger que le personnel reconnaisse au moins une fois par an avoir lu et compris les procédures et la politique de sécurité. 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. 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 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. 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. Copyright 2010 PCI Security Standards Council LLC Page 64

65 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 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 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 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 Mettre en place un programme qui contrôle la conformité des prestataires de services à la norme PCI DSS au moins une fois par an Mettre en œuvre un plan de réponse aux incidents. Être prêt à réagir immédiatement à toute intrusion dans le système. 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. 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. 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. 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. Copyright 2010 PCI Security Standards Council LLC Page 65

66 É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 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 Désigner le personnel spécifique disponible 24 heures sur 24 et sept jours sur sept pour répondre aux alertes Organiser la formation appropriée du personnel en charge de la réponse aux violations de la sécurité 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 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. 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. 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. 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. 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é. Copyright 2010 PCI Security Standards Council LLC Page 66

67 s 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 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. 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. A.1.2 Restreindre l'accès et les privilèges de chaque entité à son seul environnement de données de titulaires de cartes. 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. 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. 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 Copyright 2010 PCI Security Standards Council LLC Page 67

68 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. 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. services ne peut monopoliser les ressources du système. 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 titulaires de cartes. 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. Copyright 2010 PCI Security Standards Council LLC Page 68

69 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. Document Conditions et procédures d'évaluation de sécurité de la norme PCI DSS 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 Norme de sécurité des données du PCI : Questionnaire d autoévaluation B et attestation Norme de sécurité des données du PCI : Questionnaire d autoévaluation C-VT et attestation Norme de sécurité des données du PCI : Questionnaire d autoévaluation C et attestation Norme de sécurité des données du PCI : Questionnaire d autoévaluation D et attestation Glossaire des termes, abréviations et acronymes PCI DSS et PA-DSS Public visé Tous les commerçants et les prestataires de services Tous les commerçants et les prestataires de services Tous les commerçants et les prestataires de services Commerçants qualifiés 9 Commerçants qualifiés 9 Commerçants qualifiés 9 Commerçants qualifiés 9 Commerçants qualifiés et prestataires de services 9 Tous les commerçants et les prestataires de services 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». Copyright 2010 PCI Security Standards Council LLC Page 69