Security für Medizingerätesoftware Schneller und sicherer am Markt

Bild: Grammatech; iStock, Chalabala
06.06.2017

Bei einem medizinischen Notfall zählt jede Sekunde. Jeder Griff muss sitzen, jedes medizinische Gerät funktionieren. Damit auf Medizintechnik auch in Zeiten der Digitalisierung Verlass ist, dürfen Sicherheitslücken gar nicht erst entstehen.

Sicherheitsexperten zufolge ist die Security in Medizingeräten noch immer unzureichend. In einer gängigen Infusionspumpe fanden sich zum Beispiel mehr als 1.400 Sicherheitslücken. Medizingeräte sind heute gefährdeter als je zuvor. Grund dafür ist die steigende Zahl drahtlos kommunizierender, vernetzter und an das Internet angebundener Devices. Neben der funktionalen Sicherheit (Safety) muss die Software der Medizingeräte deshalb zukünftig auch die Absicherung gegen externe Angriffe (Security) mit einbeziehen. Das Risikomanagement, das auch eine besser Absicherung und Schwachstellen-Management umfasst, ist der Eckpfeiler bei der Softwareentwicklung für Medizingeräte; in diesem Prozess spielt die statische Analyse eine zentrale Rolle.

Aufgrund der Notwendigkeit robuster Security für Medizingeräten veröffentlichte die amerikanische Arzneimittelzulassungsbehörde (Food and Drug Administration, FDA) im Jahr 2014 Richtlinien zum Umgang mit Cybersecurity. Diese sind als übergeordneter Leitfaden für den Umgang mit dem Thema Security zu verstehen. Sie nennen viele Gründe für den Einsatz automatisierter Tools, wie die Software Codesonar des Unternehmens Grammatech.

Cybersecurity von Anfang an

Hersteller sollten bereits bei der Entwicklung eines Medizingeräts das Thema Cybersecurity berücksichtigen, lautet eine der Empfehlungen der FDA. Auch Grammatech betont, dass der Security-Aspekt von Anfang an eingebaut und nicht erst später nachgerüstet werden sollte.

Das Design- und Entwicklungskonzept sollte die Identifikation von Assets, Bedrohungen und Schwachstellen angemessen berücksichtigen, lautet eine weitere Empfehlung. Die statische Analyse, die Grammatech mit Codesonar anbietet, fügt sich nahtlos in bestehende Softwareentwicklungsprozesse ein und hilft insbesondere bei der Detektierung und Identifikation von Sicherheitslücken in Code und Binärdateien.

Im Umgang mit dem Thema Cybersecurity empfiehlt die FDA zudem eine Beurteilung der Auswirkungen von Bedrohungen und Schwachstellen auf die Funktionalität des Geräts und damit auch für die Endanwender und Patienten. Auch die Wahrscheinlichkeit für eine Bedrohung und für die Ausnutzung einer Schwachstelle sollten Unternehmen untersuchen. Mithilfe der Tainted-Data-Analyse kann Codesonar die Herkunft von Daten in der gesamten Software verfolgen, um potenzielle Anfälligkeiten gegenüber externen Quellen offenzulegen. Vor der Auslieferung sollten Hersteller außerdem Unterlagen zur Cybersicherheit ihres Medizingeräts vorlegen, rät die FDA. Die Reportfunktionen der statischen Analysetools unterstützen die Prozessdokumentation, die Abwicklung der Tests und das Bereitstellen der Software.

Security an erster Stelle

Das Thema Security war nicht immer ein vorrangiges Kriterium bei Medizingeräten. Weil moderne Geräte aber an Netzwerke angeschlossen und oft mit dem Internet verbunden sind, müssen Security und Privatsphäre verstärkt Beachtung finden. Insbesondere müssen Security-Prinzipien früher im Lebenszyklus der Entwicklung angewandt werden. Ein Designkonzept nach dem Prinzip Security First sieht vor, dass Security mit höchster Priorität in den Software Development Lifecycle (SDLC) eingebunden wird. Entwickler und Projektmanager sollten in diesen wichtigen Phasen mindestens folgende Aktivitäten vornehmen:

  • Anforderungsphase: Liegt eine Risikobewertung für das gesamte System vor, lassen sich die möglichen Bedrohungen für ein Gerät besser verstehen. In diesem Abschnitt sollten die für Security spezifischen Anforderungen einbezogen werden, verbunden mit bekannten Missbrauchsfällen. Bei diesen handelt es sich um Sicherheitslücken und Anwendungsfälle, die Angreifer missbräuchlich verwenden könnten. Security wird in dieser Phase zu einer bekannten Zielsetzung des Entwicklungsprojekts, mit dem entsprechenden Umfang an Risikomanagement sowie Zeit- und Kostenplanung.

  • Design und Architektur: Spätestens wenn die in Frage kommenden Architekturen verfügbar sind, müssen die Prüfungen auch Security-Aspekte einbeziehen. Jetzt sollten Testpläne erstellt werden, die Security-
    Analysen gemäß den erkannten Missbrauchsfällen umfassen.

  • Code-Entwicklung: Während der Codierungsphase sind Security-
    Richtlinien und Codierstandards einzuhalten; auch Tests und die Testautomation unter Einbeziehung einer Security-Analyse spielen eine wesentliche Rolle. Automatisierungs-Tools, wie die statische Analyse, sind entscheidend, damit sich keine Schwachstellen in das Produkt einschleichen.

  • Integration und Test: Nimmt das System als Ganzes langsam Gestalt an, werden mit Subsystem- und Systemtests etwaige Schwachstellen aufgedeckt, bevor die Integration und Markteinführung erfolgt. Automatisierte Penetration-Testing-Werkzeuge helfen in diesem Stadium, Schwachstellen offenzulegen, die in früheren Entwicklungsphasen nicht berücksichtigt wurden.

  • Deployment und Wartung: Ist ein Produkt erst auf dem Markt im Einsatz, steigen die Kosten für die Beseitigung von Sicherheitslücken exponentiell. Wird ein Produkt nach dem Prinzip Security First entwickelt, sinkt die Gefahr, von einer Sicherheitsverletzung betroffen zu sein. Dennoch ist ein Security-
    Problem auch hier möglich. Für dessen zügige Beseitigung ist es unerlässlich, das Produkt mit der Fähigkeit auszustatten, Firmware und Software zu aktualisieren. Neue Schwachstellen und Bedrohungen müssen in einem iterativen Prozess immer wieder berücksichtigt werden.

Ein Medizingerät abzusichern erfordert viele Überlegungen. Über die bestehenden funktionalen Anforderungen hinaus zählen zu den Security-Anforderungen unter anderem Benutzer-
Authentisierung, Manipulationsschutz, sichere Speicherung, abgesicherte Kommunikation, Zuverlässigkeit und Verfügbarkeit.

Softwaremodule verifizieren

Obwohl die Norm IEC 62304, die Mindestanforderungen an die wichtigsten Lebenszyklusprozesse für medizinischer Software enthält, keine bestimmten Software-Tools benennt, formuliert sie die Notwendigkeit für rigorose Tests, Akzeptanzkriterien und Rückverfolgbarkeit. Angesichts des Umfangs der meisten Softwareprojekte für Medizingeräte ist es nicht sinnvoll, diese Funktionen ohne entsprechende Tools auszuführen. So verlangt die Norm einen Verifikationsprozess für Softwaremodule (Software Units). Demnach hat der Hersteller Strategien, Methoden und Prozeduren für die Verifikation einer jeden Software Unit einzurichten. Die Norm fordert zudem, dass ein Hersteller soweit erforderlich Akzeptanzkriterien für Software Units festzulegen hat, bevor die Inte-
gration in Software Items erfolgt. Zudem muss er sicherstellen, dass die Software Units diese Akzeptanzkriterien erfüllen und der Softwarecode den Programmierprozeduren oder Codierstandards entspricht.

Sofern im Design weitere Akzeptanzkriterien vorhanden sind, muss der Hersteller diese soweit erforderlich für Folgendes einbeziehen: korrekte Ereignisabfolge, Daten- und Kontrollfluss, geplante Ressourcenzuweisung, Fehlerbehandlung (Definition, Isolation und Behebung von Fehlern), Initialisierung von Variablen, Selbstdiagnose, Speichermanagement und -überläufe sowie Randbedingungen.

Viele dieser Akzeptanzkriterien eignen sich für statische Analysetools oder Static Application Security Testing (SAST). Da diese Argumente für die statische Analyse sprechen, hat die FDA Codesonar zur Analyse von Medizingerätesoftware verwendet, um nach einer Reihe von Ausfällen von Infusionspumpen die Qualität des Quellcodes zu überprüfen.

Codeanalysen per SAST

SAST-Tools helfen in der Codierungs- und Integrationsphase der Entwicklung. Indem man die Qualität des Codes in der Entwicklungs- und Wartungsphase fortlaufend gewährleistet, senkt man die Kosten und Risiken durch Security- und Qualitätsprobleme in Software. Die Tools bieten verschiedene Vorteile der statischen Analyse. Sie findet beispielsweise Fehler, die auf Coverage basierenden Techniken entgehen.

Modultests werden oft nach dem Umfang ihrer Überdeckung, etwa Anweisungs- oder Entscheidungsüberdeckung, beurteilt. Dennoch bleiben dabei viele Fehler unentdeckt, welche die statischen Analysetools jedoch erkennen. Zudem detektieren sie Fehler frühzeitig. Sie kommen darüber hinaus mit sogenannter Software of Unknown Pedigree/Provenance (SOUP) zurecht, die in Medizingerätesoftware einen besonderen Umgang verlangt. Gute statische Analyse-Tools können die Qualität und Sicherheit von Software von externen Zulieferern sowie von kommerzieller Off-the-Shelf-Software beurteilen, einschließlich rein binär vorliegender Executables und Bibliotheken.

Die statische Analyse beschleunigt darüber hinaus die Dokumentation für die Freigabe vor dem Inverkehrbringen. Das Dokumentieren der Ergebnisse von Softwaremodul-Akzeptanzprüfungen ist entscheidend für den Nachweis der Konformität zu Zertifizierungsstandards. Mit Reportfunktionen erleichtert sie die Erfüllung der FDA-Vorschriften.

Security ist heute ein vorrangiger Risiko- und Haftungsfaktor bei der Entwicklung von Medizingerätesoftware. Nicht nur die FDA, sondern auch bewährte Verfahrensweisen verlangen, dass der Security-Aspekt frühzeitig in ein Produkt eingebaut wird. SAST-Tools spielen eine wichtige Rolle beim Beschleunigen der Markteinführung von Medizingeräten und unterstützen die Freigabeprozesse vor dem Inverkehrbringen.

Bildergalerie

  • Einbindung von Security-Prozessen in den Software Development Lifecycle

    Einbindung von Security-Prozessen in den Software Development Lifecycle

    Bild: Grammartech

  • Während die Eliminierung eines einzelnen Fehlers in der Entwicklung rund fünf Stunden dauert, ist der Aufwand bei einem Fehler in der Produktions­umgebung durchschnittlich dreimal so hoch. Das belegt eine Studie des National Institute of Standard Technology aus dem Jahr 2002.

    Während die Eliminierung eines einzelnen Fehlers in der Entwicklung rund fünf Stunden dauert, ist der Aufwand bei einem Fehler in der Produktions­umgebung durchschnittlich dreimal so hoch. Das belegt eine Studie des National Institute of Standard Technology aus dem Jahr 2002.

Firmen zu diesem Artikel
Verwandte Artikel