Software in sicherheitsrelevanten Systemen Ralf Pinger / Stefan Gerken Sommersemester 2016

Software in sicherheitsrelevanten Systemen Sommersemester 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

Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page 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

Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page 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

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

Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page 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

Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page 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 I hochradioaktivem schweren Wasser aus dem Leck, das in den Brennstoffbehälter geschlagen worden war

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 Ralf Pinger / Stefan Gerken Page Fehlerpropagation – Störungen und Unfälle Bild: nach Sergio Montenegro

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

Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page 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.

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

Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page 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!

Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page 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

Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page 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

Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page 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?

Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page 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

Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page 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

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

Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page Quantifizierung – Qualitätsmodelle Qualitätsmodell nach ISO/IEC

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

Software in sicherheitsrelevanten Systemen Sommersemester Ralf Pinger / Stefan Gerken Page 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

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