Funktionale Sicherheit und Cyber-Security gemeinsam betrachten

Funktionale Sicherheit schützt Anlagen und erhält deren Produktivität. Autarke Sicherheitssteuerungen helfen, Risiken und damit die Lifecycle-Kosten zu senken. Richtig aufgebaut bildet die sichere Steuerung die letzte Verteidigungslinie gegen Cyber-Attacken.

Sicherheitsgerichtete Automatisierungslösungen müssen heute neben der Funktionalen Sicherheit (Safety) auch Cyber-Security unterstützen, also den Schutz vor Attacken über Netzwerke. Denn die Verknüpfung der Office-IT mit der Automations-IT führt zu einer offenen Netzwerkarchitektur und somit vermehrt zu Security-Risiken. Autarke Sicherheitssysteme wie Himax der Firma Hima Paul Hildebrandt können helfen, das Security-Risiko in Anlagen zu senken. Gleichzeitig erhöhen diese Systeme auch die Verfügbarkeit und Produktivität der Anlagen.

Neben der funktionalen Sicherheit ist die Produktivität ein entscheidender Faktor für jede Prozessanlage. Um die Produktivität zu garantieren, muss ein Sicherheitssystem in das Prozessleitsystem der Anlage integriert sein. Durch die Integration entsteht über Schnittstellen und Netzwerke allerdings das Risiko, dass Sicherheitsprodukte negativ beeinflusst werden. Ein Angriff auf die Integrität der Sicherheitssteuerung gefährdet auch die Integrität der funktionalen Sicherheit. An die Security-Eigenschaften einer Sicherheitssteuerung gelten daher dieselben hohen Ansprüche wie an ihre funktionalen Sicherheitseigenschaften.

Ein integriertes Sicherheitssystem vom selben Hersteller wie das Prozessleitsystem hat einige Vorteile, zum Beispiel ein einheitliches Systemkonzept und ein gemeinsamer Bus sowie ein einziges Engineering-Tool für die Standard- und funktional sichere Automation. Die Komfortgewinne gehen jedoch auf Kosten der funktionalen Sicherheit und Security. Denn alles, was ein Anwender oder die Steuerung tun kann, kann auch ein Angreifer tun. Automatismen sind Angriffspunkte und müssen kritisch geprüft werden.

Um systematische Fehler zu reduzieren, fordern die Normen IEC 61511-1 (Safety) und IEC 62443-3-3 (Security) getrennte Schutzebenen und eine Unabhängigkeit der Betriebs- und Schutzeinrichtung. Ein autarkes Prozessleitsystem und Sicherheitssystem verschiedener Hersteller bedingen per Design unterschiedliche Engineering-Tools, Datenbasen und Bedienungen. Dies vermeidet Common-Cause-Risiken.

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 wo bei 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.

Die internationale Norm IEC 62443-3-3 „Industrial communication networks – Network and system security“ fordert eine Abschottung der Produktionsnetzwerke. Dazu werden Zonen festgelegt, zum Beispiel Unternehmensnetzwerk und Leitstelle. Definierte Übergänge (Conduits) verbinden sie. Entsprechend der jeweiligen Daten oder Protokolle wird an jedem Übergang eine Firewall installiert. Und auch die kommende Revision der Norm DIN IEC 61511-1 „Funktionale Sicherheit – Sicherheitstechnische Systeme für die Prozessindustrie“ zielt in diese Richtung.

Common-Cause-Fehler vermeiden

Technische Sicherheitsmaßnahmen betreffen PC-Umgebung, Engineering-Tool, Kommunikation, sichere Steuerung und Safety-Applikation. Das BIOS-Passwort bildet die äußerste Sicherheitsschicht. Anwendergruppen sollten in der Betriebssystemumgebung nur Zugriffsrechte haben, die sie wirklich brauchen. Firewalls und Antivirensoftware oder besser noch ein Host Intrusion Prevention Systems (HIPS) verbessern den Schutz. Hierbei ist ein HIPS, auch Application Whitelisting genannt, zwar aufwendiger zu konfigurieren, bietet aber gegen bisher unbekannte Schadsoftware besseren Schutz als Antivirensoftware, da nur freigegebene Programme ausgeführt werden.

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

Silworkx, das Engineering-Tool für Himax, läuft auf einem Standard-Windows-PC. Die Software ist kompatibel zu den gängigen Antivirus-Schutzprogrammen und kann daher mit derjenigen Software eingesetzt werden, die für das jeweilige Unternehmen standardisiert und freigegeben ist. Das Programm schützt sich vor fehlerhaften Installationsdaten und Manipulationen über eine CRC-Prüfung (Cyclic Redundancy Check), die jedes Mal erfolgt, wenn die Software startet oder eine Code-Generierung stattfindet. Zusätzlich stehen MD5-Prüfsummen für die Installationsdaten zur Verfügung, um die korrekte Installation zu prüfen.

Eine Datenbankdatei in einem Hima-spezifischen Format beinhaltet die Daten für das Projekt, das mit Silworx generiert wurde, sowie die verschlüsselten Kenn- und Passwörter. Die funktionsrelevanten Projektteile sind zusätzlich über eigene CRC geschützt. Es ist möglich, bei jedem Laden der Steuerung automatisch ein Projektarchiv anzulegen. Über diese Versionshistorie kann der Nutzer alle Änderungen nachvollziehen. Diese Backup-Funktion erlaubt 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 internationale Security-Norm IEC 62443-3-3 fordert eine Abschottung der Produktionsnetzwerke.

Die erste Stufe beinhaltet das Zugriffsrecht auf die Projektdaten. Hier werden die Benutzer mit individuellem Passwort angelegt und Gruppen zugeordnet. In der zweiten Stufe legt der Anwender die Zugriffsrechte der Gruppen pro Steuerung fest. Hierfür wird jeweils ein Passwort definiert, das beliebig komplex sein kann, da es der Benutzer nicht kennen muss: Der Benutzer kennt nur sein eigenes Passwort. Ändert sich der Benutzer oder dessen Passwort, wird die Steuerung selbst nicht verändert. Zugriffe werden nachvollziehbar im Projektlog und in der Steuerungsdiagnose aufgezeichnet.

Die Ebenen trennen

Das Konzept der Trennung ist in den Hima-Steuerungssystemen durchgängig integriert. Für eine hohe Cyber-Security können für die Kommunikation verschiedene Schutzebenen mit einer virtuellen oder physikalischen Trennung aufgebaut werden. Die CPU-Module der Himax führt die Sicherheitsanwendung aus und kann 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ültige und nicht bekannte Protokollanfragen sowie das Lesen oder Schreiben von nicht konfigurierten Adressbereichen werden von der Steuerung ignoriert. Um das Risiko weiter zu reduzieren, können Anwender ein physikalisch getrenntes Kommunikationsmodul einsetzen. 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.

Achilles-Test simuliert Angriffe

Der Anbieter bezieht von Beginn an Maßnahmen zur Cyber-Security in die Produktentwicklung mit ein. Dazu zählt das Achilles-Testverfahren von Wurldtech, bei dem ständig aktualisierte Tests im Entwicklungsprozess aller neuen Produkte durchgeführt werden. Der Test ist international für die Überprüfung industrieller Cyber-Security anerkannt und beinhaltet eine Simulation von Cyber-Angriffen. Das Prozessormodul und das Kommunikationsmodul von Himax haben bei diesen Tests das Achilles-Level 1-Zertifikat erhalten.
Die sicherheitsgerichtete Steuerung Himax selbst bietet mehrere Möglichkeiten für eine sichere Kommunikation. Nicht genutzte physikalische Ports können deaktiviert und somit ein unbefugter Zugriff verhindert werden.

Des Weiteren ist ein abgestuftes Blockieren von Steuerungszugriffen möglich. Über Systemvariablen können Online-Änderungen und das Forcen von Werten blockiert werden. Der 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. Außerdem bietet die Safety-Applikation selbst Maßnahmen für eine erhöhte Security. So kann beispielsweise der CRC-Schutz genutzt werden, um Programmänderungen im System anzuzeigen und Alarme auszulösen.
Insgesamt lässt sich festhalten: Es gibt keine Safety ohne Security. Besteht über Schnittstellen oder die Integration ein Risiko, das 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, vermeidet die sichere Steuerung zufällige und systematische Fehler und bildet somit 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. Autarke Sicherheitssysteme reduzierten über den Einsatz diversitärer Technik das Security-Risiko „by design“. Do

Das bleibt hängen

Gesamtsicherheit von Industrieanlagen

• Integrierte Lösungen haben Vor- und Nachteile, Automatismen und Komfort-Funktionen sollten geprüft werden.
• Normen fordern getrennte Schutzebenen und eine Unabhängigkeit der Betriebs- und Schutzeinrichtung.
• Autark aufgebaute, sichere Steuerungen helfen, zufällige und systematische Fehler zu vermeiden.