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

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

Le plan d'assurance sécurité du système (PAS) est un document qui définit les mesures de sécurité et les engagements entre l'hébergeur et la structure utilisatrice pour l'environnement de mise en œuvre du système. Il vise à garantir la sécurité des données et des composants du système lorsqu'ils sont hébergés par un tiers ou fournis sous forme de services (SaaS).

La négligence dans la désignation des responsables de la sécurité peut entraîner un certain nombre de risques, notamment :

• Des failles de sécurité non détectées ;
• Des retards dans la réponse aux incidents de sécurité ;
• Un manque de coordination dans la gestion des risques ;
• Une faible sensibilisation à la sécurité au sein de l'équipe.