Pour remplir le test d'intrusion, l'auditeur doit :

1. S'assurer que la première page du formulaire comporte le nom ainsi qu'une description succincte de l'application ;
2. Remplir l'onglet "Base Commune" et l'onglet correspondant au type d'application indiqué dans le champ "Type d'application" ;
3. Compléter l'ensemble des règles de sécurité ;
4. Si une règle de sécurité est notée comme "N/A" ou "NON", ajouter une justification dans la section des commentaires (attention Il est également important d'évaluer les risques de ce résultat, par exemple la présence de l'id de corrélation dans l'URL lors d'un authorization code flow sur PSC via le proxy).;
5. Générer un fichier PDF à partir de la macro du test d'intrusion ou manuellement à partir du descriptif ;
6. Signer électroniquement le formulaire de test d'intrusion.

L’identification du patient doit comporter l’ensemble des éléments constitutifs de l’identité INS, à savoir :

• le nom de naissance ;
• les prénoms de naissance ;
• la date de naissance ;
• le sexe ;
• le lieu de naissance – code INSEE ;
• le matricule INS, complété par son OID.

Cet attendu est explicitement précisé par l’exigence DB.SO.105, qui mentionne l’utilisation des informations contenues dans l’entête du Compte-Rendu pour l’identification du patient, à savoir « INS accompagné de ses traits stricts ».

Dans le cadre de la trace d’audit définie par DB.SO.43, ces informations doivent être véhiculées au niveau du « ParticipantObjectID » du bloc « C.Patient AuditMessage/ParticipantObjectIdentification ».

Aucun format de représentation particulier n’est imposé par la spécification. L’utilisation d’un format tel que HL7 CX est possible mais non obligatoire ; une représentation libre est acceptable dès lors que l’ensemble des éléments constitutifs de l’identité INS est effectivement véhiculé et exploitable.

La formulation actuelle de DB.SO.43, qui mentionne uniquement « Identifiant INS du patient », peut prêter à confusion. Cet attendu doit être compris en cohérence avec DB.SO.105 et avec la définition des traits stricts composant l’INS.

Les preuves demandées sont majoritairement de la documentation spécifique à chaque exigence, une attestation sur l'honneur, ainsi que le formulaire du test d'intrusion en particulier pour l'exigence SC.SSI/GEN.18. Elles permettent de vérifier que les processus en question sont bien mis en œuvre et conformes à une démarche SSI.

La phase de rapport consiste à la fourniture par l'auditeur du rapport du test d’intrusion en remplissant et en signant électroniquement le formulaire correspondant. Ce document regroupe l’ensemble des résultats du test d’intrusion ainsi que le référencement de l’application.  

La phase de test implique la réalisation de tests en boîte grise, où l'auditeur dispose d'informations préalables, ainsi que la réalisation de compléments en boîte noire, où l'auditeur agit sans informations préalables dans le but de repérer les failles et d'obtenir une évaluation exhaustive de la sécurité de l'application. Cette phase dure en moyenne 3 à 4 jours.

La clause de revoyure permet d'avoir un engagement de la part de l'auditeur pour tester de nouveau les exigences non validées lors du test d'intrusion et d'effectuer un contre-audit afin de vérifier si les mesures de sécurité nécessaires ont été mises en œuvre.

La phase de cadrage est la phase qui précède les tests techniques. Elle est organisée par l'éditeur et consiste à communiquer les détails de l'audit au prestataire choisi pour effectuer l'audit, tels que les dates, l'environnement, les contacts, la documentation, etc.

Selon les différents pilotes réalisés par l'ANS et les échanges avec les auditeurs PASSI, le coût du test d'intrusion varie en moyenne entre 5 000 et 10 000 euros (uniquement pour le périmètre du Ségur) et dure environ une semaine ouvrée.

Un webinaire a été organisé par l'ANSSI et l'ANS à l'attention des auditeurs PASSI, dans le but de clarifier leurs responsabilités et leurs périmètres d'intervention à chaque phase du processus de réalisation du test d'intrusion : le cadrage, la réalisation du test d'intrusion et la phase de rapport.

Le replay du webinaire peut être retrouvé ici : https://esante.gouv.fr/webinaires/segur-vague-2-destination-des-prestataires-daudit-passi

Si l’utilisation des macros était bloquée pour des raisons de sécurité, nous recommandons à l’auditeur de se mettre dans un environnement sécurisé afin de les exécuter (VM, docker ou station isolée du SI). 

Les auditeurs issus d'entreprises qualifiées PASSI possèdent les compétences nécessaires pour réaliser des tests d'intrusion sans nécessiter de scénario de test prédéfini. L'ANS reconnaît leur légitimité pour mener à bien ces audits et prendre des décisions éclairées. 
De plus, si l'auditeur a des questions, il a la possibilité de les soumettre à l'ANS pour obtenir des éclaircissements. 
L'audit s'effectue en collaboration entre l'éditeur et l'auditeur. En cas de doutes ou de questions, il est fortement recommandé de discuter directement avec votre auditeur, notamment lors des phases de cadrage et reporting, afin d'assurer la clarté et la compréhension mutuelle du processus.

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.

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.