content:hauptseite [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. Motivation & Zielsetzung ======

===== 1.1 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 Safety-relevanter 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 (kohärent), neutral (konsistent) oder oft auch **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 Zutrittsbeschränkung – sondern auch neue Herausforderungen durch die Integration von IT insbesondere in Safety-relevante Systeme. Die bisher übliche getrennte Betrachtung von Safety und Security greift hier zu kurz.

Vor diesem Hintergrund wurde im VDI-Fachausschuss Safety & Security das vorliegende Wiki entwickelt. Es soll helfen, die beschriebenen Herausforderungen methodisch einzuordnen, bestehende Ansätze zu vergleichen und Grundlagen für eine gemeinsame Behandlung von Safety und Security zu schaffen

===== 1.2 Zielsetzung des Wikis =====

Das Wiki entstand aus der Arbeit des VDI-Fachausschusses „Safety & Security“, der sich mit der zunehmenden Verflechtung beider Domänen befasst. Während Safety und Security in der Vergangenheit meist getrennt voneinander behandelt wurden, zeigt sich heute immer deutlicher, dass technische Sicherheit (Safety) und Schutz vor Angriffen (Security) nicht unabhängig voneinander gedacht werden können.

Unterschiedliche fachliche Hintergründe und Zielsetzungen haben in den einzelnen Disziplinen und Domänen – etwa in der funktionalen Sicherheit, der IT-Security oder der physischen Sicherheit – zu jeweils eigenen Begrifflichkeiten, Methoden und Prozessen geführt. Der Fachausschuss hat daher zunächst die in den verschiedenen Disziplinen und Domänen verwendeten Begriffe und etablierten Verfahren systematisch analysiert, um Gemeinsamkeiten, Unterschiede und methodische Herausforderungen in einer gemeinsamen Sichtweise zusammenzuführen.

Ein erstes Teilziel war die Entwicklung einer gemeinsamen risikobasierten Darstellung, die es ermöglicht, widersprüchliche Anforderungen aus den Domänen Safety und Security systematisch zu erkennen, zu analysieren und zu gestalten. Diese Darstellung bildet die Grundlage für die im Wiki dargestellten Kategorien sicherheitsrelevanter Wechselwirkungen, die eine domänenübergreifende Einordnung technischer Schutzmaßnahmen erlauben.

Im Verlauf der Arbeit reifte die Überzeugung, die Ergebnisse nicht in Form eines einmaligen Berichts, sondern als lebendiges Wiki zu veröffentlichen. Die dynamische Entwicklung des Themenfeldes sowie die interdisziplinäre Breite machen ein fortlaufend aktualisierbares Wissensformat notwendig.

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 spricht es auch Fachleute aller Disziplinen und interessierte Leserinnen und Leser an, die sich mit sicherheitsrelevanten Wechselwirkungen technischer Schutzmaßnahmen befassen. Es bietet einen Überblick über gängige Bewertungspraktiken, Normen und Methoden aus verschiedenen technischen Disziplinen und Domänen und ordnet diese anhand definierter Kategorien sicherheitsrelevanter Wechselwirkungen ein. Dabei versteht sich das Wiki nicht als Richtlinie im engeren Sinne, sondern als strukturierter, kuratierter Wissensspeicher, der typische Herausforderungen beschreibt, Beispiele aus der Ingenieurpraxis dokumentiert und wissenschaftlich-methodische Weiterentwicklungen aufzeigt – auch unter Berücksichtigung ethischer Fragestellungen.

Das Wiki versteht sich als wachsende Wissensplattform. Es wird fortlaufend um zusätzliche Disziplinen, Praxisbeispiele und methodische Ansätze ergänzt. Beiträge und Anregungen aus der Fachcommunity sind ausdrücklich willkommen. Für weiterführende Informationen oder Mitwirkung kann Kontakt mit dem VDI-Fachausschuss 512 „Safety & Security“ aufgenommen werden.   

Langfristig soll das Wiki nicht nur als Orientierungshilfe für Fachanwender dienen, sondern auch als strukturierter Informationsraum, der künftig eine vertrauenswürdige Grundlage für die Analyse sicherheitsrelevanter Wechselwirkungen durch KI-Systeme bilden kann.

===== 1.3 Anwendungsfelder: Disziplinen =====

In diesem Abschnitt finden Sie zentrale Anwendungsfelder der gemeinsamen Betrachtung von Safety & Security. Jede Disziplin bringt eigene technische, normative und methodische Herausforderungen mit sich. Die Auflistung ist nicht als abgeschlossen zu verstehen, grundsätzlich soll der Katalog der Disziplinen stetig erweitert werden. Ziel des Wikis ist es, diese disziplinspezifisch durch Beantwortung von Leitfragen ([[https://safetyandsecurity.vdi.de/content:hauptseite#leitfragen-erlaeuterungen|siehe Abschnitt 6]]) 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:industrie-produktionsanlagen|► Industrie- und Produktionsanlagen]]
  * [[https://safetyandsecurity.vdi.de/content:kerntechnische-anlagen|► 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 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 z. B. in der funktionalen Sicherheit (Safety) Eintrittswahrscheinlichkeiten und Auswirkungen in einer ersten Risikobewertung über semi-quantitative Risikografen oder HARA-Verfahren eingeordnet werden (kategorische Einstufung nach Schadenausmaß, Exposition, Kontrollmöglichkeit usw.), wird die Eintrittswahrscheinlichkeit z. B. im Bereich der physischen Sicherheit (Security) in zwei Komponenten aufgeteilt: Die Vulnerabilität beschreibt die bewertbare und im Falle der physischen Sicherheit auch objektiv quantifizierbare Angreifbarkeit eines Systems, während die Bedrohungswahrscheinlichkeit auf menschlicher Intention beruht und daher epistemisch unsicher bleiben muss. Durch diese Aufspaltung entsteht das dreigliedrige Risikomodell aus Threat, Vulnerability und Impact, das die unterschiedliche Bewertbarkeit der Einflussgrößen berücksichtigt.

Normen der funktionalen Sicherheit wie IEC 61508 oder ISO 26262 leiten aus der Risikobewertung gestufte Anforderungen (z. B. SIL, ASIL) ab, deren Erfüllung über quantitative Nachweise zur Verfügbarkeit von Sicherheitsfunktionen bestätigt wird. Dieser zusätzliche Nachweis kann sehr gut mit der quantitativen Betrachtung der Vulnerabilität in der physischen Sicherheit verglichen werden - im komplementären Sinne, denn Vulnerabilität entspricht hier der Nicht-Verfügbarkeit von Safety-Funktionen. Folglich lässt sich das Risiko Im Bereich Security dreigliedrig als Kombination von Bedrohung (Threat), Vulnerabilität (Vulnerability) und Auswirkung (Impact) sehr gut neben die Modellierung der funktionalen Sicherheit legen.

{{:content:abbildung5.svg?550x306}}

Bild 2.1: Dreigliedrige Darstellung von Safety- und Security-Risiko

Bild 2.1 zeigt die isomorphe Struktur beider Risikomodelle:
Sowohl Safety als auch Security lassen sich dreigliedrig beschreiben – als Abfolge von Ursache (Threat, Hazard) → Fehler (Vulnerability, Failure) → Auswirkung (Impact, Consequence). Die Unterschiede in Safety und Security liegen nicht notwendig in der Struktur der Risikomodelle, sondern in der Natur der Unsicherheiten, den Bewertungsmetriken und in den zugrunde liegenden Schutzmaßnahmen.

In der gemeinsamen Betrachtung entsteht eine Kopplung über die Ebene der Vulnerabilität in zweierlei Hinsicht:
Security-Maßnahmen können bei widersprüchlichen Anforderungen die Verfügbarkeit von Safety-Funktionen beeinflussen (Designwechselwirkung - //Conflicting Requirements//) und umgekehrt, oder ein erfolgreicher Security-Angriff kann die Safety-Funktion direkt beeinflussen (Angriffswirkung). Letzteres stellt den Pfad des //Security Impact on Safety// dar – der Impact eines Security-Szenarios zeigt sich dann in der Nichtverfügbarkeit einer Safety-Funktion und führt damit zu einer erhöhten Vulnerabilität im Safety-Risiko. Angriffswirkungen auf Safety-Funktionen werden nicht innerhalb der Safety-Domäne berücksichtigt, da deren Verfügbarkeitsnachweis probabilistisch ausgelegt ist und zufällige oder systembedingte Ausfälle beschreibt. Die Bedrohungswahrscheinlichkeit in der Security ist allerdings epistemisch und kann schwerlich quantifiziert werden. Stattdessen werden Angriffswirkungen in der Security-Domäne adressiert: Die Security-Analyse (z. B. TARA nach ISO/SAE 21434) bewertet potenzielle Angriffe auf Safety-Funktionen und legt geeignete Schutzniveaus (z. B. CAL) fest, um deren Verfügbarkeit und Integrität zu gewährleisten. Damit bleibt der Safety-Nachweis methodisch konsistent, während der Security-Layer den notwendigen Schutz gegen Angriffe bereitstellt. 
Für //Safety-relevant Services// (z.B. Rettungsdienste, Feuerwehren, medizinische Versorgung), die von der Verfügbarkeit kritischer Infrastrukturen abhängen können, gilt Ähnliches. Security-Maßnahmen an den Infrastrukturen müssen diese Risiken berücksichtigen und einhegen, soweit möglich. Wo Security-Maßnahmen wenig Wirkung zeigen, können z. B. Resilienz-Maßnahmen Risiken reduzieren ([[https://safetyandsecurity.vdi.de/content:hauptseite#resilienz|siehe Abschnitt 5.2]]).
 
Besondere Herausforderung bei der Auslegung von Security-Funktionen ergeben sich bei Designwechselwirkungen mit Safety-Funktionen aufgrund widersprüchlicher Anforderungen (//Conflicting Requirements//) - siehe dazu Abschnitt 3.  

Damit wird der dreigliedrige Risikobegriff zur gemeinsamen Grundlage für die Gestaltung von Maßnahmen in beiden Domänen. Er erlaubt, Angriffswirkungen systematisch abzubilden und in die Bewertung einzubeziehen. Designwechselwirkungen zwischen Safety- und Security-Maßnahmen werden ebenfalls systematisch abgebildet. Eine semi-quantitative oder sogar quantitative Bewertung von Designwechselwirkungen (siehe Abschnitte 3.2, 3.3, 3.4) im Sinne einer Abwägung wird in aller Regel aber nicht möglich sein, da für eine Risikoabwägung regelmäßig das Gesamtrisiko auf Seiten von Safety sowie Security in die Bewertung einfließen muss und die Bewertungsmetriken nicht in allen Beiträgen (Threat, Vulnerability, Impact) direkt vergleichbar oder sogar quantifizierbar sein werden.
===== 2.2 Begriff: Safety =====

Safety-Risiken im Sinne dieser Dokumentation beziehen sich auf Risiken, die von technischen Systemen ausgehen und Menschen, Umwelt, Sachwerte oder Infrastruktur gefährden können. Sie entstehen typischerweise infolge technischer Fehler, Komponentenausfälle oder unbeabsichtigter menschlicher Fehlhandlungen, etwa durch Fehlbedienung oder unzureichende Wartung.

Ein wesentliches Merkmal von Safety-Risiken ist, dass sie aus unbeabsichtigten Ereignissen resultieren, deren Eintrittshäufigkeit auf Erfahrungswerten basierend abgeschätzt werden kann. Diese Abschätzung erfolgt in der Regel qualitativ oder semi-quantitativ, um sicherheitsrelevante Szenarien zu identifizieren und das erforderliche Sicherheitsniveau festzulegen. Typische Verfahren sind HAZOP, FMEA, Risikographen oder HARA.

In späteren Nachweisphasen werden diese Bewertungen ggf. durch quantitative Modelle ergänzt, die auf Fehlerraten oder Wahrscheinlichkeitsberechnungen basieren. Solche Verfahren dienen dem rechnerischen Nachweis, dass die geforderte Risikominderung erreicht wird. Die im Rahmen der funktionalen Sicherheit hierfür zulässigen quantitativen Nachweisverfahren sowie die anzuwendenden Grenzwerte für Ausfallwahrscheinlichkeiten sind in den Normen der funktionalen Sicherheit explizit festgelegt, beispielsweise in IEC 61508, ISO 26262, IEC 61511 oder EN ISO 13849.

Typischerweise erfolgt die Bewertung in zwei Stufen:

Gefährdungsanalyse (z. B. Risikograph, HARA, HAZOP, FMEA), die die Safety-relevanten Szenarien identifiziert, qualitativ bewertet und klassifiziert.

Nachweis der Wirksamkeit und Verfügbarkeit von Maßnahmen (z. B. über SIL- oder ASIL-Kategorien), mit dem belegt wird, dass das Risiko durch technische oder organisatorische Schutzfunktionen auf ein vertretbares Maß reduziert ist.

Die zu ergreifenden Maßnahmen – zumeist technischer Natur – zielen darauf ab, die Wahrscheinlichkeit des Eintritts eines Safety-relevanten 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 im hier betrachteten Kontext ist in aller Regel, die Verfügbarkeit, Integrität und Vertraulichkeit technischer Systeme zu schützen, in manchen Szenarien kann aber auch der Schutz von Menschenleben oder körperlicher Unversehrtheit betroffen sein. 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 Bewertung von Maßnahmen oft quantitativ erfolgt, dominieren im Bereich der IT-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. In der physischen Sicherheit können Vulnerabilitäten quantitativ ermittelt werden (z. B. EASI-Modell).

Die zunehmende digitale Vernetzung technischer Systeme hat zur Folge, dass Security-Risiken zunehmend auch Safety-relevante 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 (Security Impact on 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 Risikobasierte Modelle =====

Risikobasierte Modelle sind vielseitige Werkzeuge zur Analyse komplexer Systeme. Sie bilden die logische Struktur ab, in der Risiken entstehen, bewertet und gegeneinander abgewogen werden können. **Der Begriff Modell wird hier im erweiterten Sinn verwendet und umfasst sowohl modellhafte Darstellungen – etwa strukturierte Beschreibungen von Ursachen, Zuständen und Auswirkungen – als auch methodische Verfahren, die solche Modelle zur Risikoanalyse und Entscheidungsunterstützung praktisch anwenden.**

Risikobasierte Modelle ermöglichen es insbesondere, verschiedene Szenarien vergleichbar zu machen und dadurch Entscheidungsprozesse zu erleichtern. Auf diese Weise lassen sich Risiken gegeneinander abwägen und Maßnahmen priorisieren – ein Aspekt, der gerade bei begrenzten Ressourcen und konkurrierenden Schutzstrategien von hoher Bedeutung ist.

Darauf aufbauend unterscheiden sich die Modelllandschaften in Safety und Security, die im Folgenden zusammengefasst werden.

==== 2.5.1 Safety-orientierte Modelle ====

  * **FMEA/FMECA**: qualitative und semi-quantitative Analyse möglicher Fehlerarten und ihrer Auswirkungen.
  * **Risk Graphs (IEC 61508, ISO 26262)**: semiquantitative Ableitung von Sicherheitsanforderungen (SIL, ASIL) aus Schweregrad, Exposition und Kontrollierbarkeit.
  * **RAMS-Ansätze (z. B. EN 50126, VDI 4001ff.)**: integrierte Betrachtung von Zuverlässigkeit, Verfügbarkeit, Instandhaltbarkeit und Sicherheit.
  * **Reliability Block Diagrams (RBD) und Markov-Modelle**: quantitative Bewertung von Verfügbarkeit, Redundanz und Zustandsübergängen.
  * **Probabilistische Sicherheitsanalysen (PSA/PRA, IAEA)**: Ereignis- und Fehlerbäume, Level 1–3. Im Level-1 liegt der Fokus auf der Ermittlung von Eintrittswahrscheinlichkeiten bis hin zu Kernschäden (d. h. einer schweren Schädigung des Reaktorkerns durch Verlust von Kühlung oder Reaktivitätskontrolle). Level-2 betrachtet die Freisetzung radioaktiver Stoffe, Level-3 deren Auswirkungen auf Bevölkerung und Umwelt.
==== 2.5.2 Security-orientierte Modelle ====

  * **Attack Trees und Attack Graphs**: Darstellung möglicher Angriffspfade, vielfach im IT- und OT-Sicherheitsumfeld etabliert.
  * **Kill Chain / MITRE ATT&CK**: Sequenzmodelle zur Abbildung von Angriffsphasen.
  * **Threat Analysis and Risk Assessment (TARA, ISO/SAE 21434)**: automotive-spezifisches Vorgehen zur Bedrohungsanalyse.
  * **Common Vulnerability Scoring System (CVSS)**: Bewertungsskala für Schwachstellen, häufig für IT- und OT-Umgebungen.
  * **VDI/VDE 2182-Reihe**: Vorgehensmodelle und Anwendungsbeispiele für Security in der industriellen Automatisierung.
==== 2.5.3 Integrierte und hybride Modelle ====

  * **Bow-Tie-Modelle**: Verbindung von Ursachen (Safety: technisches Versagen; Security: Angriff) und Barrieren mit möglichen Folgen.
  * **Bayes’sche Netze**: probabilistische Modellierung, geeignet zur Integration unsicherer und gemischter Ursachen.
  * **HARM (Hierarchical Attack Representation Model)**: Verknüpfung von Attack Trees und Safety-Analysen.
  * **Resilience-Ansätze**: Fokus auf Anpassungsfähigkeit, Wiederanlauf und Robustheit jenseits rein probabilistischer Bewertungen.
==== 2.5.4 Herausforderungen ====

  * **Quantitativ vs. qualitativ**: Safety-Analysen basieren auf umfangreichen Zuverlässigkeitsdaten, während Security-Analysen oft auf schwer quantifizierbaren Szenarien beruhen.
  * **Unsicherheiten**: Epistemische Unsicherheiten (fehlende Daten) und die Koinzidenz von Angriffen mit Safety-relevanten Ereignissen sind methodisch schwer fassbar.
  * **Domänenspezifik**: Je nach Branche (z. B. Luftfahrt, Automotive, Kerntechnik, KRITIS) kommen unterschiedliche Standards und Modellansätze zum Einsatz.
==== 2.5.5 Referenzen und einschlägige Standards ====

^**Richtlinie** ^**Kommentar** |
|**Safety-orientierte Standards und Richtlinien** |   |
|IEC 61508|Funktionale Sicherheit sicherheitsbezogener Systeme|
|IEC 61511 / VDI/VDE 2180|Funktionale Sicherheit in der Prozessindustrie|
|ISO 26262|Road vehicles – Functional safety (Titel)|
|EN 50126 / EN 50129 (RAMS)|Railway Applications|
|IAEA Safety Standards (SSR-4, SSG-3, SSG-4)|Grundlagen der probabilistischen Sicherheitsanalyse (PSA)|
|**Security-orientierte Standards und Richtlinien** |   |
|ISO/SAE 21434|Road vehicles – Cybersecurity engineering (Titel)|
|Common Vulnerability Scoring System (CVSS)|Bewertung von IT-Schwachstellen|
|NIST SP 800-30|Guide for Conducting Risk Assessments (IT Security)|
|ED-203A (EUROCAE)|Security Risk Assessment in der Luftfahrt|
|VDI/VDE 2182-Reihe|Informationssicherheit in der industriellen Automatisierung|
|**Hybride und integrierte Ansätze** |   |
|Bow-Tie-Methodik|In verschiedenen Normen und Richtlinien genutzt|
|Bayes’sche Netze|Probabilistische Modellierung für kombinierte Safety- und Security-Ursachen|
|HARM (Hierarchical Attack Representation Model)|Verknüpfung von Attack Trees und Safety-Modellen|
|Resilience-Engineering-Ansätze|Z. B. nach Erik Hollnagel, VDI 4004 im weiteren Umfeld|

====== 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. Safety-Funktionen 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. Angriffe – insbesondere IT-basierte, aber auch physische – können safety-relevante Funktionen direkt beeinträchtigen.

Die Auswirkung von Angriffen auf Safety-Funktionen (Security Impact on Safety - siehe Bild 2.1) ist konstituierend für die gemeinsame Betrachtung von Safety und Security. Erst die Möglichkeit, dass Angriffe und Security-Schwachstellen die Wirksamkeit bzw. Verfügbarkeit (Availability) von Safety-Funktionen beeinträchtigen, macht eine integrierte Analyse erforderlich. Ähnliches gilt für Anforderungen an die Verfügbarkeit kritischer Infrastrukturen, von denen viele safety-relevante Prozesse abhängen können.

Bei der Gestaltung von Safety- und Security-Funktionen können widersprüchliche Anforderungen (conflicting requirements - siehe Bild 2.1) auftreten. Die designrelevanten Wechselwirkungen von Safety- und Security-Maßnahmen lassen sich in vier Kategorien einteilen (Tabelle 3.1).

*Tabelle 3.1: Kategorien designrelevanter Wechselwirkungen*

^Kategorie^Beziehungsart der Anforderungen^Design-Wechselwirkung^Richtung der Beeinflussung^Beispielhafte Anwendung^Lösungsbeispiel|
|1|kohärent oder konsistent|nein|keine|Firewall beschränkt Wartungszugriff|parallele Auslegung von Safety & Security|
|2|widersprüchlich|ja|Security → Safety (unidirektional)|IT-Security-Maßnahme verzögert Safety-Funktion|Priorisierung Safety, szenarienabhängige Umschaltungen|
|3|widersprüchlich|ja|Safety → Security (unidirektional)|Safety-Freigabe verhindert Zutrittsbeschränkung|Zeitbegrenzung, szenarienabhängige Freigaben|
|4|widersprüchlich|ja|Safety ⇆ Security (bidirektional)|Gebäudetüren: Fluchtweg vs. Zutrittsbeschränkung|richtungsabhängige Entkopplung: Pushbar, Panikschloss|


==== Methodische Herausforderungen bei der gemeinsamen Bewertung ====

Eine zentrale Herausforderung bei der integrierten Betrachtung von Safety und Security liegt in den unterschiedlichen Bewertungslogiken und den in aller Regel nicht direkt vergleichbaren Metriken der beiden Domänen.

  * **Safety:**  Die Risikobewertung erfolgt meist qualitativ oder semiquantitativ (z. B. SIL nach IEC 61508, ASIL nach ISO 26262). Der Nachweis der Verfügbarkeit von Sicherheitsfunktionen (hardwarebezogen) basiert überwiegend auf probabilistischen Methoden und quantitativen Nachweisen.
  * **Security:**  Die Risikobewertung erfolgt in der Regel qualitativ oder semiquantitativ, insbesondere in der IT-Security (z. B. TARA nach ISO/SAE 21434, CVSS, IEC 62443, NIST SP 800-30, BSI 200-3). Eintrittswahrscheinlichkeiten lassen sich hier aufgrund der Willensbildung von Angreifern kaum probabilistisch erfassen, sie bleiben epistemisch unsicher. In der physischen Sicherheit lassen sich zumindest Verwundbarkeiten über quantitative Verfahren beschreiben.
Daraus folgt: Eine direkte risikobasierte Abwägung zwischen Safety- und Security-Maßnahmen, insbesondere bei widersprüchlichen Anforderungen, ist grundsätzlich nur eingeschränkt möglich. Diese methodische Einschränkung betrifft Kategorien 2, 3 und 4 und bildet den Rahmen für die nachfolgenden Abschnitte (3.1 – 3.4) in denen die Kategorien im Detail erläutert und anhand von Beispielen sowie Lösungsansätzen vertieft werden. Sonderfälle, die über diese Systematik hinausgehen – etwa disruptive und hybride Angriffe – werden in Abschnitt 3.5 behandelt.

===== 3.1 Consistent/Coherent Safety-Security Requirements =====

Diese Kategorie umfasst Konstellationen, in denen Anforderungen aus Safety und Security kohärent oder konsistent sind – es bestehen keine widersprüchlichen Ziele. Sicherheitsmaßnahmen beider Domänen können in diesem Fall unabhängig nebeneinander ausgelegt werden.

**Beispiele:**

  * Generisch: Firewall-beschränkter Wartungszugriff, bei dem Remote-Zugänge zu Steuerungen z. B. nur über definierte Ports und autorisierte IP-Adressen erlaubt sind. Diese Maßnahme erhöht die Security, ohne die Wirksamkeit der Safety-Funktionen zu beeinflussen.
  * KRITIS: An kritischen Energieinfrastrukturen, etwa Umspannwerken, werden Videoüberwachungssysteme eingesetzt, die zugleich Angriffserkennung (Security) und Gefahrenprävention (Safety) leisten. Das System detektiert unbefugten Zutritt oder Vandalismus und erkennt zugleich, wenn sich Personen in gefährliche Zonen begeben. Über Lautsprecher können Warnhinweise oder direkte Ansprachen ausgelöst werden, um Unfälle oder ggf. Straftaten zu verhindern. Beide Zielsetzungen – Schutz vor Angriffen und Schutz von Personen – wirken kohärent und erhöhen gemeinsam die Gesamtsicherheit der Anlage.

**Lösungsansatz:**  Da keine widersprüchlichen Anforderungen bestehen, können Sicherheitsmaßnahmen für Safety und Security unabhängig voneinander ausgelegt werden. Voraussetzung ist, dass mögliche Angriffswirkungen auf Safety-Funktionen in der jeweiligen Security-Risikoanalyse berücksichtigt werden – sei es im Rahmen einer TARA (Automotive) oder anderer etablierter Verfahren wie ISO/IEC 27005, NIST SP 800-30, BSI-200-3 oder IEC 62443. In diesem Fall können auch die Sicherheitsmetriken getrennt geführt werden (z. B. SIL/ASIL für Safety, CVSS oder Security Level für Security).

===== 3.2 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 beeinträchtigen. Diese Wechselwirkung ist unidirektional: Maßnahmen oder Vorgaben aus der Security-Domäne wirken sich negativ auf Safety-Funktionen aus.

**Beispiele:**

  * Generisch: Zwei-Faktor-Authentifizierung verlangsamt die Bedienung eines Notfall-Systems.
  * KRITIS: IT-Sicherheitsmaßnahmen in Kommunikationsnetzen (z. B. Firewalls, Verschlüsselung) beeinträchtigen unter Störbedingungen die Safety-relevante Kommunikation.

Typische Szenarien:

  * Verzögerung sicherheitskritischer Aktionen durch Authentifizierung: Strenge Zugriffskontrollen (z. B. PIN, Token, Zwei-Faktor) können im Notfall wertvolle Zeit kosten.
  * Sicherheitsupdates beeinträchtigen Safety-Verfügbarkeit: Software-Updates zur Schließung von Security-Lücken können Neustarts oder temporäre Ausfälle sicherheitskritischer Systeme erzwingen.
  * Netzwerksegmentierung unterbricht Safety-Kommunikation: Strikte Trennung von Netzwerken aus Security-Gründen kann die Kommunikation verteilter Safety-Funktionen behindern.
  * Verschlüsselung verursacht Verzögerung oder Datenverlust: Safety-relevante Datenströme, die verschlüsselt übertragen werden, können durch Latenzen oder Inkompatibilitäten beeinträchtigt werden.
  * IT-/TK-Infrastrukturen: Firewalls oder Verschlüsselungstechnologien in Kommunikationsnetzen können im Störfall die Echtzeitfähigkeit sicherheitsrelevanter Kommunikation beeinträchtigen.

**Lösungsansatz:**  Grundsätzlich ist der Schutz von Menschenleben (in aller Regel durch Safety-Maßnahmen) höher zu priorisieren als der Schutz technischer Systeme oder Daten (worauf sich Security-Maßnahmen meist beschränken). In Fällen von widersprüchlichen Anforderungen sind Einzelfallentscheidungen erforderlich, um Konflikte aufzulösen.

Mögliche Maßnahmen (generisch) umfassen:

  * szenarienabhängige Umschaltungen (z.B. Notfall-Betriebsmodi),
  * technische Bypass-Mechanismen für Notfälle,
  * intelligente Fail-Safe-Strategien,
  * Priorisierung sicherheitskritischer Kommunikation in Netzwerken,
  * abgestimmte Update-Strategien.

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

In dieser Kategorie beeinflussen Anforderungen oder Maßnahmen aus dem Bereich Safety die Ausgestaltung und Wirksamkeit von Security-Maßnahmen. Die Wechselwirkung ist unidirektional: Vorgaben aus der Safety-Domäne können Security-Maßnahmen schwächen oder umgehen.

**Beispiele:**

  * Physische Sicherheit: Brandschutz (Safety: automatische Türentriegelung im Brandfall) untergräbt Zutrittsbeschränkung (Security).
  * Flughäfen: Notöffnung (Safety) von Sicherheitstüren untergräbt Zutrittskontrolle (Security) in den Sicherheitsbereich. Unberechtigte Betätigungen von Nottastern führen ggf. zu Evakuierung des Sicherheitsbereichs und erneuter Kontrolle aller Passagiere.
  * Umspannstation - Stromnetz: Bei Eindringen Unbefugter kann die Polizei als Interventionskraft (Security) die Anlage nicht ohne Sicherheitseinweisung (Safety) bzw. Begleitung geschulten Personals betreten.   
  * Generisch: Ein frei zugänglicher Not-Aus-Schalter kann Sicherheitsmechanismen umgehen und so eine potenzielle Security-Schwachstelle darstellen.

Typische Szenarien:

  * Notöffnungen vs. Zugangsschutz: In der physischen Sicherheit besteht ein klassischer Konflikt zwischen Brandschutz (Türen müssen sich im Brandfall automatisch entriegeln, um Fluchtwege freizugeben) und Zutrittsbeschränkung (Türen sollen verschlossen bleiben, um unbefugten Zutritt zu verhindern).
  * Redundanzanforderungen: Safety-gerechte Entkopplung redundanter Systeme kann zentrale Security-Maßnahmen wie durchgängige Zugangskontrolle oder einheitliches Patch-Management behindern.
  * Bypass-Schaltungen für Diagnose oder Wartung: Aus Safety-Gründen erlaubte Bypass-Funktionen können potenzielle Security-Lücken darstellen, wenn sie nicht abgesichert sind.
  * Mensch-Maschine-Schnittstellen mit Safety-Fokus: Anforderungen an schnelle Bedienbarkeit (z. B. frei zugängliche Not-Aus-Schalter) können Zugriffskontrollen aushebeln.
  * Kommunikationspriorisierung: Safety-bezogene Datenpakete erhalten Vorrang in Echtzeitnetzwerken, wodurch Security-relevante Meldungen (z. B. Einbruchalarme) verzögert werden können.

**Lösungsansatz:**

Grundsätzlich gilt: Der Schutz von Menschenleben (in aller Regel durch Safety-Maßnahmen) hat Vorrang. Gleichzeitig ist zu vermeiden, dass Safety-Maßnahmen unbeabsichtigt gravierende Security-Lücken erzeugen.

Da es sich hierbei um widersprüchliche Anforderungen handelt, müssen Einzelfallentscheidungen getroffen werden, wie mit den Zielkonflikten umzugehen ist.

Mögliche Ansätze:

  * zeitlich begrenzte Umschaltungen (z. B. Türen entriegeln nur für definierte Zeitfenster im Brandfall),
  * szenarienabhängige Freigaben durch technische Logik (z.B. Brandalarm) oder direkte Ansprache bei Anforderung,
  * verstärkte Überwachung (z. B. Video, Sensorik) von Situationen, in denen Safety-Vorgaben Security umgehen können,
  * dokumentierte Risikoabwägungen und klare Regelungen, wann Safety-Vorgaben Security-Anforderungen temporär außer Kraft setzen dürfen.

===== 3.4 Contradicting Safety-Security Requirements =====

In dieser Kategorie bestehen widersprüchliche Anforderungen an Safety- und Security-Funktionen, die gleichzeitig nicht vollständig erfüllbar sind. Die Wechselwirkung ist bidirektional: Safety-Maßnahmen können Security behindern und umgekehrt. Solche Zielkonflikte sind besonders kritisch, da beide Schutzziele gleichwertig im Systemdesign berücksichtigt werden müssen.

**Beispiele:**

  * Physische Sicherheit: 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 (richtungsabhängig) zu entkoppeln. Flucht (von innen nach außen) ist dann immer möglich, während Eindringen (von außen nach innen) unterbunden wird.
  * Amok- und Terrorlagen: Aus Safety-Sicht müssen Fluchtwege jederzeit offenstehen, damit Menschen im Notfall das Gebäude verlassen können. Aus Security-Sicht erfordert der Schutz der Personen im Gebäude jedoch häufig einen Lockdown, bei dem Türen verschlossen bleiben, um Täter nicht hereinzulassen. In diesem Fall schützen Security-Maßnahmen Menschenleben und sind gleichrangig zu behandeln.
  * Luftfahrt: Ein besonders tragischer Fall eines ungelösten Zielkonflikts war der Absturz des Germanwings-Flugs 9525. Die Cockpittür ist gepanzert (Security) und nicht aufzubrechen. Im Notfall kann sie durch die Crew 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.

**Lösungsansatz:**

Wechselseitig (bidirektional) widersprüchliche Anforderungen erfordern besonders sorgfältige Abwägungen, da Safety und Security hier in beide Richtungen im Konflikt stehen und ggf. auch beide den Schutz von Menschenleben betreffen. Ein rein technischer Vergleich der Risiken ist kaum möglich, weil epistemische Unsicherheiten bei Angriffen ein systematisches Abwägen von Risiken extrem erschweren.

Grundsätzlich gilt:

  * In einfacheren Szenarien können technische Lösungen wie richtungsabhängige Entkopplung (Panikschlösser, Pushbars, Anti-Amok-Schlösser) oder szenarienabhängige Umschaltungen (z. B. unterschiedliche Türsteuerung bei Feueralarm vs. Einbruchsfall) eine grundsätzliche Konfliktauflösung ermöglichen.
  * In komplexeren Szenarien (z. B. Luftfahrt) sind Einzelfallentscheidungen erforderlich, bei denen technische, ethische, gesellschaftliche und regulatorische Kriterien sorgfältig abzuwägen sind.

Mögliche Lösungsansätze:

  * technische Lösungen zur richtungsgebundenen Entkopplung wie Panikschlösser, Pushbars, Anti-Amok-Schlösser
  * szenarienabhängige Umschaltungen (z. B. Türen verhalten sich unterschiedlich bei Feueralarm vs. Einbruchsfall)
  * verstärkte Überwachung (z. B. Video, Sensorik) in Umschaltszenarien
  * dokumentierte Risikoabwägungen, die explizit begründen, wie widersprüchliche Anforderungen priorisiert oder kombiniert werden

===== 3.5 Sonderfälle =====

Es gibt Szenarien, die sich aufgrund der Schwere der Auswirkungen von den Lösungsansätzen her nicht in die dargestellte Systematik einordnen lassen. Diese Sonderfälle entstehen zum Beispiel durch disruptive Angriffe oder hybride Bedrohungen und werden hier nur exemplarisch behandelt. Sie erfordern eine gesonderte Betrachtung, da klassische Maßnahmen und Lösungsansätze meist nicht ausreichen.

**Disruptive Angriffe:**

Disruptive Angriffe können ganze Systemarchitekturen unterlaufen und sicherheitsrelevante Funktionen großflächig beeinträchtigen oder außer Kraft setzen. Die Frage nach einem angemessenen Schutzniveau, das etwa zwischen Safety und Security abzuwägen wäre, stellt sich damit nicht mehr. Beispiele sind:

  * Drohnenangriffe, die klassische Maßnahmen des Perimeterschutzes, wie z. B. Zäune und andere Barrieren überfliegen oder umgehen. Durch derartige Angriffe werden die bodengebundenen Maßnahmen der physischen Sicherheitsarchitektur außer Kraft gesetzt. Mittlerweile wird z. B. häufiger bei Sichtung von Drohnen der Flugbetrieb auf Flughäfen komplett eingestellt. Es mangelt an geeigneten zivilen Abwehrmaßnahmen.
  * (Physische) Angriffe (ggf. koordiniert) auf Netzknoten in Strom- oder Kommunikationsnetzen, die sehr weitreichende und ggf. länger andauernde Ausfälle verursachen können. Die hohe Interkonnektivität moderner Systeme führt dazu, dass lokale Ereignisse globale Wirkungen entfalten können.

**Hybride Szenarien:**

In manchen Fällen treten natürliche Gefährdungen (Safety) und gezielte Angriffe (Security) gleichzeitig auf oder verstärken sich gegenseitig. Beispiele sind:

  * Ein Stromausfall durch Naturereignis, der gezielt für einen IT-Angriff ausgenutzt wird.
  * Flutereignisse, die kritische Infrastrukturen schwächen und gleichzeitig Angriffsgelegenheiten eröffnen.

Solche Szenarien erhöhen die Komplexität der Risikobewertung erheblich, da sich Ursachen und Wirkungen überlagern und Unsicherheiten zunehmen.

**Lösungsansatz:**

Sonderfälle erfordern erweiterte Schutzstrategien, die über etablierte Kategorien hinausgehen:

  * Resilienzorientierte Konzepte, die auf Anpassungsfähigkeit, Wiederanlauf und Robustheit setzen.

<html> <a id="funktionale-sicherheit"></a> </html>

  * Neuartige Sicherheits- und Abwehrmaßnahmen, wenn Bedrohungen klassische Paradigmen überwinden (z. B. Drohnenabwehr, KI-gestützte Analysen).

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

Die Funktionale Sicherheit ist ein zentraler Bestandteil der technischen Sicherheit von Systemen. Für den Bereich Maschinen und Anlagen bezieht sie 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 Bild 4.1).

{{  https://safetyandsecurity.vdi.de/_media/content:fusi_abbildung_1.svg?direct&400x227  }}

Bild 4.1: Risiko als Funktion von Schadensausmaß und Eintrittswahrscheinlichkeit (Quelle: VDI-EE 4020: Einführung in die Funktionale Sicherheit)

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. Ein gutes Beispiel dafür ist ein Not-Ausschalter.

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 (Bild 4.2). Diese Fehler oder Ausfälle können jeweils zu einem Versagen der Sicherheitsfunktion führen.

{{  https://safetyandsecurity.vdi.de/_media/content:fusi_abbildung_2.svg?direct&500x134  }}

Bild 4.2: Systematische Fehler und zufällige Ausfälle (Quelle: VDI-EE 4020: Einführung in die Funktionale Sicherheit)

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 (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 (Bild 4.3).

{{  https://safetyandsecurity.vdi.de/_media/content:fusi_abbildung_3.svg?direct&500x292  }}

Bild 4.3: V-Modell für den Software-Entwicklungsprozess nach IEC 61508 (Quelle: VDI-EE 4020: Einführung in die Funktionale Sicherheit)

Als Maß für die Zuverlässigkeit sicherheitsbezogener Systeme bei der Ausführung 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.

Tabelle 4.1 gibt ein Beispiel einer Tabelle mit Maßnahmen zur Vermeidung von systematischen Fehlern.

Tabelle 4.1: Beispiel einer Maßnahmen-Tabelle der IEC 61508


^Nr.  ^Technique/Measure *  ^Ref.  ^SIL 1^SIL 2^SIL 3^SIL 4|
|1a  |Semiformale Methoden  |Table B.7  |R  |R  |HR  |HR  |
|1b  |Formale Methoden  |B.2.2, C.2.4  |—  |R  |R  |HR  |
|2  |Vorwärtsverfolgbarkeit von den Anforderungen an die Sicherheit des Systems zu den Anforderungen an die Sicherheit der Software|C.2.11  |R  |R  |HR  |HR  |
|3  |Rückwärtsverfolgbarkeit von den Anforderungen an die Sicherheit zu den wahrgenommenen Sicherheitsbedürfnissen|C.2.11  |R  |R  |HR  |HR  |
|4  |Rechnergestützte Spezifikationswerkzeuge, die die obigen Verfahren/Maßnahmen angemessen unterstützen  |B.2.4  |R  |R  |HR  |HR  |


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

{{  https://safetyandsecurity.vdi.de/_media/content:fusi_abbildung_4.svg?direct&500x228  }}

Bild 4.4: Hardware-Struktur einer Sicherheitsfunktion (Quelle: VDI-EE 4020: Einführung in die Funktionale Sicherheit)

Die Funktion besteht aus zwei Kanälen, welche jeweils aus den folgenden Komponenten bestehen:

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

{{  https://safetyandsecurity.vdi.de/_media/content:fusi_abbildung_5.svg?direct&500x266  }}

Bild 4.5: Von der IEC 61508 abgeleitete Safety-Normen (Quelle: VDI-EE 4020: Einführung in die Funktionale Sicherheit)

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

  * DIN EN 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 ======

<html> <a id="it_security"></a> </html> 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-Security 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-Security 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“**. <html> <a id="resilience"></a> </html>

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

  * **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-Security 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-Security-Risiken 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“**. <html> <a id="ethik"></a> </html>

++++ 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“**. <html> <a id="leitfragen"></a> </html>

++++ 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 ([[https://safetyandsecurity.vdi.de/content:hauptseite#anwendungsfelderdisziplinen|siehe Abschnitt 1.3]]) 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?**  <html> <a id="vdi-richtlinien"></a> </html> 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 VDI-Richtlinien mit Bezug zu Safety und Security (Auszug) ======

Diese Übersicht ist als auszugsweise Gesamtschau relevanter VDI-Richtlinien zu sehen, die einen Bezug zu Safety und Security haben, einschließlich solcher mit spezifischem Anwendungsbezug (z. B. Ladungssicherung, Gebäudetechnik). Weitere VDI-Richtlinien mit konkretem Bezug zu den jeweiligen Disziplinen finden sich [[:content:hauptseite#anwendungsfelderdisziplinen|ebenda]]

^Richtlinie^Kommentar|
| [[https://www.dinmedia.de/en/technical-rule/vdi-vde-2180-blatt-1/303375924|VDI/VDE 2180 Blatt 1]] / [[https://www.dinmedia.de/en/technical-rule/vdi-vde-2180-blatt-2/306164093|Blatt 2]] / [[https://www.dinmedia.de/en/technical-rule/vdi-vde-2180-blatt-3/306163771|Blatt 3]] / [[https://www.dinmedia.de/en/technical-rule/vdi-vde-2180-blatt-4/331294578|Blatt 4]] | Funktionale Sicherheit in der Prozessindustrie; Grundlage IEC 61511. |
| [[https://www.dinmedia.de/de/technische-regel/vdi-ee-4020/378351818|VDI-EE 4020 (2024)]] | Einführung in die Funktionale Sicherheit nach IEC 61508; domänenübergreifende Basisnorm. |
| [[https://www.dinmedia.de/en/technical-rule/vdi-2510-blatt-2/353761577|VDI 2510 Blatt 2 (2022)]] | Fahrerlose Transportsysteme, sicherheitstechnische Anforderungen; Automotive/Logistik. |
| [[https://www.dinmedia.de/de/technische-regel/vdi-2700/76329774|VDI 2700 Reihe (ab 2014)]] | Ladungssicherung im Transportwesen; klassisches Safety-Thema (Infrastruktur/Transport). |
| [[https://www.dinmedia.de/en/draft-technical-rule/vdi-4062-blatt-1/376568444|VDI 4062 Blatt 1 (Entwurf 2024)]] | Evakuierung von Personen; Safety und Resilienz im Personenfluss. |
| [[https://www.dinmedia.de/en/technical-rule/vdi-6010-blatt-2/355808073|VDI 6010 Blatt 2 (2022)]] | Sicherheitstechnische Anlagen im Gebäude (Brandfallsteuerungen). |
| [[https://www.dinmedia.de/en/technical-rule/vdi-vde-2182-blatt-1/314114388|VDI/VDE 2182 Blatt 1]] / [[https://www.dinmedia.de/en/technical-rule/vdi-vde-2182-blatt-2-1/170847294|2.1]] / [[https://www.dinmedia.de/en/technical-rule/vdi-vde-2182-blatt-2-2/173513663|2.2]] / [[https://www.dinmedia.de/en/technical-rule/vdi-vde-2182-blatt-2-3/267500528|2.3]] / [[https://www.dinmedia.de/en/technical-rule/vdi-vde-2182-blatt-3-1/187310424|3.1]] / [[https://www.dinmedia.de/en/technical-rule/vdi-vde-2182-blatt-3-2/167996669|3.2]] / [[https://www.dinmedia.de/en/technical-rule/vdi-vde-2182-blatt-4/319538752|4]] | Informationssicherheit in der industriellen Automatisierung; zentrale Security-Reihe. |
| [[https://www.dinmedia.de/en/technical-rule/vdi-vde-3516-blatt-1/188604553|VDI/VDE 3516 Blatt 1 (2013)]] | Validierung von Open-Source-Software im GxP-Umfeld; Security/Safety-Schnittstelle Softwarequalität. |
| [[https://www.dinmedia.de/en/technical-rule/vdi-vde-4004-blatt-1/348409377|VDI/VDE 4004 Blatt 1 (2022/2024 Update)]] | Testen vernetzter I4.0-Systeme; Reliability- und Security-Schnittstellen. |
| [[https://www.dinmedia.de/en/technical-rule/vdi-4002-blatt-2/144627727|VDI 4002 Blatt 2 (2011)]] | Qualifizierung von Zuverlässigkeitsingenieur:innen; Schnittstelle Safety/Security-Kompetenz. |
| [[https://www.dinmedia.de/en/technical-rule/vdi-ee-5702-blatt-3/378351845|VDI-EE 5702 Blatt 3 (2024)]] | Medical SPICE für Medizinprodukte-Software; Schnittstelle Safety, Security, Softwarequalität. |
| [[https://www.dinmedia.de/de/technische-regel/vdi-3780/32141408|VDI 3780 (2024)]] | Technikbewertung: Grundlagen & Begriffe; Orientierungsrahmen für Risiko, Bewertung, Ethik. |


====== 8. Fachausschuss Team ======

In diesem Abschnitt stellen wir die Mitglieder des Fachausschusses vor, die mit großem Engagement an der Arbeit rund um Safety & Security mitgewirkt haben. Besonderer Dank gilt dem Vorsitzenden sowie der VDI-Begleitung, die die inhaltliche und organisatorische Leitung übernehmen.

----

===== Vorsitzender =====

**Prof. Dr.-Ing. Kai-Dietrich Wolf**

Fakultät für Maschinenbau und Sicherheitstechnik

Institut für Sicherungssysteme, Bergische Universität Wuppertal

----

===== VDI-Begleitung =====

**Dr. Andreas Herrmann**

Verein Deutscher Ingenieure (VDI)

----

===== Fachausschuss-Mitglieder =====

Die folgenden Personen wirken ehrenamtlich im Fachausschuss mit:

^Nachname  ^Vorname  ^Titel  ^Firma  |
|Assaf  |Katja  |   |Hasso-Plattner-Institut  |
|Banse  |Gerhard  |Prof. Dr. Prof. e.h  |ehemals Karlsruher Institut für Technologie  |
|Bühler  |Cornelia  |   |TÜV SÜD Industrie Service GmbH IS-ESR 2  |
|Iffländer  |Lukas  |Prof. Dr.  |Hochschule für Technik und Wirtschaft Dresden  |
|Isermann  |Jan  |Dr.-Ing.  |TKMS ATLAS ELEKTRONIK GmbH  |
|Jopen  |Manuela  |Dr.  |GRS gGmbh, Köln  |
|Jung  |Norbert  |Prof. Dr.-Ing.  |Hochschule Bonn-Rhein-Sieg Institut für Sicherheitsforschung  |
|Keller  |Hubert B.  |Dr.  |ci-tec GmbH  |
|Kiank  |Stephan  |Dipl.-Ing.  |ZF Active Safety GmbH  |
|Kriso  |Stefan  |Dipl.-Phys.  |Robert Bosch GmbH  |
|Lichte  |Daniel  |Dr.  |Deutsches Zentrum für Luft- und Raumfahrt  |
|Meier  |David  |M.Sc.  |Fraunhofer-Institut für Optronik, Systemtechnik und Bildauswertung  |
|Pelzl  |Jan  |Prof. Dr.  |Hochschule Hamm-Lippstadt  |
|Pinnow  |Dirk  |Dipl.-Ing.  |PINNOW & Partner GmbH  |
|Ramírez-Agudelo  |Oscar H.  |Dr.  |Deutsches Zentrum für Luft- und Raumfahrt  |
|Roos  |Johannes  |Consultant  |Tuomi  |
|Sauer  |Jochen  |   |axis BERATUNGSGRUPPE  |
|Schepers  |David  |Prof. Dr.  |Hochschule Ruhr West - Institut Naturwissenschaften  |
|Schlummer  |Marco  |Dr.-Ing.  |Institut für Qualitäts- und Zuverlässigkeitsmanagement GmbH  |
|Schulz-Forberg  |Bernd  |Dr.-Ing.  |   |
|Sill Torres  |Frank  |Dr.-Ing. habil.  |Deutsches Zentrum für Luft- und Raumfahrt  |
|Termin  |Thomas  |Dr.-Ing.  |WITTE Automotive  |
|Zeh  |Martin  |Dipl.-Ing. (FH)  |SGS-TÜV Saar GmbH  |

----

===== Hinweis =====

Die Liste wird fortlaufend aktualisiert, sobald weitere Mitglieder benannt oder Änderungen erfolgen.