Cybersecurity in Medical Devices: FDA Guidance Dokumente

Dienstag 23. Oktober 2018

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, der 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, finden Sie hier zusammengefasst.

1. FDA 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 runter.

FDA Cybersecurity Guidance

Abb. 1: Übersicht über das FDA Guidance Document zur Cybersecurity (Pre-Market) vom Oktober 2014 (zum Vergrößern klicken)

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, wie die Hersteller vorgehen sollen, 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 die Patienten, die 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 und 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 FDA Cybersecurity Guidance Dokuments im Rahmen des „normalen“ Risikomanagements erfüllen.

Spezifische Forderungen im FDA Cybersecurity Guidance Dokument

FDA Cybersecurity Guidance Documentation

Abb. 2: Die Schritte, die die FDA empfiehlt (zum Vergrößern klicken)

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

  1. Identify: Wie eben dargestellt sollen 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 im Cybersecurity Guidance Dokument, 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. Die 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 Guidance Dokument sagt auch, dass Änderungen an der Software einzig mit dem Zweck, Cybersecurity Bedrohungen gerecht zu werden, in der Regel keiner neuen Zulassung bedürfen.

D.h. die FDA kommt uns zumindest ein kleines bisschen entgegen.

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.

FDA Guidance Cybersecurity

Abb. 3: Das Guidance Document der FDA zur Cybersecurity vom Oktober 2018. Das Dokument vom Oktober 2018 trägt den gleichen Titel.

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

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

a) Weniger eine Überarbeitung, sondern eher ein Neu-Entwurf

Der Entwurf des FDA „Guidance Documents“ 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. Die FDA hat dessen Kapitelstruktur grundlegend geändert. Das Dokument ist mit 24 Seiten fast dreimal so umfangreich wie sein Vorgänger (neun Seiten).

Kapitelstruktur des FDA Cybersecurity Guidance vom Oktober 2018 als Mindmap

Abb. 4: Die FDA hat die Kapitelstruktur des „Guidance Documents“ zur IT Security völlig überarbeitet (zum Vergrößern klicken)

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 und 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, auch wenn sie diese Liste nicht so genannt habe.

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. Die Tiers (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 Documents anazuwenden 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 dem Guidance Document 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 mit den „Design Controls“, es trägt den Titel „V. Designing a Trustworthy Device: Application of NIST Cybersecurity Framework“, 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 und spezifischer. Es gibt mehr Beispiele und konkrete Anforderungen.

Von der FDA geforderte Design Controls zur Cybersecurity

Abb. 5: Überblick über das Kapitel „V. Designing a Trustworthy Device: Application of NIST Cybersecurity Framework“ mit den Anforderungen zu den Design Controls (zum Vergrößern klicken)

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 diese 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
  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 den Anwendern (Patienten, Krankenhäuser etc.) es 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 die Hersteller Support und Software-Patches bereitstellt. Konkrete Forderungen (außer der Information darüber) stellt die FDA allerdings nicht.
Weiterführende Informationen

Lesen Sie in diesem Artikel zum Labeling, was man unter dem Begriff versteht, und dass es um weit mehr geht, als um Labels.

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: Die 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 jedoch stärker die „Auswirkungen“ 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 Documents zur Cybersecurity war notwendig. Die neue Version (genauer gesagt dessen 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 sollte, 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. FDA 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
  • Eigenes Testen
  • Soft- und Hardware-Lieferanten
  • Kunden wie Krankenhäusern
  • 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 Document 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.

FDA Postmarket Cybersecurity Guidance Cocument

Schon länger hat die FDA dieses „Program Book“ veröffentlicht, das sie weiterhin empfiehlt.

Fazit

Die Forderungen der FDA konkretisieren das, 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

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 Krankenhaus-System der UCLA eingebrochen und haben 4,5 Mio. Datensätze gestohlen (Artikel bei Heise). Bezeichnender Weise 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 verschiedenster 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 gerade keine hartkodierten Passwörter.

Kategorien: FDA Zulassung - die U.S. Food and Drug Administration, Risikomanagement & ISO 14971, Software & IEC 62304
Tags:

Ein Kommentar über “Cybersecurity in Medical Devices: FDA Guidance Dokumente”

  1. Tetyana Rybchak schrieb:

    Sehr Hilfreich!

Kommentar schreiben