Deutsche IT-Sicherheitskriterien

1. Version 1989 - i -

Vorwort

In der Wirtschaft und in der öffentlichen Verwaltung spielt die Informationstechnikbereits heute eine wichtige Rolle. Innerhalb des nächsten Jahrzehnts wird ihreWeiterentwicklung eine Vielzahl neuer Anwendungsmöglichkeiten eröffnen und zueinem erheblich erweiterten Einsatz informationstechnischer Systeme führen. Damitwerden Wirtschaft und Verwaltung zunehmend von dem einwandfreien Funktionierenund der uneingeschränkten Verfügbarkeit informationstechnischer Systeme abhängig.Zugleich ist mit der Zunahme von Risiken zu rechnen, die die Vertraulichkeit derDaten des einzelnen Bürgers wie die der Wirtschaft und des Staates gefährden.

Um einen sicheren Umgang mit Daten und informationsverarbeitenden Systemen zugewährleisten, ist es erforderlich, der jeweiligen Gefährdungslage entsprechendeSicherheitsstandards einzuhalten. Als einheitliche "Meßlatte" zur Beurteilung derSicherheit informationstechnischer Systeme wurden im Auftrag der Bundesregierungunter Beteiligung von Wirtschaft und Wissenschaft "IT-Sicherheitskriterien"erarbeitet. Sie sind eine Fortentwicklung des in Fachkreisen bekannten "OrangeBook" (Originaltitel: Trusted Computer System Evaluation Criteria) des US-amerikanischen Department of Defense (DoD) und stehen allen Stellen, die sich mitFragen der Sicherheit informationstechnischer Anwendungen befassen, zur Verfügung.

Verantwortlich für die "IT-Sicherheitskriterien" und ihre Fortschreibung zeichnet die"Zentralstelle für Sicherheit in der Informationstechnik (ZSI)", die zudem beauftragtist, informationstechnische Systeme anhand dieser Kriterien auf ihre Sicherheit zuprüfen und zu bewerten. Sie kann auch andere geeignete Stellen autorisieren,bestimmte Prüfungen ganz oder in Teilen durchzuführen. Produkte, die die Prüfungerfolgreich durchlaufen, erhalten ein Sicherheitszertifikat.

Einzelheiten über die Durchführung von Prüfungen (Rahmenbedingungen,Prüfmethoden, usw.) und die Vergabe von Sicherheitszertifikaten enthält ein "IT-Evaluationshandbuch", das in Kürze ebenfalls veröffentlicht wird. Es soll vor allemauch eine Gleichbehandlung sowohl der an einem Zertifikat interessierten Herstellerals auch der zu prüfenden Produkte gewährleisten.

Ferner ist ein "IT-Sicherheitshandbuch" in Vorbereitung, mit dem die Anwender aufdie bestehenden Gefahren hingewiesen und in die Lage versetzt werden sollen,system- und anwendungsbezogene Sicherheitskonzepte zu entwickeln und umzusetzen.In diesen Sicherheitskonzepten sind alle erforderlichen Sicherheitsvorkehrungen(organisatorische, personelle, technische und bauliche) zusammenzufassen undaufeinander abzustimmen. Der jeweilige Anwender oder Vorschriftengeber bestimmt,welches Maß an Sicherheit und welcher technische Sicherheitsstandard im Einzelfallgeboten sind.

- ii - 1. Version 1989

Mit den genannten Maßnahmen werden die Rahmenbedingungen für die Entwicklungund den Einsatz gesicherter informationstechnischer Systeme für alle Anwendungs-bereiche geschaffen.

Dem Sicherheitsstandard dieser Systeme kommt auch im internationalen Wettbewerbzunehmend Bedeutung zu. Im Hinblick darauf, vor allem aber als Beitrag zurVerwirklichung des europäischen Binnenmarktes, ist die schnellstmöglicheEntwicklung internationaler, zumindest aber europäischer Sicherheitsstandardsgeboten. Initiativen mit diesem Zweck wurden bereits eingeleitet. Sie werden mitNachdruck weiterverfolgt.

Der Bundesminister Der Bundesminister des Innern für Wirtschaft

Dr. Wolfgang Schäuble Dr. Helmut Haussmann

1. Version 1989 - iii -

Zusammenfassung

Die hier vorgelegten IT-Sicherheitskriterien sind für die Bewertung der Sicherheitvon Systemen der Informationstechnik (IT) entwickelt worden. Die IT-Sicherheitskriterien werden durch das IT-Evaluationshandbuch ergänzt. Es enthälteine Vielzahl von Erläuterungen, die den Umfang dieses Kataloges sprengen würden.

Der vorliegende Katalog der IT-Sicherheitskriterien ist in sechs Kapitel eingeteilt.

Kapitel 1 gibt eine Einführung in die Zielrichtung der Kriterien. Dabei wirdbesonders Bezug genommen auf die Schwierigkeit, die Sicherheit eines Systemsobjektiv zu bewerten.

Kapitel 2 legt die Grundlagen der IT-Sicherheitskriterien dar, welche ihre Strukturund ihren Inhalt formen. Dies sind die drei Grundbedrohungen:

Verlust der Vertraulichkeit,Verlust der Integrität,Verlust der Verfügbarkeit.

Darauf aufbauend wird der Begriff der Sicherheitsanforderungen abgeleitet, die derBenutzer eines Systems erfüllt haben will.

Kapitel 3 gibt eine detaillierte Einführung in die Grundfunktionen "Sicherer Systeme".Diese sind die "Identifikation und Authentisierung", "Rechteverwaltung","Rechteprüfung", "Beweissicherung", "Wiederaufbereitung", "Fehlerüberbrückung","Gewährleistung der Funktionalität" und die "Übertragungssicherung". Die ersten vierleiten sich aus Überlegungen zum Begriff "Recht" ab. Die folgenden sind notwendig,da Systeme auf einem technischen Gerät ablaufen, das erstens nicht fehlerfrei seinkann und zweitens über endliche Betriebsmittel verfügt. Die Grundfunktion"Datenübertragungssicherung" wird dann notwendig, wenn Daten den Einflußbereichder anderen Grundfunktionen verlassen.

Kapitel 4 beschreibt für jede Grundfunktion die wichtigen Punkte, die einMechanismus zu erfüllen hat, um eine bestimmte Güte zugesprochen zu bekommen.Die Bewertung der Güte der Mechanismen kann zum Ergebnis "ungeeignet","schwach", "mittelstark", "stark", "sehr stark" und "nicht überwindbar" führen. Sie hatdirekten Einfluß auf die Bewertung der Sicherheit.

- iv - 1. Version 1989

Kapitel 5 beschreibt zehn unterschiedliche Funktionalitätsklassen. Die ersten fünfbeschreiben die Sicherheitsanforderungen, die sich aus dem "Orange Book"(Originaltitel: Trusted Computer System Evaluation Criteria) des US-amerikanischenDepartment of Defense (DoD) und den dort definierten Klassen ableiten lassen. Dierestlichen zeigen exemplarisch unterschiedliche Zusammenfassungen vonSicherheitsanforderungen auf, die von verschiedenen Systemen zu erfüllen sind. DieAnzahl der Funktionalitätsklassen ist nicht beschränkt, damit können auch in derZukunft entstehende Systeme leichter mit diesem Katalog bewertet werden, da keinevorgefaßten Annahmen über die zu erfüllenden Sicherheitsanforderungen bestehen.

Kapitel 6 beinhaltet eine detaillierte Auflistung der Kriterien, die die Bewertung derSicherheit eines Systems erlauben. Die acht erarbeiteten Qualitätsstufen sindhierarchisch geordnet, wobei Q0 jene Stufe ist, die für Systeme gilt, die dieAnforderungen der höheren Stufen nicht erfüllen. Die Hauptmerkmale, die in dieBewertung eingehen, sind:

Qualität der Sicherheitsanforderungen,Qualität der Spezifikation der zu evaluierenden Systemteile,Qualität der verwendeten Mechanismen,Qualität der Abgrenzung zu nicht zu evaluierenden Systemteilen,Qualität des Herstellungsvorganges,Betriebsqualität,Qualität der Anwenderdokumentation.

Dabei wird unterschieden, welche Anforderungen der Hersteller zu erfüllen hat undwie die Evaluationsbehörde den Erfüllungsgrad prüft.

Mit diesem Katalog können nur Aussagen hinsichtlich des Erfüllungsgrades derSicherheitsanforderungen gemacht werden. Die IT-Sicherheitskriterien sind nichtdazu geeignet, die Gesamtfunktionalität eines IT-Systems zu bewerten.

Ein Glossar der wichtigsten in den IT-Sicherheitskriterien verwendeten Begriffe,sowie eine tabellarische Übersicht der hierarchischen Funktionalitätsklassen F1 bisF5 und der Qualitätsstufen Q1 bis Q7 vervollständigen den Katalog.

Die vorliegende Ausgabe (1. Fassung vom 11. Januar 1989) der IT-Sicherheitskriterien wird infolge der ständig fortschreitenden Entwicklung auf deminformationstechnischen Sektor laufender Überarbeitung bedürfen. Der Herausgeberist daher jederzeit an Verbesserungsvorschlägen und konstruktiven Anregungeninteressiert.

1. Version 1989 - 1 -

Inhaltsverzeichnis

Vorwort i

Zusammenfassung iii

Inhaltsverzeichnis 1

1. Zielrichtung der IT-Sicherheitskriterien 3

2. Grundlagen der IT-Sicherheitskriterien 5

3. Grundfunktionen sicherer Systeme 8

3.1 Identifikation und Authentisierung 8

3.2 Rechteverwaltung 8

3.3 Rechteprüfung 9

3.4 Beweissicherung 9

3.5 Wiederaufbereitung 10

3.6 Fehlerüberbrückung 10

3.7 Gewährleistung der Funktionalität 10

3.8 Übertragungssicherung 11

4. Mechanismen 14

4.1 Identifikation und Authentisierung 16

4.2 Rechteverwaltung 19

4.3 Rechteprüfung 20

4.4 Beweissicherung 21

4.5 Wiederaufbereitung 21

4.6 Fehlerüberbrückung 22

4.7 Gewährleistung der Funktionalität 23

4.8 Übertragungssicherung 24

- 2 - 1. Version 1989

5. Funktionalitätsklassen 27

Funktionalitätsklasse F1 27










6. Qualitätskriterien und Qualitätsstufen 49

6.1 Einzelaspekte der Qualitätskriterien 49

6.2 Charakterisierung der Qualitätsstufen 54

6.3 Detaillierte Beschreibung der einzelnen Qualitätsstufen 56

Vorbemerkungen 56

Qualitätsstufe Q0 57








Glossar 101

Tabellen 105

1. Version 1989 - 3 -

1. Zielrichtung der IT-Sicherheitskriterien

Die Bedeutung der Informationstechnik nimmt in allen Bereichen der Gesellschaftständig zu. Damit wächst auch gleichzeitig die Abhängigkeit von der elektronischenDatenverarbeitung und insbesondere die Gefahr des Mißbrauchs.Es ist daher unabdingbar, die möglichen Bedrohungen zu analysieren underforderliche Sicherheitsvorkehrungen zu ergreifen. Um das Vertrauen in dieWirksamkeit solcher Vorkehrungen zu erlangen, muß deren Qualität beurteilbar sein.Dies kann geschehen

- indem man dem Hersteller dieses Produktes und seiner Qualitätssicherung vertraut,oder

- indem man das Produkt selbst in ausreichender Form prüft, oder

- indem das Produkt von einer Institution geprüft wird, zu der man selbstausreichendes Vertrauen besitzt.

Will man eine objektive Vertrauensbildung sicherstellen, so bleibt nur der dritte Weg:Die Prüfung durch eine neutrale und vertrauenswürdige Institution. UmfassendeAkzeptanz der Prüfmethodik macht es erforderlich, daß die Produktprüfung sotransparent wie möglich erfolgt.Diesem Ziel dienen die vorliegenden Sicherheitskriterien. Sie werden von derEvaluationsbehörde veröffentlicht. Alle Betroffenen, insbesondere Hersteller undBetreiber von IT-Systemen, haben damit eine gemeinsame Arbeitsgrundlage.

Bei der Konzeption dieses Kataloges waren folgende prinzipielle Fragen zu klären:

1. Wie bewertet man die Qualität von Sicherheitsvorkehrungen ?

2. Wie weist man nach, daß die gewählten Sicherheitsvorkehrungen ausreichendsind, das System vor allen realen Sicherheitsbedrohungen zu schützen ?

zu 1) Der in den vorliegenden IT-Sicherheitskriterien aufgezeigte Lösungsweg be-schreibt das Bewertungsschema für Sicherheitsvorkehrungen. Damit wird dieSystemprüfung sowohl für den Hersteller als auch für den Anwender von IT-Systemen transparent. Die Kriterien definieren 8 verschiedene Qualitätsstufenmit steigenden Anforderungen an Art und Umfang der Prüfung. Dadurch ist esmöglich, ein IT-System je nach der Stärke der Sicherheitsfunktionen, denverwendeten Mechanismen und der Qualität der Implementierung mit Hilfe dervorliegenden Kriterien in eine entsprechende Qualitätsstufe einzuordnen.

zu 2) Um die Vollständigkeit der gewählten Sicherheitsvorkehrungen nachzuweisen,ist zuvor eine Analyse der vorhandenen Bedrohungen erforderlich. Diese sindjedoch von System zu System sowohl in Art als auch im Umfang sehr

- 4 - 1. Version 1989

unterschiedlich und von vielen Faktoren abhängig. Daher beschäftigt sich dasdritte Kapitel dieses Kataloges einerseits mit den typischen Grundfunktionensicherer Systeme, andererseits mit der Frage, wie die für ein Systemnotwendigen Sicherheitsfunktionen gefunden werden können. Dieser Teil desKataloges richtet sich weniger an die prüfende Institution, als vielmehr anHersteller und Anwender von IT-Systemen. Die Bedrohungen, denen einSystem ausgesetzt ist, lassen sich nur in seiner Einsatzumgebung analysieren.Soweit einzelne Bedrohungen für den Einsatzzweck des Systems relevant sind,ergeben sich hieraus Sicherheitsanforderungen, die dann unter Zuhilfenahmedieses Kataloges in der Forderung nach einer Funktionalitätsklasse undQualitätsstufe münden.

Neben den IT-Sicherheitskriterien gibt die Evaluationsbehörde folgende Dokumenteheraus:

- IT-Evaluationshandbuch mit der Beschreibung des eigentlichen Prüfvorganges,

- IT-Sicherheitshandbuch mit Leitlinien für dieSicherheitserfordernisse bei Anwendung der Informationstechnik im konkretenEinzelfall.

1. Version 1989 - 5 -

2. Grundlagen der IT-Sicherheitskriterien

Ausgangspunkt für Sicherheitsanforderungen an ein IT-System sind immer dieBedrohungen, denen dieses System ausgesetzt ist. Die Bedrohungen selbst sindeinerseits wieder abhängig von der Umwelt, in der das System betrieben wird,andererseits von der Sensitivität der im System verarbeiteten Informationen.Betrachtet man die drei Grundbedrohungen, denen ein IT-System ausgesetzt ist,nämlich

- unbefugter Informationsgewinn(Verlust der Vertraulichkeit)

- unbefugte Modifikation von Informationen(Verlust der Integrität)

- unbefugte Beeinträchtigung der Funktionalität(Verlust der Verfügbarkeit)

so stellt man fest, daß diese Bedrohungen für unterschiedliche IT-Systeme auch sehrunterschiedlich gewichtet sein können. Für manche Systeme (z. B. öffentlicheDatenbanken) stellt unbefugter Informationsgewinn keine oder nur eine sehr geringgewichtete Bedrohung dar, während dies für andere Systeme (z. B. militärischeFührungsinformationssysteme) eine extrem große Bedrohung ist. Ähnliche Beispielelassen sich auch für die anderen beiden Grundbedrohungen finden.

Nun läßt sich ein Teil dieser Bedrohungen durch Maßnahmen verringern, die dieUmwelt, in der das IT-System betrieben wird, so gestalten, daß diese Bedrohungen imIT-System selbst nicht mehr zum Tragen kommen. Dies können z. B. Maßnahmen sein,die den Personenkreis einschränken, der Zugang zum Rechner bzw. zu Datenträgernbesitzt, oder auch Maßnahmen, die den Zu- und Abgang von Personen und Material inder Umwelt des Rechners überwachen und protokollieren. Nur der dann nochverbleibenden Restbedrohung muß durch technische Maßnahmen im IT-Systembegegnet werden. Diese Restbedrohung hängt also von der Aufgabe des Systems, vonder Sensitivität der im System verarbeiteten Informationen sowie von der Umwelt desSystems inklusive der dort ergriffenen technischen oder organisatorischenSchutzmaßnahmen ab. Dies bedeutet aber, daß auch diese Restbedrohung imallgemeinen von System zu System sehr unterschiedlich ist. Entsprechendunterschiedlich müßten demnach auch die Sicherheitsanforderungen und die darausabgeleiteten Sicherheitsfunktionen im IT-System selbst sein. Es ist jedoch wedersinnvoll noch möglich, für jedes System einen eigenen speziellen Satz vonSicherheitsfunktionen zu entwickeln und zu implementieren. Vielmehr muß das Systemso ausgewählt werden, daß die in ihm vorhandenen Sicherheitsfunktionen dieSicherheitsanforderungen, die sich aus der Bedrohungsanalyse ergeben, vollständigabdecken. Dabei ist darauf zu achten, daß die eventuell zusätzlich vorhandenenSicherheitsfunktionen nicht im Widerspruch zu der geforderten Funktionalität des Sy-stems stehen.

- 6 - 1. Version 1989

Um dem Anwender die Auswahl eines Systems zu erleichtern, sind in diesem Katalogeine Reihe von Funktionalitätsklassen für Sicherheitsfunktionen definiert. JedeFunktionalitätsklasse ist eine Zusammenstellung von Sicherheitsfunktionen, die ineinem IT-System in dieser Kombination vorkommen können. In vielen Fällen kann einAnwender dadurch eine Klasse finden, die alle von ihm für sein auszuwählendesSystem aufgestellten Sicherheitsanforderungen abdeckt. Möglich ist auch, daß ersteine Kombination verschiedener Klassen seine Sicherheitsanforderungen abdeckt.Somit sind für ihn alle Systeme geeignet, die von der Evaluationsbehörde in dieseFunktionalitätsklassen sowie einer seinem geforderten Maß an Vertrauenentsprechenden Qualitätsstufe evaluiert worden sind. Zusätzlich zur Einordnung ineine oder mehrere Funktionalitätsklassen werden viele reale IT-Systeme noch weitereSicherheitsanforderungen erfüllen. Entspricht nun keine der in den Kriterienaufgeführten Funktionalitätsklassen den Sicherheitsanforderungen des Anwenders, somuß er seine Sicherheitsanforderungen mit denen der bisher evaluierten Systeme inallen Einzelpunkten vergleichen, um eventuell ein seinen Anforderungen genügendesSystem auswählen zu können. Um auch in diesem Fall die Auswahl eines Systems zuerleichtern, wird ein Satz von Grundfunktionen definiert, durch die alleSicherheitsanforderungen abgedeckt werden können. Zu jeder Grundfunktion werdeneine Reihe von Forderungen aufgezählt, die bei der Aufstellung detaillierterSicherheitsanforderungen für ein System von Bedeutung sein können. DieseAufzählung kann sowohl vom Anwender als Leitlinie zur Bestimmung derSicherheitsanforderungen an ein zu beschaffendes System, als auch vom Hersteller zurCharakterisierung der in seinem System realisierten Sicherheitsvorkehrungenverwendet werden.Im Evaluationsbericht eines Systems werden daher nicht nur die abgedecktenFunktionalitätsklassen sowie die erreichte Qualitätsstufe niedergelegt, sondern erenthält auch eine detaillierte Aufzählung, welche der bei den Grundfunktionenaufgezählten Einzelpunkte betrachtet wurden und in welcher Form sie im Systemrealisiert sind.

Das nachfolgende Diagramm soll noch einmal verdeutlichen, wie man bei derAufstellung von Sicherheitsanforderungen sowie bei der Bestimmung desnotwendigen Maßes an Vertrauen vorgehen sollte. Dabei ist unter Umständen einmehrfaches Durchlaufen des Zyklus notwendig, d. h. es kann durchaus vorkommen,daß man nach dem ersten Durchlauf feststellt, daß kein System die notwendigeFunktionalität und Qualität bietet. Dann muß man entweder die Bedrohungen durchorganisatorische Maßnahmen außerhalb des Systems verringern oder die funktionalenAnforderungen an das System zurückschrauben und danach erneut dieSicherheitsanforderungen sowie die erforderliche Qualitätsstufe bestimmen.

1. Version 1989 - 7 -

Abhängigkeiten bei der Festlegung derSicherheitsanforderungen sowie der erforderlichenImplementierungsqualität

Umwelt Einsatzumgebung

Bedrohung

Sicherheitsbedarf

Sicherheitsanforderungen

Grundfunktionen

Mechanismen

Funktionale

Anforderungen

Sicherheitsrichtlinien

Technische und

qualitative Anforderungen

an die Implementierung

- 8 - 1. Version 1989

3. Grundfunktionen sicherer Systeme

Die in diesem Kapitel aufgezählten Grundfunktionen sind ausreichend, ein sehr weitesSpektrum von Sicherheitsanforderungen abzudecken. In vielen Fällen werden dieSicherheitsanforderungen jedoch so gestaltet sein, daß zu ihrer Realisierung nicht alleder aufgezeigten Grundfunktionen benötigt werden.Dieses Kapitel soll nicht nur die Grundfunktionen kurz beschreiben, sondern auchHilfestellungen bei der Aufstellung von Sicherheitsanforderungen geben. Dazu werdennach der Skizzierung jeder einzelnen Grundfunktion eine Reihe von Punktenaufgezählt, die bei der Aufstellung von Sicherheitsanforderungen bezogen auf dieseGrundfunktion relevant sein können. Zur Aufstellung der Sicherheitsanforderungenkann man dann - ausgehend von der Bedrohungsanalyse für das System\ - dieaufgezeigten Punkte auf ihre Verwendbarkeit zur Abwehr von Bedrohungen desSystems analysieren. Auf diese Weise kann man dann bereits zu recht präzisen unddetaillierten Sicherheitsanforderungen gelangen.

3.1 Identifikation und Authentisierung

In den Sicherheitsanforderungen müssen die Subjekte und Objekte spezifiziertsein, für die eine Identifikation bzw. eine Identifikation mit Authentisierungdurchgeführt werden muß. Eine Authentisierung kann nur dann unterbleiben,wenn eine fehlerhafte Identifikation praktisch ausgeschlossen werden kann.Diese Grundfunktion ist Voraussetzung für eine sinnvolle Anwendung derGrundfunktionen "Rechteverwaltung", "Rechteprüfung" und "Beweissicherung".

Die folgenden Punkte können in den Sicherheitsanforderungen eines Systemsbezogen auf die Grundfunktion "Identifikation und Authentisierung" vonBedeutung sein:

- welche Subjekte und Objekte nur identifiziert werden müssen,- welche Subjekte und Objekte identifiziert und authentisiert werden müssen,- unter welchen Umständen eine Identifikation und Authentisierung erfolgen

muß,- welche Aktionen bei nicht erfolgreicher Identifikation und Authentisierung

ergriffen werden müssen.

3.2 Rechteverwaltung

Identifizierbare Subjekte können Rechte bezüglich anderer identifizierbarerSubjekte oder Objekte besitzen. Da diese Rechte im allgemeinen nicht statischsind, wird eine Rechteverwaltung benötigt, die die in denSicherheitsanforderungen festgelegten Regeln zur Modifikation von Rechtenrealisiert.Vielfach bestehen auch Beschränkungen derart, daß Rechte nur dann ausgeübtwerden können, wenn das Subjekt ein bestimmtes Attribut besitzt.Dadurch können Rollen definiert sein, d. h. ein Subjekt besitzt automatisch ein

1. Version 1989 - 9 -

bestimmtes Recht, falls ein Attribut gesetzt ist und hat keine Möglichkeit in denBesitz dieses Rechtes zu gelangen, wenn dieses Attribut nicht gesetzt ist.

In den Sicherheitsanforderungen eines Systems kann festgelegt sein:

- welche Subjekte bzw. Subjektklassen und welche Objekte bzw.Objektklassen der Rechteverwaltung unterliegen,

- welche Arten von Rechten zwischen Subjekten und Objekten existierenkönnen,

- wer Rechte vergeben bzw. ändern darf,- welche Regeln bei der Vergabe bzw. Änderung von Rechten eingehalten

werden müssen,- welche Voraussetzungen vor einer Vergabe oder Änderung von Rechten

erfüllt sein müssen,- welche Rollen durch die Rechteverwaltung definiert werden müssen,- welche Rechte an spezielle Rollen gebunden sind,- welche Rollen miteinander unvereinbar sind.

3.3 Rechteprüfung

Bei jedem Versuch eines identifizierbaren Subjekts, Rechte bezüglich einesanderen Subjekts oder Objekts auszuüben, ist es Aufgabe der Rechteprüfung,nur solche Aktionen zu erlauben, die das identifizierbare Subjekt aufgrundseiner vorhandenen Rechte ausüben darf.


- bei welchen Aktionen eine Rechteprüfung erfolgen soll,- welche Aktionen ergriffen werden sollen, wenn versucht wird, eine Aktion

ohne das zugehörige Recht auszuführen,- welche Ausnahmen es bei der Rechteprüfung geben soll und unter welchen

Umständen diese Ausnahmen gültig sein sollen.

3.4 Beweissicherung

Die Beweissicherung protokolliert Informationen über erfolgte oder versuchteAusübung von Rechten. Dadurch kann nachträglich überprüft werden, ob einMißbrauch von Rechten erfolgte oder versucht wurde.


- welche Ereignisse protokolliert werden sollen,- welche Informationen dabei aufgezeichnet werden sollen,

- 10 - 1. Version 1989

- wo diese Informationen aufgezeichnet werden sollen,- wer, wie und wann auf diese Informationen zugreifen darf,- nach welchen Kriterien diese Informationen ausgewertet werden sollen.

3.5 Wiederaufbereitung

Eine Reihe von Betriebsmitteln wie z. B. Haupt- und Peripheriespeicherplatzwerden hintereinander von mehreren Subjekten oder Objekten benutzt.Zwischen je zwei Nutzungen müssen solche wiederverwendbarenBetriebsmittel so wiederaufbereitet werden, daß kein Informationsflußstattfinden kann, der gegen die Sicherheitsanforderungen verstößt.


- welche Betriebsmittel wiederaufbereitet werden müssen,- nach bzw. vor welchen Aktionen eine Wiederaufbereitung erfolgen muß.

3.6 Fehlerüberbrückung

Aufgabe der Fehlerüberbrückung ist es, die Auswirkungen von Fehlverhaltendes Systems zu begrenzen und so einen möglichst verlustfreien Ablauf zugewährleisten. Grundvoraussetzung dazu ist, daß ein solches Fehlverhaltenmöglichst frühzeitig erkannt wird.


- welche Fehlerklassen überbrückt werden sollen,- in welcher Form (kontrollierter Abbruch, Fixpunkt und Wiederanlauf,

automatische Fehlerkorrektur etc.) die Fehlerüberbrückung erfolgen soll,- welche Beeinträchtigungen (z. B. Daten-, Funktions- oder Zeitverlust) in

Kauf genommen werden können.

3.7 Gewährleistung der Funktionalität

Jedes System hat vorgegebene Aufgaben zu erfüllen. In vielen Systemen ist einAusfall der Funktionalität einzelner Systemteile nicht tolerierbar. Es ist daher inden Sicherheitsanforderungen festzulegen, welche Funktionalität unbedingteingehalten werden muß, da ihr Ausfall die Gesamtsicherheit des Systems innicht hinnehmbarer Weise beeinträchtigen würde. Dazu können auchVerzögerungen gehören, durch die Teile der Funktionalität nicht in einemvorgegebenen Zeitintervall zur Verfügung gestellt werden (z. B. wenn auf einEingangssignal nicht rechtzeitig reagiert wird).


1. Version 1989 - 11 -

- welche Funktionalität einzelner Systemteile mit welcher Prioritätgewährleistet sein muß,

- unter welchen Randbedingungen diese Funktionalität eingehalten werdenmuß,

- unter welchen Umständen auf welche Funktionalität verzichtet werden kann.

3.8 Übertragungssicherung

Bei der Datenübertragung können im allgemeinen die Übertragungswege nichtvollständig durch die Rechteverwaltung und Rechteprüfung abgesichert werden.Es sind also zusätzliche Sicherheitsvorkehrungen zu treffen.Bei der Charakterisierung der Sicherheitsvorkehrungen bei der Datenüber-tragung wurde eine Einteilung gewählt, die auch an vielen anderen Stellen derLiteratur zu finden ist <1>.

Zwar ergeben sich dadurch Überschneidungen mit den anderenGrundfunktionen, jedoch scheint es nicht sinnvoll, eine eigene Einteilung zuwählen, durch die Schwierigkeiten bei der Abbildung auf andereBeschreibungen der Sicherheitsvorkehrungen bei der Datenübertragungvorgezeichnet wären.Die einzelnen Sicherheitsvorkehrungen bei der Datenübertragung sollen nunkurz skizziert werden:

3.8 1 Peer Entity Authentication (Authentisierung auf Partnerebene)

Hierbei handelt es sich um Vorkehrungen, die sicherstellen sollen, daß währendeiner Datenübertragung auch tatsächlich die gewünschten Partner miteinanderkommunizieren. Dieser Sicherheitsaspekt kann auch unter der Grundfunktion"Identifikation und Authentisierung" eingeordnet werden. Es sind daher die dortaufgezählten Einzelpunkte auch für die Identifikation und Authentisierung vonPartnern bei einer Datenübertragung zu beachten.

3.8 2 Access Control (Zugriffskontrolle)

Die Zugriffskontrolle soll verhindern, daß nicht autorisierte Benutzer bestimmtebei der Datenübertragung verwendete Betriebsmittel benutzen und dadurch z. Bunberechtigt Kommunikationsbeziehungen aufbauen. Es handelt sich also umeinen Bereich, der auch unter den Grundfunktionen "Rechteverwaltung" und"Rechteprüfung" eingeordnet werden kann. Es sind daher die dort aufgezähltenEinzelpunkte auch für die Kontrolle des Zugriffs zu Betriebsmitteln derDatenübertragung zu beachten.

<1>1 siehe "Security Addendum" zum OSI-Model ISO 7498-2-1988(E)

- 12 - 1. Version 1989

3.8 3 Data Confidentiality (Vertraulichkeit von Daten)

Normalerweise wird die Geheimhaltung von Daten durch die Grundfunktionen"Rechteverwaltung" und "Rechteprüfung" gewährleistet. Bei der Übertragungvon Daten gibt es jedoch im allgemeinen Bereiche, wo diese Grundfunktionennicht mehr wirksam sind. Deswegen müssen andere Sicherheitsvorkehrungengetroffen werden, die eine Geheimhaltung der Daten auch in diesen Bereichengewährleisten. Zu den Daten, die geheimgehalten werden müssen, können auchdie Adressen von Sender bzw. Empfänger, spezielle Felder mitProtokollinformationen sowie die Menge der übertragenen Daten gehören.

In den Sicherheitsanforderungen kann daher festgelegt sein:

- für welche Übertragungswege Maßnahmen zur Geheimhaltung notwendigsind,

- welche Daten auf welchen Strecken der Übertragung geheimgehalten werdenmüssen.

3.8 4 Data Integrity (Integrität von Daten)

Unter dem Aspekt der Datenintegrität ist sowohl die Wahrung der Integrität derNutzdaten, als auch die spezieller Protokolldaten wie zum Beispiel die derEmpfängeradressen einzuordnen. Wahrung der Integrität bedeutet, daß es anallen dazu erforderlichen Stellen bei der Datenübertragung möglich sein muß,die benötigten Informationen aus dem Datenstrom zu erhalten. Dies kann sowohldurch Maßnahmen zur Fehlererkennung und -überbrückung als auch durchMaßnahmen zur Fehlervermeidung erreicht werden. Bei der Aufstellung vonSicherheitsanforderungen für integritätswahrende Maßnahmen sind daher diebei den Grundfunktionen "Fehlerüberbrückung" und "Gewährleistung derFunktionalität" aufgestellten Einzelpunkte zu beachten.

3.8 5 Data Origin Authentication (Authentisierung des Senders von Daten)

Die Identifikation und Authentisierung des Urhebers eines Datenstromes istvielfach ebenfalls ein wichtiger Aspekt der Sicherheitsanforderungen. Bei derFormulierung von Sicherheitsanforderungen in diesem Bereich sind die bei derGrundfunktion "Identifikation und Authentisierung" aufgezeigten Einzelpunkte zubeachten.

1. Version 1989 - 13 -

3.8 6 Non-repudiation (Anerkennung von Daten)

Hier sind zwei Teilaspekte zu beachten: Einerseits kann es erforderlich sein,dem Empfänger eines Datenstroms die Möglichkeit zu geben, zu beweisen, daßein Datenstrom ihm von dem angegebenen Sender per Datenübertragungübersandt worden ist, andererseits kann es auch erforderlich sein, dem Sendereines Datenstroms die Möglichkeit zu geben, zu beweisen, daß der Adressat desDatenstroms diesen auch in Empfang genommen hat. Es handelt sich hier alsoum einen Problembereich der Authentisierung von Datenströmen zusammen mitihren Sendern respektive Empfängern. Diese Authentisierung wird dannnotwendig, wenn es unter Umständen notwendig sein kann, das Senden bzw.Empfangen von Datenströmen nachzuweisen. Es sind also neben den Aspektender Grundfunktion "Identifikation und Authentisierung" auch die Aspekte derGrundfunktion "Beweissicherung" bei der Aufstellung vonSicherheitsanforderungen in diesem Bereich zu beachten.

- 14 - 1. Version 1989

4. Mechanismen

Zur Realisierung der Sicherheitsfunktionen werden Mechanismen bzw. Algorithmenverwendet. Diese Mechanismen bzw. Algorithmen können folgendesicherheitskritische Schwachstellen besitzen:

1) Die verwendetenMechanismen bzw. Algorithmen sind nicht in der Lage, dieSicherheitsanforderungen vollständig abzudecken.

2) Die Mechanismen bzw.Algorithmen besitzen prinzipielle Schwächen, durch die Sicherheitsfunktionenauch bei korrekter Implementierung umgangen oder außer Kraft gesetzt werdenkönnen.

Neben sicherheitskritischen Schwachstellen, die die Mechanismen bzw. Algorithmenselbst betreffen, können

3) die Mechanismen bzw.Algorithmen auch fehlerhaft implementiert sein.

Punkt 1) sollte bei der Prüfung der Abbildung zwischen den Sicherheitsanforderungenund der Spezifikation beachtet und bewertet werden, Punkt 3) ist dann bei der Prüfungder Implementierung zu untersuchen. Dieses Kapitel befaßt sich daher hauptsächlichmit Punkt 2), d. h. es sollen die Schwachstellen der Mechanismen bzw. Algorithmengefunden werden, die auch bei korrekter Implementierung noch vorhanden sind. Eswerden lediglich Leitlinien zur Auffindung solcher Schwachstellen und zur Bewertungvon Mechanismen bzw. Algorithmen angegeben. Im IT-Evaluationshandbuch wird dieAnwendung dieser Leitlinien an einigen Beispielen erläutert.

Die prinzipiellen Schwächen eines Mechanismus lassen sich noch untergliedern in

- Schwächen, die dem Mechanismus bzw. Algorithmus in der spezifizierten Forminhärent sind und auch durch organisatorische Maßnahmen in der Systemumweltnicht oder nur sehr schwer beseitigt werden können, sowie

- Schwächen, die bei dem Mechanismus bzw. Algorithmus in der spezifiziertenForm durch organisatorische Maßnahmen unwirksam gemacht werden können.

Schwächen der ersten Form führen prinzipiell zu einer Abwertung der Stärke desMechanismus bzw. Algorithmus, bei Schwächen der zweiten Form muß dagegen dieArt und maschinelle Unterstützung der notwendigen organisatorischen Maßnahmen beieiner Bewertung mit berücksichtigt werden. Prinzipiell kann man jedoch sagen, daßdie Notwendigkeit von aufwendigen und fehleranfälligen organisatorischen

1. Version 1989 - 15 -

Maßnahmen ebenfalls zu einer Abwertung der Stärke eines Mechanismus bzw.Algorithmus führen muß.

In einem Evaluationsbericht ist daher für jeden Mechanismus aufzuführen:

- Welche Sicherheitsanforderungen durch diesen Mechanismus allein oder inKombination mit anderen Mechanismen abgedeckt werden sollen,

- welche prinzipiellen Schwächen und Stärken der Mechanismus besitzt, und inwelcher Form diese das Zusammenspiel mit anderen Mechanismen beeinflussen,

- welche organisatorischen Maßnahmen notwendig sind, damit verbleibendeSchwächen des Mechanismus nicht zum Tragen kommen.

Die beiden letzten Punkte sind dann ausschlaggebend für die Bewertung eines Mecha-nismus. Dabei sollen die folgenden Stufen eine Leitlinie zur Bewertung von Mecha-nismen bilden.

ungeeignetDer Mechanismus ist nicht wirksam.

schwachDer Mechanismus ist lediglich als Abwehr unbeabsichtigter Verstöße gegen dieSicherheitsanforderungen geeignet, stellt jedoch kein ernsthaftes Hindernisgegen absichtliche Verstöße dar.

mittelstarkDer Mechanismus bietet bereits Schutz bei absichtlichen Verstößen gegen dieSicherheitsanforderungen, ist jedoch mit mittelgroßem Aufwand von Personenmit normalen Kenntnissen des Systems zu überwinden.

starkDer Mechanismus bietet einen guten Schutz bei absichtlichen Verstößen gegendie Sicherheitsanforderungen und ist nur mit großem Aufwand bzw. unterZuhilfenahme aufwendiger Hilfsmittel zu überwinden. Falls organisatorischeMaßnahmen zur Aufrechterhaltung der Stärke des Mechanismus notwendig sind,müssen diese recht einfach geartet und wenig fehleranfällig sein. Beifehleranfälligen organisatorischen Maßnahmen müssen im zu evaluierenden IT-System Methoden zur Erkennung und Vermeidung solcher Fehler implementiertsein. Die organisatorischen Maßnahmen sind im Evaluationsbericht zubeschreiben. Die Bewertung der Qualität dieser Methoden und der Korrektheitihrer Implementierung ist dabei Teil der Evaluation.

- 16 - 1. Version 1989

sehr starkDer Mechanismus bietet einen sehr guten Schutz bei absichtlichen Verstößengegen die Sicherheitsanforderungen und ist nach dem derzeitigen Stand derTechnik nur mit sehr großem Aufwand und unter Zuhilfenahme sehr aufwendigerHilfsmittel zu überwinden. Organisatorische Maßnahmen zur Aufrechterhaltungder Stärke des Mechanismus müssen relativ einfach geartet und wenigfehleranfällig sein. Mögliche Fehlerquellen bei der Handhabung derorganisatorischen Maßnahmen müssen weitgehend vom zu evaluierenden Sy-stem überwacht werden und Maßnahmen zur Fehlervermeidung müssenimplementiert sein. Alle diese Kontrollfunktionen müssen Bestandteil der zuevaluierenden Software sein.

nicht überwindbarDer Mechanismus bietet einen zur Zeit nicht überwindbaren Schutz bei absicht-lichen Verstößen gegen die Sicherheitsanforderungen. Zur Aufrechterhaltungseiner Stärke werden höchstens solche organisatorische Maßnahmen eingesetzt,die durch systeminterne Überwachungsfunktionen praktisch vollständig gegenFehler abgesichert sind. Alle diese Kontrollfunktionen müssen Bestandteil derzu evaluierenden Software sein.

Hinweise für die Bewertung von Mechanismen aufgeschlüsselt nach denGrundfunktionen

4.1 Grundfunktion: Identifikation und Authentisierung

Bei der Bewertung von Mechanismen zur Realisierung der GrundfunktionIdentifikation und Authentisierung sind folgende Aspekte zu bewerten:

- Die Garantie der Eindeutigkeit der Identität.

- Möglichkeiten zur Täuschung des Authentisierungsmechanismus.

Dabei müssen je nach Art der Authentisierung folgende Aspekte betrachtetwerden:

- Bei Authentisierung durch Besitztum:- Die Möglichkeit zum Entwenden des zur Authentisierung benutzten

Objektes.- Der Aufwand zum Fälschen des zur Authentisierung benutzten Objektes.

1. Version 1989 - 17 -

- Bei Authentisierung durch Wissen:- Der Aufwand zur Erlangung des Wissens.

- Bei Authentisierung durch Merkmale:- Der Aufwand zum Fälschen der Merkmale.

Bei der Bewertung der Garantie der Eindeutigkeit der Identität kann folgendeEinteilung als Anhaltspunkt für eine Bewertung dienen:

- Falls die Wahrscheinlichkeit einer nicht korrekten Identifikation durch einemögliche mehrdeutige Identität größer als 10-2 ist, so ist der Mechanismusals "schwach" zu bewerten.

- Falls die Wahrscheinlichkeit einer nicht korrekten Identifikation durch einemögliche mehrdeutige Identität größer als 10-4 ist, so kann der Mechanismusbis "mittelstark" bewertet werden.

- Falls die Wahrscheinlichkeit einer nicht korrekten Identifikation durch einemögliche mehrdeutige Identität größer als 10-6 ist, so kann der Mechanismusbis "stark" bewertet werden.

- Falls die Wahrscheinlichkeit einer nicht korrekten Identifikation durch einemögliche mehrdeutige Identität größer als 10-8 ist, so kann der Mechanismusbis "sehr stark" bewertet werden.

4.1.1 Authentisierung durch Besitztum

Bei einer Authentisierung durch Besitztum muß bei der Bewertung beachtetwerden, daß der zur Authentisierung benutzte Gegenstand außerhalb des zuevaluierenden Teils des Systems anderen Subjekten überlassen, bzw. vondiesen entwendet oder gefälscht werden kann. Gegen die Bedrohung desÜberlassens und des Entwendens können keine Maßnahmen innerhalb des IT-Systems getroffen werden. Die einzige Schutzmaßnahme gegen diese Bedrohungist eine zusätzliche Authentisierung des Subjektes entweder gegenüber dem zurAuthentisierung benutzten Objekt oder aber gegenüber dem IT-System. Beieiner Authentisierung gegenüber dem zur Authentisierung benutzten Objekt istder dort verwendete Mechanismus selbst ebenfalls zu bewerten sowie dieKommunikation zwischen dem Objekt und dem IT-System zu untersuchen. Dennüber diesen Kommunikationskanal benachrichtigt das Objekt das IT-System, obes selbst seinen Besitzer korrekt identifiziert und authentisiert hat. Besitzt daszur Authentisierung benutzte Objekt DV-Anteile (z. B. bei einer Chipkarte), sosind diese als Teil des zu evaluierenden Systems zu betrachten. In diesem Fallhandelt es sich dann ebenso wie bei einer zusätzlichen Authentisierung

- 18 - 1. Version 1989

gegenüber dem IT-System um eine Kombination von Mechanismen, dieentsprechend zu bewerten ist.

Die Fälschungssicherheit des zur Authentisierung benutzten Objektes kann vonder Evaluationsbehörde im allgemeinen nicht beurteilt werden. Soll das Systemjedoch in eine Qualitätsklasse höher als Q1 evaluiert werden, kann dieEvaluationsbehörde die Vorlage eines Gutachtens einer unabhängigen Instanzverlangen, in dem die Fälschungssicherheit des zur Authentisierung benutztenObjektes untersucht und bewertet wird.

4.1.2 Authentisierung durch Wissen

Auch Wissen kann außerhalb des IT-Systems durch bewußtes Weitergeben oderunzureichende Geheimhaltung übertragen werden. Außerdem kann sich einUnbefugter durch Raten und Probieren das Wissen verschaffen. DieseBedrohungen können innerhalb des IT-Systems nicht abgefangen werden, sindalso als inhärente Schwächen anzusehen. Zusätzliche Schwächen sind in diesemFalle jedoch gegeben, wenn

- die Kommunikation zwischen dem zu authentisierenden Subjekt und demvertrauenswürdigen Teil des IT-Systems nicht ausreichend abgesichert ist,oder

- eine Kommunikationsverbindung zwischen dem zu authentisierenden Subjektund dem vertrauenswürdigen Teil des IT-Systems von wenigervertrauenswürdigen Teilen des IT-Systems vorgetäuscht werden kann, oder

- die Authentisierungsinformationen vom vertrauenswürdigen Teil des Sy-stems unzureichend gegen Zugriffe von Unberechtigten geschützt sind.

Falls eine dieser drei Bedrohungen wirksam werden kann, ist der Aufwand zurunbefugten Erlangung des zur Authentisierung eines Subjektes benötigtenWissens abzuschätzen und der Authentisierungsmechanismus entsprechend denoben aufgeführten Richtlinien zu bewerten.

Außerdem spielt die Wahrscheinlichkeit, daß Wissen durch Erraten erlangtwerden kann, eine entscheidende Rolle. Die Zahl der Versuche zum Erraten, diein einem bestimmten Zeitraum möglich sind, sowie die erforderlichen Spezial-kenntnisse bestimmen, wie der Mechanismus zu bewerten ist.

4.1.3 Authentisierung durch Merkmale

Erfolgt die Authentisierung durch Merkmale, so ist zu untersuchen, ob dieseMerkmale eindeutig genug, ausreichend fälschungssicher und fest genug mit demzu identifizierenden Subjekt verbunden sind. Falls es sich um Merkmale

1. Version 1989 - 19 -

handelt, die nicht DV-technischer Natur sind, so kann die Prüfbehörde dieVorlage von Gutachten verlangen, in denen diese Punkte untersucht werden.Aufgrund der Ergebnisse dieser Untersuchungen ist dann von der Prüfbehördedie Stärke des Mechanismus zu bewerten.

4.2 Grundfunktion: Rechteverwaltung

Bei Mechanismen und Algorithmen zur Realisierung der GrundfunktionRechteverwaltung sind folgende Aspekte besonders zu untersuchen:

- Die Vollständigkeit der Rechteverwaltung, d. h. es ist zu untersuchen, ob alleSubjekte und Objekte, die nach den Sicherheitsanforderungen derRechteverwaltung unterliegen sollen, auch wirklich erfaßt werden.Außerdem ist zu prüfen, ob alle Rechte in der Form vergeben werdenkönnen, wie es die Sicherheitsanforderungen verlangen.

- Die Widerspruchsfreiheit der Rechtestruktur, d. h. es ist zu untersuchen, obes bei der Vergabe von Rechten zu Widersprüchen mit existierenden Rechtenkommen kann, und ob in jedem solchen Fall genau festgelegt ist, welchesRecht tatsächlich gültig ist. Falls dies nicht festgelegt ist, muß es zumindesteine maschinelle Unterstützung bei der Erkennung solcher Konfliktfällegeben.

- Die Überschaubarkeit der Rechtestruktur. Dies ist ein wichtiges Kriterium,um die Entstehung ungewollter Rechtebeziehungen zu vermeiden. Bietet einSystem die Möglichkeit, komplexe Rechtestrukturen zu erstellen, so ist eserforderlich, daß auch maschinelle Unterstützung bei der Darstellung undAnalyse der Rechtestruktur vorhanden ist.

- Der Schutz vor verdeckten Rechteänderungen, d. h. Änderungen von Rechten,die durch nicht vertrauenswürdige Programme vorgenommen werdenkönnen, ohne daß der Benutzer dieser Programme unmittelbar davoninformiert wird. Ohne einen solchen Schutz können durch "TrojanischePferde" ungewollte Rechtebeziehungen eingerichtet werden.

- Der Schutz vor der Entstehung nicht mehr änderbarer Rechtebeziehungen.Dies sind Rechtebeziehungen, die von keinem Subjekt mehr rückgängiggemacht werden können. Ein gleichgelagertes Problem ist der Schutz vorOperationen in der Rechteverwaltung, die nicht mehr rückgängig gemachtwerden können (z.B. der Systemverwalter, der sich selbst das Systemver-walterkennzeichen löscht).

- Die Verwaltung der zugehörigen Rechte beim Löschen oder Umbenennen vonSubjekten bzw. Objekten. Werden z. B. beim Löschen eines Subjektes nichtauch alle Rechte gelöscht, die dieses Subjekt besitzt, so kann es zu

- 20 - 1. Version 1989

ungewollten Rechtebeziehungen kommen, wenn später einmal ein neuesSubjekt mit dem gleichen Namen eingerichtet wird (vorausgesetzt, dieRechteverwaltung identifiziert Subjekte über ihren Namen).

- Der Schutz vor Einschränkungen bei der Ausübbarkeit von Rechten. Vielfachmüssen Rechte temporär eingeschränkt werden um die Integrität vonObjekten zu gewährleisten (z. B. muß in vielen Systemen der Zugriff zu einerDatei gesperrt werden, wenn ein Subjekt schreibend auf diese Dateizugreift). Hier ist zu untersuchen, ob die im System vorhandenenEinschränkungen bei der Ausübbarkeit von Rechten im Einklang mit denSicherheitsanforderungen, insbesondere den Anforderungen bezüglich derVerfügbarkeit stehen.

4.3 Grundfunktion: Rechteprüfung

Mechanismen bzw. Algorithmen zur Rechteprüfung sind auf die folgendenAspekte zu untersuchen:

- Vollständigkeit der Rechteprüfung.Dies bedeutet, daß vor jedem Versuch, ein Recht auszuüben, überprüft wird,ob das Recht vorhanden ist. Falls dies nicht geschieht, gibt es Wege, dieRechteprüfung zu umgehen, die bereits durch den verwendeten Mechanismusbzw. Algorithmus bedingt sind. Falls diese Wege nicht durch andereMechanismen blockiert werden, ist der Mechanismus abzuwerten. DieBewertung hängt davon ab, welchen Aufwand es für einen böswilligenBenutzer bedeutet, einen dieser Wege auszunutzen.

- Zeitpunkt der Rechteprüfung.Dies bedeutet, daß zwischen Prüfung und Ausübung eines Rechtes keineAktionen erfolgen können, die einen Entzug des Rechtes zur Folge haben.Hier ist zu bewerten, wie lange ein Subjekt noch in der Lage ist, dasentzogene Recht auszuüben und welche Folgen dies haben kann. Davon istabhängig, wie der Mechanismus bei einem solchen Verhalten zu bewertenist.

- Verfügbarkeit der Entscheidungsdaten.Dies bedeutet, daß sichergestellt ist, daß alle zur Prüfung benötigten Datenjederzeit verfügbar sind. Dies kann insbesondere in Netzwerken oderverteilten Systemen ein Problem sein. Stehen nicht alle Entscheidungsdatenzur Verfügung, so gibt es zwei Alternativen für die Rechteprüfung: Entwedersie läßt die Ausübung des Rechtes zu, mit der Gefahr, daß ein Subjekt einRecht ausübt, welches ihm nicht zugestanden wurde, oder sie verhindert dieAusübung des Rechtes mit der Gefahr, daß ein Subjekt ein gegebenes Rechtnicht ausüben und dadurch unter Umständen seine Aufgabe nicht erfüllenkann. In jedem dieser beiden Fälle muß untersucht werden, wie

1. Version 1989 - 21 -

wahrscheinlich das Eintreten dieses Falles ist und welche Auswirkungen dasVerhalten der Rechteprüfung auf die Erfüllung der Sicherheitsanforderungendes Systems dann haben kann. Es ist daher im Einzelfall zu entscheiden, obund wie der Mechanismus zu bewerten ist.

- Integrität der Entscheidungsdaten.Dies bedeutet, daß sichergestellt ist, daß die zum Treffen einer Entscheidungüber die Erlaubnis eines Zugriffs verwendeten Daten nicht in unzulässigerWeise verändert werden können. Dazu zählen auch Veränderungen, die durchHardwarefehler oder Übertragungsfehler entstehen können. Falls es möglichist, die Entscheidungsdaten gezielt in unzulässiger Weise zu verändern, istdie Bewertung von dem Aufwand abhängig, der zu einer solchen Ver-änderung notwendig ist.Im Falle von möglichen stochastischen Änderungen muß die Wahrscheinlich-keit für das Auftreten einer solchen Änderung abgeschätzt werden. DieseWahrscheinlichkeit bestimmt dann die Bewertung des Mechanismus.

4.4 Grundfunktion: Beweissicherung

Bei den zur Beweissicherung eingesetzten Mechanismen sind folgende Aspektebesonders zu untersuchen:

- Untäuschbarkeit der Beweissicherung.Dies bedeutet, es muß sorgfältig geprüft werden, ob Wege existieren, durchdie es möglich ist, die Beweissicherung zur Aufzeichnung von fehlerhaftenDaten zu veranlassen. Dazu zählt auch die Protokollierung von Ereignissen,die in Wirklichkeit nicht stattgefunden haben.

- Vollständigkeit der Beweissicherung.Dies bedeutet, es muß sorgfältig geprüft werden, ob es möglich ist, daßEreignisse entgegen den Sicherheitsanforderungen nicht protokolliertwerden. Ein solcher Fall kann zum Beispiel dann eintreten, wenn derMechanismus keine Vorkehrungen beim Überlaufen derProtokollierungsdateien vorsieht.

4.5 Grundfunktion: Wiederaufbereitung

Mechanismen bzw. Algorithmen zur Wiederaufbereitung sind auf die folgendenAspekte zu untersuchen:

- Art der Wiederaufbereitung.Dies bedeutet, ist es nach einer Wiederaufbereitung tatsächlich unmöglich,an die vorher im Objekt gespeicherten Daten zu gelangen. Falls dies dochmöglich ist, muß der Aufwand zur Erlangung der Daten durch einen

- 22 - 1. Version 1989

Unbefugten abgeschätzt werden. In Abhängigkeit von diesem Aufwand ist derMechanismus zu bewerten.

- Zeitpunkt der Wiederaufbereitung.Dies bedeutet, kann zwischen Freigabe des Objektes und Wiederaufbereitungeventuell noch ein Zugriff zu dem Objekt erfolgen, durch den Rückschlüsseauf die im Objekt gespeicherten Daten möglich sind.

4.6 Grundfunktion: Fehlerüberbrückung

Mechanismen zur Fehlerüberbrückung bestehen aus zwei Teilen, die nachunterschiedlichen Gesichtspunkten zu analysieren sind: der Fehlererkennungsowie der eigentlichen Fehlerüberbrückung. Die Überbrückung kann aus einemkontrollierten Abbruch mit möglichst minimalem Daten-, Funktions- undZeitverlust bestehen, oder es wird der Versuch einer Fehlerkorrekturunternommen. Im zweiten Fall sind Überschneidungen mit der Grundfunktion"Gewährleistung der Funktionalität" gegeben, da eine Fehlerkorrektur nur denZweck haben kann, in bestimmten Bereichen die Funktionsfähigkeit des Systemsauch im Fehlerfall zu gewährleisten.Mechanismen zur Fehlererkennung sind auf die folgenden Aspekte zuuntersuchen:

- Vollständigkeit der Fehlererkennung.Dies bedeutet, werden auch tatsächlich alle Fehler, die durch denMechanismus erkannt werden sollen, auch unter allen Umständen erkannt.

- Korrektheit der Fehleranalyse.Dies bedeutet, können alle zur weiteren Fehlerbehandlung erforderlichenInformationen bei jedem erkannten Fehler korrekt extrahiert werden.

Die Bewertung des Mechanismus bei Schwächen in den oben genanntenBereichen muß dann in Abhängigkeit von der Wahrscheinlichkeit, mit der dieseSchwächen auftreten, erfolgen.

Mechanismen zur Fehlerüberbrückung sind nach den folgenden Gesichtspunktenzu prüfen:

- Möglicher Daten-, Funktions- oder Zeitverlust durch die Fehlerüber-brückung. Dieser Punkt ist unter den Sicherheitsanforderungen an das Systembezüglich Integrität und Verfügbarkeit zu prüfen. Mögliche Verluste, die imGegensatz zu den Sicherheitsanforderungen stehen, führen zu einerAbwertung des Mechanismus. Die Stärke der Abwertung hängt ab von derWahrscheinlichkeit, mit der der Fehler auftritt, und von derWahrscheinlichkeit, mit der in diesem Fall ein nach den

1. Version 1989 - 23 -

Sicherheitsanforderungen nicht mehr tolerierbarer Daten-, Funktions- oderZeitverlust eintritt.

- Unabhängigkeit des Korrekturverfahrens von der Fehlerquelle. Der Mecha-nismus ist darauf zu prüfen, daß Auswirkungen des Fehlers den korrektenAblauf des Korrekturverfahrens nicht beeinträchtigen.

- Mögliche Fehlerquellen in der Fehlerüberbrückung selbst. Es ist zu prüfen,daß bei der Fehlerüberbrückung selbst kein Zustand entstehen kann, der zueinem rekursiven Aufruf der Fehlerüberbrückungsprogramme führen kann.Ein solcher Zustand kann in vielen Systemen auftreten, wenn während derFehlerüberbrückung selbst wieder ein Fehler auftritt. Kann dies nichtausgeschlossen werden, ist zu prüfen, ob damit ein nach denSicherheitsanforderungen nicht mehr tolerierbarer Daten-, Funktions- oderZeitverlust verbunden sein kann. Die Wahrscheinlichkeit für das Auftreteneines solchen Falles ist ausschlaggebend für die Bewertung.

4.7 Grundfunktion: Gewährleistung der Funktionalität

Unter dieser Grundfunktion werden Mechanismen betrachtet, die bestimmteFunktionalitäten des Systems kontinuierlich aufrechterhalten, auch wenn nichtdirekt ein Fehler auftritt. Es handelt sich hierbei also um Mechanismen zurFehlervermeidung. Beispiele sind Mechanismen zur Deadlockvermeidung,Scheduling-Algorithmen, die die in den Sicherheitsanforderungenniedergelegten Antwortzeiten garantieren sollen, oder umRedundanzmaßnahmen, durch die eine kontinuierliche Funktionalität auch beiAusfall bestimmter Komponenten gewährleistet werden kann. In vielen Fällensind Mechanismen zur Gewährleistung der Funktionalität eng gekoppelt mitMechanismen zur Fehlerüberbrückung. Daher wird man solche Mechanismendann nach den Kriterien für beide Grundfunktionen untersuchen müssen.

Mechanismen zur Realisierung der Grundfunktion "Gewährleistung derFunktionalität" sind speziell nach folgenden Gesichtspunkten zu untersuchen:

- Bei Mechanismen, die eine Erkennung von fehlerkritischen Situationenvoraussetzen (z. B. Mechanismen, die bei hoher Systembelastung eingreifensollen bzw. generell Mechanismen, die erst bei Überschreiten vorgegebenerGrenzwerte aktiviert werden), ist zu prüfen, ob die Maßnahmen zurErkennung ausreichend sind, oder ob sich der Fehler, der vermieden werdensoll, eventuell noch durch andere Symptome ankündigen kann.

- 24 - 1. Version 1989

- Maßnahmen zur Fehlervermeidung sind darauf zu untersuchen, inwieweitdiese Maßnahmen andere Funktionen beeinträchtigen. Ist dies der Fall, somuß geprüft werden, daß diese Beeinträchtigungen nicht im Widerspruch zuden Sicherheitsanforderungen stehen. Außerdem muß untersucht werden, obdie Funktionen, deren Funktionalität gewährleistet werden sollen, auchunabhängig von solchen Funktionen sind, die durch die Maßnahmen zurGewährleistung der Funktionalität negativ beeinflußt werden. Sind sie nichtunabhängig, so können Rückwirkungen auf die aufrechtzuerhaltendeFunktionalität nicht ausgeschlossen werden.

4.8 Grundfunktion: Übertragungssicherung

Sicherheitsfunktionen zur Übertragungssicherung, wie sie z. B. im "SecurityAddendum" zum OSI-Modell vorgestellt werden, umfassen auch Bereiche, diebereits durch andere Grundfunktionen abgedeckt sind. Im folgenden Teil werdenzwar die Einzelbedrohungen bei der Datenübertragung analog zum OSI-SecurityAddendum behandelt, es wird jedoch bei jedem Einzelpunkt darauf verwiesen,welche anderen Grundfunktionen zur Abwehr der speziellen Bedrohungverwendet werden können. Mechanismen zur Abwehr einer solchen Bedrohungsind dann auch bezüglich derjenigen Kriterien zu untersuchen, die bei denangegebenen Grundfunktionen aufgestellt wurden.Der folgende Teil behandelt die einzelnen Sicherheitsaspekte bei derDatenübertragung und gibt Kriterien zur Beurteilung von Mechanismen zur Rea-lisierung dieser Aspekte an.

4.8.1 Peer Entity Authentication (Authentisierung auf Partnerebene)

Dies ist ein Bereich, der durch Mechanismen zur Realisierung derGrundfunktion "Identifikation und Authentisierung" abgedeckt wird.Entsprechend sind diese Mechanismen unter den dort genannten Gesichtspunk-ten zu untersuchen und zu bewerten.

4.8.2 Access Control (Zugriffskontrolle)

Mechanismen zur Zugriffskontrolle dienen entweder zur Verwaltung vonZugriffsrechten, sind also nach den Kriterien der Grundfunktion"Rechteverwaltung" zu untersuchen, oder sie dienen zur Prüfung vonZugriffsrechten, sind also nach den Kriterien der Grundfunktion"Rechteprüfung" zu untersuchen und zu bewerten.

4.8.3 Data Confidentiality (Vertraulichkeit von Daten)

Bei der Datenübertragung besteht im allgemeinen das Problem, daß dieInformationen bei der Übertragung häufig nicht vollständig durch Mechanismender Grundfunktionen "Rechteprüfung" und "Rechteverwaltung" geschützt

1. Version 1989 - 25 -

werden können, da diese Mechanismen nicht an allen Stellen desÜbertragungsweges wirksam sind. Um daher Informationen vor unberechtigterKenntnisnahme zu schützen, müssen zusätzlich Mechanismen eingesetzt werden,die an den Stellen Schutz gewährleisten, an denen die eingesetztenMechanismen zur Rechteverwaltung und Rechteprüfung nicht wirksam sind. Alszu schützende Informationen werden nicht nur die eigentlichenNutzinformationen betrachtet, sondern vielfach auch spezielleProtokollinformationen, wie zum Beispiel die Adressen von Sender oderEmpfänger. In manchen Fällen muß sogar die Menge der übertragenenNutzinformation geheimgehalten werden.Mechanismen für diesen Aspekt der Datenübertragungssicherung sind unterfolgenden Gesichtspunkten zu untersuchen:

- Schutz der Informationen durch die Kombination der verschiedenenSchutzmechanismen auf dem gesamten Übertragungsweg.

- Schutz der Zusatzinformationen, die zur Rückgewinnung der Informationenauf der Empfängerseite benötigt werden, vor unbefugter Kenntnisnahme undunbefugter Modifikation auf dem Übertragungsweg.

- Nachweis, daß ein berechtigter Empfänger die Informationen rekonstruierenkann.

4.8.4 Data Integrity (Integrität von Daten)

Hierbei ist sowohl der Aspekt der Integrität einzelner Datenpakete bzw.Datenfelder als auch der Aspekt der Integrität des gesamten Datenstroms oderdie Integrität der Reihenfolge der Übertragung einzelner Datenpakete zu sehen.Mechanismen für diesen Bereich der Datenübertragung lassen sich nach denKriterien der Grundfunktionen "Fehlererkennung und -überbrückung" und"Gewährleistung der Funktionalität" bewerten.

4.8.5 Data Origin Authentication (Authentisierung des Senders von Daten)

Dieser Aspekt fällt wieder unter die Grundfunktion "Identifikation undAuthentisierung". Mechanismen zur Realisierung dieser Funktion sind also nachden Kriterien dieser Grundfunktion zu beurteilen.

4.8.6 Non-repudiation (Anerkennung von Daten)

Hierbei sind folgende Teilaspekte zu betrachten:

1) Nachweisbarkeit, daß ein bestimmter Datenstrom von einem bestimmtenSubjekt gesendet wurde.

- 26 - 1. Version 1989

Dies bedeutet, daß ein Empfänger nachweisen kann, daß ihm ein bestimmterDatenstrom von einem eindeutig identifizierbaren Sender übersandt wordenist. Es muß also sichergestellt sein, daß kein anderer als der angegebeneSender in der Lage ist, diesen Datenstrom zu erzeugen.

2) Nachweisbarkeit, daß ein bestimmter Datenstrom von dem berechtigtenEmpfänger entgegengenommen wurde.

Dies bedeutet, daß der Sender eines Datenstroms nachweisen kann, daßdieser Datenstrom auch seinen Adressaten erreicht hat. Der Sender muß alsoeine Art von fälschungssicherer Empfangsquittung (z.B. elektronischeUnterschrift) erhalten.

Die eingesetzten Mechanismen werden also in beiden Fällen einerseits derIdentifikation und Authentisierung von Sender bzw. Empfänger, andererseits zurBeweissicherung benutzt. Entsprechend sind die Mechanismen nach denKriterien für diese beiden Grundfunktionen zu untersuchen und zu bewerten.

1. Version 1989 - 27 - F1

5. Funktionalitätsklassen

Die hier aufgeführten Funktionalitätsklassen sollen lediglich Anhaltspunkte sein, dieeinerseits einem Anwender die Auswahl eines Systems erleichtern, andererseitsHerstellern bei der Konzeption und Einordnung seines Systems helfen können. Es istdurchaus möglich, daß ein System die Anforderungen mehrerer Klassen gleichzeitigerfüllt. In einem Zertifikat sind dann alle Klassen aufgezählt, die das evaluierteSystem erfüllt. Hierarchisch geordnet sind lediglich die Funktionalitätsklassen, dieaus dem Orange Book abgeleitet sind.Falls sich die Notwendigkeit ergibt, ist es durchaus möglich, daß spätere Versionender IT-Sicherheitskriterien zusätzliche Funktionalitätsklassen enthalten.

Funktionalitätsklasse F1(abgeleitet aus der Funktionalität der Orange Book Klasse C1)

Identifikation und Authentisierung

Das System muß Benutzer identifizieren und authentisieren. Diese Identifikation undAuthentisierung muß vor jeder anderen Interaktion des Systems mit dem Benutzererfolgt sein. Nur nach einer erfolgreichen Identifikation und Authentisierung dürfenandere Interaktionen möglich sein. Die Authentisierungsinformationen müssen sogespeichert sein, daß nur autorisierte Benutzer Zugriff dazu besitzen.

Rechteverwaltung

Das System muß Zugriffsrechte zwischen Benutzern und/oder Benutzergruppen undObjekten, die der Rechteverwaltung unterliegen, kennen und verwalten. Dabei muß esmöglich sein, Benutzern bzw. Benutzergruppen den Zugriff zu einem Objekt ganz zuverwehren. Vergabe und Entzug von Zugriffsrechten zu einem Objekt darf nur durchautorisierte Benutzer möglich sein.

Rechteprüfung

Das System muß bei jedem Zugriffsversuch von Benutzern bzw. Benutzergruppen zuden der Rechteverwaltung unterliegenden Objekten die Berechtigung überprüfen.Unberechtigte Zugriffsversuche müssen abgewiesen werden.

F2 - 28 - 1. Version 1989

Funktionalitätsklasse F2(abgeleitet aus der Funktionalität der Orange Book Klasse C2)


Das System muß Benutzer identifizieren und authentisieren. Diese Identifikation undAuthentisierung muß vor jeder anderen Interaktion des Systems mit dem Benutzererfolgt sein. Nur nach einer erfolgreichen Identifikation und Authentisierung dürfenandere Interaktionen möglich sein. Die Authentisierungsinformationen müssen sogespeichert sein, daß nur autorisierte Benutzer Zugriff dazu besitzen.Bei jeder durchgeführten Interaktion muß das System die Identität desBenutzers feststellen können.

Rechteverwaltung

Das System muß Zugriffsrechte zwischen Benutzern und/oder Benutzergruppen undObjekten, die der Rechteverwaltung unterliegen, kennen und verwalten. Dabei muß esmöglich sein, Benutzern bzw. Benutzergruppen den Zugriff zu einem Objekt ganz zuverwehrensowie den Zugriff auf einen nicht-modifizierenden Zugriffzu beschränken. Außerdem muß es möglich sein, für jeden Benutzer separat dieZugriffsrechte zu einem Objekt festzulegen. Vergabe und Entzug vonZugriffsrechten zu einem Objekt darf nur durch autorisierte Benutzer möglich sein.Die Weitergabe von Zugriffsrechten muß kontrollierbar sein. Ebenso darfdas Einbringen neuer Benutzer sowie das Löschen bzw. Sperren von Benutzernnur durch autorisierte Benutzer möglich sein.

Rechteprüfung

Das System muß bei jedem Zugriffsversuch von Benutzern bzw. Benutzergruppen zuden der Rechteverwaltung unterliegenden Objekten die Berechtigung überprüfen.Unberechtigte Zugriffsversuche müssen abgewiesen werden.

Beweissicherung

Das System muß eine Protokollierungskomponente enthalten, die in der Lage ist,folgende Ereignisse mit folgenden Daten zu protokollieren:

Benutzung des Identifikations- und Authentisierungsmechanismus.

Daten: Datum; Uhrzeit; Benutzer-Id., die angegeben wurde; Kennung desGerätes, an dem der Identifikations- und Authentisierungsmechanismusbenutzt wurde (z. B. Terminal-Id.); Erfolg bzw. Mißerfolg desVersuches.

1. Version 1989 - 29 - F2

Zugriff zu einem der Rechteverwaltung unterliegenden Objekt.

Daten: Datum; Uhrzeit; Benutzer-Id.; Name des Objektes; Art des Zugriffs-versuches; Erfolg bzw. Mißerfolg des Versuches.

Anlegen bzw. Löschen eines der Rechteverwaltung unterliegenden Objektes.

Daten: Datum; Uhrzeit; Benutzer-Id.; Name des Objektes; Art der Aktion.

Aktionen von Benutzern bzw. Rollen mit besonderen Rechten, die die Sicherheitdes Systems betreffen.

Daten: Datum; Uhrzeit; Benutzer-Id.; Art der Aktion; Name des Objektes, aufdas sich die Aktion bezog (Solche Aktionen sind z. B. Einbringen oderLöschen (Sperren) von Benutzern; Einbringen bzw. Entfernen vonDatenträgern; Starten bzw. Stoppen des Systems).

Der Zugriff zu den Protokollinformationen darf nur dazu autorisierten Benutzernmöglich sein. Es muß möglich sein, die Protokollierung auf einen oder mehrerebeliebig wählbare Benutzer zu beschränken. Es müssen Auswerte- undVerwaltungsprozeduren für die Protokolldaten vorhanden und dokumentiertsein. Der Aufbau der Protokollsätze muß vollständig beschrieben sein.

Wiederaufbereitung

Alle Speicherobjekte müssen vor einer Wiederverwendung durch andereBenutzer so aufbereitet werden, daß keine Rückschlüsse auf ihren früherenInhalt möglich sind.

F3 - 30 - 1. Version 1989

Funktionalitätsklasse F3(abgeleitet aus der Funktionalität der Orange Book Klasse B1)


Das System muß Benutzer identifizieren und authentisieren. Diese Identifikation undAuthentisierung muß vor jeder anderen Interaktion des Systems mit dem Benutzererfolgt sein. Nur nach einer erfolgreichen Identifikation und Authentisierung dürfenandere Interaktionen möglich sein. Die Authentisierungsinformationen müssen sogespeichert sein, daß nur autorisierte Benutzer Zugriff dazu besitzen. Bei jederdurchgeführten Interaktion muß das System die Identität des Benutzers feststellenkönnen.

Rechteverwaltung

Das System muß Zugriffsrechte zwischen Benutzern und/oder Benutzergruppen undObjekten, die der Rechteverwaltung unterliegen, kennen und verwalten. Dabei muß esmöglich sein, Benutzern bzw. Benutzergruppen den Zugriff zu einem Objekt ganz zuverwehren sowie den Zugriff auf einen nicht-modifizierenden Zugriff zu beschränken.Außerdem muß es möglich sein, für jeden Benutzer separat die Zugriffsrechte zueinem Objekt festzulegen. Vergabe und Entzug von Zugriffsrechten zu einem Objektdarf nur durch autorisierte Benutzer möglich sein. Die Weitergabe von Zugriffsrechtenmuß kontrollierbar sein. Ebenso darf das Einbringen neuer Benutzer sowie dasLöschen bzw. Sperren von Benutzern nur durch speziell autorisierte Benutzer möglichsein.

Zusätzlich muß das System alle Subjekte und Speicherobjekte, die seinerKontrolle unterliegen, mit Attributen versehen (dazu gehören z. B. Prozesse,Dateien, Speichersegmente, Geräte). Der Wert dieser Attribute muß dabei alsGrundlage für regelbasierte ("mandatory") Zugriffsrechte dienen. Diese Regelnmüssen festlegen, bei welchen Kombinationen von Attributwerten von Subjektund Objekt ein Subjekt ein bestimmtes Zugriffsrecht zu diesem Objekt besitzendarf.Beim Export eines attributierten Objektes müssen auch die Attribute so mitexportiert werden, daß der Empfänger deren Wert eindeutig rekonstruierenkann.

Die regelbasierten Zugriffsrechte müssen so gestaltet sein, daß sich folgenderSpezialfall realisieren läßt:

Das Attribut besteht aus zwei Teilen. Ein Teil besitzt einen hierarchischgeordneten Wertebereich, der andere Teil ist nicht hierarchisch. FolgendeRegeln müssen realisierbar sein:Lesender Zugriff eines Subjektes zu einem Objekt ist nur gestattet, wenn derWert des hierarchischen Attributteils beim Subjekt größer oder gleich dem Wertdes hierarchischen Attributteils beim Objekt ist, und der nicht-hierarchischeAttributteil des Subjektes eine Obermenge des nicht-hierarchischen Attributteilsdes Objektes ist.

1. Version 1989 - 31 - F3

Schreibender Zugriff eines Subjektes zu einem Objekt ist nur gestattet, wennder Wert des hierarchischen Attributteils beim Subjekt kleiner oder gleich demWert des hierarchischen Attributteils beim Objekt ist, und der nicht-hierarchische Attributteil des Subjektes eine Teilmenge des nicht-hierarchischenAttributteils des Objektes ist.Der Benutzer darf nur Subjekte erzeugen, deren Wert des hierarchischenAttributteils kleiner oder gleich dem bei der Identifikation angegebenen Wert istund dessen nicht-hierarchischer Attributteil eine Teilmenge des bei derIdentifikation angegebenen ist.

Beim Import von nicht-attributierten Daten müssen deren Attribute aufAnforderung des Systems durch einen autorisierten Benutzer festgelegt werden.Exportkanäle müssen entweder als einstufig oder als mehrstufig kennzeichenbarsein. Über als einstufig gekennzeichnete Kanäle dürfen nur Informationengesendet oder empfangen werden,deren Attribut einen fest vorgegebenen Wert besitzt. In diesem Fall braucht derAttributwert nicht mit übertragen werden, da er implizit durch die Einstufungdes Kanals festgelegt ist. Voraussetzung ist jedoch, daß die Einstufung desKanals durch einen autorisierten Benutzer in einer nicht täuschbaren Weisefestgelegt worden ist.Bei mehrstufigen Kanälen muß durch das Übertragungsprotokoll sichergestelltsein, daß die Empfängerseite alle Attributwerte vollständig rekonstruieren und ineindeutiger Weise der übertragenen Information zuordnen kann.Jede Änderung der Einordnung eines Kanals darf nur explizit durch autorisierteBenutzer erfolgen. Jede solche Änderung muß protokollierbar sein.

Das System muß menschenlesbare Ausgaben mit Attributwerten kennzeichnen.Die Werte der Attribute leiten sich aus den im System formulierten Regeln ab.Die Art und der Ort der Darstellung der Attribute muß dabei von einem speziellautorisierten Benutzer festlegbar sein.

Rechteprüfung

Das System muß bei jedem Zugriffsversuch von Benutzern bzw. Benutzergruppen zuden der Rechteverwaltung unterliegenden Objekten die Berechtigung überprüfen.Unberechtigte Zugriffsversuche müssen abgewiesen werden.Der Wert der Attribute soll als Grundlage einer regelbasierten Rechteprüfungdienen. Diese Regeln müssen eindeutig festlegen, wann ein Subjekt Zugriff zueinem derart geschützten Objekt besitzen darf. Falls für ein Objekt zusätzlichnoch diskrete Zugriffsrechte vergeben worden sind, darf ein Zugriff nurzugelassen werden, wenn sowohl die diskreten als auch die regelbasiertenZugriffsrechte diesen Zugriff gestatten.

F3 - 32 - 1. Version 1989

Beweissicherung


Benutzung des Identifikations- und Authentisierungsmechanismus

Daten: Datum; Uhrzeit; Benutzer-Id. die angegeben wurde; Kennzeichnung desGerätes, an dem der Identifikations- und Authentisierungsmechanismusbenutzt wurde (z.B. Terminal-Id.); Erfolg bzw. Mißerfolg des Versuches;angegebene Attributwerte des Benutzers.

Zugriffsversuch zu einem der Rechteverwaltung unterliegenden Objekt

Daten: Datum; Uhrzeit; Benutzer-Id.; Name des Objektes; Art des Zugriffsversuches;Erfolg bzw. Mißerfolg des Versuches; Attributwerte des Objektes.

Anlegen bzw. Löschen eines der Rechteverwaltung unterliegenden Objektes

Daten: Datum; Uhrzeit; Benutzer-Id.; Name des Objektes; Art der Aktion;Attributwerte des Objektes.

Aktionen von Benutzern bzw. Rollen mit besonderen Rechten, die die Sicherheit desSystems betreffen

Daten: Datum; Uhrzeit; Benutzer-Id.; Art der Aktion; Name und Attributwerte desObjektes, auf das sich die Aktion bezog.

(Solche Aktionen sind z. B. Einbringen oder Löschen (Sperren) von Benutzern;Einbringen bzw. Entfernen von Datenträgern; Starten bzw. Stoppen des Systems;Erzeugen und Ändern von Attributwerten; Ändern von Ausgabekennzeichen;Ändern der Einstufung von Kanälen).

Der Zugriff zu den Protokollinformationen darf nur autorisierten Benutzern möglichsein. Es muß möglich sein, die Protokollierung auf einen oder mehrere beliebigwählbare Benutzer und/oder Attributwerte von Objektenzu beschränken. Esmüssen Auswerte- und Verwaltungsprozeduren für die Protokolldaten vorhanden unddokumentiert sein. Der Aufbau der Protokollsätze muß vollständig beschrieben sein.

Wiederaufbereitung

Alle Speicherobjekte müssen vor einer Wiederverwendung durch andere Benutzer soaufbereitet werden, daß keine Rückschlüsse auf ihren früheren Inhalt möglich sind.

1. Version 1989 - 33 - F4

Funktionalitätsklasse F4(abgeleitet aus der Funktionalität der Orange Book Klasse B2)


Das System muß Benutzer identifizieren und authentisieren. Diese Identifikation undAuthentisierung muß vor jeder anderen Interaktion des Systems mit dem Benutzererfolgt sein. Nur nach einer erfolgreichen Identifikation und Authentisierung dürfenandere Interaktionen möglich sein. Die Authentisierungsinformationen müssen sogespeichert sein, daß nur autorisierte Benutzer Zugriff dazu besitzen.Identifikation und Authentisierung müssen über einen vertrauenswürdigen Pfadzwischen Benutzer und System abgewickelt werden, initiert durch den Benutzer.Bei jeder durchgeführten Interaktion muß das System die Identität des Benutzersfeststellen können.

Rechteverwaltung

Das System muß Zugriffsrechte zwischen Benutzern und/oder Benutzergruppen undObjekten, die der Rechteverwaltung unterliegen, kennen und verwalten.Zugriffsrechte müssen zu Rollen gruppierbar sein. Minimal müssen die Rollenvon Operator und Systemadministrator definierbar sein.Dabei muß es möglich sein, Benutzern bzw. Benutzergruppen den Zugriff zu einemObjekt ganz zu verwehren sowie den Zugriff auf einen nicht-modifizierenden Zugriffzu beschränken. Außerdem muß es möglich sein, für jeden Benutzer separat dieZugriffsrechte zu einem Objekt festzulegen. Vergabe und Entzug von Zugriffsrechten zueinem Objekt darf nur durch autorisierte Benutzer möglich sein. Die Weitergabe vonZugriffsrechten muß kontrollierbar sein. Ebenso darf das Einbringen neuer Benutzersowie das Löschen bzw. Sperren von Benutzern nur durch speziell autorisierteBenutzer möglich sein.

Zusätzlich muß das System alle Subjekte und Objekte mit Attributen versehen (dazugehören z. B. Prozesse, Dateien, Speichersegmente, Geräte). Der Wert dieserAttribute muß dabei als Grundlage für regelbasierte ("mandatory") Zugriffsrechtedienen. Diese Regeln müssen festlegen, bei welchen Kombinationen vonAttributwerten von Subjekt und Objekt ein Subjekt ein bestimmtes Zugriffsrecht zudiesem Objekt besitzen darf.Beim Export eines attributierten Objektes müssen auch die Attribute so mit exportiertwerden, daß der Empfänger deren Wert eindeutig rekonstruieren kann.

Die regelbasierten Zugriffsrechte müssen so gestaltet sein, daß sich folgender Spe-zialfall realisieren läßt:

Das Attribut besteht aus zwei Teilen. Ein Teil besitzt einen hierarchisch geordnetenWertebereich, der andere Teil ist nicht hierarchisch. Folgende Regeln müssen reali-sierbar sein:

F4 - 34 - 1. Version 1989

Lesender Zugriff eines Subjektes zu einem Objekt ist nur gestattet, wenn der Wert deshierarchischen Attributteils beim Subjekt größer oder gleich dem Wert deshierarchischen Attributteils beim Objekt ist, und der nicht-hierarchische Attributteildes Subjektes eine Obermenge des nicht-hierarchischen Attributteils des Objektes ist.Schreibender Zugriff eines Subjektes zu einem Objekt ist nur gestattet, wenn der Wertdes hierarchischen Attributteils beim Subjekt kleiner oder gleich dem Wert deshierarchischen Attributteils beim Objekt ist, und der nicht-hierarchische Attributteildes Subjektes eine Teilmenge des nicht-hierarchischen Attributteils des Objektes ist.Der Benutzer darf nur Subjekte erzeugen, deren Wert des hierarchischen Attributteilskleiner oder gleich dem bei der Identifikation angegebenen Wert ist und dessen nicht-hierarchischer Attributteil eine Teilmenge des bei der Identifikation angegebenen ist.

Beim Import von nicht-attributierten Daten müssen deren Attribute auf Anforderungdes Systems durch einen autorisierten Benutzer festgelegt werden.Exportkanäle müssen entweder als einstufig oder als mehrstufig kennzeichenbar sein.Über als einstufig gekennzeichnete Kanäle dürfen nur Informationen gesendet oderempfangen werden, deren Attribut einen fest vorgegebenen Wert besitzt. In diesemFall braucht der Attributwert nicht mit übertragen werden, da er implizit durch dieEinstufung des Kanals festgelegt ist. Voraussetzung ist jedoch, daß die Einstufung desKanals durch einen autorisierten Benutzer in einer nicht täuschbaren Weise festgelegtworden ist.Bei mehrstufigen Kanälen muß durch das Übertragungsprotokoll sichergestellt sein,daß die Empfängerseite alle Attributwerte vollständig rekonstruieren und ineindeutiger Weise der übertragenen Information zuordnen kann.Für mehrstufige Kanäle muß es möglich sein, den maximalen und minimalenAttributwert anzugeben, den die übertragene Information besitzen darf.Jede Änderung der Einordnung eines Kanals darf nur explizit durch autorisierteBenutzer erfolgen. Jede solche Änderung muß protokollierbar sein.

Das System muß menschenlesbare Ausgaben mit Attributwerten kennzeichnen. DieWerte der Attribute leiten sich aus den im System formulierten Regeln ab. Die Art undder Ort der Darstellung der Attribute muß dabei von einem speziell autorisiertenBenutzer festlegbar sein.

Jede Änderung der Attributwerte aller Subjekte, die für einen Benutzer in einerlaufenden interaktiven Sitzung aktiv sind, muß diesem Benutzer sofort angezeigtwerden. Der Benutzer muß jederzeit die Möglichkeit haben, sich dieAttributwerte aller Subjekte, die für diesen Benutzer in einer laufendeninteraktiven Sitzung aktiv sind, anzeigen zu lassen.

Rechteprüfung

Das System muß bei jedem Zugriffsversuch von Benutzern bzw. Benutzergruppen zuden der Rechteverwaltung unterliegenden Objekten die Berechtigung überprüfen.Unberechtigte Zugriffsversuche müssen abgewiesen werden. Der Wert der Attribute

1. Version 1989 - 35 - F4

soll als Grundlage einer regelbasierten Rechteprüfung dienen. Diese Regeln müsseneindeutig festlegen, wann ein Subjekt Zugriff zu einem derart geschützten Objektbesitzen darf. Falls für ein Objekt zusätzlich noch diskrete Zugriffsrechte vergebenworden sind, darf ein Zugriff nur zugelassen werden, wenn sowohl die diskreten alsauch die regelbasierten Zugriffsrechte diesen Zugriff gestatten.

Beweissicherung



Daten: Datum; Uhrzeit; Benutzer-Id. die angegeben wurde; Kennzeichnung desGerätes, an dem der Identifikations- und Authentisierungsmechanismusbenutzt wurde (z.B. Terminal-Id.); Erfolg bzw. Mißerfolg des Versuches;angegebene Attributwerte des Benutzers.


Daten: Datum; Uhrzeit; Benutzer-Id.; Name des Objektes; Art des Zugriffsversuches;Erfolg bzw. Mißerfolg des Versuches; Attributwerte des Objektes.





(Solche Aktionen sind z. B. Einbringen oder Löschen (Sperren) von Benutzern;Einbringen bzw. Entfernen von Datenträgern; Starten bzw. Stoppen des Systems;Erzeugen und Ändern von Attributwerten; Ändern von Ausgabekennzeichen; Ändernder Einstufung von Kanälen).

Der Zugriff zu den Protokollinformationen darf nur autorisierten Benutzern möglichsein. Es muß möglich sein, die Protokollierung auf einen oder mehrere beliebigwählbare Benutzer und/oder Attributwerte von Objekten zu beschränken. Es müssenAuswerte- und Verwaltungsprozeduren für die Protokolldaten vorhanden unddokumentiert sein. Der Aufbau der Protokollsätze muß vollständig beschrieben sein.

Außerdem muß das System die Möglichkeit besitzen, bekannte Ereignisse zuprotokollieren, die zu einem unerlaubten Informationsfluß durch Ausnutzungverdeckter Speicherkanäle führen können.

Wiederaufbereitung

F4 - 36 - 1. Version 1989


1. Version 1989 - 37 - F5

Funktionalitätsklasse F5(abgeleitet aus der Funktionalität der Orange Book Klassen B3/A1)


Das System muß Benutzer identifizieren und authentisieren. Diese Identifikation undAuthentisierung muß vor jeder anderen Interaktion des Systems mit dem Benutzererfolgt sein. Nur nach einer erfolgreichen Identifikation und Authentisierung dürfenandere Interaktionen möglich sein. Die Authentisierungsinformationen müssen sogespeichert sein, daß nur autorisierte Benutzer Zugriff dazu besitzen. Identifikationund Authentisierung müssen über einen vertrauenswürdigen Pfad zwischen Benutzerund System abgewickelt werden, initiiert durch den Benutzer oder durch das System.Bei jeder durchgeführten Interaktion muß das System die Identität des Benutzersfeststellen können.In den Sicherheitsanforderungen können neben dem Login weitere Aktionenfestgelegt sein, vor deren Ausführung eine zusätzliche Identifikation undAuthentisierung erforderlich ist.

Rechteverwaltung

Das System muß Zugriffsrechte zwischen Benutzern und/oder Benutzergruppen undObjekten, die der Rechteverwaltung unterliegen, kennen und verwalten. Zugriffsrechtemüssen zu Rollen gruppierbar sein. Minimal müssen die Rollen von Operator und Sy-stemadministrator definierbar sein.Die Rollen von Operator, Systemverwalter und Sicherheitsverantwortlichemmüssen klargetrennt sein. Dabei muß es möglich sein, Benutzern bzw. Benutzergruppen denZugriff zu einem Objekt ganz zu verwehren sowie den Zugriff auf einen nicht-modifizierenden Zugriff zu beschränken. Außerdem muß es möglich sein, für jedenBenutzer separat die Zugriffsrechte zu einem Objekt festzulegen. Vergabe und Entzugvon Zugriffsrechten zu einem Objekt darf nur durch autorisierte Benutzer möglich sein.Die Weitergabe von Zugriffsrechten muß kontrollierbar sein. Ebenso darf dasEinbringen neuer Benutzer sowie das Löschen bzw. Sperren von Benutzern nur durchspeziell autorisierte Benutzer möglich sein.

Es muß möglich sein, für jedes Objekt, welches der Kontrolle der diskretenRechteverwaltung unterliegt, eine Liste von Benutzern sowie eine Liste vonBenutzergruppen mit ihren jeweiligen Zugriffsrechten zu diesem Objektanzugeben. Außerdem muß es möglich sein, zu jedem solchen Objekt eine Listevon Benutzern sowie eine Liste von Benutzergruppen anzugeben, die keinZugriffsrecht zu diesem Objekt besitzen sollen.

Zusätzlich muß das System alle Subjekte und Objekte mit Attributen versehen (dazugehören z. B. Prozesse, Dateien, Speichersegmente, Geräte). Der Wert dieserAttribute muß dabei als Grundlage für regelbasierte ("mandatory") Zugriffsrechtedienen. Diese Regeln müssen festlegen, bei welchen Kombinationen von

F5 - 38 - 1. Version 1989

Attributwerten von Subjekt und Objekt ein Subjekt ein bestimmtes Zugriffsrecht zudiesem Objekt besitzen darf.Beim Export eines attributierten Objektes müssen auch die Attribute so mit exportiertwerden, daß der Empfänger deren Wert eindeutig rekonstruieren kann.

Die regelbasierten Zugriffsrechte müssen so gestaltet sein, daß sich folgender Spe-zialfall realisieren läßt:

Das Attribut besteht aus zwei Teilen. Ein Teil besitzt einen hierarchisch geordnetenWertebereich, der andere Teil ist nicht hierarchisch. Folgende Regeln müssen reali-sierbar sein:Lesender Zugriff eines Subjektes zu einem Objekt ist nur gestattet, wenn der Wert deshierachischen Attributteils beim Subjekt größer oder gleich dem Wert deshierarchischen Attributteils beim Objekt ist, und der nicht-hierarchische Attributteildes Subjektes eine Obermenge des nicht-hierarchischen Attributteils des Objektes ist.Schreibender Zugriff eines Subjektes zu einem Objekt ist nur gestattet, wenn der Wertdes hierarchischen Attributteils beim Subjekt kleiner oder gleich dem Wert derhierarchischen Attributteils beim Objekt ist, und der nicht-hierarchische Attributteildes Subjektes eine Teilmenge des nicht-hierarchischen Attributteils des Objektes ist.Der Benutzer darf nur Subjekte erzeugen, deren Wert des hierarchischen Attributteilskleiner oder gleich dem bei der Identifikation angegebenen Wert ist und dessen nicht-hierarchischer Attributteil eine Teilmenge des bei der Identifikation angegebenen ist.

Beim Import von nicht-attributierten Daten müssen deren Attribute auf Anforderungdes Systems durch einen autorisierten Benutzer festgelegt werden.

Exportkanäle müssen entweder als einstufig oder als mehrstufig kennzeichenbar sein.Über als einstufig gekennzeichnete Kanäle dürfen nur Informationen gesendet oderempfangen werden, deren Attribut einen fest vorgegebenen Wert besitzt. In diesemFall braucht der Attributwert nicht mit übertragen werden, da er implizit durch dieEinstufung des Kanals festgelegt ist. Voraussetzung ist jedoch, daß die Einstufung desKanals durch einen autorisierten Benutzer in einer nicht täuschbaren Weise festgelegtworden ist.Bei mehrstufigen Kanälen muß durch das Übertragungsprotokoll sichergestellt sein,daß die Empfängerseite alle Attributwerte vollständig rekonstruieren und ineindeutiger Weise der übertragenen Information zuordnen kann. Für mehrstufigeKanäle muß es möglich sein, den maximalen und minimalen Attributwert anzugeben,den die übertragene Information besitzen darf.Jede Änderung der Einordnung eines Kanals darf nur explizit und nur durchautorisierte Benutzer erfolgen. Jede solche Änderung muß protokollierbar sein.

Das System muß menschenlesbare Ausgaben mit Attributwerten kennzeichnen. DieWerte der Attribute leiten sich aus den im System formulierten Regeln ab. Die Art undder Ort der Darstellung der Attribute muß dabei von einem speziell autorisiertenBenutzer festlegbar sein.

1. Version 1989 - 39 - F5

Jede Änderung der Attributwerte aller Subjekte, die für einen Benutzer in einerlaufenden interaktiven Sitzung aktiv sind, muß diesem Benutzer sofort angezeigtwerden. Der Benutzer muß jederzeit die Möglichkeit haben, sich die Attributwertealler Subjekte, die für diesen Benutzer in einer laufenden interaktiven Sitzung aktivsind, anzeigen zu lassen.

Rechteprüfung

Das System muß bei jedem Zugriffsversuch von Benutzern bzw. Benutzergruppen zuden der Rechteverwaltung unterliegenden Objekten die Berechtigung überprüfen.Unberechtigte Zugriffsversuche müssen abgewiesen werden. Der Wert der Attributesoll als Grundlage einer regelbasierten Rechteprüfung dienen. Diese Regeln müsseneindeutig festlegen, wann ein Subjekt Zugriff zu einem derart geschützten Objektbesitzen darf. Falls für ein Objekt zusätzlich noch diskrete Zugriffsrechte vergebenworden sind, darf ein Zugriff nur zugelassen werden, wenn sowohl die diskreten alsauch die regelbasierten Zugriffsrechte diesen Zugriff gestatten.

Beweissicherung



Daten: Datum; Uhrzeit; Benutzer-Id., die angegeben wurde; Kennzeichen desGerätes, an dem der Identifikations- und Authentisierungsmechanismusbenutzt wurde (z.B. Terminal-Id.); Erfolg bzw. Mißerfolg des Versuches;angegebene Attributwerte des Benutzers.


Daten: Datum; Uhrzeit; Benutzer-Id.; Name des Objektes:; Art des Zugriffs-versuches; Erfolg bzw. Mißerfolg des Versuches; Attributwerte desObjektes.





(Solche Aktionen sind z. B. Einbringen oder Löschen (Sperren) von Benutzern;Einbringen bzw. Entfernen von Datenträgern; Starten bzw. Stoppen des Systems;Erzeugen und Ändern von Attributwerten: Ändern von Ausgabekennzeichen; Ändernder Einstufung von Kanälen).

F5 - 40 - 1. Version 1989

Nur autorisierten Benutzern darf der Zugriff zu den Protokollinformationen möglichsein. Es muß möglich sein, die Protokollierung auf einen oder mehrere beliebigwählbare Benutzer und/oder Attributwerte von Objekten zu beschränken. Es müssenAuswerte- und Verwaltungsprozeduren für die Protokolldaten vorhanden unddokumentiert sein. Der Aufbau der Protokollsätze muß vollständig beschrieben sein.

Ferner muß ein Mechanismus existieren, der das Auftreten von Ereignissenüberwacht, die entweder besonders sicherheitskritisch sind bzw. durch ihrhäufiges Auftreten zu einer kritischen Bedrohung der Sicherheit des Systemswerden können. Dieser Mechanismus muß in der Lage sein, sofort einen speziel-len Benutzer bzw. Benutzer mit einer speziellen Rolle über das Eintreten solcherEreignisse zu informieren. Der Mechanismus soll auch in der Lage sein, insolchen Fällen selbsttätig Aktionen zu ergreifen, durch die ein weiteresAuftreten solcher Ereignisse unterbunden wird.

Außerdem muß das System die Möglichkeit besitzen, bekannte Ereignisse zuprotokollieren, die zu einem unerlaubten Informationsfluß durch Ausnutzungverdeckter Speicherkanäle mißbraucht werden können.

Wiederaufbereitung


1. Version 1989 - 41 - F6

Funktionalitätsklasse F6

Zielrichtung

Die Funktionalitätsklasse F6 zielt auf Systeme mit hohen Anforderungen bezüglich derIntegrität von Daten und Programmen. Solche Anforderungen können zum Beispiel beiDatenbanksystemen sinnvoll sein.



Rechteverwaltung

Das System muß Zugriffsrechte zwischen Benutzern, Rollen und Prozessen zu spe-ziellen Objekten kennen und verwalten. Rollen sind dabei als Benutzer mit speziellenAttributen zu verstehen. Dabei muß es möglich sein, den Zugriff von Benutzern aufdiese Objekte so einzuschränken, daß dieser Zugriff nur über speziell festgelegteProzesse möglich ist.Ferner muß es möglich sein, Objekte einem vordefinierten Typ zuzuordnen. Es mußmöglich sein, für jeden Typ von Objekten festzulegen, welche Benutzer, Rollen oderProzesse Zugriff einer bestimmten Art zu diesen Objekten besitzen können. Dadurchsoll es möglich sein, den Zugriff von Benutzern auf Objekte eines bestimmten Typs soeinzuschränken, daß dieser Zugriff nur über festgelegte Prozesse möglich ist. Nur spe-ziell autorisierten Benutzern darf es möglich sein, neue Typen zu definieren bzw.Zugriffsrechte zu Typen zu vergeben oder zu entziehen. Diese Aktionen müssenexplizit von diesem Benutzer initiiert werden. Alle Kommunikationen zwischen demSystem und dem Benutzer müssen bei diesen Aktionen über einen vertrauenswürdigenPfad ablaufen. Dadurch soll verhindert werden, daß diese Aktionen durch trojanischePferde mißbraucht werden können.Folgende Zugriffsrechte müssen mindestens existieren:Lesen, Schreiben, Anfügen, Löschen, Umbenennen (für Objekte)Ausführen, Löschen, Umbenennen (für ausführbare Objekte)Anlegen von Objekten eines bestimmten Typs, Löschen von Objekten eines be-stimmten Typs.

F6 - 42 - 1. Version 1989

Rechteprüfung

Das System soll bei jedem Zugriffsversuch von Benutzern bzw. Benutzergruppen zuden der Rechteverwaltung unterliegenden Objekten die Berechtigung überprüfen.Unberechtigte Zugriffsversuche müssen abgewiesen werden.

Beweissicherung

Das System muß eine Protokollierungskomponente enthalten, die in der Lage ist,mindestens folgende Ereignisse mit folgenden Daten zu protokollieren:


Daten: Datum; Uhrzeit; Benutzer-Id. die angegeben wurde; Kennzeichnung desGerätes, an dem der Identifikations- und Authentisierungsmechanismusbenutzt wurde (z.B. Terminal-Id); Erfolg bzw. Mißerfolg des Versuches.


Daten: Datum; Uhrzeit; Benutzer-Id.; Name des Objektes; Art des Zugriffsversuches;Erfolg bzw. Mißerfolg des Versuches.


Daten: Datum; Uhrzeit; Benutzer-Id.; Name des Objektes; Art der Aktion.

Aktionen von Benutzern bzw. Rollen, mit besonderen Rechten, die die Sicherheit desSystems betreffen

Daten: Datum; Uhrzeit; Benutzer-Id.; Art der Aktion; Name(n) der Subjekte bzw.Objekte, auf die sich die Aktion bezog.

(Solche Aktionen sind z. B. Einbringen oder Löschen (Sperren) von Benutzern;Einbringen bzw. Entfernen von Datenträgern; Starten bzw. Stoppen des Systems.)

Anlegen bzw. Löschen von Typen

Daten: Datum; Uhrzeit; Benutzer-Id.; Art der Aktion; Name des Typs.

Vergabe eines Typs für ein Objekt

Daten: Datum; Uhrzeit; Benutzer-Id.; Name des Objektes; Name des Typs.

Vergabe oder Entzug von Zugriffsrechten zu einem Objekt bzw. zu einem Objekttyp

Daten: Datum; Uhrzeit; Benutzer-Id.; Art der Aktion; Art des Zugriffsrechtes; Namedes Subjektes; Name des Objektes bzw. Name des Objekttyps.

Nur autorisierten Benutzern darf der Zugriff zu den Protokollinformationen möglichsein. Es muß möglich sein, die Protokollierung auf einen oder mehrere beliebigwählbare Benutzer zu beschränken. Es müssen Auswerte- und Verwaltungsprozedurenfür die Protokolldaten vorhanden und dokumentiert sein. Der Aufbau derProtokollsätze muß detailliert beschrieben sein.

1. Version 1989 - 43 - F7


Zielrichtung

Die Funktionalitätsklasse F7 stellt starke Anforderungen an die Verfügbarkeit einesSystems bzw. spezieller Funktionen eines Systems. Solche Anforderungen sind z. B.bei Prozeßsteuerungsrechnern sinnvoll.

Fehlerüberbrückung

Das System muß in der Lage sein, den Ausfall bestimmter einzelnerHardwarekomponenten (z. B. einer Platte oder eines einzelnen Prozessors in einemMehrprozessorsystem) so zu überbrücken, daß alle fortlaufend benötigten Funktionenauch in dem Restsystem kontinuierlich zur Verfügung stehen. Nach Reparatur derausgefallenen Komponente muß diese so wieder in das System integriert werdenkönnen, daß eine kontinuerliche Aufrechterhaltung der fortlaufend benötigtenFunktionen gegeben ist. Nach der Integration muß das System wieder denursprünglichen Grad der Ausfallsicherheit erreicht haben. Für die Dauer einessolchen Reintegrationsprozesses müssen Maximalzeiten angegeben werden.

Gewährleistung der Funktionalität

Das System muß in der Lage sein, unabhängig von seiner momentanen Belastung fürbestimmte festgelegte Aktionen eine maximale Reaktionszeit zu garantieren.Außerdem muß für festgelegte Aktionen die Verklemmungsfreiheit des Systemsgewährleistet sein.

F8 - 44 - 1. Version 1989


Zielrichtung

Die Funktionalitätsklasse F8 stellt Anforderungen an die Sicherung der Integrität vonDaten bei der Datenübertragung.



Vor dem Beginn einer Datenübertragung muß die Gegenseite (Rechner, Prozeß oderBenutzer) identifiziert und authentisiert werden. Nur nach erfolgreicher Identifikationund Authentisierung darf eine Übertragung von Nutzdaten erfolgen.Beim Empfang von Daten muß deren Sender identifiziert und authentisiert werdenkönnen. Alle Authentisierungsinformationen müssen vor unbefugtem Zugriff und vorFälschung geschützt sein.

Übertragungssicherung

Bei der Datenübertragung müssen Methoden zur Fehlererkennung und Fehlerkorrektureingesetzt werden. Diese Verfahren müssen so gestaltet sein, daß auch absichtlicheManipulationen an den Adressfeldern und den Nutzdaten erkannt werden können.Auch darf die bloße Kenntnis der bei den Verfahren eingesetzten Algorithmen ohnespezielle Zusatzkenntnisse nicht dazu führen, daß nicht erkannte Manipulationen anden oben genannten Daten durchgeführt werden können. Die dazu benötigtenZusatzkenntnisse müssen so geschützt sein, daß höchstens einige wenige speziellautorisierte Benutzer Zugang dazu besitzen.Außerdem müssen Verfahren eingesetzt werden, die auch ein unbefugtesWiedereinspielen von alten Datenströmen sicher als Fehler erkennen.

Beweissicherung



Daten: Datum; Uhrzeit; Initiator der Identifikation und Authentisierung; Name des zuidentifizierenden Subjektes; Erfolg oder Mißerfolg der Aktion.

1. Version 1989 - 45 - F8

Erkannte Fehler bei der Datenübertragung

Daten: Datum; Uhrzeit; Partner bei der Datenübertragung; Art des Fehlers; Erfolgoder Mißerfolg beim Korrekturversuch.

Verbindungsaufbau zur Datenübertragung

Daten: Datum; Uhrzeit; Benutzer-Id. des Initiators; Name des Subjektes (Rechner,Prozeß oder Benutzer) auf der Empfängerseite; Parameter des Verbindungs-aufbaus (falls diese variabel sind).

F9 - 46 - 1. Version 1989


Zielrichtung

Die Funktionalitätsklasse F9 ist für Systeme gedacht, die hohe Anforderungen an dieGeheimhaltung von Daten bei der Datenübertragung verlangen. Als Kandidaten fürdiese Klasse kommen zum Beispiel spezielle Verschlüsselungsgeräte in Betracht.


Das System muß die Möglichkeit bieten, Nutzinformationen vor einer Übertragungautomatisch zu verschlüsseln sowie (auf Empfängerseite) automatisch zuentschlüsseln. Dabei muß ein geprüftes und von einer autorisierten Prüfstellezugelassenes Verfahren eingesetzt werden. Es muß sichergestellt sein, daß die zumEntschlüsseln benötigten Parameterwerte so geschützt sind, daß kein UnbefugterZugang zu diesen Daten besitzt.

1. Version 1989 - 47 - F10


Zielrichtung

Die Funktionalitätsklasse F10 ist für vernetzte Systeme gedacht, die hoheAnforderungen an die Geheimhaltung und Integrität der zu übertragendenInformationen stellen. Dies kann zum Beispiel der Fall sein, wenn sensitiveInformationen über nicht absicherbare (z.B. öffentliche) Netze übertragen werdenmüssen.



Vor dem Beginn einer Datenübertragung muß die Gegenseite (Rechner, Prozeß oderBenutzer) identifiziert und authentisiert werden. Nur nach erfolgreicher Identifikationund Authentisierung darf eine Übertragung von Nutzdaten erfolgen.Beim Empfang von Daten muß deren Sender identifiziert und authentisiert werdenkönnen. Alle Authentisierungsinformationen müssen vor unbefugtem Zugriff und vorFälschung geschützt sein.


Das System bietet die Möglichkeit einer Ende-zu-Ende-Verschlüsselung, die eineGeheimhaltung des Empfängers auf weiten Teilen des Übertragungsweges umfaßt.Ebenso ist die Geheimhaltung des Verkehrsaufkommens auf speziellenDatenübertragungsleitungen gegeben. Das System muß so gestaltet sein, daß unbefugteManipulationen von Nutzdaten und Protokolldaten sowie das unbefugteWiedereinspielen von alten Daten sicher als Fehler erkannt werden. Alle Parameter,die zu einer unbefugten Entschlüsselung benutzt werden können, sind so zu schützen,daß nur solche Personen Zugang zu diesen Daten besitzen, die diesen Zugang zurErfüllung ihrer Aufgaben unbedingt benötigen.

Beweissicherung



F10 - 48 - 1. Version 1989

Daten: Datum; Uhrzeit; Initiator der Identifikation und Authentisierung; Name des zuidentifizierenden Subjektes; Erfolg oder Mißerfolg der Aktion.

Erkannte Fehler bei der Datenübertragung

Daten: Datum; Uhrzeit; Partner bei der Datenübertragung; Art des Fehlers; Erfolgoder Mißerfolg beim Korrekturversuch.

Verbindungsaufbau zur Datenübertragung

Daten: Datum; Uhrzeit; Benutzer-Id. des Initiators; Name des Subjektes (Rechner,Prozeß oder Benutzer) auf der Empfängerseite; Parameter des Verbindungs-aufbaus (falls diese variabel sind).

Spezielle Datenübertragungstransaktionen

Daten: Datum; Uhrzeit; Benutzer-Id. des Senders; Benutzer-Id. des Empfängers;übertragene Nutzinformationen; Datum und Uhrzeit des Empfangs der Daten.

1. Version 1989 - 49 -

6. Qualitätskriterien und Qualitätsstufen

6.1 Einzelaspekte der Qualitätskriterien

Zur Beurteilung der Qualität der Sicherheitsfunktionen eines Systems bzw. einerEinzelkomponente sind eine Reihe von Einzelaspekten zu untersuchen und zubewerten. Diese Einzelaspekte lassen sich in die folgenden Bereiche gliedern:

- Qualität der Sicherheitsanforderungen

- Qualität der Spezifikation der zu evaluierenden Systemteile

- Qualität der verwendeten Mechanismen

- Qualität der Abgrenzung zu nicht zu evaluierenden Systemteilen

- Qualität des Herstellungsvorganges

- Betriebsqualität

- Qualität der anwenderbezogenen Dokumentation

Die Einzelaspekte in diesen Bereichen werden in den folgenden Abschnittendargelegt. Die konkreten Anforderungen für diese Einzelaspekte sind dann beiden einzelnen Qualitätsstufen beschrieben.

6.1.1 Qualität der Sicherheitsanforderungen

Obwohl bei den Qualitätskriterien explizit nicht die Erfüllung bestimmterSicherheitsanforderungen oder Sicherheitsmodelle verlangt wird, kann dennochdie Qualität der vom Auftraggeber der Prüfbehörde zur Evaluation mitvorgelegten Sicherheitsanforderungen nach einer Reihe von Qualitätskriterienuntersucht werden, die unabhängig von der konkreten Funktionalität derSicherheitsfunktionen sind. Dies sind im einzelnen:

- Die Art der Darstellung der Sicherheitsanforderungen(z. B. verbal, semiformal oder als formales Sicherheitsmodell).

- Konsistenz und Widerspruchsfreiheit der Sicherheitsanforderungen d.h. eskann (in gewissen Grenzen abhängig von der Darstellungsform und der Artder Sicherheitsanforderungen) geprüft werden, ob die aufgestelltenSicherheitsanforderungen in dieser Form überhaupt sinnvoll sind.

- 50 - 1. Version 1989

6.1.2 Qualität der Spezifikation der zu evaluierenden Systemteile

Auch für die Spezifikation der zu evaluierenden Systemteile kann eine Reihevon Aspekten angegeben werden, die bei der Beurteilung der Qualität einersolchen Spezifikation betrachtet werden müssen. Dies sind im einzelnen:

- Die Art der Darstellung der Spezifikation(verbal, semiformal oder formal).

- Der Detaillierungsgrad sowie die Struktur der Spezifikation.Dies beinhaltet sowohl die horizontale Struktur, d. h. die Art der Aufteilungin unabhängige Funktionseinheiten, als auch die vertikale Struktur, d. h. Zahlund Art der hierarchischen Verfeinerungen.

- Die Darstellung der Abbildung der Spezifikation auf die Sicherheitsanfor-derungen.

- Die Nachvollziehbarkeit dieser Abbildung.

- Die Darstellung und Nachvollziehbarkeit der Abbildung zweier benachbarterHierarchiestufen der Spezifikation aufeinander.

- Die Nachvollziehbarkeit der Nebeneffektfreiheit der Spezifikation.

- Die Qualität der bei der Spezifikation verwendeten Werkzeuge(z. B. Spezifikationssprachen, Prüfwerkzeuge).

6.1.3 Qualität der verwendeten Mechanismen

Die Qualität der verwendeten Mechanismen ist ein weiteres Kriterium zurBeurteilung der Gesamtqualität eines Systems oder einer Einzelkomponente.Dabei sind zwei Aspekte zu untersuchen:

- Die Eignung des Mechanismus zur Erfüllung der aufgestellten Sicherheits-anforderung(en).

- Die Stärke des Mechanismus, mit der er das für die angestrebteQualitätsstufe notwendige Vertrauen in seine Wirksamkeit liefert.

Diese beiden Aspekte sind insbesondere auch für die Mechanismen zuuntersuchen, mit denen die zu evaluierenden Teile des Systems von den nicht zuevaluierenden Teilen separiert werden.

1. Version 1989 - 51 -

6.1.4 Qualität der Abgrenzung zu nicht zu evaluierenden Systemteilen

Ein sehr wichtiges Kriterium ist die Qualität, mit der die zu evaluierenden Teiledes Systems von anderen, nicht zu evaluierenden Teilen getrennt sind. Hierzusind zu untersuchen:

- Ob die Sicherheitsfunktionen, die durch die zu evaluierenden Systemteilerealisiert werden sollen, von anderen Komponentendes Systems umgangenwerden können.

- Ob die Sicherheitsfunktionen von anderen Systemkomponenten getäuschtwerden können.

- Ob die Sicherheitsfunktionen von anderen Systemkomponenten in einerWeise mißbraucht werden können, die einen Verstoß gegen dieSicherheitsanforderungen darstellt.

Hierzu ist die Qualität zu begutachten, mit der die Integrität und korrekteFunktionalität der Sicherheitsfunktionen auch bei böswilligen Aktionen einesBenutzers unter Ausnutzung nicht evaluierter Systemkomponenten eingehaltenwird. Böswillige Aktionen können dabei sowohl Aktionen sein, mit denenversucht wird, die Abgrenzung der Sicherheitsfunktionen zu anderenSystemteilen aufzubrechen, als auch solche, die versuchen, die vorhandenenSchnittstellen in einer Weise zu mißbrauchen, die einen Verstoß gegen dieSicherheitsanforderungen darstellt.

Dabei wird sich in vielen Fällen herausstellen, daß es Teile des Systems gibt,die zwar nicht direkt zur Erfüllung der Sicherheitsanforderungen beitragen,jedoch von den Sicherheitsfunktionen nicht oder nicht ausreichend getrennt sind.Da nicht ausgeschlossen werden kann, daß diese Teile die Funktionalität derSicherheitsfunktionen beeinflussen, sind diese Teile auch einer Evaluation zuunterziehen.

6.1.5 Qualität des Herstellungsvorganges

Schwierigster Punkt bei der Bewertung der Qualität eines Systems bzw. einerEinzelkomponente ist die Beurteilung der Qualität der Implementierung derSicherheitsfunktionen. Zur Beurteilung der Implementierungsqualität sindfolgende Einzelaspekte zu untersuchen:

- Die verwendete Implementierungssprache(hier insbesondere die Beschreibung der Sprache).

- Die Darstellung der Abbildung der Implementierung auf die Spezifikation.

- 52 - 1. Version 1989

- Die Korrektheit und Nachvollziehbarkeit dieser Abbildung.

- Die Nachvollziehbarkeit der Nebeneffektfreiheit bezüglich der Sicherheits-anforderungen.

- Die Art und Qualität der verwendeten Werkzeuge(z. B. Compiler, Linker, Testwerkzeuge, Konfigurationsverwaltung).

- Die Qualität der Implementierungsumgebung.Dies betrifft insbesondere die Art und Wirksamkeit der Sicherheitsvor-kehrungen, durch die ein Einbringen von "Trojanischen Pferden" in dieSoftware verhindert werden soll. Dazu gehören Aspekte wie:

- Versionskontrolle,

- Rollentrennung im Software-Entwicklungsprozeß,

- Zugriffskontrolle auf alle Programme und sonstigen Dokumente,

- Protokollierung der Zugriffe auf Programme und sonstige Dokumente,

- durchgeführte Tests und dabei eingesetzte Testmethoden und Werkzeuge,

- Vertrauenswürdigkeit des Entwicklungspersonals.

6.1.6 Betriebsqualität

Die Betriebsqualität ist ein Maß dafür, wie korrekt sich dieSicherheitsfunktionen unter normalen Betriebsbedingungen und unterAusnahmebedingungen verhalten, und wie die Einhaltung derSicherheitsanforderungen bei Konfigurierung, Wartung und Softwareänderungengarantiert wird. Dazu sind die folgenden Aspekte zu betrachten:

- Konfigurierbarkeit.Viele Systeme lassen sich entsprechend den Bedürfnissen eines Betreiberskonfigurieren. Die Auswirkungen der möglichen Konfigurationen auf dasVerhalten der Sicherheitsfunktionen sind darzulegen.

- Generierung des Systems.Die möglichen Einwirkungen bei der Generierung des Systems auf dieFunktionalität der Sicherheitsfunktionen sind darzulegen.

1. Version 1989 - 53 -

- Einspielung des Systems.Die Fehlermöglichkeiten, die beim Einspielen des Systems auftreten können,sowie die getroffenen Gegenmaßnahmen sind darzulegen.

- Selbsttesteinrichtungen.Vorhandene Selbsttesteinrichtungen für Hard- und Firmware sinddarzulegen.

- Auslieferung/Verteilung.Die Fehler- und Manipulationsmöglichkeiten auf dem Übertragungswegsowie die getroffenen Gegenmaßnahmen sind darzulegen.

- Wartung (Hardware und Software).Die Methoden und Mechanismen, die die korrekte Funktionalität derSicherheitsfunktionen im Falle einer Hardware- oder Softwarewartunggewährleisten sollen, sind darzulegen. Mögliche Schwachstellen sind zubeschreiben.

- Sicheres Starten, sicherer Wiederanlauf nach einem Fehler bzw.nach der Wartung.Die Methoden und Mechanismen, die ein sicheres Wiederanlaufen nacheinem Fehler bzw. nach einer Wartung oder Umstellung auf andereHardware- oder Softwarekomponenten gewährleisten sollen, sinddarzulegen.

Bei der Betrachtung der Betriebsqualität muß zuerst untersucht werden,inwieweit die einzelnen Punkte für das zu evaluierende System überhauptrelevant sind. Bietet ein System z. B. keine Konfigurierungsmöglichkeiten, sobrauchen in diesem Bereich natürlich auch keine Qualitätsuntersuchungenstattfinden. Das Fehlen einer solchen Konfigurierungsmöglichkeit hat keinennegativen Einfluß auf die erreichbare Qualitätsstufe.

6.1.7 Qualität der anwenderbezogenen Dokumentation

Die anwenderbezogene Dokumentation ist bezüglich der Aspekte

- Korrektheitd. h. Übereinstimmung mit den realen Gegebenheiten,

- Vollständigkeit,

- Verständlichkeit und

- Handhabbarkeit

- 54 - 1. Version 1989

zu bewerten.

6.2 Charakterisierung der Qualitätsstufen

Zur Bewertung der Qualität werden 8 Qualitätsstufen definiert. Dabeibezeichnet Q0 die niedrigste Stufe, Q7 die höchste hier definierteQualitätsstufe. Höhere Qualitätsstufen als Q7 sind zwar denkbar, jedoch mitheutigen technischen Mitteln nicht erreichbar. Falls der technische Fortschritteine bessere Qualität als die unter Q7 definierte ermöglicht, sollte eine weitereStufe Q8 definiert werden, die die Qualitätsanforderungen für eine solche Stufeunter Berücksichtigung der erweiterten technischen Möglichkeiten festlegt. Ineiner solchen Stufe könnte z. B. die Verwendung formal verifizierter Werkzeuge(Verifikationssysteme, Compiler, Linker etc.) und ein formal verifiziertesHardware- und Firmwaredesign verlangt werden.

Die 8 Qualitätsstufen lassen sich folgendermaßen charakterisieren:

Q0 : unzureichende QualitätDie Evaluation ergab keine für eine höhere Stufe ausreichendeQualität.

Q1 : getestetDie Sicherheitsanforderungen sind verbal formuliert. DieSpezifikation beschreibt relativ grob die Art der Implementierung.Das System wurde mit Hilfe einfacher Tests auf Erfüllung derSicherheitsanforderungen geprüft. Dabei wurden keine Fehlergefunden.

Q2 : methodisch getestetDie Sicherheitsanforderungen sind verbal formuliert. Das Systemwurde an Hand der Spezifikation methodisch getestet und aufErfüllung der Sicherheitsanforderungen geprüft. Dabei wurden keineFehler gefunden.

Q3 : methodisch getestet und teilanalysiertDie Sicherheitsanforderungen sind detailliert verbal beschrieben. DieSystemspezifikation wurde informell analysiert und auf Konsistenzmit den Sicherheitsanforderungen geprüft. Der Quellcode wurdestichprobenartig an Stellen, die als besonders kritisch angesehenwurden, analysiert. Das System wurde an Hand dieser Analysenmethodisch getestet und auf Erfüllung der Sicherheitsanforderungengeprüft. Dabei wurden keine Fehler gefunden.

1. Version 1989 - 55 -

Q4 : informell analysiertDie Sicherheitsanforderungen sind detailliert verbal beschrieben. Sy-stemspezifikation und Quellcode wurden informell analysiert und aufKonsistenz mit den Sicherheitsanforderungen geprüft. Das Systemwurde methodisch getestet und auf Erfüllung derSicherheitsanforderungen geprüft. Dabei wurden keine Fehlergefunden.

Q5 : semiformal analysiertDie Sicherheitsanforderungen sind detailliert verbal beschrieben. Diewichtigsten Sicherheitsanforderungen sind formal spezifiziert. DieSystemspezifikation liegt auch in semiformaler Notation vor.Systemspezifikation und Quellcode wurden mit semiformalenMethoden analysiert und auf Konsistenz mit denSicherheitsanforderungen geprüft. Das System wurde methodischgetestet und auf Erfüllung der Sicherheitsanforderungen geprüft.Dabei wurden keine Fehler gefunden.

Q6 : formal analysiertSicherheitsanforderungen und Systemspezifikation sind zusätzlich informaler Notation niedergelegt und auf Konsistenz verifiziert worden.Der Quellcode wurde sorgfältig auf Konsistenz mit der Spezifikationgeprüft. Das System wurde methodisch getestet und auf Erfüllung derSicherheitsanforderungen geprüft. Dabei wurden keine Fehlergefunden.

Q7 : formal verifiziertSicherheitsanforderungen und Systemspezifikation sind zusätzlich informaler Notation niedergelegt und auf Konsistenz verifiziert worden.Die Konsistenz zwischen Spezifikation und Quellcode wurde formalverifiziert. Das System wurde methodisch getestet und auf Erfüllungder Sicherheitsanforderungen geprüft. Dabei wurden keine Fehlergefunden.

- 56 - 1. Version 1989

6.3 Detaillierte Beschreibung der einzelnen Qualitätsstufen

VorbemerkungenIn einer höheren Qualitätsstufe sind sowohl die Summe der Anforderungen anden Auftraggeber als auch die Summe der Aufwände beim Prüfvorgang höherals in einer niedrigeren Qualitätsstufe.

Bei der Definition der einzelnen Qualitätsstufen wurde weitestgehend aufsubjektiv interpretierbare Formulierungen (wie z. B. sorgfältig, offensichtlich,klar usw.) verzichtet.

Bei der Beschreibung der einzelnen Qualitätsstufen sind neu hinzugekommeneoder geänderte Teile fett gedruckt.

1. Version 1989 - 57 - Q0

Qualitätsstufe Q0Die Qualitätsstufe Q0 ist für solche Systeme reserviert, die evaluiert wurden,deren meßbare Qualität jedoch nicht für eine der höheren Qualitätsstufenausreichend war. Daher werden in der Stufe Q0 keine Anforderungen in irgend-einem der Qualitätspunkte verlangt.

Q1 - 58 - 1. Version 1989

Qualitätsstufe Q1Für die Qualitätsstufe Q1 ist vom Auftraggeber folgende Dokumentationvorzulegen:

- Beschreibung der Sicherheitsanforderungen,

- verbale Spezifikation der zu evaluierenden Systemteile,

- Beschreibung der Abgrenzung zu nicht zu evaluierenden Systemteilen und derSchnittstellen zu diesen Teilen,

- Beschreibung der Anwendung der Sicherheitsfunktionen, aufgeteilt nach den in denSicherheitsanforderungen festgelegten Rollen,

- Beschreibung der sicherheitsrelevanten Aspekte bei Systemgenerierung, System-start, Systemverwaltung und Systemwartung,

- Beschreibung der verwendeten Hard- und Firmware mit Darlegung der Funk-tionalität der in Hardware bzw. Firmware realisierten Schutzmechanismen.

Qualität der Sicherheitsanforderungen

Anforderungen an den Auftraggeber

Es ist ein Dokument vorzulegen, in dem die Sicherheitsanforderungen an dasSystem bzw. die Einzelkomponente dargelegt werden.

Prüfvorgang

Dieses Dokument darf keine Unstimmigkeiten enthalten.

Qualität der Spezifikation


Für das zu evaluierende System bzw. die zu evaluierende Einzelkomponenteist eine Spezifikation vorzulegen, die in natürlicher Sprache formuliert seinkann. Diese Spezifikation muß die Art der Implementierung allerSicherheitsfunktionen beschreiben.Es muß dargelegt werden, durch welcheTeile der Spezifikation die einzelnen Sicherheitsanforderungen abgedecktwerden und welche Mechanismen dabei zum Einsatz kommen.

1. Version 1989 - 59 - Q1

Prüfvorgang

In der Spezifikation dürfen keine Nebeneffekte gefunden werden, durch dieSicherheitsfunktionen umgangen oder außer Kraft gesetzt werden können.

Qualität der verwendeten Mechanismen


Die zur Realisierung der Sicherheitsanforderungen verwendetenMechanismen und Algorithmen sind in der Spezifikation zu beschreiben.

Prüfvorgang

Die verwendeten Mechanismen müssen in ihrer Gesamtheit ausreichend sein,die Sicherheitsanforderungen zu erfüllen. Der zur Erfüllung einer bestimmtenSicherheitsanforderung verwendete Mechanismus bzw. die verwendeteKombination von Mechanismen darf nicht schlechter als mit "mittelstark"bewertet worden sein. In Ausnahmefällen kann auch ein als "schwach"bewerteter Mechanismus verwendet werden.

Qualität der Abgrenzung zu nicht zu evaluierenden Systemteilen


Die zu evaluierenden Systemteile müssen von den nicht zu evaluierendenTeilen des Systems getrennt sein. Es muß dargelegt werden, warum dieSicherheitsfunktionen von den nicht zu evaluierenden Teilen des Systemsnicht umgangen werden können. Alle Schnittstellen zu nicht zu evaluierendenSystemteilen müssen mit ihren Aufgaben, ihren Parametern und Effektendokumentiert sein.

Prüfvorgang

Die Mechanismen, die die zu evaluierenden Systemteile von den nicht zuevaluierenden Teilen des Systems separieren, müssen in ihrer Gesamtheitmindestens mit "stark" bewertet worden sein. Durch Tests wird überprüft,daß die Schnittstellen in der beschriebenen Form existieren. Dabei dürfenkeine Fehler gefunden werden, durch die Sicherheitsfunktionen umgangenoder außer Kraft gesetzt werden können.

Q1 - 60 - 1. Version 1989

Qualität des Herstellungsvorganges


Es werden keine Anforderungen hinsichtlich der Implementierungssprachesowie der verwendeten Werkzeuge gestellt.

Es werden keine Voraussetzungen an die Implementierungsumgebunggemacht.

Prüfvorgang

Es werden Tests durchgeführt, durch die Unklarheiten oder vermuteteSchwachstellen, die sich bei der Prüfung der Spezifikation ergaben,aufgeklärt werden sollen. Dabei dürfen keine Wege gefunden werden, durchdie Sicherheitsfunktionen umgangen oder außer Kraft gesetzt werden können.

Betriebsqualität


Falls es unterschiedliche Konfigurationsmöglichkeiten gibt, müssen derenAuswirkungen auf die Sicherheitsanforderungen beschrieben sein. Soferndurch unterschiedliche Konfigurationen auch unterschiedliche Sicherheits-anforderungen realisiert werden, muß dies in der Dokumentation erläutertwerden.

Prüfvorgang

Die Auswirkungen unterschiedlicher Konfigurationen werden an Hand derDokumentation auf Konsistenz mit den Sicherheitsanforderungen geprüft. BeiUnklarheiten oder vermuteten Fehlern werden Tests durchgeführt, durch diediese Unklarheiten aufgeklärt werden sollen.

1. Version 1989 - 61 - Q1

Qualität der anwenderbezogenen Dokumentation


Die Anwenderdokumentation muß für alle durch dieSicherheitsanforderungen definierten Rollen deren relevanteSicherheitsfunktionen, ihre Aufgabe sowie ihre Benutzung beschreiben.

Prüfvorgang

Die Dokumentation wird auf Vollständigkeit, Verständlichkeit und Handhab-barkeit geprüft. Es dürfen keine Abweichungen zwischen realemSystemverhalten und der Dokumentation gefunden werden.

Q2 - 62 - 1. Version 1989






- Beschreibung der sicherheitsrelevanten Aspekte bei Systemgenerierung,Systemstart, Systemverwaltung und Systemwartung,

- Beschreibung der verwendeten Hard- und Firmware mit Darlegung der Funk-tionalität der in Hardware bzw. Firmware realisierten Schutzmechanismen,

- Bibliothek von Testprogrammen mit zugehöriger Testdokumentation.



Es ist ein Dokument vorzulegen, in dem die Sicherheitsanforderungen an dasSystem bzw. die Einzelkomponente mit Bezug zu den Bedrohungen undden Grundfunktionen dargelegt werden.

Prüfvorgang




Für das zu evaluierende System bzw. die zu evaluierende Einzelkomponenteist eine Spezifikation vorzulegen, die in natürlicher Sprache formuliert seinkann. Diese Spezifikation muß die Art der Implementierung allerSicherheitsfunktionen beschreiben.

1. Version 1989 - 63 - Q2

Es muß dargelegt werden, durch welche Teile der Spezifikation dieeinzelnen Sicherheitsanforderungen abgedeckt werden und welcheMechanismen dabei zum Einsatz kommen.Falls die Spezifikation hierarchisch aufgebaut ist, muß verbalbeschrieben und nachvollziehbar sein, wie die einzelnen Hierarchie-stufen aufeinander abzubilden sind. Die Abbildung derSicherheitsanforderungen muß bis auf die niedrigste Hierarchiestufe derSpezifikation nachvollziehbar sein.

Prüfvorgang

In der Spezifikation dürfen keine Nebeneffekte gefunden werden, durch dieSicherheitsfunktionen umgangen oder außer Kraft gesetzt werden können. Bisauf die niedrigste Hierarchiestufe der Spezifikation wird überprüft, daßdie Sicherheitsanforderungen erfüllt sind.




Prüfvorgang

Die verwendeten Mechanismen müssen in ihrer Gesamtheit ausreichend sein,die Sicherheitsanforderungen zu erfüllen. Der zur Erfüllung einer bestimmtenSicherheitsanforderung verwendete Mechanismus bzw. die verwendeteKombination von Mechanismen darf nicht schlechter als mit "mittelstark"bewertet worden sein.Es werden keine Ausnahmefälle zugelassen.



Die zu evaluierenden Systemteile müssen von nicht zu evaluierenden Teilendes Systems getrennt sein. Es muß dargelegt werden, warum dieSicherheitsfunktionen von den nicht zu evaluierenden Teilen des Systemsnicht umgangen werden können.Alle Schnittstellen zu nicht zu evaluierendenSystemteilen müssen mit ihren Aufgaben, ihren Parametern und Effektendokumentiert sein.

Q2 - 64 - 1. Version 1989

Prüfvorgang

Die Mechanismen, die die zu evaluierenden Systemteile von den nicht zuevaluierenden Teilen des Systems separieren, müssen in ihrer Gesamtheitmindestens mit "stark" bewertet worden sein. Durch Tests wird überprüft,daß die Schnittstellen in der beschriebenen Form existieren. Dabei dürfenkeine Fehler gefunden werden, durch die Sicherheitsfunktionen umgangenoder außer Kraft gesetzt werden können.



Es werden keine Anforderungen hinsichtlich der Implementierungssprachesowie der verwendeten Werkzeuge gestellt.

Es werden keine Voraussetzungen an die Implementierungsumgebunggemacht.

Die auf der niedrigsten Hierarchiestufe der Spezifikation definiertenFunktionseinheiten müssen identifizierbar sein. Ihre Schnittstellenuntereinander müssen dokumentiert sein.

Zusätzlich muß eine Bibliothek mit Testprogrammen sowie derzugehörigen Testdokumentation zur Verfügung stehen. DieTestdokumentation muß enthalten: Testplan, Zweck, Vorgehensweiseund Ergebnisse der Tests.

Prüfvorgang

Es werden Tests durchgeführt, durch die Unklarheiten oder vermuteteSchwachstellen, die sich bei der Prüfung der Spezifikation ergaben,aufgeklärt werden sollen. Dabei dürfen keine Wege gefunden werden, durchdie Sicherheitsfunktionen umgangen oder außer Kraft gesetzt werden können.

Ausgewählte Testbeispiele aus der Testbibliothek werden nachvollzogenund müssen die in der Dokumentation beschriebenen Ergebnisse liefern.

1. Version 1989 - 65 - Q2

Betriebsqualität


Falls es unterschiedliche Konfigurationsmöglichkeiten gibt, müssen derenAuswirkungen auf die Sicherheitsanforderungen beschrieben sein. DieseAuswirkungen müssen auch in der Spezifikation erkennbar sein. Soferndurch unterschiedliche Konfigurationen auch unterschiedlicheSicherheitsanforderungen realisiert werden, muß dies in der Dokumentationerläutert werden.

Alle Konfigurationsmöglichkeiten müssen dokumentiert sein.Bei der Generierung des Systems dürfen keine nicht protokolliertenEingriffe möglich sein, durch die Sicherheitsfunktionen auch nurteilweise außer Kraft gesetzt werden können.Es muß ein von der Prüfbehörde für diese Qualitätsstufe zugelassenesVerfahren eingesetzt werden, das sicherstellt, daß Übertragungsfehlerbei der eingespielten Software erkannt werden.Falls Sicherheitsfunktionen im Falle einer Hardware- oderSoftwarewartung außer Kraft gesetzt sind, muß dies im Handbuch fürden Systemverwalter dokumentiert sein.Das System muß Selbsttesteinrichtungen für einige derHardwarekomponenten besitzen, deren korrekte FunktionalitätVoraussetzung für das korrekte Ablaufen der zu evaluierendenSoftware ist.

Prüfvorgang

Die Auswirkungen unterschiedlicher Konfigurationen werden an Hand derSpezifikation sowie der Dokumentation auf Konsistenz mit denSicherheitsanforderungen geprüft. Bei Unklarheiten oder vermuteten Fehlernwerden Tests durchgeführt, durch die diese Unklarheiten aufgeklärt werdensollen.

Es wird geprüft, welche Eingriffe bei der Generierung des Systemsmöglich sind, welche Auswirkungen sie haben und wie sie protokolliertwerden. Die Wirksamkeit der Sicherheitsfunktionen im Wartungsfallwird auf Konsistenz mit der Dokumentation geprüft.Die Selbsttesteinrichtungen des Systems werden, soweit möglich,stichprobenhaft untersucht.

Q2 - 66 - 1. Version 1989



Die Anwenderdokumentation muß für alle durch die Sicherheitsanfor-derungen definierten Rollen deren relevante Sicherheitsfunktionen, ihreAufgabe sowie ihre Benutzung beschreiben.

Prüfvorgang

Die Dokumentation wird auf Vollständigkeit, Verständlichkeit und Hand-habbarkeit geprüft. Es dürfen keine Abweichungen zwischen realemSystemverhalten und der Dokumentation gefunden werden.

1. Version 1989 - 67 - Q3








- Bibliothek von Testprogrammen mit zugehöriger Testdokumentation,

- Quellcode der Implementierung der zu evaluierenden Systemteile.



Es ist ein Dokument vorzulegen, in dem die Sicherheitsanforderungen an dasSystem bzw. die Einzelkomponente mit Bezug zu den Bedrohungen und denGrundfunktionen dargelegt werden.

Prüfvorgang




Für das zu evaluierende System bzw. die zu evaluierende Einzelkomponenteist eine Spezifikation vorzulegen, die in natürlicher Sprache formuliert seinkann. Diese Spezifikation muß die Art der Implementierung allerSicherheitsfunktionen detailliert beschreiben. Es muß dargelegt werden,

Q3 - 68 - 1. Version 1989

durch welche Teile der Spezifikation die einzelnen Sicherheitsanforderungenabgedeckt werden und welche Mechanismen dabei zum Einsatz kommen.Falls die Spezifikation hierarchisch aufgebaut ist, muß verbal beschriebenund nachvollziehbar sein, wie die einzelnen Hierarchiestufen aufeinanderabzubilden sind. Die Abbildung der Sicherheitsanforderungen muß bis aufden Quellcode nachvollziehbar sein.

Prüfvorgang

In der Spezifikation dürfen keine Nebeneffekte gefunden werden, durch dieSicherheitsfunktionen umgangen oder außer Kraft gesetzt werden können. Bishinunter zum Quellcode wird überprüft, daß die Sicherheitsanforderungenerfüllt sind.



Die zur Realisierung der Sicherheitsanforderungen verwendeten Mechanis-men und Algorithmen sind in der Spezifikation zu beschreiben.

Prüfvorgang

Die verwendeten Mechanismen müssen in ihrer Gesamtheit ausreichend sein,die Sicherheitsanforderungen zu erfüllen. Der zur Erfüllung einer bestimmtenSicherheitsanforderung verwendete Mechanismus bzw. die verwendeteKombination von Mechanismen darf nicht schlechter als mit "stark"bewertet worden sein.In Ausnahmefällen kann auch ein als "mittelstark" bewerteterMechanismusbzw. Kombination von Mechanismen verwendet werden.



Die zu evaluierenden Systemteile müssen von nicht zu evaluierenden Teilendes Systems getrennt sein. Es muß dargelegt werden, warum dieSicherheitsfunktionen von den nicht zu evaluierenden Teilen des Systemsnicht umgangen werden können. Alle Schnittstellen zu nicht zu evaluierendenSystemteilen müssen mit ihren Aufgaben, ihren Parametern und Effektendokumentiert sein.

1. Version 1989 - 69 - Q3

Prüfvorgang

Die Mechanismen, die die zu evaluierenden Systemteile von den nicht zuevaluierenden Teilen des Systems separieren, müssen in ihrer Gesamtheitmindestens mit "stark" bewertet worden sein. Durch Tests undstichprobenartige Quellcodeuntersuchung wird geprüft, daß dieSchnittstellen in der beschriebenen Form existieren. Dabei dürfen keineFehler gefunden werden, durch die Sicherheitsfunktionen umgangen oderaußer Kraft gesetzt werden können.



Zur Implementierung müssen Sprachen verwendet werden, die eineeindeutigdefinierte Syntax und gut dokumentierte Semantik besitzen.Es müssen Verfahren oder Prozeduren existieren, die eine Generierungder zu evaluierenden Software aus den Quellprogrammen sowie eineVersions- und Änderungskontrolle ermöglichen.Die auf der niedrigsten Hierarchiestufe der Spezifikation definierten Funk-tionseinheiten müssen im Quellcode identifizierbar sein. Ihre Schnittstellenuntereinander müssen dokumentiert sein.

Zusätzlich muß eine Bibliothek mit Testprogrammen sowie der zugehörigenTestdokumentation zur Verfügung stehen. Die Testdokumentation mußenthalten: Testplan, Zweck, Vorgehensweise und Ergebnisse der Tests.

Für große Systeme muß vom Hersteller ein Softwareintegrations- undAbnahmeverfahren vorgelegt werden. In diesem Verfahren müssenzumindest die Rollen von Entwickler und Tester bzw.Abnahmeverantwortlichem getrennt sein. Der Prüfbehörde sindUnterlagen zur Verfügung zu stellen, aus denen sich die Einhaltung desIntegrations- und Abnahmeverfahren ersehen läßt.

Prüfvorgang

Es werden Penetrationstests durchgeführt, durch die Unklarheiten odervermutete Schwachstellen, die sich bei der Prüfung der Spezifikationergaben, aufgeklärt werden sollen. Dabei dürfen keine Wege gefundenwerden, durch die Sicherheitsfunktionen umgangen oder außer Kraft gesetztwerden können.

Q3 - 70 - 1. Version 1989


Die Auswirkungen einer Neugenerierung von Softwarekomponentenmüssen sich in der Konfigurations- und Änderungskontrollewiderspiegeln. Das vom Hersteller verwendete Verfahren wird von derPrüfbehörde stichprobenhaft an ausgewählten Teilen des Quellcodesnachvollzogen. Es dürfen keine Unstimmigkeiten zwischen geliefertemund generiertem Prüfobjekt existieren.Bei großen Systemen werden die Unterlagen über Softwareintegrationund Abnahme stichprobenartig auf Vollständigkeit und Konsistenzgeprüft.

Betriebsqualität


Falls es unterschiedliche Konfigurationsmöglichkeiten gibt, müssen derenAuswirkungen auf die Sicherheitsanforderungen beschrieben sein. DieseAuswirkungen müssen auch in der Spezifikation erkennbar sein. Sofern durchunterschiedliche Konfigurationen auch unterschiedlicheSicherheitsanforderungen realisiert werden, muß dies in der Dokumentationerläutert werden.

Alle Konfigurationsmöglichkeiten müssen dokumentiert sein.

Bei der Generierung des Systems dürfen keine nicht protokollierten Eingriffemöglich sein, durch die Sicherheitsfunktionen auch nur teilweise außer Kraftgesetzt werden können.

Bei der Generierung des Systems müssen alle Generierungsparameterso protokolliert werden, daß später nachvollziehbar ist, wie und wanndas System generiert wurde.

Es muß ein von der Prüfbehörde für diese Qualitätsstufe zugelassenesVerfahren eingesetzt werden, das sicherstellt, daß Übertragungsfehler beider eingespielten Software erkannt werden.

Falls Sicherheitsfunktionen im Falle einer Hardware- oder Softwarewartungaußer Kraft gesetzt sind, muß dies im Handbuch für den Systemverwalterdokumentiert sein.

1. Version 1989 - 71 - Q3

Beim Starten des Systems dürfen keine nicht protokollierten Eingriffemöglich sein, durch die das System in einen Zustand versetzt wird, indem die Sicherheitsanforderungen nicht erfüllt werden.

Das System muß Selbsttesteinrichtungen für einige der Hardwarekom-ponenten besitzen, deren korrekte Funktionalität Voraussetzung für daskorrekte Ablaufen der zu evaluierenden Software ist.

Prüfvorgang

Die Auswirkungen unterschiedlicher Konfigurationen werden an Hand derSpezifikation sowie der Dokumentation auf Konsistenz mit denSicherheitsanforderungen geprüft. Bei Unklarheiten oder vermuteten Fehlernwerden Tests durchgeführt, durch die diese Unklarheiten aufgeklärt werdensollen.

Es wird geprüft, welche Eingriffe bei der Generierung des Systems möglichsind, welche Auswirkungen sie haben, und wie sie protokolliert werden. DieWirksamkeit der Sicherheitsfunktionen im Wartungsfall wird auf Konsistenzmit der Dokumentation geprüft.Es wird geprüft, ob Eingriffe während desStartens des Systems dieses in einen Zustand versetzen können, in demSicherheitsanforderungen nicht mehr erfüllt sind, ohne daß diesprotokolliert wird.Die Selbsttesteinrichtungen des Systems werden, soweit möglich,stichprobenhaft untersucht.




Prüfvorgang

Die Dokumentation wird auf Vollständigkeit, Verständlichkeit und Hand-habbarkeit geprüft. Es dürfen keine Abweichungen zwischen realemSystemverhalten und der Dokumentation gefunden werden.

Q4 - 72 - 1. Version 1989



- verbale hierarchisch strukturierte Spezifikation der zu evaluierendenSystemteile,









Es ist ein Dokument vorzulegen, in dem die Sicherheitsanforderungen an dasSystem bzw. die Einzelkomponente detailliert mit Bezug zu denBedrohungen und den Grundfunktionen dargelegt werden.

Prüfvorgang


1. Version 1989 - 73 - Q4



Für das zu evaluierende System bzw. die zu evaluierende Einzelkomponenteist eine Spezifikation vorzulegen, die in natürlicher Sprache formuliert seinkann, jedoch müssen semiformale Hilfsmittel wie z. B. Nassi-Shneiderman-Diagramme, Datenflußdiagramme oder ähnlichesverwendet werden. Diese Spezifikation muß die Art der Implementierungaller Sicherheitsfunktionen detailliert beschreiben, wobei dieseBeschreibung mehrere Hierarchiestufen besitzen muß. Die Zahl derHierachiestufen wird von der Komplexität des Systems bestimmt. Esmuß dargelegt werden, durch welche Teile der Spezifikation die einzelnenSicherheitsanforderungen abgedeckt werden und welche Mechanismen dabeizum Einsatz kommen.Es muß verbal beschrieben undnachvollziehbar sein, wie die einzelnen Hierarchiestufen aufeinanderabzubilden sind. Die Abbildung der Sicherheitsanforderungen muß bis aufden Quellcode nachvollziehbar sein.

Prüfvorgang

In der Spezifikation dürfen keine Nebeneffekte gefunden werden, durch dieSicherheitsfunktionen umgangen oder außer Kraft gesetzt werden können.Die Realisierung der Sicherheitsanforderungen wird bis auf denQuellcode nachvollzogen.




Prüfvorgang

Die verwendeten Mechanismen müssen in ihrer Gesamtheit ausreichend sein,die Sicherheitsanforderungen zu erfüllen. Der zur Erfüllung einer bestimmtenSicherheitsanforderung verwendete Mechanismus bzw. die verwendeteKombination von Mechanismen darf nicht schlechter als mit "stark" bewertetworden sein. Es werden keine Ausnahmefälle zugelassen.

Q4 - 74 - 1. Version 1989



Die zu evaluierenden Systemteile müssen von nicht zu evaluierenden Teilendes Systems getrennt sein. Es muß dargelegt werden, warum dieSicherheitsfunktionen von den nicht zu evaluierenden Teilen des Systemsnicht umgangen werden können.Alle Schnittstellen zu nicht zu evaluierendenSystemteilen müssen mit ihren Aufgaben, ihren Parametern und Effektendokumentiert sein.

Prüfvorgang

Die Mechanismen, die die zu evaluierenden Systemteile von den nicht zuevaluierenden Teilen des Systems separieren, müssen in ihrer Gesamtheitmindestens mit "sehr stark" bewertet worden sein. Durch Tests undQuellcodeuntersuchung wird geprüft, daß die Schnittstellen in derbeschriebenen Form existieren und keine weiteren vorhanden sind. Dabeidürfen keine Fehler gefunden werden, durch die Sicherheitsfunktionenumgangen oder außer Kraft gesetzt werden können.



Zur Implementierung müssen Sprachen verwendet werden, die eine eindeutigdefinierte Syntax und gut dokumentierte Semantik besitzen. Dieverwendeten Compiler müssen entweder von einer unabhängigenInstanz geprüft sein, oder es müssen Testprogramme nebst zugehörigerTestdokumentation existieren, mit denen die FunktionalitätundEinhaltung der Sprachdefinition des jeweiligen Compilers und derzugehörigen Umgebung (z. B. Bibliotheken) von der Prüfbehördeüberprüft werden kann.Es müssen Verfahren oder Prozeduren existieren, die eine Generierung derzu evaluierenden Software aus den Quellprogrammen sowie eine Versions-und Änderungskontrolle ermöglichen.

Die Abbildung der niedrigsten Hierarchiestufe der Spezifikation mit dendort definierten Funktionseinheiten auf den Quellcode mußnachvollziehbar sein. Deren Schnittstellen untereinander müssendokumentiert sein.


1. Version 1989 - 75 - Q4

Für große Systeme muß vom Hersteller ein Softwareintegrations- undAbnahmeverfahren vorgelegt werden. In diesem Verfahren müssen zumindestdie Rollen von Entwickler und Tester bzw. Abnahmeverantwortlichemgetrennt sein. Der Prüfbehörde sind Unterlagen zur Verfügung zu stellen, ausdenen sich die Einhaltung des Integrations- und Abnahmeverfahrens ersehenläßt.

Prüfvorgang

Es werden Penetrationstests und Quellcodeinspektionen durchgeführt,durch die Unklarheiten oder vermutete Schwachstellen, die sich bei derPrüfung der Spezifikation bzw. des Quellcodes ergaben, aufgeklärt werdensollen. Dabei dürfen keine Wege gefunden werden, durch dieSicherheitsfunktionen umgangen oder außer Kraft gesetzt werden können.

Falls die verwendeten Compiler nicht von einer unabhängigen Instanzgeprüft worden sind, werden ausgewählte Testprogramme ausgeführt.Die Ergebnisse müssen mit der Testdokumentation übereinstimmen.Zusätzlich werden eigene Testprogramme entworfen. Dabei dürfenkeine Fehler in den Compilern gefunden werden, bei denen dergenerierte Maschinencode eine fehlerhafte Abbildung derSprachkonstrukte der Implementierungssprache ist.Ausgewählte Testbeispiele aus der Testbibliothek werden nachvollzogenund müssen die in der Dokumentation beschriebenen Ergebnisse liefern.

Die Auswirkungen einer Neugenerierung von Softwarekomponenten müssensich in der Konfigurations- und Änderungskontrolle widerspiegeln. Das vomHersteller verwendete Verfahren wird von der Prüfbehörde stichprobenhaftan ausgewählten Teilen des Quellcodes nachvollzogen. Es dürfen keineUnstimmigkeiten zwischen geliefertem und generiertem Prüfobjektexistieren.

Bei großen Systemen werden die Unterlagen über Softwareintegration undAbnahme stichprobenartig auf Vollständigkeit und Konsistenz geprüft.

Q4 - 76 - 1. Version 1989

Betriebsqualität


Falls es unterschiedliche Konfigurationsmöglichkeiten gibt, müssen derenAuswirkungen auf die Sicherheitsanforderungen beschrieben sein. DieseAuswirkungen müssen auch in der Spezifikation erkennbar sein. Sofern durchunterschiedliche Konfigurationen auch unterschiedliche Sicherheits-anforderungen realisiert werden, muß dies in der Dokumentation erläutertwerden.



Bei der Generierung des Systems müssen alle Generierungsparameter soprotokolliert werden, daß später nachvollziehbar ist, wie und wann dasSystem generiert wurde.

Es muß ein von der Prüfbehörde für diese Qualitätsstufe zugelassenesVerfahren eingesetzt werden, das sicherstellt, daß Übertragungsfehler beider eingespielten Software erkannt werden.

Falls Sicherheitsfunktionen im Falle einer Hardware- oder Softwarewartungaußer Kraft gesetzt sind, muß dies im Handbuch für den Systemverwalterdokumentiert sein.

Beim Starten des Systems dürfen keine nicht protokollierten Eingriffemöglich sein, durch die das System in einen Zustand versetzt wird, in demdie Sicherheitsanforderungen nicht erfüllt werden.

Das System muß Selbsttesteinrichtungen für einige der Hardware-komponenten besitzen, deren korrekte Funktionalität Voraussetzung für daskorrekte Ablaufen der zu evaluierenden Software ist.

Prüfvorgang

Die Auswirkungen unterschiedlicher Konfigurationen werden an Hand derSpezifikation, des Quellcodes sowie der Dokumentation auf Konsistenz mitden Sicherheitsanforderungen geprüft. Bei Unklarheiten oder vermutetenFehlern werden Tests durchgeführt, durch die diese Unklarheiten aufgeklärtwerden sollen.

1. Version 1989 - 77 - Q4

Es wird geprüft, welche Eingriffe bei der Generierung des Systems möglichsind, welche Auswirkungen sie haben und wie sie protokolliert werden. DieWirksamkeit der Sicherheitsfunktionen im Wartungsfall wird auf Konsistenzmit der Dokumentation geprüft.Es wird geprüft, ob Eingriffe während desStartens des Systems dieses in einen Zustand versetzen können, in demSicherheitsanforderungen nicht mehr erfüllt sind, ohne daß dies protokolliertwird.

Die Selbsttesteinrichtungen des Systems werden, soweit möglich,stichprobenhaft untersucht.



Die Anwenderdokumentation muß für alle durch die Sicherheits-anforderungen definierten Rollen deren relevante Sicherheitsfunktionen, ihreAufgabe sowie ihre Benutzung beschreiben.

Prüfvorgang

Die Dokumentation wird auf Vollständigkeit, Verständlichkeit und Hand-habbarkeit geprüft. Es dürfen keine Abweichungen zwischen realemSystemverhalten und der Dokumentation gefunden werden.Der Nachweis dafür wird durch Prüfung der relevanten Teile derSpezifikation und des Quellcodes (inklusive Penetrationstests) erbracht.

Q5 - 78 - 1. Version 1989



- formales Sicherheitsmodell mit den zugehörigen Konsistenzbeweisen,

- verbale und semiformale hierarchisch strukturierte Spezifikation der zuevaluierenden Systemteile,









Es ist ein Dokument vorzulegen, in dem die Sicherheitsanforderungen an dasSystem bzw. die Einzelkomponente detailliert mit Bezug zu den Bedrohungenund den Grundfunktionen dargelegt werden.

Zusätzlich muß ein formales Sicherheitsmodell vorgelegt werden,welches die vom Auftraggeber als wichtig erachtetenSicherheitsanforderungen in der Bereichen Vertraulichkeit undIntegrität abdeckt. Das Modell muß als konsistent mit seinen Axiomenbewiesen sein.

1. Version 1989 - 79 - Q5

Prüfvorgang


Die Konsistenzbeweise für das formale Modell werden nachvollzogen.Dieses darf keine Widersprüche zu den verbal formuliertenSicherheitsanforderungen enthalten.



Für das zu evaluierende System bzw. die zu evaluierende Einzelkomponenteist neben der verbalen Spezifikation auch eine Spezifikation vorzulegen,die zumindest in semiformaler Notation formuliert sein muß. DieseSpezifikation muß die Art der Implementierung aller Sicherheitsfunktionendetailliert beschreiben, wobei diese Beschreibung mehrere Hierarchiestufenbesitzen muß. Die Zahl der Hierarchiestufen wird durch die Komplexität desSystems bestimmt. Es muß dargelegt werden, durch welche Teile derSpezifikation die einzelnen Sicherheitsanforderungen abgedeckt werden undwelche Mechanismen dabei zum Einsatz kommen. Es muß durch eindeutigeRegeln beschrieben und nachvollziehbar sein, wie die einzelnenHierarchiestufen aufeinander abzubilden sind. Die Abbildung derSicherheitsanforderungen muß bis auf den Quellcode nachvollziehbar sein.

Für die Spezifikation ist eine Sprache mit eindeutig definierter Syntaxund semiformal definierter Semantik zu verwenden. Zur Prüfung derSyntax muß ein Werkzeug verwendet werden. Es dürfen keineSyntaxfehler vorhanden sein. Die Spezifikationsmethodik muß diehierarchische Spezifikation unterstützen und die Art der Abbildungunterschiedlicher Hierarchiestufen aufeinander festlegen.

Prüfvorgang

In der Spezifikation dürfen keine Nebeneffekte gefunden werden, durch dieSicherheitsfunktionen umgangen oder außer Kraft gesetzt werden können. DieRealisierung der Sicherheitsanforderungen wird bis auf den Quellcodenachvollzogen.Die Spezifikationssprache wird auf eindeutige Definition vonSyntax und semiformale Definition der Semantik ihrer Sprachkonstrukteuntersucht. Die Spezifikation wird werkzeugunterstützt aufSyntaxfehler geprüft.

Q5 - 80 - 1. Version 1989




Prüfvorgang

Die verwendeten Mechanismen müssen in ihrer Gesamtheit ausreichend sein,die Sicherheitsanforderungen zu erfüllen. Der zur Erfüllung einer bestimmtenSicherheitsanforderung verwendete Mechanismus bzw. die verwendeteKombination von Mechanismen darf nicht schlechter als mit "sehr stark"bewertet worden sein. In Ausnahmefällen kann auch ein als "stark"bewerteter Mechanismus bzw. Kombination von Mechanismeneingesetzt werden.



Die zu evaluierenden Systemteile müssen von nicht zu evaluierenden Teilendes Systems getrennt sein. Es muß dargelegt werden, warum dieSicherheitsfunktionen von den nicht zu evaluierenden Teilen des Systemsnicht umgangen werden können. Alle Schnittstellen zu nicht zu evaluierendenSystemteilen müssen mit ihren Aufgaben, ihren Parametern und Effektendokumentiert sein.Die Benutzung von verdeckten Kanälen muß protokollierbar sein.

Prüfvorgang

Die Mechanismen, die die zu evaluierenden Systemteile von den nicht zuevaluierenden Teilen des Systems separieren, müssen in ihrer Gesamtheitmindestens mit "sehr stark" bewertet worden sein. Durch Tests undQuellcodeuntersuchung wird geprüft, daß die Schnittstellen in derbeschriebenen Form existieren und keine weiteren vorhanden sind. Dabeidürfen keine Fehler gefunden werden, durch die Sicherheitsfunktionenumgangen oder außer Kraft gesetzt werden können.Zusätzlich werdenPrüfungen auf die Existenz von verdeckten Kanälen bei Benutzung derSchnittstellen durchgeführt. Alle so gefundenen Kanäle müssendokumentiert sein. Kanäle, die zu einem unerlaubten Informationsflußmißbraucht werden können, werden bezüglich ihrer Bandbreite sowieihrer Ausnutzbarkeit durch "Trojanische Pferde" analysiert.DieProtokollierbarkeit von verdeckten Kanälen wird geprüft.

1. Version 1989 - 81 - Q5



Zur Implementierung müssen Sprachen verwendet werden, die einegenormte oder formale definierte Syntax und eine sehr gut dokumentierteSemantik besitzen. Alle in der Beschreibung der Semantik der Spracheoffengelassenen Punkte müssen in der Dokumentation des verwendetenCompilers eindeutig geklärt sein. Die verwendeten Compiler müssenentweder offiziell geprüft ("validiert") sein, oder es müssenTestprogramme nebst zugehöriger Testdokumentation existieren, mit denendie Funktionalität und Einhaltung der Sprachdefinition des jeweiligenCompilers und der zugehörigen Umgebung (z. B. Bibliotheken) von derPrüfbehörde in allen Einzelheiten überprüft werden kann.

Es müssen Verfahren oder Prozeduren existieren, die eine Generierung derzu evaluierenden Software aus den Quellprogrammen sowie eine Versions-und Änderungskontrolle ermöglichen.

Die Abbildung der niedrigsten Hierarchiestufe der Spezifikation auf denQuellcode muß nachvollziehbar sein. Diese muß die Unterteilung desQuellcodes in Funktionseinheiten widerspiegeln. Es müssen alleVariablen, die von mehr als einer Funktionseinheit benutzt werden, inder niedrigsten Hierarchiestufe der Spezifikation definiert und mitihrem Zweck beschrieben sein. Der Quellcode muß durchgehend inkleine, überschaubare, abgegrenzte Funktionseinheiten gegliedert sein.Deren Aufgaben und Schnittstellen müssen vollständig beschrieben sein.


Für Systeme, an deren Entwicklung mehr als 5 Personen beteiligt sindoder waren, muß ein Konfigurationsverwaltungs- undVersionskontrollsystem eingesetzt werden. Dieses System muß alleÄnderungen an Spezifikation, Quellcode sowie anderen abhängigenDaten mit Verursacher, Datum und Uhrzeit protokollieren. Außerdemmuß dieses System die Rollen von Spezifizierer, Implementierer undTester kennen und voneinander separieren. Für diese Systeme muß vomHersteller ein Softwareintegrations- und Abnahmeverfahrens vorgelegtwerden. In diesem Verfahren müssen zumindest die Rollen von Entwicklerund Tester bzw. Abnahmeverantwortlichem getrennt sein. Der Prüfbehördesind Unterlagen zur Verfügung zu stellen, aus denen sich die Einhaltung desIntegrations- und Abnahmeverfahren ersehen läßt. Zu diesen Unterlagengehören auch die Protokolldaten des Konfigurationsverwaltungs- undVersionskontrollsystems.

Q5 - 82 - 1. Version 1989

Prüfvorgang

Es werden Penetrationstests und Quellcodeinspektionen durchgeführt, durchdie Unklarheiten oder vermutete Schwachstellen, die sich bei der Prüfungder Spezifikation bzw. des Quellcodes ergaben, aufgeklärt werden sollen.Dabei dürfen keine Wege gefunden werden, durch die Sicherheitsfunktionenumgangen oder außer Kraft gesetzt werden können.Zusätzlich werden Tests auf Ebene der Funktionseinheitendurchgeführt, mit denen Unklarheiten oder vermutete Fehler überprüftwerden sollen. Dabei dürfen keine Fehler festgestellt werden.

Die Abbildung der niedrigsten Hierarchiestufe der Spezifikation auf denQuellcode wird geprüft.

Falls die verwendeten Compiler nicht von einer unabhängigen Instanzgeprüft worden sind, werden ausgewählte Testprogramme ausgeführt. DieErgebnisse müssen mit der Testdokumentation übereinstimmen. Zusätzlichwerden eigene Testprogramme entworfen. Dabei dürfen keine Fehler in denCompilern gefunden werden, bei denen der generierte Maschinencode einefehlerhafte Abbildung der Sprachkonstrukte der Implementierungssprache ist.



Die Protokolldaten des Konfigurationsverwaltungs- undVersionskontrollsystems werden an einzelnen Stichproben untersucht.

Die Unterlagen über Softwareintegration und Abnahme werdenstichprobenartig auf Vollständigkeit und Konsistenz geprüft.

1. Version 1989 - 83 - Q5

Betriebsqualität


Falls es unterschiedliche Konfigurationsmöglichkeiten gibt, müssen derenAuswirkungen auf die Sicherheitsanforderungen beschrieben sein. DieseAuswirkungen müssen auch in der Spezifikation erkennbar sein. DieseAuswirkungen auf die Sicherheitsanforderungen dürfen nur gering seinund müssen in der Dokumentation erläutert werden.




Es muß ein von der Prüfbehörde für diese Qualitätsstufe zugelassenesVerfahren eingesetzt werden, das sicherstellt, daß Übertragungsfehler beider eingespielten Software erkannt werden. Zusätzlich muß ein von derPrüfbehörde für diese Qualitätsstufe zugelassener Weg zurSoftwareverteilung eingehalten werden.

Im laufenden Betrieb darf keine Softwarewartung durchgeführt werden,durch die Sicherheitsfunktionen außer Kraft gesetzt werden. FallsSicherheitsfunktionen im Falle einer Hardwarewartung außer Kraftgesetzt sind, muß dies im Handbuch für den Systemverwalter dokumentiertsein.

Beim Starten des Systems dürfen keine nicht protokollierten Eingriffemöglich sein, durch die das System in einen Zustand versetzt wird, in demdie Sicherheitsanforderungen nicht erfüllt werden. Es muß ein Verfahrenexistieren, das Modifikationen an evaluierten Teilen der Software beimStarten des Systems erkennen kann.

Es müssen Prozeduren existieren, die das System auch nach einem Sy-stemabsturz sowie nach einem Hard- oder Softwarefehler wieder ineinen sicheren Zustand bringen. Diese Prozeduren müssen so gestaltetsein, daß eine Fehlbedienung nicht zu einem unerkannten Verlust anFunktionalität der Sicherheitsfunktionen führt.

Q5 - 84 - 1. Version 1989

Das System muß Selbsttesteinrichtungen für alle Hardwarekomponentenbesitzen, deren korrekte Funktionalität Voraussetzung für das korrekteAblaufen der zu evaluierenden Software ist.

Prüfvorgang


Es wird geprüft, welche Eingriffe bei der Generierung des Systems möglichsind, welche Auswirkungen sie haben. und wie sie protokolliert werden. DieWirksamkeit der Sicherheitsfunktionen im Wartungsfall wird auf Konsistenzmit der Dokumentation geprüft. Es wird geprüft, ob Eingriffe während desStartens des Systems dieses in einen Zustand versetzen können, in demSicherheitsanforderungen nicht mehr erfüllt sind, ohne daß dies protokolliertwird.

Die Einhaltung des Weges bei der Softwareverteilung wird geprüft.Wartungs- und Wiederanlaufprozeduren werden auf Einhaltung deraufgestellten Anforderungen geprüft.Die Selbsttesteinrichtungen des Systems werden stichprobenhaft untersucht.




Prüfvorgang

Die Dokumentation wird auf Vollständigkeit, Verständlichkeit und Hand-habbarkeit geprüft. Es dürfen keine Abweichungen zwischen realemSystemverhalten und der Dokumentation gefunden werden. Der Nachweisdafür wird durch Prüfung der relevanten Teile der Spezifikation und desQuellcodes (inklusive Penetrationstests) erbracht.

1. Version 1989 - 85 - Q6




- verbale, semiformale und formale hierarchisch strukturierte Spezifikation der zuevaluierenden Systemteile mit allen zum Nachvollziehen der formalenKonsistenzbeweise von Modell und Spezifikation notwendigen Unterlagen,




- Beschreibung der verwendeten Hard- und Firmware mit Darlegung derFunktionalität der in Hardware bzw. Firmware realisierten Schutzmechanismen,






Zusätzlich muß ein formales Sicherheitsmodell vorgelegt werden, welchesalle Sicherheitsanforderungen in den Bereichen Vertraulichkeit undIntegrität abdeckt. Das Modell muß als konsistent mit seinen Axiomenbewiesen sein.

Q6 - 86 - 1. Version 1989

Prüfvorgang


Die Konsistenzbeweise für das Modell werden nachvollzogen. Dieses darfkeine Widersprüche zu den verbal formulierten Sicherheitsanforderungenenthalten.



Für das zu evaluierende System bzw. die zu evaluierende Einzelkomponenteist neben der verbalen und der semiformalen Spezifikation auch eineSpezifikation vorzulegen, die in einer formal definiertenSpezifikationssprache formuliert sein muß. Diese Spezifikation muß die Artder Implementierung aller Sicherheitsfunktionen detailliert beschreiben,wobei diese Beschreibung mehrere Hierarchiestufen besitzen muß. Die Zahlder Hierarchiestufen wird durch die Komplexität des Systems bestimmt. Esmuß dargelegt werden, durch welche Teile der Spezifikation die einzelnenSicherheitsanforderungen abgedeckt werden und welche Mechanismen dabeizum Einsatz kommen. Die Konsistenz der obersten Hierarchiestufe derSpezifikation mit dem formalen Sicherheitsmodell muß mathematischbewiesen (verifiziert) sein. Es muß formal beschrieben und formalnachvollziehbar sein, wie die einzelnen Hierarchiestufen aufeinanderabzubilden sind. Die Erfüllung der Sicherheitsanforderungen muß bis auf denQuellcode nachvollziehbar sein.

Für die Spezifikation ist eine Sprache mit formal definierter Syntax undSemantik zu verwenden. Es müssen Werkzeuge zur Syntaxprüfung, zurUnterstützung bei der Generierung der Verifikationsbedingungen sowiezur Unterstützung beim Beweis dieser Verifikationsbedingungenverwendet werden. Es dürfen keine Syntaxfehler und keine unbewiesenenVerifikationsbedingungen vorhanden sein. Die Spezifikationsmethodikmuß die hierarchische Spezifikation unterstützen und die Art der Abbildungunterschiedlicher Hierarchiestufen aufeinander formal festlegen.

1. Version 1989 - 87 - Q6

Prüfvorgang

In der Spezifikation dürfen keine Nebeneffekte gefunden werden, durch dieSicherheitsfunktionen umgangen oder außer Kraft gesetzt werden können. Eswerden zusätzlich formale Methoden eingesetzt, durch die z. B.verdeckte Speicherkanäle gefunden werden können. Die Realisierungder Sicherheitsanforderungen wird bis auf den Quellcode nachvollzogen.

Die Beweise, die die Konsistenz zwischen dem formalen Modell und derobersten Hierarchiestufe der Spezifikation zeigen sollen, werdennachvollzogen. Es wird geprüft, daß diese Beweise hinreichend sind,diese Konsistenz zu zeigen.Ebenso wird die Generierung derVerifikationsbedingungen auf Vollständigkeit und stichprobenhaft aufKorrektheit überprüft. Die Spezifikationssprache wird auf formaleDefinition der Syntax und Semantik ihrer Sprachkonstrukte untersucht. DieSpezifikation wird werkzeugunterstützt auf Syntaxfehler geprüft.




Prüfvorgang

Die verwendeten Mechanismen müssen in ihrer Gesamtheit ausreichend sein,die Sicherheitsanforderungen zu erfüllen. Der zur Erfüllung einer bestimmtenSicherheitsanforderung verwendete Mechanismus bzw. die verwendeteKombination von Mechanismen darf nicht schlechter als mit "sehr stark"bewertet worden sein. Es werden keine Ausnahmen zugelassen.



Die zu evaluierenden Systemteile müssen von nicht zu evaluierenden Teilendes Systems getrennt sein. Es muß dargelegt werden, warum dieSicherheitsfunktionen von den nicht zu evaluierenden Teilen des Systemsnicht umgangen werden können.Alle Schnittstellen zu nicht zu

Q6 - 88 - 1. Version 1989

evaluierenden Systemteilen müssen mit ihren Aufgaben, ihren Parameternund Effekten dokumentiert sein. Die Benutzung von verdeckten Kanälen mußprotokollierbar sein.

Prüfvorgang

Die Mechanismen, die die zu evaluierenden Systemteile von den nicht zuevaluierenden Teilen des Systems separieren, müssen in ihrer Gesamtheitmindestens mit "sehr stark" bewertet worden sein. Durch Tests, Quellcode-untersuchung und Maschinencodeuntersuchung wird überprüft, daß dieSchnittstellen in der beschriebenen Form existieren und keine weiterenvorhanden sind. Dabei dürfen keine Fehler gefunden werden, durch dieSicherheitsfunktionen umgangen oder außer Kraft gesetzt werden können.Zusätzlich werden Prüfungen auf die Existenz von verdeckten Kanälen beiBenutzung der Schnittstellen durchgeführt. Alle so gefundenen Kanälemüssen dokumentiert sein. Kanäle, die zu einem unerlaubten Informationsflußmißbraucht werden können, werden bezüglich ihrer Bandbreite sowie derenAusnutzbarkeit durch "Trojanische Pferde" analysiert. DieProtokollierbarkeit von verdeckten Kanälen wird geprüft. Alle gefundenenund nicht beseitigbaren verdeckten Kanäle dürfen maximal eineBandbreite von 10 Bit/Sekunde besitzen.



Zur Implementierung müssen Sprachen verwendet werden, die eine genormteoder formal definierte Syntax und eine sehr gut dokumentierte Semantikbesitzen. Alle in der Beschreibung der Semantik der Spracheoffengelassenen Punkte müssen in der Dokumentation des verwendetenCompilers eindeutig geklärt sein. Die verwendeten Compiler müssenoffiziell geprüft ("validiert") sein und müssen von der Evaluationsbehördeals Implementierungssprache für Systeme dieser Qualitätsstufezugelassen sein.

Zusätzlich sind ein Quellcodedebugger und ein Maschinencodedebuggerzur Verfügung zu stellen, die das Setzen von Haltepunkten sowie dieAnzeige und Modifikation von Variablen bzw. Speicherbereichen anHaltepunkten ermöglichen.


1. Version 1989 - 89 - Q6

Die Abbildung vom Quellcode auf den erzeugten Maschinencode mußnachvollziehbar sein.

Die Abbildung der niedrigsten Hierarchiestufe der Spezifikation auf denQuellcode muß nachvollziehbar sein. Diese muß die Unterteilung desQuellcodes in Funktionseinheiten widerspiegeln. Es müssen alle Variablen,die von mehr als einer Funktionseinheit benutzt werden, in der niedrigstenHierarchiestufe der Spezifikation definiert und mit ihrem Zweck beschriebensein. Der Quellcode muß durchgehend in kleine, überschaubare, abgegrenzteFunktionseinheiten gegliedert sein. Deren Aufgaben und Schnittstellenmüssen vollständig beschrieben sein.


Bei der Entwicklung und Wartung des Systems ist einKonfigurationsverwaltungs- und Versionskontrollsystem einzusetzen,welches eine diskrete und eine rollenabhängige Zugriffskontrolle zuallen bei der Quellcodeentwicklung anfallenden Objekten(Anforderungskataloge, Spezifikationen, Verifikationsbedingungen,Quellprogramme, Objektmodule, Dokumentationen etc.) ermöglicht undModifikationen dieser Objekte mit Urheber, Datum und Uhrzeitprotokolliert. Außerdem muß dieses System die Rollen von Spezifizierer,Implementierer und Tester kennen und voneinander separieren.

Vom Hersteller muß ein Softwareintegrations- und Abnahmeverfahrenvorgelegt werden. In diesem Verfahren müssen zumindest die Rollen, diedas Konfigurationsverwaltungs- und Versionskontrollsystem kennt, mitihren Aufgaben und Verantwortungsbereichen definiert sein. DerPrüfbehörde sind Unterlagen zur Verfügung zu stellen, aus denen sich dieEinhaltung des Integrations- und Abnahmeverfahrens ersehen läßt. Zu diesenUnterlagen gehören auch die Protokolldaten des Konfigurationsverwaltungs-und Versionskontrollsystems.

Prüfvorgang

Es werden Penetrationstests und Quellcodeinspektionen durchgeführt, durchdie Unklarheiten oder vermutete Schwachstellen, die sich bei der Prüfungder Spezifikation bzw. des Quellcodes ergaben, aufgeklärt werden sollen.Bei diesen Prüfungen wird stichprobenhaft auch der vom Compiler gene-rierte Maschinencode mit einbezogen. Dabei dürfen keine Wege gefundenwerden, durch die Sicherheitsfunktionen umgangen oder außer Kraft gesetztwerden können.

Q6 - 90 - 1. Version 1989

Zusätzlich werden Tests auf Ebene der Funktionseinheiten durchgeführt, mitdenen Unklarheiten oder vermutete Fehler überprüft werden sollen. Dabeidürfen keine Fehler festgestellt werden. Für diese Tests wird auch einQuellcodedebugger und ein Maschinencodedebugger verwendet.

Die Abbildung der niedrigsten Hierarchiestufe der Spezifikation auf denQuellcode wird überprüft. Es werden eigene Testprogramme für denCompiler entworfen. Dabei dürfen keine Fehler in den Compilern gefundenwerden, bei denen der generierte Maschinencode eine fehlerhafte Abbildungder Sprachkonstrukte der Implementierungssprache ist.



Die Protokolldaten des Konfigurationsverwaltungs- und Versionskontrollsy-stems werden an einzelnen Stichproben untersucht.


Betriebsqualität


Falls es unterschiedliche Konfigurationsmöglichkeiten gibt, müssen derenAuswirkungen auf die Sicherheitsanforderungen beschrieben sein. DieseAuswirkungen müssen auch in der formalen Spezifikation erkennbar sein.Diese Auswirkungen auf die Sicherheitsanforderungen dürfen nur gering seinund müssen in der Dokumentation erläutert werden. Es muß im laufendenBetrieb durch dazu autorisierte Rollen jederzeit feststellbar sein, wiedas System konfiguriert worden ist.



1. Version 1989 - 91 - Q6



Im laufenden Betrieb darf keine Softwarewartung durchgeführt werden,durch die Sicherheitsfunktionen außer Kraft gesetzt werden. FallsSicherheitsfunktionen im Falle einer Hardwarewartung außer Kraft gesetztsind, muß dies im Handbuch für den Systemverwalter dokumentiert sein. Indiesem Fall darf keine Hardwarewartung ohne explizites Einverständnisdes Systemverwalters möglich sein.

Beim Starten des Systems dürfen keine nicht protokollierten Eingriffemöglich sein, durch die das System in einen Zustand versetzt wird, in demdie Sicherheitsanforderungen nicht erfüllt sind. Es muß ein Verfahrenexistieren, das Modifikationen an evaluierten Teile der Software beimStarten des Systems erkennen kann.

Es müssen Prozeduren existieren, die das System auch nach einem Sy-stemabsturz sowie nach einem Hard- oder Softwarefehler wieder in einensicheren Zustand bringen. Diese Prozeduren müssen so gestaltet sein, daßeine Fehlbedienung nicht zu einem unerkannten Verlust an Funktionalität derSicherheitsfunktionen führt.


Prüfvorgang


Es wird geprüft, welche Eingriffe bei der Generierung des Systems möglichsind, welche Auswirkungen sie haben, und wie sie protokolliert werden. DieWirksamkeit der Sicherheitsfunktionen im Wartungsfall wird auf Konsistenzmit der Dokumentation geprüft.

Q6 - 92 - 1. Version 1989

Es wird geprüft, ob Eingriffe während des Startens des Systems dieses ineinen Zustand versetzen, in dem die Sicherheitsanforderungen nicht mehrerfüllt sind, ohne daß dies protokolliert wird.

Die Einhaltung des Wegs bei der Softwareverteilung wird geprüft.Wartungs- und Wiederanlaufprozeduren werden auf Einhaltung deraufgestellten Anforderungen geprüft.

Die Selbsttesteinrichtungen des Systems werden untersucht.




Prüfvorgang

Die Dokumentation wird auf Vollständigkeit, Verständlichkeit und Handhab-barkeit geprüft. Es dürfen keine Abweichungen zwischen der Dokumentationund dem realen Systemverhalten gefunden werden. Der Nachweis dafür wirddurch Prüfung der relevanten Teile der Spezifikation und des Quellcodes(inklusive Penetrationstests) erbracht.

1. Version 1989 - 93 - Q7




- verbale, semiformale und formale hierarchisch strukturierte Spezifikation der zuevaluierenden Systemteile mit allen zum Nachvollziehen der formalenKonsistenzbeweise von Modell und allen Hierarchiestufen der Spezifikationnotwendigen Unterlagen,




- Beschreibung der verwendeten Hard- und Firmware mit Darlegung derFunktionalität der in Hardware bzw. Firmware realisierten Schutzmechanismen,


- Quellcode der Implementierung der zu evaluierenden Systemteile mit allen zumNachvollziehen der formalen Konsistenzbeweise von Spezifikation undQuellcode notwendigen Unterlagen.




Zusätzlich muß ein formales Sicherheitsmodell vorgelegt werden, welchesalle Sicherheitsanforderungen abdeckt. Das Modell muß als konsistent mitseinen Axiomen bewiesen sein.

Q7 - 94 - 1. Version 1989

Prüfvorgang


Die Konsistenzbeweise für das Modell werden nachvollzogen. Dieses darfkeine Widersprüche zu den verbal formulierten Sicherheitsanforderungenenthalten.



Für das zu evaluierende System bzw. die zu evaluierende Einzelkomponenteist neben der verbalen und der semiformalen Spezifikation auch eineSpezifikation vorzulegen, die in einer formal definiertenSpezifikationssprache formuliert sein muß. Diese Spezifikation muß die Artder Implementierung aller Sicherheitsfunktionen detailliert beschreiben,wobei diese Beschreibung mehrere Hierarchiestufen besitzen muß. Die Zahlder Hierarchiestufen wird durch die Komplexität des Systems bestimmt. Esmuß dargelegt werden, durch welche Teile der Spezifikation die einzelnenSicherheitsanforderungen abgedeckt werden und welche Mechanismen dabeizum Einsatz kommen. Die Konsistenz aller Hierarchiestufen derSpezifikation mit dem formalen Sicherheitsmodell muß mathematischbewiesen (verifiziert) sein. Es muß formal bewiesen sein, daß dieeinzelnen Hierarchiestufen aufeinander abbildbar sind. Die Erfüllung derSicherheitsanforderungen muß bis auf den Quellcode bewiesen sein.

Für die Spezifikation ist eine Sprache mit formal definierter Syntax undSemantik zu verwenden. Es müssen Werkzeuge zur Syntaxprüfung, zurUnterstützung bei der Generierung der Verifikationsbedingungen sowie zurUnterstützung beim Beweis dieser Verifikationsbedingungen verwendetwerden. Es dürfen keine Syntaxfehler und keine unbewiesenenVerifikationsbedingungen vorhanden sein. Die Spezifikationsmethodik mußdie hierarchische Spezifikation unterstützen und die Art der Abbildungunterschiedlicher Hierarchiestufen aufeinander formal festlegen.

Prüfvorgang

In der Spezifikation dürfen keine Nebeneffekte gefunden werden, durch dieSicherheitsfunktionen umgangen oder außer Kraft gesetzt werden können. Eswerden zusätzlich formale Methoden eingesetzt, durch die z. B. verdeckteSpeicherkanäle gefunden werden können. Die vorliegenden Beweise für dieRealisierung der Sicherheitsanforderungen werden bis auf den Quellcodenachvollzogen.

1. Version 1989 - 95 - Q7

Die Beweise, die die Konsistenz zwischen dem formalen Modell und derobersten Hierarchiestufe der Spezifikation und die Konsistenz dereinzelnen Hierarchiestufen der Spezifikation untereinander zeigensollen, werden nachvollzogen. Es wird geprüft, daß diese Beweisehinreichend sind, diese Konsistenz zu zeigen. Ebenso wird die Generierungder Verifikationsbedingungen auf Vollständigkeit und stichprobenhaft aufKorrektheit überprüft. Die Spezifikationssprache wird auf formaleDefinition der Syntax und der Semantik ihrer Sprachkonstrukte untersucht.Die Spezifikation wird werkzeugunterstützt auf Syntaxfehler geprüft.



Die zur Realisierung der Sicherheitsanforderungen verwendeten Mechanis-men und Algorithmen sind in der Spezifikation zu beschreiben.

Prüfvorgang

Die verwendeten Mechanismen müssen in ihrer Gesamtheit ausreichend sein,die Sicherheitsanforderungen zu erfüllen. Der zur Erfüllung einer bestimmtenSicherheitsanforderung verwendete Mechanismus bzw. die verwendeteKombination von Mechanismen darf nicht schlechter als mit mit "nichtüberwindbar" bewertet worden sein. Nur in Ausnahmefällen kann auchein Mechanismus verwendet werden, der nur mit "sehr stark" bewertetwurde.



Die zu evaluierenden Systemteile müssen von nicht zu evaluierenden Teilendes Systems getrennt sein. Es muß dargelegt werden, warum dieSicherheitsfunktionen von den nicht zu evaluierenden Teilen des Systemsnicht umgangen werden können.Alle Schnittstellen zu nicht zu evaluierendenSystemteilen müssen mit ihren Aufgaben, ihren Parametern und Effektendokumentiert sein. Die Benutzung von verdeckten Kanälen mußprotokollierbar sein.

Q7 - 96 - 1. Version 1989

Prüfvorgang

Die Mechanismen, die die zu evaluierenden Systemteile von den nicht zuevaluierenden Teilen des Systems separieren, müssen in ihrer Gesamtheitmit "nicht überwindbar" bewertet worden sein. Durch Tests,Quellcodeuntersuchung und Maschinencodeuntersuchung wird überprüft, daßdie Schnittstellen in der beschriebenen Form existieren und keine weiterenvorhanden sind. Dabei dürfen keine Fehler gefunden werden, durch dieSicherheitsfunktionen umgangen oder außer Kraft gesetzt werden können.Zusätzlich werde Prüfungen auf die Existenz von verdeckten Kanälen beiBenutzung der Schnittstellen durchgeführt. Alle so gefundenen Kanälemüssen dokumentiert sein. Kanäle, die zu einem unerlaubten Informationsflußmißbraucht werden können, werden bezüglich ihrer Bandbreite sowie derenAusnutzbarkeit durch "Trojanische Pferde" analysiert. DieProtokollierbarkeit von verdeckten Kanälen wird überprüft. Alle gefundenenund nicht beseitigbaren verdeckten Kanäle dürfen maximal eine Bandbreitevon 1 Bit/Sekunde besitzen.



Zur Implementierung müssen Sprachen verwendet werden, die eine genormteoder formal definierte Syntax und eine formal definierte Semantik besitzen.In dieser Definition der Semantik dürfen nur sehr wenige Punkteoffengelassen sein. Alle offengelassenen Punkte müssen genau erläutertwerden. In der Implementierungsbeschreibung des verwendetenCompilers muß die Semantik dieser Teile dann formal definiert sein. Dieverwendeten Compiler müssen offiziell geprüft ("validiert") sein undmüssen von der Evaluationsbehörde als Implementierungssprache fürSysteme dieser Qualitätsstufe zugelassen sein.

Zusätzlich sind ein Quellcodedebugger und ein Maschinencodedebugger zurVerfügung zu stellen, die das Setzen von Haltepunkten sowie die Anzeigeund Modifikation von Variablen bzw. Speicherbereichen an Haltepunktenermöglichen.


Die Abbildung vom Quellcode auf den erzeugten Maschinencode mußnachvollziehbar sein. Auch die Maschinensprache des verwendetenProzessors muß weitgehend formal definiert sein.

1. Version 1989 - 97 - Q7

Die Konsistenz zwischen der niedrigsten Hierarchiestufe derSpezifikation und dem Quellcode muß formal bewiesen (verifiziert) sein.Diese muß die Unterteilung des Quellcodes in Funktionseinheitenwiderspiegeln. Es müssen alle Variablen, die von mehr als einerFunktionseinheit benutzt werden, in der niedrigsten Hierarchiestufe derSpezifikation definiert und mit ihrem Zweck beschrieben sein. DerQuellcode muß durchgehend in kleine, überschaubare, abgegrenzteFunktionseinheiten gegliedert sein. Deren Aufgaben und Schnittstellenmüssen vollständig beschrieben sein.

Zusätzlich muß eine Bibliothek mit Testprogrammen sowie der zu-gehörigenTestdokumentation zur Verfügung stehen. Die Test-dokumentation mußenthalten: Testplan, Zweck, Vorgehensweise und Ergebnisse der Tests.

Bei der Entwicklung und Wartung des Systems ist einKonfigurationsverwaltungs- und Versionskontrollsystem einzusetzen,welches eine diskrete und eine rollenabhängige Zugriffskontrolle zu allen beider Quellcodeentwicklung anfallenden Objekten (Anforderungskataloge,Spezifikationen, Verifikationsbedingungen, Quellprogramme, Objektmodule,Dokumentationen etc.) ermöglicht und Modifikationen dieser Objekte mitUrheber, Datum und Uhrzeit protokolliert. Außerdem muß dieses System dieRollen von Spezifizierer, Implementierer und Tester kennen und voneinanderseparieren. Das gesamte Entwicklungspersonal muß überprüft sein.

Vom Hersteller muß ein Softwareintegrations- und Abnahmeverfahrenvorgelegt werden. In diesem Verfahren müssen zumindest die Rollen, die dasKonfigurationsverwaltungs- und Versionskontrollsystem kennt, mit ihrenAufgaben und Verantwortungsbereichen definiert sein. Der Prüfbehörde sindUnterlagen zur Verfügung zu stellen, aus denen sich die Einhaltung desIntegrations- und Abnahmeverfahrens ersehen läßt. Zu diesen Unterlagengehören auch die Protokolldaten des Konfigurationsverwaltungs- undVersionskontrollsystems.

Prüfvorgang

Es werden Penetrationstests und Quellcodeinspektionen durchgeführt, durchdie Unklarheiten oder vermutete Schwachstellen, die sich bei der Prüfungder Spezifikation bzw. des Quellcodes ergaben, aufgeklärt werden sollen.Bei diesen Prüfungen wird auch der vom Compiler generierteMaschinencode mit einbezogen. Dabei dürfen keine Wege gefundenwerden, durch die Sicherheitsfunktionen umgangen oder außer Kraft gesetztwerden können.Zusätzlich werden Tests auf Ebene der Funktionseinheiten durchgeführt, mitdenen Unklarheiten oder vermutete Fehler überprüft werden sollen. Dabeidürfen keine Fehler festgestellt werden. Für diese Tests wird auch ein

Q7 - 98 - 1. Version 1989

Quellcodedebugger und ein Maschinencodedebugger verwendet. DerQuellcode wird unter Einsatz formaler Methoden auf die Existenz vonverdeckten Kanälen untersucht. Es wird geprüft, daß alle gefundenenund nicht beseitigbaren verdeckten Kanäle dokumentiert sind.

Es werden die Beweise zur Konsistenz von Spezifikation und Quellcodeauf Korrektheit und Vollständigkeit geprüft.

Für die Generierung von Penetrationstests und bei der Suche nachverdeckten Kanälen wird auch der erzeugte Maschinencode analysiert.

Es werden Tests durchgeführt, die die Einhaltung der formalenDefinition der Maschinensprache auf dem verwendeten Prozessornachweisen sollen. Dabei dürfen keine Unstimmigkeiten oderundokumentierte Nebeneffekte gefunden werden.

Die Abbildung der niedrigsten Hierarchiestufe der Spezifikation auf denQuellcode wird überprüft. Es werden eigene Testprogramme für denCompiler entworfen. Dabei dürfen keine Fehler in den Compilern gefundenwerden, bei denen der generierte Maschinencode eine fehlerhafte Abbildungder Sprachkonstrukte der Implementierungssprache ist.

Alle Testbeispiele aus der Testbibliothek werden nachvollzogen und müssendie in der Dokumentation beschriebenen Ergebnisse liefern.


Die Protokolldaten des Konfigurationsverwaltungs- und Versionskontrollsy-stems werden an einzelnen Stichproben untersucht.


1. Version 1989 - 99 - Q7

Betriebsqualität


Falls es unterschiedliche Konfigurationsmöglichkeiten gibt, müssen derenAuswirkungen auf die Sicherheitsanforderungen beschrieben sein. DieseAuswirkungen müssen auch in der formalen Spezifikation erkennbar sein.Diese Auswirkungen auf die Sicherheitsanforderungen dürfen nur gering seinund müssen in der Dokumentation erläutert werden. Es muß im laufendenBetrieb durch dazu autorisierte Rollen jederzeit feststellbar sein, wie dasSystem konfiguriert worden ist.





Im laufenden Betrieb darf keine Softwarewartung durchgeführt werden,durch die Sicherheitsfunktionen außer Kraft gesetzt werden. FallsSicherheitsfunktionen im Falle einer Hardwarewartung außer Kraft gesetztsind, muß dies im Handbuch für den Systemverwalter dokumentiert sein. Indiesem Fall darf keine Hardwarewartung ohne explizites Einverständnis desSystemverwalters möglich sein.

Beim Starten des Systems dürfen keine nicht protokollierten Eingriffemöglich sein, durch die das System in einen Zustand versetzt wird, in demdie Sicherheitsanforderungen nicht erfüllt sind. Es muß ein Verfahrenexistieren, das Modifikationen an evaluierten Teile der Software beimStarten des Systems erkennen kann.

Es müssen Prozeduren existieren, die das System auch nach einem Systemab-sturz sowie nach einem Hard- oder Softwarefehler wieder in einen sicherenZustand bringen. Diese Prozeduren müssen so gestaltet sein, daß eine

Q7 - 100 - 1. Version 1989

Fehlbedienung nicht zu einem unerkannten Verlust an Funktionalität derSicherheitsfunktionen führt.


Prüfvorgang

Die Auswirkungen unterschiedlicher Konfigurationen werden an Hand derSpezifikation, des Quellcodes sowie der Dokumentation auf Konsistenz mitden Sicherheitsanforderungen geprüft. Bei Unklarheiten oder vermutetenFehlern werden Tests durchgeführt, durch die diese Unklarheiten aufgeklärtwerden sollen. Durch diese Tests müssen alle Unklarheiten beseitigtwerden.Es wird geprüft, welche Eingriffe bei der Generierung des Systems möglichsind, welche Auswirkungen sie haben, und wie sie protokolliert werden. DieWirksamkeit der Sicherheitsfunktionen im Wartungsfall wird auf Konsistenzmit der Dokumentation geprüft. Es wird geprüft, ob Eingriffe während desStartens des Systems dieses in einen Zustand versetzen, in dem dieSicherheitsanforderungen nicht mehr erfüllt sind, ohne daß dies protokolliertwird.

Die Einhaltung des Weges bei der Softwareverteilung wird geprüft.Wartungs- und Wiederanlaufprozeduren werden auf Einhaltung deraufgestellten Anforderungen geprüft.

Dies beinhaltet auch gezielte Penetrationstests. Es dürfen keineUnstimmigkeiten gefunden werden.Die Selbsttesteinrichtungen des Systems werden untersucht.




Prüfvorgang

Die Dokumentation wird auf Vollständigkeit, Verständlichkeit und Handhab-barkeit geprüft. Es dürfen keine Abweichungen zwischen der Dokumentationund dem realen Systemverhalten gefunden werden. Der Nachweis dafür wirddurch Prüfung der relevanten Teile der Spezifikation und des Quellcodes(inklusive Penetrationstests) erbracht.

1. Version 1989 - 101 -

Glossar

Authentisierung: Nachweis der angegebenen Identität.

Bedrohung: Faktor oder Umstand, der die Einhaltung der Sicherheitsanforderungenan das IT-System gefährden kann.

Benutzer: Person, die mit dem IT-System in Verbindung steht und dessen Diensteund Funktionen in Anspruch nimmt.

Betriebsqualität: Maß für die Einhaltung der Sicherheitsanforderungen während desBetriebs eines IT-Systems, insbesondere in Ausnahmesituationen wie z.B.Fehler, Wartung.

Beweissicherung: Protokollierung der Ausübung bzw. der versuchten Ausübung vonRechten, insbesondere um Verstöße gegen die Sicherheitsanforderungennachträglich nachweisen zu können.

Datenübertragung: Transport von Daten, wobei der Übertragungsweg imallgemeinen nicht durch die Funktionen der Rechteprüfung undRechteverwaltung gesichert ist.

Evaluation: Prüfung und Bewertung eines IT-Systems anhand der IT-Sicherheitskriterien.

Evaluationsbehörde: Diese Behörde koordiniert die Evaluation und zertifiziert dasevaluierte Produkt gemäß der Bewertung.

Evaluationsbericht: Dokument, in dem das Ergebnis der Prüfung des IT-Systems unddie daraus resultierende Bewertung nach Einzelaspekten aufgegliedertniedergelegt ist.

Evaluationshandbuch: Richtlinien zur Vorgehensweise bei der Evaluation.

Falltür: Eine versteckte Funktionalität des Systems, die es erlaubt, dieSicherheitsanforderungen zu umgehen.

Formaler Beweis: Strenger Beweis im mathematischen Sinne, i.a. aufPrädikatenlogik beruhend.

Formales Modell: Ein formales Modell besteht aus Mengen von abstrakten Objektenmit darauf definierten Funktionen und Operationen, für die bestimmteGesetzmäßigkeiten (Axiome) gelten. Grundgerüst für ein formales Modellist zum Beispiel die Prädikatenlogik. Ein Modell entsteht aus der Realität

- 102 - 1. Version 1989

durch Abstrahieren (und damit Vereinfachen) und ist einermathematischen Behandlung zugänglich.

(formales) Sicherheitsmodell: (formales) Modell für die Sicherheitsanforderungenbzw. Teile davon.

Funktionalitätsklasse: Klasse, die bestimmte Mindestanforderungen bezüglich derFunktionalität der Sicherheitsfunktionen an ein IT-System stellt.

Identifikation: Bestimmung der Identität eines Subjekts bzw. Objekts.

Integrität: Maß für die Unverfälschtheit und Korrektheit von Daten.

IT-System: System der Informationstechnik

Kanal, verdeckter: Kommunikationsweg, der einen den Sicherheitsanforderungenzuwiderlaufenden Informationsfluß ermöglicht. Die Bandbreite einesverdeckten Kanals ist ein Maß für die mögliche Stärke diesesInformationsflusses im nachrichtentechnischen bzw.informationstheoretischen Sinn.

Konfigurierung: Wahl einer der für ein IT-System möglichen Ausprägungen (hard-und softwareseitig).

Mechanismus: Algorithmus zur Realisierung vorgegebenerSicherheitsanforderungen.

Nebeneffekt: Unbeabsichtigte, unspezifizierte Nebenwirkung einer Funktion, dieunter Umständen auch eine Verletzung der Sicherheitsanforderungenbewirken bzw. ermöglichen kann.

Objekt: Objekte spielen die passive Rolle in der Rechteverwaltung bzw.Rechteprüfung, d.h. auf sie wird zugegriffen. Z.B. Dateien,Inhaltsverzeichnisse, Geräte.

Penetration: Umgehung der Sicherheitsanforderungen eines IT-Systems.

Penetrationstest: Test mit dem Ziel, die Sicherheitsfunktionen auf die Möglichkeitzur Penetration hin zu untersuchen.

Qualität: Maß für die Güte mit der bestimmte Anforderungen an ein IT-Systemerfüllt werden.

Qualitätsstufen: Hierarchische Unterteilung bezüglich der Qualität eines IT-Systems. Bei der Evaluation erfolgt die Bewertung der Qualität eines IT-

1. Version 1989 - 103 -

Systems. Anhand dieser Bewertung erfolgt eine Einstufung in eine derQualitätsstufen Q0 bis Q7.

Rechteprüfung: Überprüfung durch das System, ob ein bestimmtes Subjekt dieBerechtigung hat, in der beabsichtigten Art auf das gewünschte Objektzuzugreifen. Durch die Rechteprüfung wird die unbefugte Ausübung vonRechten verhindert.

Rechteverwaltung: Teil des Systems, der die Rechtebeziehungen zwischenSubjekten und Objekten verwaltet, z.B. in Form der Verwaltung einerZugriffskontrolliste.

Rolle: Eine Rolle ist eine Gruppierung von Rechten, die einem Subjekt zugewiesenworden sind. Z.B. die Rolle des Systemverwalters.

Schwachstelle: Schwäche im IT-System, die zur Umgehung oder Täuschung derSicherheitsanforderungen ausgenutzt werden kann.

Sicherheitsanforderungen: Eine Menge von Forderungen und Regeln, die festlegen,wie sicherheitskritische Daten zu handhaben und zu verarbeiten sind.

Sicherheitsfunktionen: Funktionen, die die Sicherheitsanforderungen im IT-Systemverwirklichen.

Sicherheitskritisches Ereignis: Ein Ereignis, welches einen Verstoß gegen dieSicherheitsanforderungen bewirken kann.

Spezifikation: Definition der zur Abdeckung der Sicherheitsanforderungen nötigenSicherheitsfunktionen.

Subjekt: Subjekte spielen die aktive Rolle in der Rechteverwaltung bzw.Rechteprüfung, d.h. sie üben Rechte auf Objekte aus. Z.B. Personen,Prozesse.

Systemverwalter: Rolle in der Rechteverwaltung, i.a. mit außergewöhnlichenRechten versehen.

Trojanisches Pferd: Ein Programm, das vordergründig eine nützliche Aufgabe ver-richtet, versteckt jedoch weitere Aktionen durchführt, wie z. B. sich diePrivilegien bzw. Rechte des Aufrufers zunutze zu machen, um dieSicherheitsanforderungen zu unterlaufen.

Verfügbarkeit: Die Verfügbarkeit eines IT-Systems bzw. einzelnerSystemfunktionen wird durch die Wartezeit auf Systemfunktionen bzw. aufbenötigte Betriebsmittel bestimmt.

- 104 - 1. Version 1989

Verifikation: Nachweis der Korrektheit von Programmen mit formalen Mitteln, wiez.B. wp-Kalkül.

Wiederaufbereitung: Aufbereitung wiederverwendbarer Betriebsmittel, wie z.B.Haupt- oder Peripherspeicher, um einen den Sicherheitsanforderungenzuwiderlaufenden Informationsfluß zwischen Subjekt bzw. Objekt, diedieses Betriebsmittel nacheinander benutzen, zu verhindern.

1. Version 1989 -105 -

Tabellen

Die nachfolgenden beiden Tabellen zeigen in einer Übersicht die funktionalenAnforderungen der hierarchisch geordneten Funktionalitätsklassen F1 - F5 und diequalitativen Anforderungen der Qualitätsstufen Q1 - Q7.

- 106 - 1. Version 1989

Anforderungen an die Funktionalität

(der hierarchisch geordneten Klassen F1 – F5)

F1 F2 F3 F4 F5X X X Subjektidentifizierung und - authentisierung Identifikation

X X Vertrauenswürdiger Zugriffspfad und Authentisierung

X X X X Benutzerbestimmbarer Zugriffsschutz

X Festgelegter, regelbasierter Zugriffsschutz

X Attribute für Subjekte und Objekte

X Integrität der Attribute

X Ausgabe von Informationen über Attributwerte Rechte-

X Ausgabe über einstufige Kanäle verwaltung

X X Ausgabe über mehrstufige Kanäle

X Ausgabe von attributierten Informationen

X Attribute menschenlesbarer Ausgaben

X X Überprüfung von Ereignissen und Daten Rechteprüfung

X X X Protokollierung von Ereignissen und Daten

X Auswertung und Dokumentation von Protokolier-

ungsdaten

Beweissicherung

X Überwachung sicherheitskritischer Ereignisse

X Wiederaufbereitung von Objekten Wiederaufbereitung

Keine Anforderungen an

diese Klasse

X Neue oder erweiterte

Anforderungen an diese Klasse

Keine Zusatzanforderungen

1. Version 1989 -107 -

Anforderungen an die Qualität

Q1 Q2 Q3 Q4 Q5 Q6 Q7X X X Spezifikation der Sicherheitsanforderungen Qualität der

X X X Formales Sicherheitsmodell Sicherheitsanforderungen

X X X X Verbale Entwurfsspezifikation

X Semiformale Entwurfsspezifikation Qualität der

X X Formale Entwurfsspezifikation Spezifikation

X X Werkzeuge zur Prüfung der Spezifikation

X X X X X X X Implementierte Mechanismen und Algorithmen Qualität der Mechanismen

X Spezifikation der Abgrenzung

X X X Abgrenzungsmechanismen Qualität der

X X X Protok. und Analyse von verdeckten Kanälen Abgrenzung

X X X X X X Abbildbarkeit Spezifikat. <-> Implementierung

X Bibliothek mit Testprogrammen

X X X X X Implementierungssprachen und Tools Qualität des

X X X Änderungs- und Versionskontrolle Herstellungsvorgangs

X X X Softwareintegrations- u. Abnahmeverfahren

X Vertrauenswürdiges Entwicklungspersonal

X X Vertrauenswürdige Systemgenerierung

X Vertrauenswürdige Systemeinspielung

X Vertrauenswürdige Systemverteilung

X X Vertrauenswürdiger Systemstart Betriebsqualität

X Vertrauenswürdiger Wiederanlauf

X X X X Systemkonfigurierung

X X X Wartung von Hardware und Software

X X Selbsttests der Hardware

X Anwenderdok. der Sicherheitsfunktion Qualität der Dokumentation

Keine Anforderungen an

diese Klasse

X Neue oder erweiterte

Anforderungen an diese Klasse

Keine Zusatzanforderungen

Deutsche IT-Sicherheitskriterien

Documents

Transcript of Deutsche IT-Sicherheitskriterien