AAMI TIR57 – Cybersecurity-Risikomanagement für Medizingeräte

Daniel Saffer

31/05/2021

Update-Hinweis (23. Mai 2025)

Dieser Beitrag basiert auf der AAMI TIR57:2016. Einem wichtigen Leitfaden für das Risikomanagement von Cybersicherheit in Medizinprodukten. Seit 2023 wurde der TIR57 durch den neuen Standard ANSI/AAMI SW96:2023 ergänzt, die die Inahlte formalisiert und erweitert.

Die wichtigsten Neuerungen:

  • SW96 definiert verbindliche Anforderungen an das Cybersecurity-Risikomanagement für Medizinprodukte
  • TIR 57 bleibt als unterstützendes Dokument gültig
  • Parallel rückt in der EU die IEC 81001-5-1 als zentraler Cybersecurity-Standard in den Fokus (von der FDA anerkannt)

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:

  1. den Security-Risikomanagementplan
  2. die Security-Risikoanalyse (inkl. Security-Maßnahmen)
  3. 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/.


Geschrieben von Daniel Saffer

Daniel Saffer ist Chief Technical Officer (CTO) der MEDtech Ingenieur GmbH. In dieser Rolle verantwortet er die technische Strategie des Unternehmens und unterstützt Kundenprojekte in der Medizintechnik. Sein Fokus liegt auf der Weiterentwicklung sicherheitskritischer Softwarelösungen, regulatorischen Anforderungen und innovativen Technologien für die Branche.


Weitere Beiträge

  • 30/01/2024
  • Allgemein, Security, Software, Usability

Wo ist denn jetzt wieder dieses Headset? Wer kennt es nicht, man möchte sein Smartphone mit einem Bluetooth-Gerät verbinden, startet den Suchvorgang und plötzlich sieht man den Wald vor ...

Weiterlesen
  • 04/09/2023
  • Allgemein, Normen, Qualität, Testen

Um eine hohe Produktqualität zu gewährleisten und Kunden zufriedenzustellen, müssen Qualitätsprobleme frühzeitig erkannt, analysiert und behoben werden. Hier ist CAPA ein bewährtes Instrument, um Unternehmen dabei zu unterstützen, die ...

Weiterlesen
  • 31/10/2022
  • Dokumentation, Normen, Security, Systems Engineering

In der Medizintechnik können technische Fehler in einem Gerät fatale Folgen für Bediener oder Patienten haben. Daher wird bei der Zulassung des Medizinprodukts auch generell eine Sicherheitsarchitektur gefordert. Wichtig ...

Weiterlesen
Cookie-Übersicht

Die Internetseiten der MEDtech Ingenieur GmbH verwenden Cookies. Cookies sind Textdateien, welche über einen Internetbrowser auf einem Computersystem abgelegt und gespeichert werden.

Zahlreiche Internetseiten und Server verwenden Cookies. Viele Cookies enthalten eine sogenannte Cookie-ID. Eine Cookie-ID ist eine eindeutige Kennung des Cookies. Sie besteht aus einer Zeichenfolge, durch welche Internetseiten und Server dem konkreten Internetbrowser zugeordnet werden können, in dem das Cookie gespeichert wurde. Dies ermöglicht es den besuchten Internetseiten und Servern, den individuellen Browser der betroffenen Person von anderen Internetbrowsern, die andere Cookies enthalten, zu unterscheiden. Ein bestimmter Internetbrowser kann über die eindeutige Cookie-ID wiedererkannt und identifiziert werden.

Durch den Einsatz von Cookies kann die MEDtech Ingenieur GmbH den Nutzern dieser Internetseite nutzerfreundlichere Services bereitstellen, die ohne die Cookie-Setzung nicht möglich wären.

Mittels eines Cookies können die Informationen und Angebote auf unserer Internetseite im Sinne des Benutzers optimiert werden. Cookies ermöglichen uns, wie bereits erwähnt, die Benutzer unserer Internetseite wiederzuerkennen. Zweck dieser Wiedererkennung ist es, den Nutzern die Verwendung unserer Internetseite zu erleichtern. Der Benutzer einer Internetseite, die Cookies verwendet, muss beispielsweise nicht bei jedem Besuch der Internetseite erneut seine Zugangsdaten eingeben, weil dies von der Internetseite und dem auf dem Computersystem des Benutzers abgelegten Cookie übernommen wird.

Die betroffene Person kann die Setzung von Cookies durch unsere Internetseite jederzeit mittels einer entsprechenden Einstellung des genutzten Internetbrowsers verhindern und damit der Setzung von Cookies dauerhaft widersprechen. Ferner können bereits gesetzte Cookies jederzeit über einen Internetbrowser oder andere Softwareprogramme gelöscht werden. Dies ist in allen gängigen Internetbrowsern möglich. Deaktiviert die betroffene Person die Setzung von Cookies in dem genutzten Internetbrowser, sind unter Umständen nicht alle Funktionen unserer Internetseite vollumfänglich nutzbar.

Weitere Informationen erhalten Sie in unserer Datenschutzerklärung.

Unbedingt notwendige Cookies

Dieses Cookie wird benötigt, um Ihre Cookie-Einstellungen zu merken und weitere Hauptfunktionen zur Verfügung zu stellen

Um Ihnen eine Auskunft über Ihre gespeicherten personenbezogenen Daten hier (https://medtech-ingenieur.de/gespeicherte-daten-2/) geben zu können, benötigen wir einen Cookie, um Sie bei der Datenabfrage identifizieren zu können. Dieser Cookie muss aus Sicherheitsgründen deshalb aktiviert sein. Ein weiterer Cookie wird gesetzt, um diesen Banner nicht erneut anzeigen zu müssen.

Cookie-Name Beschreibung
PHPSESSID Name: PHP session
Anbieter:
Eigentümer der Webseite (MEDtech Ingenieur)
Zweck:
Wir benötigt, um Sie bei der Anfrage von personenbezogenen Daten identifizieren zu können. Das Cookie wird nur gesetzt, wenn Sie eine Anfrage hier (https://medtech-ingenieur.de/gespeicherte-daten-2/) stellen.
Laufzeit: Sitzungsende
Kategorie: Unbedingt notwendige Cookies
moove_gdpr_popup Name: Cookie-Box Einstellungen
Anbieter:
Eigentümer der Webseite (MEDtech Ingenieur)
Zweck:
Wird benötigt, um Ihre Cookie-Einstellungen zu speichern, um den Cookie-Banner nicht erneut anzeigen zu müssen.
Laufzeit: 1 Jahr
Kategorie: Unbedingt notwendige Cookies
comment_author_9c90e388e3e1be4a6c594fa6ac8a3eec
comment_author_email_9c90e388e3e1be4a6c594fa6ac8a3eec
comment_author_url_9c90e388e3e1be4a6c594fa6ac8a3eec
Name: Kommentar Einstellungen
Anbieter:
Eigentümer der Webseite (MEDtech Ingenieur)
Zweck:
Cookie wird angelegt, wenn Sie ein Kommentar auf MEDtech Ingenieur veröffentlichen wollen, um Sie als Autor identifizieren und den aktuellen Status Ihres Kommentars anzeigen zu können. Das Cookie enthält den angegebenen Namen. Das Cookie wird erst gesetzt, wenn Sie der Speicherung Ihrer personenbezogenen Daten zustimmen.
Laufzeit: 1 Jahr
Kategorie: Unbedingt notwendige Cookies
rmp-rate Name: RMP Rate
Anbieter: Eigentümer der Webseite (MEDtech Ingenieur)
Zweck: Cookie wird angelegt, wenn Sie eine Bewertung eines Blogbeitrags mithilfe des Sternebewertungssystems abgeben. Ihnen wird eine anonymisierte ID zugewiesen, um zu erkennen, ob Sie einen Artikel bereits bewertet haben oder nicht. Das Cookie wird nur verwendet, um zu verhindern, dass mehrfache Bewertung abgegeben werden und erst gesetzt, wenn Sie auf einen Stern klicken.
Laufzeit: 1 Jahr
Kategorie: Unbedingt notwendige Cookies
medtech-download-page Name: Download Page
Anbieter: Eigentümer der Webseite (MEDtech Ingenieur)
Zweck: Cookie wird angelegt, wenn Sie den Landing-Page Prozess erfolgreich durchlaufen haben. Dies geschieht nur, wenn Sie einen Content-Download von unserer Website anstreben.
Laufzeit: 1/2 Jahr
Kategorie: Unbedingt notwendige Cookies