Besoin d’aide ? Toutes les réponses et ressources utiles pour les ENS

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.

Les tests d'intrusion se déroulent en trois phases : la phase de cadrage, la phase de test et la phase de rapport.

• La phase de cadrage est la phase qui précède les tests techniques. Elle est organisée par l'éditeur et consiste à communiquer les détails de l'audit au prestataire choisi pour effectuer l'audit, tels que les dates, l'environnement, les contacts, la documentation, etc.
• 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 phase de rapport consiste à la fourniture par l'auditeur du rapport du test d’intrusion en remplissant et en signant électroniquement le formulaire correspondant. Ce document regroupe l’ensemble des résultats du test d’intrusion ainsi que le référencement de l’application.

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.

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