SI. Sicherheit und Kritikalität

SA. Safety and Criticality

Inhalt
SA.1 Behandlung der Sicherheit
SA.2 Behandlung der Kritikalität
Verknüpfungen mit der V-Modell Mailingliste

Inhalt		SA.1 Behandlung der Sicherheit SA.2 Behandlung der Kritikalität Verknüpfungen mit der V-Modell Mailingliste

SA.1 Behandlung der Sicherheit

Kriterienkataloge zur Sicherheit fassen jeweils Mengen von Prüfkriterien an den Sicherheitsanteil eines Systems in Abhängigkeit der sicherheitsrelevanten Einstufung zusammen. Diese Einstufung bestimmt die Evaluierung unter den Aspekten Wirksamkeit und Korrektheit.

Aus Sicht des Entwicklungsprozesses sind hieraus abzuleiten:

Anforderungen an die Existenz bestimmter Produkte
Anforderungen an Inhalt und Eigenschaften dieser Produkte
Anforderungen an die Prüfung dieser Produkte
Anforderungen an Methoden/Werkzeuge, der Entwicklung
Anforderungen an die Rollenverteilungen und die damit verbundenen organisatorischen Maßnahmen

Die Anforderungen an die ersten drei Kategorien werden durch die Regelungen des V-Modells unmittelbar erfüllt. Die Anforderungen hinsichtlich der Methoden, Werkzeuge und organisatorischen Maßnahmen werden mittelbar im Rahmen der Vorgehensweise nach V-Modell erfüllt, indem diese in den entsprechenden Planungsdokumenten festgeschrieben und damit kontrolliert realisiert werden.

SA.2 Behandlung der Kritikalität

Unter "Kritikalität" wird im V-Modell die Bedeutung verstanden, die einem Fehlverhalten einer Betrachtungseinheit beigemessen wird. Es gibt sowohl physikalische Betrachtungseinheiten, dies sind die Produkte System, Segment, SW-Einheit/HW-Einheit, SW-Komponente, SW-Modul, Datenbank, als auch logische Betrachtungseinheiten, dies sind Funktionen (Systemfunktion, Segmentfunktion, Einheiten-Funktion). Zur Einstufung der Kritikalität ist nicht allein die physikalische Betrachtungseinheit, sondern auch die von ihr berührte Umgebung zu berücksichtigen. So sind z. B. bei einem Fehlverhalten der Software eines IT-Systems potentielle Auswirkungen in Betracht zu ziehen, die sowohl das System selbst als auch in der Folge seine Umwelt betreffen.

SI.2.1 Kritikalitätszuordnung

Die Kritikalität einer Betrachtungseinheit wird in Stufen (Kritikalitätsstufen) angegeben, wobei die Einstufung umso höher ist, je gravierendere direkte und indirekte Auswirkungen bei Fehlverhalten zu erwarten sind.

Als eine allgemeine Festlegung für technische Systeme kann die Kritikalitätseinstufung in Tabelle SI.1 angesehen werden

Kritikalität Art des Fehlverhaltens
hoch Fehlverhalten kann zum Verlust von Menschenleben führen
mittel Fehlverhalten kann die Gesundheit von Menschen gefährden oder zur Zerstörung von Sachgütern führen
niedrig Fehlverhalten kann zur Beschädigung von Sachgütern führen, ohne jedoch Menschen zu gefährden
keine Fehlverhalten gefährdet weder die Gesundheit von Menschen noch Sachgüter

Kritikalität	Art des Fehlverhaltens
hoch	Fehlverhalten kann zum Verlust von Menschenleben führen
mittel	Fehlverhalten kann die Gesundheit von Menschen gefährden oder zur Zerstörung von Sachgütern führen
niedrig	Fehlverhalten kann zur Beschädigung von Sachgütern führen, ohne jedoch Menschen zu gefährden
keine	Fehlverhalten gefährdet weder die Gesundheit von Menschen noch Sachgüter

Tabelle SI.1: Festlegung von Kritikalität für technische Systeme

Bei Software muß die Festlegung der Kritikalität von deren Einsatzzweck abhängig gemacht werden. Sie soll, ebenso wie die Festlegung der Anzahl der Stufen, immer projektspezifisch durch eine Abschätzung der direkten und indirekten Auswirkungen eines möglichen Fehlverhaltens erfolgen.

Bei administrativen Informationssystemen ist durch ein Fehlverhalten keine Gefährdung von Menschenleben zu erwarten. Hier könnte beispielsweise für ein spezifisches Projekt die Kritikalitätseinstufung in Tabelle SI.2 verwendet werden.

Kritikalität Art des Fehlverhaltens
hoch Fehlverhalten macht sensitive Daten für unberechtigte Personen zugänglich oder verhindert administrative Vorgänge (z. B. Gehaltsauszahlung, Mittelzuweisung) oder führt zu Fehlentscheidungen infolge fehlerhafter Daten.
niedrig Fehlverhalten, das zum Ausfall von Plandaten und damit zu Abflugverzögerungen führen kann.
keine alle übrigen Arten von Fehlverhalten.

Kritikalität	Art des Fehlverhaltens
hoch	Fehlverhalten macht sensitive Daten für unberechtigte Personen zugänglich oder verhindert administrative Vorgänge (z. B. Gehaltsauszahlung, Mittelzuweisung) oder führt zu Fehlentscheidungen infolge fehlerhafter Daten.
niedrig	Fehlverhalten, das zum Ausfall von Plandaten und damit zu Abflugverzögerungen führen kann.
keine	alle übrigen Arten von Fehlverhalten.

Tabelle SI.2: Festlegung von Kritikalität für administrative Informationssysteme

Als Beispiel einer projektspezifischen Kritikalitätseinstufung für eine Realzeitanwendung (z. B. Flugsicherung) könnte die Kritikalitätseinstufung in Tabelle SI.3 angesehen werden.

Kritikalität Art des Fehlverhaltens
hoch Fehlverhalten, das zu fehlerhaften Positionsangaben der Flugobjekte am Kontrollschirm führen kann.
niedrig Fehlverhalten, das zum Ausfall von Plandaten und damit zu Abflugverzögerungen führen kann.
keine alle übrigen Arten von Fehlverhalten.

Kritikalität	Art des Fehlverhaltens
hoch	Fehlverhalten, das zu fehlerhaften Positionsangaben der Flugobjekte am Kontrollschirm führen kann.
niedrig	Fehlverhalten, das zum Ausfall von Plandaten und damit zu Abflugverzögerungen führen kann.
keine	alle übrigen Arten von Fehlverhalten.

Tabelle SI.3: Festlegung von Kritikalität für Realzeitanwendungen

Im Geltungsbereich des V-Modells leiten sich aus einer festgelegten Kritikalitätsstufe zusätzliche Qualitätsanforderungen ab, die der jeweiligen Funktionalität, d. h. den jeweiligen Funktionen samt ihren Importschnittstellen, zuzuordnen sind. Die Festlegung der Kritikalität der Funktionen ist für das System, jedes Segment und jede SW-Einheit/HW-Einheit in einer Kritikalitäten/Funktionen-Matrix darzustellen. Hierbei wird in Matrizendarstellung einer jeden Funktion eine bestimmte Kritikalitätsstufe zugeordnet.

SI.2.2 Vererbung der Kritikalität

Im Verlauf der Entwicklung werden Betrachtungseinheiten zunehmend verfeinert. Dabei vererben sich die Kritikalitätseinstufungen vom System auf die Systemfunktionen (Produkt

Funktion), von den Systemfunktionen auf Segmente (Funktion

Produkt), vom Segment auf die Segmentfunktionen und von hier ab über die SW-Einheiten/HW-Einheiten zu den Funktionen der SW-Einheiten/HW-Einheiten bis auf die SW-Komponenten, SW-Module und Datenbanken.

Da mit der Kritikalitätsstufe die Entwicklungskosten steigen, muß stets eine Minimierung der Anzahl kritischer Funktionen bei unverändertem Systemverhalten angestrebt werden. Hohe Kritikalität darf nur dort vergeben werden, wo sie notwendig ist.

Es gilt folgende Regel 1 (Vererbungsregel)::

R 1a Produkt Funktion
Mindestens eine der bei oben angeführtem Verfeinerungprozeß aus einem Produkt erzeugten Funktionen muß eine gleich hohe Kritikalitätsstufe wie das Produkt selbst besitzen.
R 1b Funktion Produkt
Bei der Zuordnung der Funktionen zu den Produkten muß mindestens ein einer Funktion zugeordnetes Produkt eine gleich hohe Kritikalitätsstufe haben wie die Funktion.

R 1a	Produkt Funktion Mindestens eine der bei oben angeführtem Verfeinerungprozeß aus einem Produkt erzeugten Funktionen muß eine gleich hohe Kritikalitätsstufe wie das Produkt selbst besitzen.
R 1b	Funktion Produkt Bei der Zuordnung der Funktionen zu den Produkten muß mindestens ein einer Funktion zugeordnetes Produkt eine gleich hohe Kritikalitätsstufe haben wie die Funktion.

Eine weitere Regel R2 betrifft die Kritikalität abhängiger Funktionen:

R 2a Beeinflussen sich zwei Funktionen einseitig, d. h. eine Funktion nutzt Leistungen der anderen, so muß die Kritikalitätsstufe der beeinflussenden (benutzten) Funktion mindestens ebenso hoch sein wie die der nutzenden Funktion.
R 2b Beeinflussen sich zwei Funktionen gegenseitig, z. B. durch gegenseitiges Senden von Signalen, müssen beide die gleiche Kritikalitätseinstufung haben.

R 2a	Beeinflussen sich zwei Funktionen einseitig, d. h. eine Funktion nutzt Leistungen der anderen, so muß die Kritikalitätsstufe der beeinflussenden (benutzten) Funktion mindestens ebenso hoch sein wie die der nutzenden Funktion.
R 2b	Beeinflussen sich zwei Funktionen gegenseitig, z. B. durch gegenseitiges Senden von Signalen, müssen beide die gleiche Kritikalitätseinstufung haben.

Die Vererbungsregel R1 gewährleistet, daß eine einmal festgelegte Kritikalitätseinstufung eines Produkts im Verlaufe des Verfeinerungsprozesses in mindestens einem Verfeinerungszweig erhalten bleibt. Sie soll einen Designer dazu veranlassen, die Kritikalitätseinschätzung beim Entwurf möglichst genau zu lokalisieren.

Die Regel R2 soll ihn veranlassen, die Abhängigkeiten zwischen den Entwurfseinheiten zu minimieren. Dies entspricht einem wesentlichen Entwurfsprinzip für sichere, zuverlässige und wartbare Systeme.

SI.2.3 Maßnahmen zur Abwehr der Auswirkung von Fehlverhalten

Bei optimalen kritischen Pfaden kann die geforderte Sicherheit und Zuverlässigkeit durch Erhöhung der Kritikalität weiterer Funktionen nicht erhöht werden. Dadurch können die mit den jeweiligen Kritikalitätsstufen verbundenen Maßnahmen gezielt und mit besonderen Anstrengungen wahrgenommen werden. Diese Maßnahmen sind konstruktiver oder analytischer Natur. Sie haben das Ziel, die Zuverlässigkeit und Sicherheit auf unterschiedliche Art und Weise zu erhöhen :

Konstruktive Maßnahmen:
Entwicklung von eigensicheren bzw. fehlertoleranten Funktionseinheiten, Konfigurierung von redundanten oder diversitären1 Funktionseinheiten
Analytische Maßnahmen:
Durchführung umfangreicher Verifikation und Validation bis zur Zertifikationsreife

In dieser generellen Formulierung sind die Maßnahmen sowohl auf die Hardware bzw. die materiellen Funktionseinheiten (z. B. von den Schaltkreisen bis zu den Geräten) als auch auf die Software (z. B. von Prozeduren bis zu Prozessen) anwendbar.

Während die Einstufung der Kritikalität im Submodell SE erfolgt, geschieht im Rahmen der Aktivität QS1 - QS-Initialisierung die Zuordnung der erforderlichen Maßnahmen. Hierfür sind Vorgaben für die Erstellung und Prüfung von Produkten zu machen. Diese Vorgaben bestehen primär in der Festschreibung bestimmter Methoden, aber auch von Werkzeugvorgaben, wie die Produkte zu erstellen und zu prüfen ist. Für jede Kritikalitätsstufe ist vorzugeben, welche Maßnahmen (anzuwendende Methoden und/oder einzusetzende Werkzeuge) gefordert werden, um einem Fehlverhalten entgegenzuwirken. Diese Angaben lassen sich am besten in Matrizenform darstellen. Aus diesem Grunde werden die Erstellungs- und Prüfvorgaben bezüglich der Kritikalitätsstufen als Kritikalitäten/Methoden-Matrix bezeichnet. Diese Kritikalitäten/Methoden-Matrix ist im QS-Plan festzuschreiben.

Bei der Festlegung der projektspezifischen Kritikalitäten/Methoden-Matrix sind vertragliche Vereinbarungen und Vorgaben zu beachten, wie z. B. bezüglich Zertifizierungs-Richtlinien, Genehmigungs-Richtlinien, validierte Werkzeuge oder diversitäre Entwicklungen.

Die Vorgehensweise und das Zusammenspiel zwischen SE and QS skizziert Abbildung SI.1. Unter Beachtung der Regeln R1 und R2 wird in den Aktivitäten SE1 - System-Anforderungsanalyse bis SE4-SW - SW-Grobentwurf die Kritikalität der Funktionseinheiten bestimmt, verfeinert und in Kritikalitäten/Funktionen-Matrizen dargestellt.

Unter Verwendung der Kritikalitäten/Methoden-Matrix im QS-Plan werden,

die Konstruktionsvorgaben in eine Aufgabenplanung umgesetzt (Aktivitäten PM1 - Projektinitialisierung, PM4 - Feinplanung),
die Konstruktionsschritte durchgeführt (Aktivitäten SE1 - System-Anforderungsanalyse-SE6-SW - SW-Implementierung),
Prüfvorgaben festgeschrieben (Aktivität QS2 - Prüfungsvorbereitung),
Prüfungen durchgeführt (Aktivität QS4 - Produktprüfung),
geprüfte Produkte integriert (Aktivitäten SE7-SW - SW-Integration-SE8 - System-Integration),
integrierte SE-Produkte geprüft (Aktivität QS4 - Produktprüfung).

Abbildung SI.1: SE- und QS-Zusammenarbeit bezüglich der Kritikalität

Die folgende Tabelle SI.4 enthält beispielhafte Empfehlungen für die Aufstellung einer Kritikalitäten/Methoden-Matrix für Software-Produkte unter Berücksichtigung des heutigen und mittelfristig zu erwartenden Technologiestandes. Die Tabellen geben die Zuordnung nur als Vorschlag und ohne Berücksichtigung anwendungsspezifischer Aspekte wieder. So ist im allgemeinen Fall weder eine Prüfung mittels C1-Testabdeckung für eine unkritische Funktionseinheit ausgeschlossen noch eine Spezifikation nach streng mathematischen Methoden für eine hochkritische Funktionseinheit obligatorisch. Ist jedoch eine Festlegung wie im Beipiel der Tabelle SI.4 getroffen, so ist diese für das Projekt verbindlich.

Konstruktive Qualitätssicherungsmethoden
(Erstellungsmethoden) Kritikalitätsstufe
hoch mittel niedrig keine
SW-Anforderungen mit SADT punto punto punto
Grobentwurf mit HOOD punto punto punto
Feinentwurf mit HOOD PDL punto punto punto
Feinentwurf mit VDM (algebraisch) punto
Programmierrichtlinien XYZ befolgen punto punto punto punto
Strukturierte Programmierung punto punto punto punto
Verwendung eines validierten Compilers punto punto punto

Analytische Qualitätssicherungsmethoden
(Prüfmethoden) Kritikalitätsstufe
hoch mittel niedrig keine
Walkthrough punto punto punto punto
Audit für Aktivitäten laut QS-Plan punto punto punto
Durchschnittliche C1-Testabdeckung von mindestens 90 % punto punto punto punto
Durchschnittliche C2-Testabdeckung von mindestens 90 % punto punto punto
Informelle Prüfung gemäß Prüfspezifikation punto punto
Korrektheitsbeweis Code versus Feinentwurf punto
Stat. Analyse bzgl. Einhaltung der Programmierrichtl. XYZ punto punto punto punto
Simulation punto

Tabelle SI.4: Beispiel einer Kritikalitäten/Methoden-Matrix

Verknüpfungen mit der V-Modell Mailingliste

Mail 0343 - Re: Kritikalitaet u. Qualitaetsstufen
Mail 0341 - Re: Kritikalitaet u. Qualitaetsstufen
Mail 0340 - Kritikalitaet u. Qualitaetsstufen
Mail 0198 - Re: IT-Sicherheitskonzept (198)
Mail 0167 - Re: Kritikalitaet im Finanzbereich (167)

This page online • GDPA Online • Last Updated 03.Mar.2004 by C. Freericks