IoT & eHealth Das Risiko von Open Source im IoMT
Anbieter zum Thema
Mit dem Internet of Medical Things (IoMT) steht dem Gesundheitswesen ein grundlegender Wandel bevor. Unternehmen können hier unter Einsatz von Open Source innovative Lösungen schneller entwickeln und auf den Markt bringen, solange sie dabei Sicherheits- und Compliance-Risiken berücksichtigen.

Der zunehmende Einsatz von Software macht Medizinprodukte smart – von Fitness-Wearables und Apps über Herzschrittmacher oder Neuroprothesen bis hin zu In-Home Monitoring-Systemen. Das Internet of Medical Things (IoMT) verspricht vor allem aber auch eine enorme Entlastung des Gesundheitswesens, dessen Kosten von Jahr zu Jahr steigen. Ein Grund dafür ist die wachsende Bevölkerung, die zudem immer älter wird und unter mehreren alterstypischen Begleiterkrankungen leidet. Der Anteil der über 65-Jährigen soll sich bis 2050 verdoppeln, die weltweiten Gesundheitsausgaben bis 2020 allein auf insgesamt 8,7 Billionen US-Dollar steigen. Ohne einen radikalen Wandel und den breiten Einsatz von innovativen Technologien wird die Gesundheitsversorgung in vielen Ländern nicht mehr finanzierbar sein.
Die Medizintechnik übernimmt hier eine wesentliche Rolle, um Kosten zu senken und die Versorgung sicherzustellen. Neue Technologien in Form von Embedded Software und die Nutzung von Daten im Kontext von KI und Machine Learning gelten als Schlüssel der digitalen Transformation im Medizin- und Healthcare-Sektor. IoMT-Systeme und -Software ermöglichen es, Geräte dort bereitzustellen, wo sie gebraucht werden, Kosten zu managen und zu reduzieren und basierend auf Datenerfassung und -analyse eine bessere und schnellere Behandlung anzubieten. Während also beispielsweise die Krankenhaus-IT reibungsloser und effektiver arbeitet, können Ärzte und Pfleger unmittelbar auf Patientendaten zugreifen und sich auf intelligente technische Helfer verlassen. Auch der wachsende Trend zur Telegesundheit („Telehealth“) verspricht Kosten zu reduzieren und den Patientenkomfort zu verbessern. Das reicht von Patientenportalen und der interaktiven Kommunikation mit Ärzten bis zu Remote-Monitoringsystemen in den eigenen vier Wänden. So ist es nicht überraschend, dass der Markt für softwaregetriebene medizinische Geräte bis 2022 auf 48,3 Milliarden US-Dollar steigen wird.
Sicherheit und Compliance bereiten Kopfschmerzen
Das Potenzial ist riesig. Für Softwareanbieter und Hersteller gibt es jedoch auch neue Herausforderungen zu berücksichtigten, wie beispielsweise die Einhaltung von Lizenzvorgaben. Das gilt insbesondere für das Internet of Things (IoT), wo Geräte häufig mit eingebetteten Betriebssystemen und Softwarekomponenten bereitgestellt werden. In vielen Fällen sind diese Betriebssysteme Open Source und unterliegen der General Public License (GPL). Danach sind Entwicklerteams bei der Nutzung verpflichtet, den Quellcode aller Produkte und Komponenten, in denen sie GPL-lizenzierte Komponenten verwenden, ebenfalls offenzulegen. In der innovationsgetriebenen IoMT-Branche ist der transparente, regelgerechte Umgang mit dem Quellcode jedoch eher die Ausnahme. Vielmehr setzen Unternehmen alles daran, ihr geistiges Eigentum (Intellectual Property) zu schützen, um wettbewerbsfähig bleiben zu können.
Eine zentrale Frage ist auch die Sicherheit von vernetzten und softwaregesteuerten Medizinprodukten. Grundsätzlich sind Hersteller dazu verpflichtet, Zuverlässigkeit und Sicherheit über den gesamten Lebenszyklus von Medizinprodukten zu gewährleisten – in jeder Phase und für jede Komponente des Geräts. Das beginnt beim Gehäuse, geht über die mechanischen Teile und die Elektronik bis hin zur Embedded Software und dem zugrunde liegenden Programmiercode. Mit dem IoMT wird automatisch auch Cybersicherheit zum Thema. Wie Computer und Netzwerke ist auch die in den Geräten integrierte Software angreifbar und kann über Schwachstellen im Code ausgenutzt und manipuliert werden. Um solche Sicherheitslücken managen und beheben zu können, braucht es eine umfassende Sicherheitsstrategie.
Das Software-Management beginnt, ehe das medizinische Gerät in der Praxis eingesetzt wird. Potenzielle Risiken hinsichtlich der Cybersicherheit und der Compliance müssen schon im Produktdesign berücksichtigt werden. Dazu gehören beispielsweise Funktionen für das zeitnahe Bereitstellen und Implementieren von Sicherheits-Patches und Updates. Ist ein Gerät einmal auf dem Markt, ist es an den Herstellern, die intelligenten und vernetzten Geräte proaktiv zu überwachen und zu warten sowie bekannt gewordene Schwachstellen schnellstmöglich zu schließen.
:quality(80)/images.vogel.de/vogelonline/bdb/1644600/1644606/original.jpg)
Sensorik
Sensoren helfen bei der Beatmung von Intensivpatienten
Open Source: Unwissenheit schützt nicht vor Schaden
Insbesondere Open Source Software (OSS) wird hier unterschätzt. Dabei hat die Popularität von OSS mit dem rasanten Wachstum des IoT einen Höhepunkt erreicht. Mit steigender Komplexität der Softwareprodukte, wächst auch die Menge an Code. Die Mehrheit der Entwicklungsteams greift daher bei der Entwicklung von Software auf OS-Komponenten zurück, um nicht nur schneller, sondern auch effektiver arbeiten zu können. Mehr als 50 Prozent des Codes in den meisten kommerziellen Softwarepaketen ist Open Source. Die freie Verwendung von OSS hat jedoch einen Haken: Wird die Nutzung von OSS-Code nicht genau dokumentiert und verwaltet, lässt sich zu einem späteren Zeitpunkt nur schwer zurückverfolgen, wo und wie dieser Code eingesetzt wurde und ob dieser alle Lizenzvorgaben erfüllt. Das kann nicht nur bei neu auftretenden Schwachstellen schwerwiegende Konsequenzen haben, sondern auch Probleme mit der Compliance nach sich führen.
Ein Fall, der wie kein anderer in den letzten Jahren das Risiko von OSS verdeutlicht, ist die CVE-2017-5638 Schwachstelle in Apache Struts 2. Das Open Source Framework wird für viele gängige Webanwendungen in Unternehmen und Regierungsbehörden aber auch im Finanz- und Gesundheitssektor genutzt. Obwohl ein Patch für die Schwachstelle bereitstand, versäumte es der US-amerikanische Finanzdienstleister Equifax die Sicherheitslücke rechtzeitig zu schließen. Die Folge: Über ein Exploit konnten Hacker in das System eindringen und Daten von schätzungsweise 143 Millionen Menschen erbeuten.
Eine Schwachstelle wie Apache Struts lässt sich nicht verhindern. Unternehmen können jedoch Richtlinien zum Umgang mit ihnen festlegen und Versionsupdates, Fehlerberichte und Patches in ihre Sicherheitsprozesse integrieren. Vorausgesetzt, sie wissen, ob sie von einer Schwachstelle tatsächlich betroffen sind und in welchen Geräten sich diese befindet. Durchschnittlich stoßen die Analysten von Flexera bei Audits von 32.600 Codezeilen auf eine Schwachstelle, ein Compliance-Risiko oder Ähnliches (s. Grafik). Diese Trefferquote erscheint zwar auf den ersten Blick relativ klein. Berücksichtigt man jedoch die tatsächliche enorme Anzahl an Code, aus denen sich Hightech-Medizinprodukte zusammensetzen, verändert sich die Lage schnell.
Zudem geht es nicht nur darum, den eigenen, intern entwickelten Code zu kennen, sondern auch zu wissen, was über externe Partner und Drittanbieter hinzufügt wurde. Open-Source-Code stammt in den meisten Fällen aus unterschiedlichen Quellen wie Containern, Build-Dependencies oder Binärdateien. Daher gilt es, die gesamte Software Supply Chain im Auge zu behalten. Ansonsten sehen sich Hersteller sehr schnell einer Reihe weiterer Herausforderungen wie Verletzungen der IP-Konformität, Probleme bei der Exportkontrolle, Korrektur/Reparatur und unkontrollierter Versionsverbreitung gegenüber.
:quality(80)/images.vogel.de/vogelonline/bdb/1622000/1622002/original.jpg)
Fakten
IoT-Statistiken des Gesundheitswesens
Software Bill of Material
Um versteckte Compliance- und Sicherheitsrisiken im Quellcode von Geräten nicht zu übersehen, benötigen Unternehmen Lösungen, die Open Source automatisiert scannen und Sicherheitslücken identifizieren. Je sicherheitskritischer die Anwendung und je niedriger die Fehlertoleranz, desto tiefer und gründlicher die Analyse von OSS. Zwangsläufig ist Open-Source-Risikomanagement ein iterativer Prozess, der sich über den ganzen Produktlebenszyklus zieht. Zu diesem Schluss kam auch die FDA (The Food and Drug Administration). In einem Bericht kündigte die US-amerikanische Behörde an, prüfen zu wollen, ob Unternehmen zur Erstellung einer „Software Bill of Materials“ (BOM) verpflichtet werden sollen. Das ausführliche Verzeichnis aller verwendeten Komponenten einer Software könnte der FDA dann im Rahmen einer Pre-Market-Submission zur Verfügung gestellt werden. Aber auch Kunden und Endanwender könnten mit der Liste die Software in ihren vernetzten Assets besser verwalten, überwachen und schützen.
Die Software-BOM ist nur ein Bestandteil einer umfassenden Software Composition Analysis (SCA), die eine grundlegende automatisierte Transparenz von OSS in Geräten sicherstellt. Dieser Ansatz ermöglicht es Entwickler- und Sicherheitsteams, OS-Komponenten zu identifizieren und zurückzuverfolgen, Richtlinien festzulegen und durchzusetzen, Software in Systemen proaktiv und kontinuierlich zu überwachen und OSS-Scanning nahtlos in den Built-Prozess von Anwendungen zu integrieren.
Hersteller, die diese Schritte beherzigen, können zuversichtlich in Richtung IoMT aufbrechen und bei der Entwicklung smarter und vernetzter medizinischer Geräte die Vorteile von Open Source in vollem Umfang nutzen – ohne Anwender und Patienten einem unnötigen Sicherheitsrisiko auszusetzen und gegen Compliance-Vorgaben zu verstoßen.
:quality(80)/images.vogel.de/vogelonline/bdb/1502200/1502259/original.jpg)
Security
E-Health: Patienten sorgen sich um Datensicherheit
Dieser Beitrag ist ursprünglich auf unserem Partnerportal BigData-Insider erschienen.
(ID:46415418)