• est un guide aidant à la définition/sélection de mesures de sécurité
• n’est pas un référentiel de certification (contrairement à ISO 27001 qui est un recueil d’exigences, à l’instar de l’ISO 9001 dans le domaine de la qualité)

La première version date de 2005 et devrait être remplacée, d’ici la fin de cette année, par une nouvelle version ISO/IEC 27002:2013.

Le brouillon de cette version est en appel à commentaires jusqu’à Mars 2013.
Je vous propose de découvrir l’état actuel et la nouvelle structuration de ce document normatif (j’aborderai le fond, certaines nouvelles thématiques, dans de prochains articles).

NB : La version française – « NF », n’étant évidemment pas encore d’actualité ; j’ai repris la terminologie de la précédente traduction lorsque les termes/phrases étaient strictement identiques, sinon je me suis efforcé de traduire en collant au plus près de la terminologie courante dans le domaine de la SSI.

____________________________________________________________

Préambule

0. Introduction

0.1 Historique et contexte

0.2 Besoins en sécurité de l’information

0.3 Sélection des mesures de sécurité

0.4 Mise au point des lignes directrices propres à l’organisme

0.5 Prise en compte du cycle de vie

0.6 Normes associées

1. Domaine d’application

2. Références normatives

3. Termes et définitions

4. Structure de la présente norme

4.1 Articles

4.2 Principales rubriques

5. Politiques de sécurité

5.1 Directives pour la gestion de la sécurité de l’information

5.1.1 Politiques de sécurité de l’information

5.1.2 Réexamen de la politique de sécurité de l’information

6. Organisation de la sécurité de l’information

6.1 Organisation interne

6.1.1 Rôles et responsabilités en matière de sécurité de l’information

6.1.2 Relations avec les autorités

6.1.3 Relations avec des groupes de spécialistes

6.1.4 Sécurité de l’information dans la gestion des projets

6.1.5 Séparation des tâches

6.2 Appareils mobiles et télétravail

6.2.1 Politique pour les appareils mobiles

6.2.2 Télétravail

7. Sécurité liée aux ressources humaines

7.1 Avant le recrutement

7.1.1 Sélection

7.1.2 Conditions d’embauche

7.2 Pendant la durée du contrat

7.2.1 Responsabilités de la direction

7.2.2 Sensibilisation, qualification et formation en matière de sécurité de l’information

7.2.3 Processus disciplinaire

7.3 Fin ou modification de contrat

7.3.1 Responsabilités en fin de contrat

8. Gestion des biens

8.1 Responsabilités relatives aux biens

8.1.1 Inventaire des biens

8.1.2 Propriété des biens

8.1.3 Utilisation correcte des biens

8.2 Classification de l’information

8.2.1 Classification de l’information

8.2.2 Marquage de l’information

8.2.3 Manipulation des biens

8.2.4 Restitution des biens

8.3 Manipulation des supports

8.3.1 Gestion des supports amovibles

8.3.2 Mise au rebut des supports

8.3.3 Supports physiques en transit

9. Contrôle d’accès

9.1 Exigences métier relatives au contrôle d’accès

9.1.1 Politique de contrôle d’accès

9.1.2 Politique relative à l’utilisation des services en réseau

9.2 Gestion de l’accès utilisateur

9.2.1 Enregistrement des utilisateurs

9.2.2 Gestion des privilèges

9.2.3 Gestion des secrets d’authentification des utilisateurs

9.2.4 Réexamen des droits d’accès utilisateurs

9.2.5 Retrait ou modification des droits d’accès utilisateurs

9.3 Responsabilités utilisateurs

9.3.1 Utilisation des secrets d’authentification

9.4 Contrôle d’accès au système d’exploitation et aux applications

9.4.1 Restriction d’accès à l’information

9.4.2 Ouverture de sessions sécurisées

9.4.3 Système de gestion des mots de passe

9.4.4 Emploi des utilitaires système

9.4.5 Contrôle d’accès au code source du programme

10. Cryptographie

10.1 Mesures cryptographiques

10.1.1 Réglementation relative aux mesures cryptographiques

10.1.2 Gestion des clés

11. Sécurité physique et environnementale

11.1 Zones sécurisées

11.1.1 Périmètre de sécurité physique

11.1.2 Contrôles physiques des accès

11.1.3 Sécurisation des bureaux, des salles et des équipements

11.1.4 Protection contre les menaces extérieures et environnementales

11.1.5 Travail dans les zones sécurisées

11.1.6 Zones de livraison et de chargement

11.2 Matériel

11.2.1 Choix de l’emplacement et protection du matériel

11.2.2 Services généraux

11.2.3 Sécurité du câblage

11.2.4 Maintenance du matériel

11.2.5 Retrait des biens

11.2.6 Sécurité du matériel et des biens hors des locaux

11.2.7 Mise au rebut ou recyclage sécurisé(s) du matériel

11.2.8 Matériel utilisateur laissé sans surveillance

11.2.9 Politique du bureau propre et de l’écran vide

12. Sécurité de l’exploitation

12.1 Procédures et responsabilités liées à l’exploitation

12.1.1 Procédures d’exploitation documentées

12.1.2 Gestion des modifications

12.1.3 Dimensionnement

12.1.4 Séparation des équipements de développement, de test et d’exploitation

12.2 Protection contre les codes malveillants

12.2.1 Mesures contre les codes malveillants

12.3 Sauvegardes

12.3.1 Sauvegarde des informations

12.4 Journalisation et surveillance

12.4.1 Rapport d’audit

12.4.2 Protection des informations journalisées

12.4.3 Journal administrateur et journal des opérations

12.4.4 Synchronisation des horloges

12.5 Mesure relative aux logiciels en exploitation

12.5.1 Installation des logiciels sur des systèmes en exploitation

12.6 Gestion des vulnérabilités techniques

12.6.1 Gestion des vulnérabilités techniques

12.6.2 Restrictions relatives à l’installation des logiciels

12.7 Prises en compte de l’audit du système d’information

12.7.1 Contrôles de l’audit du système d’information

13. Sécurité des télécommunications

13.1 Gestion de la sécurité des réseaux

13.1.1 Mesures sur les réseaux

13.1.2 Sécurité des services réseau

13.1.3 Cloisonnement des réseaux

13.2 Transfert des informations

13.2.1 Politiques et procédures de transfert des informations

13.2.2 Accords de transfert

13.2.3 Messagerie électronique

13.2.4 Engagements de confidentialité ou de non-divulgation

14. Acquisition, développement et maintenance

14.1 Exigences de sécurité applicables aux systèmes d’information

14.1.1 Analyse et spécification des exigences de sécurité

14.1.2 Sécuriser les services applicatifs sur les réseaux publics

14.1.3 Protection des transactions de services applicatifs

14.2 Sécurité en matière de développement et d’assistance technique

14.2.1 Politique de développement sécurisé

14.2.2 Procédures de contrôle des modifications

14.2.3 Réexamen technique des applications après modification de la plateforme d’exploitation

14.2.4 Restrictions relatives à la modification des progiciels

14.2.5 Procédures de développement du système

14.2.6 Environnement de développement sécurisé

14.2.7 Externalisation du développement

14.2.8 Tests de sécurité du système

14.2.9 Tests d’acceptation du système

14.3 Données d’essai

14.3.1 Protection des données d’essai

15. Relation avec les fournisseurs

15.1 Sécurité dans les relations avec les fournisseurs

15.1.1 Politique de sécurité de l’information avec les fournisseurs

15.1.2 Sécurité dans les accords conclu avec les fournisseurs

15.1.3 Informations et télécommunications dans la chaîne d’approvisionnement

15.2 Gestion de la prestation de service par un fournisseur

15.2.1 Surveillance et réexamen des services d’un fournisseur

15.2.2 Gestion des modifications dans les services d’un fournisseur

16. Gestion des incidents liés à la sécurité de l’information

16.1 Gestion des incidents liés à la sécurité de l’information

16.1.1 Responsabilités et procédures

16.1.2 Signalement des événements

16.1.3 Signalement des failles

16.1.4 Evaluation et prise en compte des évènements

16.1.5 Réponse aux incidents

16.1.6 Exploitation des incidents déjà survenus

16.1.7 Collecte de preuves

17. Aspects de la sécurité de l’information en matière de gestion de la continuité de l’activité

17.1 Continuité de la sécurité de l’information

17.1.1 Planification de la continuité de la sécurité de l’information

17.1.2 Mise en œuvre de la continuité de la sécurité de l’information

17.1.3 Vérifier, réexaminer et évaluer la continuité de la sécurité de l’information

17.2 Redondance

17.2.1 Disponibilité des moyens de traitement de l’information

18. Conformité

18.1 Revue de la sécurité de l’information

18.1.1 Revue indépendante de la sécurité de l’information

18.1.2 Conformité avec les politiques de sécurité et les standards

18.1.3 Contrôle de la conformité technique

18.2 Conformité avec les exigences légales et contractuelles

18.2.1 Identification de la législation en vigueur

18.2.2 Droits de propriété intellectuelle

18.2.3 Protection des enregistrements de l’organisme

18.2.4 Protection des données et confidentialité des informations relatives à la vie privée

18.2.5 Réglementation relative aux mesures cryptographiques

19. Bibliographie

La première directive oblige l’opérateur à notifier, aux autorités nationales compétentes, toute perte de confidentialité (vol, perte, divulgation d’informations), et sauf cas exceptionnel jugé d’utilité publique, les personnes physiques concernées ne seront pas informés.

NB: en France, une proposition de Loi élaborée au Sénat au mois de novembre 2009 propose que la CNIL puisse être l’autorité recueillant ces notifications.

La seconde directive impose, au delà de l’information de l’autorité nationale, une communication éclairée des personnes physiques (les véritables victimes donc). Les données concernées doivent être “sensibles” (à caractère personnel) et la perte de confidentialité doit avoir un impact sur la vie privée des personnes.

Ce nouveau cadre juridique a été initialement présenté comme le moyen d’élaborer des recommandations en matière de sécurité à l’échelle Européenne (en consolidant les statistiques des différentes autorités nationales), il permet aussi de se mettre en phase avec le reste du monde, et notamment les USA qui appliquent depuis 2002 une obligation de notification de ce type d’incident de sécurité (les organisations des secteurs financier et santé sont particulièrement visés).

Aux USA, il existe une exception : les organisations ne notifient pas les pertes de confidentialité si les données avaient été chiffrées. Le cadre juridique européen reprend cette exception en précisant qu’un opérateur n’a pas obligation de notifier ses failles de sécurité, s’il a mis en place des moyens de rendre incompréhensibles ses données, et que ces moyens ont été validés par une autorité nationale compétente. En France, l’ANSSI serait probablement l’entité la mieux placée pour cette validation, puisqu’elle délivre depuis longtemps des labels de sécurité aux produits informatiques, et tout particulièrement pour des matériels et logiciels de chiffrement.

Toujours aux USA et dès ce mois de Février 2010, de nouvelles règles du Health Insurance Portability and Accountability Act (HIPAA) sont applicables en cas de perte de confidentialité des données de santé (PHI Protected Health Informations) :

• obligation d’informer directement chaque personne concernée dans les 60 jours suivant l’incident (en cas de difficulté à joindre les personnes concernées : obligation de diffuser l’information sur un site Web ou par voie de presse dans les 90 jours)
• si l’incident concerne plus de 500 personnes, le HHS (département de la santé de l’administration américaine) doit également être notifié (il publiera aussi l’information sur son site Web)

A noter que toutes les organisations devront maintenir un journal détaillé de leurs incidents et le fournir annuellement au HHS.

Les impacts liés à l’information publique sur des failles de confidentialité : perte d’image, perte financière (souvent plus importants aux USA : les class actions deviennent monnaie courante) obligeront sans doute de nombreuses organisations publiques et privées à se préoccuper vraiment de la sécurité de nos informations personnelles.

Le principe consistant à tenter de cacher les incidents de sécurité de son SI (ou de masquer les failles d’un logiciel, fusse-t-il en licence commerciale) est à mon sens, et sera toujours une mauvaise idée. Pour autant, l’obligation de notification d’un incident de sécurité reste une mesure prise a posteriori.

Il faut revenir aux fondamentaux : implémenter quelques mesures techniques permettent de limiter l’impact des menaces qui pèsent sur les informations à caractère personnel :

• des informations chiffrées n’ont pas le même intérêt (voire plus du tout) à être volées ou divulguées que si elles sont conservées “en clair”
• une tentative d’usurpation d’identité avec des informations volées ou divulguées n’a pas la même probabilité de réalisation si ces dernières sont vérifiées de façon pertinente par le système à qui on les présente

J’aurai l’occasion de revenir sur l’intérêt et les modalités du chiffrement des données de santé ainsi que sur les mécanismes d’identification et d’authentification (des PS et des patients).

PS : le site datalossdb.org, opéré par l’Open Security Foundation, référence quelques pertes, vols ou divulgations potentielles d’informations à caractère personnel (en tous cas celles ayant été portées à la connaissance du public…)

Mise à jour/complément du 25/01/2011 :
http://www.enisa.europa.eu/media/les-notifications-de-violation-de-donnees-en-europe-un-nouveau-rapport-de-l2019agence-europeenne

Ce nouveau document donne un aperçu de la norme 27001 (notamment par une introduction à la notion de SMSI : système de management de la sécurité des informations) et du vocabulaire ad-hoc.

On y trouvera les définitions de termes couramment usités tels que par exemple : évaluation de risques, analyse de risques, disponibilité, intégrité, confidentialité ou encore actif et actif informationnel.

Elle est disponible gratuitement < ici >

Pour mémoire, la norme 27001 est aujourd’hui de plus en plus adoptée, et d’ailleurs préconisée en France par le Référentiel Général de Sécurité (RGS). Elle décrit en effet, comment mettre en place un SMSI qui permet d’améliorer de façon continue la sécurité des systèmes d’informations : CQFD.

Il est y précisé que désormais l’hébergement de données de santé à caractère personnel concerne aussi les données sur support papier.

Texte actuel de l’article 1111-8

Si cette disposition permettra plus facilement aux établissements d’externaliser leurs archives papier, cela implique toutefois que les prestataires spécialisés dans l’archivage papier devront se conformer au décret sur l’hébergement de données de santé, et donc se soumettre à la procédure d’agrément.

Le référentiel de constitution des dossiers de demande d’agrément paru en Mars 2009 leur est donc opposable.

A noter, que le consentement du patient est toujours un pre-requis à l’hébergement, on imagine alors les quelques soucis à pouvoir externaliser les archives qui engorgent actuellement les hôpitaux.

Voici le début de l’article 1111-8 du CSP tel qu’il devrait être publié dans les prochains jours :

” Les professionnels de santé ou les établissements de santé ou la personne concernée peuvent déposer des données de santé à caractère personnel, recueillies ou produites à l’occasion des activités de prévention, de diagnostic ou de soins, auprès de personnes physiques ou morales agréées à cet effet. Cet hébergement de données, quel qu’en soit le support, papier ou informatique, ne peut avoir lieu qu’avec le consentement exprès de la personne concernée.

Les traitements de données de santé à caractère personnel que nécessite l’hébergement prévu au premier alinéa, quel qu’en soit le support, papier ou informatique, doivent être réalisés dans le respect des dispositions de la loi n° 78-17 du 6 janvier 1978 relative à l’informatique, aux fichiers et aux libertés. La prestation d’hébergement, quel qu’en soit le support, fait l’objet d’un contrat. Lorsque cet hébergement est à l’initiative d’un professionnel de santé ou d’un établissement de santé, le contrat prévoit que l’hébergement des données, les modalités d’accès à celles-ci et leurs modalités de transmission sont subordonnées à l’accord de la personne concernée.

Les conditions d’agrément des hébergeurs des données, quel qu’en soit le support, sont fixées par décret en Conseil d’Etat pris après avis de la Commission nationale de l’informatique et des libertés et des conseils de l’ordre des professions de santé. Ce décret mentionne les informations qui doivent être fournies à l’appui de la demande d’agrément, notamment les modèles de contrats prévus au deuxième alinéa et les dispositions prises pour garantir la sécurité des données traitées en application de l’article 34 de la loi n° 78-17 du 6 janvier 1978 précitée, en particulier les mécanismes de contrôle et de sécurité dans le domaine informatique ainsi que les procédures de contrôle interne. Les dispositions de l’article L. 4113-6 s’appliquent aux contrats prévus à l’alinéa précédent.”

A l’heure du SaaS, du green computing et de la télé médecine, stocker des données sur du papier puis les faire héberger, c’est plutôt cocasse !

Comme je l’ai écrit dans le précédent billet, la norme 27799 comporte à mon sens une redite de la norme 27001 (même si les auteurs s’en défendent dès l’introduction du document).

Ainsi, en ce qui concerne le “plan d’actions pratique pour la mise en œuvre de la 27002″, on y lit que la conformité à l’ISO 27002 peut être garantie par la mise en place d’un SMSI (Système de Management de la Sécurité des Informations) et que “si possible” ce SMSI respectera les recommandations des points 6.2 à 6.7 de la 27799 et que vous seriez aussi inspirés de lire les exemples de son annexe B.
Autrement, cela revient à dire: “mettez en place un SMSI tel que défini dans l’ISO 27001, et vous serez conformes aux bonnes pratiques et à l’expérience internationale”.

Là où il y a une volonté, il y a un chemin (…d’amélioration continue)
Lénine

L’enjeu et les bénéfices attendus d’une telle organisation mérite bien une petite explication.

La mise en œuvre d’un SMSI, à l’instar d’un système qualité, est avant tout un projet transversal à tout ou partie des activités de l’organisation: on parle alors du “périmètre” du système.
En santé, le périmètre peut être par exemple, un service ou un département d’un centre hospitalier, un cabinet médical, la branche prévoyance/santé d’une entreprise d’assurance ou encore les services d’un hébergeur de données de santé.
Quel que soit son périmètre, le projet SMSI implique une mobilisation de la hiérarchie de l’organisation: la direction générale et/ou médicale ainsi que l’ensemble des employés impliqués dans les activités du dit périmètre (personnels soignants ou non).

Le SMSI vise à atteindre des objectifs (fixés notamment par une politique) en mettant en place des mesures organisationnelles et techniques (comme celles de la 27799 et 27002), puis à conserver et améliorer le niveau atteint.

Les systèmes de management (SMSI, ou SMQ pour la qualité) fonctionnent selon un processus d’amélioration continue nommé PDCA (Plan, Do, Check, Act) encore appelé roue de Deming, et dont les étapes peuvent être traduites en français par Planifier, Déployer, Contrôler et Agir.
Vous devez tant que faire ce peu, mettre en œuvre ce modèle cyclique à chaque niveau du SMSI.

Les phases de mise en place du SMSI comprennent par ailleurs:
- l’appréciation des risques
- la sélection de mesures de sécurité ad hoc (ici, celles de la 27799 notamment)
- les activités transverses telles que la gouvernance et la documentation du système
- la sensibilisation du personnel
- le suivi du système par le biais d’indicateurs et d’audits internes.

On ne gouverne jamais une nation contre ses habitudes
Louis XVI

La norme 27799 recommande la mise en place d’un forum de management de la sécurité des informations (FMSI).
Ce forum, idéalement formé par l’extension d’un comité existant dans l’organisation, est de représentation mixte (membres des fonctions médicales et administratives ou technologiques). Ce processus unique de gouvernance (simplification du pilotage, réduction des coûts) doit permettre de garantir l’existence d’une politique et d’un soutien clairs de la direction.

Ce n’est plus souvent que la perte de choses qui en enseigne la valeur
Schopenhauer

Lorsque l’on parle de sécurité des informations, il ne s’agit pas seulement de protéger les données informatiques, mais toutes les informations ayant de la valeur pour l’organisation, et quel que soit leur support ou leur mode de transmission : écrits papier, connaissances et savoir-faire. On parle plus généralement d’actifs informationnels.

S’agissant d’informations dites personnelles, je rappelle que dans la Loi française n°78-17 du 6 Janvier 1978, il s’agit de toute information relative à une personne physique identifiée ou qui peut être identifiée, directement ou indirectement, par référence à un numéro d’identification ou à un ou plusieurs éléments qui lui sont propres.
Le chapitre 3 de la norme 27799 précise lui, qu’une information personnelle de santé est “une information relative à la santé physique ou mentale d’un individu identifiable ou à la prestation de services de santé”, ce qui inclut donc ainsi les informations sur les personnes identifiables et impliquées dans la prise en charge du dit individu : les professionnels de santé.

Voici quelques exemples d’actifs ou de supports d’informations: planning de rendez-vous, logiciel d’anonymisation, bâtiment des archives, échographe, ordonnancier, dictaphone, personnel du bureau des admissions, films radiologiques, compte-rendu de consultation, cassettes de sauvegarde, cartes CPS, base de données des rapprochements d’identités, routeur pare-feu, plan de soins, étiquettes patient, emails, système de traçabilité du matériel stérile.

Vous aurez à choisir un niveau de granularité adapté à l’importance de votre périmètre, toutefois de façon générale l’actif à identifier sera plutôt l’information en elle même que son support.

NB : La norme 27799 ne fournit pas de listes d’actifs types (pas plus que la 27002 d’ailleurs), et c’est logiquement à vous qu’il revient d’élaborer l’inventaire de vos biens informationnels.

Ensuite, et ici décrit de façon très générique, l’appréciation des risques consiste à évaluer la vraisemblance du risque et son coût – en matière de perte d’intégrité, de disponibilité ou de confidentialité – qui pèse sur un actif et ce en fonction de ses vulnérabilités et des menaces qui pèsent sur lui.

Je trouve dommage que le document fasse exclusivement référence à la norme ISO 13335-3 alors que la récente norme ISO 27005 (dont la publication a d’ailleurs précédée celle de l’ISO 27799) est sans doute aujourd’hui le meilleur référentiel en la matière, notamment parce qu’elle reprend les exigences exprimées dans la 27001 et qu’elle fusionne le meilleur des méthodes utilisées jusqu’à lors : l’ISO 13335, mais aussi Octave, Mehari ou encore EBIOS.

L’obligation de subir nous donne le droit de savoir
Jean Rostand

Une fois les risques identifiés, vous aurez à sélectionner tout ou partie de mesures de sécurité ad hoc. L’ISO 27799 préconise l’implémentation de plusieurs mesures de sécurité, dont 25 sont obligatoires comme :
- Ecraser de façon sécurisée ou détruire tous les supports d’informations lorsqu’ils ne sont plus utilisés,
- Séparer les équipements de développement, d’essai et d’exploitation,
- Sécuriser et rendre infalsifiable les informations journalisées,
- Garantir l’identification univoque des patients et être capable de fusionner des identités multiples.

En revanche on ne trouve aucune obligation en ce qui concerne l’usage de messagerie électronique, le chiffrement (des informations de santé stockées ou sauvegardées).

A noter qu’en France, le projet d’arrêté pris en application de l’article R1110-1 du CSP sera à considérer comme une exigence réglementaire dans la politique de votre SMSI et nécessitera l’implémentation de mesures de sécurité pour répondre aux règles obligatoires du décret (parmi la cinquantaine actuellement retenue). Ce décret rend obligatoire l’usage de la carte CPS pour tout accès par des PS à des données personnelles de santé, ce qui nécessite évidemment de sélectionner les mesures de sécurité du chapitre 11 “Contrôle d’accès” de l’ISO 27002 ou le point 7.8 dans l’ISO 27799.
A noter que, et sous réserve de la publication de sa version définitive, l’application du décret reste “limitée” au seul critère de confidentialité  (rien à propos de l’intégrité ou de la disponibilité des informations médicales) et concerne exclusivement des supports électroniques: à suivre donc.

N’admettez rien a priori si vous pouvez le vérifier
Kipling

Il possible de mettre en place un SMSI basé sur les recommandations du chapitre 6 de l’ISO 27799 ou directement (et idéalement à mon avis) sur le référentiel ISO 27001, sans vouloir nécessairement viser sa certification : l’important étant d’augmenter la fiabilité de votre organisation.
Cf. mon billet précédent pour les conditions de la certification.

Pour autant, la mise en œuvre d’un SMSI impose de formaliser des processus et des indicateurs ; il devient alors utile de mesurer l’adéquation entre la réalité et ce qui a été spécifié : on parle d’audits internes ou externes, ces derniers audits ayant pour objectif de vérifier la conformité du SMSI à la norme pour l’obtention de sa certification.

La certification permet finalement d’apporter la confiance en votre SMSI aux différentes parties prenantes : les patients, les autorités de tutelle, l’opinion publique, et le personnel bien entendu (on peut même lire dans la norme 27799 que “l’approche cohérente de la sécurité de l’information [...] améliorera le moral des employés” !)

En conclusion

L’ISO 27799 apporte un bon éclairage sur la notion d’informations de santé personnelles à ceux qui ne connaissent pas ce domaine.
En revanche, pour celles et ceux qui officient déjà dans le contexte (professionnels de santé, RSSI ou personnel des DSI d’hôpitaux ou cliniques, etc.) et au delà de l’intérêt d’une référence commune de mesures de sécurité obligatoires, cette norme tient plus d’un guide de prise en main pour implémenter la norme ISO 27001 et l’ISO 27002 qui lui est déjà associée.
Il me semble que les normes dites d’application “sectorielle” sont comme les lois: on devrait déjà s’assurer de mettre en œuvre celles qui existent, et de n’en créer d’autres que si l’on est assuré de leur efficacité.

Depuis plusieurs années, la continuité et la qualité des soins reposent de plus en plus sur les systèmes d’informations. La sécurité de ces systèmes, et souvent des informations de santé personnelles, est devenue un enjeu crucial notamment en raison de l’augmentation de leur traitement informatique et du nombre d’échanges entre professionnels.

La norme internationale ISO 27799:2008 (“Gestion de la sécurité de l’information relative à la santé en utilisant l’ISO/CEI 27002″) parue en juin dernier, propose des recommandations pour la mise en oeuvre de mesures de sécurité adaptées aux organisations de soins et autres dépositaires de données personnelles de santé. Elle peut donc intéresser des établissements de soins, des réseaux de santé ou des hébergeurs.

C’est pendant l’année 2002 qu’un groupe de travail Australien a proposé l’adaptation de la norme ISO 17799:2000 au domaine de la santé, cette norme étant à l’origine de l’ISO 27002.
Le lancement du projet de norme 27799 n’a donc pas attendu, comme l’ai souvent lu sur le Web, l’avènement des projets Google Health ou Microsoft Healthvault ; d’autant qu’un projet de norme ISO met généralement au moins quatre ans avant d’arriver au stade publication.

Le référentiel ISO 27799 a été créé pour répondre aux exigences de sécurité des informations de santé et finalement pour répondre aux objectifs liés à la prise en charge du patient : assurer sa sécurité, le respect de sa vie privée et l’efficacité des soins médicaux qui lui sont apportés.

La norme reprend les critères classiques “DICA” (Disponibilité, Intégrité, Confidentialité et Auditabilité) comme les objectifs majeurs en matière de protection des informations de santé, et ce quelle que soit la taille, le mode de fonctionnement ou la localisation de l’organisation concernée.

En théorie, et par exemple en France, cette norme peut donc être mise en œuvre par des hébergeurs nationaux du Dossier Médical Personnel ou par un hôpital local.

NB: l’intégrité des informations n’étant pas synonyme de qualité de ces dernières, tout objectif d’assurance qualité des données (à protéger) a été logiquement exclu du domaine d’application de cette norme.

Comme son nom l’indique, la 27799 s’appuie sur un autre référentiel normatif, l’ISO 27002:2005, qui est un “catalogue” de bonnes pratiques en matière de sécurité des informations. Lorsque l’on utilise l’ISO 27002 seule, l’implémentation de ses mesures de sécurité reste facultative: on sélectionne celles qui correspondent aux actifs et risques préalablement identifiés.

Certaines mesures de l’ISO 27002 ont été jugées essentielles dans le domaine de la santé. C’est pourquoi l’ISO 27799 reprend plusieurs dispositions, parmi les 11 thèmes de l’ISO 27002, afin de les rendre obligatoires ou d’en préciser la mise en oeuvre. l’ISO 27799 ajoute par ailleurs des objectifs non présents dans la 27002.

La norme ISO 27001:2005, qui décrit la façon d’opérer un Système de Management de la Sécurité des Informations (SMSI), bien que non indispensable (malheureusement) à la mise en place des dispositions de l’ISO 27799, y est citée notamment pour ses principes d’amélioration continue de la sécurité. J’y reviendrai dans la suite de ce (long) billet.

NB: contrairement à une idée reçue, la seule mise en oeuvre de la norme ISO 27002 ou ISO 27799 ne peut pas faire l’objet d’une certification ! C’est la vérification de conformité à la norme 27001 qui peut être effectuée, et ce par un audit du système complet de management : audit de certification du SMSI.

Enfin, il faut rappeler qu’en France le GMSIH avait retenu l’ISO 27799 (à l’époque encore au stade pré-norme) dans l’étude pour l’élaboration de la déclinaison du référentiel général d’interopérabilité (RGI) et la démarche d’élaboration des référentiels de Santé (thème n°5 “Sécurité”).

• Organisation du document

Les chapitres 1 et 2 comprennent l’introduction, quelques généralités et les références normatives (en fait une seule, l’ISO 27002).
Le vocabulaire et les termes spécifiques sont explicités dans les chapitres 3 et 4, quant au chapitre 5, il précise les notions de sécurité de l’information de santé.

La “substantifique moelle” se trouve finalement dans les deux chapitres suivants : le chapitre 6, qui décrit la mise en pratique de l’ISO 27002 et le chapitre 7 qui liste les mesures de sécurité essentielles pour le domaine de la santé.

Trois annexes informatives (A à C) clôturent le document :
La première décrit les menaces générales pesant sur les informations de santé, la seconde décrit les activités et documents propres au SMSI et la dernière énumère quelques avantages à tirer d’un outillage pour la mise en œuvre de la norme (élaboration de bases de données pour l’analyse de risques ou la gestion de la déclaration d’applicabilité, etc.)

• Premier constat

La norme est intéressante pour ses préconisations quant au contexte de mise en œuvre: gouvernance mixte médical/administratif (forum de management ISMF, etc.) et sur les adaptations d’implémentation des mesures de sécurité.

Mais à part celà, je me dit qu’ils auraient pu l’intituler “ISO 27001 pour les nuls …du monde de la santé”.
En effet, pourquoi ainsi faire du cycle d’amélioration continue et de l’appréciation des risques une simple redite informative de ce qui déjà décrit, imposé et appliqué dans d’autres domaines avec la norme ISO 27001 ?
Pourtant, nombre de DSIO ou RSSI d’hôpitaux et cliniques sont capables de mettre en oeuvre la 27001 et de façon tout à fait optimisée à leur contexte !

PS: je suis déçu de la traduction française, car elle est approximative et discutable à de nombreux endroits du document, par ailleurs quelques coquilles grammaticales et orthographiques subsistent. Cela peut sembler un peu mesquin, mais pour une norme internationale à 168 euros les 63 pages, on peut s’attendre à un minimum de rigueur. Je conseille donc d’opter directement (ou en cas de doute) pour la version écrite dans la langue de Shakespeare.

La suite dans le prochain billet…

Depuis 2007 des offres SaaS apparaissent pour le monde de la Santé : gestion de dossiers médicaux de spécialités voire de gestion complète de cabinet médical, SIR, PACS et même jusqu’à d’ambitieux projets de SIH complets.

Aujourd’hui les offres SaaS évoluent, et du coup la définition du “S” pour “Software” gagne en précision sémantique : Il s’agit moins de fournir des applications intégrées voire monolithiques que de fournir, à la demande, des composants (intégrant fonctions et données) répondant à des besoins basiques ou spécifiques et généralement sans IHM (sans l’interactivité utilisateur).

Amazon WS, Google Apps ou encore eBay ont déjà ouvert la voie en mettant à disposition des services Web qui, s’ils permettaient initialement d’exposer les fonctionnalités de leur propre business, offrent désormais des fonctions de base pour le traitement des informations (stockage, indexation, gestion de files de messages, etc.).
On parle même de HaaS (Hardware as a Service) pour un service comme Amazon Elastic Compute Cloud qui fourni des machines virtuelles (qui n’est d’ailleurs pas sans rappeler la location de temps machine sur les mainframes).

Les architectures orientées services (SOA) permettent de simplifier l’implémentation et l’évolutivité des processus métier du SI par une mise en œuvre de composants réutilisables (les services).
Dans le domaine des systèmes d’informations de santé (SIS), l’intégration des informations et l’interopérabilité sont des objectifs majeurs, la SOA est un bon moyen d’assurer rapidement l’évolution et l’adaptation d’un SIS aux contraintes réglementaires et aux nouvelles gouvernances régulièrement mises en œuvre pour améliorer notre système de Santé.

Pourquoi dès lors, ne pas imaginer de bâtir un SIS orienté services dont certains d’entre eux seraient déployés en mode SaaS. Ces services étant développés, testés, maintenus et sécurisés par un fournisseur garantissant un niveau de service ad-hoc (SLA), ils pourraient même aller jusqu’à constituer les composants du cœur même du SIS.

Le déploiement SaaS pourrait par ailleurs donner un petit coup de pouce à l’avènement de nombreux projets SOA dont les mises en œuvre sont souvent longues et complexes, même s’il faut rappeler qu’une SOA ne résout déjà pas – à elle seule – les problématiques existantes d’un SI (performances insuffisantes en production, évolutions poussives des implémentations existantes, etc.).

Ainsi, je pense qu’il sera possible de trouver à moyen terme des offres SaaS pour des implémentations de tout ou partie des profils d’intégration IHE par exemple (ou de tout autre type de services à valeur ajoutée basé sur les standards ayant cours : HL7, ISO, etc.).
La modélisation des composants (services applicatifs et fonctionnels) et des processus métiers de la SOA pourra avantageusement s’appuyer sur les caractéristiques des profils IHE : homogénéité des profils, fonctions communes entre profils, identification précise des rôles, des acteurs et des transactions, interfaces techniques basées sur les standards Web services.

Un SIS pourra par exemple, mixer l’usage des services PIX/PDQ (d’un fournisseur spécialisé dans les composants de gestion d’identités patients) avec les services plus “techniques” (CT, ATNA) managés par un autre fournisseur. Ce même SIS disposera de son propre entrepôt XDS mais utilisera le registre (partagé par d’autres entités d’un même domaine) géré par un dernier fournisseur SaaS (spécialisé dans l’indexation).

La mise en place d’un SI composé de services déployés en mode SaaS nécessitera une attention toute particulière sur les engagements du fournisseur en matière de disponibilité et de continuité de service. Les problèmes récents (juillet et août 2008) rendant les services Google Mail, Docs et Apps indisponibles pendant près d’une heure donne une idée des risques actuels (même avec les poids lourds de l’Internet) et de leur impact dans le domaine des affaires …ou de la santé: pouvez vous (encore) imaginer votre DMP sur Google Health ?

Les fournisseurs SaaS spécialisés en santé (en France, nécessairement agréés “hébergeurs de données de santé”) assureraient en priorité l’amélioration continue de la qualité et de la sécurité, et plus classiquement le provisionning et le suivi de la facturation. Le support et la maintenance seraient assurés directement (fournisseur & éditeur) ou en collaboration étroite avec des éditeurs tiers.

A noter que, au delà de la disponibilité, les autres critères de sécurité (intégrité, confidentialité et auditabilité) applicables à l’exploitation de ces services seront particulièrement cruciaux pour les SIS.

En conclusion, les services SaaS utilisés par des SIS conçus en SOA permettraient aux établissements médicaux et autres réseaux de santé de se doter – avec des investissements raisonnables et maîtrisés – de systèmes d’informations interopérables et évolutifs.
Charge aux éditeurs et aux hébergeurs de prendre le virage SOA et SaaS.