Payment Card Industry (PCI) Normes en matière de sécurité des données. Version 1.1

Transcription

1 Payment Card Industry (PCI) Normes en matière de sécurité des données Version 1.1 Date de publication : septembre 2006

2 Mettre en place et gérer un réseau sécurisé 1 ère exigence : installer et gérer une configuration de pare-feu afin de protéger les données des titulaires de carte 2 ème exigence : ne pas utiliser les paramètres par défaut du fournisseur pour les mots de passe et les autres paramètres de sécurité du système Protéger les données des titulaires de carte 3 ème exigence : protéger les données des titulaires de carte stockées 4 ème exigence : crypter la transmission des données des titulaires de carte sur les réseaux publics ouverts Disposer d un programme de gestion de la vulnérabilité 5 ème exigence : utiliser et mettre à jour régulièrement un logiciel antivirus 6 ème exigence : développer et gérer des applications et systèmes sécurisés Mettre en œuvre des mesures de contrôle d'accès efficaces 7 ème exigence : limiter l accès aux données des porteurs de carte aux cas de nécessité professionnelle absolue 8 ème exigence : attribuer une identité d utilisateur unique à chaque personne disposant d un accès informatique 9 ème exigence : limiter l accès physique aux données des titulaires de carte Surveiller et tester régulièrement les réseaux 10 ème exigence : suivre et surveiller tous les accès aux ressources du réseau et aux données des titulaires de carte 11 ème exigence : tester régulièrement les systèmes et procédures de sécurité Disposer d une politique en matière de sécurité de l information 12 ème exigence : disposer d une politique régissant la sécurité de l information 1

3 Préface Ce document décrit les 12 exigences des Normes en matière de sécurité des données (Data Security Standard, DSS) de l industrie des cartes de crédit (Payment Card Industry, PCI). Les exigences PCI DSS s'organisent en 6 groupes logiques liés, qui sont des «objectifs de contrôle». Le tableau ci-dessous présente un certain nombre d éléments communément utilisés des données de titulaire de carte et d authentification sensibles ; indique si le stockage de chaque élément de données est autorisé ou interdit et précise si chaque élément de données doit être protégé. Ce tableau n est pas exhaustif, mais il est présenté de manière à illustrer les divers types d exigences qui s appliquent à chaque élément de données. Les exigences PCI DSS s appliquent si un Numéro de compte primaire (Primary Account Number, PAN) est stocké, traité ou transmis. En l absence de stockage, de traitement ou de transmission de PAN, les exigences PCI DSS ne s appliquent pas. Données de titulaire Élément de données Numéro de cpte primaire (PAN) Archivage autorisé Protection requise Exig. 3.4 PCI DSS OUI OUI OUI Nom du titulaire* OUI OUI* NON Code service* OUI OUI* NON Date d expiration* OUI OUI* NON Données d authentification sensibles** Bande magnétique complète NON s.o. s.o. CVC2/CVV2/CID NON s.o. s.o. PIN/bloc PIN NON s.o. s.o. * Ces éléments de données doivent être protégés s ils sont stockés conjointement avec le PAN. Cette protection doit être conforme aux exigences PCI DSS en liaison avec la protection générale de l environnement des titulaires de carte. En outre, d autres lois (par exemple, relatives à la protection des données personnelles des consommateurs, de vie privée, de vol d'identité ou de sécurité des données) peuvent imposer une protection spécifique de ces données, ou une divulgation adéquate des pratiques de la société dès lors que des données à caractère personnel sont collectées dans le cadre de l activité. Toutefois, les PCI DSS ne s'appliquent pas si des PAN ne sont pas stockés, traités ou transmis. ** Aucune donnée d authentification sensible ne doit être stockée après autorisation (même cryptée). Ces exigences en matière de sécurité s'appliquent à l'ensemble des «composantes du système». Ces composantes sont définies comme toute composante, tout serveur ou toute application du réseau, inclus dans l environnement de données du titulaire de carte, ou connecté à celui-ci. L environnement de données du titulaire de carte est la partie du réseau qui possède des données de titulaires de carte ou des données d authentification sensibles. Une segmentation adéquate du réseau, qui isole des systèmes stockant, traitant ou transmettant des données de titulaire de carte de ceux qui ne le font pas peut réduire le périmètre de l environnement de données du titulaire de carte. Au nombre des composantes de réseau 2

4 figurent notamment les pare-feux, commutateurs, routeurs, points d'accès sans fil, appareils de réseau et autres dispositifs de sécurité. Les divers types de serveur incluent notamment les suivants : Internet, base de données, authentification, courrier, mandataire, network time protocol (NTP) et serveur de nom de domaine (domain name server, DNS). Les applications englobent l ensemble des applications achetées et personnalisées, y compris internes et externes (Internet). 3

5 Mettre en place et gérer un réseau sécurisé 1 ère exigence : installer et gérer une configuration de pare-feu afin de protéger les données des titulaires de carte Les pare-feux sont des dispositifs informatiques qui contrôlent le trafic autorisé à entrer sur le réseau de la société, ou à en sortir, ainsi que le trafic dans des secteurs plus sensibles du réseau interne d'une société. Un pare-feu vérifie la totalité du trafic du réseau et bloque les transmissions non-conformes aux critères de sécurité édictés. Tous les systèmes doivent être protégés contre tout accès non autorisé par Internet, qu il s agisse d accès au système aux fins de commerce électronique, d accès Internet par des employés, grâce au navigateur de leur poste de travail, ou d accès par le biais du courrier électronique des employés. Il arrive fréquemment que des chemins apparemment insignifiants, vers et depuis l Internet, puissent constituer des voies d accès non protégées à des systèmes clés. Les pare-feux sont un mécanisme de protection essentiel de tout réseau informatique. 1.1 Mettre en place des normes de configuration de pare-feu incluant les aspects suivants : un processus formel d approbation et de test de toutes les connexions externes de réseau, ainsi que de l ensemble des modifications apportées à la configuration du parefeu ; un diagramme du réseau à jour, avec toutes les connexions à des données de titulaires de carte, y compris tous réseaux sans fil ; la nécessité d un pare-feu pour chaque connexion Internet et entre toute zone d'accueil (demilitarized zone, DMZ) et la zone de réseau interne ; la description des groupes, rôles et responsabilités en matière de gestion logique des composants de réseau ; une liste écrite des services et ports nécessaires à l activité ; la justification et la consignation par écrit de tous protocoles disponibles en dehors des protocoles http (hypertext transfer protocol, HTTP), SSL (secure sockets layer, SSL), SSH (secure shell, SSH) et de réseau privé virtuel (virtual private network, VPN) ; la justification et la consignation par écrit de tous protocoles à risque autorisés (par exemple, un protocole de transfert de fichiers (file transfer protocol, FTP), avec les raisons de l utilisation du protocole, et les mesures de sécurité utilisées) ; un examen trimestriel des ensembles de règles applicables aux pare-feux et aux routeurs ; des normes de configuration pour les routeurs ; 1.2 Développer une configuration de pare-feu bloquant tout trafic en provenance de réseaux et d'hôtes «non sécurisés», à l exception des protocoles nécessaires à l environnement des données de titulaire de carte. 1.3 Élaborer une configuration de pare-feu limitant les connexions entre des serveurs accessibles publiquement et des composantes de système stockant des données de titulaire de carte, y compris toute connexion depuis un réseau sans fil. Cette configuration de pare-feu doit en principe englober les aspects suivants : la restriction du trafic Internet entrant vers des adresses Internet dans la zone d'accueil (filtres d'entrée) ; ne pas laisser des adresses internes passer de l Internet à la zone d accueil ; 4

6 1.3.3 la mise en œuvre d une inspection dynamique, également désignée filtre dynamique à paquets (ce qui signifie que seule les connexions «établies» sont autorisées dans le réseau) ; le positionnement de la base de données dans une zone de réseau interne, distincte de la zone d accueil ; la limitation du trafic entrant et sortant à ce qui est nécessaire à l'environnement des données de titulaires de carte ; la sécurisation et la synchronisation de fichiers de configuration de routeur. Les fichiers de configuration d'exécution (pour le fonctionnement normal des routeurs) et les fichiers de configuration de démarrage (lors du redémarrage des machines) doivent par exemple présenter une configuration sécurisée identique ; l'interdiction de tout autre trafic, entrant ou sortant, dans la mesure où il n a pas été spécifiquement autorisé ; l'installation de pare-feux de périmètre entre tous réseaux sans fil et l environnement de données de titulaires de carte, et la configuration de ces pare-feux de manière à bloquer tout trafic provenant de l'environnement sans fil, ou pour contrôler tout trafic (lorsqu il est nécessaire à des fins commerciales) ; l'installation d un logiciel pare-feu personnel sur un ordinateur portable ou un ordinateur appartenant à un employé disposant d'une connectivité directe à l'internet (par exemple, les ordinateurs portables utilisés par les employés), utilisés pour accéder au réseau de l'organisation. 1.4 Interdire l accès public direct entre les réseaux externes et toute composante du système stockant des données de titulaire de carte (par exemple, les fichiers de base de données, journal et trace) Mettre en place une zone d accueil pour filtrer et vérifier l ensemble du trafic, ainsi que pour interdire les routes directes pour le trafic Internet entrant et sortant Restreindre le trafic sortant des applications de carte de paiement vers des adresses Internet situées dans la zone d accueil. 1.5 Mettre en œuvre un déguisement d adresse Internet, pour éviter que les adresses internes ne soient traduites et divulguées sur Internet. Utilisation de technologies mettant en œuvre l espace adresse RFC 1918, telles qu'une traduction d adresse de port (port address translation, PAT) ou une traduction d adresse de réseau (network address translation, NAT). 2 ème exigence : ne pas utiliser les paramètres par défaut du fournisseur pour les mots de passe et les autres paramètres de sécurité du système Les pirates informatiques (externes et internes à une société) utilisent fréquemment des mots de passe par défaut du fournisseur et d autres paramètres par défaut du fournisseur pour s'introduire dans les systèmes. Ces mots de passe et paramètres sont bien connus des communautés de pirates et facilement déterminés au moyen des informations publiques. 2.1 Il est impératif de toujours modifier les réglages par défaut du fournisseur avant d installer un système sur le réseau (par exemple, inclure des mots de passe, des chaînes communautaires de protocole de gestion de réseau simple (simple network management protocol, SNMP) et la suppression de comptes inutiles) Dans le cas des environnements sans fil, modifier les réglages par défaut du fournisseur sans fil, y compris notamment les clés Wired Equivalent Privacy (WEP), le Service Set IDentifier (SSID) par défaut, les mots de passe et les chaînes communautaires SNMP. Désactiver les émissions en clair du SSID sur le réseau. Mettre 5

7 en place une technologie d accès WiFi protégé (WPA et WPA2) pour le cryptage et l authentification lorsqu il existe une capacité WPA. 2.2 Développer des normes de configuration pour l ensemble des composants du système. Faire en sorte que ces normes prennent en compte l ensemble des vulnérabilités connues en matière de sécurité et soient cohérentes avec des normes de renforcement de la sécurité du système acceptées par l industrie, telles que définies, par exemple par le SysAdmin Audit Network Security Network (SANS), le National Institute of Standards Technology (NIST) et le Center for Internet Security (CIS) Mettre en œuvre uniquement une section primaire par serveur (ainsi, les serveurs Internet, de base de données et DNS doivent être mis en place sur des serveurs distincts) Désactiver tous les services et protocoles inutiles et non sécurisés (les services et protocoles qui ne sont pas directement nécessaires à l exécution de la fonction spécifiée des appareils) Configurer les paramètres de sécurité du système pour prévenir toute utilisation frauduleuse Supprimer toutes les fonctionnalités inutiles, telles que les scripts, lecteurs, dispositifs, sous-systèmes, systèmes de fichiers et serveurs Internet inutiles. 2.3 Crypter tous les accès administratifs non-console. Utiliser des technologies telles que SSH, VPN ou SSL/TLS (transport layer security) pour la gestion par Internet et les autres accès administratifs non-console. 2.4 Les fournisseurs d hébergement doivent protéger les données et l environnement hébergé de chaque entité. Ces fournisseurs doivent se conformer à des instructions spécifiques figurant en Annexe A : «Application des normes PCI en matière de sécurité des données (DSS) des fournisseurs d hébergement». 6

8 Protéger les données des titulaires de carte 3 ème exigence : protéger les données des titulaires de carte en stock Le cryptage est une composante essentielle de la protection des données de titulaires de carte. Si un intrus parvient à franchir les autres contrôles de sécurité du réseau et à accéder à des données cryptées, sans les clés de cryptographie adéquates, les données ne sont pas lisibles ni utilisables par lui. D autres méthodes efficaces de protection des données stockées doivent également être envisagées comme des opportunités d atténuation possible du risque. Ainsi, au nombre des méthodes de minimisation des risques figurent notamment le non-stockage des données de carte de crédit à moins que cela ne soit absolument nécessaire, le fait de tronquer les données du titulaire de carte si un PAN complet n est pas nécessaire, ainsi que la transmission des PAN exclusivement par courrier électronique crypté. 3.1 Le stockage des données de titulaire de carte doit être limité au minimum. Élaborer une politique en matière de conservation et d élimination de données. Limiter les quantités stockées et les délais de conservation des données au strict nécessaire au plan économique, légal et/ou réglementaire, comme prévu dans la politique en matière de conservation des données. 3.2 Ne pas stocker de données d authentification sensibles après autorisation (même si elles sont cryptées). Au nombre des données d authentification sensibles figurent les données indiquées dans les Exigences à ci-après : Ne jamais stocker la totalité du contenu d une quelconque piste de la bande magnétique (au dos d'une carte, sur une puce ou ailleurs). Les données sont alternativement désignées piste complète, piste 1, piste 2 et données de bande magnétique. Dans le cours normal de l activité, il est possible qu il soit nécessaire de conserver les éléments de données de la bande magnétique ci-après : le nom du titulaire du compte, le numéro de compte primaire (primary account number, PAN), la date d expiration et le code de service. Afin de minimiser le risque, stocker uniquement les éléments de données nécessaires à l'activité. NE JAMAIS stocker le code de vérification de la carte, ni la valeur, ni non plus des éléments de données de valeur de vérification du code PIN. Remarque : pour plus d information, se reporter au «Glossaire» Ne pas stocker de code de validation de carte, ni de valeur (à trois ou quatre chiffres, imprimés sur le côté face ou au verso d'une carte de paiement) utilisée pour vérifier des transactions cartes absente (card-not-present, CNP). Remarque : pour plus d information, se reporter au «Glossaire» Ne pas stocker le numéro d identification personnel (personal identification number, PIN), ni le bloc PIN crypté. 3.3 Masquer le PAN lorsqu il s affiche (les six premiers chiffres et les quatre derniers sont le nombre maximum de chiffres affichés). Remarque : cette exigence ne s applique pas aux employés et aux autres parties ayant spécifiquement besoin d avoir connaissance de la totalité du PAN ; de même, cette exigence ne remplacera-t-elle pas des obligations plus rigoureuses existantes applicables à l affichage de données de titulaire de carte (par exemple, dans le cas de reçus de point de vente [point of sale, POS]). 3.4 Rendre le PAN, au minimum, illisible où qu il soit stocké (y compris des données sur support numérique portable, support de sauvegarde, journaux et données reçues de, ou stockées par des réseaux sans fil), en utilisant l'une ou l'autre des approches suivantes : des fonctions efficaces de hachage à sens unique (index hachés) ; 7

9 une troncature ; des jetons et pads index (les pads doivent être stockés de manière sécurisée) ; une cryptographie performante, avec des processus et procédures de gestion clés associés. En ce qui concerne les coordonnées de compte, au MINIMUM, le PAN doit être rendu illisible. Si, pour une raison ou pour une autre, une société n est pas en mesure de crypter des données de titulaire de carte, se reporter à l'annexe B : «Contrôles destinés à suppléer au défaut de cryptage des données stockées» Si un cryptage par disque est utilisé (au lieu d un cryptage par fichier ou base de données au niveau colonne), l'accès logique doit être géré indépendamment des mécanismes de contrôle d'accès au système d'exploitation natif (par exemple, en n'utilisant pas un système local, ni des comptes Active Directory). Les clés de décryptage ne doivent pas être liées à des comptes d utilisateur. 3.5 Protéger les clés de cryptage utilisées pour le cryptage des données de titulaire de carte, à la fois contre la divulgation et l utilisation illicite limiter l accès aux clés au plus petit nombre possible de dépositaires, en fonction des nécessités ; stocker les clés, de manière sécurisée, en un nombre de lieux et de formes aussi réduit que possible. 3.6 Consigner et mettre en œuvre complètement l ensemble des processus et procédures de gestion de clés pour les clés utilisées pour le cryptage des données des titulaires de carte, y compris les suivantes : génération de clés performantes ; distribution de clé sécurisée ; stockage de clé sécurisé ; changement périodique des clés : comme tenu pour nécessaire et recommandé par l application associée (par exemple, le changement de clé, ou re-keying), de préférence automatiquement ; au moins annuellement ; destruction des anciennes clés ; répartition des informations et mise en place d un double système de contrôle des clés (de manière à ce que deux ou trois personnes, chacune d elles connaissant une partie de la clé, reconstituent la clé dans son intégralité) ; la prévention des substitutions de clés non autorisées ; le remplacement des clés dont compromises ou suspectées de l être ; l'annulation des clés anciennes ou invalides ; l'obligation, pour les principaux dépositaires de clés, de signer un formulaire indiquant qu ils comprennent et acceptent les responsabilités liées à leurs fonctions de dépositaire. 4 ème exigence : crypter la transmission des données des titulaires de carte sur les réseaux publics ouverts Les informations sensibles doivent être cryptées lors de leur transmission sur des réseaux permettant aux pirates, ainsi qu ils le font couramment, d intercepter, de modifier et de détourner des données en cours de transit. 8

10 4.1 Utiliser des techniques de cryptographie et des protocoles de sécurité performants, comme par exemple des protocoles SSL (Secure Sockets Layer)/TLS (Transport layer security) et IPSEC (Internet Protocol Security) pour protéger les données sensibles des titulaires de carte lors de leur transmission sur des réseaux publics ouverts. L Internet, le WiFi (IEEE x), le réseau de téléphonie mobile (Global System for Mobile Communications, GSM) et le General Packet Radio Service (GPRS) sont des exemples de réseaux publics ouverts relevant du périmètre des normes PCI DSS Dans le cas des réseaux sans fil transmettant des données de titulaire de carte, crypter les transmissions en utilisant la technologie d accès protégé au WiFi (WPA ou WPA2), IPSEC VPN ou SSL/TLS. Ne jamais se fier uniquement au protocole WEP (Wired Equivalent Privacy) pour protéger la confidentialité et l accès à un réseau LAN sans fil. En cas d utilisation de WEP, prendre les mesures suivantes : utiliser avec une clé de cryptage d au moins 104 bits et une valeur d initialisation de 24 bits au minimum ; utiliser UNIQUEMENT en liaison avec la technologie d accès protégé au WiFi (WPA ou WPA2), VPN ou SSL/TLS ; permuter les clés WEP partagées une fois par trimestre (ou automatiquement si la technologie le permet) ; permuter les clés WEP partagées en cas de changement des personnels disposant d un accès aux clés ; restreindre l accès basé sur l'adresse MAC (media access code). 4.2 Ne jamais envoyer de PAN non cryptés par courrier électronique. Disposer d un programme de gestion de la vulnérabilité 5 ème exigence : utiliser et mettre à jour régulièrement un logiciel ou des programmes antivirus Nombre de vulnérabilités et de virus dangereux entrent dans le réseau par le biais des activités des employés. Un logiciel anti-virus doit être utilisé sur tous les systèmes ordinairement affectés par les virus afin de protéger les systèmes contre les logiciels dangereux. 5.1 Déployer un logiciel anti-virus sur tous les systèmes généralement affectés par les virus (en particulier les ordinateurs personnels et les serveurs) Remarque : les systèmes d exploitation sous UNIX et les ordinateurs centraux ne figurent pas au nombre des systèmes couramment affectés par les virus Faire en sorte que les programmes anti-virus soient capables de détecter d autres formes de logiciels nuisibles, y compris les logiciels d espionnage (ou «spyware») et publicitaires, de les supprimer et d'assurer une protection contre ceux-ci. 5.2 Faire en sorte que tous les mécanismes anti-virus soient à jour, qu ils fonctionnent activement et qu'ils soient capables de générer des listes de contrôle. 6 ème exigence : développer et gérer des applications et systèmes sécurisés Il arrive que des individus peu scrupuleux utilisent les vulnérabilités en matière de sécurité pour accéder aux systèmes. Il est remédié à nombre de ces vulnérabilités par des correctifs de sécurité mis à disposition par le fournisseur. Tous les systèmes doivent être équipés des correctifs appropriés les plus récents, afin de les protéger des intrusions d'employés ou de pirates informatiques, ainsi que contre les virus. Remarque : les correctifs appropriés sont ceux qui ont été suffisamment évalués et testés pour déterminer qu ils n entrent pas en conflit avec les configurations de sécurité en place. En ce qui concerne 9

11 les applications développées en interne, de nombreuses vulnérabilités peuvent être évitées par des processus de développement de système standard, ainsi que par des techniques de codage sécurisées. 6.1 S'assurer que toutes les composantes et tous les logiciels du système disposent des correctifs de sécurité les plus récents mis à disposition par le fournisseur. Installer les correctifs de sécurité dans un délai d un mois suivant leur publication. 6.2 Mettre en place un processus destiné à identifier les vulnérabilités en matière de sécurité nouvellement identifiées (par exemple, souscrire un abonnement à des services d alerte disponibles gratuitement sur l'internet). Mettre les normes à jour afin de faire face aux nouveaux problèmes de vulnérabilité. 6.3 Développer des applications logicielles sur la base des meilleures pratiques sectorielles et intégrer la sécurité de l information dans l ensemble du cycle de développement de logiciel Tester tous les correctifs de sécurité, ainsi que toutes modifications de configuration de système ou de logiciel avant déploiement Séparer les environnements de développement, de test et de production Séparation des obligations entre les environnements de développement, de test et de production Les données de production (PAN actifs) ne sont pas utilisées aux 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 Suppression des comptes d application, noms d utilisateur et mots de passe usuels avant que les applications ne deviennent actives ou ne soient mises à la disposition de clients Examen du code personnalisé avant de mettre à la disposition de la production ou de clients afin d identifier toute vulnérabilité de cryptage éventuelle. 6.4 Se conformer aux procédures en matière de contrôle des changements pour toutes les modifications apportées au système et au logiciel. Les procédures doivent inclurent les éléments suivants : consignation écrite de l impact ; approbation par signature de la direction par les parties appropriées ; vérification de la fonctionnalité opérationnelle ; procédures de sauvegarde. 6.5 Développer toutes les applications Internet sur la base de principes directeurs en matière de codage sécurisé tels que ceux de l'open Web Application Security Project (OWASP). Étudier un code d application personnalisé, afin d identifier les vulnérabilités en matière de codage. Prévenir les vulnérabilités de codage courantes dans les processus de développement de logiciel, afin d inclure les éléments suivants : les entrées non validées ; un contrôle d accès compromis (par exemple, une utilisation malveillante d identités d utilisateur) ; une authentification et une gestion de session compromises (l utilisation d'éléments d authentification de compte et les cookies de session) ; les attaques par Cross-Site Scripting (XSS ou CSS) ; les attaques par débordement de tampon ; les attaques par injection (par exemple, une injection de commandes SQL (Structured Query Language)) ; une gestion d erreur inadéquate ; 10

12 6.5.8 un stockage non sécurisé ; un refus de service ; une gestion de configuration non sécurisée. 6.6 Faire en sorte que toutes les applications d interface Internet soient protégées contre les attaques connues grâce à l une ou l autre des méthodes suivantes : faire contrôler par une organisation spécialisée dans la sécurité des applications, tout code d'application personnalisé aux fins de détection des vulnérabilités courantes ; Installer un pare-feu de couche application qui protège les applications d interface Internet. Remarque : cette méthode est considérée comme une «meilleure pratique» jusqu au 30 juin 2008, après quoi, elle devient obligatoire. Mettre en œuvre des mesures de contrôle d'accès efficaces 7 ème exigence : limiter l accès aux données des porteurs de carte aux cas de nécessité professionnelle absolue Cette exigence est destinée à garantir que seuls les personnels autorisés peuvent accéder aux données critiques. 7.1 Limiter l accès aux ressources de calcul et aux informations des titulaires de carte aux seules personnes qui, en raison de leurs fonctions, sont tenues d'y accéder. 7.2 Mettre en place un mécanisme pour les systèmes avec de multiples utilisateurs limitant l accès en fonction du besoin de l'utilisateur d'en avoir connaissance et réglé sur «interdire à tous», sauf autorisation spécifique. 11

13 8 ème exigence : attribuer une identité d utilisateur unique à chaque personne disposant d un accès informatique L attribution d un identifiant unique (identité d utilisateur) à chaque personne disposant d un accès garantit que les actions concernant des données et systèmes critiques seront exécutées par des utilisateurs connus et dûment autorisés, et en assure la traçabilité. 8.1 Identifier tous les utilisateurs par un nom d utilisateur unique avant de les autoriser à accéder aux composants du système ou aux données de titulaires de carte. 8.2 En plus de l attribution d une identité d utilisateur unique, employer au moins l une des méthodes ci-après pour identifier l ensemble des utilisateurs : mot de passe ; jetons (par exemple, SecureID, certificats ou clé publique) ; biométrie. 8.3 Mettre en œuvre une authentification à deux facteurs pour l'accès distant au réseau par des employés, administrateurs et tiers. Utiliser des technologies telles que l authentification à distance et un service de renseignement par téléphone (RADIUS) ou un système de contrôle d accès de contrôleur d accès au terminal (Terminal Access Controller Access Control System, TACACS) avec des jetons ; ou VPN (basé sur SSL/TLS ou IPSEC) avec des certificats individuels. 8.4 Crypter tous les mots de passe pour leur transmission et leur stockage sur toutes les composantes du système. 8.5 Assurer une gestion adéquate de l identification et des mots de passe d utilisateur pour des utilisateurs non consommateurs et des administrateurs sur toutes les composantes du système, comme suit : contrôler l ajout d'identités d utilisateur, d identifiants et d autres éléments d identification, leur suppression et leur modification ; vérifier l identité de l utilisateur avant de procéder à une réinitialisation de mot de passe ; mettre en place un mot de passe initial, avec une valeur unique, pour chaque utilisateur et le modifier immédiatement après la première utilisation ; mettre fin immédiatement à l accès des utilisateurs ayant cessé d être employés par l entreprise ; supprimer les comptes d utilisateur inactifs au moins tous les 90 jours ; activer les comptes utilisés par des fournisseurs aux fins de maintenance à distance uniquement durant la période nécessaire ; communiquer les procédures et politiques en matière de mot de passe à tous les utilisateurs ayant accès aux données de titulaires de carte ; ne pas utiliser de comptes et mots de passe collectifs, partagés ou génériques ; changer les mots de passe d utilisateur au moins tous les 90 jours ; exiger que les mots de passe comptent au moins sept caractères ; utiliser des mots de passe contenant des caractères à la fois numériques et alphabétiques ; ne pas autoriser une personne à soumettre un nouveau mot de passe identique à l un ou l autre des quatre derniers mots de passe utilisés par elle ; limiter le nombre de tentatives d accès en verrouillant l identité d utilisateur après au plus 6 tentatives ; fixer la période de verrouillage à trente minutes, ou jusqu'à ce qu'un administrateur active l'identité d'utilisateur ; 12

14 si une session est inactive depuis plus de 15 minutes, imposer à l utilisateur de saisir à nouveau son mot de passe pour réactiver le terminal ; authentifier tous les accès à toute base de données contenant des données de titulaire de carte. Ceci inclut les accès par les applications, administrateurs et tous les autres utilisateurs. 13

15 9 ème exigence : limiter l accès physique aux données des titulaires de carte Tout accès physique à des données ou systèmes contenant des données de titulaires de carte est l occasion, pour des individus, d'accéder à des dispositifs ou données et de s'emparer de systèmes ou d'exemplaires papier, et doit de ce fait être limité de manière appropriée. 9.1 Utiliser des contrôles d entrée dans les installations appropriés, afin de limiter et de contrôler l accès physique à des systèmes qui stockent, traitent ou transmettent des données de porteur de carte Utiliser des caméras pour surveiller les zones sensibles. Vérifier les données collectées et les mettre en relation avec d autres. Sauf interdiction légale, stocker ces données durant au moins 3 mois Limiter l accès physique aux prises du réseau accessibles publiquement Limiter l accès physique aux points d accès sans fil, portails et périphériques portables. 9.2 Développer des procédures destinées à aider l ensemble des personnels à faire une distinction entre les employés et les visiteurs, en particulier dans les zones où des données de titulaires de carte sont accessibles. «Employé» désigne les employés à temps plein et partiel, les salariés et personnels à temps partiel, ainsi que les consultants ayant la qualité de «résident» sur le site de l'entité. Le terme «visiteur» fait référence aux fournisseurs, invités d un employé, personnels de service ou à toute personne ayant besoin d accéder aux locaux pour une brève période, n excédant généralement pas une journée. 9.3 Faire en sorte que tous les visiteurs soient gérés comme suit : que, le cas échéant, une autorisation leur soit délivrée pour leur permettre d accéder à des zones dans lesquelles des données de titulaire de carte sont traitées ou conservées ; que, le cas échéant, leur soit remis un «laisser-passer» (par exemple, un badge ou un dispositif d accès) ayant une heure et une date d expiration, et identifiant les visiteurs comme n'étant pas des employés de l'entreprise ; qu'il leur soit demandé de restituer leur «laisser-passer» avant de quitter les installations ou à la date d expiration. 9.4 Utiliser un registre des visiteurs afin de conserver une piste de vérification physique de l activité du visiteur. À moins que le droit en vigueur ne l interdise, conserver ce registre durant une période d au moins trois mois. 9.5 Stocker les sauvegardes en lieu sûr, de préférence dans des installations hors site, par exemple, sur un site alternatif ou de sauvegarde, ou une installation de stockage commercial. 9.6 Assurer la sécurité physique de tous documents papier et supports électroniques (y compris les ordinateurs, supports électroniques, matériel de réseau et de communication, lignes de télécommunications, reçus papier, rapports papier et télécopies) contenant des données de titulaires de carte. 9.7 Assurer un contrôle rigoureux sur la diffusion interne ou externe de tous types de support contenant des données de titulaires de carte, et notamment comme suit : classifier le support pour qu il puisse être identifié comme confidentiel ; envoyer le support par service de coursier sécurisé, ou par tout autre mode de livraison permettant un suivi exact. 9.8 Faire en sorte que la direction autorise la sortie de tout support placé dans une zone sécurisée (en particulier lorsque ce support est destiné à être communiqué à des personnes). 9.9 Maintenir un contrôle strict sur le stockage et l'accessibilité des médias contenant des données de titulaire de carte. 14

16 9.9.1 Inventorier strictement tous les supports et s assurer qu ils sont stockés en sécurité Détruire les supports contenant des données de titulaire de carte lorsqu ils ne sont plus nécessaires, pour des raisons commerciales ou juridiques, comme suit : déchiqueter, incinérer ou réduire en pulpe les documents ; éliminer, démagnétiser, déchiqueter ou détruire de toute autre manière tout support électronique, de manière à ce que les données de titulaire de carte ne puissent être reconstruites. 15

17 Surveiller et tester régulièrement les réseaux 10 ème exigence : suivre et surveiller tous les accès aux ressources du réseau et aux données des titulaires de carte Les mécanismes de connexion et la capacité à suivre les activités de l utilisateur sont critiques. L'existence de journaux dans tous les environnements permet une analyse et un suivi complets si quoi que ce soit tourne mal. Il est très difficile de déterminer la cause d une atteinte à la sécurité sans journaux d activité du système Mettre en place un processus destiné à lier tous les accès à des composants du système (en particulier un accès avec des privilèges administratifs, par exemple, de base) à chaque utilisateur individuel Mettre en œuvre, pour toutes les composantes du système, des pistes d audit automatisées afin de reconstituer les événements ci-après : tous les accès d un utilisateur individuel aux données d un titulaire de carte ; toutes les actions effectuées par une personne jouissant d'avantages de base ou administratifs ; l'accès à toutes les pistes de vérification ; les tentatives d accès logique invalides ; l'utilisation des mécanismes d identification et d authentification ; l'initialisation des journaux de vérification ; la création et la suppression d objets de niveau système Enregistrer au moins les entrées de liste de piste de vérification ci-après pour l ensemble des composantes du système et pour chaque événement : l'identification de l utilisateur ; le type d événement ; la date et le lieu ; une indication de succès ou d échec ; l'origine de l événement ; l'identité ou le nom des données, composants de système ou ressources affectés Synchroniser toutes les horloges et heures critiques du système Sécuriser les piste de vérification afin qu elles ne puissent être détruites Limiter la consultation des pistes de vérification aux personnes ayant, du fait de leurs fonctions, besoin d y avoir accès Protéger les fichiers des pistes de vérification des modifications non autorisées Sauvegarder promptement les fichiers des pistes de vérification sur un serveur registre centralisé, ou un support difficile à modifier Copier les journaux relatifs aux réseaux sans fil sur un serveur registre du LAN interne Utiliser, avec les journaux, un logiciel de contrôle de l intégrité des fichiers et de détection des modifications, pour que les données de journal existantes ne puissent être modifiées sans que cela n entraîne le déclenchement d alertes (bien que l'ajout de nouvelles données ne déclenche en principe pas d'alertes) Examiner les journaux pour toutes les composantes des systèmes au moins quotidiennement. Les examens de journaux doivent englober les serveurs remplissant des fonctions de sécurité, 16

18 tels que les systèmes de détection d intrusion (Intrusion Detection System, IDS) et les serveurs authentification, d autorisation et de protocole comptable (AAA) (par exemple, RADIUS). Remarque : des outils d'exploitation de journal, d'analyse et d alerte peuvent être utilisés pour assurer la conformité à l'exigence Conserver l historique de piste de vérification durant au moins un an, avec un minimum de trois mois de disponibilité en ligne. 17

19 11 ème exigence : tester régulièrement les systèmes et procédures de sécurité Des vulnérabilités sont constamment découvertes par des pirates et chercheurs et sont introduites par de nouveaux logiciels. Les systèmes, procédés et logiciels personnalisés doivent être testés fréquemment pour vérifier que la sécurité est assurée dans la durée, ainsi qu'en liaison avec toutes modifications du logiciel Tester annuellement les contrôles de sécurité, limitations, connexions de réseau et restriction pour assurer la capacité à identifier de manière adéquate et à bloquer toutes tentatives d accès non autorisé. Utiliser un analyseur sans fil au moins une fois par trimestre afin d identifier tous les dispositifs sans fil utilisés Réaliser des balayages de vulnérabilité de réseau, internes et externes, au moins une fois par trimestre, ainsi qu après toute modification importante du réseau (telles que l installation de nouvelles composantes de système, les modifications de la topologie du réseau, les changements des règles du pare-feu, les mises à jour de produit). Remarque : les balayages de vulnérabilité externe doivent être assurés par un prestataire agréé par l'industrie de la carte de paiement. Les balayages réalisés après des modifications apportées au réseau peuvent être effectués par les collaborateurs internes de la société Réaliser des tests de pénétration au moins une fois par an, ainsi qu après toute modification ou actualisation significative de l'infrastructure ou de l'application (par exemple, une mise à jour du système d'exploitation, ou l'ajout d'un sous-réseau ou serveur Internet à l'environnement). Ces tests de pénétration doivent inclure les suivants : des tests de pénétration de couche de réseau ; des tests de pénétration de couche d application Utiliser des systèmes de détection d intrusion, des systèmes de détection d intrusion gérés par le système central et des systèmes de prévention d'intrusion, afin de surveiller la totalité du trafic du réseau et de prévenir le personnel en cas d'éventuelles atteintes à la sécurité. Tenir à jour tous les moteurs de détection et de prévention d'intrusions Déployer un logiciel de surveillance d intégrité de fichier afin d alerter les personnels en cas de modification non autorisée d un système critique ou de fichiers de contenu ; et configurer le logiciel pour la réalisation, au moins une fois par semaine, d'une comparaison de fichiers critiques. Les fichiers critiques ne sont pas nécessairement uniquement ceux qui contiennent des données de titulaire de carte. Aux fins de surveillance de l intégrité des fichiers, les fichiers critiques sont d ordinaire ceux qui ne changent pas régulièrement, mais dont la modification pourrait indiquer une atteinte à la sécurité du système, ou un risque d atteinte. Les produits de surveillance de l intégrité de fichier sont généralement livrés pré-configurés, avec les fichiers critiques pour le système d'exploitation lié. D autres fichiers critiques, tels que ceux se rapportant à des applications personnalisées, peuvent être évalués et définis par l'entité (qu'il s'agisse d'un commerçant ou d'un prestataire de services). 18

20 Disposer d une politique en matière de sécurité de l information 12 ème exigence : disposer d une politique prenant en compte la sécurité de l information pour les employés et sous-traitants Une solide politique en matière de sécurité donne le ton à l ensemble de la société et indique aux employés ce qui est attendu d eux. Tous les employés doivent être conscients de la sensibilité des données et des responsabilités qui leur incombent en liaison avec leur protection Édicter, publier, maintenir en vigueur et diffuser une politique de sécurité correspondant aux caractéristiques ci-après : prenant en compte l ensemble des exigences contenues dans les présentes spécifications ; comportant un processus annuel d identification des menaces et vulnérabilités, qui débouche sur une évaluation formelle du risque ; incluant un examen au moins annuel, ainsi que des mises à jour lorsque l environnement change Développer des procédures de sécurité opérationnelles quotidiennes conformes aux exigences des présentes spécifications (par exemple, des procédures de maintenance de compte d utilisateur et de vérification de journal) Élaborer des politiques d utilisation pour les technologies critiques d interface avec des employés (comme, par exemple, les modems et appareils sans fil) afin de définir une bonne utilisation de ces technologies à l intention de l ensemble des employés et sous-traitants. S assurer que ces politiques régissant l utilisation comportent les obligations ci-après : l'accord explicite de la direction ; une obligation d authentification pour utiliser la technologie ; une liste de la totalité des dispositifs et personnels disposant d un accès ; un étiquetage des appareils indiquant l identité du propriétaire, ses coordonnées et le but de leur utilisation ; les utilisations acceptables des technologies ; les emplacements de réseau acceptables pour les technologies ; une liste des produits approuvés par la société ; une interruption automatique de la session après une période d inactivité spécifique ; l'activation des modems fournisseurs uniquement lorsque ces derniers en ont besoin, avec désactivation immédiate après utilisation ; en cas d accès distant aux données de titulaire de carte via modem, l interdiction de stocker ces données de titulaire sur disque dur local, disquette ou autre support externe. Indisponibilité des fonctions copier/coller et d impression lors de l accès distant Faire en sorte que les politiques et procédures en matière de sécurité définissent clairement les responsabilités en matière de sécurité de l information telles qu elles s appliquent à l ensemble des employés et sous-traitants Attribuer à un individu ou à une équipe les responsabilités ci-après en matière de gestion de la sécurité de l'information : mettre en place, consigner par écrit et diffuser les politiques et procédures en matière de sécurité ; 19

21 surveiller et analyser les informations et alertes dans le domaine de la sécurité, et en assurer la diffusion auprès des collaborateurs compétents ; élaborer, consigner par écrit et diffuser des procédures d intervention en cas d incident et de remontée des paliers de décisions en matière de sécurité, afin d assurer une gestion ponctuelle et efficace de toutes situations ; administrer les comptes d utilisateur, y compris tous ajouts et toutes suppressions ou modifications ; surveiller et contrôler tous les accès à des données Mettre en œuvre un programme formel de sensibilisation à la sécurité pour que tous les employés soient pleinement conscients de l importance de la sécurité des données des titulaires de carte Former les employés lors de leur recrutement et, par la suite, au moins annuellement (par exemple, par courrier, voie d affichage, mémorandums, réunions et promotions) Exiger les employés qu ils reconnaissent formellement, par écrit, avoir lu et compris la politique et les procédures de la société en matière de sécurité Soumettre les employés éventuels à des vérifications afin de minimiser le risque d attaques de sources internes. En ce qui concerne les salariés tels que les personnels de caisse de point de vente, qui ont seulement accès à un numéro de carte à la fois, lors de la réalisation d une transaction, cette exigence a uniquement valeur de recommandation Si des données de titulaire de carte sont communiquées à des prestataires de services, les mesures ci-après sont impératives : les prestataires de services doivent se conformer aux exigences des Normes PCI DSS ; un accord comportant une attestation certifiant que le prestataire de services est responsable de la sécurité des données de titulaire de carte en la possession du fournisseur/prestataire Mettre en œuvre un plan d intervention en cas d incident. Être prêt à intervenir sur-le-champ en cas de violation de la sécurité du système Élaborer le plan d intervention en cas d incident destiné à être appliqué lors d une atteinte à la sécurité du système. Faire en sorte que le plan prenne en compte, au moins, les procédures spécifiques d intervention en cas d incident, de reprise et de continuité de l activité, de sauvegarde, les rôles et responsabilités, ainsi que les stratégies de communication et de contact (par exemple, en informant les Acquéreurs et les associations de carte de crédit) Tester le plan au moins une fois par an Désigner des collaborateurs spécifiques, qui devront être disponibles 24 heures sur 24, 7 jours sur 7, pour répondre aux alertes Fournir une formation appropriée aux collaborateurs en charge de l intervention en cas d atteinte à la sécurité Inclure les alertes suite à une détection d intrusion, de prévention d intrusion et des systèmes de surveillance de l intégrité des fichiers Développer des processus de modification et d évolution du plan d'intervention en cas d incident, en fonction des leçons apprises, ainsi que dans le but de tenir compte des évolutions du secteur Toutes les entités de traitement et prestataires de services doivent disposer de, et appliquer des politiques et procédures de gestion d entités liées incluant ce qui suit : gérer une liste d entités liées ; 20

22 faire en sorte qu une vérification préalable soit effectuée avant la connexion de toute entité ; s assurer que l entité est conforme aux Normes PCI DSS ; connecter et déconnecter les entités conformément à une procédure établie. 21

23 Annexe A : Application des normes PCI DSS des fournisseurs d hébergement Exigence A.1 : les fournisseurs d hébergement protègent l environnement des données de titulaire de carte Comme indiqué dans l Exigence 12.8, tous prestataires de service disposant d un accès à des données de titulaire de carte (y compris les fournisseurs d hébergement) doivent se conformer aux Normes PCI DSS. En outre, l Exigence 2.4 prévoit que les fournisseurs d hébergement doivent protéger l environnement et les données hébergés de chaque entité. De ce fait, ils doivent accorder une attention particulière aux aspects suivants : A.1 Protéger les données et l environnement hébergés de chaque entité (qu il s agisse d un commerçant, d un prestataire de services ou de toute autre entité), comme indiqué dans les points A.1.1 à A.1.4 : A.1.1 faire en sorte que chaque entité ait uniquement accès à l environnement de données de son propre titulaire de carte ; A.1.2 limiter l accès et les privilèges de chaque entité exclusivement à l environnement de données de son propre titulaire de carte ; A.1.3 faire en sorte que les pistes de connexion et de vérification soient activées et uniques à l environnement de données de titulaire de carte de chaque entité, et conformément à l'exigence 10 des Normes PCI DSS ; A.1.4 mettre en place des processus destinés à permettre des investigations technico-légales ponctuelles en cas d'atteinte à la sécurité d'une entité marchande ou d'un prestataire de services hébergé. Un fournisseur hébergé doit se conformer à ces obligations, ainsi qu à toutes autres sections pertinentes des Normes PCI DSS. Remarque : même s'il est possible qu'un fournisseur d'hébergement se conforme à ces exigences, la conformité de l'entité utilisant le fournisseur d'hébergement n est pas nécessairement garantie. Chaque entité doit impérativement se conformer aux Normes PCI DSS et, le cas échéant, valider la conformité. v

24 Annexe B : Contrôles correctifs Contrôles correctifs Dispositions générales Des contrôles correctifs peuvent être envisagés en liaison avec la plupart des exigences des Normes PCI DSS, lorsqu une entité n est pas en mesure de se conformer aux spécifications techniques relatives à une exigence, mais a suffisamment atténué le risque associé. Pour la définition complète des contrôles correctifs, voir le Glossaire des Normes PCI DSS. L efficacité d un contrôle correctif est fonction des spécificités de l environnement dans lequel le contrôle de sécurité est réalisé, des contrôles de sécurité environnants et de la configuration du contrôle. Les sociétés doivent savoir qu un contrôle correctif donné ne saurait être efficace dans tous les environnements. Chaque contrôle correctif doit donner lieu à une évaluation approfondie après sa mise en œuvre, afin d en garantir l efficacité. Les principes directeurs ci-après prévoient des contrôles correctifs lorsque les sociétés ne sont pas en mesure de rendre illisibles les données de titulaire de carte, conformément aux dispositions de l exigence 3.4. Contrôles correctifs afférents à l Exigence 3.4. Lorsqu une société n est pas en mesure de rendre illisible des données de titulaire de carte (par exemple, par cryptage) en raison de contraintes techniques ou de limitations commerciales, des contrôles correctifs pourront être envisagés. Seules les sociétés ayant entrepris une analyse de risque et soumises à des contraintes technologiques ou commerciales documentées légitimes peuvent envisager le recours à des contrôles correctifs aux fins de mise en conformité. Les sociétés envisageant de recourir à des contrôles correctifs dans le but de rendre illisibles les données de titulaire de carte doivent comprendre les risques constitués par la conservation de données de titulaire de carte lisibles. De manière générale, les contrôles doivent fournir une protection supplémentaire dans le but d atténuer tous risques supplémentaires liés à la conservation de données de titulaire de carte lisibles. Les contrôles envisagés doivent être en plus de ceux prévus par les Normes PCI DSS et doivent être conformes à la définition des «Contrôles correctifs» contenue dans le Glossaire des Normes PCI DSS. Les contrôles correctifs peuvent inclure un dispositif, ou une combinaison de dispositifs, d applications et de commandes remplissant toutes les conditions ci-après : 1. assurer une segmentation/abstraction supplémentaire (par exemple, au niveau de la couche de réseau) ; 2. offrir l aptitude à limiter l accès aux données de titulaire de carte ou aux bases de données, sur la base des critères suivants : adresses Internet/MAC ; application/service ; comptes/groupes d utilisateur ; type de données (filtre dynamique à paquets) ; 3. limiter l accès logique à la base de données ; accès par contrôle logiciel à la base de données indépendante d Active Directory ou de Lightweight Directory Access Protocol (LDAP) ; 4. prévenir/détecter les attaques courantes contre des applications ou bases de données (par exemple, injection de commandes SQL). v