die risikobehaftete Zone der Industrial Control Systeme

Die riskobehaftete Zone der Industrial Control Systeme
Einführung in Safety Instrumented Systems (SIS) und deren
Herausforderungen für die Security
Erwin Kruschitz, IMI IT meets Industry, anapur AG
1. Abstract
Das Papier gibt im ersten Teil eine Einführung in den Themenbereich der SIS.
Der zweite Teil befasst sich mit der Security von SIS. Der Schwerpunkt liegt
dabei bei der Frage des Engineerings, welches aus Sicht des Autors große
Angriffsflächen bietet.
2. Einführung
Risiken für Leib und Leben oder die Umwelt, welche z.B. von Raffinerien,
Chemiebetrieben oder Signalanlagen im Transportwesen ausgehen, werden
durch spezielle Systeme abgewehrt. Diese Systeme werden in diesem Beitrag
als SIS bezeichnet. Im Sprachgebrauch befinden sich aber auch die Begriffe
SSPS
(Safety
Speicherprogrammierbare
Steuerung)
oder
sicherheitsgerichtetes System. SIS haben die Aufgabe, Anlagen in einen
sicheren Zustand zu fahren (z.B. abzuschalten), wenn Gefahr droht. Häufig
hört man das Argument, dass diese Systeme nicht vernetzt und deshalb vor
Cyber Security Gefahren geschützt sind. Diese Sichtweise befindet sich
gerade im Umbruch. Dieser Beitrag möchte erläutern warum.
2.1 Begriff: Safety (Funktionale Sicherheit, Functional Safety)?
Mit Funktionaler Sicherheit wird versucht, Risiken für Mensch und Umwelt,
welche z.B. durch Maschinen oder verfahrenstechnische Anlagen entstehen,
mit Mitteln der Automatisierungstechnik (Sensorik, Aktorik und Steuerung) auf
ein tolerierbares Maß zu vermindern.
Im Beispiel (Abbildung Fehler! Es wurde keine Folge festgelegt.) wird der
Füllstand des Behälters (LT, Level Transmitter) durch einen Regler (LIC Level
Indication Control) eines konventionellen Automatisierungssystems (BPCS
Basic Process Control System) geregelt. Das Risiko einer BehälterÜberfüllung wird durch die Einführung eines Safety Instrumented System (SIS)
verringert (siehe rote Linie in Abbildung Fehler! Es wurde keine Folge
festgelegt.).
Abbildung Fehler! Es wurde keine Folge festgelegt. Beispiel Functional Safety
Das Qualitätsmerkmal eines SIS ist der vierstufige SIL (Sicherheits Integritäts
Level).
D.h. je höher der SIL ist, desto „sicherer“ ist das SIS und somit
unwahrscheinlicher ist ein Schaden für Menschen oder Umwelt. In der
Planungsphase einer Anlage wird der zu erreichende SIL ermittelt (durch
Risiko-Analyse). In der Errichtungsphase muss das Erreichen des SIL
nachgewiesen (errechnet) werden.
Wenn der durch den Einsatz des SIS erreichte SIL der Anforderung aus der
Risikoanalyse entspricht, gilt die Anlage als „sicher“ (d.h.: Restrisiko <
tolerierbares Risiko).
2.2 Unterschiede im Risikobegriff Safety versus Security
Diskussionen zwischen IT-Experten und Automatisierungsingenieuren leiden
häufig an einem unterschiedlichen Verständnis darüber, was „das System“
bzw. „das Risiko“ ist. Insofern erscheint eine Erläuterung der verschiedenen
Auffassungen hier sinnvoll und notwendig.
Wie oben bereits besprochen wird Risiko im Zusammenhang mit Safety als
das Prozessrisiko verstanden, d.h. ein möglicher Schaden an Mensch, Umwelt
oder Anlage.
Im Zusammenhang mit Safety wird im Grundsatz von einem SIS
ausgegangen, dessen Funktion vorherbestimmt werden kann (hoher Grad an
Deterministik). Die Zuverlässigkeit der Funktion wird durch SIL beschrieben. In
der Nachweis-Praxis wird der SIL primär über SIS-inhärente Faktoren
bestimmt (z.B. Ausfallrate, Anteil gefährlicher Fehler vs. ungefährlicher Fehler,
Redundanz bzw. Hardware- Fehlertoleranz). Die Grundlagen aus der Safety
Norm IEC61508/61511 beschreiben auch Fehler mit systematischer Ursache
(z.B. menschliches Versagen, organisatorische Missstände, Software-Fehler).
In der Safety Praxis befinden sich systematische Fehler eher im Hintergrund.
Zusammengefasst kann gesagt werden, dass bei der Frage nach Safety fast
ausschließlich auf SIS-systemimmanente Parameter fokussiert wird. Sabotage
oder Einwirkungen von außen – z.B. Angriffe über Netzwerkverbindungenwurden in der Vergangenheit kaum beachtet. In der zweiten Revision der
Safety Normen (IEC 61508/61511) ist eine Analyse der Security Risiken
vorgeschrieben. Dies wird in den nächsten Jahren zu einer Änderung führen.
Die Security-Community sieht das genau umgekehrt. Für den SecurityFachmann kommt die Bedrohung vornehmlich von außen (in Form eines
externen Angreifers) und richtet sich gegen das IT-System (bzw. dessen
Schwachstellen) und nutzt diese aus.
Unter Schaden versteht der Security Fachmann den Verlust
von Systemverfügbarkeit
von Vertraulichkeit von Informationen
der Integrität des Systems und der Daten
2.3 Komponenten eines Safety-Systems
Der Fokus der Safety-Normen bei der Beschreibung von SISen liegt auf den
Komponenten Sensor, Aktor und Steuerungssystem (SSPS).
Die Engineering Komponente für Maschinen und Anlagen und das SIS ist
häufig mit der Unternehmens-IT vernetzt, bietet einem weiten Spektrum von
Benutzern Zugriff auf hochsensible Daten und besteht häufig aus einer
vielfältigen - Windows-basierten - Software-Landschaft. Bei diesen
Engineeringsystemen kommt es durchaus vor, dass Restriktionen bzgl.
Sicherheitsupdates durch die Hersteller vorliegen. Hinzu kommen sehr lange
Betriebszeiten von zum Teil 20 Jahren. Dies ist von Seiten der Security als
kritisch zu betrachten und erfordert ein besonderes Augenmerk.
Die Engineering Funktion umfasst Konfigurationssoftwarepakete für die
einzelnen Komponententypen. Diese Pakete und die Konfiguration können
von unterschiedlichen Herstellern oder Quellen stammen.
Häufig ist die Engineering Funktion für eine Anlage auf mehreren -meist
mobilen- Geräten installiert. Bei Planung, Umsetzung und Wartung sind daher
unterschiedliche Personen/-gruppen involviert. Während des Betriebs des SIS
haben primär der Anlagenbetreiber (Betrieb und Wartungsabteilung) und der
Systemintegrator (für Änderungen, Updates, Fehlerbeseitigung) Zugriff.
Abbildung Fehler! Es wurde keine Folge festgelegt. Funktionen eines Safety
Systems (SIS) (Funktionale Darstellung)
2.4 Einbettung (Vernetzung) des SIS in die betriebliche
Produktionsumgebung
Nach einer landläufig verbreiteten Ansicht ist ein SIS ein nicht vernetztes
System, das weitgehend unberührt über den Lebenzyklus hin seine Dienste
verrichtet. Der folgende Absatz möchte dieses Vorurteil in Frage stellen, denn
auch in der Betriebsphase befindet sich ein SIS zwangsläufig im
Datenaustausch mit seiner betrieblichen Umgebung z.B. im Zusammenhang
mit folgenden Aktivitäten:
Wiederkehrende Prüfungen und Kalibrierung von Sensoren
Änderungen der System-Firmware
Systemstatus Überwachung und Störungsanalyse
Schnittstellen zu Prozessleitsystemen (PLS)
Datentransport zum BDIS
Dokumentation (CAE-System, Kalibrierungssystem, MaintenanceSystem)
Hier besteht die Gefahr, dass durch einen Angreifer beispielsweise
Manipulationen an der Konfiguration des SIS vorgenommen werden.
3. Worin bestehen die Herausforderungen für die Security
Security für Safety ist ein „neues“ Thema. Noch gibt es kaum SIS
Komponenten auf dem Markt, bei denen Security Anforderungen bereits in der
Produktentwicklung berücksichtigt wurden.
Die zunehmende Nutzung von IT & Netzwerktechnik überwindet Grenzen, die
bis vor wenigen Jahren bedingt durch die Art der eingesetzten Technologie
vorhanden waren. Viele Prozesse können durch Vernetzung vereinfacht und
beschleunigt werden.
Hinsichtlich Security hatte die „technologiebedingte Separation“ einen klaren
Vorteil. Diversität und Segregation verhinderten nicht nur den einfachen und
erwünschten Datenaustausch, sondern auch die unerwünschte Ausbreitung
von Daten und Programmen.
In diesem Zusammenhang besteht jetzt die Herausforderung für
Systemhersteller und Endanwender sowie die diversen IT- und
Ingenieurabteilungen, Grenzen neu zu definieren und entsprechend
abzusichern.
.
Dort wo das SIS eine Infrastruktur mit anderen Systemen teilt bzw. vernetzt ist
(und das ist insbesondere beim Engineering System der Fall), entstehen
prinzipiell folgende Fragen:
1. ist die gemeinsam genutzte Infrastruktur technisch geeignet für den
Zweck des SIS?
2. ist Rückwirkungsfreiheit gesichert? D.h. andere Systeme haben
keine Auswirkung auf den Betrieb des SIS Systems (und umgekehrt)
3. ist die organisatorische Zuständigkeit für die Aufrechterhaltung der
Integrität der Infrastruktur geklärt?
Diese Fragen entstehen beispielsweise bei der Nutzung
•
eines
gemeinsamen
IT-Netzwerkes
Automatisierungstechnik (inkl. SIS)
•
einer gemeinsamen Engineering Station (für SIS und BPCS)
für
Office
IT
und
Beispiel 1:
Ein Engineering-System (Windows PC) wird unter
konventionellen betrieblichen IT-Infrastruktur betrieben.
Nutzung
der
Durch möglicherweise nicht installierte Updates sind Schwachstellen
vorhanden über die das System mit einer Schadsoftware infiziert werden kann.
Diese könnte die Programmierung der Anlage und des SIS manipulieren.
Frage: Wie wird sichergestellt, dass das Patchen des Betriebssystems in
Übereinstimmung mit den Regeln des Systemherstellers und gleichzeitig der
hausinternen IT durchgeführt wird?
Beispiel 2 (integriertes System)
Ein SIS wird mit demselben Engineering-Softwarepaket konfiguriert wie ein
normales BPCS.
Mögliche Probleme: a) Das ähnliche Erscheinungsbild der Anwendungen
begünstigt Verwechslungen zwischen SIS und BPCS. b) Schadsoftware kann
auf einen Schlag sowohl BPCS als auch SIS beeinträchtigen. c)
Das Logik-System eines SIS läuft auf derselben Controller-Hardware wie das
BPCS.
Frage: Kann das rückwirkungsfrei funktionieren? Ist das Gebot nach
Separation und Diversität eingehalten? Besteht Verwechslungsgefahr?
Generell entsteht durch Vernetzung das Problem der Komplexität. Je
integrierter und vernetzter Systeme sind, desto schwieriger ist vorherzusehen,
wie diese Systeme in Ausnahmesituationen reagieren (Determinismus).
Entsprechend muss auch die Frage geklärt werden, wie viel
Integration/Vernetzung für ein SIS erlaubt sein soll.
4.
Fazit: Welche Faktoren tragen dazu bei, dass die Kernfunktion
Safety durch Security Zwischenfälle beeinflusst werden kann?
Die Engineering Station (Hardware) die Engineering Applikationen (SoftwarePakete) und Engineering Daten, werden nicht als integraler Bestandteil des
Safety Systems betrachtet. Die daraus resultierende Sorglosigkeit im Umgang
entspricht nicht dem tatsächlichen Risiko.
5.
Lösungsansatz
SIS Hersteller werden bei Entwicklung Ihrer Komponenten auch Security
Fragen berücksichtigen. Angesichts der Entwicklungszyklen beim Hersteller
und der Lebenszyklen der im Betrieb befindlichen SIS-Produkte, ist die
Wirkung dieser Maßnahme erst in einigen Jahren zu erwarten.
Kurzfristiger Erfolg kann durch folgende Maßnahmen erzielt werden:
a) Härtung: Die Windows Betriebssysteme von Engineering Systemen
sollten für deren Betriebszweck zugeschnitten sein. D.h. sämtliche Softund Hardware-Komponenten, die für den Zweck nicht zwingend
gebraucht werden, sollten entfernt werden.
b) Trennung: SIS Engineering Stationen sollten nicht für andere Zwecke
als das SIS Engineering verwendet werden. Die Integration in die ITInfrastruktur soll möglichst gering sein (ggf. auf dauerhafte Netzwerk –
Integration verzichten). Der Datentransport zu und von der Engineering
Station soll unter streng geregelten Bedingungen stattfinden.
c) Ausbildung: SIS Ingenieure sollen in Security Belangen geschult sein.
d) Technische Maßnahmen wie Application Whitelisting, Virenschutz,
Firewalls, Intrusion Detection/Protection sollen die erstgenannten
Maßnahmen unterstützen.

Download Report