Profil de Protection pour services bancaires et / ou financiers sur Internet Version : V7 Date : 4 août 2004
Sommaire 1 DU LIVRE BLANC AU REFERENTIEL DE SECURITE... 5 1.1 MISSION CONFIEE AU CFONB PAR LE SECRETARIAT GENERAL DE LA COMMISSION BANCAIRE... 5 1.2 UN REFERENTIEL DE SECURITE, POUR QUI?... 5 1.3 UN REFERENTIEL DE SECURITE, SOUS QUELLE FORME?... 5 1.4 SPECIFICITES DES ETABLISSEMENTS BANCAIRES ET FINANCIERS... 5 1.4.1 Contrôle interne...5 1.4.2 Lutte contre le blanchiment...6 1.4.3 Risque juridique...6 1.4.4 Agrément des établissements...6 1.5 CHAMP D'APPLICATION DU REFERENTIEL SECURITE... 7 1.6 POINTS FORTS DE LA DEMARCHE... 8 1.6.1 Reconnaissance internationale du référentiel certifié selon les Critères Communs...8 1.6.2 Utilisations du référentiel...8 2 DEMARCHE RETENUE PAR LE CFONB... 9 2.1 PRINCIPE... 9 2.1.1 Définition du système cible et analogie avec le guichet bancaire...9 2.1.2 Biens et environnement de sécurité...10 2.1.3 de sécurité...11 2.1.4 Exigences de sécurité...11 2.2 ROLE DE LA MAITRISE D OUVRAGE ET DE LA MAITRISE D ŒUVRE... 11 2.2.1 Maîtrise d ouvrage...11 2.2.2 Maîtrise d œuvre...11 3 EXPRESSION DU BESOIN DE SECURITE... 12 3.1 INTRODUCTION... 12 3.1.1 Description générale du Profil de Protection (PP)...12 3.1.2 Identification du Profil de protection...13 3.1.3 Conventions...13 3.2 DESCRIPTION DE LA CIBLE D EVALUATION... 14 3.2.1 Concepts et définitions...14 3.2.2 Vue d'ensemble de la fourniture d'un service bancaire et / ou financier sur Internet...16 3.2.3 Acteurs et Rôles...16 3.2.4 Modélisation de la cible d'évaluation...17 3.2.5 Éléments variables de la TOE...19 3.3 ENVIRONNEMENT DE SECURITE DE LA CIBLE D EVALUATION... 21 3.3.1 Biens de la TOE...21 3.3.2 Hypothèses...24 3.3.3 Politiques de sécurité organisationnelles...27 3.3.4 Menaces...34 3.4 OBJECTIFS DE SECURITE... 44 3.4.1 Obligations...46 3.4.2 Politique de sécurité...47 3.4.3 Conception & développement...49 3.4.4 Contrôle et suivi...49 3.4.5 Cryptographie...50 3.4.6 Sécurité physique...51 3.4.7 Sécurité logique...52 4 EXIGENCES DE SECURITE... 53 2 / 123
4.1 EXIGENCES FONCTIONNELLES ET D'ASSURANCE... 53 4.1.1 Exigences fonctionnelles...53 4.1.2 Exigences d'assurance...94 4.2 NOTES D'APPLICATION... 103 4.3 ARGUMENTAIRE... 103 5 ANNEXES... 104 5.1 BIBLIOGRAPHIE... 104 5.2 ACRONYMES, GLOSSAIRE ET TERMINOLOGIE... 106 5.2.1 Acronymes...106 5.2.2 Glossaire...107 5.2.3 Terminologie relative aux exigences d'assurance...109 5.3 CLASSES DE TRANSACTIONS ET TRANSACTIONS... 111 5.4 DOMAINES DE SENSIBILITE AUX RISQUES... 115 5.5 CARACTERISTIQUES DE SECURITE DE LA CIBLE D'EVALUATION... 117 5.5.1 Caractéristiques des nouvelles architectures...117 5.5.2 Bonnes pratiques de protection...117 5.6 MAINTENANCE DE L'ASSURANCE... 120 5.6.1 Famille Plan de maintenance de l assurance [AMA_AMP]...120 5.6.2 Famille Rapport de classification des composants de la TOE [AMA_CAT.1]...121 5.6.3 Famille Preuve de la maintenance de l assurance [AMA_EVD]...121 5.6.4 Famille Analyse d impact sur la sécurité [AMA_SIA]...122 5.7 LISTE DES PARTICIPANTS DU GROUPE DE TRAVAIL "PROFIL DE PROTECTION"... 123 3 / 123
Liste des figures Figure 1 : Vue d'ensemble de la fourniture d'un SBFI...16 Figure 2 : Modèle fonctionnel d'un Système SBFI...18 Figure 3 : Domaines de sensibilité aux risques...116 Liste des tableaux Tableau 1 : Abréviations des Biens...22 Tableau 2 : Types d'attaques...35 Tableau 3 : Liste des exigences fonctionnelles et des niveaux SOF spécifiques associés...55 Tableau 4 : Liste minimale des événements auditables (FAU_GEN.1)...58 Tableau 5 : Liste des informations d'audit à enregistrer (FAU_GEN.1)...59 Tableau 6 : Liste minimale des opérations cryptographiques (FCS_COP.1)...66 Tableau 7 : Règles complémentaires de contrôle de flux d'information...70 Tableau 8 : Liste des rôles (FMT_SMR.1)...84 Tableau 9 : Liste minimale des rejeux à détecter (FPT_RPL.1)...85 Tableau 10 : Liste des exigences d'assurance retenues...95 4 / 123
1 DU LIVRE BLANC AU REFERENTIEL DE SECURITE 1.1 Mission confiée au CFONB par le Secrétariat Général de la Commission Bancaire Le Secrétariat général de la Commission bancaire, par le biais de son groupe de travail "Sécurité des systèmes d information et des transactions", a confié au groupe sécurité du Comité Français d Organisation et de Normalisation Bancaire (CFONB) la mission d élaborer un référentiel de sécurité pour les sites bancaires et / ou financiers sur Internet. La Commission Bancaire (CB) et le Conseil des Marchés Financiers (CMF) ont participé financièrement et opérationnellement à cette mission prise en charge par le CFONB car ils ont estimé qu'elle correspondait à leurs préoccupations et réflexions dans le domaine des services bancaires et / ou financiers fournis sur Internet. Ce travail s inscrit dans le cadre de la réflexion internationale menée au sein du Comité de Bâle et de la mise en œuvre des recommandations de la Commission bancaire et de la Banque de France publiées dans le Livre Blanc intitulé "Internet : quelles conséquences prudentielles?". Le livre blanc distingue trois types de services bancaires et / ou financiers sur Internet : Institutionnels : ils présentent des informations à caractère public sur l'établissement, comme par exemple ses produits. Consultation des données privées : ils nécessitent une identification et une authentification de l utilisateur, lui permettant d accéder à des informations personnelles, par exemple la consultation de ses comptes ou de ses portefeuilles de titres. Transactionnels : ils permettent à l utilisateur, sur la base de son authentification, de réaliser des opérations bancaires et / ou financières, par exemple des virements ou des opérations sur des titres. 1.2 Un référentiel de sécurité, pour qui? Ce référentiel de sécurité s'adresse avant tout aux maîtrises d'ouvrage et aux maîtrises d'œuvre impliquées dans les offres de services bancaires et/ou financiers de leurs établissements. 1.3 Un référentiel de sécurité, sous quelle forme? Conformément aux préconisations du Livre Blanc "Internet : quelles conséquences prudentielles?", ce référentiel de sécurité est rédigé en respectant la norme ISO/IEC 15408 (correspondant aux Critères Communs) et constitue un "Profil de Protection" (PP) au sens de la norme. 1.4 Spécificités des établissements bancaires et financiers Le référentiel de sécurité rappelle la notion d Établissement Agrée Responsable d un Service bancaire et/ou financier (EARS). Il est fait référence à cette notion pour la définition des objectifs et exigences de sécurité. Ce référentiel met en relief un certain nombre d'objectifs de sécurité provenant de la réglementation en vigueur, notamment les objectifs relatifs au respect de la vie privée, au cadre contractuel relatif à la fourniture d'un service bancaire et / ou financier, et à la gestion des preuves des transactions. De plus, le référentiel de sécurité intègre les spécificités bancaires et / ou financières rappelées ci-dessous. 1.4.1 Contrôle interne Les établissements de crédit et les sociétés d investissements sont soumis aux règlements édictés par le Comité de la Réglementation Bancaire et Financière, notamment : règlement n 90-08 du 25 juillet 1990 qui fixe, pour les établissements assujettis, la nature des contrôles internes ; 5 / 123
règlement n 90-09 du 25 juillet 1990 relatif au risque de taux d'intérêt sur les opérations de marché ; règlement n 91-04 du 16 janvier 1991 concernant l'organisation du système comptable et du dispositif de traitement de l'information des établissements de crédits et des maisons de titres ; règlement n 97-02 du 21 février 1997 relatif au contrôle interne des établissements de crédit. En plus de ce cadre réglementaire, le groupe de travail sur les conséquences prudentielles liées à l Internet recommande de fournir au responsable du contrôle interne une compétence explicite et exhaustive sur toute question relative à la sécurité. 1.4.2 Lutte contre le blanchiment Le blanchiment est défini comme le fait de faciliter, par tout moyen, la justification mensongère de l'origine des biens ou des revenus de l'auteur d'un crime ou d'un délit ayant procuré à celui-ci un profit direct ou indirect. Le blanchiment peut être facilité par la nature dématérialisée de la relation qui s établit entre l établissement financier et son client via Internet, rendant plus difficile la vérification de l identité et de la capacité financière de ce dernier. La loi du 12 juillet 1990 sur le blanchiment d'argent punit l'entrave à l'identification de valeurs d origine criminelle. Un décret relatif au défaut de vigilance en matière d'opérations financières pénalise tout professionnel de la finance qui ne vérifie pas l'identité de l'ayant droit économique. La loi sur le blanchiment d'argent a les caractéristiques suivantes : elle s'applique à tous les établissements proposant des services bancaires et/ou financiers : banques, directions de fonds de placement, compagnies d'assurances, gérants de fortunes, agents fiduciaires, bureaux de change, etc. ; l organisme financier doit vérifier l'identité du cocontractant et de l'ayant droit économique ; en cas de soupçon de blanchiment de valeurs d'origine criminelle, il est obligé d'informer le service TRACFIN ; un système de surveillance et de contrôle est mis en place pour vérifier la mise en application de la loi ; l'autorité de contrôle peut transmettre aux autorités étrangères des informations non accessibles au public moyennant des garanties de confidentialité et d'utilisation exclusive pour la lutte contre le blanchiment. 1.4.3 Risque juridique En plus du Code pénal (articles 226-16 à 226-24), l article 14 du règlement N 97-02 du Comité de la Réglementation Bancaire et Financière responsabilise les dirigeants des établissements dans l évaluation et la maîtrise des risques liés à la sécurité des systèmes d information. La dématérialisation des relations avec les tiers introduit un risque juridique spécifique aux prestations transfrontalières. 1.4.4 Agrément des établissements Les opérations de banque ou les services d investissement effectués sur Internet sont couverts par les réglementations générales et sectorielles applicables à ces activités. C est le Comité des Établissements de Crédit et des Entreprises d Investissement (CECEI) qui est chargé, par la loi du 24 février 1984 et la loi de modernisation des activités financières du 2 juillet 1996, de délivrer les agréments pour l exercice de ces opérations sur le réseau. Pour le service d investissement de la gestion de portefeuille pour le compte de tiers, la Commission des Opérations de Bourse (COB) est seule compétente. Dans le cas d un élargissement de son activité sur Internet à de nouveaux services non couverts par le champ de l agrément qui lui a été accordé, l établissement devra veiller à actualiser son agrément auprès des autorités compétentes. Un établissement bancaire et / ou financier est dit agréé lorsqu'il a reçu une autorisation pour fournir des services bancaires et / ou des services financiers de la part de l'autorité compétente. L'autorisation est appelée agrément. 6 / 123
Pour la France, les différentes autorités délivrant les agréments sont : le Comité des Établissements de Crédit et des Entreprises d'investissement (CECEI), qui agrée les Établissements de Crédit et les Entreprises d'investissement ; le Conseil des Marchés Financiers (CMF), qui délivre une habilitation à l'exercice de l'activité de Tenue de Compte Conservation ou de Compensation, en général à des établissements agréés par le CECEI, mais également à titre dérogatoire à des entités qui ne sont ni des établissements de crédit ni des entreprises d'investissement (par exemple à des GIE) ; la Commission des Opérations de Bourse (COB), qui agrée les Sociétés de Gestion ; les institutions et services visés par les articles L. 518-1 et L. 531-2 du Code Monétaire et Financier sont assimilés à des établissements agréés. 1.5 Champ d'application du référentiel sécurité La vocation première du référentiel est de garantir un niveau de sécurité équivalent pour les services bancaires et/ou financiers disponibles sur Internet. Ces services sont précisés dans la cible d évaluation (chapitre 3.2). Un établissement qui n offrirait pas de bonnes garanties de sécurité ferait courir un risque majeur à la communauté bancaire et financière. Le référentiel de sécurité permet de garantir la conformité du dispositif de sécurité adopté par un établissement, grâce à l application des critères nécessaires et suffisants de la "cible de sécurité" communautaire. Dans le profil de protection, ces critères sont appelés "objectifs de sécurité" et "exigences de sécurité". Les exigences de sécurité sont la traduction des objectifs de sécurité dans le formalisme imposé des Critères Communs Les objectifs de sécurité concernent les maîtrises d'ouvrage et les maîtrises d'œuvre des établissements, alors que les exigences de sécurité s appliquent à l'exploitation et sont limitées à certains personnels (équipes sécurité ). Le référentiel de sécurité concerne les sites bancaires et / ou financiers transactionnels sur Internet, qu'ils s adressent à une clientèle particulière ou d'entreprise. Le référentiel est modulaire et d un niveau d abstraction élevé, afin de le rendre indépendant de la technologie en place. Il a été conçu ainsi pour tenir compte de la variété des architectures techniques existant au sein des établissements et pour rester pertinent en cas d'évolution des technologies. En revanche, il ne couvre pas : les services bancaires et / ou financiers n utilisant pas le canal Internet ; les services bancaires et / ou financiers de nature non transactionnelle ; les équipements de connexion des acteurs et en particulier des utilisateurs ; les systèmes de secours de tout ou partie des services bancaires et / ou financiers sur Internet ; le système de contrôle des accès physiques. 7 / 123
1.6 Points forts de la démarche 1.6.1 Reconnaissance internationale du référentiel certifié selon les Critères Communs La certification de conformité du référentiel de sécurité à la norme internationale ISO/IEC 15408 (Critères Communs) garantit sa reconnaissance par tous les états signataires. 1.6.2 Utilisations du référentiel Le référentiel de sécurité peut être utilisé pour : rédiger le cahier des charges sécurité d'un nouveau service bancaire et / ou financier sur Internet ; évaluer et certifier conformément aux Critères Communs un service bancaire et / ou financier sur Internet L évaluation selon les Critères Communs est réalisée par un organisme indépendant et compétent (il doit être agréé pour pouvoir procéder à des évaluations). En France, ces organismes sont appelés Centre d Évaluation de la Sécurité des Technologies de l Information (CESTI). La certification est prononcée par un organisme gouvernemental au vu du rapport d'évaluation rédigé par le CESTI. En France, il s'agit de la Direction Centrale de la Sécurité des Systèmes d'information (DCSSI). Il est également envisageable que la certification d'un service ou site sur la base de ce référentiel participe à la décision d'agrément d'un nouvel entrant. 8 / 123
2 DEMARCHE RETENUE PAR LE CFONB 2.1 Principe La norme internationale ISO/IEC 15408:1999, intitulée "Critères Communs pour l évaluation de la sécurité des technologies de l information" comprend les parties suivantes : ISO/IEC 15408-1:1999 : (partie 1) Introduction et modèle général ; ISO/IEC 15408-2:1999 : (partie 2) Exigences fonctionnelles de sécurité ; ISO/IEC 15408-3:1999 : (partie 3) Exigences d assurance de sécurité. L'emploi des Critères Communs dans le présent référentiel impose : l'utilisation des termes définis dans la norme et le respect du plan imposé pour un profil de protection (partie 1) ; l'utilisation des exigences de sécurité fonctionnelles et d'assurance (parties 2 et 3). Pour tenir compte du formalisme imposé par les Critères Communs pour les exigences de sécurité, la démarche d'élaboration du référentiel a comporté deux phases : 1. Expression du besoin de sécurité, aboutissant à la définition des objectifs de sécurité et reprenant les termes définis par les Critères Communs ; 2. Traduction du besoin de sécurité en critères d'évaluation de la sécurité, sous forme d'exigences de sécurité respectant le formalisme des Critères Communs. L'expression du besoin de sécurité a comporté deux étapes : a) Définition du système étudié, sur une base fonctionnelle ; Le système étudié est la cible d'évaluation pour les Critères Communs. b) Définition des objectifs de sécurité, qui résultent : des éléments du système qui présentent une valeur ; Ces éléments sont les biens pour les Critères Communs. des menaces ; Ces éléments sont les menaces pour les Critères Communs. de tout ce qui doit être respecté : o contraintes issues de la prise en compte de l'existant ; Ces éléments sont les hypothèses de sécurité pour les Critères Communs. o règles et pratiques en vigueur. Ces éléments sont les Politiques de Sécurité Organisationnelles ou OSP (Organisational Security Policy) pour les Critères Communs. Les paragraphes qui suivent présentent ces notions clé. 2.1.1 Définition du système cible et analogie avec le guichet bancaire Le système étudié (cible d'évaluation) a été défini à l'aide de Blocs fonctionnels, regroupant un ensemble de fonctions ayant la même finalité et définis par analogie avec une agence bancaire traditionnelle. On retrouve ainsi les éléments fondamentaux d'une agence bancaire : l accueil établissement : sont disponibles en libre service les renseignements d ordre général et les documentations. L'accueil établissement est matérialisé dans une agence par différents éléments : une enseigne, située au dehors de l'agence et qui identifie l'établissement auprès du passant ; des locaux, comprenant : o une entrée principale ; 9 / 123
o un hall d'accueil ; o un guichet ; o des bureaux, dont certains accessibles au client (pour les entretiens avec des conseillers) ; des objets (affiches, dépliants ) faisant la promotion de l'établissement et tous marqués du logo de l'établissement. l accueil guichet : après avoir été identifié par l agent présent au guichet le client peut accéder à certains services bancaires et / ou financiers. Ces services peuvent être qualifiés de standards. Le client peut aussi se diriger vers le guichet pour poser une question. Le personnel au guichet doit alors lui répondre ou l orienter vers le bon interlocuteur. Les services bancaires et financiers accessibles à un guichet sont par exemple : consultation de solde de son (ses) compte(s) bancaire(s) ; demande de chéquier et / ou de carte bancaire ; opposition sur une (ses) carte(s), chèque(s) et prélèvement(s). Certains services ne sont pas accessibles au guichet et nécessitent un entretien avec un conseiller clientèle. L'agent au guichet oriente le client vers le conseiller ou prend rendez-vous pour une date ultérieure. Certains services personnalisés demandent en effet une préparation préalable de la part du conseiller. l accueil exploitants / administrateurs : Il est constitué de tous les éléments intervenant dans l'accès du personnel aux ressources de l'agence. l accueil fournisseur : pour fonctionner, l'agence a besoin d'un certain nombre de fournitures. Quelle que soit l'entrée utilisée (principale ou de service), les modalités d'accueil d'un fournisseur ne sont pas celles d'un client ou d'un membre du personnel. 2.1.2 Biens et environnement de sécurité L environnement de sécurité comprend : les hypothèses de sécurité retenues ; elles traduisent les contraintes qui s'exercent sur le système étudié par le biais de ses interfaces avec son environnement. les politiques de sécurité organisationnelles ; elles traduisent les règles à respecter. les menaces. Elles sont habituellement exprimées en précisant : l'agent menaçant, pour lequel il est recommandé de décrire : o la motivation ; o l'expertise ; o les moyens financiers. l'attaque, pour laquelle il est recommandé de décrire : o la ou les méthodes d'attaque ; o la ou les vulnérabilités exploitées ; o l'opportunité, c'est à dire les conditions préalables à satisfaire pour pouvoir être en mesure de réaliser l'attaque. le Bien visé. Le caractère générique de ce profil ne permet pas de décrire tous les biens. 10 / 123
C'est pourquoi une menace y est définie par un libellé qui regroupe : un type d'attaque ; un ou plusieurs agents menaçants ; un ou plusieurs Biens visés. 2.1.3 de sécurité Les objectifs de sécurité, regroupés par domaine, expriment les protections permettant de : contrer les menaces identifiées ; prendre en compte les hypothèses de sécurité ainsi que les politiques de sécurité organisationnelles. 2.1.4 Exigences de sécurité Rappel ; les exigences de sécurité traduisent les objectifs de sécurité conformément au formalisme des Critères Communs. Les exigences de sécurité sont de deux catégories : exigences de sécurité fonctionnelles ; exigences de sécurité d assurance. Les exigences fonctionnelles portent sur les fonctions du système qui contribuent à la sécurité. Les exigences d'assurance portent sur tout le cycle de vie du système. Elles ont pour but de garantir que les fonctions de sécurité mises en œuvre respectent les objectifs de sécurité. 2.2 Rôle de la maîtrise d ouvrage et de la maîtrise d œuvre 2.2.1 Maîtrise d ouvrage La maîtrise d ouvrage (MOA) définit le cahier des charges du service bancaire à ouvrir sur Internet, notamment en termes de sécurité. Pour cela elle utilise les objectifs de sécurité du profil de protection. 2.2.2 Maîtrise d œuvre La maîtrise d œuvre (MOE) conçoit le service bancaire et / ou financier sur Internet défini dans le cahier des charges de la MOA. Elle utilise le Profil de Protection comme référence pour identifier et spécifier les exigences de sécurité que doit satisfaire la Cible de Sécurité, qui, contrairement au Profil de Protection, dépend de l implémentation. Le tableau ci-dessous synthétise l utilisation du Profil de Protection pour les deux catégories de public visé. Phase Pour la maîtrise d ouvrage, utilisation du PP comme : Pour la maîtrise d œuvre, utilisation du PP comme : Définition Guide et référence pour formuler les objectifs de sécurité du cahier des charges du service bancaire et / ou financier sur Internet qu elle commandite. Évaluation Guide pour déterminer les niveaux d assurance requis. Référence pour interpréter les exigences fonctionnelles et formuler les spécifications fonctionnelles pour les cibles d évaluation et de sécurité. Référence pour interpréter les exigences d assurance et déterminer les approches d assurance des cibles d évaluation et de sécurité. 11 / 123
3 EXPRESSION DU BESOIN DE SECURITE Ce chapitre regroupe les chapitres imposés par les Critères Communs suivants : Introduction Description de la cible d'évaluation Environnement de sécurité de la cible d'évaluation de sécurité 3.1 Introduction 3.1.1 Description générale du Profil de Protection (PP) Ce PP définit le niveau minimum de sécurité pour un Service Bancaire et / ou Financier transactionnel sur Internet (SBFI). Réalisé par la communauté bancaire et financière française conformément à la recommandation du Livre Blanc "Internet : quelles conséquences prudentielles?" (1 ère édition de décembre 2000), il a été élaboré en tenant compte de textes à portée européenne et internationale. Il a pour but de constituer le référentiel de sécurité d'un système fournissant un SBFI, pouvant impliquer l'accès en temps réel à un Système de Production Bancaire et / ou Financier (SPBF) qui participe à la réalisation d'un SBFI. Ce PP concerne la sécurité technique et organisationnelle d'un SBFI et participe, directement ou indirectement, à la couverture des risques : Les principaux risques couverts sont : risques juridiques ; Ils sont liés au non-respect des règles en vigueur dans les pays concernés. Ces règles sont de multiples natures : statut et protection du client (capacité des clients à effectuer des opérations bancaires et financières, droit à la consommation, condition de majorité ou de capacité juridique, conditions d accès au type de service proposé) ; forme de la prestation de services envisagée (forme des contrats conclus électroniquement, conditions déclaratives ou les obligations de vérification, règles applicables à l information des investisseurs, modalités d'obtention d'un agrément ) ; fiscalité, preuve risque de perte de maîtrise de l'outil informatique, conduisant les systèmes d'information (SI) des établissements à ne plus offrir le niveau de sécurité et de service garanti à l utilisateur ; S'agissant de services en ligne, ces risques sont de même nature que les risques traditionnels. Ils nécessitent des mesures techniques, organisationnelles (rôles et responsabilités), administratives (procédures, consignes ) ou relevant de la sécurité physique (dispositif anti-intrusion, contrôle des accès physique, sécurité incendie ). risque de réputation ; L'utilisation d'internet augmente le danger d une perte de crédibilité de la part du public et non seulement des clients face à des dysfonctionnements : problèmes techniques, fraudes, malversations, déni de service, détournements d'utilisation, propagandes répréhensibles. Les dysfonctionnements constatés dans un établissement ou les incidents rencontrés peuvent ternir sa réputation et le déstabiliser.de plus, ils comportent un risque de contagion à l encontre de la communauté bancaire et financière dans son ensemble. 12 / 123
risques en matière de blanchiment ; Trois facteurs aggravent les risques de blanchiment dans le cas de services en ligne : la facilité d'accès à un service sans contrainte géographique (matérielle ou temporelle), la dématérialisation, la rapidité de prise en compte des ordres. risques terroristes, qui peuvent cibler les infrastructures vitales pour déstabiliser, voire paralyser les systèmes financiers. Ce PP présente deux caractéristiques fondamentales : il fait abstraction de tout produit ou architecture technique. La cible d'évaluation ou TOE (Target Of Evaluation) porte sur un ou des SBFI dont le PP formalise les exigences de sécurité. Les fonctions de sécurité répondant aux exigences de sécurité seront réparties sur divers composants matériels et / ou logiciels de la TOE ; il concerne une grande variété de SBFI. De ce fait, ce PP contient des objectifs et/ou exigences «conditionnels». Pour une cible d'évaluation (TOE) donnée, certains objectifs et certaines exigences fonctionnelles sont sans objet car ils ne correspondent pas aux éléments existants dans le SBFI. Il est donc indispensable que l'utilisation de ce PP fasse suite à une analyse de risques spécifique à la TOE afin d'adapter les protections au contexte. Cette analyse de risques doit aboutir : 1. à la détermination des objectifs et exigences de sécurité fonctionnelles contenues dans le PP qui sont applicables ; 2. à la définition d'exigences de sécurité pouvant compléter celles du PP. Afin de mettre en exergue la nécessité de cette analyse de risques, cette dernière fait l'objet d'une Hypothèse de sécurité. 3.1.2 Identification du Profil de protection Ce profil de protection a pour titre : Profil de Protection pour services bancaires et / ou financiers sur Internet. Son numéro de version est V7. Il est enregistré dans le catalogue des profils de protection certifiés de la DCSSI sous le numéro <à enregistrer>. Il est rédigé conformément à la norme ISO/IEC 15408 : 1999 (parties 1 à 3). Il concerne un système des Technologies de l'information (TI) et non un produit au sens de l'iso/iec 15408. Un Système TI est un ensemble d'éléments matériels et / ou logiciels de traitement de l'information sous forme électronique ayant une finalité et un environnement opérationnel donnés. 3.1.3 Conventions Ce PP définit un certain nombre de termes. Chaque fois qu'ils sont employés, ils sont écrits avec leur initiale en majuscule. Il définit également des acronymes pour faciliter la lecture. Dès qu'un acronyme est défini il est systématiquement utilisé. Les acronymes définis dans ce PP correspondent à des expressions françaises. Ils côtoient des acronymes issus de l'iso/iec qui correspondent à des expressions anglaises. Le glossaire figurant en annexe regroupe tous les termes et acronymes employés dans le PP. 13 / 123
3.2 Description de la cible d évaluation 3.2.1 Concepts et définitions 3.2.1.1 Établissement agréé responsable d'un service bancaire et / ou financier Un établissement est dit agréé lorsqu'il a reçu une autorisation pour fournir des services bancaires et / ou des services financiers de la part de l'autorité compétente. L'autorisation est appelée agrément. Un SBFI est sous la responsabilité d'un établissement agréé. Cet établissement est appelé établissement agréé responsable de SBFI (EARS). 3.2.1.2 Canaux Un Canal de communication est un moyen d'échange d'informations sous forme électronique entre deux Systèmes TI. Note d'application : Quand des données électroniques sont échangées à l'aide d'un support de données (bande, disquette ), il ne s'agit pas d'un Canal. Un Canal véhicule uniquement des flux logiques. Un Canal Ouvert est un Canal qui n'est pas contrôlé par l'ears. Un Canal Contrôlé est un Canal qui est contrôlé par l'ears et qui apporte des garanties que tous les Systèmes TI qui y ont accès sont autorisés. Le contrôle effectué peut reposer sur des mécanismes logiques et / ou physiques. Un Canal Internet est un Canal Ouvert empruntant Internet. 3.2.1.3 Utilisateur Un Utilisateur est une personne physique qui accède via un Canal Internet à un service bancaire et / ou un service financier. Trois types d'utilisateurs sont définis : l'utilisateur anonyme ne fournit pas d'informations d'identification au cours de l'accès au service ; Par exemple, une personne qui consulte simplement le site http://www.l_etablissement.fr pour obtenir la valeur du CAC 40 est un Utilisateur anonyme. l'utilisateur identifié mais non vérifié ; Dans ce cas, les informations d'identification fournies par l'utilisateur le sont sous sa responsabilité et ne sont pas vérifiées par l'ears. Par exemple, une personne qui fournit ses nom, prénom et adresse afin de recevoir de la documentation est un Utilisateur identifié mais non vérifié. l'utilisateur identifié et vérifié, qui fournit des informations d'identification et d'authentification vérifiées sous la responsabilité de l'ears. Par exemple, une personne qui a saisi son identifiant puis son mot de passe pour passer un ordre de virement de compte à compte est un Utilisateur identifié et vérifié. Il n'existe pas de correspondance exacte entre les trois types d'utilisateurs précédemment définis et la notion de client. Dans la suite du PP, un Utilisateur est considéré comme identifié et vérifié. 14 / 123
3.2.1.4 Transaction bancaire et / ou financière sur Internet Une transaction bancaire et / ou financière sur Internet (Transaction) est une opération ordonnée via Internet par un Utilisateur identifié et vérifié. Elle est prise en compte, par un EARS reconnu comme agréé, par l'utilisateur, au moyen d un acquittement renvoyé à l Utilisateur en temps réel. Une Transaction est constituée d'une suite d'opérations élémentaires, elle doit avoir un début et une fin. La fin est matérialisée par l'acquittement, qui confirme la prise en compte de la Transaction. Même si l'acquittement ne parvient pas à l'utilisateur (quelle qu'en soit la raison), l'opération est enregistrée et constitue une Transaction. Les opérations élémentaires de traitement d'une Transaction peuvent ne pas être terminées quand la Transaction est acquittée. A titre d'exemple, une liste non exhaustive de Transactions est donnée en annexe. Les Transactions présentent des sensibilités variées. Leur sensibilité est notamment fonction : de leur périmètre (Transactions intra-établissement, Transactions impliquant plusieurs établissements) ; de leurs caractéristiques propres (limite par ordre et limite du cumul sur une période donnée ) ; de caractéristiques propres à l'utilisateur (profil ) ; du cadre légal et réglementaire. Ce PP distingue deux catégories de Transactions selon leur sensibilité : les Transactions présentant un risque opérationnel élevé ; les autres Transactions. La distinction de ces deux catégories de Transactions est l'un des deux «éléments variables» du PP. En effet, le PP concerne ainsi des TOE traitant : soit de Transactions «normales» ; soit de Transactions présentant un risque opérationnel élevé ; soit de Transactions des deux catégories. Pour une TOE donnée, l'ears doit classifier les Transactions dans le cadre de l'analyse de risques mentionnée au paragraphe 3.1.1. Le paragraphe 3.2.5 précise les répercussions, sur le reste du PP, de la prise en considération des éléments variables. 3.2.1.5 Service bancaire et / ou financier sur Internet Un service bancaire et / ou financier sur Internet (SBFI) est un service bancaire et / ou financier accessible via un Canal Internet et impliquant une Transaction. 3.2.1.6 Système fournissant un ou des services bancaires et / ou financiers sur Internet Un Système SBFI est un système fournissant un ou des SBFI. 15 / 123
3.2.2 Vue d'ensemble de la fourniture d'un service bancaire et / ou financier sur Internet La fourniture d'un SBFI implique au moins deux Systèmes TI : l'équipement de l'utilisateur ; le Système SBFI. En outre, un ou plusieurs systèmes de production bancaires et / ou financiers (SPBF) peuvent intervenir pour certaines Transactions. Equipement Utilisateur Transaction sans accès SPBF Transaction avec accès SPBF Système SBFI SPBF Canal Internet Figure 1 : Vue d'ensemble de la fourniture d'un SBFI Notes d'application : Les équipements des Utilisateurs et des Fournisseurs sont par défaut non sûrs Les Acteurs ayant les Rôles Utilisateur ou Fournisseur de données constituent des populations très variées et non contrôlées par l'ears. Il est ainsi exclu de considérer que tous emploient un équipement ayant : les mêmes propriétés de sécurité ; au moins un certain niveau de sécurité. De ce fait leurs équipements doivent être considérés comme non sûrs Les équipements des Exploitants, des Administrateurs, des Chargés de clientèle ainsi que les SPBF sont contrôlés mais considérés comme non sûrs au sens de l ISO/IEC 15408 Les équipements de ces Acteurs sont contrôlés par l'ears, qui prend un soin particulier pour les sécuriser, notamment les SPBF. Néanmoins ils sont considérés comme non sûrs au sens de l'iso/iec 15408 parce que le fait de désigner l'un de ces équipements comme étant de confiance au sens de la norme nécessite au préalable son évaluation 1 ou du moins d'avoir prouvé qu'il dispose de fonctions de sécurité adaptées. 3.2.3 Acteurs et Rôles Un Acteur est une personne physique qui interagit avec la TOE. Un Rôle est un ensemble de règles définissant les interactions autorisées entre la TOE et un Acteur ou un Système TI externe à la TOE. Un rôle traduit des responsabilités. Les rôles définis sont : Utilisateur ; Ce Rôle est alloué aux Acteurs que sont les Utilisateurs (considérés comme identifiés et vérifiés), ou aux Systèmes TI agissant au nom de ces Acteurs. 1 Cf. la norme, paragraphe 1.3 du tome 2, alinéa 21. 16 / 123
Fournisseur de données ; Ce Rôle est alloué aux Acteurs ou Systèmes TI externes à la TOE responsables de la fourniture de données à la TOE. Par exemple, les sociétés transmettant des informations financières sont des Fournisseurs de données (Bloomberg, Fininfo ). Chargé de clientèle ; Ce Rôle est alloué aux Acteurs placés sous la responsabilité de l'ears et qui utilisent la TOE pour dialoguer de manière interactive avec un Utilisateur, ou aux Systèmes TI agissant au nom de ces Acteurs. SPBF ; Ce Rôle est alloué aux Systèmes TI externes à la TOE que sont les SPBF. Exploitant ; Ce Rôle est alloué aux Acteurs ou Systèmes TI externes qui ont la responsabilité de surveiller et faire fonctionner la TOE et qui emploient un accès logique à la TOE (par exemple : exploitant système, équipe de maintenance). Dans certains cas, l'accès logique est précédé d'un accès physique à la TOE. C'est par exemple le cas pour le changement d'une carte réseau défectueuse. Administrateur ; Ce Rôle est alloué aux Acteurs ou Systèmes TI externes qui ont la responsabilité de définir et contrôler le fonctionnement de la TOE et qui emploient un accès logique à la TOE (par exemple : administrateur système, administrateur sécurité, administrateur fonctionnel, webmestre). Dans certains cas, l'accès logique est précédé d'un accès physique à la TOE. C'est par exemple le cas pour l'initialisation de certains équipements cryptographiques. Certains Acteurs peuvent accéder à la TOE sous des Rôles différents. Les formulations du type "les Acteurs ayant le Rôle Utilisateur ( )" sont lourdes. Dans la suite du document et quand il n'y aura pas d'ambiguïté, des formulations abrégées seront utilisées pour faire référence aux Acteurs. Elles consistent à donner aux Acteurs le nom de leur Rôle (un Utilisateur, des Utilisateurs, un Exploitant ). 3.2.4 Modélisation de la cible d'évaluation 3.2.4.1 Modèle d Architecture fonctionnelle d'un Système SBFI et de son environnement L architecture fonctionnelle d'un Système SBFI et de son environnement est composée de Blocs fonctionnels, c'està-dire d ensembles de fonctions contribuant à un même objectif. 17 / 123
Système SBFI Fournisseur de données Ouvert ou Contrôlé Accueil Fournisseurs de données Contrôlé Réception n 1 Réception n 2 Contrôlé SPBF... Utilisateur Canal Internet (Ouvert) Contrôlé Accueil Etablissement pour Utilisateurs Contrôlé Accueil Guichet pour Utilisateurs Contrôlé SBFI n 1... Canal Internet (Ouvert) Exploitant Contrôlé Canal Internet (Ouvert) Administrateur Contrôlé Accueil Exploitants et Administrateurs Contrôlé Exploitation Détection intrusions... Contrôlé SBFI n i... Système de surveillance Contrôlé Chargé de clientèle Un rectangle aux bordures fines représente un Bloc fonctionnel, un rectangle aux bordures épaisses réprésente un Système TI externe. Les accès devant être gérés sur la base d'un Rôle, c'est celui-ci qui est indiqué pour identifier le système TI externe ou l'acteur. Aucune donnée ne figure sur le schéma car il est considéré que l'accès à une donnée est effectué à l'aide d'un Bloc fonctionnel. - Le Bloc fonctionnel "Accueil Etablissement pour Utilisateurs" a au moins les fonctions : * d'identifier et authentifier sans ambiguïté le Système SBFI auprès de l'utilisateur ; * de mener clairement au guichet. - Le Bloc fonctionnel "Accueil Guichet pour Utilisateurs" a au moins les fonctions : * d'identifier l'utilisateur, ou de s'assurer que son identification a été faite ; * de présenter clairement les SBFI fournis à l'utilisateur, en fonction de son identification ; * de donner accès au SBFI demandé. - Un Bloc fonctionnel "SBFI n i" a au moins les fonctions : * d'authentifier l'utilisateur, ou de s'assurer que son authentification a été faite ; * de fournir le SBFI demandé, en fonction des droits de l'utilisateur. - Le Bloc fonctionnel "Accueil Fournisseurs de données" a au moins les fonctions : * d'identifier et authentifier sans ambiguïté le Système SBFI auprès du Fournisseur de données ; * d'identifier le Fournisseur de données ; * de donner accès au Bloc fonctionnel gérant la réception de données concernée. - Un Bloc fonctionnel "Réception n i" a au moins les fonctions : * d'authentifier le Fournisseur de données, ou de s'assurer que son authentification a été faite ; * de gérer la réception de données concernée, en fonction des droits du Fournisseur de données. - Le Bloc fonctionnel "Accueil Exploitants et Administrateurs" a au moins les fonctions : * d'identifier le Système SBFI ; * d'identifier et authentifier l'exploitant et l'administrateur ; * de proposer les fonctions d'exploitation ou administration autorisées, en fonction des droits de l'acteur. - Les Blocs fonctionnels "Exploitation", "Détection d'intrusions"... offrent les fonctions d'exploitation/administration accessibles. - Le Bloc fonctionnel "Système de surveillance" regroupe toutes les fonctions de surveillance. Figure 2 : Modèle fonctionnel d'un Système SBFI L architecture fonctionnelle d'un Système SBFI repose sur les principes suivants : les Blocs fonctionnels concernent exclusivement un (ou plusieurs) SBFI ; Les services qui ne sont pas des SBFI sont pris en charge par des Blocs différents de ceux figurant sur le schéma. 18 / 123
les Blocs fonctionnels "Accueil Établissement pour Utilisateurs", "Accueil Guichet pour Utilisateurs" et "SBFI n i" sont volontairement distincts ; chaque Bloc fonctionnel doit faire l'objet de mécanismes empêchant son contournement ; En particulier, un Acteur ayant le Rôle Utilisateur ne doit pas pouvoir accéder au Bloc fonctionnel "Accueil Guichet pour Utilisateurs" sans être passé par le bloc "Accueil Établissement pour Utilisateurs". Note d'application : Le non-contournement s'applique aux Blocs fonctionnels, pas aux fonctions de sécurité auxquelles ceux-ci font appel (authentification, contrôle d'accès logique ). les fonctions d'identification, d'authentification et de gestion des droits, faisant partie intégrante du Système SBFI, ne sont pas forcément spécifiques à un Bloc fonctionnel. Par exemple : l'identification d'un Utilisateur peut être réalisée avant le Bloc fonctionnel "Accueil Guichet pour Utilisateurs" ; l'authentification d'un Utilisateur peut être réalisée avant un Bloc fonctionnel "SBFI n i" ; les Blocs fonctionnels "Accueil Guichet pour Utilisateurs" et "SBFI n i" peuvent demander à un Utilisateur de s'authentifier alors que celui-ci l'a déjà été. En outre, le procédé d'authentification peut être différent ; les droits d'accès d'un Utilisateur à un SBFI peuvent être vérifiés avant un Bloc fonctionnel "SBFI n i". 3.2.4.2 Portée de la cible d'évaluation La TOE est le Système SBFI précédemment modélisé. La TOE inclut la documentation associée, destinée aux différents Rôles. Sont exclus de la TOE : les services qui ne sont pas des SBFI (par exemple de nature non transactionnelle) ; les services fournis aux Utilisateurs par un Canal différent du Canal Internet (accès Minitel par exemple) ; les Systèmes TI que sont les équipements de connexion des Acteurs, et en particulier des Utilisateurs ; les Systèmes TI destinés à secourir tout ou partie des SBFI ; le Système TI de contrôle des accès physiques. Le cycle de vie d'un Système TI comporte au moins les phases : conception réalisation (conception et réalisation constituent souvent deux phases distinctes), qualification, production, évolution du système (maintenance). Ce PP prend en compte la TOE en phase de production. 3.2.5 Éléments variables de la TOE La nature fonctionnelle du PP ainsi que la diversité des SBFI pris en compte a conduit à introduire la notion «d éléments variables». Un élément variable étant une spécificité fonctionnelle que l on ne retrouve pas forcément dans tous les SBFI. Chaque TOE doit faire l'objet d'une analyse de risques effectuée par l'ears et prenant en compte ces éléments variables. Ce paragraphe présente ces éléments, avec pour chacun d eux : les répercussions sur le PP, notamment concernant les objectifs et exigences fonctionnelles applicables ; la présentation adoptée afin de rendre explicites et claires les règles de sélection des objectifs et exigences applicables. Les éléments variables sont : 1. la distinction de deux catégories de Transactions : les transactions «normales» et celles présentant un «risque opérationnel élevé» ; remarque : ce concept est introduit au paragraphe 3.2.1.4 relatif aux Transactions. L'analyse de risques menée par l'ears doit préciser la catégorie de chaque Transaction. Cette distinction permet de préciser les deux types d' suivants : ceux communs à toutes les Transactions, quelle que soit leur catégorie ; 19 / 123
ceux spécifiques aux Transactions présentant un risque opérationnel élevé. remarque 1 : le libellé d'un Objectif spécifique aux Transactions présentant un risque opérationnel élevé précise explicitement que l'objectif porte uniquement sur cette catégorie de Transactions. remarque 2 : certaines exigences fonctionnelles s'appliquent uniquement à un Objectif spécifique à une Transaction présentant un risque opérationnel élevé. Cette information est mise en évidence à l'aide d'une note d'application située après le texte du composant fonctionnel, qui stipule que : «Cette exigence est nécessaire pour satisfaire l'objectif OT.xxx, spécifique aux Transactions présentant un risque opérationnel élevé». 2. la prise en compte de "caractéristiques de sécurité" de certains Biens, qui ne peuvent être précisées dans le PP en termes de besoins en disponibilité et / ou intégrité et / ou confidentialité et / ou non-répudiation. Cet élément variable :concerne les Biens et leurs besoins de sécurité. Il sera détaillé dans le chapitre suivant ( 3.3) concernant l'environnement de sécurité de la TOE). Son existence repose sur le constat suivant : les Biens, par exemple ceux transitant entre l'utilisateur et la TOE, auront des besoins de sécurité différents selon la TOE : besoin en intégrité seul, en confidentialité et intégrité, en non-répudiation, en disponibilité, etc. Au stade du PP, il est impossible de définir une liste de Biens dont on connaît les besoins précis en disponibilité et / ou intégrité et / ou confidentialité et / ou non-répudiation. La prise en compte de "caractéristiques de sécurité" a les répercussions suivantes : plusieurs stipulent dans leur libellé la nécessité de protéger des Biens "conformément à leurs caractéristiques de sécurité", les exigences fonctionnelles relatives aux traitant de la protection conformément aux "caractéristiques de sécurité" des Biens ont été définies selon deux principes : a) faire en sorte qu'à chaque besoin en disponibilité, intégrité, confidentialité ou non-répudiation correspondent au moins une exigence fonctionnelle ; b) ne pas être trop contraignant de façon à laisser aux établissements une marge de manœuvre (matérialisée par les protections supplémentaires susceptibles d'être définies à l'issue de l'analyse de risques qu'ils doivent faire) ; le fait qu'une exigence fonctionnelle participe à la satisfaction d'un objectif relatif à la protection, conformément à des "caractéristiques de sécurité", est mis en évidence à l'aide d'une note d'application située après le texte du composant fonctionnel. Ce texte stipule que : «Cette exigence est nécessaire pour satisfaire l'objectif OT.xxx, relatif à des protections conformes aux «caractéristiques de sécurité» des Biens, pour ce qui concerne : les <Biens Acteur ou Biens SBFI> ; ayant un besoin en : <disponibilité ou intégrité ou confidentialité ou non-répudiation>. Note(s) d'application : Ce PP ne comporte pas d'hypothèse spécifique aux Transactions présentant un risque opérationnel élevé : quel que soit le type d'une Transaction, les hypothèses sur l'usage attendu de la TOE ou sur ses conditions d'emploi sont identiques. Ce PP ne comporte pas de Menace spécifique aux Transactions présentant un risque opérationnel élevé : le type d'une Transaction ne modifie pas la nature des risques, mais éventuellement leurs conséquences. Ce PP n'envisage aucune répercussion sur les exigences d'assurance ou le niveau de résistance des fonctions associé à certaines exigences fonctionnelles. Ces aspects font partie de la marge de manœuvre des établissements à l'issue de leur analyse de risques. 20 / 123