La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Guide de mise en œuvre de la méthode – Introduction

Présentations similaires


Présentation au sujet: "Guide de mise en œuvre de la méthode – Introduction"— Transcription de la présentation:

1 Guide de mise en œuvre de la méthode – Introduction
Déclinaison du Cadre Interopérabilité Sécurité dans le domaine de la Santé Guide de mise en œuvre de la méthode – Introduction

2 Sommaire du Guide 0. Introduction I. La méthode
II. Dérouler la méthode (Partie Guide) II.1 Utiliser Nuxeo en l’état II.2 Créer de nouvelles bases de règles à partir de nouveaux référentiels Nom du document

3 0. Introduction 0.1 Le GMSIH 0.2 La démarche d’analyse des référentiels 0.2 Les référentiels 0.3 Pourquoi une méthode d’analyse 0.4 Quelques définitions Sécurité Interopérabilité Nom du document

4 0.1 Introduction / Le GMSIH (1)
La mission du Groupement pour la Modernisation du Système d’Information Hospitalier (GMSIH) est définie par l’article 2 de l’arrêté ministériel du 23 février 2000 a été étendue par la Loi de financement de la Sécurité Sociale (LFSS) de 2006 Dans le cadre général de la construction du SIS, le GMSIH est chargé de concourir à la mise en cohérence, à l'interopérabilité, à l'ouverture et à la sécurité des SI utilisés par les établissements de santé (ES), ainsi qu'à l'échange d'informations dans les réseaux de soins entre la médecine de ville, les ES et le secteur médico-social , afin d'améliorer la coordination des soins ES établissements de santé SI : Système d’Information 202 / Guide de Mise en Œuvre METHODE

5 0.1 Introduction / Le GMSIH (2)
Comme contributeur à l’interopérabilité, le GMSIH prend en compte la normalisation dans ses études et dans ses travaux sur les échanges électroniques d’information La DGME et le SGDN ont défini les référentiels généraux d’interopérabilité et de sécurité (RGI/RGS) (ordonnance n° du 8 décembre 2005) Courant 2007, le GMSIH a lancé un projet de déclinaison de ces référentiels pour les établissements de santé et les réseaux de santé, 202 / Guide de Mise en Œuvre METHODE

6 0.1 Introduction / Le GMSIH (3)
Courant 2008, le GMSIH a prolongé le projet de 2007 avec les objectifs suivants poursuivre les travaux entrepris en 2007, en appliquant la méthode définie alors pour élaborer des référentiels de sécurité susceptibles d’être appliqués par les ES et les réseaux de santé valider définitivement la méthode tout en l’affinant par sa mise en pratique sur un cas concret et réaliste 202 / Guide de Mise en Œuvre METHODE

7 0.2 Introduction / La démarche d’analyse / Sommaire
La méthode d’analyse des référentiels Pourquoi des référentiels Pourquoi une méthode d’analyse Les objectifs de la méthode 202 / Guide de Mise en Œuvre METHODE

8 0.2 Introduction / Les référentiels dans le domaine de la santé (1)
Les référentiels répondent au besoin de cohérence entre les enjeux métier L’accroissement de la complexité de l’environnement Evolution de l’organisation de santé vers le décloisonnement des pratiques médicales :  Réseaux de santé  Patients à domicile  Patients mobiles  Qualité des soins  Technicité des actes  Répartition de l’offre de soins  Vieillissement de la population  Contraintes budgétaires 202PLANGT v01

9 0.2 Introduction / Les référentiels dans le domaine de la santé (2)
Objectifs du domaine de santé Plus de communication et d’échanges entre les professionnels de santé Le patient devient partie prenante de sa prise en charge Les outils techniques deviennent plus performants ou accessibles par tous Internet Téléphone mobile Autres dispositifs de santé … 202PLANGT v01

10 0.2 Introduction / Les référentiels dans le domaine de la santé (3)
La Problématique Pour communiquer et partager entre acteurs de l’information, il est nécessaire disposer des modes d’organisation qui soient compatibles entre elles basés sur des concepts standardisés et de l’information reconnue (par tous) Pour cela, des référentiels communs ou connus apportent un cadre permettant d’assurer la convergence des points de vue l'ensemble des acteurs est en phase sur la nécessité d'une gouvernance claire basée sur des "recommandations fortes" compatibles à la fois avec les besoins et avec l'environnement règlementaire et technique, tout en recherchant la plus grande cohérence possible avec l'international. Le domaine concerné (eSanté) est à la croisée de nombreux domaines (eAdministration, biomédical, IT, social...) et le nombre de recommandations à prendre en compte sans cesse croissant. L'idée est donc de développer et d’évaluer une méthode permettant d'élaborer une recommandation adaptée à un sujet ("référentiel" adapté à un "domaine d'application") à partir de recommandations existantes. 202PLANGT v01

11 0.2 Introduction / Les référentiels dans le domaine de la santé (4)
Définition d’un référentiel Selon le niveau d’abstraction défini en urbanisation, il existe de nombreuses définitions Les quatre niveaux d’abstraction sont Métier Système fonctionnel Système applicatif Technique Taxinomie ( taxi qui vient du grec taxis signifiant "mise en ordre", à l’origine utilisée pour le classement des espèces animales ou végétales) » Définitions des niveaux d’abstraction (cf. Note de cadrage méthodologique) : Métier (objets et processus métier) : par exemple, stratégie d’établissement, objectifs métier, concepts de culture d’établissement, processus, organisation, besoins de conduite du changement ; Système / fonctionnel, par exemple par ajout de fonctions, qui peuvent se retrouver en contradiction avec des fonctions existantes ; Système / architecture applicative : organisation du système en applications, modules transverses, sous-modules, etc. ; Technique (Implémentation logique ou physique) : impacts techniques de mise en œuvre de la règle sur les architectures système d’information, les applications et les systèmes, besoin d’interopérabilité des systèmes et des technologies, d’urbanisation des systèmes, degré de modularité, niveau d’adaptabilité des techniques employées, niveau de sécurité attendu ; 202PLANGT v01

12 0.2 Introduction / Les référentiels dans le domaine de la santé (4)
Exemples de description sur les 4 niveaux d’abstraction Niveau métier (Pourquoi) Cas d’utilisation du processus de prescription médicamenteuse, carte d’environnement (des acteurs), diagramme de processus, diagramme de fonctions, dictionnaire de données (métier) Niveau fonctionnel (Quoi) fonction de prescription dans un système d’information (prescription, validation, préparation, délivrance, gestion des stocks, gestion des informations …) avec un modèle conceptuel de données Niveau architecture (Comment) Architecture applicative, modèle logique de données, dictionnaire de données (système), interfaces, messages, infrastructure (poste, serveur) supportant l’application Niveau technique (Avec quoi) modèle de données physiques, SGBD, transactions Définition Dictionnaire : référentiel simple dont la composition s’appuie sur la description d’un élément accompagné a minima d’un identifiant(généralement univoque) ou code et d’un libellé ou intitulé (GMSIH) Catalogue normalisé qui inventorie et définit les éléments de données d'un système d'information (SIG) 202 / Guide de Mise en Œuvre METHODE

13 0.2 Introduction / Les référentiels dans le domaine de la santé (5)
Définition d’un référentiel (niveau métier) «Un référentiel regroupe un ensemble de règles , élaborées selon une méthode visant le consensus, et considérées comme nécessaires et suffisantes pour atteindre un objectif donné (sécurité, interopérabilité...) pour un domaine d’application défini Ces règles doivent être différenciées et classées selon leurs origines (référentiels existants) et les préoccupations (interopérabilité, sécurité, etc.) auxquelles elles répondent Le référentiel qui les récapitule reprend donc dans sa structure, les critères de différenciation et de classement retenus comme pertinents pour le domaine d’application considéré : Ces critères représentent la taxinomie intrinsèque au référentiel et à son domaine d’application » Un référentiel regroupe un ensemble de règles considérées comme consensuelles, pour un domaine d’application donné Un référentiel regroupe un ensemble de règles nécessaires et suffisantes pour atteindre un objectif donné (sécurité, interopérabilité...) dans un domaine d'application Note : la méthode est "consensuelle" mais la définition de la règle peut ne pas l’être 202PLANGT v01

14 0.2 Introduction / Les référentiels dans le domaine de la santé (6)
Exemples de référentiels Le Code de la Santé Publique (CSP) Le RGI Référentiel Général d’Interopérabilité de la DGME composé de trois volets Sémantique Organisationnel Technique Le RGS Référentiel Général de Sécurité orienté authentification et confidentialité Référentiel d’homologation des Outils de Sécurisation de Messagerie : OSM Les normes et standards DICOM Les profils IHE … 202PLANGT v01

15 0.2 Introduction / Les référentiels dans le domaine de la santé (7)
Définition au niveau architecture du SI Ensemble d’informations cohérentes qui s’imposent à toutes les applications du Système d’Information qui en ont besoin Le Référentiel est une composante logique qui permet de gérer ces informations, de garantir leur qualité, leur cohérence, leur unicité … Il représente ainsi la source de «confiance» concernant ces informations Exemples  Référentiel Produits, Référentiel Clients, … 202PLANGT v01

16 0.2 Introduction / Les référentiels dans le domaine de la santé (8)
Notion de règle Les règles métier sont des déclarations structurées de haut niveau, permettant de contraindre, contrôler et influencer un aspect du métier. Une règle est composée de deux parties une condition (aussi appelée fait) et une action (aussi appelée conséquence ou inférence) Quand la condition est remplie, l’action est exécutée Un exemple de construction d’une règle est proposé par la suite dans ce document 202 / Guide de Mise en Œuvre METHODE

17 0.2 Introduction / Les référentiels dans le domaine de la santé (9)
Dans la santé Il existe de nombreux référentiels et cadres d’interopérabilité généralement construits pour répondre à un besoin particulier, pour un domaine ou champ d’application (établissements de santé, plateformes de service de santé, DMP, Assurance Maladie, …) Le système d’information de santé ne se conçoit plus en îlots mais comme une architecture globalement cohérente de modules C’est pourquoi il est nécessaire de définir une organisation pour faire converger les cadres appliqués aux différents champs d’application, et qu’elle soit supportée par des méthodes 202PLANGT v01

18 0.2 Introduction / Les référentiels dans le domaine de la santé (10)
Pré-requis à la définition de référentiels Mettre en place des forums permettant des échanges et assurant le consensus dans le choix des référentiels et de leur pertinence Définir ou connaitre les processus et les architectures qui utiliseront les référentiels définis Mettre en place une expertise reconnue dans le domaine de la santé  Etablir le consensus 202PLANGT v01

19 0.2 Introduction / Besoin d’une organisation pour établir le consensus
Groupe d’experts du domaine étudié Acteurs du champ d’application Comité d’Arbitrage Critères de construction des taxinomies des architectures et des règles Décision sur le champ Validation Critères de caractérisation des référentiels Critères de caractérisation des champs d’application Analyse des règles Validation en commun « Confrontation» des règles aux besoins et sélection» des règles Validation en commun Validation finale des règles sélectionnées Présentation

20 0.3 Introduction / Etablir une méthode d’analyse (1)
Quelques recommandations Réduire la complexité S’appuyer sur les « méthodes-standards » d’urbanisation Harmoniser les référentiels en les adossant à des « taxinomies » Maintenir les taxinomies 202PLANGT v01

21 0.3 Introduction / Etablir une méthode d’analyse (2)
Réduire la complexité des référentiels par une granularité judicieuse Analyser et énoncer une règle pas trop complexe, portant sur des notions maitrisées Synthèse d’un référentiel adaptée au champ d’application Définir des notions communes à tous les référentiels S’appuyer sur les « méthodes-standards » d’urbanisation Zachman, Togaff,… 202 / Guide de Mise en Œuvre METHODE

22 0.3 Introduction / Etablir une méthode d’analyse (3)
Harmoniser les référentiels les adosser à des «taxinomies» (concepts d’architecture sous-jacents) applicables à plusieurs champs d’application avec des niveaux de granularité homogènes Procéder par étapes, sur des champs d’application connus et selon les besoins réels des partenaires (maîtrises d’ouvrage, industriels) Maintenir les taxinomies pour maîtriser leurs impacts sur la structure des référentiels par un processus concerté d’analyse et de génération des règles, entre champs d’application connexes 202 / Guide de Mise en Œuvre METHODE

23 0.3 Introduction / Etablir une méthode d’analyse (4)
Quelle méthode d’analyse ? Une structuration commune basée sur des notions ou concepts partagés Présentation

24 0.3 Introduction / Etablir une méthode d’analyse (5)
L’objectif de ce document est de Proposer une démarche permettant aux acteurs du SI de Santé de prendre des décisions d’une manière méthodique et objective sur les règles applicables à un ou plusieurs champs d’application Définir une méthode et un ensemble de critères pour 1/ Analyser les référentiels et construire une base de connaissance 2/ Argumenter et sélectionner les règles applicables à un champ d’application Dans ce cadre, l’objectif de ce guide est de présenter la démarche et les outils sur lesquels elle s’appuie, notamment les outils permettant de construire les bases de connaissance sur les référentiels. Le déroulement de la démarche sur la base des outils est décrite fait l’objet d’une seconde présentation. Nom du document

25 0.4 Introduction / Rappels de définition (1)
Les caractéristiques de sécurité Confidentialité Propriété des éléments essentiels de n'être accessibles qu'aux utilisateurs autorisés Intégrité Propriété d'exactitude et de complétude des éléments essentiels Disponibilité Propriété d'accessibilité des éléments essentiels au moment voulu par les utilisateurs autorisés Cette propriété peut aussi être exprimée sous la forme d’un niveau de service attendu dans un contrat de service (SLA) Preuve Propriété assurant que l’action d’une entité peut être attriobuée de manière unique à cette entité (ISO :1989) Les définitions sont issues du document EBIOS v2 – Section 1 – Introduction – 5 février 2004 202 / Guide de Mise en Œuvre METHODE

26 0.4 Introduction / Rappels de définition (2)
Exigence de sécurité Spécification fonctionnelle ou d'assurance sur le système d'information ou sur son environnement, portant sur les mécanismes de sécurité à mettre en œuvre et couvrant un ou plusieurs objectifs de sécurité Qualification d'un produit de sécurité Acte par lequel la DCSSI atteste de la capacité d’un produit à assurer, avec un niveau de sécurité donné, les fonctions qu’il prend en charge. Le niveau de sécurité effectivement atteint est évidemment conditionné par l’adéquation des conditions d’utilisation du produit, conditions dont l’autorité administrative fait son affaire Définitions extraites de la méthode EBIOS 202 / Guide de Mise en Œuvre METHODE

27 0.4 Introduction / Rappels de définition (3)
Interopérabilité source "European Interoperability Framework“ ability of information and communication technology (ICT) systems and of the business processes they support to exchange data and to enable the sharing of information and knowledge Capacité des systèmes des technologies de l’information et de la communication et des processus métier qu’ils supportent à échanger des données et à partager de l’information et des connaissances AFNIC Compatibilité des équipements ou des procédures permettant à plusieurs systèmes ou organismes d’agir ensemble 202 / Guide de Mise en Œuvre METHODE

28 0.4 Introduction / Rappels de définition (4)
Lien entre interopérabilité et sécurité Les normes gouvernant au plan législatif les référentiels des SI de Santé sont codifiées dans le CSP (Articles L , L ) La loi n° du 30 janvier 2007 (article 25), s'appuie sur le CSP (lois de 2002 et 2004), et a apporté cet élément nouveau consistant à associer les exigences de sécurité et d'interopérabilité "La détention et le traitement sur des supports informatiques de données de santé à caractère personnel par des professionnels de santé, des établissements de santé ou des hébergeurs de données de santé à caractère personnel, sont subordonnés à l'utilisation de systèmes d'information conformes aux prescriptions adoptées en application de l'article L (i.e. décret "Confidentialité") et répondant à des conditions d'interopérabilité arrêtées par le ministre chargé de la santé Cette loi fait apparaître le besoin de cohérence entre les deux ensembles de référentiels référentiels généraux (ex. RG* de la DGME) référentiels impliqués par les dispositions législatives et réglementaires spécifiques applicables aux S.I. du système de santé CSP : Code de la Santé Publique Au niveau réglementaire, le décret n° du 15 mai 2007 "relatif à la confidentialité des informations médicales etc.), pris en application du CSP (L ), a précisé les exigences voulues par le législateur, en disposant que : "La conservation sur support informatique des informations médicales mentionnées aux trois premiers alinéas de l'article L par tout professionnel, tout établissement et tout réseau de santé ou tout autre organisme intervenant dans le système de santé est soumise au respect de référentiels définis par arrêtés du ministre chargé de la santé, pris après avis de la Commission nationale de l'informatique et des libertés. Ces référentiels s'imposent également à la transmission de ces informations par voie électronique entre professionnels. … Les référentiels déterminent les fonctions de sécurité nécessaires à la conservation ou à la transmission des informations médicales en cause et fixant le niveau de sécurité requis pour ces fonctions." Sur ces bases, on veillera donc à la cohérence entre les deux ensembles de référentiels (référentiels généraux prévus par l’ordonnance de 2005, et référentiels impliqués par les dispositions législatives et réglementaires spécifiques applicables aux S.I. du système de santé) en tenant compte des dispositions ou exigences particulières applicables à celui-ci. 202 / Guide de Mise en Œuvre METHODE

29 La Méthode / SOMMAIRE .1 Objectifs de la méthode
.2 Les étapes de la méthode .3 Les grands principes .4 Analyse des référentiels .5 Analyse de risque .6 Documentation de la méthode Structure du guide 202 / Guide de Mise en Œuvre METHODE

30 I.1 Objectifs de la méthode
La méthode vise à répondre aux enjeux de partage et de mutualisation des informations de santé, de mise en place d’architectures de communication de qualité entre les acteurs du système de santé dans un contexte réglementaire complexe (Arrêté confidentialité, T2A, DMP, RGS, programmes nationaux , …) Définir d’une manière unique les concepts de référence à utiliser Permettre à l’organisation de consensus (décrite précédemment) de disposer des éléments de décision sur les règles applicables à un champ d’application, établis de manière méthodique, objective et reproductible 202 / Guide de Mise en Œuvre METHODE

31 I.1 Objectifs de la méthode
Notion de concept Représentation abstraite d'un objet, d'une idée Dans le cas des référentiels et des règles Représentation des «objets» cités dans les règles Le terme «objet» est pris ici au sens «modélisation objet» Dans la règle ci-dessous, les concepts sont notés en gras ARRETE CONFIDENTIALITE §3.2.1 Le système authentifie les utilisateurs avant tout accès à des informations médicales à caractère personnel  ou à toute ressource critique 202 / Guide de Mise en Œuvre METHODE

32 I.2 Etapes de la méthode 1/ Analyser les règles des référentiels
identifier les concepts sur lesquels portent ces règles 2/ Analyser les risques sur le champ d’application identifier les concepts sensibles aux menaces 3/ Rechercher, dans les référentiels, les règles portant sur les concepts les plus sensibles 4/ Sélectionner les règles selon des critères définis (dont la confrontation coût / bénéfice) 202 / Guide de Mise en Œuvre METHODE

33 3/ Rechercher les règles portant sur le concept sensible
I.2 La Méthode / Etapes 1/ Référentiels 2/ Champ d’application Analyse des règles Analyse de risques Concepts Concepts Sensibles D’abord, l’analyse des règles d’un référentiel donné permet d’identifier les concepts cités dans les règles, ce qui permet de les caractériser. Dans un second temps, l’analyse d’un champ d’application, selon le principe d’une analyse de risque, permet d’identifier les biens sensibles, les menaces portant sur ces biens, et les impacts potentiels de ces menaces. Dans un troisième temps, on cherchera dans les règles caractérisées celles qui portent sur les mêmes concepts que les biens sensibles. Enfin, les règles issues de la troisième étape sont caractérisées par leur coût de mise en œuvre. L’estimation de ce coût peut ensuite être confrontée aux bénéfices apportées par la mise en œuvre de la règle pour le concept commun. 3/ Rechercher les règles portant sur le concept sensible 4/ Confronter le coût de mise en œuvre de la règle / Bénéfices pour le concept sensible Nom du document

34 I.3 La Méthode / Grands principes (1)
Analyse des référentiels L’analyse s’appuie sur une démarche d’urbanisation et sur les niveaux d’abstraction correspondent aux niveaux d’urbanisation des systèmes d’information Métier Système Fonctionnel Système Architecture Technique Ces niveaux ont été déduits des travaux de la méthode Zachman (diapositive suivante) Définitions des niveaux d’abstraction (cf. Note de cadrage méthodologique) : Métier (objets et processus métier) : par exemple, stratégie d’établissement, objectifs métier, concepts de culture d’établissement, processus, organisation, besoins de conduite du changement ; Système / fonctionnel, par exemple par ajout de fonctions, qui peuvent se retrouver en contradiction avec des fonctions existantes ; Système / architecture applicative : organisation du système en applications, modules transverses, sous-modules, etc. ; Technique (Implémentation logique ou physique) : impacts techniques de mise en œuvre de la règle sur les architectures système d’information, les applications et les systèmes, besoin d’interopérabilité des systèmes et des technologies, d’urbanisation des systèmes, degré de modularité, niveau d’adaptabilité des techniques employées, niveau de sécurité attendu ; Nom du document

35 I. 3 La Méthode / Grands principes (Zachman)
Nom du document

36 I.3 La Méthode / Grands principes (CONCEPTS)
Les concepts utilisés pour l’analyse des règles dans les référentiels sont «QQQOCP» QUOI : Objets sur lesquels s’appliquent les contraintes QUI : Acteurs impliqués dans la règle QUAND : Stabilité dans le temps et l’espace de la règle et du Champ d’application Où : périmètre géographique Comment : moyens et méthodes employés POURQUOI : Objectif / bénéfice de la règle + COMBIEN : Coût de mise en œuvre / Bénéfice attendu Nom du document

37 I.3 La Méthode / Grands Principes / Concepts clés
Constats Entre plusieurs référentiels, des termes différents désignent le même concept (XUA Identity Assertion, X-User Assertion) Le même terme peut désigner plusieurs concepts Au sein d’un même référentiel, selon le niveau d’abstraction (niveau d’urbanisation) de la règle, le terme employé pour désigner un même concept peut varier: Ex: le terme certificat est utilisé dans le RGS pour des concepts différents à différents niveaux Certificat, certificat serveur, cachet serveur, certificat cachet serveur D’une règle à l’autre, plusieurs termes désignent le même concept Besoin de définir un concept correspondant à un ensemble de synonymes Besoin d’organiser les concepts en chaînes selon le niveau d’abstraction Nom du document

38 I.3 La Méthode / Grands principes
Notions de Concepts-Racine Les principaux concepts identifiés portent sur Le QUOI (Identité, authentifiant, certificats, etc.) Le QUI (Patient, PS, Etablissement) Il est nécessaire d’identifier les concepts-clés, abstraction de concepts similaires Le QUOI : Identité, Identifiant, Identifiant numérique … Le QUI : Organisation, Personne (Métier), Acteur (Système) Les concepts-clés sont structurés en chaînes de concepts sur les 4 niveaux d’abstraction, dont le concept-racine est de niveau Métier 202 / Guide de Mise en Œuvre METHODE

39 I.3 La Méthode / Grands principes/ Exemple de chaînes de concepts
Fichier des Chaînes de concepts I.3 La Méthode / Grands principes/ Exemple de chaînes de concepts Organisation Réglementation Métier Fonction Equipe Garantie d’Id. Personne Accès Information Procédure de face à face Identité Habilitation Rôle Autorisation Système d’Information Identification Acteur Système / Fonctionnel Authentification Id. numérique Authentifiant Profil Système / Architecture Identifiant Attestation Contrôle d’Accès Contrôle de profil Certificat électronique Ressources informatiques Droit d’accès Pièce d’Identité Mécanismes d’authentification Ex. Access List Données Identifiant unique et exclusif Mot de Passe Identité numérique Certificat Système Caractéristique biométrique Assertion Technique Autres Mécanismes d’authentification Nom du document

40 I.3 La Méthode / Concepts clés et Synonymes
Un concept-clé peut avoir plusieurs synonymes Exemple : Information CSP Informations nécessaires Information concernant la personne informations concernant la santé [de la personne] informations relatives à une même personne prise en charge Arrêté confidentialité informations médicales informations à caractère médical  informations  médicales  à  caractère  personnel   Dossier médical ²202 / Guide de Mise en Œuvre / METHODE

41 I.3 La Méthode / Grands principes / Scenario global
Référentiels Champ d’application Critères Qualité des règles Analyse de risques Analyse Zach N Niveaux d’abstraction à considérer Concepts de chaque niveau d’abstraction Objets (QUOI) Biens Sensibles QUI Vulnérabilités QUAND COMMENT L’Analyse des règles du référentiel passe par un ensemble de filtres successifs D’abord le filtre des critères qualité des règles (atomicité, dépendance, etc.) Puis, l’identification des concepts, selon les principes de Zachman, qui sont ensuite classés selon chaque niveau d’abstraction considéré, ce qui permet de positionner la règle / le référentiel par rapport à l’échelle des niveaux d’abstraction. Attention, certains concepts peuvent se situer sur plusieurs niveaux à la fois. Cette première phase d’identification permet d’estimer le coût de mise en œuvre de la règle. Dans un second temps, une analyse des risques portant sur le champ d’application visé est effectuée, selon les principes de la méthode EBIOS. Cette analyse de risques permet d’identifier les biens sensibles, que l’on rapprochera des concepts QUOI, QUI, et COMMENT, et pour lesquels seront déterminés les menaces, et les impacts de ces menaces. Plus qu’aux aspects purement liés aux caractéristiques de disponibilité, intégrité , et confidentialité, il est important de quantifier ces impacts sur les aspects métier, comme la qualité des soins, les responsabilités juridiques, l’image de l’organisation (établissement), et les impacts financiers relatifs à ces aspects. L’estimation de ces impacts permet de vérifier l’équilibre entre le coût de mise en œuvre de la mesure, d’une part, et de l’autre, le bénéfice attendu de cette mise en œuvre sur les aspects métier. C’est cette confrontation qui permet, avec d’autres critères, de disposer des arguments de décision sur la mise en œuvre de la règle, comme contre-mesure sur un risque donné. * Sensibilité menaces COMBIEN COMBIEN & POURQUOI Critères (COMBIEN, POURQUOI, QUAND, Où) Probabilité * Impact Bénéfices (POURQUOI) Risques Coûts Confrontation Coûts vs Risques Objectifs et contre-mesures 202_CR_CP_

42 I.4 La Méthode / Analyse des référentiels
Critères Qualité des règles Analyse Zach N Concepts de chaque niveau d’abstraction Objets (QUOI) QUI COMMENT Les planches qui suivent précisent les étapes de la première branche de l’analyse, qui porte sur les référentiels à étudier. COMBIEN Bénéfices (POURQUOI) Coûts Nom du document

43 I.4 La Méthode / Les référentiels analysés (1/2)
Choix des référentiels Réglementaires français DGME : Référentiel Général de Sécurité / d’Interopérabilité (RGS / RGI) Ministère de la Santé CSP Arrêté Confidentialité Décret Hébergeur CNIL Autres réglementaires HIPAA Cette liste de référentiels correspond à un état des lieux de la base documentaire actuellement analysée. En cas d’ajout de nouveaux textes dans la base, il est nécessaire de mettre à jour cette liste Nom du document

44 I.4 La Méthode / Les référentiels analysés (2/2)
Référentiels Normatifs Généraux ISO 27799 Métier GIP CPS : Référentiel d’Homologation des Outils de Sécurisation de Messagerie (OSM) IHE : XUA, ATNA, DSG DICOM – Security Nom du document

45 I.4 La Méthode / Analyse des référentiels
L’analyse des référentiels passent par plusieurs étapes .1 Le classement du référentiel dans sa globalité selon Le(s) niveau(x) d’abstraction concerné(s) Le degré de généricité / degré d’adaptation au métier de la santé .2 L’analyse qualité des règles Principes du Business Rules Group .3 L’identification des concepts selon les travaux de Zachman .4 L’estimation du coût des règles .5 Résultats de l’Analyse du Référentiel 202 / Guide de Mise en Œuvre METHODE

46 I.4.1 La Méthode / Les référentiels étudiés
Générique Métier ISO 27799 CSP/ Arrêté Confidentialité RGS HIPAA Métier Etude sécurité (GMSIH) Décret hébergeur RGI Réf. «Confidentialité» (GMSIH) Système Fonctionnel Ref. Homologation des OSM IHE DICOM Architectures de sécurité (GMSIH) Architecture Les référentiels étudiés ont été classés en fonction des niveaux d’abstraction adressés par les règles qu’ils contiennent De leur niveau de généricité (orientation métier de la santé, ou référentiel généraliste) Le référentiel d’homologation du GMSIH est en fait relativement générique (reprend la norme S/MIME), mais inclut un élément purement domaine de santé, qui est la clé de confidentialité partagée, ce qui lui donne une position à part par rapport aux autres référentiels issus du domaine de la santé. Technique 46

47 I.4.2 La Méthode / Critères qualité des règles
Qualifier les règles contenues dans le référentiel en utilisant les critères qualité définis par le Business Rules Group Atomicité Déclarative Contrainte plutôt que permission Exprimée en langage naturel Traçable Structurée Nom du document

48 I.4.2 La Méthode / Critères qualité des règles
Atomicité Une règle ne peut être subdivisée, ou décomposée dans une version plus simple sans perte d’information Déclarative Décrire les buts de la logique métier à atteindre (QUOI, POURQUOI) plutôt que les actions à faire pour atteindre ces buts (COMMENT) Ex. SI A ALORS B Exprimée en langage naturel Note 1 : Sur les aspects déclaratifs, il ne faut pas perdre de vue que le COMMENT d’une règle située à un niveau d’abstraction donné (ex. métier), peut devenir le QUOI d’une autre règle situé au niveau d’abstraction inférieur (ex. architecture) Principe du boîte noire / boîte blanche Note 2 : L’emploi du langage naturel dispense de l’apprentissage préalable d’un formalisme et s’appuie sur le principe de « ce qui se conçoit bien s’énonce clairement » Nom du document

49 I.4.2 La Méthode / Critères qualité des règles
Contrainte plutôt que permission l’usage de la RFC 2119, qui fixe les conditions d’emploi des termes MUST (NOT) et SHOULD (NOT), oriente et structure l’expression des contraintes Traçable L’insertion de la règle métier dans le SI peut être tracée tout au long des étapes de construction du SI jusqu’à sa mise en œuvre Structurée Facilité de lecture et de compréhension, voire dans un objectif d’automatisation Note 1 : La RFC 2119 fixe 4 niveaux de recommandations et l’usage des termes associés : MUST / MUST NOT SHOULD / SHOULD NOT 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification. 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label Note 2 : Sur le besoin de structure de la règle, un nécessaire équilibre doit être trouvé avec l’emploi du langage naturel. Pour exemple, l’emploi des méthodes formelles ou de grammaires plus ou moins contraignantes (ex. Critères Communs) peuvent être employées mais il peut nécessiter un apprentissage préalable. Nom du document

50 I.4.3 La Méthode / Analyse Zachman
Objectif Identifier les concepts-clés ciblés par la règle Mode d’emploi Décomposer la règle pour extraire les concepts en s’ appuyant sur la principes du QQQOCCP La page suivante fournit un exemple de texte d’une règle et des concepts clés qu’elle emploie Nom du document

51 I.4.3 La Méthode / Analyse Zachman
QUOI QUI REGLE : ACTEUR réalise ACTION sur OBJET avec des MOYENS, en conformité avec REFERENCE dans telles CONDITIONS pour atteindre un OBJECTIF COMMENT COMMENT Où, QUAND POURQUOI SYSTÈME d’INFORMATION PERSONNE ARR. CONF. §3.2.1 : Le système authentifie les utilisateurs avant tout accès à des informations médicales à caractère personnel   ou à toute ressource critique Les couleurs indiquent à quel type de concept (QQQOCP) correspondent les concepts extraits de la règle de l’arrêté confidentialité ACCES INFORMATIONS MEDICALES PERSONNELLES RESSOURCE Nom du document

52 I.4.4 La Méthode / Identifier le coût d’une règle (1)
A partir des concepts identifiés dans une règle, les coûts de sa mise en œuvre (charge, délai, ressource) sont estimés L’analyse des coûts de la règle s’appuie a minima sur les concepts QUI Quels sont les acteurs ? Quelles sont les responsabilités engagées ? QUOI De quoi parle-t-on, que manipule-t-on ? COMMENT Quels sont les moyens recommandés ou imposés par la règle ? Les pages suivantes détaillent les implications des concepts en terme de coût Nom du document

53 I.4.4 La Méthode / Identifier le coût d’une règle (2/ QUI)
Coûts de l’Organisation et des moyens humains Quels sont les acteurs impliqués par la règle en direct (Administration, ES, PS, utilisateurs, patients) en indirect (IGC, atelier de perso) Identification des Responsabilités Pour les acteurs impliqués Pour d’éventuels autres membres de l’organisation Liées à la sécurité et aux aspects fonctionnels Charge en ressources humaines Nécessité de création de poste (Ex. officier de sécurité) Charge de pilotage, d’exploitation et de surveillance Conduite du changement : communication et Formation des utilisateurs 202 / Guide de Mise en Œuvre METHODE

54 I.4.4 La Méthode / Identifier le coût d’une règle (3/ QUOI)
La sensibilité des objets cités dans la règle peut amener à mettre en œuvre des moyens spécifiques en fonction de leur besoin de sécurité / sûreté / qualité Le Coût de ces mécanismes de protection peut être estimé (coffre, portiers électroniques, outils, …) Les mesures spécifiques à mettre en œuvre sont identifiées pendant l’analyse de risque dont les concepts de type (QUOI) font l’objet. 202 / Guide de Mise en Œuvre METHODE

55 I.4.4 La Méthode / Identifier le coût d’une règle (4/ QUOI)
Par exemple, mettre en place Une redondance de système pour assurer la Disponibilité Du contrôle d’accès et des outils de signature pour assurer l’Intégrité Des outils de chiffrement pour assurer la Confidentialité Une qualification formelle du système pour assurer la sûreté de fonctionnement 202 / Guide de Mise en Œuvre METHODE

56 I.4.4 La Méthode / Identifier le coût d’une règle (5/COMMENT)
A partir du COMMENT identifié dans la règle, préciser les moyens nécessaires à sa mise en œuvre Pré-requis (dépendances) Types de moyens Procédures, changement de mode de fonctionnement Humains / compétences Moyens techniques (Firewall, IPS) Interaction entre les impacts de la mise en œuvre des moyens et le périmètre des moyens humains Exemple : former / équiper une équipe technique impacte un nombre limité d’acteurs (responsabilités) ce qui a un coût réduit par rapport à la formation de l’ensemble des acteurs de soins IPS : Intrusion Prevention System 202 / Guide de Mise en Œuvre METHODE

57 I.4.4 La Méthode / Identifier le coût d’une règle (6/ COMMENT)
Pour chaque moyen, examiner La disponibilité des moyens Maturité des moyens techniques Préexistants dans l’organisation, «consommables» Acquisition courante ou action spécifique Possibilité de mutualisation des moyens avec ceux déterminés dans le cadre de l’analyse d’une autre règle Leur coût D’acquisition / développement De mise en œuvre (migration) D’exploitation et surveillance De maintenance / évolution Explications 202 / Guide de Mise en Œuvre METHODE

58 I.4.4 La Méthode / Identifier le coût d’une règle (7)
Cette analyse est d’abord menée de manière générique sur la règle, indépendamment des contraintes propres à un champ d’application Les conclusions de cette analyse générique sont ensuite ré-ajustées et exploitées pour les règles retenues dans le cadre d’un champ d’application Le travail sur un champ d’application, voire plusieurs, peut permettre de mutualiser les coûts de mise en œuvre d’une règle (ex. démarche SSI complète) 202 / Guide de Mise en Œuvre METHODE

59 I.4.4 La Méthode / Exemple de calcul du coût d’une règle (1)
RGS/ RS0021 Il est OBLIGATOIRE que les autorités administratives installant une nouvelle infrastructure de gestion de clés ou faisant appel à un Prestataire de Service de Certification électronique pour émettre des certificats de personne à usage d’authentification mettent en place une Politique de Certification compatible avec la PC Type Service Authentification V2.1 Nom du document

60 I.4.4 La Méthode / Exemple de calcul du coût d’une règle (2)
Dans cet exemple, on se positionne comme un organisme de santé (ex. établissement) décidant de mettre en œuvre la règle De recourir au GIP CPS pour assurer les services d’infrastructure de gestion de clé ou de Prestataire de services de certification Cette dernière hypothèse permet de simplifier la suite de l’analyse, en la recentrant sur les objets sensibles que va manipuler l’organisme de santé, soit directement cités dans la règle, soit déduits de l’analyse de la réglementation citée en référence Les planches qui suivent se basent sur l’analyse de la règle RS0021 du RGS et des exigences de la PC Type Service Authentification V2.1 202 / Guide de Mise en Œuvre METHODE

61 I.4.4 La Méthode / Exemple de calcul du coût d’une règle (3)
Analyse des aspects «QUOI» Informations personnelles des détenteurs de certificats Quelle protection, quelles responsabilités Certificats Protection de leur disponibilité et de la disponibilité de leur statut Supports de certificats et de clé pour les niveaux PRIS 2* et 3* les supports matériels doivent être certifiés EAL2+ (standard) ou EAL4+ (renforcée) sur l’échelle des Critères Communs Demander au GIP CPS : Le coût d’une carte CPS La charge de gestion en interne Coût des upgrades des applications hospitalières pour prendre en compte les certificats sur support matériel Critères d’estimation Nom du document

62 I.4.4 La Méthode / Exemple de calcul du coût d’une règle (4)
Analyse des aspects «Comment» On se place dans l’hypothèse ou l’organisme ne met pas en place d’IGC (concept cité dans la règle) Mais certains moyens à mettre en œuvre, cités dans la PC Type, restent sous la responsabilité de l’organisme, notamment Procédure (interne) de distribution et de révocation Local sécurisé de stockage des supports en attente de distribution (coffre-fort) Mise en cohérence des applicatifs Responsabilité de vérification de l’identité des porteurs IGC : Infrastructure de Gestion de Clés Nom du document

63 I.4.4 La Méthode / Exemple de calcul du coût d’une règle (5)
Analyse des aspects «QUI» Responsable de la vérification de l’identité des porteurs Mandataire de certification vérifications de l'identité, voire d’autres attributs des porteurs assure notamment le face-à-face (niveaux 2* et 3*) Interface avec l’Autorité d’Enregistrement Porteur Session de sensibilisation à l’usage de la carte et du certificat Responsable des informations personnelles Autorité de Certification Le Mandataire de certification est un rôle défini dans la PRIS v2 - PC Type – Authentification : Mandataire de certification (MC) - [ENTREPRISE] [ADMINISTRATION] Le mandataire de certification est désigné par et placé sous la responsabilité de l'entité cliente. Il est en relation directe avec l'AE. Il assure pour elle un certain nombre de vérifications concernant l'identité et, éventuellement, les attributs des porteurs de cette entité (il assure notamment le face-à-face pour l'identification des porteurs lorsque celui-ci est requis). (Note de l’auteur : le face-à-face (avec ou sans délégation) est obligatoire pour les niveaux 2* et 3*) Nom du document

64 I.4.5 La méthode / Résultats de l’Analyse du Référentiel (1)
A l’issue de l’analyse des référentiels Les référentiels sont analysés Les concepts présents dans les règles sont identifiés pour chaque niveau d’abstraction Les règles sont caractérisées selon Les différents niveaux d’abstraction Les concepts Le niveau de recommandation de la règle Réglementaire / Normatif Obligatoire / Optionnel / Déconseillé / Interdit (RFC2119) 202 / Guide de Mise en Œuvre METHODE

65 I.4.5 La méthode / Résultats de l’Analyse du Référentiel (2)
A l’issue de l’analyse des référentiels Les éléments génériques du coût de mise en œuvre des règles du référentiel sont estimés Cette analyse de coût doit ensuite être ajustée en fonction des objectifs de sécurité propres au champ d’application cible Ce point fait l’objet de la partie I.5 202 / Guide de Mise en Œuvre METHODE

66 I.5 La Méthode / Analyse du champ d’application
Cette phase s’organise autour de deux grandes activités Analyse de risque Sélection des règles 202 / Guide de Mise en Œuvre METHODE

67 I.5 La Méthode / Analyse du champ d’application
Critères Qualité des règles Analyse de risques Niveaux d’abstraction à considérer Biens Sensibles CONCEPTS (issus des Référentiels) Vulnérabilités L’analyse du champ d’application suit le déroulement d’une analyse de risque selon la méthodologie EBIOS, établie par la DCSSI * Sensibilité menaces COMBIEN Critères (COMBIEN, POURQUOI, QUAND, Où) Probabilité * Impact Bénéfices (POURQUOI) Risques Coûts Sélection des règles par Confrontation Coûts vs Risques Objectifs et contre-mesures 202 / Guide de Mise en Œuvre METHODE 67

68 I.5 La Méthode / Analyse de risque sur le champ d’application
L’analyse de risque suit les étapes suivantes 1. Etude de contexte Identifier les biens sensibles Caractériser le besoin de sécurité sur ces biens via les impacts sur le métier d’une perte de sécurité 2. Etude des menaces sur les biens et des vulnérabilités propres aux biens 3. Identifier les risques (scenarios d’attaque) 4. Identifier les objectifs de sécurité 5. Décliner les objectifs en exigences de sécurité 6. Rechercher des règles dans les référentiels analysés pour répondre aux objectifs de sécurité 202 / Guide de Mise en Œuvre METHODE

69 I.5.1 La Méthode / Analyse de risque sur le champ d’application
Etude de contexte Les activités importantes dans cette étape sont Identifier les biens sensibles du champ d’application, par exemple Informations à caractère personnel liées au patient Facture électronique (Feuille de soins FSE) Fonctions Ressources (PACS, Serveur de messagerie) … Identifier les concepts correspondants à ces biens sensibles Caractériser le besoin de sécurité sur ces biens (Disponibilité, Intégrité, Confidentialité, Preuve) (DICP) PFSS : Plate-forme de service de santé 202 / Guide de Mise en Œuvre METHODE

70 I.5.1 La Méthode / Analyse de risque sur le champ d’application
Concepts associés au champ d’application (exemple PFSS) Métier Professionnel de santé Patient Consentement Alertes Identité Identité Informations médicales Rendez-Vous Historique des événements Bases de connaissances (professionnelles) Espaces Collaboratifs Pilotage Système / Fonctionnel Bases de connaissances (publiques) Messagerie Sécurisée Serveur d’Identité Autorisation Fonctions techniques Observatoires Aide à la décision médicale Gestion des Urgences Gestion des gardes Dossier Patient E-Learning Annuaire Patient Annuaire PS Droits d’accès Portails Annuaires des ressources (ressources) support d’informations médicales Authentifiant Authentifiant Système / Architecture Mot de Passe Carte CPS Technique Nom du document

71 I.5.1 La Méthode / Analyse de risque sur le champ d’application
Etude de contexte (suite) Caractériser le besoin de sécurité sur ces biens via les impacts sur le métier du champ d’application d’une perte de sécurité selon les caractéristiques sécurité (Disponibilité, Intégrité, Confidentialité, Preuve) Utiliser une grille d’évaluation des impacts (planche suivante) Selon le champ d’application, pour un même bien, le besoin de sécurité peut varier, par exemple, pour un serveur de messagerie Pour la dématérialisation de factures D2 I4 C3 P3 Pour les PFSS D4 I3 C4 P3 DICP : Disponibilité, Intégrité, Confidentialité, Preuve 202 / Guide de Mise en Œuvre METHODE

72 I.5.1 La Méthode / Analyse de risque sur le champ d’application
Grille d’évaluation des besoins de sécurité Etude de contexte (suite) Quelque soit le champ d’application, utiliser la même échelle d’évaluation du besoin de sécurité, comme celle présentée dans cette planche -ci-dessous 202 / Guide de Mise en Œuvre METHODE

73 I.5.2 La Méthode / Analyse de risque sur le champ d’application / Menaces
Etude des menaces sur les biens et des vulnérabilités propres aux biens Utiliser un catalogue de menaces (ex. EBIOS, MEHARI) Pour chaque bien, évaluer les impacts des menaces pertinentes sur les axes QFRI (Q) Qualité des soins (F) Financier (R) Responsabilité (juridique) (I) Image (de l’établissement) Il est nécessaire de formaliser la correspondance entre les impacts sur les axes DICP et les impacts sur les axes QFRI, pour le champ d’application L’analyse réalisée s’est appuyée sur la méthodologie et les bases de connaissances EBIOS (DCSSI). Mais aucune méthode spécifique d’analyse de risque n’est imposée pour réaliser ces étapes. (autres possibilité, MEHARI, OCTAVE, NIST, etc.) Note 1 : Pour chaque bien, évaluer en priorité les impacts des menaces les plus pertinentes par rapport à ses besoins de sécurité estimés dans l’étape précédente Par exemple, évaluer l’impact de la menace de divulgation sur un bien diffusé au public n’est pas indispensable Note 2 : L’impact de Responsabilité (juridique) prend en compte les attaques juridiques pour non respect de la réglementation 202 / Guide de Mise en Œuvre METHODE

74 I.5.3 La Méthode / Analyse de risque sur le champ d’application
Identifier les vulnérabilités des biens et les risques (scenarios d’attaque) Exemple de vulnérabilité Absence / faiblesse de contrôle d’accès physique ou logique Identifier la nature des attaques Indisponibilité des matériels Perte d’intégrité des données et/ou des Identités Divulgation d’informations (sensibilité accrue sur les VIP) Atteinte à l’image Identifier l’origine des attaques 202 / Guide de Mise en Œuvre METHODE

75 I.5.3 La Méthode / Analyse de risque sur le champ d’application
Identifier l’origine des attaques, par exemple Humaine Erreur d’utilisation (humain) Physique Panne, perte d’énergie Principes d’organisation du système Ex. Identito-Vigilance Défauts de processus Principes d’architecture des systèmes et de construction des logiciels Surveillance insuffisante des équipements Contrôle insuffisant des modifications sur les logiciels Limites des politiques de contrôle d’accès 202 / Guide de Mise en Œuvre METHODE

76 I.5.4 La Méthode / Analyse de risque sur le champ d’application
Identifier les Objectifs de sécurité Grandes orientations visant à contrer / réduire les risques Tant du point de vue de la probabilité d’occurrence que des impacts Par exemple Protéger l’intégrité des données gérées (Id, Dossier Patient, aide à la décision, statistiques, ressources) Maintenir la disponibilité des systèmes et données (pérennité) Préserver la confidentialité des données à partir du moment où elles sont d’accès restreint Préparer des preuves contre les attaques judiciaires Mettre en place le Contrôle d’accès (principes d‘authentification) Identifier les concepts visés par ces objectifs Données médicales, Identité Patient, Authentification 202 / Guide de Mise en Œuvre METHODE

77 I.5.5 La Méthode / Analyse de risque sur le champ d’application
Décliner les objectifs en exigences de sécurité A partir des concepts identifiés dans les objectifs, rechercher dans la base des référentiels les règles portant sur ces concepts Sélectionner les règles applicables au champ Ce point fait l’objet des pages suivantes (I.5.6) Compléter avec des exigences propres au champ et non couvertes par les règles existantes 202 / Guide de Mise en Œuvre METHODE

78 I.5.6 La Méthode / Sélection des règles applicables (1)
La sélection des règles applicables s’appuie sur L’utilisation des référentiels analysés et des règles caractérisées L’exploitation des caractéristiques propres à chaque règle L’analyse de la règle par rapport Aux autres règles (dépendances, redondances) Au champ d’application (coût / bénéfice) Aux opportunités de factorisation de la règle (et de son coût) sur plusieurs champs d’application Aux opportunités de mise en œuvre Dans le cas des redondances entre règles, les principes de priorité sont les suivants Une règle issue d’un référentiel réglementaire prime la règle normative Une règle obligatoire prime une règle optionnelle 202 / Guide de Mise en Œuvre METHODE

79 I.5.6 La Méthode / Sélection des règles applicables (2)
Exploitation des caractéristiques propres à chaque règle Les concepts ciblés par la règle et le niveau d’abstraction considéré sont-ils cohérents avec ceux du champ d’application ? La règle appartient-elle à un référentiel réglementaire ou normatif ? Quel est son niveau de recommandation (Obligatoire / Optionnel) ? Quelles sont les caractéristiques sécurité impactées par la mise en œuvre de la règle ? Quelle est la qualité de rédaction de la règle ? La règle fournit-elle une motivation générique ? Quel est son coût théorique de mise en œuvre ? 202 / Guide de Mise en Œuvre METHODE

80 I.5.6 La Méthode / Sélection des règles applicables
Construction de l’argumentation sur la règle Base de connaissance des référentiels 1/ Lister les règles des référentiels correspondants aux CONCEPTS des objectifs 2/ Caractéristiques intrinsèques de la règle 3/ Intérêt de la règle par rapport Réglementaire / Normatif * Obligatoire / Optionnel Autres Règles : redondance / dépendance Niveau d’Abstraction Exemples d’opportunités de factorisation de la mise en œuvre d’une règle (et de son coût) sur plusieurs champs d’application ou avec une autre règle: Dans un établissement, mettre en place une authentification à deux facteurs sur la prescription, la saisie d’acte, la télémédecine, la dématérialisation des échanges administratifs (FSE, achats) Dans le RGS, factoriser les nombreuses règles paramétrables selon le type de certificat et la PC Type (Authentification, Signature, Authentification + Signature, Chiffrement ) Au champ d’application : bénéfice attendu / motivation pour le champ DICA Qualité de la règle Existence d’une motivation À tous les champs d’application concernés (possibilité de factorisation) Coût de la règle Opportunité Nom du document

81 I.5.6 La Méthode / Processus de sélection des règles
Organiser les règles caractérisées par des concepts communs avec les objectifs de sécurité issus de l’analyse de risque Par source (réglementaire / normatif) Par niveau de recommandation (Obligatoire / recommandé ou optionnel) Règles autonomes / règles dépendantes d’autres règles Règles communes à des recherches sur plusieurs concepts Par niveau d’abstraction Par motivation (si exprimée) Nom du document

82 I.5.6 La Méthode / Processus de sélection des règles (2)
Vérifier Leur conformité avec la base juridique existante applicable aux concepts de la règle Leur qualité (cf. Règles du Business Rules Group) La redondance ou la contradiction avec une autre règle Le réglementaire l’emporte sur le normatif si pertinent Préciser, dans l’argumentation de la règle choisie, les différentes sources contenant une règle redondante 202 / Guide de Mise en Œuvre METHODE

83 I.5.6 La Méthode / Processus de sélection des règles (3)
Selon une démarche similaire à celle de l’estimation du coût de mise en œuvre de la règle, identifier les moyens nécessaires pour sa mise en œuvre les limites de la mise en œuvre QUI : Responsabilités, Organisation, moyens humains QUOI : Ressources matérielles COMMENT : disponibilité des moyens (maturité technique), méthodes, outils Quand Satisfaction des pré-requis , Stabilité dans le temps et l’espace de la règle et du Champ d’application Où : Périmètre géographique, organisationnel, fonctionnel Pourquoi (motivation) Compatibilité avec la base juridique existante applicable aux concepts cités dans la règle Critères de qualité (cf. liste des qualités des règles métier Liens entre les objets manipulés par la règle et les « biens » sensibles du champ d’application (issus de l’analyse de risque) COMBIEN (Coût de mise en oeuvre / Bénéfice attendu) ; o Le bénéfice de l’application de la règle qu’elle est susceptible d’apporter au champ d’application, et la capacité à mesurer ce bénéfice ; o Le manifeste des règles métier du Business Rules Group cite nommément cet aspect du processus d’évaluation des règles (cf. annexe §C Critère 8.3) : Le coût de la mise en vigueur des règles doit être apprécié en fonction des risques encourus ainsi que des opportunités manquées en cas de leur non application.) ; · Aspects réglementaires : o La règle doit être compatible avec la base juridique existante applicable aux concepts cités dans la règle ; o Le libellé de la règle doit préparer les règlements futurs ; · QUAND : Stabilité dans le temps et l’espace de la règle et du champ d’application : o Stratégie de déploiement de la règle ; o Réalisation des (in)formations nécessaires ; o Stabilité de la notion dans le temps et dans l’espace ; o Variabilité selon l’organisation ; Nom du document

84 I.5.6 La Méthode / Processus de sélection des règles (4)
Confronter le COMBIEN au POURQUOI Confronter le coût de la mise en œuvre de la règle portant sur un concept Avec le coût de l’impact d’un risque sur les biens sensibles correspondant à ce concept dans le champ d’application (bénéfice attendu) Evaluer les opportunités de mise en œuvre Factorisation entre champ d’application Multiplicité des motivations Volonté politique Nom du document

85 I.5.6 La Méthode / Processus de sélection des règles (5)
Confronter le coût de mise en œuvre de la règle aux bénéfices pour le concept sensible 1/ Référentiels 2/ Champ d’application Analyse de l’impact de la règle Analyse de risques sur le champ Coût de mise en œuvre Coût d’une attaque sur le bien / concept L’argumentaire 4/ Opportunité 3/ Avis objectif 5/ Décision 202 / Guide de Mise en Œuvre METHODE

86 I.5.6 La Méthode / Processus de sélection des règles (Complément)
Vérifier la couverture des objectifs de sécurité issus de l’analyse de risque sur le champ d’application par les règles issues des référentiels Si certains objectifs ne sont pas couverts par les règles Enrichir la base de référentiels avec des référentiels portant sur les concepts de l’objectif Décliner les exigences de sécurité correspondant à ces objectifs en règles propres au champ d’application base de connaissance (ISO 27002, ISO 15408, ISO 21827, etc.) méthode heuristique (rédaction de toute pièce) Conseils pratiques [Méthode EBIOS V2] pour l’élaboration des exigences fonctionnelles de sécurité « Il est possible d'utiliser les exigences de sécurité fonctionnelles génériques et le tableau de détermination des objectifs et exigences de sécurité du guide "Outillage pour le traitement des risques SSI" pour lister les exigences de sécurité fonctionnelles destinées à satisfaire les objectifs de sécurité couvrant les vulnérabilités. Les exigences de sécurité fonctionnelles peuvent être sélectionnées parmi les composants fonctionnels de la base de connaissances ou rédigées de toute pièce. Chacun des objectifs de sécurité devra être couvert par au moins une exigence de sécurité et la complète couverture doit être dûment justifiée. Les exigences sont ensuite raffinées, dans la mesure du possible, et les dépendances entre composants (Critères Communs) doivent être étudiées et justifiées. Selon le niveau d’expertise sur le système, les composants peuvent être laissés non-raffinés en précisant toutefois qu’ils seront raffinés par le maître d’oeuvre dans le cadre de sa réponse. (Note de l’auteur : ce point s’adresse directement à la structure des exigences formalisées dans les Critères Communs, qui peuvent rester non-raffinés si l’analyse vise la réalisation d’un profil de protection, et non d’une cible de sécurité) 202 / Guide de Mise en Œuvre METHODE

87 I.5.6 La Méthode / Processus de sélection des règles (Complément)
Exemple les objectifs de qualité de construction des logiciels pour limiter les dysfonctionnements et assurer la disponibilité et l’intégrité du service, ne sont actuellement couverts par aucune règle issus des référentiels analysés Les exigences correspondantes pourraient être Mettre en place un processus formalisé de gestion de configuration sur [les composants système intervenant dans le champ d’application] (ISO 27002, ISO 20000, ISO 9001, CMMI) Mettre en œuvre les exigences d’assurance sécurité décrites dans les critères communs (ex. qualification EAL4 du logiciel de rapprochement d’identité) Note : Les différents niveaux d’évaluation des systèmes / produits selon la norme ISO (Critères Communs) sont les suivants : Evaluation assurance level 1 (EAL1) - functionally tested Evaluation assurance level 2 (EAL2) - structurally tested Evaluation assurance level 3 (EAL3) - methodically tested and checked Evaluation assurance level 4 (EAL4) - methodically designed, tested, and reviewed Evaluation assurance level 5 (EAL5) - semiformally designed and tested Evaluation assurance level 6 (EAL6) - semiformally verified design and tested Evaluation assurance level 7 (EAL7) - formally verified design and tested 202 / Guide de Mise en Œuvre METHODE

88 Les outils support de la démarche
Aperçu de la seconde partie du Guide de mise en œuvre Nom du document

89 Guides et mode d’emploi
Mode d’emploi de Nuxeo Mode de construction d’une base de règles à partir d’un nouveau référentiel Mode d’emploi Nuxeo . doc Guide de Construction d’une base de règles . ppt Nom du document

90 Guides et mode d’emploi
Outil d’analyse de risque pour un champ d’application Outils de sélection des règles Analyse de risque. Xls Modèle de FEROS . ppt Note Technique Sélection_règles Nom du document

91 Base de connaissances Nom du document


Télécharger ppt "Guide de mise en œuvre de la méthode – Introduction"

Présentations similaires


Annonces Google