UPDATE

Ständig ändern sich Gesetze für Hersteller von Medizinprodukten.

Wir halten Sie 1x pro Woche kompakt auf dem Laufenden, damit Sie nichts verpassen

Jetzt eintragen

1x wöchentlich
kompakte Übersicht
Fachinformationen von Prof. Dr. Johner

Autor: Prof. Dr. Christian Johner

Inhaber der Johner Institut GmbH

AAMI TIR 57: IT-Sicherheit und Risikomanagement

Dienstag 24. Oktober 2017

Der TIR 57 ist ein „Technical Information Report“ der amerikanischen AAMI.

Er möchte Hilfestellung dabei geben, Risiken durch mangelnde IT-Sicherheit von Medizinprodukten zu erkennen und zu beherrschen und so die Anforderungen der ISO 14971 an das Risikomanagement zu erfüllen.

Inhaltsübersicht
Zusammenfassung »
Verbindlichkeit der TIR 57 »
Zusammenspiel mit ISO 14971 »
Fazit »

TIR 57: Zusammenfassung für eilige Leser

Der AAMI TIR 57 ist ein Guidance Document, das Herstellern zeigen möchte, wie sie die Anforderungen der ISO 14971 erfüllen können. Dazu benennt der TIR 57 für jedes Teilkapitel der ISO 14971 die notwendigen Tätigkeiten, um IT-Sicherheitsrisiken zu identifizieren, zu bewerten und zu beherrschen.

Der TIR 57 taucht nicht tief in die Technologie ab und bietet keine Anleitung, wie Hersteller beispielsweise Buffer-Overflow-Schwachstellen identifizieren oder in der Entwicklung von vorneherein vermeiden können.

Wenn Hersteller keinen dedizierten Risikomanagementprozess bzw. Risikomanagementplan für die IT-Sicherheit haben, empfiehlt es sich, diese Verfahrensanweisungen bzw. Pläne um die im TIR 57 genannten Aspekte zu ergänzen.

Verbindlichkeit des TIR 57

Der AAMI TIR 57 ist ein „Technical Information Report“ (TIR) und somit nicht per se verbindlich. Allerdings verlangen alle relevanten Vorschriften, dass Hersteller Risiken gemäß „Stand der Technik“ identifizieren. Die EU-Medizinprodukteverordnung MDR schreibt beispielsweise:

„Bei Produkten, zu deren Bestandteilen Software gehört, oder bei Produkten in Form einer Software wird die Software entsprechend dem Stand der Technik entwickelt und hergestellt, wobei die Grundsätze des Software-Lebenszyklus, des Risikomanagements einschließlich der Informationssicherheit, der Verifizierung und der Validierung zu berücksichtigen sind.“ MDR, Anhang I, Absatz 17.2

Die FDA zählt den AAMI TIR 57 zu den „Consensus Standards“ und zitiert ihn in den eigenen „Guidance Documents“ zur „Cybersecurity“.

Hersteller sollten daher den TIR 57 nicht als weitere „nervige“ regulatorische Anforderung verstehen, sondern als Hilfestellung, um die IT-Sicherheit der eigenen Produkte zu verbessern.

Zusammenspiel von TIR 57 und ISO 14971

Der TIR 57 übernimmt bewusst die Kapitelstruktur der ISO 14971 und passt die Kapitelüberschriften entsprechend an (s. Abb. 1).

Risikomanagement-Prozess nach TIR 57 und ISO 14971 im Vergleich

Abb. 1: Prozesse der ISO 14971 (links) und des TIR 57 (rechts) im Vergleich (zum Vergrößern klicken)

Im Gegensatz zur ISO 14971 erweitert der TIR 57 die Schutzziele um die IT-Sicherheit und definiert entsprechend den Begriff „Schaden“ etwas breiter:

Definition: Harm

„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“

TIR 57

Abb. 2: Schutzziele des TIR 57 und der ISO 14971 im Vergleich (nach “Figure 2” des TIR 57)

Inhalt und Forderungen des TIR 57 im Überblick

Kapitelstruktur

Der Technical Report bildet die ISO 14971 ab und konkretisiert und ergänzt deren Forderungen spezifisch für Risiken durch mangelnde IT-Sicherheit.

Abb. 3: TIR 57 im Überblick (zum Vergrößern klicken)

Forderungen jedes Kapitels

Kapitel	Forderungen, Anmerkungen
3.1 Risikomanagementprozess	Prozess um Aspekte der IT-Sicherheit ergänzen Geänderte Schutzziele beachten (s.o.)
3.2 Verantwortung der Leitung	Akzeptanzkriterien definieren, Prozess prüfen
3.3 Qualifikation des Personals	Erfahrungen mit eigenen Produkten und Techniken der IT-Sicherheit sicherstellen. Dies dokumentieren!
3.4 Sicherheits-Risikomanagementplan	Risikomanagementplan ergänzen. Beispielsweise sollten Tests der IT-Sicherheit wie „fuzz testing“ oder Penetrationstesten ergänzt werden. Weitere Methoden könnten die systematische Auswertung von Fehlerdatenbanken, die statische Code-Analyse und Code-Reviews umfassen. Auch die Planung der nachgelagerten Phase muss die IT-Sicherheitsrisiken beachten.
3.5 Sicherheits-Risikomanagementakte	Enthält analog der 14971 den Plan, die Maßnahmen und deren Verifizierung.
4.1 Prozess der IT-Sicherheitsrisikoanalyse	Der Prozess muss gemäß der Kapitel 4.2 bis 4.4 durchgeführt werden. Dabei ist zu beachten, das nicht nur das Produkt selbst, sondern auch dessen Kontext analysiert wird.
4.2 Zweckbestimmung und Identifikation der Charakteristiken bezüglich der IT-Sicherheit des Medizinprodukts	Das Schutzziel ist nicht mehr nur das Vermeiden körperlicher Schäden, sondern auch die IT-Sicherheit. Die Hersteller müssen bei der Analyse den ganzen Kontext betrachten, in dem das Produkt später bei den Betreibern eingesetzt wird.
4.3 Identifikation von Bedrohungen, Schwachstellen, Assets und schädlichen Einflüssen	Dieses Kapitel ist eines der spezifischsten für die IT-Security. Vergleichbar dem BSI-Grundschutzkatalog müssen die Hersteller die Bedrohungen (z.B. Angriffe), Schwachstellen (z.B. mangelnder Schutz vor Buffer-Overflow) und Objekte (z.B. das Produkt, Daten, Systeme, Komponenten, Netzwerke) identifizieren. Auch die Methoden wie die Attack-Trees, die systematische Auswertung von Publikationen oder das Thread-Modeling sind spezifisch.
4.4 Einschätzung des Sicherheits-Risikos	Die besondere Herausforderung ist die Abschätzung der Wahrscheinlichkeit. Diese ergibt sich v.a. aus der Kombination von Bedrohungen und Schwachstellen. Diese Kombinationen müssen „durchdekliniert“ werden.
5. Sicherheits-Risikobewertung	Keine neuen oder spezifischen Anforderungen
6.1 Minimierung der Sicherheitsrisiken	Keine neuen oder spezifischen Anforderungen
6.2 Analyse der Optionen für die Sicherheits-Risikobeherrschung	Keine neuen oder spezifischen Anforderungen Hinweis auf das Konzept der ISO 80001-1 zu den Verantwortlichkeitsvereinbarungen z.B. zwischen Herstellern und Betreibern. „Security by obscurity“ betrachtet der TIR 57 nicht als eine wirkungsvolle Option, was er aber erst in Kapitel 6.5 erwähnt.
6.3 Implementierung der Risikobeherrschungsmaßnahmen	Keine neuen oder spezifischen Anforderungen
6.4 Bewertung der Restrisiken	Keine neuen oder spezifischen Anforderungen
6.5 Risiko-Nutzen-Analyse	Keine neuen oder spezifischen Anforderungen. Bei Risiken durch mangelnde IT-Sicherheit, die keinen(!) Schaden für Patienten bedeuten können, dürfen Entscheidungen anhand einer Kosten-Nutzen-Betrachtung gefällt werden. Besonders herausfordernd sind sich widersprechende Ziele wie Safety und Security (z.B. Confidentiality).
6.6 Durch Risikobeherrschungsmaßnahmen entstehende Risiken	Auch hier kommen sich widersprechende Ziele zum Tragen: Eine zusätzliche Passwortabfrage kann beispielsweise die IT-Security erhöhen, die Safety aber erniedrigen, weil die Behandlung verzögert wird. Abb. 1 verdeutlicht durch die roten Pfeile diese Abhängigkeiten.
6.7 Vollständigkeit der Risikobeherrschung	Keine neuen Anforderungen. Die Maßnahmen durch Überprüfung der Wirksamkeit betreffen jetzt die IT-Sicherheit.
7. Bewertung der Akzeptanz des Gesamtrisikos	Keine neuen oder spezifischen Anforderungen Allerdings sollten sich widersprechende Ziele (s.o.) diskutiert werden.
8. Sicherheits-Risikomanagementbericht	Im Wesentlichen keine neuen Anforderungen. Allerdings sind einige Aspekte spezifischer zu dokumentieren: – Bedrohungen, Schwachstellen – Assets – Umgebung der Nutzung (z.B. Netzwerke) – Umgang mit Security-Patches und Malware
9. Informationen aus der Herstellung und der Herstellung nachgelagerten Phase	Keine neuen Anforderungen. Spezifischere Aspekte umfassen: – Auswertung von Logs – Umgang mit Malware – Informationen von SW- und HW-Herstellern, Sicherheitsforschern usw.

Weiterführende Informationen

Im Auditgarant finden Sie umfangreiche Listen an Beispielen für Objekte, Schwachstelle und Bedrohungen. Die Videotrainings erläutern die Modelle und zeigen, wie Sie z.B. ein Thread-Modeling, eine Buffer-Overflow-Attacke oder ein Fuzz-Testing durchführen.

Sonstiges

Die meisten Seiten des TIR 57 gelten den Anhängen. Diese erläutern u.a. die folgenden Aspekte:

Besonderheiten der IT-Sicherheit bei Medizinprodukten

Die Autoren weisen auf die Besonderheiten der IT-Sicherheit bei Medizinprodukten hin wie:

IT-Security muss in Notfällen niedriger gewichtet sein als die „Safety“
Häufig dezentrale Verwaltung des Zugangs zu Daten, der zudem Patienten-spezifisch sein muss
Produkte werden über Jahrzehnte genutzt
Safety hat Vorrang vor ökonomischen Überlegungen
Heterogene Einsatz-Szenarien bei Betreibern

Modelle und Prozesse

Der Technical Information Report diskutiert verschiedene Bedrohungen und empfiehlt dabei, die Arten von Angreifern, deren Motivationen, Ziele und Fähigkeiten zu betrachten. In einer sechsstufigen Kategorie sieht der TIR 57 auf den beiden gefährlichsten Stufen die staatlichen Angreifer.

Das Guidance-Document enthält auch (Check-)listen, die allerdings nicht immer sehr vollständig und systematisch abgeleitet erscheinen:

Physikalische Assets
„Information Assets“
Bedrohungen
Schwachstellen
Fragen zur IT-Sicherheit, z.B. mit Bezug zur Leistungsfähigkeit / Zweckbestimmung, zur Datenspeicherung, zur Datenübertragung, zur Authentisierung / Autorisierung, zum Auditing, zu Updates, zur Malware-Protection usw.

Fazit und Empfehlungen

Wer eine konkrete Anleitung erwartet, welche Schwachstellen in welchen Produkten mit welchen Verfahren identifiziert und wie beseitigt werden, der wird vom TIR 57 enttäuscht sein. Es enthält keine Checkliste mit konkreten Prüfaspekten. Hier sei den Herstellern die IEC ISO 15408 empfohlen. Eine Ausnahme ist die Checkliste in Anhang D, die eine schnelle erste Abschätzung der IT-Sicherheit von (Medizin-)produkten erlaubt.