Bedeutung von Safety und Security in Industrie- und Produktionsanlagen und im Arbeitsschutz

Die zunehmende Digitalisierung und Vernetzung in der Industrie bringen neben zahlreichen Chancen auch erhebliche Sicherheitsrisiken mit sich. Insbesondere kritische Infrastrukturen und industrielle Steuerungssysteme sind zunehmend Ziel von Cyberangriffen.

In der DIN EN ISO 12100, die als zentrale Norm für die Maschinensicherheit gilt, wird der Begriff Risiko wie folgt definiert:

„Kombination aus der Wahrscheinlichkeit des Eintretens eines Schadens und der Schwere des Schadens.“

Diese Definition legt zwei zentrale Dimensionen eines Risikos fest:

• Wahrscheinlichkeit: Die Wahrscheinlichkeit, mit der ein gefährliches Ereignis oder ein Schaden eintritt.
• Schwere des Schadens: Die potenziellen Konsequenzen, die aus dem Ereignis resultieren, wie Verletzungen oder Todesfälle.

Hinweis: Schäden an Eigentum und Umwelt werden von der DIN EN 12100 explizit nicht betrachtet. Bei Security-Vorfällen kann jedoch auch hier Schaden entstehen.

In der Funktionalen Sicherheit werden Sicherheitsfunktionen (Steuerungsfunktionen) zur Minderung von Risiken eingesetzt. Die Sicherheit hängt in diesem Zusammenhang also direkt von der korrekten Funktion der steuerungstechnischen Maßnahme ab.

Zur quantitativen Bewertung der Sicherheitsfunktionen wird entweder die gefahrbringende Ausfallwahrscheinlichkeit pro Stunde (PFH: Probability of Dangerous Failure per Hour) bei Sicherheitsfunktionen mit hoher Anforderungsrate oder die gefahrbringende Ausfallwahrscheinlichkeit bei Anforderung (PFD: Probability of Dangerous Failure on Demand) bei Sicherheitsfunktionen mit niedriger Anforderungsrate berechnet.

Problematisch bei der Bewertung von Risiken im Bereich Maschinen und Anlagen ist eine exakte quantitative Beschreibung der Risikoparameter Schadensausmaß, Gefährdungsexposition, Wahrscheinlichkeit für Eintritt des Gefährdungsereignisses und Möglichkeit zur Vermeidung/Begrenzung des Schadens (siehe auch Abschnitt 2 „Durchführung von Risikoanalysen“).

Diese Parameter können im besten Fall semi-quantitativ beschrieben werden, und die Risikoparameter müssen für unterschiedliche Anwendungsfälle (Maschinen, Prozessindustrie, Nuklear-Sektor usw.) jeweils neu kalibriert werden.

Ein weiteres Problem stellen mögliche Widersprüche hinsichtlich der Verfügbarkeit der Maschinen oder Anlagenfunktion und Zuverlässigkeit der Sicherheitsfunktion(en) dar. Bei ungünstiger Auslegung der Sicherheitsfunktionen kann es zu häufigen ungewollten Unterbrechungen der Maschinen- oder Anlagenfunktion kommen. Der Nachweis der Sicherheitsintegrität der Hardware lässt sich durch Anwendung geeigneten Methoden quantitativ erbringen und drückt sich letztendlich in der berechneten gefahrbringenden Ausfallwahrscheinlichkeit aus. Allerdings lassen sich Maßnahmen zur Vermeidung systematischer Entwicklungsfehler quantitativ nicht erfassen. Problematisch ist in diesem Zusammenhang auch der Nachweis der Sicherheitsintegrität der Software, da für die Software keine Ausfallwahrscheinlichkeit berechnet werden kann, denn Software kann nur systematische Fehler enthalten und nicht zufällig ausfallen. Aus diesem Grund werden deterministische Ansätze (z. B. Verwendung von Hardware-Redundanzen oder Methoden zur Erkennung von Hardware-Ausfällen) mit verschiedenen Methoden zur Vermeidung systematischer Entwicklungsfehler kombiniert. Dadurch sollen einerseits zufällige Hardware-Ausfälle beherrscht und systematische Entwicklungsfehler möglichst vermieden oder ebenfalls beherrscht werden.

Weitere Probleme können durch mögliche Widersprüche hinsichtlich der Anforderungen an die Funktionale Sicherheit und Anforderungen an die IT-Security entstehen. Die Normen der Funktionalen Sicherheit definieren keine eigenen IT-Security Anforderungen, sondern verweisen diesbezüglich auf andere Normen, wie ISO/IEC TR 19791 und die Normenreihe IEC 62443. Auf mögliche Konflikte zwischen Funktionaler Sicherheit und IT-Security gehen die Normen der Funktionalen Sicherheit nicht ein. z.B. kann die Safety eine Zeitvorgabe für eine Reaktion vorgeben, die durch Security-Maßnahmen, wie z.B. Kryptografie nicht eingehalten werden können. Weiterhin werden keine direkten Bezüge zum Thema „Physical Security“ hergestellt.

Unscharfe Risikobeiträge werden nur bei der Berechnung der Ausfallwahrscheinlichkeit bei elektronischer Hardware berücksichtigt. Dazu werden die bekannten Methoden der Statistik verwendet, d. h. Berücksichtigung von statistischen Verteilungen der Bauteil-Ausfallraten (standardmäßig Weibull-Verteilung) und Festlegung von zulässigen Konfidenzintervallen für die verwendeten Ausfallraten. Die Unsicherheiten bei der Bestimmung der Ausfallwahrscheinlichkeit sind damit mathematisch gut zu erfassen. Generell lässt sich sagen, dass bei der Berechnung der Ausfallwahrscheinlichkeiten normalerweise mit „konservativen“ Werten für die Ausfallraten gerechnet wird, so dass Unsicherheiten in der Regel keinen negativen Einfluss auf die Funktionale Sicherheit haben. Für die Bestimmung von Ausfallwerten bei der Mechanik werden auch B10d Werte bestimmt. Die Mechanik wird längere Zeit betrieben und die Anzahl der gefährlichen Ausfälle empirisch bestimmt.

https://www.maschinen-sicherheit.net/07-seiten/3620-b10d-wert.php

• Generelle Anforderungen werden beschrieben in Richtlinie 2006/42/EG Anhang I und in ISO 12100:2010
• Einige generelle Anforderungen zur Security in Richtlinie 2006/42/EG Anhang I 1.2.1. und in ISO 12100 Abschnitt 5.5.3.6 werden beschrieben
• Mutwillige Überwindung von Schutzeinrichtungen; Die Sabotage ist eine Art von „Tampering“ und eine Cyber-Attacke kann man auch als Sabotage verstehen.
• Betrachtet werden im Wesentlichen Gefahren für einzelne Personen. In Einschränkung der IEC 61508 werden Personenschäden für mehrere Personen nicht schwerer eingestuft als ein einzelner Personenschaden, da die Anzahl der beteiligten Personen in der Regel begrenzt ist (z.B. gegenüber einem Flugzeugabsturz).
• Typische Schadensarten sind z.B. Quetschen/Scheren von Körperteilen, Verbrennungen durch heiße Oberflächen, Strahlungsschäden, Kontakt mit gefährlichen Stoffen, Stromschlag. Auch spezifische ergonomische Gefahren werden betrachtet.

Disclaimer: Die nachfolgenden Ausführungen sollen einen Einblick in die Heterogenität der Security in der Anlagensicherheit geben und somit die unterschiedlichen Herangehensweisen an Risikodefinitionen und Herangehensweisen erklären, sind für sich selbst aber nicht abschließend oder als alleinig richtig/gültig zu betrachten.

Die Security in der Anlagensicherheit ist traditionell (bedingt durch deren historische Ausprägung) oft in verschiedene Fachgebiete unterteilt. Grundsätzlich und vereinfacht dargestellt kann zwischen Physical Security und IT-Security (wobei IT/OT-Security dazugezählt werden sollte, siehe unten) unterschieden werden. Die Physical Security der Betriebsbereiche/Gebäude/Anlagen definiert sich meist über ihre Maßnahmen mit deren Hilfe Unbefugte daran gehindert werden sollen, bestimmte Bereiche zu betreten oder zu verlassen (Zäune, Pforten etc.). Diese Art der Sicherheit ist heutzutage bereits stellenweise eng mit dem Themenfeld des Arbeitsschutzes (und somit der Safety) verwoben. Zusätzlich wird ausgehend (aber nicht ausschließlich) von den Erfordernissen an Kamera/Drohnenüberwachung etc. auch die Schnittstelle zur IT-Security immer bedeutsamer. Sichtbar wird diese am Terminus der Informationssicherheit der sowohl Bereiche der Physical Security als auch der IT-Security vereinnahmt.

Die IT-Security in der Anlagensicherheit ist aus der Historie betrachtet ebenfalls in zwei Fachgebiete zu unterteilen. Die „Office-IT-Security“ wird dabei häufig als der „klassische“ bzw. ursprüngliche Bereich der IT-Security betrachtet. Mit der Einführung von allgemeinzugänglichen EDV-Systemen (im Gegensatz zu den frühen „Mainframes oder Supercomputern“, welche nur für einen streng überwachten Personenkreis zugänglich waren) wurde es schnell notwendig, Maßnahmen und Vorgaben zu treffen, um die Funktionsfähigkeit und Zuverlässigkeit von Computersystemen aufrechtzuerhalten.

Diese zu schützenden Kernelemente sind die heute für die IT-Security maßgeblichen Werte und stellen die primären Sicherheitsziele dar:

• Vertraulichkeit
• Integrität
• Verfügbarkeit

Daraus abgeleitet etablierten sich im Laufe der Zeit noch weitere Parameter (zumeist ableitbar aus den oben genannten Werten), welche aber nicht direkt zu den genannten Werten gezählt werden:

• Authentizität
• Verbindlichkeit / Nichtabstreitbarkeit
• Zurechenbarkeit bzw. Anonymität

Der zweite historische Pfeiler der IT-Security ist in der OT-Security (Operational Technology Security) zu sehen, welche stark an Bedeutung gewinnt. Verstärkt wird dies durch den voranschreitenden Trend der Digitalisierung in dessen Sogwirkung auch alte und somit bisher offline betriebene Anlagenteile vernetzt werden, was gänzlich neue Betrachtung zum Thema OT-Security notwendig macht.

Aufgrund der immer stärker werdenden Integration und Vernetzung von Produktionsanlagen (OT-Netzwerke) mit dem Office /Produktionsplanungsbereichen (IT-Netzwerke) spricht man an dieser Stelle auch vermehrt von IT-OT Konvergenz (Kienle, 2017). Für die folgenden Erläuterungen wird Security im Sinne der IT/OT Konvergenz bzw. als Teil der Informationssicherheit verwendet.

Das Security Risiko wird ähnlich wie bei Safety aus dem Produkt vom Schadenausmaß und der Eintrittswahrscheinlichkeit bestimmt. Um das Risiko zu vermindern, werden geeignete Gegenmaßnahmen implementiert, die den möglichen Angriff erschweren. Ein Ausschließen ist möglich, wenn der Angriffspfad als solcher durch die Maßnahmen ausgeschlossen werden kann (z.B. durch Deaktivieren einer Funktion, eines Zugangswegs etc.).

Im Gegensatz zu herkömmlichen Risikobetrachtungen ist in der IT-Security sowohl der Eintritt des Schadensereignisses als auch die Vermeidung oder Begrenzung des Schadens schwierig zu fassen, da beides abhängig ist vom aktuellen Stand des Wissens (nicht Stand der Technik). So können jahrelang als sicher geltende Prozeduren/Vorkehrungen innerhalb von Stunden nutzlos werden oder – noch schlimmer- selbst zum Angriffspfad werden. Hierfür haben sich im Laufe der Zeit unterschiedliche Lösungsansätze gebildet, welche verschiedene Vor- und Nachteile aufweisen.

Stark vereinfacht können viele der Lösungsansätze grundsätzliche auf zwei Herangehensweisen reduziert werden.

1) Durch Betrachtung des aktuellen Ist-Zustandes sowohl in Bezug auf Angriffs- und Verteidigungswerkzeuge lassen sich die aktuelle Bedrohung und auch Gefährdung ableiten. Dies offenbart sich auch in den Definitionen für Bedrohung und Gefährdung, wie das nachfolgende Beispiel des BSI zeigt (Bundesamt für Sicherheit in der Informationstechnik (BSI), 2019):

IT-Bedrohung: Ein Umstand oder Ereignis, der oder das die Verfügbarkeit, Integrität oder Vertraulichkeit von Informationen beeinträchtigen kann, wodurch dem Besitzer bzw. Benutzer der Informationen ein Schaden entstehen kann. (Quelle: Bundesamt für Sicherheit in der Informationstechnik, 2019)

Gefährdung: Eine konkrete Gefahr, die für ein konkretes Schutzgut wie Vermögen, Wissen, Gegenstände oder Gesundheit besteht, aber noch nicht eingetreten ist. Die Gefährdung entspricht einem potentiellen Ereignis oder einer potentiellen Entwicklung mit möglichen Auswirkungen für ein Schutzgut.

IT-Gefährdung: Eine IT-Bedrohung, die konkret über eine Schwachstelle auf ein Objekt einwirkt. Eine IT-Bedrohung wird somit erst durch eine vorhandene Schwachstelle zur Gefährdung für ein Objekt.

2) Im relativ starken Kontrast dazu stehen „Assume the Breach“ Ansätze (grob zu übersetzten mit „erwarte den Angriff“). Diesen Ansätzen gemein ist die Tatsache, dass davon ausgegangen wird, dass ein System kompromittiert, ist bzw. es nicht hinreichend ausgeschlossen werden kann (Alaniz, 2017). Dies hat zur Folge, dass einzelne Systeme stark gesichert werden, wobei der Sicherungsverbund in den Hintergrund tritt. Ein großer Vorteil wird im Aufheben des falschen Gefühls der Sicherheit gesehen, da es sich in vielen Bereichen gezeigt hat, dass erfolgreiche Angriffe nur eine Frage der Zeit sind oder von der unangemessenen Handlung nur eines Mitarbeiters ausgelöst werden kann. „Assume the Breach“ soll zu einer besseren Sicherheitskultur führen, da permanent von einem Angriff ausgegangen wird und die Wirksamkeit der eigenen Abwehrkapazitäten stets kritisch betrachtetet wird. Der größte Nachteil sind die relativ hohen Kosten (entstehend durch den deutlichen Mehraufwand für Sicherheit einzelner Bauteile/Funktionen) und teilweise nicht mögliche Nutzung bestimmter (Komfort-)Funktionen.

Aufgrund der historischen Entwicklung (siehe oben) haben sich diverse Vorgehensweisen, Verhalten, Definitionen, Sprachgebräuche und Lösungskonzepte im Bereich Security mit unterschiedlichen Schwerpunkten und Voraussetzungen entwickelt. Diese zu standardisieren ist bereits innerhalb dieser kleinen Themengemeinschaft eine große Herausforderung. So war es beispielswiese lange Zeit unüblich (und auch nicht notwendig), dass Mitarbeiter der Bereiche IT und OT-Informationen austauschten.

Durch das (oftmals wirtschaftlich erzwungene) Zusammenwachsen verschiedener Teilbereiche von vorher offline betriebenen Systemen (Digitalisierung, Industrie 4.0 etc.) mit digitalen Systemen oder Hybriden (IoT (Internet of Things)/IIoT (Industrial Internet of Things)) entstehen sehr viele neue Angriffsszenarien und Vektoren. Dies wird noch verstärkt durch die Problematik um Updates und Patches, welche zum Teil eingespielt werden können oder aber zum Teil auch nicht. Häufig genannte Gründe hierfür sind oft das fehlende Zeitfenster für einen Neustart des Systems (z.B. bei Anlagen mit langer An- und Abfahrtszeit und 24/7 Conti-Betrieb mit nur wenigen Revisionszeiträumen im Jahr), die Ungewissheit über die Wirkung (oder den Erfolg) des Patches auf ein bestehendes Gesamtsystem, sowie drohende Garantie- oder Funktionsverluste bestimmter Anlagenteile bei nicht Verwendung der ursprünglich zertifizierten (aber veralteten/unsicheren) Softwareversion. In diesem Kontext sind auch Geräte zu betrachten, für die es keinen Software-Support mehr gibt (z.B. Win XP).

Aktuell entstehen sehr viele unterschiedliche IT-Security Standards (bzw. Werke zum Umgang mit Digitalisierung) auf nationaler und internationaler Ebene. Dabei sind nicht nur Umfang und Anzahl der Dokumente problematisch, sondern auch die Tatsache, dass unterschiedliche Forderungen aufgestellt werden, welche nicht zwangsläufig miteinander harmonieren. Zusätzlich sind auch nationalstaatliche Interessen (Versorgungsicherheit, Verteidigungsfähigkeit, Datenweitergabe zur Terrorabwehr etc.) zu berücksichtigen.

IT-Risikoanalysen sind bei Weitem nicht so stark standardisiert und objektiv wie ihre Äquivalente aus dem Bereich Safety. Die Bedrohungslage bzw. die Schwachstellen verändern sich laufend und zum Teil sehr schnell. Was heute sicher eingestuft wurde, kann morgen schon unsicher sein. Der mögliche Schaden ist eher abzuschätzen als genau zu beziffern. Die Eintrittswahrscheinlichkeit hängt von zahlreichen Faktoren ab, die oft nur intuitiv abgeschätzt werden können. Dies führt dazu, dass bei einer IT-Risikoanalyse die Einschätzungen der Fachleute oft stark auseinander gehen und von Dritten nicht einfach nachzuvollziehen sind.

Viele Fragen technischer oder organisatorischer Natur sind bisher nicht eindeutig beantwortbar, so sind beispielweise Virenscanner ein sehr umstrittenes Thema. Während sie in einigen Konzepten einen unverzichtbaren Bestandteil darstellen, sind sie in anderen Konzepten verboten. Für beide Aussagen gibt es gute Gründe. So erkennt ein Virenscanner je nach Bauart nur bekannte oder ähnliche Angriffe. Allerdings werden täglich viele hunderttausend neue Schadprogramme in Umlauf gebracht, im Jahr 2016 ~390.000 pro Tag (Jürgen Schmidt, Volker Zota , 2016), wobei viele davon bisher bekannten Schadcode-Familien zumindest ähneln. Darüber hinaus gab es in der Vergangenheit diverse Fälle, bei denen der Virenscanner selbst Ziel des Angriffs war, da dieser üblicherweise mehr Berechtigungen hat als der übliche Nutzer. Zusätzlich haben Virenscanner oft einen negativen Einfluss auf die Performance bzw. verzögern Prozesse, was gerade im Zusammenspiel mit Safety zu großen Problemen führen kann.

Die Erwartungen an „KI“ bzw. „selbstlernende Systeme“ zur IT-Security (Virenscanner, IDS etc.) sind teilweise zu optimistisch. Häufig werden diese auch als systemische Blackbox betrieben, so dass die eigentlichen Wirkprozesse nur dem Hersteller bekannt sind. Dies resultiert nicht selten in verzerrten Risikoanalysen bzw. Maßnahmenkatlogen.

Security ist in vielen Bereichen immer noch nicht regulärer Bestandteil des Design-Prozesses (Security by Design) sondern wird je nach Budget im Anschluss an Engineering und Designentscheidungen kurzfristig hinzugefügt. Die daraus resultierenden Probleme sind gut an vielen modernen IoT-Bauteilen zu sehen, welche oftmals mit massiven Sicherheitslücken auf den Markt kommen (Kleinhans, 2016) (Foltýn, 2018). Ein Nachrüsten (nachträgliches integrieren von Security) ist oft aus diversen Gründen schwierig (fehlende finanzielle Mittel, fehlender Platz im Gerät, zusätzliche Wärmeentwicklung im Gerät, zusätzlicher Stromverbrauch des Gerätes etc.).

Die Wirksamkeit einer IT-Security-Maßnahme ist oftmals zeitlich beschränkt, wobei der Zeitpunkt ihres „unwirksam“ Werdens zumeist nicht vorhersehbar ist, da er nicht auf physische Grundlagen (z.B. Materialermüdung) beruht. Dabei können mehrere Fälle unterscheiden werden:

• Es existiert ein unbekannter Fehler (Software oder Hardware) im Produkt oder der Schutzmaßnahme, der sich ausnutzen lässt. Wann dieser Fehler gefunden wird, lässt sich nicht vorhersagen. Bekannte Fehlerquellen verringern die Zeit bis zur Entdeckung maßgeblich.
• Die Schutzmaßnahme wird bedingt durch den technischen Fortschritt unwirksam, wobei technischer Fortschritt sowohl mehr Rechenleistung als auch neue Funktionsweisen beinhaltet. Ein Beispiel für letzteres wäre die sich seit langem anbahnende Entwicklung von Quantencomputern, welche Kryptographische Verschlüsselungen auf Basis von Primzahlen (z.B. RSA) oder elliptischer Kurven (z.B. ECC) unsicher machen würden.
• Die Schutzmaßnahme basiert auf dem Nichtwissen um die Funktion bzw. des Vorhandenseins der Information (Security by Obscurity). So sind Beispielweise mittels Steganographie „verschlüsselte“ Informationen (z.B. ein in einem Bild versteckter Text) lediglich „versteckt“. Weiß der Angreifer um die Existenz der Information ist die Schutzmaßnahme oft wirkungslos.