deposit_hagen
Systematische Analyse- und Beurteilungsmethodik für die IT-Sicherheit prozessführender Computersysteme in operativen Industrieumgebungen
Mathematik und
Informatik
Dissertation
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
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.
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.
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
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
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
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
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).
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
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
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?
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.
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“).
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
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-
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.
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
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.
Abbildung 2: Schematische Darstellung einer Leittechnikanlage
Automatisierungsebene
Automatisierungssysteme erfassen die Eingangssignale mittels spezieller Eingabemodule, die auch der messtechnischen Behandlung der normierten Eingangssignale (galvanische
Quelle: Siemens
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.
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.
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.
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
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
Automatisierungssystem: Programmierbare Zentraleinheiten und IO-Einheiten mit 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
Automatisierungssystem: Programmierbare Zentraleinheiten und IO-Einheiten mit 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: 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.
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
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.
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.
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.
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).
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].“
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.
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
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.
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
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.
