Santé : lancer un programme de bug bounty avant la fuite de données

Un programme de bug bounty dans la santé permet à des chercheurs autorisés de découvrir et de signaler des vulnérabilités avant que des criminels ne les exploitent. Il ne fonctionne que si l’éditeur a déjà publié un périmètre de test sûr, désigné les personnes chargées d’évaluer les signalements et prévu le budget des correctifs et des primes. La faille d’injection SQL signalée dans le logiciel polonais Medyc montre pourquoi ce travail est nécessaire dès maintenant. On ignore si un programme de primes aurait empêché cette intrusion précise.

Une clinique polonaise a informé ses patients que deux fournisseurs de logiciels distincts qu’elle utilisait, MyDr et Medyc de Qbusoft, avaient subi des violations de données. Le communiqué sur MyDr et celui sur Medyc décrivent les deux incidents séparément. Une clinique peut donc faire face à des risques qui se cumulent chez ses fournisseurs, sans avoir de raison de penser que les intrusions partagent une cause technique.

Que sait-on de l’incident Medyc ?

La notification de la clinique attribue les constats techniques à l’enquête menée par Qbusoft avec des experts en investigation numérique. Elle indique qu’un attaquant a exploité une injection SQL dans une interface de l’application Medyc les 22 et 23 août 2026, puis transféré une archive chiffrée de la base de données hors de l’environnement de Qbusoft. L’intrusion a été détectée dans la nuit du 8 au 9 septembre. Selon la clinique, Qbusoft a corrigé la faille le jour de la détection, restreint les droits sur la base de données, renouvelé des secrets techniques et signalé l’affaire à la police ainsi qu’à l’autorité polonaise de protection des données.

Pour les patients de l’unité de jour de traitement des addictions de la clinique, la notification précise que les données téléchargées contenaient de façon avérée leurs noms, numéros d’identification polonais PESEL, adresses, numéros de téléphone et adresses e-mail. Selon cette notification, les noms et numéros PESEL étaient stockés sous forme chiffrée, mais Qbusoft a conseillé à la clinique de partir du principe que les attaquants pouvaient facilement déchiffrer ces deux champs et les obtenir en clair. Des scripts visaient aussi les tables de données médicales ; la clinique estime donc très probable que des comptes rendus de sortie aient été emportés. La notification ne confirme pas que ces comptes rendus ont été copiés.

Le 25 septembre, l’autorité polonaise de protection des données, l’UODO, a indiqué que, selon des informations parues dans les médias, jusqu’à cinq millions de personnes pourraient être concernées et qu’elle prévoyait un contrôle de Qbusoft. Ce chiffre de personnes touchées n’est pas vérifié. L’autorité a également repris la déclaration du ministre chargé du numérique du 24 septembre, selon laquelle Qbusoft n’avait alors signalé l’incident ni à CERT Polska ni au CSIRT du secteur de la santé. Le récit de la clinique mentionne des signalements à la police et à l’UODO : ce sont d’autres destinataires. Les deux récits peuvent donc être exacts.

L’article de Zaufana Trzecia Strona relie l’affaire Medyc à l’auteur de l’attaque antérieure contre MyDr. Les autorités publiques n’ont pas établi cette attribution dans les sources disponibles pour cet article. Le fait opérationnel essentiel ne dépend pas de l’identité de l’attaquant : une faille d’injection SQL dans une interface de l’application Medyc aurait permis à des données de quitter l’environnement de l’éditeur.

Pourquoi prévoir un canal de signalement et des primes avant le premier rapport ?

L’injection SQL est le type de défaut applicatif qu’un chercheur externe pourrait repérer sans accès privilégié. Un programme peut lui indiquer quels systèmes il est autorisé à tester, comment démontrer une faille sans ouvrir de vrais dossiers de patients, où envoyer son signalement et quand attendre une réponse. Les recommandations du NIST sur la divulgation des vulnérabilités préconisent un processus formel pour recevoir, évaluer, traiter et communiquer sur les signalements. Elles ne promettent pas qu’un tel processus détectera toutes les failles.

Commencez par un programme de divulgation des vulnérabilités (VDP) : un contact public, un périmètre, des règles, une sphère de sécurité (Safe Harbor), une file de réception effectivement suivie et un chemin du rapport accepté jusqu’au correctif. Ajoutez ensuite un programme de bug bounty rémunéré lorsque l’équipe peut absorber davantage de rapports et dispose d’un budget de primes approuvé. La prime incite les chercheurs à consacrer du temps à votre produit ; le traitement des rapports et la correction rendent cette attention utile. Si votre organisation peut déjà assurer les deux, publiez les deux dès maintenant. Un incident est un mauvais moment pour rédiger vos premières règles de test.

Aucun des comptes rendus publics sur Medyc ne montre qu’un chercheur de bonne foi avait découvert cette injection SQL plus tôt, tenté de la signaler ou l’aurait trouvée dans le cadre d’un programme de primes. Un tel programme ne remplace pas non plus des requêtes de base de données sûres, la revue de code, les tests d’intrusion, la journalisation, le principe du moindre privilège pour les accès à la base de données ou la réponse aux incidents. Il permet aux chercheurs de signaler une faille tant qu’il est encore temps de la corriger.

Comment permettre aux chercheurs de tester sans exposer les patients ?

Un programme destiné aux logiciels médicaux doit tracer une limite concrète. La politique de divulgation du ministère américain de la Santé et des Services sociaux donne un exemple utile : ne tester que les systèmes énumérés, n’exploiter une faille que dans la mesure nécessaire pour la confirmer, s’arrêter devant des données sensibles et ne jamais extraire de dossiers. Un éditeur peut adapter ces choix à son architecture et à ses conseils juridiques. Ils ne constituent pas une autorisation de tester les systèmes d’une autre organisation.

Le programme public de bug bounty de Doctolib offre un exemple dans la santé, avec un périmètre, des primes et des conditions de test explicites. Un éditeur plus petit n’a pas à reprendre ses montants ni le volume de son programme. Il peut reprendre la discipline qui consiste à publier où les chercheurs peuvent intervenir et comment préserver les soins aux patients.

Faites une répétition interne avant d’inviter le public : soumettez un rapport fictif, suivez sa réception et son attribution, vérifiez le délai de réponse, apportez un correctif et envoyez un message de clôture au chercheur. Corrigez toute rupture dans la transmission avant d’inviter davantage de chercheurs.

Quels éditeurs de logiciels médicaux devraient y réfléchir dès maintenant ?

Un fournisseur qui conserve les dossiers de nombreuses cliniques indépendantes a une responsabilité envers chacune d’elles : un seul défaut applicatif peut obliger chaque clinique à évaluer l’exposition de ses patients. Les éditeurs de logiciels de dossier médical électronique, de gestion de cabinet et de prise de rendez-vous devraient publier un canal de signalement avant d’en avoir besoin. Les produits hébergés et les installations gérées par les cliniques peuvent nécessiter des limites de test différentes ; chaque programme doit se limiter aux systèmes détenus par l’éditeur ou pour lesquels il a obtenu l’autorisation de faire réaliser des tests.

Pour la personne responsable de l’ingénierie ou de la sécurité chez un éditeur, la bonne question est la suivante : un chercheur pourrait-il aujourd’hui trouver le bon contact, envoyer un rapport sans exposer de patients et le faire parvenir à quelqu’un qui a le pouvoir de corriger la faille ? Si la réponse est incertaine, cartographiez les systèmes et désignez maintenant cette personne. Une clinique peut poser la même question lors de son évaluation des risques liés à un fournisseur de logiciels. Notre précédente analyse de MyDr examine plus largement les limites des canaux de signalement face à plusieurs types de violations. Le cas Medyc souligne l’importance de définir quelles interfaces du produit les chercheurs externes peuvent tester sans risque pour les patients et au sujet desquelles ils peuvent envoyer un signalement.

Comment Kit peut-il aider à gérer un programme de divulgation dans la santé ?

Kit fournit à une équipe de sécurité un portail public de signalement et la configuration du programme, un fichier security.txt généré, un périmètre publié, l’attribution et le triage des rapports, la communication avec les chercheurs et le suivi des délais SLA. Une équipe qui décide de verser des primes peut définir des fourchettes, débattre des propositions, consigner l’approbation et suivre le relais vers le versement. Définissez d’abord un périmètre limité à vos propres systèmes et à ceux que leur propriétaire vous autorise expressément à faire tester, puis une politique de test sans risque pour les patients. Vérifiez ensuite tout le parcours, du dépôt à la clôture, avec un rapport fictif.

Kit ne recherche pas les injections SQL, ne sécurise pas les requêtes de base de données et ne prouve pas qu’un éditeur est à l’abri d’une violation de données. Ces tâches relèvent toujours de l’ingénierie et de la réponse aux incidents. Kit aide un chercheur externe à joindre l’équipe responsable du correctif et garde la trace de la personne chargée du rapport et de la suite qui lui est donnée. Pour les étapes détaillées, consultez le guide de mise en place d’un programme de divulgation des vulnérabilités.