Previous Next V-Model Official Homepage by IABG  
Part 3: Collection of Manuals Homepage  
Sicherheit und Kritikalität  Homepage  

  SA. Safety and Criticality

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:

    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

    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.

    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.

    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.

    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.

    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 : 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,

    Abbildung SI.1
    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)

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