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

Le test d’intrusion est applicable pour toutes les solutions passant le référencement Ségur V2 dans le cadre de l'exigence SC.SSI/GEN.18 qui stipule que le système doit faire l’objet d’un test d’intrusion réalisé par un prestataire d’audit (PASSI) à la charge de l’éditeur (audit PASSI non exigé). Le prestataire d'audit remplit un formulaire confirmant la conformité du système aux critères de sécurité requis. Ce formulaire est une preuve essentielle à fournir et doit démontrer l'éligibilité du système au référencement. De plus, il doit être daté de moins d'un an et être signé électroniquement par le prestataire ayant réalisé l'audit.

Le périmètre du test d’intrusion doit être parfaitement cadré pour limiter les impacts sur l’application ou le système d’information. Ainsi, la prestation doit être réalisée de préférence sur un environnement « iso-prod » (tel qu’un environnement de développement, de test, etc.) plutôt que sur un environnement de production.

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.