Profil de Protection pour services bancaires et / ou financiers sur Internet. Version : V7 Date : 4 août 2004

Transcription

1 Profil de Protection pour services bancaires et / ou financiers sur Internet Version : V7 Date : 4 août 2004

2 Sommaire 1 DU LIVRE BLANC AU REFERENTIEL DE SECURITE MISSION CONFIEE AU CFONB PAR LE SECRETARIAT GENERAL DE LA COMMISSION BANCAIRE UN REFERENTIEL DE SECURITE, POUR QUI? UN REFERENTIEL DE SECURITE, SOUS QUELLE FORME? SPECIFICITES DES ETABLISSEMENTS BANCAIRES ET FINANCIERS Contrôle interne Lutte contre le blanchiment Risque juridique Agrément des établissements CHAMP D'APPLICATION DU REFERENTIEL SECURITE POINTS FORTS DE LA DEMARCHE Reconnaissance internationale du référentiel certifié selon les Critères Communs Utilisations du référentiel DEMARCHE RETENUE PAR LE CFONB PRINCIPE Définition du système cible et analogie avec le guichet bancaire Biens et environnement de sécurité de sécurité Exigences de sécurité ROLE DE LA MAITRISE D OUVRAGE ET DE LA MAITRISE D ŒUVRE Maîtrise d ouvrage Maîtrise d œuvre EXPRESSION DU BESOIN DE SECURITE INTRODUCTION Description générale du Profil de Protection (PP) Identification du Profil de protection Conventions DESCRIPTION DE LA CIBLE D EVALUATION Concepts et définitions Vue d'ensemble de la fourniture d'un service bancaire et / ou financier sur Internet Acteurs et Rôles Modélisation de la cible d'évaluation Éléments variables de la TOE ENVIRONNEMENT DE SECURITE DE LA CIBLE D EVALUATION Biens de la TOE Hypothèses Politiques de sécurité organisationnelles Menaces OBJECTIFS DE SECURITE Obligations Politique de sécurité Conception & développement Contrôle et suivi Cryptographie Sécurité physique Sécurité logique EXIGENCES DE SECURITE / 123

3 4.1 EXIGENCES FONCTIONNELLES ET D'ASSURANCE Exigences fonctionnelles Exigences d'assurance NOTES D'APPLICATION ARGUMENTAIRE ANNEXES BIBLIOGRAPHIE ACRONYMES, GLOSSAIRE ET TERMINOLOGIE Acronymes Glossaire Terminologie relative aux exigences d'assurance CLASSES DE TRANSACTIONS ET TRANSACTIONS DOMAINES DE SENSIBILITE AUX RISQUES CARACTERISTIQUES DE SECURITE DE LA CIBLE D'EVALUATION Caractéristiques des nouvelles architectures Bonnes pratiques de protection MAINTENANCE DE L'ASSURANCE Famille Plan de maintenance de l assurance [AMA_AMP] Famille Rapport de classification des composants de la TOE [AMA_CAT.1] Famille Preuve de la maintenance de l assurance [AMA_EVD] Famille Analyse d impact sur la sécurité [AMA_SIA] LISTE DES PARTICIPANTS DU GROUPE DE TRAVAIL "PROFIL DE PROTECTION" / 123

4 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 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 / 123

5 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 (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 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 du 25 juillet 1990 qui fixe, pour les établissements assujettis, la nature des contrôles internes ; 5 / 123

6 règlement n du 25 juillet 1990 relatif au risque de taux d'intérêt sur les opérations de marché ; règlement n 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 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é 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 Risque juridique En plus du Code pénal (articles à ), l article 14 du règlement N 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 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

7 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 et L 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

8 1.6 Points forts de la démarche 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 (Critères Communs) garantit sa reconnaissance par tous les états signataires 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

9 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 :1999 : (partie 1) Introduction et modèle général ; ISO/IEC :1999 : (partie 2) Exigences fonctionnelles de sécurité ; ISO/IEC :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é 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

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

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

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

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

14 3.2 Description de la cible d évaluation Concepts et définitions É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) 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 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 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

15 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 Le paragraphe précise les répercussions, sur le reste du PP, de la prise en considération des éléments variables 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 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

16 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 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 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 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 / 123

17 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 ) Modélisation de la cible d'évaluation 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

18 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

19 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" 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 É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 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

20 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

21 3.3 Environnement de sécurité de la cible d évaluation Ce chapitre décrit : les Biens de la TOE ; les Hypothèses ; les Politiques de Sécurité Organisationnelles (OSP) ; les Menaces qui portent sur les Biens Biens de la TOE Les Biens faisant partie de la TOE. sont : des Biens SBFI ; des Biens Acteur. Les Biens SBFI sont : les logiciels et programmes de la TOE dont le bon fonctionnement est nécessaire pour garantir la sécurité de la TOE (il s'agit par exemple des mécanismes cryptographiques) les données d'identification et authentification, qui servent : soit à identifier et authentifier un Acteur (cf. l'osp P.ID&A_ACTEUR qui stipule que tout Acteur doit être authentifié avant d'accéder à un Bien) ou un Système TI externe à la TOE (SPBF par exemple) ; soit à identifier et authentifier la TOE auprès d'un Système TI externe (l'équipement d'un Utilisateur par exemple). les secrets, qui servent à assurer la confidentialité de données. Il s'agit par exemple des mots de passe (sous leur forme interne gérée par la TOE) et des secrets cryptographiques. Les secrets cryptographiques sont constitués : des clés cryptographiques ; des autres données nécessaires aux mécanismes cryptographiques (valeurs initiales ). les données de configuration de la sécurité, qui permettent d'adapter le comportement de la TOE en termes de sécurité. Il s'agit par exemple des règles de filtrage des accès, des règles de gestion des habilitations, des caractéristiques de journalisation. les données d'activité sécurité, qui sont définies afin de rendre compte de l'état du système. Il s'agit par exemple du contenu des journaux et des données constituées à des fins statistiques. Les Biens Acteur peuvent être : relatifs à un acteur donné (données spécifiques aux échanges entre un Acteur donné et la TOE). relatifs à chacun des Acteurs. Remarque : les Biens Acteur d'un Utilisateur sont les données nécessaires pour traiter les Transactions de cet Utilisateur et qui sont spécifiques à celui-ci. Ils varient selon les Transactions (pour mémoire, une liste indicative de Transactions figure en annexe). 21 / 123

22 Les abréviations suivantes sont utilisées par la suite : Bien Biens Acteur Biens Acteur relatifs à un Acteur Bien(s) SBFI de type logiciels et programmes Bien(s) SBFI de type données d'identification et authentification Bien(s) SBFI de type secrets Bien(s) SBFI de type données de configuration de la sécurité Bien(s) SBFI de type données d'activité sécurité Note(s) d'application : Biens Acteur Abréviation Biens relatifs à un Acteur Programme(s) Authentifiant(s) Secret(s) Tableau 1 : Abréviations des Biens Configuration(s) Journal(aux) Les Biens ont été définis de façon à faciliter la correspondance avec les «données utilisateurs» et les «données concernant les fonctions de sécurité de la TOE ou «TSF» (TOE Security Fonctions)» au sens des Critères Communs : o les Biens Acteur sont les «données utilisateur» ; o les Biens SBFI sont les «données de la TSF». Les Authentifiants peuvent avoir un besoin de confidentialité et des Secrets peuvent servir à authentifier. Ces deux types de Biens peuvent donc avoir une intersection non vide comme indiqué dans les Critères Communs. Compte tenu de la variété des Transactions et des autres opérations prises en compte par le PP, les Biens Acteur relatifs à un Acteur ou à un type d'acteurs ne peuvent être précisés davantage, ni les besoins de sécurité associés. Prenons l'exemple de la consultation d'un compte. Il est possible que les Biens et leurs besoins de sécurité, varient en fonction : o de l'établissement ; o du système au sein d'un même établissement ; o de l'utilisateur (poids financier, historique dans l'établissement ). Précision concernant la typologie des données impliquées dans l'authentification d'un Acteur : Prenons le cas où une partie d'une Transaction est protégée par SSL, l'utilisateur s'authentifiant à la demande du serveur Web par mot de passe (le serveur pilote l'authentification de l'utilisateur, pas SSL) : o Le mot de passe saisi par l'utilisateur n'est pas un Bien (ou fourni par son navigateur si cette option est possible et a été retenue) car il est en dehors de la TOE. o La donnée correspondante, qui transite vers la TOE : n'est pas un Bien si elle correspond au mot de passe saisi chiffré par SSL est un Bien si le mot de passe saisi a subi une transformation sous le contrôle de la TOE (chiffrement, hachage), mais pas un Authentifiant (car ce n'est pas une donnée de la TSF) Par exemple, le serveur Web, via du code mobile (applet JAVA ), peut hacher le mot de passe avant de le donner au tunnel SSL. 22 / 123

23 o La donnée conservée par la TOE, qui, par confrontation avec celle transmise protégée par SSL, permet de s'assurer de la validité du mot de passe, est un Authentifiant (et un Secret). Ces deux données ne sont pas forcément identiques. La donnée conservée par la TOE peut être le résultat d'un calcul (de hachage par ex.). Et aussi : o La clé de session SSL est un Bien (mais pas un Secret car ce n'est pas une donnée de la TSF). o La clé privée du serveur (associée à son certificat X509), qui permet l'authentification du serveur, est un Authentifiant (et un Secret). A un Acteur peuvent être associées (cf. notamment la note d'application précédente) : o plusieurs données d'identification ; o plusieurs données d'authentification (en nombre pas forcément égal à celui des données d'identification). Exemples de Biens Acteur relatifs à un Utilisateur : o Soldes de comptes o Historiques d'opérations sur un compte o Seuils (découvert autorisé ) 23 / 123

24 3.3.2 Hypothèses Les Critères Communs distinguent les Hypothèses : relatives à l'usage attendu de la TOE ; relatives à l'environnement d'emploi de la TOE. Une abréviation est associée à chaque Hypothèse. Son format est Hx.yyy, où : x peut prendre les valeurs 'T' pour une Hypothèse portant sur l'usage attendu de la TOE, et 'E' pour une Hypothèse portant sur l'environnement d'emploi ; yyy indique le sujet sur lequel porte l'hypothèse Protections adaptées aux risques L'EARS a procédé à une analyse de risques spécifique à la TOE afin de mettre en place des protections adaptées : [HE.ANALYSE_RISQUES] L analyse de risques permettra en particulier : la détermination des objectifs et exigences fonctionnelles contenues dans le PP qui sont applicables compte tenu des éléments variables, à savoir : la présence ou non de Transactions présentant un risque opérationnel élevé ; les caractéristiques de sécurité des Biens ; la définition des exigences de sécurité spécifiques au contexte de la TOE et pouvant compléter celles définies dans ce PP. Ce PP concerne une grande variété de TOE et ne peut fixer toutes les protections requises pour toutes les TOE. Pour une TOE donnée, il est primordial que chaque EARS effectue une analyse de risques spécifique afin de déterminer toutes les protections requises pour réduire les risques à un niveau qu'il juge acceptable. Un exemple de protection spécifique à une TOE est la limitation des montants des opérations à l'aide de seuils. Notes d'application : Les de sécurité spécifiques aux Transactions présentant un risque opérationnel élevé sont : OT.AUTH_FORTE_UTILISATEUR OE.ELEMENTS_AUTH_UTILISATEUR OT.PREUVE_TRANSACTION Les portant sur les "caractéristiques de sécurité des Biens" sont : OT.PROTECTION_BIENS_TRANSMIS OT.PROTECTION_BIENS_STOCKES OE.ELEMENTS_AUTH_UTILISATEUR Illustration de l'impossibilité de définir dans le PP les caractéristiques de sécurité des Biens : Les Biens sont définis de manière fonctionnelle. Notamment les Biens Acteurs et parmi eux les Biens relatifs à un Utilisateur. Il est donc impossible de définir précisément leurs caractéristiques de sécurité (besoins DICP). Exemple : pour la consultation d'un compte, il est possible que les Biens associés et leurs besoins de sécurité, varient en fonction : o de l'établissement ; o du système au sein d'un même établissement ; o de l'utilisateur (poids financier, historique dans l'établissement ). 24 / 123

25 Cette Hypothèse présente une particularité par rapport aux autres : elle requiert qu'une tâche relative à la sécurisation de la TOE, une analyse de risques, soit effectuée avant la rédaction de la cible de sécurité, et que ses résultats soient exploités lors de la rédaction de la cible. L'analyse de risques préalable conduit à des protections qui doivent a priori être mises en œuvre : o dans la TOE ; o dans l'environnement de la TOE. Cette Hypothèse est à satisfaire avant la mise en production de la TOE et concerne donc son environnement Acteurs de confiance Les Acteurs ayant les Rôles Exploitant, Administrateur ou Chargé de clientèle sont de confiance [HE.ACTEURS_DECONFIANCE] Cette Hypothèse stipule que les Acteurs pouvant avoir les Rôles mentionnés sont de confiance, c'est-à-dire : qu'ils ne font pas d'erreur ; qu'ils ne sont pas malveillants. Cette Hypothèse a pour conséquence que toutes les Menaces envisagées dans ce PP sont externes. Les agents menaçants (au sens des Critères Communs «CC») ne peuvent être des Exploitants, des Administrateurs ou des Chargés de clientèle. En outre, aucune vulnérabilité liée à ces personnels ne peut être prise en compte (par exemple. : collusion, oubli d'une consigne) Acteurs compétents Les Acteurs ayant les Rôles Exploitant, Administrateur ou Chargé de clientèle disposent des compétences et des moyens nécessaires pour mener à bien leurs missions [HE.COMPETENCE] Cette Hypothèse concerne tous les Acteurs ayant les Rôles Exploitant ou Administrateur ou Chargé de clientèle. Il convient : de s'assurer que le personnel intervenant sur la TOE est compétent et formé ; de s'assurer que les équipes sont suffisamment dimensionnées pour absorber la charge de travail ; de donner au personnel les moyens techniques leur permettant d'effectuer leurs missions dans de bonnes conditions Responsabilité s Les contrats formalisent les Rôles et responsabilités respectifs des Acteurs de la TOE [HE.CONTRATS] La définition des Rôles et responsabilités de chacun est primordiale pour la sécurité. Cette Hypothèse concerne tous les Acteurs et en particulier les Utilisateurs. Elle s'applique aussi dans les cas où l'ears délègue une partie de la maîtrise d'œuvre à des organismes tiers (hébergement d'une partie de la TOE). Le terme contrat désigne tout document formalisant les Rôles et responsabilités ayant une valeur juridique. Des formes de contrat différentes tenant compte du type d'acteurs sont envisageables. Par exemple, le contrat d'un Utilisateur et celui d'un Exploitant peuvent avoir des formes distinctes. Il est rappelé que certains Acteurs peuvent se connecter sous plusieurs Rôles. Note d'application : L'Hypothèse requiert que des contrats existent et portent sur l'environnement de la TOE Contrat avec l'utilisateur Toute Transaction s'effectue dans un cadre contractuel entre l'utilisateur et l'ears [HE.CONTRAT_UTILISATEUR] La finalité de cette Hypothèse est de protéger l'utilisateur et l'ears, en requérant l'existence d'un contrat, qui doit : 25 / 123

26 préciser les législations et réglementations en vigueur qui s imposent tant à l Utilisateur qu à l EARS ; préciser de manière expresse les modes de preuve propres à la prise en compte des Transactions, dans le respect de la réglementation en vigueur ; être rédigé avec un souci de clarté, afin d'être compréhensible pour l'utilisateur ; avoir un contenu tenant compte du profil de l'utilisateur (par exemple : clientèle particulière, clientèle professionnelle ) ; être communiqué clairement à l'utilisateur ; préciser ses modalités de résiliation Accès physiques et sécurité physique La TOE met en œuvre un contrôle des accès physiques aux locaux abritant des Biens, en fonction d un Rôle [HE.ACCES_PHYSIQUES] Cette Hypothèse requiert que : tous les constituants de la TOE soient situés dans des locaux faisant l'objet d'un contrôle des accès physiques ; les accès soient gérés en tenant compte des Rôles définis. La TOE est située dans des locaux disposant de mesures de sécurité physique définies dans le cadre de l'analyse de risques spécifique à la TOE réalisée par l'ears [HE.PROTECTION_PHYSIQUE] HE.ACCES_PHYSIQUES traite le contrôle des accès physiques. Cette Hypothèse porte donc sur toutes les autres protections relatives à la sécurité physique, par exemple : anti-intrusion, sécurité incendie, alimentation en fluide Accès logiques L Utilisateur et le Fournisseur de données identifient et authentifient la TOE [HE.IDEN_AUTHEN_TOE] 26 / 123

27 3.3.3 Politiques de sécurité organisationnelles La Politique de sécurité organisationnelle est l'ensemble formalisé et validé des règles, procédures, codes de conduite ou lignes directrices de sécurité qu une organisation impose pour son fonctionnement [cf norme ISO/IEC 15408]. Une règle peut être : technique, c'est-à-dire appeler une architecture, un paramétrage ou une configuration particulière apte à la satisfaire, en matière de sécurité logique ou de sécurité des accès physiques ; Par exemple, la règle stipulant que tout flux non explicitement autorisé doit être rejeté par un pare-feu et enregistré, est technique. non technique, c'est-à-dire appeler une organisation (responsabilités), une procédure ou un comportement. Par exemple, la règle stipulant que toutes les interventions sur un serveur doivent être décrites dans une main courante n'est pas technique. Une abréviation est associée à chaque OSP. Son format est P.yyy où yyy indique le sujet sur lequel porte l'osp Respect du modèle d architecture fonctionnelle (Blocs fonctionnels et Canaux) La TOE doit être conforme au modèle d architecture fonctionnelle figurant dans ce PP (Blocs fonctionnels et Canaux) [P.MODELISATION] Il est rappelé (cf. le paragraphe "Architecture Modèle d Architecture fonctionnelle d'un Système SBFI et de son environnement") que : les échanges de la TOE avec une entité externe peuvent emprunter plusieurs types de Canaux, dont un Canal Ouvert ou un Canal Internet et un Canal Contrôlé ; les échanges de la TOE avec un SPBF ou un Chargé de clientèle empruntent nécessairement des Canaux Contrôlés ; les échanges internes à la TOE empruntent nécessairement des Canaux Contrôlés. Un Canal Ouvert a été précédemment défini comme un Canal n'étant pas contrôlé par l'ears donc non sûr (la réciproque n'est pas vraie). Le contournement d'un Bloc fonctionnel doit être empêché [P.NON_CONTOURNEMENT] La TOE doit être conçue de façon à empêcher le contournement d'un Bloc fonctionnel Vulnérabilités de conception La TOE ne doit fournir que les fonctions pour lesquelles elle a été conçue, dans le but d'empêcher les vulnérabilités de conception [P.FONCTIONS] La finalité de cette OSP est de réduire les vulnérabilités de conception Algorithmes et protocoles cryptographiques La TOE doit faire appel à des algorithmes et / ou protocoles cryptographiques ayant prouvé leur résistance, et doit permettre le renouvellement des secrets [P.CRYPTO] La finalité de cette OSP est de garantir que les calculs les plus sensibles de la TOE emploieront des mécanismes résistants. Elle requiert donc l'emploi d'algorithmes et protocoles cryptographiques dont la résistance est reconnue. Il convient de préciser que : les algorithmes et protocoles cryptographiques doivent être distingués de leurs mises en œuvre. Par exemple, RSA est un algorithme dont la mise en œuvre logicielle peut varier en résistance (et en performances) selon le codage effectué ; 27 / 123

28 le choix d'algorithmes ou protocoles standardisés ou normalisés (et donc publics) n'est pas imposé ; Gestion des éléments cryptographiques Les règles de gestion des secrets cryptographiques de la TOE doivent être résistantes, formalisées et validées [P.CRYPTO_GESTION] Les secrets cryptographiques sont extrêmement sensibles. La finalité de cette OSP est de protéger leur gestion, à savoir l'ensemble des actions les concernant : génération, stockage, transport, renouvellement, révocation, archivage Il convient de préciser que le renouvellement des secrets cryptographiques n'est pas imposé. En revanche, cette OSP requiert que leur renouvellement soit prévu dès la conception afin de pouvoir être effectué rapidement en cas de besoin. Les règles doivent être résistantes de façon à garantir la sécurité des actions touchant aux secrets cryptographiques Isolation des éléments cryptographiques Au sein de la TOE les secrets et mécanismes cryptographiques doivent être isolés et protégés contre les attaques physiques et logiques [P.ISOLATION_SECRETS_CRYPTO] Il est primordial que les secrets et mécanismes cryptographiques : soient clairement identifiés ; fassent l'objet de mesures de contrôle d'accès physique et / ou logique spécifiques Sécurité en phase de conception - réalisation La sécurité doit être prise en compte dès la conception de la TOE [P.CONCEPTION] Cette OSP requiert que lors de la phase de conception réalisation de la TOE, un soin particulier soit apporté : à la définition des futures caractéristiques de sécurité du système ; à la vérification de la conformité et de l'efficacité de ces caractéristiques (exemples : contrôle des accès physiques et logiques à l'environnement de développement, emploi d'un modèle formel de sécurité pour la conception) Phase de qualification La TOE doit être qualifiée d'un point de vue fonctionnel et technique avant sa mise en production, en faisant appel à un organe indépendant et compétent pouvant être interne à l'ears [P.QUALIFICATION] La finalité de cette OSP est de s'assurer que, au début de la phase de production, ce qui va devenir la TOE a les caractéristiques de sécurité attendues. Elle requiert que des analyses et des tests soient effectués afin de vérifier que la TOE a les caractéristiques de sécurité attendues, en termes de conformité et d'efficacité. La qualification doit être effectuée par un organe indépendant dont la compétence est reconnue. Celui-ci n'est pas nécessairement externe à l'ears., mais il doit être indépendant des équipes ayant conçu, réalisé et intégré la TOE Contrôle des accès logiques Les accès logiques à la TOE doivent faire l'objet d'une politique de sécurité basée sur les notions d'identité et de Rôle. Les Acteurs doivent avoir uniquement accès aux fonctions nécessaires à leurs tâches dans le Rôle qui leur est imparti [P.ACCES_LOGIQUES] La finalité de cette OSP est de garantir que : les règles de protection des accès logiques sont formalisées et validées ; les accès sont au moins gérés d'après un Rôle ; les accès sont tous imputés. Le contrôle des accès logiques peut être exercé à des niveaux variés, par exemple : 28 / 123

29 l'url d'accès à la TOE ; les ressources du site (pages HTML, servlets, JSP ) et leurs champs (XML ) ; les méthodes invoquées (dans le cas d'une TOE utilisant les langages orientés objet) ; les bases de données. La TOE doit mettre à disposition de l utilisateur et du fournisseur de données, les moyens de l identifier et de l authentifier.[p. IDEN_AUTHEN_TOE] La finalité de cette OSP est de garantir que le site atteint par les utilisateurs et les fournisseurs de données n est pas un site usurpé Maîtrise des échanges Les échanges internes et avec l'extérieur de la TOE doivent faire l'objet d'une politique de maîtrise des échanges garantissant que les entités émettrices et destinataires sont autorisées [P.FLUX] La finalité de cette OSP est de ne laisser passer que les échanges entre entités autorisées. Elle requiert que les règles de maîtrise des échanges soient formalisées et validées. Les échanges ne sont pas nécessairement automatisés. Par exemple, l'envoi d'un support de données contenant des Biens vers un lieu de stockage constitue un échange. Dans la suite du PP, les transferts de Biens sous forme électronique mais à l'aide d'un support physique (par exemple une bande) sont appelés "transferts physiques". Les autres transferts de données sont appelés "flux logiques". La maîtrise des échanges implique des dispositifs techniques et non techniques Protection contre les rebonds La TOE doit être conçue et gérée de façon à empêcher un rebond depuis la TOE vers un équipement tiers [P.REBOND] Un rebond est l'action d'une personne malveillante cherchant à réaliser une attaque logique sur un système tiers à partir d'une machine de la TOE sur laquelle il a, au préalable, gagné un accès non autorisé. Cette action peut entraîner de lourdes conséquences sur l'ears, notamment en termes d image. Le rebond correspond à une menace portant sur une machine située en dehors de la TOE, donc sur des éléments qui ne sont pas considérés comme un Bien dans ce PP (car tous les Biens font partie de la TOE). En revanche, la protection contre cette menace requiert la mise en œuvre de protections dans la TOE. C'est pourquoi la menace de rebond est prise en compte sous forme d'osp Protection contre les mystifications de la TOE La TOE doit être conçue et gérée de façon à empêcher sa mystification [P.MYSTIFICATION_TOE] La mystification de la TOE est l'action d'une personne malveillante cherchant à contrefaire la TOE afin de glaner des informations confidentielles relatives aux Utilisateurs, en premier lieu les informations d'identification et d'authentification. Elle peut porter atteinte à la vie privée d'utilisateurs et avoir de lourdes conséquences sur l'ears notamment en termes de réputation ou en cas d'action judiciaire à son encontre, La mystification de la TOE correspond à une menace portant sur une machine située en dehors de la TOE, donc sur des éléments qui ne sont pas considérés comme un Bien dans ce PP (car tous les Biens font partie de la TOE). En revanche, la protection contre cette menace requiert la mise en œuvre de protections dans la TOE. C'est pourquoi la menace de mystification est prise en compte sous forme d'osp. 29 / 123

30 Consentement de l'utilisateur La TOE doit s'assurer du consentement explicite de l'utilisateur avant la prise en compte d'une Transaction [P.CONSENTEMENT_UTILISATEUR] La finalité de cette OSP est de protéger l'utilisateur d'une Transaction involontaire ou erronée. Le consentement de l'utilisateur doit être de qualité. Les dispositions garantissant la qualité du consentement de l'utilisateur doivent être formalisées et validées. Elles doivent notamment prendre en considération les risques de clic ou double-clic malencontreux. Au minimum, le consentement de l'utilisateur doit être explicite Confirmation de l'utilisateur Pour une Transaction présentant un risque opérationnel élevé, la TOE doit obtenir de l Utilisateur une réponse explicite à sa demande de confirmation avant de valider son consentement [P.CONFIRMATION_UTILISATEUR] Cette OSP vient en complément de P.CONSENTEMENT_UTILISATEUR pour exiger, dans le cas des Transactions présentant un risque opérationnel élevé, que l'utilisateur valide son consentement après que la TOE lui ait transmis une demande de confirmation de prise en compte de la Transaction Piste d'audit La TOE doit conserver un historique des Transactions ayant valeur de piste d'audit [P.PISTE_AUDIT] Cette OSP requiert que la TOE conserve un historique des Transactions permettant :de reconstituer l'ordre chronologique des opérations élémentaires associées à chaque Transaction ; La TOE doit protéger l'intégrité et la confidentialité des informations de l'historique et de les conserver conformément à la réglementation en vigueur Relevé de Transaction Toute Transaction modifiant un Bien Acteur d'un Utilisateur doit inclure l'envoi d'un Relevé de Transaction à l'utilisateur [P.RELEVE_TRANSACTION] La finalité de cette OSP est de permettre à l'utilisateur de recevoir un résumé de chaque Transaction modifiant un Bien Acteur. Il convient de noter que : le Relevé de Transaction peut parvenir à l'utilisateur par un autre Canal (exemple d'un message SMS envoyé au téléphone portable de l'utilisateur alors que celui-ci a effectué la Transaction depuis un ordinateur) ; le Relevé de Transaction peut parvenir en différé à l'utilisateur (exemple d'un message électronique envoyé à l'utilisateur). 30 / 123

31 Preuve d'une Transaction présentant un risque opérationnel élevé Pour une Transaction présentant un risque opérationnel élevé, l'ears doit être en mesure : [P.PREUVE_TRANSACTION] de justifier que la Transaction a été initiée par l'utilisateur ; de justifier que la Transaction est conforme à celle initiée par l'utilisateur ; d'apporter la preuve du moment de réception de la confirmation de l'utilisateur. Cette OSP requiert l'existence et la conservation d'une preuve pour les Transactions présentant un risque opérationnel élevé, conformément à la réglementation en vigueur. La valeur probante d'un faisceau d'éléments est déterminée par l'autorité judiciaire. Cette OSP s'appuie donc sur d'autres aspects de la sécurité, et notamment sur ceux abordés dans : HE.CONTRAT_UTILISATEUR (les modes de preuve ne reposent pas forcément sur une signature électronique. Si le mode de preuve adopté n'est pas fondé sur une signature électronique, il doit faire l'objet d'une convention de preuve annexée au contrat conclu avec l'utilisateur) ; P.CONSENTEMENT_UTILISATEUR et P.CONFIRMATION_UTILISATEUR ; P.CRYPTO et P.CRYPTO_GESTION ; P.PISTE_AUDIT Oppositions La TOE doit savoir : [P.OPPOSITION_SBFI] mettre en opposition un SBFI suite à la demande d'un Utilisateur ; accepter ou refuser de fournir un SBFI en fonction de la mise en opposition ou non de ce service pour l'utilisateur concerné. Faire opposition est un moyen de lutter contre les usurpations d'identité et de compte, ou contre les falsifications d'opérations. Il importe de pouvoir faire opposition à un SBFI spécifique, car les autres moyens de lutte contre ces attaques peuvent varier selon le SBFI (exemple d'un SBFI impliquant une Transaction présentant un risque opérationnel élevé et réclamant une authentification plus résistante). La mise en opposition doit pouvoir être réalisée par l'utilisateur, pour un SBFI qui le concerne. Notes d'application : Cette OSP autorise les mises en opposition par un Acteur qui n'est pas Utilisateur. Cette OSP n'impose pas que la TOE gère l'intégralité de la mise en opposition d'un SBFI par un Utilisateur (ce qui correspond au cas où la mise en opposition est une Transaction). Par exemple, les mises en oppositions peuvent être initiées via un Canal qui n'est pas un Canal Internet (téléphone, Minitel ) puis être transmises à la TOE Formalisation, validation, diffusion et contrôle de la sécurité La sécurité de la TOE et de son environnement doit être placée sous la responsabilité d'un organe unique situé au niveau hiérarchique adapté, chargé notamment de valider la Politique de sécurité de la TOE [P.RESPONSABILITE_TOE] La Politique de sécurité de la TOE doit être formalisée avant d'être validée. Afin de garantir la prise en compte de la sécurité, il importe que celle-ci soit de la responsabilité d'un organe unique. Celui-ci ne peut être précisé ici car il dépend de la TOE et de son environnement. En revanche il devra être indiqué dans la Cible de sécurité Contrôle interne La TOE doit être incluse dans le processus de contrôle interne de l'ears, ce qui implique que le processus de contrôle interne de l'ears vérifie la conformité à la Politique de sécurité de la TOE [P.CONTROLE] un 31 / 123

32 La finalité de cette OSP est de détecter a posteriori les violations de la Politique de sécurité de la TOE. Elle requiert la mise en place de contrôles permettant de vérifier le respect et la correcte mise en œuvre de ce qui est formalisé : la Politique de sécurité de la TOE (cf. P.RESPONSABILITE_TOE). Il est recommandé que : certains contrôles reposent à la fois sur des vérifications régulières et inopinées ; les procédés de vérifications consistent en recueils d'informations sur un mode déclaratif (informations recueillies en interviews par exemple) et en recueils "de visu" (audits techniques, tests, emploi de scanners de vulnérabilités ) Surveillance La surveillance de la TOE doit détecter les violations de la Politique de sécurité de la TOE, et le cas échéant alerter qui de droit [P.SURVEILLANCE] La violation de la Politique de sécurité de la TOE peut résulter de la survenance d'un accident, d'une erreur ou d'une malveillance. On considère qu'une tentative de violation est une violation. Les règles de surveillance sont techniques et non techniques. Elles doivent comporter : des règles de détection, qui doivent notamment exploiter les informations collectées au titre de la veille sécurité (cf. P.MAINTENANCE_SECU) : règles visant à détecter des tentatives de violation de la Politique de sécurité de la TOE ; règles visant à détecter après coup des violations de la Politique de sécurité de la TOE ; des règles d'alerte, visant à réagir le plus vite et le plus efficacement possible en cas de violation de la Politique de sécurité de la TOE suspectée ou avérée Veille et maintenance sécurité Les éléments de la TOE doivent faire l'objet d'une veille sécurité et d'une maintenance sécurité permanentes [P.MAINTENANCE_SECU] La finalité de cette OSP est la mise en place d'un processus permanent de suivi et d'adaptation aux évolutions : des menaces (par exemple les nouvelles techniques d attaques, la propagation fulgurante d un virus, l activité suspecte de groupes malveillants...) ; des vulnérabilités (par exemple la publication de nouvelles failles dans les produits en production) ; des produits et des technologies capables de contribuer à renforcer la sécurité Trace Les événements les plus sensibles de la TOE doivent être enregistrés de manière à pouvoir être tracés et imputés [P.TRACE] Les événements suivants au moins sont enregistrés : connexions et déconnexions des Acteurs ; affectations et retraits de privilèges à un Acteur ; opérations de gestion des acteurs ayant des privilèges (Administrateurs et Exploitants) ; opérations de gestion d'un secret cryptographique (par ex. : génération, révocation) ; accès et flux illicites (tentatives incluses) Disponibilité Un plan d'action doit être défini afin de faire face aux événements impactant fortement la disponibilité de la TOE [P.CONTINUITE] La finalité de cette OSP est de définir les règles de réaction à un événement touchant fortement la disponibilité de la TOE. 32 / 123

33 Elle requiert que les responsabilités et les règles de réaction soient formalisées et validées, et traitent notamment : la gestion des incidents impactant fortement la disponibilité ; le maintien en conditions opérationnelles ; la gestion des crises. Il convient de noter que : la définition du plan impose au préalable de définir les exigences en termes de continuité de service, et donc en particulier de spécifier les fonctions vitales devant être conservées (par exemple, il est possible que l'une des premières actions inscrites dans le plan consiste à couper la TOE du réseau Internet) ; le plan peut inclure un plan de reprise d'activité Gestion des incidents de sécurité Les règles de gestion des incidents de sécurité concernant la TOE doivent être formalisées et validées [P.GESTION_INCIDENTS] La finalité de cette OSP est de réduire les dommages issus d'un incident. Elle requiert que les règles de réaction et de gestion associées soient formalisées et validées. Elles doivent traiter notamment : les mesures conservatoires ; la collecte des éléments de preuve ; le retour au fonctionnement normal ; le dépôt de plaintes par l'ears (dans le cas d'une malveillance). Les règles doivent notamment s'appuyer sur les informations enregistrées au titre des traces et de la piste d'audit (cf. P.TRACE et P.PISTE_AUDIT) Vie privée Les règles d'application de la réglementation en vigueur concernant le respect de la vie privée d'un Utilisateur de la TOE doivent être formalisées et validées [P.VIE_PRIVEE] Cette OSP requiert le respect du cadre juridique en vigueur en matière de protection de la vie privée et oblige à préciser comment il est décliné en règles concernant les Utilisateurs Gestion des configurations et des changements Tous les éléments constituant la TOE doivent faire l'objet d'une gestion de configuration formalisée et validée [P.GESTION_CONFIG] La finalité de cette OSP est de connaître dans le détail et avec de fortes garanties d'exhaustivité tous les éléments de la TOE. Elle requiert qu'une gestion de configuration soit mise en place et que les règles associées soient formalisées et validées Qualification avant modification Toute modification touchant un élément constituant la TOE doit être qualifiée avant sa mise en œuvre par un organe indépendant pouvant être interne à l'ears [P.QUALIFICATION_MODIF] La finalité de cette OSP est d'éviter qu'une modification puisse entraîner une violation de la Politique de sécurité de la TOE. Elle requiert que toute modification de la TOE fasse l'objet d'un processus de qualification, y compris une modification non motivée pour des raisons sécuritaires. La qualification doit être effectuée par un organe indépendant dont la compétence est reconnue. Celui-ci n'est pas nécessairement externe à l'ears. Il doit être indépendant des équipes ayant conçu, réalisé et intégré la modification de la TOE. 33 / 123

34 3.3.4 Menaces Cette section présente successivement, les types d attaques, les Agents menaçants et les Menaces Types d'attaques Les Critères Communs préconisent de décrire chaque attaque à l'aide : d'une ou plusieurs méthodes d'attaque ; d'une ou plusieurs vulnérabilités exploitées ; d'une voire plusieurs opportunités. Compte tenu de la nature des TOE, et de la diversité des architectures possibles : l'expression «type d'attaques» est préférée à «attaque» ; chaque type d'attaque est accompagné d'une liste de méthodes d'attaque fournie uniquement à titre indicatif afin d'illustrer le type d'attaque ; aucune vulnérabilité n'est citée ; aucune opportunité n'est citée. Le tableau suivant présente les types d'attaques retenus, avec pour chacun : Un libellé. Leur nature, c'est-à-dire s'il s'agit : o d'un accident ; o d'une erreur ; o d'une malveillance. La ou les atteintes engendrées, sachant que : o l'atteinte principale figure en MAJUSCULE ; o les atteintes possibles s'expriment en termes d'impact sur les différentes composantes de la sécurité : la disponibilité ('d' ou 'D') ; l'intégrité ('i' ou 'I') ; la confidentialité ('c' ou 'C') ; la composante preuve & contrôle ('p' ou 'P'). Des exemples de méthodes d'attaque. 34 / 123

35 Type d'attaques Nature Atteinte(s) Méthode(s) d'attaque *** Non exhaustif *** Dysfonctionnement technique Accident Dicp Panne Bug / Vice caché Erreur Erreur Dicp Erreur d'utilisation Rejeu involontaire (clic malencontreux ) Vol de données échangées Malveillance logique C Écoute passive Espionnage Branchement pirate Vol de données stockées C Fouille Abus de droits Cryptanalyse C Cryptanalyse Emploi d'un cracker de mots de passe Exploitation illicite de données (hors cryptanalyse) C Analyse de trafic Inférence sur des données Usurpation d'identité d'un Acteur dicp Substitution (spoofing, brute force, attaque statistique, cross site scripting ) Rejeu Intrusion logique (hors usurpation d'identité) dicp Exploitation d'un bug connu Cheval de Troie Balayage (scan de ports ) Trappe / backdoor Altération de données échangées I Interception (attaque man-in-the-middle ) Contrefaçon / invention Altération de données stockées I Abus de droits Défaçage de site Web (tag de la home page) Virus Déni de service distribué D Déni de service distribué Déni sur une liaison D Ver Envoi de paquets en grand nombre Déni sur un serveur D Flooding (SYN Flood ) Buffer overflow Autre déni de service D Blocage de compte Saturation de fichier Destruction de données (stockées) D Effacement de données Virus Bombe logique Répudiation volontaire d'une opération P Répudiation Note(s) d'application : Tableau 2 : Types d'attaques Les types d'attaque ci-dessous ne sont pas retenus car ils sont traités par des Hypothèses : o les événements naturels (incendie, dégâts des eaux ) et les attaques physiques (intrusion physique, sabotage ) ; o les erreurs émanant des Acteurs sous contrôle de l'ears (Exploitants, Administrateurs et Chargés de clientèle) ; o les malveillances émanant des Acteurs sous contrôle de l'ears (Exploitants, Administrateurs et Chargés de clientèle) ; o les attaques via un SPBF. 35 / 123

36 Les types d'attaques "Déni de service" concernent uniquement les dénis reposant sur la saturation d'une ressource. Les autres moyens pour effectuer des dénis de service sont exclus : o la destruction logique de données de configuration (ces attaques relèvent du type d'attaque "Destruction de données") ; o la destruction ou la modification physique d'un équipement (traité par une Hypothèse). Les rebonds entrants (précédant des tentatives d'intrusion) ne sont pas considérés comme un type d'attaque mais comme des conditions préalables (parmi d'autres, éventuellement) Agents menaçants Le PP vise des TOE qui doivent être protégées contre les attaques des Agents menaçants suivants : Un Pirate informatique, défini comme étant un individu voire un groupe d'individus : sachant traquer et utiliser les programmes malveillants qui sont accessibles sur le Net, et sachant adapter des programmes d'attaque ou en créer s'il dispose d'un mode d'emploi pouvant disposer de beaucoup de temps disposant de moyens modérés : emploi d'un ou plusieurs ordinateurs "standards" ; capable d'adapter des équipements spécifiques (par ex. pour espionner des communications sansfil). Note(s) d'application : Le Pirate informatique est donc un attaquant de moyenne envergure, dont le "terrain de prédilection" est Internet (même si la définition englobe les attaques effectuées via d'autres Canaux). Volontairement, la liste des Agents menaçants ne contient pas les organisations mafieuses, les concurrents (français ou étranger), etc. Le profil de protection a vocation à constituer le référentiel de sécurité minimum pour la profession bancaire et / ou financière. Dès lors, il est cohérent de limiter les agresseurs à ceux de moyenne envergure. Un Utilisateur ou un Fournisseur de données défaillant, c'est-à-dire faisant une erreur quelle qu'en soit la cause : inadvertance, défaut d'ergonomie Un Utilisateur ou un Fournisseur de données malveillant, c'est-à-dire faisant une action malveillante quelle qu'elle soit, en profitant de son accès autorisé à la TOE. Note(s) d'application : Utilisateur et Fournisseur de données malveillants sont distingués du Pirate informatique car leurs attaques tirent exclusivement profit de leur accès autorisé. Un cas particulier est celui des répudiations. Par exemple, la répudiation d'une Transaction ne peut être le fait d'un Pirate informatique. Un Utilisateur qui tente une action malveillante n'exploitant pas le fait qu'il est identifié et vérifié est considéré comme un Pirate informatique. Les autres Acteurs (Exploitants, Administrateurs et Chargés de clientèle) ne sont pas des Agents menaçants, ce qui est cohérent avec l'hypothèse HE.ACTEURS_DECONFIANCE. 36 / 123

37 Menaces Une abréviation est associée à chaque Menace. Son format est M.yyy, où yyy indique le sujet de la Menace. Erreur d'un Utilisateur ou d'un Fournisseur de données, touchant potentiellement tout Bien [M.ERREUR] Cette Menace concerne tous les types d'erreurs qu'un Utilisateur ou un Fournisseur de données est susceptible de faire, quelle que soit la cause : manque d'information, inadvertance, défaut d'ergonomie La Menace concerne avant tout les Biens relatifs à l'acteur impliqué mais on ne peut exclure des atteintes : sur les Biens d'autres Acteurs de même Rôle ; sur les Biens d'acteurs ayant un autre Rôle ou sur les Biens SBFI. Comme indiqué dans le tableau Tableau 2 : Types d'attaques, les atteintes peuvent concerner toutes les composantes de la sécurité. Note d'application : Les autres Acteurs ne peuvent faire d'erreurs car ils sont supposés compétents et disposant de moyens suffisants (HE.COMPETENCE) Dysfonctionnement technique, touchant potentiellement tout Bien [M.DYSFONCTIONNEMENT] Cette Menace concerne tous les types de dysfonctionnements techniques, par exemple : bug, vice caché. Comme indiqué dans le tableau Tableau 2 : Types d'attaques, les atteintes peuvent concerner toutes les composantes de la sécurité. Perte de confidentialité suite au vol de données échangées sur un Canal Ouvert, par un Pirate informatique, touchant potentiellement tout Bien ayant un besoin de confidentialité [M.VOL_OUVERT] Cette Menace recouvre toutes les attaques permettant de recueillir des données au cours de leur transit mais sans les détruire (sinon, c'est de l'altération). La Menace recouvre les actions malveillantes effectuées : depuis un accès gagné sur l'équipement d'un Utilisateur ou d'un Fournisseur de données ; via un autre accès au Canal. La Menace concerne les Biens transitant par un Canal Ouvert : Canal Internet ou autre. Les Biens visés par un Pirate informatique peuvent être, par exemple : des Biens Acteur relatifs à un Utilisateur, comme : o un ou des secrets (par exemple, une clé de session SSL) ; o des informations confidentielles car protégées par le secret bancaire ; o d'autres informations confidentielles ; des Biens Acteur relatifs à un Fournisseur de données ; des Biens Acteur relatifs à un Exploitant ou un Administrateur ; des Biens SBFI, par exemple du code mobile téléchargé sur un navigateur. Comme indiqué dans le tableau Tableau 2 : Types d'attaques, les atteintes concernent uniquement la composante confidentialité. Note d'application : Le pirate peut éventuellement être un Utilisateur ou un Fournisseur de données malveillant. 37 / 123

38 Perte de confidentialité suite au vol de données échangées sur un Canal Contrôlé, par un Fournisseur de données malveillant ou un Pirate informatique ayant gagné un accès à l'équipement d'un Fournisseur de données, touchant potentiellement tout Bien ayant un besoin de confidentialité [M.VOL_CONTROLE] Cette Menace recouvre toutes les attaques permettant de recueillir des données au cours de leur transit mais sans les détruire (sinon, c'est de l'altération). Cette Menace est très similaire de M.VOL_OUVERT. Les Biens pouvant être touchés ainsi que les attaques sont analogues à ceux de M.VOL_OUVERT. La différence réside dans le type de Canal. Comme indiqué dans le tableau Tableau 2 : Types d'attaques, les atteintes concernent uniquement la composante confidentialité. Note(s) d'application : Le vol de données pendant un échange nécessite un accès au Canal sur lequel elles transitent. Par définition, quand le Canal est Contrôlé, tous les systèmes TI qui y ont accès sont autorisés. Dans cette situation, le seul risque de vol provient d'une personne malveillante ayant accès à l'un des systèmes TI connecté ou faisant partie du Canal Contrôlé. Compte tenu d'une part des Canaux pouvant être Contrôlés (cf. le schéma Figure 2 : Modèle fonctionnel d'un Système SBFI), et d'autre part des Hypothèses sur les Acteurs de confiance (HE.ACTEURS_DECONFIANCE) il s'ensuit que la Menace ne peut être le fait que d'un : o Fournisseur de données malveillant ; o Pirate informatique ayant gagné un accès à l'équipement d'un Fournisseur de données et l'exploitant, probablement dans une perspective de rebond entrant (pour gagner un accès à la TOE). M.VOL_CONTROLE et M.VOL_OUVERT sont distinguées afin de mettre en relief l'importance du type de Canal. Accès illicite aux données stockées dans la TOE, par un Utilisateur ou un Fournisseur de données malveillant ou par un Pirate informatique, touchant potentiellement tout Bien ayant un besoin de confidentialité [M.VOL_STOCKAGE] Cette Menace recouvre toutes les attaques permettant de recueillir des données stockées, comme : la fouille (consiste à étudier méthodiquement l'ensemble des fichiers et des variables d'un système pour en retirer des informations utiles) ; l abus de droits. La Menace peut viser tout Bien stocké dans la TOE, dès lors que ce dernier a un besoin en confidentialité. Comme indiqué dans le tableau Tableau 2 : Types d'attaques, les atteintes concernent uniquement la composante confidentialité. Note d'application : La Menace ne concerne pas le vol d'un support de données. En effet, voler un support nécessite d'y avoir physiquement accès. Or la TOE est supposée protégée contre les accès physiques non autorisés (cf. HE.ACCES_PHYSIQUES). Les protections contre les attaques physiques sont du ressort de l'environnement de la TOE. 38 / 123

39 Perte des protections offertes par des moyens de chiffrement touchant un Secret [M.CRYPTANALYSE] La réalisation de la Menace est toujours soumise à une condition préalable : le vol des données utiles à la cryptanalyse (stockées ou échangées). Comme indiqué dans le tableau Tableau 2 : Types d'attaques, les atteintes concernent uniquement la composante confidentialité. Note(s) d'application : La perte de protection peut résulter par exemple d attaques par cryptanalyse. La cryptanalyse est une forme d analyse d'un système de cryptographie et/ou de ses données en entrée et en sortie de manière à identifier les variables confidentielles et/ou sensibles ainsi que le texte en clair. La cryptanalyse recouvre une grande variété de méthodes d'attaques. Bon nombre d'entre elles requièrent une expertise technique voire des moyens financiers élevés. Seules les méthodes d'attaques qui sont à la portée du Pirate informatique tel que défini dans le paragraphe sont à prendre en considération au titre du PP. Ainsi : l'emploi d'un cracker de mot de passe (disponibles sur le Net) est dans le périmètre du PP ; le cassage d'un mécanisme cryptographique tel qu'un algorithme de chiffrement est hors périmètre. L'accès illicite à un équipement chiffrant permet de réaliser des actions de cryptanalyse. Les Hypothèses sur les protections physiques et le contrôle des accès physiques conduisent à écarter cela des conditions préalables à la réalisation de la Menace. Détournement de données par un Utilisateur ou un Fournisseur de données malveillant ou par un Pirate informatique, en vue de porter atteinte à la confidentialité de tout bien de la TOE [M.EXPLOITATION_DONNEES] Cette Menace recouvre toutes les formes d'exploitation, sauf la cryptanalyse, de données destinées à comprendre le fonctionnement d'une partie de la TOE, afin, ultérieurement, de tenter d'autres attaques. Les attaques ultérieures envisageables peuvent être des intrusions ou des falsifications (dans un but de fraude par exemple.). La réalisation de la Menace est toujours soumise à une condition préalable : le vol des données. Comme indiqué dans le tableau Tableau 2 : Types d'attaques, les atteintes concernent uniquement la composante confidentialité. Perte de confidentialité et d intégrité des données suite à une usurpation d'identité d'un Utilisateur, par un Pirate informatique, touchant l'authentifiant de cet Utilisateur [M.USURP_UTILISATEUR] Cette Menace consiste à se faire passer pour un autre, quelle que soit la manière, par exemple : emploi de l'authentifiant préalablement volé ; rejeu ; découverte de l'authentifiant (par brute force par ex.). Les attaques peuvent être classées en deux catégories : celles soumises à une condition préalable, le vol des données utiles, et éventuellement à la cryptanalyse des données volées ; celles qui cherchent à découvrir l'authentifiant. 39 / 123

40 Certaines réalisations de la Menace mettent en danger d'autres voire tous les autres Authentifiants. Cela accroît leur gravité. Suite à l'usurpation d'identité d'un Utilisateur, des atteintes : aux Biens relatifs à cet Utilisateur ; voire à d'autres Biens, sont possibles. Note d'application : La Menace est uniquement le fait d'un Pirate informatique, mais celui-ci peut être par ailleurs un Utilisateur. Perte de confidentialité et d intégrité des données suite à une usurpation d'identité d'un Acteur autre qu'un Utilisateur, par un Pirate informatique, touchant l'authentifiant de cet Acteur [M.USURP_ACTEUR] Cette Menace consiste à se faire passer pour un autre, quelle que soit la manière. Elle est très similaire de M.USURP_UTILISATEUR. La différence réside dans les Acteurs concernés. Note(s) d'application : cf. M.USURP_UTILISATEUR. Perte de disponibilité, de confidentialité et d intégrité des données suite à une intrusion logique via le Canal Internet, par un Utilisateur ou un Fournisseur de données malveillant ou par un Pirate informatique, touchant potentiellement tout Programme [M.INTRU_INTERNET] Cette Menace recouvre toutes les attaques réalisées par le biais du Canal Internet et permettant de gagner un accès illicite à la TOE, quel qu'il soit, à l'exclusion de celles qui relèvent de l'usurpation d'identité. Potentiellement tout Programme peut être touché. Dans la pratique, il s'agit essentiellement de ceux situés en frontal du Canal Internet (serveurs Web, programmes de filtrage). Suite à une intrusion logique, tout type d'attaque est envisageable. Il faut donc particulièrement redouter cette Menace. Parmi les méthodes d'attaques possibles, l'exploitation d'un bug connu est particulièrement fréquente. D'où l'importance de mettre en œuvre une veille et une maintenance sécurité. Note d'application : cette Menace est distinguée des autres Menaces relatives à l'intrusion afin de mettre en avant le fait qu'internet est un vecteur d'intrusion très important. Perte de disponibilité, de confidentialité et d intégrité des données suite à une intrusion logique via un Canal Ouvert hors Internet, par un Utilisateur ou un Fournisseur de données malveillant ou par un Pirate informatique, touchant potentiellement tout Programme [M.INTRU_OUVERT] Cette Menace recouvre toutes les attaques d'intrusion réalisées par le biais d'un Canal Ouvert qui n'est pas un Canal Internet, à l'exclusion de celles qui relèvent de l'usurpation d'identité. Note(s) d'application : Cf. M.INTRU_INTERNET Perte de disponibilité, de confidentialité et d intégrité des données suite à une intrusion logique via un Canal Contrôlé, par un Utilisateur ou un Fournisseur de données malveillant ou par un Pirate informatique, touchant potentiellement tout Programme [M.INTRU_CONTROLE] Cette Menace recouvre toutes les attaques d'intrusion réalisées par le biais d'un Canal Contrôlé. Dès lors, il y a une condition préalable : avoir un accès à ce Canal. Note(s) d'application : Cf. M.INTRU_INTERNET 40 / 123

41 Altération de données échangées sur un Canal Ouvert, par un Utilisateur ou Fournisseur de données malveillant ou par un Pirate informatique, touchant potentiellement tout Bien ayant un besoin d'intégrité [M.ALTERATION_OUVERT] Cette Menace recouvre toutes les actions visant l'intégrité de données échangées, soit : la modification ; la suppression ; l'insertion ; La Menace est très similaire de M. ALTERATION_CONTROLE. La différence réside dans le fait qu'elle concerne les Biens transitant par un Canal Ouvert : Canal Internet ou autre. S'agissant d'un Utilisateur ou Fournisseur de données malveillant, la Menace recouvre uniquement les actions de ceux-ci concernant leurs propres échanges avec la TOE (dans l'optique de décortiquer ces échanges pour mieux les exploiter). En effet, le Canal étant Ouvert, les intrusions que l'utilisateur 2 peut faire sur les communications de l'utilisateur 1 sont identiques à celles qu'un Pirate informatique peut faire. S'agissant d'un Pirate informatique, la Menace recouvre les actions malveillantes : effectuées depuis un accès gagné sur l'équipement d'un Utilisateur ou d'un Fournisseur de données ; ou effectuées via un autre accès au Canal. Altération de données échangées sur un Canal Contrôlé, par un Fournisseur de données malveillant ou un Pirate informatique ayant gagné un accès à l'équipement d'un Fournisseur de données, touchant potentiellement tout Bien ayant un besoin d'intégrité [M.ALTERATION_CONTROLE] Cette Menace recouvre toutes les actions visant l'intégrité de données échangées, soit : la modification ; la suppression ; l'insertion ; le retardement. S'agissant d'un Fournisseur de données malveillant, la Menace recouvre : les actions sur ses propres échanges avec la TOE ; les actions sur les échanges d'un autre Fournisseur de données avec la TOE. Les Biens visés (par un Pirate informatique ou un Fournisseur) peuvent être : des Biens Acteur relatifs à un ou à des Fournisseurs, par exemple des informations financières (par exemple la modification de cours de Bourse ) ; d'autres Biens. Si la connexion se fait à l'aide du protocole FTP, il est par exemple envisageable d'essayer de modifier de façon illicite des ressources présentes dans l'arborescence. Note d'application : L'altération de données pendant un échange nécessite un accès au Canal sur lequel elles transitent. Par définition, quand le Canal est Contrôlé, tous les systèmes TI qui y ont accès sont autorisés. Dans cette situation, le seul risque d'altération provient d'une personne malveillante ayant accès à l'un des systèmes TI connecté ou faisant partie du Canal Contrôlé. 41 / 123

42 Compte tenu d'une part des Canaux pouvant être Contrôlés (cf. le schéma Figure 2 : Modèle fonctionnel d'un Système SBFI), et d'autre part des Hypothèses sur les Acteurs de confiance (HE.ACTEURS_DECONFIANCE) il s'ensuit que la Menace ne peut être le fait que : d'un Fournisseur de données malveillant ; d'un Pirate informatique ayant gagné un accès à l'équipement d'un Fournisseur de données et l'exploitant, probablement dans une perspective de rebond entrant (pour gagner un accès à la TOE). Altération de données stockées, par un Utilisateur ou Fournisseur de données malveillant ou par un Pirate informatique, touchant potentiellement tout Bien ayant un besoin d'intégrité [M.ALTERATION_STOCKAGE] Cette Menace recouvre toutes les actions visant l'intégrité de données stockées, en excluant la destruction, soit : la modification ; l'insertion. Cette Menace est soumise à une condition préalable : avoir un accès à la TOE. Perte de disponibilité de tout type de bien suite à un déni de service distribué, effectué par un Pirate informatique, sur des canaux ouverts [M.DENI_DISTRIBUE] Une attaque de déni de service distribué consiste à faire en sorte que de très nombreuses machines envoient au même moment et vers la même cible de nombreux flux. Le résultat est que la liaison d'accès à la TOE concernée sature et qu'il devient impossible d'accéder à la TOE par le Canal concerné. Un déni de service distribué peut être réalisé par un individu unique. Des programmes existent pour ce faire. Ils sont assez faciles à trouver sur Internet. Note(s) d'application : Les dénis de service distribués sont distingués des autres dénis de service car les protections sont différentes. Les dénis de service distribués ne nécessitent pas d'accès préalable à la TOE, et ne peuvent donc être le fait que d'un Pirate informatique. Les dénis de service distribués concernent les Canaux Ouverts. Perte de disponibilité de tout type de bien ayant un besoin de disponibilité, suite à un déni de service effectué par un Pirate informatique, sur un Canal [M.DENI_CANAL] Une attaque de déni de service sur une liaison consiste à faire en sorte de saturer une liaison d'accès à la TOE, donc un Canal. Les dénis de service distribués sont exclus puisqu'ils font l'objet d'une Menace dédiée. Cette liaison d'accès n'est pas forcément la seule visée. Dans le cas d'un ver par exemple, l'attaquant cherche à saturer un réseau. La Menace recouvre deux catégories d'attaques : les vers et virus ; les envois en masse de paquets de données. La Menace concerne tous les types de Canaux. Perte de disponibilité d un serveur, suite à un déni de service effectué par un Pirate informatique [M.DENI_SERVEUR] Une attaque de déni de service sur un serveur consiste à faire en sorte de saturer le serveur dans son ensemble. Les effets attendus sont donc : 42 / 123

43 ralentir voire arrêter le serveur (et tous les programmes qu'il fait tourner) ; créer une brèche dans la sécurité permettant de mener une autre attaque (par ex. une intrusion). La Menace recouvre deux catégories d'attaques : les saturations des capacités réseau du serveur (par ex. : attaque "SYN Flood") ; les saturations d'autres ressources, sur lesquelles le fonctionnement du serveur repose (par exemple. : création de nombreux process, buffer overflow). Ce type de déni de service consiste en attaques visant en premier lieu le fonctionnement de la TOE (donc un Programme). Perte de disponibilité de la TOE suite à un déni de service effectué par un Utilisateur ou Fournisseur de données malveillant ou par un Pirate informatique afin de toucher tous les biens exposés à la saturation et notamment les journaux [M.DENI_SELECTIF] Les autres Menaces de type déni de service correspondent à des attaques cherchant à rendre indisponible un serveur tout entier (en l'attaquant ou l'une de ses liaisons). La présente Menace englobe les autres attaques par saturation, pouvant viser, par exemple : la saturation d'un fichier ou d'un espace de stockage, par exemple : o saturation d'un fichier de logs (cas particulier important) ; le refus d'un service à un Acteur, par exemple : o blocage d'un compte quand on atteint le nombre maximal de tentatives d'authentification autorisées (cas particulier important). La Menace est principalement le fait d'un Pirate informatique. Néanmoins on peut imaginer qu'un Utilisateur, par exemple, veuille saturer un journal afin de ne pas laisser de traces. Note d'application : Il est impossible de préciser toutes les catégories d'attaques qui sont visées par la Menace. Destruction de données stockées, par un Utilisateur ou Fournisseur de données malveillant ou par un Pirate informatique, touchant potentiellement tout Bien [M.DESTRUCTION] La destruction de données stockées consiste à effacer des données. La réalisation de la Menace est toujours soumise à une condition préalable : avoir un accès, licite ou non. Note d'application : La destruction d'une donnée répond à divers buts, par exemple : déni de service (si par exemple on détruit une Configuration) ; suppression de traces. Répudiation volontaire d'une Transaction ou d'une Transaction présentant un risque opérationnel élevé, par un Utilisateur malveillant, touchant les Biens relatifs à cet Utilisateur [M.REPUD_TRANSACTION] Note d'application : La nature de la Transaction n'influe pas sur la Menace, mais sur l'ampleur des impacts quand elle se réalise. Répudiation volontaire relative à une fourniture de données, par un Fournisseur de données, touchant les Biens relatifs à ce Fournisseur de données [M.REPUD_FOURNITURE] Note(s) d'application : Cf. M.REPUD_TRANSACTION. 43 / 123

44 3.4 de sécurité Un Objectif de sécurité est, conformément à la norme ISO/IEC 15408, une expression de l intention de contrer des Menaces identifiées ou de satisfaire des Politiques de sécurité organisationnelles et des Hypothèses. Les de sécurité synthétisent les résultats de l'étude de la TOE et de son environnement. Toute Menace, toute Hypothèse et toute OSP doit faire l'objet d'au moins un Objectif de sécurité. Ils doivent en outre être cohérents avec le but opérationnel et le contexte de la TOE, en l'occurrence la fourniture de SBFI. Les TOE étant de type système, différents types d'objectifs sont définis : les objectifs portant sur la TOE, qui sont ultérieurement déclinés en exigences fonctionnelles et qui sont évalués conformément aux CC ; les objectifs portant sur l'environnement de la TOE, dont : o les objectifs portant sur le contexte d'exploitation, qui sont à auditer en parallèle à l'évaluation ; o les autres objectifs. Une abréviation est associée à chaque Objectif. Son format est Ox.yyy, où : x peut prendre les valeurs : o 'T' pour un Objectif portant sur la TOE ; o 'A' pour un Objectif portant sur l'environnement et qui doit être audité ; o 'E' pour un Objectif portant sur l'environnement et qui n'a pas à être audité. yyy indique le sujet sur lequel porte l'objectif. Les Critères Communs acceptent qu'un Objectif porte sur la TOE et sur son environnement. Par convention, un tel Objectif a une abréviation de type OT.yyy mais une note d'application précise que l'objectif porte sur la TOE et sur son environnement. Les objectifs qui portent sur la TOE ne portent que sur les fonctionnalités du système (SBFI) en phase d exploitation. La justification des objectifs de sécurité est fournie dans le document "Argumentaire du PP". Les objectifs de sécurité sont présentés par grand domaine de sécurité, dans l'ordre du tableau récapitulatif ciaprès : 44 / 123

45 Domaine Obligations Politique de sécurité Acteurs Objectif OT.VIE_PRIVEE OE.CONTRATS OE.CONTRAT_UTILISATEUR OT.CONSENTEMENT_UTILISATEUR OT.CONFIRMATION_UTILISATEUR OT.OPPOSITION_SBFI OE.RELEVE_TRANSACTION OT.PREUVE_TRANSACTION OE.RESPONSABILITE_TOE OE.ANALYSE_RISQUES OT.TYPE_CANAUX OE.CONTINUITE OE.GESTION_INCIDENTS OT.PROTECTION_BIENS_TRANSMIS OT.PROTECTION_BIENS_STOCKES OT.ID_TOE_INTERNET OT.AUTH_TOE OE.IDEN_AUTHEN_TOE OT.ID&A_UTILISATEUR OT.ID&A_HORS_UTILISATEUR OT.AUTH_FORTE_UTILISATEUR OE.ELEMENTS_AUTH_UTILISATEUR OE.UTILISATEUR OE.ACTEURS_DECONFIANCE OE.COMPETENCE Conception et développement OE.CONCEPTION OE.FONCTIONS OE.QUALIFICATION OE.MODELISATION OT.NON_CONTOURNEMENT Contrôle et suivi OE.CONTROLE OT.AUDIT OT.PISTE_AUDIT OT.TRACE OT.SURVEILLANCE OT.REACTION OE.GESTION_CONFIG OE.MAINTENANCE_SECU OE.QUALIFICATION_MODIF Cryptographie OT.CRYPTO_MECANISMES OT.CRYPTO_UTILISATEUR OT.ISOLATION_SECRETS_CRYPTO OT.CRYPTO_DYNAMIQUE OT.CRYPTO_RESISTANCE Sécurité physique OA.ACCES_PHYSIQUES OE.PROTECTION_PHYSIQUE OA.TRANSFERT_PHYSIQUES Sécurité logique OT.ACCES_LOGIQUES OT.FLUX_LOGIQUES 45 / 123

46 3.4.1 Obligations La cible d évaluation doit répondre aux obligations d ordre pénal, légal, réglementaire et contractuel. La TOE doit respecter les règles d'application de la réglementation en vigueur concernant le respect de la vie privée d'un Utilisateur [OT.VIE_PRIVEE] Note d'application : l objectif de sécurité est réalisé par la TOE (ex. : règle de contrôle d'accès à des données) et par l environnement de la TOE. Les contrats doivent formaliser les Rôles et responsabilités respectifs des Acteurs de la TOE [OE.CONTRATS] Toute Transaction doit s'effectuer dans un cadre contractuel entre l'utilisateur et l'ears, le contrat devant : [OE.CONTRAT_UTILISATEUR] préciser les législations et réglementations en vigueur qui s imposent tant à l Utilisateur qu à l EARS ; préciser de manière expresse les modes de preuve propres à la prise en compte des Transactions, dans le respect de la réglementation en vigueur ; être rédigé avec un souci de clarté, afin d'être compris de l'utilisateur ; avoir un contenu tenant compte du profil de l'utilisateur ; être communiqué clairement à l'utilisateur ; préciser ses modalités de résiliation. La TOE doit s'assurer du consentement explicite de l'utilisateur avant la prise en compte d'une Transaction [OT.CONSENTEMENT_UTILISATEUR] Pour une Transaction présentant un risque opérationnel élevé, la TOE doit obtenir de l Utilisateur une réponse explicite à sa demande de confirmation avant de valider son consentement [OT.CONFIRMATION_UTILISATEUR] La TOE doit savoir : [OT.OPPOSITION_SBFI] mettre en opposition un SBFI suite à la demande d'un Utilisateur ; accepter ou refuser de fournir un SBFI en fonction de la mise en opposition ou non de ce service pour l'utilisateur concerné. Note d'application : Cet Objectif de sécurité est réalisé par la TOE et non par l environnement de la TOE. Toute Transaction modifiant un Bien Acteur d'un Utilisateur doit inclure l'envoi d'un Relevé de Transaction à l'utilisateur [OE.RELEVE_TRANSACTION] Note d'application : Cet Objectif de sécurité est réalisé par l'environnement de la TOE car le Relevé de Transaction intègre des opérations bancaires et/ou financières réalisées hors de la TOE. Pour une Transaction présentant un risque opérationnel élevé, l'ears doit être en mesure de justifier que la Transaction a été initiée par l'utilisateur, de justifier que la Transaction est conforme à celle initiée par 46 / 123

47 l'utilisateur, et d'apporter la preuve du moment de réception par la TOE de la confirmation de l'utilisateur [OT.PREUVE_TRANSACTION] Politique de sécurité Ces objectifs reprennent les orientations et les engagements généraux pour assurer la sécurité au plus tôt dans le cycle de vie de la TOE. La sécurité de la TOE et de son environnement doit être placée sous la responsabilité d'un organe unique situé à un niveau hiérarchique, chargé notamment de valider la Politique de sécurité de la TOE [OE.RESPONSABILITE_TOE] L'EARS doit procéder une analyse de risques spécifique à la TOE afin de mettre en place des protections adaptées. Cette analyse de risques doit en particulier aboutir à : [OE.ANALYSE_RISQUES] la détermination des objectifs et exigences fonctionnelles contenues dans le PP qui sont applicables compte tenu des éléments variables, à savoir : la présence ou non de Transactions présentant un risque opérationnel élevé ; les caractéristiques de sécurité des Biens ; la définition des exigences de sécurité spécifiques au contexte de la TOE et pouvant compléter celles définies dans ce PP. Notes d'application : L'identification des Transactions présentant un risque opérationnel élevé et la définition des caractéristiques de sécurité des Biens visés par les susmentionnés sont des souplesses introduites dans le PP pour tenir compte de la variété des TOE et de leurs environnements. L objectif de sécurité est réalisé par l'environnement de la TOE. La TOE doit être conçue et gérée en tenant compte du type des Canaux de communication employés (Ouverts ou Contrôlés) [OT.TYPE_CANAUX] Note d'application : l objectif de sécurité est réalisé par la TOE et par l'environnement de la TOE. En effet : des Canaux sont dans la TOE ; des Canaux sont partiellement dans la TOE (par exemple : Canal entre la TOE et son SPBF). Un plan d'action doit être défini afin de faire face aux événements impactant fortement la disponibilité de la TOE [OE.CONTINUITE] Les règles de gestion des incidents de sécurité concernant la TOE doivent être formalisées et validées [OE.GESTION_INCIDENTS] La TOE doit protéger les Biens transmis conformément à leurs caractéristiques 2 de sécurité [OT.PROTECTION_BIENS_TRANSMIS] 2 Les caractéristiques de sécurité des Biens sont toutes les combinaisons des besoins en intégrité, disponibilité, confidentialité et / ou non-répudiation. 47 / 123

48 La TOE doit protéger les Biens stockés conformément à leurs caractéristiques 2 de sécurité [OT.PROTECTION_BIENS_STOCKES] La TOE doit fournir à tout Acteur y accédant via un Canal Internet les moyens de l'identifier [OT.ID_TOE_INTERNET] Note d'application : Actuellement, l'identification de la TOE doit au moins reposer sur une URL (Uniform Ressource Locator, c'est-à-dire l'adresse électronique d'un site Web) comportant un nom le plus proche possible de celui de l'ears. La TOE doit fournir à tout Utilisateur ou Fournisseur de données les moyens de l'authentifier [OT.AUTH_TOE] Note d'application : Le libellé de cet objectif met en exergue le fait que l'utilisateur et le Fournisseur de données ont un rôle à jouer dans l'authentification des sites Web, notamment afin de lutter contre les mystifications de site. Si l'on prend l'exemple des sites accédés en HTTPS, l'authentification réussie du serveur Web ne signifie pas que le serveur Web est celui de l'ears. Il faut aller examiner le certificat X509 du serveur et vérifier qu'il a bien été délivré à l'ears. Tout Utilisateur ou Fournisseur de données doit identifier et authentifier la TOE [OE.IDEN_AUTHEN_TOE] Note d'application : l objectif de sécurité est réalisé par l environnement de la TOE. La TOE doit identifier et authentifier tout Utilisateur avant de fournir l accès à un Bien [OT.ID&A_UTILISATEUR] La TOE doit identifier et authentifier tout Acteur qui n'est pas un Utilisateur avant de fournir l accès à un Bien [OT.ID&A_HORS_UTILISATEUR] Note d'application : L'existence de deux pour traiter l'identification et l'authentification d'un Acteur est due aux exigences fonctionnelles qui leur sont associées (familles FIA_UID et FIA_UAU). Dans le cas d'un Utilisateur, on autorise des actions avant l'identification et l'authentification. Les Exigences sont donc FIA_UID.1 (identification) et FIA_UAU.1 (authentification). Pour les autres Acteurs, identification et authentification doivent intervenir avant toute autre action. Les exigences associées sont FIA_UID.2 (hiérarchique de FIA_UID.1) et FIA_UAU.2 (hiérarchique de FIA_UAU.1). Pour les Critères Communs, l'aiguillage vers FIA_UID.1 ou.2 (idem pour FIA_UAU.1 ou.2) ne peut être réalisé que si les sont distincts. Il n'est pas possible de le fonder sur le Rôle de l'acteur. La TOE doit authentifier de façon forte un Utilisateur initiant une Transaction présentant un risque opérationnel élevé [OT.AUTH_FORTE_UTILISATEUR] Note d'application : Le risque pour une authentification est d'être utilisée à l'insu de l'utilisateur (perte, vol, usurpation, simulation). Une authentification forte limite ces risques. Pour une Transaction présentant un risque opérationnel élevé, les éléments nécessaires à l authentification d un Utilisateur doivent être protégés conformément à leurs caractéristiques de sécurité [OE. ELEMENTS_AUTH_UTILISATEUR] Note d'application : l objectif de sécurité est réalisé par l'environnement TI de la TOE.Acteurs 48 / 123

49 La responsabilisation, la sensibilisation et la formation des Acteurs concourent à réduire les risques d erreur humaine, de vol, de fraude ou d utilisation abusive de la cible d évaluation. L EARS doit responsabiliser l Utilisateur en le sensibilisant aux risques inhérents à la manipulation et au stockage, sur l équipement qui est sous sa seule responsabilité, des données liées à la fourniture d un SBFI [OE.UTILISATEUR] Les Acteurs ayant les Rôles Exploitant, Administrateur ou Chargé de clientèle doivent être de confiance [OE.ACTEURS_DECONFIANCE] Les Acteurs ayant les Rôles Exploitant, Administrateur ou Chargé de clientèle doivent disposer des compétences et des moyens nécessaires pour mener à bien leurs missions [OE.COMPETENCE] Conception & développement La conformité de la cible d évaluation au référentiel de sécurité doit être prise en compte dès la conception. Il convient de séparer les environnements de développement et de production. La cible d évaluation ou son évolution doit faire l objet d une qualification avant sa mise en production. La sécurité doit être prise en compte dès la conception de la TOE [OE.CONCEPTION] Note d'application : La TOE est par définition un Système TI en production. C'est pourquoi il est considéré que sa conception porte sur l'environnement. La TOE ne doit fournir que les fonctions pour lesquelles elle a été conçue, dans le but d'empêcher les vulnérabilités de conception [OE.FONCTIONS] La TOE doit être qualifiée d'un point de vue fonctionnel et technique avant sa mise en production, en faisant appel à un organe indépendant et compétent pouvant être interne à l'ears [OE.QUALIFICATION] Note d'application : La TOE est par définition un Système TI en production. C'est pourquoi il est considéré que sa qualification porte sur l'environnement. La TOE doit être conforme au modèle fonctionnel défini dans ce PP. Elle doit distinguer les Transactions présentant un risque opérationnel élevé des autres Transactions [OE.MODELISATION] Le contournement d'un Bloc fonctionnel doit être empêché [OT.NON_CONTOURNEMENT] Contrôle et suivi Ces objectifs apportent une réponse au droit de preuve et plus particulièrement à l obligation de la piste d audit. La TOE doit être incluse dans le processus de contrôle interne de l'ears, avec pour corollaire que le processus de contrôle interne de l'ears doit vérifier le respect de la Politique de sécurité de la TOE [OE.CONTROLE] La TOE doit disposer des moyens aidant les Acteurs autorisés à analyser les données tracées afin de détecter des tentatives de violations ou des violations de la Politique de sécurité de la TOE [OT.AUDIT] Note d'application : OT.AUDIT traite de l'exploitation des traces. 49 / 123

50 La TOE doit conserver un historique des Transactions ayant valeur de piste d'audit [OT.PISTE_AUDIT] La TOE doit enregistrer les événements suivants en y adjoignant des informations d'imputation (au moins : identité, Rôle et horodatage) et doit protéger ces événements contre leur destruction et la saturation [OT.TRACE] connexions et déconnexions des Acteurs ; affectations et retraits de privilèges à un Acteur ; opérations de gestion des acteurs ayant des privilèges (Administrateurs et Exploitants) ; opérations de gestion d'un secret cryptographique (par exemple : génération, révocation) ; accès et flux illicites (tentatives incluses). Note d'application : La seconde partie du libellé de l'objectif, qui traite de la protection des traces, est définie pour couvrir en partie la Menace M.DENI_SELECTIF. La TOE doit disposer de moyens automatisés temps réel pour détecter des tentatives de violation ou des violations de la Politique de sécurité de la TOE, fondés sur l'analyse de l'activité de la TOE [OT.SURVEILLANCE] La TOE doit disposer de moyens pour réagir aux détections des tentatives de violation ou des violations de la Politique de sécurité de la TOE [OT.REACTION] Tous les éléments constituant la TOE doivent faire l'objet d'une gestion de configuration formalisée et validée [OE.GESTION_CONFIG] Les éléments de la TOE doivent faire l'objet d'une veille sécurité et d'une maintenance sécurité permanentes permettant le suivi et l'adaptation (respectivement) aux évolutions des menaces, des vulnérabilités ainsi que des technologies et produits aptes à renforcer la sécurité [OE.MAINTENANCE_SECU] Toute modification touchant un élément constituant la TOE doit être qualifiée avant sa mise en œuvre par un organe indépendant pouvant être interne à l'ears [OE.QUALIFICATION_MODIF] Cryptographie Les mécanismes cryptographiques renforcent la protection des données sensibles. La TOE doit employer des mécanismes cryptographiques ayant prouvé leur résistance pour protéger ses secrets [OT.CRYPTO_MECANISMES] Les échanges entre la TOE et un Utilisateur doivent employer des mécanismes cryptographiques standardisés [OT.CRYPTO_UTILISATEUR] Note d'application : L'emploi d'algorithmes ou protocoles standardisés renforce la confiance dans leur résistance puisqu ils ont pu être éprouvés publiquement. L'Objectif de sécurité est réalisé par la TOE et par l environnement de la TOE. 50 / 123

51 Au sein de la TOE, les secrets et mécanismes cryptographiques doivent être isolés et protégés contre les attaques physiques et logiques. Ceci concerne en particulier tous les secrets employés pour générer et / ou en protéger un autre [OT.ISOLATION_SECRETS_CRYPTO] Notes d'application : L'Objectif de sécurité est réalisé par la TOE et par l environnement de la TOE. La TOE doit prendre en charge les protections logiques. Concernant l'environnement de la TOE, un système de contrôle des accès physiques et des dispositifs anti-intrusion bien pensés et gérés constituent des protections physiques qui satisfont l'objectif (des enceintes sécuritaires ne sont pas forcément nécessaires). La TOE doit fournir les moyens de réagir dans les délais requis en cas de compromission des secrets [OT.CRYPTO_DYNAMIQUE] Note d'application : L'Objectif de sécurité est réalisé par la TOE et par l environnement de la TOE. Les règles de gestion des secrets cryptographiques de la TOE doivent être résistantes, formalisées et validées [OT.CRYPTO_RESISTANCE] Note d'application : L'Objectif de sécurité est réalisé par la TOE par l environnement de la TOE Sécurité physique La sécurité de la cible d évaluation ne peut pas être assurée sans un contrôle physique strict de son accès. La TOE doit mettre en œuvre un contrôle des accès physiques aux locaux abritant des Biens en permettant d autoriser les accès en fonction d un Rôle [OA.ACCES_PHYSIQUES] Note d'application : Une gestion rigoureuse des accès physiques est nécessaire pour obtenir un bon niveau de sécurité global. C'est pourquoi il est demandé que cet Objectif sur l'environnement de la TOE soit audité en même temps que l'évaluation. La TOE doit être située dans des locaux disposant de mesures de sécurité physique adaptées, définies dans le cadre de l'analyse de risques spécifique à la TOE réalisée par l'ears [OE.PROTECTION_PHYSIQUE] La TOE doit mettre en œuvre un contrôle des transferts physiques afin de garantir que les entités émettrices et destinataires sont autorisées (Bloc ou Système TI) [OA.TRANSFERT_PHYSIQUES] Note d'application : Une gestion rigoureuse des transferts physiques est nécessaire pour obtenir un bon niveau de sécurité global. Par exemple, un support de sauvegarde a la même sensibilité que les données d'origine. C'est pourquoi il est demandé que cet Objectif sur l'environnement de la TOE soit audité en même temps que l'évaluation. 51 / 123

52 3.4.7 Sécurité logique La sécurité logique permet aux Acteurs d avoir un accès individualisé, après identification et autorisation, en fonction de leur Rôle. La TOE doit mettre en œuvre un contrôle des accès logiques aux Biens en permettant d autoriser les accès en fonction d un Rôle [OT.ACCES_LOGIQUES] La TOE doit mettre en œuvre un contrôle des flux logiques afin de garantir que les entités émettrices et destinataires sont autorisées (Bloc ou Système TI) [OT.FLUX_LOGIQUES] 52 / 123

53 4 EXIGENCES DE SECURITE Ce chapitre regroupe les chapitres imposés par les Critères Communs, concernant : les exigences de sécurité les notes d'application l argumentaire 4.1 Exigences fonctionnelles et d'assurance Il est rappelé que ce chapitre est réservé à un public averti, du fait du formalisme des exigences imposé par les Critères Communs. Il est en particulier important de noter que le texte des exigences contient des termes qui ont une autre signification dans la partie précédente du PP (par exemple : utilisateur, rôle). Ce chapitre comporte : les exigences fonctionnelles, qui spécifient les futures fonctions de sécurité du système, c'est-à-dire ce que le système doit savoir faire en termes de sécurité ; les exigences d'assurance, c'est-à-dire les exigences qui portent sur le cycle de vie du système et notamment sa conception / réalisation et qui consistent à vérifier la conformité et l'efficacité des fonctions de sécurité. Les exigences fonctionnelles et d assurance ne portent que sur les fonctionnalités du système (SBFI) en phase d exploitation Exigences fonctionnelles Niveau de résistance Certaines fonctions de sécurité font l'objet d'un niveau de résistance spécifique. Pour toutes ces fonctions, la métrique de cotation du niveau de résistance est celle définie dans les CC. Les niveaux de résistance spécifiques sont précisés dans le paragraphe suivant Récapitulatif des exigences fonctionnelles et des niveaux de résistance spécifiques associés Le tableau ci-dessous présente l'intégralité des exigences fonctionnelles retenues, et indique le cas échéant le niveau de résistance associé, des fonctions. Les exigences sont classées comme dans la norme ISO/IEC c'est-à-dire dans l'ordre alphabétique des abréviations des composants fonctionnels. Les conventions pour les colonnes du tableau sont : "Classe / Famille" : indique la classe ou la famille du composant, conformément à l'iso/iec ; "Abréviation composant" : indique l'abréviation du composant, conformément à l'iso/iec ; Remarque : Les abréviations des composants itérés suivent les principes suivants : - /A pour un composant ayant pour dépendance une exigence traitant d accès logique ; - /F pour un composant ayant pour dépendance une exigence traitant de flux logique ; - /AouF pour un composant ayant pour dépendance une exigence traitant, au choix du rédacteur de la cible, d accès logique ou de flux logique. "Nom composant" : indique le nom du composant, conformément à l'iso/iec ; "Niv. SOF" (Strength Of Function) : indique, le cas échéant, le niveau SOF requis ('e' = SOF-élémentaire, 'M' = SOF-moyen, 'E' = SOF-élevé). 53 / 123

54 Classe / Famille Audit de sécurité Abréviation composant Réponse automatique à l'audit de sécurité FAU_ARP.1 Alarmes de sécurité Nom composant Génération des données de l'audit de FAU_GEN.1 Génération de données d'audit sécurité FAU_GEN.2 Lien avec l'identité de l'utilisateur Analyse de l'audit de sécurité FAU_SAA.1 Analyse de violation potentielle Revue de l'audit de sécurité FAU_SAR.1 Revue d'audit FAU_SAR.2 Revue d'audit restreinte Sélection des évènements de l'audit de sécurité FAU_SEL.1 Audit sélectif Stockage d'évènements de l'audit de FAU_STG.1 Stockage protégé de la trace d audit sécurité FAU_STG.2 Garanties de disponibilité des données d'audit Communication FAU_STG.4 Prévention des pertes de données d'audit Non-répudiation de l'origine FCO_NRO.1 Preuve sélective de l origine M Support cryptographique FCO_NRO.2 Preuve systématique de l'origine M Gestion de clés cryptographiques FCS_CKM.1 Génération de clés cryptographiques M FCS_CKM.1pour CKM2 Génération de clés cryptographiques M FCS_CKM.2 Distribution de clés cryptographiques M FCS_CKM.3 Accès aux clés cryptographiques M FCS_CKM.4 Destruction de clés cryptographiques M Opération cryptographique FCS_COP.1 Opération cryptographique (non normalisée) M Protection des données de l'utilisateur Politique de contrôle d'accès FDP_ACC.1 Contrôle d'accès partiel Fonctions de contrôle d'accès FDP_ACF.1 Contrôle d'accès basé sur les attributs de sécurité Authentification de données FDP_DAU.1 Authentification de données élémentaire M Exportation vers une zone hors du contrôle de la TSF FDP_ETC.1/A Exportation de données de l'utilisateur sans attributs de sécurité FDP_ETC.1/AouF Exportation de données de l'utilisateur sans attributs de sécurité Politique de contrôle de flux d'information FDP_IFC.1 Contrôle de flux d'information partiel Fonctions de contrôle de flux d'information FDP_IFF.1 Attributs de sécurité simples Importation depuis une zone hors de contrôle de la TSF FDP_ITC.1/A FDP_ITC.1/AouF Importation de données de l'utilisateur sans attributs de sécurité Importation de données de l'utilisateur sans attributs de sécurité Transfert interne à la TOE FDP_ITT.1/A Protection élémentaire d'un transfert interne FDP_ITT.1/AouF Protection élémentaire d'un transfert interne Annulation FDP_ROL.1/Aou F Annulation élémentaire Intégrité des données stockées FDP_SDI.1 Contrôle de l intégrité des données stockées Identification et authentification Échecs de l'authentification FIA_AFL.1 Gestion d'un échec de l'authentification Définition des attributs de l'utilisateur FIA_ATD.1 Définition des attributs de l'utilisateur Spécification de secrets FIA_SOS.1 Vérification de secrets Authentification de l'utilisateur FIA_UAU.1 Programmation de l'authentification M FIA_UAU.2 Authentification de l utilisateur avant toute action M FIA_UAU.4 Mécanismes d authentification à usage unique M FIA_UAU.7 Authentification avec retours protégés Identification de l'utilisateur FIA_UID.1 Programmation de l'identification Administration de la sécurité FIA_UID.2 Identification de l utilisateur avant toute action Administration des fonctions de la TSF FMT_MOF.1 3 Administration du comportement des fonctions de sécurité Administration des attributs de sécurité FMT_MSA.1/A Administration des attributs de sécurité Niv. SOF 3 Attention, cette exigence n est retenue que comme exigence conditionnée 54 / 123

55 Classe / Famille Abréviation composant FMT_MSA.1/F FMT_MSA.1/AouF FMT_MSA.2/A FMT_MSA.2/AouF FMT_MSA.3/A FMT_MSA.3/F FMT_MSA.3/AouF Nom composant Administration des attributs de sécurité Administration des attributs de sécurité Attributs de sécurité sûrs Attributs de sécurité sûrs Initialisation statique d'attributs Initialisation statique d'attributs Initialisation statique d'attributs Administration des données de la TSF FMT_MTD.1 Administration des données de la TSF Rôles pour l'administration de la sécurité FMT_SMR.1 Rôles de sécurité Protection de la TSF Transfert des données de la TSF à l'intérieur de la TOE FPT_ITT.1 Détection de rejeu FPT_RPL.1 Détection de rejeu Protection élémentaire des données de la TSF lors d'un transfert interne Passage par un moniteur de référence FPT_RVM.1 Capacité de la politique de sécurité d une TOE ou «TSP» (TOE Security Policy)) à ne pas être contournée Séparation de domaines FPT_SEP.1 Séparation des domaines pour la TSF Horodatage FPT_STM.1 Horodatage fiable Cohérence de la reproduction des données de la TSF à l'intérieur de la TOE Accès à la TOE FPT_TRC.1 Cohérence interne de la TSF Messages d'accès à la TOE FTA_TAB.1 Messages par défaut d'accès à la TOE Historique des accès à la TOE FTA_TAH.1 Historique des accès à la TOE Établissement d'une session de la TOE FTA_TSE.1 Établissement d'une session de la TOE Chemins et canaux de confiance Chemin de confiance FTP_TRP.1 Chemin de confiance Niv. SOF Tableau 3 : Liste des exigences fonctionnelles et des niveaux SOF spécifiques associés 55 / 123

56 Conventions de présentation des exigences fonctionnelles Les conventions adoptées sont : les composants fonctionnels retenus sont présentés dans l'ordre alphabétique de leurs abréviations ; les sélections et affectations effectuées figurent dans le texte des composants ; quand le PP ne sélectionne qu'une partie des propositions d'une sélection multiple, les autres sont ôtées du texte du composant. Cela signifie que le rédacteur de la ST peut ajouter des propositions de sélection non retenues dans le PP mais doit alors itérer le composant ; quand le PP effectue une affectation en indiquant une liste d'items, la possibilité d'ajouter des items dans le composant est exclue. Cela signifie que le rédacteur de la ST peut ajouter des items non retenus dans le PP mais doit alors itérer le composant ; les raffinements sont indiqués à la suite du composant ; des notes d'application sont indiquées à la suite de certains composants afin de fournir des informations complémentaires de compréhension ; dans les raffinements ou les notes d'application, tout terme repris de l'iso/iec est indiqué entre les guillemets '«' et '»' afin de bien mettre en évidence qu'il s'agit de l'acceptation Critères Communs Attributs de sécurité Un certain nombre de composants fonctionnels concernent ce que les Critères Communs appellent des «attributs de sécurité». Ce paragraphe les présente de façon regroupée. Les attributs de sécurité sont de quatre sortes : des «informations» ; des «objets», c'est-à-dire des conteneurs d'informations, typiquement des répertoires, des fichiers ou des messages ; des «sujets», c'est-à-dire typiquement des processus ou programmes, lancés à l'initiative d'un Acteur ou par un système ; des «utilisateurs», c'est-à-dire des Acteurs. Les attributs définis dans le PP sont : Attributs d'objets : o Permissions Attributs de sujets : o Rôles Attributs d'utilisateurs : o Statut d'accès à un SBFI par un Utilisateur (signale si un SBFI est mis en opposition pour un Utilisateur donné ou non) o Identité Attributs d'informations : o Transaction présentant un risque opérationnel élevé ou non o Canal Contrôlé ou non Note d'application : le rédacteur de la ST peut ajouter de nouveaux attributs. Il s'expose alors à devoir itérer les composants fonctionnels concernés et doit prendre garde à la cohérence des dépendances. 56 / 123

57 Politiques Ce PP définit deux Politiques de Fonctions de Sécurité ou SFP (Security Function Policy) : une politique de contrôle d'accès, SFP_AccèsLogique ; une politique de contrôle de flux d'information, SFP_FluxLogique. Les règles associées à ces deux politiques sont partiellement définies dans le PP. Les compléments devront être apportés dans la ST. Les seules règles qui ont été précisées sont celles requises pour la cohérence avec le reste du PP. Note d'application : les politiques définies sont nécessairement générales compte tenu de l'optique fonctionnelle du PP et de la diversité des SBFI pris en considération. En particulier, aucune politique spécifique à certains Rôles et / ou Biens n'a été définie. 57 / 123

58 Détail des exigences fonctionnelles Conformément à la norme ISO/IEC 15408, les exigences doivent être formulées en langue anglaise. Dans ce document, les exigences en langue anglaise, pour des raisons de facilité d usage, ont été traduites en français 4. Le choix des exigences fonctionnelles a été fait en considérant que : les Biens Acteur sont les «données utilisateur» au sens de la norme ISO/IEC ; les Biens SBFI sont les «données de la TSF» au sens de la norme ISO/IEC Remarque : Selon les options retenues lors de la conception de la TOE, le rédacteur de la cible pourra choisir parmi les exigences conditionnées en justifiant ses choix Classe Audit de sécurité [FAU] Alarmes de sécurité [FAU_ARP.1] La TSF doit entreprendre [la remontée d'une Alarme sur un équipement surveillé par un Acteur ayant des privilèges] dès la détection d une violation potentielle de la sécurité. [FAU_ARP.1.1] Note d'application : le rédacteur de la ST peut ajouter d'autres actions à entreprendre en itérant le composant. OT.REACTION Génération de données d audit [FAU_GEN.1] La TSF doit pouvoir générer un enregistrement d audit des événements auditables suivants : [FAU_GEN.1.1] a) démarrage et arrêt des fonctions d audit ; b) tous les éléments auditables pour le niveau d'audit [non spécifié] ; c) et [les événements définis dans le tableau Tableau 4]. Libellé événement auditable Connexions et déconnexions des Acteurs Affectations et retraits de privilèges à un Acteur Opérations de gestion des acteurs ayant des privilèges Opérations de gestion d'un secret cryptographique Accès et flux illicites (tentatives incluses) Tableau 4 : Liste minimale des événements auditables (FAU_GEN.1) 4 En cas de divergence entre la version traduite en français et la version anglaise, la version anglaise fait référence. 58 / 123

59 La TSF doit enregistrer au minimum les informations suivantes dans chaque enregistrement d audit : [FAU_GEN.1.2] a) date et heure de l événement, type d événement, identité du sujet, ainsi que le résultat (succès ou échec) de l événement ; b) et, pour chaque type d évènement d audit, sur la base des définitions d événements auditables contenues dans les composants fonctionnels inclus dans le PP ou la ST, [les informations d'audit définies dans le tableau Tableau 5 : Liste des informations d'audit à enregistrer (FAU_GEN.1)] : Libellé information d'audit Rôle de l'utilisateur Toutes les informations nécessaires pour respecter la réglementation en vigueur Tableau 5 : Liste des informations d'audit à enregistrer (FAU_GEN.1) Note d'application : Le rédacteur de la ST peut ajouter d'autres événements à auditer (FAU_GEN.1.1) et/ou d'autres informations d'audit (FAU_GEN.1.2) en itérant le composant. En particulier, il peut être amené à le faire afin de satisfaire pleinement l'objectif OT.PISTE_AUDIT. OT.PREUVE_TRANSACTION, OT.PROTECTION_BIENS_STOCKES, OT.AUDIT OT.PISTE_AUDIT, OT.TRACE, OT.SURVEILLANCE, OT.REACTION néant Lien avec l identité de l utilisateur [FAU_GEN.2] La TSF doit pouvoir associer chaque événement auditable avec l identité de l utilisateur qui est à l origine de l événement. [FAU_GEN.2.1] OT.PREUVE_TRANSACTION, OT.PISTE_AUDIT, OT.TRACE néant Analyse de violation potentielle [FAU_SAA.1] La TSF doit pouvoir appliquer un ensemble de règles en surveillant les événements audités et indiquer, en fonction de ces règles, une violation potentielle de la TSP. [FAU_SAA.1.1] La TSF doit appliquer les règles suivantes pour la surveillance des événements audités : [FAU_SAA.1.2] a) accumulation ou combinaison d' [événements auditables définis dans le tableau Tableau 4 : Liste minimale des événements auditables (FAU_GEN.1)] connus pour indiquer une violation potentielle de la sécurité ; b) [affectation : toutes les autres règles]. 59 / 123

60 OT.AUDIT, OT.SURVEILLANCE, OT.REACTION néant Revue d audit [FAU_SAR.1] La TSF doit offrir à [affectation : utilisateurs autorisés] la capacité de lire [les informations d'audit définies dans le tableau Tableau 5 : Liste des informations d'audit à enregistrer (FAU_GEN.1)] à partir des enregistrements d audit. [FAU_SAR.1.1] La TSF doit présenter les enregistrements d audit d une façon permettant à l utilisateur de les interpréter. [FAU_SAR.1.2] Note(s) d'application : Toutes les informations d'audit enregistrées, définies par FAU_GEN.1, doivent pouvoir être lues. Ce composant est nécessaire pour satisfaire OT.PROTECTION_BIENS_STOCKES lorsque des Biens SBFI stockés, de type Journaux, ont un besoin en intégrité. Autrement dit : ce composant est toujours nécessaire. Le rédacteur de la ST devra définir les «utilisateurs autorisés» en itérant le composant. OT.PROTECTION_BIENS_STOCKES, OT.AUDIT Revue d audit restreinte [FAU_SAR.2] La TSF doit interdire à tous les utilisateurs le droit d accès en lecture aux enregistrements d audit, à l exception de ceux à qui l on a accordé un droit de lecture explicite. [FAU_SAR.2.1] Note d'application : ce composant est nécessaire pour satisfaire OT.PROTECTION_BIENS_STOCKES lorsque des Biens SBFI stockés, de type Journaux, ont un besoin en confidentialité. OT.PROTECTION_BIENS_STOCKES, OT.AUDIT Audit sélectif [FAU_SEL.1] 60 / 123

61 La TSF doit pouvoir inclure ou exclure des événements auditables de l ensemble des événements audités en fonction des attributs suivants : [FAU_SEL.1.1] a) [sélection : identité de l objet, identité de l utilisateur, identité du sujet, identité de l hôte, type d événement] b) [affectation : liste des attributs supplémentaires sur lesquels se base la sélectivité de l audit]. OT.PISTE_AUDIT, OT.TRACE Stockage protégé de la trace d audit [FAU_STG.1] La TSF doit protéger les enregistrements d audit stockés contre une suppression non autorisée. [FAU_STG.1.1] La TSF doit pouvoir [sélection : empêcher, détecter] les modifications effectuées sur les enregistrements d audit. [FAU_STG.1.2] Note d'application : ce composant est nécessaire pour satisfaire OT.PROTECTION_BIENS_STOCKES lorsque des Biens SBFI stockés, de type Journaux, ont un besoin en intégrité. OT.PREUVE_TRANSACTION OT.PROTECTION_BIENS_STOCKES Garanties de disponibilité des données d audit [FAU_STG.2] La TSF doit protéger les enregistrements d audit stockés contre une suppression non autorisée. [FAU_STG.2.1] La TSF doit pouvoir [sélection : empêcher, détecter] les modifications effectuées sur les enregistrements d audit. [FAU_STG.2.2] La TSF doit garantir que [affectation : métrique pour sauvegarder les enregistrements d audit] des enregistrements d audit sera maintenue quand les conditions suivantes apparaîtront : [sélection : dépassement de capacité du stockage de l audit, défaillance, attaque]. [FAU_STG.2.3] Note d'application : ce composant est nécessaire pour satisfaire OT.PROTECTION_BIENS_STOCKES lorsque des Biens SBFI stockés, de type Journaux, ont un besoin en disponibilité. OT.PREUVE_TRANSACTION, OT.PROTECTION_BIENS_STOCKES OT.PISTE_AUDIT OT.TRACE 61 / 123

62 Prévention des pertes de données d audit [FAU_STG.4] Si la trace d audit est pleine, la TSF doit [sélection : ignorer les événements auditables, empêcher les événements auditables, autres que ceux provoqués par l utilisateur autorisé bénéficiant de droits spéciaux, écraser les enregistrements d audit les plus anciennement stockés ] et [affectation : autres actions à entreprendre en cas de défaillance du stockage de l audit]. [FAU_STG.4.1] Note(s) d'application : Le rédacteur de la ST devra définir les «utilisateurs autorisés bénéficiant de droits spéciaux» en itérant le composant. Ce composant est nécessaire pour satisfaire OT.PROTECTION_BIENS_STOCKES lorsque des Biens SBFI stockés, de type Journaux, ont un besoin en disponibilité. OT.PREUVE_TRANSACTION, OT.PROTECTION_BIENS_STOCKES OT.PISTE_AUDIT, OT.TRACE Classe Communication [FCO] Preuve sélective de l origine [FCO_NRO.1] La TSF doit pouvoir générer la preuve de l origine des [affectation : liste des types d informations] transmis à la demande de [sélection : émetteur, destinataire, [affectation : liste des tierces parties]]. [FCO_NRO.1.1] La TSF doit pouvoir établir un lien entre [l'identifiant] de l émetteur des informations et les [affectation : liste des champs d information] des informations auxquelles la preuve s applique. [FCO_NRO.1.2] La TSF doit fournir à [sélection : émetteur, destinataire, [affectation : liste des tierces parties]] la capacité de vérifier la preuve de l origine des informations étant donné [affectation : limitations relatives à la preuve de l origine]. [FCO_NRO.1.3] NOTA BENE : FCO_NRO.1 est retenu car il est considéré qu'il ne requiert pas nécessairement un procédé de signature électronique. OT.PROTECTION_BIENS_TRANSMIS 62 / 123

63 Preuve systématique de l origine [FCO_NRO.2] La TSF doit mettre en œuvre la génération de la preuve de l origine à tout moment pour [affectation : liste des types d informations] transmise. [FCO_NRO.2.1] La TSF doit pouvoir établir un lien entre [l'identifiant] de l émetteur des informations et les [affectation : liste des champs d information] des informations auxquelles la preuve s applique. [FCO_NRO.2.2] La TSF doit fournir à [sélection : émetteur, destinataire, [affectation : liste des tierces parties]] la capacité de vérifier la preuve de l origine des informations étant donné [affectation : limitations relatives à la preuve de l origine]. [FCO_NRO.2.3] Note(s) d'application : Cette exigence est nécessaire pour satisfaire l'objectif OT.PREUVE_TRANSACTION, spécifique aux Transactions présentant un risque opérationnel élevé. Le rédacteur de la ST doit la compléter de façon à satisfaire l'objectif. Pour FCO_NRO.2.3 : Le rédacteur de la ST doit notamment prendre en compte les délais imposés par la réglementation en vigueur. NOTA BENE : FCO_NRO.2 est retenu car il est considéré qu'il ne requiert pas nécessairement un procédé de signature électronique. OT.PREUVE_TRANSACTION OT.PROTECTION_BIENS_TRANSMIS Classe Support cryptographique [FCS] Génération de clés cryptographiques [FCS_CKM.1] La TSF doit générer les clés cryptographiques conformément à un algorithme de génération de clés cryptographiques spécifié [affectation : algorithme de génération de clés cryptographiques] et à des tailles de clés cryptographiques spécifiées [affectation : tailles des clés cryptographiques] qui satisfont à ce qui suit : [affectation : liste des normes]. [FCS_CKM.1.1] Note(s) d'application : L'algorithme de génération de clé utilisé doit être conforme à la réglementation en vigueur. L'algorithme de génération de clé utilisé doit permettre une gestion dynamique des secrets, afin de satisfaire OT.CRYPTO_DYNAMIQUE. L'algorithme de génération de clé utilisé doit permettre une gestion résistante des secrets, afin de satisfaire OT.CRYPTO_RESISTANCE. OT.CRYPTO_MECANISMES, OT.CRYPTO_UTILISATEUR OT.ISOLATION_SECRETS_CRYPTO, OT.CRYPTO_DYNAMIQUE OT.CRYPTO_RESISTANCE 63 / 123

64 OT.VIE_PRIVEE Génération de clés cryptographiques [FCS_CKM.1pourCKM2] La TSF doit générer les clés cryptographiques conformément à un algorithme de génération de clés cryptographiques spécifié [affectation : algorithme de génération de clés cryptographiques] et à des tailles de clés cryptographiques spécifiées [affectation : tailles des clés cryptographiques] qui satisfont à ce qui suit : [affectation : liste des normes]. [FCS_CKM.1.1pourCKM2] Note(s) d'application : L'algorithme de génération de clé utilisé doit être conforme à la réglementation en vigueur. L'algorithme de génération de clé utilisé doit permettre une gestion dynamique des secrets, afin de satisfaire OT.CRYPTO_DYNAMIQUE. L'algorithme de génération de clé utilisé doit permettre une gestion résistante des secrets, afin de satisfaire OT.CRYPTO_RESISTANCE. OT.PROTECTION_BIENS_STOCKES Distribution de clés cryptographiques [FCS_CKM.2] La TSF doit distribuer les clés cryptographiques conformément à une méthode de distribution de clés cryptographiques spécifiée [affectation : méthode de distribution de clés cryptographiques] qui satisfait à ce qui suit : [affectation : liste des normes]. [FCS_CKM.2.1] Note(s) d'application : La méthode de distribution de clé utilisée doit être conforme à la réglementation en vigueur. La méthode de distribution de clé utilisée doit permettre une gestion dynamique des secrets, afin de satisfaire OT.CRYPTO_DYNAMIQUE. La méthode de distribution de clé utilisée doit permettre une gestion résistante des secrets, afin de satisfaire OT.CRYPTO_RESISTANCE. OT.PROTECTION_BIENS_STOCKES, OT.CRYPTO_DYNAMIQUE OT.CRYPTO_RESISTANCE OT.ISOLATION_SECRETS_CRYPTO OT.VIE_PRIVEE 64 / 123

65 Accès aux clés cryptographiques [FCS_CKM.3] La TSF doit réaliser [affectation : type d accès aux clés cryptographiques] conformément à une méthode d accès aux clés cryptographiques spécifiée [affectation : méthode d accès aux clés cryptographiques] qui satisfait à ce qui suit : [affectation : liste des normes]. [FCS_CKM.3.1] Note(s) d'application : La méthode d'accès aux clés utilisée doit être conforme à la réglementation en vigueur. La méthode d'accès aux clés utilisée doit permettre une gestion dynamique des secrets, afin de satisfaire OT.CRYPTO_DYNAMIQUE. La méthode d'accès aux clés utilisée doit permettre une gestion résistante des secrets, afin de satisfaire OT.CRYPTO_RESISTANCE. Ce composant est nécessaire pour satisfaire OT.PROTECTION_BIENS_STOCKES lorsque des Biens SBFI stockés de type Secrets cryptographiques ont un besoin en confidentialité et/ou intégrité et/ou disponibilité. Autrement dit, ce composant est toujours nécessaire pour ces Biens. Le rédacteur de la ST doit cependant préciser les protections requises. OT.PROTECTION_BIENS_STOCKES, OT.ISOLATION_SECRETS_CRYPTO OT.CRYPTO_DYNAMIQUE, OT.CRYPTO_RESISTANCE OT.VIE_PRIVEE Destruction de clés cryptographiques [FCS_CKM.4] La TSF doit détruire les clés cryptographiques conformément à une méthode de destruction de clés cryptographiques spécifiée [affectation : méthode de destruction de clés cryptographiques] qui satisfait à ce qui suit : [affectation : liste des normes]. [FCS_CKM.4.1] Note d'application : La méthode de destruction de clés utilisée doit être conforme à la réglementation en vigueur. La méthode de destruction de clés utilisée doit permettre une gestion dynamique des secrets, afin de satisfaire OT.CRYPTO_DYNAMIQUE. La méthode de destruction de clés utilisée doit permettre une gestion résistante des secrets, afin de satisfaire OT.CRYPTO_RESISTANCE. OT.PROTECTION_BIENS_STOCKES, OT.CRYPTO_MECANISMES OT.CRYPTO_UTILISATEUR, OT.ISOLATION_SECRETS_CRYPTO OT.CRYPTO_DYNAMIQUE, OT.CRYPTO_RESISTANCE 65 / 123

66 OT.VIE_PRIVEE Opération cryptographique [FCS_COP.1] La TSF doit exécuter [les opérations définies dans le tableau Tableau 6] conformément à un algorithme cryptographique [affectation : algorithme cryptographique] et avec des tailles de clés cryptographiques [affectation : tailles des clés cryptographiques] spécifiées qui satisfont à ce qui suit : [affectation : liste des normes]. [FCS_COP.1.1] Opération cryptographique Authentification de la TOE auprès d'un utilisateur Chiffrement d'un Bien transmis par la TOE à un équipement utilisateur Déchiffrement d'un Bien reçu d'un équipement utilisateur Tableau 6 : Liste minimale des opérations cryptographiques (FCS_COP.1) Note(s) d'application : Les opérations cryptographiques qui concernent un utilisateur doivent nécessairement être effectuées à l'aide d'un voire plusieurs algorithme(s) normalisé(s). Le ou les algorithmes utilisés doivent être conformes à la réglementation en vigueur. Le rédacteur de la ST peut ajouter d'autres opérations cryptographiques en itérant le composant. FCS_COP.1 requiert une fonctionnalité qui lui fournisse les clés de chiffrement. Les clés sont générées en interne (finalité de FCS_CKM.1). OT.CRYPTO_MECANISMES, OT.CRYPTO_UTILISATEUR OT.ISOLATION_SECRETS_CRYPTO OT.VIE_PRIVEE 66 / 123

67 Classe Protection des données de l'utilisateur [FDP] Contrôle d accès partiel [FDP_ACC.1] La TSF doit appliquer la [SFP SFP_AccèsLogique] aux [affectation : liste des sujets, objets et opérations sur les sujets et objets couverts par la SFP] [FDP_ACC.1.1] Note(s) d'application : Pour les objets : Tous les Biens doivent être pris en compte par la SFP SFP_AccèsLogique. Pour les sujets : Tous les Acteurs ou Systèmes TI agissant au nom d'un Acteur doivent être pris en compte par la SFP SFP_AccèsLogique. Pour les opérations : Toutes les opérations portant sur un Bien doivent être prises en compte par la SFP SFP_AccèsLogique. OT.VIE_PRIVEE, OT.OPPOSITION_SBFI, OT.ID_TOE_INTERNET OT.AUTH_TOE, OT.CRYPTO_MECANISMES, OT.CRYPTO_UTILISATEUR OT.ISOLATION_SECRETS_CRYPTO, OT.CRYPTO_DYNAMIQUE OT.CRYPTO_RESISTANCE, OT.ACCES_LOGIQUES OT.PROTECTION_BIENS_TRANSMIS, OT.PROTECTION_BIENS_STOCKES Contrôle d accès basé sur les attributs de sécurité [FDP_ACF.1] La TSF doit appliquer la [SFP SFP_AccèsLogique] aux objets en se basant sur [affectation : liste des attributs de sécurité]. [FDP_ACF.1.1] Note(s) d'application : Afin d être moins restrictifs qu avec une liste d attributs imposée, la définition des attributs de sécurité est laissée à la charge du rédacteur de la ST. La TSF doit appliquer les règles suivantes pour déterminer si une opération entre des sujets contrôlés et des objets contrôlés est autorisée : [affectation : règles qui régissent les accès aux sujets contrôlés et aux objets contrôlés utilisant des opérations contrôlées sur des objets contrôlés]. [FDP_ACF.1.2] La TSF doit autoriser explicitement l accès de sujets à des objets en fonction des règles complémentaires suivantes : [affectation : règles basées sur les attributs de sécurité, qui autorisent explicitement l accès de sujets à des objets]. [FDP_ACF.1.3] La TSF doit refuser explicitement l accès de sujets à des objets en fonction de [affectation : règles basées sur les attributs de sécurité, qui interdisent explicitement l accès de sujets à des objets]. [FDP_ACF.1.4] Note d'application : Les règles de contrôle d'accès doivent respecter la réglementation en vigueur en matière de protection de la vie privée. 67 / 123

68 OT.VIE_PRIVEE, OT.OPPOSITION_SBFI, OT.ID_TOE_INTERNET OT.AUTH_TOE, OT.CRYPTO_MECANISMES, OT.CRYPTO_UTILISATEUR OT.ISOLATION_SECRETS_CRYPTO, OT.CRYPTO_DYNAMIQUE OT.CRYPTO_RESISTANCE, OT.ACCES_LOGIQUES Authentification de données élémentaire [FDP_DAU.1] La TSF doit offrir une capacité de générer une preuve pouvant être utilisée comme garantie de la validité de [affectation : liste des objets ou types d informations]. [FDP_DAU.1.1] La TSF doit offrir aux [affectation : liste des sujets] l aptitude de vérifier la preuve de la validité des informations indiquées. [FDP_DAU.1.2] Note d'application : ce composant est nécessaire pour satisfaire OT.PROTECTION_BIENS_STOCKES lorsque des Biens Acteurs stockés ont un besoin de nonrépudiation. OT.PROTECTION_BIENS_STOCKES Exportation de données de l utilisateur sans attributs de sécurité [FDP_ETC.1/A] La TSF doit appliquer la [SFP_AccèsLogique] lors de l exportation de données de l utilisateur, contrôlées par la ou les SFP, vers l extérieur du TSC. [FDP_ETC.1.1/A] La TSF doit exporter les données de l utilisateur sans les attributs de sécurité associés aux données de l utilisateur. [FDP_ETC.1.2/A] Note(s) d'application : Ce composant concerne tous les Biens Acteurs échangés avec un système TI qui n'est pas de confiance. OT.VIE_PRIVEE, OT.ID_TOE_INTERNET, OT.AUTH_TOE Exportation de données de l utilisateur sans attributs de sécurité [FDP_ETC.1/AouF] La TSF doit appliquer la [SFP_AccèsLogique, SFP_FluxLogique] lors de l exportation de données de l utilisateur, contrôlées par la ou les SFP, vers l extérieur du TSC. [FDP_ETC.1.1/AouF] 68 / 123

69 La TSF doit exporter les données de l utilisateur sans les attributs de sécurité associés aux données de l utilisateur. [FDP_ETC.1.2/AouF] Note(s) d'application : Ce composant concerne tous les Biens Acteurs échangés avec un système TI qui n'est pas de confiance. Ce composant est nécessaire pour satisfaire OT.PROTECTION_BIENS_TRANSMIS lorsque des Biens Acteurs, exportés par la TOE vers un Système TI qui n'est pas de confiance, ont un besoin de confidentialité et/ou d'intégrité et/ou de disponibilité. OT.PROTECTION_BIENS_TRANSMIS Contrôle de flux d information partiel [FDP_IFC.1] La TSF doit appliquer la [SFP SFP_FluxLogique] aux [affectation : liste des sujets, des informations et des opérations couvertes par la SFP qui déclenchent le transfert d informations contrôlées vers et en provenance de sujets contrôlés]. [FDP_IFC.1.1] Note d'application : cette exigence doit concerner tous les sujets et tous les Biens transmis sans support physique de stockage de données (donc entre deux processus exécutés sur la même machine où sur des machines reliées par un réseau). OT.CONSENTEMENT_UTILISATEUR, OT.CONFIRMATION_UTILISATEUR, OT.TYPE_CANAUX, OT.FLUX_LOGIQUES OT.PROTECTION_BIENS_TRANSMIS, OT.PROTECTION_BIENS_STOCKES Attributs de sécurité simples [FDP_IFF.1] La TSF doit appliquer la [SFP SFP_FluxLogique] en fonction des types suivants d attributs de sécurité de sujets et d informations : [Transaction présentant un risque opérationnel élevé ou non, Canal Ouvert ou Contrôlé]. [FDP_IFF.1.1] Note d'application : le rédacteur de la ST peut ajouter d'autres attributs en itérant le composant. La TSF doit autoriser un flux d information entre un sujet contrôlé et des informations contrôlées par l intermédiaire d une opération contrôlée si les règles suivantes s appliquent : [affectation : pour chaque opération, les relations basées sur les attributs de sécurité qui doivent exister entre les attributs de sécurité du sujet et les attributs de sécurité des informations]. [FDP_IFF.1.2] La TSF doit appliquer les [règles complémentaires définies dans le tableau Tableau 7 : Règles complémentaires de contrôle de flux d'information]. [FDP_IFF.1.3] 69 / 123

70 Règles complémentaires Une Transaction doit pouvoir être annulée avant son terme en remettant la TOE à son état initial Un Bloc fonctionnel ne doit pas pouvoir être contourné La TOE doit s'assurer du consentement explicite de l'utilisateur avant la prise en compte d'une Transaction Toute Transaction modifiant un Bien Acteur d'un utilisateur doit inclure l'envoi d'un Relevé de Transaction à l'utilisateur Pour toute Transaction présentant un risque opérationnel élevé : la TSF doit obtenir de l utilisateur une réponse explicite à sa demande de confirmation avant de valider son consentement Pour toute Transaction présentant un risque opérationnel élevé : la TSF doit initier les opérations élémentaires permettant de : justifier que la Transaction a été initiée par l'utilisateur ; justifier que la Transaction est conforme à celle initiée par l'utilisateur ; prouver le moment de réception par la TOE de la confirmation de l'utilisateur. Tableau 7 : Règles complémentaires de contrôle de flux d'information Note d'application : le rédacteur de la ST peut ajouter d'autres règles complémentaires en itérant le composant. La TSF doit fournir ce qui suit [affectation : liste des capacités complémentaires de la SFP]. [FDP_IFF.1.4] La TSF doit autoriser explicitement un flux d information en fonction des règles suivantes : [affectation : règles basées sur les attributs de sécurité, qui autorisent explicitement les flux d information]. [FDP_IFF.1.5] La TSF doit interdire explicitement un flux d information en fonction des règles suivantes : [affectation : règles basées sur les attributs de sécurité, qui interdisent explicitement les flux d information]. [FDP_IFF.1.6] Note d'application relative aux règles (concerne plusieurs éléments) : les règles de contrôle des flux d'informations doivent respecter la réglementation en vigueur en matière de protection de la vie privée, afin de respecter, notamment, OT.VIE_PRIVEE. OT.CONSENTEMENT_UTILISATEUR, OT.CONFIRMATION_UTILISATEUR OT.TYPE_CANAUX, OT.FLUX_LOGIQUES OT.PREUVE_TRANSACTION Importation de données de l utilisateur sans attributs de sécurité [FDP_ITC.1/A] La TSF doit appliquer la [SFP SFP_AccèsLogique] lors de l importation de données de l utilisateur contrôlées par la SFP en provenance de l extérieur du TSC. [FDP_ITC.1.1/A] La TSF doit ignorer tout attribut de sécurité associé aux données de l utilisateur lorsqu elles sont importées depuis l extérieur du TSC. [FDP_ITC.1.2/A] La TSF doit appliquer les règles suivantes lors de l importation de données de l utilisateur contrôlées par la SFP en provenance de l extérieur du TSC : [affectation : règles complémentaires de contrôle d importation]. [FDP_ITC.1.3/A] Note(s) d'application : Le composant s'applique aux données transmises à la TOE depuis un système TI qui n'est pas de confiance et considérées comme des Biens Acteur dès qu'elles atteignent le TSC (TOE Scope of Control). 70 / 123

71 OT.VIE_PRIVEE Importation de données de l utilisateur sans attributs de sécurité [FDP_ITC.1/AouF] La TSF doit appliquer la [SFP SFP_AccèsLogique, SFP_FluxLogique] lors de l importation de données de l utilisateur contrôlées par la SFP en provenance de l extérieur du TSC. [FDP_ITC.1.1/AouF] La TSF doit ignorer tout attribut de sécurité associé aux données de l utilisateur lorsqu elles sont importées depuis l extérieur du TSC. [FDP_ITC.1.2/AouF] La TSF doit appliquer les règles suivantes lors de l importation de données de l utilisateur contrôlées par la SFP en provenance de l extérieur du TSC : [affectation : règles complémentaires de contrôle d importation]. [FDP_ITC.1.3/AouF] Note(s) d'application : Le composant s'applique aux données transmises à la TOE depuis un système TI qui n'est pas de confiance et considérées comme des Biens Acteur dès qu'elles atteignent le TSC (TOE Scope of Control). Ce composant est nécessaire pour satisfaire OT.PROTECTION_BIENS_TRANSMIS lorsque des Biens Acteurs, importés par la TOE depuis un Système TI qui n'est pas de confiance, ont un besoin de confidentialité et/ou d'intégrité et/ou de disponibilité. OT.PROTECTION_BIENS_TRANSMIS Protection élémentaire d un transfert interne [FDP_ITT.1/A] La TSF doit appliquer la [SFP SFP_AccèsLogique] pour empêcher la [sélection : divulgation, modification ou perte d utilisation] de données de l utilisateur au cours de leur transmission entre des parties de la TOE physiquement séparées. [FDP_ITT.1.1/A] Note(s) d'application : La formulation de ce composant signifie que la TSF peut, selon le Bien transmis : o appliquer uniquement la SFP SFP_AccèsLogique, Dans la ST, si des Biens Acteurs échangés entre deux parties de la TOE ont des besoins de sécurité différents, ce composant doit être itéré autant de fois que nécessaire et raffiné afin d'indiquer sur quelles données de l'utilisateur porte chaque itération. OT.VIE_PRIVEE 71 / 123

72 Protection élémentaire d un transfert interne [FDP_ITT.1/AouF] La TSF doit appliquer la [SFP SFP_AccèsLogique, SFP_FluxLogique] pour empêcher la [sélection : divulgation, modification ou perte d utilisation] de données de l utilisateur au cours de leur transmission entre des parties de la TOE physiquement séparées. [FDP_ITT.1.1/AouF] Note(s) d'application : La formulation de ce composant signifie que la TSF peut, selon le Bien transmis : o appliquer uniquement la SFP SFP_AccèsLogique, ou o appliquer uniquement la SFP SFP_FluxLogique, Ce composant est nécessaire pour satisfaire OT.PROTECTION_BIENS_TRANSMIS lorsque des Biens Acteurs, échangés entre deux parties de la TOE, ont un besoin de confidentialité et/ou intégrité et/ou disponibilité. Dans la ST, si des Biens Acteurs échangés entre deux parties de la TOE ont des besoins de sécurité différents, ce composant doit être itéré autant de fois que nécessaire et raffiné afin d'indiquer sur quelles données de l'utilisateur porte chaque itération. OT.PROTECTION_BIENS_TRANSMIS, OT.PROTECTION_BIENS_STOCKES Annulation élémentaire [FDP_ROL.1/AouF] La TSF doit appliquer la [SFP SFP_AccèsLogique, SFP_FluxLogique] pour autoriser l annulation des [affectation : liste des opérations] sur les [affectation : liste des objets]. [FDP_ROL.1.1/AouF] La TSF doit autoriser l annulation des opérations dans les [affectation : limites dans lesquelles l annulation peut être effectuée]. [FDP_ROL.1.2/AouF] Note(s) d'application : Concernant les opérations (FDP_ROL.1.1) : Le composant concerne toutes les opérations élémentaires associées à une Transaction : ces opérations élémentaires, initiées par un utilisateur, doivent pouvoir être annulées avant la prise en compte d'une Transaction et ce sans modification des Biens concernés. La formulation de ce composant signifie que la TSF peut : o appliquer uniquement la SFP SFP_AccèsLogique, ou o appliquer uniquement la SFP SFP_FluxLogique, 72 / 123

73 OT.PROTECTION_BIENS_STOCKES Contrôle de l intégrité des données stockées [FDP_SDI.1] La TSF doit contrôler les données de l utilisateur stockées au sein du TSC à la recherche des [affectation : erreurs d intégrité] sur tous les objets, en fonction des attributs suivants : [affectation : attributs des données de l utilisateur]. [FDP_SDI.1.1] Note d'application : ce composant est nécessaire pour satisfaire OT.PROTECTION_BIENS_STOCKES lorsque des Biens Acteurs ont un besoin d'intégrité. OT.PROTECTION_BIENS_STOCKES 73 / 123

74 Classe Identification et authentification [FIA] Gestion d un échec de l authentification [FIA_AFL.1] La TSF doit détecter quand [affectation : nombre] tentatives d authentification infructueuses ont eu lieu en relation avec [affectation : liste d événements liés à l authentification]. [FIA_AFL.1.1] Quand le nombre spécifié de tentatives d authentification infructueuses a été atteint ou dépassé, la TSF doit [affectation : liste d actions]. [FIA_AFL.1.2] OT.ID&A_UTILISATEUR, OT.ID&A_HORS_UTILISATEUR OT.AUTH_FORTE_UTILISATEUR OT.PREUVE_TRANSACTION Définition des attributs de l utilisateur [FIA_ATD.1] La TSF doit maintenir la liste suivante d attributs de sécurité appartenant à des utilisateurs individuels : [statut d'accès à un SBFI]. [FIA_ATD.1.1] Note d'application : le rédacteur de la ST peut préciser d'autres attributs associés aux «utilisateurs» en itérant le composant. Par exemple, dans le cas d'un Utilisateur, ces attributs peuvent être : sa nature : particulier ou entreprise ; son profil, qui définit les services auxquels il a accès ; le plafond des sommes qu'il peut manipuler. OT.OPPOSITION_SBFI néant Vérification de secrets [FIA_SOS.1] La TSF doit offrir un mécanisme pour contrôler que les secrets répondent à [affectation : une métrique de qualité définie]. [FIA_SOS.1.1] Note(s) d'application : Dans le cas où les «secrets» sont des mots de passe, la TSF doit au minimum effectuer le contrôle du nombre de caractères. Certains systèmes ou applications présentent des limitations en matière de vérifications de non-trivialité des mots de passe. C'est pourquoi rien n'est imposé concernant ces vérifications. Elles peuvent par exemple se limiter à vérifier qu'il n'y a pas N fois le même caractère. 74 / 123

75 OT.ID&A_UTILISATEUR, OT.ID&A_HORS_UTILISATEUR OT.AUTH_FORTE_UTILISATEUR OT.PREUVE_TRANSACTION Programmation de l authentification [FIA_UAU.1] La TSF doit autoriser que [affectation : liste d actions transitant par la TSF] pour le compte de l utilisateur soient effectuées avant qu il ne soit authentifié. [FIA_UAU.1.1] La TSF doit exiger que chaque utilisateur soit authentifié avec succès avant d autoriser toute autre action transitant par la TSF pour le compte de cet utilisateur. [FIA_UAU.1.2] OT.ID&A_UTILISATEUR, OT.AUTH_FORTE_UTILISATEUR OT.PREUVE_TRANSACTION Authentification de l utilisateur avant toute action [FIA_UAU.2] La TSF doit exiger que chaque utilisateur soit authentifié avec succès avant d autoriser toute autre action transitant par la TSF pour le compte de cet utilisateur. [FIA_UAU.2.1] OT.ID&A_HORS_UTILISATEUR Mécanismes d authentification à usage unique [FIA_UAU.4] La TSF doit empêcher la réutilisation des données d authentification liées à [mécanisme(s) d'authentification impliqué(s) pour les Transactions présentant un risque opérationnel élevé]. [FIA_UAU.4.1] Note(s) d'application : Ce composant est nécessaire pour satisfaire OT.AUTH_FORTE_UTILISATEUR, qui est spécifique aux Transactions présentant un risque opérationnel élevé. Dans le cas de Transactions ne présentant pas un risque opérationnel élevé, le rédacteur de la ST peut néanmoins indiquer des mécanismes d'authentification à usage unique, en itérant le composant. 75 / 123

76 OT.AUTH_FORTE_UTILISATEUR OT.PREUVE_TRANSACTION Authentification avec retours protégés [FIA_UAU.7] La TSF ne doit fournir que [affectation : liste des informations retournées] à l utilisateur pendant que l authentification est en cours. [FIA_UAU.7.1] Note(s) d'application : Le composant s'applique à tous les mécanismes d'authentification ; Le composant interdit de retourner les données à l'identique, c'est-à-dire en clair. Mais, par exemple, des "*" peuvent être affichés. OT.ID&A_UTILISATEUR, OT.ID&A_HORS_UTILISATEUR, OT.AUTH_FORTE_UTILISATEUR OT.PREUVE_TRANSACTION Programmation de l identification [FIA_UID.1] La TSF doit autoriser que [affectation : liste d actions transitant par la TSF] pour le compte de l utilisateur soient effectuées avant qu il ne soit identifié. [FIA_UID.1.1] La TSF doit exiger que chaque utilisateur soit identifié avec succès avant d autoriser toute autre action transitant par la TSF pour le compte de cet utilisateur. [FIA_UID.1.2] Note(s) d'application : Les actions transitant par la TSF autorisées avant l'identification d'un Utilisateur sont notamment toutes celles qui ne rentrent pas dans le cadre d'une Transaction (présentant un risque opérationnel élevé ou non). OT.VIE_PRIVEE, OT.OPPOSITION_SBFI, OT.PREUVE_TRANSACTION OT.ID&A_UTILISATEUR, OT.AUTH_FORTE_UTILISATEUR, OT.PISTE_AUDIT, OT.TRACE OT.TYPE_CANAUX, OT.PROTECTION_BIENS_TRANSMIS, OT.PROTECTION_BIENS_STOCKES, OT.ID_TOE_INTERNET, OT.AUTH_TOE OT.CRYPTO_MECANISMES, OT.CRYPTO_UTILISATEUR, OT.ISOLATION_SECRETS_CRYPTO, OT.CRYPTO_DYNAMIQUE, OT.CRYPTO_RESISTANCE, OT.ACCES_LOGIQUES, OT.FLUX_LOGIQUES 76 / 123

77 Identification de l utilisateur avant toute action [FIA_UID.2] La TSF doit exiger que chaque utilisateur soit identifié avec succès avant d autoriser toute autre action transitant par la TSF pour le compte de cet utilisateur. [FIA_UID.2.1] OT.ID&A_HORS_UTILISATEUR OT.TYPE_CANAUX, OT.PROTECTION_BIENS_TRANSMIS, OT.PROTECTION_BIENS_STOCKES, OT.ID_TOE_INTERNET, OT.AUTH_TOE OT.CRYPTO_MECANISMES, OT.CRYPTO_UTILISATEUR, OT.ISOLATION_SECRETS_CRYPTO, OT.CRYPTO_DYNAMIQUE, OT.CRYPTO_RESISTANCE, OT.ACCES_LOGIQUES, OT.FLUX_LOGIQUES Classe Administration de la sécurité [FMT] Administration du comportement des fonctions de sécurité [FMT_MOF.1] La TSF doit restreindre l aptitude de [sélection : déterminer le comportement, désactiver, activer, modifier le comportement] des fonctions [affectation : liste des fonctions] aux [rôles définis dans le tableau Tableau 8 : Liste des rôles (FMT_SMR.1)]. [FMT_MOF.1.1] Note(s) d'application : L'administration du comportement des fonctions de sécurité doit être conforme à la modélisation de la TOE effectuée dans le chapitre 2. En particulier, les fonctions de sécurité impliquées dans le non-contournement d'un Bloc fonctionnel ne doivent pas pouvoir être désactivées ou modifiées (cf. OE.MODELISATION). Ce composant est nécessaire pour satisfaire OT.PROTECTION_BIENS_STOCKES lorsque des Biens SBFI stockés, de type Configuration, ont un besoin en confidentialité et/ou intégrité et/ou disponibilité. Autrement dit, ce composant est toujours nécessaire. Le rédacteur de la ST doit cependant préciser les protections requises. Si elles diffèrent selon le Bien, le composant doit être itéré. Le rédacteur de la ST peut définir des règles différentes selon les rôles ; il devra alors itérer le composant. OT.PROTECTION_BIENS_STOCKES Administration des attributs de sécurité [FMT_MSA.1/A] 77 / 123

78 La TSF doit mettre en œuvre la [SFP SFP_AccèsLogique] pour restreindre aux [rôles définis dans le tableau Tableau 8 : Liste des rôles (FMT_SMR.1)] l aptitude de [sélection : changer la valeur par défaut, interroger, modifier, supprimer, [affectation : autres opérations]] les attributs de sécurité [affectation : liste des attributs de sécurité]. [FMT_MSA.1.1/A] Note(s) d'application : La formulation de ce composant signifie que la TSF peut : o Appliquer uniquement la SFP SFP_AccèsLogique ; L'administration des attributs de sécurité doit être conforme à la modélisation de la TOE effectuée dans le chapitre 2. Lors de la rédaction de la ST, les opérations liées à ce composant devront être complétées en respectant le fait que : o les attributs de sécurité suivants doivent pouvoir être modifiés : statut de mise en opposition d'un SBFI pour un utilisateur donné ; Rôle(s) affecté(s) à un Acteur ; Permissions ; Transaction présentant un risque opérationnel élevé ou non o les attributs de sécurité suivants ne doivent pas pouvoir être modifiés : type de Canal. Le rédacteur de la ST peut définir des règles différentes selon les rôles ; il devra alors itérer le composant. OT.VIE_PRIVEE, OT.OPPOSITION_SBFI, OT.ID_TOE_INTERNET OT.AUTH_TOE, OT.CRYPTO_MECANISMES, OT.CRYPTO_UTILISATEUR OT.ISOLATION_SECRETS_CRYPTO, OT.CRYPTO_DYNAMIQUE OT.CRYPTO_RESISTANCE, OT.ACCES_LOGIQUES Administration des attributs de sécurité [FMT_MSA.1/F] La TSF doit mettre en œuvre la [SFP SFP_FluxLogique] pour restreindre aux [rôles définis dans le tableau Tableau 8 : Liste des rôles (FMT_SMR.1)] l aptitude de [sélection : changer la valeur par défaut, interroger, modifier, supprimer, [affectation : autres opérations]] les attributs de sécurité [affectation : liste des attributs de sécurité]. [FMT_MSA.1.1/F] Note(s) d'application : La formulation de ce composant signifie que la TSF applique uniquement la SFP SFP_FluxLogique ; L'administration des attributs de sécurité doit être conforme à la modélisation de la TOE effectuée dans le chapitre 2. Lors de la rédaction de la ST, les opérations liées à ce composant devront être complétées en respectant le fait que : o les attributs de sécurité suivants doivent pouvoir être modifiés : 78 / 123

79 statut de mise en opposition d'un SBFI pour un utilisateur donné ; Rôle(s) affecté(s) à un Acteur ; Permissions ; Transaction présentant un risque opérationnel élevé ou non o les attributs de sécurité suivants ne doivent pas pouvoir être modifiés : type de Canal. Le rédacteur de la ST peut définir des règles différentes selon les rôles ; il devra alors itérer le composant. OT.CONSENTEMENT_UTILISATEUR, OT.CONFIRMATION_UTILISATEUR OT.TYPE_CANAUX, OT.FLUX_LOGIQUES Administration des attributs de sécurité [FMT_MSA.1/AouF] La TSF doit mettre en œuvre la [SFP SFP_AccèsLogique, SFP_FluxLogique] pour restreindre aux [rôles définis dans le tableau Tableau 8 : Liste des rôles (FMT_SMR.1)] l aptitude de [sélection : changer la valeur par défaut, interroger, modifier, supprimer, [affectation : autres opérations]] les attributs de sécurité [affectation : liste des attributs de sécurité]. [FMT_MSA.1.1/AouF] Note(s) d'application : La formulation de ce composant signifie que la TSF peut : o Appliquer uniquement la SFP SFP_AccèsLogique ; ou o Appliquer uniquement la SFP SFP_FluxLogique ; L'administration des attributs de sécurité doit être conforme à la modélisation de la TOE effectuée dans le chapitre 2. Lors de la rédaction de la ST, les opérations liées à ce composant devront être complétées en respectant le fait que : o les attributs de sécurité suivants doivent pouvoir être modifiés : statut de mise en opposition d'un SBFI pour un utilisateur donné ; Rôle(s) affecté(s) à un Acteur ; Permissions ; Transaction présentant un risque opérationnel élevé ou non o les attributs de sécurité suivants ne doivent pas pouvoir être modifiés : type de Canal. Ce composant est nécessaire pour satisfaire OT.PROTECTION_BIENS_STOCKES lorsque des Biens SBFI stockés, correspondant à des «attributs de sécurité» ont un besoin en confidentialité et/ou intégrité et/ou disponibilité. Autrement dit, ce composant est toujours nécessaire. Le rédacteur de la ST doit cependant préciser les protections requises. Si elles diffèrent selon l'attribut, le composant doit être itéré. 79 / 123

80 Le rédacteur de la ST peut définir des règles différentes selon les rôles ; il devra alors itérer le composant. OT.PROTECTION_BIENS_TRANSMIS, OT.PROTECTION_BIENS_STOCKES Attributs de sécurité sûrs [FMT_MSA.2/A] La TSF doit garantir que seules des valeurs sûres sont acceptées pour les attributs de sécurité. [FMT_MSA.2.1/A] Note d'application : ce composant est retenu pour respecter les dépendances des composants de la classe FCS. Garantir des valeurs sûres pour tous les attributs de sécurité nécessiterait un modèle informel de politique de sécurité couvrant toute la TSF. C'est jugé trop contraignant, en conséquence : la dépendance de FMT_MSA.2 avec ADV_SPM.1 est cassée (cf. la justification) ; FMT_MSA.2 fait l'objet d'un raffinement précisant les attributs de sécurité pour lesquelles des valeurs sûres doivent être garanties. Le rédacteur de la ST devra définir la liste des attributs de sécurité comme par exemple les clés cryptographiques. OT.CRYPTO_MECANISMES, OT.CRYPTO_UTILISATEUR OT.ISOLATION_SECRETS_CRYPTO, OT.CRYPTO_DYNAMIQUE OT.CRYPTO_RESISTANCE Attributs de sécurité sûrs [FMT_MSA.2/AouF] La TSF doit garantir que seules des valeurs sûres sont acceptées pour les attributs de sécurité. [FMT_MSA.2.1] Note d'application : ce composant est retenu pour respecter les dépendances des composants de la classe FCS. Garantir des valeurs sûres pour tous les attributs de sécurité nécessiterait un modèle informel de politique de sécurité couvrant toute la TSF. C'est jugé trop contraignant, en conséquence : la dépendance de FMT_MSA.2 avec ADV_SPM.1 est cassée (cf. la justification) ; FMT_MSA.2 fait l'objet d'un raffinement précisant les attributs de sécurité pour lesquelles des valeurs sûres doivent être garanties. Le rédacteur de la ST devra définir la liste des attributs de sécurité comme par exemple les clés cryptographiques. 80 / 123

81 OT.PROTECTION_BIENS_STOCKES Initialisation statique d attribut [FMT_MSA.3/A] La TSF doit mettre en œuvre la [SFP SFP_AccèsLogique] afin de fournir des valeurs par défaut [sélection : restrictives, permissives, autres propriétés] pour les attributs de sécurité qui sont utilisés pour appliquer la SFP. [FMT_MSA.3.1/A] La TSF doit permettre aux [rôles définis dans le tableau Tableau 8 : Liste des rôles (FMT_SMR.1)] de spécifier des valeurs initiales alternatives pour remplacer les valeurs par défaut lorsqu un objet ou une information est créé. [FMT_MSA.3.2/A] Note(s) d'application : La formulation de ce composant signifie que la TSF applique uniquement la SFP SFP_AccèsLogique ; Ce composant est retenu pour respecter des dépendances. Il est considéré que la formulation de ce composant respecte les dépendances vis-à-vis de FMT_MSA.3 : o des composants fondés sur la SFP SFP_AccèsLogique (ex. : FDP_ACF.1) ; Le rédacteur de la ST peut définir des règles différentes selon les rôles ; il devra alors itérer le composant. OT.VIE_PRIVEE, OT.OPPOSITION_SBFI, OT.ID_TOE_INTERNET OT.AUTH_TOE, OT.CRYPTO_MECANISMES, OT.CRYPTO_UTILISATEUR OT.ISOLATION_SECRETS_CRYPTO, OT.CRYPTO_DYNAMIQUE OT.CRYPTO_RESISTANCE, OT.ACCES_LOGIQUES Initialisation statique d attribut [FMT_MSA.3/F] La TSF doit mettre en œuvre la [SFP SFP_FluxLogiques] afin de fournir des valeurs par défaut [sélection : restrictives, permissives, autres propriétés] pour les attributs de sécurité qui sont utilisés pour appliquer la SFP. [FMT_MSA.3.1/F] La TSF doit permettre aux [rôles définis dans le tableau Tableau 8 : Liste des rôles (FMT_SMR.1)] de spécifier des valeurs initiales alternatives pour remplacer les valeurs par défaut lorsqu un objet ou une information est créé. [FMT_MSA.3.2/F] Note(s) d'application : La formulation de ce composant signifie que la TSF applique uniquement la SFP SFP_FluxLogique ; Ce composant est retenu pour respecter des dépendances. Il est considéré que la formulation de ce composant respecte les dépendances vis-à-vis de FMT_MSA.3 : 81 / 123

82 o des composants fondés sur la SFP SFP_FluxLogique (ex. : FDP_ITC.1). Le rédacteur de la ST peut définir des règles différentes selon les rôles ; il devra alors itérer le composant. OT.CONSENTEMENT_UTILISATEUR OT.CONFIRMATION_UTILISATEUR OT.TYPE_CANAUX OT.FLUX_LOGIQUES Initialisation statique d attribut [FMT_MSA.3/AouF] La TSF doit mettre en œuvre la [SFP SFP_AccèsLogique, SFP_FluxLogiques] afin de fournir des valeurs par défaut [sélection : restrictives, permissives, autres propriétés] pour les attributs de sécurité qui sont utilisés pour appliquer la SFP. [FMT_MSA.3.1/AouF] La TSF doit permettre aux [rôles définis dans le tableau Tableau 8 : Liste des rôles (FMT_SMR.1)] de spécifier des valeurs initiales alternatives pour remplacer les valeurs par défaut lorsqu un objet ou une information est créé. [FMT_MSA.3.2/AouF] Note(s) d'application : La formulation de ce composant signifie que la TSF peut : o Appliquer uniquement la SFP SFP_AccèsLogique ; ou o Appliquer uniquement la SFP SFP_FluxLogique ; Ce composant est retenu pour respecter des dépendances. Il est considéré que la formulation de ce composant respecte les dépendances vis-à-vis de FMT_MSA.3 : o des composants fondés sur la SFP SFP_AccèsLogique (ex. : FDP_ACF.1) ou o des composants fondés sur la SFP SFP_FluxLogique (ex. : FDP_ITC.1). Le rédacteur de la ST peut définir des règles différentes selon les rôles ; il devra alors itérer le composant. OT.PROTECTION_BIENS_TRANSMIS 82 / 123

83 Administration des données de la TSF [FMT_MTD.1] La TSF doit restreindre l aptitude de [sélection : changer une valeur par défaut, interroger, modifier, supprimer, effacer [affectation : autres opérations]] les [affectation : liste des données de la TSF] aux [rôles définis dans le tableau Tableau 8 : Liste des rôles (FMT_SMR.1)]. [FMT_MTD.1.1] Note(s) d'application : L'administration des données de la TSF doit être conforme à la modélisation de la TOE effectuée dans le chapitre 2. En particulier, les données de la TSF impliquées dans le non-contournement d'un Bloc fonctionnel ne doivent pas pouvoir être modifiées par un utilisateur non autorisé (cf. OE.MODELISATION). Le rédacteur de la ST peut définir des règles différentes selon les rôles ; il devra alors itérer le composant. OT.PISTE_AUDIT, OT.TRACE OT.PROTECTION_BIENS_STOCKES 83 / 123

84 Rôles de sécurité [FMT_SMR.1] La TSF doit tenir à jour les rôles [définis dans le tableau Tableau 8]. [FMT_SMR.1.1] Référence rôle Utilisateur Fournisseur de données Chargé de clientèle Exploitant Administrateur SPBF Description rôle 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 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 ). 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 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 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. Ce Rôle est alloué aux Systèmes TI externes à la TOE que sont les SPBF Tableau 8 : Liste des rôles (FMT_SMR.1) La TSF doit être capable d associer des utilisateurs à des rôles. [FMT_SMR.1.2] Note(s) d'application :La ST peut définir davantage de rôles, en itérant le composant. Néanmoins : les rôles supplémentaires doivent en termes de responsabilités et de droits former des sous-ensembles des Rôles, c'est-à-dire respecter les règles : o plusieurs «rôles» peuvent être associé à un Rôle ; o un «rôle» est nécessairement associé à un seul Rôle. les itérations doivent tenir compte des composants qui dépendent de FMT_SMR.1. OT.VIE_PRIVEE, OT.CONSENTEMENT_UTILISATEUR OT.CONFIRMATION_UTILISATEUR, OT.OPPOSITION_SBFI, OT.TYPE_CANAUX OT.PROTECTION_BIENS_TRANSMIS, OT.PROTECTION_BIENS_STOCKES OT.ID_TOE_INTERNET, OT.AUTH_TOE, OT.PISTE_AUDIT, OT.TRACE OT.CRYPTO_MECANISMES, OT.CRYPTO_UTILISATEUR OT.ISOLATION_SECRETS_CRYPTO, OT.CRYPTO_DYNAMIQUE OT.CRYPTO_RESISTANCE, OT.ACCES_LOGIQUES, OT.FLUX_LOGIQUES 84 / 123

85 Classe Protection de la TSF [FPT] Protection élémentaire des données de la TSF lors d un transfert interne [FPT_ITT.1] La TSF doit protéger les données de la TSF contre la [sélection : divulgation, modification] quand elles sont transmises entre des parties séparées de la TOE. [FPT_ITT.1.1] Note d'application : ce composant est nécessaire pour satisfaire OT.PROTECTION_BIENS_TRANSMIS lorsque des Biens SBFI, échangés entre deux parties de la TOE, ont un besoin de confidentialité et/ou d'intégrité. Dans la ST, si des Biens SBFI échangés entre deux parties de la TOE ont des besoins de sécurité différents, ce composant doit être itéré autant de fois que nécessaire et raffiné afin d'indiquer sur quelles données de l'utilisateur porte chaque itération. OT.PROTECTION_BIENS_TRANSMIS Détection de rejeu [FPT_RPL.1] La TSF doit détecter le rejeu pour les entités suivantes : [entités définies dans le tableau Tableau 9]. [FPT_RPL.1.1] Entités dont il faut détecter le rejeu Séquence d'authentification (d'un Acteur ou d'un système TI externe) Transaction Transaction présentant un risque opérationnel élevé Tableau 9 : Liste minimale des rejeux à détecter (FPT_RPL.1) La TSF doit exécuter [affectation : liste des actions spécifiques] quand le rejeu est détecté. [FPT_RPL.1.2] Note d'application : le rédacteur de la ST peut ajouter d'autres entités dont il faut détecter le rejeu en itérant le composant. OT.ID&A_UTILISATEUR, OT.ID&A_HORS_UTILISATEUR OT.AUTH_FORTE_UTILISATEUR Capacité de la TSP à ne pas être contournée [FPT_RVM.1] 85 / 123

86 La TSF doit garantir que les fonctions qui mettent en œuvre la TSP sont appelées et s exécutent avec succès avant que chaque fonction dans le TSC ne soit autorisée à démarrer. [FPT_RVM.1.1] OT.NON_CONTOURNEMENT Séparation de domaines pour la TSF [FPT_SEP.1] La TSF doit maintenir un domaine de sécurité pour sa propre exécution, qui la protège des interférences et des intrusions par des sujets non sûrs. [FPT_SEP.1.1] La TSF doit appliquer une séparation entre les domaines de sécurité de sujets dans le TSC. [FPT_SEP.1.2] Note(s) d'application : Ce composant s'applique au moins aux sujets correspondant à des mécanismes cryptographiques, afin de satisfaire OT.ISOLATION_SECRETS_CRYPTO. Ce composant requiert l'existence d'au moins un cloisonnement à l'intérieur de la TOE, isolant la TSF des attaques externes ou provenant de parties de la TOE en dehors de la TSF. Or, la TOE est un système composé de plusieurs éléments et de ce fait comporte probablement différents cloisonnements (à l'aide de la mise en œuvre de firewall, reverse proxy ). Il est donc probable que certaines TSF comporteront plusieurs domaines de sécurité, ce qui est l'objet du composant FPT_SEP.2 (hiérarchique à FPT_SEP.1). Ce composant n'est pas retenu afin de ne pas contraindre trop les périmètres et architectures de TOE possibles. OT.ISOLATION_SECRETS_CRYPTO, OT.ACCES_LOGIQUES OT.FLUX_LOGIQUES OT.VIE_PRIVEE Horodatage fiable [FPT_STM.1] La TSF doit être capable de fournir un horodatage fiable pour son propre usage. [FPT_STM.1.1] NOTA BENE : FPT_STM.1 est retenu car il est considéré : qu'il ne requiert pas nécessairement une base de temps commune à l'ensemble de la TOE ; qu'il est satisfait quand, par exemple, les traces permettent d'ordonner chronologiquement les événements (sachant que FAU_GEN.1.2 réclame que la TSF enregistre pour chaque événement tracé : la date, l'heure et toute information requise par la réglementation en vigueur). 86 / 123

87 OT.PREUVE_TRANSACTION, OT.PROTECTION_BIENS_STOCKES OT.AUDIT, OT.PISTE_AUDIT, OT.TRACE, OT.SURVEILLANCE, OT.REACTION Cohérence interne de la TSF [FPT_TRC.1] La TSF doit garantir que des données de la TSF sont cohérentes quand elles sont reproduites entre des parties de la TOE. [FPT_TRC.1.1] Quand des parties de la TOE contenant des données de la TSF qui ont été reproduites sont déconnectées, la TSF doit garantir la cohérence de ces données à la reconnexion avant de traiter toute demande pour [affectation : liste des SF dépendant de la cohérence de la reproduction des données de la TSF]. [FPT_TRC.1.2] Note d'application : ce composant est nécessaire pour satisfaire OT.PROTECTION_BIENS_STOCKES lorsque des Biens SBFI, reproduits entre deux parties de la TOE, ont un besoin d'intégrité. Il requiert en effet qu'en cas de coupure de communication entre deux parties de la TOE les données restent cohérentes. OT.PROTECTION_BIENS_STOCKES Classe Accès à la TOE [FTA] Messages par défaut d accès à la TOE [FTA_TAB.1] Avant d établir une session utilisateur, la TSF doit afficher un message d avertissement informatif relatif à l utilisation non autorisée de la TOE. [FTA_TAB.1.1] Note d'application : Le composant concerne tous les «utilisateurs», c'est-à-dire tous les Acteurs. Ce composant participe à la détection des usurpations d'identité en sensibilisant les Acteurs et notamment les Utilisateurs. OT.ACCES_LOGIQUES 87 / 123

88 Historique des accès à la TOE [FTA_TAH.1] Dès l établissement réussi d une session, la TSF doit afficher à l attention de l utilisateur [sélection : la date, l heure, la méthode, le lieu] du dernier établissement réussi d une session. [FTA_TAH.1.1] Dès l établissement réussi d une session, la TSF doit afficher [sélection : la date, l heure, la méthode, le lieu] de la dernière tentative d établissement infructueuse d une session et le nombre de tentatives infructueuses depuis le dernier établissement réussi d une session. [FTA_TAH.1.2] La TSF ne doit pas effacer les informations concernant l historique des accès de l interface utilisateur sans laisser à l utilisateur la possibilité de revoir ces informations. [FTA_TAH.1.3] Note(s) d'application : La retenue de ce composant est cohérent avec le fait qu'il est demandé de tracer les connexions réussies et les tentatives infructueuses (cf. FAU_GEN.1) Le rédacteur de la ST doit effectuer les sélections en cohérence avec les informations d'audit OT.ID&A_UTILISATEUR, OT.ID&A_HORS_UTILISATEUR Établissement d une session de la TOE [FTA_TSE.1] La TSF doit être capable de refuser l établissement d une session en fonction de [affectation : attributs]. [FTA_TSE.1.1] OT.ACCES_LOGIQUES 88 / 123

89 Classe Chemins et canaux de confiance [FTP] Chemin de confiance / Authentification initiale [FTP_TRP.1] La TSF doit fournir un chemin de communication entre elle-même et des utilisateurs [sélection : distants, locaux] qui soit logiquement distinct des autres chemins de communication et qui garantisse l identification de ses extrémités et la protection des données transférées contre une modification ou une divulgation. [FTP_TRP.1.1] La TSF doit permettre à [sélection : la TSF, des utilisateurs locaux, des utilisateurs distants] d initier une communication via le chemin de confiance. [FTP_TRP.1.2] La TSF doit exiger l utilisation du chemin de confiance pour [l'authentification initiale d un utilisateur]. [FTP_TRP.1.3] Note(s) d'application : La TOE doit authentifier tous les Acteurs. Or ceux-ci utilisent des Systèmes TI non sûrs au sens des CC. Le composant est donc nécessaire pour protéger l'authentification de tous les Acteurs. Le composant est nécessaire pour satisfaire OT.AUTH_TOE lorsque des Biens Acteurs ou des Biens SBFI, échangés entre la TOE et un Système TI qui n'est pas de confiance, ont un besoin de confidentialité et/ou d'intégrité et/ou d'identification des extrémités pour l'authentification initiale de l'acteur (le composant est itéré pour traiter les besoins allant au delà de l'authentification initiale). Concernant FTP_TRP.1.1 : Selon leur Rôle, les Acteurs sont à considérer comme distants uniquement ou bien distants ou locaux. A savoir : o utilisateurs uniquement distants : Utilisateur ; Fournisseur de données ; Chargé de clientèle ; SPBF ; o utilisateurs pouvant être distants ou locaux : Exploitant ; Administrateur. Concernant FTP_TRP.1.2 : la ou les parties pouvant initier une communication varie selon l'acteur et le «service». Le ou les initiateurs sont donc à définir dans la ST. OT.AUTH_TOE OT.VIE_PRIVEE Chemin de confiance / Authentification initiale [FTP_TRP.1/Auth] La TSF doit fournir un chemin de communication entre elle-même et des utilisateurs [sélection : distants, locaux] qui soit logiquement distinct des autres chemins de communication et qui garantisse l identification de ses extrémités et la protection des données transférées contre une modification ou une divulgation. [FTP_TRP.1.1/Auth] 89 / 123

90 La TSF doit permettre à [sélection : la TSF, des utilisateurs locaux, des utilisateurs distants] d initier une communication via le chemin de confiance. [FTP_TRP.1.2/Auth] La TSF doit exiger l utilisation du chemin de confiance pour [l'authentification initiale d un utilisateur]. [FTP_TRP.1.3/Auth] Note(s) d'application : La TOE doit authentifier tous les Acteurs (cf. OT.ID&A_UTILISATEUR et OT.ID&A_HORS_UTILISATEUR). Or ceux-ci utilisent des Systèmes TI non sûrs au sens des CC. Le composant est donc nécessaire pour protéger l'authentification de tous les Acteurs. Le composant est nécessaire pour satisfaire OT.PROTECTION_BIENS_TRANSMIS lorsque des Biens Acteurs ou des Biens SBFI, échangés entre la TOE et un Système TI qui n'est pas de confiance, ont un besoin de confidentialité et/ou d'intégrité et/ou d'identification des extrémités pour l'authentification initiale de l'acteur (le composant est itéré pour traiter les besoins allant au delà de l'authentification initiale). Concernant FTP_TRP.1.1 : Selon leur Rôle, les Acteurs sont à considérer comme distants uniquement ou bien distants ou locaux. A savoir : o utilisateurs uniquement distants : Utilisateur ; Fournisseur de données ; Chargé de clientèle ; SPBF ; o utilisateurs pouvant être distants ou locaux : Exploitant ; Administrateur. Concernant FTP_TRP.1.2 : la ou les parties pouvant initier une communication varie selon l'acteur et le «service». Le ou les initiateurs sont donc à définir dans la ST. OT.PROTECTION_BIENS_TRANSMIS Chemin de confiance / Hors authentification initiale [FTP_TRP.1/Hors_Auth] La TSF doit fournir un chemin de communication entre elle-même et des utilisateurs [sélection : distants, locaux] qui soit logiquement distinct des autres chemins de communication et qui garantisse l identification de ses extrémités et la protection des données transférées contre une modification ou une divulgation. [FTP_TRP.1.1/Hors_Auth] La TSF doit permettre à [sélection : la TSF, des utilisateurs locaux, des utilisateurs distants] d initier une communication via le chemin de confiance. [FTP_TRP.1.2/Hors_Auth] La TSF doit exiger l utilisation du chemin de confiance pour [affectation : autres services pour lesquels un chemin de confiance est exigé]. [FTP_TRP.1.3/Hors_Auth] Note d'application : ce composant est nécessaire pour satisfaire OT.PROTECTION_BIENS_TRANSMIS lorsque des Biens Acteurs ou des Biens SBFI, échangés 90 / 123

91 entre la TOE et un Système TI qui n'est pas de confiance, ont un besoin de confidentialité et/ou d'intégrité et/ou d'identification des extrémités ne portant pas sur l'authentification initiale. OT.PROTECTION_BIENS_TRANSMIS Tableau de synthèse de couverture des exigences fonctionnelles X : Exigence C : Exigence conditionnée Couvert par les exigences OT.VIE_PRIVEE OT.CONSENTEMENT_UTILISATEUR OT.CONFIRMATION_UTILISATEUR OT.OPPOSITION_SBFI OT.PREUVE_TRANSACTION OT.TYPE_CANAUX OT.PROTECTION_BIENS_TRANSMIS OT.PROTECTION_BIENS_STOCKES OT.ID_TOE_INTERNET OT.AUTH_TOE OT.ID&A_UTILISATEUR OT.ID&A_HORS_UTILISATEUR OT.AUTH_FORTE_UTILISATEUR OT.NON_CONTOURNEMENT OT.AUDIT OT.PISTE_AUDIT OT.TRACE OT.SURVEILLANCE OT.REACTION OT.CRYPTO_MECANISMES OT.CRYPTO_UTILISATEUR OT.ISOLATION_SECRETS_CRYPTO OT.CRYPTO_DYNAMIQUE OT.CRYPTO_RESISTANCE OT.ACCES_LOGIQUES OT.FLUX_LOGIQUES FAU_ARP.1 FAU_GEN.1 X X X X X X X FAU_GEN.2 X X X FAU_SAA.1 X X X FAU_SAR.1 X X FAU_SAR.2 X X FAU_SEL.1 X X FAU_STG.1 X X FAU_STG.2 X X X X FAU_STG.4 X X X X FCO_NRO.1 C FCO_NRO.2 X C FCS_CKM.1 C X X X X X X 91 / 123

92 Couvert par les exigences OT.VIE_PRIVEE OT.CONSENTEMENT_UTILISATEUR OT.CONFIRMATION_UTILISATEUR OT.OPPOSITION_SBFI OT.PREUVE_TRANSACTION OT.TYPE_CANAUX OT.PROTECTION_BIENS_TRANSMIS OT.PROTECTION_BIENS_STOCKES OT.ID_TOE_INTERNET OT.AUTH_TOE OT.ID&A_UTILISATEUR OT.ID&A_HORS_UTILISATEUR OT.AUTH_FORTE_UTILISATEUR OT.NON_CONTOURNEMENT OT.AUDIT OT.PISTE_AUDIT OT.TRACE OT.SURVEILLANCE OT.REACTION OT.CRYPTO_MECANISMES OT.CRYPTO_UTILISATEUR OT.ISOLATION_SECRETS_CRYPTO OT.CRYPTO_DYNAMIQUE OT.CRYPTO_RESISTANCE OT.ACCES_LOGIQUES OT.FLUX_LOGIQUES FCS_CKM.1pourCKM2 X FCS_CKM.2 C X C X X FCS_CKM.3 C X X X X FCS_CKM.4 C X X X X X X FCS_COP.1 C X X C FDP_ACC.1 X X C C X X X X X X X X FDP_ACF.1 X X X X X X X X X X FDP_DAU.1 X FDP_ETC.1/A X X X FDP_ETC.1/AouF X FDP_IFC.1 X X X C C X FDP_IFF.1 X X C X X FDP_ITC.1/A X FDP_ITC.1/AouF X FDP_ITT.1/A X FDP_ITT.1/AouF X X FDP_ROL.1/AouF X FDP_SDI.1 X FIA_AFL.1 C X X X FIA_ATD.1 X FIA_SOS.1 C X X X FIA_UAU.1 C X X FIA_UAU.2 X FIA_UAU.4 C X FIA_UAU.7 C X X X FIA_UID.1 X X X X X C C C C C X X X X C C C C C C C 92 / 123

93 Couvert par les exigences OT.VIE_PRIVEE OT.CONSENTEMENT_UTILISATEUR OT.CONFIRMATION_UTILISATEUR OT.OPPOSITION_SBFI OT.PREUVE_TRANSACTION OT.TYPE_CANAUX OT.PROTECTION_BIENS_TRANSMIS OT.PROTECTION_BIENS_STOCKES OT.ID_TOE_INTERNET OT.AUTH_TOE OT.ID&A_UTILISATEUR OT.ID&A_HORS_UTILISATEUR OT.AUTH_FORTE_UTILISATEUR OT.NON_CONTOURNEMENT OT.AUDIT OT.PISTE_AUDIT OT.TRACE OT.SURVEILLANCE OT.REACTION OT.CRYPTO_MECANISMES OT.CRYPTO_UTILISATEUR OT.ISOLATION_SECRETS_CRYPTO OT.CRYPTO_DYNAMIQUE OT.CRYPTO_RESISTANCE OT.ACCES_LOGIQUES OT.FLUX_LOGIQUES FIA_UID.2 C C C C C X C C C C C C C FMT_MOF.1 C FMT_MSA.1/A X X X X X X X X X X FMT_MSA.1/F X X X X FMT_MSA.1/AouF X X FMT_MSA.2/A X X X X X FMT_MSA.2/AouF X FMT_MSA.3/A X X X X X X X X X X FMT_MSA.3/F X X X X FMT_MSA.3/AouF X FMT_MTD.1 C X X FMT_SMR.1 X X X X X X X X X X X X X X X X X X FPT_ITT.1 X FPT_RPL.1 X X X FPT_RVM.1 X FPT_SEP.1 C X X X FPT_STM.1 X X X X X X X FPT_TRC.1 X FTA_TAB.1 X FTA_TAH.1 X X FTA_TSE.1 X FTP_TRP.1 C X FTP_TRP.1/Auth X FTP_TRP.1/Hors_Auth X 93 / 123

94 4.1.2 Exigences d'assurance Composition du package d'assurance Conformément à la norme ISO/IEC 15408, les exigences doivent être formulées en langue anglaise. Dans ce document, les exigences en langue anglaise, pour des raisons de facilité d usage, ont été traduites en français 5. Les exigences d assurance retenues de ce profil de protection ne déterminent pas de niveau EAL, mais pour certaines un niveau minimum a été spécifié. Le tableau ci-dessous présente l'intégralité des composants d'assurance retenus. Les conventions pour les colonnes du tableau sont : "Classe d'assurance" : indique la classe du composant, conformément à l'iso/iec ; "Famille d'assurance" : indique la famille du composant, conformément à l'iso/iec ; "Composant d'assurance retenu" : indique l'indice du composant d'assurance retenu ; "Nombre de composants" : indique le nombre de composants dans la famille considérée. Cette indication a pour but d'aider à situer le ou les composants choisis parmi tous ceux de la famille (tous les composants d'assurance d'une famille sont hiérarchiques). Classe d'assurance Famille d'assurance Composant d'assurance retenu Nombre de composants Gestion de configuration ACM_AUT 2 ACM_CAP 3 5 ACM_SCP 2 3 Livraison et exploitation ADO_DEL 1 3 ADO_IGS 1 2 Développement ADV_FSP 1 4 ADV_HLD 2 5 ADV_IMP 3 ADV_INT 3 ADV_LLD 3 ADV_RCR 1 1 ADV_SPM 3 Guides AGD_ADM 1 1 AGD_USR 1 1 Support au cycle de vie ALC_DVS 1 2 ALC_FLR 1 3 ALC_LCD 3 ALC_TAT 3 Tests ATE_COV 1 3 ATE_DPT 3 ATE_FUN 1 2 ATE_IND 1 3 Estimation des vulnérabilités AVA_CCA 3 AVA_MSU 3 AVA_SOF En cas de divergence entre la version traduite en français et la version anglaise, la version anglaise fait référence. 94 / 123

95 AVA_VLA 2 4 Tableau 10 : Liste des exigences d'assurance retenues Détail des exigences d'assurances Les composants d'assurance retenus sont présentés dans l'ordre alphabétique de leurs abréviations Classe Gestion de configuration [ACM] Famille Capacités de la Configuration Management (CM) [ACM_CAP] Contrôles des autorisations [ACM_CAP.3] Tâches du développeur : Le développeur doit fournir une référence pour la TOE [ACM_CAP.3.1D] Le développeur doit utiliser un système de CM [ACM_CAP.3.2D] Le développeur doit fournir une documentation de CM [ACM_CAP.3.3D] Contenu et présentation des éléments de preuve : La référence de la TOE doit être unique pour chaque version de la TOE [ACM_CAP.3.1C] La TOE doit être identifiée par sa référence [ACM_CAP.3.2C] La documentation de CM doit inclure une liste de configuration et un plan de CM [ACM_CAP.3.3C] La liste de configuration doit décrire les éléments de configuration qui constituent la TOE [ACM_CAP.3.4C] La documentation CM doit décrire la méthode utilisée pour identifier de façon unique les éléments de configuration [ACM_CAP.3.5C] Le système de CM doit identifier de façon unique tous les éléments de configuration [ACM_CAP.3.6C] Le plan de CM doit décrire comment le système de CM est utilisé [ACM_CAP.3.7C] Les éléments de preuve doivent démontrer que le système de CM fonctionne conformément au plan de CM [ACM_CAP.3.8C] La documentation de CM doit fournir des éléments de preuve montrant que tous les éléments de configuration ont été et sont maintenus efficacement par le système de CM [ACM_CAP.3.9C] Le système de CM doit proposer des mesures permettant que les changements autorisés sur les éléments de configuration [ACM_CAP.3.10C] Tâches de l'évaluateur : L évaluateur doit confirmer que les informations fournies satisfont à toutes les exigences relatives au contenu et à la présentation des éléments de preuve [ACM_CAP.3.1E] Note(s) d'application : ACM_CAP.3 est retenu car il peut être satisfait uniquement à l'aide de mesures organisationnelles. ACM_CAP.3.10C comporte une faute de typographie. Il doit se lire : "Le système de CM doit proposer des mesures ne permettant que les changements autorisés sur les éléments de configuration" Famille Portée de la CM [ACM_SCP] Couverture du suivi des problèmes par la CM [ACM_SCP.2] Tâches du développeur : Le développeur doit fournir la documentation de CM [ACM_SCP.2.1D] Contenu et présentation des éléments de preuve : 95 / 123

96 La documentation de CM doit montrer que le système CM contrôle au minimum les éléments suivants : la représentation de l implémentation de la TOE, la documentation de conception, la documentation de test, la documentation de l utilisateur, la documentation de l administrateur, la documentation de CM et les anomalies de sécurité [ACM_SCP.2.1C] La documentation de CM doit décrire comment les éléments de configuration sont contrôlés par le système de CM [ACM_SCP.2.2C] Tâches de l'évaluateur : L évaluateur doit confirmer que les informations fournies satisfont à toutes les exigences relatives au contenu et à la présentation des éléments de preuve [ACM_SCP.2.1E] Classe Livraison et exploitation [ADO] Famille Livraison [ADO_DEL] Procédures de livraison [ADO_DEL.1] Tâches du développeur : Le développeur doit documenter les procédures de livraison à l utilisateur de la TOE ou de parties de celleci [ADO_DEL.1.1D] Le développeur doit utiliser les procédures de livraison [ADO_DEL.1.2D] Contenu et présentation des éléments de preuve : La documentation de livraison doit décrire toutes les procédures qui sont nécessaires pour maintenir la sécurité lors de la distribution de versions de la TOE vers le site d un utilisateur [ADO_DEL.1.1C] Tâches de l'évaluateur : L évaluateur doit confirmer que les informations fournies satisfont à toutes les exigences pour le contenu et la présentation des éléments de preuve [ADO_DEL.1.1E] Famille Installation, génération et démarrage [ADO_IGS] Procédures d installation, de génération et de démarrage [ADO_IGS.1] Tâches du développeur : Le développeur doit documenter les procédures nécessaires à une installation, une génération et un démarrage sûrs de la TOE [ADO_IGS.1.1D] Contenu et présentation des éléments de preuve : La documentation doit décrire les étapes nécessaires à une installation, une génération et un démarrage sûrs de la TOE [ADO_IGS.1.1C] Tâches de l'évaluateur : L évaluateur doit confirmer que les informations fournies satisfont à toutes les exigences pour le contenu et la présentation des éléments de preuve [ADO_IGS.1.1E] L évaluateur doit déterminer que les procédures d installation, de génération et de démarrage conduisent à une configuration sûre [ADO_IGS.1.2E] Note(s) d'application : Une installation, une génération et un démarrage sont «sûrs» quand ils permettent de mettre la TOE dans l'état de sécurité spécifié. Selon les TOE, installation et génération peuvent se faire dans un ordre différent. Une bonne pratique est souvent de réduire au strict minimum les opérations à effectuer sur site. La génération est alors pour sa plus grande partie faite avant l'installation sur site Classe Développement [ADV] 96 / 123

97 Famille Spécifications fonctionnelles [ADV_FSP] Spécifications fonctionnelles informelles [ADV_FSP.1] Tâches du développeur : Le développeur doit fournir des spécifications fonctionnelles [ADV_FSP.1.1D] Contenu et présentation des éléments de preuve : Les spécifications fonctionnelles doivent décrire la TSF et ses interfaces externes dans un style informel [ADV_FSP.1.1C] Les spécifications fonctionnelles doivent avoir une cohérence interne [ADV_FSP.1.2C] Les spécifications fonctionnelles doivent décrire le but et le mode d emploi de toutes les interfaces externes de la TSF, en fournissant, lorsque cela est approprié, les détails sur les effets, les exceptions et les messages d erreur [ADV_FSP.1.3C] Les spécifications fonctionnelles doivent représenter complètement la TSF [ADV_FSP.1.4C] Tâches de l'évaluateur : L évaluateur doit confirmer que les informations fournies satisfont à toutes les exigences relatives au contenu et à la présentation des éléments de preuve [ADV_FSP.1.1E] L évaluateur doit déterminer que les spécifications fonctionnelles constituent une instantiation correcte et complète des exigences fonctionnelles de sécurité de la TOE [ADV_FSP.1.2E] Famille Conception de haut niveau [ADV_HLD] Conception de haut niveau - identification des sous-sytèmes dédiés à la sécurité [ADV_HLD.2] Tâches du développeur : Le développeur doit fournir la conception de haut niveau de la TSF [ADV_HLD.2.1D] Contenu et présentation des éléments de preuve : La présentation de la conception de haut niveau doit être en style informel [ADV_HLD.2.1C] La conception de haut niveau doit avoir une cohérence interne [ADV_HLD.2.2C] La conception de haut niveau doit décrire la structure de la TSF en termes de sous-systèmes [ADV_HLD.2.3C] La conception de haut niveau doit décrire les fonctionnalités de sécurité fournies par chaque sous-système de la TSF [ADV_HLD.2.4C] La conception de haut niveau doit identifier tout matériel, micro-programme ou logiciel sous-jacent exigé par la TSF, et présenter les fonctions fournies par le mécanisme de protection de soutien implémenté dans ce matériel, micro-programme ou logiciel [ADV_HLD.2.5C] La conception de haut niveau doit identifier toutes les interfaces des sous-systèmes de la TSF [ADV_HLD.2.6C] La conception de haut niveau doit identifier les interfaces des sous-systèmes de la TSF qui sont visibles de l extérieur [ADV_HLD.2.7C] La conception de haut niveau doit décrire le but et le mode d emploi de toutes les interfaces des soussystèmes de la TSF, en fournissant, lorsque cela est approprié, les détails sur les effets, les exceptions et les messages d erreur [ADV_HLD.2.8C] La conception de haut niveau doit décrire la séparation de la TOE entre les sous-systèmes dédiés à la mise en œuvre de la TSP et les autres sous-systèmes [ADV_HLD.2.9C] Tâches de l'évaluateur : L évaluateur doit confirmer que les informations fournies satisfont à toutes les exigences relatives au contenu et à la présentation des éléments de preuve [ADV_HLD.2.1E] L évaluateur doit déterminer que la conception de haut niveau est une instantiation correcte et complète des exigences fonctionnelles de sécurité de la TOE [ADV_HLD.2.2E] 97 / 123

98 Note d'application : la relation entre sous-systèmes de la TSF et Blocs fonctionnels doit être définie Famille Correspondance des représentations [ADV_RCR] Démonstration de correspondance informelle [ADV_RCR.1] Tâches du développeur : Le développeur doit fournir une analyse de correspondance entre toutes les paires de représentations de la TSF adjacentes fournies [ADV_RCR.1.1D] Contenu et présentation des éléments de preuve : Pour chaque paire de représentations de la TSF adjacentes fournies, l analyse doit démontrer que toutes les fonctionnalités de sécurité pertinentes de la représentation de la TSF la plus abstraite sont correctement et complètement raffinées dans la représentation de la TSF la moins abstraite [ADV_RCR.1.1C] Tâches de l'évaluateur : L évaluateur doit confirmer que les informations fournies satisfont à toutes les exigences relatives au contenu et à la présentation des éléments de preuve [ADV_RCR.1.1E] Classe Guides [AGD] Famille Guide de l administrateur [AGD_ADM] Guide de l administrateur [AGD_ADM.1] Tâches du développeur : Le développeur doit fournir un guide de l administrateur à l attention du personnel chargé de l administration du système [AGD_ADM.1.1D] Contenu et présentation des éléments de preuve : Le guide de l administrateur doit décrire les fonctions et les interfaces d administration à la disposition de l administrateur de la TOE [AGD_ADM.1.1C] Le guide de l administrateur doit décrire comment administrer la TOE d une façon sûre [AGD_ADM.1.2C] Le guide de l administrateur doit contenir des avertissements concernant les fonctions et les privilèges qui devraient être contrôlés dans un environnement d exploitation sûr [AGD_ADM.1.3C] Le guide de l administrateur doit décrire toutes les hypothèses relatives au comportement de l utilisateur, qui ont un rapport avec l exploitation sûre de la TOE [AGD_ADM.1.4C] Le guide de l administrateur doit décrire tous les paramètres de sécurité qui sont sous le contrôle de l administrateur, en indiquant les valeurs sûres quand cela est approprié [AGD_ADM.1.5C] Le guide de l administrateur doit décrire chaque type d événement touchant à la sécurité, relatif aux fonctions d administration qui doivent être réalisées, y compris le changement des caractéristiques de sécurité d entités qui sont sous le contrôle de la TSF [AGD_ADM.1.6C] Le guide de l administrateur doit être cohérent avec tous les autres documents fournis pour l évaluation [AGD_ADM.1.7C] Le guide de l administrateur doit décrire toutes les exigences de sécurité pour l environnement TI, qui concernent l administrateur [AGD_ADM.1.8C] Tâches de l'évaluateur : L évaluateur doit confirmer que les informations fournies satisfont à toutes les exigences relatives au contenu et à la présentation des éléments de preuve [AGD_ADM.1.1E] Famille Guide de l'utilisateur [AGD_USR] 98 / 123

99 Guide de l utilisateur [AGD_USR.1] Tâches du développeur : Le développeur doit fournir un guide de l utilisateur [AGD_USR.1.1D] Contenu et présentation des éléments de preuve : Le guide de l utilisateur doit décrire les fonctions et les interfaces disponibles aux utilisateurs ne remplissant pas des fonctions d administrateurs de la TOE [AGD_USR.1.1C] Le guide de l utilisateur doit décrire l utilisation des fonctions de sécurité fournies par la TOE accessibles aux utilisateurs [AGD_USR.1.2C] Le guide de l utilisateur doit contenir des avertissements concernant les fonctions et les privilèges accessibles aux utilisateurs qui devraient être contrôlés dans un environnement d exploitation sûr [AGD_USR.1.3C] Le guide de l utilisateur doit présenter clairement toutes les responsabilités qui incombent à l utilisateur et qui sont nécessaires pour une exploitation sûre de la TOE, y compris celles liées aux hypothèses relatives au comportement de l utilisateur figurant dans l énoncé de l environnement de sécurité de la TOE [AGD_USR.1.4C] Le guide de l utilisateur doit être cohérent avec toute autre documentation fournie pour l évaluation [AGD_USR.1.5C] Le guide de l utilisateur doit décrire toutes les exigences de sécurité pour l environnement TI, qui concernent l utilisateur [AGD_USR.1.6C] Tâches de l'évaluateur : L évaluateur doit confirmer que les informations fournies satisfont à toutes les exigences relatives au contenu et à la présentation des éléments de preuve [AGD_USR.1.1E] Classe Support au cycle de vie [ALC] Famille Sécurité du développement [ALC_DVS] Identification des mesures de sécurité [ALC_DVS.1] Tâches du développeur : Le développeur doit produire la documentation relative à la sécurité du Développement [ALC_DVS.1.1D] Contenu et présentation des éléments de preuve : La documentation relative à la sécurité du développement doit décrire toutes les mesures de sécurité physiques, organisationnelles, touchant au personnel et autres qui sont nécessaires pour protéger la confidentialité et l intégrité de la conception et de l implémentation de la TOE dans son environnement de développement [ALC_DVS.1.1C] La documentation relative à la sécurité du développement doit fournir des éléments de preuve indiquant que ces mesures de sécurité sont appliquées au cours du développement et de la maintenance de la TOE [ALC_DVS.1.2C] Tâches de l'évaluateur : L évaluateur doit confirmer que les informations fournies satisfont à toutes les exigences relatives au contenu et à la présentation des éléments de preuve [ALC_DVS.1.1E] L évaluateur doit confirmer que les mesures de sécurité sont appliquées [ALC_DVS.1.2E] Famille Correction d anomalies [ALC_FLR] 99 / 123

100 Correction élémentaire d anomalies [ALC_FLR.1] Tâches du développeur : Le développeur doit documenter les procédures de correction d anomalies [ALC_FLR.1.1D] Contenu et présentation des éléments de preuve : La documentation relative aux procédures de correction d anomalies doit décrire les procédures utilisées pour surveiller toutes les anomalies de sécurité signalées dans chaque version de la TOE [ALC_FLR.1.1C] Les procédures de correction d anomalies doivent exiger qu une description de la nature et des effets de chaque anomalie de sécurité soit fournie, ainsi que l état d avancement de la recherche d une correction de cette anomalie [ALC_FLR.1.2C] Les procédures de correction d anomalies doivent exiger que des actions correctives soient identifiées pour chacune des anomalies de sécurité [ALC_FLR.1.3C] La documentation relative aux procédures de correction d anomalies doit décrire les méthodes utilisées pour fournir aux utilisateurs de la TOE les informations sur les anomalies, les corrections et les conseils concernant les actions correctives [ALC_FLR.1.4C] Tâches de l'évaluateur : L évaluateur doit confirmer que les informations fournies satisfont à toutes les exigences relatives au contenu et à la présentation des éléments de preuve [ALC_FLR.1.1E] Classe Tests [ATE] Famille Couverture [ATE_COV] Éléments de preuve de la couverture [ATE_COV.1] Tâches du développeur : Le développeur doit fournir les éléments de preuve de la couverture des tests [ATE_COV.1.1D] Contenu et présentation des éléments de preuve : Les éléments de preuve de la couverture des tests doivent montrer la correspondance entre les tests identifiés dans la documentation de test et la TSF, telle qu elle est décrite dans les spécifications fonctionnelles [ATE_COV.1.1C] Tâches de l'évaluateur : L évaluateur doit confirmer que les informations fournies satisfont à toutes les exigences relatives au contenu et à la présentation des éléments de preuve [ATE_COV.1.1E] Note d'application : le non-contournement des Blocs fonctionnels doit faire l'objet de tests Famille Tests fonctionnels [ATE_FUN] Tests fonctionnels [ATE_FUN.1] Tâches du développeur : Le développeur doit tester la TSF et documenter les résultats [ATE_FUN.1.1D] Le développeur doit fournir la documentation de test [ATE_FUN.1.2D] Contenu et présentation des éléments de preuve : La documentation de test doit être constituée des plans de test, des descriptions de procédures de test, des résultats de tests attendus et des résultats de tests réellement obtenus [ATE_FUN.1.1C] Les plans de test doivent identifier les fonctions de sécurité à tester et décrire le but des tests à exécuter [ATE_FUN.1.2C] Les descriptions des procédures de test doivent identifier les tests à exécuter et décrire les scenarii de test de chaque fonction de sécurité. Ces scénarios doivent inclure tous les ordonnancements relatifs aux résultats des autres tests [ATE_FUN.1.3C] 100 / 123

101 Les résultats de tests attendus doivent montrer les résultats prévus à la suite d une exécution réussie des tests [ATE_FUN.1.4C] Les résultats de tests provenant de l exécution des tests par le développeur doivent démontrer que chaque fonction de sécurité testée s est comportée conformément à ses spécifications [ATE_FUN.1.5C] Tâches de l'évaluateur : L évaluateur doit confirmer que les informations fournies satisfont à toutes les exigences relatives au contenu et à la présentation des éléments de preuve [ATE_FUN.1.1E] Famille Tests indépendants [ATE_IND] Tests indépendants conformité [ATE_IND.1] Tâches du développeur : Le développeur doit fournir la TOE afin d exécuter les tests [ATE_IND.1.1D] Contenu et présentation des éléments de preuve : La TOE doit se prêter à l exécution de tests [ATE_IND.1.1C] Tâches de l'évaluateur : L évaluateur doit confirmer que les informations fournies satisfont à toutes les exigences relatives au contenu et à la présentation des éléments de preuve [ATE_IND.1.1E] L évaluateur doit tester un sous-ensemble de la TSF quand cela est approprié pour confirmer que la TOE fonctionne conformément à ses spécifications [ATE_IND.1.2E] Classe Estimation des vulnérabilités [AVA] Famille Résistance des fonctions de sécurité de la TOE [AVA_SOF] Évaluation de la résistance des fonctions de sécurité de la TOE [AVA_SOF.1] Tâches du développeur : Le développeur doit effectuer une analyse de la résistance des fonctions de sécurité de la TOE pour chaque mécanisme identifié dans la ST faisant l objet d une annonce de résistance des fonctions de sécurité de la TOE [AVA_SOF.1.1D] Contenu et présentation des éléments de preuve : Pour chaque mécanisme faisant l objet d une annonce de résistance des fonctions de sécurité de la TOE, l analyse de la résistance des fonctions de sécurité de la TOE doit montrer qu il atteint ou dépasse le niveau de résistance minimum défini dans le PP ou la ST [AVA_SOF.1.1C] Pour chaque mécanisme faisant l objet d une annonce spécifique de résistance des fonctions de sécurité de la TOE, l analyse de la résistance des fonctions de sécurité de la TOE doit montrer qu il atteint ou dépasse la métrique spécifique de la résistance des fonctions définie dans le PP ou la ST [AVA_SOF.1.2C] Tâches de l'évaluateur : L évaluateur doit confirmer que les informations fournies satisfont à toutes les exigences relatives au contenu et à la présentation des éléments de preuve [AVA_SOF.1.1E] L évaluateur doit confirmer que les annonces de la résistance sont correctes [AVA_SOF.1.2E] Famille Analyse de vulnérabilités [AVA_VLA] 101 / 123

102 Analyse de vulnérabilités indépendante [AVA_VLA.2] Tâches du développeur : Le développeur doit effectuer et documenter une analyse des fournitures de la TOE pour rechercher les moyens par lesquels un utilisateur peut violer la TSP [AVA_VLA.2.1D] Le développeur doit documenter les caractéristiques des vulnérabilités identifiées [AVA_VLA.2.2D] Contenu et présentation des éléments de preuve : La documentation doit montrer, pour toutes les vulnérabilités identifiées, que la vulnérabilité ne peut pas être exploitée dans l environnement prévu pour la TOE [AVA_VLA.2.1C] La documentation doit justifier que la TOE, compte tenu des vulnérabilités identifiées, est résistante aux attaques de pénétration évidentes [AVA_VLA.2.2C] Tâches de l'évaluateur : L évaluateur doit confirmer que les informations fournies satisfont à toutes les exigences relatives au contenu et à la présentation des éléments de preuve [AVA_VLA.2.1E] L évaluateur doit effectuer des tests de pénétration, en s appuyant sur l analyse de vulnérabilités du développeur, pour garantir que les vulnérabilités identifiées ont été prises en compte [AVA_VLA.2.2E] L évaluateur doit effectuer une analyse de vulnérabilités indépendante [AVA_VLA.2.3E] L évaluateur doit effectuer des tests de pénétration indépendants, basés sur une analyse de vulnérabilités indépendante, afin de déterminer le caractère exploitable des vulnérabilités supplémentaires identifiées dans l environnement prévu [AVA_VLA.2.4E] L évaluateur doit déterminer si la TOE est résistante aux attaques de pénétration effectuées par un attaquant ayant un potentiel d attaque élémentaire [AVA_VLA.2.5E] 102 / 123

103 4.2 Notes d'application Les notes d application ont été volontairement reparties dans tout le document. Elles se trouvent à la suite des éléments qui les concernent. 4.3 Argumentaire Ce chapitre contient la justification de la cohérence du PP. Il est destiné à un public très restreint, incluant notamment l'évaluateur du PP. Pour alléger le document, il figure donc sur un document dédié intitulé "Argumentaire du PP". 103 / 123

104 5 ANNEXES 5.1 Bibliographie Textes législatifs ou réglementaires : Code Monétaire et Financier Loi n du 6 janvier 1978 relative à l'informatique, aux fichiers et aux libertés Directive 95/46/CE du Parlement européen et du Conseil, du 24 octobre 1995, relative à la protection des personnes physiques à l'égard du traitement des données à caractère personnel et à la libre circulation de ces données Comité de Bâle : Document "Risk Management Principles for Electronic Banking" (juillet 2003) Document "Sound Practices for the Management and Supervision of Operational Risk" (février 2003) Document " Management and supervision of cross-border electronic banking activities",(juillet 2003) Document consultatif "The Third Consultative Paper of the New Basel Capital Accord" (avril 2003) Organisation internationale des commissions de valeurs (International Organization of Securities Commissions) : Report on Securities Activity on the Internet II datant de juin 2001 Commission Bancaire, Comité de la réglementation bancaire et financière (CRBF) & Banque de France : Livre blanc sur la sécurité des systèmes d'information dans les établissements de crédit (2 nde édition de mars 1996) Livre blanc "Internet, quelles conséquences prudentielles?" (1 ère édition de décembre 2000) Règlement CRBF n du 26 juin 2001 relatif au contrôle interne des établissements de crédit et des entreprises d'investissement et modifiant le règlement n du 21 février 1997 relatif au contrôle interne des établissements de crédit Conseil des Marchés Financiers : Règlement général du Conseil des Marchés Financiers Décision n relative à la conservation des données afférentes aux transactions sur les instruments financiers admis aux négociations sur un marché réglementé Décision n relative aux prescriptions et recommandations pour les prestataires de services d'investissement offrant un service de réception-transmission ou d'exécution d'ordres de bourse comportant une réception des ordres via Internet Décision n relative à l'application des règles de bonne conduite à l'occasion de l'introduction de sociétés en bourse Rapport de synthèse intitulé "Contrôle de la réception d ordres par Internet" publié dans la revue n 35 du Conseil (février 2001) Commission des Opérations de Bourse : Règlement n relatif aux organismes de placement collectif en valeurs mobilières bénéficiant de la procédure allégée Règlement n modifiant le règlement n relatif aux organismes de placement collectif en valeurs mobilières bénéficiant de la procédure allégée Règlement n modifiant le règlement de la Commission des opérations de bourse n relatif aux organismes de placement collectif en valeurs mobilières bénéficiant d'une procédure allégée 104 / 123

105 Fédération des Banques Françaises Circulaire FBF n 2003/238 du 09/09/2003 "L'authentification - Les niveaux et les risques" Critères Communs : ISO/IEC : Critères Communs pour l'évaluation de la sécurité des technologies de l'information Partie 1 : Introduction et modèle général ISO/IEC : Critères Communs pour l'évaluation de la sécurité des technologies de l'information Partie 2 : Exigences fonctionnelles de sécurité ISO/IEC : Critères Communs pour l'évaluation de la sécurité des technologies de l'information Partie 3 : Exigences d'assurance de sécurité CEM-99/045 Part 2: Common Methodology for Information Technology Security Evaluation version 1.0 August 1999 ISO/IEC WD , Information technology Security techniques Guide for the production of Protection Profiles and Security Targets 6 Le working draft est proposé pour étude et commentaires dans le texte ISO de référence ISO/IEC JTC 1/SC 27 N 2603 daté du 20/04/ / 123

106 5.2 Acronymes, glossaire et terminologie Les acronymes ou termes issus de la norme ISO/IEC sont suivis de la mention : (CC). Les acronymes et les termes issus de la norme ISO/IEC sont listés en premier. Tous les acronymes et termes sont présentés par ordre alphabétique. Certains acronymes ci-dessous correspondent à des termes définis dans le glossaire ci-après. CC (CC) OSP (CC) PP (CC) SFP (CC) SOF (CC) ST (CC) TI (CC) TOE (CC) TSC (CC) TSF (CC) TSP (CC) Acronymes Common Criteria for Information Technology Security Evaluation. Critères Communs pour l'évaluation et la certification des TI Organisational Security Policy. Politique de sécurité organisationnelle Protection Profile. Profil de protection Security Function Policy. Politique d'une fonction de sécurité Strength Of Function. Résistance d'une fonction Security Target. Cible de sécurité Technologie de l'information Target of Evaluation. Cible d'évaluation TOE Scope of Control. Champ de contrôle de la TSF TOE Security Functions. Fonctions de sécurité de la TOE TOE Security Policy. Politique de sécurité d une TOE SBFI EARS SPBF Service bancaire et / ou financier transactionnel sur Internet Établissement Agréé Responsable d'un SBFI Système de Production Bancaire et / ou Financier AM CM EAL CESTI DCSSI Assurance Management. Maintenance de l'assurance Configuration management. Gestion de configuration Evaluation Assurance Level. Niveau d'évaluation de l'assurance. Les EAL sont définis dans la norme à titre indicatif, pour des raisons de compatibilité avec les niveaux ITSEC. Centre d évaluation de la sécurité des technologies de l information. Organisme d'évaluation français. Direction Centrale de la Sécurité des Systèmes d'information. Organisme de certification français. 106 / 123

107 5.2.2 Glossaire Authentification forte Authentification limitant les risques d'utilisation du ou des éléments d'authentification à l'insu de la personne (perte, vol, usurpation, simulation) Bien (CC) Information ou ressource d une TOE à protéger par des contre-mesures Champ de contrôle de la TSF (CC) Ensemble des interactions qui peuvent survenir avec ou à l intérieur d une TOE et qui sont soumises aux règles édictées par la TSP Cible d'évaluation (CC) Produit ou système TI, et la documentation associée pour l administrateur et pour l utilisateur qui est l objet d une évaluation Données de la TSF (CC) Données créées par et pour la TOE, et qui pourraient affecter le fonctionnement de la TOE Données utilisateur (CC) Evaluation (CC) Fonction de sécurité de la TOE (CC) Hypothèses (CC) Objectif de sécurité (CC) Politique de sécurité d une TOE (CC) Politique de sécurité organisationnelle (CC) Profil de Protection (CC) Résistance d'une fonction (CC) Rôle (CC) Système TI (CC) Données créées par et pour l utilisateur, et qui n affectent pas le fonctionnement de la TSF Estimation d un PP, d une ST ou d une TOE par rapport à des critères définis. Partie de la TOE qui prend en charge la sécurité Expression liée à la confiance que l'on peut avoir dans un élément de la TOE ou de son environnement Expression de l intention de contrer des Menaces identifiées ou de satisfaire à des Politiques de sécurité organisationnelles et à des Hypothèses Ensemble des règles qui précisent comment gérer, protéger et distribuer les Biens à l intérieur d une TOE Une ou plusieurs règles, procédures, codes de conduite ou lignes directrices de sécurité qu une organisation impose pour son fonctionnement Ensemble d exigences de sécurité valables pour une catégorie de TOE, indépendant de son implémentation, qui satisfait des besoins spécifiques d utilisateurs Caractéristique d une fonction de sécurité de la TOE exprimant les efforts minimum supposés nécessaires pour mettre en défaut le comportement de sécurité attendu par attaque directe des mécanismes de sécurité sous-jacents Ensemble prédéfini de règles régissant les interactions autorisées entre la TOE et un Acteur ou un Système TI externe Système informatique, i.e. ensemble de composants matériels et / ou logiciels de traitement de l'information sous forme électronique 107 / 123

108 Acteur Authentification Canal (de communication) Ouvert Contrôlé Canal Internet Transaction Utilisateur Toute personne physique ayant un accès physique et / ou logique à la TOE. Action de s'assurer de l'identité d'un Système TI ou d'une personne physique. Moyen d'échange d'informations sous forme électronique entre deux Systèmes TI. Trois types d'échanges d'informations sous forme électronique existent : partage d'informations (par exemple l'accès à une même base de données) ; transmission à l'intérieur d'une machine (par exemple les échanges entre deux processus gérés par la même unité centrale) ; transmission entre deux machines reliées par un réseau (par exemple la transmission sur un réseau local). Un Canal peut reposer sur plusieurs réseaux. Par exemple, le Canal employé par une personne se connectant par modem RTC à Internet afin d'accéder à un SBFI repose sur deux réseaux : celui de l'opérateur qui fournit l'accès RTC et le réseau Internet. Caractérise un Canal qui n'est pas contrôlé par l'ears. Caractérise 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 par l'ears. Canal Ouvert empruntant Internet. 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. Personne physique qui accède via un Canal Internet à un service bancaire et / ou un service financier, et est identifiée et vérifiée au préalable. 108 / 123

109 5.2.3 Terminologie relative aux exigences d'assurance La liste suivante contient des termes fréquemment utilisés dans la partie 3 de la norme ISO/IEC Cohérent (consistent) Ce terme décrit une relation entre deux entités ou plus et indique qu il n y a pas de contradictions apparentes entre ces entités Qui possède une cohérence interne (internally consistent) Il n y a pas de contradictions apparentes entre les aspects d une entité. Pour une documentation, cela signifie qu il n y a pas d énoncés dans la documentation pouvant être considérés comme contradictoires entre eux. Complet (complete) Toutes les parties nécessaires d'une entité ont été fournies. Pour une documentation, cela signifie que toutes les informations pertinentes figurent dans la documentation, à un niveau de détail tel qu aucune explication supplémentaire n est exigée au niveau d abstraction concerné Confirmer (confirm) Ce terme est utilisé pour indiquer que quelque chose doit être revu en détail et qu'une détermination indépendante de sa suffisante doit être réalisée. Le niveau de rigueur exigé dépend de la nature du sujet. Ce terme s applique seulement aux tâches de l évaluateur Contrer (counter) Ce terme est typiquement utilisé dans le contexte où un objectif de sécurité contre une menace particulière, mais n indique pas nécessairement qu il en résulte que la menace est complètement éradiquée Contrôler (verify) Ce terme est similaire au terme confirmer, mais possède des connotations plus rigoureuses. Utilisé dans le contexte des tâches de l évaluateur, ce terme indique qu un effort indépendant est exigé de la part de l évaluateur. Décrire (describe) Ce terme exige que certains détails spécifiques à une entité soient fournis Démontrer (demonstrate) Ce terme fait référence à une analyse menant à une conclusion, ce qui est moins rigoureux qu une preuve (proof) Déterminer (determine) Ce terme exige que soit menée une analyse indépendante, avec pour objectif de parvenir à une certaine conclusion. L utilisation de ce terme diffère de celle de confirmer (confirm) ou de contrôler (verify), puisque ces autres termes impliquent qu une analyse a déjà été effectuée et doit être revue, alors que l utilisation de déterminer (determine) implique que soit menée une analyse véritablement indépendante, en général sans qu'aucune analyse préalable n'ait été effectuée Exhaustif (exhaustive) Ce terme est utilisé dans les CC pour ce qui concerne la conduite d une analyse ou d une autre activité. Il a une signification proche de celle de systématique (systematic) mais considérablement renforcée, du fait qu il indique non seulement qu une approche méthodique a été adoptée pour effectuer l analyse ou l activité concernée selon un plan non ambigu, mais également que le plan qui a été suivi est suffisant pour garantir que toutes les voies possibles ont été explorées Expliquer (explain) Ce terme diffère à la fois de décrire et de démontrer. Il est censé répondre à la question Pourquoi? sans essayer réellement de prétendre que la ligne de conduite qui a été choisie était nécessairement optimale Garantir (ensure) Ce terme, utilisé seul, implique une forte relation de cause à effet entre une action et ses conséquences. Ce terme est précédé typiquement de 109 / 123

110 l expression aide à (helps), qui indique que la conséquence n est pas absolument certaine, sur la base de cette seule action Intelligible (coherent) Une entité est logiquement ordonnée et possède une signification discernable. Pour une documentation, cela concerne à la fois le texte lui-même et la structure du document, à savoir s il est compréhensible par l audience visée Justification (justification) Ce terme fait référence à une analyse aboutissant à une conclusion, mais il se veut plus rigoureux que le terme démonstration car il exige une rigueur significative pour expliquer très soigneusement et complètement chaque étape d un argument logique Prouver (prove) Ce terme fait référence à une analyse formelle au sens mathématique. Il a une signification de rigueur totale dans tous les cas. Typiquement, prouver est utilisé lorsqu on désire montrer la correspondance entre deux représentations de la TSF avec un niveau élevé de rigueur Qui se soutiennent mutuellement (mutually supportive) Ce terme décrit une relation au sein d un groupe d entités et indique que les entités possèdent des propriétés qui n entrent pas en conflit et qui peuvent aider les autres entités à remplir leurs tâches. Il n est pas nécessaire de déterminer que chaque entité individuelle en question apporte une aide directe à d autres entités de ce groupe ; en fait, c est une détermination plus générale qui est faite Spécifier (specify) Ce terme est utilisé dans le même contexte que décrire, mais est censé être plus rigoureux et plus précis. Il ressemble beaucoup à définir Tracer (trace) Ce terme est utilisé pour indiquer qu une correspondance informelle est exigée entre deux entités avec seulement un niveau de rigueur minimal Vérifier (check) Ce terme a une signification similaire à confirmer (confirm) ou contrôler (verify), mais il se veut moins rigoureux. Ce terme requiert qu une décision rapide soit prise par l évaluateur, exigeant seulement une analyse superficielle ou peut-être même aucune analyse 110 / 123

111 5.3 Classes de Transactions et Transactions Les classes de Transactions regroupent des Transactions de niveaux de besoin de sécurité voisins. Le tableau cidessous présentent les classes de Transaction identifiées et les caractérise : Classes de Transactions Code Niveau de Commentaires besoin Transactions avec flux FLUXFIN Haut Les Transactions où le flux financier est soumis à une financier condition ne sont pas distinguées des autres (exemple : vendre tel montant du titre T dès que sa côte passe en dessous du seuil S). En effet, dans les deux cas, les exigences de conservation de l'ordre sont analogues. Ces Transactions présentent : un besoin en confidentialité fort (anonymat donneur d'ordre, montants en jeu, aspect "anticipation" sur la tendance du marché) ; un besoin en intégrité fort (montants en jeu) ; un besoin en traçabilité fort (montants en jeu). Transactions modifiant la relation contractuelle Transactions avec commande d'un Bien matériel Transactions avec mise en place d'un flux d'information Transactions de consultation d'informations privées CONTRAT Moyen Il s'agit par exemple de la demande d'ouverture de compte, de la mise en opposition d'une carte bancaire. Ces Transactions présentent : un besoin en confidentialité fort (respect vie privée, anonymat) ; un besoin en intégrité moyen (une erreur est repérable et corrigeable) ; un besoin en traçabilité fort (cas des conflits avec le client). BIENMAT Moyen Il s'agit par exemple de la demande de chéquier. Ces Transactions présentent : un besoin en confidentialité moyen ; un besoin en intégrité moyen ; un besoin en traçabilité moyen. INFORM Faible Il s'agit par exemple de simulations ou de mises en place d'alerte sur franchissement de seuil. Ces Transactions présentent : un besoin en confidentialité moyen (certains flux peuvent être personnalisés) ; un besoin en intégrité moyen ; Un besoin en traçabilité faible. CONSULT Faible Il s'agit par exemple de la consultation de solde. Ces Transactions présentent : Un besoin en confidentialité fort ; Un besoin en intégrité moyen ; un besoin en traçabilité faible. La consultation d'informations publiques n'est pas considérée comme une Transaction. 111 / 123

112 Le tableau suivant récapitule les Transactions identifiées, présentées suivant la classe associée : Nature Code classe Transaction Bancaire Financièr e FLUXFIN Demande de transfert de compte titres Ordre de virement de compte à compte Ordre de transfert de titres Passation d un ordre d achat ou de vente d instrument financier Modification des caractéristiques d un ordre d achat ou de vente d instrument financier Suppression d un ordre d achat ou de vente en vie Création d un ordre d apport à une offre publique Révocation d un ordre d apport à une offre publique Réservation de titres à l occasion d une introduction en Bourse Suppression d une réservation de titres pour une introduction Saisie, modification, suppression d une instruction relative à la livraison du sous-jacent d un produit dérivé Prorogation de position issue d ordres avec SRD Souscription de parts d OPCVM Cession de parts OPCVM Virement : de compte à compte ; sur liste (ordres individuels) ; sur liste (ordres groupés) ; exceptionnels. Émission d'avis de prélèvement : sur liste prédéterminée ; autrement. Utilisation et remboursement de la réserve de crédit Saisie des effets (au crédit d'un compte) : à partir d'une liste de tirés prédéterminée ; autrement. Saisie des décisions de paiement sur les LCR se présentant sur le compte du client (au débit du compte) 112 / 123

113 Nature Code classe Transaction Bancaire Financièr e CONTRAT Déclenchement procédure ouverture de compte Déclenchement procédure clôture de compte Souscription d'un abonnement Délégation de services 7 (implique un abonnement) Rattachement de comptes Détachement de comptes Ajout d'une option à un abonnement Suppression d'une option à un abonnement Modification du compte à débiter Mise en opposition d'une carte bancaire Mise en opposition d'un chéquier Gestion des listes de virements Gestion des listes de prélèvements Gestion de la liste des tirés (effets de commerce) BIENMAT Commande de devises Commande de chèques de voyage Commande de chéquier Commande d'un carnet de remises de chèques Commande d'un carnet de RIB INFORM Formation en ligne Exercices d évaluation de connaissance en ligne Gestion de portefeuille virtuel (simulation) Mise en place par l utilisateur d une alerte liée à la passation d ordres de bourse spécifiques Mise en place par l utilisateur d une alerte sur franchissement de seuil pour le cours d une valeur Mise en place d une alerte sur rupture d activité (suspension ou reprise de cotation) 7 Possibilité pour un abonné de créer un accès pour une personne non abonnée. 113 / 123

114 Nature Code classe Transaction Bancaire Financièr e CONSULT Consultation des opérations sur titres en cours (concernant l'utilisateur) situation des ordres de Bourse et des OPCVM ; liste des opérations réalisées depuis le début de la liquidation ; liste des opérations réalisées lors de la liquidation précédente. Consultation de comptes titres (concernant l'utilisateur) : consultation des soldes des liquidités ; consultation des soldes instruments financiers (en nombre de titres ou de contrats) ; consultation de la valorisation des titres ; consultation des engagements, couvertures, engagements possibles (notion de "pouvoir d'investissement"). Consultation des avis d'opéré Consultation de compte bancaire : dernières opérations et suspens ; historique des opérations ; cartes à débiter ; position globale ; soldes en valeurs ; incidents de gestion (impayés subis, écritures en suspens ) ; recherche d'opérations sur un compte ; pointage d'opérations sur un compte. Consultation de virements : en attente d'exécution ; rejetés. Consultation de l'épargne Consultation des prêts en cours Consultation de la réserve de crédit Consultation d'informations relatives à la fiscalité Consultations des produits d'assurance et de leurs couvertures Consultation des effets de commerce relatifs à un compte : liste des effets (portefeuille) ; ventilation par tiré ; recherche d'effets liste des factures remises par le client dans le cadre de la loi Dailly. 114 / 123

115 5.4 Domaines de sensibilité aux risques L'EARS doit mener une analyse de risques spécifique à la TOE, ce qui inclut la détermination de la sensibilité des Biens de la TOE. Cette annexe présente la notion de "domaine de sensibilité aux risques" afin d'aider l'ears à définir la sensibilité des Biens de la TOE. Le principe des domaines de sensibilité aux risques est de regrouper les Biens ayant un niveau de sensibilité analogue, afin de leur appliquer des mesures de contrôle d'accès physiques et / ou logiques identiques. 115 / 123

116 EARS Domaine EARS public Autre domaine (hors EARS) Domaine de l'utilisateur A Domaines privés de l'ears 5 Domaine privé lié à l'utilisateur A Domaine privé lié à l'utilisateur B Autres domaines privés liés à des Utilisateurs Domaine privé spécifique de l'ears Un domaine regroupe toutes les informations relatives à l'entité concernée : - un domaine Utilisateur regroupe toutes les informations dont la protection est de la responsabilité de l'utilisateur ; - un domaine privé lié à un Utilisateur regroupe toutes les informations relatives à celui-ci et dont la protection est de la responsabilité de l'ears ; - le domaine public de l'ears regroupe toutes les informations publiques ; - le domaine privé spécifique de l'ears regroupe toutes les informations dont l'ears a besoin pour fournir un SBFI hormis celles relatives aux Utilisateurs. Les flèches ci-dessus présentent des exemples de relations entre domaines et notamment de Transactions : 1 Ne constitue pas une Transaction Transaction interne à un domaine privé lié à un Utilisateur (ex. : consultation de solde) Transaction entre deux domaines privés liés à des Utilisateurs de l'ears (ex. : virement de compte à compte) Transaction entre l'ears et l'extérieur (ex. : passation d'un ordre de bourse) 5 Une transaction peut éventuellement entraîner des échanges entre plus de deux domaines (domaine de l'utilisateur non compris) : - autre domaine privé lié à un Utilisateur ; - domaine public de l'ears ; - domaine extérieur à l'ears. Par souci de lisibilité, le schéma ne comporte aucune flèche impliquant le domaine privé spécifique de l'ears. Figure 3 : Domaines de sensibilité aux risques 116 / 123

117 5.5 Caractéristiques de sécurité de la cible d'évaluation Cette annexe présente : les caractéristiques des nouvelles architectures à prendre en compte dans les actions de protection d'un site Internet ; des bonnes pratiques de protection d'un site Internet, à voir comme des mesures ayant fait leur preuve, présentées à titre d'exemple Caractéristiques des nouvelles architectures La protection d'un site Internet doit tenir compte des caractéristiques suivantes des nouvelles architectures : deux facteurs structurants : la construction par assemblage de composants et la mutualisation des ressources ; une répartition des ressources informatiques (fichiers, bases de données, applications, imprimantes ) en différents endroits, combinée à une multiplicité des points d accès possibles ; une forte hétérogénéité des fournisseurs de composants matériels et logiciels ; une sécurité intrinsèque des produits du marché variable ; des cycles de développement de plus en plus courts (d'où le risque de faire des prototypes permanents) Bonnes pratiques de protection La protection de la TOE doit traiter quatre volets : 1. protéger les Canaux de communication liés à une Transaction ; Pour protéger correctement les Canaux de communication associés à une Transaction, il est généralement recommandé de traiter les aspects : authenticité d une Transaction : toute Transaction, créée ou modifiée de façon illicite durant son transfert, est rejetée ; confidentialité des données : la confidentialité des données transmises est garantie ; non-rejeu : il est impossible de rejouer une Transaction. 2. vérifier l'identité des parties impliquées dans une Transaction ; La vérification de l identité est un point fondamental pour la sécurité des Transactions. Sur Internet, il convient de ne pas se fier à une simple vérification d identité des parties impliquées dans la Transaction. Une authentification mutuelle (réciproque) est nécessaire. Pour assurer une authentification forte, il est recommandé d éviter le simple mot de passe. Dans le cas de mots de passe, des règles de gestion des mots de passe doivent être définies (péremption, complexité, renouvellement ) et ceux-ci ne doivent jamais circuler en clair sur un réseau public comme Internet. 3. assurer la sécurité des composants techniques employés ; Pour jouer pleinement son rôle, un Système SBFI doit traiter les aspects : disponibilité des SBFI et du Système TI qui les fournit : les SBFI sont assurés conformément aux règles d exploitation ; enregistrement des opérations : toutes les opérations effectuées sur le Système SBFI sont enregistrées de façon à permettre la traçabilité ; protection contre des intrusions internes ou externes ; protection de l intégrité et de la confidentialité des données associées aux SBFI. 117 / 123

118 Afin de traiter ces aspects, il est généralement recommandé de mettre en œuvre les principales mesures suivantes : architecture n-tiers : afin de protéger les données et applications sensibles, celles-ci sont positionnées dans une architecture à étages, sur des équipements accessibles uniquement depuis des équipements intermédiaires, eux-mêmes accessibles uniquement depuis les serveurs frontaux. confinement : afin de limiter les risques de rebond, les serveurs accessibles de l extérieur sont isolés sur des sous-réseaux (souvent appelés «zone démilitarisée» ou DMZ). La communication entre ces zones démilitarisées et avec le reste du système est contrôlée par des dispositifs de sécurité : pare-feux, routeurs filtrants ou relais inverses par exemple. L administration du Système SBFI est effectuée par un accès dédié et spécifiquement protégé ; contrôle d accès : l accès aux locaux, serveurs et données est contrôlé et tient compte du Rôle de la personne (accès physiques et logiques) ; sécurité des serveurs : les serveurs du Système SBFI utilisent des versions de système d exploitation durcies. Seuls les services du système d exploitation nécessaires au bon fonctionnement du SBFI sont installés. En particulier, tous les services réseau non utilisés sont supprimés. Il est aussi recommandé d installer des programmes pour vérifier périodiquement l intégrité des logiciels installés et pour détecter des attaques virales ; sécurité des développement : les applications développées spécifiquement pour le SBFI suivent des procédures de développement qui incluent des règles de programmation sécurisée. disponibilité d'un SBFI : les services en ligne doivent être en général disponibles 24 heures sur 24. Les défaillances technologiques ou les sabotages mais aussi les attaques venant d Internet dont l'objectif est de bloquer l accès au serveur (dénis de service) sont pris en compte. Il est possible de se protéger contre ce type de problèmes en installant des systèmes redondants et des dispositifs permettant la reprise sur incidents (fail over) ; boîtiers de sécurité : comme le Système SBFI est amené à manipuler des clés cryptographiques pour effectuer certaines opérations, il est recommandé d équiper les serveurs de dispositifs matériels indépendants et ayant en charge les opérations cryptographiques. Cela procure un bon niveau de protection contre des attaques internes mais aussi contre les pirates informatiques ; veille sécurité : la sécurité d un système d information peut subir des dégradations du fait de la découverte et de la publications de failles de sécurité par des utilisateurs internes ou externes. La diffusion des alertes de sécurité et des procédures pour mettre en place les parades sont clairement définies. Cette veille est assurée de façon durable et tient compte de la durée de service ; audit : l enregistrement de l état ou de l activité des différents serveurs dans des traces est le principal moyen de couvrir les objectifs de traçabilité de l activité et d imputabilité des actions. Les traces font l objet d une centralisation avec synchronisation horaires des différentes sources. Elles sont analysées régulièrement pour détecter les attaques ; personnel : le personnel en contact direct avec le Système SBFI satisfait à de forts critères de probité et de compétences (en se tenant notamment informé des derniers développements en matière de sécurité). En outre, l architecture du Système SBFI doit être conçue pour permettre de distinguer différents niveaux de sensibilités aux risques et de mettre en œuvre des moyens de défense adaptés. Les mesures ci-dessus doivent être pensées et mises en œuvre afin de maintenir en permanence la sécurité dans le temps. 4. protéger les Utilisateurs. L'Utilisateur souhaite utiliser Internet sans restriction mais dans la plupart des cas il n a pas connaissance des risques associés. Toutefois il reste le seul responsable de son équipement de connexion et du niveau de sécurité qu il offre. Lors de la conception d'un Système SBFI il est recommandé que : le système soit le plus simple possible pour l Utilisateur. Toute solution qui nécessite l intervention d un tiers doit être rejetée ; toutes les Transactions restent sous le contrôle de l Utilisateur et que des preuves soient enregistrées ; 118 / 123

119 le système soit conçu pour assurer une bonne protection des données associées à l Utilisateur lors de leur transmission, de leur manipulation et de leur stockage. Les informations relatives à l Utilisateur ne sont transmises que si elles sont strictement nécessaires à la réalisation de la Transaction. De manière générale, il est recommandé que les dispositifs logiciels et matériels mis à la disposition de l Utilisateur satisfassent plusieurs exigences de sécurité : ils ne peuvent pas être utilisés sans le consentement de l Utilisateur. Ce consentement peut prendre la forme d un mot de passe, d une caractéristique personnelle (biométrie) ou encore d une carte à puce ; il est extrêmement difficile de modifier les données liées à une Transaction au moyen d un programme malicieux (virus, cheval de Troie ). En particulier, il doit être impossible que des logiciels chargés de manière licite ou illicite à partir d Internet modifient les Transactions sans que l Utilisateur en soit averti ; pour limiter les conséquences d une défaillance du système, celui-ci prévoit un moyen simple pour restaurer les données associées ; les informations sensibles comme les clés cryptographiques et les mots de passe sont conservées de manière sûre afin que seules les personnes autorisées puissent les utiliser ; pendant la Transaction, l intégrité des données échangées doit être assurée ; toutes les Transactions sont imputées afin d'assurer leur traçabilité. Il est donc recommandé que les solutions proposées aux Utilisateurs par les fournisseurs de SBFI satisfassent les mesures suivantes : pertinence : pour les solutions logicielles, l Utilisateur respecte un nombre important de procédures de sécurité (installation, configuration ) ; qualité : le niveau de sécurité de la solution fournie est vérifié par un organisme indépendant. Il est recommandé que le niveau de qualité du produit soit visible par l Utilisateur (labellisation) qui a ainsi l assurance que le produit a un niveau de sécurité suffisant et a été correctement testé ; ergonomie : un Système SBFI doit présenter une interface ergonomique pour l Utilisateur. De plus, il est recommandé d'informer l'utilisateur : des règles nécessaires à l installation et au fonctionnement de la solution logicielle et / ou matérielle qui lui est fournie ou mise à disposition. Par exemple : les règles de sauvegarde des données, à faire régulièrement ; les règles de stockage des clés d accès au SBFI (mots de passe, codes confidentiels ou encore les cartes à puce). Lorsqu il s agit de biens immatériels, il est recommandé d'éviter de les conserver sur l'équipement dans la mesure du possible. des précautions et conseils permettant d améliorer la sécurité, comme par exemple protéger son équipement de connexion contre des attaques virales, ne pas charger de programmes d origine inconnue ou de type suspect sans s assurer de son origine, etc. 8 Il est recommandé que les règles, précautions et conseils soient clairs, simples et raisonnables (proportionnés au risque et à l assurance sur le risque), de manière que l Utilisateur ne soit pas dissuadé de les suivre en pratique (ce qui aurait pour effet de les invalider). 8 On pourra utiliser notamment le CD-ROM "Les risques cachés d Internet" réalisé par le CFONB avec la collaboration de la DCSSI. 119 / 123

120 5.6 Maintenance de l'assurance Une évaluation certification donne l'assurance que la sécurité est celle attendue à un instant donné. Or la sécurité est un challenge permanent. Dans le cas de la certification d'une TOE selon les Critères Communs, il est donc intéressant de faire vivre le certificat obtenu. C'est le principe de maintenance de l'assurance, appelé également maintenance du certificat. La présente annexe comporte les composants d'assurance qu'il est recommandé de prendre en compte dans le cas de la certification d'une TOE. Les composants relatifs à la maintenance de l'assurance figurent en annexe car : quand on les retient, cela signifie que le certificat n'est délivré qu'après un cycle complet de maintenance. Un établissement qui s'engage dans la certification d'une TOE a donc la liberté dans sa cible de sécurité d'inclure les composants d'assurance, mais n'y est pas obligé ; en dehors de toute volonté de certification selon les Critères Communs ou de maintenance du certificat associé, les composants d'assurance mettent en exergue des aspects importants de la sécurité Famille Plan de maintenance de l assurance [AMA_AMP] Plan de maintenance de l assurance [AMA_AMP.1] Tâches du développeur : Le développeur doit fournir un plan Assurance Management (AM) [AMA_AMP.1.1D] Contenu et présentation des éléments de preuve : Le plan AM doit contenir une brève description de la TOE, incluant les fonctionnalités de sécurité qu elle offre, ou y faire référence [AMA_AMP.1.1C] Le plan AM doit identifier la version certifiée de la TOE et doit faire référence aux résultats d évaluation [AMA_AMP.1.2C] Le plan AM doit faire référence au rapport de classification des composants de la TOE pour la version certifiée de la TOE [AMA_AMP.1.3C] Le plan AM doit définir le domaine d application des changements de la TOE qu il couvre [AMA_AMP.1.4C] Le plan AM doit décrire le cycle de vie de la TOE et doit identifier les prévisions de toute nouvelle version de la TOE, ainsi qu une brève description de tous les changements planifiés qui auront vraisemblablement un impact significatif sur la sécurité [AMA_AMP.1.5C] Le plan AM doit décrire le cycle de maintenance de l assurance, en établissant et en justifiant le planning prévisionnel des audits AM et la date prévue pour la prochaine réévaluation de la TOE [AMA_AMP.1.6C] Le plan AM doit identifier le ou les individus qui assureront le rôle d analyste de sécurité du développeur pour la TOE [AMA_AMP.1.7C] Le plan AM doit décrire comment le rôle d analyste de sécurité du développeur garantira que les procédures documentées ou référencées dans le plan AM sont suivies [AMA_AMP.1.8C] Le plan AM doit décrire comment le rôle d analyste de sécurité du développeur garantira que toutes les Tâches du développeur liées à l analyse d impact sur la sécurité des changements affectant la TOE sont réalisées correctement [AMA_AMP.1.9C] Le plan AM doit justifier pourquoi le ou les analyste(s) de sécurité du développeur sont considérés comme étant suffisamment familiarisés avec la cible de sécurité, les spécifications fonctionnelles et (lorsque cela est approprié) la conception de haut niveau de la TOE, ainsi qu avec les résultats d évaluation et toutes les exigences d assurance applicables pour la version certifiée de la TOE [AMA_AMP.1.10C] 120 / 123

121 Le plan AM doit décrire les procédures qui doivent être appliquées pour maintenir l assurance de la TOE ou y faire référence, ce qui doit inclure au minimum les procédures de gestion de configuration, les éléments de preuve relatifs à la maintenance de l assurance, la réalisation de l analyse d impact sur la sécurité des changements opérés sur la TOE et la correction d anomalies [AMA_AMP.1.11C] Tâches de l'évaluateur : L évaluateur doit confirmer que les informations fournies satisfont à toutes les exigences relatives au contenu et à la présentation des éléments de preuve [AMA_AMP.1.1E] L évaluateur doit confirmer que les plannings proposés pour les audits AM et la réévaluation de la TOE sont acceptables et cohérents vis-à-vis des changements proposés dans la TOE [AMA_AMP.1.2E] Famille Rapport de classification des composants de la TOE [AMA_CAT.1] Rapport de classification des composants de la TOE [AMA_CAT.1] Tâches du développeur : Le développeur doit fournir un rapport de classification des composants de la TOE pour la version certifiée de la TOE [AMA_CAT.1.1D] Contenu et présentation des éléments de preuve : Le rapport de classification des composants de la TOE doit classer chaque composant de la TOE identifiable dans chaque représentation de la TSF, de la plus abstraite jusqu à la moins abstraite, en fonction de sa pertinence vis-à-vis de la sécurité ; au minimum, les composants de la TOE doivent être classés, soit comme étant dédiés à l application de la TSP, soit comme étant non dédié à l application de la TSP [AMA_CAT.1.1C] Le rapport de classification des composants de la TOE doit décrire le schéma de classification utilisé, de telle sorte que l on puisse déterminer comment classer de nouveaux composants introduits dans la TOE, et également à quel moment modifier le classement des composants qui existent déjà dans la TOE à la suite de changements apportés à celle-ci ou à sa cible de sécurité [AMA_CAT.1.2C] Le rapport de classification des composants de la TOE doit identifier tous les outils utilisés dans l environnement de développement qui, s ils sont modifiés, auront un impact sur l assurance dans le fait que la TOE satisfait à sa cible de sécurité [AMA_CAT.1.3C] Tâches de l'évaluateur : L évaluateur doit confirmer que les informations fournies satisfont à toutes les exigences relatives au contenu et à la présentation des éléments de preuve [AMA_CAT.1.1E] L évaluateur doit confirmer que la classification des composants de la TOE et des outils, ainsi que le schéma de classification utilisé, sont appropriés et cohérents avec les résultats d évaluation de la version certifiée [AMA_CAT.1.2E] Famille Preuve de la maintenance de l assurance [AMA_EVD] Éléments de preuve du processus de maintenance [AMA_EVD.1] Tâches du développeur : L analyste de sécurité du développeur doit fournir une documentation AM pour la version courante de la TOE [AMA_EVD.1.1D] Contenu et présentation des éléments de preuve : La documentation AM doit inclure une liste de configuration et une liste des vulnérabilités identifiées de la TOE [AMA_EVD.1.1C] La liste de configuration doit décrire les éléments de configuration incluant la version courante de la TOE [AMA_EVD.1.2C] La documentation AM doit fournir la preuve que les procédures documentées ou référencées dans le plan AM sont appliquées [AMA_EVD.1.3C] La liste des vulnérabilités identifiées dans la version courante de la TOE doit montrer, pour chaque vulnérabilité, qu elle ne peut pas être exploitée dans l environnement prévu de la TOE [AMA_EVD.1.4C] 121 / 123

122 Tâches de l'évaluateur : L évaluateur doit confirmer que les informations fournies satisfont à toutes les exigences relatives au contenu et à la présentation des éléments de preuve [AMA_EVD.1.1E] L évaluateur doit confirmer que les procédures documentées ou référencées dans le plan AM sont appliquées [AMA_EVD.1.2E] L évaluateur doit confirmer que l analyse d impact sur la sécurité pour la version courante de la TOE est cohérente avec la liste de configuration [AMA_EVD.1.3E] L évaluateur doit confirmer que tous les changements documentés dans l analyse d impact sur la sécurité pour la version courante de la TOE s inscrivent dans le domaine d application couvert par le plan AM [AMA_EVD.1.4E] L évaluateur doit confirmer que les tests fonctionnels ont été exécutés sur la version courante de la TOE, avec une profondeur homogène avec le niveau d assurance maintenu [AMA_EVD.1.5E] Famille Analyse d impact sur la sécurité [AMA_SIA] Échantillonnage de l analyse d impact sur la sécurité [AMA_SIA.1] Tâches du développeur : L analyste de sécurité du développeur doit, pour la version courante de la TOE, fournir une analyse d impact sur la sécurité qui couvre tous les changements effectués par rapport à la version certifiée de la TOE [AMA_SIA.1.1D] Contenu et présentation des éléments de preuve : L analyse d impact sur la sécurité doit identifier la version certifiée de la TOE à partir de laquelle a été constituée la version courante de la TOE [AMA_SIA.1.1C] L analyse d impact sur la sécurité doit identifier tout composant nouveau ou modifié de la TOE, classé comme étant dédié à l application de la TSP [AMA_SIA.1.2C] L analyse d impact sur la sécurité doit, pour tout changement concernant la cible de sécurité ou les représentations de la TSF, décrire brièvement ce changement et tous les effets qu il peut avoir sur les niveaux de représentation moins abstraits [AMA_SIA.1.3C] L analyse d impact sur la sécurité doit, pour tout changement concernant la cible de sécurité ou les représentations de la TSF, identifier toutes les fonctions de sécurité TI et tous les composants de la TOE classés comme étant dédiés à l application de la TSP, qui sont concernés par ce changement [AMA_SIA.1.4C] L analyse d impact sur la sécurité doit, pour tout changement qui implique une modification de la représentation de l implémentation de la TSF ou de l environnement TI, identifier les éléments de preuve relatifs à des tests qui montrent, au niveau d assurance requis, que la TSF continue à être correctement implémentée à la suite de ce changement [AMA_SIA.1.5C] L analyse d impact sur la sécurité doit, pour chaque exigence d assurance applicable dans les classes d assurance gestion de configuration (ACM), support au cycle de vie (ALC), livraison et exploitation (ADO) et guides (AGD), identifier toutes les fournitures d évaluation qui ont changé et fournir une brève description de chaque changement et de son impact sur l assurance [AMA_SIA.1.6C] L analyse d impact sur la sécurité doit, pour chaque exigence d assurance applicable dans la classe d assurance estimation des vulnérabilités (AVA), identifier les fournitures d évaluation qui ont changé et celles qui n ont pas changé, et justifier des décisions concernant la mise à jour ou non de la fourniture [AMA_SIA.1.7C] Tâches de l'évaluateur : L évaluateur doit confirmer que les informations fournies satisfont à toutes les exigences relatives au contenu et à la présentation des éléments de preuve [AMA_SIA.1.1E] L évaluateur doit vérifier, par échantillonnage, que l analyse d impact sur la sécurité documente les modifications à un niveau de détail approprié, avec les justifications appropriées qui montrent que l assurance a été maintenue dans la version courante de la TOE [AMA_SIA.1.2E] 122 / 123

123 5.7 Liste des participants du groupe de travail "Profil de protection" Par ordre alphabétique : NOM ETABLISSEMENT ANGER Aïcha LA POSTE [email protected] BLEICHER Jean-Louis BANQUE FEDERALE DES BANQUES POPULAIRES [email protected] BOUTHIER Eric SOCIETE GENERALE [email protected] BROSSIER Christian BANQUE FEDERALE DES BANQUES POPULAIRES [email protected] BRUGUIER Patrick BANQUE DE FRANCE [email protected] CHALIER René BANQUE FEDERALE DES BANQUES POPULAIRES CATHALO Emmanuel TELINDUS - CF [email protected] [email protected] CORNILLAUT Jean-Pierre CMF [email protected] DESLANDES Jérôme BANQUE DE FRANCE [email protected] ELIOT Romain SOCIETE GENERALE [email protected] FAURE Alain BNP PARIBAS [email protected] HERVOIR Olivier BNP PARIBAS [email protected] ISNARD Jean Euronext Paris S.A [email protected] KRIN Joël BANQUE DE FRANCE [email protected] LABOURET Ghislaine BANQUE DE FRANCE [email protected] LETOUQ Martial Crédit Agricole SA [email protected] MARTIN Carlos BANQUE DE FRANCE [email protected] MESSAUT Xavier Crédit Agricole SA [email protected] MOSCOVITCH Marc TELINDUS - CF [email protected] NOEL Siegfried TELINDUS - CF [email protected] RITZ Christian BNP PARIBAS [email protected] SINTUREL Henri Secrétariat Général de la Commission Bancaire [email protected] SPILEERS Denis BNP PARIBAS [email protected] SULPICE Jean Caisse des Dépôts et Consignations [email protected] VERGNOLLE Vincent BANQUE DE FRANCE [email protected] VIELPEAU Alain CREDIT LYONNAIS [email protected] WATTIEZ Georges SOCIETE GENERALE [email protected] 123 / 123