Mathematik Und Informatik

Hans-Richard Kraft
Systematische Analyse- und

Beurteilungsmethodik für die
IT-Sicherheit prozessführender
Computersysteme in operativen
Industrieumgebungen
Mathematik
und
Informatik
Dissertation
deposit_hagen
Publikationsserver der
Universitätsbibliothek
Systematische Analyse- und
Beurteilungsmethodik für die IT-Sicherheit
prozessführender Computersysteme in
operativen Industrieumgebungen
Dissertation
zur Erlangung des Grades eines

Doktors der Naturwissenschaften (Dr. rer. nat.)
der Fakultät Mathematik und Informatik

der FernUniversität in Hagen
vorgelegt von
Hans-Richard Kraft
Juni 2016
FernUniversität Hagen
Gutachterin und Gutachter:
Prof. Dr. Ulrike Baumöl
Prof. Dr. Jörg Keller
Tag der mündlichen Prüfung:
16. November 2016
Seite 1 von 262

Zusammenfassung
2010 erweiterte das Kunstwort „Stuxnet“ die Diskussion um Computersicherheit auf eine
bislang nur Fachleuten vertraute Geräte- und Systemklasse: Leit- und
Automatisierungssysteme für Produktionsanlagen und kritische Infrastrukturen. Eine Vielzahl
von Veröffentlichungen führte vor allem den hochentwickelten Industriegesellschaften ihre
Abhängigkeit von der korrekten Funktion dieser Systeme vor Augen.
Im Kontext der Stuxnet-Analysen ergriffen Lieferanten Maßnahmen zur Verbesserung der IT-
Sicherheit ihrer Systeme bzw. Komponenten während Betreiber ihre Anlagen auf
entsprechende Schwachstellen untersuchten.
Die Entwicklung geeigneter Maßnahmen zur Verbesserung der IT-Sicherheit der Leit- und
Automatisierungssysteme verdeutlichte, dass nicht nur anlagentypischen Randbedingungen,
wie z.B. sehr lange Einsatzzeiten (20+ Jahre), z.T. unzureichende Hardware-Ressourcen
oder hohe Kosten im Falle von Anlagenstillständen, Herausforderungen darstellen, sondern
auch eine Methode zur systematische Beurteilung der IT-Sicherheit dieser Systeme fehlte.
Mangels Alternativen dienen deshalb in der Regel Analyseansätze zur Beurteilung des
Risikos von Cyberangriffen anstelle der IT-Sicherheit von Anlagen. Wesentliche
Schwachstellen dieser Herangehensweise sind fehlende Ereignisdaten zur Abschätzung von
Eintrittswahrscheinlichkeiten, mangelnde Aussagekraft der Ergebnisse sowie der nicht
quantifizierbare Einfluss subjektiver Einschätzungen des Prüfpersonals.
Zwecks Vermeidung der genannten Schwächen beschreibt die vorliegende Arbeit eine
automatisierbare Analysemethodik auf Basis generischer Angriffsszenarien gegen die zu
betrachtende Zielanlage. Mit Hilfe einer neuartigen Sicherheitsmetrik, die subjektive
Einschätzungen des Prüfpersonals durch sicherheitsrelevante Anlageneigenschaften ersetzt,
resultieren reproduzierbare Ergebnisse für die Beurteilung der IT-Sicherheit von Leit- und
Automatisierungssystemen
Zum Zweck der Erprobung der vorgeschlagenen Methode findet die vorgeschlagene
Analysemethodik Anwendung auf eine praxisnahe Beispielanlage. Die Analyseergebnisse
werden auf die neuentworfene Sicherheitsmetrik abgebildet. Den Abschluss bildet ein
Vergleich der Ergebnisse dieser Vorgehensweise mit den Ergebnissen einer risikobasierten
Methode auf Basis eines entsprechenden Standards.
Seite 2 von 262

Abstract
In 2010 “Stuxnet” widened the discussion regarding computer security on a class of device
previously known to experts only: automation and control systems in production
environments and critical infrastructures. Numerous publications highlighted the modern
societies’ dependence on the correct function of these systems.
In the context of the Stuxnet-related investigations and publications, vendors applied bug
fixes and countermeasures and plant operators scanned their systems on vulnerabilities.
The development of countermeasures in order to improve the cyber security of automation

and control systems raised domain-specific constraints, e.g very long periods of system
utilization (20+ years), limited hardware resources or significant commercial costs for plant
outages. In addition, there is no systematic approach to cyber security assessments of these
systems.
In the absence of alternatives, assessment approaches address the risk of cyber security
issues rather than the plant security. The risk-based approach lacks the availability of
statistically valid incident data for the estimation of event probabilities, the limited value of the
assessment results and the not quantifiable influence of individual ratings.
In order to avoid these weaknesses, this document describes a semi-automatized

assessment approach based on generic attack scenarios against the target plant. For the
purpose of the cyber security evaluation of automation and control systems, this document
describes a new metric which replaces individual ratings of the assessment staff by security-
related plant security properties.
For the validation purpose, the proposed assessment approach has been applied to a close-
to-practice plant sample. The assessment results are mapped on the new security metric.
Finally, the results of this assessment are compared with the results of a risk-oriented
assessment to the same plant based on a common assessment standard.
Seite 3 von 262

Inhalt
1 Einleitung ....................................................................................................................... 8
1.1 Einführung ............................................................................................................... 8
1.2 Ausgangssituation und Motivation ........................................................................... 9
1.3 Zielsetzung .............................................................................................................11
1.4 Vorgehensweise .....................................................................................................13
1.5 Gliederung .............................................................................................................14
2 Grundlegende Aspekte der Leit- und Automatisierungssysteme....................................17
2.1 Übersicht Leittechniksysteme .................................................................................17
2.2 Technologietrends ..................................................................................................22
2.3 Unterschiede zwischen Leittechnik- und IT-Systemen............................................25
2.3.1 Schutzziele von IT-Systemen ..........................................................................25
2.3.2 Schutzziele von SCADA-Systemen .................................................................25
2.3.3 Echtzeitanforderungen ....................................................................................27
2.3.4 Betriebliche Aspekte........................................................................................27
3 IT-Sicherheit von Leit- und Automatisierungssystemen .................................................31
3.1 Überblick ................................................................................................................31
3.2 Begriffe und Abgrenzungen ....................................................................................31
3.2.1 Funktionale Sicherheit .....................................................................................31
3.2.2 IT-Sicherheit ....................................................................................................32
3.2.3 Schutzziele: Abgrenzung und Anforderungen an die Systeme ........................34
3.3 Überlegungen zur Beurteilung von IT-Sicherheit ....................................................34
3.4 Bedrohungen von Leit- und Automatisierungssystemen .........................................36
3.5 IT-Sicherheit als Systemeigenschaft ......................................................................41
3.6 Extrakt der weiterführenden Ergebnisse .................................................................43
4 Ansätze zur Beurteilung der IT-Sicherheit von Leit- und Automatisierungssystemen.....46
4.1 Motivation ...............................................................................................................46
Seite 4 von 262

4.2 Überblick typischer Analysemethoden ....................................................................48
4.2.1 Allgemeine Anmerkungen ...............................................................................48
4.2.2 Ansätze zur Beurteilung der IT-Sicherheit .......................................................49
4.2.3 IT-Security-Metriken für SCADA-Systeme .......................................................51
4.2.4 Risikoanalysen für SCADA-Systeme ...............................................................54
4.3 Kritik der Konzepte und Vorgehensweisen .............................................................61
4.4 Kriterien eines praxisgerechten Beurteilungsansatzes ...........................................62
4.5 Extrakt der weiterführenden Ergebnisse .................................................................63
5 Vorschlag eines neuen Analysemodells für SCADA-Systeme .......................................65
5.1 Beurteilungsansatz für IT-Sicherheit .......................................................................65
5.2 Beurteilung der Angriffsvoraussetzungen ...............................................................68
5.3 Herleitung von Angriffsszenarien ............................................................................72
5.3.1 Allgemeines ....................................................................................................72
5.3.2 Leittechnikmodell zur Herleitung generischer Angriffsszenarien ......................73
5.3.3 Herleitung generischer Angriffsszenarien mittels Attack Tree-Graphen ...........80
5.4 Formale Betrachtung des Analyseprozesses..........................................................91
5.4.1 Formale Methoden des Analyseprozesses ......................................................91
5.4.2 Verlauf des Analyseprozesses ........................................................................94
5.4.3 Beschreibung der Angriffsszenarien ................................................................96
5.4.4 Beschreibung der leittechnischen Anlage ......................................................100
5.4.5 Abbildung der Angriffsszenarien auf die Zielanlage .......................................104
5.4.6 Herleitung der Voraussetzungen für kritische Angriffsszenarien ....................108
5.5 Extrakt der weiterführenden Ergebnisse ...............................................................110
6 Konzept einer Leittechnik-IT-Sicherheitsmetrik ............................................................112
6.1 IT-Sicherheitsmetrik – Wozu? ..............................................................................112
6.2 Begrifflichkeiten ....................................................................................................113
6.3 Kritik der vorgestellten IT-Sicherheit-Metriken ......................................................115
6.3.1 Allgemeine Betrachtung ................................................................................115
6.3.2 Ansätze für IT-Sicherheitsmetriken................................................................116
Seite 5 von 262

6.3.3 Schlussfolgerungen zu Metriken ...................................................................118
6.4 IT-Sicherheitsmetrik: Randbedingungen für Leittechniksysteme...........................126
6.4.1 Allgemeines ..................................................................................................126
6.4.2 Wesentliche Randbedingungen .....................................................................127
6.5 Vorschlag einer leittechnikspezifischen Sicherheitsmetrik ....................................132
6.5.1 Statische Metrikinhalte ..................................................................................133
6.5.2 Dynamische Metrikinhalte .............................................................................144
6.5.3 Auswirkung geänderter Randbedingungen auf resultierende Metrik ..............145
6.5.4 Interpretation der vorgeschlagenen Sicherheitsmetrik ...................................152
6.6 Extrakt der weiterführenden Ergebnisse ...............................................................153
7 Werkzeugbasierte Durchführung der Analyse .............................................................156
7.1 Automatisierte Analyseverfahren ..........................................................................157
7.1.1 Beurteilungsrahmen der Analysemethoden ...................................................157
7.1.2 Automatisierbare Analyseverfahren...............................................................158
7.1.3 Zusammenfassung und Bewertung der Analysemethoden ............................161
7.2 Technische Umsetzung des Analyseschemas......................................................162
7.3 Datentechnische Realisierung ..............................................................................168
7.4 Ausführen der Anlagenanalyse ............................................................................168
7.5 Bildung der Sicherheitsmetrik ...............................................................................170
7.5.1 Import der PROLOG-Ergebnisse ...................................................................170
7.5.2 Abbildung der Analyseergebnisse auf Teil-Metriken ......................................171
7.5.3 Übersicht Anlagen-Metrik ..............................................................................176
8 Anwendung der Analysemethodik auf ein Praxisbeispiel .............................................179
8.1 Schematische Darstellung einer Beispielanlage ...................................................179
8.2 Anwendung von Analysemethoden auf die Beispielanlage ...................................181
8.2.1 Anlagenvalidierung gemäß etabliertem Standard ..........................................182
8.2.2 Beispielhafte Anlagenbeurteilung auf Basis des Standards ...........................202
8.2.3 Anwendung der vorgeschlagenen Analysemethodik auf die Beispielanlage ..213
8.3 Ergebnisvergleich der angewandten Analysemethoden .......................................221
Seite 6 von 262

8.3.1 Ergebnisse der Standard-basierten Analyse .................................................221
8.3.2 Ergebnisse der vorgeschlagenen Szenario-basierten Analysemethode ........223
8.3.3 Gegenüberstellung und Vergleich der Analyseergebnisse ............................223
9 Zusammenfassung und Ausblick .................................................................................226
10 Verzeichnisse ..........................................................................................................235
10.1 Literaturverzeichnis ..............................................................................................235
10.2 Abbildungsverzeichnis ..........................................................................................240
10.3 Abkürzungsverzeichnis ........................................................................................242
11 Anhang ....................................................................................................................243
Seite 7 von 262

Kapitel 1 Einleitung
1 Einleitung
1.1 Einführung
Im Verlauf des Jahres 2010 brachte es ein Kunstwort zu globaler Medienpräsenz: Stuxnet.
Die Berichterstattung in Internet, Zeitungen und Zeitschriften, TV-Nachrichten und TV-
Talkshows verdeutlichten den Medienkonsumenten, dass nicht nur die PCs von
Privatanwendern oder die Intranets von Unternehmen, Verwaltungen und Regierungen
Angriffen mittels Schadsoftware ausgesetzt sind. Offensichtlich sind auch jene Systeme
Bedrohungen ausgesetzt, die das Funktionieren zentraler Infrastruktureinrichtungen
sicherstellen sollen. Unter dem anhaltenden Medienecho, das nicht auf militärische Begriffe
verzichtete (u.a. „Digitaler Erstschlag ist erfolgt“, (Rieger, 2010)) nahm eine erstaunte
Öffentlichkeit zur Kenntnis, was Kenner der Materie nicht überraschte: Computersysteme mit
bekannten und unbekannten Schwachstellen steuern Kraftwerke und Stromnetze,
Wasserversorgung und Abwasserentsorgung, Gas- und Ölpipelines, Verkehrssysteme
(Ampelanlagen, Eisenbahn- und Flugsicherheitssysteme) und andere für moderne
Gesellschaften wichtige Systeme. Erschwerend kommt hinzu, dass leider nicht nur die
Systeme der gesellschaftlichen Daseinsvorsorge („Kritische Infrastruktur“) von Angriffen
dieser Art betroffen sind, sondern auch industrielle Fertigungsanlagen, private
Heizungssteuerungen - und Kirchenglocken.
Spätestens mit Bekanntwerden der durchschlagenden Wirkung der Schadsoftware „Stuxnet“

im Laufe des Jahres 2010 rückten leittechnische Anlagen ins Bewusstsein der medial
erreichbaren Öffentlichkeit. Die Berichterstattung im Internet, in den Printmedien sowie durch
Funk & Fernsehen beseitigte letzte Zweifel nicht nur bei den Medienkonsumenten sondern
auch in den Unternehmen der betroffenen Branchen und deren Systemlieferanten: moderne
Gesellschaften sind abhängig von der korrekten Funktion dieser Art von Systemen und diese
Systeme sind bislang unbekannten Bedrohungen ausgesetzt.
Bei Betreibern und Lieferanten geriet die Frage nach der IT-Sicherheit der eigenen
Leittechnik- und Automatisierungssysteme an prominente Stelle der Tagesordnungen. Allein,
die verfügbaren Analysemethoden liefern unbefriedigende Antworten: Ergebnisse basieren
auf vagen Einschätzungen hinsichtlich der Systemsicherheit, subjektiven Beurteilungen und
statistischen Daten zweifelhafter Eignung. Darüber hinaus sind einige Analysemethoden für
Betreiber nicht anwendbar, da die für jene Analysen notwendigen Informationen nicht
vorliegen (closed source-Systeme).
Seite 8 von 262

1.2 Ausgangssituation und Motivation
Die Veröffentlichungen im Nachgang zu „Stuxnet“ hatten unterschiedliche Konsequenzen zur

Folge:
 Hersteller von Leit- und Automatisierungssystemen ergriffen Maßnahmen zur

Verbesserung ihrer Softwarequalität und Serviceangebote („Patch management“).
 Lieferanten von Virenschutzprogrammen und Whitelisting-Lösungen wiesen in ihren

Marketing-Kompagnien darauf hin, dass ihre Produkte „Stuxnet“ erkannt bzw.
verhindert hätten.
 Betreiber von kritischen Infrastrukturen veranlassten Sicherheitsanalysen für ihre

Anlagen.
 IT- und Unternehmensberater erkannten Leit- und Automatisierungssysteme als

zusätzliches Betätigungsfeld.
 Politik- und Militärberater brachten sich mit Kriegsszenarien („Cyber war“) ins
Gespräch.
 Standardisierungsinstitute veröffentlichen bzw. ergänzten Empfehlungen und

Standards zur IT-Sicherheit für Leit- und Automatisierungssysteme im Allgemeinen
sowie mit besonderem Fokus auf kritische Infrastrukturen.
 In den Medien ließen sich mit der Darstellung und Diskussion ausgefeilter
Bedrohungsszenarien, die vielfach an den 70-Jahre Spielfilm „War games“ angelehnt
waren, Einschalt- und Klickzahlen steigern.
Anmerkung: Als „kritische Infrastruktur“ werden lt. Bundesamt für Sicherheit in der Informationstechnik, BSI,
„Organisationen und Einrichtungen mit wichtiger Bedeutung für das staatliche Gemeinwesen, bei deren
Ausfall oder Beeinträchtigung nachhaltig wirkende Versorgungsengpässe, erhebliche Störungen der
öffentlichen Sicherheit oder andere dramatische Folgen einträten“. In Deutschland werden Sektoren u.a.
Transport und Verkehr, Energie, Ernährung, Wasser, Gesundheit den Kritischen Infrastrukturen
zugeordnet (BSI).
Ungeachtet des entstandenen Medien- und Marketing-Hypes offenbarten sich bei

eingehender Betrachtung erforderlicher Maßnahmen einige technische Probleme, für die es
keine einfachen Lösungen zu geben scheint:
 Die lange Nutzungsdauer von 10 bis 20 Jahren (teilweise sogar noch länger) der Leit-
und Automatisierungssysteme in Produktionsanlagen, wie z.B. Kraftwerken, hat zur
Folge, dass die Anlagenbetreiber nach einiger Zeit für diese veralteten und
Seite 9 von 262

abgekündigten Betriebssysteme und Anwendungen keine Software-Aktualisierungen

mehr erhalten.
 Die Aktualisierung der Systeme mittels Software Patches – insbesondere der

Betriebssysteme – kann den Neustart der betreffenden Systeme erfordern. Der damit
einhergehende temporäre Kontrollverlust des Bedienpersonals über die
Gesamtanlage erzwingt in der Regel das Abschalten eines Teils der Anlage oder
sogar eine Komplettabschaltung.
 Die Rechenleistung der Systeme sowie die vorhandenen Hardware-Ressourcen (z.B.

verfügbarer Hauptspeicher) erlauben keine Installation zusätzlicher Schutzsoftware,
wie z.B. Virenschutzlösungen.
 Für proprietäre Betriebssysteme sind keine Schutzprogramme am Markt verfügbar

(Virenschutz, Whitelisting etc.).
 Signatur-basierte Schutzprogramme sind gegen unbekannte Schadsoftware („Zero-

Day-Exploits“) und maßgeschneiderte Angriffe mittels individueller Schadsoftware
(„micro distribution“) wirkungslos.
 Da die Ablaufprogramme der Automatisierungssysteme für jede Anlage individuell

entworfen werden müssen, liefern die heuristischen Methoden der
Virenschutzhersteller keine Signaturen für Schadcode der Automatisierungssysteme.
Systeme und Komponenten sowie Methoden zum Schutz von IT-Systemen sind bei
Bekanntwerden von „Stuxnet“, d.h. im Jahre 2010, an die Erfordernisse dieser Systeme im
Unternehmens- und Privatumgebungen ausgerichtet. Die besonderen Anforderungen von
Produktionsumgebungen insbesondere im Bereich der „kritischen Infrastruktur“ (siehe oben)
finden keine Berücksichtigung. Hinsichtlich der Angriffsziele unterscheiden sich
Angriffsszenarien gegen Leit- und Automatisierungssysteme grundsätzlich von Angriffen
gegen IT-Systeme wie z.B. E-Mail-Server, Datenbanken, Web Server sowie Dateisystemen
von Server oder PCs etc.: bei Angriffsvarianten gegen typische IT-Landschaften stellen diese
IT-Systeme das primäre Angriffsziel dar, um an Informationen dieser Systeme zu gelangen
oder Dienste dieser Systeme zu beeinträchtigen. Im Gegensatz dazu stellen die Leit- und
Automatisierungssysteme in der Regel nicht das eigentliche Angriffsziel dar: Angriffe gegen
die Steuerungssysteme von kritischen Infrastrukturen oder Produktions- und
Fertigungsanlagen zielen auf den physischen bzw. den verfahrenstechnischen Prozess, den
die Leit- und Automatisierungssysteme steuern und kontrollieren. Über die Beeinflussung
des physischen Prozesses soll realer Schaden für Personen, Anlagen oder Umwelt
Seite 10 von 262

entstehen bzw. angedroht werden. Die Leit- und Automatisierungssysteme dienen hierbei als
Mittel zum Zweck.
Die nachhaltige Verbesserung des Schutzes vor Cyber-Angriffen der Leit- und
Automatisierungssystemen insbesondere in kritischen Infrastrukturen muss die IT-Sicherheit
dieser Systeme einer systematischen Analyse und Zustandsbewertung zugänglich machen –
unter Berücksichtigung der anlagentypischen Besonderheiten sowie der jeweils verfügbaren
Informationen für Hersteller und Betreiber.
1.3 Zielsetzung
In der vorliegenden Arbeit soll nun der Frage nachgegangen werden, wie angesichts dieser
Randbedingungen Betreiber von Leit- und Automatisierungsanlagen ihre Systeme
analysieren und Optionen zur Verbesserung der IT-Sicherheit ableiten können. Vor eine
vergleichbare Herausforderung wie Betreiber sehen sich die Lieferanten von Leitsystemen
gestellt, die ihre Systeme vor der Auslieferung an die Kunden anlagenspezifisch
konfigurieren müssen: Auswahl und Art der gelieferten Systeme und Komponenten, die
Vernetzung der Systeme untereinander sowie die Ausprägung der verfahrenstechnischen
Prozesslogik beeinflussen die IT-Sicherheit der leittechnischen Gesamtanlage.
Für die betriebliche Praxis stellen sich hinsichtlich der Beurteilung der IT-Sicherheit von
SCADA-Systemen (Supervisory Control and Data Acquisition) im Wesentlichen zwei Fragen:
 Was versteht man unter der „Sicherheit“ von Leit- und Automatisierungssystemen?
 Wie soll die IT-Sicherheit von SCADA-Systemen analysiert werden?
Bei Durchsicht der Literatur stößt man auf das Problem, dass sich die „Sicherheit“ eines
Systems durch keine Variable direkt abbilden lässt. Aus diesem Mangel heraus greifen viele
Analysemethoden auf die Ersatzgröße „Risiko“ (eines erfolgreichen Angriffs) zurück. Es ist
naheliegend, dass die Beurteilung des Risikos von Angriffen gegen Computersysteme weder
eine Aussage über die inhärente Sicherheit des Zielsystems darstellt, noch eine
Analysemethode ergibt, die diesem Ziel dient. Ganz im Sinne der Erkenntnis Christian
Morgensterns: „Wer das Ziel nicht kennt, kann den Weg nicht finden!“
Dies führt zur ersten Forschungsfrage, die im Rahmen der vorliegenden Arbeit einer
beantwortet werden soll:
 Gibt es Metriken, die den Sicherheitsstatus von Leitsystemen im Kontext betrieblicher

Anwendung hinreichend beschreiben?
Seite 11 von 262

Falls diese Frage nicht zufriedenstellend beantwortet werden kann, soll die Ausgangsfrage
folgendermaßen erweitert werden:
 Welchen Kriterien müssen Metriken zur Beschreibung der IT-Sicherheit von

Leitsystemen genügen?
 Lässt sich aus diesen Kriterien das Konzept einer solchen Metrik herleiten?
Die Analyseansätze, die auf IT-Systeme angewandt werden und denen eine
Risikobetrachtung zugrunde liegt, offenbaren eine Reihe von Defiziten: Die subjektiven
Risikoeinschätzungen von Angriffen führen zu Ergebnissen, die nicht nur vom betrachteten
Zielsystem sondern auch vom Analysepersonal abhängen: typischerweise tendieren
erfahrene IT-Sicherheitsexperten dazu, Angriffe aufgrund eigener Kenntnisse als „einfach“ zu
klassifizieren, während weniger qualifizierte Analysten die gleichen Angriffsszenarien eher
als „schwierig“ einschätzen. Außerdem ist zu berücksichtigen, dass Risikoaussagen über
allgemeine Bedrohungslagen oder vermutete Fähigkeiten unbekannter Angreifer
grundsätzlich keine Aussage über das betrachtete System darstellen. Risikoeinschätzungen
können nicht als Aussagen hinsichtlich der Systemeigenschaft „Sicherheit“ aufgefasst
werden.
Für die vorliegende Arbeit ergibt sich damit eine weitere Forschungsfrage:
 Wie lassen sich Leit- und Automatisierungssysteme analysieren, um die für eine
geeignete Metrik notwendigen Daten zu erhalten und eine Aussage hinsichtlich der
Systemsicherheit bilden zu können.
Im Gegensatz zu den in der Literatur beschriebenen risikobasierten Analysemethoden und

Sicherheitsmetriken soll der in dieser Arbeit vorgestellte Ansatz eine Analysesystematik für
Leit- und Automatisierungssysteme im betrieblichen Kontext bereitstellen und den Status der
IT-Sicherheit reproduzierbar und nachvollziehbar in einer Metrik abbilden. Zielsetzung ist,
erstmals eine Aussage hinsichtlich der IT-Sicherheit für leittechnische Systeme zu
formulieren, die ausschließlich auf anlageninhärenten Fakten basiert.
Seite 12 von 262

1.4 Vorgehensweise
Die Frage nach der Analysemethode der IT-Sicherheit für leittechnische Anlagen beinhaltet
neben der notwendigen Systematik auch die Aspekte eines automatisierbaren
Analyseablaufes sowie die Erzielung reproduzierbarer und nachvollziehbarer Ergebnisse.
Die in dieser Arbeit vorgestellte Systematik zur Beurteilung der IT-Sicherheit von
leittechnischen Systemen adressiert beide Aspekte.
Zunächst ist die Frage zu beantworten, welche Angriffe gegen die Zielanlage - aus Sicht des
Analysten - möglich sind. Ausgehend von einem Bedrohungsmodell, bestehend aus den
Elementen Angreifer, Zielsystem und Angriffspfad, wird zu zeigen sein, dass dem
Leittechnikbetreiber keine belastbaren Informationen hinsichtlich potentieller Angreifer sowie
der Gesamtzahl der Systemschwachstellen seines Leitsystems vorliegen. Mangels
ausreichender Informationen hinsichtlich der systemimmanenten Exploit-Möglichkeiten
aufgrund der unbekannten Softwarefehler muss sich die Analysemethode auf die physischen
und logischen Angriffspfade gegen die Zielsysteme fokussieren. Im Gegensatz zu den
Aspekten ‚Angreifer‘ bzw. ‚Systemschwachstellen‘ verfügt der Betreiber über umfassende
Kenntnisse hinsichtlich der Angriffspfade gegen seine Anlage.
Die automatisierte Analysemethodik bildet die Beschreibung generischer Angriffsszenarien

auf die Beschreibung der Zielanlage ab. Die Umsetzung mit Mitteln der logischen
Programmierung resultiert aus der Überlegung, dass z.B. PROLOG-Systeme dieses
Matching der Angriffsszenarien auf die Anlagenbeschreibung als Systemfunktion
bereitstellen.
Diese automatisierte Analyse liefert die gegen die Zielanlage realisierbaren

Angriffsszenarien. Aus der Beschreibung dieser Angriffsszenarien leiten sich auch jene
Voraussetzungen ab, die Angreifer für erfolgreiche Angriffe zu erfüllen haben.
Im zweiten Teil des vorgeschlagenen Analyseansatzes steht die Frage im Mittelpunkt,

welche messbaren Faktoren die IT-Sicherheit einer leittechnischen Anlage beschreiben. Zu
diesem Zweck wird eine IT-Sicherheitsmetrik vorgeschlagen, deren Elemente aus
ausschließlich sicherheitsrelevanten Größen bestehen: die Anzahl möglicher
Angriffsszenarien („Sicherheitsniveau“), systembedingte Anzahl der möglichen
Angriffsvarianten („SCADA-Angriffsoberfläche“), die besonders gefährdeten
Systemkomponenten („Kritische Angriffspunkte“), die Risikobewertung des Betreibers der
Angriffsszenarien („Kritikalität der Angriffsmuster“) sowie der Anteil der potentiellen
Angriffsszenarien, die den Risikoanforderungen des Betreibers nicht genügen („relative
Kritikalität“).
Seite 13 von 262

Die vorliegende Arbeit stellt den typischen Analysemethoden, die auf empirischen Daten
undefinierter Unsicherheit und in der Regel ohne Bezug auf die betrachtete Zielanlage
beruhen, einen alternativen Ansatz gegenüber: die vorgeschlagene Systematik mündet auf
formalisierter Weise in eine Sicherheitsmetrik, die generische Angriffsszenarien auf die
Eigenschaften der betrachteten Zielanlage abbildet. Während risikobasierte
Analysemethoden den Versuch unternehmen, die Wahrscheinlichkeit eines „Schwarzen
Schwans“ (Taleb, 2012) zu bestimmen (d.h. das erstmalige Eintreten eines unbekannten
Sicherheitsereignisses), beschreibt die hier vorgeschlagene Methodik einen resultierenden
Sicherheitsstatus in Form einer reproduzierbaren Aussage, die zielsystemimmanente
Eigenschaften berücksichtigt und einen transparenten Algorithmus anwendet.
1.5 Gliederung
Ausgehend von der Diskussion einiger Begriffe und Technologietrends im Bereich der
prozessführenden Computersysteme für operative Industrieumgebungen in Kapitel 2 sollen
anschließend grundsätzliche Fragen zur IT-Sicherheit dieser Klasse von Computersystemen
betrachtet werden (Kapitel 3). Den Schwerpunkt bilden die Besonderheiten dieser
Systemklasse sowie die Unterschiede gegenüber „typischen“ IT-Systemen und beleuchten
die sich daraus ergebenden Konsequenzen für deren IT-Sicherheit. Ausgehend von diesen
Überlegungen wird ein Bedrohungsmodell hergeleitet, das als Grundlage für eine neue
Analysemethode für Leittechniksysteme dienen soll: eine auf Fakten basierende Methode mit
reproduzierbaren Analyseergebnissen.
Nach der Behandlung dieser grundlegenden Aspekte der IT-Sicherheit von Leit- und
Automatisierungssystemen soll der Frage nachgegangen werden, wie Hersteller und/oder
Betreiber solcher Anlagen die IT-Sicherheit beurteilen und geeignete Maßnahmen zu deren
Verbesserung finden können. Kapitel 4 wirft dazu einen Blick auf die typischen
Analysemethoden, die zur Beurteilung der IT-Sicherheit herangezogen werden können
einschließlich einer Kritik dieser Methoden hinsichtlich der Anwendung auf die diskutierte
Systemklasse.
In Kapitel 5 folgt die Beschreibung einer Analysemethode, die sowohl den Besonderheiten
von Leit- und Automatisierungssystemen genügt als auch die Möglichkeiten von Herstellern
und Betreibern berücksichtigt, solche Analysen faktenbasiert durchzuführen. Kern der
Überlegung ist, wie sich eine Aussage zur Sicherheit eines SCADA-Systems intrinsisch
herleiten lässt. Besondere Bedeutung kommt dabei der Frage nach dem „Exploit-Pfad“ zu,
d.h. der Art und Weise, wie ein Angriff gegen ein Zielsystem überhaupt ausgeführt werden
Seite 14 von 262

kann. Des Weiteren wird angestrebt, Analyseergebnisse weitestgehend frei von subjektiven
Einschätzungen des Analyseteams zu bilden. Die Vermeidung subjektiver Einflüsse ist die
Voraussetzung dafür, dass die Analyseergebnisse die Eigenschaften des Leitsystems
widerspiegeln und nicht die spekulativen Vermutungen der Analysten. Besonderen Nutzen
entfalten diese Analysen, wenn sie in regelmäßigen Abständen wiederholt werden, um
Änderungen an den Systemen sowie veränderte Bedrohungsszenarien zu berücksichtigen.
Vor diesem Hintergrund sind sowohl die Frage des Analyseaufwandes als auch die damit
verknüpfte Automatisierbarkeit des Verfahrens zu diskutieren.
Kapitel 6 rückt die Fragen nach Inhalt und Form der Analyseergebnisse in den Mittelpunkt.
Gerade wiederholt durchgeführte Analysen derselben Anlage sollen vergleichbare
Ergebnisse liefern. Für den operativen Geschäftsbetrieb hat sich die Einbindung solcher
Analyseergebnisse mittels geeigneter Metriken bewährt. Zu diesem Zweck untersucht das
Kapitel 6 Metriken, die in der Praxis zur Beurteilung der IT-Sicherheit von
Computersystemen herangezogen werden, auf deren Brauchbarkeit für Leit- und
Automatisierungssysteme. Auf Basis dieser Kritik wird eine Metrik vorgeschlagen, die auf die
Beurteilung der IT-Sicherheit von Leit- und Automatisierungssystemen zugeschnitten ist.
Kern dieses Kapitels ist somit auch die Antwort auf die Frage nach der Sicherheit eines
Systems.
Ausgehend von konzeptionellen Überlegungen der vorangegangenen Kapitel zu

Analysemethode und Metrikkonzept folgt in Kapitel 7 die Darstellung der werkzeuggestützten
Umsetzung der skizzierten Überlegungen. Hierzu gehören das automatisierbare
Analyseverfahren, die technische Umsetzung des Analyseschemas, die datentechnische
Realisierung sowie die abschließende Generierung der Sicherheitsmetrik.
Nachdem das vorangegangene Kapitel sowohl die neue Analysemethodik als auch eine für
SCADA-Systeme angemessene Metrik zur Beurteilung der IT-Sicherheit beschrieben hat,
sollen in Kapitel 8 die vorgeschlagene Methodik und Metrik einem Praxistest unterzogen
werden: die Beurteilung der Sicherheitsrisiken einer Beispielanlage anhand der in dieser
Arbeit vorgeschlagenen Methode wird eine Analyse auf Basis eines etablierten Standards
gegenübergestellt. Anschließend werden die Vorteile der neuen IT-Sicherheitsmetrik anhand
der Beispielanlage skizziert.
Das abschließende Kapitel 9 fasst die Überlegungen und Schlussfolgerungen der

vorliegenden Arbeit zusammen und skizziert die Anwendung der vorgeschlagenen Methode
sowie des neuen Metrik-Konzepts zum Zwecke der Verbesserung der IT-Sicherheit für Leit-
Seite 15 von 262

und Automatisierungsanlagen. Ein Ausblick auf weiterführende Arbeiten zur Steigerung des
Automatisierungsgrades der Analysen rundet das Kapitel ab.
Aspekte der vorliegenden Arbeit wurden 2015 in (Kraft, 2015) veröffentlicht.
Seite 16 von 262

Kapitel 2 Grundlegende Aspekte der Leit- und Automatisierungssysteme
2 Grundlegende Aspekte der Leit- und Automatisierungssysteme
2.1 Übersicht Leittechniksysteme
Leittechnikanlagen zur Führung verfahrenstechnischer Prozesse lassen sich in mehrere

hierarchische Ebenen gliedern (siehe auch Abbildung 1):
Abbildung 1: Typische Funktionsebenen einer Leittechnikanlage
Anmerkung: Für leittechnische Systeme hat sich über den englischen Sprachraum hinaus
auch der Begriff „Supervisory Control and Data Acquisition system“ (SCADA system)
etabliert.
Während Abbildung 1 die Bestandteile einer Leittechnikanlage in generischer Form der

sogenannten „Leittechnikpyramide“ darstellt, zeigt Abbildung 2 ein typisches Schema einer
realen Leittechnikanlage. Die konkrete Ausprägung solcher Systeme wird natürlich auch von
Seite 17 von 262

den verschiedenen Herstellern geprägt und ist vom Entwicklungszeitraum des Systems
beeinflusst.
Aktoren / Sensoren
Die unterste Ebene der „Leittechnikpyramide“ stellt die Schnittstelle zur physischen
Umgebung des verfahrenstechnischen Prozesses dar. Sensoren erfassen messtechnisch
Prozessgrößen, wie z.B. Drücke, Temperaturen, Durchflüsse, mechanische Stellungen und
Bewegungen und wandeln sie in normierten Eingangssignale (z.B. 0 – 10V, 4 – 20mA) um.
Aktoren beeinflussen den Prozess mittels Antrieben, Ventilen und sonstigen Stellgliedern in
Abhängigkeit von den vom Automatisierungssystem ausgegebenen (normierten)
Ausgangssignalen.
Quelle: Siemens
Abbildung 2: Schematische Darstellung einer Leittechnikanlage
Automatisierungsebene
Automatisierungssysteme erfassen die Eingangssignale mittels spezieller Eingabemodule,

die auch der messtechnischen Behandlung der normierten Eingangssignale (galvanische
Seite 18 von 262

Entkopplung, Glättung, etc.) dienen und wandeln die Signale in Prozessdaten mit realen
Prozesseinheiten (z.B. bar, kg/s, %) um. Ggf. versorgen die Automatisierungssysteme die
vorgeschalteten Sensoren auch mit der notwendigen Energie. Gemäß der im
Automatisierungssystem hinterlegten Programmlogik werden diese Eingangsdaten
verarbeitet, bei Bedarf mit manuellen Eingaben des Bedienpersonals verknüpft und in
Ausgabedaten überführt. Ausgabemodule wandeln die Ausgabedaten in der Regel in
elektrische Ausgangssignale um, die mit Hilfe der nachgeschalteten Aktoren (Pumpen,
Antriebe, Ventile, etc.) den verfahrenstechnischen Prozess beeinflussen. Die in den
Automatisierungssystemen hinterlegte Prozesslogik umfasst nicht nur die eigentlichen
Programme zur Prozessführung, sondern auch Programme, die zur Behandlung von
Fehlerzuständen und kritischen Prozesssituationen dienen. Aus diesem Grund müssen diese
Systeme strengen Echtzeitanforderungen genügen, um Schäden für Personen, Anlage
sowie Umwelt zu vermeiden.
Für die Automatisierungssysteme existieren verschiedene Konzepte hinsichtlich der

Ausprägung der Systemredundanz:
 Nicht-redundant
 Hochverfügbar
 Fehlersicher
 Hochverfügbar und fehlersicher
Die nicht-redundante Ausführung entspricht der einfachen Ausführung der Systeme, die
vielfach auch als „einkanalig“ beschrieben wird, da jede Systemfunktion und -komponente
nur einmal vorhanden ist.
Die hochverfügbaren Systeme - auch als „1-von-2“-Systeme bezeichnet - haben alle

wesentlichen Systemfunktionen und -komponenten doppelt implementiert, so dass bei
Ausfall einer Komponente das System weiterhin funktioniert. Die redundanten Funktionen
sind im Sinne einer ODER-Verknüpfung realisiert.
Fehlersichere System (auch: „2-von-2“-System) haben ebenfalls alle wesentlichen

Systemfunktionen und -komponenten doppelt implementiert. Im Gegensatz zu den
hochverfügbaren Systemen, sind die redundanten Funktionen sind im Sinne einer UND-
Verknüpfung realisiert. Falls eine Abweichung zwischen den beiden Funktionskanälen
entsteht, führt das System sofort eine vordefinierte Schutz- oder Sicherheitsfunktion aus, z.B.
das Abschalten des geführten Anlagenteils. Diese Schutz- oder Sicherheitsfunktion muss in
der Regel durch eine zugelassene Überwachungsbehörde geprüft und zugelassen werden.
Seite 19 von 262

Schließlich gibt es noch hochverfügbare und fehlersichere Automatisierungssysteme. Diese

Systemvariante verfügt über drei Redundanzkanäle, die mittels einer „2-von-3“-Logik
verknüpft sind. Der Ausfall eines Redundanzkanales wird durch das System toleriert, jedoch
geht es dann in den Zustand eines fehlersicheren Systems („2-von-2“) über: bei Auftreten
eines weiteren Fehlers führt das System sofort die vordefinierte Schutz- oder
Sicherheitsfunktion aus.
Es ist offensichtlich, dass die Schutz- und Sicherheitsfunktionen, die die Umgebung des
Automatisierungssystems vor physischen Schäden bewahren sollen, eine besonders
schützenswerte Systemeigenschaft hinsichtlich der IT-Sicherheit darstellen.
Im engl. Sprachraum werden die Automatisierungssysteme auch mit dem Begriff „Process
Logic Controller“ (PLC) bezeichnet
Bedien- und Beobachtungsebene
Die Bedien- und Beobachtungsebene umfasst die Arbeitsstationen des Bedienpersonals,

denen die sichere Prozessführung obliegt, und die zugehörigen Anwendungsserver, die die
Arbeitsplatzsysteme mit den für eine ordnungsgemäße Prozessführung notwendigen
Visualisierungsdaten und Bedienmöglichkeiten bereitstellen. Die Visualisierung soll möglichst
übersichtlich statische und dynamische Prozesszustände darstellen, kritische Prozesswerte
melden und Bedienelemente zur Eingabe manueller Bedienbefehle und
Prozesseinstellungen bereitstellen.
Im engl. Sprachraum werden die Bedien- und Beobachtungssysteme auch mit dem Begriff
„Human Machine Interface“ (HMI) bezeichnet.
Projektierungssysteme
Mit Hilfe von Projektierungssystemen erhalten die Automatisierungssysteme sowie die

Bedien- und Beobachtungssysteme ihre logische, funktionale Struktur, die die anlagen- und
prozessspezifische Aufgabenstellung implementiert. Hierzu gehören die Prozesslogik und
die Normierungseinstellungen der Ein- und Ausgabewerte in den Automatisierungssystem
sowie die Prozessdarstellungen in den Bedien- und Beobachtungssystemen, mit denen das
Betriebspersonal die Anlage bedient. Darüber hinaus können – je nach Hersteller – auch die
Konfiguration des Prozessalarm- und Meldesystems oder Einstellungen der Systemplattform
erfolgen.
Je nach Hersteller lassen sich mit den Projektierungssystemen auch die Parameter der
Aktoren und Sensoren einstellen.
Seite 20 von 262

Im engl. Sprachraum werden die Projektierungssysteme auch mit dem Begriff „Engineering
system“ (ES) bezeichnet.
Informationssysteme
Neben den oben geschilderten Aufgaben der Leitsysteme stellen die Betreiber
prozesstechnischer Anlagen in zunehmendem Maße die Anforderung, Prozessdaten nicht
dem Bedienpersonal im Leitstand, sondern auch den Mitarbeitern im Büroumfeld zur
weiteren Verarbeitung und Analyse zur Verfügung stellen zu können. Dies erfordert die
Anbindung eines Prozessdatenarchives an die Leittechnik, die die Büromitarbeiter in der
Lage versetzt, nach eigenem Bedarf Datenanalysen vorzunehmen.
Zur Optimierung der prozesstechnischen Verfahren, z.B. Verbrennungsregelung, An- und

Abfahrprozesse etc., aber auch zu Servicezwecken ist es erforderlich Mitarbeitern aus dem
Unternehmensnetzwerk heraus einen direkten Zugang zur Benutzeroberfläche des
Leitsystems zu gewähren. Hierzu dienen z.B. Terminal Server, die Anwendern in den Büros
ausschließlich lesenden Zugriff auf die Benutzeroberfläche der Leitsysteme gewähren.
In zunehmendem Maße stellen Betreiberunternehmen die Anforderung an Leitsysteme,

Prozessdaten an typische IT-Systeme der Unternehmensführung (betriebswirtschaftliche
Systeme, wie z.B. Enterprise Ressource Planning ERP, Abrechnungssysteme oder zur
Datenaggregation auf höherer Unternehmensebene) zu übertragen. Für diese Zwecke
erfolgen entweder Datenauskopplungen aus dem bereits oben erwähnten
Prozessdatenarchiv oder direkte Kopplungen zwischen Leittechnik und Systemen der
Unternehmens-IT.
Im Falle von Störungen der Automatisierungssysteme geht von den verfahrenstechnischen

Prozessen ein hohes Schadenspotential aus. Dies gilt insbesondere bei Prozessen mit
hohen kinetischen Energien, hohen Dampfdrücken oder -temperaturen, offenem Feuer,
giftigen oder anderweitig gefährlichen Stoffen. Aus diesem Grund muss die IT-Sicherheit der
Leitsysteme, die die Systemintegrität gewährleisten soll, einem reproduzierbaren und
transparenten Managementprozess unterworfen sein. Dies bedeutet, dass die
Betriebsorganisation die vorgegebenen Ziele hinsichtlich der Leittechniksicherheit durch
definierte Betriebsabläufe, Verantwortlichkeiten und Ressourcen anstrebt sowie die
Zielerreichung in geeigneter Weise kontrolliert und gegebenenfalls geeignete (zusätzliche)
Maßnahmen ergreift. Der Nutzen einer umfassenden Aussage zur IT-Sicherheit der
Leittechnik für die Betriebsführung ist offensichtlich.
Seite 21 von 262

2.2 Technologietrends
Der Übergang der Leit- und Automatisierungstechnik von einer Technologie, die auf
diskreten Bauelementen basierte (Logikbausteine, Integrated circuits) zu den heute
genutzten Systemen auf Basis von Standardkomponenten, d.h. Verzicht auf
Spezialhardware und Nutzung von Standardbetriebssystemen anstelle proprietärer
Betriebssysteme, lässt sich grob in 4 Phasen unterteilen (siehe Abbildung 3).
Abbildung 3: Technologietrends (Quelle: Verfasser)
Die aufgeführten Zeiträume sind nur zur groben Orientierung angegeben. Sie können sich je
nach Hersteller, Branche, Anlagentyp und geografischer Region unterscheiden:
Phase 1 Automatisierung auf Basis diskreter Hardware-Bausteine
Automatisierungssystem: diskrete Logikbausteine auf IC-Basis
Bedienung und Beobachtung: Pultbedienung und Einzelanzeigeinstrumente
Systemprojektierung: mittels Hardwareverdrahtung
Seite 22 von 262

Vernetzung: keine
Phase 2 Digitale Automatisierungssysteme
Automatisierungssystem: Programmierbare Zentraleinheiten und IO-Einheiten mit

zunächst hartcodierter und/oder programmierbarer Logik
Bedienung und Beobachtung: Spezialrechner sowie Pultbedienung und

Einzelanzeigeinstrumente
Systemprojektierung: mittels Spezialgeräten und Hardwareverdrahtung
Vernetzung: Netzwerkverbindungen zwischen Systemen und Komponenten des

gleichen Herstellers mittels proprietären Netzwerkprotokollen
Phase 3 Standardisierung

programmierbarer Logik; Automatisierungssysteme auf Basis von
Standardbetriebssystemen und PC-Hardware („Soft-PLC“) für unkritische Aufgaben
Bedienung und Beobachtung: Nutzung von Standardplattformen (Betriebssysteme,

Datenbanken, Hardware) zur Ausführung von Leittechnikanwendungen
Systemprojektierung: mittels Leittechnikanwendungen auf Standardrechnern und

Standardplattformen (Betriebssysteme, Datenbanken, Hardware)
Vernetzung: Netzwerkverbindungen zwischen Systemen und Komponenten des

gleichen Herstellers mittels Standardprotokollen
Schnittstellen: Verwendung weitverbreiteter Standardschnittstellen wie z.B. CD/DVD-

Laufwerke oder USB-Tastaturen / -Mäuse / -Datenträger
Phase 4 Vernetzung

programmierbarer Logik; Automatisierungssysteme auf Basis von
Standardbetriebssystemen und PC-Hardware („Soft-PLC“) für unkritische Aufgaben
Bedienung und Beobachtung: Nutzung von Standardplattformen (Betriebssysteme,

Datenbanken, Hardware) zur Ausführung von Leittechnikanwendungen
Systemprojektierung: mittels Leittechnikanwendungen auf Standardrechnern und

Standardplattformen (Betriebssysteme, Datenbanken, Hardware)
Seite 23 von 262

Vernetzung: Automatisierungssysteme unterschiedlicher Hersteller mit

Standardprotokollen; standardisierte Bussysteme zur Anbindung der Feldgeräte;
Fernwartung; Anbindung an Unternehmensnetzwerke; Fernwartungszugänge
Mit Blick auf den Schutz der Systeme vor Angriffen lassen sich daraus folgende
Technologietrends ableiten und neuartigen Risiken zuordnen:
 In zunehmendem Maße kommen in Leit- und Automatisierungssystemen

Standardkomponenten (Betriebssysteme, Datenbanken, Netzwerkprotokolle etc.) zur
Anwendung. Damit erweitert sich der Kreis von Personen, die – zumindest in
Teilbereichen – über Systemkenntnisse verfügen, über die sogenannten „Insider“
hinaus.
 Der Vernetzungsgrad zwischen Systemen verschiedener Hersteller nimmt zu; dies

erfordert zunehmende Standardisierung der Kommunikation. Die Standardisierung
erweitert den Kreis der Personen mit Systemkompetenz.
 Der Vernetzungsgrad zwischen Komponenten, die im zentralen Leittechnikraum

platziert sind und Komponenten, die entweder im Feldbereich oder in anderen
Örtlichkeiten des Unternehmens untergebracht sind, nimmt zu. Dies erweitert die
Anzahl möglicher Angriffs- und Manipulationspunkte gegen die Systeme bzw. die
Systemkommunikation ohne physischen Zugang zum zentralen Leittechnikraum
vorauszusetzen.
 Die Verfügbarkeit spezifischer Systemdokumentationen im Internet erweitert den

Kreis von Personen mit (Teil-) Systemkenntnissen.
 Die Verfügbarkeit von Suchmaschinen im Internet, die sich auf das Auffinden von
Automatisierungssystemen spezialisiert haben, erleichtert das Finden sowie den
Zugang zu diesen Systemen erheblich.
 Der Einsatz von (standardisierten) Hardwarekomponenten aus Fremdfertigung bringt

das Risiko mit sich, dass Hard- oder Software-Funktionen in den Fertigungsprozess
eingeschleust werden, die eine Beeinflussung der Leitsysteme im operativen Betrieb
ermöglichen. Dieses Risiko wird durch Nutzung von Standardschnittstellen
(CD/DVD/USB) und der Vernetzung mit Intranets und/oder Internet verstärkt.
Seite 24 von 262

2.3 Unterschiede zwischen Leittechnik- und IT-Systemen
2.3.1 Schutzziele von IT-Systemen
IT-Serversysteme in Unternehmen dienen unterschiedlichen Unternehmenszwecken.

Beispiele seien Fileserver, E-Mail-Server, Web-Server am Internet oder im Intranet,
Finanzbuchhaltung (ERP-Systeme) usw. Die wesentlichen Schutzziele, denen die Rechner
genügen müssen, sind Vertraulichkeit, Integrität und Verfügbarkeit – in unterschiedlicher
Priorität. Beim Fileserver, der aktuelle Forschungsdokumente speichert, steht die
Vertraulichkeit im Vordergrund. Die ERP-Systeme müssen primär Integrität, d.h. Richtigkeit
der Unternehmensdaten, aber auch Vertraulichkeit gewährleisten, z.B. für personalbezogene
Informationen. Die Verfügbarkeit der Systeme spielt eine nachrangige Rolle. Ein Ausfall von
Minuten bis evtl. wenigen Stunden ist zwar in der Regel mit Kosten sowie Störungen der
normalen Betriebsabläufe verbunden, können aber je nach Systemzweck toleriert werden.
Die Schutzzielpriorität bei IT-Systemen ist daher wie folgt:
1. Vertraulichkeit
2. Integrität
3. Verfügbarkeit
Je nach Anwendungszweck des Systems kann die Priorität von Vertraulichkeit und Integrität
auch vertauscht sein. Beispielsweise hat bei Informationen, die aus rechtlichen Gründen
veröffentlicht werden, die Richtigkeit der Daten Vorrang vor einer nicht notwendigen
Vertraulichkeit der Informationen (wg. Veröffentlichung im Internet).
Weitere Schutzziele von IT-Systemen, wie z.B. die Nachvollziehbarkeit oder die
Nichtabstreitbarkeit von Transaktionen, sollen im Kontext der vorliegenden Arbeit nicht weiter
betrachtet werden, da sie für leittechnische Systeme (derzeit) keine Rolle spielen.
2.3.2 Schutzziele von SCADA-Systemen
Leittechniksysteme haben die Aufgabe, verfahrenstechnische Prozesse zu führen. Unter

Aufsicht des Bedienpersonals und mittels manuellen Bedieneingriffen oder automatischen
Programmabläufen greifen diese Systeme über Aktoren in die physische Umgebung ein.
Neben den im Vordergrund stehenden verfahrenstechnischen Prozessabläufen, erfüllen die
Leittechniksysteme auch Schutzfunktionen für Personen, Anlage und Umwelt: Im Falle
kritischer Prozesszustände überführen sie die Gesamtanlage in einen sicheren, d.h. für die
Umgebung ungefährlichen oder schadensminimalen Zustand. Bei Ausfall des Systems
Seite 25 von 262

verliert das Bedienpersonal ggf. die Anlagenkontrolle und die Schutzfunktionen sind nicht
mehr verfügbar: es entsteht das Risiko von Personen-, Anlagen- oder Umweltschäden.
Die Schutzziele von Leittechniksystemen haben aufgrund der skizzierten Schutzfunktionen

grundsätzlich eine Prioritätenfolge, die sich von den anwendungsabhängigen Prioritäten der
oben skizzierten IT-Systeme (siehe 2.3.1, 2.3.2) unterscheidet:
1. Verfügbarkeit
2. Integrität
3. Vertraulichkeit
Die Systemverfügbarkeit von Leittechniksystemen genießt immer oberste Priorität. Dieses

Anforderungsprofil resultiert aus folgenden Gründen:
a) Bei Ausfall des Leittechniksystems stehen die implementierten Schutzfunktionen des

Anlagenprozesses nicht mehr zur Verfügung. Um Schäden für Personal, Anlage und
Umwelt zu vermeiden, muss die Anlage abgeschaltet deshalb werden. In der Regel
sind mit der Abschaltung und dem späteren Neustart des verfahrenstechnischen
Prozesses erhebliche finanzielle Schäden für die Anlagenbetreiber verbunden.
b) Im Falle einer Unverfügbarkeit des Leitsystems verliert das Bedienpersonal u.U. die
Prozesskontrolle. Auch in diesem Falle ist eine Notabschaltung einzuleiten – mit den
bereits erwähnten finanziellen Einbußen. Die Anlagenabschaltung in solchen
Situationen kann bei kritischen (im Sinne von gefährlich) Prozessen auch behördlich
vorgeschrieben sein.
Ebenfalls sehr hohe Priorität genießt die Systemintegrität, da logische Fehler in den System-
oder Ablaufprogrammen Fehlfunktionen verursachen können, die sich über die
angeschlossenen Aktoren in die physische Umgebung auswirken. Die Vertraulichkeit der
Daten in Leittechniksystemen genießt vielfach geringe Priorität. Gespeicherte oder
übertragene Daten verfügen in Automatisierungssystemen vielfach nicht über den
erforderlichen Informationskontext (Signalname, Wertebereich etc.), was eine nicht
autorisierte Auswertung erschwert bzw. unmöglich macht. Ausnahmen für Systeme mit
höheren Anforderungen an die Vertraulichkeit stellen z.B. SCADA-Systeme für chemische
Produktionsverfahren dar, da die in der Systemlogik abgebildeten Produktionsregeln das
spezifische Produktions-Knowhow des Unternehmens darstellen. Generell ist jedoch
zukünftig mit einer zunehmenden Bedeutung der Aspekte des Knowhow-Schutzes bei
Automatisierungssystemen zu rechnen.
Seite 26 von 262

2.3.3 Echtzeitanforderungen
Im Gegensatz zu typischen IT-Systemen im Bereich der Unternehmens-IT, wie z.B.

Dateiserver, E-Mail-Server, Web-Server etc., stellen SCADA-Systeme hohe Anforderungen
an die Echtzeitfähigkeit. Auf jede Anlagensituation, die das System mittels Sensoren erfasst,
muss eine notwendige Reaktion innerhalb definierter Reaktionszeiten erfolgen. Geforderte
Reaktionszeiten liegen häufig im Bereich 10 … 500ms. Kritische Prozesse erfordern
Reaktionszeiten, die im Bereich weniger Millisekunden liegen. Der wesentliche Unterschied
zu hochbelasteten Handels- oder Transaktionssystemen, z.B. der Finanzwirtschaft, die aus
Gründen des erforderlichen Datendurchsatzes geringe Reaktionszeiten liefern müssen, ist,
dass Leitsysteme auf definierte externe Ereignisse in allen Lastsituationen zulässige
Reaktionszeiten nicht überschreiten dürfen. Diese Prognostizierbarkeit der Systemreaktion
stellt ein wesentliches Merkmal der Leitsysteme dar.
Die Integration von Schutzmaßnahmen, die ursprünglich für typische IT-Umgebungen

entwickelt wurden, wie z.B. Firewalls, Verschlüsselungssysteme etc. darf bei Einsatz in
Leittechnikanlagen keinen nachteiligen Einfluss auf die Verfügbarkeit der Systeme und deren
Reaktionsfähigkeit zur Folge haben. Zu beachten sind die resultierende Gesamtverfügbarkeit
wie auch die Signallaufzeit vom Bedieneingriff des Personals hin zum Aktor und vom Sensor
zurück zur Anzeige der Prozessreaktion. Der Einbau zusätzlicher IT-Schutzkomponenten,
wie z.B. Firewalls zwischen den Endpunkten des Signalweges erhöht die
Ausfallwahrscheinlichkeit der Signalstrecke, während z.B. der Einbau zusätzlicher
Verschlüsselungstechnik die Laufzeit des Signals aufgrund der zusätzlich notwendigen
Datenverarbeitung erhöht. Insbesondere bei kritischen Prozessanlagen legen Betreiber
und/oder Aufsichtsbehörden Grenzwerte für Reaktionszeiten fest und prüfen deren
Einhaltung im Rahmen der Abnahmeprüfung einer Gesamtanlage.
2.3.4 Betriebliche Aspekte
Die Anforderungen hinsichtlich der IT-Sicherheit für Leittechnik- und IT-Systeme

unterscheiden sich aufgrund der unterschiedlichen Einsatzgebiete dieser Systeme. Neben
den unterschiedlichen Prioritäten der Schutzziele (siehe 2.3.1 und 2.3.2) sowie den
unterschiedlichen Randbedingungen, wie z.B. die Echtzeitanforderungen an Leittechnik- und
Automatisierungssysteme, ergeben sich auch aufgrund der betrieblichen Besonderheiten
unterschiedliche Herangehensweisen der Implementierung von Maßnahmen zur IT-
Sicherheit.
Seite 27 von 262

Erhebliche Unterschiede findet man zwischen IT-Unternehmensnetzwerken und

Leittechniknetzwerken. Erstere sind heterogen hinsichtlich der Anzahl und Art der Systeme
und Applikationen sowie der eingesetzten Hardware (z.B. Server, Desktops, Notebooks,
Tablet-PCs etc.). Außerdem kennzeichnet diese Netze nutzungsbedingt eine dynamische
Charakteristik angesichts der Vielzahl der hinzugefügten bzw. entfernten Anwendungen,
Systeme und Netzwerksegmente. Im Gegensatz dazu ist für Leittechniknetzwerke eine stark
reduzierte Vielfalt hinsichtlich der Betriebssysteme, Anwendungen und Hardwarevarianten
typisch. Die Veränderungsdynamik hinsichtlich der Anzahl und Art der eingesetzten Systeme
und Applikationen ist gering. Änderungen an Leitsystemen gehen in der Regel mit
Änderungen am Produktionsprozess einher und können oft nur bei Anlagenstillstand
vorgenommen werden.
Neben dem eher statischen Charakter der Leit- und Automatisierungssysteme existiert in der
Praxis noch ein weiterer Unterschied, der wesentliche Auswirkung auf die IT-Sicherheit hat:
der physische und logische Zugang zu den Leitsystemen. In der Regel hat nur ein kleiner
Personenkreis physischen Zugang in die Räumlichkeiten mit Leittechnikkomponenten und
logischen Zugang über Netzwerkverbindungen. Des Weiteren sind in Systemen mit
aktuellem Sicherheitskonzept die physischen Standardschnittstellen, wie z.B. CD- / DVD-
Laufwerke oder USB-Schnittstellen deaktiviert. Diese Abschottung bringt jedoch mit sich,
dass sich Sicherheitsupdates nicht automatisiert einspielen lassen. Das manuelle Einspielen
setzt voraus, diese Abschottung zumindest temporär aufzuheben.
Erschwerend kommt hinzu: das zeitnahe Einspielen der Sicherheitsupdates in

Unternehmens-IT-Systemen erfolgt typischerweise innerhalb definierter Wartungsfenster,
z.B. in den Nachtstunden, wenn typische Büroarbeiten ruhen. Im Gegensatz dazu haben
Systeme, die verfahrenstechnische Prozesse steuern, ein 24/7-Betriebsmodell, das über
Wochen oder Monate ohne Unterbrechungen betrieben wird. Tägliche oder wöchentliche
Wartungsfenster für regelmäßige Aktualisierungsmaßnahmen existieren nicht.
Die Aktualisierung betriebswichtiger Komponenten, wie z.B. des Betriebssystems, erzwingt

in vielen Fällen einen Systemneustart, der sich direkt auf die Betriebsführung des
verfahrenstechnischen Prozesses auswirkt. Das Wartungspersonal steht nun vor einem
Dilemma, das IT-Systemverantwortlichen in der Regel unbekannt ist: entweder wird das
Einspielen von sicherheitsrelevanten Aktualisierungen auf einen späteren Termin
verschoben und damit Angreifern für eine längeren Zeitraum die Chance gegeben, die
Schwachstellen für Angriffe zu missbrauchen, oder den verfahrenstechnischen Prozess in
einen Zustand zu überführen, der das Aktualisieren der Leit- und Automatisierungssysteme
gestattet.
Seite 28 von 262

Falls der Betreiber die Entscheidung für das Herunterfahren des verfahrenstechnischen
Prozesses zum ausschließlichen Zwecke der Systemaktualisierung und einem
anschließenden Neustart trifft, stellt sich ein weiteres Dilemma: die notwendigen Eingriffe in
den verfahrenstechnischen Prozess verursachen unter Umständen erhebliche finanzielle
Einbußen. Das Einspielen der Sicherheits-Patches verursacht damit gerade jene Kosten, die
durch Beseitigung der Systemschwachstelle vermieden werden sollten. Der Betreiber fügt
sich durch die Systemaktualisierung somit selbst den Schaden zu, den ein potentieller
Angreifer durch Ausnutzen der Systemschwachstelle verursachen wollte. Dessen ungeachtet
reduziert der Betreiber mit der Systemaktualisierung die Risiken physischer Schäden an
Personen, Anlagen und Umwelt.
Im Gegensatz zu IT-Systemen ist für Leit- und Automatisierungssysteme eine lange

Nutzungsdauer typisch. Während Server und PCs selten länger als 3 … 5 Jahre zum Einsatz
kommen, ist bei SCADA-Systemen eine Nutzungsdauer von 20 Jahren keine Seltenheit. Der
Austausch kompletter Leitsysteme verursacht einen Anlagenstillstand, der mehrere Wochen
oder gar Monate in Anspruch nehmen kann – mit entsprechenden Kosten für den damit
verbundenen Produktionsausfall. Konsequenz dieser langen Nutzungsperioden und des
damit einhergehenden Alters der Systeme ist die zunehmend reduzierte Bereitstellung von
Updates und Bugfixes durch die Hersteller. Ein Problem, das sich für typische IT-Systeme
aufgrund der vergleichsweise kurzen Nutzungsdauer nur selten stellt. Ein aktuelles Beispiel
stellt die von Microsoft angekündigte Einstellung des allgemeinen Supports für MS Windows
XP (Microsoft, 2014) dar. Die SCADA-Betreiber stehen damit vor einer Reihe von Problemen
bzw. Entscheidungen, die sich in dieser Weise für typische IT-Systeme nicht oder nur in
geringem Maße stellen:
 Microsoft stellt keine kostenlosen Windows XP-Aktualisierungen (Security-Patches)

mehr zur Verfügung. Hersteller stehen vor der Entscheidung, die MS Windows XP-
basierten Produktlinien abzukündigen oder kostenpflichtige Servicevereinbarungen
mit Microsoft zu schließen und an die Kunden weiter zu verrechnen.
 Im Falle der Abkündigung muss der Betreiber entscheiden, welches Nachfolgesystem

eingesetzt werden soll, bis wann dieses System verfügbar ist und wie die
Systemmigration erfolgen kann – unter Berücksichtigung der Auswirkungen für den
verfahrenstechnischen Prozess. Bei kritischer Infrastruktur ist für die Dauer der
Umstellungsmaßnahmen Ersatzproduktionskapazität zu beschaffen (z.B.
Stromerzeugungskapazität).
Seite 29 von 262

 Da MS Windows XP seit 2002 im Einsatz sein kann, ist im Falle des Umstiegs auf ein
neueres Betriebssystem in der Regel ein Hardware-Tausch notwendig.
 Im Falle des Betriebssystem- und / oder Hardware-Tausches sind Abhängigkeiten

von SCADA-Spezialkomponenten zu prüfen.
In jedem Falle muss der SCADA-Betreiber die Verknüpfung der notwendigen IT-Sicherheit
seiner Systeme mit der Servicefähigkeit des Lieferanten sowie den Migrationsaufwand
(Zeitraum) seines SCADA-Systems mit den verfahrenstechnischen Randbedingungen der
Produktion in Einklang bringen.
Abschließend sei noch auf ein formales Problem bezüglich der Systemaktualisierungen
hingewiesen. Für besonders kritische Anlagen, d.h. Anlagen deren Störung oder
Nichtverfügbarkeit besonders unerwünschte Auswirkungen auf die Umgebung haben
könnten, legen die zuständigen Aufsichtsbehörden besondere Auflagen für das Einspielen
von Software fest. Neben eindeutigen Vorgaben für den Prozesszustand während der
Wartungsmaßnahmen, müssen Hersteller u.U. umfangreiche Dokumentationen für die
geplanten Maßnahmen vorlegen, die z.B. auch mögliche Auswirkungen der einzuspielenden
Software beinhalten. Für sogenannte „Qualifizierte Systeme“ können Aufsichtsbehörden
sogar einen umfangreichen Re-Zertifizierungsprozess vorschreiben.
Auf die unterschiedliche Handhabung der IT-Sicherheit für IT-Systeme zur betrieblichen oder
privaten Nutzung sowie den Leit- und Automatisierungssystemen wird nun auch in ersten
Standards hingewiesen. (DKE, 2014) weist darauf hin, dass „Normen wie ISO/IEC 27000,
ISO/IEC 27001 und ISO/IEC 27002 […] wegen der spezifischen Eigenheiten
rechnerbasierter leittechnischer Systeme in KKW, zu denen auch die Anforderungen
bezüglich Reaktorsicherheit und Genehmigungsverfahren zu zählen sind, nicht direkt auf den
Cyberschutz dieser Systeme anwendbar [sind].“
Seite 30 von 262

Kapitel 3 IT-Sicherheit von Leit- und Automatisierungssystemen
3 IT-Sicherheit von Leit- und Automatisierungssystemen
3.1 Überblick
Nach den grundlegenden Überlegungen zu Leit- und Automatisierungssystemen im

vorangehenden Kapitel soll nun für die weitere Arbeit ein Blick auf die wesentlichen
Begrifflichkeiten im Kontext dieser Systeme geworfen werden.
Die Abgrenzung zwischen funktionaler Sicherheit und IT-Sicherheit dient dem Zweck, die IT-
Sicherheit leittechnischer Systeme als Schutzelement der funktionalen Anlagensicherheit zu
verdeutlichen. Aus der Analyse verschiedener Definitionen der „IT-Sicherheit“ lässt sich eine
Herangehensweise für die Analysemethode und die Kennzahlenmatrix ableiten.
Voraussetzung für die weitere Betrachtung der Bedrohungen der Leit- und
Automatisierungssysteme ist Entwicklung eines Bedrohungsmodells, das sowohl die
Analysemethode als auch notwendige Abgrenzungen bzw. Ausschlüsse (von der weiteren
Betrachtung) plausibilisiert. Mit Hilfe des Bedrohungsmodells lassen sich die Aktoren des
generischen Angriffsszenarios identifizieren und die numerischen bzw. funktionalen
Zusammenhänge untersuchen. Das Bedrohungsmodell, das der weiteren Betrachtung
zugrunde liegt, grenzt jene Aktoren ab, für die Systemanalysten keine validen Daten zur
Verfügung stehen. Im Gegensatz zu anderen Analyseansätzen liefert das vorzustellende
Bedrohungsmodell jene Aktoren, die einer faktenorientierten Betrachtung zugänglich sind.
3.2 Begriffe und Abgrenzungen
3.2.1 Funktionale Sicherheit
Der dt. Begriff „Sicherheit“ findet in der engl. Sprache zwei Entsprechungen: Safety und
Security.
Sicherheit im Sinne des engl. Begriffs „Safety“ wird im dt. Sprachraum als funktionale
Sicherheit bezeichnet und beschreibt Systemfunktionen, die dem Schutz der
Systemumgebung vor Fehlfunktionen des betrachteten Automatisierungssystems dienen
(Abbildung 4). Als Systemumgebung können Personen, Anlagen und Anlagenteile sowie die
von dem betreffenden System über die angeschlossenen Aktoren beeinflussbare Umwelt
aufgefasst werden.
Seite 31 von 262

Das für die Automatisierungstechnik wichtige Regelwerk (ISA-62443-1-1, 2014) definiert den
Begriff der funktionalen Sicherheit als "freedom from unacceptable risk".
Abbildung 4: Safety vs. Security
Sicherheitsmaßnahmen zum Schutz der Umgebung können z.B. Redundanzkanäle mit

Voting-Strukturen (2-von-2), Fehlererkennungsmechanismen oder dedizierte Abschalt- oder
sonstige Schutzprozeduren sein. Im weiteren Verlauf des vorliegenden Dokumentes wird auf
die Aspekte der funktionalen Sicherheit nicht eingegangen und ‚Sicherheit‘ ausschließlich im
Sinne von ‚Security‘ aufgefasst.
3.2.2 IT-Sicherheit
Fehlerhafte Parameter oder Systemeinstellungen eines SCADA-Systems, z.B. aufgrund

eines erfolgreichen Angriffes, können zu einer inkorrekten Betriebsweise des
verfahrenstechnischen Prozesses führen und Schäden für die Umgebung verursachen.
Aufgrund dieser Gefährdung von Personen, Anlagen oder der Umwelt stellt die
Gewährleistung der funktionalen Sicherheit, d.h. die korrekte und sichere Funktion des
Seite 32 von 262

betrachteten Systems, das primäre Ziel der IT-Sicherheit dar. IT-Sicherheit (im Sinne des
engl. Begriffs „Security“) bezeichnet den Schutz des betrachteten Systems vor
Manipulationen aus der Systemumgebung. Systemmanipulationen stellen absichtliche oder
unabsichtliche Veränderungen der Anwendungs- oder Konfigurationsdaten des Zielsystems
dar, die zu einem Systemverhalten führen können, das nicht den Anforderungen der
Aufgabenstellung sowie geltenden technischen Regelwerken genügt (Abbildung 4).
Das für die Automatisierungstechnik wichtige Regelwerk (ISA-62443-1-1, 2014) definiert den
Begriff der IT-Sicherheit als
1. Schutzmaßnahmen für ein System
2. Systemzustand, der sich aus der Implementierung und Pflege von

Schutzmaßnahmen ergibt
3. Systemressourcen, die sich in einem Zustand frei von unberechtigtem Zugriff und von
unberechtigtem oder unbeabsichtigten Änderungen, Zerstörungen oder Verlust
befinden
4. hinreichendes Vertrauen in die Fähigkeit eines Computersystems, dass unberechtigte

Personen oder Systeme weder die Software noch die Daten verändern können,
keinen Zugang zu Systemfunktionen erhalten und sichergestellt ist, dass dies
berechtigten Personen oder Systemen nicht verweigert wird
5. Schutz vor illegalem oder unerwünschtem Eindringen oder Beeinträchtigen des

korrekten und vorgesehenen Betriebs eines industriellen Leit- oder
Automatisierungssystems
Für die weitere Betrachtung der IT-Sicherheit von SCADA-Systemen lassen sich aus dieser
Definition folgende Aspekte ableiten:
- Schutzmaßnahmen für ein System,
- Robustheit gegen Angriffe und
- Korrekter Systemzustand bzw. korrekte und verfügbare Systemfunktionen.
Einen wichtigen Aspekt fügt (Eckert, 2008) der obigen Definition von IT-Sicherheit hinzu:
Sicherheit wird als die Eigenschaft eines funktionssicheren Systems aufgefasst, nur solche
Systemzustände anzunehmen, die keine unautorisierte Informationsveränderung oder -
gewinnung ermöglichen.
Seite 33 von 262

3.2.3 Schutzziele: Abgrenzung und Anforderungen an die Systeme
In Kapitel 2.3.2 wurde bereits auf die vorrangigen Schutzziele „Verfügbarkeit“ und „Integrität“
von SCADA-Systemen hingewiesen. Diese Schutzziele ergeben sich aus der vorgenannten
Definition des Begriffes „IT-Sicherheit“ (Kapitel 3.2.2). Das System soll die geforderten
Systemdienste und -funktionen trotz Angriffsbemühungen robust bereitstellen
(„Verfügbarkeit“) und die Systemfunktionen korrekt ausführen und nur zulässige
Systemzustände einnehmen („Integrität“).
Das Schutzziel „Vertraulichkeit“ genießt hingegen eine nachrangige Priorität. Eine Ausnahme
bilden Systeme deren Prozesslogik wertvolle und damit schützenswerte
Betriebsgeheimnisse enthält. Diese Art der Automatisierungssysteme findet man z.B. im
Bereich der chemischen oder pharmazeutischen Industrie. Im weiteren Verlauf dieser Arbeit
beschränkt sich die vorliegende Betrachtung auf die Schutzziele „Verfügbarkeit“ und
„Integrität“. Diese beiden Schutzziele leiten sich aus der Anforderung an SCADA-Systeme
ab, die implementierte Prozesslogik zu jedem geforderten Zeitpunkt (= Verfügbarkeit) korrekt
(= Integrität) auszuführen. Systemanforderungen hinsichtlich der funktionalen Sicherheit (=
Safety) betrachten vorrangig die Aspekte der Beherrschbarkeit von Systemstörungen und
analysieren Ursachen primär innerhalb des betrachteten Systems. Fragen hinsichtlich
Fehlerursache und –auswirkung bleibt im weiteren Verlauf unberücksichtigt (siehe z.B.
(Eusgeld, et al., 2008)). Maßnahmen zur Beherrschung solcher Störungen können
beispielsweise Redundanzkanäle mit Synchronisationskontrolle, Auslegung von
Bauelementen, Fehlerfrüherkennungs- und Meldemechanismen usw. sein. Im Gegensatz zur
funktionalen Sicherheit stellt die IT-Sicherheit die Frage, wie eine unzulässige Manipulation
eines Systems von außen verhindert werden kann. Ziel einer unzulässigen
Systemmanipulation ist es, das korrekte Funktionieren eines Systems temporär oder auf
Dauer zu beeinträchtigen. Aufgrund der Vermutung, dass im Falle einer derartigen
Androhung einer Manipulation der Betreiber zusätzliche Schutzmaßnahmen ergreifen würde,
wird der Fall der Androhung einer Manipulation nicht weiter betrachtet.
3.3 Überlegungen zur Beurteilung von IT-Sicherheit
Der vorangegangene Abschnitt (3.2.2) stellte wesentliche Definitionen der IT-Sicherheit vor.
Diese Definitionen adressieren sowohl die Schutzmaßnahmen für SCADA-Systeme als auch
die korrekten und verfügbaren Systemfunktionen im Sinne von Systemeigenschaften. Diese
Definitionen haben jedoch ein gemeinsames Defizit: es fehlen Definitionen und Methoden
Seite 34 von 262

hinsichtlich der Messbarkeit der IT-Sicherheit. Die Definitionen beschreiben keine Variable,
die eine eindeutige Aussage zum Status der Systemsicherheit ermöglichen würde.
Hersteller und Betreiber von Leit- und Automatisierungssystemen stehen also trotz der
genannten Definitionen vor den Fragen:
 Was ist IT-Sicherheit?
 Wie kann man die IT-Sicherheit messen?
 Wie kann man die IT-Sicherheit einer Anlage beurteilen?
Aufgrund der bereits erwähnten Tatsache, dass es keine Größe gibt, die den
Sicherheitsstatus eines Computersystems hinreichend repräsentiert, greifen Analysten in der
Regel auf die Variable „Risiko“ als Ersatzgröße zurück. Auf risikobasierte Analysemethoden
wird in Kapitel 4 eingegangen werden. Zur Motivation sei vorab die Frage aufgeworfen,
welchen Nutzen Ergebnisse der Sicherheitsbetrachtungen für SCADA-Systeme in der Form
„Die Sicherheit ist MEDIUM“ oder „Die Sicherheit beträgt 57%“ für den Betreiber haben. Wie
noch zu zeigen sein wird, lassen sich solche Ergebnisse - falls überhaupt vorhanden – nur
oberflächlich mit den Aussagen zu ähnlicher Anlagen oder mit den Ergebnissen früherer
Analysen vergleichen. Erschwerend kommt hinzu, dass die Vergleichbarkeit von
Analyseergebnisse kritisch hinterfragt werden sollte (siehe 4.3). Konkrete Maßnahmen zur
Verbesserung der Anlagensicherheit lassen sich aus solchen Ergebnissen in der Regel nicht
ableiten.
Für die Beurteilung der IT-Sicherheit durch die Betreiber ist die Frage relevant, wie
umfangreich die Kenntnisse die Betreiber hinsichtlich der von ihnen betriebenen SCADA-
Systeme überhaupt sind. Betriebssysteme, SCADA-Applikationen sowie Firmware-
Komponenten enthalten in der Regel Software (Closed Source Software), über die Betreiber
keine detaillierten Informationen erhalten. Software-Analysemethoden, wie z.B. statische
Codeanalyse des Source-Codes, kommen deshalb nicht in Betracht. Die Ergebnisse wären
auch von begrenztem Nutzen, da die Betreiber an der Software üblicherweise keine
Änderungen vornehmen können (fehlende Sachkunde) bzw. wollen (Erlöschen der
Garantie).
Für den Betreiber mündet die Frage nach der System-IT-Sicherheit in die Betrachtung,
welche Manipulationen an dem zu untersuchenden System möglich sind. Die Antwort auf
diese Frage liefert dann Hinweise für Handlungsoptionen zur Verbesserung der
Systemsicherheit.
Seite 35 von 262

3.4 Bedrohungen von Leit- und Automatisierungssystemen
Die im vorangegangen Abschnitt (3.3) angestellten grundsätzlichen Überlegungen zur

Beurteilung der IT-Sicherheit von SCADA-Systemen sollen nun durch die Betrachtung der
Bedrohungen von Leit- und Automatisierungssystemen ergänzt werden. Diesem Zweck dient
ein elementares, dreiteiliges Bedrohungsmodell (siehe Abbildung 5).
Eine Bedrohung gegen SCADA-Systeme setzt drei beteiligte Instanzen voraus:
 Angreifer
 Zielsystem (SCADA-System)
 Angriffspfad vom Angreifer zum Zielsystem
Abbildung 5: Bedrohungsmodell
Im Gegensatz zu einem IT-System, wie z.B. einer Datenbank, einem Internet-Server usw.,
stellt die Störung oder die Manipulation eines Leitsystems keinen direkten „Nutzen“ für den
Seite 36 von 262

Angreifer dar: es lassen sich in der Regel keine Daten nutzbringend entwenden (evtl.
Ausnahme: Pharmazie oder Chemie o.ä.) oder Internetdienste missbräuchlich nutzen. Das
Interesse des Angreifers liegt im verfahrenstechnischen Prozess, den das SCADA-System
kontrolliert. Das Androhen oder Herbeiführen eines Schadens an Menschen, Anlagen oder
Umwelt stellt das Bedrohungsszenario für den Betreiber dar. Für die weitere Betrachtung
wird deshalb davon ausgegangen, dass das primäre Ziel des Angreifers der
verfahrenstechnische Prozess ist und das Automatisierungssystem lediglich das Mittel zum
Zweck darstellt. (Rid, 2013 S. 13) bezeichnet diese code-basierte Zerstörung als „parasitäre“
Eigenschaft des Zielsystems.
Die Analyse von Angriffsmodellen gegen die SCADA-Systeme zum Zwecke eines Schadens
in der physischen (und kommerziellen) Welt, kann nur mit Hilfe der drei oben genannten
Elemente erfolgen. Für die weitergehende Sicherheitsanalyse stellt sich somit die zentrale
Frage, welche Informationen über diese drei notwendigen Instanzen im Kontext der
Zielanlage überhaupt verfügbar sind:
 Angreifer
Eine umfassende Analyse der Sicherheit eines SCADA-Systems setzt voraus, dass
Informationen zur Beurteilung potentieller Angreifer vorliegen. Diese Daten müssen in
nachvollziehbarer und reproduzierbarer Form zugänglich sein.
Betrachtet man unter dieser Randbedingung das Element „Angreifer“, so wird offensichtlich,
dass einem Betreiber in der Regel keine Informationen über (potentielle) Täter vorliegen.
Selbst die Frage, ob überhaupt eine Angriffsbedrohung vorliegt, lässt sich in der Regel nicht
fundiert beantworten. Schließlich ist angesichts der begrenzten Zahl der Zielsysteme und
den möglichen Gegenmaßnahmen seitens der Anlagenbetreiber ist nicht davon auszugehen,
dass ein Angreifer einen Angriff ankündigt bzw. androht. Die Anwendung bzw. die Gültigkeit
statistischer Daten hinsichtlich einer Angriffswahrscheinlichkeit wird später in Kapitel 4
diskutiert werden.
Verschiedene Analysemodelle teilen Angreifer in unterschiedliche Klassen ein, wie z.B.

Script Kiddy, professionelle Angreifer, organisierte Kriminalität, staatliche Einrichtungen usw.
Diesen Angreifertypen lassen sich dann unterschiedliche Kompetenzen und Ressourcen
zuordnen. Diese Methode erfordert prinzipiell für jede dieser Angriffsklassen eine Analyse,
einschließlich der Analyseergebnissen für jede dieser Angriffsklassen. Eine Schlussfolgerung
auf die Eintrittswahrscheinlichkeit dieser Angriffsklassen in Bezug auf die betrachtete
Zielanlage lässt sich ebenfalls nicht ableiten. Die Beschränkung auf einen bestimmten
Angreifertyp hat somit rein spekulativen Charakter.
Seite 37 von 262

Aus den vorangegangenen Überlegungen resultiert, dass sich aus dem Element „Angreifer“
keine Daten für eine auf Fakten basierte, reproduzierbare Ergebnisse liefernde
Analysemethode ableiten lassen. Aus diesem Grund bleibt der Angreifer in der weiteren
Betrachtung und Entwicklung einer neuen Analysemethode ausgeklammert.
 Zielsystem
Das zweite Element des Bedrohungsmodells gemäß Abbildung 5 stellt das das SCADA-
System als eigentliches Ziel des Angriffes dar. Die Schwachstellen eines Systems stellen
hinsichtlich der Beurteilung der IT-Sicherheit von Computersystemen wesentliche Kriterien
dar: je größer die Zahl der Schwachstellen, desto geringer die IT-Sicherheit des betrachteten
Systems (Patel, et al., 2008).
Die Anzahl der Software-Schwachstellen eines Systems beeinflussen die IT-Sicherheit in

zweierlei Sicht:
a) Die absolute Anzahl der Schwachstellen
b) Die zeitliche Entwicklung der Anzahl der bekannt gewordenen Schwachstellen
Für die Ableitung einer faktenbasierten, reproduzierbaren Analysemethode ist zu klären,

welche Informationen hinsichtlich der Software-Schwachstellen (dem Betreiber) zur
Verfügung stehen. Leitsysteme bestehen heute aus verschiedenen Softwarekomponenten
verschiedener Hersteller. Typische Komponenten sind Betriebssysteme, Datenbanken,
Browser, die SCADA-Anwendung usw. Verschiedene Security-Metriken berücksichtigen die
Anzahl der bekannten Software-Schwachstellen. Die Systemsicherheit wird jedoch durch alle
Schwachstellen bestimmt – nicht nur durch die öffentlich bekannt gewordenen
Schwachstellen. Der Öffentlichkeit – und damit dem Betreiber – unbekannte Schwachstellen
(“Zero Day exploits”) könnten dem Angreifer sehr wohl bekannt sein.
In Anhang A1 ist anhand des Linux-Kernels eine Abschätzung der Anzahl von Software-
Schwachstellen dargestellt. Allein für den Betriebssystemkern erhält man schätzungsweise
über 3.000 Schwachstellen, die über den Nutzungszeitraum eines Leitsystems (typisch: 15
Jahre) trotz ca. 75 Updates pro Jahr unkorrigiert bleiben. Der Fehlervorrat für die
Entwicklung von „Zero Day Exploits“ scheint hinreichend groß.
Mit der skizzierten Abschätzung der Gesamtfehlerzahl des Linux-Kernel korreliert die
Aussage von Phil Zimmermann in (Wetter, et al.):
„Eigentlich benötigt man keine Hintertüren [in aktuellen Betriebssystemen, Anm. d.

Verf.], Zero Days reichen völlig aus – deren Vorrat ist nahezu unerschöpflich.“
Seite 38 von 262

Verschärfend kommt die „Lebensdauer“ der Zero-Day-Exploits hinzu, die sich über einen
signifikanten Teil einer typischen Software- oder Systemnutzungsdauer erstreckt: (Bilge,
Leyla; Dumitra, Tudor, 2012) identifizieren die durchschnittliche Zeitdauer zwischen
Freisetzung von Schadsoftware zur Ausnutzung einer Schwachstelle und der
Veröffentlichung der Schwachstelle bzw. des Patches auf ca. 10 Monate. Berücksichtigt man
die typische Nutzungsdauer von Softwareprodukten und IT-Systemen von ca. 3 … 5 Jahren,
die Vielzahl der Schwachstellen sowie die z.T. erhebliche Zeitspanne bis Schwachstellen
durch die Anwender gepatcht werden, dann wird ersichtlich, dass Patch-Maßnahmen in der
ersten Hälfte der Softwarenutzungsdauer nur bedingt vor Angriffsmöglichkeiten mittels Zero-
Day-Exploits schützen. Vergleich man diese Abschätzung mit den Werten von (Sumner
Lemon, 2007), so ergibt sich im Laufe von 5 Jahren eine geringfügige Verkürzung der Zero-
Day-Lebensdauer um ca. 10%.
Aus der skizzierten Abschätzung und der Lebensdauer von Zero-Day-Exploits lassen sich für
SCADA-Betreiber zwei Erkenntnisse ableiten:
1) Fasst man den IT-Sicherheitsstatus eines Rechnersystems als proportional zur

Anzahl der sicherheitsrelevanten (bekannten und unbekannten) Schwachstellen auf,
so trägt der Wartungsaufwand für das Aktualisieren des Systems mittels Software-
Patches zu keiner signifikanten Verbesserung bei.
2) Der Patch-Aufwand lässt sich rechtfertigen, weil durch die Beseitigung der öffentlich
bekannten Schwachstellen jenen Angreifern, die keinen Zugang zu Zero-Day-Exploits
haben, Angriffsmöglichkeiten genommen werden.
Aus dem oben skizzierten Bedrohungsmodell, bestehend aus den drei Elementen „Angreifer
– Zielsystem – Angriffspfad“, wurden Annahmen über potentielle Angreifer bereits als nicht
hilfreich für eine faktenbasierte Analysemethode identifiziert und deshalb das Element
„Angreifer“ aus der weiteren Betrachtung entfernt. Angesicht der obigen Abschätzung mit
dem Ergebnis, dass ca. 66% (siehe: Anhang A1) aller Software-Fehler über die
Nutzungsdauer eines Leitsystems hinweg existieren, ergibt die Analyse von (bekannten)
Software-Schwachstellen für die Sicherheitsanalyse keinen nennenswerten Nutzen für die
Sicherheitsanalyse: auch das zweite Element, das „Zielsystem“ mit der Perspektive der
Systemschwachstellen, muss für die weitere Betrachtung ausgeschlossen werden.
Die Elemente „Angreifer“ und „Zielsystem“ des Bedrohungsmodells liefern den Betreibern
leittechnischer Systeme – wie oben ausgeführt – keinerlei Fakten, die als Grundlage einer
Sicherheitsbeurteilung dienen können. Für eine Sicherheitsanalyse mit dem Ziel
Seite 39 von 262

reproduzierbarer, nachvollziehbarer und vergleichbarer Analyseergebnisse verbleibt lediglich

das letzte der drei Elemente des Bedrohungsmodells übrig: der Pfad vom Angreifer zum
Angriffsziel. Im Gegensatz zu den beiden verworfenen Elementen „Angreifer“ und
„Zielsystem (Schwachstellen)“, über die Betreiber keine Informationen haben, sind die
Zugangsmöglichkeiten bekannt. Sie lassen sich aufzählen und dokumentieren. An dieser
Stelle wird auf die Berücksichtigung von „Covert Channels“ verzichtet, da hierfür das
Zielsystem u.U. bereits manipuliert sein muss (Vorhandensein eines ‚covert channel
receiver’). Des Weiteren sollen nur Angriffsszenarien betrachtet werden, die im Rahmen
einer systematischen Erfassung möglicher Angriffsmodelle in Frage kommen (siehe 5.3).
Allerdings muss die Frage beantwortet werden, ob – im Vergleich zu Angreifer und

Zielsystem – der Angriffspfad überhaupt ein relevantes Element für die Analyse der IT-
Sicherheit leittechnischer Systeme darstellt. Die Fokussierung auf den Angriffspfad ist
berechtigt, da prinzipiell kein Angriff gegen SCADA-Systeme (oder andere
Computersysteme) möglich ist, solange keine Verbindung zwischen Angreifer und
Zielsystem besteht. Der Angriffspfad kann in Abhängigkeit von der Art des Angriffs und der
Art und Örtlichkeit der Zielanlage unterschiedliche Ausprägungen annehmen:
 physische und/oder logische Verbindung
 permanente oder temporäre Verbindung
 die Verbindung besteht synchron oder asynchron zum Angriffsverlauf
Zur Verdeutlichung der letzten Ausprägung sei auf die Angriffsvariante hingewiesen, in deren
Verlauf z.B. USB-Speicher im Eingangsbereich einer Zielanlage „verloren“ werden, in der –
leider berechtigten – Hoffnung, dass ein Finder den Speicher an die USB-Schnittstelle eines
Bürocomputers anschließt und die gespeicherte Schadsoftware sich in der Zielanlage
ausbreiten kann.
Im weiteren Verlauf, insbesondere im Rahmen der Herleitung einer neuen Analysemethode

in Kapitel 4.5, wird der Angriffspfad im Sinne einer physischen und/oder logischen
Verbindung aufgefasst, die der Durchführung des Angriffes dient.
Die Beurteilung der IT-Sicherheit leittechnischer Systeme muss folgende Angriffsvarianten,

(Zugangsvarianten) berücksichtigen:
1. Direkter Angriff über Netzwerke, an die das Zielsystem angeschlossen ist
2. Direkter Angriff mittels physischem Zugang zum Zielsystem
3. Indirekter Angriff auf das Zielsystem durch Nutzung von physischen

Systemschnittstellen
Seite 40 von 262

Die notwendige Beschreibung der Systemzugangsmöglichkeiten im Rahmen der

Sicherheitsanalyse berücksichtigt hierfür die nachfolgend aufgeführten Zugangstypen:
1. SCADA-Netzwerkstruktur
2. Physische Systemschnittstellen (Netzwerk, USB, Seriell, Parallel, CD/DVD,

Bluetooth, IrDA, etc.)
3. physischer Zugang zum Zielsystem
Auf die Berücksichtigung dieser Zugangstypen geht Kapitel 5.2 bei der Beschreibung der
neuen Analysemethode ein. Die Struktur des Leitsystems (Systemtopologie) stellt somit das
einzige Element des Bedrohungsmodells dar, für das der Betreiber über fundierte
Informationen verfügt. Neben den praktischen Erwägungen, dass über die potentiellen
Angreifer und deren Beziehung zum Zielsystem keine validen Aussagen möglich sind, ist mit
der Fokussierung auf den Angriffspfad ein methodischer Vorteil verknüpft: Annahmen und
Vermutungen – oder besser: Spekulationen – über Angreifer stellen keine Aussage über das
Zielsystem hinsichtlich dessen IT-Sicherheit, sondern eben Aussagen über die Angreifer dar.
Im Gegensatz dazu bilden Analyseergebnisse, die auf Fakten der SCADA-Topologie
beruhen, Aussagen zur IT-Sicherheit mit Zielsystembezug.
3.5 IT-Sicherheit als Systemeigenschaft
Im vorangegangenen Abschnitt wurde erkannt, dass die Elemente „Angreifer“ und

„Zielsystem“ keine objektiven und reproduzierbaren Fakten für die Beurteilung der IT-
Sicherheit liefern. Als zentraler Analyseansatz stellten sich die Zugangspfade zur
Ausnutzung von Systemschwachstellen heraus. Diese Sichtweise stellt eine grundsätzlichen
Perspektivenänderung der IT-Sicherheit von Leittechniksystemen dar: die Abkehr von
(unsicheren) externen Faktoren und die Fokussierung auf systemeigene Faktoren, die die IT-
Sicherheit beeinflussen. Es sei an dieser Stelle nochmals darauf hingewiesen, dass der
Betreiber in der Regel weder das Bedrohungspotential durch Angreifer kennt, noch einen
hinreichend vollständigen Überblick über die (meistens unbekannten) Softwares-
Schwachstellen seines Systems hat. Lediglich die Zugangspfade zum System liegen im
Bereich seiner Kontrolle.
Auf die Frage, wie Sicherheit als Systemeigenschaft von den verschiedenen individuellen
Systemteilen und -funktionen abhängt, gingen bereits (Dobson, et al., 2001) ein. Sie
Seite 41 von 262

erkannten, dass z.B. der Entwicklungsprozess das Auseinanderfallen der Sicherheit des
Gesamtsystems und der Sicherheit der einzelnen Systembestandteile hervorrufen kann.
IT-Sicherheit lässt sich somit als Systemeigenschaft auffassen, die nicht (ausschließlich) auf
der Implementierung individueller Systemfunktionen beruht, sondern das nach außen
wirksame Verhalten des Gesamtsystems beurteilt: das Ganze ist mehr als die Summe der
Teile (Gillils, 2013). Dieser Sachverhalt spiegelt sich später in einem Element der
vorgeschlagenen Sicherheitsmetrik wider (SACDA-Angriffsoberfläche, siehe Kapitel 6.5.1).
Aktuelle Standardisierungsbemühungen (ISA99) tragen dieser Sichtweise Rechnung.

Etablierte Prüfungen der Systemsicherheit ergänzen Systemprüfungen um neuartige Tests
der Robustheit gegen externe Einflüsse, wie z.B. Penetrationstests oder Schwachstellen-
Scans. Beispielsweise muss sich das System unter hohen Netzwerklasten oder bei
fehlerhaften Netzwerkprotokollpaketen bewähren. Diese Prüfungen verstehen das
Zielsystem als Einheit und untersuchen die Auswirkungen externer Einflüsse auf das
Systemverhalten.
Vor dem Hintergrund zielgerichteter Angriffe Externer gegen SCADA-Systeme definiert

(Eckert, 2008) IT-Sicherheit als Systemeigenschaft, die nur Systemzustände ohne
unautorisierten Informationsveränderung oder -gewinnung zulässt. Diese Definition
berücksichtigt keine Schutzmaßnahmen innerhalb des Zielsystems oder entlang potentieller
Zugangangspfade. Hier wird deutlich, dass ein Computersystem, das eine unbekannt hohe
Zahl von Schwachstellen unbekannter Schwere besitzt, trotzdem als „sicher“ gelten kann:
nämlich solange ein Angreifer keine Möglichkeit hat, sich physischen und/oder logischen
Zugang zum System zu verschaffen und die Schwachstellen missbräuchlich auszunutzen.
Nicht die Schwachstellen begründen die Unsicherheit eines Systems, sondern die
Möglichkeiten potentieller Angreifer diese Schwachstellen auszunutzen.
Um für die Unternehmensführung reproduzierbare und nachvollziehbare Ergebnisse

hinsichtlich der System-IT-Sicherheit bereit zu stellen, sollen subjektive Einschätzungen
vermieden und durch objektive Daten ersetzt werden: IT-Sicherheit als objektivierbare
Systemeigenschaft.
Exkurs: Sichere Rechnersysteme

An dieser Stelle soll zum Zweck der Themenabgrenzung kurz auf die Frage nach inhärent
sicheren Rechnersystemen eingegangen werden. Aufgrund der funktionalen Anforderungen
und den Interaktionen mit physischen Prozessen müssen leittechnisches Systeme vor allem
den Schutzzielen „Integrität“ und „Verfügbarkeit“ genügen. Die Erfüllung der
Seite 42 von 262

schutzzielbedingten Anforderungen streben die Hersteller im Rahmen des Systemdesign

und der Systemimplementierung an - insbesondere mittels hinreichender Softwarequalität
und einer widerstandsfähigen Systemarchitektur. Des Weiteren sind Maßnahmen zum
Schutz der Konfigurations- und Anlagendaten zu treffen. Da diese vorgenannten
Maßnahmen durch die Hersteller im Rahmen des Systementwicklungsprozesses zu
erbringen sind und in der Regel durch die Systemintegratoren und Betreiber nicht beeinflusst
werden können, bleibt die Diskussion der Eigenschaften ‚sicherer Rechnersysteme‘ in der
vorliegenden Arbeit unberücksichtigt
Allerdings können ‚sichere Systeme‘ in gleicher Weise durch die vorgeschlagene

Analysemethode behandelt werden. Wie zu zeigen sein wird, spiegeln sich die
Eigenschaften sicherer Systeme in den kritischen Angriffsszenarien, die gegen das System
ausgeführt werden können, wieder. Der Entwurf sicherer Systeme wird deshalb im weiteren
Verlauf dieser Arbeit nicht behandelt.
3.6 Extrakt der weiterführenden Ergebnisse
In diesem Kapitel 3 wurden folgende, für die weitere Beurteilung der IT-Sicherheit von Leit-
und Automatisierungssystemen wesentliche Aspekte kurz zusammengeführt.
 Fokussierung auf IT-Sicherheit (Security)
Zunächst diente die begriffliche Unterscheidung zwischen funktionaler Sicherheit (engl.:

safety) und IT-Sicherheit (engl.: security) der Abgrenzung im Rahmen der weiteren
Betrachtung: Der Fokus wird auf der Beurteilung der IT-Sicherheit liegen, d.h. von
Maßnahmen, die dem Schutz der SCADA-Systeme vor Angriffen aus der Systemumgebung
dienen. Trotz des inneren Zusammenhangs zwischen der IT-Sicherheit und der funktionalen
Sicherheit bleibt letztere im weiteren Verlauf der Betrachtungen unberücksichtigt.
 Primäre Schutzziele: Verfügbarkeit und Integrität
Leit- und Automatisierungssysteme dienen dem Zweck, verfahrenstechnische Prozesse

unter Kontrolle des Betriebspersonals und gemäß der gespeicherten Prozesslogik ablaufen
zu lassen. Der Ausfall eines solchen Systems zieht in der Regel wirtschaftlich nachteilige
Folgen für den Betreiber nach sich. Aufgrund möglicher physischer oder chemischer
Auswirkungen von Systemausfällen oder -fehlfunktionen können auch Schäden für
Menschen, Umwelt und die Anlage die Folge sein. Für die weitere Betrachtung wird deshalb
besonderes Augenmerk auf die Schutzziele „Verfügbarkeit“ und „Integrität“ der SCADA-
Seite 43 von 262

Systeme Wert gelegt. Andere Schutzziele, wie z.B. Vertraulichkeit (Confidentiality),

Nichtabstreitbarkeit (Non-repudiation) usw., bleiben unberücksichtigt.
 Sicherheitsanalysen: schwierige Beurteilungsgröße „IT-Sicherheit“
Die möglichen Konsequenzen für Umgebung von SCADA-Systemen im Falle von

Fehlfunktionen oder Ausfällen veranlasst die Betreiber, regelmäßig die IT-Sicherheit ihrer
Systeme zu überprüfen. Zur Beurteilung der Anlagen-IT-Sicherheit können die Betreiber
allerdings nicht auf eine messbare Größe „IT-Sicherheit“ bzw. eine handhabbare
„Messvorschrift“ zurückgreifen. Existierende Standards zur Beurteilung der Anlagen-IT-
Sicherheit weichen daher auf die Ersatzgröße „Risiko“ aus. Diese Größe ist unbefriedigend
hinsichtlich der zugrundeliegenden Daten und Fakten, wie auch den ableitbaren
Handlungsoptionen für den Anlagenbetreiber.
 Bedrohungen von Leit- und Automatisierungssystemen
Die weiteren Überlegungen hinsichtlich der IT-Sicherheit von SCADA-Systemen basieren auf
dem skizzierten, dreiteiligen Bedrohungsmodell:
 Angreifer
Die weitere Berücksichtigung der drei Einzelelemente des Bedrohungsmodells wurde

folgendermaßen hergeleitet:
 Verzicht auf Berücksichtigung des Elementes „Angreifer“
Für das Element „Angreifer“ liegen dem Betreiber der leittechnischen Anlage keine validen
Daten für eine auf Fakten basierte, reproduzierbare Ergebnisse liefernde Analysemethode
vor. Aus diesem Grund bleibt der Angreifer in der weiteren Betrachtung und Entwicklung
einer neuen Analysemethode ausgeklammert.
 Verzicht auf Berücksichtigung des Elementes „Zielsystem (Schwachstellen)“
Wie oben gezeigt, verbleiben ca. 66% aller Software-Fehler über die gesamte
Nutzungsdauer eines Leitsystems hinweg unkorrigiert. Die Analyse von (bekannten)
Software-Schwachstellen für die Sicherheitsanalyse liefert somit keinen nennenswerten
Nutzen. Deshalb bleibt das Element „Zielsystem“ mit der Perspektive der
Systemschwachstellen aus der weiteren Betrachtung ausgeschlossen.
 Fokussierung auf die Systemstruktur (Angriffspfad)
Seite 44 von 262

Als verbleibendes Element des Bedrohungsmodells erweist sich der Angriffspfad, d.h. die
physische und/oder logische Verbindung vom Angreifer zum Zielsystem. Die Struktur des
Leitsystems (Systemtopologie) muss dementsprechend im Rahmen der Sicherheitsanalyse
auf jene Pfade hin untersucht werden, über die ein Angreifer sich Zugang zum System
verschaffen und Schwachstellen des Systems ausnutzen kann (Angriffs- und
Ausführungspfad). Der Angriffspfad stellt das einzige Element des Bedrohungsmodells dar,
für das der Betreiber über fundierte Informationen verfügt.
 IT-Sicherheit als objektivierbare Systemeigenschaft
Die Beurteilung der IT-Sicherheit soll idealerweise auf Basis objektiver Fakten in einer
operativ handhabbaren Variablen resultieren. Die Auffassung von IT-Sicherheit als
Eigenschaft des Gesamtsystems soll in die Bildung dieser Größe einfließen. Schließlich
sollen die grundlegenden Faktoren dieser Größe dem Betreiber der Zielanlage verfügbar
sein und ausschließlich auf Fakten der SCADA-Topologie beruhen. Diese Voraussetzung
ermöglicht Aussagen zur IT-Sicherheit mit ausschließlichem Zielsystembezug als
Analyseergebnisse.
Diese Ergebnisse der vorangegangenen Abschnitte bilden die Grundlagen für die
nachfolgenden Betrachtungen zur Beurteilung der IT-Sicherheit von SCADA-Systemen.
Seite 45 von 262

Kapitel 4 Ansätze zur Beurteilung der IT-Sicherheit von Leit- und
4 Ansätze zur Beurteilung der IT-Sicherheit von Leit- und

4.1 Motivation
Zunächst stellt sich die Frage, ob und warum die IT-Sicherheit von Leit- und
Automatisierungssystemen überhaupt analysiert werden muss. Schließlich sind diese Art von
Systemen seit vielen Jahren im betrieblichen Einsatz (siehe Abbildung 3), während der Ruf
nach mehr IT-Sicherheit erst seit wenigen Jahren an Bedeutung gewinnt (~ 2008 / 2010).
 Veranlassung
Spätestens seit der medialen Aufmerksamkeit, die „Stuxnet“ zuteilwurde, kann kein
Unternehmensverantwortlicher behaupten, nicht gewusst zu haben, dass das Verursachen
physischer Schäden mittels SCADA-Systemen möglich ist. Als erster Schritt – auch zum
rechtlichen Eigenschutz der Unternehmensleitungen – ist die Betrachtung des Ist-Zustandes
unter Einbeziehung der jeweiligen Systemlieferanten unvermeidlich.
 Ursache
Als Zweites stellt sich die Frage, warum die IT-Sicherheit leittechnischer Systeme in den
zurückliegenden 5 … 8 Jahren in steigendem Maße an Bedeutung gewonnen hat. Die
Ursache dieses Bedeutungsgewinnes geht mit der Entwicklung der Leit- und
Automatisierungssysteme unter den maßgeblichen technologischen Trends einher (siehe
Kap. 2.2 Technologietrends). Wesentliche Treiber dieser technischen Entwicklung sind die
zunehmende Verwendung von Standardkomponenten (Betriebssysteme, Datenbanken,
Applikationen, Netzwerkprotokolle und Schnittstellen). Das für Angriffe auf SCADA-Systeme
notwendige Wissen ist durch die Verwendung dieser Standardkomponenten in weiten
Personenkreisen vorhanden und darüber hinaus erleichtert das Internet den Zugang zu
Fachinformationen ganz wesentlich. Des Weiteren trägt die Vernetzung von leittechnischen
Systemen und sogenannten Geschäftsanwendungen im Intranet der Betreiberfirmen zur
Steigerung des Angriffsrisikos bei. Schließlich erhöht auch die direkte oder indirekte
Anbindung von SCADA-Systemen an das Internet das Gefährdungsrisiko der
Leittechnikanlagen.
 Ziele
Nach der Klärung des „Ob“ und „Warum“ von Analysen zur SCADA-IT-Sicherheit rücken die
mit den Analysen angestrebten Ziele in den Fokus der Betrachtung: die Analysen sollen
Seite 46 von 262

primär Hilfestellung beim Gewährleisten der betrieblichen Anlagensicherheit (hier im Sinne

von „Safety“) geben. Aufgrund des physischen und finanziellen Schadenspotentials
angegriffener SCADA-Systeme steht die Vermeidung von Schäden für die
Systemumgebung (Menschen, Anlagen, Umwelt, Finanzen, ideelle Werte /
Unternehmensruf) im Vordergrund. IT-Sicherheitsanalysen sollen Angriffsmöglichkeiten
aufzeigen, um geeignete Schutzmaßnahmen ergreifen zu können.
 Verantwortlichkeit
Mit der Betriebsverantwortung für den störungsfreien Ablauf verfahrenstechnischer Prozesse

obliegt dem Betreiber die Verantwortung für die IT-Sicherheit der Leittechniksysteme. Im
Rahmen der Entwicklung, kundenspezifischen Projektierung und Inbetriebnahme der
Leittechniksysteme steht auch der Systemlieferant vor der Aufgabe, die IT-Sicherheit
ausgelieferter Systeme zu analysieren. Insbesondere aufgrund fehlender Informationen zu
kommerziellen Aspekten des Anlagenbetriebs, der physischen und organisatorischen
Randbedingungen muss sich der Lieferant in der Regel auf die Berücksichtigung der
Leittechniksystemeigenschaften beschränken.
 Ergebnisse
Die abschließende Frage ist, welche Ergebnisse aus den Analysen der SCADA-IT-Sicherheit
werden erwartet. Aus Betreibersicht müssen die Ergebnisse zwei Aspekte adressieren:
a) Aufdeckung von Systemschwachstellen, die Angriffsmöglichkeiten gegen die

Leittechniksysteme eröffnen und
b) Handlungsoptionen zur Verbesserung des Schutzes vor Angriffen gegen die

Leittechniksysteme aufzeigen
Neben der Frage nach den Inhalten der Analyseergebnisse stellt sich auch die Frage, in
welcher Form die Ergebnisse darzustellen sind, um anschließend in die betrieblichen
Arbeitsabläufe einzufließen. Aufgrund der ingenieurmäßigen Prägung der Zielgruppen im
Bereich der Leittechnikverantwortlichen, bietet es sich an, die Ergebnisse in Form von
Kennzahlen darzustellen. Auch für den Vergleich von Ergebnissen aus verschiedenen, in
zeitlichen Abständen vorgenommenen Analysen ist die Überführung der Ergebnisse in
geeignete Metriken vorteilhaft. Insbesondere im Unternehmensmanagement werden
Metriken zur Unternehmenssteuerung bevorzugt.
In den nächsten Abschnitten dieses Kapitels sollen nun typische Analysemethoden

betrachtet und vor dem Hintergrund der Aspekte dieser Motivation kritisiert werden.
Seite 47 von 262

4.2 Überblick typischer Analysemethoden
4.2.1 Allgemeine Anmerkungen
Die Beurteilung der IT-Sicherheit industrieller Automatisierungssysteme steht vor folgenden

Herausforderungen:
1) Das Sicherheitsbewusstsein der Betreiber ist teilweise unzureichend ausgeprägt.

Vielfach schätzen Betreiber ihr spezifisches Risiko, Ziel eines Angriffs zu werden, als
vernachlässigbar ein. Als Gründe werden angeführt:
 “Unsere Produktionssysteme haben keine externen Zugangsmöglichkeiten“
 “Unser System ist sicher, weil es für Externe unmöglich wäre, es zu verstehen”
 “Wir sind wahrscheinlich kein Angriffsziel, weil wir nicht wichtig oder interessant
genug sind, um Hacker auf uns aufmerksam zu machen”
 “Wir hatten noch nie ein Problem. Es gab kein Eindringen oder Stören unseres
Produktionsnetzwerkes”
 “Es ist noch nie passiert, also ist es unwahrscheinlich. Ich glaube nicht, dass es
passieren wird”
 “Wir können die Ausgaben und den Personalaufwand nicht rechtfertigen“
(Dickman, 2008)
2) Schutzvorkehrungen, wie z.B. Firewalls gegen das Internet,

Kommunikationsverschlüsselung, physischer Zugangsschutz etc. hat keine oder nur
geringe Wirkung gegen Innentäter, die diese Vorkehrungen umgehen können. Es wird
geschätzt, dass ca. 40% der Sicherheitsvorfälle zu Lasten interner Angreifer gehen.
(Richardson, 2007)
3) Qualifizierte statistische Daten über Angriffe gegen Leitsysteme liegen nicht vor.
 Ergebnisse von Risikoanalysen, beispielsweise auf Basis des ALE-Ansatzes

(Annual Loss Expectancy), sind nur bedingt tauglich oder komplett unbrauchbar
(Berinato, 2005): „The numbers are too poor even to lie with."
 Nach eigenen, nicht repräsentativen Erfahrungen des Verfassers installieren

heute Betreiber von kritischen Infrastrukturen in steigendem Maße
Schutzeinrichtungen, wie z.B. Firewalls. Ein adäquates Betriebs- und
Seite 48 von 262

Servicemodell für diese Komponenten fehlt jedoch weitgehend: selbst die

Erkennung von Angriffen durch Firewalls würde das Personal vielfach nicht
erkennen, da Logdateien keiner (regelmäßigen) Analyse unterliegen. Selbst im
Falle einer Veröffentlichung statistischer Daten keine Gründe, wie z.B.
Geheimhaltung aus Gründen der nationalen Sicherheit / des Unternehmensrufes
in der Öffentlichkeit, sonstige unternehmensspezifische Gründe,
entgegenstünden: viele Unternehmen würden Angriffe auf ihre Leitsysteme oder
Produktionsnetze derzeit überhaupt nicht erkennen.
4) Die Betreiber verfügen über keine Methode zur Beurteilung der IT-Sicherheit von
SCADA-Systemen.
4.2.2 Ansätze zur Beurteilung der IT-Sicherheit
Gängige Methoden zur Beurteilung der IT-Sicherheit von SCADA-Systemen lassen sich in
folgende Kategorien unterteilen:
 Metriken
 Risikoanalysen
Metriken leiten aus zusammengetragenen Informationen Kennzahlen über den aktuellen

Zustand der Leitsysteme ab. Die Fortschreibung dieser Kennzahlen soll die zeitliche
Entwicklung des Sicherheitszustandes der Anlage darstellen.
Risikoanalysen versuchen, potentielle Schäden im Falle von Cyber-Angriffen abzuschätzen.
Im Rahmen einer Studie über IT-Sicherheit in britischen Unternehmen des Sektors der
kritischen Infrastruktur wurden bedenkliche Ergebnisse zutage gefördert (Cornish, et al.,
2011):
Das Bewusstsein der Betreiber kritischer Infrastrukturen gegenüber der IT-Sicherheit sowie
den damit verknüpften notwendigen Handlungsweisen scheint dem Bedrohungspotential der
Anlagen nicht angemessen zu sein.
Hinsichtlich der Wahrnehmung und Sensibilität angesichts möglicher Bedrohungen, scheint

es kein oder nur geringes Bewusstsein dafür zu geben, was eine Systemschwachstelle ist
oder welche schwerwiegenden Auswirkungen Schwachstellen haben können. Im
Wesentlichen existiert keine Vorstellung über die Natur und die Schwere dieses Problems,
obwohl die Cyber-Sicherheit eine Herausforderung für den privaten und öffentlichen Sektor
Seite 49 von 262

darstellt. Grundsätzlich besteht eine mangelnde Bereitschaft, verlässliche Daten

bereitzustellen. Neben dem Mangel an verfügbaren Daten zur IT-Sicherheit in kritischen
Infrastrukturen fehlt auch ein einheitlicher und systematischer Ansatz für ein geeignetes
Risikomanagement in den Unternehmen.
Für die Handlungsweise werden trotz prinzipieller Unsicherheit mangels Daten

Empfehlungen ausgesprochen, die sowohl auf die Beurteilung der IT-Sicherheit als auch auf
die Ableitung konkreter Handlungsoptionen zielen:
 Die Betrachtung und Analyse der IT-Sicherheit als einen wesentlichen Bestandteil
in die Risikostrategie des Unternehmens integrieren.
 Umfassende Risikoanalysen durchführen, auch wenn sich offensichtlich ‘unknown

unknowns’ nicht vermeiden lassen.
 Die Entwicklung flexibler Reaktionspläne und -maßnahmen, die das Unternehmen

vor strategischen Erschütterungen schützen und die allgemeine
Widerstandsfähigkeit gegen Cyber-Angriffe steigern sollen.
 Unternehmen müssen in die Zukunft blicken und potentielle Bedrohungen

identifizieren, um rechtzeitig vorbeugende Reaktionsmaßnahmen für diese
Risiken zu entwickeln.
Vor dem Hintergrund der Ergebnisse potentieller Software-Schwachstellen in

Betriebssystemen (siehe Anhang) ist die Frage offensichtlich, wie Betreiber kritischer
Infrastrukturen gegen die Vielzahl dieser Schwachstellen vorbeugende Maßnahmen
ergreifen sollen.
(Cornish, et al., 2011) verweisen auf die Notwendigkeit, uneinheitliche Sichtweisen auf die
IT-Sicherheit innerhalb von Unternehmen zu beseitigen und die Grundlagen für effiziente
Handlungsweisen zu schaffen. Als Maßnahmen werden u.a. die Verbesserung des
Bewusstseins gegenüber der IT-Sicherheit sowie eine umfassender Ansatz zur Analyse des
IT-Security-Status empfohlen. Eine angemessene Beurteilung der IT-Sicherheit
berücksichtigt die drei Aspekte Bedrohung, Wirkung und Schwachstelle in ausgewogener
Weise. Eine Über- oder Unterschätzung einer der drei Komponenten hat fehlerhafte
Schlussfolgerungen der restlichen Komponenten zur Folge. Beispielsweise kann die
Schwierigkeit, die Wirkung eines Cyber-Angriffes richtig abzuschätzen, dazu führen, dass
das Risikomanagement einer Organisation fehlgeleitet wird. Insbesondere soll die
Seite 50 von 262

Beurteilung der IT-Sicherheit weniger Augenmerk auf den Zustand von Einzelaspekte
(„Virenschutz ist aktuell“) legen als auf die Konsequenzen von Maßnahmen: Verbessert sich
das Schutzniveau oder verschiebt sich der Fokus der Bedrohung auf einen anderen Teil der
Organisation?
An dieser Stelle wird jedoch eine wesentliche Frage im Rahmen der Sicherheitsdiskussion
aufgeworfen: Was bedeutet „Verbesserung des Schutzniveaus“? Diese Frage soll im
weiteren Verlauf der vorliegenden Arbeit behandelt und beantwortet werden.
Hinsichtlich der IT-Sicherheit für Leit- und Automatisierungssysteme erkennen (Cornish, et

al., 2011) das Fehlen einer Strategie, um Bedrohungen gegen die SCADA-Systeme
wichtiger Versorgungseinrichtungen zu begegnen.
4.2.3 IT-Security-Metriken für SCADA-Systeme
Um den Status der IT-Sicherheit im Rahmen des Systembetriebes verbessern zu können,

sollen Sicherheitsanalysen Ergebnisse liefern, die in Handlungsoptionen für die betriebliche
Praxis münden. Diesem Zweck dienen Kennzahlen, die die IT-Sicherheit hinreichend genau
abbilden sollen. Die Kennzahlen lassen sich in die Kategorien „metrics“ (Kennzahl, Metrik)
und „measurements“ (Messung) unterteilen. Messungen stellen objektiv messbare Rohdaten
dar. Metriken hingegen sind objektive oder subjektive Interpretationen der Messdaten.
(Payne, 2006)
Daraus wird bereits ersichtlich, dass Metrik-basierte Beurteilungen subjektiven Einflüssen

unterliegen. Diese subjektiven Einflüsse ergeben sich durch die an der Analyse beteiligten
Personen bzw. der Zusammensetzung des an der Analyse beteiligten Personenkreises. Die
subjektiven Einschätzungen, die in eine Analyse einfließen, führen dazu, dass die Analysen
nur bedingt reproduzierbare bzw. nachvollziehbare Ergebnisse liefern (können).
(Juneja, et al., 2011) unterscheiden Metriken und Messungen in technischer Sicht:
Messungen stellen singuläre, zeitlich eindeutige Sichten auf spezifische, diskrete Faktoren
dar. Demgegenüber erzeugen Metriken auf der Basis von Messungen und vorab definierten
Vergleichsdaten Kennzahlen. Messungen werden aus Zählvorgängen abgeleitet, während
Metriken im Rahmen von Analysen entstehen und folgenden Aufgaben dienen können:
 Risikomanagement
 Audits & Compliance-Untersuchungen
Seite 51 von 262

 Betriebsprozesse zum Zweck der IT-Sicherheit
Metriken stellen Werkzeuge dar, die Entscheidungsfindungen bzw. Managementaufgaben

unterstützen sollen. Des Weiteren dienen sie dem Zweck, die Leistungsfähigkeit und das
Verantwortungsbewusstsein des Systembetriebs zu erhöhen. Dazu gehören die Sammlung,
Analyse und Dokumentation relevanter Betriebsdaten. Das Ziel der Kontrolle relevanter
Anlagenaktivitäten ist, diese durch geeignete Maßnahmen zu verbessern - basierend auf
beobachtbaren Messungen.
Security-Metriken lassen sich in verschiedene Kategorien klassifizieren (Savolo, 2007):
 Quantitative vs. qualitative Metriken
 Grad der Objektivität bzw. Subjektivität der Metriken
 Direkte vs. indirekte Metriken
 Statische vs. dynamische Metriken
 Absolute vs. relative Metriken
Darüber hinaus schlägt (Savolo, 2007) eine hierarchische Taxonomie von Metriken vor:
 Security-Metriken für die Geschäftsprozessebene
 Security-Metriken für das Informationssicherheitsmanagement in einer

Organisation
 Sicherheits-, Zuverlässigkeits- und Vertraulichkeits-Metriken für Produkte,

Systeme und Dienste
(Berinato, 2005) führt folgende, sehr technische IT-Metriken zur Beurteilung der IT-Sicherheit
auf:
 Baseline Defences Coverage
Als Grundlage der Sicherheitsbeurteilung soll ein Netzwerk auf bekannte und
unbekannte Netzteilnehmer überprüft werden. Insbesondere sollen
Konfigurationsdaten und Logdateien von Virenschutzlösungen, Firewall und
anderen Schutzeinrichtungen systematisch analysiert werden.
 Patch Latency
‚Patch latency‘ wird als Zeitspanne zwischen der Veröffentlichung und der
erfolgreichen Installation eines Patches in den Zielsystemen verstanden
Seite 52 von 262

 Password Strength
Durchschnittliche, geschätzte Zeit, die zum Brechen eines Passworts benötigt

wird
 Platform Compliance Scores
Prüfung von Konfigurationsversäumnissen, die häufig übersehen werden, wie z.B.

offene aber unbenutzte Netzwerk-Ports, Systeme, die (unbeabsichtigt) von einem
zu großen Benutzerkreis genutzt werden, unveränderte Standard-
Benutzerberechtigungen (Benutzername und/oder Passwort) usw.
 Legitimate E-Mail Traffic Analysis
Zulässige E-Mail-Verkehrsanalyse umfasst Metrikdaten, wie z.B. eingehendes

und ausgehendes Verkehrsvolumen oder die Größe aus- und eingehender E-
Mails sowie die Analyse des Verkehrsflusses mit externen Mail-Partnern.
Es ist offensichtlich, dass diese Kennzahlen für Unternehmens-IT-Umgebungen konzipiert

wurden und für SCADA-Systeme nur bedingt tauglich sind und ggf. angepasst werden
müssen.
Einen Überblick über verschiedene Metriken zur Beurteilung der Sicherheit in IT-Systemen
geben (Anbalagan, et al., 2009). Die Arbeit zielt auf „Security“ im Kontext des „software
reliability engineering“. Ungeachtet der Tatsache, dass diese Zielsetzung für Betreiber oder
Lieferanten nur einen bedingt nutzbaren Ansatz darstellt, ist es sinnvoll, die vorgestellten
Metriken im Hinblick auf die Brauchbarkeit im SCADA-Kontext zu betrachten:
 MTTPR
‚Mean Time To Problem Report‘ (MTTPR) definiert den Durchschnittswert

zwischen dem Auftreten eines Problems (Sicherheitsereignis) und der Meldung in
Form eines entsprechenden Berichts innerhalb eines definierten Zeitraumes (z.B.
Kalenderjahr).
 MTTPE
‚Mean Time To Problem Exploit‘ (MTTPE) definiert die durchschnittliche Zeit

zwischen Ereignissen innerhalb eines definierten Zeitraumes (z.B. Kalenderjahr).
Diese Kennzahl ist vergleichbar mit ‚Mean Time Between Failures‘ (MTBF), die
die durchschnittliche Zeit angibt, die ein System ohne Fehler arbeitet.
Seite 53 von 262

 MTTPC
‚Mean Time To Problem Correction‘ (MTTPC) definiert die durchschnittliche

Zeitdauer für eine Problembeseitigung innerhalb eines betrachteten Zeitraumes.
Diese Kennzahl ist vergleichbar mit ‚Mean Time To Repair‘ (MTTR), die die
durchschnittliche Zeit angibt, um ein System nach einer Störung zu reparieren.
MTTPC erlaubt eine Aussage hinsichtlich der Wartbarkeit einer Komponente.
 System Usage
Die ‚System usage‘ umfasst mehrere Parameter: beispielsweise wird die Anzahl
der in Betrieb befindlichen Systeme während eines betrachteten angegeben, wie
viele davon angegriffen wurden und wie hoch ist die durchschnittliche System-
Unverfügbarkeit ist usw.
 Rates
Die erfassten Werte der o.g. Kennzahlen lassen sich auch auf verschiedene
Zeiträume normalisieren, wie z.B. definierte Kalenderzeiträume oder die
Zeiträume der Systembetriebszeit.
Fazit:
Die obigen Beispiele verschiedener Autoren zeigen, dass kein Kennzahlensystem existiert,
das für die Anwendung auf Leittechniksysteme hinreichend etabliert ist und in der
betrieblichen Praxis Anerkennung gefunden hat sowie in der Lage ist, reproduzierbare
Ergebnisse ohne subjektive Einflüsse zu liefern.
4.2.4 Risikoanalysen für SCADA-Systeme
Das Risikomanagement wird in der Literatur als Prozess aufgefasst, in dem kritische
Anlagewertgegenstände („assets“) identifiziert und mit einem Unternehmenswert versehen
werden. Anschließend folgen die Abschätzung der Wahrscheinlichkeit eines
Sicherheitsvorfalles und die Ableitung des Schadenspotentials (Kaeo, 2004 S. 295ff). Als
wesentliche Schwachpunkte dieser Methode gelten fehlende Anhaltspunkte über die
potentiellen Angreifer gegen ein Unternehmen bzw. Organisation sowie die Schwierigkeit,
die den Systemen zugeordneten Unternehmenswerte objektiv zu bestimmen.
Seite 54 von 262

Der Übergang von subjektiven Einschätzungen zu validen statistischen Daten stellt die
Grundlage jeder Risikoanalyse zur Beurteilung der IT-Sicherheit dar. (Baker, et al., 2002)
beschreiben quantitative Methoden zur Risikobeurteilung als systematisch, wiederholbar und
auf objektiven Messungen basierend. Besondere Bedeutung wird der statistischen Validität
beigemessen.
Die Literatur zum Thema „Risikoanalyse“ lässt sich in zwei Kategorien einteilen: Zum einen
gibt es methodische Ansätze, die auf Basis statistischer Daten valide Ergebnisse zum
Risikopotential eines Systems oder einer Anlage ableiten. Als Beispiel hierfür sei (Haimes,
2009) genannt. Eine andere Gruppe von Beiträgen versucht, in praktischen Ansätzen das
Fehlen statistischer Daten zu kompensieren.
Nachfolgend sollen einige technische bzw. betriebswirtschaftliche Ansätze zur Risikoanalyse

skizziert werden, um typische Vorgehensweisen in Unternehmen zu verdeutlichen.
Technische geprägte Ansätze der Risikoanalyse
Wie oben erwähnt, sollen die Ergebnisse von Sicherheitsanalysen Eingang in das
unternehmensweite Risikomanagements finden. Risikomanagement wird als Kombination
verschiedener Teilschritte zur Bestimmung der Wahrscheinlichkeit von Sicherheitsvorfällen
aufgefasst. Trotz des Fehlens faktenbasierter Aussagen soll die IT-Sicherheit der SCADA-
Systeme als Bestandteil in das Risikomanagement des Unternehmens integriert werden. Die
Teilschritte benennt (Kaeo, 2004 S. 295 ff):
 Identifikation der relevanten Vermögenswerte (assets)
 Zuordnung eines Wertes für potentielle Vermögensschäden
 Bestimmung der Wahrscheinlichkeit eines Angriffes
Die Schwachpunkte dieser Methode benennt der Autor wie folgt:
 Keine Kenntnisse hinsichtlich der möglichen Angreifer der betrachteten

Organisation
 Die Zuordnung von Werten potentieller Vermögensschäden auf relevante

Vermögenswerte des Unternehmens ist ein äußerst subjektiv geprägter Prozess
Ungeachtet dieser Defizite schlägt der Autor eine Mischung aus qualitativer und quantitativer
Methode zur Beurteilung von Risiken vor, die zum Zwecke der Darstellung typischer
Vorgehensweisen bei Risikoanalysen kurz skizziert werden soll.
Seite 55 von 262

Im Rahmen einer „einfachen Risikoberechnung“ werden Eintrittswahrscheinlichkeiten von

Bedrohungen (Stufen = 1, 2, 3) mit den erwarteten Verlusten (Stufen = 1, 2, 3) aus einer
Bedrohung multipliziert. Das Risiko ergibt sich daraus in den Stufen = 1 ... 9. In einer
spezielleren Form versucht der Autor Risiken einzelner Netzwerksegmente zu bestimmen.
Ausgehend von (subjektiven) Werten für die Schutzziele Verfügbarkeit, Integrität und
Vertraulichkeit der verschiedenen Segmente soll das relative Risiko mittels verschiedener
Hilfsgrößen wie „network importance“, „Prevent an occurrence“ und „prevent degradation“
berechnet werden.
Die Bestimmung der Eintrittswahrscheinlichkeiten sowie die Abschätzung der erwarteten

Verluste haben gemein, dass sie auf subjektiven Einschätzung ( Stufen = 1, 2, 3) beruhen.
An dieser Stelle sei auf (Schneier, 2007) verwiesen, der die Genauigkeit und Gültigkeit
subjektiver menschlicher Einschätzungen von Risiken untersucht.
Aus den vorgenannten Gründen sollte von subjektiven Einschätzungen zu validen

statistischen Daten übergegangen werden. Statistische Daten stellen die Grundlage jeder
Risikoanalyse zur Beurteilung der IT-Sicherheit dar. Quantitative Methoden sind
systematisch, wiederholbar und basieren auf objektiven Messungen. Außerdem kann die
statistische Gültigkeit überprüft werden. Allerdings erfordern statistische Daten erhebliche
Kenntnisse hinsichtlich der Auswirkungen physischer Phänomene auf die technischen
Systeme der (kritischen) Infrastrukturen. Die große räumliche Ausdehnung und die
Komplexität von Infrastruktursystemen sowie ihre gegenseitigen Abhängigkeiten
beschränken derzeit die Anwendung quantitativer Methoden. Erschwerend kommt hinzu,
dass keine umfassenden Infrastruktur-Datenbanken existieren, die die notwendigen
statistischen Daten bereitstellen könnten. Zwar gibt es eine Reihe von Datenbanken bzw.
Informationsquellen mit Daten zu Infrastrukturen, einschließlich GIS-Datenbanken, jedoch
sind diese Systeme weder koordiniert noch konsistent. Anzahl und Inhalt von
Informationsquellen zu (US-) Infrastrukturen sind nicht vollständig bekannt. Einige
Datenquellen wurden kürzlich von Regierungs-Web-Seiten wieder entfernt, während
vermutlich manche Datenbanken aufgrund nationaler Interessen erst gar nicht veröffentlicht
wurden. Desgleichen sind keine Modellierungswerkzeuge für die Infrastruktursysteme
vorhanden. Quantitative Methoden zur Risikobeurteilung sind deshalb praktisch nicht
möglich (Baker, et al., 2002).
Neben den notwendigen Basisdaten für sicherheits-orientierte Risikoanalysen fehlen auch

die Prozesse um belastbare Ergebnisse zu erhalten. Aufgrund der Größe, Komplexität und
Verzahnung von Infrastruktursystemen können heutzutage nur qualitative Prozesse
Seite 56 von 262

umgesetzt werden. Gerade deshalb sollten solche Prozesse soweit als möglich durch Fakten
und wissenschaftliche Werkzeuge unterstützt und geführt werden. Im Laufe der Zeit sollten
sich die Prozesse im Sinne einer inhaltlichen Konsistenz annähern und zunehmend
quantitativen Charakter annehmen – obwohl die Aufgabenstellung äußerst komplex und es
fraglich ist, ob jemals ein vollständig quantitativer Prozess entstehen wird. Ungeachtet der
gewählten Methodenansätze müssen die Werkzeuge und Modelle einer Validierung
unterzogen werden, um aussagekräftige Ergebnisse zu liefern (Baker, et al., 2002).
Als Beispiel für Ansätze, die das Fehlen statistischer Daten zu kompensieren versuchen, sei
nachfolgende Methodik zur Risikoreduzierung bei kleinen SCADA-Systemen beschrieben.
Der Ansatz geht von der Annahme aus, dass das Risiko eines SCADA-Systems proportional
zur notwendigen Zeit eines erfolgreichen Angriffes ist. Die vorgeschlagene Methode
(McQuee, et al., 2006) ist wie folgt strukturiert:
 Schritt 1. Bestimme die betrachtete Systemkonfiguration
 Schritt 2. Identifiziere anwendbare Aspekte des quantitativen Risikomodells
 Schritt 3. Identifiziere und gewichte die Sicherheitsanforderungen der

primären Angriffsziele
 Schritt 4. Identifiziere Systemschwachstellen
 Schritt 5. Kategorisiere Systemschwachstellen in jeder Komponente nach Art

des möglichen Kompromittieren
 Schritt 6. Schätze die notwendige Zeit für einen Angriff für jede Komponente
ab
 Schritt 7. Erzeuge die Kompromitierungsgraphen und Angriffspfade
 Schritt 8. Suche den/die bestimmenden Angriffspfad(e)
 Schritt 9. Wiederhole die Schrittes 3–8 für das Basissystem und erweiterte
Systeme
 Schritt 10. Schätze die Reduzierung des Risikos ab
Für den abschließenden Schritt zur Abschätzung der Reduktion des Risikos schlagen die
Autoren vor, die sich ergebende Verlängerung der Kennzahl ‚time-to-compromise’ als
zentrale Kennziffer zu verwenden.
Auch in diesem Analyseansatz wird deutlich, dass die unsichere Zielgröße „Risiko“ ersetzt
wird durch Rückgriffe auf Einzeldaten, die allerdings genauso unsicher bzw. wenig belastbar
Seite 57 von 262

und hochgradig subjektiv sind. Gerade am Beispiel der Größe ‚time-to-compromise’, als der
erforderlichen Zeit für einen erfolgreichen Angriff wird der subjektive Einfluss der
beurteilenden Personen besonders deutlich: Besteht der Kreis der Auditoren aus Personen,
deren Kenntnisse in Sachen IT-Sicherheit – und hier insbesondere: Hacking – gering ist, so
wird der Zeitaufwand wohl eher als „hoch“ eingeschätzt. Dies ergibt sich aus der subjektiven
Einschätzung unerfahrener Personen, die sich vorstellen, selbst einen solchen Angriff
durchführen zu müssen. Demgegenüber schätzen in Sachen „Hacking“ geschulte Personen
den Zeitaufwand für die jeweiligen Angriffsszenarien deutlich geringer ein – in Kenntnis der
eigenen Fähigkeiten und Erfahrungen. Der subjektive Einfluss auf die Analyseergebnisse ist
offensichtlich.
Betriebswirtschaftlich geprägte Ansätze der Risikoanalyse
Im Gegensatz zu den oben geschilderten eher technisch orientierten Verfahren zur

Risikoabschätzung lässt sich aber auch eine betriebswirtschaftlich geprägte Sichtweise
anwenden.
Für eine betriebswirtschaftliche Betrachtung der Informationssicherheit ist es notwendig,

potentielle Risiken möglichst vollständig zu erfassen und - soweit als möglich - adäquat zu
quantifizieren. Des Weiteren muss die Risikoabschätzung auch die Kosten sowie die
Wirksamkeit von Schutzmaßnahmen berücksichtigen (Fox, 2011).
Ziel der Risikoquantifizierung ist die Ableitung einer einfachen Bewertung des erreichten
Sicherheitsniveaus: Das Niveau gilt als angemessen, wenn alle nicht-akzeptablen Risiken
durch geeignete Sicherheitsmaßnahmen ausgeschlossen sind und alle verbleibenden
Risiken durch passende Maßnahmen in ihren Auswirkungen begrenzt werden.
Die Anwendung dieser Methode stößt in der Praxis allerdings auf praktische Probleme:
In vielen Fällen ist eine hinreichend präzise Quantifizierung der betrieblichen Risiken, die
sich aus dem Betrieb leittechnischer Anlagen ergeben, nicht möglich. Hinsichtlich der Frage,
wie wahrscheinlich ein (erstmaliger) Cyber-Angriff gegen ein SCADA-System eines
Betriebes ist, kann z.B. keine faktenbasierte Antwort gegeben werden: es ist das Problem,
die Eintrittswahrscheinlichkeit eines „Schwarzen Schwans“ zu bestimmen (siehe (Taleb,
2012)).
Nachfolgend seien einige betriebswirtschaftlich geprägte Ansätze zur Risikoanalyse skizziert:
Seite 58 von 262

Annualized Loss Expectancy (ALE)
Als erster betriebswirtschaftlicher Ansatz zur Risikoeinschätzung wird die Bestimmung der
Größe „Annual Loss Expectancy” (ALE) betrachtet (Hayden, 2010). Die Formel zur
Bestimmung des erwarteten Verlustes ergibt sich aus der Formel:
ALE = L * P
mit ALE = erwarteter jährlicher Verlust [€]
L= finanzielle Höhe des Schadens [€]
P= Eintrittswahrscheinlichkeit des Schadens [%]
Methodische Schwächen dieser Methode ergeben sich aus Betrachtung eines einzelnen
Risikos. Das bedeutet für die praktische Anwendung, dass alle betrieblichen Risiken
voneinander getrennt werden müssen und somit alle Bedrohungen und entsprechende
Gegenmaßnahmen einer isolierten Analyse zu unterziehen sind. Das ALE-Modell impliziert
die gegenseitige Unabhängigkeit einzelner Bedrohungen und Gegenmaßnahmen. Das ist in
der Praxis jedoch in den meisten Fällen eine grobe Vereinfachung. Darüber hinaus
berücksichtigt das ALE-Modell keine kumulativen Effekte: die Einzelrisiken werden einfach
addiert (Fox, 2011). Und nicht zuletzt gewichtet das ALE-Modell nicht, ob es sich um einen
großen Schaden mit geringer Eintrittswahrscheinlichkeit oder einen geringen Schäden mit
hoher Eintrittswahrscheinlichkeit handelt. Während sich letztere meist sehr gut kontrollieren
lassen, können erstere aber existenzbedrohend sein und ihr Eintritt sollte daher in jedem Fall
durch geeignete Maßnahmen verhindert werden.
Return on Security Investment (ROSI)
Ein weiteres betriebswirtschaftliches Model zur Risikobetrachtung stellt der ROSI-Ansatz dar,
der auf der Berechnung eines „Return on Security Investment“ (ROSI) beruht (Bourgue,
2012).
Diesem Modell liegt die Überlegung zugrunde, dass jede wirksame Sicherheitsinvestition (SI)
entweder die Eintrittswahrscheinlichkeit (P) oder die Höhe eines bestimmten Schadens (L)
reduziert. Diese Reduktion senkt den erwarteten Schaden (engl. „Annual Loss Expectancy”,
ALE). Der „Gewinn“ einer Sicherheitsmaßnahme ergibt sich damit aus der Verringerung
dieses Erwartungswertes abzüglich der Gesamtkosten der ergriffenen Maßnahme (TCOSI),
und die Kennzahl ROSISI als Quotient aus Gewinn und Kosten. In einem ersten Schritt
berechnet sich der neue Erwartungswert für den potentiellen Schaden aus:
Seite 59 von 262

ALEneu = Lneu • Pneu
mit ALEneu = erwarteter jährlicher Verlust nach einer durchgeführten
Sicherheitsinvestition [€]
Lneu = erwarteter Schaden nach einer durchgeführten Sicherheitsinvestition [€]
Pneu = Eintrittswahrscheinlichkeit nach einer durchgeführten
Sicherheitsinvestition [%]
Der „Gewinn“ (RSI) aus der getätigten Sicherheitsinvestition lässt sich nach folgender Formel
bestimmen:
RSI = ALEalt – ALEneu – TCOSI
mit ALEneu = erwarteter jährlicher Verlust nach einer durchgeführten
Sicherheitsinvestition [€]
ALEalt = erwarteter jährlicher Verlust vor einer Sicherheitsinvestition [€]
TCOSI = Betrag der Sicherheitsinvestition [€]
Schließlich folgt der relative Ertrag aus der Sicherheitsinvestition aus:
ROSISI = RSI / TCOSI
Leider taugt auch dieser Ansatz nur bedingt für eine Aussage hinsichtlich des Risikos eines
Cyber-Angriffs. Der rechnerische Gewinn aus der Sicherheitsinvestition resultiert in einer
Reduzierung des operativen Betriebsrisikos, d.h. eines Erwartungswertes für die Kosten, die
sich aus Sicherheitsvorfällen ergeben. Ob durch die Sicherheitsinvestition tatsächlich
Einsparungen erzielt werden, lässt sich selbst ex-post nicht zuverlässig feststellen: Es ist
äußerst schwierig zu klären, ob ein Angriff aufgrund der Sicherheitsmaßnahmen nicht
stattfand oder ob überhaupt kein Angriff erfolgte.
(Fox, 2011) sieht in den der Methode zugrunde liegenden Erwartungswerten ( ALE-
Ansatz) die systematische Schwachstelle des Ansatzes: Im Gegensatz zur Berechnung von
zahlreichen anderen, versicherbaren Risiken beruhen die Erwartungswerte auf keinen
verlässlichen und ausreichend vergleichbaren Daten aus der Vergangenheit. Damit sind die
Erwartungswerte eher subjektive Einschätzungen des Auditors / Analysten als faktenbasierte
und nachvollziehbare Daten. Erschwerend kommt hinzu, dass mit geringer werdender
Schadenswahrscheinlichkeit auch die evtl. verfügbaren Erfahrungs- oder Vergleichswerte
seltener werden. Damit einher geht die Zunahme der Ungenauigkeit der Schätzung. Zudem
Seite 60 von 262

besitzen die Schätzungen der Höhe der Kosten eines Vorfalls eine sehr große "Unschärfe“
(Varianz).
Insgesamt weist die Anwendung einer betriebswirtschaftlichen Risiko-Betrachtungsweise auf

Leitsysteme verschiedene methodische Defizite auf:
Den betriebswirtschaftlichen Modellen liegt eine vereinfachende Annahme zu Grunde, die

durchgeführten Kalkulationen im Einzelfall Makulatur werden lassen. Beispielsweise
betrachtet das ROSI-Modell Einzelrisiken und darauf ausgerichtete Schutzmaßnahmen
jeweils isoliert. Dabei bleibt unberücksichtigt, dass Schutzmaßnahmen in der Praxis häufig
auf zahlreiche Einzelrisiken wirken. Demgegenüber verursacht ein Schadensereignis
erfahrungsgemäß meist Folgen, die aus kumulierten Risiken resultieren.
Des Weiteren ist es problematisch, die Amortisation von Sicherheitsinvestitionen zu

bestimmen. Die hohe Entwicklungsgeschwindigkeit in der Informationstechnik im
Allgemeinen und die sich ständig verändernde Bedrohungslage für vernetze Systeme im
Speziellen, kann die Wirksamkeit solcher Gegenmaßnahmen erheblich reduzieren und eine
(vollständige) Amortisation der getätigten Sicherheitsinvestition verhindern. Der
Amortisationszeitraum für Investitionen lässt sich deshalb nur bedingt bestimmen.
Schließlich bleibt ein Nebeneffekt vieler Sicherheitsmaßnahmen und / oder -investitionen in

den betriebswirtschaftlichen Modellen völlig ausgeblendet: viele Maßnahmen, die einer
verbesserten IT-Sicherheit dienen, verursachen Produktivitätsverluste in den betrieblichen
Arbeitsabläufen. Diese Effizienzverluste der betrieblichen Arbeitsprozessen lassen sich im
Allgemeinen nur schwer kalkulieren (Sonnenreich, et al., 2006).
4.3 Kritik der Konzepte und Vorgehensweisen
Es existiert eine Reihe von Methoden zur Analyse von Risiken, die sich prinzipiell auf
SCADA-Anlagen anwenden lassen. Für eine aussagekräftige Anwendung dieser Methoden -
vergleichbar zum Bereich der Versicherungswirtschaft - fehlen statistische Daten über
Cyber-Vorfälle in SCADA-Anlagen sowie auswertbare Informationen über potentielle
Angreifer gegen die betrachtete Zielanlage (oder zumindest vergleichbare Anlagen). Die
Ergebnisse aus Risikoanalysen haben deshalb eine hohe Unsicherheit. Angesichts der
absoluten Unsicherheit der Einzelergebnisse besteht die alternative Möglichkeit, nur die
dynamische Entwicklung der Analyseergebnisse, d.h. Resultate regelmäßig erfolgter
Analysen nach gleicher Methodik über eine gewisse Zeit hinweg, zu betrachten. Allerdings
Seite 61 von 262

sind auch diese, dem Zweck einer vergleichenden Betrachtung dienenden Ergebnisse, nur
von begrenztem Wert: wechselnde Teilnehmergruppen der Analyseteams, sich im Laufe der
Zeit verändernde Einschätzungen der Teilnehmer hinsichtlich der Bedrohungslage sowie
evtl. Veränderungen der Anlagenstruktur beeinflussen die Resultate. Für den
Anlagenbetreiber besteht somit die Ungewissheit, ob die Veränderung der „Sicherheit“ auf
eine veränderte Einschätzung der Auditoren (subjektiv) oder eine veränderte
Bedrohungslage zurückzuführen ist. Selbst angesichts einer unveränderten „Sicherheit“
besteht die Möglichkeit, dass eine kritischere Bedrohungslage durch gegenläufige Auditoren-
Einschätzungen (wegen unterschiedlicher Teamzusammensetzung) in unerwünschter Weise
kompensiert wird.
Besonders wichtig: eine konkrete Aussage über die IT-Sicherheit von Leit- und
Automatisierungssysteme im Sinne einer Systemeigenschaft (siehe 3.5) liefern weder der
technikorientierte noch der betriebswirtschaftlich geprägte Analyseansatz.
Die mangelnde Aussagekraft der Risikoanalysenergebnisse in Verbindung mit den fehlenden

Handlungsempfehlungen für Maßnahmen zur Beseitigung von Sicherheitsschwachstellen in
leittechnischen Anlagen stellt die Anwendung dieser Methoden zur Beurteilung der IT-
Sicherheit von SCADA-Systemen grundsätzlich in Frage.
4.4 Kriterien eines praxisgerechten Beurteilungsansatzes
Trotz der vorgenannten Kritik an den Risikoanalysemethoden lassen sich allerdings Kriterien
zur Beurteilung der IT-Sicherheit ableiten, die eine erfolgversprechende
Beurteilungsmethodik charakterisieren.
Eine Beurteilungsmethodik, die nachvollziehbare Ergebnisse für die IT-Sicherheit einer

SCADA-Anlage liefern kann, sollte folgenden Kriterien genügen:
 Die der Analyse zugrunde gelegte Beurteilungsmethode soll für den Anwender
transparent sein, z.B. durch Nutzung eines (systemgestützten) Algorithmus.
 Die Ergebnisse des Beurteilungsprozesses müssen für den Anwender reproduzierbar

sein. Dies bedeutet, dass für den Betreiber der Anlage ersichtlich ist, wie die
Ergebnisse zustande gekommen sind bzw. welche Faktoren das Ergebnis
bestimmen.
 Voraussetzung für die Reproduzierbarkeit und Nachvollziehbarkeit der

Analyseergebnisse ist, dass subjektive Einflüsse aus dem Kreis der an der
Seite 62 von 262

Risikobeurteilung beteiligten Personen, soweit als möglich vermieden werden.

Gerade bei wechselnder Zusammensetzung des Analyseteams ist es ansonsten
schwierig, über mehrere Analysen hinweg die Ergebniskonsistenz zu gewährleisten.
 Für die Reduzierung des Analyseaufwandes sowie die Sicherstellung hinreichender

Datenqualität ist eine (zumindest) teilweise Automatisierung des
Beurteilungsprozesses bzw. Analyseablauf hilfreich.
 Eine Analysemethode für leittechnische Anlagen sollte sich sowohl von SCADA-
Hersteller/Lieferanten als auch von den Anlagenbetreibern anwenden lassen. Für
Lieferanten bietet es sich an, die Sicherheitsanalyse der nach Kundenwünschen
konzipierten Leittechnikanlage bereits vor der Auslieferung vorzunehmen und die
Ergebnisse dem Kunden zu präsentieren. Der Betreiber einer SCADA-Anlage möchte
die Analysemethode im Rahmen des betrieblichen Risikomanagements sowie zur
Sicherstellung eines sicheren Anlagenbetriebes nutzen.
 Die Anwendung der Analysemethode durch Hersteller / Lieferanten setzt voraus,

dass keine Abhängigkeit von kommerziellen Risikoparametern der
(verfahrenstechnischen) Gesamtanlage besteht. Diese Daten stellen in der Regel
Geschäftsgeheimnisse des Kunden dar, über die der Lieferant nicht verfügt.
Dieses Kapitel 4 trug folgende, für die weitere Beurteilung der IT-Sicherheit von Leit- und
Automatisierungssystemen wesentliche Aspekte zusammen:
 Typische Analyseansätze zur Beurteilung der IT-Sicherheit
Bereits im vorangegangenen Kapitel 3 wurde darauf hingewiesen, dass in Ermangelung

einer eindeutig bestimmbaren Größe „Sicherheit“ (im Sinne von „security“) im Rahmen von
Beurteilungsverfahren zur IT-Sicherheit vielfach auf die Ersatzgröße „Risiko“ ausgewichen
wird. Im betrieblichen Umfeld finden sowohl technisch-orientierte als auch
betriebswirtschaftlich geprägte Analysemethoden Anwendung zur Bestimmung des
Anlagenrisikos, das sich aus der Nutzung leittechnischer Systeme im betrieblichen Umfeld
ergibt.
Seite 63 von 262

 Kritik der Konzepte und Vorgehensweisen
Als wesentliche Kritikpunkte der skizzierten Analysemethoden haben sich die fehlenden
statistischen Daten (im Gegensatz zur Anwendung im Bereich der Versicherungswirtschaft),
der Einfluss subjektiver Einschätzungen auf die Analyseergebnissen, die starke Unsicherheit
hinsichtlich der Aussagekraft der Ergebnisse für die Betreiber und vor allem die fehlende
Aussage zum Anlagenstatus der IT-Sicherheit gezeigt.
 Kriterien eines praxisgerechten Beurteilungsansatzes
Aus der Kritik der Analyseansätze ergeben sich die Kriterien für einen Analyseansatz, der
den Anforderungen der betrieblichen Praxis genügt: Transparenz und Reproduzierbarkeit der
Abbildung der Anlageneigenschaften auf die Analyseergebnisse, Verzicht auf subjektive
Einschätzungen und automatisierbare Analyseschritte sind die wesentlichen Anforderungen.
Schließlich soll das Analyseergebnis eine Aussage über den Sicherheitsstatus der
Zielanlage darstellen.
Seite 64 von 262

Kapitel 5 Vorschlag eines neuen Analysemodells für SCADA-Systeme
5 Vorschlag eines neuen Analysemodells für SCADA-Systeme
5.1 Beurteilungsansatz für IT-Sicherheit
Die im vorigen Kapitel kurz skizzierten Ansätze zeigen, dass es derzeit keine
zufriedenstellende Methodik zur Beurteilung der IT-Sicherheit einer leittechnischen Anlage
im Bereich der kritischen Infrastrukturen gibt.
Die wesentlichen Kritikpunkte sind:
- Subjektive Einflüsse und Einschätzungen der Teammitglieder bei Sicherheitsanalysen

erschweren die Reproduzierbarkeit der Ergebnisse.
- Risikoanalysen scheitern an den fehlenden, statistisch belastbaren Basisdaten für

Cyberangriffe gegen Leittechnikanlagen in kritischen Infrastrukturen.
- Die Einbeziehung kommerzieller Betriebsdaten für die Beurteilung möglicher

Schadenspotentiale schließen Lieferanten und Hersteller in der Projektierungsphase
leittechnischer Anlagen von einer Beurteilung der IT-Sicherheit aus.
Es wird nun der Ansatz einer Beurteilungsmethodik zur Diskussion gestellt, der versucht, die
aufgeführten Schwachstellen zu vermeiden.
Um zu einer neuartigen Methodik zu gelangen, ist der Blickwinkel auf die betrachteten
Systeme und die damit gesteuerten Gesamtanlagen zu verändern. In den im
vorangegangenen Kapitel 4 skizzierten Analysemethoden stand das Risiko, das mit Angriffen
gegen leittechnische Systeme verbunden ist, im Mittelpunkt der Betrachtung. Das
grundlegende Problem aktueller Analyseansätze ist, dass die Angreifer als Ausgangspunkt
der Sicherheitsbetrachtung einer Anlage aufgefasst werden. Das in Abschnitt 3.3
beschriebene Bedrohungsmodell (siehe Abbildung 5) sowie die Diskussion dieses Modells
zeigten die Probleme, hinsichtlich der Modellelemente „Angreifer“ und
„Systemschwachstellen“ zu verlässlichen Aussagen zu gelangen. Ohne Kenntnisse über die
Kompetenzen sowie die technischen, finanziellen und zeitlichen Möglichkeiten der Angreifer,
ohne Kenntnis der hinter dem Angriff steckenden Intensionen und Motivationen und
schließlich ohne Kenntnis der für den Angriff auszunützenden Systemschwachstellen lassen
sich die Auswirkungen auf die Systemumgebung für den Falle eines Cyber-Angriffes nicht
abschätzen. Selbst die aktuell häufig empfohlene Einordnung potentieller Angreifer in
Klassen „typischer Angreifer“, wie z.B. Script-Kiddy, Hersteller von Massen-Schadsoftware
(keine Zielgruppenspezifische Ausprägung) oder Angreifer mit unbegrenzten Ressourcen,
hilft grundsätzlich nicht weiter.
Seite 65 von 262

In Kenntnis dieser Randbedingungen der Sicherheitsbetrachtungen ist es nützlich, den

Blickwinkel zu ändern: anstelle die Auswirkungen eines Cyber-Angriffes auf die
Systemumgebung in den Mittelpunkt der Betrachtung zu stellen, sollte das Augenmerk auf
die Widerstandsfähigkeit der Systeme gegen Cyber-Angriffe gelenkt werden. Diese
Überlegung geht mit der grundsätzlichen Forderung nach Verbesserung der
Schutzmaßnahmen für kritische Infrastrukturen einher (Clark, et al., 2011).
Es stellt sich nun allerdings die Frage, ob mit dieser Überlegung nicht ein in der
Vergangenheit ungelöstes Problem durch ein anderes, ebenso wenig lösbares Problem
ersetzt wird: bisher besteht die Schwierigkeit, Eintrittswahrscheinlichkeiten von Cyber-
Angriffen und deren Auswirkungen ohne statistisch tragfähige Daten für Einzelfälle zu
beurteilen. Dieses Problem wird nun durch die Fragestellung ersetzt, die
Widerstandsfähigkeit gegen heute und zukünftig unbekannte Angriffsszenarien
abzuschätzen.
Die Widerstandsfähigkeit einer leittechnischen Anlage gegen Cyber-Angriffe zum Maßstab

der IT-Sicherheit von leitechnischen Systemen zu machen, geht von der Überlegung aus,
dass jeder Angriff einen „Infektionspfad“ vom Angreifer bis zum Zielsystem voraussetzt.
Diese Verbindungen zwischen Angreifer und Zielsystem können physischer und/oder
logischer Art sein. Logische Zugänge zum Zielsystem kann ein Angreifer entweder lokal
erhalten, d.h. durch physischen Systemzugang vor Ort und Anmelden am System, oder
durch Zugang über Netzwerke (z.B. via Internet, remote access). Darüber hinaus kann der
Systemzugang direkt via Netzwerk / Konsole oder indirekt erfolgen. Beispiel einer indirekten
Ausprägung eines Angriffes kann ein USB-Stick sein, den ein Angreifer im Außenbereich
einer Anlage „verliert“ oder einem Mitarbeiter der Anlage bei passender Gelegenheit
„schenkt“. Die Wahrscheinlichkeit, dass ein solches Gerät Zugang zum Netzwerk der Anlage
erhält, ist relativ hoch.
Der praktische Vorteil dieses Ansatzes („Infektionspfad“) ist, dass sich die Schnittstellen
eines leittechnischen Systems (z.B. USB, Firewire, CD/DVD, Bluetooth, eSATA etc.)
automatisiert erfassen lassen. Die potentiellen Infektionswege sind auf diese Weise
aufzählbar und außerdem für den Betreiber im Rahmen seiner Systemkenntnis bekannt. Es
sei an dieser Stelle jedoch ausdrücklich darauf hingewiesen, dass grundsätzlich nur jene
Angriffspfade Berücksichtigung finden, die das Analyseteam durch systematische
Betrachtung möglicher Angriffsszenarien auf Basis des aktuellen Kenntnisstands herleiten
konnte (siehe Vorgehensweise zur Herleitung von Angriffsszenarien, gemäß Kap. 5.3.3).
Seite 66 von 262

Die praktische Umsetzung des neuen Analysekonzeptes gliedert sich somit in folgende
Schritte (siehe auch Abbildung 6):
1) Bestimmung von Beurteilungskriterien der Voraussetzungen für Angriffsszenarien

gegen die Zielanlage
2) Herleitung von generischen Angriffsszenarien
3) Abbildung der gefundenen Angriffsszenarien auf die Zielanlage
4) Bewertung der umsetzbaren Angriffsszenarien anhand der Voraussetzungskriterien
5) Bewertung der IT-Sicherheit der Zielanlage mittels einer geeigneten Metrik
Abbildung 6: Übersicht über die vorgeschlagene Analysemethode
Abbildung 6 stellt in einem Übersichtsschema den vorgeschlagenen, neuen Analyseverlauf

dar. Unabhängig voneinander sind zwei Datenmodelle erforderlich:
 Auflistung möglicher Angriffe gegen Leitsysteme
Seite 67 von 262

Die Auflistung erfolgt in allgemeiner Form und ist somit nicht anlagenspezifisch – mit
Ausnahme der Auswahl der betrachteten Rechnertypen und sonstigen Komponenten.
 Beschreibung des Zielsystems

Die Beschreibung des Zielsystems muss einer automatisierten Auswertung
zugänglich sein.
Der nächste Analyseschritt bildet die betrachteten Angriffsmodelle (automatisiert) auf die
Zielsystembeschreibung ab. Als Ergebnis erhält man daraus jene realisierbaren
Angriffsmodelle, die aufgrund der Zielanlageneigenschaften technisch möglich sind.
Für diese realisierbaren Angriffsszenarien sind anschließend die Angriffsvoraussetzungen zu

betrachten. Dieser Schritt setzt die Erstellung geeigneter Beurteilungskriterien voraus (siehe
Kapitel 5.2). Diese Bewertung liefert als Ergebnis die Angriffsvoraussetzungen für die
gefundenen realisierbaren Angriffsszenarien, d.h. Aussagen über die technischen Hürden,
diese Angriffe gegen die Zielanlage durchzuführen.
Schließlich überführt eine geeignete Matrix die Ergebnisse in eine Form, die faktenbasierte
Aussagen zur IT-Sicherheit der leittechnischen Anlage für die Unternehmensführung liefert
und geeignete Handlungsoptionen aufzeigt.
Die nachfolgenden Abschnitte dieses Kapitels stellen den skizzierten Analyseverlauf

detailliert dar.
5.2 Beurteilung der Angriffsvoraussetzungen
In Abweichung vom skizzierten Analyseverlauf soll zunächst auf die Beurteilungskriterien

eingegangen werden, da diese ein wesentliches Element des neuen Analysemodells
darstellen.
Wie oben gezeigt (siehe 4.3), sind Risikoanalysen sehr stark subjektiven Einschätzungen
unterworfen und liefern daher nur bedingt reproduzierbare Ergebnisse. Besonders
problematisch ist die Einschätzung der Potentiale eines Angreifers (technische und
finanzielle Möglichkeiten, Zeitaufwand, Knowhow etc.). Risikobeurteilungen potentieller
Angriffe gegen Computersysteme, die auf der Einschätzung von Fähigkeiten und
Möglichkeiten (unbekannter) Angreifer beruhen, haben somit nur unbestimmte Aussagekraft.
Als Konsequenz dieser Überlegungen ergibt sich, auf jegliche Einschätzungen potentieller
Angreifer zu verzichten und Angriffsszenarien danach zu beurteilen, welche
Seite 68 von 262

Voraussetzungen für einen erfolgreichen Angriff nötig sind. Dieser abgeänderte Blickwinkel
wurde in 5.1 als „Infektionspfad“-Schema bezeichnet. Dieser Denkansatz soll nun dahin
erweitert werden, alle Aspekte zu betrachten, die für einen erfolgreichen Angriff gegen
Computersysteme (hier: Leittechniksysteme) notwendig sind. Diese Angriffsaspekte bilden
ganz nebenbei die Möglichkeit, die Angreifer - ohne jegliche Spekulation - einer
Kategorisierung zuzuführen und eine Priorisierung der Maßnahmen zum Schutz der Anlage
vorzunehmen. Die Angriffsvoraussetzungen lassen sich wie folgt zusammenfassen:
Zugang zum Zielsystem
Jeder Angriff gegen ein Rechnersystem setzt einen Zugang zu dem betreffenden System
voraus. Dieser Zugang kann physisch oder logisch, d.h. mittels Netzwerk, erfolgen. Auch
gemischte Zugangsmöglichkeiten sind denkbar.
Kompetenzen hinsichtlich des Angriffszieles
Die erforderlichen Kompetenzen für die Durchführung eines Angriffes setzen sich in der
Regel aus mehreren Elementen zusammen: anlagenspezifische und allgemeine Fähigkeiten
und Wissen. Leitsysteme stellen in der Regel nicht das eigentliche Angriffsziel dar. Sie sind
eher Mittel zum Zweck, d.h. der Angriff zielt primär gegen den vom Leitsystem geführten
(physikalischen) Prozess. Der eigentliche Angriff gegen den Prozess erfolgt also mit Hilfe
des Leitsystems. Daraus ergibt sich, dass ein Angreifer ggf. über Knowhow bezüglich des
verfahrenstechnischen Prozesses, die System- und Anlagentechnik der angegriffenen
Anlage, sowie personenspezifische Informationen verfügen muss.
Verfügbare Ausrüstung
Zur Durchführung des Angriffes muss ein Angreifer ggf. über unterschiedliche Ausstattung
technischer Gerätschaften verfügen.
Für die weitere Betrachtung sind also folgende Elemente zu berücksichtigen:
 Zugangsmöglichkeiten („Access“)
 Kompetenzen („Knowhow“)
 Ausrüstung („Equipment“)
An dieser Stelle sei auf die Konsequenz dieser neuen Betrachtungsweise hingewiesen: Im
weiteren Verlauf der nachfolgend skizzierten Analysemethode wird nicht versucht, die
Wahrscheinlichkeiten, dass ein (in der Regel unbekannter) Angreifer diese drei
Voraussetzungen erfüllt, abzuschätzen. Im Gegensatz dazu soll eine Kriterienskala die
Schwierigkeit, diese Voraussetzungen zu erfüllen, abbilden.
Seite 69 von 262
Beispiel: Falls ein Angriffsszenario Kenntnisse eines Standardbetriebssystems

erfordert, ist diese Kompetenz bzw. Wissen einer geringen Voraussetzungshürde
zuzuordnen. Betriebssystemkenntnisse sind großen Personenkreisen in vielfältigen
Quellen ohne wesentliche Einschränkungen zugänglich. Demgegenüber ist die
Kenntnis eines bestimmten Benutzerpasswortes personen- und anlagenspezifisch und
kann als hohe Voraussetzungshürde eingestuft werden.
Aus diesen Grundüberlegungen lassen sich die Basisparameter für die Beurteilung eines
Angriffsszenarios ableiten. Die drei Parameter
 Zugang
 Kompetenzen
 Equipment
werden nachfolgend graduell unterteilt.
Der Kennwert „Zugang“ bildet eine abstrakte Anlagenstruktur auf vier Kategorien ab:
 Gelände
 Gebäude
 Raum
 Gerät
Im Rahmen der Analyse ist für jedes Angriffsszenario zu entscheiden, welcher Zugangsgrad
notwendig ist.
Der Kennwert „Kompetenz“ beschreibt die notwendigen Kenntnisse bzw. Fähigkeiten eines
Angreifers im Rahmen eines gegebenen Angriffsszenarios:
 Allgemein
Allgemeines Wissen steht praktisch jedermann zur Verfügung bzw. ist in einfacher
Weise zu erlangen.
 Spezifisch
Spezifisches Wissen umfasst sowohl system- wie auch anlagentechnisches Wissen,

das zwar nicht explizit restriktiv gehandhabt wird, über das im Allgemeinen aber nur
eingeschränkte Personenkreise verfügen.
Seite 70 von 262

 Sensibel
Als sensibel wird personenspezifisches Knowhow eingestuft, das im Allgemeinen

restriktiv gehandhabt wird (z.B. Benutzername).
 Kritisch
Als kritisches Knowhow werden Informationen betrachtet, die es erlauben, die

Identität (autorisierter) Personen anzunehmen (z.B. Passwort).
Im Rahmen der Analyse ist für jedes Angriffsszenario zu entscheiden, welche Kompetenzen
notwendig sind.
Der Kennwert „Equipment“ beschreibt Voraussetzungen hinsichtlich der Ausstattung des

Angreifers:
 Allgemein
Ausrüstungsgegenstände werden dann als allgemein verfügbar eingestuft, wenn

Angreifer diese jederzeit und ohne Einschränkungen beschaffen können.
 Eingeschränkt
Ausstattung wird als „eingeschränkt“ beurteilt, wenn die Beschaffung detailliertes

Wissen hinsichtlich der Liefermöglichkeiten voraussetzt, d.h. Einschränkungen
hinsichtlich der Lieferkette bestehen.
 Restriktiv
Als beschränkt verfügbar gelten Ausrüstungen dann, wenn diese Produkte nicht frei
erwerbbar sind, d.h. Einschränkungen bezüglich des Käufers bestehen.
 Individuell
Als individuelle Ausstattungen gelten Gegenstände oder Produkte, die nur

individuellen Personen zur Verfügung stehen (z.B. ID-Karten, elektronische Ausweise
etc.)
Im Rahmen der Analyse ist für jedes Angriffsszenario zu entscheiden, welche Ausstattung
notwendig ist.
Aus den oben aufgeführten Kriterien für die drei Parameter Zugang, Knowhow und
Ausrüstung lassen sich nun die Angriffsszenarien gegen eine leittechnische Anlage anhand
der notwendigen Voraussetzungen für eine Durchführung des Angriffs beurteilen.
Seite 71 von 262

Kriterium
Allgemein Eingeschränkt Restriktiv Individuell
Parameter
Zugang
Kompetenz
Equipment
Tabelle 1: Beurteilungskriterien für Angriffsvoraussetzungen
Abschließend sei an dieser Stelle nochmals auf die prinzipiell veränderte Blickrichtung des
Beurteilungskonzeptes hingewiesen: Die Analyse versucht nicht, die Wahrscheinlichkeit
abzuschätzen, mit der ein unbekannter Angreifer beispielsweise Kenntnisse eines
bestimmten Betriebssystems hat, sondern ordnet die Schwierigkeit bzw. Einfachheit an
solche Kenntnisse zu gelangen, einer der vier Kriterienstufen („Allgemein“, „Eingeschränkt“,
„Restriktiv“, „Individuell“) zu.
Die Beurteilungskriterien für die drei Parameter kann z.B. der Anlagenbetreiber aufgrund
eigener Recherche für die Beschaffung von Ausrüstungsgegenständen und die Verfügbarkeit
notwendiger Informationen zu Systemen und Produkten (Knowhow) selbst erstellen.
Hinsichtlich der Kriterienstufen des Parameters „Zugang“ steht er sogar selbst in der
Durchsetzungsverantwortung. Diese Klassifizierungen kann der Betreiber somit hinreichend
genau selbst bestimmen. Im Gegensatz dazu sind Informationen oder die Abschätzungen
von Eintrittswahrscheinlichkeiten über unbekannte Angreifer hingegen in aller Regel nicht
verfügbar.
5.3 Herleitung von Angriffsszenarien
5.3.1 Allgemeines
Für den weiteren Fortgang der Analyse ist es notwendig, dezidierte Angriffsszenarien
herzuleiten und auf der Anwendbarkeit gegen die betrachtete Zielanlage zu überprüfen. Mit
Hilfe der Methode „Attack Tree“, auf die in Kapitel 5.3.3 detailliert eingegangen wird, lassen
sich sowohl Angriffsszenarien als auch die notwendigen Voraussetzungen für einen
erfolgreichen Angriff bestimmen. Die Abbildung dieser Angriffsvoraussetzungen auf die
Seite 72 von 262

systemtechnischen Eigenschaften der Zielanlage liefert als Ergebnis aus der Menge aller
beschriebenen Angriffsszenarien die Teilmenge jener Angriffsszenarien, die prinzipiell
erfolgreich durchführbar sind.
5.3.2 Leittechnikmodell zur Herleitung generischer Angriffsszenarien
Anforderungen an die Beschreibungsmethode
SCADA-Anlagen bestehen aus einer Anzahl von Komponenten aus einer überschaubaren
Zahl von Geräteklassen. Die Beschreibungsmethodik von Angriffsszenarien sollte deshalb
modularen Charakter haben und dokumentierte Szenarien in wiederverwendbarer Form zur
Verfügung stellen.
Ein Leitsystem kann eine große Anzahl von Komponenten umfassen. Die daraus
resultierende Menge an möglichen Angriffsszenarien sollte einer automatisierbaren
Auswertung zugänglich sein. Automatisierbare Abläufe reduzieren fehleranfällige manuelle
Interaktionen und liefern reproduzierbare Ergebnisse.
Aufgrund von zukünftig bekannt werdenden Schwachstellen und darauf beruhenden

Angriffsszenarien sollte die Beschreibungsmethodik erweiterbar sein: flexibel sowohl
hinsichtlich neuer Erkenntnisse, als auch hinsichtlich des Detaillierungsgrades der
Darstellung.
Eine brauchbare Methode zur Beschreibung von Angriffsszenarien sollte somit folgende
Kriterien erfüllen:
 Wiederverwendbarkeit
 Automatisierbare Auswertung
 Variabler Detaillierungsgrad
Generische Angriffsszenarien
Ein zentrales Problem von Sicherheitsanalysen stellt die Definition der relevanten
Angriffsszenarien dar. Da keine Analysemethode existiert, die alle bekannten und
unbekannten (aber möglichen!) Angriffsszenarien kennt und berücksichtigt, sollte einer
praktikablen Analysemethodik eine systematische Herangehensweise zugrunde liegen und
gefundene Szenarien aus vorangegangenen Analysen wiederverwendet werden können. Zu
diesem Zweck bietet sich eine Vorgehensweise an, die auf generischen Angriffsszenarien
basiert und diese im weiteren Analyseprozess schrittweise verfeinert. Als Ausgangspunkt für
Seite 73 von 262

die Bildung generischer Angriffsszenarien können Auswirkungen erfolgreicher Angriffe gegen

Leitsysteme herangezogen werden, wie sie z.B. (Knapp, 2011 S. 36) beschreibt:
Ereignistyp Potentielle Auswirkung
Einfügen von SW-Hintertüren zur Beeinflussung

ansonsten sicherer Systeme
Änderung an Betriebssystem- Unterdrückung von Alarmen und Meldungen um
oder Anwendungsdaten Manipulationen nicht sichtbar werden zu lassen
Änderungen des erwarteten Systemverhaltens um
unerwünschte oder unvorhersehbare Ergebnisse
hervorzurufen
Schäden an Ausrüstung und/oder Anlagen
Änderungen der
programmierbaren Fehlfunktion des verfahrenstechnischen Prozesses (z.B.
Prozesslogik in Abschaltung)
Automatisierungsgeräten Kontrolle über den verfahrenstechnischen Prozess
verhindern
Fehlbedienungen aufgrund falscher Informationen
verursachen, die Änderungen der programmierbaren
Fehlinformation für das Logik nach sich ziehen könnten
Bedienpersonal Verstecken schädlicher Manipulationen, einschließlich
der Manipulation an sich oder des eingeschleusten
Codes (z.B., ein Rootkit)
Manipulation von Verhindern erwarteter Maßnahmen, Sicherheits-
Sicherheitssystemen oder reaktionen und anderer Schutzvorkehrungen mit
anderen Steuerungseinheiten potentiell schädlichen Auswirkungen
Auslösen weiterer Angriffsszenarien
Negative Auswirkungen auf die Produktion oder gar das
Einschleusen von Erzwingen einer Abschaltung zur Schadensanalyse,
Schadsoftware Säuberung und/oder Ersatz
Ermöglichen weiterer Angriffe, Informationsdiebstähle,
Manipulationen oder Infektionen mit Schadcode
Sensitive Informationen, wie z.B. Rezepturen oder
Diebstahl von Information
chemischer Formeln werden gestohlen
Sensitive Informationen, wie z.B. Rezepturen oder
Manipulation von
chemischer Formeln werden verändert, um ungünstige
Informationen
Auswirkungen auf die produzierten Güter zu verursachen
Tabelle 2: Angriffstypen und potentielle Auswirkungen
Um im Verlauf der Zielsystemanalyse subjektive Einschränkungen der potentiellen

Angriffsvarianten auszuschließen, soll im nächsten Schritt ein generisches Leittechnikmodell
die Grundlage für die Herleitung von Angriffsszenarien bilden. Zu diesem Zweck soll das in
Seite 74 von 262

Abbildung 7 dargestellte generische Leittechnikmodell dienen. Dieses Modell besteht aus

folgenden Leittechnikelementen:
 Bedienstation für den Operator (HMI-Client)
 Arbeitsplatz für Leittechnikpersonal (Engineering, ENG-Client)
 Server für die Leittechnikanwendung (HMI-Server)
 Automatisierungssystem (PLC)
 Stellglied (Actuator)
 Messstellen (Sensor)
Abbildung 7: Generisches Leittechnikmodell
Ausgehend vom physikalischen Prozess, den die Leittechnik führt, erfassen Sensoren die
physikalischen Prozessgrößen und wandeln diese in (normierte) Prozesszustandsdaten um.
Seite 75 von 262

Das Automatisierungsgerät (Process Logic Controller, PLC) wandelt die erfassten Daten in
Prozesswerte um, z.B. Drücke, Temperaturen, Positionen usw. Die Verarbeitung der
Prozesswerte innerhalb des PLC erfolgt gemäß der hinterlegten Prozesslogik (Code des
Automatisierungssystems, AS-Code) in zwei verschiedenen Varianten:
 Verarbeitung der Prozesswerte gemäß Logik und automatische Veränderung der

Prozess-Steuerdaten, die über die angeschlossenen Aktoren den physikalischen
Prozess beeinflussen (Steuerung / open loop control, Regelung / closed loop control)
oder
 Weitergabe der Prozesswerte an den HMI-Server zur weiteren Verarbeitung

(Visualisierung, Archivierung)
Neben den vom Prozess erfassten Prozesszuständen (Messwerte) erzeugt das PLC gemäß
Prozesslogik auch berechnete Prozesswerte und sogenannte Prozessalarme bei
Überschreiten oder Unterschreiten kritischer Grenzen der Prozessgrößen. Neben diesen aus
dem Prozess abgeleiteten Prozessalarmen kann ein Automatisierungsgerät auch
Systemalarme mittels Geräte-Selbstüberwachung auslösen. Neben den dynamischen Daten,
die das Automatisierungsgerät an den HMI-Server sendet, wird bei Bedarf auch die
Prozesslogik (AS-Code) zwischen PLC und HMI-Server ausgetauscht.
Das Bedien- und Beobachtungssystem (Human Machine Interface, HMI) besteht

typischerweise aus einer Server- und einer Client-Komponente. Der HMI-Server, der bei
großen Anlagen auch aus mehreren Rechnersystemen bestehen kann, führt eine Reihe von
Aufgaben durch. Die wesentlichen Aufgaben sind:
 Datenmodell zur Visualisierung der Prozessinformationen
 Bereitstellung der Dienste zur Prozessvisualisierung und -bedienung
 Bereitstellung der Dienste, Funktionen und Datenhaltung zur Anlagenprojektierung
 Bereitstellung der Dienste und Funktionen der Prozesswertverarbeitung
 Prozessdatenarchiv
Das Leitstandpersonal führt die Anlage über die Arbeitsplätze, an denen die HMI-Client-
Systeme aufgestellt sind. Die HMI-Clients stellen den physikalischen Prozess mittels
sogenannter Prozessbilder dar, in denen aktuelle Prozesszustände angezeigt werden und
das Bedienpersonal auch Bedieneingriffe, d.h. Schalthandlungen, vornehmen kann.
Die Projektierung der leittechnischen Systeme führt das Engineering-Personal mittels der
Engineering-Clients durch. Je nach Hersteller sind diese Clients mit speziellen
Seite 76 von 262
Projektierungsfunktionen ausgestattet oder die Systeme entsprechen weitgehend den HMI-

Clients, falls der HMI-Server alle Projektierungsfunktionen sowie die notwendige
Datenhaltung zentral bereitstellt.
Abbildung 7 stellt die wesentlichen Elemente einer leittechnischen Anlage dar. In einer
Verfeinerung zeigt Abbildung 8 die Datenflüsse zwischen den Leittechnikkomponenten,
während Abbildung 9 die für das Leitsystem wesentlichen Datenspeicher darstellt. Aus
diesem Schema lassen sich eine Reihe potentieller Angriffsziele ableiten.
Grundsätzlich ist zwischen
 Angriffen gegen die Kommunikation zwischen den Systemen (Datentransfer) und
 Angriffen gegen die einzelnen Systeme (Datenhaltungen)
zu unterscheiden. Als Angriffsarten sind bei leittechnischen Systemen für kritische

Infrastrukturen primär die Schutzziele „Verfügbarkeit“ und „Integrität“ zu berücksichtigen. Im
Gegensatz zu Automatisierungssystemen in Fertigungsanlagen (Automobil, Chemie etc.)
spielt das Schutzziel „Vertraulichkeit“ nur eine untergeordnete Rolle.
Seite 77 von 262

Abbildung 8: Datenflussschema im generischen Leittechnikmodell
Seite 78 von 262

Abbildung 9: Datenhaltung des generischen Leittechnikmodells
Seite 79 von 262

5.3.3 Herleitung generischer Angriffsszenarien mittels Attack Tree-Graphen
Eine Methode zur Beschreibung von Angriffsszenarien sollte folgende Kriterien erfüllen:
 Wiederverwendbarkeit
 Automatisierbare Auswertung
 Variabler Detaillierungsgrad
Eine Beschreibungsmethodik, die diesen Kriterien genügt, sind die sogenannten „Attack
tree“-Modelle.
Eine Reihe von Autoren beschreibt diesen Ansatz zur Darstellung von Angriffen. Hierzu
gehören (ohne Anspruch auf Vollständigkeit): (Moore, et al., 2001), (Espedalen, 2007),
(Mauw, et al.), (Schneier, 1999), (Byres, et al., 2004), (Wikipedia, 2011 S. Attack Tree) u.a.
(Schneier, 1999) definiert Attack trees als formalen und methodischen Ansatz, der die
Sicherheit von Computersystemen auf der Basis verschiedener Angriffe beschreibt. Attack
trees stellen Angriffe in Form einer Baumstruktur dar: das Angriffsziel bildet den zentralen
Wurzelknoten und die verschiedenen Möglichkeiten, dieses Ziel zu erreichen, die
untergeordneten Blätterknoten.
Im umfassenderen Sinn stellen Attack tree-Modelle Wege dar, um
 die Sicherheit von Systemen zu durchdenken und zu beschreiben
 eine automatische Datenbasis aufzubauen, die die Sicherheit des Systems darstellt
 Wissen hinsichtlich der Systemsicherheit zu erlangen und dieses Wissen zu nutzen
 Entscheidungen über die Verbesserung der Systemsicherheit oder hinsichtlich der

Auswirkungen neuartiger Angriffe auf die Sicherheit zu treffen
(Schneier, 1999)
In allgemeiner Form lassen sich „Attack trees“ als Ansatz zur Dokumentation von
Angriffsinformationen in strukturierter und wiederverwendbarer Form auffassen (Moore, et
al., 2001). Der Wurzelknoten eines Baumes (in einem Wald von Bäumen) repräsentiert ein
Ereignis, das den Unternehmenszweck signifikant beeinträchtigen könnte. Jeder Attack tree
beschreibt in detaillierter Weise die Möglichkeiten eines Angreifers, das betreffende Ereignis
herbeizuführen. Jeder Pfad durch den Attack Tree repräsentiert eine eigenständige
Angriffsmöglichkeit gegen das Unternehmen.
Zu diesem Zweck zerlegt man die Attack trees in Knoten, die Unterziele darstellen:
Seite 80 von 262

 UND-Dekompositionen stellen einen Satz von Unterzielen dar, die alle für einen
erfolgreichen Angriff erreicht werden müssen oder
 ODER-Dekompositionen stellen einen Satz von Unterzielen dar, von denen jedes
einzelne für einen erfolgreichen Angriff ausreicht.
Der Detaillierungsgrad der Zerlegung ist dem Bedarf des Anwenders überlassen. Ein
wichtiger Aspekt für die Anwendung in der Praxis dieser Methode ist die
Wiederverwendbarkeit von Attack trees.
(Moore, et al., 2001) erweitern das Attack tree-Konzept um Angriffsmuster („Attack patterns“)
und definieren diese als generische Repräsentation vorsätzlich ausgeführter, schädlicher
Angriffe, die gemeinhin in spezifischen Kontexten erfolgen. Ein Angriffsmuster besteht aus:
 dem übergeordneten Angriffsziel des Musters
 einer Liste von Voraussetzungen für die Anwendung des Musters
 die Schrittfolge des Angriffes
 einer Liste von Bedingungen, die einen erfolgreichen Angriff kennzeichnen
Die Angriffsmuster zielen auf die Formalisierung der Analyse, um eine verbesserte
Reproduzierbarkeit zu erreichen.
Nachfolgend ist das Beispiel eines Angriffsmusters skizziert:
Unexpected Operator Attack Pattern
Goal: Exploit unexpected operator vulnerability to perform malicious function
Precondition: Attacker can execute certain programs on the target system
Attack:
1. Identify executable program on the target system susceptible to unexpected operator

vulnerability
AND
2. Identify (unexpected) operator that permits composing system calls
AND
3. Identify system call that would perform malicious function when executed with
program’s privilege
AND
4. Construct unexpected input by composing legal input value with system call using the
unexpected operator
AND
Seite 81 von 262

5. Execute program on the target system with unexpected input
Post condition: Target system performs malicious function
Eine ergänzende Anwendung des Graphenansatzes stellen „Semantic Threat“-Graphen dar,

die die Konfigurationsverwaltung von Security Policies unterstützen sollen (Foley, et al.,
2011). Dabei werden klassische Attack Trees erweitert, um semantische Informationen über
die Sicherheitskonfiguration mit Bedrohungen, Schwachstellen und Gegenmaßnahmen zu
verknüpfen. Threat trees, Attack trees und ähnlich strukturierte Modellierungsmethoden
dienen der Identifikation, Repräsentierung und Analyse von Bedrohungen gegen
Unternehmenswerte. Wesentlichen Nutzen sehen die Autoren im top down-Ansatz und dem
semi-formalen, methodischen Ansatz zur Bestimmung möglicher Bedrohungsvektoren sowie
in besonderer Weise in der Wiederverwendbarkeit der erstellten Modelle und Daten.
Als Fazit des oben Genannten erscheinen Attack trees als geeignete Methode, um
Angriffsszenarien auf SCADA-Systeme zu modellieren. Wesentliche Vorteile sind die
Wiederverwendbarkeit, sowie eine automatisierte Auswertung. Reproduzierbare Ergebnisse
und reduzierter Modellierungsaufwand im Rahmen wiederkehrender Analysen sind der
Nutzen dieser Methode.
Die Modellierung der SCADA-Angriffsszenarien mittels „Attack Trees“ lässt sich nach
folgender Vorgehensweise durchführen: jede Komponente der betrachteten Anlage stellt den
Wurzelknoten eines Attack Tree dar. Unterhalb des Wurzelknotens ergänzt man die zu
berücksichtigenden Schutzziele (z.B. Verfügbarkeit und Integrität). In der anschließenden
Unterebene folgen dann die Knoten, die jeweils einem denkbaren Angriff gegen das
übergeordnete Schutzziel benennen. Die darunter angeordneten Knoten listen die für den
Angriff notwendigen Voraussetzungen auf. Jede der tieferliegenden Knotenebenen spaltet
die Voraussetzungen in weitere Details auf. Die Detaillierung endet, sobald eine unteilbare
Voraussetzung (z.B. Passwort) gefunden wurde. Als ein Szenario werden alle Teilbäume
aufgefasst, die ausgehend von einem Schutzziel einen Pfad zu einem Endknoten darstellen.
UND-verknüpfte (Teil-) Pfade sind im Sinne zusätzlich notwendiger Voraussetzungen
hinzuzufügen. Für die weitere Betrachtung spielen die Zwischenknoten der Bäume keine
Rolle. Sie stellen lediglich Zwischenschritte im Rahmen der Analyse dar. Das Ziel der
Analyse ist es, aus den Angriffsbäumen die Beziehungen
Szenario  Voraussetzung(en)
Seite 82 von 262

abzuleiten: für jedes Angriffsszenario sind die notwendigen Voraussetzungen hinsichtlich der
Beurteilungskriterien gemäß Kapitel 5.2 („Zugang“, „Kompetenz“ und „Ausrüstung“) zu
bestimmen.
Abbildung 10 zeigt das Fragment eines Attack Tree. Das einfache Beispiel stellt die
Angriffsmöglichkeiten gegen die Rechnerklasse „HMI-System“ dar. Der Einfachheit halber
beschränkt sich das gezeigte Beispiel auf Angriffe gegen das Schutzziel „Verfügbarkeit“
mittels physischen oder logischen Systemzugangs.
Aus dem gezeigten Einfachbeispiel lassen sich folgende Angriffsszenarien herleiten:
 Szenario 1: Cyber-Angriff mittels physischem Systemzugang
 Szenario 2: Cyber-Angriff mittels logischem Systemzugang (hier: Netzwerk)
Abbildung 10: Beispiel eines Attack Tree für ein einfaches Angriffsszenario
Die Verfeinerung mit Hilfe der notwendigen Voraussetzungen für einen erfolgreichen Angriff
ergibt folgende, beispielhafte Angriffsszenarien:
Seite 83 von 262

 Szenario 1-1: Cyber-Angriff mittels physischem Systemzugang
o Voraussetzung 1: Raum unverschlossen
o Voraussetzung 2: Systemschrank unverschlossen
o Voraussetzung 1: Raum unverschlossen
o Voraussetzung 2: Systemschrank verschlossen
o Voraussetzung 3: Schrankschlüssel vorhanden
o Voraussetzung 1: Raum verschlossen
o Voraussetzung 2: Raumschlüssel vorhanden
o Voraussetzung 3: Systemschrank unverschlossen
o Voraussetzung 1: Raum verschlossen
o Voraussetzung 2: Raumschlüssel vorhanden
o Voraussetzung 3: Systemschrank verschlossen
o Voraussetzung 4: Schrankschlüssel vorhanden
 Szenario 2-1: Cyber-Angriff mittels logischem Systemzugang via Netz
o Voraussetzung 1: Admin-Kennung vorhanden
 Szenario 2-2: Cyber-Angriff mittels logischem Systemzugang via Netz
o Voraussetzung 1: User-Kennung vorhanden
Hinweis: das gezeigte Attack Tree-Beispiel bildet die möglichen Angriffsszenarien nicht
vollständig ab, sondern soll lediglich die Herangehensweise zur Ableitung der
Angriffsszenarien und den zugehörigen Voraussetzungen verdeutlichen.
Nach diesen generischen Erläuterungen zu „Attack Trees“ sowie der Verdeutlichung anhand
eines Einfachbeispiels soll nun auf die Vorgehensweise zur Erarbeitung der Attack Tree-
Modelle bei realen Anlagen eingegangen werden. Die Analyse der IT-Sicherheit von
Leitsystemen wirft die Frage auf, wie eine hinreichende Abdeckung möglicher
Seite 84 von 262

Angriffsvarianten überhaupt erzielt werden kann. An dieser Stelle sei vor der Illusion
gewarnt, durch geeignete Algorithmen ließen sich evtl. noch unbekannte 0-Day-Exploits
aufdecken. Angesichts der Freisetzung von ca. 900.000 neuen Schadsoftware-Varianten pro
Tag (!) in 2014 (Symantec, 2015) haben sich weder Black-Listing-Ansätze (typ. heuristische
Virenschutzprogramme) noch White-Listing-Methoden (Application Blocker, etc.) als
erfolgreich erwiesen. In Kenntnis dieser Fakten geht die vorliegende Arbeit von der Annahme
aus, dass lediglich die logischen und physischen Angriffspfade eine Chance bieten, Angriffe
abzuwehren. Die Herleitung und Begründung für diesen Ansatz erfolgte in Kapitel 3.4. Dieser
Ansatz führt zum Konzept des erweiterten Perimeter-Schutzes der Leittechnikanlage. Der
Perimeter stellt in diesem Sinne die äußere, angreifbare „Hülle“ der Anlage dar. Hierzu
gehören die physischen Zugangsmöglichkeiten zu den Schnittstellen (Tastatur, USB-
Schnittstelle, CD/DVD-Laufwerk usw.) sowie die logischen Zugangsmöglichkeiten über
Netzwerkverbindungen (kabelgebunden, kabellos).
Aufgrund der zentralen Bedeutung des Attack-Tree-Ansatzes für das in der vorliegenden
Arbeit konzipierte Analyseverfahren, soll an dieser Stelle die Herleitung der Attack Tree-
Modelle schematisch dargestellt werden.
In einem ersten Schritt zerlegt das Analyseteam die Zielanlage in die einzelnen Bestandteile,
d.h. die technischen Komponenten, wie z.B. Server, Clients, Netzwerk-Switches etc. Gemäß
dem Angriffsmodell „Angriffspfad“ (siehe Kapitel 3.4) liegt der Fokus der Betrachtung auf den
Hardware-Schnittstellen der Leittechnikelemente. Die vorhandenen Hardware-Schnittstellen
der installierten Komponenten gleichen Typs können mit Hilfe der entsprechenden
Datenblätter vollständig erfasst werden.
Nachdem für alle Leittechnikbestandteile die für Angriffe nutzbaren Schnittstellen vorliegen,
ist für jede Komponente individuell zu prüfen, ob die jeweilige Gerätekonfiguration die
Nutzung der vorhandenen Schnittstellen ermöglicht. Während die deaktivierten Schnittstellen
in der weiteren Analyse übergangen werden können, sind die aktivierten Schnittstellen in den
Attack Tree-Modellen zu berücksichtigen. Je nach Gerätetyp sind die Konfigurationsdaten
ggf. einer automatisierten Verarbeitung zugänglich.
Nachdem nun die erforderlichen Informationen über die Leittechnikelemente zum Zweck der
Erstellung von Attack Trees systematisch vorliegen, muss das Analyseteam auf Basis dieser
Daten die denkbaren Angriffsvarianten zusammentragen. Hierfür ist es hilfreich, aus den
Datenflussdiagrammen der Zielsystemkomponenten (siehe z.B. Abbildung 8 und Abbildung
9) wesentliche Datenhaltungen (Engineering-, Konfigurations- und Benutzerdaten, Software-
Seite 85 von 262

Anwendungen) und Systemdienste, die als Angriffsziele dienen können, zu extrahieren.

Grundsätzlich sind folgende generische Angriffsvarianten Ausgangspunkte der Analyse:
 Angriff mittels Interaktion an der lokalen Systemkonsole
 Angriff mittels Interaktion via Netzwerkverbindung mit entferntem Gerät
 Angriff durch Einschleusen von Schadsoftware
Kern des Attack Tree-Ansatzes ist es nun, für jede Leittechnikkomponente (Server, Clients,
Netzwerkkomponenten, etc.) diese generischen Angriffsszenarien systematisch durch die
Beantwortung folgender Fragestellungen zu verfeinern:
 Welche Schnittstellen sind physisch zugänglich?
 Welche Komponenten können (systemgemäß oder unbekannt) an diese

Schnittstellen angeschlossen werden?
 Können Daten (Benutzerdaten, Engineering-Daten, Konfigurationsdaten,

Systemsoftware) manipuliert werden?
 Können (System-) Dienste manipuliert werden?
Diese Fragen sind zunächst unter lokaler, individueller Perspektive des jeweiligen Systems
zu betrachten. Anschließend ist in einem zweiten Schritt zu klären, welche Möglichkeiten
prinzipiell bestehen, die Leittechnikkomponenten über die Leittechniknetzwerke anzugreifen
(Missbrauch einer vorhandenen LT-Komponente, Anschluss einer unzulässigen
Fremdkomponente). Die Antworten zu diesen Fragen fließen als Daten in die Attack Tree-
Modelle ein. Die Erarbeitung der Attack Tree-Modelle bildet die wesentliche Aufgabe des
Analyseteams - neben der Betrachtung der resultierenden Analyseergebnisse und der sich
ergebenden Sicherheitsmetrik.
Die Herleitung der Attack Tree-Modelle erfolgt – wie beschrieben – zwar manuell bzw.
teilautomatisiert, jedoch reduziert die angewendete Vorgehensweise das Risiko,
Systemschnittstellen zu übersehen. Diese systematische Erfassung der Angriffspfade
vermeidet eine Abhängigkeit der Analyseergebnisse von der personellen Zusammensetzung
des Analyseteams.
Die praktische Anwendung der Attack Tree-Methode ist nun wie folgt: Die Attack Trees
erhalten den jeweiligen Rechnertyp als Start- bzw. Wurzelknoten. Auf der untergeordneten
Blattebene folgen die berücksichtigten Schutzziele (hier: Verfügbarkeit, Integrität). Die
nachfolgenden Ebenen werden dann so weit detailliert, bis entweder ein Knoten mit
eindeutig identifizierbarer Aussage hinsichtlich
Seite 86 von 262
a) Angreifer-Voraussetzung (pink) oder

b) Systemvoraussetzung (grün)
gefunden wird (siehe Beispiel in Abbildung 11). Die unterlagerten Detailblätter sind als
Voraussetzung für die übergeordnete Angriffsmöglichkeit aufzufassen. Enthält ein Knoten
mehr als ein Blatt in der darunterliegenden Detailebene, sind diese im Sinne einer UND bzw.
ODER-Verknüpfung aufzufassen (je nach Kennzeichnung).
Die Vorteile der Attack Tree-Methode sind, dass sich der Detaillierungsgrad je nach
Anforderung anpassen lässt. Die erhaltenen Ergebnisse stehen für spätere
Wiederverwendungen bzw. Ergänzungen / Erweiterungen zur Verfügung: zu jedem Zeitpunkt
lassen sich die Attack Tree-Graphen für die verschiedenen Systeme sowohl hinsichtlich der
zu betrachtenden Komponenten als auch hinsichtlich einer veränderten Bedrohungslage
anpassen. Solange die Attack Tree-Modelle nicht verändert werden, d.h. solange es keine
Änderung an der Zielanlage gibt, sind die Ergebnisse von Wiederholungsprüfungen
konsistent hinsichtlich der Leittechniksystemeigenschaften.
In Abbildung 11 ist als Beispiel ein Ausschnitt des Attack Tree für ein HMI-Client-System
wiedergegeben. Zur besseren Übersicht und Bearbeitung des Attack Tree wurde der
ursprünglichen Darstellung nach (Schneier, 1999) eine vertikale Struktur hinzugefügt:
 Wurzelknoten
Links oben steht der Gerätetyp als Wurzelknoten zur Identifikation der Geräteklasse.
 Schutzziele
Darunter folgen zur besseren Strukturierung jene Schutzziele (hier: Integrität), die im
Rahmen der jeweiligen Angriffsvarianten adressiert werden.
 Angriffsziele
Als nächsten Klassifikationsschritt wurden die potentiellen Angriffsziele eines
Systems aufgeführt: die Datenausgabe zu anderen Systemen sowie die
Datenspeicher der betrachteten Komponente.
 Angriffsvarianten
Schließlich folgen die verschiedenen Angriffsvarianten (z.B. Manipulation von
Sollwerten oder Benutzerdaten).
Die Ergänzungen der Attack Tree-Struktur gegenüber dem Schneier-Vorschlag dienen

ausschließlich der Verbesserung der praktischen Handhabbarkeit der Modelle.
Seite 87 von 262

Die Endpunkte der einzelnen Zweige in den Attack Trees stellen die Voraussetzungen für die
Angriffsvarianten dar. Die farblichen Unterschiede weisen auf die Zuordnung der
Voraussetzung zum Angreifer (Farbe: pink) oder zum Leitsystem (Farbe: dunkelgrün) hin.
An dieser Stelle soll kurz auf die naheliegende Frage eingegangen werden, wie die typische
Komplexität sowie Vielfalt von Angriffsszenarien in Netzwerken beherrscht wird. Die
Beantwortung dieser Frage umfasst zwei Bereiche:
 Die (generischen) Angriffsszenarien in den Attack Tree-Modellen bilden die

möglichen Angriffsvarianten ab.
 Das Ablaufsystem der automatisierten Analyse (PROLOG-System) verfügt über die

notwendigen Klauseln, um den Matching-Prozess durchzuführen (siehe 7.2,
Abbildung 47).
Die Beschreibung der Angriffsvoraussetzungen in den Attack Tree-Modellen erfolgt in Form

eines Schemas:
Typ_Ausgangssystem / Typ_Schnittstelle_Ausgangssystem / Typ_Zielsystem)
Die PROLOG-Basisklauseln in (siehe 7.2, Abbildung 47, in ‚solution.pl‘) suchen die Lösung
in folgenden schematischen Schritten:
1) „System1 = Typ_Ausgangssystem“
UND „System1 hat Typ_Schnittstelle_Ausgangssystem“
2) „System2 = Typ_ Zielsystem“
3) „Existiert Netzverbindung (System1, System2)“
Die PROLOG-Basisklauseln umfassen nicht nur Klauseln, die Systemeigenschaften der

Anlagenkomponenten ableiten, sondern auch Klauseln, die komplexe Suchaufgaben
ausführen, z.B. Suche eines Verbindungspfades zwischen zwei Systemen innerhalb eines
(ge-switchten) Netzes.
Seite 88 von 262

Abbildung 11: Ausschnitt eines Attack Tree für ein HMI-Client-System
Seite 89 von 262

Die in Abbildung 11 eingeführte Unterscheidung der Angriffsvoraussetzungen nach

„Angreifer-relevant“ und „systembedingt“ erfolgte nicht nur zum Zweck einer verbesserten
Handhabung der Attack Tree-Darstellungen, die je nach Anlagengröße und Detaillierung
einen erheblichen Umfang annehmen können, sondern auch aus methodischen Gründen.
Die system-relevanten Voraussetzungen reduzieren die generischen Angriffsszenarien auf
die systembedingt möglichen Angriffsszenarien. Diese systembedingt möglichen
Angriffsszenarien lassen sich durch Berücksichtigung der Angreifer-relevanten
Voraussetzungen auf die vom Angreifer durchführbaren Angriffsszenarien reduzieren, d.h.
jene Szenarien, die aufgrund der Eigenschaften der Angreifer (Kompetenzen,
Zugangsmöglichkeiten, Ausrüstung) ausführbar sind (siehe Abbildung 12). Kapitel 5.4 geht
auf die formalen Aspekte dieser Überlegungen ein.
Abbildung 12: Beziehungen zwischen Angriffsszenarien und den Voraussetzungen
Seite 90 von 262

Die Abhängigkeit der möglichen Angriffsszenarien von den Eigenschaften des betrachteten
Zielsystems soll an einem Beispiel verdeutlicht werden: Alle generischen Angriffsszenarien,
die als Voraussetzung auf eine USB-Schnittstelle angewiesen sind, lassen sich nur gegen
jene Systeme anwenden, die über eine aktivierte (!) USB-Schnittstelle verfügen. Im Falle
einer mechanischen, elektrischen oder per Konfigurationseinstellungen nachhaltig
deaktivierten USB-Schnittstelle sind alle USB-basierten Angriffsszenarien aus der Menge der
systembedingt möglichen Angriffsszenarien zu entfernen.
An dieser Stelle soll noch kurz auf die Angreifer-seitigen Voraussetzungen – hinsichtlich der
weiteren Verwendung im Rahmen des vorgeschlagenen Analysekonzeptes – eingegangen
werden. In den vorangegangenen Kapiteln wurde nachgewiesen, dass die Ergebnisse
existierender Analysekonzepte zur Beurteilung der IT-Sicherheit von leittechnischen
Systemen auf spekulativen Annahmen bezüglich der Fähigkeiten und Möglichkeiten
potentieller Angreifer beruhen. Die oben dargestellte Abhängigkeit der durch den Angreifer
realisierbaren Angriffsszenarien (siehe Abbildung 12) von den Angreifer-relevanten
Voraussetzungen darf nicht zu dem methodischen Fehler führen, Angriffsszenarien aufgrund
eben dieser spekulativen Annahmen aus dem Analyseprozess zu eliminieren. Wie im
weiteren Verlauf der Darstellung dieses neuen Analysekonzeptes noch zu zeigen sein wird,
dienen diese Angreifer-seitigen Voraussetzungen der Bestimmung des Schwierigkeitsgrades
des betreffenden Angriffsszenarios. Dieser Schwierigkeitsgrad ermöglicht die Abbildung der
Angriffsszenarien auf das vom Anlagenbetreiber akzeptierte Niveau der Angriffshürden. Zu
diesem Zweck ist eine Unterteilung der Voraussetzungen, die der Angreifer für einen
erfolgreichen Angriff zu erfüllen hat, in die Kategorien „Zugang“, „Kompetenz“ und
Ausrüstung“ hilfreich.
5.4 Formale Betrachtung des Analyseprozesses
5.4.1 Formale Methoden des Analyseprozesses
Kapitel 5.1 skizzierte den prinzipiellen Verlauf des vorgeschlagenen Analyseprozesses

(siehe auch Abbildung 6). Bevor auf die einzelnen Prozessschritte im nächsten Abschnitt
näher eingegangen wird, sollen zunächst die formalen Methoden erläutert werden.
Kern des vorgeschlagenen Analysekonzeptes ist es, die Voraussetzungen denkbarer

Angriffsszenarien dahingehend zu überprüfen, ob diese Voraussetzungen durch die
systemtechnischen Eigenschaften der Zielanlage gegeben sind. Bei der Analyse handelt es
sich also um einen Suchprozess, dessen Ergebnis eine Liste der ausführbaren
Seite 91 von 262
Angriffsszenarien umfasst. Als Datengrundlage für diese Suche dienen die Beschreibungen
der Angriffsszenarien (hier: der Voraussetzungen) und der Anlagentopologie (Systeme und
Komponenten, Netzwerksegmente, Schnittstellen usw.). Zur Automatisierung dieser Suche
bietet sich ein deklaratives Programmiermodell an, das eine Suche in einem Graphen
unterstützt. Im Rahmen der vorliegenden Arbeit bot sich deshalb ein PROLOG-basiertes
System als experimentelle Programmierumgebung an.
PROLOG als Programmiersprache ist in der Literatur umfassend beschrieben. Exemplarisch

sei auf das Standardwerk (Clocksin, et al., 2003) verwiesen. Als Beispiel soll an dieser Stelle
das Anwendungskonzept stark vereinfacht dargestellt werden.
Mittels prädikatelogischer Ausdrücke lassen sich Informationen bezüglich der

Angriffsszenarien (vereinfacht) folgendermaßen darstellen:
Die allgemeingültige Aussage
„Ein Angriffsszenario mit der Kennung SID setzt die Voraussetzungen REQ1 und
REQ2 voraus.“
lässt sich in Form folgender PROLOG-Prädikate ausdrücken, worin die Terme SID, REQ1
und REQ2 Variablen darstellen:
scenario(SID, REQ1, REQ2).
Hinweis: PROLOG-Klauseln schließen mit einem Punkt ab.
Die allgemeingültige Aussage
„Ein Rechner mit der Kennung HID verfügt über die Konfigurationen CONF1 und
CONF2.“
lässt sich in folgender Form ausdrücken, worin die Terme HID, CONF1 und CONF2
Variablen darstellen:
host(HID, CONF1, CONF2).
Die Beschreibung konkreter Angriffsszenarien ersetzt in den o.g. Prädikaten die Variablen
durch Fakten:
scenario(1, usb, autorun).
scenario(2, cdDvd, autorun).
Diese Klauseln beschreiben, dass das Angriffsszenario 1 eine USB-Schnittstelle sowie eine
aktivierte (MS Windows) Auto-run-Funktion voraussetzt, während Szenario 2 anstelle einer
USB-Schnittstelle ein CD- bzw. DVD-Laufwerk erwartet.
Seite 92 von 262
Die Beschreibung der Rechner mit Hilfe der host-Klausel erfolgt in PROLOG beispielsweise
wie folgt:
host(server1, usb, none).
host(server2, cdDvd, autorun).
Die Fakten dieser Klauseln sollen festlegen, dass
 das System „Server 1“ über eine USB-Schnittstelle verfügt, während
 das System „Server 2“ ein CD- bzw. DVD-Laufwerk enthält und die Windows
Autorun-Funktion aktiviert ist.
Mit dem Fakt „none“ wird lediglich festgelegt, dass die entsprechende Variable mit keinem
(leittechnischen) Inhalt besetzt ist.
Eine Datenbasis, die die oben dargestellten scenario- und host-Fakten enthält, kann nun in
unterschiedlichen Weisen genutzt werden. Zum Zwecke der vorgeschlagenen
Anlagenanalyse sind folgende Fragestellungen sinnvoll:
 Welche der Angriffsszenarien sind aufgrund der leittechnischen Randbedingungen

möglich?
 Gegen welche Systeme sind erfolgreiche Angriffsszenarien ausführbar?
Mit den Mitteln der Prädikatelogik lässt sich die erste Frage wie folgendermaßen darstellen:
scenario(SID, X, Y)  host(HID, X, Y)  critical(SID, HID)
Anmerkung: im Rahmen dieses stark vereinfachten Beispiels wird auf programmtechnischen Aspekte
wie z.B. der Prüfung auf vertauschte Variablenpositionen der Übersichtlichkeit wegen nicht eingegangen.
Diese Syntax beschreibt die Suche nach einer Lösung in der Datenbasis, für die gilt:
scenario-Variable REQ1 = host-Variable CONF1 (freie Variable „X“)
scenario-Variable REQ2 = host-Variable CONF2 (freie Variable „Y“)
Als Ergebnis der Suche in der Datenbasis werden für die übereinstimmenden scenario- und
host-Datensätze jeweils die Variablen „SID“ und „HID“ ausgegeben.
PROLOG ermöglicht die erste Frage unter Berücksichtigung obiger Anmerkung wie folgt:
scenario(SID, X, Y)  host(_, X, Y).
Anmerkung: in der host-Klausel dient das Zeichen „_“ als Platzhalter für einen Term, der für das
Ergebnis ohne Bedeutung ist.
Seite 93 von 262

Als Ergebnis erhält man die Variablen SID und HID für jene host- und scenario-Datensätze,
deren Variablen X und Y übereinstimmen:
SID = 2
Die Frage 2 nach Systemen gegen die Angriffsszenarien möglich sind, lässt sich in
PROLOG-Syntax wie folgt formulieren:
scenario(_, X, Y)  host(HID, X, Y).
Als Ergebnis erhält man die Rechnerkennung
HID = server2
Das kleine Beispiel zeigt, dass PROLOG die Formulierung logischer Fragestellung
ermöglicht, ohne dass ein Suchalgorithmus neu implementiert werden muss.
5.4.2 Verlauf des Analyseprozesses
Nachdem der vorangegangene Abschnitt die formalen Methoden erläuterte, sollen nun auf
dieser Basis der in Kapitel 5.1 (siehe hierzu Abbildung 6) skizzierte Analyseverlauf in 5
Schritten beschrieben werden. Die Details der Schritte 1 … 4 sind anschließend in den
Abschnitten 5.4.3 bis 5.4.6 dargestellt. Dem Konzept der Sicherheitsmetrik ist danach das
eigenständige Kapitel 6 gewidmet.
Wie bereits erwähnt, unterscheidet sich die Vorgehensweise des in der vorliegenden Arbeit
vorgeschlagenen Analyseansatzes von den in Kapitel 4 dargestellten Analysemethoden.
Anstatt das Risiko eines erstmaligen, hypothetischen und/oder erfolgreichen Angriffes
unbekannter Angreifer zu bestimmen, geht der faktenbasierte Ansatz einen neuen Weg:
zunächst erfolgt die systematische Zusammenstellung denkbarer Angriffsszenarien gegen
die Zielanlage. Anhand der Abbildung der Voraussetzungen dieser Szenarien auf die
Eigenschaften der Zielsysteme erhält man dann die Untermenge der technisch möglichen
Angriffsszenarien. Die Voraussetzungen dieser Szenarien stellen auch die Voraussetzungen
hinsichtlich Kompetenzen, Ausrüstung und Zugangsmöglichkeiten der Angreifer dar. Diese
Angreifer-Kategorisierung ermöglicht dem Anlagenbetreiber in nachvollziehbarer Weise,
seine Risikoakzeptanz - im Sinne von Angriffshürden – zu definieren. Gegen jene
Angriffsszenarien mit inakzeptabel niedrigen Angriffshürden kann der Betreiber geeignete
Maßnahmen ergreifen. Aus den systematisch erhaltenen Angriffsdaten und
Systemeigenschaften lässt sich eine Sicherheitsmetrik ableiten.
Seite 94 von 262

Schritt 1: Herleitung generischer Angriffsszenarien
Wie in 5.3.3 beschrieben, sind zunächst die Angriffsszenarien mit Hilfe der Attack Tree-
Methode zusammenzutragen. Die Ergebnisse lassen sich in Tabellenform zusammentragen
(siehe Tabelle in Abbildung 13) und liegen zur Weiterverarbeitung in Form von PROLOG-
Relationen vor.
Schritt 2: Beschreibung der Zielanlage
Der nächste Schritt dient der Beschreibung der Zielanlage in einer Form, die ebenfalls zur
weiteren systemgestützten Verarbeitung geeignet ist. Grundlage dieses Schrittes ist die
Zusammenstellung der erforderlichen Anlagendaten. Abbildung 15 zeigt eine räumliche
Darstellung einer einfachen, beispielhaften Leittechnikanlage.
Schritt 3: Abbildung der Angriffsszenarien auf die Zielanlage
Der nächste Schritt stellt den ersten (automatisiert durchführbaren) Analyseschritt dar. Für
einen erfolgreichen Angriff gegen Leittechniksysteme, d.h. die konkrete Umsetzung eines
allgemeingültigen Angriffsszenarios, müssen die Zugangsvoraussetzungen durch den
Anlagenbetreiber (= Systemvoraussetzungen) gegeben sein. Nur falls diese
Zugangsvoraussetzungen vorliegen, hat ein Angreifer die Möglichkeit, mittels Knowhow und
Ausrüstung einen Angriff erfolgreichen durchzuführen.
Schritt 4: Ableitung der Angreifer-Voraussetzungen der umsetzbaren Angriffsszenarien
Nachdem im vorangegangenen Schritt 3 der Übergang von den generischen

Angriffsszenarien auf die systemtechnisch bedingten, umsetzbaren Angriffsszenarien
erfolgte, müssen aus den realisierbaren Angriffsszenarien die Voraussetzungen, die die
Angreifer zu erfüllen haben abgeleitet werden. Diese Informationen bestimmen die
Schwierigkeitsgrade, die den einzelnen Angriffsszenarien entgegenstehen.
Seite 95 von 262

Schritt 5: Matrixbildung
Abschließend sind die im vorangegangenen Schritt erhaltenen Angriffsvoraussetzungen in

ein normiertes Schema (Metrik) zu überführen, um eine Aussage hinsichtlich der IT-
Sicherheit der Zielanlage zu erhalten.
Dieser Analyseverlauf ist in den nachfolgenden Abschnitten 5.4.3 … 5.4.6 detailliert

beschrieben.
5.4.3 Beschreibung der Angriffsszenarien
Die Ergebnisse der Attack Tree-Analyse, d.h. die gefundenen Angriffsszenarien, lassen sich
für die spätere Weiterverarbeitung tabellarisch darstellen. Abbildung 13 und Abbildung 14
zeigen in Ausschnitten die systemseitigen sowie die angreiferseitigen Voraussetzungen.
Die Szenario-Daten lassen sich in drei Kategorien strukturieren:
 Allgemeine Szenario-Informationen
Hierzu zählen die Szenario-Kennung, die Szenario-Bezeichnung, das Schutzziel und
das Zielsystem des betreffenden Szenarios.
 Informationen über die angreiferseitigen Voraussetzungen

Hierzu zählen die Anforderungen hinsichtlich des Knowhow, der Ausrüstung und der
Zugangsmöglichkeiten.
 Informationen über die systemseitigen Voraussetzungen

Hierzu zählen die Voraussetzungen, die systemseitig vorhanden sein müssen, um ein
Angriffsszenario erfolgreich umsetzen zu können.
Zur Verbesserung der Übersichtlichkeit und Handhabbarkeit erfolgt die Abbildung der
Szenarien in PROLOG-Klauseln in Form einer Aufspaltung der Szenarien in drei Teile:
1) Formale Informationen eines Szenarios
2) Beschreibung der Voraussetzungen auf Betreiberseite (systemtechnischen

Voraussetzungen) und
3) Beschreibung der Angreifer-Voraussetzungen
Seite 96 von 262

Zur Beschreibung der formalen Aspekte dient die scenarioD-Relation:
scenarioD(SZENARIO-ID, ZIELSYSTEM, ANGREIFERSYSTEM, SCHUTZZIEL, SZENARIONAME)
Als Beispiel seien für die Szenarien 1 ... 3 die entsprechenden Fakten mittels scenarioD-
Beziehung abgebildet:
scenarioD(1.1, hmiClient, hmiClient, integrity, manipulateUserCredentials).

scenarioD(2.1, hmiClient, malDevice, integrity, manipulateUserCredentials).
scenarioD(3.1, hmiClient, anyClient, integrity, manipulateUserCredentials).
scenarioD(3.2, hmiClient, anyClient, integrity, manipulateUserCredentials).
Hinweis: die Szenarien 1 und 3 wurden jeweils in zwei Szenarien aufgespalten, um später
die alternativen Systemvoraussetzungen (USB oder CD/DVD) in einfacher Weise abbilden
zu können.
Die Voraussetzungen, die Angreifer zu erfüllen haben, lassen sich als Fakten mit Hilfe
folgender PROLOG-Beziehung abbilden:
scenarioA(SCENARIO-ID, ZIELSYSTEMTYP, ANGRIFFSQUELLE, REQUIREMENT1,

REQUIREMENT2, REQUIREMENT3, REQUIREMENT4).
Folgende Fakten wurden beispielhaft erfasst:
scenarioA(1.1, locationAccess, osKnowhow, userName, password, none).

scenarioA(2.1, locationAccess, osKnowhow, none, none, none).
Als Ergebnis dieses Schrittes stehen die Fakten der Angriffsszenarien, die im Rahmen der
Attack Tree-Analyse gefunden wurden, zur Weiterverarbeitung in Form von PROLOG-
Relationen zur Verfügung.
Die oben beschriebenen PROLOG-Klauseln bilden die Voraussetzungs-Datenbasis für die

automatisierte Analyse.
Seite 97 von 262

Abbildung 13: Angriffsszenarien gegen HMI-Clients / Systemeigenschaften (Ausschnitt)
Seite 98 von 262

Abbildung 14: Angriffsszenarien gegen HMI-Clients / Angreifer-Voraussetzungen (Ausschnitt)
Seite 99 von 262

5.4.4 Beschreibung der leittechnischen Anlage
Für die automatisierte Analyse der Anlagenstruktur ist es notwendig, eine Leittechnikanlage
in geeigneter Weise zu beschreiben. Die Anlagenstruktur zerfällt dafür in die
Informationsbausteine
 Netzwerktopologie
 Gerätebeschreibung
 Gerätekonfiguration
 Sonstige Anlageninformationen
Zentrale Informationsquelle für Anlagendaten ist ein Netzwerkplan der untersuchten

Zielanlage (siehe die vereinfachte Darstellung der räumlichen Verteilung in Abbildung 16).
Abbildung 15: Beispielschema einer leittechnischen Anlage
Seite 100 von 262

Neben der Beschreibung der Leittechnikkomponenten ist es notwendig, die Netzwerkstruktur

zu erfassen (siehe Abbildung 16):
Abbildung 16: Darstellung der Netzwerkstruktur des Beispiels
Aus diesen Darstellungen sind folgende Informationen zur Anlagenbeschreibung ableitbar:
Netzwerktopologie
Die Netzwerktopologie beschreibt, welche Netzwerk-Switch-Geräte ein Netzwerk-Segment

aufspannen:
Netzwerk-Segment Switch-Gerät
<Segment-Kennung> <Switch-Kennung>
Beispiel
HMI-LAN SW-01
Seite 101 von 262

Die Zuordnung der Netzwerksegmente zu Switch-Geräten lässt sich in Form folgender

PROLOG-Relation wiedergeben:
net (netzwerkSegment, switchID ).
Beispiel:
net (hmiLAN, SW01 ).
Neben der Beschreibung der Netzwerk-Segmente müssen auch die an ein Netzwerk-
Segment angeschlossenen Endgeräte beschrieben werden:
Switch-Gerät Switch-Port (Anschlusselement) Gerätekennung
<Switch-Kennung> <Port-Kennung> <Systemkennung>

Beispiel
SW-01 Port-1 ThinClient-01
Der Anschluss von Rechnersystemen an Switch-Ports lässt sich in Form folgender

PROLOG-Relation wiedergeben:
switch ( switchID, portID, systemID ).
Beispiel:
switch ( SW01, port1, tc01 ).
Gerätebeschreibung
Die Beschreibung der im Netzwerk befindlichen Geräte umfasst folgende Daten:
Gerätetyp Gerätekennung Örtlichkeit
<Gerätetype> <Systemkennung> <Aufbauort>

Beispiel
HMI-Client ThinClient-01 Hauptleitstand
Die Beschreibung der im Netzwerk vorhandenen Systeme und Geräte durch den Systemtyp,
Systemkennung und Aufbauort lässt sich in Form folgender PROLOG-Relation wiedergeben:
Seite 102 von 262

deviceType ( systemType, systemID, location )
Beispiel:
deviceType ( hmiClient, tc01, hauptleitstand).
Gerätekonfiguration
Relevant für die Betrachtung der Angriffspfade sind Informationen bezüglich der
Geräteschnittstellen und ggf. welche Geräte daran angeschlossen sind:
Gerätekennung
Gerätetyp Gerätekennung Schnittstellentyp
(angeschlossenes Gerät)
<Gerätetype> <Systemkennung> <Schnittstellenkennung> <Gerätekennung >
Beispiel
HMI-Client ThinClient-01 USB kein
Die Beschreibung der System- und Gerätekonfigurationen durch den Systemtyp,

Systemkennung, Schnittstelle und Kennung des angeschlossenen Systems bzw. Gerätes
lässt sich in Form folgender PROLOG-Relation wiedergeben:
config ( systemType, systemID, interface, deviceID ).
Beispiel:
config (hmiClient, tc01, usb, none ).
Sonstige Anlageninformationen
Schließlich werden für die Analyse noch allgemeine Anlageninformationen benötigt. Für eine
Analyse möglicher Angriffe ist es wichtig zu wissen, welche Örtlichkeiten permanent mit
SCADA-Bedienpersonal besetzt sind und wo SCADA-Systeme permanent ohne
Beaufsichtigung arbeiten:
Örtlichkeit Personalverfügbarkeit
<Aufbauort> <Personalstatus>
Beispiel
Hauptleitstand permanent
Seite 103 von 262

Diese Informationen bezüglich der Personalverfügbarkeit in den Räumlichkeiten mit

Komponenten der Leittechnikanlage lassen sich in Form folgender PROLOG-Relation
abbilden:
staff ( location, permanentPersonal ).
Beispiel:
staff ( hauptleitstand, yes ).
Als Ergebnis dieses Schrittes steht die Anlagenbeschreibung zur Weiterverarbeitung in Form
von PROLOG-Relationen zur Verfügung.
Die oben beschriebenen PROLOG-Klauseln bilden die Anlagen-Datenbasis für die

automatisierte Analyse des nächsten Schrittes.
5.4.5 Abbildung der Angriffsszenarien auf die Zielanlage
Die beiden vorangegangenen Abschnitte beschrieben die Überführung der Daten der
generischen Angriffsszenarien (5.4.3) sowie der Zielanlage (5.4.4) in ein zur
Weiterverarbeitung geeignetes Format. Auf dieser Basis sollen nun die zielanlagentypischen,
realisierbaren Angriffsszenarien automatisiert gefunden werden.
Der Suchalgorithmus implementiert eine Abbildung der Voraussetzung für die gefundenen
Angriffsszenarien (aus 5.4.3) auf die technischen Eigenschaften der Zielanlage (aus 5.4.4).
Alle Angriffsszenarien, deren Voraussetzungen durch die Zielanlage erfüllt sind, bilden die
Menge der „kritischen“ (weil ausführbaren) Angriffsszenarien. Formal lässt sich dieser Schritt
wie folgt beschreiben:
generischeSzenarien(IDSZ, REQSYSTEM)  zielAnlage(IDSYSTEM, PROPERTYSYSTEM)
 kritischeSzenarien(IDSZ, IDSYSTEM, REQSYSTEM = PROPERTYSYSTEM)
mit generischeSzenarien = Beschreibungs-Klauseln der generischen Angriffsszenarien
IDSZ = Szenario-Kennungen
REQSYSTEM = systemtechnische Angriffsvoraussetzungen der Szenarien
zielAnlage = Beschreibungs-Klauseln der Komponenten der Zielanlage
IDSYSTEM = Zielsystem-Kennungen
PROPERTYSYSTEM = systemtechnische Eigenschaften der Zielsysteme
Seite 104 von 262

kritischeSzenarien = Menge der identifizierten Angriffsszenarien und Zielsystemen, bei

denen die systemtechnischen Angriffsvoraussetzungen der Szenarien und die
systemtechnischen Eigenschaften der Zielsysteme übereinstimmen
Das Ergebnis dieser Abbildung liefert die Menge jener generischen Angriffsszenarien, bei
denen die systemtechnischen Angriffsvoraussetzungen der Szenarien (REQSYSTEM) mit den
systemtechnischen Eigenschaften der Zielsysteme (PROPERTYSYSTEM) übereinstimmen. Die
Variablen IDSZ und IDSYSTEM liefern die Identifikation des ausführbaren Angriffsszenarios
sowie die betroffene Systemkomponente.
Zentraler Baustein bei der Bestimmung dieser „kritischen“ Szenarien ist die scenario-
Relation. Diese Klausel setzt für jedes Szenario die Voraussetzungen (siehe Abbildung 13)
um und schreibt die Ergebnisse in eine Datei.
scenario(SC):-
((SC = 1.1), scenarioD(SC, T, S, _, A), systemOperating(T, SID, L), cdDvd(T, SID));
((SC = 1.2), scenarioD(SC, T, S, _, A), systemOperating(T, SID, L), usb(T, SID));
((SC = 2.1), scenarioD(SC, T, ST, _, A), deviceType(T, SID, _), openSwitchPort(SW, L),
netConnection(SID, open, SW));
((SC = 3.1), scenarioD(SC, T, S, _, A), anyClient(S, X), systemOperating(X, SID, L), cdDvd(X,
SID));
((SC = 3.2), scenarioD(SC, T, S, _, A), anyClient(S, X), systemOperating(X, SID, L), usb(X,
SID)).
Anmerkung: zur Verbesserung der Übersichtlichkeit und Lesbarkeit wurde auf die Angabe
der Klauseln zur Dateiausgabe verzichtet.
Hilfsklauseln prüfen auf der Basis der Anlagenbeschreibungen die Existenz der notwendigen
technischen Voraussetzungen (gemäß 5.4.4) indem sie geeignete logische Zusammenhänge
modellieren:
Beispiele für Hilfsklauseln:
systemOperating(ZIELSYSTEMTYP, SYSTEM-ID, LOCATION)
liefert die Systeminstanzen (System-ID), die dem gemäß Szenario geforderten

Systemtyp entsprechen, und den Ort des Systems.
Seite 105 von 262

cdDvd(ZIELSYSTEMTYP, SYSTEM-ID) bzw. usb(ZIELSYSTEMTYP, SYSTEM-ID)
prüft, welche Systeme über ein CD / DVD-Laufwerk bzw. eine USB-Schnittstelle

verfügen.
deviceType(ZIELSYSTEMTYP, SYSTEM-ID, _)
ermittelt die Systeminstanzen, die einem bestimmten Systemtyp entsprechen.
openSwitchPort(SWITCH, LOCATION)
liefert die Örtlichkeiten von Switch-Geräten, die einen offenen, ungenutzten

Netzwerk-Port konfiguriert haben.
netConnection(SYSTEM-ID, open, SWITCH)
liefert Systeminstanzen, die von einem offenen Netzwerk-Port eines Switch-Gerätes

aus erreichbar sind.
Als Ergebnis der Analyse erhält man die Auflistung, welche Szenarien sich aufgrund der
systemtechnischen Randbedingungen gegen die Anlage ausführen lassen. Die Fakten
werden in Form einer PROLOG-Beziehung generiert, um für die weitere Bearbeitung in
PROLOG verfügbar zu sein:
req(SZENARIO-ID, SZENARIONAME, LOCATION, ZIELSYSTEMTYP, SYSTEM-ID,

ANGRIFFSQUELLE).
Die automatisierte Analyse liefert auf Basis der Beispielanlage folgende Ergebnisse (für die
bereits oben dargestellten Beispiel-Szenarien 1 … 3):
req(1.1, manipulateUserCredentials, engineeringRaum, hmiClient, tc05, hmiClient).

req(1.1, manipulateUserCredentials, hauptLTRaum, hmiClient, tc09, hmiClient).
req(2.1, manipulateUserCredentials, ltRaum2, hmiClient, tc01, malDevice).
Seite 106 von 262


req(3.1, manipulateUserCredentials, hauptLTRaum, hmiClient, hmiS01, hmiServer).
req(3.1, manipulateUserCredentials, hauptLTRaum, hmiClient, histS01, appServer).
req(3.1, manipulateUserCredentials, hauptLTRaum, hmiClient, tsS01, appServer).
req(3.2, manipulateUserCredentials, hauptLTRaum, hmiClient, hmiS01, hmiServer).
req(3.2, manipulateUserCredentials, hauptLTRaum, hmiClient, histS01, appServer).
req(3.2, manipulateUserCredentials, hauptLTRaum, hmiClient, tsS01, appServer).
...
Das oben gezeigte Ergebnis stellt die Extraktion der möglichen, d.h. „kritischen“ Szenarien
dar, die aufgrund der systemtechnischen Eigenschaften gegen die Zielanlage möglich sind.
Es sei an dieser Stelle darauf hingewiesen, dass dies einen wesentlichen Unterschied zu
sonstigen Analysemethoden darstellt: die Auflistung der möglichen, d.h. kritischen
Angriffsszenarien basiert nicht auf mehr oder minder plausible Annahmen über die
Fähigkeiten und Möglichkeiten unbekannter Angreifer. Das Ergebnis wird automatisiert
durch die Verarbeitung von Fakten der gefundenen Angriffsszenarien und der zu
untersuchenden Zielanlage erreicht.
Seite 107 von 262

5.4.6 Herleitung der Voraussetzungen für kritische Angriffsszenarien
In Kapitel 5.4.3 (siehe auch Abbildung 14) wurden die Voraussetzungen aufgelistet, die ein
Angreifer zur Umsetzung der jeweiligen Szenarien erbringen muss.
Zur Abbildung in ein zur Weiterverarbeitung geeignetes Format diente die PROLOG-Klausel
„scenarioA“:

Beispielhaft lieferten die Szenarien 1 …3 folgende Daten, die als PROLOG-Fakten erfasst
wurden:

scenarioA(2.1, locationAccess, osKnowhow, none, none, none).
Die Analyse der Angriffsvoraussetzungen bildet die im vorangegangenen Kapitel 5.4.5

gefundenen kritischen Szenarien (req-Fakten) auf die Angreiferdaten der Angriffsszenarien
(scenarioA-Fakten) ab.
Die Voraussetzungen für einen anlagentypisch möglichen Angriff ergeben sich aus der Regel
reqs(SCENARIO-ID, SZENARIONAME, ZUGANG, LOCATION, ZIELSYSTEMTYP,

REQUIREMENT1, REQUIREMENT2, REQUIREMENT3, REQUIREMENT4) :--
req(SZENARIO-ID, SZENARIONAME, LOCATION, ZIELSYSTEMTYP, SYSTEM-ID,

ANGRIFFSQUELLE),

Das Mapping der kritischen Szenario-Fakten auf die Fakten der Angreiferdaten liefert die
Voraussetzungen hinsichtlich Knowhow und Equipment, die ein Angreifer für einen
erfolgreichen Angriff gegen die Beispielanlage (für die Beispiel-Szenarien 1… 3) erfüllen
muss:
Seite 108 von 262

reqs(1.1, manipulateUserCredentials, locationAccess, engineeringRaum, hmiClient,

osKnowhow, userName, password, none).
reqs(1.1, manipulateUserCredentials, locationAccess, hauptLTRaum, hmiClient, osKnowhow,
userName, password, none).
reqs(2.1, manipulateUserCredentials, locationAccess, ltRaum2, malDevice, osKnowhow,
none, none, none).
none, none, none).
none, none, none).
none, none, none).
none, none, none).
none, none, none).
none, none, none).
none, none, none).
none, none, none).
none, none, none).
Seite 109 von 262


reqs(3.1, manipulateUserCredentials, locationAccess, hauptLTRaum, hmiServer, osKnowhow,
reqs(3.1, manipulateUserCredentials, locationAccess, hauptLTRaum, appServer, osKnowhow,
reqs(3.2, manipulateUserCredentials, locationAccess, hauptLTRaum, hmiServer, osKnowhow,
Das Ergebnis dieses Analyseschrittes liefert damit für alle ausführbaren („kritischen“)
Angriffsszenarien die Voraussetzungen, die Angreifer erfüllen müssen, um die Szenarien
erfolgreich durchführen zu können. Für die Bildung einer Aussage hinsichtlich der IT-
Sicherheit der betrachteten Zielanlage stehen somit die notwendigen Informationen (im
Sinne der vorhandenen Hürden gegen mögliche Angriffe) zur Verfügung.
Auf den abschließenden Analyseschritt zur Bildung einer geeigneten Metrik für die
Beurteilung der IT-Sicherheit geht Kapitel 6 ein.
Dieses Kapitel 5 trug folgende, für die weitere Beurteilung der IT-Sicherheit von Leit- und
Automatisierungssystemen wesentliche Aspekte zusammen:
 Teilautomatisierbare Analysemethode
Der in Abschnitt 5.4.1 skizzierte 4-stufige Analyseprozess liefert die notwendigen Fakten zur
Beurteilung der IT-Sicherheit der betrachteten Leittechnikanlage. Ausgehend von den
Seite 110 von 262

Beschreibungen der Angriffsszenarien sowie der Zielanlage läuft der Analyseprozess

vollautomatisch ab.
 Wiederverwendbare Beschreibung von Angriffsszenarien
Für die Beschreibung der Angriffsszenarien stehen Attack Trees als Methode zur Verfügung.
Dieser Ansatz hat den Vorteil, dass bei wiederholter Betrachtung der Bedrohungslage nur
die zusätzlichen, d.h. neuen Bedrohungen zu erfassen sind. Die Datenerfassung der
Angriffsszenarien ist beliebig erweiterbar und setzt keine speziellen Werkzeuge bzw.
Anwendungen voraus.
 Wiederverwendbare Beschreibung der Zielanlage
Desgleichen gilt für die Beschreibung der Leittechnikanlage für die automatisierte Analyse:
lediglich Änderungen am betrachteten Zielsystem erfordern Änderungen der
Anlagenbeschreibung.
 Analyseergebnisse
In einem automatisierten Prozess liefert die vorgestellte Methode Anzahl und

Beschreibungen der ausführbaren Angriffsszenarien, d.h. der kritischen Angriffsszenarien.
Des Weiteren erhält man die Voraussetzungen seitens der Angreifer für erfolgreiche Angriffe
in Bezug auf Zugang, Ausrüstung und Kenntnisse.
 Beurteilung der Analyseergebnisse
Im Gegensatz zu den in Kapitel 4 skizzierten Analyseansätzen liefert die hier vorgestellte

Analysemethode Aussagen über die untersuchte Leittechnikanlage ohne Annahmen
undefinierter Faktenbasis oder Spekulationen über die in der Regel unbekannten Angreifer
sowie deren Fähigkeiten und Möglichkeiten. Das Ergebnis wird ausschließlich durch eine
formalisierte Verarbeitung von Fakten der gefundenen Angriffsszenarien und der zu
untersuchenden Zielanlage erreicht. Schließlich erlauben die gewonnenen Ergebnisse, d.h.
Anzahl und Art der kritischen Szenarien sowie die Angriffsvoraussetzungen für Angreifer,
Vergleiche zwischen Leittechnikanlagen: Unterschiede lassen sich eindeutig auf
unterschiedliche Bedrohungssituationen oder Ausprägungen der Leittechnikanlage
zurückführen. Subjektive Einschätzungen der Auditoren erschweren die Vergleichbarkeit
nicht, da sie keinen Eingang in die Ergebnisse finden.
Seite 111 von 262

Kapitel 6 Konzept einer Leittechnik-IT-Sicherheitsmetrik
6 Konzept einer Leittechnik-IT-Sicherheitsmetrik
6.1 IT-Sicherheitsmetrik – Wozu?
Angesichts der aktuellen Bedrohungslage für den Bereich der „kritischen Infrastrukturen“
stehen die Leitungsgremien betroffener Unternehmen in der Verantwortung, die Systeme zur
Führung der verfahrenstechnischen Prozesse ausreichend zu sichern. Bei einer ersten
Betrachtung lässt sich also die eingangs gestellte Frage dahingehend beantworten, dass
eine IT-Sicherheitsmetrik dem Zweck dient, den Status der IT-Sicherheit eines Leitsystems in
geeigneter Form abzubilden und darzustellen. Gemäß der Management-Weisheit, dass sich
nur managen lässt, was auch gemessen werden kann, dienen Metriken somit als Grundlage
für Führungs- und Handlungsentscheidungen in den Unternehmen.
Bei genauerem Hinsehen wirft die obige Antwort hinsichtlich des Zwecks einer Metrik jedoch
zwei neue Fragen auf:
a) Wie „misst“ man die IT-Sicherheit bzw. geeignete Basisgrößen?
b) Welche Prozessgrößen bilden eine hinreichende Messgrundlage für IT-Sicherheit?
Da „IT-Sicherheit“ keine eigenständige Größe darstellt, die einer direkten Erfassung im Sinne
einer Messung zugänglich ist, hat sich in der Literatur - aber auch in der Praxis - die
Vorgehensweise durchgesetzt, Sicherheit mittels auszuwählender Hilfsgrößen indirekt zu
bestimmen.
Betrachtet man die IT-Sicherheit im Kontext der Unternehmensführung, dann wird deutlich,
dass nicht die „IT-Sicherheit“ das eigentliche Ziel der Betrachtung darstellt, sondern das
damit verknüpfte Unternehmensrisiko. Verfügt die Unternehmens- oder Bereichsleitung über
ein hinreichend genaues Abbild des Sicherheitsniveaus der Anlage, können ggf. notwendige
technische Maßnahmen zur Verbesserung der Sicherheit oder anderweitige, nicht-
technische Maßnahmen (z.B. Risikotransfer mittels Versicherung) zur Senkung des
Unternehmensrisikos ergriffen werden.
Ungeachtet der Bedeutung der IT-Sicherheit als Baustein des Risikomanagements

behandelt das vorliegende Dokument im weiteren Verlauf „IT-Sicherheit“ als zentrales
Element der Betrachtung.
Seite 112 von 262

6.2 Begrifflichkeiten
Im Zusammenhang mit IT-Sicherheitsmetriken sind zwei Begriffe von zentraler Bedeutung:

Messung und Metrik. In der Literatur findet man insbesondere für den Begriff „Metrik“
unterschiedliche Interpretationen.
Einen Überblick über eine Reihe von Definitionen geben (Masera, et al., 2010):
Das „New Oxford American Dictionary“ definiert eine Metrik als ein System oder eine
standardisierte Messung.
In der Mathematik und der Physik fasst man eine Metrik als eine binäre Funktion eines
topologischen Raumes auf, die für beliebige zwei Punkte des Raumes einen Wert
zurückgibt, der gleich der Distanz zwischen ihnen ist oder einen Wert, der als Analogon zur
Entfernung der Punkte zum Zwecke der Analyse dient. Wichtige Eigenschaften einer Metrik
(hier: im Sinne einer Funktion) sind die Symmetrie sowie die Dreiecksungleichung.
Etwas spezifischer hinsichtlich „IT-Sicherheit“ werden Metriken auch folgendermaßen

interpretiert:
Im Kontext der IT-Sicherheit helfen Metriken bei der Quantifizierung von Auswirkungen von
Angriffen.
(Illingworth (Edt.), 1991) definiert eine Metrik als informellen Namen einer Messung oder als
Größe, die den Grad einer begrifflichen Software-Eigenschaft repräsentiert.
(Moily, 2011) beschreibt Metrik etwas unscharf als eine Kategorie von Werkzeugen, die
Entscheider nutzen, um Daten in verschiedenen Bereichen von Organisationen zu
beurteilen. In einfachster Form stellt eine Metrik eine Messung dar, die mit einer Skala oder
einem Vergleichswert verglichen wird, um ein nützliches Ergebnis zu liefern.
Erfasste Messdaten, die in den Kontext von Vergleichsdaten gestellt werden, bilden danach
ein funktionales Konstrukt namens „Metrik“.
Im Zusammenhang mit IT-Sicherheit trennt (Hayden, 2010) die beiden Begriffe eindeutig:
Er definiert eine Metrik als Ergebnis. Sie dient als begriffliches Verzeichnis, das
Informationen definiert und normiert.
Im Gegensatz dazu fasst er „Messung“ als Aktivität auf, im Rahmen der Beobachtungen
durchgeführt und Daten gesammelt werden. Ziel ist, einen praktischen Einblick in ein
untersuchtes Thema zu erlangen.
Seite 113 von 262

In diesem Sinne beschreibt Messung alle Aktivitäten, die der Beobachtung und Sammlung
der Basisdaten dienen, während eine Metrik die Daten in den Kontext der betrachteten
Domäne stellt und in normierter Form zur weiteren Verarbeitung bereitstellt.
(Payne, 2006) definiert die Begriffe auf Basis einer eher praktischen Herangehensweise:
Messungen stellen danach einzelne, zeitbehaftete Sichten auf spezifische, diskrete

Faktoren, während Metriken durch Vergleich mit einer vordefinierten Datenreihe resultieren.
Kurz gesagt: Messungen sind das Ergebnis von Zählung(en), während Metriken durch
Analyse entstehen. Payne fasst Messungen als (objektive) Rohdaten auf. Allerdings weist
sie darauf hin, dass Metriken entweder „objektive oder subjektive menschliche
Interpretationen“ der Rohdaten darstellen. Sie betont also, dass neben der notwendigen
Kontextbildung auch die subjektive Betrachtung die Beurteilung der IT-Sicherheit
beeinflussen kann. Um dieser Beeinflussung zu begegnen, empfiehlt sie SMART-Metriken
anzuwenden. Brauchbare Metriken sollten also spezifisch, messbar, erreichbar,
wiederholbar und zeitabhängig sein.
(Hayden, 2010) betont die Bedeutung der Messung im Rahmen einer reproduzierbaren und
systematischen Vorgehensweise: Messungen ermöglichen, über subjektive Sprache und
individuelle Erfahrung hinauszugehen und stellen ein allgemeingültiges Konzept für
Beobachtung und Vergleich dar. Außerdem helfen Messungen bei der Handhabung von
Uneinigkeiten und Fehler, indem sie helfen, Kriterien zu standardisieren und Werte zu
normieren. Schließlich lassen sich die Ergebnisse gegen Vergleichsdaten validieren.
Auf die Tatsache, dass auch präzise gemessenen Daten, u.U. keine exakte Aussage über
das Niveau der IT-Sicherheit erlauben, geht Kapitel 6.3 ein.
(Juneja, et al., 2011) definieren Metrik als Hilfsmittel zur Entscheidungsfindung und
verweisen auf den Prozesscharakter einer Zustandsüberwachung sowie der Verbesserung
betrachteter Aktivitäten: Metriken werden als Hilfsmittel zur Entscheidungsfindung,
Leistungsverbesserung sowie der Zuordnung von Verantwortlichkeiten aufgefasst, indem
relevante Leistungsdaten erfasst, analysiert und berichtet werden. Der Zweck der
Leistungsmessung ist die Überwachung und Kontrolle des Zustandes gemessener
Aktivitäten und die Verbesserungen dieser Aktivitäten durch geeignete Korrekturmaßnahmen
- basierend auf den beobachteten Messungen.
(McIntyre, et al., 2007) stellen den Zusammenhang zwischen Metriken und den
bestimmenden Unternehmenszielen her:
Metriken sollten das Erreichen übergeordneter Ziele sicherstellen, wie z.B. funktionale
Sicherheit (engl. „safety“) oder den unterbrechungsfreien Betrieb.
Seite 114 von 262

Für die weitere Betrachtung ergeben sich aus der vorangestellten Literatur folgende
Bedeutungen der Begriffe:
Messung (Measurement) umfasst alle Aktivitäten, die der
 Erfassung,
 Übertragung (von der Datenquelle bis zum logischen Ziel, d.h. dem
Verarbeitungsprozess) und
 Normierung
im Rahmen der Verarbeitung von Prozesswerten dienen.
Metrik umfasst
 die Auswahl und Bestimmung der Metrikgrößen, die dem jeweiligen Geschäftsziel
dienen,
 die notwendigen Funktionen, um die Rohdaten (Messwerte) in die Ergebniswerte zu

überführen und
 die Definition der notwendigen Vergleichsdaten, die der Kontextbildung und/oder der
Normierung dienen.
Die Messung stellt somit die unterlagerte Datenebene dar, während die Metrik die darauf
aufsetzende Informationsschicht zur Unterstützung der Unternehmensführung bildet.
6.3 Kritik der vorgestellten IT-Sicherheit-Metriken
6.3.1 Allgemeine Betrachtung
Wie bereits in Kapitel 6.1 dargestellt, dienen IT-Sicherheitsmetriken dem Zweck, die
Gefahrenpotentiale, die sich aus dem Betrieb von Computersystemen ergeben,
abzuschätzen und evtl. notwendige Handlungsentscheidungen zu unterstützen. Die Auswahl
des logischen Inhaltes einer Metrik muss deshalb auf die Angriffsmöglichkeiten ausgerichtet
sein. Aus dieser Fokussierung ergeben sich folgende Konsequenzen:
a) Die Metrikinhalte und -strukturen müssen eine konsistente Darstellung der

Gefährdungspotentiale unterstützen. Dies beinhaltet statische Werte zum Zeitpunkt
der Analyse (soweit möglich) sowie die Veränderung der Gefährdung im Zeitverlauf.
Des Weiteren sollten Metriken Indikatoren für Handlungsoptionen beinhalten, d.h. die
Seite 115 von 262

Identifizierung von Angriffszielen sowie die Identifizierung von Ausgangspunkten für

Angriffe.
b) Die Methode zur Gefahrenabschätzung muss die charakteristischen

Leitsystemeigenschaften berücksichtigen.
Betrachtet man unter diesen Aspekten typische, in der Praxis angewandte IT-
Sicherheitsmetriken und Risikobetrachtungen für Leitsysteme, so ergeben sich Zweifel an
deren praktischen Nutzen.
6.3.2 Ansätze für IT-Sicherheitsmetriken
Die Ansätze für IT-Sicherheitsmetriken basieren im Wesentlichen auf empirischen Daten und
statistischen Methoden sowie betriebswirtschaftlichen Kennzahlen.
(Hayden, 2010) stellt einige Größen zur Risikobeurteilung zusammen - überschrieben mit „A
Parade of Horribles“:
Risk
Die etwas naive Definition von Risiko im Kontext der IT-Sicherheit steht mangelndem
Nachdruck beim Versuch der Messung des Risikos gegenüber. Die vielleicht am
weitesten verbreitete Methode zur Messung des Sicherheitsrisikos sind Varianten
der „Wahrscheinlichkeit x Schadenpotential”-Matrix.
Annualized Loss Expectancy (ALE)

Wenn Schwachstellen-orientierte Statistiken die am häufigsten verwendeten
Messdaten im Bereich „Security“ sind, dann ist ALE das am häufigsten verwendete
Metrik-Konzept. ALE stellt eine Einschätzung dar, wie groß der erwartete Verlust
eines Sicherheitsereignisses ist.
ALE bestimmt sich anhand der Formel ALE = ARO * SLE, mit ARO als annualisierte
Eintrittswahrscheinlichkeit und SLE als (einzelne) Verlusterwartung.
Return on Invest (ROI)

Die Verwendung von ROI als eine Security-Metrik, stellt den Versuch dar, den Nutzen
einer Sicherheitsinvestition zu berechnen.
Aus Security-Sicht wird die Größe „ROI“ in verschiedenen Weisen angewendet.

Einerseits steht ROI im Zusammenhang mit der Größe ALE. Falls eine Organisation
Seite 116 von 262

Schutzmaßnahmen gegen Cyber-Angriffe ergreift, definiert das Verhältnis der Kosten

für die Maßnahmen zu den erwarteten Verlusten durch einen Angriff die Größe „ROI“.
Andererseits dient das ROI Lieferanten von Sicherheitsprodukten als

Marketingargument.
Total cost of ownership

Während ALE versucht, Verluste im Zusammenhang mit Angriffen gegen IT-Systeme
zu bestimmen und das ROI den „Profit“ aus Schutzmaßnahmen zu messen versucht,
stellt die Größe „TCO“ jene Kosten dar, die sich aus dem Betrieb des Systems über
den gesamten Lebenszyklus ergeben.
Bei der Beurteilung der aufgeführten Methoden ist Hayden eindeutig:
 Eine Security-Risikobeurteilung misst nicht das Risiko
 ALE stellt eine schlechte Metrik dar
 Die Verwendung der ROI-Methode im Kontext der IT-Security kann auch als
„statistische Alchimie“ bezeichnet werden, da sie fälschlicherweise versucht,
unterschiedliche Konzepte formelmäßig zu verknüpfen.
 Die TCO-Methode ist als Security-Metrik ungeeignet, da sie auf Anschaffungen bzw.
Investitionen hinsichtlich der IT-Sicherheit basiert, aber keine Messung des IT-
Sicherheitsprozesses berücksichtigt.
(Haimes, 2009) schlägt für die Risikoanalyse hinsichtlich Cyber-Angriffe (gegen SCADA-
Systeme in Wasserwerken) die Methode der System-Dekomposition vor. Angriffsszenarien
werden bei dieser Methode mittels Ereignisbaum auf die Systemstruktur abgebildet. Für jede
Systemvoraussetzung, die der Angreifer zum Erreichen des Angriffszieles erfolgreich
überwinden muss, ist eine Erfolgswahrscheinlichkeit abzuschätzen. Für jedes
Angriffsszenario lässt sich auf diese Weise die Wahrscheinlichkeit des Ereignispfades für
Erfolg / Misserfolg des Angreifers berechnen.
Zentrale Schwachstelle dieses Ansatzes ist die Notwendigkeit, für jeden Knoten des
Ereignisbaumes die Wahrscheinlichkeit der Überwindung durch den Angreifer abzuschätzen.
Neben der damit dominierenden subjektiven Einschätzung des Auditors stellt sich die Frage,
welcher Typ „Angreifer“ in den Mittelpunkt der Betrachtung steht. Die Wahrscheinlichkeit der
Überwindung eines Knotens im Ereignisbaum hängt von der Kompetenz, dem Wissen und
Seite 117 von 262

ggf. der Ausrüstung und den finanziellen Mitteln des Angreifers usw. ab. Daraus ergibt sich,
dass für eine Anlage nicht ein einzelner Ereignisbaum zu erstellen ist, sondern ein „Wald“
von Ereignisbäumen, die die verschiedenen Angreifertypen repräsentieren. Und: für jeden
Ereignisbaum (d.h. jeden Angreifertyp) sind anschließend die angriffstypischen
Eintrittswahrscheinlichkeiten abzuschätzen.
An dieser Stelle stößt man auf die grundsätzlichen Fragen, wie sich das Verhalten der
potentiellen Angreifer modellieren lässt und wie wahrscheinlich die einzelnen
Modellannahmen in der Realität sind. Aus der Verfügbarkeit präzise gemessener Daten, wie
z.B. die Anzahl der falsch eingegebenen Passwörter pro Zeiteinheit o.ä., ergibt sich deshalb
immer noch keine exakte Aussage über den Anlagensicherheitsstatus.
6.3.3 Schlussfolgerungen zu Metriken
Die im vorangegangenen Kapitel skizzierten Ansätze zur Risikobetrachtung von

Leittechnikanlagen auf Basis von IT-Sicherheitsmetriken werfen die Frage auf, inwieweit
diese Methoden für die Sicherheitsbetrachtung von SCADA-Anlagen geeignet sind.
(Masera, et al., 2010) zweifeln die Nützlichkeit der heute verwendeten Sicherheitsmetriken
grundsätzlich an:
Es gibt keine allgemein akzeptierte Definition einer Security-Metrik. Der Begriff „Metrik“
repräsentiert in der Praxis unterschiedliche Begrifflichkeiten. Im Sinne einer quantitativen
Standardfunktion basiert „Metrik“ auf Prozess- und/oder Produktmessungen. Dieser Ansatz
dient aber keiner Sicherheitsbetrachtung einer Anlage sondern bezieht sich auf die
Beurteilung von Systemen zum Zwecke der Zertifizierung.
(Savolo, 2008) kritisiert die Vereinfachung der Realität durch die Metrik-Bildung:
Die Möglichkeit der Messung der Sicherheit sowie der Entwicklung von Security-Metriken zur
Darstellung aktueller Sicherheitsphänomene wurde vielfach kritisiert. Beim Entwurf einer
Sicherheitsmetrik muss die Tatsache berücksichtigt werden, dass Metriken eine komplexe
sozio-technische Situation vereinfachen.
Seite 118 von 262

Auf die grundsätzliche Bedeutung sowie die praktische Anwendung von Sicherheitsmetriken
gehen (Masera, et al., 2010) wie folgt ein:
Security-Metriken sollen die Erfüllung bestimmter Sicherheitsanforderungen oder den

relativen Wert einer Sicherheitseigenschaft darstellen. Daraus leiten sich zwei wesentliche
Aspekte ab:
 Security-Metriken sind Indikatoren und keine Messungen der Sicherheit. Sicherheit ist
keine Funktion, die sich auf einen Parameter reduzieren lässt und lässt sich für ein
System nicht auf ein einzelnes Attribut verdichten;
 Security-Metriken hängen in starkem Maße von den Bezugspunkten der Messung ab

und dürfen keinesfalls als absolute Größen, bezogen auf externe Maßstäbe,
aufgefasst werden.
(McIntyre, et al., 2007) stellen die Anwendung von Sicherheitsmetriken aus dem Bereich der
Unternehmens-IT für SCADA-Systeme in kritischen Infrastrukturen in Frage:
Die typische Anwendung von Metriken für Geschäftsanwendungen kann für

Prozessleitsysteme nicht in Betracht gezogen werden. Metriken finden in vielen
Organisationen und Bereichen, wie z.B. Verwaltung, Finanzen, Kommunikation und
Technologie, regelmäßig Anwendung. Betriebliche Produktionsumgebungen sind durch
vollständig unterschiedliche Anforderungen und Zielsetzungen gekennzeichnet. Im
Wesentlichen sind Ausfallzeiten und Produktionsunterbrechungen zu vermeiden. Es ist zu
berücksichtigen, dass „kritische Infrastrukturen“ genau dieses liefern: ein „kritisches“ Produkt
oder eine „kritische“ Dienstleistung, wobei „kritisch“ im Sinne von „für die Gesellschaft
wichtig“ zu verstehen ist. Die verlässliche Verfügbarkeit von Energie ist ein besonderer
Bereich, dessen Störung ungleich schwerwiegendere Auswirkungen haben kann, als der
Ausfall eines IT-Systems oder eines E-Mail-Servers während der Geschäftszeit. Die
Zielsetzungen für die Betreiber kritischer Infrastrukturen kreisen um die Verfügbarkeit und die
Betriebssicherheit gegenüber der Öffentlichkeit und dem Anlagenpersonal. Berücksichtigt
man Aufgaben und Zielsetzungen, kann gefolgert werden, dass die üblichen Metriken für
Anwendungen der Informationstechnologie nicht direkt auf betriebliche Umgebungen
übertragbar sind. Der Gebrauch von Metriken in Architekturen betrieblicher
Produktionsumgebungen mit entsprechenden Randbedingungen muss die Kritikalität der
Anlagen sowie möglicher Konsequenzen in Betracht ziehen.
Seite 119 von 262

Studien, die auf empirischen Daten zu Schwachstellen in SCADA-Systeme basieren, findet

man bei (Gritsai, et al., 2012). Wie in Abbildung 18 gezeigt, listen sie mit Schwerpunkt auf
europäischen und amerikanischen Firmen weniger als 100 Schwachstellen p.a. (in 2012).
Zudem ist zu berücksichtigen, dass Systemschwachstellen keine erfolgreichen Angriffe
darstellen. Es ist anzumerken, dass sich diese Schwachstellenzahl ausschließlich auf
Software-Produkte in dedizierten SCADA-Komponenten bezieht. Schwachstellen von
Standard-IT-Komponenten, die in leittechnischen Systemen auch zum Einsatz kommen (z.B.
Standardbetriebssysteme, Browser, etc.), bleiben unberücksichtigt. (Gritsai, et al., 2012)
geben an, dass nur für ca. 35% der Schwachstellen Angriffsschemata („exploits“) bekannt
sind (siehe Tabelle 3).
Jahr Anzahl der bekannten Angriffsmuster
2008 2
2009 6
2011 30
2012 20
Tabelle 3: Anzahl bekannter Angriffsmuster
(Nicholson, et al., 2012) listen Angriffe gegen SCADA-Anlagen in verschiedenen

Industriesektoren seit 2000 auf (siehe
Abbildung 17). Widersprüchliche Angaben finden sich in (Iversen, 2004), der für den Zeitraum
von 1982 – 2000 einen Anteil von 31% der gemeldeten Angriffe gegen SCADA-Systeme als
„extern“ klassifiziert, während für den Zeitraum von 2001 – 2003 bereits 70% der Angriffe
von außen kamen.
Seite 120 von 262

Abbildung 17: Angriffe gegen SCADA-Systeme nach (Nicholson et.al. 2012)
Seite 121 von 262

Abbildung 18: Schwachstellen in SCADA-Systemen
Eine statistisch valide Datengrundlage für die Bestimmung von Eintrittswahrscheinlichkeiten

für Individualanlagen lässt sich daraus nicht ableiten.
Aus den USA gibt es für den Zeitraum von Januar 2012 bis Dezember 2014 Zahlen zu
Sicherheitsereignissen in Leittechniksystemen („Industrial Control Systems“) durch die
staatliche Behörde ICS-CERT, die zum US. Department of Homeland Security gehört. (ICS-
CERT, 2014) gibt für den angegebenen Zeitraum 138 bis 232 Sicherheitsvorfälle an (siehe
Abbildung 19). Für den Fall, dass die empirischen Daten Grundlage für statistische
Methoden bilden sollen, dürfen jedoch maximal die Daten des betreffenden Sektors
verwendet werden. Für das Jahr 2014 (Fiscal Year) gibt der Bericht für den Sektor „Wasser“
14 Ereignisse an und für den Sektor „Energie“ 79 Ereignisse (siehe Abbildung 20). Unter der
hypothetischen Annahme, dass alle Ereignisse des Sektors „Energie“ in Kraftwerksblöcken
aufgetreten wären, kann man schließen, dass für über 99% der Kraftwerksblöcke keine
Ereignisdaten vorliegen. Sämtliche leittechnischen Einrichtungen der Transport- und
Verteilnetzes der USA, die engmaschig über die USA verteilt sind, blieben bei dieser
Annahme jedoch völlig unberücksichtigt! Auf die Verwendung der empirischen Ereignisdaten
als Grundlage für statistische Risikobetrachtungen ist deshalb zu verzichten.
Seite 122 von 262

Abbildung 19: ICS-CERT-Angaben zu Sicherheitsvorfällen (2012 - 2014)
Abbildung 20: ICS-CERT-Angaben zu Sicherheitsvorfällen je Sektor (2014)
Seite 123 von 262

Des Weiteren listen (Nicholson, et al., 2012) die in Frage kommenden Angreifertypen auf:
 Hacker mit staatlicher Beauftragung
 Terroristen
 Nicht-staatliche Hacker / organisierte Kriminalität
 unzufriedene Mitarbeiter / Innentäter
 Hobbyangreifer
 Script kiddies
 „Hacktivists“ (Hacker mit politisch / ethischem Hintergrund)
 Regulär beauftragte Penetrationstests
Unter der Annahme, dass diese Auflistung vollständig ist, müsste für die Beurteilung der IT-
Sicherheit einer SCADA-Anlage für alle vorangestellten Angreifertypen individuelle
Angriffsprofile erstellt und entsprechende Eintrittswahrscheinlichkeiten bestimmt werden.
Erschwerend kommt hinzu, dass hierfür kein valides Datenmaterial zur Verfügung steht
(siehe oben).
Für die weitere Arbeit ergeben sich aus dem Vorangestellten folgende Schlussfolgerungen:
 IT-Sicherheitsmetriken können ein Hilfsmittel zur Beurteilung des Unternehmensrisikos
aus dem Betrieb von SCADA-Systemen darstellen.
 Keine der vorgestellten Ansätze zur Sicherheitsbeurteilung liefern eine belastbare
Aussage in Bezug auf die „IT-Sicherheit“ von SCADA-Systemen.
 Keine der Methoden beinhaltet eine begründete Verknüpfung von „IT-Sicherheit“ und
„Anlagenrisiko“.
 Die skizzierten Methoden erfordern in unterschiedlichem Umfang subjektive
Einschätzungen zur Ableitung quantitativer oder qualitativer Ergebnisse.
 Metriken stellen keinen Endpunkt einer Analyse dar, sondern bilden einen Baustein einer
geschlossenen Wirkungskette (Beobachtung – Analyse – Planung – Umsetzung –
Beobachtung)
 Die Methoden bieten keine Auflösung des „Auditoren-Dilemma“.
Anmerkung
Als „Auditoren-Dilemma“ bezeichne ich folgende Situation, im Falle einer auf empirischen
Daten basierenden Analysemethode:
Seite 124 von 262

a. Für SCADA-Neuanlagen können prinzipiell keine anlagenspezifischen Daten zur

Verfügung stehen.
b. Für individuelle Altanlagen können prinzipiell keine statistisch validen Daten
vorliegen, d.h. eine hinreichend große Anzahl empirischer Daten erfolgreicher
Angriffe.
c. Als Ersatzdaten werden empirische Werte nur bedingt vergleichbarer Anlagen bzw.
Branchen herangezogen.
Bei Verwendung von Ersatzdaten ähnlicher Anlagen (regional, national, global, Branche)
muss der Auditor jedoch die Frage beantworten, welche Aussagekraft Analyseergebnisse
haben, die auf Daten anderer Anlagen beruhen. Insbesondere stellt der Begriff „ähnliche
Anlage“ den Auditor vor folgende Frage: Bezieht sich der Begriff „Ähnlichkeit“ auf Anlagen
mit den hinreichend gleichen Attributen, wie z.B.
 Sektor / Branche, z.B. Energie
 Anlagentyp, z.B. Kraftwerk, Umspannstation, Pipeline
 Kraftwerkstyp, z.B. Kohleblock, Gasturbine, Wasserkraftanlage
 Anlagenalter
 Betreiber
 SCADA-Lieferant
Es ist naheliegend, dass auch die Art des Unternehmens (internationaler Energiekonzern
oder lokales Stadtwerk) oder die Anlagengröße (Blockleistung) Auswirkungen auf die
Bedrohungslage hat, sofern ideologisch motivierte oder staatliche Angreifer infrage kommen.
Die Sicherheit von Leit- und Automatisierungssystemen beruht nicht alleine auf technischen
Ausprägungen der Systeme, sondern auch auf den sog. „Soft skills”, wie z.B.
Mitarbeiterschulung („Security awareness“), Wartungsprozessen für Systeme usw., die sich
von Anlage zu Anlage sehr stark unterscheiden und mithin zu stark divergierenden
Ergebnissen hinsichtlich der IT-Sicherheit führen.
Außerdem: statistische Ergebnisse auf Basis großer Datenmengen erfolgreicher Angriffe

gegen vergleichbare Leitsysteme / Leitsystemstrukturen lassen keine Rückschlüsse für
individuelle Anlagen zu.
Der Auditor verwendet also ein quantitatives oder qualitatives Beurteilungsmodell, dessen
Aussagekraft der Ergebnisse nicht begründbar ist.
Seite 125 von 262

6.4 IT-Sicherheitsmetrik: Randbedingungen für Leittechniksysteme
6.4.1 Allgemeines
Sicherheitsmetriken für Leitsysteme müssen auf die besondere Systemcharakteristik der

Leittechnik zugeschnitten sein. Leittechnische Systeme unterscheiden sich hinsichtlich der
Schutzziele von Systemen aus dem Bereich der typischen Unternehmens-IT (Enterprise-IT).
In typischen Systemen der Unternehmens-IT haben Vertraulichkeit und Korrektheit der

Informationen oberste Priorität. Die Verfügbarkeit der Systeme ist nachrangig.
Bei Leittechniksystemen genießen die Integrität (d.h. die Korrektheit der prozessführenden
Logik) sowie die Verfügbarkeit (der Schutzfunktionen) oberste Priorität. Die Vertraulichkeit
der verarbeiteten Daten hat nachrangige Bedeutung.
Schutzziele im Bereich …
Priorität der
Schutzziele Unternehmens-IT Leittechniksysteme
1 Vertraulichkeit Integrität
2 Integrität Verfügbarkeit
3 Verfügbarkeit Vertraulichkeit
Tabelle 4: Priorität der Schutzziele in unterschiedlichen Technologieanwendungen
Aus den unterschiedlichen Schutzzielen folgt, dass IT-Sicherheitsmetriken für

Leittechniksysteme andere Inhalte darstellen müssen, als Metriken für Systeme der
Unternehmens-IT.
(Moily, 2011) weist auf die zum Teil konträren Bedeutungen von Sicherheitsmaßnahmen in
typischen Unternehmens-IT-Umgebungen im Gegensatz zu SCADA-Anlagen zur Führung
von verfahrenstechnischen Prozessen hin: IT-Sicherheitsmetriken lassen sich nicht immer
direkt auf Prozessleitsysteme anwenden, trotz gleicher Basistechnologien. Beispielsweise
gelten in IT-Systemen starke Passwörter mit definierter Gültigkeitsdauer und Kontensperrung
im Falle mehrfach fehlgeschlagenen Anmeldeversuchen als „best practise“. Demgegenüber
kann Bedienpersonal von Öl- und Gas-Pipelines, Kraftwerken, Raffinerien oder
Ölförderanlage gezwungen sein, im Falle kritischer Zustände in erheblichen
Stresssituationen handeln zu müssen. Der Systemzugang muss daher ohne oder nur mit
minimaler Verzögerung zwingend möglich sein, um gegebenenfalls Prozessstörungen zu
Seite 126 von 262

vermeiden. Aus diesem Grund wird für Arbeitsplätze zur Prozessführung teilweise sogar auf
einen Passwortschutz verzichtet. Schließlich soll ein Angreifer auch nicht in der Lage sein,
durch vorsätzliche mehrfache Falscheingabe von Passwörtern den Arbeitsplatz für zulässige
und notwendige Bedienungen zu blockieren.
Anmerkung: Der Betrieb von Rechnersystemen (Bedienarbeitsplätzen) ohne Passwortschutz

für das Bedienpersonal mag für den Leser mit Security-Hintergrund, der durch typische IT-
Systemlandschaften geprägt ist, äußerst bedenklich erscheinen. Es sei jedoch darauf
hingewiesen, dass die Vorgängertechnologie dieser PC-basierten Arbeitsplätze
konventionelle Bedienpulte waren, die technologiebedingt über keinen „Passwortschutz“
verfügten. Es soll häufiger vorgekommen sein, dass Reinigungspersonal beim Säubern
dieser Pulte Fehlbedienungen auslösten – falls keine Zweihandbedienung vorgesehen war.
Bei Prozessbedienungen steht der schnelle, ungehinderte Zugang zur Leittechnik-
Benutzeroberfläche im Vordergrund. Des Weiteren ist zu berücksichtigen, dass der
Passwortschutz die Aufgabe hat, den Bedieneingriffe auf autorisiertes Personal zu
beschränken. Diese Aufgabe lässt sich auch anderweitig realisieren, z.B. mittels
permanenter Besetzung des Leitstandes durch Schichtpersonal (per se autorisiert) oder ggf.
durch geeignetes Video-Monitoring.
6.4.2 Wesentliche Randbedingungen
Für die weitere Betrachtung der Anforderungen an Sicherheitsmetriken für leittechnische

Systeme werden folgende Randbedingungen zugrunde gelegt:
Aussage zum Sicherheitsniveau der Zielanlage
Die Inhalte einer Sicherheitsmetrik sollen die Einschätzung der IT-Sicherheit einer
Leittechnikanlage ermöglichen und die Darstellung von Pseudo-Sicherheitsgrößen
vermeiden.
Beispiel: In der Literatur, aber auch in realen Audits, kommen Darstellungen zur IT-Sicherheit
in Form einer Sicherheits- oder Risikomatrix zur Anwendung (siehe Beispiel in Tabelle 5).
Dabei werden Mitarbeiter danach befragt, Angriffsszenarien nach Eintrittswahrscheinlichkeit
(„Hoch“, „Mittel“, „Gering“) und Schadenspotential („Hoch“, „Mittel“, „Gering“) zu beurteilen.
Die Aussagen der befragten Mitarbeiter / Anwender / Experten lassen sich dann in die
verschiedenen Quadranten der Matrix (von Hoch/Hoch bis Gering/Gering) einordnen. Die
Seite 127 von 262

Matrixwerte werden anschließend mittels numerischer Gewichtung der 9 Matrixzellen sowie

der Anzahl der Szenarien je Matrixzelle zu einem Gesamtwert aggregiert.
Eintrittswahrscheinlichkeit
Risikomatrix
Hoch Mittel Gering
Szenario 1
Hoch
Szenario 4
Schadenspotential Mittel Szenario 2 Szenario 3
Szenario 5
Gering
Szenario 6
Tabelle 5: Beispiel einer Risikomatrix
Das Ergebnis stellt zwar ein häufig verwendetes Element von Sicherheitsmetriken dar.
Allerdings ist offensichtlich, dass diese Art der Darstellung nichts über die Sicherheit einer
Anlage aussagt, sondern lediglich die Einschätzung der Befragten wiedergibt. (Siehe in
(Hayden, 2010), Kapitel 2.3.2: „Security risk assessments don’t measure risk…“). Die
Qualität der Einschätzung, d.h. Erfahrung und Kompetenz der Befragten, Grad der
Objektivität usw., fließt nicht in das Ergebnis der Befragung ein. Außerdem hängt das
Ergebnis der „Messung“ von der Zusammensetzung des Kreises der Befragten ab.
Die Verwendung von Ersatzgrößen, insbesondere der Größe „Risiko“ wurde bereits in
Kapitel 6.3 kritisiert. Ziel des Entwurfs von Konzepten von Sicherheitsmetriken sollte die
Berücksichtigung inhärenter Sicherheitseigenschaften der Zielsysteme sein.
Transparenz der Abbildung der Basisgrößen auf die Sicherheitsmetrik
Die Bildung der Metrikinhalte auf Basis der zugrundeliegenden „Rohdaten“ (im Sinne einer
Messung) muss transparent darstellbar sein, um die Richtigkeit der Ergebnisse überprüfen
sowie die Sinnhaftigkeit der funktionalen Abbildung beurteilen zu können.
Seite 128 von 262

Nachvollziehbarkeit der Metrikbildung
Angesichts der Tatsache, dass die Beurteilung der IT-Sicherheit von Leittechnikanlagen in
regelmäßigen Abständen erfolgen sollte, müssen die Ergebnisse dieser Analysen
vergleichbar sein. Ansonsten ist völlig unklar, wie Abweichungen zustande gekommen sind.
Mögliche Ursachen könnten sein:
 Veränderungen der Leittechnik (Bestandteile, Systemeigenschaften, Örtlichkeiten

usw. ),
 eine veränderte Bedrohungslage oder
 eine abweichende Einschätzungen der Auditoren
Subjektive Einschätzungen von Auditoren oder anderweitig an der Untersuchung Beteiligten

beeinflussen die Analyseergebnisse in zweierlei Hinsicht:
 die subjektiven Einschätzungen sind von der Zusammensetzung des Kreises der
Befragten abhängig und
 die Gleichwertigkeit der individuellen Einschätzungen im Laufe der Zeit ist nicht
gewährleistet und in der Regel nicht verifizierbar.
Zur Verdeutlichung dieses Sachverhaltes sei an dieser Stelle darauf hingewiesen, dass
Fachleute hinsichtlich IT-Sicherheit aufgrund eigener Sachkunde mögliche Angriffsvarianten
häufig als „einfach realisierbar“ einschätzen, während am Assessment Beteiligte mit weniger
Security-Expertise die gleichen Angriffsvarianten eher als „schwierig zu realisieren“
einstufen.
Zum Zwecke der Nachvollziehbarkeit der Ergebnisse sollten Veränderungen der

Analyseergebnisse ausschließlich auf technischen Änderungen an den Systemen bzw.
veränderten Bedrohungslagen beruhen.
Konsistenz der Metrikbildung über die Zeit
In engem Zusammenhang mit der Nachvollziehbarkeit der Analyseergebnisse steht die

Konsistenz der Ergebnisse über den zeitlichen Verlauf regelmäßig wiederkehrender
Sicherheitsanalysen.
Wie bereits hinsichtlich der Nachvollziehbarkeit der Ergebnisse festgestellt, beeinflussen

subjektive Einschätzungen von Auditoren, die in die Analyseergebnisse einfließen, die
Vergleichbarkeit mit Auditergebnissen aus Vergangenheit und Gegenwart. Für die Ableitung
von Handlungsoptionen ist es unabdingbar, die Analyseergebnisse als Verbesserung oder
Seite 129 von 262

Verschlechterung des Anlagensicherheitsniveaus interpretieren zu können. Veränderungen ,

die sich lediglich aufgrund subjektiver Einschätzungen ergeben, müssen ausgeschlossen
sein.
Die Metrikbildung sollte erlauben, eine konsistente Fortschreibung der Sicherheitsanalysen

trotz Änderungen der Leittechniktopologie oder Änderungen der Bedrohungslage (z.B. neue
Angriffsszenarien) zu erzeugen. Zu diesem Zweck sollten die Auswertungen diese beiden
Veränderungstypen sukzessive berücksichtigen, so dass sich Ergebnisveränderungen
eindeutig den möglichen Ursachen zuordnen lassen.
Datenmodell muss Zielanlage abbilden
In Kapitel 6.3.3 wurde bereits auf die Verwendung empirischer Daten und statistischer
Methoden für die Bildung von IT-Sicherheitsmetriken eingegangen. In der vorliegenden
Arbeit werden diese Ansätze abgelehnt. Aus Sicht des Verfassers lassen sich auf diesen
Wegen keine qualifizierten Aussagen hinsichtlich der IT-Sicherheit einer individuellen
Leittechnikanlage ableiten.
Begründung
1. Es stehen keine brauchbaren empirischen Daten zu Verfügung
Bei (Nicholson, et al. 2012) (siehe Kapitel 2.3.3) und (Gritsai, et al. 2012) findet man
numerische Angaben zu realen Angriffen („exploits“) gegen SCADA-Systeme (alle
Branchen, global). Bei weltweit < 50 Angriffen pro Jahr sind statistische Aussagen
nicht sinnvoll (Hinweis: allein in Deutschland sind ca. 1.000 Kraftwerksblöcke
unterschiedlichen Alters, verschiedener Technologien und Leistungsgrößen in
Betrieb).
2. Die Übertragbarkeit statistischer Daten zwischen unterschiedlichen Anlagentypen ist

nicht gegeben
Die Vergleichbarkeit empirischer Daten über verschiedene Anlagentypen, Branchen,

oder Unternehmen hinweg ist in der Literatur nicht gegeben. Neben unterschiedlichen
Betriebs- und Führungskonzepten, die sich in unterschiedlicher Bedeutung des
Themas „IT-Sicherheit“ in der täglichen Betriebspraxis niederschlägt, spielt auch die
Relevanz einer Produktionseinheit im gesamten Anlagenpark eine Rolle. Der Ausfall
eines kleinen 300 MW Kraftwerksblockes stellt für ein Unternehmen mit einer
Seite 130 von 262

Erzeugungskapazität von 5.000 MW ein größeres Problem dar, als ein 500 MW Block
in einer Anlagenflotte, die über eine Gesamtkapazität von 20.000 MW verfügt.
3. Empirische Daten erlauben grundsätzlich keine Aussage zu einer individuellen

Zielanlage
Falls hinreichend empirische Daten verfügbar wären, stellt sich die Frage, ob es
methodisch sinnvoll ist, diese Daten auf die untersuchte Zielanlage anzuwenden.
Schließlich stellen diese Daten eine Abbildung (Mittelwert) der Sicherheitslage
anderer Anlagen dar. Streng genommen gelten diese Daten nur für die der
empirischen Untersuchung zugrundeliegenden Anlagen (Stichproben). Anhand eines
fiktiven Beispiels wird die Nutzlosigkeit empirischer Daten anderer Anlagen bei
Anwendung auf eine Zielanlage deutlich: Die statistische Auswertung der
Sicherheitslage von 100 Anlagen, wobei davon 99 Anlagen höchste
Sicherheitsstandards erfüllen, würde der 100. Anlage (die betrachtete Zielanlage), die
fiktiv ohne jegliche Sicherheitsmaßnahme betrieben wird, fälschlicherweise ebenfalls
geringes Gefährdungspotential zubilligen.
4. Für Neuanlagen stehen prinzipiell keine empirischen Daten zur Verfügung.
5. Grundsätzliche Anwendbarkeit der Metrik für singuläre Anlagen
Die Abbildung empirischer Anlagendaten einer ganzen Branche auf eine individuelle
Zielanlage wirft grundsätzlich die Frage auf, ob die Abbildung überhaupt gerechtfertigt
ist. Gründe können unterschiedliche Betriebsarten aufgrund nationaler Vorschriften,
verschiedenartige Produktionsmethoden oder sonstige individuelle Sonderfaktoren,
z.B. unternehmensspezifische Eigenschaften, sein.
Des Weiteren sollte eine Sicherheitsmetrik auch eine völlig individuelle, ganz
spezifische Anlage darstellen können.
6. Individuell zugeschnittene Angriffsmuster lassen sich mittels empirischer Daten

prinzipiell nicht erfassen.
Seite 131 von 262

Laut Anti-Malware Lösungshersteller Symantec (Kroll, Lars; Peters, Alexander 2012) beträgt
der Anteil sogenannter Mikro-Distributionen ca. 75%. Diese auf das entsprechende Ziel
maßgeschneiderte Schadsoftware wird typischerweise auf weniger als 50 Rechnersystemen
entdeckt und nutzt dem Angreifer bekannte anlagenspezifische Schwachstellen. Statistische
Methoden sind bei dieser Art von Angriffen völlig unbrauchbar.
Die diskutierten Randbedingungen für eine neue Sicherheitsmetriken lassen sich wie folgt
zusammenfassen:
 Aussage zu Sicherheit der Zielanlage: „Sicherheit messen“
 Transparenz der Abbildung der Basisgrößen auf die Sicherheitsmetrik
 Nachvollziehbarkeit der Metrikbildung: Verzicht auf subjektive Einschätzungen
 Konsistenz der Metrikbildung über die Zeit
 Datenmodell bildet Zielanlage ab: Verzicht auf empirische Daten unterschiedlicher

Anlagentypen
 Anwendbarkeit der Sicherheitsmetrik für singuläre Anlagen
6.5 Vorschlag einer leittechnikspezifischen Sicherheitsmetrik
In Kenntnis der Randbedingungen für Sicherheitsmetriken aus Kapitel 6.4 soll nun ein
Vorschlag für die Inhalte einer Sicherheitsmetrik für Leittechniksysteme vorgestellt werden.
In Kapitel 8 findet die nachfolgend beschriebene Metrik Anwendung im Rahmen der Analyse
einer beispielhaften Leittechnikanlage.
Wie bereits in Kapitel 6.1 erwähnt, dient eine IT-Sicherheitsmetrik dem Zweck, den Status
der IT-Sicherheit eines Leitsystems in geeigneter Form darzustellen. Als Grundlage für
Führungs- und Handlungsentscheidungen benötigt ein Unternehmen Informationen über den
Sicherheitsstatus der leittechnischen Einrichtung hinsichtlich zweier Perspektiven:
a) Der aktuelle Sicherheitsstatus zum Zeitpunkt der Analyse und
b) Die Veränderung des Sicherheitsstatus über den zeitlichen Betriebsablauf (in

zeitlichen Abständen wiederkehrende Analysen)
Um diesem Anspruch zu genügen, müssen Metriken statische Informationen liefern, die die
Sicherheitszustände zu definierten Zeitpunkten beschreiben. Des Weiteren müssen die
Seite 132 von 262

Metrikinhalte auch dynamische Elemente umfassen, die eine Fortschreibung der Metrik unter
Berücksichtigung von Veränderungen ermöglichen.
6.5.1 Statische Metrikinhalte
Definition der Größe „Sicherheitsniveau“
Kapitel 6.4 diskutierte bereits das wesentliche Manko bekannter Sicherheitsmetriken:

anstelle der „Sicherheit“ werden andere Ersatzgrößen gemessen und als Metrik dargestellt.
Als erster Schritt ist deshalb die Frage zu klären, welche Messwerte als Grundlage für die
Bewertung der „IT-Sicherheit“ einer Leitechnikanlage dienen können.
Der weiteren Betrachtung liegt folgende Überlegung bezüglich der Sicherheitsdefinition

zugrunde. Sie bildet die zentrale Größe der vorgestellten IT-Sicherheitsmetrik:
Ein System gilt in dem Maße als „sicher“, wie erfolgreiche Angriffe auf das System
verhindert werden.
Das heißt, das Sicherheitsniveau einer Anlage ist umgekehrt proportional zur Zahl der
potentiell (erfolgreich) möglichen Angriffsmuster. An dieser Stelle ist zu beachten, dass aus
naheliegenden Gründen nur die bekannten Angriffsmuster in die Analyse einfließen.
Aus dieser Überlegung ergibt sich folgende Definition des ersten Metrikelementes:
Sicherheitsniveau = 1 - (Ak / Ab )
mit den Variablen
Ak : kritische Angriffsszenarien (= systembedingt mögliche Angriffe)
Die „Anzahl der potentiell möglichen Angriffsszenarien“ leitet sich aus der
PROLOG-basierten Analyse der Anlagentopologie ab (siehe Kapitel 5.4.5).
Ab : bekannte Angriffsszenarien
Die „Anzahl der bekannten Angriffsszenarien“ ergibt sich aus der Analyse von
möglichen Angriffen, z.B. mit Hilfe der Methode „Attack Tree“ (siehe Kapitel
5.3.3).
Die Größe „Sicherheitsniveau“ beschreibt, wie hoch der Anteil der systembedingt möglichen
(kritischen) Angriffsszenarien gegen die Zielanlage ist - bezogen auf die bekannten
(generischen) Angriffsmuster.
Die Prüfung der Plausibilität der Formel zeigt die Übereinstimmung der Charakteristik der
Formel mit der Erwartung aus der Praxis:
Seite 133 von 262

Nimmt man an, dass aus der Literatur, Veröffentlichungen in der Presse oder aus eigenen
Überlegungen neue generische Angriffsmuster gefunden werden, so sollte das
Sicherheitsniveau der Anlage abnehmen (Randbedingung: keine zusätzlichen
Schutzmaßnahmen werden implementiert):
Sicherheitsniveauneu = 1 - [(Ak + n ) / (Ab + n)]
mit
n = Anzahl der neu gefundenen Angriffsmuster
ergibt sich wegen
1 – Ak / Ab > 1 – (Ak + n) / (Ab + n)
für das neue Sicherheitsniveau:
Sicherheitsniveaualt > Sicherheitsniveauneu
Das nachfolgende Beispiel soll das Konzept des Begriffes „Sicherheitsniveau“ verdeutlichen.
Es seien die folgenden generischen Angriffsmuster gegen SCADA-Systeme bekannt:
o Manipulation von Benutzerrechten (1)
o Manipulation der HMI-Software (2)
o Deaktivieren von HMI-Funktionen (3)
o Denial-of-Service-Angriff (DoS) (4)
Weiter wird angenommen, dass aufgrund der systemtechnischen Ausgestaltung der

Netzwerkverkabelung und der Konfiguration der Netzwerkkomponenten das Anschließen
eines Fremdgerätes nicht möglich wäre und deshalb DoS-Angriffe ausgeschlossen werden
können.
Daraus ergibt sich das Sicherheitsniveau mit 4 bekannten Angriffsszenarien [(1) … (4)] sowie
3 systembedingt möglichen Angriffsszenarien [(1) … (3)], d.h.
Ab = 4
Ak = 3
zu
Sicherheitsniveau = 1 - ( 3 / 4 ) = 0,25
Seite 134 von 262

Im Rahmen eines Audit-Verfahren gegen die SCADA-Anlage kommt nun der Betreiber zu
der Erkenntnis, dass ein Angriff gegen die Stromversorgung der Systeme möglich wäre. Dies
führt zu folgender Neubewertung
Ab = 5
Ak = 4
mit dem neuen Ergebnis
Sicherheitsniveauneu = 1 - ( 4 / 5 ) = 0,2
Die zusätzlich gewonnene Erkenntnis bezüglich eines weiteren Angriffsmusters reduziert das
Sicherheitsniveau der betrachteten Zielanlage von 25% auf 20% - unter der Annahme keiner
zusätzlichen Gegenmaßnahmen. Des Weiteren zeigt das - zugegeben sehr einfache -
Beispiel, dass sich die Veränderung des Audit-Ergebnisses auf die geänderte
Bedrohungslage zurückführen lässt. Subjektive Einschätzungen, wie z.B. die Zuweisung der
Eintrittswahrscheinlichkeit eines bestimmten Angriffes, fließen nicht in das Ergebnis ein.
SCADA-Angriffsoberfläche
Während die Größe „Sicherheitsniveau“ auf Basis der bekannten generischen und
umsetzbaren Angriffsmuster eine allgemeine Einschätzung des Sicherheitsniveaus der
Leittechnikanlage liefert, steht nun das Bedrohungspotential im Fokus der Betrachtung.
Zu diesem Zweck wird der Begriff der „Angriffsinstanz“ eingeführt. Angriffsinstanzen stellen
konkrete Umsetzungen (= Angriffsvarianten) der generischen Angriffsmuster dar. Die
Abbildung der generischen Angriffsmuster (hier: systemtechnischen Voraussetzungen) auf
die konkrete Anlagentopologie liefert die „kritischen“ Szenarien. Diese Lösungen geben zu
jedem Angriffsmuster die gefundenen systemtechnischen Kombinationen aus, die die
Angriffsvoraussetzungen erfüllen. Ein Angriffsmuster lässt sich ggf. gegen mehrere
Komponenten der Leitechnikanlage ausführen. Mithin beschreibt das Ergebnis die Vielfalt
der Angriffsmuster gegen die Zielanlage.
Ein Beispiel soll die bisher eingeführten Klassen von Angriffsszenarien verdeutlichen:
I. Mit Hilfe der Attack Tree-Methode wurde das generische Angriffsmuster

„Schadsoftware-Infektion via USB-Schnittstelle“ gefunden.
II. Die (automatisierte) Abbildung dieses generische Angriffsmusters auf die technische
Beschreibung der Zielanlage ( Systeme mit USB-Schnittstellen) überführt das
Seite 135 von 262

generische Angriffsszenario in das mögliche, d.h. kritische Szenario „Schadsoftware-

Infektion via USB-Schnittstelle“.
III. Schließlich liefert die (automatisierte) Analyse der Zielanlage die Angriffsinstanzen,
nämlich dass x Systeme mit diesem Szenario angegriffen werden können.
Anmerkung: die Größe „Angriffsoberfläche“ gibt die Häufigkeit der sogenannten „kritischen“
Angriffsszenarien an. Welche Systeme davon betroffen sind, liefert das unten beschriebene
Metrikelement „kritische Angriffspunkte“.
In der Sicherheitsmetrik stellt die SCADA-Angriffsoberfläche somit eine Angriffsmatrix dar,

die die systembedingte Anzahl der möglichen Angriffsvarianten gegen die Leittechnik angibt.
Jedes Angriffsmuster lässt sich als Tupel, bestehend aus den beiden Faktoren „Bezeichnung
Angriffsmuster“ und „Anzahl der Angriffsinstanzen“ beschreiben.
Die Angriffsoberfläche der Zielanlage, bestehend aus allen Angriffsmusterdaten, ist dann in
Form einer Matrix darstellbar:
Angriffsoberfläche := [ Angriffsmuster, AnzahlAngriffsinstanzen ]
Beispiel für die Metrikgröße „SCADA-Angriffsoberfläche“
Im Gegensatz zum Sicherheitsniveau bildet die Angriffsoberfläche konkrete

Angriffsszenarien gegen die Zielanlage ab. Beispielsweise können für Angriffsmuster gegen
eine fiktive SCADA-Anlage (siehe Kapitel 8) folgende Instanzen gefunden werden:
Angriffsszenario Anzahl der Angriffsinstanzen

Manipulation Benutzerrechte 75
Deaktivieren HMI-Funktion 64
usw. nn
Tabelle 6: Angriffsinstanzen
Die Analyse der beispielhaften Leittechnikanlage ergibt die SCADA-Angriffsoberfläche zu:
Manipulation Benutzerrechte, 75
Angriffsoberfläche = Deaktivieren HMI-Funktion, 64
xyz ..., nn
Seite 136 von 262

Kritische Angriffspunkte
Die im vorangegangenen Abschnitt beschriebene Metrikgröße „SCADA-Angriffsoberfläche“

stellte die Häufigkeit der Durchführbarkeit eines Angriffsmusters summarisch dar.
Beispielsweise lieferte die Analyse, dass das Angriffsmuster „Manipulation Benutzerrechte“
in 75 Varianten gegen die Zielanlage ausführbar ist.
Vor dem Hintergrund realer Betriebsverhältnisse ist es für den Betreiber hilfreich, zu
erkennen, welche Systeme oder Komponenten am häufigsten als Zielsysteme an
Angriffsszenarien beteiligt sind. Angesichts begrenzter Beschaffungs- und Wartungsbudgets
ist der Betreiber in der Lage, „kritische“ Systeme zu erkennen, um mit dem möglichen
Aufwand ein Maximum an Angriffsinstanzen zu verhindern.
Zu diesem Zweck wird die Variable „Anzahl Angriffsinstanzen“ zu einem Tupel

„Angriffsinstanz“ erweitert.
Angriffsinstanz = [ ID, Angriffsmuster, Zielsystemtyp, Zielsystem-ID, Quellsystem-ID ]
Die Auswertung der „kritischen Szenarien“ (siehe Kapitel 5.4.5), d.h. aller möglichen
Instanzen über alle Angriffsmuster hinweg, ermöglicht dem Betreiber, jene Systeme
ausfindig zu machen, die die größten Risiken bergen, d.h. über die meisten Angriffsinstanzen
realisierbar sind. Das Ergebnis der Bestimmung ergibt für jedes Teilsystem der
Leittechnikanlage die Summe aller Angriffsinstanzen gegen dieses Teilsystem.
Angriffspunkte = [ Zielsystem-IDn, Σi AngriffsinstanzenRelevanzi ]
für Teilsystem n, bei i Angriffsmustern
und
AngriffsinstanzenRelevanzi :=
0 wenn Angriffsinstanzi (Zielsystem-IDi ≠ Zielsystem-IDn)

1 wenn Angriffsinstanzi (Zielsystem-IDi = Zielsystem-IDn)
Beispiel für die Metrikgröße „kritischen Angriffspunkte“
Als Ergebnis der PROLOG-Analyse (der Beispielanlage) erhält man für folgende Systeme
die Häufigkeit möglicher Angriffe:
Seite 137 von 262

Zielsystem Anzahl der Angriffsinstanzen

HMI Thin Client „tc 05“ 65
HMI Server „hmiS01“ 59
Historian Server „histS01“ 45
usw. nn
Tabelle 7: Anzahl der Angriffsinstanzen
Dies ergibt die nachfolgende Matrix für die
tc05, 65
Angriffspunkte = hmiS01, 59
histS01, 45
Aus dieser „Hitliste“ der gefährdeten Systeme ist der Betreiber in der Lage, besonders
gefährdet Systeme zu identifizieren und Schutzmaßnahmen abzuleiten.
Kritikalität der Angriffsmuster
Die weiter oben eingeführte Variable „Sicherheitsniveau“ basiert auf den potentiell möglichen
und den bekannten Angriffsmustern, die für die Zielanlage in Frage kommen. Eine
Gewichtung der einzelnen Angriffsmuster, z.B. hinsichtlich des potentiellen Schadens oder
der Eintrittswahrscheinlichkeit, erfolgte aufgrund des spekulativen Charakters nicht.
Betrachtet man zusätzlich die Voraussetzungen für die sogenannten kritischen
Angriffsmuster, also jene Muster, die systembedingt möglich sind, erhält man eine weitere
Eigenschaft dieser Angriffsmuster: die Voraussetzungen eines Angriffsmusters lässt sich als
Hürde gegen Angreifer interpretieren, die es für einen erfolgreichen Angriff zu überwinden
gilt. Um die Angriffsvoraussetzungen als Baustein in die Sicherheitsmetrik integrieren zu
können, ist eine Klassifizierung notwendig.
Kapitel 5.2 unterzog die Angriffsvoraussetzungen bereits einer Zuordnung. Die

Voraussetzungen ließen sich in folgende Klassen einteilen:
 Zugangsmöglichkeiten („Access“)
 Kompetenzen („Knowhow“)
 Ausrüstung („Equipment“)
Seite 138 von 262

Zum Zweck der Klassifizierung erhalten die einzelnen Elemente einer Voraussetzungsklasse
jeweils einen Bewertungsfaktor zugeordnet. Dieser Faktor stellt keinen absoluten Wert dar,
sondern dient ausschließlich der Bewertung der Voraussetzungen einer Klasse relativ
zueinander.
Beispielhaft soll dieses Schema anhand der Angriffsvoraussetzungen hinsichtlich der

Zugangsmöglichkeiten illustriert werden. Betrachtet seien die Voraussetzungen für die
Zugänglichkeit einer fiktiven Leittechnikanlage. Die Zugangsvoraussetzungen lassen sich
anlagentypisch folgendermaßen beschreiben:
Zutritt zu … Bewertungsfaktor
Gelände 1
Gebäude 2
Leittechnikraum 3
Geräte in LT-Schrank 4
Tabelle 8: Bewertungsfaktoren "Zugang"
Hinweis: für die weitere Bildung der Sicherheitsmetrik ist die Anzahl der Elemente je
Voraussetzungsklasse ohne Bedeutung. Desgleichen ist es unerheblich, ob die
Gewichtungsfaktoren in einer Folge mit oder ohne Lücken vergeben werden. Die
Bewertungsfaktoren sollen lediglich ein relatives Maß untereinander bilden, das die
Schwierigkeit abbildet, die Voraussetzung zu erfüllen. Im vorliegenden Beispiel bezeichnet
ein größerer Bewertungsfaktor eine schwierigere Angriffsvoraussetzung.
Formal lassen sich die Voraussetzungen für kritische Angriffsszenarien wie folgt
beschreiben:
SzenarioV := [ Szenario-ID, Voraussetzung_Knowhow, Voraussetzung_Equipment,
Voraussetzung_Zugang ]
mit
Szenario-ID = Kennung der Szenarien
Voraussetzung_Knowhow = { Knowhow-1, Knowhow-2, … }
Voraussetzung_Equipment = { Equipment-1, Equipment-2, … }
Voraussetzung_Zugang = { Zugang-1, Zugang-2, … }
Seite 139 von 262

Die Variablen „Voraussetzung_<Klasse>“ enthalten die Mengen der

Angriffsvoraussetzungen der jeweiligen Voraussetzungsklasse
Ordnet man den einzelnen Voraussetzungselementen einen numerischen Bewertungsfaktor

zu, ergibt sich daraus ein Ordnungsschema für die Angriffsvoraussetzungen:
Voraussetzung_Knowhow = { k1, k2, … }
Voraussetzung_Equipment = { e1, e2, … }
Voraussetzung_Zugang = { z1, z2, … }
Unter der Voraussetzung der oben erwähnten Zuordnungsregel des Bewertungsfaktors, d.h.
ein numerisch größerer Wert bildet eine schwierigere Angriffsvoraussetzung, lässt sich für
jede Voraussetzungsklasse eines Szenarios die Angriffsschwierigkeit als Maximalwert der
Bewertungsfaktoren darstellen.
#Knowhow = max(k) | k ∈ {ki }
#Equipment = max(e) | e ∈ {ei } mit i Elementen der Voraussetzungsklasse
#Zugang = max(z) | z ∈ {zi }
Auf diese Weise lassen sich die Szenario-spezifischen Angriffsvoraussetzungen in einer

Matrix beschreiben:
Szenario = [Szenario-ID, #Knowhow, #Equipment, #Zugang]
Die Matrix „Szenario“ gibt die maximalen Bewertungsfaktoren hinsichtlich Knowhow,

Ausrüstung und Zugang für alle kritischen Angriffsszenarien wieder.
Anmerkung: An dieser Stelle ließe sich nun einwenden, dass die Bewertungsfaktoren
subjektiven Einflüssen unterliegen und sich nicht aus Fakten ableiten lassen. Dieser
Argumentation sei entgegengehalten, dass die Bewertungsfaktoren keine absoluten Werte
hinsichtlich einer Sicherheitsaussage darstellen, sondern für den weiteren Verlauf der
Analyse primär einer Ordnung der Angriffsvoraussetzungen dienen. Darüber hinaus
unterscheiden sich die Bewertungsfaktoren beispielsweise von subjektiven Einschätzungen
der Kompetenzen und Fähigkeiten unbekannter Angreifer dahin gehend, dass die
Bewertungsfaktoren transparent in den (automatisierten) Analyseprozess einfließen.
Seite 140 von 262

Demgegenüber verbleiben die Einschätzungen über potentielle Angreifer und deren

Auswirkungen auf die daraus resultierenden Analyseergebnisse im Gedankenmodell der
Auditoren und sind im Analyseverlauf nicht transparent nachvollziehbar. Des Weiteren stellt
die Transparenz des Modells sicher, dass das Bewertungsmodell bei unveränderten
Bewertungsfaktoren konsistent über die Zeit bleibt.
Nachdem die Voraussetzungen der Angriffsszenarien durch die Auditoren numerisch

festgelegt wurden, stehen die Bewertungsfaktoren aller Angriffsszenarien mit Hilfe der Matrix
„Szenario“ zur weiteren Verarbeitung bereit. Ziel dieses Metrik-Bausteines ist es, die
Kritikalität der möglichen Angriffsszenarien zu bewerten. Die drei vorangegangenen Metrik-
Bausteine „Sicherheitsniveau“, „SCADA-Angriffsoberfläche“ und „kritische Angriffspunkte“
wiesen allen Angriffsszenarien die gleiche Bedeutung zu. Eine Gewichtung beispielsweise
hinsichtlich potentieller Schäden oder zu überwindendender Voraussetzungen erfolgte nicht.
Im Gegensatz dazu soll die Metrik-Größe „Kritikalität“ den Angriffsszenarien eine individuelle
Gewichtung zuordnen.
Das Beurteilungsprinzip der „Kritikalität“ ist es, die potentiellen Angriffsmuster danach zu
bewerten, wie „schwierig“ es ist, die Szenarien zu realisieren, d.h. einen entsprechenden
Angriff gegen die Zielanlage auszuführen. Im Gegensatz zu den in Kapitel 6.3 kritisierten
Metrikansätzen, die auf (nicht verfügbaren) empirischen Daten basieren, berücksichtigt der
Baustein „Kritikalität“ zwei wesentliche Analyseelemente:
 die konkrete Betriebssituation der untersuchten Leittechnikanlage
 die Risikoakzeptanz des betreffenden Betreiberunternehmens
An dieser Stelle sei nochmals auf die Bedeutung des Begriffes „Risikoakzeptanz“ im Kontext
der vorliegenden Arbeit hingewiesen (s. a. 5.4.2): Im Gegensatz zu den kritisierten
risikobasierten Analyseansätzen, denen Vermutungen bzw. Einschätzungen zu den
Erfolgsaussichten von Angreifern zugrunde liegen (4.2.4), soll die Risikoakzeptanz
nachvollziehbar darstellen, welche Angriffsszenarien der Betreiber aufgrund der
Angriffsvoraussetzungen als hinreichend unwahrscheinlich und mithin das damit verbundene
Betriebsrisiko als akzeptabel klassifiziert.
Die Kritikalität der Angriffsszenarien soll die Anzahl der potentiellen Angriffsmuster angeben,
die einer vorgegebenen Akzeptanzschwelle des Betreibers nicht genügen. Zu diesem Zweck
ist für die automatisierte Beurteilung der Angriffsszenarien, die Risikoakzeptanz des
Betreibers zu definieren und einer automatisierten Verarbeitung zugänglich zu machen. Dies
geschieht mit Hilfe des Tupel
RisikovektorBetreiber := [ #KnowhowBetreiber, #EquipmentBetreiber, #ZugangBetreiber]
Seite 141 von 262

Der RisikovektorBetreiber beschreibt, welches Risiko der Betreiber als akzeptabel einstuft.
Die Kritikalität der Angriffsmuster ergibt sich dann aus
Szenario = [Szenario-ID, #Knowhow, #Equipment, #Zugang]
RisikovektorBetreiber = [ #KnowhowBetreiber, #EquipmentBetreiber, #ZugangBetreiber]
mit Hilfe der Überleitung
Kritikalität := # { a ∈ Szenario: #KnowhowBetreiber > #Knowhow ˅
#EquipmentBetreiber > #Equipment ˅
#ZugangBetreiber > #Zugang }
Die Formel „Kritikalität“ gibt die Anzahl der kritischen Angriffsszenarien an, deren
Angriffsvoraussetzungen als geringer (d.h. „einfacher zu realisieren“) eingeschätzt werden
als die Risikoakzeptanz des Betreibers ( #KnowhowBetreiber, #EquipmentBetreiber,
#ZugangBetreiber ).
Das Kritikalität-Bewertungsschema soll anhand eines Beispiels zur Beurteilung der

Voraussetzungen hinsichtlich der Zugangsmöglichkeiten dargestellt werden:
Aus der Annahme, dass der Betreiber bereit ist, die Risiken aus jenen Angriffsszenarien zu
akzeptieren, die einen physischen Zugang zu den Leittechnikkomponenten in den
verschlossenen Leittechnikschränken voraussetzen (Betreiber: „sehr schwierig“), ergibt sich
ein Wert für
#ZugangBetreiber = 4 ( „Zugriff auf Geräte in LT-Schrank“, siehe Tabelle 8)
Hinsichtlich des Voraussetzungsklasse „Zugang“ liefert „Kritikalität“ die Anzahl aller

Angriffsszenarien deren maximaler Bewertungsfaktor #Zugang < 4 ist. Diese Bewertung der
Angriffsszenarien lässt sich dahingehend interpretieren, dass der Betreiber bereit ist, Risiken
aus jenen Angriffsszenarien zu akzeptieren, die physikalischen Zugriff auf die
Leittechnikkomponenten erfordern. Grund dafür könnte sein, dass – aus Sicht des Betreibers
– die physische Zutrittskontrolle sowie die Überwachung der Leittechnikschränke (in denen
die Geräte eingebaut sind) als hinreichend eingeschätzt werden: Angriffsszenarien, die einen
physischen Zugriff auf die Geräte erfordern, können also ausgeschlossen werden.
Demgegenüber schätzt der Betreiber Angriffsszenarien, denen Zugangsvoraussetzungen ein
Bewertungsfaktor < 4 zugeordnet wird, als realisierbar ein, so dass jene Angriffsszenarien
unbedingt in der Sicherheitsmetrik zu visualisieren sind.
Der Betreiber ist nun Lage, zu definieren, welche Risiken akzeptabel sind, wobei die Risiken
durch die vom Angreifer zu erfüllenden Angriffsvoraussetzungen beschrieben sind.
Seite 142 von 262

Die relative Kritikalität der Angriffsmuster gibt den Anteil der potentiellen Angriffsszenarien
an, die den Anforderungen des Betreiber-Risikovektors nicht genügen:
Kritikalitätrelativ := Kritikalität / Angriffsszenarienpotentiell
Die Kritikalität der potentiellen Angriffsszenarien stellt somit die Anzahl der kritischen
Szenarien dar, denen die Angriffsvoraussetzungen für eine erfolgreiche Umsetzung als
niedriger klassifiziert werden, als es der Risikoakzeptanz der Betreiber entspricht.
An dieser Stelle soll zur Illustration ein Beispiel für die Variablen „Kritikalität“ und „relative
Kritikalität“ dargestellt werden:
Betrachtet seien der Übersichtlichkeit wegen lediglich die Voraussetzungen für die
Zugänglichkeit zur Leittechnikanlage. Die Zugangsvoraussetzungen lassen sich
anlagentypisch folgendermaßen beschreiben.
Voraussetzung_Zutritt Bewertungsfaktor
Gelände 1
Gebäude 2
Leittechnikraum 3
Geräte in LT-Schrank 4
Tabelle 9: Beispiel für Bewertungsfaktoren "Zugang"
Die Zugang-Komponente des Risikovektors legt der Betreiber auf 3 fest. Dies bedeutet, der
Betreiber akzeptiert Risiken, die sich aus Angriffsszenarien ergeben, die einen Zugang zum
Leittechnikraum erfordern.
RisikovektorBetreiber (Zugang) = 3
Die Kritikalität gibt dann die Anzahl aller kritischen Szenarien an, die als
Angriffsvoraussetzungen nur Zugang zum Gelände oder Gebäude, jedoch nicht zum
Leittechnikraum erfordern. Für eine fiktive Anlage, die diesem Beispiel zugrunde liegt,
ergaben sich 59 Angriffsszenarien, deren Zugangsvoraussetzungen keinen physischen
Zugriff auf die Leitechnikkomponenten erfordert (#Zugang < 4).
Seite 143 von 262

Angesichts der Anzahl von 67 realisierbaren („kritischen“) Angriffsszenarien ergibt sich eine
relative Kritikalität von
Kritikalitätrelativ = Kritikalität / Angriffsszenarienpotentiell = 59 / 67 = 88%
An dieser Stelle sei auf den wesentlichen Unterschied zu den typischen Risikobetrachtungen
in der Literatur hingewiesen: während Risikoanalysen üblicherweise (mehr oder weniger
nicht begründbare) Vermutungen darüber anstellen, wie wahrscheinlich ein erfolgreicher
Angriff eines vollkommen unbekannten Angreifer unter unbekannten Randbedingungen ist,
leitet die vorliegenden Arbeit das Risiko ausschließlich aus den bekannten
Angriffsvoraussetzungen ab. Eine Vermutung („Wahrscheinlichkeit“) hinsichtlich den
Fähigkeiten oder Intentionen unbekannter Angreifer ist überflüssig. Die Einschätzung des
Betreibers hinsichtlich des akzeptierten Risikos kann keinesfalls aus Fakten abgeleitet
werden. Deshalb ist es zwingend notwendig, dass die Daten dieser Einschätzung in
transparenter und nachvollziehbarer Weise in die Beurteilung der IT-Sicherheit der
Leittechnikanlage einfließen.
6.5.2 Dynamische Metrikinhalte
Der vorangegangene Abschnitt beschrieb die Sicherheit leittechnischer Anlagen anhand der
folgenden Variablen:
 Sicherheitsniveau
 SCADA-Angriffsoberfläche
 Kritische Angriffspunkte
 Kritikalität der Angriffsmuster
 Relative Kritikalität der Angriffsmuster
Diese Variablen bilden statische Metrikbausteine, die den Anlagenzustand als

Momentaufnahme zum Zeitpunkt der Analyse dokumentieren.
Für die Darstellung des Verlaufes des Sicherheitsstatus der Leittechnikanlage über die
Betriebszeit sind zeitabhängige Metrikinhalte notwendig. Zu diesem Zweck lassen sich die
Werte der numerischen Variablen Kritikalität und relative Kritikalität in einem Zeitdiagramm
darstellen. Die Variablen SCADA-Angriffsoberfläche und kritische Angriffspunkte stellen
tabellarische Größen dar. Deshalb bietet es sich an, diese Inhalte bezüglich der
anzuzeigenden Analysezeitpunkte in tabellarischer Form gegenüberzustellen. An dieser
Stelle sei angemerkt, dass die Struktur der vorgeschlagenen Sicherheitsmetrik entweder
Seite 144 von 262

beschreibende Einzelwerte (z.B.: „Sicherheitsniveau“) oder Aussagen in Listenform (z.B.

„SCADA-Angriffsoberfläche“) enthält. Diese Metrikstruktur erlaubt, Analyseergebnisse
verschiedener Zeitpunkte auch dann miteinander zu vergleichen, wenn sich z.B. die Anzahl
der Angriffsszenarien oder die Struktur der Leittechnikanlage verändern. Diese
vorgeschlagene Methodik ermöglicht die Veränderungen des Sicherheitsstatus von
Analysezeitpunkt zu Analysezeitpunkt zu beurteilen.
In Kapitel 8.2.3 werden Beispiele der statischen und dynamischen Metrikinhalte dargestellt.
6.5.3 Auswirkung geänderter Randbedingungen auf resultierende Metrik
Die beiden vorangestellten Abschnitte beschrieben die statische sowie die dynamische
Perspektive der vorgeschlagenen Sicherheitsmetrik. An dieser Stelle sollen nun die
Auswirkungen von Änderungen der bestimmenden Randbedingungen auf die resultierenden
Metriken qualitativ beschrieben werden. Bei in zeitlichem Abstand durchgeführten
Sicherheitsanalysen einer Anlage können Änderungen der Randbedingungen auftreten, die
Einfluss auf die Metrikdaten haben:
- Änderung der Bedrohungslage aufgrund neu bekannt gewordener Angriffsvarianten

(siehe 5.4.3) und
- Technische Veränderungen an der Leittechnikanlage, z.B. zusätzliche SCADA-

Komponenten (siehe 5.4.4)
Da eine quantitative Analyse sowohl eine konkrete Anlagenstruktur sowie detaillierte

Änderungen der Angriffsszenarien voraussetzt und damit jedoch nicht mehr allgemeingültig
wäre, soll nachfolgend eine qualitative Betrachtung der Auswirkungen von Änderungen
erfolgen. Ziel dieser Betrachtung ist es, die Wirkrichtung von Änderungen auf die
Sicherheitsmetrik zu beurteilen.
Grundlage der Betrachtung sind die vier grundlegenden Formeln für die Bildung der
Sicherheitsmetrik aus 6.5.1:
(1) Sicherheitsniveau = 1 - (Ak / Ab )

mit den Variablen
Ak : kritische Angriffsszenarien (systembedingt mögliche Angriffe)
(2) Angriffsoberfläche := [ Angriffsszenario i, Anzahl_Instanzen i ]

für i Angriffsmuster
Seite 145 von 262

(3) Kritische Angriffspunkte = [Zielsystem-IDn, Σi AngriffsinstanzenRelevanzi]
für Teilsystem n, bei i Angriffsmuster
(4) Kritikalität := # { a ∈ Szenario: #KnowhowBetreiber > #Knowhow ˅
Die Betrachtung der Auswirkungen geht von zwei Sicherheitsanalysen zu den beiden
Zeitpunkten t = t1 und t = t2 aus. In zwei Teilschritten sollen zunächst die Auswirkungen von
Änderungen der Bedrohungslage und anschließend die Änderungen an der
Leittechnikstruktur untersucht werden.
Schritt 1: Änderung der Bedrohungslage
Die veränderte Bedrohungslage wirkt sich auf die Sicherheitsanalyse dergestalt aus, dass
zusätzliche Angriffsszenarien zu berücksichtigen sind:
Analyse zum Zeitpunkt t1: Ak (t1), Ab (t1)
Analyse zum Zeitpunkt t2: Ak (t2), Ab (t2)
Die Änderung der Bedrohungslage von Zeitpunkt t1 nach t2 ist in zwei Varianten möglich:
1) Neue Angriffsszenarien werden bekannt und alle Szenarien sind

technologiebedingt gegen die Zielanlage ausführbar
2) Neue Angriffsszenarien werden bekannt, sind jedoch technologiebedingt nicht

gegen die Zielanlage ausführbar
Aus obiger Formel (1) ergeben sich für die Metrikgröße „Sicherheitsniveau“ aus den beiden
Varianten folgende Auswirkungen:
Variante 1)
Kritische Angriffsszenarien: Ak (t1) < Ak (t2)
Bekannte Angriffsszenarien: Ab (t1) < Ab (t2)
Seite 146 von 262

 Sicherheitsniveau (t1) > Sicherheitsniveau (t2)
d.h. durch die neu bekannt gewordenen und ausführbaren Angriffsszenarien

nimmt das Sicherheitsniveau ab.
Variante 2)
Kritische Angriffsszenarien: Ak (t1) = Ak (t2)
Bekannte Angriffsszenarien: Ab (t1) < Ab (t2)
 Sicherheitsniveau (t1) < Sicherheitsniveau (t2)
d.h. durch die neu bekannt gewordenen, aber nicht ausführbaren

Angriffsszenarien steigt das Sicherheitsniveau.
Aus obiger Formel (2) ergeben sich für die Metrikgröße „Angriffsoberfläche“ aus den beiden
Variante 1)
 Angriffsoberfläche (t1) < Angriffsoberfläche (t2)
d.h. durch die neu bekannt gewordenen und ausführbaren Angriffsszenarien wird
die Angriffsoberfläche größer.
Variante 2)
 Angriffsoberfläche (t1) = Angriffsoberfläche (t2)

Angriffsszenarien bleibt die Angriffsoberfläche unverändert.
Aus obiger Formel (3) ergeben sich für die Metrikgröße „Kritische Angriffspunkte“ aus den
beiden Varianten folgende Auswirkungen:
Variante 1)
Seite 147 von 262

 Kritische Angriffspunkte (t1) < Kritische Angriffspunkte (t2)
d.h. durch die neu bekannt gewordenen und ausführbaren Angriffsszenarien

nimmt die Anzahl der kritischen Angriffspunkte zu.
Variante 2)
 Kritische Angriffspunkte (t1) = Kritische Angriffspunkte (t2)

Angriffsszenarien bleibt die Anzahl der kritischen Angriffspunkte unverändert.
Aus obiger Formel (4) ergeben sich für die Metrikgröße „Kritikalität“ aus den beiden
Variante 1)
 Kritikalität (t1) < Kritikalität (t2)
d.h. falls die Angriffsvoraussetzungen der neu bekannt gewordenen und

ausführbaren Angriffsszenarien der Risikotoleranz des Betreibers nicht genügen,
nimmt die Kritikalität zu, ansonsten bleibt die Kritikalität unverändert.
Variante 2)
 Kritikalität (t1) = Kritikalität (t2)

Angriffsszenarien bleibt die Kritikalität unverändert.
Seite 148 von 262

Schritt 2: Änderung der Leittechnikstruktur
Im vorangegangenen Schritt 1 wurden die Auswirkungen von Änderungen der

Bedrohungslage auf die Metrik-Kennzahlen betrachtet. Zwischen den Zeitpunkten t1 und t2
zweier Sicherheitsanalysen kann sich jedoch nicht nur die allgemeine Bedrohungslage
ändern, sondern auch Struktur und Umfang der Leittechnikanlage. Schritt 2 beschreibt nun
die Auswirkungen technischer Änderungen der Leittechniksysteme auf die Metrik-
Kenngrößen.
Für Schritt 2 ergeben sich folgende Varianten:
1) Bedingt durch technische Änderungen an der Leittechnikanlage sind weniger

Angriffsszenarien ausführbar (z.B. aufgrund von Sicherheitsmaßnahmen)
2) Bedingt durch technische Änderungen an der Leittechnikanlage nimmt die Anzahl

der ausführbaren Angriffsszenarien zu (z.B. aufgrund der Erweiterung der
Leittechnikanlage)
Wie in Schritt 1 bilden die vier grundlegenden Formeln für die Bildung der Sicherheitsmetrik
aus 6.5.1 die Basis der Betrachtung:
(1) Sicherheitsniveau = 1 - (Ak / Ab )
mit den Variablen
Ak : kritische Angriffsszenarien (systembedingt mögliche Angriffe)
(2) Angriffsoberfläche := [ Angriffsszenario i, Anzahl_Instanzen i ]
für i Angriffsmuster
(3) Kritische Angriffspunkte = [Zielsystem-IDn, Σi AngriffsinstanzenRelevanzi]
für Teilsystem n, bei i Angriffsmuster
(4) Kritikalität := # { a ∈ Szenario: #KnowhowBetreiber > #Knowhow ˅
Seite 149 von 262

Aus obiger Formel (1) ergeben sich für die Metrikgröße „Sicherheitsniveau“ aus den beiden
Variante 1)
Kritische Angriffsszenarien: Ak (t1) > Ak (t2)
Bekannte Angriffsszenarien: Ab (t1) = Ab (t2)
 Sicherheitsniveau (t1) < Sicherheitsniveau (t2)
d.h. die reduzierte Anzahl von ausführbaren Angriffsszenarien zum Zeitpunkt t 2

(z.B. aufgrund von Schutzmaßnahmen) steigert das Sicherheitsniveau.
Variante 2)
Bekannte Angriffsszenarien: Ab (t1) = Ab (t2)
 Sicherheitsniveau (t1) > Sicherheitsniveau (t2)
d.h. die neu aufgedeckten, ausführbaren Angriffsszenarien (z.B. aufgrund der

technischen Änderungen am Leitsystem) senken das Sicherheitsniveau zum
Zeitpunkt t2 ab.
Aus obiger Formel (2) ergeben sich für die Metrikgröße „Angriffsoberfläche“ aus den beiden
Variante 1)
 Angriffsoberfläche (t1) > Angriffsoberfläche (t2)
d.h. die geringere Anzahl von ausführbaren Angriffsszenarien zum Zeitpunkt t2

(z.B. aufgrund von Schutzmaßnahmen) reduziert die Angriffsoberfläche.
Seite 150 von 262

Variante 2)
 Angriffsoberfläche (t1) < Angriffsoberfläche (t2)

technischen Änderungen am Leitsystem) vergrößern die Angriffsoberfläche.
Aus obiger Formel (3) ergeben sich für die Metrikgröße „Kritische Angriffspunkte“ aus den
beiden Varianten folgende Auswirkungen:
Variante 1)
 Kritische Angriffspunkte (t1) > Kritische Angriffspunkte (t2)
d.h. die geringere Anzahl von ausführbaren Angriffsszenarien zum Zeitpunkt t2

(z.B. aufgrund von Schutzmaßnahmen) reduziert die Anzahl der kritischen
Angriffspunkte.
Variante 2)
 Kritische Angriffspunkte (t1) < Kritische Angriffspunkte (t2)

technischen Änderungen am Leitsystem) vergrößern die Anzahl der kritischen
Angriffspunkte.
Aus obiger Formel (4) ergeben sich für die Metrikgröße „Kritikalität“ aus den beiden
Variante 1)
 Kritikalität (t1) > Kritikalität (t2)
Seite 151 von 262

d.h. die geringere Anzahl bekannter und ausführbaren Angriffsszenarien, die der
Risikotoleranz des Betreibers nicht genügen, reduziert die Kritikalität, ansonsten
bleibt die Kritikalität unverändert.
Variante 2)
 Kritikalität (t1) < Kritikalität (t2)
d.h. falls die neu bekannt gewordenen, ausführbaren Angriffsszenarien der

Risikotoleranz des Betreibers nicht genügen, steigt die Kritikalität der
Angriffsszenarien, ansonsten bleibt die Kritikalität unverändert.
Die beiden Schritte zur separaten Beurteilung der Auswirkung von veränderter
Bedrohungslage bzw. der Veränderung der Struktur der Leittechnikanlage zeigen, dass sich
die Änderungen konsistent auf die Metrikgrößen auswirken. Für die praktische Anwendung
der Metrik ergibt sich daraus die Schlussfolgerung, die Analyse ebenfalls in zwei Teilschritten
durchzuführen, um hinreichende Ursachentransparenz der auftretenden Änderungen an
Metrikdaten sicherzustellen.
6.5.4 Interpretation der vorgeschlagenen Sicherheitsmetrik
Die in den vorangegangenen Abschnitten vorgeschlagene Sicherheitsmetrik, muss – wie

jede vergleichbare Metrik – im Kontext der operativen Betriebsumgebung interpretiert
werden: die Kenngrößen der Metrik müssen zum Zwecke der operativen Betriebsführung
eindeutige Schlussfolgerungen erlauben.
Nachfolgend sollen die einzelnen Metrikgrößen eine Abbildung auf Entscheidungen im

Kontext der betrieblichen Abläufe erfahren:
 Sicherheitsniveau – Indikator potentieller Angreifbarkeit
Das Sicherheitsniveau stellt einen Indikator hinsichtlich der potentiellen Angreifbarkeit der
Anlage dar. In das Sicherheitsniveau fließen sowohl die allgemein bekannten
Angriffsszenarien ein, als auch die systemtechnisch bedingt gegen die Anlage ausführbaren
Angriffsszenarien. Somit reflektiert diese Größe die allgemeine Bedrohungslage (bekannte
Angriffsszenarien), aber auch die Wirksamkeit der aktuell wirksamen Schutzmaßnahmen
Seite 152 von 262

(ausführbare Angriffsszenarien). Die Größe „Sicherheitsniveau“ lässt sich somit in die

Unternehmenssteuerung als nachprüfbare Zielvorgabe, wie auch als langfristige
Fortschreibung der erreichten Anlagensicherheit integrieren.
 SCADA-Angriffsoberfläche – Kenngröße potentieller Angriffsmöglichkeiten
Die SCADA-Angriffsoberfläche beschreibt die Vielzahl der systembedingt möglichen

Angriffsvarianten gegen die Leittechnik.
 Kritische Angriffspunkte – Schwachpunkte der Leittechnikanlage
Die kritischen Angriffspunkte decken die Vielzahl der Angriffsmöglichkeiten gegen die
verschiedenen Systeme und Komponenten einer Leittechnikanlage auf. Damit lassen sich
Maßnahmen zur Verbesserung der Sicherheit auf jene Elemente konzentrieren, die für
Angreifer die meisten Schwachstellen bereithalten.
 Kritikalität der Angriffsmuster
Die „Kritikalität“ der potentiellen Angriffsmuster visualisiert die Schwierigkeit im Sinne einer
Angriffshürde, die Angriffsszenarien zu realisieren, d.h. einen entsprechenden Angriff gegen
die Zielanlage auszuführen. Die Kenngröße basiert auf den Voraussetzungen Knowhow,
Ausrüstung und Zugangsmöglichkeit und zeigt dem Betreiber auf, wie sich für die Anlage
hinsichtlich dieser 3 Dimensionen Verbesserungspotential ergibt.
 Relative Kritikalität der Angriffsmuster
Die relative Kritikalität der Angriffsmuster zeigt auf, wie hoch der Anteil der potentiellen
Angriffsszenarien ist, die den Anforderungen des Betreiber-Risikovektors nicht genügen. Im
Zusammenspiel mit der (absoluten) Kritikalität sowie der Angriffsoberfläche lassen sich im
betrieblichen Entscheidungsprozess Verbesserungspotentiale und Schwachpunkte der
Leittechniksicherheit identifizieren.
Zu Beginn dieses Kapitels wurden Begriffe und aktuelle Ansätze für IT-Sicherheitsmetriken
skizziert. Es zeigten sich erhebliche Schwachstellen der recherchierten und vorgestellten
Metriken. Als wesentliche Defizite stellten sich heraus:
 die Kennzahlen gängiger Sicherheitsmetriken bilden nur bedingt die IT-Sicherheit der
betrachteten Zielsysteme ab
Seite 153 von 262

 verschiedene Ansätze verwenden empirischer Daten ohne den Nachweis der

Gültigkeit für individuelle Anlagen zu erbringen
 Betreiber können aus den gefundenen Kennzahlen keine Handlungsoptionen ableiten
Unter Berücksichtigung der Randbedingungen für leittechnische Anlagen lassen sich

Anforderungen für SCADA-Sicherheitsmetriken zusammenstellen. Für eine IT-
Sicherheitsmetrik, die eine hinreichende Abbildung der IT-Sicherheit der Leittechniksysteme
leistet, müssen folgende, wesentliche Randbedingungen gelten:
 die Metrik muss eine Aussage zur Sicherheit der Zielanlage liefern
 transparente Abbildung der Basisgrößen auf die Sicherheitsmetrik
 Nachvollziehbarkeit der Metrikbildung
 Konsistenz der Metrikbildung über die Zeit
 Berücksichtigung der Struktur der betrachteten Zielanlage
 Anwendbarkeit auf singulär Anlagen (Einzelanlagen)
Diese Randbedingungen bestimmen den Vorschlag einer IT-Sicherheitsmetrik für

Leittechniksysteme, die sich in zwei wesentliche Informationsbereiche untergliedert:
 statischer Metrikbereich und
 dynamischer Metrikbereich
Der statische Metrikbereich liefert die Informationen hinsichtlich der Sicherheit der Zielanlage
zum Zeitpunkt der Analyse und umfasst folgende Sicherheitsaspekte:
 Sicherheitsniveau, d.h. eine numerische Aussage über die Anzahl möglicher

Angriffsvarianten gegen die betrachtete Anlage
 SCADA-Angriffsoberfläche, d.h. eine Aussage über die Vielfalt mit der Varianten der
Angriffsszenarien in der Zieltopologie umsetzbar sind
 kritische Angriffspunkte, d.h. die Anzahl potentieller Angriffsszenarien gegen die

einzelnen Teilsysteme der Leittechnikanlage
 Kritikalität der Angriffsmuster, d.h. Bewertung der möglichen Angriffsszenarien

anhand der Angriffsvoraussetzungen und der Risikoakzeptanz des Betreibers
 Relative Kritikalität der Angriffsmuster, d.h. der Anteil der potentiellen

Angriffsszenarien, die der der Risikoakzeptanz des Betreibers nicht genügen
Seite 154 von 262

Die Fortschreibung der statischen Metrikdaten über die Betriebszeit der Anlage hinweg aus
wiederkehrenden Anlagenanalysen liefert den zeitlichen Verlauf der IT-Sicherheit der
Leittechnikanlage.
 Der dynamische Informationsbereich der Sicherheitsmetrik stellt die Veränderung der

IT-Sicherheit im Verlauf der Zeit dar, d.h. über mehrere Anlagenanalysen hinweg
Die vorgeschlagene Metrik liefert für Leittechniksysteme die Visualisierung des Status der IT-
Sicherheit unter Berücksichtigung:
 des Sicherheitsniveau der Zielanlage
 der Struktur und Bestandteile der Zielanlage
 der Anfälligkeit der Teilsysteme
 der Risikoakzeptanz des Betreibers
 des aktuellen Anlagenstatus
 der zeitlichen Veränderung über wiederkehrende Anlagenanalysen hinweg
Die Beachtung der skizzierten Randbedingungen, d.h. die Aussagen zur Systemsicherheit,
die Transparenz und Nachvollziehbarkeit der Abbildung, stellen
 die Konsistenz der Sicherheitsmetrik über die Zeit
hinweg sicher. In die (automatisierte) Analyse der Zielanlage fließt die Struktur der
individuellen Zielanlage ein.
Seite 155 von 262

Kapitel 7 Werkzeugbasierte Durchführung der Analyse
7 Werkzeugbasierte Durchführung der Analyse

Die vorangegangenen Kapitel beschrieben einen neuartigen Ansatz zur Analyse und
Beurteilung der IT-Sicherheit leittechnischer Systeme. Diese Methodik umfasste folgende
Schritte:
 Beschreibung der Angriffsszenarien
 Beschreibung der Zielanlage
 Herleitung der möglichen Angriffsszenarien im Kontext der Zielanlage
 Bestimmung der Kennzahlen der Sicherheitsmetrik
In diesem Kapitel soll die technische Vorgehensweise der Methode beschrieben werden.
Dies beginnt mit den Randbedingungen, die die Methode erfüllen muss, um eine effiziente
Analysedurchführung zu ermöglichen.
Methodeneffizienz
Die Effizienz der Methode, d.h. ein möglichst geringer Zeit- und Arbeitsaufwand,
insbesondere für die Datenerfassung der Angriffsszenarien und der
Zielanlagenbeschreibung, ist Voraussetzung für ihre regelmäßige betriebliche Anwendung.
Wiederverwendbarkeit der Basisdaten
Für die Effizienz der Methode spielt der Aufwand für die Datenerfassung eine entscheidende
Rolle. Hierbei sind zwei Perspektiven zu berücksichtigen:
 die analysebedingt notwendigen Menge der zielsystemspezifischen Daten aus den

untersuchten Systemen sowie
 der Aufwand für die Datenbeschaffung
Hierbei müssen allerdings zwei Fälle unterschieden werden: die erstmalige Analyse nach der
vorgeschlagenen Methodik und nachfolgende Wiederholungen. Im Rahmen der erstmaligen
Anwendung ist ein höherer Aufwand zur Beschaffung der Daten zulässig. Bei nachfolgenden
Wiederholungen ist der Aufwand auf ein Minimum zu reduzieren. Minimum soll in diesem
Kontext bedeuten, dass nur jene Daten neu zu erfassen sind, die Änderungen der
Seite 156 von 262

Bedrohungslage, d.h. der anzuwendenden Angriffsszenarien, oder der Zielanlage, z.B.

aufgrund zusätzlicher Komponenten in der Leittechnikanlage, abbilden.
Automatisierbarkeit der Methode
Die weitgehende Automatisierbarkeit der Methode reduziert die manuellen

Eingriffsnotwendigkeiten mit der Gefahr unabsichtlicher Erfassungs- oder Eingabefehler. Die
Konsistenz der verwendeten Analysedaten ist die Voraussetzung für die Vergleichbarkeit der
Analyseergebnisse. Der Ausschluss manueller, d.h. unter Umständen nicht reproduzierbarer
Eingriffe in den Verlauf der Analyse führt zu einem konsistenten algorithmischen
Analyseverlauf, dessen mögliche Ergebnisvarianz nur noch von den Eingabedaten abhängt.
Bevor auf die datentechnische Umsetzung der vorgeschlagenen Methode eingegangen wird,
sollen kurz aus der Literatur bekannte Analyseverfahren hinsichtlich Methodik und
Anwendbarkeit dem vom Verfasser vorgeschlagenen Ansatz gegenübergestellt werden.
7.1 Automatisierte Analyseverfahren
7.1.1 Beurteilungsrahmen der Analysemethoden
Für die Beurteilung und Einordnung der gefundenen (semi-) automatisierten

Analyseverfahren zur Beurteilung der IT-Sicherheit wird folgendes Schema zugrunde gelegt.
Wesentliches Sortiermerkmal ist der Zielsystemtyp, d.h.
 Unternehmens-IT-Systeme oder
 SCADA-Systeme
Diese beiden Systemtypen lassen sich mit den Untergruppen
 Anwendungen
 Betriebssystem
 Schnittstellen
strukturieren. Des Weiteren sind – in einem erweiterten Sinne von „Peripherie“ – die
Untergruppen um die Kategorien „Cloud Services“ bzw. „Feldbereich“ zu ergänzen.
Da Leit- und Automatisierungssysteme auch Komponenten mit proprietären

Betriebssystemen beinhalten (RTU, PLC etc.), wurden die Betriebssysteme entsprechend
unterteilt.
Seite 157 von 262

Neben der Abdeckung der IT- bzw. SCADA-Systemstruktur spielt die der Analyse
zugrundeliegende Methodik, d.h. analysierte Faktenbasis, eine zentrale Rolle. Berücksichtigt
wurden die Analysen
 des Source-Codes und
 der Software-Schwachstellen
Schließlich ist für die Zielsetzung des vorliegenden Dokuments von Bedeutung, welche
Zielgruppe in der Lage ist, die Analyse durchzuführen. Aus diesen Überlegungen ergibt sich
das in Tabelle 10 dargestellte Beurteilungsschema.
Anwendbarkeit des
Methodenbasis
Verfahrens durch …
(semi-) automatisierte Analyseverfahren
für … Source Software- Hersteller / Anwender /
Code Schwachstellen Lieferant Betreiber
Anwendungen
Betriebssystem
IT-Systeme Schnittstellen
Netzwerkstruktur
Cloud Services
Anwendungen
Standard
Betriebssystem
SCADA- proprietär
Systeme
Schnittstellen
Netzwerkstruktur
Feldbereich
Tabelle 10: Beurteilungsschema automatisierter Analyseverfahren
In Kapitel 7.1.3 werden die vergleichenden Ergebnisse in diesem Beurteilungsschema

zusammengefasst.
7.1.2 Automatisierbare Analyseverfahren
Nachfolgend sind einige Beispiele automatisierbarer Analyseverfahren aufgelistet:
(Gutbrodt, 2007) schlägt die automatisierte Ausführung von Angriffen gegen die Feldebene
vor, um die Wirksamkeit von Schutzmechanismen auszuwerten. Potentielle
Seite 158 von 262

Angriffsrichtungen sind aus der Prozessleitebene auf die Feldebene oder durch direkte
Ankoppelung an die Feldebene.
Um möglichst einfach zahlreiche Angriffsvariationen zu erzeugen, setzt der Verfasser die

Technik des „Fuzz-Testing“ („Fuzzing“) ein. Die Penetrationstests sollen die Schwachstellen
aufdecken. Probleme des Verfahrens sind:
a. Integration von Mechanismen zur Rückmeldung von erkannten Angriffen in die

Schutzmechanismen der Feldebene ist notwendig (Geräteveränderung)
b. Ersetzung der Funktionalität der Feldgeräte durch Rückmeldemechanismen

(Geräteveränderung)
c. Simulation der Auswirkungen von Angriffen (Testumgebung)
(Zahid Anwar, 2008) betrachtet SCADA-Systeme für das elektrische Stromversorgungsnetz.

Das Hochspannungsnetz (Schalter, Leitungen, Transformatoren etc.) wird mittels
Prädikatenlogik als sogenanntes „Network model“ abgebildet. Die kritischen Stellen des
Versorgungsnetzes (hier: Feldebene) werden auf die Angreifbarkeit auf SCADA-
Systemebene aufgrund bekannter Schwachstellen untersucht. Als Maß für „Sicherheit“ wird
in einfacher Weise die Funktion der „Länge“ des Angriffspfades herangezogen. Die Auswahl
der SCADA-Komponenten in Abhängigkeit von ihrer Bedeutung für das Hochspannungsnetz
ist zwar für die Betrachtung dessen Betriebssicherheit sinnvoll, schränkt jedoch die
Allgemeingültigkeit der Methode für Leitsysteme ein.
(Bleikertz, 2010) beschreibt einen Ansatz zur Analyse von mehrschichtigen virtuellen
Infrastrukturen. Zu diesem Zweck wendet er die Ansätze für Schwachstellen-Assessments
traditioneller Rechnerumgebungen auf die Amazon Cloud-Infrastruktur an.
Zur Beurteilung der Sicherheit zieht der Autor die Erreichbarkeit von Systemen aufgrund der
IP-Adresse und der verwendeten Protokolle heran. Regelsätze beschreiben die zulässigen
Verbindungen.
Probleme des Verfahrens sind m.E. die Nutzung von Wahrscheinlichkeiten:
The idea is to convert vulnerability ratings into probabilities, i.e., the probability an
attacker can and will execute a certain attack to change from one attack state to the
next.
Seite 159 von 262

Des Weiteren bilden die bekannten Schwachstellen von Systemdiensten („services“) die
Grundlage, um die Widerstandsfähigkeit gegen Angriffe hinsichtlich Aufwand und Zeitbedarf
zu bestimmen.
(Mohamed Almorsy, 2013) stellt einen Ansatz vor, der ausgehend von Angriffsszenarien und
dafür definierten Angriffssignaturen die Sicherheit eines Systems anhand verschiedener
Metriken beurteilt. Nachteil der Methode ist, dass die notwendigen Informationen zur Bildung
der Metriken Anwendern bzw. Betreibern nicht zur Verfügung stehen.
In (Mohammad Salim Ahmed, 2010) beschreiben die Autoren ein Framework zur
Quantifizierung wesentlicher Security-Risikofaktoren. Auf der Basis bekannter
Schwachstellen sowie der historischen Entwicklung von Schwachstellen, wird für
Systemdienste die Schwere zukünftiger Schwachstellen abgeschätzt. Ausgehend von den
aktuellen Schwachstellen eines Systems evaluiert das vorgeschlagene Framework das zu
erwartende Risiko zukünftiger Schwachstellen.
Wesentliche Probleme des Verfahrens sind, dass es auf den bekannten Schwachstellen der
vorhandenen Services beruht und die Abschätzung zukünftiger Schwachstellen aus
historischen Schwachstellen-Daten ableitet. Das Fehlen solcher historischer Daten bei
SCADA-Systemen beschränkt die Methode auf typische IT-Systeme.
Die US-Behörde „National Institute of Standards and Technology” (NIST) hat die
Unterstützung des Werkzeuges zur automatisierten Selbstbeurteilung der IT-Sicherheit
(Automated Security Self-Evaluation Tool, ASSET) 2007 eingestellt (aufgrund der Ersetzung
von NIST SP800-26 durch NIST SP 800-53 bzw. NIST SP 800-53A). Anwender konnten
Antworten zu vorgegebenen Fragelisten manuell in ein Datenbank-gestütztes Client-Server-
System eingeben. Die Fragenliste basierte auf dem NIST-Dokument NIST SP 800-26 /
Anhang A. Die Fragen sind allgemeingültig für die Themenbereiche Risikomanagement,
Schutzmaßnahmen, System life cycle, Berechtigungsprozesse, Security Plan,
Personalprozesse, physische Sicherheit, unterstützende IT-Betriebsfunktionen,
Notfallplanung, HW-/SW-Wartung, Maßnahmen zur Sicherstellung der Datenintegrität,
Dokumentation, Schulung, Ereignismanagement usw. Auf Basis der eingegebenen Daten
ließen sich Berichte für eine betrachtete Anlage oder Berichte über alle Anlagen hinweg
erzeugen.
Seite 160 von 262

Die US-Behörde „Defense Advanced Research Projects Agency” (DARPA), eine

Unterorganisation des US-Verteidigungsministeriums, hat das Programm „Automated
Program Analysis for Cyber Security“ ins Leben gerufen. Das Programm zielt auf schnelle
und robuste Validierung der Sicherheit von mobilen Anwendungen (Apps). Über die
Erweiterung des Programmes auf andere Systemklassen, z.B. SCADA, sowie Ergebnisse
liegen dem Verfasser keine Erkenntnisse vor.
In dieser Zusammenstellung wurden die werkzeuggestützten Methoden zur Analyse des

Quellcodes im Rahmen einer Software-Entwicklung nicht betrachtet. Diese Methoden stehen
ausschließlich den Herstellern von Softwaresystemen zur Sicherung und Verbesserung der
Software-Qualität zur Verfügung und stellen für installierte, anlagenspezifische
Konfigurationen keine Analysemethode dar. Des Weiteren blieben Methoden zur
Untersuchung von Protokollen oder kryptografischen Verfahren außerhalb der Betrachtung.
7.1.3 Zusammenfassung und Bewertung der Analysemethoden
Die im vorangegangenen Kapitel aufgeführten automatisierbaren Methoden zur Beurteilung

der IT-Sicherheit von IT- und SCADA-Systemen decken nur einen Teil der Systemlandschaft
ab (siehe Tabelle 11).
Es fällt auf, dass mit einer Ausnahme (Zahid Anwar, 2008) keine Methode den Betreibern
von SCADA-Systemen die Beurteilung der IT-Sicherheit ihrer in Betrieb befindlichen Anlagen
ermöglicht. (Zahid Anwar, 2008) adressiert allerdings primär die Schwachstellen des
elektrischen Versorgungsnetzes (aus Sicht der Leitsysteme: Feldbereich). Für den Bereich
der SCADA-Komponenten mit proprietären Betriebssystemen sind ebenfalls keine
Analysemethoden veröffentlicht, die über die (vermutlichen) qualitätssichernden Maßnahmen
der Hersteller hinausgehen.
Eine allgemeingültige Methode für Leit- und Automatisierungssysteme ist somit auch nicht
gegeben.
Seite 161 von 262

Anwendbarkeit des
Methodenbasis
(semi-) automatisierte Verfahrens durch …
Analyseverfahren
für … Software- Hersteller / Anwender /
Source Code
Schwachstellen Lieferant Betreiber
(Mohamed
Almorsy, x ---
Anwendungen 2013)
(Mohammad Salim
x ---
Ahmed, 2010)
(Mohamed
IT- Almorsy, x ---
Systeme Betriebssystem 2013)
(Mohammad Salim
x ---
Ahmed, 2010)
Schnittstellen
Netzwerkstruktur
Cloud Services (Bleikertz, 2010) x (x)
(Mohamed
Anwendungen Almorsy, x ---
2013)
(Mohamed
Almorsy, x ---
Betriebs Standard 2013)
-system (Mohammad Salim
x ---
SCADA- Ahmed, 2010)
Systeme proprietär
Schnittstellen
Netzwerkstruktur
(Gutbrodt, 2007) x ---

Feldbereich (Zahid Anwar,
x x
2008)
Tabelle 11: Zusammenfassung der Analysemethoden
7.2 Technische Umsetzung des Analyseschemas
Auf Basis der vorgenannten Randbedingungen lassen sich die zu erfassenden Anlagendaten
in zwei Kategorien einordnen:
a) Daten, die sich automatisiert in den Zielsystemen erfassen lassen
b) Daten, die systemtechnisch nicht verfügbar sind oder deren Erfassung nicht
automatisiert möglich ist
Seite 162 von 262

In die erste Kategorie gehören beispielsweise Konfigurationsdaten aus Rechnersystemen.

Die Daten der zweiten Kategorie umfasst typischerweise manuell zu erfassende
Informationen, die nicht in der Leittechnik hinterlegt sind, wie z.B.
 Zuordnungen von Systemen zu Räumlichkeiten
 Zutrittsberechtigungen von Personen / Personengruppen zu Räumen
 Informationen zum Einbau von Leittechnikkomponenten in (abschließbare) Schränke
 (teilweise) Geräte-Identifikationskennungen
 (teilweise) Anschluss von Systemen an Switch-Netzwerk-Ports und Port-Zustände
Wie bereits in Kapitel 5.3.3 aufgezeigt, diente die Methode der „Attack Trees“ zur Herleitung
von Angriffsszenarien. Als Ergebnis liegen diese Szenarien als komponentenspezifisch
ausgeprägte Graphen vor, deren Wurzelknoten die betrachtete Komponente der
Leittechnikanlage bildet. Die Graphen-Endpunkte der einzelnen Graphen-Zweige liefern die
elementaren Voraussetzungen für die betrachteten Angriffsvarianten. Die Herleitung der
kritischen, d.h. tatsächlich möglichen Angriffsvarianten erfolgt durch Abbildung dieser
Voraussetzungen auf die Beschreibungen der Zielanlage. Der Analysealgorithmus stellt
somit das Suchen nach Lösungen dar, in denen die Voraussetzungen aus den Attack Tree-
Graphen mit den Systemeigenschaften übereinstimmen („Match“). Zur Implementierung
dieser Lösungssuche wird die Abbildung der Anlagen- und Szenario-Daten als Logik-
orientierte Wissensrepräsentation aufgefasst. Zur systemtechnischen Verarbeitung dient ein
PROLOG-System. Die PROLOG-Wissensbasis des Analysesystems besteht aus den
Fakten, die automatisiert oder manuell erfasst wurden sowie den PROLOG-Regeln, die der
Lösungssuche dienen.
Für das Analyseschema ergibt sich folgendes Automatisierungskonzept (siehe Abbildung

21):
1. Anlagendaten
Anlagendaten werden – soweit technisch möglich – automatisch aus den Zielsystemen

ausgelesen; Umgebungsdaten (Zutrittsberechtigungen, räumliche Zuordnungen etc.) werden
manuell hinzugefügt.
Seite 163 von 262

2. Szenario-Daten
Die Szenario-Definitionen (Szenario-ID, Zielsystem, Ausgangssystem, notwendiges

Knowhow, notwendige Ausrüstung, notwendige Informationen, Voraussetzungen der
Systemtechnik) sind einmalig je Szenario manuell zu beschreiben.
Die Übersetzung der Szenario-Daten in PROLOG-Klauseln erfolgt automatisch (Initial bzw.

nach Änderungen an den Szenario-Beschreibungen).
Abbildung 21: Übersicht des semi-automatischen Analyseablaufes
Die Analyseschritte 1 … 3 sind in Abbildung 22 detaillierter dargestellt.
Seite 164 von 262

3. Analyseschritt #1
Aus den Anlagendaten (PROLOG-Fakten) und den Szenario-Klauseln extrahiert der

Analyseschritt #1 automatisiert die aufgrund der vorgegebenen Struktur und Konfiguration
der Leittechnikanlage möglichen Angriffsszenarien („kritische Szenarien“).
Auf Basis der möglichen Angriffsszenarien und der Voraussetzungen, die ein Angreifer
erfüllen muss (aus Szenario-Daten: Knowhow, Zugang, Equipment) bestimmt Analyseschritt
#2 automatisiert die Menge der Szenario-spezifischen Voraussetzungen.
Abbildung 22: Datentechnisches Analyseschema
5. Bewertungsschema
Das Bewertungsschema (siehe 6.5) wird als statisch betrachtet und manuell für die in Frage
kommenden Angriffsvoraussetzungen erstellt (im Wesentlichen einmalig; Ergänzungen nur
im Falle zusätzlicher Voraussetzungen).
Seite 165 von 262

Auf Basis der Menge der gefundenen Angriffsvoraussetzungen und mittels Verknüpfung mit
dem Bewertungsschema erstellt Analyseschritt #3 automatisiert die finale Sicherheitsmetrik
für die betrachtete Leittechnikanlage.
Die Programmausführung, d.h. das Suchen nach Lösungen für die kritischen
Angriffsszenarien (Abbildung der Angriffsszenarien auf die Beschreibung der Zielanlage) und
die Ableitung der Sicherheitsmetrik ist in Abbildung 23 dargestellt. Die Daten der
Angriffsszenarien sowie der Anlagenbeschreibung sind in PROLOG-Klauseln (= Fakten)
abgebildet. Funktionsklauseln bilden das eigentliche PROLOG-Programm. Sie
bewerkstelligen den Suchprozess nach Lösungen, d.h. das Matching von Szenario-Daten
und Systemeigenschaften.
Abbildung 23: Übersicht Programmschema
Ausgehend von dieser Struktur erfolgten im Rahmen der Erprobung der Methodik an
Anlagenmodellen einige Optimierungsschritte. Zu diesem Zweck wurde der Analyseprozess
in einen PROLOG-Teil und einen Datenbankteil aufgespalten.
Seite 166 von 262

Die PROLOG-basierte Suche nach Schwachstellen in der SCADA-Anlagentopologie

erfordert Informationen über:
 die Netzwerkstruktur der Anlage
 sicherheitsrelevante Konfigurationsdaten der Systeme und Komponenten sowie
 zusätzliche Informationen über Anlage (z.B. physische Zugänglichkeit, temporäre /

permanente Anwesenheit von Personal etc.)
Ziel der Optimierung ist, eine eindeutige Trennung der Anlagendaten von der Struktur der
Datenhaltung sowie den verschiedenen Generierungsmechanismen herbeizuführen.
Aus Gründen der Handhabbarkeit im Rahmen einer praktischen Anwendung, wurden die
Datensätze, die bislang als PROLOG-Klauseln in Textdateien gehalten wurden, semantisch
gleichartig in Datenbanktabellen (hier: MS Access) überführt. Für die Anwendung in der
Praxis hat die Verwendung einer solchen Eingabeoberfläche Vorteile hinsichtlich der
Benutzerfreundlichkeit und der Vermeidung von Eingabefehlern. Nach Erfassung der Daten
in der Datenbank erfolgt - per definiertem Export-Algorithmus - der Export der Daten in
Textdateien mit PROLOG-Syntax. Somit stehen die Daten anschließend für die Analyse mit
Hilfe des PROLOG-Laufzeitsystems zur Verfügung.
Vorteile dieser Vorgehensweise:
 Je nach Verfügbarkeit der originären Daten lassen sich die Datensätze manuell oder
automatisiert erfassen.
 Die Datenbankstruktur sowie die Datenbankoberfläche unterstützen die Prüfung der

Eingabedaten auf Plausibilität (Format, Wertebereich etc.).
 Die Erzeugung der PROLOG-Klauseln per Datenbankalgorithmus verhindert Fehler

bei manueller Datenerfassung in Textdateien (PROLOG-Datensätze).
Als methodischer Vorteil kann erwähnt werden, dass die Generierung der PROLOG-Syntax
aus Datenbanktabellen erzwingt, dass die Zielsyntax ausschließlich in Abhängigkeit von den
betreffenden Datensatzinhalten abgeleitet wird (SQL-Abfragen). Der generische Charakter
der Datenbankabfragen eliminiert die Möglichkeit, einzelfall-typische Ergänzungen im
Rahmen der Makroprogrammierung.
Hinweise:
1) eine Datenbank-Normalisierung erfolgte nicht
2) die Schlüssel der Datenbanktabellen sind in der nachfolgenden Beschreibung nicht

angegeben
Seite 167 von 262

7.3 Datentechnische Realisierung
Die datentechnische Realisierung der automatisierten Analyseschritte ist in Anhang A2

detailliert beschrieben.
7.4 Ausführen der Anlagenanalyse
Die Migration der Datenhaltung (hier: Anlagendaten, Voraussetzungen für Angriffe) von
Einzeldateien auf eine Datenbank hat Auswirkung auf den Ablauf der Analyse der
Leittechnikanlage. Die tabellarischen Strukturen erleichtern den Aufbau einer
abschließenden Metrik. Aus diesem Grund wurde die PROLOG-basierte Analyse deutlich
vereinfacht. Mit Hilfe des PRLOG-Systems werden lediglich die sogenannten „kritischen
Szenarien“ gesucht. Die darauf aufbauende Metrik kann innerhalb der Datenbank mit den
vorhandenen Anlagen- und Szenario-Daten abgebildet werden (siehe Übersicht des
Programmablaufes in Abbildung 23).
Die „kritischen Szenarien“ ergeben sich aus der Abbildung der systemtechnischen
Voraussetzungen der Angriffsmuster auf die Anlagenbeschreibungen mit den Methoden der
Prädikatelogik. Als Ergebnis liefert die PROLOG-Analyse Datensätze der Form:
<Szenario-ID : Szenario-Bezeichnung : Örtlichkeit Angriff : Zielsystem-Typ : Zielsystem-ID : Ausgangssystem-ID>
Abbildung 24: Kritische Szenario-Daten (Ausschnitt)
Seite 168 von 262

Das Programm führt das „Matching“ der Szenario-Daten auf die Anlagendaten unter
Verwendung von PROLOG-Klauseln aus, die in Abbildung 23 als Funktionsklauseln
bezeichnet werden. Die Bestimmung der kritischen Szenarien, d.h. jener Angriffsszenarien,
die aufgrund der Anlagenstruktur sowie den Gerätekonfigurationen möglich sind, ergibt sich
aus folgender Formel:
scenarioD  scenario  kritischeSzenarienn
Nachfolgend sind beispielhaft die Makro-generierten Klauseln für das Szenario „1.1“
dargestellt:
...
scenarioA(1.1, locAccessDevice, cd, none, none, none, osKnowhow, none,

userName, password).
...
scenario(SC):-
((SC = 1.1), scenarioD(SC, TS, SS, _, A), cdDvd(SS, SSID), systemOperating(SS,

SSID, L), deviceType(SS, SSID, _), writeData(SC, A, TS, SSID, SID, L));
...
Nachfolgend sind die Bestandteile der obigen PROLOG-Klausel kurz skizziert:
Die Klausel „scenarioD()“ enthält die Szenario-Kennung, das Angriffsziel (Systemtyp), den
Ausgangspunkt des Angriffs (Systemtyp), das Schutzziel gegen das sich der Angriff richtet
sowie die Bezeichnung der Angriffsart.
Die Klausel „scenarioA()“ enthält Fakten aus den Voraussetzungen, die der Angreifer zu
erfüllen hat: Equipment, Knowhow und notwendiger physischer Zugang.
Die Klausel „scenario(SC)“ besteht wiederum aus mehreren funktionalen PROLOG-Klauseln.

Die Einbindung von „scenarioD()“ stellt die allgemeinen Szenario-Daten zur Verfügung.
Beispiele:
Die Funktionsklauseln unifizieren Informationen zur Systemtechnik der Zielsysteme:
 cdDvd(SS, SSID)
- Source-Systemtyp, System-ID hat CD / DVD
Seite 169 von 262

 systemOperating(SS, SSID, L)
- Source-Systemtyp, System-ID, Raum ermöglicht lokale Systembedienung
 deviceType(SS, SSID, _)
- System-ID ist vom Typ „Systemtyp“
Die Klausel „writeData(SC, A, TS, SSID, SID, L)” gibt die Daten in eine Datei aus.
Die Häufigkeit der PROLOG-basierten Anlagenanalyse hängt von der Häufigkeit der
Änderungen an den Anlagendaten bzw. Szenario-Beschreibungen ab. Betriebstypisch
dürften diese Analyse sowie die nachfolgenden Schritte in festen Zyklen erfolgen.
7.5 Bildung der Sicherheitsmetrik
Die vorangegangenen Abschnitte beschrieben die Datenstrukturen der Datenbank für die
Erfassung der Anlagen- und Szenario-Daten sowie den Export in PROLOG-Klauseln. Die
nachfolgenden Abschnitte beschreiben nun die Datenstrukturen zum Import der Ergebnisse
der PROLOG-Analyse in die Datenbank und die Bildung der Metrik auf Basis dieser
Ergebnisse.
7.5.1 Import der PROLOG-Ergebnisse
Mit Hilfe von Datenbankfunktion erfolgt der Import der Ergebnisse aus der PROLOG-Analyse
in eine Datenbanktabelle. Manuelle Datenmanipulationen sind nicht erforderlich. Der Import
stellt eine 1:1-Abbildung der PROLOG-Ergebnisse dar (Beispiel siehe Abbildung 25).
Die Häufigkeit des Datenimports hängt von der Häufigkeit der Analysedurchgänge ab. Die
Inhalte der Datenbanktabelle (Abbildung 25) entsprechen den Inhalten, die das PROLOG-
Laufzeitsystem als Suchergebnis liefert (Abbildung 24).
Seite 170 von 262

Abbildung 25: Import der PROLOG-Ergebnisse (Ausschnitt)
7.5.2 Abbildung der Analyseergebnisse auf Teil-Metriken
Die Bildung der Metrik über den Sicherheitsstatus der Leittechnikanlage erfolgt in zwei
Schritten:
Zunächst werden die gefundenen „kritischen Szenarien“ jeweils mit den Datenbanktabellen,
die die Voraussetzungen „Zugang“, „Equipment“ und „Knowhow“ enthalten, verknüpft. Als
Ergebnis erhält man drei Teil-Metriken für die drei Teilbereiche. Im zweiten Schritt werden
diese Teil-Metriken zu einer Gesamt-Metrik zusammengeführt.
Bildung der Teil-Metrik „Equipment“
Auf Basis der über das Attribut „Scenario-ID“ verknüpften Tabellen

„VORAUSSETZUNGEN_EQUIPMENT“ und „PROLOG_KRITSCENARIOS“ wird die Abfrage
(View) „Criteria_Equipment“ gebildet, die für die identifizierten „kritischen Szenarien“ die
Seite 171 von 262

Voraussetzungen hinsichtlich der notwendigen Ausrüstung liefert. Ergänzend zur Abbildung

der Angriffsvoraussetzungen (z.B. CD, USB, Fremdgerät etc.) erfolgt in dieser Abfrage auch
die Bewertung der einzelnen Voraussetzungen gemäß den Abstufungen „General“, „Limited“,
Restricted“ und „Individual“ sowie die Aggregation dieser Einzelbewertungen auf eine
Gesamtbewertung des betreffenden Szenarios (siehe Beispiel in Abbildung 26).
Transformationsschritt Datenstruktur
VORAUSSETZUNGEN_EQUIPMENT(SzenarioID, Szenario, Schutzziel,

Zielsystem, #Cd, #UsbStick, #Fremdgeraet, #Manipulations-Tool, #DoS-
Tabellendefinitionen Tool, #App-spec-Malware)
PROLOG_KRITSCENARIOS (SzenarioID, Szenario, Zielsystem,
ZielsystemID, AusgangssystemID
SELECT DISTINCT PROLOG_kritScenarios.SC,

PROLOG_kritScenarios.Attack,
Voraussetzungen_Equipment.CD,
Voraussetzungen_Equipment.USB-Stick,
Voraussetzungen_Equipment.Fremdgeraet,
Voraussetzungen_Equipment.Manipulations-Tool,
Voraussetzungen_Equipment.DoS-Tool],
Voraussetzungen_Equipment.App-spec-Malware,
SQL-Transformation IIf(CD="x" OR USB-Stick="x" Or CD="x" OR USB-Stick="x" OR
Fremdgeraet="x",1,0) AS General,
IIf(DoS-Tool="x",1,0) AS Limited,
IIf(Manipulations-Tool="x",1,0) AS Restricted,
IIf(App-spec-Malware="x",1,0) AS Individual,
General*1+Limited*2+Restricted*4+Individual*8 AS Level
FROM PROLOG_kritScenarios INNER JOIN
Voraussetzungen_Equipment ON PROLOG_kritScenarios.SC =
Voraussetzungen_Equipment.Szenario-ID;
CRITERIA_Equipment(SzenarioID, Szenario, #Cd, #UsbStick,

View-Definition #Fremdgeraet, #Manipulations-Tool, #DoS-Tool, #App-spec-Malware,
#General, #Limited, #Restricted, #Individual, #Level)
Auf Basis dieser Datenbankverknüpfung erhält man die Angriffsvoraussetzungen hinsichtlich

der erforderlichen Ausrüstung („Equipment“) wie beispielhaft in Abbildung 26 gezeigt.
Seite 172 von 262

Abbildung 26: Criteria_Equipment (Ausschnitt)
Bildung der Teil-Metrik „Knowhow“
Die Bildung der Teil-Metrik „Knowhow“ erfolgt in gleicher Weise wie die Teil-Metrik
„Equipment“. Die Bewertungsklassen hinsichtlich Knowhow sind „General“, „Specific“,
„Sensitiv“ und „Individual“ (siehe Beispiel in Abbildung 27).
VORAUSSETZUNGEN_KNOWHOW(SzenarioID, Szenario, Schutzziel,

Zielsystem, #Besy-Knowhow, #App-Knowhow, #System-Knowhow,
Tabellendefinitionen Username, Password)

Voraussetzungen_Knowhow.Besy-Knowhow,
Voraussetzungen_Knowhow.System-Knowhow,
Voraussetzungen_Knowhow.App-Knowhow,
Voraussetzungen_Knowhow.Username,
SQL-Transformation Voraussetzungen_Knowhow.Passwort,
IIf([Besy-Knowhow]="x",1,0) AS [General],
IIf([System-Knowhow]="x" OR [App-Knowhow]="x",1,0) AS Specific,
IIf([Username]="x",1,0) AS Sensitive, IIf([Passwort]="x",1,0) AS Critical,
[General]*1+[Specific]*2+[Sensitive]*4+[Critical]*8 AS [Level]
FROM PROLOG_kritScenarios INNER JOIN Voraussetzungen_Knowhow
ON [PROLOG_kritScenarios].SC=Voraussetzungen_Knowhow.[Szenario-
ID];
CRITERIA_Knowhow(SzenarioID, Szenario, #System-Knowhow, #App-
View-Definition Knowhow, #Username, #Password, #General, #Specific, #Sensitive,
#Critical, #Level)
Seite 173 von 262


der erforderlichen Zugangsmöglichkeiten („Location“) wie beispielhaft in Abbildung 27
gezeigt.
Abbildung 27: Criteria_Knowhow (Ausschnitt)
Bildung der Teil-Metrik „Zugang“
Die Bildung der Teil-Metrik „Zugang“ erfolgt ebenfalls in der beschriebenen Weise. Die
Bewertungsklassen hinsichtlich Zugänglichkeit sind „Area“, „Building“, „Room“ und „Device“
(Beispiel siehe Abbildung 28).
Seite 174 von 262

VORAUSSETZUNGEN_SYSTECH(SzenarioID, Szenario, Schutzziel,

Zielsystem, #Cd, #Usb, #OpenSwitchPort, #LocProgSS, #Netzverbindung,
#ASPunkt_Zielsystem, #ASPunkt_Fremdsystem, #ASPunkt_AnyClient,
Tabellendefinitionen #Systembenutzung)

PROLOG_kritScenarios.Location,
Voraussetzungen_SysTech.Systembenutzung,
Voraussetzungen_SysTech.CD,
Voraussetzungen_SysTech.USB,
Voraussetzungen_SysTech.locProgSS,
Voraussetzungen_SysTech.openSwitchPort,
IIf([Location]="engineeringRaum",1, IIf(Location="hauptLTRaum",1,
SQL-Transformation IIf(Location="LTRaum1",1,IIf(Location="LTRaum2",1,0)))) AS Area,
IIf(Location="engineeringRaum",1, IIf(Location="hauptLTRaum",1,
IIf(Location="LTRaum1",1,IIf(Location="LTRaum2",1,0)))) AS Building,
IIf(Location="engineeringRaum",1, IIf(Location="hauptLTRaum",1,
IIf(Location="LTRaum1",1,IIf(Location="LTRaum2",1,0)))) AS Room,
IIf(CD="x" OR USB="x" OR locProgSS="x" OR locProgSS="x" OR
openSwitchPort="x", 1,0) AS Device,
Area*1+Building*2+Room*4+Device*8 AS Level
FROM PROLOG_kritScenarios INNER JOIN Voraussetzungen_SysTech
ON PROLOG_kritScenarios.SC = Voraussetzungen_SysTech.Szenario-
ID;
CRITERIA_Location(SzenarioID, Szenario, Location, #Systembenutzung,
View-Definition #Cd, #Usb, #LocProgSS , #OpenSwitchPort , #Area, #Building, #Room,
#Device, #Level)

der erforderlichen Kompetenzen („Knowhow“) wie beispielhaft in Abbildung 28 gezeigt.
Seite 175 von 262

Abbildung 28: Criteria_Location (Ausschnitt)
7.5.3 Übersicht Anlagen-Metrik
Nachdem im vorangegangenen Abschnitt die Bildung der drei Teil-Metriken beschrieben

wurde, folgt nun die Bildung der Gesamtmetrik für die Anlage (siehe Abbildung 29).
Die Gesamtmetrik führt per Abfrage (View) für jedes Angriffsszenario die Bewertungen
hinsichtlich „Knowhow“, „Equipment“ und „Zugänglichkeit“ zusammen.
CRITERIA_Knowhow(SzenarioID, Szenario, #System-Knowhow, #App-

Knowhow, #Username, #Password, #General, #Specific, #Sensitive,
#Critical, #Level)
CRITERIA_Equipment(SzenarioID, Szenario, #Cd, #UsbStick,
Tabellendefinitionen #Fremdgeraet, #Manipulations-Tool, #DoS-Tool, #App-spec-Malware,
#General, #Limited, #Restricted, #Individual, #Level)
CRITERIA_Location(SzenarioID, Szenario, Location, #Systembenutzung,
#Cd, #Usb, #LocProgSS , #OpenSwitchPort , #Area, #Building, #Room,
#Device, #Level)
Seite 176 von 262

SELECT DISTINCT Criteria_Equipment.SC,

Criteria_Location.Attack,
Criteria_Location.Location,
Criteria_Location.Level AS Level Location,
Criteria_Equipment.Level AS Level Equipment,
SQL-Transformation Criteria_Knowhow.Level AS Level Knowhow
FROM (Criteria_Equipment INNER JOIN Criteria_Knowhow ON
Criteria_Equipment.SC = Criteria_Knowhow.SC) INNER JOIN
Criteria_Location ON (Criteria_Knowhow.Attack = Criteria_Location.Attack)
AND (Criteria_Knowhow.SC = Criteria_Location.SC);
Overview_Metric(ScenarioID, Scenario,Location, LevelLocation,

View-Definition LevelEqipment, LevelKnowhow)
Die Datenbank liefert die Metrik-Daten über den View „Overview_Metric“ (siehe Abbildung
29). Die resultierende Sicherheitsmetrik wird im nachfolgenden Kapitel anhand eines
Beispiels dargestellt.
Seite 177 von 262

Abbildung 29: Metrik-Daten mittels DB-View "Overview_Metric" (Ausschnitt)
Seite 178 von 262

Kapitel 8 Anwendung der Analysemethodik auf ein Praxisbeispiel
8 Anwendung der Analysemethodik auf ein Praxisbeispiel

Die vorangegangen Kapitel beschrieben eine neu konzipierte Analysemethodik für
leittechnische Systeme. Die Methode umfasst die systematische Herleitung realisierbarer
Angriffsszenarien gegen die betrachtete Leittechnikanlage sowie die Beurteilung der IT-
Sicherheit dieser Anlage anhand einer Metrik, die ausschließlich auf zielsystemspezifischen
Fakten beruht.
Dieses abschließende Kapitel soll die Analysemethode einer Erprobung im Rahmen einer
Beispielanlage unterziehen. Der Beurteilung der Methode liegen folgende Ansätze
zugrunde:
 Vergleich mit einer etablierten Methode
 Erprobung anhand eines praxisgerechten Beispiels einer Zielanlage
8.1 Schematische Darstellung einer Beispielanlage
Für die Gegenüberstellung der in dieser Arbeit vorgeschlagenen Analysemethodik und einer
etablierten Methode soll eine praxisgerechte Beispielanlage einer Leittechnikanlage
zugrunde gelegt werden. Diese beispielhafte Zielanlage dient sowohl der
Methodenerprobung als auch dem Ergebnisvergleich beider Methoden.
Zum Zwecke der Anonymisierung der realen Anlage wurde die Anzahl der jeweiligen
Leittechnikkomponenten verändert. Die Leittechnikkomponententypen der Zielanlage blieben
erhalten. Abbildung 30 skizziert die räumliche Verteilung der Leittechnikkomponenten über
die wesentlichen Örtlichkeiten der Anlage.
Im Hauptleittechnikraum sind die HMI-Serversysteme, das Prozessdatenarchiv sowie die

Automatisierungssysteme installiert. Des Weiteren ist ein temporär genutztes DSL-Modem
vorhanden. Neben den fest installierten HMI-Clients sind für die Dauer der Inbetriebnahme
zusätzliche (temporäre) HMI-Clients verfügbar. Der Hauptleittechnikraum ist nicht permanent
mit Personal besetzt.
Im Leittechniknebenraum befindet sich ein HMI-Client für Engineering- und

Datensicherungszwecke. Dieser Raum ist nicht permanent mit Personal besetzt.
Im Hauptleitstand sind ausschließlich HMI-Clients zur Anlagenbedienung installiert. Der

Hauptleitstand ist permanent mit Schichtpersonal besetzt.
Seite 179 von 262

In den Leittechnikräumen für den E-Filter sowie die Bekohlung sind HMI-Clients zur Vor-Ort-
Bedienung der Anlage als auch Automatisierungssysteme untergebracht. Diese
Leittechnikräume sind nicht permanent mit Personal besetzt.
Abbildung 30: Anlagentopologie (phys.)
In den Leittechnikräumen für den Flugaschen-Silo sowie die Schiffsentladung stehen nur
HMI-Clients zur Bedienung der Anlage zur Verfügung. Diese Räume sind nicht permanent
mit Personal besetzt.
Im Leittechnikraum der Nebensysteme sind nur Automatisierungssysteme installiert. Eine

Vor-Ort-Bedienung ist nicht vorgesehen. Dieser Raum ist nicht permanent mit Personal
besetzt.
Hinweis: auf die Berücksichtigung der Drucker wurde verzichtet.
Abbildung 31 zeigt die logische Sicht auf die Zielanlage.
Seite 180 von 262

Abbildung 31: Anlagentopologie (log.)
8.2 Anwendung von Analysemethoden auf die Beispielanlage
Nachdem das vorangegangene Kapitel (8.1) eine typische Beispielanlage skizzierte, soll
dieses Kapitel die Anwendung verschiedener Analysemethoden auf diese Beispielanlage
beschreiben. Als erster Schritt ist die Auswahl eines geeigneten Standards hinsichtlich der
Beurteilung der IT-Sicherheit von Leittechnikanlagen zu treffen (8.2.1). Anschließend erfolgt
die Analyse der Beispielanlage auf Basis des ausgewählten Standards (8.2.2). Um einen
Methodenvergleich zu ermöglichen, wird danach die Beispielanlage mit der neu
vorgeschlagenen, faktenbasierten Analysemethode einer Beurteilung unterzogen. Im
abschließenden Schritt (8.3) folgt der Ergebnis- und Methodenvergleich.
Seite 181 von 262

8.2.1 Anlagenvalidierung gemäß etabliertem Standard
Auswahl eines Regelwerkes als Analysemethode
Für die Beurteilung der IT-Sicherheit wird - mangels geeigneter IT-Sicherheitskriterien - in

der Regel eine Risikoanalyse hinsichtlich möglicher Cyber-Angriffe und potentieller Schäden
vorgenommen (siehe Kapitel 3.3).
Als mögliche Referenz zur Beurteilung der Sicherheit kommen mehrere SCADA-relevante
Standards in Betracht:
 NERC CIP
 NIST SP 800-30
 NIST SP 800-55
 VGB R175
 ISO 27000
Als Grundlage für die weitere vergleichende Betrachtung wird
„NIST SP800-30 Guide for Conducting Risk Assessments“
(NIST-SP800-30, 2012) ausgewählt, da dieser Standard sowohl in Europa als auch in den
USA als Grundlage für die Risikoanalyse auch für leittechnische Anlagen dient und im
Gegensatz zu den anderen Standards auf klassifizierbare Ergebnisse abzielt.
Auswahl der Methode
(NIST-SP800-30, 2012) stellt folgende Methodenansätze zur Analyse der Zielanlagen zur
Auswahl:
Analysis approaches differ with respect to the orientation or starting point of the risk
assessment, level of detail in the assessment, and how risks due to similar threat
scenarios are treated. An analysis approach can be:
1) threat-oriented
2) asset/impact-oriented or
3) vulnerability-oriented
Seite 182 von 262

Da im Rahmen der vorliegenden Arbeit die Beurteilung der IT-Sicherheit des SCADA-
Systems im Mittelpunkt steht, basiert die weitere Betrachtung auf der bedrohungsorientierten
Analyseansatz. Die weitere Betrachtung des Analyseprozesses gemäß (NIST-SP800-30,
2012) folgt dem Prozess wie in Abbildung 32 dargestellt.
Aufgrund des Ziels, eine standardisierte Methode zur Risikobeurteilung von SCADA-
Systemen mit der vom Verfasser vorgeschlagenen Methode zu vergleichen, beschränkt sich
die weitere Betrachtung auf die beiden Analyseschritte
 Schritt 1: „Prepare for Assessment“ und

 Schritt 2: „Conduct Assessment“.
Abbildung 32: Risikoanalyseprozess gemäß NIST SP800-30 (Quelle: NIST)
Die unternehmensspezifischen Prozessschritte 3 („Communicate Results“) und 4 („Maintain

Assessment“) sind für den angestrebten Methodenvergleich unerheblich, da in gleicher
Weise auf die Ergebnisse beider Ansätze anwendbar.
Für den weiteren Analyseprozess leiten sich daraus die nachfolgend beschriebenen
Prozessschritte ab.
Seite 183 von 262

Schritt 1: Vorbereitung der Analyse
(NIST-SP800-30, 2012) listet in Kapitel 3.1 folgende Vorbereitungsaufgaben auf:
 Task 1-1: Identify purpose

 Task 1-2: Identify scope
 Task 1-3: Identify assumptions and constraints
 Task 1-4: Identify information sources
 Task 1-5: Identify risk model and analytical approach
Für den angestrebten Methodenvergleich sollen nachfolgend die Aufgaben der einzelnen
Prozessschritte dargestellt werden.
Task 1-1
Identify the purpose of the risk assessment in terms of the information that the
assessment is intended to produce and the decisions the assessment is intended to
support.
Es ist das Ziel der Analyse auf Basis (NIST-SP800-30, 2012), verifizierbare Aussagen zum
Status der IT-Sicherheit der SCADA-Zielanlage zu erhalten.
Die Analyseergebnisse sollen Unternehmensentscheidungen im Bereich Investition, Betrieb

und Systemwartung unterstützen, die die Sicherheit der Zielanlage gegen Cyber-Angriffe
verbessern.
Task 1-2
Identify the scope of the risk assessment in terms of organizational applicability, time
frame supported and architectural/technology considerations.
Als Analyseobjekt wird die SCADA-Zielanlage betrachtet. Diese umfasst die

Automatisierungssysteme, die HMI- und Engineering-Systeme, die zugehörigen
Netzwerkkomponenten sowie die unmittelbaren Räumlichkeiten, in denen die SCADA-
Komponenten untergebracht sind. Systeme, Komponenten sowie Räume, die nicht zum
typischen Lieferumfang bzw. Örtlichkeit eines Leitsystems gehören, bleiben von der
Betrachtung ausgeschlossen. Desgleichen bleiben organisatorische Fragen des Betreibers
oder terminliche / zeitliche Aspekte der Analyse unberücksichtigt, da diese keine
Systemeigenschaft darstellen.
Seite 184 von 262

Task 1-3
Identify the specific assumptions and constraints under which the risk assessment is
conducted.
Die Analyse im Rahmen des Methodenvergleichs stützt sich auf folgende Annahmen:
 Threat Sources
Für die Analyse kommen folgende Angreifertypen in Betracht:
 Betriebsfremde Angreifer, die sich Zugang zum Gelände verschaffen

 Betriebsfremde Angreifer, die in der Lage sind, Schadsoftware in die Zielanlage
einzuschleusen
 Interne Angreifer, die formal keinen Zugang zum Leitsystem haben
Da ein SCADA-System keine hinreichende technischen Möglichkeiten hat, zwischen
vertrauenswürdigen Personen mit Angriffsabsichten und vertrauenswürdigen Personen ohne
Angriffsabsichten zu unterscheiden, werden vertrauenswürdige Personen (z.B. SCADA-
Systemadministrator, Leittechnikpersonal etc.) von der weiteren Betrachtung
ausgeschlossen. Desgleichen bleiben unbeabsichtigte Fehlbedienungen des Personals
unberücksichtigt, da solche Fehler nicht als vorsätzliche Angriffe aufgefasst werden.
Anmerkung zu „autorisierten bzw. nicht autorisierten Anwendern (= Angreifer):
Vereinzelte Regelwerke, aber vor allem Ausschreibungen von Betreibern leittechnischer Anlagen erheben die
Forderung, dass Leitsysteme gegen den Zugriff nicht autorisierter Anwender geschützt sein müssen. Diese
Forderung beinhaltet sogar die missbräuchliche Verwendung von Benutzername und Passwort oder ID-Karte
berechtigter Anwender. Offensichtlich wird dabei nicht bedacht, dass ein Rechnersystem einen Anwender nur
anhand der vorgegebenen Identifikationsmerkmale („Credentials“), z.B. Benutzername / Passwort, identifizieren
und autorisieren kann. Bei missbräuchlicher Verwendung dieser Merkmale gilt ein Angreifer automatisch als
autorisierter Anwender. Da bei modernen Betriebssystemen alle Prozesse im Kontext eines System- oder
Benutzerkontos laufen, bewegt sich ein Angreifer nach erfolgreicher Anmeldung immer im Kontext eines
autorisierten Benutzers.
Threat Events
Folgende Angriffstypen aus (NIST-SP800-30, 2012) werden für die Analyse übernommen:
Anmerkung: Vor dem Hintergrund, dass die vorliegende Betrachtung die IT-Sicherheit der
SCADA-Systeme zum Ziel hat, werden Angriffe, die für nicht-computerbasierte Systeme in
gleicher Weise möglich sind (z.B. physische Zerstörungen, Unterbrechung von
Kabelverbindungen, Beeinflussung der Stromversorgung der Systeme etc.) nicht
berücksichtigt. Im Mittelpunkt der Betrachtung stehen Risiken, die durch Nutzung software-
Seite 185 von 262

basierter Systeme hinzukommen. Die nachfolgenden Tabellen aus dem zugrunde gelegten
Standard beschreiben die möglichen Bedrohungsszenarien. Durchgestrichen wurden jene
Szenarien, die aus Sicht des Verfassers für die betrachtete Zielanlage nicht relevant sind.
Perform reconnaissance and gather information
Threat Events Description
Perform perimeter network Adversary uses commercial or free software to scan

reconnaissance / scanning. organizational perimeters to obtain a better understanding
of the information technology infrastructure and improve
the ability to launch successful attacks.
Perform network sniffing of exposed Adversary with access to exposed wired or wireless data
networks. channels used to transmit information uses network
sniffing to identify components, resources, and
protections.
Gather information using open source Anmerkung des Verfassers:

discovery of organizational information.
Die Beschaffung und Analyse öffentlich bekannter
Informationen durch Angreifer liegen außerhalb der
Beurteilungsmöglichkeiten der Leittechnikverantwortlichen
Perform reconnaissance and Adversary uses various means (e.g., scanning, physical
surveillance of targeted organizations. observation) over time to examine and assess
organizations and ascertain points of vulnerability.
Perform malware-directed internal Adversary uses malware installed inside the organizational
reconnaissance. perimeter to identify targets of opportunity. Because the
scanning, probing, or observation does not cross the
perimeter, it is not detected by externally placed intrusion
detection systems.
Craft or create attack tools
Craft phishing attacks.

Anmerkung des Verfassers:
Adversary counterfeits communications
from a legitimate/trustworthy source to Die Vorbereitungsmaßnahmen für Cyber-Angriffe gegen
acquire sensitive information such as SCADA-Systeme liegen außerhalb der Einflussbereiche
usernames, passwords, or SSNs. sowie der Beurteilungsmöglichkeiten der
Typical attacks occur via email, instant Leitsystemverantwortlichen und bleiben deshalb
messaging, or comparable means; unberücksichtigt.
commonly directing users to websites
that appear to be legitimate sites, while
actually stealing the entered
information.
Craft spear phishing attacks.
Seite 186 von 262

Adversary employs phishing attacks

targeted at high value targets (e.g.,
senior leaders/executives).
Craft attacks specifically based on

deployed information technology
environment.
Adversary develops attacks (e.g., crafts

targeted malware) that take advantage
of adversary knowledge of the
organizational information technology
environment.
Deliver/insert/install malicious capabilities
Deliver known malware to internal

organizational information systems
(e.g., virus via email).
Deliver modified malware to internal Angriffe gegen „organizational information systems“ liegen
organizational information systems. außerhalb der Analyse von SCADA-Systemen.
Deliver targeted malware for control of

internal systems and exfiltration of data.
Deliver malware by providing removable Adversary places removable media (e.g., flash drives)
media. containing malware in locations external to organizational
physical perimeters but where employees are likely to find
the media (e.g., facilities parking lots, exhibits at
conferences attended by employees) and use it on
organizational information systems.
Insert untargeted malware into Anmerkung des Verfassers:

downloadable software and/or into
Die Manipulation und Bereitstellung von Open Source-
commercial information technology
Software liegt außerhalb des SCADA-
products.
Betrachtungsraumes
Insert targeted malware into Anmerkung des Verfassers:

organizational information systems and
Die Infektion von „organizational information systems and
information system components.
information system components“ liegt außerhalb des
SCADA-Verantwortungsbereiches.
Insert specialized malware into Anmerkung des Verfassers:

organizational information systems
Die Infektion von „organizational information“ liegt
based on system configurations.
außerhalb des SCADA-Verantwortungsbereiches.
Insert counterfeit or tampered hardware Adversary intercepts hardware from legitimate suppliers.
into the supply chain. Adversary modifies the hardware or replaces it with faulty
or otherwise modified hardware.
Seite 187 von 262

Insert tampered critical components into

organizational systems.
Install general-purpose sniffers on Anmerkung des Verfassers:

organization-controlled information Die Betrachtung von Angriffsrisiken von „organizational
systems or networks. information“ liegt außerhalb des SCADA-
Verantwortungsbereiches.
Install persistent and targeted sniffers
on organizational information systems
and networks.
Insert malicious scanning devices (e.g., Adversary uses postal service or other commercial
wireless sniffers) inside facilities. delivery services to deliver to organizational mailrooms a
device that is able to scan wireless communications
accessible from within the mailrooms and then wirelessly
transmit information back to adversary.
Insert subverted individuals into Anmerkung des Verfassers:

organizations.
Manipulationen / Angriffe gegen das Personal bleiben
unberücksichtigt, da keine SCADA-Eigenschaft.
Insert subverted individuals into
privileged positions in organizations.
Exploit and compromise
Exploit physical access of authorized Adversary follows (“tailgates”) authorized individuals into
staff to gain access to organizational secure/controlled locations with the goal of gaining access
facilities. to facilities, circumventing physical security checks.
Exploit poorly configured or Adversary gains access through the Internet to information
unauthorized information systems systems that are not authorized for Internet connectivity or
exposed to the Internet. that do not meet organizational configuration
requirements.
Exploit split tunneling. Adversary takes advantage of external organizational or

personal information systems (e.g., laptop computers at
remote locations) that are simultaneously connected
securely to organizational information systems or networks
and to non secure remote connections.
Exploit multi-tenancy in a cloud Anmerkung des Verfassers:

environment.
Cloud-Anwendungen werden nicht als Bestandteil von
SCADA-Systemen betrachtet.
Exploit known vulnerabilities in mobile Adversary takes advantage of fact that transportable
systems (e.g., laptops, PDAs, smart information systems are outside physical protection of
phones). organizations and logical protection of corporate firewalls,
and compromises the systems based on known
vulnerabilities to gather information from those systems.
Exploit recently discovered Adversary exploits recently discovered vulnerabilities in

organizational information systems in an attempt to
Seite 188 von 262

vulnerabilities. compromise the systems before mitigation measures are

available or in place.
Exploit vulnerabilities on internal Anmerkung des Verfassers:

organizational information systems.
Die Betrachtung von Angriffsrisiken von „organizational
information“ liegt außerhalb des SCADA-
Verantwortungsbereiches.
Exploit vulnerabilities using zero-day Adversary employs attacks that exploit as yet unpublicized
attacks. vulnerabilities. Zero-day attacks are based on adversary
insight into the information systems and applications used
by organizations as well as adversary reconnaissance of
organizations.
Exploit vulnerabilities in information Adversary launches attacks on organizations in a time and

systems timed with organizational manner consistent with organizational needs to conduct
mission/business operations tempo. mission/business operations.
Exploit insecure or incomplete data Adversary obtains unauthorized information due to

deletion in multi-tenant environment. insecure or incomplete data deletion in a multi-tenant
environment (e.g., in a cloud computing environment).
Violate isolation in multi-tenant Adversary circumvents or defeats isolation mechanisms in

environment. a multi-tenant environment (e.g., in a cloud computing
environment) to observe, corrupt, or deny service to
hosted services and information/data.
Compromise critical information Adversary obtains physical access to organizational

systems via physical access. information systems and makes modifications.
Compromise information systems or Adversary installs malware on information systems or

devices used externally and devices while the systems/devices are external to
reintroduced into the enterprise. organizations for purposes of subsequently infecting
organizations when reconnected.
Compromise software of organizational Anmerkung des Verfassers:

critical information systems.
Die Betrachtung von Angriffsrisiken von „organizational
information“ liegt außerhalb des SCADA-
Compromise organizational information Verantwortungsbereiches.
systems to facilitate exfiltration of
data/information.
Compromise mission-critical Adversary compromises the integrity of mission-critical

information. information, thus preventing or impeding ability of
organizations to which information is supplied, from
carrying out operations.
Compromise design, manufacture, Adversary compromises the design, manufacture, and/or

and/or distribution of information system distribution of critical information system components at
components (including hardware, selected suppliers.
software, and firmware).
Seite 189 von 262

Conduct an attack (i.e., direct/coordinate attack tools or activities)
Conduct communications interception Adversary takes advantage of communications that are

attacks. either unencrypted or use weak encryption (e.g.,
encryption containing publically known flaws), targets
those communications and gains access to transmitted
information and channels.
Conduct wireless jamming attacks. Adversary takes measures to interfere with wireless
communications so as to impede or prevent
communications from reaching intended recipients.
Conduct attacks using unauthorized Adversary conducts attacks using ports, protocols, and
ports, protocols and services. services for ingress and egress that are not authorized for
use by organizations.
Conduct attacks leveraging traffic/data Adversary makes use of permitted information flows (e.g.,
movement allowed across perimeter. email communication, removable storage) to compromise
internal information systems, which allows adversary to
obtain and exfiltrate sensitive information through
perimeters.
Conduct simple Denial of Service (DoS) Adversary attempts to make an Internet-accessible

attack. resource unavailable to intended users, or prevent the
resource from functioning efficiently or at all, temporarily or
indefinitely.
Conduct Distributed Denial of Service Adversary uses multiple compromised information

(DDoS) attacks. systems to attack a single target, thereby causing denial of
service for users of the targeted information systems.
Conduct targeted Denial of Service Adversary targets DoS attacks to critical information
(DoS) attacks. systems, components, or supporting infrastructures, based
on adversary knowledge of dependencies.
Conduct physical attacks on

organizational facilities.
Conduct physical attacks on Anmerkung des Verfassers:

infrastructures supporting organizational
facilities. Diese Angriffsvariante ist nicht security-relevant
Conduct cyber-physical attacks on

organizational facilities.
Conduct data scavenging attacks in a Adversary obtains data used and then deleted by
cloud environment. organizational processes running in a cloud environment.
Conduct brute force login Adversary attempts to gain access to organizational

attempts/password guessing attacks. information systems by random or systematic guessing of
passwords, possibly supported by password cracking
utilities.
Conduct non-targeted zero-day attacks. Adversary employs attacks that exploit as yet unpublicized
vulnerabilities. Attacks are not based on any adversary
Seite 190 von 262

insights into specific vulnerabilities of organizations.
Conduct externally-based session Adversary takes control of (hijacks) already established,

hijacking. legitimate information system sessions between
organizations and external entities (e.g., users connecting
from off-site locations).
Conduct internally-based session Adversary places an entity within organizations in order to

hijacking. gain access to organizational information systems or
networks for the express purpose of taking control
(hijacking) an already established, legitimate session
either between organizations and external entities (e.g.,
users connecting from remote locations) or between two
locations within internal networks.
Conduct externally-based network traffic Adversary, operating outside organizational systems,

modification (man in the middle) intercepts/eavesdrops on sessions between organizational
attacks. and external systems. Adversary then relays messages
between organizational and external systems, making
them believe that they are talking directly to each other
over a private connection, when in fact the entire
communication is controlled by the adversary. Such
attacks are of particular concern for organizational use of
community, hybrid, and public clouds.
Conduct internally-based network traffic Adversary operating within the organizational

modification (man in the middle) infrastructure intercepts and corrupts data sessions.
attacks.
Conduct outsider-based social

engineering to obtain information. Anmerkung des Verfassers:
Conduct insider-based social Diese Angriffsvariante ist nicht security-relevant

engineering to obtain information.
Conduct attacks targeting and Adversary targets key organizational employees by

compromising personal devices of placing malware on their personally owned information
critical employees. systems and devices (e.g., laptop/notebook computers,
personal digital assistants, smart phones). The intent is to
take advantage of any instances where employees use
personal information systems or devices to handle
critical/sensitive information.
Conduct supply chain attacks targeting Adversary targets and compromises the operation of
and exploiting critical hardware, software (e.g., through malware injections), firmware, and
software, or firmware. hardware that performs critical functions for organizations.
This is largely accomplished as supply chain attacks on
both commercial off-the-shelf and custom information
systems and components.
Seite 191 von 262

Achieve results (i.e., cause adverse impacts, obtain information)
Obtain sensitive information through Adversary with access to exposed wired or wireless data
network sniffing of external networks. channels that organizations (or organizational personnel)
use to transmit information (e.g., kiosks, public wireless
networks) intercepts communications.
Obtain sensitive information via Adversary directs malware on organizational systems to

exfiltration. locate and surreptitiously transmit sensitive information.
Cause degradation or denial of attacker- Adversary directs malware on organizational systems to

selected services or capabilities. impair the correct and timely support of organizational
mission/business functions.
Im Kontext der vorliegenden Arbeit wird diese Bedrohung
auf Leittechnik im Sinne von “Business function”
interpretiert.
Cause deterioration/destruction of
critical information system components
and functions.
Cause integrity loss by creating, Diese Angriffsvariante ist nicht security-relevant
deleting, and/or modifying data on
publicly accessible information systems
(e.g., web defacement).
Cause integrity loss by polluting or Adversary implants corrupted and incorrect data in critical
corrupting critical data. data, resulting in suboptimal actions or loss of confidence
in organizational data/services.
Im Kontext der vorliegenden Arbeit wird diese Bedrohung
auf Leittechnik im Sinne von “Manipulation
betriebswichtiger Engineering-Daten“ (= „Corrupting
critical data”) interpretiert.
Cause integrity loss by injecting false Adversary injects false but believable data into
but believable data into organizational organizational information systems, resulting in suboptimal
information systems. actions or loss of confidence in organizational
data/services.
Cause disclosure of critical and/or Anmerkung des Verfassers:

sensitive information by authorized
users. Diese Angriffsvariante ist nicht security-relevant
Cause unauthorized disclosure and/or Adversary contaminates organizational information

unavailability by spilling sensitive systems (including devices and networks) by causing
information. them to handle information of a classification/sensitivity for
which they have not been authorized. The information is
exposed to individuals who are not authorized access to
such information, and the information system, device, or
network is unavailable while the spill is investigated and
mitigated.
Seite 192 von 262

Obtain information by externally located Adversary intercepts organizational communications over

interception of wireless network traffic. wireless networks. Examples include targeting public
wireless access or hotel networking connections, and
drive-by subversion of home or organizational wireless
routers.
Obtain unauthorized access. Adversary with authorized access to organizational

information systems, gains access to resources that
exceeds authorization.
Obtain sensitive data/information from Anmerkung des Verfassers:

publicly accessible information systems.
Diese Angriffsvariante ist nicht security-relevant
Obtain information by opportunistically Adversary steals information systems or components (e.

stealing or scavenging information g., laptop computers or data storage media) that are left
systems/components. unattended outside of the physical perimeters of
organizations, or scavenges discarded components.
Maintain a presence or set of capabilities
Obfuscate adversary actions.

Adversary takes actions to inhibit the Die Bedrohungsereignisse bleiben unberücksichtigt, da sie
effectiveness of the intrusion detection keine direkte Interaktion mit den SCADA-Systemen
systems or auditing capabilities within beschreiben.
organizations.
Seite 193 von 262

Coordinate a campaign
Coordinate a campaign of multi-staged

attacks (e.g., hopping).
Coordinate a campaign that combines

internal and external attacks across
multiple information systems and
information technologies.
Coordinate campaigns across multiple

organizations to acquire specific Anmerkung des Verfassers:
information or achieve desired outcome.
Die Bedrohungsereignisse bleiben unberücksichtigt, da sie
Coordinate a campaign that spreads keine direkte Interaktion mit den SCADA-Systemen
attacks across organizational systems beschreiben.
from existing presence.
Coordinate a campaign of continuous,

adaptive, and changing cyber-attacks
based on detailed surveillance.
Coordinate cyber-attacks using external

(outsider), internal (insider), and supply
chain (supplier) attack vectors.
Die oben aufgeführten „Threat Events“ für physische oder logische Angriffe lassen sich
anhand der von den Angreifern angewandten Taktiken, Techniken und Methoden (Tactics,
techniques, and procedures, TTPs) klassifizieren. Der Relevanz von Bedrohungsereignissen
werden folgende Werte zugeordnet:
Value Description
Confirmed The threat event or TTP has been seen by the organization.
Expected The threat event or TTP has been seen by the organization’s peers or partners.
Anticipated The threat event or TTP has been reported by a trusted source.
Predicted The threat event or TTP has been predicted by a trusted source.
Possible The threat event or TTP has been described by a somewhat credible source.
The threat event or TTP is not currently applicable. For example, a threat event or
TTP could assume specific technologies, architectures, or processes that are not
present in the organization, mission/business process, EA segment, or information
N/A system; or predisposing conditions that are not present (e.g., location in a flood plain).
Alternately, if the organization is using detailed or specific threat information, a threat
event or TTP could be deemed inapplicable because information indicates that no
adversary is expected to initiate the threat event or use the TTP.
Seite 194 von 262

Der Ausnutzbarkeit von Schwachstellen werden folgende numerischen Werte zugeordnet:
Qualitative Semi-Quantitative
Description
Values Values
The vulnerability is exposed and exploitable, and its exploitation

could result in severe impacts.
Very High 96-100 10 Relevant security control or other remediation is not implemented
and not planned; or no security measure can be identified to
remediate the vulnerability.
The vulnerability is of high concern, based on the exposure of the

vulnerability and ease of exploitation and/or on the severity of
impacts that could result from its exploitation.
High 80-95 8
Relevant security control or other remediation is planned but not
implemented; compensating controls are in place and at least
minimally effective.
The vulnerability is of moderate concern, based on the exposure

of the vulnerability and ease of exploitation and/or on the severity
Moderate 21-79 5 of impacts that could result from its exploitation.
Relevant security control or other remediation is partially
implemented and somewhat effective.
The vulnerability is of minor concern, but effectiveness of

remediation could be improved.
Low 5-20 2
Relevant security control or other remediation is fully
implemented and somewhat effective.
The vulnerability is not of concern.

Very Low 0-4 0 Relevant security control or other remediation is fully
implemented, assessed, and effective.
Der Reichweite bzw. Durchdringung der Vorbedingungen werden folgende Werte

zugeordnet:
Seite 195 von 262

Description
Values Values
Applies to all organizational missions/business functions (Tier 1),
Very High 96-100 10 mission/business processes (Tier 2), or information systems (Tier
3).
Applies to most organizational missions/business functions (Tier
High 80-95 8 1), mission/business processes (Tier 2), or information systems
(Tier 3).
Applies to many organizational missions/business functions (Tier
Moderate 21-79 5 1), mission/business processes (Tier 2), or information systems
(Tier 3).
Applies to some organizational missions/business functions (Tier
Low 5-20 2 1), mission/business processes (Tier 2), or information systems
(Tier 3).
Applies to few organizational missions/business functions (Tier
Very Low 0-4 0 1), mission/business processes (Tier 2), or information systems
(Tier 3).
Die Beurteilung der Eintrittswahrscheinlichkeit eines Cyber-Angriffs soll nach (NIST-SP800-

30, 2012) in einem vierstufigen Prozess abgeschätzt werden. Der Standard listet folgende
Beurteilungskriterien für
- Angriffsversuch
- Angriffsausführung und
- Schadenwahrscheinlichkeit im Falle eines Angriffs.
-
Seite 196 von 262

Wahrscheinlichkeit für Angriffsversuche
Description
Values Values
Very High 96-100 10 Adversary is almost certain to initiate the threat event.
High 80-95 8 Adversary is highly likely to initiate the threat event.
Moderate 21-79 5 Adversary is somewhat likely to initiate the treat event.
Low 5-20 2 Adversary is unlikely to initiate the threat event.
Very Low 0-4 0 Adversary is highly unlikely to initiate the threat event.
Wahrscheinlichkeit der erfolgreichen Angriffsausführung
Description
Values Values
Error, accident, or act of nature is almost certain to occur; or

Very High 96-100 10
occurs more than 100 times a year
Error, accident, or act of nature is highly likely to occur; or

High 80-95 8
occurs between 10-100 times a year
Error, accident, or act of nature is somewhat likely to occur; or

Moderate 21-79 5
occurs between 1-10 times a year.
Error, accident, or act of nature is unlikely to occur; or occurs

Low 5-20 2
less than once a year, but more than once every 10 years.
Error, accident, or act of nature is highly unlikely to occur; or

Very Low 0-4 0
occurs less than once every 10 years.
Seite 197 von 262

Schadenswahrscheinlichkeit im Falle eines Angriffs
Description
Values Values
If the threat event is initiated or occurs, it is almost certain to

Very High 96-100 10
have adverse impacts
If the threat event is initiated or occurs, it is highly likely to have

High 80-95 8
adverse impacts
If the threat event is initiated or occurs, it is somewhat likely to

Moderate 21-79 5
If the threat event is initiated or occurs, it is unlikely to have

Low 5-20 2
adverse impacts
If the threat event is initiated or occurs, it is highly unlikely to

Very Low 0-4 0
Für die Gesamteintrittswahrscheinlichkeit für einen Angriff gibt der Standard folgende
Kriterien an:
Likelihood of Likelihood Threat Events Result in Adverse Impacts

Threat Event
Initiation or
Occurrence Very Low Low Moderate High Very High
Very High Low Moderate High Very High Very High
High Low Moderate Moderate High Very High
Moderate Low Low Moderate Moderate High
Low Very Low Low Low Moderate Moderate
Very Low Very Low Very Low Low Low Low
Seite 198 von 262

Schäden durch Angriffe klassifiziert der Standard in folgenden Kategorien:
Type of Impact Type of Impact
HARM TO - Inability to perform current missions/business functions.

OPERATIONS
- In a sufficiently timely manner.
- With sufficient confidence and/or correctness.
- Within planned resource constraints.
- Inability, or limited ability, to perform missions/business functions in the future.
- Inability to restore missions/business functions.
- In a sufficiently timely manner.
- With sufficient confidence and/or correctness.
- Within planned resource constraints.
- Harms (e.g., financial costs, sanctions) due to noncompliance.
- With applicable laws or regulations.
- With contractual requirements or other requirements in other binding
agreements (e.g., liability).
- Direct financial costs.
- Relational harms.
- Damage to trust relationships.
- Damage to image or reputation (and hence future or potential trust
relationships).
HARM TO - Damage to or loss of physical facilities.

ASSETS
- Damage to or loss of information systems or networks.
- Damage to or loss of information technology or equipment.
- Damage to or loss of component parts or supplies.
- Damage to or of loss of information assets.
- Loss of intellectual property.
HARM TO - Injury or loss of life.

INDIVIDUALS
- Physical or psychological mistreatment.
- Identity theft.
- Loss of Personally Identifiable Information.
- Damage to image or reputation.
Seite 199 von 262

HARM TO OTHER - Harms (e.g., financial costs, sanctions) due to noncompliance.

ORGANIZATIONS
- With applicable laws or regulations.
- With contractual requirements or other requirements in other binding
agreements.
- Direct financial costs.
- Relational harms.
- Damage to trust relationships.
- Damage to reputation (and hence future or potential trust
relationships).
HARM TO THE - Damage to or incapacitation of a critical infrastructure sector.

NATION
- Loss of government continuity of operations.
- Relational harms.
- Damage to trust relationships with other governments or with
nongovernmental entities.
- Damage to national reputation (and hence future or potential trust
relationships).
- Damage to current or future ability to achieve national objectives.
- Harm to national security.
Die Kriterien zur Beurteilung der Schwere von Schäden durch Angriffe gibt der Standard wie
folgt an:
Description
Values Values
The threat event could be expected to have multiple severe or

catastrophic adverse effects on organizational operations,
Very High 96-100 10
organizational assets, individuals, other organizations, or the
Nation.
The threat event could be expected to have a severe or

catastrophic adverse effect on organizational operations,
organizational assets, individuals, other organizations, or the
Nation. A severe or catastrophic adverse effect means that, for
example, the threat event might: (i) cause a severe degradation
High 80-95 8 in or loss of mission capability to an extent and duration that the
organization is not able to perform one or more of its primary
functions; (ii) result in major damage to organizational assets; (iii)
result in major financial loss; or (iv) result in severe or
catastrophic harm to individuals involving loss of life or serious
life-threatening injuries.
Seite 200 von 262

The threat event could be expected to have a serious adverse

effect on organizational operations, organizational assets,
individuals other organizations, or the Nation. A serious adverse
effect means that, for example, the threat event might: (i) cause a
significant degradation in mission capability to an extent and
Moderate 21-79 5 duration that the organization is able to perform its primary
functions, but the effectiveness of the functions is significantly
reduced; (ii) result in significant damage to organizational assets;
(iii) result in significant financial loss; or (iv) result in significant
harm to individuals that does not involve loss of life or serious life-
threatening injuries.
The threat event could be expected to have a limited adverse

effect on organizational operations, organizational assets,
individuals other organizations, or the Nation. A limited adverse
effect means that, for example, the threat event might: (i) cause a
Low 5-20 2 degradation in mission capability to an extent and duration that
the organization is able to perform its primary functions, but the
effectiveness of the functions is noticeably reduced; (ii) result in
minor damage to organizational assets; (iii) result in minor
financial loss; or (iv) result in minor harm to individuals.
The threat event could be expected to have a negligible adverse

Very Low 0-4 0 effect on organizational operations, organizational assets,
individuals other organizations, or the Nation.
Der Standard empfiehlt, im Rahmen der Vorbereitungsphase auch das vom Unternehmen
akzeptierte Risiko sowie die mit den Randbedingungen verbundenen Unsicherheiten
abzuschätzen. Auf diesen Schritt wird in der weiteren Analyse verzichtet, da die dafür
notwendigen Geschäftsinformationen den Leittechniklieferanten in der Regel nicht zur
Verfügung stehen.
Als Beurteilungs- und Analysemethode empfiehlt der Standard folgende Ansätze:
Beurteilungsmethode
 Quantitativ
 Qualitativ
 Semi-quantitativ
Analysemethode
 Bedrohungsorientiert
 Wert- oder Schadensorientiert
 Schwachstellenorientiert
Für die weitere Betrachtung wird ein qualitativer, bedrohungsorientierter Ansatz gewählt.
Seite 201 von 262

Begründung:
1) Aufgrund der Unsicherheiten bei Abschätzungen sind numerische Beurteilungen nicht

begründbar.
2) Der SCADA-Lieferant verfügt weder über ausreichende Informationen bezüglich der
kommerziellen Geschäftsaspekte des Zielunternehmens noch hinsichtlich der
Schwachstellen eingesetzter Fremdprodukte (z.B. Betriebssysteme).
Task 1-4
Identify the sources of descriptive, threat, vulnerability, and impact information to be

used in the risk assessment.
Für die weitere Risikoanalyse werden jene Informationen, über die der SCADA-Lieferanten
verfügt, zugrunde gelegt.
Task 1-5
Identify the risk model and analytic approach to be used in the risk assessment.
Das Ziel der Betrachtung ist es, die IT-Sicherheit des SCADA-Systems zu beurteilen.
Mangels direkter IT-Sicherheitsgrößen wird - in Abwandlung typischer kommerziell
orientierter Risikoabschätzungen im Sinne eines potentiellen Schadens - in der
nachfolgenden Analyse versucht, das Risiko einer Manipulation des SCADA-Systems
abzuschätzen.
Als Risiko wird nicht der kommerziell messbare Schaden eines Angriffes aufgefasst, sondern
die Wahrscheinlichkeit einer angriffsbedingten Fehlfunktion des SCADA-Systems.
8.2.2 Beispielhafte Anlagenbeurteilung auf Basis des Standards
Auf Basis der im vorangegangenen Kapitel dargestellten Schemata soll nun die
Anlagenanalyse der Beispielanlage erfolgen.
Identifikation der Bedrohungsquellen und -ereignisse
Aus den Überlegungen zur Vorbereitung der Beurteilung einer SCADA-Anlage im

vorangegangenen Kapitel, dient eine erstellte Checkliste für die Identifikation der
Bedrohungsquellen und -ereignisse.
Seite 202 von 262

Zu diesem Zweck werden die Bedrohungsszenarien (siehe oben: Tabelle „Threat Events”)
auf die grundsätzliche Anwendbarkeit auf ein SCADA-System überprüft und gegebenenfalls
in die Checkliste „Bedrohungsszenarien“ übertragen (siehe Abbildung 33). Für die
Überprüfung einer Zielanlage wurde in die Checkliste die Spalte „Realisierbarkeit“
hinzugefügt, die angibt, ob die gegebenen Randbedingungen die Umsetzung des Szenarios
in der Zielanlage überhaupt ermöglichen.
Abbildung 33: Standard-basierte Bedrohungsszenarien (Template)
Schwachstellen und Vorbedingungen
Im zweiten Schritt der Anlagenbeurteilung sind den zu berücksichtigenden

Bedrohungsszenarien für SCADA-Anlagen die Relevanz der Bedrohungsereignisse und die
Ausnutzbarkeit der Schwachstellen zuzuordnen (siehe Abbildung 34). Die Reichweite der
Bedrohungsszenarien bleibt in der weiteren Betrachtung ausgeklammert, da die
Seite 203 von 262

Leittechniksysteme und der gesteuerte physikalische Anlagenprozess als Einheit aufgefasst

werden.
Abbildung 34: Bedrohungsrelevanz (Template)
Die drei oben beschriebenen Variablen
 Realisierbarkeit in Zielanlage
 Bedrohungsrelevanz
 Ausnutzbarkeit der Schwachstellen
sind in eine Gesamtrelevanz des entsprechenden Bedrohungsszenarios abzubilden.
Seite 204 von 262

Zur Berechnung der Szenario-Gesamtrelevanz liegt folgendes Schema zu Grunde, das sich
aus obigem NIST-Modell ableitet:
Variable Einschätzung Berechnungsfaktor
ja 1
Realisierbarkeit eines Szenarios
nein 0
Bestätigt 100
Erwartet 80
Angenommen 60
Bedrohungsrelevanz
Vorhergesagt 40
Möglich 20
N/A (nicht anwendbar) 0
Very High 100
High 95
Ausnutzbarkeit Moderate 79
Low 20
Very Low 4
Die Ausnutzbarkeit der Schwachstellen wurde anhand folgender Kriterien klassifiziert:
Klasse der Bekanntheitsgrad Konsequenzen der Implementierte

Ausnutzbarkeit der Schwachstelle Ausnutzung Schutzmaßnahmen
ausnutzbar mit schweren

Very High bekannt keine
Auswirkungen
ausnutzbar mit schweren

High bekannt geringe
Auswirkungen
ausnutzbar mit mittleren mit durchschnittlicher

Moderate bekannt
Auswirkungen Wirksamkeit
ausnutzbar mit geringen mit erheblicher

Low bekannt
Auswirkungen Wirksamkeit
ausnutzbar mit unerheblichen effektive und geprüfte

Very Low bekannt
Auswirkungen Schutzmaßnahmen
Seite 205 von 262

Die Szenario-Relevanz berechnet sich mittels der Formel
Szenario-Relevanz = Realisierbarkeit * Bedrohungsrelevanz * Ausnutzbarkeit / 100
Einen qualifizierten Ergebniswert (gem. NIST-Schema) liefert die abschließende

Transformation des numerischen Ergebnisses in eine qualitative Aussage:
Variable: Szenario-Relevanz
Numerischer Ergebniswert Qualitative Aussage
0 N/A
1 … 10 Very low
11 … 30 Low

31 … 59 Moderate
60 … 78 High
>79 Very High
Bestimmung der Eintrittswahrscheinlichkeit
Der dritte Schritt einer Anlagenbeurteilung ordnet die realisierbaren Angriffsszenarien einer
Eintrittswahrscheinlichkeiten zu (siehe Abbildung 35).
Hierzu gehören
 die Wahrscheinlichkeit von Angriffsversuchen,

 die Wahrscheinlichkeiten erfolgreicher Angriffe sowie
 die Schadenswahrscheinlichkeit im Falle erfolgreicher Angriffe.
Da die Einschätzung der Wahrscheinlichkeit von Angriffsversuchen sehr stark von den
potentiellen Angreifer-Kategorien abhängt, über die einem Betreiber wenig bis keine
verlässlichen Informationen zur Verfügung stehen, wird diese Wahrscheinlichkeitsgröße in
der weiteren Betrachtung nicht berücksichtigt.
Seite 206 von 262

Abbildung 35: Eintrittswahrscheinlichkeiten (Template)
Die Überführung der beiden berücksichtigten Wahrscheinlichkeiten (Wahrscheinlichkeiten

erfolgreicher Angriffe, Schadenswahrscheinlichkeit im Falle erfolgreicher Angriffe) in eine
„Szenario-Eintrittswahrscheinlichkeit für einen Angriff“ erfolgt gemäß gegebenem NIST-
Schema (siehe 8.2.1). Anmerkung: Die Einschätzungen dieser Wahrscheinlichkeiten
unterliegen der subjektiven Einschätzung der Auditoren und wurden in Abweichung von den
Kriterien des NIST-Standards wie folgt klassifiziert:
Wahrscheinlichkeit Erwartete
erfolgreicher Angriffe Eintrittshäufigkeit
Very High 1x je Woche
High 1x je Monat
Moderate 1x je Jahr
Low 1x je 10 Jahre
Very Low 1x je Anlagennutzungsdauer
Seite 207 von 262

Für die Schadenswahrscheinlichkeit erfolgreicher Angriffe (gem. NIST-Klassifizierung)

wurden folgende Klassifizierungen gewählt:
Schadenswahrscheinlichkeit
Eintrittswahrscheinlichkeit
erfolgreicher Angriffe
Very High 96 – 100%
High 80 – 95%
Moderate 21 – 79%
Low 5 – 20%
Very Low 0 – 4%
Bestimmung des Schadenspotentials
Die Schadensbeurteilung gemäß (NIST-SP800-30, 2012) berücksichtigt einerseits die

Instanzen, die einen Schaden erleiden und andererseits die Schwere des angerichteten
Schadens.
Die Bewertung der Schadensklassen nimmt der Verfasser wie folgt vor:
 Nation/Gesellschaft: viele Personen, Umwelt und/oder Sachwerte erleiden Schäden

 Unternehmen: ein Schaden ist auf das Unternehmen (Personen, Umwelt und/oder
Sachwerte) beschränkt
 Personen: einzelne oder wenige Personen kommen zu Schaden
 Betrieb/Anlage/Sachwerte: Vermögenswerte des Unternehmens sind gefährdet
 Betriebsablauf: die Verfügbarkeit der Produktion ist gefährdet
Die Schwere des angerichteten Schadens klassifiziert der Standard wie folgt:
 Very High: mehrere katastrophale Schadensereignisse

 High: ein schweres oder katastrophales Schadensereignis
 Moderate: ein ernstes Schadensereignis
 Low: begrenzte Schadenswirkung
 Very Low: vernachlässigbarer Schaden
Die Transformation der Szenario-Schadensklassifikation erfolgt auf Basis des NIST-
Transformationsschemas für die Szenario-Eintrittswahrscheinlichkeit (siehe 8.2.1). Die
Checkliste ist in Abbildung 36 abgebildet.
Seite 208 von 262

Abbildung 36: Schadensklassifikation (Template)
Abschließende Bestimmung des Gesamtrisikos
Wie anhand der in Kapitel 8.2.1 beschriebenen NIST-Schemata und den daraus abgeleiteten
Checklisten beschrieben, setzt sich der qualitative Risikowert eines Bedrohungsszenarios
aus folgenden Größen zusammen:
 Szenario-Relevanz
 Szenario-Schadensklassifikation
 Szenario-Eintrittswahrscheinlichkeit
Diese drei Größen verfügen über den Wertevorrat „N/A / Very Low / Low / Moderate / High /
Very High”. Zum Zweck einer automatisierten Bestimmung des Gesamtrisikos erfolgt eine
Abbildung auf nummerische Werte. Folgendes lineare Transformationsschema diente dieser
Wandlung der qualitativen Aussagen in numerische Werte:
Seite 209 von 262

Qualitativer Wert Quantitativer Wert
N/A 0
Very Low 20
Low 40

Moderate 60
High 80
Very High 100
Mit Hilfe dieses Transformationsschemas erfolgte die Bildung numerischer Werte für die drei
Größen. Das Szenario-spezifische Risiko bestimmt sich als Mittelwert dieser drei
numerischen Größen. falls die Szenario-Relevanz nicht „N/A“ ist:
Falls Relevanz = „N/A“:
Szenario-spezifisches Risiko = 0
Falls Relevanz <> „N/A“:
Szenario-spezifisches Risiko =
(Relevanz + Schadensklassifikation + Eintrittswahrscheinlichkeit)/3
Zur Rücktransformation des berechneten numerischen Szenario-spezifischen Risikowertes

in eine qualitative Aussage dient das folgende Transformationsschema:
Quantitativer Wert Qualitativer Wert
0 N/A
1 ... 20 Very Low
21 ...40 Low

41 ...60 Moderate
61 ...80 High
81...100 Very High
Das Ergebnis der Analyse erhält man automatisch in der Auswertetabelle für eine Zielanlage
entsprechend Abbildung 37.
Seite 210 von 262

Abbildung 37: Bestimmung des Gesamtrisiko (Template)
In Abbildung 38 ist ein Ausschnitt des Analyseergebnisses dargestellt.
Seite 211 von 262

Abbildung 38: Analyseergebnis gemäß Standard-Methode (Ausschnitt)
Zum Zwecke einer übersichtlicheren Darstellung des Anlagenrisikos können die 5 Gruppen
der NIST-Bedrohungsszenarien zur nachfolgend dargestellten Gesamtaussagen
zusammengefasst werden:
Bedrohungsszenarien Szenario-Risikowert
Perform reconnaissance and gather information Low 26,3
Deliver/insert/install malicious capabilities Low 40,0
Exploit and compromise Low 39,4
Conduct an attack
Low 34,3
(i.e., direct/coordinate attack tools or activities)
Achieve results
Moderate 43,5
(i.e., cause adverse impacts, obtain information)
Legende: Quantitativer Risikowert: Very High / High / Moderate / Low / Very Low / N/A
Qualitativer Risikowert: 0 ... 100
Seite 212 von 262

Einschränkungen
Bei der Herleitung der Checklisten ist zu berücksichtigen, dass NIST SP8000-30 zur
Risikobeurteilung von (allgemeinen) IT-Systemen dient. Der Standard ist nicht auf SCADA-
Systeme zugeschnitten. Eine Abgrenzung des Bedrohungskataloges auf jene Szenarien, die
für Leittechniksysteme in Frage kommen, ist unumgänglich. Aus diesem Grund fand eine
Reihe von Fragen des Standards keine Berücksichtigung in den Checklisten.
Im Wesentlichen blieben Fragen zu folgenden Themenbereichen unberücksichtigt:
 Bedrohungsszenarien, die keinen direkten Bezug zu SCADA-Systemen haben, z.B.

Beschaffung von Informationen im Internet, Angriffsvorbereitungen mittels „social
engineering“ oder „phishing“ / E-Mail-Angriffe gegen Mitglieder der
Unternehmensleitung, E-Mail-Versand von Schadsoftware im Unternehmensnetzwerk
(nicht SCADA-Netzwerk) etc.
 Bedrohungsszenarien, die explizit Nicht-SCADA-Systeme adressieren, z.B. Angriffe
gegen E-Mail- / Web-Server- / ERP- / Datenbank-Systeme im
Unternehmensnetzwerk, Angriffe gegen Cloud-Funktionen / -Daten etc.
Wie bereits im vorangegangenen Kapitel beschrieben, fließen in die Analyse auch die
subjektiven Einschätzungen des Auditors (hier: des Verfassers) in die Ergebnisse ein.
8.2.3 Anwendung der vorgeschlagenen Analysemethodik auf die Beispielanlage
Diese Kapitel beschreibt die Analyse der gleichen Beispielanlage wie im vorangegangenen
Kapitel – jedoch anhand der in dieser Arbeit vorgeschlagenen Analysemethode.
Vorgehensweise
Die Analyse auf Basis der vorgeschlagenen neuen Szenario-basierter Analyse erfolgt in
folgenden Schritten:
Seite 213 von 262

1. Einpflegen der Anlagendaten in die Datenbank
Datenbanktabellen:
 Devices
 Net
 Config
 Staff
 Switches
 UserAccess
 StaticARP
2. Exportieren der PROLOG-Klauseln, d.h. Überführen der Datenbankinhalte in

PROLOG-Fakten
Der Export erfolgt mittels gespeicherter Datenbankmakros, die die

entsprechenden Datenbankabfragen ausführen und in externe Textdateien
überführen. Exportiert werden die Anlagendaten sowie die generierten
Klauseln der Szenario-Beschreibungen.
3. PROLOG-Analyse durchführen
Die Analyse ergab 1343 Szenario-Instanzen, die aufgrund der

Systemtopologie gegen die Zielanlage ausführbar sind.
4. Import der gefundenen kritischen Szenarien in die Datenbank
Der Import der erhaltenen Ergebnisse der PROLOG-Analyse in die Datenbank

erfolgt mit Hilfe eines gespeicherten Datenbankmakros in eine entsprechende
Datenbanktabelle.
5. Auswertung der Security-Metrik
Zur Analyse der Ergebnisse und einfachen grafischen Darstellungen lassen

sich die Ergebnisse der Security-Metrik in MS Excel aus der Datenbank
aufrufen und darstellen.
Zum Zwecke der Darstellung des sogenannten dynamischen Teils der Security-Metrik wurde
eine der gefundenen Schwachstelle der Zielanlage virtuell beseitigt. (hier: DSL-Modem für
Remote Access für Servicezwecke) und die oben genannten Schritte 1 ... 5 mit der
abgeänderten Anlagenkonfiguration erneut durchgeführt. Auf diese Weise ergeben sich zwei
Seite 214 von 262

unterschiedliche Analyseergebnisse. Die Auswirkungen auf die Sicherheit der

Leittechnikanlage lassen sich anhand des dynamischen Elements der Security-Metrik
darstellen.
Gemäß der beschriebenen Vorgehensweise ergab die PROLOG-Analyse 1343 kritische

Szenarien, d.h. Angriffsmuster, die aufgrund der systemtechnischen Ausprägung der
Zielanlage ausführbar sind.
Die MS Excel-basierte Sicherheitsmetrik ergab für den Anlagenzustand folgende Werte:
Das Sicherheitsniveau beträgt lediglich 7.2 %, d.h. 90 von insgesamt 97 bekannten

Szenarien sind ausführbar (siehe Abbildung 39).
Abbildung 39: Ergebnis "Sicherheitsniveau" (Beispielanlage)
Die Angriffsoberfläche ergab die in Abbildung 40 aufgeführten Instanzen der verschiedenen

Angriffsmuster, d.h. wie häufig – in unterschiedlichen Varianten – die Angriffsmuster
ausführbar sind.
Seite 215 von 262

Abbildung 40: Ergebnis "SCADA-Angriffsoberfläche" (Beispielanlage)
In Abbildung 41 sind die gefundenen Angriffspunkte („Top 10“) aufgelistet. Mit 218
Angriffsvarianten ist ein unbekanntes „malicious device“ aufgeführt. Diese Lösung ergab sich
aus der Anlagenbeschreibung, die die beiden generischen Geräte „external switch“,
angeschlossen an das DSL-Modem, sowie „malicious device“, angeschlossen an den
vorgenannten Switch im Internet, enthält. Auf diese Weise wurde ein unbekanntes Gerät
(Rechner) im Internet modelliert.
Abbildung 41: Ergebnis "Kritische Angriffspunkte" (Beispielanlage)
Seite 216 von 262

Für die Bestimmung der Kritikalität der Angriffsszenarien (siehe Kapitel 6.5.1) wurden
folgende Anforderungsfaktoren der Szenarien-Voraussetzungen festgelegt:
Zugänglichkeit Gelände Gebäude LT-Raum Geräteschrank
Risikowert 1 2 4 8
Allgemein Eingeschränkt Nur schwierig Individuelle

Ausrüstung
erhältlich erhältlich erhältlich Ausrüstung
Risikowert 1 2 4 8
Allgemein Spezielle Kritisches

Knowhow Ausnahmefall
voraussetzbar Kompetenzen Knowhow
Risikowert 1 2 4 8
Anmerkung: Die Abbildung der Voraussetzungsklassen in numerische Werte soll lediglich die
nachfolgende Auswertung vereinfachen.
An dieser Stelle sei nochmals auf die Bedeutung des Begriffes „Risikowert“ im Kontext der
vorliegenden Arbeit hingewiesen (s. a. 5.4.2): Im Gegensatz zu anderen, risikobasierten
Analyseansätzen, soll der „Risikowert“ nachvollziehbar darstellen, welche
Angriffsvoraussetzungen im Sinne einer tolerierbaren Angriffshürde der Betreiber als
hinreichend unwahrscheinlich und mithin als akzeptabel klassifiziert.
Für die Bestimmung der Kritikalität der Angriffsszenarien wurde der Betreiber-Risikovektor
folgendermaßen angenommen, d.h. der Betreiber akzeptiert Szenarien deren
Voraussetzungen Angreifer-seitig mindestens folgende Anforderungsfaktoren zugeordnet
werden können (gemäß obigen Tabellen der Voraussetzungsklassen):
Betreiber-
Ausrüstung Knowhow Zugänglichkeit
Risikovektor
Anforderungsfaktor 6 10 10
Seite 217 von 262

Alle Angriffsszenarien, deren Voraussetzungen hinsichtlich Ausrüstung, Knowhow und

Zugänglichkeit den vom Betreiber vorgegebenen Anforderungsfaktor unterschreiten, werden
als „kritisch“ eingestuft.
Als Analyseergebnis zeigt sich, dass gemäß Betreiber-Risikovektor für die Zielanlage 89%
der Angriffsszenarien als kritisch eingestuft werden. Dies bedeutet, dass 80
Angriffsszenarien das vom Betreiber akzeptierte Risiko übersteigen (siehe Abbildung 42).
Anmerkung: der Betreiber-Risikovektor wurde vom Verfasser angenommen.
Abbildung 42: Ergebnis "Kritikalität" (Beispielanlage)
Die vorigen Abschnitte dokumentieren für die Zielanlage (gemäß Abbildung 30 / Abbildung
31) die statischen Analyseergebnisse zum Zeitpunkt der Untersuchung. Um die
dynamischen, d.h. über die Zeit veränderlichen, Inhalte der Sicherheitsmetrik darstellen zu
können, erfolgte (fiktiv) eine Änderung an der Zielanlage und anschließend eine erneute
Analyse. Die Vergleichsanalyse beruht auf der Annahme, dass sich aufgrund der
Erkenntnisse aus der Erstanalyse der Betreiber dazu entschlossen hat, das DSL-Modem aus
der Anlage zu entfernen.
Nachfolgend sind die Veränderungen der Kennzahlen der Sicherheitsmetrik aufgrund der
Veränderung der Zielanlagenkonfiguration dargestellt (dynamische Metrik-Elemente).
Nach der (angenommenen) Veränderung der Zielanlage förderte die PROLOG-Analyse noch
1087 kritische Szenarien zutage. Das Sicherheitsniveau der Anlage verbesserte sich um
28.9%. Anstelle der ursprünglich 90 Angriffsszenarien lassen sich nach der Modifikation nur
noch 64 Szenarien ausführen. (Abbildung 43)
Seite 218 von 262

Abbildung 43: Ergebnis "Sicherheitsniveau / dynamisch" (Beispielanlage)
Die Anzahl der möglichen Angriffsvarianten, die gegen die abgeänderte Zielanlage möglich
sind, hat sich um ca. 19% reduziert (Abbildung 44).
Abbildung 44: Ergebnis "SCADA-Angriffsoberfläche / dynamisch" (Beispielanlage)
Aus Abbildung 45 ist ersichtlich, dass als kritische Komponente das Fremdgerät („malicious
device“) nicht mehr erscheint bzw. die mögliche Anzahl von Angriffen aufgrund dieser
Komponente auf null sinkt.
Seite 219 von 262

Abbildung 45: Ergebnis "Kritische Angriffspunkte / dynamisch" (Beispielanlage)
Deutlich verbessert ( -30% ) hat sich die Anzahl jener Angriffsszenarien, die vom Betreiber
als „kritisch“, d.h. als ‚zu einfach‘ realisierbare Angriffsszenarien eingestuft werden
(Abbildung 46).
Abbildung 46: Ergebnis "Kritikalität / dynamisch" (Beispielanlage)
Randbedingungen
Die Analyse auf einem PC (AMD Athlon 64 Dual Core Prozessor, MS Windows XP) benötigt
laut PROLOG-Statistik („time”) 8,31 sec.
Seite 220 von 262

8.3 Ergebnisvergleich der angewandten Analysemethoden
8.3.1 Ergebnisse der Standard-basierten Analyse
Analyseergebnis
Die Analyse der Zielanlage auf Basis des Standards NIST SP 800-30 ergab folgendes
zusammengefasste Ergebnis:
Threat scenario Risk level
Perform reconnaissance and gather information Low 26,3
Deliver/insert/install malicious capabilities Low 40,0
Exploit and compromise Low 39,4
Conduct an attack (i.e., direct/coordinate attack tools or activities) Low 34,3
Achieve results (i.e., cause adverse impacts, obtain information) Moderate 43,5
Das Analyseergebnis liefert eine Gesamtaussage über die betrachtete Gesamtanlage.
Vorteile der Methode
Vorteil der Analysemethode gemäß NIST SP 800-30 ist aus Sicht des Verfasser der
umfangreiche Katalog an Bedrohungsszenarien. Dieser Katalog ermöglicht, eine Fragenliste
/ Checkliste zu entwickeln, die auf die Zielanlage zugeschnitten ist. Bei Wiederverwendung
der Checklisten ist lediglich darauf zu achten, Veränderungen an der Anlage hinreichend zu
berücksichtigen.
Nachteile der Methode
Die Nachteile der Methode übersteigen die Vorteile jedoch bei Weitem.
- Aussagekraft der Ergebnisse
Betrachtet man die zusammengefassten Ergebnisse in obiger Tabelle, so stellt sich

sofort die Frage, was ein Risiko-Level von z.B. „Moderate“ bzw. „43.5“ bedeutet. Selbst
die Annahme einer statistischen Aussage, wie z.B. „die Wahrscheinlichkeit eines
erfolgreichen Angriffs innerhalb der Nutzungsdauer der Anlage beträgt 43,5%“ ist wenig
hilfreich: Schließlich bedeutet jeder Wahrscheinlichkeitswert > 0%, dass ein Angriff
Seite 221 von 262

jederzeit (d.h. auch: sofort) möglich ist. Die Übertragung statistischer Aussagen auf
Einzelereignisse liefert keine anlagenspezifischen Aussagen.
- Vergleichbarkeit der Ergebnisse
Verzichtet man auf die Interpretation der gewonnenen Ergebnisse im Sinne absoluter
Aussagen (gemäß a) ), dann stellt sich die Frage, ob die Ergebnisse relativen Charakter
haben und zu Vergleichen herangezogen werden können.
Vergleiche lassen sich in zeitlicher und Objektperspektive anstellen:
 Zeitlich: Veränderung von Analyseergebnissen einer Anlage über die Zeit

(regelmäßige Analysen)
 Objekte: Vergleiche der Analyseergebnisse verschiedener Anlagen
Die Beurteilung der Vergleichbarkeit der Analyseergebnisse der Standard-basierten
Methode muss berücksichtigen, dass in die Analyseteilschritte (Realisierbarkeit der
Bedrohungsszenarien, Bedrohungsrelevanz, Eintrittswahrscheinlichkeiten und
Schadensklassifikation) folgende Informationen einfließen:
 Bedrohungsszenario
 Anlagenstruktur
 Einschätzung der Auditoren
Analysiert man dieselbe Anlage zu verschiedenen Zeitpunkten, dann fließen
Anlagenänderungen, Änderungen der Bedrohungsszenarien und unterschiedliche
Einschätzungen der Auditoren (Erfahrungsgewinn / -verlust, veränderte
Teamzusammensetzung) in die Beurteilung ein. Welche Konsequenzen ein
Anlagenbetreiber aus den Ergebnisänderungen ziehen soll, ist völlig unklar.
Analysiert und vergleicht man verschiedene Anlagen, dann fließen unterschiedliche

Unternehmensorganisationen, Anlagenstrukturen, evtl. unterschiedliche, wirksame
Bedrohungsszenarien und unterschiedliche Einschätzungen der Auditoren
(unterschiedliche Teamzusammensetzungen) in die Beurteilung ein. Auch bei dieser Art
des Vergleichs ist die Interpretation der Ergebnisse völlig offen.
Die Nutzung der Analyseergebnisse zu Vergleichszwecken ist fragwürdig.
- Automatisierung der Analysemethode
Eine Automatisierung der Analyse ist mit Ausnahme der Datenaggregation nicht möglich,
da die Fragestellungen nicht in systemtechnische Abfragen abgebildet werden können.
Seite 222 von 262

- Ableitung von Handlungsoptionen
Die NIST SP 800-30-basierte Methode stellt keine Ableitung von Handlungsoptionen aus
den Analyseergebnissen bereit.
- Fehlende Aussage zum Sicherheitsstatus einer Zielanlage
Die Ergebnisse der Analyse liefern keine Aussage über den Sicherheitsstatus einer
betrachteten Leittechnikanlage, sondern lediglich wenig nutzbare Aussagen zu
fragwürdigen Risikowerten.
8.3.2 Ergebnisse der vorgeschlagenen Szenario-basierten Analysemethode
Vorteile der Methode
An der Methode der Szenario-basierten Analyse werden folgende Aspekte als vorteilhaft
eingeschätzt:
a) Die Methode basiert ausschließlich auf Anlagenfakten und Benutzerangaben (Betreiber-

Risikovektor), die im System hinterlegt und damit eindeutig dokumentiert sind.
Individuelle Einschätzungen sind nicht erforderlich.
b) Die Methode liefert konkrete, d.h. numerische Aussagen zum Sicherheitsstatus der
Zielanlage.
c) Die Methode liefert konkrete Aussagen hinsichtlich der Schwachstellen, d.h. der
besonders kritischen Anlagenteile.
d) Im Falle technologischer Änderungen des Zielsystems ist die Faktenbasis einfach
anpassbar.
e) Die Methode liefert reproduzierbare Ergebnisse.
Nachteile der Methode
Als nachteilig werden derzeit lediglich die systemtechnische Handhabung von Datenbank
und PROLOG-System, d.h. unzureichende Benutzeroberfläche sowie die noch fehlende
Integration der beiden Komponenten angesehen.
8.3.3 Gegenüberstellung und Vergleich der Analyseergebnisse
In der nachfolgenden Tabelle sind die Ergebnisse der beiden Analysemethoden

gegenübergestellt:
Seite 223 von 262

Ergebniseigenschaften Standard-basierte Methode Fakten-basierte Methode
Risikowerte für fünf wesentliche

Sicherheitsmetrik für individuelle
Schritte eines Cyber-Angriffes
Art der Ergebnisse Zielanlage
(siehe 8.3.1 / Tabelle
(siehe 8.2.3)
Gesamtaussage)
Die Ergebnisse basieren in

transparenter Weise auf Daten,
Die Zusammensetzung des
die aus der betrachteten
Ergebnisqualität Analyseteams hat starken
Zielanlage ableitbar bzw.
Einfluss auf die Ergebnisse.
nachvollziehbar dokumentiert
sind.
Gering Hoch
Hängt vom Kreis der Auditoren Alle ergebnisbestimmenden
Reproduzierbarkeit ab, den zeitlichen Abständen Faktoren sind im System
zwischen Audits sowie hinterlegt; keine individuellen
technischen Änderungen Einschätzungen
Individuelle Auditoren- Faktenbasierte Aussagen zum

Nutzen der Ergebnisse einschätzungen des Risikos eines Systemzustand, hinsichtlich der
Cyberangriffes IT-Sicherheit;
Mittel – Hoch
Gering
Automatisierbarkeit (Zielsystemdaten, Analyse-ablauf,
(nur Aggregation der Input-Daten)
Sicherheitsmetrik)
Erfordern Interpretation der Konkrete Hinweise auf

Handlungsoptionen
Ergebnisse Anlagenschwachstellen
Vergleichbarkeit ...
aktueller Ergebnisse Bedingt; Ja;

mit vorangegangenen die Einflüsse veränderter Anlagenänderungen und ver-
Analysen Bedrohungssituationen, Anlagen- änderte Risikoeinschätzungen
änderungen oder Wechsel beim sind nachvollziehbar
Audit-Personal sind nicht zu
identifizieren
der Ergebnisse Bedingt;

Bedingt;
verschiedener Kennzahlen der Sicherheits-
die Risikoeinschätzung metrik können als Vergleichswert
Anlagen
hinsichtlich des Bedrohungs- herangezogen werden, falls
potentials verschiedener Anlagen vergleichbare Angriffsszenarien
kann zwecks Erfahrungs- den Analysen zugrunde liegen
austausch von Interesse sein
Erstanalyse: Erfassung der
Abhängig von der Anlagengröße Anlagendaten
Aufwand – zwecks Einarbeitung der
Auditoren Folgeanalysen: Erfassung der
Anlagenänderungen
Etablierte Methode Ja Nein
Seite 224 von 262

Die Gegenüberstellung der Ergebnisse der beiden Methoden zeigt, dass die Standard-
basierte Analyse allgemeine Aussagen zum Risiko eines Cyber-Angriffes macht.
Wesentliche Defizite sind die individuellen Einschätzungen, die der Analyse zugrunde liegen,
sowie die Frage, welche Aussagekraft die resultierenden Risikowerte überhaupt haben.
Demgegenüber liefert die Fakten-basierte Methode reproduzierbare Ergebnisse zur

betrachteten Zielanlage. Der Betreiber erhält konkrete Aussagen zu Schwachstellen der
Anlage. Die Analyse liefert konkrete Hinweise auf jene Systeme bzw. Komponenten, die
aufgrund der Anzahl der kritischen Angriffsszenarien das größte Gefährdungspotential für die
Zielanlage darstellen und sind ein wesentlicher Baustein der resultierenden Sicherheitsmetrik
(siehe z.B. das DSL-Modem und ‚malicious device‘ in Kapitel 8.2.3, s.a. Abbildung 41 und
Abbildung 45).
Seite 225 von 262

Kapitel 9 Zusammenfassung und Ausblick
9 Zusammenfassung und Ausblick

Abschließend fasst dieses Kapitel die wesentlichen Ergebnisse dieser Arbeit zusammen und
skizziert einen Ausblick auf Fragestellungen, die die vorgestellte Analysemethode erweitern
können.
 Fokussierung auf IT-Sicherheit
Ausgehend von der Betrachtung der Begrifflichkeiten im Zusammenhang mit der IT-
Sicherheit leittechnischer Anlagen wurde die inhaltliche Fokussierung der vorliegenden
Arbeit festgelegt. Die begriffliche Unterscheidung zwischen funktionaler Sicherheit (engl.:
Safety) und IT-Sicherheit (engl.: Security) diente der Abgrenzung der weiteren Betrachtung:
Der Fokus liegt auf der Beurteilung der IT-Sicherheit, d.h. auf Schutzmaßnahmen für
SCADA-Systeme vor Angriffen aus der Systemumgebung.
 Primäre Schutzziele: Verfügbarkeit und Integrität
Leit- und Automatisierungssysteme dienen dem Zweck, verfahrenstechnische Prozesse

kontrolliert und sicher ablaufen zu lassen. Der Ausfall eines solchen Systems zieht in der
Regel wirtschaftlich negative Folgen für den Betreiber nach sich. Wichtiger ist allerdings,
dass aufgrund möglicher physischer oder chemischer Auswirkungen von Systemausfällen
oder -fehlfunktionen auch Schäden für Menschen, Umwelt und die Anlage folgen können. Im
Gegensatz zu IT-Systemen, die für Unternehmensgeschäftsprozesse im Büro- und
Serverumfeld zum Einsatz kommen, stehen bei Leit- und Automatisierungssystemen deshalb
die Schutzziele „Verfügbarkeit“ und „Integrität“ im Vordergrund. Andere Schutzziele, wie z.B.
Vertraulichkeit, Nichtabstreitbarkeit usw., bleiben unberücksichtigt, da sie für Leitsysteme in
der Regel keine oder nur geringe Bedeutung haben.
 Sicherheitsanalysen: schwierige Beurteilungsgröße „IT-Sicherheit“
Im Nachgang zu Sicherheitsereignissen für den Bereich leittechnischer Anlagen, wie z.B.

„Stuxnet“, zeigen Betreiber gesteigertes Interesse an der IT-Sicherheit ihrer Systeme. Vor
dem Hintergrund potentiell unternehmenskritischer Konsequenzen physischer und
kommerzieller Schäden im Falle von Fehlfunktionen oder Ausfällen der SCADA-Systeme
neigen Betreiber zunehmend zu Überprüfungen der IT-Sicherheit ihrer Systeme. Hierbei
stellt man allerdings fest, dass zur Beurteilung der Anlagen-IT-Sicherheit keine messbare
Größe „IT-Sicherheit“ bzw. eine handhabbare „Messvorschrift“ vorliegt. Derzeit existierende
Standards zur Beurteilung der Anlagen-IT-Sicherheit greifen daher auf die Ersatzgröße
Seite 226 von 262

„Risiko“ zurück. Diese Größe ist unbefriedigend hinsichtlich der zur Verfügung stehenden
Daten sowie den ableitbaren Handlungsoptionen für Anlagenbetreiber.
 Bedrohungen von Leit- und Automatisierungssystemen
Die vorgestellte Analysemethode der IT-Sicherheit von SCADA-Systemen beruht auf einem
dreiteiligen Bedrohungsmodell aus den Elementen:
 Angreifer
Für die weitere Herleitung der neuen Analysemethode wurden die drei Einzelelemente des
Bedrohungsmodells im Einzelnen betrachtet:
 Verzicht auf Berücksichtigung des Elementes „Angreifer“
Für das Analyseelement „Angreifer“ liegen den Betreibern leittechnischer Anlagen keine
Daten für eine auf Fakten basierende, reproduzierbare Ergebnisse liefernde
Analysemethode vor. Aus diesem Grund bleibt der Angreifer in den weiteren Überlegungen
zur Entwicklung einer neuen Analysemethode ausgeklammert.
 Verzicht auf Berücksichtigung des Elementes „Zielsystem (Schwachstellen)“
Es ließ sich zeigen, dass durch das Einspielen sicherheitsrelevanter Software-

Aktualisierungen hinsichtlich der Abschätzung vorhandener Software-Schwachstellen in den
Systemen keine signifikante Verbesserung der SCADA-IT-Sicherheit zu erreichen ist. Etwa
66% aller Software-Fehler erfahren über die gesamte Nutzungsdauer eines Leitsystems
hinweg keine Korrektur. Die Analyse (bekannter) Software-Schwachstellen für die
Sicherheitsbeurteilung liefert somit keinen nennenswerten Nutzen. Das Analyseelement
„Zielsystem“ mit der Perspektive der Systemschwachstellen bleibt deshalb aus der weiteren
Betrachtung ausgeschlossen.
 Fokussierung auf die Systemstruktur (Angriffspfad)
Aus dem dreistufigen Bedrohungsmodell „Angreifer – Zielsystem – Angriffspfad“ erweist sich

lediglich der Angriffspfad, d.h. die Verbindung vom Angreifer zum Zielsystem, als
analysierbares Element. Die Struktur des Leitsystems (Systemtopologie) muss deshalb im
Rahmen der Sicherheitsanalyse auf jene Pfade hin untersucht werden, über die sich
Angreifer Zugang zu Systemen verschaffen und Schwachstellen der Systeme ausnutzen
können (Angriffs- und Ausführungspfad). Außerdem: der Angriffspfad stellt das einzige
Seite 227 von 262

Element des Bedrohungsmodells dar, für das Betreiber über fundierte Informationen
verfügen.
 IT-Sicherheit als objektivierbare Systemeigenschaft
Die Beurteilung der IT-Sicherheit resultiert in einer Aussage hinsichtlich des

Sicherheitsstatus der Zielanlage. Idealerweise liefert diese Aussage eine operativ
handhabbare Größe auf Basis objektiver Fakten. Die Interpretation der IT-Sicherheit als
Eigenschaft des Gesamtsystems soll in das Analyseergebnis einfließen. Schließlich sollen
die grundlegenden Faktoren dieser finalen Aussage dem Betreiber der Zielanlage verfügbar
sein und ausschließlich auf Fakten der SCADA-Topologie beruhen. Dies ist Voraussetzung
für Analyseergebnisse mit Aussagen zur IT-Sicherheit mit eindeutigem Zielsystembezug und
unter Verzicht statistischer Daten anderer, nur bedingt vergleichbarer SCADA-Anlagen.
Nach der Diskussion wesentlicher Begriffe bzw. grundlegender Überlegungen zur IT-
Sicherheit leittechnischer Anlagen, standen gängige Analyseansätze zur Beurteilung der IT-
Sicherheit im Mittelpunkt der Betrachtung.
 Typische Analyseansätze zur Beurteilung der IT-Sicherheit
Die Beurteilung der IT-Sicherheit im Rahmen von Analyseverfahren erfolgt - wie bereits
erwähnt - in Ermangelung einer eindeutig bestimmbaren Größe „Sicherheit“ (im Sinne von
„security“) vielfach durch Ausweichen auf die Ersatzgröße „Risiko“. Im betrieblichen Umfeld
finden sowohl technisch-orientierte als auch betriebswirtschaftlich geprägte
Analysemethoden Anwendung zur Bestimmung jenes Risikos, das sich aus der Nutzung
leittechnischer Systeme im betrieblichen Kontext ergibt. Die Beurteilung der IT-Sicherheit im
Sinne einer Systemeigenschaft wird damit nur bedingt erreicht.
 Kritik der Konzepte und Vorgehensweisen
Als wesentliche Kritikpunkte der skizzierten Analysemethoden traten das Fehlen

statistischer Daten, der Einfluss subjektiver Einschätzungen auf die Analyseergebnissen, die
starke Unsicherheit hinsichtlich der Aussagekraft der Ergebnisse für die Betreiber und vor
allem die fehlende Aussage zum Anlagenstatus der IT-Sicherheit zutage.
 Kriterien eines praxisgerechten Beurteilungsansatzes
Aus der Kritik der dargestellten Analyseansätze lassen sich Kriterien für einen Analyseansatz
ableiten, der den Anforderungen der betrieblichen Praxis genügt: wesentliche
Randbedingungen sind Transparenz und Reproduzierbarkeit der Abbildung der
Seite 228 von 262

Anlageneigenschaften auf die Analyseergebnisse, Verzicht auf subjektive Einschätzungen

sowie automatisierbare Analyseschritte. Im Mittelpunkt der Analyse soll jedoch eine Aussage
über den Sicherheitsstatus der Zielanlage stehen.
 Teilautomatisierbare Analysemethode
Der skizzierte 5-stufige Analyseprozess liefert die notwendigen Fakten zur Beurteilung der
IT-Sicherheit der betrachteten Leittechnikanlage. Ausgehend von den Beschreibungen der
Angriffsszenarien und der Zielanlage läuft der Prozess vollautomatisch ab.
 Wiederverwendbare Beschreibung von Angriffsszenarien
Attack Trees dienen der Beschreibung der Angriffsszenarien. Diese Methode hat den Vorteil,
dass bei wiederholter Betrachtung der Bedrohungsrisiken nur die zusätzlichen, d.h. neuen
Bedrohungsrisiken zu erfassen sind. Die Datenerfassung der Angriffsszenarien ist beliebig
erweiterbar, sowohl hinsichtlich der Anzahl als auch des Detaillierungsgrades der
berücksichtigten Szenarien.
 Wiederverwendbare Beschreibung der Zielanlage
Desgleichen gilt für die Beschreibung der Leittechnikanlage für die automatisierte Analyse:
Lediglich Änderungen am betrachteten Zielsystem ziehen Änderungen der
Anlagenbeschreibung nach sich. Die Datenbeschaffung ist – soweit die Daten
systemtechnisch vorliegen – automatisiert abfragbar.
 Analyseergebnisse
In einem automatisierten Prozess liefert die vorgestellte Methode Anzahl und

Beschreibungen der ausführbaren Angriffsszenarien, sowie die Voraussetzungen, die der
Angreifer für erfolgreiche Angriffe hinsichtlich Zugangsmöglichkeit, Ausrüstung und
Kompetenzen zu erfüllen hat.
 Beurteilung der Analyseergebnisse
Die vorgestellte Analysemethode liefert faktenbasierte Aussagen über die untersuchte

Leittechnikanlage. Im Gegensatz zu den bekannten Analyseverfahren liefert die
vorgeschlagene Analysemethode Ergebnisse ohne Annahmen oder Spekulationen
unbekannten Wahrheitsgrades hinsichtlich der (in der Regel) unbekannten Angreifer. Das
Ergebnis resultiert ausschließlich aus der Verarbeitung von Fakten der gefundenen
Angriffsszenarien und der zu untersuchenden Zielanlage. Schließlich erlauben die
gewonnenen Ergebnisse, d.h. Anzahl und Art der kritischen Szenarien sowie die
Seite 229 von 262

Angriffsvoraussetzungen für Angreifer, Vergleiche zwischen Leittechnikanlagen anzustellen:

Unterschiede lassen sich eindeutig auf unterschiedliche Bedrohungssituationen oder
Ausprägungen der Leittechnikanlage zurückführen. Unbekannte Einschätzungen der
Auditoren erschweren die Vergleichbarkeit nicht, da sie keinen Eingang in die Ergebnisse
finden. Es lassen sich Vergleiche zwischen verschiedenen Anlagen zum gleichen Zeitpunkt
anstellen, wie auch Vergleiche zwischen den Zuständen einer Anlage zu verschiedenen
Zeitpunkten.
 Randbedingungen einer neuen IT-Sicherheitsmetrik für SCADA-Systeme
Für eine IT-Sicherheitsmetrik, die die Abbildung der IT-Sicherheit der Leittechniksysteme
leistet, gelten folgende, wesentliche Randbedingungen:
 die Metrik muss eine Aussage zur Sicherheit der Zielanlage liefern
 die Transparenz der Abbildung von Basisgrößen auf die Sicherheitsmetrik muss
gegeben sein
 die Nachvollziehbarkeit der Metrikbildung ist sicherzustellen
 die Konsistenz der Metrikbildung über die Zeit muss gewährleistet sein
 die Struktur der Zielanlage muss in die Metrik einfließen
 die Metrik muss auch für singulär Anlagen (Einzelanlagen) anwendbar sein
 Inhalte einer neuen IT-Sicherheitsmetrik für SCADA-Systeme
Diese Randbedingungen bestimmen den Vorschlag einer IT-Sicherheitsmetrik für

Leittechniksysteme. Die Metrik untergliedert sich in einen statischen und einen dynamischen
Metrik-Bereich. Die vorgeschlagene Metrik liefert für Leittechniksysteme die Visualisierung
des IT-Sicherheitszustandes unter Berücksichtigung:
 des Sicherheitsniveau der Zielanlage
 der Struktur und Bestandteile der Zielanlage
 der Anfälligkeit der Teilsysteme
 der Risikoakzeptanz des Betreibers
 des aktuellen Systemstatus
 der zeitlichen Veränderung über wiederkehrende Anlagenanalysen hinweg
Seite 230 von 262

Der statische Metrik-Bereich liefert die Informationen hinsichtlich der Sicherheit der
Zielanlage zum Zeitpunkt der Analyse und umfasst die folgenden Sicherheitsaspekte:
 Sicherheitsniveau, d.h. eine numerische Aussage über die Anzahl möglicher

Angriffsvarianten gegen die betrachtete Anlage
 SCADA-Angriffsoberfläche, d.h. eine Aussage über die Vielfalt mit der Varianten der
Angriffsszenarien in der Zieltopologie umsetzbar sind
 kritische Angriffspunkte, d.h. die Anzahl potentieller Angriffsszenarien gegen die

einzelnen Teilsysteme der Leittechnikanlage
 Kritikalität der Angriffsmuster, d.h. Bewertung der möglichen Angriffsszenarien

anhand der Angriffsvoraussetzungen auf Basis der Risikoakzeptanz des Betreibers
 Relative Kritikalität der Angriffsmuster, d.h. der Anteil der potentiellen

Angriffsszenarien, die der der Risikoakzeptanz des Betreibers nicht genügen
Die Fortschreibung der statischen Metrik-Daten aus wiederkehrenden Anlagenanalysen

liefert den zeitlichen Verlauf der IT-Sicherheit der Leittechnikanlage, d.h. den dynamischen
Informationsbereich der Sicherheitsmetrik.
Die Beachtung der skizzierten Randbedingungen, d.h. die Aussagen zur Systemsicherheit,
die Transparenz und Nachvollziehbarkeit der Abbildung, stellen die Konsistenz der
Sicherheitsmetrik über die Zeit hinweg sicher.
 Vergleich der vorgeschlagenen Analysemethode mit einer etablierten Methode
Zentrale Defizite etablierter Analysemethoden (anhand eines Standard-basierten Beispiels)

sind aus Sicht des Verfassers die Beeinflussung der Analyseergebnisse durch subjektive
Einschätzungen. Solche bewussten oder unbewussten Annahmen der Auditoren erschweren
die Reproduzierbarkeit und Vergleichbarkeit der Ergebnisse. Des Weiteren ist die
Aussagekraft von Ergebnisse der Art „Risiko = Moderate“ oder „Risiko = 43.7%“ nur bedingt
hilfreich. Schließlich bedeutet jedes Angriffsrisiko > 0%, dass jederzeit mit einem Angriff zu
rechnen ist. Interview-orientierte Methoden erschweren die Automatisierbarkeit etablierter
Analyseansätze. Konkrete Handlungsoptionen ergeben sich aus den Analyseergebnissen in
der Regel nicht – insbesondere bei Methoden, die nicht für Leitechnikanlagen konzipiert sind.
Seite 231 von 262

Die vorgestellte Szenario-basierte Analyse verfügt im Gegensatz dazu über folgende

Vorteile:
 Die Methode basiert ausschließlich auf Anlagenfakten und Benutzerangaben

(Betreiber-Risikovektor), die im System hinterlegt und damit eindeutig dokumentiert
sind. Es sind keine individuellen Einschätzungen notwendig.
 Die Methode liefert konkrete, d.h. numerische Aussagen zum Sicherheitsstatus der
Zielanlage.
 Die Methode liefert konkrete Aussagen hinsichtlich der Anlagenschwachpunkte, d.h.

der besonders gefährdeten Anlagenteile.
 Bei technologischen Änderungen des Zielsystems lässt sich die Faktenbasis in

einfacher Weise anpassen.
 Die Methode liefert reproduzierbare Ergebnisse.
Die Gegenüberstellung der Ergebnisse einer Standard-basierten Methoden und dem hier
vorgestellten Analysemethode zeigt, dass die Standard-basierte Analyse allgemeine
Aussagen zum Risiko eines Cyber-Angriffes liefert. Wesentliche Defizite sind die
individuellen Einschätzungen, die der Analyse zugrunde liegen, sowie die Frage, welche
Aussagekraft die resultierenden Risikowerte überhaupt haben.
Demgegenüber liefert die Szenario-basierte Methode reproduzierbare Ergebnisse zur

betrachteten Zielanlage. Der Betreiber erhält konkrete Aussagen zu Schwachstellen der
Anlage.
Ausblick
Das in dieser Arbeit vorgestellte Analysemodell zur Beurteilung der IT-Sicherheit

leittechnischer Anlagen geht von der Beschreibung der Angriffsszenarien und der Zielanlage
aus und nimmt auf dieser Datenbasis eine automatisierte Analyse vor, deren Ergebnisse in
eine neue IT-Sicherheits-Metrik einfließen.
Während die Analyse sowie die Metrikbildung automatisch ablaufen, sind die Daten zur
Anlagenbeschreibung – je nach Zielsystemausprägung – teilweise manuell und teilweise
automatisiert aus den Leittechniksystemen und -komponenten auslesbar. Hinsichtlich Anzahl
und Art der Systeme haben Leittechnikanlagen einen eher statischen Charakter. Der
Seite 232 von 262

manuelle Aufwand bleibt damit grundsätzlich überschaubar und beschränkt sich bei
Wiederholungsanalysen auf die Änderungen an der Zielanlage seit der Analyse.
Wesentlicher Anteil der manuell zu erbringenden Arbeit ist die Beschreibung der
Angriffsszenarien. In der vorliegenden Arbeit wurde hierfür auf die Methode „Attack Tree”
zurückgegriffen.
Im Rahmen der Analyse kommen somit jene Angriffsszenarien in Betracht, die vom
Analyseteam mittels Attack Trees gefunden und beschrieben werden. Diese Methode stellt
zwar einen systematischen Ansatz zur Zusammenstellung anlagenspezifischer
Angriffsszenarien dar, jedoch bleiben weitere Quellen generischer Angriffsvarianten
unberücksichtigt. Eine mögliche Quelle generischer Angriffsszenarien stellen beispielsweise
die durch CERT-Organisationen publizierten Software-Schwachstellen dar. Diese
Publikationen enthalten in der Regel generische Methodenbeschreibungen zur Ausnutzung
der gemeldeten Software-Schwachstellen.
Als Erweiterung der in dieser Arbeit dargestellten Analysemethode ist es hilfreich, auch
andere Quellen generischer Angriffsszenarien zu berücksichtigen. Auf Basis der
umfassenden Beschreibung der SCADA-Anlage sollte eine Methode entwickelt werden, die
die Abbildung generischer Methodenbeschreibungen aus veröffentlichten Software-
Schwachstellen auf die Zielanlage ermöglicht. Zu diesem Zweck wäre es notwendig, einen
Algorithmus zu entwickeln, der aus den veröffentlichten Methodenbeschreibungen die
notwendigen Fakten und Randbedingungen im Sinne der Voraussetzungen „Equipment“,
„Zugang“ und „Knowhow“ gemäß Kapitel 5.2 extrahiert. Da die publizierten Software-
Schwachstellen sich auf dezidierte Software-Anwendungen (Name, Version) beziehen, wäre
das in der vorliegenden Arbeit vorgeschlagene Anlagen-Datenmodell um diese beiden
Datenelemente zu erweitern. Informationen über die installierten Software-Anwendungen
lassen sich in der Regel automatisiert aus den Zielsystemen auslesen.
Nachdem die beiden Voraussetzungen
- Extraktions-Algorithmus für Voraussetzungen in Software-Schwachstellenpublikationen und
- Erweiterung des beschreibenden Leittechnikanlagendatenmodells
erfüllt sind, lassen sich mögliche Konsequenzen publizierter Meldungen über Software-
Schwachstellen automatisiert gegen eine individuelle Zielanlage überprüfen.
Seite 233 von 262

Diese Prüfungen liefern Ergebnisse im Sinne der in dieser Arbeit vorgeschlagenen Methodik:
1) Überführung der generischen Schwachstellenausnutzung in eine sogenannte "kritische

Angriffsvariante", falls unter Berücksichtigung der Anlagenbeschreibung die betreffende
Schwachstelle prinzipiell ausnutzbar ist.
2) Identifikation der generischen Schwachstellenausnutzung als "irrelevant", falls die

generische Angriffsmethode gegen die betrachtete Zielanlage nicht ausnutzbar ist.
3) Berücksichtigung der schwachstellen-bedingten kritischen Angriffsszenarien im Rahmen

der fortlaufenden Aktualisierung der Anlagen-Sicherheitsmetrik.
Die Erweiterung der vorgeschlagenen Analysemethode um zusätzliche Quellen generischer

Angriffsszenarien ergibt folgende Vorteile:
- Erweiterung der Menge der berücksichtigten Angriffsszenarien um Varianten aus externen

Quellen
- Integration veröffentlichter Software-Schwachstelleninformationen in die anlagenspezifische

Leittechnik-IT-Sicherheitsmetrik
- Unterstützung der Ableitung eventuell notwendiger Maßnahmen zum Schutz der

Leittechnikanlage und damit Verbesserung des Anlagen-IT-Sicherheitszustandes.
Seite 234 von 262

Anhang
10 Verzeichnisse
10.1 Literaturverzeichnis
Anbalagan, Prasanth und Vouk, Mladen . 2009. Towards a Unifying Approach in

Understanding Security Problems. [Online] 2009.
http://www4.ncsu.edu/~panbala/issre09.pdf.
Baker, Arnold B., et al. 2002. A Scalable Systems Approach for Critical Infrastructure
Security. [Online] 2002. http://prod.sandia.gov/techlib/access-control.cgi/2002/020877.pdf.
Berinato, Scott. 2005. A Few Good Information Security Metrics. [Online] 2005.
http://www.csoonline.com/article/220462/a-few-good-information-security-metrics.
Bilge, Leyla; Dumitra, Tudor. 2012. Before we knew it: An empirical study of zero-day
attacks in the real world. ACM Conference on Computer and Communications Security.
Raleigh, NC : s.n., 2012. S. 833–844.
Bleikertz, Sören. 2010. Automated Security Analysis of Infrastructure Clouds. [Online] 2010.
http://openfoo.org/research/master.pdf.
Bourgue, Romain. 2012. Introduction to Return on Security Investment. [Online] 2012.

http://www.enisa.europa.eu/activities/cert/other-work/introduction-to-return-on-security-
investment/at_download/fullReport.
BSI. KRITIS. [Online] Bundesamt für Sicherheit in der Informationstechnik.

http://www.kritis.bund.de/SubSites/Kritis/DE/Servicefunktionen/Glossar/Functions/glossar.ht
ml?lv2=4968594.
Byres, Eric J., Franz, Matthew und Miller, Darrin . 2004. The Use of Attack Trees in
Assessing Vulnerabilities in SCADA Systems. [Online] 2004.
http://www.tofinosecurity.com/downloads/14.
Clark, Richard A. und Knacke, Robert K. 2011. World Wide War. Hamburg : Hoffmann &
Campe, 2011. S. 141.
Clocksin, William F. und Mellish, Christopher S. 2003. 5. Berlin, Heidelberg : Springer,

2003.
Corbet, Jonathan, Kroah-Hartman, Greg und McPherson, Amanda. 2013. [Online] 2013.
www.linuxfoundation.org/publication/linux-foundation/who-writes-linux-2013.
Seite 235 von 262

Anhang
—. 2012. Linux Foundation. [Online] 2012. go.linuxfoundation.org/who-writes-linux-2012.
Cornish, Paul , et al. 2011. Cybersecurity and the UK's Critical National Infrastructure.
[Online] 2011.
http://www.chathamhouse.org/sites/default/files/public/Research/International%20Security/r0
911cyber.pdf.
Dickman, Frank. 2008. Hacking the industrial network. [Online] 2008.

http://www.isa.org/FileStore/Intech/WhitePaper/Hacking-the-industrial-network-
USversion.pdf.
DKE. 2014. Kernkraftwerke – Leittechnische Systeme – Anforderungen an die IT-

Sicherheitsplanung für rechnerbasierte Systeme. DKE Deutsche Kommission Elektrotechnik
Elektronik Informationstechnik im DIN und VDE. s.l. : IEC, 2014. S. 107. DIN IEC 62645
(VDE 0491-3-7).
Dobson, J.E. und Randell, B. 2001. Building reliable secure computing systems out of
unreliable insecure components. Computer Security Applications Conference, ACSAC 2001.
2001. S. 164 - 173.
Eckert, Claudia. 2008. IT-Sicherheit. München : Oldenbourg Wissenschaftsverlag GmbH,

2008.
Espedalen, Jeanne H. 2007. Attack Trees Describing Security in Distributed Internet-

Enabled Metrology. [Online] 2007. http://idtjeneste.nb.no/URN:NBN:no-bibsys_brage_4218.
Eusgeld, et al. 2008. Dependability Matrix. [Hrsg.] Irene Eusgeld, Felic C. Freiling und Ralf
Reussner. Berlin, Heidelberg : Springer, 2008. Dagstuhl Seminar, 30.10. - 01.11.2005.
Foley, Simon N. und Fitzgerald, William M. 2011. Management of Security Policy

Configuration using a Semantic Threat Graph Approach. [Online] 2011.
http://www.cs.ucc.ie/~simon/pubs/jcs2011a.pdf.
Fox, Dirk. 2011. Betriebswirtschaftliche Bewertung von Security Investments in der Praxis.
[Hrsg.] Secorvo Security Consulting GmbH. Datenschutz und Datensicherheit, Ausgabe
01/2011. 2011.
Gillils. 2013. Security as an Emergent System Property. MIT Geospatial Data Center.
[Online] 2013. Blog. http://cybersecurity.mit.edu/2013/09/security-as-an-emergent-system-
property/.
Gritsai, Gleb, et al. 2012. SCADA Safety in Numbers. [Online] 2012.

www.ptsecurity.com/download/SCADA_analytics_english.pdf.
Seite 236 von 262

Anhang
Gutbrodt, Felix. 2007. Automatisierte, systematische Evaluierung der IT-Sicherheit auf der
Feldebene von Automatisierungssystemen. Institut für Automatisierungs- und
Softwaretechnik (IAS), Universität Stuttgart. 2007. VDI-Bericht 1980.
Haimes, Yacov Y. 2009. Risk Modeling, Assessment, and Management. 3. Hobocken : John
Wiley & Sons, 2009.
Haimes, Yakov Y. 2009. Risk Modeling, Assessment, and Management. Hoboken : John
Wiley & Sons, 2009.
Hayden, Lance. 2010. IT Security Metrics. New York : The McGraw-Hill Companies, 2010.
ICS-CERT. 2012. ICS-Cert Incident Response Summary Report 2009-2011. [Online] 2012.
https://ics-cert.us-cert.goc/pdf/ICS-CERT_Incident_Response_Summary_Report_09_11.pdf.
Illingworth (Edt.), Valerie. 1991. Dictionary of Computing. 3. Oxford : Oxford University

Press, 1991.
ISA-62443-1-1. 2014. ISA99 Master Glossary. [Online] 2014. [Zitat vom: 14. 05 2014.]
http://isa99.isa.org/ISA99%20Wiki/Master-Glossary.aspx.
Iversen, Wes. 2004. Hackers Step Up SCADA Attacks. [Online] 2004.

www.automationworld.com/webonly-898.
Juneja, Deepti , Arora, Kavita und Duggal, Sonia . 2011. Developing Security Metrics for
Information Security Measurement System. [Hrsg.] Manav Rachna International University,
Faridabad Faculty of Business and Computer applications. International Journal of Enterprise
Computing and Business Systems. 07 2011, Bd. 1, 2.
—. 2011. Developing Security Metrics for Information Security Measurement System.

International Journal of Enterprise Computing and Business Systems. 2011, Bd. 1, 2.
Kaeo, Merike. 2004. Designing Network Security. Inianapolis : Cisco Systems Inc., 2004.
Knapp, Eric D. 2011. Industrial Network Security. Waltham, MA : Elsevier, 2011.
Kraft, Hans-Richard. 2015. A Fact-driven Security Assessment Methodology for SCADA

Systems in Operational Environments. Open Journal of Information Security and
Applications. 2015, Bd. 1, 2.
—. 2013. SCADA-Systeme & -Angriffe - Methodenvalidierung. 2013.
—. 2012. SCADA-Systeme & -Angriffe - semi-automatisches Analyseverfahren. 2012.

Quartalsbericht.
—. 2012. SCADA-Systeme & -Angriffe: Bestimmung der IT-Sicherheit. 2012.
Seite 237 von 262

Anhang
—. 2012. SCADA-Systeme & -Angriffe: Musterimplementierung des Verfahrens zur

Bestimmung der IT-Sicherheit. 2012.
Kroll, Lars; Peters, Alexander. 2012. Heute attackieren Cyberkriminelle mit System.
Karlsruhe : Symantec, 2012.
Masera, Marcelo und Fovino, Igor Nai. 2010. Security Metrics for Cyber Security
Assessment and Testing. Security Technology Assessment Unit. Ispra, Italy : Joint Research
Centre of the European Commission, 2010.
Mauw, Sjouke und Oostdijk, Martijn. Foundations of Attack Trees. [Online]

http://www.win.tue.nl/~sjouke/publications/papers/attacktrees.pdf.
McIntyre, Annie , Becker, Blair und Halbgewachs, Ron . 2007. Security Metrics for
Process Control Systems. [Online] 2007. http://energy.sandia.gov/wp/wp-
content/gallery/uploads/McIntyre-SAND2007-2070P.pdf.
McQuee, Miles A., et al. 2006. Quantitative Cyber Risk Reduction Estimation Methodology
for a Small SCADA Control System. Proceedings of the 39th Hawaii International
Conference on System Sciences. 2006.
Microsoft. 2014. MS Windows XP - Support-Ende. [Online] Microsoft, 2014.

https://www.microsoft.com/de-de/windows/xp/.
Mohamed Almorsy, John Grundy, Amani S. Ibrahim. 2013. Automated Software

Architecture Security Risk Analysis using Formalized Signatures. Centre for Computing and
Engineering Software Systems, Swinburne University of Technology, Melbourne, Australia.
ICSE 2013, San Francisco, USA : s.n., 2013.
Mohammad Salim Ahmed, Ehab Al-Shaer, Mohamed Taibah, Latifur Khan. 2010.
Objective Risk Evaluation for Automated Security Management. Journal of Network and
Security Management. 2010.
Moily, Sowmya . 2011. Security for Critical Infrastructures: Security Metrics, Risk
Assessment and Standards. [Online] 2011.
http://www.academia.edu/652038/Security_for_Critical_Infrastructures_Security_Metrics_Ris
k_Assessment_and_Standards.
Moore, Andrew P., Ellison, Robert J. und Linger, Richard C. 2001. Attack Modeling for
Information Security and Survivability. [Online] 2001.
http://www.cert.org/archive/pdf/01tn001.pdf.
Seite 238 von 262

Anhang
National Institute of Standards and Technology. National Vulnerability Database. [Online]

http://web.nvd.nist.gov/view/statistics.
Nicholson, A., et al. 2012. SCADA security in the light of Cyber-Warfare. Journal of
Computer & Security. 2012, 31, S. 418 - 436.
NIST. National Vulnerability Database. [Online] [Zitat vom: 11. 06 2014.]

http://web.nvd.nist.gov/view/vuln/statistics.
NIST-SP800-30. 2012. Risk Management Guide for Information Technology Systems.

[Online] Rev. 1, 2012. NIST SP 800-30.
Patel, Sandip C., Graham, James H. und Ralston, Patricia A.S. 2008. Quantitatively
assessing the vulnerability of critical information systems: A new method for evaluating
security enhancements. [Hrsg.] Elsevier. International Journal of Information Management.
2008, Bd. 28, S. 483 - 491.
Payne, Shirley C. 2006. A Guide to Security Metrics. [Online] 2006.

http://www.sans.org/reading_room/whitepapers/auditing/guide-security-metrics_55.
Richardson, Robert. 2007. CSI Survey 2007: The 12th Annual Computer Crime and
Security Survey. [Online] 2007. www.GoCSI.com.
Rid, Thomas. 2013. Cyber War Will Not Take Place. Oxford : Oxfoed University Press,
2013.
Rieger, Frank. 2010. Der digitale Erstschlag ist erfolgt. Frankfurter Allgemeine Zeitung. 18.
02 2010.
Savolo, Reijo. 2008. A Novel Security Metrics Taxonomy for R&D Organisations.
Johannesburg, RSA : ISSA, 2008.
—. 2007. Towards a Security Metrics Taxonomy for the Information and Communication
Technology Industry. Oulu, Finland : IEEE, 2007.
Schneier, Bruce. 1999. Schneier on Attack Trees (I). [Online] 1999.

http://www.ddj.com/184411129.
—. 1999. Schneier on Attack Trees (II). [Online] 1999.

http://web.eecs.utk.edu/~dunigan/cns04/attacktrees.pdf.
—. 2007. Why the Human Brain Is a Poor Judge of Risk. [Online] 2007.
https://www.schneier.com/essay-162.html.
Seite 239 von 262

Anhang
Sonnenreich, Wes, Albanese, Jason und Stout, Bruce. 2006. Return On Security
Investment (ROSI) - A Practical Quantitative Model. Journal of Research & Practice in
Information Technology. Vol. 38, 2006, 1, S. 45 - 56. SageSecure.
Sumner Lemon. 2007. Average zero-day bug has 348-day lifespan, exec says. [Online]
2007. http://www.computerworld.com/article/2542245/security0/average-zero-day-bug-has-
348-day-lifespan--exec-says.html.
Symantec. 2015. Internet Security Threat Report 2015. 2015.
Tsang, Rose. 2010. Cyberthreats, Vulnerabilities and Attacks on SCADA Networks. [Online]
2010. gspp.berkeley.edu/iths/Tsang_SCADA%20Attacks.pdf.
Werner, Matthias. 2007. Fehler in Software. [Online] 2007. http://osg.informatik.tu-

chemnitz.de/lehre/old/ss07/vs/10-softwareft.pdf.
Wetter, Dirk und Koch, Werner. Passivität heißt, sich abzufinden - Interview mit Phil
Zimmermann. iX. 11.2013, S. 106f.
Wikipedia. 2011. Attack tree. [Online] 2011. http://en.wikipedia.org/wiki/Attack_tree.
—. 2015. Source lines of code. [Online] 2015. http://de.wikipedia.org/wiki/Linux_(Kernel).
Zahid Anwar, Ravinder Shankesi, Roy. H. Campbell. 2008. Automatic Security

Assessment of Critical Cyber-Infrastructures. Dependable Systems & Networks with FTCS
and DCC. Anchorage, USA : IEEE, 2008. S. 366-375.
10.2 Abbildungsverzeichnis
Abbildung 1: Typische Funktionsebenen einer Leittechnikanlage ........................................................ 17
Abbildung 2: Schematische Darstellung einer Leittechnikanlage ......................................................... 18
Abbildung 3: Technologietrends (Quelle: Verfasser)............................................................................. 22
Abbildung 4: Safety vs. Security ............................................................................................................ 32
Abbildung 5: Bedrohungsmodell............................................................................................................ 36
Abbildung 6: Übersicht über die vorgeschlagene Analysemethode ...................................................... 67
Abbildung 7: Generisches Leittechnikmodell ........................................................................................ 75
Abbildung 8: Datenflussschema im generischen Leittechnikmodell ..................................................... 78
Abbildung 9: Datenhaltung des generischen Leittechnikmodells .......................................................... 79
Abbildung 10: Beispiel eines Attack Tree für ein einfaches Angriffsszenario ....................................... 83
Seite 240 von 262

Anhang
Abbildung 11: Ausschnitt eines Attack Tree für ein HMI-Client-System ............................................... 89
Abbildung 12: Beziehungen zwischen Angriffsszenarien und den Voraussetzungen .......................... 90
Abbildung 13: Angriffsszenarien gegen HMI-Clients / Systemeigenschaften (Ausschnitt) ................... 98
Abbildung 14: Angriffsszenarien gegen HMI-Clients / Angreifer-Voraussetzungen (Ausschnitt) ......... 99
Abbildung 15: Beispielschema einer leittechnischen Anlage .............................................................. 100
Abbildung 16: Darstellung der Netzwerkstruktur des Beispiels ........................................................... 101
Abbildung 17: Angriffe gegen SCADA-Systeme nach (Nicholson et.al. 2012) ................................... 121
Abbildung 18: Schwachstellen in SCADA-Systemen .......................................................................... 122
Abbildung 19: ICS-CERT-Angaben zu Sicherheitsvorfällen (2009 - 2011) ......................................... 123
Abbildung 20: ICS-CERT-Angaben zu Sicherheitsvorfällen je Sektor (2011) ..................................... 123
Abbildung 21: Übersicht des semi-automatischen Analyseablaufes .................................................. 164
Abbildung 22: Datentechnisches Analyseschema .............................................................................. 165
Abbildung 23: Übersicht Programmschema ........................................................................................ 166
Abbildung 24: Kritische Szenario-Daten (Ausschnitt) ......................................................................... 168
Abbildung 25: Import der PROLOG-Ergebnisse (Ausschnitt) ............................................................. 171
Abbildung 26: Criteria_Equipment (Ausschnitt)................................................................................... 173
Abbildung 27: Criteria_Knowhow (Ausschnitt) .................................................................................... 174
Abbildung 28: Criteria_Location (Ausschnitt) ...................................................................................... 176
Abbildung 29: Metrik-Daten mittels DB-View "Overview_Metric" (Ausschnitt) .................................... 178
Abbildung 30: Anlagentopologie (phys.) .............................................................................................. 180
Abbildung 31: Anlagentopologie (log.) ................................................................................................ 181
Abbildung 32: Risikoanalyseprozess gemäß NIST SP800-30 (Quelle: NIST) .................................... 183
Abbildung 33: Standard-basierte Bedrohungsszenarien (Template) .................................................. 203
Abbildung 34: Bedrohungsrelevanz (Template) .................................................................................. 204
Abbildung 35: Eintrittswahrscheinlichkeiten (Template) ...................................................................... 207
Abbildung 36: Schadensklassifikation (Template)............................................................................... 209
Abbildung 37: Bestimmung des Gesamtrisiko (Template) .................................................................. 211
Abbildung 38: Analyseergebnis gemäß Standard-Methode (Ausschnitt) ........................................... 212
Abbildung 39: Ergebnis "Sicherheitsniveau" (Beispielanlage) ............................................................ 215
Seite 241 von 262

Anhang
Abbildung 40: Ergebnis "SCADA-Angriffsoberfläche" (Beispielanlage) .............................................. 216
Abbildung 41: Ergebnis "Kritische Angriffspunkte" (Beispielanlage) ................................................... 216
Abbildung 42: Ergebnis "Kritikalität" (Beispielanlage) ......................................................................... 218
Abbildung 43: Ergebnis "Sicherheitsniveau / dynamisch" (Beispielanlage) ........................................ 219
Abbildung 44: Ergebnis "SCADA-Angriffsoberfläche / dynamisch" (Beispielanlage) .......................... 219
Abbildung 45: Ergebnis "Kritische Angriffspunkte / dynamisch" (Beispielanlage) .............................. 220
Abbildung 46: Ergebnis "Kritikalität / dynamisch" (Beispielanlage) ..................................................... 220
Abbildung 47: Implementierung ........................................................................................................... 249
Abbildung 48: Erfassung von Konfigurationsdaten (Beispiel) ............................................................. 251
Abbildung 49: Datenbankoberfläche zum Import / Export von PROLOG-Daten ................................ 254
Abbildung 50: Tabellenansicht Szenario-Daten (Beispiel) .................................................................. 255
10.3 Abkürzungsverzeichnis
AS Automation system Automatisierungssystem
ES Engineering system Projektierungssystem
HMI Human machine interface system Bedien- und Beobachtungssystem
KKW --- Kernkraftwerk
NVD National Vulnerability Database
PLC Process logic controller Automatisierungsgerät
SCADA Supervisory control and data acquisition Leittechniksystem
Seite 242 von 262

Anhang
11 Anhang
A1 Abschätzung Schwachstellen eines Rechnersystems

In diesem Kapitel soll betrachtet werden, welche Rückschlüsse sich hinsichtlich der
vermutlich vorhandenen Software-Schwachstellen – und damit dem Sicherheitsstatus des
betrachteten Systems – ziehen lassen. Als Methodenbeispiel dient der Linux-Kernel (2.6 –
3.2), da hierfür im Gegensatz zu kommerziellen Software-Produkten („closed source“)
hinreichende Daten vorliegen.
Laut (Wikipedia, 2015) besteht der Linux-Kernel (Version: 3.2) aus 14.998.651 Zeilen
Quellcode (Source lines of code, SLOC):
nSLOC = 14.998.651 SLOC [1]
(Werner, 2007) gibt für industrielle Software-Produkte eine Forderung von 0.3 … 2 Fehler je
100 Zeilen Quellcode an. In der Realität ist 1 Fehler je 100 Zeilen (eSLOC) Quellcode typisch:
eSLOC = 1/100 Fehler pro SLOC [2]
Daraus ergibt sich für den Linux-Kernel (V 3.2) folgende vermutete Anzahl von Fehlern (nE)
im Quellcode:
nE = nSLOC * eSLOC [3]
nE = 14.998.651 SLOC * 0.01 Fehler je SLOC = 149.986 Fehler
Auf Basis von (Corbet, et al., 2012) und (Corbet, et al., 2013) ergeben sich für die Linux-
Kernel-Versionen 2.6 … 3.2 folgende Daten hinsichtlich „Total Updates“ und „Fixes“ (=
Anzahl der korrigierten Fehler):
Seite 243 von 262

Anhang
Datum Version Total Updates Update p.a. Fixes Fixes p.a.

2005-03-02 2.6.11 12 79
2005-05-17 2.6.12 6 30 47 254
2005-08-28 2.6.13 5 39
2005-10-27 2.6.14 7 89
2006-01-02 2.6.15 7 103
2006-03-19 2.6.16 62 991
98 1688
2006-06-17 2.6.17 14 177
2006-09-19 2.6.18 8 232
2006-11-29 2.6.19 7 185
2007-02-04 2.6.20 21 447
2007-04-25 2.6.21 7 64 155 1270
2007-07-08 2.6.22 19 366
2007-10-09 2.6.23 17 302
2008-01-24 2.6.24 7 243
2008-04-16 2.6.25 20 106 481 3535
2008-07-13 2.6.26 8 321
2008-10-09 2.6.27 61 1879
2008-12-24 2.6.28 10 611
2009-03-23 2.6.29 6 379
2009-06-09 2.6.30 10 87 431 4944
2009-09-09 2.6.31 14 819
2009-12-02 2.6.32 57 3315
2010-02-24 2.6.33 20 1877
2010-05-15 2.6.34 10 48 1323 5496
2010-08-01 2.6.35 14 1609
2010-10-20 2.6.36 4 687
2011-01-04 2.6.37 6 592
2011-03-14 2.6.38 8 634
122 3736
2011-05-18 2.6.39 4 441
2011-07-21 3.0 94 3764
2011-10-24 3.1 10 694
2012-01-04 3.2 50 50 3943 389
Tabelle 12: Linux-Kernel Update-Daten
Aus der Gruppierung in Jahresscheiben lassen sich folgende Mittelwerte ableiten:
Mittlere Anzahl der Updates p.a.: 75,6
Mittlere Anzahl der Fixes p.a.: 3406,9
Daraus ergeben sich
nP = 75 Updates p.a. [4]
nF = 45 Fixes per Update [5]
Seite 244 von 262

Anhang
Die typische Nutzungsdauer eines Serverbetriebssystems in Leitsystemen kann auf ca. 15

Jahre geschätzt werden:
tSYS = 15 a
Während dieser Systemnutzungsdauer beseitigten die in diesem Zeitraum veröffentlichten

Updates – auf Basis der oben abgeleiteten Kennzahlen – folgende Fehleranzahl (eF):
eF = nP * nF * tSYS [6]
eF = 75 Updates/a * 45 Fixes/Update * 15 a = 50.625 Fehler
Das Einspielen von 1.125 Updates (Patches) über die Systemnutzungsdauer hinweg
reduziert die Anzahl der vermutlichen Systemfehler somit um 50.625 Fehler. Angesichts der
vermuteten Gesamtzahl von Fehler im Quellcode von 149.986 Fehlern ergibt sich eine
Reduzierung der ursprünglichen Produktfehlerzahl zu:
qred = eF / nE [7]
qred = 50.625 Fehler / 149.986 Fehler = 33,7 %
Die regelmäßige Aktualisierung des Linux-Kernels mit 1 … 2 Patches pro Woche über einen
Zeitraum von 15 Jahren belässt vermutlich 66,3 % (= 99.361 Fehler) der ursprünglichen, bei
erstmaliger Auslieferung vorhandenen Fehlern im Produkt.
Im Rahmen dieser Abschätzung der über die gesamte Lebensdauer des Betriebssystems
vorhandenen Software-Fehler blieben zwei Aspekte unberücksichtigt, die die Gesamtzahl
der in einem Computersystem vorhandenen Software-Fehler zusätzlich steigern:
1. Fehlerkorrekturen (Updates) bestehen ebenfalls aus prinzipiell fehlerhafter Software.

D.h. durch das Aktualisieren des Zielsystems mit Updates / Patches / Hotfixes etc.
werden dem System neue Fehler hinzugefügt.
2. Das Leitsystem besteht außer dem Betriebssystem noch aus weiteren Software-
Komponenten, wie z.B. Datenbanken, Browser, Middleware (Java) sowie der
eigentlichen Leitechnikanwendung. Auch diese Software-Produkte sind fehlerhaft und
erhöhen die Zahl der Fehler im Gesamtsystem.
Es ist jedoch zu berücksichtigen, dass nicht alle Software-Fehler sicherheitsrelevant (im

Sinne von „Security“) sind. Die Anzahl der vorhandenen sicherheitsrelevanten Fehler, d.h.
Software-Schwachstellen kann man jedoch wie folgt abschätzen.
Seite 245 von 262

Anhang
Auf Basis der oben eingeführten Anzahl der jährlichen Software-Updates für den Linux-
Kernel
nP = 75 Patches p.a.
sowie der Abschätzung für die Anzahl der korrigierten Fehler je Patch (nF)
nF = 45 gefixte Fehler je Patch
ergibt sich die Anzahl der korrigierten Fehler p.a. zu:
nkF = nP * nF = 3.375 korrigierte Fehler p.a. [8]
Diese Anzahl der korrigierten Fehler nkF kann man auch als die Anzahl der bekannten Fehler
auffassen – unabhängig von der Sicherheitsrelevanz.
Diese Anzahl der bekannten Fehler lässt sich die Anzahl der bekannten Software-
Schwachstellen gegenüberstellen. Diesem Zweck soll die National Vulnerability Database
(NIST) dienen. Für das betrachtete Betriebssystem gibt die NVD für die Zeit von 1997 bis
2014 folgende gemeldeten Schwachstellen an:
Jahr Schwachstellen Quelle:

http://web.nvd.nist.gov/view/vuln/statistics-
1997 1 results?adv_search=true&cves=on&query=linux+kernel
1998 2
1999 5
2000 6
2001 21
2002 15
2003 20
2004 49
2005 136
2006 96
2007 76
2008 82
2009 109
2010 129
2011 86
2012 114
2013 200
2014 85
Tabelle 13: Schwachstellen des Linux-Kernel (Quelle: NVD)
Seite 246 von 262

Anhang
Die Mittelwertbildung über die Daten von 2005 bis 2012 ergibt die Anzahl der
bekanntgewordenen Schwachstellen p.a.
nkV = 103,5 Schwachstellen p.a. [9]
Aus den beiden Faktoren für die bekanntgewordenen Fehler nkF (= korrigierte Fehler) und
den bekanntgewordenen Schwachstellen nkV lässt sich das Verhältnis der Fehler zu den
(sicherheitsrelevanten) Schwachstellen nF/V bilden:
nF/V = nkF / nkV = 3.375 korrigierte Fehler p.a. / 103,5 Schwachstellen p.a. = 32,6 [10]
Dieser Faktor gibt an, dass unter ca. 33 Software-Fehlern eine sicherheitsrelevante
Schwachstelle zu erwarten ist (d.h. 3,06 % der Fehler sind sicherheitsrelevant).
Mit Hilfe dieses Faktors kann nun die Anzahl der nicht korrigierten Software-Schwachstellen
abgeschätzt werden. Aufgrund der Größe des Source Codes ergab sich oben die Anzahl der
Fehler im gesamten Software-Produkt zu:
nE = 149.986 Fehler siehe [3]
Das Einspielen der Patches über die Systemnutzungsdauer von angenommen 15 Jahren
reduziert die Fehlerzahl um:
eF = 50.625 Fehler siehe [6]
Die Anzahl der über die gesamte Systemnutzungsdauer nicht korrigierten Fehler ergibt sich
damit zu:
nuF = nE - eF [11]
nuF = 99.361 Fehler
Unter der Annahme, dass bei bekannten und unbekannten Software-Fehlern der Anteil der
sicherheitsrelevanten Fehler gleich groß ist, erhält man die Anzahl der niemals korrigierten
sicherheitsrelevanten Software-Schwachstellen mittels:
nF/V = nkF / nkV = nuF / nuV [12]
 nuV = nuF / nF/V = 99.361 Fehler / 32,6 Fehler/Schwachstelle [13]
nuV = 3.047 Schwachstellen
Der dieser Abschätzung zugrunde liegende Betriebssystemkern enthält demgemäß über die
gesamte Nutzungsdauer hinweg über 3.000 sicherheitsrelevante Software-Schwachstellen,
die niemals beseitigt werden und als potentielle Angriffsmöglichkeiten dienen können. An
dieser Stelle sei Phil Zimmermann zitiert: „man benötigt keine Hintertüren [in aktuellen
Seite 247 von 262

Anhang
Betriebssystemen, Anm. d. Verf.], Zero Days reichen völlig aus – deren Vorrat ist nahezu
unerschöpflich“ (Wetter, et al.).
Seite 248 von 262

Anhang
A2 Datentechnische Realisierung des Analyseverfahrens

Übersicht
In diesem Abschnitt soll die datentechnische Realisierung der Analysemethode beschrieben

werden. Die Implementierung besteht aus zwei wesentlichen Elementen:
 eine Datenbank zur Eingabe und Verwaltung der statischen Szenario- und
Anlagendaten sowie
 das PROLOG-Laufzeitsystem zur Lösungsfindung hinsichtlich der kritischen

Szenarien.
In Abbildung 47 sind die wesentlichen Bestandteile der Datenhaltungen dargestellt.

Kernelement der skizzierten Realisierung ist, dass alle Datentransformationen durch 1:1-
Abbildungen erfolgen. Sowohl beim Import oder Export als auch bei Datenbankabfragen
(SQL-Views) ist keine datengetriebene Beeinflussung der Abbildungsfunktion notwendig. Die
Datenbank besteht aus folgenden Bereichen:
Abbildung 47: Implementierung
Seite 249 von 262

Anhang
Anlagendaten
Die Datenbanktabellen enthalten die Daten zur Beschreibung der Zielanlage. Diese Daten
sind in SCADA-Anlagen typischerweise sehr statisch. Je nach datentechnischer
Verfügbarkeit erfolgt der Import der Daten in die Datenbank manuell (z.B.
Personalinformationen) oder automatisiert (z.B. Konfigurationsdaten).
Szenariodaten
Die Tabellen enthalten die Beschreibungen der berücksichtigten Angriffsszenarien, wie

Bezeichnung, Zielsystem, Ausgangspunkt des Angriffs, Zugangs-, Knowhow- und
Ausrüstungsvoraussetzungen. Die Szenario-Daten werden bei direkter Erfassung aus den
Attack Tree-Strukturen manuell in die Datenbank eingetragen. Falls beispielsweise die
Attack Tree-Erfassung mittels MS Excel erfolgt, könnten die Daten auch automatisiert in die
Datenbank übertragen werden.
Transformationsabfragen
Datenbankabfragen (SQL-Statements) überführen die erfassten Angriffs- und Anlagendaten

in PROLOG-Klauseln.
Export- / Importfunktionen
Die Exportfunktionen übertragen die Daten (PROLOG-Klauseln) in externe Dateien, auf die
das PROLOG-Laufzeitsystem zugreifen kann. Nach Durchlaufen der drei Analyseschritte #1
… #3 liegen die kritischen Szenarien und deren Angriffsvoraussetzungen vor.
Importfunktionen der Datenbank importieren die Ergebnisse der PROLOG-Auswertung. Die
Berechnung der tabellenartigen Sicherheitsmetrik hat sich mit den Mitteln einer Datenbank
als deutlich übersichtlicher herausgestellt, als die Implementierung mittels PROLOG-
Methoden.
Dokumentation der Anlageninformationen
Das Erfassen von Anlagendaten lässt sich mit Hilfe der Datenbankoberfläche (siehe Beispiel
in Abbildung 48) bewerkstelligen. Im Falle einer realen Anwendung wäre empfehlenswert,
von der Tabellenoberfläche auf eine Formulareingabe zu wechseln, um geeignete Prüfungen
der Eingabedaten hinterlegen zu können. Die Änderungshäufigkeit der realen
Seite 250 von 262

Anhang
Leittechnikanlage bestimmt die Häufigkeit der Änderungen an den

Anlagenbeschreibungsdaten.
Abbildung 48: Erfassung von Konfigurationsdaten (Beispiel)
Folgende Anlagenbereiche sind hierbei zu berücksichtigen:
 Konfigurationsdaten
 Gerätedaten
 Kommunikationsbeziehungen
 Netzwerkstrukturinformationen
Seite 251 von 262

Anhang
 Personalpräsenz
 Benutzerzugangsberechtigungen
 Kommunikationskonfiguration (hier: ARP-Konfiguration)
Angesichts der Tatsache, dass Leittechniksysteme im Gegensatz zu typischen

Unternehmensnetzwerken einen eher statischen Charakter haben (geringe Hardware-
Austauschrate, lange Software-Nutzung, geringe Personalanzahl, keine räumliche
Rechnerumzüge etc.) sowie die Möglichkeiten, Daten direkt aus Zielsystemen oder
Netzwerkmanagementsystemen auszulesen, bleibt der manuelle Aufwand zur Datenpflege
überschaubar.
Die Anlagendaten werden in folgenden Datenbanktabellen erfasst (siehe auch Beispiel in

Abbildung 48):
 CONFIG(DeviceType, DeviceID, Port, HostID)
 DEVICES(DeviceType, DeviceID, Location)
 COMMUNICATE(Source, Target)
 NET(LanID, SwitchID)
 STAFF(Location, State)
 USERACCESS(Usergroup, Location)
 STATICARP(Source, Destination)
Datenbankabfragen (SELECT-Statement) überführen die Tabellendaten mittels Datenbank-

View zur Laufzeit in entsprechende PROLOG-Klauseln. Das Transformationsschema der
Views fasst die Daten der Tabellen-Attribute in einem View-Attribut zusammen – ergänzt um
die PROLOG-Syntaxelemente.
Seite 252 von 262

Anhang
Transformationsbeispiel
Die Tabellendaten gemäß der entsprechenden Tabellendefinition werden per SQL-

Transformation in die View-Definition überführt.
Tabellendefinition CONFIG(DeviceType, DeviceID, Port, HostID)
SELECT "config(" & [Type] & ", " & [DeviceID] & ", " & [Port] & ", " &
[HostID] & ")."
SQL-Transformation
AS Config
FROM Config;
View-Definition CONFIG(DeviceType, DeviceID, Port, HostID)
Datenbank-Exportfunktionen übertragen die erfassten Daten aus den PROLOG-Abfragen in

externe Textdateien (im Beispiel nach config.pl). Aus dem obigem Beispiel ist ersichtlich,
dass der Export eine 1:1-Transformation der Datenbankinhalte in die PROLOG-Klauseln
darstellt. Aus den erfassten Anlagendaten lassen sich die notwendigen PROLOG-Klauseln
zur Anlagenbeschreibung automatisiert per Exportfunktion erzeugen.
Die Häufigkeit der Generierung der Klauseln hängt von der Änderungsrate der Anlagendaten
ab. Falls keine Änderungen an den Anlagendaten vorgenommen werden, ist auch keine
Generierung notwendig.
Mit Datenbankmitteln (MS Access) lässt sich der Export und Import von Daten nach bzw. aus
dem PROLOG-Laufzeitsystem (eigentlich: Dateisystem) in einfacher Weise bewerkstelligen
(siehe Abbildung 49).
Seite 253 von 262

Anhang
Abbildung 49: Datenbankoberfläche zum Import / Export von PROLOG-Daten
Dokumentation der Szenarien-Daten
Die Daten zur Beschreibung der Angriffsszenarien werden in die Datenbank importiert. Die
Daten basieren auf den Ergebnissen der Attack Tree-Analyse. Ergänzungen sind nur im
Falle von neuen Erkenntnissen hinsichtlich möglicher Angriffsszenarien notwendig und
können - ähnlich wie Änderungen an den Anlagendaten - per Datenbankoberfläche
eingegeben werden.
Die Daten der erfassten Angriffsszenarien werden aus den ursprünglichen MS Excel-
Tabellen in drei Datenbanktabellen importiert:
 Voraussetzungen_SysTech
 Voraussetzungen_Equipment
 Voraussetzungen_Knowhow
Seite 254 von 262

Anhang
Abbildung 50: Tabellenansicht Szenario-Daten (Beispiel)
Die Tabellen enthalten die Voraussetzungen für ein erfolgreiches Angriffsszenario als
Basisinformationen für die nachfolgende Analyse.
Tabellendefinitionen:
VORAUSSETZUNGEN_SYSTECH(SzenarioID, Szenario, Schutzziel, Zielsystem,

#Cd, #Usb, #OpenSwitchPort, #LocProgSS, #Netzverbindung, #ASPunkt_Zielsystem,
#ASPunkt_Fremdsystem, #ASPunkt_AnyClient, #Systembenutzung)
VORAUSSETZUNGEN_EQUIPMENT(SzenarioID, Szenario, Schutzziel, Zielsystem,

#Cd, #UsbStick, #Fremdgeraet, #Manipulations-Tool, #DoS-Tool, #App-spec-
Malware)
VORAUSSETZUNGEN_KNOWHOW(SzenarioID, Szenario, Schutzziel, Zielsystem,

#Besy-Knowhow, #App-Knowhow, #System-Knowhow, Username, Password)
Anmerkung: Tabellenattribute, die mit dem Präfix „#“ versehen sind, haben einen
binären Wertevorrat (ja / nein).
Die notwendigen PROLOG-Klauseln werden in drei Abschnitten erzeugt:
ScenarioA: Knowhow- und Equipment-Voraussetzungen, die ein potentieller Angreifer

zu erfüllen hat
ScenarioD: Formale Daten eines Angriffsszenarios (Szenario-ID, Bezeichnung,

Schutzziel, Zielsystem)
Seite 255 von 262

Anhang
ScenarioS: Systemtechnische Voraussetzungen für ein Angriffsszenario
Bildung von PROLOG-Klauseln: angreiferseitige Voraussetzungen
Die durch die Angreifer zu erfüllenden Voraussetzungen (scenarioA) lassen sich mit Hilfe
des folgenden Datenbank-Konstrukts in PROLOG-Klauseln überführen:
Auf Basis der Datenbanktabellen VORAUSSETZUNGEN_EQUIPMENT und

VORAUSSETZUNGEN_KNOWHOW wird eine Hilfstabelle (View) gebildet: SCENARIO_A
VORAUSSETZUNGEN_EQUIPMENT(SzenarioID, Szenario,
Schutzziel, Zielsystem, #Cd, #UsbStick, #Fremdgeraet,
#Manipulations-Tool, #DoS-Tool, #App-spec-Malware)
Tabellendefinitionen
VORAUSSETZUNGEN_KNOWHOW(SzenarioID, Szenario,
Schutzziel, Zielsystem, #Besy-Knowhow, #App-Knowhow, #System-
Knowhow, Username, Password)
SELECT DISTINCT Voraussetzungen_Equipment.[Szenario-ID],

Voraussetzungen_Equipment.CD, IIf([CD]=True,"cd","none") AS
R_CD, Voraussetzungen_Equipment.[USB-Stick],
IIf([CD]=True,"usbStick","none") AS R_USB,
Voraussetzungen_Equipment.Fremdgeraet,
IIf([Fremdgeraet]=True,"malDevice","none") AS R_Fremdgeraet,
Voraussetzungen_Equipment.[Manipulations-Tool], IIf([Manipulations-
Tool]=True,"malSwTool","none") AS [R_Manipulations-Tool],
Voraussetzungen_Equipment.[DoS-Tool], IIf([DoS-
Tool]=True,"dosTool","none") AS [R_DoS-Tool],
Voraussetzungen_Equipment.[App-spec-Malware], IIf([App-spec-
Malware]=True,"appSpecMalware","none") AS [R_App-spec-
Malware], Voraussetzungen_Knowhow.[Besy-Knowhow], IIf([Besy-
SQL-Transformation Knowhow]=True,"osKnowhow","none") AS [R_Besy-Knowhow],
Voraussetzungen_Knowhow.[App-Knowhow], IIf([App-
Knowhow]=True,"appKnowhow","none") AS [R_App-Knowhow],
Voraussetzungen_Knowhow.[System-Knowhow], IIf([System-
Knowhow]=True,"systemKnowhow","none") AS [R_System-
Knowhow], Voraussetzungen_Knowhow.Username,
IIf([Username]=True,"userName","none") AS R_Username,
Voraussetzungen_Knowhow.Passwort,
IIf([Passwort]=True,"password","none") AS R_Passwort
FROM Voraussetzungen_Equipment INNER JOIN
Voraussetzungen_Knowhow ON
Voraussetzungen_Equipment.[Szenario-ID] =
Voraussetzungen_Knowhow.[Szenario-ID];
SCENARIO_A( Voraussetzungen_Equipment.Szenario-ID,
Voraussetzungen_Equipment.CD, R_CD,
Voraussetzungen_Equipment.USB-Stick, R_USB,
View-Definition Voraussetzungen_Equipment.Fremdgeraet, R_Fremdgeraet,
Voraussetzungen_Equipment.Manipulations-Tool, R_Manipulations-
Tool,
Voraussetzungen_Equipment.DoS-Tool, R_DoS-Tool,
Seite 256 von 262

Anhang
Voraussetzungen_Equipment.App-spec-Malware, R_App-spec-
Malware,
Voraussetzungen_Knowhow.Besy-Knowhow, R_Besy-Knowhow,
Voraussetzungen_Knowhow.App-Knowhow, R_App-Knowhow,
Voraussetzungen_Knowhow.System-Knowhow, R_System-Knowhow,
Voraussetzungen_Knowhow.Username, R_Username,
Voraussetzungen_Knowhow.Passwort, R_Passwort,
join( Voraussetzungen_Equipment.Szenario-ID =
Voraussetzungen_Knowhow.SzenarioID )
Anmerkung: die View-Attribute mit Präfix „R_“ bilden den Inhalt des vorangestellten
Attributes auf einen binären Wertevorrat ab (ja / nein)
Die Laufzeitabfrage (View) „SCENARIO_A“ stellt die Daten zur Erzeugung der PROLOG-
Syntax bereit. Die Datenbankabfrage „PROLOG_ScenarioA“ bildet die Attribute-Werte aus
„SCENARIO_A“ auf das einzelne Attribut „PROLOG“ in „PROLOG_ScenarioA“ ab.
Seite 257 von 262

Anhang
SCENARIO_A( Voraussetzungen_Equipment.Szenario-ID,
Voraussetzungen_Equipment.CD, R_CD,
Voraussetzungen_Equipment.USB-Stick, R_USB,
Voraussetzungen_Equipment.Fremdgeraet, R_Fremdgeraet,
Voraussetzungen_Equipment.Manipulations-Tool, R_Manipulations-
Tool,
Voraussetzungen_Equipment.DoS-Tool, R_DoS-Tool,
Tabellendefinition Voraussetzungen_Equipment.App-spec-Malware, R_App-spec-
Malware,
(Datenbank-View)
Voraussetzungen_Knowhow.Besy-Knowhow, R_Besy-Knowhow,
Voraussetzungen_Knowhow.App-Knowhow, R_App-Knowhow,
Voraussetzungen_Knowhow.System-Knowhow, R_System-Knowhow,
Voraussetzungen_Knowhow.Username, R_Username,
Voraussetzungen_Knowhow.Passwort, R_Passwort,
join( Voraussetzungen_Equipment.Szenario-ID =
Voraussetzungen_Knowhow.SzenarioID )
SELECT DISTINCT "scenarioA(" & [Szenario-ID] & ", " & [R_CD] & ", "
& [R_USB] & ", " & [R_Fremdgeraet] & ", " & [R_Manipulations-Tool] &
SQL-Transformation ", " & [R_DoS-Tool] & ", " & [R_App-spec-Malware] & ", " & [R_Besy-
Knowhow] & ", " & [R_System-Knowhow] & ", " & [R_Username] & ", "
& [R_Passwort] & "). " AS PROLOG FROM ScenarioA;
PROLOG_scenarioA(scenarioA(Szenario-ID, R_CD,
R_USB, R_Fremdgeraet, R_Manipulations-Tool,
View-Definition
R_DoS-Tool, R_App-spec-Malware, R_Besy-Knowhow,
R_System-Knowhow, R_Username, R_Passwort).)
Anmerkung: die Abfrage „SCENARIO_A“ dient ausschließlich als Hilfskonstrukt zur besseren
Kontrolle der Arbeitsschritte. Die Verknüpfungen wären auch in die Abfrage
„PROLOG_scenarioA“ integrierbar, so dass auf die Abfrage „SCENARIO_A“ verzichtet
werden könnte.
Bildung von PROLOG-Klauseln: Angriffsbeschreibungen
Die Beschreibungen der Angriffe (scenarioD) lassen sich mit Hilfe des folgenden Datenbank-
Konstrukts in PROLOG-Klauseln überführen:
Seite 258 von 262

Anhang
Auf Basis der Datenbanktabellen VORAUSSETZUNGEN_SYSTECH wird eine Hilfstabelle

(View) gebildet: SCENARIO_DEFINITION

Zielsystem, #Cd, #Usb, #OpenSwitchPort, #LocProgSS,
Tabellendefinition #Netzverbindung, #ASPunkt_Zielsystem, #ASPunkt_Fremdsystem,
#ASPunkt_AnyClient, #Systembenutzung)
SELECT VORAUSSETZUNGEN_SYSTECH.Szenario-ID
VORAUSSETZUNGEN_SYSTECH.Szenario,
VORAUSSETZUNGEN_SYSTECH.Schutzziel,
VORAUSSETZUNGEN_SYSTECH.Zielsystem,
Zielsystem,
IIf(ASPunkt_Zielsystem=True,1,0) AS R_SS_Target,
IIf(ASPunkt_Fremdsystem=True,2,0) AS R_SS_MalSystem,
IIf(ASPunkt_AnyClient=True,4,0) AS R_SS_AnyClient,
SQL-Transformation
R_SS_Target + R_SS_MalSystem + R_SS_AnyClient AS Summe,
IIf(Summe=0, "none",
(IIf(Summe=1,
(IIf([Summe]=2, malDevice", (IIf([Summe]=4, "anyClient", "xxx"))))))
AS SourceSystem FROM VORAUSSETZUNGEN_SYSTECH
"scenarioD(" & [Szenario-ID] & ", " & [Zielsystem] & ", " &
[SourceSystem] & ", " & [Schutzziel] & ", " & [Szenario] & ")." AS
Prolog
SCENARIODEFINITION(scenarioA(Szenario-ID, Szenario, Schutzziel,

View-Definition Zielsystem, R_SS_Target, R_SS_Malsystem, R_SS_AnyClient,
Summe, SourceSystem, Prolog)
Für den Export werden die PROLOG-Klauseln in einem separaten View

„PROLOG_scenarioD“ bereitgestellt:
SCENARIODEFINITION(scenarioA(Szenario-ID, Szenario, Schutzziel,

Tabellendefinition Zielsystem, R_SS_Target, R_SS_Malsystem, R_SS_AnyClient,
Summe, SourceSystem, Prolog)
SQL-Transformation SELECT Prolog FROM SCENARIODEFINITION
View-Definition PROLOG_scenarioD(Prolog)
Seite 259 von 262

Anhang
Bildung von PROLOG-Klauseln: Systemtechnische Voraussetzungen
Die Beschreibungen der systemtechnischen Voraussetzungen (scenarioS) für einen

erfolgreichen Angriff gegen das Leitsystem lassen sich mit Hilfe des folgenden Datenbank-
Konstrukts in PROLOG-Klauseln überführen:
Auf Basis der Datenbanktabellen VORAUSSETZUNGEN_SYSTECH wird eine Hilfstabelle

(View) gebildet: SCENARIO_S

Zielsystem, #Cd, #Usb, #OpenSwitchPort, #LocProgSS, #Netzverbindung,
Tabellendefinition #ASPunkt_Zielsystem, #ASPunkt_Fremdsystem, #ASPunkt_AnyClient,
#Systembenutzung)
SELECT VORAUSSETZUNGEN_SYSTECH.ID,
VORAUSSETZUNGEN_SYSTECH.Szenario-ID,
VORAUSSETZUNGEN_SYSTECH.Szenario,
VORAUSSETZUNGEN_SYSTECH.Schutzziel,
VORAUSSETZUNGEN_SYSTECH.Zielsystem,
VORAUSSETZUNGEN_SYSTECH.CD,
VORAUSSETZUNGEN_SYSTECH.USB,
VORAUSSETZUNGEN_SYSTECH.openSwitchPort,
VORAUSSETZUNGEN_SYSTECH.locProgSS,
VORAUSSETZUNGEN_SYSTECH.Netzverbindung,
VORAUSSETZUNGEN_SYSTECH.ASPunkt_Zielsystem,
VORAUSSETZUNGEN_SYSTECH.ASPunkt_Fremdsystem,
VORAUSSETZUNGEN_SYSTECH.ASPunkt_AnyClient,
VORAUSSETZUNGEN_SYSTECH.Systembenutzung,
IIf([CD]=True,1,0) AS _CD, IIf(USB=True,2,0) AS _USB,
IIf(openSwitchPort=True,4,0) AS R_openSwitchPort,
SQL-Transformation IIf(locProgSS=True,8,0) AS R_locProgSS,
IIf(Netzverbindung=True,16,0) AS R_Netzverbindung,
IIf(ASPunkt_Zielsystem=True,32,0) AS R_ASPunkt_Zielsystem,
IIf(ASPunkt_Fremdsystem=True,64,0) AS R_ASPunkt_Fremdsystem,
IIf(ASPunkt_AnyClient=True,128,0) AS R_ASPunkt_AnyClient,
IIf(Systembenutzung=True,256,0) AS R_Systembenutzung,
IIf(Voraussetzungen_SysTech.Zielsystem="network",512,0) AS R_TS-
Netzwerk, IIf(Voraussetzungen_SysTech.Zielsystem="dhcpServer",1024,0)
AS R_TS-dhcp,
IIf(Voraussetzungen_SysTech.Zielsystem="switch",2048,0) AS R_TS-
switch,
R_CD + R_USB + R_openSwitchPort + R_locProgSS + R_Netzverbindung
+ R_ASPunkt_Zielsystem + R_ASPunkt_Fremdsystem +
R_ASPunkt_AnyClient + R_Systembenutzung + R_TS-Netzwerk + R_TS-
dhcp + R_TS-switch AS Summe
FROM VORAUSSETZUNGEN_SYSTECH;
Seite 260 von 262

Anhang
SCENARIO_S(VORAUSSETZUNGEN_SYSTECH.Szenario-ID,
VORAUSSETZUNGEN_SYSTECH.CD, R_CD,
VORAUSSETZUNGEN_SYSTECH.USB, R_USB,
VORAUSSETZUNGEN_SYSTECH.OpenSwitchPort, R_OpenSwitchPort,
VORAUSSETZUNGEN_SYSTECH.LocProgSS, R_LocProgSS,
VORAUSSETZUNGEN_SYSTECH.Netzverbindung, R_Netzverbindung,
View-Definition VORAUSSETZUNGEN_SYSTECH.ASPunkt_Zielsystem,
R_ASPunkt_Zielsystem,
R_ASPunkt_Fremdsystem,
R_ASPunkt_AnyClient,
R_Systembenutzung)
Für den Export werden die PROLOG-Klauseln in einem separaten View

„PROLOG_scenarioS“ bereitgestellt:
SCENARIO_S(VORAUSSETZUNGEN_SYSTECH.Szenario-ID,
VORAUSSETZUNGEN_SYSTECH.CD, R_CD,
VORAUSSETZUNGEN_SYSTECH.USB, R_USB,
VORAUSSETZUNGEN_SYSTECH.OpenSwitchPort, R_OpenSwitchPort,
VORAUSSETZUNGEN_SYSTECH.LocProgSS, R_LocProgSS,
VORAUSSETZUNGEN_SYSTECH.Netzverbindung, R_Netzverbindung,
VORAUSSETZUNGEN_SYSTECH.ASPunkt_Zielsystem,
Tabellendefinitionen R_ASPunkt_Zielsystem,
R_ASPunkt_Fremdsystem,
R_ASPunkt_AnyClient,
R_Systembenutzung)
SZENARIO-DATEN(Kombination, Voraussetzungen)
SELECT Prolog FROM SCENARIODEFINITION SELECT DISTINCT "(" &

"(SC = " & Szenario-ID & ")" & ", " & "scenarioD(SC, TS, SS, _, A)" & ", " &
"(TS = " & Zielsystem & ")" & ", " & Voraussetzungen & ");" AS PROLOG
SQL-Transformation FROM Szenario-Daten
INNER JOIN SCENARIO_S ON SZENARIO-DATEN.Kombination =
SCENARIO_S.Summe
View-Definition PROLOG_scenarioS(Prolog)
Seite 261 von 262

Anhang
Anmerkung: Die Abbildung der systemtechnischen Voraussetzungen (z.B. CD, USB,

openSwitchPort, etc.) auf die PROLOG-Klausel erfolgt durch Bildung eines numerischen
Indexes über die Kombination der Voraussetzungen. Jedem (eindeutigen) Indexwert wird
anschließend ein PROLOG-Fragment aus der Tabelle SZENARIO-DATEN zugeordnet.
Schema der Indexbildung:
Die Inhalte der Datenbanktabelle VORAUSSETZUNGEN_SYSTECH kann zu diesem Zweck

als (i, j)-Matrix aufgefasst werden:
(Attribute ... CD USB ... ... )
... 1 1 1 ...
VORAUSSETZUNGEN_SYSTECH = ... 1 0 1 ... = | Vij |
... 0 1 1 ...
Die Matrix besteht aus i Zeilen (= Datensätze) und j Spalten (= systemtechnische

Voraussetzungen). Als Bewertungsfaktor der verschiedenen Voraussetzungen wird ein
Zeilenvektor mit n Elementen verwendet:
Bewertungsvektor = | 1 2 4 8 16 ... | = | Bn |
wobei n = j (= Anzahl der Spalten für die systemtechnischen Voraussetzungen)
Durch Multiplikation der (Teil-) Matrix VORAUSSETZUNGEN_SYSTECH mit dem

Bewertungsvektor erhält man für jede Matrixzeile den eindeutigen Wert für die Kombination
der Voraussetzungen:
| Vij | * | Bn | = | Ci |
mit Ci = ∑𝑗 Vi,n * Bn
𝑛=1
Seite 262 von 262

Mathematik Und Informatik

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Mathematik Und Informatik

Hochgeladen von

Copyright:

Verfügbare Formate

Hans-Richard Kraft

Systematische Analyse- und

zur Erlangung des Grades eines

der Fakultät Mathematik und Informatik

Prof. Dr. Ulrike Baumöl

Prof. Dr. Jörg Keller

Tag der mündlichen Prüfung:

16. November 2016

Seite 1 von 262

Seite 2 von 262

The development of countermeasures in order to improve the cyber security of automation

In order to avoid these weaknesses, this document describes a semi-automatized

Seite 3 von 262

1.1 Einführung ............................................................................................................... 8

1.2 Ausgangssituation und Motivation ........................................................................... 9

1.3 Zielsetzung .............................................................................................................11

1.4 Vorgehensweise .....................................................................................................13

1.5 Gliederung .............................................................................................................14

2 Grundlegende Aspekte der Leit- und Automatisierungssysteme....................................17

2.1 Übersicht Leittechniksysteme .................................................................................17

2.2 Technologietrends ..................................................................................................22

2.3 Unterschiede zwischen Leittechnik- und IT-Systemen............................................25

2.3.1 Schutzziele von IT-Systemen ..........................................................................25

2.3.2 Schutzziele von SCADA-Systemen .................................................................25

2.3.3 Echtzeitanforderungen ....................................................................................27

2.3.4 Betriebliche Aspekte........................................................................................27

3 IT-Sicherheit von Leit- und Automatisierungssystemen .................................................31

3.1 Überblick ................................................................................................................31

3.2 Begriffe und Abgrenzungen ....................................................................................31

3.2.1 Funktionale Sicherheit .....................................................................................31

3.2.2 IT-Sicherheit ....................................................................................................32

3.2.3 Schutzziele: Abgrenzung und Anforderungen an die Systeme ........................34

3.3 Überlegungen zur Beurteilung von IT-Sicherheit ....................................................34

3.4 Bedrohungen von Leit- und Automatisierungssystemen .........................................36

3.5 IT-Sicherheit als Systemeigenschaft ......................................................................41

3.6 Extrakt der weiterführenden Ergebnisse .................................................................43

4 Ansätze zur Beurteilung der IT-Sicherheit von Leit- und Automatisierungssystemen.....46

4.1 Motivation ...............................................................................................................46

Seite 4 von 262

4.2.1 Allgemeine Anmerkungen ...............................................................................48

4.2.2 Ansätze zur Beurteilung der IT-Sicherheit .......................................................49

4.2.3 IT-Security-Metriken für SCADA-Systeme .......................................................51

4.2.4 Risikoanalysen für SCADA-Systeme ...............................................................54

4.3 Kritik der Konzepte und Vorgehensweisen .............................................................61

4.4 Kriterien eines praxisgerechten Beurteilungsansatzes ...........................................62

4.5 Extrakt der weiterführenden Ergebnisse .................................................................63

5 Vorschlag eines neuen Analysemodells für SCADA-Systeme .......................................65

5.1 Beurteilungsansatz für IT-Sicherheit .......................................................................65

5.2 Beurteilung der Angriffsvoraussetzungen ...............................................................68

5.3 Herleitung von Angriffsszenarien ............................................................................72

5.3.1 Allgemeines ....................................................................................................72

5.3.2 Leittechnikmodell zur Herleitung generischer Angriffsszenarien ......................73

5.3.3 Herleitung generischer Angriffsszenarien mittels Attack Tree-Graphen ...........80

5.4 Formale Betrachtung des Analyseprozesses..........................................................91

5.4.1 Formale Methoden des Analyseprozesses ......................................................91

5.4.2 Verlauf des Analyseprozesses ........................................................................94

5.4.3 Beschreibung der Angriffsszenarien ................................................................96

5.4.4 Beschreibung der leittechnischen Anlage ......................................................100

5.4.5 Abbildung der Angriffsszenarien auf die Zielanlage .......................................104

5.4.6 Herleitung der Voraussetzungen für kritische Angriffsszenarien ....................108

5.5 Extrakt der weiterführenden Ergebnisse ...............................................................110

6 Konzept einer Leittechnik-IT-Sicherheitsmetrik ............................................................112

6.1 IT-Sicherheitsmetrik – Wozu? ..............................................................................112