Payment Card Industry (PCI) Normes en matière de sécurité ... · de carte du reste du réseau...

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

Procédures d’audit de sécurité

Version 1.1 Date de publication : septembre 2006

Copyright 2006 PCI Security Standards Council LLC. Security Audit Procedures v 1.1 2

Table des matières Procédures d’audit de sécurité .................................................................................................................................................................................................. 1 Version 1.1 ................................................................................................................................................................................................................................ 1

Table des matières ............................................................................................................................................................................................................ 2 Introduction ............................................................................................................................................................................................................................... 3 Informations relatives aux conditions d’application des Normes PCI DSS ................................................................................................................................ 4 Périmètre du contrôle de conformité aux Normes PCI DSS ...................................................................................................................................................... 5

Sans fil ............................................................................................................................................................................................................................... 6 Externalisation ................................................................................................................................................................................................................... 6 Échantillon ......................................................................................................................................................................................................................... 6 Contrôles correctifs ............................................................................................................................................................................................................ 7

Instructions et contenus afférents au Rapport sur la conformité ................................................................................................................................................ 7 Revalidation d’éléments ouverts ............................................................................................................................................................................................... 9 Mettre en place et gérer un réseau sécurisé ............................................................................................................................................................................. 9

1ère exigence : installer et gérer une configuration de pare-feu afin de protéger les données des titulaires de carte .......................................................... 9 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 ....... 14

Protéger les données des titulaires de carte ........................................................................................................................................................................... 18 3ème exigence : protéger les données des titulaires de carte en stock .............................................................................................................................. 18 4ème exigence : crypter la transmission des données des titulaires de carte sur les réseaux publics ouverts ................................................................... 26

Disposer d’un programme de gestion de la vulnérabilité ......................................................................................................................................................... 29 5ème exigence : utiliser et mettre à jour régulièrement un logiciel ou des programmes antivirus ....................................................................................... 29 6ème exigence : développer et gérer des applications et ses systèmes sécurisés ............................................................................................................ 30

Mettre en œuvre des mesures de contrôle d'accès efficaces .................................................................................................................................................. 36 7ème exigence : limiter l’accès aux données des porteurs de carte aux cas de nécessité professionnelle absolue ........................................................... 36 8ème exigence : attribuer une identité d’utilisateur unique à chaque personne disposant d’un accès informatique. .......................................................... 37 9ème exigence : limiter l’accès physique aux données des titulaires de carte. ................................................................................................................... 43

Surveiller et tester régulièrement les réseaux ......................................................................................................................................................................... 47 11ème exigence : tester régulièrement les systèmes et procédures de sécurité ................................................................................................................ 50

Disposer d’une politique en matière de sécurité de l’information ............................................................................................................................................. 53 12ème exigence : disposer d’une politique prenant en compte la sécurité de l’information pour les employés et sous-traitants ........................................ 53

Annexe A : conditions d’application des Normes PCI DSS pour les fournisseurs d’hébergement (avec les Procédures de test) ............................................ 61 Exigence A.1 : les fournisseurs d’hébergement protègent l’environnement des données de titulaire de carte ................................................................. 61

Annexe B – Contrôles correctifs .............................................................................................................................................................................................. 65 Contrôles correctifs – Dispositions générales .................................................................................................................................................................. 65 Contrôles correctifs afférents à l’Exigence 3.4. ................................................................................................................................................................ 65

Annexe C : Feuille de travail de contrôle correctif/exemple complété ..................................................................................................................................... 66


Introduction Les Procédures d’audit de sécurité de PCI sont destinées à être utilisées par des évaluateurs procédant à des vérifications sur site pour des commerçants et des prestataires de services nécessaires pour valider la conformité aux exigences des Normes de Payment Card Industry (PCI) en matière de sécurité des données (Data Security Standard, DSS). Les exigences et les procédures de vérification présentées dans ce document sont fondées sur les Normes PCI DSSDSS.

Ce document comporte les éléments suivants :

• Introduction • Informations relatives aux conditions d’application des Normes PCI DSS • Périmètre du contrôle de conformité aux Normes PCI DSS • Instructions et contenus afférents au Rapport sur la conformité • Revalidation d’éléments ouverts • Procédures d’audit de sécurité ANNEXES • Annexe A : conditions d’application des Normes PCI DSS pour les fournisseurs d’hébergement (avec les

Procédures de test) • Annexe B : Contrôles correctifs

• Annexe C : Feuille de travail de contrôle correctif/exemple complété


Informations relatives aux conditions d’application des Normes PCI DSS 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.

* 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 Normes 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).

Élément de données

Stockage autorisé

Protection requise

EXIG. PCI DSS 3.4

Données titulaire de carte de crédit Primary Account Number (PAN) OUI OUI OUI

Nom du titulaire de carte de crédit*OUI OUI* NON

Code service* OUI OUI* NON

Date d’expiration* OUI OUI* NON

Données d’authentification sensibles** Bande magnétique entièreNON s.o. s.o.

CVC2/CVV2/CID NON s.o. s.o.

Bloc PIN/PIN NON s.o. s.o.

Formatted: French (France)


Périmètre du contrôle de conformité aux Normes PCI DSS Ces exigences de sécurité des Normes PCI DSS s'appliquent à l'ensemble des « composantes du système ». Ces composantes sont définies comme toute composante réseau, tout serveur ou toute application, 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. Au nombre des composantes de réseau 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).

Une segmentation adéquate du réseau, qui isole des systèmes stockant, traitant ou transmettant des données de titulaire de carte du reste du réseau peut réduire le périmètre de l’environnement de données du titulaire de carte. Le vérificateur doit s’assurer que la segmentation est adéquate et réduit le périmètre de vérification.

Un prestataire de services ou un commerçant peut avoir recours à un fournisseur tiers pour gérer des composantes telles que des routeurs, pare-feux ou bases de données, la sécurité physique et/ou des serveurs. Le cas échéant, il est possible que cela ait une incidence sur la sécurité de l’environnement des données de titulaire de carte. Les services pertinents du fournisseur tiers doivent faire l'objet de vérifications, soit 1) lors de chacun des audits PCI des clients du fournisseur tiers ; soit 2) à l'occasion d'un audit PCI du fournisseur tiers lui-même.

En ce qui concerne les prestataires de services tenus de se soumettre à une vérification sur site annuelle, une validation de conformité doit, sauf spécification contraire, être mise en œuvre pour tous systèmes sur lesquels des données de titulaire de carte sont stockées, traitées ou transmises.

Dans le cas des commerçants tenus de se soumettre à une vérification sur site annuelle, la validation de conformité est axée sur tout/tous système(s) ou composant(s) de système lié(s) à l’autorisation et au règlement sur le(s)quel(s) des données de titulaire de carte sont stockées, traitées ou transmises, y compris les suivants : • toutes connexions externes au réseau commercial (par exemple : un accès distant destiné aux employés ; une société

de carte de paiement ; un accès de tiers aux fins de traitement et de maintenance) ; • toutes les connexions à, et depuis l’environnement d’autorisation et de règlement (par exemple : les connexions pour

l’accès employé ou des dispositifs tels que des pare-feux et des routeurs) ; • tous entrepôts de données hors de l’environnement d’autorisation et de règlement stockant plus de 500 000 numéros

de compte. Remarque : même si certains entrepôts de données ou systèmes sont exclus de la vérification, il incombe au commerçant de s'assurer que tous systèmes stockant, traitant ou transmettant des données de titulaire de carte sont conformes aux Normes PCI DSS ;


• l’environnement de point de vente (point-of-sale, POS) : le lieu où une transaction est acceptée, dans un point de vente commercial (c’est-à-dire, une boutique de détail, un restaurant, un établissement hôtelier, une station service, un supermarché ou tout autre point de vente) ;

• en l’absence d’accès externe au site commercial (par Internet, accès sans fil, réseau privé virtuel (Virtual Private Network, VPN), réseau commuté ou haut débit, ou machines accessibles publiquement, telles que des kiosques), l'environnement de point de vente peut être exclu.

Sans fil

Si une technologie sans fil est utilisée pour stocker, traiter ou transmettre des données de titulaire de carte (par exemple, des transactions de point de vente, ou l’enregistrement de données en situation de mobilité, dit « line-busting »), ou bien, si un réseau local sans fil d’entreprise (Local Area Network, LAN) est connecté à, ou fait partie de l’environnement du titulaire de carte (par exemple, parce qu’il n’est pas clairement séparé par un pare-feu), les Exigences et Procédures de test pour les environnements sans fil s’appliquent et doivent également être mises en œuvre. La sécurité des réseaux sans fil n’est pas encore parvenue à maturité, mais ces exigences spécifient que les fonctionnalités de base en matière de sécurité des réseaux sans fil seront mises en œuvre dans le but d’assurer une protection minimale. Étant donné qu’il n’est pas encore possible de sécuriser convenablement les technologies sans fil, avant qu’une technologie sans fil ne soit mise en place, une société doit évaluer avec soin la technologie par rapport aux risques. Envisager le déploiement d’une technologie sans fil uniquement pour la transmission de données non sensibles, ou dans l’attente du déploiement d'une technologie plus sûre.

Externalisation

En ce qui concerne les entités qui externalisent le stockage, le traitement ou la transmission de données de titulaires de carte à des prestataires de services tiers, le Rapport sur la conformité doit consigner par écrit le rôle de chacun des prestataires. En outre, il incombe aux prestataires de services de valider leur propre conformité par rapport aux exigences des Normes PCI DSS, indépendamment des audits auxquels sont soumis leurs clients. En outre, les commerçants et prestataires de services doivent exiger par contrat que tous tiers associés ayant accès aux données de titulaire de carte se conforment aux Normes PCI DSS. Pour plus de détails, se reporter à l’exigence 12.8 du présent document.

Échantillon

L’évaluateur peut sélectionner un échantillon représentatif de composants du système aux fins de tests. L’échantillon doit être une sélection représentative de tous les types de composants du système et comporter une multiplicité de systèmes d’exploitation, de fonctions et d’applications applicables au domaine soumis à examen. Le responsable des vérifications pourrait par exemple choisir des serveurs Sun fonctionnant sous Apache WWW, des serveurs NT sous Oracle, des systèmes principaux exécutant des applications existantes de traitement de carte, des serveurs de transfert de données fonctionnant sous HP-UX, ainsi que des serveurs Linux sous MYSQL. Si toutes les applications fonctionnent à partir d’un seul système d’exploitation (par exemple, NT, Sun), l’échantillon doit néanmoins comporter une multiplicité d’applications (par exemple, des serveurs de base de données, serveurs Internet et serveurs de transfert de données).


Lors de la sélection d’échantillons de boutiques de commerçants, ou pour les commerçants franchisés, les évaluateurs doivent prendre en compte les éléments suivants : • s'ils existe des processus standards obligatoires en place, prévus par les Normes PCI DSS, auxquels chaque boutique doit

se conformer, l’échantillon peut être plus réduit que nécessaire en l’absence de processus standard, afin de démontrer raisonnablement que chaque boutique est configurée conformément aux processus standard ;

• si plus d’un type de processus standard est en place (par exemple, pour des types de boutiques différents), l'échantillon doit être suffisamment important pour englober des boutiques sécurisées par chaque type de processus ;

• en l'absence de processus standard prévus par les Normes PCI DSS, la taille de l’échantillon doit être plus importante pour vérifier que chaque boutique comprend et met en œuvre les exigences des Normes PCI DSS de manière appropriée.

Contrôles correctifs

Les contrôles correctifs doivent être consignés par écrit par l’évaluateur et joints à la soumission du Rapport sur la conformité, comme indiqué en Annexe C : Fiche de contrôle correctif/exemple achevé.

Pour une définition des « contrôles correctifs », voir le document Glossaire, abréviations et acronymes des Normes PCI DSS.

Instructions et contenus afférents au Rapport sur la conformité Ce document doit être utilisé par des évaluateurs comme modèle pour l'élaboration du Rapport sur la conformité. L’entité faisant l’objet des vérifications doit se conformer aux exigences en matière de rapport de chaque société de carte de paiement, pour faire en sorte que chaque société de carte de paiement reconnaisse la conformité de l’entité. Contacter chaque société de carte de paiement pour déterminer les exigences et instructions de chaque société en matière de rapport. Tous les évaluateurs doivent, pour établir un Rapport sur la conformité, se conformer aux instructions en matière de contenu et de format.

1. Coordonnées et date du rapport

• Inclure les coordonnées du commerçant ou du prestataire de services, ainsi que celles de l'évaluateur • Date du rapport

2. Sommaire exécutif Inclure les éléments suivants : • descriptif de l’activité ; • énumérer les prestataires de services et les autres entités avec lesquelles la société partage des données de titulaire de carte ; • énumérer les relations de l’entité de traitement ; • indiquer si une entité est directement connectée à une société de carte de paiement ;


• en ce qui concerne les commerçants, les produits de point de vente utilisés ; • toutes entités en propriété exclusive devant être en conformité avec les Normes PCI DSS ; • toutes entités internationales devant être en conformité avec les Normes PCI DSS ; • tous réseaux locaux sans fil d’entreprise (LAN) et/ou terminaux de point de vente sans fil connectés à l’environnement de carte de

données.

3. Description de l’objet des travaux et de l’approche adoptée

• Version du document relatif aux Procédures en matière d’audit de sécurité utilisées pour procéder à l’évaluation • Période de l’évaluation • Environnement sur lequel l’évaluation est axée (par exemple, les points d’accès Internet du client, le réseau interne d'entreprise, les

points de traitement de la société de carte de paiement) • Tous secteurs exclus de l’examen • Une brève description, ou un schéma très général de la topologie et des commandes du réseau • Une liste des personnes interrogées • Une liste des pièces examinées • Une liste des matériels et logiciels critiques (par exemple, base de données ou logiciel de cryptage) utilisés • Pour les vérifications concernant des fournisseurs de services gérés (Managed Service Provider, MSP), déterminer clairement

quelles exigences de ce document s'appliquent au MPS concerné (et sont pris en compte dans la vérification), et lesquels ne sont pas inclus dans l'examen et qu'il incombe aux clients du MSP d’inclure dans leur audit. Inclure des informations concernant les adresses IP du MSP faisant l’objet d’un balayage dans le cadre des balayages de vulnérabilité trimestriels du MSP et indiquer les adresses Internet qu'il incombe aux clients du MSP d'inclure dans leurs propres balayages trimestriels

4. Résultats des balayages trimestriels

• Résumer les résultats des quatre balayages trimestriels les plus récents dans les commentaires à l’Exigence 11.2 • Le balayage doit couvrir toutes les adresses IP accessibles depuis l’extérieur (interface Internet) existantes de l’entité

5. Conclusions et observations

• Tous les évaluateurs doivent utiliser le modèle suivant pour présenter des descriptions et conclusions détaillées dans le cadre du rapport, concernant chaque exigence ou partie d’une exigence

• Le cas échéant, consigner par écrit tous contrôles correctifs envisagés pour conclure qu'un contrôle est en place • Pour une définition des « contrôles correctifs », voir le document Glossaire, abréviations et acronymes des Normes PCI

DSS.


Revalidation d’éléments ouverts Un rapport relatif aux « contrôles en place » est nécessaire pour vérifier la conformité. Si le rapport initial du vérificateur/de l'évaluateur comporte des « éléments ouverts », le commerçant/prestataire de service doit prendre en compte ces éléments avant que la validation ne soit achevée. L’évaluateur/le vérificateur procédera alors à une nouvelle évaluation pour valider les mesures correctives mises en œuvre et certifier que toutes les exigences sont satisfaites. Après revalidation, l’évaluateur établira un nouveau Rapport sur la conformité, vérifiant que le système est pleinement conforme et le soumettra conformément aux instructions (voir ci-dessus).

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.

EXIGENCES DES NORMES PCI DSS PROCÉDURES DE TEST EN PLACE PAS EN PLACE

DATE CIBLE/ COMMENTAIRES

1.1 Mise en place de normes de configuration de pare-feu incluant les aspects suivants :

1.1 Obtenir et inspecter les normes de configuration de pare-feu et autres documents spécifiés ci-après afin de vérifier que les normes sont complètes. Répondre à chacun des points de cette section.

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 pare-feu ;

1.1.1 Vérifier que les normes de configuration de pare-feu comportent un processus formel pour toutes les modifications de pare-feu, y compris des tests et l'approbation, par la direction, de toutes modifications apportées à la configuration des connexions externes et du logiciel pare-feu.




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.2.a S'assurer qu'il existe un diagramme de réseau à jour et vérifier qu'il prend bien en compte toutes les connexions à des données de titulaire de carte, y compris tous réseaux sans fil.

1.1.2.b. Vérifier que le diagramme est bien tenu à jour.

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.3 Vérifier que les normes de configuration de pare-feu comportent l'exigence d'un pare-feu pour chaque connexion Internet, ainsi qu'entre tout DMZ et l'Intranet. Vérifier que le diagramme de réseau actuel est cohérent avec les normes de configuration de pare-feu.

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.4 Vérifier que les normes de configuration de pare-feu incluent une description de groupes, rôles et responsabilités pour la gestion logique de composants de réseau.

1.1.5 une liste écrite des services et ports nécessaires à l’activité ;

1.1.5 Vérifier que les normes de configuration de pare-feu incluent une liste documentée des services/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.6 Vérifier que les normes de configuration de pare-feu incluent une justification et une documentation pour tous protocoles disponibles, en plus des protocoles HTTP, SSL et SSH, ainsi que de 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.7.a Vérifier que les normes de configuration de pare-feu incluent 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 motifs de l’utilisation du protocole et les mesures de sécurité mises en œuvre.

1.1.7.b Examiner la documentation et les paramètres pour chaque service utilisé afin de recueillir la preuve du fait que le service est nécessaire et sécurisé.

1.1.8 un examen trimestriel des ensembles de règles applicables aux

1.1.8.a Vérifier que les normes de configuration de pare-feu prévoient un examen trimestriel des ensembles de




pare-feux et aux routeurs ; règles applicables aux pare-feux et routeurs.

1.1.8.b Vérifier que les ensembles de règles sont révisés trimestriellement.

1.1.9 Normes de configuration pour les routeurs

1.1.9 Vérifier qu’il existe des normes de configuration à la fois pour les pare-feux et 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.2 Sélectionner un échantillon de pare-feux/routeurs 1) entre l’Internet et la zone d’accueil et 2) entre la zone d’accueil et le réseau interne. L’échantillon doit englober le routeur-goulet (choke router) sur Internet, le routeur et le pare-feu de zone d’accueil, le segment titulaire de carte de zone d'accueil, le routeur de périmètre et le segment réseau de titulaire de carte interne. Examiner les configurations des pare-feux et routeurs pour vérifier que le trafic entrant et sortant soit limité uniquement aux 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 inclure :

1.3 Examiner les configurations de pare-feu/routeur pour vérifier que les connexions restreintes entre les serveurs accessibles publiquement et les composants stockant des données de titulaire de carte, comme suit :

1.3.1 la restriction du trafic Internet entrant vers des adresses Internet dans la zone d'accueil (filtres d'entrée) ;

1.3.1 Vérifier que le trafic Internet entrant est limité à des adresses IP dans la zone d’accueil.

1.3.2 ne pas laisser les adresses internes passer de l’Internet à la zone d’accueil ;

1.3.2 Vérifier que les adresses internes ne peuvent passer de l’Internet à la zone d’accueil.

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

1.3.3 Vérifier que le pare-feu procède à une inspection dynamique (filtre dynamique à paquets). [Seules des connexions établies doivent être autorisées, et uniquement si elles sont associées à une session préalablement établie (exécuter NMAP sur tous les ports TCP, avec un ensemble




autorisées dans le réseau) ; de bits « syn reset » ou « syn ack ») ; une réponse signifie que des paquets sont autorisés, même s'ils ne font pas partie d'une session établie antérieurement)].

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.4 Vérifier que la base de données se trouve 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.5 Vérifier que le trafic entrant et le trafic sortant sont limités au nécessaire pour l’environnement du titulaire de carte et que les restrictions sont dûment consignées par écrit.

1.3.6 la sécurisation et la synchronisation de fichiers de configuration de routeur. Ainsi, 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.6 Vérifier que les fichiers de configuration de routeur sont sécurisés et synchronisés [par exemple, que les fichiers de configuration d’exécution (utilisés pour le fonctionnement normal des routeurs) et des fichiers de configuration de démarrage (utilisés lorsque les machines sont réinitialisées), ont bien des configurations identiques et sécurisées].

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.7 Vérifier que tout autre trafic entrant ou sortant non inclus dans les points 1.2 et 1.3 ci-dessus est spécifiquement exclu.

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.8 Vérifier que des pare-feux de périmètre sont installés entre tous réseaux sans fil et systèmes stockant des données de titulaire de carte, et que ces pare-feux interdisent ou contrôlent tout trafic (dans la mesure où celui-ci est nécessaire à des fins commerciales) depuis l’environnement sans fil vers des systèmes stockant des données de titulaire de carte.

1.3.9 l'installation d’un logiciel de pare-feu personnel sur un ordinateur portable ou un ordinateur appartenant à un employé disposant d'une

1.3.9 Vérifier que les appareils mobiles et/ou les ordinateurs appartenant à des employés équipés d’une connectivité directe à l’Internet (par exemple, les ordinateurs portables utilisés par des employés), et qui sont utilisés pour




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.

accéder au réseau de l’organisation sont équipés de logiciels pare-feu personnels installés et actifs, configurés par l’organisation sur la base de critères spécifiques et non modifiables par l’employé.

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 Pour établir que l’accès direct entre des composants de systèmes et de réseaux publics externes stockant des données de titulaire de carte est interdit, mettre en œuvre les mesures suivantes, spécifiquement pour la configuration de tout pare-feu/routeur situé entre la zone d’accueil et le réseau interne :

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.1 Examiner les configurations de pare-feu/routeur, et s’assurer qu’il n’existe aucune route directe pour le trafic Internet entrant ou 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.4.2 Examiner les configurations de pare-feu/routeur et vérifier que le trafic interne sortant provenant des applications de titulaire de carte peut uniquement accéder à des adresses IP situées dans la zone d'accueil.

1.5 Mettre en œuvre un déguisement d’adresse IP, 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).

1.5 Pour l’échantillon de composants de pare-feu/routeur ci-dessus, vérifier que toute traduction d’adresse de réseau (Network Address Translation, NAT), ou toute autre technologie utilisant l’espace d’adresse RFC 1918 est employée pour restreindre la diffusion d’adresses IP depuis le réseau interne vers l’Internet (déguisement d’adresse IP).


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 paramètres 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 Choisir un échantillon de composants du système, de serveurs critiques et de points d’accès sans fil et tenter de se connecter (avec l’aide d’un administrateur du système) à des dispositifs utilisant des comptes et mots de passe par défaut du fournisseur, afin de vérifier que les comptes et mots de passe par défaut ont bien été modifiés. (Pour identifier les comptes/mots de passe du fournisseur, consulter les manuels et sources du fournisseur disponibles sur Internet.)

2.1.1 Dans le cas des environnements sans fil, modifier les paramètres 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 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.1.1 Vérifier les éléments suivants concernant les paramètres par défaut pour les environnements sans fil :

• que les clés WEP par défaut ont été modifiées lors de l’installation, et sont changées chaque fois qu’une personne ayant connaissance des clés quitte la société ou change de fonction ;

• que le SSID a été modifié ; • que la diffusion de la SSID a été désactivée ; • que les chaînes communautaires SNMP aux

points d’accès ont été changées ; • que les mots de passe par défaut aux points

d’accès ont été changés ; • que la technologie WPA ou WPA2 est activée si le

système sans fil est compatible WPA ; • le cas échéant, d'autres paramètres par défaut du

fournisseur sans fil liés à la sécurité.




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.a Étudier les normes de configuration du système de l’organisation pour les composantes de réseau, les serveurs critiques et les points d’accès au réseau sans fil et vérifier que les normes de configuration du système sont compatibles avec des normes de renforcement de la sécurité acceptées par l’industrie, telles que définies, par exemple, par le SANS, le NIST et le CIS.

2.2.b Vérifier que les normes de configuration du système incluent chaque élément ci-après (aux 2.2.1 – 2.2.4).

2.2.c Vérifier que les normes de configuration de système s’appliquent lors de la configuration de nouveaux systèmes.

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.1 Pour un échantillon de composants du système, de serveurs critiques et de points d’accès sans fil, vérifier qu'une seule fonction primaire est mise en œuvre par serveur.

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.2 Pour un échantillon de composants de système, de serveurs critiques et de points d'accès sans fil, inspecter les services, démons et protocoles du système activés. Vérifier que des services ou protocoles inutiles ou non sécurisés ne sont pas activés, ou qu’ils sont justifiés et dûment consignés par écrit en liaison avec l’utilisation appropriée du service (par exemple, que le FTP n’est pas utilisé, ou qu’il est crypté par technologie SSH ou autre).

2.2.3 Configurer les paramètres de sécurité du système pour prévenir toute utilisation frauduleuse.

2.2.3.a Interroger les administrateurs de système et/ou les responsables de la sécurité pour vérifier qu’ils connaissent bien les configurations des paramètres de sécurité courants de leurs systèmes d’exploitation, serveurs de base de données, serveurs Internet et systèmes sans fil.

2.2.3.b Vérifier que les configurations des paramètres de sécurité courants sont inclus dans les normes de configuration du système.

2.2.3.c Pour un échantillon de composants de système, de serveurs critiques et de points d'accès sans fil, vérifier que les paramètres de sécurité communs sont réglés de




manière adéquate.

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.2.4 Pour un échantillon de composants de système, de serveurs critiques et de points d'accès sans fil, vérifier que toute fonctionnalité inutile (par exemple, les scripts, drivers, fonctionnalités, sous-systèmes, systèmes de fichiers, etc.) est supprimée. S’assurer que les fonctions activées sont dûment recensées et que seules des fonctionnalités consignées par écrit sont présentes sur les machines constituant l'échantillon.

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.3 Pour un échantillon de composants de système, de serveurs critiques et de points d'accès sans fil, vérifier que l’accès administratif non-console est crypté :

• en observant la connexion d’un administrateur à chaque système pour vérifier que la technologie SSH (ou toute autre méthode de cryptage) est activée avant que le mot de passe de l'administrateur ne soit requis ;

• en vérifiant les services et fichiers de paramètres sur les systèmes, pour établir que Telnet et d’autres commandes de connexion ne sont pas disponibles pour une utilisation interne ;

• en s'assurant que l'accès d'un administrateur à l'interface de gestion sans fil est crypté par SSL/TLS. De manière alternative, vérifier que les administrateurs ne peuvent se connecter à distance à l’interface de gestion sans fil (toute gestion d’environnements sans fil s’effectue uniquement à partir de la 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 DSS des fournisseurs d’hébergement ».

2.4 Mettre en œuvre les procédures de tests A.1.1 à A.1.4, telles que décrites en détail dans l’Annexe A, « Conditions d’application des normes PCI DSS pour les fournisseurs d’hébergement (avec procédures de test) » pour les audits PCI des Fournisseurs de services partagés, afin de vérifier que les Fournisseurs de services partagés protègent l'environnement et les données hébergées de leurs entités (commerçants et fournisseurs de service).



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 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 des données le non-stockage des données de carte de crédit à moins que cela ne soit absolument nécessaires, 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 réduit 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.1 Collecter et étudier les politiques et procédures de la société en matière de conservation et de destruction de données et mettre en œuvre les mesures suivantes :

• vérifier que les politiques et procédures incluent des obligations légales, réglementaires et commerciales en matière de conservation de données, y compris des exigences spécifiques relative à la conservation des données de titulaire de carte (par exemple, les données de titulaire de carte doivent être détenues durant une période X, pour des raisons commerciales Y) ;

• vérifier que les politiques et procédures incluent des dispositions relatives à l'élimination des données, lorsqu'il n'existe plus de raisons légales, réglementaires ou commerciales, y compris concernant les données de titulaire de carte ;

• vérifier que les politiques et procédures englobent tout stockage de données de titulaire de carte, y compris les serveurs de base de données, ordinateurs centraux, répertoires de transfert et répertoires de copies de données en vrac utilisés pour transférer des données entre serveurs, ainsi que les répertoires utilisés pour normaliser des données entre transferts de serveurs ;

• vérifier que les politiques et procédures prévoient




un processus programmatique (automatisé) destiné à supprimer, au moins sur une base trimestrielle, les données de titulaire de carte pour lesquels les délais de conservation par l'entreprise sont dépassés, ou à défaut une obligation de vérification, au moins trimestrielle, afin de vérifier que les données de titulaire de carte stockées n'excèdent pas les exigences applicables en matière de délais de conservation par l'entreprise.




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 Si des données d’authentification sensibles sont reçues et supprimées, obtenir et étudier les processus de suppression de données afin de vérifier que les données ne sont pas récupérables. Pour chaque élément de données d’authentification sensible ci-après, mettre en œuvre les mesures suivantes :

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.1 Pour un échantillon de composants de système, de serveurs critiques et de points d’accès sans fil, examiner les aspects suivants et vérifier que la totalité du contenu de toute piste d’une bande magnétique située au verso de la carte ne seront stockées en aucunes circonstances :

• données de transaction entrantes ; • registres de transaction ; • fichiers historiques ; • fichiers trace ; • registres de correction d’erreurs ; • plusieurs schémas de base de données ; • contenus de base de données.

3.2.2 Ne pas stocker de code de validation de carte, ni de valeur (à trois ou quatre chiffres, imprimés sur

3.2.2 Pour un échantillon de composants de système, de serveurs critiques et de points d’accès sans fil, examiner les aspects suivants et vérifier que le code de validation de




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, consulter le « Glossaire ».

carte à trois ou quatre chiffres figurant sur le recto de la carte ou la plage de signature (données CVV2, CVC2, CID, CAV2) n’est stocké en aucune circonstance :


3.2.3 Ne pas stocker le numéro d’identification personnel (personal identification number, PIN), ni le bloc PIN crypté.

3.2.3 Pour un échantillon de composants de système, de serveurs critiques et de points d’accès sans fil, examiner les aspects suivants et vérifier que les codes PIN et les blocs PIN cryptés ne sont stockés en aucune circonstance :


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.3 Obtenir et étudier les politiques écrites et examiner l’affichage en ligne des données de carte de crédit pour vérifier que les numéros de carte sont masqués lors de l’affichage des données de titulaire de carte, à l’exception des personnes ayant spécifiquement besoin de consulter les numéros de carte de crédit complets.




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 solides de hachage à sens unique (index hachés) ;

• une troncature ; • des Index tokens et Index

pads (les PAD 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 correctifs ».

3,4.a Obtenir et étudier des documents relatifs au système utilisé pour protéger les données stockées, y compris le fournisseur, le type du système/processus et les algorithmes de cryptage (le cas échéant). Vérifier que les données sont bien illisibles à l’aide de l’une ou l’autre des méthodes suivantes :

• des hachages à sens unique (index hachés), tels que le SHA-1 ;

• une troncature ou un masquage ; • des Index tokens et PAD, les PAD étant stockés de

manière sécurisée ; • une cryptographie performante, par exemple, triple-

DES 128 bits ou AES 256 bits, avec des processus et procédures de gestion de clés associés.

3,4.b Étudier plusieurs tableaux à partir d’un échantillon de serveur de bases de données pour vérifier que les données sont bien illisibles (c’est-à-dire, non stockées en texte seul)

3,4.c Examiner un échantillon de support amovible (par exemples, des bandes de sauvegarde) afin de s’assurer que les données de titulaire de carte sont bien illisibles.

3.4.d Examiner un échantillon de registres d’audit pour confirmer que les données de titulaire de carte sont assainies ou supprimées des registres.

3.4.e Vérifier que les données de titulaire de carte transmises par des réseaux sans fil sont bien illisibles, où qu’elles soient 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

3.4.1.a Si des données de cryptage de disque sont utilisées, vérifier qu’un accès logique à des systèmes de fichiers cryptés est mis en œuvre par le biais d'un mécanisme distinct du mécanisme du système d'exploitation natif (par exemple, n’utilisant pas de comptes locaux ou de répertoire actif).




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.4.1.b Vérifier que les clés de décryptage ne sont pas stockées sur le système local (par exemple, stocker les clés sur des disquettes, CD-ROM, etc., qui peuvent être sécurisés et récupérés uniquement en cas de besoin).

3.4.1.c Vérifier que les données de titulaire de carte sur support mobile sont cryptées où qu'elles soient stockées (le cryptage disque ne permet souvent pas de crypter les supports mobiles).

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 Vérifier les processus destinés à protéger les clés de cryptage utilisés pour crypter les données de titulaire de carte contre la divulgation et l’utilisation illicite en mettant en œuvre les mesures suivantes :

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.1 examiner les listes d’accès d’utilisateur afin de vérifier que l’accès aux clés cryptographiques est limité à quelques très rares dépositaires ;

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.5.2 examiner les fichiers de configuration système pour vérifier que les clés cryptographiques sont stockées sous format crypté, et que les clés de cryptage de clé sont bien stockées séparément des clés de cryptage de données.

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 de titulaire de carte, y compris les suivantes :

3,6.a Vérifier l’existence de procédure de gestion de clés pour les clés utilisées pour le cryptage de données de titulaire de carte.

3,6.b Pour les Prestataires de services uniquement : si le Prestataire de services partage des clés avec ses clients pour la transmission de données de titulaire de carte, vérifier qu’il met à la disposition de sa clientèle des documents comportant des recommandations relatives à la manière stocker et de modifier de manière sûre les clés de cryptage du client (utilisées pour transmettre des données entre le client et le prestataire de services).

3,6.c Examiner les procédures de gestion de clé et mettre en œuvre les mesures suivantes :

3.6.1 la génération de clés performantes ;

3.6.1 Vérifier que les procédures de gestion de clé nécessitent la génération de clés performantes

3.6.2 la distribution de clé sécurisée ;

3.6.2 Vérifier que les procédures de gestion de clés imposent une distribution de clés sécurisée




3.6.3 le stockage de clé sécurisé ; 3.6.3 Vérifier que les procédures de gestion de clés imposent un stockage de clés sécurisé

3.6.4 Changements de clés périodiques

• 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.4 Vérifier que les procédures de gestion de clés imposent des changements de clés périodiques. Vérifier que les procédures de changement sont mises en œuvre au moins annuellement.

3.6.5 Destruction des anciennes clés.

3.6.5 Vérifier que les procédures de gestion de clé nécessitent la 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.6 Vérifier que les procédures de gestion de clé prévoient la répartition des informations et mettre en place 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 totalité de celle-ci).

3.6.7 Prévention des substitutions de clés non autorisées.

3.6.7 Vérifier que les procédures de gestion de clé prévoient la prévention des remplacements de clés non autorisés.

3.6.8 Le remplacement des clés compromises ou suspectées de l’être

3.6.8 Vérifier que les procédures de gestion de clé prévoient le remplacement des clés compromises ou suspectées de l’être.

3.6.9 L'annulation des clés anciennes ou invalides

3.6.9 Vérifier que les procédures de gestion de clés prévoient la révocation des clés anciennes ou invalides (principalement pour les clés RSA)

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.

3.6.10 Vérifier que les principales procédures de gestion de clés imposent aux dépositaires de clés de signer un formulaire stipulant qu’ils comprennent et acceptent les responsabilités liées à la fonction de dépositaire de clés.



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.



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.a Vérifier que l’utilisation du cryptage (par exemple, SSL/TLS ou IPSEC) lorsque des données de titulaire de carte sont transmises ou reçues sur des réseaux publics ouverts.

• Vérifier qu'un cryptage performant est utilisé pour la transmission des données.

• En ce qui concerne les protocoles SSL, vérifier que HTTPS apparaît comme un élément de l’adresse URL (Universal Record Locator) du navigateur et qu’aucune donnée de titulaire de carte n’est requise lorsque HTTPS n’apparaît pas dans l’adresse URL.

• Sélectionner un échantillon de transactions lorsqu’elles sont reçues et observer les transactions lorsqu’elles interviennent, pour vérifier que les données de titulaire de carte sont cryptées en cours de transit

• Vérifier que seuls des clés/certificats SSL/TLS de confiance sont acceptés.

• Vérifier que la puissance de cryptage adéquate est mise en œuvre au regard de la méthodologie de cryptage utilisée (vérifier les recommandations/meilleures pratiques du fournisseur).




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.1.1.a En ce qui concerne les réseaux sans fil transmettant des données de titulaire de carte, ou liées à des environnements de titulaire de carte, vérifier que des méthodologies de cryptage appropriées sont utilisées pour toutes les transmissions sans fil, notamment les : accès Wi-Fi protégé (WPA ou WPA2), IPSEC VPN ou SSL/TLS.

4.1.1.b En cas d’utilisation de technologie WEP, vérifier : • qu'elle est utilisée avec une clé de cryptage

d’au moins 104 bits et une valeur d’initialisation de 24 bits ;

• qu'elle est utilisée uniquement en liaison avec la technologie d’accès WiFi protégé (WPA ou WPA2), VPN ou SSL/TLS ;

• que les clés WEP partagées soient permutées au moins trimestriellement (ou automatiquement si la technologie le permet) ;

• que les clés WEP partagées soient permutées en cas de changement des personnels disposant d’un accès aux clés ;

• que l’accès est limité sur la base d’une adresse MAC.

4.2 Ne jamais envoyer de PAN non cryptés par courrier électronique.

4.2.a Vérifier qu’une solution de cryptage de courrier électronique est utilisée lorsque des données de titulaire de carte sont envoyées par e-mail.

4.2.b Vérifier l’existence d’une politique précisant que les PAN non cryptés ne sont pas envoyés par e-mail.




4,2.c Interroger de 3 à 5 employés pour vérifier qu’un logiciel de cryptage d’e-mail est exigé pour les e-mails contenant des PAN.


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 etles ordinateurs centraux ne figurent pas au nombre des systèmes couramment affectés par les virus.

5.1 Pour un échantillon de composants de système, de serveurs critiques et de points d'accès sans fil, vérifier qu’un logiciel antivirus est bien installé.

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.1.1 Pour un échantillon de composants de système, de serveurs critiques et de points d'accès sans fil, vérifier que des programmes antivirus détectent les logiciels nuisibles, y compris les logiciels espions (« spyware ») et publicitaires, les éliminent et protègent le système 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.

5.2 Vérifier que le logiciel antivirus est à jour, qu’il fonctionne activement et qu’il est capable de générer des registres

• Recueillir la politique, l’étudier et vérifier qu’il contient des impératifs applicables à la mise à jour d’un logiciel antivirus et de définition de virus.

• Vérifier que l’installation principale du logiciel permet des mises à jour automatiques et des scannages périodiques, et que ces fonctionnalités sont activées pour un échantillon de composants du système, de serveurs critiques et de serveurs de point d'accès sans fil.

• Vérifier que la génération de registres est activée et que les registres sont tenus conformément à la politique de la société en matière de conservation de documents.

6ème exigence : développer et gérer des applications et ses 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é mises à disposition par le fournisseur. Tous les systèmes doivent être équipés des corrections d’erreur de logiciel appropriées les plus récentes, 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ées pour déterminer qu'ils n’entrent pas en conflit avec les configurations de sécurité en place. En ce qui concerne 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 de système 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.1.a Pour un échantillon de composants du système, de serveurs critiques et de points d’accès sans fil, ainsi que des logiciels liés, comparer la liste des correctifs de sécurité installés sur chaque système à la plus récente liste des correctifs de sécurité du fournisseur, afin de vérifier que les correctifs existants du fournisseur sont bien installés.

6.1.b Étudier les politiques liées à l’installation de correctifs de sécurité, afin de vérifier qu’ils exigent l’installation de tous nouveaux correctifs d’erreurs pertinents dans le domaine de la sécurité dans un délai de 30 jours.




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 gratuit disponibles sur l'Internet). Mettre les normes à jour afin de faire face aux nouveaux problèmes de vulnérabilité.

6.2.a Interroger des personnels responsables afin de vérifier que des processus sont mis en œuvre dans le but de repérer toutes nouvelles vulnérabilités en matière de sécurité.

6.2.b Vérifier que les processus d’identification de nouvelles vulnérabilités en matière de sécurité incluent l’utilisation de sources externes d’informations relatives aux vulnérabilités dans le domaine de la sécurité, ainsi que pour la mise à jour des normes de configuration examinées dans la 2ème Exigence, alors que de nouveaux problèmes de vulnérabilité sont découverts.

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 Obtenir et étudier les processus écrits de développement de logiciel, afin de vérifier qu’ils sont basés sur des normes sectorielles et que la sécurité est prise en compte tout au long du cycle de vie du produit. À partir d’un examen des processus écrits de développement de logiciel, des entretiens avec des développeurs de logiciel, ainsi que de l'étude de données pertinentes (documents afférents à la configuration de réseau, données de production et de test, etc.), vérifier ce qui suit :

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.1 que toutes modifications (y compris toutes corrections d’erreur) sont testées avant d’être déployées au niveau de la production ;




6.3.2 Séparer les environnements de développement, de test et de production.

6.3.2 que les environnements de test/développement sont distincts de l’environnement de production, et qu’il existe un contrôle d’accès en place pour garantir la séparation ;

6.3.3 Séparation des obligations entre les environnements de développement, de test et de production.

6.3.3 qu'il existe une séparation entre les missions des collaborateurs affectés aux environnements de développement/test et celles des personnels affectés à l'environnement 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.4 que les données de production (PAN actifs) ne sont pas utilisées aux fins de test ou de développement, ou sont expurgées avant usage ;

6.3.5 Suppression des données et comptes de tests avant que les systèmes de production ne deviennent actifs.

6.3.5 que les données de test et les comptes sont supprimés avant que le système de production ne devienne actif ;

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.6 que les comptes d’application personnalisés, noms d’utilisateur et/ou mots de passe sont supprimés avant que le système soit mis en production ou mis à la disposition des 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.3.7.a Obtenir et étudier toutes politiques, écrites ou autres, pour confirmer que des examens du code sont exigés et doivent être exécutés par des personnes autres que l’auteur alors à l’origine du code

6.3.7.b Vérifier que des examens du code sont réalisés, en liaison avec un nouveau code et après des modifications du code Remarque : Cette exigence s’applique aux examens de code pour le développement de logiciels personnalisés, dans le cadre du cycle de vie de développement de système (System Development Life Cycle, SDLC) ; ces analyses peuvent être réalisées par des personnels internes. Un code sur mesure pour les applications d’interface Internet sera soumis à des contrôles supplémentaires au 30 juin 2008 – pour de plus amples détails, voir l’exigence 6.6 des normes PCI DSS.




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.a Obtenir et examiner les procédures de contrôle du changement de la société liées à la mise en œuvre des correctifs de sécurité et des modifications de logiciel et vérifier que les procédures incluent les points 6.4.1 – 6.4.4 ci-après

6,4.b Pour un échantillon de composants du système, de serveurs critiques et de points d’accès sans fil, examiner les trois changements les plus récents/correctifs de sécurité pour chaque composant du système et retracer ces modifications jusqu’aux documents liés dans le domaine du contrôle des changements. Vérifier que, pour chaque changement examiné, les éléments ci-après ont été consignés par écrit, conformément aux procédures de contrôle du changement :

6.4.1 consignation écrite de l’impact ;

6.4.1 Vérifier que la consignation écrite de l’impact sur le client figure dans les documents de contrôle des changements pour chacune des modifications de l’échantillon.

6.4.2 approbation par signature de la direction par les parties appropriées ;

6.4.2 Vérifier que l’approbation par la direction, par des parties appropriées, est présente pour chacune des modifications de l’échantillon.

6.4.3 vérification de la fonctionnalité opérationnelle ;

6.4.3 Vérifier que des tests de fonctionnalité opérationnelle ont été réalisés pour chacune des modifications de l’échantillon.

6.4.4 procédures de sauvegarde. 6.4.4 Vérifier que des procédures de sauvegarde sont prêtes pour chacune des modifications de l’échantillon.

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.a Obtenir et étudier des processus de développement de logiciel pour toutes applications basées sur Internet. Vérifier que les processus prévoient une formation aux techniques de codage sécurisé pour les développeurs et qu’ils sont fondés sur des recommandations telles que les Principes directeurs de l’OWASP (http://www.owasp.org).

6.5.b En ce qui concerne les applications basées sur Internet, vérifier que des processus sont en place afin de confirmer que les applications Internet ne sont pas exposées aux risques suivants :




6.5.1 les entrées non validées ; 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.2 l'utilisation malveillante d'identités d'utilisateurs ;

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.3 l'utilisation malveillante des éléments d’authentification de compte et cookies de session ;

6.5.4 les attaques par Cross-Site Scripting (XSS ou CSS) ;

6.5.4 les attaques par Cross-Site Scripting ;

6.5.5 les attaques par débordement de tampon ;

6.5.5 les attaques par débordement de tampon imputables à des entrées non validées et à d’autres causes ;

6.5.6 les attaques par injection (par exemple, une injection de commandes SQL (Structured Query Language)) ;

6.5.6 les injections de commandes SQL et autres attaques par injection de commandes ;

6.5.7 une gestion d’erreur inadéquate ;

6.5.7 la gestion d’erreurs inadéquate ;

6.5.8 un stockage non sécurisé ; 6.5.8 un stockage non sécurisé ;

6.5.9 un refus de service ; 6.5.9 un refus de service ;

6.5.10 une gestion de configuration non sécurisée.

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

6.6 En ce qui concerne les applications basées sur Internet, s’assurer que l’une ou l’autre des méthodes ci-après est en place :

• vérifier que le code application sur mesure est révisé périodiquement par une organisation spécialisée dans la sécurité des applications ; que toutes les vulnérabilités en matière de codage ont été corrigées ; et que l’application a fait l’objet d’une nouvelle application après la mise en œuvre des corrections ;

• vérifier qu’il existe un pare-feu de couche application avant les applications d’interface Internet, afin de détecter et de prévenir les attaques basées sur




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.

Internet.


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.

EXIGENCES DES NORMES PCI DSS PROCÉDURES DE TEST EN

PLACE PAS EN PLACE

DATE CIBLE/ COMMENTAIRE

S 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.1 Obtenir et étudier les politiques écrites en matière de contrôle des données, et vérifier que la politique inclut bien les éléments suivants :

• que les droits d’accès à des identités d’utilisateurs privilégiés sont limités aux privilèges les plus limités possibles, nécessaires à l'exercice de ses responsabilités professionnelles ;

• que l’attribution de privilèges soit basée sur la base de la classification du poste et des fonctions des collaborateurs individuels ;

• l’exigence d’un formulaire d’autorisation signé de la direction spécifiant les privilèges requis ;

• la mise en œuvre d’un système de contrôle d’accès automatisé.

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.

7.2 Examiner les paramètres du système et les documents du fournisseur afin de vérifier qu’un système de contrôle d’accès est mis en œuvre et inclut les aspects suivants :

• la couverture de l’ensemble des composants de système ; • l'attribution de privilèges aux individus sur la base de la

classification de leur poste et de leurs fonctions ; • un réglage par défaut « Interdire tous » (certains systèmes de

contrôle d’accès sont réglés par défaut sur « Autoriser tous », permettant ainsi l’accès de tous à moins qu’une règle n’ait été écrite pour édicter une interdiction, ou tant que tel n’est pas le cas)


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é.


PLACE PAS EN PLACE


S 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.1 Pour un échantillon d’identités d’utilisateur, étudier les listes d’identité d’utilisateurs et vérifier que tous les utilisateurs disposent d’un nom d’utilisateur unique pour accéder aux composants ou à des données de titulaire 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.2 Pour vérifier que les utilisateurs sont authentifiés à l’aide d’une identité d’utilisateur unique, ainsi que d’éléments d’authentification supplémentaires (par exemple, un mot de passe), lors de l’accès à l’environnement de titulaire de carte, effectuer les démarches suivantes :

• collecter et étudier des documents décrivant la ou les modes d’authentification utilisés ;

• pour chaque type de mode d’authentification utilisé, de même que pour chaque type de composant du système, observer le déroulement d'une procédure d'authentification afin de s'assurer que l’authentification se déroule bien conformément à la ou aux modes d’authentification décrits par écrit.

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

8.3 Pour vérifier qu’une authentification à deux facteurs est mise en œuvre pour tous les accès distants au réseau, observer un employé (par exemple, un administrateur) se connecter à distance au réseau et vérifier qu’un mot de passe et un élément d'authentification supplémentaire (carte à puce, jeton PIN) sont effectivement requis.



PLACE PAS EN PLACE


S 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 tous les composants du système.

8,4.a Pour un échantillon de composants du système, de serveurs critiques et de points d’accès sans fil, examiner les fichiers mots de passe afin de vérifier que ces derniers sont illisibles.

8,4.b Pour les Prestataires de services uniquement, vérifier les fichiers de mot de passe pour s’assurer que les mots de passe du client sont cryptés.



PLACE PAS EN PLACE


S 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 Étudier les procédures et interroger des collaborateurs pour s'assurer que les procédures d'authentification d'utilisateur et de gestion de mot de passe sont appliquées, par la mise en œuvre des mesures ci-après :

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.1.a Sélectionner un échantillon d’identités d’utilisateurs, y compris d’administrateurs et d’utilisateurs généraux. S’assurer que chaque utilisateur est en droit d’utiliser le système conformément à la politique de la société, en mettant en œuvre les mesures suivantes :

• obtenir et examiner un formulaire d’autorisation pour chaque identité d’utilisateur ;

• vérifier que les identités d’utilisateur incluses dans l'échantillon sont utilisées conformément au formulaire d’autorisation (y compris tous privilèges spécifiés et toutes signatures obtenues) en retraçant l'origine des informations depuis le formulaire d'autorisation jusqu'au système.

8.5.1.b vérifier que seuls des administrateurs ont accès aux consoles de gestion des réseaux sans fil.

8.5.2 vérifier l’identité de l’utilisateur avant de procéder à une réinitialisation de mot de passe ;

8.5.2 Étudier les procédures de mot de passe et observer les personnels en charge de la sécurité pour vérifier que, si un utilisateur demande la réinitialisation d’un mot de passe par téléphone, par courrier électronique, Internet ou autre méthode autre qu’en « face à face », l’identité de l’utilisateur est contrôlée avant la réinitialisation du 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.3 Examiner les procédures en matière de mot de passe et observer les personnels de sécurité, pour vérifier que les mots de passe initiaux pour les nouveaux utilisateurs ont une valeur unique pour chaque utilisateur et sont modifiés après une première utilisation.

8.5.4 mettre fin immédiatement à l’accès des utilisateurs ayant

8.5.4 Sélectionner un échantillon d’employés licenciés au cours des six mois précédents et étudier les listes d’accès d’utilisateurs



PLACE PAS EN PLACE


S cessé d’être employés par l’entreprise ;

courants, afin de vérifier que leurs identités d’utilisateur ont été désactivées ou supprimées.

8.5.5 supprimer les comptes d’utilisateur inactifs au moins tous les 90 jours ;

8.5.5 Pour un échantillon d’identités d’utilisateur, vérifier qu’il n’existe pas de comptes inactifs de plus de 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.6 Vérifier que tous comptes utilisés par des fournisseurs dans le but de supporter et de maintenir des composants de systèmes sont inactifs, activés uniquement lorsque le fournisseur en a besoin et surveillés lors de leur utilisation

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.7 Interroger les utilisateurs à partir d’un échantillon d’identités d’utilisateur, afin de vérifier qu’ils sont familiarisés avec les procédures et les politiques en matière de mot de passe.

8.5.8 ne pas utiliser de comptes et mots de passe collectifs, partagés ou génériques ;

8.5.8.a Pour un échantillon de composants du système, de serveurs critiques et de points d’accès sans fil, examiner les listes d’identités d’utilisateur afin de vérifier les points suivants : • que les identités d’utilisateur et les comptes génériques sont

désactivés ou supprimés ; • qu’il n’existe pas identités d’utilisateur partagées pour les

activités d’administration du système et les autres fonctions critiques ;

• qu'aucune identité d’utilisateur partagée ou générique n’est utilisée pour administrer des réseaux locaux d’entreprise et dispositifs sans fil.

8.5.8.b Examiner les politiques/procédures en matière de mot de passe, afin de vérifier que les mots de passe collectifs et partagés sont explicitement interdits.

8.5.8.c Interroger les administrateurs du système pour vérifier qu’aucun mot de passe collectif ou partagé n’est distribué, même sur demande.

8.5.9 changer les mots de passe d’utilisateur au moins tous les 90 jours ;

8.5.9 Pour un échantillon de composants du système, de serveurs critiques et de points d’accès sans fil, obtenir et inspecter les paramètres de configuration du système, afin de vérifier que des



PLACE PAS EN PLACE


S paramètres de mot de passe d’utilisateur sont définis pour mettre les utilisateurs en demeure de modifier leur mot de passe au moins tous les 90 jours. Dans le cas des seuls Prestataires de service, examiner les processus internes et les documents du client/d’utilisateur afin de vérifier que les mots de passe des clients doivent être changés périodiquement et que les clients reçoivent des instructions quant aux moments où, et aux circonstances dans lesquelles les mots de passe doivent être modifiés.

8.5.10 exiger que les mots de passe comptent au moins sept caractères ;

8.5.10 Pour un échantillon de composants du système, de serveurs critiques et de points d’accès sans fil, obtenir et inspecter les paramètres de configuration du système, afin de vérifier que des paramètres de mot de passe d’utilisateur sont définis pour que les mots de passe comportent au moins sept caractères. Dans le cas des seuls Prestataires de service, examiner les processus internes et les documents du client/d’utilisateur afin de vérifier qu’il existe une obligation que les mots de passe des clients comportent 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.11 Pour un échantillon de composants du système, de serveurs critiques et de points d’accès sans fil, obtenir et inspecter les paramètres de configuration du système, afin de vérifier que des paramètres de mot de passe d’utilisateur sont définis pour que les mots de passe comportent à la fois des caractères numériques et alphabétiques. Dans le cas des seuls Prestataires de service, examiner les processus internes et les documents du client/d’utilisateur afin de vérifier qu’il existe une obligation que les mots de passe des clients comportent à la fois des caractères 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.12 Pour un échantillon de composants du système, de serveurs critiques et de points d’accès sans fil, obtenir et inspecter les paramètres de configuration du système, afin de vérifier que des paramètres de mot de passe d’utilisateur sont définis pour qu’un nouveau mot de passe ne puisse être le même que les quatre choisis antérieurement. Dans le cas des seuls Prestataires de service, examiner les processus internes et les documents du client/d’utilisateur afin de vérifier qu'un nouveau mot de passe d'un client ne puisse être le



PLACE PAS EN PLACE


S même que les quatre précédents.

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.13 Pour un échantillon de composants de système, de serveurs critiques et de point d’accès sans fil, obtenir et inspecter les paramètres de configuration du système, pour vérifier que des paramètres de mot de passe prévoient qu'un compte d'utilisateur doit être verrouillé après, au plus, six tentatives de connexion infructueuses. Dans le cas des seuls Prestataires de service, examiner les processus internes et les documents du client/d’utilisateur afin de vérifier que les comptes de client sont verrouillés temporairement après, au plus, six tentatives de connexion infructueuses.

8.5.14 fixer la période de verrouillage à trente minutes, ou jusqu'à ce qu'un administrateur active l'identité d'utilisateur ;

8.5.14 Pour un échantillon de composants de système, de serveurs critiques et de point d’accès sans fil, obtenir et inspecter les paramètres de configuration du système, pour vérifier que des paramètres de mot de passe prévoient que lorsque un compte d'utilisateur est verrouillé, il le reste durant trente minutes ou jusqu'à ce qu'un administrateur du système réinitialise le compte.

8.5.15 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 ;

8.5.15 Pour un échantillon de composants de système, de serveurs critiques et de point d’accès sans fil, obtenir et inspecter les paramètres de configuration du système, pour vérifier que des paramètres de mot de passe prévoient que la période d’inactivité du système/de la session a été fixée à 15 minutes au plus.

8.5.16 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.

8.5.16.a Examiner les paramètres de configuration de base de données pour un échantillon de base de données, afin de vérifier que l’accès est authentifié, y compris pour les utilisateurs, applications et administrateurs individuels.

8.5.16.b Examiner les paramètres de configuration de base de données et les comptes de base de données, pour vérifier que les requêtes SQL à la base de données sont interdites (il ne devrait y avoir qu’un nombre très limité de comptes individuels de connexion de base de données. Les requêtes SQL directes doivent être limitées aux administrateurs de base de données.)


9ème exigence : limiter l’accès physique aux données des titulaires de carte.

Tout accès physique à des données ou système 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.


PLACE PAS EN PLACE

DATE CIBLE/ COMMENTAIR

ES 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.

9.1 Vérifier l’existence de contrôles de sécurité physique pour chaque salle informatique, centre de données ou autre espace physique équipé de systèmes contenant des données de titulaire de carte.

• Vérifier que l’accès est contrôlé par des lecteurs de badge et d’autres équipements, y compris des badges autorisés, des verrous et des clés

• Observer une tentative d’administrateur de système pour se connecter à des consoles pour trois systèmes sélectionnés de manière aléatoire dans l'environnement de titulaire de carte et vérifier qu'ils sont « verrouillés » de manière à empêcher toute utilisation non autorisée.

9.1.1 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 trois mois.

9.1.1 Vérifier que des caméras vidéo surveillent les points d’entrée/de sortie des centres de données dans lesquels des données de titulaire de carte sont stockées ou présentes. Les caméras vidéo doivent être placées à l’intérieur du centre de données ou être protégées d'une quelconque autre manière contre les détériorations physiques ou la neutralisation. Vérifier que les caméras sont surveillées et que les données collectées par elles sont stockées durant au moins trois mois.

9.1.2 Limiter l’accès physique aux prises du réseau accessibles publiquement.

9.1.2 Vérifier, en interrogeant des administrateurs de réseau, ainsi que par l’observation, que les prises de réseau ne sont activées que lorsque des employés dûment autorisés à cet effet en ont besoin. Les salles de conférence destinées à accueillir des visiteurs ne doivent par exemple pas être équipées de ports réseau activés par protocole DHCP. Alternativement, vérifier que les visiteurs sont accompagnés à tout moment lorsqu'ils se trouvent dans des zones équipées de prises de réseau actives.

9.1.3 Limiter l’accès physique aux points d’accès sans fil,

9.1.3 Vérifier que l’accès physique aux points d’accès sans fil, portails et dispositifs portables est limité de manière appropriée.



PLACE PAS EN PLACE


ES portails et périphériques portables.

9.2 Développer des procédures destiner à 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,2.a Examiner les processus et les procédures d’attribution de badges à des employés, entrepreneurs et visiteurs et vérifier que ces processus incluent les éléments ci-après :

• des procédures existantes en matière d’attribution de nouveaux badges, de modification des critères d’accès et de retrait des badges des employés cessant de travailler pour l'entreprise, ou des badges visiteur expirés ;

• un accès limité au système de badges.

9,2.b Observer les individus dans les locaux afin de vérifier qu’il est facile de distinguer les employés des visiteurs.

9.3 Faire en sorte que tous les visiteurs soient gérés comme suit :

9.3 Vérifier que des contrôles des employés/visiteurs sont en place comme suit :

9.3.1 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 ;

9.3.1 Observer des visiteurs, pour contrôler l’utilisation par eux des badges d’identité. Tenter d’accéder au centre de données afin de vérifier que le badge d'identification d'un visiteur n'autorise pas l'accès non accompagné à des espaces dans lesquels sont stockées des données de titulaire de carte.

9.3.2 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

9.3.2 Examiner les badges d’employés et de visiteurs pour vérifier que les badges d’identification distinguent clairement les employés des visiteurs/personnes extérieures et que les badges de visiteur expirent.



PLACE PAS EN PLACE


ES l'entreprise ; 9.3.3 qu'il leur soit demandé de restituer leur « laisser-passer » avant de quitter les installations ou à la date d’expiration.

9.3.3 Observer les visiteurs quittant les installations afin de vérifier s’il leur est demandé de restituer leur badge d’identité à leur départ ou lorsqu’ils arrivent à 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,4.a Vérifier que le registre afférent à un visiteur est utilisé pour enregistrer l’accès physique aux installations, ainsi qu’aux salles informatiques et aux centres de données lorsque des données de titulaire de carte sont stockées ou transmises.

9,4.b Vérifier que le registre contient le nom du visiteur, la société représentée et l’employé autorisant l’accès physique et qu’il est conservé 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.5 Vérifier que le site de stockage pour les sauvegardes de support est sécurisé. S’assurer que le lieu de stockage hors site fait l'objet de contrôles périodiques afin de s’assurer que le stockage des sauvegardes de support est bien sécurisé physiquement et protégé contre les risques d'incendie.

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.6 Vérifier que les procédures de protection des données de titulaire de carte incluent des contrôles pour la sécurisation physique de supports papier et électroniques dans des salles informatiques et des centres de données (y compris des reçus papier, rapports sur support papier, télécopies, CD et disques sur les bureaux des employés et les espaces de travail ouverts, ainsi que les disques durs des PC).

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 les éléments suivant :

9.7 Vérifier qu’il existe une politique de contrôle de la distribution de supports contenant des données de titulaire de carte et que la politique prend en compte l’ensemble des supports distribués, y compris ceux mis à la disposition de personnes.

9.7.1 classifier le support pour qu’il puisse être identifié comme confidentiel ;

9.7.1 S’assurer que tous les supports sont classifiés, afin qu'ils puissent être identifiés comme « confidentiels ».



PLACE PAS EN PLACE


ES 9.7.2 envoyer le support par service de coursier sécurisé, ou par tout autre mode de livraison permettant un suivi exact.

9.7.2 Vérifier que tous supports envoyés hors de l’installation sont connectés et autorisés par la direction, puis transmis par service de coursier sécurisé ou tout autre mode de livraison permettant un suivi.

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.8 Sélectionner un échantillon récent de plusieurs jours de registres de suivi de support hors site et vérifier la présence, dans les registres de détails de suivi et d'autorisations adéquates de la direction.

9.9 Maintenir un contrôle strict sur le stockage et l'accessibilité des médias contenant des données de titulaire de carte.

9.9 Obtenir et étudier la politique en matière de contrôle de stockage et de conservation de supports papier et électronique et s’assurer que cette politique prévoit des inventaires périodiques de support.

9.9.1 Inventorier strictement tous les supports et s’assurer qu’ils sont stockés en sécurité.

9.9.1.a Obtenir et examiner le registre d'inventaire des supports, afin de vérifier que des inventaires périodiques de supports sont réalisés. 9.9.1.b Examiner les processus afin de vérifier que les supports sont stockés en sécurité

9.10 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 :

9.10 Obtenir et examiner la politique de destruction périodique de supports et vérifier qu'elle englobe tous supports contenant des données de titulaire de carte et confirmer ce qui suit :

9.10.1 déchiqueter, incinérer ou réduire en pulpe les documents ;

9.10.1.a Vérifier que les documents sous forme de support papier sont déchiquetés ou réduits en pulpe, conformément aux normes ISO 9564-1 ou ISO 11568-3e.

9.10.1.b Examiner les conteneurs de stockage utilisés pour les informations à détruire, afin de s’assurer que les conteneurs sont sécurisés. Par exemple, vérifier qu’un conteneur de « documents à déchiqueter », possède bien une serrure interdisant l’accès à ses contenus.

9.10.2 Éliminer, démagnétiser, déchiqueter ou détruire de toute autre manière tout support électronique, de manière à ce

9.10.2 Vérifier que les supports électroniques sont détruits et que les données qu’ils contenaient ne peuvent être récupérées ; en utilisant un programme d’effacement militaire pour supprimer des fichiers, ou autrement pour démagnétiser ou détruire matériellement les



PLACE PAS EN PLACE


ES que les données de titulaire de carte ne puissent être reconstituées.

supports.

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.

EXIGENCES DES NORMES PCI DSS PROCÉDURES DE TEST EN PLACE

PAS EN PLACE


10.1 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.

10.1 Vérifier, par observation et par un entretien avec l’administrateur du système, que des pistes de vérification sont activées et actives, y compris pour tous réseaux sans fil connectés.

10.2 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 :

10.2 Vérifier, par des entretiens, l’examen de registres de vérification et l’examen de paramètres de registres d'audit que les événements suivants sont bien enregistrés dans les registres d'activité du système :

10.2.1 tous les accès d’un individuel aux données d’un titulaire de carte ;

10.2.1 tous les accès d’un individu aux données d’un titulaire de carte ;

10.2.2 toutes les actions effectuées par une personne jouissant d'avantages de base ou administratifs ;

10.2.2 les actions effectuées par une personne jouissant d'avantages de base ou administratifs ;

10.2.3 l'accès à toutes les pistes de vérification ;

10.2.3 l'accès à toutes les pistes de vérification ;

10.2.4 les tentatives d’accès logique invalides ;

10.2.4 les tentatives d’accès logique invalides ;



PAS EN PLACE


10.2 5 l'utilisation des mécanismes d’identification et d’authentification ;

10.2.5 l'utilisation des mécanismes d’identification et d’authentification ;

10.2.6 l'initialisation des journaux de vérification ;

10.2.6 l'initialisation de journaux de vérification ;

10.2.7 la création et la suppression d’objets de niveau système.

10.2.7 la création et la suppression d’objets de niveau système.

10.3 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 :

10.3 Vérifier, par des entretiens et par l’observation, pour chaque événement devant donner lieu à vérification (à partir du 10.2) que la piste de vérification comporte les éléments suivants :

10.3.1 l'identification de l’utilisateur ; 10.3.1 l'identification de l’utilisateur ;

10.3.2 le type d’événement ; 10.3.2 le type d’événement ;

10.3.3 la date et le lieu ; 10.3.3 le cachet horodateur ;

10.3.4 une indication de succès ou d’échec ;

10.3.4 une indication de succès ou de réussite, y compris pour les connexions sans fil ;

10.3.5 l'origine de l’événement ; 10.3.5 l'origine de l’événement ;

10.3.6 l'identité ou la dénomination des données, composants de système ou ressources affectés.

10.3.6 l'identité ou la dénomination des données, composants de système ou ressources affectés.

10.4 Synchroniser toutes les horloges et heures du système critique.

10.4 Obtenir et examiner le processus d’obtention et de distribution de l’heure exacte au sein de l’organisation, ainsi que les configurations de paramètres systémiques liés au temps pour un échantillon de composants du système, de serveurs critiques et de points d'accès sans fil. Vérifier que les points suivants sont inclus dans le processus et mis en œuvre :

10.4.a Vérifier qu'un NTP ou une technologie similaire est utilisée pour la synchronisation horaire.

10.4.b Vérifier que des serveurs internes ne reçoivent pas de signaux horaires émanant de sources externes. [Deux ou trois serveurs centraux, au sein de l’organisation, reçoivent des signaux horaires externes [provenant directement d’une radio spéciale, de satellites GPS ou d’autres sources externes, et basés



PAS EN PLACE


sur le Temps atomique international et l’UTC (ex-GMT)], travaillent en homologue les uns avec les autres afin de maintenir l'exactitude horaire et partagent le temps avec d'autres serveurs internes.] 10.4.c Vérifier que la version du Network Time Protocol (NTP) utilisée est la plus récente

10.4.d Vérifier que des hôtes externes spécifiques, desquels les serveurs horaires accepteront des mises à jour horaires NTP (pour éviter qu’un attaquant ne modifie l’horloge), ont été désignés. De manière optionnelle, ces mises à jour peuvent être cryptées par clé symétrique, et des listes de contrôle d’accès spécifiant les adresses IP qui seront communiquées au service NTP (pour empêcher une utilisation non autorisée de serveurs horaires internes) peuvent être établies. Pour plus d’informations, consulter www.ntp.org/

10.5 Sécuriser les piste de vérification afin qu’elles ne puissent être détruites.

10.5 Interroger l’administrateur du système et étudier les autorisations afin de vérifier que les pistes de vérification sont sécurisées, pour qu’elles ne puissent être effacées, comme suit :

10.5.1 Limiter la consultation des pistes de vérification aux personnes ayant, de par leurs fonctions, besoin d’y avoir accès.

10.5.1 vérifier que seules des personnes ayant besoin d’en avoir connaissance dans le cadre de leurs fonctions puissent accéder aux fichiers de piste de vérification.

10.5.2 Protéger les dossiers des pistes de vérification des modifications non autorisées.

10.5.2 Vérifier que les fichiers de piste de vérification courants sont protégés des modifications non autorisées grâce à des mécanismes de contrôle d’accès, une séparation physique et/ou une ségrégation de réseau.

10.5.3 Sauvegarder promptement les fichiers des pistes de vérification sur un serveur registre centralisé, ou un support difficile à modifier.

10.5.3 Vérifier que les fichiers des pistes de vérification sont promptement sauvegardés sur un serveur registre centralisé, ou un support difficile à modifier.

10.5.4 Copier les journaux relatifs aux réseaux sans fil sur un serveur registre du LAN interne.

10.5.4 Vérifier que les journaux relatifs aux réseaux sans fil sont téléchargés ou copiés sur un serveur registre interne centralisé, ou un support difficile à



PAS EN PLACE


modifier.10.5.5 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 registre 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).

10.5.5 Vérifier l’utilisation de la surveillance de l’intégrité de fichier ou le logiciel de détection de modification en examinant les paramètres du système et les fichiers modifiés, ainsi que les résultats des activités de surveillance.

10.6 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é, 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 10.6.

10.6.a Obtenir et étudier les politiques et procédures en matière de sécurité pour vérifier qu'elles incluent des procédures de vérification des journaux de sécurité au moins quotidiennement et qu'un suivi des exceptions est requis.

10.6.b Par des observations et des entretiens, s’assurer que des examens réguliers des journaux sont réalisés pour l’ensemble des composants du système.

10.7 Conserver l’historique de piste de vérification durant au moins un an, avec un minimum de trois mois de disponibilité en ligne.

10,7.a Obtenir et étudier les politiques et procédures en matière de sécurité et s’assurer qu’elles incluent des politiques relatives à la conservation des registres de vérification durant au moins un an.

10.7.b Vérifier que des journaux de vérification sont disponibles en ligne ou sur bande durant au moins un an.

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.



PAS EN PLACE


11.1 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.

11.1.a Vérifier, par des entretiens avec le personnel de sécurité, ainsi qu’en examinant le code, les documents et les processus pertinents, que des tests de sécurité des appareils ont été mis en place, pour que des contrôles identifient et stoppent les tentatives d'accès non autorisé dans l'environnement de titulaire de carte.

11.1.b Vérifier qu’un analyseur sans fil est utilisé, au moins une fois par trimestre, afin d’identifier l'ensemble des dispositifs sans fil.

11.2 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é.

11.2.a Étudier le résultat des balayages de vulnérabilité de réseau, d'hôte et d'application pour les quatre trimestres les plus récents, afin de vérifier que des tests de sécurité des dispositifs dans l’environnement de titulaire de carte sont périodiquement effectués. Vérifier que les processus de balayage incluent de nouveaux balayages jusqu’à ce que des résultats « propres » puissent être obtenus.

11.2.b Pour vérifier qu’un balayage externe a lieu sur une base trimestrielle, conformément aux Procédures de balayage de sécurité de PCI, étudier le résultat des balayages de vulnérabilité externes pour les quatre trimestres les plus récents, afin de vérifier que :

• quatre balayages trimestriels ont eu lieu au cours de la période de 12 mois la plus récente ;

• les résultats de chaque balayage sont conformes aux Procédures de PCI en matière de balayage de sécurité) ;

• les balayages ont été effectués par un prestataire agréé pour mettre en œuvre les Procédures de PCI en matière de balayage de sécurité.

11.3 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

11.3 Obtenir et étudier les résultats des tests de pénétration les plus récents, afin de vérifier que des tests de pénétration sont réalisés au moins annuellement, ainsi qu’après chaque changement significatif de l’environnement. Vérifier que toutes



PAS EN PLACE


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 :

vulnérabilités identifiées ont été corrigées. Vérifier que les tests de pénétration incluent les suivants :

11.3.1 des tests de pénétration de couche de réseau ;

11.3.1 des tests de pénétration de couche de réseau ;

11.3.2 des tests de pénétration de couche d’application.

11.3.2 des tests de pénétration de couche d’application.

11.4 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.

11.4.a Observer l’utilisation, en liaison avec le réseau, de systèmes de détection d’intrusion dans le réseau et/ou de systèmes de prévention d’intrusion. Vérifier que la totalité du trafic critique du réseau dans l’environnement de données de titulaire de carte est surveillé.

11.4.b Vérifier qu’un système de détection d’intrusion ou un système de prévention d’intrusion est en place pour surveiller et alerter les personnels d’éventuelles atteintes à la sécurité.

11.4.c Étudier les configurations des systèmes de détection d’intrusion/système de prévention d’intrusion et vérifier que les systèmes de détection d’intrusion ou systèmes de prévention d’intrusion sont configurés, maintenus et mis à jour, conformément aux instructions du fournisseur/prestataire, afin de garantir une protection optimale.



PAS EN PLACE


11.5 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).

11.5 Vérifier l’utilisation de produits de surveillance de l’intégrité de fichiers dans l’environnement de données de titulaire de carte, en observant les paramètres du système et les fichiers surveillés, ainsi qu’en étudiant les résultats des activités surveillées.

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 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.



PLACE PAS EN PLACE


12.1 Édicter, publier, maintenir en vigueur et diffuser une politique en matière de sécurité correspondant aux caractéristiques ci-après :

12.1 Étudier la politique de sécurité de l’information et s’assurer que cette politique est publiée et diffusée auprès de l’ensemble des utilisateurs voulus du système (y compris les fournisseurs/prestataires, sous-traitants et partenaires commerciaux).

12.1.1 prenant en compte l’ensemble des exigences contenues dans les présentes spécifications ;

12.1.1 Vérifier que la politique prenne en compte l’ensemble des aspects des présentes spécifications.

12.1.2 comportant un processus annuel d’identification des menaces et vulnérabilités, qui débouche sur une évaluation formelle du risque ;

12.1.2 Vérifier que la politique en matière de sécurité de l’information inclut un processus annuel d’évaluation des risques permettant d’identifier les menaces et vulnérabilités éventuelles et débouchant sur une évaluation formelle du risque.

12.1.3 incluant un examen au moins annuel, ainsi que des mises à jour lorsque l’environnement change.

12.1.3 Vérifier que la politique en matière de sécurité de l’information est examinée au moins annuellement et mise à jour comme nécessaire pour tenir compte de la modification des objectifs commerciaux ou de l'évolution de l'environnement en matière de risque.

12.2 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).

12.2.a Étudier les procédures de sécurité opérationnelle quotidiennes. S’assurer qu’elles sont conformes à ces spécifications et incluent des procédures administratives et techniques pour chacune des exigences.

12.3 É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 :

12.3 Obtenir et étudier la politique applicable aux technologies d’interface avec les salariés et vérifier qu'elle inclut les éléments suivants :

12.3.1 l'accord explicite de la 12.3.1 Vérifier que les politiques en matière d’utilisation



PLACE PAS EN PLACE


direction ; prévoient l’approbation explicite, par la direction, de l'utilisation des appareils.

12.3.2 une obligation d’authentification pour utiliser la technologie ;

12.3.2 Vérifier que les politiques en matière d’utilisation exigent que l’utilisation de tous les appareils soit authentifiée par nom d'utilisateur et mot de passe, ou tout autre élément d'authentification (par exemple, un jeton)

12.3.3 une liste de la totalité des dispositifs et personnels disposant d’un accès ;

12.3.3 Vérifier que les politiques en matière d’utilisation exigent une liste de la totalité des périphériques/appareils, ainsi que des personnels autorisés à les utiliser.

12.3.4 un étiquetage des appareils indiquant l’identité du propriétaire, ses coordonnées et le but de leur utilisation ;

12.3.4 Vérifier que les politiques en matière d’utilisation exigent un étiquetage des appareils indiquant l’identité du propriétaire, ses coordonnées et le but de leur utilisation.

12.3.5 les utilisations acceptables des technologies ;

12.3.5 Vérifier que les politiques en matière d’utilisation exigent que l’utilisation des technologies soit acceptable.

12.3.6 les emplacements de réseau acceptables pour les technologies ;

12.3.6 Vérifier que les politiques en matière d’utilisation exigent que l’utilisation des technologies soit acceptable.

12.3.7 une liste des produits approuvés par la société ;

12.3.7 Vérifier que les politiques en matière d’utilisation exigent une liste des produits approuvés par la société.

12.3.8 une interruption automatique de la session après une période d’inactivité spécifique ;

12.3.8 Vérifier que les politiques en matière d’utilisation exigent une interruption automatique de la session après une période d’inactivité spécifique.

12.3.9 l'activation des modems fournisseurs uniquement lorsque ces derniers en ont besoin, avec désactivation immédiate après utilisation ;

12.3.9 Vérifier que les politiques en matière d’utilisation exigent l'activation des modems fournisseurs uniquement lorsque ces derniers en ont besoin, avec désactivation immédiate après utilisation.

12.3.10 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.

12.3.10 Vérifier que les politiques en matière d’utilisation interdisent le stockage de ces données de titulaire sur disque dur local, disquette ou autre support externe lors de l’accès distant à ces données, par modem. Vérifier que les politiques interdisent les fonctions copier/coller et d’impression lors de l’accès distant.

12.4 Faire en sorte que les politiques et procédures en matière

12.4 Vérifier que les politiques en matière d’utilisation définissent clairement les responsabilités en matière de



PLACE PAS EN PLACE


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.

sécurité de l’information telles qu’elles s’appliquent à l’ensemble des employés et sous-traitants.

12.5 Attribuer à un individu ou à une équipe les responsabilités ci-après en matière de gestion de la sécurité de l'information :

12.5 Vérifier que la sécurité de l’information est confiée formellement à un Directeur de la sécurité, ou à tout autre membre de la direction compétent dans le domaine de la sécurité. Obtenir et examiner les politiques et procédures en matière de sécurité de l’information, afin de vérifier que les responsabilités ci-après, en matière de sécurité de l’information, sont attribuées de manière spécifique et formelle :

12.5.1 mettre en place, consigner par écrit et diffuser les politiques et procédures en matière de sécurité ;

12.5.1 Vérifier que les responsabilités en matière de création et de diffusion des politiques et procédures en matière de sécurité sont formellement réparties.

12.5.2 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 ;

12.5.2 Vérifier que la responsabilité de la surveillance et de l’analyse des alertes de sécurité, ainsi que la diffusion de l’information à des collaborateurs compétents en matière de sécurité de l’information et de la direction de l’unité fonctionnelle, sont réparties formellement.

12.5.3 é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 ;

12.5.3 Vérifier que les responsabilités en matière de création et de diffusion des politiques et procédures en matière d’intervention d’urgence et de remontée des paliers de décisions sont formellement réparties.

12.5.4 administrer les comptes d’utilisateur, y compris tous ajouts et toutes suppressions ou modifications ;

12.5.4 Vérifier que les responsabilités en matière d’administration de compte d’utilisateur et de gestion d’authentification sont attribuées formellement.

12.5.5 surveiller et contrôler tous les accès à des données.

12.5.5 Vérifier que les responsabilités en matière de surveillance et de contrôle de l’ensemble des accès aux données sont attribuées formellement.

12.6 Mettre en œuvre un programme formel de sensibilisation à

12.6.a Vérifier l’existence d’un programme formel de sensibilisation à la sécurité destiné à tous les employés.



PLACE PAS EN PLACE


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 :

12.6.b Obtenir et étudier les procédures et documents afférents au programme de sensibilisation et mettre en œuvre les mesures suivantes :

12.6.1 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).

12.6.1.a Vérifier que le programme de sensibilisation à la sécurité inclut plusieurs méthodes de sensibilisation et de formation des salariés (par exemple, des affiches, courriers, réunions, etc.)

12.6.1.b Vérifier que tous les employés participent à une formation de sensibilisation à leur arrivée dans l'entreprise et, par la suite, au moins une fois par an.

12.6.2 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é.

12.6.2 Vérifier que le programme de sensibilisation à la sécurité impose aux employés de reconnaître par écrit qu’ils ont lu et compris la politique de la société en matière de sécurité de l’information.

12.7 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.

12.7 Interroger la direction du département des ressources humaines et vérifier que des contrôles de sécurité sont effectués (conformément aux dispositions du droit local) concernant les employés qui auront accès à des données de titulaire de carte ou à l'environnement de données de titulaire de carte. (Entre autres exemples de vérifications figurent les contrôles préalables au recrutement, demandes d’extrait de casier judiciaire, l’historique de crédit et la vérification des références).

12.8 Si des données de titulaire de carte sont communiquées à des prestataires de services, les mesures ci-après sont impératives :

12.8 Si l’entité faisant l’objet des vérifications partage des données de titulaire de carte avec une autre société, obtenir et examiner les contrats entre l’organisation et tous tiers susceptibles de gérer des données de titulaire de carte (par exemple, des installations de stockage de bandes de sauvegarde, des fournisseurs de services gérés, comme par exemple des sociétés d'hébergement sur Internet ou des fournisseurs de services de sécurité, ou des entités recevant des données à des fins de modélisation de fraude). Mettre en œuvre les mesures suivantes :



PLACE PAS EN PLACE


12.8.1 les prestataires de services doivent se conformer aux exigences des Normes PCI DSS ;

12.8.1 Vérifier que le contrat contient des dispositions exigeant le respect des Normes PCI DSS.

12.8.2 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.

12.8.2 Vérifier que le contrat contient des dispositions prévoyant la reconnaissance, par le tiers, de sa responsabilité en matière de sécurisation de données de titulaire de carte.

12.9 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.

12.9 Obtenir et examiner le Plan d’intervention d’urgence, ainsi que les procédures liées et mettre en œuvre les mesures suivantes :

12.9.1 É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).

12.9.1 Vérifier que le Plan d’intervention d’urgence et les procédures liées incluent :

• les rôles, responsabilités et stratégies de communication en cas d’atteinte à la sécurité ;

• la couverture et les réponses pour l’ensemble des composants de système critique ;

• l’information, au minimum, des associations et acquéreurs de carte de crédit ;

• une stratégie en matière de continuité de l’activité après une atteinte à la sécurité ;

• la référence à, ou l’inclusion de procédures d’intervention d'urgence des associations de carte ;

• l'analyse des obligations légales en matière de déclaration des atteintes à la sécurité (ainsi, le projet de loi 1836 de l’État de Californie prévoit-il une obligation d’information des clients concernés en cas d’atteinte à la sécurité, avérée ou éventuelle, en relation avec toute transaction avec des résidents californiens figurant dans la base de données).

12.9.2 Tester le plan au moins une fois par an.

12.9.2 S’assurer que le plan est testé au moins une fois par an.



PLACE PAS EN PLACE


12.9.3 Désigner des collaborateurs spécifiques, qui devront être disponibles 24 heures sur 24, 7 jours sur 7, pour répondre aux alertes.

12.9.3 Vérifier, par l’observation et l’examen des politiques, qu’il existe un dispositif d’intervention et une surveillance 24 heures sur 24, 7 jours sur 7, en relation avec toutes preuves d'activités non autorisées, toutes alertes se rapportant à des systèmes de détection d'incident critiques, et/ou toutes déclarations afférentes à la modification non autorisée de systèmes critiques ou de fichiers de contenu.

12.9.4 Fournir une formation appropriée aux collaborateurs en charge de l’intervention en cas d’atteinte à la sécurité.

12.9.4 Vérifier, par l’observation et l’examen des politiques, que les collaborateurs en charge de la gestion des atteintes à la sécurité bénéficient de formations périodiques.

12.9.5 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.

12.9.5 Vérifier, par l’observation et l’examen des politiques, que la surveillance et l’intervention suite à une alerte des systèmes de sécurité sont incluses dans le Plan d’intervention d’urgence.

12.9.6 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.

12.9.6 Vérifier, par l’observation et l’examen des politiques, qu'il existe un 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.

12.10 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 :

12.10 Vérifier, par l’observation et l’examen des politiques et procédures, ainsi que de la documentation à l’appui, qu'il existe un processus de gestion des entités liées, par la mise en œuvre des mesures suivantes :

12.10.1 gérer une liste d’entités liées ;

12.10.1 Vérifier qu’il existe une liste d’entités liées.

12.10.2 faire en sorte qu’une vérification préalable soit effectuée avant la connexion de toute entité ;

12.10.2 Vérifier que des procédures prévoient qu’une vérification préalable doit être effectuée avant la connexion de toute entité.

12.10.3 s’assurer que l’entité est conforme aux Normes PCI DSS ;

12.10.3 Vérifier que les procédures prévoient que l’entité se conforme aux Normes PCI DSS

12.10.4 connecter et déconnecter les entités conformément à une procédure établie.

12.10.4 Vérifier que la connexion et la déconnexion d’entités se déroulent conformément à un processus bien établi



Annexe A : conditions d’application des Normes PCI DSS pour les fournisseurs d’hébergement (avec les Procédures de test)

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 :

Exigences ProcÉdures de test En Place PAS En Place Date CIBLE/ CommentAI

REs

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 : 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é.

A.1 Spécifiquement, dans le cas d’un audit PCI concernant un Fournisseur d’hébergement partagé, vérifier que les Fournisseurs d’hébergement partagé protègent les données et environnements hébergés d’entités (commerçants et prestataires de service), sélectionnent un échantillon de serveurs (Microsoft Windows et Unix/Linux) dans un échantillon représentatif de commerçants et de prestataires de service hébergés, et vérifier les points A.1.1 à A.1.4 ci-après.

A.1.1 faire en sorte que chaque entité ait uniquement accès à l’environnement de données de son

A.1.1 Si un fournisseur d’hébergement partagé permet à des entités (par exemple, des commerçants et prestataires de service) d’exécuter leurs propres applications, vérifier que



REs propre titulaire de carte ;

ces processus d'application fonctionnent avec l'identité d'utilisateur unique de l'entité. Par exemple :

• aucune entité dans le système ne peut utiliser une identité d'utilisateur partagée pour un serveur Internet ;

• tous les scripts CGI utilisés par une entité doivent être créés et fonctionner en tant qu’identité d'utilisateur unique de l’entité.

A.1.2 limiter l’accès et les privilèges de chaque entité exclusivement à l’environnement de d é d tit l i d

A.1.2.a Vérifier que l’identité d’utilisateur d’un processus d’application n’est pas celle d’un utilisateur privilégié (de base/admin.).



REs

A.1.2.b S’assurer que chaque entité (commerçant ou prestataire de services) possède les autorisations de lecture, écrite ou exécution uniquement pour les fichiers et répertoires qu’elle possède, ou aux fichiers systèmes nécessaires (soumis à restriction par l’autorisation d’un système de fichiers, des listes de contrôle d’accès, « chroot », « jailshell », etc.). IMPORTANT : les fichiers d’une entité ne peuvent être répartis par groupe.

A.1.2.c Vérifier que les entités d’utilisateur ne disposent pas d’un accès écrit aux données binaires d’un système partagé

A.1.2.d Vérifier que la consultation des entrées dans le journal est limitée à l’entité propriétaire.

A.1.2.e S’assurer qu'une entité ne peut monopoliser les ressources de serveur requises pour exploiter les vulnérabilités (erreur, fonctionnement et conditions de redémarrage entraînant, par exemple, des attaques par débordement de tampon) ; vérifier que des restrictions sont en place pour l’utilisation des ressources de ce système : • espace de disque ; • bande passante ; • mémoire ; • unité centrale.

A.1.3 faire en sorte que les connexions et pistes 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.3.a Vérifier que le fournisseur d’hébergement partagé a activé la connexion comme suit, pour l’environnement de chaque fournisseur ayant la qualité de commerçant ou de prestataire de services : • des connexions sont activées pour des applications

courantes de tiers ; • des connexions sont actives par défaut ; • des connexions sont disponibles pour examen par

l’entité propriétaire ; • les emplacements des connexions sont clairement

communiqués à l’entité propriétaire.

A.1.4 mettre en place des processus destinées à permettre

A.1.4 Vérifier que le fournisseur d’hébergement partagé dispose de politiques écrites destinées à permettre des



REs des investigations technico-légales ponctuelle en cas d'atteinte à la sécurité d'une entité marchande ou d'u, prestataire de services hébergé.

investigations technico-légales ponctuelles en cas d'atteinte à la sécurité.

Security Audit Procedures v 1.1 65

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 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).

Annexe C : Feuille de travail de contrôle correctif/exemple complété

Exemple

1. Contraintes : énumérer les contraintes empêchant le respect des exigences initiales

2. Objectif : définir l’objectif du contrôle initial ; identifier l’objectif atteint par le contrôle correctif

3. Risque identifié : identifier tout risque supplémentaire constitué par le défaut de contrôle initial

4. Définition des contrôles correctifs : définir les contrôles correctifs et expliquer de quelle manière ils prennent en compte les objectifs du contrôle initial, ainsi que, le cas échéant, le risque accru.

The objective of requiring unique logins is twofold. First, it is not considered acceptable from a security perspective to share login credentials. Secondly, shared logins makes it impossible to state definitively that a person is responsible for a particular action.

Additional risk is introduced to the access control system by not ensuring all users have a unique ID and are able to be tracked.

Company XYZ employs stand-alone Unix Servers without LDAP. As such, they each require a ‘root’ login. It is not possible for Company XYZ to manage the ‘root’ login nor is it feasible to log all ‘root’ activity by each user.


Company XYZ is going to require all users to log into the servers from their desktop using the SU command. SU allows a user to access the ‘root’ account and perform actions under the ‘root’ account but is able to be logged in the su-log directory. In this way, each user’s actions can be tracked through the SU account.

Date post:	14-Sep-2018
Category:	Documents
Upload:	dinhkiet
View:	213 times
Download:	0 times

Payment Card Industry (PCI) Normes en matière de sécurité ... · de carte du reste du réseau...

Documents