Softwareentwicklung in der Medizin Die statische Codeanalyse prüft auf Softwaresicherheit

Anbieter zum Thema

Insider Research

Fehlerhafte Software in medizinischen Geräten führt im schlimmsten Fall dazu, dass Patienten sterben. Neben verbesserter Software sollen Verifikationsprozesse und statische Codeanalyse helfen.

Entwickler von Medizingeräten müssen sicherheitskritische Software für lebensrettende Anwendungen erstellen. Gefährlich wird es, wenn Anbieter von medizinischen Geräten die Software-Entwicklung immer noch als risikoarme Aktivität betrachten.

Denn dann verwundert es kaum, dass Patienten wegen schlecht entwickelter Medizingeräte-Software sterben. Innerhalb der letzten 10 Jahre haben sich die Rückrufe von fehlerhaften Medizingeräten beinahe verdoppelt: Vor allem wegen eines fehlerhaften Geräts mit hinreichender Wahrscheinlichkeit für Todesfall. So registrierte die Food and Drug Administration (FDA) der USA von 2005 bis 2009 über 56.000 Probleme und 710 Todesfälle im Zusammenhang mit Infusionspumpen an die FDA.

Zudem riefen Pumpenhersteller mehr als 87 Geräte zurück. Weil laut FDA viele Verletzungs- und Todesfälle auf Fehler beim Produktdesign und Entwicklung zurückzuführen sind, rief sie in 2010 die „Infusion-Pump-Improvement-Initiative“ ins Leben. Sie sieht unter anderem die verbesserte Software-Entwicklung und Verifikationsprozesse in der Branche vor und empfiehlt die statische Codeanalyse, um die gefährlichsten Fehlertypen und Sicherheitsrisiken aufzuspüren.

Malware und Viren in medizinischen Geräten

Wie Autos oder PCs sind moderne Medizingeräte größenteils netzwerkfähig: Sei es für die Beobachtung oder Berichterstattung oder Schulungszwecke. Über diese Schnittstellen können Hacker in medizinische, im Körper installierte Geräte wie Schrittmacher oder Insulinpumpen manipulieren, und den Patienten Schaden zufügen. Zudem findet sich laut MIT Technology Review auf vielen Medizingeräten ähnliche Malware und Viren wie auf Desktop-PCs. Dahinter steht, dass die Programme oft auf älteren Windows Betriebssystemen basieren, und die Hersteller einer Änderung nicht zustimmen bzw. dem Krankenhaus ihre Zustimmung für Änderungen nicht erteilen, nicht einmal für zusätzlich Antivirus-Software, weil sie sich über die regulatorischen Anforderungen uneins sind.

Ein weiterer Gefahrenfaktor ist der wachsende Anteil an Fremdsoftware oder zugekaufter Software. Weil dieser Code nicht vom Gerätehersteller selbst entwickelt wurde, unterliegt er auch nicht dessen direkter Kontrolle. Selbst wenn der Code keine Bugs enthält, bleibt immer noch die Gefahr für unentdeckte Fehler, die über das Betriebssystem aus dritter Hand, Code Libraries, Open Source oder kommerzielle Softwareteile bei deren Integration eingeschleppt werden können.

Bildergalerie

Wo Leben auf dem Spiel stehen, sollten sich Entwickler von Medizingerätesoftware zum Einsatz von „Best Practices“ verpflichten – hier ist die Übernahme eines sicherheitskritischen Kodierungsstandards kosteneffektiv und sehr lohnenswert. Sowohl die FDA als auch EU verlangen einen dokumentierten Software-Entwicklungsprozess (IEC62304), wobei die FDA nicht ausdrücklich auf Programmierstandards besteht. Viele Medizingeräte-Hersteller haben deren Wichtigkeit erkannt und sie freiwillig als Teil ihrer Software-Qualitätsinitative übernommen. Besonders vorteilhaft ist: Viele der „Best Practices“ sind nur mit minimalem Aufwand oder Kosten verbunden, und inzwischen existieren ausgezeichnete sicherheitskritische Standards für Medizintechnik – wie die „Power of 10“ Regeln des NASA Jet Propulsion Laboratory für sicherheitskritisches Programmieren, ursprünglich zum Einsatz in Software für Raumschiffe entwickelt.

Zehn einfach zu merkende Programmierregeln

Diese zehn einfachen, leicht zu merkenden Programmierregeln wurden so konzipiert, dass ein Missbrauch automatisch von statischen Analysetools entdeckt wird. Die moderne Quellcodeanalyse ist die effektivste Art, um die wirksame Umsetzung eines Programmierstandards sicherzustellen. Zusätzlich zur Prüfung des Codes nach seiner Konformität mit Standards kann sie auch ernste semantische Fehler aufdecken, wie Buffer Overruns, NULL-Zeiger Dereferenzierungen, Race Conditions und Ressourcen-Lecks oder eine fehlerhaft genutzte Schnittstelle zwischen Programmen (API).

Beinahe 30 Prozent des Codes in Embedded-Anwendungen, wie Medizingeräten, ist kommerzielle Fremdsoftware in Binärformat ohne eigentlichen Quellcode (Grafiken und Windowing Toolkits, Kryptographie-Bibliotheken, Middleware und Datenbanken). Besonders gefährdet sind Systeme, die sich aus Code von mehreren Anbietern zusammensetzen. Viele Fehler, die zu Sicherheitsschwachstellen führen, haben ihren Ursprung an Schnittstellen zwischen Modulen, oftmals wegen verschiedener Interpretationen ihrer Spezifizierungen. Sind Teile des Quellcodes nicht verfügbar, können Mischformen der statischen Analysetools, die Quellcodeanalyse mit Binärcodeanalyse kombinieren, sehr hilfreich bei der Sicherstellung von Robustheit und Sicherheit des Codes sein.

Sicherheitslücken und bösartiger Code

Als Besonderheit überprüft die Binärcodeanalyse Software auf Sicherheitslücken und bösartigen Code, ohne dass sie dazu deren Quellcode benötigt. Da diese Technologie nicht auf Debug-Symbolen oder Symboltabellen beruht, ermöglicht sie das Prüfen von abisolierten Programmdateien („Stripped Executables“), wie sie gewöhnlich von Softwareanbietern ausgeliefert werden. Zu den „Best Practices“ der Entwickler gehört auch, Eingaben aus potenziell gefährlichen Kanälen immer als risikoreich einzustufen, bis deren Gültigkeit geprüft wurde, weil der Großteil der eingesetzten Medizingeräte-Software latente Fehler oder Sicherheitsschwachstellen enthält.

Eingaben aus gefährlichen Kanälen einstufen

Ungeprüfte Eingabewerte werden als „Tainted“ bezeichnet, zu deutsch: Mit einem Makel behaftet. Zu den typischen Fehlerarten gehören Buffer Overruns, SQL- oder Befehl-Injektion, Cross-Site Scripting, Arithmetic Overflow und Path Traversal. Zu prüfen, ob ein Programm Tainted-Daten korrekt verarbeitet, kann eine echte Herausforderung sein, weil dies die Überprüfung des Datenverlaufs durch die Code-Struktur verlangt. Sogar bei relativ kleinen Programmen ist das sehr mühsam, und für die meisten Echtzeitanwendungen generell manuell nicht durchführbar.

Darum liegt der beste Ansatz in der Automatisierung. Die Taint-Analyse ist eine Technik, um Entwicklern aufzuzeigen, wie der Verlauf von riskanten Daten von einem Programmteil in einen anderen erfolgen kann. Mithilfe von modernen statischen Analysetools können sie mögliche Angriffsflächen auf der Programmoberfläche besser verstehen und somit die Fehlersuche und –behebung enorm verkürzen. Manche Tools führen die Taint-Analyse dynamisch aus. Dennoch bietet ein statischer Ablauf wichtige Vorteile – nicht zuletzt um sicherzugehen, dass alle Ausführungen möglich sind, und nicht nur diejenigen, für die Testfälle vorliegen.

Auch vor dem OP macht die Vernetzung nicht halt. Ganz im Gegenteil: In Krankenhäusern sind Übertragungen zu Schulungszwecken oder zur Diagnosefindung keine Seltenheit. Entwickler von Medizingeräte-Software tragen die Verantwortung für hochwertigen Code, vom dem Gesundheit und Sicherheit der Patienten abhängen. Sicherheitskritische Programmierstandards erzielen in anderen Branchen, wo es um Menschenleben geht, ausgezeichnete Ergebnisse.

Wegen der hohen Rückrufrate von Medizingeräten sollte ihre Übernahme von Geräteherstellern zwingend sein. Moderne statische Analysetools finden Fehler, die sehr früh in der Entwicklung auftreten, und gewährleisten die korrekte Implementierung und Sicherheit von Software. Darum sollten sie in der Medizintechnik routinemäßig eingesetzt werden.

Dieser Beitrag stammt ursprünglich von unserem Schwesterportal Elektronikpraxis.de.

* Dr. Paul Anderson ist Vice President Engineering bei GrammaTech.

(ID:44413513)