Cybersecurity in Medical Devices: Die Guidance-Dokumente der FDA

Das Thema Cybersecurity steht zur Zeit sehr im Fokus der FDA. Die US-Gesundheitsbehörde hat dazu drei Guidance-Dokumente veröffentlich, die sich an Hersteller von Medizinprodukten wenden, allerdings mit unterschiedlichem Fokus.

1. Das FDA-Guidance-Dokument Cybersecurity in Medical Devices wendet sich an alle Medizinproduktehersteller, deren Produkte Software enthalten oder eigenständige Software sind. Der Fokus liegt auf der Entwicklungsphase (Pre-Market).
2. Das Dokument Postmarket Management of Cybersecurity in Medical Device schildert die Ansichten der FDA bezüglich der Phase nach der Entwicklung.
3. Das Dokument Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software ist lediglich ein FAQ.

Update: Die FDA hat einen Entwurf für ein Update des Pre-Market Cybersecurity Guidance Documents verfasst. Was die FDA darin fordert, ist hier für Sie zusammengefasst.

Update: Die FDA hat Best Practices for Communicating Cybersecurity Vulnerabilities to Patients veröffentlicht.

1. Guidance Document: „Cybersecurity in Medical Devices“ (Stand 2014)

Wenn Sie das aktuellere Dokument (Entwurf!) „Content of Premarket Submissions for Management of Cybersecurity in Medical Devices“ vom Oktober 2018 interessiert, dann scrollen Sie bitte weiter nach unten.

Diese Dokumentation müssen die Hersteller bei einer Zulassung z. B. nach 510(k) einreichen.

Zusammenspiel von FDA Cybersecurity Guidance und Risikomanagement

Der Vorschlag der FDA im Cybersecurity-Guidance-Dokument zum Vorgehen der Hersteller entspricht dem üblichen Risikomanagement, bei dem eine FMEA zum Einsatz kommt:

1. Die Hersteller sollen die Schnittstellen der Software wie Netzwerk (WLAN, Kabel) und Laufwerte (USB, CD) identifizieren und jeweils Schwachstellen und Bedrohungsszenarien analysieren. Bei einer FMEA wären das die Inputs. Beispiele für IT-Security-Probleme finden Sie hier.
2. Anschließend sollen die Hersteller die Gefährdungen abschätzen, die sich bei diesen Angegriffen und über diese Schnittstelle ergeben für Patienten, Anwender und das Medizinprodukt selbst. Berücksichtigen Sie bei der Risikoanalyse Risiken durch unautorisierten Zugriff, durch Veränderungen, Missbrauch oder „Denial of Use“ oder durch die Verletzung der Vertraulichkeit der Daten. Kurz: Es geht wie immer bei IT-Security um die CIA-Aspekte:
   C: Confidentiality
   I: Integrity
   A: Availability
   Im Gegensatz zur klassischen IT-Security stehen hier aber Risiken für Patienten, Anwender und Dritte im Fokus. Es geht somit um körperliche bzw. gesundheitliche Schäden, weniger um materielle.
3. Wie im Risikomanagement üblich müssen für diese Gefährdungen die Wahrscheinlichkeiten und damit die Risiken abgeschätzt werden.
4. Im letzten Schritt müssen die Hersteller die Maßnahmen festlegen, die Restrisiken und die Risikoakzeptanz abschätzen.

Damit lassen sich die Forderungen des Cybersecurity-Guidance-Dokuments der FDA im Rahmen des „normalen“ Risikomanagements erfüllen.

Spezifische Forderungen im Cybersecurity-Guidance-Dokument

Die FDA hat ein konkretes Modell vor Augen, nach dem Hersteller vorgehen sollen:

1. Identify: Die Schnittstellen und damit verbundenen Schwachstellen und Angriffsszenarien identifiziert werden.
2. Protect: Bei den Maßnahmen sieht die FDA v. a. den Zugriffsschutz und die Sicherstellung der Integrität der Software vor.
3. Detect: Weiter wünscht die FDA, dass mögliche Kompromittierungen automatisch erkannt und dokumentiert werden.
4. Respond: Benutzer müssen auf diese Probleme hingewiesen werden, wobei eine Mindestfunktionalität des Produkts gewährleistet bleiben muss (um Risiken durch einen vollständigen Ausfall des Geräts zu minimieren).
5. Recover: Es sollten Möglichkeiten aufgezeigt werden, wie das Medizinprodukt wieder in einen integren Zustand zurückgeführt werden soll.

Forderungen des FDA Cybersecurity Guides an die Dokumentation

Die Dokumentation geht über die des reinen Risikomanagements hinaus. Hersteller müssen laut Cybersecurity-Guidance-Dokument zusätzlich zum Risikomanagement (Gefährdungen, Risiken, Maßnahmen) dokumentieren:

• Einen Plan, wie sie die Software aktualisiert halten wollen, um auf neue Sicherheitsbedrohungen reagieren zu können
• Eine Beschreibung, wie der Hersteller die Integrität bereits vor der Auslieferung an den Kunden sicherstellen will
• Anweisungen an die Kunden, wie sie das Produkt bedienen sollen und welche Laufzeitumgebung (z. B. Firewalls, Antivirus-Software) bereitgestellt werden muss

510(k) und FDA-Guidance-Dokument „Cybersecurity in Medical Devices“

Das Cybersecurity Guidance legt nicht nur fest, welche Dokumentation Hersteller bei einer Zulassung z. B. nach 510(k) (Premarket Notification, PMN) einreichen müssen. Das Dokument sagt auch, dass Änderungen an der Software einzig zu dem Zweck, Cybersecurity-Bedrohungen gerecht zu werden, in der Regel keiner neuen Zulassung bedürfen.

D. h., dass die FDA uns zumindest ein kleines bisschen entgegenkommt.

Weitere Quellen

Die FDA referenziert in dem Dokument weitere Quellen wie die IEC 80001. In diesem Zusammenhang ist auch das FDA Guidance Document „Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software“ zu erwähnen.

2. Entwurf des Guidance Documents „Cybersecurity in Medical Devices“ (Oktober 2018)

Im Oktober 2018 hat die FDA eine Überarbeitung des ersten Guidance-Dokuments zur Cybersecurity publiziert (hier herunterladen). Dieser Abschnitt informiert Sie über die Änderungen.

a) Weniger eine Überarbeitung, sondern eher ein neuer Entwurf

Der Entwurf des Guidance Documents der FDA zur Cybersecurity ist mehr als nur eine Überarbeitung des Vorgängerdokuments aus dem Jahr 2014. Die FDA hat das Dokument in weiten Teilen von Grund auf neu verfasst. So ist auch die Kapitelstruktur grundlegend geändert. Das Dokument ist mit 24 Seiten fast dreimal so umfangreich wie sein Vorgänger (neun Seiten).

b) Allgemeine Prinzipien

Die FDA benennt im vierten Kapitel wichtige Prinzipien:

• Cybersecurity ist ein Teil der „Software Validation“ im Rahmen des 21 CFR part 820.30 und damit eine zwingende Voraussetzung für die Zulassung (z. B. Pre-Market Notification (PMN) 510(k), Pre-Market Approval (PMA), De Novo Requests).
• Cybersecurity betrifft den ganzen Produktlebenszyklus, d. h. nicht nur die Entwicklung.
• Die Hersteller alleine können die Cybersecurity nicht gewährleisten.
• Cybersecurity und Risikomanagement arbeiten Hand in Hand. Dazu gleich mehr.

c) Zusammenspiel von Cybersecurity und Risikomanagement

Es geht bei der Cybersecurity darum, Risiken (und damit mögliche Schäden für Patienten) durch mangelnde Cybersecurity systematisch zu analysieren, zu bewerten und zu beherrschen.

Unverändert ist der FMEA-artige Ansatz, den die FDA vorschlägt:

1. „Assets“ und deren mögliche Schwachstellen identifizieren
2. Bedrohungen identifizieren
3. Deren Auswirkungen auf Patienten analysieren
4. Wahrscheinlichkeiten und Schweregrade und damit Risiken abschätzen
5. Über Risikoakzeptanz entscheiden sowie notwendige Maßnahmen definieren und umsetzen
6. Restrisiken bewerten

d) Cybersecurity Bill of Materials (CBOM)

Neu ist hingegen das Konzept der „Cybersecurity Bill of Materials (CBOM)“. Diese definiert die FDA wie folgt:

Cybersecurity Bill of Materials (CBOM)

a list that includes but is not limited to commercial, open source, and off-the-shelf software and hardware components that are or could become susceptible to vulnerabilities.

Über diese CBOM hätten Hersteller aber für den ersten der oben genannten Schritte („Assets identifizieren) eigentlich bereits verfügen müssen.

Spätestens jetzt sollte unmissverständlich klar sein, dass die Systemarchitektur und die Software-Architektur die Voraussetzung darstellen, um die Anforderungen an die Cybersecurity zu erfüllen.

Interessant ist die Anforderung der FDA, die Cybersecurity als Kriterien für den Einkauf bzw. die Beschaffung zu definieren.

e) Einteilung in Tiers

Die FDA führt das Konzept der Tiers ein. Tier 1 und Tier 2 klassifizieren die Medizinprodukte letztlich nach kritisch und unkritisch bezüglich der Cybersecurity:

Tier-1-Medizinprodukte sind Medizinprodukte die vernetzbar sind und bei denen ein Problem mit der Cybersecurity direkt zu einem Patientenschaden führen könnte. Als Beispiele nennt die FDA sehr kritische Produkte wie Neurostimulatoren, implantierbare Defibrillatoren, Dialysemaschinen und Infusionspumpen. Auch die Systeme, die damit verbunden sind (wie bei der Heimüberwachung) oder die deren Überwachung oder Kontrolle dienen (wie „Programmer“) zählen dazu.

Tier-2-Medizinprodukte sind alle anderen Medizinprodukte.

Die FDA betont, dass diese Einteilung in Tiers nur im Kontext dieses Guidance-Dokuments anzuwenden und völlig unabhängig von der sonstigen Klassifizierung sei.

Für Tier-1-Produkte möchte die FDA die Design Controls angewendet und dokumentiert wissen, die sie in ihrem Guidance-Dokument beschreibt. Für die Tier-2-Produkte sollen die Hersteller generell beschreiben, wie sie die Cybersecurity umgesetzt haben oder alternativ auf Basis des Risikomanagements begründen, weshalb die spezifizierten Design Controls nicht angemessen bzw. notwendig sind.

f) Design Controls

Das Kapitel zu den Design Controls trägt den Titel V. Designing a Trustworthy Device: Application of NIST Cybersecurity Framework und ist das umfangreichste. Es entspricht einer umfangreichen Überarbeitung und Ergänzung des Kapitels 5. Cybersecurity Functions im Vorgängerdokument.

Die Anforderungen sind nun viel granularer dargestellt und spezifischer. Es gibt mehr Beispiele und konkrete Anforderungen.

Diese Design Controls sind zu umfangreich, um einzeln wiedergegeben zu werden. Der gemeinsame Leitfaden des TÜV Süd und des Johner Instituts enthält alle Aspekte. Dieser Leitfaden wird Ende November kostenfrei publiziert.

g) Labeling

Neu in dieser Form sind die Anforderungen der FDA an das Labeling. Demnach müssen die Hersteller im Labeling Folgendes adressieren:

1. Anforderungen an die Nutzungsumgebung, z. B. Firewalls, Virenschutz
2. Beschreibung, wie das Gerät auch im Fall eines (erfolgreichen) Angriffs die kritischen Funktionalitäten aufrechterhält
3. Beschreibung von Backup und Restore
4. Anleitung, was die Nutzer an Infrastruktur bereitstellen müssen
5. Beschreibung, wie das Gerät gesichert ist oder gesichert werden kann, z. B. durch Konfiguration, Firewall-Regeln, Einsatz von Virenschutz, White-Listing, physischen Zugangsschutz
6. Übersicht über die Netzwerk-Ports und anderen Schnittstellen und Beschreibung welche Daten/Funktionalitäten in welche Richtung ausgetauscht bzw. zur Verfügung gestellt werden
7. Beschreibung, wie die Anwender Updates vom Hersteller herunterladen können
8. Beschreibung, wie das Gerät anomale Situationen wie sicherheitsbezogene Ereignisse (z. B. Angriffe) meldet
9. Beschreibung, wie sicherheitsbezogene Ereignisse nachvollziehbar gemacht werden, z. B. in Form von Audit-Logs. Dabei muss auch klargestellt werden, wo die Log-Dateien zu finden sind, wie diese gesichert und wiederverwendet werden und wie diese Informationen ausgewertet werden können.
10. Beschreibung, wie die Gerätekonfiguration durch autorisierte Anwender gesichert bzw. wiederhergestellt werden kann
11. Ausreichend detaillierte Systemdiagramme für Endanwender. Dass diese Systemdiagramme enthalten sollten, spezifiziert die FDA in der Sektion zur Dokumentation (s. u.).
12. Die CBOM, um es den Anwendern (Patienten, Krankenhäuser etc.) zu ermöglichen, Auswirkungen von Schwachstellen zu identifizieren und Maßnahmen zu ergreifen
13. Anleitungen, um eine sichere Installation und Wartung über das Netzwerk zu ermöglichen und auf entdeckte Schwachstellen zu reagieren
14. Informationen über den Cybersecurity Support. Die FDA stellt an dieser Stelle noch fest, dass die IT-Security-Risiken nach der Phase steigen, in der ein Hersteller Support und Software-Patches bereitstellt. Konkrete Forderungen (außer der Information darüber) stellt die FDA allerdings nicht.

g) Dokumentation

Die FDA fordert zwei Dokumentationen:

1. Design Documentation
2. Risk Management Documenation

Design Documentation

Im Rahmen der Design Documentation müssen die Hersteller dokumentieren, wie sie die Empfehlungen im Kapitel 5 zu den Design Controls umgesetzt haben. Eine Ausnahme erlaubt die FDA für die Tier-2-Produkte: Hersteller dürfen aus dem Risikomanagement begründen, weshalb das nicht notwendig ist.

Zusätzlich fordert die FDA „Systemdiagramme“. Zum Glück listet sie die Elemente auf, die sie in solchen Diagrammen erwartet:

• Netzwerk-, Architektur-, Fluss- und Zustandsdiagramme
• Schnittstellen, Komponenten, „Assets“, Kommunikationspfade, Protokolle une Netzwerk-Ports
• Mechanismen zur Authentifizierung und zur Kontrolle jeder kommunizierenden Komponente des Systems wie Webseiten, Server, interoperable Systeme und Cloud-Speicher
• Rollen und Zuständigkeiten der Anwender bezüglich dieser „Assets“ und Kommunikationskanäle
• Beschreibung der kryptographischen Methoden, z. B. Nutzung kryptographischer Schlüssel. Diese Beschreibung muss auch darlegen, wie Firmware- und Software-Updates geschützt werden.

Schließlich müssen die Hersteller darlegen, welche Komponenten sie wie durch Patches über den Produktlebenszyklus hin aktualisieren wollen und müssen.

Risk Management Documentation

Im Rahmen des Risikomanagements erwartet die FDA von den Herstellern die folgende Dokumentation:

• Threat Model auf Systemebene
• Liste aller Cybersecurity-Risiken, die bei der Entwicklung berücksichtigt wurden. Die FDA empfiehlt, die „Auswirkungen“ stärker als die Wahrscheinlichkeiten zu diskutieren. Sonst müsste man die Wahrscheinlichkeiten begründen.
• Liste aller Maßnahmen heruntergebrochen auf Funktionen bzw. Komponenten
• Beschreibung der Tests. Dabei fordert („should“) die FDA Prüfungen wie Penetrationstests, „Vulnerarbility Scanning“, statische und dynamische Code-Analyse.
• Traceability-Matrix
• Cross-Reverenz der CBOM mit der National Vulnerability Database (NVD)

Diese Forderungen sind im Wesentlichen nachvollziehbar. Bemerkenswert ist jedoch die Forderung nach spezifischen Testverfahren und der Cross-Referenz zur NVD.

i) Fazit

Die FDA hat im Gegensatz zu den europäischen Behörden schon früh begonnen, Anforderungen an die IT-Sicherheit von Medizinprodukten zu formulieren. Die völlige Überarbeitung des ersten Guidance-Dokuments zur Cybersecurity war notwendig. Die neue Version (genauer gesagt deren Entwurf) zeichnet sich durch eine bessere innere Logik sowie durch konkretere und spezifischere Anforderungen aus.

Die etwas grobschlächtige (weil binäre) Einteilung in Tiers erlaubt den Herstellern, einen „risk based approach“ zu wählen und damit die Aufwände an die Entwicklung und Dokumentation den Risiken durch mangelnde IT Security anzupassen.

Der Leitfaden enthält in der Sektion zum „Labeling“ Inkonsistenzen wie Redundanzen. Die Forderung wirkt befremdlich, dass die Anwender die CBOM kennen sollten, um damit die Auswirkungen von Schwachstellen abzuschätzen und durch Maßnahmen abzumildern.

Was Endanwender mit Architektur-, Fluss- und Zustandsdiagrammen anfangen sollen, bleibt unklar. Müssen Hersteller jetzt komplett die Hose runterlassen? Was soll der Nutzen sein?

Es wäre begrüßenswert gewesen, hätte die FDA nicht nur Anforderungen an das Produkt, sondern auch Anforderungen an die Lebenszyklusprozess formuliert.

3. Das Guidance Document „Postmarket Management“

Die FDA hat erkannt, dass Hersteller während der Entwicklung nicht alle künftigen Bedrohungen mit Bezug zur Cybersecurity vorhersagen und adressieren können. Daher verlangt sie, dass die Hersteller auch nach der Entwicklung kontinuierlich diese Bedrohungen analysieren und entsprechende Maßnahmen ergreifen.

„Postmarket“-Informationsquellen

Zu den Informationsquellen, die die FDA den Herstellen empfiehlt auszuwerten, zählen:

• Ergebnisse der Sicherheitsforscher
• Eigene Tests
• Soft- und Hardware-Lieferanten
• Kunden wie Krankenhäuser
• Institutionen, die sich auf das Sammeln, Analysieren und Verbreiten entsprechender Informationen spezialisiert haben

Maßnahmen

Die FDA empfiehlt das NIST Framework (National Institut for Standards and Technology) anzuwenden, dessen Elemente (Identify, Protect, Detect, Respond und Recover) bereits das erste Guidance-Dokument aufgreift.

Die FDA wiederholt die Gedanken des ersten Dokuments:

1. Finden Sie heraus, welche wesentlichen (klinischen) Leistungsmerkmale Ihr Medizinprodukt erfüllen muss.
2. Identifizieren Sie die Risiken, die auftreten, wenn diese Leistungsmerkmale nicht erfüllt sind — hier aufgrund eines Cybersecurity-Problems.
3. Analysieren Sie, wie es zu diesem Problem kommen kann. Nutzen Sie dazu die o. g. Informationen.
4. Bewerten Sie diese potenziellen Probleme und deren Wahrscheinlichkeiten, z. B. mit dem Common Vulnerability Scoring System.
5. Analysieren Sie die Auswirkungen auf die Gesundheit, d. h. den Schweregrad möglicher Schäden.
6. Bewerten Sie die Vertretbarkeit der Risiken.
7. Beseitigen Sie Schwachstellen (immer), stellen Sie die Wirksamkeit der Maßnahmen sicher und dokumentieren Sie all das.
8. Informieren Sie die Nutzer.

An dieser Stelle erwähnt die FDA, dass proaktive Maßnahmen zur Verbesserung der Cybersecurity gemäß 21 CFR part 806.10 der FDA nicht gemeldet werden müssen.

Schon seit Längerem hat die FDA dieses Program Book veröffentlicht, das sie weiterhin empfiehlt.

Fazit

Die Forderungen der FDA konkretisieren, was man von einer üblichen Marktüberwachung erwarten würde. Bemerkenswert sind:

1. Das Dokument ist an einigen Stellen erstaunlich konkret, z. B. die auszuwertenden Informationsquellen bzw. die anzuwendenden Methoden betreffend.
2. Das Dokument gibt Antworten auf die Fragen, wann Cybersecurity-bezogene Maßnahmen zu melden sind.
3. Das Dokument definiert Begriffe (z. B. Exploit, Remediation, Threat, Threat Modelling) und gibt zahlreiche Beispiele.

4. Aktuelles

Best Practices for Communicating Cybersecurity Vulnerabilities to Patients

Am 1. Oktober 2021 hat die FDA Best Practices for Communicating Cybersecurity Vulnerabilities to Patients veröffentlicht. Bei dem Dokument handelt es sich nicht um ein Guidance-Dokument, sondern um allgemeine Hinweise und Vorschläge für eine bessere Kommunikation von Cybersecurity-Risiken.

Nach den Best Practices sollten Informationen über Risiken vor allem folgende Voraussetzungen erfüllen:

• Leicht verständliche Inhalte bieten sowie Inhalte mit
  • Aktualität
  • Relevanz
  • Einfachheit
  • Lesbarkeit für ein breit gefächertes Publikum
• Risiken erläutern
• Auf Unbekanntes hinweisen und es erläutern
• Es Patienten einfach machen, die Risiken zu identifizieren und das Produkt zu nutzen. Insbesondere
  • sollten Informationen leicht bei Online-Suchen zu finden sein,
  • sollten Informationen auf mobilen Geräten gut lesbar sein.

Das Dokument enthält auch die Best Practices, die beim Patient Engagement Advisory Committee (PEAC) Meeting vom 10. September 2019 erörtert wurden.

Beispiele für mangelnde IT-Security von Medizinprodukten

• Manipulierbare Medizingeräte: Technology Review berichtet, wie angreifbar und damit manipulierbar Medizingeräte sind.
• Millionen Gesundheitsdaten gestohlen: Hacker sind in das Krankenhaussystem der UCLA eingebrochen und haben 4,5 Mio. Datensätze gestohlen (Artikel bei Heise). Bezeichnenderweise wurde der Einbruch erst nach über einem halben Jahr bemerkt.
  In dem Maß, in dem diese Gesundheitsdaten an Wert gewinnen, werden unsere Betreiber vermehrt diesen Angriffen ausgesetzt sein.
• Beatmungsgeräte: Hartkodierte Passworte im Netz verfügbar? Die Passwörter verschiedener GE-Geräte, darunter Beatmungsgeräte, scheinen im Netz zu stehen. Ein GE-Mitarbeiter hat mir eine ganze Liste an Dokumenten zukommen lassen.
  Ich verstehe die Notwendigkeit, für Schulungszwecke auf die Geräte zu kommen; aber ganz so einfach sollte man es sich vielleicht doch nicht machen. Das FDA Cybersecurity Guidance Document verlangt jedenfalls keine hartkodierten Passwörter.