Content uploaded by Peter Kieseberg
Author content
All content in this area was uploaded by Peter Kieseberg on Jul 25, 2021
Content may be subject to copyright.
293
Evaluierung des Cyber Lagebildkonzepts
im praktischen Einsatz
Miriam Kaundert, Louis Ziegler, Timea Pahi, Florian Skopik, Maria
Leitner, Peter Kieseberg, Bernhard Schwanzer und John Kojo
Ampia-Addison
Zusammenfassung
Der im Rahmen des CISA Projektes erstellte technische Demonstrator wurde in einer
eintägigen, iterativen Planspielübung analysiert und für einen möglichen Realeinsatz
evaluiert. Die praktische Anwendung des Demonstrators durch die Teilnehmenden
stellte einen Abgleich der entwickelten Cyber Incident Situational Awareness (CISA)
-Denition mit einer möglichen Anwendungsrealität dar und agierte als Feuerprobe für
die Nützlichkeit der dargestellten Datentypen und -verknüpfungen zur Lagebeurtei-
lung durch Identikation von Schwachstellen in den verwendeten Visualisierungsop-
tionen. Diese Tauglichkeitsprüfung soll zur Schärfung der Bedürfnisse – einerseits für
die Nutzung von Daten zur Lagebeurteilung, andererseits für die Schulung zukünftiger
Operateure – beitragen. Hierbei wurde vor allem der Bedarf nach intensivem Training
und klarer Rollendenition einerseits für die Operateure eines Lagezentrums, anderer-
seits für das Lagezentrum selbst, aufgezeigt. Eine der Kernbeobachtungen waren die
8
M. Kaundert (*) · L. Ziegler
Infraprotect, Gesellschaft für Risikoanalyse, Notfall- und Krisenmanagement GmbH, Wien,
Österreich
e-mail: m.kaundert@infraprotect.com; l.ziegler@infraprotect.com
T. Pahi · F. Skopik · M. Leitner
Center for Digital Safety & Security, AIT Austrian Institute of Technology, Wien, Österreich
e-mail: timea.pahi@ait.ac.at; orian.skopik@ait.ac.at; maria.leitner@ait.ac.at
P. Kieseberg
SBA Research, Wien, Österreich
e-mail: pkieseberg@sba-research.org
B. Schwanzer · J. Kojo Ampia-Addison
Thales Austria, Wien, Österreich
e-mail: bernhard.schwanzer@thalesgroup.com; john.addison@thalesgroup.com
© Springer-Verlag GmbH Deutschland, ein Teil von Springer Nature 2018
F. Skopik et al. (Hrsg.), Cyber Situational Awareness in Public-Private-Partnerships,
https://doi.org/10.1007/978-3-662-56084-6_8
294 M. Kaundert et al.
unterschiedlichen Wünsche einerseits nach „mehr“ Daten und mehr Information und
andererseits nach aggregierterer Darstellung und ausgeprägterer Interpretation durch
die Software. Der Umgang mit Informationsunsicherheit in der Lagebeurteilung wird
daher einen besonders prominenten Fokus für zukünftige Operateure darstellen. Eine
vollautomatisierte Darstellung eines Lagebildes, in welcher das Softwaretool selbst
eine Beurteilung der Lage erstellt und ausgibt, konnte mit den vorliegenden Mitteln
nicht erreicht werden und es muss in Zukunft beurteilt werden, in welchem Ausmaß
eine maschinelle Interpretation von Daten zur Lagebilderstellung einerseits möglich
und andererseits erwünscht ist. Nach Auswertung des durchgeführten Planspiels ist die
Aufwendung menschlicher „Übersetzungsleistung“ für die Entwicklung einer Lageein-
schätzung unabdingbar.
8.1 Das Projekt CISA und das CISA Planspiel
Zielsetzung des im FFG Sicherheitsforschungsproggramm KIRAS1 geförderten Projektes
CISA2 („Cyber Incident Situational Awareness“) war die Erarbeitung und Denition des
Begriffs der „Cyber Situational Awareness“ (CSA; Lageverständnis), und eine konkrete
Ausarbeitung welche Entscheidungen aufgrund einer erhobenen Cyber-Lage getroffen
werden können/müssen und wie die Informationen aus den technisch/operativen Daten-
quellen aufbereitet und dargestellt werden müssen, damit Behörden und Bedarfsträger
optimal agieren können. Das Projekt CISA stellte eine konsequente Zusammenfüh-
rung der bisherigen Forschungsaktivitäten dar, um in einem wissenschaftlich fundierten
Konzept den Prozess zur Etablierung allumfassender Cyber Situational Awareness aus
technisch-operativen Informationen aus dem Cyberspace zu erarbeiten. Neben der Metho-
denentwicklung wurden auch Demonstrationsszenarien aufgebaut, um die Methodik der
Etablierung von Cyber Situational Awareness und dessen Verwendbarkeit in einer Real-
World Umgebung testen und evaluieren zu können.
Der im Rahmen des KIRAS Sicherheitsforschungsprojekts CISA erstellte technische
Demonstrator wurde in einer eintägigen, iterativen Planspielübung analysiert und für
einen möglichen Realeinsatz evaluiert. Das Konzept „Übung“ ist als Trainingsinstrument
für Personen welche mit der Bewältigung außergewöhnlicher Ereignisse betraut sind, eta-
bliert (Honger et al. 2016) und wird im europäischen Kontext auch intensiv angewendet.
Eine weitere Anwendungsmöglichkeit einer Übung ist die Überprüfung einer Organisa-
tion oder eines Entwurfes (Boin et al. 2004), was auch ihr Einsatzzweck im vorliegenden
Zusammenhang war. Eine Leistungsbewertung der Teilnehmenden wurde nicht durchge-
führt und war auch zu keinem Zeitpunkt Ziel des Planspiels.
1 KIRAS, http://www.kiras.at/ (Letzter Zugriff: 21.05.2018)
2 CISA, http://www.kiras.at/gefoerderte-projekte/detail/d/cisa-cyber-incident-situational-awareness/
(Letzter Zugriff: 21.05.2018)
8 Evaluierung des Cyber Lagebildkonzepts im praktischen Einsatz 295
Die praktische Anwendung des Demonstrators durch die Teilnehmenden stellte viel-
mehr einen Abgleich der entwickelten Cyber Situational Awareness (CSA)-Denition
(vgl. Kap. 1) mit einer möglichen Anwendungsrealität dar und agierte als Feuerprobe
für die Nützlichkeit der dargestellten Datentypen und Datenverknüpfungen (vgl. Kap.7)
zur Lagebeurteilung durch Identikation von Schwachstellen in den verwendeten Visu-
alisierungsoptionen. Der praktischen Anwendung des Tools durch Teilnehmende mit
unterschiedlichen professionellen Backgrounds kam hier besondere Bedeutung zu, ver-
tritt ein potenzielles Lagezentrum doch den Anspruch, ein gemeinsames Lagebild für alle
Akteuere bieten zu können. Diese Tauglichkeitsprüfung soll zur Schärfung der Bedürf-
nisse, einerseits für die Nutzung von Daten zur Lagebeurteilung, andererseits für die Schu-
lung zukünftiger Operateure, beitragen.
Zur Überprüfung der Leistungsfähigkeit des Demonstrators wurden Indikatoren fest-
gelegt, welche im Rahmen der Durchführung erhoben und im Anschluss ausgewertet
wurden. Der Anspruch in diesem Kontext kann keine Beherrschung einer Krise sein – dies
ist eine unrealistische Erwartung, da den Teilnehmenden die nötigen Ressourcen nicht
zur Verfügung standen. Umso größere Bedeutung kam der Darstellung des Lagebildes
zu, welches zur Lagebeurteilung genutzt wurde und das einen efzienten Umgang mit
eingehender Information und deren Aufbereitung und Weitergabe an Entscheidungsträger
ermöglicht (Clarke 1999).
Das vorliegende Kapitel beschreibt Aufbau, Konzeption und Ablauf des Planspiels,
seine methodischen Ansätze und Evaluierungsschritte und bietet eine Interpretation der
Ergebnisse.
8.1.1 Konzept der Pilotumgebung
Das Ziel des CISA Planspiels bestand in erster Linie in der Evaluierung des CSA Konzepts
und der Etablierung der Methodik zur Bildung einer CSA. Im Zuge einer Stabsrahmen-
übung wurden die möglichen Lagebilddarstellungen (siehe Cyber-Lagebilder in Kap.2)
in einem simulierten Cyber-Lagezentrum evaluiert. Die Ergebnisse und Erkenntnisse aus
dem Planspiel sollen bei der Ableitung von Anforderungen an Cyber-Lagebilder, bei der
Auswahl von Visualisierungen zur Cyber-Lagebilddarstellung und der Nutzung der Tools
in Szenarien, als auch bei der Entwicklung eines Curriculums für Operateure des Lage-
zentrums unterstützen.
Ziel der Evaluierung waren daher weder die Fähigkeiten, noch das technische Ver-
ständnis der Übenden zu bewerten. Die Evaluierung bezog sich auf die Visualisierungs-
Software (Demonstrator) und ihre Möglichkeiten, Datentypen und Datenverknüpfungen
darzustellen. Dabei stand die Flexibilität bei der Anpassung auf konkrete Anforderungen
der Lagezentren (LZ) im Fokus.
Es wurde ein iterativer Ansatz gewählt, bei dem die Teilnehmenden (TN) als Opera-
teure in einem ktiven Lagezentrum über drei Runden mit Inputs zu einem möglichen
Cyberangriff auf kritische Infrastrukturen in Österreich konfrontiert wurden. Jede Iteration
296 M. Kaundert et al.
dauerte zwischen eineinhalb und zwei Stunden und war als eigenes Szenario zu verstehen,
welches losgelöst von den anderen im Rahmen einer Lagebeurteilung eingeschätzt werden
musste.
Die dem Planspiel zugrunde liegende Konzeption soll zwar insbesondere auf die Lage-
bilddarstellung im Rahmen eines Cyber-Sicherheitsszenarios abzielen, sie kann aber auch
für fast alle anderen Übungstypen herangezogen werden. Selbstverständlich ist dies nur
bei einer entsprechend zu erwartenden, hohen Übungskomplexität sinnvoll.
In der maßgeblichen deutschen Literatur des Bundesamts für Sicherheit in der Informa-
tionstechnik BSI (2008) sind mehrere Übungstypen beschrieben. Die Übungstypen sind in
Tab.8.1 den Grundlagen von BMI (2008, 2017) gegenübergestellt:
Diese Übersicht zu den denierten Übungstypen gibt einen Einblick in die Übungs-
komplexität für die aktiv teilnehmenden Organisationen und Unternehmen. Mit Blick auf
die Übungsleitung bzw. Übungsplanung sind jedoch noch zwei weitere Aspekte wichtig:
• Übungsausprägung
• Übungscharakter
Bei der Übungsausprägung wird festgelegt, ob die Übung verteilt, also disloziert, an mehre-
ren Standorten durchgeführt werden soll oder ob alle Organisationen oder Unternehmen an
einem Ort zusammen üben. Selbstverständlich sind auch hier wieder Mischformen möglich.
Der Übungscharakter beschreibt den Ankündigungsgrad der Übung. Sicherlich stellt eine
unangekündigte Übung die höchsten Anforderungen an die übenden Unternehmen/Organi-
sationen, aber auch an die Übungsleitung, dar. Der Prozess der Übungskonzeption wird in
drei Phasen eingeteilt. Er folgt den Vorgaben der NATO Collective Training and Exercise
Directive (2013) der auf Basis der langjährigen Übungserfahrung von Infraprotect für zivile
Anwendungen stark vereinfacht wurde und in Tab.8.2 zusammengefasst ist:
8.1.2 Zieldenition für die Pilotierung
8.1.2.1 Planung und Festlegung der Ziele
Die generellen Ziele des Planspiels wurden in Abschn.8.1.1 bereits angesprochen. Auf-
grund der Wichtigkeit der Aus- bzw. Bewertbarkeit der Übungsziele wird deren Beschrei-
bung in einem eigenen Abschnitt behandelt. Grundsätzlich sollten folgende Sichten auf
die Übungsziele, die dem TOP-Prinzip folgen, ermöglicht werden:
• Technische Sichtweise auf die zur Verfügung stehende zur Lagedarstellung (Tech-
nische Ziele)
• Prozessuale Sichtweise auf die internen und externen Kooperations- und Kollabora-
tionsverfahren zur „Ereignisbewältigung“ (Organisatorische Ziele)
• Individuelle Sichtweise auf die persönlichen Herausforderungen zur „Ereignisbewälti-
gung“ (Persönliche Ziele)
8 Evaluierung des Cyber Lagebildkonzepts im praktischen Einsatz 297
Tab.8.1 Gegenüberstellung verschiedener Übungstypen
Übungsart
KRITIS
BMI
Beschreibung Übungsart KRITIS BMI Beschreibung BSI Übungsart
BSI
Keine explizite Erwähnung oder Entsprechung Um die Angemessenheit und die Funktionsfähigkeit der techni-
schen Lösungen sicherzustellen, müssen diese getestet werden.
Hierzu zählen beispielsweise Tests von redundant ausgelegten
Leitungen, der Stromversorgung, der Wiederherstellung von
Datensicherungen, der Ausfallsicherheit von Clustern, der einge-
setzten Meldetechnik, der technischen Infrastruktur oder einzel-
ner IT Komponenten. Einzelne Komponenten und ihre Funktion
sollten regelmäßig sowie anlassbezogen bei größeren Verände-
rungen der Systeme oder der jeweiligen Systemumgebung getes-
tet werden, um das Zusammenspiel zu überprüfen.
Test der
technischen
Vorsorge-
maßnahmen
Keine explizite Erwähnung oder Entsprechung Mit dieser Übungsart werden die Prozeduren, Teilprozesse und
Systemgruppen auf ihre Funktionalität überprüft, die in den
verschiedenen Teilplänen des Notfallhandbuchs festgelegt sind.
Dabei werden zum einen Abläufe, aber vor allem auch das Zu-
sammenspiel und die Abhängigkeiten verschiedener Komponen-
ten oder Maßnahmen überprüft. Dazu zählen Wiederanlaufpläne,
Wiederherstellungspläne, wie auch die Notfallpläne für die
Sofortmaßnahmen (z.B. zur Evakuierung der Belegschaft bei
Feueralarm).
Funktions-
test
Keine explizite Erwähnung oder Entsprechung Ziel von Plan-Reviews ist, die einzelnen Pläne der Notfall- und
Krisenbewältigung zu überprüfen. Die
Teilnehmer gehen bei dieser Übungsart die Pläne theoretisch
durch und überprüfen die Plausibilität der
Inhalte und der getroffenen Annahmen. Die Funktionsfähigkeit
der beschriebenen Inhalte wird dabei augenscheinlich bewertet.
Plan-Re-
view
298 M. Kaundert et al.
Übungsart
KRITIS
BMI
Beschreibung Übungsart KRITIS BMI Beschreibung BSI Übungsart
BSI
Planbespre-
chung/Plan-
übung
Eine Planbesprechung/Planübung dient der ge-
meinsamen Entwicklung und Überprüfung von
Reaktionsmustern auf ein vorgegebenes Sze-
nario sowie dem Aufdecken der gegenseitigen
Abhängigkeiten von Betreibern Kritischer Infra-
strukturen. Es handelt sich um eine moderierte
Besprechung mit Leitfragen zur konstruktiven
Diskussion, gegebenenfalls auch ergänzt durch
Fachvorträge, die Hintergründe zum behandel-
ten Szenario vermitteln. Die Reaktionen auf
das Szenario werden dabei in der Regel nicht
wirklich durchgeführt, sondern nur theoretisch
besprochen.
Die Planbesprechung wird dazu verwendet, am „grünen Tisch“–
daher auch der Name „Table Top Exercise“ – Probleme und Sze-
narien durchzudenken. In dieser Übungsart wird ein Szenario vor-
gegeben und theoretisch durchgespielt. Diese Übungsart ist noch
relativ einfach umzusetzen und dient einer ersten Validierung.
Unstimmigkeiten und Missverständnisse können so aufgedeckt
werden, bevor ein kostenintensiver operativer Aufwand betrieben
wird. Während der Etablierungsphase des Notfallmanagements
sollte diese Überprüfungsart häufiger wiederholt werden.
Planbespre-
chung
Eine besondere Form von Planbesprechung sind die sogenannten
Stabsübungen. Dabei wird die
Zusammenarbeit im Krisenstab geübt.
Stabsü-bun-
gen
Eine weitere Form der Planbesprechung sind die Stabsrahmen-
übungen. Sie stellen eine erweiterte Form der Stabsübung dar.
Sie dienen dazu, neben der Zusammenarbeit im Krisenstab auch
die Zusammenarbeit zwischen dem Krisenstab und den operati-
ven Teams zu überprüfen und zu üben. In der Regel werden die
stabsnahen Strukturen praktisch geübt, während die operative
Umsetzung theoretisch simuliert wird.
Stabsrah-
men-übun-
gen
Tab.8.1 (Fortzetzung)
8 Evaluierung des Cyber Lagebildkonzepts im praktischen Einsatz 299
Übungsart
KRITIS
BMI
Beschreibung Übungsart KRITIS BMI Beschreibung BSI Übungsart
BSI
Kommu-
nikations-
übung
Bei einer Kommunikationsübung handelt es
sich um die Überprüfung der Kommunikations-
mittel und -verfahren, die für die Alarmierung
vereinbart sind, der Kommunikationsmittel und
-verfahren, die für den Austausch zwischen den
Partnern in Not- und Krisenfällen vorgesehen
sind. Mögliche Kommunikationsmittel können
zum Beispiel Telefon, Telefax, E-Mail, Mess-
aging-Systeme, Internetportale und/oder Video-
konferenzen sein.
Ein neuralgischer Punkt der Notfall- und Krisenbewältigung ist
die Meldung und Alarmierung des Krisenstabs und weiterer Ver-
antwortlicher. Daher sind die Verfahren zur Meldung, Eskalation
und Alarmierung regelmäßig zu überprüfen. Dieser Test umfasst
einfache Überprüfungen der Kommunikationsmittel bis hin zum
Zusammentreten des Krisenstabs im Krisenstabsraum. Es wer-
den dabei die in den Plänen hinterlegten Zuständigkeiten und
Rufnummern wie auch die Verfahren, die Eskalationsstrategie,
die Erreichbarkeiten und die Stellvertreterregelungen getestet. Es
wird überprüft, ob die vorliegenden Pläne aktuell, verständlich
und handhabbar, die Verfahren praktikabel und die zu nutzende
Technologien (z.B. Alarmierungssystem, Notfall-Telefon, SMS,
Pager, Internet, Funk- oder Satellitenkommunikationsgeräte)
funktionsbereit, effektiv und angemessen sind.
Kommu-
nikations-
und Alar-
mierungs-
übung
Koordina-
tionsübung
Eine Koordinationsübung hat zwei Schwer-
punkte. Sie dient zum einen der Überprüfung der
technischen und organisatorischen Voraussetzun-
gen, die für eine effiziente Abarbeitung aller an-
stehenden Aktionen und Aspekte der Krise benö-
tigt werden (wie zum Beispiel das IT-Lage- und
Krisenreaktionszentrum des BSI). Zum anderen
wird auch die Bewältigung eines Notfalls bezie-
hungsweise einer Krise inhaltlich geübt. Für eine
Koordinationsübung ist ein Szenario unabding-
bar. Im Gegensatz zur Planbesprechung/Plan-
übung wird dieses nicht nur diskutiert, sondern
unter Zuhilfenahme der zur Verfügung stehenden
Pläne und Kriseneinrichtungen durchgespielt.
Durch eine realitätsnahe Simulation werden die festgelegten Pro-
zeduren und Maßnahmen für die Bewältigung von Notfallszena-
rien oder -ereignissen auf ihre Zweckmäßigkeit, Angemessenheit
und Funktionalität getestet. Dabei werden sowohl die Alarmie-
rung und Eskalation, die Notfallbewältigungsorganisation, die
Arbeit des Krisenstabs und die Zusammenarbeit aller beteiligten
Stellen erprobt. Solche Übungen könnten als Funktions- oder Be-
reichsübungen und in einer weiteren Stufe bereichsübergreifend
organisiert werden.
Simulation
von Szena-
rien
Tab.8.1 (Fortzetzung)
300 M. Kaundert et al.
Übungsart
KRITIS
BMI
Beschreibung Übungsart KRITIS BMI Beschreibung BSI Übungsart
BSI
Erweiterte
Koordina-
tionsübung
Die erweiterte Koordinationsübung ist die
höchste Stufe der Übungsarten und besitzt den
größten Komplexitäts- und Realitätsgrad. Die
gesamte Reaktion auf eine Krise wird, überwie-
gend in Echtzeit und daher gegebenenfalls über
einen längeren Zeitraum, mit möglichst allen
Personen, die auch in einer realen Krise beteiligt
wären, durchgespielt.
Die aufwendigste Art einer Simulation ist die Ernstfall- oder
Vollübung. Je nach Szenario sind dabei auch Externe, wie bei-
spielsweise die Feuerwehr, Hilfsorganisationen, Behörden etc.,
einzubeziehen.
Diese Übungsart kann und sollte erst in einem fortgeschrittenen
Stadium durchgeführt werden.
Die Vollübung orientiert sich an der Wirklichkeit und bezieht
alle Hierarchieebenen vom Management bis zum einzelnen Mit-
arbeiter mit ein. Der Vorbereitungs-, Durchführungs- und Nach-
bereitungsaufwand ist nicht zu unterschätzen. Dennoch sollte bei
hohen Anforderungen der Institution an das Notfallmanagement
nicht darauf verzichtet werden. Auch Ernstfallübungen sollten re-
gelmäßig in größeren zeitlichen Abständen durchgeführt werden.
Ernstfall-
oder Voll-
übung
Tab.8.1 (Fortzetzung)
8 Evaluierung des Cyber Lagebildkonzepts im praktischen Einsatz 301
Tab.8.2 Prozess der Übungskonzeption
Phasen Phase I Spezi-
fikation und
Übungskonzept
Phase II
Übungs-vor-
bereitung
und-planung
Phase III Übungs-
durchführung
Phase IV Auswer-
tung und Bericht
Ergebnisse •Übungskonzept
•Übungsteil-
nehmer
•Übungszweck
•Übungsziele
•Übungssze-
nario
•Drehbuch
•Übungssetting
•Evtl.Trainings
und Vorübungen
•Übungs-durch-
führung
•Evaluation
•Auswertungder
Evaluierung
•Übungsbericht
•Handlungs-emp-
fehlungen
Diese drei Zielkategorien wirken primär intraorganisational und betrachten die inter-
nen Abläufe an den Schnittstellen nach außen. Grundsätzlich sollten nach BSI „wenige,
klar denierte und für die vorgesehene(n) Zielgruppe(n) überzeugende Ziele festgelegt
werden“ (BSI 2014: 16). Die dort beispielhaft genannten Aspekte beziehen sich jedoch
zum Großteil auf ein bereits existierendes System der Ereignisbewältigung. Das Konzept
des „Lagezentrums“ ist jedoch (noch) ktiv und bedarf daher in seiner Evaluierung eines
anderen Fokus. Die Zielsetzungen des CISA Planspiels im Sinne der Beurteilung einer
Cyber-Bedrohungslage lauten deswegen wie folgt:
• Stärkung des Bewusstseins für die Notwendigkeit der übergreifenden Zusammenarbeit
und die gegenseitigen Abhängigkeiten
• Erhebung, welche Datentypen für die Lagebeurteilung relevant sind
• Erhebung, welche Datenverknüpfungen für die Lagebeurteilung relevant sind
• Erhebung, welche Datendarstellungen (Visualisierungen) für die Lagebeurteilung
relevant sind
• Abgleich der entwickelten Denition des Cyber-Lagebildbegriffes
Die Evaluierung dieser Punkte wurde mittels entsprechend konzipierter Fragestellungen
während des Planspiels abgefragt.
8.1.2.2 Festlegung der Nicht-Ziele
Zur Abgrenzung des Projektes wurden eindeutige Nicht-Ziele für die Evaluierung des
Demonstrators formuliert. Der Rahmen des Forschungsprojektes zielte auf eine Evaluie-
rung der obengenannten Aspekte im Planspiel ab. Die daraus abgeleiteten Nicht-Ziele sind:
• Optische/ästhetische Einschätzungen des Demonstrators (Skalierungen, Farbgebun-
gen, Font usw.)
• Reale Verfügbarkeit von Daten (z.B. Sensor-/Auditdaten)
• Ereignisbewältigung der teilnehmenden Personen in den Lagezentren
302 M. Kaundert et al.
8.1.3 Anwendungsfall für die Pilotierung
Das dem Planspiel zugrunde liegende Szenario wurde darauf abgestimmt, den Zweck aus
technisch-organisatorischer Sicht bestmöglich und plausibel zu unterstützen. Es nimmt
die Existenz eines österreichischen Lagezentrums zur Auswertung von Cyber-Bedro-
hungsszenarien an, sowie die Umsetzung der NIS-Richtlinie in geltendes Recht. Es wurde
den Teilnehmenden in Form eines Arbeitsbuches bereits vorab zur Verfügung gestellt, um
eine Auseinandersetzung mit dieser gemeinsamen Ausgangslage zu ermöglichen.
Aus technischer Sicht baut es auf den Fall Petya (alias „GoldenEye“, „NotPetya“,
„ExPetr“) auf. Seit 27. Juni 2017 beobachteten IT-Security Experten einen weltweiten
Ransomware-Angriff mittels einer neuen Variante der schon zuvor als „Petya“ bekannten
Schadsoftware. Die vermeintlich neue Variante von Petya, jener Schadsoftware, die Win-
dows-Computer in mehr als 64Ländern befallen hatte, war mehr als nur eine einfache
Ransomware. Bei der aktuellen Version der Schadsoftware handelte es sich um einen
„Wiper“, welcher sich vom Original deutlich unterscheidet und dessen einziger Zweck
Zerstörung zu sein schien. Wie bei Ransomware wurde zwar der Datenträger verschlüs-
selt, doch im Gegensatz zu WannaCry und Co. bestand keinerlei Hoffnung auf Wieder-
herstellung. Experten vermuteten eine Ablenkungsaktion eines Staates und sahen dies als
Hinweise darauf, dass die Angreifer eher auf Chaos und weniger auf Prot aus waren.
Für Betroffene bestand keine Möglichkeit zur Wiedererlangung ihrer Daten, weshalb
sich auch bei diesem Vorfall die Wichtigkeit der zeitnahen Einspielung aktueller Sicher-
heitsupdates und Patches, der Anfertigung regelmäßiger Sicherungen (Backups) sowie
der Einsatz entsprechender Sicherheitssoftware, erneut bestätigte (Anonymous 2017a;
Frenkel et al. 2017).
Vor allem Unternehmen und Anwender in zahlreichen EU-Mitgliedsstaaten, der Ukraine
sowie Russland waren maßgeblich von diesem Angriff betroffen. Es wurde vermutet, dass
der initiale Vektor der Schadsoftware über ein Software-Update eines ukrainischen Soft-
wareherstellers (MeDoc) für Buchhaltungssoftware erfolgte, welcher vermutlich von Kri-
minellen unbemerkt gehackt wurde. Berichten zufolge wurde für die Wiederherstellung
der Systeme die Zahlung von jeweils 300 Dollar in der Cyberwährung Bitcoin gefor-
dert. Vor allem die Ukraine, Russland, England und Indien sind nach Einschätzung von
Schweizer Experten Opfer von Hackerangriffen geworden (Anonymous 2017b)
Betroffene Unternehmen weltweit:
• Die Schweizer Vermarktungsrma Admeira
• Der russische Ölkonzern Rosneft
• Die dänische Reederei Maersk
• Das britische Werbeunternehmen WPP
• Der französische Industriekonzern Saint-Gobain
• Der US-Nahrungsmittelkonzern Mondelez International
• Das Computersystem des deutschen Beiersdorf-Konzerns
• Das ukrainischen Katastrophen-Atomkraftwerk Tschernobyl
8 Evaluierung des Cyber Lagebildkonzepts im praktischen Einsatz 303
8.1.3.1 Die Funktionsweise von Petya
Eine Untersuchung einer früheren Version von Petya durch die Firma F-Secure3 ergab,
dass Petya, anders als andere Ransomware, nicht Dateien verschlüsselt, sondern die
Indextabelle des Dateisystems. Ohne diese Tabelle ist für den Computer nicht erhebbar,
wo auf der Festplatte welche Teile welcher Dateien abgelegt sind.
Die Malware kann sich über mehrere Wege in Netzwerken ausbreiten und verschlüsselt
Dateien auf inzierten Rechnern. Für die Verbreitung werden teilweise Sicherheitslücken
genutzt, die auch schon bei der Ransomware „WannaCry“ ausgenutzt wurden. Es wird
automatisch ein Neustart durchgeführt, wobei das Betriebssystem dann nicht mehr korrekt
hochfährt. Auf dem Bildschirm erscheint nur noch die Information, dass der Computer
inziert ist und wie das Lösegeld überwiesen werden soll (siehe Abb.8.1).
Die Kommunikation mit dem Server läuft über das anonymisierte Netzwerk TOR und
die Zahlung wird in Bitcoins verlangt, die ebenfalls fast anonym sind. Fachleute zogen
Parallelen zu dem Angriff mit dem Schadprogramm „WannaCry“, das Mitte Mai rund um
den Globus Computer lahmgelegt hatte (Hay Newman 2017).
Petya ist auf den ersten Blick ein klassischer Erpressungstrojaner: Ein inzierter PC
lässt sich nicht mehr hochfahren; ein stilisierter Totenkopf und Information zur Ver-
schlüsselung sämtlicher Daten und zur Lösegeldzahlung erscheinen. Es existieren jedoch
markante Unterschiede zur Urform von Petya, welche erstmals 2016 auftrat. Kaspersky
stützt diese Annahme, denn auch das Unternehmen konnte in seinen Untersuchungen
Abb.8.1 Inzierter Computer
3 Petya, https://www.f-secure.com/en/web/business_global/petya (Letzter Zugriff: 21.05.2018)
304 M. Kaundert et al.
ein entscheidendes Detail nicht nden: Die Installations-ID, mit welcher der Freigabe-
Schlüssel erstellt werden kann, fehlt. Normalerweise müssen diese Installations-IDs an
die Angreifer verschickt werden, um die Daten wiederherzustellen. Die Angreifer können
den Decryption Key mit ihrem dazugehörigen Schlüssel extrahieren. Petya ähnelt jedoch
einem anderen Wiper, der vor fünf Jahren als Shamoon die Runde machte und primär
Energiekonzerne in Saudi-Arabien und Katar beel (Anonymous 2017c). Die Experten
rieten Unternehmen, ein Update ihrer Windows-Software durchzuführen und Back-ups
anzulegen. Nutzer von Windows XP und Windows 7konnten sich durch Installation des
Sicherheits-Patches MS17-010 schützen.
Die folgenden Nachrichten wurden im Zusammenhang mit dem Sicherheitsfall in
Österreich veröffentlicht.
Vom Kurier veröffentlicht am 28.06.2017:
… Von der neuen Cyberattacke durch eine bisher nicht bekannte Erpresser-Software sind
auch Firmen in Österreich betroffen. Bisher wurden zwei Unternehmen dem Bundeskriminal-
amt (BK) gemeldet, hieß es Mittwochmittag. Es handelt sich um internationale Unternehmen
mit Standort in Wien. Diese Erpresser-Software sei „noch übler“, sagte Bundeskriminalamts-
sprecher Vincenz Kriegs-Au. Es wurden mehrere Computer der beiden Unternehmen in Wien
inziert, für jeden einzelnen fordern die Erpresser 300 Dollar. Kriegs-Au wies auf die Wich-
tigkeit hin, dass etwaige weitere Betroffene Anzeige erstatten: Nur so erhalten die Ermittler
wichtige Informationen, um den digitalen Spuren im Netz folgen zu können. Alle österrei-
chischen Ransomware-Fälle werden zentral von einer Sonderkommission übernommen. Die
Soko CLAVIS bearbeitet diese und steht diesbezüglich auch im laufenden internationalen
Kontakt mit den ermittelnden Behörden anderer Staaten und mit Europol, berichtete das Bun-
deskriminalamt (Anonymous 2017d).
FutureZone Online Portal am 29.06.2017:
… Bei den geschädigten Unternehmen in Österreich handelt es sich um drei international
agierende Firmen mit Niederlassungen bzw. Standorten in Wien … (Anonymous 2017e).
Aufforderung auf Meldung:
Betroffene sind dazu aufgefordert, eine entsprechende Meldung beim Cyber Crime Com-
petence Center (C4) des Bundeskriminalamtes (24h Telefon: +43-1-24836-986500; E-Mail:
against-cybercrime@bmi.gv.at) zu erstatten.
Weitere aktuelle Informationen erhalten Sie zusätzlich beim österreichischen Computer
Emergency Response Team (CERT.at) unter http://cert.at/warnings/all/20170628.html
8.1.3.2 Anwendungsfall beim CISA Planspiel
Im Planspiel wird von 100 Unternehmen der kritischen Infrastruktur ausgegangen. Davon
sind 29 Unternehmen vulnerabel für Petya Ransomware. Bei 16 Unternehmen wurde die
Vulnerabilität ausgenutzt, d.h. sie sind schon von zumindest einer Infektion betroffen. 61
Unternehmen sind nicht betroffen und über 10 Unternehmen liegt keine Information vor.
8 Evaluierung des Cyber Lagebildkonzepts im praktischen Einsatz 305
In den drei Iterationen ändert sich die für die Lagezentren (LZ) zugängliche Informations-
dichte bezüglich dieses Szenarios von LOW auf HIGH.
Aus der Liste mit 800 österreichischen kritischen Unternehmen wurden 100 Unter-
nehmen für das Planspiel ausgewählt. Diese 100 Unternehmen bildeten die Grundlage für
die drei Iterationen. Das zugrunde liegende Szenario blieb in allen drei Iterationen gleich,
jedoch wurde die Dichte der Information, welche den Lagezentren für die Beurteilung und
Einschätzung der Lage zur Verfügung gestellt wird, geändert.
Um eine Vergleichbarkeit der Visualisierungen zwischen den Iterationen herzustellen
und um zur Nutzung des Demonstrators auf möglichst zuverlässige Art und Weise Daten
zu erheben, wurden alle drei Iterationen an einem Tag abgehalten und lediglich durch
kurze Pausen getrennt. Dies war von Bedeutung für die Befragung der Teilnehmenden
mittels der vorbereiteten Fragebögen, denn je kürzer das Zeitintervall einer Befragung
gehalten wird, desto geringer ist die Wahrscheinlichkeit, dass eine Änderung der persön-
lichen Einstellung/Ansichten der Teilnehmenden stattndet, welche das Antwortverhalten
beeinusst (Krosnick und Fabrigar 1997).
Im Planspiel wurden Informationen in verschiedener Form eingespielt, wie etwa
Pichtmeldungen, freiwillige Meldungen, Cybersecurity-Auditdaten und Sensordaten
(siehe detaillierte Erklärung in Abschn.8.1.4). Sie wurden zeitlich versetzt im Demonst-
rator in visueller Form zur Verfügung gestellt, um das fortschreitende Szenario zu simu-
lieren. Die Auditdaten in Iteration drei wurden gesammelt zu Beginn der Iteration ein-
gespielt. Die Einspielungen erfolgten über die vorbereitete Visualsierungssoftware (siehe
Abschn.8.2.1) und wurden in den Lagezentren in Form von verschiedenen Verknüpfungen
und Darstellungsarten gezeigt. Die Teilnehmenden hatten den Auftrag, die Bedrohungs-
lage anhand der gezeigten Visualisierungen einzuschätzen und diese bei Bedarf anzupas-
sen (z.B. durch Setzen von Filtern). Hierdurch ergab sich eine grasch variierende Dar-
stellung ein- und derselben Lage in den unterschiedlichen Lagezentren.
Die Teilnehmenden in den Lagezentren wurden zu vordenierten Zeitpunkten in allen
drei Iterationen des Planspiels aufgefordert:
• Eine Warnung an kritische Infrastrukturen zu erstellen und auszugeben
• Fragebögen hinsichtlich der Nutzung/Anpassung der Visualisierungen auszufüllen
• Einen Endbericht zum Ereignis (=der Iteration) zu erstellen
Für eine detaillierte Beschreibung der Evaluationsmethodik wird auf Abschn. 8.3.2
verwiesen.
Entsprechend der zur Verfügung stehenden Datengrundlage pro Iteration verringerte
sich die Ungewissheit (siehe graue Balken „keine Information“ in Abb.8.2. Die Daten-
typen, welche von einer konkreten Anzahl von Unternehmen pro Iteration in die Lage-
zentren eingespielt wurden, sind in Tab.8.3 dargestellt und zeigen, dass die für das Lage-
zentrum verfügbaren Daten sich mit jeder Iteration der Realität näherten.
306 M. Kaundert et al.
8.1.4 Dargestellte Datentypen
Die Informationen zur Bedrohungslage wurden den Lagezentren durch den Demonstrator
in unterschiedlich aufbereiteter Form zur Verfügung gestellt:
%HWURIIHQ
9XOQHUDEHO
1LFKWYXOQHUDEHO
.HLQH,QIRUPDWLR
Q
,WHUDWLRQ ,WHUDWLRQ ,WHUDWLRQ 5HDOLWlW
/DJH]HQWUXP6LFKWSUR,WHUDWLRQ
%HWURIIHQ 9XOQHUDEHO 1LFKWYXOQHUDEHO.HLQH,QIRUPDWLRQ
Abb.8.2 Datengrundlage pro Iteration
Tab.8.3 Verwendete Datentypen pro Iteration
Iteration 1 Iteration 2 Iteration 3
Phase I. Auditdaten: keine
Meldungen: 5U
Sensordaten: keine
Auditdaten: keine
Meldungen: 5U
Sensordaten: 36U
Auditdaten: 71U
Meldungen: 5U
Sensordaten: 36U
Phase II. Auditdaten: keine
Meldungen: 4U
Sensordaten: keine
Auditdaten: keine
Meldungen: 4U
Sensordaten: 37U
Auditdaten: bereits
eingespielt
Meldungen: 4U
Sensordaten: 37U
Phase III. Auditdaten: keine
Meldungen: 3U
Sensordaten: keine
Auditdaten: keine
Meldungen: 3U
Sensordaten: 7U
Auditdaten: bereits
eingespielt
Meldungen: 3U
Sensordaten: 7U
U = Unternehmen
8 Evaluierung des Cyber Lagebildkonzepts im praktischen Einsatz 307
• Darstellung von Basisdaten
• Verknüpfung verschiedener Daten
• Darstellung unterschiedlicher Diagrammtypen
• Darstellung unterschiedlicher Zeitspannen
Dargestellt wurden folgende Datensätze:
• Meldungen (in Form von freiwilligen Meldungen oder Pichtmeldungen)
• Sensordaten: dienen der Sammlung von Informationen zu möglichen Incidents. Ihre
Darstellung erfolgt automatisiert, unabhängig von Meldungen. Sie stellen eine Übungs-
künstlichkeit dar.
• Auditdaten: Darstellung von Hintergrundinformationen zu potenziellen Zielen, soll
Einschätzung der Gefährdung potenzieller Ziele ermöglichen, genauso Einschätzung
von Dauer und Gefährlichkeit eines Incidents und die Vertrauenswürdigkeit von Infor-
mationen. Wird dargestellt durch ausgewählte NIST-Controls (5) und stellen eine
Übungskünstlichkeit dar.
• Organisationsdaten (Organisationsname, -standort, -sektor, Firmenkritikalität)
Die Teilnehmenden waren angehalten, die Darstellungen im Demonstrator während der
Iterationen aktiv anzupassen, um unterschiedlichste Aspekte von Interesse abzudecken
und darstellen zu lassen. Größere Menge an Informationen sollten so interaktiv und struk-
turiert als Lagebild dargelegt und ihre Rolle bei der Entscheidungsndung und Lageein-
schätzung bewertet werden.
8.1.4.1 Freiwillige Meldungen und Pichtmeldungen
Die Freiwilligen Meldungen und Pichtmeldungen wurden entlang des Structured Threat
Information eXpression (STIX) Schemas aufgebaut, welches als Standard für die struk-
turierte Erhebung von komplexer Information zu Cyber-Bedrohungslagen gilt. STIX
entstand ursprünglich aus dem Bedürfnis heraus, eine standardisierte Repräsentation für
Cyber-Bedrohungs-Indikatoren zu entwickeln und festzuhalten, welche Informationsart
und –umfang hierfür nötig ist. STIX (OASIS-Standard STIX 1.2) stellt eine gemeinsame
Herangehensweise an die Darstellung von sicherheitsrelevanten Informationen dar und
beinhaltet:
• Cyber Observables
• Indikatoren
• Vorfälle
• Taktiken, Techniken und Angriffsprozesse des Gegners (inkl. Malware, Angriffsmus-
ter, Exploits usw.)
• Exploit targets (Schwachstellen, Bedrohungern usw.)
• Handlungsanweisungen
308 M. Kaundert et al.
• Cyberangriffs-Kampagnen
• Bedrohungsakteure
Für mehr Details zum Informationsanalyse-Konzept siehe Kap.7.
8.1.4.2 Sensordaten
Einer der wesentlichen Aspekte, die im Rahmen des Planspiels eruiert und analysiert
wurden, war die Frage, ob die Anbindung von Sensorsystemen und automatischen Analy-
sewerkzeugen den Wert des Lagebildes erhöhen kann. Durch Nutzung von Sensoren kann
eine einfache und schnelle Erkennung und Spezizierung von Angriffen erreicht werden,
sowie auch eine rasche Erkennung alternativer Ziele und eine qualizierte Einschätzung
zu deren Gefährdung. Dies ist unabdingbar bei der Transition des Begriffs „Lagebild“ von
einer rein passiven, reaktiven Instanz hin zu einem proaktiven Werkzeug.
Im Planspiel wurden zwei Sensorsysteme eingesetzt: eines an der Peripherie (bspw.
netzwerkseitig), sowie eines im Zentrum der jeweiligen kritischen Infrastruktur. Der
Aufbau der gesendeten Informationen war analog zu jenem der freiwilligen Meldungen
und Pichtmeldungen, jedoch mit weniger detaillierter Information.
Bezüglich der Sensoren wurden folgende Annahmen für das Planspiel getroffen:
• Nicht bei allen Organisationen/kritischen Infrastrukturen sind beide Sensorsysteme
installiert
• Beide Sensoren ändern in der Weiterentwicklung des Szenarios ihre Werte.
• Die Organisationen selbst kennen ihre Sensorzustände nicht; nur den Lagezentren ist
bekannt, welche Werte die Sensoren ausgeben. So wurde das Einbringen von nicht-
szenario-relevanten Informationen ermöglicht, was die Darstellung einer Art „Hin-
tergrundrauschen“ gestattete, welches das Lagezentrum von den Einspielungen der
Bedrohungslage zu unterscheiden hatte.
Hinsichtlich der Sensoren ergab sich für die Lagezentren also ein diverses Bild der Betrof-
fenheit. Tab.8.4 zeigt eine grobe Übersicht über die installierten Sensoren und ihre Wer-
tebereiche. Alle vorhandenen Sensoren wurden zum Zweck der Übung am Anfang mit
„init“ belegt. Dadurch zeigen diese Sensoren noch nichts an und werden auch nicht in
Tab.8.4 Übersicht der Sensoren und ihrer Wertebereiche
Sensor Wertebereich Relevant Petya Default
SensorNessus {init, nil, „CVE-2017–0144“,
„CVE-2017–0145“, „CVE-2017–
12896“, „CVE-2017–0676“, „CVE-
2017–0234“}
„CVE-2017–0145“,
„CVE-2017–0145“
nil
SensorTraffic {„init“, „normal“, „TOR“} „TOR“ „normal“
8 Evaluierung des Cyber Lagebildkonzepts im praktischen Einsatz 309
Statistiken des Demonstrators angezeigt, was eine Verzerrung der Graken durch die Ini-
tialisierung und somit Missverständnisse auf Seiten der Teilnehmenden bei der Lagebe-
urteilung verhindert.
Eingesetzte Sensoren
SensorNessus: Dieser Sensor simuliert einen Nessus-Scan wichtiger Endsysteme und
liefert eine Liste an gefundenen Schwachstellen zurück. Dieser Sensor, der im Zentrum
der kritischen Systeme agiert, ermöglicht einige interessante Übungsaspekte:
• Darstellung und Erkennung betroffener Systeme, ohne dass diese angegriffen werden.
• Einbringen von verwirrenden, für das gespielte Szenario irrelevanten, Informationen, die
aber dennoch keine Falschinformationen sind. Dies simuliert ein „Hintergrundrauschen“,
welches beabsichtigt ist, da ein Lagezentrumim Anlassfall nicht ausschließlich Sensorin-
formationen zu einem konkreten Ereignis erhalten würde und sich mit der Unterscheidung,
welche Informationen für das zu untersuchende Ereignis relevant sind, befassen muss.
• Übungskünstlichkeit: Um die Übung dennoch übersichtlich zu halten, gibt der Sensor
lediglich eine Liste an angetroffenen CVEs zurück. Dies wird noch weiter vereinfacht,
indem der Sensor immer genau einen CVE-Code zurückgeben kann.
SensorTrafc: Dieser Sensor sitzt an der Peripherie und erkennt verschlüsselten Trafc
und speziell TOR-Verkehr. Auch dieser Sensor ermöglicht die Einbringung von für das
Übungssze-nario nicht unmittelbar relevanten Informationen.
• Übungskünstlichkeit: Die Erkennung von TOR ist eine Übungskünstlichkeit, nicht
weil TOR nicht erkannt werden kann (außer bei der Nutzung von Hidden Services ist
das mittels Verbindungsdaten gut möglich), sondern weil die Frage natürlich bestehen
bleibt, ob so ein Sensor in der Realität sinnvoll ist.
8.1.4.3 Auditdaten
Als zusätzliche Informationsquelle standen den Lagezentren Informationen von IT-Si-
cherheitsaudits der Organisationen zur Verfügung. Die Auditdaten richteten sich nach den
Security und Privacy Controls des National Institute of Standards and Technology (2013).
In der Übung wurden 5 ausgewählte Maßnahmen (=NIST Controls) genutzt. Jede Maß-
nahme kann den Wert low, medium oder high annehmen und ist vom Reifegrad der Umset-
zung in der jeweiligen Organisation abhängig. Die Auditdaten waren als Unterstützung
zur Einschätzung des technischen und organisatorischen Know-Hows und der Bewälti-
gungsbereitschaft einer Organisation im Fall eines Sicherheitsvorfalls gedacht.
Die fünf verwendeten Controls sind:
• RA-5Vulnerability Scanning
• SI-2Flaw Remediation
310 M. Kaundert et al.
• SI-4 Information System Monitoring
• SI-7 Software, Firmware, and Information Integrity
• IR-1 Incident Response Policy and Procedures
Während des Planspiels haben die Teilnehmer die folgenden Informationen über die aus-
gewählten NIST Maßnahmen gesehen. Siehe Tab.8.5 als Beispiel mit RA-5-Maßnahme.
Tab.8.5 Kontrollbeschreibung
Control Nummer
RA-5 Vulnerability Scanning
In Risk Assessment
Control Description
The organization:
a. Scans for vulnerabilities in the information system and hosted applications [Assignment:
organization-defined frequency and/or randomly in accordance with organization-defined pro-
cess] and when new vulnerabilities potentially affecting the system/applications are identified
and reported;
b. Employs vulnerability scanning tools and techniques that facilitate interoperability among
tools and automate parts of the vulnerability management process by using standards for:
1. Enumerating platforms, software flaws, and improper configurations;
2. Formatting checklists and test procedures; and
3. Measuring vulnerability impact;
c. Analyzes vulnerability scan reports and results from security control assessments;
d. Remediates legitimate vulnerabilities [Assignment: organization-defined response times] in
accordance with an organizational assessment of risk; and
e. Shares information obtained from the vulnerability scanning process and security control as-
sessments with [Assignment: organization-defined personnel or roles] to help eliminate similar
vulnerabilities in other information systems (i.e., systemic weaknesses or deficiencies).
Supplemental Guidance
Security categorization of information systems guides the frequency and comprehensiveness of
vulnerability scans. Organizations determine the required vulnerability scanning for all infor-
mation system components, ensuring that potential sources of vulnerabilities such as networked
printers, scanners, and copiers are not overlooked. Vulnerability analyses for custom software
applications may require additional approaches such as static analysis, dynamic analysis, binary
analysis, or a hybrid of the three approaches.
Control Enhancements :
•Updatetoolcapability
•Updatebyfrequency
•Depthofcoverage
•Discoverableinformation
References
NIST Special Publications 800-40, 800-70, 800-115
8 Evaluierung des Cyber Lagebildkonzepts im praktischen Einsatz 311
8.1.4.4 Firmenkritikalität
Die Firmenkritikalität fungierte als eine angenommene Größe, die dem Lagezentrum. Bei
Der Bewertung von Incidents als Hilfestellung dienen sollte. Sie setzte sich ktiv aus Ele-
menten wie der Substituierbarkeit, Abhängigkeit von anderen Organisationen und derglei-
chen zusammen. Die Firmenkritikalität wurde in 10 Stufen (1 bis 10) angegeben. 1 stellte
dabei die niedrigste und 10 die höchste Stufe dar (10 wurde als entsprechend schwer
substituierbar angenommen, andere Organisationen sind in besonderem Maße abhängig,
etc.). Diese Größe wurde als Übungskünstlichkeit eingeführt, um den Lagezentrum eine
Orientierung zur Auswirkung von betroffenen Organisationen zu geben, ohne dass die
Teilnehmenden alle für das Planspiel ausgewählten Organisationen in ihren Abhängig-
keiten und Kooperationen genau kennen müssen.
8.2 Ablauf des Planspiels
Je nach Komplexität, Anzahl der Teilnehmenden und Übungstyp bzw. Übungsausprä-
gung4 müssen Tests der zur Verfügung stehenden Übungstechnik geplant und durchgeführt
werden. Der Aufwand für Teststellungen von weit verteilten Übungen sollte nicht unter-
schätzt werden. Hier sollte je nach Übungstyp auch ein Vorlauf von mehreren Tagen bis
Wochen eingeplant werden. Die Visualisierungsmöglichkeiten des Demonstrators wurden
seit Mitte des Jahres 2017 angepasst und wiederholt getestet. Die resultierenden Widgets
sowie der iterative Ansatz des Planspiels wurden im Dezember 2017 im Rahmen eines
Probedurchlaufes geprüft. Darauf aufbauend wurden Optimierungen hinsichtlich Orga-
nisation, Schulungsunterlagen und Software erhoben und zeitgerecht für den Planspiel-
termin umgesetzt.
Um alle beim Planspiel Anwesenden im Vorfeld auf das Szenario und auf die für sie
vorgesehene Rolle einzustimmen, wurden durch Infraprotect ab Mitte Jänner Vorabinfor-
mationen ausgesendet, wie z.B. das Arbeitsbuch für Teilnehmende, welches Hintergrund-
informationen zum Szenario bot (siehe auch Abschn.8.1.3). Beobachtende für das Plan-
spiel wurden bereits ein Tag zuvor in technische und organisatorische Grundlagen der
Übung eingewiesen.
Um die Teilnehmenden in die Handhabung des Demonstrators und genauer in ihre
Rolle in den Lagezentren einzuführen, wurden die ersten beiden Stunden am Planspiel-
tag für entsprechende Einweisungen verwendet, bevor mit den drei Iterationen gestartet
wurde. Während der Iterationen erfolgte die Betreuung der Teilnehmenden in den Lage-
zentren in erster Linie durch die Beobachtenden, welche den Lagezentren zugeordnet
waren. Nach dem Ende der letzten Iteration und der letzten durch die Teilnehmenden
auszufüllenden Bewertung erfolgte ein gemeinsames Debrieng anhand vorbereiteter
Leitfragen, bei welchem ein Sprecher pro Lagezentrum das Feedback des gesamten Lage-
zentrums vortrug.
4 Disloziert oder an einem Ort
312 M. Kaundert et al.
8.2.1 Technisches Setting
Das Übungssetting mit seinen Kommunikationskanälen ist in Abb.8.3 dargestellt. Die Ein-
spielungen an die Lagezentren erfolgten mittels des Demonstrators (blauer Pfeil), welcher
verschiedene, durch die Teilnehmenden exibel anpassbare Visualisierungen („Widgets“)
zur Darstellung der Daten bot. Jedes Lagezentrum war daher in der Lage, unterschiedliche
Widgets zur Darstellung ein- und derselben Lage zu nutzen.
Alle weiteren Kommunikationswege im Planspiel wurden mittels eines von T-System
Austria eingerichteten und vorkongurierten Chatsystems (mattermost) durchgeführt.
Ebenso wurden Rückfragen aus den Lagezentren in die von der fachlichen Übungsleitung
dargestellte „Außenwelt“ (CERT, kritische Infrastruktur, dem Lagezentrum übergeordnete
Ebene; schwarze Pfeile) von den Teilnehmenden durchgeführt.
Die organisatorische Übungsleitung kommunizierte, ebenfalls per Chat, mit den
Beobachtenden in den Lagezentren, um bspw. die Zeitpunkte für die Beantwortung der
Fragebögen jeder Iteration bekanntzugeben und andere organisatorische Absprachen zu
treffen und weiteren (technischen) Unterstützungsbedarf an die technische Übungsleitung
Abb.8.3 Kommunikationskanäle im Übungssetting
8 Evaluierung des Cyber Lagebildkonzepts im praktischen Einsatz 313
weiterzuleiten. Die fachliche, organisatorische und technische Übungsleitung hielten sich
weiters im selben Raum auf, was direkte Abstimmungen zum Szenario vereinfachte.
Das Planspiel selbst war aus Teilnehmendensicht größtenteils digital mit einzelnen ana-
logen Teilbereichen gestaltet. Mit anderen Worten, wurden Lagebildaspekte und Handlun-
gen in den Lagezentrennicht ausschließlich papierbasiert dargestellt oder umgesetzt. Die
Teilnehmenden konnten einerseits die Visualisierungen im Demonstrator äußerst exibel
den eigenen Bedürfnissen anpassen, um die durch das Drehbuch vorgegebenen Datenein-
spielungen darzustellen. Auch Warnungen und Endberichte konnten digital über eine im
Demonstrator eingearbeitete Plattform verfasst werden. Die Erhebung des Feedbacks der
Teilnehmenden zu den einzelnen Visualisierungen erfolgte in Papierform.
8.2.2 Drehbuch
Das in Abschn. 8.1.1 dargestellte Planspielszenario als Haupthandlungsstrang (Event)
gibt Rahmenbedingungen, Ausgangssituation und grobe Auswirkungsmöglichkeiten auf
die kritische Infrastruktur vor und damit auch Datensätze, welche für die Visualisierung
dieser Auswirkungen herangezogen werden können. Die Handlung einer Übung wird, wie
in Abb.8.4 gezeigt, auf drei Ebenen entwickelt:
Das Drehbuch jeder Iteration war in drei Phasen gegliedert (siehe Abb.8.5). Die Phasen
enthalten mehrereIncidents, also Situationen oder Geschehnisse im Rahmen des Hand-
lungsstranges, die diesen weiter detaillierten. Injects (Einspielungen) waren letztlich jene
Informationen, die in Form von freiwilligen Meldungen, Pichtmeldungen, Sensordaten
und Auditdaten bei den Teilnehmenden einlangten.
Abb.8.4 Hierarchieebenen
der Drehbuchentwicklung
Abb.8.5 Phasen jeder Iteration
314 M. Kaundert et al.
Die einzuspielenden Daten jeder Iteration wurden in jeweils einem eigenen Drehbuch
aufbereitet und über den Demonstrator visualisiert. Zwischen den Phasen waren längere
Zeitintervalle ohne Einspielungen vorgesehen, während derer Fragebögen (Evaluationen,
siehe auch Abschn.8.3) durch die Teilnehmenden ausgefüllt wurden. Diese Evaluationen
wurden als Meilensteine im Ablauf vermerkt.
8.2.3 Akteure
Drei Personengruppen wurden während des Planspiels unterschieden:
• Übungsleitung
• Teilnehmende Organisationen in Lagezentren
• Beobachtende
In den folgenden nächsten Abschnitten erfolgt die detaillierte Beschreibung der Aktueren.
8.2.3.1 Übungsleitung
Die Übungsleitung wurde, um den Kommunikations- und Steueraufgaben einer kom-
plexen Übung gerecht zu werden, in drei Rollen unterteilt und bestand aus Mitarbei-
tern von AIT, CERT, Infraprotect, Repuco Unternehmensberatung, SBA Research,
Thales und T-Systems Austria. Für die Übungsleitung war ein Übungsleitungs-inter-
nes, umfassendes Lagebild über die eingespielten Injects wichtig, um auf allfällige
nichtvorhersehbare Entwicklungen des Gesamtkollektivs rasch und efzient reagieren
zu können.
Die Aufgabe der Übungsleitung während des Planspiels lautete wie folgt:
• Steuerung des Szenarios durch Einspielungen welche im Demonstrator visualisiert
wurden
• Darstellung der Außenrealität für die Übenden (Behörden, First Responder, nicht
betroffene und betroffene Unternehmen etc.)
Die Verantwortlichkeiten in der Übungsleitung gliederten sich wie in Tab.8.6 gezeigt.
8.2.3.2 Teilnehmende Organisationen in Lagezentren
Das Lagezentrum war daher in seiner Denition für das Planspiel zu verstehen als ein k-
tives Konstrukt dessen Aufgaben im Hinblick auf die „Cyberlage“ in Österreich sich grob
in drei Punkten zusammenfassen lassen:
• Analyse eingehender Daten zur Beurteilung der aktuellen Sicherheitslage und Ausstel-
lung von Warnungen für kritische Infrastrukturen
• Beratende Tätigkeit (=Erstellung von Empfehlungen) für die übergeordneten Behör-
den/die übergeordnete politische Ebene
8 Evaluierung des Cyber Lagebildkonzepts im praktischen Einsatz 315
• Erkennen von Zusammenhänge/Abhängigkeiten im Lagebild und bei Bedarf Rück-
frage an kritische Infrastrukur/übergeordnete Ebene/CERT
Auf die Darstellung exakter Meldewege wurde bewusst verzichtet, da diese einerseits
im Vorfeld durch die Bedarfsträger nicht freigegeben wurden und andererseits nicht im
Scope des Planspiels lagen. Stattdessen wurde der Fokus auf die verwendeten Datentypen
und-visualisierungen für die Lagebeurteilung gelegt. Im Detail wurde von den Lagezent-
ren während des Planspiels erwartet:
• Die Situation und ihre Entwicklung zu beobachten
• Informationen zu sammeln, auszuwerten, zu aggregieren und so zu visualisieren, dass
dadurch ein Lagebild und eine Lageeinschätzung entwickelt werden kann, die bspw.
folgende Punkte umfasst:
– Handelt es sich um einen Angriff? Welche Methoden werden hierfür verwendet,
erfolgt er gerichtet oder ungerichtet?
– Welche Infrastrukturen sind aktuell betroffen und können aller Wahrscheinlichkeit
nach in Zukunft betroffen sein?
– Wie sieht ein worst case aus und welche Auswirkungen können im worst case erwar-
tet werden?
– Welche Handlungsempfehlungen können Entscheidungsträgern gegeben werden?
Die teilnehmenden Organisationen stellten Personal für die Besetzung der Lagezentren
zur Verfügung, welche den Demonstrator zur Lagebilddarstellung verwendeten. Im Plan-
spiel wurden alle vorhandenen Ressourcen ausgeschöpft und insgesamt fünf Lagezentren
(LZ) mit jeweils 3–4 Personen betrieben. LZ wurden von Teilnehmern von T-Systems
Austria, BMI und BMLV gespielt.
Jedes Lagezentrum erhielt weitergeleitete Freiwillige Meldungen und Pichtmeldun-
gen, First Responder agierten als Proxy und Quelle zugleich. Jedes Lagezentrum wurde
gleichzeitig mit denselben Informationen zur Lage konfrontiert. Es wurde erwartet, dass
die Darstellung via der im Demonstrator bereitgestellten Widgets im Sinne einer umfas-
senden Evaluation des Demonstrators von Lagezentrum zu Lagezentrum variierte.
Tab.8.6 Verantwortlichkeiten der Übungsleitung
Rolle Aufgaben
Organisatorische Übungslei-
tung (Gesamtleitung)
Gesamtsteuerung des Szenarios
Technische Übungsleitung Einspielungen an die Lagezentren via Demonstrator,
(technische) Infrastruktur
Fachliche Übungsleitung Rückfragemöglichkeit für Teilnehmer durch Darstellung von
CERT
kritischer Infrastruktur
dem Lagezentrum übergeordneter Ebene
316 M. Kaundert et al.
8.2.3.3 Beobachtende
Zwei Beobachtende waren jedem Lagezentrum zugeteilt und erfüllten dort folgende
Aufgaben:
• Technischer Support (Demonstrator Handling, Unterstützung bei der Visualisierung)
• Mitprotokollieren von Aktionen/Eindrücken der Übenden (z. B. Entscheidung zur
Frühwarnung)
• Klarstellen von unter Umständen unklaren Fragestellungen der Evaluierungsbögen
• Kommunikationsschnittstelle zur organisatorischen Übungsleitung zur Abstimmung
der Evaluierungszeitpunkte im Szenario
Zur optimalen Vorbereitung der Beobachtenden auf ihre Rolle wurden diese bereits am
Vortag durch Thales und Infraprotect in die Handhabung des Demonstrators und die orga-
nisatorischen Abläufe des Planspiels eingeführt. Es war das Ziel, einen Beobachtenden
vorrangig als Unterstützung für die Teilnehmenden einzusetzen, den anderen als Proto-
kollführer zur Erfassung von Eindrücken aus der Beobachtenden-Perspektive. Daher liegt
zumindest ein Beobachtenden-Protokoll pro Lagezentrum vor.
8.3 Evaluierung
Dieser Abschnitt beschreibt die Evaluationsprozesse, die diesen Ergebnissen zugrunde
liegen.
Die Datendarstellungen wurden von den Teilnehmenden bewertet nach:
• Nutzen der graschen Darstellung (Diagrammtyp, Informationsdichte, Hervorheben
besonderer Aspekte udgl.)
• Verknüpfung von Informationen: Welcher Mehrwert wird durch die Verknüpfung der
einzelnen Daten erzielt? (z.B. Verknüpfung der Nachricht einer einmeldenden Organi-
sation mit den Audit-Daten der letzten Audit-Periode)
• Nutzen in Bezug auf den „Erkenntnisgewinn“ und Unterstützung zur Entscheidungs-
ndung
Diese Bewertung erfolgte durch die teilnehmenden Personen in den Lagezentren während
der Iterationen auf zwei Wege:
1. Als analoger Fragebogen welcher zu vordenierten Zeitpunkten im Szenario durch die
Teilnehmenden ausgefüllt wird (getriggert durch die Beobachtenden)
2. Durch Erstellen einer Frühwarnung (für kritische Infrastrukturen) und eines Endberich-
tes zum Ereignis anhand vorgefertigter Templates. Diese werden nach dem Ausfüllen
direkt via Übungschat an die Übungsleitung übermittelt.
8 Evaluierung des Cyber Lagebildkonzepts im praktischen Einsatz 317
Die Gliederung jeder Iteration in 3 Phasen ermöglicht eine Bewertung jeder Iteration
anhand dreier Evaluierungsschritte, wie in Tab.8.7 gezeigt:
Die Evaluierungen wurden anhand von Fragebögen in analoger Form den Teilnehmenden
durch die Beobachtenden vorgelegt. Bei den Evaluierungsschritten A und C wurden zusätz-
lich die Möglichkeit, eine Warnung für kritische Infrastruktur auszufüllen (A) und das Ver-
fassen eines Endberichtes zum Ereignis (C) gepromptet. Der Einspielungen der Injects via
Demonstrator waren derart getimt, dass für das Ausfüllen der entsprechenden Fragebögen
und das Ausstellen von Warnung und Endbericht ausreichend Zeit zur Verfügung stand.
Die Fragestellung für jeden Evaluierungsschritt konzentriert sich im Wesentlichen auf
folgende Punkte:
• Was ist Ihre nächste Aktion?
• Auf welche Daten/Infos des Lagebildes stützen Sie diese Aktion?
• War die Art der Darstellung hilfreich oder würden Sie eine andere/erweiterte Darstel-
lung bevorzugen?
• Welche Daten/Informationen fehlen Ihnen im Interface bzw. würden Sie in der Realität
erfragen?
• Welche Daten/Informationen waren für die Entscheidungsndung in der aktuellen
Phase nicht nützlich?
8.3.1 Rahmendatenerfassung: anonymisierte und personalisierte
Fragebögen
Um den Input jeder einzelnen teilnehmenden Person zu sammeln und Dominanzeffek-
ten in der Gruppendynamik vorzubeugen, erhielten die Übenden nach jeder Phase einer
Tab.8.7 Evaluierungsschritte in den drei Iterationen
Iteration Evaluierungsschritt Evaluierte Phase
11A Beginn bis Frühwarnung
1B Frühwarnung bis Entwarnung
1C Entwarnung bis Ende
22A Beginn bis Frühwarnung
2B Frühwarnung bis Entwarnung
2C Entwarnung bis Ende
33A Beginn bis Frühwarnung
3B Frühwarnung bis Entwarnung
3C Entwarnung bis Ende
Allgemeiner Block 4Vergleichsfragen zwischen allen 3
Iterationen
318 M. Kaundert et al.
Iteration einen Fragenbogen, der nicht in der jeweiligen Lagezentrum-Gruppe auszufüllen
war, sondern der den Blickwinkel und die Meinung der Einzelperson erfassen sollte.
Vollständig anonymisierte Fragebögen erheben ausschließlich Antworten und lassen
den Kontext der Übenden (Rolle in der Organisation, technischer Background etc.)
außer Acht. Dieser positivistische Ansatz (della Porta und Keating 2008) vernachlässigt
jedoch die Art und Weise wie Übende aus ihrem jeweiligen Kontext heraus das Planspiel
wahrnehmen, das Lagebild entwickeln und die Situation einschätzen – der eigene Back-
ground bzw. der eigene Kontext ist daher eine essenzielle Variable in der Evaluierung
des Demonstrators. Obwohl unter vollständiger Anonymisierung, besonders bei sensitiven
Themen, in der Regel ehrlichere Antworten zu erwarten sind (Dunbar et al. 2001) wird
der Wissensgewinn aus dem jeweiligen Kontext der übenden Personen als zu wichtig ein-
geschätzt um ihn außer Acht zu lassen. Es werden daher folgende Rahmeninformationen
pro Fragebogen erhoben:
• Rolle in der Organisation: technisch oder organisatorisch
• Nummer des Lagezentrums: 1–5
Die Organisation, welche das Lagezntrum betrieb, musste nicht eigens erhoben werden,
da die Lagezentren mit homogenen Gruppen besetzt wurden. Dies ermöglichte zwar eine
grundsätzliche, annähernde Identikation der Übenden, die jedoch nicht mit einer de-
nitiven namentlichen Zuordnung des Fragebogens zu einer Person vergleichbar ist und
somit einer Anonymisierung beinahe gleichkommt. Zusätzlich wurde mehrmals (bereits
ab Aussendung der Vorinformation an die Teilnehmenden) betont, dass nicht die Teilneh-
menden im Zentrum der Evaluierung des Planspiels standen, sondern die Visualisierungs-
optionen des Demonstrators. Dies sollte den Fokus weg vom Gefühl einer persönlichen
Verantwortung/Rechenschaft der Übenden hin zu den eigentlichen Übungszielen lenken
und somit die Auskunftsfreudigkeit bzw. Antwortbereitschaft beim Ausfüllen der Frage-
bögen verstärken. Die Beobachtenden in den LZ wurden vorab zu den Fragebögen ein-
gewiesen und trugen Sorge für die Klärung von Formulierungen, welche für die Übenden
u.U. trotz sorgfältiger Vorbereitung missverständlich waren.
8.3.2 Methodik der Evaluierung
Die Erfassung der Aktivitäten der Teilnehmenden und somit die Datensammlung für die
Evaluierung des Demonstrators erfolgte auf vier unterschiedlichen Wegen:
1. Durch die Kommunikation der Übenden mit der „Außenwelt“ (=Übungsleitung) im
Rahmen des Planspiels (z.B. Rückfragen an CERT)
2. Durch die Beobachtenden
3. Durch das Ausfüllen der Fragenbögen durch die Übenden selbst
4. Durch Abfragen zweier konkreten Handlungen im Rahmen des Planspiels (Warnung
und Endbericht)
8 Evaluierung des Cyber Lagebildkonzepts im praktischen Einsatz 319
Auf diese Weise wurden Eindrücke zur Demonstratornutzung auf verschiedenen Wegen
gesammelt und können im Rahmen der Auswertung abgeglichen und kontextualisiert
werden. Eine Selbsteinschätzung zur Handhabung der Visualisierungen (Fragebogen) und
eine Fremdeinschätzung (Beobachtung) wurden erhoben, was zu zusätzlicher Anreiche-
rung der Auswertung des Planspiels führte.
Im Rahmen von komplexen Übungen ist eine Bewertung von organisations-/unter-
nehmensinternen, technisch-organisatorischen Zielsetzungen grundsätzlich von „Eigen-
personal“ vorzunehmen, welches vergleichbare Aufgaben in der Regelorganisation
bzw. Aufbau und Ablauforganisation der jeweiligen Organisation wahrnimmt. Da die
Übungsziele des CISA Planspieles jedoch nicht auf die Bewertung der technisch-orga-
nisatorischen Aspekte (wie z.B. Stabsarbeit) abzielten, sondern ausschließlich auf die
Einschätzung der Übenden bezüglich des konkreten Nutzens des Demonstrators (siehe
Abschn.8.1.1), konnten die Blickwinkel „externer“ Beobachtender in die Erstellung des
Fremdbildes sinnvoll miteinbezogen werden, indem diese die Interaktion der Teilnehmen-
den mit dem Demonstrator und Aspekte der Entscheidungsndung im Handling des Tools
mitprotokollierten. Für eine Darstellung der Ergebnisse, siehe Abschn.8.4
8.3.3 Warnung an kritische Infrastrukturen, Verfassen Endbericht
Die Warnung an kritische Infrastrukturen ebenso wie der Endbericht konnten auf Basis
der Informationsdichte unterschiedlich detailliert/konkret gestaltet werden, im Hinblick
auf den Informationsgehalt der Warnung oder der Szenariobeschreibung im Endbericht
selbst, als auch bezogen auf den Adressatenkreis (pro Sektor/Unternehmensgröße) oder
im Einsatz bendliche Assets etc). Die Warnung und der Endbericht wurden von den Teil-
nehmenden praktisch während der Durchführung des Planspiels gestaltet (Warnung: 1x
pro Iteration am Ende von Phase I – Evaluationsschritt A, Endbericht: 1x pro Iteration am
Ende von Phase III, vgl. Tab.8.7 und Abb.8.6) und auf zwei Wegen dokumentiert:
• durch die Beobachtende (Dokumentation der Entscheidungsndung)
• durch das Ausfüllen eines vorgefertigten Templates.
Somit wurde spezisch anhand der Durchführung von Handlungen welche auf den Infor-
mationen, ihrer Darstellung und ihrer Bewertung im Lagebild beruhen, die Lageeinschät-
zung der Teilnehmenden erhoben. Warnung und Endbericht wurden digital während des
Planspiels erfasst und ebenfalls qualitativ ausgewertet.
8.3.4 Datenerhebung im Fragebogen: Methode und Skalierung
Für die Datenerhebung der Fragebögen, welche an die Teilnehmenden ausgegeben
wurden, wurden folgende Antwortmethoden eingesetzt:
320 M. Kaundert et al.
Abb.8.6 Erstellen einer
Warnung im Demonstrator
• Vermerk auf einer vierteiligen Beurteilungsskala („Likert“)
• Beantwortung mittels Multiple Choice Fragen
• Freitextantworten
Generell gesprochen zielen die im Planspiel zur Datenerhebung verwendeten Methoden
darauf ab, zwei Aspekte zu erheben:
1. Korrelation unterschiedlicher Wahrnehmungen von Visualisierungen (Konvergenzvali-
dität)
2. Unterschiede in der Wahrnehmung von Visualisierungen (Diskriminanzvalidität)
Dies erinnert oberächlich an einen Multitrait-Multimethod-Ansatz (Campbell und Fiske
1959), jedoch wurde auf die Erstellung einer entsprechenden Matrix zur Auswertung ver-
zichtet, da diese einerseits äußerst aufwendig in der Erarbeitung ist und andererseits auf-
grund der unklaren Auszählregelungen das Ergebnis fragwürdig erscheinen lässt (Bagozzi
1980; Peter 1981). Stattdessen erfolgt eine quantitative und qualitative Aggregation der
erhobenen Antworten, sowie eine qualitative Inhaltsanalyse der Freitextantworten auf Basis
der induktiven Kategorienentwicklung, die stark vereinfacht in Abb.8.7 dargestellt ist.
Die Fragenbeantwortung wurde jeweils zum Ende einer Phase durch die Beobach-
tenden eingeleitet; daraus folgt, dass die Teilnehmenden während des Szenarioablaufes
Fragen zur eben vergangenen Phase beantworteten und nicht etwa einen gesammelten
Fragebogen am Ende jeder Iteration bearbeiteten. Dieser Ansatz ermöglichte eine gleich-
mäßige Abfrage zur Einschätzung der verwendeten Visualisierungsoptionen und beugt
dem Primacy-Recency-Effekt (Murdoch 1962) vor. Bei diesem Effekt würden Informatio-
nen, die zu Beginn bzw. zum Schluss der Übung aufgenommen wurden, überproportional
repräsentiert werden. Die entwickelten Fragebögen wurden im Rahmen des CISA Probe-
durchlaufes im Dezember 2017gemeinsam mit dem Drehbuch und dem Demonstrator
getestet, um einerseits durch Austestung an einer externen Personengruppe etwaige, offen-
sichtliche Missverständnisse in der Formulierung offenzulegen, andererseits, um die Zeit-
dauer, welche für die Beantwortung eingeplant war, praktisch zu überprüfen. Die Beob-
achtenden, welche den Teilnehmenden während des Planspiels zur Seite gestellt bekamen,
waren zu einem großen Teil aus den Test-Teilnehmenden dieses Probedurchgangs, was die
8 Evaluierung des Cyber Lagebildkonzepts im praktischen Einsatz 321
Einschulung der Beobachtenden in ihre Rolle ressourcenschonend gestaltete und verein-
fachte. Ein bedeutender Teil dieser Rolle war die Vorbeugung von unbeabsichtigten Inter-
pretationen aller Fragenmethoden (Beurteilungsskala, Multiple Choice, Freitext) durch
die Teilnehmenden.
In Folge werden die Aspekte, welche zu einer Auswahl der jeweiligen Methode für das
Planspiel geführt haben, aufgeführt.
Beurteilungsskalen wurden erstmals im frühen 20. Jahrhundert eingesetzt (Likert
1932, Thurstone und Chave 1929) und stellen seither ein häug genutztes Instrument der
Sozialwissenschaften zur Messung von Meinungen und Einstellungen dar. „Einstellun-
gen“ sind höchst subjektive, individuelle Konstrukte, deren absolute Messung de facto
nicht möglich ist, da die Antwort des Teilnehmenden immer ein Resultat des Zusammen-
wirkens äußerer Faktoren darstellt (Krosnick und Fabrigar 1997). Dies bedeutet, dass die
Nutzung einer Beurteilungsskala immer nur eine Momentaufnahme, gefärbt durch viele
verschiedene Faktoren, ergibt, und bei längeren Befragungspausen sich der individuelle
Referenzrahmen des Probanden ändern kann, was die Zuverlässigkeit und Vergleichbarkeit
der Daten negativ beeinusst. Um dem vorzubeugen wurden einerseits alle drei Iteratio-
nen des Planspiels an einem Tag abgehalten, andererseits wurden die Iterationen und auch
die Fragebögen so straff wie möglich gestaltet. Ein Nebeneffekt einer solchen Straffung
ist jedoch, dass Probanden sich an ihre gegebenen Antworten exakter erinnern können und
dazu tendieren, diese zu wiederholen. Die gewählte Skalierung (4-teilig) sollte einerseits
Abb.8.7 Induktive Kategorienentwicklung nach Mayring (2000)
322 M. Kaundert et al.
den Teilnehmenden die Möglichkeit geben, auch weniger extreme Meinungen angeben
zu können, ohne dabei die Klarheit der Standpunkte durch zu detaillierte Abstufungen
aufzuweichen, da mit höherer Anzahl der möglichen Abstufungen die Bedeutung und
Abgrenzung der einzelnen Antwortoption abnimmt (Krosnick und Fabrigar 1997). Der
Nutzen einer neutralen Antwortmöglichkeit (wie z.B. die Antwortoption „keine Tendenz“
im Beispiel in Abb.8.8) und ihre Auswirkungen auf die erhobenen Daten werden in der
Literatur kontroversiell diskutiert und können nicht als abschließend geklärt betrachtet
werden (Andrews 1984; Krosnick et al. 1996; Madden und Klopfer 1978). Ein beson-
ders relevanter Kritikpunkt an einer fehlenden neutralen Antwortmöglichkeit wird von
Larossi (2006) erwähnt: Sind eine Antwortoption bzw. die Fragestellung unklar, tendieren
Probanden dazu, nicht ihrer Einstellung tatsächlich entsprechende Antworten zu geben
(satiscing), was zur Verfälschung der Daten führt. Insbesondere in einem derart techni-
schen Setting wie dem CISA Planspiel ist so die Gefahr zur Datenverfälschung gegeben,
wenn Teilnehmende mit wenig technischem Background zu den technischen Aspekten
des Demonstrators befragt werden. Beim Entwurf der Fragebögen für das Planspiel wurde
aufgrund des Einsatzes der Beobachtenden als Klärungs-Instanz für die Teilnehmenden
von der Option einer neutralen Antwort Abstand genommen.
Multiple Choice Fragen zwingen Probanden zu einer (oder mehreren) Antworten
unter Verwendung eines geschlossenen Fragenformats. Während das Format für Tests aller
Art eingesetzt wird (beginnend bei IQ-Tests bis hin zu Aufnahmetests an Universitäten)
und hierbei das Erheben von „richtigem“ und „falschem“ Wissen und somit die Eignung
von Probanden im Vordergrund steht, lag im Rahmen des CISA Planspiels das Hauptau-
genmerk auf der Evaluierung des Demonstrators. Hier konnte es naturgemäß keine absolut
richtige oder falsche Antwort, sondern lediglich eine individuelle Bewertung von Visuali-
sierungen und Datentypen durch die Teilnehmenden geben. Das Multiple Choice Format
wurde im Planspiel in erster Linie eingesetzt, um eine rasche, vergleichbare Auswertung
der Antworten durchführen zu können.
Freitextantworten wurden zum Teil als Zusatzfeld angeboten, um gegebene Multiple
Choice Antworten genauer zu spezizieren, zum Teil handelte es sich auch um alleinste-
hende Antworten. Freitextantworten beinhalten einerseits die Möglichkeit für Probanden,
ohne vorgegebenes Gerüst der eigenen Meinung Ausdruck verleihen zu können, anderer-
seits liegt genau darin auch ihre größte Schwäche da sich hierdurch die Auswertung der
Daten verkompliziert, weil Freitext nicht quantitativ wie Multiple Choice Fragen ausge-
wertet werden kann. Probanden können unter gewissen Umständen auch dazu tendieren,
in Freitextantworten zu detaillierte oder zu oberächliche Information zu geben, bzw. in
ein vom Fragensteller unbeabsichtigtes Thema „abzurutschen“.
Abb.8.8 Beispiel einer 5-teiligen Likert-Skala
8 Evaluierung des Cyber Lagebildkonzepts im praktischen Einsatz 323
8.3.5 Debrieng
Die im Debrieng der Teilnehmenden und Beobachtenden eingeholten Informationen
wird anhand von Leitfragen gegliedert um eine gemeinsame Struktur zu erarbeiten. Diese
Leitfragen lauteten:
• Was hat Sie im Demonstrator bei der Lagebeurteilung besonders unterstützt?
• Was hat Sie im Demonstrator besonders abgelenkt/verunsichert?
• Haben Sie sonstige Anmerkungen zur Übung bzw. Wünsche für den Demonstrator?
Die resultierenden Anmerkungen können in mehrere Typen (und übergeordnete Katego-
rien) gegliedert werden wie in Tab.8.8 dargestellt.
8.4 Gesamtinterpretationen der Ergebnisse und Erkenntnisse
Folgend werden die Ergebnisse der Evaluation dargelegt. Hierbei werden die Rück-
meldungen in Hinblick auf ihre Auswirkungen aufbereitet: Welche Charakteristika des
Demonstrators (Datenvi-sualisierungen und –verknüpfungen) zeigten unter Umständen
Auswirkungen auf die Lagebeur-teilung durch die Teilnehmenden (bezüglich Erstellung
einer Warnung, Sicherheit in der Lage-beurteilung usw.)?
Tab.8.8 Kategorien der Rückmeldungen
Übergeordnete
Kategorie
Typ Rückmeldung Definition
Daten Visualisierung Visualisierung von Daten (-verknüpfungen) im
Demonstrator
Verknüpfung Verknüpfung von Datentypen im Demonstrator
Auditdaten Auditdaten/-scores und deren Anwendung betref-
fend
Sensoren Anm. zu Sensordaten und deren Anwendung
Technik Filter Anm. zu Filterfunktionen des Tools
Annotations Anm. zu Annotationsfunktionen
Technik sonstiges Andere technische Aspekte des Demonstrators und
seine Features
Teilnehmende Reaktion Teilnehmer-bezogenes Feedback, Anm. der Teil-
nehmer zu bestimmten Punkten des Planspiels
Kommunikation Anm. zu Kommunikation im Lagezentrum bzw.
zwischen LZ und „Außenwelt“
Sonstiges Methodik Anm. zu methodischem Aufbau des Planspiels
324 M. Kaundert et al.
8.4.1 Ergebnisse Szenariobeurteilung
8.4.1.1 Einschätzung der Sicherheit bei Lagebeurteilung und Einschätzung
der Gefährdungslage
Der konkrete Nutzen des Lagebildes zur Lageeinschätzung stellte eine integrale Frage des
CISA Projektes dar. Daher ist es relevant, inwiefern sich durch Anwendung des Demons-
trators die Lageeinschätzung und -beurteilung im Lauf des Planspiels veränderte. Dies
ist in Abb.8.9 dargestellt. Hier ist einerseits die Sicherheit bei der Lagebeurteilung als
auch die Einschätzung der Bedrohungslage gezeigt, wobei Stufe vier als das Maximum
von Sicherheit bei Bedrohungseinschätzung und Sicherheit der Lagebeurteilung gilt. Die
Sicherheit der Einschätzung ist durch alle drei Iterationen hindurch relativ gleichbleibend.
Der leichte Abstieg zu Beginn von Iteration zwei wirkt nicht signikant, kann aber unter
Umständen mit der Informations-„Flut“ durch die Sensordaten zu Beginn von Iteration
zwei korrespondieren. Die Einschätzung der Bedrohung ist in Phase 1 von Iteration I
vergleichsweise gering, wohl, weil es sich um die erste Anwendung des Tools nach der
Einschulungsveranstaltung für die Teilnehmenden handelte und sie sich erst mit dem Sze-
nario und den Darstellungsvarianten im Dashboard vertraut machen mussten. Ansonsten
ist auch die Einschätzung der Bedrohungslage relativ konstant durch alle Runden, was
darauf fußen kann, dass sich das Basisszenario nicht änderte. Die Erhöhung der Informa-
tionsdichte hatte hier auf die Gefährdungseinschätzung anscheinend keine Auswirkung.
8.4.1.2 Ausgabe von Warnungen
Auf Basis der vorliegenden Informationen wurden die Teilnehmenden gebeten, einzuschätzen,
ob sie eine Warnung an kritische Infrastruktur erstellen würden und diese bei Bedarf als Lage-
zentrum zu erstellen. Dies spiegelt die Einschätzung der Bedrohlichkeit der Lage wider. Der
zeitliche Verlauf der Warnungsausgabe durch die Lagezentren (LZ) ist in Abb.8.10 gezeigt.
Abb.8.9 Lage-Einschätzung und Sicherheit der Lagebeurteilung
8 Evaluierung des Cyber Lagebildkonzepts im praktischen Einsatz 325
8.4.1.3 Analyse des Inhalts von Warnungen und Endberichten
Die Analyse des Inhalts der von den Lagezentren ausgegebenen Warnungen und End-
berichte ergab, dass die Inhalte der einspielten Meldungen prinzipiell wahrgenommen
wurden: das Vorhandensein von Sicherheitslücken und Schadsoftware wurde ebenso fest-
gestellt wie das Auftreten von TOR Trafc (siehe Abb.8.11)
Die möglichen Auswirkungen des Ereignisses sind in erster Linie mit der aufgetretenen
Schadsoftware verknüpft (Erpressung und Verschlüsselung), eine Denition hinsichtlich
möglicher weitreichender oder kaskadierender Effekte ist größtenteils nicht erfolgt (nicht
näher speziziert bzw. keine Auswirkungen).
8.4.1.4 Getroene Gegenmaßnahmen der Lagezentren
Tab.8.9 zeigt die Auswertung der Templates Warnungen an die kritische Infrastruktur und
Endberichte an die übergeordnete Ebene. Die Rückmeldungen der Templates aller Lagezen-
tren wurden in der Reihenfolge entsprechend der Struktur der Vorlagen gruppiert. Abb.8.12
zeigt, welche Gegenmaßnahmen von allen Lagezentren in den Endberichten genannt wurden.
Abb.8.10 Ausgabe von Warnungen im Planspiel
Abb.8.11 Aspekte des Lagebildes nach Warnung/Endbericht
326 M. Kaundert et al.
Tab.8.9 Gruppierung der Auswertung von Warnungen und Endberichten
Warnungen
Gruppierung/Frage Nennung der LZ
Begründung (für nicht Aus-
stellen einer Warnung)
Weitere Beobachtung nötig
Einbindung anderer Stellen
Unkritische Lage
Beschreibung Angriff (Schadsoftware)
Beschreibung Angriff (TOR Traffic)
Beschreibung Angriff (Sensorik)
Beschreibung Angriff (Sicherheitslücken)
Beschreibung der Lage Beschreibung Betroffene (Nicht näher genannte Org.)
Beschreibung Betroffene (Gesundheitssektor)
Beschreibung Betroffene
Beschreibung Betroffene (Behörden)
Beschreibung Betroffene (Lebensmittelversorgung)
Beschreibung zeitl. Aspekte (Angriff in engem Zeitintervall)
Prognose Verbreitung
Auswirkungen des Angriff Verschlüsselung
TOR Traffic
Erpressung
Gefährdung
Auswirkungen auf Risiko-
gruppen
Lebensmittelversorgung
Gesundheitssektor
Behörden
Banken
Institutionen
Nicht spezifiziert
Handlungsempfehlungen Analyse
Beobachtung
Kommunikation
Technik
Endberichte
Gruppierung Untergruppe 1
Auswirkungen Angriff Verschlüsselung
8 Evaluierung des Cyber Lagebildkonzepts im praktischen Einsatz 327
Erpressung
TOR Traffic
Unkritische Auswirkungen
Keine Auswirkungen
Auswirkung nicht näher spezifiziert
Zeitl. Auswirkungen des Angriffs 5-24h
24h und mehr
Keine Angabe
Keine Auswirkungen
Nicht näher spezifiziert
Getroffene Maßnahmen Technische Maßnahmen
Kommunikation
Warnung
Analyse/Monitoring
keine
Empfehlungen Analyse/Monitoring
Kommunikation
Handlungsempfehlungen
Technische Maßnahmen
Worst-Case Auswirkungen Ausfall von Sektoren
Geringe Ausfälle
Restrisiko
Ausbreitung Schadsoftware
Risikogruppen nach Sektor Behörden
Lebensmittelversorgung
Gesundheitssektor
Energie
Transport
Finanzsektor
Banken
Digitale Infrastruktur
Industrie
Tab.8.9 (Fortzetzung)
328 M. Kaundert et al.
Prominent ist hier vor allem die Zunahme der Nennung von Kommunikationsmaßnah-
men zwischen Iteration 1 und 2, der Abfall der Ausstellung einer Warnung als Gegenmaß-
nahme und die Zunahme von „keinen Gegenmaßnahmen“.
8.4.2 Ergebnisse zu verwendeten Datentypen und Visualisierungen
Es kann zusammengefasst werden, dass alle angebotenen Datentypen (Meldungen, Sen-
sordaten und Auditdaten) von den Teilnehmenden im Rahmen des Szenarios angenommen
wurden, wobei nicht alle Datentypen und -verknüpfungen als gleichermaßen sinnvoll zur
Lagebeurteilung eingeschätzt wurden. Die Abfrage der Nützlichkeit der einzelnen Visua-
lisierungen erfolgte hierbei in den Fragebögen für die Teilnehmenden. Grundlage ist die
Summe der Bewertungen „eher hilfreich“ und „hilfreich“ aller Lagezentren in allen Ite-
rationen für die Visualisierungen in den Fragebögen. Eine Zusammenfassung der Ergeb-
nisse zeigt Abb.8.13. In Folge werden die „Top Ten“ der in Abb.8.13 angeführten Visua-
lisierungen kurz beschrieben.
1. Als zentrales Element im Demonstrator wurde von Teilnehmenden und Beobachtenden
gleichermaßen Vis-12* (Abb.8.14) angegeben, welche tabellarisch den Verlauf und
ausgewählte Inhalte der einzelnen Meldungen anzeigt. Die Meldungskritikalität wurde
hier von einigen Teilnehmenden als besonders hilfreich angegeben.
Abb.8.12 Zahl und Art der Gegenmaßnahmen im zeitlichen Verlauf
8 Evaluierung des Cyber Lagebildkonzepts im praktischen Einsatz 329
2. Auf Platz zwei wurde Vis-01gereiht, welche den Eingang von ausschließlich Picht-
meldungen (unten) und freiwilligen Meldungen (oben) im zeitlichen Verlauf zeigt
(Abb.8.15). Ein Herausltern eines konkreten Zeitbereiches war möglich.
3. Ab Iteration zwei verfügbare Sensordaten wurden in Vis-02 (Abb. 8.16) bevorzugt
angezeigt, welche die Sensorinputs nach CVE auf einer Timeline darstellte.
4. Vis-22 (Abb.8.17) stellte erneut einen tabellarischen Meldungsverlauf dar, der jedoch
nur Sensordaten und Meldungsdaten inklusive einer Vorfallsbeschreibung darstellte.
Im Unterschied zum Meldungsverlauf sind hier weniger Informationen dargestellt.
5. Vis-03 (Abb.8.18) zeigt die Meldungen und Sensordaten nach Auditscore eingefärbt.
Dargestellt wird die Anzahl der Einträge auf einer Timeline.
6. Vis-28 zeigt den Fortschritt der Gegenmaßnahmen, welche durch die betroffene kri-
tische Infrastruktur zu Ereignisbewältigung ergriffen wurden. Der Fortschrittsgrad
(rechts in Abb. 8.19) wird dabei von der kritischen Infrastruktur selbst angegeben
und im Demonstrator dargestellt. Gegenmaßnahmen mit einem Fortschritt von 100%
(=gelöstes Problem) wurden in dieser Darstellung ausgeblendet.
7. Vis-06 zeigt die Meldungskritikalität LOW/MEDIUM/HIGH (welche von den kriti-
schen Infrastrukturen selbst vergeben wird) pro Sektor als Treemap an (Abb.8.20). Die
Zahlenangabe in den jeweiligen gefärbten Bereichen bezieht sich auf die Anzahl der
getätigten Meldungen.
8. Die Word-Cloud in Vis-10 (Abb.8.21) welche die häugsten CVEs zeigte, stellte einer-
seits einen sehr kritisch beurteilten Punkt im Debrieng dar, bei dem einige Teilneh-
mende anmerkten, die Darstellung nur eingeschränkt sinnvoll zu nden. Andererseits
wurde diese Visualisierung häug genug als „sehr hilfreich“ oder „eher hilfreich“ ein-
gestuft, um eine Platzierung in den „Top Ten“ zu erreichen.
Abb.8.13 „eher hilfreiche“ und „hilfreiche“ Visualisierungen
Abb.8.14 Vis-12: Meldeverlauf
Abb.8.15 Vis-01: Pichtmeldungen und Freiwillige Meldungen im zeitlichen Verlauf
Abb.8.16 Vis-02: Sensordaten pro CVE im zeitlichen Verlauf
Abb.8.17 Vis-22: Meldungsverlauf (nur Sensor- und Meldungsdaten)
Abb.8.18 Vis-03: Meldungen und Sensordaten gefärbt nach Auditscore
8 Evaluierung des Cyber Lagebildkonzepts im praktischen Einsatz 335
9. Vis-05 (Abb. 8.22) zeigt die Auditbewertung pro NIST Maßnahme pro Sender an
(siehe Beschreibung der Auditdaten in Abschn.8.1.4.3). Hierbei gilt die Aufschlüsse-
lung: grün=hoher Reifegrad, gelb=mittlerer Reifegrad, rot=niedrigere Reifegrad,
blau=keine Information.
10. Eine Verteilung der von CVEs betroffenen (rot) und nicht betroffenen Unternehmen
(grün) pro Sektor wird in Vis-21 gezeigt, wobei ein PieChart einen Sektor darstellt.
Im Vis-21 Beispiel in Abb.8.23 wird zum Beispiel abgebildet, dass die Sektoren im
ersten und zweiten PieChart von rechts von allen gezeigten Sektoren am stärksten
durch die relevanten CVEs betroffen sind.
Darstellungen und Widgets
In Bezug auf die im Demonstrator benutzten Visualisierungen lässt sich große Afnität
zu bekannten und weniger komplexen Darstellungsformaten erkennen, einerseits basie-
rend auf Aussagen der Teilnehmenden („Listen sind am besten“, „Word Cloud lieber als
Tabelle darstellen“), andererseits auch nach Auswertung der Fragebögen und dem resul-
tierend „Top-Ten“ Ranking der hilfreichen Visualisierungen (siehe Abb.8.13). Drei der
zehn Visualisierungen sind tabellarisch, drei weitere sind klassische Balken-/Säulendia-
gramme, eines ist ein PieChart. Komplexere Darstellungen wie Treemaps, Heatmaps oder
Trenddiagramme kommen wenig bis gar nicht in den zehn beliebtesten Darstellungen vor.
Dies ist sicherlich einerseits den technischen Optionen des Demonstrators geschuldet, der
nicht jede angedachte Diagrammart optisch ansprechend abbilden konnte, andererseits
auch dem Szenario, das durch die Komprimierung auf Iterationen von etwa eineinhalb
Stunde Länge auch auf einer gewissen Einfachheit gehalten werden musste.
Dennoch kann der Großteil der beliebtesten Visualisierungsarten durchaus als „klas-
sische“ oder „typische“ Darstellungen gewertet werden. Dies ist auch ein Symptom des
„entschleunigten“ Übungsablaufes: die Teilnehmenden hatten ausreichend Zeit, um Text
(z.B. Freitexteinträge in den Pichtmeldungen) zu lesen und darüber zu diskutieren, was
im Sinne des Planspielzieles war. Eine intensivere Bespielung der Lagezentren mit Infor-
mation würde auch den Bedarf nach aggregierteren Graken erhöhen (im Vergleich zu
textbasierten Listen), da schnellere Erfassung einer komplexeren Situation unter Druck
erfolgen müsste.
Abb.8.19 Vis-28: Fortschritt der Gegenmaßnahmen
Abb.8.20 Vis-06: Meldungskritikalität pro Sektor
8 Evaluierung des Cyber Lagebildkonzepts im praktischen Einsatz 337
Folgende Anmerkungen zu den Visualisierungen lassen sich ableiten:
• Um (topograsche) Karten sinnvoll gestalten zu können, sind zunächst umfassende
Risiko- und Folgeanalysen nötig, sowie Anschluss an das Asset Management der ent-
sprechenden Organisation. So ließen sich auch Kaskadeneffekte in kritischer Infra-
struktur und daraus folgend Auswirkungsabschätzungen sinnvoll umsetzen.
• Die Vorliebe für „klassische“ Darstellungsarten ist zum Teil wohl der Tatsache geschul-
det, dass die Zeit um die Teilnehmenden in das Tool und die vorbereiteten Visualisie-
rungen einzuführen, beschränkt war und nicht mit einem tatsächlichen Training für
Operateure gleichgesetzt werden kann. Obwohl das Planspiel keinen stressbasierten
Ansatz verfolgte, stellte das Setting (neues Tool, neue Rolle als Operateur im Lage-
zentrum, im Detail unbekanntes Szenario) eine gewisse Belastung dar, was dazu führen
kann, dass Nutzung „altbekannter“ Tabellen und Visualisierungen bevorzugt wird.
• Wenn die Visualisierungen des Planspiels in Zukunft adaptiert zum Einsatz kommen
sollen, empehlt es sich, sie vorab unter größerem Druck (wie z.B. einer stressbasier-
ten Übung) auf ihre Anwendbarkeit zu testen.
8.4.3 Ergebnisse Debrieng
Mit Teilnehmenden und Beobachtenden wurde jeweils ein Debrieng direkt im Anschluss
an das Planspiel abgehalten mit dem Zweck, Rückmeldungen gesammelt abzufragen und
Raum für Input zu schaffen, welcher durch die Fragebögen und Protokolle nicht abge-
deckt worden war. Das Debrieng wurde anhand von zuvor verteilten Leitfragen struktu-
riert. Die Antworten bezüglich der unterstützenden sowie verunsichernden/ablenkenden
Punkte des Demonstrators sind in Abb.8.24 zusammengefasst. Da es sich hierbei um eine
Abb.8.21 Vis-10: Word-Cloud (CVEs)
Abb.8.22 Vis-05: Auditbewertung pro NIST-Control pro Sender
8 Evaluierung des Cyber Lagebildkonzepts im praktischen Einsatz 339
rein quantitative Auswertung der Anzahl der Nennungen je Themenbereich handelt, muss
das Resultat als grober Überschlag der Wichtigkeit, welche den einzelnen Punkten durch
Teilnehmende und Beobachtende beigemessen wurde, betrachtet werden.
Die Visualisierungen und Datenverknüpfungen welche als besonders hilfreich genannt
wurden, sind unter Punkt 8.4.2 beschrieben. Besonders hervorzuheben ist hierbei Vis-12,
die in allen Lagezentren einen zentralen Platz einnahm. Auditdaten und Sensoren als ktiv
verfügbare Datentypen zur Lagebeurteilung wurden als eher verunsichernd eingestuft. Die
Flexibilität des Tools (welche unter dem Punkt „Technik sonstiges“ läuft) wird vornehm-
lich als nützlich bewertet. Diese Flexibilität wird in erster Linie durch das Setzen von
Filtern erreicht, die in ihrer Komplexität wiederum als hinderlich erscheinen. Im Bereich
„Kommunikation“ wurden die fehlenden Meldewege von Teilnehmenden zum Teil als
störend empfunden.
Die Kommunikationswege wurden hier von den Beobachtenden in keiner Weise –
weder als Störfaktor, noch als Unterstützung – erfasst und sind deswegen in der Abbildung
nicht dargestellt. Die Visualisierungen im Demonstrator wurden aus der beobachtenden
Perspektive deutlich ablenkender bewertet als unterstützend.
Dies begründet sich zum Teil darin, dass manche Darstellungen nicht intuitiv von den
Teilnehmenden erfasst werden konnten, da beispielsweise zu viel Information in eine Visu-
alisierung verpackt oder durch die Farbgebung in manchen Visualisierungen bestimmte
Abb.8.23 Vis-21: Verteilung der von CVEs betroffenen/nicht betroffenen Unternehmen pro
Sektor
Abb.8.24 Teilnehmenden-Feedback zu unterstützenden/verunsichernden Aspekten
340 M. Kaundert et al.
Bedeutung der Daten wahrgenommen wurde. Hinsichtlich der vom Projektteam gewählten,
vorbereiteten und schließlich von den Teilnehmenden genutzten Datenverknüpfungen war
das Feedback der Beobachtenden vorsichtig positiv – es scheint hier als hätten die ange-
dachten Zusammenstellungen einen sinnvollen Ansatz zur Lagebeurteilung dargestellt.
Hinsichtlich der verwendeten Datentypen beurteilen auch die Beobachtenden die Dar-
stellung und Verwendung der Sensor- und Auditdaten als eher verunsichernd, obwohl die
Nutzung der Auditdaten auch aus Sicht der Beobachtenden nützliche Aspekte aufwies.
Der Punkt „Technik Sonstiges“ deckt inhaltlich v. a. Eigenschaften des Demonstrators
ab, die einerseits auf die Nutzung von Kibana zurückgehen und andererseits auf die Tat-
sache, dass es sich bei dem vorgestellten Tool um einen Prototyp handelt, dessen Handling
unkomfortabel ist und beispielsweise einen hohen „Scroll-Aufwand“ erfordert oder eine
Developer-Sicht ermöglicht.
Bezüglich Wünschen zum Handling und den Funktionalitäten des Demonstrators, sowie
den unterstützenden und den verunsichernden/ablenkenden Faktoren des Tools ergibt eine
quantitative Zusammenfassung der 188 Rückmeldungen (siehe Abb 8.25 und 8.26) von
Teilnehmenden und Beobachtenden. Ohne genau auf die exakte Anzahl der einzelnen
Wortmeldungen einzugehen, ist ableitbar, dass in erster Linie die Bereiche „Daten“ und
„Technik“ angemerkt wurden, was für die Zukunft eine Beschäftigung mit in erster Linie
diesen beiden Aspekten einer Lagebild-Software vorschlägt vgl. hier die Rückmeldungs-
kategorien in Tab.8.8)
8.4.4 Ergebnisse Schulungsableitungen
Die Notwendigkeit umfangreicher Trainings für zukünftige Operateure tritt stark in den
Vordergrund, besonders in Bezug auf ihren technischen Background, ihre Rolle im Lage-
zentrum und die Verwendung von Lagebeurteilungssoftware. Einige der verwendeten
Abb.8.25 Beobachtenden-Feedback zu unterstützenden/verunsichernden Aspekten
8 Evaluierung des Cyber Lagebildkonzepts im praktischen Einsatz 341
Visualisierungen waren nicht intuitiv erfassbar und konnten somit keine hilfreichen Infor-
mationen liefern. Dies ist weniger dem Tool als der geringen Einschulungsphase geschul-
det und ließe sich durch entsprechende Trainings der Operateure ändern. Es ist unwahr-
scheinlich, dass Darstellungen von komplexen Datenverknüpfungen zur Lagebeurteilung
ohne intensive Einschulung/Training nutzbar sind. Es wurde vom Tool erwartet, dass
automatisch gezeigt werden sollte, welche Information qualiziert oder für das laufende
Szenario wichtig ist. Die Rolle eines Operateurs muss beinhalten, dies selbstständig zu
erkennen, ebenso wie den Umgang mit unsicherer Information, wie z.B. die Trennung
von szenariorelevanter Information zu „Hintergrundrauschen“.
Der Schulungsbedarf erstreckt sich ebenso auf die frühzeitige Erkennung von Vorfäl-
len und Umsetzung von Lessons Learned aus früheren Fällen und Schärfung, wie diese
früheren Vorfälle sich im Lagebild abgezeichnet hätten/haben. Eine geringere Anzahl von
im Lagezentrum eingehenden Meldungen bedeuten nicht zwangsweise, dass eine Lage
weniger bedrohlich ist oder sich nicht entwickelt. Eine Sensibilisierung in Richtung Worst
Case Prognose ist nötig; auch um vorzubeugen, dass eine möglicherweise „ruhige“ Lage-
zentrum-interne Sicht automatisch nach Außen projiziert wird, anstelle der objektiven
Analyse eingehender Daten und Worst Case Prognose des Szenarios.
Bei aller Digitalisierung und automatisierter Aufbereitung von Daten hat das Planspiel
klar gezeigt, dass auch ein detailliertes Lagebild Rückfragen und Kommunikation (mit
CERT, mit kritischer Infrastruktur u. a.) nicht ersetzen kann. Die strukturierte Nutzung
eines entsprechenden (und ausfallsicheren) Kanals für Operateure ist zwingend nötig.
Wird bei Unklarheiten kein Abgleich der eigenen Interpretation und Datenaufbereitung
mit dem Sender durchgeführt, kann sich verstärktes conrmation bias (Auswahl von
Informationen, die die eigenen Erwartungen/Annahmen bestätigen) bei den Operateuren
im Lagezentrum entwickeln.
Abb.8.26 Rückmeldungen
342 M. Kaundert et al.
8.5 Zusammenfassung und Ausblick
Das Planspiel hat in erster Linie den Bedarf nach intensivem Training und klarer Rol-
lendenition einerseits für die Operateure eines Lagezentrumss, andererseits für das
Lagezentrum selbst, aufgezeigt. Der Fokus der Findings des vorliegenden Berichtes liegt
hier eindeutig auf den Ableitungen, welche für zukünftige Trainings getroffen werden
können. Eine gewisse „Ziellosigkeit“ der Teilnehmenden hinsichtlich der Lagebeurtei-
lung und Verwendung des Demonstrators lässt sich mit beschränkter Einschulungsphase
und umständlicher Handhabung des Demonstrator-Prototyps erklären. Dennoch ist eine
der Kernbeobachtungen einerseits der Wunsch nach „mehr“ Daten und mehr Information
und andererseits der Wunsch nach aggregierterer Darstellung und ausgeprägterer Inter-
pretation durch die Software. Der Bedarf nach mehr Sicherheit in der Lageeinschätzung
kommt hier zum Vorschein. Dies äußert sich dadurch, dass mehr Input (mehr Daten)
zur Beurteilung gewünscht ist. Interessanterweise führte jedoch im Planspiel das Vor-
handensein von mehr Daten in den Iterationen eins und drei nicht zu einer signikan-
ten Zunahme der Beurteilungssicherheit, was den Schluss zulässt, das in erster Linie
beim Training der Operateure des Lagezentrums anzusetzen ist: Diese müssen über klar
denierte Kompetenzen verfügen, mit Informationsunsicherheit in der Lagebeurteilung
umgehen können und benötigen, auch bei einer automatisierten Darstellung einer Situ-
ation, einen Kommunikationskanal und eine klare Kommunikationsstruktur zu CERTs
und kritischer Infrastruktur.
Eine vollautomatisierte Darstellung eines Lagebildes, in welcher das Softwaretool
selbst eine Beurteilung der Lage erstellt und ausgibt, konnte mit den vorliegenden Mitteln
nicht erreicht werden. Die menschliche Interpretation war während des Planspiels zur
Situationseinschätzung unabdingbar und konnte im Planspiel nicht vollständig durch auto-
matisierte Prozesse ersetzt werden. Wenngleich ein erhöhter Grad an Automation unter
Umständen mit anderen Softwarelösungen erreicht werden kann, stellt sich dennoch die
Frage, ob eine vollständig automatisierte Lagebilddarstellung, bei der die Maschine als
Ersatz für die Interpretation durch den Menschen dient, einerseits möglich und anderer-
seits erstrebenswert ist.
Abkürzungsverzeichnis
CERT Computer Emergency Response Team
CISA Cyber Incident Situational Awareness
CVE Common Vulnerability and Exposure
LZ Lagezentrum
TOR The Onion Router (Protokoll)
8 Evaluierung des Cyber Lagebildkonzepts im praktischen Einsatz 343
Literatur
Andrews, F. M. (1984) ‘Construct Validity and Error Components of Survey Measures: A Structural
Modeling Approach’, Public Opinion Quarterly, 48 (2): 409–42.
Anonymous (2017a) ‘Cyber-attack was about data and not money, say experts’, BBC, 29.06. Online@:
http://www.bbc.com/news/technology-40442578 (Letzter Zugriff: 21.05.2017)
Anonymous (2017b) Virus ist gefährlicher als Wanna Cry‘, Tagesanzeiger, 28.06. Online @:
https://www.tagesanzeiger.ch/ausland/europa/hacker-greifen-firmen-in-ganz-europa-an/
story/16538414 (Letzter Zugriff: 21.05.2017)
Anonymous (2017c) ‘Cyber-Attacke Petya war kein Erpressungstrojaner - sondern Schlimmeres‘,
die Presse, 26.06. Online @: https://diepresse.com/home/techscience/internet/5243277/CyberAt-
tacke-Petya-war-kein-Erpressungstrojaner-sondern-Schlimmeres (Letzter Zugriff: 21.05.2017)
Anonymous (2017d) ‚Cyberattacke: Österreichische Unternehmen betroffen‘, Kurier, 28.06. Online @:
https://kurier.at/politik/ausland/cyberattacke-oesterreichische-unternehmen-betroffen/272.263.310
(Letzter Zugriff: 21.05.2017)
Anonymous (2017e) ‚Petya verursacht Millionenschaden in Österreich‘, futurezone, 29.06. Online @:
https://futurezone.at/digital-life/petya-verursacht-millionenschaden-in-oesterreich/272.456.403
(Letzter Zugriff: 21.05.2017)
Bagozzi, R. P. (1980), Causal Models in Marketing, New York: Wiley
Boin, A., Kofman-Bos, C. und Overdijk, W. (2004) ‘Crisis Simulations: Exploring Tomorrow’s Vul-
nerabilities and Threats’, Simulation and Gaming, 35 (3): 378-393.
Bundesamt für die Sicherheit in der Informationstechnik (BSI) (2008): BSI-Standard 100-4 – Not-
fallmanagement. Bonn, Online @ https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/
Publikationen/ITGrundschutzstandards/BSI-Standard_1004.pdf?__blob=publicationFile&v=1
(Letzter Zugriff: 21.05.2017)
Bundesamt für die Sicherheit in der Informationstechnik (BSI) (2014): IT-Notfall- und Krisen-
übungen in Kritischen Infrastrukturen. Bonn: Geschäftsstelle der UP KRITIS, Online @ https://
www.kritis.bund.de/SharedDocs/Downloads/Kritis/DE/Notfall_Krisen%C3%BCbung.pdf?__
blob=publicationFile (Letzter Zugriff: 21.05.2017)
Bundesamt für Sicherheit in der Informationstechnik (BMI) (2017), Schutz Kritischer Infrastruk-
turen. Online @:https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Bro-
schueren/Schutz-Kritischer-Infrastrukturen-ITSig-u-UP-KRITIS.pdf?__blob=publicationFi-
le&v=7 (Letzter Zugriff: 02.08.2018)
Bundesministerium des Innern (BMI) (2008): Anlagen zum Konzept für Notfall und- Krisenübun-
gen in Kritischen Infrastrukturen. Umsetzungsplan Kritis, Berlin, 12/2008; Online @: http://
docplayer.org/10002239-Anlagen-zum-konzept-fuer-notfall-und-krisenuebungen-in-kritischen-
infrastrukturen.html (Letzter Zugriff: 21.05.2018)
Campbell, D. T. und Fiske, D. W. (1959) ‘Convergent and discriminant validation by the multitrait-
multimethod matrix’, Psychological Dashin, 56 (2): 81–105.
Clarke, K. (1999), Getting Started with GIS, 2nd ed., Prentice Hall Series in Geographic Information
Science, ed. Kieth Clarke. Upper Saddle River, NJ: Prentice Hall, 1999, 2–3
della Porta, D. und Keating, M. (2008) Approaches and Methodologies in the Social Sciences: A
Pluralist Perspective, Cambridge: Cambridge University Press
Dunbar, C., Rodriguez, D., und Parker, L. (2001) ‚Race, Subjectivity and the Interview Process‘ in
J. F. Gubrium und J. A. Holstein (Hg.) Handbook of Interview Research: Context and Method,
Thousand Oaks/London/New Delhi: Sage Publications:279-298
Frenkel, S, Scott M. und Mozur, P. (2017) ‘Mystery of Motive for a Ransomware Attack:
Money, Mayhem or a Message’, The New York Times, 28.06. Online @: https://www.nytimes.
344 M. Kaundert et al.
com/2017/06/28/business/ramsonware-hackers-cybersecurity-petya-impact.html (Letzter Zugriff:
21.05.2018)
Hay Newman, L. (2017) ‚Latest Ransomware Hackers Didn’t Make WannaCry’s Mistakes‘, Wired,
27.06. Online @ https://www.wired.com/story/petya-ransomware-wannacry-mistakes/(Letzter
Zugriff: 21.05.2018)
Honger, G., Heimann, R., und Kranaster, M. (2016) ‚Ausbildung und Training von Stäben‘, in
G.Honger und R. Heimann (Hg.) Handbuch Stabsarbeit: Führungs- und Krisenstäbe in Ein-
satzorganisationen, Berlin, Heidelberg: Springer: 235-241
Iaorissi, G. (2006) The Power of Survey Design, Washington: The World Bank
Krosnick, J. A. und Fabrigar, L. R. (1997) ‚Designing Rating Scales for Effective Measurement in
Surveys‘, in L. Lyberg, P. Biemer, M. Collins, E. de Leeuw, C Dippo, N. Schwarz und D. Trewin
(Hg.) Survey Measurement and Process Quality, New York: John Wiley: 141-164
Krosnick, J. A., Narayan, S., und Smith, W. R. (1996) ‚Satiscing in surveys: Initial evidence’, in
M.T. Braverman und J. K. Slater (Hg.), Advances in survey research, San Francisco: Sage: 29-44
Likert, R. (1932) A Technique for the Measurement of Attitudes, New York: Columbia University
Press
Madden, T. M., und Klopfer. F. J. (1978) ‚The “cannot decide” option in Thurstone-typic attitude
scales’, Educational and Psychological Measurement, 38: 259-264.
Mayring, P. (2000) ‚Qualitative Content Analysis‘, Forum: Qualitative Social Research, 1 (2):
Art. 20. Online @: http://nbnresolving.de/urn:nbn:de:0114-fqs0002204, letzter Zugriff am
08.02.2018
Murdoch, B. B. (1962) ‘The serial position effect of free recall’, Journal of Experimental Psycho-
logy, 64 (5): 482-488. Online @: https://pdfs.semanticscholar.org/f518/20619ca42c5799f3c5acc
3855671b905419c.pdf (Letzter Zugriff: 21.05.2018)
North Atlantic Treaty Organisation (NATO) (2013) 75-3 Collective Training and Exercise Direc-
tive. 10/2013; Online @: http://www.act.nato.int/images/stories/structure/jft/bi-sc-75-3_nal.
pdf (Letzter Zugriff: 21.05.2018)
National Institute of Standards and Technology (2013) ‘Security and Privacy Controls for Federal
Information Systems and Organizations’, NIST Special Publication 800-53, Revision 4.
Online@: http://dx.doi.org/10.6028/NIST.SP.800-53r4 (Letzter Zugriff: 21.05.2018)
Peter, J. P. (1981) ‚Construct Validity: A Review of Basic Issues and Marketing Practices‘, Journal
of Marketing Research, 28: 133-145.
Thurstone, L. L., und Chave, E. J. (1929) The Measurement of Attitudes, Chicago: University of
Chicago Press
