start [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.
~~NOCACHE~~ [[:inhaltsverzeichnis|Inhaltsverzeichnis]]

----

====== VDI Fachbeirat Sicherheit und Zuverlässigkeit ======

**Fachausschuss //Safety & Security// **
===== 1 Ziel & Motivation =====

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.
==== 1.1 Safety & Security gemeinsam betrachten ====

Es sind im Wesentlichen zwei gegenwärtige Entwicklungen, die eine gleichzeitige Behandlung von Safety und Security nahelegen: Die zunehmende IT-basierte Vernetzung und damit zunehmende Vulnerabilität unserer Gesellschaft, aber auch ein signifikant zunehmendes Bedrohungsniveau für moderne Gesellschaften, das sich keinesfalls auf Szenarien der Cyberangriffe beschränkt, sondern auch physische Bedrohungen einbeziehen muss. In technischen Zusammenhängen spielen Infrastrukturen dabei eine zentrale Rolle.

=== (IT-)Security Impact on Safety ===

Komplexe Sicherheitsfunktionen in technischen Anlagen und z.B. auch Automobilen sind oft zeitkritisch; ihre sichere Funktion hängt von der schnellen und sicheren Kommunikation in Netzwerken ab. Die allgegenwärtige und zunehmende Vernetzung macht die IT-Sicherheit zu einer der zentralen Herausforderungen der Zukunft.

Die Funktionale Sicherheit spielt eine zentrale Rolle bei der Risikominderung komplexer technischer Systeme in zahlreichen Disziplinen. Sicherheitsfunktionen stellen z.B. die rechtzeitige Abschaltung gefährdender Systeme wie z.B. Chemieanlagen oder Zugangsbeschränkung zu Gefahrenbereichen sicher und schützen somit ggf. zahlreiche Leben und körperliche Unversehrtheit. Die technische Umsetzung von Sicherheitsfunktionen erfordert in der Regel neben Sensoren und Aktoren Logik- oder IT-Systeme, die bei gegebener Vernetzung grundsätzlich für Cyberangriffe vulnerabel sind. In gängigen Standards und Sicherheitsrichtlinien, z.B. IEC 61508, finden diese Bedrohungen nur unzureichende Berücksichtigung. Ursächlich dafür sind die geforderten quantitativen Nachweise der Verfügbarkeit von Sicherheitsfunktionen, die zwar in den quantitativen Methoden der Zuverlässigkeitsbewertung etabliert, aber in der Bewertung menschengemachter Angriffe auf IT-Infrastrukturen schwer, wenn nicht unmöglich darstellbar sind. Die Metriken der Bewertung von Safety und IT-Security sind hier nicht kompatibel. Diese Situation stellt uns gegenwärtig vor große Herausforderungen.

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

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.

=== Security Impact on Availability ===

Kritische Infrastrukturen sind das Rückgrat moderner Gesellschaften. Die permanente Verfügbarkeit von Energie-, Wasser-, Kommunikations- und Verkehrsinfrastrukturen ist selbstverständliche Grundlage unserer gesellschaftlichen und wirtschaftlichen Existenz. Von Angriffen auf diese Infrastrukturen, seien sie terroristisch, kriminell, politisch oder anderweitig motiviert, können sehr viele Menschen zur gleichen Zeit betroffen sein. Derartige Angriffe, sowohl auf die IT- als auch auf die physischen Komponenten der Infrastrukturen bedrohen somit die Sicherheit unserer Gesellschaft. Sicherungsmaßnahmen gegen diese Angriffe müssen vergleichbare Sicherheitsniveaus erreichen, wenn Schwachstellen vermieden werden sollen. Wechselwirkungen zwischen diesen Maßnahmen müssen ggf. berücksichtigt werden, z.B. die physische Sicherheit von SCADA-Systemen oder Serverräumen. Auch dies erfordert den Abgleich der Maßnahmen auf der Basis bewertender Metriken.

=== Cyberphysische Systeme ===

Die Verbindung zwischen Systemkomponenten in der physischen Welt und der IT-basierten Vernetzung ist bei Cyberphysischen Systemen, z.B. Drohnenschwärme besonders ausgeprägt oder mit besonders hohen Auswirkungen und Risiken verbunden, wenn man so will. Im Zeitalter des Internet of Things (IOT) ist von einer Ausweitung der cyberphysischen Sphäre auf die meisten gebräuchlichen Technologien auszugehen. Alle oben genannten Wechselwirkungen zwischen den Domänen Safety und Security treffen dabei – je nach Anwendung – auch auf Cyberphysische Systeme zu. Dies gilt ebenso für die damit verbundenen Herausforderungen bei der abgestimmten risikogerechten Auslegung der Systeme in beiden Domänen.

==== 1.2 Ziele für den Fachausschuss: ====

Übergeordnetes Ziel des zu gründenden [[https://www.vdi.de/tg-fachgesellschaften/vdi-gesellschaft-produkt-und-prozessgestaltung/sicherheit-und-zuverlaessigkeit|Fachausschusses]] Synthese von Safety und Security ist die Erarbeitung und Fortführung des in dieser Form vorliegenden Statusberichtes zu den Herausforderungen, sowie zum Stand der Anwendung und Entwicklung von Methoden zur übergreifenden Betrachtung von Safety und Security. Im Zuge der Erarbeitung des Berichts reifte die Überzeugung, aufgrund der schnellen Entwicklungen in diesem Themengebiet und der Interdisziplinarität und Breite des Anwendungsbereichs, die Ergebnisse in Form eines Wikis zusammenzutragen. In dieser Form richtet sich der Bericht an Ingenieure und Technikanwender, die im Umfeld zunehmender Wechselwirkungen von Safety- und Security Maßnahmen aktiv sind, aber auch an Interessierte an diesem Themenkomplex aus anderen Bereichen.

Das Wiki liefert eine Übersicht gängiger Bewertungspraktiken in unterschiedlichen technischen Disziplinen und ordnet diese anhand zu definierender Kategorien in Bezug auf die Risikobewertung ein. Dabei kann der Bericht dem Anspruch an eine Richtlinie zum gegebenen Zeitpunkt noch nicht gerecht werden. Vielmehr weist der Bericht auf Herausforderungen und bestehende Ingenieurpraxis in der Bewertung und Risikoanalyse hin und zeigt wissenschaftlich-methodische Entwicklungen auf, wobei nicht zuletzt auch ethische Gesichtspunkte adressiert werden.

Erstes Teilziel für den Fachausschuss war die Entwicklung eines gemeinsamen risikobasierten Modells, das ganzheitlich die verschiedenen Fachgebiete aus den Domänen Safety und Security zusammenführen kann. Das Modell und die gleichzeitig darzustellende Methodik zur Synthese sollen es dem Anwender ermöglichen, Zielkonflikte und widersprüchliche Anforderungen an Safety und Security von Produkten und Infrastrukturen zu formulieren.

===== 2 Lösungsansätze =====

Um eine ganzheitliche Betrachtung zu erreichen, sollen verschiedene Risikobeiträge in den Domänen Safety und Security einheitlich, z.B. auf der Basis einer quantifizierenden Metrik, betrachtet werden. Hierzu können im Bereich der Safety z.B. die funktionale Sicherheit, technische Sicherheit, Zuverlässigkeitstheorie und Verlässlichkeit aber auch weitere Bereiche wie Brandschutz und Arbeitssicherheit gehören. Für den Bereich der Security soll die Betrachtung die Bereiche der physischen und informationstechnischen Sicherheit von Infrastrukturen, Anlagen und Produkten umfassen. Wie sich schon bald abzeichnet, wird eine quantitative Abbildung der IT-Sicherheit im Sinne der Wirksamkeit von Maßnahmen zur Abwehr von Angriffen, also zur Verminderung der Vulnerabilität, in der Regel nicht möglich sein. Andererseits existieren semi-quantitative Bewertungsansätze z.B. im Bereich Luftfahrt, die in bewährter Weise Risikobeiträge in den Aspekten Safety und Security bewerten. In der physischen Sicherheit sind allerdings quantitative Ansätze in der Bewertung der Vulnerabilität von Sicherungssystemen durchaus bekannt.

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

Über die Abgrenzung von Safety und Security lässt sich vortrefflich streiten. Da wir uns vorgenommen haben, Safety und Security in einer Bewertung zusammenzuführen, ist eine scharfe Abgrenzung eigentlich nicht erforderlich. Dennoch kann für das Verständnis der Herausforderungen und der Lösungsansätze eine Betrachtung der beiden Sicherheitsdomänen aus der Perspektive der Risikobewertung aufschlussreich sein. In beiden Domänen, Safety und Security, sollen relevante Szenarien risikobasiert bewertet werden, wir werden also bei Teilereignissen auch von Safety- bzw. Security-Risiken sprechen.

==== Safety ====

Safety-Risiken im Sinne dieser Dokumentation sind insbesondere Risiken die von der Technik ausgehen und Mensch, Technik oder Infrastruktur betreffen. Damit sind ursächlich für Safety-Risiken meist versagende technische Komponenten. Auch unabsichtliches menschliches Fehlverhalten kann ursächlich für Safety-Risiken sein, z.B. im Bereich Arbeits- oder Brandschutz. Die Besonderheit für die Risikobewertung besteht darin, dass das auslösende Ereignis eines Safety Vorfalls oft auf der Basis von Evidenz und Erfahrungswerten probabilistisch beschrieben werden kann, was die Häufigkeit des Eintretens betrifft. Dies ist bei den Security-Risiken i.d.R. nicht möglich.

==== Security ====

Security-Risiken im Sinne dieser Dokumentation gehen auf von Menschen gewollt verursachte Ereignisse zurück, die Technik und Infrastruktur und damit mittelbar auch den Menschen bedrohen. Die Häufigkeit, mit der diese Ereignisse eintreten ist aufgrund der menschlichen Willensbildung i.d.R. nicht probabilistisch zu erfassen. In Ermangelung von Evidenz kann man i.d.R. nur mit sehr großen Unsicherheiten behaftete Angaben zur Bedrohungswahrscheinlichkeit machen. Aus diesem Grund beschränkt sich die Analyse der Eintrittswahrscheinlichkeit bei Security-Risiken oft auf die Vulnerabilität. Dies gilt sowohl für die IT- als auch für die physische Sicherheit.

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

Die Zusammenführung aller Risiken in einer Bewertung über die Domänen Safety und Security ist eine Zielstellung des FA512. Bei einer dreiteiligen Risikobewertung, wie sie hier vorgeschlagen wird, muss sich die Zusammenführung in der Regel über diese drei Risikobereiche erstrecken. Die Formulierung eines Gesamtrisikos über alle Beiträge aus Safety und Security erlaubt z.B. eine Abwägung widersprüchlicher Anforderungen oder eine Optimierung im Sinne einer Cost-Benefit-Analyse insbesondere dann, wenn die entsprechenden Metriken für die Bewertung der Risikobeiträge in den Domänen Safety und Security kompatibel sind und eine quantitative Bemessung erlauben. Wo Risikobeiträge quantitativ bewertet werden, kann rechnerisch optimiert werden, sofern die Unsicherheiten, die unbedingt mitbetrachtet werden müssen, nicht zu groß sind. Wenn widersprüchliche Anforderungen vorliegen, bzw. erhebliche Wechselwirkungen zwischen Safety- und Security-Maßnahmen gegeben sind, müssen die jeweiligen Metriken die Wirkung der Maßnahmen in der jeweils anderen Domäne abbilden können, also kompatibel sein, damit Entscheidungen in Abwägung oder Optimierung getroffen werden können. Auch hier gilt, dass Unsicherheiten nicht zu groß werden dürfen, wenn tragfähige Entscheidungen getroffen werden sollen.

===== ************** Überarbeitung bis hier ************** =====

===== 4 IT-Security / Informationssicherheit =====

==== 4.1 Einleitung ====

==== 4.2 Begriffe ====

===== 5 Risikobegriff im Kontext von Funktionaler Sicherheit =====

Autor: David Schepers

Risiko bezogen auf eine Gefährdung wird in der Disziplin der Funktionalen Sicherheit in Abhängigkeit von Schadensausmaß und Eintrittswahrscheinlichkeit bewertet. Übergeordnetes Ziel ist es, unzulässig hohe Risiken auf ein tolerierbares Maß zu mindern. Welches Maß an Risiko noch als tolerierbar angesehen wird, hängt vom Grad der Akzeptanz in der jeweiligen Gesellschaft ab.

\\
Im Bereich Maschinen und Anlagen zum Beispiel werden zunächst mögliche Gefährdungen identifiziert. Der Begriff „Gefährdung“ bezieht sich hierbei auf jede potentielle Schadensquelle, welche von einer Maschine oder Anlage für Mensch und Umwelt ausgeht. Anschließend werden die Gefährdungen hinsichtlich ihres realen Risikos bewertet. Risiko wird wie eingangs erwähnt als eine „Kombination aus der Wahrscheinlichkeit, mit der ein Schaden auftritt, und dem Ausmaß dieses Schadens“ definiert (vgl. IEC 61508-1). Die Eintrittswahrscheinlichkeit hängt dabei von der Gefährdungsexposition, der Wahrscheinlichkeit, dass die Gefährdungssituation überhaupt eintritt sowie der Möglichkeit zur Vermeidung oder Begrenzung des Schadens ab (siehe Abbildung 1).

{{  :625d820ab4b41220ac816b4663206734.png  }}

Abbildung 1: Risiko als Funktion von Schadensausmaß und Eintrittswahrscheinlichkeit (Quelle: EN ISO 12100)

Falls an technischen Einrichtungen unzulässig hohe Risiken bestehen, müssen diese durch geeignete Maßnahmen gemindert werden. Risikominderung kann durch konstruktive Maßnahmen, durch den Einsatz von technischen Schutzeinrichtungen oder durch organisatorische Maßnahmen (Definition von Prozessen, Warnhinweise usw.) erfolgen.

Die Disziplin der Funktionalen Sicherheit bezieht sich immer auf den Einsatz von steuerungstechnischen Maßnahmen (Sicherheitsfunktionen) zur Risikominderung. Funktionale Sicherheit bezeichnet also den Teil der Gesamtsicherheit, welcher von der korrekten Funktion der sicherheitsbezogenen Teile der eingesetzten Steuerungssysteme abhängt.

Sicherheitsfunktionen zählen bezüglich der Maßnahmen zur Risikominderung zu den technischen Schutzeinrichtungen und bestehen in der Regel aus einer Sensorik zur Erfassung eines (Gefährdungs-) Ereignisses, einer Logik zur Auswertung des Ereignisses und einer Aktorik zur Ausführung einer (Gegen-)Maßnahme. Da bei Ausfall der betrachteten Sicherheitsfunktion das abzusichernde Risiko nicht mehr wie gewünscht gemindert wird, ist es das erklärte Ziel der Funktionalen Sicherheit, die (gefahrbringende) Ausfallwahrscheinlichkeit der Sicherheitsfunktion je nach abzusicherndem Risiko unter einem definierten Grenzwert zu halten. Die gefahrbringende Ausfallwahrscheinlichkeit bezieht sich in diesem Zusammenhang auf die Ausfälle, welche zur Folge haben, dass die Sicherheitsfunktion das abzusichernde Risiko nicht mehr mindern kann. 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. Hohe Anforderungsrate bedeutet in diesem Zusammenhang, dass die Sicherheitsfunktion kontinuierlich oder häufig (mindestens einmal pro Jahr) angefordert wird und niedrige Anforderungsrate bedeutet, dass die Sicherheitsfunktion selten (weniger als einmal pro Jahr) angefordert wird.

Zur Realisierung von Sicherheitsfunktionen ist neben der Auswahl von Hardware-Komponenten (Sensor, Logik, Aktor) in vielen Fällen auch eine Implementierung einer entsprechenden Software notwendig. Software und Hardware-Komponenten können systematische Fehler enthalten und Hardware-Komponenten können außerdem zufällig ausfallen (Abbildung 2). Diese Fehler oder Ausfälle können jeweils zu einem Versagen der Sicherheitsfunktion führen.

{{  :f5d25d89d310cbf44f09bc4374e3520e.png  }}

Abbildung 2: Systematische Fehler und zufällige Ausfälle

Die im Kontext der Funktionalen Sicherheit definierten Maßnahmen zielen im Wesentlichen darauf ab, (gefahrbringende) systematische Fehler zu vermeiden oder – wenn möglich – zu beherrschen und (gefahrbringende) zufällige Ausfälle zu beherrschen (zufällige Bauteilausfälle können nicht vermieden werden). Die Grundnorm IEC 61508 „Funktionale Sicherheit sicherheitsbezogener elektrischer/elektronischer/programmierbarer elektronischer Systeme“ (Teile 1 bis 7) definiert Anforderungen zur Vermeidung oder Beherrschung systematischer Fehler in Hardware und Software sowie zur Beherrschung zufälliger Hardware-Ausfälle.

\\
Bei der Auslegung der Software und Hardware nach IEC 61508 werden hierzu insbesondere die fünf folgenden Maßnahmen angewendet:

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

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.
  - 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.).
  - Qualitätsmanagement: Zur Vermeidung systematischer Fehler fordert die Norm IEC 61508 ein umfangreiches Qualitätsmanagement bei der Entwicklung sicherheitsrelevanter Hardware und Software. Da insbesondere die Software nur systematische Fehler enthalten (und nicht zufällig ausfallen) kann, kommt dem Software-Qualitätsmanagement eine besondere Bedeutung zu. Die Norm fordert hierzu unter anderem die Anwendung des so genannten V-Modells (Abbildung 3).

{{  :3de6b729cf900d959884fed5c90ea291.png  }}

Abbildung 3: V-Modell für den Software-Entwicklungsprozess nach IEC 61508

Als Maß für die Zuverlässigkeit einer Sicherheitsfunktion definiert die Norm IEC 61508 den SIL (Safety Integrity Level – Stufe der Sicherheitsintegrität). In der Norm werden insgesamt vier SIL definiert, wobei SIL 1 die niedrigste und SIL 4 die höchste Stufe der Sicherheitsintegrität darstellen.

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:

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.

Für die Realisierung der Sicherheitsfunktion wird die nachfolgende Hardware-Struktur gewählt:

{{  :d6c8b6c6dac113927daef37b1c1b3fcb.png  }}Die Funktion besteht aus zwei Kanälen, welche jeweils aus den folgenden Komponenten besteht:

  * Temperatursensor zur Erfassung der Temperatur
  * Logikeinheit zur Auswertung der Temperatur und zur Ansteuerung des Aktors (Schütz)
  * Schütz zur Trennung der elektrischen Energieversorgung des Heizelements (Hinweis: Das Heizelement selbst ist nicht Teil der Sicherheitsfunktion)

Die gewählte Sicherheitsfunktion weist die folgenden Eigenschaften auf:

  * Es handelt sich um eine redundante Struktur (HFT = 1). Jeder Kanal kann für sich die Sicherheitsfunktion ausführen (Abschalten der Energieversorgung des Heizelements bei Überschreiten einer definierten Temperaturschwelle). Der Ausfall eines Kanals kann durch die redundante Struktur beherrscht werden.
  * Für alle Teilsysteme (Sensor, Logik, Aktor) ist eine Fehlererkennung möglich: Für die Sensoren können die Temperaturwerte in der Logik miteinander verglichen werden. Tritt z. B. eine Diskrepanz zwischen den Werten auf, deutet dies auf einen möglichen Fehler in einem der Sensoren hin. Sicherheitshalber kann dann die Sicherheitsfunktion ausgelöst werden und damit ein sicherer Zustand eingenommen werden, bis der Fehler behoben wurde. Die Logikeinheiten können sich z. B. mittels einer zeitlichen und logischen Programmlaufüberwachung und mittels geeigneter Selbsttests überprüfen. Für die Aktorik können Schütze mit Spiegelkontakten verwendet werden, welche durch die Logik überwacht werden müssen. Es ist zu beachten, dass ein möglicher Fehler in einem Schütz erst bei einem Zustandswechsel erkannt werden kann, da nur dann ersichtlich wird, ob das Schütz noch wie vorgesehen abschalten kann. Falls im Betrieb praktisch nie ein Zustandswechsel (Abschalten) vorgesehen ist, weil der Reaktor im Dauerbetrieb läuft, kann keine Fehlererkennung erfolgen, so dass ggf. ein manuelles Überprüfen der Aktorik im Rahmen von Wartungsarbeiten notwendig ist.
  * Der SFF für alle Teilsysteme kann z. B. mit Hilfe der Norm IEC 61508 abgeschätzt oder mit Hilfe einer FMEA/FMEDA (Failure Method and Effects (and Diagnostic) Analysis) bestimmt werden.
  * Bezüglich der Fehlererkennung sei darauf hingewiesen, dass diese dazu dient, eine Anhäufung von versteckten gefahrbringenden Fehlern in der Sicherheitsfunktion zu vermeiden. Einzelfehler in einem Kanal können im vorliegenden Beispiel durch den redundanten Kanal beherrscht werden. Falls sich der Einzelfehler im Betrieb jedoch nicht bemerkbar macht, kann nach einiger Zeit ein weiterer gefahrbringender Fehler im zweiten Kanal hinzukommen, wodurch die Sicherheitsfunktion nicht mehr ausgeführt werden könnte. Daher ist es sinnvoll, die redundante Auslegung mit Maßnahmen zur automatischen Fehlererkennung zu kombinieren.
  * Die Ausfallraten der verwendeten Bauteile sowie die angewendeten Maßnahmen gegen Fehler gemeinsamer Ursache werden bei der Berechnung der Ausfallwahrscheinlichkeit der Sicherheitsfunktion (PFH/PFD) berücksichtigt.
  * Begleitet wird die Auslegung und Umsetzung der Sicherheitsfunktion von geeigneten fehlervermeidenden Maßnahmen, d. h. jeder Entwicklungsschritt wird sehr sorgfältig geplant und überprüft/ausgetestet.

Abschließend sei noch erwähnt, dass es neben der Grundnorm zur Funktionale Sicherheit IEC 61508 noch eine Vielzahl an Sektornormen existieren, welche für den jeweiligen Anwendungsbereich angepasst wurden, um der Anwenderin oder dem Anwender das Verständnis und die Umsetzung der erforderlichen Maßnahmen zu erleichtern.

Weitere Informationen zum Thema finden sich z. B. in den nachfolgenden Quellen.

  * IEC 61508, Teile 1 - 7: Funktionale Sicherheit sicherheitsbezogener elektrischer/elektronischer/programmierbarer elektronischer Systeme
  * VDI-EE 4020: Einführung in die Funktionale Sicherheit
  * VDI/VDE 2180: Funktionale Sicherheit in der Prozessindustrie

===== 6 Risiko- und Sicherheitsmetriken =====

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

==== 6.1 Definition Risikobegriff ====

In einem ersten Schritt wird die Entwicklung einer einheitlichen abstrakten Definition des Risikobegriffs angestrebt, die eine ganzheitliche Beschreibung der Domänen Safety und Security ermöglicht. Hierzu sollen vorhandene Ansätze zur risikobasierten Modellierung sowohl von Safety als auch Security kritisch analysiert und eingeordnet werden. Durch die inhaltliche Zusammenführung der Ansätze soll sich eine Definition des Risikobegriffs ergeben, der es ermöglicht, die spezifischen Eigenschaften von Safety und Security und ihrer Aspekte abzubilden. Hierzu notwendige Parameter zur Analyse des Risikos, die einer quantitativen Betrachtung zugänglich sind, sollen eingeführt werden.

Denkbar ist beispielsweise die Verwendung eines mehrgliedrigen Risikobegriffs. Im Bereich Safety werden meist die zwei Parameter //Eintrittswahrscheinlichkeit//  und //Auswirkung//  betrachtet, wobei abweichend zum Beispiel in IEC 61508 vier Parameter zur Betrachtung des Risikos herangezogen werden. Im Gegensatz hierzu wird im Bereich Security zumeist ein dreigliedriges Risikomodell betrachtet, das neben der Auswirkung als Risikofaktor die Eintrittswahrscheinlichkeit in //Bedrohung//  und //Verwundbarkeit//  aufteilt.

Abbildung 1: Beispielhafter Risikoansatz für Safety und Security

Abbildung 1 zeigt beispielhaft einen möglichen Ansatz einer dreigliedrigen Definition des Risikobegriffs für Safety und Security. Im Anhang finden sich weitere wichtige risikobasierte Ansätze zur Sicherheitsbewertung.

==== 6.2 Entwicklung Risikomodell ====

In einem zweiten Schritt sollte ein mathematisches Modell entwickelt werden, das die aus dem Risikobegriff resultierenden Parameter quantitativ definiert und verknüpft. Das so entstehende Modell sollte allgemein genug sein, um eine Risikoanalyse unterschiedlicher Betrachtungsobjekte, beispielsweise Infrastrukturen oder Produkte, zu erlauben. Hierbei kann das zu entwickelnde quantitative Modell, wie im Bereich Safety weit verbreitet, auf probabilistischen Annahmen basieren. Auch Risikomodelle der Security basieren zum Teil auf diesen Annahmen. Ausgehend hiervon würde eine Beschreibung der Modellparameter auf Basis probabilistischer Verteilungen angestrebt, was aber im Bereich der Security der weiteren Entwicklung vorhandener Modelle bedarf.

Das entstehende probabilistische Modell wird die Risikoanteile von sowohl Safety als auch Security beinhalten und miteinander verknüpfen. Dies wird es ermöglichen, das resultierende Gesamtrisiko zu bewerten und ggf. sogar Maßnahmen im Sinne einer Zielkonfliktminimierung abwägen zu können.

==== 6.3 Betrachtung von Unsicherheiten ====

Eine Risikoanalyse auf Basis eines probabilistischen Modells erlaubt die Abbildung von Unsicherheiten in der Berechnung und Bewertung des Risikos, die sich in den Parametern der Verteilungen widerspiegeln. Diese Unsicherheiten ergeben sich beispielsweise aus unzureichender Evidenz für die Wirksamkeit von Maßnahmen, der unklaren Eintrittswahrscheinlichkeit von Bedrohungen oder nicht exakt definierbaren Auswirkungen oder Wechselwirkungen zwischen den einzelnen Domänen, sowie Unzulänglichkeiten des Modells. In einem dritten Schritt soll deshalb untersucht werden, wie diese Unsicherheiten analysiert und beschrieben werden können, so dass sie methodisch zur Unterstützung der Entscheidungsfindung bezüglich bestimmter untersuchter Konfigurationen dienen können. Hierbei soll insbesondere geprüft werden, wie die Sinnhaftigkeit einer ausgewählten Konfiguration von Safety- und Security-Maßnahmen unter Berücksichtigung vorhandener wechselseitiger Beeinflussungen und Unsicherheiten analysiert werden kann. Eine der möglichen Methoden, die zum Einsatz kommen könnte, wäre die (varianzbasierte) Sensitivitätsanalyse. Weitere Methoden zur Analyse von Unsicherheiten können hilfreich sein.

===== 7 Ethische und rechtliche Aspekte =====

===== 8 Leitfragen-Erläuterungen =====

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

  * Wie wird das Risiko, werden Safety und Security in der Disziplin beschrieben: Begriffe, Modelle und Verfahren?

  * Welche Probleme und Dilemmata sind in Ihrer Disziplin charakteristisch?

  * Wie werden unscharfe oder unsichere Risikobeiträge behandelt?

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

  * Wie werden Risikoanalysen in Ihrer Disziplin durchgeführt (qualitativ, quantitativ, semi-quantitativ, nach Norm oder Richtlinie)?

  * Welche Metriken kommen hierbei zum Einsatz?

  * Wie treten Wechselwirkungen der Domänen Safety und Security in der Risikoanalyse in Ihrer Disziplin in Erscheinung und wie werden diese behandelt?

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

  * Werden in den angrenzenden Disziplinen ähnliche oder andere Probleme bearbeitet?

  * Was sind methodische Unterschiede und Gemeinsamkeiten in verschiedenen Domänen?

  * Wie könnte ein gemeinsamer Nenner für die Quantifizierung von Risiken in Safety- und Security Modellen aussehen?

  * Welches neue Wissen ist erforderlich für eine Synthese der Domänen?

===== 9 Anhang: Beispiele für risikobasierte Modelle (zu ergänzen) =====

==== 9.1 Safety ====

DIN EN ISO 13849: Sicherheit von Maschinen - Sicherheitsbezogene Teile von Steuerungen, 2017.

DIN EN 61882 VDE 0050-8: HAZOP-Verfahren (HAZOP-Studien), 2017

IAEA Safety Reports Series No. 25: Review of Probabilistic Safety Assessments by Regulatory Bodies, 2002.

IAEA Safety Reports Series No. 52: Best Estimate Safety Analysis for Nuclear Power Plants: Uncertainty Evaluation, 2008.

IAEA Safety Standards Series No. GSR Part 4 (Rev. 1): Safety Assessment for Facilities and Activities, 2016.

IAEA Safety Standards Specific Safety Guide No. SSG-3: Development and Application of Level 1 Probabilistic Safety Assessment for Nuclear Power Plants, 2010.

IAEA Safety Standards Specific Safety Guide No. SSG-4: Development and Application of Level 2 Probabilistic Safety Assessment for Nuclear Power Plants, 2010.

IEC 61508: Funktionale Sicherheit sicherheitsbezogener elektrischer/elektronischer/programmierbarer elektronischer Systeme, 2011.

IEC 61511: Functional safety - Safety instrumented systems for the process industry sector, 2016.

ISO 26262: Road vehicles – Functional safety, 2018.

NE 144: Risikobasierte Instandhaltung von Brandmeldeanlagen, 2012.

==== 9.2 Security ====

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

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

[[:content:arbeitsschutz|Arbeitsschutz]]

[[:content:automotive|Automobile Sicherheit]]

[[:content:railway|Railway]]

[[:content:industrie|Industrie und Produktionsanlagen]]

[[:content:kernenergie|Kernenergieanlagen]]

[[:content:luftfahrt|Luftfahrt]]

[[:content:maritime_sicherheit|Maritime Sicherheit]]

[[:content:oeffentliche_sicherheit|Öffentliche Sicherheit]]

[[:content:physische_sicherheit|Physische Sicherheit]]

[[:content:kritis|Kritische Infrastrukturen (KRITIS)]]

[[:content:beherrschung_von_unsicherheit|Beherrschung von Unsicherheit]]