Protégez les données patients avant qu'elles ne deviennent une notification de violation

L'exposition d'ePHI déclenche une notification obligatoire

Sous HIPAA, l'accès non autorisé au dossier d'un seul patient impose une notification de violation au HHS et, le cas échéant, au patient. Les défauts de contrôle d'accès à l'origine de ces expositions, comme l'IDOR et l'autorisation défaillante dans les API FHIR, sont exactement ce que Penetrify détecte.

La HIPAA Security Rule impose des tests réguliers

45 CFR §164.308(a)(8) impose des évaluations techniques et non techniques régulières de vos contrôles de sécurité. « Régulier » signifie plus d'une fois par an quand vous livrez du code tous les mois, et Penetrify rend le test continu économiquement praticable.

Les API FHIR créent de nouvelles surfaces d'attaque

Les standards modernes d'interopérabilité en santé (FHIR R4, SMART on FHIR) créent des endpoints d'API qui exposent les données patients à grande échelle. Une autorisation mal configurée sur un seul endpoint FHIR peut exposer toute votre population de patients.

45 CFR §164.308(a)(8) : évaluation régulière des garanties techniques et non techniques

Contrôle 10.m : tests d'intrusion dans le cadre du programme de gestion des vulnérabilités

CC6.1 : contrôles d'accès logiques avec preuves de tests d'intrusion

A.12.6 : gestion des vulnérabilités techniques avec tests de sécurité réguliers

HIPAA aujourd'hui, et la règle proposée qui rend le test d'intrusion explicite

La HIPAA Security Rule actuelle impose une évaluation « régulière » technique et non technique des garanties (45 CFR §164.308(a)(8)) sans nommer explicitement le test d'intrusion, ce qui explique pourquoi les programmes de sécurité en santé varient autant. Cette ambiguïté est en train de disparaître : la mise à jour de la Security Rule proposée par le HHS (NPRM publiée le 6 janvier 2025) rendrait les exigences explicites, avec notamment un test d'intrusion au moins tous les 12 mois et un scan de vulnérabilités au moins tous les six mois.

À la mi-2026, la règle est toujours proposée et non définitive, et l'OCR continue d'appliquer la Security Rule actuelle. La direction est cependant sans ambiguïté, et les enquêtes de l'OCR traitent déjà l'absence de tests techniques comme la preuve d'une analyse de risques insuffisante, le manquement le plus souvent cité dans les procédures. Mettre la cadence de test en place maintenant, c'est faire de la future règle définitive un non-événement ; attendre, c'est devoir bâtir un programme sous la contrainte d'une échéance de conformité.

Le test continu répond d'ailleurs mieux au critère « régulier » dès aujourd'hui que n'importe quelle mission annuelle : un historique documenté de scans sur l'année, chacun accompagné de ses résultats et de ses preuves de correction, correspond précisément au type d'évaluation continue que décrit le §164.308(a)(8).

FHIR et SMART on FHIR : l'interopérabilité est une surface d'attaque

Les obligations américaines d'interopérabilité ont placé les données patients derrière des API standardisées : ressources FHIR R4, autorisation SMART on FHIR, export de données en masse. La standardisation aide aussi les attaquants : ils savent exactement quels endpoints existent (/Patient, /Observation, /DocumentReference) et exactement ce que fuite un endpoint mal configuré. Un seul endpoint FHIR qui n'applique pas l'autorisation au niveau de la ressource peut exposer toute une population de patients, et contrairement à un ordinateur portable volé, il le fait en silence.

Les modes de défaillance récurrents sont précis : des identifiants de ressources acceptés sans vérifier la relation de soin de l'utilisateur demandeur (IDOR à l'échelle d'une population), des scopes SMART accordés largement et jamais appliqués ressource par ressource, et des endpoints d'export en masse accessibles avec des identifiants prévus pour l'accès à un seul dossier. Penetrify teste ces frontières d'autorisation comme un attaquant les sonde : entre rôles, entre patients, entre scopes, à chaque déploiement de votre API.

Penetrify teste les frontières d'autorisation sur tous les rôles utilisateur (clinicien, administrateur, patient) et cherche spécifiquement les vulnérabilités IDOR qui exposent des dossiers patients hors des relations de soin autorisées. C'est la première cause de violations de données en santé.

Chaque scan produit un rapport horodaté et classé par sévérité. Quand l'OCR audite votre programme de sécurité, vous pouvez démontrer un historique documenté de tests de sécurité réguliers sur toute votre application, et non un unique rapport annuel figé à un instant donné.

Penetrify teste les implémentations FHIR R4 et SMART on FHIR sur l'application des frontières d'autorisation, la validation des scopes et le contrôle d'accès aux ressources : précisément les surfaces d'attaque que les outils DAST standard ne sont pas configurés pour tester.

Penetrify ne modifie, ne supprime ni n'exfiltre jamais de données. Il teste en observant les réponses de l'application, pas en effectuant d'opérations d'écriture. Utilisable sans risque sur des environnements de staging qui reproduisent la structure des données patients de production.