LinkedIn Xing
Connectivity Cybersecurity Medizinprodukte 2 |GRÜNEWALD

Von der Digitalisierung in der Medizin profitieren - HealthCare 2.0 und MedTec- Industrie 4.0:

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

Die Digitalisierung in der Medizin ist nicht nur die Schlüsseltechnologie zur Effizienzsteigerung und Schonung der Personalressourcen in der medizinischen Versorgung – Stichwort Pflegenotstand –, sondern eine wesentliche Voraussetzung zur Weiterentwicklung der Evidenzbasierten Medizin (EbM) und damit zur Steigerung und Sicherung der Versorgungsqualität. Evidence-adaptive clinical decision support systems (CDSS) unterstützen nicht nur die Therapieentscheidung, sondern auch die Delegation der Therapiesteuerung vom verantwortlichen Arzt auf das medizinische Assistenzpersonal. Medizin braucht digitale Lösungen. Der erste Teil dieses [wissenswert] Blogbeitrages hat sich auf die User- und Business Cases fokussiert. In diesem zweiten Teil berichten wir über unsere Best Practices zur Analyse und dem Nachweis der Cybersecurity und der regulatorischen & normativen Vorgaben.

Stichworte: Cyber-Security, Cyber-Sicherheit, Medical Devices, (EU) 2017/745 MDR, (EU) 2017/746 IVDR, (EU) 2016/679 DSGVO, MPG, MPSV, MPDG, MPAMIV, MDS2, Privacy by Design, MDCG 2019-16,  BSI CS-E 132, IEC 81001-5-1:2021, ISO 13485, IEC TR 60601-4-5:2021,  Threat Modeling, CAPEC, OWASP, Common Vulnerability Scoring System (CVSS)

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.

Auch über die Bedeutung des Manufacturer Disclosure Statement for Medical Device Security (MDS2) für Marketing & Vertrieb müssen wir noch sprechen.

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 embedded 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 Medizintechnik- Hersteller einzuordnen.

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 den 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 Härtung 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 Software Fehler 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 kann alleiniger Schutz der Netzzugangsschicht nicht ausreichen.

Um beim Wireless Wardriving, also dem aktiven Suchen nach offenen WLAN (ZigBee-, EnOcean-) Netzwerken nicht zur Hintertür z.B. zu Klinik Netzwerkes zu werden, sollte der Zugang zur WLAN-Konfiguration auf allen Medizinprodukten abgesichert sein 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 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 senken. Allerdings ist die Virtualisierung von MAC Adressen für IT-Spezialisten keine Hürde.

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 (Tampering) werden.

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).  

Damit lässt sich ein sicherer Datenaustausch zwischen Medizinprodukten, zwischen Medizinprodukten und EHR- / IT-Systemen und auch zwischen Medizinprodukten und IoMT Servern der Hersteller realisieren. Allerdings werden durch dieses Tunneling auch die Sicherheitsmaßnahmen des Betreibers / Krankenhausnetzwerkes umgangen. Mit dem Marketing Claim „Firewall-friendly“ sollte man sehr vorsichtig sein. Ein smarter Lösungsansatz kann ein Device Pool and Security Management Tool auf dem Server des Herstellers sein, mit dem nicht nur die Security und Datenschutzeinstellungen der Geräte in Profilen zentral konfiguriert werden können, sondern auch ein online Logging / Protokol Sniffing geboten wird. Transparenz schafft vertrauen – auch bei IT Security und Datenschutzverantwortlichen in Krankenhäusern, MVZ und Praxen.

Die Netzwerkprotokolle Transport Layer Security (TLS) bzw. der Vorgänger Secure Socket Layer (SSL) werden wie in Bild 2 zu sehen zur Sicherung von Daten der Anwenderschicht genutzt.

TLS/SSL kommt z.B. zur Absicherung von web-based Anwendungen im https: Protokoll zur Anwendung.

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

Im [wissenswert] Innovationskraft in der R&D und Schlagkraft im Vertrieb als untrennbare Erfolgsfaktoren in der Medizintechnik |> Link haben wir im Sinne des Lean Innovation & Requirements Engineering und der agilen Entwicklung von Medizinprodukten eine Plattformstrategie für die Architektur der nächsten Produktgenerationen vorgeschlagen.

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 der 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 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 hardwarenahe 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 (Tamper detection) 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 automatisch Verteilung der Netzwerk- & Zugangs- & Geräteeinstellungen anbieten.

Die Integration der Netzwerkkonfiguration & Cyber-Security Settings für die verantwortlichen IT-/Datenschutz Spezialisten 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. Wireless Charging 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.

Aus Security Sicht sollten Zugänge nur für den Zeitraum aktiviert sein, in denen sie auch von Anwender aktiv genutzt werden. Wer die Funktion der Anzeige des Links zum EWS als QR Code auf dem Display anbietet, kann diese Funktion mit der Aktivierung des Zugangs und automatischen Deaktivierung nach z.B. 1 Std. Nichtbenutzung verbinden.

Das 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 dass auch während des Telefongespräches mit dem Anwender.

Mit der Kombination der drei letztgenannten Vorschläge, „Sensorik zur Bedienerführung in der Handhabung“ + „beliebig großer 2nd Screen / AR-Brille“ + „Connected Bedienerführung“ ergibt die Möglichkeit 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 und in der Zukunft ist. 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äuser einen Netzwerkzugang voraussetzen. Im Sinne der Robustheit sollte man nicht nur den Connectivity Statusindikator präsent auf der GUI halten, sondern den Verbindungsstatus- & -Qualität (Latenz) auf einer Zeitachse auch auf dem Gerät sichtbar 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 System (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/ Uhrzeit auf allen Geräten immer aktuell bleiben. Eine banale Funktion, die nicht nur für Geräte Logdateien / Audittrails, sondern insbesondere für die Zeitstempel in der Diagnostik- und Therapiedokumentation sogar juristisch relevant sind. Allerdings bietet NTP auch großes Potential für Spoofing und Tampering Angriffe. Global Web Real-time Communication (RTC) z.B. über die IoMT-Verbindung zum Hersteller können eine smarte Lösung und Alternative bieten.

Der Anhang B der IEC 81001-5-1:2021 bietet eine gute Orientierungshilfe zur praktischen Implementierung der geforderten Security Life Cycle Activities in den Produkt Entwicklungs- / Wartungs- / Unterstützungsprozess, 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. intended purpose] im Segment Problem auch als Checkliste für die normativen Vorgaben. |> Link

Zur Erweiterung der Produkt Risikoanalyse um (Cyber-) Security Aspekte 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 alle Verwundbarkeit (engl. Vulnerability) identifiziert und bewertet werden, ist ein streng systematische 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.

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  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. Der Anhang C Threat Modelling der Anhang B der IEC 81001-5-1:2021 bietet 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.

Autoren und Feedback

Angefragt: Michael Zinsmaier ist Solution Architect bei Worldline, dem EU-Marktführer im Bereich Zahlungsverkehrs- und Transaktionsdienstleistungen und Pionier in der Zero-Trust-Network-Access (ZTNA) Technologie. |> Worldline

Lukas Fey ist Leiter des Fachbereichs Cybersecurity bei der embeX GmbH, einem der führenden Hard- & Software Entwicklungsdienstleister in der Medizintechnik |> Medical Engineering

Philipp Babel, M.Sc. ist Compliance Spezialist / Berater und hat umfassende Erfahrung im Bereich Computer System Validierung & Digitale Medizinprodukte

Dipl.-Ing. (FH) Bernd Schleimer ist mit 20 Jahren Branchenerfahrung in der Medizintechnik als Senior Berater MedTec bei der GRÜNEWALD GmbH tätig.

Wir freuen uns auf Ihr Feedback zu diesem [wissenswert] Blogbeitrag.

GRÜNEWALD Beratungs- & Dienstleistungen zum Thema

Das GRÜNEWALD Team bietet umfassende Dienstleistungen zur Beratung und praktischen Arbeit in den Bereichen Lean Innovation & Requirements Engineering und der agilen Spezifikation, Entwicklung und Zulassung von MDR/IVDR/FDA Medizinprodukten.Eine Übersicht finden Sie unter auf der Seite Unterstützung Entwicklung Zulassung Medizinprodukte F&E auf unserer Homepage.)

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn