Annexe 4 _Sécurité de l`information - e

ANNEXE 4
Sécurité de l’information
Document de référence
Aide à la Définition des exigences de sécurité
Dans le cadre de l’élaboration
D’un cahier de charges
13/06/2014
GM
Adaptation Interprétations acronyme MoSCoW
11/06/2014
GM
Document de base –
présentation groupe chef projet informatique
04/06/2014
GM
Elaboration du document.

Exigences sécurité
Lors de l’élaboration d’un cahier de charges,
1. Revue des exigences de base avec le Conseiller en Sécurité du Système d’Information
2. Au besoin, sélection, ajout, retrait d’exigences et adaptation des niveaux d’exigences
3. Emission d’un rapport contradictoire (identification et raison des écarts)
4. Validation formelle par l’utilisateur principal et l'exécutif du projet pour acceptation des risques non
couverts ou résiduels
5. Intégration des exigences retenues et de leur niveau d’exigence dans le cahier de charge
Le Dossier Patient Informatisé est au cœur du système d’information et est indispensable pour soutenir
l'activité de l'institution. Dans sa conception, son architecture, son développement, sa maintenance et dans
son utilisation, cette solution doit impérativement répondre aux exigences de sécurité de l’information et de
protection de la confidentialité des données à caractère personnel.
Il en est de même pour toute solution périphérique participant à la prise en charge médicale, soignant ou
administrative du patient ou participant aux missions des Cliniques gérant des données à caractère personnel,
des données critiques ou sensibles.
Côté patient, si l'informatisation du milieu hospitalier tend à assurer un meilleur partage de
l'information au sein de l'institution et des équipes médicales et soignantes lors de la prise en charge
médicale, la dématérialisation du dossier amène une certaine inquiétude : «Trop de monde peut
accéder à mon dossier ». Ainsi, toute solution doit répondre à cette préoccupation en vue du respect
des droits du patient. Le dossier ou toute partie participante à sa constitution doit être vu comme un
coffre-fort électronique dont l'accès est limité aux seules personnes habilités lors des prises en
charge médicale et pour assurer la continuité des soins.
Côté utilisateur, le souhait est d’avoir à disposition une solution ergonomique flexible, mobile,
d’accès facile et permanent pour les missions que l'utilisateur assure : prise en charge du patient
qu'elle soit médicale, soignante ou administrative, enseignement, recherche.
La question de la sécurité tend à trouver le point d'équilibre et de convergence dans le strict respect des lois
et des règles.
Les données à caractère personnel, et spécifiquement les données médicales, doivent être gérées
comme appartenant à un coffre-fort électronique à savoir un espace virtuel de stockage et de
conservation sécurisé et réputé inviolable permettant de restituer ce qui y a été déposé sans altération.
Dès lors, dans une vision idéale, seuls les professionnels de la santé qui participent à la continuité des soins
du patient, c’est-à-dire à des activités de diagnostic, de traitement ou de prévention, peuvent accéder aux
informations nominatives. Pour assurer les missions d'enseignement et de recherche, l'utilisateur accédera à
des informations anonymisées.
Les exigences s'appliquent à tout actif informationnel (solution informatisée et appareillage médical –
pour tout « objet » : exécutables, données, serveur (application ou base de données), poste utilisateur
(fixe ou mobile),...). En annexe1, schéma des bonnes pratiques en matière de datasecurity management.
Les différentes garanties à rencontrer sont :
• l'authentification (au besoin, forte) (qui),
• l'autorisation ou contrôle d'accès (qui peut avoir accès),
• la confidentialité (qui accède à quoi, quand, comment et pourquoi),
• le droit de modification (qui modifie quoi), et
• la traçabilité (qui a fait quoi)
• l’intégrité, la disponibilité et la rétention de l’information (sécuriser et protéger le quoi)

Relevé des exigences en rapport aux fonctionnalités des solutions
Le tableau suivant reprend les fonctionnalités. L’interprétation des valeurs de l'acronyme MoSCoW étant:
M - MUST - DOIT l’avoir – exigence obligatoire, impérative et vitale.
S - SHOULD - DEVRAIT l’avoir – exigence obligatoire, essentielle et critique mais peut être remplacée par
une solution alternative technique et/ou organisationnelle offrant un niveau de sécurité équivalent, reconnue
et validée par la commission de confidentialité et de sécurité de l’information.
C - COULD (POURRAIT l’avoir) –devrait être implémentée dans les intérêts du projet, si les ressources
projet le permettent. Une solution alternative assurant la finalité de l’exigence est à proposer si
l’implémentation de l’exigence se fera par la suite.
W – WOULD - peut être implémenté par la suite.
Fonctionnalités
Niveau
proposé
Niveau
retenu
1
Contrôle d’accès
1.1
Accès contrôlé aux seuls utilisateurs habilités (en fonction de
profils individuels, rôle(s), association avec des groupes de travail)
aux applications et aux fonctions pour un « accès nécessaire et
suffisant » en liaison avec le contrôle de session.
M
1.2
Accès contrôlé pour des tiers externes (rejet des connexions
abusives, logs des tentatives usurpées, refus d'interception de
session) (niveau browser, application et db)
M
1.3.
Format et valeurs de l’identifiant login calqués au format et valeurs
des logins institutionnels.
M
1.4
Identification des utilisateurs synchronisés avec un annuaire central
(A.D. ou type LDAP) sur base d'un groupe ou attribut.
S
1.5.
Comptes à privilèges (application, DB, server) propre à l’institution
avec accès contrôlé et journalisé (refus d’une approche générique)
M
1.6.
Subordination à la solution institutionnelle de Single-Sign-On
S
2.
Fonctions de sécurité
2.1.
Plan de classement ou catégorisation des informations (à défaut,
niveau le plus élevé doit être appliqué)
M
2.2.
Fonctionnalité de gestion des droits d'accès, attribution et
révocation – avec historique des droits (via rôle administrateur
d'application)
M
2.3.
Mécanisme sécurisé de connexion et de gestion et de suivi de
session. (usage protocole SSL, challenge de session, refus dans les
url de données de session/identification, absence de persistance de
données session en dehors de la session…)
M
2.4.
Mécanisme d'Horodatage (timestamping des informations)
M
2.5.
Mécanisme d'Horodatage certifié (conformité législation pour les
M

Fonctionnalités
Niveau
proposé
Niveau
retenu
fonctionnalités de prescription) (compatibilité interface ehealth)
2.6.
Conversion des formats vers un format pérenne (en entrée) (exple
de format jugé pérenne : pdf/A-1, XML, Tiff groupe 4, ODT,...)
C
2.7.
Pérennité - Conversion des formats au sein de la solution pour toute
information nécessitant un archivage électronique (interface dossier
patient et conservation des données et rapports légaux) (exple de
format jugé pérenne : pdf/A-1, XML, Tiff groupe 4, ODT,...)
M
2.8.
Disponibilité (QoS) (en fonction des besoins des services
utilisateurs – adaptation du SLA)
M
2.9.
Mécanisme et procédure intégrés au Plan de continuité et de reprise
des services utilisateurs ou de l'institution
S
2.10.
Mécanisme de maintien des capacités (puissance, stockage
adéquat)
S
2.11.
Outil d'audit de sécurité – interrogation et rapport de tout accès aux
données sur base des traces
S
2.12.
Mécanisme d’impression sécurisée – marquage automatique de la
mention « confidentiel », horodatage, identité utilisateur.
M
2.13.
Mécanisme de prévention contre la copie et la fuite de données
(contrôle des ports, encryption,..)
S
3
Authentification - Non répudiation
.
3.1
Authentification univoque des utilisateurs et non répudiation des
actions (au besoin, authentification forte suivant mécanisme adapté
à la sensibilité des informations, aux modes de communication)
M
3.2
Signature électronique associé aux actions (conformité législation
des prescriptions)
M
3.3.
Signature électronique à valeur probante (conformité législation
pour les documents communiqués électroniquement à un tiers
externe) (p.e. comptabilité carte eID)
M
3.4.
Mécanisme de délégation formelle (association responsable /
délégué avec gestion des historiques des associations)
S
4
Protection du contenu
4.1.
Chiffrement du contenu en fonction de la catégorie de l'objet
M
4.2.
Chiffrement des communications et des échanges
M
5.
Intégrité / exactitude
.
5.1.
Intégrité (bit par bit) en contenu et en format
M
5.2.
Intégrité avec évolution des données / formulaires - gestion de la
M

Fonctionnalités
Niveau
proposé
Niveau
retenu
présentation historique
5.3.
Lisibilité dans le temps
M
5.4.
Mécanisme de retrait logique d'informations et notification
(données erronées, droit rectification émanant du patient)
M
5.5.
Mécanisme de couplage ou découplage de dossiers (fusion)
S
6.
Confidentialité
6.1.
Confidentialité (contenu secret) vis-à-vis des collaborateurs
habilités (en fonction de la catégorisation des données et des
groupes métiers) (collecte et traitement des informations limités à
celles nécessaires, aux seuls fins attendues , accès à un champ en
fonction de l'utilisateur, du rôle, du groupe métier)
M
6.2.
Confidentialité (contenu secret) vis-à-vis de tiers externes.
Séparation et isolement des données de celles des autres clients
(p.e. cas cloud privé/communautaire)
M
6.3.
Confidentialité vis-à-vis d’administrateurs du système
M
6.4.
Mécanisme contrôle d'accès en fonction du lien thérapeutique et/ou
dossier ouvert/fermé en fonction des périodes de visites du patient
et possibilité de bris-de-glace (cas d'urgences)
S
6.5.
Anonymisation des données d'identification des patients/ des
personnes pour accès dans le cadre des missions de recherche et
d'enseignement
S
6.6.
Indication des patients à risque élevé (notion de VIP, notion
d'alertes,...)
S
6.7.
Mécanisme d'enregistrement du consentement éclairé du patient
S
6.8.
Mécanisme d'enregistrement du droit d'opposition du patient
(écartement d'un prestataire de soins, retrait d’informations,...)
S
6.9.
Confidentialité des données relatives à des personnes tierces
S
6.10.
Automatisation du masquage des données nominatives pour les
environnements de tests et de validation.
M
7.
Protection
7.1.
Protection logique des données (restriction d'accès de session
(time-out), support crypté, mécanisme de Data Lost Protection,
contre altération et accès direct en DB, validation des backups,
procédure d'effacement sécurisé lors retrait des équipements) (être
attentif à l'appareillage médical et aux équipements mobiles)
M
7.2.
Stockage distinct entre les renseignements d'identité des patients et
les informations médicales, de soins et de traitements. (Ce service
permettra également aux chercheurs et analystes autorisés
S