IT-Security bei “Legacy Devices”

Dass Gesetze und Normen die IT-Security auch bei „Legacy Devices“ einfordern, ist verständlich. Die Art, wie diese Anforderungen formuliert werden, führt allerdings oft zu Verwirrung.

Beispielsweise konnten sich Gesetzgeber und Normenkomitees nicht auf gemeinsame Definitionen einigen. So geht es einmal um die IT-Sicherheit bei Legacy Devices, einmal um die IT-Sicherheit von Altprodukten bzw. von Bestandsprodukten und woanders um die IT-Sicherheit bei Software in Transition.

Auch die Anforderungen an die IT-Sicherheit von Medizinprodukten, die Software enthalten oder Software sind, sind nicht aufeinander abgestimmt.

Dieser Artikel ordnet ein und verschafft Medizinprodukteherstellern, Benannten Stellen und Betreibern einen Überblick.

1. IT-Security – um welche Produkte geht es?

a) Kontext

In diesem Beitrag geht es um Medizinprodukte,

• die bereits in den Verkehr gebracht wurden und
• die Software enthalten bzw. Standalone-Software sind und
• bei denen es Risiken durch mangelnde IT-Sicherheit geben kann.

Dabei lassen sich folgende Situationen unterscheiden:

1. Die Konformität mit aktuellen Anforderungen ist nachgewiesen.
   Der Hersteller hat die aktuell gültigen Anforderungen an die IT-Sicherheit bereits ermittelt und nachgewiesen.
2. Die Konformität mit aktuellen Anforderungen ist NOCH nicht nachgewiesen.
   Der Hersteller hat die Produkte konform mit der „alten Gesetzgebung“ entwickelt. Er hat die Konformität mit neuen regulatorischen Anforderungen noch nicht nachwiesen, z. B. weil diese unbekannt sind oder weil Ressourcen fehlen.
3. Die Konformität mit aktuellen Anforderungen kann nicht nachgewiesen werden.
   Der Hersteller hat festgestellt, dass er die aktuell gültigen regulatorischen Anforderungen nicht erreichen und damit nicht nachweisen kann, etwa weil
   • enthaltene Softwarekomponenten (SOUP/OTS) von Drittanbietern abgekündigt oder nicht mehr gewartet werden,
   • der damalige Hersteller nicht mehr existiert oder
   • das Design oder die Technologie des Produkts so veraltet sind, dass eine Umsetzung von IT-Sicherheitsmaßnahmen nicht mehr möglich ist.

b) Begriffsdefinitionen

Normen und Leitlinien unterscheiden die oben genannten Situationen auch begrifflich:

Transitional Health Software

Die IEC 81001-5-1 bezeichnet die Software bei Produkten der Situation 2 als “Transitional Health Software”.

Allerdings schließt diese Definition die Software in Situation 3 nicht aus. Denn sie unterscheidet nicht, ob die Anforderungen nicht oder noch nicht erfüllt sind.

Legacy Device

Das IMDRF-Dokument N70 definiert die Produkte mit Software, deren Konformität mit den aktuellen Anforderungen nicht nachgewiesen werden konnte (Situation 3), als „Legacy Devices“.

Diese Definition bezieht „legacy“ nur auf den Kontext der „Cybersecurity“. Die IMDRF adressiert in ihrem Dokument nur „Cybersecurity Threats“, welche eine Auswirkung auf die Sicherheit der Patienten haben. Eine negative Auswirkung ausschließlich auf die Datensicherheit ist beispielswese nicht im Umfang des Dokuments.

Leider stimmt die Definition des Begriffs „Legacy Device“ des IMDRF nicht mit der Definition der IEC 62304 überein.

Diese Definition unterscheidet (im Gegensatz zur Definition des IMDRF) nicht, ob die IT-Sicherheit und damit die Konformität wieder erreicht werden können (s. auch Abb. 1). Sie berücksichtigt auch nicht das Alter des Produkts. Die IEC 62304 geht aber davon aus, dass das Produkt weiter vermarktet wird.

Dieser Artikel verwendet den Begriff „Altprodukt“ als Überbegriff für alle Situationen, in denen die IT-Security von Medizinprodukten, die vor dem Gültigkeitsbeginn der aktuellen regulatorischen Anforderungen in den Markt gebracht wurden, nicht oder noch nicht nachweisen wurde.

c) Fragestellung und deren Relevanz

Hier stellt sich nun die Frage, wie “Altprodukte” im Hinblick auf IT-Sicherheit behandelt werden müssen, und zwar für die oben genannten Situationen 2 und 3 (Konformität mit aktuellen Anforderungen ist noch nicht nachgewiesen bzw. kann nicht nachgewiesen werden). Die Frage lautet:

Gibt es einen “Bestandsschutz”, d. h. eine uneingeschränkte Weiterverwendung der Produkte im Markt für “Altprodukte” im Sinne von “transitional health software” oder von “legacy devices”?

Die Antwort auf diese Frage ist entscheidend. Denn gerade für sehr alte Produkte ist es oft nicht mehr (wirtschaftlich) möglich, deren Software zu aktualisieren, weil

• die verwendeten Technologien nicht mehr existieren oder nicht mehr aktualisiert wurden (Programmierumgebungen, Bibliotheken),
• ein Update auf der alten Hardware nicht mehr lauffähig wäre,
• bei Entwicklung keine Mechanismen für eine einfache (Fern-)Wartung vorgesehen wurden,
• die Betreiber nicht bereit sind, für diese Software-Wartung zu bezahlen.

Wenn der Bestandsschutz fällt, könnten sich viele Hersteller veranlasst sehen, die Produkte vom Markt zu nehmen.

2. Kein genereller Bestandsschutz für „Altprodukte“

Die Antwort auf die oben aufgeworfene Frage ist eindeutig:

Im Kontext der IT-Sicherheit gibt es bei „Altprodukten“ keinen generellen Bestandsschutz!

Die ökonomischen Folgen für Hersteller und selbst eine drohende schlechtere Versorgung der Patienten sind keine Argumente, um auf die IT-Sicherheit der Altprodukte zu verzichten.

a) Begründung 1: Besonderheit von IT-Sicherheitsrisiken

Die Motivation für ausreichende IT-Sicherheitsmaßnahmen liegt in der besonderen Bedrohungslage durch Cyberattacken.

Dass die Anforderungen an die IT-Sicherheit besonders hoch sind (oder zumindest erscheinen), hat mehrere Gründe:

1. Hohe Risiken durch böswilligen Missbrauch
   Schwachstellen bei der IT-Sicherheit sind mit hohen Risiken verbunden: Die Produkte können in die volle Kontrolle von Angreifern gelangen, die beispielsweise manipulierte Gerätesoftware einspielen und auf andere Produkte im gleichen Netzwerk oder auf gesammelte Patientendaten in sehr großen Mengen zugreifen.
2. Hohe Geschwindigkeit des Missbrauchs relativiert den Nutzen von PMS-Daten
   Die Bewertung der derzeitigen “Resilienz” der Produkte gegen Cyberattacken auf Basis von Post-Market-Daten ist schwierig. In der sehr schnelllebigen Cyberwelt ändern sich Angriffs-Vektoren, Angriffs-Werkzeuge und die Fähigkeiten der Angreifer ständig. Es muss damit gerechnet werden, dass Angriffe – so sie noch nicht stattgefunden haben – nur eine Frage der Zeit sind.

Es ist also nicht sinnvoll, “Altprodukten” eine ausreichende IT-Sicherheit zu bescheinigen, nur weil keine gegenteiligen Informationen vorliegen. Vielmehr müssen fortlaufend die “Security by Design” verbessert und entsprechende IT-Sicherheits-Aktivitäten im Lebenszyklus des Produkts implementiert werden.

b) Begründung 2: Regulatorische Anforderungen

Die Hersteller müssen die gesetzlichen und normativen Anforderungen erfüllen. Die speziellen Anforderungen an „Altprodukte“ stellt das nächste Kapitel vor.

3. Regulatorische Anforderungen an die IT-Sicherheit von ”Altprodukten”

a) MDR/IVDR

MDR und IVDR legen in den grundlegenden Sicherheits- und Leistungsanforderungen in ihrem jeweiligen Anhang I fest, dass die Medizinprodukte eine IT-Sicherheit nach dem Stand der Technik aufweisen müssen.

Wie bei allen grundlegenden Anforderungen unterscheiden sie nicht zwischen Legacy Devices und Non-Legacy Devices. Sie fordern allerdings von den Herstellern, den Betreibern Vorgaben im Kontext der IT-Sicherheit zu machen.

b) IEC 62304

Die IEC 62304 verlangt, die Konformität mit allen normativen Anforderungen zu überprüfen, und damit auch die Anforderungen an die IT-Sicherheit von Legacy Devices.

Die Norm fordert in Kapitel 4.4 von den Herstellern, die Risiken zu analysieren und eine Gap-Analyse durchzuführen. Abhängig von diesen Ergebnissen sind die von der Norm für „Neuprodukte“ vorgeschriebenen Aktivitäten nachzuholen.

Die Norm unterscheidet dabei NICHT, ob diese Anforderungen einen Bezug zur IT-Security haben oder nicht.

c) ISO 14971

Die Risikomanagementnorm verpflichtet die Hersteller zu „Aktivitäten in der Herstellung und der Herstellung nachgelagerten Phase“. Dazu zählt auch die Überprüfung, ob

• neue Gefährdungen (und damit neue Risiken) vorliegen und
• der allgemeine Stand der Technik noch erfüllt ist.

Damit ist fortlaufend zu analysieren, ob alle IT-sicherheitsbezogene Risiken bekannt und nach Stand der Technik beherrscht sind.

d) IEC 81001-5-1

Spezifischer für die IT-Security bei Legacy Devices ist die IEC 81001-5-1. Besonders relevant ist der normative Anhang F zur „Transitional Health Software“. Dieser Software-Typ ist nicht mit „Legacy Software“ im Sinne der IEC 62304 gleichzusetzen.

Anhang F verpflichtet die Hersteller zu:

• Durchführung einer Gap-Analyse mit den Anforderungen der Norm
• Entwicklung eines Plans, um die Software in einen konformen Zustand zu überführen
• Post-Market-Aktivitäten gemäß der Norm

e) Leitfäden der IMDRF

Die IMDRF hat gleich zwei Leitfäden zur Cybersecurity publiziert:

• IMDRF WG/N60 FINAL2020 Principles and Practices for Medical Device Cybersecurity
• IMDRF WG/N70 FINAL:2023 Principles and Practices for the Cybersecurity of Legacy Medical Devices

Der Scope des zweiten Dokuments ist die Legacy Software gemäß der Definition des IMDRF („medical devices that cannot be reasonably protected against current cybersecurity threats”).

Als wichtigste Aufgaben des Herstellers fordert der zweite Leitfaden

• von der Entwicklung:
  • Drittanbieter-Software und deren Support-Dauer durch Anbieter berücksichtigen
  • Produkte so sicher wie möglich entwickeln, um für einen langen Zeitraum IT-Sicherheit gewähren zu können
• vom Support:
  • Schwachstellen und Risiken weiterhin zu beobachten und zu kommunizieren
  • Geplantes und tatsächliches Ende der Unterstützung klar an Betreiber kommunizieren, auch für Drittanbieter-Software

f) Leitfaden des MITRE

Das MITRE-Dokument zeigt Möglichkeiten auf, um die Cybersecurity dieser Produkte zu verbessern. Es sieht sich als Ergänzung zum IMDRF-Dokument und greift dessen Total Product Lifecycle Process (TPLC) wieder auf.

Da „Security by Design“ schlecht nachträglich zu erreichen ist, verlagert man die Maßnahmen stärke auf die Seite des Betreibers. Das Zusammenspiel von Betreiber und Hersteller bzw. die jeweiligen Aufgaben werden im Dokument herausgearbeitet und in acht konkrete Empfehlungen überführt:

1. Pilotdatenerhebung zur Unterstützung der Entscheidungsfindung beim Risikomanagement für Altgeräte
2. Entwicklung von Vorlagen für Vereinbarungen über den Informationsaustausch, um die Transparenz zu erhöhen
3. Einrichtung einer Arbeitsgruppe für die Sicherheitsarchitektur
4. Entwicklung eines Forschungsprogramms zum modularen Design für Medizinprodukte
5. Durchführung einer Studie zur Koordinierung des Schwachstellenmanagements
6. Entwicklung von Kompetenzmodellen für Rollen im Zusammenhang mit Legacy-Cyber-Risikomanagement
7. Ermittlung von Ressourcen für die Entwicklung von Arbeitskräften
8. Teilnahme an Partnerschaften für gegenseitige Hilfe. Der Aspekt der gemeinschaftlichen Verantwortung und Aufgaben im Ökosystem der Medizinprodukte steht demnach im Vordergrund und entspricht der Komplexität von Herausforderungen bei Legacy-Produkten.

Damit scheint das Dokument eine sinnvolle Ergänzung zur IEC 81001-5-1 zu sein, die in Anhang F lediglich die Aufgaben des Herstellers auflistet.

4. Notwendige Maßnahmen der Hersteller

Die regulatorischen Anforderungen sind ausreichend klar und die Hersteller wissen, was zu tun ist. Bei vielen Maßnahmen kann das Johner Institut unterstützen:

Notwendige Maßnahme	Mögliche Unterstützung
Eine Kultur im Unternehmen schaffen, die IT-Sicherheit im Bewusstsein aller Mitarbeiter verankert	Inhouse-Schulungen
Qualifikation des Personals in Punkt “IT-Sicherheit” aufbauen und auf Niveau halten	Seminar zur IT-Security Video-Trainings in der Johner Academy
“Security by Design” nachholen durch Abarbeiten des Anhangs F der IEC 81001-5-1 für alle “Altprodukte” im Markt	Workshop zum Erstellen des von der IEC 81001-5-1 geforderten Plans Unterstützung bei der Festlegung, Überprüfung und Dokumentation der IT-Sicherheitsmaßnahmen
Für Neuprodukte sicherstellen, dass sie bereits ausreichend nach Stand der Technik entwickelt wurden, und in der Post-Market-Phase fortlaufend an den Stand der Technik anpassen	Workshop zum Erstellen der von der IEC 62304 und IEC 81001-5-1 geforderten Pläne Anpassen der Verfahrensanweisungen im QMS Unterstützung bei der Festlegung, Überprüfung und Dokumentation der IT-Sicherheitsmaßnahmen
Transparenz schaffen für den Zeitpunkt, an dem ein Produkt den Status “IT-sicher” verliert und damit zum Legacy Device wird. Dazu mit regelmäßigen Penetration-Tests auf aktuellem Niveau des Standes der Technik nach bisher unbekannten Schwachstellen in Produkten und Systemen suchen. Diesen Statuswechsel frühzeitig an Betreiber kommunizieren (End of support).	Analyse, ob die IT-Sicherheit dem Stand der Technik entspricht Penetration-Tests durchführen
Mit Betreibern zusammenarbeiten, um Legacy devices mit maximaler IT-Sicherheit zu betreiben (z. B. durch Maßnahmen des Betreibers, durch Abschalten von Funktionen und Komponenten).	Risikoanalysen

5. Fazit und Zusammenfassung

Der Ansatz „Fire-and-Forget“ ist bei Medizinprodukten nicht möglich. Normen und Gesetze verpflichten die Hersteller, die Risiken durch ihre Produkte über deren kompletten Lebenszyklus hinweg zu bewerten und die Sicherheit der Produkte zu gewährleisten. Das gilt im besonderen Maß für Cybersecurity.

Hersteller stehen in vielen Fällen vor einer Entscheidung: Um diese Risiken zu beherrschen, können sie die Vermarktung der Produkte einstellen oder Cybersecurity durch eine Überarbeitung der Produkte erreichen.

Die Pflicht zur Überarbeitung ist nicht auf Produkte beschränkt, die der Hersteller weiter in den Markt bringt. Sie kann auch für Produkte gelten, die bereits in den Markt gebracht wurden.

Die MITRE gibt den Herstellern die Möglichkeit, die Cybersecurity-Risiken gemeinsam mit den Betreibern zu beherrschen. Diesen Ansatz beschreibt die IEC 81001-5-1 nicht. Daher ist es hilfreich, beide Dokumente gemeinsam zu verwenden.

---

Das Johner Institut hilft Ihnen gerne bei Fragen rund um Ihre Legacy-Medizinprodukte. Wie das ablaufen kann, erfahren Sie in einem kostenlosen Expertengespräch.

---