Bug-Bounty-Programme im Gesundheitswesen: vor dem Datenleck starten

Ein Bug-Bounty-Programm im Gesundheitswesen gibt autorisierten Sicherheitsforschern die Möglichkeit, Schwachstellen zu finden und zu melden, bevor Kriminelle sie ausnutzen. Das funktioniert nur, wenn der Anbieter vorher einen sicheren Geltungsbereich für Tests veröffentlicht, Personen für die Prüfung von Meldungen bestimmt und Mittel für Korrekturen und Prämien bereitgestellt hat. Die gemeldete SQL-Injection-Schwachstelle in der polnischen Software Medyc zeigt, warum diese Vorarbeit jetzt nötig ist. Ob ein Bug-Bounty-Programm gerade diesen Angriff verhindert hätte, ist unbekannt.

Eine polnische Klinik hat ihre Patientinnen und Patienten inzwischen darüber informiert, dass zwei verschiedene von ihr genutzte Softwareanbieter, MyDr und Medyc von Qbusoft, von Datenlecks betroffen waren. Ihre Mitteilung zu MyDr und ihre Mitteilung zu Medyc beschreiben die Vorfälle getrennt. Das führt vor Augen, dass sich die Risiken mehrerer Zulieferer für eine Klinik überlagern können, selbst wenn nichts auf eine gemeinsame technische Ursache der Angriffe hindeutet.

Was ist über den Vorfall bei Medyc bekannt?

Die Klinik führt die technischen Erkenntnisse in ihrer Mitteilung auf eine Untersuchung von Qbusoft mit forensischen Fachleuten zurück. Demnach nutzte ein Angreifer am 22. und 23. August 2026 eine SQL-Injection-Schwachstelle in einer Medyc-Anwendungsschnittstelle und übertrug ein verschlüsseltes Datenbankarchiv aus der Umgebung von Qbusoft. Der Einbruch wurde in der Nacht vom 8. auf den 9. September entdeckt. Laut Klinik behob Qbusoft die Schwachstelle noch am Tag der Entdeckung, schränkte Datenbankberechtigungen ein, erneuerte technische Geheimnisse und meldete den Fall der Polizei und der polnischen Datenschutzbehörde.

Für Patientinnen und Patienten der Tagesstation zur Behandlung von Suchterkrankungen nennt die Mitteilung Daten, die nachweislich im heruntergeladenen Archiv enthalten waren: Namen, polnische PESEL-Nummern, Adressen, Telefonnummern und E-Mail-Adressen. Der Mitteilung zufolge waren Namen und PESEL-Nummern verschlüsselt gespeichert. Qbusoft riet der Klinik jedoch, davon auszugehen, dass die Angreifer diese beiden Felder leicht entschlüsseln und im Klartext erlangen konnten. Skripte zielten auch auf Tabellen mit medizinischen Daten. Deshalb hält die Klinik es für sehr wahrscheinlich, dass auch Entlassungsberichte entnommen wurden. Die Mitteilung bestätigt nicht, dass Entlassungsberichte kopiert wurden.

Die polnische Datenschutzbehörde UODO erklärte am 25. September, Medienberichten zufolge könnten bis zu fünf Millionen Menschen betroffen sein; sie plane eine Prüfung von Qbusoft. Das ist keine verifizierte Zahl der Betroffenen. Die Behörde wiederholte außerdem die Aussage des Digitalministers vom 24. September, Qbusoft habe den Vorfall bis dahin weder CERT Polska noch dem CSIRT des Gesundheitssektors gemeldet. Die Angaben der Klinik zu Meldungen an Polizei und UODO betreffen andere Empfänger; beide Darstellungen können daher zutreffen.

Der Bericht von Zaufana Trzecia Strona stellt eine Verbindung zwischen dem Medyc-Fall und dem Akteur hinter dem früheren MyDr-Fall her. Öffentliche Behörden haben diese Zuordnung in den für diesen Artikel verfügbaren Quellen nicht bestätigt. Die entscheidende betriebliche Erkenntnis hängt nicht von der Identität des Angreifers ab: Durch eine SQL-Injection-Schwachstelle in einer Schnittstelle der Medyc-Anwendung konnten Berichten zufolge Daten aus der Umgebung des Anbieters abfließen.

Warum Meldeweg und Prämien vor der ersten Meldung einrichten?

SQL Injection ist eine Art von Anwendungsfehler, die ein externer Sicherheitsforscher möglicherweise ohne privilegierten Zugang erkennen kann. Ein Programm kann festlegen, welche Systeme für Tests freigegeben sind, wie sich ein Fund ohne Einsicht in echte Patientenakten belegen lässt, wohin die Meldung gehört und wann eine Antwort zu erwarten ist. Die NIST-Empfehlungen zur Offenlegung von Schwachstellen raten zu einem geregelten Verfahren, um Meldungen anzunehmen, zu bewerten, zu bearbeiten und über ihre Behebung zu informieren. Sie versprechen nicht, dass ein solches Verfahren jeden Fehler findet.

Beginnen Sie mit einem Vulnerability Disclosure Program (VDP): einem öffentlichen Kontakt, einem definierten Geltungsbereich, Testregeln, Safe-Harbor-Bedingungen, einer betreuten Eingangsablage und einem Weg von der bestätigten Meldung bis zur Korrektur. Ergänzen Sie dann ein bezahltes Bug-Bounty-Programm, sobald das Team zusätzliche Meldungen bearbeiten kann und ein Prämienbudget freigegeben ist. Die Aussicht auf eine Prämie gibt Forschern einen Grund, Zeit in Ihr Produkt zu investieren. Erst Annahme und Behebung machen diese Aufmerksamkeit nützlich. Wenn Ihre Organisation beides bereits tragen kann, veröffentlichen Sie beides jetzt. Während eines Vorfalls lassen sich die ersten Testregeln nur schwer festlegen.

Keiner der öffentlichen Berichte zu Medyc belegt, dass ein gutwilliger Forscher diese SQL-Injection-Schwachstelle schon früher gefunden oder zu melden versucht hat oder sie im Rahmen eines Bug-Bounty-Programms entdeckt hätte. Ein solches Programm ersetzt auch keine sicheren Datenbankabfragen, Code-Reviews, Penetrationstests, Protokollierung, möglichst eng begrenzte Datenbankrechte oder die Reaktion auf Sicherheitsvorfälle. Es gibt Forschern einen Weg, einen Fehler zu melden, solange noch Zeit für eine Korrektur ist.

Wie können Forscher testen, ohne Patientendaten offenzulegen?

Ein Programm für medizinische Software muss die Grenze konkret festlegen. Die Richtlinie des US-Gesundheitsministeriums zur Meldung von Schwachstellen zeigt ein brauchbares Muster: nur ausdrücklich genannte Systeme testen, einen Exploit nur so weit nutzen, wie es zum Nachweis nötig ist, bei sensiblen Daten aufhören und keine Datensätze abziehen. Ein Anbieter kann solche Regeln an seine Architektur und rechtliche Beratung anpassen. Sie sind keine Erlaubnis, Systeme anderer Organisationen zu testen.

Doctolibs öffentliches Bug-Bounty-Programm ist ein Beispiel aus dem Gesundheitswesen mit festgelegtem Geltungsbereich, Prämien und Testbedingungen. Ein kleinerer Anbieter muss weder die Prämienhöhen noch den Umfang des Programms übernehmen. Er kann sich daran orientieren, klar zu veröffentlichen, wo Forscher testen dürfen und wie sie die Versorgung von Patienten unberührt lassen.

Proben Sie den Ablauf intern, bevor Sie das Programm öffnen: Reichen Sie eine fiktive Meldung ein, verfolgen Sie Eingang und Zuweisung, prüfen Sie die Reaktionsfrist, beheben Sie den Fehler und schicken Sie dem Forscher eine Abschlussnachricht. Beheben Sie versäumte Übergaben, bevor Sie weitere Sicherheitsforscher einladen.

Welche Anbieter medizinischer Software sollten jetzt darüber nachdenken?

Ein Anbieter, der Akten für viele voneinander unabhängige Kliniken verwahrt, trägt jeder einzelnen gegenüber Verantwortung: Ein einziger Anwendungsfehler kann jede dieser Kliniken zwingen, die mögliche Offenlegung ihrer Patientendaten zu prüfen. Anbieter von Software für elektronische Patientenakten, Praxisverwaltung und Terminbuchung sollten einen Meldeweg veröffentlichen, bevor sie ihn dringend brauchen. Für gehostete Produkte und von Kliniken selbst betriebene Installationen können unterschiedliche Testgrenzen nötig sein. Jedes Programm darf nur Systeme nennen, die dem Anbieter gehören oder für deren Tests er eine ausdrückliche Erlaubnis hat.

Für die Technik- oder Sicherheitsverantwortlichen eines Anbieters lautet die entscheidende Frage: Könnte ein Forscher heute die richtige Kontaktstelle finden, eine patientenschonende Meldung einreichen und damit eine Person erreichen, die den Fehler beheben darf? Ist die Antwort unklar, erfassen Sie die Systeme und bestimmen Sie jetzt diese verantwortliche Person. Eine Klinik kann dieselbe Frage stellen, wenn sie das Risiko eines Softwareanbieters prüft. Die frühere Analyse zum MyDr-Datenleck behandelt die Grenzen von Meldekanälen bei verschiedenen Arten von Datenlecks. Der Medyc-Fall unterstreicht, wie wichtig es ist, festzulegen, welche Produktschnittstellen externe Forscher gefahrlos testen und zu welchen sie Meldungen einreichen dürfen.

Wie hilft Kit beim Betrieb eines Meldeprogramms im Gesundheitswesen?

Kit bietet einem Sicherheitsteam ein öffentliches Meldeportal samt Programmeinrichtung, eine generierte security.txt, einen veröffentlichten Geltungsbereich, die Zuweisung und Sichtung von Meldungen, die Kommunikation mit Forschern und die Verfolgung von SLA-Fristen. Ein Team, das Prämien zahlen möchte, kann Prämienbereiche festlegen, Vorschläge beraten, Freigaben dokumentieren und die Übergabe zur Auszahlung verfolgen. Beginnen Sie mit einem Geltungsbereich, der nur eigene oder ausdrücklich für Tests freigegebene Systeme umfasst, und mit Regeln zum Schutz der Patienten bei diesen Tests. Prüfen Sie dann mit einer fiktiven Meldung den gesamten Weg vom Eingang bis zum Abschluss.

Kit sucht nicht nach SQL Injection, macht Datenbankabfragen nicht sicher und beweist nicht, dass ein Anbieter vor Datenlecks geschützt ist. Das bleiben Aufgaben der Entwicklung und der Reaktion auf Sicherheitsvorfälle. Kit hilft einem externen Forscher, das für die Korrektur zuständige Team zu erreichen, und hält fest, wer die Meldung verantwortet und was als Nächstes geschieht. Die Einrichtung beschreibt der Leitfaden für Vulnerability Disclosure Programs.