FAQ des industriels

Deux enjeux majeurs sont associés à la mise en œuvre de l’IGC-Santé :  

• assurer la sécurité des clés privées et des certificats émis par l’ANS : il faut veiller à limiter l’accès à ces clés privées et qu’elles ne puissent pas être dupliquées ni installées sur plusieurs équipements ;
• assurer la continuité de service : de nombreuses applications de santé utilisaient les certificats émis par les deux anciennes IGC-CPS, qui ne sont plus actives depuis Janvier 2021. Elles doivent prendre en compte les nouveaux certificats émis par l’IGC-Santé.

En plus, les certificats émis par l’IGC-Santé respectent les règles habituelles de sécurité (analyse de risque, politique de sécurité), les "Politiques de Certification", et ils sont conformes aux référentiels de la PGSSI-S.

L'Infrastructure de Gestion des Clés cryptographiques (IGC) opérée par l'ANS (IGC-Santé) délivre des certificats conformes au référentiel d'identification à la Politique Générale de Sécurité des Systèmes d’Information de Santé (PGSSI-S) pour l’accès aux services du numérique en santé (article L1470-1 et suivants du Code de la Santé Publique).

Les certificats émis par l'ANS permettent d'identifier les acteurs du secteur, personnes physiques et organisations. Ils attestent aussi de la qualité des pratiques de gestion des clés publiques mises en œuvre par ces autorités. Ils peuvent être révoqués en cas de défaillance.

L’ANS propose 4 offres de certificats logiciels : 

• certificat de personne morale Organisation ;
• certificat de personne morale Serveur ;
• certificat de personne physique Professionnel ;
• certificat de personne physique Professionnel de Santé .

Afin de vous familiariser avec les notions et les cadres de la e-santé, l'ANS met à disposition des entreprises les ressources suivantes, consultables en toute autonomie : 

• Une plateforme de formation : plateforme ouverte à tous (professionnels du secteur santé, usagers, étudiants, industriels…) proposant des contenus de formation qui abordent toutes les dimensions de la e-santé : le cadre règlementaire, les grands programmes nationaux, les référentiels et services socles, etc.
• Le guichet G_NIUS : guichet national de l’innovation du numérique en santé, fruit d’un travail collectif entre la délégation ministérielle au numérique en santé (DNS) et l’agence du numérique en santé (ANS) pour orienter, informer, mettre en relation l’ensemble des acteurs de la e santé, faciliter l’innovation et valoriser les réussites de terrain, notamment autour de 4 thèmes : 
  • Financement,
  • Réglementation,
  • Ecosystème,
  • Programmes nationaux.
• Les enregistrements des webinaires dispensés par l'ANS sur l'ensemble des thématiques d'expertise de l'Agence
• Des fiches synthétiques : fiches descriptives mises à disposition par l'équipe Innovation sur 7 sujets clés de la e-santé, déclinés en sous-thématiques : 
  • Interopérabilité,
  • Services socles et référentiels,
  • Conformité réglementaire,
  • Stratégie nationale,
  • Sécurité des SI,
  • Europe et international,
  • Référencement des SI.

L'offre d'accompagnement de l'ANS pour les entreprises innovantes du numérique en santé est structurée autour de 3 piliers : 

• Sensibilisation : ce pilier propose des sessions collectives ayant pour but de présenter des sujets généraux (INS, Pro Santé Connect, le référencement Mon Espace Santé, etc.), de donner une visibilité sur les évolutions et les contraintes réglementaires, et principalement de répondre aux questions des innovateurs sur les sujets d’expertise de l’ANS. Les actions menées capitalisent par ailleurs sur les contenus déjà mis à disposition par l’ANS, comme les webinaires thématiques sur le site de l’ANS, ou les contenus de e-learning de la plateforme de formation. Ce pilier repose également sur des productions spécifiques comme les fiches synthétiques qui ont vocation à servir de point d’entrée à tout acteur innovant sur chacune des thématiques d’expertise. 
• Animation : ce pilier se base sur l'organisation d’évènements formels et informels permettant de mettre en contact les experts de l’ANS et les acteurs innovants, sur des newsletters pour pousser de l'information générale (sessions organisées, actualités) auprès de l'écosystème , et sur l'animation de communautés thématiques pour répondre aux questions des innovateurs.
• Soutien et orientation : ce pilier vise à bien comprendre le positionnement et les besoins des entreprises au travers de sessions de "deep-dive" afin de personnaliser l'accompagnement de l'ANS, d'appuyer de manière spécifique les acteurs au travers de sessions thématiques individuelles selon le besoin, ou encore de soutenir plus largement les acteurs de l'écosystème sur des thématiques communes fortes au travers de meets-ups startups ou d'évènements d'envergure (type projectathon).

Le test doit être daté de moins d'un an.

Le mode d'hébergement est pris en compte au niveau des exigences SSI ainsi que des points de contrôle du test d'intrusion dans le cas où un industriel ou un tiers sous sa responsabilité assure l'hébergement de tout ou partie des composants du système, ou fournit tout ou partie du système sous forme de service (SaaS).
En revanche, les OS ne sont pas pris en compte dans les exigences SSI.

Le choix du responsable de la sécurité dépend de la structure de l'éditeur. Cela implique d'identifier les personnes qui ont les compétences et l'expertise pour prendre en charge la sécurité de la solution. Il peut s'agir de responsables sécurité, de développeurs sécurité expérimentés, d'architectes sécurité, etc.

La désignation des personnes responsables de la sécurité des produits nécessite les étapes suivantes :
- Identifier les exigences spécifiques de votre produit en matière de sécurité ;
- Évaluer les compétences et l'expérience des membres de votre équipe ;
- Désigner les responsabilités en matière de sécurité en fonction des compétences des membres de l'équipe ;
- Formaliser ces responsabilités dans les rôles et responsabilités de l'équipe.

Des recommandations sur la désignation des responsabilités en matière de sécurité sont fournies dans diverses ressources, notamment le guide d'hygiène de l'ANSSI, la PGSSI-S de l'ANS et la norme ISO 27002. 

La désignation d'acteurs responsables de la sécurité apporte plusieurs avantages, notamment :

• Une meilleure gestion des risques de sécurité ;
• Une responsabilité claire pour les problèmes de sécurité ;
• Une amélioration de la coordination des activités de sécurité ;
• Une sensibilisation accrue à la sécurité au sein de l'équipe de développement ;
• Une conformité aux normes de sécurité.

La négligence dans la désignation des responsables de la sécurité peut entraîner un certain nombre de risques, notamment :

• Des failles de sécurité non détectées ;
• Des retards dans la réponse aux incidents de sécurité ;
• Un manque de coordination dans la gestion des risques ;
• Une faible sensibilisation à la sécurité au sein de l'équipe.

L'exigence a pour objectif de vérifier si une sensibilisation générale aux enjeux et aux risques à la SSI est menée auprès des équipes du système (équipes de conception, de développement, d'installation, d'exploitation, d'administration, de maintenance, de support, etc.). Il est préconisé d'effectuer cette sensibilisation à minima annuellement pour l'ensemble des équipes et pour chaque nouvel arrivant. Cette sensibilisation peut être effectuée par des équipes de l'éditeur ou des prestataires qu'il choisit librement.
Dans le cas où le système est destiné à traiter des données à caractère personnel, alors la sensibilisation doit intégrer des obligations légales (en particulier le règlement général sur la protection des données) ainsi que des réglementations applicables.

La responsabilité de la rédaction du plan d'assurance sécurité du système peut être partagée entre l'éditeur et l'hébergeur ou le fournisseur de services SaaS, en fonction des accords contractuels. Cependant, il est essentiel que ce plan soit clairement et doit contenir : 

• Le cadre juridique : les références légales, les réglementations et les obligations contractuelles liées à l'hébergement du système, en précisant les responsabilités et les droits des parties impliquées, etc. ;
• Les mesures de sécurité : les dispositions et les procédures de sécurité mises en place pour protéger le système hébergé (ex: contrôles d'accès, protection des données, etc.) ;
• Les engagements entre l'hébergeur et la structure utilisatrice comme par exemple des garanties de disponibilité, des délais de réponse en cas de problème, des mesures de résilience en cas de panne, etc. ;
• L'environnement de mise en œuvre du système : il s'agit de décrire l'environnement technique et opérationnel dans lequel le système doit être déployé (ex: configuration réseau, connectivité, etc.). 

Un "standard de développement sécurisé" est un ensemble de lignes directrices, de bonnes pratiques que les développeurs devraient suivre pour garantir la sécurité d'un système. Il peut provenir de différentes sources (ex : guide de l'ANSSI, documentation interne, OWASP, PGSSI-S, etc.). Il comprend des recommandations sur la vérification de la qualité du code, la gestion de l'obsolescence des bibliothèques, la sécurisation de la plateforme système, et bien d'autres aspects liés à la sécurité. Il est essentiel car il permet de réduire les vulnérabilités potentielles, les failles de sécurité et les risques de cyberattaques, assurant ainsi la sécurité du système.

La réalisation d’un audit PASSI (conditions de réalisation spécifiques et auditeur certifié PASSI) n’est pas requise. La seule obligation est de faire réaliser le test d'intrusion par un organisme qualifié PASSI (Liste des prestataires de services qualifiés).

NB : Le lien est susceptible de changer si l'ANSSI y apporte des modifications à posteriori.

La veille technologique concerne les composants du système tels que les bibliothèques, les logiciels, les dépendances, etc.

La responsabilité de garantir le bon fonctionnement de ces processus et de veiller à l'application en temps opportun des correctifs repose sur l'équipe ou la personne chargée de la sécurité informatique de votre système.