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

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 intervient lors de la réalisation de l'audit et son rôle consiste à :

1. S'assurer d'avoir reçu tous les éléments opérationnels nécessaires à la réalisation de l'audit (ex. URL, adresse IP, matrices de flux, etc.) en fonction du type d'application (application web, application mobile, client lourd 3 tiers ou plus et client lourd inférieur à 3 tiers) ;
2. Évaluer la conformité de l'application à tous les points de contrôle du formulaire de test d'intrusion tel que défini dans le guide de l'utilisateur, puis le compléter ;
3. Générer un fichier PDF à partir du formulaire de test d'intrusion ;
4. Proposer à l’éditeur des mesures correctives à mettre en œuvre dans le cas où certains points de contrôle auraient été jugés non conformes ;
5. Signer électroniquement avec l'approbation d'un TSP ;
6. Transmettre le test d'intrusion à l'éditeur qui le déposera sur la plateforme Convergence.

La correction des vulnérabilités ainsi que la soumission du test d'intrusion à l'ANS doivent être effectuées avant la fin du processus de référencement.

Pour assurer la complétude du formulaire, l’éditeur doit renseigner l’ensemble des informations propres à son application dans le formulaire du test d’intrusion (fichier Excel, onglet « 1 – Résultat Formulaire »).  L’éditeur informera l’auditeur du type d’application correspondant à sa solution conformément au logigramme fourni dans le guide du test d'intrusion. L’auditeur vérifiera que l’éditeur a bien respecté les règles de ce logigramme.

Le rôle de l'éditeur consiste à intervenir en amont de l'audit afin de fournir à l'auditeur l'ensemble des éléments nécessaires à la réalisation de la prestation incluant :

• La définition du périmètre du test d'intrusion, la mise à disposition d'une version majeure du logiciel correspondant à la production, la désactivation des dispositifs de sécurité non liés à la solution commerciale et à la conduite de l'évaluation ;
• Les éléments opérationnels nécessaires à la réalisation de l'audit (ex : URL, adresse IP, matrices de flux, etc.) selon la typologie de chaque application (application WEB, application Mobile, client lourd 3 tiers ou plus et client lourd moins de trois tiers).

En cas de vulnérabilité de gravité haute, ou de présence d'un nombre de vulnérabilités de gravité moyenne supérieur au seuil défini par l'ANS, l'auditeur doit en informer l'éditeur qui transmettra l'information au CERT Santé et pourra grâce à la clause de revoyure corriger les vulnérabilités puis par la suite transmettre le test d'intrusion sur Convergence.

Cette phase a pour finalité d'échanger sur le rapport du test d'intrusion, notamment si des manquements aux règles de sécurité sont détectées. L'auditeur devra communiquer les résultats du test d'intrusion à l'éditeur en clarifiant les points suivants :

• Les détails techniques des vulnérabilités identifiées ;
• L'impact potentiel des non-conformités aux règles de sécurité et le niveau de risque associé ;
• Les solutions concrètes permettant de corriger les potentielles failles ;
• La définition des prochaines étapes (définition d’une date permettant d’évaluer de nouveau les vulnérabilités recensées).

L'architecture 2-tiers se compose de deux principales couches (la couche client et la couche serveur) tandis que l'architecture 3-tiers ajoute une couche intermédiaire, généralement appelée la couche applicative. Une couche applicative peut accroître la sécurité de la solution en effectuant un tampon entre la présentation côté client et les données côté serveur et en permettant une gestion centralisée de l'application sur le serveur.

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.

Un secret désigne toute donnée sensible et protéiforme caractérisée par son usage dans les processus d’authentification des utilisateurs et de contrôle d’accès à des ressources et/ou fonctionnalités de composants système ou applicatif. Cela peut désigner des identifiants de comptes, identifiants de session, mots de passe, clés de chiffrement, clés d’API, jetons d’authentification, etc.
Sauf exception justifiée liée à la réglementation, aucun secret n'est journalisé par défaut. Dans le cas contraire, la confidentialité des données doit être garantie dans les traces (utilisation d'un hash, etc.).

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.