5 Teil 5: V-Modell-Referenz Produkte
5.3 Produkte
5.3.7 Anforderungen und Analysen
5.3.7.10 Sicherheitsanalyse
Vorgehensbaustein: Sicherheit (AN)
Verantwortlich: Funktionssicherheitsbeauftragter (bei Verwendung des Vorgehensbausteins Sicherheit (AN))
Aktivität: Sicherheitsanalyse durchführen und bewerten
Mitwirkend: QS-Verantwortlicher
Sinn und Zweck
Ziel der Sicherheitsanalyse (häufig auch Risikoanalyse genannt) ist die Ermittlung der Ursachen von Gefährdungen, sowie die Abschätzung der Wahrscheinlichkeit für den Eintritt dieser Gefährdung bzgl. der Funktionssicherheit.
Die Risiken (Eintrittswahrscheinlichkeit mal Schadenshöhe je Gefährdung) werden ermittelt und Maßnahmen zur Risikominderung der Gefährdungen ausgewählt. Die Auswahl ist zu begründen.
Die Sicherheitsanalyse ist für jedes als sicherheitskritisch eingestufte Systemelement durchzuführen.
Wird erzeugt von
Projekthandbuch, Gesamtsystemspezifikation (Pflichtenheft) (siehe Produktabhängigkeit 4.27)
Implementierungs-, Integrations- und Prüfkonzept SW, SW-Architektur (siehe Produktabhängigkeit 4.18)
HW-Architektur, Implementierungs-, Integrations- und Prüfkonzept HW (siehe Produktabhängigkeit 4.7)
Implementierungs-, Integrations- und Prüfkonzept SW, SW-Architektur (siehe Produktabhängigkeit 4.19)
Implementierungs-, Integrations- und Prüfkonzept SW, SW-Architektur (siehe Produktabhängigkeit 4.17)
HW-Architektur, Implementierungs-, Integrations- und Prüfkonzept HW (siehe Produktabhängigkeit 4.8)
HW-Architektur, Implementierungs-, Integrations- und Prüfkonzept HW (siehe Produktabhängigkeit 4.6)
Implementierungs-, Integrations- und Prüfkonzept System, Unterstützungs-Systemarchitektur (siehe Produktabhängigkeit 4.16)
Implementierungs-, Integrations- und Prüfkonzept Unterstützungssystem, Unterstützungs-Systemarchitektur (siehe Produktabhängigkeit 4.24)
Implementierungs-, Integrations- und Prüfkonzept Unterstützungssystem, Unterstützungs-Systemarchitektur (siehe Produktabhängigkeit 4.5)
Implementierungs-, Integrations- und Prüfkonzept Unterstützungssystem, Unterstützungs-Systemarchitektur (siehe Produktabhängigkeit 4.21)
Implementierungs-, Integrations- und Prüfkonzept System, Systemarchitektur (siehe Produktabhängigkeit 4.15)
Implementierungs-, Integrations- und Prüfkonzept System, Systemarchitektur (siehe Produktabhängigkeit 4.23)
Implementierungs-, Integrations- und Prüfkonzept System, Systemarchitektur (siehe Produktabhängigkeit 4.4)
Implementierungs-, Integrations- und Prüfkonzept System, Systemarchitektur (siehe Produktabhängigkeit 4.20)
Gesamtsystemspezifikation (Pflichtenheft) (siehe Produktabhängigkeit 4.25)
Gesamtsystemspezifikation (Pflichtenheft) (siehe Produktabhängigkeit 4.26)
Hängt inhaltlich ab von
Projekthandbuch, Datenschutzkonzept, Informationssicherheitskonzept (siehe Produktabhängigkeit 5.46)
5.3.7.10.1 Gefährdungsidentifikation und Schadensklassifikation
Die »Gefährdungsidentifikation und Schadensklassifikation beschreibt Gefährdungen, die möglicherweise beim Einsatz des zu untersuchenden Systems zu Schadensereignissen führen. Für jede Gefährdung wird die potenzielle Schadenshöhe je Schadenskategorie angegeben. Für jede identifizierte Gefährdung wird die zugeordnete Schadensklasse je Schadenskategorie angegeben.
Schadensereignisse können je nach Systemart unterschiedliche Schadenskategorien wie Tod, Verletzungen, Krankheit, den Verlust oder Beschädigungen von Gerätschaften, Eigentum und/oder Umweltschäden zur Folge haben. Es kann sich aber auch um einen reinen Vermögensschaden z.B. durch Produktionsausfall oder Nichtverfügbarkeit eines dringend benötigten Systems handeln.
Ebenso können immaterielle Schäden verursacht werden, wie z.B. bei Verstößen gegen gesetzliche Vorgaben/Auflagen, Imageschäden als Verkaufshindernisse oder Auslöser von Rückrufaktionen. Jedes Schadensereignis, das durch eine Gefährdung eintreten kann, hat unterschiedlich schwere Folgen. Um diese leichter handhaben zu können, werden die Schadensereignisse zweckmäßigerweise in Schadensklassen eingeteilt.
5.3.7.10.2 Folgenanalyse und Relevanzeinstufung
Für jede Gefährdung, die in der Gefährdungsidentifikation erkannt wurde, werden folgende Ergebnisse zusammengestellt:
- Ursachen der Gefährdung,
- Eintrittswahrscheinlichkeit der Gefährdung,
- Ermittlung des Risikos (Eintrittswahrscheinlichkeit des Schadens mal Schadenshöhe)
- Feststellung, ob das ermittelte Risiko im Rahmen des vom Auftraggeber akzeptierten Risikos liegt. Ist das Risiko über dem Akzeptanzwert, sind im nächsten Schritt risikomindernde Maßnahmen auszuwählen.
Die Eintrittswahrscheinlichkeit bei der Gefährdung "Ausfall einer Komponente" kann auf der Basis der Lebensdauer eines Systemteils oder der Betriebsstunden angegeben werden.
5.3.7.10.3 Sicherheitsmaßnahmen
Für alle in der Sicherheitsanalyse als nicht akzeptabel bewerteten Risiken werden Maßnahmen zur Risikominderung ermittelt. Die Vorschläge risikomindernden Maßnahmen findet sich im Projekthandbuch im Thema »Organisation und Vorgaben zur Sicherheit.
Die Notwendigkeit der Maßnahmen ergibt sich aus dem Auftreten einer Gefährdung, die außerhalb des vorgegebenen Toleranzbereichs beziehungsweise jenseits des Schwellenwertes liegt und somit nicht akzeptiert wird. Deshalb ist es erforderlich, geeignete Maßnahmen zu ermitteln und zu prüfen, ob durch die Durchführung dieser Maßnahme(n) das vorliegende Risiko derart gemindert wird, dass es akzeptiert werden kann.
»Sicherheitsmaßnahmen können aus konstruktiven Verfahren (in Hinblick auf Systementwicklung und Realisierung), analytischen Maßnahmen (Prüfmaßnahmen), zusätzlichen funktionalen oder nicht-funktionalen Anforderungen an das System sowie zusätzlichen Sicherheitseinrichtungen oder organisatorischen Auflagen bestehen.
Risikominderungsmaßnahmen sollen die Schadenshöhe (Schadensklasse) und/oder die Eintrittswahrscheinlichkeit einer Gefährdung mindern.
Die Auswirkungen der Maßnahmen, wie Grad der Minderung, Aufwand der Umsetzung, Auswirkungen auf Inbetriebnahme, Betrieb, Stilllegung oder Bedienpersonal, werden hinsichtlich ihrer technischen und wirtschaftlichen Eignung bewertet.
Die Entscheidung für die Auswahl der geeignetsten Maßnahmen wird begründet.
Sollte keine geeignete Maßnahme gefunden werden, so ist nach den Vorgaben zur Sicherheit im Projekthandbuch zu verfahren. Es muss zusammen mit dem Auftraggeber eine Lösung gesucht werden und diese muss durch einen Problemmeldungs-/Änderungsantrag eingebracht und der Lösungsweg dokumentiert werden.