Die riskobehaftete Zone der Industrial Control Systeme

Transkript

1 Die riskobehaftete Zone der Industrial Control Systeme 1. Abstract Einführung in Safety Instrumented Systems (SIS) und deren Herausforderungen für die Security Erwin Kruschitz, IMI IT meets Industry, anapur AG 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.).

2 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.

3 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 Security- Fachmann 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.

4 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, Maintenance- System) 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.

5 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 für Office IT und Automatisierungstechnik (inkl. SIS) einer gemeinsamen Engineering Station (für SIS und BPCS) Beispiel 1: Ein Engineering-System (Windows PC) wird unter Nutzung der konventionellen betrieblichen IT-Infrastruktur betrieben. 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?

6 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 (Software- Pakete) 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 IT- Infrastruktur 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.