Die wechselseitigen Beziehungen von Safety und Security werden aktuell stark diskutiert. Offensichtliche Parallelen sind zwischen den beiden Domänen ebenso erkennbar wie gravierende Unterschiede. Die Krux dabei: Eine allgemein akzeptierte Vorgehensweise wurde noch nicht entwickelt und auch in den einschlägigen Normen finden die Hersteller und Betreiber von Maschinen wenig Hilfestellung zu diesem Thema.

Bei der Frage, welche Security-Maßnahmen sich für den Schutz von Safety-Systemen eignen, ist es sinnvoll, sich die Natur der gefährlichen Fehler vor Augen zu halten. Safety unterscheidet prinzipiell zwischen stochastischen Fehlern und systematischen Fehlern. Mitigationsmaßnahmen für stochastische Fehler umfassen zum Beispiel Redundanz und Selbstprüfung, während systematische Fehler durch Verifikations- und Validierungsmaßnahmen sowie durch die Qualität des Entwicklungsprozesses aufgedeckt beziehungsweise vermieden werden. Je höher der geforderte Safety Integrity Level (SIL), desto rigoroser die Maßnahmen. Die Ausnutzung von Security-Lücken hingegen erfordert ein gezieltes Vorgehen eines Angreifers, welcher eine bestimmte Motivation sowie bestimmte Fähigkeiten und finanzielle Mittel zur Verfügung haben muss.

Für die Bestimmung des erforderlichen Safety Integrity Levels (SIL) nach IEC 62061 oder des Performance Levels nach ISO 13849 für eine identifizierte Gefährdung sind in diesen Normen konkrete Verfahren definiert. Bei der Führung des Sicherheitsnachweises ist zu belegen, dass vom System eine definierte und vom SIL abhängige, maximal tolerierbare statistische Gefährdungsrate nicht überschritten wird.

Ein statistischer Ansatz zur quantita­tiven Beschreibung der Effizienz von Security-Maßnahmen analog zur Vorgangsweise im Zuge der Ermittlung von Ausfallraten in Safety-Systemen erscheint nicht sinnvoll, da es noch keine allgemein anerkannte Kalibrierung von Security-Risiken auf Ausfallwahrscheinlichkeiten gibt. Ferner stehen statistische Daten hinsichtlich der Wahrscheinlichkeit eines Angriffs oft nicht zur Verfügung. Auch wären derartige Daten wenig hilfreich, da statistische Daten wenig geeignet sind, die Häufigkeit und Professionalität von Angriffen in der Zukunft zu prognostizieren. Dies ist ein wesentlicher Unterschied zu Safety-Betrachtungen: Hier wird aus Feldbeobachtungen in der Vergangenheit auf das Ausfallverhalten in der Zukunft geschlossen und daraus mögliche Systemarchitekturen für das Erreichen der erforderlichen Sicherheitsziele abgeleitet. Eine wichtige Annahme in Safety-Systemen ist zudem, dass über einen gewissen Zeitraum das Ausfallverhalten konstant ist. Nur solange dies voraus­gesetzt werden kann, sind auch die in den maßgeblichen Normen angeführten Berechnungsmethoden gültig.

Safe&secure – ein integrierter Ansatz

Bild 1: Integrierter Entwicklungs­prozess von Safety und Security basierend auf der Norm ISA 62443-3-2 (Workingdraft) mit Verbindung zum Safety-­Entwicklungs­prozess.

© Bachmann Electronic

Die Normenfamilie ISA/IEC 62443 definiert eine Vorgehensweise, wie sich ausgehend von einer Risiko-Analyse konkrete Security-Maßnahmen für ein ‚Industrial Automation and Control System‘ (IACS) ableiten lassen. Der ­aktuelle Stand dieser Normen berücksichtigt Safety nur als potenzielles ­Risikogebiet, Verbindungen zum Safety-Lebenszyklus werden nicht gemacht. Die von Bachmann Electronic vorgeschlagene Vorgehensweise ist in Bild 1 dargestellt.

Die Safety-Analyse

Im Vorfeld der Security-Risiko-Analyse führt der Hersteller des Safety-Systems eine Safety-orientierte Fehler-Möglichkeits- und Fehler-Einfluss-Analyse (FMEA) durch (SA1). In diesem Zuge werden alle möglichen Fehler identifiziert, welche die Sicherheitsintegrität beeinträchtigen können (SA2). Sind alle erdenklichen Fehler identifiziert, werden entsprechende Safety-Maßnahmen definiert, um stochastische Ursachen der festgestellten Gefährdungen zu limitieren (SA3). Systematische Fehler im Entwicklungsprozess der Hard- oder Software sind durch entsprechende Verifikations- und Validierungsmaßnahmen auszuschließen.

Im Zuge von Schritt SA4 wird analysiert, welche der identifizierten Fehler ein potenzieller Angreifer hervorrufen könnte und welche davon nicht schon durch in SA3 definierte Maßnahmen abgedeckt sind. Dabei sind sowohl die vom Hersteller vorgesehenen Einsatz-Szenarien der Safety-Steuerung als auch der gesamte Lebenszyklus des Safety-Systems in die Betrachtung miteinzubeziehen. Geht es um die Informationssicherheit von Safety-Steuerungen, so gilt es auch die diesbezüglichen Schutzziele zu definieren. Aus Sicht der Sicherheit von Personen und Anlagen ist hauptsächlich die Integrität von Daten, Authentizität, Verfügbarkeit und zeitliche Deterministik von Bedeutung. Schutzziele wie Vertraulichkeit sind hingegen von untergeordneter Bedeutung.

Das Ergebnis dieser Analyse listet alle möglichen Verwundbarkeiten auf, welche die Integrität der funktionalen Sicherheit gefährden könnten und zwar für den Fall, dass ein Angreifer Zugang zum System erlangt.

Die Security-Analyse

Bei der Security-Analyse genügt es nicht, eine einzelne Steuerung oder Produktionsmaschine isoliert zu betrachten. Vielmehr sind stets das gesamte IT-Netzwerk des Anlagenbetreibers und die von diesem Netzwerk abhängenden Assets in die Analyse einzubeziehen. Im Verlauf der Analyse wird dieses Netzwerk in Zonen mit ähnlichen Security-Anforderungen eingeteilt und es werden IT-Schutzmaßnahmen für jede Zone bestimmt. Der Ablauf der Security-Analyse ist ebenfalls in Bild 1 dargestellt.

Ausgangspunkt ist eine High-Level-Risiko-Analyse (SE1) mit dem Ziel, für konkrete Angriffs-Szenarien das vom Anlagenbetreiber gerade noch akzeptierte Risiko (RA) zu bestimmen. Die Schutzziele der Safety werden dabei als Risikogebiet in die Analyse einbezogen.

Im nächsten Schritt (SE2) erfolgt die Einteilung des IT-Netzwerks in die erwähnten Zonen mit ähnlichen Security-Anforderungen. Dabei wird das Ergebnis der Highlevel-Risiko-Analyse berücksichtigt. Weiterhin werden Kommunikationsverbindungen, sogenannte Conduits, zwischen den verschiedenen Zonen definiert. Die Vorabversion der Norm ISA 62443-3-2 macht konkrete Vorgaben für diese Aufteilung: Unter anderem sollen nicht nur unterschied­liche Zonen für Geschäfts-IT und An­lagensteuerungen eingerichtet werden, sondern Anlagen mit Safety-Anforderungen sollen ebenfalls in eigenen Zonen zusammengefasst werden.

Bei der detaillierten Risiko-Analyse (SE3), welche für jede Zone mit schutzbedürftigen Assets durchzuführen ist, sind dieselben Risikogebiete ins Auge zu fassen wie in Schritt SE1. Dazu ­werden konkrete Bedrohungs-Sze­narien in Verbindung mit bekannten Verwundbarkeiten betrachtet. Für diese Paare aus Bedrohung und Verwund­barkeit werden jeweils die Auswirkung und die Wahrscheinlichkeit eines erfolg­reichen Angriffs qualitativ bestimmt und anschließend das daraus resultierende Risiko abgeleitet. Für diejenigen Zonen, in denen sich Safety-Steue­rungen befinden, sind die Ergebnisse des Schritts SA4 aus der Safety-Ana­lyse grundlegender Teil der Risikobe­wertung.

Im Rahmen der detaillierten Risiko-Analyse sind für die Security relevante Annahmen zu definieren und zu berücksichtigen. Solche Annahmen können beispielsweise die physische Sicherheit der Anlage betreffen. Schutzmaßnahmen zur Cyber-Security werden hingegen noch nicht einbezogen. Das aus der Analyse folgende Risiko wird daher ungemildertes Risiko (Ru) genannt.

Als nächstes erfolgt die Bestimmung eines sogenannten ‚Security-Level-­Target‘ (SL-T) für die betrachtete Zone (SE4). Der Security-Level ist als Maß für die Fähigkeiten und die Ressourcen zu verstehen, die ein Angreifer aufbringen muss, um die spezifischen Schutzmaßnahmen zu umgehen. Je höher der Security-Level, desto mehr Schutzmaßnahmen müssen umgesetzt werden und es wird für einen Angreifer entsprechend schwieriger diese zu umgehen.

Der SL-T berechnet sich aus dem Quotienten Ru/RA, welcher auch Cyber-Risk-Reduction-Factor (CRRF) genannt wird. Ist der SL-T bestimmt, lassen sich auf Basis der Norm IEC 62443-3-3 konkrete Security-Maßnahmen ableiten.

Nachdem in Schritt SE4 die laut Norm notwendigen Schutzmaßnahmen abgeleitet wurden, erfolgt nun in Schritt SE5 die Bestimmung der tatsächlich umsetzbaren Security-Maßnahmen. Es ist aber möglich, dass die im Automatisierungssystem verwendeten Komponenten nicht alle erforderlichen Schutzmaßnahmen unterstützen. Die Schnittmenge aus den erforderlichen und tatsächlich unterstützten Schutzmaßnahmen wird SL-C genannt. Unter Berücksichtigung der im SL-C umsetzbaren Security-Maßnahmen werden die Auswirkung und die Wahrscheinlichkeit eines erfolgreichen Angriffs für die identifizierten Bedrohungen und Verwundbarkeiten neu bestimmt und das verbleibende Restrisiko (RR) abgeleitet.

Falls dieses Restrisiko akzeptiert wird, ist der Prozess abgeschlossen und die Ergebnisse sind dokumentierbar (SE6). Ist das Restrisiko nicht akzeptabel, lassen sich gezielt Security-Maßnahmen aus höheren Security-Level verwenden, sofern sie von den Komponenten unterstützt werden (SE7). Gegebenenfalls sind andere Komponenten zu verwenden, um die Anzahl der umsetzbaren Security-Maßnahmen zu erhöhen.

Konsequente Umsetzung

Prinzipiell kann die Umsetzung jeder einzelnen Security-Maßnahme entweder als Security-Layer im Safety-System selbst erfolgen oder über eine Gateway-Funktion an der Zonenschnittstelle zwischen Betriebsführung und Safety. Werden Security-Maßnahmen im Safety-System integriert, ist der Systemarchitekt oft mit widersprüchlichen Anforderungen konfrontiert. So erfordern kryptografische Verfahren Ressourcen, welche an den Kommunikations-Endpunkten einer Sicherheitssteuerung oft nicht vorhanden sind. Auch steht mitunter die Forderung nach deterministischer Kommunikation im Konflikt zum zeitlichen Verhalten kryptografischer Algorithmen.

Ein maßgeblicher Unterschied zwischen dem Lebenszyklus der funktionalen Sicherheit und dem der Informationssicherheit besteht in der Praxis hinsichtlich der Häufigkeit von Software-Updates an laufenden Systemen. Während eine wohldefinierte Vorgangsweise zum Einspielen von Security-Patches Teil jedes Security-Lifecycles ist, erfordert die im Allgemeinen wesentlich höhere Software-Qualität von Safety-Software wesentlich seltenere Updates, welche aufgrund der notwendigen Zertifizierungsschritte auch sehr kostenintensiv sind. Aus diesem Grund muss sichergestellt sein, dass Änderungen in der Security-Schicht stets rückwirkungsfrei auf den Safety-Teil der Steuerung durchführbar sind, damit keine Re-Zertifizierung notwendig ist beziehungsweise die damit verbundenen Kosten möglichst gering gehalten werden können.

Vier Security-Level anwählbar

Bild 2: Das M1-Automatisierungssystem von Bachmann vereint Safety und Security in einem integrierten Ansatz.

© Bachmann Electronic

Bild 2 zeigt das M1-Automatisierungssystem von Bachmann, welches die bisher diskutierte Herangehensweise konsequent umsetzt. Die Lösung umfasst eine Standardsteuerung für die Umsetzung der Steuerungs- und Betriebsführungsaufgaben, während sicherheitsrelevante Aufgaben von der SLC284-Safety-Steuerung samt ihren zugeordneten Eingabe- und Ausgabemodulen realisiert werden. Die Vernetzung beider Steuerungen erfolgt über die Backplane.

Beispielhaft sei eine informationstechnische Gefährdung der Safety-Integrität für die Illustration der in Bild 1 vorgestellten Methodik herangezogen. Der Datenverkehr zwischen der Safety-Steuerung und den zugehörigen Eingabe- und Ausgabemodulen ist Safety-relevant und damit gemäß den Anforderungen für sichere Kommunikation aus EN 50159 aus Safety-Sicht abzusichern. Um Daten aus der Safety-Steuerung auch für die Betriebsführung zur Verfügung stellen zu können, werden Safety-Datenpakete parallel zu Prozessdaten über die Backplane geführt. Damit werden diese jedoch aus Security-Sicht angreifbar und sind entsprechend zu schützen. Aus Kosten- und Performancegründen ist eine kryptografische Absicherung der Safety-Datenpakete zwischen der Safety-Steuerung und Eingabe-/Ausgabemodulen nicht zielführend. Deshalb wird in Schritt SE3 der Security-Analyse auf die Gateway-Funktion der M1-Steuerung zurückgegriffen. Aus Sicht der Safety-Steuerung dient die M1-Standardsteuerung somit zum einen als Security-Gateway und zum andern als Router für Safety-Datenpakete innerhalb des Steuerungssystems.

In der Security-Architektur des übergeordneten Kommunikationsnetzes dient die Standardsteuerung als Security-Endpunkt und implementiert State-of-the-art-Security-Schutzmechanismen. Abhängig von der identifizierten Bedrohung sind vier unterschiedliche Security-Level durch den Benutzer auswählbar. So sind beispielsweise in Stufe 4 nur die notwendigsten Ports geöffnet und Kommunikation mit der Steuerung über Ethernet ist nur mittels kryptografischer Protokolle möglich. Ebenfalls realisiert ist ein Zugriffsmanagementsystem, welches eine feingranulare Definition der Zugriffsrechte nicht nur auf die Steuerung selbst, sondern auch auf jede einzelne Prozessvariable individuell erlaubt.

Kurzum: Mit diesem Ansatz ist die Safety-Steuerung zur Gänze in die Betriebsführung integriert, ohne Maßnahmen der funktionalen Sicherheit und Informationssicherheit zusammenzuführen. Damit sind jederzeit Security-Updates durchführbar, ohne dass eine Re-Zertifizierung des Safety-Teils erforderlich ist.

Autorten:
Christoph Scherrer ist Produktmanager für Safety & Security bei Bachmann Electronic;
Bernd Süßmilch leitet bei Bachmann Electronic die Test­abteilung für Entwicklungswerkzeuge und Runtime-Umgebung.