Unabhängige Sicherheitssysteme für
getrennte Schutzebenen

News


Header_Security_Landingpage_910x300

Integrierte Lösung trotz getrennter Schutzebenen: Good Engineering Practice

Der wachsende Kostendruck und die zunehmende Komplexität bei Planung und Betrieb von sicherheitskritischen Anlagen lässt die Nachfrage nach integrierten Sicherheitslösungen steigen. Die IEC 61511 fordert wo immer möglich den Erhalt sämtlicher Schutzschichten. Für jede dieser Schutzschichten wird Unabhängigkeit, Diversität und physikalische Trennung verlangt. Auch beim Thema Cyber Security fordert die IEC 61511 ED 2 eine dedizierte Risikobeobachtung.

Sicherheit ohne Kompromisse
Nur wenn Sicherheitssystem und Prozessleitsystem auf unterschiedlichen Plattformen, Entwicklungsgrundlagen und Philosophien basieren, sind sie autark und damit in der Lage, als separate Schutzschichten im Sinne der IEC 61511 zu agieren. Damit werden Fehler, welche unterschiedliche Schutzschichten gleichzeitig betreffen (Common-Cause und systematische Fehler) reduziert.

Ein getrenntes Sicherheitssystem stellt den Erhalt der Schutzebenen sicher und reduziert somit das Risiko von Cyber Angriffen.

Schutzebenen

Jede Schutzebene hat ein eigenes Niveau der Risikominimierung

Sicherheitstechnik unabhängig vom Patch Management der Leittechnik

Durch die intensive Nutzung von standardisierter Hardware und Software im Bereich der Prozessleittechnik besteht die Notwendigkeit für ein angemessenes Patch Management. Das Patchen behebt Schwachstellen der in Prozessleitsystemen verwendeten Software und des Betriebssystems. Problematisch ist, dass aufgrund der Komplexität der Softwarearchitektur eine analytische Bewertung der Risiken, die durch die Aktualisierung entstehen könnten, schwierig bis unmöglich sind. So können durchgeführte Patches im Prozessleitsystem z.B. auch Funktionalitäten des in das PLS integrierten Sicherheitssystems beeinflussen.

Bestehen Risiken für Personen- und/oder Umweltschäden, muss jedoch sichergestellt werden, dass in Folge des Patch-Prozesses keine Fehler zu kritischen Situationen führen. Nur die technologische Trennung von Prozessleitsystem und Sicherheitssystem stellt sicher, dass die funktionale Sicherheit durch Updates der Leitsysteme weiterhin gewährleistet ist.

Auswirkungen von Leitsystem-Updates auf das Sicherheitssystem werden durch die technologische Trennung der Systeme verhindert.

Vorteile getrennter Systeme:

  • Sowohl der Standard für funktionale Sicherheit IEC 61511 als auch der Security Standard IEC 62443 fordern getrennte Schutzebenen
  • Unabhängige "layer of protection"
  • Garantierte technische Rückwirkungsfreiheit „by design“
  • Eliminierung von "common cause"-Fehler, die zu sicherheitskritischen Situationen oder zu ungewollten Abschaltungen führt
  • Vermeidung von sicherheitskritischen Design-, Programmier- und Bedienerfehlern durch Vermischung von sicheren-/nicht-sicheren Elementen ("human common cause"-Fehler)
  • Klare Trennung der technischen und organisatorischen Verantwortungsbereiche
  • Erfüllung der Anforderungen zur Trennung nach IEC 61508/11 führt im Zweifelsfall zu mehr Rechtssicherheit
  • Unterstreicht die unterschiedlichen Lebenszyklen von Betriebs- und Schutzeinrichtungen --> Betriebseinrichtung sind dynamisch (viele Änderungen), Schutzeinrichtung sind statisch (wenig Änderungen)
  • Entspricht  „Good Engineering Practice“ für kritische Applikationen

Integriert und trotzdem sicher

Doch wie lassen sich zum einen Wirtschaftlichkeit und zum anderen die notwendige Unabhängigkeit der Systeme miteinander vereinbaren? Folgende Aspekte sind bei der Integration von Sicherheitssystemen zu betrachten:

  1. Unabhängige Engineering-Prozesse
  2. Strukturelle Integrität der Automatisierungsplattform
  3. Integration von Betriebs und Wartungsinformationen
  • 1. Unabhängige Engineering-Prozesse

    Die gemäß IEC 61511 geforderte funktionale Unabhängigkeit der unterschiedlichen Schutzebenen einer Anlage ist nicht auf die technische Implementierung der Funktionalität beschränkt. Vielmehr ist bei der Bewertung des erreichten Sicherheitsniveaus bzw. für eine höhere SIL (s. IEC 61508) ein Engineering Prozess einzuhalten, welcher die Ausführung/Prüfung durch unabhängige Abteilungen bzw. Organisationen fordert.


    Dies geschieht in der Praxis einerseits durch das Einführen eines entsprechenden Management-Prozesses, andererseits dadurch, dass nur entsprechend qualifiziertes Personal das Engineering der Sicherheitssteuerung vornehmen kann. Der Einsatz von autarken und diversitären Sicherheitssystemen mit unterschiedlichen Engineering Tools stellt dies „by design“ sicher.

    SILworX als unabhängiges Engineering Tool 

    Ein unabhängiges Engineering Tool für das Sicherheitssystem vermeidet „common cause“-Fehler und bietet dennoch die Möglichkeit für den einfachen Datenimport und für die Integration von Daten in die Bedien- und Beobachtungsfunktion des Prozessleitsystems.

    • Klare Trennung der Verantwortungs- und Aufgabenbereiche
    • Engineering und Änderungsprozesse für die Sicherheitssteuerung unabhängig von denen der Betriebseinrichtungen
    • Sichere physikalische Trennung durch unabhängige Engineering Station möglich
    • Konzentration auf die einfache und sichere Bedienung des Sicherheitssystems „Ease of use“
    • Verhindern von Anwenderfehlern durch das Unterstützen von sicheren Bedienphilosophien
    • Zugriffsschutz durch integriertes Benutzermanagement für Projekt- und Steuerungszugriff
    • Keine Nutzung von gemeinsamen Datenbanken oder gleiche Datenbankzugriffsmechanismen, welche sowohl die Konfigurationsdaten der betrieblichen Automatisierung als auch die der Sicherheitsfunktionen speichern bzw. ändern
    • Das Risiko für Manipulationen am Sicherheitssystem aufgrund von vorgenommene Änderungen am Prozessleitsystem ist somit reduziert --> einer der Wirkmechanismen des STUXNET Schadsoftware
    • Dennoch ermöglicht SILworX die umfangreiche Übernahme von Konfigurationsdaten (Tagnamen, Skalierungen, Meldetexte, Adressen etc.) und komplette Funktionen (z.B. Informationen über die umzusetzende Logik) aus übergeordneten Engineering Systemen

  • 2. Strukturelle Integrität der Automatisierungsplattform

    Eine vom Leitsystem unabhängige HIMA Sicherheitssteuerung ist deshalb robuster gegenüber Cyber Angriffen, da sie eigene entwickelte Strukturen nutzt:

    • Nutzung von HIMA proprietären Betriebssystemen, welche inhaltlich nicht veröffentlicht werden
    • Mehr als 45 Jahren Erfahrung in der Entwicklung von Sicherheitssystemen mit Code Reviews und Qualitätsmanagement
    • Reduzierung auf Funktionen, die ausschließlich für den Betrieb der HIMA Automatisierungsplattform notwendig sind
    • Geringerer Umfang und Komplexität des Betriebssystems wobei im Gegensatz zu generischen Betriebssystemen nahezu vollständige Funktionstest möglich sind

    Die Kombination von „relativer Einfachheit“ einerseits und umfangreichen Funktionstests andererseits liefert ein so großes Maß an Robustheit, dass keine regelmäßigen Patches notwendig sind.

  • 3. Integration von Betriebs und Wartungsinformationen

    Für den wirtschaftlichen Betrieb ist trotz der geforderten Unabhängigkeit eine umfassende Integration von Betriebs- und Wartungsinformationen notwendig. HIMA Systeme können in alle führenden Leitsysteme integriert werden. Wir übernehmen dabei die Verantwortung für die PLS-SIS-Integration und ermöglichen die gewünschten Funktionalitäten.

    Bei unserer Datenintegration werden alle Schnittstellen zu externen Systemen funktional vollständig im Rahmen eines „Whitelisting“ beschrieben. Dies beinhaltet:

    • Datenbereiche (Wo werden Daten geschrieben/gelesen)
    • Dateninhalte (Welche Werte dürfen die übertragenen Daten haben)
    • Schnittstellenfunktionen (Welche Kommandos werden wann akzeptiert)


    Alle Aktivitäten an einer externen Schnittstelle, die nicht den vordefinierten Regeln entsprechen, werden ignoriert. Somit können alle für die Integration eines Sicherheitssystems notwendigen Funktionen abgebildet werden.

Kontakt

Tel: +49 6202 709 0
Fax: +49 6202 709 107
securityAThima.com