Connectivity und Cybersecurity bei Medizinprodukten im MDR- & IVDR- Zeitalter (Teil 2: R&D Best Practices)

Das ECRI, die wohl renommierteste Organisation, die unabhängige Vergleichstests von Medizinprodukten durchführt und veröffentlicht, benennt Cybersecurity-Angriffe als die größte Gefahr für die Gesundheitstechnologie im Jahr 2022. |> ECRI

Das |> BfArM weist deutlich darauf hin, dass entsprechend der Medizinprodukte-Anwendermelde- und Informationsverordnung (MPAMIV) Hersteller und Betreiber gleichermaßen verpflichtet sind, Risiken und Ereignisse, die im Zusammenhang mit der Vernetzung von Medizinprodukten stehen, im Rahmen der Medizinprodukte-Vigilanz zu melden.

Diese Meldungen werden veröffentlicht und die Behörde entscheidet über Handlungsbedarf beim Hersteller und bewertet sogar die Maßnahmen des Herstellers.

Die neue IEC 81001-5-1:2021-12 konkretisiert die Forderungen der MDR / IVDR (Punkt 17.2. im Anhang I) und muss heute, schon vor der Harmonisierung, als „verbindlicher“ Stand der Technik bewertet werden.

Die EU-MDR und analog die EU-IVDR fordern in den grundlegenden Sicherheits- & Leistungsanforderungen, dass Software entsprechend dem Stand der Technik entwickelt (..) wird, wobei die Grundsätze des Software-Lebenszyklus (…) zu berücksichtigen sind.

Eine Konkretisierung für die an das Requirements- & Usability Engineering und die Validierung anlehnende „obere“ Ebene findet man in der DIN EN 82304-1:2018 Gesundheitssoftware – Teil 1: Allgemeine Anforderungen für die Produktsicherheit, die Vorgaben im Bereich Architektur & Design, Implementierung und Verifizierung in der DIN EN 62304:2016-10 Medizingeräte-Software- Software-Lebenszyklus-Prozesse. (vergleiche Bild 1)

Strenggenommen ist die IEC 82304 für in Medizingeräte eingebettete Software, Programmable Electrical Medical Systems (PEMS), nicht anwendbar. Im Bild 1 wäre noch die DIN EN 60601-1:2013 Medizinische elektrische Geräte – Teil 1: Allgemeine Festlegungen für die Sicherheit einschließlich der wesentlichen Leistungsmerkmale bzw. die DIN EN 61010-1 Berichtigung 1:2022-02 zu ergänzen. Der Vollständigkeit halber sei noch auf die ISO/TS 82304-2:2021 Gesundheitssoftware – Teil 2: Gesundheits- und Wellness-Apps – Qualität und Zuverlässigkeit hingewiesen.

Die IEC 81001-5-1:2021-12 Health software and health IT systems safety, effectiveness and security – Part 5-1: Security – Activities in the product life cycle ist wirklich eine Bereicherung und erhebt zurecht den Anspruch, den Stand der Technik beim Thema Cyber-Sicherheit von Medizinprodukten zu definieren.

Daraus ergibt sich auch die Empfehlung, die IEC 81001-5-1 auch schon vor der angekündigten Harmonisierung als verbindliche Vorgabe für Hersteller von Medizintechnikeinzuordnen.

Da die IEC 81001-5-1 die Integration der Cybersecurity Prozesse in das (ISO 13485) Qualitätsmanagementsystem fordert, empfiehlt es sich, die Erweiterung kurzfristig und noch vor dem nächsten Audit zu implementieren. Das betrifft neben dem Entwicklungsprozess nach 7.3 der EN ISO 13485:2016 ergänzt um die Anforderungen des Artikels 10 Absatz 9 der MDR (analog der IVDR) und den vorgenannten IEC 82304-1 und IEC 62304 auch die folgenden „13485-“Abschnitte:

• 6. Managementbewertung: Die Bewertung der Wirksamkeit der Prozesse zur Sicherung und Steigerung der (Cyber-) Sicherheit muss mindestens alle 12 Monate erfolgen.
• 2 Personelle Ressourcen: Definition der Verantwortlichkeiten, Fortbildungen und Nachweise für die Fachkompetenz in der Cyber-Security.
• 2.3 Kommunikation: Erweiterung des Reklamations- & Vigilanz-Prozesses (8.2.3 Berichterstattung an Regulierungsbehörden und MDR Artikel 10 Absätze 8 – 12), um die Offenlegung Cyber-Security relevanter Risiken / Vorkommnisse und deren Bewertung durch einen Vulnerability-Score.
• 4.1 Beschaffungsprozess: Werden Software Module die einen Einfluss auf die Sicherheit haben können und kundenspezifisch entwickelt wurden durch einen externen Lieferenten / Entwicklungsdienstleister bezogen, sind nicht nur die Cyber-Security Anforderungen zu spezifizieren, sondern auch die Implementierung von Security Lifecycle Aktivitäten zu prüfen.
• 2 Überwachung & Messung, 8.5 Verbesserung: Frühzeitige Untersuchung bekannt gewordener „Vulnerabilities“ und kontinuierliche Verbesserung der Härtung gegen Cybersecurity-Sicherheitsmängel durch die Post-Market Beobachtungen z.B. im Rahmen des MDR Artikel 83.

Die Cyber-Sicherheit befasst sich mit allen Aspekten der IT-Sicherheit im Cyber-Raum, also sämtliche mit dem globalen Internet verbundenen IT und IT-Infrastrukturen, sowie deren Kommunikation, Anwendung, Prozesse mit Daten, Informationen und Intelligenzen. So die Definition aus dem Standardwerk von Professor Norbert Pohlmann [1] in dem potentielle Schwachstellen (engl. Weaknesses) elf Kategorien zugeordnet werden:

• Zu hohe Fehlerdichte in Software
• Identifikation und Authentifikation
• Manipulierte IT / -Sicherheitstechnologie
• Unsichere IoT Geräte
• Ungenügender Schutz vor Malware
• Unsichere Webseiten
• Nutzung mobiler Geräte
• Vertraulichkeit von E-Mails
• Bezahlen mit persönlichen Daten
• Internet-Kompetenz der Nutzer
• Fake-News und weitere unerwünschte Inhalte

Eine Verwundbarkeit (engl. Vulnerability) ist eine Schwachstelle, die durch einen Angreifer (threat actor, malicious actor) zu seinem Vorteil und zum Nachteil des zu schützenden Systems werden kann. Die Verwundbarkeit kann wiederum zu einer Bedrohung (engl. Threat) werden, wenn es einen Weg gibt, dadurch eine Vertraulichkeitsverletzung, eine Manipulation oder auch Störung der Verfügbarkeit (CIA-Triade) zu verursachen.

Werden den zu schützenden Werten, den Assets (A), der zugehörigen Verwundbarkeit (V) und der Bedrohung (B) Werte, typischerweise {1 – 5}, zugeordnet, berechnet sich das Risiko mit R = A + V + B – 2.

Während die Kategorien 5 – 11 vermutlich eher in der Verantwortung der IT-Abteilung und dem Risiko Management von MedTech Unternehmen liegen, also die Kontrolle der Sicherheitsmechanismen der Rechner in der Produktion, der Produktentwicklung, dem zentralen technischem Service und insbesondere auch den Service-Technikern im Feld (siehe ISO/IEC 27000), sind die ersten Punkte direkt auf die Cyber-Sicherheit von (vernetzten) Medizinprodukten anwendbar.

|> Zu hohe Fehlerdichte in Software

Die Fehlerdichte, die Anzahl der Softwarefehler pro 1000 Zeilen Code, ist bei qualitativ hochwertiger Software heute im Schnitt 0,3. Da gängige Betriebssysteme ca. 10. Mio. Zeilen Code haben, sind hier im Schnitt 3.000 Softwarefehler zu finden. [2] Normativ finden wir einige Vorgaben und Best Practices zum sicheren Codieren z.B. in der ISO/IEC TR 24772, den MISRA-C oder SEI CERT C und SEI CERT C++ Kodierungsstandards und im Anhang A.4 Secure coding best practices for healthcare software der IEC 81001-5-1:2021.

|> Identifikation und Authentifikation

Sind die Netzwerk- & Connectivity Einstellungen eines Medizinproduktes frei, oder durch ein in der Gebrauchsanweisung oder dem Service Manual abgedruckten hardcoded Passwortes zugänglich, werden Man-in-the-Middle-Angriffe (MitM) und Redirects (Routing) Angriffe nahezu trivial.

Stellt das Medizinprodukt USB-Ports für den technischen Service oder auch den Export von Diagnose- / Therapiedaten auf einen beliebigen USB-Stick zu Verfügung, sollten nicht nur Aspekte zum Schutz patientenbezogener Daten implementiert sein, sondern auch die Härtung des Schutzes gegen Exploits systematisch bewertet sein. Exploits bezeichnen eine Schadsoftware (engl. Malware), die Verwundbarkeiten des Systems ausnutzt. Das Institut für Internet-Sicherheit geht zurzeit davon aus, dass auf jedem 10ten IT-Endgerät in Deutschland ungewollte intelligente Malware vorhanden ist, die über ein Botnetz gesteuert wird. [1]

Bevor wir im Abschnitt 6 nochmal auf diese Angriffsvektoren eingehen, wollen wir uns im folgenden Abschnitt auf die Sicherheit der Einbindung von Medical Devices in TCP/IP- und Internet-of-Medical-Things– Netzwerke (IoT, IoMT) fokussieren:

Im Gegensatz zu den Großgeräten z.B. aus der Bildgebung oder Laboratoriumsmedizin bergen die als fest, ortsveränderlich, fahrbar oder gar tragbar klassifizierten Medizinprodukte Herausforderungen bei der Sicherung des Netzwerkzugangs. Das Netzwerkkabel in einer speziell markierten Buchse reicht als alleiniger Schutz auf Netzzugangsebene nicht aus.

Um beim Wireless Wardriving, also dem aktiven Suchen nach offenen WLAN (ZigBee-, EnOcean-) Netzwerken nicht zur Hintertür z.B. eines Kliniknetzwerkes zu werden, sollte der Zugang zur WLAN-Konfiguration auf allen Medizinprodukten abgesichert und offene, WEP und WPA Konfigurationen nicht möglich sein. Erst WPA-2 (AES) gilt bei regelmäßigem Wechsel des symmetrischen Pre-Shared Key (PSK) als moderat, WPA-3 als durchaus sicher.

IEEE 802.1X ist ein Standard für die Authentifizierung von Geräten bei einem Authentication Service wie z.B. LDAP, RADIUS, …, die sich mit einem kabelgebundenen- oder WLAN-Netzwerk verbinden möchten.

Die wohl einfachste und recht effektive Methode des Zugriffsschutz auf der Netzwerkschicht ist der MAC-Filter, d.h. das Eintragen der MAC-Adresse jedes einzelnen Medizinproduktes auf die Whitelist. Das sollte auch das Risiko durch DHCP-Spoofing und DHCP Starvation Attacks minimieren.

Beim Port/Address Locking wird eine MAC-Adresse an einen bestimmten Port gebunden. Jede andere MAC-Adresse wird an diesem Port nicht akzeptiert und die Datenpakete verworfen.

Beim (Port-) Scanning versucht der Angreifer alle IP-Adressen eines Netzwerkes anzusprechen, um dann offenen Ports / Diensten aufzuspüren. Das Protocol Fuzzing sendet nichtvorgesehene (malformed) Inhalte an eine Schnittstelle / einen Port, um über einen Fehler in der Implementierung das Zielsystem zu beeinflussen, z.B. zum Absturz zu bringen. Angriffe, die darauf zielen das System außer Betrieb zu setzen, werden als Denial-of-Service (DoS-) Angriffe bezeichnet.

Die unverschlüsselte Datenübertragung von z.B. HL7 Messages per UDP oder TCP Verbindung können ohne entsprechende in der Netzwerkarchitektur implementierte Sicherheitsmechanismen wie Abschottungsfunktionen durch Firewalls und virtuelle Netzwerke (VLANs) mitgelesen (Sniffen) und verändert (Spoofing) werden.

Firewall-Systeme sichern und kontrollieren den Übergang von einem zu schützenden Netz zu einem unsicheren Netz. Neben dem Verbergen der internen Netzstruktur stehen die Zugangskontrollen auf Netzwerk-, Nutzer- und Datenebene, sowie die Rechteverwaltung im Vordergrund.

IPSec (Internet Protocol Security) sichert die Integrität und Authentizität der (TCP/UDP) Daten (Authentication Header, AH) genauso wie die Vertraulichkeit der Daten über Verschlüsselung (Encapsulating Security Payloard, ESP).

Mit IPSec lässt sich ein sicherer Datenaustausch zwischen separierten Netzwerken realisieren. So können Medizinprodukte beispielsweise mit EHR- / IT-Systemen oder mit den IoMT Servern der Hersteller verbunden werden.

Das Netzwerkprotokoll Transport Layer Security (TLS) wird, wie in Bild 2 zu sehen, zur Sicherung von Daten der Anwenderschicht genutzt. Neben der Verschlüsselung kann TLS auch einen Beitrag zur Authentifizierung der Kommunikationsteilnehmer leisten.

Durch die Verifizierung, der Identität, des Zielsystems können sogenannte Man in the Middle Angriffe auf die Kommunikation effektiv verhindert werden. Idealerweise wird mutual TLS (mTLS) eingesetzt, so dass auch die Quelle durch das Zielsystem verifiziert werden kann, bevor das erste Byte Applikationsdaten ausgetauscht wird.

Ein VPN emuliert ein Netzwerk, es unterstützt das Routing unterschiedlicher Protokolle, Ports und potentielle IP-Adressen und wird häufig zur Verknüpfung getrennter Netze über unsichere Medien (Internet) eingesetzt.

IPSec ist eine VPN Technologie, im Sprachgebrauch meint VPN allerdings normalerweise Softwarelösungen, die einen Endpunkt in ein entferntes Netzwerk einklinken können, oft inklusive der Filterung auf bestimmte Dienste (Laptop -> Firmennetz).

VPN Technologien können komplexe Einsatzszenarien mit geringem Aufwand ermöglichen und Netzwerkgrenzen verwischen. Für den sicheren Betrieb sollte der breite Zugriff durch explizite Freigaben / Whitelisting beschränkt werden und bei der Authentifizierung auf ein möglichst hohes Schutzniveau geachtet werden.

Bei Zero Trust handelt es sich um ein neuartiges        Sicherheitskonzept für Firmennetze, das unter dem zunehmenden Druck der Digitalisierung und Vernetzung aber auch durch immer professioneller agierende Hacker und Ransomware Banden – und damit zunehmender Sicherheitsrisken – rasant an Bedeutung gewinnt.

So fordert die US Regierung in einem Anfang 2022 erschienenen Memorandum M-22-09 die konkrete Umsetzung einer Zero Trust Strategie von nachgelagerten Ministerien und Behörden. Auch die CMMC Zertifizierung des Department of Defense weist starke Querbezüge zu Zero Trust auf und eine Übernahme der Kernprinzipien in relevante Normen und Leitlinien für den Betrieb kritischer Infrastruktur ist nur eine Frage der Zeit.

Was aber ist Zero Trust: Im Grundsatz die Abkehr von einer nach außen gerichteten Gefahrenabwehr, die die sichere und sorgenlose Kommunikation in einem geschützten inneren Netzwerk ermöglicht. Die grundlegende Erkenntnis hinter Zero Trust ist, dass eine solche externalisierte Abwehr nicht dauerhaft erfolgreich sein wird. Statt auf den Schutz der Netzübergänge zu vertrauen zielt eine Zero Trust Architektur darauf ab, durch geeignete Maßnahmen die Risiken und Schäden durch Sicherheitszwischenfälle unter Einbeziehung aller Akteure und der gesamten Kommunikation zu minimieren.

Im Wortsinn geht es um die Abkehr von Sicherheitsstrukturen, die auf (implizitem) Vertrauen beispielsweise basierend auf dem (Netzwerk-)Standort fußen und zu expliziter Verifizierung und Absicherung aller Kommunikationsteilnehmer hinführen. Der Schutz von Daten, Anwendungen & Geräten, geht vor dem Schutz von Netzwerken.

Konkret lassen sich basierend auf der Definition des amerikanischen „National Institute of Standards and Technology“ NIST folgende Kernziele ableiten:

1. Aktives Management der Sicherheit aller firmeneigenen und assoziierten Geräte
2. Starke Authentifizierung der Kommunikationspartner (mTLS), Benutzer (MFA) und Geräte (Zertifikate)

• Durchgehende Verschlüsselung der Kommunikation

1. Individuelle Autorisierung jedes Zugriffes und Nichtübertragbarkeit der Autorisierung auf weitere Geräte / Anwendungen
2. Dynamische Zugriffskontrollen, die beispielsweise Benutzergruppenzugehörigkeit mit der Authentifizierungsstärke und einer Risikobewertung kombinieren

Durch die konsequente Anwendung des „Least Privilege Principles“ können im Ergebnis die Wahrscheinlichkeit und die Auswirkungen von Sicherheitszwischenfällen verringert werden.

Aus Sicht eines Infrastrukturbetreibers fokussiert sich Zero Trust erst einmal auf die klassische IT, beispielsweise auf das Krankenhausmanagementsystem, das Bestellungswesen, Tools zum Erstellen von Schichtplänen und den sicheren Zugriff zu ebendiesen IT-Anwendungen für die Angestellten.

Mindestens genauso wichtig ist allerdings die Sicherheit und Einsatzbereitschaft von CT Scannern, Laborgeräten und Vitalparameter Monitoren. Gerade im Bereich der Medizingeräte erleben wir heute zwei gegenläufige Entwicklungen. Auf der einen Seite steigt der Vernetzungsgrad an. Die Fähigkeiten zur Fernwartung und Datenanalyse gewinnen im „After Sales“ Bereich stark an Bedeutung. Andererseits werden die Sicherheitsvorschriften immer strikter: So hat die FDA in letzter Zeit vermehrt Medizinprodukte aus Gründen der Cybersicherheit zurückgerufen und auch in Europa ist das Risikobewusstsein gewachsen, erkennbar beispielsweise an den BSI Normen zur Datensicherheit sowie beim Thema Softwareklassifizierung MDD / MDR.

Die Anwendung von Zero Trust Prinzipien und die Fähigkeit zur Integration in eine Zero Trust Architektur sind hier Kernelemente eines zukunftssicheren Produktportfolios. Der klassische Weg, sichere Kommunikation mit einem Krankenhausnetzwerk über einen VPN oder einen zentralen IPsec Router herzustellen, ist nach diesen Maßstäben nicht mehr zukunftssicher. Ohne weitergehende Absicherungsmaßnahmen werden die Prinzipien III), IV) und V) verletzt.

Abhilfe kann durch Konnektivitätslösungen geschaffen werden, die den Schutz dichter an oder auf das Gerät verlagern und nicht vom impliziten Vertrauen in eine gesicherte Infrastruktur abhängig sind. Weitere Merkmale solcher Lösungen sind:

• Verschlüsselung jeglicher Kommunikation
• starke Authentifizierung aller Aktoren
• Klassifikation von Daten, besonderer Schutz von Patientendaten
• Integrationsfähigkeit mit weiteren Bausteinen einer Zero Trust Architektur
• Modellierung von Zugriffsrechten, dynamische Zugriffskontrollen
• Nachvollziehbarkeit von Zugriffen

In Kombination mit geräteseitigen Funktionen, wie beispielsweise der Entkopplung von Safetymaßnahmen, der Umsetzung einer starken Geräteidentität, der Anwendung des Least Privilege Principles und der Klassifikation und Annotation von Daten können weitreichende Use Cases aus dem Bereichen After Sales, Pay per Use, Remote Service, Data Analytics oder Predictive Maintenance nachvollziehbar sicher umgesetzt werden.

Medizinische Versorgungseinrichtungen wie Arztpraxen und Krankenhäuser zählen in der Regel zur kritischen Infrastruktur, die besonders hohe Anforderungen an die Resilienz der IT-Infrastruktur stellen müssen.

Die DIN EN ISO/IEC 27001:2017 beschreiben die Anforderungen an Informationssicherheitsmanagement (ISMS) und definiert den Stand der Technik.

Beispielsweise wurden in Deutschland die Vorgaben aus § 8a Sicherheit in der Informationstechnik Kritischer Infrastrukturen des BSI Gesetztes im Branchenspezifische Sicherheitsstandard (B3S) für die Gesundheitsversorgung im Krankenhaus umgesetzt.

Nach dem Sozialgesetzbuch (SGB) V sind deutsche Krankenhäuser seit dem 1. Januar 2022 verpflichtet, ihre IT-Sicherheit nach dem Stand der Technik umzusetzen. (SGB V § 75c). 

Eine ähnliche Priorität erfordert die praktische Umsetzung der Vorgaben zum Datenschutz (EU- 2016/679 Datenschutzgrundverordnung DSGVO) und der gesetzlichen Vorgaben zum Schutz elektronischer Patientendaten in der Telematikinfrastruktur, in Deutschland definiert durch das Patientendaten-Schutz-Gesetz (PDSG), in den USA der Health Insurance Portability and Accountability Act HIPAA).

Ein (zentraler) Aspekt der Verantwortung der Betreiber ist die Cyber-Sicherheit bei der IT-Integration von Medizinprodukten, wie sie in DIN EN 80001-1:2011 Anwendung des Risikomanagements für IT-Netzwerke, die Medizinprodukte beinhalten – Teil 1: Aufgaben, Verantwortlichkeiten und Aktivitäten bzw. auch dem Entwurf E DIN EN 80001-1:2018 beschrieben wird.

Eine Grundvoraussetzung dafür ist, dass dem Kunden und Betreiber die benötigten Cyber-Security Detailinformationen zu den Medizinprodukten zur Verfügung gestellt werden. Damit wird die Cyber-Sicherheit von Medizinprodukten zum Beschaffungskriterium und Thema für das Downstream-Marketing und den Vertrieb.

Das Manufacturer Disclosure Statement for Medical Device Security (MDS2) erleichtert als standardisiertes und maschinenlesbares Dokument den Austausch aller (cyber-)sicherheitsrelevanten Merkmalen und Funktionen von Medizinprodukten.

MDS2 wird sich als globaler Standard etablieren und deswegen schon heute in R&D, Marketing & Vertrieb genutzt werden. |> Expertenkreis CyberMed

Im ersten Teil unserer Serie [wissenswert] Connectivity und Cybersecurity bei Medizinprodukten im MDR- & IVDR- Zeitalter (Teil 1: Stakeholder-Anforderungen) haben wir zentrale User- und Business- Cases der Connectivity von Medizinprodukten herausgearbeitet. |> Link

Die Anzeige der Verfügbarkeit einer neuen Softwareversion auf dem GUI des PEMS und die Implementierung zur automatisierten Software Verteilung (Software Distribution) sind vielleicht offensichtliche Anforderungen der inkrementellen / agilen Entwicklung von Medizinprodukten. Aus Sicht des Risiko Managements kann das Download häufig jederzeit im laufenden Betrieb erfolgen. Die Ausführung des Updates wird gern an den „Servicemodus“ gekoppelt, bei dem der Nutzer bestätigt, dass kein Patient verbunden ist.

Die Verpflichtung der Einweisung in neue Funktionen, z.B. aus der Anlage 1 des MPBetreibV, lässt sich z.B. über einen Video Link in einem QR-Code einfach realisieren.

In den folgenden Abschnitten wollen wir vielleicht nicht ganz so offensichtliche und für die Cybersecurity relevante Aspekte der Architektur von PEMS Medizinprodukten beleuchten.

Cyber-Sicherheit von Medizinprodukten und der Datenschutz sind untrennbare mit der sicheren Identifikation und Authentifikation bei sicherheitsrelevanten Zugriffen verbunden.

Die Architektur für die (Hardware-) Plattform der nächsten Gerätegeneration sollte zumindest optional entsprechende Sicherheitsmechanismen bieten, um zukünftige Beschaffungskriterien erfüllen zu können.

In der Industrie wie auch in Krankenhäusern haben sich Mitarbeiter-RFID-Karten etabliert. Mittlerweile gibt es RFID Reader Module, die nicht nur eine Vielzahl der unterschiedlichsten HF/LF RFID Karten lesen können, sondern sogar Authentifizierungen über die Near Field Communication (NFC) und Bluetooth Low Energy (BLE) Technologien ermöglichen.

Der Zugriff auf die Netzwerkeinstellungen (MAC Adresse) und die Konfiguration der Intraoperabilitäts- und Datentransfer Einstellungen lässt sich schon über einen gerätespezifischen PIN oder eine RFID Card absichern.

Die als Stand der Technik geltenden MedTec Cybersecurity-Mindestanforderungen z.B. zur Passwort Authentifizierung oder zum Handling der Schnittstellen zu Nachbarsystemen, lassen sich beim Computer-Aided Requirements Engineering aus allgemeingültigen Checklisten z.B. inspiriert durch die IEC TR 60601-4-5:2021 (…) Guidance and interpretation – Safety-related technical security specifications in das Product Backlog übernehmen.

Die Integration einer manipulationssicheren Hardware Komponente, dem s.g. Trusted Platform Module (TPM), ist mittlerweile bei Laptops Standard geworden und wird sicher auch in der Medizintechnik zum Standard werden. TPMs bieten nicht nur die Möglichkeit die Systemkonfiguration zu überwachen, sondern auch Zugangs- & Konfigurationsdaten vertraulich zu speichern. Dabei werden die Daten während der Verschlüsselung an die Systemkonfiguration gebunden, was man Sealing nennt.

Bei der Architektur zur Neuentwicklung der Plattform für die nächsten Produktgenerationen kann man auch über eine von der Betriebsspannung unabhängigen Sensorik zur Erkennung des Öffnens des Gehäuses, dem Zugang zu internen Schnittstellen, und von Stürzen und Schlägen für den Service und die Bearbeitung von Garantieschäden z.B. im Rahmen eines Vollservice- oder Pay-by-Use Vertrages nachdenken.

Wer den Wunsch von Kunden (und natürlich dem Vertrieb) nach einer klinikweiten Standardisierung der medizintechnischen Ausstattung unterstützen möchte, kann über IoMT Verbindungen in ein Kundenportal die zentrale Konfiguration und automatische Verteilung der Netzwerk- & Zugangs- & Geräteeinstellungen anbieten.

Die Integration der Netzwerkkonfiguration & Cyber-Security Settings für die verantwortlichen IT-/Datenschutzspezialisten in IoMT-Kundenportale hat auch den Vorteil, dass nicht nur die Dokumentation von Ereignissen, Auffälligkeiten und Vorkommnissen (Audit-Trail), sondern auch die (E-Mail-) Notifikation der Verantwortlichen einfach und zuverlässig realisiert werden kann.

Nicht nur im Sinne der Cybersecurity, sondern auch im Sinne eines Hygenic Designs, sollten die Hardware-Geräteschnittstellen auf das Minimum reduziert werden. RJ45 Gerätebuchsen sollten vor dem Eindringen von Flüssigkeiten (Blut, Desinfektionsmittel) mechanisch geschützt sein. Kabelloses Aufladen und flache magnetische Steckverbindersysteme erfreuen sich zunehmender Beliebtheit auch in der Medizintechnik und der Krankenhaus-Hygiene.

Wer in der Gerätearchitektur die Sensoren zur Erkennung der Handhabung und Identifikation z.B. der Verbrauchsmaterialien integriert, hat sich nicht nur im Bereich Pay-by-Use und dem Schutz vor Produktpiraterie einen Wettbewerbsvorteil gesichert, sondern eröffnet sich ganz neue Möglichkeiten der auf die Handhabung des Gerätes und der Verbrauchsmaterialien erweiterten interaktiven Bedienerführung.

Der scheinbare Widerspruch zwischen kleinen handlichen Geräten und der interaktiven Bedienerführung oder Darstellung des Therapieverlaufes auf (beliebig) großen Bildschirmen, in Augmented-Reality-Brillen (AR-Brillen) oder auf Smartphones / Tablets lässt sich durch einen Embedded Web Server (EWS) auflösen. TLS/SSL sichern die Implementierungen ab.

Der klassische Remote Service, also die Übertragung von grafischen Bildschirminhalten vom Medizinprodukt zu einem Service Techniker, lässt sich außerhalb von Großgeräten im Risikomanagement kaum beherrschen.

Der Schlüssel der zukunftsweisenden Lösung liegt darin, der technisch trivialen Lösung, der Übertragung von Geräte-Log Dateien per IPSec auf einen Server, zu widerstehen: Werden stattdessen Sensor- / Gerätestatus- und Fehlermeldungen zusammen mit der ID der aktuellen Ansicht / Menüs auf dem Gerätedisplay dargestellt, entsteht für den Remote Service ein „lebendiger digitaler Zwilling“ – und das auch während des Telefongespräches mit dem Anwender.

Die Kombination der drei letztgenannten Vorschläge, „Sensorik zur Bedienerführung in der Handhabung“, „beliebig großer 2nd Screen / AR-Brille“ und „Connected Bedienerführung“ ermöglicht durch interaktive Anwenderschulung direkt mit dem jeweiligen Gerät den größtmöglichen Lernerfolg bieten zu können.   

Die COVID-19 Pandemie hat noch einmal deutlich gemacht, wie wichtig ein Hygenic Design bei Medizintechnischen Geräten heute ist und in der Zukunft sein wird. Das wird die Bedeutung der Themen Hygenic Design & Intraoperabilität als Beschaffungskriterium z.B. in der Intensivmedizin noch einmal steigern. 

Ob zur Verbesserung der Ergonomie, des Alarm Managements, der Therapiesteuerung oder eben zur Fernbedienung der Geräte im Isolierzimmer – eine zukunftssichere Gerätearchitektur wird immer Schnittstellen für die Intraoperabilität vorsehen. Selbst bei geschlossenen Systemen von Modulen des gleichen Herstellers drängt sich die Implementierung des SDC / Vital Standards nach DIN EN ISO IEEE 11073 auf.

Im Gegensatz zum Homecare Bereich können wir in Praxen und Krankenhäusern einen Netzwerkzugang voraussetzen. Hier ist es wichtig, nicht nur den Status der Connectivity auf der GUI zu zeigen, sondern den Verbindungsstatus- und ihre Qualität (Latenz) im zeitlichen Verlauf auch auf dem Gerät sichtbar zu machen Zur Lokalisation von Medizinprodukten, z.B. im Sinne eines klinikweiten Geräte Pool- & Service Managements durch die Medizintechnik, oder die Kostenallokation bei Pay-by-Use Betreibermodellen, konnten sich Hardware basierte Real-Time Locating Systeme (RTLS) nach ISO/IEC 24730-1 ff. bislang nicht in Kliniken durchsetzen.

Sind die Stationen und Funktionsbereiche mit separaten Virtual LANs ausgestattet, kann die DHCP Netzwerkkonfiguration eine vielleicht ausreichend genaue Lokalisationen ohne großen (finanziellen) Mehraufwand bieten.

In diesem Zusammenhang sei nochmal an das Network Time Protocol (NTP) erinnert, mit dem Datum und Uhrzeit auf allen Geräten stets aktuell bleiben. Eine banale Funktion, die nicht nur für Geräte Logdateien und Audittrails, sondern insbesondere für die Zeitstempel in der Diagnostik- und Therapiedokumentation sogar juristisch relevant ist.

Der Anhang B der IEC 81001-5-1:2021 bietet eine gute Orientierungshilfe zur praktischen Implementierung der geforderten Security Life Cycle Aktivitäten in den Entwicklungs- / Wartungs- und Unterstützungsprozess des Produktes, der ein Konfigurationsmanagement mit Änderungskontrolle und -historie umfasst.

Die unter dem Begriff Security Context in der IEC 81001-5-1:2021 geforderten Informationen zum IT- Umfeld integrieren wir im Lean Innovation / Requirements Engineering schon in der Spezifikation und erweitern die Angaben zu Nutzungsumgebung & Portabilität [Bestimmungsgemäßer Gebrauch, engl. intenden purpose] im Segment Problem auch als Checkliste für die normativen Vorgaben.

Zur Erweiterung der Produktrisikoanalyse um (Cyber-) Securityaspekte bietet es sich an, methodisch auf Bewährtes wie die Vorgaben aus der DIN EN ISO 14971:2020 zurückzugreifen.

Um sicherzustellen, dass im Rahmen der Risikoanalyse auch tatsächlich jede Verwundbarkeit (engl. Vulnerability) identifiziert und bewertet wird, ist ein streng systematisches Vorgehen, das sogenannte Threat Modeling empfohlen und gefordert.

Ein Beispiel aus dem Methodenbaukasten ist der Attack-Defense Tree (ADTree), bei dem in Anlehnung an eine Fehlerbaumanalyse die möglichen Angriffsvektoren auf das Medizinprodukt visualisiert und entsprechende Verteidigungsmaßnahmen definiert werden.

Im Sinne einer Fokussierung des Aufwandes (und der Kosten) sind Methoden sehr interessant, die auf Erfahrungswissen setzen.

Aus dem “The Open Web Application Security Project” (OWASP) wird die Liste der aktuellen Top 10 der häufigsten Angriffsvektoren veröffentlicht. Die Common Attack Pattern Enumeration and Classification (CAPEC) beschreibt die bekanntesten Angriffsmuster.

Das Common Weakness Scoring System (CWSS) bietet den Vorteil, dass die Angriffsvektoren nicht nur benannt, sondern auch über ein Scoring priorisiert werden. Anhang C Treat Modelling und Anhang B der IEC 81001-5-1:2021 bieten eine gute Übersicht.

Die TRA zielt auf die Identifizierung und Bewertung von Einbruchsszenarien und den daraus resultierenden Schwachstellen ab.

Der bestimmungsgemäße Gebrauch (inkl. Security Context) ergeben zusammen mit den erarbeiteten und in ihrem Kundennutzen und dem Beitrag zum Produkterfolg bewerteten Lösungsalternativen und den Erkenntnissen aus der Threat / Risk Analysis (TRA) die Vorgaben für das R&D Team.

Darunter eben auch die Entwicklung der Defense-in-Depth Strategie nach IEC 81001-5-1:2021, einem Cybersecurity Ansatz, bei dem in übereinander liegenden Sicherheitsschichten gedacht wird. Dieser mehrschichtige Ansatz mit beabsichtigten Redundanzen erhöht die Sicherheit eines Medizinproduktes / Systems als Ganzes und spricht die verschiedene Attack–Vektoren an.

Im Anhang B der IEC 81001-5-1:2021 finden sich konkrete Vorschläge zur (Weiter-) Entwicklung der Architektur und den Prinzipien des Secure Designs.

Das Thema Cyber-Sicherheit erhöht den Umfang der Systemtests ganz erheblich: Security Requirements Testing gegen die Spezifikationen im Backlog, Threat Mitigation Tests (fuzz testing, buffer overflow testing, ..), Vulnerability und Penetration Testing zählen zu den wichtigsten Anforderungen.

Dieses Knowhow und Equipment intern aufzubauen wird sich für die meisten Unternehmen eher nicht lohnen. Da sind die Angebote von auf die Medizintechnik spezialisierten Prüflaboratorien sicher interessant. So ist auch die Trennung zwischen Entwicklung und Prüfung sichergestellt.