02322 Klassifizierung von IT-Security-Risiken
|
Die Nichteinhaltung einer Safety-Vorgabe (Betriebssicherheit) kann zu einer Verletzung (Wunde) führen. Dass damit ein Schaden einhergeht, der quantifiziert werden kann, ist offensichtlich und anerkannt, wenngleich die Bewertung der Höhe eines solchen Schadens Raum für Interpretationen und Diskussionen bietet.
Doch auch die Verletzung der Security (Informationssicherheit) kann zu einem Schaden führen. Dabei ergeben sich zwei Aspekte: Zum einen kann das Ausnutzen einer Security-Schwachstelle zu einem Schaden führen. Beispiel: Eine nicht autorisierte Person führt einen Vorgang an einem Medizinprodukt aus, der zu einer Verletzung des Patienten (oder von Anwendern bzw. Dritten) führt. Zum anderen kann sich aber bereits aus dem Zugriff auf Daten und Informationen ein Schaden ergeben. Beispiel: Eine nicht autorisierte Person greift auf vertrauliche (Patienten-)Informationen zu.
Die Informationssicherheit rückt mit Erscheinen und Inkrafttreten der Medizinprodukteverordnung (MPV) (engl. Medical Device Regulation – MDR) in den Fokus des Risikomanagements. Dieser Beitrag beschreibt, wie ein Schaden bemessen und nachvollziehbar dokumentiert werden kann. Arbeitshilfen: von: |
1 Abgrenzung
Safety-Schutzklassen
Die im Bereich der Medizintechnik verwendeten Software-Sicherheitsklassen, wie sie in der IEC 62304 [1] definiert sind, beziehen sich spezifisch auf Risiken, die eine physische Verletzung oder Schädigung der Gesundheit von Menschen oder eine Schädigung von Gütern oder der Umwelt darstellen, die mit einer Softwarefehlfunktion verbunden sind. Das ergibt sich direkt aus Definition 3.8 „Schaden” in IEC 62304, die sich auf ISO 14971:2007 bezieht. Beachten Sie jedoch, dass in der mittlerweile in neuer Ausgabe erschienenen ISO 14971 der Schadensbegriff geändert und das Wort „physische” gestrichen wurde. Dadurch (und durch die Detaillierung im Scope) ist EN ISO 14971:2019 auch für Betrachtungen bzgl. Security anwendbar.
Die im Bereich der Medizintechnik verwendeten Software-Sicherheitsklassen, wie sie in der IEC 62304 [1] definiert sind, beziehen sich spezifisch auf Risiken, die eine physische Verletzung oder Schädigung der Gesundheit von Menschen oder eine Schädigung von Gütern oder der Umwelt darstellen, die mit einer Softwarefehlfunktion verbunden sind. Das ergibt sich direkt aus Definition 3.8 „Schaden” in IEC 62304, die sich auf ISO 14971:2007 bezieht. Beachten Sie jedoch, dass in der mittlerweile in neuer Ausgabe erschienenen ISO 14971 der Schadensbegriff geändert und das Wort „physische” gestrichen wurde. Dadurch (und durch die Detaillierung im Scope) ist EN ISO 14971:2019 auch für Betrachtungen bzgl. Security anwendbar.
Die Software-Sicherheitsklassen stellen somit Safety-Schutzklassen dar und lassen sich – in Grenzen – mit den Safety Integrity Levels (SIL) aus der funktionalen Sicherheit wie in IEC 61508-3 [2] beschrieben vergleichen.
Neben der in diesem Beitrag beschriebenen Vorgehensweise sind im Bereich der IT-Sicherheit weitere Verfahren bekannt und etabliert. Im Umfeld der Grundschutzvorgehensweisen des Bundesamts für Sicherheit in der Informationstechnik (BSI) wird dazu beispielsweise ebenfalls von Schutzbedarfsklassen gesprochen, in der Regel aber nur mit einer dreistufigen Klassifizierung (niedrig, mittel, hoch). Nur bis zur Schutzklasse „mittel” darf man sich dann auf allgemeine Grundschutzmaßnahmen verlassen, für die Schutzklasse „hoch” müssen eine dedizierte Risikoanalyse und eine spezifische Maßnahmendefinition und -bewertung erfolgen.
Mittlerweile hat auch die Normung mit IEC 81001-5-1 [3] und IEC/TR 60601-4-5 [4] eine Norm sowie einen technischen Report veröffentlicht, die sich beide mit Security in Medizinprodukten befassen.
Risikomanagement vs. Sicherheitsanforderungen
Anforderungen liegen damit zwar vor, aber wie ein Security-Risikomanagement, wie es in der Medizintechnik verstanden und seit Jahren gemäß ISO 14971 [5] gelebt wird, in der Praxis umgesetzt werden kann, findet sich darin nur rudimentär bis gar nicht. Genau an dieser Stelle greifen die nachfolgenden Ausführungen. Darin wird ein praktischer Weg für ein solches Security-bezogenes Risikomanagement beschrieben.
Anforderungen liegen damit zwar vor, aber wie ein Security-Risikomanagement, wie es in der Medizintechnik verstanden und seit Jahren gemäß ISO 14971 [5] gelebt wird, in der Praxis umgesetzt werden kann, findet sich darin nur rudimentär bis gar nicht. Genau an dieser Stelle greifen die nachfolgenden Ausführungen. Darin wird ein praktischer Weg für ein solches Security-bezogenes Risikomanagement beschrieben.
2 Bestandsaufnahme
Klassifizierungssysteme
Die Verwendung von Klassifizierungen zum Zweck der Einordnung und/oder des Vergleichs ist eine weit verbreitete und etablierte Vorgehensweise. Bereits in der Schule hat jeder in Form des Notensystems damit Bekanntschaft gemacht. Klassifizierungen finden sich in allen Bereichen der Technik wieder, so z. B. bei Kennzahlen, Prozessindikatoren, Prioritäten. Auch im Bereich der Medizinprodukte finden Klassifizierungssysteme weitläufige Anwendung.
Die Verwendung von Klassifizierungen zum Zweck der Einordnung und/oder des Vergleichs ist eine weit verbreitete und etablierte Vorgehensweise. Bereits in der Schule hat jeder in Form des Notensystems damit Bekanntschaft gemacht. Klassifizierungen finden sich in allen Bereichen der Technik wieder, so z. B. bei Kennzahlen, Prozessindikatoren, Prioritäten. Auch im Bereich der Medizinprodukte finden Klassifizierungssysteme weitläufige Anwendung.
Beim Risikomanagement nach ISO 14971 wird eine erkannte (potenzielle) Gefährdung mittels der Parameter Schweregrad und Auftretenswahrscheinlichkeit bewertet und als „Risiko” bezeichnet.
Softwaresicherheitsklassen, wie in IEC 62304 beschrieben, beziehen sich spezifisch auf die möglichen Auswirkungen einer Softwarefehlfunktion, wobei (zum Zweck der Klassifizierung) die Wahrscheinlichkeit des Auftretens auf „1”, also „sicheres Auftreten”, gesetzt und nur der Schweregrad untersucht wird.
2.1.1 Beschreibung
Drei Klassen A, B und C
Die DIN EN 62304 [1] beschreibt die Softwaresicherheitsklassifizierung im Normkapitel 4.3. Die Einteilung findet in drei Klassen statt, namentlich „A”, „B” und „C”, wobei die Klasse „A” ein Softwaresystem beschreibt, von dessen Fehlfunktion kein unvertretbares Risiko ausgehen kann. Ein Softwaresystem der Klasse „C” hingegen kann zum größtmöglichen Schadensausmaß (schwere Verletzung/Tod) führen.
Die DIN EN 62304 [1] beschreibt die Softwaresicherheitsklassifizierung im Normkapitel 4.3. Die Einteilung findet in drei Klassen statt, namentlich „A”, „B” und „C”, wobei die Klasse „A” ein Softwaresystem beschreibt, von dessen Fehlfunktion kein unvertretbares Risiko ausgehen kann. Ein Softwaresystem der Klasse „C” hingegen kann zum größtmöglichen Schadensausmaß (schwere Verletzung/Tod) führen.
Anmerkung
Da der Hersteller sein Softwaresystem in Komponenten und diese wiederum in Einheiten (Units) zerlegen kann, gelten die Überlegungen zur Klassifizierung auch für diese Unterteilungen und sind sinngemäß anzuwenden. Siehe auch DIN EN 62304, 4.3d).
Die Softwaresicherheitsklassifizierung nach DIN EN 62304
| • | dient einzig der Festlegung, welche normativen Anforderungen (hier: bezogen auf DIN EN 62304) zu erfüllen sind; |
| • | skaliert damit sowohl Prozessaufwand als auch Dokumentationsumfang und -tiefe; |
| • | geschieht auf der Basis der schlimmstmöglichen Gefährdungssituation(en) und des damit verbundenen Schadensausmaßes, zu denen das Softwaresystem beitragen kann, somit einzig gemäß dem Schweregrad. Die Auftretenswahrscheinlichkeit wird nicht einbezogen; |
| • | setzt zum Zweck der Klassifizierung die Wahrscheinlichkeit für das Auftreten eines Softwarefehlers im betrachteten Softwaresystem (also einer Fehlfunktion des Softwaresystems) hypothetisch auf „1” (100 %, also „sicheres Auftreten”) gesetzt; |
| • | erlaubt die Berücksichtigung von Risiko-Kontroll-Maßnahmen außerhalb der zu klassifizierenden Software, wodurch sich durch geeignete Maßnahmen eine geringere Softwaresicherheitsklasse ergeben kann. |
2.1.2 Auftretenswahrscheinlichkeit 100 %
Fehler reproduzierbar und nicht zufällig
Die Annahme des „sicheren” Auftretens der Fehlfunktion liegt in der Überlegung begründet, dass das Verhalten des Softwaresystems durch die Programmierung bereits eindeutig festgelegt ist. Dabei ist zu bedenken, dass bei Anwendungen der Künstlichen Intelligenz (KI), die nicht gesperrt sind, sondern sich während der Laufzeit durch Lernen verändern, das Verhalten nicht mehr deterministisch ist und dieser Umstand in die Betrachtungen mit einbezogen werden muss. Bei gleichen Eingangs-, Vor- und Laufzeitbedingungen sind die Ergebnisse (Output) des Softwaresystems eindeutig festgelegt und immer gleich. Ein Softwaresystem verhält sich nicht „zufällig” – im Gegensatz zu Hardware-komponenten, die z. B. auch zufällige Fehler wie Alterung, Fertigungstoleranzen zeigen.
Die Annahme des „sicheren” Auftretens der Fehlfunktion liegt in der Überlegung begründet, dass das Verhalten des Softwaresystems durch die Programmierung bereits eindeutig festgelegt ist. Dabei ist zu bedenken, dass bei Anwendungen der Künstlichen Intelligenz (KI), die nicht gesperrt sind, sondern sich während der Laufzeit durch Lernen verändern, das Verhalten nicht mehr deterministisch ist und dieser Umstand in die Betrachtungen mit einbezogen werden muss. Bei gleichen Eingangs-, Vor- und Laufzeitbedingungen sind die Ergebnisse (Output) des Softwaresystems eindeutig festgelegt und immer gleich. Ein Softwaresystem verhält sich nicht „zufällig” – im Gegensatz zu Hardware-komponenten, die z. B. auch zufällige Fehler wie Alterung, Fertigungstoleranzen zeigen.