Die Anforderungen an die Cybersicherheit von Medizinprodukten gerät immer mehr in den Fokus von Behörden und damit vor allem auch der Risikomanagementprozess für Risiken im Zusammenhang mit Cybersicherheit. Normen wie die IEC 81001-5-1 oder die FDA Guidance „Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions“fordern einen sicheren Produktlebenszyklus. Darüber hinaus verlangt die MDCG 2019-16 ebenfalls die Cybersicherheit von Medizingeräten. Wie unterscheiden sich diese Risiken zu denen bezüglich Patientensicherheit? Können wir unseren ISO 14971 Prozess einfach und schnell erweitern oder braucht es eine neue Lösung, um die neuen Risiken adäquat abdecken zu können? Erfahren Sie in diesem Blogbeitrag, worauf es beim Risikomanagementprozess für Cybersicherheit ankommt und wo Sie effizient und schnell ansetzen können, um mögliche Lücken zu schließen.
Was unterscheidet die Security von der Safety?
Die beiden Begriffe „Security“ und „Safety“ lassen sich im deutschen beide mit dem Begriff „Sicherheit“ übersetzen, allerdings spiegelt diese Übersetzung nicht die grundlegenden Unterschiede zwischen den beiden wider. Während es sich bei der „Safety“ um die Patientensicherheit handelt, geht es bei der „Security“ um die Produktsicherheit:
Safety – Patientensicherheit
Bei der Patientensicherheit steht laut den Definitionen der ISO 14971 der Schutz und die Sicherheit des Patienten im Fokus, aber auch der Schutz des Anwenders und der Nutzungsumgebung. Das Risikomanagement nach ISO 14971 betrachtet Risiken demnach rein aus der Sicht, wie wahrscheinlich es ist, dass eine Gefährdung für Patient, Nutzer oder Umgebung entstehen. Aus diesem Aspekt heraus werden ebenfalls die Schweregrade bestimmt, welche in der Regel eine Bandbreite von „Keine Auswirkungen“ bis hin zu „Irreversible Schäden oder Tod“ abbilden. Damit werden explizit Schädigungen und Beeinträchtigungen des Gerätes selbst, sowie wirtschaftliche Schäden für das Unternehmen ausgeklammert.
Security – Produktsicherheit / IT-Sicherheit
Bei der Produktsicherheit geht es ausnahmsweise nicht um die Patientensicherheit, sondern um den Schutz des Gerätes bzw. des medizinischen Systems. Hierbei ist es wichtig, dass die zu schützenden Assets – also die Teile des Systems, die einen Wert haben – definiert und priorisiert werden. Dabei werden explizit auch Unternehmenswerte, wie zum Beispiel die I.P. (Intellectual Property) oder auch das Image des Unternehmens als schützenswerte Assets angesehen. Während die Patientensicherheit sich über die Auftretungswahrscheinlichkeit und den Schweregrad bewerten lässt, geht es bei der Produktsicherheit um das Angriffspotential, welches sich aus den verschiedenen Bedrohungen (Threats) und Schwachstellen (Vulnerabilities) des Systems ergibt.
Der Unterschied zwischen Safety und Security ist ein essenzieller Aspekt bei der Klassifizierung und Bewertung der entsprechenden Risiken. Durch die grundlegend verschiedene Natur der zugrunde liegenden Ursachen ist es nötig zusätzliche Expertise aufzubauen und den Risikomanagementprozess des Unternehmens umzustrukturieren.
Woher kommen die Anforderungen an einen Security Risikomanagementprozess?
Die Anforderungen an einen Security Risikoprozess kommen maßgeblich aus der EN IEC 81001-5-1 Abschnitt 7, sowie der oben genannten FDA Guidance „Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions“ Abschnitt V.A. Letztere geht ebenfalls deutlich auf den Unterschied zwischen Safety und Security ein und empfiehlt einen losgelösten Security Risikomanagementprozess zu etablieren. Bezüglich des Inhaltes sind sich beide Dokumente einig. Die folgenden Aspekte müssen grundlegend von einem entsprechenden Risikomanagementprozess abgedeckt werden:
- Sicherheitsumfeld des Produktes analysieren und dokumentieren (Security Context)
- Identifizierung von Schwachstellen mit Hilfe eines Bedrohungsmodells (Threat Modelling)
- Einschätzung und Bewertung des Security Risikos
- Beherrschung des Risikos (Threat Mitigation)
- Überwachen der implementierten Risikobeherrschungsmaßnahmen
Generell gilt, dass beide regulatorischen Dokumente nicht separat voneinander, sondern gemeinsam betrachtet werden sollten. Die IEC 81001-5-1 gibt einen guten prozessualen Rahmen vor, welche Aktivitäten erforderlich sind um einen sicheren Produktentwicklungslebenszyklus (Secure Product Development Framework – SPDF) zu erstellen. Die FDA verlangt diesen SPDF und erkennt die IEC 81001-5-1 ebenfalls als prozessualen Rahmen an. Darüber hinaus stellt die FDA aber konkrete Anforderungen an die Inhalte der zu erstellenden Dokumentation. Damit ergänz sie die IEC 81001-5-1 mit praktischen Beispielen und Best-Practices.
Für zusätzliche praktische Beispiele verweist die FDA auf weitere Technische Berichte von der AAMI. Hier sind besonders hervorzuheben die AAMI TIR57:2016 (R2013) „Principles for medical device security – Risk management“ und die AAMI TIR97:2019 (R2023) „Principles for medical device security – Postmarket risk management for device manufacturers“.
Prozessuale Anleitungen anhand der AAMI TIR57 und AAMI TIR 97
Die AAMI TIR57:2016 (R2013) „Principles for medical device security – Risk management“ beschreibt einen Ansatz für das Risikomanagement während des Entwicklungsprozesses. Hier wird darauf hingewiesen, dass es aufgrund der unterschiedlichen Natur der Risiken empfehlenswert ist einen separaten Prozess zu definieren. Die folgende Abbildung aus der AAMI TIR57:2016 (R2023) zeigt die Verlinkung der beiden Prozesse:
Der empfohlene Prozess zeigt die Verlinkung der beiden Risikomanagementprozesse. Es wird deutlich, dass beide Prozesse eine funktionierende Schnittstelle von den jeweiligen Risikokontrollen benötigen, wenn der verdacht besteht ein Einfluss auf den anderen Prozess zu haben. Security Risiken mit möglichem Einfluss auf die Patientensicherheit müssen demnach im Safety Risikomanagement betrachtet werden und umgekehrt.
WICHTIG: Hierbei muss das Risiko dupliziert und nicht transferiert werden. Man betrachtet dasselbe Risiko in beiden Prozessen und definiert ggfs. Kontrollmaßnahmen aus Security- UND aus Safety-Sicht.
Die AAMI TIR57:2016 (R2013) bietet neben der Erläuterung der Prozesse ebenfalls Beispiele für die Bewertung von Risiken mit verschiedenen Ansätzen in Anhang B:
- Bedrohungs-orientiert
- Asset-orientiert
- Schwachstellen-orientiert
Somit zeigt die AAMI TIR57:2016 (R2013) eine grundlegende Basis für die Implementierung eines Risikomanagementprozesses für die Produktsicherheit auf und bietet gleichzeitig ein gewisses Maß an Freiheit in der Wahl der Methodik, um eine möglichst gute Lösung für die eigene Unternehmensstruktur zu finden.
Nach der Freigabe des Systems und der Beobachtung im Markt kann die AAMI TIR97:2019 (R2023) „Principles for medical device security – Postmarket risk management for device manufacturers“ zu Rate gezogen werden. Hier werden maßgeblich die sogenannten „Cybersecurity Signals“ beschrieben. Bei diesen Signalen handelt es sich um Informationen, die auf eine mögliche oder bestätigte Schwachstelle, einen Exploit, eine Bedrohung oder ein Bedrohungsereignis hinweisen, das ein Medizinprodukt betrifft oder betreffen könnte. Sollte ein solches Signal erkannt werden, beschreibt die AAMI TIR97:2019 (R2023) auf praktische Weise, wie und in welchem Zeitrahmen sinnvollerweise reagiert werden sollte.
Diese Reaktionen beinhalten ebenfalls die grundlegenden Prozesse:
- Koordinierte Offenlegung von Schwachstellen und Sicherheitslücken (Coordinated Vulnerability Disclosure – CVD)
- Reaktionsplan bei Zwischenfällen (Incidents Response Plan – IRP)
Die CVD wird maßgeblich in Anhang C beschrieben und geht dabei auf den Prozess selbst ein, aber auch auf die Kriterien, wann Schwachstellenberichte von externen Quellen akzeptiert werden und, wie diese anschließend wieder an die Nutzer zurückgemeldet werden sollten.
Der IRP wird im Anhang E beschrieben. Hierbei wird genau erläutert, wie man sich auf die Reaktion vorbereiten sollte, welche Kriterien es für die Bewertung der Vorfälle gibt und wie am besten darauf reagiert werden sollte. Dabei unterscheidet der Anhang E maßgeblich zwischen den internen Aktivitäten und der Kommunikation nach außen. Abschließend geht der Anhang ebenfalls auf die Koordinierung der nötigen Freigaben der Software ein inklusive der benötigen SBOM.
Zusammenfassend lässt sich sagen, dass Security Risikomanagement eine große Hürde für viele Unternehmen sein kann. Es gibt viele regulatorische Anforderungen und weitaus mehr Dokumente, die eine Best-Practice versprechen. Doch Security Risikomanagement ist kein Gipfel, den man an einem Tag erklimmen muss. Es ist ein kontinuierlicher Prozess, der sich in viele kleine Etappen aufteilen lässt. Die Priorisierung dieser einzelnen Schritte sollten über eine Risiko-Nutzen-Analyse begründet und dokumentiert werden. Ist dies gegeben, steht einer erfolgreichen Reise hin zu einem sicheren Medizin-System nichts mehr im Weg.
Bitte beachten Sie, dass alle Angaben und Auflistungen nicht den Anspruch der Vollständigkeit haben, ohne Gewähr sind und der reinen Information dienen.
