content:industrie [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.
====== Safety (Security) Risiko im Bereich von Industrie- und Produktionsanlagen ======

**Autoren:** David Schepers, Martin Zeh, Stephan Gebhard, David Meier
===== Kommentare =====

  * Unklar, wie Abbildung 10: Security Risiko Betrachtung aus 62443 abgeleitet wird.
  * "Bezüglich unscharfer oder unsicherer Risikobeiträge im Bereich Security im Industrieumfeld gibt es den Vorschlag, das minimale Risiko auf SL 2 festzulegen. Bei höheren anzunehmenden Schäden kann auf SL 3 erhöht werden. Ein SL 4 ist technisch schwer umsetzbar und sehr kostenintensiv und wird daher ausgeschlossen." Sollte als Zitat mit Quellenangabe verwendet werden. Wer schlägt hier was vor? Wir sollten uns hier an belegbare fakten halten. Die Norm sagt das so nicht.

===== 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| |
|[[:industrie|ISO 12100]]|2010|Safety of machinery - General principles for design - Risk assessment and risk reduction|Risikobewertung|
|[[:industrie|IEC 62061]]|2016|Safety of machinery - Functional safety of safety-related electrical, electronic and programmable electronic control systems|Maschinen-Technik|
|[[:industrie|ISO 13849-1]]|2015|Safety of machinery - Safety-related parts of control systems - Part 1: General principles for design|Maschinen-Technik|
|[[:industrie|ISO 13849-2]]|2012|Safety of machinery - Safety-related parts of control systems - Part 2: Validation|Maschinen-Technik|
|[[:industrie|IEC 61800-5-2]]|2017|Adjustable speed electrical power drive systems - Part 5-2: Safety requirements – Functional Safety|Antriebstechnik|
|[[:industrie|IEC 61511-1]]|2016|Functional safety - Safety instrumented systems for the process industry sector, Parts 1 - 3|Prozesstechnik|
|[[:industrie|IEC 61513]]|2011|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|

==== 2. Security ====

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

^Kennung^Jahr^Titel^Anmerkung|
|[[:industrie|IEC 62443-4-1]]|2018|Security for industrial automation and control systems – Part 4-1: Secure product development lifecycle requirements|Produktentwicklung|
|[[:industrie|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|
|[[:industrie|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) ===

^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|
|[[: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 ===

^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|
|[[:industrie|ISO/IEC 19792]]|2009|Information technology – Security techniques – Security evaluation of biometrics|Biometrische Technologie|

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

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

=== 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|
|[[:industrie|DIN EN 1627]]|2021|Pedestrian doorsets, windows, curtain walling - Burglar resistance|Einbruchshemmung|
|[[:industrie|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|
|[[:industrie|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|
|[[:industrie|IEC/TR 63069]]|2019|Framework for functional safety and security|Anwendung im Maschinenbereich, IEC 62443|

===== 1 Risiko: Definition und Herausforderungen =====
 <font 18px/inherit;;inherit;;inherit>__**Funktionale Sicherheit:**__</font>

Hinweis: Zur Erklärung der Begrifflichkeiten Risiko und Funktionale Sicherheit siehe Abschnitt 5 „Risikobegriff im Kontext von funktionaler Sicherheit“.

 \\
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 Ausfallwahrscheinlichkeit 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. Weiterhin werden keine direkten Bezüge zum Thema „Physical Security“ hergestellt.

Unscharfe Risikobeiträge werden nur bei der Berechnung der Ausfallwahrscheinlichkeit berücksichtigt. Dazu werden die bekannten Methoden der Statistik verwendet, d. h. Berücksichtigung von statistischen Verteilungen der Bauteil-Ausfallraten (standardmäßig Exponentialverteilung) 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.

----
 <font 18px/inherit;;inherit;;inherit>__**Security:**__</font>

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

**Herleitung & Definitionen**

Die Security in der Anlagensicherheit ist traditionell (bedingt durch seine historische Ausprägung) oft in verschiedene Fachgebiete unterteilt. Grundsätzlich und vereinfacht dargestellt kann zwischen Physical Security und IT-Security (wobei ITOT-Security dazugezählt werden sollte, siehe unten) unterscheiden 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 „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 Bürostrukturen aufrechtzuerhalten. Frühe Beispiele für einen „Wurm“ (Creeper) und dessen „Antivirus“ (Reaper) gehen beispielsweise bereits auf das Jahr 1971 zurück (IEEE Computer Society, 2005). Diese zu schützenden Kernelemente sind die heute für die IT-Security maßgeblichen Werte:

  * 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 seit ~10-15 Jahren stark an Bedeutung gewinnt. Spätestens seit dem Stuxnet-Wurm aus dem Jahr 2010, welcher gezielt die Zentrifugen des iranischen Atomanreicherungsprogramms zerstörte (Kushner, 2013) wurde die Absicherung von Produktionsnetzen und –anlagen immer wichtiger. Verstärkt wird dies durch den voranschreitenden Trend der Digitalisierung (Stichwort Industrie 4.0) in dessen Sogwirkung auch alte und somit bisher offline betriebene Analgenteile 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 den 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 ITOT 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.) \\  \\
Dabei sind jedoch einige Besonderheiten zu beachten (Auszug): \\  \\
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 verscheiden 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 relativ 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 einen 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.

__ <font 16px/inherit;;inherit;;inherit>**Herausforderungen:**</font> __
  * 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 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 harmonisieren (ähnlich zur Safety, siehe oben). Zusätzlich sind in letzter Zeit 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. Dies hängt u.a. auch damit zusammen, dass es im Bereich der IT-Security noch relativ wenig Erfahrung gibt, um Risiken zu bewerten. 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 Meinungen 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 Angreife. 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. Auch einen negativen Einfluss auf das Gefährdungsbewusstsein wird den Scannern nachgesagt, da man ja vermeintlich geschützt ist und somit im Zweifelsfall mehr Risiken eingeht. Andererseits sind viele erfolgreiche Angriffe nicht neu, sondern zumeist bekannt oder nur leicht verändert, womit sie für Virenscanner bis zu einem gewissen Grad erkennbar bleiben. Auch die Updatefrequenz vieler Virenscannerhersteller hat sich deutlich erhöht. Systemerkennungs-Software und Deep-Learning-Algorithmen haben ebenfalls zur Beschleunigung und Verbesserung der Erkennungsraten beigetragen.
  * 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 großteils mit massiven Lü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) nahezu wirkungslos machen würde. Bis wann Quantencomputern „Einsatzfähig“ sind ist aktuell ungewiss.
      * 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.
  * Die Entwicklung von wirkungsvollen IT-Security Maßnahmen ist ein oft langwieriger Prozess, so hat sich bisher kein Verfahren zur „Post Quanten“ Kryptographie – also ein Kryptographische Verfahren welches auch Quantencomputern standhält (siehe oben) – durchgesetzt (Böck, 2019). Ausgehend von der ersten Konferenz zu diesem Themenkomplex im Jahr 2006 haben sich seitdem diverse Forschungs- und Lösungsansätze mit unterschiedlichen Vor- als auch Nachteilen gebildet (Pomper, 2018). Erschwerend kommt hinzu das in vielen Ansätzen noch diverse Sicherheitslücken / Schwachstellen existieren, welche sich bereits mit heute verfügbaren Mitteln ausnutzen lassen (Eye, 2009). Darüber hinaus ist bisher unklar inwieweit bisherige Produkte (Hard und/oder Software) mit den neuen Kryptographische Verfahren nachgerüstet werden können oder ob hierfür neue Produktentwicklungen notwendig sind, z.B. aufgrund der zusätzlich benötigten Rechenleistung.

----

[1] Modere Produkte enthalten meist sehr viele Zeilen Code (SLOC bzw. LOC). Als grober Richtwert werden 15 - 50 Fehler per 1000 Zeilen ausgelieferten Code für die Industrie angesetzt (McConnell, 2004) , wobei dies je nach Aufwand deutlich variieren kann. So wies die Software des Spaceshuttles 0 Fehler in 500,000 Zeilen Code auf (McConnell, 2004) . Zum Vergleich: Firefox- und Chromebrowser ~ 5-10 Millionen LOC, Boing 787 ~ 14 Millionen LOC, F-35 ~24 Millionen LOC, Win XP ~ 40 Millionen LOC (McCandless, 2005). Bei sicherheitsrelevanten Anwendungen empfiehlt es sich folglich eine möglichst geringe Anzahl Code zu verwenden. Dies widerspricht allerdings leider oft der Philosophie der Produktdesigner nach einem immer größer werdenden Funktionsumfang, unabhängig davon was der Kernzweck ist/war.

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

__ <font 16px/inherit;;inherit;;inherit>**Safety:**</font> __ \\  \\
In der Funktionalen Sicherheit werden Risikoanalysen im Wesentlichen qualitativ oder semi-quantitativ durchgeführt. Zunächst werden in der Regel an einem System potentielle 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 potentiellen 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)). \\  \\
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.

{{  :8056410484d9faf7061b47029c8392f2.png  }}

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

__** <font 16px/inherit;;inherit;;inherit>Security:</font> **__

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

  * 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:

** <font 16px/inherit;;inherit;;inherit>1) BSI-Grundschutz Standard 200-3 (Bundesamt für Sicherheit in der Informationstechnik (BSI), 2017)</font> **

 \\
Zur Vorbereitung der Risikoanalyse werden die Assets einer Schutzbedarfsfeststellung unterzogen (siehe Abbildung 3).

{{:0b31bf3445d693e583489d68a73da518.png}}

Abbildung 3: Integration der Risikoanalyse in den Sicherheitsprozess nach BSI Standard 200-3

Hierfür wird jedem Asset ein Schutzbedarf (normal, hoch, sehr hoch) für jeden der Werte (Verfügbarkeit, Integrität, Vertraulichkeit) zugewiesen. Beispiele nach welchen Kriterien „normal“ „hoch“ und „sehr hoch“ vergeben werden sind in Abbildung 4 dargestellt. 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). \\  \\ {{:92ee686944dd1c1fdac73e3e3964febf.png}}

Abbildung 4: Schutzbedarfskriterien für ein fiktives Beispiel gemäß BSI (Bundesamt für Sicherheit in der Informationstechnik (BSI)) \\  \\
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, in der Verantwortung des Durchführenden.

 \\
 <font 16px/inherit;;inherit;;inherit>**S**</font>
 <font 16px/inherit;;inherit;;inherit>**chritt 1:**</font>  Erstellung einer Gefährdungsübersich t

  * 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

{{:948f3701905be092c39c91ffff24b9ae.png}}

Abbildung 5: Gefährdungen (Auszug) und ihr möglicher Einfluss auf die Grundwerte gemäß BSI Standard 200-3, Dabei steht C für Confidentiality (Vertraulichkeit), I für Integrity (Integrität) und A für Availability (Verfügbarkeit
 <font 16px/inherit;;inherit;;inherit>**Schritt 2:**</font>  Risikoeinstufung

  * Risikoeinschätzung (Ermittlung von Eintrittshäufigkeit und Schadenshöhe)

{{:875690101c1a1c1cc9d56536f397c5d1.png}}

{{:a46a6d0a1f30e2102ad2f08ca8ce4e4a.png}}

Tabelle 1: Kategorisierung von Eintrittshäufigkeiten (Bundesamt für Sicherheit in der Informationstechnik (BSI))

{{:a7397f0fa92cf5e9bf80383180459171.png}}

Tabelle 2: Kategorisierung von Schadensauswirkungen (Bundesamt für Sicherheit in der Informationstechnik (BSI))

  * Risikobewertung (Ermittlung der Risikokategorie)

{{:7ce236fe30d6d462b463b914722bbce8.png}} \\
Abbildung 6: Matrix zur Einstufung von Risiken (Bundesamt für Sicherheit in der Informationstechnik (BSI), 2019)
 <font 16px/inherit;;inherit;;inherit>**Schritt 3:**</font>  Risikobehandlung

  * Risikovermeidung
  * Risikoreduktion (Ermittlung von Sicherheitsmaßnahmen)
  * Risikotransfer
  * Risikoakzeptanz

{{:9f021c3b72c6ae429ea3a83a613aeaea.png}}

Abbildung 7: Risikobehandlung (Bundesamt für Sicherheit in der Informationstechnik (BSI), 2019)
 <font 16px/inherit;;inherit;;inherit>**Schritt 4: **</font>  Konsolidierung des Sicherheitskonzepts

  * Integration der aufgrund der Risikoanalyse identifizierten zusätzlichen Maßnahmen in das Sicherheitskonzept BSI-Standard200-3

Diese Schritte sind gemäß PDCA – Zyklus (siehe Abbildung 8) als andauernder Prozess zu verstehen und am besten in enger Anbindung an die ISO 27000 Familie anzuwenden

{{:ebd52c3f994baa7e99ede711cc857093.png}}

Abbildung 8: PDCA-Zyklus gemäß BSI Standard 200-1

Abbildung 9 zeigt eine sehr ähnliche Methodik, welche von der NIST in ihrem Risk Management Framework verwendet wird. Die zugehörigen Regelwerke zu den einzelnen Schritten sind dabei den äußere zweie Ringen der Abbildung 9 zu entnehmen.

{{:710421427e35e7a097f1942f54322540.png}}

Abbildung 9: Schaubild Risk Management Framework der NIST

** <font 16px/inherit;;inherit;;inherit>2) IEC 62443 Familie:</font> ** \\  \\
Ein Security-Angriff kann nur erfolgen, wenn neben einer Bedrohung (motivierter Angreifer) eine oder mehrere Schwachstellen vorhanden sind. Daher müssen bei der Risiko-Betrachtung bzw. bei den Gegenmaßnahmen zur Verminderung des Risikos mögliche Schwachstellen betrachtet werden.

{{:b78d90b3c4220ee581be2ef59082953d.png}}

Abbildung 10: Security Risiko Betrachtung

Zur Risikobestimmung wird die IEC 62443-3-2 angewendet, die eine Risikobetrachtung einer Komponente im System durchführt. Dabei wird das Risiko in vier Stufen (Security Levels) eingeteilt, wobei SL 1 für den Schutz gegen versehentliches/zufälliges Eindringen und SL 4 für den Schutz gegen absichtliche Versuche mit spezifischen Kenntnissen und erheblichen Mitteln steht. Der bestimmte SL-Wert für die Systemkomponente bezieht sich auf den Einsatz im System. D.h. eine Systemkomponente, die in unterschiedlichen Systembereichen verwendet wird, kann unterschiedliche Security Levels haben. Das Gerät muss nach dem höchsten Security-Level entwickelt worden sein, welcher bei dem Einsatz im System auftreten kann. Es werden dabei unterschiedlichen Methoden angewendet:

  * FMEA (auf Systemebene  Angriffsmöglichkeiten im System)
  * FMEA (auf Produktebene  Angriffsmöglichkeit direkt auf das Produkt (physikalischer Zugriff); eine wichtige Betrachtung für die Produktentwicklung)
  * Angriffsbäume
  * Checklisten

Ähnlich wie bei Safety wird das Risiko mit folgender Formel festgelegt: \\  \\ ** <font 18px/inherit;;inherit;;inherit>Risiko = Eintrittswahrscheinlichkeit x Schadensausmaß</font> ** \\  \\ {{:07933bb8c488641c5981af2f3ac6a729.png}} \\
Abbildung 11: Schadensmatrix Security (Quelle: 998-20298472_Cybersecurity_Assessments_GMA_White_Paper.pdf)

Eine mögliche Zuordnung der SL-Werte wird in der Abbildung 3 verdeutlicht. Die Farbe Grün stellt SL 1 dar, Gelb einen SL 2, Orange einen SL 3 und Rot einen SL 4 (siehe Abbildung 3). \\  \\
Die Bestimmung der Eintrittswahrscheinlichkeit ist nicht eindeutig qualitativ oder quantitativ erfassbar. Man greift hier auf Hilfsmittel zurück und schätzt ab, wer Interesse hat einen Angriff durchzuführen. Hier müssen intuitiv 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 mit bewertet. Hieraus kann eine subjektive Wahrscheinlichkeit des Angriffs abgeleitet werden. Das Risiko kann noch vermindert werden, wenn ein Angriff entdeckt werden kann. Der Zusammenhang wird in der Abbildung 4 veranschaulicht. Das Schadensausmaß muss individuell bestimmt werden. Eine mittelständische Firma hat bei einem finanziellen Schaden einen anderen Maßstab als ein Großkonzern.

Bezüglich unscharfer oder unsicherer Risikobeiträge im Bereich Security im Industrieumfeld gibt es den Vorschlag, das minimale Risiko auf SL 2 festzulegen. Bei höheren anzunehmenden Schäden kann auf SL 3 erhöht werden. Ein SL 4 ist technisch schwer umsetzbar und sehr kostenintensiv und wird daher ausgeschlossen. Bei einer zu hohen Gefahr wird davon abgesehen die Applikation umzusetzen. \\
Ausgehend von einem noch nicht veröffentlichen Kapitel der IEC 62443, welches aber in der Praxis bereits von einigen Firmen umgesetzt wird, soll zukünftig auch der Reifegrad der Organisation bzw. der technischen Umsetzung mit einbezogen werden. Abbildung 10 zeigt die sich ergebende Matrix für SL und Reifegrad. \\  \\ {{:e79dca40d556eb597940e23893873b2e.png}}

Abbildung 12: Einbezug des Reifegrades (ZVEI, 2017) \\  \\
 <font 16px/inherit;;inherit;;inherit>**3) Checkliste nach NA 163**</font>  \\  \\
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. \\  \\ {{:eda0d18bf80d018b961768c5554a5e53.png}}

Abbildung 13: Struktur einer Risikobeurteilung mit den durch NA 163 vordefinierten Schritten (Kruschitz, 2017) \\  \\
Checkliste der NA 163 abgearbeitet werden können. Die Checkliste selbst nennt zumeist verschiedene Bauteile oder Organisationsstrukturen und gibt hierfür konkrete Maßnahmen vor, welche von erklärenden Hilfstexten flankiert werden, siehe Abbildung 11. \\  \\ {{:267a003b12b07a85364b245dd2592a19.png}}

Abbildung 14: Auszug aus der Checkliste der NA 163 (Namur, 2017)
 <font 16px/inherit;;inherit;;inherit>__**Schwachstellenermittlung:**__</font>  \\  \\
Existierende Schwachstellen werden u.a. systematisch erfasst und vom Schweregrad bewertet. Eines der gebräuchlichsten Systeme ist das Common Vulnerbility Scoring System (CVSS). Dieses Rating teilt Schwachstellen in Abhängigkeit von deren Schwere in 5 Kategorien ein: None, Low, Medium, High, Critical, siehe Abbildung 14. \\  \\
Die Bewertungskriterien sind auf der CVSS-Seite erläutert (Siehe Abbildung 13).

{{:3bc381eee5fc43ec3df6458f099ca5df.png}}

Abbildung 15: Common Vulnerabiliy Scoring System (Quelle: [[https://www.first.org/cvss/|https://www.first.org/cvss/]]) \\  \\ {{:8631ebc51c4a4007a6c166a626678fa3.png}} \\
Abbildung 16: Rating der CVSS Cores \\  \\
Eine Auflistung aller bekannten Schwachstellen erfolgt in der CVE-Datenbank (siehe Abbildung 15), welche frei verfügbar eingesehen werden kann. \\  \\ {{:dd9b95607da180f04d4bcb51f24460d9.png}} \\
Abbildung 17: CVE- Security Vulnerabiliy Data Source ([[https://www.cvedetails.com/|https://www.cvedetails.com/]]) \\  \\
Wenn bei Safety-Entwicklungen Security Risiken mit **Safety-Impakt**  auftreten, müssen diese auch Safety konform betrachtet werden. Eine reine Anwendung nach üblichen Security-Normen ist hier nicht zulässig. Hier steht die Vorgehensweise, die bei der Safety angewendet wird, im Vordergrund, insbesondere wenn Menschenleben in Gefahr sind. In diesem Fall muss nachgewiesen werden, dass das Produkt nach dem Stand der Technik entwickelt worden ist. Reine Security-Risiken, die nur einen finanziellen Schaden versuchen, können nicht betrachtet werden. Sobald ein Safety-Impakt erkennbar ist muss das Risiko auf ein vertretbares Maß reduziert werden.

===== 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. \\  \\
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. Allerdings können im Bereich der Security 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. 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 potentiellen Angreifers, die man schwer abschätzen kann, insbesondere nicht in quantitativer Form.

Die Schwachstellen werden teilweise bereits gut erfasst und auch mathematisch bewertet (siehe Abbildung 6). Zu 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 dessen Bewertung analog zu den Schwachstellen.

===== Quellen =====

__Normen__

Safety:

  * IEC 61508:2010 Parts 1 - 7, Functional safety of electrical/electronic/programmable electronic safety-related systems
  * EN ISO 12100:2010, Safety of machinery - General principles for design - Risk assessment and risk reduction
  * EN 62061:2016, Safety of machinery - Functional safety of safety-related electrical, electronic and programmable electronic control systems
  * EN ISO 13849-1:2015, Safety of machinery - Safety-related parts of control systems - Part 1: General principles for design
  * EN ISO 13849-2:2012, Safety of machinery - Safety-related parts of control systems - Part 2: Validation
  * EN 61800-5-2:2017, Adjustable speed electrical power drive systems - Part 5-2: Safety requirements – Functional Safety
  * IEC 61511:2016 Parts 1 - 3: Functional safety - Safety instrumented systems for the process industry sector
  * IEC 61513:2011 Nuclear power plants - Instrumentation and control important to safety - General requirements for systems
  * DIN 820-12:2014, Normungsarbeit - Teil 12: Leitfaden für die Aufnahme von Sicherheitsaspekten in Normen

 \\
Security:

  * DIN 4102-1:1998-05 Brandverhalten von Baustoffen und Bauteilen - Teil 1: Baustoffe; Begriffe, Anforderungen und Prüfungen
  * DIN 4102-2:1977-09 Brandverhalten von Baustoffen und Bauteilen; Bauteile, Begriffe, Anforderungen und Prüfungen
  * DIN 4102-3:1977-09 Brandverhalten von Baustoffen und Bauteilen; Brandwände und nichttragende Außenwände, Begriffe, Anforderungen und Prüfungen
  * DIN 4102-4:2016-05 Brandverhalten von Baustoffen und Bauteilen - Teil 4: Zusammenstellung und Anwendung klassifizierter Baustoffe, Bauteile und Sonderbauteile
  * DIN 4102-4:2016-05 Brandverhalten von Baustoffen und Bauteilen - Teil 4: Zusammenstellung und Anwendung klassifizierter Baustoffe, Bauteile und Sonderbauteile
  * DIN EN 1627:2019-05 – Entwurf Türen, Fenster, Vorhangfassaden, Gitterelemente und Abschlüsse - Einbruchhemmung - Anforderungen und Klassifizierung
  * DIN EN 1628:2019-05 – Entwurf Türen, Fenster, Vorhangfassaden, Gitterelemente und Abschlüsse - Einbruchhemmung - Prüfverfahren für die Ermittlung der Widerstandsfähigkeit unter statischer Belastung
  * DIN EN 1629:2019-04 – Entwurf Türen, Fenster, Vorhangfassaden, Gitterelemente und Abschlüsse - Einbruchhemmung - Prüfverfahren für die Ermittlung der Widerstandsfähigkeit unter dynamischer Belastung;
  * DIN EN 60529 Berichtigung 1:2017-02;VDE 0470-1 Berichtigung 1:2017-02
  * DIN EN 60529 Berichtigung 2:2019-06;VDE 0470-1 Berichtigung 2:2019-06
  * DIN EN 60529:2014-09;VDE 0470-1:2014-09 Schutzarten durch Gehäuse (IP-Code) (IEC 60529:1989 + A1:1999 + A2:2013)
  * IEC 62443-1-1:2009, Industrial communication networks – Network and system security – Part 1-1: Terminology, concepts and models
  * IEC 62443-1-2, Industrial communication networks - Network and system security Part 1-2: Glossary
  * IEC 62443-1-3, Industrial communication networks - Network and system security - Part 1-3: System security compliance metrics
  * IEC 62443-2-2, Industrial communication networks - Network and system security - Part 2-2: Implementation guidance for an industrial automation and control system security program
  * IEC 62443-2-3:2015, Security for industrial automation and control systems - Part 2-3: Patch management in the IACS environment
  * IEC 62443-2-4:2017, Security for industrial automation and control systems - Part 2-4: Security program requirements for IACS service providers
  * IEC 62443-3-2 Industrial communication networks - Network and system security - Part 3-2: Security levels for zones and conduits
  * IEC 62443-4-1:2019 Security for industrial automation and control systems – Part 4-1: Secure product development lifecycle requirements.
  * IEC 62443-4-2:2018 Industrial communication networks - Network and system security - Part 4-2: Technical security requirements for industrial automation and control system components
  * ISO/IEC TR 19791:2010, Security techniques – Security assessment of operational systems
  * IEC/TR 63069 - Framework for Functional Safety and Security
  * IEC 62443-2-1:2010, Industrial communication networks – Network and system security – Part 2-1: Establishing an industrial automation and control system security program
  * IEC 62443-3-1:2009, Industrial communication networks – Network and system security – Part 3-1: Security technologies for industrial automation and control systems
  * IEC 62443-3-3:2013 Industrial communication networks – Network and system security – Part 3-3: System security requirements and security levels
  * ISO/IEC 10118-1:2016 Information technology – Security techniques – Hash-functions – Part 1: General
  * ISO/IEC 10118-2:2010 Information technology – Security techniques – Hash-functions – Part 2: Hash-functions using an n-bit block cipher
  * ISO/IEC 10118-3:2018 IT Security techniques – Hash-functions – Part 3: Dedicated hash-functions
  * ISO/IEC 10118-4:1998 Information technology – Security techniques – Hash-functions – Part 4: Hash-functions using modular arithmetic
  * ISO/IEC 11770-1:2010 Information technology – Security techniques – Key management – Part 1: Framework
  * ISO/IEC 11770-2:2018 IT Security techniques – Key management – Part 2: Mechanisms using symmetric techniques
  * ISO/IEC 11770-3:2015 Information technology – Security techniques – Key management – Part 3: Mechanisms using asymmetric techniques
  * ISO/IEC 11770-4:2017 Information technology – Security techniques – Key management – Part 4: Mechanisms based on weak secrets
  * ISO/IEC 11770-5:2011 Information technology – Security techniques – Key management – Part 5: Group key management
  * ISO/IEC 11770-6:2016 Information technology – Security techniques – Key management – Part 6: Key derivation
  * ISO/IEC 13335-1:2004 Information technology – Security techniques – Management of information and communications technology security – Part 1: Concepts and models for information and communications technology security management
  * ISO/IEC 15408:2009 – Common Criteria
  * ISO/IEC 17799:2005 Information technology – Security techniques – Code of practice for information security management
  * ISO/IEC 18028-1:2006 Information technology – Security techniques – IT network security – Part 1: Network security management
  * ISO/IEC 18028-2:2006 Information technology – Security techniques – IT network security – Part 2: Network security architecture
  * ISO/IEC 18028-3:2005 Information technology – Security techniques – IT network security – Part 3: Securing communications between networks using security gateways
  * ISO/IEC 18028-4:2005 Information technology – Security techniques – IT network security – Part 4: Securing remote access
  * ISO/IEC 18028-5:2006 Information technology – Security techniques – IT network security – Part 5: Securing communications across networks using virtual private networks
  * ISO/IEC 18033-1:2015 Information technology – Security techniques – Encryption algorithms – Part 1: General
  * ISO/IEC 18033-2:2006 Information technology – Security techniques – Encryption algorithms – Part 2: Asymmetric ciphers
  * ISO/IEC 18033-3:2010 Information technology – Security techniques – Encryption algorithms – Part 3: Block ciphers
  * ISO/IEC 18033-4:2011 Information technology – Security techniques – Encryption algorithms – Part 4: Stream ciphers
  * ISO/IEC 18033-5:2015 Information technology – Security techniques – Encryption algorithms – Part 5: Identity-based ciphers
  * ISO/IEC 18033-6:2019 IT Security techniques – Encryption algorithms – Part 6: Homomorphic encryption
  * ISO/IEC 18045:2008 Information technology – Security techniques – Methodology for IT security evaluation
  * ISO/IEC 19790:2012 Information technology – Security techniques – Security requirements for cryptographic modules
  * ISO/IEC 19792:2009 Information technology – Security techniques – Security evaluation of biometrics
  * ISO/IEC 27000:2018 Information technology – Security techniques – Information security management systems – Overview and vocabulary
  * ISO/IEC 27001:2013 Information technology — Security techniques — Information security management systems — Requirements
  * ISO/IEC 27002:2013 Information technology – Security techniques – Code of practice for information security controls
  * ISO/IEC 27004:2016 Information technology – Security techniques – Information security management – Monitoring, measurement, analysis and evaluation
  * ISO/IEC 27005:2018 Information technology – Security techniques – Information security risk management
  * ISO/IEC 27039:2015 Information technology – Security techniques – Selection, deployment and operations of intrusion detection and prevention systems (IDPS)
  * ISO/IEC 9798-1:2010 Information technology – Security techniques – Entity authentication – Part 1: General
  * ISO/IEC 9798-2:2019 IT Security techniques – Entity authentication – Part 2: Mechanisms using authenticated encryption
  * ISO/IEC 9798-3:2019 IT Security techniques – Entity authentication – Part 3: Mechanisms using digital signature techniques
  * ISO/IEC 9798-4:1999 Information technology – Security techniques – Entity authentication – Part 4: Mechanisms using a cryptographic check function
  * ISO/IEC 9798-5:2009 Information technology – Security techniques – Entity authentication – Part 5: Mechanisms using zero-knowledge techniques
  * ISO/IEC 9798-6:2010 Information technology – Security techniques – Entity authentication – Part 6: Mechanisms using manual data transfer
  * ISO/IEC TR 13335-2:1997 Information technology – Guidelines for the management of IT Security – Part 2: Managing and planning IT Security
  * ISO/IEC TR 13335-3:1998 Information technology – Guidelines for the management of IT Security – Part 3: Techniques for the management of IT Security
  * ISO/IEC TR 13335-4:2000 Information technology – Guidelines for the management of IT Security – Part 4: Selection of safeguards
  * ISO/IEC TR 13335-5:2001 Information technology – Guidelines for the management of IT Security – Part 5: Management guidance on network security
  * ISO/IEC TR 15443-1:2012 Information technology – Security techniques – Security assurance framework – Part 1: Introduction and concepts
  * ISO/IEC TR 15443-2:2012 Information technology – Security techniques – Security assurance framework – Part 2: Analysis

__Ergänzende Literatur/Quellennachweise (Zitate):__
  * Alaniz, A. (19. Dezember 2017). [[http://www.andrewalaniz.com|www.andrewalaniz.com]]. Von The Assumed Breach Model – A Practical Approach Part 1 / Part 2 / Part 3 abgerufen
  * Böck, H. (7. Januar 2019). golem.de. Von [[https://www.golem.de/news/post-quanten-kryptographie-zu-viele-vorschlaege-und-zu-viele-bytes-1901-138500.html|https://www.golem.de/news/post-quanten-kryptographie-zu-viele-vorschlaege-und-zu-viele-bytes-1901-138500.html]] abgerufen
  * Börcsök, J. (2015). Funktionale Sicherheit - Grundzüge sicherheitstechnischer Systeme. Berlin: VDE-Verlag.
  * Bundesamt für Sicherheit in der Informationstechnik (BSI). (2017). Risikoanalyse auf Basis des IT-Grundschutzes (Standard 200-3). Bonn: BSI.
  * Bundesamt für Sicherheit in der Informationstechnik (BSI). (2019). IT-Grundschutz Kompendium. Bonn: BSI.
  * Bundesamt für Sicherheit in der Informationstechnik (BSI). (kein Datum). IT-Grund¬schutz-Schu¬lung. Von bsi.bund.de: [[https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzSchulung/itgrundschutzschulung_node.html|https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzSchulung/itgrundschutzschulung_node.html]] abgerufen
  * CERT DGUV [[https://cert.dguv.de/|https://cert.dguv.de/]]
  * DHS. (kein Datum). Von Homeland Security: [[https://www.dhs.gov/topic/cybersecurity|https://www.dhs.gov/topic/cybersecurity]] abgerufen
  * ENISA. (kein Datum). Von European Union Agency for Network and Information Security: [[https://www.enisa.europa.eu/|https://www.enisa.europa.eu/]] abgerufen
  * Eye, F. v. (6. Juni 2009). [[http://www.nm.ifi.lmu.de/|http://www.nm.ifi.lmu.de/]]. Von Institut für Informatik der Fakultät für Mathematik, Informatik und Statistik an der Ludwig-Maximilians-Universität: [[http://www.nm.ifi.lmu.de/~voneye/pdf/vone10.pdf|www.nm.ifi.lmu.de/~voneye/pdf/vone10.pdf]] abgerufen
  * Foltýn, T. (1. November 2018). [[http://www.welivesecurity.com|www.welivesecurity.com]]. Von [[https://www.welivesecurity.com/deutsch/2018/11/01/internet-of-things-cybersecurity-fragwuerdig/|https://www.welivesecurity.com/deutsch/2018/11/01/internet-of-things-cybersecurity-fragwuerdig/]] abgerufen
  * HSE. (kein Datum). Von Health and Safety Executive: [[http://www.hse.gov.uk/eci/cyber-security.htm|http://www.hse.gov.uk/eci/cyber-security.htm]] abgerufen
  * ICS CERT. (kein Datum). Von Industrial Control Systems Cyber Emergency Response Team: [[https://ics-cert.us-cert.gov/|https://ics-cert.us-cert.gov/]] abgerufen
  * IEEE Computer Society. (2005). IEEE Annals of the History of Computing Volumes 27-28. IEEE Computer Society, Institute of Electrical and Electronics Engineers.
  * Jürgen Schmidt, Volker Zota . (19. 4 2016). heise.de. Von [[https://www.heise.de/newsticker/meldung/Zahlen-bitte-Taeglich-390-000-neue-Schadprogramme-3177141.html|https://www.heise.de/newsticker/meldung/Zahlen-bitte-Taeglich-390-000-neue-Schadprogramme-3177141.html]] abgerufen
  * Kienle, M. (26. Januar 2017). Operational IT - Die Grenzen zwischen IT und OT abbauen. Von Computerwoche.de: [[https://www.computerwoche.de/a/operational-it,3329464|https://www.computerwoche.de/a/operational-it,3329464]] abgerufen
  * Kleinhans, J.-P. (2016). Der Staat gegen das Internet der unsicheren Dinge. Zeit Online.
  * Kruschitz, E. (22. März 2017). Cyber Security für funktionale Sicherheit - Sicht der chemischen Industrie. Von [[http://conference.vde.com/fs/2017/Vortragsfolien/Documents/Cyber%20Security%20f%C3%BCr%20funktionale%20Sicherheit%20aus%20Sicht%20d.%20chemischen%20Industire_E.%20Kruschitz.pdf|http://conference.vde.com/fs/2017/Vortragsfolien/Documents/Cyber%20Security%20f%C3%BCr%20funktionale%20Sicherheit%20aus%20Sicht%20d.%20chemischen%20Industire_E.%20Kruschitz.pdf]] abgerufen
  * Kushner, D. (26. Februar 2013). The Real Story of Stuxnet. (I. Spectrum, Hrsg.) Von [[https://spectrum.ieee.org/telecom/security/the-real-story-of-stuxnet|https://spectrum.ieee.org/telecom/security/the-real-story-of-stuxnet]] abgerufen
  * Landoll, D. (2011 (Auflage 2)). The Security Risk Assessment Handbook: A Complete Guide for Performing Security Risk Assessments. CRC Press.
  * Namur. (15. Dezember 2017). AK-PRAXIS 4.18 NA 163 Checkliste 2017-12-15. Von [[https://www.namur.net/fileadmin/media_www/Dokumente/AK-PRAXIS_4.18_NA163_Checkliste_DE_2017_12_15.xlsx|https://www.namur.net/fileadmin/media_www/Dokumente/AK-PRAXIS_4.18_NA163_Checkliste_DE_2017_12_15.xlsx]] abgerufen
  * NAMUR. (15. Dezember 2017). NAMUR.net. Von [[https://www.namur.net/empfehlungen-u-arbeitsblaetter/aktuelle-nena.html|https://www.namur.net/empfehlungen-u-arbeitsblaetter/aktuelle-nena.html]] abgerufen
  * NERC. (kein Datum). Von North American Electric Reliability Corporation: [[https://www.nerc.com/Pages/default.aspx|https://www.nerc.com/Pages/default.aspx]] abgerufen
  * NIST. (kein Datum). Von National Institute for Standards and Technology: [[http://csrc.nist.gov/|http://csrc.nist.gov/]] abgerufen
  * OWASP. (kein Datum). Von Open Web Application Security Project: , [[https://www.owasp.org/index.php/Main_Page|https://www.owasp.org/index.php/Main_Page]] abgerufen
  * P. Wratil und M. Kieviet. (2010). Sicherheitstechnik für Komponenten und Systeme. Berlin: VDE-Verlag.
  * Pomper, A. (2018). Verschlüsselung: Die Zukunft der Kryptographie im Zeitalter der Quantencomputer. Von [[https://www.funkschau.de/telekommunikation/artikel/151797/|https://www.funkschau.de/telekommunikation/artikel/151797/]] abgerufen
  * scadahacker.com. (kein Datum). Von SCADAhacker.com, industrial security of Supervisory Control and Data Acquisition (SCADA): [[https://scadahacker.com/index.html|https://scadahacker.com/index.html]] abgerufen
  * Shostack, A. (2014). Threat Modeling: designing for security. John Wiley & Sons, Inc.
  * Talabis, M. R. (2012). Information Security Risk Assessment Toolkit Practical Assessments through Data Collection and Data Analysis, Syngress (26. Oktober 2012). Syngress.
  * ZVEI. (April 2017). Orientierungsleitfaden für Hersteller zur IEC 62443. Von [[https://www.zvei.org/fileadmin/user_upload/Presse_und_Medien/Publikationen/2017/April/Orientierungsleitfaden_fuer_Hersteller_IEC_62443/Orientierungsleitfaden_fuer_Hersteller_IEC_62443.pdf|https://www.zvei.org/fileadmin/user_upload/Presse_und_Medien/Publikationen/2017/April/Orientierungsleitfaden_fuer_Hersteller_IEC_62443/Orientierungsleitfaden_fuer_Hersteller_IEC_62443.pdf]] abgerufen