Wenn die Software entscheidet Medizinische Geräte gefahrlos im Internet der Dinge

Autor / Redakteur: Sebastian Seifert und Lars Hemmann * / Ira Zahorsky

Gesundheitsdaten und medizinische Geräte bedürfen eines besonderen Schutzes im Internet der Dinge. Die Qualität der Software spielt dabei eine entscheidende Rolle.

Firmen zum Thema

Vernetzte Medizingeräte: Mit der richtigen Software lassen sich Gesundheitsdaten und medizinische Geräte vor einen Angriff schützen.
Vernetzte Medizingeräte: Mit der richtigen Software lassen sich Gesundheitsdaten und medizinische Geräte vor einen Angriff schützen.
(Bild: Method Park)

Der feindliche Agent sitzt im Café nahe der Botschaft, neben dem Cappuccino steht sein Laptop. Eine schwarze Limousine verlässt das Botschaftstor Richtung Flughafen, an Bord: ein ausreisewilliger Dissident. Der Agent scheint zu arbeiten, während die Limousine vorbeirollt.

Eine halbe Stunde später muss der Wagen stoppen, ein Rettungswagen übernimmt den ins Koma gefallenen Passagier. Die Diagnose: eine lebensgefährliche Unterzuckerung des an Diabetes leidenden Funktionärs. Die Flucht ist gescheitert.

Bildergalerie

Der Datenschutz spielt eine wichtige Rolle

Wie könnte unser Agentenkrimi das Rätsel dieses Attentats auflösen? Vielleicht ist eine portable Insulinpumpe (Bild 1) im Spiel, und der Angreifer hat per Funk eine Fehldosierung ausgelöst. Wer meint, die Story sei spannend, aber weit hergeholt, irrt sich. Schon 2011 hat der Security Researcher Jay Radcliffe realistische, funkbasierte Angriffsszenarien auf bestimmte Insulinpumpen öffentlich gemacht [2].

Ähnliche, das Herstelleransehen schädigende Vorfälle bei der Datensicherheit und Verlässlichkeit von Medizingeräten häufen sich. Kein Wunder: Wir erleben unter dem Schlagwort Internet of Things eine Explosion von neuen Produkten, die durch Sammlung und Verwertung von Daten sowie durch Vernetzung und Austausch dieser Daten Mehrwert schaffen. Damit werden aber auch Themen wie Datenschutz, Datensicherheit und die Entwicklung komplexerer Software in Bereichen hochaktuell, in denen sie bisher vielleicht von geringerer Bedeutung waren. Das fehlende Know-how muss schnell aufgebaut werden.

Beginnen wir bei den gesammelten Informationen. Alle gesundheitsbezogenen Daten sind generell Teil der persönlichen Sphäre und unterliegen der Datenschutz-Gesetzgebung. Hinzu kommen spezielle Rechtsvorschriften im Gesundheitsbereich, wie etwa die ärztliche Schweigepflicht. Selbst in den ansonsten nicht besonders datenschutzfreudigen USA sind Gesundheitsdaten durch scharfe Regelungen abgesichert.

Ergänzendes zum Thema
Umfassendes Wissen bei vernetzten Geräten

Wer medizinische Produkte auf den europäischen oder US-Markt bringt, muss die entsprechenden Richtlinien kennen. Auch vernetzte Geräte im medizinischen Umfeld, die ihre Daten untereinander sicher austauschen, machen keine Ausnahme. Im IoT brauchen Unternehmen allerdings zusätzlich einen Software-Entwicklungsprozess. Hier ist der Aufbau von Know-how gefragt. Schulungen spielen dabei ebenso eine wichtige Rolle wie auch eine externe Beratung oder das Auslagern bestimmter Software-Teilprojekte an einen Dienstleister.

Das Datenschutzrecht stellt einige typische Anforderungen. In Deutschland gelten etwa die Prinzipien der Erforderlichkeit, der Datensparsamkeit und der Datenvermeidung. Nur die für den Anwendungszweck notwendigen Daten sollen erhoben werden. Die gesammelten Daten sind konsequenterweise zweckgebunden; nicht mehr notwendige Daten sind zu löschen. Die Erhebung der Daten bedarf einer rechtlichen Grundlage, typischerweise der Einwilligung des Betroffenen. Diese sollte dokumentiert werden.

Werden die Daten gespeichert und übertragen, dann muss die Vertraulichkeit der Daten sichergestellt sein. Das kann etwa durch sichere Verschlüsselungsverfahren erfolgen. Der Zugang zu den Daten soll auf die notwendigen Nutzerkreise beschränkt sein; Abruf und Nutzung der Daten müssen gegebenenfalls nachvollziehbar sein, etwa durch Protokollierung.

Erschwert wird die korrekte Umsetzung der Vorschriften, wenn ein Produkt international vertrieben wird. Einerseits gelten in den verschiedenen Ländern natürlich unterschiedliche Bestimmungen. Andererseits kommunizieren in vielen IoT-Szenarien die Geräte mit einem zentralen Dienst, der beispielsweise vom Hersteller betrieben wird und die gesammelten Daten speichert und aufbereitet. Der Datenaustausch zwischen verschiedenen Rechtssystemen ist aber problematisch. Gegebenenfalls muss der zentrale Dienst in separierten, lokalen Ausprägungen realisiert werden.

Die personenbezogenen Daten sichern

Schon wegen des Datenschutzes gilt es, sich Gedanken über Zugangs- und Informationssicherheit zu machen. Aber nicht nur deshalb! Auch die korrekte Funktion des Gerätes sowie die Integrität und Verfügbarkeit der Daten sind bedroht. Bei einer medizinischen Anwendung ist die Sicherheit des Patienten in Frage gestellt.

Offene Netzwerk-Schnittstellen im Internet sind ständig automatisierten Angriffen ausgesetzt, die bekannt werdende Sicherheitslücken auszunutzen versuchen. Selbst ein in der Sache erfolgloser Angriff kann bei mangelnder Robustheit der Geräte-Software zu problematischem Fehlverhalten oder Ausfall führen (Denial of Service). Und nicht einmal das Bedrohungsszenario eines gerichteten Angriffs darf völlig vernachlässigt werden. Auch wenn die überwältigende Mehrheit der Nutzer nicht im Milieu unseres Agentenkrimis unterwegs ist, möchte doch niemand seine Gesundheit einem laienhaft abgesicherten Gerät anvertrauen. Wird eine Sicherheitslücke bekannt, kann der Imageschaden für den Hersteller enorm sein.

Ergänzendes zum Thema
Originalbeitrag als ePaper oder im pdf-Format lesen

Dieser Autorenbeitrag ist in der Printausgabe ELEKTRONIKPRAXIS 21/2015 erschienen. Diese ist auch als kostenloses ePaper oder als pdf abrufbar.

Know-how in der Disziplin Informationssicherheit (Information Security) ist also essentiell. Es gibt eine Reihe anerkannter Prinzipien sicheren Entwurfs, die Anforderungen und Architektur eines sicheren Systems leiten sollen. Dazu zählen zum Beispiel die Identifikation der schützenswerten Güter, die Minimierung der Angriffsfläche oder die Verwendung sicherer Standardeinstellungen. Wichtig ist ein ganzheitlicher Ansatz der Sicherheitsarchitektur (Bild 2).

Im Detail helfen von Security-Organisationen veröffentlichte Checklisten, mögliche Sicherheitslücken nicht zu übersehen, etwa die OWASP Internet of Things Top 10 [3]. Zudem gibt es wertvolle automatische Werkzeuge und Techniken für statische und dynamische Software-Analyse mit Sicherheitsfokus, etwa Fuzzing oder Penetration Testing. Setzt man populäre Off-The-Shelf-Software (OTS) ein, sollte man bekannte Security-Mailinglisten, wie beispielsweise Bugtraq [4], verfolgen. Für Medizinprodukte ergeben sich teils weitreichende gesetzliche Anforderungen an den Entwicklungsprozess von Gerät und Software. Das gilt nicht für jedes Produkt, aber immer dann, wenn das entsprechende Produkt als Medizinprodukt im Sinne des Gesetzes einzustufen ist.

Was sagt die Medizinprodukterichtlinie?

Doch wann ist das der Fall? Um das Produkt richtig einstufen zu können, muss es vom Hersteller für einen bestimmten Zweck festgelegt werden. Wird das Produkt für die Diagnose, Therapie oder Überwachung von Krankheiten oder Verletzungen eingesetzt oder dient es beispielsweise der Empfängnisverhütung? In beiden Fällen ist es ein Medizinprodukt. Dabei kann Software auf zwei Arten unter eine gesetzliche Regelung fallen: Software als integraler Bestandteil eines Gerätes oder eigenständig, etwa als mobile App.

In Europa bestimmt im Detail die Medizinprodukterichtlinie, was ein Medizinprodukt ist; sie gibt den gesetzlichen Rahmen für die Entwicklung vor. Sie definiert grundlegende Anforderungen, unter anderem zum Risikomanagement, zur Gebrauchstauglichkeit (Usability), zu Lebenszyklusprozessen für die Software-Entwicklung sowie zur elektrischen und mechanischen Sicherheit.

Um ein Medizinprodukt auf den europäischen Markt zu bringen, muss der Hersteller in einem Konformitätsbewertungsverfahren nachweisen, dass er diese Anforderungen erfüllt. Abhängig davon, in welche Risikoklassen das Gerät und seine Software je nach Gefährdungspotenzial für den Menschen einzustufen sind, ist eine entsprechende technische Dokumentation anzufertigen und eventuell bei einer benannten Stelle, etwa dem TÜV, einzureichen. Dazu ist es sinnvoll, sich an eine Reihe von Normen zu halten, die die EU als sogenannte harmonisierte Normen anerkannt hat.

Zunächst sollte ein Qualitätsmanagementsystem nach EN ISO 13485, eine umfassendere Verwandte der allseits bekannten Norm ISO 9001, etabliert werden. Durch ein Risikomanagement nach EN ISO 14971 werden mögliche Gefährdungen des Anwenders bzw. Patienten durch das Medizinprodukt analysiert, bewertet, dokumentiert und so weit wie möglich abgeschwächt. Die EN 62304 stellt Anforderungen an die eingesetzten Software-Lebenszyklus-Prozesse für Entwicklung, Wartung, Risiko- und Konfigurationsmanagement. Schließlich beschreibt die EN 62366, wie der Entwicklungsprozess die Gebrauchstauglichkeit des Produktes sicherstellen kann.

Medizinische Produkte für den US-Markt

Neben dem europäischen Markt ist für viele Hersteller der amerikanische Markt interessant. Hier ist die amerikanische Food and Drug Administration (FDA) zuständig. Auf Basis des Code of Federal Regulations, Title 21 „Food and Drugs“ ist hier eine echte Zulassung des Produktes durch die FDA vor dem Inverkehrbringen der medizinischen Produkte notwendig. Dazu muss entweder eine Premarket Notification (510(k)) oder ein umfassenderes Premarket Approval eingereicht werden. Der Umfang der technischen Dokumentation, die der Einreichung beigelegt werden muss, richtet sich dabei nach dem ermittelten Level of Concern (Gefährdungspotenzial).

Um den Hersteller zu unterstützen, veröffentlicht die FDA sogenannte Guidance-Dokumente [5]. Relevante Guidance-Dokumente für die Software eines Medizinproduktes beschreiben etwa die Verwendung von OTS-Software, Prinzipien der Software-Validierung oder den empfohlenen Inhalt von Einreichungen (Dokumente wie Risk Analysis, Software Requirements Specification, Architecture Design Chart oder Software Design Specification).

Wie adressiert die Regulierung die Themen Daten und Vernetzung? In Europa gibt es bisher wenig Konkretes. Wird das Medizinprodukt in einem medizinischen IT-Netzwerk eingesetzt, etwa in einem Krankenhaus, führt dessen Betreiber eventuell ein Risikomanagement nach EN 80001-1 durch. Dabei ist er auf die Mithilfe des Medizinprodukte-Herstellers angewiesen. Betreibt der Hersteller vernetzter Medizinprodukte selbst einen Server, um die Funktion seiner Geräte zu ermöglichen, muss er sich an die Medizinprodukte-Betreiberverordnung halten.

Bei der FDA wird es etwas konkreter: Interessante aktuelle Guidance-Dokumente für Medizinprodukte im Internet of Things betrachten Mobile Medical Applications sowie, gleich mit zwei Dokumenten, das wichtige Thema Cybersecurity. Hier werden insbesondere Forderungen für ein securitybezogenes Risikomanagement und für den Umgang mit Sicherheitslücken in OTS-Software gestellt. Die FDA verweist dabei auch auf die vom National Institute of Standards and Technolgy identifizierten Cybersecurity-Kernfunktionen (Bild 3).

Ergänzendes zum Thema
Originalbeitrag als ePaper oder im pdf-Format lesen

Dieser Autorenbeitrag ist in der Printausgabe ELEKTRONIKPRAXIS 21/2015 erschienen. Diese ist auch als kostenloses ePaper oder als pdf abrufbar.

Im Internet der Dinge entscheidet die Software

Die Entwicklung ist klar definiert: Eine wachsende Rolle spielen vernetzte Geräte, die sicher ihre Daten austauschen. Medizinische Applikationen und Anwendungen sind davon nicht ausgenommen. Wer hier beim Internet of Things dabei sein will, muss die besprochenen Themen für seine eigene Entwicklung klären. Vor allem rücken die Software der Geräte und IoT-Dienste in den Mittelpunkt. Um sicher sein zu können, die Anforderungen in Bezug auf Datenschutz und Informationssicherheit richtig zu erkennen und zu erfüllen, braucht das Unternehmen einen ausgereiften Software-Entwicklungsprozess und die Mitarbeiter einiges an fachlichem Können. Geht es um die Entwicklung eines Medizinprodukts, muss der Prozess nicht nur reif sein – er muss auch nachweisbar die regulatorischen Anforderungen erfüllen.

Wer eine erfolgversprechende Produktidee hat, aber nicht in allen der genannten Bereiche tiefere Erfahrung vorweisen kann, sollte unbedingt auf Unterstützung zurückgreifen. Dazu gehören der Aufbau des eigenen Know-hows auf anerkannte Schulungen. Das kann beispielsweise die Certified Professional for Medical Software sein. Daneben empfiehlt es sich außerdem noch, auf externe Wissensquellen zu nutzen. Das erfolgt durch kompetente Beratung oder durch die Vergabe von Software-Projektteilen an fachlich qualifizierte Dienstleister. So werden bereits im Vorfeld Fehler vermieden, deren Kosten bei einem Produkt im Feld schnell gewaltig ausdehnen können. Und das eingangs erwähnte Attentat per Funk bleibt schließlich nur Krimimaterial.

Dieser Autorenbeitrag ist in der Printausgabe ELEKTRONIKPRAXIS 21/2015 erschienen. Diese ist auch als kostenloses ePaper oder als pdf abrufbar

* Sebastian Seifert und Lars Hemmann sind beide Senior Software Engineers im Team Medical Devices bei Method Park.

(ID:43700643)