| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung |
| content:startseite [2025/05/07 19:13] – [7 Ethische und rechtliche Aspekte] approve | content:startseite [2025/09/21 13:32] (aktuell) – approve |
|---|
| ====== Startseite ====== | ====== 1. Einleitung & Motivation ====== |
| |
| | ===== 1.1 Zielsetzung des Wikis ===== |
| |
| ===== 1 Ziel & Motivation ===== | Das vorliegende Wiki entstand aus der Arbeit des VDI-Fachausschusses „Safety & Security“. Ziel war es zunächst, einen umfassenden Statusbericht zu erstellen, der die Herausforderungen und aktuellen methodischen Entwicklungen im Bereich der gemeinsamen Bewertung von Safety und Security systematisch darstellt. Aufgrund der schnellen Entwicklungen in diesem Themenfeld und der interdisziplinären Breite wurde entschieden, die Ergebnisse in Form eines lebendigen Wikis bereitzustellen, das kontinuierlich weiterentwickelt werden kann. |
| |
| Die Bewertung von Risiken nimmt in der Regel mögliche zukünftige Entwicklungen vorweg und versucht diese anhand unterschiedlicher Szenarien einzuordnen, so dass z.B. eine Reihung im Sinne der Relevanz oder sogar eine quantitative Bewertung möglich wird. Dieses Unterfangen ist naturgemäß mit eher mehr als weniger Unsicherheiten behaftet, was das Vergleichen von Szenarien durchaus erschwert. Bei der Bemessung von Maßnahmen, die Risiken mindern sollen, sind deshalb Sicherheitsaufschläge ein gängiges Mittel, um Unsicherheiten zu berücksichtigen und somit „auf der sicheren Seite“ zu bleiben. In diesem Sinne lassen sich z.B. Anforderungen an die funktionale Sicherheit von Produkten festlegen, die Redundanzen technischer Komponenten erfordern und somit nicht zuletzt auch die Kosten erhöhen. Müssen nun allerdings Risiken gegen Kosten abgewogen werden (was regelmäßig der Fall ist) oder liegen Risiken vor, deren Anforderungen zur Minderung ggf. sogar in Ihrer Natur widersprüchlich sind, so stellt sich die Aufgabe der Risikoabwägung, die noch größere Herausforderungen bereithält, als die reine Risikobewertung. Dies ist spätestens seit der Corona-Pandemie auch breiteren Anteilen der Bevölkerung bewusst: Maßnahmen zum Gesundheitsschutz der Bevölkerung müssen z. B. gegen Einschränkungen von Grundrechten, wirtschaftliche sowie soziale Belange abgewogen werden. | Das Wiki richtet sich vorrangig an Ingenieurinnen und Ingenieure sowie technische Fachkräfte, die in der Praxis mit Safety- und Security-Fragestellungen konfrontiert sind. Darüber hinaus sollen auch Fachleute aus benachbarten Disziplinen sowie interessierte Leserinnen und Leser angesprochen werden, die sich mit den zunehmenden Wechselwirkungen zwischen technischen Schutzmaßnahmen auseinandersetzen. |
| |
| Die oft widersprüchlichen Anforderungen an Safety- und Security Funktionen waren der Ausgangspunkt zur Einrichtung des Fachausschuss //Safety & Security// des VDI. Im Verlauf der Diskussionen in Sitzungen mit zahlreichen Experten stellte sich allerdings heraus, dass die Mehrzahl der Mitglieder des Ausschusses mit einer etwas anders gelagerten Herausforderung beschäftigt war, dem Einfluss von IT-Security Aspekten auf Safety-Funktionen, die dem Bereich der funktionalen Sicherheit zugeordnet werden können. Es besteht ein großer Bedarf an Vorgehensweisen zur angemessenen Bewertung und Auslegung von IT-Security-Maßnahmen im Hinblick auf die funktionale Sicherheit. Auch aus diesem Grund ergab es sich, dass in der Mehrzahl der in dieser Übersicht betrachteten Disziplinen funktionale Sicherheit eine große Rolle spielt. | Das Wiki bietet einen Überblick über etablierte Praktiken und Bewertungsverfahren aus unterschiedlichen technischen Disziplinen und ordnet diese anhand definierter Kategorien sicherheitsrelevanter Wechselwirkungen ein. Dabei versteht es sich nicht als Richtlinie im engeren Sinne, sondern als strukturierter, kuratierter Wissensspeicher, der typische Herausforderungen benennt, Beispiele aus der Ingenieurpraxis beschreibt und wissenschaftlich-methodische Weiterentwicklungen aufzeigt – auch unter Einbeziehung ethischer Überlegungen. |
| ==== 1.1 Safety & Security gemeinsam betrachten ==== | |
| |
| Es sind im Wesentlichen zwei gegenwärtige Entwicklungen, die eine gleichzeitige Behandlung von Safety und Security nahelegen: Die zunehmende IT-basierte Vernetzung und damit zunehmende Vulnerabilität unserer Gesellschaft, aber auch ein signifikant zunehmendes Bedrohungsniveau für moderne Gesellschaften, das sich keinesfalls auf Szenarien der Cyberangriffe beschränkt, sondern auch physische Bedrohungen einbeziehen muss. In technischen Zusammenhängen spielen Infrastrukturen dabei eine zentrale Rolle. | Ein zentrales Ziel ist die Entwicklung einer domänenübergreifenden Perspektive, die Anwenderinnen und Anwendern hilft, widersprüchliche Anforderungen an Safety- und Security-Maßnahmen systematisch zu erkennen, zu analysieren und zu gestalten. Darüber hinaus soll das Wiki auch als strukturierter, semantisch zugänglicher Informationsraum dienen, der zukünftig KI-Systemen eine vertrauenswürdige Grundlage zur Analyse sicherheitsrelevanter Wechselwirkungen bietet. |
| |
| === (IT-)Security Impact on Safety === | ===== 1.2 Warum Safety & Security gemeinsam denken? ===== |
| |
| Komplexe Sicherheitsfunktionen in technischen Anlagen und z.B. auch Automobilen sind oft zeitkritisch; ihre sichere Funktion hängt von der schnellen und sicheren Kommunikation in Netzwerken ab. Die allgegenwärtige und zunehmende Vernetzung macht die IT-Sicherheit zu einer der zentralen Herausforderungen der Zukunft. | Die gemeinsame Betrachtung von Safety und Security wird durch zwei wesentliche Entwicklungen notwendig: |
| |
| Die Funktionale Sicherheit spielt eine zentrale Rolle bei der Risikominderung komplexer technischer Systeme in zahlreichen Disziplinen. Sicherheitsfunktionen stellen z.B. die rechtzeitige Abschaltung gefährdender Systeme wie z.B. Chemieanlagen oder Zugangsbeschränkung zu Gefahrenbereichen sicher und schützen somit ggf. zahlreiche Leben und körperliche Unversehrtheit. Die technische Umsetzung von Sicherheitsfunktionen erfordert in der Regel neben Sensoren und Aktoren Logik- oder IT-Systeme, die bei gegebener Vernetzung grundsätzlich für Cyberangriffe vulnerabel sind. In gängigen Standards und Sicherheitsrichtlinien, z.B. IEC 61508, finden diese Bedrohungen nur unzureichende Berücksichtigung. Ursächlich dafür sind die geforderten quantitativen Nachweise der Verfügbarkeit von Sicherheitsfunktionen, die zwar in den quantitativen Methoden der Zuverlässigkeitsbewertung etabliert, aber in der Bewertung menschengemachter Angriffe auf IT-Infrastrukturen schwer, wenn nicht unmöglich darstellbar sind. Die Metriken der Bewertung von Safety und IT-Security sind hier nicht kompatibel. Diese Situation stellt uns gegenwärtig vor große Herausforderungen. | **Zunehmende IT-Vernetzung technischer Systeme** führt dazu, dass sicherheitskritische Funktionen – etwa zur Gefahrenvermeidung – immer häufiger auf IT-Komponenten basieren. Diese sind potenziell angreifbar. Damit entsteht die Möglichkeit, dass Angriffe auf IT-Systeme (Security) zum Ausfall sicherheitsrelevanter Funktionen (Safety) führen. Diese Angriffswirkung ist zentraler Auslöser für die Notwendigkeit, Safety und Security gemeinsam zu denken. |
| |
| === Widersprüche zwischen Safety und Security === | **Zunehmende Bedrohungslage** in Gesellschaft, Infrastruktur und Wirtschaft – durch Cyberangriffe, hybride Bedrohungen oder gezielte physische Angriffe – verlangt nach einer integrierten sicherheitstechnischen Auslegung. Dies betrifft nicht nur die IT-Sicherheit, sondern auch die physische Sicherheit, etwa in Bezug auf kritische Infrastrukturen oder industrielle Anlagen. |
| |
| Anforderungen an Safety und Security Funktionen sind oft widersprüchlich. Fluchtmöglichkeiten, z.B. im Falle eines Brandes, werden in Gebäuden durch verriegelte Türen eingeschränkt. Zahlreiche Vorschriften und technische Vorkehrungen, wie z.B. Panikschlösser, reduzieren die negativen Wechselwirkungen von Safety- und Security-Maßnahmen in Gebäuden. Der Absturz des [[https://de.wikipedia.org/wiki/Germanwings-Flug_9525|Germanwings Fluges 9525 ]] in den französischen Alpen ging prominent durch die Medien: Eine Cockpittür ist kugelsicher gepanzert (Security), was das Aufbrechen im Notfall natürlich erheblich erschwert. Ein Sicherheitscode, der der Crew bekannt ist, kann die Verriegelung der Tür im Notfall lösen (Safety), allerdings kann dies aus Gründen der Gefahrenabwehr (Security) aus dem Inneren des Cockpits heraus unterbunden werden. Allem Anschein nach hat dieses Szenario zum Tod von 150 Menschen geführt. | Die Schutzfunktion technischer Systeme wird heute zunehmend durch Kombinationen aus Safety- und Security-Maßnahmen gewährleistet. Dabei treten Wechselwirkungen auf, die entweder synergetisch, neutral oder widersprüchlich sein können. Die Herausforderung besteht darin, diese Wechselwirkungen zu erkennen, zu bewerten und geeignete Maßnahmen zur Risikominimierung zu ergreifen. |
| |
| Neben Safety und Verfügbarkeit wird damit auch Security regelmäßig zum obersten Gebot technischer Auslegung kritischer Systeme. Widersprüchlichkeiten zwischen den Anforderungen müssen ggf. abgewogen werden, um zum bestmöglichen Design zu kommen. Neben ethischen Fragestellungen wirft dies auch neue technische und wissenschaftliche Fragestellungen auf. Eine Risikoanalyse als Grundlage der übergreifenden Bewertung muss einerseits die Quantifizierung aller Risikobeiträge in einer gemeinsamen Metrik ermöglichen, andererseits müssen auch Unschärfen und Informationslücken berücksichtigt werden, um angemessene Entscheidungen treffen zu können oder die quantitative Analyse als Entscheidungshilfe im Einzelfall auch komplett zu verwerfen. Die Rolle der Unsicherheiten darf insbesondere bei der Abwägung widersprüchlicher Anforderungen nicht vernachlässigt werden, denn unter großen Unsicherheiten ist eine gute Abwägung kaum möglich. | Im Fokus stehen dabei nicht nur klassische Zielkonflikte – etwa zwischen Brandschutz und Zutrittskontrolle – sondern auch neue Herausforderungen durch die Integration von IT in sicherheitsrelevante Systeme. Die bisher übliche getrennte Betrachtung von Safety und Security greift hier zu kurz. Das Wiki verfolgt deshalb das Ziel, eine strukturierte, disziplinübergreifende Orientierung für die gemeinsame Bewertung und Gestaltung sicherheitsrelevanter Systeme zu schaffen. |
| |
| === Security Impact on Availability === | ====== 1.3 Disziplinen ====== |
| |
| Kritische Infrastrukturen sind das Rückgrat moderner Gesellschaften. Die permanente Verfügbarkeit von Energie-, Wasser-, Kommunikations- und Verkehrsinfrastrukturen ist selbstverständliche Grundlage unserer gesellschaftlichen und wirtschaftlichen Existenz. Von Angriffen auf diese Infrastrukturen, seien sie terroristisch, kriminell, politisch oder anderweitig motiviert, können sehr viele Menschen zur gleichen Zeit betroffen sein. Derartige Angriffe, sowohl auf die IT- als auch auf die physischen Komponenten der Infrastrukturen bedrohen somit die Sicherheit unserer Gesellschaft. Sicherungsmaßnahmen gegen diese Angriffe müssen vergleichbare Sicherheitsniveaus erreichen, wenn Schwachstellen vermieden werden sollen. Wechselwirkungen zwischen diesen Maßnahmen müssen ggf. berücksichtigt werden, z.B. die physische Sicherheit von SCADA-Systemen oder Serverräumen. Auch dies erfordert den Abgleich der Maßnahmen auf der Basis bewertender Metriken. | 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: |
| |
| === Cyberphysische Systeme === | * [[https://safetyandsecurity.vdi.de/content:automotive|► Automobile Sicherheit]] |
| | * [[https://safetyandsecurity.vdi.de/content:arbeitsschutz|► Industrieanlagen & Arbeitsschutz]] |
| | * [[https://safetyandsecurity.vdi.de/content:kernenergie|► Kernenergieanlagen]] |
| | * [[https://safetyandsecurity.vdi.de/content:maritime_sicherheit|► Maritime Sicherheit]] |
| | * [[https://safetyandsecurity.vdi.de/content:physische_sicherheit|► Physische Sicherheit]] |
| | * [[https://safetyandsecurity.vdi.de/content:kritis|► KRITIS (Kritische Infrastrukturen)]] |
| |
| Die Verbindung zwischen Systemkomponenten in der physischen Welt und der IT-basierten Vernetzung ist bei Cyberphysischen Systemen, z.B. Drohnenschwärme besonders ausgeprägt oder mit besonders hohen Auswirkungen und Risiken verbunden, wenn man so will. Im Zeitalter des Internet of Things (IOT) ist von einer Ausweitung der cyberphysischen Sphäre auf die meisten gebräuchlichen Technologien auszugehen. Alle oben genannten Wechselwirkungen zwischen den Domänen Safety und Security treffen dabei – je nach Anwendung – auch auf Cyberphysische Systeme zu. Dies gilt ebenso für die damit verbundenen Herausforderungen bei der abgestimmten risikogerechten Auslegung der Systeme in beiden Domänen. | ====== 2. Grundlagen: Risiko, Safety, Security, Unsicherheiten ====== |
| |
| ==== 1.2 Ziele für den Fachausschuss: ==== | ===== 2.1 Begriff: Risiko ===== |
| |
| Übergeordnetes Ziel des zu gründenden [[https://www.vdi.de/tg-fachgesellschaften/vdi-gesellschaft-produkt-und-prozessgestaltung/sicherheit-und-zuverlaessigkeit|Fachausschusses]] Synthese von Safety und Security ist die Erarbeitung und Fortführung des in dieser Form vorliegenden Statusberichtes zu den Herausforderungen, sowie zum Stand der Anwendung und Entwicklung von Methoden zur übergreifenden Betrachtung von Safety und Security. Im Zuge der Erarbeitung des Berichts reifte die Überzeugung, aufgrund der schnellen Entwicklungen in diesem Themengebiet und der Interdisziplinarität und Breite des Anwendungsbereichs, die Ergebnisse in Form eines Wikis zusammenzutragen. In dieser Form richtet sich der Bericht an Ingenieure und Technikanwender, die im Umfeld zunehmender Wechselwirkungen von Safety- und Security Maßnahmen aktiv sind, aber auch an Interessierte an diesem Themenkomplex aus anderen Bereichen. | Die Grundlage der gemeinsamen Betrachtung von Safety und Security bildet ein einheitlicher Risikobegriff. Ziel ist es, eine risikobasierte Systematik zu etablieren, die Wechselwirkungen zwischen technischen Maßnahmen in beiden Domänen systematisch erfassen und bewerten kann. |
| |
| Das Wiki liefert eine Übersicht gängiger Bewertungspraktiken in unterschiedlichen technischen Disziplinen und ordnet diese anhand zu definierender Kategorien in Bezug auf die Risikobewertung ein. Dabei kann der Bericht dem Anspruch an eine Richtlinie zum gegebenen Zeitpunkt noch nicht gerecht werden. Vielmehr weist der Bericht auf Herausforderungen und bestehende Ingenieurpraxis in der Bewertung und Risikoanalyse hin und zeigt wissenschaftlich-methodische Entwicklungen auf, wobei nicht zuletzt auch ethische Gesichtspunkte adressiert werden. | Risiko wird dabei grundsätzlich verstanden als eine Kombination aus Eintrittswahrscheinlichkeit und Auswirkung eines unerwünschten Ereignisses. Dieses Basismodell eignet sich gut zur Beschreibung klassischer Safety-Szenarien, stößt jedoch im Bereich der Security auf methodische Grenzen: Während technische Versagenswahrscheinlichkeiten in der Regel probabilistisch abschätzbar sind (z. B. aus Erfahrungswerten oder Fehlermodellen), ist dies bei sicherheitsrelevanten Angriffsszenarien nicht der Fall. |
| |
| Erstes Teilziel für den Fachausschuss war die Entwicklung eines gemeinsamen risikobasierten Modells, das ganzheitlich die verschiedenen Fachgebiete aus den Domänen Safety und Security zusammenführen kann. Das Modell und die gleichzeitig darzustellende Methodik zur Synthese sollen es dem Anwender ermöglichen, Zielkonflikte und widersprüchliche Anforderungen an Safety und Security von Produkten und Infrastrukturen zu formulieren. | Im Bereich Security basiert die Eintrittswahrscheinlichkeit eines Angriffs in der Regel auf menschlicher Willensbildung. Die damit verbundene Unsicherheit ist epistemischer Natur – also durch fehlende oder nicht zugängliche Information bedingt – und kann nicht probabilistisch im klassischen Sinne modelliert oder durch Verteilungsfunktionen dargestellt werden. Daher wird in der Security häufig mit qualitativen oder semiquantitativen Einschätzungen gearbeitet, oder auch durch separate Bewertung von Verwundbarkeiten. |
| |
| ===== 2 Lösungsansätze ===== | Zur Beschreibung von Risiko in beiden Domänen haben sich unterschiedliche Modellierungen etabliert: |
| |
| ** <font 24px/inherit;;inherit;;#f1c40f>Rohversion aus KI</font> ** | * Im Bereich Safety wird Risiko meist durch Eintrittswahrscheinlichkeit × Schadensausmaß beschrieben. In Normen wie IEC 61508 oder ISO 26262 führen diese zu gestuften Anforderungen (z. B. SIL, ASIL), die über die Verfügbarkeit von Sicherheitsfunktionen quantitativ nachgewiesen werden können. |
| | * Im Bereich Security wird Risiko oft als Kombination von Bedrohung, Vulnerabilität und Auswirkung beschrieben. Die Bedrohungswahrscheinlichkeit selbst bleibt dabei meist unquantifiziert – stattdessen erfolgt eine qualitative Einschätzung unter Unsicherheiten. |
| |
| Die Notwendigkeit, Safety und Security gemeinsam zu betrachten, stellt neue Anforderungen an Methodik und Praxis der Risikobewertung. Die Zielsetzung ist eine domänenübergreifende Betrachtung von Risiken auf einer gemeinsamen, möglichst quantifizierbaren Bewertungsbasis – unter Berücksichtigung disziplinspezifischer Herausforderungen, Zielkonflikte und Unsicherheiten. | {{:content:startseite5.svg?400x157}} |
| |
| ==== 2.1 ( IT- )Security Impact on Safety ==== | Abbildung 1: Dreigliedrige Darstellung von Safety- und Security-Risiko |
| |
| Die zunehmende IT-Vernetzung sicherheitskritischer Komponenten – insbesondere in Automatisierung und Automotive – führt dazu, dass zeitkritische Sicherheitsfunktionen zunehmend von IT-Systemen abhängen. Angriffe auf Kommunikationsnetze, Manipulationen von Steuergeräten oder Störungen der Datenverfügbarkeit können direkte Auswirkungen auf Safety-Funktionen haben. In der funktionalen Sicherheit nach IEC 61508 oder ISO 26262 ist die Risikobewertung auf probabilistische Kenngrößen wie Ausfallwahrscheinlichkeit und Diagnosebedeckungsgrad fokussiert. Die Einbindung von Security-Aspekten erfordert jedoch eine Erweiterung der Methodik. Erste Ansätze zur Übertragung der SIL-Logik auf Security-Maßnahmen – etwa in Form definierter „Security Level“ – sind in Automotive (ISO/ SAE 21434) oder Industrie ( IEC 62443) zu finden, stoßen aber auf methodische Grenzen: Angreiferverhalten ist nicht zufällig, und Eintrittswahrscheinlichkeiten sind nur qualitativ einschätzbar. Die Metriken beider Domänen sind derzeit inkompatibel. | 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). |
| |
| ==== 2.2 Widersprüche zwischen Safety und Security ==== | 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. |
| |
| In zahlreichen Disziplinen treten Zielkonflikte zwischen Safety- und Security-Anforderungen auf. In der physischen Sicherheit kann z. B. der Schutz vor unbefugtem Zutritt den sicheren und schnellen Notausgang behindern. In der Nukleartechnik führt die Notwendigkeit hoher Sicherheitsmaßnahmen gegen Sabotage zu Zielkonflikten mit betrieblichen Anforderungen an Reaktionszeiten und Redundanzpfade . Solche Widersprüche sind nicht auflösbar, sondern müssen abgewogen werden. Dies erfordert Verfahren, die Zielgewichtungen, Prioritäten und Konsequenzen auf einer vergleichbaren Skala bewerten können. Bestehende qualitative Risikoanalysen sind hier nur eingeschränkt hilfreich. Eine übergreifende Bewertung muss auch epistemische Unsicherheiten einbeziehen, da unter großer Unsicherheit keine verlässliche Abwägung möglich ist. | |
| |
| ==== 2.3 Security Impact on Availability ==== | ===== 2.2 Begriff: Safety ===== |
| |
| Insbesondere im Bereich kritischer Infrastrukturen ( KRITIS ) ist die Verfügbarkeit das zentrale Schutzziel – etwa in Energieversorgung, Wasserwirtschaft oder Telekommunikation. IT-Sicherheitsmaßnahmen (z. B. Segmentierung, Firewalls, Verschlüsselung) können jedoch die Verfügbarkeit durch Verzögerungen, Fehlkonfigurationen oder Sperrmechanismen beeinträchtigen. Ein belastbarer Lösungsansatz besteht in der gegenseitigen Berücksichtigung von IT- und physischer Sicherheit, etwa durch abgestimmte Sicherheitskonzepte für SCADA-Systeme , Leitstände oder Netzknoten. Die Vorgaben des BSI-Gesetzes und der KRITIS-Verordnung fordern die Einhaltung des „Standes der Technik“, ohne diesen konkret zu quantifizieren. Die Entwicklung semi-quantitativer Metriken, die sowohl Verfügbarkeitseinbußen als auch Angriffsrisiken modellieren, ist daher ein zentrales Forschungsziel. | 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. |
| |
| ==== 2.4 Cyberphysische Systeme ==== | 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. |
| |
| Bei cyberphysischen Systemen – wie autonomen Fahrzeugen, Industrie-4.0-Fertigungslinien oder Drohnensystemen – ist die Verknüpfung von physischer Funktionalität und IT-Kommunikation besonders eng. Die Wechselwirkungen zwischen Safety und Security sind hier maximal ausgeprägt: Eine IT-Störung kann unmittelbar zu einem sicherheitsrelevanten Ausfall führen – und umgekehrt können Sicherheitsmaßnahmen physische Prozesse blockieren. Im Bereich Luftfahrt wird dieser Zusammenhang adressiert, etwa durch integrierte Sicherheitskonzepte, jedoch ist die methodische Tiefe bislang unzureichend. Zukünftig bedarf es domänenübergreifender Methoden zur integrierten Risikoanalyse, die sowohl funktionale Sicherheitsmodelle als auch IT-Angriffsmodelle kombinieren, beispielsweise durch die Kopplung von FMEA/Fault Tree mit Bedrohungsszenarien oder Bayesschen Netzen . | Typischerweise erfolgt eine zweistufige Bewertung: |
| | Gefährdungsanalyse (z. B. Risikograph, HARA), die die sicherheitsrelevanten Szenarien ermittelt und klassifiziert. |
| |
| ===== 3 Definition Safety & Security ===== | Nachweis der Wirksamkeit/Verfügbarkeit von Maßnahmen (z. B. über SIL- oder ASIL-Kategorien), die das Risiko auf ein vertretbares Maß reduzieren sollen. |
| |
| Über die Abgrenzung von Safety und Security lässt sich vortrefflich streiten. Da wir uns vorgenommen haben, Safety und Security in einer Bewertung zusammenzuführen, ist eine scharfe Abgrenzung eigentlich nicht erforderlich. Dennoch kann für das Verständnis der Herausforderungen und der Lösungsansätze eine Betrachtung der beiden Sicherheitsdomänen aus der Perspektive der Risikobewertung aufschlussreich sein. In beiden Domänen, Safety und Security, sollen relevante Szenarien risikobasiert bewertet werden, wir werden also bei Teilereignissen auch von Safety- bzw. Security-Risiken sprechen. | Die zu ergreifenden Maßnahmen – zumeist technischer Natur – zielen darauf ab, die Wahrscheinlichkeit des Eintritts eines sicherheitsrelevanten Ereignisses bei einem bestimmten Auslöser (z. B. Fehler, Umwelteinfluss) zu verringern oder dessen Auswirkungen zu begrenzen. Die dafür eingesetzten Methoden sind in vielen technischen Normen und Regelwerken etabliert (vgl. Abschnitt 2.5.1). |
| |
| ==== 3.1 Safety ==== | 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-Risiken im Sinne dieser Dokumentation sind insbesondere Risiken die von der Technik ausgehen und Mensch, Technik oder Infrastruktur betreffen. Damit sind ursächlich für Safety-Risiken meist versagende technische Komponenten. Auch unabsichtliches menschliches Fehlverhalten kann ursächlich für Safety-Risiken sein, z.B. im Bereich Arbeits- oder Brandschutz. Die Besonderheit für die Risikobewertung besteht darin, dass das auslösende Ereignis eines Safety Vorfalls oft auf der Basis von Evidenz und Erfahrungswerten probabilistisch beschrieben werden kann, was die Häufigkeit des Eintretens betrifft. Dies ist bei den Security-Risiken i.d.R. nicht möglich. | |
| |
| ==== 3.2 Security ==== | ===== 2.3 Begriff: Security ===== |
| |
| Security-Risiken im Sinne dieser Dokumentation gehen auf von Menschen gewollt verursachte Ereignisse zurück, die Technik und Infrastruktur und damit mittelbar auch den Menschen bedrohen. Die Häufigkeit, mit der diese Ereignisse eintreten ist aufgrund der menschlichen Willensbildung i.d.R. nicht probabilistisch zu erfassen. In Ermangelung von Evidenz kann man i.d.R. nur mit sehr großen Unsicherheiten behaftete Angaben zur Bedrohungswahrscheinlichkeit machen. Aus diesem Grund beschränkt sich die Analyse der Eintrittswahrscheinlichkeit bei Security-Risiken oft auf die Vulnerabilität. Dies gilt sowohl für die IT- als auch für die physische Sicherheit. | Security-Risiken entstehen durch vorsätzliche, zielgerichtete Handlungen, die auf die Beeinträchtigung oder Kompromittierung technischer Systeme und Infrastrukturen abzielen. Im Gegensatz zur Safety ist die Ursache also nicht zufällig oder unbeabsichtigt, sondern willensgesteuert – etwa durch Sabotage, Spionage, Terrorismus, Diebstahl oder Cyberangriffe. |
| |
| ==== 3.3 Domänenübergreifende Zusammenführung ==== | Das zentrale Merkmal von Security-Risiken ist die epistemische Unsicherheit bezüglich ihrer Eintrittswahrscheinlichkeit: Da Angriffe von intelligenten Akteuren ausgehen, sind sie nicht probabilistisch erfassbar. Es existieren in der Regel keine belastbaren historischen Daten, die eine statistische Modellierung der sogenannten Bedrohungswahrscheinlichkeit erlauben würden. Aus diesem Grund wird bei Security-Risiken häufig nur die Vulnerabilität des Systems betrachtet – also die Verwundbarkeit bei gegebenem Angriff. |
| |
| Die Zusammenführung aller Risiken in einer Bewertung über die Domänen Safety und Security ist eine Zielstellung des FA512. Bei einer dreiteiligen Risikobewertung, wie sie hier vorgeschlagen wird, muss sich die Zusammenführung in der Regel über diese drei Risikobereiche erstrecken. Die Formulierung eines Gesamtrisikos über alle Beiträge aus Safety und Security erlaubt z.B. eine Abwägung widersprüchlicher Anforderungen oder eine Optimierung im Sinne einer Cost-Benefit-Analyse insbesondere dann, wenn die entsprechenden Metriken für die Bewertung der Risikobeiträge in den Domänen Safety und Security kompatibel sind und eine quantitative Bemessung erlauben. Wo Risikobeiträge quantitativ bewertet werden, kann rechnerisch optimiert werden, sofern die Unsicherheiten, die unbedingt mitbetrachtet werden müssen, nicht zu groß sind. Wenn widersprüchliche Anforderungen vorliegen, bzw. erhebliche Wechselwirkungen zwischen Safety- und Security-Maßnahmen gegeben sind, müssen die jeweiligen Metriken die Wirkung der Maßnahmen in der jeweils anderen Domäne abbilden können, also kompatibel sein, damit Entscheidungen in Abwägung oder Optimierung getroffen werden können. Auch hier gilt, dass Unsicherheiten nicht zu groß werden dürfen, wenn tragfähige Entscheidungen getroffen werden sollen. | Security-Risiken lassen sich typischerweise in zwei Hauptbereiche unterteilen: |
| |
| ===== 4 IT-Security / Informationssicherheit ===== | IT-/Cybersecurity, bei der Systeme über digitale Schnittstellen (Netzwerke, Software, Fernzugriffe) angegriffen werden. |
| |
| Im Kontext technischer Systeme und der Informationsverarbeitung gewinnt die differenzierte Betrachtung von Safety und Security zunehmend an Bedeutung. Trotz ihrer unterschiedlichen Ausrichtung – Safety fokussiert auf den Schutz vor unbeabsichtigten Ereignissen, während Security den Schutz vor vorsätzlichen Angriffen adressiert – erfordert die Digitalisierung und Vernetzung technischer Systeme eine integrative Sichtweise. | Physische Sicherheit, bei der der Zugang zu bedrohten Systemen, Anlagen oder Einrichtungen durch physische Mittel (z. B. Einbruchswerkzeug, schwere Kfz) erlangt wird. |
| |
| ==== 4.1 Motivation ==== | Ziel von Security-Maßnahmen ist es, die Verfügbarkeit, Integrität und Vertraulichkeit technischer Systeme zu schützen. Dazu werden Maßnahmen implementiert, die das Auftreten eines erfolgreichen Angriffs erschweren, detektieren oder seine Wirkung begrenzen – etwa über Zugangskontrollen, Firewalls, Verschlüsselung, Segmentierung, physische Barrieren oder organisatorische Maßnahmen. |
| |
| 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. | Im Gegensatz zur Safety, wo die Risikobewertung oft quantitativ erfolgt, dominieren im Bereich der Security qualitative oder semi-quantitative Bewertungsverfahren (z. B. TARA-Analysen, Bedrohungskataloge, CVSS). Die Bewertung ist oft kontextabhängig und orientiert sich an Szenarien, Angreiferprofilen oder Schutzzielen. |
| |
| ==== 4.2 Einordnung von Safety und Security ==== | 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. |
| |
| === 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 | ===== 2.4 Umgang mit Unsicherheiten ===== |
| |
| === IT-Sicherheit (Security ) === | Im Rahmen sicherheitstechnischer Risikoanalysen spielen Unsicherheiten eine zentrale Rolle. Grundsätzlich lassen sich zwei Arten von Unsicherheiten unterscheiden: |
| |
| Im Gegensatz zu Safety konzentriert sich Security auf die Abwehr von beabsichtigten, bösartigen Bedrohungen gegen die Vertraulichkeit, Integrität und Verfügbarkeit von Systemen und Daten. Security umfasst die Gesamtheit der Maßnahmen zum Schutz vor Angriffen, Diebstahl, Sabotage oder unberechtigtem Zugriff. | Aleatorische Unsicherheiten, d. h. zufällige Streuungen (z. B. Ausfallraten, Umweltbedingungen), die durch Verteilungsfunktionen erfasst und mit probabilistischen Verfahren behandelt werden können. |
| |
| === Zuverlässigkeit durch Safety und Security === | Epistemische Unsicherheiten, d. h. Unsicherheiten aufgrund fehlender oder unvollständiger Informationen, etwa über die Wahrscheinlichkeit menschlichen Handelns oder die Existenz von Schwachstellen. |
| |
| Die Zuverlässigkeit technischer Systeme hängt maßgeblich von den Aspekten Safety und Security ab. Die Herausforderung liegt in der integrierten Berücksichtigung beider Aspekte, um Systemausfälle zu verhindern und die Zuverlässigkeit zu erhöhen. Eine effektive Umsetzung von Safety- und Security-Maßnahmen steigert somit die Gesamtzuverlässigkeit eines Systems. Die Abhängigkeiten zwischen physischen und informationstechnischen Systemen erfordern eine gemeinsame Betrachtung, um Schwachstellen effektiv zu adressieren und zu beheben. Beispielsweise kann eine Sicherheitslücke in der IT-Infrastruktur nicht nur Datenrisiken, sondern auch physische Sicherheitsrisiken nach sich ziehen. | Mit aleatorischen Unsicherheiten kann man methodisch gut umgehen. In der Safety-Domäne sind bewährte Verfahren verfügbar: Monte-Carlo-Simulationen, die Berechnung von Vertrauensbereichen, varianzbasierte Sensitivitätsanalysen oder Bayessche Netze erlauben eine methodisch fundierte Risikoanalyse. Eine Abwägung verschiedener Risiken gegeneinander ist in diesem Rahmen prinzipiell möglich. |
| |
| === Konflikte zwischen Safety und Security === | Im Security-Bereich dominiert jedoch epistemische Unsicherheit. Die Eintrittswahrscheinlichkeit von Security-Risiken hängt wesentlich von der Willensbildung potenzieller Angreifer ab und ist in der Regel nicht probabilistisch modellierbar. Damit versagen die klassischen Methoden der probabilistischen Risikoanalyse – etwa die Bewertung über Eintrittswahrscheinlichkeit × Auswirkung – im Security-Kontext weitgehend. |
| |
| **Ressourcenallokation**: Die Ressourcen (Zeit, Geld, Personal) können begrenzt sein, und die Priorisierung der einen kann zu Lasten der anderen gehen. Zum Beispiel könnte ein übermäßiger Fokus auf Security-Maßnahmen Ressourcen von wichtigen Safety-Maßnahmen abziehen und umgekehrt. | 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. |
| |
| **Design- und Implementierungskonflikte**: Einige Sicherheitsmaßnahmen könnten im Widerspruch zu Sicherheitsanforderungen stehen. Ein Beispiel hierfür ist die Zutrittskontrolle: Während aus Sicherheitsgründen ein restriktiver Zutritt wünschenswert ist, könnte dies im Notfall die Rettungsdienste behindern und somit die Sicherheit gefährden. | |
| |
| **Datenzugriff und Privatsphäre**: Security-Maßnahmen, die eine Überwachung und das Sammeln von Daten erfordern, können in Konflikt mit dem Datenschutz und der Privatsphäre der Nutzer stehen, was wiederum safety-relevante Aspekte beeinflussen kann, insbesondere in Bereichen, die eine anonyme Datenerhebung erfordern. | ===== 2.5 Beispiele für risikobasierte Modelle ===== |
| |
| **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. | ==== 2.5.1 Safety Modelle ==== |
| ==== 4.3 Grundlagen der Security ==== | |
| |
| === Schutzziele === | * DIN EN ISO 13849: Sicherheit von Maschinen - Sicherheitsbezogene Teile von Steuerungen, 2017. |
| | * DIN EN 61882 VDE 0050-8: HAZOP-Verfahren (HAZOP-Studien), 2017 |
| | * IAEA Safety Reports Series No. 25: Review of Probabilistic Safety Assessments by Regulatory Bodies, 2002. |
| | * IAEA Safety Reports Series No. 52: Best Estimate Safety Analysis for Nuclear Power Plants: Uncertainty Evaluation, 2008. |
| | * IAEA Safety Standards Series No. GSR Part 4 (Rev. 1): Safety Assessment for Facilities and Activities, 2016. |
| | * IAEA Safety Standards Specific Safety Guide No. SSG-3: Development and Application of Level 1 Probabilistic Safety Assessment for Nuclear Power Plants, 2010. |
| | * IAEA Safety Standards Specific Safety Guide No. SSG-4: Development and Application of Level 2 Probabilistic Safety Assessment for Nuclear Power Plants, 2010. |
| | * IEC 61508: Funktionale Sicherheit sicherheitsbezogener elektrischer/elektronischer/programmierbarer elektronischer Systeme, 2011. |
| | * IEC 61511: Functional safety - Safety instrumented systems for the process industry sector, 2016. |
| | * ISO 26262: Road vehicles – Functional safety, 2018. |
| | * NE 144: Risikobasierte Instandhaltung von Brandmeldeanlagen, 2012. |
| |
| 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-Sicherheit integriert behandelt. Die Abhängigkeiten der Schutzziele erfordert eine ausgewogene Berücksichtigung aller vier Aspekte, um ein effektives Sicherheitsniveau zu erreichen. | ==== 2.5.2 Security Modelle ==== |
| |
| === Technische Maßnahmen === | * Alberts, Christopher, Audrey Dorofee, James Stevens, and Carol Woody. “Introduction to the OCTAVE Approach.” Networked Systems Survivability Program. Pittsburgh, PA, USA: Carnegie Mellon University, 2003. |
| | * Beyerer, Jürgen, and Jürgen Geisler. “A Framework for a Uniform Quantitative Description of Risk with Respect to Safety and Security.” CKGE_TMP_i European Journal of Security Research CKGE_TMP_i 1 (2016): 135–150. |
| | * BSI - Bundesamt für Sicherheit in der Informationstechnik. “Guidelines for Developer Documentation according to Common Criteria Version 3.1,” 2007. |
| | * Campbell, Philip L., and Jason E. Stamp. “A Classification Scheme for Risk Assessment Methods.” SANDIA REPORT. Albuquerque, NM, USA: Sandia National Laboratories, 2004. |
| | * Harnser Group, ed. “A Reference Security Management Plan for Energy Infrastructure.” European Commission, 2010. |
| | * Landoll, Douglas J. The Security Risk Assessment Handbook: AComplete Guide for Performing Security Risk Assessments. 2nd ed. Boca Raton, FL, USA: CRC Press, 2011. |
| | * NE 153: Automation Security 2020 - Design, Implementierung und Betrieb industrieller Automatisierungssysteme, 2015 |
| |
| //Anmerkung JP: Kryptografie, Key Management, Systemsicherheit, Softwaresicherheit, Hardwaresicherheit, Netzwerksicherheit, Security-by-Design, Secure Coding, (ggf. erweitern) // | ====== 3. Kategorien sicherheitsrelevanter Wechselwirkungen zwischen Safety und Security ====== |
| |
| * **Kryptografie:** Kryptografie bezeichnet die Lehre von der Verschlüsselung von Informationen. Ziel ist es, Daten so zu transformieren, dass sie nur von autorisierten Parteien entschlüsselt und gelesen werden können. Moderne Kryptografie nutzt mathematische Algorithmen für die Verschlüsselung und Sicherstellung der Integrität von Daten, um Vertraulichkeit, Authentizität und Nichtabstreitbarkeit in digitalen Kommunikationen zu gewährleisten. | 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. |
| * **Key Management:** Key Management umfasst die Verfahren und Technologien zum Erzeugen, Verteilen, Verwalten, Speichern, und zum finalen Löschen von Kryptografieschlüsseln. Ziel ist es, die Sicherheit der Schlüssel über ihren gesamten Lebenszyklus hinweg zu gewährleisten, da die Sicherheit der verschlüsselten Informationen direkt von der Sicherheit der Schlüssel abhängt. | |
| * **Systemsicherheit:** Systemsicherheit betrachtet übergeordnet den Schutz von Computersystemen und deren Ressourcen vor Missbrauch, Ausfällen, oder unbefugtem Zugriff. Dies schließt physische Sicherheitsmaßnahmen, Betriebssystemsicherheit, Anwendungssoftware-Sicherheit und unterschiedliche Kontrollmechanismen zur Überwachung und Reaktion auf Sicherheitsvorfälle ein. | |
| * **Softwaresicherheit:** Softwaresicherheit konzentriert sich auf die Entwicklung und Implementierung von Software, die frei von Schwachstellen ist und resistent gegenüber Cyberangriffen bleibt. Dies beinhaltet die Anwendung von Sicherheitspraktiken während des gesamten Softwareentwicklungslebenszyklus, um die Einführung und Ausnutzung von Schwachstellen zu verhindern. | |
| * **Cloud-Sicherheit:** Spezifische Praktiken und Technologien zum Schutz von Daten, Anwendungen und Infrastrukturen, die in der Cloud gehostet werden. Dies beinhaltet Verschlüsselung, Zugriffskontrollen, Sicherheitsüberwachung und Compliance-Management. | |
| * **Hardwaresicherheit:** Hardwaresicherheit beschäftigt sich mit dem Schutz von physischen Geräten vor Manipulationen, Diebstahl oder Beschädigung. Dazu gehören Maßnahmen wie physische Absicherung, anti-tampering Technologien und die Integration von Sicherheitsfeatures direkt auf der Hardware-Ebene, z.B. durch Secure-Boot-Mechanismen oder hardwarebasierte Verschlüsselungsunterstützung. | |
| * **Netzwerksicherheit:** Netzwerksicherheit umfasst Maßnahmen und Technologien zum Schutz von Daten während deren Übertragung über Netzwerke. Ziele sind die Gewährleistung der Vertraulichkeit, Integrität und Verfügbarkeit von Daten. Maßnahmen beinhalten Firewalls, Intrusion Detection und Prevention Systeme, Verschlüsselung, sowie Zugriffskontrollen. | |
| * **Security-by-Design:** Security-by-Design ist ein Ansatz in der Entwicklung von IT-Systemen, bei dem Sicherheitsüberlegungen von Anfang an ein integraler Bestandteil des Design- und Entwicklungsprozesses sind, im Gegensatz dazu, Sicherheitsfeatures nachträglich in ein bereits fertiges Produkt einzubauen. Dieser Ansatz strebt an, Sicherheitsrisiken proaktiv zu minimieren. | |
| * **Secure Coding:** Secure Coding bedeutet, Sicherheitsprinzipien bei der Softwareentwicklung konsequent anzuwenden, um Schwachstellen zu vermeiden, die während der Implementierungsphase entstehen können. Es schließt die Anwendung von Best Practices, Richtlinien und Standards ein, die darauf abzielen, sichere Codepraktiken zu fördern und somit die Anfälligkeit für Angriffe zu reduzieren. | |
| === Organisatorische Maßnahmen === | |
| |
| //Anmerkung JP: Need-to-Know-Prinzip, Least-Privilege Prinzip, Separation of Duties, Job Rotation, Security Management (vergl. ISMS, evtl. weiter aufdröseln), Incident Management, Patch Management, (ggf. erweitern) // | 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: |
| * **Security Management (vergl. ISMS):** Security Management umfasst die strategische Planung, Implementierung und Überwachung von Sicherheitsrichtlinien und -verfahren zur Gewährleistung der Integrität, Vertraulichkeit und Verfügbarkeit von Informationssystemen. Ein Informationssicherheitsmanagementsystem (ISMS) ist ein systematischer Ansatz zur Verwaltung sensibler Unternehmensinformationen, so dass sie sicher bleiben. Es beinhaltet Personen, Prozesse und IT-Systeme, indem es einen risikobasierten Ansatz verfolgt. | |
| * **Incident Management:** Incident Management bezieht sich auf den Prozess und die organisatorischen Strukturen, die für das Management der Antwort auf IT-Sicherheitsvorfälle erforderlich sind. Ziel ist es, die Auswirkungen von Sicherheitsvorfällen zu minimieren, die normalen Geschäftsoperationen schnellstmöglich wiederherzustellen und aus den Vorfällen zu lernen, um zukünftige Sicherheitsrisiken zu minimieren. | |
| * **Patch Management:** Patch Management ist der Prozess der Verwaltung von Updates für Software und Systeme, der insbesondere die Identifikation, das Testen und die Implementierung von Patches (Korrekturen oder Updates) umfasst. Ein effektives Patch-Management-Verfahren ist entscheidend, um bekannte Sicherheitslücken zu schließen und das Risiko von Sicherheitsverletzungen zu reduzieren. Es erfordert eine Balance zwischen der schnellen Anwendung kritischer Patches, um Sicherheitsrisiken zu minimieren, und der Notwendigkeit, die Stabilität und Kompatibilität innerhalb der IT-Landschaft zu gewährleisten. | |
| * **Drittanbieter- und Lieferantenrisikomanagement:** Bewertung und Kontrolle der Risiken, die von Dritten ausgehen, mit denen Daten geteilt oder die in kritische Geschäftsprozesse eingebunden sind. Dies kann die Überprüfung der Sicherheitspraktiken von Drittanbietern und die Einführung von Sicherheitsanforderungen in Vertragsvereinbarungen beinhalten. | |
| * **Informationsklassifizierung und -handling:** Entwicklung und Durchsetzung von Richtlinien zur Klassifizierung von Informationen nach ihrem Sicherheitsbedarf sowie entsprechenden Handhabungsprozeduren. Diese organisatorischen Maßnahmen sind entscheidend für die Schaffung eines ganzheitlichen und effektiven Sicherheitsprogramms, das sowohl technische als auch menschliche Faktoren berücksichtigt und sich kontinuierlich an sich ändernde Bedrohungen anpassen kann. | |
| * **Need-to-Know-Prinzip:** Das Need-to-Know-Prinzip besagt, dass Personen nur Zugang zu den Informationen erhalten sollen, die unbedingt notwendig für die Ausübung ihrer Aufgaben sind. Ziel ist es, das Risiko unbeabsichtigter oder beabsichtigter Informationslecks zu minimieren und die Datensicherheit zu erhöhen, indem der Zugriff auf sensible Informationen strikt kontrolliert wird. | |
| * **Least-Privilege Prinzip:** Das Least-Privilege Prinzip (Prinzip der minimalen Rechtevergabe) bedeutet, dass Nutzern und Systemen nur die minimal notwendigen Berechtigungen für die Erfüllung ihrer spezifischen Aufgaben gewährt werden. Dies reduziert das Risiko, dass weitreichende Rechte missbraucht werden oder dass ein Angreifer, der ein Konto kompromittiert, weitreichenden Zugriff innerhalb des Systems erlangen kann. | |
| * **Separation of Duties (Trennung von Verantwortlichkeiten):** Die Trennung von Verantwortlichkeiten ist ein Sicherheitsprinzip, das fordert, kritische Aufgaben so aufzuteilen, dass für deren erfolgreiche Ausführung die Zusammenarbeit mehrerer Personen erforderlich ist. Dies soll Interessenkonflikte vermeiden, Betrug erschweren und die Wahrscheinlichkeit von Fehlern oder unbefugten Handlungen reduzieren. | |
| * **Job Rotation:** Job Rotation bezeichnet den regelmäßigen Wechsel von Mitarbeitern durch verschiedene Positionen oder Aufgabenbereiche. In der IT-Sicherheit wird dieses Prinzip eingesetzt, um das Risiko von Insider-Bedrohungen zu minimieren, da kontinuierliche Veränderungen die Möglichkeiten für längere unbefugte Aktivitäten einschränken. Es fördert zudem die Redundanz von Fachwissen und erhöht die Widerstandsfähigkeit gegenüber Personalausfällen. | |
| === Security in der Praxis === | |
| |
| Die Messung von IT-Sicherheit ist nicht trivial, da der Grad der Sicherheit von Produkten und Systemen nicht direkt messbar ist wie physikalische Größen. Stattdessen müssen indirekte Indikatoren, Metriken und Modelle herangezogen werden, um die Sicherheitseffektivität zu bewerten. Im Folgenden wird ein Überblick über die Vorgehensmodelle und gängiger Methoden zur Messung der IT-Sicherheit gegeben und anschließend auf die rechtlichen Rahmenbedingungen sowie relevante Standards eingegangen. | ^ Kategorie ^ Beziehungsart der Anforderungen ^ Relevante Designwechselwirkung ^ Richtung der Beeinflussung ^ Beispielhafte Betrachtung ^ |
| | | 1 | kohärent oder konsistent | nein | keine | parallele Auslegung von Safety & Security | |
| | | 2 | widersprüchlich | ja | Security → Safety (unidirektional) | IT-Security-Maßnahme verzögert Safety-Funktion | |
| | | 3 | widersprüchlich | ja | Safety → Security (unidirektional) | Safety-Maßnahme erschwert Zutrittskontrolle | |
| | | 4 | widersprüchlich | ja | bidirektional | Panikschloss: Fluchtszenario vs. Zutrittsverhinderung | |
| |
| === Vorgehensmodelle zum Messen von Security === | 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 ===== |
| |
| Die Messung von IT-Sicherheit beginnt mit der Definition von Zielen und Kriterien, die die Sicherheitsanforderungen des Systems widerspiegeln. Diese Anforderungen basieren häufig auf den drei Grundpfeilern der IT-Sicherheit: Vertraulichkeit, Integrität und Verfügbarkeit (CIA-Prinzip). Zusätzlich können je nach Kontext weitere Aspekte wie Authentizität, Zurechenbarkeit und Nicht-Zurückweisbarkeit relevant sein. Deren Erfüllungsgrad lässt sich dann anhand von detaillierten Analysen des Systems bestimmen. Die meisten Ansätze verfahren dabei Risikobasiert, d.h. es wird zunächst eine Risikoanalyse zur Bestimmung der wesentlichen Schwachstellen und deren Schadenspotential durchgeführt. Die Risikoanalyse in der IT-Sicherheit zielt darauf ab, potenzielle Bedrohungen für Informationssysteme zu erkennen und die dadurch verursachten potenziellen Schäden sowie die Wahrscheinlichkeit ihres Auftretens zu bewerten. Sie beinhaltet die systematische Betrachtung von Schwachstellen, Bedrohungsvektoren und potenziellen Auswirkungen eines Sicherheitsvorfalls. Die Risikoanalyse bildet die Basis für das Risikomanagement und die Entwicklung effektiver Sicherheitsstrategien. Modelle wie STRIDE, DREAD, TARA und CVSS helfen dabei, Sicherheitsbedrohungen zu klassifizeren. Jedes dieser Modelle und Frameworks bietet spezifische Perspektiven und Werkzeuge zur Bewertung und Handhabung von Sicherheitsrisiken. Die Auswahl und Kombination der geeigneten Methoden hängt von der spezifischen Ausgestaltung des Systems ab. Häufig wird z.B. das Common Vulnerability Scoring System (CVSS) verwendet, welches ein offener Standard zur Bewertung der Schwere von Sicherheitslücken ist. CVSS bietet eine standardisierte Methode, um die Auswirkungen von Schwachstellen zu quantifizieren und zu vergleichen, indem es ihnen eine Nummer (Score) von 0 bis 10 zuweist, wobei höhere Werte auf eine größere Schwere hindeuten. CVSS Scores helfen bei der Priorisierung von Patch- und Mitigationsmaßnahmen basierend auf der potenziellen Auswirkung einer Schwachstelle. Die Bewertung von Schwachstellen kann über Blackbox-/ Whitebox-Analysen und Penetrationstest erfolgen. Diese ermöglichen unterschiedliche Perspektiven und Herangehensweisen zur Bewertung der IT-Sicherheit. | Der hier beschriebene Fall entspricht der Kategorie 1 der sicherheitsrelevanten Designwechselwirkungen: Die Anforderungen aus Safety und Security sind kohärent oder konsistent – es bestehen keine widersprüchlichen Anforderungen. |
| |
| * **Blackbox-Analyse:** Die Blackbox-Analyse ist ein Ansatz, bei dem der Tester keine Vorabinformationen über das innere Funktionieren des Systems hat. Tester interagieren mit der externen Schnittstelle des Systems (wie einer Webapplikation oder einem Netzwerkdienst), um potenzielle Schwachstellen und Sicherheitslücken rein aus der Perspektive eines externen Angreifers zu identifizieren. Diese Methode ahmt das Vorgehen eines echten Angreifers nach, der typischerweise keinen Zugang zu internen Details des Systems besitzt. Die Blackbox-Analyse kann zeitaufwändig sein, da sie eine umfangreiche Erkundung erfordert, und ist besonders effektiv bei der Identifizierung von Schwachstellen in der Zugriffskontrolle und bei öffentlich zugänglichen Diensten. | **Angriffswirkung auf Safety-Funktionen** |
| * **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. | |
| === 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. | Komplexe Sicherheitsfunktionen in technischen Anlagen und z. B. auch Automobilen sind oft zeitkritisch; ihre sichere Funktion hängt von der schnellen und sicheren Kommunikation in Netzwerken ab. Die allgegenwärtige und zunehmende Vernetzung macht die IT-Sicherheit zu einer der zentralen Herausforderungen der Zukunft. |
| |
| Einige der wichtigsten rechtlichen Rahmenbedingungen sind: | Sicherheitsfunktionen stellen z. B. die rechtzeitige Abschaltung gefährdender Systeme oder Zugangsbeschränkung zu Gefahrenbereichen sicher und schützen somit Leben und körperliche Unversehrtheit. Die technische Umsetzung dieser Funktionen erfordert in der Regel Logik- oder IT-Systeme, die bei gegebener Vernetzung für Cyberangriffe vulnerabel sind. |
| |
| * **NIS2-Richtlinie (EU):** Die Richtlinie über Sicherheit von Netz- und Informationssystemen (NIS2) ist eine überarbeitete Version der ursprünglichen NIS-Richtlinie der Europäischen Union. Sie zielt darauf ab, ein hohes gemeinsames Sicherheitsniveau für Netz- und Informationssysteme in der EU zu gewährleisten. NIS2 erweitert den Anwendungsbereich auf weitere kritische Sektoren und verstärkt die Sicherheits- und Melderequirements für Unternehmen wesentlich. | **Methodische Herausforderungen bei der gemeinsamen Bewertung** |
| * **Cyber Resilience Act (CRA, geplant):** Die Europäische Kommission hat einen Vorschlag für einen „Cyber Resilience Act“ vorgelegt, der darauf abzielt, die Sicherheit von digitalen Produkten und zugehörigen Dienstleistungen innerhalb der EU zu stärken. Der CRA soll Mindestanforderungen an die Cybersicherheit für Produkte mit digitalen Elementen einführen und einen einheitlicheren Rechtsrahmen schaffen. | |
| * **Datenschutz-Grundverordnung (DSGVO):** Die DSGVO ist eine Verordnung der Europäischen Union, die den Schutz personenbezogener Daten und die Freizügigkeit dieser Daten regelt. Sie stellt strenge Anforderungen an die Verarbeitung personenbezogener Daten durch Unternehmen und Organisationen und gibt den Betroffenen weitreichende Rechte. Verstöße gegen die DSGVO können zu hohen Geldstrafen führen. | |
| * **IT-Sicherheitsgesetz (IT-SiG, Deutschland):** Das deutsche IT-Sicherheitsgesetz bildet die nationale Umsetzung der EU-NIS-Richtlinie und adressiert Betreiber kritischer Infrastrukturen. Es verpflichtet diese, bestimmte Mindeststandards an IT-Sicherheit einzuhalten und erhebliche Sicherheitsvorfälle zu melden. Mit dem IT-Sicherheitsgesetz 2.0 wurde der Anwendungsbereich erweitert und die Anforderungen verschärft. | |
| * **Exportkontrolle:** Sowohl auf nationaler Ebene als auch international sind Regelungen zur Exportkontrolle von IT-Sicherheitstechnologien von Bedeutung. Diese Regelungen sollen verhindern, dass sicherheitskritische Technologien, einschließlich Verschlüsselungssoftware und Dual-Use-Güter, in falsche Hände geraten. Länder wie die USA und die Mitgliedstaaten der Europäischen Union haben umfangreiche Bestimmungen erlassen, die den Export bestimmter Technologien beschränken. | |
| === Relevante Standards === | |
| |
| Zertifizierungen spielen eine zentrale Rolle im Bereich der IT-Sicherheit, indem sie Standards für Wissen, Fähigkeiten, Praktiken und Prozesse setzen. | In gängigen Standards der funktionalen Sicherheit, wie IEC 61508 oder ISO 26262, werden quantitative Nachweise der Verfügbarkeit von Sicherheitsfunktionen gefordert – etwa über Ausfallwahrscheinlichkeiten und Diagnosebedeckung. Diese Metriken sind jedoch nicht kompatibel mit denen der IT-Security, da Eintrittswahrscheinlichkeiten für Cyberangriffe in der Regel nicht probabilistisch, sondern nur qualitativ abgeschätzt werden können. |
| |
| //Anmerkung JP: Evtl. kürzen. // | Während sich Safety-Maßnahmen (z. B. SIL, ASIL) quantitativ über Fehlerraten und Zuverlässigkeitskennwerte belegen lassen, ist eine vergleichbare quantitative Bewertung von Security-Maßnahmen nicht möglich. Eine risikobasierte Abwägung zwischen den beiden Domänen ist daher in dieser Kategorie nur eingeschränkt möglich. |
| * **ISO 27001/x (ISMS):** Der internationale Standard ISO/IEC 27001 definiert die Anforderungen für ein Informationssicherheits-Managementsystem (ISMS). Er unterstützt Organisationen dabei, ihre Informationen durch systematische Risikomanagementprozesse sicher zu schützen, wobei die Flexibilität der Implementierung nach den spezifischen Sicherheitsanforderungen der Organisation erlaubt ist. | |
| * **BSI IT-Grundschutz:** Entwickelt vom Bundesamt für Sicherheit in der Informationstechnik (BSI) in Deutschland, bietet der IT-Grundschutz einen umfassenden Ansatz zur Implementierung von Sicherheitsmaßnahmen. Es handelt sich um eine Sammlung von Empfehlungen und Best Practices, die auf der Identifizierung von typischen Gefährdungen und Standard-Sicherheitsmaßnahmen basieren, um ein angemessenes Sicherheitsniveau zu gewährleisten. | |
| * **ISO/IEC 15408 (Common Criteria - CC):** Diese internationale Norm bietet einen Rahmen für die Bewertung der Sicherheit und Vertrauenswürdigkeit von Informations- und Kommunikationstechnikprodukten und -systemen. Sie ermöglicht es Herstellern, ihre Produkte unabhängig prüfen und zertifizieren zu lassen, um so deren Sicherheitseigenschaften transparent zu machen. | |
| * **ISO 62443:** Dieser Standard konzentriert sich auf die industrielle Kommunikationstechnik und spezifiziert Sicherheitsmaßnahmen zum Schutz industrieller Automatisierungssysteme. Es bietet ein Framework zur Absicherung industrieller Automatisierungs- und Kontrollsysteme (IACS) und adressiert Aspekte wie Systemintegrität, Vertraulichkeit und Verfügbarkeit. | |
| * **ISO/SAE 21434:** Ein Standard für die Cybersicherheit in der Automobilindustrie, der sich auf den Engineering-Lebenszyklus von Fahrzeugen konzentriert. Er bietet Richtlinien zur Risikobewertung, zum Design, zur Entwicklung, zur Produktion, zum Betrieb und zur Wartung von Sicherheitssystemen in Fahrzeugen, um deren Cyberresilienz zu stärken. | |
| * **FIPS 140:** Das Federal Information Processing Standard (FIPS) Publication 140 ist ein US-amerikanischer Standard, der die Anforderungen an kryptografische Module festlegt, einschließlich deren Entwurf und Implementierung. Der Standard wird hauptsächlich von Regierungsbehörden und anderen Organisationen verwendet, die sensible, aber unklassifizierte Informationen schützen müssen. | |
| * **NIST Cybersecurity Framework (CSF):** Entwickelt vom National Institute of Standards and Technology (NIST) in den USA, dient dieses Rahmenwerk dazu, Organisationen bei der Verwaltung und Minderung von Cyberrisiken zu unterstützen. Es bietet eine einheitliche Sprache und Methodik für die Einführung einer effektiven Cybersecurity-Praxis und fokussiert auf die Aspekte Identifizieren, Schützen, Erkennen, Reagieren und Wiederherstellen. | |
| === Entwicklung sicherer Produkte === | |
| |
| Anmerkung JP: Evtl. noch SecDevOps ergänzen Der Entwurf, der Betrieb und die Wartung von sicheren Systemen, Prozessen und Produkten wir über das das Security Engineering, einem Teilbereich des Systems Engineering, gewährleistet. Beim Security Engineering geht es darum, angemessenen Schutz vor den Risiken, Bedrohungen und Schwachstellen zu bieten. Der Security Engineering Prozess ist ein systematischer und strukturierter Ansatz, um sicherzustellen, dass Sicherheitsanforderungen während der gesamten Lebensdauer eines Systems oder Produktes berücksichtigt und implementiert werden. Dies schließt die Konzeption, Entwicklung, Implementierung, Wartung und Außerbetriebnahme ein. Im Folgenden wird der Security Engineering Prozess in seinen grundsätzlichen Schritten erläutert: | Da in dieser Kategorie keine widersprüchlichen Anforderungen bestehen, können Sicherheitsmaßnahmen für Safety und Security grundsätzlich unabhängig nebeneinander ausgelegt werden – vorausgesetzt, Angriffswirkungen auf Safety-Funktionen werden in der TARA (Security-Risikoanalyse) angemessen berücksichtigt. |
| |
| - **Identifikation und Bewertung der Assets** Der erste Schritt besteht darin, die schützenswerten Assets zu identifizieren und zu bewerten. Die Bewertung schließt eine Bestimmung der Wichtigkeit jedes Assets und des potentiellen Schadens bei Verlust, Beschädigung oder Missbrauch ein. | ===== 3.2 Security Impact on Availability ===== |
| - **Risikoanalyse** Nach der Identifikation und Bewertung der Assets folgt die Risikoanalyse. Dabei werden potenzielle Bedrohungen und Schwachstellen, die die Sicherheit der Assets beeinträchtigen könnten, identifiziert. Die Risikoanalyse bewertet auch, wie wahrscheinlich es ist, dass ein bestimmtes Risiko eintritt, und welchen potenziellen Schaden es verursachen könnte. | |
| - **Festlegung von Sicherheitszielen und -anforderungen** Basierend auf der Risikoanalyse werden Sicherheitsziele und -anforderungen definiert, die die Richtung für die Gestaltung und Entwicklung von sicherheitskritischen Systemen und Produkten vorgeben. Diese Anforderungen beziehen sich in der Regel auf die Integrität, Verfügbarkeit, Vertraulichkeit und Authentizität der Assets. | |
| - **Entwurf und Entwicklung** In dieser Phase werden Sicherheitskonzepte und -maßnahmen entwickelt und in das Produkt oder System integriert. Dies kann die Auswahl sicherer Hardware- und Softwarekomponenten, die Entwicklung sicherer Protokolle und die Implementierung von Kryptografie beinhalten. | |
| - **Implementierung und Verifikation** Nach der Gestaltung und Entwicklung erfolgt die Implementierung der Sicherheitsmaßnahmen. Anschließend wird eine Verifikation durchgeführt, um sicherzustellen, dass die Sicherheitsanforderungen erfüllt sind. Dies kann durch Tests, Code-Reviews und Sicherheitsaudits geschehen. | |
| - **Betrieb und Wartung** Sicherheit ist ein fortlaufender Prozess. Daher umfasst der Security Engineering Prozess auch den Betrieb und die Wartung von Systemen und Produkten, um zu gewährleisten, dass sie sicher bleiben. Dies schließt regelmäßige Updates, Patch-Management und das Monitoring von Sicherheitsvorfällen ein. | |
| - **Reaktion auf Sicherheitsvorfälle und Wiederherstellung** Der letzte Schritt beinhaltet die Entwicklung und Implementierung von Plänen zur Reaktion auf Sicherheitsvorfälle und zur Wiederherstellung nach einem Vorfall. Dies soll sicherstellen, dass ein System oder Produkt nach einem Sicherheitsvorfall schnell wieder in einen sicheren Zustand zurückgeführt werden kann. Der Security Engineering Prozess ist ein zyklischer und iterativer Prozess, der eine kontinuierliche Bewertung und Anpassung der Sicherheitsmaßnahmen erfordert, um mit den sich ständig weiterentwickelnden Bedrohungen Schritt zu halten. | |
| ==== 4.4 Domänenspezifische Herausforderungen ==== | |
| |
| Die Domänen Embedded Systems, Industrial Control Systems (ICS), Kritische Infrastrukturen (KRITIS), Automotive und Medizintechnik stehen jeweils vor spezifischen Herausforderungen in Bezug auf die Cybersecurity. Diese Herausforderungen ergeben sich aus den besonderen Anforderungen, Einsatzumgebungen und Risiken, die mit jeder Domäne verbunden sind. Im Folgenden wird ein wissenschaftlicher Überblick über diese domänenspezifischen Herausforderungen gegeben: | Kritische Infrastrukturen (KRITIS) sind das Rückgrat moderner Gesellschaften. Die permanente Verfügbarkeit von Energie-, Wasser-, Kommunikations- und Verkehrsinfrastrukturen bildet die Grundlage unserer gesellschaftlichen und wirtschaftlichen Existenz. Infolge der zunehmenden Bedrohungslage – etwa durch hybride Angriffe oder gezielte Cyberattacken – rückt die Resilienz dieser Infrastrukturen verstärkt in den Fokus. |
| |
| * **Embedded Systems:** Embedded Systems sind in vielen Bereichen des täglichen Lebens und der Industrie eingebettet, von einfachen Haushaltsgeräten bis hin zu komplexen Steuerungssystemen. | Dabei ist zwischen unterschiedlichen Bereichen kritischer Infrastrukturen zu unterscheiden: |
| * **Ressourcenbeschränkungen:** Viele Embedded Devices verfügen über beschränkte Rechenleistung, Speicherplatz und Energiekapazität, was die Implementierung umfassender Sicherheitsmechanismen erschwert. | |
| * **Lange Lebenszyklen:** Einige Embedded Devices, wie in der Luft- und Raumfahrt, sind für lange Betriebsdauern ausgelegt, wobei Aktualisierungen oder Patches schwierig umzusetzen sein können. | * Bei physisch-technischen Infrastrukturen wie Strom-, Wasser- oder Verkehrssystemen sind Anforderungen an Verfügbarkeit (Availability) und Schutz vor Angriffen (Security) in der Regel konsistent. Die IT-Sicherheitsmaßnahmen zielen hier auf den Erhalt der Betriebsfähigkeit ab, ohne die Availability zu gefährden (Kategorie 1). |
| * **Heterogenität und Kompatibilität:** Die Vielfalt der Hardware und Software in Embedded Systems erschwert die Standardisierung von Sicherheitslösungen. | * Bei IT- und Telekommunikationsinfrastrukturen können sich hingegen Security-Maßnahmen negativ auf die Availability auswirken. Beispielsweise können Segmentierungen, Firewalls oder Verschlüsselungstechnologien durch Fehlkonfiguration oder Sperrmechanismen zu Verzögerungen oder Ausfällen führen (Kategorie 2). |
| * **Industrie und Produktionsanlage / Industrial Control Systems (ICS):** ICS sind kritische Komponenten in der Fertigungs- und Versorgungsindustrie, deren Kompromittierung weitreichende physische Schäden verursachen kann. | |
| * **Verfügbarkeit vs. Vertraulichkeit:** Im Gegensatz zu herkömmlichen IT-Systemen liegt der Fokus bei ICS auf der Verfügbarkeit und Integrität der Systeme. Die Sicherstellung der Vertraulichkeit ist oft von sekundärer Bedeutung. | Von Angriffen – ob terroristisch, kriminell, staatlich oder anderweitig motiviert – können sehr viele Menschen gleichzeitig betroffen sein. Wechselwirkungen zwischen physischer und IT-bezogener Security müssen daher berücksichtigt werden, etwa bei der Sicherung von SCADA-Systemen oder Rechenzentren. Dies erfordert die Entwicklung abgestimmter, semi-quantitativer Metriken zur Bewertung von Security-Maßnahmen unter Availability-Gesichtspunkten. |
| * **Alte und proprietäre Systeme:** Viele ICS laufen auf veralteten oder proprietären Systemen, für die es schwierig ist, Sicherheitspatches zu erhalten oder zu implementieren. | |
| * **Netzwerkisolierung:** Obwohl die Isolierung von Steuerungsnetzwerken von der übrigen IT-Infrastruktur als Schutzmaßnahme gilt, wird sie zunehmend schwieriger, da ICS immer öfter remote überwacht und gesteuert werden. | **Lösungsansätze**: |
| * **Kritische Infrastrukturen (KRITIS):** KRITIS umfassen Einrichtungen und Dienste, die für das Funktionieren der Gesellschaft wesentlich sind, wie Energieversorgung, Wasserwirtschaft und Gesundheitsdienste. | |
| * **Hohe Anforderungen an die Ausfallsicherheit:** Ausfälle oder Beeinträchtigungen können gravierende Auswirkungen auf die öffentliche Sicherheit haben. | Ein belastbarer Lösungsansatz besteht in der abgestimmten Betrachtung von IT-Sicherheit, physischem Schutz und Verfügbarkeitsanforderungen in einer integrierten Analyse. Für physisch-technische Infrastrukturen steht der Erhalt der operativen Verfügbarkeit im Vordergrund. Für IT-/TK-Infrastrukturen hingegen sind spezifische Gegenmaßnahmen gegen Angriffe zu entwickeln, die die Verfügbarkeit nicht gefährden. |
| * **Zielscheibe für staatlich unterstützte Angreifer:** Aufgrund ihrer Bedeutung sind KRITIS oft Ziele für Cyberangriffe mit staatlicher Unterstützung oder mit der Absicht, der Gesellschaft Schaden zuzufügen. | |
| * **Komplexität und Verwundbarkeit:** Die Vernetzung und Abhängigkeit zwischen verschiedenen KRITIS erhöht die Angriffsfläche und potenzielle Auswirkungen von Cyberangriffen. | Die gesetzlichen Vorgaben – etwa das BSI-Gesetz, die KRITIS-Verordnung oder das neue KRITIS-Dachgesetz – fordern die Einhaltung des 'Standes der Technik'. Dieser ist jedoch interpretationsbedürftig und dynamisch. Die Entwicklung validierbarer Kriterien und abgestimmter Bewertungsskalen ist daher ein zentrales Forschungs- und Praxisziel. |
| * **Automotive:** Die zunehmende Vernetzung und Automatisierung in Fahrzeugen führt zu neuen Sicherheitsrisiken. | |
| * **Komplexe Lieferkette:** Die Automotive-Industrie kennzeichnet eine komplexe Lieferkette, die die Konsistenz und Zuverlässigkeit von Sicherheitsmaßnahmen erschwert. | ===== 3.3 Security Requirements Undermining Safety ===== |
| * **Sicherheit des Fahrzeuglebenszyklus:** Die langfristige Sicherung von Fahrzeugen vom Entwurf bis zur Verschrottung ist eine Herausforderung, insbesondere in Bezug auf Softwareupdates und Patches. | |
| * **Datenschutz:** Die Sammlung und Übertragung persönlicher Daten durch vernetzte Fahrzeuge stellt Herausforderungen für den Datenschutz dar. | In sicherheitskritischen Systemen kann es zu Situationen kommen, in denen Security-Anforderungen die Wirksamkeit oder rechtzeitige Ausführung von Safety-Funktionen behindern. Solche Fälle sind besonders kritisch, da der Schutz von Menschenleben durch Safety-Funktionen in der Regel oberste Priorität hat. Eine solche Konstellation stellt eine eigene Kategorie in der Betrachtung von Safety-Security-Wechselwirkungen dar, die sich von klassischen Angriffswirkungen (Security Impact on Safety) unterscheidet. |
| * **Medizintechnik:** Geräte im Gesundheitswesen sind besonders sensibel, da sie unmittelbar Patientendaten verarbeiten und lebenserhaltende Funktionen ausführen. | |
| * **Lebensrettende Geräte:** Die Sicherheit von Medizingeräten ist kritisch, da Fehlfunktionen direkt das Leben von Patienten gefährden können. | Während bei Angriffswirkungen die Kompromittierung durch eine externe Bedrohung erfolgt, geht es in dieser Kategorie um Designentscheidungen oder Sicherheitsanforderungen, die aus der Security-Domäne stammen und unbeabsichtigt Safety-Funktionen beeinträchtigen. Die Herausforderung liegt hier nicht in der quantitativen Risikobewertung, sondern in der szenariobasierten Analyse möglicher Konflikte und ihrer technischen Entkopplung. |
| * **Datenschutz und Compliance:** Medizingeräte verarbeiten hochsensible Patientendaten und müssen strenge Datenschutzbestimmungen wie die europäische Datenschutz-Grundverordnung (DSGVO) einhalten. | |
| * **Geräteaktualisierungen:** Viele Medizingeräte sind schwer zugänglich und können nur mit erheblichem Aufwand aktualisiert werden, was die Behebung von Sicherheitslücken erschwert. | **Typische Szenarien** |
| ===== 5 Risikobegriff im Kontext von Funktionaler Sicherheit ===== | |
| | Verzögerung sicherheitskritischer Aktionen durch Authentifizierung: In IT-gestützten Safety-Funktionen kann eine starke Zugriffskontrolle (z. B. PIN, Token, Zwei-Faktor) im Notfall wertvolle Zeit kosten. Dies gilt z. B. für Sicherheitssysteme in der Industrie oder im Automotive-Bereich. |
| | * **Sicherheitsupdates beeinträchtigen Safety-Verfügbarkeit**: Regelmäßige Software-Updates zur Schließung von Security-Lücken können Systemneustarts oder zeitweilige Nichtverfügbarkeit sicherheitskritischer Systeme erfordern. |
| | * **Netzwerksegmentierung unterbricht Safety-Kommunikation**: Strikte Trennung von Netzwerken aus Security-Gründen kann zu unerwünschten Kommunikationsbarrieren führen, insbesondere bei verteilten Safety-Funktionen. |
| | * **Verschlüsselung verursacht Verzögerung oder Inkompatibilität**: Wenn Safety-relevante Daten verschlüsselt übertragen werden, kann dies zu Verzögerungen oder Datenverlusten führen, z. B. in Fahrzeugnetzwerken oder verteilten Industrieanlagen. |
| | * **IT-KRITIS-Ausfall mit Safety-Folgen**: Bei kritischen IT- oder Kommunikationsinfrastrukturen (z. B. GNSS, Zeitserver, SCADA-Netze) können Ausfälle auch sicherheitsrelevante physische Systeme betreffen. Diese Fälle wurden in Abschnitt 3.2 bereits behandelt. |
| | |
| | **Lösungsansätze** |
| | In der Regel ist der Schutz von Menschenleben höher zu priorisieren als der Schutz technischer Systeme oder Daten. Deshalb sollte bei potenziellen Konflikten zwischen Security- und Safety-Zielen stets eine szenarienabhängige Entkopplung geprüft werden. Mögliche Maßnahmen umfassen: |
| | |
| | * Einsatz technischer Entkopplungsmechanismen (z. B. sicherheitsgerichtete Bypass-Funktionen, notfallfähige Benutzeroberflächen) |
| | * Entwicklung intelligenter Umschaltlogiken oder „Fail-Safe“-Strategien |
| | * Klassifikation sicherheitskritischer Kommunikation als „prioritär“ in Netzwerken, auch unter Security-Randbedingungen |
| | * Dokumentation und risikoorientierte Freigabe von Update-Zeitpunkten und Sicherheitsmaßnahmen |
| | |
| | Die Designentscheidung sollte unter Berücksichtigung von Worst-Case-Szenarien getroffen werden, in denen Safety-Funktionen kompromittiert werden könnten. Eine rein technische Betrachtung reicht nicht aus – es ist auch eine ethische Bewertung erforderlich, wenn Zielkonflikte auftreten. |
| | |
| | ===== 3.4 Safety Requirements Undermining Security ===== |
| | |
| | In der dritten Kategorie der Wechselwirkungen beeinflussen Anforderungen oder Maßnahmen aus dem Bereich Safety die Ausgestaltung und Wirksamkeit von Security-Maßnahmen. Diese Wechselwirkungen sind unidirektional: Eine Vorgabe oder Maßnahme aus der funktionalen Sicherheit schränkt Möglichkeiten zur Absicherung gegenüber gezielten Angriffen ein – z. B. durch Redundanzanforderungen, Notfallzugänge oder Entkopplung sicherheitskritischer Systeme. |
| | |
| | **Vorgeschriebene Notöffnungen vs. Zugangsschutz** |
| | |
| | In sicherheitskritischen Anlagen (z. B. Kernkraftwerke, chemische Industrie) kann eine Safety-Vorgabe erfordern, dass sich Türen bei Feuer oder Stromausfall automatisch öffnen müssen – unabhängig davon, ob eine unautorisierte Person gerade Zugang hätte. Dadurch wird ein zuvor sicherer Zugang (Security) durch eine Safety-Funktion untergraben. |
| | |
| | **Entkoppelung redundanter Systeme** |
| | |
| | Aus Safety-Gründen wird häufig Redundanz eingeführt (z. B. Redundanz bei Steuerungen oder Netzwerken). Wenn diese redundanten Systeme aus Safety-Sicht bewusst voneinander getrennt (entkoppelt) gehalten werden, können zentrale Security-Mechanismen wie eine durchgehende Zugangskontrolle oder einheitliches Patch-Management behindert werden. |
| | |
| | **Bypass-Schaltungen für Diagnose- oder Wartungszwecke** |
| | |
| | Für Wartung und Instandhaltung (oft aus Safety-Gründen) existieren oft Bypass-Schaltungen oder spezielle Zugriffsmöglichkeiten, die in Notfällen oder zu Diagnosezwecken aktiviert werden dürfen. Diese können potenziell ein Security-Loch darstellen, wenn sie nicht ausreichend abgesichert oder überwacht werden. |
| | |
| | **Mensch-Maschine-Schnittstellen mit Safety-Fokus** |
| | |
| | Bestimmte Anforderungen an Benutzerfreundlichkeit oder Erreichbarkeit von Not-Aus-Schaltern können Sicherheitsmaßnahmen wie Zugriffskontrolle (z. B. über PINs, Karten oder biometrische Daten) unterlaufen – z. B. weil eine schnelle Reaktionsfähigkeit als übergeordneter Safety-Wert gilt. |
| | |
| | **Priorisierung von Safety-Meldungen in Kommunikationsnetzen** |
| | |
| | In manchen Protokollen oder Echtzeitnetzwerken werden Safety-bezogene Datenpakete priorisiert übertragen, was zu Verzögerungen oder Paketverlusten bei Security-Meldungen führen kann (z. B. Alarmierung bei einem Einbruch oder Angriff). |
| | |
| | Diese Beispiele zeigen, dass auch Safety-Anforderungen in bestimmten Konstellationen sicherheitsrelevante Wechselwirkungen hervorrufen können. Solche Szenarien sind sorgfältig zu prüfen – auch wenn die Priorisierung der Safety-Funktion in vielen Fällen gerechtfertigt ist, muss die potenzielle Schwächung von Security-Maßnahmen im Gesamtsystem mitgedacht werden. |
| | |
| | ===Abwägung und Priorisierung=== |
| | Auch wenn die Wahrscheinlichkeit und Relevanz solcher Szenarien geringer ist als bei der umgekehrten Wechselwirkung (Security Impact on Safety), sollte die Möglichkeit dennoch im Designprozess berücksichtigt werden – insbesondere in besonders kritischen Infrastrukturen wie der Kerntechnik. |
| | |
| | Dabei gilt weiterhin die grundlegende Empfehlung: Der Schutz von Menschenleben (in diesem Kontext: Safety) hat in sicherheitsrelevanten Anwendungen grundsätzlich Vorrang. Security-Maßnahmen dürfen die Wirksamkeit von Safety-Funktionen nicht kompromittieren – aber umgekehrt ist auch zu vermeiden, dass Safety-Maßnahmen potenzielle Sicherheitslücken verursachen oder Schutzmechanismen im Bereich Security unterlaufen. |
| | |
| | |
| | ===== 3.5 Contradicting Safety-Security Requirements ===== |
| | Die hier beschriebenen Konstellationen entsprechen Kategorie 4 – also Fällen widersprüchlicher Anforderungen an Safety- und Security-Funktionen mit potenziell sicherheitsrelevanten Wechselwirkungen. In diesen Fällen sind Safety- und Security-Ziele nicht gleichzeitig erfüllbar, sondern konkurrieren miteinander. |
| | |
| | Ein klassisches Beispiel ist die Gebäudesicherheit: Fluchtmöglichkeiten im Brandfall (Safety) können durch verriegelte Türen (Security) behindert werden. Technische Maßnahmen wie Panikschlösser oder Pushbars dienen dazu, diese Anforderungen szenarioabhängig zu entkoppeln. Solche Lösungen ermöglichen eine automatische oder manuelle Umschaltung des Systemverhaltens je nach Bedrohungslage – etwa Feueralarm vs. Einbruch. |
| | |
| | Ein besonders tragischer Fall eines ungelösten Zielkonflikts war der Absturz des Germanwings-Flugs 9525: Die Cockpittür war aus Sicherheitsgründen (Security) gepanzert und nicht aufzubrechen. Im Notfall kann sie mit einem Code von außen geöffnet werden (Safety), allerdings lässt sich dieser Mechanismus aus dem Cockpit heraus blockieren (Security). Dies führte dazu, dass die Crew den Suizid des Piloten nicht verhindern konnte – 150 Menschen starben. Dieses Beispiel illustriert eindrücklich die sicherheitsrelevanten Konsequenzen widersprüchlicher Anforderungen. |
| | |
| | Auch in der Nukleartechnik entstehen Zielkonflikte: Maßnahmen gegen Sabotage (Security) können betriebliche Anforderungen an Redundanz oder Reaktionszeiten (Safety) beeinträchtigen. Derartige Widersprüche lassen sich nicht vollständig auflösen, sondern erfordern eine bewusste Abwägung. |
| | |
| | Das Problem bei der Abwägung liegt vor allem in der Unsicherheit: Während aleatorische Unsicherheiten (z. B. bei Komponentenausfällen) probabilistisch modellierbar sind, handelt es sich bei der Eintrittswahrscheinlichkeit von Angriffen meist um epistemische Unsicherheiten – also um nicht objektivierbare Einschätzungen. Eine belastbare Risikoabwägung zwischen Safety und Security ist daher nur sehr eingeschränkt möglich. |
| | |
| | Lösungsansätze bestehen unter anderem in der Entwicklung technischer Entkopplungsmechanismen und semi-quantitativer Bewertungsverfahren. Diese sollen dabei helfen, Prioritäten, Wirkungsgrade und Zielkonflikte nachvollziehbar zu machen. Letztlich müssen sicherheitsrelevante Entscheidungen jedoch immer auch ethische und gesellschaftliche Aspekte berücksichtigen. |
| | |
| | Im Gegensatz zu Kategorie 1 (kohärente Anforderungen) und Kategorie 2 (unidirektionale Beeinflussung durch Security auf Availability oder Safety) sind die Zielkonflikte der hier betrachteten Kategorie 4 besonders komplex, da sie eine simultane, gleichwertige Betrachtung beider Schutzziele erfordern. |
| | |
| | ===== 3.6 Cyberphysical Systems ===== |
| | |
| | Cyberphysische Systeme (CPS) sind Systeme, in denen physische Prozesse, IT-Komponenten und Kommunikationstechnologien so eng miteinander verknüpft sind, dass eine getrennte Betrachtung von Safety, IT-Security und physischer Sicherheit kaum noch möglich ist. Sie stellen nicht nur ein zentrales Anwendungsfeld für die kombinierte Sicherheitsbewertung dar, sondern fordern die etablierten Paradigmen der Sicherheit in ihrer Grundstruktur heraus. |
| | |
| | **Verwobene Sicherheitsdomänen** |
| | |
| | In CPS greifen Sicherheitsfunktionen aus allen Domänen – funktionale Sicherheit (Safety), IT-Security und physische Security – unmittelbar ineinander: |
| | |
| | * Ein physischer Angriff auf ein Rechenzentrum oder SCADA-System kann systemweit alle IT- und Steuerungsfunktionen kompromittieren. |
| | * Ein Cyberangriff auf eine Zugangskontrolle kann physische Sicherheitsmaßnahmen außer Kraft setzen. |
| | * IT-gesteuerte Drohnenangriffe können etablierte physische Sicherheitsarchitekturen wie Zäune, Schleusen oder Perimeterüberwachung vollständig unterlaufen, bzw. überfliegen. |
| | |
| | **Globale Wirkung lokaler Störungen** |
| | |
| | Die immanente IT-Verknüpfung in CPS führt dazu, dass lokale Ereignisse globale Auswirkungen haben können: |
| | |
| | * Ein Angriff an einem Netzknoten kann kritische Steuerungsprozesse in entfernten Regionen lahmlegen. |
| | * Die Kopplung von Safety-Funktionen an IT-Systeme bedeutet: ein lokaler Security-Vorfall kann global sicherheitsrelevante Funktionen aushebeln – z. B. Notabschaltungen, Brandschutz, oder Verkehrsregelung. |
| | |
| | **Auflösung klassischer Sicherheitsgrenzen** |
| | |
| | Während frühere Sicherheitskonzepte meist klar zwischen physischen und digitalen Angriffsvektoren unterschieden, verwischen diese Grenzen zunehmend. Der Schutz technischer Systeme muss daher domänenübergreifend gedacht werden: |
| | |
| | **Lösungsansätze** |
| | |
| | Cyberphysische Systeme benötigen neue, integrative Ansätze, z.B.: |
| | |
| | * Szenariobasierte Risikoanalysen, die Safety-, IT- und physische Risiken gemeinsam bewerten |
| | * Kopplung etablierter Methoden (FMEA, Fault Tree, HARA, TARA) zu domänenübergreifenden Modellen |
| | * Dynamisch adaptierbare Schutzstrategien, die im Notfall automatische Umschaltungen oder Priorisierungen erlauben |
| | * Technische Mechanismen zur zuverlässigen Entkopplung von Szenarien |
| | ====== 4. Funktionale Sicherheit ====== |
| | |
| | Die Funktionale Sicherheit ist ein zentraler Bestandteil der technischen Sicherheit von Maschinen und Anlagen. Sie bezieht sich auf Sicherheitsfunktionen, die durch Steuerungs- und Automatisierungstechnik realisiert werden, um Risiken systematisch zu mindern. Im Mittelpunkt steht die Beherrschung von Gefährdungen durch gezielte technische Maßnahmen, wie z. B. Sensorik, Logik und Aktorik, deren zuverlässiges Zusammenspiel essenziell ist, um gefährliche Situationen zu erkennen und darauf zu reagieren. |
| | |
| | Dieser Abschnitt erklärt grundlegende Konzepte wie Risiko, Sicherheitsfunktionen, Ausfallwahrscheinlichkeiten (PFD/PFH), Safety Integrity Level (SIL), typische Fehlerarten und Schutzmaßnahmen. Dabei wird die Normenbasis (insbesondere IEC 61508) ebenso betrachtet wie konkrete Beispiele und bewährte Methoden zur Entwicklung sicherer Systeme. |
| | |
| | → Für detaillierte Inhalte klicken Sie auf **„Mehr Informationen“**. |
| |
| Autor: David Schepers | ++++ Mehr Informationen| |
| |
| Risiko bezogen auf eine Gefährdung wird in der Disziplin der Funktionalen Sicherheit in Abhängigkeit von Schadensausmaß und Eintrittswahrscheinlichkeit bewertet. Übergeordnetes Ziel ist es, unzulässig hohe Risiken auf ein tolerierbares Maß zu mindern. Welches Maß an Risiko noch als tolerierbar angesehen wird, hängt vom Grad der Akzeptanz in der jeweiligen Gesellschaft ab. | Risiko bezogen auf eine Gefährdung wird in der Disziplin der Funktionalen Sicherheit in Abhängigkeit von Schadensausmaß und Eintrittswahrscheinlichkeit bewertet. Übergeordnetes Ziel ist es, unzulässig hohe Risiken auf ein tolerierbares Maß zu mindern. Welches Maß an Risiko noch als tolerierbar angesehen wird, hängt vom Grad der Akzeptanz in der jeweiligen Gesellschaft ab. |
| |
| \\ | \\ Im Bereich Maschinen und Anlagen zum Beispiel werden zunächst mögliche Gefährdungen identifiziert. Der Begriff „Gefährdung“ bezieht sich hierbei auf jede potentielle Schadensquelle, welche von einer Maschine oder Anlage für Mensch und Umwelt ausgeht. Anschließend werden die Gefährdungen hinsichtlich ihres realen Risikos bewertet. Risiko wird wie eingangs erwähnt als eine „Kombination aus der Wahrscheinlichkeit, mit der ein Schaden auftritt, und dem Ausmaß dieses Schadens“ definiert (vgl. IEC 61508-1). Die Eintrittswahrscheinlichkeit hängt dabei von der Gefährdungsexposition, der Wahrscheinlichkeit, dass die Gefährdungssituation überhaupt eintritt sowie der Möglichkeit zur Vermeidung oder Begrenzung des Schadens ab (siehe Abbildung 1). |
| Im Bereich Maschinen und Anlagen zum Beispiel werden zunächst mögliche Gefährdungen identifiziert. Der Begriff „Gefährdung“ bezieht sich hierbei auf jede potentielle Schadensquelle, welche von einer Maschine oder Anlage für Mensch und Umwelt ausgeht. Anschließend werden die Gefährdungen hinsichtlich ihres realen Risikos bewertet. Risiko wird wie eingangs erwähnt als eine „Kombination aus der Wahrscheinlichkeit, mit der ein Schaden auftritt, und dem Ausmaß dieses Schadens“ definiert (vgl. IEC 61508-1). Die Eintrittswahrscheinlichkeit hängt dabei von der Gefährdungsexposition, der Wahrscheinlichkeit, dass die Gefährdungssituation überhaupt eintritt sowie der Möglichkeit zur Vermeidung oder Begrenzung des Schadens ab (siehe Abbildung 1). | |
| |
| {{ :625d820ab4b41220ac816b4663206734.png }} | {{ :625d820ab4b41220ac816b4663206734.png }} |
| Die im Kontext der Funktionalen Sicherheit definierten Maßnahmen zielen im Wesentlichen darauf ab, (gefahrbringende) systematische Fehler zu vermeiden oder – wenn möglich – zu beherrschen und (gefahrbringende) zufällige Ausfälle zu beherrschen (zufällige Bauteilausfälle können nicht vermieden werden). Die Grundnorm IEC 61508 „Funktionale Sicherheit sicherheitsbezogener elektrischer/elektronischer/programmierbarer elektronischer Systeme“ (Teile 1 bis 7) definiert Anforderungen zur Vermeidung oder Beherrschung systematischer Fehler in Hardware und Software sowie zur Beherrschung zufälliger Hardware-Ausfälle. | Die im Kontext der Funktionalen Sicherheit definierten Maßnahmen zielen im Wesentlichen darauf ab, (gefahrbringende) systematische Fehler zu vermeiden oder – wenn möglich – zu beherrschen und (gefahrbringende) zufällige Ausfälle zu beherrschen (zufällige Bauteilausfälle können nicht vermieden werden). Die Grundnorm IEC 61508 „Funktionale Sicherheit sicherheitsbezogener elektrischer/elektronischer/programmierbarer elektronischer Systeme“ (Teile 1 bis 7) definiert Anforderungen zur Vermeidung oder Beherrschung systematischer Fehler in Hardware und Software sowie zur Beherrschung zufälliger Hardware-Ausfälle. |
| |
| \\ | \\ Bei der Auslegung der Software und Hardware nach IEC 61508 werden hierzu insbesondere die fünf folgenden Maßnahmen angewendet: |
| Bei der Auslegung der Software und Hardware nach IEC 61508 werden hierzu insbesondere die fünf folgenden Maßnahmen angewendet: | |
| |
| - Anwendung von Redundanz: Verwendung von mehr als einem Mittel zum Ausführen einer geforderten Funktion. Bei einem möglichen Ausfall eines Bauteils oder einer Komponente kann die Funktion von der redundanten Komponente weiterhin ausgeführt werden. Dadurch können zufällige Ausfälle beherrscht werden. Die IEC 61508 definiert die Kenngröße HFT (Hardware Fault Tolerance – Hardware-Fehlertoleranz) zur Beschreibung der Hardware-Struktur von (Teil-)Systemen, welche für die Realisierung einer Sicherheitsfunktionen verwendet wird. HFT = 0 entspricht hierbei z. B. einer einkanaligen Struktur, da der erste (gefahrbringende) Ausfall direkt zum Verlust der Sicherheitsfunktion führen würde. HFT = 1 entspricht dementsprechend einer zweikanaligen Struktur, da ein (gefahrbringender) Ausfall in einem Kanal bei dieser Auslegung noch tolerierbar wäre, wohingegen ein weiterer Ausfall eines Kanals den Verlust der Sicherheitsfunktion zur Folge hätte. HFT = 2 entspricht einer dreikanaligen Struktur usw. | - Anwendung von Redundanz: Verwendung von mehr als einem Mittel zum Ausführen einer geforderten Funktion. Bei einem möglichen Ausfall eines Bauteils oder einer Komponente kann die Funktion von der redundanten Komponente weiterhin ausgeführt werden. Dadurch können zufällige Ausfälle beherrscht werden. Die IEC 61508 definiert die Kenngröße HFT (Hardware Fault Tolerance – Hardware-Fehlertoleranz) zur Beschreibung der Hardware-Struktur von (Teil-)Systemen, welche für die Realisierung einer Sicherheitsfunktionen verwendet wird. HFT = 0 entspricht hierbei z. B. einer einkanaligen Struktur, da der erste (gefahrbringende) Ausfall direkt zum Verlust der Sicherheitsfunktion führen würde. HFT = 1 entspricht dementsprechend einer zweikanaligen Struktur, da ein (gefahrbringender) Ausfall in einem Kanal bei dieser Auslegung noch tolerierbar wäre, wohingegen ein weiterer Ausfall eines Kanals den Verlust der Sicherheitsfunktion zur Folge hätte. HFT = 2 entspricht einer dreikanaligen Struktur usw. |
| Den unterschiedlichen Safety Integrity Level werden feste gefahrbringende Ausfallwahrscheinlichkeiten zugeordnet, welche nicht überschritten werden dürfen. Je höher der angestrebte SIL ist, desto niedriger muss die gefahrbringende Ausfallwahrscheinlichkeit der Sicherheitsfunktion sein. Dazu ist ein rechnerischer Nachweis erforderlich, nämlich die Berechnung von PFH oder PFD. Weiterhin werden nach SIL abgestufte Anforderungen an die Struktur der Hardware und die Anwendung fehlervermeidender Maßnahmen bei der Entwicklung der Hardware und Software definiert. Grundsätzlich gilt, dass für höhere Stufen der Sicherheitsintegrität die fehlervermeidenden Maßnahmen zunehmend umfangreicher werden. | Den unterschiedlichen Safety Integrity Level werden feste gefahrbringende Ausfallwahrscheinlichkeiten zugeordnet, welche nicht überschritten werden dürfen. Je höher der angestrebte SIL ist, desto niedriger muss die gefahrbringende Ausfallwahrscheinlichkeit der Sicherheitsfunktion sein. Dazu ist ein rechnerischer Nachweis erforderlich, nämlich die Berechnung von PFH oder PFD. Weiterhin werden nach SIL abgestufte Anforderungen an die Struktur der Hardware und die Anwendung fehlervermeidender Maßnahmen bei der Entwicklung der Hardware und Software definiert. Grundsätzlich gilt, dass für höhere Stufen der Sicherheitsintegrität die fehlervermeidenden Maßnahmen zunehmend umfangreicher werden. |
| |
| \\ | \\ Ein einfaches Beispiel soll die zuvor genannten Maßnahmen grundlegend erläutern: |
| Ein einfaches Beispiel soll die zuvor genannten Maßnahmen grundlegend erläutern: | |
| |
| Betrachtet wird eine Sicherheitsfunktion zur Überwachung der Temperatur in einem chemischen Reaktor. In dem Reaktor soll die Temperatur einer Chemikalie auf einem konstanten Niveau gehalten werden. Dazu kann ein Heizelement ein- oder ausgeschaltet werden. Dies wird durch eine (nicht sichere) Regelungsfunktion übernommen. Es besteht jedoch die Gefahr, dass die Regelungsfunktion versagt, z. B. falls das Heizelement auf Grund eines Fehlers nicht mehr abgeschaltet wird. Dadurch könnte die Chemikalie eine kritische Temperatur annehmen, was anschließend zu einem Bersten des Reaktors führen könnte. Eine Sicherheitsfunktion soll dieses Risiko geeignet mindern. Dazu wird folgende Sicherheitsfunktion definiert: Abschalten der elektrischen Energieversorgung des Heizelements bei Überschreiten einer festgelegten Temperaturgrenze. | Betrachtet wird eine Sicherheitsfunktion zur Überwachung der Temperatur in einem chemischen Reaktor. In dem Reaktor soll die Temperatur einer Chemikalie auf einem konstanten Niveau gehalten werden. Dazu kann ein Heizelement ein- oder ausgeschaltet werden. Dies wird durch eine (nicht sichere) Regelungsfunktion übernommen. Es besteht jedoch die Gefahr, dass die Regelungsfunktion versagt, z. B. falls das Heizelement auf Grund eines Fehlers nicht mehr abgeschaltet wird. Dadurch könnte die Chemikalie eine kritische Temperatur annehmen, was anschließend zu einem Bersten des Reaktors führen könnte. Eine Sicherheitsfunktion soll dieses Risiko geeignet mindern. Dazu wird folgende Sicherheitsfunktion definiert: Abschalten der elektrischen Energieversorgung des Heizelements bei Überschreiten einer festgelegten Temperaturgrenze. |
| * VDI-EE 4020: Einführung in die Funktionale Sicherheit | * VDI-EE 4020: Einführung in die Funktionale Sicherheit |
| * VDI/VDE 2180: Funktionale Sicherheit in der Prozessindustrie | * VDI/VDE 2180: Funktionale Sicherheit in der Prozessindustrie |
| | ++++ |
| |
| ===== 6 Risiko- und Sicherheitsmetriken ===== | ====== 5. Querschnittsthemen ====== |
| |
| Die Entwicklung des Risikomodells könnte in drei Entwicklungsschritten erfolgen: 1. Definition eines übergeordneten [[:start#definition_risikobegriff|Risikobegriffs]] 2. Entwicklung eines ganzheitlichen [[:start#definition_risikobegriff|Risikomodells]] 3. Betrachtung von [[:start#betrachtung_von_unsicherheiten|Unsicherheiten]] | Themen wie IT-Security, Resilienz und ethische Aspekte sind keine eigenständigen Disziplinen im engeren Sinne, sondern betreffen alle sicherheitsrelevanten Fachgebiete gleichermaßen. Sie wirken disziplinübergreifend, durchziehen technische, organisatorische und gesellschaftliche Fragestellungen und sind für jede Domäne – von der Automobilsicherheit bis hin zur kritischen Infrastruktur – von grundlegender Bedeutung. |
| |
| ==== 6.1 Definition Risikobegriff ==== | ===== 5.1 IT-Security ===== |
| |
| In einem ersten Schritt wird die Entwicklung einer einheitlichen abstrakten Definition des Risikobegriffs angestrebt, die eine ganzheitliche Beschreibung der Domänen Safety und Security ermöglicht. Hierzu sollen vorhandene Ansätze zur risikobasierten Modellierung sowohl von Safety als auch Security kritisch analysiert und eingeordnet werden. Durch die inhaltliche Zusammenführung der Ansätze soll sich eine Definition des Risikobegriffs ergeben, der es ermöglicht, die spezifischen Eigenschaften von Safety und Security und ihrer Aspekte abzubilden. Hierzu notwendige Parameter zur Analyse des Risikos, die einer quantitativen Betrachtung zugänglich sind, sollen eingeführt werden. | Die Sicherheit informationstechnischer Systeme ist ein zentraler Aspekt moderner digitaler Infrastrukturen. In diesem Kapitel werden grundlegende Schutzziele, technische und organisatorische Maßnahmen sowie praxisnahe Ansätze zur Gewährleistung der IT-Sicherheit vorgestellt. Darüber hinaus wird ein Überblick über relevante Standards, rechtliche Rahmenbedingungen sowie domänenspezifische Herausforderungen gegeben, die im Kontext kritischer Systeme wie Automotive, KRITIS, Medizintechnik oder Embedded Systems besonders ins Gewicht fallen. |
| |
| Denkbar ist beispielsweise die Verwendung eines mehrgliedrigen Risikobegriffs. Im Bereich Safety werden meist die zwei Parameter //Eintrittswahrscheinlichkeit// und //Auswirkung// betrachtet, wobei abweichend zum Beispiel in IEC 61508 vier Parameter zur Betrachtung des Risikos herangezogen werden. Im Gegensatz hierzu wird im Bereich Security zumeist ein dreigliedriges Risikomodell betrachtet, das neben der Auswirkung als Risikofaktor die Eintrittswahrscheinlichkeit in //Bedrohung// und //Verwundbarkeit// aufteilt. | Ziel ist es, ein systematisches Verständnis für die Prinzipien, Methoden und Anforderungen der IT-Sicherheit zu vermitteln – sowohl aus theoretischer Sicht als auch mit Blick auf konkrete Umsetzungsstrategien in der Praxis. |
| |
| Abbildung 1: Beispielhafter Risikoansatz für Safety und Security | → Für detaillierte Inhalte klicken Sie auf **„Mehr Informationen“**. |
| |
| Abbildung 1 zeigt beispielhaft einen möglichen Ansatz einer dreigliedrigen Definition des Risikobegriffs für Safety und Security. Im Anhang finden sich weitere wichtige risikobasierte Ansätze zur Sicherheitsbewertung. | ++++ Mehr informationen |==== 5.1.1 Motivation ==== |
| |
| ==== 6.2 Entwicklung Risikomodell ==== | 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. |
| |
| In einem zweiten Schritt sollte ein mathematisches Modell entwickelt werden, das die aus dem Risikobegriff resultierenden Parameter quantitativ definiert und verknüpft. Das so entstehende Modell sollte allgemein genug sein, um eine Risikoanalyse unterschiedlicher Betrachtungsobjekte, beispielsweise Infrastrukturen oder Produkte, zu erlauben. Hierbei kann das zu entwickelnde quantitative Modell, wie im Bereich Safety weit verbreitet, auf probabilistischen Annahmen basieren. Auch Risikomodelle der Security basieren zum Teil auf diesen Annahmen. Ausgehend hiervon würde eine Beschreibung der Modellparameter auf Basis probabilistischer Verteilungen angestrebt, was aber im Bereich der Security der weiteren Entwicklung vorhandener Modelle bedarf. | ==== 5.1.2 Einordnung von Safety und Security ==== |
| |
| Das entstehende probabilistische Modell wird die Risikoanteile von sowohl Safety als auch Security beinhalten und miteinander verknüpfen. Dies wird es ermöglichen, das resultierende Gesamtrisiko zu bewerten und ggf. sogar Maßnahmen im Sinne einer Zielkonfliktminimierung abwägen zu können. | === Technische Betriebssicherheit (Safety) === |
| |
| ==== 6.3 Betrachtung von Unsicherheiten ==== | 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 |
| |
| Eine Risikoanalyse auf Basis eines probabilistischen Modells erlaubt die Abbildung von Unsicherheiten in der Berechnung und Bewertung des Risikos, die sich in den Parametern der Verteilungen widerspiegeln. Diese Unsicherheiten ergeben sich beispielsweise aus unzureichender Evidenz für die Wirksamkeit von Maßnahmen, der unklaren Eintrittswahrscheinlichkeit von Bedrohungen oder nicht exakt definierbaren Auswirkungen oder Wechselwirkungen zwischen den einzelnen Domänen, sowie Unzulänglichkeiten des Modells. In einem dritten Schritt soll deshalb untersucht werden, wie diese Unsicherheiten analysiert und beschrieben werden können, so dass sie methodisch zur Unterstützung der Entscheidungsfindung bezüglich bestimmter untersuchter Konfigurationen dienen können. Hierbei soll insbesondere geprüft werden, wie die Sinnhaftigkeit einer ausgewählten Konfiguration von Safety- und Security-Maßnahmen unter Berücksichtigung vorhandener wechselseitiger Beeinflussungen und Unsicherheiten analysiert werden kann. Eine der möglichen Methoden, die zum Einsatz kommen könnte, wäre die (varianzbasierte) Sensitivitätsanalyse. Weitere Methoden zur Analyse von Unsicherheiten können hilfreich sein. | === IT-Security === |
| |
| ===== 7 Ethische und rechtliche Aspekte ===== | Im Gegensatz zu Safety konzentriert sich Security auf die Abwehr von beabsichtigten, bösartigen Bedrohungen gegen die Vertraulichkeit, Integrität und Verfügbarkeit von Systemen und Daten. Security umfasst die Gesamtheit der Maßnahmen zum Schutz vor Angriffen, Diebstahl, Sabotage oder unberechtigtem Zugriff. |
| „Sicherheit“ (als „Oberbegriff“ zu Safety und Security) wird ubiquitär verwendet, hat verschiedene Bedeutungen und ist – abhängig vom Bezug – vielfältig konnotiert; sie ist jedoch trotz allem zu einem zentralen Bezugspunkt menschlichen Denkens, Handelns und Strebens geworden. Die Herstellung bzw. Gewährleistung von (Technik-)Sicherheit in unterschiedlichen gesellschaftlichen Bereichen ist auch mit ethischen Implikationen verbunden. | |
| | |
| Ethik als Reflexionswissenschaft unterstützt die Suche nach Überschaubarkeit und Orientierung in einer (scheinbar?) immer unübersichtlicheren, komplexeren Welt. Ethische Analysen und Reflexionen sind kein (abstraktes) Moralisieren, sondern eine Form der „Beratung“ – insbesondere hinsichtlich Geboten oder Verboten bzw. Empfehlungen für Entscheidungen. Hinsichtlich Safety/Security bezieht sich das einerseits auf die Klärung grundlegender Begrifflichkeiten, Argumentationen und Begründungsverfahren sowie das Herausarbeiten impliziter Bedeutungsgehalte und Prämissen. Andererseits formuliert Ethik spezifische Standards und identifiziert mögliche Kriterien, die bei der Beurteilung von Sicherheit bzw. im praktischen Umgang mit ihr zu Grunde zu legen sind bzw. zu Grunde gelegt werden sollten. Dadurch, dass sich das auf mehrere (technische) Domänen bezieht, ergeben sich unterschiedliche Perspektiven und unterschiedliche Metriken, mit denen Sicherheit bemessen wird. | |
| | |
| Dabei ist von einer Einheit von kognitiven, normativen, prozeduralen und kommunikativen Komponenten auszugehen. | |
| | |
| Die kognitive Komponente besteht darin, anhand wissenschaftlicher Erkenntnisse, praktischer Erfahrungen und theoretischer – auch hypothetischer – Überlegungen mögliche sicherheitsrelevante Ursachen, Zusammenhänge und Szenarien zu erfassen. Auf diese Weise erhält man instrumentelles, vor allem wissenschaftlich-technologisches, politisches und organisatorisches Wissen über Kausalabläufe oder signifikante Korrelationen. Im Vordergrund steht Beschreibungs- und Gestaltungswissen für Produkte, Technologien und Anlagen sowie ihre Einbindung in Mensch-Technik-Interaktionen. Allerdings sind unterschiedliche Arten von Unsicherheiten zu berücksichtigen, insbesondere epistemische und aleatorische (von Zufällen abhängige). Während man erstere (er)kennen kann (jedoch mit mehr oder weniger großen „Lücken“, je nachdem, wie umfangreich die Evidenz und wie gut die Datenlage ist), entziehen sich letztere weitgehend der Erkenntnis, da sie auf Zufällen und menschlichem Handeln basieren. (Man denke in diesem Zusammenhang nur an die „List der Vernunft“!) | |
| | |
| Die normative Komponente hängt damit zusammen, dass das, was als „(un-)sicher“ betrachtet sowie welcher Bereich möglicher Gefährdungen wahrgenommen bzw. welcher ausgeblendet wird („Wie sicher ist sicher genug?“), von Wollens- und Sollens-Vorstellungen und damit von Normen und Wertungen abhängig ist – die immer auch kulturell geprägt sind. Auch deshalb besteht infolge möglicher differierender Interessen und Wertvorstellungen etwa zwischen „Beteiligten“ und „Betroffenen“ sicherheitsrelevanter technischer Lösungen selten Einigkeit: Mit der Entscheidung über Handlungsstrategien bzw. Handlungen werden positive und negative Folgen verteilt, und zwar zumeist ungleich hinsichtlich verschiedener Bevölkerungsgruppen sowie zwischen Gegenwart und Zukunft. Das bedeutet, dass es auch um Leitbilder und Prioritäten, Maßstäbe und Indikatoren für sicherheitsverbesserndes Handeln bzw. entsprechende Verfahren geht. Das schließt (methodische) Reflexionen über den Prozess der (Güter-)Abwägung im Falle von Ziel- und Güter- bzw. Normkonflikten ein. Relevant sind dabei folgende Fragen: Wo muss der Mensch abwägen? Wo kann dies der Maschine beziehungsweise dem Algorithmus überlassen werden? Welche Risikoanteile darf man (keinesfalls) ausblenden? | |
| | |
| Die prozedurale Komponente betrifft die über- bzw. transindividuelle Festlegung von Präferenzfolgen und Beurteilungsmaßstäben für Entscheidungen (etwa: „Wie sicher ist fair genug?“). Sollen das nicht top down-Entscheidungen der Politik (oder einen beliebigen anderen Institution) sein, muss diese Festlegung als Such- und Entscheidungsprozess organisiert werden, bei denen die relevanten Akteure die zu verfolgenden Ziele und die darauf aufbauenden bzw. davon ausgehenden Konzepte bei Berücksichtigung realer Macht- und Interessenkonstellationen aushandeln müssen (z.B. im Rahmen partizipativer Verfahren). Hier geht es auch um Fragen der Ressourcenverteilung, also der Verteilung von Ressourcen auf einzelne Sicherungsmaßnahmen, sowie um die Fragen, inwiefern man eine Abwägung, gegebenenfalls auch widersprüchliche Anforderungen aus unterschiedlichen Domänen, einem Algorithmus überlassen kann oder in welchen Bereichen eine menschliche Abwägung unbedingt erforderlich ist (etwa, weil Schaden an Leib und Leben von Menschen gegen Schaden an Sachen abgewogen werden muss). Im Ergebnis wird sich bei der Entscheidungsfindung dann eine Mischung aus menschlicher und Algorithmus-Entscheidung einstellen. Letzteres ist allein deshalb schon erforderlich, weil die Komplexität und die Anzahl der zu entscheidenden Freiheitsgrade zumeist sehr groß sind. Ziel sind letztendlich konsensfähige und bindende Resultate durch vielfältige kommunikative Prozesse. | |
| | |
| Diese bilden die kommunikative Komponente, vor allem als Aufklärungs- und Vorsorgekommunikation, als Legimitationskommunikation und als Störfall- und Krisenkommunikation. Diese folgt einerseits aber keinem einfachen Sender-Empfänger-Modell, sondern ist mit „Kodierungen“ und „Dekodierungen“ unterschiedlichster Art bei den Beteiligten verbunden, andererseits können dabei auch (kommunikative) Konflikte über Annahmen und Definitionen sowie Daten und Statistiken, Schätzwerte und Wahrscheinlichkeiten, Kosten-Nutzen-Vergleiche sowie gesellschaftliche Werte auftreten. | |
| |
| Die vier Komponenten in ihrer Einheit sind die Grundlage für stets notwendige (individuelle, kollektive oder gesellschaftliche) Abwägungen zwischen unterschiedlichen sicherheitsrelevanten „Schutzgütern“ bei der Suche nach dem „Ob?“ bzw. dem „Wie?“ konkreter sicherheitsrelevanter Lösungen (z.B. zwischen Sachwerten und Leben, zwischen informationeller Selbstbestimmung und der staatlichen Pflicht zur Kriminalitätsvorbeugung und –bekämpfung oder zwischen ökologischen und ökonomischen Interessen). Abwägungen sind eine Methode der möglichen Konfliktlösung auch im Bereich Sicherheit. Sie erfolgen hier in einem „Quadrupel“ unterschiedlicher Anforderungsbereiche: (1) (domänenspezifische) technische Voraussetzungen und Möglichkeiten, (2) gesellschaftliche Bedingungen und Anforderungen (insbesondere Schutzziele und –güter), (3) wirtschaftliche Erwartungen und Verfahrenswege (z.B. Aufwand-Nutzen-Überlegungen) sowie (4) rechtliche und Schadensregulierungen (z.B. Haftungs- und Gewährleistungsprobleme). Diese sind jeweils „angemessen“ zu berücksichtigen und „in Einklang“ zu bringen. Ergebnis ist eine Wichtung der jeweiligen Vor- wie Nachteile der zur Auswahl stehenden (auch alternativer) Lösungen, die zu einer Entscheidung hinsichtlich Nutzung bzw. Nicht-Nutzung dieser Lösungen führen (soll). Dieser Abwägungsprozess wird – was nicht vergessen werden darf – zusätzlich von individuellen Erwartungen und gemachten Erfahrungen beeinflusst, ist somit häufig nicht transindividuell oder intersubjektiv. | === Zuverlässigkeit durch Safety und Security === |
| |
| Deshalb ist (mindestens) zweierlei zu kommunizieren: Erstens der zugrunde gelegte Beschreibungs- und Erklärungsrahmen („relative Apriori“, theoretische Prämissen, Grundannahmen) und zweitens die angewendeten Kriterien, Präferenzfolgen und Maßstäbe bei Auswahl- und Bewertungsprozessen. | Die Zuverlässigkeit technischer Systeme hängt maßgeblich von den Aspekten Safety und Security ab. Die Herausforderung liegt in der integrierten Berücksichtigung beider Aspekte, um Systemausfälle zu verhindern und die Zuverlässigkeit zu erhöhen. Eine effektive Umsetzung von Safety- und Security-Maßnahmen steigert somit die Gesamtzuverlässigkeit eines Systems. Die Abhängigkeiten zwischen physischen und informationstechnischen Systemen erfordern eine gemeinsame Betrachtung, um Schwachstellen effektiv zu adressieren und zu beheben. Beispielsweise kann eine Sicherheitslücke in der IT-Infrastruktur nicht nur Datenrisiken, sondern auch physische Sicherheitsrisiken nach sich ziehen. |
| |
| Damit gilt als zusammenfassende ethische Quintessenz: Jegliche sicherheitsrelevante Entscheidung muss letztlich sowohl nachvollzieh- und hinterfrag- als auch (auf der Grundlage „guter Gründe“) rechtfertigbar sein. | === Konflikte zwischen Safety und Security === |
| |
| | **Ressourcenallokation**: Die Ressourcen (Zeit, Geld, Personal) können begrenzt sein, und die Priorisierung der einen kann zu Lasten der anderen gehen. Zum Beispiel könnte ein übermäßiger Fokus auf Security-Maßnahmen Ressourcen von wichtigen Safety-Maßnahmen abziehen und umgekehrt. |
| |
| ===== 8 Leitfragen-Erläuterungen ===== | **Design- und Implementierungskonflikte**: Einige Sicherheitsmaßnahmen könnten im Widerspruch zu Sicherheitsanforderungen stehen. Ein Beispiel hierfür ist die Zutrittskontrolle: Während aus Sicherheitsgründen ein restriktiver Zutritt wünschenswert ist, könnte dies im Notfall die Rettungsdienste behindern und somit die Sicherheit gefährden. |
| |
| **Rohversion aus KI ** | **Datenzugriff und Privatsphäre**: Security-Maßnahmen, die eine Überwachung und das Sammeln von Daten erfordern, können in Konflikt mit dem Datenschutz und der Privatsphäre der Nutzer stehen, was wiederum safety-relevante Aspekte beeinflussen kann, insbesondere in Bereichen, die eine anonyme Datenerhebung erfordern. |
| |
| ==== 8.1 Risiko: Definition und Herausforderungen ==== | **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. |
| |
| **Wie wird das Risiko, werden Safety und Security in der Disziplin beschrieben: Begriffe, Modelle und Verfahren? ** | ==== 5.1.3 Grundlagen der IT-Security ==== |
| |
| Diese Frage zielt auf die verwendeten Definitionen und theoretischen Konzepte ab: Wie wird Risiko modelliert (z. B. als Produkt aus Eintrittswahrscheinlichkeit und Schadensausmaß)? Welche Modelle sind etabliert (z. B. Bow-Tie, Fault Tree, Angriffsszenarien)? Wie unterscheiden sich Safety- und Security-Verständnisse? | === Schutzziele === |
| |
| **Welche Probleme und Dilemmata sind in Ihrer Disziplin charakteristisch? ** | 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. |
| |
| Hier geht es um typische Zielkonflikte, Unsicherheiten oder widersprüchliche Anforderungen, die in der Praxis auftreten – z. B. zwischen offener Bedienbarkeit (Safety) und Zugangsbeschränkung (Security). Wie werden unscharfe oder unsichere Risikobeiträge behandelt? Gefragt wird nach dem Umgang mit epistemischer Unsicherheit, fehlender Evidenz oder nur schwer quantifizierbaren Risiken – etwa durch Expertenabschätzungen, konservative Annahmen oder Sensitivitätsanalysen. | === Technische Maßnahmen === |
| |
| ==== 8.2 Durchführung von Risikoanalysen ==== | * **Kryptografie:** Kryptografie bezeichnet die Lehre von der Verschlüsselung von Informationen. Ziel ist es, Daten so zu transformieren, dass sie nur von autorisierten Parteien entschlüsselt und gelesen werden können. Moderne Kryptografie nutzt mathematische Algorithmen für die Verschlüsselung und Sicherstellung der Integrität von Daten, um Vertraulichkeit, Authentizität und Nichtabstreitbarkeit in digitalen Kommunikationen zu gewährleisten. |
| | * **Key Management:** Key Management umfasst die Verfahren und Technologien zum Erzeugen, Verteilen, Verwalten, Speichern, und zum finalen Löschen von Kryptografieschlüsseln. Ziel ist es, die Sicherheit der Schlüssel über ihren gesamten Lebenszyklus hinweg zu gewährleisten, da die Sicherheit der verschlüsselten Informationen direkt von der Sicherheit der Schlüssel abhängt. |
| | * **Systemsicherheit:** Systemsicherheit betrachtet übergeordnet den Schutz von Computersystemen und deren Ressourcen vor Missbrauch, Ausfällen, oder unbefugtem Zugriff. Dies schließt physische Sicherheitsmaßnahmen, Betriebssystemsicherheit, Anwendungssoftware-Sicherheit und unterschiedliche Kontrollmechanismen zur Überwachung und Reaktion auf Sicherheitsvorfälle ein. |
| | * **Softwaresicherheit:** Softwaresicherheit konzentriert sich auf die Entwicklung und Implementierung von Software, die frei von Schwachstellen ist und resistent gegenüber Cyberangriffen bleibt. Dies beinhaltet die Anwendung von Sicherheitspraktiken während des gesamten Softwareentwicklungslebenszyklus, um die Einführung und Ausnutzung von Schwachstellen zu verhindern. |
| | * **Cloud-Sicherheit:** Spezifische Praktiken und Technologien zum Schutz von Daten, Anwendungen und Infrastrukturen, die in der Cloud gehostet werden. Dies beinhaltet Verschlüsselung, Zugriffskontrollen, Sicherheitsüberwachung und Compliance-Management. |
| | * **Hardwaresicherheit:** Hardwaresicherheit beschäftigt sich mit dem Schutz von physischen Geräten vor Manipulationen, Diebstahl oder Beschädigung. Dazu gehören Maßnahmen wie physische Absicherung, anti-tampering Technologien und die Integration von Sicherheitsfeatures direkt auf der Hardware-Ebene, z.B. durch Secure-Boot-Mechanismen oder hardwarebasierte Verschlüsselungsunterstützung. |
| | * **Netzwerksicherheit:** Netzwerksicherheit umfasst Maßnahmen und Technologien zum Schutz von Daten während deren Übertragung über Netzwerke. Ziele sind die Gewährleistung der Vertraulichkeit, Integrität und Verfügbarkeit von Daten. Maßnahmen beinhalten Firewalls, Intrusion Detection und Prevention Systeme, Verschlüsselung, sowie Zugriffskontrollen. |
| | * **Security-by-Design:** Security-by-Design ist ein Ansatz in der Entwicklung von IT-Systemen, bei dem Sicherheitsüberlegungen von Anfang an ein integraler Bestandteil des Design- und Entwicklungsprozesses sind, im Gegensatz dazu, Sicherheitsfeatures nachträglich in ein bereits fertiges Produkt einzubauen. Dieser Ansatz strebt an, Sicherheitsrisiken proaktiv zu minimieren. |
| | * **Secure Coding:** Secure Coding bedeutet, Sicherheitsprinzipien bei der Softwareentwicklung konsequent anzuwenden, um Schwachstellen zu vermeiden, die während der Implementierungsphase entstehen können. Es schließt die Anwendung von Best Practices, Richtlinien und Standards ein, die darauf abzielen, sichere Codepraktiken zu fördern und somit die Anfälligkeit für Angriffe zu reduzieren. |
| | === Organisatorische Maßnahmen === |
| |
| **Wie werden Risikoanalysen in Ihrer Disziplin durchgeführt (qualitativ, quantitativ, semi-quantitativ, nach Norm oder Richtlinie)? ** | * **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. |
| * Diese Frage betrifft die Methodik der Risikoanalyse – ob sie auf Zahlen basiert (quantitativ), auf Bewertungsskalen (semi-quantitativ) oder auf Expertenurteilen und Kategorien (qualitativ), sowie ob normative Vorgaben (z. B. ISO, IEC) genutzt werden. | * **Incident Management:** Incident Management bezieht sich auf den Prozess und die organisatorischen Strukturen, die für das Management der Antwort auf IT-Sicherheitsvorfälle erforderlich sind. Ziel ist es, die Auswirkungen von Sicherheitsvorfällen zu minimieren, die normalen Geschäftsoperationen schnellstmöglich wiederherzustellen und aus den Vorfällen zu lernen, um zukünftige Sicherheitsrisiken zu minimieren. |
| | * **Patch Management:** Patch Management ist der Prozess der Verwaltung von Updates für Software und Systeme, der insbesondere die Identifikation, das Testen und die Implementierung von Patches (Korrekturen oder Updates) umfasst. Ein effektives Patch-Management-Verfahren ist entscheidend, um bekannte Sicherheitslücken zu schließen und das Risiko von Sicherheitsverletzungen zu reduzieren. Es erfordert eine Balance zwischen der schnellen Anwendung kritischer Patches, um Sicherheitsrisiken zu minimieren, und der Notwendigkeit, die Stabilität und Kompatibilität innerhalb der IT-Landschaft zu gewährleisten. |
| | * **Drittanbieter- und Lieferantenrisikomanagement:** Bewertung und Kontrolle der Risiken, die von Dritten ausgehen, mit denen Daten geteilt oder die in kritische Geschäftsprozesse eingebunden sind. Dies kann die Überprüfung der Sicherheitspraktiken von Drittanbietern und die Einführung von Sicherheitsanforderungen in Vertragsvereinbarungen beinhalten. |
| | * **Informationsklassifizierung und -handling:** Entwicklung und Durchsetzung von Richtlinien zur Klassifizierung von Informationen nach ihrem Sicherheitsbedarf sowie entsprechenden Handhabungsprozeduren. Diese organisatorischen Maßnahmen sind entscheidend für die Schaffung eines ganzheitlichen und effektiven Sicherheitsprogramms, das sowohl technische als auch menschliche Faktoren berücksichtigt und sich kontinuierlich an sich ändernde Bedrohungen anpassen kann. |
| | * **Need-to-Know-Prinzip:** Das Need-to-Know-Prinzip besagt, dass Personen nur Zugang zu den Informationen erhalten sollen, die unbedingt notwendig für die Ausübung ihrer Aufgaben sind. Ziel ist es, das Risiko unbeabsichtigter oder beabsichtigter Informationslecks zu minimieren und die Datensicherheit zu erhöhen, indem der Zugriff auf sensible Informationen strikt kontrolliert wird. |
| | * **Least-Privilege Prinzip:** Das Least-Privilege Prinzip (Prinzip der minimalen Rechtevergabe) bedeutet, dass Nutzern und Systemen nur die minimal notwendigen Berechtigungen für die Erfüllung ihrer spezifischen Aufgaben gewährt werden. Dies reduziert das Risiko, dass weitreichende Rechte missbraucht werden oder dass ein Angreifer, der ein Konto kompromittiert, weitreichenden Zugriff innerhalb des Systems erlangen kann. |
| | * **Separation of Duties (Trennung von Verantwortlichkeiten):** Die Trennung von Verantwortlichkeiten ist ein Sicherheitsprinzip, das fordert, kritische Aufgaben so aufzuteilen, dass für deren erfolgreiche Ausführung die Zusammenarbeit mehrerer Personen erforderlich ist. Dies soll Interessenkonflikte vermeiden, Betrug erschweren und die Wahrscheinlichkeit von Fehlern oder unbefugten Handlungen reduzieren. |
| | * **Job Rotation:** Job Rotation bezeichnet den regelmäßigen Wechsel von Mitarbeitern durch verschiedene Positionen oder Aufgabenbereiche. In der IT-Security wird dieses Prinzip eingesetzt, um das Risiko von Insider-Bedrohungen zu minimieren, da kontinuierliche Veränderungen die Möglichkeiten für längere unbefugte Aktivitäten einschränken. Es fördert zudem die Redundanz von Fachwissen und erhöht die Widerstandsfähigkeit gegenüber Personalausfällen. |
| | === Security in der Praxis === |
| |
| **Welche Metriken kommen hierbei zum Einsatz? ** | Die Messung von IT-Security ist nicht trivial, da der Grad der Sicherheit von Produkten und Systemen nicht direkt messbar ist wie physikalische Größen. Stattdessen müssen indirekte Indikatoren, Metriken und Modelle herangezogen werden, um die Sicherheitseffektivität zu bewerten. Im Folgenden wird ein Überblick über die Vorgehensmodelle und gängiger Methoden zur Messung der IT-Security gegeben und anschließend auf die rechtlichen Rahmenbedingungen sowie relevante Standards eingegangen. |
| * Hier geht es um die verwendeten Maßzahlen zur Risikobewertung, wie SIL (Safety Integrity Level), PL (Performance Level), CVSS (Common Vulnerability Scoring System) oder eigene branchenspezifische Kennzahlen. | |
| |
| **Wie treten Wechselwirkungen der Domänen Safety und Security in der Risikoanalyse in Ihrer Disziplin in Erscheinung und wie werden diese behandelt? ** | === Entwicklung sicherer Produkte === |
| * Gefragt wird, ob und wie Abhängigkeiten oder Zielkonflikte zwischen Safety- und Security-Anforderungen explizit betrachtet und methodisch integriert werden – etwa durch kombinierte Modelle, Szenarien oder Priorisierungen. | |
| |
| ==== 8.3 Domänenübergreifende Zusammenführung ==== | Der Entwurf, der Betrieb und die Wartung von sicheren Systemen, Prozessen und Produkten wir über das das Security Engineering, einem Teilbereich des Systems Engineering, gewährleistet. Beim Security Engineering geht es darum, angemessenen Schutz vor den Risiken, Bedrohungen und Schwachstellen zu bieten. Der Security Engineering Prozess ist ein systematischer und strukturierter Ansatz, um sicherzustellen, dass Sicherheitsanforderungen während der gesamten Lebensdauer eines Systems oder Produktes berücksichtigt und implementiert werden. Dies schließt die Konzeption, Entwicklung, Implementierung, Wartung und Außerbetriebnahme ein. Im Folgenden wird der Security Engineering Prozess in seinen grundsätzlichen Schritten erläutert: |
| |
| **Werden in den angrenzenden Disziplinen ähnliche oder andere Probleme bearbeitet? ** | - **Identifikation und Bewertung der Assets** Der erste Schritt besteht darin, die schützenswerten Assets zu identifizieren und zu bewerten. Die Bewertung schließt eine Bestimmung der Wichtigkeit jedes Assets und des potentiellen Schadens bei Verlust, Beschädigung oder Missbrauch ein. |
| * Diese Frage dient dem Vergleich mit benachbarten Disziplinen: Gibt es gemeinsame Herausforderungen (z. B. Unsicherheiten, Zielkonflikte)? Wo unterscheiden sich Herangehensweisen oder Prioritäten? | - **Risikoanalyse** Nach der Identifikation und Bewertung der Assets folgt die Risikoanalyse. Dabei werden potenzielle Bedrohungen und Schwachstellen, die die Sicherheit der Assets beeinträchtigen könnten, identifiziert. Die Risikoanalyse bewertet auch, wie wahrscheinlich es ist, dass ein bestimmtes Risiko eintritt, und welchen potenziellen Schaden es verursachen könnte. |
| | - **Festlegung von Sicherheitszielen und -anforderungen** Basierend auf der Risikoanalyse werden Sicherheitsziele und -anforderungen definiert, die die Richtung für die Gestaltung und Entwicklung von sicherheitskritischen Systemen und Produkten vorgeben. Diese Anforderungen beziehen sich in der Regel auf die Integrität, Verfügbarkeit, Vertraulichkeit und Authentizität der Assets. |
| | - **Entwurf und Entwicklung** In dieser Phase werden Sicherheitskonzepte und -maßnahmen entwickelt und in das Produkt oder System integriert. Dies kann die Auswahl sicherer Hardware- und Softwarekomponenten, die Entwicklung sicherer Protokolle und die Implementierung von Kryptografie beinhalten. |
| | - **Implementierung und Verifikation** Nach der Gestaltung und Entwicklung erfolgt die Implementierung der Sicherheitsmaßnahmen. Anschließend wird eine Verifikation durchgeführt, um sicherzustellen, dass die Sicherheitsanforderungen erfüllt sind. Dies kann durch Tests, Code-Reviews und Sicherheitsaudits geschehen. |
| | - **Betrieb und Wartung** Sicherheit ist ein fortlaufender Prozess. Daher umfasst der Security Engineering Prozess auch den Betrieb und die Wartung von Systemen und Produkten, um zu gewährleisten, dass sie sicher bleiben. Dies schließt regelmäßige Updates, Patch-Management und das Monitoring von Sicherheitsvorfällen ein. |
| | - **Reaktion auf Sicherheitsvorfälle und Wiederherstellung** Der letzte Schritt beinhaltet die Entwicklung und Implementierung von Plänen zur Reaktion auf Sicherheitsvorfälle und zur Wiederherstellung nach einem Vorfall. Dies soll sicherstellen, dass ein System oder Produkt nach einem Sicherheitsvorfall schnell wieder in einen sicheren Zustand zurückgeführt werden kann. Der Security Engineering Prozess ist ein zyklischer und iterativer Prozess, der eine kontinuierliche Bewertung und Anpassung der Sicherheitsmaßnahmen erfordert, um mit den sich ständig weiterentwickelnden Bedrohungen Schritt zu halten. |
| | ==== 5.1.4 Vorgehensmodelle & Metriken ==== |
| |
| **Was sind methodische Unterschiede und Gemeinsamkeiten in verschiedenen Domänen? ** | Die Messung von IT-Security beginnt mit der Definition von Zielen und Kriterien, die die Sicherheitsanforderungen des Systems widerspiegeln. Diese Anforderungen basieren häufig auf den drei Grundpfeilern der IT-Sicherheit: Vertraulichkeit, Integrität und Verfügbarkeit (CIA-Prinzip). Zusätzlich können je nach Kontext weitere Aspekte wie Authentizität, Zurechenbarkeit und Nicht-Zurückweisbarkeit relevant sein. Deren Erfüllungsgrad lässt sich dann anhand von detaillierten Analysen des Systems bestimmen. Die meisten Ansätze verfahren dabei Risikobasiert, d.h. es wird zunächst eine Risikoanalyse zur Bestimmung der wesentlichen Schwachstellen und deren Schadenspotential durchgeführt. Die Risikoanalyse in der IT-Security zielt darauf ab, potenzielle Bedrohungen für Informationssysteme zu erkennen und die dadurch verursachten potenziellen Schäden sowie die Wahrscheinlichkeit ihres Auftretens zu bewerten. Sie beinhaltet die systematische Betrachtung von Schwachstellen, Bedrohungsvektoren und potenziellen Auswirkungen eines Sicherheitsvorfalls. Die Risikoanalyse bildet die Basis für das Risikomanagement und die Entwicklung effektiver Sicherheitsstrategien. Modelle wie STRIDE, DREAD, TARA und CVSS helfen dabei, Sicherheitsbedrohungen zu klassifizeren. Jedes dieser Modelle und Frameworks bietet spezifische Perspektiven und Werkzeuge zur Bewertung und Handhabung von Sicherheitsrisiken. Die Auswahl und Kombination der geeigneten Methoden hängt von der spezifischen Ausgestaltung des Systems ab. Häufig wird z.B. das Common Vulnerability Scoring System (CVSS) verwendet, welches ein offener Standard zur Bewertung der Schwere von Sicherheitslücken ist. CVSS bietet eine standardisierte Methode, um die Auswirkungen von Schwachstellen zu quantifizieren und zu vergleichen, indem es ihnen eine Nummer (Score) von 0 bis 10 zuweist, wobei höhere Werte auf eine größere Schwere hindeuten. CVSS Scores helfen bei der Priorisierung von Patch- und Mitigationsmaßnahmen basierend auf der potenziellen Auswirkung einer Schwachstelle. Die Bewertung von Schwachstellen kann über Blackbox-/ Whitebox-Analysen und Penetrationstest erfolgen. Diese ermöglichen unterschiedliche Perspektiven und Herangehensweisen zur Bewertung der IT-Sicherheit. |
| * Diese Frage zielt darauf ab, innerhalb der jeweiligen Disziplin (z. B. Luftfahrt, Automotive, Energie, IT, physische Sicherheit) die Unterschiede und Gemeinsamkeiten der Methoden zur Risikoanalyse zwischen den Domänen Safety und Security herauszuarbeiten. Es soll untersucht werden, wie Risikoanalysen in beiden Bereichen jeweils durchgeführt werden – etwa hinsichtlich ihrer Modelle, Metriken, Normgrundlagen, Szenarioarten oder des Umgangs mit Unsicherheit – und ob sich daraus übertragbare Ansätze oder bestehende Zielkonflikte ableiten lassen. Ziel ist es, domänenübergreifende Schnittmengen zu identifizieren und Synergien oder Widersprüche systematisch zu dokumentieren. | |
| |
| **Wie könnte ein gemeinsamer Nenner für die Quantifizierung von Risiken in Safety- und Security Modellen aussehen? ** | * **Blackbox-Analyse:** Die Blackbox-Analyse ist ein Ansatz, bei dem der Tester keine Vorabinformationen über das innere Funktionieren des Systems hat. Tester interagieren mit der externen Schnittstelle des Systems (wie einer Webapplikation oder einem Netzwerkdienst), um potenzielle Schwachstellen und Sicherheitslücken rein aus der Perspektive eines externen Angreifers zu identifizieren. Diese Methode ahmt das Vorgehen eines echten Angreifers nach, der typischerweise keinen Zugang zu internen Details des Systems besitzt. Die Blackbox-Analyse kann zeitaufwändig sein, da sie eine umfangreiche Erkundung erfordert, und ist besonders effektiv bei der Identifizierung von Schwachstellen in der Zugriffskontrolle und bei öffentlich zugänglichen Diensten. |
| * Ziel dieser Frage ist es, Kriterien, Maße oder Modelle zu benennen, die domänenübergreifend genutzt werden können – etwa harmonisierte Risikokategorien, kompatible Skalen oder gemeinsame Indikatoren. | * **Whitebox-Analyse:** Im Gegensatz zur Blackbox-Analyse hat der Tester bei der Whitebox-Analyse umfassenden Zugang zu allen internen Ressourcen des Systems, einschließlich Quellcode, Architekturdokumentation und Konfigurationsdetails. Diese Methode ermöglicht eine gründlichere Überprüfung, da sie das Verständnis der internen Logik und Struktur des Systems nutzt, um Sicherheitslücken zu identifizieren. Die Whitebox-Analyse ermöglicht es Testern, gezielt nach Schwachstellen in der Implementierung und Logik zu suchen, was zu einer effizienteren Identifizierung von Problemen wie Code-Injektion, unzureichender Datenvalidierung und anderen sicherheitskritischen Fehlern führt. |
| | * **Penetrationstesting:** (auch bekannt als Pen-Testing oder ethisches Hacking) ist eine praxisorientierte Methode, bei der Sicherheitsexperten versuchen, in ein IT-System einzudringen, um Schwachstellen und Sicherheitsrisiken zu identifizieren. Im Gegensatz zu den eher theoretischen oder statischen Ansätzen der Blackbox- und Whitebox-Analyse ist das Penetrationstesting dynamisch und zielt darauf ab, die realen Auswirkungen eines Angriffs auf die Sicherheit des Systems zu simulieren. Es kann sowohl Blackbox- als auch Whitebox-Methoden umfassen, abhängig davon, wie viel Vorwissen über das System zur Verfügung steht. Penetrationstests bewerten nicht nur die Existenz von Sicherheitslücken, sondern auch die Fähigkeit des Systems, Angriffsversuche zu erkennen und darauf zu reagieren, und bieten so wertvolle Einblicke in die operative Sicherheit eines Systems. |
| | ==== 5.1.5 Normen & rechtlicher Rahmen ==== |
| |
| **Welches neue Wissen ist erforderlich für eine Synthese der Domänen? ** | === Rechtliche Rahmenbedingungen === |
| * 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. | |
| |
| ===== 9 Anhang: Beispiele für risikobasierte Modelle (zu ergänzen) ===== | 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. |
| |
| ==== 9.1 Safety ==== | Einige der wichtigsten rechtlichen Rahmenbedingungen sind: |
| |
| DIN EN ISO 13849: Sicherheit von Maschinen - Sicherheitsbezogene Teile von Steuerungen, 2017. | * **NIS2-Richtlinie (EU):** Die Richtlinie über Sicherheit von Netz- und Informationssystemen (NIS2) ist eine überarbeitete Version der ursprünglichen NIS-Richtlinie der Europäischen Union. Sie zielt darauf ab, ein hohes gemeinsames Sicherheitsniveau für Netz- und Informationssysteme in der EU zu gewährleisten. NIS2 erweitert den Anwendungsbereich auf weitere kritische Sektoren und verstärkt die Sicherheits- und Melderequirements für Unternehmen wesentlich. |
| | * **Cyber Resilience Act (CRA, geplant):** Die Europäische Kommission hat einen Vorschlag für einen „Cyber Resilience Act“ vorgelegt, der darauf abzielt, die Sicherheit von digitalen Produkten und zugehörigen Dienstleistungen innerhalb der EU zu stärken. Der CRA soll Mindestanforderungen an die IT-Security für Produkte mit digitalen Elementen einführen und einen einheitlicheren Rechtsrahmen schaffen. |
| | * **Datenschutz-Grundverordnung (DSGVO):** Die DSGVO ist eine Verordnung der Europäischen Union, die den Schutz personenbezogener Daten und die Freizügigkeit dieser Daten regelt. Sie stellt strenge Anforderungen an die Verarbeitung personenbezogener Daten durch Unternehmen und Organisationen und gibt den Betroffenen weitreichende Rechte. Verstöße gegen die DSGVO können zu hohen Geldstrafen führen. |
| | * **IT-Sicherheitsgesetz (IT-SiG, Deutschland):** Das deutsche IT-Sicherheitsgesetz bildet die nationale Umsetzung der EU-NIS-Richtlinie und adressiert Betreiber kritischer Infrastrukturen. Es verpflichtet diese, bestimmte Mindeststandards an IT-Security einzuhalten und erhebliche Sicherheitsvorfälle zu melden. Mit dem IT-Sicherheitsgesetz 2.0 wurde der Anwendungsbereich erweitert und die Anforderungen verschärft. |
| | * **Exportkontrolle:** Sowohl auf nationaler Ebene als auch international sind Regelungen zur Exportkontrolle von IT-Sicherheitstechnologien von Bedeutung. Diese Regelungen sollen verhindern, dass sicherheitskritische Technologien, einschließlich Verschlüsselungssoftware und Dual-Use-Güter, in falsche Hände geraten. Länder wie die USA und die Mitgliedstaaten der Europäischen Union haben umfangreiche Bestimmungen erlassen, die den Export bestimmter Technologien beschränken. |
| | === Relevante Standards === |
| |
| DIN EN 61882 VDE 0050-8: HAZOP-Verfahren (HAZOP-Studien), 2017 | Zertifizierungen spielen eine zentrale Rolle im Bereich der IT-Sicherheit, indem sie Standards für Wissen, Fähigkeiten, Praktiken und Prozesse setzen. |
| |
| IAEA Safety Reports Series No. 25: Review of Probabilistic Safety Assessments by Regulatory Bodies, 2002. | * **ISO 27001/x (ISMS):** Der internationale Standard ISO/IEC 27001 definiert die Anforderungen für ein Informationssicherheits-Managementsystem (ISMS). Er unterstützt Organisationen dabei, ihre Informationen durch systematische Risikomanagementprozesse sicher zu schützen, wobei die Flexibilität der Implementierung nach den spezifischen Sicherheitsanforderungen der Organisation erlaubt ist. |
| | * **BSI IT-Grundschutz:** Entwickelt vom Bundesamt für Sicherheit in der Informationstechnik (BSI) in Deutschland, bietet der IT-Grundschutz einen umfassenden Ansatz zur Implementierung von Sicherheitsmaßnahmen. Es handelt sich um eine Sammlung von Empfehlungen und Best Practices, die auf der Identifizierung von typischen Gefährdungen und Standard-Sicherheitsmaßnahmen basieren, um ein angemessenes Sicherheitsniveau zu gewährleisten. |
| | * **ISO/IEC 15408 (Common Criteria - CC):** Diese internationale Norm bietet einen Rahmen für die Bewertung der Sicherheit und Vertrauenswürdigkeit von Informations- und Kommunikationstechnikprodukten und -systemen. Sie ermöglicht es Herstellern, ihre Produkte unabhängig prüfen und zertifizieren zu lassen, um so deren Sicherheitseigenschaften transparent zu machen. |
| | * **ISO 62443:** Dieser Standard konzentriert sich auf die industrielle Kommunikationstechnik und spezifiziert Sicherheitsmaßnahmen zum Schutz industrieller Automatisierungssysteme. Es bietet ein Framework zur Absicherung industrieller Automatisierungs- und Kontrollsysteme (IACS) und adressiert Aspekte wie Systemintegrität, Vertraulichkeit und Verfügbarkeit. |
| | * **ISO/SAE 21434:** Ein Standard für die IT-Security in der Automobilindustrie, der sich auf den Engineering-Lebenszyklus von Fahrzeugen konzentriert. Er bietet Richtlinien zur Risikobewertung, zum Design, zur Entwicklung, zur Produktion, zum Betrieb und zur Wartung von Sicherheitssystemen in Fahrzeugen, um deren Cyberresilienz zu stärken. |
| | * **FIPS 140:** Das Federal Information Processing Standard (FIPS) Publication 140 ist ein US-amerikanischer Standard, der die Anforderungen an kryptografische Module festlegt, einschließlich deren Entwurf und Implementierung. Der Standard wird hauptsächlich von Regierungsbehörden und anderen Organisationen verwendet, die sensible, aber umklassifizierte Informationen schützen müssen. |
| | * **NIST Cybersecurity Framework (CSF):** Entwickelt vom National Institute of Standards and Technology (NIST) in den USA, dient dieses Rahmenwerk dazu, Organisationen bei der Verwaltung und Minderung von IT-Securityrisiken zu unterstützen. Es bietet eine einheitliche Sprache und Methodik für die Einführung einer effektiven IT-Security-Praxis und fokussiert auf die Aspekte Identifizieren, Schützen, Erkennen, Reagieren und Wiederherstellen. |
| | ==== 5.1.6 Domänenspezifische Herausforderungen ==== |
| |
| IAEA Safety Reports Series No. 52: Best Estimate Safety Analysis for Nuclear Power Plants: Uncertainty Evaluation, 2008. | Die Domänen Embedded Systems, Industrial Control Systems (ICS), Kritische Infrastrukturen (KRITIS), Automotive und Medizintechnik stehen jeweils vor spezifischen Herausforderungen in Bezug auf die IT-Security. Diese Herausforderungen ergeben sich aus den besonderen Anforderungen, Einsatzumgebungen und Risiken, die mit jeder Domäne verbunden sind. Im Folgenden wird ein wissenschaftlicher Überblick über diese domänenspezifischen Herausforderungen gegeben: |
| |
| IAEA Safety Standards Series No. GSR Part 4 (Rev. 1): Safety Assessment for Facilities and Activities, 2016. | * **Embedded Systems:** Embedded Systems sind in vielen Bereichen des täglichen Lebens und der Industrie eingebettet, von einfachen Haushaltsgeräten bis hin zu komplexen Steuerungssystemen. |
| | * **Ressourcenbeschränkungen:** Viele Embedded Devices verfügen über beschränkte Rechenleistung, Speicherplatz und Energiekapazität, was die Implementierung umfassender Sicherheitsmechanismen erschwert. |
| | * **Lange Lebenszyklen:** Einige Embedded Devices, wie in der Luft- und Raumfahrt, sind für lange Betriebsdauern ausgelegt, wobei Aktualisierungen oder Patches schwierig umzusetzen sein können. |
| | * **Heterogenität und Kompatibilität:** Die Vielfalt der Hardware und Software in Embedded Systems erschwert die Standardisierung von Sicherheitslösungen. |
| | * **Industrie und Produktionsanlage / Industrial Control Systems (ICS):** ICS sind kritische Komponenten in der Fertigungs- und Versorgungsindustrie, deren Kompromittierung weitreichende physische Schäden verursachen kann. |
| | * **Verfügbarkeit vs. Vertraulichkeit:** Im Gegensatz zu herkömmlichen IT-Systemen liegt der Fokus bei ICS auf der Verfügbarkeit und Integrität der Systeme. Die Sicherstellung der Vertraulichkeit ist oft von sekundärer Bedeutung. |
| | * **Alte und proprietäre Systeme:** Viele ICS laufen auf veralteten oder proprietären Systemen, für die es schwierig ist, Sicherheitspatches zu erhalten oder zu implementieren. |
| | * **Netzwerkisolierung:** Obwohl die Isolierung von Steuerungsnetzwerken von der übrigen IT-Infrastruktur als Schutzmaßnahme gilt, wird sie zunehmend schwieriger, da ICS immer öfter remote überwacht und gesteuert werden. |
| | * **Kritische Infrastrukturen (KRITIS):** KRITIS umfassen Einrichtungen und Dienste, die für das Funktionieren der Gesellschaft wesentlich sind, wie Energieversorgung, Wasserwirtschaft und Gesundheitsdienste. |
| | * **Hohe Anforderungen an die Ausfallsicherheit:** Ausfälle oder Beeinträchtigungen können gravierende Auswirkungen auf die öffentliche Sicherheit haben. |
| | * **Zielscheibe für staatlich unterstützte Angreifer:** Aufgrund ihrer Bedeutung sind KRITIS oft Ziele für Cyberangriffe mit staatlicher Unterstützung oder mit der Absicht, der Gesellschaft Schaden zuzufügen. |
| | * **Komplexität und Verwundbarkeit:** Die Vernetzung und Abhängigkeit zwischen verschiedenen KRITIS erhöht die Angriffsfläche und potenzielle Auswirkungen von Cyberangriffen. |
| | * **Automotive:** Die zunehmende Vernetzung und Automatisierung in Fahrzeugen führt zu neuen Sicherheitsrisiken. |
| | * **Komplexe Lieferkette:** Die Automotive-Industrie kennzeichnet eine komplexe Lieferkette, die die Konsistenz und Zuverlässigkeit von Sicherheitsmaßnahmen erschwert. |
| | * **Sicherheit des Fahrzeuglebenszyklus:** Die langfristige Sicherung von Fahrzeugen vom Entwurf bis zur Verschrottung ist eine Herausforderung, insbesondere in Bezug auf Softwareupdates und Patches. |
| | * **Datenschutz:** Die Sammlung und Übertragung persönlicher Daten durch vernetzte Fahrzeuge stellen Herausforderungen für den Datenschutz dar. |
| | * **Medizintechnik:** Geräte im Gesundheitswesen sind besonders sensibel, da sie unmittelbar Patientendaten verarbeiten und lebenserhaltende Funktionen ausführen. |
| | * **Lebensrettende Geräte:** Die Sicherheit von Medizingeräten ist kritisch, da Fehlfunktionen direkt das Leben von Patienten gefährden können. |
| | * **Datenschutz und Compliance:** Medizingeräte verarbeiten hochsensible Patientendaten und müssen strenge Datenschutzbestimmungen wie die europäische Datenschutz-Grundverordnung (DSGVO) einhalten. |
| | * **Geräteaktualisierungen:** Viele Medizingeräte sind schwer zugänglich und können nur mit erheblichem Aufwand aktualisiert werden, was die Behebung von Sicherheitslücken erschwert. |
| | ++++ |
| |
| IAEA Safety Standards Specific Safety Guide No. SSG-3: Development and Application of Level 1 Probabilistic Safety Assessment for Nuclear Power Plants, 2010. | ===== 5.2 Resilienz ===== |
| |
| IAEA Safety Standards Specific Safety Guide No. SSG-4: Development and Application of Level 2 Probabilistic Safety Assessment for Nuclear Power Plants, 2010. | Die Betrachtung der Resilienz ist motiviert durch die Annahme, dass nicht alle zukünftigen Gefährdungssituationen vorhersehbar sind, sondern dass im Gegenteil gerade besonders drastische Störereignisse plötzlich und unerwartet auftreten können. Die Auswirkungen solcher Ereignisse können nicht vollends abgefangen oder verhindert werden. Das Ziel von Resilienz-bildenden oder -stärkenden Maßnahmen ist es stattdessen ein System zu befähigen mit den Auswirkungen von Störungen jedweder Art und Ausprägung umzugehen – auch solcher, die bis zu ihrem Auftreten unbekannt waren. |
| |
| IEC 61508: Funktionale Sicherheit sicherheitsbezogener elektrischer/elektronischer/programmierbarer elektronischer Systeme, 2011. | → Für detaillierte Inhalte klicken Sie auf **„Mehr Informationen“**. |
| |
| IEC 61511: Functional safety - Safety instrumented systems for the process industry sector, 2016. | ++++ Mehr informationen|==== 5.2.1 Definition Resilienz ==== |
| |
| ISO 26262: Road vehicles – Functional safety, 2018. | Der Begriff Resilienz beschreibt die Fähigkeit eines Systems (unmittelbar sowie langfristig) mit den Auswirkungen unspezifischer und möglicherweise unvorhergesehener Störereignisse umzugehen. Entsprechend der Vielfalt an Mechanismen, die zu einem positiven Umgang mit einem Störereignis beitragen können, ergibt sich die Resilienz eines Systems aus einer Kombination unterschiedlicher Kompetenzen und Strategien. Genau genommen beschreibt der Begriff Resilienz also nicht eine einzelne, sondern eine Gruppe von Fähigkeiten. Diese Gruppe lässt sich anhand dreier übergeordneter Grundfähigkeiten zusammenfassen, die die Zielsetzung resilienten Verhaltens erfassen: Ein resilientes System ist in der Lage die Auswirkungen einer Störung gering zu halten (Absorptionsfähigkeit) und sich von diesen schnell und vollständig zu erholen (Restorationsfähigkeit). Darüber hinaus besitzt ein resilientes System eine gewisse Lernfähigkeit, die es dem System ermöglicht die zum Umgang mit Störungen notwendigen Fähigkeiten zu steigern oder diese in einer sich verändernden Gefährdungslage langfristig zu erhalten (Adaptionsfähigkeit). Jede dieser drei übergeordneten Grundfähigkeiten (Absorptions-, Restorations- und Adaptionsfähigkeit) ergibt sich wiederum aus verschiedenen Resilienz-bildenden Eigenschaften und Fertigkeiten. Beispielsweise kann die Absorptionsfähigkeit eines Systems durch bestimmte Strukturmerkmale (wie ein modulares Design oder das Vorhandensein redundanter Elemente) sowie durch organisatorische Fertigkeiten der handelnden Akteure (z.B. Entscheidungs- und Kommunikationsfähigkeit in Krisensituationen) positiv beeinflusst werden. |
| |
| NE 144: Risikobasierte Instandhaltung von Brandmeldeanlagen, 2012. | ==== 5.2.2 Abgrenzung zum Risikobegriff ==== |
| |
| ==== 9.2 Security ==== | Ein entscheidendes Kriterium zur Unterscheidung von Risiko- und Resilienz-basierten Ansätzen zur Steigerung der Sicherheit oder Zuverlässigkeit eines Systems ist die Unsicherheit oder Kenntnis über die Ereignisse oder Szenarien, die die beiden Ansätze adressieren. Während Risiko-basierte Ansätze darauf abzielen ein System auf Gefährdungssituationen vorzubereiten, deren Charakteristika zu einem gewissen Grad bekannt oder zumindest absehbar sind, zielen Resilienz-basierte Ansätze darauf ab ein System auf den Umgang mit beliebigen Gefährdungssituationen vorzubereiten – hierzu zählen insbesondere auch unerwartete und singuläre Störereignisse. Charakteristisch für Resilienz-basierte Betrachtungen ist der starke Fokus auf das System selbst bzw. auf die Ausprägung der resilienten Fähigkeiten dieses Systems. Entsprechende Betrachtungen beinhalten dabei speziell auch die Fähigkeiten, die nach der Ausbildung negativer Folgen zum Tragen kommen (d.h. die Restorations- und Adaptionsfähigkeit des Systems). |
| |
| Alberts, Christopher, Audrey Dorofee, James Stevens, and Carol Woody. “Introduction to the OCTAVE Approach.” Networked Systems Survivability Program. Pittsburgh, PA, USA: Carnegie Mellon University, 2003. Beyerer, Jürgen, and Jürgen Geisler. “A Framework for a Uniform Quantitative Description of Risk with Respect to Safety and Security.” CKGE_TMP_i European Journal of Security Research CKGE_TMP_i 1 (2016): 135–150. BSI - Bundesamt für Sicherheit in der Informationstechnik. “Guidelines for Developer Documentation according to Common Criteria Version 3.1,” 2007. Campbell, Philip L., and Jason E. Stamp. “A Classification Scheme for Risk Assessment Methods.” SANDIA REPORT. Albuquerque, NM, USA: Sandia National Laboratories, 2004. Harnser Group, ed. “A Reference Security Management Plan for Energy Infrastructure.” European Commission, 2010. Landoll, Douglas J. CKGE_TMP_i The Security Risk Assessment Handbook: AComplete Guide for Performing Security Risk Assessments CKGE_TMP_i . 2nd ed. Boca Raton, FL, USA: CRC Press, 2011.NE 153: Automation Security 2020 - Design, Implementierung und Betrieb industrieller Automatisierungssysteme, 2015 | ==== 5.2.3 Resilienz bewerten und quantifzieren ==== |
| |
| ===== 10 Resilienz ===== | Die Bewertung des Resilienz-Status eines Systems – d.h. die Ermittlung des Grades der Fähigkeit eines Systems mit jedweder Störung umgehen zu können – ist mit einigen Schwierigkeiten verbunden. Dies hängt damit zusammen, dass sich die Ausprägung einer Fähigkeit nur in dem Moment manifestiert, in dem diese Fähigkeit gebraucht wird – d.h. im Falle der Resilienz, während eines Störereignisses. Für die Bewertung oder Quantifizierung der Resilienz bedeutet dies im Umkehrschluss, dass um die tatsächliche Resilienz eines Systems fehlerlos zu ermitteln, jede erdenkliche Störung berücksichtigt werden müsste. Folglich kann jede Resilienz-Bewertung nur eine Näherung an die tatsächliche Resilienz eines Systems liefern. Bei entsprechenden Näherungen kann grundsätzlich zwischen zwei Herangehensweisen unterschieden werden – Outcome-basierten (ergebnisorientiert) und Property-basierten (eigenschaftsbasiert). |
| |
| Die Betrachtung der Resilienz ist motiviert durch die Annahme, dass nicht alle zukünftigen Gefährdungssituationen vorhersehbar sind, sondern dass im Gegenteil gerade besonders drastische Störereignisse plötzlich und unerwartet auftreten können. Die Auswirkungen solcher Ereignisse können nicht vollends abgefangen oder verhindert werden. Das Ziel von Resilienz-bildenden oder -stärkenden Maßnahmen ist es stattdessen ein System zu befähigen mit den Auswirkungen von Störungen jedweder Art und Ausprägung umzugehen – auch solcher, die bis zu ihrem Auftreten unbekannt waren. | Outcome-basierte Ansätze stützen sich auf den Ausgang von exemplarischen Störszenarien um die Resilienz eines Systems zu bewerten. Hierfür muss zum einen eine Auswahl an exemplarischen Störereignissen oder Störfällen getroffen werden und zum anderen ein Maß für die Quantifizierung des Ausgangs einer Störung festgelegt werden. Beide Aspekte beeinflussen das Ergebnis der Resilienz-Bewertung erheblich, weswegen darauf geachtet werden sollte, dass die ausgewählten Szenarien das Spektrum aller möglichen relevanten Störfälle adäquat abdecken und die gewählte Quantifizierung die wesentlichen Systemfunktionen erfasst. Ein besonders verbreiteter Ansatz ist hierbei die Nutzung von Performance-Kurven, die die Funktionsfähigkeit (Performance) eines Systems über den Verlauf einer Störung anhand eines oder mehrerer charakteristischer Performance-Indikatoren darstellen. Mit Hilfe bestimmter Metriken, wie der Fläche unter der Performance-Kurve oder der Steigung der Performance-Restoration, können aus diesen Kurven Kennzahlen abgeleitet werden, die die Güte der Systemantwort auf die entsprechende Störung charakterisieren. Die Zusammenschau einer gewissen Menge von Performance-Kurven ermöglicht es dann Rückschlüsse auf die Resilienz zu ziehen, die den beobachtenden Systemantworten zugrunde liegt. |
| |
| ==== 10.1 Definition Resilienz ==== | Eine Alternative zu Outcome-basierten Bewertungen der Resilienz stellt die Property-basierte Betrachtung dar. Bei dieser Herangehensweise wird die Resilienz eines Systems anhand von Systemeigenschaften bewertet, von denen angenommen wird, dass sie die Grundlage der resilienten Fähigkeiten bzw. die Grundlage resilienten Verhaltens bilden. Entsprechende Ansätze beruhen also nicht auf der Betrachtung realer oder simulierter Störfälle, sondern betrachten das System im ungestörten Zustand um dessen Potential mit möglichen Störungen umzugehen abzuschätzen. Eine weitverbreitete Methodik stellen in diesem Kontext sogenannte Resilienz-Kompositions-Indikatoren dar, die Informationen aus unterschiedlichen Quellen (z.B. Umfrageergebnisse, demographische Daten, Expert*innen-Befragungen), einer konzeptionellen Hierarchie folgend, zusammenführen um die Resilienz eines Systems anhand einer Reihe von Kennzahlen darzustellen. Je nach Kompositions-Indikator können sich die verschiedenen Kennzahlen dabei auf unterschiedliche Aspekte der Resilienz beziehen, beispielsweise auf die verschiedenen Resilienz-Fähigkeiten oder die unterschiedlichen Wirkungsdimensionen der Resilienz (technisch, organisatorisch, sozial, ökonomisch). |
| |
| Der Begriff Resilienz beschreibt die Fähigkeit eines Systems (unmittelbar sowie langfristig) mit den Auswirkungen unspezifischer und möglicherweise unvorhergesehener Störereignisse umzugehen. Entsprechend der Vielfalt an Mechanismen, die zu einem positiven Umgang mit einem Störereignis beitragen können, ergibt sich die Resilienz eines Systems aus einer Kombination unterschiedlicher Kompetenzen und Strategien. Genau genommen beschreibt der Begriff Resilienz also nicht eine einzelne, sondern eine Gruppe von Fähigkeiten. Diese Gruppe lässt sich anhand dreier übergeordneter Grundfähigkeiten zusammenfassen, die die Zielsetzung resilienten Verhaltens erfassen: Ein resilientes System ist in der Lage die Auswirkungen einer Störung gering zu halten (Absorptionsfähigkeit) und sich von diesen schnell und vollständig zu erholen (Restorationsfähigkeit). Darüber hinaus besitzt ein resilientes System eine gewisse Lernfähigkeit, die es dem System ermöglicht die zum Umgang mit Störungen notwendigen Fähigkeiten zu steigern oder diese in einer sich verändernden Gefährdungslage langfristig zu erhalten (Adaptionsfähigkeit). Jede dieser drei übergeordneten Grundfähigkeiten (Absorptions-, Restorations- und Adaptionsfähigkeit) ergibt sich wiederum aus verschiedenen Resilienz-bildenden Eigenschaften und Fertigkeiten. Beispielsweise kann die Absorptionsfähigkeit eines Systems durch bestimmte Strukturmerkmale (wie ein modulares Design oder das Vorhandensein redundanter Elemente) sowie durch organisatorische Fertigkeiten der handelnden Akteure (z.B. Entscheidungs- und Kommunikationsfähigkeit in Krisensituationen) positiv beeinflusst werden. | ++++ |
| |
| ==== 10.2 Abgrenzung zum Risikobegriff ==== | ===== 5.3 Ethische Aspekte ===== |
| |
| Ein entscheidendes Kriterium zur Unterscheidung von Risiko- und Resilienz-basierten Ansätzen zur Steigerung der Sicherheit oder Zuverlässigkeit eines Systems ist die Unsicherheit oder Kenntnis über die Ereignisse oder Szenarien, die die beiden Ansätze adressieren. Während Risiko-basierte Ansätze darauf abzielen ein System auf Gefährdungssituationen vorzubereiten, deren Charakteristika zu einem gewissen Grad bekannt oder zumindest absehbar sind, zielen Resilienz-basierte Ansätze darauf ab ein System auf den Umgang mit beliebigen Gefährdungssituationen vorzubereiten – hierzu zählen insbesondere auch unerwartete und singuläre Störereignisse. Charakteristisch für Resilienz-basierte Betrachtungen ist der starke Fokus auf das System selbst bzw. auf die Ausprägung der resilienten Fähigkeiten dieses Systems. Entsprechende Betrachtungen beinhalten dabei speziell auch die Fähigkeiten, die nach der Ausbildung negativer Folgen zum Tragen kommen (d.h. die Restorations- und Adaptionsfähigkeit des Systems). | Ethische Reflexionen spielen eine zentrale Rolle, wenn es um Fragen der Sicherheit geht – verstanden als Oberbegriff von Safety und Security. Denn Sicherheit betrifft nicht nur technische Machbarkeit, sondern auch Wertentscheidungen, Verantwortlichkeiten und gesellschaftliche Aushandlungsprozesse. Ethik hilft dabei, Orientierungen in komplexen Entscheidungssituationen zu entwickeln und Maßstäbe für verantwortungsvolles Handeln zu formulieren. Der folgende Text beleuchtet, wie sich sicherheitsrelevante Entscheidungen ethisch analysieren und begründen lassen. Im Mittelpunkt stehen vier wesentliche Dimensionen: kognitiv, normativ, prozedural und kommunikativ. |
| |
| ==== 10.3 Resilienz bewerten und quantifzieren ==== | → Für detaillierte Inhalte klicken Sie auf **„Mehr Informationen“**. |
| |
| Die Bewertung des Resilienz-Status eines Systems – d.h. die Ermittlung des Grades der Fähigkeit eines Systems mit jedweder Störung umgehen zu können – ist mit einigen Schwierigkeiten verbunden. Dies hängt damit zusammen, dass sich die Ausprägung einer Fähigkeit nur in dem Moment manifestiert, in dem diese Fähigkeit gebraucht wird – d.h. im Falle der Resilienz, während eines Störereignisses. Für die Bewertung oder Quantifizierung der Resilienz bedeutet dies im Umkehrschluss, dass um die tatsächliche Resilienz eines Systems fehlerlos zu ermitteln, jede erdenkliche Störung berücksichtigt werden müsste. Folglich kann jede Resilienz-Bewertung nur eine Näherung an die tatsächliche Resilienz eines Systems liefern. Bei entsprechenden Näherungen kann grundsätzlich zwischen zwei Herangehensweisen unterschieden werden – Outcome-basierten (ergebnisorientiert) und Property-basierten (eigenschaftsbasiert). | ++++ Mehr informationen|==== 5.3.1 Ethische Überlegungen & Abwägung ==== |
| |
| Outcome-basierte Ansätze stützen sich auf den Ausgang von exemplarischen Störszenarien um die Resilienz eines Systems zu bewerten. Hierfür muss zum einen eine Auswahl an exemplarischen Störereignissen oder Störfällen getroffen werden und zum anderen ein Maß für die Quantifizierung des Ausgangs einer Störung festgelegt werden. Beide Aspekte beeinflussen das Ergebnis der Resilienz-Bewertung erheblich, weswegen darauf geachtet werden sollte, dass die ausgewählten Szenarien das Spektrum aller möglichen relevanten Störfälle adäquat abdecken und die gewählte Quantifizierung die wesentlichen Systemfunktionen erfasst. Ein besonders verbreiteter Ansatz ist hierbei die Nutzung von Performance-Kurven, die die Funktionsfähigkeit (Performance) eines Systems über den Verlauf einer Störung anhand eines oder mehrerer charakteristischer Performance-Indikatoren darstellen. Mit Hilfe bestimmter Metriken, wie der Fläche unter der Performance-Kurve oder der Steigung der Performance-Restoration, können aus diesen Kurven Kennzahlen abgeleitet werden, die die Güte der Systemantwort auf die entsprechende Störung charakterisieren. Die Zusammenschau einer gewissen Menge von Performance-Kurven ermöglicht es dann Rückschlüsse auf die Resilienz zu ziehen, die den beobachtenden Systemantworten zugrunde liegt. | „Sicherheit“ (als „Oberbegriff“ zu Safety und Security) wird ubiquitär verwendet, hat verschiedene Bedeutungen und ist – abhängig vom Bezug – vielfältig konnotiert; sie ist jedoch trotz allem zu einem zentralen Bezugspunkt menschlichen Denkens, Handelns und Strebens geworden. Die Herstellung bzw. Gewährleistung von (Technik-)Sicherheit in unterschiedlichen gesellschaftlichen Bereichen ist auch mit ethischen Implikationen verbunden. |
| |
| Eine Alternative zu Outcome-basierten Bewertungen der Resilienz stellt die Property-basierte Betrachtung dar. Bei dieser Herangehensweise wird die Resilienz eines Systems anhand von Systemeigenschaften bewertet, von denen angenommen wird, dass sie die Grundlage der resilienten Fähigkeiten bzw. die Grundlage resilienten Verhaltens bilden. Entsprechende Ansätze beruhen also nicht auf der Betrachtung realer oder simulierter Störfälle, sondern betrachten das System im ungestörten Zustand um dessen Potential mit möglichen Störungen umzugehen abzuschätzen. Eine weitverbreitete Methodik stellen in diesem Kontext sogenannte Resilienz-Kompositions-Indikatoren dar, die Informationen aus unterschiedlichen Quellen (z.B. Umfrageergebnisse, demographische Daten, Expert*innen-Befragungen), einer konzeptionellen Hierarchie folgend, zusammenführen um die Resilienz eines Systems anhand einer Reihe von Kennzahlen darzustellen. Je nach Kompositions-Indikator können sich die verschiedenen Kennzahlen dabei auf unterschiedliche Aspekte der Resilienz beziehen, beispielsweise auf die verschiedenen Resilienz-Fähigkeiten oder die unterschiedlichen Wirkungsdimensionen der Resilienz (technisch, organisatorisch, sozial, ökonomisch). | Ethik als Reflexionswissenschaft unterstützt die Suche nach Überschaubarkeit und Orientierung in einer (scheinbar?) immer unübersichtlicheren, komplexeren Welt. Ethische Analysen und Reflexionen sind kein (abstraktes) Moralisieren, sondern eine Form der „Beratung“ – insbesondere hinsichtlich Geboten oder Verboten bzw. Empfehlungen für Entscheidungen. Hinsichtlich Safety/Security bezieht sich das einerseits auf die Klärung grundlegender Begrifflichkeiten, Argumentationen und Begründungsverfahren sowie das Herausarbeiten impliziter Bedeutungsgehalte und Prämissen. Andererseits formuliert Ethik spezifische Standards und identifiziert mögliche Kriterien, die bei der Beurteilung von Sicherheit bzw. im praktischen Umgang mit ihr zu Grunde zu legen sind bzw. zu Grunde gelegt werden sollten. Dadurch, dass sich das auf mehrere (technische) Domänen bezieht, ergeben sich unterschiedliche Perspektiven und unterschiedliche Metriken, mit denen Sicherheit bemessen wird. |
| | |
| | Dabei ist von einer Einheit von kognitiven, normativen, prozeduralen und kommunikativen Komponenten auszugehen. |
| | |
| | Die kognitive Komponente besteht darin, anhand wissenschaftlicher Erkenntnisse, praktischer Erfahrungen und theoretischer – auch hypothetischer – Überlegungen mögliche sicherheitsrelevante Ursachen, Zusammenhänge und Szenarien zu erfassen. Auf diese Weise erhält man instrumentelles, vor allem wissenschaftlich-technologisches, politisches und organisatorisches Wissen über Kausalabläufe oder signifikante Korrelationen. Im Vordergrund steht Beschreibungs- und Gestaltungswissen für Produkte, Technologien und Anlagen sowie ihre Einbindung in Mensch-Technik-Interaktionen. Allerdings sind unterschiedliche Arten von Unsicherheiten zu berücksichtigen, insbesondere epistemische und aleatorische (von Zufällen abhängige). Während man erstere (er)kennen kann (jedoch mit mehr oder weniger großen „Lücken“, je nachdem, wie umfangreich die Evidenz und wie gut die Datenlage ist), entziehen sich letztere weitgehend der Erkenntnis, da sie auf Zufällen und menschlichem Handeln basieren. (Man denke in diesem Zusammenhang nur an die „List der Vernunft“!) |
| | |
| | Die normative Komponente hängt damit zusammen, dass das, was als „(un-)sicher“ betrachtet sowie welcher Bereich möglicher Gefährdungen wahrgenommen bzw. welcher ausgeblendet wird („Wie sicher ist sicher genug?“), von Wollens- und Sollens-Vorstellungen und damit von Normen und Wertungen abhängig ist – die immer auch kulturell geprägt sind. Auch deshalb besteht infolge möglicher differierender Interessen und Wertvorstellungen etwa zwischen „Beteiligten“ und „Betroffenen“ sicherheitsrelevanter technischer Lösungen selten Einigkeit: Mit der Entscheidung über Handlungsstrategien bzw. Handlungen werden positive und negative Folgen verteilt, und zwar zumeist ungleich hinsichtlich verschiedener Bevölkerungsgruppen sowie zwischen Gegenwart und Zukunft. Das bedeutet, dass es auch um Leitbilder und Prioritäten, Maßstäbe und Indikatoren für sicherheitsverbesserndes Handeln bzw. entsprechende Verfahren geht. Das schließt (methodische) Reflexionen über den Prozess der (Güter-)Abwägung im Falle von Ziel- und Güter- bzw. Normkonflikten ein. Relevant sind dabei folgende Fragen: Wo muss der Mensch abwägen? Wo kann dies der Maschine beziehungsweise dem Algorithmus überlassen werden? Welche Risikoanteile darf man (keinesfalls) ausblenden? |
| | |
| | Die prozedurale Komponente betrifft die über- bzw. transindividuelle Festlegung von Präferenzfolgen und Beurteilungsmaßstäben für Entscheidungen (etwa: „Wie sicher ist fair genug?“). Sollen das nicht top down-Entscheidungen der Politik (oder einen beliebigen anderen Institution) sein, muss diese Festlegung als Such- und Entscheidungsprozess organisiert werden, bei denen die relevanten Akteure die zu verfolgenden Ziele und die darauf aufbauenden bzw. davon ausgehenden Konzepte bei Berücksichtigung realer Macht- und Interessenkonstellationen aushandeln müssen (z.B. im Rahmen partizipativer Verfahren). Hier geht es auch um Fragen der Ressourcenverteilung, also der Verteilung von Ressourcen auf einzelne Sicherungsmaßnahmen, sowie um die Fragen, inwiefern man eine Abwägung, gegebenenfalls auch widersprüchliche Anforderungen aus unterschiedlichen Domänen, einem Algorithmus überlassen kann oder in welchen Bereichen eine menschliche Abwägung unbedingt erforderlich ist (etwa, weil Schaden an Leib und Leben von Menschen gegen Schaden an Sachen abgewogen werden muss). Im Ergebnis wird sich bei der Entscheidungsfindung dann eine Mischung aus menschlicher und Algorithmus-Entscheidung einstellen. Letzteres ist allein deshalb schon erforderlich, weil die Komplexität und die Anzahl der zu entscheidenden Freiheitsgrade zumeist sehr groß sind. Ziel sind letztendlich konsensfähige und bindende Resultate durch vielfältige kommunikative Prozesse. |
| | |
| | Diese bilden die kommunikative Komponente, vor allem als Aufklärungs- und Vorsorgekommunikation, als Legimitationskommunikation und als Störfall- und Krisenkommunikation. Diese folgt einerseits aber keinem einfachen Sender-Empfänger-Modell, sondern ist mit „Kodierungen“ und „Dekodierungen“ unterschiedlichster Art bei den Beteiligten verbunden, andererseits können dabei auch (kommunikative) Konflikte über Annahmen und Definitionen sowie Daten und Statistiken, Schätzwerte und Wahrscheinlichkeiten, Kosten-Nutzen-Vergleiche sowie gesellschaftliche Werte auftreten. |
| | |
| | Die vier Komponenten in ihrer Einheit sind die Grundlage für stets notwendige (individuelle, kollektive oder gesellschaftliche) Abwägungen zwischen unterschiedlichen sicherheitsrelevanten „Schutzgütern“ bei der Suche nach dem „Ob?“ bzw. dem „Wie?“ konkreter sicherheitsrelevanter Lösungen (z.B. zwischen Sachwerten und Leben, zwischen informationeller Selbstbestimmung und der staatlichen Pflicht zur Kriminalitätsvorbeugung und –bekämpfung oder zwischen ökologischen und ökonomischen Interessen). Abwägungen sind eine Methode der möglichen Konfliktlösung auch im Bereich Sicherheit. Sie erfolgen hier in einem „Quadrupel“ unterschiedlicher Anforderungsbereiche: (1) (domänenspezifische) technische Voraussetzungen und Möglichkeiten, (2) gesellschaftliche Bedingungen und Anforderungen (insbesondere Schutzziele und –güter), (3) wirtschaftliche Erwartungen und Verfahrenswege (z.B. Aufwand-Nutzen-Überlegungen) sowie (4) rechtliche und Schadensregulierungen (z.B. Haftungs- und Gewährleistungsprobleme). Diese sind jeweils „angemessen“ zu berücksichtigen und „in Einklang“ zu bringen. Ergebnis ist eine Wichtung der jeweiligen Vor- wie Nachteile der zur Auswahl stehenden (auch alternativer) Lösungen, die zu einer Entscheidung hinsichtlich Nutzung bzw. Nicht-Nutzung dieser Lösungen führen (soll). Dieser Abwägungsprozess wird – was nicht vergessen werden darf – zusätzlich von individuellen Erwartungen und gemachten Erfahrungen beeinflusst, ist somit häufig nicht transindividuell oder intersubjektiv. |
| | |
| | Deshalb ist (mindestens) zweierlei zu kommunizieren: Erstens der zugrunde gelegte Beschreibungs- und Erklärungsrahmen („relative Apriori“, theoretische Prämissen, Grundannahmen) und zweitens die angewendeten Kriterien, Präferenzfolgen und Maßstäbe bei Auswahl- und Bewertungsprozessen. |
| | |
| | Damit gilt als zusammenfassende ethische Quintessenz: Jegliche sicherheitsrelevante Entscheidung muss letztlich sowohl nachvollzieh- und hinterfrag- als auch (auf der Grundlage „guter Gründe“) rechtfertigbar sein. |
| | |
| | ++++ |
| | |
| | ====== 6. Leitfragen-Erläuterungen ====== |
| | |
| | Die folgenden zehn Leitfragen dienen dazu, die Beschreibung der einzelnen Disziplinen in eine einheitliche Struktur zu bringen. Alle Expertinnen und Experten wurden gebeten, ihre Disziplin entlang dieser Fragen zu beschreiben. Auf diese Weise lassen sich die Sichtweisen auf Risiko, Methoden, Dilemmata sowie mögliche Ansätze zur Auflösung von Zielkonflikten systematisch erfassen und vergleichen. **Auch für neu aufzunehmende Disziplinen ist vorgesehen, dass sie anhand dieser Leitfragen dargestellt werden, um eine konsistente Erweiterung des Wikis zu ermöglichen.** |
| | |
| | ==== Risiko: Definition und Herausforderungen ==== |
| | **Frage: Wie wird das Risiko, werden Safety und Security in der Disziplin beschrieben: Begriffe, Modelle und Verfahren?** |
| | |
| | Diese Frage zielt auf die verwendeten Definitionen und theoretischen Konzepte ab: Wie wird Risiko modelliert (z. B. als Produkt aus Eintrittswahrscheinlichkeit und Schadensausmaß)? Welche Modelle und Verfahren sind etabliert (z. B. Bow-Tie, Fault Tree, Angriffsszenarien)? Wie unterscheiden sich Safety- und Security-Verständnisse? |
| | |
| | **Frage: Welche Probleme und Dilemmata sind in Ihrer Disziplin charakteristisch?** |
| | |
| | Hier geht es um typische Zielkonflikte, Unsicherheiten oder widersprüchliche Anforderungen, die in der Praxis auftreten – z. B. zwischen offener Bedienbarkeit (Safety) und Zugangsbeschränkung (Security). |
| | |
| | **Frage: Wie werden unscharfe oder unsichere Risikobeiträge behandelt?** |
| | |
| | Gefragt wird nach dem Umgang mit epistemischer Unsicherheit, fehlender Evidenz oder nur schwer quantifizierbaren Risiken – etwa durch Expertenabschätzungen, konservative Annahmen oder Sensitivitätsanalysen. |
| | |
| | ==== Durchführung von Risikoanalysen ==== |
| | |
| | **Frage: Wie werden Risikoanalysen in Ihrer Disziplin durchgeführt (qualitativ, quantitativ, semi-quantitativ, nach Norm oder Richtlinie)?** |
| | |
| | Diese Frage betrifft die Methodik der Risikoanalyse – ob sie auf Zahlen basiert (quantitativ), auf Bewertungsskalen (semi-quantitativ) oder auf Expertenurteilen und Kategorien (qualitativ), sowie ob normative Vorgaben (z. B. ISO, IEC) genutzt werden. |
| | |
| | **Frage: Welche Metriken kommen hierbei zum Einsatz?** |
| | |
| | Hier geht es um die verwendeten Maßzahlen zur Risikobewertung, wie SIL (Safety Integrity Level), PL (Performance Level), CVSS (Common Vulnerability Scoring System) oder eigene branchenspezifische Kennzahlen. |
| | |
| | **Frage: Wie treten Wechselwirkungen der Domänen Safety und Security in der Risikoanalyse in Ihrer Disziplin in Erscheinung und wie werden diese behandelt?** |
| | |
| | Gefragt wird, ob und wie Abhängigkeiten oder Zielkonflikte zwischen Safety- und Security-Anforderungen explizit betrachtet und methodisch integriert werden – etwa durch kombinierte Modelle, Szenarien oder Priorisierungen. |
| | |
| | ==== Domänenübergreifende Zusammenführung ==== |
| | |
| | **Frage: Werden in den angrenzenden Disziplinen ähnliche oder andere Probleme bearbeitet?** |
| | |
| | Diese Frage dient dem Vergleich mit benachbarten Disziplinen: Gibt es gemeinsame Herausforderungen (z. B. Unsicherheiten, Zielkonflikte)? Wo unterscheiden sich Herangehensweisen oder Prioritäten? |
| | |
| | **Frage: Was sind methodische Unterschiede und Gemeinsamkeiten in verschiedenen Domänen?** |
| | |
| | Diese Frage zielt darauf ab, innerhalb der jeweiligen Disziplin (z. B. Luftfahrt, Automotive, Energie, IT, physische Sicherheit) die Unterschiede und Gemeinsamkeiten der Methoden zur Risikoanalyse zwischen den Domänen Safety und Security herauszuarbeiten. Es soll untersucht werden, wie Risikoanalysen in beiden Bereichen jeweils durchgeführt werden – etwa hinsichtlich ihrer Modelle, Metriken, Normgrundlagen, Szenarioarten oder des Umgangs mit Unsicherheit – und ob sich daraus übertragbare Ansätze oder bestehende Zielkonflikte ableiten lassen. Ziel ist es, domänenübergreifende Schnittmengen zu identifizieren und Synergien oder Widersprüche systematisch zu dokumentieren. |
| | |
| | **Frage: Wie könnte ein gemeinsamer Nenner für die Quantifizierung von Risiken in Safety- und Security-Modellen aussehen?** |
| | |
| | Ziel dieser Frage ist es, Kriterien, Maße oder Modelle zu benennen, die domänenübergreifend genutzt werden können – etwa harmonisierte Risikokategorien, kompatible Skalen oder gemeinsame Indikatoren. |
| | |
| | **Frage: Welches neue Wissen ist erforderlich für eine Synthese der Domänen?** |
| | |
| | Abschließend wird nach offenen Forschungsfragen, neuen Kompetenzen oder interdisziplinärem Wissen gefragt, das notwendig ist, um Safety und Security systematisch zu integrieren – etwa zu Unsicherheitsbewertung, ethischer Abwägung oder Entscheidungsmodellen. |
| | |
| | |
| | ====== 7. Fachausschuss Team ====== |
| | [[content:fachausschuss|Der Fachausschuss]] |
| |
| |