Schutz gegen Cyberangriffe – was tun bei Software als Medizinprodukt? Schutz gegen Cyberangriffe – was tun bei Software als Medizinprodukt?

Sabine Koll
Journalistin in Böblingen

Anfang Oktober startete das Verzeichnis der digitalen Gesundheitsanwendungen (Diga), also die „App auf Krankenschein“. Und schon wenige Tage danach war eine der beiden gelisteten Diga von IT-Sicherheitsexperten gehackt. Diese haben sich mit einfachen Mitteln Zugriff auf Konten von Nutzern verschafft. Das Bundesinstitut für Arzneimittel und Medizinprodukte (Bfarm), das die Anwendungen im Auftrag des Gesundheitsministeriums in punkto Datenschutz und Datensicherheit prüft, reagierte schnell, und der Fehler wurde durch den Hersteller beseitigt.

Für die Reputation von Medizintechnik-Herstellern sind solche Cybercrime-Vorfälle ein Horrorszenario. Aber was sollte man tun? „Es gibt im Moment noch keine gesamthafte Norm in diesem Bereich für die Branche“, stellte Hans Wenner, Inhaber des Ingenieurbüros Wenner in Rüsselsheim, während der Online-Fachveranstaltung „Cybersecurity bei Medizinprodukten“ des VDE-Bereichs Medizinprodukte und Software (Meso) klar. „Deshalb ziehen Auditoren Benannter Stellen verschiedene, bereits vorhandene Papiere als Stand der Technik heran und prüfen die Hersteller danach.“

BSI TR-03161 ist verpflichtend für Apps auf Krankenschein

Dazu gehört die im April 2020 veröffentlichte Technische Richtlinie BSI TR-03161 „Sicherheitsanforderungen an digitale Gesundheitsanwendungen“. Sie ist in deutscher Sprache verfasst und muss von allen Herstellern angewendet werden, die eine Diga für mobile Endgeräte in Verkehr bringen wollen. Das Bfarm nutzt die BSI TR-03161 als Grundlage für seine Diga-Prüfungen, und auch die Corona-Warn-App des Bundes erfüllt nach Aussage des BSI die Anforderungen der Technischen Richtlinie. Doch auch über den Fokus Diga hinaus kann die Richtlinie laut Wenner sehr gute Dienste leisten. Zudem habe sie das Zeug dazu hat, in Zukunft Basis für eine Norm zu sein, denn mit dem BSI steht immerhin die Cyber-Sicherheitsbehörde des Bundes dahinter.

BSI TR-03161 befindet sich im „Trial in Use“, also in der Erprobung im Einsatz. Das heißt laut Wenner, dass Erfahrungswerte bezüglich der Prüfung gesammelt werden und dass es zu Änderungen kommen kann. „Außerdem sollen später Kapitel ergänzt werden, die eine Zertifizierung nach der Richtlinie ermöglichen“, so der Berater.

Worauf bei Cybersecurity zu achten ist

Die prinzipielle Methodik des BSI-Dokuments umfasst eine Security Problem Definition, die mögliche Bedrohungsszenarien aufzeigt. Dabei werden acht konkrete Beispiele genannt – etwa zum Thema Authentifizierung. Es werden organisatorische Sicherheitspolitiken aufgeführt, beispielsweise dass die Anwendung sensible Daten nicht im Klartext an externe Frameworks oder Bibliotheken weitergeben soll. Wenner: „Das ist eine sehr gute Anforderung, die nicht überall umgesetzt wird. So werden zum Beispiel immer wieder Cloud-Speicher für Backups mit sensiblen Daten, die nicht verschlüsselt sind, genutzt.“ Das BSI-Papier macht dabei auch konkrete Angaben zum Cloud-Anbieter: Dieser darf die Daten nicht dort vorhalten, wo sie nicht unter deutsches Datenschutzrecht wie etwa die Datenschutzgrundverordnung fallen. Daraus werden elf Prüfaspekte abgeleitet, die vor Bedrohungen schützen sollen: Sie sind in die vier Kategorien „Muss“, „Darf nicht“, „Soll“ und „Kann“ unterteilt.

„Der große Vorteil der BSI TR-03161 ist, dass sie im Vergleich zu vielen Richtlinien und Normen äußerst konkret ist – etwa beim Aufzeigen potenzieller Bedrohungsszenarien“, sagt Wenner. „Als Nachteil wiederum sehe ich, dass die Richtlinie sehr umfangreich und detailliert ist. Kunden sind zum Teil erschrocken, wie umfangreich und genau diese Anforderungen an manchen Stellen sind. Auch sind einzelne Anforderungen im Kontext beziehungsweise in Kombination manchmal sehr schwer umzusetzen.“ So hält er beispielsweise das Konzept der Zwei-Faktor-Authentifizierung in Verbindung mit der Anforderung, dass eine erneute Authentifizierung gefordert werden muss, sobald die Software in den Hintergrundmodus versetzt wird, für schwer umsetzbar. Die Gebrauchstauglichkeit leide darunter. „Die Umsetzung aller Prüfaspekte der BSI TR-03161 stellt Hersteller vor große Herausforderungen, das könnte eine Hürde für das Erstellen und die Bewertung einer Diga darstellen“, lautet sein Fazit. Er empfiehlt daher: „Schauen Sie das BSI-Dokument an, es enthält viele wirklich interessante Aspekte. Aber seien Sie froh, dass Sie manche nur umsetzen müssen, wenn Sie eine Diga entwickeln.“

Anhaltspunkt: Guidance on Cybersecurity for medical Devices

Als zweites aktuelles Dokument stellte Wenner die MDCG 2019-16 „Guidance on Cybersecurity for medical Devices“ vom Dezember 2019 vor. Sie hat für die Entwicklung von Software als Medizinprodukt ebenfalls keinen verbindlichen Charakter. Doch steht dahinter mit der MDCG, welche die Europäische Kommission berät und bei der Umsetzung der Medical Device Regulation (MDR) unterstützt, ebenfalls ein Schwergewicht, sodass Auditoren Benannter Stellen sich gerne darauf stützen.

Wesentlich Neues bringt das MDCG-Papier nicht für diejenigen, die sich mit dem Thema Cybersecurity bereits befasst hat. Im Gegenteil: „Es nimmt Bezug auf viele schon vorhandene Dokumente“, stellt Wenner fest. So decken nach seiner Einschätzung die künftige Norm ISO/IEC 81001-5-1 „Health software and health IT systems safety, effectiveness and security – Part 5-1: Security – Activities in the product life cycle“ und technische Reports wie IEC/TR 80001-2-2 oder IEC/TR 60601-4-5 „die Inhalte der MDCG 2019-16 einigermaßen ab“.

Das Motto sollte sein: Security by Design

Für sinnvoll erachtet der Berater die Hinweise im Leitfaden, dass Safety und Security nicht voneinander zu trennen sind, sowie die Empfehlung, nach dem Prinzip „Security by Design“ zu arbeiten. Letzteres heißt, dass schon während des Entwicklungszyklus’ Sicherheitsanforderungen an die Software einzubeziehen sind, um spätere Sicherheitslücken zu verhindern. „Und das sollte im gesamten Software-Lebenszyklus beibehalten werden“, so Wenner.

„Unternehmen, die Software als Medizinprodukt entwickeln, sehen im Dschungel von Richtlinien oft den Wald vor lauter Bäumen nicht. Man sollte im ersten Schritt für sich also festlegen, welche Richtlinie oder Norm für die zu entwickelnde Software greift. Und dann muss man im nächsten Schritt verstehen, was konkret zu tun ist“, betont Wenner. Nach einem pragmatischen Ansatz gefragt, antwortet er: „Das Risikomanagement ist der Dreh- und Angelpunkt von allem. Über Risiken nachzudenken und diese zu dokumentieren, das ist das A und O.“ Und auch dafür gibt es ein neues druckfrisches Dokument mit der DIN EN ISO 14971:2020 (Edition 3), der Norm für das Risikomanagement für Medizinprodukte. Sie wurde im Juli 2020 veröffentlicht und schließt nun auch die Betrachtung von Risiken mit ein, die sich auf Daten- und Informationssicherheit beziehen.

Unsere Webinar-Empfehlung

Webinar: medizin&technik Konradin-Verlag Robert Kohlhammer GmbH

Innovationstage Medizintechnik September 2022 (Teil 2)

Erfahren Sie, was sich in der Medizintechnik-Branche derzeit im Bereich 3D-Druck, Digitalisierung & Automatisierung sowie beim Thema Nachhaltigkeit tut.

• Mehr lesen