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

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.

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.

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.

Deux cas peuvent se présenter : 
- Si un ou plusieurs manquements aux règles de sécurité de gravité haute sont présents, ces derniers doivent être corrigés avant la fin du processus de référencement. Par ailleurs, en cas de vulnérabilité majeure découverte sur la solution, toute vulnérabilité ayant un score CVSS (Common Vulnérabilité Scoring System) égal ou supérieur à 8, l'auditeur doit en informer l'éditeur qui transmettra l'information au CERT Santé.
- Si un ou plusieurs manquements aux règles de sécurité de gravité moyenne sont présents, il est préférable, mais non obligatoire dans le cadre du référencement Ségur, de corriger ces derniers avant la fin du processus de référencement. A noter qu'au-delà de 10 manquements aux règles de sécurité de gravité moyenne, l'éditeur ne sera pas éligible au référencement.  

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. 

L'auditeur doit effectuer une évaluation du niveau de criticité des vulnérabilités identifiées pour les vulnérabilités publiques déjà déclarées et identifiées publiquement (enregistrées avec un numéro CVE : https://nvd.nist.gov/vuln/search) des composants de la solution, et dont les codes d’exploitation publiés pourraient être utilisés. 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.
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. 
Par ailleurs, l’auditeur peut réévaluer le score CVSS d’une vulnérabilité, en particulier s’il juge qu’elle n’est pas exploitable en raison du contexte applicatif de la solution ou si des mesures de sécurité ont été mises en place pour la protéger. Dans ce cas, il est possible de valider la règle de sécurité en incluant dans les commentaires une justification de ce choix.

Lors de l'évaluation, l'auditeur doit effectuer des tests sur des points de contrôle, dont certains sont communs à tous types d'applications, et d'autres sont spécifiques à chaque type d'application. Ces points sont listés dans le formulaire du test d'intrusion comme suit :

• 18 points de contrôle communs à toutes les solutions qui doivent être systématiquement examinés par l'auditeur, quelle que soit la nature de la solution ;
• 21 à 24 points de contrôle spécifiques au type de la solution (application web, application mobile, client lourd avec une architecture de trois tiers ou plus, et client lourd avec une architecture de moins de trois tiers).

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.

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 "standard de développement sécurisé" est un ensemble de lignes directrices, de bonnes pratiques que les développeurs devraient suivre pour garantir la sécurité d'un système. Il peut provenir de différentes sources (ex : guide de l'ANSSI, documentation interne, OWASP, PGSSI-S, etc.). Il comprend des recommandations sur la vérification de la qualité du code, la gestion de l'obsolescence des bibliothèques, la sécurisation de la plateforme système, et bien d'autres aspects liés à la sécurité. Il est essentiel car il permet de réduire les vulnérabilités potentielles, les failles de sécurité et les risques de cyberattaques, assurant ainsi la sécurité du système.