Payment Card Industry (PCI) Normes en matière de sécurité des données Version 1.1 Date de publication : septembre 2006
Mettre en place et gérer un réseau sécurisé 1 ère exigence : installer et gérer une configuration de pare-feu afin de protéger les données des titulaires de carte 2 ème exigence : ne pas utiliser les paramètres par défaut du fournisseur pour les mots de passe et les autres paramètres de sécurité du système Protéger les données des titulaires de carte 3 ème exigence : protéger les données des titulaires de carte stockées 4 ème exigence : crypter la transmission des données des titulaires de carte sur les réseaux publics ouverts Disposer d un programme de gestion de la vulnérabilité 5 ème exigence : 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
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
figurent notamment les pare-feux, commutateurs, routeurs, points d'accès sans fil, appareils de réseau et autres dispositifs de sécurité. Les divers types de serveur incluent notamment les suivants : Internet, base de données, authentification, courrier, mandataire, network time protocol (NTP) et serveur de nom de domaine (domain name server, DNS). Les applications englobent l ensemble des applications achetées et personnalisées, y compris internes et externes (Internet). 3
Mettre en place et gérer un réseau sécurisé 1 ère exigence : installer et gérer une configuration de pare-feu afin de protéger les 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 : 1.1.1 un processus formel d approbation et de test de toutes les connexions externes de réseau, ainsi que de l ensemble des modifications apportées à la configuration du parefeu ; 1.1.2 un diagramme du réseau à jour, avec toutes les connexions à des données de titulaires de carte, y compris tous réseaux sans fil ; 1.1.3 la nécessité d un pare-feu pour chaque connexion Internet et entre toute zone d'accueil (demilitarized zone, DMZ) et la zone de réseau interne ; 1.1.4 la description des groupes, rôles et responsabilités en matière de gestion logique des composants de réseau ; 1.1.5 une liste écrite des services et ports nécessaires à l activité ; 1.1.6 la justification et la consignation par écrit de tous protocoles disponibles en dehors des protocoles http (hypertext transfer protocol, HTTP), SSL (secure sockets layer, SSL), SSH (secure shell, SSH) et de réseau privé virtuel (virtual private network, VPN) ; 1.1.7 la justification et la consignation par écrit de tous protocoles à risque autorisés (par exemple, un protocole de transfert de fichiers (file transfer protocol, FTP), avec les raisons de l utilisation du protocole, et les mesures de sécurité utilisées) ; 1.1.8 un examen trimestriel des ensembles de règles applicables aux pare-feux et aux routeurs ; 1.1.9 des normes de configuration pour les routeurs ; 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 : 1.3.1 la restriction du trafic Internet entrant vers des adresses Internet dans la zone d'accueil (filtres d'entrée) ; 1.3.2 ne pas laisser des adresses internes passer de l Internet à la zone d accueil ; 4
1.3.3 la mise en œuvre d une inspection dynamique, également désignée filtre dynamique à paquets (ce qui signifie que seule les connexions «établies» sont autorisées dans le réseau) ; 1.3.4 le positionnement de la base de données dans une zone de réseau interne, distincte de la zone d accueil ; 1.3.5 la limitation du trafic entrant et sortant à ce qui est nécessaire à l'environnement des données de titulaires de carte ; 1.3.6 la sécurisation et la synchronisation de fichiers de configuration de routeur. Les fichiers de configuration d'exécution (pour le fonctionnement normal des routeurs) et les fichiers de configuration de démarrage (lors du redémarrage des machines) doivent par exemple présenter une configuration sécurisée identique ; 1.3.7 l'interdiction de tout autre trafic, entrant ou sortant, dans la mesure où il n a pas été spécifiquement autorisé ; 1.3.8 l'installation de pare-feux de périmètre entre tous réseaux sans fil et l environnement de données de titulaires de carte, et la configuration de ces pare-feux de manière à bloquer tout trafic provenant de l'environnement sans fil, ou pour contrôler tout trafic (lorsqu il est nécessaire à des fins commerciales) ; 1.3.9 l'installation d un logiciel pare-feu personnel sur un ordinateur portable ou un ordinateur appartenant à un employé disposant d'une connectivité directe à l'internet (par exemple, les ordinateurs portables utilisés par les employés), utilisés pour accéder au réseau de l'organisation. 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). 1.4.1 Mettre en place une zone d accueil pour filtrer et vérifier l ensemble du trafic, ainsi que pour interdire les routes directes pour le trafic Internet entrant et sortant. 1.4.2 Restreindre le trafic sortant des applications de carte de paiement vers des adresses Internet situées dans la zone d accueil. 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). 2.1.1 Dans le cas des environnements sans fil, modifier les réglages par défaut du fournisseur sans fil, y compris notamment les clés Wired Equivalent Privacy (WEP), le Service Set IDentifier (SSID) par défaut, les mots de passe et les chaînes communautaires SNMP. Désactiver les émissions en clair du SSID sur le réseau. Mettre 5
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). 2.2.1 Mettre en œuvre uniquement une section primaire par serveur (ainsi, les serveurs Internet, de base de données et DNS doivent être mis en place sur des serveurs distincts) 2.2.2 Désactiver tous les services et protocoles inutiles et non sécurisés (les services et protocoles qui ne sont pas directement nécessaires à l exécution de la fonction spécifiée des appareils) 2.2.3 Configurer les paramètres de sécurité du système pour prévenir toute utilisation frauduleuse 2.2.4 Supprimer toutes les fonctionnalités inutiles, telles que les scripts, lecteurs, dispositifs, sous-systèmes, systèmes de fichiers et serveurs Internet inutiles. 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
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 3.2.1 à 3.2.3 ci-après : 3.2.1 Ne jamais stocker la totalité du contenu d une quelconque piste de la bande magnétique (au dos d'une carte, sur une puce ou ailleurs). Les données sont alternativement désignées piste complète, piste 1, piste 2 et données de bande magnétique. Dans le cours normal de l activité, il est possible qu il soit nécessaire de conserver les éléments de données de la bande magnétique ci-après : le nom du titulaire du compte, le numéro de compte primaire (primary account number, PAN), la date d expiration et le code de service. Afin de minimiser le risque, stocker uniquement les éléments de données nécessaires à l'activité. NE JAMAIS stocker le code de vérification de la carte, ni la valeur, ni non plus des éléments de données de valeur de vérification du code PIN. Remarque : pour plus d information, se reporter au «Glossaire». 3.2.2 Ne pas stocker de code de validation de carte, ni de valeur (à trois ou quatre chiffres, imprimés sur le côté face ou au verso d'une carte de paiement) utilisée pour vérifier des transactions cartes absente (card-not-present, CNP). Remarque : pour plus d information, se reporter au «Glossaire». 3.2.3 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
une troncature ; des jetons et pads index (les pads doivent être stockés de manière sécurisée) ; une cryptographie performante, avec des processus et procédures de gestion clés associés. En ce qui concerne les coordonnées de compte, au MINIMUM, le PAN doit être rendu illisible. Si, pour une raison ou pour une autre, une société n est pas en mesure de crypter des données de titulaire de carte, se reporter à l'annexe B : «Contrôles destinés à suppléer au défaut de cryptage des données stockées». 3.4.1 Si un cryptage par disque est utilisé (au lieu d un cryptage par fichier ou base de données au niveau colonne), l'accès logique doit être géré indépendamment des mécanismes de contrôle d'accès au système d'exploitation natif (par exemple, en n'utilisant pas un système local, ni des comptes Active Directory). Les clés de décryptage ne doivent pas être liées à des comptes d utilisateur. 3.5 Protéger les clés de cryptage utilisées pour le cryptage des données de titulaire de carte, à la fois contre la divulgation et l utilisation illicite. 3.5.1 limiter l accès aux clés au plus petit nombre possible de dépositaires, en fonction des nécessités ; 3.5.2 stocker les clés, de manière sécurisée, en un nombre de lieux et de formes aussi réduit que possible. 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 : 3.6.1 génération de clés performantes ; 3.6.2 distribution de clé sécurisée ; 3.6.3 stockage de clé sécurisé ; 3.6.4 changement périodique des clés : comme tenu pour nécessaire et recommandé par l application associée (par exemple, le changement de clé, ou re-keying), de préférence automatiquement ; au moins annuellement ; 3.6.5 destruction des anciennes clés ; 3.6.6 répartition des informations et mise en place d un double système de contrôle des clés (de manière à ce que deux ou trois personnes, chacune d elles connaissant une partie de la clé, reconstituent la clé dans son intégralité) ; 3.6.7 la prévention des substitutions de clés non autorisées ; 3.6.8 le remplacement des clés dont compromises ou suspectées de l être ; 3.6.9 l'annulation des clés anciennes ou invalides ; 3.6.10 l'obligation, pour les principaux dépositaires de clés, de signer un formulaire indiquant qu ils comprennent et acceptent les responsabilités liées à leurs fonctions de dépositaire. 4 ème exigence : crypter la transmission des données des titulaires de carte sur les réseaux publics ouverts Les informations sensibles doivent être cryptées lors de leur transmission sur des réseaux permettant aux pirates, ainsi qu ils le font couramment, d intercepter, de modifier et de détourner des données en cours de transit. 8
4.1 Utiliser des techniques de cryptographie et des protocoles de sécurité performants, comme par exemple des protocoles SSL (Secure Sockets Layer)/TLS (Transport layer security) et IPSEC (Internet Protocol Security) pour protéger les données sensibles des titulaires de carte lors de leur transmission sur des réseaux publics ouverts. L Internet, le WiFi (IEEE 802.11x), le réseau de téléphonie mobile (Global System for Mobile Communications, GSM) et le General Packet Radio Service (GPRS) sont des exemples de réseaux publics ouverts relevant du périmètre des normes PCI DSS. 4.1.1 Dans le cas des réseaux sans fil transmettant des données de titulaire de carte, crypter les transmissions en utilisant la technologie d accès protégé au WiFi (WPA ou WPA2), IPSEC VPN ou SSL/TLS. Ne jamais se fier uniquement au protocole WEP (Wired Equivalent Privacy) pour protéger la confidentialité et l accès à un réseau LAN sans fil. En cas d utilisation de WEP, prendre les mesures suivantes : 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 e-mail des employés. Un logiciel anti-virus doit être utilisé sur tous les systèmes ordinairement affectés par les virus afin de protéger les systèmes contre les logiciels dangereux. 5.1 Déployer un logiciel anti-virus sur tous les systèmes généralement affectés par les virus (en particulier les ordinateurs personnels et les serveurs) Remarque : les systèmes d exploitation sous UNIX et les ordinateurs centraux ne figurent pas au nombre des systèmes couramment affectés par les virus. 5.1.1 Faire en sorte que les programmes anti-virus soient capables de détecter d autres formes de logiciels nuisibles, y compris les logiciels d espionnage (ou «spyware») et publicitaires, de les supprimer et d'assurer une protection contre ceux-ci. 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
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. 6.3.1 Tester tous les correctifs de sécurité, ainsi que toutes modifications de configuration de système ou de logiciel avant déploiement. 6.3.2 Séparer les environnements de développement, de test et de production. 6.3.3 Séparation des obligations entre les environnements de développement, de test et de production. 6.3.4 Les données de production (PAN actifs) ne sont pas utilisées aux fins de test ou de développement. 6.3.5 Suppression des données et comptes de tests avant que les systèmes de production ne deviennent actifs. 6.3.6 Suppression des comptes d application, noms d utilisateur et mots de passe usuels avant que les applications ne deviennent actives ou ne soient mises à la disposition de clients. 6.3.7 Examen du code personnalisé avant de mettre à la disposition de la production ou de clients afin d identifier toute vulnérabilité de cryptage éventuelle. 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 : 6.4.1 consignation écrite de l impact ; 6.4.2 approbation par signature de la direction par les parties appropriées ; 6.4.3 vérification de la fonctionnalité opérationnelle ; 6.4.4 procédures de sauvegarde. 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 : 6.5.1 les entrées non validées ; 6.5.2 un contrôle d accès compromis (par exemple, une utilisation malveillante d identités d utilisateur) ; 6.5.3 une authentification et une gestion de session compromises (l utilisation d'éléments d authentification de compte et les cookies de session) ; 6.5.4 les attaques par Cross-Site Scripting (XSS ou CSS) ; 6.5.5 les attaques par débordement de tampon ; 6.5.6 les attaques par injection (par exemple, une injection de commandes SQL (Structured Query Language)) ; 6.5.7 une gestion d erreur inadéquate ; 10
6.5.8 un stockage non sécurisé ; 6.5.9 un refus de service ; 6.5.10 une gestion de configuration non sécurisée. 6.6 Faire en sorte que toutes les applications d interface Internet soient protégées contre les attaques connues grâce à l une ou l autre des méthodes suivantes : faire contrôler par une organisation spécialisée dans la sécurité des applications, tout code d'application personnalisé aux fins de détection des vulnérabilités courantes ; Installer un pare-feu de couche application qui protège les applications d interface Internet. Remarque : cette méthode est considérée comme une «meilleure pratique» jusqu au 30 juin 2008, après quoi, elle devient obligatoire. Mettre en œuvre des mesures de contrôle d'accès efficaces 7 ème exigence : limiter l accès aux données des porteurs de carte aux cas de nécessité professionnelle absolue Cette exigence est destinée à garantir que seuls les personnels autorisés peuvent accéder aux données critiques. 7.1 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
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 : 8.5.1 contrôler l ajout d'identités d utilisateur, d identifiants et d autres éléments d identification, leur suppression et leur modification ; 8.5.2 vérifier l identité de l utilisateur avant de procéder à une réinitialisation de mot de passe ; 8.5.3 mettre en place un mot de passe initial, avec une valeur unique, pour chaque utilisateur et le modifier immédiatement après la première utilisation ; 8.5.4 mettre fin immédiatement à l accès des utilisateurs ayant cessé d être employés par l entreprise ; 8.5.5 supprimer les comptes d utilisateur inactifs au moins tous les 90 jours ; 8.5.6 activer les comptes utilisés par des fournisseurs aux fins de maintenance à distance uniquement durant la période nécessaire ; 8.5.7 communiquer les procédures et politiques en matière de mot de passe à tous les utilisateurs ayant accès aux données de titulaires de carte ; 8.5.8 ne pas utiliser de comptes et mots de passe collectifs, partagés ou génériques ; 8.5.9 changer les mots de passe d utilisateur au moins tous les 90 jours ; 8.5.10 exiger que les mots de passe comptent au moins sept caractères ; 8.5.11 utiliser des mots de passe contenant des caractères à la fois numériques et alphabétiques ; 8.5.12 ne pas autoriser une personne à soumettre un nouveau mot de passe identique à l un ou l autre des quatre derniers mots de passe utilisés par elle ; 8.5.13 limiter le nombre de tentatives d accès en verrouillant l identité d utilisateur après au plus 6 tentatives ; 8.5.14 fixer la période de verrouillage à trente minutes, ou jusqu'à ce qu'un administrateur active l'identité d'utilisateur ; 12