content:test [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.
====== 1. Einleitung & Motivation ======

Test
<html>
<a id="meinanker"></a>
</html>
===== 1.1 Zielsetzung des Wikis =====

Das vorliegende Wiki entstand aus der Arbeit des VDI-Fachausschusses „Safety & Security“. Ziel war es zunächst, einen umfassenden Statusbericht zu erstellen, der die Herausforderungen und aktuellen methodischen Entwicklungen im Bereich der gemeinsamen Bewertung von Safety und Security systematisch darstellt. Aufgrund der schnellen Entwicklungen in diesem Themenfeld und der interdisziplinären Breite wurde entschieden, die Ergebnisse in Form eines lebendigen Wikis bereitzustellen, das kontinuierlich weiterentwickelt werden kann.

Das Wiki richtet sich vorrangig an Ingenieurinnen und Ingenieure sowie technische Fachkräfte, die in der Praxis mit Safety- und Security-Fragestellungen konfrontiert sind. Darüber hinaus sollen auch Fachleute aus benachbarten Disziplinen sowie interessierte Leserinnen und Leser angesprochen werden, die sich mit den zunehmenden Wechselwirkungen zwischen technischen Schutzmaßnahmen auseinandersetzen.

Das Wiki bietet einen Überblick über etablierte Praktiken und Bewertungsverfahren aus unterschiedlichen technischen Disziplinen und ordnet diese anhand definierter Kategorien sicherheitsrelevanter Wechselwirkungen ein. Dabei versteht es sich nicht als Richtlinie im engeren Sinne, sondern als strukturierter, kuratierter Wissensspeicher, der typische Herausforderungen benennt, Beispiele aus der Ingenieurpraxis beschreibt und wissenschaftlich-methodische Weiterentwicklungen aufzeigt – auch unter Einbeziehung ethischer Überlegungen.

Ein zentrales Ziel ist die Entwicklung einer domänenübergreifenden Perspektive, die Anwenderinnen und Anwendern hilft, widersprüchliche Anforderungen an Safety- und Security-Maßnahmen systematisch zu erkennen, zu analysieren und zu gestalten. Darüber hinaus soll das Wiki auch als strukturierter, semantisch zugänglicher Informationsraum dienen, der zukünftig KI-Systemen eine vertrauenswürdige Grundlage zur Analyse sicherheitsrelevanter Wechselwirkungen bietet.

===== 1.2 Warum Safety & Security gemeinsam denken? =====

Die gemeinsame Betrachtung von Safety und Security wird durch zwei wesentliche Entwicklungen notwendig:

**Zunehmende IT-Vernetzung technischer Systeme** führt dazu, dass sicherheitskritische Funktionen – etwa zur Gefahrenvermeidung – immer häufiger auf IT-Komponenten basieren. Diese sind potenziell angreifbar. Damit entsteht die Möglichkeit, dass Angriffe auf IT-Systeme (Security) zum Ausfall sicherheitsrelevanter Funktionen (Safety) führen. Diese Angriffswirkung ist zentraler Auslöser für die Notwendigkeit, Safety und Security gemeinsam zu denken.

**Zunehmende Bedrohungslage** in Gesellschaft, Infrastruktur und Wirtschaft – durch Cyberangriffe, hybride Bedrohungen oder gezielte physische Angriffe – verlangt nach einer integrierten sicherheitstechnischen Auslegung. Dies betrifft nicht nur die IT-Sicherheit, sondern auch die physische Sicherheit, etwa in Bezug auf kritische Infrastrukturen oder industrielle Anlagen.

Die Schutzfunktion technischer Systeme wird heute zunehmend durch Kombinationen aus Safety- und Security-Maßnahmen gewährleistet. Dabei treten Wechselwirkungen auf, die entweder synergetisch, neutral oder widersprüchlich sein können. Die Herausforderung besteht darin, diese Wechselwirkungen zu erkennen, zu bewerten und geeignete Maßnahmen zur Risikominimierung zu ergreifen.

Im Fokus stehen dabei nicht nur klassische Zielkonflikte – etwa zwischen Brandschutz und Zutrittskontrolle – sondern auch neue Herausforderungen durch die Integration von IT in sicherheitsrelevante Systeme. Die bisher übliche getrennte Betrachtung von Safety und Security greift hier zu kurz. Das Wiki verfolgt deshalb das Ziel, eine strukturierte, disziplinübergreifende Orientierung für die gemeinsame Bewertung und Gestaltung sicherheitsrelevanter Systeme zu schaffen.

====== 1.3 Disziplinen ======

In diesem Abschnitt finden Sie zentrale Anwendungsbereiche der gemeinsamen Betrachtung von Safety & Security. Jede Disziplin bringt eigene technische, normative und methodische Herausforderungen mit sich. Ziel des Wikis ist es, diese disziplinspezifisch zu beschreiben und vergleichbar zu machen – anhand definierter Kategorien, Bewertungsansätze und typischer Zielkonflikte. Klicken Sie auf einen der folgenden Links, um mehr zu erfahren:

  * [[https://safetyandsecurity.vdi.de/content:automotive|► Automobile Sicherheit]]
  * [[https://safetyandsecurity.vdi.de/content:arbeitsschutz|► Industrieanlagen & Arbeitsschutz]]
  * [[https://safetyandsecurity.vdi.de/content:kernenergie|► Kernenergieanlagen]]
  * [[https://safetyandsecurity.vdi.de/content:maritime_sicherheit|► Maritime Sicherheit]]
  * [[https://safetyandsecurity.vdi.de/content:physische_sicherheit|► Physische Sicherheit]]
  * [[https://safetyandsecurity.vdi.de/content:kritis|► KRITIS (Kritische Infrastrukturen)]]

====== 2. Grundlagen: Risiko, Safety, Security, Unsicherheiten ======

===== 2.1 Begriff: Risiko =====

Die Grundlage der gemeinsamen Betrachtung von Safety und Security bildet ein einheitlicher Risikobegriff. Ziel ist es, eine risikobasierte Systematik zu etablieren, die Wechselwirkungen zwischen technischen Maßnahmen in beiden Domänen systematisch erfassen und bewerten kann.

Risiko wird dabei grundsätzlich verstanden als eine Kombination aus Eintrittswahrscheinlichkeit und Auswirkung eines unerwünschten Ereignisses. Dieses Basismodell eignet sich gut zur Beschreibung klassischer Safety-Szenarien, stößt jedoch im Bereich der Security auf methodische Grenzen: Während technische Versagenswahrscheinlichkeiten in der Regel probabilistisch abschätzbar sind (z. B. aus Erfahrungswerten oder Fehlermodellen), ist dies bei sicherheitsrelevanten Angriffsszenarien nicht der Fall.

Im Bereich Security basiert die Eintrittswahrscheinlichkeit eines Angriffs in der Regel auf menschlicher Willensbildung. Die damit verbundene Unsicherheit ist epistemischer Natur – also durch fehlende oder nicht zugängliche Information bedingt – und kann nicht probabilistisch im klassischen Sinne modelliert oder durch Verteilungsfunktionen dargestellt werden. Daher wird in der Security häufig mit qualitativen oder semiquantitativen Einschätzungen gearbeitet, oder auch durch separate Bewertung von Verwundbarkeiten.

Zur Beschreibung von Risiko in beiden Domänen haben sich unterschiedliche Modellierungen etabliert:

  * Im Bereich Safety wird Risiko meist durch Eintrittswahrscheinlichkeit × Schadensausmaß beschrieben. In Normen wie IEC 61508 oder ISO 26262 führen diese zu gestuften Anforderungen (z. B. SIL, ASIL), die über die Verfügbarkeit von Sicherheitsfunktionen quantitativ nachgewiesen werden können.
  * Im Bereich Security wird Risiko oft als Kombination von Bedrohung, Vulnerabilität und Auswirkung beschrieben. Die Bedrohungswahrscheinlichkeit selbst bleibt dabei meist unquantifiziert – stattdessen erfolgt eine qualitative Einschätzung unter Unsicherheiten.

{{:content:startseite5.svg?400x157}}

Abbildung 1: Dreigliedrige Darstellung von Safety- und Security-Risiko

Die zu ergreifenden Maßnahmen im Bereich Safety und Security – die hier in aller Regel technologischer Natur sind – sollen das Eintreten des sicherheitsrelevanten Ereignisses mit bestimmter Wahrscheinlichkeit verhindern, sei es im Fall einer äußeren Bedrohung (z. B. Angriff, Missbrauch) oder eines internen Elementarereignisses (z. B. Komponentenausfall, Bedienungsfehler).

Die Herausforderung einer gemeinsamen Betrachtung liegt in der methodischen Integration dieser beiden Perspektiven. Eine Möglichkeit besteht in einem dreigliedrigen Risikobegriff, in Anlehnung an den Bereich Security, der die unterschiedlichen Beiträge zum Risiko berücksichtigt und somit eine Grundlage für Maßnahmenbewertung und Entscheidungsfindung schafft.

===== 2.2 Begriff: Safety =====

Safety-Risiken im Sinne dieser Dokumentation beziehen sich auf Risiken, die durch technische Systeme ausgelöst werden und Menschen, Umwelt, Sachwerte oder Infrastruktur gefährden können. Sie entstehen typischerweise infolge technischer Fehler, Komponentenausfälle oder unbeabsichtigter menschlicher Fehlhandlungen, z. B. durch Fehlbedienung oder mangelnde Wartung.

Ein wesentliches Merkmal von Safety-Risiken ist, dass ihre Eintrittswahrscheinlichkeit auf Basis von Erfahrungswerten probabilistisch abgeschätzt werden kann. In vielen Disziplinen der Safety werden Eintrittswahrscheinlichkeiten und Wirkungsfolgen (z. B. Personen- oder Umweltschäden) quantitativ modelliert und als Grundlage für das Sicherheitsdesign herangezogen – etwa über Methoden wie Fehlerbaumanalyse, HAZOP oder auch FMEA.

Typischerweise erfolgt eine zweistufige Bewertung: Gefährdungsanalyse (z. B. Risikograph, HARA), die die sicherheitsrelevanten Szenarien ermittelt und klassifiziert.

Nachweis der Wirksamkeit/Verfügbarkeit von Maßnahmen (z. B. über SIL- oder ASIL-Kategorien), die das Risiko auf ein vertretbares Maß reduzieren sollen.

Die zu ergreifenden Maßnahmen – zumeist technischer Natur – zielen darauf ab, die Wahrscheinlichkeit des Eintritts eines sicherheitsrelevanten Ereignisses bei einem bestimmten Auslöser (z. B. Fehler, Umwelteinfluss) zu verringern oder dessen Auswirkungen zu begrenzen. Die dafür eingesetzten Methoden sind in vielen technischen Normen und Regelwerken etabliert (vgl. Abschnitt 2.5.1).

Safety-Maßnahmen werden zunehmend durch IT-gestützte Komponenten realisiert, etwa Steuergeräte, Sensorik oder vernetzte Aktoren. Diese technologische Entwicklung begründet neue Verwundbarkeiten, die im Bereich der IT-Security verortet sind – und macht somit die gemeinsame Betrachtung von Safety und Security notwendig.

===== 2.3 Begriff: Security =====

Security-Risiken entstehen durch vorsätzliche, zielgerichtete Handlungen, die auf die Beeinträchtigung oder Kompromittierung technischer Systeme und Infrastrukturen abzielen. Im Gegensatz zur Safety ist die Ursache also nicht zufällig oder unbeabsichtigt, sondern willensgesteuert – etwa durch Sabotage, Spionage, Terrorismus, Diebstahl oder Cyberangriffe.

Das zentrale Merkmal von Security-Risiken ist die epistemische Unsicherheit bezüglich ihrer Eintrittswahrscheinlichkeit: Da Angriffe von intelligenten Akteuren ausgehen, sind sie nicht probabilistisch erfassbar. Es existieren in der Regel keine belastbaren historischen Daten, die eine statistische Modellierung der sogenannten Bedrohungswahrscheinlichkeit erlauben würden. Aus diesem Grund wird bei Security-Risiken häufig nur die Vulnerabilität des Systems betrachtet – also die Verwundbarkeit bei gegebenem Angriff.

Security-Risiken lassen sich typischerweise in zwei Hauptbereiche unterteilen:

IT-/Cybersecurity, bei der Systeme über digitale Schnittstellen (Netzwerke, Software, Fernzugriffe) angegriffen werden.

Physische Sicherheit, bei der der Zugang zu bedrohten Systemen, Anlagen oder Einrichtungen durch physische Mittel (z. B. Einbruchswerkzeug, schwere Kfz) erlangt wird.

Ziel von Security-Maßnahmen ist es, die Verfügbarkeit, Integrität und Vertraulichkeit technischer Systeme zu schützen. Dazu werden Maßnahmen implementiert, die das Auftreten eines erfolgreichen Angriffs erschweren, detektieren oder seine Wirkung begrenzen – etwa über Zugangskontrollen, Firewalls, Verschlüsselung, Segmentierung, physische Barrieren oder organisatorische Maßnahmen.

Im Gegensatz zur Safety, wo die Risikobewertung oft quantitativ erfolgt, dominieren im Bereich der Security qualitative oder semi-quantitative Bewertungsverfahren (z. B. TARA-Analysen, Bedrohungskataloge, CVSS). Die Bewertung ist oft kontextabhängig und orientiert sich an Szenarien, Angreiferprofilen oder Schutzzielen.

Die zunehmende digitale Vernetzung technischer Systeme hat zur Folge, dass Security-Risiken zunehmend auch sicherheitsrelevante Funktionen betreffen – etwa wenn IT-Systeme, die Teil der Safety-Architektur sind, durch Cyberangriffe gestört oder manipuliert werden können. Dadurch entstehen relevante Wirkungen von Security auf Safety, die eine gemeinsame Betrachtung erforderlich machen.

===== 2.4 Umgang mit Unsicherheiten =====

Im Rahmen sicherheitstechnischer Risikoanalysen spielen Unsicherheiten eine zentrale Rolle. Grundsätzlich lassen sich zwei Arten von Unsicherheiten unterscheiden:

Aleatorische Unsicherheiten, d. h. zufällige Streuungen (z. B. Ausfallraten, Umweltbedingungen), die durch Verteilungsfunktionen erfasst und mit probabilistischen Verfahren behandelt werden können.

Epistemische Unsicherheiten, d. h. Unsicherheiten aufgrund fehlender oder unvollständiger Informationen, etwa über die Wahrscheinlichkeit menschlichen Handelns oder die Existenz von Schwachstellen.

Mit aleatorischen Unsicherheiten kann man methodisch gut umgehen. In der Safety-Domäne sind bewährte Verfahren verfügbar: Monte-Carlo-Simulationen, die Berechnung von Vertrauensbereichen, varianzbasierte Sensitivitätsanalysen oder Bayessche Netze erlauben eine methodisch fundierte Risikoanalyse. Eine Abwägung verschiedener Risiken gegeneinander ist in diesem Rahmen prinzipiell möglich.

Im Security-Bereich dominiert jedoch epistemische Unsicherheit. Die Eintrittswahrscheinlichkeit von Security-Risiken hängt wesentlich von der Willensbildung potenzieller Angreifer ab und ist in der Regel nicht probabilistisch modellierbar. Damit versagen die klassischen Methoden der probabilistischen Risikoanalyse – etwa die Bewertung über Eintrittswahrscheinlichkeit × Auswirkung – im Security-Kontext weitgehend.

Konsequenz: In Fällen widersprüchlicher Anforderungen – etwa bei Zielkonflikten zwischen Safety und Security – ist eine Risikoabwägung methodisch kaum möglich, da eine quantitative Vergleichbarkeit der Risiken fehlt. Dies stellt eine wesentliche Herausforderung für die Auslegung sicherheitskritischer Systeme dar, die beide Domänen berücksichtigen müssen.

===== 2.5 Beispiele für risikobasierte Modelle =====

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

==== 2.5.2 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. The Security Risk Assessment Handbook: AComplete Guide for Performing Security Risk Assessments. 2nd ed. Boca Raton, FL, USA: CRC Press, 2011.
  * NE 153: Automation Security 2020 - Design, Implementierung und Betrieb industrieller Automatisierungssysteme, 2015

====== 3. Kategorien sicherheitsrelevanter Wechselwirkungen zwischen Safety und Security ======

Die zunehmende Vernetzung technischer Systeme sowie die veränderte globale Sicherheitslage machen eine gemeinsame Betrachtung von Safety- und Security-Maßnahmen erforderlich. Angriffe – insbesondere IT-basierte – können sicherheitsrelevante Funktionen direkt beeinträchtigen. Solche Angriffswirkungen sind konstituierend für die Notwendigkeit eines zusätzlichen Security-Layers und führen zu neuen Herausforderungen bei der Systemauslegung.

Im Rahmen dieses Wikis unterscheiden wir daher systematisch zwischen vier Typen sicherheitsrelevanter Designwechselwirkungen zwischen Safety und Security. Diese ergeben sich aus der Art der Beziehung zwischen den Anforderungen beider Domänen sowie deren wechselseitiger funktionaler Beeinflussung:

^Kategorie^Beziehungsart der Anforderungen^Relevante Designwechselwirkung^Richtung der Beeinflussung^Beispielhafte Betrachtung|
|1|kohärent oder konsistent|nein|keine|parallele Auslegung von Safety & Security|
|2|widersprüchlich|ja|Security → Safety (unidirektional)|IT-Security-Maßnahme verzögert Safety-Funktion|
|3|widersprüchlich|ja|Safety → Security (unidirektional)|Safety-Maßnahme erschwert Zutrittskontrolle|
|4|widersprüchlich|ja|bidirektional|Panikschloss: Fluchtszenario vs. Zutrittsverhinderung|

Hinweis: Die Angriffswirkung (Security Impact on Safety) ist unabhängig von der Designwechselwirkung und betrifft alle Kategorien, bei denen Safety-Funktionen auf IT-Systemen basieren. Sie ist konstituierend für die Notwendigkeit eines gemeinsamen Sicherheitsdesigns.

===== 3.1 IT-Security Impact on Safety =====

Der hier beschriebene Fall entspricht der Kategorie 1 der sicherheitsrelevanten Designwechselwirkungen: Die Anforderungen aus Safety und Security sind kohärent oder konsistent – es bestehen keine widersprüchlichen Anforderungen.

**Angriffswirkung auf Safety-Funktionen**

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.

Sicherheitsfunktionen stellen z. B. die rechtzeitige Abschaltung gefährdender Systeme oder Zugangsbeschränkung zu Gefahrenbereichen sicher und schützen somit Leben und körperliche Unversehrtheit. Die technische Umsetzung dieser Funktionen erfordert in der Regel Logik- oder IT-Systeme, die bei gegebener Vernetzung für Cyberangriffe vulnerabel sind.

**Methodische Herausforderungen bei der gemeinsamen Bewertung**

In gängigen Standards der funktionalen Sicherheit, wie IEC 61508 oder ISO 26262, werden quantitative Nachweise der Verfügbarkeit von Sicherheitsfunktionen gefordert – etwa über Ausfallwahrscheinlichkeiten und Diagnosebedeckung. Diese Metriken sind jedoch nicht kompatibel mit denen der IT-Security, da Eintrittswahrscheinlichkeiten für Cyberangriffe in der Regel nicht probabilistisch, sondern nur qualitativ abgeschätzt werden können.

Während sich Safety-Maßnahmen (z. B. SIL, ASIL) quantitativ über Fehlerraten und Zuverlässigkeitskennwerte belegen lassen, ist eine vergleichbare quantitative Bewertung von Security-Maßnahmen nicht möglich. Eine risikobasierte Abwägung zwischen den beiden Domänen ist daher in dieser Kategorie nur eingeschränkt möglich.

Da in dieser Kategorie keine widersprüchlichen Anforderungen bestehen, können Sicherheitsmaßnahmen für Safety und Security grundsätzlich unabhängig nebeneinander ausgelegt werden – vorausgesetzt, Angriffswirkungen auf Safety-Funktionen werden in der TARA (Security-Risikoanalyse) angemessen berücksichtigt.

===== 3.2 Security Impact on Availability =====

Kritische Infrastrukturen (KRITIS) sind das Rückgrat moderner Gesellschaften. Die permanente Verfügbarkeit von Energie-, Wasser-, Kommunikations- und Verkehrsinfrastrukturen bildet die Grundlage unserer gesellschaftlichen und wirtschaftlichen Existenz. Infolge der zunehmenden Bedrohungslage – etwa durch hybride Angriffe oder gezielte Cyberattacken – rückt die Resilienz dieser Infrastrukturen verstärkt in den Fokus.

Dabei ist zwischen unterschiedlichen Bereichen kritischer Infrastrukturen zu unterscheiden:

  * Bei physisch-technischen Infrastrukturen wie Strom-, Wasser- oder Verkehrssystemen sind Anforderungen an Verfügbarkeit (Availability) und Schutz vor Angriffen (Security) in der Regel konsistent. Die IT-Sicherheitsmaßnahmen zielen hier auf den Erhalt der Betriebsfähigkeit ab, ohne die Availability zu gefährden (Kategorie 1).
  * Bei IT- und Telekommunikationsinfrastrukturen können sich hingegen Security-Maßnahmen negativ auf die Availability auswirken. Beispielsweise können Segmentierungen, Firewalls oder Verschlüsselungstechnologien durch Fehlkonfiguration oder Sperrmechanismen zu Verzögerungen oder Ausfällen führen (Kategorie 2).

Von Angriffen – ob terroristisch, kriminell, staatlich oder anderweitig motiviert – können sehr viele Menschen gleichzeitig betroffen sein. Wechselwirkungen zwischen physischer und IT-bezogener Security müssen daher berücksichtigt werden, etwa bei der Sicherung von SCADA-Systemen oder Rechenzentren. Dies erfordert die Entwicklung abgestimmter, semi-quantitativer Metriken zur Bewertung von Security-Maßnahmen unter Availability-Gesichtspunkten.

**Lösungsansätze**:

Ein belastbarer Lösungsansatz besteht in der abgestimmten Betrachtung von IT-Sicherheit, physischem Schutz und Verfügbarkeitsanforderungen in einer integrierten Analyse. Für physisch-technische Infrastrukturen steht der Erhalt der operativen Verfügbarkeit im Vordergrund. Für IT-/TK-Infrastrukturen hingegen sind spezifische Gegenmaßnahmen gegen Angriffe zu entwickeln, die die Verfügbarkeit nicht gefährden.

Die gesetzlichen Vorgaben – etwa das BSI-Gesetz, die KRITIS-Verordnung oder das neue KRITIS-Dachgesetz – fordern die Einhaltung des 'Standes der Technik'. Dieser ist jedoch interpretationsbedürftig und dynamisch. Die Entwicklung validierbarer Kriterien und abgestimmter Bewertungsskalen ist daher ein zentrales Forschungs- und Praxisziel.

===== 3.3 Security Requirements Undermining Safety =====

In sicherheitskritischen Systemen kann es zu Situationen kommen, in denen Security-Anforderungen die Wirksamkeit oder rechtzeitige Ausführung von Safety-Funktionen behindern. Solche Fälle sind besonders kritisch, da der Schutz von Menschenleben durch Safety-Funktionen in der Regel oberste Priorität hat. Eine solche Konstellation stellt eine eigene Kategorie in der Betrachtung von Safety-Security-Wechselwirkungen dar, die sich von klassischen Angriffswirkungen (Security Impact on Safety) unterscheidet.

Während bei Angriffswirkungen die Kompromittierung durch eine externe Bedrohung erfolgt, geht es in dieser Kategorie um Designentscheidungen oder Sicherheitsanforderungen, die aus der Security-Domäne stammen und unbeabsichtigt Safety-Funktionen beeinträchtigen. Die Herausforderung liegt hier nicht in der quantitativen Risikobewertung, sondern in der szenariobasierten Analyse möglicher Konflikte und ihrer technischen Entkopplung.

**Typische Szenarien**

Verzögerung sicherheitskritischer Aktionen durch Authentifizierung: In IT-gestützten Safety-Funktionen kann eine starke Zugriffskontrolle (z. B. PIN, Token, Zwei-Faktor) im Notfall wertvolle Zeit kosten. Dies gilt z. B. für Sicherheitssysteme in der Industrie oder im Automotive-Bereich.

  * **Sicherheitsupdates beeinträchtigen Safety-Verfügbarkeit**: Regelmäßige Software-Updates zur Schließung von Security-Lücken können Systemneustarts oder zeitweilige Nichtverfügbarkeit sicherheitskritischer Systeme erfordern.
  * **Netzwerksegmentierung unterbricht Safety-Kommunikation**: Strikte Trennung von Netzwerken aus Security-Gründen kann zu unerwünschten Kommunikationsbarrieren führen, insbesondere bei verteilten Safety-Funktionen.
  * **Verschlüsselung verursacht Verzögerung oder Inkompatibilität**: Wenn Safety-relevante Daten verschlüsselt übertragen werden, kann dies zu Verzögerungen oder Datenverlusten führen, z. B. in Fahrzeugnetzwerken oder verteilten Industrieanlagen.
  * **IT-KRITIS-Ausfall mit Safety-Folgen**: Bei kritischen IT- oder Kommunikationsinfrastrukturen (z. B. GNSS, Zeitserver, SCADA-Netze) können Ausfälle auch sicherheitsrelevante physische Systeme betreffen. Diese Fälle wurden in Abschnitt 3.2 bereits behandelt.
**Lösungsansätze**  In der Regel ist der Schutz von Menschenleben höher zu priorisieren als der Schutz technischer Systeme oder Daten. Deshalb sollte bei potenziellen Konflikten zwischen Security- und Safety-Zielen stets eine szenarienabhängige Entkopplung geprüft werden. Mögliche Maßnahmen umfassen:

  * Einsatz technischer Entkopplungsmechanismen (z. B. sicherheitsgerichtete Bypass-Funktionen, notfallfähige Benutzeroberflächen)
  * Entwicklung intelligenter Umschaltlogiken oder „Fail-Safe“-Strategien
  * Klassifikation sicherheitskritischer Kommunikation als „prioritär“ in Netzwerken, auch unter Security-Randbedingungen
  * Dokumentation und risikoorientierte Freigabe von Update-Zeitpunkten und Sicherheitsmaßnahmen

Die Designentscheidung sollte unter Berücksichtigung von Worst-Case-Szenarien getroffen werden, in denen Safety-Funktionen kompromittiert werden könnten. Eine rein technische Betrachtung reicht nicht aus – es ist auch eine ethische Bewertung erforderlich, wenn Zielkonflikte auftreten.

===== 3.4 Safety Requirements Undermining Security =====

In der dritten Kategorie der Wechselwirkungen beeinflussen Anforderungen oder Maßnahmen aus dem Bereich Safety die Ausgestaltung und Wirksamkeit von Security-Maßnahmen. Diese Wechselwirkungen sind unidirektional: Eine Vorgabe oder Maßnahme aus der funktionalen Sicherheit schränkt Möglichkeiten zur Absicherung gegenüber gezielten Angriffen ein – z. B. durch Redundanzanforderungen, Notfallzugänge oder Entkopplung sicherheitskritischer Systeme.

**Vorgeschriebene Notöffnungen vs. Zugangsschutz**

In sicherheitskritischen Anlagen (z. B. Kernkraftwerke, chemische Industrie) kann eine Safety-Vorgabe erfordern, dass sich Türen bei Feuer oder Stromausfall automatisch öffnen müssen – unabhängig davon, ob eine unautorisierte Person gerade Zugang hätte. Dadurch wird ein zuvor sicherer Zugang (Security) durch eine Safety-Funktion untergraben.

**Entkoppelung redundanter Systeme**

Aus Safety-Gründen wird häufig Redundanz eingeführt (z. B. Redundanz bei Steuerungen oder Netzwerken). Wenn diese redundanten Systeme aus Safety-Sicht bewusst voneinander getrennt (entkoppelt) gehalten werden, können zentrale Security-Mechanismen wie eine durchgehende Zugangskontrolle oder einheitliches Patch-Management behindert werden.

**Bypass-Schaltungen für Diagnose- oder Wartungszwecke**

Für Wartung und Instandhaltung (oft aus Safety-Gründen) existieren oft Bypass-Schaltungen oder spezielle Zugriffsmöglichkeiten, die in Notfällen oder zu Diagnosezwecken aktiviert werden dürfen. Diese können potenziell ein Security-Loch darstellen, wenn sie nicht ausreichend abgesichert oder überwacht werden.

**Mensch-Maschine-Schnittstellen mit Safety-Fokus**

Bestimmte Anforderungen an Benutzerfreundlichkeit oder Erreichbarkeit von Not-Aus-Schaltern können Sicherheitsmaßnahmen wie Zugriffskontrolle (z. B. über PINs, Karten oder biometrische Daten) unterlaufen – z. B. weil eine schnelle Reaktionsfähigkeit als übergeordneter Safety-Wert gilt.

**Priorisierung von Safety-Meldungen in Kommunikationsnetzen**

In manchen Protokollen oder Echtzeitnetzwerken werden Safety-bezogene Datenpakete priorisiert übertragen, was zu Verzögerungen oder Paketverlusten bei Security-Meldungen führen kann (z. B. Alarmierung bei einem Einbruch oder Angriff).

Diese Beispiele zeigen, dass auch Safety-Anforderungen in bestimmten Konstellationen sicherheitsrelevante Wechselwirkungen hervorrufen können. Solche Szenarien sind sorgfältig zu prüfen – auch wenn die Priorisierung der Safety-Funktion in vielen Fällen gerechtfertigt ist, muss die potenzielle Schwächung von Security-Maßnahmen im Gesamtsystem mitgedacht werden.

=== Abwägung und Priorisierung ===

Auch wenn die Wahrscheinlichkeit und Relevanz solcher Szenarien geringer ist als bei der umgekehrten Wechselwirkung (Security Impact on Safety), sollte die Möglichkeit dennoch im Designprozess berücksichtigt werden – insbesondere in besonders kritischen Infrastrukturen wie der Kerntechnik.

Dabei gilt weiterhin die grundlegende Empfehlung: Der Schutz von Menschenleben (in diesem Kontext: Safety) hat in sicherheitsrelevanten Anwendungen grundsätzlich Vorrang. Security-Maßnahmen dürfen die Wirksamkeit von Safety-Funktionen nicht kompromittieren – aber umgekehrt ist auch zu vermeiden, dass Safety-Maßnahmen potenzielle Sicherheitslücken verursachen oder Schutzmechanismen im Bereich Security unterlaufen.

===== 3.5 Contradicting Safety-Security Requirements =====

Die hier beschriebenen Konstellationen entsprechen Kategorie 4 – also Fällen widersprüchlicher Anforderungen an Safety- und Security-Funktionen mit potenziell sicherheitsrelevanten Wechselwirkungen. In diesen Fällen sind Safety- und Security-Ziele nicht gleichzeitig erfüllbar, sondern konkurrieren miteinander.

Ein klassisches Beispiel ist die Gebäudesicherheit: Fluchtmöglichkeiten im Brandfall (Safety) können durch verriegelte Türen (Security) behindert werden. Technische Maßnahmen wie Panikschlösser oder Pushbars dienen dazu, diese Anforderungen szenarioabhängig zu entkoppeln. Solche Lösungen ermöglichen eine automatische oder manuelle Umschaltung des Systemverhaltens je nach Bedrohungslage – etwa Feueralarm vs. Einbruch.

Ein besonders tragischer Fall eines ungelösten Zielkonflikts war der Absturz des Germanwings-Flugs 9525: Die Cockpittür war aus Sicherheitsgründen (Security) gepanzert und nicht aufzubrechen. Im Notfall kann sie mit einem Code von außen geöffnet werden (Safety), allerdings lässt sich dieser Mechanismus aus dem Cockpit heraus blockieren (Security). Dies führte dazu, dass die Crew den Suizid des Piloten nicht verhindern konnte – 150 Menschen starben. Dieses Beispiel illustriert eindrücklich die sicherheitsrelevanten Konsequenzen widersprüchlicher Anforderungen.

Auch in der Nukleartechnik entstehen Zielkonflikte: Maßnahmen gegen Sabotage (Security) können betriebliche Anforderungen an Redundanz oder Reaktionszeiten (Safety) beeinträchtigen. Derartige Widersprüche lassen sich nicht vollständig auflösen, sondern erfordern eine bewusste Abwägung.

Das Problem bei der Abwägung liegt vor allem in der Unsicherheit: Während aleatorische Unsicherheiten (z. B. bei Komponentenausfällen) probabilistisch modellierbar sind, handelt es sich bei der Eintrittswahrscheinlichkeit von Angriffen meist um epistemische Unsicherheiten – also um nicht objektivierbare Einschätzungen. Eine belastbare Risikoabwägung zwischen Safety und Security ist daher nur sehr eingeschränkt möglich.

Lösungsansätze bestehen unter anderem in der Entwicklung technischer Entkopplungsmechanismen und semi-quantitativer Bewertungsverfahren. Diese sollen dabei helfen, Prioritäten, Wirkungsgrade und Zielkonflikte nachvollziehbar zu machen. Letztlich müssen sicherheitsrelevante Entscheidungen jedoch immer auch ethische und gesellschaftliche Aspekte berücksichtigen.

Im Gegensatz zu Kategorie 1 (kohärente Anforderungen) und Kategorie 2 (unidirektionale Beeinflussung durch Security auf Availability oder Safety) sind die Zielkonflikte der hier betrachteten Kategorie 4 besonders komplex, da sie eine simultane, gleichwertige Betrachtung beider Schutzziele erfordern.

===== 3.6 Cyberphysical Systems =====

Cyberphysische Systeme (CPS) sind Systeme, in denen physische Prozesse, IT-Komponenten und Kommunikationstechnologien so eng miteinander verknüpft sind, dass eine getrennte Betrachtung von Safety, IT-Security und physischer Sicherheit kaum noch möglich ist. Sie stellen nicht nur ein zentrales Anwendungsfeld für die kombinierte Sicherheitsbewertung dar, sondern fordern die etablierten Paradigmen der Sicherheit in ihrer Grundstruktur heraus.

**Verwobene Sicherheitsdomänen**

In CPS greifen Sicherheitsfunktionen aus allen Domänen – funktionale Sicherheit (Safety), IT-Security und physische Security – unmittelbar ineinander:

  * Ein physischer Angriff auf ein Rechenzentrum oder SCADA-System kann systemweit alle IT- und Steuerungsfunktionen kompromittieren.
  * Ein Cyberangriff auf eine Zugangskontrolle kann physische Sicherheitsmaßnahmen außer Kraft setzen.
  * IT-gesteuerte Drohnenangriffe können etablierte physische Sicherheitsarchitekturen wie Zäune, Schleusen oder Perimeterüberwachung vollständig unterlaufen, bzw. überfliegen.

**Globale Wirkung lokaler Störungen**

Die immanente IT-Verknüpfung in CPS führt dazu, dass lokale Ereignisse globale Auswirkungen haben können:

  * Ein Angriff an einem Netzknoten kann kritische Steuerungsprozesse in entfernten Regionen lahmlegen.
  * Die Kopplung von Safety-Funktionen an IT-Systeme bedeutet: ein lokaler Security-Vorfall kann global sicherheitsrelevante Funktionen aushebeln – z. B. Notabschaltungen, Brandschutz, oder Verkehrsregelung.

**Auflösung klassischer Sicherheitsgrenzen**

Während frühere Sicherheitskonzepte meist klar zwischen physischen und digitalen Angriffsvektoren unterschieden, verwischen diese Grenzen zunehmend. Der Schutz technischer Systeme muss daher domänenübergreifend gedacht werden:

**Lösungsansätze**

Cyberphysische Systeme benötigen neue, integrative Ansätze, z.B.:

  * Szenariobasierte Risikoanalysen, die Safety-, IT- und physische Risiken gemeinsam bewerten
  * Kopplung etablierter Methoden (FMEA, Fault Tree, HARA, TARA) zu domänenübergreifenden Modellen
  * Dynamisch adaptierbare Schutzstrategien, die im Notfall automatische Umschaltungen oder Priorisierungen erlauben
  * Technische Mechanismen zur zuverlässigen Entkopplung von Szenarien

====== 4. Funktionale Sicherheit ======

Die Funktionale Sicherheit ist ein zentraler Bestandteil der technischen Sicherheit von Maschinen und Anlagen. Sie bezieht sich auf Sicherheitsfunktionen, die durch Steuerungs- und Automatisierungstechnik realisiert werden, um Risiken systematisch zu mindern. Im Mittelpunkt steht die Beherrschung von Gefährdungen durch gezielte technische Maßnahmen, wie z. B. Sensorik, Logik und Aktorik, deren zuverlässiges Zusammenspiel essenziell ist, um gefährliche Situationen zu erkennen und darauf zu reagieren.

Dieser Abschnitt erklärt grundlegende Konzepte wie Risiko, Sicherheitsfunktionen, Ausfallwahrscheinlichkeiten (PFD/PFH), Safety Integrity Level (SIL), typische Fehlerarten und Schutzmaßnahmen. Dabei wird die Normenbasis (insbesondere IEC 61508) ebenso betrachtet wie konkrete Beispiele und bewährte Methoden zur Entwicklung sicherer Systeme.

→ Für detaillierte Inhalte klicken Sie auf **„Mehr Informationen“**.

++++ Mehr Informationen|

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

====== 5. Querschnittsthemen ======

Themen wie IT-Security, Resilienz und ethische Aspekte sind keine eigenständigen Disziplinen im engeren Sinne, sondern betreffen alle sicherheitsrelevanten Fachgebiete gleichermaßen. Sie wirken disziplinübergreifend, durchziehen technische, organisatorische und gesellschaftliche Fragestellungen und sind für jede Domäne – von der Automobilsicherheit bis hin zur kritischen Infrastruktur – von grundlegender Bedeutung.

===== 5.1 IT-Security =====

Die Sicherheit informationstechnischer Systeme ist ein zentraler Aspekt moderner digitaler Infrastrukturen. In diesem Kapitel werden grundlegende Schutzziele, technische und organisatorische Maßnahmen sowie praxisnahe Ansätze zur Gewährleistung der IT-Sicherheit vorgestellt. Darüber hinaus wird ein Überblick über relevante Standards, rechtliche Rahmenbedingungen sowie domänenspezifische Herausforderungen gegeben, die im Kontext kritischer Systeme wie Automotive, KRITIS, Medizintechnik oder Embedded Systems besonders ins Gewicht fallen.

Ziel ist es, ein systematisches Verständnis für die Prinzipien, Methoden und Anforderungen der IT-Sicherheit zu vermitteln – sowohl aus theoretischer Sicht als auch mit Blick auf konkrete Umsetzungsstrategien in der Praxis.

→ Für detaillierte Inhalte klicken Sie auf **„Mehr Informationen“**.

++++ Mehr informationen |==== 5.1.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.

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

==== 5.1.3 Grundlagen der IT-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-Security integriert behandelt. Die Abhängigkeiten der Schutzziele erfordert eine ausgewogene Berücksichtigung aller vier Aspekte, um ein effektives Sicherheitsniveau zu erreichen.

=== Technische Maßnahmen ===

  * **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 ===
  * **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-Security 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-Security 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-Security gegeben und anschließend auf die rechtlichen Rahmenbedingungen sowie relevante Standards eingegangen.

=== Entwicklung sicherer Produkte ===

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.
==== 5.1.4 Vorgehensmodelle & Metriken ====

Die Messung von IT-Security 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-Security 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.
==== 5.1.5 Normen & rechtlicher Rahmen ======= 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 IT-Security 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-Security 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.

  * **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 IT-Security 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 umklassifizierte 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 IT-Securityrisiken zu unterstützen. Es bietet eine einheitliche Sprache und Methodik für die Einführung einer effektiven IT-Security-Praxis und fokussiert auf die Aspekte Identifizieren, Schützen, Erkennen, Reagieren und Wiederherstellen.
==== 5.1.6 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 IT-Security. 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 stellen 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.2 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.

→ Für detaillierte Inhalte klicken Sie auf **„Mehr Informationen“**.

++++ Mehr informationen|==== 5.2.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.

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

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

++++

===== 5.3 Ethische Aspekte =====

Ethische Reflexionen spielen eine zentrale Rolle, wenn es um Fragen der Sicherheit geht – verstanden als Oberbegriff von Safety und Security. Denn Sicherheit betrifft nicht nur technische Machbarkeit, sondern auch Wertentscheidungen, Verantwortlichkeiten und gesellschaftliche Aushandlungsprozesse. Ethik hilft dabei, Orientierungen in komplexen Entscheidungssituationen zu entwickeln und Maßstäbe für verantwortungsvolles Handeln zu formulieren. Der folgende Text beleuchtet, wie sich sicherheitsrelevante Entscheidungen ethisch analysieren und begründen lassen. Im Mittelpunkt stehen vier wesentliche Dimensionen: kognitiv, normativ, prozedural und kommunikativ.

→ Für detaillierte Inhalte klicken Sie auf **„Mehr Informationen“**.

++++ Mehr informationen|==== 5.3.1 Ethische Überlegungen & Abwägung ====

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

++++

====== 6. Leitfragen-Erläuterungen ======

Die folgenden zehn Leitfragen dienen dazu, die Beschreibung der einzelnen Disziplinen in eine einheitliche Struktur zu bringen. Alle Expertinnen und Experten wurden gebeten, ihre Disziplin entlang dieser Fragen zu beschreiben. Auf diese Weise lassen sich die Sichtweisen auf Risiko, Methoden, Dilemmata sowie mögliche Ansätze zur Auflösung von Zielkonflikten systematisch erfassen und vergleichen. **Auch für neu aufzunehmende Disziplinen ist vorgesehen, dass sie anhand dieser Leitfragen dargestellt werden, um eine konsistente Erweiterung des Wikis zu ermöglichen.**

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

**Frage: 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 und Verfahren sind etabliert (z. B. Bow-Tie, Fault Tree, Angriffsszenarien)? Wie unterscheiden sich Safety- und Security-Verständnisse?

**Frage: 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).

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

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

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

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

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

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

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

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

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

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

====== 7. Fachausschuss Team ======

[[:content:fachausschuss|Der Fachausschuss]]