FAQ de l'offre : Ségur du numérique en santé

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 2 heures dans tous les cas.

Le numéro RRPS doit être utilisé lorsqu’il existe. Lorsqu’il n’existe pas et qu’un autre numéro national est disponible, l’utilisation de cet autre numéro est tolérée. 

Les preuves demandées sont de la documentation spécifique, une attestation sur l'honneur selon l'exigence, ainsi que le formulaire du test d'intrusion dans le cadre de l'exigence SC.SSI/GEN.18 (Profil AHI uniquement*). Elles permettent de vérifier que les processus en question sont bien mis en œuvre et conformes à une démarche SSI.

*Pour les autres solutions du couloir médico-social, le test d'intrusion est porté par l'exigence SC.PSC.14 dans le cadre de l'homologation Espace de Confiance ProSantéConnect.

Il est demandé qu’une fréquence de sauvegarde des données soit prévue dans la documentation, mais aucune fréquence n’est définie pour cette exigence.  
Il convient à chaque éditeur de définir ce qui est acceptable au regard du contexte d’utilisation de sa solution.   
Selon l’ANSSI, une stratégie de sauvegarde doit notamment tenir compte de la perte de données maximale admissible (PDMA) et de la durée maximale d’interruption admissible (DMIA) définies pour l’ensemble des valeurs métier du SI de l’entité (applications, données). 

Le test d'intrusion concerne toutes les solutions, incluant les applications web et mobiles, les clients lourds de trois tiers ou plus et les clients lourds inférieurs à trois tiers. Le guide d'utilisation propose une classification explicite à travers un logigramme : une application est considérée comme web si elle fonctionne sur un serveur web ou est accessible via un navigateur. En revanche, si elle est spécifiquement conçue pour les appareils mobiles, elle est classée comme une application mobile. Si aucune de ces catégories ne s'applique et qu'une installation locale est nécessaire, elle est alors répertoriée comme un client lourd. Deux types de clients lourds sont à distinguer : un client lourd est qualifié de trois tiers ou plus s'il intègre un serveur d'application par lequel transitent tous les flux, sinon il est considéré comme moins de trois tiers.

Exception : Si un type d'architecture est dédié à une partie de l'application ne traitant aucune donnée personnelle ou de santé (par exemple : la partie mobile pour la commande en rayon), il n'est pas nécessaire de remplir un formulaire.

Si l’utilisation des macros était bloquée pour des raisons de sécurité, nous recommandons à l’auditeur de se mettre dans un environnement sécurisé afin de les exécuter (VM, docker ou station isolée du SI). 

Les auditeurs issus d'entreprises qualifiées PASSI possèdent les compétences nécessaires pour réaliser des tests d'intrusion sans nécessiter de scénario de test prédéfini. L'ANS reconnaît leur légitimité pour mener à bien ces audits et prendre des décisions éclairées. 
De plus, si l'auditeur a des questions, il a la possibilité de les soumettre à l'ANS pour obtenir des éclaircissements. 
L'audit s'effectue en collaboration entre l'éditeur et l'auditeur. En cas de doutes ou de questions, il est fortement recommandé de discuter directement avec votre auditeur, notamment lors des phases de cadrage et reporting, afin d'assurer la clarté et la compréhension mutuelle du processus.

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.

La phase de test implique la réalisation de tests en boîte grise, où l'auditeur dispose d'informations préalables, ainsi que la réalisation de compléments en boîte noire, où l'auditeur agit sans informations préalables dans le but de repérer les failles et d'obtenir une évaluation exhaustive de la sécurité de l'application. Cette phase dure en moyenne 3 à 4 jours.

La clause de revoyure permet d'avoir un engagement de la part de l'auditeur pour tester de nouveau les exigences non validées lors du test d'intrusion et d'effectuer un contre-audit afin de vérifier si les mesures de sécurité nécessaires ont été mises en œuvre.