content:arbeitsschutz [VDI Knowledgebase]

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.
====== 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.

===== Relevante Normen und Richtlinien (unvollständig) =====

==== 1. Safety Grundnormen ====

^Kennung^Jahr^Titel^Anmerkung|
|[[:industrie|IEC 61508]]|2010|Functional safety of electrical/electronic/programmable electronic safety-related systems, Parts 1 - 7| |
|[[https://www.dinmedia.de/de/norm/iso-12100/136574342|ISO 12100]]|2010|Safety of machinery - General principles for design - Risk assessment and risk reduction|Risikobewertung|
|[[https://www.dinmedia.de/en/standard/din-en-iec-62061/358503687|IEC 62061]]|2023|Safety of machinery - Functional safety of safety-related electrical, electronic and programmable electronic control systems|Maschinen-Technik|
|[[https://www.dinmedia.de/en/standard/iso-13849-1/367982018|ISO 13849-1]]|2023|Safety of machinery - Safety-related parts of control systems - Part 1: General principles for design|Maschinen-Technik|
|[[https://www.dinmedia.de/en/standard/iso-13849-2/167356377|ISO 13849-2]]|2012|Safety of machinery - Safety-related parts of control systems - Part 2: Validation|Maschinen-Technik|
|[[https://www.dinmedia.de/en/standard/din-en-61800-5-2/277436970|IEC 61800-5-2]]|2017|Adjustable speed electrical power drive systems - Part 5-2: Safety requirements – Functional Safety|Antriebstechnik|
|[[https://www.dinmedia.de/en/standard/din-en-61511-1/296008238|IEC 61511-1]]|2019|Functional safety - Safety instrumented systems for the process industry sector, Parts 1 - 3|Prozesstechnik|
|[[https://www.dinmedia.de/en/standard/din-en-61513/188355832|IEC 61513]]|2013|Nuclear power plants - Instrumentation and control important to safety - General requirements for systems|Kernkraft-Technik|
|[[:industrie|ISO 10218]]|2011|Robots and robotic devices - Safety requirements for industrial robots|Industrie-Roboter-Technik|
|[[:industrie|IEC 61496]]|2020|Safety of machinery - Electro-sensitive protective equipment| |


==== 2. Security ====

=== 2.1 Normenfamilien für gesamtheitliche Betrachtungen ===

^Kennung^Jahr^Titel^Anmerkung|
|[[https://www.dinmedia.de/de/norm/din-en-iec-62443-4-1/292194568|IEC 62443-4-1]]|2018|Security for industrial automation and control systems – Part 4-1: Secure product development lifecycle requirements|Produktentwicklung|
|[[https://www.dinmedia.de/de/norm/din-en-iec-62443-4-2/312858287|IEC 62443-4-2]]|2019|Security for industrial automation and control systems - Part 4-2: Technical security requirements for IACS components|Produktentwicklung|
|[[:industrie|IEC 62443-3-2]]|2018|Industrial communication networks - Network and system security - Part 3-2: Security levels for zones and conduits|Risikobeurteilung auf Systemebene|
|[[https://www.dinmedia.de/en/standard/din-en-iec-62443-3-3/311519620|IEC 62443-3-3]]|2013|Industrial communication networks – Network and system security – Part 3-3: System security requirements and security levels|Technische Security-Anforderungen|

=== 2.2 Normen für Informationssicherheits-Managementsysteme (ISMS) ===

ALLE NORMEN ZURÜCKGEZOGEN

^Kennung^Jahr^Titel^Anmerkung|
|[[:industrie|ISO/IEC 27001]]|2013|Information technology — Security techniques — Information security management systems — Requirements|Informationssicherheits-Managementsysteme|
|[[:industrie|ISO/IEC 27002]]|2013|Information technology – Security techniques – Code of practice for information security controls|Kontrollmechanismen für die Informationssicherheit - Zurückgezogen|
|[[:industrie|ISO/IEC 27005]]|2018|Information technology – Security techniques – Information security risk management|Risikomanagement für Informationssicherheit|
|[[:industrie|ISO/IEC 13335]]|2004|Information technology - Security techniques - Management of information and communications technology security|Sicherheit der Informations- und Kommunikationstechnik|

=== 2.3 Normen für die Evaluierung von IT-Sicherheit ===

ALLE NORMEN ZURÜCKGEZOGEN

^Kennung^Jahr^Titel^Anmerkung|
|[[:industrie|ISO/IEC 18045]]|2008|Information technology – Security techniques – Methodology for IT security evaluation|Methodik zur Evaluation von IT-Sicherheit|
|[[:industrie|ISO/IEC 15408]]|2009|Information technology – Security techniques – Evaluation criteria for IT security|IT-Sicherheit|
|[[:industrie|ISO/IEC 19790]]|2012|Information technology – Security techniques – Security requirements for cryptographic modules|Kryptographische Module|
|[[https://www.dinmedia.de/de/norm/iso-iec-19792/121413760|ISO/IEC 19792]]|2009|Information technology – Security techniques – Security evaluation of biometrics|Biometrische Technologie|

=== 2.4 Normen für spezielle (IT)-Sicherheitsverfahren ===

ALLE NORMEN RICHTLINIEN REIHEN KEINE LINKS

^Kennung^Jahr^Titel^Anmerkung|
|[[:industrie|ISO/IEC 10118]]|2016|IT Security techniques - Hash-functions|Hashfunktionen|
|[[:industrie|ISO/IEC 11770]]|2017|IT Security techniques - Key management|Schlüsselmanagement|
|[[:industrie|ISO/IEC 18033]]|2020|IT Security techniques - Encryption algorithms|Verschlüsselungsalgorithmen|
|[[:industrie|ISO/IEC 9798]]|2010|IT Security techniques - Entity authentication|Authentifizierung|
|[[:industrie|ISO/IEC 27034]]|2011|Information technology — Security techniques — Application security| |

=== 2.5 Normen für physikalische Sicherheit im Kontext der IT-Sicherheit ===

^Kennung^Jahr^Titel^Anmerkung|
|[[:industrie|DIN 4102]]|2017|Fire behaviour of building materials and building components|Brandverhalten|
|[[https://www.dinmedia.de/de/norm/din-en-1627/332355073|DIN EN 1627]]|2021|Pedestrian doorsets, windows, curtain walling - Burglar resistance|Einbruchshemmung|
|[[https://www.dinmedia.de/de/norm/din-en-60529/206456159|DIN EN 60529]]|2014|Schutzarten durch Gehäuse (IP-Code) (IEC 60529:1989 + A1:1999 + A2:2013)|Schutzarten durch Gehäuse|

=== 2.6 Normen für spezielle Sicherheitsmaßnahmen ===

^Kennung^Jahr^Titel^Anmerkung|
|[[:industrie|ISO/IEC 18028]]|2014|IT Security techniques - Network security|Netzwerksicherheit|
|[[https://www.dinmedia.de/de/norm/iso-iec-27039/231353426|ISO/IEC 27039]]|2015|Information technology – Security techniques – Selection, deployment and operations of intrusion detection and prevention systems (IDPS)|IDS-Systeme|

==== 3. Sonstige Normen ====

^Kennung^Jahr^Titel^Anmerkung|
|[[:iec_tr_63069|IEC/TR 63069]]|2019|Framework for functional safety and security|Anwendung im Maschinenbereich, IEC 62443|
|[[http://data.europa.eu/eli/reg/2019/881/oj|Cyber Security Act]]|2019|Verordnung (EU) 2019/881 des Europäischen Parlaments und des Rates vom 17. April 2019 über die ENISA (Agentur der Europäischen Union für Cybersicherheit) und über die Zertifizierung der Cybersicherheit von Informations- und Kommunikationstechnik und zur Aufhebung der Verordnung (EU) Nr. 526/2013 (Rechtsakt zur Cybersicherheit)| |
|[[http://data.europa.eu/eli/reg/2024/2847/oj|Cyber Resilience Act]]|2024|Verordnung (EU) 2024/2847 des Europäischen Parlaments und des Rates vom 23. Oktober 2024 über horizontale Cybersicherheitsanforderungen für Produkte mit digitalen Elementen und zur Änderung der Verordnungen (EU) Nr. 168/2013 und (EU) 2019/1020 und der Richtlinie (EU) 2020/1828 (Cyberresilienz-Verordnung)| |
|[[http://data.europa.eu/eli/dir/2006/42/oj|Maschinenrichtlinie]]|2006|Richtlinie 2006/42/EG des Europäischen Parlaments und des Rates vom 17. Mai 2006 über Maschinen und zur Änderung der Richtlinie 95/16/EG| |
|[[http://data.europa.eu/eli/reg/2023/1230/oj|Maschinenverordnung]]|2023|Verordnung (EU) 2023/1230 des Europäischen Parlaments und des Rates vom 14. Juni 2023 über Maschinen und zur Aufhebung der Richtlinie 2006/42/EG des Europäischen Parlaments und des Rates und der Richtlinie 73/361/EWG des Rates| |

===== 1 Risiko: Definition und Herausforderungen =====

==== 1.1 Funktionale Sicherheit ====

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

==== 1.2 Security ====

//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. //

=== 1.2.1 Definitionen ===

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.

==== 1.3 Herausforderungen ====

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.

===== 2 Durchführung von Risikoanalysen =====

==== 2.1 Safety ====

In der Funktionalen Sicherheit werden Risikoanalysen im Wesentlichen qualitativ oder semiquantitativ durchgeführt. Zunächst werden in der Regel an einem System potenzielle Gefährdungen unter Zuhilfenahme von qualitativen Methoden identifiziert. Mögliche Methoden zur Durchführung von Risikoanalysen sind z. B. in spezifischen Normen beschrieben, wie z. B. EN ISO 12100 für den Maschinensektor oder es wird auf entsprechende Normen zur Risikoanalyse, wie IEC/ISO 31010, verwiesen. Die Normen IEC 61508 und IEC 61511 schlagen für die Durchführung von Gefährdungsanalysen unter anderem die folgenden Methoden vor:

  * Sicherheits-Durchsprachen
  * Checklisten
  * Was-wäre-wenn-Analysen
  * HAZOP (Hazard and Operability Study)
  * FMEA (Failure Mode and Effects Analysis)
  * Ursache-Wirkungs-Analyse

Diesen Methoden ist gemein, dass sie grundlegend einen qualitativen Ansatz zur Identifizierung von möglichen Gefährdungen verfolgen. Die Ergebnisse können jedoch für eine quantitative Bewertung von Sicherheitsfunktionen (Berechnung der gefahrbringenden Ausfallwahrscheinlichkeit) weiterverwendet werden.

Für alle identifizierten Gefährdungen wird anschließend das Risiko anhand des potenziellen Schadensausmaßes und der Eintrittswahrscheinlichkeit abgeschätzt. Auch diese Abschätzung des Risikos erfolgt im Wesentlichen qualitativ, nur einige Parameter lassen sich zum Teil quantitativ grob abschätzen (z. B. hängt die Wahrscheinlichkeit des Eintritts eines Schadens von der Gefährdungsexposition ab (Häufigkeit/Aufenthaltsdauer im Gefährdungsbereich)).

**Schaden**  wird semi-quantitativ beurteilt:

  * in der ISO 13849-1: leicht, reversibel; ernst, irreversibel/tot
  * in der IEC 62061: irreversibel: Bsp.: Tod, Verlust eines Auges oder Arms; gebrochene Gliedmaßen, Verlust eines/mehrerer Finger; reversibel: ärztliche Behandlung erforderlich; Erste Hilfe erforderlich

**Häufigkeit und Dauer**  der Exposition wird quantitativ beurteilt:

  * ISO 13849-1: Selten oder kurz (weniger als 1-mal pro 15 Minuten, nicht mehr als 1/20 der Gesamtbetriebsdauer); häufig (stand 2021)
  * IEC 62061: ≤ 1h; > 1 h bis ≤ 1 Tag; > 1 Tag bis ≤ 2 Wochen; > 2 Wochen bis ≤ 1 Jahr; > 1 Jahr; alle jeweils unterschieden in Dauer kleiner/größer 10 Minuten

Möglichkeit zur **Vermeidung**  der Gefährdungsereignisse wird semi-quantitativ beurteilt:

  * beide o.g. Normen nennen nur qualitative Einschätzungen (unmöglich, selten, wahrscheinlich)
  * andere Normen im Maschinenbau geben für bestimmte Bewegungsarten quantitative Werte für langsame Bewegungen an (z.B. 25cm/s für Roboter, wenn nichts den betroffenen Menschen am Ausweichen hindert)

**Wahrscheinlichkeit**  des Schadenseintritts wird qualitativ beurteilt

  * ISO 13849-1: Niedrig, normal
  * IEC 62061: sehr hoch, wahrscheinlich, möglich, selten, vernachlässigbar

Allen Risiken, die mittels technischer Schutzeinrichtungen (d. h. steuerungstechnischer Maßnahmen) gemindert werden sollen, wird eine erforderliche Stufe der Sicherheitsintegrität (SIL: Safety Integrity Level) zugewiesen. Die Norm IEC 61508 definiert insgesamt vier Stufen der Sicherheitsintegrität. SIL 1 spiegelt hierbei die niedrigste Stufe und SIL 4 die höchste Stufe der Sicherheitsintegrität wider. Eine häufig verwendete Möglichkeit für die Zuweisung des erforderlichen SILs ist die Anwendung eines so genannten Risikographen (siehe Abbildung 2). Die Risikoparameter (C, F, P, W) müssen für den jeweiligen Anwendungsfall kalibriert werden. IEC 61508-5 enthält weitere Hinweise zur Kalibrierung der Risikoparameter sowie alternative Methoden zur Ermittlung der erforderlichen Stufe der Sicherheitsintegrität.

Abbildung 2: Risikograph zur Ermittlung des erforderlichen SILs (Quelle: IEC 61508-5)

Je nach Stufe der erforderlichen Sicherheitsintegrität wird eine maximal zulässige Ausfallwahrscheinlichkeit der sicherheitsrelevanten Steuerungsfunktion definiert. Der Nachweis, dass die geforderte Ausfallwahrscheinlichkeit eingehalten wird, lässt sich gut mit den bekannten Methoden der Zuverlässigkeitstechnik quantitativ bestimmen (Berücksichtigung der Bauteil-Ausfallraten und Berechnung der gesamten Ausfallwahrscheinlichkeit über Zuverlässigkeitsblock-Diagramme, Monte Carlo-Methode, Markov-Methode usw.).

Wechselwirkungen bezüglich Security-Anforderungen werden in den Normen der Funktionalen Sicherheit nicht behandelt. Die Norm IEC 61508 macht dazu die folgende Aussage: „[…] fordert diese Norm, dass boshafte und nicht autorisierte Handlungen, während der Gefährdung und Risikoanalyse zu betrachten sind. Der Anwendungsbereich der Analyse schließt alle relevanten Phasen des Sicherheitslebenszyklus ein; […]“ (vgl. IEC 61508-1:2010, Abschnitt 1.2).

Security-Anforderungen müssen also bei der Gefährdungs- und Risikoanalyse über alle Phasen des Sicherheitslebenszyklus betrachtet werden. Bezüglich der IT-Security wird auf ISO/IEC TR 19791 und die Normenreihe IEC 62443 verwiesen.

Da boshafte oder nicht autorisierte Handlungen dazu führen können, dass die Sicherheitsfunktionen zur Risikominderung nicht mehr wie vorgesehen funktionieren und das Risiko dementsprechend nicht mehr mindern können, ist Security eine grundlegende Voraussetzung für die Gewährleistung der Funktionalen Sicherheit.

==== 2.2 Security ====

Bei einer Risikoanalyse werden grundsätzlich die zu schützende Werte (sogenannte Assets) bestimmt. Danach wird das Schadensausmaß bewertet, welches beim Verlust des Wertes eintreten kann. Dabei kann der potenzielle Schaden in unterschiedliche Kategorien eingeteilt werden, beispielsweise:

  * Finanzieller Verlust
  * Verlust von Ansehen (Image)
  * Verletzung von rechtlichen Vorgaben (z.B. Datenschutz)
  * Personenschäden bzw. Tod von Personen, Umweltschäden

Diese Informationen sind Ausgangpunkt für die eigentliche Risikoanalyse, für die es verschiedene Ansätze gibt. Drei davon sollen im Folgenden kurz vorgestellt werden:

**1) BSI-Grundschutz Standard 200-3 (Bundesamt für Sicherheit in der Informationstechnik (BSI), 2017) **  Zur Vorbereitung der Risikoanalyse werden die Assets einer Schutzbedarfsfeststellung unterzogen. Hierfür wird jedem Asset ein Schutzbedarf (normal, hoch, sehr hoch) für jeden der Werte (Verfügbarkeit, Integrität, Vertraulichkeit) zugewiesen. Die Art und Höhe der Kriterien sind dabei aber nicht verpflichtend festgelegt, sie müssen aber einer systematischen Überprüfung standhalten (logischer Aufbau und aufbauend auf belastbare Hintergründe). Für Elemente mit einem hohen oder sehr hohen Schutzbedarf ist eine Risikoanalyse verpflichtend. Für den Schutzbedarf „normal“ obliegt die Entscheidung, ob eine Risikoanalyse durchgeführt werden soll, der Verantwortung des Durchführenden.

**Schritt 1**: Erstellung einer Gefährdungsübersicht Zunächst wird eine Gefährdungsübersicht erstellt. Dazu dient eine vorgegebene Liste mit elementaren Gefährdungen, welche aus dem IT-Grundschutz entnommen wurden. Zu jeder elementaren Gefährdung sind die hauptsächlich betroffenen Grundwerte angegeben (Vertraulichkeit, Integrität und Verfügbarkeit). Ziele der Gefährdungsübersicht sind damit:

  * Zusammenstellung einer Liste von möglichen elementaren Gefährdungen in Abhängigkeit ihrer Auswirkungen auf die jeweiligen Assets
  * Ermittlung zusätzlicher Gefährdungen, die über die elementaren Gefährdungen hinausgehen und sich aus dem spezifischen Einsatzszenario ergeben

Abbildung 3: Gefährdungen (Auszug) und ihr möglicher Einfluss auf die Grundwerte, aus BSI-Standard 200-3

**Schritt 2**: Risikoeinstufung Die Einstufung des Risikos ist in zwei Schritte eingeteilt, die Einschätzung und die Bewertung des Risikos.

**Risikoeinschätzung**

Es werden die Risiken ermittelt, welche von den festgestellten Gefährdungen ausgehen. Diese hängen von Eintrittshäufigkeit und Höhe des Schadens ab. Die Schadenshöhe kann dabei durch die durchführende Institution nur selbst eingeschätzt werden. Dabei müssen die direkten Schäden, finanzieller oder anderer Art, und auch Folgeschäden berücksichtigt werden. Auch die Abschätzung der Aufwände bezüglich der Schadensbehebung sollten berücksichtigt werden. Die Schadenshöhe wird in 4 Kategorien eingeteilt:

  * Vernachlässigbar
  * Begrenzt
  * Beträchtlich
  * Existenzbedrohend

Die Eintrittshäufigkeit kann nur durch Fachpersonal mit entsprechender Expertise eingeschätzt werden. Dabei wird hauptsächlich auf Erfahrungswerte zurückgegriffen, wenn verfügbar können auch konkrete Statistiken zur Hilfe gezogen werden. Die Eintrittshäufigkeit wird in 4 Kategorien eingeteilt:

  * Selten (< 1x / 5 Jahre)
  * Mittel (alle 1 bis 5 Jahre)
  * Häufig (< 1x / Monat)
  * Sehr häufig (mehrmals pro Monat)

**Risikobewertung**

Anhand z.B. einer Risikomatrix werden die Risiken bewertet. Dazu dienen die ermittelten Werte für Schadenshöhe und Eintrittshäufigkeit. Eine Beispielmatrix ist in Abbildung 4 gezeigt. Die durchführende Institution muss diese jedoch den eigenen Bedürfnissen anpassen. Die Bewertung erfolgt auf Basis von 4 Risikokategorien:

  * Gering
  * Mittel
  * Hoch
  * Sehr hoch

Abbildung 4: Matrix zur Einstufung von Risiken aus BSI-Standard 200-3

**Schritt 3**: Risikobehandlung Abhängig von der jeweiligen Institution müssen die Risiken im nächsten Schritt behandelt werden. Dies kann dabei abhängig z.B. vom Risikoappetit der Institution sein. Zur Behandlung der verbleibenden Risiken ergeben sich dabei 4 Möglichkeiten:

  * Risikovermeidung, z.B. durch Ausschluss der Ursache
  * Risikoreduktion, z.B. durch zusätzliche Sicherheitsmaßnahmen
  * Risikotransfer, Übertragung auf Dritte
  * Risikoakzeptanz, bewusstes Akzeptieren aus geschäftlichem Interesse

Der BSI-Standard 200-3 sieht darüber hinaus das Konzept der „Risiken unter Beobachtung“ vor. Dies gilt für akzeptierte Risiken, von denen jedoch zu erwarten ist, dass diese sich in der Zukunft erhöhen werden. Für diese sollten bereits ergänzende Sicherheitsmaßnahmen erarbeitet werden, welche dann gezielt in Betrieb genommen werden können.

**Schritt 4**: Konsolidierung des Sicherheitskonzepts Wurden anhand der Risikoanalyse ergänzende Maßnahmen hinzugefügt, welche noch nicht Teil des bestehenden Sicherheitskonzepts waren, müssen diese in dieses integriert werden. Diese Konsolidierung besteht dabei aus mehreren Punkten:

  * Eignung: Sind die Maßnahmen wirklich geeignet alle relevanten Gefährdungen vollständig abzudecken?
  * Zusammenwirkung: Unterstützen sich die verschiedenen Maßnahmen oder gibt es Widersprüche bei Maßnahmen?
  * Benutzerfreundlichkeit: Wie berücksichtigen die Maßnahmen Bedienungsfehler und vermeiden eine Umgehung durch Betroffene?
  * Angemessenheit: Sind die Maßnahmen wirklich angemessen, z.B. im Vergleich zu den Kosten und Aufwänden der Umsetzung?

Auf Grundlage dieser Fragestellungen sollen die Maßnahmen bereinigt (durch Verwerfen und Ersetzen, Auflösen von Widersprüchen oder durch Überarbeitung) und final in das Sicherheitskonzept integriert werden.

**2) IEC 62443-Reihe:**

Die verschiedenen Teile der IEC 62443 Normen-Familie an Cybersicherheitsstandards richten sich an verschiedene beteiligte Rollen und definieren die Aufgaben und Pflichten dieser Rollen. Dazu gehören Hersteller, Integratoren und Betreiber. Ein zentraler Bestandteil, besonders auf der Kommunikation zwischen den Rollen, sind dabei die sogenannten Sicherheitslevel (SL) von 1 bis 4, siehe Tabelle 1 Sicherheitslevel (SL) nach IEC 62443. Ähnlich zu den SIL-Stufen der funktionalen Sicherheit (IEC 61508) kann hiermit ein bestimmter Schutzbedarf ausgedrückt werden. Die Grundlage zur Bestimmung unterscheidet sich aber von den SIL-Stufen. Die SL-Stufen unterscheiden dabei, wie in Tabelle 1 gezeigt, auch explizit zwischen absichtlichen und unabsichtlichen Verstößen bzw. Angriffen. Im Rahmen der 62443-Reihe wird der SL auch in Form des SL-C (Security Level-Capability) als Beschreibung der durch ein System oder eine Komponente zu erreichenden Sicherheitsanforderungen und -funktionen verwendet. Dafür gibt es, beispielsweise in 62443-3-3 und 62443-4-2, Zuordnungen zwischen konkreten technischen Anforderungen und jeweiligen SLs.

Tabelle 1 Sicherheitslevel (SL) nach IEC 62443

^SL^Beschreibung|
|1|Schutz vor zufälligen, unabsichtlichen Verstößen|
|2|Schutz vor absichtlichen Verstößen mit einfachen Mitteln, geringem Aufwand, allgemeinen Fähigkeiten und geringer Motivation|
|3|Schutz vor absichtlichen Verstößen mit fortgeschrittenen Mitteln, mäßigem Aufwand, speziellen Fähigkeiten und mäßiger Motivation|
|4|Schutz vor absichtlichen Verstößen mit fortgeschrittenen Mitteln, erheblichem Aufwand, speziellen Fähigkeiten und hoher Motivation|

Risiko- und Bedrohungsanalysen sind ein wichtiger Bestandteil der 62443-Reihe. In der 62443-3-2 wird ein eigener Risikoanalyseprozess beschrieben, der im Besonderen die Konzepte der 62443-Reihe mit aufnimmt, darunter beispielsweise die SL und das Konzept der Sicherheitszonen und -conduits. Eine Sicherheitszone ist definiert als eine Gruppierung logischer oder physische Assets, die gemeinsame Sicherheitsanforderungen haben, basierend auf Faktoren wie Kritikalität und Folgen eines Angriffs. Die Schnittstellen zwischen de Sicherheitszonen werden „conduits“ genannt.

{{  :content:industrieanlagen_abbildung5.svg  }}Abbildung 5: Sicherheitszonen mit „conduits“ einer Aufzugssteuerung mit Fernwartung

Quelle: SGS TÜV Saar

Als Risiko, die für Sicherheitszonen bestimmt wird, bezeichnet die 62443-Reihe dabei auch die Kombination aus Eintrittswahrscheinlichkeit und Auswirkung, wobei die Eintrittswahrscheinlichkeit noch weiter aufgeteilt wird in Bedrohung und Schwachstelle, und somit zu folgender Risikodefinition führt:

Risiko = Bedrohung x Schwachstelle x Auswirkung

{{ :content:industrieanlagen_abbildung6.svg |}}

{{  :content:industrieanlagen_abbildung.svg?nolink&  }}Abbildung 6: Security Risiko Betrachtung Quelle: SGS TÜV Saar CS3 - Security for Safety Schulung

Die bedeutet, ein Risiko kann nur bestehen, wenn neben einer Bedrohung (z.B. ein motivierter Angreifer), eine oder mehrere Schwachstellen vorhanden sind.

{{  :content:industrieanlagen_abbildung7.svg  }}

Abbildung 7: Motivationen und Fähigkeiten von unterschiedlichem Angreifer-Typen Quelle: SGS TÜV Saar CS3 - Security for Safety Schulung

Daher müssen bei der Risiko-Betrachtung bzw. bei den Gegenmaßnahmen zur Verminderung des Risikos explizit mögliche Schwachstellen betrachtet werden. Zusätzlich können Maßnahmen zur Erkennung eines Angriffs (z.B. Intrusion-Detection) das Risiko senken.

In Abbildung 5 werden mögliche Security Bedrohungen nach der Microsoft Stride Methode aufgelistet. Die IEC 62443-3-3 und IEC 62443-4-2 definieren eine Anzahl von Gegenmaßnahmen für diese Bedrohungen. Um so höher der Security Level ist, um so mehr Gegenmaßnahmen müssen implementiert werden.

{{  :content:industrieanlagen_abbildung8.svg  }}Abbildung 8: Security Bedrohungen nach der STRIDE-Methode mit Assets Quelle: SGS TÜV Saar CS3 - Security for Safety Schulung

[[https://en.wikipedia.org/wiki/STRIDE_model|https://en.wikipedia.org/wiki/STRIDE_model]]

Schwachstellen findet man in der CVE-Sicherheitslückendatenbank [[https://www.cvedetails.com/|https://www.cvedetails.com/]].

Die Bestimmung der Eintrittswahrscheinlichkeit ist nicht eindeutig qualitativ oder quantitativ erfassbar. Man greift hier auf Hilfsmittel zurück und schätzt diese ab. Hierzu müssen beispielsweise die Motivation des möglichen Angreifers, sein Fachwissen und seine verfügbaren Mittel abgeschätzt werden. Zudem werden die Verfügbarkeit von Systemkenntnissen, die Möglichkeit eines Zugriffs auf das anzugreifende Objekt (Physical Security) und die benötigten Zugriffsrechte, angelehnt an die EVITA-Methode (SAE J3061), mit bewertet. Hinzu kommt die Abschätzung des Ausnutzbarkeit von Schwachstellen des Systems.

{{  :content:industrieanlagen_abbildung9.svg  }}

Abbildung 9: Abschätzung der Eintrittswahrscheinlichkeit eines Angriffs Quelle: SGS TÜV Saar CS3 - Security for Safety Schulung

In Abbildung 6 werden unterschiedliche mögliche Schäden aufgelistet. Der hauptsächliche Schaden wird von finanzieller Natur sein. Die IEC 62443 unterscheidet hier fünf verschiedene Schweregrade, die je nach Firmengröße festgelegt werden müssen. Ein Großkonzern hat eine andere Schmerzgrenze wie ein Kleinbetrieb.

{{  :content:industrieanlagen_abbildung10.svg  }}

Abbildung 10: Unterschiedliche mögliche Schäden Quelle: SGS TÜV Saar CS3 - Security for Safety Schulung

Aus dem Schadenindex und der Eintrittswahrscheinlichkeit kann ein Risiko berechnet werden.

{{  :content:industrieanlagen_abbildung11.svg  }}

Abbildung 11: Bestimmung des Security Risikos Quelle: SGS TÜV Saar CS3 - Security for Safety Schulung

Innerhalb der Risikoanalyseprozesse der 62443-3-2 gibt es dabei auch einige Besonderheiten:

  * Die Risikoanalyse wird in mehreren Zyklen durchgeführt. Zunächst wird mit einer initialen Risikobeurteilung begonnen, welches sich auf Worst-Case-Szenarien konzentriert und eine Grundlage der weiteren Einteilung des analysierten Systems („System under Consideration“ SUC) darstellt.
  * Im Rahmen der zunächst festgestellten Bereiche werden dann detailliertere Risikobeurteilungen durchgeführt. Hierbei ist besonders ein Zwischenschritt bedeutsam, bei dem vorhandene Maßnahmen zur Reduzierung der Eintrittswahrscheinlichkeit nicht mit betrachtet werden. Das daraus folgende „ungeminderte“ Cybersicherheits-Risiko kann dann zur Festlegung eines Security Level-Ziels (SL-T, Security Level-Target) verwendet werden, welche bestimmte technische Mindestanforderungen nach sich zieht.
  * Erst darauf werden Maßnahmen betrachtet bzw. weitere Maßnahmen im Rahmen der Risikobehandlung bestimmt.
  * Für die Entwicklung von Geräten mit Security Level (SL) muss ein geeigneter Entwicklungsprozess nach IEC 62443-4-1 vorhanden sein. Die Implementierung des Prozesses wird ähnlich zu CMMI mit Reifegraden (maturity level) bewertet. Die IEC 62443 gibt aber keine Mindestreifegrad für einen vorgegeben Security-Level vor.
  * Eine gute Ergänzung wäre eine Betrachtung der Kosten, für die Umsetzung von Gegenmaßnahmen. Eventuell kann man mit dem Risiko leben und eventuelle finanzielle Risiken in Kauf nehmen. Das gilt aber nicht für ein Safety-Risiken.

__Hinweis__: Darüber hinaus gibt die IEC TR 63069 ein Mapping der IEC 61508 zur IEC 62443.

**3) Checkliste nach NA 163**

In Anbetracht des relativ großen Arbeits- und Zeitaufwandes, den „normale“ Risikoanalysen erfordern, gibt es gerade bei einfacheren Systemen die Bestrebung diese durch checklistenartige Verfahren zu ersetzen. In Bezug auf die Anlagensicherheit ist dies u.a. im Arbeitsblatt NAMUR NA 163 festgehalten, siehe „IT-Risikobeurteilung von PLT-Sicherheitseinrichtungen“ (NAMUR, 2017). Ziel der NA 163 ist es niederkomplexe Automatisierungsfunktionen in Hinblick auf die IT-Security in möglichst kurzer Zeit mit möglichst wenig (externer) Fachexpertise sicher zu gestalten. Um dies zu erreichen, wurden diverse Annahmen getroffen, die für die meisten einfachen Automatisierungsfunktionen generell zutreffend sind, siehe Abbildung 10 Schritt 1 bis 4c.

Abbildung: Struktur einer Risikobeurteilung mit den durch NA 163 vordefinierten Schritten (Kruschitz, 2017)

===== 3 Domänenübergreifende Zusammenführung =====

Die beschriebenen Probleme treten in angrenzenden Disziplinen in ähnlicher Weise auf. Der Begriff Risiko ist quantitativ nicht exakt definierbar, stattdessen kommen qualitative oder semi-quantitative Methoden zur Bewertung des Risikos zum Einsatz.

In der Disziplin der Funktionalen Sicherheit lässt sich die erreichte Stufe der Sicherheitsintegrität einer Sicherheitsfunktion insbesondere für die Hardware quantitativ erbringen, jedoch ist der Nachweis für die Software nur zu einem geringen Teil quantitativ möglich (Anwendung von Software-Metriken z.B. zum Nachweis der Code-Abdeckung oder zur Bewertung der Modul-Komplexität). Maßnahmen zur Vermeidung systematischer Entwicklungsfehler können quantitativ nicht hinreichend bewertet werden. Diese Probleme bestehen in gleichem Maße in angrenzenden Disziplinen.

Auf Grund der zunehmenden Digitalisierung und Vernetzung von technischen Systemen und Einrichtungen rücken Anforderungen an die Security zunehmend in den Fokus der Sicherheitstechnik. Da Security eine grundlegende Voraussetzung für die Gewährleistung der Funktionalen Sicherheit ist, müssen Anstrengungen getroffen werden, um die Anforderungen beider Disziplinen zu vereinen oder klare Schnittstellen mit klaren Zuständigkeiten etabliert werden, wobei letzteres in Anbetracht aktueller Entwicklungen immer schwieriger umzusetzen ist. Die Norm IEC 61508 fordert hierzu grundlegend, „boshafte und nicht autorisierte Handlungen“ frühzeitig während der Gefährdungs- und Risikoanalyse zu betrachten. In der Safety-Disziplin wird aber bisher keine Security behandelt, oder es wird lediglich auf Regelwerke zur Security verwiesen.

Als gemeinsamer Nenner für die Quantifizierung von Risiken in Safety- und Security Modellen könnte die Stufe der erforderlichen Sicherheitsintegrität (SIL) dienen. Je höher das Risiko ist, welches mit einer Sicherheitsfunktion gemindert werden soll, desto höher ist die erforderliche Stufe der Sicherheitsintegrität. Einer erforderlichen SIL könnten also zusätzlich auch (Mindest-)Maßnahmen zur Gewährleistung der Security zugeordnet werden, ähnlich wie es mit dem Security Level (SL) der IEC 62443-Reihe versucht wird. Allerdings zeigt sich gerade in diesem Bereich der Security, wie die Randbedingungen zur Risikobewertung einer hohen Volatilität unterliegen, wodurch sich auch die Quantifizierung des Risikos ändern würde. Eine gemeinsame Quantifizierung ist daher zum Teil unter Experten umstritten. Zunächst existiert keine Metrik, um von einem PL oder SIL aus der Safety auf einen notwendigen SL nach IEC 62443 zu schließen. Ferner existiert bislang keine Möglichkeit die Wahrscheinlichkeit eines Angriffs für bestimmte Tage vorherzusagen. Es ist lediglich bekannt, dass es nur eine Frage der Zeit ist, bis eine Sicherheitslücke ausgenutzt wird. Die sogenannten „Zero Day Exploits“ sind Sicherheitslücke, die den Entwicklern der betroffenen Anwendung noch nicht gemeldet wurde. Das Wissen über solche Schwachstellen können im Darknet käuflich erworben werden und stellen ein illegales Geschäftsmodell dar.

Für die Synthese der beiden Domänen wären die folgenden Fragestellungen relevant:

  * Welche Security-Maßnahmen sollten den jeweiligen Stufen der Sicherheitsintegrität (SIL) (mindestens) zugeordnet werden? Welche Unterschiede sind bei verschiedenen Anwendungsfeldern gegebenenfalls zu berücksichtigen?
  * Wie lässt sich die Wirksamkeit von Security-Maßnahmen einheitlich bewerten? Gibt es quantitative Methoden zur Bewertung der Maßnahmen?
  * Welche Verifikations- und Validationsmaßnahmen (z.B. Penetrations-Tests) sollten mindestens durchgeführt werden, um die Wirksamkeit der Security-Maßnahmen zu gewährleisten? Auf Grund der sich schnell ändernden Randbedingungen (insbesondere bezüglich IT-Security): Wie wird mit neuen Erkenntnissen umgegangen, welche sich während der Betriebszeit der Maschine oder Anlage ergeben?
  * Welche Konflikte bezüglich der Anforderungen an die Funktionale Sicherheit und der Security sind typischerweise in der praktischen Anwendung zu erwarten und welche Handlungsempfehlungen sollen für die Auflösung der Konflikte ausgesprochen werden?
  * Welche ethischen Fragestellungen ergeben sich aus den im vorhergehenden Punkt genannten Konflikten und können auf diese Fragestellungen Antworten/Empfehlungen angegeben werden?

Eine Quantifizierung von Risiken ist vor allem bei Security sehr problematisch. Ein wichtiger Faktor ist die Bewertung der Motivation und die Fähigkeiten eines potenziellen Angreifers, die man schwer abschätzen kann, insbesondere nicht in quantitativer Form. Es ist Gegenstand aktueller Forschung, wie eine Quantifizierung im Bereich der Security ermöglicht werden kann. Während die Quantifizierung in der Safety bereits weit entwickelt ist, scheint eine einfache Lösung für den Bereich der Security nicht in Sicht. Dies liegt insbesondere daran, dass die Einflüsse auf die Safety als Funktion, der der Zeit angenähert werden können. Das Verhalten von Angreiferinnen und Angreifern lässt sich nicht vorhersagen. Für die Quantifizierung kann die Ausfallrate von 1000 Halbleiterbauteilen systematisch bestimmt werden. Programmierfehler lassen sich dagegen kaum für eine sinnvolle Quantifizierung verwenden. Entweder kann ein Fehler automatisiert gefunden werden, dann sollten er leicht vor Auslieferung gefunden werden können. Oder es handelt sich um Fehler, der aktuell nur durch einen Menschen gefunden werden kann, dann hängt die Erkennungsrate ebenso vom Menschen ab, wie die Fehlerrate beim Codieren.

Es gibt auch Ansätze, die Software-Qualität statistisch zu erfassen. Siehe dazu “Software Reliability Engineering: More reliable Software and cheaper –2nd Edition”

[[https://de.scribd.com/document/94483021/Software-Reliability-Engineering-More-Reliable-Software-Faster-and-Cheaper-2nd-Edition|https://de.scribd.com/document/94483021/Software-Reliability-Engineering-More-Reliable-Software-Faster-and-Cheaper-2nd-Edition]]

Die Schwachstellen werden teilweise bereits gut erfasst und auch mathematisch bewertet (siehe Abbildung 4). Zur Bewertung des Risikos müsste noch die aktuellen Bedrohungen systematisch erfasst und bewertet werden. Es gibt zwar schon vom BSI aktualisierte Bedrohungskataloge bzw. für einzelne Jahre Übersichten von Angriffen. Wünschenswert wäre hier die Einführung der systematischen Erfassung von Bedrohungen und deren Bewertung analog zu den Schwachstellen.

Da die Bestimmung des Security Levels sich schwierig gestaltet, gib es einen pragmatischen Ansatz, der eine Zuordnung eines SL 2 vorsieht. Bei Erkennung eines erhöhten Risikos wird auf SL 3 erhöht. Ein SL 1 ist zu wenig und bei einem SL 4 sind die Gegenmaßnahmen derart aufwendig, dass sie kaum umgesetzt werden können. Zudem muss sich in der Praxis noch herausstellen, wie die Maßnahmen für Komponenten, die in der IEC 62443-4-2 für die einzelnen SL-Werte definiert sind, vernünftig umgesetzt werden können. Hier gibt es auch die Möglichkeit, Maßnahmen vom Produkt auf die Applikationsebene (IEC 62443-3-3) zu verlagern.

Ein weiteres spannendes Thema ist die Kombination von Safety und Security-Anforderungen. So verlangt die Safety bei einem Safety relevanten Ereignis eine Reaktion ich Echtzeit. Durch den Einsatz von Kryptographie, das bei kleinen Mikrocontroller sehr zeitaufwendig ist, wird die Umsetzung der Echtzeitanforderung schwierig. Hier muss noch Erfahrungen in der Praxis gesammelt werden.

Wenn Safety und Security in einem Gerät kombiniert werden, muss auch bei jeder Änderung im Security-Teil eine komplette Safety Änderungsprüfung durchgeführt werden. Hier empfiehlt es sich, die Safety von der Security strikt zu trennen.

Das Security-Risiko kann auch erheblich reduziert werden, wenn der physische Zugang zum Gerät eingeschränkt wird. Das Gerät sollte in einem Bereich mit beschränktem Zugang installiert sein. Der Zugang über Schnittstelle kann zudem zeitlich beschränkt oder extra abgesichert werden.

Für die Validation der Security-Anforderungen wird der Penetration-Test angewendet. Hier werden unabhängigen Personen mit gutem Fachwissen mit der detaillierten Geräteinformation beauftragt, die eingebauten Sicherheitsmechanismen zu umgehen. Die Güte der Tests hängt sehr stark von der Kreativität und Können des Testers ab. Hier empfiehlt es sich Test-Personen einzusetzen, die entsprechend qualifiziert sind. Die BSI bietet eine Zertifizierung als IS-Penetrationstester an.

[[https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Zertifizierung-und-Anerkennung/Zertifizierung-von-Personen/Penetrationstester/penetrationstester_node.html|https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Zertifizierung-und-Anerkennung/Zertifizierung-von-Personen/Penetrationstester/penetrationstester_node.html]]