Die Normenfamilie IEC 60601 ist eigentlich nur für medizinisch elektrische Geräte anzuwenden. Doch die IEC/TR 60601-4-5 bildet eine Ausnahme: Dieser Technical Report zur IT-Sicherheit hat alle Medizinprodukte im „Scope“, die in IT-Netzwerke eingebunden sind. Das betrifft auch Software as a Medical Device.
Erfahren Sie, welche Anforderungen die IEC/TR 60601-4-5 an Hersteller und Betreiber stellt. Diese Norm gibt Ihnen z. B. konkrete Hinweise, welche Maßnahmen zur Verbesserung der IT-Sicherheit Sie umsetzen müssen und von welchen Faktoren diese Verpflichtung abhängt.
Damit will Ihnen die Norm helfen,
- sichere Produkte zu entwickeln,
- gleichzeitig unnötige Aufwände zu vermeiden und
- die Chancen zu erhöhen, Probleme bei der Zulassung Ihres Produkts zu vermeiden.
1. IEC/TR 60601-4-5: Noch ’ne Norm. Muss das sein?
a) Sollten Sie die Norm überhaupt lesen?
Die IEC/TR 60601-4-5 hat im Januar 2021 das Entwurfsstadium verlassen und liegt nur als Technical Report vor. Sie sollten diese dann lesen, wenn Sie erfahren möchten, wohin die normative Reise geht. Wenn Sie wenig Zeit haben, dann verzichten Sie darauf und gehen Sie wie folgt vor:
- Lesen Sie diesen Artikel, um einen Überblick zu erlangen und um mitreden zu können.
- Verwenden Sie den Leitfaden zur IT-Sicherheit bei Medizinprodukten bei der Entwicklung und Überwachung der Medizinprodukte im Markt. Der Leitfaden gibt Ihnen konkrete Handlungsleitung und wird von den Benannten Stellen in abgewandelter Form verwendet.
Wenn Sie etwas mehr Zeit haben, dann überspringen Sie die meisten Kapitel und lesen noch den Anhang B der Norm.
b) Weshalb reichen andere Normen nicht aus?
Es gibt bereits zahlreiche Normen zur IT-Sicherheit. Die Normenfamilien IEC 62443 und die IEC 15408 sind Beispiele dafür. Weshalb bedarf es weiterer für Medizinprodukte spezifischer Normen?
Safety versus Security
Die erste Antwort liegt in den Schutzzielen: In der allgemeinen IT Security unterscheidet man v.a.:
- (Ressource) Availability
- (System / Data) Integrity
- (Data) Confidentiality
Die IEC 62443, welche die IEC/TR 60601-4-5 ausführlich referenziert, kennt zudem noch:
- Identification and authentication control
- Restricted data flow
- Timly response to events
Allerdings sind das eher untergeordnete Ziele, um die drei erst genannten zu erreichen.
Bei den Medizinprodukten gilt es zusätzlich, die Safety zu beachten.
Die Schutzziele Safety und Security können auch im Konflikt stehen, wenn z. B. der rasche Zugriff einer Person auf Patientendaten auch im medizinischen Notfall möglich sein voll. Das würde zwar die IT-Sicherheit (Confidentiality) kompromittieren, die Safety hingegen erhöhen.
Als Mitglied der Normenfamilie IEC 60601 fordert die IEC/TR 60601-4-5 zur Implementierung der Safety:
- Grundlegende Sicherheit / Basic Safety
- Wesentliche Leistungsmerkmale / Essential Performance
- Minimum an notwendiger klinischer Funktionalität
- Verfügbarkeit des Medizinprodukts
Priorisierungen
Im Gegensatz zur IEC/TR 60601-4-5 kennen viele andere Normen keine sogenannte Security Levels, die Ihnen das nächste Kapitel vorstellt. Mit diesen Security Levels können Sie Maßnahmen für die IT-Sicherheit abhängig von dem „Schutzbedürfnis“ festlegen und damit unnötige Aufwände sparen.
2. Security Levels – Das zentrale Konzept der IEC/TR 60601-4-5
a) Übersicht über die Typen an Security Levels
Die Norm arbeitet mit drei Typen an Security Levels (SL):
- SL-T: Das Target Security Level, das man für das Netzwerk inklusive des darin vernetzten Medizinprodukts erreichen muss, um die festgelegten Schutzziele zu erreichen.
- SL-C: Das Capabiliy Security Level, das Level, das man für das Medizinprodukt und das Netzwerk tatsächlich erreichen kann, wenn man Maßnahmen zur Verbesserung der IT-Sicherheit ergreift.
- SL-A: Das Achieved Security Level, das Level, das man tatsächlich erreicht hat.
Für jedes dieser Security Levels schlägt die IEC/TR 60601-4-5 fünf Stufen vor, von SL 0 (nichts implementiert) bis SL 4, dem höchsten Level. Offensichtlich müssen bei hohen Risiken hohe Security Levels erreicht werden.
Das SL-T muss letztlich der Betreiber bzw. Integrator festlegen, da nur er beurteilen kann, in welcher Netzwerkumgebung ein Medizinprodukt eingesetzt wird. Ein Progammiergerät für einen Herzschrittmacher, das offen im Internet hängen würde, bedarf eines höheren Security Levels als ein Anästhesiearbeitsplatz in einem völlig abgeschotteten Netzwerk eines OPs.
Hingegen bestimmen die Hersteller das SL-C, das erreicht werden kann, wenn die Betreiber das Gerät spezifikationsgemäß konfigurieren und betreiben. Das SL-C hängt davon ab, welche Maßnahmen der Hersteller implementiert und auch überprüft hat.
Welches tatsächliche Security Level (SL-A) die Betreiber erreichen, hängt von mehreren Faktoren ab:
- Hat der Betreiber die Geräte innerhalb des Netzwerks und das Netzwerk selbst korrekt konfiguriert?
- Hat der Betreiber Maßnahmen zur Erhöhung der IT-Sicherheit außerhalb des Geräts umgesetzt?
Beispielsweise „Integrationstests“ bestimmen das tatsächlich erreichte SL-A, wobei mit „Integration“ die Integration der Geräte in den Netzwerkverbund gemeint ist.
b) Festlegung des SL-T
Die IEC/TR 60601-4-5 empfiehlt die SL-Ts für diese verschiedenen Umgebungen einzeln festzulegen. Doch nicht nur die Netzwerkumgebung sollte einen Einfluss haben, sondern auch:
- Wert der Produkte
- Höhe der Schäden, wenn die Basissicherheit oder wesentliche Leistungsmerkmale nicht mehr gegeben sind
- Vorliegen von Patientendaten
- Nutzerprofile
- Heimnetzwerk versus Krankenhausnetzwerk
- Angriffsfläche z. B. Anzahl der Geräte, Anzahl verfügbarer Ports, Anzahl Schnittstellen
- Anzahl der Medizinprodukte im Markt
c) Nutzen und Verwendung der Security Levels
Die Security Levels sollen helfen, die Anforderungen an und die Aufwände für die IT-Sicherheit zu steuern. Dazu erstellt die Norm im Anhang B ein Mapping zwischen den Aspekten der IEC 62443 und den Security Levels, wie die folgenden Beispiele zeigen:
Anforderungen |
SL1 |
SL2 |
SL3 |
SL4 |
Authentifizierung der Nutzer |
X |
X |
X |
X |
Multifaktor-Authentifizierung an allen Schnittstellen |
X |
X | ||
Rollenbasierte Berechtigungen |
X |
X |
X | |
Malware-Schutz |
X |
X |
X |
X |
3. Verweise auf andere Normen
Die IEC/TR 60601-4-5 verweist normativ die IEC 62443-4-2:2019 (Security for industrial automation and control systems – Part 4-2: Technical security requirements for IACS components), ebenso auf die IEC 80001-1-Familie.
Sie wiederholt die Forderung nach üblichen Schutzmaßnahmen und Prinzipien wie „Least Privilege“, Minimierung der Daten, Einhalten eines Software-Entwicklungsprozesses und Schutz durch Hardware-Maßnahmen (z. B. physischer Zugriffsschutz).
Die Norm ergänzt nur wenige Anforderungen der IEC 62442-4-2 bzw. modifiziert diese leicht. Weiter listet sie spezifische Anforderungen an die Begleitmaterialien. Diese reichen von der Festlegung der vorgesehenen Anwender über Vorgabe zur Konfiguration des Produkts bis hin zu Maßnahmen, für die die Betreiber und Anwender verantwortlich sind.
4. Fazit
a) Mögliche Kritikpunkte
Es soll nicht abgestritten werden, dass es eine Norm zur IT Security benötigt, die spezifisch für Medizinprodukte ist. Auch verdient die Einschätzung der IEC/TR 60601-4-5 Zustimmung, dass die IT-Sicherheit übergreifend d. h. sowohl für Hersteller und Betreiber geregelt werden sollte.
Ob die IEC/TR 60601-4-5 dem Anspruch gerecht werden wird, kann diskutiert werden. Mögliche Kritikpunkte sind:
- Durch die Verweise und Einbindung anderer Normen ist die IEC/TR 60601-4-5 schwer lesbar und überblickbar.
- Die Norm erscheint manchmal inkonsistent, was die Konkretheit der Anforderungen betrifft. Durch die Referenz auf die IEC 62443 sind diese Anforderungen teilweise sehr konkret. Andere Anforderungen, wie dass eine DoS-Attacke keine „Safety-related“ Funktionen behindern sollten, sind eher „High-Level“.
- Es fehlt eine klare Handlungsleitung z. B. entlang des Entwicklungsprozesses, wie das der Leitfaden zur IT-Sicherheit tut. Dieser berücksichtigt ebenfalls die IEC 62443.
- Das Zusammenspiel und die Zusammenarbeit zwischen Herstellern und Betreiber betrachtet die IEC/TR 60601-4-5 nur unzureichend und v. a. über Verweise auf die IEC 80001-1-Familie. Anforderungen an die Post-Market Surveillance finden sich (nahezu) keine. Das ist angesichts der Anforderungen der MDR bedenklich.
b) Scope?
Es wäre auch schön gewesen, wenn die Norm den Scope noch klarer gemacht hätte:
- Im Titel steht „ME Equipment“. Damit wäre sie auf standalone Software nicht anwendbar.
- Im Vorwort schreibt sie: „This document provides IT security specifications for medical devices connectable to medical IT-networks as network components, including medical software applications.“ Bezieht sich das „including medical software applications“ auf die „network components“ oder auf „medical devices“?
- Im „Scope“ heißt es dann „This document provides detailed technical recommendations for security features of medical devices used in medical IT-networks […]“. Von „ME Equipment“ ist keine Rede mehr.
Fazit: Die IEC/TR 60601-4-5 ist für Software as Medical Device anwendbar.
c) Was gefällt
Dass die IEC/TR 60601-4-5 das Rad nicht neu erfindet, sondern auf Bestehendes, v.a. auf die IEC 62443 verweist, ist lobenswert.
Ebenfalls hilfreich ist der Ansatz, für verschiedene Schutzziele jeweils die Security Levels zu bestimmen (SL-T, SL-C und SL-A) . Das ermöglicht es, Maßnahmen in den Medizinprodukten sowie im Netzwerk zu priorisieren.
Genau dieser Fokus ist notwendig: Denn ein immer mehr an Normen und Anforderungen führt nicht zu mehr (IT-)Sicherheit, sondern nur zu einer Überforderung aller Beteiligten.
Änderungshistorie
- 2019-10: Erster Version dieses Artikels. Die Norm liegt nur als Entwurf vor.
- 2021-02: Die Norm ist freigegeben. Dies ist im Artikel geändert. Das Mindmap ist an die neue Kapitelstruktur angepasst.
Hallo Herr Johner,
kann es sein, dass die Norm nie über den Stadium eines Entwurfs hinausgekommen ist? Zumindest finde ich nichts.
Danke und Grüße
Benjamin Kainikkara
Lieber Herr Kainikkara,
danke für die wichtige Frage! Ich habe gerade Rücksprache mit Mitgliedern dieses Gremiums erhalten. Man erwartet die Veröffentlichung in „wenigen Wochen“. Es scheint hinter den Kulissen also weiter gerabeitet worden zu sein.
Beste Grüße auch an die netten Kollegen, Christian Johner
Hallo Herr Kainikkara und Herr Johner,
der Technical Report ist am 18.Januar 2021 nun ‚endlich‘ publiziert worden.
Dank Herrn Johners Einschätzung fällt die Entscheidung zur Anwendung leicht.
Aus dem heutigen virtuellen Meeting mit dem TÜV Süd kann ich Ihnen nur empfehlen, dass Sie (auch für diesen Standard) die kritische Würdigung in der Liste der angewandten Standards unbedingt vornehmen sollten. In der IVDR gibt es zu Hardware Networks und Security Networks in jedem Fall etwas zu tun. Ggf. können Sie dies in der MDS2-Tabelle mit adressieren oder separat.
Herzliche Grüße, Franz Döpp