Wie ein Datenleck in einem Arzt-Terminservice monatelang offen bleiben konnte

Inhaltsverzeichnis

Responsible Disclosure beschreibt den verantwortungsvollen Umgang mit Sicherheitslücken, bei dem zuerst das Unternehmen informiert wird und erst im Nachgang die Öffentlichkeit. Ein tolles Konzept, wenn es denn funktioniert.

Dass das längst nicht immer so ist, zeigt der folgende Fall, in dem Informationen zu schätzungsweise mehr als 15.000 Patienten zugänglich waren – für jede bei dem Portal angemeldete Person. Zu den Daten gehörten etwa die Namen, häufig auch die Telefonnummern für die SMS-Erinnerung, wann die Patienten bei welchem Arzt waren und gegebenenfalls die Notizen des Arztes. Anschließend genügte ein Blick in die Konsole der Webanwendung, um die Informationen zu sehen und möglicherweise mitzuschneiden, sobald Personen in der Warteschlange des Dienstes auftauchten. Doch wie kam es dazu?

Dienst soll Wartezeiten verkürzen

Bei Arztterminen müssen Patientinnen und Patienten oft lange Wartezeiten in Kauf nehmen. Die eingesetzte Warteschlangen-Software des österreichischen Start-up-Unternehmens Quickticket verspricht, die Zeiten im Wartezimmer zu minimieren. Patienten können sich bei ihrem Arzt, entweder digital oder aus Papier, ein Ticket ziehen und werden über ihren Platz in der Warteschlange informiert. Einige Praxisverwaltungssysteme nutzen dafür eine automatische Synchronisation zu Quickticket. Dummerweise konnte nicht nur das Praxispersonal sehen, welcher Patient aus der Arztpraxis in der Warteschlange als Nächstes dran war, sondern prinzipiell alle auf dem Webportal angemeldeten Personen – ein Testaccount reichte dafür aus. Denn die von dem Start-up programmierte Software hatte Sicherheitslücken.

Martin Tschirsich, der die Lücke entdeckt hat, hatte die österreichische Firma bereits Mitte November 2022 auf das Problem sowie die Informationspflicht bei derartigen Datenschutzverstößen hingewiesen und unentgeltlich seine Hilfe dabei angeboten, die Sicherheitslücke zu schließen. Eine Meldung des Vorfalls bei der zuständigen Datenschutzbehörde, zu der das Unternehmen verpflichtet war, erfolgte jedoch nicht.

Die weitere Kommunikation zwischen Tschirsich und dem Start-up ging munter hin und her, war stets freundlich, aber die Lücken blieben offen. Dem Eindruck nach war sich das Unternehmen zunächst nicht über die Tragweite seines Handelns bewusst. Da das Unternehmen nicht angemessen auf die Sicherheitsmeldung reagierte, wandte sich Tschirsich, wie vom Bundesamt für Sicherheit in der Informationstechnik in ihrer FAQ für Sicherheitsforschende empfohlen, an CERT-Bund – einem Team von Sicherheitsexperten des BSI – mit einem Bericht über den Vorfall:

Aufgrund diverser Sicherheitsmängel ist es Dritten jederzeit möglich, das Geschehen auf allen Wartelisten in Echtzeit mitzuverfolgen. Das Echtzeitgeschehen auf den Wartelisten wird über Websockets kommuniziert, die eingehende Verbindungen ohne Authentisierungsprüfung annehmen. Zudem sind diverse REST-API-Endpunkte ohne Authentisierungsprüfung zugänglich. Preisgegeben werden Namen und gegebenenfalls Telefonnummern von Patienten, deren Behandler, Zeitpunkt und Ort der Leistungserbringung sowie gegebenenfalls weitere Notizen des medizinischen Personals zum Behandlungsfall. Es handelt sich folglich um Gesundheitsdaten beziehungsweise besondere Kategorien personenbezogener Daten nach Art. 9 DSGVO.

Der CERT-Bund erstellte ein Ticket zur Sicherheitsmeldung. Da "eine gesetzliche Legitimation des BSI zur Anordnung der Behebung von Schwachstellen" laut BSI nicht besteht, ist es folglich "nicht dazu befugt, das weitere Vorgehen zu koordinieren", sondern fungiert lediglich als Mittler zwischen den Parteien. Erst eine weitere Woche später, nachdem Tschirsich das Start-up über die Datenschutzlücke informiert hatte, entschied sich CERT-Bund dazu, das CVD-Verfahren (Coordinated Vulnerability Disclosure) – zum Umgang mit Sicherheitslücken – zu starten. CERT-Bund informierte Quickticket über die Schwachstelle und wies gleichzeitig auf deren Schwere hin.

Außerdem informierte CERT-Bund sein österreichisches Pendant (CERT-AT) und bat Quickticket um eine Stellungnahme. Eine Woche später, Mitte Dezember, informierte Quickticket CERT-Bund darüber, die Sicherheitslücke geschlossen zu haben. Dem war jedoch nicht so.

Gemäß Leitlinie ist "in Absprache mit den Sicherheitsforschenden" eine Frist von 45 bis 90 Tagen zu setzen. Tschirsich hatte dem BSI dazu geraten, dem Unternehmen eine möglichst kurze Frist zu setzen, da besonders schützenswerte Daten betroffen waren und aufgrund des bereits aufgelaufenen Zeitverzugs. Der CERT-Bund rät jedoch dazu, "mindestens die Industrie-üblichen 90 Tage als Frist zu verwenden". Zum Vergleich, Googles Projekt Zero definiert eine 7-Tage-Frist bei aktiv ausgenutzten Schwachstellen.

BSI verweist zurück an Sicherheitsexperten

Nach weiterer Kommunikation mit Quickticket verwies das BSI das Unternehmen an den Sicherheitsforscher, für den direkten Austausch. Das noch bestehende Angebot von Tschirsich nahm das Unternehmen aber nicht in Anspruch. Auch die Meldung an die österreichische Datenschutzbehörde fehlte weiterhin. Gegenüber dem CERT-Bund sagte Quickticket, man arbeite an der Behebung der Sicherheitslücke – wohl erfolglos. Nachdem alle Möglichkeiten der CVD-Leitlinie ausgeschöpft waren, sah der Sicherheitsexperte keinen anderen Ausweg, als die Lücke öffentlich zu machen, um weiteren möglichen Schaden zu verhindern. Aus Sicht des CERT-Bunds sprach ebenfalls nichts dagegen, empfahl aber, das Unternehmen über die nächsten Schritte und die Gründe für diese zu informieren.

Tschirsichs Bemühungen blieben weiterhin erfolglos, denn eigentlich hätte das Unternehmen die Sicherheitslücke schließen und darüber informieren müssen. Aufgrund des gescheiterten CVD-Prozesses wandte sich der Sicherheitsforscher an heise online. Nachdem wir aufgrund des Vorfalls eine Anfrage an das Unternehmen gestellt hatten, zeigte sich Quickticket verwundert und teilte zunächst mit, die gemeldeten Schwachstellen seien "rasch" behoben worden. Das war nicht der Fall, wie wir mithilfe des Sicherheitsforschers dokumentieren konnten. Erst der mediale Druck schien Wirkung zu zeigen und führte dazu, dass die beanstandeten Lücken anscheinend geschlossen wurden. Parallel dazu hat Quickticket nach eigenen Angaben die österreichischen Datenschutzbehörden informiert und einen eigenen Sicherheitsberater hinzugezogen – Monate, nachdem sie über das Datenleck Bescheid gewusst hatten.

Frustrierender CVD-Prozess

Über den gesamten Ablauf zeigt sich der Sicherheitsexperte verärgert. Er hatte mehrfach seine Hilfe angeboten, doch seine Bemühungen, Patientinnen und Patienten zu schützen, blieben lange erfolglos. Offen bleibt die Frage, warum das Unternehmen den Datenschutzvorfall erst auf Nachfrage von heise online gemeldet hatte. Informationen darüber, dass es sich bei dem Datenleck um einen meldepflichtigen Datenschutzvorfall handelt, hatte das Unternehmen bereits im November. Während der gesamten Zeit warb es trotz offener Lücke weiterhin für seinen Dienst und gewann in der Zeit neue Kunden. Bis Ende Februar wurden weder Arztpraxen noch Patienten über die Sicherheitslücke informiert.

Klare Datenschutzverstöße

Laut Thilo Weichert, dem ehemaligen Datenschutzbeauftragten von Schleswig-Holstein, zeigt dieser Fall Datenschutzverstöße – nach Artikel 9, 25 und 32 der Datenschutzgrundverordnung. Dadurch, dass Dritte sehen konnten, bei welchem Arzt Patienten waren, liegt klar ein Verstoß nach Artikel 9, "der Verarbeitung besonderer Kategorien personenbezogener Daten" vor. Außerdem hätte das Unternehmen den Fall unverzüglich den beteiligten Ärzten melden müssen, damit diese innerhalb von 72 Stunden nach Bekanntwerden die zuständigen Datenschutzbehörden und ihre Patientinnen und Patienten über den Datenschutzvorfall informieren können.

Das ganze Verhalten und die Unkenntnis des Unternehmens zeugt von mangelndem Wissen um die gültigen Datenschutzgesetze. Überdies stellt sich die Frage, warum es bei im Gesundheitswesen eingesetzten Produkten wie Terminservice-Portalen keine Zulassungsstelle gibt, wie beispielsweise bei Medizinprodukten.

Meldeprozess verbesserungswürdig

Ebenfalls unklar ist, warum die Sicherheitslücke monatelang offen bleiben konnte und bei wem die Verantwortlichkeiten in diesem Fall liegen. Die meldende Person wird für ihren Einsatz nicht honoriert. Noch schlimmer: Unternehmen könnten Anzeige gegen Sicherheitsexperten erstatten, die möglicherweise weitere Konsequenzen nach sich zieht. Verschiedene Experten, unter anderem der CCC und auch die AG Kritis, fordern das sofortige Beheben der Sicherheitslücken nach deren Bekanntwerden und eine Verbesserung des Meldeprozesses.

Gefordert wird außerdem eine zentrale Meldestelle für Sicherheitsvorfälle. "Das BSI ist die am besten geeignete zentrale Anlaufstelle von Sicherheitslücken in Deutschland. Es kann Sicherheitsexperten nicht auch noch angelastet werden, sich lange mit unklaren Zuständigkeiten und möglicher Verantwortungsdiffusion beschäftigen zu müssen", sagt die Sicherheitsforscherin und Vorsitzende des Innovationsverbundes öffentliche Gesundheit, Bianca Kastl. In der Regel werden meldende Person für ihren Einsatz nicht honoriert – im schlimmsten Fall droht ihnen sogar eine Anzeige.

Nach Ansicht von Kastl braucht es daher "einen verlässlichen Single Point of Contact – mit dem der verantwortungsvolle Umgang mit Sicherheitslücken auch zu Ende geführt werden kann. Nichts wäre für Sicherheitsexperten nerviger, als am Ende wieder alleine mit dem Problem dazustehen".

Auszüge aus der DSGVO zu Artikel 9, 25 und 32

Artikel 9: Verarbeitung besonderer Kategorien personenbezogener Daten
Die Verarbeitung personenbezogener Daten, aus denen die rassische und ethnische Herkunft, politische Meinungen, religiöse oder weltanschauliche Überzeugungen oder die Gewerkschaftszugehörigkeit hervorgehen, sowie die Verarbeitung von genetischen Daten, biometrischen Daten zur eindeutigen Identifizierung einer natürlichen Person, Gesundheitsdaten oder Daten zum Sexualleben oder der sexuellen Orientierung einer natürlichen Person ist untersagt.

Artikel 25: Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen

1. Unter Berücksichtigung des Stands der Technik, der Implementierungskosten und der Art, des Umfangs, der Umstände und der Zwecke der Verarbeitung sowie der unterschiedlichen Eintrittswahrscheinlichkeit und Schwere der mit der Verarbeitung verbundenen Risiken für die Rechte und Freiheiten natürlicher Personen trifft der Verantwortliche sowohl zum Zeitpunkt der Festlegung der Mittel für die Verarbeitung als auch zum Zeitpunkt der eigentlichen Verarbeitung geeignete technische und organisatorische Maßnahmen – wie z. B. Pseudonymisierung –, die dafür ausgelegt sind, die Datenschutzgrundsätze wie etwa Datenminimierung wirksam umzusetzen und die notwendigen Garantien in die Verarbeitung aufzunehmen, um den Anforderungen dieser Verordnung zu genügen und die Rechte der betroffenen Personen zu schützen.

2. Der Verantwortliche trifft geeignete technische und organisatorische Maßnahmen, die sicherstellen, dass durch Voreinstellung nur personenbezogene Daten, deren Verarbeitung für den jeweiligen bestimmten Verarbeitungszweck erforderlich ist, verarbeitet werden. 2Diese Verpflichtung gilt für die Menge der erhobenen personenbezogenen Daten, den Umfang ihrer Verarbeitung, ihre Speicherfrist und ihre Zugänglichkeit. 3Solche Maßnahmen müssen insbesondere sicherstellen, dass personenbezogene Daten durch Voreinstellungen nicht ohne Eingreifen der Person einer unbestimmten Zahl von natürlichen Personen zugänglich gemacht werden.

3. Ein genehmigtes Zertifizierungsverfahren gemäß Artikel 42 kann als Faktor herangezogen werden, um die Erfüllung der in den Absätzen 1 und 2 des vorliegenden Artikels genannten Anforderungen nachzuweisen.

Artikel 32: Sicherheit der Verarbeitung
1. Unter Berücksichtigung des Stands der Technik, der Implementierungskosten und der Art, des Umfangs, der Umstände und der Zwecke der Verarbeitung sowie der unterschiedlichen Eintrittswahrscheinlichkeit und Schwere des Risikos für die Rechte und Freiheiten natürlicher Personen treffen der Verantwortliche und der Auftragsverarbeiter geeignete technische und organisatorische Maßnahmen, um ein dem Risiko angemessenes Schutzniveau zu gewährleisten; diese Maßnahmen schließen gegebenenfalls unter anderem Folgendes ein:
- die Pseudonymisierung und Verschlüsselung personenbezogener Daten
- die Fähigkeit, die Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme und Dienste im Zusammenhang mit der Verarbeitung auf Dauer sicherzustellen
- die Fähigkeit, die Verfügbarkeit der personenbezogenen Daten und den Zugang zu ihnen bei einem physischen oder technischen Zwischenfall rasch wiederherzustellen
- ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der technischen und organisatorischen Maßnahmen zur Gewährleistung der Sicherheit der Verarbeitung.
2. Bei der Beurteilung des angemessenen Schutzniveaus sind insbesondere die Risiken zu berücksichtigen, die mit der Verarbeitung verbunden sind, insbesondere durch – ob unbeabsichtigt oder unrechtmäßig – Vernichtung, Verlust, Veränderung oder unbefugte Offenlegung von beziehungsweise unbefugten Zugang zu personenbezogenen Daten, die übermittelt, gespeichert oder auf andere Weise verarbeitet wurden.
3. Die Einhaltung genehmigter Verhaltensregeln gemäß Artikel 40 oder eines genehmigten Zertifizierungsverfahrens gemäß Artikel 42 kann als Faktor herangezogen werden, um die Erfüllung der in Absatz 1 des vorliegenden Artikels genannten Anforderungen nachzuweisen.
4. Der Verantwortliche und der Auftragsverarbeiter unternehmen Schritte, um sicherzustellen, dass ihnen unterstellte natürliche Personen, die Zugang zu personenbezogenen Daten haben, diese nur auf Anweisung des Verantwortlichen verarbeiten, es sei denn, sie sind nach dem Recht der Union oder der Mitgliedstaaten zur Verarbeitung verpflichtet.

(mack)