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

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

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

2 Software in sicherheitsrelevanten Systemen Sommersemester 2016 03.06.2016 Ralf Pinger / Stefan Gerken Page 2 Kapitel 2 - SW und Systeme Inhaltsübersicht 1.Abgrenzungen 2.Vollständigkeit und Korrektheit 3.Toleranzen bei SW und HW und Auswirkungen auf die Entwicklung 4.Fehlerpropagation 5.Fehler und Ausfälle 6.Quantifizierung 1.zufällige Fehler 2.systematische Fehler 3.Qualität

3 Software in sicherheitsrelevanten Systemen Sommersemester 2016 03.06.2016 Ralf Pinger / Stefan Gerken Page 3 2.1 Abgrenzungen – Definition Definition Software Intellektuelle Schöpfung, die Programme, Verfahren, Regeln und alle dazugehörige Dokumentation umfasst, die zum Betrieb eines Systems gehören. englische Übersetzung intellectual creation comprising the programs, procedures, rules and any associated documentation pertaining to the operation of a system. Quelle: EN 50128

4 Software in sicherheitsrelevanten Systemen Sommersemester 2016 03.06.2016 Ralf Pinger / Stefan Gerken Page 4 2.2 Vollständigkeit und Korrektheit Vollständigkeit  Wurden alle Eingangswerte und ihre Parameter definiert?  Führen alle Verhaltensweisen der realen Welt zu gefährdungsfreien Reaktionen des implementierten Systems? Korrektheit  Tut das System genau das, was definiert wurde?  Führen alle implementierten Reaktionen des Systems zu einem gefährdungsfreien Verhalten der realen Welt? Folgerung: Korrektheit ist theoretisch nachweisbar, Vollständigkeit maximal plausibel

5 Software in sicherheitsrelevanten Systemen Sommersemester 2016 03.06.2016 Ralf Pinger / Stefan Gerken Page 5 2.3 Toleranzen Bild: nach Sergio Montenegro  "normaler" Funktionsbereich eines Systems ist ein schmales Band  Fehlerbereich ist der Rest

6 Software in sicherheitsrelevanten Systemen Sommersemester 2016 03.06.2016 Ralf Pinger / Stefan Gerken Page 6 2.3 Toleranzen – HW und SW Auswirkungen bei  Hardware  Sind analoger Natur (sie „zerbricht“ nicht unmittelbar)  Führen im Allgemeinen nicht sofort zu einem Ausfall des Teils  Führen nicht zwangsläufig zu einem Bruch  Software  Ist digital (Werte sind sofort unplausibel, Wertebereiche laufen über, …)  Führen im Normalfall sofort zu einem undefinierten Zustand  Regenerieren sich im Normalfall nicht

7 Software in sicherheitsrelevanten Systemen Sommersemester 2016 03.06.2016 Ralf Pinger / Stefan Gerken Page 7 2.3 Toleranzen – Beispiel SW-Fehler Kincardine in Ontario, Kanada, Schwerer Reaktorunfall 1990 Beim Austausch eines abgebrannten Brennelementes geriet die computergesteuerte Umlademaschine in einen unkontrollierten Zustand. Als sie sich 40 cm über dem Schachtdeckel befand, wurden durch einen falschen Befehl im Code des Computers, der die Umlademaschine kontrollierte, zugleich alle 4 Bremsen des Hebezuges gelöst und das schwere Gerät fiel auf die Schachtabdeckung. Die Folge war der Austritt von 12.000 I hochradioaktivem schweren Wasser aus dem Leck, das in den Brennstoffbehälter geschlagen worden war

8 Software in sicherheitsrelevanten Systemen Sommersemester 2016 Ablauf:  Störung oder Fehler liegen vor  Störung wird wirksam  Störung pflanzt sich fort  Störung führt zu einem Unfall 03.06.2016 Ralf Pinger / Stefan Gerken Page 8 2.4 Fehlerpropagation – Störungen und Unfälle Bild: nach Sergio Montenegro

9 Software in sicherheitsrelevanten Systemen Sommersemester 2016 03.06.2016 Ralf Pinger / Stefan Gerken Page 9 2.4 Fehlerpropagation – Hierarchisch Bild: nach Sergio Montenegro Fehler pflanzen sich in der funktionalen Programmhierarchie fort, da einzelne Module sich undefiniert verhalten

10 Software in sicherheitsrelevanten Systemen Sommersemester 2016 03.06.2016 Ralf Pinger / Stefan Gerken Page 10 2.4 Fehlerpropagation – Datenfluss Bild: nach Sergio Montenegro Fehler pflanzen sich zeitlich im Datenfluss fort, da einzelne Module sich undefiniert verhalten und reaktive Systeme im Regelfall nicht gedächtnislos sind.

11 Software in sicherheitsrelevanten Systemen Sommersemester 2016 03.06.2016 Ralf Pinger / Stefan Gerken Page 11 2.4 Fehlerpropagation – Fehlerauswirkungen Bild: nach Sergio Montenegro

12 Software in sicherheitsrelevanten Systemen Sommersemester 2016 03.06.2016 Ralf Pinger / Stefan Gerken Page 12 2.5 Fehler und Ausfälle Fehler ist die Abweichung von einem erwarteten Sollwert  Fehler kann unterschiedliche Ursachen haben  Menschliche (z. B. Fehlbedienungen)  Systematische (z. B. Programmierfehler, falsche Anforderungen)  Zufällige Ursachen (z. B. Übertragungsfehler)  Physikalische (z. B. Messfehler) Ausfall ist das Versagen einer technischen Funktion  Ausfall bezieht sich auf physikalische Objekte  Ausfall ist in der Regel stochastisch  Nur ein unerwarteter Ausfall kann zu einem Fehler führen Ausfall und Fehler hängen zusammen, sind aber nicht identisch!

13 Software in sicherheitsrelevanten Systemen Sommersemester 2016 03.06.2016 Ralf Pinger / Stefan Gerken Page 13 2.6 Quantifizierung Zweck:  ist nichts anderes als die Angabe von irgendetwas als Zahlenwert  zum Zweck der Vergleichbarkeit  erzeugt das Gefühl einer objektiven Bewertung Problem:  Vergleichbarkeit  Objektivität

14 Software in sicherheitsrelevanten Systemen Sommersemester 2016 03.06.2016 Ralf Pinger / Stefan Gerken Page 14 2.6.1 Quantifizierung – zufällige Fehler Voraussetzung: Stochastisches Fehlermodell  Softwarefehler besitzen (hoffentlich) deterministisches Fehlermodell  Ausfall  Stochastisches Modell über die Zeit → Ausfallrate ≡ Ausfälle des Elements pro Stunde  Stochastisches Modell über die Nutzungsfälle → Ausfallwahrscheinlichkeit ≡ Ausfälle pro Nutzung des Elements  Betrifft sowohl Verfügbarkeit als auch Sicherheit

15 Software in sicherheitsrelevanten Systemen Sommersemester 2016 03.06.2016 Ralf Pinger / Stefan Gerken Page 15 2.6.2 Quantifizierung – systematische Fehler Mögliche Quantifizierung:  Z. B. Gefundene Fehler pro LOC Prognose von systematischen Fehlern  Systematische Fehler treten bei gleichen Eingangsbedingungen reproduzierbar immer wieder auf  Zufälligkeit der Eingangsbedingungen sind nicht notwendigerweise gegeben  Warum einen Fehler nicht beheben, wenn er bekannt ist?  Woher weiß man, wie die Restfehler verteilt sein werden?

16 Software in sicherheitsrelevanten Systemen Sommersemester 2016 03.06.2016 Ralf Pinger / Stefan Gerken Page 16 2.6.2 Quantifizierung – korrekt, robust und vollständig Korrektheit ist ein Synonym für Fehlerfreiheit, das heißt:  Korrektheit ist digital  Korrektheit einer Realisierung ist bezogen auf deren Spezifikation  Eine fehlende Spezifikation impliziert Korrektheit Vollständigkeit ist  verallgemeinert, wenn alles für eine Problemlösung erforderte realisiert wurde (Normalbetrieb und Fehlerfälle)  bezogen auf Software die Umsetzung aller Anforderungen der Spezifikation  bezogen auf ein Problem die Spezifikation aller Aspekte eines Problems Robustheit ist  unter unerwarteten Situationen sinnvoll zu reagieren  nicht digital  nicht proportional zur Korrektheit

17 Software in sicherheitsrelevanten Systemen Sommersemester 2016 03.06.2016 Ralf Pinger / Stefan Gerken Page 17 2.6.3 Quantifizierung – Qualität Qualität - Lat.: qualitas – Beschaffenheit  Die Gesamtheit von Merkmalen (und Merkmalswerten) einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen. [Deutsche Gesellschaft für Qualität] Qualitätsmodelle  Softwarequalität selbst ist in der Praxis nicht direkt anwendbar.  weitere Detaillierung und Konkretisierung durch Qualitätsmodelle  Ableitung von Unterbegriffen

18 Software in sicherheitsrelevanten Systemen Sommersemester 2016 03.06.2016 Ralf Pinger / Stefan Gerken Page 18 2.6.3 Quantifizierung – Qualitätsmodelle Qualitätsmodell nach Balzert

19 Software in sicherheitsrelevanten Systemen Sommersemester 2016 03.06.2016 Ralf Pinger / Stefan Gerken Page 19 2.6.3 Quantifizierung – Qualitätsmodelle Qualitätsmodell nach ISO/IEC 9126-1

20 Software in sicherheitsrelevanten Systemen Sommersemester 2016 03.06.2016 Ralf Pinger / Stefan Gerken Page 20 2.6.3 Quantifizierung – Qualitätsmodelle Qualitätsmodell GQM nach Basili, Rombach

21 Software in sicherheitsrelevanten Systemen Sommersemester 2016 03.06.2016 Ralf Pinger / Stefan Gerken Page 21 2.6.3 Quantifizierung – Metriken Beispiele:  McCabes zyklomatische Zahl  Eindeutig definiert  Reproduzierbar  Nur auf Kontrollflussgraphen anwendbar  Lines of Code (LOC)  Unklarheit bezüglich Leerzeilen und Kommentarzeilen  Function Points  Basiert auf individuellen Einschätzungen  Prinzipbedingt nur sehr eingeschränkt reproduzierbar

22 Software in sicherheitsrelevanten Systemen Sommersemester 2016 03.06.2016 Ralf Pinger / Stefan Gerken Page 22 2.6.3 Quantifizierung – Qualität Bild: Axel Zechner Qualitätsanforderungen Qualitätsmodell Architekturmodell Designmodell