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