Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
| content:test [2025/09/18 17:02] – [2.1 Begriff: Risiko] approve | content:test [2025/12/08 10:25] (aktuell) – alte Version wiederhergestellt (2025/11/24 16:44) droste | ||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| ====== 1. Einleitung & Motivation ====== | ====== 1. Einleitung & Motivation ====== | ||
| + | |||
| + | < | ||
| ===== 1.1 Zielsetzung des Wikis ===== | ===== 1.1 Zielsetzung des Wikis ===== | ||
| Zeile 25: | Zeile 27: | ||
| ====== 1.3 Disziplinen ====== | ====== 1.3 Disziplinen ====== | ||
| - | In diesem Abschnitt finden Sie zentrale Anwendungsbereiche der gemeinsamen Betrachtung von Safety & Security. Jede Disziplin bringt eigene technische, normative und methodische Herausforderungen mit sich. Ziel des Wikis ist es, diese disziplinspezifisch zu beschreiben und vergleichbar zu machen – anhand definierter Kategorien, Bewertungsansätze und typischer Zielkonflikte. | + | In diesem Abschnitt finden Sie zentrale Anwendungsbereiche der gemeinsamen Betrachtung von Safety & Security. Jede Disziplin bringt eigene technische, normative und methodische Herausforderungen mit sich. Ziel des Wikis ist es, diese disziplinspezifisch zu beschreiben und vergleichbar zu machen – anhand definierter Kategorien, Bewertungsansätze und typischer Zielkonflikte. Klicken Sie auf einen der folgenden Links, um mehr zu erfahren: |
| - | Klicken Sie auf einen der folgenden Links, um mehr zu erfahren: | + | |
| * [[https:// | * [[https:// | ||
| Zeile 50: | Zeile 51: | ||
| * Im Bereich Security wird Risiko oft als Kombination von Bedrohung, Vulnerabilität und Auswirkung beschrieben. Die Bedrohungswahrscheinlichkeit selbst bleibt dabei meist unquantifiziert – stattdessen erfolgt eine qualitative Einschätzung unter Unsicherheiten. | * Im Bereich Security wird Risiko oft als Kombination von Bedrohung, Vulnerabilität und Auswirkung beschrieben. Die Bedrohungswahrscheinlichkeit selbst bleibt dabei meist unquantifiziert – stattdessen erfolgt eine qualitative Einschätzung unter Unsicherheiten. | ||
| - | {{:content:startseite4.svg? | + | {{:content:startseite5.svg? |
| - | Abbildung 1: Dreigliedrige Darstellung von Safety- und Security-Risiko | + | Abbildung 1: Dreigliedrige Darstellung von Safety- und Security-Risiko |
| Die zu ergreifenden Maßnahmen im Bereich Safety und Security – die hier in aller Regel technologischer Natur sind – sollen das Eintreten des sicherheitsrelevanten Ereignisses mit bestimmter Wahrscheinlichkeit verhindern, sei es im Fall einer äußeren Bedrohung (z. B. Angriff, Missbrauch) oder eines internen Elementarereignisses (z. B. Komponentenausfall, | Die zu ergreifenden Maßnahmen im Bereich Safety und Security – die hier in aller Regel technologischer Natur sind – sollen das Eintreten des sicherheitsrelevanten Ereignisses mit bestimmter Wahrscheinlichkeit verhindern, sei es im Fall einer äußeren Bedrohung (z. B. Angriff, Missbrauch) oder eines internen Elementarereignisses (z. B. Komponentenausfall, | ||
| Die Herausforderung einer gemeinsamen Betrachtung liegt in der methodischen Integration dieser beiden Perspektiven. Eine Möglichkeit besteht in einem dreigliedrigen Risikobegriff, | Die Herausforderung einer gemeinsamen Betrachtung liegt in der methodischen Integration dieser beiden Perspektiven. Eine Möglichkeit besteht in einem dreigliedrigen Risikobegriff, | ||
| - | |||
| ===== 2.2 Begriff: Safety ===== | ===== 2.2 Begriff: Safety ===== | ||
| - | Safety-Risiken im Sinne dieser Dokumentation beziehen sich auf Risiken, die durch technische Systeme ausgelöst werden und Menschen, Umwelt, Sachwerte oder Infrastruktur gefährden können. Sie entstehen typischerweise infolge technischer Fehler, Komponentenausfälle oder unbeabsichtigter menschlicher Fehlhandlungen, | + | Safety-Risiken im Sinne dieser Dokumentation beziehen sich auf Risiken, die durch technische Systeme ausgelöst werden und Menschen, Umwelt, Sachwerte oder Infrastruktur gefährden können. Sie entstehen typischerweise infolge technischer Fehler, Komponentenausfälle oder unbeabsichtigter menschlicher Fehlhandlungen, |
| Ein wesentliches Merkmal von Safety-Risiken ist, dass ihre Eintrittswahrscheinlichkeit auf Basis von Erfahrungswerten probabilistisch abgeschätzt werden kann. In vielen Disziplinen der Safety werden Eintrittswahrscheinlichkeiten und Wirkungsfolgen (z. B. Personen- oder Umweltschäden) quantitativ modelliert und als Grundlage für das Sicherheitsdesign herangezogen – etwa über Methoden wie Fehlerbaumanalyse, | Ein wesentliches Merkmal von Safety-Risiken ist, dass ihre Eintrittswahrscheinlichkeit auf Basis von Erfahrungswerten probabilistisch abgeschätzt werden kann. In vielen Disziplinen der Safety werden Eintrittswahrscheinlichkeiten und Wirkungsfolgen (z. B. Personen- oder Umweltschäden) quantitativ modelliert und als Grundlage für das Sicherheitsdesign herangezogen – etwa über Methoden wie Fehlerbaumanalyse, | ||
| - | Typischerweise erfolgt eine zweistufige Bewertung: | + | Typischerweise erfolgt eine zweistufige Bewertung: Gefährdungsanalyse (z. B. Risikograph, |
| - | Gefährdungsanalyse (z. B. Risikograph, | + | |
| Nachweis der Wirksamkeit/ | Nachweis der Wirksamkeit/ | ||
| Zeile 73: | Zeile 72: | ||
| Safety-Maßnahmen werden zunehmend durch IT-gestützte Komponenten realisiert, etwa Steuergeräte, | Safety-Maßnahmen werden zunehmend durch IT-gestützte Komponenten realisiert, etwa Steuergeräte, | ||
| - | |||
| ===== 2.3 Begriff: Security ===== | ===== 2.3 Begriff: Security ===== | ||
| Zeile 92: | Zeile 90: | ||
| Die zunehmende digitale Vernetzung technischer Systeme hat zur Folge, dass Security-Risiken zunehmend auch sicherheitsrelevante Funktionen betreffen – etwa wenn IT-Systeme, die Teil der Safety-Architektur sind, durch Cyberangriffe gestört oder manipuliert werden können. Dadurch entstehen relevante Wirkungen von Security auf Safety, die eine gemeinsame Betrachtung erforderlich machen. | Die zunehmende digitale Vernetzung technischer Systeme hat zur Folge, dass Security-Risiken zunehmend auch sicherheitsrelevante Funktionen betreffen – etwa wenn IT-Systeme, die Teil der Safety-Architektur sind, durch Cyberangriffe gestört oder manipuliert werden können. Dadurch entstehen relevante Wirkungen von Security auf Safety, die eine gemeinsame Betrachtung erforderlich machen. | ||
| - | |||
| ===== 2.4 Umgang mit Unsicherheiten ===== | ===== 2.4 Umgang mit Unsicherheiten ===== | ||
| Zeile 107: | Zeile 104: | ||
| 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. | Konsequenz: In Fällen widersprüchlicher Anforderungen – etwa bei Zielkonflikten zwischen Safety und Security – ist eine Risikoabwägung methodisch kaum möglich, da eine quantitative Vergleichbarkeit der Risiken fehlt. Dies stellt eine wesentliche Herausforderung für die Auslegung sicherheitskritischer Systeme dar, die beide Domänen berücksichtigen müssen. | ||
| - | |||
| ===== 2.5 Beispiele für risikobasierte Modelle ===== | ===== 2.5 Beispiele für risikobasierte Modelle ===== | ||
| Zeile 137: | Zeile 133: | ||
| ====== 3. Kategorien sicherheitsrelevanter Wechselwirkungen zwischen Safety und Security ====== | ====== 3. Kategorien sicherheitsrelevanter Wechselwirkungen zwischen Safety und Security ====== | ||
| - | Die zunehmende Vernetzung technischer Systeme sowie die veränderte globale Sicherheitslage machen eine gemeinsame Betrachtung von Safety- und Security-Maßnahmen erforderlich. Angriffe – insbesondere IT-basierte – können sicherheitsrelevante Funktionen direkt beeinträchtigen. Solche Angriffswirkungen sind konstituierend für die Notwendigkeit eines zusätzlichen Security-Layers und führen zu neuen Herausforderungen bei der Systemauslegung. | + | Die zunehmende Vernetzung technischer Systeme sowie die veränderte globale Sicherheitslage machen eine gemeinsame Betrachtung von Safety- und Security-Maßnahmen erforderlich. Angriffe – insbesondere IT-basierte – können sicherheitsrelevante Funktionen direkt beeinträchtigen. Solche Angriffswirkungen sind konstituierend für die Notwendigkeit eines zusätzlichen Security-Layers und führen zu neuen Herausforderungen bei der Systemauslegung. |
| Im Rahmen dieses Wikis unterscheiden wir daher systematisch zwischen vier Typen sicherheitsrelevanter Designwechselwirkungen zwischen Safety und Security. Diese ergeben sich aus der Art der Beziehung zwischen den Anforderungen beider Domänen sowie deren wechselseitiger funktionaler Beeinflussung: | Im Rahmen dieses Wikis unterscheiden wir daher systematisch zwischen vier Typen sicherheitsrelevanter Designwechselwirkungen zwischen Safety und Security. Diese ergeben sich aus der Art der Beziehung zwischen den Anforderungen beider Domänen sowie deren wechselseitiger funktionaler Beeinflussung: | ||
| - | ^ Kategorie ^ Beziehungsart der Anforderungen ^ Relevante Designwechselwirkung ^ Richtung der Beeinflussung ^ Beispielhafte Betrachtung | + | ^Kategorie^Beziehungsart der Anforderungen^Relevante Designwechselwirkung^Richtung der Beeinflussung^Beispielhafte Betrachtung| |
| - | | 1 | kohärent oder konsistent | nein | keine | parallele Auslegung von Safety & Security | | + | |1|kohärent oder konsistent|nein|keine|parallele Auslegung von Safety & Security| |
| - | | 2 | widersprüchlich | ja | Security → Safety (unidirektional) | IT-Security-Maßnahme verzögert Safety-Funktion | | + | |2|widersprüchlich|ja|Security → Safety (unidirektional)|IT-Security-Maßnahme verzögert Safety-Funktion| |
| - | | 3 | widersprüchlich | ja | Safety → Security (unidirektional) | Safety-Maßnahme erschwert Zutrittskontrolle | | + | |3|widersprüchlich|ja|Safety → Security (unidirektional)|Safety-Maßnahme erschwert Zutrittskontrolle| |
| - | | 4 | widersprüchlich | ja | bidirektional | Panikschloss: | + | |4|widersprüchlich|ja|bidirektional|Panikschloss: |
| Hinweis: Die Angriffswirkung (Security Impact on Safety) ist unabhängig von der Designwechselwirkung und betrifft alle Kategorien, bei denen Safety-Funktionen auf IT-Systemen basieren. Sie ist konstituierend für die Notwendigkeit eines gemeinsamen Sicherheitsdesigns. | Hinweis: Die Angriffswirkung (Security Impact on Safety) ist unabhängig von der Designwechselwirkung und betrifft alle Kategorien, bei denen Safety-Funktionen auf IT-Systemen basieren. Sie ist konstituierend für die Notwendigkeit eines gemeinsamen Sicherheitsdesigns. | ||
| + | |||
| ===== 3.1 IT-Security Impact on Safety ===== | ===== 3.1 IT-Security Impact on Safety ===== | ||
| Zeile 192: | Zeile 189: | ||
| Verzögerung sicherheitskritischer Aktionen durch Authentifizierung: | Verzögerung sicherheitskritischer Aktionen durch Authentifizierung: | ||
| + | |||
| * **Sicherheitsupdates beeinträchtigen Safety-Verfügbarkeit**: | * **Sicherheitsupdates beeinträchtigen Safety-Verfügbarkeit**: | ||
| * **Netzwerksegmentierung unterbricht Safety-Kommunikation**: | * **Netzwerksegmentierung unterbricht Safety-Kommunikation**: | ||
| * **Verschlüsselung verursacht Verzögerung oder Inkompatibilität**: | * **Verschlüsselung verursacht Verzögerung oder Inkompatibilität**: | ||
| * **IT-KRITIS-Ausfall mit Safety-Folgen**: | * **IT-KRITIS-Ausfall mit Safety-Folgen**: | ||
| - | + | **Lösungsansätze** | |
| - | **Lösungsansätze** | + | |
| - | In der Regel ist der Schutz von Menschenleben höher zu priorisieren als der Schutz technischer Systeme oder Daten. Deshalb sollte bei potenziellen Konflikten zwischen Security- und Safety-Zielen stets eine szenarienabhängige Entkopplung geprüft werden. Mögliche Maßnahmen umfassen: | + | |
| * Einsatz technischer Entkopplungsmechanismen (z. B. sicherheitsgerichtete Bypass-Funktionen, | * Einsatz technischer Entkopplungsmechanismen (z. B. sicherheitsgerichtete Bypass-Funktionen, | ||
| Zeile 233: | Zeile 229: | ||
| Diese Beispiele zeigen, dass auch Safety-Anforderungen in bestimmten Konstellationen sicherheitsrelevante Wechselwirkungen hervorrufen können. Solche Szenarien sind sorgfältig zu prüfen – auch wenn die Priorisierung der Safety-Funktion in vielen Fällen gerechtfertigt ist, muss die potenzielle Schwächung von Security-Maßnahmen im Gesamtsystem mitgedacht werden. | Diese Beispiele zeigen, dass auch Safety-Anforderungen in bestimmten Konstellationen sicherheitsrelevante Wechselwirkungen hervorrufen können. Solche Szenarien sind sorgfältig zu prüfen – auch wenn die Priorisierung der Safety-Funktion in vielen Fällen gerechtfertigt ist, muss die potenzielle Schwächung von Security-Maßnahmen im Gesamtsystem mitgedacht werden. | ||
| - | ===Abwägung und Priorisierung=== | + | === Abwägung und Priorisierung === |
| Auch wenn die Wahrscheinlichkeit und Relevanz solcher Szenarien geringer ist als bei der umgekehrten Wechselwirkung (Security Impact on Safety), sollte die Möglichkeit dennoch im Designprozess berücksichtigt werden – insbesondere in besonders kritischen Infrastrukturen wie der Kerntechnik. | Auch wenn die Wahrscheinlichkeit und Relevanz solcher Szenarien geringer ist als bei der umgekehrten Wechselwirkung (Security Impact on Safety), sollte die Möglichkeit dennoch im Designprozess berücksichtigt werden – insbesondere in besonders kritischen Infrastrukturen wie der Kerntechnik. | ||
| Dabei gilt weiterhin die grundlegende Empfehlung: Der Schutz von Menschenleben (in diesem Kontext: Safety) hat in sicherheitsrelevanten Anwendungen grundsätzlich Vorrang. Security-Maßnahmen dürfen die Wirksamkeit von Safety-Funktionen nicht kompromittieren – aber umgekehrt ist auch zu vermeiden, dass Safety-Maßnahmen potenzielle Sicherheitslücken verursachen oder Schutzmechanismen im Bereich Security unterlaufen. | Dabei gilt weiterhin die grundlegende Empfehlung: Der Schutz von Menschenleben (in diesem Kontext: Safety) hat in sicherheitsrelevanten Anwendungen grundsätzlich Vorrang. Security-Maßnahmen dürfen die Wirksamkeit von Safety-Funktionen nicht kompromittieren – aber umgekehrt ist auch zu vermeiden, dass Safety-Maßnahmen potenzielle Sicherheitslücken verursachen oder Schutzmechanismen im Bereich Security unterlaufen. | ||
| - | |||
| ===== 3.5 Contradicting Safety-Security Requirements ===== | ===== 3.5 Contradicting Safety-Security Requirements ===== | ||
| + | |||
| Die hier beschriebenen Konstellationen entsprechen Kategorie 4 – also Fällen widersprüchlicher Anforderungen an Safety- und Security-Funktionen mit potenziell sicherheitsrelevanten Wechselwirkungen. In diesen Fällen sind Safety- und Security-Ziele nicht gleichzeitig erfüllbar, sondern konkurrieren miteinander. | Die hier beschriebenen Konstellationen entsprechen Kategorie 4 – also Fällen widersprüchlicher Anforderungen an Safety- und Security-Funktionen mit potenziell sicherheitsrelevanten Wechselwirkungen. In diesen Fällen sind Safety- und Security-Ziele nicht gleichzeitig erfüllbar, sondern konkurrieren miteinander. | ||
| Zeile 285: | Zeile 282: | ||
| * Dynamisch adaptierbare Schutzstrategien, | * Dynamisch adaptierbare Schutzstrategien, | ||
| * Technische Mechanismen zur zuverlässigen Entkopplung von Szenarien | * Technische Mechanismen zur zuverlässigen Entkopplung von Szenarien | ||
| + | |||
| ====== 4. Funktionale Sicherheit ====== | ====== 4. Funktionale Sicherheit ====== | ||
| Zeile 382: | Zeile 380: | ||
| 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. | 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 ==== | + | ==== 5.1.2 Einordnung von Safety und Security ======= Technische Betriebssicherheit (Safety) === |
| - | + | ||
| - | === Technische Betriebssicherheit (Safety) === | + | |
| Safety bezieht sich auf den Schutz vor unbeabsichtigten Bedrohungen, | Safety bezieht sich auf den Schutz vor unbeabsichtigten Bedrohungen, | ||
| Zeile 406: | Zeile 402: | ||
| **Regulatorische und normative Herausforderungen**: | **Regulatorische und normative Herausforderungen**: | ||
| - | ==== 5.1.3 Grundlagen der IT-Security ==== | + | ==== 5.1.3 Grundlagen der IT-Security ======= Schutzziele === |
| - | + | ||
| - | === 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: | 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: | ||
| Zeile 424: | Zeile 418: | ||
| * **Secure Coding: | * **Secure Coding: | ||
| === Organisatorische Maßnahmen === | === Organisatorische Maßnahmen === | ||
| - | |||
| * **Security Management (vergl. ISMS): | * **Security Management (vergl. ISMS): | ||
| * **Incident Management: | * **Incident Management: | ||
| Zeile 456: | Zeile 449: | ||
| * **Whitebox-Analyse: | * **Whitebox-Analyse: | ||
| * **Penetrationstesting: | * **Penetrationstesting: | ||
| - | ==== 5.1.5 Normen & rechtlicher Rahmen ==== | + | ==== 5.1.5 Normen & rechtlicher Rahmen ======= Rechtliche Rahmenbedingungen === |
| - | + | ||
| - | === Rechtliche Rahmenbedingungen === | + | |
| Die rechtlichen Rahmenbedingungen für IT-Sicherheit sind durch nationale und internationale Gesetze, Richtlinien und Verordnungen gegeben. Diese Vorschriften zielen darauf ab, ein Mindestniveau an Sicherheit für Informationstechnologiesysteme zu gewährleisten und den Schutz personenbezogener Daten zu stärken. | Die rechtlichen Rahmenbedingungen für IT-Sicherheit sind durch nationale und internationale Gesetze, Richtlinien und Verordnungen gegeben. Diese Vorschriften zielen darauf ab, ein Mindestniveau an Sicherheit für Informationstechnologiesysteme zu gewährleisten und den Schutz personenbezogener Daten zu stärken. | ||
| Zeile 565: | Zeile 556: | ||
| ==== Risiko: Definition und Herausforderungen ==== | ==== Risiko: Definition und Herausforderungen ==== | ||
| + | |||
| **Frage: Wie wird das Risiko, werden Safety und Security in der Disziplin beschrieben: | **Frage: Wie wird das Risiko, werden Safety und Security in der Disziplin beschrieben: | ||
| Zeile 608: | Zeile 600: | ||
| Abschließend wird nach offenen Forschungsfragen, | Abschließend wird nach offenen Forschungsfragen, | ||
| - | |||
| ====== 7. Fachausschuss Team ====== | ====== 7. Fachausschuss Team ====== | ||
| - | [[content: | + | |
| + | [[:content: | ||