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

Dans le cadre du processus de consultation de documents KOS par la fonction consommatrice d'un logiciel DRIMBox, tel que défini au sein de la spécification projet DRIMBox, le premier acteur impliqué est le LPS initiant une requête d’appel contextuel. Dans ce cadre, le LPS est responsable de la qualification de l’intégralité des traits INS en amont de la construction de la requête d’appel contextuel émise à destination du logiciel DRIMBox. Ainsi, les traits d'identité INS qui sont réceptionnés par le logiciel DRIMBox peuvent être considérés comme « fiables ». 
A partir du contenu associé à la requête d'appel contextuel reçue, la fonction consommatrice du logiciel DRIMBox est en mesure d’interroger l'environnement DMP afin de déterminer quels documents d’intérêt doivent être présentés à l’utilisateur au sein de son IHM (Cf. transaction TD3.1 définie au sein du Guide d'Intégration DMP). 
A l'issue de cette première interaction avec l'environnement DMP, le logiciel DRIMBox récupère un certain nombre de métadonnées associées au contexte de publication du document d’intérêt. C’est uniquement à partir de cette étape que l'interface de consultation du logiciel DRIMBox peut être constituée (pour plus de précisions, se référer à l'exigence DB.CO.54 de la spécification projet DRIMBox). 
Les métadonnées récupérées par la fonction consommatrice du logiciel DRIMBox auprès de l'environnement DMP peuvent elles-mêmes être considérées comme « fiables » car résultant d’un contexte de publication du document KOS construit à partir de l’analyse d’un compte-rendu d’imagerie, lui-même issu d’une demande d’acte d’imagerie remplie par un professionnel de santé.
Ainsi, l’ensemble du processus aboutissant à l’affichage des informations au sein de l’IHM de la DRIMBox consommatrice permet de conserver une cohérence avec celles saisies initialement lors de la planification de l’examen d’imagerie du patient.

Dans le cadre d'une demande de consultation d'un document KOS par un professionnel de santé depuis l'interface du logiciel DRIMBox, ce dernier doit tout d'abord contrôler la consentement du patient à une telle opération (information véhiculée au travers du paramètre "InformationEtConsentement" mentionné au sein de la requête d'appel contextuel provenant du LPS). Ensuite, le logiciel DRIMBox doit  initier une transaction permettant d'effectuer un test d'existence du DMP et de récupérer les conditions d'accès à celui-ci (transaction TD0.2 mentionnée au sein du Guide d'Intégration DMP). Enfin, et si cela s'avère nécessaire, le logiciel DRIMBox doit ajouter une autorisation du professionnel de santé pour la consultation de ce DMP (pour plus de précisions à ce sujet, se référer à la transaction TD0.3 définie au sein du Guide d'Intégration DMP).

Pour DRIMBOX, la plaquette commerciale ou tout autre document décrivant le périmétre fonctionnel que couvre votre solution logicielle est recevable. L'objectif étant de vérifier que votre solution logicielle répond au périmétre fonctionnel du dispositif choisi.

Pour toute question relative à Pro Santé Connect (PSC) ou sur l'espace de confiance PSC, veuillez-vous référer à la FAQ dédié.

Pour toute question relative à Pro Santé Connect (PSC) ou sur l'espace de confiance PSC, veuillez-vous référer à la FAQ dédié.

Le scénario SSI/IAM.92.01 relatif aux preuves de conformité sur la gestion des mots de passe a fait l'objet d'une évolution.

Afin d’harmoniser les exigences sur l’ensemble des couloirs, le scénario modifié s’applique désormais à tous les éditeurs qui candidatent sur les guichets RIS et DRIMBox.

Qu’est-ce qui change concrètement ?

Le scénario précédent pour RIS et DRIMbox prévoyait un blocage du compte après 5 échecs de changement de mot de passe.
Désormais, conformément au scénario harmonisé, il faut :

• Réaliser une tentative de connexion erronée répétée,
• Mettre en évidence le blocage du compte après un nombre d’échecs consécutifs au plus égal à 10 (et non plus après 5 échecs de changement de mot de passe).

Le scénario attendu est le suivant : Scénario de conformité : SSI/IAM.92.01

Vérifier la mise en place d'une politique de mots de passe robuste pour les comptes à privilèges
 

Etapes du scénario :

1. Se connecter avec un compte à privilège dont la durée de validité a été dépassée
2. Mettre en évidence que le système impose à l'utilisateur un changement de son mot de passe
3. Effectuer une tentative de changement de mot de passe à l'aide d'un mot de passe ne respectant pas la limite de 15 caractères
4. Mettre en évidence le refus du changement de mot de passe
5. Effectuer une tentative de changement de mot de passe à l'aide d'un mot de passe ne respectant pas la présence d'une majuscule
6. Mettre en évidence le refus du changement de mot de passe
7. Effectuer une tentative de changement de mot de passe à l'aide d'un mot de passe ne respectant pas la présence d'un chiffre
8. Mettre en évidence le refus du changement de mot de passe
9. Effectuer une tentative de changement de mot de passe à l'aide d'un mot de passe ne respectant pas la présence d'un caractère spécial
10. Mettre en évidence le refus du changement de mot de passe
11. Effectuer une tentative de changement de mot de passe à l'aide d'un mot de passe précédemment utilisé
12. Mettre en évidence le refus du changement de mot de passe
13. Effectuer une tentative de changement de mot de passe à l'aide d'un mot de passe satisfaisant l'ensemble des critères
14. Mettre en évidence la réussite du changement de mot de passe
15. Effectuer une tentative de connexion au compte à l'aide d'un mot de passe erroné et répéter l'opération
16. Mettre en évidence le blocage du compte après un nombre défini d'échecs de connexion consécutifs au plus égal à 10
     

Notez que le scénario s’applique immédiatement pour tous les futurs dépôts. Le mécanisme de preuve reste inchangé (Capture vidéo montrant le bon déroulé du scénario de conformité).

Que dois-je faire si mes preuves sont déjà réalisées ou en cours de réalisation ?

• Si vos preuves n’ont pas encore été déposées, appliquez directement le scénario harmonisé.
• Si vos preuves ont déjà été déposées selon l’ancienne version, préparez une mise à jour conforme au nouveau scénario pour répondre aux demandes de modification.

Pour toute question, nous vous invitons à contacter le support Industriels Ségur : Formulaire de contact

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.

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.