Anwendungsfall Medizinelektronik Wenn Safety und Security kollidieren

Abbildung 1: Die Kombination aus der Sicherheit eines Separation Kernels und der Zweckmäßigkeit eines Hypervisors erfüllt viele Anforderungen zur funktionalen Sicherheit, die auch mit der Angriffssicherheit in Verbindung stehen.

Zwischen Security und Safety liegen meist Welten, mit unterschiedlichen Standards, Herangehensweisen und maßgebenden Gremien.

Mit dem richtigen Ansatz kann Software aber beiden Anforderungskatalogen genügen.

Beim Stichpunkt »Software Security«, also die Sicherheit von Daten, werden die meisten Menschen vermutlich an gehackte Bankkonten oder Angriffe auf Firmendatenbanken denken. Der augenblickliche Trend zum Hacken von Krankenakten ist jedoch viel attraktiver als elektronische Kreditkartendaten, weil profitabler und auch risikoloser. »Die natürliche, unverzügliche Reaktion auf die Entdeckung eines solchen Vorstoßes wäre, den Zugang abzuriegeln«, erklärt Mark Pitchford, Technical Manager EMEA von Lynx Software Technologies. »Vorübergehende Unannehmlichkeiten für autorisierte Nutzer sind in Hinblick auf die ärztliche Schweigepflicht und Privatsphäre des Patienten sicher als zweitrangige, untergeordnete Überlegung anzusehen.«

Im Gegensatz dazu müssen sicherheitskritische Anwendungen oft weiterarbeiten, auch wenn ein Problem auftaucht – zum Beispiel wenn ein implantierbarer Kardioverter-Defibrillator (ICD) wie im Jahr 2005 der Fortify DR von St. Jude Medical möglicherweise von kosmischer Hintergrundstrahlung so beeinflusst werden kann, dass das Resultat ein dauerhafter Verlust seiner Defibrillationsfähigkeiten wäre.

Im Jahr 1983 führte die Atomic Energy of Canada Limited (AECL) »Therac 25« ein, das neueste Produkt einer ganzen Serie erfolgreicher Strahlentherapie-Apparaturen. Zwischen 1985 und 1987 war Therac 25 an mindestens sechs Unfällen beteiligt, bei denen Patienten massive und tödliche Überdosen an Strahlung erhielten, ungefähr das 100-Fache der beabsichtigten Dosis – ein Ergebnis völlig unzureichender Praktiken bei der Softwareentwicklung. Hier gab es keinerlei Hinweise auf eine Sicherheitslücke. Erneut wäre sogar in dieser Situation die Standardoption gewesen: das Gerät einfach abzuschalten.

Der Hacker Barnaby Jack wies die Möglichkeit nach, implantierbare Insulinpumpen von Medtronic drahtlos angreifen und daraufhin kontrollieren zu können, was die Tatsache unterstreicht, dass wir bei medizinischen Geräten im Grunde sowohl funktional als auch angriffssichere Systeme haben müssen. Der Hacker wies eine eindeutige Sicherheitslücke nach, die das Gerät unsicher machte. »Dem Empfänger des überdosierten Insulins dürfte es ziemlich egal sein, welche der beiden Kategorien – Safety oder Security – die angreifende Software letztendlich kompromittierte«, erklärt Pitchford.

Der Leitfaden »Content of Premarket Submissions for Management of Cybersecurity in Medical Devices - Guidance for Industry and Food and Drug Administration Staff« der amerikanischen Food and Drug Administration (FDA) nimmt einen ähnlichen Standpunkt ein. Er empfiehlt, dass Hersteller Cybersecurity-Risiken als Bestandteil des Designs und der Entwicklung eines medizintechnischen Gerätes betrachten und dass sie der FDA die identifizierten Risiken und damit verbundenen Maßnahmen dokumentierten sollten, um diese Risiken zu reduzieren. Dies impliziere in vorbildlicher Weise funktionale Sicherheit und Angriffssicherheit.

Generelle Standards für die funktionale Sicherheit wie IEC 61508/EN 61508 und die spezifisch für die Medizintechnik gültigen Varianten IEC 62304 und EN 62304 formulieren Anforderungen an die funktionale Sicherheit, um mit jeglicher Sachlage umzugehen, die die funktionale Sicherheit beeinträchtigt – einschließlich jeglicher Sicherheitsbedrohung mit diesem Potential. Bei jedem dieser Standards wird größte Sorgfalt gelegt auf Best-Practise-Methoden in der System-und Softwareentwicklung, vom Design und der Spezifizierung über die Implementierung bis hin zum Test.

»Obwohl diese Praktiken von Anfang an sicherheitsorientiert konzipiert sind, wird ein gut gestalteter, geschriebener und getesteter Code unvermeidlich sicherer sein, weil viele Fehler, die Verwundbarkeit verursachen, zweifellos nicht vorhanden sein werden«, erläutert Pitchford. »Im Gegenzug ist es gleichermaßen angebracht, diese auf funktionale Sicherheit zielenden Best-Practise-Prinzipien um Pendants auf dem Gebiet der Angriffssicherheit zu ergänzen.«