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

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.

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.