FAQ des industriels

Pour remplir le test d'intrusion, l'auditeur doit :

1. S'assurer que la première page du formulaire comporte le nom ainsi qu'une description succincte de l'application ;
2. Remplir l'onglet "Base Commune" et l'onglet correspondant au type d'application indiqué dans le champ "Type d'application" ;
3. Compléter l'ensemble des règles de sécurité ;
4. Si une règle de sécurité est notée comme "N/A" ou "NON", ajouter une justification dans la section des commentaires ;
5. Générer un fichier PDF à partir de la macro du test d'intrusion ou manuellement à partir du descriptif ;
6. Signer électroniquement le formulaire de test d'intrusion.

L'auditeur doit effectuer une évaluation du niveau de criticité des vulnérabilités identifées. Pour un score CVSS v3 supérieur ou égal à 8, une vulnérabilité est considérée comme haute. Pour un score CVSS v3 compris entre 4 et 8, une vulnérabilité est considérée comme moyenne. Dans le cadre du Ségur seule la solution est auditée et le périmètre du SI n'est pas pris en compte. Par conséquent, il peut exister des mesures de sécurité supplémentaires qui rendent l'attaque sur la vulnérabilité difficilement réalisable. Ainsi, l'auditeur peut valider une règle de sécurité s'il constate que des mesures de sécurité rendent l'attaque impossible.

Les points de contrôle au niveau du formulaire du test d’intrusion sont répartis en trois catégories : 

• Gravité haute : la non-conformité au point de contrôle attendu est éliminatoire. L’éditeur ne sera pas éligible au référencement dans ce cas ; 
• Gravité moyenne : jusqu’à 10 réponses négatives à des points de contrôle de gravité moyenne peuvent être acceptées au maximum sans remettre en cause l’éligibilité au référencement sur l’ensemble du formulaire du test d’intrusion ; 
• Non applicable (NA) : points de contrôle s’appliquant uniquement aux clients lourds avec une architecture moins de trois tiers et, bien qu'ils doivent être évalués, n'étant pas pris en compte dans le processus de référencement. Cette exclusion découle de l'incompatibilité entre la nature de l'architecture et les critères de contrôle. 

Le filtrage des entrées utilisateur et un mécanisme d'encodage des données doivent être implémentés. Les caractères potentiellement dangereux doivent être échappés avant d'être retournés dans les réponses du serveur (ex : usage d'entités HTML). L'ensemble des entrées utilisateur doivent obligatoirement être traitées de manière sécurisée par le serveur, afin de proscrire tout type d'injection côté serveur quelles que soient les technologies utilisées. Des contrôles d'encodage/échappement supplémentaires peuvent également être mis en place côté client.

Lorsque l'auditeur juge que l'exploitation d'une vulnérabilité est complexe en raison du contexte applicatif de la solution, il est possible de valider la règle de sécurité en incluant des précisions explicatives.

• Est considérée comme donnée sensible toute donnée à caractère personnel, qu'elle soit ou non de santé ou bien toute information participant à la sécurité du système d'information constitué par le système ou auquel il participe.
• Est considérée comme opération sensible tout déclenchement d'action susceptible d'induire directement ou indirectement l'enregistrement, l'affichage, la transmission, la modification ou l'effacement d'information sensible, sauf à ce que l'analyse de risque du système ait spécifié que l'action considérée sur les informations considérées n'était pas porteuse d'enjeu particulier, tout déclenchement d'action susceptible d'induire des effets négatifs sur la santé de patients et tout autre déclenchement d'action identifiée par l'analyse de risque du système comme devant faire l'objet de mesures de protection et/ou de contrôle renforcées. 

Une application client-serveur fait référence à une architecture désignant la séparation des tâches d’une application entre deux entités distinctes et cloisonnées. Le côté client désigne l’ensemble des composants logiciels manipulés par les utilisateurs. Le côté serveur désigne l’ensemble des composants logiciels responsables des traitements, c’est-à-dire l’implémentation de la logique métier, et de l’accès aux données.

Un TSP est un fournisseur de services de confiance qui fournit des certificats numériques utilisés pour authentifier et sécuriser les signatures électroniques.

Une application standalone est un logiciel embarquant l’ensemble des composantes nécessaires à son fonctionnement, et en particulier le traitement et l'implémentation de « l’intelligence » du logiciel, responsable de toute la logique métier et garant du fonctionnement de l’application et la gestion du stockage des données.

Le client effectue des contrôles sur la taille des entrées de l'utilisateur afin de prévenir les attaques par débordement de mémoire tampon. De plus, toutes les entrées de l'utilisateur dans le client lourd doivent être nettoyées pour éviter les injections de commandes (commandes arbitraires visant le système d'exploitation par l'intermédiaire de l'application). Par ailleurs, l'utilisation d'un serveur d'application est nécessaire pour éviter l'accès à la base de données directement à partir du client lourd.

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.

Les éditeurs devront déposer leurs preuves sur le guichet Vague 2 dès qu’il sera ouvert et ils pourront bénéficier du financement SONS Va1+Va2 en cas de référencement, dans les limites d'exclusion précisées dans l'AF Vague 2 ("Eligibilité d’un Client à la Prestation Ségur Vague 1 + Vague 2"). S’ils sont référencés Vague 1, ils ne devront pas redéposer les preuves Vague 1, mais uniquement celles du périmètre Vague 2.

Non, cela n'est pas obligatoire. Attention, seuls les profils référencés pourront bénéficier du financement SONS. Des contrôles seront réalisés.

L'intégration d'une interface Mailiz n'a pas de lien avec le choix du profil MSS. Si vous choisissez le profil Mailiz en déploiement, les preuves déposées devront correspondre à ce profil.

Les URL de test de l'interface DST sont au §8.3.2.2 du "Dossier des Spécifications Techniques (DST) des interfaces clients de messagerie / opérateurs MSSanté (V1.3 - 28/01/2022)" disponible sur https://mssante.fr/is/doc-technique.

Une nouvelle interface IMAP/SMTP sera disponible début juillet dans le cadre de la vague 2 du Ségur : celle-ci ne sera plus uniquement exposée par Mailiz, mais par l'ensemble des opérateurs MSSanté d'ici fin 2022. L'interface DST sera encore proposée au moins jusqu'à fin 2023.

Pour plus d'informations : https://mssante.fr/is/cr-taskforce-mssante & https://participez.esante.gouv.fr/consultation/referentiel-1-mssante-et-contrat-v2-operateurs/presentation/presentation

Oui, le bon de commande, et ses éventuelles annexes, doit avoir fait l’objet d’un accord explicite du Client final, par la signature du responsable, celle-ci pouvant être manuscrite ou électronique : signature avec certificats CPx, signature avec identification électronique par Pro Santé Connect, signature par certificat logiciel RGS, signature électronique de niveau minimum eIDAS simple

Un certificat est lié à une structure/utilisateur cliente d'un éditeur.
Une structure / un utilisateur peut mandater son éditeur pour la gestion et la mise en oeuvre de son certificat.
Un changement d'éditeur nécessite de désigner un nouvel administrateur technique chez cet éditeur.
/!\ Révision réglementaire en cours

Il s’agit d’une lettre dans laquelle vous attestez répondre aux critères d’éligibilité décrits dans la section 2.1 du DSR. Il convient, pour chacun des critères listés de décrire en quoi la solution logicielle y répond (par exemple sur la base d’une documentation produit, de captures d’écrans ou tout autre élément attestant de cette éligibilité).

Si vous effectuez un montage (utilisation d’une solution tierce déjà certifiée), vous n’avez pas à effectuer de demande de certification auprès du CNDA. Vous pouvez communiquer à l'ANS le NIL de cette solution tierce lors de votre demande de référencement.

Oui. Pour obtenir plus d’informations sur ces contrôles, veuillez-vous reporter aux slides ci-dessous, en particulier à la slide 3 ("Précisions sur les contrôles au guichet ASP")