FDA Cybersecurity Leitfaden für die Zulassung

Wer ein Medizinprodukt in der USA zulassen will, kommt an der Food and Drug Administration (FDA – Behörde für Zulassung von Medizinprodukten in der USA) nicht vorbei. Medizinprodukte werden immer vernetzter und erfassen zunehmend mehr Daten. Dabei bleibt es nicht aus, dass Medizinprodukte Ziel von Angreifern werden. Um dem zu begegnen, hat die FDA das Guidance Dokument Content of Premarket Submissions for Management of Cybersecurity in Medical Devices herausgegeben. In diesem Beitrag möchte ich auf diesen Leitfaden eingehen und die wesentlichen Aspekte vorstellen. Wichtige Fachbegriffe werden hier in englischer Sprache genannt, da es für viele Begriffe in der deutschen Sprache keine richtige Entsprechung gibt. Das fängt schon bei den Begriffen “Safety” und “Security” an. Beides kann man im Deutschen mit “Sicherheit” übersetzen.  Dabei meint “Safety” die funktionale Sicherheit, also den Schutz des Menschen vor der Maschine, während die “Security” die Sicherheit vor Angriffen von außen, also den Schutz der Maschine, der Umgebung oder des Menschen vor anderen Menschen, betrachtet.

Wen betrifft die Guideline?

In erster Hinsicht betrifft die Guideline alle Medizinprodukte-Hersteller, die eine Zulassung für ein Produkt in den USA anstreben. Das gilt für die Premarket Notification (510k), De Novo requests, Premarket Approval Application (PMAs), Product Development Protocols (PDPs) und Humanitarian Device Exemption (HDE).

Die FDA weist darauf hin, dass es eine gemeinsame Verantwortung für die Cybersecurity gibt, die durch die Gesundheitseinrichtungen, Patienten, Gesundheitsdienstleister und Hersteller von medizinischen Geräten geteilt werden muss. Den Herstellern soll durch die Richtlinie eine Hilfestellung gegeben werden, um folgende Aspekte zu berücksichtigen:

  1. Risikobasierter Ansatz, um Medizinprodukte mit angemessenen Cybersecurity-Schutzmaßnahmen zu entwickeln.
  2. Ganzheitlicher Ansatz für die Cybersecurity von Geräten, indem Risiken und Maßnahmen während des gesamten Produktlebenszyklus bewertet werden.
  3. Gewährleistung der Wartung und Kontinuität der Sicherheit kritischer Geräte und der wesentlichen Leistungsmerkmale und
  4. Förderung der Entwicklung vertrauenswürdiger, wirksamer und sicherer Geräte.

Aus meiner Sicht ist die Richtlinie aber auch für Hersteller sinnvoll, die keine FDA-Zulassung anstreben, da sie einen guten Leitfaden darstellt, wie man mit dem Thema Cybersecurity umgehen soll.

Ihr Ansprechpartner:

Dipl.-Ing. Goran Madzar, Gesellschafter, Senior Systems Engineer 
E-Mail: madzar@medtech-ingenieur.de
Tel.:  +49 9131 691 240
 

Benötigen Sie Unterstützung bei der Entwicklung Ihres Medizingeräts? Wir helfen gerne! Die MEDtech Ingenieur GmbH bietet Hardware-Entwicklung, Software-Entwicklung, Systems Engineering, Mechanik-Entwicklung und Beratung aus einer Hand. Nehmen Sie Kontakt mit uns auf.

Kontakt aufnehmen

Der risikobasierte Ansatz

Bei dem risikobasierten Ansatz geht es darum, einen Prozess zu durchlaufen, um die Cybersecurity des Medizinproduktes zu verbessern. Der Prozess besteht aus den folgenden Schritten:

  • Identifikation von Assets (Werte), Threats (Gefährdungen) und Vulnerabilites (Schwachstellen).
  • Bewertung der Auswirkungen von Bedrohungen und Schwachstellen auf die Gerätefunktionalität.
  • Einschätzung der Wahrscheinlichkeit, dass eine Bedrohung und eine Sicherheitslücke ausgenutzt werden.
  • Bestimmung des Risikograds und geeigneter Maßnahmen.
  • Bewertung des Restrisikos und der Risikoakzeptanzkriterien.

Dabei ist nicht jedes Gerät gleich zu betrachten. Medizinprodukte die vernetzter sind (Ethernet, WiFi, USB, Bluetooth oder ähnliches) sind natürlich verwundbarer als Systeme, die keine entsprechenden Schnittstellen besitzen. Die FDA schlägt hier zwei Stufen von Geräten vor. Geräte mit hohem Risiko für Cybersecurity (Tier 1) und Geräte mit normalem Risiko (Tier 2).

FDA Cybersecurity Klassifizierung

Stufen von Geräten

Die Cybersecurity-Klassifizierung hängt dabei nicht mit der Produkt-Klassifizierung zusammen. So kann es z.B. ein Medizinprodukt der Klasse II (z.B. Infusionspumpe) geben, das der höheren Klassifizierung Tier 1 entspricht, während ein Klasse III Produkt (z.B. Herzschrittmacher) ohne Konnektivität Tier 2 entsprechen kann. Maßgeblich ist der in der Abbildung oben beschriebene Entscheidungsprozess.

Produkte, die der Klasse Tier 1 entsprechen, haben dabei strengere Regelungen an die Dokumentation. Für diese Produkte sind alle Empfehlungen der Richtlinie zu befolgen. Für Produkte der Klasse Tier 2 können einzelne Empfehlungen ausgelassen werden, wenn dafür eine risikobasierte Begründung vorliegt.

Wie können sich Geräte vor Angriffen schützen?

In der Übersicht unten sehen sie eine Checkliste von Maßnahmen, die sie bei der Entwicklung von Geräten berücksichtigen sollten. All diese Punkte stammen aus der FDA Richtlinie. An dieser Stelle sollen die Punkte in Kürze gezeigt werden, damit Sie einen Überblick bekommen.

  • Nicht autorisierte Zugriffe verhindern
    • Zugangsbeschränkungen für vertrauenswürdige Benutzer und Geräte
      • Zugangsbeschränkung durch Benutzer ID, Passwort, Smartcard oder biometrisch.
      • Automatische Abmeldung des Nutzers nach einem Timeout, sofern sinnvoll.
      • Verwendung unterschiedlicher Zugriffsrechte
      • Authentifizierung für Administratoren oder Service Mitarbeiter
      • Starke Passwörter. Nicht fest einprogrammiert, einfach zu erraten, Default-Passwort, Selbes Passwort für alle Geräte, nicht änderbare Passwörter, schwierig zu ändernden Passwörter, öffentlich zugängliche Passwörter.
      • Physische Sperren, um Manipulation von Kommunikationsschnittstellen zu reduzieren.
    • Authentifizierung und Prüfung sicherheitskritischer Kommandos
      • Benutzung einer Authentifizierung, um nicht autorisierten Zugang zu Gerätefunktionen zu verhindern.
      • Benutzer Authentifizierung vor der Freigabe von Software-Updates inklusive Betriebssystem, Anwendungen oder Anti-Malware Software.
      • Verwendung einer kryptografisch starken Authentifizierung, die auf dem Gerät gespeichert ist.
      • Authentifizierung aller externen Geräte (z.B. eine Verbindung zu einem Server).
      • Authentifizierung von Firmware und Software (Signaturen, Nachrichten-Authentifizierung, Versionsnummer oder andere Metadaten). Geräte sollen elektronisch identifizierbar sein.
      • Die Authentifizierung soll auf Grundlage von Zugangsdaten oder anderen Möglichkeiten erfolgen, die nicht durch andere Geräte ausgelöst werden können.
      • Das Gerät soll nach der Richtlinie “Deny by default” (Standardmäßig verweigern) realisiert werden. Was nicht explizit erlaubt ist, soll erst einmal verboten sein. So sollen z.B. alle unautorisierten Verbindungen (TCP, USB, Bluetooth, serielle Schnittstellen) abgelehnt werden.
      • So wendig Rechte wie notwendig gewähren.
  • Sicherstellen von verlässlichem Inhalt
    • Code Integrität
      • Nur Software-Updates zulassen, die kryptografisch überprüft sind. Downgrades verhindern.
      • Wo das möglich ist, Software Integrität vor der Ausführung überprüfen (z.B. durch digitale Signaturen).
    • Daten Integrität
      • Eingehende Daten auf Integrität prüfen.
      • Sichere Datenübertragung zum Gerät und vom Gerät und wenn sinnvoll Punkt zu Punkt Verschlüsselung.
      • Schutz der Integrität der Daten, die für die funktionale Sicherheit und wesentlichen Leistungsmerkmale notwendig sind.
      • Ausreichend starke Verschlüsselung nach Stand der Technik.
      • Gerätespezifische Verschlüsselung, damit beim Verlust eines Schlüssels nicht alle Geräte betroffen sind.
    • Ausführungsintegrität
      • Wo machbar, soll man die Best Practices nutzen, um die Integrität des Codes während der Ausführung überprüfen.
Hinweis: Security Anforderungen können im Widerspruch zu Safety Anforderungen stehen! So kann z.B. eine Authentifizierung zu einer Verzögerung der Behandlung führen, die nicht akzeptabel ist. In diesen Fällen gilt es zwischen Safety und Security abzuwägen und die Entscheidung zu dokumentieren.

Die Richtlinie erwähnt auch auf die Vertraulichkeit der Daten, wobei dieses Thema nicht explizit behandelt wird. Als Hersteller muss man sich Gedanken über den Schutz der Patientendaten machen. Hier gilt z.B. die DSGVO und andere Richtlinien und Gesetze.

Wie können Geräte mit Angriffen umgehen?

Cybersecurity Angriffe sollen natürlich möglichst verhindert werden. Doch falls es trotzdem zu einem Vorfall kommt, so ist es notwendig einen Angriff zu erkennen, zu melden und den Schaden möglichst wieder rückgängig zu machen. Dafür sollen die nachfolgenden Punkte beachtet werden.

  • Design der Geräte damit ein Cybersecurity Angriff zeitnah erkannt wird.
    • Das Gerät soll Angriffe, während dem Betrieb erkennen und mit Zeitstempel protokollieren.
    • Das Gerät soll es ermöglichen, dass Routine Checks und Antivirus Scans durchgeführt werden können, ohne sich auf die wesentlichen Leistungsmerkmale des Gerätes auszuwirken.
    • Das Gerät soll Protokolle mit Cybersecurity-relevanten Ereignissen anlegen und speichern können. Wichtig ist die Dokumentation wie und wo die Daten gespeichert oder archiviert und ausgewertet werden sollen.
    • Das Gerät soll sichere Konfigurationen spezifizieren, die mögliche Schwachstellen so weit wie möglich begrenzen.
    • Das Gerät soll so gestaltet sein, dass es das Konfigurationsmanagement unterstützt. So soll es für den autorisierten Nutzer möglich sein, Software Änderungen nachvollziehen zu können.
    • Der Produktlebenszyklus soll es erleichtern die Schwachstellen über verschiedene Produktlinien und Produktvarianten zu analysieren.
    • Das Gerät soll eine CBOM (Cyber Security Bill of Material) in einer elektronische maschinenlesbaren Form besitzen. Mehr dazu weiter unten im Blog-Beitrag.
  • Design der Geräte damit ein Cybersecurity-Angriff gemeldet und die Auswirkungen eines Angriffs bewertet werden können.
    • Das Gerät soll den Benutzer nach einem potenziellen Angriff benachrichtigen.
    • Das Gerät soll so realisiert sein, dass zukünftige Software Patches und Updates eingespielt werden können, um Schwachstellen zu beseitigen.
    • Es soll möglich sein, Patches und Updates zügig zu verifizieren und validieren.
    • Die Architektur muss es erleichtern, dass zügig Patches und Updates aufgespielt werden können.
  • Design der Geräte damit Funktionalitäten schnell wieder hergestellt werden.
    • Kritische Funktionalitäten möglichst so realisieren, dass selbst bei einer Kompromittierung des Gerätes, diese nicht betroffen sind.
    • Durch einen Benutzer mit besonderen Rechten, soll es möglich sein, Gerätekonfigurationen wieder herzustellen.
    • Es ist zu spezifizieren, wie autonom das Gerät bei Ausfall von Kommunikation weiterarbeiten kann (Resilienz).
    • Das Gerät soll resilient gegen mögliche Angriffe wie Netzwerkausfälle, Denial-of-Service Angriffe, exzessive Bandbreitennutzung, Jitter oder andere Störungen sein.

Was ist bei dem Labeling zu berücksichtigen?

Auch durch das Informieren des End-Anwenders kann die Security verbessert und damit das Risiko für Angriffe reduziert werden. Folgende Punkte nenn hierbei die FDA Richtlinie:

  1. Anweisungen im Hinblick auf Maßnahmen zur Verbesserung der Cybersecurity bei Nutzung des Produktes (z. B. Verwendung von Anti-Virus Software oder einer Firewall).
  2. Eine Beschreibung der Features, die auch im Falle einer Kompromittierung funktionstüchtig bleiben.
  3. Eine Beschreibung, wie ein Backup / Wiederherstellung durchgeführt oder die Konfiguration zurückgesetzt werden kann (z.B. Werkseinstellung).
  4. Hinweise für den Benutzer für notwendige Infrastruktur, um das Gerät nutzen zu können.
  5. Eine Beschreibung wie das Produkt sicher konfiguriert werden kann.
  6. Eine Liste der Netzwerk Ports und anderer Schnittstellen die Daten senden oder Empfangen. Ein Hinweis, dass ungenutzte Ports deaktiviert werden sollen.
  7. Eine Beschreibung, wie ein User sicher ein Software-Update erhalten kann.
  8. Eine Beschreibung, wie ein Gerät unberechtigte Zugriffe meldet (z.B. Fehlgeschlagene Login Versuche, Konfigurationsänderungen, Netzwerk Anomalien und unzulässige Kommunikation).
  9. Beschreibung der Logging Mechanismen des Produktes.
  10. Eine Beschreibung, wie ein autorisierter Benutzer Daten und Konfigurationen wiederherstellen kann.
  11. Eine ausführliche Beschreibung für den End-Anwender durch System Diagramme.
  12. Eine Cybersecurity Bill of Material, um den Anwender in die Lage zu versetzen Schwachstellen zu erkennen und Gegenmaßnahmen vorzunehmen.
  13. Wenn zutreffend, eine Anleitung wie eine sichere Verbindung zu Service-Zwecken herzustellen ist. Weiterhin eine Anleitung, wie der Benutzer Security Vorfälle melden kann.
  14. Informationen darüber, falls der Support durch den Hersteller nicht mehr  aufrechterhalten wird. Dann ist davon auszugehen, dass die Risiken über die Zeit zunehmen werden.

Risikomanagement Dokumentation

Das Risikomanagement verbindet das Design mit dem Gefährdungsmodell, den klinischen Risiken, den Maßnahmen und der Verifizierung. Um die Risiken adäquat zu beherrschen, bedarf es eines sicheren Designs. Die Prinzipien für das Risikomanagement für Cybersecurity wird durch die AAMI TIR57 (Principles for medical device security – Risk management) festgelegt. Um vertrauenswürdige Produkte zu entwickeln, bedarf es der folgenden Punkte:

  1. Ein Gefährdungsmodell auf Systemebene welches System Risiken betrachtet.
  2. Eine Liste aller Cybersecurity Risiken, die für das System zutreffen.
  3. Eine Liste aller umgesetzten Cybersecurity Maßnahmen mit Begründung. Die Maßnahmen sind in Form von verifizierbaren Anforderungen zu formulieren.
  4. Dokumentation der Testergebnisse.
  5. Eine Traceability Matrix, die die Cybersecurity Risikokontrollmaßnahmen mit den Risiken und der Verifizierung verbindet.
  6. Eine Cybersecurity Bill of Material (CBOM). Dazu mehr im darauffolgenden Kapitel.

Für die Verifikation sind folgende Themen zu adressieren:

  1. Test der Gerätefunktionalität
  2. Nachweis, dass Software von dritten (Off-The-Shelf Software) in Bezug auf Cybersecurity sicher ist.
  3. Statische und dynamische Code Analyse mit Test von Zugangsdaten (fest einprogrammierte Passwörter, Default-Passwörter oder einfach zu erratende oder einfach zu umgehende Passwörter.
  4. Schwachstellen Scan
  5. Tests der Robustheit
  6. Grenzwert Analyse
  7. Penetrationstests
  8. Test Berichte von Außenstehenden.

Was ist die Cybersecurity Bill of Material (CBOM)?

Die CBOM ist eine vollständige Liste aller Komponenten inklusive kommerzieller Software, Open Source Software, Off-The-Shelf Software aber auch Hardware, welche Schwachstellen für die Cybersecurity aufweisen können. Bei der Erstellung der CBOM sind Datenbanken wie z.B. die National Vulerability Database (NVD) oder andere ähnlichen Datenbanken nach Schwachstellen und bekannt Vorkommnissen zu prüfen. Dabei sind Kriterien für den Umgang mit Schwachstellen festzulegen und Begründungen zu dokumentieren, sofern Schwachstellen nicht behoben werden.

Fazit

Der Schutz der Geräte gegen Angriffe wird zunehmend wichtiger. Es gibt eine Vielzahl von Regularien und Quellen, die Hersteller von Medizinprodukten heranziehen können. Die hier besprochene Richtlinie der FDA ist mit Sicherheit eine ganz wesentliche und gibt einige wichtige Hinweise, die beim Design zu berücksichtigen sind. Und das nicht nur dann, wenn man das Produkt in den USA zulassen möchte. Wir merken zunehmend, dass die Cybersecurity eine immer wichtigere Rolle in unseren Projekten hat und wir unterstützen unsere Kunden dabei, vertrauenswürdige (trustworthy) und sichere Medizinprodukte zu entwickeln. Sofern sie dazu Fragen haben, treten sie gerne mit uns in Kontakt.

Viele Grüße
Goran Madzar

Auch interessant:

Architekturentscheidungen dokumentieren

Warum um Himmels willen haben wir das damals so entschieden? Wer hat sich nicht schon einmal während der Entwicklung gefragt, auf welcher…

Autor

  • Seit Mai 2007 bin ich zusammen mit meinem Kollegen Martin Bosch selbständig. Unser Standort ist im Innovations- und Gründerzentrum in Erlangen. Hier entwickeln wir für Kunden in der Medizintechnik mit unseren Mitarbeitern Lösungen für die Produkte von Morgen.

Wie hilfreich war dieser Beitrag?

Durch das Anklicken der Sterne wird ein Cookie in diesem Browser gespeichert, um das mehrfache Abgeben von Bewertungen zu verhindern. Durch das Anklicken der Sterne erlauben Sie medtech-ingenieur.de das Cookie zu speichern.

Es gibt bereits 0 Bewertung(en) mit einer Durschnittsbewertung von 0.

Bisher keine Bewertungen! Seien Sie der Erste, der diesen Beitrag bewertet.

Es tut uns leid, dass der Beitrag für Sie nicht hilfreich war!

Helfen Sie uns, diesen Beitrag zu verbessern!

Wie können wir diesen Beitrag verbessern?

Getagged mit: , , ,