IT-Sicherheitsarchitekturen im Gesundheitswesen
Medizingeräte als Achillesferse?
Mit einer gestohlenen Krankenakte lassen sich laut mehreren Untersuchungen auf dem Schwarzmarkt circa 50 US-Dollar erzielen; eine gestohlene Sozialversicherungskarte dagegen bringt lediglich 1 US-Dollar ein. In den Krankenhäusern kommen zunehmend elektronische Krankenakten zum Einsatz, und es wird immer wichtiger, die Daten direkt auf den Medizingeräten zu erfassen. So entsteht ein Strom an wertvollen Daten, der seinen Ausgangspunkt auf den Medizingeräten hat und diese zu einem lohnenden Angriffsziel für alle Arten von Kompromittierungen macht.
Wie lässt sich die Sicherheit und Integrität der Daten auf einem medizinischen Gerät gewährleisten? Ein guter Ansatzpunkt ist das Betriebssystem, das den Zugriff auf die Hardwareressourcen kontrolliert und die Ausführung der Applikationen verwaltet. Ein Betriebssystem für ein mobiles Medizingerät muss sich an drei wichtigen Kriterien messen lassen: Verlässlichkeit, Anbindung und Datenintegrität. Mit Verlässlichkeit ist gemeint, dass das Betriebssystem auf Ereignisse korrekt, rechtzeitig und so lange wie erforderlich reagiert. Anbindung bezeichnet die Art und Weise, wie das Betriebssystem entweder direkt oder über ein Netzwerk mit verschiedenen anderen Geräten und Systemen kommuniziert. Und bei Datenintegrität und -sicherheit geht es darum, wie das Betriebssystem Daten sicher speichert und vor Einsichtnahme durch nicht autorisierte Dritte schützt.
Das Betriebssystem ist von zentraler Bedeutung für das medizintechnische Gerät: Fällt das Betriebssystem aus, versagt auch alles andere. Und ein medizintechnisches Gerät ist kein Desktop-PC – selbst bei Geräten der FDA-Klassen I und II sind sporadische Ausfälle und Neustarts inakzeptabel. Derartige Probleme werden gegebenenfalls auf dem PC zu Hause noch toleriert, niemand würde sie aber hinnehmen, wenn die eigene Gesundheit oder Leib und Leben von Patienten oder Angehörigen auf dem Spiel stehen.
Ein grundlegendes Kriterium bei der Auswahl eines Betriebssystems ist seine Konformität zu einschlägigen Bestimmungen in den Märkten, in denen das Medizingerät vertrieben werden soll. In den USA können Medizintechnikhersteller auf zwei Arten eine Marktzulassung erlangen: Für Produkte, die mit bereits von der US-amerikanischen Food and Drug Administration (FDA) zugelassenen Produkten vergleichbar sind, kann 90 Tage vor der geplanten Markteinführung ein Antrag auf 510(k)-Zulassung bei der FDA gestellt werden. Andere Geräte muss zunächst die FDA prüfen und genehmigen, bevor sie auf den Markt gebracht werden dürfen. Darüber hinaus müssen Medizintechnikhersteller in den USA gegebenenfalls Zulassungen nach weiteren gesetzlichen Bestimmungen einholen, darunter etwa der Health Insurance Portability and Accountability Act (HIPAA) und der Health Information Technology for Economic and Clinical Health Act (HITECH). Diese Konformitätsanforderungen zu erfüllen ist zeitaufwendig und wirft ganz erhebliche Zusatzkosten auf dem Weg zur Marktreife auf, doch es führt kein Weg an ihr vorbei.
Aufsichtsbehörden wie die FDA prüfen zwar keine einzelnen Komponenten, sondern ganze Geräte. Dennoch ist es für den Hersteller von Vorteil, wenn seine Geräte auf einem Betriebssystem aufbauen, das bereits erfolgreich in Systemen zum Einsatz kam, die den Anforderungen der Aufsichtsbehörde genügen. Und nicht nur das: Die Auswahl eines Betriebssystems, dessen Konformität mit wichtigen Medizintechniknormen wie etwa der IEC 62304 bereits bewiesen wurde, kann den Zeit- und Kostenaufwand für die Erlangung einer Zulassung erheblich reduzieren.
Was sagt die IEC 62304?
Die IEC 62304 ist eine der Normen, welche die funktionale Sicherheit in Medizingeräten regelt (Bild 1). Richtlinien der FDA für die USA sowie der Generaldirektion Gesundheit und Verbraucher für die EU nehmen auf sie Bezug, insbesondere die Medizinprodukterichtlinie (93/42/EWG), die Richtlinie für aktive implantierbare medizinische Geräte (90/385/EWG) und die Richtlinie über In-vitro-Diagnostika (98/79/EG). Die Norm beschreibt empfohlene Vorgehensweisen für Hersteller, die hochwertige Software für das Gesundheitswesen entwickeln.
Die IEC 62304 geht davon aus, dass in den Geräten Software-Standardkomponenten (»off-the-shelf« bzw. OTS, kommerziell oder anderweitig) zum Einsatz kommen und liefert zwei Definitionen für »Software unklarer Herkunft« (SOUP): Software, die nicht speziell für ein medizinisches Gerät geschrieben wurde und/oder Software mit fehlender oder unzureichender Dokumentation des Entwicklungsprozesses. Wichtig ist an dieser Stelle, dass die Unterscheidung nicht zwischen kommerziellen Standardkomponenten (COTS) und Software unklarer Herkunft (SOUP) erfolgt, sondern zwischen sogenannter »Opaque-SOUP« und »Clear-SOUP«. Hobbs schreibt in [1], dass Hersteller, die zwischen undurchsichtiger Opaque-SOUP (die zu vermeiden ist) und Clear-SOUP (für die Quellcode, Fehlerhistorien und Daten aus dem Langzeiteinsatz vorliegen) unterscheiden, in vielen Fällen feststellen werden, dass COTS-Software die optimale Wahl für sicherheitsrelevante Medizingeräte ist (siehe auch [2]).
ISO-62304-Konformität bietet zwar zahlreiche Vorteile, in der Realität sind aber die meisten Betriebssysteme nicht konform. Es drängt sich der Vergleich eines Hauskaufs auf, bei dem nur die Fassade, nicht aber das Tragwerk des Objekts die baurechtlichen Auflagen erfüllt.
Wo im Englischen zwischen »Safety« und »Security« unterschieden wird, kennen wir im Deutschen nur ein Wort: »Sicherheit« – schließlich gehen funktionale Sicherheit (Safety) und Sicherheit vor externen Bedrohungen (Security) oft Hand in Hand. Sicherheitsbedrohungen für medizinische Geräte sind real. Systeme im Gesundheitswesen sind aufgrund ihrer Verwundbarkeit und des Werts der von ihnen verwalteten Informationen ein lohnendes Angriffsziel.
Ein Datenleck bei einem medizinischen Gerät kann schwerwiegende Folgen haben: Es könnten vertrauliche Patientendaten kompromittiert werden, oder das Gerät könnte böswillig modifiziert und dadurch die Gesundheit von Patienten gefährdet werden. Nach einem Bericht des Ponemon-Instituts aus dem Jahr 2011 mit dem Titel »Second Annual Benchmark Study on Patient Privacy & Data Security« gaben 96 Prozent aller Gesundheitsdienstleister an, dass sie in den letzten zwei Jahren mindestens ein Datenleck gehabt hätten.
Erst kürzlich hat die FDA neue Hinweise zu Cybersicherheit bei medizinischen Geräten herausgegeben. Die Hinweise enthalten Empfehlungen sowie eine Liste von Informationen, die bei Anträgen auf Marktzulassung von medizintechnischen Geräten bei der FDA beizufügen sind. Unter anderem wird den Herstellern von Medizingeräten nahegelegt, Cybersicherheits-Kontrollmechanismen zu entwickeln, die sicherstellen, dass ein Gerät seinen vorgesehenen Einsatzzweck erfüllt, und Cybersicherheit bei Konzeption und Entwicklung des Medizingeräts zu berücksichtigen. Weitere empfohlene Sicherheitsvorkehrungen sind unter anderem der Einsatz moderner Mechanismen auf Betriebssystemebene, die den Zugriff auf Trusted-Users beschränken, sowie die Verschlüsselung vertraulicher Informationen, um die Sicherheit von Datenübertragungen an das und von dem Gerät zu gewährleisten.
Es werden Fortschritte im Bereich des Betriebssystems angemahnt, darunter mehr Schutz vor Hackern in mobilen Netzen. Das Betriebssystem muss eine wesentlich feingranularere Kontrolle über mehrere Systemprivilegierungsstufen bieten. Systementwickler sollten über Einstellungen festlegen können, welche Operationen ein Programm ausführen und wie es einen Dienst vom Kernel des Betriebssystems anfordern darf (Bild 2). Außerdem sollte es nicht mehr erforderlich sein, einem Softwareprogramm, das nur bestimmte Ressourcen benötigt, Root-Zugriff auf das ganze System zu geben. Vielmehr sollte mit Betriebssystemmitteln sichergestellt werden können, dass jedes Programm nur auf die tatsächlich benötigten Ressourcen zugreifen kann.
Da sich die Verbraucher immer mehr auf mobile medizinische Geräte und medizinische Apps verlassen, werden Maßnahmen für mehr Datenschutz und Sicherheit immer wichtiger. Die Wahl des Betriebssystems hat erhebliche Auswirkungen auf die möglichen Sicherheitsmaßnahmen wie auch auf den Zeit- und Kostenaufwand für die Zertifizierung und die Gesamtkosten des Geräts.
Über den Autor:
Chris Ault ist als Senior Product Manager für das Medizintechnik-Softwareportfolio von QNX Software Systems verantwortlich.
| Wechselvolle Geschichte von QNX |
|---|
| Im Jahr 1982 gründeten Gordon Bell und Dan Dodge die Firma Quantum Software. Um die Jahrtausendwende wurde das Unternehmen in QNX Software Systems umbenannt. 2004 wurde QNX Teil des Konzerns Harman International. Im April 2010 kaufte Research in Motion (heute: BlackBerry) QNX von Harman. |
Lesen Sie mehr zum Thema
