Safety bildet die Basis für jede Art von Prozessanlage, denn ohne Beherrschung der funktionalen Sicherheitsrisiken darf eine Anlage nicht betrieben werden. Durch die Integration eines Sicherheitssystems in das Prozessleit-system von Anlagen entsteht über Schnittstellen und Netzwerke allerdings in zweierlei Hinsicht ein Risiko: Ein Angriff auf die Integrität der Sicherheitssteuerung gefährdet auch die Integrität der funktionalen Sicherheit. Angesichts der Entwicklung, dass die Verknüpfung der Office-IT mit der Automations-IT zu einer offenen Netzwerk-Architektur vermehrt zu Sicherheits-Risiken in der Automation führt, ist an die Security-Eigenschaften einer Safety-Steuerung derselbe hohe Anspruch zu stellen wie an ihre funktionalen Sicherheitseigenschaften.

Auf den ersten Blick können wirtschaftliche Gründe dafür sprechen, ein integriertes Sicherheitssystem einzusetzen, das von demselben Hersteller stammt, der auch das Prozessleitsystem liefert. Schließlich versprechen ein einheitliches Systemkonzept und ein gemeinsamer Bus sowie ein einziges Engineerring-Tool für die Standard- und funktional sichere Automation ei-nige Vorteile. Solche Komfortvorteile können allerdings auch Nachteile in den Bereichen funktionale Sicherheit und Security mit sich bringen, da sich dadurch die Angriffsfläche entsprechend vergrößert.

Bei einem integrierten Leit- und Sicherheitssystem ‚aus einer Hand‘ gilt es daher, alle Automatismen und Komfortvorteile kritisch zu prüfen. Je offener und integrierter eine Sicherheitssteuerung ist, umso mehr Aufwand für Or-ganisation und Security ist erforderlich. Security-Angriffspunkte stellen hier Automatismen dar, wie zum Beispiel Diagnose-Anzeigen, die automatische Interaktion zwischen Engineering-Tool und Steuerung sowie die Interaktion zwischen der Visualisierung des Leitsystems und dem Sicherheitssystem.

Normen fordern getrennte Schutzebenen

Um systematische Fehler zu reduzieren, fordern die beiden Normen IEC 61511-1 (Safety) und IEC 62443-3-3 (Security) getrennte Schutzebenen und eine Unabhängigkeit der Betriebs- und Schutzeinrichtung. Autarke  Prozess-leitsys­teme und Sicherheitssysteme von verschiedenen Herstellern bedingen per Design unterschiedliche En-gineering-Tools und Datenbasen und eine ­unterschiedliche Bedienung. Das heißt: Solche Systeme von verschiedenen Herstellern vermeiden aufgrund diversitärer Technik Common-Cause-Risiken und reduzieren das Security-Risiko.

Die internationale Security-Norm IEC 62443-3-3 fordert eine Abschottung der Produktionsnetzwerke.

© Hima

Dabei sorgt die diversitäre Technik auch für eine klare Trennung der Verantwortungsbereiche und unterstützt die unterschiedliche Handhabung von Betriebs- und Schutzeinrichtungen in der Praxis. Denn während bei der Betriebseinrichtung tägliche Optimierung, Aktualisierung und Änderung im Fokus stehen, gilt für die Schutzeinrichtung, dass diese selten und nur von qualifiziertem Personal bedient werden darf. Jeder Zugriff auf eine Schutzeinrichtung stellt ein potenzielles Risiko dar und Veränderungen sind nur über einen ‚Management of Change‘-Prozess erlaubt.

Die internationale Norm IEC 62443-3-3 „Industrial communication networks – Network and system security“ fordert eine Abschottung der Produktions-Netzwerke. Dazu werden einzelne Zonen festgelegt (Unternehmensnetzwerk, Leitstelle, Sicherheitssystem, Prozessleitsystem etc.), die über definierte Übergänge (Conduits) verbunden sind. Entsprechend der jeweiligen Daten oder Protokolle, die auszutauschen sind, wird an jedem Übergang ein Schutz in Form einer Firewall installiert. Für dieses Konzept ist es zwingend erforderlich, dass die ausgetauschten Daten klar definiert sind. Nur wenn dieser Aufbau dem Anwender bekannt ist, lassen sich entsprechende Schutzmaßnahmen vorsehen.

Auch die kommende Revision der Norm DIN IEC 61511-1 „Funktionale Sicherheit – Sicherheitstechnische Systeme für die Prozessindustrie“ zielt in diese Richtung. Sie spricht sich dafür aus, die Unabhängigkeit, Diversität, physikalische Trennung und Common-Cause-Fehler zwischen Schutzebenen zu prüfen, zu bewerten und sicherzustellen. Diese beinhaltet des Weiteren den eindeutigen Hinweis, dass ein ­Sicherheitssystem – soweit praktikabel – physikalisch getrennt sein sollte. Aktuelle Diskussionen in Standardisierungsgremien wie Namur oder DKE haben ebenfalls zum Thema, dass es für die Beherrschung von Security-Risiken einer eigenen sicheren Trennung und eines entsprechend definierten Überganges bedarf. Hierfür müssen im Zweifelsfall auch automatische Komfortfunktionen deaktiviert werden, um die Komplexität und damit die Security-Risiken zu reduzieren.

Security: die technischen Maßnahmen

Ein Sicherheitssystem muss vielfältige Eigenschaften besitzen, um es gegen kombinierte Safety-Security-Risiken härten zu können. Die technischen Maßnahmen betreffen verschiedene Bereiche:

1. PC-Umgebung
Das BIOS-Passwort bildet die äußerste Sicherheitsschicht, um den PC für das Engineering-Tool des Sicherheitssystems gegen unerlaubte Zugriffe zu schützen. Gemäß dem Grundprinzip, nur zu unterstützen, was benötigt wird, sollten in der Betriebssystem-Umgebung Anwender- und Gruppenrichtlinien mit reduzierten Zugriffsrechten eingerichtet werden.

Eine Firewall und eine Antiviren-Software oder besser noch ein Host Intrusion Prevention System (HIPS) verbessern den Security-Schutz weiter. Hierbei ist ein HIPS – auch Application Whitelisting genannt – zwar aufwen-diger zu konfigurieren, bietet aber vor allem gegen bisher unbekannte Schadsoftware einen besseren Security-Schutz als Antiviren-Software, da nur die vom Anwender freigegebenen Programme ausgeführt werden dürfen.

Um die verschiedenen Security Maßnahmen richtig zu konfigurieren, ist es notwendig, dass die erforderlichen Ports und Benutzerrechte für das Engineer-ing-Tool bekannt sind. Zusätzlich ist es erforderlich, dass die Engineering-Software zur Security-Software anderer Hersteller kompatibel ist. Damit kann der Anwender flexibel die für ihn am besten passenden oder vorgeschriebenen Security-Produkte einsetzen. Auch für diese Schutzebenen gilt das Prinzip der Diversität, das heißt der Einsatz von Produkten unterschiedlicher Hersteller vermeidet gleichartige Fehler.

2. Engineering-Tool

Viele Engineering-Werkzeuge laufen auf einem Standard-PC mit Windows. So beispielsweise auch das Tool SILworX für die Sicherheitssteuerungen von Hima. Die Software ist kompatibel zu allen gängigen Antivirus-Schutzprogrammen und daher mit der Antivirus-Software einsetzbar, die für das jeweilige Unternehmen standardisiert und freigegeben ist. Das Tool schützt sich vor fehlerhaften Installationsdaten und Manipulationen über eine CRC-Prüfung (Cyclic Redundancy Check), die jedes Mal erfolgt, wenn die Software gestartet wird oder eine Code-Generierung stattfindet. Zusätzlich stehen dem Anwender MD5-Prüfsummen für die Installationsdaten zur Verfügung, um die Korrektheit der Installation zu prüfen.

Beim Engineering-Tool SILworX schützt ein zweistufiges Benutzermanagement mit konfigurierbaren Zugriffsrechten sowohl das Projekt als auch das Sicherheitssystem.

© Hima

Das beispielhaft erwähnte Engineering-Tool besitzt noch weitere Merkmale, die Security fördern: Eine Datenbankdatei in einem herstellerspezifischen Format beinhaltet die Daten für das generierte Projekt sowie die verschlüsselten Kenn- und Passwörter. Die funktionsrelevanten Projektteile sind zusätzlich über eigene CRC geschützt, so dass auch eine Veränderung der Projektdaten mit dem vorhandenen sicheren Code-Vergleicher erkannt und nachvollzogen werden kann.

Es ist zudem möglich, bei jedem Laden der Steuerung automatisch ein Projektarchiv anzulegen. Über diese lückenlose Versionshistorie sind alle Änderungen nachvollziehbar. Diese Backup-Funktion erlaubt daneben das Identifizieren und Wiederherstellen des zuletzt gültigen Projektes im Rahmen einer ‚Recovery Procedure‘.

Ein zweistufiges Benutzermanagement für die Projekt- und Steuerungszugriffe sorgt für zusätzlichen Schutz. Die erste Stufe beinhaltet das Zugriffsrecht auf die Projektdaten. Hier können die personalisierten Benutzer mit individuellem Benutzerpasswort angelegt und Benutzergruppen zugeordnet werden. In der zweiten Stufe werden die Zugriffsrechte pro Steuerung festgelegt. Aus den angelegten Benutzergruppen ist auswählbar, welche Gruppe auf die jeweilige Steuerung zugreifen darf. Hierfür wird jeweils ein spezielles Passwort definiert. Dieses Passwort kann beliebig komplex sein, da es dem Benutzer nicht bekannt sein muss. Vorteile dieses Verfahrens sind, dass der Benutzer nur sein eigenes Passwort kennt und bei einer Änderung der individuellen Benutzer oder deren Passwörter die Steuerung selbst nicht verändert wird. Damit erhöht sich der Security-Schutz und bei einem Mitarbeiterwechsel oder einer Passwort-Aktualisierungen ist es nicht notwendig, Änderungen in der Sicherheitssteuerung vorzunehmen. Zugriffe werden im Projektlog und in der Steuerungsdiagnose aufgezeichnet, was eine einfache Nachvollziehbarkeit ermöglicht.

3. Sichere Steuerung

Die sicherheitsgerichtete Steuerung selbst kann etliche Möglichkeiten für eine sichere Kommunikation bieten – etwa indem nicht genutzte physikalische Ports deaktivierbar sind und somit ein unbefugter Zugriff verhindert wird. Eine weitere Möglichkeit ist ein abgestuftes Blockieren von Steuerungszugriffen über Systemvariablen. Ein Read-only-Betrieb bietet zusätzlichen Schutz vor Manipulationen. Über einen Schlüsselschalter am Installationsort des Systems können die Systemvariablen über einen digitalen Eingang beschrieben und freigegeben oder gesperrt werden. Wird dieser Schlüssel ‚abgezogen‘, erlaubt die Steuerung im RUN-Modus nur das Lesen – egal, welche Zugriffe über das Netzwerk erfolgen.

4. Kommunikation

Für eine hohe Cyber-Security können für die Kommunikation verschiedene Schutzebenen mit einer virtuellen oder physikalischen Trennung aufgebaut werden. Im Beispiel der Himax-Sicherheitssteuerung führt die CPU Sicherheitsanwendung aus und kann zudem  Kommunikationsaufgaben übernehmen. Beide Bereiche sind auf der CPU durch einen SIL3-zertifizierten Schutz des Speichers und des Timings zwischen dem Kommunikations- und Safety-Bereich getrennt.

Wird eine nicht sichere Datenübertragung direkt an der CPU angeschlossen, sorgt eine integrierte Firewall für eine virtuelle Trennung, indem nur die vom Anwender konfigurierten Protokolle und Daten unterstützt werden. Ungül-tige beziehungsweise nicht bekannte Protokollanfragen oder das Lesen/Schreiben von nicht konfigurierten Adressbereichen werden von der Steuerung einfach ignoriert.

Für eine weitere Risikoreduzierung ist ein physikalisch getrenntes Kommunikationsmodul einsetzbar. Das Modul hat dieselben Security-Firewall-Eigenschaften wie das Prozessormodul und ist lediglich über den internen Systembus mit der CPU verbunden. Da das Kommunikationsmodul nicht die CPU beeinflussen kann, ist die sichere Funktion physikalisch von der nicht sicheren Kommunikation getrennt.

5. Safety-Applikation

Last but not least kann die Safety-Applikation selbst Maßnahmen für eine erhöhte Security bieten. So lässt sich beispielsweise der CRC-Schutz nutzen, um Programmänderungen im System anzuzeigen und Alarme auszulösen.

Das Fazit: Es gibt keine Safety ohne Security. Besteht über Schnitt­stellen oder die Integration ein Risiko, dass die Integrität der funktionalen ­Sicherheit gefährdet, verdient Security dieselbe hohe Aufmerksamkeit wie das  Thema Safety. Richtig aufgebaut – das heißt so autark und separat wie möglich, um zufällige und syste­matische Fehler zu vermeiden –, bildet die sichere Steuerung die letzte ­Verteidigungslinie. Die Security-Norm IEC 62443-3-3 und die kommende ­Revision der Safety-Norm IEC 61511-1 unterstützen diesen Ansatz, indem sie getrennte Schutzebenen fordern.

Autoren: Stefan Ditting ist Produktmanager Kommunikation bei Hima und Thomas Janzer ist Produktmanager Software bei Hima.