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

(1)

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

(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

(3)

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é

(4)

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)

(5)

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 ;

(6)

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

(7)

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 ;

(8)

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

(9)

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.

(10)

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

DATE CIBLE/

COMMENTAIRES 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

(11)

DATE CIBLE/

COMMENTAIRES 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

(12)

DATE CIBLE/

COMMENTAIRES 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

(13)

DATE CIBLE/

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

(14)

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.

PLACE

DATE CIBLE/

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

(15)

DATE CIBLE/

COMMENTAIRES 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

(16)

DATE CIBLE/

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

(17)

(18)

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

PLACE

DATE CIBLE/

COMMENTAIRES 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

(19)

DATE CIBLE/

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

(20)

DATE CIBLE/

COMMENTAIRES 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

(21)

DATE CIBLE/

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

(22)

DATE CIBLE/

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

(23)

DATE CIBLE/

COMMENTAIRES 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

(24)

DATE CIBLE/

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

(25)

(26)

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.

PLACE

DATE CIBLE/

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

(27)

DATE CIBLE/

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

(28)

DATE CIBLE/

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

(29)

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.

PLACE

DATE CIBLE/

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

(30)

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.

PLACE

DATE CIBLE/

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