Previous Next V-Model Official Homepage by IABG  
Part 3: Collection of Manuals Homepage  
SEC  Homepage  

  SEC. Using the V-Model and the ITSEC

Inhalt  
  • SEC.1 Einleitung
  • SEC.2 Erläuterungen zum Submodell SE
  • SEC.3 Erläuterungen zum Submodell QS
  • SEC.4 Erläuterungen zum Submodell KM
  • SEC.5 Erläuterungen zum Submodell PM
  • Verknüpfungen mit der V-Modell Mailingliste
  • SEC.1 Einleitung

    In diesem Handbuch sollen die Aktivitäten und Produkte genannt werden, die für die Evaluation von Systemen relevant sind. Es wird beschrieben, was bei den einzelnen Aktivitäten speziell unter dem Aspekt Evaluation zu tun ist bzw. welche Inhalte bei den Produkten für die Evaluation erwartet werden.

    Für die verschiedenen E-Stufen kann es unterschiedliche Anforderungen bei den einzelnen Aktivitäten und Produkten geben. Auch sind nicht alle Aktivitäten und Produkte stets für jede E-Stufe der ITSEC gefordert. Diese Abweichungen werden bei den einzelnen Aktivitäten und Produkten entsprechend vermerkt. Bei den Aktivitäten und Produkten wird außerdem vermerkt, zu welchem Evaluationsdokument ihre Ergebnisse beitragen können.

    Bei nicht kommentierten Aktivitäten und Produkten konnte keine Relevanz für die Evaluation nach ITSEC festgestellt werden.

    SEC.2 Erläuterungen zum Submodell SE

    SE1 - System-Anforderungsanalyse
    SE1.1 - Ist-Aufnahme/-Analyse durchführen Falls bei einem vorhandenen System bereits Sicherheitsmaßnahmen existieren, müssen diese hinsichtlich eines neu vorgegebenen Sicherheitsziels und einer veränderten Einsatzumgebung analysiert und bewertet werden.
    SE1.2 - Anwendungssystem beschreiben Zusätzlich zu den operationellen Anforderungen an das System muß vom AG das Sicherheitsziel vorgegeben werden. Das Sicherheitsziel ist die Grundlage für die Erarbeitung der Sicherheitsanforderungen. Diese werden bei der Aktivität SE1.6 - Bedrohung und Risiko analysieren nach Durchführung einer Bedrohungs- und Risikoanalyse im Hinblick auf dieses Sicherheitsziel ermittelt

    Aufgrund der Sicherheitsanforderungen wird unter Berücksichtigung des tragbaren Restrisikos die angestrebte Stärke der Mechanismen für die Realisierung der Sicherheitsfunktionen und die angestrebte E-Stufe festgelegt.

    SE1.5 - System fachlich strukturieren Bei der fachlichen Strukturierung des Systems werden die IT-Maßnahmen des Sicherheitskonzepts umgesetzt in Sicherheitsfunktionen, die den Bedrohungen entgegenwirken können. Diese Funktionen werden als "sicherheitsspezifische Funktionen" bezeichnet, da sie direkt zur Sicherheit des Systems beitragen. Diese Sicherheitsfunktionen, die zur Abwehr von Bedrohungen gewählt werden, können einer vordefinierten Funktionalitätsklasse der ITSEC entsprechen, können aber auch völlig frei definierte Sicherheitsfunktionen sein.

    Die Sicherheitsfunktionalität ist abzugrenzen von der übrigen operationellen Funktionalität.

    SE1.6 - Bedrohung und Risiko analysieren Auf der Basis der operationellen Anforderungen und im Hinblick auf das Sicherheitsziel, das erreicht werden soll, werden gemäß IT-Sicherheitshandbuch oder AU 248 die Bedrohungen festgestellt und die jeweiligen Risiken ermittelt. Es werden diejenigen Bedrohungen als relevant eingestuft, die ein nicht akzeptables Risiko (Eintrittswahrscheinlichkeit einer Bedrohung und Schadenshöhe) bergen.

    Um diese als relevant eingestuften Bedrohungen abzuwehren, müssen geeignete Maßnahmen ergriffen werden. Solche Maßnahmen können IT-Maßnahmen sein, aber auch Maßnahmen administrativer, organisatorischer, personeller oder infrastruktureller Art. Die Gesamtheit dieser Maßnahmen bildet das Sicherheitskonzept. Die Entwicklung der Nicht-IT-Maßnahmen wird nicht weiter durch das V-Modell geregelt. Sie werden aber sehr wohl bei der Evaluation berücksichtigt, da sie zur Sicherheit des Systems beitragen.

    Die IT-Maßnahmen werden realisiert durch Sicherheitsfunktionen. Diese Sicherheitsfunktionen benötigen eine bestimmte Vertrauenswürdigkeit, die sowohl durch die Stärke des Mechanismus als auch durch die Qualität ihrer Realisierung (E-Stufe) bestimmt wird. Die Bestimmung der Mechanismenstärke und der E-Stufe für die Sicherheitsfunktionen liegt außerhalb der Regelungen durch das V-Modell.

    SE2 - System-Entwurf
    SE2.1 - System technisch entwerfen Neben den sicherheitsspezifischen Funktionen wird es auch solche Funktionen geben, deren korrektes Verhalten für die Sicherheitsfunktionen unerläßlich ist. Diese Funktionen tragen indirekt zur Sicherheit bei, wenn sich eine oder mehrere Sicherheitsfunktionen auf diese Funktionen verlassen. Deshalb werden sie als "sicherheitsrelevante Funktionen" bezeichnet.

    Beim Entwurf des Systems ist darauf zu achten, daß sowohl die Sicherheitsfunktionen selbst als auch die sicherheitsrelevanten Funktionen von der Software, die als nicht sicherheitsrelevant angesehen wird, ausreichend abgegrenzt werden, indem die Anzahl der Schnittstellen so klein wie möglich gehalten wird. Die Notwendigkeit jeder Schnittstelle ist zu beschreiben und zu begründen. Es ist auch darauf zu achten, daß der Umfang des gesamten Sicherheitsanteils (sicherheitsspezifische und sicherheitsrelevante Funktionen), der Gegenstand der Evaluation ist, so klein wie möglich gehalten wird (Minimierung des vertrauenswürdigen Anteils).

    Die Schnittstellen zur Einsatzumgebung sind exakt zu beschreiben.

    SE2.3 - Realisierbarkeit untersuchen Die Abgrenzbarkeit des sicherheitsrelevanten Teils vom nicht sicherheitsrelevanten Teil ist zu prüfen.

    Die Machbarkeit der angestrebten E-Stufe ist zu prüfen. Ein Kriterium für die Realisierbarkeit einer hohen E-Stufe ist auch die erwartete Komplexität des Sicherheitsanteils.

    Es sind aber auch Überlegungen bezüglich der Wirtschaftlichkeit einer vorgegebenen E-Stufe anzustellen. Die Untersuchungen, die durchzuführen sind, müssen unter Berücksichtigung des tragbaren Restrisikos die Kosten, die für eine bestimmte E-Stufe entstehen, abwägen gegen die möglichen Schäden, die bei Wirksamwerden der Bedrohungen eintreten.

    SE2.4 - Anwenderforderungen zuordnen Es ist der Nachweis zu erbringen, daß sämtliche Sicherheitsanforderungen im Sicherheitskonzept (IT- Maßnahmen und Nicht-IT-Maßnahmen) berücksichtigt werden. Das erleichtert u. a. die Feststellung des noch vorhandenen Restrisikos.
    SE2.6 - System-Integration spezifizieren Es muß spezifiziert werden, wie die Integration des sicherheitsrelevanten Teils, der begleitend oder später evaluiert werden soll, in den Teil, der nicht evaluiert werden soll, zu erfolgen hat.
    SE3 - SW-/HW-Anforderungsanalyse
    SE3.1 - Allgemeine Anf. aus Sicht der SW-/HW-Einheit def. Es ist zu prüfen, ob sich der sicherheitsrelevante Teil auf diese SW-/HW-Einheit auswirkt, d. h. ob bestimmte sicherheitsspezifische oder -relevante Funktionen in dieser SW-/HW-Einheit realisiert werden müssen.
    SE3.2 - Anf. an die externen Schnittst. der SW-/HW-Einheit präz. Falls sich sicherheitsspezifische oder -relevante Funktionen in dieser SW-/HW-Einheit befinden, muß eine exakte Schnittstellenbeschreibung zum restlichen sicherheitsspezifischen oder sicherheitsrelevanten Teil, der in anderen SW-/HW-Einheiten verstreut sein kann, vorliegen. Es muß das Zusammenwirken dieser Funktionen mit den anderen über diese Schnittstelle beschrieben werden.
    SE3.3 - Anf. an die Funktionalität definieren Es sind die Anforderungen an die Sicherheitsfunktionen und die dafür notwendigen Daten zu erstellen.
    SE3.4 - Anf. an die Qualität der SW-/HW-Einheit definieren Falls die SW-/HW-Einheit einen sicherheitsrelevanten Teil enthält, ist dieser mit der vorgegebenen E-Stufe zu realisieren
    SE3.5 - Anf. an Entwicklungs- und SWPÄ-Umgebung definieren Die verschiedenen E-Stufen haben unterschiedliche Anforderungen an die Entwicklungsumgebung.

    Anforderungen werden gestellt an den Einsatz von Methoden und Werkzeugen wie

    • die Methode der Spezifikation und die Spezifikationssprache,
    • die Programmiersprache und den eingesetzten Compiler,
    • das Konfigurationsmanagement und die Leistungsfähigkeit eines Werkzeugs zur Konfigurationskontrolle.
    Forderungen werden auch gestellt bezüglich der Möglichkeit, innerhalb der Entwicklungsumgebung verschiedene Benutzer und Rollen unterscheiden zu können und deren Accountability sicherzustellen, um
    • Benutzer für Aktivitäten und Aktionen autorisieren zu können,
    • Rollentrennung zur Durchführung von Aktivitäten zu ermöglichen,
    • die Nachweisbarkeit von Aktivitäten und Aktionen während des Entwicklungsprozesses zu ermöglichen.
    SE4 - SW-Grobentwurf
    SE4.1 - SW-Architektur entwerfen Diese Aktivität ist für alle E-Stufen erforderlich. Die Art der geforderten Darstellung ist für die verschiedenen E-Stufen unterschiedlich. Sie reicht von einer informellen Beschreibung bis zur Notwendigkeit einer formalen Notation.

    Die Bedrohungs- und Risikoanalyse ist fortzuschreiben. Es ist zu untersuchen, ob durch die Verfeinerung neue Bedrohungen und Risiken auftreten.

    Bei den Stufen E1 bis E3 wird eine informelle Beschreibung der Architektur gefordert.

    Es gibt zwischen diesen drei E-Stufen allerdings unterschiedliche Anforderungen, wie präzise die Aufteilung in sicherheitsrelevante und andere Komponenten dargestellt und das Erreichen der Trennung beschrieben werden muß.

    Bei den Stufen E4 bis E5 wird eine semiformale Beschreibung des sicherheitsrelevanten Teils gefordert.

    Zwischen diesen beiden E-Stufen gibt es ebenfalls unterschiedliche Anforderungen bzgl. Detaillierungsgrad dieser semiformalen Darstellung. Sie bezieht sich vor allem auf die größtmögliche Unabhängigkeit der sicherheitsspezifischen Komponenten und die inhärent bestehenden Abhängigkeiten.

    Bei der Sufe E6 wird eine formale Beschreibung des sicherheitsrelevanten Teils verlangt.

    SE4.2 - SW-interne und -externe Schnittstellen entwerfen Alle Schnittstellen der sicherheitsspezifischen und sicherheitsrelevanten SW-Komponenten/Prozesse/SW-Module müssen mit ihrem Zweck und ihren Parametern beschrieben werden. Die Separierung vom nicht sicherheitrelevanten Teil muß sichtbar sein. Die Schnittstellen sind zu minimieren. Der Einsatz von bestimmten Beschreibungsmethoden ist von der E-Stufe abhängig.
    SE4.3 - SW-Integration spezifizieren Die Integration des sicherheitsrelevanten Teils, der evaluiert werden soll, in den Teil, der nicht evaluiert werden soll, muß spezifiziert sein.
    SE5 - SW-Feinentwurf
    SE5.1 - SW-Komponente/-Modul/Datenbank beschreiben Ab der Evaluationsstufe E2 darf der Feinentwurf im Rahmen des Tailoring nicht mehr entfallen.

    Bei den Stufen E2 und E3 ist eine informelle Beschreibung des Sicherheitsanteils des Feinentwurfs ausreichend.

    Bei den Stufen E4 bis E6 ist eine semiformale Beschreibung des Sicherheitsanteils des Feinentwurfs erforderlich.

    Es muß ein Abgleich des Feinentwurfs bzgl. des Grobentwurfs durchgeführt werden.

    SE5.2 - Betriebsmittel- und Zeitbedarf analysieren Dieser Aspekt kann evtl. für die Sicherheitsvorgaben relevant sein.
    SE6 - SW-Implementierung
    SE6.3 - Selbstprüfung des SW-Moduls/der Datenbank durchf. Es muß ein Abgleich des Codes bzgl. des Feinentwurfs durchgeführt werden.
    SE8 - System-Integration
    SE8.2 - Selbstprüfung des Systems durchführen Das Zusammenwirken der Mechanismen ist zu untersuchen, und es müssen Penetrationsanalysen durchgeführt werden.
    SE8.3 - Produkt bereitstellen Die korrekte Anwendung der Sicherheitsfunktionen durch den Sicherheitsverantwortlichen und die Benutzer muß gewährleistet werden. Deshalb sind diese Informationen in die entsprechenden Handbücher zur Systemverwalter- und Benutzerdokumentation aufzunehmen.

    SEC.3 Erläuterungen zum Submodell QS

    QS1 - QS-Initialisierung Bis E3 ist ein manuelles Konfigurationsmanagement möglich.

    Ab E4 ist ein werkzeuggestütztes Konfigurationsmanagement erforderlich.

    Eine strikte Rollentrennung zwischen Entwicklung und QS ist ab E5 zwingend vorgeschrieben.

    QS2 - Prüfungsvorbereitung
    QS2.1 - Prüfmethoden und -kriterien festlegen Als Prüfkriterien für die Sicherheitsfunktionen sind zu berücksichtigen:
    • Zusammenwirken der Sicherheitsfunktionen
    • Wirksamkeit der Mechanismen
    • Abgrenzung, dh. Schnittstellen zu nicht vertrauenswürdiger Software
    Als Prüfmethoden für die Sicherheitsfunktionen sind zu berücksichtigen:
    • Schwachstellenanalyse
    • Wirksamkeitsanalyse
    • Penetrationstest
    QS4 - Produktprüfung
    QS4.2 - Produkt inhaltlich prüfen Laufzeitbibliotheken werden in das System oder Produkt mit eingebunden und sind entsprechend der angestrebten Evaluationsstufe zu behandeln.

    SEC.4 Erläuterungen zum Submodell KM

    KM1 - KM-Planung Konfigurationskontrolle ist bei allen E-Stufen erforderlich. Ab der Stufe E4 muß sie werkzeuggestützt erfolgen.

    Für E6 müssen nicht nur die sicherheitsrelevanten Produkte, sondern auch die eingesetzten Werkzeuge der Konfigurationskontrolle unterliegen.

    KM2 - Produkt- und Konfigurationsverwaltung Ab der Stufe E4 muß sie werkzeuggestützt erfolgen. Die Anforderungen an die Leistungsfähigkeit dieses Werkzeugs wachsen bei jeder Evaluationsstufe.
    KM3 - Änderungsmanagement (Konfigurationssteuerung)
    KM3.3 - Änderung abschließen Ab E4 muß eine Protokollinformation über Änderungen aller Produkte, die der Konfigurationskontrolle unterliegen, vorgelegt werden.

    SEC.5 Erläuterungen zum Submodell PM

    PM1 - Projektinitialisierung
    PM1.2 - Projektkriterien und Entwicklungsstrategie festlegen Eine wesentliche Festlegung ist, ob das zu erstellende System oder Produkt evaluiert werden soll. Nur dann sind die ITSEC-Kriterien relevant und einzuhalten.

    Ab der Evaluationsstufe E5 müssen die Laufzeitbibliotheken im Quellcode zur Verfügung gestellt werden. Deshalb muß vorab geklärt werden, ob der Compiler-Hersteller bereit ist, die Quellen an die Evaluationsstelle zur Einsichtnahme auszuliefern

    PM1.3 - Projektspezifisches V-Modell erstellen Ein endgültiges projektspezifisches V-Modell kann erst dann erstellt werden, wenn die angestrebte E-Stufe feststeht.
    PM1.4 - Toolset-Management durchführen Bei den einzelnen E-Stufen sind Mindestanforderungen an Methoden und Werkzeuge definiert.
    PM1.5 - Grobplan erstellen Da ab der Evaluationsstufe E4 oder höher spezielle Anforderungen an den Enwicklungsvorgang und an die Enwicklungsumgebung gestellt werden, muß rechtzeitig für die Verfügbarkeit der speziellen Werkzeuge, die über die geforderte Funktionalität bzw. Qualität verfügen, gesorgt werden.

    Es muß erfahrenes Personal vorhanden sein, das eine Analyse des Zusammenwirkens der gewählten Sicherheitsfunktionen durchführen kann. Ebenso muß es imstande sein, Wirksamkeitsanalysen für die Mechanismen, die zur Implementierung der Sicherheitsfunktionen gewählt wurden, durchzuführen.

    Bei höheren E-Stufen muß die Verfügbarkeit des Personals, das über entsprechende Erfahrung im Umgang mit semiformalen bzw. formalen Spezifikationen verfügt, gewährleistet sein.

    Soll eine begleitende Evaluation durchgeführt werden, muß die Mitarbeit der Evaluatoren und des BSI bei der Planung ebenfalls berücksichtigt werden.

    PM10 - Schulung/Einarbeitung Falls die Projektmitarbeiter kein entsprechendes Wissen und keine entsprechende Erfahrungen in den notwendigen Kenntnissen (siehe Aktivität PM 1.3) für die Entwicklung nach einer bestimmten E-Stufe besitzen, müssen sie entsprechend geschult werden. Eine Sensibilisierung bzgl. Sicherheit ist erforderlich.

    Verknüpfungen mit der V-Modell Mailingliste

    Mail 0399 - Re: Evaluierungsstufen (399)
    Mail 0343 - Re: Kritikalitaet u. Qualitaetsstufen
    Mail 0341 - Re: Kritikalitaet u. Qualitaetsstufen
    Mail 0340 - Kritikalitaet u. Qualitaetsstufen

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