Les ressources mises à disposition pour la réalisation du test d'intrusion sont le formulaire du test d'intrusion et le guide d'utilisation.

• Le formulaire du test d'intrusion comprend des contrôles de sécurité classés en deux catégories selon leur niveau de gravité (haute ou moyenne), et qui concernent soit tous les types d'application, soit un type d'application spécifique (application web, application mobile, client lourd 3 tiers ou plus et client lourd inférieur à 3 tiers).
• Le guide d’utilisation du formulaire du test d'intrusion fournit une vue d'ensemble détaillée des éléments nécessaires à la réalisation d'un test d'intrusion. Il couvre chaque phase du test, en tenant compte des rôles distincts de l'éditeur et de l'auditeur. Le guide fournit également des informations sur la classification des applications, ainsi que des définitions et des précisions sur certains points de contrôle du formulaire.

Le périmètre du test d’intrusion doit être parfaitement cadré pour limiter les impacts sur l’application ou le système d’information. Ainsi, la prestation doit être réalisée de préférence sur un environnement « iso-prod » (tel qu’un environnement de développement, de test, etc.) plutôt que sur un environnement de production.

Le test d’intrusion est applicable pour toutes les solutions passant le référencement Ségur V2, dans le cadre de l'homologation à l'Espace de Confiance ProSantéConnect (exigence SC.PSC.14). Cette exigence stipule que le système doit faire l’objet d’un test d’intrusion réalisé par un prestataire d’audit (PASSI) à la charge de l’éditeur (audit PASSI non exigé). Le prestataire d'audit remplit un formulaire confirmant la conformité du système aux critères de sécurité requis. Ce formulaire est une preuve essentielle à fournir et doit démontrer l'éligibilité du système au référencement. De plus, il doit être daté de moins d'un an et être signé électroniquement par le prestataire ayant réalisé l'audit.

Le référentiel d'identification électronique annule et remplace au 1er juin 2022 trois référentiels de la PGSSI-S :

• Le référentiel d’identification des acteurs sanitaires et médico-sociaux v1.0 ;
• Le référentiel d’authentification des acteurs de santé v2.0;
• Le référentiel des autorités de certification éligibles pour l’authentification publique dans le secteur de la santé v2.0.

Les exigences découlent du référentiel d’identification électronique qui a été rendu opposable par arrêté ministériel conformément au code de la santé publique, Art. L. 1470-1. à Art. L. 1470-6 (arrêté du 28 mars 2022). Il fait partie de la Politique Générale de Sécurité des Systèmes d’Information en Santé (PGSSI-S).
Le respect du référentiel d'identification électronique engage dès lors la responsabilité des responsables de traitement assujettis à ce référentiel. En particulier, la Commission Nationale de l'Informatique et des Libertés (CNIL) peut diligenter des audits et sanctionner les établissements pour un défaut d'application du référentiel d'identification électronique.

Les différents volets du référentiel d'identification électronique peuvent être récupérés sur le site de publication de la PGSSI-S par l'ANS.

Les preuves requises consistent en des captures d'écran ou des séquences vidéo illustrant les mesures de gestion des comptes d'utilisateurs, la connexion et la déconnexion au système.

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.

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.

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.

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 leurs 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 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 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.

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

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.
La liste des prestataires de services qualifiés peut être retrouvée ici : https://cyber.gouv.fr/decouvrir-les-solutions-qualifiees

NB : Le lien ci-dessus est susceptible de changer si l'ANSSI y apporte des modifications a posteriori.

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.).