Startseite > Medizintechnik > E-Health > Cybersecurity: Immun gegen Angriffe auf Medizingeräte

Per Tool-Kombi gegen Sicherheitslücken

Cybersecurity: Immun gegen Angriffe auf Medizingeräte

17. April 2025, 14:38 Uhr | Von Royd Lüdtke und Artur Hirsch, Verifysoft

Vernetzte Healthcare-Systeme sind auch bei Hackern ein Angriffsziel - und müssen mit Hinblick auf die Geräte- und Patientensicherheit gut geschützt sein.

Ob gezielter Anschlag oder großangelegter Cyberangriff – vernetzte Medizingeräte müssen gegen vielfältige Angriffsarten geschützt sein. Welche Normen und Richtlinien geben Orientierung in der Entwicklung? Handreichung zu Analysemethoden, statischen und dynamischen Testing sowie dessen Kombination.

▶ Diesen Artikel anhören

Ohne Mikrocontroller und Softwaresteuerung kommt kein modernes, digitalisiertes Medizingerät aus. Je nach genauem medizinischen Einsatz und Kritikalität sind die Anforderungen an die Softwarequalität durchaus unterschiedlich, prinzipiell wird nach funktionaler Sicherheit (Safety) sowie der Sicherheit gegenüber Angriffen von außen (Security) beurteilt.

Die Bedeutung der funktionalen Sicherheit für in der Medizin eingesetzte Geräte ist klar. Seit der Vernetzung rückt jedoch der Bedarf an Sicherheit gegen Angriffe mehr in den Fokus. Heute kommunizieren medizinische Geräte über das Internet mit Ärzten, untereinander und auch mit anderen Institutionen. Dieses »Internet of Medical Things« (IoMT) eröffnet große Chancen, birgt aber auch große Risiken, denen Softwarehersteller durch umfangreiche Test- und Analysemethoden begegnen müssen.

Vorteile und Chancen vernetzter Medizingeräte

Ob vernetztes Ultraschallgerät, Herzschrittmacher oder Infusionspumpen – netzfähige Medizingeräte können Kosten senken sowie Lebensqualität und Überlebenschancen von Patienten drastisch erhöhen. Sie ermöglichen es Ärzten etwa, die Vitalfunktionen ihrer Patienten remote zu überwachen und Medikamentendosierungen durch Fernsteuerung anzupassen. Die Möglichkeit der Überwachung von Patienten rund um die Uhr, verbunden mit im Notfall automatisch ausgelösten Alarm- und Standortmeldungen, verkürzt überlebenswichtige Reaktionszeiten signifikant. Direkt miteinander kommunizierende Geräte können in medizinisch vertretbaren Umfang auch selbständig agieren. Wird z. B. durch eine kontinuierliche Blutzuckermessung eine drohende Unterzuckerung erkannt, so kann unverzüglich eine Meldung an eine Infusionspumpe erfolgen, die eine Glukosemenge injiziert.

Lebens- oder gesundheitsgefährdende Situationen durch Ausfall oder Fehlfunktion von medizinischen Geräten sind glücklicherweise selten, vereinzelt aber dennoch zu verzeichnen. Softwaregesteuerte Geräte sind heute vielfach in der Lage, Selbstdiagnosen durchzuführen und – sofern netzgebunden – Fehlfunktionen zu melden. Damit wird die Ausfallsicherheit erheblich verbessert.

Risiken vernetzter Medizingeräte

Matchmaker+ Anbieter zum Thema

zu Matchmaker+

Mit der Gerätevernetzung wird jede individuelle Sicherheitslücke eines Geräts gefährlicher. Netzwerkschnittstellen sind aus Entwicklersicht immer als potenzielle Einfallstore für Angriffe von außen zu betrachten (Bild 1) – Angreifer könnten unter Ausnutzung von Sicherheitsschwachstellen die Kontrolle über ein Medizingerät erlangen – mit weitreichenden Folgen. Medizinische Geräte wurden mittelbar bereits genutzt, um in Infrastrukturen von Krankenhäusern und Gesundheitszentren einzubrechen. Bekannt geworden sind diese Einbrüche unter dem Namen »MEDJACK« (Medical Device Hijack). Ausgenutzt wurden etwa veraltete Betriebssysteme oder unsichere Programmfunktionen.

Ob persönliche kriminelle Motive oder typische Cyberverbrechen wie Ransomware-Attacken bis hin zu möglichen Terrorakten durch Manipulation vernetzter, lebenserhaltender Geräte – über MEDJACKs lassen sich hohe Sach- und Personenschäden anrichten. So können Patienten- und Personaldaten abgegriffen, weitere Geräte infiziert oder wichtige Daten böswillig verändert oder verschlüsselt werden.

Wie werden solche Angriffe in der Regel durchgeführt?

Es gibt viele Einfallstore, die ein Angreifer auszunutzen kann – oft kombinieren Angreifer mehrere Methoden. Ein Angreifer kann in einem Netzwerk als »Man-in-the-Middle« agieren, um den Datenverkehr auszuspähen. Durch Extrahieren von Zugangsdaten und die Suche nach Schwachstellen ist es möglich, Schadcode zu injizieren. Die Ausprägungen reichen vom Zugriff aus der Distanz über Keylogger bis hin zum Sperren/Verschlüsseln von Daten oder ganzen Geräten, um diese gegen Zahlung hoher Geldbeträge wieder freizugeben – so geschehen bei zahlreichen Ransomware-Angriffen auf Einrichtungen des Gesundheitswesens.

Denial-of-service-Attacken hingegen setzen auf das Überfluten eines Datenempfängers mit einer sehr großen Menge an Datenpaketen. Dies führt zu einer eingeschränkten oder auch komplett verhinderten Funktion des Angegriffenen. Aber auch die Software der einzelnen Medizingeräte selbst (z. B. Firmware) kann als Sprungbrett für Angriffe genutzt werden. Diese Software besteht oft aus einem Eigenentwicklungsanteil und extern entwickelten Komponenten. Um Sicherheit gegenüber Angriffen von außen zu gewährleisten, müssen Entwickler sowohl selbst erstellten Code als auch externe Softwarekomponenten auf Sicherheitslücken hin überprüfen.

Normen und Richtlinien für Softwarehersteller

Zur Vermarktung von Medizinprodukten in Europa ist die Medizinprodukteverordnung (MDR) bindend. Diese schreibt eine Risikomanagement- und Risiko-Nutzen-Analyse vor. Einen Leitfaden zum Risikomanagementprozess hinsichtlich der funktionalen Sicherheit eines Produkts bietet die ISO 14971. Nicht bindend, aber sehr hilfreich ist die AAMI TIR57 als Erweiterung der ISO 14971, um den Risikomanagementprozess auf Cybersecurity auszuweiten.

Grundsätzlich sind für den Prozess von der Produktidee bis zur Marktherausnahme die von der EU-Kommission veröffentlichten Normen IEC 62304, IEC 82304-1 und IEC 60601-1 anzuwenden. Für Medizinprodukte, die in Netzwerken betrieben werden, ist zudem die Norm IEC 80001-1 relevant. Zu erwähnen ist auch die Richtlinie (EU) 2022/2555 des Europäischen Parlaments und des Rates vom 14. Dezember 2022 über Maßnahmen für ein hohes gemeinsames Cybersicherheitsniveau in der Union.

Statische Analyse und dynamisches Testen

Zur Gewährleistung der Softwarequalität kommen während des Softwareentwicklungsprozesses grundsätzlich zwei komplementäre Test- und Analyseverfahren zur Anwendung: Die statische Codeanalyse und das dynamische Testen.

Die statische Analyse untersucht Quellcode- und Binärdateien im Hinblick auf enthaltene kritische Fehler und Sicherheitsschwachstellen, ohne den Code ausführen zu müssen.
Die dynamische Analyse beurteilt durch Ausführen von Tests dagegen das Laufzeitverhalten der Applikation oder des Moduls. Aufgedeckt wird überwiegend funktionales Fehlverhalten, das aber durchaus auch Sicherheitsschwachstellen bedingen kann. Zum Ausführen von Tests muss bereits funktionsfähiger Programmcode vorhanden sein. Die statische Analyse hingegen ist bereits früher – begleitend zur Implementierung – einsetzbar.

Im Entwicklungszyklus wird die statische Security Analyse (SAST) je nach Entwicklungstand auch bereits auf noch nicht lauffähige Applikationsteile (z. B. Funktionen) angewandt (Bild 2). In dieser Phase lassen sich nach Analyse mit Tools wie CodeSonar notwendige Korrekturen im Quellcode frühzeitig und damit noch kostengünstig umsetzen.

Tools für die statische Analyse

Zur statischen Analyse stehen verschiedene Werkzeuge zur Verfügung (Bild 3): Einige Tools scannen den Quellcode und sind spezialisiert darauf, Schwachstellen wie Speicherüber- und -unterläufe, Format-String-Probleme, hart codierte Passwörter, geringe Verschlüsselungstiefen und eingebaute Hintertüren (Backdoors) aufzudecken. Andere Werkzeuge konzentrieren sich auf die Analyse von Binärdateien wie Bibliotheken und deren Abhängigkeiten zu eventuell weiteren eingebundenen Komponenten, um potenzielle Sicherheitslücken zu identifizieren. Insbesondere wird dabei auch nach Code-Konstrukten gesucht, die aktuell zu bekannten Sicherheitsschwachstellen geführt haben. Durch die Kombination dieser Vorgehensweisen lassen sich viele potenziell kritische Sicherheitslücken im Quellcode beheben, bevor die Software in Betrieb genommen wird.

Bei eigenentwickeltem Code empfiehlt sich die oben beschriebene Quellcodeanalyse. Das gleiche gilt für eingebundene Open-Source-Komponenten, für die der Quellcode im Zugriff steht. Man spricht hier von »0-Day-Analyse«, da damit noch unbekannte Sicherheitsschwachstellen aufgedeckt werden können. Im Hinblick auf die Open Source-Komponenten bietet sich zudem eine Überprüfung auf bekannte Sicherheitsprobleme (N-Day-Ermittlung) mittels Recherche in einschlägigen Vulnerability-Datenbanken an. Entwickler erhalten so Informationen über die Kritikalität von enthaltenen Sicherheitsschwachstellen sowie eventuell bereits vorhandene Korrekturen.

Kommerzielle Komponenten liegen zumeist nur als Binärdateien vor. Hier empfiehlt sich zunächst eine statische 0-Day-Binärcodeanalyse. Die sicherlich notwendige N-Day-Ermittlung hinsichtlich in der Binärdatei eventuell enthaltener Open Source-Komponenten ist allerdings erst durchführbar, wenn diese identifiziert sind. Das leistet die Software Composition Analysis (SCA): Dabei werden beispielsweise Zeichenketten gesucht, die auf verwendete Open-Source-Komponenten hinweisen. Analysetools wie CodeSentry ermöglichen zudem auch ohne Zugriff auf den Quellcode skalierbare Analysen. Anschließend können die Datenbanken auf bereits bekannte Schwachstellen abgefragt werden.

Grundsätzlich sollte Software, die in vernetzten Geräten zum Einsatz kommt, einer statischen »Taint Data Analyse« – einem virtuellen Penetrationstest – unterzogen werden. Man untersucht dabei, wie eingespeister Schadcode in der Applikation weitergeleitet würde und welche Funktionen davon betroffen wären. Dadurch lassen sich bereits im Vorfeld Gegenmaßnahmen treffen.

Zum Abschluss, wenn die vollständige Applikation gebaut worden ist, sollte noch eine Sicherheitsattributsanalyse durchgeführt werden. Hierbei wird überprüft, ob z. B. von der Möglichkeit, den Compiler zusätzliche Sicherheitsmechanismen in den Binärcode einbauen zu lassen, Gebrauch gemacht wurde.

Ein Muss: Die Test-Kombination

Die dynamische Analyse ist ein zur statischen Analyse komplementäres und unverzichtbares Verfahren, um die Zuverlässigkeit von Software sicherzustellen. Das dynamische Testen kann allerdings erst dann erfolgen, wenn ablauffähige Teile der Applikation (z. B. Module) vorliegen.

Im Rahmen dieser Tests wird die einwandfreie Funktionalität inklusive der für die Security relevanten Komponenten überprüft. Ein Werkzeug zur Messung der Testabdeckung stellt sicher, dass keine Tests ausgelassen wurden. Unter Einhaltung der beschriebenen Prozesse und Vorgaben zu Planung, Design, Entwicklung und Analyse von Software zum Einsatz in Medizingeräten kann ein hohes Maß an Sicherheit gewährleistet werden. (uh)