Sichere Medizinprodukte Schwachstellen aufdecken und Angriffe durch Software-Updates verhindern

Anbieter zum Thema

MicroConsult Academy GmbH

MES Electronic Connect GmbH & Co. KG

RECOM Power GmbH

Vernetzte Medizinprodukte müssen in jeder Phase des Design- und Entwicklungsprozesses sicher gegen Angriffe sein. Die Sicherheit muss auch im Falle eines Angriffs gewährleistet sein.

Hersteller von Medizinprodukten müssen immer schneller intelligent vernetzte Geräte entwickeln, die individuell anpassbar sind und die Produktsicherheit gewährleisten. Damit die Medizinprodukte die behördliche Zulassung erhalten, müssen sich die Gerätehersteller in jeder Phase des Design- und Entwicklungsprozesses auf Sicherheitsaspekte konzentrieren.

Dazu gehören Design, Entwicklung und Tests vor der Markteinführung bis zur Sicherheit eines Geräts während seiner gesamten Lebensdauer. Neue Schwachstellen und Angriffsmethoden werden in rasantem Tempo entdeckt. Die Möglichkeit, potenzielle Sicherheitsangriffe durch Software-Updates zu verhindern, muss bereits bei der Entwicklung berücksichtigt werden, damit das Gerät sicher bleibt.

Die Sicherheit von Medizinprodukten ist wichtig, um Kunden und Patienten, die mit diesen Produkten interagieren, zu versichern, dass ihre Gesundheit und ihre persönlichen Daten ernst genommen werden. Regulierungsbehörden auf der ganzen Welt verlangen und überprüfen zunehmend, dass Geräte vor und nach der Produktfreigabe so sicher wie möglich sind.

Sicherheitsschwachstellen und der CVE

Eine Sicherheitsschwachstelle ist ein Programmierfehler oder Bug genannt, der ein Gerät anfällig für eine Manipulation oder Störung durch eine unvorhergesehene externe oder interne Anwendung macht. Sicherheitsschwachstellen sind bei Medizinprodukten unvermeidlich. Indem sie diese Unvermeidbarkeit erkennen und sich darauf vorbereiten, können Entwickler von eingebetteten Systemen das Risiko und den potenziellen Schaden, den diese Schwachstellen verursachen können, begrenzen.

Das wichtigste Werkzeug im Prozess, um potenzielle Probleme zu erkennen und einzudämmen, ist ein Industriestandard namens „Common Vulnerabilities and Exposures“ (CVE). Ursprünglich 1999 definiert, sind CVE eine Sammlung bekannter Sicherheitslücken, die in Produkten oder in der Vergangenheit existierten. Die CVE werden gemeinsam von der MITRE Corporation und der US National Vulnerability Database (NVD), einer Datenbank des US Department of Homeland Security, veröffentlicht und gepflegt.

Ein CVE wird entweder im Nachhinein entdeckt, nachdem ein Schaden eingetreten ist, oder von einem gewissenhaften Techniker, der einen potenziellen Exploit entdeckt. Die meisten Exploits werden entdeckt, ohne Schaden anzurichten. Sobald ein Exploit durch den CVE-Prozess bekannt wird, kann er leicht von Hackern auf der ganzen Welt ausgenutzt werden. Der CVE-Prozess gibt den Produkt- oder Softwareentwicklern Zeit, die Schwachstelle zu beheben, bevor sie weltweit bekannt wird, so dass sie schnell handeln können, um die Schwachstelle zu beheben und die Sicherheit der Geräte zu gewährleisten.

Vulnerability Score und die Folgen für betroffene Geräte

Nach der Entdeckung wird jedem CVE eine Identifikationsnummer (ID) zugewiesen. Wenn ein CVE als Sicherheitsproblem eingestuft wird, weist die NVD dem CVE auch einen sogenannten Vulnerability Score zu. Das ist eine Zahl zwischen 1 und 10. Je höher die Zahl, desto schwerwiegender können die Folgen der Schwachstelle für die betroffenen Geräte sein. Das NVD enthält alle weiteren bekannten Informationen über das Problem sowie Links zu relevanten Websites, die das Sicherheitsproblem detaillierter beschreiben. Dazu gehört auch die Fehlerbehebung.

Der Hauptvorteil des CVE-Meldeverfahrens besteht darin, dass Sicherheitsproblem, die Möglichkeiten zur Behebung, der Schweregrad und das Risiko, das es für Ihre Produkte darstellen könnte, bekannt gemacht werden. Sicherheitsschwachstellen können verschiedene nachteilige Auswirkungen haben:

• Verlust oder Änderung kritischer Patientendaten, welche die Gesundheit des Patienten oder des medizinischen Personals gefährden könnten.

• Offenlegung von Kunden- oder Endbenutzerdaten, die zu Identitätsdiebstahl, HIPAA-Verletzungen und anderen schwerwiegenden Folgen führen könnte.

• Infiltration des Geräts durch böswillige Akteure, die zum Eindringen von Malware, zur Deaktivierung des Geräts oder zur Infizierung anderer Teile des Krankenhaus- oder Kliniknetzwerks mit Viren oder Malware führen könnte.

Sicherheitsprobleme und Produktentwicklung

Bei der Entwicklung von Geräten, die so sicher wie möglich sein müssen, ist es wichtig, die verschiedenen Quellen möglicher Sicherheitsprobleme zu berücksichtigen:

• Probleme, die der Entwicklungsgemeinschaft zum Zeitpunkt der Geräteentwicklung bekannt waren.

• Probleme, die nach der Produktfreigabe entdeckt werden.

• Probleme, die aufgrund unzureichender präventiver Entwicklungstechniken durch die speziell für das Gerät geschriebene Software verursacht werden.

Geräteschutz vor bekannten Sicherheitsproblemen

Viele potenzielle Schwachstellen (Exploits), die von Hackern genutzt werden, sind der weltweiten Sicherheitsgemeinschaft bereits bekannt und wurden behoben. Ein medizinisches Gerät kann immer noch über eine Schwachstelle ausgenutzt werden, die bereits behoben war, als das Gerät auf den Markt kam. Das zu verhindern ist mühsam, spart aber Zeit, schützt den Ruf des Herstellers und begrenzt die Kosten und die potenzielle rechtliche Haftung.

Die Regulierungsbehörden verlangen von den Geräteentwicklern, dass sie potenzielle Exploits prüfen, bevor sie das Gerät auf den Markt bringen. In den USA ist dieser Prozess Teil der „FDA Guidance on the Content of Premarket submissions for Management of Cybersecurity“.

Linux ist in vielen Medizinprodukten weit verbreitet. Für Open-Source-Komponenten in einem Medizinprodukt gibt esWerkzeugen, mit denen sich feststellen lässt, ob die Software wichtige CVEs enthält. Ein wichtiges Werkzeug heißt „Cve-Check“. Es erstellt Berichte über Pakete, welche CVEs enthalten, die in den verwendeten Versionen nicht behoben sind, indem es eine Versionsprüfung ausführt. Damit soll festgestellt werden, ob vor der Fertigstellung des Produkts vorbeugende Maßnahmen erforderlich sind.

Oft ziehen es Gerätehersteller vor, ihre Entwickler die Produktprobleme lösen zu lassen, anstatt eine Linux-Distribution zu verwalten und zu pflegen. Die enormen Möglichkeiten, die Stabilität und die Gemeinschaft, die Open-Source-Software bietet, haben jedoch ihren Preis. Entweder muss der Gerätehersteller das selbst übernehmen oder eine kommerzielle Linux-Distribution einsetzen und seinen Lieferanten dafür verantwortlich machen. In dieser Phase geht es nicht nur darum, bekannte Schwachstellen zu überwachen und zu beseitigen.

Die folgenden Probleme können zu einer Schwachstelle führen.

• Zugriffskontrolle: Ist es möglich, Rollen für den Zugriff auf verschiedene Arten von Daten zu definieren (Benutzerebene, Managementebene oder Wartungsebene) und sicherzustellen, dass nur autorisierte Rollen Zugriff auf die Daten haben? Ist der Datenzugriff über das Internet für höhere Benutzerebenen im Vergleich zum physischen Zugriff auf das Gerät erschwert? Ist es schwierig, die Authentifizierungsmethoden des Geräts für Exploits auszunutzen? Werden Standardkonten und -passwörter so verwaltet, dass sie im Feld nicht für Exploits verwendet werden können? Linux bietet mindestens zwei verschiedene Methoden zur Verwaltung der Zugriffskontrolle: Discretionary (DAC), das Standard-Linux-Modell für die Zugriffskontrolle, und Mandatory (MAC), das komplexer und sicherer ist und Teil des SELinux-Pakets ist.

• Verschlüsselung: Sind die auf dem Gerät gespeicherten Daten sowohl im Speicher als auch auf der Festplatte und die zwischen den Geräten übertragenen Daten geschützt und verschlüsselt, so dass sie nur von denjenigen entschlüsselt werden können, für die sie bestimmt sind? Viele potentielle Exploits, die Außenstehenden Einblick in die Daten geben würden, benötigen immer noch den richtigen Schlüssel, um die Daten entschlüsseln zu können. Entwickler müssen sicherstellen, dass ein anderer Mechanismus als der einfache Zugriff auf einen verschlüsselten Speicher überwunden werden muss, um Zugang zu den Schlüsseln zu erhalten.

• Hardwarebasierte Sicherheitsunterstützung: Viele Funktionen moderner Prozessoren tragen zur Sicherheit von Geräten und Anwendungen bei. Es liegt jedoch in der Verantwortung des Systemdesigners, sie zu nutzen. Moderne Mikroprozessoren bieten Funktionen wie TrustZone, Cryptographic Acceleration oder Trusted Platform Modules (TPMs), die die Entwicklung sicherer Designs beschleunigen und unterstützen.

Zukunftssichere medizinische Geräte entwickeln

Die Arbeit am Produkt ist nach der Veröffentlichung noch nicht abgeschlossen. Die Anzahl der bekannten Sicherheitslücken schwankt und nimmt täglich zu. In der Regel stellen sie kein Problem dar, da viele CVE gegen ältere Versionen von Open-Source-Komponenten oder gegen Komponenten, die nicht verwendet werden, gemeldet werden. Auch wenn es keine Möglichkeit gibt, das zu verhindern, müssen sich Entwickler darüber im Klaren sein, dass das passieren wird. Die Zeit, in der ein Produkt sicher gemacht werden kann, ist die Entwicklungsphase, in der es aktualisiert wird, sobald neue Exploits (und schwerwiegende Produktfehler) entdeckt und behoben werden.

Die Aufsichtsbehörden nehmen in dieser Hinsicht eine wesentlich strengere Haltung ein und verlangen, dass Pläne für das Management dieses Problems Teil der Pläne für die Zeit nach dem Inverkehrbringen des Produkts sind in den USA gemäß den Richtlinien für das Management der Cybersicherheit nach dem Inverkehrbringen für Medizinprodukte.

Im Jahr 2016 legte ein als Mirai-Botnet bekannter Exploit große Teile des Internets lahm, indem er kleine IoT-Geräte wie Webcams und Router kaperte und sie für Distributed-Denial-of-Service- (DDoS-)Angriffe gegen US-amerikanische und französische Anbieter von Webinfrastrukturen missbrauchte. Die meisten Besitzer dieser infizierten Geräte wussten nicht, dass ihre Systeme infiziert waren. Mirai und seine Derivate stellen bis heute eine Bedrohung dar. Die meisten Nutzer der betroffenen Geräte kannten die Standardeinstellungen nicht oder wussten nicht, wie sie diese einfach ändern konnten, so dass das Mirai-Botnet leichtes Spiel hatte, die Kontrolle über diese Geräte zu übernehmen.

Mögliche Schwachstellen beim Einsatz von Linux

Wenn Linux und andere Open-Source-Software für einen Teil des Produktdesigns verwendet werden, gibt es Schwachstellen im Gerät, wenn es auf den Markt kommt. Die Entwickler müssen davon ausgehen, dass ein böswilliger Akteur unbefugten Zugriff auf das Gerät erlangen könnte. Wenn dies geschieht, muss es ihm so schwer wie möglich gemacht werden, diesen Zugang gewinnbringend auszunutzen. Es gibt keinen perfekten Schutz gegen bestimmte Hacker, die mit dem Wissen über Exploits im Gerät ausgestattet sind. Entwickler können Schwachstellen in Open-Source-Modulen nicht vermeiden, aber Nutzer können potenzielle Schwachstellen in ihren eigenen Anwendungen kontrollieren. Sie sollten darauf achten, wie die Anwendungen auf dem Gerät entwickelt werden.

Die meisten Exploits in Open-Source- und Anwendungssoftware sind auf Entwicklungsfehler zurückzuführen, die wiederholt auftreten. Dereferenzierte Null-Zeiger, das Freigeben bereits freigegebener Speicherbereiche oder Überläufe bei Puffern fester Länge sind nur einige Beispiele für Programmierfehler, die von Angreifern leicht ausgenutzt werden können, um Geräte zu kompromittieren. Es gibt jedoch mehrere Ansätze, die verwendet werden können:

• Statische (und dynamische) Analyse: Die erste statische Analyse wird wahrscheinlich vom Compiler als Warnung angezeigt. Viele Unternehmen übersehen das Diagnosewerkzeug. Darüber hinaus bietet die Open-Source-Community mehrere nützliche statische Analysewerkzeuge wie cppcheck und clang, für die es viele kommerzielle Lösungen gibt. Alle Werkzeuge decken Probleme auf, die bei der Überprüfung des Programmcodes leicht übersehen werden. Solange die Berichte der Werkzeuge verwaltet werden, können Entwickler mehrere schwerwiegende Klassen potenzieller Exploits in ihren Anwendungen verhindern.

• Einen Programmierstandard verwenden: Im Allgemeinen ist der MISRA-Programmierstandard der Goldstandard und bietet durchdachte Empfehlungen zur Sicherung von Geräteanwendungen. Obwohl MISRA aus der Automobil- und Sicherheitsbranche stammt, sollte es von jedem Gerätehersteller in Betracht gezogen werden, der seine Anwendungen absichern möchte. Die meisten statischen Analysewerkzeuge erleichtern den Testvon Anwendungen anhand der MISRA-Regeln erheblich. Obwohl es auch andere Programmierstandards gibt, stellt MISRA eine so gute Kombination aus nützlichen Erkenntnissen und bewährten Verfahren dar, dass es von Unternehmen jeder Größe implementiert werden kann.

• Ein weiterer Programmierstandard stammt vom Software Engineering Institute in Carnegie Mellon und heißt SEI CERT C. Zwischen diesem Standard und MISRA gibt es erhebliche Überschneidungen. Die SEI-Standards gehen über C und C++ hinaus und umfassen auch Android, Java und Perl.

Es gibt keine völlig fehlerfreien Produkte

Die Kunden wissen, dass es keine völlig fehlerfreien Geräte gibt. Sie wollen wissen, wie der Hersteller Fehler und ihre Auswirkungen minimiert und wie er reagiert, wenn etwas unvermeidlich schief geht. Die beschriebenen Methoden werden nicht alle potenziellen zukünftigen Sicherheitsprobleme verhindern, aber sie versetzen die Geräteentwickler in eine gute Position, um auftretende Probleme schnell zu lösen.

Durch die Verbesserung der Sicherheit und die Begrenzung der Exposition der Geräte gegenüber Exploit-Versuchen können die Anwender die Anfälligkeit der Geräte gegenüber Angriffen verringern, sich besser auf den Schutz von Patientendaten einstellen, mit größerer Wahrscheinlichkeit problemlos behördliche Genehmigungen erhalten und die Behandlungsergebnisse für Patienten auf der ganzen Welt verbessern.

* Robert Bates ist Chief Safety Officer der Embedded Platform Systems Group bei Siemens Digital Industries Software und verantwortlich für die Sicherheits-, Qualitäts- und Schutzaspekte des Embedded-Produktportfolios für die Märkte Medizin, Industrie, Automobil und Luft- und Raumfahrt.

(ID:49451684)