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/10 13:43] – [2 Durchführung von Risikoanalysen] 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 26: | Zeile 105: | ||
| 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. | + | 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. |
| - | 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 | + | 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, |
| - | 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. | 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:// | + | [[https:// |
| * Generelle Anforderungen werden beschrieben in Richtlinie 2006/42/EG Anhang I und in ISO 12100:2010 | * Generelle Anforderungen werden beschrieben in Richtlinie 2006/42/EG Anhang I und in ISO 12100:2010 | ||
| Zeile 46: | Zeile 120: | ||
| ==== 1.2 Security ==== | ==== 1.2 Security ==== | ||
| - | // | + | |
| - | Risikodefinitionen und Herangehensweisen erklären, sind für sich selbst aber nicht abschließend oder als alleinig richtig/ | + | // |
| - | // | + | |
| === 1.2.1 Definitionen === | === 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/ | ||
| - | Zusätzlich wird ausgehend (aber nicht ausschließlich) von den Erfordernissen an | ||
| - | Kamera/ | ||
| - | 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“, | + | 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: | Diese zu schützenden Kernelemente sind die heute für die IT-Security maßgeblichen Werte und stellen die primären Sicherheitsziele dar: | ||
| + | |||
| * Vertraulichkeit | * Vertraulichkeit | ||
| * Integrität | * Integrität | ||
| Zeile 63: | Zeile 136: | ||
| 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: | 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 | * Authentizität | ||
| * Verbindlichkeit / Nichtabstreitbarkeit | * Verbindlichkeit / Nichtabstreitbarkeit | ||
| Zeile 71: | Zeile 145: | ||
| Aufgrund der immer stärker werdenden Integration und Vernetzung von Produktionsanlagen (OT-Netzwerke) mit dem Office / | 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 | + | 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, |
| - | 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/ | 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/ | ||
| Zeile 78: | Zeile 151: | ||
| Stark vereinfacht können viele der Lösungsansätze grundsätzliche auf zwei Herangehensweisen reduziert werden. | 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 | + | 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, |
| - | 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**: | + | **IT-Bedrohung**: |
| - | Vertraulichkeit von Informationen beeinträchtigen kann, wodurch dem Besitzer bzw. Benutzer der | + | |
| - | Informationen ein Schaden entstehen kann. (Quelle: Bundesamt für Sicherheit in der Informationstechnik, | + | |
| **Gefährdung**: | **Gefährdung**: | ||
| Zeile 90: | Zeile 159: | ||
| **IT-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, | |
| - | 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, | + | |
| - | Dies hat zur Folge, dass einzelne Systeme stark gesichert werden, wobei der Sicherungsverbund in den Hintergrund tritt. Ein großer Vorteil wird im Aufheben des falschen Gefühls der Sicherheit gesehen, da es sich in vielen Bereichen gezeigt hat, dass erfolgreiche Angriffe nur eine Frage der Zeit sind oder von der unangemessenen Handlung nur eines Mitarbeiters ausgelöst werden kann. „Assume the Breach“ soll zu einer besseren Sicherheitskultur führen, da permanent von einem Angriff ausgegangen wird und die Wirksamkeit der eigenen Abwehrkapazitäten stets kritisch betrachtetet wird. Der größte Nachteil sind die relativ hohen Kosten (entstehend durch den deutlichen Mehraufwand für Sicherheit einzelner Bauteile/ | + | |
| ==== 1.3 Herausforderungen ==== | ==== 1.3 Herausforderungen ==== | ||
| + | |||
| Aufgrund der historischen Entwicklung (siehe oben) haben sich diverse Vorgehensweisen, | Aufgrund der historischen Entwicklung (siehe oben) haben sich diverse Vorgehensweisen, | ||
| Zeile 101: | Zeile 169: | ||
| 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, | 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 | + | 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. |
| - | Ä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, | + | Viele Fragen technischer oder organisatorischer Natur sind bisher nicht eindeutig beantwortbar, |
| - | Zusätzlich haben Virenscanner oft einen negativen Einfluss auf die Performance bzw. verzögern Prozesse, was gerade im Zusammenspiel mit Safety zu großen Problemen führen kann. | + | |
| Die Erwartungen an „KI“ bzw. „selbstlernende Systeme“ zur IT-Security (Virenscanner, | 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 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.). |
| - | (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, | + | Die Wirksamkeit einer IT-Security-Maßnahme ist oftmals zeitlich beschränkt, |
| - | Zeitpunkt ihres „unwirksam“ Werdens zumeist nicht vorhersehbar ist, da er nicht auf physische Grundlagen (z.B. Materialermüdung) beruht. Dabei können mehrere Fälle unterscheiden werden: | + | |
| - | * Es existiert ein unbekannter Fehler (Software oder Hardware) im Produkt oder der Schutzmaßnahme, | + | * 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 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. | * 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 Durchführung von Risikoanalysen ===== | ||
| + | |||
| ==== 2.1 Safety ==== | ==== 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, | + | 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, |
| - | verwiesen. Die Normen IEC 61508 und IEC 61511 schlagen für die Durchführung von Gefährdungsanalysen unter anderem die folgenden Methoden vor: | + | |
| * Sicherheits-Durchsprachen | * Sicherheits-Durchsprachen | ||
| * Checklisten | * Checklisten | ||
| Zeile 133: | Zeile 198: | ||
| 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. | 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 | + | 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/ |
| - | 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** |
| - | **Schaden** wird semi-quantitativ beurteilt: | ||
| * in der ISO 13849-1: leicht, reversibel; ernst, irreversibel/ | * in der ISO 13849-1: leicht, reversibel; ernst, irreversibel/ | ||
| * in der IEC 62061: irreversibel: | * in der IEC 62061: irreversibel: | ||
| - | **Häufigkeit und Dauer** der Exposition wird quantitativ beurteilt: | + | |
| + | **Häufigkeit und Dauer** | ||
| * ISO 13849-1: Selten oder kurz (weniger als 1-mal pro 15 Minuten, nicht mehr als 1/20 der Gesamtbetriebsdauer); | * 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/ | * 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** der Gefährdungsereignisse wird semi-quantitativ beurteilt: | + | |
| + | Möglichkeit zur **Vermeidung** | ||
| * beide o.g. Normen nennen nur qualitative Einschätzungen (unmöglich, | * 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) | * 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** des Schadenseintritts wird qualitativ beurteilt | + | |
| + | **Wahrscheinlichkeit** | ||
| * ISO 13849-1: Niedrig, normal | * ISO 13849-1: Niedrig, normal | ||
| * IEC 62061: sehr hoch, wahrscheinlich, | * 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. | 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) | Abbildung 2: Risikograph zur Ermittlung des erforderlichen SILs (Quelle: IEC 61508-5) | ||
| - | Je nach Stufe der erforderlichen Sicherheitsintegrität wird eine maximal zulässige | + | 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, |
| - | 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: | + | 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: |
| - | „[…] 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. | 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. | ||
| Zeile 165: | Zeile 232: | ||
| 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. | 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. | ||
| - | ==== 2.2 Security ==== | + | __false__ |
| - | Bei einer Risikoanalyse werden grundsätzlich die zu schützende Werte (sogenannte Assets) bestimmt. Danach wird das Schadensausmaß bewertet, welches beim Verlust des Wertes eintreten kann. Dabei kann der potenzielle Schaden in unterschiedliche Kategorien eingeteilt werden, beispielsweise: | + | |
| - | * Finanzieller Verlust | + | |
| - | * Verlust von Ansehen (Image) | + | |
| - | * Verletzung von rechtlichen Vorgaben (z.B. Datenschutz) | + | |
| - | * Personenschäden bzw. Tod von Personen, Umweltschäden | + | |
| - | Diese Informationen sind Ausgangpunkt für die eigentliche Risikoanalyse, | + | |
| - | **1) BSI-Grundschutz Standard 200-3 (Bundesamt für Sicherheit in der Informationstechnik (BSI), 2017) | + | ===== 3 Domänenübergreifende Zusammenführung ===== |
| - | ** | + | |
| - | Zur Vorbereitung der Risikoanalyse werden die Assets einer Schutzbedarfsfeststellung unterzogen. Hierfür wird jedem Asset ein Schutzbedarf (normal, hoch, sehr hoch) für jeden der Werte (Verfügbarkeit, | + | |
| - | Für Elemente mit einem hohen oder sehr hohen Schutzbedarf ist eine Risikoanalyse verpflichtend. Für den Schutzbedarf „normal“ obliegt die Entscheidung, | + | |
| - | **Schritt 1**: Erstellung einer Gefährdungsübersicht | ||
| - | Zunächst wird eine Gefährdungsübersicht erstellt. Dazu dient eine vorgegebene Liste mit elementaren Gefährdungen, | ||
| - | |||
| - | * Zusammenstellung einer Liste von möglichen elementaren Gefährdungen in Abhängigkeit ihrer Auswirkungen auf die jeweiligen Assets | ||
| - | * Ermittlung zusätzlicher Gefährdungen, | ||
| - | |||
| - | |||
| - | Abbildung 3: Gefährdungen (Auszug) und ihr möglicher Einfluss auf die Grundwerte, aus BSI-Standard 200-3 | ||
| - | |||
| - | **Schritt 2**: Risikoeinstufung | ||
| - | Die Einstufung des Risikos ist in zwei Schritte eingeteilt, die Einschätzung und die Bewertung des Risikos. | ||
| - | |||
| - | **Risikoeinschätzung** | ||
| - | |||
| - | Es werden die Risiken ermittelt, welche von den festgestellten Gefährdungen ausgehen. Diese hängen von Eintrittshäufigkeit und Höhe des Schadens ab. | ||
| - | Die Schadenshöhe kann dabei durch die durchführende Institution nur selbst eingeschätzt werden. Dabei müssen die direkten Schäden, finanzieller oder anderer Art, und auch Folgeschäden berücksichtigt werden. Auch die Abschätzung der Aufwände bezüglich der Schadensbehebung sollten berücksichtigt werden. Die Schadenshöhe wird in 4 Kategorien eingeteilt: | ||
| - | * Vernachlässigbar | ||
| - | * Begrenzt | ||
| - | * Beträchtlich | ||
| - | * Existenzbedrohend | ||
| - | |||
| - | Die Eintrittshäufigkeit kann nur durch Fachpersonal mit entsprechender Expertise eingeschätzt werden. Dabei wird hauptsächlich auf Erfahrungswerte zurückgegriffen, | ||
| - | * Selten (< 1x / 5 Jahre) | ||
| - | * Mittel (alle 1 bis 5 Jahre) | ||
| - | * Häufig (< 1x / Monat) | ||
| - | * Sehr häufig (mehrmals pro Monat) | ||
| - | |||
| - | **Risikobewertung** | ||
| - | |||
| - | Anhand z.B. einer Risikomatrix werden die Risiken bewertet. Dazu dienen die ermittelten Werte für Schadenshöhe und Eintrittshäufigkeit. | ||
| - | * Gering | ||
| - | * Mittel | ||
| - | * Hoch | ||
| - | * Sehr hoch | ||
| - | |||
| - | |||
| - | Abbildung 4: Matrix zur Einstufung von Risiken aus BSI-Standard 200-3 | ||
| - | |||
| - | **Schritt 3**: Risikobehandlung | ||
| - | Abhängig von der jeweiligen Institution müssen die Risiken im nächsten Schritt behandelt werden. Dies kann dabei abhängig z.B. vom Risikoappetit der Institution sein. Zur Behandlung der verbleibenden Risiken ergeben sich dabei 4 Möglichkeiten: | ||
| - | |||
| - | * Risikovermeidung, | ||
| - | * Risikoreduktion, | ||
| - | * Risikotransfer, | ||
| - | * Risikoakzeptanz, | ||
| - | |||
| - | Der BSI-Standard 200-3 sieht darüber hinaus das Konzept der „Risiken unter Beobachtung“ vor. Dies gilt für akzeptierte Risiken, von denen jedoch zu erwarten ist, dass diese sich in der Zukunft erhöhen werden. Für diese sollten bereits ergänzende Sicherheitsmaßnahmen erarbeitet werden, welche dann gezielt in Betrieb genommen werden können. | ||
| - | |||
| - | **Schritt 4**: Konsolidierung des Sicherheitskonzepts | ||
| - | Wurden anhand der Risikoanalyse ergänzende Maßnahmen hinzugefügt, | ||
| - | * Eignung: Sind die Maßnahmen wirklich geeignet alle relevanten Gefährdungen vollständig abzudecken? | ||
| - | * Zusammenwirkung: | ||
| - | * Benutzerfreundlichkeit: | ||
| - | * Angemessenheit: | ||
| - | Auf Grundlage dieser Fragestellungen sollen die Maßnahmen bereinigt (durch Verwerfen und Ersetzen, Auflösen von Widersprüchen oder durch Überarbeitung) und final in das Sicherheitskonzept integriert werden. | ||
| - | |||
| - | **2) IEC 62443-Reihe: | ||
| - | |||
| - | Die verschiedenen Teile der IEC 62443 Normen-Familie an Cybersicherheitsstandards richten sich an verschiedene beteiligte Rollen und definieren die Aufgaben und Pflichten dieser Rollen. Dazu gehören Hersteller, Integratoren und Betreiber. Ein zentraler Bestandteil, | ||
| - | |||
| - | Tabelle 1 Sicherheitslevel (SL) nach IEC 62443 | ||
| - | ^ SL ^ Beschreibung ^ | ||
| - | | 1 | Schutz vor zufälligen, | ||
| - | | 2 | Schutz vor absichtlichen Verstößen mit einfachen Mitteln, geringem Aufwand, allgemeinen Fähigkeiten und geringer Motivation | | ||
| - | | 3 | Schutz vor absichtlichen Verstößen mit fortgeschrittenen Mitteln, mäßigem Aufwand, speziellen Fähigkeiten und mäßiger Motivation | | ||
| - | | 4 | Schutz vor absichtlichen Verstößen mit fortgeschrittenen Mitteln, erheblichem Aufwand, speziellen Fähigkeiten und hoher Motivation | | ||
| - | |||
| - | Risiko- und Bedrohungsanalysen sind ein wichtiger Bestandteil der 62443-Reihe. In der 62443-3-2 wird ein eigener Risikoanalyseprozess beschrieben, | ||
| - | Eine Sicherheitszone ist definiert als eine Gruppierung logischer oder physische Assets, die gemeinsame Sicherheitsanforderungen haben, basierend auf Faktoren wie Kritikalität und Folgen eines Angriffs. Die Schnittstellen zwischen de Sicherheitszonen werden „conduits“ genannt. | ||
| - | |||
| - | |||
| - | Abbildung 4: Sicherheitszonen mit „conduits“ einer Aufzugssteuerung mit Fernwartung | ||
| - | |||
| - | Quelle: SGS TÜV Saar | ||
| - | |||
| - | Als Risiko, die für Sicherheitszonen bestimmt wird, bezeichnet die 62443-Reihe dabei auch die Kombination aus Eintrittswahrscheinlichkeit und Auswirkung, wobei die Eintrittswahrscheinlichkeit noch weiter aufgeteilt wird in Bedrohung und Schwachstelle, | ||
| - | |||
| - | Risiko = Bedrohung x Schwachstelle x Auswirkung | ||
| - | |||
| - | |||
| - | Abbildung 4: Security Risiko Betrachtung | ||
| - | |||
| - | Quelle: SGS TÜV Saar CS3 - Security for Safety Schulung | ||
| - | |||
| - | Die bedeutet, ein Risiko kann nur bestehen, wenn neben einer Bedrohung (z.B. ein motivierter Angreifer), eine oder mehrere Schwachstellen vorhanden sind. | ||
| - | |||
| - | |||
| - | Abbildung 5: Motivationen und Fähigkeiten von unterschiedlichem Angreifer-Typen | ||
| - | |||
| - | Quelle: SGS TÜV Saar CS3 - Security for Safety Schulung | ||
| - | |||
| - | Daher müssen bei der Risiko-Betrachtung bzw. bei den Gegenmaßnahmen zur Verminderung des Risikos explizit mögliche Schwachstellen betrachtet werden. Zusätzlich können Maßnahmen zur Erkennung eines Angriffs (z.B. Intrusion-Detection) das Risiko senken. | ||
| - | |||
| - | In Abbildung 5 werden mögliche Security Bedrohungen nach der Microsoft Stride Methode aufgelistet. | ||
| - | Die IEC 62443-3-3 und IEC 62443-4-2 definieren eine Anzahl von Gegenmaßnahmen für diese Bedrohungen. Um so höher der Security Level ist, um so mehr Gegenmaßnahmen müssen implementiert werden. | ||
| - | |||
| - | |||
| - | Abbildung 6: Security Bedrohungen nach der STRIDE-Methode mit Assets | ||
| - | |||
| - | Quelle: SGS TÜV Saar CS3 - Security for Safety Schulung | ||
| - | |||
| - | https:// | ||
| - | |||
| - | Schwachstellen findet man in der CVE-Sicherheitslückendatenbank https:// | ||
| - | |||
| - | Die Bestimmung der Eintrittswahrscheinlichkeit ist nicht eindeutig qualitativ oder quantitativ erfassbar. Man greift hier auf Hilfsmittel zurück und schätzt diese ab. Hierzu müssen beispielsweise die Motivation des möglichen Angreifers, sein Fachwissen und seine verfügbaren Mittel abgeschätzt werden. Zudem werden die Verfügbarkeit von Systemkenntnissen, | ||
| - | |||
| - | |||
| - | Abbildung 5: Abschätzung der Eintrittswahrscheinlichkeit eines Angriffs | ||
| - | Quelle: SGS TÜV Saar CS3 - Security for Safety Schulung | ||
| - | |||
| - | In Abbildung 6 werden unterschiedliche mögliche Schäden aufgelistet. Der hauptsächliche Schaden wird von finanzieller Natur sein. Die IEC 62443 unterscheidet hier fünf verschiedene Schweregrade, | ||
| - | |||
| - | |||
| - | Abbildung 6: Unterschiedliche mögliche Schäden | ||
| - | |||
| - | Quelle: SGS TÜV Saar CS3 - Security for Safety Schulung | ||
| - | |||
| - | Aus dem Schadenindex und der Eintrittswahrscheinlichkeit kann ein Risiko berechnet werden. | ||
| - | |||
| - | |||
| - | Abbildung 7: Bestimmung des Security Risikos | ||
| - | |||
| - | Quelle: SGS TÜV Saar CS3 - Security for Safety Schulung | ||
| - | |||
| - | Innerhalb der Risikoanalyseprozesse der 62443-3-2 gibt es dabei auch einige Besonderheiten: | ||
| - | * Die Risikoanalyse wird in mehreren Zyklen durchgeführt. Zunächst wird mit einer initialen Risikobeurteilung begonnen, welches sich auf Worst-Case-Szenarien konzentriert und eine Grundlage der weiteren Einteilung des analysierten Systems („System under Consideration“ SUC) darstellt. | ||
| - | * Im Rahmen der zunächst festgestellten Bereiche werden dann detailliertere Risikobeurteilungen durchgeführt. Hierbei ist besonders ein Zwischenschritt bedeutsam, bei dem vorhandene Maßnahmen zur Reduzierung der Eintrittswahrscheinlichkeit nicht mit betrachtet werden. Das daraus folgende „ungeminderte“ Cybersicherheits-Risiko kann dann zur Festlegung eines Security Level-Ziels (SL-T, Security Level-Target) verwendet werden, welche bestimmte technische Mindestanforderungen nach sich zieht. | ||
| - | * Erst darauf werden Maßnahmen betrachtet bzw. weitere Maßnahmen im Rahmen der Risikobehandlung bestimmt. | ||
| - | * Für die Entwicklung von Geräten mit Security Level (SL) muss ein geeigneter Entwicklungsprozess nach IEC 62443-4-1 vorhanden sein. Die Implementierung des Prozesses wird ähnlich zu CMMI mit Reifegraden (maturity level) bewertet. Die IEC 62443 gibt aber keine Mindestreifegrad für einen vorgegeben Security-Level vor. | ||
| - | * Eine gute Ergänzung wäre eine Betrachtung der Kosten, für die Umsetzung von Gegenmaßnahmen. Eventuell kann man mit dem Risiko leben und eventuelle finanzielle Risiken in Kauf nehmen. Das gilt aber nicht für ein Safety-Risiken. | ||
| - | |||
| - | __Hinweis__: | ||
| - | |||
| - | **3) Checkliste nach NA 163** | ||
| - | |||
| - | In Anbetracht des relativ großen Arbeits- und Zeitaufwandes, | ||
| - | |||
| - | |||
| - | Abbildung: Struktur einer Risikobeurteilung mit den durch NA 163 vordefinierten Schritten (Kruschitz, 2017) | ||
| - | |||
| - | ===== 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, | 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. | 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 | + | 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, |
| - | 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 | + | 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, |
| - | 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, | + | |
| - | Quantifizierung des Risikos ändern würde. Eine gemeinsame Quantifizierung ist daher zum Teil unter Experten umstritten. Zunächst existiert keine Metrik, um von einem PL oder SIL aus der Safety auf einen notwendigen SL nach IEC 62443 zu schließen. Ferner existiert bislang keine Möglichkeit die Wahrscheinlichkeit eines Angriffs für bestimmte Tage vorherzusagen. Es ist lediglich bekannt, dass es nur eine Frage der Zeit ist, bis eine Sicherheitslücke ausgenutzt wird. Die sogenannten „Zero Day Exploits“ sind Sicherheitslücke, | + | |
| Für die Synthese der beiden Domänen wären die folgenden Fragestellungen relevant: | 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? | * 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? | * Wie lässt sich die Wirksamkeit von Security-Maßnahmen einheitlich bewerten? Gibt es quantitative Methoden zur Bewertung der Maßnahmen? | ||
| Zeile 344: | Zeile 256: | ||
| Es gibt auch Ansätze, die Software-Qualität statistisch zu erfassen. Siehe dazu “Software Reliability Engineering: | Es gibt auch Ansätze, die Software-Qualität statistisch zu erfassen. Siehe dazu “Software Reliability Engineering: | ||
| - | https:// | + | [[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. | + | 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, | + | 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, | + | 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. | 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. | ||
| Zeile 358: | Zeile 270: | ||
| 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, | 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:// | + | [[https:// |