{"text_format":"1","workbook":"xlsx","n_sheets":3,"sheets":["1 - Résultat Formulaire","2 - Proxy","3 - Génération PDF & Signature"],"not_rendered":{"charts":0,"images":2,"macros":1,"external_links":0,"defined_names":3,"comments":0,"pivot_tables":0},"unopened":[],"bounds":{"document_bytes":16777216,"sheet_cells":100000,"rows_first":2000,"rows_last":500,"rows_between":2000,"halvings":0,"cell_chars":16384,"cell_head_chars":4096},"cells_cut":0,"cells_raw":0,"read":"whole","date_system":"1900"}

{"sheet":"1 - Résultat Formulaire","index":0,"n_rows":32,"n_cols":5,"rows_kept":32,"cut":false,"hidden":false,"merged":[[22,4,22,7],[24,4,25,7],[27,4,27,6],[24,1,25,3],[20,1,20,7],[18,8,19,8],[13,2,13,6],[16,1,16,7],[18,0,19,0],[18,1,18,7],[19,1,19,7]]}
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[null,null,"Questionnaire d'audit de sécurité pour l'habilitation à l'Espace de Confiance"]
[]
[]
[null,"Pro Santé Connect (PSC) est le fédérateur d’identités des professionnels des secteurs sanitaire, médico-social et social enregistrés au Répertoire Partagé des Professionnels de Santé (RPPS). Ce service socle est proposé par l’Agence du Numérique en Santé (ANS). \nIl leur offre une manière simple, sécurisée et unifiée de se connecter à tous leurs services numériques en santé, en pouvant passer de l’un à l’autre de manière particulièrement fluide. \n\nL’Espace de Confiance (EDC) de Pro Santé Connect est un environnement dédié aux services numériques en santé entrant dans le cadre du CI-SIS Volet Transport. \nL’EDC vise à instaurer une relation de confiance entre ses différents composants afin, notamment, de garantir les niveaux de sécurité attendus. "]
[]
[null,"Ce formulaire, effectué par un prestataire d'audit de la sécurité des systèmes d'information qualifé (PASSI), atteste la réalisation d'un test d'intrusion dans le cadre de l'habilitation à l'EDC."]
[null,"Ce document précise les règles de sécurité validées par l'auditeur, ainsi que le résultat du référencement de l'application vis à vis des exigences de sécurité informatique."]
[null,"Le périmètre du test d’intrusion doit se limiter au service proxy e-santé, et ne doit en aucun cas inclure le logiciel de santé de test qui doit être fourni à l’auditeur, ou une éventuelle simulation d’API Pro Santé connectée. Le logiciel de santé de test doit uniquement permettre d’identifier les principales fonctionnalités du proxy e-santé et faciliter le test d’intrusion.\t\t\t\t\t\t"]
[]
[null,"Nom de l'application & version"]
[]
[null,"Description succincte de l'application"]
[]
[]
[null,"Résultat",null,null,"L'application peut être référencée"]
[]
[]
[]
[null,null,null,"Signature de l'auditeur :"]

{"sheet":"2 - Proxy","index":1,"n_rows":22,"n_cols":7,"rows_kept":22,"cut":false,"hidden":false,"merged":[[1,0,1,6]]}
[]
["Résultat d'audit de sécurité - Proxy"]
[]
["ID","Périmètre","Nom court","Règles de sécurité","Notation","Commentaire","Gravité"]
["P1","Gestion des sessions","Changement ID corrélation ","Il est impossible d'utiliser le service Proxy e-santé pour contacter une API Pro Santé Connectée sans disposer au préalable d'un identifiant de corrélation ",null,null,"Haute"]
["P2","Gestion des sessions","Conformité identifiant de corrélation ","L'identifiant de corrélation utilisateur est caché autant que techniquement possible dans l’URL, et n'apparaît jamais dans les paramètres d'url et les messages d'erreur.",null,null,"Haute"]
["P3","Gestion des sessions","Changement ID corrélation ","L'identifiant de corrélation produit par le service proxy e-santé doit être changé à chaque nouvelle connexion, et ne pas être prédictible, y compris en disposant d'identifiants de corrélation précédemment générés",null,null,"Haute"]
["P4","Gestion des sessions","Invalidation après inactivité","La session d'un utilisateur est invalidée au terme d'une période d'inactivité de 30min maximum.",null,null,"Haute"]
["P5","Gestion des sessions","Invalidation après inactivité","La session d'un utilisateur est invalidée au terme d'une période de 4h maximum.",null,null,"Haute"]
["P6","Gestion des sessions","Déconnexion","La session d'un utilisateur est invalidée au terme d'une procédure de déconnexion de PSC.",null,null,"Haute"]
["P7","Exposition","Exposition des services","Les services exposés par le proxy ne permettent pas d'obtenir un accès non autorisé à une ressource mise à disposition par le proxy (données, console permettant une exécution de code distante, ...). \nNote: Pour définir les cas d'accès autorisés, l'auditeur peut se baser sur les déclarations de l'éditeur, en les comparant au niveau d'autorisation requis et au type de service ou de ressource exposé.",null,null,"Haute"]
["P8","Exposition","Exposition des comptes génériques","Les comptes génériques éventuels doivent être restreints à des comptes de service (non destinés aux utilisateurs) ou à des usages ponctuels qui requièrent des privilèges spécifiques.",null,null,"Haute"]
["P9","Exposition","Composants vulnérables","Lors d'un scan, le système doit être constitué d'éléments ne présentant aucune vulnérabilité de sécurité d'un score CVSS v3 supérieur ou égal à 8. Pour les identifier, l'auditeur pourra recourir à tout moyen jugé approprié, tel qu'un scan de vulnérabilités des composants du système lorsque cela est possible.\n(NB : 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 ces détails dans un commentaire explicatif - cf.guide d'utilisation)",null,null,"Haute"]
["P10","Gestion des traces et événements de sécurité","Journalisation technique - authentification","Toutes les tentatives d'authentification à Pro Santé Connect ou à une API Pro Santé Connectée par un utilisateur final doivent être enregistrées avec un horodatage en UTC, issu d'une source de temps fiable, et l'IP d'origine des requêtes, associés à chaque événement d'authentification.",null,null,"Haute"]
["P11","Gestion des traces et événements de sécurité","Journalisation technique des données sensibles","Sauf exception justifiée liée à la réglementation, aucun secret (cf. définition du guide d'utilisation) n'est journalisé ni présent dans les messages d'erreur par défaut. Dans le cas contraire, la confidentialité des données doit être garantie dans les traces (hash, etc.)",null,null,"Haute"]
["P12","Gestion des traces et événements de sécurité","Journalisation des événements","Les événements de sécurité sont journalisés (doit être enregistré a minima, l'authentification erronée, le refus d'accès à une ressource, etc.)",null,null,"Haute"]
["P13","Gestion des traces et événements de sécurité","Test procédure d'alerte","L'auditeur doit vérifier qu'en cas de requête non conforme effectuée au service Proxy e-Santé, le système rejette la requête et déclenche correctement la procédure d'alerte",null,null,"Haute"]
["P14","Protection des données en transit","Cryptographie","Sur les flux / informations auxquels a accès l'auditeur, les données sensibles doivent être sécurisées avec des protocoles et algorithmes cryptographiques à l'état de l'art (https://www.ssi.gouv.fr/uploads/2021/03/anssi-guide-selection_crypto-1.0.pdf)",null,null,"Haute"]
["P15","Protection des données en transit","Cryptographie","L'ensemble des flux client-serveur sont toujours protégés par l'utilisation du chiffrement. Exemple du protocole HTTPS : les flux HTTP sont redirigés vers HTTPS et le serveur doit inclure l'entête de sécurité HSTS dans ses réponses.",null,null,"Haute"]
["P16","Gestion des entrées","Prévention des injections ","L'ensemble des entrées utilisateur doivent être traitées de manière sécurisées par le serveur, afin de proscrire tout type d'injection côté serveur, ou côté client si ces données sont réfléchies, quelles que soit les technologies utilisées.\n\nA titre d'exemple :\n* Prévention des injections en base de données (les requêtes SQL adressées à interpréteur SQL intègrant des données fournies par les utilisateurs, donc non sûres, doivent être préparées (\"prepared statement\"), ou les données doivent avoir été spécifiquement neutralisées vis à vis des risques d'injection SQL prélablement à leur usage dans la requête, explicitement ou par l'usage de fonctions de construction de requête SQL intégrant cette fonctionnalité de sécurité) ;\n* Prévention des injections dans des annuaires LDAP (toutes les données non sûres qui sont utilisées dans des requêtes LDAP doivent être correctement neutralisées soit en utilisant la bonne fonction d'encodage LDAP, soit par l'utilisation d'un framework tel que LINQtoLDAP). \n* Seconde ligne de défense contre les injections de charges utiles réfléchies : par exemple un serveur pourrait répondre à une requête en incluant des données préalablement sauvegardées, contenant du code HTTP menant à l'injection de javascript malveillant (prévention des XSS). Il est alors attendu que les données soient correctement neutralisées en utilisant une encapsulation appropriée là où des données produites par un utilisateur sont susceptibles de se trouver.",null,null,"Haute"]
["P17","Gestion des entrées","Vérification respect des standards","Lorsque le Proxy e-Santé joue un rôle de \"passe-plat\", relayant à l'identique une requête SOAP vers les API Pro Santé Connectées (en y incluant une assertion SAML), il est impossible de transformer la requête reçue en entrée de manière à la dénaturer et à compromettre le niveau de sécurité offert par le système. \nLe format de la requête doit rester très similaire à celui donné en entrée. Dans le cadre du protocole HTTP, le format de la requête inclut : le chemin URL, le verbe HTTP, les paramètres obligatoires, le format des paramètres.\nPar exemple, une requête modifiant l'état du serveur ou de sa base de données ne doit pas être transformée par le proxy d'un verbe POST à un verbe GET.",null,null,"Haute"]
["P18","Gestion des entrées","Vérification accès ressource","Toute demande d'usage/modification d’une référence directe à une ressource (clé de base de données, nom de fichier, ressource web etc.) par le client fait nécessairement l’objet d’une vérification d'autorisation côté serveur et d'une autorisation explicite pour tout utilisateur.",null,null,"Haute"]

{"sheet":"3 - Génération PDF & Signature","index":2,"n_rows":20,"n_cols":3,"rows_kept":20,"cut":false,"hidden":false,"merged":[[30,4,30,12],[31,4,31,12],[32,4,32,12],[33,4,33,12],[34,4,34,12],[29,4,29,12],[14,1,14,12],[16,1,16,12],[18,2,18,12],[19,2,19,12],[22,1,22,12],[23,1,23,2],[23,3,23,12],[24,1,24,2],[24,3,24,12],[26,1,26,12],[27,4,27,12],[28,4,28,12]]}
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[]
[null,"Le guide d'utilisation du formulaire du test d'intrusion doit être consulté avant de travailler sur ce document"]
[]
[null,"Génération du PDF & Signature électronique\n\nUne fois le formulaire complété, il vous suffit de renseigner le répertoire où vous voulez sauvergarder votre fichier au niveau de la ligne \"Lien\" (par défaut, le chemin d'accès pointe vers le dossier utilisateur de votre poste de travail et correspond à un système d'exploitation Windows. Vous pouvez le modifier si vous utilisez un autre système d'exploitation), ainsi que renommer le nom du questionnaire au format : \"Test intrusion_NOM APPLICATION.pdf\" (il ne faut pas supprimer l'extension du fichier). Une fois ces modifications apportées, il vous suffit de cliquer sur le bouton \"Génération PDF\". \n\nEn cas de dysfonctionnement de la macro, vous pouvez générer le PDF manuellement en suivant les étapes suivantes :\n1. Positionner vous sur l'onglet \"Résultat Formulaire\" ;\n2. Sélectionner les feuilles à exporter (les onglets \"Résultat Formulaire\" et \"Proxy\") en effectuant un ctrl+clic gauche ;\n3. Une fois la sélection effectuée, cliquer sur Fichier, Exporter, Créer PDF ;\n4. Renommer le document au format : \"Test intrusion_NOM APPLICATION.pdf\".\n\nUne fois le PDF généré, le formulaire doit être signé électroniquement, avec l’approbation d’un TSP (Trust Service Provider). Pour apposer cette signature électronique, deux options sont possibles (détails des étapes disponibles dans l’annexe 4 : processus autour de la signature électronique) : \n1. Via une application bureautique telle qu’Adobe avec un certificat de signature délivré par un TSP ;\n2. Via une plateforme de signature électronique reconnue telle que DocuSign, Docaposte, YouSign, etc.\nCe fichier signé électroniquement, avec l’approbation du TSP via un certificat de signature ou via une plateforme de signature électronique, constitue une preuve essentielle que l’éditeur devra soumettre dans le cadre de sa candidature pour l'habilitation à l'EDC."]
[]
[null,"Lien","C:\\Users\\alexandre.blanchon"]
[null,"Nom","test intrusion_NOM_APPLICATION.pdf"]