(Ausarbeitung als PDF herunterladen)
Technische
Universität München
Hauptseminar
Ansätze für Betriebssysteme der Zukunft
Sommersemester
2005
BOSS
Standard
for Baseline Operating Systems Security
Betreuer: Dipl.-Inf. (univ.) Werner Held
Bearbeiter: Alexander Scherer
Ausarbeitung
Inhaltsverzeichnis
1
Beteiligte Organisationen 2
1.1 National Institute of Standards and Technology (NIST) 2
a) Kurze Fakten 2
b) Aufgabenbereiche 3
c) Publikationen 3
d) National Information Assurance Partnership (NIAP) 4
1.2 Institute of Electrical and Electronics Engineers (IEEE) 4
a) Wichtige
IEEE-Standards 4
b) Laufende Projekte 5
2 Definitionen 5
2.1 Commercial off-the-shelf (COTS) 5
2.2 Common Criteria (CC) 5
2.3 Schutzprofile (Protection Profiles, PP) 6
2.4 COTS Security Protection Profile (CSPP) 7
a) Anwendungsbereich 7
b) Übersicht der CSPP
Anforderungen 9
3 Standard for Baseline Operating Systems
Security (BOSS) 9
3.1
Entstehungsgeschichte 10
3.2 Zielsetzung 10
3.3 Übersichtsgrafik
11
4
COTS Security Protection Profile - Operating Systems (CSPP-OS) 11
4.1 Motivation 11
4.2
Evaluationsgegenstand (TOE) 11
a) Produktklasse 12
b) Arbeitsumgebung 12
c) Geforderte
Sicherheitsfunktionen 12
4.3 Die Sicherheitsumgebung
12
a) Arbeitsumgebung 13
b)
Organisationsinterne Sicherheitsrichtlinien 13
c) Maßnahmen des TOE
zum Abwehren von Angriffen und beseitigen von Sicherheitslücken 13
d) Auftreten von
Sicherheitsrisiken außerhalb des Wirkungsbereichs des TOE und deren Beseitigung
15
e) Bereiche in denen
sowohl TOE als auch dessen Umgebung Sicherheitsverantwortung tragen 17
f) Beschreibung der
„Assurance“ 17
4.4 Funktionale
Anforderungen 18
a) Betriebssystem
(TOE) 18
b) Die IT Umgebung 18
c) Die Nicht-IT Umgebung
18
d) SOF 18
5
Zusammenfassung 18
6
Anhang 18
6.1
Abkürzungsverzeichnis 18
6.2 Glossar 19
6.3 Quellen 23
1 Beteiligte Organisationen
Um dem Leser die Einarbeitung
in die Thematik des Standards für „Baseline Operating Systems Security“ zu erleichtern wird im folgendem
Abschnitt ein Überblick über die an der Entstehung von beteiligten
Organisationen gegeben.
1.1 National Institute of Standards and Technology (NIST)
a) Kurze Fakten (aus [NIST Homepage])
Die Behörde gehört
zur technologischen Verwaltung des Wirtschaftsministeriums der vereinigten
Staaten von Amerika und befasst sich mit
der Formulierung und Definition von Standardisierungsprozessen, der Entwicklung
und der Forschung auf den Gebieten Messungen und Technologie. Der Hauptsitz der
1901 als erste Bundesforschungseinrichtung gegründeten Behörde befindet sich in
Gaithersburg (Maryland).
Das „National Institute of Standards and Technology“ ist in vier Einrichtungen
aufgegliedert:
·
Die Forschungslabors,
welche die technologische Infrastruktur für die amerikanische Industrie
bereitstellen, um deren Produkte und Dienstleistungen ständig zu verbessern.
·
Der „Hollings
Manufacturing Extension Partnership“, die kleinen Herstellern ein
überregionales Netz von Zentren zur Verfügung stellt, um ihnen technische wie
wirtschaftliche Hilfe zu geben.
·
Dem „Malcolm
Baldrige National Quality Award“, der hervorragende Leistungen und
Qualitätssicherung unter den amerikanischen Herstellern,
Dienstleistungsgestellschaften und Forschungseinrichtungen fördert.
·
Das „Advanced
Technology Program“ zur Förderung der Forschung und Entwicklung von innovativen
Technologien.
Bei ihrer Arbeit wird die
Behörde im Jahr 2005 durch ein operatives Budget von 858 Milliarden Dollar und
von 3000 Wissenschaftlern, Ingeneuren, Techniker und Verwaltungangestellten
unterstützt. Zusätzlich erwartet NIST 44,6 Millionen an Gebühren für
Dienstleistungen wie Kalibrierungen, Messungsstandards und Akkreditierung von
Labors.
b) Aufgabenbereiche (aus [NIST Homepage])
NIST's Hauptziel besteht darin
die Wettbewerbsvorteile Amerikas durch technologische Innovationen zu sichern.
Neue Technologien im Bereich der Bio- und Nanotechnologie und im Bereich der
Informatik hängen von den Werkzeugen, die NIST zum Messen, Auswerten und
Standardisieren entwickelt hat, ab. Das Hauptziel, das das Institut auf der
eigenen Webseite nennt ist es „eine bessere Zukunft zu ermöglichen“, indem es
Messmethoden, Standards und Technologie zur Prodktivitässteigerung,
Handelserleichterungen und der Steigerung des Lebensqualität entwickelt.
c) Publikationen
Die
Computersicherheits-Abteilung ist eine von insgesamt acht Abteilungen der NIST
IT-Labors. Regelmäßig veröffentlicht diese Abteilung sogenannte Interagency
Reports (IRs). Im folgenden sind einige Beispiele aufgeführt:
|
NIST IR 7219 |
"Computer Security Division - 2004 Annual Report" |
April 2005 |
|
NIST IR 7100 |
"PDA Forensic Tools:An Overview and Analysis" |
August 2004 |
|
NIST IR 7046 |
"A Framework for Multi-Mode Authentication: Overview and
Implementation Guide" |
August 2003 |
|
NIST IR 7030 |
"Picture Password: A Visual Login Technique for |
July 2003 |
|
NIST IR 6985 |
"COTS Security Protection Profile - Operating
Systems (CSPP-OS) (Worked Example Applying Guidance of NISTIR-6462,
CSPP)" |
April 2003 |
|
NIST IR 6462 |
"CSPP - Guidance for COTS Security Protection
Profiles" |
December 1999 |
Tabelle
1 Auszug aus den NIST Interagency Reports [NIST publications]
Die beiden zuletzt genannten
dienen als Grundlage für das BOSS auf das später im Detail eingegangen wird.
d) National Information
Assurance Partnership (NIAP)
NIAP ist eine von der
amerikanischen Regierung initiierte Partnerschaft zwischen dem NIST und der
National Security Agency (NSA), um die Sicherheitsbedürfnisse sowohl für
Anwender und Hersteller von Informationstechnik sicherzustellen.
Ziel der Partnerschaft ist es der amerikanische Regierung eine weitreichende
Auswahl an empfohlenen Schutzprofilen (siehe Kapitel 2.3) in den
technologischen Schlüsselbereichen zur Verfügung zu stellen. Dafür wird
versucht ein Konsens sowohl der Schutzprofile aus dem öffentlichen als auch dem
privaten Bereich auf nationaler und internationaler Ebene zu bilden.
Das Langzeitziel dieser Partnerschaft ist es das Vertrauen der Kunden in
Informationssysteme und Netze durch „kosteneffektive Sicherheit für Tests,
Ausweitungsprogramme und Gewährleistungsprüfungen” zu gewinnen.
Als Zertifizierungsstelle der Common Criteria in den USA verantwortet NIAP das
„Common Criteria Evaluation and Validation Scheme (CCEVS)“ [CC Consumers].
1.2 Institute of Electrical and Electronics Engineers (IEEE) [IEEE Wiki])
Das IEEE (Institute of
Electrical and Electronics Engineers) ist ein weltweiter Berufsverband von
Ingenieuren aus den Bereichen Elektrotechnik und Informatik. Es ist
Veranstalter von Fachtagungen, Herausgeber diverser Fachzeitschriften und
bildet Gremien für die Standardisierung von Technologien, Hardware und
Software. Wissenschaftlichen Beiträgen in Zeitschriften oder zu Konferenzen des
IEEE wird im Allgemeinen eine besonders hohe fachliche Güte unterstellt.
Das IEEE ist mit mehr als 360.000 Mitgliedern in 175 Ländern (2005) der größte
technische Berufsverband der Welt. Es zergliedert sich in zahlreiche
sogenannten „Societies“ die sich mit speziellen Gebieten der Elektro- und
Informationstechnik auseinandersetzen und in ihrer Vielfalt das gesamte
Spektrum der Elektro- und Informationstechnik abdecken. Dem Executive Committee
der IEEE Section Germany sitzt derzeit Prof. Dr. Ing. Adolf J. Schwab als
Chairman vor. Weltweit ist die Mitgliedsarbeit in ca. 300 länderorientierten
Gruppen zusammengefasst.
Das IEEE entstand am 1. Januar 1963 aus dem Zusammenschluss der beiden
amerikanischen Ingenieursverbände American Institute of Electrical Engineers
(AIEE) und Institute of Radio Engineers (IRE).
a) Wichtige IEEE-Standards
o
IEEE 488 (Bussystem für Peripheriegeräte)
o
IEEE 754 (Fließkomma-Arithmetik-Spezifikationen)
o
IEEE 802 (LAN/MAN)
o
IEEE 1275 (Open Firmware)
o
IEEE 1284 (Parallele Schnittstelle)
o
IEEE 1451
(Intelligente Sensorik im Netzwerk)
o
IEEE 1003 (POSIX)
o
IEEE 1394 (FireWire)
b) Laufende Projekte [IEEE Projects]
·
P1667 - Standard Protocol for Authentication in Host
Attachments of Transient Storage Devices
·
P1700 - Standard for Information System Security
Assurance Architecture (ISSAA)
·
P2600 - Standard for Information Technology: Hardcopy
System and Device Security
·
P1619 - Standard Architecture for Encrypted Shared
Storage Media
·
P2200 - Standard for Baseline Operating
System Security
(Dormant Project
Awaiting Chair and Tech Editor)
2 Definitionen
Im
folgendem Kapitel werden Definitionen von Begriffen, die essentiell für das
Verständnis der im BOSS dargelegten Zusammenhänge sind, aufgeführt.
2.1 Commercial off-the-shelf (COTS)
Als
commercial off-the-shelf (englisch für kommerzielle Produkte aus dem Regal)
oder kurz COTS werden seriengefertigte Produkte aus dem Elektronik- oder Softwaresektor bezeichnet, die in
großer Stückzahl völlig gleichartig aufgebaut verkauft werden. Dies kann
beispielsweise bei Office-Produkten oder Warenwirtschaftssystemen praktiziert werden.
[Wiki COTS]
Unter COTS Produkte fallen auch herkömmliche Betriebssysteme wie Microsoft
Windows oder Linux.
2.2 Common Criteria
(CC)
Unter
common criteria versteht man gemeinsame Kriterien für die Prüfung und Bewertung
der Sicherheit von Informationstechnik. In der Version 2.0 sind sie Ende Mai
1998 unter Beteiligung Deutschlands, Frankreichs, Großbritanniens, Kanadas, der
Niederlande und der USA fertiggestellt worden. Sie sind für die Bewertung der
Sicherheitseigenschaften praktisch aller informationstechnischen Produkte und
Systeme geeignet. Die CC 2.1 sind durch die Internationale
Standardisierungsorganisation (ISO) unter der Nummer 15408 ein internationaler
Standard geworden. Die wenigen nichttechnischen Änderungen, die durch den Standardisierungsprozess
der ISO notwendig geworden sind, wurden in der CC Version 2.1 durchgeführt (aus
[BSI CC]).
Die CC befassen sich mit dem Schutz von Informationen vor nicht-autorisierter
Preisgabe, Modifizierung oder vor Zugangsverlust. Die diesen drei Bedrohungen
zugewiesenen Schutzkategorien werden in der Regel mit Vertraulichkeit,
Integrität und Verfügbarkeit bezeichnet.
Schwerpunkte der CC sind auf die Aktivitäten einer Person zurückzuführende
Bedrohungen von Informationen, unabhängig davon, ob diese Aktivitäten böswillig
sind oder nicht. Die CC gelten jedoch auch für einige nicht auf die Aktivitäten
einer Person zurückzuführende Bedrohungen und sie können auch in anderen
IT-Gebieten Anwendung finden, erheben aber außerhalb des eng umgrenzten Bereichs
der IT-Sicherheit keinen Anspruch auf Kompetenz (aus [Bundesanzeiger]).
Die Common Criteria sind nicht nur Grundlage für die systematische Prüfung
(Evaluation) der Sicherheit von IT, sondern bieten den IT-Herstellern auch
einen Maßstab für die möglichen Sicherheitsmaßnahmen in ihren Produkten (aus
[BSI PP]).
Vielen Anwendern von IT fehlen Wissen, Fachkenntnis oder die nötigen Mittel, um
beurteilen zu können, ob ihr Vertrauen in die Sicherheit ihres IT-Produkts oder
Systems angemessen ist, und sie möchten sich auch nicht allein auf die
Versicherungen des Entwicklers verlassen. Die Anwender können deshalb, um ihr
Vertrauen in die Sicherheitsmaßnahmen zu erhöhen, eine Analyse der Sicherheit
(d.h. eine Sicherheitsevaluation) des IT-Produkts oder Systems in Auftrag geben
(aus [CC Teil 1]).
2.3 Schutzprofile
(Protection Profiles, PPs)
Schutzprofile ermöglichen es,
eine Sicherheitslage anhand von Bedrohungen, Annahmen über die Betriebsumgebung
der IT, Sicherheitszielen usw. zu beschreiben. Ein PP definiert dabei eine
implementierungsunabhängige Menge von IT-Sicherheitsanforderungen. Mit Hilfe
der Anforderungen in den Common Criteria wird dann eine Musterlösung auf
angemessen abstrakter Ebene beschrieben. Diese Musterlösungen werden in Kürze
von der ISO registriert und damit weltweit zur Verfügung stehen. Auf diese
Weise haben Autoren von Schutzprofilen die Möglichkeit, weltweit Standards zu
setzen. Einerseits können Hersteller mit Hilfe von Schutzprofilen Standards für
ihre Produkte schaffen - wie bereits in Deutschland und Frankreich für
Smartcards geschehen - andererseits haben Anwender die Möglichkeit, ihren
Sicherheitsbedarf standardgerecht zu artikulieren. Auch Behörden und
internationale Organisationen, können mit Hilfe von Schutzprofilen ihre
Sicherheitsinteressen und Vorstellungen für bestimmte IT-Anwendungen und
Produkttypen in Form eines standardisierten Sicherheitskonzepts zum Ausdruck
bringen (aus [BSI PP]).
Anhand der Evaluationskriterien aus den Common Criteria wird die Prüfung und
Bewertung von Schutzprofilen durchgeführt, wodurch nachgewiesen werden soll,
dass das Schutzprofil vollständig, konsistent und technisch stimmig ist und für
den Gebrauch in der evaluierten Umgebung geeignet ist. Dabei soll das Schutzprofil
für Benutzer der evaluierten Umgebung klar und verständlich gestaltet werden.
Folgende Tabelle umfasst Schutzprofile, die im
Bereich der Betriebssysteme von den Common Criteria Zertifizierungsstellen
validiert wurden:
|
Profil Name |
Version |
Datum |
Abkürzung |
Sponsor |
|
Multi-Level
Operating Systems in Medium Robustness Environments PP |
01.01.22 |
01.06.01 |
PP_MLOSPP-MR_V1.22 |
NSA |
|
Single-Level
Operating Systems in Medium Robustness Environments PP |
01.01.22 |
01.06.01 |
PP_MLOSPP-MR_V1.22 |
NSA |
|
Controlled
Access PP (Basic Robustness/C2) |
1.d |
01.10.99 |
CAPP_V1.d |
NSA |
|
Labeled
Security PP (Medium Robustness/B1) |
1.b |
01.10.99 |
LSPP_V1.b |
NSA |
Tabelle
2 Protection Profiles validiert für Betriebssysteme [NIAP PP]
2.4 COTS Security Protection Profile (CSPP) [CSPP]
COTS Security Protection Profile (ehemals
CS2 “Commercial Security 2”) ist ein Leitfaden eines Schutzprofils für
Standartanwendungen der nahen Zukunft.
Dabei erhebt CSPP den Anspruch die nötigen
Richtlinien zur Entwicklung von konformen Schutzprofilen bereitszustellen, die
allgemein auf COTS angewendet werden können. Dabei spezifiziert CSPP jedoch
nicht alle erdenklichen Systeme. Um speziellen Anforderungen gerecht zu werden
müssen zum Teil einige Spezifikationen hinzugefügt werden.
Das CSPP beschreibt also weitreichend standpunktsneutrale und theoretische
Systeme in Form eines Schutzprofils. Dabei werden einige Common Criteria
spezifiziert, um die Entwicklung von standardisierten Protection Profiles zu ermöglichen.
Die Schlüsselannahmen der CSPP Schutzprofile lauten:
·
Das CSPP konforme TOE („Target of Evaluation“) umfasst
COTS Informations-Technologie.
·
Authentifizierte
Benutzer haben das Bedürfnis nach einer sicheren IT Umgebung und halten gewissenhaft
die Sicherheitsrichtlinien der Organisation ein.
·
Eine Kompetente
Wartung aller Sichereheitsberiche wird durchgeführt.
·
Die
Geschäftsprozessautomatisierung ist im Hinblick darauf implementiert, was CSPP
konforme Protection Profiles nicht von ihren TOEs erwarten können.
a) Anwendungsbereich
Tabelle 3 gibt Aufschluss über
die Systeme, auf die das COTS Security Protection Profile angewendet werden
kann:
|
Art des Systems |
· sowohl Einzelrechner als auch verteilte Rechner · Single- und Multiuser · Standardbetriebssysteme, Datenbanksysteme und andere Anwendungen |
|
Art des Zugriffs |
· Öffentlicher Zugriff: Der Benutzer hat keine eindeutigen Identifizierungsmerkmale, und wird vor einem Zugriff nicht authentifiziert. · Authentifizierte Benutzer sind vom System bereits vor einem Zugriff eindeutig identifizierbar, und haben über die der Öffentlichkeit zugänglichen Informationen hinaus Zugriff. |
|
Art der Nutzung |
CSPP konforme Schutzprofile sind sowohl für Umgebungen in der Wirtschaft als auch in der Regierung einsetzbar. ·
Staatliche Nutzung: ·
Wirtschaftliche Nutzung: |
Tabelle
3 Anwendugsbereich der CSPP [CSPP]
Durch
den Einsatz von Standardanwendungen werden gleichzeitig deren Vorzüge, wie ein
weitreichender Funktionsumfang bei geringen Kosten, ausgenutzt, jedoch müssen
dabei einige Kompromisse, beispielsweise der geringe Leistungsumfang im Bereich
der Sicherheit, in Kauf genommen werden. Dort setzt das CSPP an, indem
Sicherheitsleitlinien für auf COTS basierende System bereitgestellt werden.
Dabei deckt das CSPP auch jene Bereiche ab, wo es, beispielsweise aus
Kostengründen, nicht realistisch erscheint von einer typischen
Standardanwendung ausreichenden Schutz zu erwarten.
b) Übersicht der CSPP
Anforderungen
Der Evaluierungsgegenstand
(TOE, „Target of Evaluation“) eines Schutzprofils der Common Criteria ist die
IT Komponete oder das System, wofür Anforderungen spezifiziert werden müssen.
Folgende Tabelle gibt Aufschluss über die Anforderung an das zu betrachtende
System:
|
Vertrauenswürdigkeit |
Die Vertrauenswürdigkeitsstufe wurde so gewählt, dass das Sicherheitsniveau aus bestehenden Methoden der COTS Entwicklung erhalten bleibt und keine umfangreiche Evaluierung durch Dritte nötig ist. Sie erweitern die vom TOE ergriffenen Sicherheitsmaßnahmen, welche · ausreichend zur Kontrolle eine Gemeinde von vertrauensvollen authentifizierten Benutzern sind, · so genannte „unsophisticated“ technische Angriffe abwehren, · jedoch keinen ausreichenden Schutz gegen so genannten „sophisticated“, technischen Angriffen bieten können. |
|
Anforderungen („Functionality“) |
Das fiktive CSPP System befriedigt folgende Sicherheitsanforderungen an ein verteiltes System in einer unsicheren Netzwerkumgebung: · Eine Zugriffskontroll-Strategie zwischen aktiven Einheiten („Subjekten“) und passiven Objekten, die auf deren Identität erlaubte Handlungen und Einschränkungen der Betriebsumgebung (wie beispielsweise „time-of-day“ und „port-of-entry“) basiert. · Kontrolle des Informationsfluss auf der Makroebene (zwischen Domänen). · Resistenz gegen Überlastung der Ressourcen durch eine Ressourcen- Verteilungsstrategie. · Methoden zur Erkennung von Sicherheitslücken. · Mechanismen zur zuverlässigen Systemwiederherstellung im Falle eines Systemversagens oder Festellens einer Sicherheitslücken. |
|
Abgrenzungskriterien („What
the TOE need not to require“) |
CSPP konforme Protection Profiles dürfen vom TOE nicht erwarten, dass es · so genannte „label-based controls“ zu Verfügung stellt (wie z.B. als staatlich oder als Firmeneigentum gekennzeichnete Daten), · adequaten Schutz vor Missbrauch von authorisierten Rechten und „ sophisticated“ Angriffen (mit Zugiffsverweigerung) bietet und · ausreichend Schutz vor Installation-, Anwender- und Administrationsfehlern gewährleistet. |
Tabelle
4 Anforderungen der CSPP [CSPP]
3 Standard for Baseline Operating Systems Security (BOSS)
In diesem Kapitel werden die
globalen Zusammenhänge der einzelnen Organisationen und Begrifflichkeiten
illustriert, die auf den „Standard for Baseline Operating Systems Security“
einwirken.
3.1
Entstehungsgeschichte
Am
12. Juni wurde durch eine E-Mail von Jodi Haasz, Senior Administrator IEEE-SA
Governance and Electronic Processes, an Curtis Anderson das Projekt „P2200 - Standard for Baseline
Operating Systems Security (TM) (BOSS TM)“ bis 31. Dezember 2007 genehmigt
[BOSS INIT]. Dieses Projekt basiert auf die CC, die im NIST IR 6462 [CSPP]
spezifiziert wurden. Als Basisdokument dienen der Arbeitsgruppe der NIST IR
6985: „COTS Security Protection Profile - Operating Systems (CSPP-OS) (Worked
Example Applying Guidance of NISTIR-6462, CSPP)“ vom April 2003 [CSPP-OS].
Am 21. Oktober schrieb der Projektleiter John Cole
folgende E-Mail [BOSS MAIL]:
Date: Thu, 21 Oct 2004
10:48:03 -0400
Sender: Baseline Operating
System Security <BOSS@COMPUTER.ORG>
From: "Cole, John (Civ,
ARL/CISD)" <cole@ARL.ARMY.MIL>
Subject: Suspension of
Activities
All, Because I am
unable to spend time as chair of the Baseline Operating System Security working
group, and because we have lost participation by NIST as a proponent,
activities for this group are suspended for several months waiting to see if
others are interested in taking over the roles of working group chair and
technical editor. If by the end of January 2005 no one does, then as sponsor of
the working group, I will request that the project be withdrawn from IEEE. We
have had great discussions, great participants, and the list of those
interested numbers around 150. But the problem with volunteer activities is
that volunteers have real jobs with time demands that are sometimes inelastic,
and changing support from the organizations sponsoring the volunteers. If any
of you are interested in serving in these roles (working group chair, technical
editor) for the BOSS WG, send me email or call before February 2005. Thanks Jack
Woraufhin
schließlich im „IEEE Report of Recent Activities“ hingewiesen wurde, dass das
Projekt P2200 „Standard for Baseline Operating System Security“ aufgrund einer
Vakanz seitens der Führungsposition sowie des technischen Bearbeiters bis auf
weiteres auf Eis gelegt wurde [IEEE ACT].
3.2 Zielsetzung
BOSS soll als Leitfaden für Sicherheitsanforderungen
an kommerzielle COTS Betriebssysteme dienen, und dabei sinnvolle
Sicherheitsanforderungen zur Verfügung stellen. Augenmerk liegt auf die
Formulierung eines Leitfadens, der für das breite Publikum verständlich und
klar ist. Überdies soll er Anwendern sowie der Industrie gleichermaßen
Eingriffsmöglichkeiten in Sicherheit-Standards für Betriebssysteme bieten,
indem das Thema, nicht wie bisher ausschließlich vom Staat, sondern auch von
der Öffentlichkeit erörtert wird.
Da sich die Zielsetzung von BOSS mit
den Zielvorstellungen der Schutzprofile der Common Criteria deckt, wurde als
Basis für den Standard das CSPP-OS, auf
das im nächsten Kapitel eingegangen wird,
gewählt.
3.3 Übersichtsgrafik
Den
Zusammenhang der einzelnen Einrichtungen und ihr Zusammenwirken soll die
folgende Grafik verdeutlichen:
Zeichnung 1 Übersicht
der globalen Zusammenhänge
Da BOSS auf CSPP-OS aufbaut wird im Folgendem
detailliert auf jenes eingegangen.
4 COTS Security Protection Profile - Operating Systems (CSPP-OS) [CSPP-OS]
4.1 Motivation
Ziel des „COTS Security
Protection Profile - Operating Systems“ ist es in Form eines Schutzprofils ein
ausgearbeitetes Beispiel der im NIST IR 6462 „COTS Security Profile“ [CSPP]
vorgestellten Protection Profiles der Common Criteria für COTS Informationstechnologie
zu liefern.
In diesem Schutzprofil werden Anforderungen definiert und spezifiziert, die man
braucht um die Sicherheitsprobleme, von denen ausgegangen werden kann, dass
COTS Betriebssysteme (mit etwaigen Add-On-Paketen) in naher Zukunft konfrontiert
werden, zu lösen.
Die Zielgruppe des CSPP-OS besteht aus Unternehmern und Organisationen, aus dem
staatlichen und dem privaten Sektor, die mit der Verantwortung betraut wurden
Schutzprofile zu entwickeln oder überarbeiten (wie beispielsweise das P2200 BOSS).
Da es sich bei CSPP-OS um ein angewandtes Beispiel des im [CSPP] formulierten
Schutzprofils handelt, gelten die im Kapitel 2.4 gemachten Aussagen auch für
das CSPP-OS.
4.2
Evaluationsgegenstand (TOE)
Die TOEs werden durch
Produktklasse, Arbeitsumgebung und geforderte Sicherheitsfunktionen
eingegrenzt.
a) Produktklasse
Vom CSPP-OS werden
Standard-Betriebsysteme sowohl im Einzelbetrieb als auch in Netzwerkumgebungen
berücksichtigt, welche mit einem oder mehreren Prozessoren betrieben werden,
die zusammen mit der angeschlossenen Peripherie von mehreren Benutzern genutzt
werden können.
Die gemeinsamen Freigaben auf Daten und Ressourcen müssen gesteuert und
kontrolliert werden. Das TOE soll dem Anwender direkt Dienste zur Verfügung
stellen oder als Plattform verteilter Anwendungen dienen, wobei eine sichere
Kommunikation über ein ungesichertes Netz gewährleistet werden muss. Dabei kann
das TOE ein Standard-Betriebssystem mit Add-On-Paketen sein, welche die
Grundfunktionen erweitern.
b) Arbeitsumgebung
Die Arbeitsumgebung des
Betriebssystems (TOE) besteht aus Computersystemen auf denen jenes ausgeführt
wird und weitere Systeme, die mit ihm verbunden sind.
Der menschliche Benutzer ist in Verbindung mit dem von ihm gestarteten
Systemprozessen verantwortlich für jegliche Systemaktivität. Das Betriebssystem
muss Prozesse erzeugen, die entweder einem eindeutigen Benutzer zugeordnet
werden können oder einem eindeutig identifizierbaren Systemprozess.
In einer Netzwerkumgebung muss die Möglichkeit bestehen, dass ein Prozess einen
weiteren auf einem anderen Computersystem aufrufen kann.
c) Geforderte
Sicherheitsfunktionen
Folgende Auflistung beinhaltet
spezifische Sicherheitsanforderungen an ein CSPP-OS konformes Betriebssystem:
·
Einhaltung der
von den IT Sicherheitsrichtlinen verhängten Zugriffskontrollstrategie
·
Zuweisung eines
einzigartigen und eindeutigen Identifikator sowohl an jeden authentifizierten
Benutzer als auch an alle Systemprozesse (einschließlich derer, die nicht von
einem Benutzer gestartet wurden)
·
Zugriffserteilung
nur durch die geforderte Authentifizierung
·
Definition einer
Menge von Operationen für (noch) nicht authentifizierte Benutzer
·
Revision durch
individuelle Rechenschaftsablage und sowohl Aufspüren von als auch Reagieren
auf Sicherheitslücken
·
Möglichkeit des Zugriffsberechtigungs-Management
·
Gegen
Ressourcen-Überlastung resistente Ressourcen-Verwaltungsmöglichkeiten
·
Systemwiederherstellungs-Fähigkeiten zur Überlebensfähigkeit von
Systemfehlern und Sicherheitslücken
·
Automatische
Unterstützung zur Verifizierung von sicherem Datenverkehr, Insallation,
Arbeitsverrichtung und Administration
4.3 Die
Sicherheitsumgebung
Im Folgenden wird näher auf das
CSPP-OS konforme Betriebssystem eingegangen. Zuerst speziell auf dessen Arbeitsumgebung,
im weiteren Verlauf wird aufgeführt für welche organisationsinterne
Sicherheitsrichtlinien CSPP-OS geeignet sind. Überdies wird kurz auf die IT
bezogene Anforderungen an die Organisation im Bezug auf das fiktive IT-System,
in dem das CSPP konforme Betriebssystem eingesetzt wird, eingegangen.
Schließlich werden bewusst in Kauf genommene Sicherheitsrisiken behandelt und
abschließend eine allgemeine Beschreibung der Vertrauenswürdigkeit gegeben.
a) Arbeitsumgebung
Annahmen im Bezug auf das TOE:
Das TOE ist ein System, das auf COTS der nahen Zukunft basiert, wobei von ihm
nicht verlangt wird, ausreichenden Schutz vor Missbrauch von autorisierten
Benutzer-Rechten zu bieten. „Label-based“ Kontrollelemente enthält müssen nicht
enthalten sein, da es unwahrscheinlich ist, dass diese in der nahen Zukunft in
COTS integriert werden. Schließlich wird aus selbigem Grunde nicht vom TOE
verlangt, dass es sich ausreichend gegen technische durchdachte
(„sophisticated“) Angriffe zu Wehr setzten kann.
Annahmen im Bezug auf das
Personal:
Die Administration findet auf einer kompletten „on-going“ Basis statt.
Authentifizierte Benutzer haben das Bedürfnis nach einer sicheren IT Umgebung
und halten gewissenhaft die Sicherheitsrichtlinien der Organisation ein.
b) Organisationsinterne
Sicherheitsrichtlinien
Die internen
Sicherheitsbestimmungen beschreiben Anforderungen an die Umgebung, wie
beispielsweise eine Abstimmung der eingesetzten Informationstechnologie mit den
gängigen Gesetzen und Regulierungen, sowie Informationsfluss-Bestimmungen.
Zudem wird eine verantwortungsvolle Benutzerbasis vorausgesetzt, die es
ermöglicht jeden Anwender für seine Taten zur Verantwortung zu ziehen und die
Annahme zulässt, dass alle Benutzer auf die eingesetzte IT geschult wurden und
diese nur im Rahmen der autorisierten Benutzungsrichtlinien verwenden.
c) Maßnahmen des TOE
zum Abwehren von Angriffen und Beseitigen von Sicherheitslücken
Technische Gegenmaßnahmen von
Systemen der zukünftigen COTS-Generation gegen Angriffe müssen ergriffen werden.
Jene
werden in zwei Kategorien eingeteilt:
·
„unsophisticated“
und böswillige Angriffe, die nicht von authentifizierten Benutzern stammen,
·
Angriffe von
authentifizierten Benutzern, die ohne böse Absichten versuchen sich
unautorisiert Zugriff zu verschaffen oder nicht autorisierte Operationen
durchzuführen.
Alle
anderen Bedrohungen der Systemsicherheit müssen durch die Kontrollen seitens
der Arbeitsumgebung abgefangen werden, beziehungsweise als Sicherheitsrisiken
in Kauf genommen werden.
Im folgendem Abschnitt, der die
Sicherheitsrisiken behandelt, wird zwischen technischen und nicht-technischen
Mitteln des Eindringens unterschieden. Unter technischen Mitteln versteht man
durch Informationstechnologie implementierte Maßnahmen, die zum Zweck haben,
die Zugriffskontrollmaßnahmen des Betriebssystems zu umgehen (beispielsweise
eine absichtliche Verursachung eines Pufferüberlaufs). Nicht-technische Mittel
sind jene, die sich nicht im Verantwortungsbereich der eingesetzten IT-Umgebung
befinden (zum Beispiel verschlossene Büroräume oder bewachte Gebäude).
|
ACCESS-TOE: Ein
authentifizierte Benutzer kann sich unautorisiert Zugang zu einer Ressource
oder Information verschaffen, die nicht vom TOE via Benutzerfehler,
Systemfehler oder einem „unsophisticated“ technischen Angriff abgefangen
wird. Durch die alleinige Freigabe von
öffentlichen und authentifizierten Zugängen auf Ressourcen und Handlungen für
die sie autorisiert wurden kann dies erreicht werden (O.ACCESS-TOE). Überdies muss das TOE die Möglichkeit
zur Verfügung stellen Zugriffsrechte für Benutzer- und Systemprozesse zu
spezifizieren und zu verwalten (O.AUTHORIZE-TOE). Um auf nicht-böswillige autorisierte Software oder Benutzer, die durch das Umgehen oder Aushebeln der Sicherheitsrichtlinien Zugang erhalten haben, zu reagieren muss das TOE diese verhindern (O.BYPASS-TOE). |
|
|
AUDIT-CONFIDENTIALITY-TOE: Die Wahrnehmung von sicherheitsrelevanten Ereignissen im
Zuständigkeitsbereich des TOE kann durch unautorisierte Individuen oder
Prozesse umgangen werden. |
Das TOE muss für Aktionen in seinem Kontroll- beziehungsweise Wissensbereich gewährleisten, dass alle Benutzer schrittweise für ihre sicherheitsrelevanten Handlungen ermittelbar sind. Dies wird durch eine „moderate effectiveness“ erreicht, mit dem Wissen dass es aus gewissen Gründen nicht möglich ist bestimmte Handlungen zuzuordnen (O.ACCOUNT-TOE). |
|
AUDIT-CORRUPTED-TOE: Einträge von sicherheitsrelevanten Ereignissen unter der Kontrolle des TOE können durch Unautorisierte verändert oder zerstört werden. |
|
|
TRACEABLE-TOE: Aufgrund des Betriebssystems kann es möglich sein, dass sicherheitsrelevante Ereignisse nicht bis zu einem Benutzer- oder Systemprozess verfolgt werden können. |
|
|
|
|
|
DENIAL-TOE: Das TOE kann Ziel
einer „unsophisticated denial-of-service“ Attacke werden, deshalb muss es dem
TOE möglich sein dieser zu trotzen. Das TOE muss sich selbst vor „unsophisticated denial-of-service“ Attacken schützen (O.AVAILABLE-TOE). |
|
|
ENTRY-TOE: Durch eine
„unsophisticated“ technische Attacke kann dieselbe Person Zugriff auf vom TOE
bewachte Ressourcen oder Informationen erhalten. Diese Art des Eindringens muss durch das TOE verhindert werden (O.ENTRY-TOE). |
|
|
RESOURCES: Die freigegebenen internen Ressourcen können aufgrund eines Systemfehlers oder unbeabsichtigten Benutzereingaben überlastet werden. Das TOE muss sich gegen derartige Fehler schützen können (O.RESOURCES). |
|
|
OBSERVE-TOE: Spezifikations-, Design- oder Implementierungsfehler können kompetente Benutzer oder Sicherheitsadministratoren fälschlicherweise im Glauben lassen, dass das TOE, trotz des Auftretens von Ereignissen, die auf Unsicherheiten schließen ließen, immer noch sicher sei. Durch eine Kombination von Vorsorge- und Erkennungsmaßnahmen, die die möglicherweise sehr Umfangreiche Anzahl an möglichen Fehlzuständen einzugrenzen versuchen, kann dem entgegengewirkt werden (O.OBSERVE-TOE). |
|
|
CRASH-TOE: Der
Sicherheitsstatus des TOE kann durch einen Systemabsturz kompromittiert werden.
Um die von ihm kontrollierten Informationen zu beherrschen, muss das TOE in
einem sicheren Zustand verbleiben. Beim Erkennen eines Systemfehlers, einer Diskontinuität des Dienstes oder einer Sicherheitslücke muss das TOE die Möglichkeit zur Rückkehr zu einem sicheren Zustand zur Verfügung stellen (O.RECOVER-TOE). |
|
|
TOE-CORRUPTED: Der Sicherheitszustand eines TOEs könnte als Resultat einer geringstufigen Attacke absichtlich korrumpiert worden sein, um zukünftiges Eindringen zu ermöglichen. Diese speziellen Sicherheitslücken muss das TOE erkennen (O.DETECT-TOE). |
|
RECORD-EVENT-TOE:
Sicherheitsrelevante Ereignisse des TOEs, die geloggt werden sollten,
werde nicht erfasst.Tabelle
5 Bedrohungen und Sicherheitsziele TOE [CSPP-OS]
d) Auftreten von
Sicherheitsrisiken außerhalb des Wirkungsbereichs des TOE und deren
Beseitigung
Die
im Folgendem aufgeführten Bedrohungen und Sicherheitsziele („Objectives“)
befinden sich nicht im Aufgabenbereich des TOE und müssen deshalb von der
Arbeitsumgebung abgefangen werden:
|
ACCESS-NON-TECHNICAL: Wie
im vorhergehenden Abschnitt bereits angedeutet kann sich ein
authentifizierter Benutzer ungenehmigten Zugang verschaffen. Durch Sicherheitspersonal und Benutzerschulung kann dem entgegengewirkt werden (O.ACCESS-NON-TECHNICAL). |
|
PHYSICAL: Sicherheitskritische Bereiche des System können physikalischen Attacken ausgesetzt werden. Durch eine effektive Prävention kann dies verhindert werden (O.PHYSICAL). |
|
DENIAL-Non-TOE: Das
System kann Ziel einer „sophisticated
denial-of-service“ Attacke werden. Da nicht von COTS der nahen Zukunft
erwartet wird diesen zu widerstehen, müssen diese Systeme auf den Schutz
durch die nicht-IT Umgebung vertrauen. Dies wird durch eine Kombination von Prevention, Früherkennung und Wiederherstellung erreicht (O.AVAILABLE-Non-TOE). |
|
DENIAL-SOPHISTICATED: Die
nicht zum TOE gehörende IT kann Ziel einer „unsophisticated
denial-of-service“ Attacke werden, derer sie zu widerstehen vermögen soll. Die Umgebung muss Möglichkeiten liefern diese und deren Folgen zu erkennen. Die Art der Reaktion geschieht mit einer „moderate effectiveness“ (O.DENIAL-SOPHISTICATED). |
|
ACCESS-Non-TOE: Ein
authentifizierte Benutzer kann sich unautorisiert Zugang zu einer Ressource
oder Information verschaffen, die nicht vom TOE via Benutzerfehler, Systemfehler
oder einem „unsophisticated“ technischen Angriff abgefangen wird. Durch die alleinige Freigabe von
öffentlichen und authentifizierten Zugriffen auf Ressourcen und Handlungen
für die sie autorisiert wurden, kann dies erreicht werden (O.ACCESS-Non-TOE). Überdies muss die IT die
Möglichkeit zur Verfügung stellen Zugriffsrechte für Benutzer- und
Systemprozesse zu spezifizieren und zu verwalten (O.AUTHORIZE-Non-TOE). Um den Zugang von „non-malicious“ autorisierter Software oder Benutzern, die durch das Umgehen oder Aushebeln der Sicherheitsrichtlinien eindringen konnten, zu unterbinden, muss die IT Umgebung diese verhindern (O.BYPASS-Non-TOE). |
|
|
AUDIT-CONFIDENTIALITY-Non-TOE:
Die Wahrnehmung von sicherheitsrelevanten
Ereignissen außerhalb des Zuständigkeitsbereichs des TOE kann durch
unautorisierte Individuen oder Prozesse umgangen werden. |
Daher muss die IT außerhalb des TOE der Öffentlichkeit und authentifizierten Benutzern Zugriff auf Ressourcen und Handlungen, für welche sie autorisiert wurden, erteilen. Außerdem muss diese IT sicherstellen, dass alle Benutzer für ihre sicherheitsrelevanten Aktionen verantwortlich gemacht werden können (O.ACCOUNT-Non-TOE). |
|
AUDIT-CORRUPTED-Non-TOE: Einträge von sicherheitsrelevanten Ereignissen außerhalb des Zuständigkeitsbereichs des TOE können möglicherweise durch Unautorisierte verändert oder zerstört werden. |
|
|
RECORD-EVENT-Non-TOE: Sicherheitsrelevante Ereignisse die außerhalb des TOEs geloggt werden sollten werde nicht erfasst. |
|
|
TRACEABLE-Non-TOE: Aufgrund der Informationssysteme außerhalb des TOE kann es möglich sein, dass sicherheitsrelevante Ereignisse nicht bis zu einem Benutzer- oder Systemprozess verfolgt werden können. |
|
|
ENTRY-NON-TECHNICAL: Durch nichttechnische Mittel kann sich eine nicht authentifizierter Benutzer Zugang zu Ressourcen oder Informationen verschaffen. Dies muss von der IT Umgebung verhindert werden; das Bewusstsein dieser Gefahr und Anwenderschulungen reichen großteils zur Erfüllung dieser Direktive aus (O.ENTRY-NON-TECHNICAL). |
|
|
ENTRY-Non-TOE: Durch
eine „unsophisticated“ technische Attacke kann dieselbe Person Zugriff auf Ressourcen oder
Informationen erhalten die nicht vom TOE überwacht werden. Das Bewusstsein dieser Gefahr und Anwenderschulungen reichen Großteils zur Erfüllung dieser Direktive aus (O.ENTRY-Non-TOE). |
|
|
ENTRY-SOPHISTICATED: Dieselbe Person kann sich durch
eine „sophisticated“ technische Attacke
Zugriff auf Informationen und Ressourcen verschaffen. Da sich das COTS System
erwartungsgemäß nicht gegen diese Angriffe wehren kann muss die
Arbeitsumgebung diesen Schutz gewährleisten. Die TOE Umgebung muss Möglichkeiten liefern diese und deren Folgen zu erkennen. Die Art der Reaktion geschieht mit einer „moderate effectiveness“ (O.ENTRY-SOPHISTICATED). |
|
|
OBSERVE-Non-TOE: Spezifikations-, Design- oder Implementierungsfehler können kompetente Benutzer oder Sicherheitsadministratoren fälschlicherweise im Glauben lassen, dass das System, trotz des Auftretens von Ereignissen, die auf Unsicherheiten schließen ließen, immer noch sicher sei. Durch eine Kombination von Vorsorge- und Erkennungmaßnahmen, die die möglicherweise sehr Umfangreiche Anzahl an möglichen Fehlzuständen einzugrenzen versuchen, wird dem entgegengewirkt (O.OBSERVE-Non-TOE). |
|
Tabelle
6 Bedrohungen und Sicherheitsziele nicht TOE [CSPP-OS]
e) Bereiche in denen
sowohl TOE als auch dessen Umgebung Sicherheitsverantwortung tragen
Im Folgendem
werden Bereiche aufgeführt in denen zum einen keine Abgrenzung der
Aufgabenbereiche möglich ist oder zum anderen beide gleichermaßen an der
Erfüllung der Sicherheitsrichtlinen beitragen:
Um böswilliges Eindringen in unautorisierte Bereiche durch authentifizierte
Benutzer zu verhindern sind die TOE Kontrollen allein nicht ausreichend. Zusätzliche
Umgebungskontrollen sind notwendig.
Im weiteren sind das gemeinsame Auffinden von Sicherheitslücken, die
Implementierung und Wartung beider Systeme unter Einhaltung und Beibehaltung
der IT Sicherheit von Nöten.
Überdies muss in beiden Systemen gewährleistet sein, dass beiden Systeme sowohl
geltende Gesetze wie Regulierungen einhalten.
Schließlich muss eine Überlastung geteilter Ressourcen verhindert werden, und
die Möglichkeit bei einem Systemausfall oder dem Feststellen von
Sicherheitslücken des Wiederherstellens eines sicheren Systemstatus gegeben
sein.
f) Anforderung an die
Vertrauenswürdigkeit („assurances“)
Da CSPP-OS
eine Definition von in naher Zukunft erreichbarer und mit geringen
Evaluierungskosten verbundener COTS Sicherheit darstellt decken sich die
Anforderungen an die Vertrauenswürdigkeit mit den gängigen in der Praxis
bewährten Entwicklungsmethoden und beinhalten nur einen minimalen Anteil an
Analyse durch Dritte. Grund dafür ist, dass aktuelle COTS Entwicklungsstandards
kein „Security Engineering“ im geeigneten Maße umfassen. Ein Vorschreiben
dieser Techniken hätte zur Folge, dass Entwicklungsmethoden und
Personalfertigkeiten komplett überarbeitet werden müssen. Da dies nicht möglich
bzw. als unwahrscheinlich gilt wurde das CSPP-OS mit diesem Vorbehalt
entwickelt.
4.4 Funktionale
Sicherheitsanforderungen
In
diesem Abschnitt werden exemplarisch funktionale Anforderungen der CSPP-OS
Spezifikation entnommen um jene zu illustrieren.
a) An das Betriebssystem
(TOE)
Die funktionalen Anforderungen bestehen aus teilweisen
erweiterten, verfeinerten oder durch die Sicherheitsvorgaben vertiefende
Komponenten der Common Criteria.
Die im Schutzprofil spezifizierten Vorgaben müssen strikt vom Betriebssystem
eingehalten werden. Aufgrund der Komplexität und des Umfangs der funktionalen
Anforderungen wird exemplarisch ein Beispiel durchgearbeitet; dies kann auf
alle weiteren Anforderungen angewendet werden.
|
Req Number |
CC Component |
Name |
Extended |
Refined |
ST adds detail |
Objectives function helps address |
|
30 |
FIA_USB.1-NIAP-0415 |
User-Subject Binding |
|
|
|
o.access-TOE |
Tabelle
7 Funktionale Anforderungen an das TOE [CSPP-OS]
Die
Tabelle „Funktionale Anforderungen“ ist direkt aus dem Kapitel 5.1 des
Schutzprofils CSPP-OS entnommen. Sie enthält eine fortlaufende
Anforderungsnummer, gefolgt von der Common Criteria Komponente, auf die Bezug
genommen wird, dem Namen der Anforderung und den eventuell durchgeführten
Modifikationen. In der letzten Spalte werden die Sicherheitsziele, die durch
die Funktion abgedeckt werden aufgeführt.
Der folgende Abschnitt ist ein Auszug aus Teil zwei der Common Criteria
„Funktionale Sicherheitsanforderungen“[CC Teil 2], der die Komponente FIA_USB.1-NIAP-0415
beschreibt:
|
Benutzer-Subjekt-Bindung (FIA_USB) |
7 - Klasse FIA: Identifikation und Authentisierung |
7.6 Benutzer-Subjekt-Bindung
(FIA_USB)
Familienverhalten
Ein authentisierter Benutzer
aktiviert in der Regel ein Subjekt, um den TOE (EVG) zu benutzen. Die
Benutzersicherheitsattribute sind (vollständig oder teilweise) mit dem Subjekt
verknüpft. Diese Familie definiert Anforderungen zur Erzeugung und Erhaltung
der Verknüpfung der Benutzersicherheitsattribute mit dem Subjekt, das für den
Benutzer handelt.
Komponentenabstufung
FIA_USB.1
Benutzer-Subjekt-Bindung erfordert die Erhaltung der Verknüpfung zwischen den
Sicherheitsattributen des Benutzers und einem Subjekt, das für den Benutzer
handelt.
Management: FIA_USB.1
Folgende Aktionen kommen für
die Managementfunktionen in FMT in Betracht:
a)
Ein autorisierter Systemverwalter kann Standardvorgaben für
Subjektsicherheitsattribute definieren.
Protokollierung: FIA_USB.1
Folgende Aktionen sollen
protokollierbar sein, wenn FAU_GEN Generierung der Sicherheitsprotokolldaten
Bestandteil des PP/der ST ist:
a) Minimal: Mißlungene Bindung von Benutzersicherheitsattributen an ein Subjekt (zum Beispiel Erzeugung eines Subjekts).
b) Einfach: Erfolgreiche oder mißlungene Bindung von Benutzersicherheitsattributen an ein Subjekt (zum Beispiel Erfolg oder Mißerfolg bei Erzeugung eines Subjekts).
FIA_USB.1
Benutzer-Subjekt-Bindung
Ist hierarchisch zu: Keinen
anderen Komponenten.
FIA_USB.1.1
Die TSF müssen die angemessenen Benutzersicherheitsattribute mit den Subjekten
verknüpfen, die für die Benutzer handeln.
Tabelle
8 Auszug aus dem zweiten Teil der CC: FIA_USB.1-NIAP-0415 [CC Teil 2]
Alle weiteren
Sicherheitsanforderungen sind dem Schutzprofil CSPP-OS [CSPP-OS] zu entnehmen.
b) An die IT Umgebung
Ähnlich
der Sicherheitsanforderungen das TOE gestellt werden, wird auf die
Anforderungen an IT Umgebung eingegangen. Im Falle des Betriebssystems machen
die Hard- und Firmware die IT Umgebung, auf dem das TOE ausgeführt wird, aus.
Parallel zum vorangehenden Punkt wird hier exemplarisch auf eine
Sicherheitsanforderung eingegangen.
|
Req Number |
CC Component |
Name |
Objectives function helps address |
|
9 |
FDP_ACC.1 |
Subset Access Control |
o.access-non-toe |
Tabelle
9 Funktionale Anforderungen an die IT Umgebung [CSPP-OS]
Die
die Anforderungsnummer nimmt Bezug auf die Anforderungen an das TOE. Etwaige
Modifikation wurden daher bereits im vorherigen Abschnitt abgedeckt.
Zur Verdeutlichung der Komponente „Subset Access Control“ folgt der Auszug aus
den Common Criteria [CC Teil 2]:
|
6 - Klasse FDP: Schutz der Benutzerdaten |
Zugriffskontrollpolitik (FDP_ACC) |
6.1 Zugriffskontrollpolitik (FDP_ACC)
Familienverhalten
Diese
Familie identifiziert SFPs für Zugriffskontrolle (durch den Namen) und
definiert den Anwendungsbereich der Kontrolle der Politiken, die den
identifizierten Teil der Zugriffskontrolle der TSP bilden. Dieser
Anwendungsbereich der Kontrolle wird durch drei Mengen charakterisiert: die
Subjekte unter Kontrollpolitik, die Objekte unter Kontrollpolitik und die
Operationen zwischen kontrollierten Subjekten und kontrollierten Objekten, die
durch die Politik abgedeckt sind. Die Kriterien erlauben die Existenz von
mehrfachen Politiken, von denen jede einen eindeutigen Namen hat. Dies wird
durch einmalige Iteration von Komponenten dieser Familie für jede genannte
Zugriffskontrollpolitik erreicht. Die Regeln, welche die Funktionalität einer
SFP für Zugriffskontrolle festlegen, werden durch andere Familien wie FDP_ACF
und FDP_SDI definiert. Die Namen der hier in FDP_ACC identifizierten SFPs für
die Zugriffskontrolle werden in allen übrigen funktionalen Komponenten mit
einer Operation, die nach einer Zuweisung oder Auswahl von SFP für
Zugriffskontrolle verlangt, verwendet.
Komponentenabstufung
FDP_ACC.1 Teilweise
Zugriffskontrolle erfordert, daß jede identifizierte SFP für Zugriffskontrolle
für eine Teilmenge der möglichen Operationen mit einer Teilmenge der Objekte
eines TOE (EVG) angewendet wird.
FDP_ACC.2 Vollständige
Zugriffskontrolle erfordert, daß jede identifizierte SFP für Zugriffskontrolle
alle Operationen mit Subjekten und Objekten abdeckt, die durch diese SFP erfaßt
sind. Weiter ist es erforderlich, daß alle Objekte und Operationen mit dem TSC
durch mindestens eine identifizierte SFP für Zugriffskontrolle abgedeckt sind.
Management: FDP_ACC.1,
FDP_ACC.2
Für diese Komponente sind keine
Management-Aktivitäten vorgesehen.
Protokollierung: FDP_ACC.1,
FDP_ACC.2
Es sind keine Ereignisse
identifiziert, die protokollierbar sein sollen, wenn FAU_GEN Generierung der
Sicherheitsprotokolldaten Bestandteil des PP/der ST ist.
FDP_ACC.1 Teilweise
Zugriffskontrolle
Ist
hierarchisch zu: Keinen anderen Komponenten.
FDP_ACC.1.1
Die TSF müssen die [Zuweisung: SFP für Zugriffskontrolle] für [Zuweisung:
Liste der Subjekte, Objekte und der durch die SFP abgedeckten Operationen
zwischen Subjekten und Objekten] durchsetzen.
Tabelle
10 Auszug aus dem zweiten Teil der CC: FDP_ACC.1 [CC Teil 2]
c) An die Nicht-IT
Umgebung
Dieses
Schutzprofil umfasst nicht alle Anforderungen an die Nicht-IT Umgebung im
Detail. Die Aussagen der Sicherheitsziele werden jedoch als ausreichend
angesehen, der Nicht-IT Umgebung Rückhalt zu geben.
Folgende Ziele müssen fast ausschließlich von Kontrollen der Nicht-IT Umgebung
abgedeckt werden:
O.ACCESS-NON-TECHNICAL, O.DENIAL-SOPHISTICATED, O.DETECT-SOPHISTICATED,
O.ENTRY-NON-TECHNICAL, O.ENTRY-SOPHISTICATED und O.PHYSICAL.
Die Ziele O.ACCESS-MALICIOUS, O.COMPLY,
O.DUE-CARE, O.MANAGE und O.OPERATE werden ausreichend durch Kontrollen der Nicht-IT
Umgebung abgedeckt.
5 Fazit
Sicherheit spielt heute bereits
eine entscheidende Rolle in vielen Bereichen. Dadurch, dass Netzwerke heute wie
morgen einen sehr großen Platz in unserer Umgebung einnehmen, wächst das
Bedürfnis an Sicherheit. Sowohl staatliche Einrichtungen als auch Unternehmen
sowie private Haushalte sind virtuell vernetzt. Viele Informationen werden über
gesicherte wie ungesicherte Netze ausgetauscht. Zudem sehen wir uns in Zukunft
vermehrt mit vernetzter Informationstechnologie im alltäglichen Leben
konfrontiert. Die Telekom stellte auf der CeBit 2005 ein gänzlich vernetztes
Haus vor, bei welchem fast alle Bereiche des Haushalts direkt mit dem Internet
verbunden sind. Durch den Anschluss an die Außenwelt vergrößert sich die
Gefahr, dass persönliche Daten wie Ressourcen Ziele eines Angriffs werden
beziehungsweise von Benutzern genutzt werden, die keinen Zugriff auf jene
erhalten sollten.
Internationale Standards wie die Common Criteria sind für die Wirtschaft von
großer Bedeutung, weil sie den globalen Markt sicherstellen. Auch Verbraucher
profitieren von der weltweiten Normung, weil die Vereinheitlichung von
Produkten die Vergleichbarkeit verbessert. Normen im Bereich der
Informationstechnik sind besonders nützlich, weil der Computermarkt seit jeher
ein Weltmarkt ist.
Durch das Andenken von Sicherheitskonzepten bereits auf der
Betriebssystemschicht, ist es möglich viele Gefahren bereits auf dieser Ebene
abzuwehren. Da vielen Anwendern jedoch technische Verständnis fehlt, diese
Gefahr einzuschätzen, ist eine Zertifizierungsstelle sehr hilfreich.
Durch zertifizierte Betriebssysteme können sich Anwender mit Hilfe durchdachter
Zertifikate und Standards einen Überblick verschaffen, in welchem Umfang das
eingesetzte Betriebssystem Schutz bietet. Zudem weisen die Schutzprofile direkt
auf Schwachstellen hin und geben den Entwicklern die Möglichkeit
Sicherheitslücken ihres Systems zu entfernen, um die Norm einzuhalten. Die
Einbeziehung der Betriebsumgebung garantiert ein genau definiertes Sicherheitsniveau.
In kommenden Generationen von Betriebssystemen kann auf die Schutzprofile Bezug
genommen werden und dadurch Standards wie BOSS geschaffen werden, die dem
Anwender wie dem Entwickler verständlich sind.
6 Anhang
6.1
Abkürzungsverzeichnis
CC Common Criteria - Gemeinsame
Kriterien
COTS commercial off-the-shelf - Standardanwendungen
EAL Evaluation Assurance Level - Vertrauenswürdigkeitsstufe
IEEE Institute of Electrical and Electronics Engineers
IT Information Technology - Informationstechnik
NIST National Institute of Standards and Technology
PP Protection Profile -
Schutzprofil
SF Security Function -
Sicherheitsfunktion
SFP Security Function Policy -
funktionale Sicherheitspolitik
SOF Strength of Function -
Stärke der Funktionen
ST Security Target - Sicherheitsvorgaben
TOE (EVG) Target of Evaluation - Evaluationsgegenstand
TSC TSF Scope of Control -
Anwendungsbereich der TSF-Kontrolle
TSF TOE Security Functions -
EVG-Sicherheitsfunktionen
TSFI TSF Interface -
TSF-Schnittstelle
TSP TOE Security Policy -
EVG-Sicherheitspolitik
6.2 Glossar
[CC Teil 1]
Abhängigkeit (dependency) — Eine solche Beziehung zwischen
Anforderungen, daß die Anforderung, von der eine andere abhängig ist, in der
Regel erfüllt sein muß, damit die andere Anforderung in der Lage ist, ihre
Ziele zu erreichen.
Angriffspotential (attack potential) — Das vorausgesetzte Potential für
das Gelingen eines Angriffs, dargestellt anhand der Fachkenntnisse,
Betriebsmittel und Motivation des potentiellen Angreifers.
Anwendungssbereich der
TSF-Kontrolle (TSF scope of control,
TSC) — Die Menge der Interaktionen, die mit oder innerhalb eines TOE (EVG)
vorkommen können und den Regeln der TSP unterliegen.
Auswahl (selection) - Die Spezifikation einer oder mehrerer
Bestandteile aus einer Liste in einer Komponente.
Authentisierungsdaten (authentication data) — Informationen, die genutzt
werden, um die angegebene Identität des Benutzers zu verifizieren.
Autorisierter Benutzer (authorised user) — Ein Benutzer, der einen Vorgang in
Übereinstimmung mit der TSP durchführen kann.
Benutzer (user) — Jede Einheit (menschlicher Benutzer oder
externe IT-Einheit) außerhalb des TOE (EVG), die mit dem TOE (EVG) interagiert.
Benutzerdaten (user data) — Daten, die vom und für den Benutzer
erstellt werden und die den
Betrieb der TSF nicht
beeinflussen
Element (element) — Eine unteilbare
Sicherheitsanforderung.
Erweiterung (extension) — Das Hinzufügen von funktionalen
Anforderungen, die nicht in Teil 2 enthalten sind, und/oder von
Vertrauenswürdigkeitsanforderungen, die nicht in Teil 3 enthalten sind, zu den
ST bzw. dem PP.
Evaluationsgegenstand (TOE
(EVG)) (target of evaluation, TOE) —
Ein IT-Produkt oder -System
— sowie die dazugehörigen
Systemverwalter- und Benutzerhandbücher — das Gegenstand einer Prüfung und
Bewertung ist.
Evaluationsschema (evaluation scheme) — Die administrativen und
organisatorischen Rahmenbedingungen, unter denen die CC durch eine
Zertifizierungsstelle in einer bestimmten Gemeinschaft angewendet werden.
Vertrauenswürdigkeitsstufe
(EAL) (evaluation assurance level,
EAL) — Ein Paket von Vertrauenswürdigkeitskomponenten aus Teil 3, das einen
Punkt auf der festgelegten CC-Vertrauenswürdigkeitsskala wiedergibt. Evaluation
Assurance Level (EAL)
Der Begriff EAL-Stufe bezeichnet eine Stufe der Vertrauenswürdigkeit
(Evaluation Assurance Level) in eine Sicherheitsleistung.
Die EAL-Stufen der Common Criteria (ISO 15408) beschreiben präzise
Anforderungen an eine IT-Sicherheitsprüfung. Mit wachsender EAL-Nummer steigen
die Anforderungen an den zu prüfenden Umfang, an die Prüftiefe und an die
Prüfmethoden. Eine niedrigere EAL-Stufe kann vom Prüfumfang als Untermenge des
Prüfaufwandes der nächst höheren Stufe angesehen werden. Daher macht das Vorgehen
Sinn, mit niedrigeren EAL-Stufen den Evaluierungsprozess zu starten, da so ein
erstes verwertbares Prüfergebnis in Form eines Zertifikates mit ausführlichem
Report schneller erreicht werden kann. Darauf aufbauend müssen die nächsten
EAL-Stufen "nur noch" den zusätzlichen Prüfaufwand umfassen. Bei EAL4
muss beispielsweise der Sourcecode evaluiert werden, was beim Evaluator
Entwicklerkenntnisse des Produktes voraussetzt! Entsprechend hoch ist der
Dokumentationsaufwand für das Produkt. Ab EAL5 kommen formale Spezifikations-
und Verifikationsmethoden hinzu, denen herkömmliche Entwicklungsmethoden nicht
mehr genügen.
Ziel einer Common Criteria-Evaluierung ist die Bestätigung, dass die vom
Hersteller behauptete Sicherheitsfunktionalität wirksam ist. Da die Sicherheitsleistung
insbesondere durch die Ausnutzbarkeit vorhandener Schwachstellen unwirksam
werden kann, ist bei allen Evaluierungsaspekten die Analyse der Schwachstellen
ein zentrales Prüfziel. Mit wachsenden EAL-Stufen wird erreicht, zunehmend
komplexer ausnutzbare Schwachstellen zu entdecken.
Wieviel ein EAL4-Zertifikat besser ist als ein EAL2-Zertifikat, kann nur aus
dem Zertifizierungsreport ersehen werden. Wenn das Produkt eine nicht zu
beseitigende Schwachstelle enthält, kann das zu einer erheblichen Einschränkung
seiner Nutzungsmöglichkeiten führen. Beispielsweise könnte eine mit EAL4
nachgewiesene Sicherheitsfunktionalität nur unter Einhaltung massivster
Restriktionen an die Nutzung wirksam sein, etwa dadurch, dass durch
einzuhaltende Auflagen an den Betrieb des Produktes jegliche
Angriffsmöglichkeit auf ein Netzwerk auszuschalten ist und so eine vorhandene
Schwachstelle nicht mehr ausnutzbar wird. Wer das Produkt trotzdem anders
betreibt, weiß immerhin, dass er angreifbar ist - trotz EAL4-Zertifikat.
Eine detaillierte Beschreibung der Sicherheitsleistung eines zertifizierten
Produktes kann im Zertifizierungsreport nachgelesen werden (alle
Zertifizierungsreporte sind veröffentlicht, siehe
www.bsi.bund.de/zertifiz/zert/report.htm oder http://www.commoncriteriaportal.org/
externer Link). Besonders interessant sind darin der Konfigurationsumfang und
die Annahmen an den Betrieb des Produktes. Tatsächlich zählt die
Internetnutzung bei vielen Zertifikaten nicht zum Konfigurationsumfang. Auch an
Netzwerkumgebungen werden häufig hohe Auflagen zum Schutz des Netzwerks
gestellt.
Gedanken zum Verzicht auf eine Sicherheitsprüfung: Ungeprüfte
Sicherheitstechnik ist genau so gut wie die Sicherheit eines Autos, das nicht
bei der Hauptuntersuchung war. Sie kann in Ordnung sein, aber man darf
berechtigtes Misstrauen haben. Erst die Hauptuntersuchung einer neutralen
Instanz gibt ein begründetes Vertrauen in die Sicherheit des Autos. Allerdings
wird bei der Hauptuntersuchung der PKW nur nach ein- und derselben Prüftiefe
geprüft. Der Aufwand zur Prüfung von IT-Sicherheit ist erheblich größer. Daher
macht es Sinn, einen wirtschaftlich durchführbaren Evaluierungsprozess
anzubieten, der mit den EAL-Stufen geschaffen wurde.
EVG-Betriebsmittel (TOE resource) — Alles in einem TOE (EVG), was nutzbar
oder verbrauchbar ist.
EVG-interner Transfer (internal TOE transfer) — Datenaustausch zwischen
getrennten Teilen des TOE (EVG).
EVG-Sicherheitsfunktionen (TOE security functions, TSF) — Eine Menge, die die
gesamte Hardware, Software, und Firmware des TOE (EVG) umfaßt, auf die Verlaß
sein muß, um die TSP korrekt zu erfüllen.
EVG-Sicherheitsmodell (TOE security policy model) — Eine strukturierte
Darstellung der Sicherheitspolitik, die durch den TOE (EVG) durchgesetzt werden
soll.
EVG-Sicherheitspolitik (TOE security policy, TSP) — Eine Menge von Regeln,
die angibt, wie innerhalb eines TOE (EVG) Werte verwaltet, geschützt und
verteilt werden.
Externe IT-Einheit (external IT entity) — Jedes IT-Produkt oder -System
außerhalb des TOE (EVG), vertrauenswürdig oder nicht, das mit dem TOE (EVG)
interagiert.
Familie (family) — Eine Gruppe von Komponenten, die
Sicherheitsziele teilen, sich aber in Schwerpunkt oder Schärfe unterscheiden
können.
Formal (formal) — Ausgedrückt in einer Sprache mit beschränkter
Syntax und festgelegter Semantik, die auf bewährten mathematischen Konzepten
basiert.
Funktionale
Sicherheitspolitik (security function
policy, SFP) — Die Sicherheitspolitik, die durch eine SF durchgesetzt wird.
Geheimnis (secret) — Informationen, die nur autorisierten
Benutzern und/oder den TSF bekannt sein dürfen, um eine konkrete SFP
durchzusetzen.
Identität (identity) — Eine Darstellung (zum Beispiel eine
Zeichenkette), die einen autorisierten Benutzer eindeutig identifiziert und
entweder der volle bzw. abgekürzte Name des Benutzers oder ein Pseudonym sein
kann.
Informell (informal) — Ausgedrückt in natürlicher Sprache.
Interner Kommunikationskanal
(internal communication channel) —
Ein Kommunikationskanal zwischen getrennten Teilen des TOE (EVG).
Inter-TSF-Transfer (inter-TSF transfers) — Datenaustausch zwischen TOE
(EVG) und den Sicherheitsfunktionen anderer vertrauenswürdiger IT-Produkte.
Iteration (iteration) — Der mehrmalige Gebrauch einer Komponente
mit unterschiedlichen Operationen.
Klasse (class) — Eine Gruppe von Familien, die eine
gemeinsame Zielsetzung verfolgen.
Komponente (component) — Die kleinste wählbare Menge von
Elementen, die in einem PP, in ST oder in einem Paket enthalten sein können.
Prüfung und Bewertung (evaluation) — Bewertung eines PP, von ST oder eines
TOE (EVG) auf Grundlage festgelegter Kriterien.
Menschlicher Benutzer (human user) — Jede Person, die mit dem TOE (EVG)
interagiert.
Objekt (object) — Eine Einheit im TSC, die Informationen
enthält oder empfängt und auf der Subjekte Operationen ausführen.
Organisatorische
Sicherheitspolitiken (organisational
security policies) - Eine oder mehrere Sicherheitsregeln, Verfahren, Praktiken
oder Anleitungen, die eine Organisation für deren Tätigkeit vorschreibt.
Paket (package) — Eine wiederverwendbare kombinierte Menge
von funktionalen Komponenten oder Vertrauenswürdigkeitskomponenten (zum
Beispiel eine EAL), die einer Menge von identifizierten Sicherheitszielen
genügen.
Produkt (product) — Ein Paket aus IT-Software, Firmware
und/oder Hardware, das Funktionalität für den Gebrauch oder die Einbindung in
einer Vielzahl von Systemen bereitstellt.
Referenzmonitor (reference monitor) — Das Konzept einer abstrakten
Maschine, die die EVGZugriffskontrollpolitiken durchsetzt.
Referenzvalidierungsmechanismus
(reference validation mechanism) —
Eine Implementierung des Referenzmonitorkonzepts, die folgende Eigenschaften
besitzt: sie ist manipulationssicher, immer eingeschaltet und einfach genug, um
gründlichen Analysen und Tests unterzogen werden zu können.
Rolle (role) — Eine vordefinierte Menge von Regeln, die die
erlaubten Interaktionen zwischen dem Benutzer und dem TOE (EVG) festlegen.
Schnittstellen der
EVG-Sicherheitsfunktionen (TOE
security functions interface, TSFI) – Eine Menge von Schnittstellen, entweder
interaktiv (Schnittstelle zwischen Mensch und Maschine) oder programmiert
(Anwendungsprogramm-Schnittstelle), über die der Zugang zu den
EVG-Betriebsmitteln, vermittelt durch die TSF, erfolgt, oder Informationen von
den TSF erhalten werden.
Schutzprofil (PP) (protection profile, PP) — Eine
implementierungsunabhängige Menge von Sicherheitsanforderungen an eine
Kategorie von TOE (EVG), die besondere Bedürfnisse der Anwender erfüllen.
Semiformal (semiformal) — Ausgedrückt in einer Sprache mit
beschränkter Syntax und festgelegter Semantik.
Sicherheitsattribut (security attribute) — Informationen, die mit
Subjekten, Benutzern und/oder Objekten verknüpft sind und die zur Durchsetzung
der TSP benötigt werden.
Sicherheitsfunktion (SF) (security function, SF) — Ein Teil oder Teile eines
TOE (EVG), auf die zur Durchsetzung einer hierzu in enger Beziehung stehende
Teilmenge der Regeln der TSP Verlaß sein muß.
Sicherheitsvorgaben (ST) (security target, ST) — Eine Menge von Sicherheitsanforderungen
und Sicherheitsspezifikationen, die als Grundlage für die Prüfung und Bewertung
eines angegebenen TOE (EVG) dienen.
Sicherheitsziel (security objective) - Darlegung der Absicht,
erkannten Gefahren entgegenzuwirken und/oder organisatorische Sicherheitspolitiken
(security policies) und Annahmen zu erfüllen.
SOF-Niedrig (SOF-basic) — Eine Stufe der EVG-Stärke (TOE strength)
von Funktionen, bei der die Analyse zeigt, daß die Funktionen einen
angemessenen Schutz gegen zufälliges Brechen der EVG-Sicherheit durch Angreifer
bieten, die über ein geringes Angriffspotential verfügen.
SOF-Mittel (SOF-medium) — Eine Stufe der EVG-Stärke (TOE
strength) von Funktionen, bei der die Analyse zeigt, daß die Funktionen einen
angemessenen Schutz gegen naheliegendes oder absichtliches Brechen der
EVG-Sicherheit durch Angreifer bieten, die über ein mittleres Angriffspotential
verfügen.
SOF-Hoch (SOF-high) - Eine Stufe der EVG-Stärke (TOE strength)
von Funktionen, bei der die Analyse zeigt, daß die Funktionen einen geeigneten
Schutz gegen geplantes oder organisiertes Brechen der EVG-Sicherheit durch
Angreifer bieten, die über ein hohes Angriffspotential verfügen.
Stärke der Funktionen (SOF) (strength of function, SOF) — Eine Charakterisierung
einer EVGSicherheitsfunktion, die den geringsten angenommenen Aufwand
beschreibt, der notwendig ist, um deren erwartetes Sicherheitsverhalten durch
einen direkten Angriff auf die zugrundeliegenden Sicherheitsmechanismen außer
Kraft zu setzen.
Subjekt (subject) — Eine Einheit innerhalb des TSC, die die
Ausführung von Operationen bewirkt.
System (system) - Ein bestimmter IT-Aufbau, mit einem
bestimmten Zweck und Einsatzumgebung.
Transfer außerhalb der
TSF-Kontrolle (transfers outside TSF
control) — Datenaustausch mit Einheiten, die nicht unter Kontrolle der TSF
stehen.
TSF-Daten (TSF data) — Von und für den TOE (EVG) erstellte
Daten, die den Betrieb des TOE (EVG) beeinflussen können.
Verfeinerung (refinement) — Das Hinzufügen von Einzelheiten zu
einer Komponente.
Vernetzbarkeit (connectivity) - Die Eigenschaft eines TOE (EVG), die
eine Interaktion mit ITEinheiten außerhalb des TOE (EVG) erlaubt. Dies umfaßt
den Datenaustausch über Kabel oder drahtlose Verbindungen, über jede Distanz,
in jeder Umgebung oder Konfiguration.
Vertrauenswürdiger Kanal (trusted channel) — Ein Übertragungsweg, bei dem eine
TSF und ein entferntes vertrauenswürdiges IT-Produkt mit der von den TSP
geforderten Vertraulichkeit kommunizieren können.
Vertrauenswürdiger Pfad (trusted path) — Ein Übertragungsweg, bei dem ein
Benutzer und die TSF mit der von den TSP geforderten Vertraulichkeit
kommunizieren können.
Vertrauenswürdigkeit (assurance) — Gründe für das Vertrauen darin, daß eine
Einheit ihre Sicherheitsziele erfüllt.
Werte (assets) — Informationen oder Betriebsmittel, die
durch Gegenmaßnahmen des TOE
(EVG) geschützt werden sollen.
Zertifizierungsstelle (evaluation authority) — Eine Institution, die die CC
in einer bestimmten Gemeinschaft mittels eines Evaluationsschemas einführt und
dadurch die Normen festlegt und die Qualität der Prüfungen und Bewertungen
überwacht, die durch Organisationen in dieser Gemeinschaft durchgeführt werden.
Zusatz (augmentation) — Das Hinzufügen einer oder mehrerer
Vertrauenswürdigkeitskomponenten aus Teil 3 zu einer EAL oder einem
Vertrauenswürdigkeitspaket.
Zuweisung (assignment) — Die Spezifikation eines identifizierten
Parameters in einer Komponente.
6.3 Quellen
Literaturverzeichnis
NIST Homepage: 2000,
http://www.nist.gov/
NIST publications: http://csrc.nist.gov/publications/nistir/
CC Consumers:
http://www.commoncriteriaportal.org/public/consumer/index.php?menu=6
IEEE Wiki: Wolfgang Ihloff, 2005, http://de.wikipedia.org/wiki/IEEE
IEEE Institute of Electrical and Electronics Engineers, 2005,
http://www.ieeeia.org/projects.html
Wiki COTS: 194.15.243.164, 2005, http://de.wikipedia.org/wiki/COTS
BSI CC: http://www.bsi.bund.de/cc/index.htm
Bundesanzeiger: 2000
BSI PP: http://www.bsi.bund.de/cc/pplist/pplist.htm
CC Teil 1: Gemeinsame
Kriterienfür die Prüfung und Bewertungder Sicherheit von Informationstechnik,
1999
NIAP PP: 2005, http://niap.nist.gov/cc-scheme/pp/index.html
CSPP: Gary Stoneburner, CSPP - Guidance for COTS Security Protection
Profiles, 1999
BOSS INIT: Jodi Haasz, 2003
BOSS MAIL: John Cole, 2004
IEEE ACT: IEEEIA, Report of Recent Activities, 2005
CSPP-OS: Gary Stoneburner, COTS Security Protection Profile - Operating
Systems (CSPP-OS), 2003
CC Teil 2: Gemeinsame
Kriterienfür die Prüfung und Bewertungder Sicherheit von Informationstechnik,
1999