content:test

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung		 Vorhergehende Überarbeitung
content:test [2025/09/18 17:31] – [2.1 Begriff: Risiko] approvecontent:test [2025/10/14 19:51] (aktuell) – [2.5.2 Security Modelle] droste
Zeile 1: Zeile 1:
 ====== 1. Einleitung & Motivation ====== ====== 1. Einleitung & Motivation ======
  
 +Test
 +<html>
 +<a id="meinanker"></a>
 +</html>
 ===== 1.1 Zielsetzung des Wikis ===== ===== 1.1 Zielsetzung des Wikis =====
  
Zeile 25: Zeile 29:
 ====== 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://safetyandsecurity.vdi.de/content:automotive|► Automobile Sicherheit]]   * [[https://safetyandsecurity.vdi.de/content:automotive|► Automobile Sicherheit]]
Zeile 52: Zeile 55:
 {{:content:startseite5.svg?400x157}} {{:content:startseite5.svg?400x157}}
  
-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, Bedienungsfehler). Die zu ergreifenden Maßnahmen im Bereich Safety und Security – die hier in aller Regel technologischer Natur sind – sollen das Eintreten des sicherheitsrelevanten Ereignisses mit bestimmter Wahrscheinlichkeit verhindern, sei es im Fall einer äußeren Bedrohung (z. B. Angriff, Missbrauch) oder eines internen Elementarereignisses (z. B. Komponentenausfall, Bedienungsfehler).
  
 Die Herausforderung einer gemeinsamen Betrachtung liegt in der methodischen Integration dieser beiden Perspektiven. Eine Möglichkeit besteht in einem dreigliedrigen Risikobegriff, in Anlehnung an den Bereich Security, der die unterschiedlichen Beiträge zum Risiko berücksichtigt und somit eine Grundlage für Maßnahmenbewertung und Entscheidungsfindung schafft. Die Herausforderung einer gemeinsamen Betrachtung liegt in der methodischen Integration dieser beiden Perspektiven. Eine Möglichkeit besteht in einem dreigliedrigen Risikobegriff, in Anlehnung an den Bereich Security, der die unterschiedlichen Beiträge zum Risiko berücksichtigt und somit eine Grundlage für Maßnahmenbewertung und Entscheidungsfindung schafft.
- 
  
 ===== 2.2 Begriff: Safety ===== ===== 2.2 Begriff: Safety =====
  
-Safety-Risiken im Sinne dieser Dokumentation beziehen sich auf Risiken, die durch technische Systeme ausgelöst werden und Menschen, Umwelt, Sachwerte oder Infrastruktur gefährden können. Sie entstehen typischerweise infolge technischer Fehler, Komponentenausfälle oder unbeabsichtigter menschlicher Fehlhandlungen, z. B. durch Fehlbedienung oder mangelnde Wartung. +Safety-Risiken im Sinne dieser Dokumentation beziehen sich auf Risiken, die durch technische Systeme ausgelöst werden und Menschen, Umwelt, Sachwerte oder Infrastruktur gefährden können. Sie entstehen typischerweise infolge technischer Fehler, Komponentenausfälle oder unbeabsichtigter menschlicher Fehlhandlungen, z. B. durch Fehlbedienung oder mangelnde Wartung.
  
 Ein wesentliches Merkmal von Safety-Risiken ist, dass ihre Eintrittswahrscheinlichkeit auf Basis von Erfahrungswerten probabilistisch abgeschätzt werden kann. In vielen Disziplinen der Safety werden Eintrittswahrscheinlichkeiten und Wirkungsfolgen (z. B. Personen- oder Umweltschäden) quantitativ modelliert und als Grundlage für das Sicherheitsdesign herangezogen – etwa über Methoden wie Fehlerbaumanalyse, HAZOP oder auch FMEA. Ein wesentliches Merkmal von Safety-Risiken ist, dass ihre Eintrittswahrscheinlichkeit auf Basis von Erfahrungswerten probabilistisch abgeschätzt werden kann. In vielen Disziplinen der Safety werden Eintrittswahrscheinlichkeiten und Wirkungsfolgen (z. B. Personen- oder Umweltschäden) quantitativ modelliert und als Grundlage für das Sicherheitsdesign herangezogen – etwa über Methoden wie Fehlerbaumanalyse, HAZOP oder auch FMEA.
  
-Typischerweise erfolgt eine zweistufige Bewertung: +Typischerweise erfolgt eine zweistufige Bewertung: Gefährdungsanalyse (z. B. Risikograph, HARA), die die sicherheitsrelevanten Szenarien ermittelt und klassifiziert.
-Gefährdungsanalyse (z. B. Risikograph, HARA), die die sicherheitsrelevanten Szenarien ermittelt und klassifiziert.+
  
 Nachweis der Wirksamkeit/Verfügbarkeit von Maßnahmen (z. B. über SIL- oder ASIL-Kategorien), die das Risiko auf ein vertretbares Maß reduzieren sollen. Nachweis der Wirksamkeit/Verfügbarkeit von Maßnahmen (z. B. über SIL- oder ASIL-Kategorien), die das Risiko auf ein vertretbares Maß reduzieren sollen.
Zeile 73: Zeile 74:
  
 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. 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 ===== ===== 2.3 Begriff: Security =====
Zeile 92: Zeile 92:
  
 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 106:
  
 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 134: Zeile 132:
   * Landoll, Douglas J. The Security Risk Assessment Handbook: AComplete Guide for Performing Security Risk Assessments. 2nd ed. Boca Raton, FL, USA: CRC Press, 2011.   * Landoll, Douglas J. The Security Risk Assessment Handbook: AComplete Guide for Performing Security Risk Assessments. 2nd ed. Boca Raton, FL, USA: CRC Press, 2011.
   * NE 153: Automation Security 2020 - Design, Implementierung und Betrieb industrieller Automatisierungssysteme, 2015   * NE 153: Automation Security 2020 - Design, Implementierung und Betrieb industrieller Automatisierungssysteme, 2015
 +
 +==== 2.5.5 Referenzen und einschlägige Standards ====
 +
 +^ **Richtlinie** ^ **Kommentar** ^
 +| **Safety-orientierte Standards und Richtlinien** |  |
 +| IAEA Safety Standards (SSR-4, SSG-3, SSG-4) | Grundlagen der probabilistischen Sicherheitsanalyse (PSA). |
 +| IEC 61508 | Funktionale Sicherheit sicherheitsbezogener Systeme. |
 +| IEC 61511 / VDI/VDE 2180 | Funktionale Sicherheit in der Prozessindustrie. |
 +| ISO 26262 | Funktionale Sicherheit im Automobilbereich. |
 +| EN 50126 / EN 50129 (RAMS) | Railway Applications. |
 +| **Security-orientierte Standards und Richtlinien** |  |
 +| ISO/SAE 21434 | Threat Analysis and Risk Assessment (TARA) im Automobilbereich. |
 +| VDI/VDE 2182-Reihe | Informationssicherheit in der industriellen Automatisierung. |
 +| 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. |
 +| **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. Hollnagel, VDI 4004 im weiteren Umfeld. |
  
 ====== 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: Fluchtszenario vs. Zutrittsverhinderung |+|4|widersprüchlich|ja|bidirektional|Panikschloss: Fluchtszenario vs. Zutrittsverhinderung|
  
 Hinweis: Die Angriffswirkung (Security Impact on Safety) ist unabhängig von der Designwechselwirkung und betrifft alle Kategorien, bei denen Safety-Funktionen auf IT-Systemen basieren. Sie ist konstituierend für die Notwendigkeit eines gemeinsamen Sicherheitsdesigns. 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 212:
  
 Verzögerung sicherheitskritischer Aktionen durch Authentifizierung: In IT-gestützten Safety-Funktionen kann eine starke Zugriffskontrolle (z. B. PIN, Token, Zwei-Faktor) im Notfall wertvolle Zeit kosten. Dies gilt z. B. für Sicherheitssysteme in der Industrie oder im Automotive-Bereich. Verzögerung sicherheitskritischer Aktionen durch Authentifizierung: In IT-gestützten Safety-Funktionen kann eine starke Zugriffskontrolle (z. B. PIN, Token, Zwei-Faktor) im Notfall wertvolle Zeit kosten. Dies gilt z. B. für Sicherheitssysteme in der Industrie oder im Automotive-Bereich.
 +
   * **Sicherheitsupdates beeinträchtigen Safety-Verfügbarkeit**: Regelmäßige Software-Updates zur Schließung von Security-Lücken können Systemneustarts oder zeitweilige Nichtverfügbarkeit sicherheitskritischer Systeme erfordern.   * **Sicherheitsupdates beeinträchtigen Safety-Verfügbarkeit**: Regelmäßige Software-Updates zur Schließung von Security-Lücken können Systemneustarts oder zeitweilige Nichtverfügbarkeit sicherheitskritischer Systeme erfordern.
   * **Netzwerksegmentierung unterbricht Safety-Kommunikation**: Strikte Trennung von Netzwerken aus Security-Gründen kann zu unerwünschten Kommunikationsbarrieren führen, insbesondere bei verteilten Safety-Funktionen.   * **Netzwerksegmentierung unterbricht Safety-Kommunikation**: Strikte Trennung von Netzwerken aus Security-Gründen kann zu unerwünschten Kommunikationsbarrieren führen, insbesondere bei verteilten Safety-Funktionen.
   * **Verschlüsselung verursacht Verzögerung oder Inkompatibilität**: Wenn Safety-relevante Daten verschlüsselt übertragen werden, kann dies zu Verzögerungen oder Datenverlusten führen, z. B. in Fahrzeugnetzwerken oder verteilten Industrieanlagen.   * **Verschlüsselung verursacht Verzögerung oder Inkompatibilität**: Wenn Safety-relevante Daten verschlüsselt übertragen werden, kann dies zu Verzögerungen oder Datenverlusten führen, z. B. in Fahrzeugnetzwerken oder verteilten Industrieanlagen.
   * **IT-KRITIS-Ausfall mit Safety-Folgen**: Bei kritischen IT- oder Kommunikationsinfrastrukturen (z. B. GNSS, Zeitserver, SCADA-Netze) können Ausfälle auch sicherheitsrelevante physische Systeme betreffen. Diese Fälle wurden in Abschnitt 3.2 bereits behandelt.   * **IT-KRITIS-Ausfall mit Safety-Folgen**: Bei kritischen IT- oder Kommunikationsinfrastrukturen (z. B. GNSS, Zeitserver, SCADA-Netze) können Ausfälle auch sicherheitsrelevante physische Systeme betreffen. Diese Fälle wurden in Abschnitt 3.2 bereits behandelt.
- +**Lösungsansätze**  In der Regel ist der Schutz von Menschenleben höher zu priorisieren als der Schutz technischer Systeme oder Daten. Deshalb sollte bei potenziellen Konflikten zwischen Security- und Safety-Zielen stets eine szenarienabhängige Entkopplung geprüft werden. Mögliche Maßnahmen umfassen:
-**Lösungsansätze** +
-In der Regel ist der Schutz von Menschenleben höher zu priorisieren als der Schutz technischer Systeme oder Daten. Deshalb sollte bei potenziellen Konflikten zwischen Security- und Safety-Zielen stets eine szenarienabhängige Entkopplung geprüft werden. Mögliche Maßnahmen umfassen:+
  
   * Einsatz technischer Entkopplungsmechanismen (z. B. sicherheitsgerichtete Bypass-Funktionen, notfallfähige Benutzeroberflächen)   * Einsatz technischer Entkopplungsmechanismen (z. B. sicherheitsgerichtete Bypass-Funktionen, notfallfähige Benutzeroberflächen)
Zeile 233: Zeile 252:
 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 305:
   * Dynamisch adaptierbare Schutzstrategien, die im Notfall automatische Umschaltungen oder Priorisierungen erlauben   * Dynamisch adaptierbare Schutzstrategien, die im Notfall automatische Umschaltungen oder Priorisierungen erlauben
   * 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 403:
 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, 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 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
Zeile 406: Zeile 425:
 **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. **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 ==== +==== 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: 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. 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.
Zeile 424: Zeile 441:
   * **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.   * **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 === === 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.   * **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.   * **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.
Zeile 456: Zeile 472:
   * **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.   * **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.   * **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 ==== +==== 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 579:
  
 ==== Risiko: Definition und Herausforderungen ==== ==== Risiko: Definition und Herausforderungen ====
 +
 **Frage: Wie wird das Risiko, werden Safety und Security in der Disziplin beschrieben: Begriffe, Modelle und Verfahren?** **Frage: Wie wird das Risiko, werden Safety und Security in der Disziplin beschrieben: Begriffe, Modelle und Verfahren?**
  
Zeile 608: Zeile 623:
  
 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. Abschließend wird nach offenen Forschungsfragen, neuen Kompetenzen oder interdisziplinärem Wissen gefragt, das notwendig ist, um Safety und Security systematisch zu integrieren – etwa zu Unsicherheitsbewertung, ethischer Abwägung oder Entscheidungsmodellen.
- 
  
 ====== 7. Fachausschuss Team ====== ====== 7. Fachausschuss Team ======
-[[content:fachausschuss|Der Fachausschuss]]+ 
 +[[:content:fachausschuss|Der Fachausschuss]]
  
  
  • content/test.1758209487.txt.gz
  • Zuletzt geändert: 2025/09/18 17:31
  • von approve