Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
| content:arbeitsschutz [2025/04/07 15:45] – [1.1 Funktionale Sicherheit] approve | content:arbeitsschutz [2025/07/16 07:35] (aktuell) – [2.2 Security] zeh | ||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| ====== Bedeutung von Safety und Security in Industrie- und Produktionsanlagen und im Arbeitsschutz ====== | ====== Bedeutung von Safety und Security in Industrie- und Produktionsanlagen und im Arbeitsschutz ====== | ||
| - | Die zunehmende Digitalisierung und Vernetzung in der Industrie bringen neben zahlreichen Chancen auch erhebliche Sicherheitsrisiken mit sich. Insbesondere kritische Infrastrukturen und industrielle Steuerungssysteme sind zunehmend Ziel von Cyberangriffen. | + | Die zunehmende Digitalisierung und Vernetzung in der Industrie bringen neben zahlreichen Chancen auch erhebliche Sicherheitsrisiken mit sich. Insbesondere kritische Infrastrukturen und industrielle Steuerungssysteme sind zunehmend Ziel von Cyberangriffen. |
| + | |||
| + | ===== Relevante Normen und Richtlinien (unvollständig) ===== | ||
| + | |||
| + | ==== 1. Safety Grundnormen ==== | ||
| + | |||
| + | ^Kennung^Jahr^Titel^Anmerkung| | ||
| + | |[[: | ||
| + | |[[https:// | ||
| + | |[[https:// | ||
| + | |[[https:// | ||
| + | |[[https:// | ||
| + | |[[https:// | ||
| + | |[[https:// | ||
| + | |[[https:// | ||
| + | |[[: | ||
| + | |[[: | ||
| + | |||
| + | |||
| + | ==== 2. Security ==== | ||
| + | |||
| + | === 2.1 Normenfamilien für gesamtheitliche Betrachtungen === | ||
| + | |||
| + | ^Kennung^Jahr^Titel^Anmerkung| | ||
| + | |[[https:// | ||
| + | |[[https:// | ||
| + | |[[: | ||
| + | |[[https:// | ||
| + | |||
| + | === 2.2 Normen für Informationssicherheits-Managementsysteme (ISMS) === | ||
| + | |||
| + | ALLE NORMEN ZURÜCKGEZOGEN | ||
| + | |||
| + | ^Kennung^Jahr^Titel^Anmerkung| | ||
| + | |[[: | ||
| + | |[[: | ||
| + | |[[: | ||
| + | |[[: | ||
| + | |||
| + | === 2.3 Normen für die Evaluierung von IT-Sicherheit === | ||
| + | |||
| + | ALLE NORMEN ZURÜCKGEZOGEN | ||
| + | |||
| + | ^Kennung^Jahr^Titel^Anmerkung| | ||
| + | |[[: | ||
| + | |[[: | ||
| + | |[[: | ||
| + | |[[https:// | ||
| + | |||
| + | === 2.4 Normen für spezielle (IT)-Sicherheitsverfahren === | ||
| + | |||
| + | ALLE NORMEN RICHTLINIEN REIHEN KEINE LINKS | ||
| + | |||
| + | ^Kennung^Jahr^Titel^Anmerkung| | ||
| + | |[[: | ||
| + | |[[: | ||
| + | |[[: | ||
| + | |[[: | ||
| + | |[[: | ||
| + | |||
| + | === 2.5 Normen für physikalische Sicherheit im Kontext der IT-Sicherheit === | ||
| + | |||
| + | ^Kennung^Jahr^Titel^Anmerkung| | ||
| + | |[[: | ||
| + | |[[https:// | ||
| + | |[[https:// | ||
| + | |||
| + | === 2.6 Normen für spezielle Sicherheitsmaßnahmen === | ||
| + | |||
| + | ^Kennung^Jahr^Titel^Anmerkung| | ||
| + | |[[: | ||
| + | |[[https:// | ||
| + | |||
| + | ==== 3. Sonstige Normen ==== | ||
| + | |||
| + | ^Kennung^Jahr^Titel^Anmerkung| | ||
| + | |[[: | ||
| + | |[[http:// | ||
| + | |[[http:// | ||
| + | |[[http:// | ||
| + | |[[http:// | ||
| ===== 1 Risiko: Definition und Herausforderungen ===== | ===== 1 Risiko: Definition und Herausforderungen ===== | ||
| Zeile 15: | Zeile 95: | ||
| * **Wahrscheinlichkeit**: | * **Wahrscheinlichkeit**: | ||
| * **Schwere des Schadens**: Die potenziellen Konsequenzen, | * **Schwere des Schadens**: Die potenziellen Konsequenzen, | ||
| - | + | **Hinweis: | |
| - | **Hinweis: | + | |
| In der Funktionalen Sicherheit werden Sicherheitsfunktionen (Steuerungsfunktionen) zur Minderung von Risiken eingesetzt. Die Sicherheit hängt in diesem Zusammenhang also direkt von der korrekten Funktion der steuerungstechnischen Maßnahme ab. | In der Funktionalen Sicherheit werden Sicherheitsfunktionen (Steuerungsfunktionen) zur Minderung von Risiken eingesetzt. Die Sicherheit hängt in diesem Zusammenhang also direkt von der korrekten Funktion der steuerungstechnischen Maßnahme ab. | ||
| Zeile 25: | Zeile 104: | ||
| Diese Parameter können im besten Fall semi-quantitativ beschrieben werden, und die Risikoparameter müssen für unterschiedliche Anwendungsfälle (Maschinen, Prozessindustrie, | Diese Parameter können im besten Fall semi-quantitativ beschrieben werden, und die Risikoparameter müssen für unterschiedliche Anwendungsfälle (Maschinen, Prozessindustrie, | ||
| + | |||
| + | Ein weiteres Problem stellen mögliche Widersprüche hinsichtlich der Verfügbarkeit der Maschinen oder Anlagenfunktion und Zuverlässigkeit der Sicherheitsfunktion(en) dar. Bei ungünstiger Auslegung der Sicherheitsfunktionen kann es zu häufigen ungewollten Unterbrechungen der Maschinen- oder Anlagenfunktion kommen. Der Nachweis der Sicherheitsintegrität der Hardware lässt sich durch Anwendung geeigneten Methoden quantitativ erbringen und drückt sich letztendlich in der berechneten gefahrbringenden Ausfallwahrscheinlichkeit aus. Allerdings lassen sich Maßnahmen zur Vermeidung systematischer Entwicklungsfehler quantitativ nicht erfassen. Problematisch ist in diesem Zusammenhang auch der Nachweis der Sicherheitsintegrität der Software, da für die Software keine Ausfallwahrscheinlichkeit berechnet werden kann, denn Software kann nur systematische Fehler enthalten und nicht zufällig ausfallen. Aus diesem Grund werden deterministische Ansätze (z. B. Verwendung von Hardware-Redundanzen oder Methoden zur Erkennung von Hardware-Ausfällen) mit verschiedenen Methoden zur Vermeidung systematischer Entwicklungsfehler kombiniert. Dadurch sollen einerseits zufällige Hardware-Ausfälle beherrscht und systematische Entwicklungsfehler möglichst vermieden oder ebenfalls beherrscht werden. | ||
| + | |||
| + | Weitere Probleme können durch mögliche Widersprüche hinsichtlich der Anforderungen an die Funktionale Sicherheit und Anforderungen an die IT-Security entstehen. Die Normen der Funktionalen Sicherheit definieren keine eigenen IT-Security Anforderungen, | ||
| + | |||
| + | Unscharfe Risikobeiträge werden nur bei der Berechnung der Ausfallwahrscheinlichkeit bei elektronischer Hardware berücksichtigt. Dazu werden die bekannten Methoden der Statistik verwendet, d. h. Berücksichtigung von statistischen Verteilungen der Bauteil-Ausfallraten (standardmäßig Weibull-Verteilung) und Festlegung von zulässigen Konfidenzintervallen für die verwendeten Ausfallraten. Die Unsicherheiten bei der Bestimmung der Ausfallwahrscheinlichkeit sind damit mathematisch gut zu erfassen. Generell lässt sich sagen, dass bei der Berechnung der Ausfallwahrscheinlichkeiten normalerweise mit „konservativen“ Werten für die Ausfallraten gerechnet wird, so dass Unsicherheiten in der Regel keinen negativen Einfluss auf die Funktionale Sicherheit haben. Für die Bestimmung von Ausfallwerten bei der Mechanik werden auch B10d Werte bestimmt. Die Mechanik wird längere Zeit betrieben und die Anzahl der gefährlichen Ausfälle empirisch bestimmt. | ||
| + | |||
| + | [[https:// | ||
| + | |||
| + | * Generelle Anforderungen werden beschrieben in Richtlinie 2006/42/EG Anhang I und in ISO 12100:2010 | ||
| + | * Einige generelle Anforderungen zur Security in Richtlinie 2006/42/EG Anhang I 1.2.1. und in ISO 12100 Abschnitt 5.5.3.6 werden beschrieben | ||
| + | * Mutwillige Überwindung von Schutzeinrichtungen; | ||
| + | * Betrachtet werden im Wesentlichen Gefahren für einzelne Personen. In Einschränkung der IEC 61508 werden Personenschäden für mehrere Personen nicht schwerer eingestuft als ein einzelner Personenschaden, | ||
| + | * Typische Schadensarten sind z.B. Quetschen/ | ||
| + | |||
| + | ==== 1.2 Security ==== | ||
| + | |||
| + | // | ||
| + | |||
| + | === 1.2.1 Definitionen === | ||
| + | |||
| + | Die Security in der Anlagensicherheit ist traditionell (bedingt durch deren historische Ausprägung) oft in verschiedene Fachgebiete unterteilt. Grundsätzlich und vereinfacht dargestellt kann zwischen Physical Security und IT-Security (wobei IT/ | ||
| + | |||
| + | Die IT-Security in der Anlagensicherheit ist aus der Historie betrachtet ebenfalls in zwei Fachgebiete zu unterteilen. Die „Office-IT-Security“ wird dabei häufig als der „klassische“ bzw. ursprüngliche Bereich der IT-Security betrachtet. Mit der Einführung von allgemeinzugänglichen EDV-Systemen (im Gegensatz zu den frühen „Mainframes oder Supercomputern“, | ||
| + | |||
| + | Diese zu schützenden Kernelemente sind die heute für die IT-Security maßgeblichen Werte und stellen die primären Sicherheitsziele dar: | ||
| + | |||
| + | * Vertraulichkeit | ||
| + | * Integrität | ||
| + | * Verfügbarkeit | ||
| + | |||
| + | Daraus abgeleitet etablierten sich im Laufe der Zeit noch weitere Parameter (zumeist ableitbar aus den oben genannten Werten), welche aber nicht direkt zu den genannten Werten gezählt werden: | ||
| + | |||
| + | * Authentizität | ||
| + | * Verbindlichkeit / Nichtabstreitbarkeit | ||
| + | * Zurechenbarkeit bzw. Anonymität | ||
| + | |||
| + | Der zweite historische Pfeiler der IT-Security ist in der OT-Security (Operational Technology Security) zu sehen, welche stark an Bedeutung gewinnt. Verstärkt wird dies durch den voranschreitenden Trend der Digitalisierung in dessen Sogwirkung auch alte und somit bisher offline betriebene Anlagenteile vernetzt werden, was gänzlich neue Betrachtung zum Thema OT-Security notwendig macht. | ||
| + | |||
| + | Aufgrund der immer stärker werdenden Integration und Vernetzung von Produktionsanlagen (OT-Netzwerke) mit dem Office / | ||
| + | |||
| + | Das Security Risiko wird ähnlich wie bei Safety aus dem Produkt vom Schadenausmaß und der Eintrittswahrscheinlichkeit bestimmt. Um das Risiko zu vermindern, werden geeignete Gegenmaßnahmen implementiert, | ||
| + | |||
| + | Im Gegensatz zu herkömmlichen Risikobetrachtungen ist in der IT-Security sowohl der Eintritt des Schadensereignisses als auch die Vermeidung oder Begrenzung des Schadens schwierig zu fassen, da beides abhängig ist vom aktuellen Stand des Wissens (nicht Stand der Technik). So können jahrelang als sicher geltende Prozeduren/ | ||
| + | |||
| + | Stark vereinfacht können viele der Lösungsansätze grundsätzliche auf zwei Herangehensweisen reduziert werden. | ||
| + | |||
| + | 1) Durch Betrachtung des aktuellen Ist-Zustandes sowohl in Bezug auf Angriffs- und Verteidigungswerkzeuge lassen sich die aktuelle Bedrohung und auch Gefährdung ableiten. Dies offenbart sich auch in den Definitionen für Bedrohung und Gefährdung, | ||
| + | |||
| + | **IT-Bedrohung**: | ||
| + | |||
| + | **Gefährdung**: | ||
| + | |||
| + | **IT-Gefährdung**: | ||
| + | |||
| + | 2) Im relativ starken Kontrast dazu stehen „Assume the Breach“ Ansätze (grob zu übersetzten mit „erwarte den Angriff“). Diesen Ansätzen gemein ist die Tatsache, dass davon ausgegangen wird, dass ein System kompromittiert, | ||
| + | |||
| + | ==== 1.3 Herausforderungen ==== | ||
| + | |||
| + | Aufgrund der historischen Entwicklung (siehe oben) haben sich diverse Vorgehensweisen, | ||
| + | |||
| + | Durch das (oftmals wirtschaftlich erzwungene) Zusammenwachsen verschiedener Teilbereiche von vorher offline betriebenen Systemen (Digitalisierung, | ||
| + | |||
| + | Aktuell entstehen sehr viele unterschiedliche IT-Security Standards (bzw. Werke zum Umgang mit Digitalisierung) auf nationaler und internationaler Ebene. Dabei sind nicht nur Umfang und Anzahl der Dokumente problematisch, | ||
| + | |||
| + | IT-Risikoanalysen sind bei Weitem nicht so stark standardisiert und objektiv wie ihre Äquivalente aus dem Bereich Safety. Die Bedrohungslage bzw. die Schwachstellen verändern sich laufend und zum Teil sehr schnell. Was heute sicher eingestuft wurde, kann morgen schon unsicher sein. Der mögliche Schaden ist eher abzuschätzen als genau zu beziffern. Die Eintrittswahrscheinlichkeit hängt von zahlreichen Faktoren ab, die oft nur intuitiv abgeschätzt werden können. Dies führt dazu, dass bei einer IT-Risikoanalyse die Einschätzungen der Fachleute oft stark auseinander gehen und von Dritten nicht einfach nachzuvollziehen sind. | ||
| + | |||
| + | Viele Fragen technischer oder organisatorischer Natur sind bisher nicht eindeutig beantwortbar, | ||
| + | |||
| + | Die Erwartungen an „KI“ bzw. „selbstlernende Systeme“ zur IT-Security (Virenscanner, | ||
| + | |||
| + | Security ist in vielen Bereichen immer noch nicht regulärer Bestandteil des Design-Prozesses (Security by Design) sondern wird je nach Budget im Anschluss an Engineering und Designentscheidungen kurzfristig hinzugefügt. Die daraus resultierenden Probleme sind gut an vielen modernen IoT-Bauteilen zu sehen, welche oftmals mit massiven Sicherheitslücken auf den Markt kommen (Kleinhans, 2016) (Foltýn, 2018). Ein Nachrüsten (nachträgliches integrieren von Security) ist oft aus diversen Gründen schwierig (fehlende finanzielle Mittel, fehlender Platz im Gerät, zusätzliche Wärmeentwicklung im Gerät, zusätzlicher Stromverbrauch des Gerätes etc.). | ||
| + | |||
| + | Die Wirksamkeit einer IT-Security-Maßnahme ist oftmals zeitlich beschränkt, | ||
| + | |||
| + | * Es existiert ein unbekannter Fehler (Software oder Hardware) im Produkt oder der Schutzmaßnahme, | ||
| + | * Die Schutzmaßnahme wird bedingt durch den technischen Fortschritt unwirksam, wobei technischer Fortschritt sowohl mehr Rechenleistung als auch neue Funktionsweisen beinhaltet. Ein Beispiel für letzteres wäre die sich seit langem anbahnende Entwicklung von Quantencomputern, | ||
| + | * Die Schutzmaßnahme basiert auf dem Nichtwissen um die Funktion bzw. des Vorhandenseins der Information (Security by Obscurity). So sind Beispielweise mittels Steganographie „verschlüsselte“ Informationen (z.B. ein in einem Bild versteckter Text) lediglich „versteckt“. Weiß der Angreifer um die Existenz der Information ist die Schutzmaßnahme oft wirkungslos. | ||
| + | |||
| + | ===== 2 Durchführung von Risikoanalysen ===== | ||
| + | |||
| + | ==== 2.1 Safety ==== | ||
| + | |||
| + | In der Funktionalen Sicherheit werden Risikoanalysen im Wesentlichen qualitativ oder semiquantitativ durchgeführt. Zunächst werden in der Regel an einem System potenzielle Gefährdungen unter Zuhilfenahme von qualitativen Methoden identifiziert. Mögliche Methoden zur Durchführung von Risikoanalysen sind z. B. in spezifischen Normen beschrieben, | ||
| + | |||
| + | * Sicherheits-Durchsprachen | ||
| + | * Checklisten | ||
| + | * Was-wäre-wenn-Analysen | ||
| + | * HAZOP (Hazard and Operability Study) | ||
| + | * FMEA (Failure Mode and Effects Analysis) | ||
| + | * Ursache-Wirkungs-Analyse | ||
| + | |||
| + | Diesen Methoden ist gemein, dass sie grundlegend einen qualitativen Ansatz zur Identifizierung von möglichen Gefährdungen verfolgen. Die Ergebnisse können jedoch für eine quantitative Bewertung von Sicherheitsfunktionen (Berechnung der gefahrbringenden Ausfallwahrscheinlichkeit) weiterverwendet werden. | ||
| + | |||
| + | Für alle identifizierten Gefährdungen wird anschließend das Risiko anhand des potenziellen Schadensausmaßes und der Eintrittswahrscheinlichkeit abgeschätzt. Auch diese Abschätzung des Risikos erfolgt im Wesentlichen qualitativ, nur einige Parameter lassen sich zum Teil quantitativ grob abschätzen (z. B. hängt die Wahrscheinlichkeit des Eintritts eines Schadens von der Gefährdungsexposition ab (Häufigkeit/ | ||
| + | |||
| + | **Schaden** | ||
| + | |||
| + | * in der ISO 13849-1: leicht, reversibel; ernst, irreversibel/ | ||
| + | * in der IEC 62061: irreversibel: | ||
| + | |||
| + | **Häufigkeit und Dauer** | ||
| + | |||
| + | * ISO 13849-1: Selten oder kurz (weniger als 1-mal pro 15 Minuten, nicht mehr als 1/20 der Gesamtbetriebsdauer); | ||
| + | * IEC 62061: ≤ 1h; > 1 h bis ≤ 1 Tag; > 1 Tag bis ≤ 2 Wochen; > 2 Wochen bis ≤ 1 Jahr; > 1 Jahr; alle jeweils unterschieden in Dauer kleiner/ | ||
| + | |||
| + | Möglichkeit zur **Vermeidung** | ||
| + | |||
| + | * beide o.g. Normen nennen nur qualitative Einschätzungen (unmöglich, | ||
| + | * andere Normen im Maschinenbau geben für bestimmte Bewegungsarten quantitative Werte für langsame Bewegungen an (z.B. 25cm/s für Roboter, wenn nichts den betroffenen Menschen am Ausweichen hindert) | ||
| + | |||
| + | **Wahrscheinlichkeit** | ||
| + | |||
| + | * ISO 13849-1: Niedrig, normal | ||
| + | * IEC 62061: sehr hoch, wahrscheinlich, | ||
| + | |||
| + | Allen Risiken, die mittels technischer Schutzeinrichtungen (d. h. steuerungstechnischer Maßnahmen) gemindert werden sollen, wird eine erforderliche Stufe der Sicherheitsintegrität (SIL: Safety Integrity Level) zugewiesen. Die Norm IEC 61508 definiert insgesamt vier Stufen der Sicherheitsintegrität. SIL 1 spiegelt hierbei die niedrigste Stufe und SIL 4 die höchste Stufe der Sicherheitsintegrität wider. Eine häufig verwendete Möglichkeit für die Zuweisung des erforderlichen SILs ist die Anwendung eines so genannten Risikographen (siehe Abbildung 2). Die Risikoparameter (C, F, P, W) müssen für den jeweiligen Anwendungsfall kalibriert werden. IEC 61508-5 enthält weitere Hinweise zur Kalibrierung der Risikoparameter sowie alternative Methoden zur Ermittlung der erforderlichen Stufe der Sicherheitsintegrität. | ||
| + | |||
| + | Abbildung 2: Risikograph zur Ermittlung des erforderlichen SILs (Quelle: IEC 61508-5) | ||
| + | |||
| + | Je nach Stufe der erforderlichen Sicherheitsintegrität wird eine maximal zulässige Ausfallwahrscheinlichkeit der sicherheitsrelevanten Steuerungsfunktion definiert. Der Nachweis, dass die geforderte Ausfallwahrscheinlichkeit eingehalten wird, lässt sich gut mit den bekannten Methoden der Zuverlässigkeitstechnik quantitativ bestimmen (Berücksichtigung der Bauteil-Ausfallraten und Berechnung der gesamten Ausfallwahrscheinlichkeit über Zuverlässigkeitsblock-Diagramme, | ||
| + | |||
| + | Wechselwirkungen bezüglich Security-Anforderungen werden in den Normen der Funktionalen Sicherheit nicht behandelt. Die Norm IEC 61508 macht dazu die folgende Aussage: „[…] fordert diese Norm, dass boshafte und nicht autorisierte Handlungen, während der Gefährdung und Risikoanalyse zu betrachten sind. Der Anwendungsbereich der Analyse schließt alle relevanten Phasen des Sicherheitslebenszyklus ein; […]“ (vgl. IEC 61508-1: | ||
| + | |||
| + | Security-Anforderungen müssen also bei der Gefährdungs- und Risikoanalyse über alle Phasen des Sicherheitslebenszyklus betrachtet werden. Bezüglich der IT-Security wird auf ISO/IEC TR 19791 und die Normenreihe IEC 62443 verwiesen. | ||
| + | |||
| + | Da boshafte oder nicht autorisierte Handlungen dazu führen können, dass die Sicherheitsfunktionen zur Risikominderung nicht mehr wie vorgesehen funktionieren und das Risiko dementsprechend nicht mehr mindern können, ist Security eine grundlegende Voraussetzung für die Gewährleistung der Funktionalen Sicherheit. | ||
| + | |||
| + | __false__ | ||
| + | |||
| + | ===== 3 Domänenübergreifende Zusammenführung ===== | ||
| + | |||
| + | Die beschriebenen Probleme treten in angrenzenden Disziplinen in ähnlicher Weise auf. Der Begriff Risiko ist quantitativ nicht exakt definierbar, | ||
| + | |||
| + | In der Disziplin der Funktionalen Sicherheit lässt sich die erreichte Stufe der Sicherheitsintegrität einer Sicherheitsfunktion insbesondere für die Hardware quantitativ erbringen, jedoch ist der Nachweis für die Software nur zu einem geringen Teil quantitativ möglich (Anwendung von Software-Metriken z.B. zum Nachweis der Code-Abdeckung oder zur Bewertung der Modul-Komplexität). Maßnahmen zur Vermeidung systematischer Entwicklungsfehler können quantitativ nicht hinreichend bewertet werden. Diese Probleme bestehen in gleichem Maße in angrenzenden Disziplinen. | ||
| + | |||
| + | Auf Grund der zunehmenden Digitalisierung und Vernetzung von technischen Systemen und Einrichtungen rücken Anforderungen an die Security zunehmend in den Fokus der Sicherheitstechnik. Da Security eine grundlegende Voraussetzung für die Gewährleistung der Funktionalen Sicherheit ist, müssen Anstrengungen getroffen werden, um die Anforderungen beider Disziplinen zu vereinen oder klare Schnittstellen mit klaren Zuständigkeiten etabliert werden, wobei letzteres in Anbetracht aktueller Entwicklungen immer schwieriger umzusetzen ist. Die Norm IEC 61508 fordert hierzu grundlegend, | ||
| + | |||
| + | Als gemeinsamer Nenner für die Quantifizierung von Risiken in Safety- und Security Modellen könnte die Stufe der erforderlichen Sicherheitsintegrität (SIL) dienen. Je höher das Risiko ist, welches mit einer Sicherheitsfunktion gemindert werden soll, desto höher ist die erforderliche Stufe der Sicherheitsintegrität. Einer erforderlichen SIL könnten also zusätzlich auch (Mindest-)Maßnahmen zur Gewährleistung der Security zugeordnet werden, ähnlich wie es mit dem Security Level (SL) der IEC 62443-Reihe versucht wird. Allerdings zeigt sich gerade in diesem Bereich der Security, wie die Randbedingungen zur Risikobewertung einer hohen Volatilität unterliegen, | ||
| + | |||
| + | Für die Synthese der beiden Domänen wären die folgenden Fragestellungen relevant: | ||
| + | |||
| + | * Welche Security-Maßnahmen sollten den jeweiligen Stufen der Sicherheitsintegrität (SIL) (mindestens) zugeordnet werden? Welche Unterschiede sind bei verschiedenen Anwendungsfeldern gegebenenfalls zu berücksichtigen? | ||
| + | * Wie lässt sich die Wirksamkeit von Security-Maßnahmen einheitlich bewerten? Gibt es quantitative Methoden zur Bewertung der Maßnahmen? | ||
| + | * Welche Verifikations- und Validationsmaßnahmen (z.B. Penetrations-Tests) sollten mindestens durchgeführt werden, um die Wirksamkeit der Security-Maßnahmen zu gewährleisten? | ||
| + | * Welche Konflikte bezüglich der Anforderungen an die Funktionale Sicherheit und der Security sind typischerweise in der praktischen Anwendung zu erwarten und welche Handlungsempfehlungen sollen für die Auflösung der Konflikte ausgesprochen werden? | ||
| + | * Welche ethischen Fragestellungen ergeben sich aus den im vorhergehenden Punkt genannten Konflikten und können auf diese Fragestellungen Antworten/ | ||
| + | |||
| + | Eine Quantifizierung von Risiken ist vor allem bei Security sehr problematisch. Ein wichtiger Faktor ist die Bewertung der Motivation und die Fähigkeiten eines potenziellen Angreifers, die man schwer abschätzen kann, insbesondere nicht in quantitativer Form. Es ist Gegenstand aktueller Forschung, wie eine Quantifizierung im Bereich der Security ermöglicht werden kann. Während die Quantifizierung in der Safety bereits weit entwickelt ist, scheint eine einfache Lösung für den Bereich der Security nicht in Sicht. Dies liegt insbesondere daran, dass die Einflüsse auf die Safety als Funktion, der der Zeit angenähert werden können. Das Verhalten von Angreiferinnen und Angreifern lässt sich nicht vorhersagen. Für die Quantifizierung kann die Ausfallrate von 1000 Halbleiterbauteilen systematisch bestimmt werden. Programmierfehler lassen sich dagegen kaum für eine sinnvolle Quantifizierung verwenden. Entweder kann ein Fehler automatisiert gefunden werden, dann sollten er leicht vor Auslieferung gefunden werden können. Oder es handelt sich um Fehler, der aktuell nur durch einen Menschen gefunden werden kann, dann hängt die Erkennungsrate ebenso vom Menschen ab, wie die Fehlerrate beim Codieren. | ||
| + | |||
| + | Es gibt auch Ansätze, die Software-Qualität statistisch zu erfassen. Siehe dazu “Software Reliability Engineering: | ||
| + | |||
| + | [[https:// | ||
| + | |||
| + | Die Schwachstellen werden teilweise bereits gut erfasst und auch mathematisch bewertet (siehe Abbildung 4). Zur Bewertung des Risikos müsste noch die aktuellen Bedrohungen systematisch erfasst und bewertet werden. Es gibt zwar schon vom BSI aktualisierte Bedrohungskataloge bzw. für einzelne Jahre Übersichten von Angriffen. Wünschenswert wäre hier die Einführung der systematischen Erfassung von Bedrohungen und deren Bewertung analog zu den Schwachstellen. | ||
| + | |||
| + | Da die Bestimmung des Security Levels sich schwierig gestaltet, gib es einen pragmatischen Ansatz, der eine Zuordnung eines SL 2 vorsieht. Bei Erkennung eines erhöhten Risikos wird auf SL 3 erhöht. Ein SL 1 ist zu wenig und bei einem SL 4 sind die Gegenmaßnahmen derart aufwendig, dass sie kaum umgesetzt werden können. Zudem muss sich in der Praxis noch herausstellen, | ||
| + | |||
| + | Ein weiteres spannendes Thema ist die Kombination von Safety und Security-Anforderungen. So verlangt die Safety bei einem Safety relevanten Ereignis eine Reaktion ich Echtzeit. Durch den Einsatz von Kryptographie, | ||
| + | |||
| + | Wenn Safety und Security in einem Gerät kombiniert werden, muss auch bei jeder Änderung im Security-Teil eine komplette Safety Änderungsprüfung durchgeführt werden. Hier empfiehlt es sich, die Safety von der Security strikt zu trennen. | ||
| + | |||
| + | Das Security-Risiko kann auch erheblich reduziert werden, wenn der physische Zugang zum Gerät eingeschränkt wird. Das Gerät sollte in einem Bereich mit beschränktem Zugang installiert sein. Der Zugang über Schnittstelle kann zudem zeitlich beschränkt oder extra abgesichert werden. | ||
| + | |||
| + | Für die Validation der Security-Anforderungen wird der Penetration-Test angewendet. Hier werden unabhängigen Personen mit gutem Fachwissen mit der detaillierten Geräteinformation beauftragt, die eingebauten Sicherheitsmechanismen zu umgehen. Die Güte der Tests hängt sehr stark von der Kreativität und Können des Testers ab. Hier empfiehlt es sich Test-Personen einzusetzen, | ||
| + | |||
| + | [[https:// | ||
| + | |||