Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Software in sicherheitsrelevanten Systemen Ralf Pinger / Stefan Gerken Sommersemester 2013.

Ähnliche Präsentationen


Präsentation zum Thema: "Software in sicherheitsrelevanten Systemen Ralf Pinger / Stefan Gerken Sommersemester 2013."—  Präsentation transkript:

1 Software in sicherheitsrelevanten Systemen Ralf Pinger / Stefan Gerken Sommersemester 2013

2 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page 2 Kapitel 4 - konstruktive Grundprinzipien der Sicherheit Inhaltsübersicht 1.Mehrkanaligkeit 2.Diversität 3.Voting 4.Sicherer Zustand 5.Fallback-Mechanismen, Redundanz 6.Umsetzung 7.Zusammenfassung

3 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Mehrkanaligkeit – Prinzip Grundprinzip: Jede Funktion wird mehrfach realisiert und ausgeführt Die Ausführungen sind paarweise rückwirkungsfrei Folgerung: Fehler werden erkannt Fehler werden offenbart Fehler werden beherrscht

4 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Mehrkanaligkeit – Unterscheidung unabhängige Wirkmechanismen: Physikalisch Logisch Algorithmen Vorgehen unabhängige Ausführungspfade: Ausfälle wirken nur in einem Kanal

5 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Diversität – Grundpinzip Prinzip Eine Aufgabe wird auf unterschiedliche Art und Weise mehrfach realisiert Spezialfall der Mehrkanaligkeit Beispiele Geschwindigkeitsermittlung über Tacho und Radar Prozess: SW-Entwicklung und SW-Test Coded Mono Processor

6 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Diversität – Probleme Probleme Bei festem Budget für Entwicklung einer Funktion bleibt für jede Variante ein entsprechend kleinerer Bruchteil (für alle Phasen der Entwicklung) Gleiche Ausbildung erzeugt gleiche Weltbilder und damit ähnliche Fehler; damit ist die Annahme der Unabhängigkeit systematischer Fehler nicht gegeben Fehlerhafte Voraussetzungen werden auch hier nicht offenbart Wissenschaftliche Untersuchungen Nancy Leveson et al. In IEEE Transactions on Software Engineering: 1986: An Experimental Evaluation of the Assumption of Independence in Multiversion Programming 1990: The Use of SelfChecks and Voting in Software Error Detection: An Empirical Study 1991: An Empirical Comparison of Software Fault Tolerance and Fault Elimination

7 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Voting Voting: Mehrkanaligkeit erzeugt immer mehrere Ergebnisse Es muss das richtige Ergebnis auf den gesteuerten Prozess wirken Annahme: Ein Fehler wirkt sich nur in einem Kanal aus Folgerung: Ein abweichender Kanal muss abgeschaltet werden

8 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Voting Problem: Hat die Hardware physische (zufällige) Fehler? Welcher Kanal ist defekt? Lösung: Man nimmt mehrere Kanäle Man versucht, einen Mehrheitsentscheid zu erwirken Wenn das nicht möglich ist, nimmt man einen sicheren Zustand ein

9 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Sicherer Zustand Ein Zustand, von dem keine Gefährdung mehr ausgeht Bei der Bahn im Regelfall der energielose Zustand (Stillstand) Im Flugzeug ein Zustand, der ein sicheres Landen erlaubt Auch der energielose Zustand ist nicht immer sicher

10 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Fallback-Mechanismen, Redundanz Rückfallebenen sind erforderlich, wenn es keinen sicheren Zustand gibt ein Stillstand des Betriebs zu teuer ist eine Bergung des ausgefallenen Gerätes nicht oder nur schwer möglich ist Rückfallebenen ermöglichen daher, für eine gewisse Zeit weiterhin Betrieb zu machen ohne die Sicherheit übermäßig zu verschlechtern

11 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Fallback-Mechanismen, Redundanz Redundanz: zusätzlicher Kanal, der im Regelbetrieb nicht benötigt wird. Verwendung nur im Fehlerfall Arten von Redundanz: Hot Standby: redundanter Kanal läuft immer mit, Umschaltung kann direkt erfolgen. Cold Standby: redundanter Kanal läuft nicht mit, Hochfahren des Systems nach Umschaltung notwendig

12 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Umsetzung In der Literatur gibt es unterschiedliche Bezeichnungen Definition: N-out-of-M oder N-von-M (z. B. 2oo2 oder 2v2) 1.N der M Kanäle müssen funktionstüchtig sein und dasselbe Ergebnis errechnen 2.Das Ergebnis der N gleichen Kanäle wird zur Weiterverarbeitung verwendet

13 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Umsetzung – 1oo2, Redundanz

14 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Umsetzung – Eigenschaften von 1oo2 Erhöhung der Zuverlässigkeit und Verfügbarkeit des Gesamtsystems Doppelte Hardwarekosten Common Cause: Gemeinsame Stromversorgung, etc. ?

15 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Umsetzung – 2oo2, Sicherheit

16 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Umsetzung – Voter

17 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Umsetzung – Eigenschaften von 2oo2 Erkennung von Hardware-Fehlern durch Voter möglich Bei Abweichung: sicherer Zustand Doppelte Hardwarekosten Common Cause: Gemeinsame Stromversorgung, etc. ? Zuverlässigkeit und Verfügbarkeit geringer als bei einem Kanal, da beide Kanäle zwingend benötigt werden.

18 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Umsetzung – 1oo1D, Sicherheit

19 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Umsetzung – Eigenschaften von 1oo1D 1D steht für 1 Kanal + Diagnose-Kanal, in diesem Sinne eigentlich auch 2 Diagnosekomponente führt eine Selbstprüfung durch Falls ein Fehler erkannt wird, erfolgt die Ausführung einer Sicherheitsfunktion (z. B. Abschalten, eingeschränkte Funktion) Fehlerhafte Ausgaben werden nicht sofort unwirksam (Diagnose muss erst arbeiten!) Gemeinsame Hardware für Haupt- und Prüfprogramm: Was passiert wenn beide gleichermaßen versagen (Common Cause) Überprüfung kann auch auf Ausgabebaugruppen verlagert werden Geringe Kosten für zusätzlich Hardware, falls D einfach aufgebaut werden kann

20 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Umsetzung – 2 mal 2oo2, Sicherheit und Redundanz

21 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Umsetzung – Eigenschaften von 2 x 2oo2 Redundanz als hot oder cold möglich Erhöhung der Zuverlässigkeit und Verfügbarkeit des Gesamtsystems Vierfache Hardwarekosten plus Umschaltungen Common Cause: Gemeinsame Stromversorgung, Sensorik, Aktorik etc. ?

22 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Umsetzung – 2 x 1oo1D, Sicherheit und Redundanz

23 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Umsetzung – Eigenschaften von 2 x 1oo1D Alternative Darstellung mit 1oo1D Hier als Hot-Standby-System mit Muxer realisiert. Dieser Muxer schaltet nur durch Sicherheit steckt in den einzelnen 1oo1D-Kanälen. Realisierungsvarianten hängen Architektur, Kosten, Nutzen, Einsatzzweck usw. ab

24 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Umsetzung – 2oo3

25 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Umsetzung – 2oo3-Voter

26 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Umsetzung – Eigenschaften von 2oo3 Verdreifachung der HW Fehlerhafter Kanal kann erkannt werden Weiterarbeiten nach erstem Fehler möglich Synchronisation noch schwieriger

27 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Zusammenfassung - Umsetzungen genannten Prinzipien sind nur Beispiele und können beliebig erweitert bzw. verändert werden Notwendigkeit der einzusetzenden Architektur sollte aus einer Risiko-Analyse abgeleitet werden Vollständige Zweikanaligkeit verringert common cause Ausfälle Hohes Maß an Ausfalloffenbarung durch Zwei- bzw. Mehrkanaligkeit möglich Durch HW-Vergleicher extrem schnelle Ausfalloffenbarung möglich Unabhängiges Abschalten durch Vergleicher möglich Natürlich können auch die Übertragungsmedien mehrkanalig ausgelegt werden!

28 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Zusammenfassung - Allgemeines Probleme: Enge Synchronisation und dichte Nachbarschaft der Kanäle machen das System empfindlich für common cause Einflüsse: Einflüsse über die Peripherie Einflüsse über die Stromversorgung Elektromagnetische Felder Temperatur (von außen, aber auch durch Nachbarkanal) Gegenmaßnahmen Sichere Trennung der Peripherie vom Rechnerkern Hoch überwachte Stromversorgung Hochwirksame Schirmung

29 Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Zusammenfassung - Allgemeines Mehrkanaligkeit kann eingesetzt werden für: Redundanz: Weiterarbeiten nach Ausfall von Kanälen Sicherheit: Erkennung von physischen Fehlern der Hardware Sicherheit und Redundanz Architekturen müssen die Ziele sicherstellen in Bezug auf R: Zuverlässigkeit A: Verfügbarkeit M: Wartbarkeit S: Sicherheit


Herunterladen ppt "Software in sicherheitsrelevanten Systemen Ralf Pinger / Stefan Gerken Sommersemester 2013."

Ähnliche Präsentationen


Google-Anzeigen