1

§ Le référentiel de sécurité du SNDS imposé par l’article 193 de la Loi de modernisation de notre système de santé : il s’applique à l’ensemble des systèmes mettant à disposition des données du SNDS.

§ Il garantit que l’accès aux données protège la confidentialité et l’intégrité des données, la traçabilité des accès et des autres traitements

§ Il impose :- la pseudonymisation ;- l’authentification forte ; - la traçabilité ; - le contrôle ;- la sensibilisation et la formation.

Référentiel Sécurité du SNDS

2

Référentiel Sécurité du SNDS

Portail accès SNDSPortail accès SNDS

3

Les conditions d’accès au SNDS pour l’utilisateur bénéficiant d’un accès au portail :

• L’utilisateur doit avoir suivi les formations pré-requises préalablement à l’attribution de droits d’accès aux données du SNDS

• L’utilisateur doit être habilité :- pour les accès permanents, par l’autorité d’enregistrement de son organisme- pour les accès sur projet, par la Cnam (dans le cadre de la convention avec le

responsable du traitement du projet)

• L’utilisateur doit signer les CGU qui formalisent 1. l’engagement individuel de l’utilisateur au respect des conditions d’accès aux données :

- le respect des finalités d’utilisation autorisées et interdites du SNDS,- l’absence d’action visant la ré identification,- l’obligation de ne diffuser que des données anonymes,- l’engagement du respect du référentiel.

2. les conditions d’utilisation du portail et des services associés

Référentiel Sécurité du SNDS

4

L’utilisateur a interdiction de sortir du portail SNIIRAM / SNDS des données non anonymes du SNDS

§ Qu’est ce que l’anonymat ? Il ne doit pas être possible, à partir des données, de déduire ou revenir à une information personnelle sur un individu. Travaux en cours pour préciser les critères définissant des données anonymes.

§ Quelques bonnes pratiques : - ne pas restituer de petits effectifs,- ne pas sortir les identifiants potentiels,- ne pas sortir d’identifiants de séjours ou de personnes- ne pas sortir des données qui permettraient, en les croisant, d’en déduire l’identité

de la personne

Référentiel Sécurité du SNDS

5

Système fils : étapes (version synthétique)

Demande d’autorisation(dossier complet)

Centralisation des élémentsetOrientation CEREES

Validation du traitement- Conformité à la loi- Sécurité jugée suffisante

Soumet sa requêteTransmet le dossier

completSignent la convention

Exploite les données

Met à disposition les données

Initie des contrôles / audits

Responsable traitement (RT) INDS CNIL

RT RT et Cnam

Cnam

RTComité audit

6

Systèmes fils : homologation (1/2)

L’analyse de risques à mener dépasse le cadre du référentiel de sécurité : ne pas oublier par exemple deconsidérer les risques liés à la disponibilité ou à l’intégrité des données lors de l’alimentation.

nPré-requis : chaque gestionnaire de systèmes du SNDS élargi doit apporter la preuve du respect des règles du référentiel de sécurité du SNDSè Chaque système du SNDS élargi doit être homologué

1. Réalisation d’une analyse de risques2. Réalisation d’une étude d’impacts sur la vie privée3. Mise en œuvre des mesures de couvertures des risques4. Recette et tests pour s’assurer de la bonne couverture des risques5. Homologation sécurité sur le périmètre considéré6. Suivi opérationnel de la sécurité du SI

L’homologation permet à un responsable, en s’appuyant sur l’avis des experts, de s’informer et d’attester aux utilisateurs du système d’information que les risques qui pèsent sur eux, sur les informations qu’ils manipulent et sur les services rendus, sont connus et maîtrisés.

La démarche d’homologation vise à trouver un équilibre entre le risque acceptable et les coûts de sécurisation puis de faire arbitrer cet équilibre, de manière formelle, par un responsable qui a autorité pour le faire.

La démarche d’homologation doit s’intégrer dans le cycle de vie du système d’information. L’homologation doit être revue au maximum tous les 3 ans.

7

Système fils : homologation (2/2)

Définir le SI Référentiel réglementaire, périmètre (fonctionnel, technique, géographique, physique). Doit correspondre à celui de l’analyse de risques conduite

Définir la démarche Définir les enjeux de sécurité du système et la profondeur de la démarche à mettre en œuvre

Identifier les acteurs Définir les rôles et obligations des acteurs qui participent à l’homologation

Organiser le dossier Inventorier le contenu du dossier d’homologation et définir le planning de la démarche

Conduire l’analyse Mener l’analyse de risques sur le périmètre défini et identifier les mesures à mettre en œuvre

Contrôler Contrôler l’exactitude de l’analyse de risque et la bonne application des mesures à travers des audits et des contrôles

Définir un plan

d’actionsDéfinir et mettre en œuvre un plan d’actions pour amener les risques identifiés qui demeurent

(risques résiduels) à un niveau acceptable

Concrétiser Le responsable du traitement du système recevant atteste de la réalisation d’une analyse de risques et de sa prise en compte

Réviser Révision périodique de l’homologation planifiée

9 étapes d’une homologation

8

Réf. de sécurité : territorialité, externalisation, classificationTe

rrito

rialit

é

Ø Identifier où sont stockées les donnéesØ Où elles sont restituées.

Si hors de France, à préciser lors de la demande d’accès. Si hors de l’UE, accord spécifique de la CNIL à obtenir.

L'hébergement des données est-il réalisé sur le territoire européen ?Autrement, est-il réalisé dans un pays reconnu par la Commission Européenne comme "offrant

un niveau de protection des données suffisant" ?Autrement, un accord spécifique de la CNIL a-t-il été obtenu ?

La problématique de la territorialité est-elle incluse dans l'analyse de risques conduite ?La problématique de la territorialité est-elle incluse dans le PIA réalisé ?

Exte

rnal

isat

ion

Transfert d'activités d'un organisme vers un prestataire externe. Peut provoquer des failles.

Ø Analyse de risques : intégrer les risques inhérentsØ Dans le contrat, déterminer la responsabilité de

chaque partie au regard des mesures à mettre en œuvre.

Ø S’assurer de la bonne mise en œuvre du référentiel de sécurité du SNDS chez les partenaires du sous-traitant

Tout ou partie d'un système élargi du SNDS est-il prévu d'être externalisé ?

L'analyse de risques tient-elle compte de cette situation ? Risques liés, localisation des données, traitement de DCP, choix techniques du prestataire, interventions à distance, hébergement mutualisé

?

Un encadrement contractuel de l'externalisation avec le partenaire est-il réalisé ?Le tiers s'engage-t-il sur le respect des règles du référentiel de sécurité du SNDS et sur les référentiels

associés (PGSSI-S, PSSI MCAS, RGS, etc.) sur le périmètre externalisé ?Des modalités d'audits et de contrôles de sécurité ont-elles été définies?

Par défaut : bases brutes du SNDS sont « à fort risque »Ø Analyse d’impact sur la vie privée dont les

risques en cas de diffusion ou d’altérationØ Revue à chaque ajout de nouvelle donnée et à

chaque appariement

L'analyse de risques a-t-elle permis de classifier le jeu de données manipulé ?Quelles informations le jeu de données permet-il de connaître ?

Peut-on dévoiler une pathologie discriminante ?Le jeu de données est-il échantillonné et si oui, à quel taux ?

Le risque d'une ré-identification publique est-il élevé ?Est-il prévu de revoir la classification à chaque ajout de nouvelles données ?

Est-il prévu de revoir la classification à chaque nouvel appariement ?Clas

sific

atio

n

9

Réf. Sécurité : sensibilisation, sauvegardes et archivesLe gestionnaire devra présenter le nombre de personnes séances et de personnes sensibilisées

Parmi les thèmes de la sensibilisation :Ø Objectifs et enjeux en matière de SSI,Ø Nature et sensibilité des données manipulées,Ø Utilisation possible des données,Ø Les conséquences d’une mauvaise utilisation,Ø Moyens participant à la SSI,Ø Règles, consignes et bonnes pratiques SSIØ La responsabilité de la personne en cas de comportement répréhensible,Ø L’existence de trace des actions réalisées par la personne et la finalité de ces

traces

Sensibiliser les utilisateurs ET les administrateurs

Obligation de formation des utilisateurs ET des administrateurs

Des actions de sensibilisation ont-elles été menées vers les utilisateurs du système ?Des actions de sensibilisation ont-elles été menées vers les administrateurs du système ?Des formations ont-elles été dispensées aux utilisateurs du système ?Des formations ont-elles été dispensées aux administrateurs du système ?Les actions de sensibilisation et de formation portent-elles sur l'utilisation des données ?Les actions de sensibilisation et de formation portent-elles sur les conséquences en cas de mauvaise utilisation ?Les actions de sensibilisation et de formation portent-elles sur les bonnes pratiques ?Les actions de sensibilisation et de formation portent-elles sur leur responsabilité ?Les actions de sensibilisation et de formation portent-elles sur l'utilisation de traces ?

Sens

ibilis

atio

nAr

chiv

age

et s

auve

gard

es

Sauvegardes :Ø S’assurer qu’elles sont dans l’analyse de risques comme mesure et comme

actif à protégerØ Définir un plan de sauvegardeØ Réaliser régulièrement des tests de restauration (min : annuellement)Ø Journaliser l’ensemble des opérations de sauvegardeØ Prévoir une exploitation des sauvegardes à chaque changement de

technologie

Archives : Ø S’assurer qu’elles sont dans l’analyse de risques comme mesure et comme

actif à protégerØ Prendre garde à la longévité des supports d’archivesØ Tracer la consultation des archivesØ S’assurer de la purge

Les données sauvegardées sont-elles soumises au référentiel de sécurité du SNDS ?Les données archivées sont-elles soumises au référentiel de sécurité du SNDS ?Un plan de sauvegarde a-t-il été défini ?Des procédures de restauration sont-elles formalisées ?A quelle fréquence les tests de restauration sont-ils réalisés ?Avez-vous prévu que les données sauvegardées restent lisibles le temps de leur durée légale de conservation ?Avez-vous prévu que les données archivées restent lisibles le temps de leur durée légale de conservation ?L'accès aux archives est-il tracé ?Les sauvegardes et les archives sont-elles considérées comme un actif à protéger dans l'analyse de risques conduite ?A quelle fréquence les contrôles de bonne purge des archives sont-ils prévus ?

10

Référentiel sécurité : hors prod, système fils, exports

Les données de prod. ne peuvent pas être utilisées sur des environnements hors prod. sauf si le présent référentiel est appliqué sur lesdits environnements

Ø Dresser l’inventaire des environnements pouvant contenir des données de production

Ø S’assurer que l’analyse de risques intègre cette problématique et que les réponses sont conformes au référentiel de sécurité.

Pour chaque environnement : Des données de production sont-elles utilisées sur l’environnement donné ?

Si oui, le référentiel de sécurité est-il appliqué sur cet environnement ?La suppression des données des environnements hors production est-elle prévue et contrôlée à l'issue

de la mise en place du système ?

Hors

pro

duct

ion

Cons

titut

ion

d’un

sys

tèm

e hé

ritie

r (sy

stèm

e pe

tit fi

ls)

L’exportation de jeux de données non anonymes d’un système du SNDS (…) doit se faire uniquement si le destinataire respecte, avant la mise à disposition, le présent référentiel.Cette exportation doit se faire dans le cadre d’une convention (…)

La demande de création du système héritier a-t-elle suivi le processus de création d’un système fils ?Le destinataire des données respecte-t-il le référentiel de sécurité ?

Une convention a-t-elle été conclue avant la fourniture des données ?Des moyens de contrôle sont-ils prévus dans cette convention ?

Une procédure d’exportation (données identifiées, manière de les transporter…) est-elle définie ?Un engagement sur les modalités de transfert sécurisé des données est-il conclu ?

Un engagement sur le respect des règles du référentiel de sécurité SNDS et des référentiels associés est-il conclu ?

Seules des données anonymes peuvent être exportéeshors du SNDS élargi.Les données non anonymes doivent être protégées par un chiffrement adapté.Les administrateurs avec des droits d’exportation de jeux de données doivent être en nombre limité, identifiés et voir leurs habilitations contrôlées régulièrement.

Des jeux de données non anonymes sont-ils prévus d'être exportés sur un réseau non maîtrisé ?Si oui, une analyse de risques spécifique a-t-elle menée pour s'assurer de leur sécurisation ?

Combien d'administrateurs disposent des droits d'exportation de jeux de données ?Sont-ils clairement identifiés ?

A quelle fréquences leurs habilitations sont-elles contrôlées ?

Expo

rtatio

ns

11

Référentiel de sécurité : accès aux donnéesL'accès aux jeux de données du SNDS des utilisateur est il limité dans le temps ?Les personnes accédant à des données non anonymes sont-elles soumises au secret professionnel ?Un processus décrit-il la mise à disposition des accès, après validation de l'autorité hiérarchique ?Les utilisateurs et administrateurs se sont-ils engagés à s'assurer de la confidentialité des données et traitement ?Les utilisateurs et administrateurs se sont-ils engagés à ne pas mettre en œuvre des actions visant la réidentification ?Les utilisateurs et administrateurs se sont-ils engagés à respecter les règles du référentiel de sécurité du SNDS ?Les finalités interdites du SNDS ont-elles été rappelées aux utilisateurs et aux administrateurs ?Les utilisateurs et administrateurs se sont-ils engagés à ne pas poursuivre une des finalités interdites du SNDS ?Des sanctions adéquates ont-elles été prévues en cas de non respect de ces engagements ?Les utilisateurs et les administrateurs ont-ils été informés de ces sanctions ?Les droits d'accès aux ressources sont-ils accordés en tenant compte du besoin d'en connaître ?Les droits d'accès aux ressources sont-ils accordés en tenant compte du respect du moindre privilège ?Les droits d'accès aux ressources sont-ils accordés suite à la mise en œuvre d'une gestion fine des profils d'accès ?

L’accès aux données doit être : Ø Limité dans le temps,Ø Avec des utilisateurs soumis au secret professionnel,Ø Possible après validation du supérieur hiérarchique,Ø Réalisée après que les accédant se soient engagés de manière opposable à

q Engagement de confidentialité,q Absence d’actions visant à la réidentification,q Engagement de respect des règles du référentiel de sécurité,q Engagement de ne pas poursuivre une finalité interdite

Des sanctions pénales en cas de non respect doivent être prévues et communiquées aux utilisateurs, administrateurs et gestionnaires de système.

Ces engagements doivent prendre la forme de signature de Conditions Générales d’Utilisation (a minima aussi contraignantes que celles pour l’accès au SNDS par le portail de la Cnam).

Un processus d’habilitation doit être défini, mis en œuvre et contrôlé.La revue des habilitations doit être réalisée au moins annuellement.

Accè

s au

x do

nnée

sM

odal

ités Ø Les exigences en terme de disponibilité doivent être définis,

Ø Les données non anonymes doivent être stockées dans un environnement maîtrisé,

Ø L’accès aux données doit se faire depuis un poste respectant les exigences de la PSSI-MCAS,

Ø Les administrateurs ne doivent pas avoir accès à Internet depuis les environnements d’administration du SNDS

Ø Identification locale ou nationale d’une personne morale ou physiqueØ Authentification forte

Les exigences de disponibilité au système ont-elles été fixées ?L'accès aux données non anonymes du SNDS est-il réalisé dans un environnement

maîtrisé ?Les postes qui permettent l'accès à cet environnement respectent-ils les exigences de la

PSSI MCAS ?Des mesures sont-elles prises pour empêcher un utilisateur de sortir des données de cet

environnement maîtrisé ?Les administrateurs ont-ils accès à Internet depuis les environnements d'administration

du SNDS élargi ?Quel type d’identification est-il mis en œuvre ?

L'accès aux données nécessite-t-il une authentification forte?Les identifiants utilisés sont-ils différents de ceux des comptes définis par défaut par les

éditeurs de logiciels ?Les comptes par défaut sont-ils désactivés ?

Plusieurs utilisateurs peuvent-ils partager le même compte ?

12

Référentiel sécurité : pseudonymisation, traçabilité

Ø Les identifiants individuels des bénéficiaires stockés dans un des systèmes du SNDS élargi ne peuvent être que des pseudonymes

Ø Seul le tiers de confiance national doit être en mesure de reconstituer les identités des bénéficiaires à partir d’un ensemble de pseudonymes

Ø Les pseudonymes des bénéficiaires doivent être différents d’un système du SNDS élargi à l’autre

Ø Supprimer le secret de pseudo quand il n’est plus utile aux traitements

Ø Prévoir le renouvellement de la pseudonymisationØ Prévoir des procédures en cas de compromission

Les pseudonymes des bénéficiaires sont-ils différents entre les systèmes du SNDS élargi ?Le pseudonyme est-il obtenu par une opération cryptographique irréversible sur un identifiant ?

Le pseudonyme est-il non signifiant et ne permet pas d'identifier directement le bénéficiaire concerné ?

Le gestionnaire de système dispose-t-il à la fois de l'ensemble des données à caractère personnel ayant servi à générer le pseudonyme et le pseudonyme généré ?

Le tiers de confiance gère-t-il des données du SNDS ?Le tiers de confiance dispose-t-il des fonctions de pseudonymisation ?

Dans le cas d’un système héritier, le secret utilisé pour la pseudonymisation a-t-il été supprimé ?Qui possède le secret ayant permis la pseudonymisation du jeu de données ?

A quelle fréquence le renouvellement du pseudo est-il planifié ?Des procédures permettant de modifier la pseudo existent-elles ?

Pseu

dony

mis

atio

n

Des traces doivent être disponibles pour contrôler l’usage des données et doivent pouvoir être instruites en justice avec un caractère probant.

Les traces doivent être : - Fonctionnelles- Techniques- Scellées quotidiennement- Être restituées et utilisables même par des non

spécialistes- Réconciliables entre elles

Les traces doivent permettre une imputation individuelle

La journalisation doit s’inscrire dans la convention

Les traces sont un actif à protéger

Les traces mises en oeuvre permettent-elles de contrôler l'utilisation de données ?Les traces mises en œuvre disposent-elles d'un caractère probant et peuvent-elles être instruites

en justice ?Les traces permettent-elles de gérer dans le temps les identités, les rôles et les habilitations ?

Les traces sont-elles quotidiennement scellées ?L'outil de gestion de la preuve permet-il de réconcilier les traces autant que de besoin ?

Des traces techniques provenant d'au moins un composant du système d'information sécurisé (SIS) sont elles en place ?

Les traces portent-elle sur les accès ?Les traces portent-elle sur les sorties ?

Les traces portent-elle sur les exportations de données ?Les traces portent-elle sur les appariements ?

Les traces portent-elle sur les opérations d'administration ?Les traces portent-elle sur les requêtes ?

Les traces sont-elles conservées dans le respect des textes encadrant le traitement de données à caractère personnel ?

Une référence commune de temps est-elle employée au sein du système ?

Traç

abili

té

13

Référentiel sécurité : surveillance, incidents

La fréquence d’analyse des comportements anormaux est définie dans le cadre de l’analyse de risques.Les comportements anormaux portent entre autre sur : Ø Temps de réponse du système,Ø Elévation de privilèges,Ø Sortie de données non autorisées,Ø Accès non autorisé aux ressources du SNDS,Ø Modification anormale de données sources,Ø Volume sorti trop important

D’autres comportements peuvent être contrôlés au regard de l’analyse de risque.

Des scénarios ont-ils été préidentifiés pour exploiter les traces ?Le temps de réponse du système est-il surveillé ?

L'élévation de privilèges est-elle surveillée ?La sortie de données non autoritsées est-elle surveillée ?

L'accès non autorisé à une ressource du SNDS est-il surveillé ?Le volume de sortie des données est-il surveillé ?

La fréquence d'analyse des traces a-t-il été défini dans le cadre de l'analyse de risques menée ?D'autres comportements suspects ont-ils été identifiés à travers l'analyse de risques ?

Surv

eilla

nce

Ø Procédure de suivi et de remontée des incidents à définir

Ø Collecte des preuves à prévoir

Ø Information de la Cnam à convenir dans le cadre de la convention

Une procédure de gestion de détection des incidents est-elle en oeuvre ?Une procédure de remontée des incidents est-elle en œuvre ?une procédure de traitement des incidents est-elle en œuvre ?

Un tableau de suivi des incidents est-il tenu à jour ?A quelle fréquence ce tableau de suivi des incidents est-il revu pour intégrer d'éventuels nouveaux

risques / mesures mises en œuvre à l'analyse de risques conduite ?Les canaux de notification d'incidents vers le gestionnaire de système central (la CNAMTS) sont-ils

définis ?

Ges

tion

des

inci

dent

s

14

- Contrôle & sanctions

- Les habilitations doivent être régulièrement revues.

- Le SNDS élargi sera périodiquement contrôlé par la CNIL et le comité d’audit (mais également Cour des comptes, ANSSI, IGAS …)

- En cas de non respect des conditions d’utilisation des données, des sanctions adéquates peuvent être prononcées, notamment la suspension de l’accès aux données pour tout l’organisme.

- La rupture du secret professionnel est pénalement sanctionnée.

Référentiel Sécurité du SNDS