| Nächste Überarbeitung | Vorhergehende Überarbeitung |
| start [2023/08/08 16:56] – angelegt csladmin | start [2025/07/21 11:11] (aktuell) – droste |
|---|
| ~~NOCACHE~~ | ~~NOCACHE~~ [[:inhaltsverzeichnis|Inhaltsverzeichnis]] |
| [[http://localhost/inhaltsverzeichnis/| Knowlegebase Inhaltsverzeichnis]] | |
| ---- | ---- |
| ====== Start ====== | |
| **VDI Fachbeirat Sicherheit und Zuverlässigkeit** | |
| |
| //Fachausschuss Safety & Security// | This is example text. |
| | |
| | ++++ Title | |
| | |
| | Text schreiben hier etste test |
| | |
| | ++++ |
| | |
| | ====== VDI Fachbeirat Sicherheit und Zuverlässigkeit ====== |
| |
| | **Fachausschuss //Safety & Security// ** |
| ===== 1 Ziel & Motivation ===== | ===== 1 Ziel & Motivation ===== |
| |
| Die Bewertung von Risiken nimmt in der Regel mögliche zukünftige Entwicklungen vorweg und versucht diese anhand unterschiedlicher Szenarien einzuordnen, so dass z.B. eine Reihung im Sinne der Relevanz oder sogar eine quantitative Bewertung möglich wird. Dieses Unterfangen ist naturgemäß mit eher mehr als weniger Unsicherheiten behaftet, was das Vergleichen von Szenarien durchaus erschwert. Bei der Bemessung von Maßnahmen, die Risiken mindern sollen, sind deshalb Sicherheitsaufschläge ein gängiges Mittel, um Unsicherheiten zu berücksichtigen und somit „auf der sicheren Seite“ zu bleiben. In diesem Sinne lassen sich z.B. Anforderungen an die funktionale Sicherheit von Produkten festlegen, die Redundanzen technischer Komponenten erfordern und somit nicht zuletzt auch die Kosten erhöhen. Müssen nun allerdings Risiken gegen Kosten abgewogen werden (was regelmäßig der Fall ist) oder liegen Risiken vor, deren Anforderungen zur Minderung ggf. sogar in Ihrer Natur widersprüchlich sind, so stellt sich die Aufgabe der Risikoabwägung, die noch größere Herausforderungen bereithält, als die reine Risikobewertung. Dies ist spätestens seit der Corona-Pandemie auch breiteren Anteilen der Bevölkerung bewusst: Maßnahmen zum Gesundheitsschutz der Bevölkerung müssen z. B. gegen Einschränkungen von Grundrechten, wirtschaftliche sowie soziale Belange abgewogen werden. | xDie Bewertung von Risiken nimmt in der Regel mögliche zukünftige Entwicklungen vorweg und versucht diese anhand unterschiedlicher Szenarien einzuordnen, so dass z.B. eine Reihung im Sinne der Relevanz oder sogar eine quantitative Bewertung möglich wird. Dieses Unterfangen ist naturgemäß mit eher mehr als weniger Unsicherheiten behaftet, was das Vergleichen von Szenarien durchaus erschwert. Bei der Bemessung von Maßnahmen, die Risiken mindern sollen, sind deshalb Sicherheitsaufschläge ein gängiges Mittel, um Unsicherheiten zu berücksichtigen und somit „auf der sicheren Seite“ zu bleiben. In diesem Sinne lassen sich z.B. Anforderungen an die funktionale Sicherheit von Produkten festlegen, die Redundanzen technischer Komponenten erfordern und somit nicht zuletzt auch die Kosten erhöhen. Müssen nun allerdings Risiken gegen Kosten abgewogen werden (was regelmäßig der Fall ist) oder liegen Risiken vor, deren Anforderungen zur Minderung ggf. sogar in Ihrer Natur widersprüchlich sind, so stellt sich die Aufgabe der Risikoabwägung, die noch größere Herausforderungen bereithält, als die reine Risikobewertung. Dies ist spätestens seit der Corona-Pandemie auch breiteren Anteilen der Bevölkerung bewusst: Maßnahmen zum Gesundheitsschutz der Bevölkerung müssen z. B. gegen Einschränkungen von Grundrechten, wirtschaftliche sowie soziale Belange abgewogen werden. |
| |
| Die oft widersprüchlichen Anforderungen an Safety- und Security Funktionen waren der Ausgangspunkt zur Einrichtung des Fachausschuss //Safety & Security// des VDI. Im Verlauf der Diskussionen in Sitzungen mit zahlreichen Experten stellte sich allerdings heraus, dass die Mehrzahl der Mitglieder des Ausschusses mit einer etwas anders gelagerten Herausforderung beschäftigt war, dem Einfluss von IT-Security Aspekten auf Safety-Funktionen, die dem Bereich der funktionalen Sicherheit zugeordnet werden können. Es besteht ein großer Bedarf an Vorgehensweisen zur angemessenen Bewertung und Auslegung von IT-Security-Maßnahmen im Hinblick auf die funktionale Sicherheit. Auch aus diesem Grund ergab es sich, dass in der Mehrzahl der in dieser Übersicht betrachteten Disziplinen funktionale Sicherheit eine große Rolle spielt. | Die oft widersprüchlichen Anforderungen an Safety- und Security Funktionen waren der Ausgangspunkt zur Einrichtung des Fachausschuss //Safety & Security// des VDI. Im Verlauf der Diskussionen in Sitzungen mit zahlreichen Experten stellte sich allerdings heraus, dass die Mehrzahl der Mitglieder des Ausschusses mit einer etwas anders gelagerten Herausforderung beschäftigt war, dem Einfluss von IT-Security Aspekten auf Safety-Funktionen, die dem Bereich der funktionalen Sicherheit zugeordnet werden können. Es besteht ein großer Bedarf an Vorgehensweisen zur angemessenen Bewertung und Auslegung von IT-Security-Maßnahmen im Hinblick auf die funktionale Sicherheit. Auch aus diesem Grund ergab es sich, dass in der Mehrzahl der in dieser Übersicht betrachteten Disziplinen funktionale Sicherheit eine große Rolle spielt. |
| === Widersprüche zwischen Safety und Security === | === Widersprüche zwischen Safety und Security === |
| |
| Anforderungen an Safety und Security Funktionen sind oft widersprüchlich. Fluchtmöglichkeiten, z.B. im Falle eines Brandes, werden in Gebäuden durch verriegelte Türen eingeschränkt. Zahlreiche Vorschriften und technische Vorkehrungen, wie z.B. Panikschlösser, reduzieren die negativen Wechselwirkungen von Safety- und Security-Maßnahmen in Gebäuden. Der Absturz des [[https://de.wikipedia.org/wiki/Germanwings-Flug_9525| Germanwings Fluges 9525 ]] in den französischen Alpen ging prominent durch die Medien: Eine Cockpittür ist kugelsicher gepanzert (Security), was das Aufbrechen im Notfall natürlich erheblich erschwert. Ein Sicherheitscode, der der Crew bekannt ist, kann die Verriegelung der Tür im Notfall lösen (Safety), allerdings kann dies aus Gründen der Gefahrenabwehr (Security) aus dem Inneren des Cockpits heraus unterbunden werden. Allem Anschein nach hat dieses Szenario zum Tod von 150 Menschen geführt. | Anforderungen an Safety und Security Funktionen sind oft widersprüchlich. Fluchtmöglichkeiten, z.B. im Falle eines Brandes, werden in Gebäuden durch verriegelte Türen eingeschränkt. Zahlreiche Vorschriften und technische Vorkehrungen, wie z.B. Panikschlösser, reduzieren die negativen Wechselwirkungen von Safety- und Security-Maßnahmen in Gebäuden. Der Absturz des [[https://de.wikipedia.org/wiki/Germanwings-Flug_9525|Germanwings Fluges 9525 ]] in den französischen Alpen ging prominent durch die Medien: Eine Cockpittür ist kugelsicher gepanzert (Security), was das Aufbrechen im Notfall natürlich erheblich erschwert. Ein Sicherheitscode, der der Crew bekannt ist, kann die Verriegelung der Tür im Notfall lösen (Safety), allerdings kann dies aus Gründen der Gefahrenabwehr (Security) aus dem Inneren des Cockpits heraus unterbunden werden. Allem Anschein nach hat dieses Szenario zum Tod von 150 Menschen geführt. |
| |
| Neben Safety und Verfügbarkeit wird damit auch Security regelmäßig zum obersten Gebot technischer Auslegung kritischer Systeme. Widersprüchlichkeiten zwischen den Anforderungen müssen ggf. abgewogen werden, um zum bestmöglichen Design zu kommen. Neben ethischen Fragestellungen wirft dies auch neue technische und wissenschaftliche Fragestellungen auf. Eine Risikoanalyse als Grundlage der übergreifenden Bewertung muss einerseits die Quantifizierung aller Risikobeiträge in einer gemeinsamen Metrik ermöglichen, andererseits müssen auch Unschärfen und Informationslücken berücksichtigt werden, um angemessene Entscheidungen treffen zu können oder die quantitative Analyse als Entscheidungshilfe im Einzelfall auch komplett zu verwerfen. Die Rolle der Unsicherheiten darf insbesondere bei der Abwägung widersprüchlicher Anforderungen nicht vernachlässigt werden, denn unter großen Unsicherheiten ist eine gute Abwägung kaum möglich. | Neben Safety und Verfügbarkeit wird damit auch Security regelmäßig zum obersten Gebot technischer Auslegung kritischer Systeme. Widersprüchlichkeiten zwischen den Anforderungen müssen ggf. abgewogen werden, um zum bestmöglichen Design zu kommen. Neben ethischen Fragestellungen wirft dies auch neue technische und wissenschaftliche Fragestellungen auf. Eine Risikoanalyse als Grundlage der übergreifenden Bewertung muss einerseits die Quantifizierung aller Risikobeiträge in einer gemeinsamen Metrik ermöglichen, andererseits müssen auch Unschärfen und Informationslücken berücksichtigt werden, um angemessene Entscheidungen treffen zu können oder die quantitative Analyse als Entscheidungshilfe im Einzelfall auch komplett zu verwerfen. Die Rolle der Unsicherheiten darf insbesondere bei der Abwägung widersprüchlicher Anforderungen nicht vernachlässigt werden, denn unter großen Unsicherheiten ist eine gute Abwägung kaum möglich. |
| |
| Die Lösungs- und Entscheidungsfindung zur Minimierung offengelegter Zielkonflikte soll durch die Integration von Unsicherheiten, die sich aus der Analyse (z.B. Expertenwissen) sowie der Synthese (z.B. Modellierung) der Risikoaspekte ergeben, abgesichert werden. Diese Unsicherheiten können die Aussagefähigkeit der Risikobewertung stark mindern bzw. die Grundlage möglicher Lösungen oder Entscheidungen in Frage stellen. Aus diesem Grund sollen mit Hilfe des Modells die aus Unsicherheiten resultierenden Einflüsse auf die Risikobetrachtung transparent gemacht werden, so dass optimale Entscheidungen bezüglich zu definierender Kriterien getroffen werden können. Bei sehr unsicherer Informationslage kann so die quantitative Analyse ggf. auch begründet verworfen werden. Bei semi-quantitativen Verfahren ist eine Möglichkeit zur Berücksichtigung von Unsicherheiten dagegen regelmäßig nicht gegeben. | Die Lösungs- und Entscheidungsfindung zur Minimierung offengelegter Zielkonflikte soll durch die Integration von Unsicherheiten, die sich aus der Analyse (z.B. Expertenwissen) sowie der Synthese (z.B. Modellierung) der Risikoaspekte ergeben, abgesichert werden. Diese Unsicherheiten können die Aussagefähigkeit der Risikobewertung stark mindern bzw. die Grundlage möglicher Lösungen oder Entscheidungen in Frage stellen. Aus diesem Grund sollen mit Hilfe des Modells die aus Unsicherheiten resultierenden Einflüsse auf die Risikobetrachtung transparent gemacht werden, so dass optimale Entscheidungen bezüglich zu definierender Kriterien getroffen werden können. Bei sehr unsicherer Informationslage kann so die quantitative Analyse ggf. auch begründet verworfen werden. Bei semi-quantitativen Verfahren ist eine Möglichkeit zur Berücksichtigung von Unsicherheiten dagegen regelmäßig nicht gegeben. |
| | |
| | Entscheidend ist eine schnelle und effektive Kommunikation zu Sicherheitslücken. Dazu wurde die [[https://www.dguv.de/ifa/fachinfos/industrial-security/kontaktstandard-security.txt/index.jsp|Spezifikation IETF RFC 9116 ]]entwickelt, die Hersteller, Betreiber, Behörden und Sicherheitsforscher untereinander vernetzt. |
| |
| ===== 3 Definition Safety & Security ===== | ===== 3 Definition Safety & Security ===== |
| ===== ************** Überarbeitung bis hier ************** ===== | ===== ************** Überarbeitung bis hier ************** ===== |
| |
| ===== 4 IT-Security / Cyber-Security ===== | ===== 4 IT-Security / Informationssicherheit ===== |
| |
| ==== 4.1 Einleitung ==== | ==== 4.1 Einleitung ==== |
| |
| - Anwendung von Redundanz: Verwendung von mehr als einem Mittel zum Ausführen einer geforderten Funktion. Bei einem möglichen Ausfall eines Bauteils oder einer Komponente kann die Funktion von der redundanten Komponente weiterhin ausgeführt werden. Dadurch können zufällige Ausfälle beherrscht werden. Die IEC 61508 definiert die Kenngröße HFT (Hardware Fault Tolerance – Hardware-Fehlertoleranz) zur Beschreibung der Hardware-Struktur von (Teil-)Systemen, welche für die Realisierung einer Sicherheitsfunktionen verwendet wird. HFT = 0 entspricht hierbei z. B. einer einkanaligen Struktur, da der erste (gefahrbringende) Ausfall direkt zum Verlust der Sicherheitsfunktion führen würde. HFT = 1 entspricht dementsprechend einer zweikanaligen Struktur, da ein (gefahrbringender) Ausfall in einem Kanal bei dieser Auslegung noch tolerierbar wäre, wohingegen ein weiterer Ausfall eines Kanals den Verlust der Sicherheitsfunktion zur Folge hätte. HFT = 2 entspricht einer dreikanaligen Struktur usw. | - Anwendung von Redundanz: Verwendung von mehr als einem Mittel zum Ausführen einer geforderten Funktion. Bei einem möglichen Ausfall eines Bauteils oder einer Komponente kann die Funktion von der redundanten Komponente weiterhin ausgeführt werden. Dadurch können zufällige Ausfälle beherrscht werden. Die IEC 61508 definiert die Kenngröße HFT (Hardware Fault Tolerance – Hardware-Fehlertoleranz) zur Beschreibung der Hardware-Struktur von (Teil-)Systemen, welche für die Realisierung einer Sicherheitsfunktionen verwendet wird. HFT = 0 entspricht hierbei z. B. einer einkanaligen Struktur, da der erste (gefahrbringende) Ausfall direkt zum Verlust der Sicherheitsfunktion führen würde. HFT = 1 entspricht dementsprechend einer zweikanaligen Struktur, da ein (gefahrbringender) Ausfall in einem Kanal bei dieser Auslegung noch tolerierbar wäre, wohingegen ein weiterer Ausfall eines Kanals den Verlust der Sicherheitsfunktion zur Folge hätte. HFT = 2 entspricht einer dreikanaligen Struktur usw. |
| - Implementierung von (automatischer) Fehlererkennung: Realisierung von Maßnahmen zur automatischen Erkennung und Beherrschung von Fehlerzuständen innerhalb der Sicherheitsfunktion, welche aus Bauteilausfällen oder systematischen Fehlern resultieren. Grundsätzlich lässt sich sagen, dass die Qualität der Fehlererkennung höher sein muss, falls wenig Redundanzen vorhanden sind oder umgekehrt geringere Anforderungen an die Fehlererkennung gestellt werden, je mehr Redundanzen zum Einsatz kommen. Die IEC 61508 definiert die Kenngröße SFF (Safe Failure Fraction – Anteil sicherer Ausfälle). Dieser Anteil bestimmt sich mittels der sicheren Ausfälle (welche zu keiner gefahrbringenden Situation führen) und den gefahrbringenden Ausfällen, welche rechtzeitig erkannt und beherrscht werden können. Eine Besonderheit gilt für einkanalige Sicherheitsfunktionen: Bei dieser Auslegung gelten für die Erkennung und Beherrschung gefahrbringender Ausfälle in der Regel hohe zeitliche Anforderungen, da der Verlust der Sicherheitsfunktion nicht durch eine weitere Redundanz beherrscht werden kann und daher unmittelbar Gefahr droht. \\ | - Implementierung von (automatischer) Fehlererkennung: Realisierung von Maßnahmen zur automatischen Erkennung und Beherrschung von Fehlerzuständen innerhalb der Sicherheitsfunktion, welche aus Bauteilausfällen oder systematischen Fehlern resultieren. Grundsätzlich lässt sich sagen, dass die Qualität der Fehlererkennung höher sein muss, falls wenig Redundanzen vorhanden sind oder umgekehrt geringere Anforderungen an die Fehlererkennung gestellt werden, je mehr Redundanzen zum Einsatz kommen. Die IEC 61508 definiert die Kenngröße SFF (Safe Failure Fraction – Anteil sicherer Ausfälle). Dieser Anteil bestimmt sich mittels der sicheren Ausfälle (welche zu keiner gefahrbringenden Situation führen) und den gefahrbringenden Ausfällen, welche rechtzeitig erkannt und beherrscht werden können. Eine Besonderheit gilt für einkanalige Sicherheitsfunktionen: Bei dieser Auslegung gelten für die Erkennung und Beherrschung gefahrbringender Ausfälle in der Regel hohe zeitliche Anforderungen, da der Verlust der Sicherheitsfunktion nicht durch eine weitere Redundanz beherrscht werden kann und daher unmittelbar Gefahr droht. |
| Hinweis: Die Implementierung von automatischer Fehlererkennung ist nicht immer zwingend erforderlich. Dies hängt im Wesentlichen vom angestrebten Sicherheitslevel, der Struktur (Anzahl der Redundanzen), der Art der verwendeten Bauteile usw. ab. In manchen Anwendungen ist es zum Teil schwierig, automatische Fehlererkennungsmechanismen zu realisieren. Hierzu existieren in den Normen der Funktionalen Sicherheit mögliche Ausnahmen, z. B. Anwendung von bewährten Bauteilen. Des Weiteren können geeignete Wartungsintervalle zur Aufdeckung unerkannter, gefährlicher Bauteilausfälle festgelegt werden. | |
| | Hinweis: Die Implementierung von automatischer Fehlererkennung ist nicht immer zwingend erforderlich. Dies hängt im Wesentlichen vom angestrebten Sicherheitslevel, der Struktur (Anzahl der Redundanzen), der Art der verwendeten Bauteile usw. ab. In manchen Anwendungen ist es zum Teil schwierig, automatische Fehlererkennungsmechanismen zu realisieren. Hierzu existieren in den Normen der Funktionalen Sicherheit mögliche Ausnahmen, z. B. Anwendung von bewährten Bauteilen. Des Weiteren können geeignete Wartungsintervalle zur Aufdeckung unerkannter, gefährlicher Bauteilausfälle festgelegt werden. |
| - Qualität der Bauteile: Die Zuverlässigkeit einer Sicherheitsfunktion kann durch Verwendung von Bauteilen mit niedriger Ausfallrate λ erhöht werden. | - Qualität der Bauteile: Die Zuverlässigkeit einer Sicherheitsfunktion kann durch Verwendung von Bauteilen mit niedriger Ausfallrate λ erhöht werden. |
| - Maßnahmen gegen Ausfälle gemeinsamer Ursache (Common Cause Failure): Auf Grund von systematischen Fehlern (bei homogener Redundanz) oder externer Beanspruchung (Temperatur, Feuchtigkeit, elektromagnetische Störungen usw.) können redundante Komponenten gleichzeitig oder kurz hintereinander auf Grund einer gemeinsamen Ursache ausfallen. Die Möglichkeit für Ausfälle gemeinsamer Ursache müssen bei der Auslegung einer mehrkanaligen Sicherheitsfunktion berücksichtigt werden und es müssen geeignete Gegenmaßnahmen getroffen werden (z. B. räumliche Trennung, Verwendung diversitärer Redundanzen, Durchführung von Umweltprüfungen wie z. B. EMV, mechanische Beanspruchung, Temperaturprüfungen usw.). | - Maßnahmen gegen Ausfälle gemeinsamer Ursache (Common Cause Failure): Auf Grund von systematischen Fehlern (bei homogener Redundanz) oder externer Beanspruchung (Temperatur, Feuchtigkeit, elektromagnetische Störungen usw.) können redundante Komponenten gleichzeitig oder kurz hintereinander auf Grund einer gemeinsamen Ursache ausfallen. Die Möglichkeit für Ausfälle gemeinsamer Ursache müssen bei der Auslegung einer mehrkanaligen Sicherheitsfunktion berücksichtigt werden und es müssen geeignete Gegenmaßnahmen getroffen werden (z. B. räumliche Trennung, Verwendung diversitärer Redundanzen, Durchführung von Umweltprüfungen wie z. B. EMV, mechanische Beanspruchung, Temperaturprüfungen usw.). |
| Den unterschiedlichen Safety Integrity Level werden feste gefahrbringende Ausfallwahrscheinlichkeiten zugeordnet, welche nicht überschritten werden dürfen. Je höher der angestrebte SIL ist, desto niedriger muss die gefahrbringende Ausfallwahrscheinlichkeit der Sicherheitsfunktion sein. Dazu ist ein rechnerischer Nachweis erforderlich, nämlich die Berechnung von PFH oder PFD. Weiterhin werden nach SIL abgestufte Anforderungen an die Struktur der Hardware und die Anwendung fehlervermeidender Maßnahmen bei der Entwicklung der Hardware und Software definiert. Grundsätzlich gilt, dass für höhere Stufen der Sicherheitsintegrität die fehlervermeidenden Maßnahmen zunehmend umfangreicher werden. | Den unterschiedlichen Safety Integrity Level werden feste gefahrbringende Ausfallwahrscheinlichkeiten zugeordnet, welche nicht überschritten werden dürfen. Je höher der angestrebte SIL ist, desto niedriger muss die gefahrbringende Ausfallwahrscheinlichkeit der Sicherheitsfunktion sein. Dazu ist ein rechnerischer Nachweis erforderlich, nämlich die Berechnung von PFH oder PFD. Weiterhin werden nach SIL abgestufte Anforderungen an die Struktur der Hardware und die Anwendung fehlervermeidender Maßnahmen bei der Entwicklung der Hardware und Software definiert. Grundsätzlich gilt, dass für höhere Stufen der Sicherheitsintegrität die fehlervermeidenden Maßnahmen zunehmend umfangreicher werden. |
| |
| \\ | \\ Ein einfaches Beispiel soll die zuvor genannten Maßnahmen grundlegend erläutern: |
| Ein einfaches Beispiel soll die zuvor genannten Maßnahmen grundlegend erläutern: | |
| |
| Betrachtet wird eine Sicherheitsfunktion zur Überwachung der Temperatur in einem chemischen Reaktor. In dem Reaktor soll die Temperatur einer Chemikalie auf einem konstanten Niveau gehalten werden. Dazu kann ein Heizelement ein- oder ausgeschaltet werden. Dies wird durch eine (nicht sichere) Regelungsfunktion übernommen. Es besteht jedoch die Gefahr, dass die Regelungsfunktion versagt, z. B. falls das Heizelement auf Grund eines Fehlers nicht mehr abgeschaltet wird. Dadurch könnte die Chemikalie eine kritische Temperatur annehmen, was anschließend zu einem Bersten des Reaktors führen könnte. Eine Sicherheitsfunktion soll dieses Risiko geeignet mindern. Dazu wird folgende Sicherheitsfunktion definiert: Abschalten der elektrischen Energieversorgung des Heizelements bei Überschreiten einer festgelegten Temperaturgrenze. | Betrachtet wird eine Sicherheitsfunktion zur Überwachung der Temperatur in einem chemischen Reaktor. In dem Reaktor soll die Temperatur einer Chemikalie auf einem konstanten Niveau gehalten werden. Dazu kann ein Heizelement ein- oder ausgeschaltet werden. Dies wird durch eine (nicht sichere) Regelungsfunktion übernommen. Es besteht jedoch die Gefahr, dass die Regelungsfunktion versagt, z. B. falls das Heizelement auf Grund eines Fehlers nicht mehr abgeschaltet wird. Dadurch könnte die Chemikalie eine kritische Temperatur annehmen, was anschließend zu einem Bersten des Reaktors führen könnte. Eine Sicherheitsfunktion soll dieses Risiko geeignet mindern. Dazu wird folgende Sicherheitsfunktion definiert: Abschalten der elektrischen Energieversorgung des Heizelements bei Überschreiten einer festgelegten Temperaturgrenze. |
| ===== 6 Risiko- und Sicherheitsmetriken ===== | ===== 6 Risiko- und Sicherheitsmetriken ===== |
| |
| Die Entwicklung des Risikomodells könnte in drei Entwicklungsschritten erfolgen: | Die Entwicklung des Risikomodells könnte in drei Entwicklungsschritten erfolgen: 1. Definition eines übergeordneten [[:start#definition_risikobegriff|Risikobegriffs]] 2. Entwicklung eines ganzheitlichen [[:start#definition_risikobegriff|Risikomodells]] 3. Betrachtung von [[:start#betrachtung_von_unsicherheiten|Unsicherheiten]] |
| <font inherit/Calibri;;inherit;;inherit>1.</font> Definition eines übergeordneten [[:start#definition_risikobegriff|Risikobegriffs]] | |
| <font inherit/Calibri;;inherit;;inherit>2.</font> Entwicklung eines ganzheitlichen [[:start#definition_risikobegriff|Risikomodells]] | |
| <font inherit/Calibri;;inherit;;inherit>3.</font> Betrachtung von [[:start#betrachtung_von_unsicherheiten|Unsicherheiten]] | |
| |
| ==== 6.1 Definition Risikobegriff ==== | ==== 6.1 Definition Risikobegriff ==== |
| |
| ==== 9.2 Security ==== | ==== 9.2 Security ==== |
| <font 11pt/Arial,Helvetica,sans-serif;;inherit;;inherit>Alberts, Christopher, Audrey Dorofee, James Stevens, and Carol Woody. “Introduction to the OCTAVE Approach.” Networked Systems Survivability Program. Pittsburgh, PA, USA: Carnegie Mellon University, 2003.</font> | |
| <font 11pt/Arial,Helvetica,sans-serif;;inherit;;inherit>Beyerer, Jürgen, and Jürgen Geisler. “A Framework for a Uniform Quantitative Description of Risk with Respect to Safety and Security.” CKGE_TMP_i European Journal of Security Research CKGE_TMP_i 1 (2016): 135–150.</font> | Alberts, Christopher, Audrey Dorofee, James Stevens, and Carol Woody. “Introduction to the OCTAVE Approach.” Networked Systems Survivability Program. Pittsburgh, PA, USA: Carnegie Mellon University, 2003. Beyerer, Jürgen, and Jürgen Geisler. “A Framework for a Uniform Quantitative Description of Risk with Respect to Safety and Security.” CKGE_TMP_i European Journal of Security Research CKGE_TMP_i 1 (2016): 135–150. BSI - Bundesamt für Sicherheit in der Informationstechnik. “Guidelines for Developer Documentation according to Common Criteria Version 3.1,” 2007. Campbell, Philip L., and Jason E. Stamp. “A Classification Scheme for Risk Assessment Methods.” SANDIA REPORT. Albuquerque, NM, USA: Sandia National Laboratories, 2004. Harnser Group, ed. “A Reference Security Management Plan for Energy Infrastructure.” European Commission, 2010. Landoll, Douglas J. CKGE_TMP_i The Security Risk Assessment Handbook: AComplete Guide for Performing Security Risk Assessments CKGE_TMP_i . 2nd ed. Boca Raton, FL, USA: CRC Press, 2011.NE 153: Automation Security 2020 - Design, Implementierung und Betrieb industrieller Automatisierungssysteme, 2015 |
| <font 11pt/Arial,Helvetica,sans-serif;;inherit;;inherit>BSI - Bundesamt für Sicherheit in der Informationstechnik. “Guidelines for Developer Documentation according to Common Criteria Version 3.1,” 2007.</font> | |
| <font 11pt/Arial,Helvetica,sans-serif;;inherit;;inherit>Campbell, Philip L., and Jason E. Stamp. “A Classification Scheme for Risk Assessment Methods.” SANDIA REPORT. Albuquerque, NM, USA: Sandia National Laboratories, 2004.</font> | |
| <font 11pt/Arial,Helvetica,sans-serif;;inherit;;inherit>Harnser Group, ed. “A Reference Security Management Plan for Energy Infrastructure.” European Commission, 2010.</font> | |
| <font 11pt/Arial,Helvetica,sans-serif;;inherit;;inherit>Landoll, Douglas J. CKGE_TMP_i The Security Risk Assessment Handbook: AComplete Guide for Performing Security Risk Assessments CKGE_TMP_i . 2nd ed. Boca Raton, FL, USA: CRC Press, 2011.NE 153: Automation Security 2020 - Design, Implementierung und Betrieb industrieller Automatisierungssysteme, 2015</font> | |
| |
| ===== 10 Resilienz ===== | ===== 10 Resilienz ===== |
| | |
| | Die Betrachtung der Resilienz ist motiviert durch die Annahme, dass nicht alle zukünftigen Gefährdungssituationen vorhersehbar sind, sondern dass im Gegenteil gerade besonders drastische Störereignisse plötzlich und unerwartet auftreten können. Die Auswirkungen solcher Ereignisse können nicht vollends abgefangen oder verhindert werden. Das Ziel von Resilienz-bildenden oder -stärkenden Maßnahmen ist es stattdessen ein System zu befähigen mit den Auswirkungen von Störungen jedweder Art und Ausprägung umzugehen – auch solcher, die bis zu ihrem Auftreten unbekannt waren. |
| | |
| | ==== 10.1 Definition Resilienz ==== |
| | |
| | Der Begriff Resilienz beschreibt die Fähigkeit eines Systems (unmittelbar sowie langfristig) mit den Auswirkungen unspezifischer und möglicherweise unvorhergesehener Störereignisse umzugehen. Entsprechend der Vielfalt an Mechanismen, die zu einem positiven Umgang mit einem Störereignis beitragen können, ergibt sich die Resilienz eines Systems aus einer Kombination unterschiedlicher Kompetenzen und Strategien. Genau genommen beschreibt der Begriff Resilienz also nicht eine einzelne, sondern eine Gruppe von Fähigkeiten. Diese Gruppe lässt sich anhand dreier übergeordneter Grundfähigkeiten zusammenfassen, die die Zielsetzung resilienten Verhaltens erfassen: Ein resilientes System ist in der Lage die Auswirkungen einer Störung gering zu halten (Absorptionsfähigkeit) und sich von diesen schnell und vollständig zu erholen (Restorationsfähigkeit). Darüber hinaus besitzt ein resilientes System eine gewisse Lernfähigkeit, die es dem System ermöglicht die zum Umgang mit Störungen notwendigen Fähigkeiten zu steigern oder diese in einer sich verändernden Gefährdungslage langfristig zu erhalten (Adaptionsfähigkeit). Jede dieser drei übergeordneten Grundfähigkeiten (Absorptions-, Restorations- und Adaptionsfähigkeit) ergibt sich wiederum aus verschiedenen Resilienz-bildenden Eigenschaften und Fertigkeiten. Beispielsweise kann die Absorptionsfähigkeit eines Systems durch bestimmte Strukturmerkmale (wie ein modulares Design oder das Vorhandensein redundanter Elemente) sowie durch organisatorische Fertigkeiten der handelnden Akteure (z.B. Entscheidungs- und Kommunikationsfähigkeit in Krisensituationen) positiv beeinflusst werden. |
| | |
| | ==== 10.2 Abgrenzung zum Risikobegriff ==== |
| | |
| | Ein entscheidendes Kriterium zur Unterscheidung von Risiko- und Resilienz-basierten Ansätzen zur Steigerung der Sicherheit oder Zuverlässigkeit eines Systems ist die Unsicherheit oder Kenntnis über die Ereignisse oder Szenarien, die die beiden Ansätze adressieren. Während Risiko-basierte Ansätze darauf abzielen ein System auf Gefährdungssituationen vorzubereiten, deren Charakteristika zu einem gewissen Grad bekannt oder zumindest absehbar sind, zielen Resilienz-basierte Ansätze darauf ab ein System auf den Umgang mit beliebigen Gefährdungssituationen vorzubereiten – hierzu zählen insbesondere auch unerwartete und singuläre Störereignisse. Charakteristisch für Resilienz-basierte Betrachtungen ist der starke Fokus auf das System selbst bzw. auf die Ausprägung der resilienten Fähigkeiten dieses Systems. Entsprechende Betrachtungen beinhalten dabei speziell auch die Fähigkeiten, die nach der Ausbildung negativer Folgen zum Tragen kommen (d.h. die Restorations- und Adaptionsfähigkeit des Systems). |
| | |
| | ==== 10.3 Resilienz bewerten und quantifzieren ==== |
| | |
| | Die Bewertung des Resilienz-Status eines Systems – d.h. die Ermittlung des Grades der Fähigkeit eines Systems mit jedweder Störung umgehen zu können – ist mit einigen Schwierigkeiten verbunden. Dies hängt damit zusammen, dass sich die Ausprägung einer Fähigkeit nur in dem Moment manifestiert, in dem diese Fähigkeit gebraucht wird – d.h. im Falle der Resilienz, während eines Störereignisses. Für die Bewertung oder Quantifizierung der Resilienz bedeutet dies im Umkehrschluss, dass um die tatsächliche Resilienz eines Systems fehlerlos zu ermitteln, jede erdenkliche Störung berücksichtigt werden müsste. Folglich kann jede Resilienz-Bewertung nur eine Näherung an die tatsächliche Resilienz eines Systems liefern. Bei entsprechenden Näherungen kann grundsätzlich zwischen zwei Herangehensweisen unterschieden werden – Outcome-basierten (ergebnisorientiert) und Property-basierten (eigenschaftsbasiert). |
| | |
| | Outcome-basierte Ansätze stützen sich auf den Ausgang von exemplarischen Störszenarien um die Resilienz eines Systems zu bewerten. Hierfür muss zum einen eine Auswahl an exemplarischen Störereignissen oder Störfällen getroffen werden und zum anderen ein Maß für die Quantifizierung des Ausgangs einer Störung festgelegt werden. Beide Aspekte beeinflussen das Ergebnis der Resilienz-Bewertung erheblich, weswegen darauf geachtet werden sollte, dass die ausgewählten Szenarien das Spektrum aller möglichen relevanten Störfälle adäquat abdecken und die gewählte Quantifizierung die wesentlichen Systemfunktionen erfasst. Ein besonders verbreiteter Ansatz ist hierbei die Nutzung von Performance-Kurven, die die Funktionsfähigkeit (Performance) eines Systems über den Verlauf einer Störung anhand eines oder mehrerer charakteristischer Performance-Indikatoren darstellen. Mit Hilfe bestimmter Metriken, wie der Fläche unter der Performance-Kurve oder der Steigung der Performance-Restoration, können aus diesen Kurven Kennzahlen abgeleitet werden, die die Güte der Systemantwort auf die entsprechende Störung charakterisieren. Die Zusammenschau einer gewissen Menge von Performance-Kurven ermöglicht es dann Rückschlüsse auf die Resilienz zu ziehen, die den beobachtenden Systemantworten zugrunde liegt. |
| | |
| | Eine Alternative zu Outcome-basierten Bewertungen der Resilienz stellt die Property-basierte Betrachtung dar. Bei dieser Herangehensweise wird die Resilienz eines Systems anhand von Systemeigenschaften bewertet, von denen angenommen wird, dass sie die Grundlage der resilienten Fähigkeiten bzw. die Grundlage resilienten Verhaltens bilden. Entsprechende Ansätze beruhen also nicht auf der Betrachtung realer oder simulierter Störfälle, sondern betrachten das System im ungestörten Zustand um dessen Potential mit möglichen Störungen umzugehen abzuschätzen. Eine weitverbreitete Methodik stellen in diesem Kontext sogenannte Resilienz-Kompositions-Indikatoren dar, die Informationen aus unterschiedlichen Quellen (z.B. Umfrageergebnisse, demographische Daten, Expert*innen-Befragungen), einer konzeptionellen Hierarchie folgend, zusammenführen um die Resilienz eines Systems anhand einer Reihe von Kennzahlen darzustellen. Je nach Kompositions-Indikator können sich die verschiedenen Kennzahlen dabei auf unterschiedliche Aspekte der Resilienz beziehen, beispielsweise auf die verschiedenen Resilienz-Fähigkeiten oder die unterschiedlichen Wirkungsdimensionen der Resilienz (technisch, organisatorisch, sozial, ökonomisch). |
| |
| ===== Disziplinen ===== | ===== Disziplinen ===== |
| |
| [[:arbeitsschutz|Arbeitsschutz]] | [[:content:arbeitsschutz|Arbeitsschutz]] |
| | |
| | [[:content:automotive|Automobile Sicherheit]] |
| |
| [[:automotive|Automobile Sicherheit]] | [[:content:railway|Railway]] |
| |
| [[:railway|Railway]] | [[:content:industrie|Industrie und Produktionsanlagen]] |
| |
| [[:industrie|Industrie und Produktionsanlagen / Industríe 4.0]] | [[:content:kernenergie|Kernenergieanlagen]] |
| |
| [[:kernenergie|Kernenergieanlagen]] | [[:content:luftfahrt|Luftfahrt]] |
| |
| [[:luftfahrt|Luftfahrt]] | [[:content:maritime_sicherheit|Maritime Sicherheit]] |
| |
| [[:maritime_sicherheit|Maritime Sicherheit]] | [[:content:oeffentliche_sicherheit|Öffentliche Sicherheit]] |
| |
| [[:oeffentliche_sicherheit|Öffentliche Sicherheit]] | [[:content:physische_sicherheit|Physische Sicherheit]] |
| |
| [[:physische_sicherheit|Physische Sicherheit]] | [[:content:kritis|Kritische Infrastrukturen (KRITIS)]] |
| |
| [[:kritis|Kritische Infrastrukturen (KRITIS)]] | [[:content:beherrschung_von_unsicherheit|Beherrschung von Unsicherheit]] |
| |
| |