Référentiel de labélisation des prestataire intervenant ... · 7.5.2 Maintenance de niveau 2 ... recevoir des fonds en paiement par carte, ... ainsi que la saisie du code confidentiel

RÈGLES POUR LA GESTION SÉCURISÉE DES SYSTÈMES D’ACCEPTATION CB ET DES SERVEURS DE MONÉTIQUE RÉPARTIE

Version 1.2.1

Janvier 2017

GROUPEMENT DES CARTES BANCAIRES CB

DPE/ESS Règles Génériques de Sécurité Règles pour la Gestion Sécurisée des Systèmes d’Acceptation CB

Diffusion publique Référence : DPE-ESS-REF-2016-006 Version : 1.2.1 Page : 2/68

Diffusion ou copie de ce document, utilisation ou divulgation de son contenu autorisée sous réserve de mention de son origine

DOCUMENT RÉDIGÉ PAR :

SOCIÉTÉ NOM FONCTION DATE

SCASSI Aimeric PIETERS Ingénieur sécurité 24/06/2016

DOCUMENT VALIDÉ PAR :

SERVICE NOM FONCTION DATE

Paycert Didier Duville Expert acceptation et certification 29/06/2016

DPE/ESS Mathieu Robert Expert sécurité

DOCUMENT APPROUVÉ PAR :

DIRECTION NOM FONCTION DATE

DPE Pierre Chassigneux Directeur 09/11/2016

HISTORIQUE DES MODIFICATIONS :

MISE À JOUR RÉVISION DESCRIPTION DES MODIFICATIONS

29/06/2016 1.0 Version initiale : refonte du référentiel d’exigence 2015 suite aux

différents workshops de 2015 et 2016 avec les professionnels de

l’acceptation.

05/08/2016 1.1 Corrections mineures (bug de numérotation des exigences

communes)

09/11/2016 1.2 Coquilles et modifications mineures (cycle de vie de l’agrément,

EXI_CONS_8, EXI_EXPL_11, EXI_COM 18 et 19, et suppression

de l’exigence EXI_COM_41 redondante avec EXI_COM_40).

31/01/2017 1.2.1 Corrections mineures, reformulations





TABLES DES MATIÈRES

1 Références, acronymes et définitions .............................................................................. 5 1.1 Références .................................................................................................................... 5

1.2 Acronymes ................................................................................................................... 5 1.3 Définitions .................................................................................................................... 6

2 Introduction .................................................................................................................... 10

2.1 Contexte ..................................................................................................................... 10 2.2 Objectifs du document .............................................................................................. 10

3 Cycle de vie des Systèmes d’Acceptation CB autonomes et des Serveurs de

Monétique Répartie ....................................................................................................... 11

3.1 Gestion des Systèmes d’Acceptation CB ................................................................. 11 3.2 Exploitation des Systèmes d’Acceptation CB et Serveurs de Monétique

Répartie ...................................................................................................................... 12 3.3 Description des étapes............................................................................................... 13

3.3.1 Étapes ................................................................................................................... 13

3.3.2 Activités transverses ............................................................................................ 15

3.4 Matrice étapes / métiers............................................................................................ 16

4 Risques sécuritaires a couvrir ....................................................................................... 17

4.1 Menaces physiques .................................................................................................... 17 4.2 Menaces logiques ....................................................................................................... 17

5 Contrôle du statut d’agrément CB ............................................................................... 19

5.1 Schéma du cycle de vie ............................................................................................. 19 5.2 Statut entre « Fin de commercialisation / déploiement » et « Fin de vie » .......... 19

5.3 Statut à « Fin de vie » ............................................................................................... 19 5.4 Responsabilités .......................................................................................................... 20 5.5 Obligation pour les professionnels de l’acceptation .............................................. 20

6 zones de sécurité ............................................................................................................. 21

6.1 Schématisation........................................................................................................... 21 6.1.1 Zones pour acteurs dont les activités monétiques sont mutualisées avec

d’autres activités .................................................................................................. 22 6.1.2 Zones pour acteurs dont l’activité est dédiée à la monétique .............................. 26

7 Exigences de sécurité ...................................................................................................... 27 7.1 Constructeur .............................................................................................................. 29 7.2 Développeur ............................................................................................................... 31

7.3 Intégrateur ................................................................................................................. 34 7.4 Préparateur ............................................................................................................... 37 7.5 Mainteneur ................................................................................................................ 39

7.5.1 Générale ............................................................................................................... 39 7.5.2 Maintenance de niveau 2...................................................................................... 39

7.5.3 Mise au rebut, recyclage ...................................................................................... 43





7.6 Exploitation ............................................................................................................... 46 7.7 Stockeur/Logisticien ................................................................................................. 49 7.8 Distributeur ............................................................................................................... 51 7.9 Tronc commun .......................................................................................................... 52

7.9.1 Expédition de Points d’Acceptation ..................................................................... 52 7.9.2 Domaine d’activités et gestion des tiers ............................................................... 52

7.9.3 Protection des locaux et des équipements ............................................................ 53 7.9.4 Protection des systèmes informatiques ................................................................ 57

7.9.5 Environnements techniques ................................................................................. 63 7.9.6 Sécurité de la documentation papier .................................................................... 63 7.9.7 Sécurité des sauvegardes ...................................................................................... 64 7.9.8 Sécurité RH .......................................................................................................... 64

Annexe 1. Table des illustrations ...................................................................................... 66 Annexe 2. Remontée d’informations au Groupement des Cartes Bancaires ............... 67





1 RÉFÉRENCES, ACRONYMES ET DÉFINITIONS

1.1 Références

[1] Référentiel d'audit Gestion sécurisée des Points d’Acceptation CB

(GSPAC) v1.4.1 du 21/03/2013

[2] Référentiel d'audit « Gestion sécurisée des Points d’Acceptation CB et

des Serveurs de Monétique Répartie » élaboré par le GCB/RMA

(GSPAMI), v1.0 du 30/01/2014

[3] Référentiel d'audit « Sécurité des Environnements de Développement,

maintenance et livraison de Logiciels utilisés par la Communauté CB »

élaboré par le GCB/RMA (SEDEL), v1.0 du 22/02/2013

[4] Référentiel d’Audit Gestion sécurisée des automates de paiement CB

(DAC pour les pétroliers, bornes d'achats pour les sociétés de transport

en communs) v1.0 (GSAUTO) du 17/04/2015

[5] Nouveau mode d’agrément et de gestion des systèmes d’acceptation

CB, Référence : DPE-ESS-NTE-2015-002, version 0.7

[6] Convention d'Agrément "CB" des Systèmes d’acceptation CB5.x,

Référence : AGR/GES/CQS/2009-005, version 2.5

[7] Exigences sécuritaires liées aux communications avec les systèmes

d’acceptation paiement, référencé DET/IS/HP/03.018, version 1.8, daté

de novembre 2015

[8] Manuel de Paiement Électronique (MPE) v5.2, décembre 1999, et ses

bulletins

[9] Manuel de Paiement Électronique (MPE) v5.5, décembre 2014

[10] Annexe 8 du Volume 4 du Manuel de Paiement Électronique (MPE)

v5.5, décembre 2014

[11] Payment Card Industry (PCI) – Terminal Software Security, Best

Practices, Version 1.0, November 2014

[12] Payment Card Industry (PCI) – Payment Application Data Security

Standard, Requirements and Security Assessment Procedures, dernière

version applicable

[13] Payment Card Industry (PCI) – Data Security Standard, Requirements

and Security Assessment Procedures, dernière version applicable

[14] PCI PIN Transaction Security Point of Interaction Standard (PTS POI)

1.2 Acronymes

CVx Card Verification Value (Visa) or Code (MasterCard)

HSM Hardware Security Module

PAN Primary Account Number

TPE Terminal de Paiement Électronique

VPN Virtual Private Network





1.3 Définitions

Acquéreur CB Tout Prestataire de Service de Paiement membre du

Groupement qui acquiert, traite et introduit, dans un

système d'échanges avec l’ensemble des Émetteurs

« CB », internationaux et des systèmes d’information et

de régulation communautaires, les données des

transactions par Cartes Bancaires « CB » ou cartes

agréées « CB » chez les Accepteurs avec lesquels il est

lié par un contrat d'acceptation « CB ».

Accepteur CB Tout commerçant, tout organisme de services, toute

profession libérale et, d'une manière générale, tout

professionnel ou organisme privé ou public habilité à

recevoir des fonds en paiement par carte, ayant signé un

contrat d'acceptation « CB » avec son Prestataire de

Service de Paiement.

Il assure l'exploitation du Système d'Acceptation.

Constructeur Acteur assurant la fourniture des composantes

matérielles et le développement des logiciels présents sur

le système d’acceptation.

Il construit, développe et met à disposition les systèmes

d'acceptation conformes au MPE. Dans ce cadre, il gère

le gestionnaire d’application pour :

Fournir au système d’acceptation les fonctions du

système et de gestion des périphériques,

Mettre à jour le logiciel du noyau.

Le constructeur est la personne morale signataire de la

Convention d’Agrément.

Développeur Organisme en charge du développement logiciel pour les

Systèmes d’Acceptation CB ou Logiciel Monétique

Distributeur/Revendeur Acteur qui prend en charge la distribution ou la revente

du Point d’Acceptation CB du Constructeur.

Intégrateur Société qui réalise l’intégration d’un Système

d’acceptation dans un système plus global de l’accepteur,

typiquement un système de vente et d’encaissement de

paiement CB.





Mainteneur Acteur chargé de l’installation et de la maintenance

(matérielle) du système d’acceptation.

Toute intervention doit être identifiée par le passage

d’une carte « mainteneur » ou d’un code secret fourni par

l’industriel

Il démonte, contrôle, et remplace les pièces en fonction

de leur état d’usure. Il effectue le remontage, la

reconfiguration du Point d’acceptation CB ainsi que son

redémarrage. Deux niveaux de maintenance sont

identifiés :

- Niveau 1 : toute action ne nécessitant pas une

réactivation de la sécurité PCI. Exemple, dépannage

par hotline, intervention standard sans démontage

nécessitant, opérations de changement de pièces

secondaires : capot, batterie, câble, etc.

- Niveau 2 : intervention requérant la réactivation de

la sécurité PCI des Points d’Acceptation. Exemple :

réparation de la carte mère, de composants

électroniques.

Monétique Répartie Expression utilisée pour désigner un Système

d’Acceptation où la fonction d’acceptation de paiement

est distribuée dans un système, typiquement entre un

Point d’acceptation et un Serveur d’acceptation. Dans le

système CB, on parle aussi de « Monétique Intégrée »

pour désigner le même système.

Outil de réactivation PCI Outils et procédures permettant à un mainteneur de

remettre en service, après s’être authentifié, un Point

d’Acceptation CB ayant déclenché ses protections

« tamper responsive » suite à une opération de réparation

sensible.

Passerelle Système transmetteur situé entre des systèmes

d'acceptation et un système acquéreur et qui a pour objet

de transporter les différents flux monétiques. Il peut

exister un ou plusieurs « systèmes transmetteurs » entre

un système d’acceptation et un système acquéreur.

Passerelliste Organisme gérant les plateformes monétiques

acheminant les transactions CB (demandes

d’autorisation, télécollectes journalières) vers les

serveurs bancaires via une « passerelle » monétique.





Point d’Acceptation (PA) Point d’interaction avec le Porteur, permettant l'affichage

du montant de la transaction, l'entrée des données de

cartes CB ou agréées CB sur le Système d'acceptation

CB, ainsi que la saisie du code confidentiel par le porteur

lorsque demandé par le Système d’acceptation.

Porteur Personne physique, ayant souscrit un contrat d'utilisation

d'une carte bancaire CB ou agréée CB auprès d'un

établissement émetteur. La carte CB permet d'accéder

aux différents services : retraits nationaux ou

internationaux, paiements nationaux ou internationaux.

Préparateur Organisme ayant en charge la configuration du Système

d’Acceptation CB dans l’environnement de l’Accepteur

et poussant les paramètres et l’installation chez

l’Accepteur. Il créé le « magasin » de l’Accepteur CB,

c’est-à-dire le système de paiement de l’Accepteur.

Serveur d’acceptation (SA) Élément de type serveur d’un Système d’acceptation dit

réparti ou intégré, généralement utilisé dans

l’environnement des grandes enseignes. Ce serveur

concentre les flux de différents Points d’Acceptation lors

des transactions de paiement tout en réalisant de manière

centralisée une partie des opérations requises par ces

transactions.

Stockeur/logisticien Organisme de logistique fournissant un service de

stockage de masse pour les Systèmes d’Acceptation CB

« préparés » ou non.

Système d'Acceptation Le Système d'Acceptation est un équipement ou un

ensemble d’équipements permettant de réaliser des

transactions de paiement électronique par carte bancaire

“CB” ou agréée “CB”, conformément aux spécifications

requises par le Groupement. Il gère des fonctions

interbancaires de paiement CB qui requièrent des

relations avec des systèmes et acteurs externes. Un

Système d’acceptation peut se réduire à un simple boîtier

rendant toutes les fonctions de paiement attendues

(équipement qu’on appelle communément Terminal de

paiement électronique autonome ou TPE autonome), ou

être un système complexe réparti comprenant un Serveur

d’acceptation (SA) et des Points d’Acceptation (PA).





TPE CB5.2 Terminal de Paiement Électronique conforme aux

spécifications CB5.2 [8] émises par le Groupement des

Cartes Bancaires CB.

TPE CB5.5 Terminal de Paiement Électronique conforme aux

spécifications CB5.5 [9] émises par le Groupement des

Cartes Bancaires CB.

Terminal Management System (TMS) Ensemble de serveurs permettant la gestion

des Points d’Acceptation. On distingue trois fonctions :

- Télé-paramétrage système ;

- Gestion et monitoring du parc de PA et de leur

cycle de vie ;

- Mises à jour à distance des logiciels (au sens

système et au sens applicatif CB2A).

Scellé1 Dispositif capable de mettre en évidence une tentative

d’atteinte à l’intégrité physique de l’équipement sur

lequel il est placé, que cette tentative ait réussi ou non.

Secret Tout élément d'authentification donnant des privilèges

sur un système ou une application.

1 Définition issue du Guide Technique de l’ANSSI « pour la réalisation et l’utilisation de scellés de sécurité

pour les équipements des systèmes d’information ».





2 INTRODUCTION

2.1 Contexte

En réponse aux recommandations émises par la Banque de France lors de la mission

Oversight framework for card payment schemes, CB a en charge le renforcement de la

surveillance des Systèmes d’Acceptation CB sur le terrain, au travers d’exigences de

sécurité spécifiques relatives au processus de maintenance, et la définition d’une

procédure standard établissant les règles pour la livraison, l’installation et la maintenance

des Systèmes d’Acceptation CB et des Serveurs de Monétique Répartie, tant dans les

établissements CB et leurs membres rattachés que chez les organismes de services

concernés travaillant pour la communauté CB.

Dans ce cadre, l’Audit Système CB a réalisé un état des lieux de ces processus de gestion

des Systèmes d’Acceptation CB et des Serveurs de Monétique Répartie, tant chez les

constructeurs que chez les prestataires de services des établissements CB.

Dans la continuité de ce travail, ce document a été élaboré pour constituer un référentiel

d’exigences sécuritaires applicables à tous les acteurs impliqués dans les différentes

étapes du cycle de vie des Systèmes d’Acceptation CB et des Serveurs de Monétique

Répartie (fabrication, développement logiciel, stockage, préparation, livraison,

exploitation, maintenance et mise au rebut).

On distingue plusieurs familles de Systèmes d’Acceptation CB :

- Terminaux de paiement électronique (TPE) autonomes ;

- Systèmes de monétique répartie avec Points d’Acceptation raccordés à des caisses

et concentrateurs monétiques ou serveurs d’acceptation ;

- Automates de paiement (parking, bornes, carburant…).

Ce référentiel doit permettre à terme à la communauté CB de labéliser tous les acteurs

impliqués dans la gestion des Systèmes d’Acceptation incluant les Serveurs de Monétique

Répartie.

2.2 Objectifs du document

Le présent document constitue le référentiel d’exigences sécuritaires applicables à chaque

étape du cycle de vie des Systèmes d’Acceptation CB et des Serveurs de Monétique

Répartie. Ces exigences couvrent les processus métiers des différents organismes

intervenant sur les Systèmes d’acceptation réalisant des transactions CB ou ayant

vocation à les réaliser, depuis la phase de construction jusqu’à la phase de mise au rebut.

Par « transaction CB », on entend des transactions initiées par un moyen de paiement CB,

et se déroulant à travers le réseau d’autorisation interbancaire CB.

Il ne couvre évidemment pas des processus métiers relatifs à la gestion du cycle de vie de

Systèmes d’acceptation qui n’auraient pas vocation à réaliser des transactions CB.





3 CYCLE DE VIE DES SYSTÈMES D’ACCEPTATION CB AUTONOMES ET DES SERVEURS DE MONÉTIQUE RÉPARTIE

Ce chapitre présente le cycle de vie des Systèmes d’Acception CB. Il propose un

découpage de ce cycle de vie, par étapes. Chacune de ces étapes correspond à un métier

auquel sont rattachées des activités.

Le marché a un historique et une répartition complexe des tâches entre les acteurs. Aussi

il se peut que la description des activités ne soit pas exhaustive et que pour certaines

d’entre elles le rattachement métier ne corresponde pas à la réalité du terrain.

Ces écarts seront alors compensés par le processus de labélisation. En effet, ce dernier

offre plus de finesse quant aux possibilités d’ajustement des exigences applicables pour

un acteur donné.

3.1 Gestion des Systèmes d’Acceptation CB

Le schéma ci-dessous présente une modélisation du cycle de vie d’un Système

d’Acceptation CB et des Serveurs de Monétique Répartie, de la fabrication à la mise au

rebut en passant par le développement des logiciels embarqués, le stockage, la

préparation, la livraison, l’exploitation et la maintenance.





Figure 1 : Cycle de vie d'un Système d'Acceptation CB

3.2 Exploitation des Systèmes d’Acceptation CB et Serveurs de Monétique Répartie

La phase d’exploitation d’un Système d’acceptation comprend plusieurs métiers qui

dépendent de l’architecture retenue, et en particulier de la typologie du Système

d’Acceptation (Point d’Acceptation autonome versus monétique répartie).

Le schéma suivant propose une simplification pour illustration, sachant que la réalité

d’une architecture donnée peut consister en autre agencement des différents métiers, en

fonction des choix réalisés par les acteurs en charge de la conception du Système

d’Acceptation et du système plus global dans lequel il s’intègre.

Stockage

Fabrication

Intégration

Développement logiciel

Stockage

Préparation / personnalisation

Stockage

Installation/mise en service

Exploitation

Maintenance

Mise au rebut

1

3

4

5

6

7

8

2

Stockage

Activités hors du périmètre de la labélisation

Développement

logiciel

2





Les notions de Passerelle réseaux et applicatives sont confondues dans le présent

référentiel par souci de simplification de la labélisation. Les exigences associées à

l’Exploitation s’appliquent donc aux deux types de système.

Figure 2 : Zoom sur l'exploitation et la gestion des différents services

3.3 Description des étapes

Ci-après sont décrites les opérations réalisées pour chacune des étapes de ce cycle de vie :

3.3.1 ÉTAPES

1 – Fabrication d’un Système d’Acceptation CB

- Fabrication des circuits imprimés (PCB), avec intégration des composants

électroniques de sécurité (PCI, vérification de signature…) ;

- Assemblage d’un Système d’Acceptation CB ;

- Chargement des secrets initiaux d’un Point d’Acceptation CB, nécessaires à

l’activation de la sécurité PCI.

Environnement TMS

Accepteur

Mainteneur

6

7

Téléparamétrage système

Développeur Logiciel

Acquéreur

6

2

6

Gestion du parc de PA

Déploiement de mises à

jour

Passerelle Monétique

6





2 – Développement des logiciels d’un Système d’Acceptation CB) et Serveur de monétique Répartie

- Développement ;

- Recette ;

- Support de mise en production, d’incident et d’évolution logicielle (correctifs

fonctionnels et de sécurité).

Ces activités concernent les Systèmes et Points d’Acceptation CB et les Serveurs de

Monétique Répartie et plus précisément :

- Les logiciels embarqués ou installés (modules logiciels du système d’exploitation,

du module EMV, de l’application CB, etc.) ;

- La signature électronique des logiciels ;

- Les outils de réactivation PCI de la sécurité d’un Point d’Acceptation CB.

3 – Intégration

- Intégration d’un Point d’Acceptation CB dans un système d’encaissement ou un

Système d’Acceptation plus complexe ;

- Mise à jour des logiciels initiaux (Systèmes d’Exploitation, application) dans un

Point d’Acceptation CB.

4 – Préparation d’un Point d’Acceptation CB

- Réception d’un Point d’Acceptation CB non préparé ;

- Téléchargement des logiciels nécessaires dans un Point d’Acceptation CB (via

TMS, Bluetooth, clé USB, port série RS-232, etc.) ;

- Paramétrage d’un Système d’Acceptation CB ;

- Fabrication de la carte de domiciliation du commerçant (selon les besoins).

5 – Installation d’un Système d’Acceptation CB

- Installation du Système d’Acceptation CB chez l’accepteur ;

- Télécollecte/télé-paramétrage d’un Système d’Acceptation CB ;

- Télé-mise à jour d’un Système d’Acceptation CB ;

6 – Exploitation d’un Système d’Acceptation CB

- Utilisation d’un Système d’Acceptation CB (transactions CB) ;

- Authentification d'un serveur d'exploitation des Systèmes d’Acceptation CB ;

- Authentification d’un Système d’Acceptation CB autonome CB ;

- Gestion des flux CB par les passerelles monétiques.





7 – Maintenance d’un Système d’Acceptation CB

- Réception d’un Point d’Acceptation CB à réparer ;

- Stockage d’un Point d’Acceptation CB à réparer ;

- Réparation d’un Point d’Acceptation CB ;

- Réactivation d’un Point d’Acceptation CB ;

- Préparation d’un Système d’Acceptation CB réparé ;

- Stockage d’un Point d’Acceptation CB réparé ;

- Emballage et expédition d’un Point d’Acceptation CB réparé ;

- Démontage d’un Point d’Acceptation CB à détruire ;

- Stockage des composants sensibles d’un Point d’Acceptation CB ;

- Mise au rebut d’un Point d’Acceptation CB.

3.3.2 ACTIVITÉS TRANSVERSES

Distribution / Revente d’un Point d’Acceptation CB

- Récupération de Points d’Acceptation CB ;

- Transport de Points d’Acceptation CB ;

- Dépose de Points d’Acceptation CB chez un acteur du cycle de gestion des

Systèmes d’Acceptation CB.

Stockage d’un Point d’Acceptation CB

- Réception d’un Point d’Acceptation CB;

- Stockage d’un Point d’Acceptation CB;

- Retrait du stock d’un Point d’Acceptation CB;

- Emballage et préparation pour expédition d’un Point d’Acceptation CB.





3.4 Matrice étapes / métiers

La matrice ci-dessous indique quels sont les métiers concernés par les différentes étapes

de gestion d’un Point d’Acceptation CB.

Étapes Métiers Commentaires

1 – Fabrication d’un Système d’Acceptation CB Constructeur

2 – Développement des logiciels d’un Système

d’Acceptation CB Développeur

3 – Intégration Intégrateur

4 – Préparation d’un Point d’Acceptation CB Préparateur

5 – Installation d’un Système d’Acceptation CB Préparateur

6 – Exploitation d’un Système d’Acceptation CB

Accepteur,

Acquéreur et

Passerelliste

7 – Maintenance d’un Système d’Acceptation CB Mainteneur

Distribution / Revente d’un Point d’Acceptation CB Distributeur /

Revendeur

Les différentes étapes de gestion

d’un Système d’Acceptation CB

ou d’un Serveur de Monétique

Répartie sont concernées par des

étapes intermédiaires de Transport

et de Stockage des Points

d’Acceptation CB

Stockage d’un Point d’Acceptation CB Stockeur /

Logisticien





4 RISQUES SÉCURITAIRES A COUVRIR

Le tableau ci-dessous synthétise les scénarii de menace qui ont été considérés par le

Groupement des Cartes Bancaires (GCB) et dont les exigences sécuritaires assurent la

couverture.

4.1 Menaces physiques

PHY_MOD-01 Ajouter un piège matériel sur un Système d’Acceptation CB, sans le

démonter (ajout d'un dispositif de capture piste magnétique/données

porteur, par exemple)

PHY_SUB-01 Substituer un Point d’Acceptation CB par un autre piégé ou

obsolète/vulnérable

PHY_PIE-01 Piéger un Système d’Acceptation CB en modifiant ses composants

matériels (ajout d'un dispositif de capture piste magnétique/données

porteur ou désactivation de la sécurité PCI, par exemple)

PHY_PIE-02 Réactiver de manière non autorisée, à l’aide des cartes/outils de

réactivation PCI fournis par le fabricant, la sécurité PCI d’un Point

d’Acceptation CB préalablement piégé

PHY_PIE-03 Voler les cartes/outils de réactivation PCI fournis par le fabricant,

pour pouvoir réactiver la sécurité PCI d’un Point d’Acceptation CB

préalablement piégé

PHY_PIE-04 Accéder à des composants de Systèmes d’Acceptation CB (cartes

mères, terminaux entiers) destinés à être réformés, pour pouvoir

récupérer des éléments de paramétrage réels permettant de refaire

fonctionner des terminaux officiels ou de tester des moyens de

contournement de la sécurité PCI

4.2 Menaces logiques

LOG_MOD-01 Modifier le paramétrage d’un Système d’Acceptation CB pour

provoquer une télécollecte sur un serveur pirate

LOG_MOD-02 Modifier le paramétrage d’un Système d’Acceptation CB pour

provoquer une mise à jour sur un serveur TMS pirate chargeant un

logiciel obsolète/vulnérable

LOG_SUB-01 Substituer un des logiciels destinés à être installés dans un Système

d’Acceptation CB par un autre piégé ou obsolète/vulnérable (stockés

localement ou dans un TMS)

LOG_SUB-02 Substituer dans un Point d’Acceptation CB (via une clé USB, le port

série RS-232, etc.) un logiciel installé par un autre piégé ou

obsolète/vulnérable

LOG_VLN-01 Exploiter à distance une faille de sécurité d’un logiciel installé dans un

Système d’Acceptation CB (par exemple via IP ou GPRS)





LOG_PIE-01 Piéger les codes sources d'un des logiciels destinés à être installés

dans un Système d’Acceptation CB (ajout d'une fonction de capture

piste magnétique/données porteur ou désactivation de la sécurité PCI,

par exemple)

LOG_PIE-02 Voler les cartes/outils de signature logicielle fournis par le fabricant,

pour pouvoir signer les logiciels destinés à être installés dans un

Système d’Acceptation CB





5 CONTRÔLE DU STATUT D’AGRÉMENT CB

5.1 Schéma du cycle de vie

Figure 3 : cycle de vie d'un Système d'Acceptation CB

Le document « Nouveau mode d’agrément et de gestion des systèmes d’acceptation CB »

[5] décrit chaque étape de ce cycle de vie et les obligations générales associées. On

précise dans ce chapitre les règles pour les opérations sur chaque étape du cycle de vie.

5.2 Statut entre « Fin de commercialisation / déploiement » et « Fin de vie »

Si le statut de fin de commercialisation est dépassé (certificat PCI PTS échu), cela

signifie que le Système d’acceptation n’est plus commercialisable, et aucun contrat ne

peut être signé par le Constructeur, l’un de ses Distributeur/Revendeurs ou bien un

Intégrateur. De même, le Système d’Acceptation ne peut plus être déployé. Une fois cette

date dépassée, le Point d’Acceptation CB peut :

- Être maintenu/réparé en l’état ou remplacé par un modèle identique,

- Être mis à jour dans une version logicielle ayant un agrément à jour ;

- Être mis au rebut.

Durant cette phase, les opérations de retraits progressifs doivent être encouragées.

5.3 Statut à « Fin de vie »

Tout Point d’Acceptation CB en fin de vie ne peut plus être maintenu et doit être mis au

rebut. CB a prévu des mesures incitatives (cf. document [5]) afin d’éviter le maintien sur

le terrain de versions de Systèmes d’Acceptation obsolètes d’un point de vue sécuritaire.





5.4 Responsabilités

Statut Métiers

Fin de commercialisation Constructeurs, Distributeurs / Revendeurs, Intégrateur

Entre fin de déploiement

et fin de vie

Constructeur, Intégrateur, Préparateur, Distributeurs / Revendeurs,

Accepteur, Acquéreur

Fin de vie Tous les acteurs sont concernés par ce contrôle.

5.5 Obligations pour les professionnels de l’acceptation

Le dispositif de contrôle permanent du professionnel de l’acceptation (cf. exigence

EXI_COM_72) doit inclure des dispositions relatives à la vérification de la conformité

des Systèmes d’Acceptation CB gérés, de leur configuration et de leurs logiciels

embarqués vis-à-vis de l’agrément CB.

En particulier, toute installation d’un Système d’Acceptation CB dont le statut de

l’agrément est à « fin de commercialisation/déploiement » doit être signalée au

demandeur de la prestation ainsi qu'au Groupement des Cartes Bancaires CB via le

formulaire défini en Annexe 2 (sauf échange standard en cas de panne). De même, pour

toute opération de maintenance apportée sur un Système d’Acceptation CB dont le statut

de l’agrément CB est à « fin de vie ». Ce Système d’Acceptation CB doit alors au plus

vite être remplacé par un Système d’Acceptation CB à jour vis-à-vis de son agrément.





6 ZONES DE SÉCURITÉ

Le présent paragraphe décrit les différents types de zones d’activités définis par le GCB

pour le référentiel de labélisation.

Les activités et exigences de sécurité associées sont précisées dans les chapitres sur les

exigences.

À noter, que l’on distingue les organismes dont l’activité principale est la gestion des

Systèmes d’Acceptation CB ou des Serveurs de Monétique Répartie de ceux dont ce n’est

qu’un élément d’ensemble.

6.1 Schématisation

Les paragraphes suivants donnent des exemples de configuration possibles. Tous les

contextes ne sont pas représentés.

Zone Rouge Salle très sensible

dédiée

Zones Orange Salle sensible

dédiée

Zone verte Accès contrôlé

Zone Blanche Espace privé

extérieur

Zone Jaune Accès contrôlé

restreint

Contrôle d’accès restreint

Contrôle d’accès

Contrôle d’accès restreint à double facteur

Légende





6.1.1 ZONES POUR ACTEURS DONT LES ACTIVITÉS MONÉTIQUES SONT MUTUALISÉES AVEC

D’AUTRES ACTIVITÉS

Ce paragraphe donne des exemples d’organisation des zones physiques pour les organismes

multi-activités.

Figure 4 : Exemple 1 de configuration pour un Développeur

Figure 5 : Exemple de configuration pour un Constructeur

Activité de développement

Activité de recette

Local technique (serveurs, etc.)

Couloir d’accès

Zone de stockage des outils de signature

logiciels

Fabrication des PA CB

Préparation des outils de

réactivation de la sécurité PCI


Couloir d’accès

PKI d’authentification des PA CB

Quai de livraison des composants





Figure 6 : Exemple de configuration pour un Intégrateur

Figure 7 : Exemple 1 de configuration pour un Préparateur

Quai de livraison

Zone de stockage des PA CB non intégrés

Zone d’intégration

Zone de transit des PA CB non intégrés ou non


Couloir d’accès

Coffre

Zone de stockage des composants non intégrés

Zone de stockage des PA CB non préparés

Quai de livraison

Zone de préparation des PA CB

Zone de stockage des PA CB préparés

Stockage des outils d’activation







Quai de livraison


Zone de stockage divers

Zone de préparation Zone de

stockage des PA CB préparés

Stockage des outils d’activation

Quai de livraison



Zone de stockage divers

Zone de préparation

SAS





Figure 10 : Maintenance de PA CB

Figure 11 : Mise au rebut de PA CB

Quai de livraison

Activité de support

Zone de réactivation de la sécurité PCI

Outils de réactivation

PA non réparés

PA réparés

Local technique et localisation de

l’outil de suivi des réparations

Activité de démontage

Quai de livraison

Activité de destruction

Stockage de PA non détruit

Stockage de composants non sensibles

Stockage de composants

sensibles





6.1.2 ZONES POUR ACTEURS DONT L’ACTIVITÉ EST DÉDIÉE À LA MONÉTIQUE

Ce paragraphe donne des exemples d’organisation des zones physiques pour les organismes

mono-activité.


Figure 13 : Exemple 2 de configuration pour un Développeur


Quai de livraison


Zone de préparation des

PA CB

Coffre

Activité de recette

Quai de livraison


Couloir d’accès

Activité de développement

Zone de stockage des outils de signature

logiciels





7 EXIGENCES DE SÉCURITÉ

Les exigences de sécurité ci-dessous doivent permettre d’assurer la couverture des risques

sécuritaires considérés. Cela concerne notamment les risques de compromission de

masse.

Pour détecter une compromission de masse, une implication de l’ensemble des acteurs

intervenant dans le cycle de vie des Points d’Acceptation CB et des Serveurs de

Monétique Répartie est nécessaire.

Cela consiste notamment à :

- Assurer une traçabilité de bout en bout des actions de gestion des PA et des

Serveurs de Monétique Répartie ;

- Maîtriser les inventaires, les stocks et le suivi des PA et des Serveurs de Monétique

Répartie ;

- Mettre en place des procédures de contrôles du respect des règles de sécurité ;

- Mettre en place des procédures de détection d’atteinte à l’intégrité physique et

logicielle des PA et des Serveurs de Monétique Répartie.

L’ensemble de ces points se retrouvent dans chacune des activités couvertes par le

référentiel de labélisation.

Pour chaque exigence applicable, l’organisme doit disposer de documentations

ou de preuves (dispositif de sécurité, compte-rendu, PV, registre papier,

configuration d’équipement, trace informatique…) démontrant la couverture de

celle-ci. Ces éléments devront être consultables par l’auditeur chargé d’évaluer

la conformité de l’organisme par rapport au présent référentiel d’exigence.

Nota : D’une manière générale, un organisme qui disposerait déjà de certifications

sécuritaires sur son environnement et ses processus métiers (comme par exemple

une certification PCI-DSS [13]) pourra faire valoir les certificats associés afin que

les résultats soient réutilisés, s’il démontre, par exemple par la consultation du

Report Of Compliance (ROC) correspondant, que le périmètre concerné est le

même et que les exigences couvertes sont de même nature.

Précisions

Les exigences encadrant le stockage sont définies au niveau du métier Stockeur.

Les exigences encadrant le transport et l’expédition sont définies au niveau du métier

Distributeur.

Dans le présent chapitre, certaines exigences différencient les acteurs multi-activités et

mono activité et modèrent alors les contraintes pour ces derniers. Par activité est entendu

« métier de l’acceptation » tel que défini au chapitre 3. Un acteur multi-activités est donc

un organisme cumulant plusieurs « métiers ».

Le terme « organisme » est un nom générique qui désigne l’entité juridique soumise aux

exigences pour le métier visé (exemple l’organisme du paragraphe 7.2 est le

Développeur).





Application des exigences : celles-ci s’appliquent aux différents organismes selon leurs

activités. Ils doivent se référer aux chapitres les concernant.

Tout organisme faisant appel à de la sous-traitance doit reporter contractuellement les

exigences qui leurs sont applicables et s’assurer de leur respect selon les modalités

définies en début de paragraphe 7.9.1





7.1 Constructeur

EXI_CONS_1 La réception, sur le site de production, des composants électroniques

de sécurité (des ASIC, par exemple), intervenant dans la fabrication

d’un Système d'Acceptation CB et contenant les secrets initiaux du

constructeur (par exemple, la clé publique du constructeur), doit être

tracée et ces derniers doivent être inventoriés précisément (Numéro

série, date/heure d'entrée en stock, date/heure de sortie du stock).

EXI_CONS_2 L'organisme doit faire signer, sur le site d’assemblage, un engagement

personnel de confidentialité par tous les opérateurs responsables du

chargement des secrets initiaux d’un Point d’Acceptation autonome

CB.

EXI_CONS_3 Lors de la fabrication d'un Système d'acceptation, un numéro de série

unique doit être intégré au Système d'Acception CB.

EXI_CONS_4 Un inventaire précis des Points d'Acceptation CB en construction doit

être tenu à jour. Celui-ci doit spécifier le numéro de série du terminal,

le type de terminal et le statut de son agrément CB. Il doit préciser

pour chaque appareil son statut (en cours de construction, en stock,

expédié, etc.)

EXI_CONS_5 La fabrication des Points d’Acceptation doit être réalisée au minimum

dans une zone « Jaune » pour les organismes dont l'activité est

principalement dédiée à la fabrication de Points d’Acceptation. A

minima en zone « Orange » pour les autres organismes.

EXI_CONS_6 Avant tout envoi d’un Point d’Acceptation CB pour Intégration,

celui-ci doit faire l’objet d’un contrôle de son statut d’agrément CB.

Suivant le statut du Système d’Acceptation, les mesures adéquates

doivent être appliquées (voir le chapitre 5 Contrôle du statut

d’agrément CB).

EXI_CONS_7 Le but de l'authentification d'un Système d'Acceptation CB est de

garantir l’origine de l’équipement appelant afin d’établir

préalablement un canal entre machines de confiance. Le certificat est

donc le reflet de la confiance accordée au constructeur sur la base de

son agrément.

À ce titre, en cas de mise en œuvre d'un mécanisme d'authentification

des Points d'Acceptation CB, le constructeur a la possibilité de générer

des certificats pour chaque machine de la gamme d’équipement ou la

configuration agréée. Le constructeur peut intervenir en tant

qu’autorité de certification vis-à-vis de ses propres produits auquel cas

il doit se conformer aux exigences CB [7]/[10].





Chaque équipement ou configuration dispose d’un numéro de série

unique par constructeur. Les clés publiques sont fournies par un

certificat conforme aux exigences CB [7]/[10]. Les serveurs

hébergeant la PKI du constructeur doivent être situés au minimum

dans une zone « Rouge »

EXI_CONS_8 En cas de mise en œuvre d'un mécanisme d'authentification des Points

d'Acceptation CB, les certificats client, générés par le constructeur et

utilisés pour authentifier les Points d’Acceptation CB, doivent

répondre aux caractéristiques cryptographiques minimales définies

dans les exigences CB [7]/[10].

EXI_CONS_9 La préparation des Outils de réactivation PCI d’un Système

d'Acceptation CB doit être réalisée au minimum dans une zone

« Orange ».

EXI_CONS_10 Le Constructeur ne doit délivrer ces Outils de réactivation PCI qu’à

des prestataires ou sous-traitants ayant signé un accord de

confidentialité avec lui, et ayant été jugés aptes par le Constructeur à

utiliser et traiter ces outils comme des éléments critiques du Système

d’acceptation, avec le niveau de protection approprié. Le recours par

le Constructeur à un prestataire de l’acceptation “Labélisé CB” pour le

service de maintenance des Points d’Acceptation satisfait de fait cette

obligation.

EXI_CONS_11 L’organisme doit mettre à disposition des centres de réparation, un

guide utilisateur des Outils de réactivation PCI d’un Système

d'Acceptation CB décrivant les outils nécessaires, leur mode

opératoire et les mesures de sécurité à mettre en place pour la

réactivation d’un Système d'Acceptation.

EXI_CONS_12 L’expédition à destination des centres de réparation, ou l’installation

directement chez eux, des outils de réactivation d’un Point

d’acceptation CB doit être sécurisée et tracée et ces derniers doivent

être inventoriés précisément.





7.2 Développeur

Ce chapitre encadre le développement de tout type de logiciel intervenant dans la gestion

des Points d’Acceptation, des Systèmes d’Acceptation et des Serveurs de Monétique

Répartie.

EXI_DEV_1 L'organisme doit avoir une liste à jour des applications dédiées à la

monétique et aux Systèmes d’Acceptation CB.

EXI_DEV_2 L'accès au code source du logiciel d'un Système d'Acceptation CB ou

d'un Serveur de Monétique Répartie doit être réservé aux seuls

contractants ayant le besoin d'en connaître.

Le dépôt des codes sources des logiciels destinés à être embarqués

dans un Système d'Acceptation CB ou dans un Serveur de Monétique

Répartie doit être réalisé sur des serveurs hébergés au minimum dans

une zone « Orange ». Cela concerne aussi bien le serveur physique

que le serveur de virtualisation exécutant la machine virtuelle

correspondante.

EXI_DEV_3 Une procédure de gestion des sauvegardes et de l'archivage des codes

sources des logiciels de Systèmes d'Acceptation CB et des Serveurs de

Monétique Répartie doit être implémentée et appliquée.

Ces sauvegardes doivent être conservées, au minimum dans des zones

« Orange ».

EXI_DEV_4 Le développement des logiciels destinés à être embarqués dans un

Système d’Acceptation CB, c’est-à-dire les micro-logiciels

(firmware), les chargeurs d'amorçage (bootloader), les logiciels

systèmes (Systèmes d’Exploitation et module EMV) et les Logiciels

Monétiques français (applications agréées CB), etc. doit être réalisé au

sein des locaux de l’organisme.

A minima en zone « Jaune », pour les organismes dont l'activité est

principalement dédiée au développement des logiciels des Systèmes

d'Acceptation CB ou des Logiciels Monétiques. A minima en zone

« Orange » pour les autres organismes.

EXI_DEV_5 L’organisme doit implémenter sur les Systèmes d’Acceptation CB les

mécanismes de sécurité nécessaires à l’établissement d’un canal de

communication entre machines de confiance (voir les exigences CB

[7]/[10] pour la sécurisation des canaux de communication).

EXI_DEV_6 Toute évolution du logiciel d'un Système d'Acceptation CB ou d'un

Serveur de Monétique Répartie doit faire l'objet d'un processus

incluant :

1. Une gestion des versions du logiciel ainsi que l'historique des

changements par version ;

2. Un processus de référencement (acteurs, archivage, gestion des

accès).





EXI_DEV_7 Un processus de gestion de l'intégrité du code source doit être

implémenté et prévoir :

1. Une procédure de contrôle de l'intégrité ;

2. Une procédure de gestion des incidents en cas de défaut

d'intégrité.

EXI_DEV_8 Les procédures de développement des logiciels d'acceptation doivent

prévoir l'application de règles de codage sécuritaires et la réalisation

de revues de code pour identifier d'éventuelles vulnérabilités des

logiciels.

EXI_DEV_9 Un processus de signature, incluant en particulier une description des

outils nécessaires pour signer les logiciels, doit être défini et appliqué

à toute version d’un logiciel d’acceptation

EXI_DEV_10 L’organisme doit fournir à ses clients la documentation et les moyens

leur permettant d’effectuer un contrôle des logiciels fournis pendant

leur exploitation.

EXI_DEV_11 La signature électronique des logiciels destinés à être embarqués dans

un Système d'Acceptation CB et dans un Serveur de Monétique

Répartie doit être réalisée par l’organisme sur le site de

développement dans une zone adaptée :

A minima en zone « Jaune », pour les organismes dont

l'activité est principalement dédiée au développement des

logiciels des Systèmes d'Acceptation CB ou des Logiciels

Monétiques.

A minima en zone « Orange » pour les autres organismes.

EXI_DEV_12 Les outils de signature électronique des logiciels destinés à être

embarqués dans un Point d'Acceptation CB et dans un Serveur de

Monétique Répartie doivent être stockés au minimum en zone

« Orange ». Les secrets doivent être conservés en zone « Rouge ».

EXI_DEV_13 La recette fonctionnelle et sécuritaire des logiciels destinés à être

embarqués dans un Système d'Acceptation CB, c’est-à-dire les

micro-logiciels (firmware), les chargeurs d'amorçage (bootloader), les

logiciels systèmes (Systèmes d’Exploitation et module EMV) et les

Logiciels Monétiques français (applications agréées CB), doit être

réalisée par l’organisme sur le site de développement dans une zone

« Jaune », au minimum.

Si le développement est réalisé en zone « jaune » (voir EXI_DEV_4),

les zones peuvent être mutualisées. Dans ce cas de figure, les

environnements techniques doivent être séparés (logiquement ou

physiquement).





EXI_DEV_14 L'organisme en charge du développement doit respecter le principe de

séparation des tâches. C’est-à-dire que ce ne sont pas les mêmes

contractants qui développent, réalisent la recette et les activités de

support d'exploitation (lorsque ce service est fourni par l'organisme en

question, est entendu par support toute activité d’aide à l’installation et

au support sur incidents).

EXI_DEV_15 Un processus de gestion du secret doit être implémenté et prévoir :

1. Une gestion des accès aux secrets ;

2. Un respect du principe de contrôle mutuel et de connaissance

répartie ;

3. Un processus régulier de renouvellement des secrets (tous les

deux ans) ;

4. Une gestion de l'archivage des secrets (stockage, accès).

EXI_DEV_16 La procédure de gestion des accès aux secrets doit, au minimum :

1. Identifier la liste des personnes strictement habilitées ;

2. Tracer les accès ;

3. Prévoir une revue annuelle des droits d'accès.

EXI_DEV_17 L'archivage des secrets doit respecter les règles suivantes :

1. Être hébergé sur un espace de stockage interne à l'organisme et

propriété de celui-ci ;

2. Être accessible selon les règles prévues par la procédure de

gestion des accès

3. Les données doivent être chiffrées (l'algorithme symétrique

utilisé pour le chiffrement est défini dans les exigences CB

[7]/[10]).

4. Durée de stockage : 6 mois.

EXI_DEV_18 Un processus de gestion de l'intégrité des secrets doit être implémenté

et prévoir :

1. Une procédure de contrôle de l'intégrité ;


d'intégrité.

EXI_DEV_19 En cas de défaut d'intégrité des secrets, une procédure de gestion des

incidents doit être appliquée et prévoir :

1. Une identification des acteurs intervenant dans la gestion des

incidents ;

2. Une gestion des alertes ;

3. Une procédure de recherche des causes et des origines de

l’incident ;

4. Une procédure de remontée d’information auprès du GIE CB,

notamment en cas de suspicion de fraude, selon la procédure

décrite à l’Annexe 2 ;

5. Un archivage des incidents.





7.3 Intégrateur

Ce paragraphe présente les exigences propres aux Intégrateurs.

EXI_INT_1 Les micro-logiciels (firmware) et les chargeurs d'amorçage

(bootloader), à intégrer dans un Point d’Acceptation autonomes CB

lors de son assemblage, doivent être récupérés de manière sécurisée,

c’est-à-dire en garantissant leur intégrité, leur authenticité et leur

confidentialité.

EXI_INT_2 Lors de la phase d’intégration d'un Système d'Acceptation CB, un

processus de chargement des logiciels et des secrets doit être établi.

Les acteurs de ce processus doivent être identifiés, leurs rôles et

responsabilités précisés.

EXI_INT_3 Lors de la phase d’intégration d’un Système d’Acceptation, un

processus de récupération des versions référencées des logiciels à

charger doit être mis en place. Les acteurs de ce processus doivent être

identifiés, ainsi que leurs rôles et responsabilités.

EXI_INT_4 Dans le cadre du processus de récupération des versions référencées

des logiciels, un processus de gestion de l'intégrité des secrets doit être


1. Une procédure de contrôle de l'intégrité (acteurs, moyens) ;


d'intégrité (acteurs, moyens).

EXI_INT_5 L’organisme doit réaliser le téléchargement des logiciels systèmes

(Système d’Exploitation et module EMV) et/ou des Logiciels

Monétiques (applications agréées CB) nécessaires dans un Système

d'Acceptation CB depuis un système hébergé au minimum dans une

zone « Orange ».

EXI_INT_6 L’organisme doit garantir l’intégrité, l’authenticité et la confidentialité

de ses logiciels systèmes et de ses Logiciels Monétiques, lors de leur

conservation et les stocker sur un serveur hébergé en zone « Orange ».

EXI_INT_7 Lors de la phase d’intégration d'un Système d'Acceptation CB, un

processus de récupération des secrets (signature, réactivation) doit être


1. Une procédure de contrôle de l'intégrité (acteurs, moyens) ;


d'intégrité (acteurs, moyens).





EXI_INT_8 Après intégration, un processus de contrôle de conformité de logiciel

d'un Système d'Acceptation CB doit être formalisé et prévoir :

1. Une procédure de contrôle des versions de logiciels et des

secrets (acteurs, moyens) ;

2. Une gestion des traces des contrôles de conformité logicielle.

EXI_INT_9 En cas de défaut de conformité ou d'intégrité logicielle, une procédure

de gestion des incidents doit être appliquée et prévoir :


incidents ;



l’incident ;

4. Un contrôle par échantillonnage de la série ;





EXI_INT_10 Un inventaire précis des Points d'Acceptation CB en cours

d'intégration doit être tenu à jour. Celui-ci doit spécifier le numéro de

série du terminal, le type de terminal, le statut de son agrément CB, et

le détail des versions des logiciels installés. Il doit préciser pour

chaque appareil son statut (en cours d'intégration, en stock, expédié,

etc.).

Pour les versions logicielles détaillées, un niveau de détail similaire à

ce qui est fourni dans les « approval files » ou les fiches « ID CB » est

attendu (composants logiciels, checksums).

EXI_INT_11 En cas de mise en œuvre d'un mécanisme d'authentification des Points

d'Acceptation CB, la clé privée est installée par l'intégrateur lors de

l'intégration.

EXI_INT_12 Seules les personnes habilitées par l'intégrateur peuvent avoir à gérer

la clé privée. Celle-ci doit rester confidentielle, notamment vis-à-vis

de l'accepteur, des porteurs et de toute personne non habilitée par le

constructeur à intervenir sur le Système d'Acceptation. Dans tous les

cas, la confidentialité des clés privées doit être assurée. Elles ne sont

ni exportables du Système d'Acceptation ni consultables.

EXI_INT_13 Le certificat de l'autorité de certification du constructeur est obtenu

auprès de celui-ci. Les clés publiques sont fournies par un certificat

conforme aux exigences CB [7]/[10].





EXI_INT_14 L’utilisation d’un certificat serveur requiert au préalable la vérification

de sa validité avec une vérification cryptographique de la signature, de

la date de début et de fin de validité et des champs critiques du

certificat.

Les algorithmes symétriques utilisables pour le chiffrement de la clé

de session sont définis dans les exigences CB [7]/[10].

Si une liste de révocation des certificats est disponible, celle-ci est

consultée au moins quotidiennement. En cas d’échec de la

vérification, le certificat n’est pas utilisé et la connexion terminée.





7.4 Préparateur

Ce paragraphe présente les exigences propres aux préparateurs.

EXI_PREP_1 Une procédure de préparation, avant distribution des logiciels de

Points d’Acceptation CB doit être implémentée et appliquée. Celle-ci

doit :

1. Identifier les moyens dédiés à cette préparation ;

2. Identifier les moyens de récupération des versions des logiciels

référencés à charger ;

3. Identifier les moyens de contrôle de l'intégrité des logiciels à

charger ;

4. Identifier les acteurs en charge de la préparation.

EXI_PREP_2 Un processus d'installation des Points d'Acceptation CB doit être

formalisé. Les acteurs sont identifiés et des moyens de contrôle de leur

identité sont prévus.

EXI_PREP_3 L’organisme doit rédiger une documentation d'installation des Points

d'Acceptation CB. Celle-ci doit informer l’accepteur de la date de fin

de vie du Point d’Acceptation CB.

Pour ce faire, l'insertion d'une référence au site du GIE CB est

recommandée pour permettre à l’accepteur d'identifier la date de fin

de vie du matériel sans erreur possible.

EXI_PREP_4 La procédure d'installation des Points d'Acceptation CB doit

également décrire les moyens d'assistance mis à disposition des

accepteurs (installation sur site, support téléphonique, etc.).

EXI_PREP_5 Des procédures de contrôle de l'intégrité physique des Points

d'Acceptation CB doivent être implémentées et appliquées sur

l'ensemble de la chaîne d'installation du matériel (mise en service,

initialisation, déploiement).





EXI_PREP_6 Lors de la procédure d'installation d'un Point d’acceptation CB, en cas

de défaut d'intégrité physique, une procédure de gestion des incidents

doit être appliquée et prévoir :


incidents ;



l’incident ;

4. Un contrôle par échantillonnage du stock ;





EXI_PREP_7 Un inventaire précis des Points d'Acceptation CB en cours de

préparation doit être tenu à jour. Celui-ci doit spécifier le numéro de

série du terminal, le type de terminal, le statut de son agrément CB et

le détail des versions des logiciels installés. Il doit préciser pour

chaque appareil son statut (en cours de préparation en stock, expédié,

etc.)

EXI_PREP_8 Avant toute utilisation d’un Point d’Acceptation, un certificat racine

d’autorité de certification est chargé :

1. Soit par l’intégrateur du Système d’Acceptation ;

2. Soit par le préparateur dans une phase de personnalisation du

Système d’Acceptation.

Plusieurs certificats racines d’autorités de certification peuvent être

installés dans une seule machine. Les certificats pourront être obtenus

auprès des autorités de certification correspondantes. Si nécessaire, le

renouvellement des certificats racines peut se faire lors d’un retour en

maintenance.

Dans un but de traçabilité, la liste des clés publiques installées doit

être consultable.

EXI_PREP_9 Pour les organismes dont l'activité de gestion des Systèmes

d'Acceptation CB ou de Serveurs de Monétique Répartie est

mutualisée avec d'autres activités, la préparation des Points

d’Acceptation doit être effectuée en zone « Orange », au minimum.

Pour les organismes dont la gestion de Systèmes d'Acceptation CB ou

de Serveurs de Monétique Répartie est la principale activité, la

Préparation des Points d’Acceptation doit être effectuée en zone

« Jaune » au minimum.





7.5 Mainteneur

Ce paragraphe présente les exigences propres aux mainteneurs.

On distingue des exigences générales, propres à l’ensemble des étapes de la maintenance

et des exigences dédiées à la maintenance de niveau 2 et à la mise au rebut.

7.5.1 GÉNÉRALE

EXI_MAIN_1 Un processus de réparation d’un Point d’Acceptation CB et d'un

Serveur de Monétique Répartie doit être implémenté. Celui-ci doit :

1. Identifier les acteurs (externes ou internes) intervenant dans le

processus et leurs responsabilités ;

2. Lister les moyens utilisés pour réaliser cette opération de

maintenance ;

3. Vérifier que toute opération de maintenance monétique sur un

Point d’Acceptation CB ou d'un Serveur de Monétique

Répartie est tracée, en identifiant au minimum le mainteneur,

la date et la nature de l’opération de maintenance effectuée ;

4. Identifier si la journalisation des opérations de maintenance est

effectuée par un processus automatique ou manuel ;

EXI_MAIN_2 Les traces de toutes les opérations de maintenance monétique sur un

Point d’Acceptation CB ou d'un Serveur de Monétique Répartie

doivent être consultables a posteriori.

EXI_MAIN_3 Un inventaire précis des Points d'Acceptation CB en cours de

maintenance doit être tenu à jour. Celui-ci doit spécifier le numéro de

série du terminal, le type de terminal, le statut de son agrément CB et

les références de l'accepteur (société, adresse, téléphone).

EXI_MAIN_4 Avant toute action de support téléphonique, le mainteneur doit

demander au commerçant le numéro de série du Point d’Acceptation

CB.

EXI_MAIN_5 L'organisme doit faire signer un engagement personnel de

confidentialité par tous les opérateurs responsables de la réactivation

de la sécurité d'un Point d'Acceptation CB.

7.5.2 MAINTENANCE DE NIVEAU 2

EXI_MAIN_6 Toute intervention de niveau 2 doit être initiée par le passage d’une

carte « mainteneur » ou par tout autre moyen fourni par l’industriel.

EXI_MAIN_7 Une procédure de contrôle du numéro de version du logiciel d'un

Point d'Acceptation CB doit être implémentée et être effectuée en

maintenance de niveau 2.

EXI_MAIN_8 Les Points d'Acceptation CB et les Serveurs de Monétique Répartie

doivent avoir la version la plus récente du logiciel du fabricant

conformément aux contrats signés avec leurs clients.





EXI_MAIN_9 Le contrat avec l’organisme ayant développé les logiciels ou distribué

le Point d’Acceptation CB doit prévoir :

1. Un service de maintien en condition opérationnelle des

logiciels ;

2. La mise à disposition de la documentation et des moyens

permettant d’effectuer le contrôle de l’intégrité des logiciels.

EXI_MAIN_10 Lors du contrôle du numéro de version du logiciel d'un Système

d'Acceptation CB ou du logiciel de Serveur de Monétique Répartie, en

cas de détection d’une régression logicielle, une procédure de gestion

d'incidents doit être appliquée et prévoir :


incidents ;



l’incident ;






EXI_MAIN_11 Un processus de télé-mise à jour d’un Point d’Acceptation CB doit

être formalisé. Les acteurs sont identifiés et les moyens pour réaliser

la télé-mise à jour sont prévus.

EXI_MAIN_12 Les moyens permettant la télé-mise à jour d'un Point d'Acceptation

CB en cours d'exploitation, à la suite de l'opération de

télécollecte/télé-paramétrage de celui-ci, doivent être identifiés.

EXI_MAIN_13 Une procédure de récupération des versions référencées des logiciels à

charger lors de la télé-mise à jour d’un Point d’Acceptation CB ou de

la mise à jour d'un logiciel de Serveur de Monétique Répartie doit être

implémentée. Celle-ci doit :

1. Identifier les moyens utilisés (serveurs, réseaux, etc.) pour la

récupération des versions référencées des logiciels à charger ;

2. Identifier comment est contrôlée l'intégrité de ces versions

référencées ;

3. Identifier les acteurs (externes ou internes) ayant accès à ces

versions récupérées.

EXI_MAIN_14 Un contrôle de l’intégrité logicielle des Points d’Acceptation CB doit

être effectué en maintenance de niveau 2.





EXI_MAIN_15 Lors du contrôle des versions du logiciel d'un Système d'Acceptation

CB ou d'un Serveur de Monétique Répartie, en cas de détection d’une

compromission des versions référencées des logiciels, une procédure

de gestion des incidents doit être appliquée et prévoir :


incidents ;



l’incident ;






EXI_MAIN_16 L’organisme doit tenir à jour une main courante (ou un journal

informatique) de toutes les réactivations réalisées, contenant la date et

l’heure de la réactivation, le nom ou l’identifiant des deux opérateurs

présents et le numéro de série du Point d’Acceptation CB réactivé.

EXI_MAIN_17 L’outil de suivi des réparations des Points d'Acceptation CB doit être

installé sur un serveur hébergé (le serveur physique ou le serveur de

virtualisation exécutant la machine virtuelle correspondante) au

minimum dans une zone « Orange ».

EXI_MAIN_18 Toute maintenance incluant un démontage d'un Point d’Acceptation

CB doit faire l'objet d'un processus de réactivation du dit Système.

EXI_MAIN_19 Dans le cadre des procédures de réactivation d'un Point d’Acceptation

CB, un processus de gestion du secret doit être implémenté et prévoir :

1. Une gestion des accès aux secrets ;

2. Un respect du principe de contrôle mutuel et de connaissance

répartie ;

3. Un processus de renouvellement des secrets ;

4. Une gestion de l'archivage des secrets (stockage, accès).

EXI_MAIN_20 Dans le cadre des procédures de réactivation d'un Point d’Acceptation

CB, un processus de gestion de l'intégrité des secrets doit être


1. Une procédure de contrôle de l'intégrité physique ;


d'intégrité.





EXI_MAIN_21 Lors d’un contrôle de niveau 2, l’intégrité physique d’un Point

d’Acceptation CB doit être vérifiée avant sa réparation. Un contrôle

sur le statut d'agrément CB du Système d’Acceptation doit également

être formalisé, suivant le statut du Système d’Acceptation, les mesures

adéquates doivent être appliquées (voir le chapitre 5 Contrôle du

statut d’agrément CB).

EXI_MAIN_22 Une procédure de gestion des incidents doit être appliquée en cas de

détection d’une compromission physique lors de la réparation d'un

Point d’Acceptation ou d'un Serveur de Monétique Répartie. Cette

procédure doit prévoir :


incidents ;



l’incident ;





6. Un archivage des incidents

EXI_MAIN_23 Les outils utilisés pour la Réactivation d’un Point d’Acceptation CB

doivent être protégés. Les acteurs ayant accès aux outils doivent être

identifiés, le principe de contrôle mutuel et de connaissance répartie

est appliqué à la conservation et à l'utilisation de ces outils. Ces outils

sont stockés en zone « Rouge ».

EXI_MAIN_24 Pour les organismes dont l'activité de gestion des Systèmes


mutualisée avec d'autres activités, la réactivation de la sécurité d'un

Point d'Acceptation CB doit être réalisée uniquement dans une zone

« Orange ».

Pour les organismes dont l'activité de gestion des Systèmes

d'Acceptation CB ou de Serveurs de Monétique Répartie est la

principale activité, la réactivation de la sécurité d'un Point

d'Acceptation CB doit être réalisée uniquement dans une zone

« Jaune ».

EXI_MAIN_25 L’organisme doit appliquer le guide utilisateur fourni par le

constructeur, décrivant les outils nécessaires pour la réactivation d'un

Point d'Acceptation CB, leur mode opératoire et les mesures de

sécurité à mettre en place.





EXI_MAIN_26 Lors d'une intervention de niveau 2 :

1. Toute sortie des outils doit être tracée et réalisée selon le

principe de contrôle mutuel. Les outils sont alors placés sous la

responsabilité d'un opérateur désigné nominativement et

habilité ;

2. Les opérateurs utilisant des outils de réactivation PCI à

l’extérieur des locaux de l’organisme doivent être clairement

identifiés et dûment habilités (voir notamment

EXI_COM_84) ;

3. Les outils doivent être remis en zone « Rouge » (après chaque

utilisation en fin de journée).

EXI_MAIN_27 En cas de détection d’une compromission des outils utilisés pour la

réactivation d'un Point d’Acceptation, une procédure de gestion

d'incident doit être appliquée. Les acteurs doivent être identifiés, le

processus de sensibilisation et de formation des personnels impliqués

dans la réparation des Points d’Acceptation CB doit être contrôlé.

EXI_MAIN_28 Lors de la réactivation d'un Point d’Acceptation, en cas de détection

d’une compromission physique ou d'un défaut d'intégrité des outils de

réactivation PCI, une procédure de gestion des incidents doit être

appliquée et prévoir :


incidents ;



l’incident ;






7.5.3 MISE AU REBUT, RECYCLAGE

Les exigences ci-dessous font référence au processus de destruction, elles s’appliquent

également dans le cadre d’un recyclage de composant.

EXI_MAIN_29 En cas d'impossibilité de réparation d’un point d’Acceptation CB ou

du Serveur de Monétique Répartie, le mainteneur doit notifier le

constructeur de la mise au rebut du matériel. Le matériel à détruire

doit alors être mis sous scellé et livré selon les exigences propres aux

activités de livraison.





EXI_MAIN_30 Un processus de mise au rebut d’un Point d’Acceptation CB ou d'un

Serveur de Monétique Répartie doit être formalisé. Celui-ci doit :

1. Identifier les acteurs (externes ou internes) intervenants dans le

processus et leurs responsabilités ;

2. Lister les moyens utilisés pour réaliser les opérations de mise

au rebut ;

3. Vérifier que toute opération de mise au rebut est tracée, en

identifiant au minimum le mainteneur, la date et la nature de

l’opération de mise au rebut effectuée.

4. Identifier si la journalisation des opérations de mise au rebut

est effectuée par un processus automatique ou manuel.

5. Vérifier que les traces de toutes opérations de mise au rebut

sont consultables à posteriori.

EXI_MAIN_31 Des procédures assurant la destruction de toutes les clés

cryptographiques et des codes PIN ou autres informations liées aux

PIN doivent être appliquées pour les dispositifs cryptographiques

retirés du service.

EXI_MAIN_32 L’organisme doit disposer d’un document décrivant, sur le site de

destruction, le processus de démontage d’un Point d'Acceptation CB à

détruire.

EXI_MAIN_33 L’organisme doit réaliser, sur le site de destruction, la destruction d’un

Point d'Acceptation CB au minimum dans une zone « Jaune ».

EXI_MAIN_34 L’organisme doit réaliser, sur le site de destruction, le démontage d’un

Point d'Acceptation CB à détruire au minimum dans une zone

« Jaune ».

EXI_MAIN_35 L’organisme doit conserver (sur au moins 12 mois glissants), sur le

site de destruction, le numéro de série d’un Point d'Acceptation CB

détruit, ainsi que le client concerné (société, adresse, coordonnées).

EXI_MAIN_36 L’organisme doit fournir au client concerné un certificat de

destruction pour un Point d'Acceptation CB détruit comportant son

numéro de série.

EXI_MAIN_37 L’organisme doit garantir, sur le site, que toutes les étiquettes

mentionnant le numéro de série d’un Point d'Acceptation CB sont

détruites lors de son démontage.

EXI_MAIN_38 L’organisme doit séparer des autres composants, les composants

sensibles d’un Point d'Acceptation CB, en particulier les composants

électroniques de sécurité (des ASIC, par exemple) contenant les

secrets initiaux du constructeur (par exemple, la clé publique du

constructeur).





EXI_MAIN_39 L’organisme doit réaliser, sur le site de destruction, le stockage des

composants sensibles d’un Point d'Acceptation CB au minimum dans

une zone « Orange ».

EXI_MAIN_40 L’organisme doit disposer d’un document décrivant, sur le site de

destruction, le processus de stockage des composants sensibles d’un

Système d'Acceptation CB.

EXI_MAIN_41 L’organisme doit garantir que la sortie du stock des composants

sensibles d’un Point d'Acceptation CB n’est autorisée que pour

procéder à leur destruction (aucun usage ou revente à des fins de

pièces détachées n’est autorisé).





7.6 Exploitation

Ce chapitre présente les exigences dédiées aux acteurs intervenants dans l’exploitation

des Systèmes d’Acceptation et des Serveurs de Monétique Répartie.

Cet ensemble d’exigences ne concerne pas la maintenance.

Un inventaire précis des Points d’Acceptation CB en cours EXI_EXPL_1

d'exploitation doit être tenu à jour. Celui-ci doit spécifier le numéro de

série du terminal, le type de terminal, le statut de son agrément CB, les

références de l'accepteur (société, adresse, téléphone).

Pour les versions logicielles détaillées, un niveau de détail similaire à EXI_EXPL_2

ce qui est fourni dans les « approval files » ou les fiches « ID CB » est

attendu (composants logiciels, checksums).

Chaque organisme intervenant dans la gestion de Serveur de EXI_EXPL_3

Monétique Répartie doit être en mesure de préciser, pour chaque client

(au sens contractuel du terme), les Serveurs de Monétique Répartie

qu’il gère (nominal, premier ou deuxième secours).

Un processus de télécollecte/télé-paramétrage ou de gestion des EXI_EXPL_4

fichiers de télécollecte (CB2A) d’un Système d’Acceptation CB doit

être formalisé. Les acteurs sont identifiés et les moyens pour réaliser

la télécollecte et le télé-paramétrage sont prévus.

Le certificat serveur utilisé pour authentifier les serveurs EXI_EXPL_5

informatiques impliqués dans la gestion des Systèmes d’Acceptation

CB doit avoir pour origine une autorité de certification autorisée par le

Groupement des Cartes Bancaires.

Les clés sont fournies au moyen d’un certificat conforme aux EXI_EXPL_6

exigences CB [7]/[10]. Le certificat serveur est généré et signé par

l’autorité de certification.

Les certificats serveur utilisés pour authentifier les serveurs EXI_EXPL_7


CB doivent répondre aux caractéristiques minimales décrites dans les

exigences CB [7]/[10].

La clé privée associée au certificat serveur doit être protégée en EXI_EXPL_8

confidentialité et en intégrité. Au minimum, des permissions strictes

doivent être appliquées sur les fichiers de clé. Lorsque cela est

possible, il est recommandé que la clé privée ne soit pas exportable.





L’utilisation d’un certificat serveur requiert au préalable la vérification EXI_EXPL_9

de sa validité (signature, validité, etc.). En cas d’échec de la

vérification, le certificat n’est pas utilisé et la connexion terminée.

Les algorithmes symétriques utilisables pour le chiffrement de la clé

de session sont ceux définis dans les exigences CB [7]/[10].

La clé de session servant au chiffrement des données doit être

renouvelée au minimum quotidiennement.

L’utilisation de mécanismes de reprise de session (exemple « Session

Résumée de SSL ») est autorisée. Ces mécanismes permettent

l’établissement rapide d’une session chiffrée grâce à une sauvegarde

de contexte de la session précédente.

Si une liste de révocation des certificats est disponible, celle-ci est

consultée au moins quotidiennement.

En cas de mise en œuvre d'un mécanisme d'authentification des Points EXI_EXPL_10

d'Acceptation CB, une procédure de renouvellement des clés privées

des Points d'Acceptation CB doit être implémentée.

Les communications entre les Points d’Acceptation CB et le serveur EXI_EXPL_11

d’acquisition, transitant sur un réseau public (Internet, etc.) ou radio

(Wifi, GPRS, 3G, etc.), doivent respecter les exigences de sécurité CB

[7]/[10].

Les serveurs de télécollecte sont localisés en zone « Orange ». EXI_EXPL_12

Une procédure de contrôle du numéro de version et de l’intégrité des EXI_EXPL_13

logiciels d'un Système d'Acceptation CB ou d'un Serveur de

Monétique Répartie doit être implémentée.

Le contrat avec l’organisme ayant développé les logiciels doit EXI_EXPL_14

prévoir :

1. Un service de maintien en condition opérationnelle des

logiciels ;

2. La mise à disposition de la documentation et des moyens

permettant d’effectuer le contrôle de l’intégrité des logiciels.





Lors du contrôle des versions et de l’intégrité du logiciel d'un Système EXI_EXPL_15

d'Acceptation CB ou d'un Serveur de Monétique Répartie, en cas de

détection d’une compromission des versions référencées des logiciels,

une procédure de gestion des incidents doit être appliquée et prévoir :


incidents ;



l’incident ;

4. Un contrôle par échantillonnage de la série ;





Les locaux techniques hébergeant les Serveurs de Monétique Répartie EXI_EXPL_16

doivent être des zones « Rouge ».





7.7 Stockeur/Logisticien

Ce paragraphe présente les exigences propres aux activités de gestion des stocks de

Points d’Acceptation et de Serveurs de Monétique Répartie.

Ce paragraphe ne traite pas des conditions de préparation du matériel avant envoi pour un

autre acteur intervenant dans la gestion des Points d’Acceptation et des Serveurs de

Monétique Répartie. Ce point est transverse à tous les acteurs et est intégré dans le

chapitre tronc commun.

EXI_STOCK_1 Un processus de réception et de stockage des Points d'Acceptation CB

doit être formalisé, les acteurs identifiés.

EXI_STOCK_2 Lors de la réception d’un ensemble de Points d’Acceptation :

1. Un contrôle sur le statut d'agrément CB des Systèmes

d’Acceptation doit être effectué. Suivant le statut des Systèmes

d’Acceptation, les mesures adéquates doivent être appliquées

(voir le chapitre 5 Contrôle du statut d’agrément CB).

2. Un contrôle de l’intégrité physique des Points d’Acceptation

doit être réalisé. Cela consiste à vérifier l’intégrité du scellé ou

de l’emballage en cas d’absence de scellé.

3. Un Procès-Verbal de bonne réception des Points d’Acceptation

doit être renvoyé à l’expéditeur par le destinataire si le

Distributeur ne procède pas à une traçabilité de la livraison.

EXI_STOCK_3 Le processus de réception doit prévoir une procédure de gestion

d'incident en cas de suspicion d’atteinte délibérée à l’intégrité

physique des scellés ou des emballages des PA. Celle-ci doit prévoir :


incidents ;

2. Une procédure de remontée d’alerte auprès de l’expéditeur ;





EXI_STOCK_4 Un inventaire précis des Points d'Acceptation CB stockés doit être

maintenu à jour. Il doit contenir au minimum les informations

suivantes : le nombre, le type, le numéro de série des Points

d’Acceptation CB stockés.

EXI_STOCK_5 L’outil de gestion ou d’identification du stock des Points

d'Acceptation CB doit être installé sur un serveur « Orange » hébergé

(le serveur physique ou le serveur de virtualisation exécutant la

machine virtuelle correspondante) au minimum dans une zone

« Orange ».





EXI_STOCK_6 Un processus de retrait du stock et de distribution des Points

d'Acceptation CB doit être implémenté. Les acteurs du processus

doivent être clairement identifiés.

EXI_STOCK_7 La procédure de retrait d'un Système d'Acceptation CB du stock, doit

spécifier les éléments suivants :

1. Interdiction de laisser sans surveillance un Système

d'Acceptation CB lors du retrait du stock. C’est-à-dire que

dans la phase de transit entre le stock et la destination

(exemple salle de préparation), le Point d’Acceptation doit

rester sous le contrôle d’un logisticien ;

2. La dépose et la récupération des Points d’Acceptation CB dans

les zones de stockage doivent être effectuées par des personnes

différentes. Exemple :

- Les préparateurs prennent les Points d’Acceptation CB

non préparés dans les zones de stockages dédiées,

- Les logisticiens déposent les Points d’Acceptation CB non

préparés dans les zones de stockages dédiées.

EXI_STOCK_8 Pour les organismes dont l'activité de gestion des Systèmes

d'Acceptation CB ou des Serveurs de Monétique Répartie est

mutualisée avec d'autres activités :

1. Le stockage des Points d’Acceptation CB non préparés doit

être effectué en zone « Jaune ». La zone de stockage doit être

différente de celles utilisées pour les autres activités de

l’organisme.

2. Le stockage des Points d’Acceptation CB préparés ou dédiés à

la mise au rebut doit être effectué en zone « Orange ».

3. Le stockage des composants sensibles d’un Système

d’Acceptation CB (maintenance ou cycle de destruction) doit

être effectué en zone « Orange ».

4. Les zones de stockage doivent être différentes de celles

utilisées pour les autres activités de l’organisme.

EXI_STOCK_9 Pour les organismes dont l'activité est principalement dédiée à la

gestion des Systèmes d'Acceptation CB ou des Serveurs de Monétique

Répartie, La zone de stockage des Points d’Acceptation CB est

« Jaune ». Les Points d’Acceptation doivent être séparés par statut

(Non préparés, préparés, mis au rebut).





7.8 Distributeur

Ce chapitre est dédié aux acteurs effectuant le transport des Points d’Acceptation.

Ne sont concernés que les transports de masse. Le transport d’un Point d’Acceptation

seul, par exemple lors d’un échange, n’est pas concerné.

EXI_DIST_1 Un processus de transport des Points d'Acceptation CB doit être

implémenté depuis la récupération du PA jusqu'à la livraison au

destinataire. Celui-ci doit préciser :

1. Les mesures de protection physique mises en œuvre ;

2. Les moyens mis en œuvre pour garantir la détection d'une

ouverture non autorisée de l'emballage ;

3. Les acteurs intervenant dans le processus de transport ;

4. Les conditions de livraison des cartes de domiciliation des

commerçants.

EXI_DIST_2 Lors du transport d'un Système d'Acceptation CB, celui-ci doit être

sécurisé. Des contrôles de l'intégrité des scellés ou des emballages

doivent être effectués à chaque étape du transport.

EXI_DIST_3 Lors de l’expédition, les bordereaux doivent mentionner de manière

exhaustive la liste des numéros de série des Points d'Acceptation CB

transportés. La liste doit être fournie par l’expéditeur.

EXI_DIST_4 Chaque étape du processus de livraison doit être tracée et faire l'objet

d'un PV (remise, contrôles et livraison), afin de permettre notamment

la détection d'une disparition d'un Système d’Acceptation.

EXI_DIST_5 Le processus de transport doit prévoir une procédure de gestion

d'incident en cas de disparition avérée. Celle-ci doit prévoir :


incidents ;

2. Une gestion des alertes internes et auprès de l’expéditeur ;


l’incident ;

4. Un contrôle par échantillonnage du stock transporté ;









7.9 Tronc commun

Le présent chapitre est commun à tous les acteurs impliqués dans la gestion des Systèmes

d’Acceptation CB ou des Serveurs et logiciels de monétique intégrée.

Néanmoins, il ne concerne que les périmètres participant à ces activités. Autrement dit les

périmètres isolés et ne participant pas à la gestion des Systèmes d’Acceptation CB ou des

Serveurs et logiciels de monétique intégrée ne sont pas concernés.

Dans le présent chapitre, le terme « locaux techniques » désigne les salles hébergeant les

infrastructures réseaux et serveurs. Par exemple, les espaces bureaux ne sont pas

concernés.

7.9.1 EXPÉDITION DE POINTS D’ACCEPTATION

EXI_COM_1 Avant toute expédition d’un ensemble de Point d’Acceptation,

l’organisme doit :

1. Apposer un scellé sur les emballages des Points

d’Acceptation ;

2. Fournir un inventaire électronique et papier des Points

d’Acceptation à destination de chaque destinataire.

EXI_COM_2 Toute expédition doit être effectuée dans le respect des exigences du

chapitre dédié aux Distributeurs (7.8).

7.9.2 DOMAINE D’ACTIVITÉS ET GESTION DES TIERS

EXI_COM_3 Chaque organisme participant à la gestion d’un Système

d’Acceptation CB ou d’un Serveur de Monétique Répartie doit

déclarer le type de prestation qu'il effectue (fabrication,

développement d'applications, installation, gestion de parcs,

téléparamétrage, télécollecte, télémise à jour, maintenance)


d’Acceptation CB ou d’un Serveur de Monétique Répartie doit être en

mesure de fournir pour chaque client, les types de prestations réalisées

et le mode de fonctionnement dans le cadre de la gestion des Systèmes

d’Acceptation CB.


d’Acceptation CB ou d’un Serveur de Monétique Répartie se doit de

déclarer la liste des sous-traitants auxquels il délègue une partie de sa

prestation et préciser la nature de cette délégation

EXI_COM_6 Chaque sous-traitance se doit d'être encadrée juridiquement, au

minimum par une convention de service et un accord de

confidentialité. Le cadre juridique de chaque sous-traitance doit

spécifier les responsabilités et exigences de sécurité transmises au

sous-traitant. Une clause d'audit doit également être incluse dans le

cadre juridique convenu entre les parties.





EXI_COM_7 Des audits doivent être régulièrement menés pour s'assurer que le

sous-traitant a effectivement implémenté les mesures de sécurité

nécessaires à la couverture des exigences de sécurité du contrat.

L’audit peut être fait par les dispositifs de contrôle interne de

l’organisme ou par un tiers mandaté par ce dernier.

EXI_COM_8 Chaque sous-traitant dit de « premier niveau » doit déclarer sa propre

liste des entreprises auxquelles il sous-traite une partie de sa prestation

et préciser la nature de cette délégation. Ces sous-traitants dits de

« second niveau » doivent être audités par le sous-traitant de premier

niveau.

7.9.3 PROTECTION DES LOCAUX ET DES ÉQUIPEMENTS

EXI_COM_9 Une analyse de risques doit être effectuée sur les périmètres de

sécurité concernant les matériels, postes de travail et serveurs, ainsi

que sur les équipements réseau et télécom impliqués dans la gestion

des Systèmes d’Acceptation CB et des Serveurs de Monétique

Répartie

EXI_COM_10 Une politique de sécurité physique doit être implémentée et doit :

1. Décrire l'organisation mise en place pour gérer la sécurité

physique, en particulier les groupes, les rôles et les

responsabilités des personnels impliqués dans la sécurité des

Systèmes d’Acceptation CB et des Serveurs de Monétique

Répartie durant leur cycle de vie, notamment pour la

protection des bâtiments et des locaux techniques.

2. Décrire les risques sécuritaires physiques et environnementaux

pesant sur les Systèmes d’Acceptation CB durant leur cycle de

vie, en prenant en compte la malveillance interne et externe.

EXI_COM_11 Le dispositif de sécurité physique mis en place doit être cohérent avec

l'analyse de risques.

EXI_COM_12 Les périmètres physiques protégeant les bâtiments doivent être sous

accès contrôlés, réglementés et vidéo-surveillés.

EXI_COM_13 L’organisme doit disposer des plans de masse des différents sites

intervenant dans le cadre de la gestion des Systèmes d'Acceptation CB

et des Serveurs de Monétique Répartie et leur découpage en zones de

sécurité.

EXI_COM_14 Les outils d'administration des dispositifs de sécurité physique doivent

être localisés dans un local dédié à accès restreint et disposer de

mesures de sécurité logique (antivirus, cloisonnement réseau,

verrouillage de session, etc.).





7.9.3.1 Exigences sur les zones

EXI_COM_15 Dans une zone « Verte » :

1. Les accès sont contrôlés ;

2. Les issues de secours et les quais de livraison doivent être

vidéo-surveillés en 24/7 ;

3. Les issues de secours doivent être sous alarme 24/7 ;

4. Les quais de livraison doivent être fermés, verrouillés et sous

alarme en cas de non utilisation.

EXI_COM_16 Les portes d’accès à une zone « Jaune » depuis la zone « Verte »

doivent disposer d’un contrôle d’accès restreint par badge à l’entrée,

actif 24h/24 et 7j/7.

Par restreint il est entendu que la liste de personnes autorisées à

accéder à la zone « Jaune » est plus limitée que celle de la zone

« Verte ».

EXI_COM_17 Les fenêtres facilement accessibles (rez-de-chaussée, terrasse…) de la

zone « Jaune » doivent être équipées d’un dispositif de détection

d'intrusion.

EXI_COM_18 Pour les organismes dont l'activité de gestion des Systèmes


mutualisée avec d'autres activités, l’accès à une zone « Orange » ne

doit être possible qu’après un passage dans une zone « Jaune »

minimum.

Pour les organismes dont l'activité de gestion des Systèmes


principale activité, l’accès à une zone « Orange » ne doit être possible,

au minimum, qu’après un passage dans une zone « Verte ».

EXI_COM_19 Les portes d’accès à une zone «Orange» doivent disposer d’un

contrôle d’accès restreint à l’entrée et à la sortie, actif 24h/24 et 7j/7.

Par restreint il est entendu que la liste de personnes autorisées à

accéder à la zone « Orange » est plus limitée que celle de la zone

d'accès (« Verte » ou « Jaune »).

EXI_COM_20 Les couloirs et les accès aux bureaux de la zone « Orange » doivent

être vidéo surveillés 24h/24 et 7j/7.



mutualisée avec d'autres activités, l’accès à une zone « Rouge » ne

doit être possible qu’après un passage dans une zone « Orange ».







principale activité, l’accès à une zone « Rouge » ne doit être possible,

au minimum, qu’après un passage dans une zone « Jaune ».

EXI_COM_23 Une zone « Rouge » peut être un coffre-fort : ce dernier doit donc

résister aux tentatives d’effraction. I doit être constitué d’un bloc porte

en acier, d’un vantail de plusieurs épaisseurs de tôle d’acier et de

serrures renforcées au minimum avec 3 points latéraux d’ancrage pour

résister aux tentatives d'effraction

EXI_COM_24 Si la zone « Rouge » est une salle, les portes d’accès doivent disposer

d’un contrôle d’accès restreint à double facteur à l’entrée et à la sortie,

actif 24h/24 et 7j/7 et couplé avec un système « anti-passback ». Les

portes doivent également être renforcées pour limiter les risques

d’intrusion. Par restreint il est entendu que la liste des personnes

autorisées à accéder à la zone « Rouge » est plus limitée que celle de

la zone « Orange ».

EXI_COM_25 Si la zone « Rouge » est une salle, il ne peut y avoir moins de deux

personnes dans cette zone.

EXI_COM_26 Si la zone « Rouge » est une salle, les portes d’accès cette zone

doivent être équipées d’un dispositif de temporisation d’ouverture

24h/24 et 7j/7, avec déclenchement d’alarme sonore.

EXI_COM_27 Si la zone « Rouge » est une salle, les portes d’accès à cette zone

doivent être sécurisées et une alerte doit être déclenchée en cas de

tentative d'effraction.

EXI_COM_28 Si la zone « Rouge » est une salle, les murs, sols et plafonds entourant

les bureaux et couloirs de cette zone doivent être renforcés (matériaux

résistants comme les parpaings, les briques ou les murs/dalles en

béton ou en acier) ou équipés de dispositifs permettant de détecter les

perçages 24h/24 et 7j/7 (capteurs de vibration, capteurs acoustiques,

par exemple).

EXI_COM_29 Si la zone « Rouge » est une salle, les bureaux et couloirs de cette

zone ne doivent pas comporter de fenêtres facilement accessibles

depuis l’extérieur (rez-de-chaussée, terrasse…).


zone ne doivent pas comporter un accès direct à l’extérieur du

bâtiment (issues de secours, puits de lumière…).






zone doivent être équipés d’un dispositif de détection des intrusions

physiques 24h/24 et 7j/7 (présence d’un gardien, capteurs

volumétriques, détection de mouvements par vidéosurveillance,

barrières infrarouges, capteurs de bris de glace, capteurs acoustiques,

par exemple).

EXI_COM_32 Si la zone « Rouge » est une salle, les issues de secours de cette zone

doivent correspondre aux portes d’accès à cette zone et doivent être

équipées d’un dispositif sécurisé d’ouverture d’urgence permettant de

désactiver le contrôle d’accès en double contrôle, pour pouvoir

évacuer la zone.

EXI_COM_33 Les locaux techniques hébergeant les serveurs informatiques

intervenant dans le cadre de la gestion des Systèmes d’Acceptation

CB doivent être des zones « Orange ».

EXI_COM_34 Les locaux techniques hébergeant les installations de sécurité (centrale

de contrôle d'accès, PC de gestion des badges d'accès) doivent être en

zone « Orange ».

7.9.3.2 Gestion des accès

EXI_COM_35 Des contrôles réguliers du bon fonctionnement des installations de

sécurité (centrale de contrôle d'accès, PC de gestion des badges

d'accès), doivent être réalisés et tracés.

EXI_COM_36 Une procédure de sécurité pour contrôler l'accès des visiteurs aux

zones impliquées dans la gestion des Systèmes d’Acceptation CB et

des Serveurs de Monétique Répartie doit être implémentée et

permettre facilement l'identification du personnel autorisé.

EXI_COM_37 Une procédure de contrôle strict des entrées/sorties de supports

amovibles (CD/DVD, clé USB, etc.) pour les postes de travail et

serveurs impliqués dans la gestion des Systèmes d’Acceptation CB et

des Serveurs de Monétique Répartie doit être implémentée. Ces

médias sont propriétés de l'organisme et leurs usages tracés et

approuvés par la direction.

EXI_COM_38 Des dispositifs de contrôle d'accès physique doivent être installés pour

assurer la protection des locaux impliqués dans la gestion des

Systèmes d’Acceptation CB et des Serveurs de Monétique Répartie.

EXI_COM_39 Des contrôles doivent être régulièrement menés pour vérifier le bon

fonctionnement des dispositifs de contrôle d'accès physique des

locaux impliqués dans la gestion des Systèmes d’Acceptation CB et

des Serveurs de Monétique Répartie.





EXI_COM_40 Des procédures de revue et de mise à jour des droits d'accès physique

aux locaux impliqués dans la gestion des Systèmes d’acceptation CB

et des Serveurs de Monétique Répartie doivent être implémentées et

appliquées.

Les acteurs sont identifiés et les revues doivent être tracées.

L'attribution de comptes et de droits d'accès :

1. se fait au fil de l'eau ;

2. est validée par un responsable ;

3. respecte le principe de séparation des tâches ;

4. respecte le principe du besoin d'en connaître ;

5. les contrôles de revue des comptes sont trimestriels (contrôle

de la bonne suppression des comptes) ;

6. les contrôles de besoins (mise à jour des droits) sont

semestriels.

EXI_COM_41 En cas de détection d’un accès non autorisé (tentative d'accès,

intrusion physique) dans un site/local impliqué dans la gestion des

Systèmes d’Acceptation CB et des Serveurs de Monétique Répartie,

une procédure de gestion des incidents doit être implémentée. Celle-ci

doit :

1. Lister les moyens utilisés pour détecter un accès non autorisé

(tentative d'accès, intrusion physique) ;

2. Identifier les acteurs (externes ou internes) intervenant en cas

de détection d’un accès non autorisé (tentative d'accès,

intrusion physique) ;

3. Avoir une procédure de remontée d’information auprès du GIE

CB, notamment en cas de suspicion de fraude, selon la

procédure décrite à l’Annexe 2 ;

4. Prévoir un archivage des incidents.

7.9.4 PROTECTION DES SYSTÈMES INFORMATIQUES

EXI_COM_42 Une analyse de risques logique doit être effectuée et prendre en

compte les menaces accidentelles et malveillantes. L'analyse doit

porter sur l'environnement logique des Systèmes d'Acceptation CB et

des Serveurs de Monétique Répartie durant leur cycle de vie

(développement, construction, livraison, stockage, exploitation et

maintenance). Cela inclut notamment la protection des postes de

travail et serveurs informatiques, ainsi que des équipements réseau et

télécom.

EXI_COM_43 Une politique de sécurité logique doit être formalisée pour garantir la

sécurité des Systèmes d’Acceptation CB et des Serveurs de Monétique

Répartie durant leur cycle de vie (développement, construction,

livraison, stockage, exploitation et maintenance).





EXI_COM_44 La politique de sécurité logique doit décrire l'organisation mise en

place. En particulier, elle doit formaliser les groupes, rôles et

responsabilités des personnels impliqués dans la sécurité des Systèmes

d’Acceptation CB et des Serveurs de Monétique Répartie durant leur

cycle de vie, notamment pour la protection des postes de travail, des

serveurs informatiques et des équipements réseaux et télécoms.

EXI_COM_45 Une cartographie des flux réseaux autorisés en rapport avec la gestion


Répartie doit être définie et cohérente avec la politique de sécurité

logique.

EXI_COM_46 Une cartographie des flux métiers nécessaires au fonctionnement des

serveurs utilisés dans les développements, la maintenance et la

livraison des logiciels monétiques utilisés par la communauté CB doit

être définie

EXI_COM_47 Les journaux d'audit d’un serveur en zone « Orange » ou « Rouge » et

des équipements réseaux (routeurs, commutateurs, pare-feu..) le

protégeant doivent être analysés au moins une fois par jour, pour

pouvoir identifier au plus tôt toute action suspecte ou non autorisée.

Les analyses peuvent être automatisées avec des solutions spécialisées

dans l’analyse des journaux d’audit.

EXI_COM_48 Dans le cadre de la maintenance d’un serveur en zone « Jaune »,

« Orange » ou « Rouge », l’organisme est responsable de la sécurité

des données hébergées sur les supports de stockage.

Il doit s'assurer opérationnellement ou contractuellement de la

destruction des données avant toute sortie du support de stockage des

locaux techniques.

Toute action de sortie d'un support de stockage et de destruction de

données doit être tracée (procès-verbal, date, qui, quoi, etc.).





EXI_COM_49 Une procédure particulière pour la gestion distante

(télé-administration lors d'éventuelles astreintes) des serveurs

informatiques et des équipements réseaux impliqués dans la gestion


Répartie doit être implémentée si le besoin a été identifié par

l'organisme. Celle-ci doit :

1. Décrire les rôles et les responsabilités des personnels

concernés, ainsi que les conditions d'intervention et leur

traçabilité.

2. Identifier et répertorier les dispositifs et logiciels utilisés pour

assurer la protection de cette télé-administration

(authentification et protection des sessions d'administration :

sessions SSH ou SSL, authentification par token).

EXI_COM_50 Une procédure de gestion d'incident de sécurité dans le cadre de la

gestion des Systèmes d’Acceptation CB et des Serveurs de Monétique

Répartie doit être implémentée.

EXI_COM_51 Les raccordements à des réseaux publics (Internet, etc.) et des réseaux

radio (Wifi, GPRS, 3G, etc.) sont filtrés par des pare-feu et les réseaux

locaux internes sont cloisonnés vis-à-vis de ces réseaux publics par la

mise en place de DMZ également filtrées par des pare-feu.

EXI_COM_52 La configuration des pare-feu concernés doit interdire tout trafic

réseau, autre que celui requis pour les flux métiers.

EXI_COM_53 Des dispositifs de détection et/ou de prévention d'intrusion réseau

doivent être mis en place sur les réseaux, incluant les interfaces avec

les réseaux publics (Internet, etc.) et radio (Wifi, GPRS, 3G, etc.),

impliqués dans la gestion des Systèmes d’Acceptation CB et des

Serveurs de Monétique Répartie.

EXI_COM_54 Les systèmes d'information métier impliqués dans la gestion des

Systèmes d’Acceptation CB et des Serveurs de Monétique Répartie (y

compris les réseaux sans fil) doivent être physiquement et/ou

logiquement cloisonnés des autres réseaux de l'organisme.

EXI_COM_55 Un processus formel pour la revue périodique des configurations des

équipements réseaux (routeurs, commutateurs, pare-feu, etc.)

impliqués dans la gestion des Systèmes d’Acceptations CB et des

Serveurs de Monétique Répartie doit être implémenté. Les traces des

revues doivent être conservées.





EXI_COM_56 Tout personnel impliqué dans la gestion des Systèmes d’Acceptation

CB et des Serveurs de Monétique Répartie doit être identifié de

manière nominative et à l'aide d'un mot de passe suffisamment

complexe, avant tout accès à des postes de travail ou des serveurs


CB et des Serveurs de Monétique Répartie. Toute conservation des

mots de passe doit être chiffrée.

EXI_COM_57 Pour toute utilisation des Systèmes d'accès réseau à distance (VPN,

modem, etc.), dans le cas d'astreinte ou de télémaintenance par

exemple, les personnels impliqués doivent être authentifiés de manière

forte, c'est-à-dire à l'aide d'un certificat ou d'une clé électronique et

d'un serveur d'authentification.

EXI_COM_58 Des procédures de revue et de mise à jour des droits d'accès logique

sur les postes de travail ou les serveurs informatiques impliqués dans

la gestion des Systèmes d’Acceptation CB et des Serveurs de

Monétique Répartie doivent être implémentées et appliquées,

notamment lors d'un changement de poste ou du départ d'un personnel

de l'organisme.

EXI_COM_59 Les postes d'exploitation fixes et les postes de travail nomades ayant

accès, par les réseaux locaux ou à distance via des accès VPN (dans le

cas d'astreintes par exemple), aux serveurs informatiques impliqués

dans la gestion des Systèmes d’acceptation CB et des Serveurs de

Monétique Répartie doivent être sécurisés :

1. Logiciel anti-virus activé et à jour, configuré pour réaliser des

analyses sur accès et des scans périodiques complets, et non

désactivable par l'exploitant ;

2. Logiciel pare-feu, activé et non désactivable par l'exploitant,

dont les règles doivent être adaptées aux usages ;

3. Le disque dur doit avoir un chiffrement de surface et des

mesures de séquestre des clés mises en œuvre ;

4. Les comptes des utilisateurs courants des postes de travail ne

doivent pas être à privilèges ;

5. L'installation de logiciels non autorisés par l'organisme doit

être interdite ;

6. Un contrôle mensuel des droits d'accès à ces postes de travail

doit être effectué ;

7. Un Système d’Exploitation sécurisé (accès par mot de passe,

démarrage sur un support amovible interdit) doit être utilisé

pour les organismes dont l'activité de gestion des Systèmes


mutualisée avec d'autres activités.





EXI_COM_60 Les serveurs informatiques impliqués dans la gestion des Systèmes

d’Acceptation CB et des Serveurs de Monétique Répartie doivent

fonctionner avec un système d’exploitation « durci », c'est-à-dire

composé exclusivement des seuls éléments logiciels et matériels

nécessaires à son fonctionnement.

Le durcissement d’un système d’exploitation consiste au minimum à :

1. Supprimer les modules inutilisés (exécutables, bibliothèques

logicielles, pilotes…) et les services inutiles (protocoles,

services TCP/IP, services systèmes, etc.) ;

2. Supprimer les comptes utilisateurs inutilisés et changer les

mots de passe par défaut ;

3. Mettre à jour le système d’exploitation avec les derniers patchs

de sécurité selon une fréquence mensuelle pour les plus

critiques et bimensuelle pour les autres ;

4. Désactiver les moyens de démarrage à distance des systèmes

d’exploitation (exemple : télé-démarrage Ethernet PXE) ;

5. Respecter les règles de durcissement proposées par les

fournisseurs de systèmes d’exploitation commerciaux ou

logiciels libres.

EXI_COM_61 Des dispositifs de contrôle d'intégrité des fichiers systèmes et des

données doivent être mis en place et exécutés régulièrement sur les

serveurs impliqués dans la gestion des Systèmes d’Acceptation CB et

des Serveurs de Monétique Répartie. Ces dispositifs doivent être

journalisés.

EXI_COM_62 Les postes de travail et les serveurs informatiques, ainsi que les

équipements réseau et télécom, y compris pour les réseaux radio

(Wifi, GPRS, 3G, etc.), impliqués dans la gestion des Systèmes

d’Acceptation CB et des Serveurs de Monétique Répartie doivent être

sous contrat de maintenance précisant que :

1. Les opérations de maintenance ne sont réalisées que par des

personnes autorisées.

2. Les opérations de maintenance sont tracées.

EXI_COM_63 Une procédure de déclenchement de service de maintenance doit être

implémentée. Celle-ci doit prévoir une suppression des données

sensibles avant toute sortie d'un matériel hors des locaux de

l'organisme pour cause de maintenance.

EXI_COM_64 Une procédure de mise au rebut des postes de travail, des serveurs

informatiques et des médias de sauvegarde et d'archivage impliqués

dans la gestion des Systèmes d’Acceptation CB et des Serveurs de

Monétique Répartie doit être implémentée.





EXI_COM_65 Les journaux d'audit des serveurs informatiques et des équipements

réseau (routeurs, commutateurs, pare-feu, etc.) impliqués dans la


Répartie doivent être activés.

EXI_COM_66 Un processus d'analyse des journaux d'audit doit être implémenté. Sa

périodicité doit être précisée (un rythme journalier est recommandé)

ainsi que la méthode d'analyse (manuelle ou automatique par un

dispositif de remontée d'alertes).

EXI_COM_67 Les dispositifs de journalisation des serveurs informatiques et des

équipements réseau (routeurs, commutateurs, pare-feu, etc.) impliqués


Monétique Répartie doivent :

1. Tracer les accès utilisateurs, notamment ceux avec des

privilèges d'administration ;

2. Les traces doivent contenir les informations suivantes : date et

heure de l'action, identité de l'utilisateur, type d'action, origine

de l'action, donnée ou ressource concernée, résultat de l'action

(succès ou échec).

EXI_COM_68 Un processus de veille sécuritaire concernant les systèmes

d'exploitation et logiciels installés sur les postes d'exploitation, les PC

portables, les serveurs informatiques et équipements réseau impliqués


Monétique Répartie doit être implémenté et porter notamment sur les

nouvelles vulnérabilités et les patchs de sécurité associés.

EXI_COM_69 Un processus de mise à jour régulière des systèmes d’exploitation et

des logiciels installés les postes de travail portables, les serveurs

informatiques et équipements réseau impliqués dans la gestion des

Systèmes d’Acceptation CB et des Serveurs de Monétique Répartie

doit être implémenté. Celui-ci doit vérifier que tous les patchs de

sécurité pertinents ont été appliqués et que les nouveaux sont

appliqués dans le mois qui suit leur publication pour les plus critiques

et dans les deux mois pour les autres.

EXI_COM_70 Des campagnes de tests d’intrusion doivent être régulièrement

réalisées sur les réseaux et applicatifs impliqués dans la gestion des

Systèmes d’Acceptation CB et des Serveurs de Monétique Répartie.

Ces tests doivent également couvrir les interfaces avec les réseaux

publics (Internet, etc.) et radio (Wifi, GPRS, 3G, etc.),. Ces

campagnes doivent donner lieu à la production de comptes rendus et

des éventuels plans d'actions associés.

EXI_COM_71 La sécurité logique et physique des Systèmes d'Acceptation CB et des

Serveurs de Monétique Répartie doit faire l'objet d'audits réguliers.





EXI_COM_72 Un dispositif de contrôle permanent de la gestion des points

d’acceptation CB ou des Serveurs de Monétique Répartie doit être mis

en place. Il doit disposer d'un référentiel de contrôle et prévoir la

rédaction de rapports attestant des résultats des contrôles menés.

EXI_COM_73 Un dispositif de contrôle périodique de la gestion des points

d’acceptation CB ou des Serveurs de Monétique Répartie doit être mis

en place. Il doit disposer d'un référentiel de contrôle et prévoir la

rédaction de rapports attestant des résultats des contrôles menés.

EXI_COM_74 Les actions réalisées (qui, quoi et quand) à chaque étape de la gestion

d'un Point d'Acceptation CB ou d'un logiciel de Serveur de Monétique

Répartie doivent être tracées.

7.9.5 ENVIRONNEMENTS TECHNIQUES

EXI_COM_75 Les différentes plateformes matérielles utilisées (informatiques et

télécommunications) dans le cadre de la gestion des Systèmes

d'Acceptation CB et des Serveurs de Monétique Répartie doivent être

identifiées.

EXI_COM_76 L'inventaire des plateformes matérielles utilisées doit inclure les

configurations déployées (marque et modèle) et les logiciels utilisés

EXI_COM_77 Une cartographie réseau doit être effectuée au minimum pour le SI

dédié aux activités de la gestion des Systèmes d'Acceptation CB et des

Serveurs de Monétique Répartie. Elle doit spécifier les interfaces

réseaux externes utilisées avec les acteurs externes (passerelles

internationales, systèmes d'information métier, sites Web extranet..).

EXI_COM_78 Des mesures doivent être mises en œuvre pour garantir une continuité

des activités liées à la gestion des Systèmes d’Acceptation CB et des

Serveurs de Monétique Répartie. Il est recommandé que ces mesures

fassent partie intégrante d'un Plan de Continuité d'Activité.

7.9.6 SÉCURITÉ DE LA DOCUMENTATION PAPIER

EXI_COM_79 L’organisme doit disposer d’une politique de classification des

informations. Le niveau approprié doit être appliqué pour les

informations relatives à la gestion des Systèmes d’Acceptation CB et

des Serveurs de Monétique Répartie. Par exemple, les procédures de

gestion des secrets doivent avoir un niveau de classification élevé.





EXI_COM_80 La politique doit prévoir, pour chaque niveau, des règles d’usage des

informations et de leurs supports, notamment les supports papiers.

Ces règles doivent encadrer la diffusion, le stockage et la destruction

des informations et de leurs supports.

Les moyens de mise en œuvre de ces règles doivent être identifiés.

Ces règles doivent être cohérentes avec les exigences du présent

référentiel.

Concernant les supports dits sensibles, ceux-ci doivent au minimum :

1. Être stockés dans un support sécurisé (armoire sous clé, disque

à accès limité, etc.) ;

2. Être détruites lorsqu’ils ne sont plus utilisés (broyeurs, etc.).

7.9.7 SÉCURITÉ DES SAUVEGARDES

EXI_COM_81 Une politique de sauvegarde doit être implémentée (planification, lieu

de stockage, application, rétention) pour les serveurs impliqués dans la


Répartie.

EXI_COM_82 Les données sauvegardées doivent bénéficier du même niveau de

sécurité que les données d'origine.

EXI_COM_83 Un inventaire des supports informatiques impliqués dans la

sauvegarde doit être réalisé et revu régulièrement.

7.9.8 SÉCURITÉ RH

EXI_COM_84 Le processus de recrutement des opérateurs responsables des

opérations sensibles sur la chaine de vie des Systèmes d'Acceptation

CB et des Serveurs de Monétique Répartie doit mettre en place une

démarche de surveillance particulière, notamment la demande de leur

extrait de casier judiciaire (ou équivalent à l’étranger) pour apprécier

sa capacité à occuper l'emploi proposé ou ses aptitudes

professionnelles. Sont notamment concernées les activités de

maintenance, développement, livraison et d'assemblage.

Les extraits de casier judiciaire ne doivent pas être conservés.





EXI_COM_85 Une charte de sécurité, ou document d’entreprise équivalent (exemple

notice générale d’information), doit être signée par les personnels


Serveurs de Monétique Répartie.

Celle-ci doit reprendre les exigences de sécurité du présent référentiel

que le personnel doit suivre et respecter. Elle doit également

responsabiliser l’intervenant vis-à-vis de la sensibilité des activités

monétiques.

EXI_COM_86 Un processus de sensibilisation et de formation des personnels


Serveurs de Monétique Répartie doit être formalisé et appliqué. Les

sensibilisations et les formations doivent être régulières. Un procès-

verbal formalisant la présence du personnel lors de ces séances doit

être signé par ces derniers.





ANNEXE 1. Table des illustrations

Figure 1 : Cycle de vie d'un Système d'Acceptation CB ......................................................... 12 Figure 2 : Zoom sur l'exploitation et la gestion des différents services .................................. 13 Figure 3 : cycle de vie d'un Système d'Acceptation CB .......................................................... 19 Figure 4 : Exemple 1 de configuration pour un Développeur ................................................. 22 Figure 5 : Exemple de configuration pour un Constructeur .................................................... 22

Figure 6 : Exemple de configuration pour un Intégrateur ....................................................... 23

Figure 7 : Exemple 1 de configuration pour un Préparateur ................................................... 23

Figure 8 : Exemple 2 de configuration pour un Préparateur ................................................... 24 Figure 9 : Exemple 3 de configuration pour un Préparateur ................................................... 24 Figure 10 : Maintenance de PA CB ......................................................................................... 25 Figure 11 : Mise au rebut de PA CB ....................................................................................... 25 Figure 12 : Exemple 4 de configuration pour un Préparateur ................................................. 26

Figure 13 : Exemple 2 de configuration pour un Développeur ............................................... 26





ANNEXE 2. Remontée d’informations au Groupement des Cartes Bancaires

Deux types de notifications sont prévus dans les exigences du présent document : la

notification pour suspicion de fraude, et la notification pour commande d’opération

non autorisée dans le système CB (date de fin de déploiement, date de fin de vie). Les

modèles de notification associés sont donnés ci-dessous.

A. Procédure concernant la suspicion de fraude

Lorsque le professionnel est amené à réaliser des opérations sur tout ou partie d’un

système d’acceptation, et qu’il détecte un élément de nature à générer de la fraude (Point

d’acceptation modifié anormalement, vol d’une palette de point d’acceptation, logiciel

non valide), et qu’il estime qu’il ne s’agit pas d’un fait isolé pouvant relever d’une erreur

involontaire de manipulation, il doit envoyer un courriel à l’adresse

« [email protected] » selon le format suivant :

Notification pour suspicion de fraude

Date d’observation

Identification du professionnel signalant

Raison social organisme

Adresse

Référence / Labélisation n°

Information technique sur le Système d’acceptation visé

Constructeur

Modèle

ITP

Version logicielle

Observations détaillées

Cette notification ne vise que la fraude aux moyens de paiement (modification matérielle

ou logicielle d’un système d’acceptation, intrusion/malware sur un système d’acceptation,

vol de secret de signature de logiciel, vol en masse de systèmes d’acceptation). Elle ne

vise pas la fraude commerciale (facturation abusive, vente abusive, …).

mailto:[email protected]





B. Procédure concernant les non-conformités issues des contrôles de fin de vie

Lorsque le professionnel est amené à installer un Système d’acceptation CB dont le statut

de l’agrément est à « fin de commercialisation/déploiement » ou « fin de vie » (sauf

échange standard en cas de panne), ou pour toute opération de maintenance apportée sur

un Système d’acceptation CB dont le statut de l’agrément CB est à « fin de vie », il doit

envoyer un courriel à l’adresse « [email protected] » selon le format

suivant :

Notification d’opération sur un Système d’Acceptation CB en fin de vie

Date d’intervention

Identification du professionnel signalant

Raison social organisme

Adresse

Référence / Labélisation n°

Information technique sur le Système d’acceptation visé

Constructeur

Modèle

ITP

Version logicielle

Type d’opération effectuée

Information commerciale

Nom du client

Donnée de contact du client

Nom du point de vente

Adresse du point de vente

mailto:[email protected]

Documents

Référentiel de labélisation des prestataire intervenant ... · 7.5.2 Maintenance de niveau 2 ... recevoir des fonds en paiement par carte, ... ainsi que la saisie du code confidentiel