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

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.

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

La responsabilité de la rédaction du plan d'assurance sécurité du système peut être partagée entre l'éditeur et l'hébergeur ou le fournisseur de services SaaS, en fonction des accords contractuels. Cependant, il est essentiel que ce plan soit clairement et doit contenir : 

• Le cadre juridique : les références légales, les réglementations et les obligations contractuelles liées à l'hébergement du système, en précisant les responsabilités et les droits des parties impliquées, etc. ;
• Les mesures de sécurité : les dispositions et les procédures de sécurité mises en place pour protéger le système hébergé (ex: contrôles d'accès, protection des données, etc.) ;
• Les engagements entre l'hébergeur et la structure utilisatrice comme par exemple des garanties de disponibilité, des délais de réponse en cas de problème, des mesures de résilience en cas de panne, etc. ;
• L'environnement de mise en œuvre du système : il s'agit de décrire l'environnement technique et opérationnel dans lequel le système doit être déployé (ex: configuration réseau, connectivité, etc.).