Die AAMI TIR 57 ist ein Technical Information Report (TIR). Er soll Medizingerätehersteller dabei unterstützen, die Cybersecurity-Risiken ihrer Medizingeräte zu detektieren und zu beheben, um die Vertraulichkeit, die Verfügbarkeit und die Integrität gewährleisten zu können. Um dieses Ziel zu erreichen, gibt das Guidance-Dokument einige Vorschläge, wie Sie einen Cybersecurity-Risikomanagementprozess in Ihrem Unternehmen einführen können. Die AAMIT TIR 57 ist nicht verbindlich. Es wird jedoch z. B. von der MDR gefordert, dass Risiken gemäßt dem Stand der Technik durch die Hersteller identifiziert werden müssen, weshalb sich ein Blick in das Dokument lohnen kann. Cybersecurity ist (nicht nur) in der Medizintechnik eine immer wichtiger werdende Thematik, da Medizintechnikgeräte immer mehr vernetzt werden und der Lebenszyklus dieser Geräte über eine Dekade hinweg gehen kann.
Die AAMI TIR 57 hat die gleiche Basisstruktur, wie der bereits vertraute Standard ISO 14971 und schlägt einen eigenen Prozess für Security-Risiken vor, der sich stark am (Safety-)Risikomanagementprozess orientiert. Wird in diesem Blog-Beitrag von Sicherheit in Zusammenhang mit der AAMI TIR 57 gesprochen, ist immer die Cybersecurity gemeint. Leider ist an dieser Stelle die deutsche Sprache nicht präzise genug und unterscheidet nicht wie das Englische zwischen „Safety“ und „Security“.
Vergleicht man die beiden Kapitelstrukturen der AAMI TIR 57 mit der ISO 14971 miteinander, so fällt die Analogie deutlich auf.
Auch die Definitionen der AAMI TIR 57 sind nahezu identisch zur ISO 14971. Ein Beispiel hierfür ist die Definition für „Harm“ (z. dt. Schaden).
Definition „Harm“ der ISO 14971:
physical injury or damage to the health of people, or damage to property or the environment
Definition „Harm“ der AAMI TIR 57:
physical injury or damage to the health of people, or damage to property or the environment, or reduction in
effectiveness, or breach of data and systems security
Die AAMI TIR 57 ergänzt hier die Definition um zwei wichtige Punkte:
- die Reduktion der Effektivität des Medizingeräts und
- die Verletzung der Daten und Systemsicherheit.
In den folgenden Kapiteln möchte ich Ihnen kurz zeigen, wie die empfohlene Security-Risikomanagementakte aufgebaut ist und auf welche Inhalte ein besonderes Augenmerk zu legen ist.
Security-Risikomanagementakte
Die Security-Risikomanagementakte ist analog zur Risikomanagementakte der ISO 14971 aufgebaut. Die Inhalte umfassen mindestens:
- den Security-Risikomanagementplan
- die Security-Risikoanalyse (inkl. Security-Maßnahmen)
- den Security-Risikomanagementreport
Die einzelnen Punkte werden in den nächsten Kapiteln näher beschrieben.
Security-Risikomanagementplan
Das Security-Risikomanagement muss Teil des Risikomanagementprozesses des Medizintechnikherstellers sein. Der Security-Risikomanagementprozess kann in den allgemeinen Risikomanagementprozess integriert oder als begleitender Prozess gehandhabt werden. Die AAMI TIR 57 empfiehlt den Prozess auszulagern. An dieser Stelle ist auch festzuhalten, dass Cybersecurity-Risiken, die sich auf die Safety auswirken, auch im Safety-Risikomanagement berücksichtigt werden müssen.
Im Security-Risikomanagementplan muss festgelegt werden, mit welchem Umfang Security-Risikomanagementaktivitäten durchgeführt werden. Um die Aktivitäten festlegen zu können, muss die generelle Beschreibung des Medizingeräts, sprich in welchem Kontext (Betriebsumgebung) agiert das Medizingerät, die System Architektur und der Intented Use bekannt sein. Definieren Sie diese oder referenzieren Sie auf die erstellten Dokumente.
Cybersecurity ist ein nie endender Prozess. Während der Lebenszeit des Systems können sich Bedrohungen ändern und neue Schwachstellen entdeckt werden. Grund hierfür sind eigene Softwarekomponenten oder die verwendete SOUP (Source of Unkown Provenance). Mit SOUP ist Software gemeint, die nicht für den Einsatz in Medizingeräten entwickelt wurde, aber frei zugänglich ist. Das kann z. B. der Hardware Abstraction Layer (HAL) von einem Mikrocontroller-Hersteller sein. Definieren Sie deshalb auch im Plan, wie Sie nach der Inverkehrbringung des Medizingeräts neue Bedrohungen und Schwachstellen überwachen, berichten, analysieren und beheben. Einer der wichtigsten Punkte ist deshalb, einen sicheren Update-Prozess zu haben, um Schwachstellen im Feld schließen zu können.
Des Weiteren müssen Sie Kriterien für die Risikobewertung, die Auswirkungsanalyse und die Akzeptanz des Restrisikos dokumentieren.
Der Plan muss auch Methoden beschreiben, die während der Entwicklung eingesetzt werden, für die Security-Risikoverifikation verwendet werden und beschreiben, wie Informationen nach der Inverkehrbringung gesammelt werden, um Bedrohungen und Schwachstellen zu erkennen.
Beispiele für Methoden, die während der Entwicklung zum Einsatz kommen, um die Wahrscheinlichkeit von unbeabsichtigten Funktionen in der Software zu verringern sind zum Beispiel Code Reviews, statische Code Analyse, Unit Tests und Continuous Integration.
Beispiele für Methoden zur Security-Risikoverifikation sind das Fuzzing, das Penetration Testing oder das Verification Testing von Cybersecurity Kontrollmaßnahmen.
Informationen können nach der Inverkehrbringung auf verschiedene Arten gesammelt werden. Sie können sich in Vulnerability Datenbanken informieren, z. B. der National Vulnerability Database (NVD, „https://nvd.nist.gov/„) oder ein sogenanntes Intrusion Detection System (Angriffserkennungssystem) in Ihrem Medizingerät implementieren, das Angriffe sammelt und in Log-Dateien abspeichert. Die Informationen können dann den Benutzern oder Ihnen mitgeteilt werden.
Security-Risikoanalyse
Die Security-Risikoanalyse ist ein sehr komplexer iterativer Prozess, bei dem viel Fachwissen benötigt wird. Hier ist es wichtig, wie ein Angreifer zu denken. Welche Motivation hat ein Angreifer, das Medizingerät zu hacken? Will er sich bereichern? Macht er es nur aus Spaß? Will er dem Unternehmen oder dem Patienten Schaden zuführen? Denken Sie immer daran, dass Sie einen Cybersecurity-Experten für die Analyse benötigen, um alle Risiken detektieren und richtig bewerten zu können.
Bevor Sie mit der Risikoanalyse starten können, wird einiges an Input benötigt. Neben den allgemeinen Informationen, die Sie bereits im Risikomanagementplan gesammelt haben, ist es wichtig zu überprüfen, ob es bereits Security-Risiken von vergleichbaren Medizinprodukten gibt. Entwickeln Sie z. B. eine Insulinpumpe, stoßen Sie relativ schnell auf eine Sicherheitslücke eines bekannten Geräts, bei dem es möglich ist, hohe Medikamentendosen zu verabreichen. Analysieren Sie, warum diese Sicherheitslücke aufgetreten ist und wie Sie vermieden werden kann. Danach sollten Sie die gewonnenen Erkenntnisse auf Ihr Medizingerät reflektieren und überprüfen, ob diese Sicherheitslücke ebenfalls auftreten könnte. Analysieren Sie auch, ob es bestimmte Konfigurationen gibt, die vom Benutzer vorgenommen werden müssen, damit das Gerät sicher ist. Welche SOUP verwenden Sie in Ihrer Software. Erstellen Sie hierfür eine Cybersecurity Bill of Material (CBOM) und analysieren Sie mögliche Schwachstellen mit der bereits genannten NVD.
Mithilfe eines Threat-Modells können Sie Bedrohungen gut ausarbeiten. Dieses empfiehlt sich ebenfalls als ein guter Einstieg. An dieser Stelle ist auch das STRIDE Modell von Microsoft (https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling) zu erwähnen, welches sehr interessant und hilfreich ist.
Durch diese Vorarbeit können Sie die Bedrohungen, Schwachstellen, Assets und negativen Auswirkungen (Adverse Impact) im Security-Risikoanalyse Dokument festhalten.
Im nächsten Schritt erfolgt die Risikobewertung. Hier wird festgehalten, wie hoch das Risiko ist und ob Security-Maßnahmen notwendig sind. Analysieren Sie auch ob die eingeführten Security-Maßnahmen zu neuen Safety-Risiken führen. Die Risikobewertung erfolgt ähnlich der ISO 14971.
Halten Sie auch fest, wer bei der Risikoanalyse beteiligt war, wann Sie durchgeführt wurde und welche Systembestandteile genau analysiert wurden.
Die gefundenen Security-Maßnahmen müssen nun in Ihr Requirementmanagement zurückgeführt werden und die sich daraus ergebenden Änderungen müssen implementiert, verifiziert und validiert werden.
Security-Risikomanagementreport
Zum Schluss möchte ich noch zeigen, was inhaltlich im Security-Risikomanagementreport festgehalten wird.
Fassen Sie nochmal die gewonnenen Erkenntnisse der Risikoanalyse zusammen und beschreiben Sie den Intended Use und den Systemkontext. Die Erkenntnisse der Risikoanalyse sind die gefundenen Schwachstellen, die zu schützenden Assets und der Schaden, der bei einem erfolgreichen Angriff (Kompromittierung) entstehen kann. Außerdem müssen Sie festhalten, welche Maßnahmen zu implementieren sind. Hier ist insbesondere auch die Traceability zwischen Risiko, Anforderung, Maßnahme und Verifikation wichtig.
Im Report ist auch festzuhalten, ob das Gesamt-Restrisiko des Systems akzeptabel ist und ob die getroffenen Maßnahmen somit ausreichend sind. Ausreichend bedeutet, dass der Stand der Technik berücksichtigt ist.
Zum Schluss müssen Sie noch beschreiben, wie sichergestellt werden kann, dass Ihr Medizingerät ohne Malware ausgeliefert wird und wie Update im Feld sicher durchgeführt werden kann. Können Updates durch den Benutzer eigenständig ausgeführt werden oder wird ein Servicetechniker benötigt? Kann die Update-Datei im Internet heruntergeladen werden? Wie schnell werden Patches bereitgestellt?
Fazit
Die AAMI TIR 57 kann Ihnen dabei helfen, einen Cybersecurity-Risikomanagementprozess in Ihrem Unternehmen zu etablieren. Vor allem die Anhänge können hier hilfreich sein. Es wird jedoch nicht gezeigt, wie Sie Threats, Vulnerabilities und Assets identifizieren und wie Sie diese beheben können. Ich hoffe, der Blog konnte Ihnen einen kurzen Einblick in die AAMI TIR 57 und die Erstellung der Security-Risikomanagementakte geben. Es ist sehr wichtig, die Security-Risiken Ihres Medizingeräts zu analysieren. Sollten Sie noch weitere Fragen zu dem Thema haben, können Sie uns gerne kontaktieren oder ein Kommentar hinterlassen.
Einen weiteren interessanten Artikel zum Thema Cybersecurity finden Sie hier: https://medtech-ingenieur.de/fda-cybersecurity-leitfaden-fuer-die-zulassung/.
