Parasoft C/C++test 2022.2 unterstützt das neue MISRA C:2012 Amendment 3 und eine Entwurfsversion von MISRA C++ 202x. Erfahren Sie mehr >>

Die Heilung von Softwarefehlern und Sicherheitslücken in Medizinprodukten

Von Alan Zeichick

6. Oktober 2016

3  min lesen

Moderne medizinische Geräte nutzen zunehmend Mikroprozessoren und eingebettete Software sowie ausgefeilte Kommunikationsverbindungen für lebensrettende Funktionen. Insulinpumpen sind beispielsweise auf eine Batterie, einen Pumpenmechanismus, einen Mikroprozessor, Sensoren und eingebettete Software angewiesen. Herzschrittmacher und Herzmonitore enthalten auch Batterien, Sensoren und Software. Viele Geräte verfügen auch über WiFi- oder Bluetooth-basierte Kommunikationsfunktionen. Selbst Krankenzimmer mit intravenösen Medikamentenabgabesystemen werden von eingebetteten Mikroprozessoren und Software gesteuert, die häufig mit dem Netzwerk der Einrichtung verbunden sind. Diese Innovationen bedeuten jedoch auch, dass ein Softwarefehler einen kritischen Fehler oder eine Sicherheitslücke verursachen kann.

Echte Bedenken hinsichtlich der Software-Sicherheit für Medizinprodukte

Im Jahr 2007 ehemaliger Vizepräsident Dick Cheney hatte bekanntlich die drahtlosen Funktionen seines Herzschrittmachers deaktiviert über Bedenken "über Berichte, dass Angreifer die Geräte hacken und ihre Besitzer töten könnten". Seitdem sind die Schwachstellen, die durch die größere Angriffsfläche auf modernen medizinischen Geräten verursacht werden, von hypothetisch zu nachweisbar geworden, teilweise aufgrund der Komplexität der Software und teilweise aufgrund des Versagens, den Code ordnungsgemäß zu härten.

Im Oktober 2011, Das Register meldete "Ein Sicherheitsforscher hat einen Angriff entwickelt, der nahe gelegene Insulinpumpen entführt und es ihm ermöglicht, Diabetikern, die sich auf sie verlassen, heimlich tödliche Dosen zu verabreichen." Die Insulinpumpe funktionierte, weil die Pumpe ein Kurzstreckenradio enthielt, mit dem Patienten und Ärzte ihre Funktionen anpassen konnten. Der Forscher zeigte, dass er mithilfe einer speziellen Antenne und einer speziell geschriebenen Software die Kontrolle über ein solches Gerät innerhalb von 300 Fuß lokalisieren und übernehmen konnte.

In einer Bericht veröffentlicht von Independent Security Evaluators (ISE) Bei der Untersuchung von 12 Krankenhäusern kam die Organisation zu dem Schluss, dass „entfernte Gegner leicht Angriffe ausführen können, die Aufzeichnungen oder Geräte manipulieren, um die Gesundheit der Patienten vollständig zu gefährden“ (S. 25). Später in dem Bericht zeigen die Forscher, wie sie die Fähigkeit demonstrierten, den Fluss von Medikamenten oder Blutproben im Krankenhaus zu manipulieren, was zur Abgabe unangemessener Medikamententypen und -dosierungen führte (S. 37) - und dies alles in der Krankenhauslobby . Sie waren auch in der Lage, Patientenmonitore und Atemschläuche zu hacken und fernzusteuern - und Alarme auszulösen, die dazu führen könnten, dass Ärzte oder Krankenschwestern nicht benötigte Medikamente verabreichen.

FDA-Richtlinien für Software für medizinische Geräte

Die Aufsichtsbehörden nehmen dies zur Kenntnis. Im Juni 2013 gab der US-amerikanische Food and Drug Administrator (FDA) eine Sicherheitswarnung zum Thema „Cybersicherheit für Medizinprodukte und Krankenhausnetzwerke“ heraus. Während sich die meisten dieser Richtlinien auf sicherheitsspezifische Belange konzentrieren (z. B. den Schutz von Benutzernamen und Kennwörtern), enthalten sie Best Practices für Entwickler eingebetteter Software. Zum Beispiel ist die FDA besorgt über „Sicherheitslücken in Standardsoftware, die unbefugten Geräte- oder Netzwerkzugriff verhindern soll, wie z. B. Klartext oder keine Authentifizierung, fest codierte Kennwörter, dokumentierte Dienstkonten in Servicehandbüchern und schlechte Codierung / SQL-Injection. “

Jenseits der Cybersicherheit: Risikomanagement im Zusammenhang mit Softwarefehlern

Während Sicherheitsverletzungen für viele Unternehmen im Vordergrund stehen, sollten Softwarefehler ein größeres Problem darstellen. Eine Pufferüberlastung, ein unzureichend getesteter Fehlerbehandler, ein Speicherverlust oder ein Defekt, der beispielsweise zum Absturz einer Smartphone-App führen würde, kann einem Patienten echten Schaden in einem medizinischen Gerät zufügen.

Durch die Implementierung einer automatisierten Softwareentwicklungsrichtlinie kann verhindert werden, dass Fehler in die Codebasis eingeführt werden, und das Geschäftsrisiko wird verringert. Vielen Softwareherstellern für medizinische Geräte scheint jedoch die Prozesssichtbarkeit zu fehlen, die sicherstellen würde, dass die Richtlinien eingehalten werden. Laut einem Juli 2012 Bericht des Electronic Engineering Journal"In Medizinprodukten, die Software enthalten, kann es äußerst schwierig sein zu beurteilen, ob ein Unternehmen seine Prozesse für Konstruktionskontrollen befolgt, insbesondere in den Bereichen Validierung, Risiko- / Gefahrenanalyse und Konstruktionsänderungen." Infolgedessen wurden mehrere Codierungsfehler gemeldet. Darüber hinaus waren „einige Fehler grundlegende Verstöße gegen Software-Codierungspraktiken, während andere neue Fehler waren, die bei der Korrektur früherer Fehler eingeführt wurden.“

Was kann getan werden? Entwickler von Medizinprodukten müssen die Best Practices für die Entwicklung sicherheitskritischer eingebetteter Software befolgen und sich darüber im Klaren sein, dass immer ausgefeiltere Funktionen (einschließlich externer Konnektivität) die Bedrohungen und den Nichtdeterminismus dieser Geräte erhöhen. Wenn ein Herzmonitor oder eine IV-Pumpe ferngesteuert und gesteuert werden kann, vervielfachen sich die Risiken weit über die Komplexität einfacher Standalone-Geräte hinaus.

Ein hilfreicher Leitfaden ist die ISO-Norm IEC 62304: 2006, „Medizinproduktesoftware - Software-Lebenszyklusprozesse. ” Wie bei allen ISO-Standards ist es sehr detailliert und umfasst Design, Architektur, Integrationstests für Komponententests und mehr. Die beste Lösung: Verstehen Sie die Risiken und befolgen Sie die Richtlinien, um das Risiko während des gesamten Softwareentwicklungszyklus zu verwalten. Es kann eine Frage von Leben und Tod sein.

Die statische Analyse von Parasoft umfasst übrigens: Mehrere integrierte Regeln für die Entwicklung von FDA-konformer Software Verwenden von C / C ++, .NET-Sprachen und Java.

Von Alan Zeichick

Alan Zeichick ist Principal Analyst bei Camden Associates. Zuvor war Alan Chefredakteur der SD Times von BZ Media. Folgen Sie ihm @zeichick.

Erhalten Sie die neuesten Nachrichten und Ressourcen zum Testen von Software sofort.