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

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. 

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.