Funktionale Sicherheit bildet die Basis für jede Art von Prozessanlage. Denn ohne Beherrschung der funktionalen Sicherheitsrisiken darf eine Anlage nicht betrieben werden. Neben der Sicherheit ist die Produktivität ein entscheidender Faktor für die Unternehmen. Um Produktivität sicherzustellen, muss ein Sicherheitssystem in das Prozessleitsystem von Anlagen integriert sein. Durch die Integration entsteht über Schnittstellen und Netzwerke allerdings ein Risiko, sodass 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 muss daher derselbe hohe Anspruch gestellt werden wie an ihre Eigenschaften bezüglich der Funktionalen Sicherheit.
Integrierte Lösung ist nicht einfach beherrschbar
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 Engineering-Tool für die Standard- und funktional sichere Automation einige Vorteile. Doch Komfortvorteile stehen meist Nachteilen in der Funktionalen Sicherheit und Security gegenüber. Denn alles, was ein Anwender oder die Steuerung tun kann, kann eben auch ein Angreifer tun. Eine größere Angriffsfläche ist die Folge daraus.
Bei einem integrierten Leitsystem und Sicherheitssystem „aus einer Hand“ müssen alle Automatismen und Komfortvorteile kritisch geprüft werden. Je offener und integrierter eine Sicherheitssteuerung ist, umso schwieriger ist die Organisation und Realisierung von Security-Maßnahmen. Denn nur, was man kennt, kann man auch schützen. Hier stellen Automatismen wie Diagnoseanzeigen, die automatische Interaktion zwischen Engineering-Tool und Steuerung sowie die Interaktion zwischen der Visualisierung des Leitsystems und dem Sicherheitssystem Security-Angriffspunkte dar.
Normen fordern getrennte Schutzebenen
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. IEC 62443-3-3 „Industrial communication networks – Network and system security“ sieht eine Abschottung der Produktionsnetzwerke vor. Dazu werden einzelne Zonen festgelegt wie Unternehmensnetzwerk, Leitstelle, Sicherheitssystem, Prozessleitsystem und so weiter, die über definierte Übergänge, genannt Conduits, verbunden sind. Entsprechend der jeweiligen Daten oder Protokolle, die ausgetauscht werden, wird ein Schutz an jedem Übergang in Form einer Firewall installiert. Für dieses Konzept ist es zwingend erforderlich, dass die ausgetauschten Daten klar definiert sind. Nur wenn diese dem Anwender bekannt sind, können entsprechende Schutzmaßnahmen vorgesehen werden.
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-Vermeidung zwischen Schutzebenen zu prüfen, zu bewerten und sicherzustellen. Die Norm beinhaltet des Weiteren den eindeutigen Hinweis, dass ein Sicherheitssystem, soweit praktikabel, physikalisch getrennt sein sollte. Aktuelle Diskussionen in Standardisierungsgremien wie Namur, DKE, und anderen haben ebenfalls zum Thema, dass es für die Beherrschung von Security-Risiken einer eigenen sicheren Trennung und eines entsprechend transparenten Übergangs bedarf. Hierfür müssen im Zweifelsfall auch automatische Komfortfunktionen deaktiviert werden, um die Komplexität und damit die Security Risiken zu reduzieren.
Security-Risiken reduzieren
Ein Sicherheitssystem muss vielfältige Security-Eigenschaften besitzen, um es gegen Safety-Security-Risiken zu härten oder um das Risiko in den Anlagen reduzieren zu können. Die technischen Maßnahmen betreffen verschiedene Bereiche:
PC-Umgebung
Engineering-Tool
Kommunikation
Sichere Steuerung
Safety-Applikation
PC-Umgebung: Common-Cause-Fehler vermeiden – Die PC-Umgebung bildet die äußerste Sicherheitsschicht, um den PC für das Engineering-Tool des Sicherheitssystems gegen unerlaubte Zugriffe zu schützen. Hierbei wird durch ein BIOS-Passwort (BIOS, Basic Input/Output System), den Einsatz einer Firewall und einer Antivirensoftware oder besser noch Application Whitelisting der Security-Schutz verbessert. Damit der bestmögliche Schutz aufgebaut werden kann, ist es entscheidend, dass das Engineering-Tool möglichst frei mit Security-Produkten unterschiedlicher Hersteller kombiniert werden darf.
Engineering-Tool: Umfassende Schutzmaßnahmen – Die Anwendung von Engineering-Tools von verschiedenen Herstellern vermeiden aufgrund diversitärer Technik Common-Cause-Risiken und reduzieren das Security-Risiko. 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 dürfen. Fehlerhafte Installationsdaten und Manipulationen sollten vom Engineering-Tool über integrierte Prüfungen erkannt werden. Für die Prüfung der Korrektheit der Installation müssen dem Anwender MD5-Prüfsummen zur Verfügung stehen.
Damit es bei Mitarbeiterwechsel oder Passwortaktualisierungen nicht notwendig ist, Änderungen in der Sicherheitssteuerung vorzunehmen, sollte ein zweistufiges Benutzermanagement für die Projekt- und Steuerungszugriffe vorhanden sein. 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 festgelegt, mit denen die Benutzergruppen auf die jeweilige Steuerung zugreifen dürfen. Hierfür wird jeweils ein spezielles Passwort definiert, welches beliebig komplex sein kann, da es dem Benutzer nicht bekannt sein muss.
Damit erhöht sich der Security-Schutz, Zugriffe werden im Projektlog und in der Steuerungsdiagnose aufgezeichnet, was eine einfache Nachvollziehbarkeit ermöglicht. 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 werden muss.
Kommunikation: Getrennte Schutzebenen – Das Konzept der Trennung sollte auch in den Steuerungssystemen durchgängig integriert sein. Für eine hohe Cyber-Security müssen für die Kommunikation verschiedene Schutzebenen mit virtueller oder physikalischer Trennung aufgebaut werden. Eine integrierte Firewall sorgt für eine virtuelle Trennung, indem nur die vom Anwender konfigurierten Protokolle und Daten unterstützt werden. Ungültige beziehungsweise nicht bekannte Protokollanfragen oder das Lesen/Schreiben von nicht konfigurierten Adressbereichen werden von der Steuerung einfach ignoriert.
Bei der physikalischen Trennung wird zusätzlich ein getrenntes Kommunikationsmodul eingesetzt. Da dieses nur Daten zur Verfügung stellt und die CPU nicht beeinflussen kann, ist die sichere Funktion physikalisch von der nicht sicheren Kommunikation getrennt.
Sichere Steuerung: Viele Schutzmöglichkeiten – Die sicherheitsgerichtete Steuerung muss Möglichkeiten bieten, unbefugte Zugriffe effektiv zu verhindern, zum Beispiel durch Deaktivierung von nicht genutzten physikalischen Ports oder durch abgestuftes Blockieren von Steuerungszugriffen. Dabei müssen Änderungen am Applikationsprogramm oder das Forcen von Werten blockierbar sein. Es sollte möglich sein, diese Funktionen über Schlüsselschalter am Installationsort des Systems zu aktivieren. Ein Read-only-Betrieb bietet dabei zusätzlichen Schutz vor Manipulationen. Wird dieser Schlüssel „abgezogen“, erlaubt die Steuerung im RUN-Modus nur das Lesen, egal, welche Zugriffe über das Netzwerk erfolgen.
Safety-Applikation: Anzeige von Programmänderungen – Last but not least bietet die Safety-Applikation selbst Maßnahmen für eine erhöhte Security. So kann beispielsweise der CRC-Schutz (Cyclic Redundancy Check, zyklische Redundanzprüfung) genutzt werden, um Programmänderungen im System anzuzeigen und Alarme auszulösen.
Safety und Security gemeinsam beachten
Es gibt kein Safety ohne Security. Besteht über Schnittstellen 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 systematische Fehler zu vermeiden –, bildet die sichere Steuerung die letzte Verteidigungslinie. Autarke Sicherheitssysteme reduzieren über den Einsatz diversitärer Technik das Security-Risiko „by design“.
