FAQ des industriels

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.

Les principaux objectifs de la procédure de sauvegarde et de restauration sont de garantir la disponibilité des données essentielles en cas de défaillance du système, de perturbation ou de perte de données.
Cette procédure contribue à la sécurité des solutions en minimisant les risques de perte de données critiques. Elle permet de restaurer rapidement et efficacement les systèmes à un état de fonctionnement antérieur, réduisant ainsi les temps d'indisponibilité et les impacts potentiels sur la sécurité et la continuité des opérations.

La procédure de sauvegarde et de restauration doit contenir des informations détaillées sur la manière de réaliser des sauvegardes efficaces, ainsi que sur la manière de restaurer les données en cas de besoin. Cela peut inclure :

• Les acteurs de la procédure de sauvegarde et de restauration et leur rôles (RACI) ;
• La fréquence de sauvegarde ;
• Le plan de sauvegarde mis en place par l'éditeur ;
• Le champ d'application (périmètre de la sauvegarde) ;
• Le lieu de stockage des sauvegardes ;
• Les méthodes de sauvegarde (ex: sauvegardes complètes, incrémentielles ou différentielles)
• Les règles de sécurité : les mesures de sécurité sont mises en place pour protéger les sauvegardes (ex: chiffrement des données, l'accès restreint aux sauvegardes,etc.) ;
• Les tests de récupération (champ des tests, fréquence, etc.) 

Les preuves demandées sont majoritairement de la documentation spécifique à chaque exigence, une attestation sur l'honneur, ainsi que le formulaire du test d'intrusion en particulier pour l'exigence SC.SSI/GEN.18. Elles permettent de vérifier que les processus en question sont bien mis en œuvre et conformes à une démarche SSI.

Pour être évaluées, les preuves doivent être déposées sur Convergence dans un conteneur ZED garantissant l'intégrité et la confidentialité des documents. Ces preuves sont consultées par les vérificateurs uniquement.

Cette exigence permet à la fois de s'assurer que le professionnel sera effectivement en mesure de s'authentifier (ou de récupérer son compte) le moment venu, et de renforcer la sécurité de l'authentification.
En effet :

• Si par exemple le professionnel commet une erreur à la saisie de son numéro de téléphone portable et que ce numéro est utilisé pour lui envoyer un code OTP par SMS comme second facteur d'authentification, alors le professionnel ne recevra pas cet OTP au moment de son authentification et ne pourra pas se connecter. Le professionnel va demander une modification de cette coordonnée, mais à ce moment-là il faudra s'assurer de son identité de manière fiable, avec deux facteurs d'authentification. Ceci peut devenir contraignant et constituer une très mauvaise expérience pour un nouvel utilisateur ;
• Si le professionnel commet une erreur à la saisie d'une adresse email utilisée comme second facteur d'authentification en cas d'oubli de son mot de passe par exemple, alors il découvrira ce problème le jour où il a besoin de récupérer son compte. Déjà en situation exceptionnelle et de perte de temps, le professionnel ne pourra pas récupérer son compte facilement et devra alors passer par une vérification fiable mais contraignante de son identité.
  La vérification permet de s'assurer que la coordonnée est bien exacte et sous la maîtrise du professionnel. De plus, ceci évite la tentation de demander le contournement des mesures de sécurité pour répondre à des situations problématiques et urgentes, prétextes justement utilisés par des attaquants pour prendre possession illégalement d'un compte. 

Lorsque les coordonnées d'un professionnel sont récupérées dans un annuaire comme le RPPS ou le RPPS+ (considéré comme un "autre système en amont"), les coordonnées sont supposées fiables et leur vérification n'est pas demandée dans la gestion du compte.

Afin de vérifier l'exactitude d'une adresse email, il y a deux grands types de méthode :

• envoyer un code numérique ou alphanumérique (lettres majuscules et chiffres) sur l'adresse email, et demander au professionnel de saisir cette valeur dans un formulaire ;
• envoyer un lien unique (URL générée spécifiquement pour ce cas d'usage) sur l'adresse email, et déclencher la validation de cette adresse email lorsqu'une connexion est ouverte sur l'URL transmise.

Afin de vérifier l'exactitude d'un numéro de téléphone, il est généralement envoyé un code numérique de 4 ou 6 chiffres par SMS sur ce numéro et le professionnel doit le ressaisir dans un formulaire.

Cette vérification doit avoir lieu au moment de la création du compte ou de la modiifcation de la coordonnée. En l'absence de vérification effective, la coordonnée ne pourra pas être utilisée car étant potentiellement invalide.

Il peut sembler inutile d'envoyer une notification sur une coordonnée (adresse email, numéro de téléphone) que le professionnel veut justement abandonner. Ceci permet toutefois, en cas d'usurpation d'identité, de prévenir le professionnel légitime qu'une coordonnée a été modifiée à son insu (il pourra alors demander une fermeture des accès et une nouvelle modification).

De plus, dans tous les cas, le professionnel retrouvera de manière précise sur cette ancienne coordonnée, utilisée sur une période donnée, la date de bascule vers sa nouvelle coordonnée.

Lorsqu'une nouvelle instance d'un logiciel ou d'un service est déployée, il faut que les mesures de restriction relatives à l'authentification par mot de passe seul soient en place sans nécessiter de configuration spécifique. Cela n'interdit pas de pouvoir modifier cette configuration, par exemple là où le référentiel d'identification électronique ne s'applique pas. Cependant, ceci évite les non-conformités lorsqu'aucune action de configuration n'est effectuée après installation / restauration d'une solution.

La solution doit permettre de respecter les exigences en termes de robustesse des mots de passe attendues dans les exigences et cela doit être paramétré ainsi dans la configuration par défaut.

En revanche, il n’est pas interdit qu’un paramétrage plus permissif soit possible (par exemple le produit n’est pas nécessairement commercialisé qu’en France). C’est alors de la responsabilité de l’établissement de santé si celui-ci fait volontairement baisser la robustesse du mot de passe. L’éditeur ne saurait être tenu pour responsable dans ce cas.

Lorsque le moyen d'authentification comprend deux facteurs, l'exigence ne s'applique pas mais ceci ne dispense pas pour autant de mettre en place des mesures contre les attaques par force brute. Par exemple, si le second facteur a été compromis (l'attaquant reçoit par exemple les OTP d'authentification), il ne faut pas permettre des tentatives répétées de soumission de mot de passe sans limite. Le responsable du moyen d'authentification doit alors mettre en œuvre des mesures identiques ou alternatives à celles prévues par l'exigence pour le cas de l'authentification par mot de passe seul.

Le délai est à définir au cas par cas par le responsable du service numérique. Il doit être assez court pour limiter les possibilités d'accès au système par un tiers mais assez long pour ne pas forcer inutilement des authentifications intempestives.

Le compromis doit être établi en fonction des risques et des contraintes opérationnelles propres au service. La durée d'inactivité provoquant la déconnexion automatique ne devrait pas pouvoir dépasser quelques dizaines de minutes dans tous les cas.