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.
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).
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.
Der TIR 57 ist eine wertvolle Ressource, um die eigenen Prozesse, insbesondere den Risikomanagementprozess und den Post-Market-Prozess, um die Aspekte der IT-Sicherheit zu ergänzen und zu konkretisieren. Nutzen Sie ihn dazu.
