grün, ab 6 rot

Potenzieller Schaden

gering = 1 mittel = 2 hoch = 3

Eintritts- wahrscheinlichkeit ^{normal = 1}

hoch = 2

sehr hoch = 3

1

2

3

2

4

6

3

6

9

Tabelle 1: Risikomatrix: Bewertungsschema für die Ermittlung des Risikos der Gefährdungsszenarien

4 / Studie zum exemplarischen Anwenden von Gefährdungsszenarien in der Energiedomäne

den BSI­Kreuzreferenztabellen von elementaren Gefährdungen und Anforderungen ableiten und ist in der folgenden → Tabelle 3 dargestellt. Dabei sind nur die Anforderungen aufgelistet, die in dem Anwendungsfall Verwendung finden. Die Bedeu-tungen der Anforderungen sowie entsprechende Referenzen sind im Anhang in → Abschnitt 7.2.5 (in → Abschnitt 5 des MUC­Templates) tabellarisch dargestellt.

Zusätzlich wurden für den Anwendungsfall folgende Sicherheitsanforderungen als notwendig erachtet: ISMS.1, ORP.5, CON.2, CON.5, CON.6, DER.3.1, DER.4, INF.1, INF.2, INF.3, INF.4, INF.5.

Auch diese Anforderungen werden im Anhang in → Abschnitt 7.2.5 (in → Abschnitt 5 des MUC­

Templates) genauer erläutert und tabellarisch dargestellt.

In der → Tabelle 7.2.4.1 im Anhang werden für die bessere Verständlichkeit zu den identifizierten Sicherheitsanforderungen jeweils zwei Beispiele für die konkretere Umsetzung genannt. Diese Beispiele zielen sowohl auf organisatorische als auch auf technische Maßnahmen ab. Für den Angriff „A1­1 Ausspähen“ spielt beispielweise für die Absicherung ein gutes „Kryptokonzept“ (CON.1) eine Rolle, um damit dann geeignete kryptografische Ver fahren auszuwählen und damit dann die Kom munika tions­

verbindung passend zu verschlüsseln.

Manche der genannten Sicherheitsanforderungen müssen nicht zwangsweise von den Entwicklern konkret realisiert werden, wenn die entsprechenden Szenarien spielen sich regional sehr begrenzt ab,

sozusagen auf Nachbarschafts­ bzw. Haushalts­

ebene, so dass keine größeren Ausfälle zu befürch­

ten sind. Da es sich in dem Anwendungsfall ins­

gesamt mit einem virtuellen Kraftwerk um ein regional begrenztes Szenario handelt, ergeben sich für die Risiken der beschriebenen Szenarien A2 und A3 ein niedriges Risiko und für das Szenario A1 ein mittleres Risiko, da mit dem MV / LV SCADA­System bereits eine größere Zahl an virtuellen Kraftwerken gesteuert wird, was in Tabelle 2 dargestellt ist.

Dies lässt sich ebenfalls damit begründen, dass das Schutzziel Verfügbarkeit in der Energiedomäne die höchste Priorität der CIA­Schutzziele aufweist.

Aus dieser Risikoanalyse kann ein Entwickler für die konkrete Implementierung Schlüsse ziehen, um die Art, den Grad und die Menge der Sicherheits­

maßnahmen geeignet auszuwählen.

Die Festlegung des potenziellen Schadens und der Eintrittswahrscheinlichkeit erfolgt in der Schritt­für­

Schritt­Analyse des Misuse Cases in → Abschnitt 4 des MUC­Templates, das im Anhang in → Kapitel 7.2 dokumentiert ist.

5.2.3 Identifikation von

Sicherheits anforderungen

Abschließend werden den einzelnen Schritten der Gefährdungsszenarien Sicherheitsanforderungen aus → Abschnitt 5 des MUC­Templates zugeordnet, um die Gefährdungen zu vermeiden oder mindes­

tens zu vermindern. Diese Zuordnung lässt sich aus

Angriffs-szenario Nr.

A1 A2 A3

Denial of Service-Angriff (DoS) Manipulation der Datenintegrität

Tabelle 2: Auswertung des Risikos der Angriffsszenarien aus dieser Studie

4 / Studie zum exemplarischen Anwenden von Gefährdungsszenarien in der Energiedomäne

heitsniveau zu erreichen. Weiterhin muss bei dieser Auswahl der Sicherheitsmaßnahmen die ent sprechende Risikoanalyse mitberücksichtigt werden. Falls eine Zertifizierung nach ISO 27000 nach IT­Grundschutz realisiert werden soll / muss, sollten ebenfalls die BSI­Bausteine angemessen umgesetzt werden.

Funktionalitäten / Dienstleistungen nicht in Anspruch genommen werden. Dann sind diese Sicherheitsanforderungen als optional zu betrachten.

Die identifizierten Sicherheitsanforderungen geben den Entwicklern Anhaltspunkte, welche Sicher­

heitsmaßnahmen konkret in der Implementierung notwendig sind, um ein möglichst hohes Sicher­

Angriffsschritt A1-1 A1-2 A2-1 A3-1 A3-2

DoS-Angriff Content Spoofing MITM-Angriff Ausspähen

Man-in-the-middle

ORP.1, ORP.2, ORP.3, ORP.4, CON.1, CON.8, CON.9, OPS.1.1.2, NET.4.1, INF.7, INF.8,

INF.9, INF.10

ORP.1, ORP.2, ORP.4, CON.1, CON.3, CON.4, CON.8, CON.9, OPS.1.1.2,

OPS.1.1.5, OPS.1.2.2, OPS.1.2.4, OPS.1.2.5, OPS.2.1, OPS.2.2, OPS.3.1, DER.1, DER.2.1, DER.2.2, DER.2.3, APP.1.1,

APP.1.2, APP.2.1, APP.2.2, APP.2.3, APP.3.1, APP.3.2, APP.3.6, APP.4.2, APP.4.3, APP.4.6, APP.5.2, SYS.1.1,

SYS.1.2.2, SYS.1.3, SYS.1.5, SYS.1.7, SYS.1.8,

SYS.2.1, SYS.2.2.2, SYS.2.3, SYS.3.1, SYS.3.2.1, SYS.3.2.2,

SYS.3.2.3, SYS.3.3, SYS.4.1, SYS.4.3, SYS.4.5, IND.2.1, IND.2.2, IND.2.4, NET.1.1, NET.1.2, NET.3.1, NET.3.2, NET.3.3, NET.4.3,

INF.7, INF.8, INF.9.

links in dieser Tabelle.

G 0.14 Ausspähen von Informationen

(Spionage)

G 0.40 Verhinde-rung von Diensten (Denial of Service)

G 0.22 Manipulation

von Informationen G 0.43 Einspielen von Nachrichten

G 0.14 Ausspähen von Informationen

(Spionage)

Tabelle 3: Zuordnung von Sicherheitsanforderungen nach BSI-IT-Grundschutz-Bausteinen

4 / Studie zum exemplarischen Anwenden von Gefährdungsszenarien in der Energiedomäne

Misuse Case­Template (MUC­Template), das an das UC­Template angelehnt ist, erfasst und doku­

mentiert. Im MUC­Template erfolgte danach ebenfalls die Analyse der Szenarien. Dafür wurden eine Risikoanalyse der Szenarien durchgeführt und standardisierte Sicherheitsanforderungen identi­

fiziert, was das Ergebnis dieser Studie darstellt. Die Erfassung und Dokumentation im MUC­Template erfolgte im Anhang in → Abschnitt 7.2.

6.2 Diskussion

Als nächster Schritt nach der Analyse mit den Misuse Cases können die ermittelten Risiken und die identifizierten Sicherheitsanforderungen dann von den Entwicklern bei der realen Implemen­

tierung des Systems herangezogen werden, um die Sicherheitsanforderungen in einem angemessenen Grad auf Basis der Risikoanalyse in konkrete Sicherheitsmaßnahmen umzusetzen. Dies kann zu Herausforderungen führen, da eine angemessene Sicherheit auch immer eine Gradwanderung ist:

Es sollen nicht übertrieben viele Mittel umgesetzt werden, was u.a. zu unnötigem Einsatz von Kapital führt, aber auch nicht zu wenig Maßnahmen ergriffen werden, was Angreifer anlocken könnte.

Insgesamt wird empfohlen ein System nach BSI­

IT­Grundschutz, ISO 27000 oder entsprechenden domänenspezifischen Versionen abzusichern und damit ein ISMS für das entsprechende System für ein kontinuierliches Sicherheitsmanagement zu Diese Studie beschäftigte sich mit dem exemplari­

schen Anwenden von Gefährdungsszenarien in der Energiedomäne. Fokus war die Verwendung solcher Szenarien bereits in der Systementwicklung, um dem Thema Informationssicherheit insgesamt eine höhere Priorität zu geben, das Prinzip Security­

by­Design weiterzuentwickeln und Systeme insge­

samt sicherer zu machen. Hierfür wurde eine Gesamt methodik aus verschiedenen standardisier­

ten Vorgehensweisen entwickelt. Im Rahmen des Themen feldes Resilienz soll mit dieser Methodik die Behandlung von Zwischenfällen im Vorfeld („fest­

stellen und verhindern“) erfolgen. Gefährdungs­

szenarien werden hier mit einer Risikoanalyse bewertet und entsprechende Sicherheitsanforde­

rungen für die Verhinderung identifiziert. Die Gesamtmethodik wurde in → Abschnitt 4.6 vorge­

stellt und dann im Folgenden beispielhaft angewen­

det. Die textuelle Beschreibung der Anwendung der Gesamtmethodik erfolgte in → Abschnitt 5.

6.1 Zusammenfassung

Zu Beginn wurde ein Anwendungsfall aus der Energiedomäne, ein virtuelles Kraftwerk in einer Überlastsituation, als passendes Beispiel ent­

wickelt. Dieser Anwendungsfall wurde dann mit dem Use Case­Template (UC­Template) nach IEC 62559 systematisch und standardisiert erfasst.

Die Erfassung und Dokumentation im UC­Template erfolgte im Anhang in → Abschnitt 7.1. Für diesen Anwendungsfall wurden weiterhin drei verschiede­

:// 6.

ZUSAMMENFASSUNG,

Im Dokument Digitalisierung, Daten und Sicherheit: Herausforderungen für Unternehmen in der EnergiewirtschaftBerlin, Mai 2021Kompendium (Seite 140-143)