Einführung in die Softwaretechnik für sichere und verlässliche Software

Transkript

1 Institut für Informatik Arbeitsgruppe Softwaretechnik Warburger Str Paderborn Einführung in die Softwaretechnik für sichere und verlässliche Software Ausarbeitung im Rahmen des Seminars ANALYSE, ENTWURF UND IMPLEMENTIERUNG ZUVERLÄSSIGER SOFTWARE von Matthias Albert Schwarz Kastanienallee Velbert betreut durch Dr. Holger Giese Paderborn, Februar 2004

2 ii

3 i Inhaltsverzeichnis 1 Einleitung Beispiel: A330 Testflug Unglück, Juni Sicherheit Sicherheit und sicherheitskritische Systeme Der Einflussbereich des Sicherheitsaspekts Einfluss auf den Systemlebenszyklus Gesellschaftliche Probleme Konfliktäre Aspekt Verwandte Bereiche Sicherheitskritische Computersysteme Aufbau sicherheitskritischer Computersysteme Vor- und Nachteile von Computersystemen Fehlerarten Entwurf sicherheitskritischer Software Qualitätsmanagement Ein Vorgehensmodell Gefahrenanalyse Risikoanalyse Spezifikation Verifikation & Validierung Zertifizierung Zusammenfassung A Literaturverzeichnis iii

4 iv

5 1 Einleitung Seit dem kommerziellen Durchbruch von Computersystemen Mitte der siebziger Jahre ist die Anzahl der weltweit im Einsatz befindlichen Computer drastisch angestiegen. Der Überwiegende Teil dieser Rechner wird jedoch nicht, wie zunächst annehmen könnte, in Desktop- oder Serversystemen verwendet, sondern größtenteils in so genannten eingebetteten Systemen. Im Gegensatz zu»gewöhnlichen«computern, die zur Verrichtung der unterschiedlichsten Aufgaben konzipiert und eingesetzt werden, werden eingebettete Systeme als Teil eines größeren Gesamtsystems, für die Verrichtung einer konkreten Aufgabe, innerhalb dieses Systems entwickelt. Mittlerweile werden circa 98% der produzierten Mikroprozessoren in genau solchen Systemen verwendet [ERCIM03]. Durch ihre vielseitigen Einsatzmöglichkeiten bestimmen eingebettete Systeme, teilweise unbemerkt, immer mehr unser alltägliches Leben. So reicht ihr Einsatzgebiet von einfachen Haushaltsgeräten, wie Kühlschränken und Waschmaschinen, bis hin zu hoch komplexen Steuerungssystemen, wie in ABS und ESP Systemen moderner Automobile, oder in Fly-By-Wire Systemen von Flugzeugen. So unterscheiden sich eingebettete Systeme von anderen Computern unter anderem durch die Tatsache, dass sich ihr Verhalten direkt auf ihre Umwelt auswirken kann. Der Absturz einer Textverarbeitungssoftware kann beispielsweise im Einzelfall hingenommen werden, während die Konsequenzen, eines Ausfalls eines Fly-By-Wire Systems unter keinen Umständen toleriert werden können. Es steht somit außer Frage, dass sowohl Hard- als auch Software, die in solch kritischen Anwendungen eingesetzt werden, erhöhten Sicherheitsanforderungen gerecht werden müssen. Im Rahmen dieser Arbeit werden, nach einem einleitenden Beispiel, die verschiedenen Problembereiche, welche beim Entwurf und Einsatz sicherheitskritischer Systeme entstehen, im Allgemeinen betrachtet, bevor daraufhin näher auf die konkrete Rolle von Computern in solchen Systemen eingegangen wird. Dabei wird gleichzeitig eine Einführung in die grundlegende Terminologie der einzelnen Bereiche gegeben. Abschließend wird dann anhand eines Vorgehensmodells ein Überblick über den Entwicklungsprozess sicherheitskritischer Systeme gegeben. Dabei wird der Schwerpunkt auf die so genannte Gefahrenund Risikoanalyse gelegt, welche eine zentrale Rolle in deren Entwicklungsprozess spielen. Viele der im Rahmen dieses Abschnitts vorgestellten Methoden und Techniken, lassen sich dabei sowohl auf die Entwicklung von Hardware als auch von Software anwenden. 1

6 1.1 Beispiel: A330 Testflug Unglück, Juni 1994 Am 30. Juni 1994 kam es zum Absturz eines Airbus A330 auf dem Flughafengelände des Blagnac Flughafens in Toulouse. Wie spätere Untersuchungen ergaben, ließ sich das Unglück, bei dem alle vier Insassen des Flugzeugs ums Leben kamen, auf einen Fehler in der Software des Autopiloten zurückführen. Im Rahmen des besagten Testflugs sollte ein neues Modul namens SRS (speed refernece system) getestet werden, welches der Kontrolle und Steuerung von Anstiegswinkel und Geschwindigkeit des Flugzeugs im Falle eines Triebwerkausfalls diente. Konkret sollte während des Tests ein Durchstarten der Maschine, mit plötzlichem Triebwerksausfall durchgeführt werden. Unmittelbar nach dem Durchstarten aktivierte der Pilot den Autopiloten, regelte die Leistung des linken Triebwerks herunter und trennte die entsprechende Hydraulikpumpe ab, um einen Ausfall zu simulieren. Wie geplant wurde das SRS Modul aktiv und passte den Anstiegswinkel des Flugzeuges der verringerten Schubkraft an. Als dieser das Limit von 25 erreichte, wechselte der Autopilot auf Grund der geringen Flughöhe den Modus und aktivierte ein anderes Modul namens ALT-STAR. Dieses Modul, welches für eine schnelle Gewinnung an Flughöhe zuständig war, war jedoch nicht für den Flug mit nur einer Turbine ausgelegt. Der Autopilot agierte daher, ohne die verringerte Schubkraft der Maschine zu berücksichtigen, und erhöhte den Anstiegswinkel drastisch. Dies führte zu einem raschen Geschwindigkeitsverlust des Flugzeugs und brachte es zusätzlich in eine Schräglage. Letztendlich verlor die Maschine den Auftrieb und stürzte ab. Das hier beschriebene Beispiel macht eines von vielen Problemen beim Entwurf sicherheitskritischer Systeme deutlich. In diesem speziellen Fall führte die hohe Komplexität des Gesamtsystems dazu, dass bei der Konzeption offensichtlich nicht alle Eventualitäten berücksichtigt wurden. So kam es dazu, dass erst die Kombination zweier (nach ihrer Spezifikation) korrekt funktionierender Systemmodule zu einem kritischen Systemfehler führte. Weiterhin wird deutlich, dass die Entwicklungsmethoden für solche Systeme extrem hohen Anforderungen gerecht werden müssen, um sicherzustellen, dass Nebeneffekte, wie in diesem Beispiel bereits beim Entwurf erkannt und beseitigt werden können. Die Tatsache, dass die Entwicklung in diesem Fall bereits nach international anerkannten Standards durchgeführt wurde, zeigt zusätzlich, dass auch die Anwendung aktueller Entwicklungsmethoden noch keine Garantie für ein sicheres System bieten kann. 2

7 2 Sicherheit Im Rahmen dieses Kapitels sollen die Probleme, welche rund um den Einsatz sicherheitskritischer Systeme entstehen, näher betrachtet werden. Zunächst werden einige zentralen Begriffe definiert, und der Einflussbereich des Sicherheitsaspektes abgesteckt. Weiterhin werden einige verwandte Gebiete vorgestellt und gegenüber dem hier betrachteten Bereich abgegrenzt. Abschließend wird dann auf die besondere Rolle von Computern in Verbindung mit sicherheitskritischen Systemen eingegangen. 2.1 Sicherheit und sicherheitskritische Systeme Zunächst soll der Begriff Sicherheit (engl. safety) näher betrachtet werden. In der Literatur finden sich zahlreiche Definitionen dieses Begriffs, wobei [Sto96] ihn beispielsweise wie folgt definiert: Safety is a property of a system that it will not endanger human life or the environment. Diese Definition ist bereits recht konkret auf den Bereich sicherheitskritischer Systeme zugeschnitten. Andere, allgemeinere Definitionen, wie sie beispielsweise in der [ISO51] gefunden werden können, bezeichnen Sicherheit als eine Situation, in der jegliches Risikos auf ein»annehmbares Maß«reduziert wurde. Nach dieser Definition gibt es somit keine»absolute Sicherheit«oder kein»nullrisiko«. Diese Tatsache gilt jedoch nicht nur für den Bereich sicherheitskritischer Systeme, sie lässt sich auf jeden Bereich unseres täglichen Lebens übertragen: So geht beispielsweise jeder Mensch, der in einem Gewitter ins Freie geht stets ein gewisses Risiko ein, von einem Blitz getroffen zu werden... An dieser Stelle soll der, jetzt schon mehrfach verwendete, Begriff des sicherheitskritischen Systems (engl. safety-critical system) definiert werden. A safety-critical system is a system whose incorrect function (failure) may have serious consequences such as loss of human life, severe injuries, large-scale environmental damage... [IBN96] Demnach kann jedes System, welches in einer nicht näher spezifizierten Weise Mensch oder Umwelt schaden zufügen kann, als sicherheitskritisch bezeichnet werden. Im englischen wird häufig der Begriff safety-related system synonym zu safety-critical system verwendet, wobei letzteres meist genutzt wird, um auf die extrem hohe Kritikalität eines Systems hinzuweisen. Abhängig von der Art der Gefahren, die von einem sicherheitskritischen System ausgehen, ist eine Unterteilung der einzelnen Sicherheitsaspekte in die folgenden drei Bereiche möglich. 3

8 Primäre Sicherheit (primary safety) Unter primäre Sicherheit fallen alle Aspekte, welche direkt von der Hardware des Systems ausgehende Gefahren betreffen. Dazu zählt zum Beispiel der Schutz des Benutzers vor elektrischen Schlägen, oder die Verhinderung eines Feuerausbruchs, der durch einen Hardwaredefekt verursacht werden könnte. Funktionale Sicherheit (functional safety) Funktionale Sicherheit spielt insbesondere bei sicherheitskritischen Computersystemen eine Rolle. Sie umfasst die Betrachtung möglicher Gefahrenquellen, die durch die vom System gesteuerten Komponenten ausgehen können. Dieser Aspekt ist somit nur dann relevant, wenn das gesteuerte Equipment tatsächlich in der Lage ist, Schaden zu verursachen. So muss zum Beispiel sichergestellt werden, dass ein Roboterarm in einer Fertigungsanlage unter keinen Umständen einen Arbeiter gefährdet. Indirekte Sicherheit (indirect safety) Einige Systeme stellen zwar selbst keine Gefährdung dar, sind aber dennoch sicherheitsrelevant. In diesem Fall muss die so genannte indirekte Sicherheit betrachtet werden. Ein Beispiel hierfür sind Notrufsysteme, welche durch einen Ausfall ebenfalls Menschen gefährden könnten. Diese Unterteilung suggeriert, dass sich der Sicherheitsaspekt auf Hardware und Steuerungseinheiten beschränkt. In Wirklichkeit kann jedoch jede Komponente eines Systems sicherheitsrelevant werden. Selbst ein einfacher Datenbankzugriff kann sicherheitsrelevant werden, wenn deren Daten in irgendeiner Weise eine sicherheitskritische Funktion beeinflussen. 2.2 Der Einflussbereich des Sicherheitsaspekts Der Einfluss des Sicherheitsaspekts ist sehr weit reichend und beschränkt sich nicht nur auf technische Details bei der Konzeption eines Systems. Der ganze Umfang dieses Einflussbereiches soll nun näher betrachtet werden Einfluss auf den Systemlebenszyklus Um der Forderung nach sicheren und verlässlichen Systemen gerecht zu werden, genügt es in der Regel nicht, lediglich den Entwurf des Systems um verschiedene»schutzfunktionen«zu erweitern. Sicherheit kann nur durch ein Gesamtkonzept erreicht werden, welches den kompletten Lebenszyklus umfasst. Abbildung 1 gibt einen Überblick über den Personenkreis, der im Laufe der Systemlebenszeit direkten Einfluss auf die Sicherheit eines Systems haben kann. Folglich müssen diese in einem Sicherheitskonzept mit berücksichtigt 4

9 werden. Abbildung 1: Der Einflussbereich des Sicherheitsaspekts [Sto96] Bereits der Kunde oder Auftraggeber kann Einfluss auf die spätere Sicherheit eines Systems haben. Falsche oder unvollständige Anforderungen führen dazu, dass das System den realen Anforderungen nicht genügt und somit lebensbedrohliche Fehler enthalten kann. Während des Entwurfsprozesses können zahlreiche weitere Fehler begangen werden. Kapitel 3 stellt einige Techniken und Vorgehensweisen vor, welche helfen sollen, Fehler während dieser Phase weitestgehend zu vermeiden. An dieser Stelle sei jedoch erwähnt, dass Sicherheit kein»feature«ist, welches einem fertigen System in Form von zusätzlichen Modulen oder Funktionen hinzugefügt werden kann. Vielmehr steht der Sicherheitsaspekt stets im Vordergrund und dominiert somit die gesamte Entwicklung. Weiterhin können Fehler in der Produktion von Hardwarekomponenten, sowie falsche Installation, Bedienung oder Wartung des Sysstems ebenfalls die Sicherheit gefährden. In einigen Fällen, insbesondere in der Atomindustrie, muss sogar die Entsorgung des Systems im Rahmen des Sicherheitskonzepts berücksichtigt werden Gesellschaftliche Probleme Wie bereits zu Begin angesprochen, ist es nicht möglich, alle mit einem System verbundenen Risiken vollständig zu eliminieren. Das somit stets verbleibende Restrisiko führt zu weiteren nicht-technischen Problemen beim Einsatz sicherheitskritischer Systeme. Wie Abbildung 1 deutlich macht, gehören Instandhalter, Nutzer oder sogar die breite Öffentlichkeit im Falle eines Systemfehlers zum gefährdeten Personenkreis. Häufig gehört der Auftraggeber oder Betreiber eines Systems selbst nicht 5

10 zu dieser Gruppe und bewertet daher die Sicherheit des Systems ganz anders, als eine betroffene Person. So könnte ein Industrieunternehmer wenig Wert auf die Sicherheit seiner Maschinen legen, da ihm eine hohe Produktivität wichtiger ist, als die Sicherheit seiner Angestellten. Ein weiteres Beispiel sind Atomkraftwerke, die in einem Fehlerfall gleich tausende Menschen bedrohen, die jedoch über den Bau oder die Sicherheit der Anlagen nicht mitentscheiden können. Auf diese Weise wird das Thema»Sicherheit«auch zu einem gesellschaftlichen Problem, was letztendlich dazu führt, dass Entwurf und Einsatz sicherheitskritischer Systeme häufig staatlicher Regulierung oder einem von zahlreichen Industriestandards unterliegen. Diese Standards stellen verschiedene Anforderungen, sowohl an das System selbst, als auch an dessen Entwicklungsprozess. Die Einhaltung dieser Vorgaben wird bei besonders kritischen Anwendungen von einer unabhängigen Zertifizierungsstelle überprüft, bevor das System in Betrieb genommen werden darf. Allerdings können auch solche Regulierungen die gesellschaftlichen Probleme nicht zu 100% lösen. Da stets ein gewisses Restrisiko für das Auftreten eines Schadens besteht, muss auch in den Standards die Gesundheit eines Menschen»bewertet«und gegen den Nutzen eines Systems abgewägt werden Konfliktäre Aspekt Sicherheit ist eine Systemqualität unter vielen und steht somit automatisch mit anderen Qualitäten in Konflikt. Der letzte Abschnitt hat schon den bestehenden Konflikt zwischen Sicherheit und Effizienz angedeutet. So kann in vielen Fällen die Sicherheit auf Kosten der Effizienz erhöht werden. Zum Beispiel wären Autos wesentlich sicherer, wenn ihre Maximalgeschwindigkeit drastisch verringert würde. Ein vollständiger Verzicht auf Autos würde eine weitere Erhöhung der allgemeinen Sicherheit mit sich bringen. Jedoch sind die meisten Menschen bereit, ein gewisses Risiko einzugehen, um in den Genuss der verschiedenen Vorteile eines Autos zu kommen. Weitere Qualitäten sind beispielsweise die Verfügbarkeit (engl. availibility) und Funktionsfähigkeit (engl. reliability) eines Systems. Unter Verfügbarkeit versteht man dabei die Wahrscheinlichkeit, dass ein System zu einem beliebigen Zeitpunkt korrekt funktioniert, wogegen die Funktionsfähigkeit die Wahrscheinlichkeit für ein korrektes Verhalten über einen gewissen Zeitraum angibt. Es steht somit außer Frage, dass eine hohe Verfügbarkeit und Funktionsfähigkeit stets angestrebt werden. Aber auch diese Qualitäten stehen im Konflikt zur Sicherheit. So besitzen sicherheitskritische Systeme häufig einen so genannten failsafe-state, in dem zwar in der Regel keine Funktionalität mehr gegeben ist, dafür aber maximale Sicherheit erreicht wird. Die Sicherheit kann also maximiert werden, wenn ein System diesen Zustand niemals verlässt. Allerdings 6

11 sind dann Verfügbarkeit und Funktionsfähigkeit gleich Null, womit das System letztendlich nutzlos ist. Es wird somit deutlich, dass stets ein trade-off zwischen Sicherheit und anderen Qualitäten durchgeführt werden muss. Dabei ist es unumgänglich, dass auch die Sicherheit zugunsten anderer Qualitäten zurückgestellt wird, um überhaupt ein funktionsfähiges System zu erhalten. 2.3 Verwandte Bereiche Nachdem nun die Problembereiche»Sicherheit«und»sicherheitskritische Systeme«detailliert betrachtet wurden, sollen an dieser Stelle einige verwandte Bereiche vorgestellt und gegeneinander abgegrenzt werden. Die Vertraulichkeit (engl. security) wird im deutschen auch häufig mit dem Begriff»Sicherheit«bezeichnet. Während sich die Sicherheit allerdings mit dem Schutz von Mensch und Umwelt beschäftigt, betrifft die Vertraulichkeit den Schutz vor unerlaubten Zugriff, sei es auf geheime Daten oder bestimmte Funktionen eines Systems. Allerdings setzt Sicherheit stets ein gewisses Maß an Vertraulichkeit voraus: So wäre ein Atomkraftwerk beispielsweise niemals sicher, wenn jeder Zugriff auf dessen Steuerung erlangen könnte. Als zweites sollen die so genannten high integrity systems betrachtet werden, welche eine Obermenge der sicherheitskritischen Systeme bilden. High integrity systems werden als Systeme definiert, deren Fehlverhalten zu einem nicht akzeptablen Schaden führen kann. Die Art des Schadens wird dabei nicht näher spezifiziert, womit also auch finanzielle Verluste oder ein Image-Schaden gemeint sein können. Ein high integrity system, welches nicht sicherheitskritisch ist, wäre zum Beispiel die Transaktionssoftware einer Bank. Einen weiteren Bereich bilden die verlässlichen Systeme (engl. dependable systems). Unter dem Begriff»Verlässlichkeit«werden die Eigenschaften Funktionsfähigkeit, Verfügbarkeit, Sicherheit und Vertraulichkeit zusammengefasst. Diese Zusammenfassung verschiedener Qualitäten zu einem Oberbegriff soll daraufhin deuten, dass alle Qualitäten gleichermaßen wichtig sind. Dieser Ansatz ist laut [Lev95] jedoch irreführend und hat bringt in der Praxis lediglich nachteile mit sich. 2.4 Sicherheitskritische Computersysteme Bis jetzt wurden sicherheitskritische Systeme im Allgemeinen betrachtet, ohne dabei auf die konkrete Rolle von Computern in diesem Bereich einzugehen. Dies soll im Rahmen dieses Abschnitts geschehen. 7

12 2.4.1 Aufbau sicherheitskritischer Computersysteme Die Grafik in Abbildung 2 zeigt schematisch die Integration eines eingebetteten Computersystems in ein Gesamtsystem. Abbildung 2: Aufbau von Kontroll- und Sicherungssystemen [Sto96] Der Computer nimmt über verschiedene Sensoren Informationen über die das von ihm gesteuerte Equipment oder dessen Umwelt auf. Die Software analysiert diese Daten und berechnet gegebenenfalls neue Befehle für das EUC, welche daraufhin über die so genannten Aktoren an das Equipment weitergeleitet werden. Sicherheitskritische Computersysteme können gemäß ihrer Funktion einer von zwei Klassen zugeordnet werden. Kontrollsysteme (control systems) Kontrollsysteme dienen primär der Steuerung anderer Systemkomponenten. Sie können genau dann als sicherheitskritisch eingestuft werden, wenn das kontrollierte Equipment unter gewissen Umständen eine Gefahrenquelle darstellt. Sicherungssysteme (protection systems) Sicherungssysteme werden in Systemen eingesetzt, die von Natur aus sicherheitskritisch sind. Sie dienen der Kontrolle anderer Systemkomponenten sowie der Umwelt des Systems. Weichen die über die Sensoren ermittelten Daten von gewissen Sollwerten ab, kann dies vom Sicherungssystem an eine Kontrollinstanz gemeldet werden, oder es können geeignete Gegenmaßnahen eingeleitet werden. Eine Untermenge dieser Gruppe sind die so genannten shut-down systems, die in einem Fehlerfall das System in einen failsafe-state überführen sollen Vor- und Nachteile von Computersystemen Verschiedene Gründe sprechen sowohl für, als auch gegen den Einsatz von 8

13 Computern in sicherheitskritischen Anwendungen. Ein klarer Vorteil von Computern ist ihre Leistungsfähigkeit. Sie sind in der Lage die Daten zahlreicher Sensoren entgegen zu nehmen und komplexe Rechenoperationen in kürzester Zeit durchzuführen. Gleichzeitig sind sie klein, leicht und haben einen verhältnismäßig geringen Energiebedarf. Diese Eigenschaft macht sie in vielen Bereichen einsetzbar. Ein weiterer Vorteil ist ihre Flexibilität, die hauptsächlich durch die Verwendung von Software entsteht. Anpassungen des Systemverhaltens können beispielsweise durch einfache Softwareupdates problemlos durchgeführt werden. Die Nachteile von Computern in diesem Zusammenhang sind weit weniger offensichtlich. So besteht das Hauptproblem in der enormen Komplexität von Hard- und Software. Je höher die Komplexität eines Systems, desto höher ist auch die Gefahr, dass es unentdeckte Designfehler enthält. Ein allgemeines Entwurfsziel sicherheitskritischer Hard- und Software ist daher stets die Komplexität so gering wie möglich zu halten. Insbesondere Software ist jedoch von Natur aus Komplex. Im Vergleich zu den meisten herkömmlichen Ingenieursprodukten liegt ihr kein kontinuierliches, sondern ein diskretes Zustandsmodell zu Grunde, wobei der Zustandsraum in der Regel zu groß ist, um sämtliche Zustände und Zustandsübergänge im Rahmen eines Tests zu überprüfen. Da ein vollständiger Systemtest nicht möglich, kann auch in der Regel die Fehlerfreiheit von Software nicht garantiert werden. Aus diesem Grund sollte nicht kategorisch auf den Einsatz von Computern in sicherheitskritischen Anwendungen gesetzt werden. Existieren alternativen, die auf einer anderen Technologie basieren, so sollten diese einem Computersystem unter Umständen vorgezogen werden Fehlerarten Im Zusammenhang mit sicherheitskritischen Computersystemen werden drei verschiedene Arten von Fehlern unterschieden. Ein fault bezeichnet einen tatsächlichen Fehler im System. Ein error ist das eventuell daraus resultierende Fehlverhalten, beziehungsweise das Abweichen von der eigentlich vorgesehenen Operation. Aus einem»error«kann nun ein system failure werden, wenn das System daraufhin seine eigentliche Aufgabe nicht mehr richtig erfüllt. In einem hierarchisch aufgebauten System stellt also ein»system failure«einer Subkomponente einen»fault«im übergeordneten Modul dar. Fehler, im Sinne von»faults«, können weiterhin in zwei Klassen unterteilt werden. Zufällige Fehler (engl. random faults) betreffen nur die Hardware. Hierunter fällt zum Beispiel die ungewollte Veränderung eines Bits, wie sie bei einer 9

14 Datenübertragung passieren kann. Da über diese Art von Fehlern statistische Daten erhoben werden können, ist eine Voraussage über ihr Auftreten, sowie die Auswirkungen auf die Gesamtperformanz des Systems möglich. Die zweite Klasse von Fehlern bilden die systematischen Fehler (engl. systematic faults). Hierunter fallen Fehler in der Spezifikation, dem Design oder der Implementierung des Systems. Über Fehler dieser Kategorie können keinerlei statistische Daten erhoben werden, was ihre Handhabung deutlich erschwert. Diese Fehlerklasse stellt insbesondere bei Software ein großes Problem dar. So werden Hardwarekomponenten, wie beispielsweise Mikroprozessoren, für den allgemeinen Einsatz konzipiert. Wird zum Beispiel ein Prozessormodell über einen längeren Zeitraum in unterschiedlichen Bereichen erfolgreich eingesetzt, so kann davon ausgegangen werden, dass er keine systematischen Fehler enthält. Software hingegen wird für einen speziellen Zweck geschrieben und kann unter Umständen erst im echten Betriebsumfeld zum ersten Mal voll getestet werden. Verschiedene Strategien sollen während des Entwurfsprozesses von Software den Umgang mit systematischen Fehlern erleichtern [Sto96]: Fehlervermeidung (engl. fault avoidance) Die Verwendung formaler Methoden unterstützt die Fehlervermeidung in der Spezifikations- und Designphase. Ein Beispiel hierfür ist die Verwendung von Datenflussdiagrammen et cetera. Bei der Implementierung von Software helfen bereits einfache Techniken wie Kapselung oder information hiding bei der Vermeidung von Fehlern. Fehlerbeseitigung (engl. fault removal) Fehler in der Spezifikation und im Design können beispielsweise durch zusätzliche Validierung, oder Design-Reviews gefunden werden. Im Fertigen System können Fehler durch umfangreiche Tests, code-walk throughs oder ähnliche Aktivitäten identifiziert werden. Fehlererkennung (engl. detection) Die Fehlererkennung soll es dem System ermöglichen, im laufenden Betrieb Fehler selbsttätig zu erkennen. Wurde eine fehlerhafte Komponente entdeckt, kann unter Umständen ein Administrator informiert werden, oder dieser eigenständig behoben werden. Fehlertoleranz (engl. fault tolerance) Fehlertoleranz soll es ermöglichen, dass ein System auch in Anwesenheit eines Fehlers, wenn auch in eingeschränkter Form, weiter funktioniert, oder, beispielsweise durch reinitiallisierung einzelner Systemkomponenten, Fehler eigenständig behebt (system recovery). Es bleibt anzumerken, dass keine dieser Techniken alleine ausreicht, um das 10

15 Auftreten systematischer Fehler zu vermeiden. Erst eine Kombination aus all diesen Techniken hilft dabei, ein adäquates Sicherheitsniveau zu erreichen. 3 Entwurf sicherheitskritischer Software In diesem Kapitel soll nun der Entwicklungsprozess sicherheitskritischer Software näher betrachtet werden. In Abschnitt wurde bereits angesprochen, dass es verschiedene staatliche Vorschriften oder industrielle Standards gibt, welche ein Vorgehen bei der Entwicklung sicherheitskritischer Systeme vorschreiben um eine spätere Zertifizierung des Systems zu erlangen. In Deutschland ist das V-Modell seit 1997 ein solcher (international anerkannter) Standard, der für Bundesbehörden, sowie für alle von ihnen vergebenen Aufträge, verpflichtend ist [Ver00]. Ziel dieser Standards ist es unter anderem, eine vereinheitlichte Vorgehensweise bei der Erstellung sicherheitskritischer Systeme zu erreichen, um eine verbesserte Vergleichbarkeit und Bewertbarkeit der Ergebnisse zu ermöglichen. Die erhöhten (Sicherheits-)Anforderungen, sowie die angesprochenen Standards und Regulierungen führen dazu, dass sich der Entwurf sicherheitskritischer Software in vielen Punkten vom Entwicklungsprozess herkömmlicher Software unterscheidet. In diesem Kapitel soll das Vorgehen beim Entwurf sicherheitskritischer Software näher vorgestellt werden. 3.1 Qualitätsmanagement Es steht mittlerweile außer Frage, dass die Qualität des Herstellungsprozesses erhebliche Auswirkungen auf die Qualität des erzeugten Produktes hat. Dies gilt insbesondere für Software, womit dem Qualitätsmanagement beim Entwurf sicherheitskritischer Software eine zentrale Rolle zukommt. Der Begriff Qualität ist nach [ISO8402] wir folgt definiert: "Qualität ist die Gesamtheit von Eigenschaften und Merkmalen eines Produktes oder einer Dienstleistung, die sich auf deren Eignung zur Erfüllung festgelegter oder vorausgesetzter Erfordernisse beziehen." Das Ziel des Qualitätsmanagements ist nun die Verbesserung und Aufrechterhaltung der Qualität aller Produkte und Aktivitäten eines Unternehmens [Sto96]. Qualitätsmanagement wird somit nicht in einer bestimmten Phase des Entwicklungsprozesses durchgeführt, sondern muss permanent in einem Unternehmen betrieben werden, um zum gewünschten Erfolg zu führen. Qualitätsmanagement besteht zum einen aus Qualitätskontrolle, welche die 11

16 Verbesserung der Produktqualität als Ziel hat, und zum anderen aus Qualitätssicherung, bei der eine korrekte Durchführung des Entwicklungs- und Herstellungsprozesses sichergestellt werden soll. Beim Entwurf sicherheitskritischer Systeme unterstützt die Qualitätssicherung insbesondere die ordnungsgemäße Dokumentation des Sicherheitsrelevanten Aspekte eines Systems (safety case). Bei einer späteren Zertifizierung spielen diese Dokumente im Rahmen der Sicherheitsrechtfertigung (engl. safety justification) eine zentrale Rolle. Auch in diesem Bereich existieren unterschiedliche Standards für das Vorgehen im Rahmen des Qualitätsmanagement, deren korrekte Anwendung sich ein Unternehmen zertifizieren oder beglaubigen lassen kann. Insbesondere bei der Auftragsvergabe für sicherheitskritische Systeme, beispielsweise von staatlicher Seite aus, muss ein Unternehmen gewisse Qualitätsstandards befolgen, um einen Auftrag zu erhalten. Diese Tatsache zeigt einmal mehr die enorme Bedeutung des Qualitätsmanagements. 3.2 Ein Vorgehensmodell Viele Standards für die Entwicklung von sicherheitskritischen Systemen schreiben ein bei der Projektdurchführung zu verwendendes Vorgehensmodell vor. Ein typisches Beispiel für ein solches Modell ist das V-Modell, welches einen Top-Down Ansatz bei Entwurf und Realisierung, sowie einen Bottom-Up Ansatz beim Test des Systems vorsieht. Abbildung 3 zeigt ein solches V-Modell, wie es im STARTS Guide [STARTS89] zu finden ist. Abbildung 3: Ein Vorgehensmodell für den Entwicklungsprozess sicherheitskritischer Software [STARTS89] 12

17 Wie jedes Vorgehensmodell stellt auch dieses Modell nur eine grobe Annäherung des wirklichen Entwicklungsprozesses dar. Insbesondere findet das Durchlaufen der einzelnen Projektphasen in der Praxis nicht in einer so streng sequenziellen Form statt, wie es die Abbildung suggeriert. Auch wenn der Sicherheitsaspekt in all diesen Phasen beachtet werden muss, wird im weiteren Verlauf nur auf einige der in Abbildung 3 gezeigten Aktivitäten eingegangen Gefahrenanalyse Die Gefahrenanalyse (engl. hazard analysis) stellt die wohl wichtigste Phase während des Entwurfs sicherer Systeme dar. Grundsätzlich steckt hinter ihr der Gedanke, dass man eine Gefahr zunächst kennen muss, um sie später vermeiden zu können. [Sto96] definiert das Wort Gefahr wie folgt: A hazard is a situation in which there is actual or potential danger to people or to the environment. Das Ziel der Gefahrenanalyse besteht nun darin, möglichst alle Gefahren, die vom System ausgehen können, sowie deren Ursachen zu ermitteln. Hierzu können verschiedene analytische Techniken verwendet werden, welch im Rahmen dieser Arbeit jedoch nicht im Detail vorgestellt werden sollen. Beispiele für solche Techniken sind unter anderem die failure modes and effects analysis (FMEA), bei der systematisch geprüft wird, wie sich ein Fehler einer einzelnen Komponente auf das Gesamtsystem auswirkt, oder die fault tree analysis (FTA), bei der ausgehend von einer identifizierten Gefahr die möglichen Ursachen im System ausfindig gemacht werden. Insgesamt werden während der Gefahrenanalyse verschiedene Aktivitäten durchgeführt, über die Abbildung 4 einen Überblick gibt. Die Rechtecke stellen die einzelnen Aktivitäten dar, während die Ellipsen auf der rechten Seite die verschiedenen Dokumente repräsentieren, die während der Gefahrenanalyse gepflegt werden sollten. Wie bereits angedeutet stellt das Vorgehensmodells in Abbildung 3 lediglich eine Annäherung an das tatsächliche Vorgehen dar. So werden zu Beginn des Projektes lediglich die die vorläufige Gefahrenidentifizierung (preliminary hazard identification, PHI), sowie die vorläufigen Gefahrenanalyse (preliminary hazard analysis, PHA) durchgeführt. Ziel der PHI ist die Identifizierung aller möglichen Gefahren, womit sie folglich beim Entwurf jedes eingebetteten Systems durchgeführt werden sollte, um zu prüfen, ob dieses überhaupt sicherheitsrelevant ist. Ist dies nicht der Fall, so braucht der Sicherheitsaspekt im weiteren Projektverlauf nicht mehr explizit betrachtet werden. Die PHA basiert 13

18 auf den Ergebnissen der PHI und dient einer detaillierten Analyse der identifizierten Gefahren. So werden unter anderem die Gefahren in Bezug auf die funktionalen Anforderungen des Systems betrachtet, um den einzelnen Funktionen Sicherheitsimplikationen zuzuordnen. Weiterhin ist bereits hier möglich, mit Rücksicht auf die identifizierten Gefahren verschiedene Entwurfsalternativen für das System zu entwickeln. Abbildung 4: Einzelaktivitäten einer Gefahrenanalyse [Sto96] Zu diesem Zeitpunkt kann nun die Risikoanalyse durchgeführt werden, deren Ergebnisse den weiteren Entwicklungsprozess entscheiden beeinflussen können. Die Risikoanalyse wird im folgenden Abschnitt genauer vorgestellt. Im weiteren Projektverlauf werden dann Sicherheitsprüfungen (engl. safety reviews), System-Gefahrenanalyse (engl. system hazard analysis) sowie System-Risikobewertung (engl. system risk assessment) durchgeführt. So werden beispielsweise bei der System-Gefahrenanalyse am konkreten Systementwurf mögliche Ursachen für Gefahren gesucht und analysiert. In der System- Risikobewertung muss daraufhin das mit dem System verbundene Risiko 14

19 erneut bewertet werden. Nach Änderungen am Entwurf müssen diese Phasen entsprechend wiederholt werden. Bei extrem kritischen Anwendungen wird ein zusätzliches Sicherheitsaudit durchgeführt. Hierbei prüft eine in der Regel unabhängige Instanz die Korrektheit und Vollständigkeit der verschiedenen sicherheitsrelevanten Dokumente Risikoanalyse Nachdem die Gefahren eines Systems identifiziert wurden, sollten diese klassifiziert werden. Da sich verschiedene Gefahren durch die Wahrscheinlichkeit, dass aus der Gefahr ein tatsächlicher Unfall wird, sowie durch die Schwere der Unfallfolgen unterscheiden, erscheint es nicht sinnvoll, alle Gefahren beim Systementwurf gleich zu berücksichtigen. Zur Klassifizierung einer Gefahr wird der Begriff des Risikos (engl. risk) eingeführt, welcher wie folgt definiert ist: Risk is a combination of the frequency of propability of a specified hazardous event, and its consequences [Sto96] Die Risikoanalyse soll also das mit einer Gefahr verbundene Risiko ermittelt. Hierzu ist eine qualitative oder quantitative Bewertung von Ereignissen beziehungsweise deren Konsequenzen notwendig. Eine qualitative Bewertung wäre beispielsweise eine Angabe wie»ausfälle pro Flugstunde«, wogegen bei einer qualitativen Bewertung Häufigkeit und Schweregrad einer vorher definierten Klasse zugeordnet werden. Standards setzen meist auf den qualitativen Ansatz, da dieser allgemeiner gehalten werden kann, was die Anwendbarkeit in der Praxis erhöht. Der Ablauf der verschiednen Aktivitäten im Rahmen der Risikoanalyse wird in Abbildung 5 dargestellt. Abbildung 5: Ablauf der Risikoanalyse [Sto96] Die während der Analyse durchgeführten Bewertungen variieren je nach Industriezweig und verwendetem Standard teilweise sehr stark. Daher werden im Folgenden die einzelnen Bewertungsschemata des IEC1508 verwendet 15

20 [IEC1508]. Dies ist kein Standard, sondern lediglich ein Draft, welcher eine grobe Orientierung für andere, speziellere Industriestandards darstellen soll. Der erste Schritt besteht in der Bestimmung der Unfallschwere. Diese wird im IEC1508 in vier Kategorien unterteilt, namentlich Catastrophic, Critical, Marginal, Negligible. Die einzelnen Kategorien werden zwar nicht genauer definiert, doch ist davon auszugehen, dass sie in Anlehnung an den Militärstandard [MoD95] entstanden sind, welcher die Klassen wie folgt definiert: Als katastrophal werden mehrere Todesfälle bezeichnet, kritisch ist ein einzelner Todesfall oder mehrere schwere Verletzungen. Ein einzelne schwere Verletzung, oder zahlreiche leichte Verletzungen werden als marginal eingestuft, wohingegen vereinzelte leichte Verletzungen letztlich der Klasse Vernachlässigbar zugeordnet werden. Die Wahrscheinlichkeiten für das Auftreten eines Unfalls werden im IEC1508 in 6 Klassen unterteilt: Frequency Frequent Probable Occasional Remote Improbable Incredible Occurrences during operational life considering all instances of the system Likely to be continually experienced Likely to occur often Likely to occur several times Likely to occur some time Unlikely, but may exceptionally occur Extremely unlikely that event will occur at all Tabelle 1: Klassifizierung der Unfallwahrscheinlichkeiten nach IEC 1508 Auf Basis dieser Bewertungen kann nun der eigentliche Risikofaktor ermittelt werden. Auch hierfür werden im IEC Draft verschiedenen Klassen, namentlich I, II, III und IV, definiert, wobei Klasse IV die Klasse mit dem geringsten Risiko darstellt. Tabelle 2 zeigt die Herleitung dieser Risikoklasse auf Basis der Schwere und Wahrscheinlichkeit eines Unfalls. Die Interpretation der einzelnen Klassen wird in Tabelle 3 dargestellt. 16

21 Consequences Frequency Catastrophic Critical Marginal Negligible Frequent I I I II Probable I I II III Occasional I II III III Remote II III III IV Improbable III III IV IV Incredible IV IV IV IV Tabelle 2: Risikoklassifizierung nach IEC1508 Risk class I II III IV Interpretation Intolerable risk Undesirable risk, and tolerable only if risk reduction is impractical or if the costs are grossly disproportionate to the improvement gained Tolerable risk, if the cost of risk reduction would exceed the improvement gained Negligible risk Tabelle 3: Interpretation der Risikoklassen nach IEC1508 Die Beschreibungen in Tabelle 3 machen deutlich, dass ein System der Risikoklasse I unter keinen Umständen realisiert werden sollte, wogegen Risikoklasse IV keinen nennenswerten Sicherheitsrisiken in sich birgt und somit auf eine gesonderte Betrachtung des Sicherheitsaspekts verzichtet werden kann. Fällt ein System unter die Kategorie II oder III, so muss entschieden werden, ob der vom System ausgehende Nutzen das Eingehen des verbleibenden Restrisikos rechtfertigt. Diese Entscheidung wird häufig von der Zertifizierungsstelle getroffen. Dabei wird das Prinzip verfolgt, dass das Risiko stets»so gering wie vernünftigerweise möglich«engl. (as low as reasonably possible) sein muss. Dies bedeutet, dass ein System dieser Risikoklasse nur dann ein Zertifikat erhalten sollte, wenn das jeweilige Restrisiko nur noch mit unverhältnismäßig hohem (finanziellen) Aufwand oder Verlust an Effektivität des Gesamtsystems erzielt werden kann. Zum Abschluss der Risikoanalyse kann dem System ein so genanntes safety 17

22 integrity level (SIL) zugewiesen werden. Safety integrity Level Continuous mode of operation (probability of a dangerous failure per year) Demand mode of operation (probability of a failure to perform its designed function on demand) to < to < to < to < to < to < to < to < 10-1 Tabelle 4: Zuweisung des SIL nach Fehlerwahrscheinlichkeit nach IEC1508 Abhängig vom zugewiesenen Integritätslevel wird in den verschiedenen Standards nun das weitere Vorgehen beim Systementwurf, beispielsweise in Form von zu verwendenden Techniken vorgeschrieben. Der Grundgedanke bei diesem Vorgehen ist der, dass beim Entwurf eines Systems mit hohem Risiko eine großes Maß Risikoreduzierung notwendig ist, was wiederum hohe Anforderungen an die Techniken stellt, welche in diesem Zusammenhang verwendet werden Spezifikation In der Spezifikation eines Systems wird beschrieben,»was«das zu entwerfende System leisten muss. Dieser Phase kommt in Verbindung mit sicherheitskritischer Software eine besondere Rolle zu. Laut [Vil91] entstehen gut zwei drittel aller Softwarefehler aufgrund einer fehlerhaften Spezifikation. Während der Spezifikationsphase wird sowohl eine Anforderungsspezifikation (engl. requirements specification) sowie eine Systemspezifikation (engl. system specification) erstellt [IBN96]. Eine häufige Ursache für Fehler in diesen Spezifikationen ist Verwendung von natürlicher Sprache, da die Korrektheit oder Vollständigkeit einer entsprechenden Beschreibung nicht überprüft werden kann. Weiterhin besteht die Gefahr der Missinterpretation. So wird versucht möglichst nur die Anforderungsspezifikation, die in einer für den Kunden verständlichen Weise verfasst werden muss, in natürlicher Sprache zu schreiben. Bei der Systemspezifikation, welche die Grundlage für die weiter interne Projektarbeit ist, wird insbesondere bei der Spezifikation sicherheitskritischer Systeme, vermehrt auf den Einsatz formaler Beschreibungsmethoden, wie beispielsweise temporale Logiken, gesetzt. Der hierfür notwendige Formalisierungsprozess zwingt den Entwickler, sich intensiv mit den Anforderungen auseinander zu setzen. Dies kommt der Sicherheit insofern zugute, als dass Unklarheiten oder Widersprüche besser erkannt und beseitigt werden können. 18

23 Es ist dennoch nicht ausgeschlossen, dass Fehler bei der Transformation der informalen Anforderungen in das formale Modell begangen werden. Dies kann nur durch die Durchführung von Reviews oder ähnlichen Aktivitäten verhindert werden Verifikation & Validierung Auch der Validierung und Verifikation kommt im Zusammenhang mit sicherheitskritischer Software eine besondere Rolle zu, da diese Verfahren die Korrektheit des Systems überprüfen sollen. Die Aufgabe der Verifikation ist es zu Prüfen, ob die Ergebnisse einer Entwicklungsphase den vorausgegangenen Anforderungen entsprechen. Abbildung 3 stellt nur die abschließende Verifikation des Gesamtsystems dar, in der geprüft wird, ob das System tatsächlich der Spezifikation entspricht. Im Prinzip kann und sollte eine Verifikation nach jeder Projektphase durchgeführt werden. Methoden der Verifikation sind beispielsweise model-checking oder theorem proving. Im Rahmen der Validierung soll letztendlich sichergestellt werden, dass das System auch den Anforderungen des Kunden entspricht. Da diese in einer informalen Art gegeben sind, existiert auch keine formale Methode für die Validierung. So wird ein System in der Regel mittels Tests oder Simulationen validiert Zertifizierung Die Zertifizierung bildet den Abschluss des Entwicklungsprozesses der meisten sicherheitskritischen Systeme und soll die Konformität dieser Systeme bezüglich eines Standards belegen. In dieser Phase wird von einer unabhängigen Instanz geprüft, ob die vorgeschriebenen Entwicklungstechniken verwendet wurden und ob die mit den verschiedenen Gefahren verbundenen Risiken in ausreichendem Maße reduziert wurden. Letztendlich entscheidet die Zertifizierungsstelle ob das erstellte System eingesetzt werden darf. Auch wenn die Zertifizierung kein Garant für ein sicheres System ist, wird die Sicherheit durch die Prüfung einer unabhängigen Instanz deutlich erhöht. 4 Zusammenfassung Im Rahmen dieser Arbeit wurde ein Überblick über den Entwurf sicherer Systeme gegeben. Dazu wurde zunächst der Problembereich definiert und gegenüber verwandten Bereichen, wie etwa der Vertraulichkeit oder den High 19

24 Integrity Systems abgegrenzt. Weiterhin wurden die Vor- und Nachteile, die der Einsatz von Computern in sicherheitskritischen Anwendungen mit sich bringt, diskutiert. Dabei wurde deutlich, dass es aufgrund der hohen Komplexität insbesondere der Software nahezu unmöglich ist, deren Korrektheit nachzuweisen. Aus diesem Grund werden erhöhte Anforderungen an den Entwicklungsprozess solcher Systeme gestellt, um später dennoch ein angemessen sicheres System zu erhalten. Eine zentrale Rolle in diesem Prozess spielen die Gefahren- und Risikoanalyse, welche der Identifikation von Gefahren beziehungsweise der Bewertung der mit ihnen verbundenen Risiken dienen. Die Ergebnisse der Risikoanalyse entscheiden dann über die in der weiteren Entwicklung zu verwendenden Techniken. Insgesamt wurde jedoch nur ein Überblick über das Vorgehen beim Entwicklungsprozess sicherheitskritischer Systeme gegeben. Nahezu jede Projektphase hat Einfluss auf die spätere Sicherheit des Systems und es existieren zahlreiche Techniken, deren Anwendung den Sicherheitsaspekt innerhalb dieser Phasen besonders berücksichtigt. Diese Techniken, wurden in der Regel nur namentlich erwähnt, da deren detaillierte Vorstellung den Rahmen dieser Arbeit gesprengt hätte. 20

25 A Literaturverzeichnis [ERCIM03] [IBN96] [IEC1508] [ISO51] [ISO8402] [Lev95] European Research Consortium for Informatics and Mathematics: News Number 52, Special: Embedded Systems. Online: U. Isaksen, J. Bowen, N. Nissanke: System and Software Safety in Critical Systems. University of Reading, 1996 Intervational Electronical Commision Draft, International Standard 1508: Functional Safety: Safety-Relate System. Geneva, 1995 ISO/IEC Guide 51: Safety aspects 1999 ISO 8402: Quality management and quality assurance 1994 N. Leveson: Safeware. Addison-Wesley, 1995 [MoD95] Directorate of Standardization Draft: Defence Standard Issue 2: Safety Management Requirements for Defence Systems Containing Programmable Electronics, Part 1. Glasgow, 1995 [STARTS89] [Sto96] [Ver00] [Vil91] STARTS Purchasers Group: Purchasers Handbook: Software Tools for Application to Large Real Time Systems. Manchaster, 1989 N. Storey: Safety critical computer systems. Prentice Hall, 1996 G. Versteegen: Das V-Modell in der Praxis dpunkt-verlag, 2000 A. Villemeur: Reliability, Availibility, Maintainability and Safety Assessment. John Eiley & Sons,