Cybersecurity
Zukunftssichere Medizingeräte mit starker Abwehr
Wie Medizingeräte-Software Sicherheitsstandards erfüllt
Mit dem Einzug der Digitalisierung in die Medizinbranche rückt die Sicherheit von Software für die verschiedenen Geräte in den Fokus. Damit die Software-Sicherheit gewährleistet ist, müssen strenge Standards für Entwicklung und Wartung erfüllt werden. Hersteller von Medizingeräten sind zusehends gefordert, um die steigenden Sicherheitslücken abzudecken und die Anforderungen der Normen zu erfüllen. Hier bietet die statische Analyse Unterstützung, um vorhersagbare Software auszuliefern.
Während in den USA die Food- and Drug Administration (FDA) tonangebend für den Medizinbereich ist, legt im Europäischen Medizingeräte-Markt die internationale Norm IEC 62304 die Anforderungen an Software-Lebenszyklus-Prozesse für die Entwicklung von Software für medizinische Geräte und medizinischer Software fest. Sie enthält die Anforderungen an Software-Lebenszyklus-Prozesse für die Entwicklung von Software für medizinische Geräte und medizinischer Software. Die in der Norm definierten Prozesse, Aktivitäten und Aufgaben bilden einen gemeinsamen Handlungsrahmen für alle Lebenszyklusprozesse für Software in Medizinprodukten.
Dazu führt die IEC 62304 verschiedene Maßnahmen ein, um einen ordnungsgemäßen Software-Entwurf, die Implementierung und das Testen abhängig von den möglichen Auswirkungen des Softwarefehlers auf den Patienten zu gewährleisten. Die FDA akzeptiert die Einhaltung der IEC 62304 als Nachweis dafür, dass Software für medizinische Geräte gemäß den erforderlichen Vorschriften/Normen entwickelt wurde, da sie die Rückverfolgbarkeit und Wiederholbarkeit des Entwicklungs- und Wartungsprozesses durchsetzt.
Sicherheitsklassen der IEC 62304
In der IEC 62304 heißt es: Der Hersteller weist jedem Software-System eine Software-Sicherheitsklasse entsprechend den möglichen Auswirkungen auf den Patienten, den Anwender oder andere Personen zu, die sich aus einer Gefahr (die eine potentielle Gefahrenquelle darstellt) ergibt, zu der das Software-System beitragen kann. Hersteller sind verpflichtet, das zu erstellende System in eine der drei Sicherheitsklassen für Software-Sicherheitsstufen einzustufen, die durch die Norm eingeführt wurden:
- Klasse A: Es sind keine Verletzungen oder Gesundheitsschäden möglich
- Klasse B: Nicht-schwere Verletzungen sind möglich
- Klasse C: Tod oder schwere Verletzung ist möglich
Die steigende Funktionalität von Wireless-, internetfähigen und vernetzten Geräten sowie tragbaren Mediengeräten (USB, CD, etc.) im Medizinbereich und der rege elektronische Austausch von medizinischen Gesundheitsinformationen treiben die Anforderungen an die Sicherheit voran. Waren diese bei medizinischen Standards in punkto Testen lange nicht sehr spezifisch, ist nun die Definition und Befolgung eines statischen Analyseprozesses notwendig, wie es auch die FDA in ihrem neuen Standard, der für 2022 erwartet wird, empfiehlt. Auch wenn sie zunächst Entwicklerzeit beansprucht und Kosten verursacht, ist die statische Analyse eine bewährte Möglichkeit, das System gegen böswillige Attacken abzusichern. Installiert der Hersteller sie mit einer sorgfältig ausgearbeiteten Reihe von Security-Richtlinien, lassen sich Systeme einrichten, die unvorhergesehenen künftigen Attacken standhalten.
Integration und Anpassung
Bei der Definition hängt vieles von den bestehenden Abläufen im Unternehmen und die für die Entwicklung eingesetzten Technologien ab. Beginnt ein Medizingeräte-Hersteller auf der »Grünen Wiese«, können nachfolgende Tipps vorteilhaft für die Einführung der statischen Analyse für C/C++ sein:
- Bestehende Richtlinien im Unternehmen überprüfen: Auch wenn diese für die manuelle Durchsetzung bestimmt sind, sollten sie so weit wie möglich an die zum statischen Analysetool gehörenden Checker übertragen werden. Ein ausgereiftes statisches Analysetool sollte diese Richtlinien zum größten Teil abdecken. Für die verbliebenen Richtlinien könnten kundenspezifische Checke in Frage kommen.
- Kontrolle der gängigen Codierstandards: Das gilt insbesondre für die auf Security ausgerichteten Richtlinien sowie einer Teilmenge an Richtlinien, die vom Team zu befolgen sind. Dabei ist es sinnvoll, die Kategorisierung der Standards zu übernehmen und jene Richtlinien auszuwählen, die als die wichtigsten eingestuft werden. Es macht beispielsweise Sinn, bei den CERT-Richtlinien mit den L1-Richtlinien zu beginnen, und bei MISRA C2012 (mit Amendment 1) mit der Prüfung der zwingend vorgeschriebenen Richtlinien.
- Analysetools definieren und unternehmensspezifische Richtlinien einbinden: Nicht alle Checker sollten sofort aktiviert werden. Besser ist es, mit einem kleinen Teil anzufangen, damit die Entwickler nicht vor einer Unmenge an Regelverletzungen stehen.
- Statische Analyse in CI/CD-Prozess aufnehmen: Hersteller sollten sicherstellen, dass die Entwickler ihren Code unmittelbar nach dessen Erstellung scannen können. Es ist auch zweckmäßig, die statische Analyse in den CI/CD-Prozess aufzunehmen.
- Bereinigung und zusätzliche Checker aktivieren: Letztlich geht es um den Nachweis, dass nicht nur eine Teilmenge, sondern alle ausgewählten Richtlinien erfüllt werden. Um sich in dem Ablauf besser orientieren und den aktuellen Fortschritt verstehen zu können, empfiehlt sich ein zentrales Berichtssystem, das bei der Zusammenfassung der Testdaten und der Überwachung der Arbeit der Entwickler hilft.
Eignungsnachweis und Konformitätsprüfung
Weil die Reports der statischen Analyse in das Qualitätsmanagement-Systems einfließen, lässt sich nicht irgendein beliebiges Tool nutzen. Sondern gemäß IEC 62304 müssen sämtliche zur Entwicklung und Verifikation der Software eingesetzten Werkzeuge für ihren Verwendungszweck validiert sein. Ob ein Tool für sicherheitskritische Entwicklungen geeignet ist, lässt sich auf unterschiedliche Art nachweisen. Abhängig vom Risikoniveau des jeweiligen Geräts reicht entweder die Weitergabe eines Konformitätszertifikats aus, oder es muss eine langwierigere Tool-Qualifikation durchlaufen werden.
Am einfachsten und zweckmäßigsten ist es, auf die Vorarbeit des Anbieters zurückzugreifen und ein bereits zertifiziertes Testwerkzeug zu nutzen. Die Konformität mit IEC 62304 verlangt den Aufbau solider Softwareentwicklungs- und Testprozesse, die mit mehreren Tools unterstützt werden. Unternehmen benötigen für Verifizierungs- und Validierungsarbeiten ein Tool, die mehrere Testmethoden umfasst, da es nicht »die eine« Technik gibt, die zur Konformität führen kann.
Parasoft C/C++ test: Software-Testverfahren automatisieren
Hier setzt Parasoft C/C++test an. Dabei handelt es sich einen integrierten Satz von Werkzeugen zum Testen von C- und C++-Quellcode, den Softwareentwickler verwenden, um ihre Anwendungen zu analysieren, zu testen, Fehler zu finden und die Qualität und Sicherheit ihrer Anwendungen zu messen. Damit ist es möglich, ein breites Spektrum Software-Testverfahren zu automatisieren, die Effizienz zu steigern sowie die Ergebnisse zu verbessern. Dadurch verringern sich Zeit und Aufwand zum Erreichen der IEC 62304-Konformität.
Weitere Informationen finden Sie unter www.parasoft.com/products/ctest
Der Autor: Miroslaw Zielinski ist Principal Software Engineer bei Parasoft
Lesen Sie mehr zum Thema
