Elektronische Gesundheitskarte und Telematikinfrastruktur

Methodik der Sicherheitskonzeption in der Telematikinfrastruktur

Version
3.6.0
Revision
1513350
Stand
02.02.2026
Status
freigegeben
Klassifizierung
öffentlich
Referenzierung
gemMeth_SiKonz

Dokumentinformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.   

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokuments

1.1 Zielsetzung

Dieses Dokument beschreibt die Methodik der Sicherheitskonzeption in der Telematikinfrastruktur (TI). Die Methodik wird in den Phasen des Lebenszyklus der Produkte der TI innerhalb der gematik verwendet, um das erforderliche Sicherheitsniveau für die TI zu erreichen und zu verifizieren.

1.2 Zielgruppe

Das Dokument richtet sich an all diejenigen in der gematik, die an der Entwicklung, Herstellung und dem Betrieb von Fachanwendungen bzw. Produkten der TI (Komponenten und Dienste) beteiligt sind.

1.3 Geltungsbereich

Der Geltungsbereich umfasst alle von der gematik entwickelten, hergestellten und betriebenen Fachanwendungen und Produkte (Komponenten und Dienste) der TI.

1.4 Abgrenzung des Dokuments

Das Dokument richtet sich nicht an Hersteller bzw. Anbieter von Produkten der TI. Die Methodik kann jedoch von Herstellern bzw. Anbietern der TI auf freiwilliger Basis adaptiert werden.

1.5 Methodik

Die verwendete Methodik der Sicherheitskonzeption orientiert sich an BSI-Standards (insbesondere [BSI-200-1] und [BSI-200-2]) sowie der Risikorichtlinie der gematik [RL_RMS] und wird in der Entwicklungsphase für Fachanwendungen bzw. Produkte (Komponenten und Dienste) der TI angewendet.

Die getroffenen Maßnahmen zur Informationssicherheit fließen in die Spezifikationen, Produkte sowie betrieblichen Maßnahmen der gematik ein. Die identifizierten Risiken werden im Risikomanagement der gematik verwaltet.

Der in diesem Dokument verwendete Begriff „Asset“ umfasst sowohl Komponenten und Dienste inklusive der darin verarbeiteten Informationsobjekte und ausgeführten Anwendungsprozesse im Sinne von Produkttypen als auch im Sinne der von den Herstellern produzierten Produkte und im Sinne der von Anbietern/Betreibern betriebenen Produktinstanzen. Abbildung 1 zeigt den Zusammenhang zwischen diesen Begriffen und welche Methoden darauf jeweils angewendet werden.

Abbildung 1: Zusammenhang zwischen den als Assets bezeichneten Begriffen und den Methoden der Sicherheitskonzeption

2 Methodik der Sicherheitskonzeption

Die in diesem Dokument dargelegte Methodik der Sicherheitskonzeption im Lebenszyklus der Produkte der TI verwendet Methoden der Informationssicherheit, um für eine Anwendung bzw. ein Produkt der TI ein angemessenes Sicherheitsniveau auf Spezifikationsebene, im Produkt selbst sowie für dessen Betrieb zu erreichen.

Die Sicherheitskonzeption findet im Rahmen der agilen Entwicklungsprozesse (SAFe, Scrum, Kanban) der gematik Anwendung. Zu Beginn erfolgt eine Informationssammlung hinsichtlich der Funktionalität und der berechtigten Akteure der Anwendung sowie der systemspezifischen Bedrohungen, Angreifer, Schutzbedarfe und Missbrauchsszenarien (Analyse und Product Discovery Phase). Hieraus werden produktspezifische Bedrohungen und Missbrauchsszenarien abgeleitet, die in die Sicherheitskonzeption einfließen. Grundlage für diese Informationen sind die Festlegungen des vorliegenden Dokuments und des übergreifenden Datenschutz- und Sicherheitskonzepts der TI. In dieser Phase des Lebenszyklus der Produkte (Entwicklungsphase) sind die Betrachtungen der zuvor genannten Aspekte im Wesentlichen noch technikneutral, da die Spezifikationen einen Umsetzungsspielraum für die Hersteller von Produkten der TI lassen. In jedem Fall muss aber auf die Interoperabilität und Kompatibilität der zu realisierenden Produkte bereits in der Spezifikation geachtet werden.

Abbildung 2: Die Methodik der Sicherheitskonzeption im Rahmen des Entwicklungsprozesses der gematik

Die Anwendung der Methodik der Sicherheitskonzeption wird im Folgenden kurz skizziert, um einen Überblick über das Zusammenspiel der verschiedenen Methoden zur Informationssicherheit zu geben.

Abbildung 3: Übersicht Methodik der Sicherheitskonzeption

Der erste Schritt besteht in der Bedrohungsanalyse auf Grundlage der Anwendungsfälle einer neuen Anwendung bzw. eines neuen Produkttyps. Zu diesem frühen Entwicklungszeitpunkt sind die Funktionen und die berechtigten Akteure in den Anwendungsfällen bekannt und können im Hinblick auf Missbrauchsszenarien betrachtet werden.

Nach der Systemzerlegung in der Architektur der neuen Anwendung bzw. des neuen Produkttyps kann die Erfassung der zu betrachtenden Assets (vgl. Kapitel 4) erfolgen. Dies sind Informationsobjekte und Anwendungsprozesse sowie Komponenten und Dienste (vgl. Abbildung 1).

Die Anwendung der Schutzbedarfsfeststellung (vgl. Kapitel 5) liefert den Schutzbedarf der Assets bezüglich der Schutzziele.

In der Business Impact Analyse (vgl. Kapitel 6) erfolgt eine Betrachtung der Schadensschwere eines Ausfalls des Assets über einen zeitlichen Verlauf. Zudem werden die Abhängigkeiten zwischen dem betrachteten Asset (hier insbes. Komponente oder Dienst) zu anderen Komponenten oder Diensten dokumentiert.

Der Schutzbedarf der Assets fließt zusammen mit dem Gefährdungskatalog und/oder dem Ergebnis der Bedrohungs- und Schwachstellenanalyse (vgl. Kapitel 7), den spezifizierten Sicherheitsfunktionen sowie den übergreifenden Festlegungen (Die übergreifenden Festlegungen finden sich einerseits im übergreifenden Sicherheitskonzept der TI und zum anderen in den übergreifenden Spezifikationen der TI wieder.) in die Gefährdungs- bzw. Sicherheitsanalyse eines zu betrachtenden Assets (einer Komponente oder eines Dienstes) ein. Für die Entwicklungsphase ist eine separate Betrachtung von Bedrohungen und Schwachstellen von Vorteil, da diese anwendungs- bzw. produkttypspezifisch sein können. Daneben wird auf Erfahrungen und Best Practices zurückgegriffen, wie sie sich im Gefährdungskatalog des BSI ([BSI-EleGef]) wiederfinden. Anstatt also Bedrohungen und Schwachstellen in der Sicherheitsanalyse separat zu betrachten, wird in der Gefährdungsanalyse eine vorgefertigte Liste von Kombinationen (Gefährdungen) daraus betrachtet, die als relevant für den Betrieb von Systemen angesehen werden. 

Beispiel: Die elementare Gefährdung G 0.15 „Abhören“ ist eine Kombination der Bedrohungsursache „Mensch“ in der Ausprägung „schädigendes Handeln“ und der Aktion „Kenntnisnahme von Informationen“ und beispielsweise der Schwachstelle „Konfigurationsfehler“. Als Schwachstellen kommen noch weitere Ausprägungen in Frage, wie „Designfehler“ oder „mangelnde physische Sicherheit der Umgebung“. Die Ausprägung „Designfehler“ würde zu einem Risiko im Entwicklungsprozess führen, wohingegen die Schwachstelle „Konfigurationsfehler“ ein betriebliches Risiko betrifft.

Die Methode der Gefährdungs- bzw. Sicherheitsanalyse (vgl. Kapitel 8) stellt den zentralen Teil der Methodik der Sicherheitskonzeption dar, in dem für die spezifizierten Sicherheitsfunktionen analysiert wird, ob sie das betrachtete Asset ausreichend schützen. Dieser Bewertungsprozess lässt sich nicht vollständig formalisieren, sondern ist auf das Einbringen von Expertenwissen angewiesen, das den aktuellen Stand der Technik reflektiert.

Das Ergebnis dieser Analyse ist entweder die Dokumentation der bewerteten Sicherheitsfunktionen, falls man zu dem Schluss gekommen ist, dass die gewählten Sicherheitsfunktionen ausreichend sind oder aber der Einstieg in eine Risikoanalyse, falls die gewählten Sicherheitsfunktionen nicht ausreichend vor Angriffen auf das Asset schützen.

Ebenso ist die Erkenntnis möglich, dass die Bedrohung, Schwachstelle oder auch das betrachtete Asset außerhalb der Systemgrenzen der TI und damit außerhalb der Regelungshoheit der gematik liegt. In diesen Fällen wird der mögliche Angriff als Grenze der Sicherheitsleistung dokumentiert.

Das Ergebnis der Risikoanalyse (vgl. Kapitel 9) ist entweder die Akzeptanz eines bewerteten Restrisikos oder aber der Entschluss, eine zusätzliche oder andere Sicherheitsfunktion zum Schutz des Assets zu wählen und diese in einer Sicherheitsanalyse erneut zu bewerten.

Weitere Risikoanalysen werden in den der Entwicklungsphase folgenden Phasen des Lebenszyklus der Produkte der TI durchgeführt. In der Zulassungsphase betrifft dies Auflagen aus Produkt- bzw. Sicherheitsgutachten, die von Herstellern bzw. Anbietern/Betreibern von Produkten der TI im Nachgang einer erteilten Zulassung zu erfüllen sind. In der Betriebsphase können weitere Risikoanalysen aufgrund von Schwachstellen oder Incidents bei Herstellern oder Anbietern/Betreibern notwendig sein sowie aufgrund von Mängeln, die bei Audits festgestellt wurden.

Ausgangspunkt sind hier die auf der Grundlage eines Produkttyps durch einen Hersteller produzierten und die durch einen Anbieter bzw. Betreiber betriebenen Produktinstanzen. Grundsätzlich werden durch den Hersteller die eingesetzte Technik und durch den Anbieter/Betreiber die Betriebsumgebung und die Betriebsprozesse bestimmt bzw. umgesetzt.

Maßnahmen, die in der Risikoanalyse festgelegt werden, können direkt den Anbieter/Betreiber betreffen, z. B. wenn die existierenden Maßnahmen nicht zur Erfüllung einer bestehenden Anforderung ausreichen, oder sie wirken indirekt, indem sie als neue Sicherheitsfunktion bzw. Maßnahme zur Anomalie-Erkennung in die Spezifikation des betroffenen Produkts aufgenommen werden. Ist die Maßnahme von genereller Natur, d.h. ihre Umsetzung ist für mehrere Produkte bzw. ihre Anbieter/Betreiber sinnvoll, wird sie in die übergreifenden Festlegungen aufgenommen.

Sofern die gematik in der Rolle eines Herstellers agiert, erfolgen Risikoanalysen im Rahmen des sicheren Softwareentwicklungsprozesses.

3 Bedrohungsanalyse auf Anwendungsfallebene

Die Bedrohungsanalyse auf Anwendungsfallebene erlaubt bei der Neuentwicklung von Anwendungen bzw. Produkttypen einen frühzeitigen Beginn der Informationserhebung für die Sicherheitsanalyse. Der frühe Zeitpunkt erfordert ggf. eine Einbeziehung des Produktteams (insbes. Business Manager und Product Owner), da die Betrachtung anhand fachlicher Anwendungsfälle erfolgt.

Aus einer Bedrohungsanalyse auf Anwendungsfallebene können bereits Erkenntnisse über die Notwendigkeit von Design- und/oder Anomalie-Erkennungsmaßnahmen gewonnen werden, die später in die Spezifikation einfließen.

Das Vorgehen besteht in einer Erfassung der Anwendungsfälle der Anwendung bzw. des Produkttyps und der Betrachtung pro Anwendungsfall, welcher Angreifer mit welcher Aktion einen Missbrauch des Anwendungsfalls begehen könnte. Als Angreifer können hierfür die berechtigten Nutzer der Anwendung in ihren Rollen (z. B. Leistungserbringer, Kostenträger, Versicherte) sowie die unspezifische Rolle „Außentäter“ verwendet werden.

Neben den Anwendungsfällen sollten auch anwendungsfallübergreifende Missbrauchsfälle betrachtet werden. Die Beschreibung von Missbrauchsfällen außerhalb der TI ist vor allem für Anwendungen sinnvoll, bei denen daran beteiligte Komponenten oder Dienste außerhalb der Regelungshoheit der gematik liegen, die gematik also nicht die Ende-zu-Ende-Verantwortung für die Anwendung hat, für deren Abwenden jedoch die Komponenten und Dienste in der TI ggf. einen Beitrag leisten könnten.

Wird ein Missbrauchsszenarium identifiziert, werden Indikatoren gesucht, die auf die Ausnutzung eines Missbrauchsszenariums hindeuten.

Die Bewertung eines Missbrauchsszenariums kann zu der Erkenntnis führen, dass das Missbrauchsszenarium mit vorhandenen bzw. bereits geplanten Maßnahmen abgewendet wird, dass mögliche Maßnahmen außerhalb der TI ergriffen werden bzw. ergriffen werden müssten (Grenze der Sicherheitsleistung) oder, dass eine weitere Analyse notwendig ist, die in einer Maßnahme im Design der Anwendung bzw. Produkttyps oder einer Maßnahme im Monitoring münden kann.

Für die Erfassung dieser Informationen bietet sich eine Mindmap an, die nach dem oben geschilderten Schema strukturiert ist:

Abbildung 4: Bedrohungsanalyse auf Anwendungsfallebene mittels Mindmap

Sollten die Anwendungsfälle der Anwendung bzw. des Produkttyps noch nicht oder noch nicht vollständig bekannt sein, so kann die Betrachtung zunächst auf generischen Anwendungsfällen erfolgen, wie sie in der Datenschutz-Grundverordnung ([DSGVO]) bzw. dem Standarddatenschutzmodell ([SDM]) beschrieben sind:

Tabelle 1: Vorgänge und Phasen eines Datenlebenszyklus gem. Abbildung 1 des SDM

Die Ergebnisse der Bedrohungsanalyse auf Anwendungsfallebene fließen in die Sicherheitsanalyse ein – insbesondere, wenn das Analyseergebnis erbracht hat, dass zusätzliche Maßnahmen in Form von Sicherheitsfunktionen oder Monitoring-Möglichkeiten erforderlich sind.

4 Asset-Erfassung

Ziel der Asset-Erfassung ist die Dokumentation, der in der Spezifikationsphase entstehenden Informationsobjekte und Anwendungsprozesse sowie Komponenten und Dienste. Die Erfassung von Assets ist eine Vorbedingung für die weiteren Prozesse der Sicherheitskonzeption sowie der betrieblichen Sicherheit, da diese Assets mit Schutzbedarfsfeststellungen, Risikoanalysen, Sicherheitsvorfällen und Schwachstellen etc. verknüpft werden.

Die Erfassung von Assets erlaubt jederzeit einen Überblick über die Produkttypen der TI, die aus ihnen realisierten Produkte und in der TI betriebenen Produktinstanzen, deren Teilkomponenten bzw. Teilsystemen sowie ggf. Versions- und Patch-Stände.

Produkttypen in Form von Komponenten und Diensten werden von der gematik in der Entwicklungsphase definiert. Alle tieferen Ebenen (Teilkomponenten und -systeme) werden von Herstellern in der Herstellungsphase bzw. Anbietern in der Betriebsphase definiert. Die Assets von Anbietern werden im regelmäßigen Zyklus an die gematik mittels Reports sowie anlassbezogen bei Änderungen über den Change-Management- bzw. Request Fulfillment Prozess übermittelt. Die Regelreports werden mit der bestehenden Asset Datenbank abgeglichen. Anlassbezogene Änderungen werden manuell nachgepflegt.

Für die Assets, die in der Entwicklungsphase definiert werden, erfolgt die Schutzbedarfsfeststellung durch die gematik. Die Assets, die von Herstellern bzw. Anbietern definiert werden, werden auch durch diese bewertet. Dabei wird von der gematik darauf geachtet, dass diese Bewertungen nicht im Widerspruch zum Bewertungssystem der gematik stehen.

5 Schutzbedarfsfeststellung

Ziel der Schutzbedarfsfeststellung ist es, für die Informationsobjekte und Anwendungsprozesse sowie Komponenten und Dienste der Telematikinfrastruktur zu ermitteln, welchen Schutzbedarf sie bezüglich der zu betrachtenden Schutzziele besitzen. Dieser Schutzbedarf orientiert sich an den möglichen Schäden, die mit einer Beeinträchtigung der Schutzziele verbunden sind.

Die Methodik der Schutzbedarfsfeststellung orientiert sich an der Schutzbedarfsfeststellung im BSI-Standard 200-2 ([BSI-200-2]). Diese ist soweit erforderlich auf die TI angepasst und durch Hilfsmittel ergänzt, die bei der Ermittlung des Schutzbedarfs unterstützen.

5.1 Schutzziele

Für alle Informationsobjekte muss der Schutzbedarf bzgl. der Schutzziele Vertraulichkeit und Integrität bewertet werden.

Vertraulichkeit: Vertraulichkeit ist der Schutz vor unbefugter Preisgabe von Informationen. Vertrauliche Informationsobjekte dürfen ausschließlich Befugten in der zulässigen Weise zugänglich sein.

Integrität: Integrität bezeichnet die Sicherstellung der Korrektheit (Unversehrtheit) von Informationsobjekten. Der Verlust der Integrität von Informationsobjekten bedeutet auch, dass diese unerlaubt verändert werden, Angaben zum Autor verfälscht oder Zeitangaben zur Erstellung manipuliert wurden.

Für alle Anwendungsprozesse muss der Schutzbedarf bzgl. des Schutzziels Verfügbarkeit bewertet werden.

Verfügbarkeit: Die Verfügbarkeit von Anwendungsprozessen ist vorhanden, wenn diese von den Anwendern stets wie vorgesehen genutzt werden können.

Die Schutzbedarfsfeststellung für die Schutzziele Vertraulichkeit, Integrität und Verfügbarkeit kann bei Bedarf um weitere Schutzziele erweitert werden, wenn dies in einem individuellen Anwendungskontext erforderlich ist. Mögliche weitere Schutzziele sind u.a. Authentizität und Nichtabstreitbarkeit.

5.2 Ermittlung des Schutzbedarfs

Grundlage der Schutzbedarfsfeststellung ist eine Liste von Informationsobjekten und Anwendungsprozessen eines zu betrachtenden Assets. Dies kann eine Komponente oder ein Dienst, oder ein Teil von diesen sein. Informationsobjekte sind Informationen mit passiven Eigenschaften, die in Anwendungsprozessen dynamisch erzeugt, verarbeitet oder gespeichert werden.

Abbildung 5 zeigt die Schritte der Schutzbedarfsfeststellung, die für Informationsobjekte und Anwendungsprozesse zu durchlaufen sind.

Abbildung 5: Schritte einer Schutzbedarfsfeststellung

Als Ergebnis der Schutzbedarfsfeststellung sind allen Informationsobjekten und Anwendungsprozessen des betrachteten Assets für jedes der zu betrachtenden Schutzziele eine der folgenden Schutzbedarfskategorien zugeordnet:

• niedrig
• mittel
• hoch
• sehr hoch

5.2.1 Individuelle Schutzbedarfsfeststellung

Welche Schutzbedarfskategorie einem Informationsobjekt bzw. Anwendungsprozess jeweils zugeordnet wird, wird durch eine individuelle Abschätzung der Höhe potentieller Schäden durch Verlust des Schutzzieles anhand der folgenden in [RL_RMS] bzw. in [RL_RMS_Auswirkungstabelle] definierten Schadensszenarien festgelegt:

• Operative Auswirkungen
• Finanzielle Auswirkungen
• Auswirkungen auf die Reputation
• Compliance / rechtliche Auswirkungen
• Auswirkung auf die informationelle Selbstbestimmung
• Auswirkung auf Gesundheit und Sicherheit

Sollten Schäden sich nicht in die definierten Schadensszenarien einordnen lassen, jedoch für die Bewertung der Schadenschwere und damit des zu ermittelnden Schutzbedarfs vonnöten sein, so können zusätzlich eigene Schadensszenarien gebildet werden.

Häufig treffen für ein Informationsobjekt bzw. einen Anwendungsprozess mehrere Schadensszenarien zu. So kann beispielsweise der Verlust der Vertraulichkeit eines Informationsobjektes einen Verstoß gegen ein Gesetz bedeuten, was auch finanzielle Einbußen nach sich zieht und gleichzeitig auch zu einem Imageverlust führt. Die Beurteilung des Schutzbedarfs erfolgt in diesem Fall nach dem Maximumprinzip, d.h. dass der Schutzbedarf immer von dem Schadensszenario mit dem schwersten potenziellen Schaden abgeleitet wird (maximale Schadensschwere bestimmt den Schutzbedarf).

5.2.2 Hilfsmittel zur Schutzbedarfsfeststellung

Um bei der Schutzbedarfsfeststellung zu unterstützen, werden folgende Hilfsmittel zur Verfügung gestellt:

• Datenklassen für Informationsobjekte: Informationsobjekte können Datenklassen zugeordnet werden, für die bereits ein generischer Schutzbedarf ermittelt wurde, Informationen zu dieser Vorgehensweise finden sich in Abschnitt 5.2.3.
• Schutzbedarf für Schlüssel und andere schützende Artefakte: Für die Informationsobjekte Schlüssel und andere schützende Artefakte (z.B. PINs, Token) wird eine gesonderte Methode zur Bestimmung ihres Schutzbedarfs in Abschnitt 5.2.4 eingeführt.
• Prozessklassen für Anwendungsprozesse: Analog zu Datenklassen können den Anwendungsprozessen Prozessklassen zugeordnet werden, für die bereits ein generischer Schutzbedarf ermittelt wurde (vgl. Abschnitt 5.2.5).

5.2.3 Datenklassen für Informationsobjekte

In diesem Abschnitt wird die Nutzung von Datenklassen zur vereinfachten Ermittlung des Schutzbedarfs von Informationsobjekten beschrieben. Schlüssel und andere schützende Artefakte (z.B. PINs, Token) werden nicht Datenklassen zugeordnet, sondern durch eine spezielle Methode in Abschnitt 5.2.4 behandelt.

Die Einführung von Datenklassen für die Schutzbedarfsfeststellung soll helfen, die Durchführung von Schutzbedarfsfeststellungen zu vereinfachen. Der Grundgedanke hierbei liegt in der Bildung von Datenklassen für Informationsobjekte, die aus dem Blickwinkel des Datenschutzes bzw. der Informationssicherheit den gleichen Schutzbedarf besitzen. Hierzu wird der Schutzbedarf jeder Datenklasse bestimmt und alle Informationsobjekte, die in diese Datenklasse fallen, haben damit genau diesen Schutzbedarf. Beispielsweise existieren in der TI eine Reihe unterschiedlicher Informationsobjekte, die personenbezogene medizinische Daten enthalten (Notfalldaten, Arztbriefe, Befunde, Röntgenbilder etc.), die bei einer individuell durchgeführten Schutzbedarfsfeststellung zum gleichen Ergebnis des Schutzbedarfs führen würden. Durch die Zuordnung dieser Informationsobjekte zur Datenklasse „personenbezogene medizinische Daten“ entfällt der Aufwand für die individuellen Schutzbedarfsfeststellungen. Das Ergebnis der Herleitung der Datenklassen findet sich als grundlegende Schutzbedarfsfeststellung im Übergreifenden Datenschutz- und Sicherheitskonzepts der TI ([gemKPT_DS_Sich_TI#Anhang B1]) wieder.

Es werden folgende Datenklassen unterschieden:

Abbildung 6: Datenklassen für die Schutzbedarfsfeststellung

Die Schutzbedarfsfeststellung der Datenklassen erfolgt entsprechend der Schadensbestimmung in der Auswirkungstabelle der Risikorichtlinie der gematik [RL_RMS_Auswirkungstabelle].

Der Personenbezug eines Informationsobjektes ist das erste Kriterium für die Bildung der Datenklassen, so dass sich Datenklassen für Informationsobjekte mit Personenbezug und Datenklassen für Informationsobjekte ohne Personenbezug ergeben.

Die Datenklassen mit Personenbezug werden in „Öffentliche personenbezogene Daten“, (nicht öffentliche, aber auch nicht medizinische) „Personenbezogene Daten“ sowie „Personenbezogene medizinische Daten“ unterteilt.

Die Datenklassen ohne Personenbezug werden in „Öffentliche“, „Daten ohne Sicherheitsrelevanz“ und „Sicherheitsrelevante Daten“ unterteilt.

Beispiele für die Zuordnung von Informationsobjekten zu den Datenklassen sind in der folgenden Abbildung dargestellt:

Abbildung 7: Beispiele für die Zuordnung von Informationsobjekten zu Datenklassen

Bei der Ermittlung des Schutzbedarfs für ein Informationsobjekt wird dieses zunächst genau einer Datenklasse zugeordnet.

Nach erfolgter Zuordnung sind die folgenden Regeln anzuwenden:

Regel D1: Treffen alle Bewertungen für die einzelnen Schadenskategorien der Schutzbedarfsfeststellung der zugeordneten Datenklasse für das Informationsobjekt zu, erhält das Informationsobjekt den Schutzbedarf dieser Klasse.

Regel D2: Falls der vordefinierte Schutzbedarf der zugeordneten Datenklasse nicht anwendbar ist, muss das Informationsobjekt individuell bewertet werden.

5.2.3.1 Datenklasse "Personenbezogene medizinische Daten"

Aufgrund der Tatsache, dass in der TI eine große Anzahl personenbezogener medizinischer Daten verarbeitet werden, wird für diese Informationsobjekte eine Datenklasse eingeführt.

Tabelle 2: Schutzbedarfsfeststellung der Datenklasse "Personenbezogene medizinische Daten"

5.2.3.2 Datenklasse "Personenbezogene Daten"

Die Datenklasse "Personenbezogene Daten" wird für Informationsobjekte mit Personenbezug eingeführt, die weder medizinischer noch öffentlicher Natur sind.

Tabelle 3: Schutzbedarfsfeststellung der Datenklasse "Personenbezogene Daten"

5.2.3.3 Datenklasse "Öffentliche personenbezogene Daten"

Die Datenklasse „Öffentliche personenbezogene Daten“ wird eingeführt, da insbesondere für die Kommunikation der Beteiligten in der TI ein Teil der personenbezogenen (nicht medizinischen) Daten veröffentlicht werden (bspw. Einträge im Verzeichnisdienst der TI).

Tabelle 4: Schutzbedarfsfeststellung der Datenklasse "Öffentliche personenbezogene Daten"

5.2.3.4 Datenklasse "Daten mit Sicherheitsrelevanz“

Diese Datenklasse beinhaltet Informationsobjekte die für Sicherheitsfunktionen notwendig sind. Sicherheitsrelevanz bedeutet hier, dass diese Informationsobjekte eine Rolle bei der Gewährleistung der Informationssicherheit in der TI spielen. Die Informationsobjekte dieser Datenklasse sind deshalb vertraulich und müssen integer sein.

Tabelle 5: Schutzbedarfsfeststellung der Datenklasse "Daten mit Sicherheitsrelevanz “

5.2.3.5 Datenklasse "Daten ohne Sicherheitsrelevanz"

Diese Datenklasse wird für Informationsobjekte ohne Personenbezug und ohne Sicherheitsrelevanz eingeführt, die nicht öffentlich sind.

Tabelle 6: Schutzbedarfsfeststellung der Datenklasse "Daten ohne Sicherheitsrelevanz"

5.2.3.6 Datenklasse "Öffentliche Daten"

In diese Datenklasse fallen öffentliche Informationsobjekte.

Tabelle 7: Schutzbedarfsfeststellung der Datenklasse "Öffentliche Daten"

5.2.4 Schutzbedarf für Schlüssel und andere schützende Artefakte

In diesem Abschnitt wird das methodische Vorgehen zur Ermittlung des Schutzbedarfs von kryptographischen Schlüsseln und anderen schützenden Artefakten (z.B. PINs, PUKs, Token) beschrieben. Schlüssel und andere schützende Artefakte erfordern eine gesonderte Methode, da ihre Schutzbedarfe abhängig von den Informationsobjekten sind, zu deren Schutz sie genutzt werden.

Die Anwendung kryptographischer Verfahren auf Informationsobjekte führt zu einem neuen Informationsobjekt mit einem geringeren Schutzbedarf. Der Schutzbedarf des ursprünglichen Informationsobjektes ändert sich dabei nicht. Kryptographische Verfahren dienen bestimmten Schutzzielen und wirken dementsprechend auch nur auf diese reduzierend. Der Schutzbedarf für die vom kryptographischen Verfahren nicht betroffenen Schutzziele wird vom kryptographisch ungeschützten Informationsobjekt auf das kryptographisch geschützte Informationsobjekt übertragen (siehe Regel S3 und S4).

Der Schutzbedarf des ursprünglichen Informationsobjektes vererbt sich auf die eingesetzten kryptographischen Schlüssel. Damit die Verlagerung des Schutzbedarfs auf den Schlüssel insgesamt nicht zu einem geringeren Sicherheitsniveau führt, muss der Schutzbedarf des Schlüssels mindestens demjenigen des ursprünglichen Informationsobjektes entsprechen (siehe Regel S1 und S2).

Bei asymmetrischen kryptographischen Verfahren wird der Schutzbedarf des Informationsobjekts vollständig auf den privaten Schlüssel verlagert. Bei öffentlichen Schlüsseln weicht dieses Vorgehen für das Schutzziel Vertraulichkeit ab. Die Vertraulichkeit von öffentlichen Schlüsseln in der TI wird pauschal mit „mittel“ angenommen, da sie zweckgebunden nur den Teilnehmern der TI zur Verfügung stehen und außerhalb der TI nicht verwendet werden sollen.

PINs und Token sind Elemente von Authentisierungsmechanismen zum Zugriff auf Daten. Analog zu den Schlüsseln hängt der Schutzbedarf der PINs und Token vom Schutzbedarf der Daten ab, die sie schützen.

Bei der Ermittlung des Schutzbedarfs von Schlüsseln und anderen schützenden Artefakten ergeben sich zusammenfassend die folgenden Regeln:

Regel S1:    Ein asymmetrischer privater Schlüssel oder ein symmetrischer Schlüssel hat bezüglich Vertraulichkeit und Integrität mindestens den gleichen Schutzbedarf wie das Informationsobjekt, das durch ihn geschützt wird. Analog ist der Schutzbedarf eines anderen schützenden Artefakts zu behandeln.

Regel S2:    Der Schutzbedarf eines asymmetrischen öffentlichen Schlüssels bezüglich Vertraulichkeit ist „mittel“ und für das Schutzziel Integrität gleich dem des korrespondierenden privaten Schlüssels.

Regel S3:    Wird ein Informationsobjekt unter Beachtung der verbindlichen Vorgaben aus [BSI-TR-03116] symmetrisch oder asymmetrisch verschlüsselt, entsteht ein neues Informationsobjekt, dessen Schutzbedarf bezüglich Vertraulichkeit „mittel“ ist und für Integrität dem Schutzbedarf des unverschlüsselten Informationsobjekts entspricht.

Regel S4:     Wird ein Informationsobjekt unter Beachtung der verbindlichen Vorgaben aus [BSI-TR-03116] digital signiert, entsteht ein neues Informationsobjekt dessen Schutzbedarf bezüglich Integrität „niedrig“ ist und für Vertraulichkeit dem Schutzbedarf des unsignierten Informationsobjekts entspricht.

5.2.5 Prozessklassen für Anwendungsprozesse

Die Einführung von Prozessklassen folgt der gleichen Motivation wie die der Einführung von Datenklassen. Sie sollen die Durchführung von Schutzbedarfsfeststellungen für Anwendungsprozesse vereinfachen. Das Ergebnis der Herleitung der Prozessklassen findet sich als grundlegende Schutzbedarfsfeststellung im Übergreifenden Datenschutz- und Sicherheitskonzepts der TI ([gemKPT_DS_Sich_TI#Anhang B1]) wieder.

Für das Schutzziel Verfügbarkeit werden folgende Prozessklassen definiert.

5.2.5.1 Prozessklasse „ohne gravierenden Einfluss auf die Nutzung der Anwendung“

Die Nicht-Verfügbarkeit des Anwendungsprozesses hat keinen gravierenden Einfluss auf die Nutzung der Anwendung und hat keine Verstöße gegen Gesetze oder Verträge zur Folge bzw. wäre mit maximal geringfügigen wirtschaftlichen bzw. finanziellen Schäden verbunden.

Tabelle 8: Schutzbedarfsfeststellung der Prozessklasse "ohne gravierenden Einfluss auf die Nutzung der Anwendung"

5.2.5.2 Prozessklasse „mit gravierendem Einfluss auf die Nutzung der Anwendung“

Die Nicht-Verfügbarkeit des Anwendungsprozesses hätte zur Folge, dass die Aufgabenerfüllung durch Ersatzverfahren zwar noch möglich ist, die Arbeitsabläufe jedoch stark gestört sind. Die daraus resultierende Ansehens- oder Vertrauensbeeinträchtigung wäre erheblich. Zudem werden finanzielle Schäden für die betroffenen Beteiligten in hohem Ausmaß angenommen.

Tabelle 9: Schutzbedarfsfeststellung der Prozessklasse "mit gravierendem Einfluss auf die Nutzung der Anwendung"

5.2.5.3 Prozessklasse: „Verhinderung der Nutzung der Anwendung“

Die Nicht-Verfügbarkeit des Anwendungsprozesses verhindert die vollständige Ausführung der Anwendung. Es gibt keine weiteren Maßnahmen, die den Ausfall des Prozesses kompensieren oder dessen Auswirkungen reduzieren könnten. Die hieraus entstehenden Schäden wären insgesamt sehr hoch.

Tabelle 10: Schutzbedarfsfeststellung der Prozessklasse "Verhinderung der Nutzung der Anwendung"

5.2.6 Schutzbedarfsfeststellung für Komponenten und Dienste

Der Schutzbedarf von Komponenten und Diensten einer Fachanwendung ergibt sich durch die Vererbung des Schutzbedarfs der durch sie verarbeiteten Informationsobjekte und Anwendungsprozesse.

Bei der Vererbung des Schutzbedarfs von Informationsobjekten und Anwendungsprozessen an Komponenten und Dienste finden die folgenden drei grundlegenden Prinzipien Anwendung.

Maximumprinzip

Zur Ermittlung des Schutzbedarfs für jedes Schutzziel werden die möglichen Schäden in ihrer Gesamtheit betrachtet. Das Schadensszenario mit den schwerwiegendsten Auswirkungen bestimmt den Schutzbedarf.

Beachtung von Abhängigkeiten

Bei der Betrachtung der möglichen Schäden und ihrer Folgen für ein Schutzziel muss auch beachtet werden, dass Komponenten und Dienste eventuell die Informationsobjekte anderer Fachanwendungen nutzen.

Kumulationseffekt

Werden mehrere Dienste von Fachanwendungen auf derselben (Hardware-) Plattform betrieben, so ist zu überlegen, ob durch Kumulation mehrerer (bspw. kleinerer) Schäden in diesen Diensten ein insgesamt höherer Gesamtschaden entstehen kann. Dann erhöht sich der Schutzbedarf der Plattform entsprechend.

6 Business Impact Analyse

Ziel der Business-Impact-Analyse (BIA) ist die Bewertung der Kritikalität (Schadensschwere) des Ausfalls (Verlust der Verfügbarkeit) einer Komponente bzw. eines Dienstes im zeitlichen Verlauf und im Kontext der vom Ausfall betroffenen Anwendungen.

Für Komponenten, die von der gematik angeboten werden, und für alle Dienste, die einen Schutzbedarf von „hoch“ oder „sehr hoch“ für das Schutzziel Verfügbarkeit aufweisen, ist die Durchführung einer BIA obligatorisch. Für alle anderen Produkttypen ist die BIA optional.

Das Ergebnis der Business-Impact-Analyse dient dazu, auftretende Verfügbarkeitsstörungen hinsichtlich ihrer Kritikalität richtig einzuordnen und relevante Notfallszenarien in der TI, welche aus besonderen Verfügbarkeitsanforderungen resultieren, zu ermitteln.

Hierfür ist es erforderlich, für vorgegebene Zeiträume einer Nichtverfügbarkeit eine abgeschätzte Schadensschwere zuzuordnen.

Die für alle Produkttypen der TI zu betrachtenden Zeiträume sind wie folgt festgelegt:

Abbildung 8: Betrachtungszeiträume der BIA

Die Bestimmung der Schadensschwere erfolgt in den Kategorien, die auch in der Schutzbedarfsfeststellung verwendet werden:

• niedrig
• mittel
• hoch
• sehr hoch

In der Regel wird die maximal auftretende Schadensschwere nicht höher sein als der Wert, der für das Schutzziel Verfügbarkeit festgelegt wurde. Geschieht dies dennoch, so muss analysiert werden, ob die Bewertung in der BIA plausibel ist oder ob die Bewertung der Schutzbedarfsfeststellung zu niedrig ist. Falls der Wert der Schutzbedarfsfeststellung als zu niedrig bewertet wird, muss dieser auf den maximalen Wert der BIA erhöht werden und der vereinbarte Service Level muss geprüft werden. Entspricht der Service Level nicht dem (neuen) Wert der Schutzbedarfsfeststellung bzw. der BIA muss analysiert werden, ob der Service Level angehoben oder ein Risiko formuliert wird, das die Diskrepanz zwischen dem aktuellen Service Level und dem Wert aus der Schutzbedarfsfeststellung bzw. der BIA behandelt.

Im Ergebnis ergibt sich die Zuordnung der Schadensschwere für einen Zeitpunkt t zu einem Zeitraum in der folgenden Tabelle:

Tabelle 11: Zuordnung von Schadensschwere zu Zeiträumen

Ein weiteres Ergebnis der Business-Impact-Analyse ist die Darstellung, welche Anwendungen der TI von der Verfügbarkeit des betrachteten Assets zwingend, mittelbar oder optional abhängen. Dabei bedeutet

• zwingend: Bei einem Ausfall des Assets sind die wesentlichen Anwendungsfälle einer Anwendung nicht mehr ausführbar.
• mittelbar: Von einem Ausfall des Assets sind die wesentlichen Anwendungsfälle einer Anwendung nicht betroffen, jedoch ergeben sich für Nutzer der Anwendung Einschränkungen im Gesamtumfang der Anwendung.
• optional: Bei einem Ausfall des Assets sind die wesentlichen Anwendungsfälle einer Anwendung noch ausführbar. Optionale Anwendungsfälle bzw. Komfortfunktionen können jedoch nicht mehr ausgeführt werden.

Das Ergebnis kann wie folgt lauten:

Tabelle 12: Zuordnung der Abhängigkeit bei Ausfällen zu Anwendungen

7 Gefährdungskatalog/Bedrohungs- und Schwachstellenanalyse

Es ist davon auszugehen, dass die TI Angriffen ausgesetzt ist, die zu Schäden führen können und somit Risiken begründen. Bei Entwicklung und Fortschreibung der TI ist es daher von Bedeutung, möglichst alle denkbaren Angriffsszenarien zu identifizieren und zu bewerten.

Diese Betrachtung kann über einen Gefährdungskatalog erfolgen oder über eine Bedrohungs- und Schwachstellenanalyse.

7.1 Gefährdungskatalog

Der Gefährdungskatalog enthält die Gefährdungskategorien der gematik. Die Gefährdungskategorien basieren auf den BSI-Elementargefährdungen ([BSI-EleGef]) und wurden für den Zweck der Gefährdungsanalyse in die nachfolgenden Gefährdungen weiter aggregiert:

• Elementarereignisse
• Ausfall und Störung IT-Infrastruktur
• Ausfall und Störung von Systemen und Netzen
• Datenverlust
• unberechtigter Abfluss von Informationen
• unberechtigte Veränderung
• Berechtigungsmissbrauch
• Fehler durch Unterlassung oder menschliches Versagen
• Ausfall oder Störung von Personal und Dienstleistern
• Schwachstellen und Fehler in Software
• aktive Angriffe / Hacking
• Verstoß gegen Gesetze, Regelungen und Verträge
• Datenschutzverstöße
• mangelnde Nachvollziehbarkeit

Dieser Gefährdungskatalog wird in der Gefährdungsanalyse für eine Analyse im Hinblick auf eventuell vorhandene Risiken verwendet.

7.2 Bedrohungs-/Schwachstellenanalyse

Angriffsszenarien resultieren aus der Bedrohung eines betrachteten Assets unter Ausnutzung einer Schwachstelle durch einen Angreifer.

Das Ziel der Bedrohungs-/Schwachstellenanalyse ist es, systematisch alle relevanten Kategorien für Angriffsszenarien abzuleiten und diese als Eingangsparameter für die Sicherheitsanalyse zur Verfügung zu stellen.

Die Methodik liefert eine Menge von Bedrohungen, Schwachstellen und Angreifern, die durch die Anwender der Methode ausgewählt und dann individuell verfeinert werden können.

In der folgenden Abbildung ist der Zusammenhang zwischen Ausgangsüberlegungen, Bedrohungen, Schwachstellen und Angreifern bis hin zur Identifikation von Angriffsszenarien dargestellt.

Abbildung 9: Übersicht der Bedrohungs- und Schwachstellenanalyse

Dort, wo es in der Analyse eines betrachteten Aspekts sinnvoll und notwendig ist, wird in den folgenden Darstellungen die Phase angegeben, in der eine Ausprägung eines Aspekts berücksichtigt werden sollte. Die Zuordnung ist als Richtwert zu verstehen. Bei Erforderlichkeit in einer konkreten Analysesituation kann davon abgewichen werden.

7.2.1 Ausgangsüberlegungen

Die Definition von Angriffsszenarien hängt im Wesentlichen von den zugrundeliegenden Ausgangsüberlegungen ab. Mit Ausgangsüberlegungen sind in diesem Dokument alle Informationen gemeint, die vorhanden sein sollten, um die Bedrohungs- und Schwachstellenanalyse effizient durchzuführen. Würden alle möglichen Kombinationen zwischen Bedrohungen, Schwachstellen und Angreifern betrachtet, ergibt sich eine sehr große Anzahl von Angriffsszenarien für ein betrachtetes Asset. Die Ausgangsüberlegungen sind deshalb wesentlich, um die theoretisch möglichen Angriffsszenarien einzugrenzen und speziell auf die betrachtete Situation zuzuschneiden.

Es müssen die folgenden Punkte dokumentiert werden:

• Betrachtetes Asset
• Betroffene Informationsobjekte und Anwendungsprozesse
• Betroffene Schutzziele
• Grenzen der Sicherheitsleistungen

Durch die Dokumentation des betrachteten Assets wird nachvollziehbar, für was Angriffsszenarien ermittelt werden sollen (welche Komponente / Dienst mit welchem Funktionsumfang).

Die Grenzen der Sicherheitsleistung der TI ergeben sich aus dem gesetzlichen Rahmen, in dem die gematik agiert. Die gematik kann darüber hinaus nicht normativ wirken, sondern lediglich unterstützend. Die Verantwortlichkeit für die Gestaltung der lokalen Abläufe, Strukturen und Systeme verbleibt entsprechend bei den Nutzern der TI und den Herstellern und Anbietern dieser lokalen Systeme.

Für jedes betrachtete Asset sollte eine Schutzbedarfsfeststellung vorliegen (vgl. Kapitel 4), aus der sich die betroffenen Schutzziele ableiten. In jedem Schritt dieser Methode muss hinterfragt werden, welche Schutzziele betroffen sind und welche spezifischen Fragestellungen sich daraus ergeben.

7.2.2 Bedrohungen

Gemäß BSI Grundschutz Glossar ist eine Bedrohung ein Umstand oder Ereignis, der oder das die Verfügbarkeit, Integrität oder Vertraulichkeit von Informationen beeinträchtigen kann, wodurch dem Besitzer bzw. Benutzer der Informationen ein Schaden entstehen kann.

Im Folgenden werden alle relevanten Bedrohungen für die Produkte der TI strukturiert.

Bedrohungen, die die Gesellschaft der Bundesrepublik Deutschland in Gänze in einem Maß bedrohen, dass bei einem von ihnen induzierten Schaden die Mehrheit der Bevölkerung nicht mehr den Erhalt der Funktionalität der TI erwartet, werden nicht betrachtet (z. B. kosmische Ereignisse, Auflösung der gesellschaftlichen Ordnung). Es werden vier Kategorien von Ursachen vorgegeben, die mit Ausnahme der Kategorie „technisches Versagen der Umgebung“ durch Ausprägungen verfeinert sind.

Tabelle 13: Übersicht der Ursachen für Bedrohungen

Neben einer Ursache besteht eine Bedrohung immer auch aus einer Aktion. Die Aktionen können sich auf Informationen, Hard- bzw. Software und Prozesse beziehen. In der folgenden Tabelle 14 sind die möglichen Aktionen für Bedrohungen vorgegeben.

Tabelle 14: Übersicht der generischen Aktionen für Bedrohungen

7.2.3 Schwachstellen

Schwachstellen sind der zweite wesentliche Teil zur Definition eines Angriffsszenarios. Damit ein Schaden entsteht, muss eine Schwachstelle durch eine Bedrohung ausgenutzt werden.

Gemäß BSI Grundschutz Glossar ist eine Schwachstelle ein sicherheitsrelevanter Fehler eines IT-Systems oder einer Institution. Eine Schwachstelle kann dazu führen, dass eine Bedrohung wirksam wird und eine Institution oder ein System geschädigt wird. Durch eine Schwachstelle wird ein Objekt (eine Institution oder ein System) anfällig für Bedrohungen.

Die folgende Tabelle 15 stellt die Kategorisierung der Schwachstellen dar. Insgesamt werden vier Schwachstellentypen definiert und weiter ausgeprägt.

Tabelle 15: Übersicht der generischen Schwachstellentypen und -ausprägungen

In Abhängigkeit von den Ausgangsüberlegungen müssen diejenigen Schwachstellen gewählt werden, die für das betrachtete Asset als relevant angesehen werden und deshalb betrachtet werden sollen.

7.2.4 Angreifer

Schäden können nur entstehen, wenn Schwachstellen bestehen, diese bedroht werden und durch Angreifer auch tatsächlich ein erfolgreicher Angriff durchgeführt wird. In Abhängigkeit von der Rolle und der Motivation des Angreifers, sind unterschiedlich starke Sicherheitsfunktionen notwendig, um den Eintritt von Schäden zu verhindern. Soll ein System bspw. gegen Anwender geschützt werden, die auf Grund von irrtümlichen Fehleingaben Schäden herbeiführen, werden die resultierenden Sicherheitsfunktionen andere sein, als wenn das System gegen hoch motivierte und gut ausgerüstete Angreifer (Hacker) von außen geschützt werden soll.

Der Angreifer ist somit der dritte wesentliche Bestandteil für die Definition von Angriffsszenarien. Bei einem Menschen als Angreifer ist immer auch das Motiv zu analysieren. Die möglichen Kombinationen von Angreifer und Motiv sind in der folgenden Tabelle 16 abgebildet. Die Beschreibungen in diesem Dokument finden sich im Übergreifenden Datenschutz- und Sicherheitskonzepts der TI als grundlegendes Bedrohungsmodell ([gemKPT_DS_Sich_TI#Anhang B2]) wieder.

Tabelle 16: Übersicht über generische Angreiferprofile

Diese generischen Angreiferprofile werden in Tabelle 17 auf die Rollen und Akteuren der TI abgebildet:

Tabelle 17: Übersicht über Angreiferprofile der Anwendungen der TI

Hinzu kommen Angreiferprofile, die nicht aus den Rollen und Akteuren der Anwendungen der TI abgeleitet sind:

Tabelle 18: Weitere Angreiferprofile

7.2.5 Angriffsszenarien

Für die Ermittlung von Angriffsszenarien müssen die 3 Dimensionen Bedrohung, Schwachstelle und Angreifer verknüpft werden. Dabei werden wiederum nicht alle Kombinationen relevant bzw. sinnvoll sein.

Die daraus entstehenden generischen Angriffsszenarien müssen entsprechend durch die Anwendung der Methode Sicherheitsanalyse zu konkreten Angriffsszenarien verfeinert werden.

Die oben dargestellte Bedrohungsanalyse stellt eine Grundlage für detailliertere auf eine konkrete Anwendung oder ein konkretes System bezogene Analyse dar. Für weitergehende Betrachtungen von Angriffspfaden können zusätzliche Methoden wie STRIDE, PASTA, Attack Trees etc. genutzt werden.

7.2.6 Ermittlung des Angriffspotentials für Angriffsszenarien

Wenn die Ermittlung des Angriffspotenzials – also wie schwer oder leicht ein Angriff durchgeführt werden kann – erforderlich ist, soll diese entsprechend [CEM] (Common Criteria Evaluation Methodology Anhang B.4) vorgenommen werden.

7.2.7 Vererbung von Bedrohungen

Eine Vererbung von Bedrohungen findet in Situationen statt, in denen ein Teilsystem – für das eine gesonderte Bedrohungsanalyse erstellt wurde – integraler Bestandteil eines Gesamtsystems wird. Die Bedrohungsanalyse für das Teilsystem fließt dabei in die Bedrohungsanalyse des Gesamtsystems ein.

Aus Sicht des Teilsystems können Bedrohungen existieren, deren Wirksamkeit von der Sicherheit des Gesamtsystems und der Integration des Teilsystems in das Gesamtsystem abhängt.

Dabei kann bei dieser Sichtweise innerhalb der Bedrohungsanalyse für das Teilsystem nicht entschieden werden, ob das Gesamtsystem Schwachstellen besitzt, die im Zusammenwirken mit der Bedrohung zu einem Risiko des Gesamtsystems führen könnten. Diese Analyse muss aus Sicht des Gesamtsystems erfolgen.

In der Bedrohungsanalyse des Teilsystems werden solche Bedrohungen mit „Bedrohung für das Gesamtsystem“ gekennzeichnet.

Nach der Übernahme dieser Bedrohungen in die Bedrohungsanalyse des Gesamtsystems erfolgt in der Sicherheitsanalyse (siehe folgendes Kapitel) des Gesamtsystems die Beurteilung, ob die Bedrohungen vollständig abgewehrt werden, oder eine Risikoanalyse erforderlich ist. Abbildung 10 verdeutlicht diesen Zusammenhang.

Abbildung 10: Vererbung von Bedrohungen

In der Betrachtung der Sicherheit des Teilsystems können auch Risiken identifiziert werden. Der Umgang damit aus Sicht des Gesamtsystems wird in Kapitel 9 behandelt.

8 Gefährdungs-/Sicherheitsanalyse

Die Gefährdungsanalyse und die Sicherheitsanalyse sind die zentralen Methoden innerhalb der Methodik der Sicherheitskonzeption im Entwicklungsprozess zur Beurteilung der Sicherheit eines Produkttyps der TI. Gefährdungs- und Sicherheitsanalyse können unabhängig voneinander durchgeführt werden. Dabei gewährleistet die Gefährdungsanalyse eine erste Gesamteinschätzung und kann durch eine erweiterte Sicherheitsanalyse vertiefend ergänzt werden.

Durch die Anwendung dieser Methoden soll die Frage beantwortet werden, ob ein betrachtetes Asset in Verbindung mit allen spezifizierten Sicherheitsfunktionen bzw. -maßnahmen ausreichend geschützt ist.

Der Kombination aus dem betrachteten Asset und Gefährdungen aus dem Gefährdungskatalog bzw. Angriffsszenarien aus der Bedrohungs- und Schwachstellenanalyse werden die Sicherheitsfunktionen bzw. -maßnahmen entgegengestellt.

8.1 Gefährdungsanalyse

Im Rahmen der Gefährdungsanalyse wird jedes Asset (hier insbesondere Komponenten und Dienste) dahingehend analysiert, ob die bestehenden Sicherheitsmaßnahmen ausreichend sind, um Risiken für das Asset aufgrund der Gefährdung aus dem Gefährdungskatalog ausschließen zu können. Folgende Auswahlmöglichkeiten bestehen:

• Nicht relevant: Die Gefährdung ist für das betrachtete Asset nicht relevant, da die Bedrohung oder Schwachstelle nicht für das Asset anwendbar ist.
• Relevant – Sicherheitsmaßnahmen ausreichend: Die Gefährdung ist anwendbar, aber durch die getroffenen Maßnahmen ausreichend abgewendet.
• Relevant – Risikoanalyse erforderlich: Die Gefährdung ist anwendbar und nicht ausreichend abgewendet. Es muss eine Risikoanalyse durchgeführt werden.

Abbildung 11: Ablauf der Gefährdungsanalyse

8.2 Sicherheitsanalyse

In der Sicherheitsanalyse wird ein betrachtetes Asset mit Missbrauchs- und Angriffsszenarien angegriffen, um so herauszufinden und beurteilen zu können, ob Angriffe adäquat abgewehrt werden können. In der Sicherheitsanalyse des Assets wird entschieden, ob die das Asset schützenden Maßnahmen das Asset ausreichend schützen.

Abbildung 12: Ablauf der Sicherheitsanalyse

Für die Beurteilung, ob ein betrachtetes Asset mit den zugeordneten Maßnahmen den Missbrauchs- und Angriffsszenarien standhält und somit als sicher gilt, wird ein Modell mit verschiedenen Fragen zur Verfügung gestellt. Sollte ein betrachtetes Asset als sicher bestätigt werden, da die vorgesehenen Maßnahmen ausreichend sind, um die Angriffe abzuwehren, so werden diese Sicherheitsfunktionen bzw. -maßnahmen dokumentiert (z.B. in einer Spezifikation) und gelten als validiert.

Sollte hingegen festgestellt werden, dass ein Missbrauchs- bzw. Angriffsszenarium erfolgreich durchgeführt werden kann und der Schutzbedarf eines Informationsobjekts oder Anwendungsprozesses in einem betrachteten Asset verletzt werden kann, wird eine Risikoanalyse durchgeführt, um beurteilen zu können, ob weitere Verbesserungsmaßnahmen ergriffen werden müssen oder ein akzeptierbares Restrisiko vorliegt, welches nicht weiter reduziert werden muss oder kann. Wird das identifizierte Restrisiko nicht akzeptiert, müssen Maßnahmen erdacht und umgesetzt werden, die die Sicherheit verbessern. Nach der Konzeption dieser zusätzlichen Maßnahmen muss die Sicherheitsanalyse erneut angewendet werden, um die Sicherheit beurteilen zu können.

Die Schritte der Sicherheitsanalyse werden folgend im Detail erläutert.

8.2.1 Vorbereitung der Sicherheitsanalyse

Im ersten Schritt werden die für die Sicherheitsanalyse benötigten Informationen gesammelt und strukturiert.

Zu betrachtendes Asset auswählen

In diesem Schritt der Sicherheitsanalyse wird ermittelt, welches Asset, mit welchem Schutzbedarf, durch welche Maßnahmen geschützt wird. Das Ergebnis dieses Methodenteils bildet somit die Grundlage für die Ermittlung und Durchführung von Angriffen, um die Sicherheit beurteilen zu können. Das betrachtete Asset beschreibt die Komponente bzw. den Dienst der Architektur, für die/den die Sicherheit beurteilt werden soll.

Die Granularität oder der Abstraktionslevel des zu betrachtenden Assets ist nicht festgelegt und kann situationsabhängig gewählt werden. Es sind grundsätzlich zwei Herangehensweisen möglich:

Top Down:

Das zu betrachtende Asset wird beginnend auf einer globalen Ebene beschrieben und es werden globale Sicherheitsfunktionen betrachtet. Die Informationsobjekte und Anwendungsprozesse, die in diesem Asset verarbeitet werden, werden global betrachtet und nicht auf die einzelnen Bestandteile der Architektur heruntergebrochen. Im Fokus der Betrachtung stehen die globale Sicherheit des betrachteten Assets und allgemeine Angriffsmöglichkeiten. Aufbauend auf Ergebnissen der Sicherheitsanalyse kann das Asset schrittweise verfeinert werden.

Bottom Up:

Das zu betrachtende Asset wird als kleinster anzunehmender Bestandteil einer Architektur beschrieben. Es wird betrachtet, ob dieser kleine bzw. atomare Bestandteil der Architektur im Detail angegriffen werden kann. Wenn die Sicherheit auf dieser Ebene erreicht wird, kann der Umfang des Assets erweitert werden.

Informationsobjekt- und Anwendungsprozess-Assets (mit Schutzbedarf) auflisten

Im nächsten Schritt muss ermittelt werden, welche Informationsobjekte und Anwendungsprozesse) in dem betrachteten Asset verarbeitet werden. Für jedes Informationsobjekt und jeden Anwendungsprozess sollte bereits durch Anwenden der Methode Schutzbedarfsfeststellung ein Schutzbedarf ermittelt worden sein.

Maximalen Schutzbedarf ermitteln

In einer komplexen Architektur können mehrere Assets, mit unterschiedlichen Anforderungen an den Schutzbedarf, in denselben Bestandteilen eines zu betrachtenden Assets verarbeitet werden. Gemäß der Anwendung des Maximumprinzips muss sich der Schutz des betrachteten Assets nach dem Informationsobjekt- und Anwendungsprozess-Asset mit dem höchsten Schutzbedarf richten.

Falls sich das betrachtete Asset in mehrere Bestandteile untergliedern lässt, kann für das Asset abgetragen werden, welche Informationsobjekt- und Anwendungsprozess-Assets in welchem Bestandteil, mit welchem Schutzbedarf, verarbeitet werden, um den höchsten Schutzbedarf pro Bestandteil zu ermitteln.

Sicherheitsmaßnahmen zuordnen

In diesem Schritt werden die Sicherheitsfunktionen bzw. -maßnahmen gesammelt, die dazu dienen, die im betrachteten Asset befindlichen Informationsobjekt- und Anwendungsprozess-Assets gegen verschiedene Angriffsmöglichkeiten zu schützen. Zur besseren Nachvollziehbarkeit sollten die Sicherheitsfunktionen zuerst aufgelistet und dann dem betrachteten Asset zugeordnet werden.

Ermittlung von Angriffsszenarien

Die Bedrohungs- und Schwachstellenanalyse liefert generische Angriffsszenarien mit ggf. zugeordneten Angriffspotentialen.

8.2.2 Durchführung der Sicherheitsanalyse

Der Grundsatz der Sicherheitsanalyse ist: Wenn kein erfolgreiches Angriffsszenario gefunden wird, dann gilt das betrachtete Asset mit den Sicherheitsmaßnahmen als ausreichend sicher. Oder anders formuliert: Sollte ein Angriffsszenario gefunden werden, mit dem ein Asset geschädigt werden kann, dann gilt das betrachtete Asset mit den Sicherheitsmaßnahmen als nicht ausreichend geschützt.

Als Input für diese Stufe werden das betrachtete Asset, die generischen Angriffsszenarien und die Sicherheitsmaßnahmen benötigt.

Stufe 1: generische Angriffsszenarien

In der ersten Stufe wird grundsätzlich geprüft, ob aus den definierten generischen Angriffsszenarien spezifische Angriffe entwickelt werden können. Zur Unterstützung der Entscheidung kann die folgende Frage verwendet werden.

Tabelle 19: Frage zur Stufe 1 der Sicherheitsanalyse

Unter Beachtung der Frage muss für jedes generische Angriffsszenario geprüft und dokumentiert werden, ob ein Angriff möglich ist.

Stufe 2: Verfeinerung der generischen Angriffsszenarien

In der zweiten Stufe wird detailliert geprüft, ob die zutreffenden generischen Angriffsszenarien derart konkretisiert und erweitert werden können, dass spezielle Schwachstellen des betrachteten Assets inkl. Sicherheitsmaßnahmen ausgenutzt werden können. Für das Finden der konkreten Angriffsszenarien ist Spezialwissen notwendig. Das Finden von Angriffsszenarien und die Beurteilung, ob das betrachtete Asset mit den Sicherheitsmaßnahmen diesem Angriff standhält, gehen stark ineinander über.

Zur Unterstützung für den Erkenntnisprozess können die in Tabelle 20 dokumentierten Fragen genutzt werden.

Tabelle 20: Fragen zur Stufe 2 der Sicherheitsanalyse

8.2.3 Ergebnis der Sicherheitsanalyse

Das Ergebnis der Sicherheitsanalyse ist die Bewertung jedes einzelnen Angriffsszenariums nach dem oben genannten Vorgehen. Ein Ergebnis kann einen der folgenden Werte (Der Wortlaut der Ergebniswerte ist beispielhaft und kann in einer konkreten Dokumentation anders lauten.) erhalten:

• Maßnahmen ausreichend

Die getroffenen Maßnahmen reichen aus, um das Angriffsszenarium abzuwehren. Es besteht kein Risiko.

• Risikoanalyse erforderlich

Wenn festgestellt wurde, dass die getroffenen Maßnahmen nicht ausreichen und der formulierte Angriff möglich ist, muss eine Risikoanalyse durchgeführt werden (vgl. Kapitel 9).

• Grenze der Sicherheitsleistung (optional)

Sofern Angriffsszenarien formuliert wurden, die auf potenziellen Schwachstellen außerhalb der TI beruhen, werden diese als Grenze der Sicherheitsleistung bewertet. Alternativ können die Grenzen der Sicherheitsleistungen der TI, die in der Betrachtung eines Assets eine Rolle spielen, in einem gesonderten Kapitel des Datenschutz- und Sicherheitskonzepts dokumentiert werden (vgl. Kapitel 10).

• Bedrohung des Gesamtsystems (optional)

Sofern Angriffsszenarien für einen Teil eines Gesamtsystems formuliert wurden, die auf potenziellen Schwachstellen außerhalb des Teilsystems aber innerhalb des Gesamtsystems beruhen, werden diese als Bedrohung des Gesamtsystems bewertet (vgl. Kapitel 7.2.7).

9 Risikoanalyse

Die Methode zur Risikoanalyse für Informationssicherheitsrisiken (IS-Risiken) der TI beschreibt, wie IS-Risiken, die Produkttypen der Telematikinfrastruktur betreffen, erfasst, bewertet und behandelt werden.

Die Risikoanalyse ist durchzuführen, wenn sich aus dem Ergebnis der Gefährdungsanalyse bzw. der Sicherheitsanalyse eine Notwendigkeit hierzu ergibt, oder wenn Informationssicherheitsrisiken im operativen Betrieb zu einer Produktinstanz erkannt werden.

Die Risikoanalyse ist der Richtlinie Risikomanagement [RL_RMS] beschrieben und wird durch deren Anhang für den Bereich Sicherheit konkretisiert.

Neben den Risiken, die in der Risikoanalyse für einen Produkttyp der TI identifiziert wurden, erbt der Produkttyp ggf. Risiken von Teilsystemen innerhalb des Produkttyps, für die gesonderte Risikoanalysen durchgeführt wurden (vgl. 7.2.7). Die für das Teilsystem identifizierten Risiken werden dabei mit dem Asset, das den jeweiligen Produkttyp des Gesamtsystems repräsentiert, verknüpft, so dass die Risiken in der Liste der Risiken des Gesamtsystems (Produkttyps) geführt werden.

Diese Form der Vererbung von Risiken erfolgt auch, wenn Risiken, die für einen Produkttyp identifiziert wurden, auch Risiken für andere Produkttypen sind.

10 Grenzen der Sicherheitsleistung

Die Grenzen der Sicherheitsleistung für die Komponenten und Dienste der TI ergeben sich aus dem gesetzlichen Rahmen in dem die gematik agiert. Die gematik kann darüber hinaus zwar nicht normativ aber zumindest unterstützend wirken. Im Endeffekt verbleibt die Verantwortlichkeit für die Gestaltung der lokalen Abläufe, Strukturen und Systeme bei den Nutzern und anderen Kommunikationspartnern der TI sowie ihren Herstellern und Anbietern in Form von Mitwirkungspflichten.

Bedrohungen und Schwachstellen – und damit mögliche Angriffs- bzw. Missbrauchsszenarien –, die im Gesamtkontext der medizinischen Versorgung außerhalb der Systemgrenzen der TI auftreten können, müssen durch die jeweils verantwortlichen Regulierungs- bzw. Aufsichtsorgane betrachtet und ggf. abgewendet werden. Gleichwohl bieten die Komponenten und Dienste der TI hierfür in einzelnen Fällen unterstützende Leistungen an.

Die Grenzen der Sicherheitsleistung zu dokumentieren, ist ein Weg um Transparenz über Angriffsszenarien herzustellen, die nicht als Risiko für die Komponente bzw. den Dienst formuliert werden, da ggf. zu treffende Abhilfemaßnahmen nicht innerhalb der TI bzw. durch die gematik ergriffen werden können.

Bei der Gestaltung von Produkttypen der TI sind folgende Punkte hinsichtlich der Grenzen der Sicherheitsleistung zu beachten:

• Mitwirkungspflichten sind so gering wie möglich zu halten.
• Mitwirkungspflichten sind zu beschreiben und an den Adressaten zu kommunizieren.
• Sofern möglich, sollte die Einhaltung von Mitwirkungspflichten von der TI bzw. der gematik sowie den zuständigen Aufsichtsbehörden überwacht werden.
• Die Auswirkungen auf die TI sind bei Nichteinhaltung der Mitwirkungspflichten durch mitigierende Maßnahmen in der TI so gering wie möglich zu halten.

11 Anhang A – Verzeichnisse

A1 – Abkürzungen

A2 – Glossar

Das Projektglossar wird als eigenständiges Dokument zur Verfügung gestellt.

A3 – Abbildungsverzeichnis

A4 – Tabellenverzeichnis

A5 – Referenzierte Dokumente

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur.

Folgende Dokumente sind gematik intern und werden nicht veröffentlicht:

Weitere Referenzierungen: