content:startseite [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.
====== Startseite ======


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

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

** <font 24px/inherit;;inherit;;#f1c40f>Rohversion aus KI</font>  **

Die Notwendigkeit, Safety und Security gemeinsam zu betrachten, stellt neue Anforderungen an Methodik und Praxis der Risikobewertung. Die Zielsetzung ist eine domänenübergreifende Betrachtung von Risiken auf einer gemeinsamen, möglichst quantifizierbaren Bewertungsbasis – unter Berücksichtigung disziplinspezifischer Herausforderungen, Zielkonflikte und Unsicherheiten.

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

Die zunehmende IT-Vernetzung sicherheitskritischer Komponenten – insbesondere in Automatisierung und Automotive – führt dazu, dass zeitkritische Sicherheitsfunktionen zunehmend von IT-Systemen abhängen. Angriffe auf Kommunikationsnetze, Manipulationen von Steuergeräten oder Störungen der Datenverfügbarkeit können direkte Auswirkungen auf Safety-Funktionen haben. In der funktionalen Sicherheit nach IEC 61508 oder ISO 26262 ist die Risikobewertung auf probabilistische Kenngrößen wie Ausfallwahrscheinlichkeit und Diagnosebedeckungsgrad fokussiert. Die Einbindung von Security-Aspekten erfordert jedoch eine Erweiterung der Methodik. Erste Ansätze zur Übertragung der SIL-Logik auf Security-Maßnahmen – etwa in Form definierter „Security Level“ – sind in Automotive (ISO/ SAE 21434) oder Industrie ( IEC 62443) zu finden, stoßen aber auf methodische Grenzen: Angreiferverhalten ist nicht zufällig, und Eintrittswahrscheinlichkeiten sind nur qualitativ einschätzbar. Die Metriken beider Domänen sind derzeit inkompatibel.

==== 2.2 Widersprüche zwischen Safety und Security ====

In zahlreichen Disziplinen treten Zielkonflikte zwischen Safety- und Security-Anforderungen auf. In der physischen Sicherheit kann z. B. der Schutz vor unbefugtem Zutritt den sicheren und schnellen Notausgang behindern. In der Nukleartechnik führt die Notwendigkeit hoher Sicherheitsmaßnahmen gegen Sabotage zu Zielkonflikten mit betrieblichen Anforderungen an Reaktionszeiten und Redundanzpfade . Solche Widersprüche sind nicht auflösbar, sondern müssen abgewogen werden. Dies erfordert Verfahren, die Zielgewichtungen, Prioritäten und Konsequenzen auf einer vergleichbaren Skala bewerten können. Bestehende qualitative Risikoanalysen sind hier nur eingeschränkt hilfreich. Eine übergreifende Bewertung muss auch epistemische Unsicherheiten einbeziehen, da unter großer Unsicherheit keine verlässliche Abwägung möglich ist.

==== 2.3 Security Impact on Availability ====

Insbesondere im Bereich kritischer Infrastrukturen ( KRITIS ) ist die Verfügbarkeit das zentrale Schutzziel – etwa in Energieversorgung, Wasserwirtschaft oder Telekommunikation. IT-Sicherheitsmaßnahmen (z. B. Segmentierung, Firewalls, Verschlüsselung) können jedoch die Verfügbarkeit durch Verzögerungen, Fehlkonfigurationen oder Sperrmechanismen beeinträchtigen. Ein belastbarer Lösungsansatz besteht in der gegenseitigen Berücksichtigung von IT- und physischer Sicherheit, etwa durch abgestimmte Sicherheitskonzepte für SCADA-Systeme , Leitstände oder Netzknoten. Die Vorgaben des BSI-Gesetzes und der KRITIS-Verordnung fordern die Einhaltung des „Standes der Technik“, ohne diesen konkret zu quantifizieren. Die Entwicklung semi-quantitativer Metriken, die sowohl Verfügbarkeitseinbußen als auch Angriffsrisiken modellieren, ist daher ein zentrales Forschungsziel.

==== 2.4 Cyberphysische Systeme ====

Bei cyberphysischen Systemen – wie autonomen Fahrzeugen, Industrie-4.0-Fertigungslinien oder Drohnensystemen – ist die Verknüpfung von physischer Funktionalität und IT-Kommunikation besonders eng. Die Wechselwirkungen zwischen Safety und Security sind hier maximal ausgeprägt: Eine IT-Störung kann unmittelbar zu einem sicherheitsrelevanten Ausfall führen – und umgekehrt können Sicherheitsmaßnahmen physische Prozesse blockieren. Im Bereich Luftfahrt wird dieser Zusammenhang adressiert, etwa durch integrierte Sicherheitskonzepte, jedoch ist die methodische Tiefe bislang unzureichend. Zukünftig bedarf es domänenübergreifender Methoden zur integrierten Risikoanalyse, die sowohl funktionale Sicherheitsmodelle als auch IT-Angriffsmodelle kombinieren, beispielsweise durch die Kopplung von FMEA/Fault Tree mit Bedrohungsszenarien oder Bayesschen Netzen .

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

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

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

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

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

Im Kontext technischer Systeme und der Informationsverarbeitung gewinnt die differenzierte Betrachtung von Safety und Security zunehmend an Bedeutung. Trotz ihrer unterschiedlichen Ausrichtung – Safety fokussiert auf den Schutz vor unbeabsichtigten Ereignissen, während Security den Schutz vor vorsätzlichen Angriffen adressiert – erfordert die Digitalisierung und Vernetzung technischer Systeme eine integrative Sichtweise.

==== 4.1 Motivation ====

Die fortschreitende Digitalisierung der Industrie und die zunehmende Komplexität technischer Infrastrukturen machen die Integration von Safety und Security zu einer wissenschaftlichen und technischen Notwendigkeit. Traditionell getrennt behandelte Bereiche erweisen sich in der Praxis als zunehmend abhängig, bedingt durch die gemeinsame digitale Basis moderner Systeme.

==== 4.2 Einordnung von Safety und Security ====

=== Technische Betriebssicherheit (Safety) ===

Safety bezieht sich auf den Schutz vor unbeabsichtigten Bedrohungen, die zu Schädigungen oder Unfällen führen können. Das Ziel von Safety-Maßnahmen ist die Minimierung von Risiken durch technisches Versagen oder menschliche Fehler, um physische Schäden oder Gefährdungen zu verhindern. Vergleiche Kapitel SAFETY

=== IT-Sicherheit (Security ) ===

Im Gegensatz zu Safety konzentriert sich Security auf die Abwehr von beabsichtigten, bösartigen Bedrohungen gegen die Vertraulichkeit, Integrität und Verfügbarkeit von Systemen und Daten. Security umfasst die Gesamtheit der Maßnahmen zum Schutz vor Angriffen, Diebstahl, Sabotage oder unberechtigtem Zugriff.

=== Zuverlässigkeit durch Safety und Security ===

Die Zuverlässigkeit technischer Systeme hängt maßgeblich von den Aspekten Safety und Security ab. Die Herausforderung liegt in der integrierten Berücksichtigung beider Aspekte, um Systemausfälle zu verhindern und die Zuverlässigkeit zu erhöhen. Eine effektive Umsetzung von Safety- und Security-Maßnahmen steigert somit die Gesamtzuverlässigkeit eines Systems. Die Abhängigkeiten zwischen physischen und informationstechnischen Systemen erfordern eine gemeinsame Betrachtung, um Schwachstellen effektiv zu adressieren und zu beheben. Beispielsweise kann eine Sicherheitslücke in der IT-Infrastruktur nicht nur Datenrisiken, sondern auch physische Sicherheitsrisiken nach sich ziehen.

=== Konflikte zwischen Safety und Security ===

**Ressourcenallokation**: Die Ressourcen (Zeit, Geld, Personal) können begrenzt sein, und die Priorisierung der einen kann zu Lasten der anderen gehen. Zum Beispiel könnte ein übermäßiger Fokus auf Security-Maßnahmen Ressourcen von wichtigen Safety-Maßnahmen abziehen und umgekehrt.

**Design- und Implementierungskonflikte**: Einige Sicherheitsmaßnahmen könnten im Widerspruch zu Sicherheitsanforderungen stehen. Ein Beispiel hierfür ist die Zutrittskontrolle: Während aus Sicherheitsgründen ein restriktiver Zutritt wünschenswert ist, könnte dies im Notfall die Rettungsdienste behindern und somit die Sicherheit gefährden.

**Datenzugriff und Privatsphäre**: Security-Maßnahmen, die eine Überwachung und das Sammeln von Daten erfordern, können in Konflikt mit dem Datenschutz und der Privatsphäre der Nutzer stehen, was wiederum safety-relevante Aspekte beeinflussen kann, insbesondere in Bereichen, die eine anonyme Datenerhebung erfordern.

**Regulatorische und normative Herausforderungen**: Unterschiedliche und manchmal widersprüchliche Vorschriften und Normen für Safety und Security können zu Herausforderungen in der praktischen Umsetzung führen. Organisationen müssen häufig einen Kompromiss finden, der nicht immer optimal für beide Aspekte ist.
==== 4.3 Grundlagen der Security ====

=== Schutzziele ===

Im Kontext der Informationstechnologie (IT) ist die Gewährleistung von Sicherheit essenziell für die Aufrechterhaltung der Funktionsfähigkeit und Vertrauenswürdigkeit digitaler Systeme. Die industrielle Anwendung fokussiert dabei auf vier fundamentale Schutzziele: Vertraulichkeit, Authentizität, Integrität und Verfügbarkeit. Diese Ziele bilden das Gerüst für ein umfassendes Verständnis und die Implementierung effektiver IT-Sicherheitsmaßnahmen. Vertraulichkeit bezieht sich auf den Schutz sensibler Informationen vor unbefugtem Zugriff. In der Literatur wird dieses Ziel oft durch die Anwendung kryptografischer Verfahren zur Verschlüsselung von Daten adressiert, deren Ziel es ist, die Lesbarkeit der Informationen ausschließlich autorisierten Entitäten vorzubehalten. Durch starke Verschlüsselungsstandards kann die Vertraulichkeit auch in unsicheren Netzwerken sichergestellt werden. Authentizität zielt darauf ab, die Echtheit eines Kommunikationspartners oder einer Information oder einer Software zu bestätigen. Die Authentizitätsprüfung wird in der Praxis durch Methoden wie digitale Signaturen und Authentifizierungsprotokolle realisiert. Diese Techniken ermöglichen die Überprüfung der Identität einer Quelle oder eines Nutzers und sind grundlegend, um die Authentizität von Systemen und Identitäten zu gewährleisten. Die Integrität sichert, dass Daten während ihrer Speicherung oder Übertragung nicht verändert, manipuliert oder auf andere Weise beschädigt werden. Durch den Einsatz von Hashfunktionen und Integritätsprüfmechanismen werden Modifikation an den Ursprungsdaten erkannt. Die Integrität ist entscheidend, um die Zuverlässigkeit und Korrektheit der Daten in IT-Systemen zu sichern. Das Schutzziel der Verfügbarkeit garantiert einen stetigen Zugriffs auf Systeme, Funktionen, Ressourcen und Informationen, insbesondere im Falle eines Angriffs oder Ausfalls. In der Praxis kommen hierbei häufig redundante Systeme, effiziente Netzwerkarchitekturen und robuste Recovery-Strategie zum Einsatz, um die kontinuierliche Funktionsfähigkeit von Funktionen und Diensten sicherzustellen. Aus praktischer Sicht besteht die Notwendigkeit eines ganzheitlichen Sicherheitsansatzes, der die unterschiedlichen Aspekte der IT-Sicherheit integriert behandelt. Die Abhängigkeiten der Schutzziele erfordert eine ausgewogene Berücksichtigung aller vier Aspekte, um ein effektives Sicherheitsniveau zu erreichen.

=== Technische Maßnahmen ===

//Anmerkung JP: Kryptografie, Key Management, Systemsicherheit, Softwaresicherheit, Hardwaresicherheit, Netzwerksicherheit, Security-by-Design, Secure Coding, (ggf. erweitern) //

   * **Kryptografie:**  Kryptografie bezeichnet die Lehre von der Verschlüsselung von Informationen. Ziel ist es, Daten so zu transformieren, dass sie nur von autorisierten Parteien entschlüsselt und gelesen werden können. Moderne Kryptografie nutzt mathematische Algorithmen für die Verschlüsselung und Sicherstellung der Integrität von Daten, um Vertraulichkeit, Authentizität und Nichtabstreitbarkeit in digitalen Kommunikationen zu gewährleisten.
  * **Key Management:**  Key Management umfasst die Verfahren und Technologien zum Erzeugen, Verteilen, Verwalten, Speichern, und zum finalen Löschen von Kryptografieschlüsseln. Ziel ist es, die Sicherheit der Schlüssel über ihren gesamten Lebenszyklus hinweg zu gewährleisten, da die Sicherheit der verschlüsselten Informationen direkt von der Sicherheit der Schlüssel abhängt.
  * **Systemsicherheit:**  Systemsicherheit betrachtet übergeordnet den Schutz von Computersystemen und deren Ressourcen vor Missbrauch, Ausfällen, oder unbefugtem Zugriff. Dies schließt physische Sicherheitsmaßnahmen, Betriebssystemsicherheit, Anwendungssoftware-Sicherheit und unterschiedliche Kontrollmechanismen zur Überwachung und Reaktion auf Sicherheitsvorfälle ein.
  * **Softwaresicherheit:**  Softwaresicherheit konzentriert sich auf die Entwicklung und Implementierung von Software, die frei von Schwachstellen ist und resistent gegenüber Cyberangriffen bleibt. Dies beinhaltet die Anwendung von Sicherheitspraktiken während des gesamten Softwareentwicklungslebenszyklus, um die Einführung und Ausnutzung von Schwachstellen zu verhindern.
  * **Cloud-Sicherheit:**  Spezifische Praktiken und Technologien zum Schutz von Daten, Anwendungen und Infrastrukturen, die in der Cloud gehostet werden. Dies beinhaltet Verschlüsselung, Zugriffskontrollen, Sicherheitsüberwachung und Compliance-Management.
  * **Hardwaresicherheit:**  Hardwaresicherheit beschäftigt sich mit dem Schutz von physischen Geräten vor Manipulationen, Diebstahl oder Beschädigung. Dazu gehören Maßnahmen wie physische Absicherung, anti-tampering Technologien und die Integration von Sicherheitsfeatures direkt auf der Hardware-Ebene, z.B. durch Secure-Boot-Mechanismen oder hardwarebasierte Verschlüsselungsunterstützung.
  * **Netzwerksicherheit:**  Netzwerksicherheit umfasst Maßnahmen und Technologien zum Schutz von Daten während deren Übertragung über Netzwerke. Ziele sind die Gewährleistung der Vertraulichkeit, Integrität und Verfügbarkeit von Daten. Maßnahmen beinhalten Firewalls, Intrusion Detection und Prevention Systeme, Verschlüsselung, sowie Zugriffskontrollen.
  * **Security-by-Design:**  Security-by-Design ist ein Ansatz in der Entwicklung von IT-Systemen, bei dem Sicherheitsüberlegungen von Anfang an ein integraler Bestandteil des Design- und Entwicklungsprozesses sind, im Gegensatz dazu, Sicherheitsfeatures nachträglich in ein bereits fertiges Produkt einzubauen. Dieser Ansatz strebt an, Sicherheitsrisiken proaktiv zu minimieren.
  * **Secure Coding:**  Secure Coding bedeutet, Sicherheitsprinzipien bei der Softwareentwicklung konsequent anzuwenden, um Schwachstellen zu vermeiden, die während der Implementierungsphase entstehen können. Es schließt die Anwendung von Best Practices, Richtlinien und Standards ein, die darauf abzielen, sichere Codepraktiken zu fördern und somit die Anfälligkeit für Angriffe zu reduzieren.
=== Organisatorische Maßnahmen ===

//Anmerkung JP: Need-to-Know-Prinzip, Least-Privilege Prinzip, Separation of Duties, Job Rotation, Security Management (vergl. ISMS, evtl. weiter aufdröseln), Incident Management, Patch Management, (ggf. erweitern) //
  * **Security Management (vergl. ISMS):**  Security Management umfasst die strategische Planung, Implementierung und Überwachung von Sicherheitsrichtlinien und -verfahren zur Gewährleistung der Integrität, Vertraulichkeit und Verfügbarkeit von Informationssystemen. Ein Informationssicherheitsmanagementsystem (ISMS) ist ein systematischer Ansatz zur Verwaltung sensibler Unternehmensinformationen, so dass sie sicher bleiben. Es beinhaltet Personen, Prozesse und IT-Systeme, indem es einen risikobasierten Ansatz verfolgt.
  * **Incident Management:**  Incident Management bezieht sich auf den Prozess und die organisatorischen Strukturen, die für das Management der Antwort auf IT-Sicherheitsvorfälle erforderlich sind. Ziel ist es, die Auswirkungen von Sicherheitsvorfällen zu minimieren, die normalen Geschäftsoperationen schnellstmöglich wiederherzustellen und aus den Vorfällen zu lernen, um zukünftige Sicherheitsrisiken zu minimieren.
  * **Patch Management:**  Patch Management ist der Prozess der Verwaltung von Updates für Software und Systeme, der insbesondere die Identifikation, das Testen und die Implementierung von Patches (Korrekturen oder Updates) umfasst. Ein effektives Patch-Management-Verfahren ist entscheidend, um bekannte Sicherheitslücken zu schließen und das Risiko von Sicherheitsverletzungen zu reduzieren. Es erfordert eine Balance zwischen der schnellen Anwendung kritischer Patches, um Sicherheitsrisiken zu minimieren, und der Notwendigkeit, die Stabilität und Kompatibilität innerhalb der IT-Landschaft zu gewährleisten.
  * **Drittanbieter- und Lieferantenrisikomanagement:**  Bewertung und Kontrolle der Risiken, die von Dritten ausgehen, mit denen Daten geteilt oder die in kritische Geschäftsprozesse eingebunden sind. Dies kann die Überprüfung der Sicherheitspraktiken von Drittanbietern und die Einführung von Sicherheitsanforderungen in Vertragsvereinbarungen beinhalten.
  * **Informationsklassifizierung und -handling:**  Entwicklung und Durchsetzung von Richtlinien zur Klassifizierung von Informationen nach ihrem Sicherheitsbedarf sowie entsprechenden Handhabungsprozeduren. Diese organisatorischen Maßnahmen sind entscheidend für die Schaffung eines ganzheitlichen und effektiven Sicherheitsprogramms, das sowohl technische als auch menschliche Faktoren berücksichtigt und sich kontinuierlich an sich ändernde Bedrohungen anpassen kann.
  * **Need-to-Know-Prinzip:**  Das Need-to-Know-Prinzip besagt, dass Personen nur Zugang zu den Informationen erhalten sollen, die unbedingt notwendig für die Ausübung ihrer Aufgaben sind. Ziel ist es, das Risiko unbeabsichtigter oder beabsichtigter Informationslecks zu minimieren und die Datensicherheit zu erhöhen, indem der Zugriff auf sensible Informationen strikt kontrolliert wird.
  * **Least-Privilege Prinzip:**  Das Least-Privilege Prinzip (Prinzip der minimalen Rechtevergabe) bedeutet, dass Nutzern und Systemen nur die minimal notwendigen Berechtigungen für die Erfüllung ihrer spezifischen Aufgaben gewährt werden. Dies reduziert das Risiko, dass weitreichende Rechte missbraucht werden oder dass ein Angreifer, der ein Konto kompromittiert, weitreichenden Zugriff innerhalb des Systems erlangen kann.
  * **Separation of Duties (Trennung von Verantwortlichkeiten):**  Die Trennung von Verantwortlichkeiten ist ein Sicherheitsprinzip, das fordert, kritische Aufgaben so aufzuteilen, dass für deren erfolgreiche Ausführung die Zusammenarbeit mehrerer Personen erforderlich ist. Dies soll Interessenkonflikte vermeiden, Betrug erschweren und die Wahrscheinlichkeit von Fehlern oder unbefugten Handlungen reduzieren.
  * **Job Rotation:**  Job Rotation bezeichnet den regelmäßigen Wechsel von Mitarbeitern durch verschiedene Positionen oder Aufgabenbereiche. In der IT-Sicherheit wird dieses Prinzip eingesetzt, um das Risiko von Insider-Bedrohungen zu minimieren, da kontinuierliche Veränderungen die Möglichkeiten für längere unbefugte Aktivitäten einschränken. Es fördert zudem die Redundanz von Fachwissen und erhöht die Widerstandsfähigkeit gegenüber Personalausfällen.
=== Security in der Praxis ===

Die Messung von IT-Sicherheit ist nicht trivial, da der Grad der Sicherheit von Produkten und Systemen nicht direkt messbar ist wie physikalische Größen. Stattdessen müssen indirekte Indikatoren, Metriken und Modelle herangezogen werden, um die Sicherheitseffektivität zu bewerten. Im Folgenden wird ein Überblick über die Vorgehensmodelle und gängiger Methoden zur Messung der IT-Sicherheit gegeben und anschließend auf die rechtlichen Rahmenbedingungen sowie relevante Standards eingegangen.

=== Vorgehensmodelle zum Messen von Security ===

Die Messung von IT-Sicherheit beginnt mit der Definition von Zielen und Kriterien, die die Sicherheitsanforderungen des Systems widerspiegeln. Diese Anforderungen basieren häufig auf den drei Grundpfeilern der IT-Sicherheit: Vertraulichkeit, Integrität und Verfügbarkeit (CIA-Prinzip). Zusätzlich können je nach Kontext weitere Aspekte wie Authentizität, Zurechenbarkeit und Nicht-Zurückweisbarkeit relevant sein. Deren Erfüllungsgrad lässt sich dann anhand von detaillierten Analysen des Systems bestimmen. Die meisten Ansätze verfahren dabei Risikobasiert, d.h. es wird zunächst eine Risikoanalyse zur Bestimmung der wesentlichen Schwachstellen und deren Schadenspotential durchgeführt. Die Risikoanalyse in der IT-Sicherheit zielt darauf ab, potenzielle Bedrohungen für Informationssysteme zu erkennen und die dadurch verursachten potenziellen Schäden sowie die Wahrscheinlichkeit ihres Auftretens zu bewerten. Sie beinhaltet die systematische Betrachtung von Schwachstellen, Bedrohungsvektoren und potenziellen Auswirkungen eines Sicherheitsvorfalls. Die Risikoanalyse bildet die Basis für das Risikomanagement und die Entwicklung effektiver Sicherheitsstrategien. Modelle wie STRIDE, DREAD, TARA und CVSS helfen dabei, Sicherheitsbedrohungen zu klassifizeren. Jedes dieser Modelle und Frameworks bietet spezifische Perspektiven und Werkzeuge zur Bewertung und Handhabung von Sicherheitsrisiken. Die Auswahl und Kombination der geeigneten Methoden hängt von der spezifischen Ausgestaltung des Systems ab. Häufig wird z.B. das Common Vulnerability Scoring System (CVSS) verwendet, welches ein offener Standard zur Bewertung der Schwere von Sicherheitslücken ist. CVSS bietet eine standardisierte Methode, um die Auswirkungen von Schwachstellen zu quantifizieren und zu vergleichen, indem es ihnen eine Nummer (Score) von 0 bis 10 zuweist, wobei höhere Werte auf eine größere Schwere hindeuten. CVSS Scores helfen bei der Priorisierung von Patch- und Mitigationsmaßnahmen basierend auf der potenziellen Auswirkung einer Schwachstelle. Die Bewertung von Schwachstellen kann über Blackbox-/ Whitebox-Analysen und Penetrationstest erfolgen. Diese ermöglichen unterschiedliche Perspektiven und Herangehensweisen zur Bewertung der IT-Sicherheit.

  * **Blackbox-Analyse:**  Die Blackbox-Analyse ist ein Ansatz, bei dem der Tester keine Vorabinformationen über das innere Funktionieren des Systems hat. Tester interagieren mit der externen Schnittstelle des Systems (wie einer Webapplikation oder einem Netzwerkdienst), um potenzielle Schwachstellen und Sicherheitslücken rein aus der Perspektive eines externen Angreifers zu identifizieren. Diese Methode ahmt das Vorgehen eines echten Angreifers nach, der typischerweise keinen Zugang zu internen Details des Systems besitzt. Die Blackbox-Analyse kann zeitaufwändig sein, da sie eine umfangreiche Erkundung erfordert, und ist besonders effektiv bei der Identifizierung von Schwachstellen in der Zugriffskontrolle und bei öffentlich zugänglichen Diensten.
  * **Whitebox-Analyse:**  Im Gegensatz zur Blackbox-Analyse hat der Tester bei der Whitebox-Analyse umfassenden Zugang zu allen internen Ressourcen des Systems, einschließlich Quellcode, Architekturdokumentation und Konfigurationsdetails. Diese Methode ermöglicht eine gründlichere Überprüfung, da sie das Verständnis der internen Logik und Struktur des Systems nutzt, um Sicherheitslücken zu identifizieren. Die Whitebox-Analyse ermöglicht es Testern, gezielt nach Schwachstellen in der Implementierung und Logik zu suchen, was zu einer effizienteren Identifizierung von Problemen wie Code-Injektion, unzureichender Datenvalidierung und anderen sicherheitskritischen Fehlern führt.
  * **Penetrationstesting:**  (auch bekannt als Pen-Testing oder ethisches Hacking) ist eine praxisorientierte Methode, bei der Sicherheitsexperten versuchen, in ein IT-System einzudringen, um Schwachstellen und Sicherheitsrisiken zu identifizieren. Im Gegensatz zu den eher theoretischen oder statischen Ansätzen der Blackbox- und Whitebox-Analyse ist das Penetrationstesting dynamisch und zielt darauf ab, die realen Auswirkungen eines Angriffs auf die Sicherheit des Systems zu simulieren. Es kann sowohl Blackbox- als auch Whitebox-Methoden umfassen, abhängig davon, wie viel Vorwissen über das System zur Verfügung steht. Penetrationstests bewerten nicht nur die Existenz von Sicherheitslücken, sondern auch die Fähigkeit des Systems, Angriffsversuche zu erkennen und darauf zu reagieren, und bieten so wertvolle Einblicke in die operative Sicherheit eines Systems.
=== Rechtliche Rahmenbedingungen ===

Die rechtlichen Rahmenbedingungen für IT-Sicherheit sind durch nationale und internationale Gesetze, Richtlinien und Verordnungen gegeben. Diese Vorschriften zielen darauf ab, ein Mindestniveau an Sicherheit für Informationstechnologiesysteme zu gewährleisten und den Schutz personenbezogener Daten zu stärken.

Einige der wichtigsten rechtlichen Rahmenbedingungen sind:

  * **NIS2-Richtlinie (EU):**  Die Richtlinie über Sicherheit von Netz- und Informationssystemen (NIS2) ist eine überarbeitete Version der ursprünglichen NIS-Richtlinie der Europäischen Union. Sie zielt darauf ab, ein hohes gemeinsames Sicherheitsniveau für Netz- und Informationssysteme in der EU zu gewährleisten. NIS2 erweitert den Anwendungsbereich auf weitere kritische Sektoren und verstärkt die Sicherheits- und Melderequirements für Unternehmen wesentlich.
  * **Cyber Resilience Act (CRA, geplant):**  Die Europäische Kommission hat einen Vorschlag für einen „Cyber Resilience Act“ vorgelegt, der darauf abzielt, die Sicherheit von digitalen Produkten und zugehörigen Dienstleistungen innerhalb der EU zu stärken. Der CRA soll Mindestanforderungen an die Cybersicherheit für Produkte mit digitalen Elementen einführen und einen einheitlicheren Rechtsrahmen schaffen.
  * **Datenschutz-Grundverordnung (DSGVO):**  Die DSGVO ist eine Verordnung der Europäischen Union, die den Schutz personenbezogener Daten und die Freizügigkeit dieser Daten regelt. Sie stellt strenge Anforderungen an die Verarbeitung personenbezogener Daten durch Unternehmen und Organisationen und gibt den Betroffenen weitreichende Rechte. Verstöße gegen die DSGVO können zu hohen Geldstrafen führen.
  * **IT-Sicherheitsgesetz (IT-SiG, Deutschland):**  Das deutsche IT-Sicherheitsgesetz bildet die nationale Umsetzung der EU-NIS-Richtlinie und adressiert Betreiber kritischer Infrastrukturen. Es verpflichtet diese, bestimmte Mindeststandards an IT-Sicherheit einzuhalten und erhebliche Sicherheitsvorfälle zu melden. Mit dem IT-Sicherheitsgesetz 2.0 wurde der Anwendungsbereich erweitert und die Anforderungen verschärft.
  * **Exportkontrolle:**  Sowohl auf nationaler Ebene als auch international sind Regelungen zur Exportkontrolle von IT-Sicherheitstechnologien von Bedeutung. Diese Regelungen sollen verhindern, dass sicherheitskritische Technologien, einschließlich Verschlüsselungssoftware und Dual-Use-Güter, in falsche Hände geraten. Länder wie die USA und die Mitgliedstaaten der Europäischen Union haben umfangreiche Bestimmungen erlassen, die den Export bestimmter Technologien beschränken.
=== Relevante Standards ===

Zertifizierungen spielen eine zentrale Rolle im Bereich der IT-Sicherheit, indem sie Standards für Wissen, Fähigkeiten, Praktiken und Prozesse setzen.

//Anmerkung JP: Evtl. kürzen. //
  * **ISO 27001/x (ISMS):**  Der internationale Standard ISO/IEC 27001 definiert die Anforderungen für ein Informationssicherheits-Managementsystem (ISMS). Er unterstützt Organisationen dabei, ihre Informationen durch systematische Risikomanagementprozesse sicher zu schützen, wobei die Flexibilität der Implementierung nach den spezifischen Sicherheitsanforderungen der Organisation erlaubt ist.
  * **BSI IT-Grundschutz:**  Entwickelt vom Bundesamt für Sicherheit in der Informationstechnik (BSI) in Deutschland, bietet der IT-Grundschutz einen umfassenden Ansatz zur Implementierung von Sicherheitsmaßnahmen. Es handelt sich um eine Sammlung von Empfehlungen und Best Practices, die auf der Identifizierung von typischen Gefährdungen und Standard-Sicherheitsmaßnahmen basieren, um ein angemessenes Sicherheitsniveau zu gewährleisten.
  * **ISO/IEC 15408 (Common Criteria - CC):**  Diese internationale Norm bietet einen Rahmen für die Bewertung der Sicherheit und Vertrauenswürdigkeit von Informations- und Kommunikationstechnikprodukten und -systemen. Sie ermöglicht es Herstellern, ihre Produkte unabhängig prüfen und zertifizieren zu lassen, um so deren Sicherheitseigenschaften transparent zu machen.
  * **ISO 62443:**  Dieser Standard konzentriert sich auf die industrielle Kommunikationstechnik und spezifiziert Sicherheitsmaßnahmen zum Schutz industrieller Automatisierungssysteme. Es bietet ein Framework zur Absicherung industrieller Automatisierungs- und Kontrollsysteme (IACS) und adressiert Aspekte wie Systemintegrität, Vertraulichkeit und Verfügbarkeit.
  * **ISO/SAE 21434:**  Ein Standard für die Cybersicherheit in der Automobilindustrie, der sich auf den Engineering-Lebenszyklus von Fahrzeugen konzentriert. Er bietet Richtlinien zur Risikobewertung, zum Design, zur Entwicklung, zur Produktion, zum Betrieb und zur Wartung von Sicherheitssystemen in Fahrzeugen, um deren Cyberresilienz zu stärken.
  * **FIPS 140:**  Das Federal Information Processing Standard (FIPS) Publication 140 ist ein US-amerikanischer Standard, der die Anforderungen an kryptografische Module festlegt, einschließlich deren Entwurf und Implementierung. Der Standard wird hauptsächlich von Regierungsbehörden und anderen Organisationen verwendet, die sensible, aber unklassifizierte Informationen schützen müssen.
  * **NIST Cybersecurity Framework (CSF):**  Entwickelt vom National Institute of Standards and Technology (NIST) in den USA, dient dieses Rahmenwerk dazu, Organisationen bei der Verwaltung und Minderung von Cyberrisiken zu unterstützen. Es bietet eine einheitliche Sprache und Methodik für die Einführung einer effektiven Cybersecurity-Praxis und fokussiert auf die Aspekte Identifizieren, Schützen, Erkennen, Reagieren und Wiederherstellen.
=== Entwicklung sicherer Produkte ===

Anmerkung JP: Evtl. noch SecDevOps ergänzen Der Entwurf, der Betrieb und die Wartung von sicheren Systemen, Prozessen und Produkten wir über das das Security Engineering, einem Teilbereich des Systems Engineering, gewährleistet. Beim Security Engineering geht es darum, angemessenen Schutz vor den Risiken, Bedrohungen und Schwachstellen zu bieten. Der Security Engineering Prozess ist ein systematischer und strukturierter Ansatz, um sicherzustellen, dass Sicherheitsanforderungen während der gesamten Lebensdauer eines Systems oder Produktes berücksichtigt und implementiert werden. Dies schließt die Konzeption, Entwicklung, Implementierung, Wartung und Außerbetriebnahme ein. Im Folgenden wird der Security Engineering Prozess in seinen grundsätzlichen Schritten erläutert:

  - **Identifikation und Bewertung der Assets**  Der erste Schritt besteht darin, die schützenswerten Assets zu identifizieren und zu bewerten. Die Bewertung schließt eine Bestimmung der Wichtigkeit jedes Assets und des potentiellen Schadens bei Verlust, Beschädigung oder Missbrauch ein.
  - **Risikoanalyse**  Nach der Identifikation und Bewertung der Assets folgt die Risikoanalyse. Dabei werden potenzielle Bedrohungen und Schwachstellen, die die Sicherheit der Assets beeinträchtigen könnten, identifiziert. Die Risikoanalyse bewertet auch, wie wahrscheinlich es ist, dass ein bestimmtes Risiko eintritt, und welchen potenziellen Schaden es verursachen könnte.
  - **Festlegung von Sicherheitszielen und -anforderungen**  Basierend auf der Risikoanalyse werden Sicherheitsziele und -anforderungen definiert, die die Richtung für die Gestaltung und Entwicklung von sicherheitskritischen Systemen und Produkten vorgeben. Diese Anforderungen beziehen sich in der Regel auf die Integrität, Verfügbarkeit, Vertraulichkeit und Authentizität der Assets.
  - **Entwurf und Entwicklung**  In dieser Phase werden Sicherheitskonzepte und -maßnahmen entwickelt und in das Produkt oder System integriert. Dies kann die Auswahl sicherer Hardware- und Softwarekomponenten, die Entwicklung sicherer Protokolle und die Implementierung von Kryptografie beinhalten.
  - **Implementierung und Verifikation**  Nach der Gestaltung und Entwicklung erfolgt die Implementierung der Sicherheitsmaßnahmen. Anschließend wird eine Verifikation durchgeführt, um sicherzustellen, dass die Sicherheitsanforderungen erfüllt sind. Dies kann durch Tests, Code-Reviews und Sicherheitsaudits geschehen.
  - **Betrieb und Wartung**  Sicherheit ist ein fortlaufender Prozess. Daher umfasst der Security Engineering Prozess auch den Betrieb und die Wartung von Systemen und Produkten, um zu gewährleisten, dass sie sicher bleiben. Dies schließt regelmäßige Updates, Patch-Management und das Monitoring von Sicherheitsvorfällen ein.
  - **Reaktion auf Sicherheitsvorfälle und Wiederherstellung**  Der letzte Schritt beinhaltet die Entwicklung und Implementierung von Plänen zur Reaktion auf Sicherheitsvorfälle und zur Wiederherstellung nach einem Vorfall. Dies soll sicherstellen, dass ein System oder Produkt nach einem Sicherheitsvorfall schnell wieder in einen sicheren Zustand zurückgeführt werden kann. Der Security Engineering Prozess ist ein zyklischer und iterativer Prozess, der eine kontinuierliche Bewertung und Anpassung der Sicherheitsmaßnahmen erfordert, um mit den sich ständig weiterentwickelnden Bedrohungen Schritt zu halten.
==== 4.4 Domänenspezifische Herausforderungen ====

Die Domänen Embedded Systems, Industrial Control Systems (ICS), Kritische Infrastrukturen (KRITIS), Automotive und Medizintechnik stehen jeweils vor spezifischen Herausforderungen in Bezug auf die Cybersecurity. Diese Herausforderungen ergeben sich aus den besonderen Anforderungen, Einsatzumgebungen und Risiken, die mit jeder Domäne verbunden sind. Im Folgenden wird ein wissenschaftlicher Überblick über diese domänenspezifischen Herausforderungen gegeben:

  * **Embedded Systems:**  Embedded Systems sind in vielen Bereichen des täglichen Lebens und der Industrie eingebettet, von einfachen Haushaltsgeräten bis hin zu komplexen Steuerungssystemen.
  * **Ressourcenbeschränkungen:**  Viele Embedded Devices verfügen über beschränkte Rechenleistung, Speicherplatz und Energiekapazität, was die Implementierung umfassender Sicherheitsmechanismen erschwert.
  * **Lange Lebenszyklen:**  Einige Embedded Devices, wie in der Luft- und Raumfahrt, sind für lange Betriebsdauern ausgelegt, wobei Aktualisierungen oder Patches schwierig umzusetzen sein können.
  * **Heterogenität und Kompatibilität:**  Die Vielfalt der Hardware und Software in Embedded Systems erschwert die Standardisierung von Sicherheitslösungen.
  * **Industrie und Produktionsanlage / Industrial Control Systems (ICS):**  ICS sind kritische Komponenten in der Fertigungs- und Versorgungsindustrie, deren Kompromittierung weitreichende physische Schäden verursachen kann.
  * **Verfügbarkeit vs. Vertraulichkeit:**  Im Gegensatz zu herkömmlichen IT-Systemen liegt der Fokus bei ICS auf der Verfügbarkeit und Integrität der Systeme. Die Sicherstellung der Vertraulichkeit ist oft von sekundärer Bedeutung.
  * **Alte und proprietäre Systeme:**  Viele ICS laufen auf veralteten oder proprietären Systemen, für die es schwierig ist, Sicherheitspatches zu erhalten oder zu implementieren.
  * **Netzwerkisolierung:**  Obwohl die Isolierung von Steuerungsnetzwerken von der übrigen IT-Infrastruktur als Schutzmaßnahme gilt, wird sie zunehmend schwieriger, da ICS immer öfter remote überwacht und gesteuert werden.
  * **Kritische Infrastrukturen (KRITIS):**  KRITIS umfassen Einrichtungen und Dienste, die für das Funktionieren der Gesellschaft wesentlich sind, wie Energieversorgung, Wasserwirtschaft und Gesundheitsdienste.
  * **Hohe Anforderungen an die Ausfallsicherheit:**  Ausfälle oder Beeinträchtigungen können gravierende Auswirkungen auf die öffentliche Sicherheit haben.
  * **Zielscheibe für staatlich unterstützte Angreifer:**  Aufgrund ihrer Bedeutung sind KRITIS oft Ziele für Cyberangriffe mit staatlicher Unterstützung oder mit der Absicht, der Gesellschaft Schaden zuzufügen.
  * **Komplexität und Verwundbarkeit:**  Die Vernetzung und Abhängigkeit zwischen verschiedenen KRITIS erhöht die Angriffsfläche und potenzielle Auswirkungen von Cyberangriffen.
  * **Automotive:**  Die zunehmende Vernetzung und Automatisierung in Fahrzeugen führt zu neuen Sicherheitsrisiken.
  * **Komplexe Lieferkette:**  Die Automotive-Industrie kennzeichnet eine komplexe Lieferkette, die die Konsistenz und Zuverlässigkeit von Sicherheitsmaßnahmen erschwert.
  * **Sicherheit des Fahrzeuglebenszyklus:**  Die langfristige Sicherung von Fahrzeugen vom Entwurf bis zur Verschrottung ist eine Herausforderung, insbesondere in Bezug auf Softwareupdates und Patches.
  * **Datenschutz:**  Die Sammlung und Übertragung persönlicher Daten durch vernetzte Fahrzeuge stellt Herausforderungen für den Datenschutz dar.
  * **Medizintechnik:**  Geräte im Gesundheitswesen sind besonders sensibel, da sie unmittelbar Patientendaten verarbeiten und lebenserhaltende Funktionen ausführen.
  * **Lebensrettende Geräte:**  Die Sicherheit von Medizingeräten ist kritisch, da Fehlfunktionen direkt das Leben von Patienten gefährden können.
  * **Datenschutz und Compliance:**  Medizingeräte verarbeiten hochsensible Patientendaten und müssen strenge Datenschutzbestimmungen wie die europäische Datenschutz-Grundverordnung (DSGVO) einhalten.
  * **Geräteaktualisierungen:**  Viele Medizingeräte sind schwer zugänglich und können nur mit erheblichem Aufwand aktualisiert werden, was die Behebung von Sicherheitslücken erschwert.
===== 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.

==== 6.4 Beispiele für risikobasierte Modelle ====

=== Safety Modelle====

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.

=== Security Modelle ===

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
===== 7 Ethische und rechtliche Aspekte =====
„Sicherheit“ (als „Oberbegriff“ zu Safety und Security) wird ubiquitär verwendet, hat verschiedene Bedeutungen und ist – abhängig vom Bezug – vielfältig konnotiert; sie ist jedoch trotz allem zu einem zentralen Bezugspunkt menschlichen Denkens, Handelns und Strebens geworden. Die Herstellung bzw. Gewährleistung von (Technik-)Sicherheit in unterschiedlichen gesellschaftlichen Bereichen ist auch mit ethischen Implikationen verbunden.
 
Ethik als Reflexionswissenschaft unterstützt die Suche nach Überschaubarkeit und Orientierung in einer (scheinbar?) immer unübersichtlicheren, komplexeren Welt. Ethische Analysen und Reflexionen sind kein (abstraktes) Moralisieren, sondern eine Form der „Beratung“ – insbesondere hinsichtlich Geboten oder Verboten bzw. Empfehlungen für Entscheidungen. Hinsichtlich Safety/Security bezieht sich das einerseits auf die Klärung grundlegender Begrifflichkeiten, Argumentationen und Begründungsverfahren sowie das Herausarbeiten impliziter Bedeutungsgehalte und Prämissen. Andererseits formuliert Ethik spezifische Standards und identifiziert mögliche Kriterien, die bei der Beurteilung von Sicherheit bzw. im praktischen Umgang mit ihr zu Grunde zu legen sind bzw. zu Grunde gelegt werden sollten. Dadurch, dass sich das auf mehrere (technische) Domänen bezieht, ergeben sich unterschiedliche Perspektiven und unterschiedliche Metriken, mit denen Sicherheit bemessen wird.
 
Dabei ist von einer Einheit von kognitiven, normativen, prozeduralen und kommunikativen Komponenten auszugehen.
  
Die kognitive Komponente besteht darin, anhand wissenschaftlicher Erkenntnisse, praktischer Erfahrungen und theoretischer – auch hypothetischer – Überlegungen mögliche sicherheitsrelevante Ursachen, Zusammenhänge und Szenarien zu erfassen. Auf diese Weise erhält man instrumentelles, vor allem wissenschaftlich-technologisches, politisches und organisatorisches Wissen über Kausalabläufe oder signifikante Korrelationen. Im Vordergrund steht Beschreibungs- und Gestaltungswissen für Produkte, Technologien und Anlagen sowie ihre Einbindung in Mensch-Technik-Interaktionen. Allerdings sind unterschiedliche Arten von Unsicherheiten zu berücksichtigen, insbesondere epistemische und aleatorische (von Zufällen abhängige). Während man erstere (er)kennen kann (jedoch mit mehr oder weniger großen „Lücken“, je nachdem, wie umfangreich die Evidenz und wie gut die Datenlage ist), entziehen sich letztere weitgehend der Erkenntnis, da sie auf Zufällen und menschlichem Handeln basieren. (Man denke in diesem Zusammenhang nur an die „List der Vernunft“!)
 
Die normative Komponente hängt damit zusammen, dass das, was als „(un-)sicher“ betrachtet sowie welcher Bereich möglicher Gefährdungen wahrgenommen bzw. welcher ausgeblendet wird („Wie sicher ist sicher genug?“), von Wollens- und Sollens-Vorstellungen und damit von Normen und Wertungen abhängig ist – die immer auch kulturell geprägt sind. Auch deshalb besteht infolge möglicher differierender Interessen und Wertvorstellungen etwa zwischen „Beteiligten“ und „Betroffenen“ sicherheitsrelevanter technischer Lösungen selten Einigkeit: Mit der Entscheidung über Handlungsstrategien bzw. Handlungen werden positive und negative Folgen verteilt, und zwar zumeist ungleich hinsichtlich verschiedener Bevölkerungsgruppen sowie zwischen Gegenwart und Zukunft. Das bedeutet, dass es auch um Leitbilder und Prioritäten, Maßstäbe und Indikatoren für sicherheitsverbesserndes Handeln bzw. entsprechende Verfahren geht. Das schließt (methodische) Reflexionen über den Prozess der (Güter-)Abwägung im Falle von Ziel- und Güter- bzw. Normkonflikten ein. Relevant sind dabei folgende Fragen: Wo muss der Mensch abwägen? Wo kann dies der Maschine beziehungsweise dem Algorithmus überlassen werden? Welche Risikoanteile darf man (keinesfalls) ausblenden?
  
Die prozedurale Komponente betrifft die über- bzw. transindividuelle Festlegung von Präferenzfolgen und Beurteilungsmaßstäben für Entscheidungen (etwa: „Wie sicher ist fair genug?“). Sollen das nicht top down-Entscheidungen der Politik (oder einen beliebigen anderen Institution) sein, muss diese Festlegung als Such- und Entscheidungsprozess organisiert werden, bei denen die relevanten Akteure die zu verfolgenden Ziele und die darauf aufbauenden bzw. davon ausgehenden Konzepte bei Berücksichtigung realer Macht- und Interessenkonstellationen aushandeln müssen (z.B. im Rahmen partizipativer Verfahren). Hier geht es auch um Fragen der Ressourcenverteilung, also der Verteilung von Ressourcen auf einzelne Sicherungsmaßnahmen, sowie um die Fragen, inwiefern man eine Abwägung, gegebenenfalls auch widersprüchliche Anforderungen aus unterschiedlichen Domänen, einem Algorithmus überlassen kann oder in welchen Bereichen eine menschliche Abwägung unbedingt erforderlich ist (etwa, weil Schaden an Leib und Leben von Menschen gegen Schaden an Sachen abgewogen werden muss). Im Ergebnis wird sich bei der Entscheidungsfindung dann eine Mischung aus menschlicher und Algorithmus-Entscheidung einstellen. Letzteres ist allein deshalb schon erforderlich, weil die Komplexität und die Anzahl der zu entscheidenden Freiheitsgrade zumeist sehr groß sind. Ziel sind letztendlich konsensfähige und bindende Resultate durch vielfältige kommunikative Prozesse.
  
Diese bilden die kommunikative Komponente, vor allem als Aufklärungs- und Vorsorgekommunikation, als Legimitationskommunikation und als Störfall- und Krisenkommunikation. Diese folgt einerseits aber keinem einfachen Sender-Empfänger-Modell, sondern ist mit „Kodierungen“ und „Dekodierungen“ unterschiedlichster Art bei den Beteiligten verbunden, andererseits können dabei auch (kommunikative) Konflikte über Annahmen und Definitionen sowie Daten und Statistiken, Schätzwerte und Wahrscheinlichkeiten, Kosten-Nutzen-Vergleiche sowie gesellschaftliche Werte auftreten. 

Die vier Komponenten in ihrer Einheit sind die Grundlage für stets notwendige (individuelle, kollektive oder gesellschaftliche) Abwägungen zwischen unterschiedlichen sicherheitsrelevanten „Schutzgütern“ bei der Suche nach dem „Ob?“ bzw. dem „Wie?“ konkreter sicherheitsrelevanter Lösungen (z.B. zwischen Sachwerten und Leben, zwischen informationeller Selbstbestimmung und der staatlichen Pflicht zur Kriminalitätsvorbeugung und –bekämpfung oder zwischen ökologischen und ökonomischen Interessen). Abwägungen sind eine Methode der möglichen Konfliktlösung auch im Bereich Sicherheit. Sie erfolgen hier in einem „Quadrupel“ unterschiedlicher Anforderungsbereiche: (1) (domänenspezifische) technische Voraussetzungen und Möglichkeiten, (2) gesellschaftliche Bedingungen und Anforderungen (insbesondere Schutzziele und –güter), (3) wirtschaftliche Erwartungen und Verfahrenswege (z.B. Aufwand-Nutzen-Überlegungen) sowie (4) rechtliche und Schadensregulierungen (z.B. Haftungs- und Gewährleistungsprobleme). Diese sind jeweils „angemessen“ zu berücksichtigen und „in Einklang“ zu bringen. Ergebnis ist eine Wichtung der jeweiligen Vor- wie Nachteile der zur Auswahl stehenden (auch alternativer) Lösungen, die zu einer Entscheidung hinsichtlich Nutzung bzw. Nicht-Nutzung dieser Lösungen führen (soll). Dieser Abwägungsprozess wird – was nicht vergessen werden darf – zusätzlich von individuellen Erwartungen und gemachten Erfahrungen beeinflusst, ist somit häufig nicht transindividuell oder intersubjektiv. 

Deshalb ist (mindestens) zweierlei zu kommunizieren: Erstens der zugrunde gelegte Beschreibungs- und Erklärungsrahmen („relative Apriori“, theoretische Prämissen, Grundannahmen) und zweitens die angewendeten Kriterien, Präferenzfolgen und Maßstäbe bei Auswahl- und Bewertungsprozessen. 

Damit gilt als zusammenfassende ethische Quintessenz: Jegliche sicherheitsrelevante Entscheidung muss letztlich sowohl nachvollzieh- und hinterfrag- als auch (auf der Grundlage „guter Gründe“) rechtfertigbar sein. 


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

** <font 24px/inherit;;inherit;;#f1c40f>Rohversion aus KI</font>  **

==== 8.1 Risiko: Definition und Herausforderungen ====

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

Diese Frage zielt auf die verwendeten Definitionen und theoretischen Konzepte ab: Wie wird Risiko modelliert (z. B. als Produkt aus Eintrittswahrscheinlichkeit und Schadensausmaß)? Welche Modelle sind etabliert (z. B. Bow-Tie, Fault Tree, Angriffsszenarien)? Wie unterscheiden sich Safety- und Security-Verständnisse?

**Welche Probleme und Dilemmata sind in Ihrer Disziplin charakteristisch? **

Hier geht es um typische Zielkonflikte, Unsicherheiten oder widersprüchliche Anforderungen, die in der Praxis auftreten – z. B. zwischen offener Bedienbarkeit (Safety) und Zugangsbeschränkung (Security). Wie werden unscharfe oder unsichere Risikobeiträge behandelt? Gefragt wird nach dem Umgang mit epistemischer Unsicherheit, fehlender Evidenz oder nur schwer quantifizierbaren Risiken – etwa durch Expertenabschätzungen, konservative Annahmen oder Sensitivitätsanalysen.

==== 8.2 Durchführung von Risikoanalysen ====

**Wie werden Risikoanalysen in Ihrer Disziplin durchgeführt (qualitativ, quantitativ, semi-quantitativ, nach Norm oder Richtlinie)? **
  * Diese Frage betrifft die Methodik der Risikoanalyse – ob sie auf Zahlen basiert (quantitativ), auf Bewertungsskalen (semi-quantitativ) oder auf Expertenurteilen und Kategorien (qualitativ), sowie ob normative Vorgaben (z. B. ISO, IEC) genutzt werden.

**Welche Metriken kommen hierbei zum Einsatz? **
  * Hier geht es um die verwendeten Maßzahlen zur Risikobewertung, wie SIL (Safety Integrity Level), PL (Performance Level), CVSS (Common Vulnerability Scoring System) oder eigene branchenspezifische Kennzahlen.

**Wie treten Wechselwirkungen der Domänen Safety und Security in der Risikoanalyse in Ihrer Disziplin in Erscheinung und wie werden diese behandelt? **
  * Gefragt wird, ob und wie Abhängigkeiten oder Zielkonflikte zwischen Safety- und Security-Anforderungen explizit betrachtet und methodisch integriert werden – etwa durch kombinierte Modelle, Szenarien oder Priorisierungen.

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

**Werden in den angrenzenden Disziplinen ähnliche oder andere Probleme bearbeitet? **
  * Diese Frage dient dem Vergleich mit benachbarten Disziplinen: Gibt es gemeinsame Herausforderungen (z. B. Unsicherheiten, Zielkonflikte)? Wo unterscheiden sich Herangehensweisen oder Prioritäten?

**Was sind methodische Unterschiede und Gemeinsamkeiten in verschiedenen Domänen? **
  * Diese Frage zielt darauf ab, innerhalb der jeweiligen Disziplin (z. B. Luftfahrt, Automotive, Energie, IT, physische Sicherheit) die Unterschiede und Gemeinsamkeiten der Methoden zur Risikoanalyse zwischen den Domänen Safety und Security herauszuarbeiten. Es soll untersucht werden, wie Risikoanalysen in beiden Bereichen jeweils durchgeführt werden – etwa hinsichtlich ihrer Modelle, Metriken, Normgrundlagen, Szenarioarten oder des Umgangs mit Unsicherheit – und ob sich daraus übertragbare Ansätze oder bestehende Zielkonflikte ableiten lassen. Ziel ist es, domänenübergreifende Schnittmengen zu identifizieren und Synergien oder Widersprüche systematisch zu dokumentieren.

**Wie könnte ein gemeinsamer Nenner für die Quantifizierung von Risiken in Safety- und Security Modellen aussehen? **
  * Ziel dieser Frage ist es, Kriterien, Maße oder Modelle zu benennen, die domänenübergreifend genutzt werden können – etwa harmonisierte Risikokategorien, kompatible Skalen oder gemeinsame Indikatoren.

**Welches neue Wissen ist erforderlich für eine Synthese der Domänen? **
  * Abschließend wird nach offenen Forschungsfragen, neuen Kompetenzen oder interdisziplinärem Wissen gefragt, das notwendig ist, um Safety und Security systematisch zu integrieren – etwa zu Unsicherheitsbewertung, ethischer Abwägung oder Entscheidungsmodellen.




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

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

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

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