Cybersicherheitsrisikomanagement für Medizinprodukte
Sytance · Aktualisiert
Das Cybersicherheits-Risikomanagement für Medizinprodukte bewertet, wie sich Bedrohungen und Schwachstellen auf Sicherheit, Wirksamkeit und Leistung auswirken können. Ein Bedrohungsmodell, eine SBOM, ein Schwachstellenscan oder ein Penetrationstest kann die Bewertung unterstützen, ist aber für sich genommen keine Risikobewertung.
Rolle des Risikomanagements
Die FDA betrachtet das Management von Sicherheitsrisiken als Teil des Qualitätsmanagementsystems und des Lebenszyklus eines Produkts. Es unterscheidet sich vom Sicherheitsrisikomanagement nach ISO 14971, da Sicherheitsmängel absichtlich herbeigeführt werden können, sich die Ausnutzbarkeit im Laufe der Zeit ändert und Schäden indirekt durch den Verlust von Verfügbarkeit, Integrität, Vertraulichkeit oder Kontrolle entstehen können. Beide Prozesse müssen dennoch ineinandergreifen, da ein Sicherheitsproblem zu einem Patientenschaden führen kann.
MDCG 2019-16 erläutert, dass eine Sicherheitsmaßnahme selbst die Sicherheit beeinflussen kann. Eine Zugriffsbeschränkung kann beispielsweise unbefugte Änderungen verhindern, aber zugleich einen legitimen Vorgang verzögern. Der Hersteller muss beide Auswirkungen unter den Bedingungen der vorgesehenen Anwendung bewerten.
Patientenschaden
Die FDA-Leitlinien für die Überwachung nach dem Inverkehrbringen stellen bei der zentralen Frage nach einem Patientenschaden auf eine Verletzung oder Beeinträchtigung der Gesundheit des Patienten bis hin zum Tod ab, nicht allein auf geschäftliche Auswirkungen.
Sicherheit und Leistung
Bewerten Sie, ob das Sicherheitsproblem die bestimmungsgemäße Funktion des Produkts verändert und ob eine Maßnahme neue Sicherheits- oder Leistungsbedenken mit sich bringt.
Bedrohungsmodellierung als Grundlage der Bewertung
Das Bedrohungsmodell zeigt auf, wie ein Angreifer eine Produktschnittstelle oder externe Abhängigkeit nutzen könnte, um ein unerwünschtes Ergebnis herbeizuführen. Die Angriffsbedingungen und möglichen Folgen fließen in die Cybersicherheits-Risikobewertung ein.
- Das Bedrohungsmodell zeigt, was schiefgehen kann und über welche Wege ein Angreifer oder ein unbeabsichtigter Auslöser das System erreichen kann.
- Die Cybersicherheits-Risikobewertung beurteilt Risiken, Maßnahmen, Restrisiken und Akzeptanzkriterien.
- Der Prozess für Sicherheitsrisiken berücksichtigt Cybersicherheitsrisiken, wenn eine Ausnutzung Patientenschäden, die klinische Leistung oder den sicheren Betrieb beeinträchtigen kann.
- Der Prozess nach dem Inverkehrbringen aktualisiert das Modell, wenn neue Schwachstellen, veränderte Einsatzumgebungen, neue Schnittstellen oder neue Angriffstechniken die Risikolage verändern.
Die Ausnutzbarkeit verändert die Analyse
Eine Cybersicherheits-Risikobewertung kann sich nicht allein auf historische Wahrscheinlichkeiten stützen. Nach den Erläuterungen der FDA konzentriert sich die Bewertung von Sicherheitsrisiken auf die Ausnutzbarkeit: die Machbarkeit, den Aufwand und die technischen Mittel, mit denen eine Schwachstelle ausgenutzt werden kann. Deshalb kann sich die Bewertung ändern, wenn beim Testen eine Schwachstelle entdeckt wird, eine CISA Known Exploited Vulnerability vorliegt, sich ein Netzwerkpfad ändert oder ein neuer öffentlicher Exploit verfügbar wird – auch wenn kein Patientenvorfall eingetreten ist.
Bei der Bewertung vor dem Inverkehrbringen dient das Bedrohungsmodell dazu, Angriffe zu beurteilen und Maßnahmen auszuwählen. Die Verifizierungsergebnisse zeigen, ob die Maßnahmen gegen diese Angriffe wirksam sind. Die FDA lässt entweder die Annahme einer Ausnutzbarkeit im ungünstigsten Fall oder eine begründete Bewertung der Ausnutzbarkeit zu, die den gesamten Produktlebenszyklus berücksichtigt.
Die Bewertung nach dem Inverkehrbringen beginnt mit einem konkreten Hinweis, etwa einer CVE, einer Meldung von Forschenden, einer Mitteilung eines Lieferanten oder einem beobachteten Exploit. Die FDA-Leitlinien zur Überwachung nach dem Inverkehrbringen richten die Entscheidung an der Ausnutzbarkeit, der Schwere eines möglichen Patientenschadens, kompensierenden Maßnahmen und der Frage aus, ob das verbleibende Risiko eines Patientenschadens kontrolliert ist.
Die SBOM ist nicht die Risikobewertung
Eine SBOM erfasst Softwarekomponenten und Abhängigkeitsbeziehungen. Sie hilft dem Hersteller, die Betroffenheit durch bekannte Schwachstellen in Komponenten, den Supportstatus und betroffene Versionen zu ermitteln. Sie zeigt nicht, ob eine anfällige Komponente erreichbar ist, ob eine Maßnahme eine Ausnutzung verhindert, ob sich die klinische Leistung ändert oder ob das Restrisiko eines Patientenschadens akzeptabel ist.
Eine SBOM ist ein formelles, maschinenlesbares Verzeichnis von Softwarekomponenten und Abhängigkeiten, Informationen zu diesen Komponenten sowie ihren hierarchischen Beziehungen.
NTIA, Framing Software Component Transparency, 2021 (Original auf Englisch)
Beitrag der SBOM
Angaben zu Identität, Version, Lieferant, Abhängigkeiten und Support einer Komponente helfen dabei, die Betroffenheit zu erkennen und das Schwachstellenmanagement zu unterstützen.
Beitrag zur Risikobewertung
Architektur, Bedrohungsmodellierung, Ausnutzbarkeit, Nachweise zu Maßnahmen und die Analyse möglicher Patientenschäden bestimmen, was die Betroffenheit für das Produkt bedeutet.
Verknüpfte Aufzeichnungen
Die FDA empfiehlt eine Rückverfolgbarkeit zwischen Bedrohungsmodell, Risikobewertung, SBOM und Prüfaufzeichnungen. Prüfende sollten bei einer betroffenen Komponente beginnen und die daraus resultierende Risikentscheidung sowie das Verifizierungsergebnis auffinden können. Für eine EU-technische Dokumentation ist zu erläutern, wie diese Aufzeichnungen die anwendbaren Anforderungen der MDR oder IVDR stützen.
Quellen
- FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, endgültige Leitlinie, Februar 2026
- FDA, Postmarket Management of Cybersecurity in Medical Devices, endgültige Leitlinie, Dezember 2016
- Europäische Kommission, MDCG 2019-16 Leitlinie zur Cybersicherheit von Medizinprodukten
- NTIA, Framing Software Component Transparency: Establishing a Common Software Bill of Materials