3. Prozesse
Hierbei müssen Unternehmen und Mitarbeiter in Prozessen denken. Darum geht es u.a. im IEC62304 für Software in medizinischen Geräten. Ohne klar definierte Prozesse lässt sich nicht nachweisen, dass ein System seine Sicherheitsanforderungen erfüllt. Prozesse gelten hierbei als messbarer Vertreter für etwas, das weitgehend unmessbar ist. So ist relativ einfach überprüfbar, ob ein Prozess eingehalten wurde. Hingegen die Qualität des Designs und des Quellcodes zu beurteilen, erweist sich als deutlich schwerer. Sauber definierte Prozesse garantieren zwar kein gutes Produkt, aber unklare Prozesse führen selten zu einem hochwertigen Produkt. Prozesse bilden daher den Rahmen für die Bestimmung von Entwicklungsparametern, z.B. erlaubt ein klarer Testprozess statistische Aussagen über die Testabdeckung. Zugleich bilden Pozesse eine Struktur, die die Beweisführungskette für den Sicherheitsnachweis aufzeigt. Ohne Prozesse müssten kostenintensive Nachweise für die Sicherheit gegebenfalls nachträglich generiert werden. Sinnvollerweise sollten Entwickler daher Prozesse definieren, die während des gesamten Projektzyklus bereits hilfreiche Nachweisdokumente generieren.
4. Explizite Aussagen
Aussagen zur Sicherheit müssen die Verlässlichkeit explizit definieren. Ebenso sind die Bedingungen, unter denen diese Aussagen gelten, explizit auszudrücken. Die FDA sagt z.B. bezüglich medizinischer Geräte, dass „Prozessdaten, die zeigen, dass Design und Produktionsabläufe solide sind“, alleine nicht nachweisen können, dass eine Software sicher ist und dass zusätzlich „Nachweismethoden erforderlich sind, die sich auf die produktspezifische Gerätesicherheit fokussieren“. Die Verlässlichkeit eines Systems beschreibt die Fähigkeit, so lange wie nötig innerhalb einer bestimmten Zeitspanne korrekt auf Ereignisse zu reagieren. Es ist somit eine Kombination aus Verfügbarkeit – als zeitlicher Begriff – und Zuverlässigkeit – Korrektheit der Reaktionen. Im Kern jedes Sicherheitsnachweises stehen Aussagen wie „Dieses System wird seine Aufgabe A mit einer Verlässlichkeit von B erfüllen, so lange die Bedingungen C gegeben sind. Falls A nicht erledigt werden kann, wird das System in seinen Design Safe State gehen, die Wahrscheinlichkeit dafür ist P“. Die Bedingungen, unter denen die Aussagen zur Verlässlichkeit gelten, sind ebenso wichtig. Beispielsweise soll eine Flugsteuerung die Anforderungen nach IEC61508 für 20 Stunden Dauerbetrieb erfüllen. Danach wird sie zurückgesetzt. Wird sie nur in Flugzeugen eingesetzt, die nie über 20 Stunden in Betrieb sind, ist diese zeitliche Limitierung irrelevant. Entwickler sollten nun also an einer Steigerung der Verlässlichkeit für diese 20 Stunden, anstatt an einer Verlängerung der möglichen Betriebsstunden arbeiten.
5. Systemausfälle
Da sich Fehler nie ganz verhindern lassen, muss ein sicher laufendes System sie erkennen und abfangen können oder sich in einen sicheren Zustand versetzen. Hierzu existieren Definitionen von Fehler, Störung und Ausfall: Bei einem Fehler handelt es sich um Programmcode, der zu unerwünschtem Verhalten führen kann. Dies führt zu einer Störung. Ein Ausfall bzw. ein Systemversagen entsteht aufgrund einer nicht abgefangenen oder korrigierten Störung. EN50128 für Railway-Applikation beschreibt, was Entwickler sicherheitskritischer Systeme leidvoll lernen mussten: „Bei einem komplexen Software-System ist es unmöglich zu beweisen, dass es völlig fehlerfrei ist“. Man kann lediglich „Nachweise erbringen, welche glaubhaft machen, dass das System so verlässlich ist wie behauptet“. Ein sicheres System muss also mehrere Verteidigungslinien enthalten: – Isolierung von sicherheitskritischen Prozessen: Sicherheitskritische Komponenten dürfen nicht von anderen Komponenten beeinflusst werden können. – Systemstörungen verhindern: Das Systemdesign muss vorsehen, dass Fehler abgefangen werden können, ehe sie zu Störungen im Betrieb führen. – Eine Störung darf keinen Ausfall verursachen: Replikation und Diversifikation sind für Software vielleicht weniger geeignet als für Hardware, aber dennoch sind sie, richtig eingesetzt, sinnvoll. – Erkennung und Wiederherstellung nach Ausfällen: Bei vielen Systemen ist es ausreichend, in einen als sicher definierten Zustand zu gehen, die Wiederherstellung obliegt dann einer höheren Systemebene (z.B. dem Anwender). Bei anderen Systemen ist das nicht praktikabel, hier müssen Recovery-Mechanismen greifen. Bei ungünstigen Rahmenbedingungen kann ein Crash mit schnellem Neustart jedoch sicherer sein.
