Ist das eigene Medizinprodukt ausreichend vor Cyberangriffen geschützt? „Ja“, werden Hersteller antworten, und das mit einer durchgeführten Risikoanalyse auf Produktebene untermauern. Doch so einfach ist es nicht, denn zwei entscheidende Dinge können weiterhin ein paar Einfallstore für Unbefugte ins Produkt schmuggeln.
Ein Beitrag von Dr. Martin Neumann, Consultant Life Science bei infoteam
Eine Warnung auf der Website des Bundesinstituts für Arzneimittel und Medizinprodukte (BfArM) lautete zusammengefasst: „Angreifer können auf einem medizinischen Gateway-Gerät, das Beatmungsgeräte, Infusionspumpen und andere medizinische Geräte mit dem Netzwerk verbindet, Administratorrechte erlangen und Code aus der Ferne ausführen.“ Tatsächlich ist die Schwachstelle bereits seit Jahren bekannt und ein Angriff wäre sogar fast für Laien möglich. Trotzdem brachte die geringe Beachtung von Cybersicherheit-Best-Practices im Lebenszyklus die Schwachstelle in ein Medizinprodukt, wo sie (erneut) entdeckt wurde. Dieses Beispiel und diverse Statistiken zeigen, dass Softwareschwachstellen und Cyberangriffe auch bei Medizinprodukten enorm zunehmen. Hersteller von Medizinprodukten sollten deshalb die Cybersicherheit ihrer Produkte schon von Beginn an mitdenken – nicht zuletzt auch wegen der gestiegenen gesetzlichen und regulatorischen Anforderungen.
Regulatorische Grundlagen für Cybersicherheit
Bereits die EU-Verordnungen 2017/745 (EU-MDR) und 2017/746 (EU-IVDR) fordern im Anhang I direkt und indirekt die Berücksichtigung der IT-Sicherheit. Am bekanntesten sind die Punkte 17.2 bzw. 16.2, denn hier steht u. a. die Forderung nach einem „State-of-the-Art“-Produktlebenszyklus, der auch die IT-Sicherheit berücksichtigt. Die Medical Device Coordination Group (MDCG) hat passend dazu den Leitfaden 2019-16 für Cybersecurity veröffentlicht. Er bietet einen guten Einstieg in die Thematik und stellt ebenfalls die Prinzipien „Secure by design“ sowie die Security-Aktivitäten über den gesamten Produktlebenszyklus heraus. Ebenfalls relevant ist die Norm IEC 81001-5-1, die von benannten Stellen bereits verstärkt eingefordert wird und für 2024 zur Harmonisierung vorgeschlagen ist. Sie liefert die Grundlage für einen „Secure Software Product Life Cycle“ (SSPLC).
Hinzu kommen EU-Gesetze, die noch in Planung sind bzw. demnächst in Kraft treten. Sie werden verstärkt ihren Fokus auf die IT-Sicherheit legen, beispielsweise die NIS2-Direktive. Sie definiert Pflichten für die Informationssysteme im Unternehmen, betrachtet den Umgang mit sicherheitsrelevanten Vorfällen und fordert die Gewährleistung der Sicherheit innerhalb der Lieferkette. Dieser unscheinbare letzte Punkt ist ein wesentlicher, denn er betrachtet nicht nur die Hersteller von Medizinprodukten selbst, sondern nimmt auch die Lieferkette als potenzielles Einfallstor für Sicherheitslücken ins Visier. Hersteller müssen deshalb sowohl aufgrund gesetzlicher Vorgaben als auch aus Eigeninteresse für die Sicherheit der eigenen Produkte ihre Lieferketten qualifizieren. Medizinproduktehersteller sollten deshalb auf Softwarezulieferer und Softwaredienstleister bauen, die ein gelebtes integriertes Managementsystem haben – bestehend aus Qualitätsmanagement (ISO 13485) und Informationssicherheitsmanagement (ISMS) (z. B. ISO 27001). Die EU-Länder sollen NIS2 bis Oktober 2024 in nationales Recht übertragen.
Und noch ein weiteres Gesetz ist für Medizinproduktehersteller mitunter relevant, obwohl es Medizinprodukte und In-vitro-Diagnostika explizit ausnimmt: Der Cyber Resilience Act (CRA) richtet sich an Produkte „mit digitalen Elementen“ wie Hard- und Software (Open-Source-Software ausgenommen) und verpflichtet die Hersteller auch hier, die Cybersicherheit für den gesamten Produktlebenszyklus („Security by design“) aufrechtzuerhalten und ein Schwachstellenmanagement zu betreiben – analog zu Medizinprodukten. Für die Hersteller von Medizinprodukten wird der CRA dann relevant, wenn nur Teilbereiche ihres Gesamtsystems als Medizinprodukt definiert sind und die Hard- und Softwarekomponenten der anderen Teilbereiche somit unter den CRA fallen.
Integration von Cybersicherheitsaktivitäten in den Produktlebenszyklus
Der Softwareproduktlebenszyklus (SPLC) ist komplex und umfasst mehrere Stufen. Für IT-Sicherheit auf dem aktuellen Stand der Technik muss er nun noch zusätzlich um Cybersicherheitsaktivitäten ergänzt werden, so dass aus dem SPLC der SSPLC wird (Secure SPLC). Der SSPLC unterteilt sich grob in zwei Ebenen: Die organisatorische Ebene beschreibt das gesamte Unternehmensgerüst, das für die Herstellung eines Medizinprodukts notwendig ist – also beispielsweise die Mitarbeiter und die genutzten IT-Systeme. Ihr Schutzbedürfnis ergibt sich daraus, dass „Secure by design“ (das System ist aufgrund seiner Entwicklung sicher) und „Secure by default“ (das System ist in den Standardeinstellungen ausreichend sicher) nur dann möglich sind, wenn auch die Entwicklungsumgebungen und -bedingungen vor Angriffen von außen geschützt sind, also beispielsweise Entwicklungsrechner frei von Trojanern und Viren sind. Eine solche organisatorische Sicherheit ermöglicht z. B. ein gelebtes ISMS nach ISO 27001, das sich relativ gut in ein bestehendes oder im Aufbau befindliches Qualitätsmanagementsystem (QMS) nach ISO 13485 implementieren lässt.
Die zweite Ebene ist der Schutz des Medizinproduktes im gesamten SSPLC. Sie wird umgeben von der schützenden und geschützten organisatorischen Ebene und umfasst neben der Planung und Entwicklung auch die Nutzungsumgebung und die Anwender. Gleichzeitig weist sie eine enge Wechselwirkung mit dem Risikomanagement auf. Der SSPLC umfasst folgende Phasen (mit Beispielen zu Cybersicherheitsaktivitäten):
- Planung: Sie beginnt mit der Definition der Sicherheitsziele hinsichtlich Vertraulichkeit, Integrität und Verfügbarkeit (C. I. A.), identifiziert Verantwortlichkeiten, plant Aktivitäten (z. B. Zulieferer-Qualifizierung, 3rd-Party-Software-Prüfung) sowie regelmäßige Überprüfungen und legt Coding Guidelines fest.
- Anforderungsanalyse: Das Sammeln und Analysieren von Anforderungen gehört ebenso zur Anforderungsanalyse wie die Beantwortung grundlegender Fragen: Wer wird das System verwenden, wie wird das System verwendet werden, welche Ein- und Ausgaben wird es geben? Spezifikationen von Sicherheitsanforderungen sind beispielsweise die Datenminimierung oder ein Rollenkonzept (einfache Nutzer, Admin-Nutzer). Die Basis für die Zweckbestimmung und Ausgaben liefert eine vorläufige Risikoanalyse.
- Design: Dazu gehört die Definition spezifischer Hardware- oder Softwareanforderungen zusammen mit dem Entwurf der Gesamtsystemarchitektur. Hier fällt auch die Entscheidung für Softwarekomponenten von Dritten (sogenannte SOUP) und Softwarewerkzeuge.
- Entwicklung: Zentrale Punkte sind das Einhalten der definierten Coding Guidelines und der Sicherheitsziele für die Organisation (beispielsweise die Verwendung von ausgewiesenen Entwicklungsrechnern). Auch Umsetzung und Dokumentation von IT-Sicherheitsmaßnahmen gehören dazu. Bei KI-basierter Software umfasst das auch den besonderen Schutz der Trainingsdaten.
- Testphase: Das gilt auch für die Cybersicherheitsanforderungen – sind sie erfüllt oder nicht? Ein Beispiel hierfür sind so genannte Penetrationstests. Die Testphase ist zugleich der späteste Zeitpunkt, an dem die Projektverantwortlichen über eine Tool-gestützte Analyse die „Software Bill of Materials“ (SBOM) identifizieren müssen. Die SBOM ist eine Stückliste und listet sämtliche Komponenten der Software auf.
- Bereitstellungsphase: Tatsächlich sind Cyberangriffe in dieser Phase bekannt, weshalb nur geprüfte Deployment-Tools eingesetzt werden dürfen.
- Betrieb und Wartung: Die Cybersicherheitsaktivitäten gehören rein formell zur Post Market Surveillance. Darunter fallen beispielsweise Sicherheitsupdates, die übrigens nur dann bei der benannten Stelle angezeigt werden müssen, falls sich daraus signifikante Änderungen ergeben. Die Überwachung und die stetige Prüfung nach neuen Bedrohungen sollten mindestens teilautomatisiert werden (basierend auf der SBOM); ebenso können auch in dieser Phase beispielsweise Penetrationstests neu bekannt gewordene Sicherheitslücken aufspüren.
