Déclinaison du Cadre Interopérabilité Sécurité dans le domaine de la Santé 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

Nom du document 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

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 3

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

4202 / Guide de Mise en Œuvre METHODE


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° 2005-1516 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é,



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


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


0.2 Introduction / Les référentiels dans le domaine de la santé (1)

8202PLANGT v01

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

Les référentiels répondent au besoin de cohérence entre

les enjeux métier

L’accroissement de la complexité de l’environnement


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

9202PLANGT v01


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

10202PLANGT v01


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étierSystème fonctionnelSystème applicatif Technique

11202PLANGT v01


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

13202PLANGT v01


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 DICOMLes profils IHE …

14202PLANGT v01


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, …

15202PLANGT v01


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 oune condition (aussi appelée fait) oet 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



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

17202PLANGT v01


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é

18202PLANGT v01

0.2 Introduction / Besoin d’une organisation pour établir le consensus

19Présentation

Groupe d’experts du domaine étudié

Critères de construction des taxinomies des architectures et des règles

Critères de construction des taxinomies des architectures et des règles

Critères de caractérisation

des champs d’application


des champs d’application

Analyse des règles Analyse des règles

« Confrontation» des règles aux besoins et sélection» des règles

« Confrontation» des règles aux besoins et sélection» des règles

Validation finale des règles sélectionnées

Validation finale des règles sélectionnées

Décision sur le champ

Acteurs du champ d’application


des référentiels


des référentiels

Validation

Validation en commun

Validation en commun

Comité d’Arbitrage

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

20202PLANGT v01


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,…



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



23Présentation

§

Référentiels Santé Existants(e.g. DICOM, DMP, EHRcom,HPRIM, HL7, IHE, OSM…)

RG* de la DGME(i.e. RGI, RGS, RGAA)

R* pour les SI de Santé…à venir…

Origines(Organisations, Référentiel, Elément Structurel)

Règle #613Règle #613









Règles










Règles

Champs d’Application

No

tio

ns

No

tio

ns

Quelle méthode d’analyse ? Une structuration commune basée sur des notions ou concepts partagés


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

connaissance2/ Argumenter et sélectionner les règles applicables

à un champ d’application

24Nom du document

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 7498-2:1989)



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



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



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. 1110-4, L. 1111-8) La loi n° 2007-127 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. 1110-4 (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é


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


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


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


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)


I.2 La Méthode / Etapes

Nom du document 33

2/ Champ d’application

1/ Référentiels

Concepts Sensibles

Analyse des règles

Concepts

3/ Rechercher les règles portant sur le concept sensible

Analyse de risques

4/ Confronter le coût de mise en œuvre de la règle / Bénéfices pour le concept sensible

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)

34Nom du document

I. 3 La Méthode / Grands principes (Zachman)

Nom du document 35

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’applicationOù : 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 36

I.3 La Méthode / Grands Principes / Concepts clés

37Nom du document

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

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


I.3 La Méthode / Grands principes/ Exemple de chaînes de concepts

Nom du document 39

Fichier des Chaînes de concepts

Autorisation

Accès

Profil

Rôle

Fonction

Droit d’accès

Contrôle d’Accès

Authentification

Equipe

Personne

Identité

Authentifiant

Réglementation Organisation

Identification Acteur

Mot de Passe

CertificatCaractéristique biométrique

Autres Mécanismes d’authentification

Contrôle de profil

Ressources informatiques

Données

Système

Information

Système d’Information

Identifiant unique et exclusif

Métier

Système / Fonctionnel

Système / Architecture

Technique

Identifiant

Procédure de

face à face

Garantie d’Id.

Assertion

Attestation

Mécanismes d’authentification

Certificat électronique

Identité numérique

Pièce d’Identité

Id. numérique

Habilitation

Ex. Access List

I.3 La Méthode / Concepts clés et Synonymes

40²202 / Guide de Mise en Œuvre / METHODE

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édicalesinformations à caractère médical informations médicales à caractère personnel Dossier médical

Champ d’application Référentiels

Analyse de risques

Biens Sensible

s

Vulnérabilités

Objectifs et contre-mesures

Critères Qualité des règles

Critères (COMBIEN, POURQUOI, QUAND, Où)

Analyse Zach N

Objets (QUOI)

QUI

COMMENT

COMBIEN

Où QUAND

Concepts de chaque niveau d’abstraction

Confrontation Coûts vs Risques Coûts

Bénéfices (POURQUOI)

Sensibilité

Probabilité * Impact Risques

menaces

Niveaux d’abstraction à considérer

COMBIEN & POURQUOI

202_CR_CP_08072008 41

I.3 La Méthode / Grands principes / Scenario global

I.4 La Méthode / Analyse des référentiels

Nom du document 42

Référentiels

Analyse Zach N

Objets (QUOI)

QUI

COMMENT

COMBIEN

Où

Concepts de chaque niveau d’abstraction

Coûts



I.4 La Méthode / Les référentiels analysés (1/2)

Nom du document 43

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é

oCSP

oArrêté Confidentialité

oDécret Hébergeur CNIL

Autres réglementaires HIPAA

I.4 La Méthode / Les référentiels analysés (2/2)

Nom du document 44

Référentiels Normatifs Généraux

o ISO 27799 Métier

oGIP CPS : Référentiel d’Homologation des Outils de Sécurisation de Messagerie (OSM)

o IHE : XUA, ATNA, DSG

oDICOM – Security

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

ISO 27799

Métier

Architecture

Générique

RGSRGI

Architectures de sécurité (GMSIH)

Etude sécurité (GMSIH)

Ref. Homologation

des OSM

Décret hébergeu

r

CSP/ Arrêté Confidentialit

éMétier

Système Fonctionnel

Technique

HIPAA

Réf. «Confidentialité»

(GMSIH)

IHE DICO

M

I.4.1 La Méthode / Les référentiels étudiés

I.4.2 La Méthode / Critères qualité des règles

Nom du document 47

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


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

48Nom du document


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

49Nom du document

I.4.3 La Méthode / Analyse Zachman

Nom du document 50

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

I.4.3 La Méthode / Analyse Zachman

Nom du document 51

REGLE : ACTEUR réalise ACTION sur OBJET avec des MOYENS, en conformité avec REFERENCE dans telles CONDITIONS pour atteindre un OBJECTIF

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

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 ?

52Nom du document

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


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, …)


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


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


I.4.4 La Méthode / Identifier le coût d’une règle (6/ COMMENT)

202 / Guide de Mise en Œuvre METHODE 57

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

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)


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

59Nom du document


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



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

61Nom du document


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

62Nom du document


Analyse des aspects «QUI» Responsable de la vérification de l’identité des

porteurs Mandataire de certification

ovérifications de l'identité, voire d’autres attributs des porteurs

oassure notamment le face-à-face (niveaux 2* et 3*) o 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

63Nom du document

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

oRéglementaire / Normatif

oObligatoire / Optionnel / Déconseillé / Interdit (RFC2119)


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


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


I.5 La Méthode / Analyse du champ d’application


Champ d’application

Analyse de risques

Biens Sensible

s

Vulnérabilités

Objectifs et contre-mesures


Critères (COMBIEN, POURQUOI, QUAND, Où)

Sélection des règles par Confrontation Coûts vs Risques


Sensibilité

Probabilité * Impact Risques

menaces

Niveaux d’abstraction à considérer

67

COMBIEN

Coûts

CONCEPTS (issus des

Référentiels)

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é

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

o Informations à caractère personnel liées au patient

oFacture électronique (Feuille de soins FSE)

oFonctions

oRessources (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)


Nom du document70

Alertes

Identité

Métier

Système / Fonctionnel

Système / Architecture

Technique

Informations médicales

Carte CPS

Patient Professionnel

de santé

Authentifiant

Consentement

Messagerie Sécurisée

Espaces Collaboratifs

Fonctions techniques

Bases de connaissances (publiques)

Bases de connaissances (professionnelles)

Identité

Authentifiant

Annuaire Patient

Annuaire PS

Annuaires des ressources

Serveur d’Identité

Droits d’accès

Historique des événements

Gestion des gardes

Portails

Autorisation

Mot de Passe

Pilotage

Gestion des Urgences

Observatoires

Rendez-Vous

Aide à la décision médicale E-LearningDossier

Patient

(ressources) support d’informations médicales

Concepts associés au champ d’application (exemple PFSS)



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

Grille d’évaluation des besoins de sécurité



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



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




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


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



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


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


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 ?


I.5.6 La Méthode / Sélection des règles applicables

Nom du document 80

Construction de l’argumentation sur la règle

1/ Lister les règles

des référentiels correspondants aux CONCEPTS des objectifs

2/ Caractéristiques intrinsèques de la

règle

Réglementaire / Normatif * Obligatoire / Optionnel

Niveau d’Abstraction

DICA

Qualité de la règle

Existence d’une motivation

Coût de la règle

3/ Intérêt de la règle par rapport

Autres Règles : redondance / dépendance

Au champ d’application : bénéfice attendu /

motivation pour le champ

À tous les champs d’application

concernés (possibilité de factorisation)

Opportunité

Base de connaissance des référentiels

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 document81

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

pertinentPréciser, dans l’argumentation de la règle choisie,

les différentes sources contenant une règle redondante



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

o Satisfaction des pré-requis , o 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

83Nom du document


Nom du document84

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


Confronter le coût de mise en œuvre de la règle aux bénéfices pour le concept sensible


2/ Champ d’application 1/ Référentiels

Coût d’une attaque sur le bien / concept

Analyse de l’impact de la règle

Coût de mise en œuvre

3/ Avis objectif

Analyse de risques sur le champ

4/ Opportunité

5/ Décision

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)


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


Les outils support de la démarche

Aperçu de la seconde partie du Guide de mise en

œuvre

Nom du document 88

Guides et mode d’emploi

Nom du document 89

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

Guides et mode d’emploi

Nom du document 90

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ègle

s

Base de connaissances

Nom du document 91

Documents

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