| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung |
| content:hauptseite [2025/10/20 04:27] – [2.1 Begriff: Risiko] wolf | content:hauptseite [2026/09/10 09:44] (aktuell) – termin_neu |
|---|
| | ====== Hauptseite ====== |
| | |
| ====== 1. Motivation & Zielsetzung ====== | ====== 1. Motivation & Zielsetzung ====== |
| |
| 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. | 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 | Eine weitere zentrale Schnittstelle bildet die Mensch-Maschine-Interaktion. Im Safety-Kontext steht der Schutz des Menschen vor Gefährdungen durch fehlerhafte oder unsichere Systemzustände im Vordergrund. Im Security-Kontext kann der Mensch dagegen sowohl Ziel eines Angriffs sein, etwa durch Manipulation oder Social Engineering, als auch selbst als Angreifer auftreten. Damit beeinflusst der Mensch beide Perspektiven in unterschiedlicher Weise und ist bei der gemeinsamen Betrachtung von Safety und Security als wesentlicher Faktor zu berücksichtigen. |
| | |
| | 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 ===== | ===== 1.2 Zielsetzung des Wikis ===== |
| 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 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. | 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. | 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. |
| * [[https://safetyandsecurity.vdi.de/content:kerntechnische-anlagen|► Kernenergieanlagen]] | * [[https://safetyandsecurity.vdi.de/content:kerntechnische-anlagen|► Kernenergieanlagen]] |
| * [[https://safetyandsecurity.vdi.de/content:maritime_sicherheit|► Maritime Sicherheit]] | * [[https://safetyandsecurity.vdi.de/content:maritime_sicherheit|► Maritime Sicherheit]] |
| | * [[https://safetyandsecurity.vdi.de/content:luftfahrt|► Luftfahrt]] |
| | * [[https://safetyandsecurity.vdi.de/content:flughafen|► Flughafen]] |
| * [[https://safetyandsecurity.vdi.de/content:physische_sicherheit|► Physische Sicherheit]] | * [[https://safetyandsecurity.vdi.de/content:physische_sicherheit|► Physische Sicherheit]] |
| * [[https://safetyandsecurity.vdi.de/content:kritis|► KRITIS (Kritische Infrastrukturen)]] | * [[https://safetyandsecurity.vdi.de/content:kritis|► KRITIS (Kritische Infrastrukturen)]] |
| Bild 2.1: Dreigliedrige Darstellung von Safety- und Security-Risiko | Bild 2.1: Dreigliedrige Darstellung von Safety- und Security-Risiko |
| |
| Bild 2.1 zeigt die isomorphe Struktur beider Risikomodelle: | 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. |
| 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: | 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]]). |
| 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 des Safety-Layers berücksichtigt, da deren Verfügbarkeitsnachweis probabilistisch ausgelegt ist und zufällige oder systembedingte Ausfälle beschreibt. Stattdessen werden sie im Security-Layer adressiert: Die Security-Analyse (z. B. nach TARA oder IEC 62443) bewertet potenzielle Angriffe auf Safety-Funktionen und legt geeignete Schutzmaßnahmen bzw. Schutzniveaus (z. B. CAL, SL) 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 gezielte Beeinflussungen 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. | 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. | 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 ===== | ===== 2.2 Begriff: Safety ===== |
| |
| ===== 2.5 Risikobasierte Modelle ===== | ===== 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 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. | 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. |
| |3|widersprüchlich|ja|Safety → Security (unidirektional)|Safety-Freigabe verhindert Zutrittsbeschränkung|Zeitbegrenzung, szenarienabhängige Freigaben| | |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| | |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 ==== | ==== Methodische Herausforderungen bei der gemeinsamen Bewertung ==== |
| * Physische Sicherheit: Brandschutz (Safety: automatische Türentriegelung im Brandfall) untergräbt Zutrittsbeschränkung (Security). | * 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. | * 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. | * 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. | * Generisch: Ein frei zugänglicher Not-Aus-Schalter kann Sicherheitsmechanismen umgehen und so eine potenzielle Security-Schwachstelle darstellen. |
| |
| |
| Tabelle 4.1: Beispiel einer Maßnahmen-Tabelle der IEC 61508 | Tabelle 4.1: Beispiel einer Maßnahmen-Tabelle der IEC 61508 |
| |
| |
| ^Nr. ^Technique/Measure * ^Ref. ^SIL 1^SIL 2^SIL 3^SIL 4| | ^Nr. ^Technique/Measure * ^Ref. ^SIL 1^SIL 2^SIL 3^SIL 4| |
| |3 |Rückwärtsverfolgbarkeit von den Anforderungen an die Sicherheit zu den wahrgenommenen Sicherheitsbedürfnissen|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 | | |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: | \\ Ein einfaches Beispiel soll die zuvor genannten Maßnahmen grundlegend erläutern: |
| → Für detaillierte Inhalte klicken Sie auf **„Mehr Informationen“**. <html> <a id="resilience"></a> </html> | → Für detaillierte Inhalte klicken Sie auf **„Mehr Informationen“**. <html> <a id="resilience"></a> </html> |
| |
| ++++ Mehr informationen | | ++++ Mehr informationen |==== 5.1.1 Motivation ==== |
| | |
| ==== 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. | 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 |
| **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. |
| * **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-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. | 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. |
| |
| ^Richtlinie^Kommentar| | ^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://vdi.de/2180|VDI/VDE 2180]]|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://vdi.de/4020|VDI-EE 4020]]|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://vdi.de/2510|VDI 2510]]|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://vdi.de/2700|VDI 2700]]|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://vdi.de/4062|VDI 4062]]|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://vdi.de/6010|VDI 6010]]|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://vdi.de/2182|VDI/VDE 2182]]|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://vdi.de/3516|VDI/VDE 3516]]|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://vdi.de/4004|VDI/VDE 4004]]|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://vdi.de/4002|VDI 4002]]|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://vdi.de/5702|VDI-EE 5702]]|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. | | |[[https://vdi.de/3780|VDI 3780]]|Technikbewertung: Grundlagen & Begriffe; Orientierungsrahmen für Risiko, Bewertung, Ethik.| |
| |
| ====== 8. Fachausschuss Team ====== | ====== 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. | In diesem Abschnitt stellen wir Mitglieder des Fachausschusses vor, die mit großem Engagement an der Arbeit rund um Safety & Security sowie an der Erstellung dieses Wikis mitgewirkt haben. Die nachfolgende Auflistung umfasst ausschließlich Personen, die einer namentlichen Nennung aktiv zugestimmt haben. Darüber hinaus haben weitere Mitglieder des Fachausschusses wichtige fachliche Beiträge geleistet, die an dieser Stelle ebenfalls ausdrücklich gewürdigt werden sollen. |
| |
| ---- | Besonderer Dank gilt dem Vorsitzenden sowie der VDI-Begleitung, die die inhaltliche und organisatorische Leitung übernehmen. |
| |
| ===== Vorsitzender ===== | ===== Vorsitzender ===== |
| |
| **Prof. Dr.-Ing. Kai-Dietrich Wolf** | Prof. Dr.-Ing. Kai-Dietrich Wolf |
| |
| Fakultät für Maschinenbau und Sicherheitstechnik | Fakultät für Maschinenbau und Sicherheitstechnik |
| |
| Institut für Sicherungssysteme, Bergische Universität Wuppertal | Institut für Sicherungssysteme, Bergische Universität Wuppertal |
| |
| ---- | |
| |
| ===== VDI-Begleitung ===== | ===== VDI-Begleitung ===== |
| |
| **Dr. Andreas Herrmann** | Dr. Andreas Herrmann (bis 2026) |
| |
| Verein Deutscher Ingenieure (VDI) | Verein Deutscher Ingenieure (VDI) |
| |
| ---- | Kim-Julia Kass (ab 2026) |
| |
| ===== Fachausschuss-Mitglieder ===== | Verein Deutscher Ingenieure (VDI) |
| |
| Die folgenden Personen wirken ehrenamtlich im Fachausschuss mit: | ===== Fachausschuss-Mitglieder ===== |
| |
| ^Nachname ^Vorname ^Titel ^Firma | | Die folgenden Personen wirken ehrenamtlich im Fachausschuss mit und haben einer namentlichen Nennung zugestimmt: |
| |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 | | |
| |
| ---- | ^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 ===== | ===== Hinweis ===== |
| |
| Die Liste wird fortlaufend aktualisiert, sobald weitere Mitglieder benannt oder Änderungen erfolgen. | Die Liste wird fortlaufend aktualisiert, sobald weitere Mitglieder einer Veröffentlichung zustimmen oder Änderungen erfolgen. Unabhängig von einer namentlichen Nennung gilt der Dank allen beteiligten Mitgliedern des Fachausschusses für ihre wertvollen Beiträge zur Arbeit des Gremiums und zur Erstellung dieses Wikis. |
| |
| |