Sicherheitstipps für Medizingeräte-Software

Sicherheitskritische Software, wie sie für Medizingeräte erforderlich ist, stellt strenge Anforderungen an die statische und dynamische Code-Analyse.

Die dynamische Analyse untersucht den laufenden Code und zeigt Codeabdeckung, Eignung und Qualität der Unit-Tests sowie Speicherlecks und andere potenzielle Schwachstellen auf. Demgegenüber interpretiert die statische Analyse den Quellcode als Text und zielt alle Schlussfolgerungen auf der Grundlage der Parser-Ausgabe, ohne eine einzige Anweisung auszuführen. Sie prüft automatisch, ob bekannte Richtlinien (z.B. MISRA, CERT, AUTOSAR, JSF) eingehalten werden, und erkennt potenzielle Fehler wie Null-Zeiger-Dereferenzierung, Division durch Null und Pufferüberläufe. Moderne statische Analysetools ergänzen die gängigen Codereviews und reduzieren dadurch den manuellen Aufwand um mindestens 30%.

Tipp 1: Der Compiler ist Ihr Freund

Üblicherweise nutzen Entwicklungsteams bei der Kompilierung -Wall und -Werror (in GCC) oder /Wall /WX (in Visual Studio) oder bei anderen Compilern ähnliche Optionen. Über das Beheben von Compiler-Warnungen kann man sich auf einfache und kostengünstige Weise auf die Ausführung der statischen Analyse vorbereiten. Die Überprüfung der Ausgabe Ihres Compilers in einem „Paranoid“-Modus kann das Gesamtvolumen der aufgedeckten Regelverletzungen verringern. Auch wenn gut ist, alle Compiler-Warnungen zu beheben, gibt es viele Projekte, bei denen der Einsatz von nur einem Compiler aus Konformitätsgründen nicht ausreicht und keine akzeptable Option darstellt. Dann empfiehlt sich der Einsatz von statischen Analysetools, die viel tiefer in den Code eindringen und deutlich mehr Hinweise liefern.

Tipp 2: Früh im Prozess auf die statische Analyse setzen

Als Entwickler von Software für medizinische Geräte sollten Sie sich mit der automatisierten statischen Code-Analyse beschäftigen. Denn sie ist fast garantiert Gegenstand einer Diskussion während eines internen/externen Audits oder einer Einreichung vor der Markteinführung. Das Tool muss so eingesetzt werden, dass die Entwicklung nicht an Geschwindigkeit verliert, während Sie an der Verbesserung der Qualität arbeiten, und dass Sie Ihre Zeit nicht mit Eigenheiten und Noise des Werkzeugs verschwenden. Viele Verstöße bei bestehendem Code können Sie beiseitelegen und zu einem späteren Zeitpunkt bearbeiten. Allerdings dürfen Sie bei der Entwicklung von Code keine neuen Verletzungen (technische Schuld) hinzufügen. Bei modernen Tools wie Parasoft C/C++test können Entwickler mit speziellen Funktionen den Noise herausfiltern und sich so auf das Beheben der Regelverletzungen im Zuge der letzten statischen Analyse konzentrieren.

Tipp 3: Flexibilität betreffend Laufzeitumgebung

Meistens halten Hersteller eine bestimmte Kapazität für Updates und Wartung der Software frei. Allerdings ist diese Leistung manchmal nicht ausreichend für die Instrumentalisierung der Software für die dynamische Analyse, weil dieser Vorgang enorm viel RAM-Kapazität und Speicherplatz zum Ablegen der Test- und Code-Abdeckungsergebnisse verschlingt. Ist der Speicher auf dem Gerät zu klein, um Tests auszuführen und die Code-Abdeckung zu erfassen, ist die Zielplattform möglicherweise ungeeignet. Wird die Hauptzielplattform nicht standardmäßig unterstützt, sollten Sie nach passenden Alternativen suchen. Vielleicht gibt es eine verwandte Plattform mit mehr Schnittstellen und Speicher? Oder der Einsatz von Hardware-Simulatoren, auf denen ARM Fast Models und QEMU laufen können?

Im Idealfall werden die Tests auf der Zielplattform ausgeführt. Trotzdem lassen Teams oft Unit- und bestimmte Anwendungsintegrationstests auf der Workstation des Entwicklers (wie Linux, Mac, Windows) laufen. Hierbei profitieren sie von einem schnelleren Entwicklungszyklus und davon, dass für allgemeine Entwicklungsplattformen mehr Tools zur Verfügung stehen. In diesem Fall ist es notwendig, den embedded Code zur Kompilierung mit einem Host-Compiler zu portieren – das kann Herausforderungen mit sich bringen. Es gibt eine Fülle an Compilern, Build-Tools, Frameworks und Methoden zu deren Ausführung. Dynamische Analysetools unterstützen einige gängige Build-Techniken mit internen Annahmen darüber, wie Entwickler sie anwenden könnten. Selbst bei portablem Code wird also das Entwicklungsteam zusätzliche Zeit benötigen, um die Einstellungen eines dynamischen Analysetools anzupassen – je nachdem, wie das Build-System des Projekts funktioniert.

Tipp 4: Autogenerierte Testfälle nicht überbewerten

Für eine höhere Codeabdeckung erstellen moderne dynamische Analysetools automatisch Sätze von Unit-Tests. Aber Tools sind eben nur Tools und agnostisch gegenüber verschiedenen Szenarien zum Einsatz des Codes. Sie müssen die generierten Unit-Tests immer noch manuell aktualisieren und sogar neu schreiben, weil nur Sie wissen, wie sich der Code verhalten soll, wenn es um positive und negative Testergebnisse geht. Zudem können auf Basis des Quellcodes autogenerierte Unit-Tests oft perfekt auf einem fehlerbehafteten Code laufen. Darum sollten Sie die automatische Testgenerierung als Ausgangsbasis für die Unit-Tests einsetzen. Weil das manuelle Erstellen von Testfällen eine zusätzliche Code-Überprüfung erzwingt und einen anderen Blickwinkel auf den Entwurf bietet, verbessert es die Codequalität.

Tipp 5: Aufwand für die Tool-Qualifizierung /-Validierung im Auge behalten

Nach Vorgaben der FDA muss jedes Werkzeug, das während der formellen Entwicklung zum Einsatz kommt, für die beabsichtigte Verwendung geeignet sein, um sicherzustellen, dass es die erwarteten Aktionen ausführt und die korrekten Ergebnisse liefert. Normalerweise handelt es sich dabei um ein spezielles Testprotokoll namens IUV (Intended Use Validation).

Branchenführende Anbieter von statischen und dynamischen Analysetools minimieren den Aufwand durch Support beim Erstellen der notwendigen Abläufe und Dokumentationen. Besonders vorteilhaft sind moderne Lösungen, die einen Großteil des Prozesses automatisieren. Auch hier sollten Sie sich, wie bei jedem anderen generischen Paket, einen Teil des Aufwands für die Überprüfung und Anpassung von Dokumenten vorbehalten, um sie mit den eigenen QMS-Verfahren zu synchronisieren. Zum Beispiel hält die Tool Qualification Software von Parasoft eine Reihe von Testfällen bereit, die in der eigenen Umgebung ausgeführt werden müssen, um die statischen und dynamischen Analysefähigkeiten zu validieren.

Mit diesen Tipps sollte Ihr Unternehmen gut gerüstet sein für höhere Ansprüche an die Software durch Cybersecurity, nachfolgend noch einmal die Zusammenfassung:

1. Behandeln Sie Compilerwarnungen als Fehler. Warnungen können bei einer neueren Version desselben Compilers zu Fehlern werden. Oft bedeuten Warnungen, dass der Compiler implizit etwas Bestimmtes tut.
2. Lassen Sie die statischen Analysetools in einer frühen Phase des Projekts laufen und beheben Sie etwaige Probleme, sobald diese auftreten.
3. Sorgen Sie dafür, dass der Code portierbar bleibt. Auch wenn Sie eigentlich nicht vorhaben, Ihren Code auf eine andere Plattform zu portieren, könnte dies irgendwann in der Zukunft eine Option sein. Abgesehen davon trägt dies dazu bei, Ihren Code sauber, pflegbar und lesbar zu halten, was auf jeden Fall günstig für die Prüfung und den weiteren Support ist.
4. Verlassen Sie sich zur Verbesserung der Codequalität nicht übermäßig auf automatisch generierte Testfälle.
5. Unterschätzen Sie die Notwendigkeit, das Tool für einen bestimmten Verwendungszweck zu validieren und den da für entstehenden Aufwand nicht.

Autor:

Andrey Shastin, Head of Global Business Medical und Embedded Systems bei Auriga

Dieser Artikel erschien in der Ausgabe 2/21 der MED engineering