Din en Iso Iec 18045 2021-02

DEUTSCHE NORM Februar 2021
DIN EN ISO/IEC 18045

D
ICS 35.030
Informationstechnik –
Sicherheitstechniken –
Methodik für die Bewertung der IT-Sicherheit (ISO/IEC 18045:2008);
Deutsche Fassung EN ISO/IEC 18045:2020, nur auf CD-ROM
Information technology –
Security techniques –
Methodology for IT security evaluation (ISO/IEC 18045:2008);
German version EN ISO/IEC 18045:2020, only on CD-ROM
Technologies de l’information –
Techniques de sécurité –
Méthodologie pour l’évaluation de sécurité TI (ISO/IEC 18045:2008);
Version allemande EN ISO/IEC 18045:2020, seulement en CD-ROM
Gesamtumfang 344 Seiten
DIN-Normenausschuss Informationstechnik und Anwendungen (NIA)

DIN EN ISO/IEC 18045:2021-02
Nationales Vorwort
Der Text von ISO/IEC 18045:2008 wurde vom Technischen Komitee ISO/IEC JTC 1 „Information technology“
der Internationalen Organisation für Normung (ISO) und der Internationalen Elektrotechnischen
Kommission (IEC) erarbeitet und als EN ISO/IEC 18045:2020 durch das Technische Komitee CEN/TC 13
„Cybersicherheit und Datenschutz“ übernommen, dessen Sekretariat von DIN (Deutschland) gehalten wird.
Das zuständige nationale Normungsgremium ist der Arbeitskreis NA 043-01-27-03 AK „Evaluationskriterien

für IT-Sicherheit“ im DIN-Normenausschuss Informationstechnik und Anwendungen (NIA).
Für die in diesem Dokument zitierten Dokumente wird im Folgenden auf die entsprechenden deutschen
Dokumente hingewiesen:
ISO/IEC 15408 (all parts) siehe DIN EN ISO/IEC 15408 (alle Teile)
Aktuelle Informationen zu diesem Dokument können über die Internetseiten von DIN (www.din.de) durch
eine Suche nach der Dokumentennummer aufgerufen werden.
Nationaler Anhang NA
(informativ)
Literaturhinweise
DIN EN ISO/IEC 15408 (alle Teile), Informationstechnik — IT-Sicherheitsverfahren —- Evaluationskriterien

für IT-Sicherheit
2
EUROPÄISCHE NORM EN ISO/IEC 18045
EUROPEAN STANDARD
NORME EUROPÉENNE März 2020
ICS 35.030
Deutsche Fassung
Informationstechnik —
Sicherheitstechniken —
Methodik für die Bewertung der IT-Sicherheit
(ISO/IEC 18045:2008)
Information technology — Technologies de l'information —
Security techniques — Techniques de sécurité —
Methodology for IT security evaluation Méthodologie pour l'évaluation de sécurité TI
(ISO/IEC 18045:2008) (ISO/IEC 18045:2008)
Diese Europäische Norm wurde vom CEN am 2. März 2020 angenommen.
Die CEN und CENELEC-Mitglieder sind gehalten, die CEN/CENELEC-Geschäftsordnung zu erfüllen, in der die Bedingungen
festgelegt sind, unter denen dieser Europäischen Norm ohne jede Änderung der Status einer nationalen Norm zu geben ist. Auf
dem letzten Stand befindliche Listen dieser nationalen Normen mit ihren bibliographischen Angaben sind beim CEN-CENELEC-
Management-Zentrum oder bei jedem CEN und CENELEC-Mitglied auf Anfrage erhältlich.
Diese Europäische Norm besteht in drei offiziellen Fassungen (Deutsch, Englisch, Französisch). Eine Fassung in einer anderen
Sprache, die von einem CEN und CENELEC-Mitglied in eigener Verantwortung durch Übersetzung in seine Landessprache
gemacht und dem Management-Zentrum mitgeteilt worden ist, hat den gleichen Status wie die offiziellen Fassungen.
CEN- und CENELEC-Mitglieder sind die nationalen Normungsinstitute und elektrotechnischen Komitees von Belgien, Bulgarien,
Dänemark, Deutschland, Estland, Finnland, Frankreich, Griechenland, Irland, Island, Italien, Kroatien, Lettland, Litauen,
Luxemburg, Malta, den Niederlanden, Norwegen, Österreich, Polen, Portugal, der Republik Nordmazedonien, Rumänien,
Schweden, der Schweiz, Serbien, der Slowakei, Slowenien, Spanien, der Tschechischen Republik, der Türkei, Ungarn, dem
Vereinigten Königreich und Zypern.
CEN-CENELEC Management Centre:

Rue de la Science 23, B-1040 Brussels
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Inhalt
Seite
Europäisches Vorwort .......................................................................................................................................................... 7

Vorwort ...................................................................................................................................................................................... 8
Rechtliche Hinweise .............................................................................................................................................................. 9
Einleitung ................................................................................................................................................................................ 10
1 Anwendungsbereich............................................................................................................................................. 11
2 Normative Verweisungen ................................................................................................................................... 11
3 Begriffe ...................................................................................................................................................................... 11
4 Symbole und Abkürzungen................................................................................................................................13
5 Überblick .................................................................................................................................................................. 13
5.1 Gliederung dieser Internationalen Norm.....................................................................................................13
6 Typographische Konventionen ........................................................................................................................14
6.1 Terminologie........................................................................................................................................................... 14
6.2 Verbgebrauch.......................................................................................................................................................... 14
6.3 Allgemeine Evaluierungsleitlinien..................................................................................................................14
6.4 Beziehung zwischen den Strukturen von ISO/IEC 15408 und ISO/IEC 18045................................14
7 Evaluierungsprozess und damit verbundene Arbeitsaufgaben...........................................................15
7.1 Einleitung ................................................................................................................................................................. 15
7.2 Überblick über den Evaluierungsprozess ....................................................................................................16
7.2.1 Zielsetzungen .......................................................................................................................................................... 16
7.2.2 Verantwortlichkeiten der Rollen.....................................................................................................................16
7.2.3 Beziehung der Rollen ........................................................................................................................................... 16
7.2.4 Allgemeines Evaluierungsmodell ....................................................................................................................16
7.2.5 Evaluatoren-Entscheidungen............................................................................................................................17
7.3 Eingabearbeitsaufgabe der Evaluierung.......................................................................................................19
7.3.1 Zielsetzungen .......................................................................................................................................................... 19
7.3.2 Anwendungshinweise.......................................................................................................................................... 19
7.3.3 Management der Teilarbeitsaufgabe der Evaluationsnachweise........................................................20
7.4 Evaluierungsunteraufgaben ..............................................................................................................................20
7.5 Ausgabearbeitsaufgabe der Evaluierung......................................................................................................20
7.5.1 Zielsetzungen .......................................................................................................................................................... 20
7.5.2 Management der Evaluierungsausgaben......................................................................................................21
7.5.3 Anwendungshinweise.......................................................................................................................................... 21
7.5.4 OR-Teilarbeitsaufgabe schreiben....................................................................................................................21
7.5.5 ETR-Teilarbeitsaufgabe schreiben..................................................................................................................22
8 Klasse APE: Evaluierung des Schutzprofils ..................................................................................................27
8.1 Einleitung ................................................................................................................................................................. 27
8.2 Anwendungshinweise.......................................................................................................................................... 28
8.2.1 Wiederverwendung der Evaluierungsergebnisse von zertifizierten PPs.........................................28
8.3 PP-Einleitung (APE_INT) .....................................................................................................................................28
8.3.1 Evaluierung der Unteraufgabe (APE_INT.1) ................................................................................................28
8.4 Konformitätsansprüche (APE_CCL) ................................................................................................................30
8.4.1 Evaluierung der Unteraufgabe (APE_CCL.1) ................................................................................................30
8.5 Sicherheitsproblemdefinition (APE_SPD) ....................................................................................................37
2
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
8.5.1 Evaluierung der Unteraufgabe (APE_SPD.1) ............................................................................................... 37

8.6 Sicherheitszielsetzungen (APE_OBJ) .............................................................................................................. 38
8.6.1 Evaluierung der Unteraufgabe (APE_OBJ.1) ................................................................................................ 38
8.6.2 Evaluierung der Unteraufgabe (APE_OBJ.2) ................................................................................................ 39
8.7 Erweiterte Komponentendefinition (APE_ECD)......................................................................................... 41
8.7.1 Evaluierung der Unteraufgabe (APE_ECD.1) ............................................................................................... 41
8.8 Sicherheitsanforderungen (APE_REQ) .......................................................................................................... 45
8.8.1 Evaluierung der Unteraufgabe (APE_REQ.1) ............................................................................................... 45
8.8.2 Evaluierung der Unteraufgabe (APE_REQ.2) ............................................................................................... 49
9 Klasse ASE: Evaluierung der Sicherheitsvorgabe ...................................................................................... 54
9.1 Einleitung ................................................................................................................................................................. 54
9.2.1 Wiederverwendung der Evaluierungsergebnisse von zertifizierten PPs ........................................ 54
9.3 ST-Einleitung (ASE_INT)...................................................................................................................................... 54
9.3.1 Evaluierung der Unteraufgabe (ASE_INT.1)................................................................................................. 54
9.4 Konformitätsansprüche (ASE_CCL)................................................................................................................. 57
9.4.1 Evaluierung der Unteraufgabe (ASE_CCL.1)................................................................................................. 57
9.5 Sicherheitsproblemdefinition (ASE_SPD)..................................................................................................... 66
9.5.1 Evaluierung der Unteraufgabe (ASE_SPD.1)................................................................................................ 66
9.6 Sicherheitszielsetzungen (ASE_OBJ)............................................................................................................... 67
9.6.1 Evaluierung der Unteraufgabe (ASE_OBJ.1)................................................................................................. 67
9.6.2 Evaluierung der Unteraufgabe (ASE_OBJ.2)................................................................................................. 68
9.7 Erweiterte Komponentendefinition (ASE_ECD) ......................................................................................... 70
9.7.1 Evaluierung der Unteraufgabe (ASE_ECD.1)................................................................................................ 70
9.8 Sicherheitsanforderungen (ASE_REQ)........................................................................................................... 74
9.8.1 Evaluierung der Unteraufgabe (ASE_REQ.1) ............................................................................................... 74
9.8.2 Evaluierung der Unteraufgabe (ASE_REQ.2) ............................................................................................... 78
9.9 Zusammenfassende Spezifikation des TOEs (ASE_TSS) .......................................................................... 83
9.9.1 Evaluierung der Unteraufgabe (ASE_TSS.1)................................................................................................. 83
9.9.2 Evaluierung der Unteraufgabe (ASE_TSS.2)................................................................................................. 83
10 Klasse ADV: Entwicklung .................................................................................................................................... 85
10.1 Einleitung ................................................................................................................................................................. 85
10.3 Sicherheitsarchitektur (ADV_ARC) ................................................................................................................. 86
10.3.1 Evaluierung der Unteraufgabe (ADV_ARC.1)............................................................................................... 86
10.4 Funktionsspezifikation (ADV_FSP) ................................................................................................................. 91
10.4.1 Evaluierung der Unteraufgabe (ADV_FSP.1)................................................................................................ 91
10.4.2 Evaluierung der Unteraufgabe (ADV_FSP.2)................................................................................................ 94
10.4.3 Evaluierung der Unteraufgabe (ADV_FSP.3)............................................................................................. 100
10.5 Darstellung der Implementierung (ADV_IMP) ........................................................................................ 118
10.5.1 Evaluierung der Unteraufgabe (ADV_IMP.1)............................................................................................ 118
10.5.2 Evaluierung der Unteraufgabe (ADV_IMP.2)............................................................................................ 120
10.6 TSF-Interna (ADV_INT)..................................................................................................................................... 120
10.6.1 Evaluierung der Unteraufgabe (ADV_INT.1)............................................................................................. 120
10.7 Modellierung der Sicherheitspolitik (ADV_SPM).................................................................................... 125
10.7.1 Evaluierung der Unteraufgabe (ADV_SPM.1) ........................................................................................... 125
10.8 TOE-Design (ADV_TDS) .................................................................................................................................... 125
10.8.1 Evaluierung der Unteraufgabe (ADV_TDS.1)............................................................................................ 125
3
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

11 Klasse AGD: Leitliniendokumente................................................................................................................ 155
11.1 Einleitung .............................................................................................................................................................. 155
11.2 Anwendungshinweise....................................................................................................................................... 155
11.3 Operative Leitlinien für Benutzer (AGD_OPE) ......................................................................................... 155
11.3.1 Evaluierung der Unteraufgabe (AGD_OPE.1)............................................................................................ 155
11.4 Vorbereitende Verfahren (AGD_PRE) ......................................................................................................... 158
11.4.1 Evaluierung der Unteraufgabe (AGD_PRE.1)............................................................................................ 158
12 Klasse ALC: Unterstützung des Lebenszyklus .......................................................................................... 160
12.1 Einleitung .............................................................................................................................................................. 160
12.2 CM-Funktionen (ALC_CMC).............................................................................................................................. 161
12.2.1 Evaluierung der Unteraufgabe (ALC_CMC.1) ............................................................................................ 161
12.3 CM-Umfang (ALC_CMS)...................................................................................................................................... 181
12.3.1 Evaluierung der Unteraufgabe (ALC_CMS.1) ............................................................................................ 181
12.4 Lieferung (ALC_DEL).......................................................................................................................................... 186
12.4.1 Evaluierung der Unteraufgabe (ALC_DEL.1)............................................................................................. 186
12.5 Entwicklungssicherheit (ALC_DVS).............................................................................................................. 188
12.5.1 Evaluierung der Unteraufgabe (ALC_DVS.1)............................................................................................. 188
12.5.2 Evaluierung der Unteraufgabe (ALC_DVS.2)............................................................................................. 190
12.6 Mängelbeseitigung (ALC_FLR)........................................................................................................................ 194
12.6.1 Evaluierung der Unteraufgabe (ALC_FLR.1) ............................................................................................. 194
12.7 Definition des Lebenszyklus (ALC_LCD)..................................................................................................... 206
12.7.1 Evaluierung der Unteraufgabe (ALC_LCD.1)............................................................................................. 206
12.7.2 Evaluierung der Unteraufgabe (ALC_LCD.2)............................................................................................. 207
12.8 Tools und Techniken (ALC_TAT)................................................................................................................... 209
12.8.1 Evaluierung der Unteraufgabe (ALC_TAT.1) ............................................................................................ 209
13 Klasse ATE: Prüfungen...................................................................................................................................... 216
13.1 Einleitung .............................................................................................................................................................. 216
13.2.1 Verständnis des erwarteten Verhaltens des TOEs ................................................................................. 217
13.2.2 Prüfen gegenüber alternativen Ansätzen zur Überprüfung des erwarteten Verhaltens
der Funktionalität .............................................................................................................................................. 218
13.2.3 Überprüfung der Angemessenheit der Prüfungen................................................................................. 218
13.3 Abdeckung (ATE_COV)...................................................................................................................................... 219
13.3.1 Evaluierung der Unteraufgabe (ATE_COV.1) ............................................................................................ 219
13.4 Tiefe (ATE_DPT) .................................................................................................................................................. 221
13.4.1 Evaluierung der Unteraufgabe (ATE_DPT.1)............................................................................................ 221
4
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

13.5 Funktionsprüfungen (ATE_FUN)................................................................................................................... 229
13.5.1 Evaluierung der Unteraufgabe (ATE_FUN.1) ............................................................................................ 229
13.5.2 Evaluierung der Unteraufgabe (ATE_FUN.2) ............................................................................................ 232
13.6 Unabhängiges Prüfen (ATE_IND) .................................................................................................................. 232
13.6.1 Evaluierung der Unteraufgabe (ATE_IND.1)............................................................................................. 232
14 Klasse AVA: Anfälligkeitsbewertung ........................................................................................................... 242
14.1 Einleitung .............................................................................................................................................................. 242
14.2 Anfälligkeitsanalyse (AVA_VAN)................................................................................................................... 243
14.2.1 Evaluierung der Unteraufgabe (AVA_VAN.1) ........................................................................................... 243
15 Klasse ACO: Zusammensetzung..................................................................................................................... 273
15.1 Einleitung .............................................................................................................................................................. 273
15.3 Begründung der Zusammensetzung (ACO_COR)..................................................................................... 274
15.3.1 Evaluierung der Unteraufgabe (ACO_COR.1)............................................................................................ 274
15.4 Entwicklungsnachweis (ACO_DEV) .............................................................................................................. 281
15.4.1 Evaluierung der Unteraufgabe (ACO_DEV.1)............................................................................................ 281
15.5 Verlässlichkeit der abhängigen Komponente (ACO_REL) ................................................................... 287
15.5.1 Evaluierung der Unteraufgabe (ACO_REL.1) ............................................................................................ 287
15.5.2 Evaluierung der Unteraufgabe (ACO_REL.2) ............................................................................................ 289
15.6 Prüfen des zusammengesetzten TOEs (ACO_CTT) ................................................................................. 292
15.6.1 Evaluierung der Unteraufgabe (ACO_CTT.1) ............................................................................................ 292
15.6.2 Evaluierung der Unteraufgabe (ACO_CTT.2) ............................................................................................ 295
15.7 Anfälligkeitsanalyse der Zusammensetzung (ACO_VUL)..................................................................... 298
15.7.1 Evaluierung der Unteraufgabe (ACO_VUL.1) ............................................................................................ 298
Anhang A (informativ) Allgemeine Evaluierungsleitlinien .............................................................................. 310
A.1 Zielsetzungen....................................................................................................................................................... 310
A.2 Probenahme ......................................................................................................................................................... 310
A.3 Abhängigkeiten ................................................................................................................................................... 312
A.3.1 Abhängigkeiten zwischen Aufgaben............................................................................................................ 312
A.3.2 Abhängigkeiten zwischen Unteraufgaben................................................................................................. 312
A.3.3 Abhängigkeiten zwischen Aktionen ............................................................................................................ 313
A.4 Standortbesichtigungen................................................................................................................................... 313
A.4.1 Einleitung .............................................................................................................................................................. 313
A.4.2 Allgemeiner Ansatz............................................................................................................................................ 314
A.4.3 Orientierungshilfe für die Erstellung der Checkliste ............................................................................ 314
A.4.4 Beispiel für eine Checkliste ............................................................................................................................ 316
A.5 Zuständigkeiten des Schemas........................................................................................................................ 318
Anhang B (informativ) Anfälligkeitsbewertung (AVA)....................................................................................... 320
B.1 Was ist eine Anfälligkeitsanalyse? ............................................................................................................... 320
B.2 Erstellung einer Anfälligkeitsanalyse durch den Evaluator............................................................... 321
B.2.1 Generische Leitlinien für Anfälligkeiten.................................................................................................... 321
5
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
B.2.2 Identifizierung potentieller Anfälligkeiten............................................................................................... 329

B.3 Wenn das Angriffspotential genutzt wird.................................................................................................. 332
B.3.1 Entwickler ............................................................................................................................................................. 332
B.3.2 Evaluator................................................................................................................................................................ 332
B.4 Berechnung des Angriffspotentials.............................................................................................................. 334
B.4.1 Anwendung des Angriffspotentials.............................................................................................................. 334
B.4.2 Charakterisierung des Angriffspotentials................................................................................................. 335
B.5 Beispielrechnung für direkten Angriff ....................................................................................................... 341
6
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Europäisches Vorwort
Der Text von ISO/IEC 18045:2008 wurde vom Technischen Komitee ISO/IEC JTC 1 „Information technology“
der Internationalen Organisation für Normung (ISO) und der Internationalen Elektrotechnischen Kommission
(IEC) erarbeitet und als EN ISO/IEC 18045:2020 durch das Technische Komitee CEN/TC 13 „Cybersicherheit
und Datenschutz“ übernommen, dessen Sekretariat von DIN gehalten wird.
Diese Europäische Norm muss den Status einer nationalen Norm erhalten, entweder durch Veröffentlichung
eines identischen Textes oder durch Anerkennung bis September 2020, und etwaige entgegenstehende
nationale Normen müssen bis September 2020 zurückgezogen werden.
Es wird auf die Möglichkeit hingewiesen, dass einige Elemente dieses Dokuments Patentrechte berühren
können. CEN ist nicht dafür verantwortlich, einige oder alle diesbezüglichen Patentrechte zu identifizieren.
Entsprechend der CEN-CENELEC-Geschäftsordnung sind die nationalen Normungsinstitute der folgenden

Länder gehalten, diese Europäische Norm zu übernehmen: Belgien, Bulgarien, Dänemark, Deutschland, die
Republik Nordmazedonien, Estland, Finnland, Frankreich, Griechenland, Irland, Island, Italien, Kroatien,
Lettland, Litauen, Luxemburg, Malta, Niederlande, Norwegen, Österreich, Polen, Portugal, Rumänien,
Schweden, Schweiz, Serbien, Slowakei, Slowenien, Spanien, Tschechische Republik, Türkei, Ungarn,
Vereinigtes Königreich und Zypern.
Anerkennungsnotiz
Der Text von ISO/IEC 18045:2008 wurde von CEN als EN ISO/IEC 18045:2020 ohne irgendeine Abänderung
genehmigt.
7
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Vorwort
ISO (die Internationale Organisation für Normung) und IEC (die Internationale Elektrotechnische Kommis-
sion) bilden das auf die weltweite Normung spezialisierte System. Nationale Normungsorganisationen, die
Mitglieder von ISO oder IEC sind, beteiligen sich an der Entwicklung von Internationalen Normen in
Technischen Komitees, die von der jeweiligen Organisation eingerichtet wurden, um spezifische Gebiete
technischer Aktivitäten zu behandeln. Auf Gebieten von beiderseitigem Interesse arbeiten die Technischen
Komitees von ISO und IEC zusammen. Weitere internationale staatliche und nichtstaatliche Organisationen,
die in engem Kontakt mit ISO und IEC stehen, nehmen ebenfalls an der Arbeit teil. Auf dem Gebiet der
Informationstechnologie haben ISO und IEC ein gemeinsames Technisches Komitee, ISO/IEC JTC 1 (JTC, en:
Joint Technical Committee), eingerichtet.
Internationale Normen werden nach den Regeln der ISO/IEC-Direktiven, Teil 2 erarbeitet.
Die Hauptaufgabe des gemeinsamen Technischen Komitees (JTC, en: Joint Technical Committee) ist es,
Internationale Normen zu erarbeiten. Die vom gemeinsamen Technischen Komitee verabschiedeten inter-
nationalen Norm-Entwürfe werden den nationalen Mitgliedern zur Abstimmung vorgelegt. Die Veröffent-
lichung als Internationale Norm erfordert Zustimmung von mindestens 75 % der abstimmenden nationalen
Mitglieder.
Es wird auf die Möglichkeit hingewiesen, dass einige Elemente dieses Dokuments Patentrechte berühren
können. ISO und IEC sind nicht dafür verantwortlich, einige oder alle diesbezüglichen Patentrechte zu
identifizieren.
ISO/IEC 18045 wurde vom gemeinsamen Technischen Komitee ISO/IEC JTC 1, Information technology,
Unterkomitee SC 27, IT Security techniques, erarbeitet. Der identische Text von ISO/IEC 18045 wird von den
Common Criteria Project Sponsoring Organisations als Gemeinsame Methodik für die Bewertung der
IT-Sicherheit (en: Common Methodology for Information Technology Security Evaluation) veröffentlicht. Die
gemeinsame XML-Quelle für beide Publikationen befindet sich auf
http://www.commoncriteriaportal.org/cc/.
Diese zweite Ausgabe ersetzt die erste Ausgabe (ISO/IEC 18045:2005), die technisch überarbeitet wurde.
Diese zweite korrigierte Version von ISO/IEC 18045:2008 enthält verschiedene redaktionelle Korrekturen in
Bezug auf Folgendes:
Konsistenz mit den korrigierten Versionen von ISO/IEC 15408-3:2008 und ISO/IEC 15408-1:2009;
APE_CCL und ASE_CCL, APE_SPD und ASE_SPD, AGD_PRE, ALC_CMC, ALC_DVS, ADV_TDS, ASE_TSS,
AVA_VAN und ADV_FSP.
8
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Rechtliche Hinweise
Die nachfolgend aufgeführten Regierungsorganisationen haben an der Entwicklung dieser Version der
Gemeinsamen Methodik für die Bewertungen der IT-Sicherheit mitgewirkt. Als gemeinsame Inhaber des
Urheberrechts an der Gemeinsamen Methodik für Bewertungen der IT-Sicherheit, Version 3.1 (genannt
CEM 3.1), gewähren sie der ISO/IEC hiermit eine nicht-exklusive Lizenz zur Nutzung von CEM 3.1 bei der
Weiterentwicklung/Pflege der Internationalen Norm ISO/IEC 18045. Diese Regierungsorganisationen
behalten jedoch das Recht, CEM 3.1 nach eigenem Ermessen zu nutzen, zu kopieren, zu verteilen, zu
übersetzen oder zu modifizieren.
Australien/Neuseeland: Das Defence Signals Directorate bzw. das Government Communications Security
Bureau;
Kanada: Communications Security Establishment;
Frankreich: Direction Centrale de la Sécurité des Systèmes d'Information;
Deutschland: Bundesamt für Sicherheit in der Informationstechnik;
Japan: Information Technology Promotion Agency;
Niederlande: Netherlands National Communications Security Agency;
Spanien: Ministerio de Administraciones Públicas und Centro Criptológico Nacional;
Vereinigtes Königreich: Communications-Electronic Security Group;
Vereinigte Staaten: National Security Agency und National Institute of Standards and Technology.
9
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Einleitung
Die Zielgruppe für diese Internationale Norm sind in erster Linie Evaluatoren, die die ISO/IEC 15408
anwenden, und Zertifizierer, die die Evaluatorenaktionen bestätigen; Antragsteller der Evaluierung,
Entwickler, PP-/ST-Autoren und andere an der IT-Sicherheit interessierte Parteien können eine sekundäre
Zielgruppe sein.
Diese Internationale Norm erkennt an, dass hier nicht alle Fragen zur Evaluierung der IT-Sicherheit
beantwortet werden und dass weitere Interpretationen notwendig sind. Einzelne Schemata legen fest, wie mit
solchen Interpretationen umzugehen ist, auch wenn diese möglicherweise Gegenstand von Vereinbarungen
über die gegenseitige Anerkennung sind. Eine Liste der methodenbezogenen Aufgaben, die im Rahmen der
einzelnen Schemata durchgeführt werden können, findet sich in Anhang A.
10
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
1 Anwendungsbereich
Diese Internationale Norm ist ein Begleitdokument zu den „Evaluierungskriterien für die IT-Sicherheit“,
ISO/IEC 15408. Diese Internationale Norm legt die Aktionen fest, die ein Evaluator mindestens durchführen
muss, um eine Evaluierung nach ISO/IEC 15408 unter Verwendung der in ISO/IEC 15408 definierten Kriterien
und Evaluationsnachweise durchzuführen.
Diese Internationale Norm legt keine Evaluatorenaktionen für bestimmte Komponenten der ISO/IEC 15408
mit hoher Vertrauenswürdigkeit fest, für die es noch keine allgemein anerkannten Leitlinien gibt.
2 Normative Verweisungen
Die folgenden zitierten Dokumente sind für die Anwendung dieses Dokuments erforderlich. Bei datierten
Verweisungen gilt nur die in Bezug genommene Ausgabe. Bei undatierten Verweisungen gilt die letzte
Ausgabe des in Bezug genommenen Dokuments (einschließlich aller Änderungen).
ISO/IEC 15408 (all parts), Information technology — Security techniques — Evaluation criteria for IT security
3 Begriffe
Für die Anwendung dieses Dokuments gelten die folgenden Begriffe.
ANMERKUNG Für fettgedruckte Begriffe ist in diesem Unterabschnitt eine eigene Definition aufgeführt.
3.1
Aktion
Evaluatorenaktionselement aus ISO/IEC 15408-3
ANMERKUNG Diese Aktionen werden entweder explizit als Evaluatorenaktionen angegeben oder implizit aus
Entwickleraktionen (implizite Evaluatorenaktionen) innerhalb der Vertrauenswürdigkeitskomponenten in
ISO/IEC 15408-3 abgeleitet.
3.2
Aufgabe
Anwendung einer Vertrauenswürdigkeitsklasse aus ISO/IEC 15408-3
3.3
Prüfen
auf Grundlage eines einfachen Vergleichs eine Entscheidung treffen
ANMERKUNG Fachwissen eines Evaluatoren ist nicht erforderlich. Eine Aussage, die dieses Verb verwendet,
beschreibt eine Zuordnung.
3.4
Evaluationsbeitrag
Ressource, die der Evaluator oder die Evaluierungsinstanz vom Antragsteller oder Entwickler anfordert, um
eine oder mehrere Evaluierungsaufgaben oder Evaluierungsüberwachungsaufgaben auszuführen
3.5
Evaluationsnachweis
konkreter Evaluationsbeitrag
3.6
Technischer Evaluierungsbericht
Bericht, in dem die vom Evaluator erstellte und bei einer Evaluierungsinstanz eingereichte
Gesamtentscheidung einschließlich Begründung dokumentiert ist
11
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
3.7
Untersuchen
mittels Analyse und unter Nutzung von Evaluatoren-Fachwissen eine Entscheidung treffen
ANMERKUNG Eine Aussage, die dieses Verb verwendet, nennt die analysierten Sachverhalte und die Eigenschaften,
aufgrund derer die Analyse durchgeführt wurde.
3.8
Interpretation
Klarstellung oder Erweiterung einer Anforderung aus ISO/IEC 15408, ISO/IEC 18045 oder aus dem Schema
3.9
Methodologie
System aus Vorgehensweisen, Verfahren und Prozessen, das für die IT-Sicherheitsevaluierung verwendet
wird
3.10
Beobachtungsbericht
Bericht, der vom Evaluator verfasst wird, wenn dieser während der Evaluierung eine Klarstellung benötigt
oder ein Problem identifiziert hat
3.11
Gesamtentscheidung
Urteil „akzeptiert“ oder „abgelehnt“, das ein Evaluator ausgehend vom Ergebnis einer Evaluierung fällt
3.12
Überwachungsentscheidung
Urteil, das von einer Evaluierungsinstanz gefällt wird und mit dem diese eine Gesamtentscheidung auf
Grundlage der Ergebnisse von Evaluierungsüberwachungsaufgaben bestätigt oder ablehnt
3.13
Aufzeichnen
eine Beschreibung der Verfahren, Ereignisse, Beobachtungen, Erkenntnisse und Ergebnisse schriftlich
festhalten, die so detailliert ist, dass die für die Evaluierung ausgeführten Arbeitsschritte damit zu einem
späteren Zeitpunkt rekonstruiert werden können
3.14
Berichten
Evaluierungsergebnisse und dokumentierende Angaben und Unterlagen im Technischen
Evaluierungsbericht oder einem Beobachtungsbericht zusammenstellen
3.15
Schema
Reihe von Regeln, die eine Evaluierungsinstanz zur Definition der Evaluierungsumgebung festlegt,
einschließlich der für die Durchführung von IT-Sicherheitsevaluierungen erforderlichen Kriterien und
Methodologie
3.16
Unteraufgabe
Anwendung einer Vertrauenswürdigkeitskomponente aus ISO/IEC 15408-3
ANMERKUNG Vertrauenswürdigkeitsfamilien werden in dieser Internationalen Norm nicht explizit behandelt, da

Evaluierungen an einer einzelnen Vertrauenswürdigkeitskomponente aus einer Vertrauenswürdigkeitsfamilie
durchgeführt werden.
12
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
3.17
Verfolgung
einfache direktionale Beziehung zwischen zwei Sätzen von Entitäten, die zeigt, welche Entitäten des ersten
Satzes welchen Entitäten des zweiten Satzes entsprechen
3.18
Entscheidung
Urteil „akzeptiert“, „abgelehnt“ oder „nicht bewertbar“, das ein Evaluator hinsichtlich eines
Evaluatorenaktionselements oder einer Vertrauenswürdigkeitskomponente oder -klasse fällt
ANMERKUNG Siehe auch Gesamtentscheidung.
3.19
Workunit
Ebene der kleinsten Einheiten bei der Durchführung der Evaluierung
ANMERKUNG Jede Aktion der Evaluierungsmethodologie umfasst eine oder mehrere Workunits, die innerhalb dieser
Aktion nach ihrem ISO/IEC 15408-Inhalt und Nachweisdarstellung oder dem Entwickleraktionselement gruppiert
wird/werden. Die Workunits werden in dieser Internationalen Norm in der gleichen Reihenfolge dargestellt, wie die
Elemente in ISO/IEC 15408, von denen sie abgeleitet wurden. Workunits sind am linken Rand durch eine Zeichenkette
gekennzeichnet, z. B. als „ALC_TAT.1-2“. Bei dieser Zeichenkette gibt die Zeichenfolge ALC_TAT.1 an, um welche
Komponente nach ISO/IEC 15408 es sich handelt (d. h., die Unteraufgabe in dieser Internationalen Norm), während die
letzte Ziffer (2) anzeigt, dass es sich hierbei um die zweite Workunit der Unteraufgabe ALC_TAT.1 handelt.
4 Symbole und Abkürzungen

ETR Technischer Evaluierungsbericht (en: evaluation technical report)
OR Beobachtungsbericht (en: observation report)
5 Überblick
5.1 Gliederung dieser Internationalen Norm
Abschnitt 6 definiert die in dieser Internationalen Norm verwendeten Konventionen.
Abschnitt 7 beschreibt allgemeine Evaluierungsarbeitsaufgaben, mit denen keine Entscheidungen verbunden

sind, da sie nicht auf die Evaluatorenaktionselemente nach ISO/IEC 15408 abgebildet werden.
Abschnitt 8 befasst sich mit der Arbeit, die zur Erzielung eines Evaluierungsergebnisses an einem PP
erforderlich ist.
Abschnitt 9 bis Abschnitt 15 legen die Evaluierungsaufgaben fest, die von Vertrauenswürdigkeitsklassen
organisiert werden.
Anhang A deckt die grundlegenden Evaluierungstechniken ab, die für den technischen Nachweis der
Evaluierungsergebnisse verwendet werden.
Anhang B bietet eine Erläuterung der Kriterien der Anfälligkeitsanalyse und Beispiele für deren Anwendung.
13
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
6 Typographische Konventionen
6.1 Terminologie
Im Gegensatz zur ISO/IEC 15408, bei der jedes Element die letzte Stelle seines Identifizierungssymbols für alle
Komponenten innerhalb der Familie beibehält, kann diese Internationale Norm neue Workunits einführen,
wenn ein Evaluatorenaktionselement der ISO/IEC 15408 von Unteraufgabe zu Unteraufgabe wechselt;
infolgedessen kann sich die letzte Stelle des Erkennungszeichens der Workunit ändern, obwohl die Workunit
unverändert bleibt.
Jede erforderliche methodenspezifische Durchführung der Evaluierung, die nicht direkt aus den
Anforderungen der ISO/IEC 15408 abgeleitet ist, wird als Arbeitsaufgabe oder Teilarbeitsaufgabe bezeichnet.
6.2 Verbgebrauch
Allen Verben der Workunits und der Teilarbeitsaufgaben wird das Hilfsverb muss vorangestellt, wobei sowohl
das Verb als auch muss in kursiver Fettschrift dargestellt werden. Das Hilfsverb muss wird nur verwendet,
wenn der vorgegebene Text obligatorisch ist, also nur innerhalb der Workunits und Teilarbeitsaufgaben. Die
Workunits und Teilarbeitsaufgaben enthalten obligatorische Aufgaben, die der Evaluator durchführen muss,
um Entscheidungen zu treffen.
Die Leitlinien, die mit den Workunits und Teilarbeitsaufgaben einhergehen, geben weitere Erläuterungen zur
Anwendung von Wörtern der ISO/IEC 15408 in einer Evaluierung. Der Verbgebrauch erfolgt in
Übereinstimmung mit ISO-Definitionen für diese Verben. Das Hilfsverb sollte wird verwendet, wenn das
beschriebene Verfahren stark bevorzugt wird. Alle anderen Hilfsverben, einschließlich dürfen, werden dort
verwendet, wo das/die beschriebene(n) Verfahren erlaubt, aber weder empfohlen noch stark bevorzugt
wird/werden; es handelt sich lediglich um eine Erläuterung.
Die Verben prüfen, untersuchen, berichten und aufzeichnen werden mit einer genauen Bedeutung innerhalb
dieses Teils dieser Internationalen Norm verwendet, und Abschnitt 3 sollte für deren Definitionen
herangezogen werden.
6.3 Allgemeine Evaluierungsleitlinien
Material, das auf mehr als eine Unteraufgabe anwendbar ist, wird an einer Stelle erfasst. Leitlinien, deren
Anwendbarkeit weit verbreitet ist (über alle Aufgaben und EALs hinweg), wurden in Anhang A erfasst.
Leitlinien, die sich auf mehrere Unteraufgaben innerhalb einer einzigen Aufgabe beziehen, wurden in der
Einleitung zu dieser Aufgabe bereitgestellt. Beziehen sich Leitlinien nur auf eine einzelne Unteraufgabe,
werden sie innerhalb dieser Unteraufgabe dargestellt.
6.4 Beziehung zwischen den Strukturen von ISO/IEC 15408 und ISO/IEC 18045
Es gibt direkte Beziehungen zwischen der Struktur von ISO/IEC 15408 (d. h. Klasse, Familie, Komponente und
Element) und der Struktur dieser Internationalen Norm. Bild 1 veranschaulicht die Entsprechung zwischen
den Konstrukten von ISO/IEC 15408 von Klasse, Familie und Evaluatorenaktionselementen sowie den
Aufgaben, Unteraufgaben und Aktionen der Evaluierungsmethodik. Aus den in der ISO/IEC 15408 genannten
Anforderungen an das Entwickleraktionselement und den Inhalt und die Nachweisdarstellung können sich
jedoch mehrere Workunits zur Evaluierungsmethodik ergeben.
14
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Bild 1 — Abbildung der Strukturen von ISO/IEC 15408 und ISO/IEC 18045
7 Evaluierungsprozess und damit verbundene Arbeitsaufgaben
7.1 Einleitung
Dieser Abschnitt gibt einen Überblick über den Evaluierungsprozess und definiert die Aufgaben, die ein
Evaluator bei der Durchführung einer Evaluierung durchführen soll.
Jede Evaluierung, ob eines PP oder TOE (einschließlich ST), folgt dem gleichen Prozess und hat vier
Evaluierungsarbeitsaufgaben gemeinsam: die Eingabearbeitsaufgabe, die Ausgabearbeitsaufgabe, die
Evaluierungsunteraufgaben und die Vorführung der technischen Kompetenz gegenüber der Arbeitsaufgabe
der Evaluierungsinstanz.
Die Eingabearbeitsaufgabe und die Ausgabearbeitsaufgaben, die mit dem Management der Evaluations-
nachweise und der Berichtserstellung zusammenhängen, werden in diesem Abschnitt vollständig
beschrieben. Jede Arbeitsaufgabe hat zugehörige Teilarbeitsaufgaben, die für alle Evaluierungen der
ISO/IEC 15408 (Evaluierung eines PP oder eines TOE) gelten und für diese normativ sind.
Die Evaluierungsunteraufgaben werden in diesem Abschnitt nur angeschnitten und in den folgenden
Abschnitten ausführlich beschrieben.
Im Gegensatz zu den Evaluierungsunteraufgaben sind mit den Eingabe- und Ausgabearbeitsaufgaben keine
Entscheidungen verbunden, da sie nicht auf die Evaluatorenaktionselemente der ISO/IEC 15408 abbilden; sie
werden durchgeführt, um die Übereinstimmung mit den universellen Grundsätzen und die Einhaltung dieser
Internationalen Norm sicherzustellen.
Die Vorführung der technischen Kompetenz gegenüber der Arbeitsaufgabe der Evaluierungsinstanz kann
durch die Analyse der Ausgabeergebnisse der Arbeitsaufgaben der Evaluierungsinstanz erbracht werden,
oder es kann die Vorführung enthalten sein, dass die Evaluatoren die Eingaben für die Unteraufgaben der
Evaluierung verstanden haben. Mit dieser Arbeitsaufgabe ist keine Evaluator-Entscheidung verbunden,
sondern eine Entscheidung der Evaluatorinstanz. Die detaillierten Kriterien zur Absolvierung dieser
Arbeitsaufgabe liegen im Ermessen der Evaluierungsinstanz, wie in Anhang 0 angegeben.
15
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
7.2 Überblick über den Evaluierungsprozess
7.2.1 Zielsetzungen
Dieser Unterabschnitt stellt das allgemeine Modell der Methodik dar und legt Folgendes fest:
a) Rollen und Verantwortlichkeiten der in den Evaluierungsprozess einbezogenen Parteien;
b) das allgemeine Evaluierungsmodell.
7.2.2 Verantwortlichkeiten der Rollen
Das allgemeine Modell legt die folgenden Rollen fest: Antragsteller, Entwickler, Evaluator und
Evaluierungsinstanz.
Der Antragsteller ist für die Antragstellung und Unterstützung einer Evaluierung verantwortlich. Dies
bedeutet, dass der Antragsteller die verschiedenen Vereinbarungen für die Evaluierung (z. B. die Beauftragung
der Evaluierung) trifft. Darüber hinaus ist der Antragsteller dafür verantwortlich, dass dem Evaluator die
Evaluationsnachweise zur Verfügung gestellt werden.
Der Entwickler erstellt den TOE und ist dafür verantwortlich, im Auftrag des Antragstellers die für die
Evaluierung erforderlichen Nachweise (z. B. Schulung, Designinformationen) zu erbringen.
Der Evaluator führt die im Zusammenhang mit einer Evaluierung erforderlichen Evaluierungsarbeitsaufgaben
aus: Der Evaluator erhält die Evaluationsnachweise vom Entwickler im Namen des Antragstellers oder direkt
vom Antragsteller, führt die Evaluierungsunteraufgaben durch und stellt die Ergebnisse der
Evaluierungsbeurteilung der Evaluierungsinstanz zur Verfügung.
Die Evaluierungsinstanz erstellt und pflegt das Schema, überwacht die vom Evaluator durchgeführte
Evaluierung und stellt auf der Grundlage der vom Evaluator gelieferten Evaluierungsergebnisse
Zertifizierungs-/Validierungsberichte sowie Zertifikate aus.
7.2.3 Beziehung der Rollen
Um zu verhindern, dass eine Evaluierung durch ungebührliche Einflussnahme unzulässig beeinflusst wird, ist
eine gewisse Trennung der Rollen erforderlich. Dies bedeutet, dass die oben beschriebenen Rollen von
verschiedenen Entitäten erfüllt werden, mit der Ausnahme, dass die Rollen des Entwicklers und Antragstellers
von einer einzigen Entität erfüllt werden können.
Darüber hinaus erfordern einige Evaluierungen (z. B. die EAL1-Evaluierung) möglicherweise nicht, dass der
Entwickler in das Projekt einbezogen wird. In diesem Fall ist es der Antragsteller, der dem Evaluator den TOE
zur Verfügung stellt und den Evaluationgsnachweis erstellt.
7.2.4 Allgemeines Evaluierungsmodell
Der Evaluierungsprozess besteht aus dem Evaluator, der die Eingabearbeitsaufgabe der Evaluierung, die
Ausgabearbeitsaufgabe der Evaluierung und die Evaluierungsunteraufgaben durchführt. Bild 2 vermittelt
einen Überblick über die Beziehung zwischen diesen Arbeitsaufgaben und Unteraufgaben.
16
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Bild 2 — Generisches Evaluierungsmodell
Dem Evaluierungsprozess kann eine Vorbereitungsphase vorausgehen, in der ein erster Kontakt zwischen
dem Antragsteller und dem Evaluator hergestellt wird. Die Arbeit, die in dieser Phase geleistet wird, und die
Einbeziehung der verschiedenen Rollen kann unterschiedlich sein. In der Regel führt der Evaluator während
dieses Schritts eine Durchführbarkeitsanalyse durch, um die Wahrscheinlichkeit einer erfolgreichen
Evaluierung zu beurteilen.
7.2.5 Evaluatoren-Entscheidungen
Der Evaluator ordnet die Entscheidungen den Anforderungen der ISO/IEC 15408 und nicht denen dieser
Internationalen Norm zu. Die kleinste Einheit der Struktur der ISO/IEC 15408, der eine Entscheidung
zugeordnet wird, ist das Evaluatorenaktionselement (explizit oder implizit). Eine Entscheidung wird einem
zutreffenden Evaluatorenaktionselement der ISO/IEC 15408 als Ergebnis der Durchführung der
entsprechenden Aktion der Evaluierungsmethodik und der Workunits zugeordnet, aus denen sie besteht.
Schließlich wird ein Evaluierungsergebnis zugeordnet, wie in ISO/IEC 15408-1, Abschnitt 9, Evaluierungs-
ergebnisse, beschrieben.
17
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Bild 3 — Beispiel der Entscheidungszuordnungsregel
Diese Internationale Norm erkennt drei sich gegenseitig ausschließende Entscheidungszustände an:
a) Die Bedingungen für eine „akzeptiert“-Entscheidung sind definiert als die Vervollständigung des
Evaluatorenaktionselements der ISO/IEC 15408 durch den Evaluator und die Feststellung, dass die
Anforderungen an das/die zu evaluierende PP, ST oder den TOE erfüllt sind. Die Bedingungen für die
Übergabe des Elements sind definiert als:
1) die einzelnen Workunits der entsprechenden Aktion der Evaluierungsmethodologie, und
2) alle für die Durchführung dieser Workunits erforderlichen Evaluationsnachweise sind einheitlich,
d. h. sie können vom Evaluator vollständig verstanden werden, und
3) alle für die Durchführung dieser Workunits erforderlichen Evaluationsnachweise weisen keine
offensichtlichen internen Inkonsistenzen oder Widersprüche zu anderen Evaluationsnachweisen auf.
Es ist zu beachten, dass hier offensichtlich bedeutet, dass der Evaluator diese Inkonsistenz bei der
Durchführung der Workunits entdeckt: Der Evaluator sollte nicht jedes Mal, wenn eine Workunit
durchgeführt wird, eine vollständige Konsistenzanalyse über die gesamten Evaluationsnachweise
hinweg durchführen;
b) Die Bedingungen für eine „abgelehnt“-Entscheidung sind definiert als eine Vervollständigung des
Evaluatorenaktionselements der ISO/IEC 15408 durch den Evaluator und die Feststellung, dass die
Anforderungen an das/die zu evaluierende PP, ST oder den TOE nicht erfüllt sind oder eine offensichtliche
Inkonsistenz in den Evaluationsnachweisen festgestellt wurde;
c) Alle Entscheidungen sind zunächst nicht bewertbar und bleiben so lange bestehen, bis entweder eine
„akzeptiert“- oder „abgelehnt“-Entscheidung zugewiesen wird.
Die Gesamtentscheidung ist genau dann „akzeptiert“, wenn sämtliche einzelnen Entscheidungen auch
„akzeptiert“ sind. Wenn in dem in Bild 3 dargestellten Beispiel die Entscheidung für ein
Evaluatorenaktionselement „abgelehnt“ ist, sind auch die Entscheidungen für die entsprechende Vertrauens-
würdigkeitskomponente, die Vertrauenswürdigkeitsklasse und die Gesamtentscheidung „abgelehnt“.
18
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
7.3 Eingabearbeitsaufgabe der Evaluierung
7.3.1 Zielsetzungen
Die Zielsetzung dieser Arbeitsaufgabe ist es, sicherzustellen, dass der Evaluator über die richtige Version der
für die Evaluierung erforderlichen Evaluationsnachweise verfügt und dass diese angemessen geschützt sind.
Andernfalls kann weder die technische Genauigkeit der Evaluierung noch die Wiederholbarkeit und
Reproduzierbarkeit der Ergebnisse der Evaluierung sichergestellt werden.
7.3.2 Anwendungshinweise
Die Verantwortung für die Bereitstellung aller erforderlichen Evaluationsnachweise liegt beim Antragsteller.
Jedoch werden wahrscheinlich die meisten Evaluationsnachweise vom Entwickler im Auftrag des
Antragstellers erstellt und geliefert.
Da die Vertrauenswürdigkeitsanforderungen für den gesamten TOE gelten, sind dem Evaluator alle
Evaluationsnachweise, die sich auf alle Teile des TOEs beziehen, zur Verfügung zu stellen. Der Umfang und der
erforderliche Inhalt solcher Evaluationsnachweise ist unabhängig von dem Grad der Kontrolle, die der
Entwickler über jeden der Teile des TOEs hat. Wenn zum Beispiel ein Design erforderlich ist, dann gelten die
Anforderungen des „TOE design“ (ADV_TDS) für alle Teilsysteme, die Teil der TSF sind. Darüber hinaus gelten
Vertrauenswürdigkeitsanforderungen, die vorhandene Verfahren erfordern (z. B. „CM capabilities“
(ALC_CMC) und „Delivery“ (ALC_DEL)), auch für den gesamten TOE (einschließlich aller Teile, die von einem
anderen Entwickler hergestellt wurden).
Es wird empfohlen, dass der Evaluator in Zusammenarbeit mit dem Antragsteller einen Index zu den
erforderlichen Evaluationsnachweisen erstellt. Dieser Index kann eine Menge Verweisungen auf die
Dokumentation sein. Dieser Index sollte genügend Informationen enthalten (z. B. eine kurze
Zusammenfassung jedes Dokuments oder zumindest einen expliziten Titel, die Angabe der relevanten
Unterabschnitte), damit der Evaluator die erforderlichen Nachweise leicht findet.
Erforderlich sind die in den Evaluationsnachweisen enthaltenen Informationen, nicht eine bestimmte
Dokumentenstruktur. Der Evaluationsnachweis für eine Unteraufgabe kann durch getrennte Dokumente
erbracht werden, oder ein einziges Dokument kann mehrere der Eingabeanforderungen einer Unteraufgabe
erfüllen.
Der Evaluator benötigt stabile und offiziell herausgegebene Versionen der Evaluationsnachweise. Der Entwurf
eines Evaluationsnachweises kann jedoch während einer Evaluierung vorgelegt werden, z. B. um einem
Evaluator eine frühzeitige, informelle Beurteilung zu ermöglichen, dieser wird aber nicht als Grundlage für
Entscheidungen verwendet. Es kann für den Evaluator hilfreich sein, Entwürfe von besonders geeigneten
Evaluationsnachweisen zu sehen, wie z. B.
a) eine Prüfdokumentation, um dem Evaluator eine frühzeitige Beurteilung von Prüfungen und
Prüfverfahren zu ermöglichen;
b) Designunterlagen, um dem Evaluator den Hintergrund für das Verständnis des TOEs-Designs zu
vermitteln:
c) Quellcode oder Hardware-Zeichnungen, damit der Evaluator die Anwendung der Normen des Entwicklers
beurteilen kann.
Der Entwurf eines Evaluationsnachweises wird mit größerer Wahrscheinlichkeit dann angetroffen, wenn die
Evaluierung eines TOEs gleichzeitig mit seiner Entwicklung durchgeführt wird. Er kann jedoch auch während
der Evaluierung eines bereits entwickelten TOEs auftreten, wenn der Entwickler zusätzliche Arbeiten
durchführen musste, um ein vom Evaluator erkanntes Problem zu beheben (z. B. um einen Fehler im Design
oder in der Implementierung zu beheben) oder um einen Evaluationsnachweis für die Sicherheit zu erbringen,
der nicht in der vorhandenen Dokumentation enthalten ist (z. B. im Fall eines TOE, der ursprünglich nicht
entwickelt wurde, um die Anforderungen der ISO/IEC 15408 zu erfüllen).
19
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
7.3.3 Management der Teilarbeitsaufgabe der Evaluationsnachweise
7.3.3.1 Konfigurationsüberwachung
Der Evaluator muss die Konfigurationsüberwachung der Evaluationsnachweise durchführen.
Die ISO/IEC 15408 impliziert, dass der Evaluator in der Lage ist, jeden Evaluationsnachweis nach dessen
Erhalt zu identifizieren und zu lokalisieren und festzustellen, ob sich eine bestimmte Version eines Dokuments
im Besitz des Evaluators befindet.
Der Evaluator muss die Evaluationsnachweise vor Änderungen oder Verlust schützen, solange sie sich im
Besitz des Evaluators befinden.
7.3.3.2 Beseitigung
Es kann sein, dass Schemata die Beseitigung von Evaluationsnachweisen am Ende einer Evaluierung
kontrollieren wollen. Die Beseitigung der Evaluationsnachweise sollte durch einen oder mehrere folgender
Punkte erreicht werden:
a) Rückgabe der Evaluationsnachweise;
b) Archivierung der Evaluationsnachweise;
c) Vernichtung der Evaluationsnachweise.
7.3.3.3 Vertraulichkeit
Ein Evaluator kann Zugriff auf kommerziell sensible Informationen des Antragstellers und des Entwicklers
haben (z. B. Informationen über das TOE-Design, spezielle Instrumente), und er kann während des Verlaufs
einer Evaluierung Zugriff auf national sensible Informationen haben. Es kann sein, dass Schemata
Anforderungen an den Evaluator stellen wollen, um die Vertraulichkeit der Evaluationsnachweise zu wahren.
Antragsteller und Evaluator können sich gegenseitig auf zusätzliche Anforderungen einigen, solange diese
gegenüber dem Schema konsistent sind.
Die Anforderungen an die Vertraulichkeit betreffen viele Aspekte bei der Durchführung der Evaluierung,
einschließlich der Entgegennahme, Handhabung, Lagerung und Beseitigung von Evaluationsnachweisen.
7.4 Evaluierungsunteraufgaben
Die Evaluierungsunteraufgaben unterscheiden sich je nachdem, ob es sich um eine PP- oder eine
TOE-Evaluierung handelt. Darüber hinaus hängen im Fall einer TOE-Evaluierung die Unteraufgaben von den
gewählten Vertrauenswürdigkeitsanforderungen ab.
7.5 Ausgabearbeitsaufgabe der Evaluierung
7.5.1 Zielsetzungen
Die Zielsetzung dieses Unterabschnitts ist es, den Beobachtungsbericht (OR) und den Technischen
Evaluierungsbericht (ETR) zu beschreiben. Die Schemata können zusätzliche Berichte des Evaluatoren, wie
z. B. Berichte über einzelne Workunits, oder zusätzliche Informationen im OR und im ETR verlangen. Diese
Internationale Norm schließt die zusätzliche Aufnahme von Informationen in diese Berichte nicht aus, da diese
Internationale Norm nur den Mindestinformationsgehalt festlegt.
Eine konsistente Berichterstattung über die Evaluierungsergebnisse erleichtert das Erreichen des
universellen Prinzips der Wiederholbarkeit und Reproduzierbarkeit der Ergebnisse. Die Konsistenz umfasst
die Art und den Umfang der im ETR und OR gemeldeten Informationen. Die Konsistenz von ETR und OR
zwischen den verschiedenen Evaluierungen liegt in der Verantwortung der Evaluierungsinstanz.
20
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator führt die beiden folgenden Teilarbeitsaufgaben durch, um die Anforderungen dieser
Internationalen Norm an den Informationsgehalt von Berichten zu erfüllen:
a) OR-Teilarbeitsaufgabe schreiben (falls im Zusammenhang mit der Evaluierung benötigt);
b) ETR-Teilarbeitsaufgabe schreiben.
7.5.2 Management der Evaluierungsausgaben
Der Evaluator liefert den ETR an die Evaluierungsinstanz sowie alle OR, sobald sie verfügbar sind. Die
Anforderungen an die Kontrolle des Umgangs mit dem ETR und den OR werden durch das Schema festgelegt,
das auch die Lieferung an den Antragsteller oder Entwickler umfassen kann. Der ETR und die OR können
sensible oder geschützte Informationen enthalten und müssen möglicherweise vor der Weitergabe an den
Antragsteller zensiert werden.
7.5.3 Anwendungshinweise
In dieser Version dieser Internationalen Norm wurden die Anforderungen an die Bereitstellung von
Evaluationsnachweisen zur Unterstützung der Neubewertung und Wiederverwendung nicht explizit
angegeben. Wenn der Antragsteller Informationen zur Neubewertung oder Wiederverwendung benötigt,
sollte das Schema, nach dem die Evaluierung durchgeführt wird, konsultiert werden.
7.5.4 OR-Teilarbeitsaufgabe schreiben
Die OR bieten dem Evaluator einen Mechanismus, mit dem er eine Klarstellung (z. B. von der Evaluierungs-
instanz über die Anwendung einer Anforderung) oder die Ermittlung eines Problems mit einem Aspekt der
Evaluierung anfragt.
Im Falle einer ablehnenden Entscheidung muss der Evaluator einen OR vorlegen, der das Evaluierungs-
ergebnis widerspiegelt. Andernfalls kann der Evaluator die OR als eine Möglichkeit nutzen, um den
Klärungsbedarf auszudrücken.
Bei jedem OR muss der Evaluator Folgendes angeben:
a) den Bezeichner des evaluierten PP oder TOE;
b) die Evaluierungsarbeitsaufgabe/-Unteraufgabe, während der die Beobachtung gemacht wurde;
c) die Beobachtung;
d) die Beurteilung ihres Schweregrades (z. B. impliziert eine ablehnende Entscheidung, verzögert den
Fortschritt der Evaluierung, erfordert eine Lösung vor Abschluss der Evaluierung);
e) die Identifizierung der für die Lösung des Problems verantwortlichen Organisation;
f) den empfohlenen Zeitplan für die Lösung;
g) die Beurteilung der Auswirkung auf die Evaluierung des Versäumnisses, die Beobachtung zu lösen.
Die angesprochene Zielgruppe eines OR und Verfahren zur Handhabung des Berichts hängen von der Art des
Berichtsinhalts und vom Schema ab. Die Schemata können verschiedene Arten von OR unterscheiden oder
zusätzliche Typen definieren, mit den damit verbundenen Unterschieden bei den erforderlichen
Informationen und der Verteilung (z. B. Evaluierungs-OR an Evaluierungsinstanzen und Antragsteller).
21
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
7.5.5 ETR-Teilarbeitsaufgabe schreiben
7.5.5.1 Zielsetzungen
Der Evaluator muss einen ETR bereitstellen, um die technische Begründung der Entscheidungen vorzulegen.
Diese Internationale Norm definiert die Mindestanforderung an den Inhalt des ETR; die Schemata können
jedoch zusätzliche Inhalte und spezifische Anforderungen an die Darstellung und Struktur festlegen. Beispiels-
weise können die Schemata verlangen, dass bestimmte einleitende Ausführungen (z. B. Haftungsausschlüsse
und Urheberrechtshinweise) im ETR gemeldet werden.
Es wird davon ausgegangen, dass der Leser des ETR mit den allgemeinen Konzepten der IT-Sicherheit, der
ISO/IEC 15408, dieser Internationalen Norm, den Evaluierungsansätzen und der IT vertraut ist.
Der ETR unterstützt die Evaluierungsinstanz bei der Bestätigung, dass die Evaluierung nach der geforderten
Norm durchgeführt wurde, aber es wird erwartet, dass die dokumentierten Ergebnisse möglicherweise nicht
alle erforderlichen Informationen enthalten, so dass zusätzliche, vom Schema speziell angefragte
Informationen erforderlich sein können. Dieser Aspekt liegt außerhalb des Anwendungsbereichs dieser
Internationalen Norm.
7.5.5.2 ETR für eine PP-Evaluierung
In diesem Unterabschnitt wird der Mindestinhalt des ETR für eine PP-Evaluierung beschrieben. Der Inhalt des
ETR ist in Bild 4 dargestellt; dieses Bild kann als Anleitung beim Aufbau der Struktur des ETR-Dokuments
verwendet werden.
Bild 4 — ETR-Informationsgehalt für eine PP-Evaluierung
22
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
7.5.5.2.1 Einleitung
Der Evaluator muss die Schemabezeichner der Evaluierung angeben.
Schemabezeichner der Evaluierung (z. B. Logos) sind die Informationen, die erforderlich sind, um das für die
Überwachung der Evaluierung verantwortliche Schema eindeutig zu identifizieren.
Der Evaluator muss die ETR-Bezeichner der Konfigurationsüberwachung angeben.
Die ETR-Bezeichner der Konfigurationsüberwachung enthalten Informationen, die den ETR identifizieren
(z. B. Name, Datum und Versionsnummer).
Der Evaluator muss die PP-Bezeichner der Konfigurationsüberwachung angeben.
PP-Bezeichner der Konfigurationsüberwachung (z. B. Name, Datum und Versionsnummer) sind erforderlich,
um zu identifizieren, was evaluiert wird, damit die Evaluierungsinstanz überprüfen kann, ob die
Entscheidungen vom Evaluator korrekt zugeordnet wurden.
Der Evaluator muss die Identität des Entwicklers angeben.
Die Identität des PP-Entwicklers wird benötigt, um die verantwortliche Partei für die Erstellung des PP zu
identifizieren.
Der Evaluator muss die Identität des Antragstellers angeben.
Die Identität des Antragstellers wird benötigt, um die verantwortliche Partei zu identifizieren, die für die
Bereitstellung von Evaluationsnachweisen für den Evaluator verantwortlich ist.
Der Evaluator muss die Identität des Evaluators angeben.
Die Identität des Evaluators wird benötigt, um die Partei zu identifizieren, die die Evaluierung durchführt und
für die Evaluierungsentscheidungen verantwortlich ist.
7.5.5.2.2 Evaluierung
Der Evaluator muss die Evaluierungsverfahren, -techniken, -instrumente und angewandten Normen
angeben.
Der Evaluator verweist auf die Evaluierungskriterien, die Methodik und die Interpretationen, die zur
Evaluierung des PP verwendet wurden.
Der Evaluator muss alle Einschränkungen bei der Evaluierung, Einschränkungen bei der Handhabung der
Evaluierungsergebnisse und Annahmen angeben, die während der Evaluierung getroffen wurden und sich
auf die Evaluierungsergebnisse auswirken.
Der Evaluator kann Informationen in Bezug auf rechtliche oder gesetzliche Aspekte, Organisation,
Vertraulichkeit usw. einbeziehen.
7.5.5.2.3 Ergebnisse der Evaluierung
Der Evaluator muss eine Entscheidung und eine unterstützende Begründung für jede Vertrauenswürdigkeits-
komponente angeben, die eine APE-Aufgabe ausmacht, als Ergebnis der Durchführung der entsprechenden
Aktion der Evaluierungsmethodik und der Workunits, aus denen sie besteht.
Die Begründung legt die Entscheidung unter Verwendung der ISO/IEC 15408, dieser Internationalen Norm,
etwaiger Interpretationen und der untersuchten Evaluationsnachweise dar und zeigt, wie die
Evaluationsnachweise jeden Aspekt der Kriterien erfüllen oder nicht. Sie enthält eine Beschreibung der
ausgeführten Arbeiten, der angewandten Verfahren und jede Herleitung von Ergebnissen. Die Begründung
kann bis auf die Ebene einer Workunit der Evaluierungsmethodik detailliert sein.
23
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
7.5.5.2.4 Schlussfolgerungen und Empfehlungen
Der Evaluator muss die Schlussfolgerungen der Evaluierung, insbesondere die Gesamtentscheidung angeben,
wie in ISO/IEC 15408-1 Abschnitt 9, Evaluierungsergebnisse, festgelegt, und durch die Anwendung der
in 7.2.5 beschriebenen Entscheidungszuordnung bestimmt.
Der Evaluator gibt Empfehlungen, die für die Evaluierungsinstanz hilfreich sein können. Diese Empfehlungen
können Defizite des PP, die bei der Evaluierung festgestellt wurden, oder die Erwähnung von besonders
nützlichen Funktionen beinhalten.
7.5.5.2.5 Liste der Evaluationsnachweise
Der Evaluator muss für jeden einzelnen Evaluationsnachweis die folgenden Informationen angeben:
die Ausgabestelle (z. B. der Entwickler, der Antragsteller);
den Titel;
die eindeutige Verweisung (z. B. Ausgabedatum und Versionsnummer).
7.5.5.2.6 Liste der Akronyme/Glossar der Begriffe
Der Evaluator muss sämtliche im ETR verwendeten Akronyme oder Abkürzungen angeben:
Von ISO/IEC 15408 oder dieser Internationalen Norm bereits festgelegte Glossardefinitionen müssen im ETR
nicht wiederholt werden.
7.5.5.2.7 Beobachtungsberichte
Der Evaluator muss eine vollständige Liste angeben, aus der die bei der Evaluierung erhobenen OR und ihr
Status eindeutig hervorgehen.
Für jeden OR sollte die Liste dessen Bezeichner sowie seinen Titel oder eine kurze Zusammenfassung seines
Inhalts enthalten.
7.5.5.3 ETR für eine TOE-Evaluierung
In diesem Unterabschnitt wird der Mindestinhalt des ETR für eine TOE-Evaluierung beschrieben. Der Inhalt
des ETR ist in Bild 5 dargestellt; dieses Bild kann als Leitfaden beim Aufbau der Struktur des ETR-Dokuments
verwendet werden.
24
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Bild 5 — ETR-Informationsgehalt für eine TOE-Evaluierung
7.5.5.3.1 Einleitung
Der Evaluator muss die Schemabezeichner der Evaluierung angeben.
Schemabezeichner der Evaluierung (z. B. Logos) sind die Informationen, die erforderlich sind, um das für die
Überwachung der Evaluierung verantwortliche Schema eindeutig zu identifizieren.
Der Evaluator muss die ETR-Bezeichner der Konfigurationsüberwachung angeben.
Die ETR-Bezeichner der Konfigurationsüberwachung enthalten Informationen, die den ETR identifizieren
(z. B. Name, Datum und Versionsnummer).
Der Evaluator muss die ST- und TOE-Bezeichner der Konfigurationsüberwachung angeben.
ST- und TOE-Bezeichner der Konfigurationsüberwachung identifizieren, was evaluiert wird, damit die
Evaluierungsinstanz überprüfen kann, ob die Entscheidungen vom Evaluator korrekt zugeordnet wurden.
Wenn die ST beansprucht, dass der TOE mit den Anforderungen eines oder mehrerer PPs übereinstimmt,
muss der ETR die Verweisung der entsprechenden PPs melden.
Die PP-Verweisung enthält Informationen, die die PPs eindeutig identifizieren (z. B. Titel, Datum und
Versionsnummer).
25
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss die Identität des Entwicklers angeben.
Die Identität des TOEs-Entwicklers wird benötigt, um die verantwortliche Partei für die Erstellung des TOEs
zu identifizieren.
Der Evaluator muss die Identität des Antragstellers angeben.
Die Identität des Antragstellers wird benötigt, um die verantwortliche Partei zu identifizieren, die für die
Bereitstellung von Evaluationsnachweisen für den Evaluator verantwortlich ist.
Der Evaluator muss die Identität des Evaluators angeben.
Die Identität des Evaluators wird benötigt, um die Partei zu identifizieren, die die Evaluierung durchführt und
für die Evaluierungsentscheidungen verantwortlich ist.
7.5.5.3.2 Beschreibung der Architektur des TOEs
Der Evaluator muss, soweit zutreffend, eine allgemeine Beschreibung des TOEs und seiner
Hauptkomponenten auf der Grundlage der in der ISO/IEC 15408 Vertrauenswürdigkeitsfamilie
beschriebenen Evaluationsnachweise mit dem Titel „TOE design“ (ADV_TDS) angeben.
Ziel dieses Unterabschnitts ist es, den Grad der architektonischen Trennung der Hauptkomponenten zu
charakterisieren. Wenn es keine Anforderung „TOE design“ (ADV_TDS) in der ST gibt, ist dies nicht anwendbar
und gilt als erfüllt.
7.5.5.3.3 Evaluierung
Der Evaluator muss die Evaluierungsverfahren, -techniken, -instrumente und angewandten Normen
angeben.
Der Evaluator darf auf die Evaluierungskriterien, die Methodik und die Interpretationen verweisen, die zur
Evaluierung des TOEs oder der zur Durchführung der Prüfungen verwendeten Geräte verwendet werden.
Der Evaluator muss alle Einschränkungen bei der Evaluierung, Einschränkungen bei der Verteilung der
Evaluierungsergebnisse und Annahmen angeben, die während der Evaluierung getroffen wurden und sich
auf die Evaluierungsergebnisse auswirken.
Der Evaluator kann Informationen in Bezug auf rechtliche oder gesetzliche Aspekte, Organisation,
Vertraulichkeit usw. einbeziehen.
7.5.5.3.4 Ergebnisse der Evaluierung
Für jede Aufgabe, bei der der TOE evaluiert wird, muss der Evaluator Folgendes angeben:
die Bezeichnung der in Betracht gezogenen Aufgabe;
eine Entscheidung und eine unterstützende Begründung für jede Vertrauenswürdigkeitskomponente, die
diese Aufgabe ausmacht, als Ergebnis der Durchführung der entsprechenden Aktion der Evaluierungs-
methodik und der Workunits, aus denen sie besteht.
Die Begründung legt die Entscheidung unter Verwendung der ISO/IEC 15408, dieser Internationalen Norm,
etwaiger Interpretationen und der untersuchten Evaluationsnachweise dar und zeigt, wie die Evaluations-
nachweise jeden Aspekt der Kriterien erfüllen oder nicht. Sie enthält eine Beschreibung der ausgeführten
Arbeiten, der angewandten Verfahren und jede Herleitung von Ergebnissen. Die Begründung kann bis auf die
Ebene einer Workunit der Evaluierungsmethodik detailliert sein.
Der Evaluator muss sämtliche Informationen angeben, die von einer Workunit speziell benötigt werden.
Für die AVA- und ATE-Aufgaben wurden Workunits festgelegt, die die im ETR anzugebenden Informationen
bestimmen.
26
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
7.5.5.3.5 Schlussfolgerungen und Empfehlungen
Der Evaluator muss die Schlussfolgerungen der Evaluierung angeben, die sich darauf beziehen, ob der TOE
seine zugehörige ST erfüllt hat, insbesondere die Gesamtentscheidung nach ISO/IEC 15408-1 Abschnitt 9,
Evaluierungsergebnisse, die durch die Anwendung der in 7.2.5 beschriebenen Entscheidungszuordnung
bestimmt wird.
Der Evaluator gibt Empfehlungen, die für die Evaluierungsinstanz hilfreich sein können. Diese Empfehlungen
können Defizite des IT-Produkts, die bei der Evaluierung festgestellt wurden, oder die Erwähnung von
besonders nützlichen Funktionen beinhalten.
7.5.5.3.6 Liste der Evaluationsnachweise
Der Evaluator muss für jeden einzelnen Evaluationsnachweis die folgenden Informationen angeben:
die Ausgabestelle (z. B. der Entwickler, der Antragsteller);
den Titel;
die eindeutige Verweisung (z. B. Ausgabedatum und Versionsnummer).
7.5.5.3.7 Liste der Akronyme/Glossar der Begriffe
Der Evaluator muss sämtliche im ETR verwendeten Akronyme oder Abkürzungen angeben:
Von ISO/IEC 15408 oder dieser Internationalen Norm bereits festgelegte Glossardefinitionen müssen im ETR
nicht wiederholt werden.
7.5.5.3.8 Beobachtungsberichte
Der Evaluator muss eine vollständige Liste angeben, aus der die bei der Evaluierung erhobenen OR und ihr
Status eindeutig hervorgehen.
Für jeden OR sollte die Liste dessen Bezeichner sowie seinen Titel oder eine kurze Zusammenfassung seines
Inhalts enthalten.
8 Klasse APE: Evaluierung des Schutzprofils
8.1 Einleitung
In diesem Abschnitt wird die Evaluierung eines PP beschrieben. Die Anforderungen und die Methodik der
PP-Evaluierung sind für jede PP-Evaluierung identisch, unabhängig von der EAL (oder anderen
Anforderungen an die Vertrauenswürdigkeit), die im PP beansprucht wird. Die Evaluierungsmethodik in
diesem Abschnitt basiert auf den Anforderungen an das PP, wie in ISO/IEC 15408-3, Klasse APE festgelegt.
Dieser Abschnitt sollte zusammen mit Anhang A, Anhang B und Anhang C, Leitlinien für Operationen, in
ISO/IEC 15408-1 verwendet werden, da diese Anhänge die Begriffe hier verdeutlichen und viele Beispiele
liefern.
27
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
8.2 Anwendungshinweise
8.2.1 Wiederverwendung der Evaluierungsergebnisse von zertifizierten PPs
Bei der Evaluierung eines PP, das auf einem oder mehreren zertifizierten PPs basiert, kann es möglich sein,
die Tatsache, dass diese PPs zertifiziert wurden, wieder zu verwenden. Das Potential für die Wieder-
verwendung des Ergebnisses eines zertifizierten PPs ist größer, wenn das zu evaluierende PP keine
zusätzlichen Bedrohungen, OSPs, Sicherheitszielsetzungen und/oder Sicherheitsanforderungen zu denen des
PP, dessen Konformität beansprucht wird, enthält. Wenn das zu evaluierende PP wesentlich mehr als das
zertifizierte PP enthält, ist eine Wiederverwendung möglicherweise überhaupt nicht sinnvoll.
Dem Evaluator ist es gestattet, die Ergebnisse der PP-Evaluierung wiederzuverwenden, indem er bestimmte
Analysen nur teilweise oder gar nicht durchführt, wenn diese Analysen oder Teile davon bereits im Rahmen
der PP-Evaluierung durchgeführt wurden. Dabei sollte der Evaluator davon ausgehen, dass die Analysen im
PP korrekt durchgeführt wurden.
Ein Beispiel wäre, wenn das PP, dessen Konformität beansprucht wird, eine Menge Sicherheitsanforderungen
enthält und diese bei der Evaluierung als in sich konsistent bestimmt wurden. Wenn das zu evaluierende PP
genau die gleichen Anforderungen verwendet, muss die Konsistenzanalyse bei der PP-Evaluierung nicht
wiederholt werden. Wenn das zu evaluierende PP eine oder mehrere Anforderungen hinzufügt oder
Operationen auf diese Anforderungen durchführt, muss die Analyse wiederholt werden. Es kann jedoch
möglich sein, bei dieser Konsistenzanalyse Arbeit zu sparen, indem die Tatsache genutzt wird, dass die
ursprünglichen Anforderungen in sich konsistent sind. Wenn die ursprünglichen Anforderungen in sich
konsistent sind, muss der Evaluator nur feststellen, dass:
a) die Menge aller neuen und/oder geänderten Anforderungen in sich konsistent ist und
b) die Menge aller neuen und/oder geänderten Anforderungen gegenüber den ursprünglichen
Anforderungen konsistent ist.
Der Evaluator vermerkt im ETR jeweils, wo Analysen aus diesem Grund nicht oder nur teilweise durchgeführt
werden.
8.3 PP-Einleitung (APE_INT)

8.3.1 Evaluierung der Unteraufgabe (APE_INT.1)
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob das PP korrekt identifiziert wird und ob
die PP-Verweisung und der TOE-Überblick miteinander konsistent sind.
8.3.1.2 Eingaben
Der Evaluationsnachweis für diese Unteraufgabe ist
a) das PP.
8.3.1.3 Aktion APE_INT.1.1E
ISO/IEC 15408-3 APE_INT.1.1C: Die PP-Einleitung muss eine PP-Verweisung und einen TOE-Überblick enthalten.
8.3.1.3.1 Workunit APE_INT.1-1
Der Evaluator muss prüfen, dass die PP-Einleitung eine PP-Verweisung und einen TOE-Überblick enthält.
ISO/IEC 15408-3 APE_INT.1.2C: Die PP-Verweisung muss das PP eindeutig identifizieren.
28
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss die PP-Verweisung untersuchen, um festzustellen, dass sie das PP eindeutig identifiziert.
Der Evaluator stellt fest, dass die PP-Verweisung das PP selbst identifiziert, so dass es leicht von anderen PPs
unterschieden werden kann, und dass sie auch jede Version des PP eindeutig identifiziert, z. B. unter
Einbeziehung einer Versionsnummer und/oder eines Veröffentlichungsdatums.
Das PP sollte über ein Verweisungssystem verfügen, das in der Lage ist, eindeutige Verweisungen zu
unterstützen (z. B. Verwendung von Zahlen, Buchstaben oder Daten).
ISO/IEC 15408-3 APE_INT.1.3C: Der TOE-Überblick muss die Verwendung und wesentliche Sicherheitsmerkmale
des TOEs zusammenfassen.
Der Evaluator muss den TOE-Überblick untersuchen, um festzustellen, dass er die Verwendung und die
wichtigsten Sicherheitsmerkmale des TOEs beschreibt.
Der TOE-Überblick sollte kurz (d. h. in einigen Absätzen) die Verwendung und die wichtigsten Sicherheits-
merkmale beschreiben, die vom TOE erwartet werden. Der TOE-Überblick sollte Verbraucher und potentielle
TOE-Entwickler in die Lage versetzen, schnell festzustellen, ob das PP für sie von Interesse ist.
Der Evaluator stellt fest, dass der Überblick für Entwickler und Verbraucher des TOEs klar genug ist und
ausreicht, um ihnen ein allgemeines Verständnis der beabsichtigten Verwendung und der wichtigsten
Sicherheitsmerkmale des TOEs zu vermitteln.
ISO/IEC 15408-3 APE_INT.1.4C: Der TOE-Überblick muss den TOE-Typ identifizieren.
Der Evaluator muss prüfen, dass der TOE-Überblick den TOE-Typ identifiziert.
ISO/IEC 15408-3 APE_INT.1.5C: Der TOE-Überblick muss jede nicht im TOE enthaltene, aber für den TOE
verfügbare Hardware/Software/Firmware identifizieren.
Der Evaluator muss den TOE-Überblick untersuchen, um festzustellen, dass er jede nicht im TOE enthaltene,
aber für den TOE verfügbare Hardware/Software/Firmware identifiziert.
Während einige TOEs eigenständig laufen können, benötigen andere TOEs (insbesondere Software-TOEs)
zusätzliche Hardware, Software oder Firmware für den Betrieb. In diesem Unterabschnitt des PP listet der
Autor des PP die gesamte Hardware, Software und/oder Firmware auf, die für den TOE zur Verfügung stehen
wird, um auf ihm zu laufen.
Diese Identifizierung sollte so detailliert sein, dass potentielle Verbraucher und TOE-Entwickler feststellen
können, ob ihr TOE mit der aufgeführten Hardware, Software und Firmware betrieben werden kann.
29
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
8.4 Konformitätsansprüche (APE_CCL)
8.4.1 Evaluierung der Unteraufgabe (APE_CCL.1)
Die Zielsetzung dieser Unteraufgabe ist es, die Gültigkeit verschiedener Konformitätsansprüche zu
bestimmen. Diese beschreiben die Konformität des PP mit der ISO/IEC 15408, anderen PPs und Paketen.
8.4.1.2 Eingaben
a) das PP,
b) das/die PP(s), mit dem/denen das PP Konformität beansprucht,
c) das/die Paket(e), mit dem/denen das PP Konformität beansprucht.
8.4.1.3 Aktion APE_CCL.1.1E
ISO/IEC 15408-3 APE_CCL.1.1C: Der Konformitätsanspruch muss einen Konformitätsanspruch nach

ISO/IEC 15408 enthalten, der die Version der ISO/IEC 15408 angibt, mit der das PP Konformität beansprucht.
8.4.1.3.1 Workunit APE_CCL.1-1
Der Evaluator muss prüfen, ob der Konformitätsanspruch einen Konformitätsanspruch nach ISO/IEC 15408
enthält, der die Version der ISO/IEC 15408 identifiziert, mit der das PP Konformität beansprucht.
Der Evaluator stellt fest, dass der Konformitätsanspruch nach ISO/IEC 15408 die Version der ISO/IEC 15408
identifiziert, die zur Entwicklung dieses PP verwendet wurde. Diese sollte die Versionsnummer der
ISO/IEC 15408 und, sofern nicht die internationale englische Version der ISO/IEC 15408 verwendet wurde,
die Sprache der verwendeten Version der ISO/IEC 15408 enthalten.
ISO/IEC 15408-3 APE_CCL.1.2C: Der Konformitätsanspruch nach ISO/IEC 15408 muss die Konformität des PP
mit ISO/IEC 15408-2 entweder als ISO/IEC 15408-2-konform oder als ISO/IEC 15408-2-erweitert beschreiben.
Der Evaluator muss prüfen, ob der Konformitätsanspruch nach ISO/IEC 15408 entweder den Anspruch
ISO/IEC 15408-2-konform oder ISO/IEC 15408-2-erweitert für das PP angibt.
ISO/IEC 15408-3 APE_CCL.1.3C: Der Konformitätsanspruch nach ISO/IEC 15408 muss die Konformität des PP
mit ISO/IEC 15408-3 entweder als ISO/IEC 15408-3-konform oder als ISO/IEC 15408-3-erweitert beschreiben.
ISO/IEC 15408-3-konform oder ISO/IEC 15408-3-erweitert für das PP angibt.
ISO/IEC 15408-3 APE_CCL.1.4C: Der Konformitätsanspruch nach ISO/IEC 15408 muss mit der erweiterten
Komponentendefinition konsistent sein.
30
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss den Konformitätsanspruch nach ISO/IEC 15408 mit der ISO/IEC 15408-2 untersuchen,
um festzustellen, dass er gegenüber der erweiterten Komponentendefinition konsistent ist.
Wenn der Konformitätsanspruch nach ISO/IEC 15408 ISO/IEC 15408-2-konform enthält, stellt der Evaluator
fest, dass die erweiterte Komponentendefinition keine Funktionskomponenten definiert.
Wenn der Konformitätsanspruch nach ISO/IEC 15408 ISO/IEC 15408-2-erweitert enthält, stellt der Evaluator
fest, dass die erweiterte Komponentendefinition mindestens eine erweiterte Funktionskomponente definiert.
fest, dass die erweiterte Komponentendefinition keine Vertrauenswürdigkeitskomponenten definiert.
fest, dass die erweiterte Komponentendefinition mindestens eine erweiterte Vertrauenswürdigkeits-
komponente definiert.
ISO/IEC 15408-3 APE_CCL.1.5C: Der Konformitätsanspruch muss alle PPs und Sicherheitsanforderungspakete
identifizieren, mit denen das PP Konformität beansprucht.
Der Evaluator muss prüfen, ob der Konformitätsanspruch einen PP-Anspruch enthält, der alle PPs
identifiziert, mit denen das PP Konformität beansprucht.
Wenn das PP nicht die Konformität mit einem anderen PP beansprucht, ist diese Workunit nicht anwendbar
und gilt daher als erfüllt.
Der Evaluator stellt fest, dass alle empfohlenen PPs eindeutig identifiziert werden (z. B. durch Titel und
Versionsnummer oder durch die in der Einführung dieses PPs enthaltene Identifizierung).
Der Evaluator wird daran erinnert, dass Ansprüche auf eine teilweise Konformität mit einem PP nicht zulässig
sind.
Der Evaluator muss prüfen, ob der Konformitätsanspruch einen Paketanspruch enthält, der alle Pakete
identifiziert, mit denen das PP Konformität beansprucht.
Wenn das PP nicht die Konformität mit einem Paket beansprucht, ist diese Workunit nicht anwendbar und gilt
daher als erfüllt.
Der Evaluator stellt fest, dass alle empfohlenen Pakete eindeutig identifiziert werden (z. B. durch Titel und
Versionsnummer oder durch die in der Einführung dieses Pakets enthaltene Identifizierung).
Der Evaluator wird daran erinnert, dass Ansprüche auf eine teilweise Konformität mit einem Paket nicht
zulässig sind.
ISO/IEC 15408-3 APE_CCL.1.6C: Der Konformitätsanspruch muss jede Konformität des PP mit einem Paket
entweder als Paket-konform oder als Paket-ergänzt beschreiben.
31
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss prüfen, ob der Konformitätsanspruch für jedes identifizierte Paket entweder den
Anspruch Paketname-konform oder Paketname-ergänzt angibt.
Wenn das PP nicht die Konformität mit einem Paket beansprucht, ist diese Workunit nicht anwendbar und gilt
daher als erfüllt.
Wenn der Anspruch auf Paketkonformität Paketname-konform enthält, stellt der Evaluator Folgendes fest.
a) Handelt es sich bei dem Paket um ein Sicherheitspaket, so enthält das PP alle im Paket enthaltenen SARs,
aber keine zusätzlichen SARs.
b) Handelt es sich bei dem Paket um ein Funktionspaket, so enthält das PP alle im Paket enthaltenen SFRs,
aber keine zusätzlichen SFRs.
Wenn der Anspruch auf Paketkonformität Paketname-ergänzt enthält, stellt der Evaluator Folgendes fest.
a) Handelt es sich bei dem Paket um ein Sicherheitspaket, dann enthält das PP alle im Paket enthaltenen
SARs und mindestens eine zusätzliche SAR oder mindestens eine SAR, die hierarchisch zu einer SAR im
Paket angeordnet ist.
b) Handelt es sich bei dem Paket um ein Funktionspaket, so enthält das PP alle im Paket enthaltenen SFRs
und mindestens eine zusätzliche SFR oder mindestens eine SFR, die hierarchisch zu einer SFR im Paket
angeordnet ist.
ISO/IEC 15408-3 APE_CCL.1.7C: Die Begründung für den Konformitätsanspruch muss nachweisen, dass der
TOE-Typ mit dem TOE-Typ in den PPs konsistent ist, für die Konformität beansprucht wird.
Der Evaluator muss die Begründung für den Konformitätsanspruch untersuchen, um festzustellen, dass der
TOE-Typ des TOEs gegenüber allen TOE-Typen der PPs konsistent ist.
Die Beziehung zwischen den Typen kann einfach sein: ein PP für eine Firewall, das Konformität mit einem
anderen PP für eine Firewall beansprucht, oder komplexer: ein PP für eine Chipkarte, das gleichzeitig
Konformität mit einer Menge anderer PPs beansprucht: ein PP für die integrierte Schaltung, ein PP für das
Betriebssystem einer Chipkarte und zwei PPs für zwei Anwendungen auf der Chipkarte.
ISO/IEC 15408-3 APE_CCL.1.8C: Die Begründung für den Konformitätsanspruch muss nachweisen, dass die
Aussage zur Sicherheitsproblemdefinition mit der Aussage zur Sicherheitsproblemdefinition in den PPs konsistent
ist, für die Konformität beansprucht wird.
Der Evaluator muss die Begründung für den Konformitätsanspruch untersuchen, um festzustellen, dass sie
die Konsistenz der Aussage der Sicherheitsproblemdefinition, wie sie in der Konformitätserklärung des PP
festgelegt ist, gegenüber den Aussagen der Sicherheitsproblemdefinition in den PPs nachweist, mit denen
Konformität beansprucht wird.
Wenn das zu evaluierende PP nicht die Konformität mit einem anderen PP beansprucht, ist diese Workunit
nicht anwendbar und gilt daher als erfüllt.
32
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Wenn das PP, mit dem Konformität beansprucht wird, keine Aussage der Sicherheitsproblemdefinition
enthält, ist diese Workunit nicht anwendbar und gilt daher als erfüllt.
Wenn eine strikte Konformität durch das PP, mit dem Konformität beansprucht wird, gefordert wird, ist keine
Begründung für den Konformitätsanspruch erforderlich. Stattdessen bestimmt der Evaluator, ob
a) die Bedrohungen in dem zu evaluierenden PP eine Obermenge der Bedrohungen im PP sind, mit dem
Konformität beansprucht wird, oder mit diesen identisch sind;
b) die OSPs in dem zu evaluierenden PP eine Obermenge der OSPs im PP sind, mit dem Konformität
beansprucht wird, oder mit diesen identisch sind;
c) die Annahmen im PP, das Konformität beansprucht, mit den Annahmen im PP, mit dem Konformität
beansprucht wird, identisch sind, wobei es zwei mögliche Ausnahmen gibt, die in den folgenden beiden
Aufzählungspunkten beschrieben werden:
eine Annahme (oder ein Teil einer Annahme) aus dem PP, mit dem Konformität beansprucht wird,
weggelassen werden kann, wenn alle Sicherheitszielsetzungen für die Betriebsumgebung, die diese
Annahme (oder einen Teil einer Annahme) betreffen, durch Sicherheitszielsetzungen für den TOE
ersetzt werden;
eine Annahme zu den Annahmen hinzugefügt werden kann, die im PP definiert werden, mit dem
Konformität beansprucht wird, wenn eine Begründung gegeben wird, warum die neue Annahme
weder eine Bedrohung (oder einen Teil einer Bedrohung) abschwächt, die/der durch
Sicherheitszielsetzungen für den TOE im PP, mit dem Konformität beansprucht wird, angesprochen
werden soll, noch eine OSP (oder einen Teil einer OSP) erfüllt, die/der durch
werden soll.
Bei der Untersuchung eines PP, bei der Annahmen aus einem anderen PP, mit dem Konformität beansprucht
wird, weggelassen oder neue Annahmen hinzugefügt werden, muss der Evaluator genau ermitteln, ob die oben
genannten Bedingungen erfüllt sind. Die folgende Erörterung liefert die Motivation und Beispiele für diese
Fälle.
Beispiel für das Weglassen einer Annahme: Ein PP, mit dem Konformität beansprucht wird, kann eine
Annahme enthalten, die besagt, dass die Betriebsumgebung eine unbefugte Änderung oder das Abfangen
von Daten, die an eine externe Schnittstelle des TOEs gesendet werden, verhindert. Dies kann der Fall
sein, wenn der TOE Daten im Klartext und ohne Integritätsschutz an dieser Schnittstelle akzeptiert und
davon ausgegangen wird, dass er sich in einer sicheren Betriebsumgebung befindet, die Angreifern den
Zugriff auf diese Daten verwehrt. Die Annahme wird dann im PP, mit dem Konformität beansprucht wird,
auf eine Zielsetzung für die Betriebsumgebung abgebildet, die angibt, dass die an dieser Schnittstelle
ausgetauschten Daten durch geeignete Maßnahmen in der Betriebsumgebung geschützt sind. Wenn ein
PP, das dieses PP beansprucht, einen sichereren TOE definiert, der eine zusätzliche Sicherheitszielsetzung
hat, die angibt, dass der TOE selbst diese Daten schützt, z. B. durch Bereitstellung eines sicheren Kanals
für die Verschlüsselung und den Integritätsschutz aller über diese Schnittstelle übertragenen Daten,
können die entsprechende Zielsetzung und die Annahme für die Betriebsumgebung beim PP, das
Konformität beansprucht, weggelassen werden. Dies wird auch als Neuzuweisung der Zielsetzung
bezeichnet, da die Zielsetzung aus der Betriebsumgebung erneut dem TOE zugewiesen wird. Es ist zu
beachten, dass dieser TOE in einer Betriebsumgebung, die die weggelassene Annahme erfüllt, immer noch
sicher ist und daher immer noch das PP erfüllt, mit dem Konformität beansprucht wird.
33
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Beispiel für das Hinzufügen einer Annahme: In diesem Beispiel soll das PP, mit dem Konformität
beansprucht wird, die Anforderungen an einen TOE vom Typ „Firewall“ festlegen, und der Autor eines
anderen PP möchte die Konformität mit diesem PP für einen TOE beanspruchen, der eine Firewall
implementiert, aber zusätzlich die Funktionalität einer Komponente für ein Virtuelles Privates Netzwerk
(VPN) bietet. Für die VPN-Funktionalität benötigt der TOE kryptographische Schlüssel, und diese
Schlüssel müssen unter Umständen auch von der Betriebsumgebung sicher gehandhabt werden (z. B.
wenn symmetrische Schlüssel zur Sicherung der Netzwerkverbindung verwendet werden und daher auf
sichere Weise anderen Komponenten im Netzwerk zur Verfügung gestellt werden müssen). In diesem Fall
ist es akzeptabel, die Annahme hinzuzufügen, dass die vom VPN verwendeten kryptographischen
Schlüssel von der Betriebsumgebung sicher gehandhabt werden. Diese Annahme bezieht sich nicht auf
Bedrohungen oder OSPs des PP, mit dem Konformität beansprucht wird, und erfüllt daher die oben
genannten Bedingungen.
Gegenbeispiel für das Hinzufügen einer Annahme: In einer Variante des ersten Beispiels kann ein PP, mit
dem Konformität beansprucht wird, bereits eine Zielsetzung für den TOE enthalten, um einen sicheren
Kanal für eine seiner Schnittstellen bereitzustellen, und diese Zielsetzung wird auf die Gefahr einer
unbefugten Änderung oder eines unbefugten Lesens der Daten auf dieser Schnittstelle abgebildet. In
diesem Fall ist es eindeutig nicht erlaubt, dass ein anderes PP, das dieses PP beansprucht, eine Annahme
für die Betriebsumgebung hinzufügt, die davon ausgeht, dass die Betriebsumgebung die Daten auf dieser
Schnittstelle vor Veränderung oder unbefugtem Lesen der Daten schützt. Diese Annahme würde eine
Bedrohung reduzieren, die durch den TOE angesprochen werden soll. Daher würde ein TOE, der ein PP
mit dieser zusätzlichen Annahme erfüllt, nicht mehr automatisch das PP erfüllen, mit dem Konformität
beansprucht wird, und dieser Zusatz ist daher nicht zulässig.
Zweites Gegenbeispiel für das Hinzufügen einer Annahme: Im obigen Beispiel eines TOE, der eine Firewall
implementiert, wäre es nicht zulässig, eine allgemeine Annahme hinzuzufügen, dass der TOE nur mit
vertrauenswürdigen Geräten verbunden ist, da dies offensichtlich wesentliche, für eine Firewall relevante
Bedrohungen beseitigen würde (und zwar, dass es nicht vertrauenswürdigen IP-Verkehr gibt, der
gefiltert werden muss). Daher wäre dieser Zusatz nicht zulässig.
Wenn durch das PP, mit dem Konformität beansprucht wird, eine nachweisbare Konformität gefordert wird,
untersucht der Evaluator die Begründung für den Konformitätsanspruch, um festzustellen, ob sie nachweist,
dass die Aussage der Sicherheitsproblemdefinition des zu evaluierenden PP gleichwertig oder restriktiver ist
als die Aussage der Sicherheitsproblemdefinition im PP, mit dem Konformität beansprucht wird.
Dazu muss die Begründung des Konformitätsanspruchs nachweisen, dass die Sicherheitsproblemdefinition im
PP, das Konformität beansprucht, gleichwertig (oder restriktiver) ist als die Sicherheitsproblemdefinition im
PP, mit dem Konformität beansprucht wird. Das bedeutet, dass
alle TOEs, die der Sicherheitsproblemdefinition im PP, das Konformität beansprucht, entsprechen
würden, auch der Sicherheitsproblemdefinition im PP, mit dem Konformität beansprucht wird,
entsprechen. Dies kann auch indirekt durch den Nachweis aufgezeigt werden, dass jedes Ereignis, das
eine Bedrohung realisiert, die im PP definiert wird, mit dem Konformität beansprucht wird, oder gegen
eine OSP verstößt, die im PP definiert ist, mit dem Konformität beansprucht wird, auch eine Bedrohung
realisieren würde, die im PP angegeben wird, das Konformität beansprucht, oder gegen eine OSP
verstoßen würde, die im PP definiert wird, das Konformität beansprucht. Es ist zu beachten, dass die
Erfüllung einer OSP, die im PP angegeben wird, das Konformität beansprucht, eine Bedrohung abwenden
kann, die im PP angegeben wird, mit dem Konformität beansprucht wird, oder dass die Abwendung einer
Bedrohung, die im PP angegeben wird, das Konformität beansprucht, eine OSP erfüllen kann, die im PP
angegeben wird, mit dem Konformität beansprucht wird, so dass Bedrohungen und OSPs sich gegenseitig
ersetzen können,
alle Betriebsumgebungen, die der Sicherheitsproblemdefinition im PP, mit dem Konformität beansprucht
wird, entsprechen würden, auch der Sicherheitsproblemdefinition im PP, das Konformität beansprucht,
entsprechen würden (mit einer Ausnahme im nächsten Aufzählungspunkt),
34
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
neben einer Menge Annahmen im PP, das Konformität beansprucht, die erforderlich sind, um die
Konformität mit der SPD des PP, mit dem Konformität beansprucht wird, nachzuweisen, kann ein PP, das
Konformität beansprucht, weitere Annahmen festlegen, jedoch nur, wenn diese zusätzlichen Annahmen
unabhängig von der Sicherheitsproblemdefinition sind, wie sie im PP, mit dem Konformität beansprucht
wird, definiert ist, und diese nicht beeinflussen. Genauer gesagt gibt es im PP, das Konformität
beansprucht, keine Annahmen, die Bedrohungen für den TOE ausschließen, denen der TOE nach dem PP,
mit dem Konformität beansprucht wird, entgegenwirken muss. Ebenso gibt es im PP, das Konformität
beansprucht, keine Annahmen, die Aspekte einer OSP realisieren, die im PP, mit dem Konformität
beansprucht wird, angegeben sind und die vom TOE nach dem PP, für das Konformität beansprucht wird,
erfüllt werden sollen.
Aussage zu den Sicherheitszielsetzungen mit der Aussage der Sicherheitszielsetzungen in den PPs konsistent ist,
für die Konformität beansprucht wird.
Der Evaluator muss die Begründung für den Konformitätsanspruch untersuchen, um festzustellen, dass die
Aussage der Sicherheitszielsetzungen, wie sie in der Konformitätserklärung des PP festgelegt ist, gegenüber
der Aussage der Sicherheitszielsetzungen in den PPs konsistent ist.
das zu evaluierende PP alle Sicherheitszielsetzungen für den TOE des PP, mit dem Konformität
beansprucht wird, enthält. Es ist zu beachten, dass es zulässig ist für das zu evaluierende PP, zusätzliche
Sicherheitszielsetzungen für den TOE aufzuweisen,
die Sicherheitszielsetzungen für die Betriebsumgebung im PP, das Konformität beansprucht, identisch
mit den Sicherheitszielsetzungen für die Betriebsumgebung im PP sind, mit dem Konformität
beansprucht wird, mit zwei möglichen Ausnahmen, die in den folgenden zwei Aufzählungspunkten
beschrieben werden,
eine Sicherheitszielsetzung für die Betriebsumgebung (oder ein Teil einer solchen Sicherheitszielsetzung)
aus dem PP, mit dem Konformität beansprucht wird, kann durch dieselbe (denselben Teil der) für den
TOE angegebene(n) Sicherheitszielsetzung ersetzt werden,
eine Sicherheitszielsetzung für die Betriebsumgebung kann zu den Zielsetzungen hinzugefügt werden, die
im PP definiert werden, mit dem Konformität beansprucht wird, wenn eine Begründung gegeben wird,
warum die neue Zielsetzung weder eine Bedrohung (oder einen Teil einer Bedrohung) abschwächt, die
durch Sicherheitszielsetzungen für den TOE im PP, mit dem die Konformität beansprucht wird,
angesprochen werden soll, noch eine OSP (oder einen Teil einer OSP) erfüllt, die/der durch
werden soll.
Bei der Untersuchung eines PP, das ein anderes PP beansprucht, das Sicherheitszielsetzungen für die
Betriebsumgebung aus dem PP, mit dem Konformität beansprucht wird, weglässt oder neue Sicherheits-
zielsetzungen für die Betriebsumgebung hinzufügt, muss der Evaluator genau festlegen, ob die oben
genannten Bedingungen erfüllt sind. Die Beispiele, die für die Annahmen in der vorangegangenen Workunit
angegeben wurden, gelten auch hier.
dass die Aussage der Sicherheitszielsetzungen des zu evaluierenden PP gleichwertig oder restriktiver ist als
die Aussage der Sicherheitszielsetzungen im PP, mit dem Konformität beansprucht wird.
35
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Dazu muss die Begründung des Konformitätsanspruchs nachweisen, dass die Sicherheitszielsetzungen im PP,
mit dem Konformität beansprucht wird, gleichwertig (oder restriktiver) ist als die Sicherheitszielsetzungen
im PP, mit dem Konformität beansprucht wird. Das bedeutet, dass
alle TOEs, die die Sicherheitszielsetzungen für den TOE im PP, das Konformität beansprucht, erfüllen
würden, auch die Sicherheitszielsetzungen für den TOE im PP, mit dem Konformität beansprucht wird,
erfüllen,
alle Betriebsumgebungen, die die Sicherheitszielsetzungen für die Betriebsumgebung im PP, mit dem
Konformität beansprucht wird, erfüllen würden, auch die Sicherheitszielsetzungen für die Betriebs-
umgebung im PP, das Konformität beansprucht, erfüllen würden (mit einer Ausnahme im nächsten
Aufzählungspunkt),
neben einer Menge Sicherheitszielsetzungen für die Betriebsumgebung im PP, das Konformität
beansprucht, die zum Nachweis der Konformität mit der Menge Sicherheitszielsetzungen verwendet
werden, die im PP definiert sind, mit dem Konformität beansprucht wird, kann ein PP, das Konformität
beansprucht, weitere Sicherheitszielsetzungen für die Betriebsumgebung festlegen, jedoch nur dann,
wenn diese Sicherheitszielsetzungen weder die ursprüngliche Menge Sicherheitszielsetzungen für den
TOE noch die Sicherheitszielsetzungen für die Betriebsumgebung, wie sie im PP, mit dem Konformität
beansprucht wird, definiert sind, beeinflussen.
Aussage zu den Sicherheitsanforderungen mit der Aussage zu den Sicherheitsanforderungen in den PPs konsistent
Der Evaluator muss das PP untersuchen, um festzustellen, ob es, wie in der Konformitätserklärung des PP
definiert, gegenüber allen Sicherheitsanforderungen in den PPs, mit denen Konformität beansprucht wird,
konsistent ist.
Begründung für den Konformitätsanspruch erforderlich. Stattdessen bestimmt der Evaluator, ob die Aussage
der Sicherheitsanforderungen in dem zu evaluierenden PP eine Obermenge der Aussage der Sicherheits-
anforderungen in dem PP ist, mit dem Konformität (bei strikter Konformität) beansprucht wird, oder ob sie
mit dieser identisch ist.
dass die Aussage der Sicherheitsanforderungen des zu evaluierenden PP gleichwertig oder restriktiver ist als
die Aussage der Sicherheitsanforderungen in dem PP, mit dem Konformität beansprucht wird.
Bei
SFRs: Die Begründung für die Konformität in dem PP, mit dem Konformität beansprucht wird, muss
nachweisen, dass die Gesamtanforderungen, die von den SFRs in dem PP definiert sind, mit dem
Konformität beansprucht wird, gleichwertig (oder restriktiver) sind als die Gesamtanforderungen, die
von den SFRs in dem PP definiert sind, mit dem Konformität beansprucht wird. Dies bedeutet, dass alle
TOEs, die die Anforderungen erfüllen würden, die durch die Menge aller SFRs im PP definiert sind mit
dem Konformität beansprucht wird, auch die Anforderungen erfüllen würden, die durch die Menge aller
SFRs im PP definiert sind, mit dem Konformität beansprucht wird.
36
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
SARs: Das PP, das die Konformität beansprucht, muss alle SARs im PP enthalten, mit dem Konformität
beansprucht wird, kann aber zusätzliche SARs beanspruchen oder die SARs durch hierarchisch stärkere
SARs ersetzen. Die Vervollständigung der Operationen in dem PP, das Konformität beansprucht, muss
konsistent gegenüber der Vervollständigung in dem PP sein, mit dem Konformität beansprucht wird;
entweder wird in dem PP, das Konformität beansprucht, die gleiche Vervollständigung verwendet wie in
dem PP, mit dem Konformität beansprucht wird, oder eine Vervollständigung, die für eine restriktivere
SAR sorgt (es gelten die Regeln zur Präzisierung).
ISO/IEC 15408-3 APE_CCL.1.11C: Die Konformitätserklärung muss die geforderte Konformität aller PPs/STs mit
dem PP als strikte PP-Konformität oder nachweisliche PP-Konformität beschreiben.
Der Evaluator muss prüfen, ob die PP-Konformitätserklärung einen Anspruch der strikten PP- oder
nachweislichen PP-Konformität angibt.
8.5 Sicherheitsproblemdefinition (APE_SPD)
8.5.1 Evaluierung der Unteraufgabe (APE_SPD.1)
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob das Sicherheitsproblem, das durch den
TOE und seine Betriebsumgebung angesprochen werden soll, klar definiert ist.
8.5.1.2 Eingaben
a) das PP.
8.5.1.3 Aktion APE_SPD.1.1E
ISO/IEC 15408-3 APE_SPD.1.1C: Die Sicherheitsproblemdefinition muss die Bedrohungen beschreiben.
8.5.1.3.1 Workunit APE_SPD.1-1
Der Evaluator muss prüfen, ob die Sicherheitsproblemdefinition die Bedrohungen beschreibt.
Wenn alle Sicherheitszielsetzungen nur aus Annahmen und/oder OSPs abgeleitet werden, muss die Aussage
der Bedrohungen im PP nicht vorhanden sein. In diesem Fall ist diese Workunit nicht anwendbar und gilt
daher als erfüllt.
Der Evaluator stellt fest, dass die Sicherheitsproblemdefinition die Bedrohungen beschreibt, denen der TOE
und/oder seine Betriebsumgebung entgegenwirken muss.
ISO/IEC 15408-3 APE_SPD.1.2C: Alle Bedrohungen müssen in Bezug auf einen Bedrohungsagenten, einen
Vermögenswert und eine unerwünschte Aktion beschrieben werden.
Der Evaluator muss die Sicherheitsproblemdefinition untersuchen, um festzustellen, dass alle Bedrohungen
anhand eines Bedrohungsagenten, eines Vermögenswertes und einer unerwünschten Aktion beschrieben
werden.
37
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Wenn alle Sicherheitszielsetzungen nur aus Annahmen und OSPs abgeleitet werden, muss die Aussage der
Bedrohungen im PP nicht vorhanden sein. In diesem Fall ist diese Workunit nicht anwendbar und gilt daher
als erfüllt.
Bedrohungsagenten können noch weiter über Aspekte wie Fachkenntnis, Ressource, Möglichkeit und
Motivation beschrieben werden.
ISO/IEC 15408-3 APE_SPD.1.3C: Die Sicherheitsproblemdefinition muss die OSPs beschreiben.
Der Evaluator muss untersuchen, ob die Sicherheitsproblemdefinition die OSPs beschreibt.
Wenn alle Sicherheitszielsetzungen nur aus Annahmen und/oder Bedrohungen abgeleitet werden, müssen
OSPs im PP nicht vorhanden sein. In diesem Fall ist diese Workunit nicht anwendbar und gilt daher als erfüllt.
Der Evaluator stellt fest, dass OSP-Aussagen in Form von Regeln oder Leitlinien gemacht werden, die vom TOE
und/oder seiner Betriebsumgebung befolgt werden müssen.
Der Evaluator stellt fest, dass jede OSP ausreichend detailliert erklärt und/oder interpretiert wird, um sie klar
verständlich zu machen; eine klare Darstellung der Grundsatzerklärungen ist notwendig, um die
Rückverfolgung der Sicherheitszielsetzungen zu ermöglichen.
ISO/IEC 15408-3 APE_SPD.1.4C: Die Sicherheitsproblemdefinition muss die Annahmen über die Betriebs-
umgebung des TOEs beschreiben.
Der Evaluator muss die Sicherheitsproblemdefinition untersuchen, um festzustellen, dass er die Annahmen
über die Betriebsumgebung des TOEs beschreibt.
Gibt es keine Annahmen, ist diese Workunit nicht anwendbar und gilt daher als erfüllt.
Der Evaluator stellt fest, dass jede Annahme über die Betriebsumgebung des TOEs hinreichend detailliert
erläutert wird, damit die Verbraucher feststellen können, dass ihre Betriebsumgebung mit der Annahme
übereinstimmt. Wenn die Annahmen nicht klar verstanden werden, kann das Endergebnis sein, dass der TOE
in einer Betriebsumgebung verwendet wird, in der er nicht in sicherer Weise funktioniert.
8.6 Sicherheitszielsetzungen (APE_OBJ)
8.6.1 Evaluierung der Unteraufgabe (APE_OBJ.1)
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob die Sicherheitszielsetzungen für die
Betriebsumgebung klar definiert sind.
8.6.1.2 Eingaben
a) das PP.
38
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
8.6.1.3 Aktion APE_OBJ.1.1E
ISO/IEC 15408-3 APE_OBJ.1.1C: Die Aussage zu Sicherheitszielsetzungen muss die Sicherheitszielsetzungen für
die Betriebsumgebung beschreiben.
8.6.1.3.1 Workunit APE_OBJ.1-1
Der Evaluator muss prüfen, ob die Aussage der Sicherheitszielsetzungen die Sicherheitszielsetzungen für die
Betriebsumgebung definiert.
Der Evaluator prüft, ob die Sicherheitszielsetzungen für die Betriebsumgebung festgelegt sind.
8.6.2 Evaluierung der Unteraufgabe (APE_OBJ.2)
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob die Sicherheitszielsetzungen die
Sicherheitsproblemdefinition angemessen und vollständig berücksichtigen und ob die Aufteilung dieses
Problems zwischen dem TOE und seiner Betriebsumgebung klar definiert ist.
8.6.2.2 Eingaben
a) das PP.
8.6.2.3 Aktion APE_OBJ.2.1E
ISO/IEC 15408-3 APE_OBJ.2.1C: Die Aussage zu Sicherheitszielsetzungen muss die Sicherheitszielsetzungen für
den TOE und die Sicherheitszielsetzungen für die Betriebsumgebung beschreiben.
Der Evaluator muss prüfen, ob die Aussage der Sicherheitszielsetzungen die Sicherheitszielsetzungen für den
TOE und die Sicherheitszielsetzungen für die Betriebsumgebung definiert.
Der Evaluator prüft, ob beide Kategorien von Sicherheitszielsetzungen klar identifiziert und von der anderen
Kategorie getrennt sind.
ISO/IEC 15408-3 APE_OBJ.2.2C: Die Begründung für die Sicherheitszielsetzungen muss jede Sicherheits-
zielsetzung für den TOE zurückführen zu den Bedrohungen, die durch diese Sicherheitszielsetzung abgewehrt
werden, und zu den OSPs, die durch diese Sicherheitszielsetzung durchgesetzt werden.
Der Evaluator muss prüfen, ob die Begründung der Sicherheitszielsetzungen alle Sicherheitszielsetzungen für
den TOE auf Bedrohungen zurückführt, denen die Zielsetzungen und/oder die durch die Zielsetzungen
durchgesetzten OSPs entgegenwirken.
Jede Sicherheitszielsetzung für den TOE kann auf Bedrohungen oder OSPs bzw. auf eine Kombination von
Bedrohungen und OSPs zurückführen, sie muss aber auf mindestens eine Bedrohung oder eine OSP
zurückführen.
Eine fehlende Nachvollziehbarkeit bedeutet, dass entweder die Begründung der Sicherheitszielsetzungen
unvollständig ist, dass die Sicherheitsproblemdefinition unvollständig ist oder dass die Sicherheitszielsetzung
für den TOE keinen sinnvollen Zweck hat.
ISO/IEC 15408-3 APE_OBJ.2.3C: Die Begründung für die Sicherheitszielsetzungen muss jede Sicherheits-
zielsetzung für die Betriebsumgebung zurückführen zu den Bedrohungen, die durch diese Sicherheitszielsetzung
abgewehrt werden, zu den OSPs, die durch diese Sicherheitszielsetzung durchgesetzt werden, und zu den
Annahmen, die durch diese Sicherheitszielsetzung eingehalten werden.
39
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss prüfen, ob die Begründung der Sicherheitszielsetzungen die Sicherheitszielsetzungen für
die Betriebsumgebung auf Bedrohungen zurückführt, denen diese Sicherheitszielsetzung entgegenwirkt, auf
die durch diese Sicherheitszielsetzung durchgesetzten OSPs und auf die durch diese Sicherheitszielsetzung
eingehaltenen Annahmen.
Jede Sicherheitszielsetzung für die Betriebsumgebung kann auf Bedrohungen, OSPs, Annahmen oder eine
Kombination von Bedrohungen, OSPs und/oder Annahmen zurückführen, sie muss aber auf mindestens eine
Bedrohung, OSP oder Annahme zurückführen.
für die Betriebsumgebung keinen sinnvollen Zweck hat.
ISO/IEC 15408-3 APE_OBJ.2.4C: Die Begründung für die Sicherheitszielsetzungen muss nachweisen, dass die
Sicherheitszielsetzungen alle Bedrohungen abwehren.
Der Evaluator muss die Begründung der Sicherheitszielsetzungen untersuchen, um festzustellen, ob sie für
jede Bedrohung rechtfertigt, dass die Sicherheitszielsetzungen zur Abwehr dieser Bedrohung geeignet sind.
Wenn keine Sicherheitszielsetzungen auf die Bedrohung zurückgeführt werden können, wird die Evaluatoren-
aktion, die sich auf diese Workunit bezieht, mit einer „abgelehnt“-Entscheidung belegt.
Der Evaluator stellt fest, dass die Begründung für eine Bedrohung zeigt, ob die Bedrohung beseitigt,
vermindert oder abgeschwächt wird.
Der Evaluator stellt fest, dass die Begründung für eine Bedrohung zeigt, dass die Sicherheitszielsetzungen
ausreichend sind: Wenn alle Sicherheitszielsetzungen, die auf die Bedrohung zurückführen, erreicht werden,
ist die Bedrohung beseitigt, ausreichend vermindert oder die Auswirkungen der Bedrohung werden
ausreichend abgeschwächt.
Es ist zu beachten, dass die Rückverfolgungen von den Sicherheitszielsetzungen bis hin zu den Bedrohungen,
die in der Begründung der Sicherheitszielsetzungen aufgeführt sind, Teil einer Begründung sein können, aber
keine Begründung für sich selbst darstellen. Selbst für den Fall, dass eine Sicherheitszielsetzung lediglich eine
Aussage ist, die die Absicht widerspiegelt, die Verwirklichung einer bestimmten Bedrohung zu verhindern, ist
eine Begründung erforderlich, die jedoch so minimal sein kann wie „Sicherheitszielsetzung X wirkt der
Bedrohung Y direkt entgegen“.
Der Evaluator stellt auch fest, dass jede Sicherheitszielsetzung, die auf eine Bedrohung zurückführt, notwendig
ist: Wenn die Sicherheitszielsetzung erreicht ist, trägt sie tatsächlich zur Beseitigung, Verminderung oder
Abschwächung dieser Bedrohung bei.
Sicherheitszielsetzungen alle OSPs durchsetzen.
jede OSP rechtfertigt, dass die Sicherheitszielsetzungen geeignet sind, diese OSP durchzusetzen.
Wenn keine Sicherheitszielsetzungen auf die OSP zurückgeführt werden können, wird die Evaluatorenaktion,
die sich auf diese Workunit bezieht, mit einer „abgelehnt“-Entscheidung belegt.
40
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator stellt fest, dass die Begründung für eine OSP zeigt, dass die Sicherheitszielsetzungen
ausreichend sind: Wenn alle Sicherheitszielsetzungen, die auf die OSP zurückführen, erreicht werden, wird
die OSP durchgesetzt.
Der Evaluator stellt auch fest, dass jede Sicherheitszielsetzung, die auf eine OSP zurückführt, notwendig ist:
Wenn die Sicherheitszielsetzung erreicht ist, trägt sie tatsächlich zur Durchsetzung der OSP bei.
Es ist zu beachten, dass die Rückverfolgungen von den Sicherheitszielsetzungen bis hin zu den OSPs, die in der
Begründung der Sicherheitszielsetzungen aufgeführt sind, Teil einer Begründung sein können, aber keine
Begründung für sich selbst darstellen. Für den Fall, dass eine Sicherheitszielsetzung lediglich eine Aussage ist,
die die Absicht widerspiegelt, eine bestimmte OSP durchzusetzen, ist eine Begründung erforderlich, die jedoch
so minimal sein kann wie „Sicherheitszielsetzung X setzt OSP Y direkt durch“.
Sicherheitszielsetzungen für die Betriebsumgebung alle Annahmen einhalten.
Der Evaluator muss die Begründung der Sicherheitszielsetzungen untersuchen, um festzustellen, dass sie für
jede Annahme für die Betriebsumgebung eine angemessene Begründung dafür enthält, dass die Sicherheits-
zielsetzungen für die Betriebsumgebung geeignet sind, diese Annahme zu bestätigen.
Wenn keine Sicherheitszielsetzungen für die Betriebsumgebung auf die Annahme zurückführen, wird die
Evaluatorenaktion, die sich auf diese Workunit bezieht, mit einer „abgelehnt“ Entscheidung belegt.
Der Evaluator stellt fest, dass die Begründung für eine Annahme über die Betriebsumgebung des TOEs zeigt,
dass die Sicherheitszielsetzungen ausreichend sind: Wenn alle Sicherheitszielsetzungen für die Betriebs-
umgebung, die auf diese Annahme zurückführen, erreicht werden, hält die Betriebsumgebung die Annahme
aufrecht.
Der Evaluator stellt auch fest, dass jede Sicherheitszielsetzung für die Betriebsumgebung, die auf eine
Annahme über die Betriebsumgebung des TOEs zurückführt, notwendig ist: Wenn die Sicherheitszielsetzung
erreicht ist, trägt sie tatsächlich dazu bei, dass die Betriebsumgebung die Annahme aufrechterhält.
Es ist zu beachten, dass die Rückverfolgungen von den Sicherheitszielsetzungen für die Betriebsumgebung bis
hin zu den Annahmen, die in der Begründung der Sicherheitszielsetzungen aufgeführt sind, Teil einer
Begründung sein können, aber keine Begründung für sich selbst darstellen. Selbst für den Fall, dass eine
Sicherheitszielsetzung der Betriebsumgebung lediglich die Neuformulierung einer Annahme ist, ist eine
Begründung erforderlich, die jedoch so minimal sein kann wie „Sicherheitszielsetzung X hält die Annahme Y
direkt aufrecht“.
8.7 Erweiterte Komponentendefinition (APE_ECD)
8.7.1 Evaluierung der Unteraufgabe (APE_ECD.1)
Die Zielsetzung dieser Unteraufgabe ist es, festzustellen, ob erweiterte Komponenten klar und eindeutig
definiert wurden und ob sie notwendig sind, d. h. sie können unter Verwendung bestehender Komponenten
der ISO/IEC 15408-2 oder ISO/IEC 15408-3 nicht klar ausgedrückt werden.
8.7.1.2 Eingaben
a) das PP.
41
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
8.7.1.3 Aktion APE_ECD.1.1E
ISO/IEC 15408-3 APE_ECD.1.1C: Die Aussage zu den Sicherheitsanforderungen muss alle erweiterten
Sicherheitsanforderungen identifizieren.
8.7.1.3.1 Workunit APE_ECD.1-1
Der Evaluator muss prüfen, ob alle Sicherheitsanforderungen in der Aussage der Sicherheitsanforderungen,
die nicht als erweiterte Anforderungen gekennzeichnet sind, in der ISO/IEC 15408-2 oder in der
ISO/IEC 15408-3 enthalten sind.
ISO/IEC 15408-3 APE_ECD.1.2C: Die erweiterte Komponentendefinition muss für jede erweiterte Sicherheits-
anforderung eine erweiterte Komponente definieren.
Der Evaluator muss prüfen, ob die erweiterte Komponentendefinition für jede erweiterte Sicherheits-
anforderung eine erweiterte Komponente definiert.
Enthält das PP keine erweiterten Sicherheitsanforderungen, ist diese Workunit nicht anwendbar und gilt
daher als erfüllt.
Eine einzelne erweiterte Komponente kann verwendet werden, um mehrfache Iterationen einer erweiterten
Sicherheitsanforderung zu definieren, es ist nicht notwendig, diese Definition für jede Iteration zu
wiederholen.
ISO/IEC 15408-3 APE_ECD.1.3C: Die erweiterte Komponentendefinition muss beschreiben, wie jede erweiterte
Komponente mit den bestehenden Komponenten, Familien und Klassen der ISO/IEC 15408 in Beziehung steht.
Der Evaluator muss die erweiterte Komponentendefinition untersuchen, um festzustellen, dass sie
beschreibt, wie jede erweiterte Komponente in die vorhandenen Komponenten, Familien und Klassen der
ISO/IEC 15408 passt.
daher als erfüllt.
Der Evaluator stellt fest, dass jede erweiterte Komponente entweder
a) ein Mitglied einer bestehenden Familie der ISO/IEC 15408-2 oder ISO/IEC 15408-3 ist, oder
b) ein Mitglied einer neuen, im PP definierten Familie.
Wenn die erweiterte Komponente Mitglied einer bestehenden Familie der ISO/IEC 15408-2 oder
ISO/IEC 15408-3 ist, stellt der Evaluator fest, dass die erweiterte Komponentendefinition angemessen
beschreibt, warum die erweiterte Komponente ein Mitglied dieser Familie sein sollte und wie sie mit anderen
Komponenten dieser Familie zusammenhängt.
Wenn die erweiterte Komponente ein Mitglied einer neuen, im PP definierten Familie ist, bestätigt der
Evaluator, dass die erweiterte Komponente nicht für eine bestehende Familie geeignet ist.
Wenn das PP neue Familien definiert, stellt der Evaluator fest, dass jede neue Familie entweder
a) ein Mitglied einer bestehenden Klasse der ISO/IEC 15408-2 oder ISO/IEC 15408-3 ist, oder
b) ein Mitglied einer neuen, im PP definierten Klasse.
42
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Wenn die Familie ein Mitglied einer bestehenden Klasse der ISO/IEC 15408-2 oder ISO/IEC 15408-3 ist, stellt
der Evaluator fest, dass die erweiterte Komponentendefinition angemessen beschreibt, warum die Familie ein
Mitglied jener Klasse sein sollte und wie sie mit anderen Familien jener Klasse zusammenhängt.
Wenn die Familie ein Mitglied einer neuen, im PP definierten Klasse ist, bestätigt der Evaluator, dass die
Familie für eine bestehende Klasse nicht geeignet ist.
Der Evaluator muss die erweiterte Komponentendefinition untersuchen, um festzustellen, dass jede
Definition einer erweiterten Komponente alle anwendbaren Abhängigkeiten dieser Komponente identifiziert.
daher als erfüllt.
Der Evaluator bestätigt, dass der PP-Autor keine zutreffenden Abhängigkeiten übersehen hat.
ISO/IEC 15408-3 APE_ECD.1.4C: Die erweiterte Komponentendefinition muss die bestehendenen Komponenten,
Familien, Klassen und die Methodik der ISO/IEC 15408 als ein Modell der Darstellung verwenden.
erweiterte Funktionskomponente die vorhandenen Komponenten der ISO/IEC 15408-2 als Modell für die
Darstellung verwendet.
Enthält das PP keine erweiterten SFRs, ist diese Workunit nicht anwendbar und gilt daher als erfüllt.
Der Evaluator stellt fest, dass jede erweiterte Funktionskomponente konsistent ist gegenüber
ISO/IEC 15408-2, 6.1.3, Komponentenstruktur.
Wenn die erweiterte Funktionskomponente Operationen verwendet, stellt der Evaluator fest, dass die
erweiterte Funktionskomponente konsistent ist gegenüber ISO/IEC 15408-1, 7.1, Operationen.
Wenn die erweiterte Funktionskomponente hierarchisch zu einer bestehenden Funktionskomponente ist,

stellt der Evaluator fest, dass die erweiterte Funktionskomponente konsistent ist gegenüber ISO/IEC 15408-2,
6.2.1, Hervorheben von Komponentenänderungen.
Definition einer neuen Funktionsfamilie die bestehenden Funktionsfamilien der ISO/IEC 15408 als Modell für
die Darstellung verwendet.
Wenn das PP keine neuen Funktionsfamilien definiert, ist diese Workunit nicht anwendbar und gilt daher als
erfüllt.
Der Evaluator stellt fest, dass alle neuen Funktionsfamilien konsistent definiert werden gegenüber
ISO/IEC 15408-2, 6.1.2, Familienstruktur.
Definition einer neuen Funktionsklasse die bestehenden Funktionsklassen der ISO/IEC 15408 als Modell für
Wenn das PP keine neuen Funktionsklassen definiert, ist diese Workunit nicht anwendbar und gilt daher als
erfüllt.
Der Evaluator stellt fest, dass alle neuen Funktionsklassen konsistent definiert werden gegenüber
ISO/IEC 15408-2, 6.1.1, Klassenstruktur.
43
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Definition einer erweiterten Vertrauenswürdigkeitskomponente die vorhandenen Komponenten der
ISO/IEC 15408-3 als Modell für die Darstellung verwendet.
Enthält das PP keine erweiterten SARs, ist diese Workunit nicht anwendbar und gilt daher als erfüllt.
Der Evaluator stellt fest, dass jede erweiterte Vertrauenswürdigkeitskomponente konsistent ist gegenüber
ISO/IEC 15408-3, 6.1.3, Struktur der Vertrauenswürdigkeitskomponenten.
Wenn die erweiterte Vertrauenswürdigkeitskomponente Operationen verwendet, stellt der Evaluator fest,
dass die erweiterte Vertrauenswürdigkeitskomponente konsistent ist gegenüber ISO/IEC 15408-1, 7.1,
Operationen.
Wenn die erweiterte Vertrauenswürdigkeitskomponente hierarchisch zu einer bestehenden Vertrauens-

würdigkeitskomponente ist, stellt der Evaluator fest, dass die erweiterte Vertrauenswürdigkeitskomponente
konsistent ist gegenüber ISO/IEC 15408-3, 6.1.3, Struktur der Vertrauenswürdigkeitskomponenten.
Der Evaluator muss die erweiterte Komponentendefinition untersuchen, um festzustellen, ob für jede
definierte erweiterte Vertrauenswürdigkeitskomponente eine anwendbare Methodik bereitgestellt wurde.
Enthält das PP keine erweiterten SARs, ist diese Workunit nicht anwendbar und gilt daher als erfüllt.
Der Evaluator stellt fest, dass für jedes Evaluatorenaktionselement jeder erweiterten SAR eine oder mehrere
Workunits vorgesehen sind und dass die erfolgreiche Durchführung aller Workunits für ein bestimmtes
Evaluatorenaktionselement nachweisen wird, dass das Element erreicht wurde.
Definition einer neuen Vertrauenswürdigkeitsfamilie die bestehenden Vertrauenswürdigkeitsfamilien der
ISO/IEC 15408 als Modell für die Darstellung verwendet.
Wenn das PP keine neuen Vertrauenswürdigkeitsfamilien definiert, ist diese Workunit nicht anwendbar und
gilt daher als erfüllt.
Der Evaluator stellt fest, dass alle neuen Vertrauenswürdigkeitsfamilien konsistent definiert werden
gegenüber ISO/IEC 15408-3, 6.1.2, Struktur der Vertrauenswürdigkeitsfamilien.
Definition einer neuen Vertrauenswürdigkeitsklasse die bestehenden Vertrauenswürdigkeitsklassen der
Wenn das PP keine neuen Vertrauenswürdigkeitsklassen definiert, ist diese Workunit nicht anwendbar und
Der Evaluator stellt fest, dass alle neuen Vertrauenswürdigkeitsklassen konsistent definiert werden
gegenüber ISO/IEC 15408-3, 6.1.1, Struktur der Vertrauenswürdigkeitsklassen.
ISO/IEC 15408-3 APE_ECD.1.5C: Die erweiterten Komponenten müssen aus messbaren und objektiven
Elementen bestehen, sodass die Konformität oder Nichtkonformität mit diesen Elementen nachgewiesen werden
kann.
44
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss die erweiterte Komponentendefinition untersuchen, um festzustellen, dass jedes
Element in jeder erweiterten Komponente messbar ist und objektive Evaluierungsanforderungen angibt, so
dass Konformität oder Nichtkonformität nachgewiesen werden kann.
daher als erfüllt.
Der Evaluator stellt fest, dass die Elemente der erweiterten Funktionskomponenten so angegeben werden,
dass sie prüfbar und durch die entsprechenden TSF-Darstellungen rückverfolgbar sind.
Der Evaluator stellt auch fest, dass Elemente der erweiterten Vertrauenswürdigkeitskomponenten die
Notwendigkeit einer subjektiven Beurteilung durch den Evaluator vermeiden.
Der Evaluator wird daran erinnert, dass alle Evaluierungskriterien zwar messbar und objektiv sind, dass es
aber anerkanntermaßen kein formales Verfahren zum Nachweis solcher Eigenschaften gibt. Daher sind die
vorhandenen Funktions- und Vertrauenswürdigkeitskomponenten der ISO/IEC 15408 als Modell für die
Bestimmung der Konformität mit dieser Anforderung zu verwenden.
8.7.1.4 Aktion APE_ECD.1.2E
erweiterte Komponente nicht eindeutig durch vorhandene Komponenten ausgedrückt werden kann.
daher als erfüllt.
Der Evaluator sollte bei dieser Bestimmung Komponenten aus ISO/IEC 15408-2 und ISO/IEC 15408-3, andere
erweiterte Komponenten, die im PP definiert wurden, Kombinationen dieser Komponenten und mögliche
Operationen an diesen Komponenten berücksichtigen.
Der Evaluator wird daran erinnert, dass die Rolle dieser Workunit darin besteht, eine unnötige Duplizierung
von Komponenten zu vermeiden, d. h. von Komponenten, die durch die Verwendung anderer Komponenten
klar ausgedrückt werden können. Der Evaluator sollte keine erschöpfende Suche nach allen möglichen
Kombinationen von Komponenten einschließlich Operationen durchführen, um zu versuchen, einen Weg zu
finden, die erweiterte Komponente durch Verwendung vorhandener Komponenten auszudrücken.
8.8 Sicherheitsanforderungen (APE_REQ)
8.8.1 Evaluierung der Unteraufgabe (APE_REQ.1)
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob die SFRs und SARs klar, eindeutig und
genau definiert sind und ob sie in sich konsistent sind.
8.8.1.2 Eingaben
a) das PP.
45
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
8.8.1.3 Aktion APE_REQ.1.1E
ISO/IEC 15408-3 APE_REQ.1.1C: Die Aussage zu den Sicherheitsanforderungen muss die SFRs und die SARs
beschreiben.
8.8.1.3.1 Workunit APE_REQ.1-1
Der Evaluator muss prüfen, ob die Aussage der Sicherheitsanforderungen die SFRs beschreibt.
Der Evaluator stellt fest, dass jede SFR auf eine der folgenden Arten identifiziert wird:
a) durch Verweisung auf eine einzelne Komponente in ISO/IEC 15408-2;
b) durch Verweisung auf eine erweiterte Komponente in der erweiterten Komponentendefinition des PP;
c) durch Verweisung auf ein PP, mit dem das PP beansprucht, konform zu sein;
d) durch Verweisung auf ein Sicherheitsanforderungspaket, mit dem das PP beansprucht, konform zu sein;
e) durch Vervielfältigung im PP.
Es ist nicht erforderlich, für alle SFRs das gleiche Identifizierungsmittel zu verwenden.
Der Evaluator muss prüfen, ob die Aussage der Sicherheitsanforderungen die SARs beschreibt.
Der Evaluator stellt fest, dass jede SAR auf eine der folgenden Arten identifiziert wird:
c) durch Verweisung auf ein PP, mit dem das PP beansprucht, konform zu sein;
d) durch Verweisung auf ein Sicherheitsanforderungspaket, mit dem das PP beansprucht, konform zu sein;
Es ist nicht erforderlich, für alle SARs das gleiche Identifizierungsmittel zu verwenden.
ISO/IEC 15408-3 APE_REQ.1.2C: Alle Subjekte, Objekte, Operationen, Sicherheitsattribute, externen Entitäten
und sonstigen in den SFRs und SARs verwendeten Begriffe müssen definiert sein.
Der Evaluator muss das PP untersuchen, um festzustellen, ob alle Subjekte, Objekte, Operationen,
Sicherheitsattribute, externen Entitäten und sonstigen Begriffe, die in den SFRs und den SARs verwendet
werden, definiert sind.
Der Evaluator stellt fest, dass das PP Folgendes definiert:
alle (Arten von) Subjekte(n) und Objekte(n), die in den SFRs verwendet werden;
alle (Arten von) Sicherheitsattribute(n) von Subjekten, Benutzern, Objekten, Informationen, Sitzungen
und/oder Ressourcen, mögliche Werte, die diese Attribute annehmen können, und alle Beziehungen
zwischen diesen Werten (z. B. ist streng_geheim „höher“ als geheim);
46
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
alle (Arten von) Operationen, die in den SFRs verwendet werden, einschließlich der Auswirkungen dieser
Operationen;
alle (Arten von) externen Entitäten in den SFRs;
andere Begriffe, die durch die Vervollständigung von Operationen in die SFRs und/oder SARs eingeführt
werden, wenn diese Begriffe nicht sofort klar sind oder außerhalb ihrer Wörterbuchdefinition verwendet
werden.
Ziel dieser Workunit ist es, sicherzustellen, dass die SFRs und SARs klar definiert sind und dass keine
Missverständnisse durch die Einführung vager Begriffe entstehen können. Diese Workunit sollte nicht bis zum
Äußersten getrieben werden, indem der Verfasser des PP gezwungen wird, jedes einzelne Wort zu definieren.
Bei den allgemeinen Adressaten einer Menge Sicherheitsanforderungen sollte davon ausgegangen werden,
dass sie über angemessene Kenntnisse der IT, der Sicherheit und der „Evaluierungskriterien für die
IT-Sicherheit“ verfügen.
All dies kann in Gruppen, Klassen, Rollen, Typen oder anderen Gruppierungen oder Charakterisierungen
dargestellt werden, die ein einfaches Verständnis ermöglichen.
Der Evaluator wird daran erinnert, dass diese Listen und Definitionen nicht Teil der Aussage der
Sicherheitsanforderungen sein müssen, sondern (teilweise oder ganz) in verschiedenen Unterabschnitten
untergebracht werden können. Dies kann insbesondere dann der Fall sein, wenn die gleichen Begriffe im
übrigen PP verwendet werden.
ISO/IEC 15408-3 APE_REQ.1.3C: Die Aussage zu den Sicherheitsanforderungen muss alle Operationen im
Zusammenhang mit den Sicherheitsanforderungen identifizieren.
Der Evaluator muss prüfen, ob in der Aussage der Sicherheitsanforderungen alle Operationen zur Erfüllung
der Sicherheitsanforderungen aufgeführt sind.
Der Evaluator stellt fest, dass alle Operationen in jeder SFR oder SAR, in denen eine solche Operation
verwendet wird, identifiziert werden. Dies umfasst sowohl abgeschlossene als auch nicht abgeschlossene
Operationen. Die Identifizierung kann durch typografische Unterscheidungen, durch explizite Kennzeichnung
im umgebenden Text oder durch jedes andere Unterscheidungsmittel erfolgen.
ISO/IEC 15408-3 APE_REQ.1.4C: Alle Operationen müssen korrekt durchgeführt werden.
8.8.1.3.5 Workunit ASE_REQ.1-5
Der Evaluator muss die Aussage der Sicherheitsanforderungen untersuchen, um festzustellen, dass alle
Zuordnungsoperationen korrekt durchgeführt werden.
Leitlinien zur korrekten Durchführung der Operationen können ISO/IEC 15408-1, Anhang C, Leitlinien für
Operationen, entnommen werden.
Iterationsoperationen korrekt durchgeführt werden.
47
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Auswahloperationen korrekt durchgeführt werden.
Präzisierungsoperationen korrekt durchgeführt werden.
ISO/IEC 15408-3 APE_REQ.1.5C: Jede Abhängigkeit der Sicherheitsanforderungen muss entweder erfüllt sein,
oder die Begründung für die Sicherheitsanforderungen muss rechtfertigen, dass die Abhängigkeit nicht erfüllt
wird.
Der Evaluator muss die Aussage der Sicherheitsanforderungen untersuchen, um festzustellen, dass jede
Abhängigkeit der Sicherheitsanforderungen entweder erfüllt ist oder ob die Begründung der Sicherheits-
anforderungen die Nichterfüllung der Abhängigkeit rechtfertigt.
Eine Abhängigkeit wird durch die Einbeziehung der betreffenden Komponente (oder einer zu ihr
hierarchischen Komponente) in die Aussage der Sicherheitsanforderungen erfüllt. Die Komponente, die zur
Erfüllung der Abhängigkeit verwendet wird, sollte gegebenenfalls durch Operationen modifiziert werden, um
sicherzustellen, dass sie diese Abhängigkeit auch tatsächlich erfüllt.
In einer Begründung, dass eine Abhängigkeit nicht erfüllt ist, sollte ebenfalls angesprochen werden
a) warum die Abhängigkeit nicht erforderlich oder sinnvoll ist, wobei in diesem Fall keine weiteren
Informationen erforderlich sind; oder
b) dass die Abhängigkeit über die Betriebsumgebung des TOEs behandelt wurde; in diesem Fall sollte in der
Begründung beschrieben sein, wie die Sicherheitszielsetzungen für die Betriebsumgebung diese
Abhängigkeit behandeln.
ISO/IEC 15408-3 APE_REQ.1.6C: Die Aussage zu den Sicherheitsanforderungen muss in sich konsistent sein.
Der Evaluator muss die Aussage der Sicherheitsanforderungen untersuchen, um festzustellen, dass sie in sich
konsistent ist.
Der Evaluator stellt fest, dass die kombinierte Menge aller SFRs und SARs in sich konsistent ist.
Der Evaluator stellt fest, dass in allen Fällen, in denen unterschiedliche Sicherheitsanforderungen für die
gleichen Arten von Nachweisen, Ereignissen, Operationen, Daten, durchzuführenden Prüfungen usw. für den
Entwickler oder für „alle Objekte“, „alle Subjekte“ usw. gelten, diese Anforderungen nicht im Widerspruch
zueinander stehen.
48
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Einige mögliche Widersprüche sind:
a) eine erweiterte SAR, die angibt, dass das Design eines bestimmten kryptographischen Algorithmus
geheim zu halten ist, und eine weitere erweiterte SAR, die eine Open-Source-Überprüfung angibt;
b) FAU_GEN.1 „Audit data generation“ mit der Angabe, dass die Identität des Subjekts protokolliert werden
soll, FDP_ACC.1 „Subset access control“ mit der Angabe, wer Zugang zu diesen Protokollen hat, und
FPR_UNO.1 „Unobservability“ mit der Angabe, dass einige Aktionen von Subjekten für andere Subjekte
unbeobachtbar sein sollten. Wenn das Subjekt, das eine Aufgabe nicht sehen soll, auf Protokolle dieser
Aufgabe zugreifen kann, stehen diese SFRs im Widerspruch zueinander;
c) FDP_RIP.1 „Subset residual information protection“ mit der Angabe der Löschung von nicht mehr
benötigten Informationen, und FDP_ROL.1 „Basic rollback“ mit der Angabe, dass ein TOE in einen früheren
Zustand zurückkehren kann. Wenn die Informationen, die für den Rollback auf den vorherigen Zustand
benötigt werden, gelöscht wurden, stehen diese Anforderungen im Widerspruch zueinander;
d) mehrfache Iterationen von FDP_ACC.1 „Subset access control“, besonders wenn einige Iterationen
dieselben Subjekte, Objekte oder Operationen abdecken. Wenn eine SFR-Zugriffskontrolle einem Subjekt
erlaubt, eine Operation an einem Objekt durchzuführen, während eine andere SFR-Zugriffskontrolle dies
nicht erlaubt, stehen diese Anforderungen im Widerspruch zueinander.
8.8.2 Evaluierung der Unteraufgabe (APE_REQ.2)
genau definiert sind, ob sie in sich konsistent sind und ob die SFRs die Sicherheitszielsetzungen des TOEs
erfüllen.
8.8.2.2 Eingaben
a) das PP.
8.8.2.3 Aktion APE_REQ.2.1E
ISO/IEC 15408-3 APE_REQ.2.1C: Die Aussage zu den Sicherheitsanforderungen müssen die SFRs und die SARs
beschreiben.
c) durch Verweisung auf eine einzelne Komponente in einem PP, mit der das PP beansprucht, konform zu
sein;
d) durch Verweisung auf eine einzelne Komponente in einem Sicherheitsanforderungspaket, mit dem das
PP beansprucht, konform zu sein;
49
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
c) durch Verweisung auf eine einzelne Komponente in einem PP, mit der das PP beansprucht, konform zu
sein;
d) durch Verweisung auf eine einzelne Komponente in einem Sicherheitsanforderungspaket, mit dem das
PP beansprucht, konform zu sein;
ISO/IEC 15408-3 APE_REQ.2.2C: Alle Subjekte, Objekte, Operationen, Sicherheitsattribute, externen Entitäten
und andere in den SFRs und SARs verwendeten Begriffe müssen definiert sein.
Der Evaluator muss das PP untersuchen, um festzustellen, ob alle Subjekte, Objekte, Operationen,
Sicherheitsattribute, externen Entitäten und sonstigen Begriffe, die in den SFRs und den SARs verwendet
werden, definiert sind.
Der Evaluator stellt fest, dass das PP Folgendes definiert:
Operationen;
werden.
Äußersten getrieben werden, indem der Verfasser des PP gezwungen wird, jedes einzelne Wort zu definieren.
50
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
untergebracht werden können. Dies kann insbesondere dann der Fall sein, wenn die gleichen Begriffe im
übrigen PP verwendet werden.
ISO/IEC 15408-3 APE_REQ.2.3C: Die Aussage zu den Sicherheitsanforderungen muss alle Operationen im
verwendet wird, identifiziert werden. Dies umfasst sowohl abgeschlossene als auch nicht abgeschlossene
Operationen. Die Identifizierung kann durch typografische Unterscheidungen, durch explizite Kennzeichnung
im umgebenden Text oder durch jedes andere Unterscheidungsmittel erfolgen.
ISO/IEC 15408-3 APE_REQ.2.4C: Alle Operationen müssen korrekt durchgeführt werden.
ISO/IEC 15408-3 APE_REQ.2.5C: Jede Abhängigkeit der Sicherheitsanforderungen muss entweder erfüllt sein,
wird.
51
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Abhängigkeit der Sicherheitsanforderungen entweder erfüllt ist oder ob die Begründung der
Sicherheitsanforderungen die Nichterfüllung der Abhängigkeit rechtfertigt.
In der Begründung, dass eine Abhängigkeit nicht erfüllt ist, sollte ebenfalls angesprochen werden,
a) warum die Abhängigkeit nicht erforderlich oder sinnvoll ist; wobei in diesem Fall keine weiteren
ISO/IEC 15408-3 APE_REQ.2.6C: Die Begründung für die Sicherheitsanforderungen muss jede SFR zu den
Sicherheitszielsetzungen für den TOE zurückverfolgen.
Der Evaluator muss prüfen, ob die Begründung der Sicherheitsanforderungen jede SFR zu den
Sicherheitszielsetzungen für den TOE zurückverfolgt.
Der Evaluator stellt fest, dass jede SFR zu mindestens einer Sicherheitszielsetzung für den TOE rückverfolgt
wird.
Eine fehlende Rückverfolgbarkeit bedeutet, dass entweder die Begründung der Sicherheitszielsetzungen
unvollständig ist, die Sicherheitszielsetzungen für den TOE unvollständig sind oder die SFR keinen sinnvollen
Zweck hat.
ISO/IEC 15408-3 APE_REQ.2.7C: Die Begründung für die Sicherheitsanforderungen muss nachweisen, dass die
SFRs alle Sicherheitszielsetzungen für den TOE erfüllen.
Der Evaluator muss die Begründung der Sicherheitszielsetzungen untersuchen, um festzustellen, ob sie bei
jeder Sicherheitszielsetzung für den TOE die Eignung der SFRs zur Erfüllung dieser Sicherheitszielsetzung für
den TOE begründet.
Wenn keine SFRs zur Sicherheitszielsetzung für den TOE rückverfolgt werden, wird die Evaluatorenaktion,
Der Evaluator stellt fest, dass die Begründung für eine Sicherheitszielsetzung für den TOE nachweist, dass die
SFRs ausreichend sind: Wenn alle SFRs, die zur Zielsetzung rückverfolgt werden, erfüllt sind, ist die
Sicherheitszielsetzung für den TOE erreicht.
Wenn die SFRs, die zu einer Sicherheitszielsetzung für den TOE rückverfolgt werden, nicht abgeschlossene
Zuordnungen bzw. nicht abgeschlossene oder eingeschränkte Auswahlen haben, stellt der Evaluator fest, dass
bei jeder denkbaren Vervollständigung oder jeder denkbaren Kombination von Vervollständigungen dieser
Operationen die Sicherheitszielsetzung immer noch erfüllt ist.
52
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator stellt auch fest, dass jede SFR, die zu einer Sicherheitszielsetzung für den TOE rückverfolgt wird,
notwendig ist: Wenn die SFR erfüllt ist, trägt sie tatsächlich zur Erreichung der Sicherheitszielsetzung bei.
Es ist zu beachten, dass die Rückverfolgungen von den SFRs bis hin zu den Sicherheitszielsetzungen für den
TOE, die in der Begründung der Sicherheitsanforderungen aufgeführt sind, ein Teil der Begründung sein
können, aber keine Begründung für sich selbst darstellen.
ISO/IEC 15408-3 APE_REQ.2.8C: Die Begründung für die Sicherheitsanforderungen muss erklären, warum die
SARs ausgewählt wurden.
Der Evaluator muss prüfen, ob die Begründung der Sicherheitsanforderungen erläutert, warum die SARs
gewählt wurden.
Der Evaluator wird daran erinnert, dass jede Erläuterung richtig ist, solange sie stimmig ist und weder die
SARs noch die Erläuterung offensichtliche Inkonsistenzen mit dem übrigen PP aufweisen.
Ein Beispiel für eine offensichtliche Inkonsistenz zwischen den SARs und dem übrigen PP wäre, wenn es zwar
sehr fähige Bedrohungsagenten gäbe, aber ein AVA_VAN SAR, das nicht vor diesen Bedrohungsagenten
schützt.
ISO/IEC 15408-3 APE_REQ.2.9C: Die Aussage zu den Sicherheitsanforderungen muss in sich konsistent sein.
konsistent ist.
zueinander stehen.
53
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
9 Klasse ASE: Evaluierung der Sicherheitsvorgabe
9.1 Einleitung
In diesem Abschnitt wird die Evaluierung einer ST beschrieben. Die Evaluierung der ST sollte vor allen
TOE-Evaluierungsunteraufgaben begonnen werden, da die ST die Grundlage und den Kontext für die
Durchführung dieser Unteraufgaben liefert. Die Evaluierungsmethodik in diesem Unterabschnitt basiert auf
den Anforderungen an die ST, wie in ISO/IEC 15408-3, Klasse ASE festgelegt.
Dieser Abschnitt sollte zusammen mit Anhang A, Anhang B und Anhang C, Leitlinien für Operationen, in
ISO/IEC 15408-1 verwendet werden, da diese Anhänge die Begriffe hier verdeutlichen und viele Beispiele
liefern.
9.2.1 Wiederverwendung der Evaluierungsergebnisse von zertifizierten PPs
Bei der Evaluierung einer ST, die auf einem oder mehreren zertifizierten PPs basiert, kann es möglich sein, die
Tatsache, dass diese PPs zertifiziert wurden, wiederzuverwenden. Das Potential für die Wiederverwendung
des Ergebnisses eines zertifizierten PPs ist größer, wenn die ST keine zusätzlichen Bedrohungen, OSPs,
Annahmen, Sicherheitszielsetzungen und/oder Sicherheitsanforderungen zu denen des PP enthält. Wenn die
ST wesentlich mehr als das zertifizierte PP enthält, ist eine Wiederverwendung möglicherweise überhaupt
nicht sinnvoll.
Dem Evaluator ist es gestattet, die Ergebnisse der PP-Evaluierung wiederzuverwenden, indem er bestimmte
Analysen nur teilweise oder gar nicht durchführt, wenn diese Analysen oder Teile davon bereits im Rahmen
der PP-Evaluierung durchgeführt wurden. Dabei sollte der Evaluator davon ausgehen, dass die Analysen im
PP korrekt durchgeführt wurden.
Ein Beispiel wäre, wenn das PP eine Menge Sicherheitsanforderungen enthält und diese bei der Evaluierung
des PP als in sich konsistent bestimmt wurden. Wenn die ST genau die gleichen Anforderungen verwendet,
muss die Konsistenzanalyse bei der ST-Evaluierung nicht wiederholt werden. Wenn die ST eine oder mehrere
Anforderungen hinzufügt oder Operationen an diesen Anforderungen durchführt, muss die Analyse
wiederholt werden. Es kann jedoch möglich sein, bei dieser Konsistenzanalyse Arbeit zu sparen, indem die
Tatsache genutzt wird, dass die ursprünglichen Anforderungen in sich konsistent sind. Wenn die
ursprünglichen Anforderungen in sich konsistent sind, muss der Evaluator nur feststellen, dass
a) die Menge aller neuen und/oder geänderten Anforderungen in sich konsistent ist; und
b) die Menge aller neuen und/oder geänderten Anforderungen gegenüber den ursprünglichen
Anforderungen konsistent ist.
Der Evaluator vermerkt im ETR jeweils, wo Analysen aus diesem Grund nicht oder nur teilweise durchgeführt
werden.
9.3 ST-Einleitung (ASE_INT)
9.3.1 Evaluierung der Unteraufgabe (ASE_INT.1)
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob die ST und der TOE korrekt identifiziert
werden, ob der TOE auf drei Abstraktionsebenen (TOE-Verweisung, TOE-Übersicht und TOE-Beschreibung)
korrekt in ausformulierter Weise beschrieben wird und ob diese drei Beschreibungen untereinander
konsistent sind.
54
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
9.3.1.2 Eingaben
a) die ST.
9.3.1.3 Aktion ASE_INT.1.1E
ISO/IEC 15408-3 ASE_INT.1.1C: Die ST-Einleitung muss eine ST-Verweisung, eine TOE-Verweisung, einen
TOE-Überblick und eine TOE-Beschreibung enthalten.
9.3.1.3.1 Workunit ASE_INT.1-1
Der Evaluator muss prüfen, ob die ST-Einleitung eine ST-Verweisung, eine TOE-Verweisung, einen
TOE-Überblick und eine TOE-Beschreibung enthält.
ISO/IEC 15408-3 ASE_INT.1.2C: Die ST-Verweisung muss die ST eindeutig identifizieren.
Der Evaluator muss die ST-Verweisung untersuchen, um festzustellen, dass sie die ST eindeutig identifiziert.
Der Evaluator stellt fest, dass die ST-Verweisung die ST selbst identifiziert, so dass sie leicht von anderen STs
unterschieden werden kann, und dass sie auch jede Version der ST eindeutig identifiziert, z. B. unter
Einbeziehung einer Versionsnummer und/oder eines Veröffentlichungsdatums.
Bei Evaluierungen, bei denen ein CM-System zur Verfügung gestellt wird, kann der Evaluator die Eindeutigkeit
der Verweisung durch Prüfung der Konfigurationsliste validieren. In den anderen Fällen sollte die ST über ein
Verweisungssystem verfügen, das in der Lage ist, eindeutige Verweisungen zu unterstützen (z. B. Verwendung
von Zahlen, Buchstaben oder Daten).
ISO/IEC 15408-3 ASE_INT.1.3C: Die TOE-Verweisung muss den TOE identifizieren.
Der Evaluator muss die TOE-Verweisung untersuchen, um festzustellen, dass sie den TOE identifiziert.
Der Evaluator stellt fest, dass die TOE-Verweisung den TOE identifiziert, so dass klar ist, auf welchen TOE sich
die ST bezieht, und dass sie auch die Version des TOEs identifiziert, z. B. unter Einbeziehung einer Versions-/
Freigabe-/ Build-Nummer oder eines Freigabedatums.
Der Evaluator muss die TOE-Verweisung untersuchen, um festzustellen, dass sie nicht irreführend ist.
Wenn sich der TOE auf ein oder mehrere namhafte Produkte bezieht, ist es erlaubt, dies in der
TOE-Verweisung kenntlich zu machen. Diese Möglichkeit sollte allerdings nicht verwendet werden, um
Verbraucher zu täuschen: Situationen, in denen nur ein kleiner Teil eines Produkts evaluiert wird, die
TOE-Verweisung dies jedoch nicht kenntlich macht, sind nicht erlaubt.
ISO/IEC 15408-3 ASE_INT.1.4C: Der TOE-Überblick muss die Verwendung und wesentliche Sicherheitsmerkmale
des TOEs zusammenfassen.
55
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss den TOE-Überblick untersuchen, um festzustellen, dass er die Verwendung und die
wichtigsten Sicherheitsmerkmale des TOEs beschreibt.
Der TOE-Überblick sollte kurz (d. h. mehrere Absätze) die Verwendung und die wichtigsten Sicherheits-
merkmale des TOEs beschreiben. Der TOE-Überblick sollte es potentiellen Verbrauchern ermöglichen, schnell
festzustellen, ob der TOE für ihre Sicherheitsbedürfnisse geeignet sein kann.
Der TOE-Überblick in einer ST für einen zusammengesetzten TOE sollte eher die Verwendung und das
wichtigste Sicherheitsmerkmal des zusammengesetzten TOE beschreiben als die der einzelnen
TOE-Komponenten.
Der Evaluator stellt fest, dass der Überblick für Verbraucher klar genug ist und ausreicht, um ihnen ein
allgemeines Verständnis der beabsichtigten Verwendung und der wichtigsten Sicherheitsmerkmale des TOEs
zu vermitteln.
ISO/IEC 15408-3 ASE_INT.1.5C: Der TOE-Überblick muss den TOE-Typ identifizieren.
Der Evaluator muss prüfen, dass der TOE-Überblick den TOE-Typ identifiziert.
Der Evaluator muss den TOE-Überblick untersuchen, um festzustellen, dass der TOE-Typ nicht irreführend
ist.
Es gibt Situationen, in denen der allgemeine Verbraucher aufgrund des TOEs-Typs eine bestimmte
Funktionalität des TOEs erwarten würde. Wenn diese Funktionalität im TOE nicht vorhanden ist, stellt der
Evaluator fest, dass diese fehlende Funktionalität angemessen im TOE-Überblick erörtert wird.
Es gibt auch TOEs, bei denen der allgemeine Verbraucher erwarten würde, dass der TOE aufgrund seines
TOE-Typs in einer bestimmten Betriebsumgebung betrieben werden sollte. Ist der TOE nicht in der Lage, in
einer solchen Betriebsumgebung zu arbeiten, stellt der Evaluator fest, dass dies im TOE-Überblick angemessen
erörtert wird.
ISO/IEC 15408-3 ASE_INT.1.6C: Der TOE-Überblick muss jede nicht im TOE enthaltene, aber für den TOE
erforderliche Hardware/Software/Firmware identifizieren.
Der Evaluator muss den TOE-Überblick untersuchen, um festzustellen, dass er jede nicht im TOE enthaltene,
aber für den TOE erforderliche Hardware/Software/Firmware identifiziert.
Während einige TOEs eigenständig laufen können, benötigen andere TOEs (insbesondere Software-TOEs)
zusätzliche Hardware, Software oder Firmware für den Betrieb. Wenn der TOE keine Hardware, Software oder
Firmware benötigt, ist diese Workunit nicht anwendbar und gilt daher als erfüllt.
Der Evaluator stellt fest, dass der TOE-Überblick jede zusätzliche Hardware, Software und Firmware
identifiziert, die der TOE zum Betrieb benötigt. Diese Identifizierung muss nicht erschöpfend, aber detailliert
genug sein, damit potentielle Verbraucher des TOEs feststellen können, ob ihre derzeitige Hardware, Software
und Firmware die Verwendung des TOEs unterstützen, und, falls dies nicht der Fall ist, welche zusätzliche
Hardware, Software und/oder Firmware benötigt wird.
ISO/IEC 15408-3 ASE_INT.1.7C: Die TOE-Beschreibung muss den physischen Umfang des TOEs beschreiben.
56
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss die TOE-Beschreibung untersuchen, um festzustellen, dass sie den physischen Umfang
des TOEs beschreibt.
Der Evaluator stellt fest, dass die Beschreibung des TOEs die Hardware-, Firmware-, Software- und
Leitlinienteile auflistet, aus denen der TOE besteht, und sie in einem Detaillierungsgrad beschreibt, der
ausreicht, um dem Leser ein allgemeines Verständnis dieser Teile zu vermitteln.
Der Evaluator stellt auch fest, dass es keine möglichen Missverständnisse darüber gibt, ob ein Hardware-,
Firmware-, Software- oder Leitlinienteil Teil des TOEs ist oder nicht.
ISO/IEC 15408-3 ASE_INT.1.8C: Die TOE-Beschreibung muss den logischen Umfang des TOEs beschreiben.
Der Evaluator muss die TOE-Beschreibung untersuchen, um festzustellen, dass sie den logischen Umfang des
TOEs beschreibt.
Der Evaluator stellt fest, dass die TOE-Beschreibung die logischen Sicherheitsmerkmale behandelt, die vom
TOE in einem Detaillierungsgrad angeboten werden, der ausreicht, um dem Leser ein ausreichendes,
allgemeines Verständnis dieser Merkmale zu vermitteln.
Der Evaluator stellt auch fest, dass es keine möglichen Missverständnisse darüber gibt, ob ein logisches
Sicherheitsmerkmal vom TOE angeboten wird oder nicht.
Eine ST für einen zusammengesetzten TOE kann auf die Beschreibung des logischen Umfangs der
Komponenten-TOEs verweisen, die in den STs des Komponenten-TOE enthalten ist, um den größten Teil
dieser Beschreibung für den zusammengesetzten TOE bereitzustellen. Der Evaluator stellt jedoch fest, dass
die ST des zusammengesetzten TOE eindeutig behandelt, welche Merkmale der einzelnen Komponenten nicht
innerhalb des zusammengesetzten TOE und daher nicht ein Merkmal des zusammengesetzten TOE sind.
9.3.1.4 Aktion ASE_INT.1.2E
Der Evaluator muss die TOE-Verweisung, den TOE-Überblick und die TOE-Beschreibung untersuchen, um
festzustellen, dass sie untereinander konsistent sind.
9.4 Konformitätsansprüche (ASE_CCL)

9.4.1 Evaluierung der Unteraufgabe (ASE_CCL.1)
Die Zielsetzung dieser Unteraufgabe ist es, die Gültigkeit verschiedener Konformitätsansprüche zu
bestimmen. Diese beschreiben, wie die ST und der TOE mit der ISO/IEC 15408 konform sind und wie die ST
mit den PPs und Paketen übereinstimmt.
9.4.1.2 Eingaben
a) die ST,
b) das/die PP(s), mit dem/denen die ST Konformität beansprucht,
c) das/die Paket(e), mit dem/denen die ST Konformität beansprucht.
57
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
9.4.1.3 Aktion ASE_CCL.1.1E
ISO/IEC 15408-3 ASE_CCL.1.1C: Der Konformitätsanspruch muss einen Konformitätsanspruch nach

ISO/IEC-15408 enthalten, der die Version der ISO/IEC 15408 angibt, mit der die ST und der TOE Konformität
beanspruchen.
9.4.1.3.1 Workunit ASE_CCL.1-1
Der Evaluator muss prüfen, ob der Konformitätsanspruch einen Konformitätsanspruch nach ISO/IEC-15408
enthält, der die Version der ISO/IEC 15408 identifiziert, mit der die ST und der TOE Konformität
beanspruchen.
Der Evaluator stellt fest, dass der Konformitätsanspruch nach ISO/IEC 15408 die Version der ISO/IEC 15408
identifiziert, die zur Entwicklung dieser ST verwendet wurde. Diese sollte die Versionsnummer der
ISO/IEC 15408 und, sofern nicht die internationale englische Version der ISO/IEC 15408 verwendet wurde,
die Sprache der verwendeten Version der ISO/IEC 15408 enthalten.
Bei einem zusammengesetzten TOE wird der Evaluator alle Unterschiede zwischen der für eine Komponente
beanspruchten Version der ISO/IEC 15408 und der für den zusammengesetzten TOE beanspruchten Version
der ISO/IEC 15408 berücksichtigen. Wenn sich die Versionen unterscheiden, wird der Evaluator beurteilen,
ob die Unterschiede zwischen den Versionen zu widersprüchlichen Ansprüchen führen werden.
Für Fälle, in denen sich die Konformitätsansprüche nach ISO/IEC 15408 für den Basis-TOE und den
abhängigen TOE auf verschiedene Hauptversionen der ISO/IEC 15408 beziehen (z. B. lautet der
Konformitätsanspruch einer Komponente des TOEs ISO/IEC 15408 v2.x und der des anderen
Komponenten-TOE ISO/IEC 15408 v3.x), wird der Konformitätsanspruch für den zusammengesetzten TOE
die frühere Version der ISO/IEC 15408 sein, da die ISO/IEC 15408 mit dem Ziel entwickelt wurde,
Abwärtskompatibilität sicherzustellen (auch wenn dies nicht im engeren Sinne erreicht werden kann, wird
davon ausgegangen, dass es grundsätzlich erreicht wird).
ISO/IEC 15408-3 ASE_CCL.1.2C: Der Konformitätsanspruch nach ISO/IEC 15408 muss die Konformität der ST
mit der ISO/IEC 15408-2 entweder als ISO/IEC 15408-2-konform oder als ISO/IEC 15408-2-erweitert
beschreiben.
ISO/IEC 15408-2-konform oder ISO/IEC 15408-2-erweitert für die ST angibt.
Bei einem zusammengesetzten TOE berücksichtigt der Evaluator, ob dieser Anspruch nicht nur mit der
ISO/IEC 15408-2, sondern auch gegenüber den Konformitätsansprüchen der ISO/IEC 15408-2 durch die
einzelnen Komponenten-TOEs konsistent ist. D. h., wenn ein oder mehrere Komponenten-TOEs den Anspruch
erheben, ISO/IEC 15408-2-erweitert zu sein, dann sollte auch der zusammengesetzte TOE den Anspruch
erheben, ISO/IEC 15408-2-erweitert zu sein.
Der Konformitätsanspruch nach ISO/IEC 15408 für den zusammengesetzten TOE kann ISO/IEC 15408-2-
erweitert sein, auch wenn die Komponenten-TOEs Teil-2-konform sind, falls zusätzliche SFRs für den
Basis-TOE beansprucht werden (siehe Leitlinien für den zusammengesetzten TOE für ASE_CCL.1.6C)
ISO/IEC 15408-3 ASE_CCL.1.3C: Der Konformitätsanspruch nach ISO/IEC 15408 muss die Konformität der ST
mit der ISO/IEC 15408-3 entweder als ISO/IEC 15408-3-konform oder als ISO/IEC 15408-3-erweitert
beschreiben.
58
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
ISO/IEC 15408-3-konform oder ISO/IEC 15408-3-erweitert für die ST angibt.
ISO/IEC 15408-3 ASE_CCL.1.4C: Der Konformitätsanspruch nach ISO/IEC 15408 muss mit der erweiterten
Komponentendefinition konsistent sein.
fest, dass die erweiterte Komponentendefinition keine Funktionskomponenten definiert.
fest, dass die erweiterte Komponentendefinition mindestens eine erweiterte Funktionskomponente definiert.
fest, dass die erweiterte Komponentendefinition keine Vertrauenswürdigkeitskomponenten definiert.
fest, dass die erweiterte Komponentendefinition mindestens eine erweiterte Vertrauenswürdigkeits-
komponente definiert.
ISO/IEC 15408-3 ASE_CCL.1.5C: Der Konformitätsanspruch muss alle PPs und Sicherheitsanforderungspakete
identifizieren, mit denen die ST Konformität beansprucht.
Der Evaluator muss prüfen, ob der Konformitätsanspruch einen PP-Anspruch enthält, der alle PPs
identifiziert, mit denen die ST Konformität beansprucht.
Wenn die ST nicht die Konformität mit einem PP beansprucht, ist diese Workunit nicht anwendbar und gilt
daher als erfüllt.
Der Evaluator stellt fest, dass alle empfohlenen PPs eindeutig identifiziert werden (z. B. durch Titel und
Versionsnummer oder durch die in der Einführung dieses PPs enthaltene Identifizierung).
Der Evaluator wird daran erinnert, dass Ansprüche auf eine teilweise Konformität mit einem PP nicht zulässig
sind. Daher kann die Konformität mit einem PP, das eine zusammengesetzte Lösung erfordert, in einer ST für
einen zusammengesetzten TOE beansprucht werden. Die Konformität mit einem solchen PP wäre bei der
Evaluierung der Komponenten-TOEs nicht möglich gewesen, da diese Komponenten die zusammengesetzte
Lösung nicht erfüllt hätten. Dies ist nur in den Fällen möglich, in denen das „zusammengesetzte“ PP die
Anwendung des Ansatzes zur Evaluierung der Zusammensetzung (Verwendung von ACO-Komponenten)
erlaubt.
Die ST für einen zusammengesetzten TOE identifiziert die ST der Komponenten-TOEs, aus denen sich die
zusammengesetzte ST zusammensetzt. Der zusammengesetzte TOE beansprucht im Wesentlichen die
Konformität mit den STs der Komponenten-TOEs.
59
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss prüfen, ob der Konformitätsanspruch einen Paketanspruch enthält, der alle Pakete
identifiziert, mit denen die ST Konformität beansprucht.
Wenn die ST nicht die Konformität mit einem Paket beansprucht, ist diese Workunit nicht anwendbar und gilt
daher als erfüllt.
Der Evaluator stellt fest, dass alle empfohlenen Pakete eindeutig identifiziert werden (z. B. durch Titel und
Versionsnummer oder durch die in der Einführung dieses Pakets enthaltene Identifizierung).
Der Evaluator stellt fest, dass die Komponenten-TOE-STs, von denen der zusammengesetzte TOE abgeleitet
ist, ebenfalls eindeutig identifiziert werden.
Der Evaluator wird daran erinnert, dass Ansprüche auf eine teilweise Konformität mit einem Paket nicht
zulässig sind.
ISO/IEC 15408-3 ASE_CCL.1.6C: Der Konformitätsanspruch muss jede Konformität der ST mit einem Paket
entweder als Paket-konform oder als Paket-erweitert beschreiben.
Der Evaluator muss prüfen, ob der Konformitätsanspruch für jedes identifizierte Paket entweder den
Anspruch Paketname-konform oder Paketname-ergänzt angibt.
Wenn die ST nicht die Konformität mit einem Paket beansprucht, ist diese Workunit nicht anwendbar und gilt
daher als erfüllt.
Wenn der Anspruch auf Paketkonformität Paketname-konform enthält, stellt der Evaluator Folgendes fest.
a) Handelt es sich bei dem Paket um ein Sicherheitspaket, so enthält die ST alle im Paket enthaltenen SARs,
aber keine zusätzlichen SARs.
b) Handelt es sich bei dem Paket um ein Funktionspaket, so enthält die ST alle im Paket enthaltenen SFRs,
aber keine zusätzlichen SFRs.
Wenn der Anspruch auf Paketkonformität Paketname-ergänzt enthält, stellt der Evaluator Folgendes fest.
a) Handelt es sich bei dem Paket um ein Sicherheitspaket, dann enthält die ST alle im Paket enthaltenen SARs
und mindestens eine zusätzliche SAR oder mindestens eine SAR, die hierarchisch zu einer SAR im Paket
angeordnet ist.
b) Handelt es sich bei dem Paket um ein Funktionspaket, so enthält die ST alle im Paket enthaltenen SFR und
mindestens eine zusätzliche SFR oder mindestens eine SFR, die hierarchisch zu einer SFR im Paket
angeordnet ist.
ISO/IEC 15408-3 ASE_CCL.1.7C: Die Begründung für den Konformitätsanspruch muss nachweisen, dass der
TOE-Typ mit dem TOE-Typ in den PPs konsistent ist, für die Konformität beansprucht wird.
Der Evaluator muss die Begründung für den Konformitätsanspruch untersuchen, um festzustellen, dass der
TOE-Typ mit allen TOE-Typen der PPs konsistent ist.
daher als erfüllt.
60
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Die Beziehung zwischen den Typen kann einfach sein: eine ST für eine Firewall, die Konformität mit einem
Firewall-PP beansprucht, oder komplexer: eine ST für eine Chipkarte, die gleichzeitig Konformität mit einer
Menge PPs beansprucht (ein PP für die integrierte Schaltung, ein PP für das Betriebssystem einer Chipkarte
und zwei PPs für zwei Anwendungen auf der Chipkarte).
Bei einem zusammengesetzten TOE stellt der Evaluator fest, ob die Begründung für den Konformitätsanspruch
nachweist, dass die TOE-Typen der Komponenten-TOEs gegenüber dem zusammengesetzten TOE-Typ
konsistent sind. Dies bedeutet nicht, dass sowohl die Komponenten- als auch die zusammengesetzten
TOE-Typen gleich sein müssen, sondern vielmehr, dass die Komponenten-TOEs für die Integration geeignet
sind, um den zusammengesetzten TOE bereitzustellen. Es sollte in der zusammengesetzten TOE-ST deutlich
gemacht werden, welche SFRs nur als Ergebnis der Zusammensetzung enthalten sind und nicht als SFRs in der
Evaluierung des Basis- und abhängigen TOE (z. B. EALx) untersucht wurden.
ISO/IEC 15408-3 ASE_CCL.1.8C: Die Begründung für den Konformitätsanspruch muss nachweisen, dass die
Aussage zur Sicherheitsproblemdefinition mit der Aussage zur Sicherheitsproblemdefinition in den PPs konsistent
Der Evaluator muss die Begründung für den Konformitätsanspruch untersuchen, um festzustellen, dass sie
die Konsistenz der Aussage der Sicherheitsproblemdefinition, wie sie in der Konformitätserklärung des PP
festgelegt ist, gegenüber den Aussagen der Sicherheitsproblemdefinition in den PPs nachweist, mit denen
Konformität beansprucht wird.
daher als erfüllt.
Wenn das PP keine Aussage der Sicherheitsproblemdefinition enthält, ist diese Workunit nicht anwendbar
a) die Bedrohungen in der ST eine Obermenge der Bedrohungen im PP sind, mit dem Konformität
beansprucht wird, oder mit diesen identisch sind;
b) die OSPs in der ST eine Obermenge der OSPs im PP sind, mit dem Konformität beansprucht wird, oder mit
diesen identisch sind;
c) die Annahmen in der ST mit den Annahmen im PP, mit dem Konformität beansprucht wird, identisch sind,
wobei es zwei mögliche Ausnahmen gibt, die in den folgenden beiden Aufzählungspunkten beschrieben
werden:
eine Annahme (oder ein Teil einer Annahme) aus dem PP kann weggelassen werden, wenn alle
Sicherheitszielsetzungen für die Betriebsumgebung, die diese Annahme (oder einen Teil einer
Annahme) betreffen, durch Sicherheitszielsetzungen für den TOE ersetzt werden;
eine Annahme zu den im PP definierten Annahmen kann hinzugefügt werden, wenn eine Begründung
gegeben wird, warum die neue Annahme weder eine Bedrohung (oder einen Teil einer Bedrohung)
abschwächt, die durch Sicherheitszielsetzungen für den TOE im PP angesprochen werden soll, noch
eine OSP (oder einen Teil einer OSP) erfüllt, die durch Sicherheitszielsetzungen für den TOE im PP
angesprochen werden soll.
61
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Bei der Untersuchung einer ST, die ein PP beansprucht, das Annahmen aus dem PP weglässt oder neue
Annahmen hinzufügt, muss der Evaluator genau festlegen, ob die oben genannten Bedingungen erfüllt sind.
Die folgende Erörterung liefert die Motivation und Beispiele für diese Fälle:
Beispiel für das Weglassen einer Annahme: Ein PP kann eine Annahme enthalten, die besagt, dass die
Betriebsumgebung eine unbefugte Änderung oder das Abfangen von Daten, die an eine externe
Schnittstelle des TOEs gesendet werden, verhindert. Dies kann der Fall sein, wenn der TOE Daten im
Klartext und ohne Integritätsschutz an dieser Schnittstelle akzeptiert und davon ausgegangen wird, dass
er sich in einer sicheren Betriebsumgebung befindet, die Angreifern den Zugriff auf diese Daten verwehrt.
Die Annahme wird dann im PP auf eine Zielsetzung für die Betriebsumgebung abgebildet, die angibt, dass
die an dieser Schnittstelle ausgetauschten Daten durch geeignete Maßnahmen in der Betriebsumgebung
geschützt sind. Wenn eine ST, die dieses PP beansprucht, einen sichereren TOE definiert, der eine
zusätzliche Sicherheitszielsetzung hat, die angibt, dass der TOE selbst diese Daten schützt, z. B. durch
Bereitstellung eines sicheren Kanals für die Verschlüsselung und den Integritätsschutz aller über diese
Schnittstelle übertragenen Daten, kann die entsprechende Zielsetzung und die Annahme für die
Betriebsumgebung aus der ST weggelassen werden. Dies wird auch als Neuzuweisung der Zielsetzung
bezeichnet, da die Zielsetzung aus der Betriebsumgebung erneut dem TOE zugewiesen wird. Es ist zu
beachten, dass dieser TOE in einer Betriebsumgebung, die die weggelassene Annahme erfüllt, immer noch
sicher ist und daher immer noch das PP erfüllt.
Beispiel für das Hinzufügen einer Annahme: In diesem Beispiel soll das PP die Anforderungen an einen
TOE vom Typ „Firewall“ festlegen, und ein ST-Autor möchte dieses PP für einen TOE beanspruchen, der
eine Firewall implementiert, aber zusätzlich die Funktionalität einer Komponente für ein Virtuelles
Privates Netzwerk (VPN) bietet. Für die VPN-Funktionalität benötigt der TOE kryptographische Schlüssel,
und diese Schlüssel müssen unter Umständen auch von der Betriebsumgebung sicher gehandhabt werden
(z. B. wenn symmetrische Schlüssel zur Sicherung der Netzwerkverbindung verwendet werden und daher
auf sichere Weise anderen Komponenten im Netzwerk zur Verfügung gestellt werden müssen). In diesem
Fall ist es akzeptabel, die Annahme hinzuzufügen, dass die vom VPN verwendeten kryptographischen
Schlüssel von der Betriebsumgebung sicher gehandhabt werden. Diese Annahme bezieht sich nicht auf
Bedrohungen oder OSPs des PP und erfüllt daher die oben genannten Bedingungen.
Gegenbeispiel für das Hinzufügen einer Annahme: In einer Variante des ersten Beispiels kann ein PP
bereits eine Zielsetzung für den TOE enthalten, um einen sicheren Kanal für eine seiner Schnittstellen
bereitzustellen, und diese Zielsetzung wird auf die Gefahr einer unbefugten Änderung oder eines
unbefugten Lesens der Daten auf dieser Schnittstelle abgebildet. In diesem Fall ist es eindeutig nicht
erlaubt, dass eine ST, die dieses PP beansprucht, eine Annahme für die Betriebsumgebung hinzufügt, die
davon ausgeht, dass die Betriebsumgebung die Daten auf dieser Schnittstelle vor Veränderung oder
unbefugtem Lesen der Daten schützt. Diese Annahme würde eine Bedrohung reduzieren, die durch den
TOE angesprochen werden soll. Daher würde ein TOE, der eine ST mit dieser zusätzlichen Annahme
erfüllt, nicht mehr automatisch das PP erfüllen, und dieser Zusatz ist daher nicht zulässig.
Zweites Gegenbeispiel für das Hinzufügen einer Annahme: Im obigen Beispiel eines TOE, der eine Firewall
implementiert, wäre es nicht zulässig, eine allgemeine Annahme hinzuzufügen, dass der TOE nur mit
vertrauenswürdigen Geräten verbunden ist, da dies offensichtlich wesentliche, für eine Firewall relevante
Bedrohungen beseitigen würde (und zwar, dass es nicht vertrauenswürdigen IP-Verkehr gibt, der
gefiltert werden muss). Daher wäre dieser Zusatz nicht zulässig.
Wenn durch das PP eine nachweisbare Konformität gefordert wird, untersucht der Evaluator die Begründung
für den Konformitätsanspruch, um festzustellen, ob sie nachweist, dass die Aussage der Sicherheitsproblem-
definition der ST gleichwertig oder restriktiver ist als die Aussage der Sicherheitsproblemdefinition im PP, mit
dem Konformität beansprucht wird.
62
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Dazu muss die Begründung des Konformitätsanspruchs nachweisen, dass die Sicherheitsproblemdefinition in
der ST gleichwertig (oder restriktiver) ist als die Sicherheitsproblemdefinition im PP. Das bedeutet, dass
alle TOEs, die die Sicherheitsproblemdefinition in der ST erfüllen würden, auch die Sicherheitsproblem-
definition im PP erfüllen. Dies lässt sich indirekt auch dadurch nachweisen, dass jedes Ereignis, das eine
im PP definierte Bedrohung realisiert oder gegen eine im PP definierte OSP verstößt, auch eine in der ST
angegebene Bedrohung realisieren oder gegen eine in der ST definierte OSP verstoßen würde. Es ist zu
beachten, dass die Erfüllung einer in der ST angegebenen OSP eine im PP angegebene Bedrohung
abwenden kann, oder dass die Abwendung einer in der ST angegebenen Bedrohung eine im PP
angegebene OSP erfüllen kann, so dass Bedrohungen und OSPs sich gegenseitig ersetzen können,
alle Betriebsumgebungen, die der Sicherheitsproblemdefinition im PP entsprechen würden, würden auch

der Sicherheitsproblemdefinition in der ST entsprechen (mit einer Ausnahme im nächsten
Aufzählungspunkt),
neben einer Menge Annahmen in der ST, die erforderlich sind, um die Konformität mit der SPD des PP
nachzuweisen, kann eine ST weitere Annahmen festlegen, jedoch nur, wenn diese zusätzlichen Annahmen
unabhängig von der Sicherheitsproblemdefinition sind und diese nicht beeinflussen, wie im PP definiert.
Genauer gesagt gibt es in der ST keine Annahmen, die Bedrohungen für den TOE ausschließen, denen der
TOE nach dem PP entgegenwirken muss. Ebenso gibt es in der ST keine Annahmen, die Aspekte einer OSP
realisieren, die im PP angegeben sind und die vom TOE nach dem PP erfüllt werden sollen.
Bei einem zusammengesetzten TOE berücksichtigt der Evaluator, ob die Sicherheitsproblemdefinition des
zusammengesetzten TOEs gegenüber der in den STs für die Komponenten-TOEs angegebenen konsistent ist.
Dies wird anhand der nachweisbaren Konformität bestimmt. Insbesondere untersucht der Evaluator die
Begründung für den Konformitätsanspruch, um Folgendes festzustellen.
a) Bedrohungsaussagen und OSPs in der zusammengesetzten TOE-ST stehen nicht im Widerspruch zu

denen aus den Komponenten-STs.
b) Alle in den Komponenten-STs getroffenen Annahmen werden im zusammengesetzten TOE-ST

aufrechterhalten. Das heißt, entweder sollte die Annahme auch in der zusammengesetzten ST vorhanden
sein, oder die Annahme sollte in der zusammengesetzten ST positiv angesprochen werden. Die Annahme
kann durch die Spezifikation von Anforderungen im zusammengesetzten TOE positiv angesprochen
werden, um eine Funktionalität bereitzustellen, die das in der Annahme erfasste Anliegen erfüllt.
Aussage zu den Sicherheitszielsetzungen mit der Aussage zu den Sicherheitszielsetzungen in den PPs konsistent
Der Evaluator muss die Begründung für den Konformitätsanspruch untersuchen, um festzustellen, dass die
Aussage der Sicherheitszielsetzungen, wie sie in der Konformitätserklärung des PP festgelegt ist, gegenüber
der Aussage der Sicherheitszielsetzungen in den PPs, mit denen Konformität beansprucht wird, konsistent ist.
daher als erfüllt.
Begründung für den Konformitätsanspruch erforderlich. Stattdessen bestimmt der Evaluator, ob:
die zu evaluierende ST alle Sicherheitszielsetzungen für den TOE des PP, mit dem Konformität
beansprucht wird, enthält. Es ist zu beachten, dass es zulässig ist für die zu evaluierende ST, zusätzliche
Sicherheitszielsetzungen für den TOE aufzuweisen;
63
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
die Sicherheitszielsetzungen für die Betriebsumgebung in der ST identisch mit den Sicherheits-
zielsetzungen für die Betriebsumgebung im PP sind, mit dem Konformität beansprucht wird, mit zwei
möglichen Ausnahmen, die in den folgenden zwei Aufzählungspunkten beschrieben werden;
eine Sicherheitszielsetzung für die Betriebsumgebung (oder einen Teil einer solchen Sicherheits-
zielsetzung) aus dem PP kann durch dieselbe (denselben Teil der) für den TOE angegebene(n)
Sicherheitszielsetzung ersetzt werden;
eine Sicherheitszielsetzung für die Betriebsumgebung kann zu den im PP definierten Zielsetzungen

hinzugefügt werden, wenn eine Begründung gegeben wird, warum die neue Zielsetzung weder eine
Bedrohung (oder einen Teil einer Bedrohung) abschwächt, die durch Sicherheitszielsetzungen für den
TOE im PP angesprochen werden soll, noch eine OSP (oder einen Teil einer OSP) erfüllt, der durch
Sicherheitszielsetzungen für den TOE im PP angesprochen werden soll.
Bei der Untersuchung einer ST, die ein PP beansprucht, das Sicherheitszielsetzungen für die Betriebs-
umgebung aus dem PP weglässt oder neue Sicherheitszielsetzungen für die Betriebsumgebung hinzufügt,
muss der Evaluator genau festlegen, ob die oben genannten Bedingungen erfüllt sind. Die Beispiele, die für die
Annahmen in der vorangegangenen Workunit angegeben wurden, gelten auch hier.
dass die Aussage der Sicherheitszielsetzungen der ST gleichwertig oder restriktiver ist als die Aussage der
Sicherheitszielsetzungen im PP, mit dem Konformität beansprucht wird.
Dazu muss die Begründung des Konformitätsanspruchs nachweisen, dass die Sicherheitszielsetzungen in der
ST gleichwertig (oder restriktiver) sind als die Sicherheitszielsetzungen im PP. Das bedeutet, dass:
alle TOEs, die die Sicherheitszielsetzungen für den TOE in der ST erfüllen würden, auch die Sicherheits-
zielsetzungen für den TOE im PP erfüllen;
alle Betriebsumgebungen, die die Sicherheitszielsetzungen für die Betriebsumgebung im PP erfüllen

würden, auch die Sicherheitszielsetzungen für die Betriebsumgebung in der ST erfüllen würden (mit einer
Ausnahme im nächsten Aufzählungspunkt);
neben einer Menge Sicherheitszielsetzungen für die Betriebsumgebung in der ST, die zum Nachweis der
Konformität mit der Menge Sicherheitszielsetzungen verwendet werden, die im PP definiert sind, kann
eine ST weitere Sicherheitszielsetzungen für die Betriebsumgebung festlegen, jedoch nur dann, wenn
diese Sicherheitszielsetzungen weder die ursprüngliche Menge Sicherheitszielsetzungen für den TOE
noch die Sicherheitszielsetzungen für die Betriebsumgebung, wie sie im PP definiert sind, mit dem
Konformität beansprucht wird, beeinflussen.
Bei einem zusammengesetzten TOE berücksichtigt der Evaluator, ob die Sicherheitszielsetzungen des
zusammengesetzten TOEs gegenüber denen in den STs für die Komponenten-TOEs angegebenen konsistent
sind. Dies wird anhand der nachweisbaren Konformität bestimmt. Insbesondere untersucht der Evaluator die
Begründung für den Konformitätsanspruch, um Folgendes festzustellen:
a) Die Aussage der Sicherheitszielsetzungen im abhängigen TOE-ST, die für jede IT in der Betriebsumgebung
relevant sind, sind gegenüber der Aussage der Sicherheitszielsetzungen für den TOE im Basis-TOE-ST
konsistent. Es wird nicht erwartet, dass die Aussage der Sicherheitszielsetzungen für die Umgebung
innerhalb der abhängigen TOE-ST alle Aspekte der Aussage der Sicherheitszielsetzungen für den TOE in
der Basis-TOE-ST abdeckt.
b) Die Aussage der Sicherheitszielsetzungen in der zusammengesetzten ST ist gegenüber den Aussagen der
Sicherheitszielsetzungen in den STs für die Komponenten-TOEs konsistent.
64
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Wenn durch das PP eine nachweisbare Konformität gefordert wird, untersucht der Evaluator die Begründung
für den Konformitätsanspruch, um festzustellen, ob sie nachweist, dass die Aussage der Sicherheits-
zielsetzungen der ST mindestens gleichwertig mit der Aussage der Sicherheitszielsetzungen im PP oder der
Komponenten-TOE-ST im Falle einer zusammengesetzten TOE-ST ist.
Aussage zu den Sicherheitsanforderungen mit der Aussage zu den Sicherheitsanforderungen in den PPs konsistent
Der Evaluator muss die ST untersuchen, um festzustellen, ob sie, wie in der Konformitätserklärung des PP
definiert, gegenüber allen Sicherheitsanforderungen in den PPs, mit denen Konformität beansprucht wird,
konsistent ist.
daher als erfüllt.
Begründung für den Konformitätsanspruch erforderlich. Stattdessen bestimmt der Evaluator, ob die Aussage
der Sicherheitsanforderungen in der ST eine Obermenge der Aussage der Sicherheitsanforderungen in dem
PP ist, mit dem Konformität (bei strikter Konformität) beansprucht wird, oder ob sie mit dieser identisch ist.
dass die Aussage der Sicherheitsanforderungen der ST gleichwertig oder restriktiver ist als die Aussage der
Sicherheitsanforderungen im PP, mit dem Konformität beansprucht wird.
Bei
SFRs: Die Begründung für die Konformität in der ST muss nachweisen, dass die von den SFRs in der ST
festgelegten Gesamtanforderungen gleichwertig (oder restriktiver) sind als die Gesamtanforderungen,
die von den SFRs im PP definiert sind. Dies bedeutet, dass alle TOEs, die die Anforderungen erfüllen
würden, die durch die Menge aller SFRs in der ST definiert sind, auch die Anforderungen, die durch die
Menge aller SFRs im PP definiert sind, erfüllen würden.
SARs: Die ST muss alle SARs im PP enthalten, kann aber zusätzliche SARs beanspruchen oder die SARs
durch hierarchisch stärkere SARs ersetzen. Die Vervollständigung der Operationen in der ST muss
konsistent gegenüber den Operationen im PP sein; es wird entweder die gleiche Vervollständigung in der
ST wie im PP verwendet oder eine Vervollständigung, die für eine restriktivere SAR sorgt (es gelten die
Regeln zur Präzisierung).
Bei einem zusammengesetzten TOE berücksichtigt der Evaluator, ob die Sicherheitsanforderungen des
zusammengesetzten TOEs gegenüber denen in den STs für die Komponenten-TOEs angegebenen konsistent
sind. Dies wird anhand der nachweisbaren Konformität bestimmt. Insbesondere untersucht der Evaluator die
Begründung für die Konformität, um Folgendes festzustellen:
a) Die Aussage der Sicherheitsanforderungen in der abhängigen TOE-ST, die für jede IT in der
Betriebsumgebung relevant ist, ist gegenüber der Aussage der Sicherheitsanforderungen für den TOE in
der Basis-TOE-ST konsistent. Es wird nicht erwartet, dass die Aussage der Sicherheitsanforderungen für
die Umgebung innerhalb der abhängigen TOE-ST alle Aspekte der Aussage der Sicherheitsanforderungen
für den TOE in der Basis-TOE-ST abdeckt, da einige SFRs möglicherweise der Aussage der Sicherheits-
anforderungen in der zusammengesetzten TOE-ST hinzugefügt werden müssen. Die Angabe der
Sicherheitsanforderungen in der Basis sollte jedoch den Betrieb der abhängigen Komponente
unterstützen.
65
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
b) Die Aussage der Sicherheitszielsetzungen in der abhängigen TOE-ST, die für jede IT in der
Betriebsumgebung relevant ist, ist gegenüber der Aussage der Sicherheitsanforderungen für den TOE in
der Basis-TOE-ST konsistent. Es wird nicht erwartet, dass die Aussage der Sicherheitszielsetzungen für
die Umgebung innerhalb der abhängigen TOE-ST alle Aspekte der Aussage der Sicherheitsanforderungen
für den TOE in der Basis-TOE-ST abdeckt.
c) Die Aussage der Sicherheitsanforderungen in der zusammengesetzten ST ist gegenüber den Aussagen der
Sicherheitsanforderungen in den STs für die Komponenten-TOEs konsistent.
dass die Aussage der Sicherheitsanforderungen der ST mindestens gleichwertig mit der Aussage der
Sicherheitsanforderungen im PP oder der Komponenten-TOE-ST im Falle einer zusammengesetzten TOE-ST
ist.
9.5 Sicherheitsproblemdefinition (ASE_SPD)

9.5.1 Evaluierung der Unteraufgabe (ASE_SPD.1)
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob das Sicherheitsproblem, das durch den
TOE und seine Betriebsumgebung angesprochen werden soll, klar definiert ist.
9.5.1.2 Eingaben
a) die ST.
9.5.1.3 Aktion ASE_SPD.1.1E
ISO/IEC 15408-3 ASE_SPD.1.1C: Die Sicherheitsproblemdefinition muss die Bedrohungen beschreiben.
9.5.1.3.1 Workunit ASE_SPD.1-1
Der Evaluator muss prüfen, ob die Sicherheitsproblemdefinition die Bedrohungen beschreibt.
der Bedrohungen in der ST nicht vorhanden sein. In diesem Fall ist diese Workunit nicht anwendbar und gilt
daher als erfüllt.
Der Evaluator stellt fest, dass die Sicherheitsproblemdefinition die Bedrohungen beschreibt, denen der TOE
und/oder die Betriebsumgebung entgegenwirken muss.
ISO/IEC 15408-3 ASE_SPD.1.2C: Alle Bedrohungen müssen in Bezug auf einen Bedrohungsagenten, einen
Vermögenswert und eine unerwünschte Aktion beschrieben werden.
Der Evaluator muss die Sicherheitsproblemdefinition untersuchen, um festzustellen, dass alle Bedrohungen
anhand eines Bedrohungsagenten, eines Vermögenswertes und einer unerwünschten Aktion beschrieben
werden.
der Bedrohungen in der ST nicht vorhanden sein. In diesem Fall ist diese Workunit nicht anwendbar und gilt
daher als erfüllt.
66
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Bedrohungsagenten können noch weiter über Aspekte wie Fachkenntnis, Ressource, Möglichkeit und
Motivation beschrieben werden.
ISO/IEC 15408-3 ASE_SPD.1.3C: Die Sicherheitsproblemdefinition muss die OSPs beschreiben.
Der Evaluator muss untersuchen, ob die Sicherheitsproblemdefinition die OSPs beschreibt.
Wenn alle Sicherheitszielsetzungen nur aus Annahmen und Bedrohungen abgeleitet werden, müssen OSPs in
der ST nicht vorhanden sein. In diesem Fall ist diese Workunit nicht anwendbar und gilt daher als erfüllt.
Der Evaluator stellt fest, dass OSP-Aussagen in Form von Regeln oder Leitlinien gemacht werden, die vom TOE
und/oder seiner Betriebsumgebung befolgt werden müssen.
Der Evaluator stellt fest, dass jede OSP ausreichend detailliert erklärt und/oder interpretiert wird, um sie klar
verständlich zu machen; eine klare Darstellung der Grundsatzerklärungen ist notwendig, um die
Rückverfolgung der Sicherheitszielsetzungen zu ermöglichen.
ISO/IEC 15408-3 ASE_SPD.1.4C: Die Sicherheitsproblemdefinition muss die Annahmen über die
Betriebsumgebung des TOEs beschreiben.
Der Evaluator muss die Sicherheitsproblemdefinition untersuchen, um festzustellen, dass er die Annahmen
über die Betriebsumgebung des TOEs beschreibt.
Gibt es keine Annahmen, ist diese Workunit nicht anwendbar und gilt daher als erfüllt.
Der Evaluator stellt fest, dass jede Annahme über die Betriebsumgebung des TOEs hinreichend detailliert
erläutert wird, damit die Verbraucher feststellen können, dass ihre Betriebsumgebung mit der Annahme
übereinstimmt. Wenn die Annahmen nicht klar verstanden werden, kann das Endergebnis sein, dass der TOE
in einer Betriebsumgebung verwendet wird, in der er nicht in sicherer Weise funktioniert.
9.6 Sicherheitszielsetzungen (ASE_OBJ)
9.6.1 Evaluierung der Unteraufgabe (ASE_OBJ.1)
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob die Sicherheitszielsetzungen für die
Betriebsumgebung klar definiert sind.
9.6.1.2 Eingaben
a) die ST.
9.6.1.3 Aktion ASE_OBJ.1.1E
ISO/IEC 15408-3 ASE_OBJ.1.1C: Die Aussage zu den Sicherheitszielsetzungen muss die Sicherheitszielsetzungen
für die Betriebsumgebung beschreiben.
67
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
9.6.1.3.1 Workunit ASE_OBJ.1-1
Der Evaluator muss prüfen, ob die Aussage der Sicherheitszielsetzungen die Sicherheitszielsetzungen für die
Betriebsumgebung definiert.
Der Evaluator prüft, ob die Sicherheitszielsetzungen für die Betriebsumgebung festgelegt sind.
9.6.2 Evaluierung der Unteraufgabe (ASE_OBJ.2)
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob die Sicherheitszielsetzungen die
Sicherheitsproblemdefinition angemessen und vollständig berücksichtigen und ob die Aufteilung dieses
Problems zwischen dem TOE und seiner Betriebsumgebung klar definiert ist.
9.6.2.2 Eingaben
a) die ST.
9.6.2.3 Aktion ASE_OBJ.2.1E
ISO/IEC 15408-3 ASE_OBJ.2.1C: Die Aussage zu den Sicherheitszielsetzungen muss die Sicherheitszielsetzungen
für den TOE und die Sicherheitszielsetzungen für die Betriebsumgebung beschreiben.
Der Evaluator muss prüfen, ob die Aussage der Sicherheitszielsetzungen die Sicherheitszielsetzungen für den
TOE und die Sicherheitszielsetzungen für die Betriebsumgebung definiert.
Der Evaluator prüft, ob beide Kategorien von Sicherheitszielsetzungen klar identifiziert und von der anderen
Kategorie getrennt sind.
ISO/IEC 15408-3 ASE_OBJ.2.2C: Die Begründung für die Sicherheitszielsetzungen muss jede Sicherheits-
zielsetzung für den TOE zurückführen zu den Bedrohungen, die durch diese Sicherheitszielsetzung abgewehrt
werden, und zu den OSPs, die durch diese Sicherheitszielsetzung durchgesetzt werden.
Der Evaluator muss prüfen, ob die Begründung der Sicherheitszielsetzungen alle Sicherheitszielsetzungen für
den TOE auf Bedrohungen zurückführt, denen die Zielsetzungen und/oder die durch die Zielsetzungen
durchgesetzten OSPs entgegenwirken.
Jede Sicherheitszielsetzung für den TOE kann auf Bedrohungen oder OSPs bzw. auf eine Kombination von
Bedrohungen und OSPs zurückführen, sie muss aber auf mindestens eine Bedrohung oder eine OSP
zurückführen.
für den TOE keinen sinnvollen Zweck hat.
ISO/IEC 15408-3 ASE_OBJ.2.3C: Die Begründung für die Sicherheitszielsetzungen muss jede Sicherheits-
zielsetzung für die Betriebsumgebung zurückführen zu den Bedrohungen, die durch diese Sicherheitszielsetzung
abgewehrt werden, zu den OSPs, die durch diese Sicherheitszielsetzung durchgesetzt werden, und zu den
Annahmen, die durch diese Sicherheitszielsetzung eingehalten werden.
68
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss prüfen, ob die Begründung der Sicherheitszielsetzungen die Sicherheitszielsetzungen für
die Betriebsumgebung auf Bedrohungen zurückführt, denen diese Sicherheitszielsetzung entgegenwirkt, auf
die durch diese Sicherheitszielsetzung durchgesetzten OSPs und auf die durch diese Sicherheitszielsetzung
eingehaltenen Annahmen.
Jede Sicherheitszielsetzung für die Betriebsumgebung kann auf Bedrohungen, OSPs, Annahmen oder eine
Kombination von Bedrohungen, OSPs und/oder Annahmen zurückführen, sie muss aber auf mindestens eine
Bedrohung, OSP oder Annahme zurückführen.
für die Betriebsumgebung keinen sinnvollen Zweck hat.
ISO/IEC 15408-3 ASE_OBJ.2.4C: Die Begründung für die Sicherheitszielsetzungen muss nachweisen, dass die
Sicherheitszielsetzungen alle Bedrohungen abwehren.
jede Bedrohung rechtfertigt, dass die Sicherheitszielsetzungen zur Abwehr dieser Bedrohung geeignet sind.
Wenn keine Sicherheitszielsetzungen auf die Bedrohung zurückgeführt werden können, wird die
Evaluatorenaktion, die sich auf diese Workunit bezieht, mit einer „abgelehnt“-Entscheidung belegt.
Der Evaluator stellt fest, dass die Begründung für eine Bedrohung zeigt, ob die Bedrohung beseitigt,
vermindert oder abgeschwächt wird.
Der Evaluator stellt fest, dass die Begründung für eine Bedrohung zeigt, dass die Sicherheitszielsetzungen
ausreichend sind: Wenn alle Sicherheitszielsetzungen, die auf die Bedrohung zurückführen, erreicht werden,
ist die Bedrohung beseitigt, ausreichend vermindert oder die Auswirkungen der Bedrohung werden
ausreichend abgeschwächt.
Es ist zu beachten, dass die Rückverfolgungen von den Sicherheitszielsetzungen bis hin zu den Bedrohungen,
die in der Begründung der Sicherheitszielsetzungen aufgeführt sind, Teil einer Begründung sein können, aber
keine Begründung für sich selbst darstellen. Selbst für den Fall, dass eine Sicherheitszielsetzung lediglich eine
Aussage ist, die die Absicht widerspiegelt, die Verwirklichung einer bestimmten Bedrohung zu verhindern, ist
eine Begründung erforderlich, die jedoch so minimal sein kann wie „Sicherheitszielsetzung X wirkt der
Bedrohung Y direkt entgegen“.
Der Evaluator stellt auch fest, dass jede Sicherheitszielsetzung, die auf eine Bedrohung zurückführt, notwendig
ist: Wenn die Sicherheitszielsetzung erreicht ist, trägt sie tatsächlich zur Beseitigung, Verminderung oder
Abschwächung dieser Bedrohung bei.
Sicherheitszielsetzungen alle OSPs durchsetzen.
jede OSP rechtfertigt, dass die Sicherheitszielsetzungen geeignet sind, diese OSP durchzusetzen.
Wenn keine Sicherheitszielsetzungen auf die OSP zurückgeführt werden können, wird die Evaluatorenaktion,
69
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator stellt fest, dass die Begründung für eine OSP zeigt, dass die Sicherheitszielsetzungen
ausreichend sind: Wenn alle Sicherheitszielsetzungen, die auf die OSP zurückführen, erreicht werden, wird
die OSP durchgesetzt.
Der Evaluator stellt auch fest, dass jede Sicherheitszielsetzung, die auf eine OSP zurückführt, notwendig ist:
Wenn die Sicherheitszielsetzung erreicht ist, trägt sie tatsächlich zur Durchsetzung der OSP bei.
Es ist zu beachten, dass die Rückverfolgungen von den Sicherheitszielsetzungen bis hin zu den OSPs, die in der
Begründung der Sicherheitszielsetzungen aufgeführt sind, Teil einer Begründung sein können, aber keine
Begründung für sich selbst darstellen. Für den Fall, dass eine Sicherheitszielsetzung lediglich eine Aussage ist,
die die Absicht widerspiegelt, eine bestimmte OSP durchzusetzen, ist eine Begründung erforderlich, die jedoch
so minimal sein kann wie „Sicherheitszielsetzung X setzt OSP Y direkt durch“.
Sicherheitszielsetzungen für die Betriebsumgebung alle Annahmen einhalten.
Der Evaluator muss die Begründung der Sicherheitszielsetzungen untersuchen, um festzustellen, dass sie für
jede Annahme für die Betriebsumgebung eine angemessene Begründung dafür enthält, dass die
Sicherheitszielsetzungen für die Betriebsumgebung geeignet sind, diese Annahme zu bestätigen.
Wenn keine Sicherheitszielsetzungen für die Betriebsumgebung auf die Annahme zurückführen, wird die
Evaluatorenaktion, die sich auf diese Workunit bezieht, mit einer „abgelehnt“-Entscheidung belegt.
Der Evaluator stellt fest, dass die Begründung für eine Annahme über die Betriebsumgebung des TOEs zeigt,
dass die Sicherheitszielsetzungen ausreichend sind: Wenn alle Sicherheitszielsetzungen für die
Betriebsumgebung, die auf diese Annahme zurückführen, erreicht werden, hält die Betriebsumgebung die
Annahme aufrecht.
Der Evaluator stellt auch fest, dass jede Sicherheitszielsetzung für die Betriebsumgebung, die auf eine
Annahme über die Betriebsumgebung des TOEs zurückführt, notwendig ist: Wenn die Sicherheitszielsetzung
erreicht ist, trägt sie tatsächlich dazu bei, dass die Betriebsumgebung die Annahme aufrechterhält.
Es ist zu beachten, dass die Rückverfolgungen von den Sicherheitszielsetzungen für die Betriebsumgebung bis
hin zu den Annahmen, die in der Begründung der Sicherheitszielsetzungen aufgeführt sind, Teil einer
Begründung sein können, aber keine Begründung für sich selbst darstellen. Selbst für den Fall, dass eine
Sicherheitszielsetzung der Betriebsumgebung lediglich die Neuformulierung einer Annahme ist, ist eine
Begründung erforderlich, die jedoch so minimal sein kann wie „Sicherheitszielsetzung X hält die Annahme Y
direkt aufrecht“.
9.7 Erweiterte Komponentendefinition (ASE_ECD)
9.7.1 Evaluierung der Unteraufgabe (ASE_ECD.1)
Die Zielsetzung dieser Unteraufgabe ist es, festzustellen, ob erweiterte Komponenten klar und eindeutig
definiert wurden und ob sie notwendig sind, d. h. sie können unter Verwendung bestehender Komponenten
der ISO/IEC 15408-2 oder ISO/IEC 15408-3 nicht klar ausgedrückt werden.
9.7.1.2 Eingaben
a) die ST.
70
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
9.7.1.3 Aktion ASE_ECD.1.1E
ISO/IEC 15408-3 ASE_ECD.1.1C: Die Aussage zu den Sicherheitsanforderungen muss alle erweiterten
Sicherheitsanforderungen identifizieren.
9.7.1.3.1 Workunit ASE_ECD.1-1
Der Evaluator muss prüfen, ob alle Sicherheitsanforderungen in der Aussage der Sicherheitsanforderungen,
die nicht als erweiterte Anforderungen gekennzeichnet sind, in der ISO/IEC 15408-2 oder in der
ISO/IEC 15408-3 enthalten sind.
ISO/IEC 15408-3 ASE_ECD.1.2C: Die erweiterte Komponentendefinition muss für jede erweiterte Sicherheits-
anforderung eine erweiterte Komponente definieren.
Der Evaluator muss prüfen, ob die erweiterte Komponentendefinition für jede erweiterte
Sicherheitsanforderung eine erweiterte Komponente definiert.
Enthält die ST keine erweiterten Sicherheitsanforderungen, ist diese Workunit nicht anwendbar und gilt daher
als erfüllt.
Eine einzelne erweiterte Komponente kann verwendet werden, um mehrere Iterationen einer erweiterten
Sicherheitsanforderung zu definieren, es ist nicht notwendig, diese Definition für jede Iteration zu
wiederholen.
ISO/IEC 15408-3 ASE_ECD.1.3C: Die erweiterte Komponentendefinition muss beschreiben, wie jede erweiterte
Komponente mit den bestehenden Komponenten, Familien und Klassen der ISO/IEC 15408 in Beziehung steht.
Der Evaluator muss die erweiterte Komponentendefinition untersuchen, um festzustellen, dass sie
beschreibt, wie jede erweiterte Komponente in die vorhandenen Komponenten, Familien und Klassen der
ISO/IEC 15408 passt.
als erfüllt.
Der Evaluator stellt fest, dass jede erweiterte Komponente entweder
a) ein Mitglied einer bestehenden Familie der ISO/IEC 15408-2 oder ISO/IEC 15408-3 ist, oder
b) ein Mitglied einer neuen, in der ST definierten Familie.
Wenn die erweiterte Komponente Mitglied einer bestehenden Familie der ISO/IEC 15408-2 oder
ISO/IEC 15408-3 ist, stellt der Evaluator fest, dass die erweiterte Komponentendefinition angemessen
beschreibt, warum die erweiterte Komponente ein Mitglied dieser Familie sein sollte und wie sie mit anderen
Komponenten dieser Familie zusammenhängt.
Wenn die erweiterte Komponente ein Mitglied einer neuen, in der ST definierten Familie ist, bestätigt der
Evaluator, dass die erweiterte Komponente nicht für eine bestehende Familie geeignet ist.
Wenn die ST neue Familien definiert, stellt der Evaluator fest, dass jede neue Familie entweder
a) ein Mitglied einer bestehenden Klasse der ISO/IEC 15408-2 oder ISO/IEC 15408-3 ist, oder
b) ein Mitglied einer neuen, in der ST definierten Klasse.
71
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Wenn die Familie ein Mitglied einer bestehenden Klasse der ISO/IEC 15408-2 oder ISO/IEC 15408-3 ist, stellt
der Evaluator fest, dass die erweiterte Komponentendefinition angemessen beschreibt, warum die Familie ein
Mitglied jener Klasse sein sollte und wie sie mit anderen Familien jener Klasse zusammenhängt.
Wenn die Familie ein Mitglied einer neuen, in der ST definierten Klasse ist, bestätigt der Evaluator, dass die
Familie für eine bestehende Klasse nicht geeignet ist.
Definition einer erweiterten Komponente alle anwendbaren Abhängigkeiten dieser Komponente identifiziert.
als erfüllt.
Der Evaluator bestätigt, dass der ST-Autor keine zutreffenden Abhängigkeiten übersehen hat.
ISO/IEC 15408-3 ASE_ECD.1.4C: Die erweiterte Komponentendefinition muss die bestehenden Komponenten,
Familien, Klassen und die Methodik der ISO/IEC 15408 als ein Modell der Darstellung verwenden.
erweiterte Funktionskomponente die vorhandenen Komponenten der ISO/IEC 15408-2 als Modell für die
Darstellung verwendet.
Enthält die ST keine erweiterten SFRs, ist diese Workunit nicht anwendbar und gilt daher als erfüllt.
Der Evaluator stellt fest, dass jede erweiterte Funktionskomponente konsistent ist gegenüber
ISO/IEC 15408-2, 6.1.3, Komponentenstruktur.
Wenn die erweiterte Funktionskomponente Operationen verwendet, stellt der Evaluator fest, dass die
erweiterte Funktionskomponente konsistent ist gegenüber ISO/IEC 15408-1, 7.1, Operationen.
Wenn die erweiterte Funktionskomponente hierarchisch zu einer bestehenden Funktionskomponente ist,

stellt der Evaluator fest, dass die erweiterte Funktionskomponente konsistent ist gegenüber ISO/IEC 15408-2,
6.2.1, Hervorheben von Komponentenänderungen.
Definition einer neuen Funktionsfamilie die bestehenden Funktionsfamilien der ISO/IEC 15408 als Modell für
Wenn die ST keine neuen Funktionsfamilien definiert, ist diese Workunit nicht anwendbar und gilt daher als
erfüllt.
Der Evaluator stellt fest, dass alle neuen Funktionsfamilien konsistent definiert werden gegenüber
ISO/IEC 15408-2, 6.1.2, Familienstruktur.
Definition einer neuen Funktionsklasse die bestehenden Funktionsklassen der ISO/IEC 15408 als Modell für
Wenn die ST keine neuen Funktionsklassen definiert, ist diese Workunit nicht anwendbar und gilt daher als
erfüllt.
Der Evaluator stellt fest, dass alle neuen Funktionsklassen konsistent definiert werden gegenüber
ISO/IEC 15408-2, 6.1.1, Klassenstruktur.
72
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Definition einer erweiterten Vertrauenswürdigkeitskomponente die vorhandenen Komponenten der
ISO/IEC 15408-3 als Modell für die Darstellung verwendet.
Enthält die ST keine erweiterten SARs, ist diese Workunit nicht anwendbar und gilt daher als erfüllt.
Der Evaluator stellt fest, dass jede erweiterte Vertrauenswürdigkeitskomponente konsistent ist gegenüber
ISO/IEC 15408-3, 6.1.3, Struktur der Vertrauenswürdigkeitskomponenten.
Wenn die erweiterte Vertrauenswürdigkeitskomponente Operationen verwendet, stellt der Evaluator fest,
dass die erweiterte Vertrauenswürdigkeitskomponente konsistent ist gegenüber ISO/IEC 15408-1, 7.1,
Operationen.
Wenn die erweiterte Vertrauenswürdigkeitskomponente hierarchisch zu einer bestehenden Vertrauens-

würdigkeitskomponente ist, stellt der Evaluator fest, dass die erweiterte Vertrauenswürdigkeitskomponente
konsistent ist gegenüber ISO/IEC 15408-3, 6.1.3, Struktur der Vertrauenswürdigkeitskomponenten.
Der Evaluator muss die erweiterte Komponentendefinition untersuchen, um festzustellen, ob für jede
definierte erweiterte Vertrauenswürdigkeitskomponente eine anwendbare Methodik bereitgestellt wurde.
Enthält die ST keine erweiterten SARs, ist diese Workunit nicht anwendbar und gilt daher als erfüllt.
Der Evaluator stellt fest, dass für jedes Evaluatorenaktionselement jeder erweiterten SAR eine oder mehrere
Workunits vorgesehen sind und dass die erfolgreiche Durchführung aller Workunits für ein bestimmtes
Evaluatorenaktionselement nachweisen wird, dass das Element erreicht wurde.
Definition einer neuen Vertrauenswürdigkeitsfamilie die bestehenden Vertrauenswürdigkeitsfamilien der
Wenn die ST keine neuen Vertrauenswürdigkeitsfamilien definiert, ist diese Workunit nicht anwendbar und
Der Evaluator stellt fest, dass alle neuen Vertrauenswürdigkeitsfamilien konsistent definiert werden
gegenüber ISO/IEC 15408-3, 6.1.2, Struktur der Vertrauenswürdigkeitsfamilien.
Definition einer neuen Vertrauenswürdigkeitsklasse die bestehenden Vertrauenswürdigkeitsklassen der
Wenn die ST keine neuen Vertrauenswürdigkeitsklassen definiert, ist diese Workunit nicht anwendbar und
Der Evaluator stellt fest, dass alle neuen Vertrauenswürdigkeitsklassen konsistent definiert werden
gegenüber ISO/IEC 15408-3, 6.1.1, Struktur der Vertrauenswürdigkeitsklassen.
ISO/IEC 15408-3 ASE_ECD.1.5C: Die erweiterten Komponenten müssen aus messbaren und objektiven
Elementen bestehen, sodass die Konformität oder Nichtkonformität mit diesen Elementen nachgewiesen werden
kann.
73
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss die erweiterte Komponentendefinition untersuchen, um festzustellen, dass jedes
Element in jeder erweiterten Komponente messbar ist und objektive Evaluierungsanforderungen angibt, so
dass Konformität oder Nichtkonformität nachgewiesen werden kann.
als erfüllt.
Der Evaluator stellt fest, dass die Elemente der erweiterten Funktionskomponenten so angegeben werden,
dass sie prüfbar und durch die entsprechenden TSF-Darstellungen rückverfolgbar sind.
Der Evaluator stellt auch fest, dass Elemente der erweiterten Vertrauenswürdigkeitskomponenten die
Notwendigkeit einer subjektiven Beurteilung durch den Evaluator vermeiden.
Der Evaluator wird daran erinnert, dass alle Evaluierungskriterien zwar messbar und objektiv sind, dass es
aber anerkanntermaßen kein formales Verfahren zum Nachweis solcher Eigenschaften gibt. Daher sind die
vorhandenen Funktions- und Vertrauenswürdigkeitskomponenten der ISO/IEC 15408 als Modell für die
Bestimmung der Konformität mit dieser Anforderung zu verwenden.
9.7.1.4 Aktion ASE_ECD.1.2E
erweiterte Komponente nicht eindeutig durch vorhandene Komponenten ausgedrückt werden kann.
als erfüllt.
Der Evaluator sollte bei dieser Bestimmung Komponenten aus ISO/IEC 15408-2 und ISO/IEC 15408-3, andere
erweiterte Komponenten, die in der ST definiert wurden, Kombinationen dieser Komponenten und mögliche
Operationen an diesen Komponenten berücksichtigen.
Der Evaluator wird daran erinnert, dass die Rolle dieser Workunit darin besteht, eine unnötige Duplizierung
von Komponenten zu vermeiden, d. h. von Komponenten, die durch die Verwendung anderer Komponenten
klar ausgedrückt werden können. Der Evaluator sollte keine erschöpfende Suche nach allen möglichen
Kombinationen von Komponenten einschließlich Operationen durchführen, um zu versuchen, einen Weg zu
finden, die erweiterte Komponente durch Verwendung vorhandener Komponenten auszudrücken.
9.8 Sicherheitsanforderungen (ASE_REQ)

9.8.1 Evaluierung der Unteraufgabe (ASE_REQ.1)
genau definiert sind und ob sie in sich konsistent sind.
9.8.1.2 Eingaben
a) die ST.
9.8.1.3 Aktion ASE_REQ.1.1E
ISO/IEC 15408-3 ASE_REQ.1.1C: Die Aussage zu den Sicherheitsanforderungen muss die SFRs und die SARs
beschreiben.
74
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
b) durch Verweisung auf eine erweiterte Komponente in der erweiterten Komponentendefinition der ST;
c) durch Verweisung auf ein PP, mit dem die ST beansprucht, konform zu sein;
d) durch Verweisung auf ein Sicherheitsanforderungspaket, mit dem die ST beansprucht, konform zu sein;
e) durch Vervielfältigung in der ST.
c) durch Verweisung auf ein PP, mit dem die ST beansprucht, konform zu sein;
d) durch Verweisung auf ein Sicherheitsanforderungspaket, mit dem die ST beansprucht, konform zu sein;
ISO/IEC 15408-3 ASE_REQ.1.2C: Alle Subjekte, Objekte, Operationen, Sicherheitsattribute, externen Entitäten
Der Evaluator muss die ST untersuchen, um festzustellen, ob alle Subjekte, Objekte, Operationen, Sicherheits-
attribute, externen Entitäten und sonstigen Begriffe, die in den SFRs und den SARs verwendet werden,
definiert sind.
Der Evaluator stellt fest, dass die ST Folgendes definiert:
Operationen;
werden.
75
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Äußersten getrieben werden, indem der Verfasser des ST gezwungen wird, jedes einzelne Wort zu definieren.
Der Evaluator wird daran erinnert, dass diese Listen und Definitionen nicht Teil der Aussage der Sicherheits-
anforderungen sein müssen, sondern (teilweise oder ganz) in verschiedenen Unterabschnitten untergebracht
werden können. Dies kann insbesondere dann der Fall sein, wenn die gleichen Begriffe in der übrigen ST
verwendet werden.
ISO/IEC 15408-3 ASE_REQ.1.3C: Die Aussage zu den Sicherheitsanforderungen muss alle Operationen im
verwendet wird, identifiziert werden. Die Identifizierung kann durch typografische Unterscheidungen, durch
explizite Kennzeichnung im umgebenden Text oder durch jedes andere Unterscheidungsmittel erfolgen.
ISO/IEC 15408-3 ASE_REQ.1.4C: Alle Operationen müssen korrekt durchgeführt werden.
76
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
ISO/IEC 15408-3 ASE_REQ.1.5C: Jede Abhängigkeit der Sicherheitsanforderungen muss entweder erfüllt sein,
wird.
Abhängigkeit der Sicherheitsanforderungen entweder erfüllt ist oder ob eine Begründung der Sicherheits-
anforderungen erfolgt, die die Nichterfüllung der Abhängigkeit rechtfertigt.
ISO/IEC 15408-3 ASE_REQ.1.6C: Die Aussage zu den Sicherheitsanforderungen muss in sich konsistent sein.
konsistent ist.
zueinander stehen.
77
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
9.8.2 Evaluierung der Unteraufgabe (ASE_REQ.2)
genau definiert sind, ob sie in sich konsistent sind und ob die SFRs die Sicherheitszielsetzungen des TOEs
erfüllen.
9.8.2.2 Eingaben
a) die ST.
9.8.2.3 Aktion ASE_REQ.2.1E
ISO/IEC 15408-3 ASE_REQ.2.1C: Die Aussage zu den Sicherheitsanforderungen muss die SFRs und die SARs
beschreiben.
c) durch Verweisung auf eine einzelne Komponente in einem PP, mit dem die ST beansprucht, konform zu
sein;
d) durch Verweisung auf eine einzelne Komponente in einem Sicherheitsanforderungspaket, mit dem die ST
beansprucht, konform zu sein;
Der Evaluator stellt fest, dass alle SARs auf eine der folgenden Arten identifiziert wird:
78
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
c) durch Verweisung auf eine einzelne Komponente in einem PP, mit dem die ST beansprucht, konform zu
sein;
d) durch Verweisung auf eine einzelne Komponente in einem Sicherheitsanforderungspaket, mit dem die ST
beansprucht, konform zu sein;
ISO/IEC 15408-3 ASE_REQ.2.2C: Alle Subjekte, Objekte, Operationen, Sicherheitsattribute, externen Entitäten
Der Evaluator muss die ST untersuchen, um festzustellen, ob alle Subjekte, Objekte, Operationen, Sicherheits-
attribute, externen Entitäten und sonstigen Begriffe, die in den SFRs und den SARs verwendet werden,
definiert sind.
Der Evaluator stellt fest, dass die ST Folgendes definiert:
Operationen;
werden.
Äußersten getrieben werden, indem der Verfasser des ST gezwungen wird, jedes einzelne Wort zu definieren.
untergebracht werden können. Dies kann insbesondere dann der Fall sein, wenn die gleichen Begriffe in der
übrigen ST verwendet werden.
ISO/IEC 15408-3 ASE_REQ.2.3C: Die Aussage zu den Sicherheitsanforderungen muss alle Operationen im
79
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
verwendet wird, identifiziert werden. Die Identifizierung kann durch typografische Unterscheidungen, durch
explizite Kennzeichnung im umgebenden Text oder durch jedes andere Unterscheidungsmittel erfolgen.
ISO/IEC 15408-3 ASE_REQ.2.4C: Alle Operationen müssen korrekt durchgeführt werden.
ISO/IEC 15408-3 ASE_REQ.2.5C: Jede Abhängigkeit der Sicherheitsanforderungen muss entweder erfüllt sein,
wird.
Abhängigkeit der Sicherheitsanforderungen entweder erfüllt ist oder ob die Begründung der Sicherheits-
anforderungen die Nichterfüllung der Abhängigkeit rechtfertigt.
80
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
ISO/IEC 15408-3 ASE_REQ.2.6C: Die Begründung für die Sicherheitsanforderungen muss jede SFR zu den
Sicherheitszielsetzungen für den TOE zurückverfolgen.
Der Evaluator muss prüfen, ob die Begründung der Sicherheitsanforderungen jede SFR zu den
Sicherheitszielsetzungen für den TOE zurückverfolgt.
Der Evaluator stellt fest, dass jede SFR zu mindestens einer Sicherheitszielsetzung für den TOE rückverfolgt
wird.
Eine fehlende Rückverfolgbarkeit bedeutet, dass entweder die Begründung der Sicherheitszielsetzungen
unvollständig ist, die Sicherheitszielsetzungen für den TOE unvollständig sind oder die SFR keinen sinnvollen
Zweck hat.
ISO/IEC 15408-3 ASE_REQ.2.7C: Die Begründung für die Sicherheitsanforderungen muss nachweisen, dass die
SFRs alle Sicherheitszielsetzungen für den TOE erfüllen.
Der Evaluator muss die Begründung der Sicherheitsanforderungen untersuchen, um festzustellen, ob sie bei
jeder Sicherheitszielsetzung für den TOE die Eignung der SFRs zur Erfüllung dieser Sicherheitszielsetzung für
den TOE begründet.
Wenn keine SFRs zur Sicherheitszielsetzung für den TOE rückverfolgt werden, wird die Evaluatorenaktion,
Der Evaluator stellt fest, dass die Begründung für eine Sicherheitszielsetzung für den TOE nachweist, dass die
SFRs ausreichend sind: Wenn alle SFRs, die zur Zielsetzung rückverfolgt werden, erfüllt sind, ist die
Sicherheitszielsetzung für den TOE erreicht.
Der Evaluator stellt auch fest, dass jede SFR, die zu einer Sicherheitszielsetzung für den TOE rückverfolgt wird,
notwendig ist: Wenn die SFR erfüllt ist, trägt sie tatsächlich zur Erreichung der Sicherheitszielsetzung bei.
Es ist zu beachten, dass die Rückverfolgungen von den SFRs bis hin zu den Sicherheitszielsetzungen für den
TOE, die in der Begründung der Sicherheitsanforderungen aufgeführt sind, ein Teil der Begründung sein
können, aber keine Begründung für sich selbst darstellen.
ISO/IEC 15408-3 ASE_REQ.2.8C: Die Begründung für die Sicherheitsanforderungen muss erklären, warum die
SARs gewählt wurden.
81
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss prüfen, ob die Begründung der Sicherheitsanforderungen erläutert, warum die SARs
gewählt wurden.
Der Evaluator wird daran erinnert, dass jede Begründung richtig ist, solange sie stimmig ist und weder die
SARs noch die Erläuterung offensichtliche Inkonsistenzen mit der übrigen ST aufweisen.
Ein Beispiel für eine offensichtliche Inkonsistenz zwischen den SARs und der übrigen ST wäre, wenn es zwar
sehr fähige Bedrohungsagenten gäbe, aber ein AVA_VAN SAR, das nicht vor diesen Bedrohungsagenten
schützt.
ISO/IEC 15408-3 ASE_REQ.2.9C: Die Aussage zu den Sicherheitsanforderungen muss in sich konsistent sein.
konsistent ist.
zueinander stehen.
geheim zu halten ist, und eine weitere erweiterte Vertrauenswürdigkeitsanforderung, die eine Open-
Source-Überprüfung angibt;
82
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
9.9 Zusammenfassende Spezifikation des TOEs (ASE_TSS)

9.9.1 Evaluierung der Unteraufgabe (ASE_TSS.1)
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob die zusammenfassende Spezifikation des
TOEs alle SFRs abdeckt und ob diese Spezifikation gegenüber anderen ausformulierten Beschreibungen des
TOEs konsistent ist.
9.9.1.2 Eingaben
a) die ST.
9.9.1.3 Aktion ASE_TSS.1.1E
ISO/IEC 15408-3 ASE_TSS.1.1C: Die zusammenfassende Spezifikation des TOEs muss beschreiben, wie der TOE
jede SFR erfüllt.
9.9.1.3.1 Workunit ASE_TSS.1-1
Der Evaluator muss die zusammenfassende Spezifikation des TOEs untersuchen, um festzustellen, dass sie
beschreibt, wie der TOE jede SFR erfüllt.
Der Evaluator stellt fest, dass die zusammenfassende Spezifikation des TOEs für jede SFR aus der Aussage der
Sicherheitsanforderungen eine Beschreibung darüber enthält, wie diese SFR erfüllt wird.
Der Evaluator wird daran erinnert, dass die Zielsetzung jeder Beschreibung darin besteht, potentiellen
Verbrauchern des TOEs einen Überblick darüber zu geben, wie der Entwickler beabsichtigt, die einzelnen SFRs
zu erfüllen, und dass die Beschreibungen daher nicht allzu detailliert sein sollten. Oft werden mehrere SFRs in
einem Kontext implementiert; zum Beispiel kann ein Passwort-Authentifizierungsmechanismus FIA_UAU.1,
FIA_SOS.1 und FIA_UID.1 implementieren. Daher wird die TSS in der Regel nicht aus einer langen Liste mit
Texten für jede einzelne SFR bestehen, sondern ganze Gruppen von SFRs können von einer Textpassage
abgedeckt werden.
Bei einem zusammengesetzten TOE stellt der Evaluator auch fest, dass es klar ist, welche Komponente jede
SFR liefert oder wie die Komponenten zusammenwirken, um die einzelne SFR zu erfüllen.
gegenüber dem TOE-Überblick und der TOE-Beschreibung konsistent ist.
Der TOE-Überblick, die TOE-Beschreibung und die zusammenfassende Spezifikation des TOEs beschreiben
den TOE ausformuliert mit steigendem Detaillierungsgrad. Diese Beschreibungen müssen daher konsistent
sein.
9.9.2 Evaluierung der Unteraufgabe (ASE_TSS.2)
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob die zusammenfassende Spezifikation des
TOEs alle SFRs behandelt, ob die zusammenfassende Spezifikation des TOEs Interferenzen, logische Eingriffe
und Umgehung behandelt und ob die zusammenfassende Spezifikation des TOEs gegenüber anderen
ausformulierten Beschreibungen des TOEs konsistent ist.
83
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
9.9.2.2 Eingaben
a) die ST.
ISO/IEC 15408-3 ASE_TSS.2.1C: Die zusammenfassende Spezifikation des TOEs muss beschreiben, wie der TOE
jede SFR erfüllt.
beschreibt, wie der TOE jede SFR erfüllt.
Der Evaluator stellt fest, dass die zusammenfassende Spezifikation des TOEs für jede SFR aus der Aussage der
Sicherheitsanforderungen eine Beschreibung darüber enthält, wie diese SFR erfüllt wird.
Verbrauchern des TOEs einen Überblick darüber zu geben, wie der Entwickler beabsichtigt, die einzelnen SFRs
zu erfüllen, und dass die Beschreibungen daher nicht allzu detailliert sein sollten. Oft werden mehrere SFRs in
einem Kontext implementiert; zum Beispiel kann ein Passwort-Authentifizierungsmechanismus FIA_UAU.1,
FIA_SOS.1 und FIA_UID.1 implementieren. Daher wird die TSS in der Regel nicht aus einer langen Liste mit
Texten für jede einzelne SFR bestehen, sondern ganze Gruppen von SFRs können von einer Textpassage
abgedeckt werden.
Bei einem zusammengesetzten TOE stellt der Evaluator auch fest, dass es klar ist, welche Komponente jede
SFR liefert oder wie die Komponenten zusammenwirken, um die einzelne SFR zu erfüllen.
ISO/IEC 15408-3 ASE_TSS.2.2C: Die zusammenfassende Spezifikation des TOEs muss beschreiben, wie sich der
TOE gegen Störungen und logische Eingriffe schützt.
beschreibt, wie sich der TOE gegen Störungen und logische Eingriffe schützt.
Verbrauchern des TOEs einen Überblick darüber zu geben, wie der Entwickler beabsichtigt, Schutz vor
Störungen und logischen Eingriffen zu bieten, und dass die Beschreibungen daher nicht übermäßig detailliert
sein sollten.
Bei einem zusammengesetzten TOE stellt der Evaluator auch fest, dass es klar ist, welche Komponente den
Schutz liefert oder wie die Komponenten zusammenwirken, um Schutz zu bieten.
ISO/IEC 15408-3 ASE_TSS.2.3C: Die zusammenfassende Spezifikation des TOEs muss beschreiben, wie sich der
TOE gegen Umgehen schützt.
beschreibt, wie sich der TOE gegen Umgehen schützt.
Der Evaluator wird daran erinnert, dass die Zielsetzung jeder Beschreibung darin besteht, potenziellen
Verbrauchern des TOEs einen Überblick darüber zu geben, wie der Entwickler beabsichtigt, Schutz vor
Umgehen zu bieten, und dass die Beschreibungen daher nicht übermäßig detailliert sein sollten.
Bei einem zusammengesetzten TOE stellt der Evaluator auch fest, dass es klar ist, welche Komponente den
Schutz liefert oder wie die Komponenten zusammenwirken, um Schutz zu bieten.
84
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
gegenüber dem TOE-Überblick und der TOE-Beschreibung konsistent ist.
Der TOE-Überblick, die TOE-Beschreibung und die zusammenfassende Spezifikation des TOEs beschreiben
den TOE ausformuliert mit steigendem Detaillierungsgrad. Diese Beschreibungen müssen daher konsistent
sein.
10 Klasse ADV: Entwicklung
10.1 Einleitung
Der Zweck der Entwicklungsaufgabe besteht darin, die Designunterlagen hinsichtlich ihrer Angemessenheit
zu beurteilen, um zu verstehen, wie die TSF die SFRs erfüllt und wie die Umsetzung dieser SFRs nicht
manipuliert oder umgangen werden kann. Dieses Verständnis wird durch die Untersuchung von zunehmend
verfeinerten Beschreibungen der TSF-Designunterlagen erreicht. Die Designunterlagen bestehen aus einer
Funktionsspezifikation (die die Schnittstellen der TSF beschreibt), einer TOE-Design-Beschreibung (die die
Architektur der TSF in Bezug auf ihre Funktionsweise beschreibt, um die Funktionen in Bezug auf die
beanspruchten SFRs zu erfüllen) und einer Implementierungsbeschreibung (eine Beschreibung auf Quellcode-
Ebene). Zusätzlich gibt es eine Beschreibung der Sicherheitsarchitektur (die die architektonischen
Eigenschaften der TSF beschreibt, um zu erklären, wie ihre Sicherheitsdurchsetzung nicht beeinträchtigt oder
umgangen werden kann), eine Beschreibung der Interna (die beschreibt, wie die TSF auf eine Weise
konstruiert wurde, die die Verständlichkeit fördert) und ein Sicherheitspolitikmodell (das die von der TSF
durchgesetzten Sicherheitspolitiken formell beschreibt).
Die Anforderungen der ISO/IEC 15408 an die Designunterlagen werden durch den Umfang und die
Detailliertheit der bereitgestellten Informationen sowie den Grad der Formalität der präsentierten
Informationen ausgeglichen. Auf den unteren Ebenen werden die sicherheitskritischsten Teile der TSF am
detailliertesten beschrieben, während weniger sicherheitskritische Teile der TSF lediglich zusammengefasst
werden; zusätzliche Vertrauenswürdigkeit wird dadurch erreicht, dass die Menge der Informationen über die
sicherheitskritischsten Teile der TSF und die Details über die weniger sicherheitskritischen Teile erhöht
werden. Die größte Vertrauenswürdigkeit wird erreicht, wenn gründliche Details und Informationen zu allen
Teilen zur Verfügung gestellt werden.
Die ISO/IEC 15408 betrachtet den Grad der Formalität eines Dokuments (d. h. ob es informell oder semiformal
ist) als hierarchisch. Ein informelles Dokument ist ein Dokument, das in einer natürlichen Sprache
ausgedrückt wird. Die Methodik diktiert nicht die spezifische Sprache, die verwendet werden muss; diese
Frage wird dem Schema überlassen. In den folgenden Absätzen werden die Inhalte der verschiedenen
informellen Dokumente unterschieden.
Eine Funktionsspezifikation bietet eine Beschreibung des Zwecks und der Art und Weise der Nutzung von
Schnittstellen zur TSF. Wenn z. B. ein Betriebssystem dem Benutzer eine Möglichkeit bietet, sich selbst zu
identifizieren, Dateien zu erstellen, zu ändern oder zu löschen, Berechtigungen festzulegen, die definieren,
welche anderen Benutzer auf Dateien zugreifen dürfen, und mit Remote-Rechnern zu kommunizieren, dann
würde seine Funktionsspezifikation Beschreibungen zu jedem dieser Punkte enthalten und wie sie durch
Interaktionen mit den von außen sichtbaren Schnittstellen zur TSF realisiert werden. Wenn es auch eine
Audit-Funktionalität gibt, die das Auftreten solcher Ereignisse erkennt und aufzeichnet, wäre zu erwarten,
dass die Beschreibung dieser Audit-Funktionalität ebenfalls Teil der Funktionsspezifikation ist; obwohl diese
Funktionalität technisch gesehen nicht direkt vom Benutzer an der externen Schnittstelle aufgerufen wird,
wird sie sicherlich von dem beeinflusst, was an der externen Schnittstelle des Benutzers geschieht.
85
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Eine Designbeschreibung wird in Form von logischen Unterteilungen (Teilsystemen oder Modulen)
ausgedrückt, die jeweils eine nachvollziehbare Dienstleistung oder Funktion bieten. Eine Firewall kann
beispielsweise aus Teilsystemen bestehen, die sich mit der Paketfilterung, mit der Fernverwaltung, mit dem
Auditing und mit der Filterung auf Verbindungsebene befassen. Die Designbeschreibung der Firewall würde
die Aktionen beschreiben, die ergriffen werden, und zwar im Hinblick darauf, welche Aktionen jedes
Teilsystem beim Eintreffen eines eingehenden Pakets an der Firewall ergreift.
10.3 Sicherheitsarchitektur (ADV_ARC)

10.3.1 Evaluierung der Unteraufgabe (ADV_ARC.1)
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob die TSF so strukturiert ist, dass sie nicht
manipuliert oder umgangen werden kann, und ob TSFs, die Sicherheitsdomänen bereitstellen, diese Domänen
voneinander isolieren.
10.3.1.2 Eingaben
a) die ST,
b) die Funktionsspezifikation,
c) das TOE-Design,
d) die Beschreibung der Sicherheitsarchitektur,
e) die Darstellung der Implementierung (falls verfügbar),
f) die operativen Leitlinien für Benutzer.
10.3.1.3 Anwendungshinweise
Die Begriffe Eigenschutz, Domänentrennung und Nicht-Umgehbarkeit unterscheiden sich von der Sicherheits-
funktionalität, die in Teil 2 der SFRs ausgedrückt wird, weil Eigenschutz und Nicht-Umgehbarkeit weitgehend
keine direkt beobachtbare Schnittstelle an der TSF haben. Vielmehr sind es Eigenschaften der TSF, die durch
das Design des TOEs erreicht und durch die korrekte Umsetzung dieses Designs durchgesetzt werden. Auch
die Evaluierung dieser Eigenschaften ist nicht ganz so einfach wie die Evaluierung der Mechanismen; es ist
schwieriger, die fehlende Funktionalität zu überprüfen als die vorhandene. Die Feststellung, dass diese
Eigenschaften erfüllt werden, ist jedoch ebenso entscheidend wie die Feststellung, dass die Mechanismen
ordnungsgemäß umgesetzt werden.
Der allgemeine Ansatz besteht darin, dass der Entwickler eine TSF vorlegt, die die oben genannten
Eigenschaften erfüllt, und den Nachweis (in Form einer Dokumentation) erbringt, der analysiert werden kann,
um zu zeigen, dass die Eigenschaften tatsächlich erfüllt sind. Der Evaluator hat die Verantwortung für die
Prüfung der Nachweise und, zusammen mit anderen für den TOE gelieferten Nachweisen, für die Feststellung,
dass die Eigenschaften erreicht werden. Die Workunits können als diejenigen charakterisiert werden, die
detailliert beschreiben, welche Informationen bereitgestellt werden müssen, und als diejenigen, die sich mit
der eigentlichen Analyse befassen, die der Evaluator durchführt.
Die Beschreibung der Sicherheitsarchitektur beschreibt, wie Domänen definiert werden und wie die TSF sie
getrennt hält. Sie beschreibt, was nicht vertrauenswürdige Prozesse daran hindert, zur TSF zu gelangen und
sie zu modifizieren. Sie beschreibt, was sicherstellt, dass alle Ressourcen unter der Kontrolle der TSF
angemessen geschützt werden und dass alle Aktionen im Zusammenhang mit den SFRs von der TSF vermittelt
werden. Sie erklärt jede Rolle, die die Umgebung in einem dieser Bereiche spielt (z. B. unter der Annahme,
dass sie von ihrer zugrunde liegenden Umgebung korrekt aufgerufen wird, wie wird ihre Sicherheits-
funktionalität aufgerufen?). Kurzum wird erklärt, wie der TOE als Anbieter jeglicher Art von Sicherheits-
diensten angesehen wird.
86
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Die Analysen, die der Evaluator durchführt, müssen im Zusammenhang mit allen für den TOE vorgelegten
Entwicklungsnachweisen in dem Detaillierungsgrad durchgeführt werden, in dem die Nachweise vorgelegt
werden. Auf niedrigeren Vertrauenswürdigkeitsstufen sollte nicht erwartet werden, dass z. B. der
TSF-Eigenschutz vollständig analysiert wird, da nur übergeordnete Design-Darstellungen zur Verfügung
stehen werden. Der Evaluator muss auch sicher sein, dass er Informationen aus anderen Teilen seiner Analyse
(z. B. der Analyse des TOEs-Designs) bei der Beurteilung der Eigenschaften, die in den folgenden Workunits
untersucht werden, verwendet.
10.3.1.4 Aktion ADV_ARC.1.1E
ISO/IEC 15408-3 ADV_ARC.1.1C: Die Beschreibung der Sicherheitsarchitektur muss im selben Detaillierungs-
grad bereitgestellt werden, wie die Beschreibung der SFR-durchsetzenden Abstraktionen im TOE-Design-
dokument.
10.3.1.4.1 Workunit ADV_ARC.1-1
Der Evaluator muss die Beschreibung der Sicherheitsarchitektur untersuchen, um festzustellen, dass die in
den Nachweisen enthaltenen Informationen in einem Detaillierungsgrad dargestellt werden, der den
Beschreibungen der SFR-durchsetzenden Abstraktionen entspricht, die in der Funktionsspezifikation und im
TOE-Design-Dokument enthalten sind.
In Bezug auf die Funktionsspezifikation sollte der Evaluator sicherstellen, dass die beschriebene Eigenschutz-
funktionalität diejenigen Auswirkungen abdeckt, die bei der TSFI offensichtlich sind. Eine solche Beschreibung
könnte den Schutz der ausführbaren Bilder der TSF und den Schutz von Objekten (z. B. Dateien, die von der
TSF verwendet werden) umfassen. Der Evaluator stellt sicher, dass die Funktionalität, die über die TSFI
aufgerufen werden könnte, beschrieben wird.
Falls „Evaluation of sub-activity“ (ADV_TDS.1) bzw. „Evaluation of sub-activity“ (ADV_TDS.2) enthalten ist,
stellt der Evaluator sicher, dass die Beschreibung der Sicherheitsarchitektur Informationen darüber enthält,
wie alle Teilsysteme, die zur TSF-Domänentrennung beitragen, funktionieren.
Falls „Evaluation of sub-activity“ (ADV_TDS.3) oder höher vorhanden ist, stellt der Evaluator sicher, dass die
Beschreibung der Sicherheitsarchitektur auch implementierungsabhängige Informationen enthält. Eine
solche Beschreibung könnte z. B. Informationen über Codierungskonventionen für die Parameterprüfung
enthalten, die TSF-Kompromisse (z. B. Pufferüberläufe) verhindern würden, sowie Informationen über die
Stapelverwaltung für Aufruf- und Rückgabeoperationen. Der Evaluator prüft die Beschreibungen der
Mechanismen, um sicherzustellen, dass der Detaillierungsgrad so hoch ist, dass zwischen der Beschreibung in
der Beschreibung der Sicherheitsarchitektur und der Darstellung der Implementierung wenig Unklarheit
besteht.
Die Evaluatoraktion im Zusammenhang mit dieser Workunit wird mit einer „abgelehnt“-Entscheidung belegt,
wenn die Beschreibung der Sicherheitsarchitektur Module, Teilsysteme oder Schnittstellen erwähnt, die nicht
in der Funktionsspezifikation oder im TOE-Design-Dokument beschrieben sind.
ISO/IEC 15408-3 ADV_ARC.1.2C: Die Beschreibung der Sicherheitsarchitektur muss die von der TSF verwalteten
Sicherheitsdomänen konsistent mit den SFRs beschreiben.
Der Evaluator muss die Beschreibung der Sicherheitsarchitektur untersuchen, um festzustellen, dass sie die
von der TSF verwalteten Sicherheitsdomänen beschreibt.
Sicherheitsdomänen beziehen sich auf Umgebungen, die von der TSF für die Nutzung durch potentiell
schädliche Entitäten bereitgestellt werden; beispielsweise stellt ein typisches sicheres Betriebssystem eine
Menge Ressourcen (Adressraum, Umgebungsvariablen je Prozess) für die Nutzung durch Prozesse mit
begrenzten Zugriffsrechten und Sicherheitseigenschaften bereit. Der Evaluator stellt fest, dass die Beschrei-
bung der Sicherheitsdomänen durch den Entwickler alle vom TOE beanspruchten SFRs berücksichtigt.
87
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Für einige TOEs gibt es solche Bereiche nicht, da alle Interaktionen, die den Benutzern zur Verfügung stehen,
durch die TSF stark eingeschränkt sind. Eine Paketfilter-Firewall ist ein Beispiel für einen solchen TOE.
Benutzer im LAN oder WAN interagieren nicht mit dem TOE, so dass es keine Sicherheitsdomänen geben
muss; es gibt nur Datenstrukturen, die von der TSF verwaltet werden, um die Pakete der Benutzer getrennt
zu halten. Der Evaluator stellt sicher, dass jede Behauptung, es gäbe keine Domänen, durch die Nachweise
belegt wird und dass tatsächlich keine solchen Domänen verfügbar sind.
ISO/IEC 15408-3 ADV_ARC.1.3C: Die Beschreibung der Sicherheitsarchitektur muss beschreiben, wie der
TSF-Initialisierungsprozess sicher gestaltet ist.
Der Evaluator muss die Beschreibung der Sicherheitsarchitektur untersuchen, um festzustellen, dass der
Initialisierungsprozess die Sicherheit aufrechterhält.
Die in der Beschreibung der Sicherheitsarchitektur enthaltenen Informationen bezüglich der TSF-Initialisie-
rung richten sich an die Komponenten des TOEs, die daran beteiligt sind, die TSF beim Einschalten oder bei
einem Reset in einen anfänglichen sicheren Zustand zu bringen (d. h. wenn alle Teile der TSF in Betrieb sind).
Diese Erörterung in der Beschreibung der Sicherheitsarchitektur sollte die Systeminitialisierungs-
komponenten und die Verarbeitung auflisten, die beim Übergang vom „Ausfall“-Zustand zum anfänglichen
sicheren Zustand erfolgt.
Es ist häufig der Fall, dass die Komponenten, die diese Initialisierungsfunktion ausführen, nicht mehr
zugänglich sind, nachdem der sichere Zustand erreicht ist; wenn dies der Fall ist, dann identifiziert die
Beschreibung der Sicherheitsarchitektur die Komponenten und erläutert, wie sie für nicht vertrauenswürdige
Entitäten nicht mehr erreichbar sind, nachdem die TSF eingerichtet wurde. In dieser Hinsicht ist die zu
bewahrende Eigenschaft, dass diese Komponenten entweder 1) nach Erreichen des sicheren Zustands nicht
von nicht vertrauenswürdigen Entitäten erreicht werden können, oder 2) wenn sie Schnittstellen zu nicht
vertrauenswürdigen Entitäten bereitstellen, können diese TSFI nicht zur Manipulation der TSF verwendet
werden.
Die Komponenten des TOEs, die mit der TSF-Initialisierung zusammenhängen, werden also selbst als Teil der
TSF behandelt und aus dieser Perspektive analysiert. Es sollte beachtet werden, dass, obwohl diese als Teil
der TSF behandelt werden, wahrscheinlich eine Begründung (wie von „TSF internals“ (ADV_INT) erlaubt)
vorgenommen werden kann, dass sie nicht den internen Strukturierungsanforderungen von ADV_INT
entsprechen müssen.
ISO/IEC 15408-3 ADV_ARC.1.4C: Die Beschreibung der Sicherheitsarchitektur muss nachweisen, dass sich die
TSF vor Eingriffen schützt.
Der Evaluator muss die Beschreibung der Sicherheitsarchitektur untersuchen, um festzustellen, dass sie
Informationen enthält, die ausreichen, um die Feststellung zu unterstützen, dass die TSF in der Lage ist, sich
vor Eingriffen durch nicht vertrauenswürdige aktive Entitäten zu schützen.
„Eigenschutz“ bezieht sich auf die Fähigkeit der TSF, sich vor Eingriffen durch externe Entitäten zu schützen,
die zu Veränderungen der TSF führen können. Bei TOEs, die von anderen IT-Entitäten abhängig sind, ist es
häufig der Fall, dass der TOE zur Erfüllung seiner Funktionen Dienste nutzt, die von den anderen IT-Entitäten
zur Verfügung gestellt werden. In solchen Fällen schützt sich die TSF allein nicht, da sie auf die anderen
IT-Entitäten angewiesen ist, um einen Teil des Schutzes sicherzustellen. Für die Zwecke der Beschreibung der
Sicherheitsarchitektur gilt der Begriff Eigenschutz nur für die Dienste, die von der TSF über ihre TSFI
bereitgestellt werden, und nicht für Dienste, die von den zugrunde liegenden IT-Entitäten, die sie verwendet,
bereitgestellt werden.
88
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Eigenschutz wird typischerweise durch eine Vielzahl von Mitteln erreicht, die von physischen und
logischen Zugangsbeschränkungen zum TOE über hardwarebasierte Mittel (z. B. „Ausführungsringe“ und
Funktionalität der Speicherverwaltung) bis hin zu softwarebasierten Mitteln (z. B. Begrenzungsprüfung von
Eingaben auf einem vertrauenswürdigen Server) reichen. Der Evaluator stellt fest, dass alle diese
Mechanismen beschrieben sind.
Der Evaluator stellt fest, dass die Designbeschreibung die Art und Weise abdeckt, wie Benutzereingaben von
der TSF so gehandhabt werden, dass die TSF nicht durch diese Benutzereingaben verfälscht werden kann.
Zum Beispiel könnte die TSF den Begriff „Berechtigung“ implementieren und sich durch die Verwendung von
Routinen im bevorrechtigten Modus zur Behandlung von Benutzereingaben schützen. Die TSF könnte von
prozessorbasierten Trennungsmechanismen wie Berechtigungsstufen oder Ringen Gebrauch machen. Die TSF
könnte Softwareschutzkonstrukte oder Codierungskonventionen implementieren, die zur Implementierung
der Trennung von Softwaredomänen beitragen, vielleicht durch die Abgrenzung von Benutzeradressraum und
Systemadressraum. Und die TSF könnte auf ihre Umgebung angewiesen sein, um den Schutz der TSF zu
unterstützen.
Alle Mechanismen, die zu den Funktionen der Domänentrennung beitragen, werden beschrieben. Der
Evaluator sollte Erkenntnisse aus anderen Nachweisen (Funktionsspezifikation, TOE-Design, Beschreibung
der TSF-Interna, andere Teile der Beschreibung der Sicherheitsarchitektur oder Darstellung der
Implementierung, wie sie im Sicherheitspaket für den TOE enthalten sind) nutzen, um festzustellen, ob eine
zum Eigenschutz beitragende Funktionalität beschrieben wurde, die in der Beschreibung der
Sicherheitsarchitektur nicht vorhanden ist.
Die genaue Beschreibung der Eigenschutzmechanismen ist die Eigenschaft, dass die Beschreibung getreu
beschreibt, was umgesetzt wird. Der Evaluator sollte andere Nachweise (Funktionsspezifikation, TOE-Design,
Dokumentation der TSF-Interna, andere Teile der Beschreibung der Sicherheitsarchitektur, Darstellung der
Implementierung, wie sie in der ST für den TOE enthalten sind) nutzen, um festzustellen, ob es in den
Beschreibungen der Eigenschutzmechanismen Unstimmigkeiten gibt. Falls die „Implementation represen-
tation“ (ADV_IMP) im Sicherheitspaket für den TOE enthalten ist, wählt der Evaluator eine Stichprobe für die
Darstellung der Implementierung aus; der Evaluator sollte auch sicherstellen, dass die Beschreibungen für die
gewählte Stichprobe genau sind. Wenn ein Evaluator nicht verstehen kann, wie ein bestimmter Eigenschutz-
mechanismus in der Systemarchitektur funktioniert oder funktionieren könnte, ist gegebenenfalls die
Beschreibung nicht genau.
ISO/IEC 15408-3 ADV_ARC.1.5C: Die Beschreibung der Sicherheitsarchitektur muss nachweisen, dass die TSF die
Umgehung der SFR-durchsetzenden Funktionalität verhindert.
Der Evaluator muss die Beschreibung der Sicherheitsarchitektur untersuchen, um festzustellen, dass sie eine
Analyse enthält, die angemessen beschreibt, wie die SFR-durchsetzenden Mechanismen nicht umgangen
werden können.
Die Nicht-Umgehbarkeit ist eine Eigenschaft, dass die Sicherheitsfunktionalität der TSF (wie durch die SFRs
angegeben) immer aufgerufen wird. Wenn beispielsweise die Zugriffskontrolle auf Dateien als Fähigkeit der
TSF über eine SFR angegeben ist, darf es keine Schnittstellen geben, über die auf Dateien zugegriffen werden
kann, ohne den Zugriffskontrollmechanismus der TSF aufzurufen (z. B. eine Schnittstelle, über die ein Zugriff
auf den Rohdatenträger erfolgt).
Um zu beschreiben, wie die Mechanismen der TSF nicht umgangen werden können, bedarf es im Allgemeinen
einer systematischen Argumentation auf der Grundlage der TSF und der TSFI. Die Beschreibung der
Funktionsweise der TSF (die in den Nachweisen für die Designzerlegung enthalten ist, z. B. in der
Funktionsspezifikation, den TOE-Designunterlagen) liefert – zusammen mit den Informationen in der TSS –
den Hintergrund, der für den Evaluator notwendig ist, um zu verstehen, welche Ressourcen geschützt werden
und welche Sicherheitsfunktionen bereitgestellt werden. Die Funktionsspezifikation enthält Beschreibungen
der TSFIs, über die auf die Ressourcen/Funktionen zugegriffen wird.
89
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator beurteilt die zur Verfügung gestellte Beschreibung (und andere vom Entwickler zur Verfügung
gestellte Informationen, wie z. B. die Funktionsspezifikation), um sicherzustellen, dass keine verfügbare
Schnittstelle zur Umgehung der TSF verwendet werden kann. Dies bedeutet, dass jede verfügbare Schnittstelle
entweder keinen Bezug zu den in der ST beanspruchten SFRs haben darf (und mit nichts interagiert, was zur
Erfüllung der SFRs verwendet wird) oder aber die Sicherheitsfunktionalität, die in anderen Entwicklungs-
nachweisen beschrieben wird, in der beschriebenen Weise verwendet. Zum Beispiel würde ein Spiel
wahrscheinlich nichts mit den SFRs zu tun haben, daher muss erklärt werden, wie es die Sicherheit nicht
beeinträchtigen kann. Der Zugriff auf Benutzerdaten hängt jedoch wahrscheinlich mit den Zugriffskontroll-
SFRs zusammen, daher würde die Erläuterung beschreiben, wie die Sicherheitsfunktionalität funktioniert,
wenn sie über die Datenzugriffsschnittstellen aufgerufen wird. Eine solche Beschreibung wird für jede
verfügbare Schnittstelle benötigt.
Es folgt ein Beispiel für eine Beschreibung. Angenommen, die TSF bietet Dateischutz. Nehmen wir ferner an,
dass, obwohl das „traditionelle“ System TSFIs zum Öffnen, Lesen und Schreiben aufruft, der im TOE-Design
beschriebene Dateischutzmechanismus aufgerufen wird, eine TSFI existiert, die den Zugriff auf eine Batch-
Job-Einrichtung ermöglicht (Erstellen von Batch-Jobs, Löschen von Jobs, Modifizieren unverarbeiteter Jobs).
Der Evaluator sollte in der Lage sein, anhand der vom Anbieter bereitgestellten Beschreibung festzustellen,
dass diese TSFI die gleichen Schutzmechanismen wie die „traditionellen“ Schnittstellen in Anspruch nimmt.
Dies könnte z. B. durch Verweisung auf die entsprechenden Unterabschnitte des TOEs-Designs geschehen, in
denen erörtert wird, wie die Batch-Job-Einrichtung TSFI ihre Sicherheitszielsetzungen erreicht.
Angenommen, es gibt ausgehend von diesem Beispiel eine TSFI, deren einziger Zweck darin besteht, die
Tageszeit anzuzeigen. Der Evaluator sollte feststellen, dass in der Beschreibung angemessen argumentiert
wird, dass diese TSFI nicht in der Lage ist, geschützte Ressourcen zu manipulieren, und dass sie keine
Sicherheitsfunktionalität aufrufen sollte.
Ein weiteres Beispiel für eine Umgehung ist, wenn die TSF die Vertraulichkeit eines kryptographischen
Schlüssels wahren soll (es ist erlaubt, ihn für kryptographische Operationen zu verwenden, es ist aber nicht
erlaubt, zu lesen/zu schreiben). Wenn ein Angreifer direkten physischen Zugriff zu dem Gerät hat, kann er
möglicherweise Seitenkanäle wie den Stromverbrauch des Geräts, die genaue Synchronisierung des Geräts
oder sogar etwaige elektromagnetische Abstrahlung des Geräts untersuchen und daraus den Schlüssel
ableiten.
Wenn solche Seitenkanäle vorhanden sein können, sollte die Vorführung die Mechanismen ansprechen, die
das Auftreten dieser Seitenkanäle verhindern, wie z. B. zufällige interne Uhren, Dual-Line-Technologie usw.
Die Verifizierung dieser Mechanismen würde durch eine Kombination aus rein designorientierten
Argumenten und Prüfungen verifiziert.
Bei einem letzten Beispiel mit Sicherheitsfunktionalität statt einer geschützten Ressource ist eine ST zu
berücksichtigen, die FCO_NRO.2 „Enforced proof of origin“ enthält, was voraussetzt, dass die TSF den
Nachweis der Herkunft für die in der ST angegebenen Informationstypen erbringt. Angenommen, die
„Informationstypen“ enthalten alle Informationen, die vom TOE per E-Mail gesendet werden. In diesem Fall
sollte der Evaluator die Beschreibung untersuchen, um sicherzustellen, dass alle TSFIs, die für den
E-Mail-Versand herangezogen werden können, die Funktion zur „Generierung des Herkunftsnachweises“
erfüllen. Die Beschreibung könnte auf Leitlinien für Benutzer verweisen, die alle Orte aufzeigt, an denen
E-Mails entstehen können (z. B. E-Mail-Programm, Benachrichtigung durch Skripte/Batch-Jobs), und die dann
aufzeigt, wie jeder dieser Orte die Funktion zur Generierung des Herkunftsnachweises aufruft.
Der Evaluator sollte auch sicherstellen, dass die Beschreibung umfassend ist, indem jede Schnittstelle im
Hinblick auf die gesamte Menge der beanspruchten SFRs analysiert wird. Dies kann erfordern, dass der
Evaluator unterstützende Informationen (Funktionsspezifikation, TOE-Design, andere Teile der Beschreibung
der Sicherheitsarchitektur, operative Leitlinien für Benutzer und vielleicht sogar die Darstellung der
Implementierung, wie sie für den TOE vorgesehen ist) untersucht, um festzustellen, dass die Beschreibung alle
Aspekte einer Schnittstelle korrekt erfasst hat. Der Evaluator sollte sich überlegen, welche SFRs jede TSFI
beeinflussen könnte (aus der Beschreibung der TSFI und ihrer Umsetzung in der Begleitdokumentation), und
dann die Beschreibung untersuchen, um festzustellen, ob sie diese Aspekte abdeckt.
90
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
10.4 Funktionsspezifikation (ADV_FSP)
10.4.1 Evaluierung der Unteraufgabe (ADV_FSP.1)
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob der Entwickler eine allgemeine
Beschreibung zumindest der SFR-durchsetzenden und SFR-unterstützenden TSFIs im Hinblick auf die
Beschreibung ihrer Parameter vorgelegt hat. Es gibt keine weiteren erforderlichen Nachweise, von denen
erwartet werden kann, dass sie zur Messung der Genauigkeit dieser Beschreibungen zur Verfügung stehen;
der Evaluator stellt lediglich sicher, dass die Beschreibungen plausibel erscheinen.
10.4.1.2 Eingaben
a) die ST,
c) die operativen Leitlinien für Benutzer.
10.4.1.3 Aktion ADV_FSP.1.1E
ISO/IEC 15408-3 ADV_FSP.1.1C: Die Funktionsspezifikation muss den Zweck und die Verwendungsmethode für
jede SFR-durchsetzende und SFR-unterstützende TSFI beschreiben.
10.4.1.3.1 Workunit ADV_FSP.1-1
Der Evaluator muss die Funktionsspezifikation untersuchen, um festzustellen, dass sie den Zweck jeder
SFR-unterstützenden und SFR-durchsetzenden TSFI angibt.
Der Zweck einer TSFI ist eine allgemeine Aussage, die die von der Schnittstelle bereitgestellte Funktionalität
zusammenfasst. Es ist nicht als eine vollständige Aussage der Aktionen und Ergebnisse im Zusammenhang mit
der Schnittstelle gedacht, sondern eher als eine Aussage, die dem Leser hilft, allgemein zu verstehen, wofür
die Schnittstelle verwendet werden soll. Der Evaluator sollte nicht nur feststellen, dass der Zweck existiert,
sondern auch, dass er die TSFI genau widerspiegelt, indem er andere Informationen über die Schnittstelle, wie
z. B. die Beschreibung der Parameter, berücksichtigt; dies kann in Verbindung mit anderen Workunits für
diese Komponente erfolgen.
Wenn eine über eine Schnittstelle verfügbare Aktion bei der Durchsetzung einer Sicherheitsrichtlinie am TOE
eine Rolle spielt (d. h., wenn eine der Aktionen der Schnittstelle auf eine der auf die TSF erhobenen SFRs
zurückgeführt werden kann), dann ist diese Schnittstelle SFR-durchsetzend. Solche Politiken sind nicht auf die
Zugriffskontrollpolitiken beschränkt, sondern beziehen sich auch auf jede Funktionalität, die von einem der
in der ST enthaltenen SFRs spezifiziert wird. Es ist zu beachten, dass eine Schnittstelle möglicherweise
verschiedene Aktionen und Ergebnisse haben kann, von denen einige SFR-durchsetzend sein können und
andere nicht.
Schnittstellen zu (oder Aktionen, die über eine Schnittstelle verfügbar sind in Bezug auf) Aktionen, von denen
die SFR-durchsetzende Funktionalität abhängt, die aber nur korrekt funktionieren müssen, damit die
Sicherheitspolitiken des TOEs erhalten bleiben, werden als SFR-unterstützend bezeichnet. Schnittstellen zu
Aktionen, von denen die SFR-durchsetzende Funktionalität nicht abhängig ist, werden als SFR-nicht-störend
bezeichnet.
91
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Es sollte beachtet werden, dass eine Schnittstelle, damit sie SFR-unterstützend oder SFR-nicht-störend ist,
keine SFR-durchsetzenden Aktionen oder Ergebnisse haben darf. Im Gegensatz dazu kann eine SFR-durch-
setzende Schnittstelle SFR-unterstützende Aktionen haben (z. B. kann die Möglichkeit, die Systemuhr
einzustellen, eine SFR-durchsetzende Aktion einer Schnittstelle sein, aber wenn dieselbe Schnittstelle zur
Anzeige des Systemdatums verwendet wird, kann diese Aktion nur SFR-unterstützend sein). Ein Beispiel für
eine rein SFR-unterstützende Schnittstelle ist eine Systemaufruf-Schnittstelle, die sowohl von nicht
vertrauenswürdigen Benutzern als auch von einem Teil der TSF, die im Benutzermodus läuft, verwendet wird.
Auf dieser Ebene ist es unwahrscheinlich, dass ein Entwickler Anstrengungen unternommen hat, um
Schnittstellen als SFR-durchsetzend und SFR-unterstützend zu kennzeichnen. Falls dies geschehen ist, sollte
der Evaluator überprüfen, inwieweit die unterstützende Dokumentation (z. B. die operativen Leitlinien für
Benutzer) die Richtigkeit dieser Identifizierung zulässt. Es ist zu beachten, dass diese Identifizierungsaufgabe
für mehrere Workunits bei dieser Komponente notwendig ist.
In dem wahrscheinlicheren Fall, dass der Entwickler die Schnittstellen nicht gekennzeichnet hat, muss der
Evaluator zunächst eine eigene Identifizierung der Schnittstellen vornehmen und dann feststellen, ob die
erforderlichen Informationen (für diese Workunit der Zweck) vorhanden sind. Auch hier wird diese
Identifizierung aufgrund fehlender unterstützender Nachweise schwierig sein und nur eine geringe
Vertrauenswürdigkeit bieten, dass alle geeigneten Schnittstellen korrekt identifiziert wurden, aber dennoch
prüft der Evaluator andere für den TOE verfügbare Nachweise, um eine möglichst vollständige Abdeckung
sicherzustellen.
Der Evaluator muss die Funktionsspezifikation untersuchen, um festzustellen, dass die Verwendungs-
methode für jede SFR-unterstützende und SFR-durchsetzende TSFI gegeben ist.
Siehe Workunit ADV_FSP.1-1 für eine Erörterung der Identifizierung von SFR-unterstützender und
SFR-durchsetzender TSFI.
Die Verwendungsmethode für eine TSFI fasst zusammen, wie die Schnittstelle manipuliert wird, um die
Aktionen aufzurufen und die mit der TSFI verbundenen Ergebnisse zu erhalten. Der Evaluator sollte in der
Lage sein, anhand der Lektüre dieses Materials in der Funktionsspezifikation zu bestimmen, wie jede
Schnittstelle zu verwenden ist. Dies bedeutet nicht unbedingt, dass es für jede TSFI eine eigene
Verwendungsmethode geben muss, da es beispielsweise möglich sein kann, allgemein zu beschreiben, wie
Kernel-Aufrufe aufgerufen werden, und dann jede Schnittstelle mit diesem allgemeinen Typ zu identifizieren.
Unterschiedliche Arten von Schnittstellen erfordern unterschiedliche Nutzungsspezifikationen. APIs,
Netzwerkprotokoll-Schnittstellen, Systemkonfigurationsparameter und Hardware-Bus-Schnittstellen haben
alle sehr unterschiedliche Verwendungsmethoden, und dies sollte sowohl vom Entwickler bei der
Entwicklung der Funktionsspezifikation als auch vom Evaluator bei der Evaluierung der
Funktionsspezifikation berücksichtigt werden.
Bei administrativen Schnittstellen, deren Funktionalität als unzugänglich für nicht vertrauenswürdige
Benutzer dokumentiert ist, stellt der Evaluator sicher, dass das Verfahren, mit dem die Funktionen
unzugänglich gemacht werden, in der Funktionsspezifikation beschrieben wird. Es sollte beachtet werden,
dass diese Unzugänglichkeit vom Entwickler in seiner Prüfreihe geprüft werden muss.
ISO/IEC 15408-3 ADV_FSP.1.2C: Die Funktionsspezifikation muss alle Parameter identifizieren, die mit jeder
SFR-durchsetzenden und SFR-unterstützenden TSFI verknüpft sind.
92
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss die Darstellung der TSFI untersuchen, um festzustellen, dass sie alle Parameter
identifiziert, die mit jeder SFR-durchsetzenden und SFR-unterstützenden TSFI verbunden sind.
Siehe Workunit ADV_FSP.1-1 für eine Erörterung der Identifizierung von SFR-unterstützender und
SFR-durchsetzender TSFI.
Der Evaluator untersucht die Funktionsspezifikation, um sicherzustellen, dass alle Parameter für die
identifizierte TSFI beschrieben sind. Parameter sind explizite Ein- oder Ausgaben an eine Schnittstelle, die das
Verhalten dieser Schnittstelle steuern. Parameter sind z. B. die Argumente, die an eine API geliefert werden;
die verschiedenen Felder im Paket für ein bestimmtes Netzwerkprotokoll; die einzelnen Schlüsselwerte in der
Windows-Registry; die Signale über eine Menge Pins auf einem Chip; usw.
Obwohl es schwierig ist, viel Vertrauenswürdigkeit darüber zu erhalten, dass alle Parameter für die
zutreffende TSFI identifiziert wurden, sollte der Evaluator auch andere für die Evaluierung zur Verfügung
gestellte Belege (z. B. operative Leitlinien für Benutzer) prüfen, um zu sehen, ob das Verhalten oder zusätzliche
Parameter dort, aber nicht in der Funktionsspezifikation beschrieben sind.
ISO/IEC 15408-3 ADV_FSP.1.3C: Die Funktionsspezifikation muss eine Begründung für die implizite
Kategorisierung von Schnittstellen als SFR-nicht-störend bereitstellen.
Der Evaluator muss die vom Entwickler angegebene Begründung für die implizite Einstufung von
Schnittstellen als SFR-nicht-störend untersuchen, um festzustellen, ob sie zutreffend ist.
In dem Fall, dass der Entwickler eine angemessene Dokumentation zur Durchführung der von den übrigen
Workunits für diese Komponente geforderten Analyse vorgelegt hat, ohne die SFR-durchsetzenden und
SFR-unterstützenden Schnittstellen explizit anzugeben, sollte diese Workunit als zufriedenstellend betrachtet
werden.
Diese Workunit soll für Fälle gelten, in denen der Entwickler einen Teil der TSFI nicht beschrieben hat und
behauptet, dass er SFR-nicht-störend ist und daher keinen anderen Anforderungen an diese Komponente
unterliegt. In einem solchen Fall legt der Entwickler eine Begründung für diese Charakterisierung in
ausreichender Detailliertheit vor, so dass der Evaluator die Begründung, die Eigenschaften der betroffenen
Schnittstellen (z. B. ihre anspruchsvolle Funktion in Bezug auf den TOE, wie z. B. „Farbpalettenmanipulation“)
versteht und dass die Behauptung unterstützt wird, dass diese SFR-nicht-störend sind. Angesichts der
Vertrauenswürdigkeitsstufe sollte der Evaluator nicht mehr Details erwarten, als für die SFR-durchsetzenden
oder SFR-unterstützenden Schnittstellen vorgesehen sind, und in der Tat sollten es viel weniger Details sein.
In den meisten Fällen sollten einzelne Schnittstellen nicht in dem vom Entwickler bereitgestellten
Begründungsteil behandelt werden müssen.
ISO/IEC 15408-3 ADV_FSP.1.4C: Die Rückverfolgung muss nachweisen, dass die SFRs auf TSFIs in der
Funktionsspezifikation zurückgehen.
Der Evaluator muss prüfen, ob die Verfolgung die SFRs mit den entsprechenden TSFIs verbindet.
Die Verfolgung wird vom Entwickler zur Verfügung gestellt, um als Leitfaden dafür zu dienen, welche SFRs mit
welchen TSFIs in Verbindung stehen. Diese Verfolgung kann so einfach wie eine Tabelle sein; sie wird als
Eingabe für den Evaluator zur Verwendung in den folgenden Workunits verwendet, in denen der Evaluator
ihre Vollständigkeit und Genauigkeit überprüft.
93
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss die Funktionsspezifikation untersuchen, um festzustellen, dass es sich um eine
vollständige Instanziierung der SFRs handelt.
Um sicherzustellen, dass alle SFRs durch die Funktionsspezifikation sowie die Prüfabdeckungsanalyse
abgedeckt sind, kann der Evaluator auf der Verfolgung des Entwicklers aufbauen (siehe ADV_FSP.1-5 eine
Zuordnung zwischen den funktionalen Sicherheitsanforderungen des TOEs und der TSFI). Es ist zu beachten,
dass diese Zuordnung aufgrund von Operationen (Zuweisungen, Präzisierungen, Selektionen), die der
ST-Autor an der funktionalen Anforderung vorgenommen hat, möglicherweise in einem Detaillierungsgrad
unterhalb der Komponenten- oder sogar Elementebene der Anforderungen liegen muss.
Beispielsweise enthält die Komponente FDP_ACC.1 ein Element mit Zuweisungen. Wenn die ST beispielsweise
zehn Regeln in der Zuweisung FDP_ACC.1 enthielt und diese zehn Regeln durch drei verschiedene TSFIs
abgedeckt waren, wäre es für den Evaluator unangemessen, FDP_ACC.1 auf TSFI A, B und C abzubilden und zu
behaupten, dass er die Workunit abgeschlossen hätte. Stattdessen würde der Evaluator FDP_ACC.1 (Regel 1)
auf TSFI A; FDP_ACC.1 (Regel 2) auf TSFI B; usw. abbilden. Es könnte auch der Fall sein, dass es sich bei der
Schnittstelle um eine Wrapper-Schnittstelle (z. B. IOCTL) handelt. In diesem Fall müsste die Zuordnung auf
eine bestimmte Menge Parameter für eine bestimmte Schnittstelle spezifisch sein.
Der Evaluator muss erkennen, dass bei Anforderungen, die sich an der TSF-Grenze nur wenig oder gar nicht
manifestieren (z. B. FDP_RIP), nicht erwartet wird, dass er diese Anforderungen vollständig auf das TSFI
abbildet. Die Analyse für diese Anforderungen wird in der Analyse für das TOE-Design (ADV_TDS)
durchgeführt, wenn sie in die ST aufgenommen wird. Da die mit TSFIs verbundenen Parameter vollständig
spezifiziert werden müssen, ist es auch wichtig zu beachten, dass der Evaluator in der Lage sein sollte
festzustellen, ob alle Aspekte einer SFR auf der Schnittstellenebene implementiert zu sein scheinen.
Der Evaluator muss die Funktionsspezifikation untersuchen, um festzustellen, dass es sich um eine genaue
Instanziierung der SFRs handelt.
Für jede funktionale Anforderung in der ST, die zu an der TSF-Grenze sichtbaren Auswirkungen führt, geben
die Informationen in der zugehörigen TSFI für diese Anforderung die durch die Anforderung beschriebene
erforderliche Funktionalität an. Wenn die ST beispielsweise eine Anforderung für Zugriffskontrolllisten
enthält und die einzige TSFI, die auf diese Anforderung abbildet, Funktionalität für Unix-ähnliche Schutzbits
spezifiziert, dann ist die Funktionsspezifikation in Bezug auf die Anforderungen nicht genau.
manifestieren (z. B. FDP_RIP), nicht erwartet wird, dass der Evaluator diese Anforderungen vollständig auf
das TSFI abbildet. Die Analyse für diese Anforderungen wird in der Analyse für das „TOE design“ (ADV_TDS)
durchgeführt, wenn sie in die ST aufgenommen wird.
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob der Entwickler eine Beschreibung der
TSFIs in Bezug auf ihren Zweck, die Verwendungsmethode und die Parameter vorgelegt hat. Darüber hinaus
werden auch die SFR-durchsetzenden Aktionen, Ergebnisse und Fehlermeldungen jeder TSFI, die
SFR-durchsetzend ist, beschrieben.
94
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
10.4.2.2 Eingaben
Der von den Workunits geforderte Evaluationsnachweis für diese Unteraufgabe ist
a) die ST,
c) das TOE-Design.
Der Evaluationsnachweis für diese Unteraufgabe, der verwendet wird, wenn er in der ST für den TOE
enthalten ist, ist
a) die Beschreibung der Sicherheitsarchitektur,
b) die operativen Leitlinien für Benutzer.
ISO/IEC 15408-3 ADV_FSP.2.1C: Die Funktionsspezifikation muss die TSF vollständig darstellen.
Der Evaluator muss die Funktionsspezifikation untersuchen, um festzustellen, dass die TSF vollständig
dargestellt ist.
Die Identifizierung der TSFI ist eine notwendige Voraussetzung für alle anderen Aufgaben in dieser
Unteraufgabe. Die TSF muss identifiziert werden (als Teil der Workunits „TOE design“ (ADV_TDS) zur
Identifizierung der TSFI. Diese Aufgabe kann auf hoher Ebene durchgeführt werden, um sicherzustellen, dass
keine großen Gruppen von Schnittstellen (Netzwerkprotokolle, Hardwareschnittstellen, Konfigurations-
dateien) versäumt wurden, oder auf niedriger Ebene, wenn die Evaluierung der Funktionsspezifikation
voranschreitet.
Bei der Beurteilung für diese Workunit stellt der Evaluator fest, dass alle Teile der TSF in Bezug auf die in der
Funktionsspezifikation aufgeführten Schnittstellen angesprochen werden. Alle Teile der TSF sollten eine
entsprechende Schnittstellenbeschreibung haben, oder wenn es für einen Teil der TSF keine entsprechenden
Schnittstellen gibt, bestimmt der Evaluator, dass dies annehmbar ist.
alle TSFIs beschreiben.
Der Evaluator muss die Funktionsspezifikation untersuchen, um festzustellen, dass sie den Zweck jeder TSFI
angibt.
der Schnittstelle gedacht, sondern als eine Aussage, die dem Leser helfen soll, allgemein zu verstehen, wofür
sondern auch, dass er die TSFI genau widerspiegelt, indem er andere Informationen über die Schnittstelle
berücksichtigt, wie z. B. die Beschreibung der Aktionen und Fehlermeldungen.
95
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
methode für jede TSFI gegeben ist.
Entwicklung der Funktionsspezifikation als auch vom Evaluator bei der Evaluierung der Funktions-
spezifikation berücksichtigt werden.
Der Evaluator sollte nicht nur feststellen, dass es eine Menge Beschreibungen der Verwendungsmethode gibt,
sondern auch, dass sie jede TSFI genau abdecken.
ISO/IEC 15408-3 ADV_FSP.2.3C: Die Funktionsspezifikation muss alle Parameter identifizieren und beschreiben,
die mit jeder TSFI verknüpft sind.
vollständig identifiziert, die mit jeder TSFI verbunden sind.
Der Evaluator untersucht die Funktionsspezifikation, um sicherzustellen, dass alle Parameter für jede TSFI
beschrieben sind. Parameter sind explizite Ein- oder Ausgaben an eine Schnittstelle, die das Verhalten dieser
Schnittstelle steuern. Parameter sind z. B. die Argumente, die an eine API geliefert werden; die verschiedenen
Felder im Paket für ein bestimmtes Netzwerkprotokoll; die einzelnen Schlüsselwerte in der Windows-
Registry; die Signale über eine Menge Pins auf einem Chip; usw.
Um festzustellen, dass alle Parameter in der TSFI vorhanden sind, sollte der Evaluator die restliche
Schnittstellenbeschreibung (Aktionen, Fehlermeldungen usw.) untersuchen, um festzustellen, ob die
Auswirkungen des Parameters in der Beschreibung berücksichtigt werden. Der Evaluator sollte auch andere
für die Evaluierung vorgelegte Nachweise (z. B. TOE-Design, Beschreibung der Sicherheitsarchitektur,
operative Leitlinien für Benutzer, Darstellung der Implementierung) daraufhin prüfen, ob das Verhalten oder
zusätzliche Parameter zwar dort, nicht aber in der Funktionsspezifikation beschrieben sind.
vollständig und genau beschreibt, die mit jeder TSFI verbunden sind.
Wenn alle Parameter identifiziert sind, muss der Evaluator sicherstellen, dass sie genau beschrieben werden
und dass die Beschreibung der Parameter vollständig ist. Eine Parameterbeschreibung sagt auf sinnvolle
Weise, um was für einen Parameter es sich handelt. Zum Beispiel könnte die Schnittstelle foo(i) als
„Parameter i, der eine ganze Zahl ist“ beschrieben werden; dies ist keine akzeptable Parameterbeschreibung.
Eine Beschreibung wie „Parameter i ist eine ganze Zahl, die die Anzahl der derzeit im System angemeldeten
Benutzer angibt“ ist viel akzeptabler.
96
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Um festzustellen, ob die Beschreibung der Parameter vollständig ist, sollte der Evaluator die restliche
Schnittstellenbeschreibung (Zweck, Verwendungsmethode, Aktionen, Fehlermeldungen usw.) untersuchen,
um festzustellen, ob die Beschreibungen des/der Parameter(s) in der Beschreibung berücksichtigt werden.
Der Evaluator sollte auch andere vorgelegte Nachweise (z. B. TOE-Design, architektonische Gestaltung,
ISO/IEC 15408-3 ADV_FSP.2.4C: Für jede SFR-durchsetzende TSFI muss die Funktionsspezifikation die
SFR-durchsetzenden Aktionen beschreiben, die mit der TSFI verknüpft sind.
Der Evaluator muss die Darstellung der TSFI untersuchen, um festzustellen, dass sie die SFR-durchsetzenden
Aktionen, die mit den SFR-durchsetzenden TSFIs verbunden sind, vollständig und genau beschreibt.
Wenn eine Aktion, die über eine Schnittstelle verfügbar ist, zu einer der auf die TSF erhobene SFR
zurückverfolgt werden kann, dann ist diese Schnittstelle SFR-durchsetzend. Solche Politiken sind nicht auf die
andere nicht.
Der Entwickler ist nicht verpflichtet, Schnittstellen als SFR-durchsetzend zu „kennzeichnen“, und er ist
ebenfalls nicht verpflichtet, über eine Schnittstelle verfügbare Aktionen als SFR-durchsetzend zu
identifizieren. Es liegt in der Verantwortung des Evaluators, die vom Entwickler vorgelegten Nachweise zu
untersuchen und festzustellen, ob die erforderlichen Informationen vorhanden sind. Wenn der Entwickler die
SFR-durchsetzenden TSFIs und die über diese TSFIs verfügbaren SFR-durchsetzenden Aktionen identifiziert
hat, muss der Evaluator die Vollständigkeit und Genauigkeit auf der Grundlage anderer für die Evaluierung
zur Verfügung gestellter Informationen (z. B. TOE-Design, Beschreibung der Sicherheitsarchitektur, operative
Leitlinien für Benutzer) und auf der Grundlage der anderen für die Schnittstellen vorgelegten Informationen
(Parameter und Parameterbeschreibungen, Fehlermeldungen usw.) beurteilen.
In diesem Fall (wenn der Entwickler nur die SFR-durchsetzenden Informationen für die SFR-durchsetzende
TSFI bereitgestellt hat) stellt der Evaluator auch sicher, dass keine Schnittstellen falsch eingeteilt wurden. Dies
geschieht durch Untersuchung anderer Informationen, die für die Evaluierung zur Verfügung gestellt werden
(z. B. TOE-Design, Beschreibung der Sicherheitsarchitektur, operative Leitlinien für Benutzer), sowie der
anderen Informationen, die für die nicht als SFR-durchsetzend gekennzeichneten Schnittstellen (z. B.
Parameter und Parameterbeschreibungen) vorgelegt werden.
In dem Fall, dass der Entwickler für alle Schnittstellen den gleichen Informationsstand bereitgestellt hat, führt
der Evaluator die gleiche Art von Analyse durch, die in den vorhergehenden Absätzen erwähnt wurde. Der
Evaluator sollte feststellen, welche Schnittstellen SFR-durchsetzend sind und welche nicht, und anschließend
sicherstellen, dass die SFR-durchsetzenden Aspekte der SFR-durchsetzenden Aktionen angemessen
beschrieben werden.
Die SFR-durchsetzenden Aktionen sind diejenigen, die an jeder externen Schnittstelle sichtbar sind und die
Durchsetzung der beanspruchten SFRs vorsehen. Wenn z. B. Audit-Anforderungen in die ST aufgenommen
werden, wären auditbezogene Aktionen SFR-durchsetzend und müssen daher beschrieben werden, auch
wenn das Ergebnis dieser Aktion im Allgemeinen nicht über die aufgerufene Schnittstelle sichtbar ist (wie es
oft bei einem Audit der Fall ist, bei dem eine Benutzeraktion an einer Schnittstelle zu einem Audit-Datensatz
führen würde, der an einer anderen Schnittstelle sichtbar ist).
97
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der erforderliche Grad der Beschreibung ist derjenige, der ausreicht, damit der Leser versteht, welche Rolle
die TSFI-Aktionen in Bezug auf die SFR spielen. Der Evaluator sollte bedenken, dass die Beschreibung
detailliert genug sein sollte, um die Generierung (und Beurteilung) von Prüffällen gegen diese Schnittstelle zu
unterstützen. Wenn die Beschreibung unklar ist oder es an Details fehlt, so dass keine aussagekräftigen
Prüfungen gegen die TSFI durchgeführt werden können, ist die Beschreibung wahrscheinlich unzureichend.
ISO/IEC 15408-3 ADV_FSP.2.5C: Für jede SFR-durchsetzende TSFI muss die Funktionsspezifikation direkte
Fehlermeldungen beschreiben, die sich aus der mit den SFR-durchsetzenden Aktionen verknüpften Verarbeitung
ergeben.
Der Evaluator muss die Darstellung der TSFI untersuchen, um festzustellen, dass sie Fehlermeldungen, die
sich aus den SFR-durchsetzenden Aktionen, die mit jeder SFR-durchsetzenden TSFI verbunden sind, ergeben
können, vollständig und genau beschreibt.
Diese Workunit sollte in Verbindung mit oder nach der Workunit ADV_FSP.2-6 durchgeführt werden, um
sicherzustellen, dass die Menge SFR-durchsetzender TSFI und SFR-durchsetzender Aktionen korrekt
identifiziert wird. Der Entwickler kann mehr Informationen als erforderlich zur Verfügung stellen (z. B. alle
mit jeder Schnittstelle zusammenhängenden Fehlermeldungen). In diesem Fall sollte der Evaluator seine
Beurteilung der Vollständigkeit und Genauigkeit auf die Fehlermeldungen beschränken, von denen er
feststellt, dass sie mit SFR-durchsetzenden Aktionen der SFR-durchsetzenden TSFI verbunden sind.
Fehler können viele Formen annehmen, je nachdem, welche Schnittstelle beschrieben wird. Bei einer API kann
die Schnittstelle selbst einen Fehlercode zurückgeben, eine globale Fehlerbedingung setzen oder einen
bestimmten Parameter mit einem Fehlercode setzen. Bei einer Konfigurationsdatei kann ein falsch
konfigurierter Parameter dazu führen, dass eine Fehlermeldung in eine Protokolldatei geschrieben wird. Bei
einer Hardware-PCI-Karte kann ein Fehlerzustand ein Signal auf dem Bus auslösen oder eine Ausnahme-
bedingung an die CPU auslösen.
Fehler (und die damit verbundenen Fehlermeldungen) entstehen durch das Aufrufen einer Schnittstelle. Die
Verarbeitung, die als Reaktion auf den Schnittstellenaufruf erfolgt, kann auf Fehlerbedingungen stoßen, die
(durch einen implementierungsspezifischen Mechanismus) die Erzeugung einer Fehlermeldung auslösen. In
einigen Fällen kann dies ein Rückgabewert von der Schnittstelle selbst sein; in anderen Fällen kann nach dem
Aufruf einer Schnittstelle ein globaler Wert gesetzt und geprüft werden. Es ist wahrscheinlich, dass ein TOE
eine Menge niedriger Fehlermeldungen hat, die sich aus grundlegenden Ressourcenbedingungen ergeben
können, wie z. B. „Datenträger voll“ oder „Ressource gesperrt“. Diese Fehlermeldungen können zwar auf eine
große Anzahl von TSFIs abbilden, aber sie könnten dazu verwendet werden, Fälle zu erkennen, in denen
Details in einer Schnittstellenbeschreibung ausgelassen wurden. Zum Beispiel könnte eine TSFI, die eine
Meldung „Datenträger voll“ erzeugt, aber keine offensichtliche Beschreibung hat, warum diese TSFI in ihrer
Beschreibung der Aktionen einen Zugriff auf den Datenträger verursachen sollte, den Evaluator veranlassen,
andere Nachweise („Security Architecture“ (ADV_ARC), „TOE design“ (ADV_TDS)) in Bezug auf diese TSFI zu
untersuchen, um festzustellen, ob die Beschreibung genau ist.
Um festzustellen, dass die Beschreibung der Fehlermeldungen einer TSFI genau und vollständig ist, bemisst
der Evaluator die Schnittstellenbeschreibung im Vergleich zu den anderen für die Evaluierung vorgelegten
Nachweisen (z. B. TOE-Design, Beschreibung der Sicherheitsarchitektur, operative Leitlinien für Benutzer)
sowie im Vergleich zu anderen für diese TSFI verfügbaren Nachweisen (Parameter, Analyse aus der Workunit
ADV_FSP.2-6).
ISO/IEC 15408-3 ADV_FSP.2.6C: Die Rückverfolgung muss nachweisen, dass die SFRs auf TSFIs in der Funktions-
spezifikation zurückgehen.
98
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
abgedeckt sind, kann der Evaluator auf der Verfolgung des Entwicklers aufbauen (siehe ADV_FSP.2-8 für eine
abgedeckt waren, wäre es für den Evaluator nicht ausreichend, FDP_ACC.1 auf TSFI A, B und C abzubilden und
zu behaupten, dass er die Workunit abgeschlossen hätte. Stattdessen würde der Evaluator FDP_ACC.1
(Regel 1) auf TSFI A; FDP_ACC.1 (Regel 2) auf TSFI B; usw. abbilden. Es könnte auch der Fall sein, dass es sich
bei der Schnittstelle um eine Wrapper-Schnittstelle (z. B. IOCTL) handelt. In diesem Fall müsste die Zuordnung
auf eine bestimmte Menge Parameter für eine bestimmte Schnittstelle spezifisch sein.
durchgeführt, wenn sie in die ST aufgenommen wird. Da die mit TSFIs verbundenen Parameter, Aktionen und
Fehlermeldungen vollständig spezifiziert werden müssen, ist es auch wichtig zu beachten, dass der Evaluator
in der Lage sein sollte festzustellen, ob alle Aspekte einer SFR auf der Schnittstellenebene implementiert zu
sein scheinen.
das TSFI abbildet. Die Analyse für diese Anforderungen wird in der Analyse für das TOE-Design (ADV_TDS)
99
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob der Entwickler eine Beschreibung der
TSFIs in Bezug auf ihren Zweck, die Verwendungsmethode und die Parameter vorgelegt hat. Darüber hinaus
werden auch die Aktionen, Ergebnisse und Fehlermeldungen jeder TSFI hinreichend beschrieben, so dass
festgestellt werden kann, ob sie SFR-durchsetzend sind, wobei die SFR-durchsetzende TSFI detaillierter
beschrieben wird als andere TSFIs.
10.4.3.2 Eingaben
a) die ST,
c) das TOE-Design.
enthalten ist, ist
b) die Darstellung der Implementierung,
c) die Beschreibung der TSF-Interna,
d) die operativen Leitlinien für Benutzer.
dargestellt ist.
Unteraufgabe. Die TSF muss identifiziert werden (als Teil der Workunits „TOE design“ (ADV_TDS)) zur
voranschreitet.
100
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
angibt.
die mit jeder TFSI verknüpft sind.
101
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
ISO/IEC 15408-3 ADV_FSP.3.4C: Für jede SFR-durchsetzende TSFI muss die Funktionsspezifikation die
SFR-durchsetzenden Aktionen beschreiben, die mit der TSFI verknüpft sind.
Der Evaluator muss die Darstellung der TSFI untersuchen, um festzustellen, dass sie die SFR-durchsetzenden
Aktionen, die mit den SFR-durchsetzenden TSFIs verbunden sind, vollständig und genau beschreibt.
Wenn eine über eine Schnittstelle verfügbare Aktion bei der Durchsetzung einer Sicherheitsrichtlinie am TOE
eine Rolle spielt (d. h., wenn eine der Aktionen der Schnittstelle auf eine der auf die TSF erhobenen SFRs
zurückgeführt werden kann), dann ist diese Schnittstelle SFR-durchsetzend. Solche Politiken sind nicht auf die
andere nicht.
Der Entwickler ist nicht verpflichtet, Schnittstellen als SFR-durchsetzend zu „kennzeichnen“, und er ist
ebenfalls nicht verpflichtet, über eine Schnittstelle verfügbare Aktionen als SFR-durchsetzend zu
identifizieren. Es liegt in der Verantwortung des Evaluators, die vom Entwickler vorgelegten Nachweise zu
untersuchen und festzustellen, ob die erforderlichen Informationen vorhanden sind. Wenn der Entwickler die
SFR-durchsetzenden TSFIs und die über diese TSFIs verfügbaren SFR-durchsetzenden Aktionen identifiziert
hat, muss der Evaluator die Vollständigkeit und Genauigkeit auf der Grundlage anderer für die Evaluierung
zur Verfügung gestellter Informationen (z. B. TOE-Design, Beschreibung der Sicherheitsarchitektur, operative
operative Leitlinien für Benutzer) und auf der Grundlage der anderen für die Schnittstellen vorgelegten
Informationen (Parameter und Parameterbeschreibungen, Fehlermeldungen usw.) beurteilen.
In diesem Fall (der Entwickler hat nur die SFR-durchsetzenden Informationen für die SFR-durchsetzende TSFI
bereitgestellt) stellt der Evaluator auch sicher, dass keine Schnittstellen falsch eingeteilt wurden. Dies
geschieht durch Untersuchung anderer Informationen, die für die Evaluierung zur Verfügung gestellt werden
(z. B. TOE-Design, Beschreibung der Sicherheitsarchitektur, operative Leitlinien für Benutzer), sowie der
anderen Informationen, die für die nicht als SFR-durchsetzend gekennzeichneten Schnittstellen (z. B.
Parameter und Parameterbeschreibungen) vorgelegt werden. Die Analyse, die für die Workunits ADV_FSP.3-7
und ADV_FSP.3-8 durchgeführt wurde, wird ebenfalls für diese Bestimmung verwendet.
102
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
In dem Fall, dass der Entwickler für alle Schnittstellen den gleichen Informationsstand bereitgestellt hat, führt
der Evaluator die gleiche Art von Analyse durch, die in den vorhergehenden Absätzen erwähnt wurde. Der
Evaluator sollte feststellen, welche Schnittstellen SFR-durchsetzend sind und welche nicht, und anschließend
sicherstellen, dass die SFR-durchsetzenden Aspekte der SFR-durchsetzenden Aktionen angemessen
beschrieben werden. Es ist zu beachten, dass der Evaluator in diesem Fall in der Lage sein sollte, den Großteil
der Arbeit, die mit der Workunit ADV_FSP.3-8 verbunden ist, im Verlauf der Durchführung dieser
SFR-durchsetzenden Analyse durchzuführen.
Die SFR-durchsetzenden Aktionen sind diejenigen, die an jeder externen Schnittstelle sichtbar sind und die
Durchsetzung der beanspruchten SFRs vorsehen. Wenn z. B. Audit-Anforderungen in die ST aufgenommen
werden, wären auditbezogene Aktionen SFR-durchsetzend und müssen daher beschrieben werden, auch
wenn das Ergebnis dieser Aktion im Allgemeinen nicht über die aufgerufene Schnittstelle sichtbar ist (wie es
oft bei einem Audit der Fall ist, bei dem eine Benutzeraktion an einer Schnittstelle zu einem Audit-Datensatz
führen würde, der an einer anderen Schnittstelle sichtbar ist).
Der erforderliche Grad der Beschreibung ist derjenige, der ausreicht, damit der Leser versteht, welche Rolle
die TSFI-Aktionen in Bezug auf die SFR spielen. Der Evaluator sollte bedenken, dass die Beschreibung
detailliert genug sein sollte, um die Generierung (und Beurteilung) von Prüffällen gegen diese Schnittstelle zu
unterstützen. Wenn die Beschreibung unklar ist oder es an Details fehlt, so dass keine aussagekräftigen
Prüfungen gegen die TSFI durchgeführt werden können, ist die Beschreibung wahrscheinlich unzureichend.
ISO/IEC 15408-3 ADV_FSP.3.5C: Für jede SFR-durchsetzende TSFI muss die Funktionsspezifikation direkte
Fehlermeldungen beschreiben, die sich aus dem Aufruf von mit der TSFI verknüpften SFR-durchsetzenden
Aktionen und Ausnahmen ergeben.
Der Evaluator muss die Darstellung der TSFI untersuchen, um festzustellen, dass sie Fehlermeldungen, die
sich aus einem Aufruf jeder SFR-durchsetzenden TSFI ergeben können, vollständig und genau beschreibt.
Diese Workunit sollte in Verbindung mit oder nach der Workunit ADV_FSP.3-6 durchgeführt werden, um
sicherzustellen, dass die Menge SFR-durchsetzender TSFI-Aktionen korrekt identifiziert wird. Der Evaluator
sollte beachten, dass die Anforderung und die damit verbundene Workunit darin besteht, dass alle direkten
Fehlermeldungen, die mit einer SFR-durchsetzenden TSFI verbunden sind, beschrieben werden müssen, die
mit SFR-durchsetzenden Aktionen verbunden sind. Der Grund dafür ist, dass auf dieser Vertrauens-
würdigkeitsstufe die „zusätzlichen“ Informationen der Fehlermeldungsbeschreibungen verwendet werden
sollten, um festzustellen, ob alle SFR-durchsetzenden Aspekte einer Schnittstelle angemessen beschrieben
worden sind. Wenn beispielsweise eine Fehlermeldung im Zusammenhang mit einer TSFI (z. B. „Zugriff
verweigert“) darauf hinweist, dass eine SFR-durchsetzende Entscheidung oder Aktion stattgefunden hat, aber
in der Beschreibung der SFR-durchsetzenden Aktionen kein Hinweis auf diesen speziellen SFR-durchsetzen-
den Mechanismus enthalten ist, dann ist die Beschreibung möglicherweise nicht vollständig.
103
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Beschreibung der Aktionen einen Zugriff auf den Datenträger verursachen sollte, den Evaluator veranlassen,
untersuchen, um festzustellen, ob die Beschreibung genau ist.
Um festzustellen, dass die Beschreibung der Fehlermeldungen einer TSFI genau und vollständig ist, bemisst
der Evaluator die Schnittstellenbeschreibung im Vergleich zu den anderen für die Evaluierung vorgelegten
Nachweisen (z. B. TOE-Design, Beschreibung der Sicherheitsarchitektur, operative Leitlinien für Benutzer)
sowie bei anderen für diese TSFI vorgelegten Nachweisen (Beschreibung der SFR-durchsetzenden Aktionen,
Zusammenfassung der SFR-unterstützenden und SFR-nicht-störenden Aktionen und Ergebnisse).
ISO/IEC 15408-3 ADV_FSP.3.6C: Die Funktionsspezifikation muss die SFR-unterstützenden und

SFR-nicht-störenden Aktionen zusammenfassen, die mit jeder TSFI verknüpft sind.
Der Evaluator muss die Darstellung der TSFI untersuchen, um festzustellen, dass sie die SFR-unterstützenden
und SFR-nicht-störenden Aktionen in Verbindung mit jeder einzelnen TSFI zusammenfasst.
Der Zweck dieser Workunit ist es, die Details über die SFR-durchsetzenden Aktionen (die in der Workunit
ADV_FSP.3-6 zur Verfügung gestellt werden) durch eine Zusammenfassung der verbleibenden Aktionen (d. h.
derjenigen, die nicht SFR-durchsetzend sind) zu ergänzen. Dies umfasst alle SFR-unterstützenden und
SFR-nicht-störenden Aktionen, unabhängig davon, ob sie durch SFR-durchsetzende TSFIs oder durch
SFR-unterstützende oder SFR-nicht-störende TSFIs ausgelöst werden. Eine solche Zusammenfassung über
alle SFR-unterstützenden und SFR-nicht-störenden Aktionen trägt dazu bei, ein vollständigeres Bild der von
der TSF bereitgestellten Funktionen zu vermitteln, und ist vom Evaluator zu verwenden, um festzustellen, ob
eine Aktion oder eine TSFI möglicherweise falsch eingeteilt wurde.
Die bereitzustellenden Informationen sind abstrakter als die, die für SFR-durchsetzende Aktionen erforderlich
sind. Sie sollten zwar immer noch detailliert genug sein, damit der Leser verstehen kann, was die Aktion
bewirkt, aber die Beschreibung muss nicht detailliert genug sein, um z. B. Schreibprüfungen gegen die Aktion
zu unterstützen. Für den Evaluator kommt es darauf an, dass die Informationen ausreichen, um eine positive
Feststellung vorzunehmen, ob die Aktion SFR-unterstützend oder SFR-nicht-störend ist. Wenn diese
Informationen fehlen, ist die Zusammenfassung unzureichend, und es müssen weitere Informationen
eingeholt werden.
104
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
abgedeckt sind, kann der Evaluator auf der Verfolgung des Entwicklers aufbauen (siehe ADV_FSP.3-9 eine
sein scheinen.
Zielsetzung dieser Unteraufgabe ist es festzustellen, ob der Entwickler alle TSFIs vollständig und genau
beschrieben hat, so dass der Evaluator feststellen kann, ob die TSFIs vollständig und genau beschrieben sind,
und ob er die funktionalen Sicherheitsanforderungen der ST zu implementieren scheint.
105
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
10.4.4.2 Eingaben
a) die ST,
c) das TOE-Design.
enthalten ist, ist
b) die Darstellung der Implementierung,
Die Funktionsspezifikation beschreibt die Schnittstellen für die TSF (die TSFI) auf strukturierte Weise.
Aufgrund der Abhängigkeit von der „Evaluation of sub-activity“ (ADV_TDS.1) wird erwartet, dass der
Evaluator die TSF identifiziert hat, bevor er mit der Arbeit an dieser Unteraufgabe beginnt. Ohne genaue
Kenntnis dessen, was die TSF ausmacht, ist es nicht möglich, die Vollständigkeit der TSFI zu beurteilen.
Bei der Durchführung der verschiedenen Workunits dieser Familie wird der Evaluator aufgefordert, die
Genauigkeit und Vollständigkeit mehrerer Faktoren (der TSFI selbst sowie der einzelnen Komponenten
(Parameter, Aktionen, Fehlermeldungen usw.) der TSFI) zu beurteilen. Bei der Durchführung dieser Analyse
wird vom Evaluator erwartet, dass er die für die Evaluierung zur Verfügung gestellte Dokumentation
verwendet. Dies schließt die ST und das TOE-Design ein und kann andere Dokumentationen wie z. B. die
operativen Leitlinien für Benutzer, die Beschreibung der Sicherheitsarchitektur und die Darstellung der
Implementierung umfassen. Die Dokumentation sollte in einer iterativen Weise untersucht werden. Der
Evaluator kann z. B. im TOE-Design lesen, wie eine bestimmte Funktion implementiert ist, sieht aber keine
Möglichkeit, diese Funktion von der Schnittstelle aus aufzurufen. Dies könnte den Evaluator dazu veranlassen,
die Vollständigkeit einer bestimmten TSFI-Beschreibung in Frage zu stellen, oder anzuzweifeln, ob eine
Schnittstelle in der Funktionsspezifikation überhaupt berücksichtigt wurde. Die Beschreibung solcher
Analysetätigkeiten im ETR ist ein Schlüsselverfahren, um zu begründen, dass die Workunits angemessen
durchgeführt wurden.
Es sollte anerkannt werden, dass es funktionelle Anforderungen gibt, deren Funktionalität sich ganz oder
teilweise eher architektonisch als durch einen bestimmten Mechanismus manifestiert. Ein Beispiel dafür ist
die Implementierung von Mechanismen zur Umsetzung der Anforderungen an „Residual information
protection“ (FDP_RIP). Solche Mechanismen werden typischerweise implementiert, um sicherzustellen, dass
ein Verhalten nicht vorhanden ist, das schwer zu prüfen ist und typischerweise durch Analyse verifiziert wird.
In den Fällen, in denen solche funktionalen Anforderungen in die ST aufgenommen werden, wird erwartet,
dass der Evaluator erkennt, dass es möglicherweise SFRs dieser Art gibt, die keine Schnittstellen haben, und
dass dies nicht als Mangel in der Funktionsspezifikation angesehen werden sollte.
106
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
dargestellt ist.
voranschreitet.
angibt.
107
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss die Funktionsspezifikation untersuchen, um die Vollständigkeit der TSFI festzustellen.
Der Evaluator muss die Designunterlagen verwenden, um die möglichen Arten von Schnittstellen zu
identifizieren. Der Evaluator muss die Designunterlagen und die Leitliniendokumente nach potentiellen TSFIs
durchsuchen, die nicht in der Dokumentation des Entwicklers enthalten sind, und so darauf hinweisen, dass
die vom Entwickler definierte Menge TSFIs unvollständig ist. Der Evaluator muss die vom Entwickler
vorgebrachten Argumente, dass die TSFI vollständig ist, untersuchen, und bis zur niedrigsten Designebene
oder mit der Darstellung der Implementierung prüfen, dass keine zusätzlichen TSFIs existieren.
ISO/IEC 15408-3 ADV_FSP.4.4C: Die Funktionsspezifikation muss alle Aktionen beschreiben, die mit jeder TSFI
verknüpft sind.
108
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss die Darstellung der TSFI untersuchen, um festzustellen, dass sie alle Aktionen im
Zusammenhang mit jeder TSFI vollständig und genau beschreibt.
Der Evaluator prüft, ob alle Aktionen beschrieben sind. Über eine Schnittstelle verfügbare Aktionen
beschreiben, was die Schnittstelle tut (im Gegensatz zum TOE-Design, das beschreibt, wie die Aktionen von
der TSF bereitgestellt werden).
Aktionen einer Schnittstelle beschreiben die Funktionalität, die über die Schnittstelle aufgerufen werden kann
und als reguläre Aktionen und SFR-bezogene Aktionen eingeteilt werden kann. Regelmäßige Aktionen sind
Beschreibungen dessen, was die Schnittstelle tut. Der Umfang der für diese Beschreibung bereitgestellten
Informationen hängt von der Komplexität der Schnittstelle ab. Die SFR-bezogenen Aktionen sind diejenigen,
die an jeder externen Schnittstelle sichtbar sind (z. B. sollte die durch den Aufruf einer Schnittstelle
verursachte Auditaufgabe (vorausgesetzt, die Auditanforderungen sind in der ST enthalten) beschrieben
werden, auch wenn das Ergebnis dieser Aktion im Allgemeinen nicht durch die aufgerufene Schnittstelle
sichtbar ist). Abhängig von den Parametern einer Schnittstelle kann es viele verschiedene Aktionen geben, die
über die Schnittstelle aufgerufen werden können (z. B. kann der erste Parameter einer API ein „Unterbefehl“
sein, und die folgenden Parameter sind spezifisch für diesen Unterbefehl. Die IOCTL-API in einigen
Unix-Systemen ist ein Beispiel für eine solche Schnittstelle).
Um festzustellen, ob die Beschreibung der Aktionen einer TSFI vollständig ist, sollte der Evaluator die restliche
Schnittstellenbeschreibung (Parameterbeschreibungen, Fehlermeldungen usw.) überprüfen, um festzu-
stellen, ob die beschriebenen Aktionen berücksichtigt werden. Der Evaluator sollte auch andere für die
Evaluierung bereitgestellte Nachweise analysieren (z. B. TOE-Design, Beschreibung der Sicherheits-
architektur, operative Leitlinien für Benutzer, Darstellung der Implementierung), um festzustellen, ob es
Nachweise für Aktionen gibt, die dort, aber nicht in der Funktionsspezifikation beschrieben sind.
ISO/IEC 15408-3 ADV_FSP.4.5C: Die Funktionsspezifikation muss alle direkten Fehlermeldungen beschreiben,
die sich aus einem Aufruf jeder TSFI ergeben können.
Der Evaluator muss die Darstellung der TSFI untersuchen, um festzustellen, dass sie alle Fehlermeldungen,
die sich aus einem Aufruf jeder TSFI ergeben, vollständig und genau beschreibt.
Beschreibung der Aktionen einen Zugriff auf die Festplatte verursachen sollte, den Evaluator veranlassen,
untersuchen, um festzustellen, ob die Beschreibung vollständig und genau ist.
109
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator legt fest, dass für jede TSFI die genaue Menge Fehlermeldungen bestimmt werden kann, die
beim Aufruf dieser Schnittstelle zurückgegeben werden kann. Der Evaluator überprüft die für die Schnittstelle
zur Verfügung gestellten Nachweise, um festzustellen, ob die Menge Fehler vollständig zu sein scheint. Er
gleicht diese Informationen mit anderen für die Evaluierung zur Verfügung gestellten Nachweisen ab (z. B.
TOE-Design, Beschreibung der Sicherheitsarchitektur, operative Leitlinien für Benutzer, Darstellung der
Implementierung), um sicherzustellen, dass es keine aus der erwähnten Verarbeitung resultierenden Fehler
gibt, die nicht in der Funktionsspezifikation enthalten sind.
Der Evaluator muss die Darstellung der TSFI untersuchen, um festzustellen, dass sie die Bedeutung aller
Fehlermeldungen, die sich aus einem Aufruf jeder TSFI ergeben, vollständig und genau beschreibt.
Um die Genauigkeit zu bestimmen, muss der Evaluator in der Lage sein, die Bedeutung des Fehlers zu
verstehen. Wenn eine Schnittstelle beispielsweise einen numerischen Code von 0, 1 oder 2 zurückgibt, wäre
der Evaluator nicht in der Lage, den Fehler zu verstehen, wenn die Funktionsspezifikation nur Folgendes
auflisten würde: „mögliche Fehler, die aus dem Aufruf der foo()-Schnittstelle resultieren, sind 0, 1 oder 2“.
Stattdessen prüft der Evaluator, ob beispielsweise folgende Fehler beschrieben sind: „mögliche Fehler, die aus
dem Aufruf der foo()-Schnittstelle resultieren, sind 0 (Verarbeitung erfolgreich), 1 (Datei nicht gefunden)
oder 2 (falsche Angabe des Dateinamens)“.
Um festzustellen, ob die Beschreibung der Fehler aufgrund des Aufrufs einer TSFI vollständig ist, untersucht
der Evaluator die restliche Schnittstellenbeschreibung (Parameterbeschreibungen, Aktionen usw.), um
festzustellen, ob potentielle Fehlerbedingungen, die durch die Verwendung einer solchen Schnittstelle
verursacht werden könnten, berücksichtigt werden. Der Evaluator prüft auch andere für die Evaluierung
vorgelegte Nachweise (z. B. TOE-Design, Beschreibung der Sicherheitsarchitektur, operative Leitlinien für
Benutzer, Darstellung der Implementierung), um festzustellen, ob die Fehlerverarbeitung im Zusammenhang
mit der TSFI dort beschrieben ist, aber nicht in der Funktionsspezifikation.
10.4.4.4.10Workunit ADV_FSP.4-10
110
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
sein scheinen.
Zielsetzung dieser Unteraufgabe ist es festzustellen, ob der Entwickler alle TSFIs vollständig und genau
beschrieben hat, so dass der Evaluator feststellen kann, ob die TSFIs vollständig und genau beschrieben sind,
und ob er die funktionalen Sicherheitsanforderungen der ST zu implementieren scheint. Die Vollständigkeit
der Schnittstellen wird anhand der Darstellung der Implementierung beurteilt.
10.4.5.2 Eingaben
a) die ST,
c) das TOE-Design,
d) die Darstellung der Implementierung.
111
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
enthalten ist, ist
b) die Beschreibung der TSF-Interna,
c) das formelle Sicherheitspolitikmodell,
dargestellt ist.
voranschreitet.
ISO/IEC 15408-3 ADV_FSP.5.2C: Die Funktionsspezifikation muss die TSFI in einem semiformalen Stil
beschreiben.
Der Evaluator muss die Funktionsspezifikation untersuchen, um festzustellen, dass sie in einem
semiformalen Stil dargestellt wird.
Eine semiformale Darstellung zeichnet sich durch ein standardisiertes Format mit einer klar definierten
Syntax aus, die die Mehrdeutigkeit, die bei informellen Darstellungen auftreten kann, reduziert. Da die Absicht
des semiformalen Formats darin besteht, die Fähigkeit des Lesers zu verbessern, die Darstellung zu verstehen,
ist die Verwendung bestimmter strukturierter Darstellungsverfahren (Pseudocode, Flussdiagramme,
Blockdiagramme) angemessen, wenn auch nicht erforderlich.
Für die Zwecke dieser Aufgabe sollte der Evaluator sicherstellen, dass die Schnittstellenbeschreibungen in
strukturierter, konsistenter Weise formatiert sind und eine gemeinsame Terminologie verwenden. Eine
semiformale Darstellung der Schnittstellen impliziert auch, dass der Detaillierungsgrad der Darstellung für
die Schnittstellen über alle TSFIs weitgehend konsistent ist. Für die Funktionsspezifikation ist es akzeptabel,
auf externe Spezifikationen für Teile der Schnittstelle zu verweisen, solange diese externen Spezifikationen
selbst semiformal sind.
112
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
angibt.
Der Evaluator muss die Funktionsspezifikation untersuchen, um die Vollständigkeit der TSFI festzustellen.
Der Evaluator muss die Designunterlagen verwenden, um die möglichen Arten von Schnittstellen zu
identifizieren. Der Evaluator muss die Designunterlagen und die Leitliniendokumente nach potentiellen TSFIs
durchsuchen, die nicht in der Dokumentation des Entwicklers enthalten sind, und so darauf hinweisen, dass
die vom Entwickler definierte Menge TSFIs unvollständig ist. Der Evaluator muss die vom Entwickler
vorgebrachten Argumente, dass die TSFI vollständig ist, untersuchen, und bis zur niedrigsten Designebene
oder mit der Darstellung der Implementierung prüfen, dass keine zusätzlichen TSFIs existieren.
113
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Schnittstellenbeschreibung (Zweck, Verwendungsmethoden, Aktionen, Fehlermeldungen usw.) untersuchen,
ISO/IEC 15408-3 ADV_FSP.5.5C: Die Funktionsspezifikation muss alle Aktionen beschreiben, die mit jeder TFSI
verknüpft sind.
Der Evaluator muss die Darstellung der TSFI untersuchen, um festzustellen, dass sie alle Aktionen im
Zusammenhang mit jeder TSFI vollständig und genau beschreibt.
Der Evaluator prüft, ob alle Aktionen beschrieben sind. Über eine Schnittstelle verfügbare Aktionen
beschreiben, was die Schnittstelle tut (im Gegensatz zum TOE-Design, das beschreibt, wie die Aktionen von
der TSF bereitgestellt werden).
Aktionen einer Schnittstelle beschreiben die Funktionalität, die über die Schnittstelle aufgerufen werden kann
und als reguläre Aktionen und SFR-bezogene Aktionen eingeteilt werden kann. Regelmäßige Aktionen sind
Beschreibungen dessen, was die Schnittstelle tut. Der Umfang der für diese Beschreibung bereitgestellten
Informationen hängt von der Komplexität der Schnittstelle ab. Die SFR-bezogenen Aktionen sind diejenigen,
die an jeder externen Schnittstelle sichtbar sind (z. B. sollte die durch den Aufruf einer Schnittstelle
verursachte Auditaufgabe (vorausgesetzt, die Auditanforderungen sind in der ST enthalten) beschrieben
werden, auch wenn das Ergebnis dieser Aktion im Allgemeinen nicht durch die aufgerufene Schnittstelle
114
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
sichtbar ist). Abhängig von den Parametern einer Schnittstelle kann es viele verschiedene Aktionen geben, die
über die Schnittstelle aufgerufen werden können (z. B. kann der erste Parameter einer API ein „Unterbefehl“
sein, und die folgenden Parameter sind spezifisch für diesen Unterbefehl. Die IOCTL-API in einigen
Unix-Systemen ist ein Beispiel für eine solche Schnittstelle).
Um festzustellen, ob die Beschreibung der Aktionen einer TSFI vollständig ist, sollte der Evaluator die restliche
Schnittstellenbeschreibung (Parameterbeschreibungen, Fehlermeldungen usw.) überprüfen, um festzu-
stellen, ob die beschriebenen Aktionen berücksichtigt werden. Der Evaluator sollte auch andere für die
Evaluierung bereitgestellte Nachweise analysieren (z. B. TOE-Design, Beschreibung der Sicherheits-
architektur, operative Leitlinien für Benutzer, Darstellung der Implementierung), um festzustellen, ob es
Nachweise für Aktionen gibt, die dort, aber nicht in der Funktionsspezifikation beschrieben sind.
ISO/IEC 15408-3 ADV_FSP.5.6C: Die Funktionsspezifikation muss alle direkten Fehlermeldungen beschreiben,
die sich aus einem Aufruf jeder TSFI ergeben können.
Der Evaluator muss die Darstellung der TSFI untersuchen, um festzustellen, dass sie alle Fehlermeldungen,
die sich aus einem Aufruf jeder TSFI ergeben, vollständig und genau beschreibt.
Beschreibung der Aktionen einen Zugriff auf die Festplatte verursachen sollte, den Evaluator veranlassen,
andere Nachweise (ADV_ARC, ADV_TDS) in Bezug auf diese TSFI zu untersuchen, um festzustellen, ob die
Beschreibung vollständig und genau ist.
Der Evaluator legt fest, dass für jede TSFI die genaue Menge Fehlermeldungen bestimmt werden kann, die
beim Aufruf dieser Schnittstelle zurückgegeben werden kann. Der Evaluator überprüft die für die Schnittstelle
zur Verfügung gestellten Nachweise, um festzustellen, ob die Menge Fehler vollständig zu sein scheint. Er
gleicht diese Informationen mit anderen für die Evaluierung zur Verfügung gestellten Nachweisen ab (z. B.
TOE-Design, Beschreibung der Sicherheitsarchitektur, operative Leitlinien für Benutzer, Darstellung der
Implementierung), um sicherzustellen, dass es keine aus der erwähnten Verarbeitung resultierenden Fehler
gibt, die nicht in der Funktionsspezifikation enthalten sind.
115
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss die Darstellung der TSFI untersuchen, um festzustellen, dass sie die Bedeutung aller
Fehlermeldungen, die sich aus einem Aufruf jeder TSFI ergeben, vollständig und genau beschreibt.
Um die Genauigkeit zu bestimmen, muss der Evaluator in der Lage sein, die Bedeutung des Fehlers zu
verstehen. Wenn eine Schnittstelle beispielsweise einen numerischen Code von 0, 1 oder 2 zurückgibt, wäre
der Evaluator nicht in der Lage, den Fehler zu verstehen, wenn die Funktionsspezifikation nur Folgendes
auflisten würde: „mögliche Fehler, die aus dem Aufruf der foo()-Schnittstelle resultieren, sind 0, 1 oder 2“.
Stattdessen prüft der Evaluator, ob beispielsweise folgende Fehler beschrieben sind: „mögliche Fehler, die aus
dem Aufruf der foo()-Schnittstelle resultieren, sind 0 (Verarbeitung erfolgreich), 1 (Datei nicht gefunden) oder
2 (falsche Angabe des Dateinamens)“.
Um festzustellen, ob die Beschreibung der Fehler aufgrund des Aufrufs einer TSFI vollständig ist, untersucht
der Evaluator die restliche Schnittstellenbeschreibung (Parameterbeschreibungen, Aktionen usw.), um
festzustellen, ob potentielle Fehlerbedingungen, die durch die Verwendung einer solchen Schnittstelle
verursacht werden könnten, berücksichtigt werden. Der Evaluator prüft auch andere für die Evaluierung
vorgelegte Nachweise (z. B. TOE-Design, Beschreibung der Sicherheitsarchitektur, operative Leitlinien für
Benutzer, Darstellung der Implementierung), um festzustellen, ob die Fehlerverarbeitung im Zusammenhang
mit der TSFI dort beschrieben ist, aber nicht in der Funktionsspezifikation.
ISO/IEC 15408-3 ADV_FSP.5.7C: Die Funktionsspezifikation muss alle Fehlermeldungen beschreiben, die sich
nicht aus einem Aufruf einer TSFI ergeben.
Der Evaluator muss die Funktionsspezifikation untersuchen, um festzustellen, dass sie alle Fehlermeldungen,
die nicht aus einem Aufruf einer TSFI hervorgehen, vollständig und genau beschreibt.
Diese Workunit ergänzt Workunit ADV_FSP.5-9, die jene Fehlermeldungen beschreibt, die aus einem Aufruf
der TSFI hervorgehen. Zusammengenommen decken diese Workunits alle Fehlermeldungen ab, die durch die
TSF erzeugt werden könnten.
Der Evaluator bewertet die Vollständigkeit und Genauigkeit der Funktionsspezifikation, indem er deren Inhalt
mit Fällen der Fehlermeldungsgenerierung innerhalb der Darstellung der Implementierung vergleicht. Die
meisten dieser Fehlermeldungen werden bereits von Workunit ADV_FSP.5-9 behandelt worden sein.
Die Fehlermeldungen, die sich auf diese Workunit beziehen, sind typischerweise solche, die nicht erwartet
werden, aber aufgrund guter Programmierpraktiken bestehen. Beispielsweise kann eine Fallbeschreibung, in
der die aus einer Liste von Fällen resultierenden Aktionen definiert werden, mit einer abschließenden
else-Anweisung enden, die auf alles anwendbar ist, was nicht erwartet werden kann; diese Praxis stellt sicher,
dass die TSF nicht in einen undefinierten Zustand gerät. Es ist jedoch nicht zu erwarten, dass der
Ausführungspfad jemals zu dieser else-Anweisung gelangen würde; daher würde eine Fehlermeldung
innerhalb dieser else-Anweisung niemals generiert werden. Obwohl sie nicht generiert würde, muss sie
dennoch in die Funktionsspezifikation aufgenommen werden.
ISO/IEC 15408-3 ADV_FSP.5.8C: Die Funktionsspezifikation muss eine Begründung für jede in der
TSF-Implementierung enthaltene Fehlermeldung bereitstellen, die sich nicht aus einem Aufruf einer TSFI ergibt.
Der Evaluator muss die Funktionsspezifikation untersuchen, um festzustellen, dass er eine Begründung für
jede Fehlermeldung liefert, die in der TSF-Implementierung enthalten ist, aber nicht aus dem Aufruf einer TSFI
hervorgeht.
Der Evaluator stellt sicher, dass jede Fehlermeldung, die unter Workunit ADV_FSP.5-11 gefunden wird, eine
Begründung enthält, die beschreibt, warum sie nicht von der TSFI aus aufgerufen werden kann.
116
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Wie in der vorhergehenden Workunit beschrieben, könnte diese Begründung so einfach sein wie die Tatsache,
dass die fragliche Fehlermeldung der Vollständigkeit der Ausführungslogik dient und nie erwartet wird, dass
sie erzeugt wird. Der Evaluator stellt sicher, dass die Begründung für jede dieser Fehlermeldungen logisch ist.
manifestieren (z. B. FDP_RIP), nicht erwartet wird, dass sie diese Anforderungen vollständig auf das TSFI
abbilden. Die Analyse für diese Anforderungen wird in der Analyse für das TOE-Design (ADV_TDS)
sein scheinen.
117
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Es gibt keine allgemeine Anleitung; das Schema sollte für diese Unteraufgabe konsultiert werden.
10.5 Darstellung der Implementierung (ADV_IMP)
10.5.1 Evaluierung der Unteraufgabe (ADV_IMP.1)
Die Zielsetzung dieser Unteraufgabe ist es, festzustellen, ob die vom Entwickler zur Verfügung gestellte
Darstellung der Implementierung für die Verwendung in anderen Analysetätigkeiten geeignet ist; die Eignung
wird anhand ihrer Übereinstimmung mit den Anforderungen für diese Komponente beurteilt.
10.5.1.2 Eingaben
a) die Darstellung der Implementierung,
b) die Dokumentation der Entwicklungstools, wie sie sich aus ALC_TAT ergibt,
c) die Beschreibung des TOEs-Designs.
Die gesamte Darstellung der Implementierung wird zur Verfügung gestellt, um sicherzustellen, dass die
Analysetätigkeiten nicht aufgrund mangelnder Informationen eingeschränkt werden. Dies bedeutet jedoch
nicht, dass die gesamte Darstellung bei der Durchführung der Analysetätigkeiten untersucht wird. Dies ist
wahrscheinlich in fast allen Fällen nicht praktikabel, abgesehen von der Tatsache, dass es höchst-
wahrscheinlich nicht zu einer höheren Vertrauenswürdigkeit des TOEs im Vergleich zu einer gezielten
Probenahme der Darstellung der Implementierung führen wird. Für diese Unteraufgabe gilt dies noch mehr.
Es wäre für den Evaluator nicht produktiv, viel Zeit damit zu verbringen, die Anforderungen für einen Teil der
Darstellung der Implementierung zu überprüfen und dann einen anderen Teil der Darstellung der
Implementierung bei der Durchführung von Analysen für andere Workunits zu verwenden. Daher wird dem
Evaluator empfohlen, die Stichprobe der Darstellung der Implementierung aus den Bereichen des TOEs
auszuwählen, die bei der während der Workunits aus anderen Familien (z. B. ATE_IND, AVA_VAN und
ADV_INT) durchgeführten Analyse von größtem Interesse sind.
10.5.1.4 Aktion ADV_IMP.1.1E
ISO/IEC 15408-3 ADV_IMP.1.1C: Die Darstellung der Implementierung muss die TSF in einem Detaillierungs-
grad definieren, der so hoch ist, dass die TSF ohne weitere Designentscheidungen generiert werden kann.
10.5.1.4.1 Workunit ADV_IMP.1-1
Der Evaluator muss prüfen, ob die Darstellung der Implementierung die TSF in einem Detaillierungsgrad
definiert, der so hoch ist, dass die TSF ohne weitere Designentscheidungen generiert werden kann.
118
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Quellcode oder Hardware-Diagramme und/oder IC-Hardware-Design-Sprachcode bzw. Layout-Daten, die

zum Aufbau der eigentlichen Hardware verwendet werden, sind Beispiele für Teile einer Darstellung der
Implementierung. Der Evaluator nimmt eine Stichprobe der Darstellung der Implementierung, um Vertrauen
zu gewinnen, dass sie sich auf der geeigneten Ebene befindet und nicht etwa auf einer Pseudocode-Ebene, die
zusätzliche Designentscheidungen erfordert. Der Evaluator wird ermutigt, beim ersten Blick auf die
Darstellung der Implementierung eine schnelle Überprüfung durchzuführen, um sich zu vergewissern, dass
der Entwickler auf dem richtigen Weg ist. Der Evaluator wird jedoch auch dazu ermutigt, den Großteil dieser
Prüfung während der Arbeit an anderen Workunits durchzuführen, die eine Untersuchung der Implemen-
tierung erfordern; dadurch wird sichergestellt, dass die für diese Workunit untersuchte Stichprobe relevant
ist.
ISO/IEC 15408-3 ADV_IMP.1.2C: Die Darstellung der Implementierung muss in der Form bereitgestellt werden,
in der das Entwicklungspersonal sie verwendet.
Der Evaluator muss prüfen, ob die Darstellung der Implementierung in der vom Entwicklungspersonal
verwendeten Form vorliegt.
Die Darstellung der Implementierung wird vom Entwickler in einer Form manipuliert, die für die
Transformation in die eigentliche Implementierung geeignet ist. Zum Beispiel kann der Entwickler mit Dateien
arbeiten, die den Quellcode enthalten, der schließlich kompiliert wird, um Teil der TSF zu werden. Der
Entwickler stellt die Darstellung der Implementierung in der von ihm verwendeten Form zur Verfügung, so
dass der Evaluator bei der Analyse automatisierte Techniken verwenden kann. Dies erhöht auch die
Zuversicht, dass die geprüfte Darstellung der Implementierung tatsächlich diejenige ist, die bei der Erstellung
der TSF verwendet wird (im Gegensatz zu dem Fall, dass sie in einem alternativen Darstellungsformat, z. B.
einem Textverarbeitungsdokument, geliefert wird). Es sollte beachtet werden, dass der Entwickler auch
andere Formen der Darstellung der Implementierung verwenden kann; diese Formen werden ebenfalls
mitgeliefert. Das übergreifende Ziel ist es, den Evaluator mit den Informationen zu versorgen, die die
Analysebemühungen des Evaluators maximieren.
Der Evaluator nimmt eine Stichprobe der Darstellung der Implementierung, um Vertrauen zu gewinnen, dass
es sich um die für den Entwickler benutzbare Version handelt. Die Stichprobe ist so beschaffen, dass der
Evaluator die Gewissheit hat, dass alle Bereiche der Darstellung der Implementierung den Anforderungen
entsprechen; eine vollständige Untersuchung der gesamten Darstellung der Implementierung ist jedoch nicht
erforderlich.
Konventionen in einigen Formen der Darstellung der Implementierung können es schwierig oder unmöglich
machen, allein aus der Darstellung der Implementierung selbst zu bestimmen, was das tatsächliche Ergebnis
der Zusammenstellung oder der Interpretation zur Laufzeit sein wird. Beispielsweise führen Compilerbefehle
für Compiler in der C-Sprache dazu, dass der Compiler ganze Teile des Codes ausschließt oder einschließt.
Einige Formen der Darstellung der Implementierung können zusätzliche Informationen erfordern, da sie
erhebliche Hindernisse für das Verständnis und die Analyse darstellen. Beispiele hierfür sind verschleierte
Quelltexte oder Quelltexte, die auf andere Weise entstellt wurden, so dass sie das Verständnis und/oder die
Analyse verhindern. Diese Formen der Darstellung der Implementierung ergeben sich typischerweise daraus,
dass eine Version der Darstellung der Implementierung genommen wird, die vom TOE-Entwickler verwendet
wird, und darauf ein Verschleierungs- oder Entstellungsprogramm ausgeführt wird. Während die
verschleierte Darstellung das ist, was kompiliert wird und möglicherweise näher an der Implementierung (in
Bezug auf die Struktur) liegt als die ursprüngliche, unverschleierte Darstellung, kann die Bereitstellung eines
solchen entstellten Codes dazu führen, dass erheblich mehr Zeit für Analyseaufgaben, die die Darstellung
betreffen, aufgewendet werden muss. Wenn solche Darstellungsformen erstellt werden, benötigen die
Komponenten Details zu den verwendeten Verschleierungstools/-algorithmen, damit die unverschleierte
Darstellung geliefert werden kann, und die zusätzlichen Informationen können dazu verwendet werden, um
das Vertrauen zu gewinnen, dass der Verschleierungsprozess keine Sicherheitsmechanismen gefährdet.
119
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator nimmt eine Stichprobe der Darstellung der Implementierung, um Vertrauen zu gewinnen, dass
alle zur Interpretation der Darstellung der Implementierung erforderlichen Informationen geliefert wurden.
Es ist zu beachten, dass die Tools zu denjenigen gehören, auf die die Komponenten „Tools and techniques“
(ALC_TAT) verweisen. Der Evaluator wird ermutigt, beim ersten Blick auf die Darstellung der
Implementierung eine schnelle Überprüfung durchzuführen, um sich zu vergewissern, dass der Entwickler auf
dem richtigen Weg ist. Der Evaluator wird jedoch auch dazu ermutigt, den Großteil dieser Prüfung während
der Arbeit an anderen Workunits durchzuführen, die eine Untersuchung der Umsetzung erfordern; dadurch
wird sichergestellt, dass die für diese Workunit untersuchte Stichprobe relevant ist.
ISO/IEC 15408-3 ADV_IMP.1.3C: Die Zuordnung zwischen der TOE-Designbeschreibung und der Stichprobe der
Darstellung der Implementierung muss deren Übereinstimmung nachweisen.
Der Evaluator muss die Zuordnung zwischen der TOE-Designbeschreibung und der Stichprobe der
Darstellung der Implementierung untersuchen, um festzustellen, ob sie korrekt ist.
Der Evaluator erweitert die Bestimmung der Existenz (angegeben in Workunit ADV_IMP.1-1), indem er die
Genauigkeit eines Teils der Darstellung der Implementierung und der TOE-Designbeschreibung verifiziert. Bei
interessanten Teilen der TOE-Designbeschreibung würde der Evaluator überprüfen, ob die Darstellung der
Implementierung die in der TOE-Designbeschreibung enthaltene Beschreibung genau wiedergibt.
Die TOE-Designbeschreibung könnte z. B. ein Login-Modul identifizieren, das zur Identifizierung und
Authentifizierung von Benutzern verwendet wird. Wenn die Benutzerauthentifizierung ausreichend
signifikant ist, würde der Evaluator überprüfen, ob der entsprechende Code diesen Dienst tatsächlich so
implementiert, wie in der TOE-Designbeschreibung beschrieben. Es könnte sich auch lohnen, zu überprüfen,
ob der Code die in der Funktionsspezifikation beschriebenen Parameter akzeptiert.
Es sei darauf hingewiesen, dass der Entwickler wählen muss, ob er die Zuordnung für die gesamte Darstellung
der Implementierung durchführt und damit garantiert, dass die gewählte Stichprobe abgedeckt wird, oder ob
er vor der Durchführung der Zuordnung auf die Auswahl der Stichprobe wartet. Die erste Option ist
wahrscheinlich mehr Arbeit, kann aber vor Beginn der Evaluierung abgeschlossen werden. Die zweite Option
ist weniger Arbeit, führt aber zu einer Aussetzung der Evaluierungsaufgabe, während die erforderlichen
Nachweise erbracht werden.
10.5.2 Evaluierung der Unteraufgabe (ADV_IMP.2)
10.6 TSF-Interna (ADV_INT)
10.6.1 Evaluierung der Unteraufgabe (ADV_INT.1)
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob die definierte Teilmenge der TSF so
gestaltet und strukturiert ist, dass die Wahrscheinlichkeit von Mängeln reduziert wird und die Wartung
leichter ohne die Einschleppung von Mängeln durchgeführt werden kann.
10.6.1.2 Eingaben
a) die ST,
b) die Beschreibung des TOEs-Designs,
120
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
c) die Darstellung der Implementierung (wenn ADV_IMP Teil der beanspruchten Vertrauenswürdigkeit ist),
d) die Beschreibung der TSF-Interna und Begründung,
e) die Dokumentation der Codierungsstandards, wie sie sich aus ALC_TAT ergibt.
Die Rolle der Beschreibung der Interna besteht darin, die Struktur des Designs und der Implementierung der
TSF zu belegen.
Die Struktur des Designs hat zwei Aspekte: die Bestandteile der TSF und die Verfahren, die zur Gestaltung der
TSF verwendet werden. In Fällen, in denen die TSF in einer Weise gestaltet ist, die gegenüber dem durch das
TOE-Design dargestellten Design konsistent ist (siehe ADV_TDS), ist die Beurteilung des TSF-Designs
offensichtlich. In Fällen, in denen die Designverfahren (siehe ALC_TAT) befolgt werden, ist die Beurteilung der
TSF-Designverfahren ähnlich offensichtlich.
In Fällen, in denen die TSF mit verfahrensbasierter Software implementiert wird, wird diese Struktur auf der
Grundlage ihrer Modularität beurteilt; die in der Beschreibung der Interna identifizierten Module sind die
gleichen wie die im „TOE design“ (ADV_TDS) identifizierten Module. Ein Modul besteht aus einer oder
mehreren Quellcodedateien, die nicht in kleinere kompilierbare Einheiten zerlegt werden können.
Die Verwendung der Zuordnung in dieser Komponente erlegt der Teilmenge der TSF, die in der Zuordnung
ADV_INT.1.1D explizit angegeben ist, strengere Beschränkungen auf als dem Rest der TSF. Während die
gesamte TSF nach den Regeln der Technik entworfen werden und zu einer gut strukturierten TSF führen soll,
wird nur die festgelegte Teilmenge speziell auf dieses Merkmal hin analysiert. Der Evaluator stellt fest, dass
die Anwendung von Codierungsstandards durch den Entwickler zu einer verständlichen TSF führt.
Das Hauptziel dieser Komponente ist es, sicherzustellen, dass die Darstellung der Implementierung der
TSF-Teilmenge verständlich ist, um die Wartung und Analyse (sowohl des Entwicklers als auch des
Evaluators) zu erleichtern.
10.6.1.4 Aktion ADV_INT.1.1E
ISO/IEC 15408-3 ADV_INT.1.1C: Die Begründung muss die Merkmale erläutern, die zur Beurteilung der
Bedeutung von „gut strukturiert“ herangezogen werden.
10.6.1.4.1 Workunit ADV_INT.1-1
Der Evaluator muss die Begründung untersuchen, um festzustellen, dass sie die Grundlage für die
Feststellung bildet, ob die TSF gut strukturiert ist.
Der Evaluator überprüft, ob die Kriterien für die Bestimmung des Merkmals „gut strukturiert“ in der
Begründung klar definiert sind. Akzeptable Kriterien stammen in der Regel aus Industriestandards für die
technologische Disziplin. Beispielsweise wird prozedurale Software, die linear ausgeführt wird, traditionell
als gut strukturiert angesehen, wenn sie den Praktiken der Software-Engineering-Programmierung
entspricht, wie sie in der IEEE-Norm (IEEE Std 610.12-1990) definiert sind. Zum Beispiel würde sie die
Kriterien für die prozeduralen Softwareteile der TSF-Teilmenge identifizieren:
a) das für die modulare Zerlegung verwendete Verfahren;
b) die bei der Entwicklung der Implementierung angewandten Codierungsstandards;
c) eine Beschreibung der maximal akzeptablen Ebene der intermodularen Kopplung, die die TSF-Teilmenge
aufweist;
d) eine Beschreibung der minimal akzeptablen Ebene der Kohäsion, die die Module der TSF-Teilmenge
aufweisen.
121
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Bei anderen Arten von Technologien, die im TOE verwendet werden – wie z. B. nicht-prozedurale Software
(z. B. objektorientierte Programmierung), weit verbreitete Standard-Hardware (z. B. PC-Mikroprozessoren)
und Spezial-Hardware (z. B. Smartcard-Prozessoren) – sollte der Evaluator die Evaluierungsinstanz um
Anleitung bitten, um die Angemessenheit der Kriterien für eine „gute Strukturierung“ zu bestimmen.
ISO/IEC 15408-3 ADV_INT.1.2C: Die Beschreibung der TSF-Interna muss nachweisen, dass die zugeordnete
Teilmenge der TSF gut strukturiert ist.
Der Evaluator muss die Beschreibung der TSF-Interna prüfen, um festzustellen, dass sie die zugewiesene
Teilmenge der TSF identifiziert.
Diese Teilmenge kann in Bezug auf die Interna der TSF auf jeder beliebigen Abstraktionsebene identifiziert
werden. Dies kann z. B. in Bezug auf die Strukturelemente der TSF, wie sie im TOE-Design identifiziert wurden
(z. B. das Audit-Teilsystem), oder in Bezug auf die Implementierung (z. B. die Dateien encrypt.c und decrypt.c
oder der IC-Chip 6227) erfolgen.
Es reicht nicht aus, diese Teilmenge in Bezug auf die beanspruchten SFRs (z. B. den Teil der TSF, der
Anonymität nach der Definition in FPR_ANO.2 bietet) zu identifizieren, da dies nicht angibt, worauf sich die
Analyse konzentrieren soll.
Der Evaluator muss die Beschreibung der TSF-Interna untersuchen, um festzustellen, dass sie nachweist, dass
die zugewiesene TSF-Teilmenge gut strukturiert ist.
Der Evaluator untersucht die Beschreibung der Interna, um sicherzustellen, dass sie eine fundierte
Begründung darüber liefert, wie die TSF-Teilmenge die Kriterien aus ADV_INT.1-1 erfüllt.
Es würde zum Beispiel erklären, wie die prozeduralen Softwareteile der TSF-Teilmenge den folgenden
Anforderungen entsprechen:
a) dass es eine Eins-zu-Eins-Entsprechung zwischen den in der TSF-Teilmenge identifizierten Modulen und
den im TOE-Design (ADV_TDS) beschriebenen Modulen gibt;
b) wie das TSF-Design ein Spiegelbild des modularen Zersetzungsprozesses ist;
c) eine Begründung für alle Fälle, in denen die Codierungsstandards nicht verwendet oder nicht eingehalten
wurden;
d) eine Begründung für jegliche Kopplung oder Kohäsion außerhalb der akzeptablen Grenzen.
Der Evaluator muss feststellen, dass das TOE-Design für die zugeordnete TSF-Untermenge gut strukturiert
ist.
Der Evaluator untersucht eine Stichprobe des TOEs-Designs, um die Genauigkeit der Begründung zu
überprüfen. Zum Beispiel wird eine Stichprobe des TOEs-Designs analysiert, um seine Übereinstimmung mit
den Gestaltungsnormen zu bestimmen, usw. Wie bei allen Bereichen, in denen der Evaluator Aufgaben an
einer Teilmenge durchführt, gibt der Evaluator eine Begründung für die Größe und den Umfang der
Stichprobe.
Die Beschreibung der Zerlegung des TOEs in Teilsysteme und Module wird das Argument liefern, dass die
TSF-Teilmenge gut strukturiert ist und sich von selbst versteht. Die Überprüfung, ob die Verfahren zur
Strukturierung der TSF (wie in ALC_TAT untersucht) befolgt werden, macht es selbstverständlich, dass die
TSF-Teilmenge gut strukturiert ist.
122
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss feststellen, dass die zugeordnete TSF-Teilmenge gut strukturiert ist.
Wenn ADV_IMP nicht Teil der beanspruchten Vertrauenswürdigkeit ist, dann ist diese Workunit nicht
anwendbar und gilt daher als erfüllt.
Der Evaluator untersucht eine Stichprobe der TSF-Teilmenge, um die Genauigkeit der Beschreibung der
Interna zu überprüfen. Zum Beispiel wird eine Stichprobe der prozeduralen Softwareteile der TSF-Teilmenge
analysiert, um ihre Kohäsion und ihre Kopplung, ihre Einhaltung der Codierungsnormen usw. zu bestimmen.
Wie bei allen Bereichen, in denen der Evaluator Aufgaben an einer Teilmenge durchführt, liefert der Evaluator
eine Begründung für die Größe und den Umfang der Stichprobe.
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob die TSF so gestaltet und strukturiert ist,
dass die Wahrscheinlichkeit von Mängeln reduziert wird und die Wartung leichter ohne die Einschleppung
von Mängeln durchgeführt werden kann.
10.6.2.2 Eingaben
a) die Beschreibung des modularen Designs,
b) die Darstellung der Implementierung (wenn ADV_IMP Teil der beanspruchten Vertrauenswürdigkeit ist),
d) die Dokumentation der Codierungsstandards, wie sie sich aus ALC_TAT ergibt.
Die Rolle der Beschreibung der Interna besteht darin, die Struktur des Designs und der Implementierung der
TSF zu belegen.
Die Struktur des Designs hat zwei Aspekte: die Bestandteile der TSF und die Verfahren, die zur Gestaltung der
TSF verwendet werden. In Fällen, in denen die TSF in einer Weise gestaltet ist, die gegenüber dem durch das
TOE-Design dargestellten Design konsistent ist (siehe ADV_TDS), ist die Beurteilung des TSF-Designs
offensichtlich. In Fällen, in denen die Designverfahren (siehe ALC_TAT) befolgt werden, ist die Beurteilung der
TSF-Designverfahren ähnlich offensichtlich.
In Fällen, in denen die TSF mit verfahrensbasierter Software implementiert wird, wird diese Struktur auf der
Grundlage ihrer Modularität beurteilt; die in der Beschreibung der Interna identifizierten Module sind die
gleichen wie die im „TOE design“ (ADV_TDS) identifizierten Module. Ein Modul besteht aus einer oder
mehreren Quellcodedateien, die nicht in kleinere kompilierbare Einheiten zerlegt werden können.
Das Hauptziel dieser Komponente ist es, sicherzustellen, dass die Darstellung der TSF-Implementierung
verständlich ist, um die Wartung und Analyse (sowohl für den Entwickler als auch für den Evaluator) zu
erleichtern.
ISO/IEC 15408-3 ADV_INT.2.1C: Die Begründung muss die Merkmale beschreiben, die zur Beurteilung der
Bedeutung von „gut strukturiert“ herangezogen werden.
123
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss die Begründung untersuchen, um festzustellen, dass sie die Grundlage für die
Feststellung bildet, ob die TSF gut strukturiert ist.
Der Evaluator überprüft, ob die Kriterien für die Bestimmung des Merkmals „gut strukturiert“ in der
Begründung klar definiert sind. Akzeptable Kriterien stammen in der Regel aus Industriestandards für die
technologische Disziplin. Beispielsweise wird prozedurale Software, die linear ausgeführt wird, traditionell
als gut strukturiert angesehen, wenn sie den Praktiken der Software-Engineering-Programmierung
entspricht, wie sie in der IEEE-Norm (IEEE Std 610.12-1990) definiert sind. Zum Beispiel würde sie die
Kriterien für die prozeduralen Softwareteile der TSF identifizieren:
a) das für die modulare Zerlegung verwendete Verfahren;
b) die bei der Entwicklung der Implementierung angewandten Codierungsstandards;
c) eine Beschreibung der maximal akzeptablen Ebene der intermodularen Kopplung, die die TSF aufweist;
d) eine Beschreibung der minimal akzeptablen Ebene der Kohäsion, die die Module der TSF aufweisen.
Bei anderen Arten von Technologien, die im TOE verwendet werden – wie z. B. nicht-prozedurale Software
(z. B. objektorientierte Programmierung), weit verbreitete Standard-Hardware (z. B. PC-Mikroprozessoren)
und Spezial-Hardware (z. B. Smartcard-Prozessoren) – sollte die Evaluierungsinstanz konsultiert werden, um
die Angemessenheit der Kriterien für eine „gute Strukturierung“ zu bestimmen.
ISO/IEC 15408-3 ADV_INT.2.2C: Die Beschreibung der TSF-Interna muss nachweisen, dass die gesamte TSF gut
strukturiert ist.
Der Evaluator muss die Beschreibung der TSF-Interna untersuchen, um festzustellen, dass sie nachweist, dass
die TSF gut strukturiert ist.
Der Evaluator untersucht die Beschreibung der Interna, um sicherzustellen, dass sie eine fundierte
Begründung darüber liefert, wie die TSF die Kriterien aus ADV_INT.2-1 erfüllt.
Es würde zum Beispiel erklären, wie die prozeduralen Softwareteile der TSF Folgendes erfüllen:
a) dass es eine Eins-zu-Eins-Entsprechung zwischen den in der TSF identifizierten Modulen und den im
TOE-Design (ADV_TDS) beschriebenen Modulen gibt;
b) wie das TSF-Design ein Spiegelbild des modularen Zersetzungsprozesses ist;
c) eine Begründung für alle Fälle, in denen die Codierungsstandards nicht verwendet oder nicht eingehalten
wurden;
d) eine Begründung für jegliche Kopplung oder Kohäsion außerhalb der akzeptablen Grenzen.
Der Evaluator muss feststellen, dass das TOE-Design gut strukturiert ist.
Der Evaluator untersucht das TOE-Design einer Stichprobe der TSF, um die Genauigkeit der Begründung zu
überprüfen. Zum Beispiel wird eine Stichprobe des TOEs-Designs analysiert, um seine Übereinstimmung mit
den Gestaltungsnormen zu bestimmen, usw. Wie bei allen Bereichen, in denen der Evaluator Aufgaben an
einer Teilmenge durchführt, gibt der Evaluator eine Begründung für die Größe und den Umfang der
Stichprobe.
124
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Die Beschreibung der Zerlegung des TOEs in Teilsysteme und Module wird das Argument liefern, dass die
TSF-Teilmenge gut strukturiert ist und sich von selbst versteht. Die Überprüfung, ob die Verfahren zur
Strukturierung der TSF (wie in ALC_TAT untersucht) befolgt werden, macht es selbstverständlich, dass die
TSF-Teilmenge gut strukturiert ist.
Der Evaluator muss feststellen, dass die TSF gut strukturiert ist.
Wenn ADV_IMP nicht Teil der beanspruchten Vertrauenswürdigkeit ist, dann ist diese Workunit nicht
anwendbar und gilt daher als erfüllt.
Der Evaluator untersucht eine Stichprobe der TSF, um die Genauigkeit der Beschreibung der Interna zu
überprüfen. Zum Beispiel wird eine Stichprobe der prozeduralen Softwareteile der TSF analysiert, um ihre
Kohäsion und ihre Kopplung, ihre Einhaltung der Codierungsnormen usw. zu bestimmen. Wie bei allen
Bereichen, in denen der Evaluator Aufgaben an einer Teilmenge durchführt, liefert der Evaluator eine
Begründung für die Größe und den Umfang der Stichprobe.
10.7 Modellierung der Sicherheitspolitik (ADV_SPM)
10.7.1 Evaluierung der Unteraufgabe (ADV_SPM.1)
10.8 TOE-Design (ADV_TDS)
10.8.1 Evaluierung der Unteraufgabe (ADV_TDS.1)
10.8.1.1 Eingaben
a) die ST,
c) die Beschreibung der Sicherheitsarchitektur,
d) das TOE-Design.
10.8.1.2 Aktion ADV_TDS.1.1E
ISO/IEC 15408-3 ADV_TDS.1.1C: Das Design muss die Struktur des TOEs in Form von Teilsystemen beschreiben.
10.8.1.2.1 Workunit ADV_TDS.1-1
Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass die Struktur des gesamten TOE in
Form von Teilsystemen beschrieben wird.
Der Evaluator stellt sicher, dass alle Teilsysteme des TOEs identifiziert werden. Diese Beschreibung des TOEs
wird als Eingabe für Workunit ADV_TDS.1-2 verwendet, in der die Teile des TOEs identifiziert werden, aus
denen die TSF besteht. Das heißt, diese Anforderung gilt eher für den gesamten TOE als nur für die TSF.
125
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der TOE (und die TSF) kann (können) in mehreren Abstraktionsschichten (d. h. Teilsystemen und Modulen)
beschrieben werden. Je nach Komplexität des TOEss kann dessen Design in Form von Teilsystemen und
Modulen beschrieben werden, wie in ISO/IEC 15408-3, A.4, ADV_TDS: Teilsysteme und Module, beschrieben.
Auf dieser Vertrauenswürdigkeitsstufe muss die Zerlegung nur auf der Ebene des „Teilsystems“ erfolgen.
Bei der Durchführung dieser Aufgabe untersucht der Evaluator andere für den TOE vorgelegte Nachweise
(z. B. ST, operative Leitlinien für Benutzer), um festzustellen, ob die Beschreibung des TOEs in diesen
Nachweisen gegenüber der im TOE-Design enthaltenen Beschreibung konsistent ist.
ISO/IEC 15408-3 ADV_TDS.1.2C: Das Design muss alle Teilsysteme der TSF identifizieren.
Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass alle Teilsysteme der TSF identifiziert
werden.
In Workunit ADV_TDS.1-1 wurden alle Teilsysteme des TOEs identifiziert, und es wurde festgestellt, dass die
Nicht-TSF-Teilsysteme korrekt charakterisiert wurden. Auf dieser Arbeit aufbauend, sollten die Teilsysteme,
die nicht als Nicht-TSF-Teilsysteme charakterisiert wurden, genau identifiziert werden. Der Evaluator stellt
fest, dass von der nach den Leitlinien „Preparative procedures“ (AGD_PRE) installierten und konfigurierten
Hardware und Software jedes Teilsystem entweder als Teil der TSF oder nicht als solches erfasst worden ist.
ISO/IEC 15408-3 ADV_TDS.1.3C: Das Design muss das Verhalten jedes SFR-unterstützenden oder
SFR-nicht-störenden TSF-Teilsystems ausreichend detailliert beschreiben, um festzustellen, dass es nicht
SFR-durchsetzend ist.
Der Evaluator muss das TOE-Design untersuchen, um festzustellen, ob jedes SFR-unterstützende oder
SFR-nicht-störende Teilsystem der TSF so beschrieben ist, dass der Evaluator feststellen kann, dass das
Teilsystem SFR-unterstützend oder SFR-nicht-störend ist.
SFR-unterstützende und SFR-nicht-störende Teilsysteme und ihre Funktionen im System brauchen nicht im
Detail beschrieben zu werden. Der Evaluator stellt jedoch auf der Grundlage der vom Entwickler vorgelegten
Nachweise fest, dass die Teilsysteme, die keine allgemeinen Beschreibungen haben, SFR-unterstützend oder
SFR-nicht-störend sind. Es ist zu beachten, dass diese Workunit weitgehend erfüllt sein wird, wenn der
Entwickler einen einheitlichen Detaillierungsgrad der Dokumentation zur Verfügung stellt, da der Punkt der
Kategorisierung der Teilsysteme darin besteht, dass der Entwickler für SFR-unterstützende und
SFR-nicht-störende Teilsysteme weniger Informationen zur Verfügung stellen kann als für SFR-durchsetzende
Teilsysteme.
Ein SFR-unterstützendes Teilsystem ist eines, auf das ein SFR-durchsetzendes Teilsystem angewiesen ist, um
eine SFR zu implementieren, das aber nicht so direkt eine Rolle spielt wie ein SFR-durchsetzendes Teilsystem.
Ein SFR-nicht-störendes Teilsystem ist ein System, das weder in einer unterstützenden noch in einer
durchsetzenden Rolle von der Umsetzung einer SFR abhängig ist.
ISO/IEC 15408-3 ADV_TDS.1.4C: Das Design muss das SFR-durchsetzende Verhalten der SFR-durchsetzenden
Teilsysteme zusammenfassen.
Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass er eine vollständige, genaue und
allgemeine Beschreibung des SFR-durchsetzenden Verhaltens der SFR-durchsetzenden Teilsysteme liefert.
126
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Entwickler kann Teilsysteme als SFR-durchsetzend, SFR-unterstützend und SFR-nicht-störend bezeich-
nen, aber diese „Tags“ werden nur verwendet, um die Menge und Art der Informationen zu beschreiben, die
der Entwickler bereitstellen muss, und können verwendet werden, um die Menge der Informationen zu
begrenzen, die der Entwickler entwickeln muss, wenn bei seinem Entwicklungsprozess nicht die erforderliche
Dokumentation erstellt wird. Unabhängig davon, ob die Teilsysteme vom Entwickler kategorisiert wurden
oder nicht, liegt es in der Verantwortung des Evaluators, festzustellen, ob die Teilsysteme über die für ihre
Rolle (SFR-durchsetzend usw.) im TOE geeigneten Informationen verfügen, und die entsprechenden
Informationen vom Entwickler einzuholen, falls der Entwickler die erforderlichen Informationen für ein
bestimmtes Teilsystem nicht zur Verfügung stellen sollte.
Das SFR-durchsetzende Verhalten bezieht sich darauf, wie ein Teilsystem die Funktionalität bereitstellt, die
eine SFR implementiert. Eine allgemeine Beschreibung muss sich nicht auf bestimmte Datenstrukturen
beziehen (obwohl sie sich auf diese beziehen kann), sondern spricht stattdessen von einem allgemeineren
Datenfluss, Nachrichtenfluss und Kontrollbeziehungen innerhalb eines Teilsystems. Das Ziel dieser Beschrei-
bungen ist es, dem Evaluator genügend Informationen zu geben, um zu verstehen, wie das SFR-durchsetzende
Verhalten erreicht wird. Es ist zu beachten, dass der Evaluator in den TOE-Designunterlagen für diese
Workunit inakzeptable Behauptungen zur SFR-Durchsetzung finden sollte. Es sollte beachtet werden, dass der
Evaluator festlegt, was „allgemein“ für einen bestimmten TOE bedeutet, und dass der Evaluator vom
Entwickler genügend Informationen erhält, um eine fundierte Entscheidung für diese Workunit zu fällen.
Um Vollständigkeit und Genauigkeit festzulegen, untersucht der Evaluator andere verfügbare Informationen
(z. B. Funktionsspezifikation, Beschreibung der Sicherheitsarchitektur, Darstellung der Implementierung). Die
Beschreibungen der Funktionalität in diesen Dokumenten sollten gegenüber dem konsistent sein, was als
Nachweis für diese Workunit vorgelegt wird.
ISO/IEC 15408-3 ADV_TDS.1.5C: Das Design muss eine Beschreibung der Interaktionen zwischen den
SFR-durchsetzenden Teilsystemen der TSF sowie zwischen den SFR-durchsetzenden Teilsystemen der TSF und
anderen Teilsystemen der TSF bereitstellen.
Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass Interaktionen zwischen den
Teilsystemen der TSF beschrieben werden.
Das Ziel der Beschreibung der Interaktionen zwischen den SFR-durchsetzenden Teilsystemen und anderen
Teilsystemen ist es, dem Leser ein besseres Verständnis der Funktionsweise der TSF zu vermitteln. Diese
Interaktionen müssen nicht auf der Implementierungsebene charakterisiert werden (z. B. Parameter, die von
einer Routine in einem Teilsystem an eine Routine in einem anderen Teilsystem übergeben werden; globale
Variablen; Hardwaresignale (z. B. Interrupts) von einem Hardware-Teilsystem an ein Interrupt-behandelndes
Teilsystem), aber die für ein bestimmtes Teilsystem identifizierten Datenelemente, die von einem anderen
Teilsystem verwendet werden sollen, müssen in dieser Erörterung behandelt werden. Alle Kontroll-
beziehungen zwischen Teilsystemen (z. B. ein Teilsystem, das für die Konfiguration einer Regelbasis für ein
Firewall-System verantwortlich ist, und das Teilsystem, das diese Regeln tatsächlich umsetzt) sollten ebenfalls
beschrieben werden.
Die Evaluatoren müssen bei der Beurteilung der Vollständigkeit der Beschreibung ihr eigenes
Urteilsvermögen einsetzen. Wenn der Grund für eine Interaktion unklar ist oder wenn es SFR-bezogene
Interaktionen gibt (die z. B. bei der Untersuchung der Beschreibungen des Teilsystemverhaltens entdeckt
werden), die nicht beschrieben zu sein scheinen, stellt der Evaluator sicher, dass diese Informationen vom
Entwickler zur Verfügung gestellt werden. Wenn der Evaluator jedoch feststellen kann, dass die Interaktionen
zwischen einer bestimmten Gruppe von Teilsystemen zwar vom Entwickler unvollständig beschrieben
werden, aber nicht zum Verständnis der Gesamtfunktionalität oder der von der TSF bereitgestellten
Sicherheitsfunktionalität beitragen, kann der Evaluator die Beschreibung als ausreichend betrachten und
nicht um ihrer selbst willen nach Vollständigkeit streben.
ISO/IEC 15408-3 ADV_TDS.1.6C: Die Zuordnung muss nachweisen, dass sich alle TSFIs auf das im von ihnen
aufgerufenen TOE-Design beschrieben Verhalten zurückverfolgen lassen.
127
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass es eine vollständige und genaue
Zuordnung von der in der Funktionsspezifikation beschriebenen TSFI auf die Teilsysteme der im TOE-Design
beschriebenen TSF enthält.
Die im TOE-Design beschriebenen Teilsysteme bieten eine Beschreibung der Funktionsweise der TSF auf einer
detaillierten Ebene für SFR-durchsetzende Teile der TSF und auf einer höheren Ebene für andere Teile der
TSF. Die TSFI beschreibt, wie die Implementierung durchgeführt wird. Die Nachweise des Entwicklers
identifizieren das Teilsystem, das anfänglich einbezogen ist, wenn eine Operation bei der TSFI angefragt wird,
und identifizieren die verschiedenen Teilsysteme, die primär für die Implementierung der Funktionalität
verantwortlich sind. Es ist zu beachten, dass ein vollständiger „Call Tree“ (Aufrufbaum) nicht für jede TSFI bei
dieser Workunit erforderlich ist.
Der Evaluator bewertet die Vollständigkeit der Zuordnung, indem er sicherstellt, dass alle TSFIs auf
mindestens ein Teilsystem abgebildet werden. Die Überprüfung der Genauigkeit ist komplexer.
Der erste Aspekt der Genauigkeit besteht darin, dass jede TSFI an der TSF-Grenze auf ein Teilsystem
abgebildet wird. Diese Bestimmung kann durch Überprüfung der Beschreibung des Teilsystems und seiner
Interaktionen erfolgen und aus diesen Informationen seinen Platz in der Architektur bestimmen. Der nächste
Aspekt der Genauigkeit ist die Sinnhaftigkeit der Zuordnung. Beispielsweise ist die Zuordnung einer TSFI, die
sich mit der Zugriffskontrolle befasst, zu einem Teilsystem, das Passwörter überprüft, nicht korrekt. Der
Evaluator sollte auch bei dieser Bestimmung sein Urteilsvermögen einsetzen. Das Ziel ist, dass diese
Informationen dem Evaluator helfen, das System und die Implementierung der SFRs zu verstehen, und die Art
und Weise, wie Entitäten an der TSF-Grenze mit der TSF interagieren können. Der Großteil der Beurteilung,
ob die SFRs durch die Teilsysteme genau beschrieben werden, wird in anderen Workunits durchgeführt.
Der Evaluator muss die funktionalen Sicherheitsanforderungen des TOEs und das TOE-Design untersuchen,
um festzustellen, dass alle funktionalen ST-Sicherheitsanforderungen durch das TOE-Design abgedeckt sind.
Der Evaluator kann eine Zuordnung zwischen den funktionalen Sicherheitsanforderungen des TOEs und dem
TOE-Design erstellen. Diese Zuordnung wird wahrscheinlich von einer funktionalen Anforderung zu einer
Menge Teilsysteme führen. Es ist zu beachten, dass diese Zuordnung aufgrund von Operationen (Zuweisungen,
Präzisierungen, Selektionen), die der ST-Autor an der funktionalen Anforderung vorgenommen hat,
möglicherweise in einem Detaillierungsgrad unterhalb der Komponenten- oder sogar Elementebene der
Anforderungen liegen muss.
Beispielsweise enthält die Komponente FDP_ACC.1 „Subset access control“ ein Element mit Zuweisungen.
Wenn die ST z. B. zehn Regeln in der Zuweisung FDP_ACC.1 „Subset access control“ enthielt und diese zehn
Regeln an bestimmten Stellen innerhalb von fünfzehn Modulen implementiert wurden, wäre es für den
Evaluator unangemessen, FDP_ACC.1 „Subset access control“ auf ein Teilsystem abzubilden und zu behaupten,
die Workunit sei abgeschlossen. Stattdessen würde der Evaluator FDP_ACC.1 „Subset access control“ (Regel 1)
auf Teilsystem A, Verhaltensweisen x, y und z abbilden; FDP_ACC.1 „Subset access control“ (Regel 2) auf
Teilsystem A, Verhaltensweisen x, p und q; usw.
Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass es eine genaue Instanziierung aller
funktionalen Sicherheitsanforderungen darstellt.
128
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator stellt sicher, dass jede Sicherheitsanforderung, die im Unterabschnitt Funktionale Sicherheits-
anforderungen an den TOE der ST aufgeführt ist, eine entsprechende Designbeschreibung im TOE-Design hat,
die genau angibt, wie die TSF diese Anforderung erfüllt. Dies erfordert, dass der Evaluator eine Sammlung von
Teilsystemen identifiziert, die für die Implementierung einer bestimmten funktionalen Anforderung
verantwortlich sind, und dann diese Teilsysteme untersucht, um zu verstehen, wie die Anforderung umgesetzt
wird. Schließlich würde der Evaluator beurteilen, ob die Anforderung korrekt umgesetzt wurde.
Wenn beispielsweise die ST-Anforderungen einen rollenbasierten Zugriffskontrollmechanismus vorsehen,

würde der Evaluator zunächst die Teilsysteme identifizieren, die zur Implementierung dieses Mechanismus
beitragen. Dies könnte durch vertieftes Wissen oder Verständnis des TOEs-Designs oder durch Arbeiten in der
vorherigen Workunit geschehen. Es ist zu beachten, dass diese Verfolgung nur dazu dient, die Teilsysteme zu
identifizieren, und nicht die vollständige Analyse darstellt.
Der nächste Schritt wäre zu verstehen, welchen Mechanismus die Teilsysteme implementiert haben. Wenn
das Design beispielsweise eine Implementierung der Zugriffskontrolle auf der Grundlage von UNIX-ähnlichen
Schutzbits beschreibt, wäre das Design keine genaue Instanziierung der im oben verwendeten ST-Beispiel
vorhandenen Zugriffskontrollanforderungen. Wenn der Evaluator aufgrund fehlender Details nicht feststellen
konnte, dass der Mechanismus korrekt umgesetzt wurde, müsste er beurteilen, ob alle SFR-durchsetzenden
Teilsysteme identifiziert wurden oder ob für diese Teilsysteme ausreichende Details bereitgestellt wurden.
10.8.2.1 Eingaben
a) die ST,
d) das TOE-Design.
Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass die Struktur des gesamten TOEs in
beschrieben werden. Je nach Komplexität des TOEs kann dessen Design in Form von Teilsystemen und
Auf dieser Vertrauenswürdigkeitsstufe muss die Zerlegung nur auf der Ebene des „Teilsystems“ erfolgen.
129
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
werden.
ISO/IEC 15408-3 ADV_TDS.2.3C: Das Design muss das Verhalten jedes SFR-nicht-störenden TSF-Teilsystems
detailliert genug beschreiben, um festzustellen, dass es SFR-nicht-störend ist.
Der Evaluator muss das TOE-Design untersuchen, um festzustellen, ob jedes SFR-nicht-störende Teilsystem
der TSF so beschrieben ist, dass der Evaluator feststellen kann, dass das Teilsystem SFR-nicht-störend ist.
SFR-nicht-störende Teilsysteme und ihre Funktionen im System brauchen nicht im Detail beschrieben zu
werden. Der Evaluator stellt jedoch auf der Grundlage der vom Entwickler vorgelegten Nachweise fest, dass
die Teilsysteme, die keine detaillierten Beschreibungen haben, SFR-nicht-störend sind. Es ist zu beachten, dass
diese Workunit weitgehend erfüllt sein wird, wenn der Entwickler einen einheitlichen Detaillierungsgrad der
Dokumentation zur Verfügung stellt, da der Punkt der Kategorisierung der Teilsysteme darin besteht, dass der
Entwickler für SFR-nicht-störende Teilsysteme weniger Informationen zur Verfügung stellen kann als für
SFR-durchsetzende und SFR-unterstützende Teilsysteme.
Ein SFR-nicht-störendes Teilsystem ist eines, von dem die SFR-durchsetzenden und SFR-unterstützenden
Teilsysteme nicht abhängig sind; d. h. sie spielen keine Rolle bei der Implementierung der SFR-Funktionalität.
ISO/IEC 15408-3 ADV_TDS.2.4C: Das Design muss das SFR-durchsetzende Verhalten der SFR-durchsetzenden
Teilsysteme beschreiben.
detaillierte Beschreibung des SFR-durchsetzenden Verhaltens der SFR-durchsetzenden Teilsysteme liefert.
Das SFR-durchsetzende Verhalten bezieht sich darauf, wie ein Teilsystem die Funktionalität bereitstellt, die
eine SFR implementiert. Obwohl es sich nicht um eine algorithmische Beschreibung handelt, wird in einer
detaillierten Verhaltensbeschreibung in der Regel erörtert, wie die Funktionalität in Bezug auf die
Schlüsseldaten und Datenstrukturen bereitgestellt wird, welche Kontrollbeziehungen innerhalb eines
Teilsystems bestehen und wie diese Elemente zusammenwirken, um das SFR-durchsetzende Verhalten
bereitzustellen. Eine solche Beschreibung bezieht sich auch auf ein SFR-unterstützendes Verhalten, das der
Evaluator bei der Durchführung nachfolgender Workunits berücksichtigen sollte.
130
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Um Vollständigkeit und Genauigkeit zu bestimmen, untersucht der Evaluator andere verfügbare Informa-
tionen (z. B. Funktionsspezifikation, Beschreibung der Sicherheitsarchitektur). Die Beschreibungen der
Funktionalität in diesen Dokumenten sollten gegenüber dem konsistent sein, was als Nachweis für diese
Workunit vorgelegt wird.
ISO/IEC 15408-3 ADV_TDS.2.5C: Das Design muss das SFR-unterstützende und SFR-nicht-störende Verhalten
der SFR-durchsetzenden Teilsysteme zusammenfassen.
allgemeine Beschreibung des SFR-unterstützenden und SFR-nicht-störenden Verhaltens der SFR-durch-
setzenden Teilsysteme liefert.
Im Gegensatz zur vorherigen Workunit fordert diese Workunit den Evaluator auf, die für SFR-unterstützende
oder SFR-nicht-störende Teilsysteme bereitgestellten Informationen zu beurteilen. Mit dieser Beurteilung
werden zwei Ziele verfolgt. Erstens sollte es dem Evaluator ein besseres Verständnis der Funktionsweise der
einzelnen Teilsysteme vermitteln. Zweitens stellt der Evaluator fest, dass das gesamte SFR-durchsetzende
Verhalten eines Teilsystems beschrieben wurde. Im Gegensatz zur vorherigen Workunit müssen die
Informationen, die für das SFR-unterstützende oder SFR-nicht-störende Verhalten bereitgestellt werden,
nicht so detailliert sein wie die Informationen, die durch das SFR-durchsetzende Verhalten bereitgestellt
werden. Beispielsweise müssen Datenstrukturen oder Datenelemente, die nicht zur SFR-durchsetzenden
Funktion gehören, wahrscheinlich nicht oder gar nicht detailliert beschrieben werden. Es ist jedoch die
Entscheidung des Evaluators, was „allgemein“ für einen bestimmten TOE bedeutet, und der Evaluator erhält
vom Entwickler genügend Informationen (selbst wenn sich herausstellt, dass diese Informationen den
Informationen entsprechen, die für die Teile des Teilsystems bereitgestellt werden, die SFR-durchsetzend
sind), um eine fundierte Entscheidung für diese Workunit zu fällen.
Der Evaluator wird jedoch gewarnt, dass „perfekte“ Vertrauenswürdigkeit weder ein Ziel ist noch von dieser
Workunit verlangt wird, so dass bei der Bestimmung des Umfangs und der Zusammensetzung der Nachweise,
die für eine Entscheidung über diese Workunit erforderlich sind, das entsprechende Urteilsvermögen
eingesetzt werden muss.
Um Vollständigkeit und Genauigkeit zu bestimmen, untersucht der Evaluator andere verfügbare Informa-
tionen (z. B. Funktionsspezifikation, Beschreibung der Sicherheitsarchitektur). Die Beschreibungen der
Funktionalität in diesen Dokumenten sollten gegenüber dem konsistent sein, was als Nachweis für diese
Workunit vorgelegt wird. Insbesondere sollte die Funktionsspezifikation verwendet werden, um festzustellen,
dass das Verhalten, das zur Implementierung der in der Funktionsspezifikation beschriebenen
TSF-Schnittstellen erforderlich ist, vom Teilsystem vollständig beschrieben wird, da das Verhalten entweder
SFR-durchsetzend, SFR-unterstützend oder SFR-nicht-störend sein wird.
ISO/IEC 15408-3 ADV_TDS.2.6C: Das Design muss das Verhalten der SFR-unterstützenden Teilsysteme
zusammenfassen.
131
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
allgemeine Beschreibung des Verhaltens der SFR-unterstützenden Teilsysteme liefert.
Im Gegensatz zu den beiden vorhergehenden Workunits verlangt diese Workunit vom Entwickler die
Bereitstellung (und vom Evaluator die Beurteilung) von Informationen über die SFR-unterstützenden
Teilsysteme. Solche Teilsysteme sollten durch die Beschreibungen der SFR-durchsetzenden Teilsysteme
sowie durch die Beschreibungen der Interaktionen in Workunit ADV_TDS.2-7 referenziert werden. Mit der
Beurteilung durch den Evaluator werden, wie bei der vorherigen Workunit, zwei Ziele verfolgt. Erstens sollte
es dem Evaluator ein Verständnis für die Funktionsweise jedes SFR-unterstützenden Teilsystems vermitteln.
Zweitens stellt der Evaluator fest, dass das Verhalten ausreichend detailliert beschrieben ist, so dass die Art
und Weise, in der das Teilsystem das SFR-durchsetzende Verhalten unterstützt, klar ist, und dass das
Verhalten selbst nicht SFR-durchsetzend ist. Die Informationen, die für das Verhalten des SFR-unter-
stützenden Teilsystems bereitgestellt werden, müssen nicht so detailliert sein wie die Informationen, die das
SFR-durchsetzende Verhalten liefert. Beispielsweise müssen Datenstrukturen oder Datenelemente, die nicht
zur SFR-durchsetzenden Funktion gehören, wahrscheinlich nicht oder gar nicht detailliert beschrieben
werden. Es ist jedoch die Entscheidung des Evaluators, was „allgemein“ für einen bestimmten TOE bedeutet,
und der Evaluator erhält vom Entwickler genügend Informationen (selbst wenn sich herausstellt, dass diese
Informationen den Informationen entsprechen, die für die Teile des Teilsystems bereitgestellt werden, die
SFR-durchsetzend sind), um eine fundierte Entscheidung für diese Workunit zu fällen.
Der Evaluator wird jedoch gewarnt, dass „perfekte“ Vertrauenswürdigkeit weder ein Ziel ist noch von dieser
Workunit verlangt wird, so dass bei der Bestimmung des Umfangs und der Zusammensetzung der Nachweise,
die für eine Entscheidung über diese Workunit erforderlich sind, das entsprechende Urteilsvermögen
eingesetzt werden muss.
Um Vollständigkeit und Genauigkeit festzulegen, untersucht der Evaluator andere verfügbare Informationen
(z. B. Funktionsspezifikation, Beschreibung der Sicherheitsarchitektur, Darstellung der Implementierung). Die
Beschreibungen der Funktionalität in diesen Dokumenten sollten gegenüber dem konsistent sein, was als
Nachweis für diese Workunit vorgelegt wird. Insbesondere sollte die Funktionsspezifikation verwendet
werden, um festzustellen, dass das Verhalten, das zur Implementierung der in der Funktionsspezifikation
beschriebenen TSF-Schnittstellen erforderlich ist, vom Teilsystem vollständig beschrieben wird.
ISO/IEC 15408-3 ADV_TDS.2.7C: Das Design muss eine Beschreibung der Interaktionen zwischen allen
Teilsystemen des TSF bereitstellen.
Das Ziel der Beschreibung der Interaktionen zwischen den Teilsystemen ist es, dem Leser ein besseres
Verständnis der Funktionsweise der TSF zu vermitteln. Diese Interaktionen müssen nicht auf der
Implementierungsebene charakterisiert werden (z. B. Parameter, die von einer Routine in einem Teilsystem
an eine Routine in einem anderen Teilsystem übergeben werden; globale Variablen; Hardwaresignale (z. B.
132
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Interrupts) von einem Hardware-Teilsystem an ein Interrupt-behandelndes Teilsystem), aber die für ein
bestimmtes Teilsystem identifizierten Datenelemente, die von einem anderen Teilsystem verwendet werden
sollen, müssen in dieser Erörterung behandelt werden. Alle Kontrollbeziehungen zwischen Teilsystemen (z. B.
ein Teilsystem, das für die Konfiguration einer Regelbasis für ein Firewall-System verantwortlich ist, und das
Teilsystem, das diese Regeln tatsächlich umsetzt) sollten ebenfalls beschrieben werden.
Während der Entwickler alle Interaktionen zwischen den Teilsystemen charakterisieren sollte, sollte beachtet
werden, dass die Evaluatoren bei der Beurteilung der Vollständigkeit der Beschreibung ihr eigenes Urteils-
vermögen einsetzen müssen. Wenn der Grund für eine Interaktion unklar ist oder wenn es SFR-bezogene
Interaktionen gibt (die z. B. bei der Untersuchung der Beschreibungen des Teilsystemverhaltens entdeckt
werden, aber nicht zum Verständnis der Gesamtfunktionalität oder der von der TSF bereitgestellten
Sicherheitsfunktionalität beitragen, kann der Evaluator die Beschreibung als ausreichend betrachten und
nicht um ihrer selbst willen nach Vollständigkeit streben.
aufgerufenen TOE-Design beschriebene Verhalten zurückverfolgen lassen.
Zuordnung von der in der Funktionsspezifikation beschriebenen TSFI auf die Teilsysteme der im TOE-Design
Die im TOE-Design beschriebenen Teilsysteme bieten eine Beschreibung der Funktionsweise der TSF auf einer
detaillierten Ebene für SFR-durchsetzende Teile der TSF und auf einer höheren Ebene für andere Teile der
TSF. Die TSFI beschreibt, wie die Implementierung durchgeführt wird. Die Nachweise des Entwicklers
identifizieren das Teilsystem, das anfänglich einbezogen ist, wenn eine Operation bei der TSFI angefragt wird,
und identifizieren die verschiedenen Teilsysteme, die primär für die Implementierung der Funktionalität
verantwortlich sind. Es ist zu beachten, dass ein vollständiger „Call Tree“ (Aufrufbaum) nicht für jede TSFI bei
dieser Workunit erforderlich ist.
mindestens ein Teilsystem abgebildet werden. Die Überprüfung der Genauigkeit ist komplexer.
Der erste Aspekt der Genauigkeit besteht darin, dass jede TSFI an der TSF-Grenze auf ein Teilsystem
abgebildet wird. Diese Bestimmung kann durch Überprüfung der Beschreibung des Teilsystems und seiner
Interaktionen erfolgen und aus diesen Informationen seinen Platz in der Architektur bestimmen. Der nächste
Aspekt der Genauigkeit ist die Sinnhaftigkeit der Zuordnung. Beispielsweise ist die Zuordnung einer TSFI, die
sich mit der Zugriffskontrolle befasst, zu einem Teilsystem, das Passwörter überprüft, nicht korrekt. Der
Evaluator sollte auch bei dieser Bestimmung sein Urteilsvermögen einsetzen. Das Ziel ist, dass diese
Informationen dem Evaluator helfen, das System und die Implementierung der SFRs zu verstehen, und die Art
und Weise, wie Entitäten an der TSF-Grenze mit der TSF interagieren können. Der Großteil der Beurteilung,
ob die SFRs durch die Teilsysteme genau beschrieben werden, wird in anderen Workunits durchgeführt.
133
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
auf Teilsystem A, Verhaltensweisen x, y und z abbilden; FDP_ACC.1 „Subset access control“ (Regel 2) auf
Teilsystem A, Verhaltensweisen x, p und q; usw.
Der Evaluator stellt sicher, dass jede Sicherheitsanforderung, die im Unterabschnitt Funktionale Sicherheits-
anforderungen an den TOE der ST aufgeführt ist, eine entsprechende Designbeschreibung im TOE-Design hat,
die genau angibt, wie die TSF diese Anforderung erfüllt. Dies erfordert, dass der Evaluator eine Sammlung von
Teilsystemen identifiziert, die für die Implementierung einer bestimmten funktionalen Anforderung
verantwortlich sind, und dann diese Teilsysteme untersucht, um zu verstehen, wie die Anforderung umgesetzt
wird. Schließlich würde der Evaluator beurteilen, ob die Anforderung korrekt umgesetzt wurde.

würde der Evaluator zunächst die Teilsysteme identifizieren, die zur Implementierung dieses Mechanismus
beitragen. Dies könnte durch vertieftes Wissen oder Verständnis des TOEs-Designs oder durch Arbeiten in der
vorherigen Workunit geschehen. Es ist zu beachten, dass diese Verfolgung nur dazu dient, die Teilsysteme zu
identifizieren, und nicht die vollständige Analyse darstellt.
Der nächste Schritt wäre zu verstehen, welchen Mechanismus die Teilsysteme implementiert haben. Wenn
das Design beispielsweise eine Implementierung der Zugriffskontrolle auf der Grundlage von UNIX-ähnlichen
Schutzbits beschreibt, wäre das Design keine genaue Instanziierung der im oben verwendeten ST-Beispiel
vorhandenen Zugriffskontrollanforderungen. Wenn der Evaluator aufgrund fehlender Details nicht feststellen
konnte, dass der Mechanismus korrekt umgesetzt wurde, müsste er beurteilen, ob alle SFR-durchsetzenden
Teilsysteme identifiziert wurden oder ob für diese Teilsysteme ausreichende Details bereitgestellt wurden.
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob das TOE-Design eine Beschreibung des
TOEs in Form von Teilsystemen liefert, die ausreicht, um die TSF-Grenze zu bestimmen, und eine
Beschreibung der TSF-Interna in Form von Modulen (und optional übergeordnete Abstraktionen) liefert. Sie
enthält eine detaillierte Beschreibung der SFR-durchsetzenden Module und genügend Informationen über die
SFR-unterstützenden und SFR-nicht-störenden Module, damit der Evaluator feststellen kann, ob die SFRs
vollständig und genau implementiert sind; das TOE-Design bietet daher eine Erläuterung der Darstellung der
Implementierung.
134
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
10.8.3.2 Eingaben
a) die ST,
d) die TOE-Gestaltung.
Es gibt drei Arten von Aufgaben, die der Evaluator in Bezug auf das TOE-Design durchführen muss. Zunächst
stellt der Evaluator fest, dass die TSF-Grenze angemessen beschrieben wurde. Zweitens stellt der Evaluator
fest, dass der Entwickler eine Dokumentation zur Verfügung gestellt hat, die den Anforderungen an Inhalt und
Darstellung dieses Teilsystems entspricht und die gegenüber anderen für den TOE bereitgestellten
Dokumentationen konsistent ist. Schließlich muss der Evaluator die für die SFR-durchsetzenden Module (auf
einer detaillierten Ebene) und die SFR-unterstützenden und SFR-nicht-störenden Module (auf einer weniger
detaillierten Ebene) bereitgestellten Designinformationen analysieren, um zu verstehen, wie das System
implementiert wird, und mit diesem Wissen sicherstellen, dass die TSFIs in der Funktionsspezifikation
angemessen beschrieben sind und dass die Prüfinformationen die TSF (die in den Workunits „Class ATE:
Tests“ erfolgt) angemessen prüft.
Es ist wichtig zu beachten, dass der Entwickler zwar verpflichtet ist, eine vollständige Beschreibung der TSF
vorzulegen (obwohl die SFR-durchsetzenden Module detaillierter sind als die SFR-unterstützenden oder
SFR-nicht-störenden Module), dass aber vom Evaluator erwartet wird, dass er bei der Durchführung seiner
Analyse sein Urteilsvermögen einsetzt. Während vom Evaluator erwartet wird, dass er sich jedes Modul
ansieht, kann der Detaillierungsgrad bei jedem untersuchten Modul variieren. Der Evaluator analysiert jedes
Modul, damit er genug Verständnis erlangt, um die Auswirkung der Funktionalität des Moduls auf die
Sicherheit des Systems zu bestimmen, und die Tiefe, in der er das Modul analysieren muss, kann je nach Rolle
des Moduls im System variieren. Ein wichtiger Aspekt dieser Analyse besteht darin, dass der Evaluator die
andere zur Verfügung gestellte Dokumentation (TSS, Funktionsspezifikation, Beschreibung der Sicherheits-
architektur und das Dokument der TSF-Interna) verwenden sollte, um festzustellen, ob die beschriebene
Funktionalität korrekt ist und die implizite Bezeichnung von SFR-unterstützenden oder SFR-nicht-störenden
Modulen (siehe unten) durch ihre Rolle in der Systemarchitektur unterstützt wird.
Der Entwickler kann Module als SFR-durchsetzend, SFR-unterstützend und SFR-nicht-störend bezeichnen,
aber diese „Tags“ werden nur verwendet, um die Menge und Art der Informationen zu beschreiben, die der
Entwickler bereitstellen muss, und sie können verwendet werden, um die Menge der Informationen zu
begrenzen, die der Entwickler entwickeln muss, wenn sein Entwicklungsprozess nicht die erforderliche
Dokumentation erstellt. Unabhängig davon, ob die Module vom Entwickler kategorisiert wurden oder nicht,
liegt es in der Verantwortung des Evaluators, festzustellen, ob die Module über die für ihre Rolle (SFR-durch-
setzend usw.) im TOE geeigneten Informationen verfügen, und die entsprechenden Informationen vom
Entwickler einzuholen, falls der Entwickler die erforderlichen Informationen für ein bestimmtes Modul nicht
zur Verfügung stellt.
135
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Für einen sehr einfachen TOE, der ausschließlich auf der „Modul“-Ebene beschrieben werden kann (siehe
ADV_TDS.3-2), ist diese Workunit nicht anwendbar und gilt daher als erfüllt.
ISO/IEC 15408-3 ADV_TDS.3.2C: Das Design muss die TSF in Form von Modulen beschreiben.
Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass die gesamte TSF in Form von
Modulen beschrieben wird.
Der Evaluator untersucht die Module auf bestimmte Eigenschaften in anderen Workunits; in dieser Workunit
stellt der Evaluator fest, dass die modulare Beschreibung die gesamte TSF abdeckt und nicht nur einen Teil
der TSF. Der Evaluator stützt sich bei dieser Bestimmung auf andere für die Evaluierung bereitgestellte
Nachweise (z. B. Funktionsspezifikation, Beschreibung der Sicherheitsarchitektur). Wenn die Funktions-
spezifikation beispielsweise Schnittstellen zu Funktionen enthält, die nicht in der Beschreibung des
TOEs-Designs beschrieben zu sein scheinen, ist es möglich, dass ein Teil der TSF nicht angemessen einbezogen
wurde. Diese Feststellung wird wahrscheinlich ein iterativer Prozess sein, bei dem mit zunehmender Analyse
der anderen Nachweise mehr Vertrauen in die Vollständigkeit der Dokumentation gewonnen werden kann.
Im Gegensatz zu Teilsystemen beschreiben die Module die Implementierung in einem Detaillierungsgrad, der
als Leitfaden für die Überprüfung der Darstellung der Implementierung dienen kann. Eine Beschreibung eines
Moduls sollte so beschaffen sein, dass aus der Beschreibung eine Implementierung des Moduls erstellt werden
könnte, und die resultierende Implementierung wäre 1) identisch mit der tatsächlichen TSF-Implementierung
in Bezug auf die dargestellten Schnittstellen, 2) identisch in der Verwendung von Schnittstellen, die im Design
erwähnt werden, und 3) funktional gleichwertig mit der Beschreibung des Zwecks des TSF-Moduls. Zum
Beispiel bietet RFC 793 eine allgemeine Beschreibung des TCP-Protokolls. Es ist notwendigerweise implemen-
tierungsunabhängig. Es bietet zwar eine Fülle von Details, ist aber keine geeignete Designbeschreibung, da es
nicht spezifisch für eine Implementierung ist. Eine tatsächliche Implementierung kann das im RFC
spezifizierte Protokoll ergänzen, und Implementierungsentscheidungen (z. B. die Verwendung von globalen
Daten im Vergleich zu lokalen Daten in verschiedenen Teilen der Implementierung) können sich auf die
durchgeführte Analyse auswirken. Die Designbeschreibung des TCP-Moduls würde die Schnittstellen
auflisten, die von der Implementierung dargestellt werden (und nicht nur die in RFC 793 definierten), sowie
eine Algorithmusbeschreibung der Verarbeitung, die mit den Modulen, die TCP implementieren, verbunden
ist (vorausgesetzt, sie ist Teil der TSF).
136
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
werden.
Wenn das Design ausschließlich in Form von Modulen dargestellt wird, dann sind Teilsysteme in diesen
Anforderungen den Modulen gleichwertig und die Aufgabe sollte auf der Modulebene durchgeführt werden.
ISO/IEC 15408-3 ADV_TDS.3.4C: Das Design muss eine Beschreibung jedes Teilsystems der TSF bereitstellen.
Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass jedes Teilsystem der TSF seine Rolle
bei der Durchsetzung der in der ST beschriebenen SFRs beschreibt.
Wird das Design ausschließlich in Form von Modulen dargestellt, so wird diese Workunit durch die
Beurteilung in den nachfolgenden Workunits als zufriedenstellend angesehen; eine explizite Aktion des
Evaluators ist in diesem Fall nicht erforderlich.
Bei Systemen, die komplex genug sind, um zusätzlich zur modularen Beschreibung eine Beschreibung der TSF
auf Teilsystemebene zu rechtfertigen, besteht das Ziel der Beschreibung auf Teilsystemebene darin, dem
Evaluator einen Kontext für die folgende modulare Beschreibung zu geben. Daher stellt der Evaluator sicher,
dass die Beschreibung auf Teilsystemebene eine Beschreibung darüber enthält, wie die funktionalen
Sicherheitsanforderungen im Design erreicht werden, jedoch auf einer Abstraktionsebene oberhalb der
modularen Beschreibung. Diese Beschreibung sollte die verwendeten Mechanismen auf einer Ebene erörtern,
die mit der Modulbeschreibung abgestimmt ist; dadurch erhalten die Evaluatoren die Roadmap, die für eine
intelligente Beurteilung der in der Modulbeschreibung enthaltenen Informationen erforderlich ist. Eine
wohlformulierte Menge Teilsystembeschreibungen hilft dem Evaluator bei der Bestimmung der Module, die
am wichtigsten für die Untersuchung sind, und konzentriert so die Evaluierungstätigkeit auf die Teile der TSF,
die die größte Relevanz in Bezug auf die Durchsetzung der SFRs haben.
Der Evaluator stellt sicher, dass alle Teilsysteme der TSF eine Beschreibung haben. Während sich die
Beschreibung auf die Rolle konzentrieren sollte, die das Teilsystem bei der Durchsetzung oder Unterstützung
der Implementierung der SFRs spielt, müssen genügend Informationen vorhanden sein, damit ein Kontext für
das Verständnis der SFR-bezogenen Funktionalität gegeben ist.
137
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Beschreibung darauf konzentrieren sollte, dass das Teilsystem bei der Durchsetzung oder Unterstützung der
Implementierung der SFRs keine Rolle spielt, müssen genügend Informationen vorhanden sein, damit ein
Kontext für das Verständnis der SFR-nicht-störenden Funktionalität gegeben ist.
Teilsystemen der TSF bereitstellen.
auf Teilsystemebene zu rechtfertigen, soll die Beschreibung der Interaktionen zwischen den Teilsystemen
dazu beitragen, dem Leser ein besseres Verständnis dafür zu vermitteln, wie die TSF ihre Funktionen erfüllt.
Diese Interaktionen müssen nicht auf der Implementierungsebene charakterisiert werden (z. B. Parameter,
die von einer Routine in einem Teilsystem an eine Routine in einem anderen Teilsystem übergeben werden;
globale Variablen; Hardwaresignale (z. B. Interrupts) von einem Hardware-Teilsystem an ein Interrupt-
behandelndes Teilsystem), aber die für ein bestimmtes Teilsystem identifizierten Datenelemente, die von
einem anderen Teilsystem verwendet werden sollen, sollten in dieser Erörterung behandelt werden. Alle
Kontrollbeziehungen zwischen Teilsystemen (z. B. ein Teilsystem, das für die Konfiguration einer Regelbasis
für ein Firewall-System verantwortlich ist, und das Teilsystem, das diese Regeln tatsächlich umsetzt) sollten
ebenfalls beschrieben werden.
werden, dass die Evaluatoren bei der Beurteilung der Vollständigkeit der Beschreibung ihr eigenes
Urteilsvermögen einsetzen müssen. Wenn der Grund für eine Interaktion unklar ist oder wenn es
SFR-bezogene Interaktionen gibt (die z. B. bei der Untersuchung der Dokumentation auf Modulebene entdeckt
werden, und eine vollständige Beschreibung nicht zum Verständnis der Gesamtfunktionalität oder der von der
TSF bereitgestellten Sicherheitsfunktionalität beitragen, kann der Evaluator die Beschreibung als ausreichend
betrachten und nicht um ihrer selbst willen nach Vollständigkeit streben.
ISO/IEC 15408-3 ADV_TDS.3.6C: Das Design muss eine Zuordnung von den Teilsystemen der TSF zu den Modulen
der TSF enthalten.
Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass die Zuordnung zwischen den
Teilsystemen der TSF und den Modulen der TSF vollständig ist.
Wird das Design ausschließlich in Form von Modulen dargestellt, so gilt diese Workunit als erfüllt.
Für TOEs, die komplex genug sind, um zusätzlich zur modularen Beschreibung eine Beschreibung der TSF auf
Teilsystemebene zu rechtfertigen, stellt der Entwickler eine einfache Zuordnung zur Verfügung, die zeigt, wie
die Module der TSF den Teilsystemen zugeordnet sind. Dadurch erhält der Evaluator einen Leitfaden für die
Durchführung seiner Beurteilung auf Modulebene. Um die Vollständigkeit festzustellen, untersucht der
Evaluator jede Zuordnung und stellt fest, dass alle Teilsysteme auf mindestens ein Modul abbilden und dass
alle Module auf genau ein Teilsystem abbilden.
138
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Teilsystemen der TSF und den Modulen der TSF genau ist.
Durchführung seiner Beurteilung auf Modulebene. Der Evaluator kann sich dafür entscheiden, die Genauigkeit
der Zuordnung in Verbindung mit der Durchführung anderer Workunits zu überprüfen. Eine „ungenaue“
Zuordnung ist eine, bei der das Modul fälschlicherweise mit einem Teilsystem verbunden ist, dessen
Funktionen innerhalb des Teilsystems nicht verwendet werden. Da die Zuordnung als Leitfaden zur
Unterstützung einer detaillierteren Analyse gedacht ist, wird der Evaluator darauf hingewiesen, angemessene
Anstrengungen auf diese Workunit aufzubringen. Es ist nicht notwendig, umfangreiche Evaluator-Ressourcen
einzusetzen, um die Genauigkeit der Zuordnung zu überprüfen. Ungenauigkeiten, die zu Missverständnissen
im Zusammenhang mit dem Design führen und im Rahmen dieser oder anderer Workunits aufgedeckt werden,
sollten mit dieser Workunit in Verbindung gebracht und korrigiert werden.
ISO/IEC 15408-3 ADV_TDS.3.7C: Das Design muss jedes SFR-durchsetzende Modul in Hinblick auf seinen Zweck
und seine Beziehung zu anderen Modulen beschreiben.
Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass die Beschreibung des Zwecks jedes
SFR-durchsetzenden Moduls und der Beziehung zu anderen Modulen vollständig und genau ist.
liegt es in der Verantwortung des Evaluators, festzustellen, ob die Module über die für ihre Rolle
(SFR-durchsetzend usw.) im TOE geeigneten Informationen verfügen, und die entsprechenden Informationen
vom Entwickler einzuholen, falls der Entwickler die erforderlichen Informationen für ein bestimmtes Modul
nicht zur Verfügung stellt.
Der Zweck eines Moduls ist die Bereitstellung einer Beschreibung, die angibt, welche Funktion das Modul
erfüllt. Ein entsprechender Hinweis an den Evaluator ist angebracht. Der Schwerpunkt dieser Workunit sollte
darin bestehen, dem Evaluator ein Verständnis für die Funktionsweise des Moduls zu vermitteln, so dass
Entscheidungen über die Fundiertheit der Implementierung der SFRs getroffen werden können, sowie die für
die Komponente ADV_ARC durchgeführte Architekturanalyse zu unterstützen. Solange der Evaluator ein
fundiertes Verständnis der Funktionsweise des Moduls und seiner Beziehung zu anderen Modulen und dem
TOE als Ganzem hat, sollte der Evaluator die Zielsetzung der erreichten Arbeit berücksichtigen und sich nicht
auf eine Dokumentationsübung für den Entwickler einlassen (indem er z. B. eine vollständige algorithmische
Beschreibung für eine selbstverständliche Darstellung der Implementierung verlangt).
Da sich die Module auf einer so niedrigen Ebene befinden, kann es schwierig sein, die Auswirkungen auf
Vollständigkeit und Genauigkeit aus anderen Dokumentationen zu bestimmen, wie z. B. der operativen
Leitlinien für Benutzer, der Funktionsspezifikation, den TSF-Interna oder der Beschreibung der Sicherheits-
architektur. Der Evaluator verwendet jedoch die in diesen Dokumenten enthaltenen Informationen im
Rahmen des Möglichen, um sicherzustellen, dass der Zweck genau und vollständig beschrieben wird. Diese
Analyse kann durch die für die Workunits des Elements ADV_TDS.3.10C durchgeführte Analyse unterstützt
werden, die die TSFI in der funktionalen Spezifikation auf die Module der TSF abbildet.
139
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
ISO/IEC 15408-3 ADV_TDS.3.8C: Das Design muss jedes SFR-durchsetzende Modul in Hinblick auf seine
SFR-bezogenen Schnittstellen, die Rückgabewerte dieser Schnittstellen, die Interaktion mit anderen Modulen und
die aufgerufenen SFR-bezogenen Schnittstellen zu anderen SFR-durchsetzenden Modulen beschreiben.
10.8.3.4.10Workunit ADV_TDS.3-10
Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass die Beschreibung der von jedem
SFR-durchsetzenden Modul dargestellten Schnittstellen eine genaue und vollständige Beschreibung der
SFR-bezogenen Parameter, der Aufrufkonventionen für jede Schnittstelle und aller direkt von der Schnittstelle
zurückgegebenen Werte enthält.
Die SFR-bezogenen Schnittstellen eines Moduls sind diejenigen Schnittstellen, die von anderen Modulen als
Mittel zum Aufrufen der bereitgestellten SFR-bezogenen Operationen und zum Bereitstellen von Eingaben an
das Modul oder zum Empfangen von Ausgaben des Moduls verwendet werden. Der Zweck in der Spezifikation
dieser Schnittstellen ist es, die Ausübung dieser Schnittstellen während der Prüfung zu ermöglichen.
Intermodulschnittstellen, die nicht SFR-bezogen sind, müssen nicht spezifiziert oder beschrieben werden, da
sie kein Faktor beim Prüfen sind. Ebenso müssen andere interne Schnittstellen, die kein Faktor beim
Durchlaufen von SFR-bezogenen Ausführungspfaden sind (wie z. B. jene internen Pfade, die festgelegt sind),
nicht spezifiziert oder beschrieben werden, da sie kein Faktor beim Prüfen sind.
SFR-bezogene Schnittstellen werden in Bezug darauf beschrieben, wie sie aufgerufen werden und welche
Werte zurückgegeben werden. Diese Beschreibung würde eine Liste von SFR-bezogenen Parametern und
Beschreibungen dieser Parameter enthalten. Es ist zu beachten, dass globale Daten auch als Parameter
betrachtet werden, wenn sie beim Aufruf des Moduls (entweder als Ein- oder Ausgänge) verwendet werden.
Wenn von einem Parameter erwartet würde, dass er eine Menge Werte annimmt (z. B. einen „Flag“-
Parameter), würde die vollständige Menge Werte angegeben, die der Parameter annehmen könnte und die
sich auf die Modulverarbeitung auswirken würden. Ebenso werden Parameter, die Datenstrukturen
darstellen, so beschrieben, dass jedes Feld der Datenstruktur identifiziert und beschrieben wird. Es ist zu
beachten, dass verschiedene Programmiersprachen zusätzliche „Schnittstellen“ haben können, die nicht
offensichtlich wären; ein Beispiel wäre die Überlastung von Operatoren/Funktionen in C++. Diese „implizite
Schnittstelle“ in der Klassenbeschreibung würde auch als Teil des detaillierten TOE-Designs beschrieben
werden. Es ist zu beachten, dass ein Modul zwar nur eine Schnittstelle darstellen könnte, es aber häufiger
vorkommt, dass ein Modul eine kleine Menge verwandter Schnittstellen aufweist.
Im Hinblick auf die Beurteilung der Parameter (Eingaben und Ausgaben) eines Moduls muss auch jede
Verwendung von globalen Daten in Betracht gezogen werden. Ein Modul „verwendet“ globale Daten, wenn es
die Daten entweder liest oder schreibt. Um sicherzustellen, dass die Beschreibung solcher Parameter (falls
verwendet) vollständig ist, verwendet der Evaluator andere Informationen, die über das Modul im TOE-Design
zur Verfügung gestellt werden (Schnittstellen, algorithmische Beschreibung usw.), sowie die Beschreibung
der speziellen Menge globaler Daten, die in Workunit ADV_TDS.3-10 beurteilt werden. Beispielsweise könnte
der Evaluator zunächst die Verarbeitung des Moduls bestimmen, indem er seine Funktion und die
dargestellten Schnittstellen (insbesondere die Parameter der Schnittstellen) untersucht. Er könnte dann
prüfen, ob die Verarbeitung anscheinend einen der im TOE-Design identifizierten globalen Datenbereiche
„berührt“. Der Evaluator stellt dann fest, dass für jeden globalen Datenbereich, der „berührt“ zu sein scheint,
dieser globale Datenbereich von dem Modul, das der Evaluator untersucht, als Eingabe- oder Ausgabemittel
aufgeführt wird.
Aufrufkonventionen sind eine Beschreibung vom Typ „Programmierverweisung“, die zum korrekten Aufruf
der Schnittstelle eines Moduls verwendet werden kann, wenn ein Programm geschrieben würde, um die
Funktionalität des Moduls über diese Schnittstelle zu nutzen. Dazu gehören die notwendigen Ein- und Aus-
gaben, einschließlich aller Einstellungen, die im Hinblick auf globale Variablen möglicherweise vorgenommen
werden müssen.
140
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Werte, die über die Schnittstelle zurückgegeben werden, beziehen sich auf Werte, die entweder durch
Parameter oder Nachrichten übergeben werden; Werte, die der Funktionsaufruf selbst in Form eines
„C“-Programmfunktionsaufrufs zurückgibt; oder Werte, die durch globale Mittel übergeben werden (wie
bestimmte Fehlerroutinen in *ix-ähnlichen Betriebssystemen).
Um sicherzustellen, dass die Beschreibung vollständig ist, verwendet der Evaluator andere Informationen, die
über das Modul im TOE-Design zur Verfügung gestellt werden (z. B. algorithmische Beschreibung, verwendete
globale Daten), um sicherzustellen, dass dem Modul alle für die Ausführung der Funktionen des Moduls
erforderlichen Daten vorgelegt werden und dass alle Werte, die andere Module von dem zu prüfenden Modul
erwarten, als vom Modul zurückgegeben identifiziert werden. Der Evaluator stellt die Genauigkeit fest, indem
er sicherstellt, dass die Beschreibung der Verarbeitung mit den Informationen übereinstimmt, die an eine
Schnittstelle oder von einer Schnittstelle übergeben werden.
ISO/IEC 15408-3 ADV_TDS.3.9C: Das Design muss jedes SFR-unterstützende Modul oder SFR-nicht-störende
Modul im Hinblick auf seinen Zweck und seine Interaktion mit anderen Modulen beschreiben.
Der Evaluator muss das TOE-Design untersuchen, um festzustellen, ob SFR-unterstützende und

SFR-nicht-störende Module korrekt eingeteilt sind.
In den Fällen, in denen der Entwickler unterschiedliche Mengen an Informationen für verschiedene Module
bereitgestellt hat, wurde eine implizite Einteilung vorgenommen. Das heißt, Module (zum Beispiel) mit
Einzelheiten zu ihren SFR-bezogenen Schnittstellen (siehe ADV_TDS.3.10C) sind geeignete SFR-unter-
stützende Module, obwohl die Untersuchung durch den Evaluator zu der Feststellung führen kann, dass einige
von ihnen SFR-unterstützend oder SFR-nicht-störend sind. Diejenigen, die nur eine Beschreibung ihres
Zwecks und der Interaktion mit anderen Modulen (zum Beispiel) haben, werden „implizit eingeteilt“ als
SFR-unterstützend oder SFR-nicht-störend.
In diesen Fällen versucht der Evaluator für diese Workunit vor allem, aus den Nachweisen für jedes Modul,
das implizit als SFR-unterstützend oder SFR-nicht-störend eingestuft wird, und aus den Evaluierungs-
informationen über andere Module (im TOE-Design, der Funktionsspezifikation, der Beschreibung der
Sicherheitsarchitektur und der operativen Leitlinien für Benutzer) zu ermitteln, ob das Modul tatsächlich
SFR-unterstützend oder SFR-nicht-störend ist. Auf dieser Vertrauenswürdigkeitsstufe sollten einige Fehler
toleriert werden; der Evaluator muss nicht absolut sicher sein, dass ein bestimmtes Modul SFR-unterstützend
oder SFR-nicht-störend ist, auch wenn es als solches gekennzeichnet ist. Wenn die vorgelegten Nachweise
jedoch darauf hindeuten, dass ein SFR-unterstützendes oder SFR-nicht-störendes Modul SFR-durchsetzend
ist, bittet der Evaluator den Entwickler um zusätzliche Informationen, um die offensichtliche Inkonsistenz zu
beheben. Angenommen, die Dokumentation für Modul A (ein SFR-durchsetzendes Modul) gibt an, dass es
Modul B aufruft, um eine Zugriffsprüfung für einen bestimmten Typ von Konstrukten durchzuführen. Wenn
der Evaluator die mit Modul B verbundenen Informationen untersucht, stellt er fest, dass der Entwickler nur
einen Zweck und eine Menge Interaktionen zur Verfügung gestellt hat (daher wird Modul B implizit als
SFR-unterstützend oder SFR-nicht-störend eingestuft). Bei der Untersuchung des Zwecks und der
Interaktionen von Modul A findet der Evaluator keine Erwähnung von Modul B, das irgendwelche
Zugriffsprüfungen durchführt, und Modul A ist nicht als ein Modul aufgeführt, mit dem Modul B interagiert.
An diesem Punkt sollte der Evaluator an den Entwickler herantreten, um die Diskrepanzen zwischen den in
Modul A und den in Modul B gelieferten Informationen zu beseitigen.
Ein weiteres Beispiel wäre, wenn der Evaluator die Zuordnung der TSFI auf die Module untersucht, wie sie
von ADV_TDS.3.2D bereitgestellt werden. Diese Untersuchung zeigt, dass Modul C mit einer SFR verbunden
ist, die eine Identifizierung des Benutzers erfordert. Auch hier gilt, dass, wenn der Evaluator die mit Modul C
verbundenen Informationen untersucht, er feststellt, dass der Entwickler nur einen Zweck und eine Menge
Interaktionen zur Verfügung gestellt hat (daher wird Modul C implizit als SFR-unterstützend oder
SFR-nicht-störend eingestuft). Bei der Untersuchung des Zwecks und der Interaktionen, die für Modul C
dargestellt wurden, kann der Evaluator nicht feststellen, warum Modul C, das als Zuordnung zu einer TSFI
aufgelistet ist, die sich mit der Benutzeridentifizierung befasst, nicht als SFR-durchsetzend eingestuft werden
würde. Auch hier sollte sich der Evaluator an den Entwickler wenden, um diese Diskrepanz aufzulösen.
141
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Ein letztes Beispiel ist vom entgegengesetzten Standpunkt aus betrachtet. Wie zuvor hat der Entwickler
Informationen im Zusammenhang mit Modul D bereitgestellt, die aus einem Zweck und einer Menge
Interaktionen bestehen (und somit Modul D implizit als SFR-unterstützend oder SFR-nicht-störend einstuft).
Der Evaluator prüft alle vorgelegten Nachweise, einschließlich des Zwecks und der Interaktionen für Modul D.
Der Zweck scheint eine aussagekräftige Beschreibung der Funktion von Modul D im TOE zu sein, die
Interaktionen sind gegenüber dieser Beschreibung konsistent, und nichts deutet darauf hin, dass Modul D
SFR-durchsetzend ist. In diesem Fall sollte der Evaluator keine weiteren Informationen über Modul D
verlangen, „nur um sicherzugehen“, dass es richtig eingestuft ist. Der Entwickler hat seine Verpflichtungen
erfüllt, und die daraus resultierende Vertrauenswürdigkeit, die der Evaluator bei der impliziten Einstufung
von Modul D hat, ist (per Definition) für diese Vertrauenswürdigkeitsstufe angemessen.
SFR-unterstützenden oder SFR-nicht-störenden Moduls vollständig und genau ist.
Die Beschreibung des Zwecks eines Moduls gibt an, welche Funktion das Modul erfüllt. Aus der Beschreibung
sollte der Evaluator in der Lage sein, eine allgemeine Vorstellung von der Rolle des Moduls zu erhalten. Um
sicherzustellen, dass die Beschreibung vollständig ist, verwendet der Evaluator die Informationen über die
Interaktionen des Moduls mit anderen Modulen, um zu beurteilen, ob die Gründe für den Aufruf des Moduls
gegenüber dem Zweck des Moduls konsistent sind. Wenn die Interaktionsbeschreibung eine Funktionalität
enthält, die sich nicht aus dem Zweck des Moduls ergibt oder mit diesem im Widerspruch steht, muss der
Evaluator feststellen, ob es sich um ein Problem der Genauigkeit oder der Vollständigkeit handelt. Der
Evaluator sollte bei zu kurz formulierten Zwecken vorsichtig sein, da eine sinnvolle Analyse auf der Grundlage
eines in einem Satz formulierten Zwecks wahrscheinlich unmöglich ist.
Vollständigkeit und Genauigkeit aus anderen Dokumentationen zu bestimmen, wie z. B. der administrativen
Anleitung, der Funktionsspezifikation, der Beschreibung der Sicherheitsarchitektur oder dem Dokument der
TSF-Interna. Der Evaluator verwendet jedoch die in diesen Dokumenten enthaltenen Informationen im
Rahmen des Möglichen, um sicherzustellen, dass die Funktion genau und vollständig beschrieben wird. Diese
werden, die die TSFI in der Funktionsspezifikation auf die Module der TSF abbildet.
Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass die Beschreibung der Interaktion
eines SFR-unterstützenden oder SFR-nicht-störenden Moduls mit anderen Modulen vollständig und genau ist.
Es ist wichtig zu beachten, dass im Hinblick auf die Anforderung von Teil 3 und diese Workunit der Begriff der
Interaktion weniger streng sein soll als der Begriff Schnittstelle. Eine Interaktion muss nicht auf der
Implementierungsebene charakterisiert werden (z. B. Parameter, die von einer Routine in einem Modul an
eine Routine in einem anderen Modul übergeben werden; globale Variablen; Hardwaresignale (z. B.
bestimmtes Modul identifizierten Datenelemente, die von einem anderen Modul verwendet werden sollen,
sollten in dieser Erörterung behandelt werden. Alle Kontrollbeziehungen zwischen Modulen (z. B. ein Modul,
das für die Konfiguration einer Regelbasis für ein Firewall-System verantwortlich ist, und das Modul, das diese
Regeln tatsächlich umsetzt) sollten ebenfalls beschrieben werden.
Leitlinien für Benutzer, der Funktionsspezifikation, der Beschreibung der Sicherheitsarchitektur oder dem
Dokument der TSF-Interna. Der Evaluator verwendet jedoch die in diesen Dokumenten enthaltenen Informa-
tionen im Rahmen des Möglichen, um sicherzustellen, dass die Funktion genau und vollständig beschrieben
wird. Diese Analyse kann durch die für die Workunits des Elements ADV_TDS.3.10C durchgeführte Analyse
unterstützt werden, die die TSFI in der funktionalen Spezifikation auf die Module der TSF abbildet.
142
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Die Interaktion eines Moduls mit anderen Modulen geht über ein Dokument vom Typ Aufrufbaum hinaus. Die
Interaktion wird aus einer funktionalen Perspektive beschrieben, warum ein Modul mit anderen Modulen
interagiert. Der Zweck des Moduls beschreibt, welche Funktionen das Modul anderen Modulen zur Verfügung
stellt; die Interaktionen sollten beschreiben, worauf das Modul von anderen Modulen angewiesen ist, um diese
Funktion zu erfüllen.
Zuordnung von der in der Funktionsspezifikation beschriebenen TSFI auf die Module der im TOE-Design
Die im TOE-Design beschriebenen Module bieten eine Beschreibung der Implementierung der TSF. Die TSFI
beschreibt, wie die Implementierung durchgeführt wird. Der Nachweis des Entwicklers identifiziert das
Modul, das bei Anfrage einer Operation in der TSFI zunächst aufgerufen wird, und identifiziert die Kette von
Modulen, die bis zu dem Modul aufgerufen werden, das in erster Linie für die Implementierung der
Funktionalität verantwortlich ist. Ein vollständiger „Call Tree“ (Aufrufbaum) ist jedoch nicht für jede TSFI bei
dieser Workunit erforderlich. Die Fälle, in denen mehr als ein Modul identifiziert werden müsste, sind Fälle,
in denen es „Eingangspunkt“-Module oder Wrapper-Module gibt, die keine andere Funktionalität haben als
die Konditionierung von Eingängen oder das Demultiplexen eines Eingangs. Eine Zuordnung zu einem dieser
Module würde dem Evaluator keine nützlichen Informationen liefern.
mindestens ein Modul abgebildet werden. Die Überprüfung der Genauigkeit ist komplexer.
Der erste Aspekt der Genauigkeit besteht darin, dass jede TSFI an der TSF-Grenze auf ein Modul abgebildet
wird. Diese Feststellung kann durch eine Überprüfung der Modulbeschreibung und ihrer Schnittstellen/Inter-
aktionen getroffen werden. Der nächste Aspekt der Genauigkeit ist, dass jede TSFI eine Kette von Modulen
zwischen dem anfänglich identifizierten Modul und einem Modul identifiziert, das in erster Linie für die
Implementierung der bei der TSF vorgestellten Funktion verantwortlich ist. Es ist zu beachten, dass dies das
Anfangsmodul sein kann, oder es kann mehrere Module geben, je nachdem, wie sehr die Eingänge
vorkonditioniert werden. Es sollte beachtet werden, dass ein Indikator für ein Vorkonditionierungsmodul
darin besteht, dass es für eine große Anzahl von TSFIs aufgerufen wird, wobei die TSFIs alle von ähnlichem
Typ sind (z. B. Systemaufruf). Der letzte Aspekt der Genauigkeit ist die Sinnhaftigkeit der Zuordnung.
Beispielsweise ist die Zuordnung einer TSFI, die sich mit der Zugriffskontrolle befasst, zu einem Modul, das
Passwörter überprüft, nicht korrekt. Der Evaluator sollte auch bei dieser Bestimmung sein Urteilsvermögen
einsetzen. Das Ziel ist, dass diese Informationen dem Evaluator helfen, das System und die Implementierung
der SFRs zu verstehen, und die Art und Weise, wie Entitäten an der TSF-Grenze mit der TSF interagieren
können. Der Großteil der Beurteilung, ob die SFRs durch die Module genau beschrieben werden, wird in
anderen Workunits durchgeführt.
Menge Teilsysteme und später zu Modulen führen. Es ist zu beachten, dass diese Zuordnung aufgrund von
Operationen (Zuweisungen, Präzisierungen, Selektionen), die der ST-Autor an der funktionalen Anforderung
vorgenommen hat, möglicherweise in einem Detaillierungsgrad unterhalb der Komponenten- oder sogar
Elementebene der Anforderungen liegen muss.
143
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
auf Module x, y und z des Teilsystems A abbilden; FDP_ACC.1 „Subset access control“ (Regel 2) auf Module x,
p und q des Teilsystems A; usw.

würde der Evaluator zunächst die Teilsysteme und Module identifizieren, die zur Implementierung dieses
Mechanismus beitragen. Dies könnte durch vertieftes Wissen oder Verständnis des TOEs-Designs oder durch
Arbeiten in der vorherigen Workunit geschehen. Es ist zu beachten, dass diese Verfolgung nur dazu dient, die
Teilsysteme und Module zu identifizieren, und nicht die vollständige Analyse darstellt.
Der nächste Schritt wäre zu verstehen, welchen Mechanismus die Teilsysteme und Module implementiert
haben. Wenn das Design beispielsweise eine Implementierung der Zugriffskontrolle auf der Grundlage von
UNIX-ähnlichen Schutzbits beschreibt, wäre das Design keine genaue Instanziierung der im oben verwendeten
ST-Beispiel vorhandenen Zugriffskontrollanforderungen. Wenn der Evaluator aufgrund fehlender Details
nicht feststellen konnte, dass der Mechanismus korrekt umgesetzt wurde, müsste er beurteilen, ob alle
SFR-durchsetzenden Teilsysteme und Module identifiziert wurden oder ob für diese Teilsysteme und Module
ausreichende Details bereitgestellt wurden.
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob das TOE-Design eine Beschreibung des
TOEs in Form von Teilsystemen liefert, die ausreicht, um die TSF-Grenze zu bestimmen, und eine
Beschreibung der TSF-Interna in Form von Modulen (und optional übergeordnete Abstraktionen) liefert. Sie
enthält eine detaillierte Beschreibung der SFR-durchsetzenden und SFR-unterstützenden Module und
genügend Informationen über die SFR-nicht-störenden Module, damit der Evaluator feststellen kann, ob die
SFRs vollständig und genau implementiert sind; das TOE-Design bietet daher eine erläuternde Darstellung der
Implementierung.
10.8.4.2 Eingaben
a) die ST,
d) das TOE-Design.
144
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Es gibt drei Arten von Aufgaben, die der Evaluator in Bezug auf das TOE-Design durchführen muss. Zunächst
stellt der Evaluator fest, dass die TSF-Grenze angemessen beschrieben wurde. Zweitens stellt der Evaluator
fest, dass der Entwickler eine Dokumentation zur Verfügung gestellt hat, die den Anforderungen an Inhalt und
Darstellung dieses Teilsystems entspricht und die gegenüber anderen für den TOE bereitgestellten
Dokumentationen konsistent ist. Schließlich muss der Evaluator die für die SFR-durchsetzenden Module (auf
einer detaillierten Ebene) und die SFR-unterstützenden und SFR-nicht-störenden Module (auf einer weniger
detaillierten Ebene) bereitgestellten Designinformationen analysieren, um zu verstehen, wie das System
implementiert wird, und mit diesem Wissen sicherstellen, dass die TSFIs in der Funktionsspezifikation
angemessen beschrieben sind und dass die Prüfinformationen die TSF (die in den Workunits „Class ATE:
Tests“ erfolgt) angemessen prüft.
Für einen sehr einfachen TOE, der ausschließlich auf der „Modul“-Ebene beschrieben werden kann (siehe
ADV_TDS.4-2), ist diese Workunit nicht anwendbar und gilt daher als erfüllt.
ISO/IEC 15408-3 ADV_TDS.4.2C: Das Design muss die TSF in Form von Modulen beschreiben, wobei jedes Modul
als SFR-durchsetzend, SFR-unterstützend oder SFR-nicht-störend bezeichnet wird.
Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass die gesamte TSF in Form von
Modulen beschrieben wird.
Der Evaluator untersucht die Module auf bestimmte Eigenschaften in anderen Workunits; in dieser Workunit
stellt der Evaluator fest, dass die modulare Beschreibung die gesamte TSF abdeckt und nicht nur einen Teil
der TSF. Der Evaluator stützt sich bei dieser Bestimmung auf andere für die Evaluierung bereitgestellte
Nachweise (z. B. Funktionsspezifikation, Beschreibung der Architektur). Wenn die Funktionsspezifikation
beispielsweise Schnittstellen zu Funktionen enthält, die nicht in der Beschreibung des TOEs-Designs
beschrieben zu sein scheinen, ist es möglich, dass ein Teil der TSF nicht angemessen einbezogen wurde. Diese
Feststellung wird wahrscheinlich ein iterativer Prozess sein, bei dem mit zunehmender Analyse der anderen
Nachweise mehr Vertrauen in die Vollständigkeit der Dokumentation gewonnen werden kann.
145
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Im Gegensatz zu Teilsystemen beschreiben die Module die Implementierung in einem Detaillierungsgrad, der
als Leitfaden für die Überprüfung der Darstellung der Implementierung dienen kann. Eine Beschreibung eines
Moduls sollte so beschaffen sein, dass aus der Beschreibung eine Implementierung des Moduls erstellt werden
könnte, und die resultierende Implementierung wäre 1) identisch mit der tatsächlichen TSF-Implementierung
in Bezug auf die dargestellten Schnittstellen, 2) identisch in der Verwendung von Schnittstellen, die im Design
erwähnt werden, und 3) funktional gleichwertig mit der Beschreibung des Zwecks des TSF-Moduls. Zum
Beispiel bietet RFC 793 eine allgemeine Beschreibung des TCP-Protokolls. Es ist notwendigerweise implemen-
tierungsunabhängig. Es bietet zwar eine Fülle von Details, ist aber keine geeignete Designbeschreibung, da es
nicht spezifisch für eine Implementierung ist. Eine tatsächliche Implementierung kann das im RFC
spezifizierte Protokoll ergänzen, und Implementierungsentscheidungen (z. B. die Verwendung von globalen
Daten im Vergleich zu lokalen Daten in verschiedenen Teilen der Implementierung) können sich auf die
durchgeführte Analyse auswirken. Die Designbeschreibung des TCP-Moduls würde die Schnittstellen
auflisten, die von der Implementierung dargestellt werden (und nicht nur die in RFC 793 definierten), sowie
eine Algorithmusbeschreibung der Verarbeitung, die mit den Modulen, die TCP implementieren, verbunden
ist (vorausgesetzt, sie ist Teil der TSF).
Der Evaluator muss das TOE-Design überprüfen, um festzustellen, ob die TSF-Module entweder als
SFR-durchsetzend, SFR-unterstützend oder SFR-nicht-störend gekennzeichnet sind.
Der Zweck der Bezeichnung jedes Moduls (entsprechend der Rolle, die ein bestimmtes Modul bei der
Durchsetzung der SFRs spielt) besteht darin, den Entwicklern die Möglichkeit zu geben, weniger
Informationen über die Teile der TSF bereitzustellen, die eine geringe Rolle für die Sicherheit spielen. Es ist
immer zulässig, dass der Entwickler mehr Informationen oder Einzelheiten zur Verfügung stellt, als die
Anforderungen verlangen, wie es der Fall sein kann, wenn die Informationen außerhalb des
Evaluierungskontextes gesammelt wurden. In solchen Fällen muss der Entwickler die Module immer noch
entweder als SFR-durchsetzend, SFR-unterstützend oder SFR-nicht-störend kennzeichnen.
Die Richtigkeit dieser Bezeichnungen wird im Laufe der Evaluierung kontinuierlich überprüft. Es geht um die
falsche Bezeichnung von Modulen als weniger bedeutend (und damit weniger Informationen aufweisend), als
dies tatsächlich der Fall ist. Während eklatante Fehlbezeichnungen sofort offensichtlich sein können (z. B. ein
Authentifizierungsmodul als keineswegs SFR-durchsetzend zu bezeichnen, wenn die „User identification“
(FIA_UID) zu den beanspruchten SFRs gehört), können andere Fehlbezeichnungen erst entdeckt werden,
wenn die TSF besser verstanden wird. Der Evaluator muss sich daher vor Augen halten, dass diese
Bezeichnungen zur größten anfänglichen Anstrengung des Entwicklers gehören, sich jedoch ändern können.
Weitere Hinweise sind Workunit ADV_TDS.4-17 zu entnehmen, die die Genauigkeit dieser Bezeichnungen
untersucht.
werden.
Wenn das Design ausschließlich in Form von Modulen dargestellt wird, dann sind Teilsysteme in diesen
Anforderungen den Modulen gleichwertig und die Aufgabe sollte auf der Modulebene durchgeführt werden.
ISO/IEC 15408-3 ADV_TDS.4.4C: Das Design muss eine semiformale Beschreibung jedes Teilsystems der TSF
bereitstellen, die gegebenenfalls durch informellen, erklärenden Text unterstützt wird.
146
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss die TDS-Dokumentation untersuchen, um festzustellen, ob die semiformale Schreibweise,
die zur Beschreibung der Teilsysteme, Module und ihrer Schnittstellen verwendet wird, definiert oder in
Bezug genommen ist.
Eine semiformale Schreibweise kann entweder durch den Antragsteller definiert werden, oder es kann auf
eine entsprechende Norm verwiesen werden. Der Evaluator sollte eine Zuordnung der Sicherheitsfunktionen
und ihrer Schnittstellen erstellen, in der dargelegt wird, in welchem Teil der Dokumentation eine Funktion
oder Schnittstelle semiformal beschrieben ist und welche Schreibweise verwendet wird. Der Evaluator
untersucht alle verwendeten semiformalen Schreibweisen, um sicherzustellen, dass sie einen semiformalen
Stil haben und um die Angemessenheit der Art und Weise zu begründen, wie die semiformalen Schreibweisen
für den TOE verwendet werden.
Der Evaluator wird daran erinnert, dass eine semiformale Darstellung sich durch ein standardisiertes Format
mit einer klar definierten Syntax auszeichnet, die die Mehrdeutigkeit, die bei informellen Darstellungen
auftreten kann, reduziert. Die Syntax aller in der Funktionsspezifikation verwendeten semiformalen Schreib-
weisen muss definiert werden, oder es ist auf eine entsprechende Norm zu verweisen. Der Evaluator
verifiziert, dass die semiformalen Schreibweisen, die zur Darstellung der Funktionsspezifikation verwendet
werden, in der Lage sind, sicherheitsrelevante Merkmale auszudrücken. Um dies festzustellen, kann sich der
Evaluator auf die SFR beziehen und die in der ST und FSP beschriebenen TSF-Sicherheitsmerkmale unter
Verwendung der semiformalen Schreibweisen vergleichen.
Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass jedes Teilsystem der TSF seine Rolle
bei der Durchsetzung der in der ST beschriebenen SFRs beschreibt.
auf Teilsystemebene zu rechtfertigen, besteht das Ziel der Beschreibung auf Teilsystemebene darin, dem
Evaluator einen Kontext für die folgende modulare Beschreibung zu geben. Daher stellt der Evaluator sicher,
dass die Beschreibung auf Teilsystemebene eine Beschreibung darüber enthält, wie die funktionalen
Sicherheitsanforderungen im Design erreicht werden, jedoch auf einer Abstraktionsebene oberhalb der
modularen Beschreibung. Diese Beschreibung sollte die verwendeten Mechanismen auf einer Ebene erörtern,
die mit der Modulbeschreibung abgestimmt ist; dadurch erhalten die Evaluatoren die Roadmap, die für eine
intelligente Beurteilung der in der Modulbeschreibung enthaltenen Informationen erforderlich ist. Eine
wohlformulierte Menge Teilsystembeschreibungen hilft dem Evaluator bei der Bestimmung der Module, die
am wichtigsten für die Untersuchung sind, und konzentriert so die Evaluierungstätigkeit auf die Teile der TSF,
die die größte Relevanz in Bezug auf die Durchsetzung der SFRs haben.
Beschreibung auf die Rolle konzentrieren sollte, die das Teilsystem bei der Durchsetzung oder Unterstützung
der Implementierung der SFRs spielt, müssen genügend Informationen vorhanden sein, damit ein Kontext für
das Verständnis der SFR-bezogenen Funktionalität gegeben ist.
147
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Beschreibung darauf konzentrieren sollte, dass das Teilsystem bei der Durchsetzung oder Unterstützung der
Implementierung der SFRs keine Rolle spielt, müssen genügend Informationen vorhanden sein, damit ein
Kontext für das Verständnis der SFR-nicht-störenden Funktionalität gegeben ist.
Teilsystemen des TSF enthalten.
Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass alle Interaktionen zwischen den
auf Teilsystemebene zu rechtfertigen, soll die Beschreibung der Interaktionen zwischen den Teilsystemen
dazu beitragen, dem Leser ein besseres Verständnis dafür zu vermitteln, wie die TSF ihre Funktionen erfüllt.
Diese Interaktionen müssen nicht auf der Implementierungsebene charakterisiert werden (z. B. Parameter,
die von einer Routine in einem Teilsystem an eine Routine in einem anderen Teilsystem übergeben werden;
globale Variablen; Hardwaresignale (z. B. Interrupts) von einem Hardware-Teilsystem an ein Interrupt-
behandelndes Teilsystem), aber die für ein bestimmtes Teilsystem identifizierten Datenelemente, die von
einem anderen Teilsystem verwendet werden sollen, müssen in dieser Erörterung behandelt werden. Alle
Kontrollbeziehungen zwischen Teilsystemen (z. B. ein Teilsystem, das für die Konfiguration einer Regelbasis
für ein Firewall-System verantwortlich ist, und das Teilsystem, das diese Regeln tatsächlich umsetzt) sollten
ebenfalls beschrieben werden.
werden, dass die Evaluatoren bei der Beurteilung der Vollständigkeit der Beschreibung ihr eigenes
Urteilsvermögen einsetzen müssen. Wenn der Grund für eine Interaktion unklar ist oder wenn es
SFR-bezogene Interaktionen gibt (die z. B. bei der Untersuchung der Dokumentation auf Modulebene entdeckt
werden, und eine vollständige Beschreibung nicht zum Verständnis der Gesamtfunktionalität oder der von der
TSF bereitgestellten Sicherheitsfunktionalität beitragen, kann der Evaluator die Beschreibung als ausreichend
betrachten und nicht um ihrer selbst willen nach Vollständigkeit streben.
ISO/IEC 15408-3 ADV_TDS.4.6C: Das Design muss eine Zuordnung von den Teilsystemen der TSF zu den Modulen
der TSF bereitstellen.
148
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Teilsystemen der TSF und den Modulen der TSF vollständig ist.
Durchführung seiner Beurteilung auf Modulebene. Um die Vollständigkeit festzustellen, untersucht der
Evaluator jede Zuordnung und stellt fest, dass alle Teilsysteme auf mindestens ein Modul abbilden und dass
alle Module auf genau ein Teilsystem abbilden.
Teilsystemen der TSF zu den Modulen der TSF genau ist.
Durchführung seiner Beurteilung auf Modulebene. Der Evaluator kann sich dafür entscheiden, die Genauigkeit
der Zuordnung in Verbindung mit der Durchführung anderer Workunits zu überprüfen. Eine „ungenaue“
Zuordnung ist eine, bei der das Modul fälschlicherweise mit einem Teilsystem verbunden ist, dessen
Funktionen innerhalb des Teilsystems nicht verwendet werden. Da die Zuordnung als Leitfaden zur
Unterstützung einer detaillierteren Analyse gedacht ist, wird der Evaluator darauf hingewiesen, angemessene
Anstrengungen auf diese Workunit aufzubringen. Es ist nicht notwendig, umfangreiche Evaluator-Ressourcen
einzusetzen, um die Genauigkeit der Zuordnung zu überprüfen. Ungenauigkeiten, die zu Missverständnissen
im Zusammenhang mit dem Design führen und im Rahmen dieser oder anderer Workunits aufgedeckt werden,
sollten mit dieser Workunit in Verbindung gebracht und korrigiert werden.
ISO/IEC 15408-3 ADV_TDS.4.7C: Das Design muss jedes SFR-durchsetzende und SFR-unterstützende Modul in
Hinblick auf seinen Zweck und seine Beziehung zu anderen Modulen beschreiben.
SFR-durchsetzenden und SFR-unterstützenden Moduls und der Beziehung zu anderen Modulen vollständig
und genau ist.
liegt es in der Verantwortung des Evaluators, festzustellen, ob die Module über die für ihre Rolle
(SFR-durchsetzend usw.) im TOE geeigneten Informationen verfügen, und die entsprechenden Informationen
vom Entwickler einzuholen, falls der Entwickler die erforderlichen Informationen für ein bestimmtes Modul
nicht zur Verfügung stellt.
149
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Zweck eines Moduls ist die Bereitstellung einer Beschreibung, die angibt, welche Funktion das Modul
erfüllt. Ein entsprechender Hinweis an den Evaluator ist angebracht. Der Schwerpunkt dieser Workunit sollte
darin bestehen, dem Evaluator ein Verständnis für die Funktionsweise des Moduls zu vermitteln, so dass
Entscheidungen über die Fundiertheit der Implementierung der SFRs getroffen werden können, sowie die für
die Teilsysteme ADV_ARC durchgeführte Architekturanalyse zu unterstützen. Solange der Evaluator ein
fundiertes Verständnis der Funktionsweise des Moduls und seiner Beziehung zu anderen Modulen und dem
TOE als Ganzem hat, sollte der Evaluator die Zielsetzung der erreichten Arbeit berücksichtigen und sich nicht
auf eine Dokumentationsübung für den Entwickler einlassen (indem er z. B. eine vollständige algorithmische
Beschreibung für eine selbstverständliche Darstellung der Implementierung verlangt).
Leitlinien für Benutzer, der Funktionsspezifikation, den TSF-Interna oder der Beschreibung der Sicherheits-
architektur. Der Evaluator verwendet jedoch die in diesen Dokumenten enthaltenen Informationen im
Rahmen des Möglichen, um sicherzustellen, dass der Zweck genau und vollständig beschrieben wird. Diese
werden, die die TSFI in der funktionalen Spezifikation auf die Module der TSF abbildet.
ISO/IEC 15408-3 ADV_TDS.4.8C: Das Design muss jedes SFR-durchsetzende und SFR-unterstützende Modul in
Hinblick auf seine SFR-bezogenen Schnittstellen, die Rückgabewerte dieser Schnittstellen, die Interaktion mit
anderen Modulen und die aufgerufenen SFR-bezogenen Schnittstellen zu anderen SFR-durchsetzenden oder
SFR-unterstützenden Modulen beschreiben.
Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass die Beschreibung der von jedem
SFR-durchsetzenden und SFR-unterstützenden Modul dargestellten Schnittstellen eine genaue und
vollständige Beschreibung der SFR-bezogenen Parameter, der Aufrufkonventionen für jede Schnittstelle und
aller direkt von der Schnittstelle zurückgegebenen Werte enthält.
Die SFR-bezogenen Schnittstellen eines Moduls sind diejenigen Schnittstellen, die von anderen Modulen als
Mittel zum Aufrufen der bereitgestellten SFR-bezogenen Operationen und zum Bereitstellen von Eingaben an
das Modul oder zum Empfangen von Ausgaben des Moduls verwendet werden. Der Zweck in der Spezifikation
dieser Schnittstellen ist es, die Ausübung dieser Schnittstellen während der Prüfung zu ermöglichen.
Intermodulschnittstellen, die nicht SFR-bezogen sind, müssen nicht spezifiziert oder beschrieben werden, da
sie kein Faktor beim Prüfen sind. Ebenso andere interne Schnittstellen, die kein Faktor beim Durchlaufen von
SFR-bezogenen Ausführungspfaden sind (wie z. B. jene internen Pfade, die festgelegt sind).
SFR-bezogene Schnittstellen von SFR-unterstützenden Modulen sind alle Schnittstellen von SFR-unter-
stützenden Modulen, die direkt oder indirekt von SFR-durchsetzenden Modulen aufgerufen werden. Diese
Schnittstellen müssen mit allen in einem solchen Aufruf verwendeten Parametern beschrieben werden. Dies
ermöglicht es dem Evaluator, den Zweck der Aufforderung an das SFR-unterstützende Modul im
Zusammenhang mit dem Betrieb der SFR-durchsetzenden Module zu verstehen.
SFR-bezogene Schnittstellen werden in Bezug darauf beschrieben, wie sie aufgerufen werden und welche
Werte zurückgegeben werden. Diese Beschreibung würde eine Liste von Parametern und Beschreibungen
dieser Parameter enthalten. Es ist zu beachten, dass globale Daten auch als Parameter betrachtet werden,
wenn sie beim Aufruf des Moduls (entweder als Ein- oder Ausgänge) verwendet werden. Wenn von einem
Parameter erwartet würde, dass er eine Menge Werte annimmt (z. B. einen „Flag“-Parameter), würde die
vollständige Menge Werte angegeben, die der Parameter annehmen könnte und die sich auf die
Modulverarbeitung auswirken würden. Ebenso werden Parameter, die Datenstrukturen darstellen, so
beschrieben, dass jedes Feld der Datenstruktur identifiziert und beschrieben wird. Es ist zu beachten, dass
verschiedene Programmiersprachen zusätzliche „Schnittstellen“ haben können, die nicht offensichtlich
wären; ein Beispiel wäre die Überlastung von Operatoren/Funktionen in C++. Diese „implizite Schnittstelle“
in der Klassenbeschreibung würde auch als Teil des detaillierten TOE-Designs beschrieben werden. Es ist zu
beachten, dass ein Modul zwar nur eine Schnittstelle darstellen könnte, es aber häufiger vorkommt, dass ein
Modul eine kleine Menge verwandter Schnittstellen aufweist.
150
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Im Hinblick auf die Beurteilung der Parameter (Eingaben und Ausgaben) eines Moduls muss auch jede
Verwendung von globalen Daten in Betracht gezogen werden. Ein Modul „verwendet“ globale Daten, wenn es
die Daten entweder liest oder schreibt. Um sicherzustellen, dass die Beschreibung solcher Parameter (falls
verwendet) vollständig ist, verwendet der Evaluator andere Informationen, die über das Modul im TOE-Design
zur Verfügung gestellt werden (Schnittstellen, algorithmische Beschreibung usw.), sowie die Beschreibung
der speziellen Menge globaler Daten, die in Workunit ADV_TDS.4-12 beurteilt werden. Beispielsweise könnte
der Evaluator zunächst die Verarbeitung des Moduls bestimmen, indem er seine Funktion und die
dargestellten Schnittstellen (insbesondere die Parameter der Schnittstellen) untersucht. Er könnte dann
prüfen, ob die Verarbeitung anscheinend einen der im TDS-Design identifizierten globalen Datenbereiche
„berührt“. Der Evaluator stellt dann fest, dass für jeden globalen Datenbereich, der „berührt“ zu sein scheint,
dieser globale Datenbereich von dem Modul, das der Evaluator untersucht, als Eingabe- oder Ausgabemittel
aufgeführt wird.
Aufrufkonventionen sind eine Beschreibung vom Typ „Programmierverweisung“, die zum korrekten Aufruf
der Schnittstelle eines Moduls verwendet werden kann, wenn ein Programm geschrieben würde, um die
Funktionalität des Moduls über diese Schnittstelle zu nutzen. Dazu gehören die notwendigen Ein- und
Ausgaben, einschließlich aller Einstellungen, die im Hinblick auf globale Variablen möglicherweise
vorgenommen werden müssen.
Werte, die über die Schnittstelle zurückgegeben werden, beziehen sich auf Werte, die entweder durch
Parameter oder Nachrichten übergeben werden; Werte, die der Funktionsaufruf selbst in Form eines
„C“-Programmfunktionsaufrufs zurückgibt; oder Werte, die durch globale Mittel übergeben werden (wie
bestimmte Fehlerroutinen in *ix-ähnlichen Betriebssystemen).
Um sicherzustellen, dass die Beschreibung vollständig ist, verwendet der Evaluator andere Informationen, die
über das Modul im TOE-Design zur Verfügung gestellt werden (z. B. algorithmische Beschreibung, verwendete
globale Daten), um sicherzustellen, dass dem Modul alle für die Ausführung der Funktionen des Moduls
erforderlichen Daten vorgelegt werden und dass alle Werte, die andere Module von dem zu prüfenden Modul
erwarten, als vom Modul zurückgegeben identifiziert werden. Der Evaluator stellt die Genauigkeit fest, indem
er sicherstellt, dass die Beschreibung der Verarbeitung mit den Informationen übereinstimmt, die an eine
Schnittstelle oder von einer Schnittstelle übergeben werden.
ISO/IEC 15408-3 ADV_TDS.4.9C: Das Design muss jedes SFR-nicht-störende Modul im Hinblick auf seinen Zweck
und seine Interaktion mit anderen Modulen beschreiben.
Der Evaluator muss das TOE-Design untersuchen, um festzustellen, ob SFR-nicht-störende Module korrekt
eingeteilt sind.
Wie in Workunit ADV_TDS.4-2 erwähnt, werden weniger Informationen über Module benötigt, die
SFR-nicht-störend sind. Ein Hauptaugenmerk des Evaluators für diese Workunit liegt auf dem Versuch, aus
den Nachweisen für jedes Modul, das implizit als SFR-nicht-störend eingestuft wird, und der Evaluierung
(Informationen über andere Module im TOE-Design, die Funktionsspezifikation, die Beschreibung der
Sicherheitsarchitektur, die operativen Leitlinien für Benutzer, das Dokument der TSF-Interna und vielleicht
sogar die Darstellung der Implementierung) zu ermitteln, ob das Modul tatsächlich SFR-nicht-störend ist. Auf
dieser Vertrauenswürdigkeitsstufe sollten einige Fehler toleriert werden; der Evaluator muss nicht absolut
sicher sein, dass ein bestimmtes Modul SFR-nicht-störend ist, auch wenn es als solches gekennzeichnet ist.
Wenn die vorgelegten Nachweise jedoch darauf hindeuten, dass ein SFR-nicht-störendes Modul
SFR-durchsetzend oder SFR-unterstützend ist, bittet der Evaluator den Entwickler um zusätzliche
Informationen, um die offensichtliche Inkonsistenz zu beheben. Angenommen, die Dokumentation für
Modul A (ein SFR-durchsetzendes Modul) gibt beispielsweise an, dass es Modul B aufruft, um eine
Zugriffsprüfung für einen bestimmten Typ von Konstrukten durchzuführen. Wenn der Evaluator die mit
Modul B verbundenen Informationen untersucht, stellt er fest, dass die einzigen Informationen, die der
Entwickler zur Verfügung gestellt hat, ein Zweck und eine Menge Interaktionen sind (daher wird Modul B
implizit als SFR-unterstützend oder SFR-nicht-störend eingestuft). Bei der Untersuchung des Zwecks und der
151
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Interaktionen von Modul A findet der Evaluator keine Erwähnung von Modul B, das irgendwelche
Zugriffsprüfungen durchführt, und Modul A ist nicht als ein Modul aufgeführt, mit dem Modul B interagiert.
An diesem Punkt sollte der Evaluator an den Entwickler herantreten, um die Diskrepanzen zwischen den in
Modul A und den in Modul B gelieferten Informationen zu beseitigen.
Ein weiteres Beispiel wäre, wenn der Evaluator die Zuordnung der TSFI auf die Module untersucht, wie sie
von ADV_TDS.4.2D bereitgestellt werden. Diese Untersuchung zeigt, dass Modul C mit einer SFR verbunden
ist, die eine Identifizierung des Benutzers erfordert. Auch hier gilt, dass, wenn der Evaluator die mit Modul C
verbundenen Informationen untersucht, er feststellt, dass der Entwickler nur einen Zweck und eine Menge
Interaktionen zur Verfügung gestellt hat (daher wird Modul C implizit als SFR-nicht-störend eingestuft). Bei
der Untersuchung des Zwecks und der Interaktionen, die für Modul C dargestellt wurden, kann der Evaluator
nicht feststellen, warum Modul C, das als Zuordnung zu einer TSFI aufgelistet ist, die sich mit der
Benutzeridentifizierung befasst, nicht als SFR-durchsetzend oder SFR-unterstützend eingestuft würde. Auch
hier sollte sich der Evaluator an den Entwickler wenden, um diese Diskrepanz aufzulösen.
Ein letztes Beispiel veranschaulicht die gegenteilige Situation. Wie zuvor hat der Entwickler Informationen im
Zusammenhang mit Modul D bereitgestellt, die aus einem Zweck und einer Menge Interaktionen bestehen
(und somit Modul D implizit als SFR-nicht-störend einstuft). Der Evaluator prüft alle vorgelegten Nachweise,
einschließlich des Zwecks und der Interaktionen für Modul D. Der Zweck scheint eine aussagekräftige Be-
schreibung der Funktion von Modul D im TOE zu sein, die Interaktionen sind gegenüber dieser Beschreibung
konsistent, und nichts deutet darauf hin, dass Modul D SFR-durchsetzend oder SFR-unterstützend ist. In
diesem Fall sollte der Evaluator keine weiteren Informationen über Modul D verlangen, „nur um
sicherzugehen“, dass es richtig eingestuft ist. Der Entwickler hat die Verpflichtungen erfüllt, und die daraus
resultierende Vertrauenswürdigkeit, die der Evaluator bei der impliziten Einstufung von Modul D hat, ist (per
Definition) für diese Vertrauenswürdigkeitsstufe angemessen.
SFR-nicht-störenden Moduls vollständig und genau ist.
Die Beschreibung des Zwecks eines Moduls gibt an, welche Funktion das Modul erfüllt. Aus der Beschreibung
sollte der Evaluator in der Lage sein, eine allgemeine Vorstellung von der Rolle des Moduls zu erhalten. Um
sicherzustellen, dass die Beschreibung vollständig ist, verwendet der Evaluator die Informationen über die
Interaktionen des Moduls mit anderen Modulen, um zu beurteilen, ob die Gründe für den Aufruf des Moduls
gegenüber dem Zweck des Moduls konsistent sind. Wenn die Interaktionsbeschreibung eine Funktionalität
enthält, die sich nicht aus dem Zweck des Moduls ergibt oder mit diesem im Widerspruch steht, muss der
Evaluator feststellen, ob es sich um ein Problem der Genauigkeit oder der Vollständigkeit handelt. Der
Evaluator sollte bei zu kurz formulierten Zwecken vorsichtig sein, da eine sinnvolle Analyse auf der Grundlage
eines in einem Satz formulierten Zwecks wahrscheinlich unmöglich ist.
Dokument der TSF-Interna. Der Evaluator verwendet jedoch die in diesen Dokumenten enthaltenen
Informationen im Rahmen des Möglichen, um sicherzustellen, dass die Funktion genau und vollständig be-
schrieben wird. Diese Analyse kann durch die für die Workunits des Elements ADV_TDS.4.10C durchgeführte
Analyse unterstützt werden, die die TSFI in der funktionalen Spezifikation auf die Module der TSF abbildet.
152
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass die Beschreibung der Interaktion
eines SFR-nicht-störenden Moduls mit anderen Modulen vollständig und genau ist.
Es ist wichtig zu beachten, dass im Hinblick auf die Anforderung von Teil 3 und diese Workunit der Begriff der
Interaktion weniger streng sein soll als der Begriff Schnittstelle. Eine Interaktion muss nicht auf der
Implementierungsebene charakterisiert werden (z. B. Parameter, die von einer Routine in einem Modul an
eine Routine in einem anderen Modul übergeben werden; globale Variablen; Hardwaresignale (z. B.
bestimmtes Modul identifizierten Datenelemente, die von einem anderen Modul verwendet werden sollen,
sollten in dieser Erörterung behandelt werden. Alle Kontrollbeziehungen zwischen Modulen (z. B. ein Modul,
das für die Konfiguration einer Regelbasis für ein Firewall-System verantwortlich ist, und das Modul, das diese
Regeln tatsächlich umsetzt) sollten ebenfalls beschrieben werden.
Die Interaktion eines Moduls mit anderen Modulen kann auf viele Arten erfasst werden. Die Absicht für das
TOE-Design ist es, dem Evaluator zu ermöglichen, (teilweise durch Analyse der Modulinteraktionen) die Rolle
der SFR-unterstützenden und SFR-nicht-störenden Module im Gesamtdesign des TOEs zu verstehen. Das
Verständnis dieser Rolle wird dem Evaluator bei der Durchführung der Workunit ADV_TDS.4-8 helfen.
Die Interaktion eines Moduls mit anderen Modulen geht über ein Dokument vom Typ Aufrufbaum hinaus. Die
Interaktion wird aus einer funktionalen Perspektive beschrieben, warum ein Modul mit anderen Modulen
interagiert. Der Zweck des Moduls beschreibt, welche Funktionen das Modul anderen Modulen zur Verfügung
stellt; die Interaktionen sollten beschreiben, worauf das Modul von anderen Modulen angewiesen ist, um diese
Funktion zu erfüllen.
Dokument der TSF-Interna. Der Evaluator verwendet jedoch die in diesen Dokumenten enthaltenen
Informationen im Rahmen des Möglichen, um sicherzustellen, dass die Interaktionen genau und vollständig
beschrieben werden.
Zuordnung von der in der Funktionsspezifikation beschriebenen TSFI auf die Module der im TOE-Design
Die im TOE-Design beschriebenen Module bieten eine Beschreibung der Implementierung der TSF. Die TSFI
beschreibt, wie die Implementierung durchgeführt wird. Der Nachweis des Entwicklers identifiziert das
Modul, das bei der Anfrage einer Operation bei der TSFI zunächst aufgerufen wird, und identifiziert die Kette
von Modulen, die bis zu dem Modul aufgerufen werden, das in erster Linie für die Implementierung der
Funktionalität verantwortlich ist. Ein vollständiger „Call Tree“ (Aufrufbaum) ist jedoch nicht für jede TSFI bei
dieser Workunit erforderlich. Die Fälle, in denen mehr als ein Modul identifiziert werden müsste, sind Fälle,
in denen es „Eingangspunkt“-Module oder Wrapper-Module gibt, die keine andere Funktionalität haben als
die Konditionierung von Eingängen oder das Demultiplexen eines Eingangs. Eine Zuordnung zu einem dieser
Module würde dem Evaluator keine nützlichen Informationen liefern.
mindestens ein Modul abgebildet werden. Die Überprüfung der Genauigkeit ist komplexer.
153
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der erste Aspekt der Genauigkeit besteht darin, dass jede TSFI an der TSF-Grenze auf ein Modul abgebildet
wird. Diese Feststellung kann durch eine Überprüfung der Modulbeschreibung und ihrer Schnittstellen/Inter-
aktionen getroffen werden. Der nächste Aspekt der Genauigkeit ist, dass jede TSFI eine Kette von Modulen
zwischen dem anfänglich identifizierten Modul und einem Modul identifiziert, das in erster Linie für die
Implementierung der bei der TSF vorgestellten Funktion verantwortlich ist. Es ist zu beachten, dass dies das
Anfangsmodul sein kann, oder es kann mehrere Module geben, je nachdem, wie sehr die Eingänge
vorkonditioniert werden. Es sollte beachtet werden, dass ein Indikator für ein Vorkonditionierungsmodul
darin besteht, dass es für eine große Anzahl von TSFIs aufgerufen wird, wobei die TSFIs alle von ähnlichem
Typ sind (z. B. Systemaufruf). Der letzte Aspekt der Genauigkeit ist die Sinnhaftigkeit der Zuordnung.
Beispielsweise ist die Zuordnung einer TSFI, die sich mit der Zugriffskontrolle befasst, zu einem Modul, das
Passwörter überprüft, nicht korrekt. Der Evaluator sollte auch bei dieser Bestimmung sein Urteilsvermögen
einsetzen. Das Ziel ist, dass diese Informationen dem Evaluator helfen, das System und die Implementierung
der SFRs zu verstehen, und die Art und Weise, wie Entitäten an der TSF-Grenze mit der TSF interagieren
können. Der Großteil der Beurteilung, ob die SFRs durch die Module genau beschrieben werden, wird in
anderen Workunits durchgeführt.
Menge Teilsysteme und später zu Modulen führen. Es ist zu beachten, dass diese Zuordnung aufgrund von
Operationen (Zuweisungen, Präzisierungen, Selektionen), die der ST-Autor an der funktionalen Anforderung
vorgenommen hat, möglicherweise in einem Detaillierungsgrad unterhalb der Komponenten- oder sogar
Elementebene der Anforderungen liegen muss.
auf Module x, y und z des Teilsystems A abbilden; FDP_ACC.1 „Subset access control“ (Regel 2) auf x, p und q
des Teilsystems A; usw.

würde der Evaluator zunächst die Teilsysteme und Module identifizieren, die zur Implementierung dieses
Mechanismus beitragen. Dies könnte durch vertieftes Wissen oder Verständnis des TOEs-Designs oder durch
Arbeiten in der vorherigen Workunit geschehen. Es ist zu beachten, dass diese Verfolgung nur dazu dient, die
Teilsysteme und Module zu identifizieren, und nicht die vollständige Analyse darstellt.
154
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der nächste Schritt wäre zu verstehen, welchen Mechanismus die Teilsysteme und Module implementiert
haben. Wenn das Design beispielsweise eine Implementierung der Zugriffskontrolle auf der Grundlage von
UNIX-ähnlichen Schutzbits beschreibt, wäre das Design keine genaue Instanziierung der im oben verwendeten
ST-Beispiel vorhandenen Zugriffskontrollanforderungen. Wenn der Evaluator aufgrund fehlender Details
nicht feststellen konnte, dass der Mechanismus korrekt umgesetzt wurde, müsste er beurteilen, ob alle
SFR-durchsetzenden Teilsysteme und Module identifiziert wurden oder ob für diese Teilsysteme und Module
ausreichende Details bereitgestellt wurden.
11 Klasse AGD: Leitliniendokumente

11.1 Einleitung
Der Zweck der Aufgabe des Leitliniendokuments besteht darin, die Angemessenheit der Dokumentation zu
beurteilen, die beschreibt, wie der Benutzer den TOE auf sichere Weise handhaben kann. Eine solche
Dokumentation sollte die verschiedenen Arten von Benutzern (z. B. diejenigen, die den TOE akzeptieren,
installieren, verwalten oder betreiben) berücksichtigen, deren fehlerhafte Aktionen die Sicherheit des TOEs
oder ihrer eigenen Daten nachteilig beeinflussen könnten.
Die Klasse der Leitliniendokumente ist in zwei Familien unterteilt, die sich erstens mit den vorbereitenden
Verfahren (alles, was getan werden muss, um den gelieferten TOE in seine evaluierte Konfiguration in der in
der ST beschriebenen Umgebung zu transformieren, d. h. Annahme und Installation des TOEs) und zweitens
mit den operativen Leitlinien für Benutzer (alles, was während des Betriebs des TOEs in seiner evaluierten
Konfiguration, d. h. Betrieb und Verwaltung, getan werden muss) befassen.
Die Aufgabe des Leitliniendokuments bezieht sich auf diejenigen Funktionen und Schnittstellen, die sich auf
die Sicherheit des TOEs beziehen. Die sichere Konfiguration des TOEs wird in der ST beschrieben.
11.3 Operative Leitlinien für Benutzer (AGD_OPE)

11.3.1 Evaluierung der Unteraufgabe (AGD_OPE.1)
Die Zielsetzungen dieser Unteraufgabe bestehen darin, festzustellen, ob die Leitlinien für Benutzer für jede
Benutzerrolle die von der TSF bereitgestellten Sicherheitsfunktionen und Schnittstellen beschreibt,
Anweisungen und Leitlinien für die sichere Verwendung des TOEs enthält, sichere Verfahren für alle
Betriebsarten behandelt, die Verhütung und Aufdeckung unsicherer TOE-Zustände erleichtert oder ob sie
irreführend oder unangemessen ist.
11.3.1.2 Eingaben
a) die ST,
c) das TOE-Design, falls zutreffend,
d) die Leitlinien für Benutzer.
155
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
11.3.1.3 Aktion AGD_OPE.1.1E
ISO/IEC 15408-3 AGD_OPE.1.1C: Die operativen Leitlinien für Benutzer müssen für jede Benutzerrolle die für
den Benutzer zugänglichen Funktionen und Berechtigungen beschreiben, die in einer sicheren Verarbeitungs-
umgebung kontrolliert werden sollten, einschließlich angemessener Warnungen.
11.3.1.3.1 Workunit AGD_OPE.1-1
Der Evaluator muss die operativen Leitlinien für Benutzer untersuchen, um festzustellen, dass sie für jede
Benutzerrolle die für den Benutzer zugänglichen Funktionen und Berechtigungen beschreibt, die in einer
sicheren Verarbeitungsumgebung kontrolliert werden sollten, einschließlich geeigneter Warnungen.
Die Konfiguration des TOEs kann es verschiedenen Benutzerrollen erlauben, unterschiedliche Berechtigungen
bei der Nutzung der verschiedenen Funktionen des TOEs zu haben. Dies bedeutet, dass einige Benutzer zur
Ausführung bestimmter Funktionen berechtigt sind, während andere Benutzer möglicherweise nicht dazu
berechtigt sind. Diese Funktionen und Berechtigungen sollten für jede Benutzerrolle durch die Leitlinien für
Benutzer beschrieben werden.
Die Leitlinien für Benutzer geben für jede Benutzerrolle an, welche Funktionen und Berechtigungen
kontrolliert werden müssen, welche Arten von Befehlen dafür erforderlich sind und die Gründe für solche
Befehle. Die Leitlinien für Benutzer sollten Warnungen bezüglich der Verwendung dieser Funktionen und
Berechtigungen enthalten. Warnungen sollten die erwarteten Auswirkungen, mögliche Nebenwirkungen und
mögliche Interaktionen mit anderen Funktionen und Berechtigungen ansprechen.
ISO/IEC 15408-3 AGD_OPE.1.2C: Die operativen Leitlinien für Benutzer müssen für jede Benutzerrolle
beschreiben, wie die vom TOE zur Verfügung gestellten Schnittstellen auf sichere Art und Weise genutzt werden.
Benutzerrolle die sichere Verwendung der vom TOE bereitgestellten verfügbaren Schnittstellen beschreiben.
Die Leitlinien für Benutzer sollten Hinweise zur effektiven Nutzung der TSF enthalten (z. B. Überprüfung der
Praxis der Passwort-Zusammenstellung, vorgeschlagene Häufigkeit von Benutzerdatei-Backups, Erörterung
der Auswirkungen der Änderung von Benutzerzugriffsberechtigungen).
ISO/IEC 15408-3 AGD_OPE.1.3C: Die operativen Leitlinien für Benutzer müssen für jede Benutzerrolle die
verfügbaren Funktionen und Schnittstellen beschreiben, insbesondere alle Sicherheitsparameter unter der
Kontrolle des Benutzers, wobei gegebenenfalls sichere Werte angegeben werden.
Benutzerrolle die verfügbaren Sicherheitsfunktionen und Schnittstellen beschreiben, insbesondere alle
Sicherheitsparameter unter der Kontrolle des Benutzers, wobei gegebenenfalls sichere Werte angegeben
werden.
Die Leitlinien für Benutzer sollten einen Überblick über die Sicherheitsfunktionalität enthalten, die auf den
Benutzeroberflächen sichtbar ist.
Die Leitlinien für Benutzer sollten den Zweck, das Verhalten und die Zusammenhänge der Sicherheits-
schnittstellen und -funktionalität identifizieren und beschreiben.
156
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Für jede für den Benutzer zugängliche Schnittstelle sollte Folgendes in den Leitlinien für Benutzer enthalten
sein:
a) Beschreibung des/r Verfahren, mit dem/denen die Schnittstelle aufgerufen wird (z. B. Befehlszeile,
programmiersprachlicher Systemaufruf, Menüauswahl, Befehlsschaltfläche);
b) Beschreibung der vom Benutzer einzustellenden Parameter, ihre besonderen Zwecke, gültige und
voreingestellte Werte sowie sichere und unsichere Nutzungseinstellungen solcher Parameter, sowohl
einzeln als auch in Kombination;
c) Beschreibung der unmittelbaren TSF-Antwort, der Nachricht oder des zurückgegebenen Codes.
Der Evaluator sollte die Funktionsspezifikation und die ST berücksichtigen, um festzustellen, ob die in diesen
Dokumenten beschriebene TSF gegenüber den operativen Leitlinien für Benutzer konsistent ist. Der Evaluator
muss sicherstellen, dass die operativen Leitlinien für Benutzer vollständig sind, um die sichere Nutzung durch
die TSFI zu ermöglichen, die allen Arten von menschlichen Benutzern zur Verfügung steht. Der Evaluator kann
als Hilfsmittel eine informelle Zuordnung zwischen den Leitlinien für Benutzer und diesen Dokumenten
erstellen. Jegliche Auslassungen in dieser Zuordnung können auf Unvollständigkeit hinweisen.
ISO/IEC 15408-3 AGD_OPE.1.4C: Die operativen Leitlinien für Benutzer müssen für jede Benutzerrolle deutlich
jede Art von sicherheitsrelevanten Ereignissen in Bezug auf die vom Benutzer zugänglichen Funktionen, die
ausgeführt werden müssen, darstellen, einschließlich Änderung der Sicherheitsmerkmale von Entitäten, die von
der TSF kontrolliert werden.
Benutzerrolle jede Art von sicherheitsrelevanten Ereignissen in Bezug auf die auszuführenden
Benutzerfunktionen beschreiben, einschließlich der Änderung der Sicherheitsmerkmale von Entitäten unter
der Kontrolle der TSF und des Betriebs nach einem Ausfall oder Betriebsfehler.
Alle Arten von sicherheitsrelevanten Ereignissen werden für jede Benutzerrolle detailliert aufgeführt, so dass
jeder Benutzer weiß, welche Ereignisse auftreten können und welche Aktion (wenn überhaupt) er
gegebenenfalls ergreifen muss, um die Sicherheit aufrechtzuerhalten. Sicherheitsrelevante Ereignisse, die
während des Betriebs des TOEs auftreten können (z. B. Audit-Trail-Überlauf, Systemabsturz, Aktualisierungen
von Benutzeraufzeichnungen, z. B. wenn ein Benutzerkonto entfernt wird, wenn der Benutzer die
Organisation verlässt), sind ausreichend definiert, um ein Eingreifen des Benutzers zur Aufrechterhaltung des
sicheren Betriebs zu ermöglichen.
ISO/IEC 15408-3 AGD_OPE.1.5C: Die operativen Leitlinien für Benutzer müssen alle möglichen Betriebsarten des
TOEs (einschließlich des Betriebs nach Ausfall oder Betriebsfehler), ihre Konsequenzen und Auswirkungen auf die
Aufrechterhaltung eines sicheren Betriebs identifizieren.
Der Evaluator muss die operativen Leitlinien für Benutzer und andere Evaluationsnachweise untersuchen,
um festzustellen, dass die Leitlinien für Benutzer alle möglichen Betriebsarten des TOEs (einschließlich, falls
zutreffend, des Betriebs nach einem Ausfall oder Betriebsfehler), ihre Konsequenzen und Auswirkungen auf
die Aufrechterhaltung eines sicheren Betriebs aufzeigen.
Andere Evaluationsnachweise, insbesondere die Funktionsspezifikation, stellen eine Informationsquelle dar,

die der Evaluator verwenden sollte, um festzustellen, ob die Leitlinien für Benutzer ausreichende
Anleitungsinformationen enthalten.
Wenn die Prüfdokumentation im Sicherheitspaket enthalten ist, dann können die in diesen Nachweisen
enthaltenen Informationen auch dazu verwendet werden, um festzustellen, ob die Leitlinien für Benutzer eine
ausreichende Dokumentation enthalten. Die in den Prüfschritten zur Verfügung gestellten Details können
verwendet werden, um zu bestätigen, dass die bereitgestellte Anleitung für die Verwendung und Verwaltung
des TOEs ausreichend ist.
157
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator sollte sich jeweils auf eine einzelne sichtbare TSFI beim Menschen konzentrieren und die
Anleitung für die sichere Verwendung der TSFI mit anderen Evaluationsnachweisen vergleichen, um
festzustellen, ob die Leitlinien in Bezug auf die TSFI für die sichere Verwendung (d. h. konsistent gegenüber
den SFRs) dieser TSFI ausreichend sind. Der Evaluator sollte auch die Beziehungen zwischen den
Schnittstellen berücksichtigen und nach potentiellen Widersprüchen suchen.
ISO/IEC 15408-3 AGD_OPE.1.6C: Die operativen Leitlinien für Benutzer müssen für jede Benutzerrolle die
Sicherheitsmaßnahmen beschreiben, die zur Erfüllung der in der ST beschriebenen Sicherheitszielsetzungen für
die Betriebsumgebung zu befolgen sind.
Benutzerrolle die Sicherheitsmaßnahmen beschreibt, die zur Erfüllung der in der ST beschriebenen
Sicherheitszielsetzungen für die Betriebsumgebung zu befolgen sind.
Der Evaluator analysiert die Sicherheitszielsetzungen für die Betriebsumgebung in der ST und stellt fest, dass
für jede Benutzerrolle die relevanten Sicherheitsmaßnahmen in den Leitlinien für Benutzer angemessen
beschrieben sind.
Die in den Leitlinien für Benutzer beschriebenen Sicherheitsmaßnahmen sollten alle relevanten externen
prozeduralen, physischen, personellen und konnektiven Maßnahmen umfassen.
Es ist zu beachten, dass die Maßnahmen, die für eine sichere Installation des TOEs relevant sind, in den
„Preparative procedures“ (AGD_PRE) untersucht werden.
ISO/IEC 15408-3 AGD_OPE.1.7C: Die operativen Leitlinien für Benutzer müssen klar und angemessen sein.
Der Evaluator muss die operativen Leitlinien für Benutzer untersuchen, um festzustellen, ob sie klar sind.
Die Leitlinien für Benutzer sind unklar, wenn sie von einem Administrator oder Benutzer aller Voraussicht
nach falsch ausgelegt und in einer Weise verwendet werden können, die dem TOE oder der vom TOE
gebotenen Sicherheit abträglich ist.
Der Evaluator muss die operativen Leitlinien für Benutzer untersuchen, um festzustellen, ob sie
nachvollziehbar sind.
Die Leitlinien für Benutzer sind unangemessen, wenn sie Anforderungen an die Verwendung oder die
Betriebsumgebung des TOEs stellen, die gegenüber der ST nicht konsistent oder für die Aufrechterhaltung der
Sicherheit unangemessen belastend sind.
11.4 Vorbereitende Verfahren (AGD_PRE)
11.4.1 Evaluierung der Unteraufgabe (AGD_PRE.1)
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob die Verfahren und Schritte für die sichere
Vorbereitung des TOEs dokumentiert wurden und zu einer sicheren Konfiguration führen.
158
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
11.4.1.2 Eingaben
a) die ST,
b) der TOE einschließlich seiner vorbereitenden Verfahren,
c) die Beschreibung der Lieferverfahren des Entwicklers, falls zutreffend.
Die vorbereitenden Verfahren beziehen sich auf alle Abnahme- und Installationsverfahren, die notwendig
sind, um den TOE zur sicheren Konfiguration, wie in der ST beschrieben, weiterzuentwickeln.
11.4.1.4 Aktion AGD_PRE.1.1E
ISO/IEC 15408-3 AGD_PRE.1.1C: Die vorbereitenden Verfahren müssen alle Schritte beschreiben, die für eine
sichere Abnahme des gelieferten TOEs in Übereinstimmung mit den Lieferverfahren des Entwicklers erforderlich
sind.
11.4.1.4.1 Workunit AGD_PRE.1-1
Der Evaluator muss die vorgesehenen Abnahmeverfahren untersuchen, um festzustellen, dass sie die für eine
sichere Abnahme des TOEs in Übereinstimmung mit den Lieferverfahren des Entwicklers erforderlichen
Schritte beschreiben.
Wenn die Lieferverfahren des Entwicklers nicht vorsehen, dass Abnahmeverfahren angewendet werden oder
angewendet werden können, ist diese Workunit nicht anwendbar und gilt daher als erfüllt.
Die Abnahmeverfahren sollten mindestens beinhalten, dass der Benutzer zu prüfen hat, ob alle Teile des TOEs,
wie in der ST angegeben, in der richtigen Version geliefert wurden.
Die Abnahmeverfahren sollten die Schritte widerspiegeln, die der Benutzer durchführen muss, um den
gelieferten TOE zu akzeptieren, und die in den Lieferverfahren des Entwicklers implizit enthalten sind.
Die Abnahmeverfahren sollten, falls zutreffend, detaillierte Informationen über die folgenden Punkte
enthalten:
a) Sicherstellung, dass der gelieferte TOE die vollständige evaluierte Instanz ist;
b) Erkennung von Modifikation/Masquerading des gelieferten TOE.
ISO/IEC 15408-3 AGD_PRE.1.2C: Die vorbereitenden Verfahren müssen alle Schritte beschreiben, die für eine
sichere Installation des TOEs und für die sichere Vorbereitung der Betriebsumgebung in Übereinstimmung mit
den in der ST beschriebenen Sicherheitszielsetzungen für die Betriebsumgebung erforderlich sind.
Der Evaluator muss die bereitgestellten Installationsverfahren untersuchen, um festzustellen, ob sie die
Schritte beschreiben, die für eine sichere Installation des TOEs und die sichere Vorbereitung der
Betriebsumgebung in Übereinstimmung mit den Sicherheitszielsetzungen in der ST erforderlich sind.
Wenn nicht erwartet wird, dass Installationsverfahren angewendet werden oder angewendet werden können
(z. B. weil der TOE möglicherweise bereits in einem betriebsbereiten Zustand geliefert wird), ist diese
Workunit nicht anwendbar und gilt daher als erfüllt.
159
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Die Installationsverfahren sollten, falls zutreffend, detaillierte Informationen über die folgenden Punkte
enthalten:
a) Mindestsystemanforderungen für eine sichere Installation;
b) Anforderungen an die Betriebsumgebung in Übereinstimmung mit den Sicherheitszielsetzungen der ST;
c) die Schritte, die der Benutzer durchführen muss, um zu einem betriebsbereiten TOE zu gelangen, der
seiner evaluierten Konfiguration entspricht. Eine solche Beschreibung muss – für jeden Schritt – ein
klares Schema für die Entscheidung über den nächsten Schritt in Abhängigkeit von Erfolg, Misserfolg oder
Problemen beim aktuellen Schritt enthalten;
d) Änderung der installationsspezifischen Sicherheitsmerkmale von Entitäten, die unter der Kontrolle der
TSF stehen (z. B. Parameter, Einstellungen, Passwörter);
e) Behandlung von Ausnahmen und Problemen.
11.4.1.5 Aktion AGD_PRE.1.2E
Der Evaluator muss alle zur Vorbereitung des TOEs erforderlichen Benutzerverfahren durchführen, um
festzustellen, dass der TOE und seine Betriebsumgebung sicher vorbereitet werden können, indem nur die
mitgelieferten Vorbereitungsverfahren verwendet werden.
Die Vorbereitung erfordert, dass der Evaluator den TOE von einem lieferbaren Zustand in den Zustand
überführt, in dem er betriebsbereit ist, einschließlich der Abnahme und Installation des TOEs und der
Durchsetzung der SFRs in Konsistenz gegenüber den in der ST festgelegten Sicherheitszielsetzungen für den
TOE.
Der Evaluator sollte nur die Verfahren des Entwicklers befolgen und darf nur die Aufgaben ausführen, die von
den Kunden üblicherweise zur Abnahme und Installation des TOEs erwartet werden, wobei er nur die
mitgelieferten vorbereitenden Verfahren verwendet. Jegliche Schwierigkeiten, die während einer solchen
Übung auftreten, können auf unvollständige, unklare oder unangemessene Leitlinien für Benutzer hindeuten.
Diese Workunit kann in Verbindung mit den Evaluierungsaufgaben unter „Independent testing“ (ATE_IND)
durchgeführt werden.
Wenn bekannt ist, dass der TOE als abhängige Komponente für eine zusammengesetzte TOE-Evaluierung
verwendet wird, dann sollte der Evaluator sicherstellen, dass die Betriebsumgebung durch die im
zusammengesetzten TOE verwendete Basiskomponente zufriedenstellend ist.
12 Klasse ALC: Unterstützung des Lebenszyklus

12.1 Einleitung
Der Zweck der Aufgabe zur Unterstützung des Lebenszyklus besteht darin, die Angemessenheit der
Sicherheitsverfahren zu bestimmen, die der Entwickler während der Entwicklung und Wartung des TOEs
verwendet. Diese Verfahren umfassen das vom Entwickler verwendete Lebenszyklusmodell, das
Konfigurationsmanagement, die während der gesamten Entwicklung des TOEs verwendeten
Sicherheitsmaßnahmen, die vom Entwickler während des gesamten Lebenszyklus des TOEs verwendeten
Tools, die Behandlung von Sicherheitsmängeln und die Lieferungsaufgabe.
Eine unzureichend kontrollierte Entwicklung und Wartung des TOEs kann zu Anfälligkeiten in der
Implementierung führen. Die Übereinstimmung mit einem definierten Lebenszyklusmodell kann dazu
beitragen, die Kontrollen in diesem Bereich zu verbessern. Ein messbares Lebenszyklusmodell, das für den
TOE verwendet wird, kann Unklarheiten bei der Beurteilung des Entwicklungsfortschritts des TOEs
beseitigen.
160
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Zweck der Konfigurationsmanagement-Aufgabe besteht darin, den Verbraucher bei der Identifizierung
des evaluierten TOEs zu unterstützen, sicherzustellen, dass die Konfigurationselemente eindeutig identifiziert
werden, und die Angemessenheit der Verfahren, die vom Entwickler zur Kontrolle und Verfolgung der am TOE
vorgenommenen Änderungen verwendet werden. Dazu gehören Einzelheiten darüber, welche Änderungen
verfolgt werden, wie potentielle Änderungen eingearbeitet werden und in welchem Maße die
Automatisierung zur Verringerung des Fehlerrisikos eingesetzt wird.
Die Sicherheitsverfahren für den Entwickler sollen den TOE und die zugehörigen Designinformationen vor
Störungen oder Offenlegung schützen. Die Einmischung in den Entwicklungsprozess kann die absichtliche
Einführung von Anfälligkeiten ermöglichen. Die Offenlegung von Designinformationen kann es ermöglichen,
Anfälligkeiten leichter auszunutzen. Die Angemessenheit der Verfahren hängt von der Art des TOEs und dem
Entwicklungsprozess ab.
Die Verwendung klar definierter Entwicklungstools und die Anwendung von Implementierungsnormen durch
den Entwickler und durch Dritte, die am Entwicklungsprozess beteiligt sind, tragen dazu bei, sicherzustellen,
dass bei der Präzisierung keine Anfälligkeiten versehentlich eingeführt werden.
Die Aufgabe zur Mängelbeseitigung soll dazu dienen, Sicherheitsmängel zu verfolgen, Korrekturmaßnahmen
zu identifizieren und die Informationen über die Korrekturmaßnahmen an die Benutzer des TOEs zu verteilen.
Der Zweck der Lieferungsaufgabe besteht darin, die Angemessenheit der Dokumentation der Verfahren zu
beurteilen, mit denen sichergestellt wird, dass der TOE ohne Änderungen an den Verbraucher geliefert wird.
12.2 CM-Funktionen (ALC_CMC)

12.2.1 Evaluierung der Unteraufgabe (ALC_CMC.1)
Die Zielsetzung dieser Unteraufgabe bestehen darin, festzustellen, ob der Entwickler den TOE eindeutig
identifiziert hat.
12.2.1.2 Eingaben
a) die ST,
b) der zum Prüfen geeignete TOE.
12.2.1.3 Aktion ALC_CMC.1.1E
ISO/IEC 15408-3 ALC_CMC.1.1C: Der TOE muss mit seiner eindeutigen Verweisung gekennzeichnet sein.
12.2.1.3.1 Workunit ALC_CMC.1-1
Der Evaluator muss prüfen, ob der zur Evaluierung bereitgestellte TOE mit seiner Verweisung gekennzeichnet
ist.
Der Evaluator sollte sicherstellen, dass der TOE die eindeutige Verweisung enthält, die in der ST angegeben
ist. Dies könnte durch etikettierte Verpackungen oder Medien bzw. durch ein vom betriebsbereiten TOE
angezeigtes Etikett erreicht werden. Damit soll sichergestellt werden, dass der Verbraucher den TOE (z. B. am
Kauf- oder Verwendungsort) identifizieren kann.
Der TOE kann ein Verfahren zur Verfügung stellen, mit dem er leicht identifiziert werden kann. Ein TOE kann
z. B. seinen Namen und seine Versionsnummer während der Startroutine oder als Antwort auf eine
Befehlszeileneingabe anzeigen. Ein Hardware- oder Firmware-TOE kann durch eine physisch auf dem TOE
eingeprägte Teilenummer identifiziert werden.
Alternativ kann die für den TOE vorgesehene eindeutige Verweisung die Kombination der eindeutigen
Verweisung jeder Komponente sein, aus der der TOE besteht (z. B. im Fall eines zusammengesetzten TOE).
161
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss prüfen, ob die verwendeten TOE-Verweisungen konsistent sind.
Wenn der TOE mehr als einmal beschriftet ist, müssen die Beschriftungen konsistent sein. Beispielsweise
sollte es möglich sein, jede gekennzeichnete Dokumentation der Leitlinien, die als Teil des TOEs geliefert wird,
mit dem evaluierten operativen TOE in Beziehung zu setzen. Dadurch wird das Vertrauen der Verbraucher
sichergestellt, dass sie die evaluierte Version des TOEs erworben haben, dass sie diese Version installiert und
die richtige Version der Anleitung haben, um den TOE in Übereinstimmung mit seiner ST zu betreiben.
Der Evaluator überprüft auch, ob die TOE-Verweisung gegenüber der ST konsistent ist.
Wenn diese Workunit auf einen zusammengesetzten TOE angewendet wird, gilt das Folgende. Der
zusammengesetzte IT-TOE wird nicht mit seiner eindeutigen (zusammengesetzten) Verweisung
gekennzeichnet, sondern nur die einzelnen Komponenten werden mit ihrer entsprechenden TOE-Verweisung
gekennzeichnet. Es würde eine Weiterentwicklung erfordern, damit der IT-TOE, d. h. während der
Inbetriebnahme und/oder des Betriebs, mit der zusammengesetzten Verweisung gekennzeichnet werden
kann. Wenn der zusammengesetzte TOE als Bestandteil der TOEs geliefert wird, dann enthalten die gelieferten
TOE-Positionen nicht die zusammengesetzte Verweisung. Die zusammengesetzte TOE-ST wird jedoch die
eindeutige Verweisung für den zusammengesetzten TOE enthalten und die Komponenten identifizieren, aus
denen der zusammengesetzte TOE besteht, anhand derer die Verbraucher feststellen können, ob sie über die
entsprechenden Elemente verfügen.
Die Zielsetzungen dieser Unteraufgabe bestehen darin, festzustellen, ob der Entwickler ein CM-System
verwendet, das alle Konfigurationselemente eindeutig identifiziert.
12.2.2.2 Eingaben
a) die ST,
b) der zum Prüfen geeignete TOE,
c) die Konfigurationsmanagementdokumentation.
Diese Komponente enthält eine implizite Evaluatorenaktion, um festzustellen, dass das CM-System verwendet
wird. Da sich die Anforderungen hier auf die Identifizierung des TOEs und die Bereitstellung einer
Konfigurationsliste beschränken, ist diese Aktion bereits durch die vorhandenen Workunits abgedeckt und
auf diese beschränkt. Bei „Evaluation of sub-activity“ (ALC_CMC.3) werden die Anforderungen über diese
beiden Punkte hinaus ausgeweitet, und es wird ein expliziterer Nachweis der Operation verlangt.
162
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
ist.
ISO/IEC 15408-3 ALC_CMC.2.2C: Die CM-Dokumentation muss die zur eindeutigen Identifizierung der
Konfigurationselemente verwendete Methode beschreiben.
Der Evaluator muss das Verfahren zur Identifizierung von Konfigurationselementen untersuchen, um
festzustellen, dass es beschreibt, wie Konfigurationselemente eindeutig identifiziert werden.
Die Verfahren sollten beschreiben, wie der Status jedes Konfigurationselements während des gesamten
Lebenszyklus des TOEs verfolgt werden kann. Die Verfahren können im CM-Plan oder in der gesamten
CM-Dokumentation detailliert beschrieben werden. Die enthaltenen Informationen sollten Folgendes
beschreiben:
a) das Verfahren, wie jedes Konfigurationselement eindeutig identifiziert wird, so dass es möglich ist,
Versionen desselben Konfigurationselements zu verfolgen;
b) das Verfahren, wie Konfigurationselementen eindeutige Bezeichner zugewiesen werden und wie sie in
das CM-System eingegeben werden;
163
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
c) das Verfahren, das zur Identifizierung ersetzter Versionen eines Konfigurationselements verwendet
werden soll.
ISO/IEC 15408-3 ALC_CMC.2.3C: Das CM-System muss alle Konfigurationselemente eindeutig identifizieren.
Der Evaluator muss die Konfigurationselemente untersuchen, um festzustellen, dass sie in einer Weise
identifiziert werden, die gegenüber der CM-Dokumentation konsistent ist.
Die Vertrauenswürdigkeit, dass das CM-System alle Konfigurationselemente eindeutig identifiziert, wird
durch die Untersuchung der Bezeichner für die Konfigurationselemente gewonnen. Sowohl für die
Konfigurationselemente, aus denen der TOE besteht, als auch für Entwürfe von Konfigurationselementen, die
vom Entwickler als Evaluationsnachweis vorgelegt werden, bestätigt der Evaluator, dass jedes
Konfigurationselement einen eindeutigen Bezeichner in einer Weise besitzt, die gegenüber dem in der
CM-Dokumentation beschriebenen eindeutigen Identifizierungsverfahren konsistent ist.
Die Zielsetzungen dieser Unteraufgabe bestehen darin, festzustellen, ob der Entwickler ein CM-System
verwendet, das alle Konfigurationselemente eindeutig identifiziert, und ob die Fähigkeit, diese Elemente zu
ändern, ordnungsgemäß kontrolliert wird.
12.2.3.2 Eingaben
a) die ST,
ist.
164
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
beschreiben:
werden soll.
165
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
ISO/IEC 15408-3 ALC_CMC.3.4C: Das CM-System muss Maßnahmen vorsehen, die sicherstellen, dass nur
autorisierte Änderungen an den Konfigurationselementen möglich sind.
Der Evaluator muss die im CM-Plan beschriebenen CM-Zugriffskontrollmaßnahmen untersuchen, um

festzustellen, ob sie den unbefugten Zugriff auf die Konfigurationselemente wirksam verhindern.
Der Evaluator kann eine Menge Verfahren verwenden, um festzustellen, ob die CM-Zugriffskontroll-
maßnahmen wirksam sind. Der Evaluator kann beispielsweise die Zugriffskontrollmaßnahmen durchführen,
um sicherzustellen, dass die Verfahren nicht umgangen werden konnten. Der Evaluator kann die von den
Verfahren des CM-Systems erzeugten Ausgaben verwenden, die von ALC_CMC.3.8C gefordert werden. Der
Evaluator kann auch einer Vorführung des CM-Systems beiwohnen, um sicherzustellen, dass die eingesetzten
Zugriffskontrollmaßnahmen effektiv funktionieren.
ISO/IEC 15408-3 ALC_CMC.3.5C: Die CM-Dokumentation muss einen CM-Plan enthalten.
Der Evaluator muss prüfen, ob die bereitgestellte CM-Dokumentation einen CM-Plan enthält.
Der CM-Plan muss kein zusammenhängendes Dokument sein, aber es wird empfohlen, dass es ein einziges
Dokument gibt, das beschreibt, wo die verschiedenen Teile des CM-Plans zu finden sind. Wenn der CM-Plan
kein Einzeldokument ist, gibt die Liste in der folgenden Workunit Hinweise darauf, welcher Kontext zu
erwarten ist.
ISO/IEC 15408-3 ALC_CMC.3.6C: Der CM-Plan muss beschreiben, wie das CM-System für die Entwicklung des
TOEs verwendet wird.
Der Evaluator muss den CM-Plan untersuchen, um festzustellen, dass er beschreibt, wie das CM-System für
die Entwicklung des TOEs verwendet wird.
Die Beschreibungen, die in einem CM-Plan enthalten sind, umfassen, falls zutreffend, Folgendes:
a) alle bei der TOE-Entwicklung durchgeführten Aufgaben, die den Verfahren des Konfigurations-
managements unterliegen (z. B. Anlegen, Ändern oder Löschen eines Konfigurationselements,
Datensicherung, Archivierung);
b) welche Mittel (z. B. CM-Tools, Formulare) zur Verfügung gestellt werden müssen;
c) die Verwendung der CM-Tools: die notwendigen Details, damit ein Benutzer des CM-Systems die
CM-Tools korrekt bedienen kann, um die Integrität des TOEs zu erhalten;
d) welche anderen Objekte (Entwicklungskomponenten, Tools, Bewertungsumgebungen usw.) unter die
Kontrolle des CM gestellt werden;
e) die Rollen und Verantwortlichkeiten der Personen, die für die Durchführung von Operationen an
einzelnen Konfigurationselementen erforderlich sind (für verschiedene Arten von
Konfigurationselementen (z. B. Designdokumentation oder Quellcode) können unterschiedliche Rollen
identifiziert werden);
f) wie CM-Instanzen (z. B. Änderungskontrollausschüsse, Schnittstellenkontroll-Arbeitsgruppen)
eingeführt und besetzt werden;
166
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
g) die Beschreibung des Änderungsmanagements;

h) die Verfahren, mit denen sichergestellt wird, dass nur autorisierte Personen Änderungen an
Konfigurationselementen vornehmen können;
i) die Verfahren, die verwendet werden, um sicherzustellen, dass keine Probleme durch nebenläufige
Prozesse wie gleichzeitige Änderungen an Konfigurationselementen auftreten;
j) die Nachweise, die sich aus der Anwendung der Verfahren ergeben. Beispielsweise könnte das CM-System
bei einer Änderung an einem Konfigurationselement eine Beschreibung der Änderung, die
Verantwortlichkeit für die Änderung, die Identifizierung aller betroffenen Konfigurationselemente, den
Status (z. B. anhängig oder abgeschlossen) sowie Datum und Uhrzeit der Änderung aufzeichnen. Dies
könnte in einem Audit-Trail der vorgenommenen Änderungen oder Änderungskontrollaufzeichnungen
dokumentiert werden;
k) der Ansatz zur Versionskontrolle und zu eindeutigen Verweisungen von TOE-Versionen (z. B. Abdecken
der Freigabe von Patches in Betriebssystemen und die anschließende Erkennung ihrer Anwendung).
ISO/IEC 15408-3 ALC_CMC.3.7C: Der Nachweis muss zeigen, dass alle Konfigurationselemente im CM-System
gepflegt werden.
Der Evaluator muss prüfen, ob die in der Konfigurationsliste identifizierten Konfigurationselemente durch
das CM-System gepflegt werden.
Das vom Entwickler eingesetzte CM-System sollte die Integrität des TOEs aufrechterhalten. Der Evaluator
sollte prüfen, ob für jede Art von Konfigurationselementen (z. B. Designdokumente oder Quelltextmodule), die
in der Konfigurationsliste enthalten sind, Beispiele für die Nachweise vorliegen, die durch die im CM-Plan
beschriebenen Verfahren erzeugt wurden. In diesem Fall hängt der Probenahmeansatz vom Grad der
Granularität ab, die im CM-System zur Steuerung der CM-Elemente verwendet wird. Wenn z. B.
10 000 Quellcode-Module in der Konfigurationsliste identifiziert werden, muss eine andere Abtaststrategie
angewendet werden als im Fall, bei dem es nur fünf oder sogar nur eines gibt. Der Schwerpunkt dieser Aufgabe
sollte darauf liegen, sicherzustellen, dass das CM-System korrekt betrieben wird, und nicht auf der Erkennung
kleinerer Fehler.
Zur Anleitung von Probenahmen siehe A.2, Probenahme.
ISO/IEC 15408-3 ALC_CMC.3.8C: Der Nachweis muss zeigen, dass das CM-System in Übereinstimmung mit dem
CM-Plan betrieben wird.
Der Evaluator muss die CM-Dokumentation prüfen, um sicherzustellen, dass sie die durch den CM-Plan
identifizierten CM-Systemdatensätze enthält.
Die vom CM-System erzeugte Ausgabe sollte den Nachweis erbringen, dass der Evaluator darauf vertrauen
muss, dass der CM-Plan angewendet und alle Konfigurationselemente vom CM-System wie in ALC_CMC.3.7C
gefordert gepflegt werden. Die Ausgabe könnte beispielsweise Formulare zur Änderungskontrolle oder
Formulare zur Genehmigung des Zugriffs auf Konfigurationselemente enthalten.
12.2.3.3.10Workunit ALC_CMC.3-10
Der Evaluator muss die Nachweise untersuchen, um festzustellen, dass das CM-System in Übereinstimmung
mit dem CM-Plan betrieben wird.
167
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator sollte eine Stichprobe von Nachweisen für jede Art von CM-relevanten Vorgängen auswählen
und untersuchen, die an einem Konfigurationselement durchgeführt wurden (z. B. Erstellung, Änderung,
Löschung, Rückfall in eine frühere Version), um zu bestätigen, dass alle Vorgänge des CM-Systems in
Übereinstimmung mit den dokumentierten Verfahren durchgeführt wurden. Der Evaluator bestätigt, dass die
Nachweise alle für diesen Vorgang im CM-Plan identifizierten Informationen enthalten. Die Untersuchung der
Nachweise kann den Zugang zu einem CM-Tool erfordern, das verwendet wird. Der Evaluator kann sich dafür
entscheiden, eine Stichprobe der Nachweise zu entnehmen.
Weiteres Vertrauen in den korrekten Betrieb des CM-Systems und die effektive Pflege der Konfigurations-
elemente kann durch Befragungen ausgewählter Entwicklungsmitarbeiter geschaffen werden. Bei der
Durchführung solcher Befragungen zielt der Evaluator darauf ab, ein tieferes Verständnis dafür zu gewinnen,
wie das CM-System in der Praxis eingesetzt wird, sowie zu bestätigen, dass die CM-Verfahren wie in der
CM-Dokumentation beschrieben angewendet werden. Es ist zu beachten, dass solche Befragungen die
Untersuchung von dokumentierenden Nachweisen eher ergänzen als ersetzen sollten und möglicherweise
nicht notwendig sind, wenn die dokumentierenden Nachweise allein die Anforderung erfüllen. Angesichts des
großen Umfangs des CM-Plans ist es jedoch möglich, dass einige Aspekte (z. B. Rollen und Verantwortlich-
keiten) aus dem CM-Plan und den Aufzeichnungen gegebenenfalls allein nicht klar hervorgehen. Dies ist ein
Fall, in dem eine Klärung durch Befragungen notwendig sein kann.
Es wird erwartet, dass der Evaluator den Entwicklungsstandort zur Unterstützung dieser Aufgabe besichtigt.
Zur Anleitung von Standortbesichtigungen siehe A.4, Standortbesichtigungen.
Die Zielsetzungen dieser Unteraufgabe bestehen darin, festzustellen, ob der Entwickler den TOE und die
zugehörigen Konfigurationselemente eindeutig identifiziert hat und ob die Fähigkeit, diese Elemente zu
modifizieren, durch automatisierte Tools ordnungsgemäß gesteuert wird, wodurch das CM-System weniger
anfällig für menschliche Fehler oder Fahrlässigkeit wird.
12.2.4.2 Eingaben
a) die ST,
ist.
168
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
zusammengesetzte TOE wird nicht mit seiner eindeutigen (zusammengesetzten) Verweisung gekennzeichnet,
sondern nur die einzelnen Komponenten werden mit ihrer entsprechenden TOE-Verweisung gekennzeichnet.
Es würde eine Weiterentwicklung erfordern, damit der zusammengesetzte TOE, d. h. während der
beschreiben:
werden soll.
169
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
durch die Untersuchung der Bezeichner für die Konfigurationselemente gewonnen. Für die unter ALC_CMS
identifizierten Konfigurationselemente bestätigt der Evaluator, dass jedes Konfigurationselement einen
eindeutigen Bezeichner in einer Weise besitzt, dass es gegenüber dem in der CM-Dokumentation
beschriebenen eindeutigen Identifizierungsverfahren konsistent ist.
ISO/IEC 15408-3 ALC_CMC.4.4C: Das CM-System muss automatisierte Maßnahmen vorsehen, die sicherstellen,
dass nur autorisierte Änderungen an den Konfigurationselementen möglich sind.
Der Evaluator muss die im CM-Plan (vgl. ALC_CMC.4.6C) beschriebenen CM-Zugriffskontrollmaßnahmen

untersuchen, um festzustellen, ob sie automatisiert und wirksam sind, um unbefugten Zugriff auf die
Konfigurationselemente zu verhindern.
ISO/IEC 15408-3 ALC_CMC.4.5C: Das CM-System muss die Produktion des TOEs durch automatisierte Mittel
unterstützen.
Der Evaluator muss den CM-Plan (vgl. ALC_CMC.4.6C) auf automatisierte Verfahren zur Unterstützung der
Produktion des TOEs prüfen.
Der Begriff „Produktion“ bezieht sich auf die Prozesse, die der Entwickler anwendet, um den TOE von der
Darstellung der Implementierung zu einem für die Lieferung an den Endkunden akzeptablen Zustand zu
bringen.
Der Evaluator überprüft vorhandene automatisierte Produktionsunterstützungsverfahren innerhalb des

CM-Plans.
Im Folgenden sind Beispiele für automatisierte Mittel zur Unterstützung der Produktion des TOEs aufgeführt:
ein „Make“-Tool (wie bei vielen Software-Entwicklungstools vorgesehen) im Falle eines Software-TOE;
ein Tool, das automatisch (z. B. mit Hilfe von Strichcodes) sicherstellt, dass nur Teile kombiniert werden,
die im Falle eines Hardware-TOE tatsächlich zusammengehören.
Der Evaluator muss die Verfahren zur Unterstützung der TOE-Produktion untersuchen, um festzustellen, ob
sie wirksam sicherstellen, dass ein TOE generiert wird, der die Darstellung seiner Implementierung
widerspiegelt.
Die Verfahren zur Produktionsunterstützung sollten beschreiben, welche Tools verwendet werden müssen,
um den endgültigen TOE aus der Darstellung der Implementierung in einer klar definierten Weise zu erstellen.
Die Konventionen, Richtlinien oder andere notwendige Konstrukte sind unter ALC_TAT beschrieben.
170
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator stellt fest, dass bei Einhaltung der Verfahren zur Produktionsunterstützung die richtigen
Konfigurationselemente zur Generierung des TOEs verwendet werden würden. In einem Software-TOE kann
dies beispielsweise die Prüfung einschließen, ob die automatisierten Produktionsverfahren sicherstellen, dass
alle Quelldateien und zugehörigen Bibliotheken im kompilierten Objektcode enthalten sind. Darüber hinaus
sollten die Verfahren sicherstellen, dass Compiler-Optionen und vergleichbare andere Optionen eindeutig
definiert sind. Bei einem Hardware-TOE kann diese Workunit die Prüfung einschließen, ob die automatischen
Produktionsverfahren sicherstellen, dass die zugehörigen Teile zusammengebaut werden und keine Teile
fehlen.
Der Kunde kann dann sicher sein, dass die zur Installation gelieferte Version des TOEs auf eindeutige Weise
von der Darstellung der Implementierung abgeleitet ist und die SFRs wie in der ST beschrieben implementiert.
Der Evaluator sollte bedenken, dass das CM-System nicht unbedingt die Fähigkeit besitzen muss, den TOE zu
erstellen, sondern dass es den Prozess unterstützen sollte, der dazu beiträgt, die Wahrscheinlichkeit
menschlicher Fehler zu verringern.
Der CM-Plan muss nicht in einem einzigen Dokument enthalten sein, aber es wird empfohlen, dass es ein
separates Dokument gibt, das beschreibt, wo die verschiedenen Teile des CM-Plans zu finden sind. Wenn der
CM-Plan aus einer Menge Dokumente besteht, gibt die Liste in der folgenden Workunit Hinweise auf den
erforderlichen Inhalt.
d) die Verfahren zur Unterstützung der Produktion;
e) welche anderen Objekte (Entwicklungskomponenten, Tools, Bewertungsumgebungen usw.) unter die
f) die Rollen und Verantwortlichkeiten der Personen, die für die Durchführung von Operationen an
g) wie CM-Instanzen (z. B. Änderungskontrollausschüsse, Schnittstellenkontroll-Arbeitsgruppen)
h) die Beschreibung des Änderungsmanagements;
171
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
i) die Verfahren, mit denen sichergestellt wird, dass nur autorisierte Personen Änderungen an
j) die Verfahren, die verwendet werden, um sicherzustellen, dass keine Probleme durch nebenläufige
k) die Nachweise, die sich aus der Anwendung der Verfahren ergeben. Beispielsweise könnte das CM-System
l) der Ansatz zur Versionskontrolle und zu eindeutigen Verweisungen von TOE-Versionen (z. B. Abdecken
ISO/IEC 15408-3 ALC_CMC.4.8C: Der CM-Plan muss die Verfahren zur Abnahme geänderter oder neu erstellter
Konfigurationselemente als Teile des TOEs beschreiben.
Der Evaluator muss den CM-Plan untersuchen, um festzustellen, dass er die Verfahren beschreibt, die zur
Abnahme geänderter oder neu erstellter Konfigurationselemente als Teile des TOEs verwendet werden.
Die Beschreibungen der Abnahmeverfahren im CM-Plan sollten die für die Abnahme verantwortlichen
Entwicklerrollen oder Personen sowie die für die Abnahme zu verwendenden Kriterien enthalten. Sie sollten
alle Abnahmesituationen berücksichtigen, die auftreten können, insbesondere
a) die erstmalige Aufnahme eines Elements in das CM-System, insbesondere die Aufnahme von Software-,
Firmware- und Hardware-Komponenten anderer Hersteller in den TOE („Integration“),
b) das Verschieben von Konfigurationselementen in die nächste Lebenszyklusphase in jeder Phase der
Konstruktion des TOEs (z. B. Modul, Teilsystem, System),
c) im Anschluss an Transporte zwischen verschiedenen Entwicklungsstandorten.
Wenn diese Workunit auf eine abhängige Komponente angewendet wird, die in einen zusammengesetzten
TOE integriert werden soll, sollte der CM-Plan die Kontrolle der Basiskomponenten, die der Entwickler des
abhängigen TOEs erhält, berücksichtigen.
Bei der Beschaffung der Komponenten haben die Evaluatoren Folgendes zu überprüfen:
a) Die Übergabe jeder Basiskomponente vom Entwickler der Basiskomponente an den Integrator
(Entwickler des abhängigen TOE) wurde in Übereinstimmung mit den sicheren Lieferverfahren des TOEs
der Basiskomponente durchgeführt, wie im Zertifizierungsbericht des TOEs der Basiskomponente
angegeben.
b) Die erhaltene Komponente hat die gleichen Bezeichner, wie sie im ST- und Zertifizierungsbericht für die
Komponente TOE angegeben sind.
c) Alles zusätzliche Material, das von einem Entwickler für die Komposition (Integration) benötigt wird,
wird zur Verfügung gestellt. Dies soll den notwendigen Auszug aus der Funktionsspezifikation der
Komponente TOE enthalten.
gepflegt werden.
172
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
kleinerer Fehler.
173
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Die Zielsetzungen dieser Unteraufgabe bestehen darin, festzustellen, ob der Entwickler den TOE und die
zugehörigen Konfigurationselemente eindeutig identifiziert hat und ob die Fähigkeit, diese Elemente zu
modifizieren, durch automatisierte Tools ordnungsgemäß gesteuert wird, wodurch das CM-System weniger
anfällig für menschliche Fehler oder Fahrlässigkeit wird.
12.2.5.2 Eingaben
a) die ST,
ist.
Wenn diese Workunit auf einen zusammengesetzten TOE angewendet wird, gilt das Folgende. Der zusammen-
gesetzte IT-TOE wird nicht mit seiner eindeutigen (zusammengesetzten) Verweisung gekennzeichnet,
sondern nur die einzelnen Komponenten werden mit ihrer entsprechenden TOE-Verweisung gekennzeichnet.
Es würde eine Weiterentwicklung erfordern, damit der IT-TOE, d. h. während der Inbetriebnahme und/oder
174
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
des Betriebs, mit der zusammengesetzten Verweisung gekennzeichnet werden kann. Wenn der
zusammengesetzte TOE als Bestandteil der TOEs geliefert wird, dann enthalten die gelieferten TOE-Positionen
nicht die zusammengesetzte Verweisung. Die zusammengesetzte TOE-ST wird jedoch die eindeutige
Verweisung für den zusammengesetzten TOE enthalten und die Komponenten identifizieren, aus denen der
zusammengesetzte TOE besteht, anhand derer die Verbraucher feststellen können, ob sie über die
beschreiben:
werden soll.
ISO/IEC 15408-3 ALC_CMC.5.3C: Die CM-Dokumentation muss begründen, dass die Abnahmeverfahren eine
angemessene und geeignete Überprüfung der Änderungen an allen Konfigurationselementen vorsehen.
Der Evaluator muss die CM-Dokumentation untersuchen, um festzustellen, ob sie es rechtfertigt, dass die
Abnahmeverfahren eine angemessene und geeignete Überprüfung der Änderungen an allen
Konfigurationselementen vorsehen.
Die CM-Dokumentation sollte hinreichend deutlich machen, dass durch die Einhaltung der Abnahmeverfahren
nur Teile von angemessener Qualität in den TOE eingebaut werden.
ISO/IEC 15408-3 ALC_CMC.5.5C: Das CM-System muss automatisierte Maßnahmen vorsehen, die sicherstellen,
dass nur autorisierte Änderungen an den Konfigurationselementen möglich sind.
175
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss die im CM-Plan (vgl. ALC_CMC.5.12C) beschriebenen CM-Zugriffskontrollmaßnahmen

untersuchen, um festzustellen, ob sie automatisiert und wirksam sind, um unbefugten Zugriff auf die
Konfigurationselemente zu verhindern.
ISO/IEC 15408-3 ALC_CMC.5.6C: Das CM-System muss die Produktion des TOEs durch automatisierte Mittel
unterstützen.
Der Evaluator muss den CM-Plan (vgl. ALC_CMC.5.12C) auf automatisierte Verfahren zur Unterstützung der
Produktion des TOEs prüfen.
Der Begriff „Produktion“ bezieht sich auf die Prozesse, die der Entwickler anwendet, um den TOE von der
Darstellung der Implementierung zu einem für die Lieferung an den Endkunden akzeptablen Zustand zu
bringen.
Der Evaluator überprüft vorhandene automatisierte Produktionsunterstützungsverfahren innerhalb des

CM-Plans.
Im Folgenden sind Beispiele für automatisierte Mittel zur Unterstützung der Produktion des TOEs aufgeführt:
ein „Make“-Tool (wie bei vielen Software-Entwicklungstools vorgesehen) im Falle eines Software-TOE;
ein Tool, das automatisch (z. B. mit Hilfe von Strichcodes) sicherstellt, dass nur Teile kombiniert werden,
die im Falle eines Hardware-TOE tatsächlich zusammengehören.
Der Evaluator muss die Verfahren zur Unterstützung der TOE-Produktion untersuchen, um festzustellen, ob
sie wirksam sicherstellen, dass ein TOE generiert wird, der die Darstellung seiner Implementierung
widerspiegelt.
Die Verfahren zur Produktionsunterstützung sollten beschreiben, welche Tools verwendet werden müssen,
um den endgültigen TOE aus der Darstellung der Implementierung in einer klar definierten Weise zu erstellen.
Die Konventionen, Richtlinien oder andere notwendige Konstrukte sind unter ALC_TAT beschrieben.
Der Evaluator stellt fest, dass bei Einhaltung der Verfahren zur Produktionsunterstützung die richtigen
Konfigurationselemente zur Generierung des TOEs verwendet werden würden. In einem Software-TOE kann
dies beispielsweise die Prüfung einschließen, ob die automatisierten Produktionsverfahren sicherstellen, dass
alle Quelldateien und zugehörigen Bibliotheken im kompilierten Objektcode enthalten sind. Darüber hinaus
sollten die Verfahren sicherstellen, dass Compiler-Optionen und vergleichbare andere Optionen eindeutig
definiert sind. Bei einem Hardware-TOE kann diese Workunit die Prüfung einschließen, ob die automatischen
Produktionsverfahren sicherstellen, dass die zugehörigen Teile zusammengebaut werden und keine Teile
fehlen.
Der Kunde kann dann sicher sein, dass die zur Installation gelieferte Version des TOEs auf eindeutige Weise
von der Darstellung der Implementierung abgeleitet ist und die SFRs wie in der ST beschrieben implementiert.
176
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator sollte bedenken, dass das CM-System nicht unbedingt die Fähigkeit besitzen muss, den TOE zu
erstellen, sondern dass es den Prozess unterstützen sollte, der dazu beiträgt, die Wahrscheinlichkeit
menschlicher Fehler zu verringern.
ISO/IEC 15408-3 ALC_CMC.5.7C: Das CM-System muss sicherstellen, dass die für die Abnahme eines
Konfigurationselements in das CM-System verantwortliche Person nicht die Person ist, die es entwickelt hat.
Der Evaluator muss das CM-System untersuchen, um festzustellen, dass sichergestellt wird, dass die Person,
die für die Abnahme eines Konfigurationselements verantwortlich ist, nicht die Person ist, die es entwickelt
hat.
Die Abnahmeverfahren beschreiben, wer für die Abnahme eines Konfigurationselements verantwortlich ist.
Anhand dieser Beschreibungen sollte der Evaluator in der Lage sein festzustellen, dass die Person, die ein
Konfigurationselement entwickelt hat, auf keinen Fall für dessen Abnahme verantwortlich ist.
ISO/IEC 15408-3 ALC_CMC.5.8C: Das CM-System muss die Konfigurationselemente identifizieren, aus denen die
TSF besteht.
Der Evaluator muss das CM-System untersuchen, um festzustellen, dass es die Konfigurationselemente
identifiziert, die die TSF bilden.
Die CM-Dokumentation sollte beschreiben, wie das CM-System die Konfigurationselemente identifiziert, aus
denen die TSF besteht. Der Evaluator sollte eine Stichprobe von Konfigurationselementen auswählen, die
jeden Elementtyp abdecken, insbesondere TSF- und Nicht-TSF-Elemente, und prüfen, ob sie vom CM-System
korrekt klassifiziert sind.
ISO/IEC 15408-3 ALC_CMC.5.9C: Das CM-System muss das Audit aller Änderungen am TOE durch automatisierte
Mittel unterstützen, einschließlich Urheber, Datum und Uhrzeit im Audit-Trail.
Der Evaluator muss das CM-System untersuchen, um festzustellen, dass es die Prüfung aller Änderungen am
TOE mit automatisierten Mitteln unterstützt, einschließlich des Urhebers, des Datums und der Uhrzeit im
Audit-Trail.
Der Evaluator sollte eine Stichprobe von Audit-Trails einsehen und prüfen, ob sie die Mindestinformationen
enthalten.
ISO/IEC 15408-3 ALC_CMC.5.10C: Das CM-System muss ein automatisiertes Mittel zur Identifizierung aller
anderen Konfigurationselemente bereitstellen, die von der Änderung an einem bestimmten Konfigurations-
element betroffen sind.
Der Evaluator muss das CM-System untersuchen, um festzustellen, dass es ein automatisiertes Mittel zur
Identifizierung aller anderen Konfigurationselemente bietet, die von der Änderung eines bestimmten
Konfigurationselements betroffen sind.
177
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Die CM-Dokumentation sollte beschreiben, wie das CM-System alle anderen Konfigurationselemente
identifiziert, die von der Änderung eines bestimmten Konfigurationselements betroffen sind. Der Evaluator
sollte eine Stichprobe von Konfigurationselementen auswählen, die alle Arten von Elementen abdeckt, und die
automatisierten Mittel anwenden, um festzustellen, dass er alle Elemente identifiziert, die von der Änderung
des ausgewählten Elements betroffen sind.
ISO/IEC 15408-3 ALC_CMC.5.11C: Das CM-System muss die Version der Darstellung der Implementierung
identifizieren können, aus der der TOE generiert wird.
Der Evaluator muss das CM-System untersuchen, um festzustellen, dass es in der Lage ist, die Version der
Darstellung der Implementierung zu identifizieren, aus der der TOE generiert wird.
Die CM-Dokumentation sollte beschreiben, wie das CM-System die Version der Darstellung der
Implementierung identifiziert, aus der der TOE generiert wird. Der Evaluator sollte eine Stichprobe der zur
Erstellung des TOEs verwendeten Teile auswählen und das CM-System anwenden, um zu überprüfen, dass es
die entsprechende Darstellung der Implementierung in der korrekten Version identifiziert.
Der CM-Plan muss kein zusammenhängendes Dokument sein, aber es wird empfohlen, dass es ein einziges
Dokument gibt, das beschreibt, wo die verschiedenen Teile des CM-Plans zu finden sind. Wenn der CM-Plan
kein Einzeldokument ist, gibt die Liste in der folgenden Workunit Hinweise darauf, welcher Kontext zu
erwarten ist.
d) die Verfahren zur Unterstützung der Produktion;
e) welche anderen Objekte (Entwicklungskomponenten, Tools, Bewertungsumgebungen usw.) unter die

178
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
f) die Rollen und Verantwortlichkeiten der Personen, die für die Durchführung von Operationen an
g) wie CM-Instanzen (z. B. Änderungskontrollausschüsse, Schnittstellenkontroll-Arbeitsgruppen)

h) die Beschreibung des Änderungsmanagements;
i) die Verfahren, mit denen sichergestellt wird, dass nur autorisierte Personen Änderungen an
j) die Verfahren, die verwendet werden, um sicherzustellen, dass keine Probleme durch nebenläufige
k) die Nachweise, die sich aus der Anwendung der Verfahren ergeben. Beispielsweise könnte das CM-System
l) der Ansatz zur Versionskontrolle und zu eindeutigen Verweisungen von TOE-Versionen (z. B. Abdecken
ISO/IEC 15408-3 ALC_CMC.5.14C: Der CM-Plan muss die Verfahren zur Abnahme geänderter oder neu erstellter
Konfigurationselemente als Teile des TOEs beschreiben.
Der Evaluator muss den CM-Plan untersuchen, um festzustellen, dass er die Verfahren beschreibt, die zur
Abnahme geänderter oder neu erstellter Konfigurationselemente als Teile des TOEs verwendet werden.
Die Beschreibungen der Abnahmeverfahren im CM-Plan sollten die für die Abnahme verantwortlichen
Entwicklerrollen oder Personen sowie die für die Annahme zu verwendenden Kriterien enthalten. Sie sollten
alle Abnahmesituationen berücksichtigen, die auftreten können, insbesondere
a) die erstmalige Aufnahme eines Elements in das CM-System, insbesondere die Aufnahme von Software-,
Firmware- und Hardware-Komponenten anderer Hersteller in den TOE („Integration“);
b) das Verschieben von Konfigurationselementen in die nächste Lebenszyklusphase in jeder Phase der
Konstruktion des TOEs (z. B. Modul, Teilsystem, System);
c) im Anschluss an Transporte zwischen verschiedenen Entwicklungsstandorten.
gepflegt werden.
179
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
kleinerer Fehler.
Der Evaluator muss die Verfahren zur Produktionsunterstützung untersuchen, um festzustellen, dass durch
Befolgung dieser Verfahren ein TOE wie der vom Entwickler für Prüfaufgaben zur Verfügung gestellte TOE
produziert würde.
180
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Wenn es sich bei dem TOE um einen kleinen Software-TOE handelt und die Produktion aus Kompilieren und
Verknüpfen besteht, könnte der Evaluator die Angemessenheit der Verfahren zur Produktionsunterstützung
bestätigen, indem er sie selbst erneut anwendet.
Wenn der Produktionsprozess des TOEs komplizierter ist (wie z. B. im Fall einer Chipkarte), aber bereits
begonnen hat, sollte der Evaluator die Anwendung der Verfahren zur Produktionsunterstützung bei einer
Begehung des Entwicklungsstandorts überprüfen. Er könnte eine in seiner Gegenwart erstellte Kopie des
TOEs mit den für seine Prüfaufgaben verwendeten Proben vergleichen.
Andernfalls sollte sich die Feststellung des Evaluators auf die vom Entwickler vorgelegten dokumentierenden
Nachweise stützen.
Diese Workunit kann in Verbindung mit den Evaluierungsaufgaben unter „Implementation representation“
(ADV_IMP) durchgeführt werden.
12.3 CM-Umfang (ALC_CMS)
12.3.1 Evaluierung der Unteraufgabe (ALC_CMS.1)
Die Zielsetzung dieser Unteraufgabe soll darin bestehen, festzustellen, ob der Entwickler das Konfigurations-
management für den TOE und die Evaluationsnachweise durchführt. Diese Konfigurationselemente werden
in Übereinstimmung mit den „CM capabilities“ (ALC_CMC) gesteuert.
12.3.1.2 Eingaben
a) die ST,
b) die Konfigurationsliste.
12.3.1.3 Aktion ALC_CMS.1.1E
ISO/IEC 15408-3 ALC_CMS.1.1C: Die Konfigurationsliste muss folgende Elemente enthalten: den TOE selbst und
den von den SARs geforderten Evaluationsnachweis.
12.3.1.3.1 Workunit ALC_CMS.1-1
Der Evaluator muss prüfen, ob die Konfigurationsliste die folgende Menge Elemente enthält:
a) der TOE selbst;
b) der von den SARs in der ST geforderte Evaluationsnachweis.
ISO/IEC 15408-3 ALC_CMS.1.2C: Die Konfigurationsliste muss die Konfigurationselemente eindeutig

identifizieren.
Der Evaluator muss die Konfigurationsliste untersuchen, um festzustellen, dass sie jedes Konfigurations-
element eindeutig identifiziert.
181
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Die Konfigurationsliste enthält genügend Informationen, um eindeutig zu identifizieren, welche Version eines
jeden Elements verwendet wurde (üblicherweise eine Versionsnummer). Anhand dieser Liste kann der
Evaluator prüfen, ob die richtigen Konfigurationselemente und die richtige Version jedes Elements bei der
Evaluierung verwendet wurden.
Die Zielsetzung dieser Unteraufgabe soll darin bestehen, festzustellen, ob die Konfigurationsliste den TOE, die
Teile, aus denen der TOE besteht, und die Evaluationsnachweise enthält. Diese Konfigurationselemente
werden in Übereinstimmung mit den „CM capabilities“ (ALC_CMC) gesteuert.
12.3.2.2 Eingaben
a) die ST,
ISO/IEC 15408-3 ALC_CMS.2.1C: Die Konfigurationsliste muss folgende Elemente enthalten: den TOE selbst, den
von den SARs geforderten Evaluationsnachweis und die Teile, aus denen der TOE besteht.
a) der TOE selbst;
b) die Teile, aus denen der TOE besteht;
c) der von den SARs geforderte Evaluationsnachweis.

identifizieren.
ISO/IEC 15408-3 ALC_CMS.2.3C: Für jedes TSF-relevante Konfigurationselement muss in der Konfigurationsliste
der Entwickler des Elements angegeben werden.
Der Evaluator muss prüfen, ob die Konfigurationsliste den Entwickler jedes TSF-relevanten Konfigurations-
elements angibt.
Wenn nur ein Entwickler an der Entwicklung des TOEs beteiligt ist, ist diese Workunit nicht anwendbar und
182
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Teile, aus denen der TOE besteht, die Darstellung der TOE-Implementierung und die Evaluationsnachweise
enthält. Diese Konfigurationselemente werden in Übereinstimmung mit den „CM capabilities“ (ALC_CMC)
gesteuert.
12.3.3.2 Eingaben
a) die ST,
von den SARs geforderten Evaluationsnachweis, die Teile, aus denen der TOE besteht, und die Darstellung der
Implementierung.
a) der TOE selbst;
c) die Darstellung der TOE-Implementierung;
d) der von den SARs in der ST geforderte Evaluationsnachweis.

identifizieren.
Evaluation verwendet wurden.
elements angibt.
183
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Teile, aus denen der TOE besteht, die Darstellung der TOE-Implementierung, Sicherheitsmängel und die
Evaluationsnachweise enthält. Diese Konfigurationselemente werden in Übereinstimmung mit den „CM
capabilities“ (ALC_CMC) gesteuert.
12.3.4.2 Eingaben
a) die ST,
von den SARs geforderten Evaluationsnachweis, die Teile, aus denen der TOE besteht, die Darstellung der
Implementierung und Berichte über Sicherheitsmängel sowie deren Behebungsstatus.
a) der TOE selbst;
d) der von den SARs in der ST geforderte Evaluationsnachweis;
e) die Dokumentation, die verwendet wird, um Details von gemeldeten Sicherheitsmängeln im

Zusammenhang mit der Implementierung aufzuzeichnen (z. B. Problemstatusberichte, die aus der
Problemdatenbank eines Entwicklers abgeleitet wurden).

identifizieren.
184
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
elements angibt.
Teile, aus denen der TOE besteht, die Darstellung der TOE-Implementierung, Sicherheitsmängel,
Entwicklungstools und zugehörige Informationen sowie die Evaluationsnachweise enthält. Diese
Konfigurationselemente werden in Übereinstimmung mit den „CM capabilities“ (ALC_CMC) gesteuert.
12.3.5.2 Eingaben
a) die ST,
von den SARs geforderten Evaluationsnachweis, die Teile, aus denen der TOE besteht, die Darstellung der
Implementierung, Berichte über Sicherheitsmängel sowie deren Behebungsstatus und Entwicklungstools und
zugehörige Informationen.
a) der TOE selbst;
d) der von den SARs in der ST geforderte Evaluationsnachweis;
e) die Dokumentation, die verwendet wird, um Details von gemeldeten Sicherheitsmängeln im

Zusammenhang mit der Implementierung aufzuzeichnen (z. B. Problemstatusberichte, die aus der
Problemdatenbank eines Entwicklers abgeleitet wurden);
f) alle Tools (einschließlich Prüfsoftware, falls zutreffend), die an der Entwicklung und Produktion des TOEs
beteiligt sind, einschließlich der Namen, Versionen, Konfigurationen und Rollen der einzelnen
Entwicklungstools und der zugehörigen Dokumentation.
Bei einem Software-TOE sind „Entwicklungstools“ in der Regel Programmiersprachen und Compiler, und die
„zugehörige Dokumentation“ umfasst Compiler- und Linker-Optionen. Für einen Hardware-TOE könnten
„Entwicklungstools“ Hardware-Designsprachen sein, Simulations- und Synthesetools, Compiler und
„zugehörige Dokumentation“ könnten wieder Compiler-Optionen enthalten.

identifizieren.
185
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
elements angibt.
12.4 Lieferung (ALC_DEL)
12.4.1 Evaluierung der Unteraufgabe (ALC_DEL.1)
Die Zielsetzung dieser Unteraufgabe soll darin bestehen, festzustellen, ob die Lieferdokumente alle Verfahren
beschreiben, die zur Aufrechterhaltung der Sicherheit des TOEs bei der Verteilung des TOEs an den Benutzer
verwendet werden.
12.4.1.2 Eingaben
a) die ST,
b) die Lieferdokumente.
12.4.1.3 Aktion ALC_DEL.1.1E
ISO/IEC 15408-3 ALC_DEL.1.1C: Die Lieferdokumentation muss alle Verfahren beschreiben, die zur
Aufrechterhaltung der Sicherheit bei der Verteilung von Versionen des TOEs an den Verbraucher notwendig sind.
12.4.1.3.1 Workunit ALC_DEL.1-1
Der Evaluator muss die Lieferdokumente untersuchen, um festzustellen, dass sie alle Verfahren beschreiben,
die zur Aufrechterhaltung der Sicherheit bei der Verteilung von Versionen des TOEs oder Teilen davon an den
Verbraucher notwendig sind.
Die Lieferdokumente beschreiben geeignete Verfahren zur Aufrechterhaltung der Sicherheit des TOEs
während der Übertragung des TOEs oder seiner Komponenten und zur Bestimmung der Identifizierung des
TOEs.
Die Lieferdokumente sollten den gesamten TOE abdecken, sie können aber für verschiedene Teile des TOEs
unterschiedliche Verfahren enthalten. Die Evaluierung sollte die gesamten Verfahren berücksichtigen.
186
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Die Lieferverfahren sollten in allen Phasen der Lieferung von der Produktionsumgebung in die Installations-
umgebung (z. B. Verpackung, Lagerung und Verteilung) anwendbar sein. Handelsübliche Gepflogenheiten für
Verpackung und Lieferung können akzeptabel sein. Dazu gehören eine Schrumpfverpackung, ein
Sicherheitsband oder ein versiegelter Umschlag. Für die Verteilung können physische (z. B. öffentliche Post
oder ein privater Verteilungsdienst) oder elektronische (z. B. elektronische Post oder Herunterladen aus dem
Internet) Verfahren verwendet werden.
Kryptographische Prüfsummen oder eine Software-Signatur können vom Entwickler verwendet werden, um
sicherzustellen, dass Manipulationen oder Masquerading erkannt werden können. Manipulationssichere
Siegel zeigen zusätzlich an, ob die Vertraulichkeit verletzt wurde. Bei Software-TOEs kann die Vertraulichkeit
durch die Verwendung einer Verschlüsselung sichergestellt werden. Wenn die Verfügbarkeit Anlass zur Sorge
gibt, könnte ein sicherer Transport erforderlich sein.
Die Auslegung des Begriffs „zur Aufrechterhaltung der Sicherheit notwendig“ muss Folgendes berück-
sichtigen.
Die Art des TOEs (z. B. ob es sich um Software oder Hardware handelt).
Die allgemeine Sicherheitsstufe, die für den TOE durch die gewählte Stufe der Anfälligkeitsbewertung
angegeben wird. Wenn vom TOE verlangt wird, dass er gegen Angreifer mit einem bestimmten Potential
in seiner vorgesehenen Umgebung resistent ist, sollte dies auch für die Lieferung des TOEs gelten. Der
Evaluator sollte feststellen, dass ein ausgewogener Ansatz gewählt wurde, so dass die Lieferung keinen
Schwachpunkt in einem ansonsten sicheren Entwicklungsprozess darstellt.
Die Sicherheitszielsetzungen, die von der ST zur Verfügung gestellt werden. Der Schwerpunkt in den
Lieferdokumenten dürfte auf Maßnahmen liegen, die sich auf die Integrität beziehen, da die Integrität des
TOEs immer wichtig ist. Die Vertraulichkeit und Verfügbarkeit der Lieferung wird jedoch bei der
Lieferung einiger TOEs ein Anliegen sein; Verfahren, die sich auf diese Aspekte der sicheren Lieferung
beziehen, sollten ebenfalls in den Verfahren besprochen werden.
12.4.1.4 Implizite Evaluatorenaktion
ISO/IEC 15408-3 ALC_DEL.1.2D: Der Entwickler muss die Lieferverfahren verwenden.
12.4.1.4.1 Workunit ALC_DEL.1-2
Der Evaluator muss Aspekte des Lieferprozesses untersuchen, um festzustellen, ob die Lieferverfahren
angewendet werden.
Der vom Evaluator gewählte Ansatz zur Prüfung der Anwendung der Lieferverfahren hängt von der Art des
TOEs und vom Lieferprozess selbst ab. Neben der Untersuchung der Verfahren selbst sucht der Evaluator eine
gewisse Vertrauenswürdigkeit, dass sie in der Praxis angewendet werden. Einige mögliche Ansätze sind:
a) eine Besichtigung der Verteilungsstelle(n), wo die praktische Anwendung der Verfahren beobachtet
werden kann;
b) die Untersuchung des TOEs zu irgendeinem Zeitpunkt während der Lieferung oder nachdem der Benutzer
den TOE erhalten hat (z. B. Prüfung auf manipulationssichere Siegel);
c) die Beobachtung, dass das Verfahren in der Praxis angewendet wird, wenn der Evaluator den TOE über
reguläre Kanäle erhält;
d) die Befragung von Endbenutzern hinsichtlich der Art und Weise, wie der TOE geliefert wurde.
187
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Es kann der Fall sein, dass bei einem neu entwickelten TOE die Lieferverfahren noch nicht ausgeübt worden
sind. In diesen Fällen muss sich der Evaluator davon überzeugen, dass geeignete Verfahren und Einrichtungen
für künftige Lieferungen vorhanden sind und dass sich alle beteiligten Mitarbeiter ihrer Verantwortung
bewusst sind. Der Evaluator kann einen „Probelauf“ einer Lieferung verlangen, wenn dies praktisch möglich
ist. Wenn der Entwickler andere ähnliche Produkte hergestellt hat, kann eine Untersuchung der Verfahren bei
ihrer Anwendung nützlich sein, um Vertrauenswürdigkeit zu bieten.
12.5 Entwicklungssicherheit (ALC_DVS)
12.5.1 Evaluierung der Unteraufgabe (ALC_DVS.1)
Zielsetzung dieser Unteraufgabe ist es festzustellen, ob die Sicherheitskontrollen des Entwicklers in der
Entwicklungsumgebung angemessen sind, um die Vertraulichkeit und Integrität des TOEs-Designs und der
Implementierung sicherzustellen, die notwendig ist, um sicherzustellen, dass der sichere Betrieb des TOEs
nicht beeinträchtigt wird.
12.5.1.2 Eingaben
a) die ST,
b) die Entwicklungssicherheitsdokumentation.
Darüber hinaus muss der Evaluator möglicherweise andere Evaluationsbeiträge untersuchen, um

festzustellen, ob die Sicherheitskontrollen klar definiert sind und eingehalten werden. Insbesondere muss der
Evaluator unter Umständen die Konfigurationsmanagement-Dokumentation des Entwicklers untersuchen
(die Eingabe für „Evaluation of sub-activity“ (ALC_CMC.4) „Produktionsunterstützung und
Abnahmeverfahren“ und „Evaluation of sub-activity“ (ALC_CMS.4) „Problemverfolgung der CM-Abdeckung“).
Der Nachweis, dass die Verfahren angewendet werden, ist ebenfalls erforderlich.
12.5.1.3 Aktion ALC_DVS.1.1E
ISO/IEC 15408-3 ALC_DVS.1.1C: Die Entwicklungssicherheitsdokumentation muss alle physischen,

prozeduralen, personellen und anderen Sicherheitsmaßnahmen beschreiben, die zum Schutz der Vertraulichkeit
und Integrität des TOEs-Designs und dessen Implementierung in seiner Entwicklungsumgebung erforderlich sind.
12.5.1.3.1 Workunit ALC_DVS.1-1
Der Evaluator muss die Entwicklungssicherheitsdokumentation untersuchen, um festzustellen, dass sie alle
in der Entwicklungsumgebung verwendeten Sicherheitsmaßnahmen enthält, die zum Schutz der
Vertraulichkeit und Integrität des TOEs-Designs und dessen Implementierung erforderlich sind.
Der Evaluator stellt fest, was erforderlich ist, indem er sich zunächst auf die ST bezieht, um Informationen zu
erhalten, die bei der Bestimmung des erforderlichen Schutzes hilfreich sein können.
Wenn keine expliziten Informationen von der ST verfügbar sind, muss der Evaluator die erforderlichen
Maßnahmen festlegen. In Fällen, in denen die Maßnahmen des Entwicklers als geringer als notwendig erachtet
werden, sollte eine klare Begründung für die Beurteilung gegeben werden, die sich auf eine potentiell
ausnutzbare Anfälligkeit stützt.
188
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Die folgenden Arten von Sicherheitsmaßnahmen werden vom Evaluator bei der Untersuchung der
Dokumentation berücksichtigt:
a) physische Maßnahmen, z. B. physische Zugriffskontrollen, die verwendet werden, um unbefugten Zugriff

auf die Entwicklungsumgebung des TOEs zu verhindern (während der üblichen Arbeitszeiten und zu
anderen Zeiten);
b) prozedurale Maßnahmen, zum Beispiel:
Gewährung des Zugriffs auf die Entwicklungsumgebung oder auf bestimmte Teile der Umgebung wie
z. B. Entwicklungsrechner;
Entzug der Zugriffsrechte, wenn eine Person das Entwicklungsteam verlässt;
Transfer von geschütztem Material innerhalb und außerhalb der Entwicklungsumgebung und
zwischen verschiedenen Entwicklungsstandorten in Übereinstimmung mit definierten
Abnahmeverfahren;
Aufnahme und Begleitung von Besuchern in die Entwicklungsumgebung;
Rollen und Verantwortlichkeiten zur Sicherstellung der kontinuierlichen Anwendung von
Sicherheitsmaßnahmen und der Aufdeckung von Sicherheitsverletzungen;
c) Personal, z. B. alle Kontrollen oder Prüfungen, die durchgeführt werden, um die Vertrauenswürdigkeit
des neuen Entwicklungspersonals festzustellen;
d) andere Sicherheitsmaßnahmen, z. B. die logischen Schutzmaßnahmen auf beliebigen Entwicklungs-
rechnern.
Die Sicherheitsdokumentation für die Entwicklung sollte die Orte, an denen die Entwicklung stattfindet,
identifizieren und die Aspekte der durchgeführten Entwicklung zusammen mit den Sicherheitsmaßnahmen
beschreiben, die an jedem Ort und für Transporte zwischen verschiedenen Orten angewendet werden.
Beispielsweise könnte die Entwicklung an mehreren Einrichtungen innerhalb eines einzigen Gebäudes, an
mehreren Gebäuden am selben Standort oder an mehreren Standorten erfolgen. Transporte von Teilen des
TOEs oder des unfertigen TOEs zwischen verschiedenen Entwicklungsstandorten sind durch „Development
security“ (ALC_DVS) abzudecken, während der Transport des fertigen TOEs zum Verbraucher in „Delivery“
(ALC_DEL) behandelt wird.
Die Entwicklung umfasst die Produktion des TOEs.
Der Evaluator muss die Vertraulichkeits- und Integritätspolitiken der Entwicklung untersuchen, um
festzustellen, ob die eingesetzten Sicherheitsmaßnahmen ausreichend sind.
Der Evaluator sollte untersuchen, ob Folgendes in den Politiken enthalten ist:
a) welche Informationen in Bezug auf die Entwicklung des TOEs vertraulich behandelt werden müssen und
welche Mitglieder des Entwicklungspersonals Zugriff auf solches Material haben dürfen;
b) welches Material vor unbefugten Änderungen geschützt werden muss, um die Integrität des TOEs zu
erhalten, und welche Mitglieder des Entwicklungspersonals dieses Material ändern dürfen.
Der Evaluator sollte feststellen, dass diese Politiken in der Entwicklungssicherheitsdokumentation

beschrieben sind, dass die verwendeten Sicherheitsmaßnahmen gegenüber den Politiken konsistent sind und
dass sie vollständig sind.
189
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Es sollte beachtet werden, dass die Verfahren des Konfigurationsmanagements dazu beitragen, die Integrität
des TOEs zu schützen, und der Evaluator sollte Überschneidungen mit den Workunits vermeiden, die für „CM
capabilities“ (ALC_CMC) durchgeführt wurden. Beispielsweise kann die CM-Dokumentation die Sicherheits-
verfahren beschreiben, die zur Kontrolle der Rollen oder Personen erforderlich sind, die Zugang zur
Entwicklungsumgebung haben sollten und die den TOE modifizieren können.
Während die Anforderungen an die „CM capabilities“ (ALC_CMC) festgelegt sind, hängen die Anforderungen
für die „Development security“ (ALC_DVS), die nur notwendige Maßnahmen vorschreiben, von der Art des
TOEs und von den Informationen ab, die in der ST bereitgestellt werden können. Die Evaluatoren würden
dann feststellen, dass eine solche Politik im Rahmen dieser Unteraufgabe angewandt wurde.
Der Evaluator muss die Entwicklungssicherheitsdokumentation und die damit verbundenen Nachweise
untersuchen, um festzustellen, dass die Sicherheitsmaßnahmen angewendet werden.
In dieser Workunit muss der Evaluator feststellen, dass die in der Entwicklungssicherheitsdokumentation
beschriebenen Sicherheitsmaßnahmen befolgt werden, so dass die Integrität des TOEs und die Vertraulichkeit
der zugehörigen Dokumentation angemessen geschützt werden. Dies könnte zum Beispiel durch die
Untersuchung des vorgelegten dokumentierenden Nachweises festgestellt werden. Der dokumentierende
Nachweis sollte durch eine Besichtigung der Entwicklungsumgebung ergänzt werden. Eine Besichtigung der
Entwicklungsumgebung ermöglicht es dem Evaluator,
a) die Anwendung von Sicherheitsmaßnahmen (z. B. physische Maßnahmen) zu beobachten;
b) dokumentierende Nachweise für die Anwendung der Verfahren zu untersuchen;
c) das Entwicklungspersonal zu befragen, um das Bewusstsein für die Sicherheitspolitiken und -verfahren
der Entwicklung und ihre Verantwortlichkeiten zu prüfen.
Eine Besichtigung des Entwicklungsstandortes ist ein nützliches Mittel, um Vertrauen in die angewandten
Maßnahmen zu gewinnen. Jede Entscheidung, von einer solchen Besichtigung abzusehen, sollte in Absprache
mit der Evaluierungsinstanz getroffen werden.
12.5.2 Evaluierung der Unteraufgabe (ALC_DVS.2)
Zielsetzung dieser Unteraufgabe ist es festzustellen, ob die Sicherheitskontrollen des Entwicklers in der
Entwicklungsumgebung angemessen sind, um die Vertraulichkeit und Integrität des TOEs-Designs und der
Implementierung sicherzustellen, die notwendig ist, um sicherzustellen, dass der sichere Betrieb des TOEs
nicht beeinträchtigt wird. Darüber hinaus soll die Angemessenheit der angewandten Maßnahmen begründet
werden.
12.5.2.2 Eingaben
a) die ST,
b) die Entwicklungssicherheitsdokumentation.
190
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Darüber hinaus muss der Evaluator möglicherweise andere Evaluationsbeiträge untersuchen, um

festzustellen, ob die Sicherheitskontrollen klar definiert sind und eingehalten werden. Insbesondere muss der
Evaluator unter Umständen die Konfigurationsmanagement-Dokumentation des Entwicklers untersuchen
(die Eingabe für „Evaluation of sub-activity“ (ALC_CMC.4) „Produktionsunterstützung“ und Abnahme-
verfahren“ und „Evaluation of sub-activity“ (ALC_CMS.4) „Problemverfolgung der CM-Abdeckung“). Der
Nachweis, dass die Verfahren angewendet werden, ist ebenfalls erforderlich.
ISO/IEC 15408-3 ALC_DVS.2.1C: Die Entwicklungssicherheitsdokumentation die muss alle physischen,

prozeduralen, personellen und anderen Sicherheitsmaßnahmen beschreiben, die zum Schutz der Vertraulichkeit
und Integrität des TOEs-Designs und dessen Implementierung in seiner Entwicklungsumgebung erforderlich sind.
Der Evaluator muss die Entwicklungssicherheitsdokumentation untersuchen, um festzustellen, dass sie alle
in der Entwicklungsumgebung verwendeten Sicherheitsmaßnahmen enthält, die zum Schutz der
Vertraulichkeit und Integrität des TOEs-Designs und dessen Implementierung erforderlich sind.
Der Evaluator stellt fest, was erforderlich ist, indem er sich zunächst auf die ST bezieht, um Informationen zu
erhalten, die bei der Bestimmung des erforderlichen Schutzes hilfreich sein können.
Wenn keine expliziten Informationen von der ST verfügbar sind, muss der Evaluator die erforderlichen
Maßnahmen festlegen. In Fällen, in denen die Maßnahmen des Entwicklers als geringer als notwendig erachtet
werden, sollte eine klare Begründung für die Beurteilung gegeben werden, die sich auf eine potentiell
ausnutzbare Anfälligkeit stützt.
Die folgenden Arten von Sicherheitsmaßnahmen werden vom Evaluator bei der Untersuchung der
Dokumentation berücksichtigt:
a) physische Maßnahmen, z. B. physische Zugriffskontrollen, die verwendet werden, um unbefugten Zugriff

auf die Entwicklungsumgebung des TOEs zu verhindern (während der üblichen Arbeitszeiten und zu
anderen Zeiten);
b) prozedurale Maßnahmen, zum Beispiel:
Gewährung des Zugriffs auf die Entwicklungsumgebung oder auf bestimmte Teile der Umgebung wie
z. B. Entwicklungsrechner;
Entzug der Zugriffsrechte, wenn eine Person das Entwicklungsteam verlässt;
Transfer von geschütztem Material außerhalb der Entwicklungsumgebung und zwischen

verschiedenen Entwicklungsstandorten in Übereinstimmung mit definierten Abnahmeverfahren;
Aufnahme und Begleitung von Besuchern in die Entwicklungsumgebung;
Rollen und Verantwortlichkeiten zur Sicherstellung der kontinuierlichen Anwendung von

Sicherheitsmaßnahmen und der Aufdeckung von Sicherheitsverletzungen;
c) Personal, z. B. alle Kontrollen oder Prüfungen, die durchgeführt werden, um die Vertrauenswürdigkeit
des neuen Entwicklungspersonals festzustellen;
d) andere Sicherheitsmaßnahmen, z. B. die logischen Schutzmaßnahmen auf beliebigen Entwicklungs-

rechnern.
Die Sicherheitsdokumentation für die Entwicklung sollte die Orte, an denen die Entwicklung stattfindet,
identifizieren und die Aspekte der durchgeführten Entwicklung zusammen mit den Sicherheitsmaßnahmen
beschreiben, die an jedem Ort und für Transporte zwischen verschiedenen Orten angewendet werden.
Beispielsweise könnte die Entwicklung an mehreren Einrichtungen innerhalb eines einzigen Gebäudes, an
mehreren Gebäuden am selben Standort oder an mehreren Standorten erfolgen. Transporte von Teilen des
191
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
TOEs oder des unfertigen TOEs zwischen verschiedenen Entwicklungsstandorten sind durch „Development
security“ (ALC_DVS) abzudecken, während der Transport des fertigen TOEs zum Verbraucher in „Delivery“
(ALC_DEL) behandelt wird.
Die Entwicklung umfasst die Produktion des TOEs.
ISO/IEC 15408-3 ALC_DVS.2.2C: Die Entwicklungssicherheitsdokumentation muss begründen, dass die

Sicherheitsmaßnahmen den erforderlichen Schutzgrad bieten, um die Vertraulichkeit und Integrität des TOEs
aufrechtzuerhalten.
Der Evaluator muss die Entwicklungssicherheitsdokumentation untersuchen, um festzustellen, dass eine

angemessene Begründung gegeben wird, warum die Sicherheitsmaßnahmen den notwendigen Schutz bieten,
um die Vertraulichkeit und Integrität des TOEs aufrechtzuerhalten.
Da Angriffe auf den TOE oder die damit verbundenen Informationen in verschiedenen Design- und
Produktionsstadien angenommen werden, müssen die Maßnahmen und Verfahren eine angemessene Ebene
haben, die notwendig ist, um diese Angriffe zu verhindern oder zu erschweren.
Da diese Ebene von dem für den TOE beanspruchten Gesamtangriffspotential (vgl. die gewählte Komponente
der „Vulnerability analysis“ (AVA_VAN) abhängt, soll die Entwicklungssicherheitsdokumentation die zur
Wahrung der Vertraulichkeit und Integrität des TOEs erforderliche Schutzebene begründen. Diese Ebene
muss durch die angewandten Sicherheitsmaßnahmen erreicht werden.
Das Konzept der Schutzmaßnahmen sollte konsistent sein, und die Begründung sollte eine Analyse darüber
enthalten, wie sich die Maßnahmen gegenseitig unterstützen. Alle Aspekte der Entwicklung und Produktion
an allen verschiedenen Standorten mit allen beteiligten Rollen bis zur Lieferung des TOEs sollten analysiert
werden.
Zur Begründung kann eine Analyse der potentiellen Anfälligkeiten unter Berücksichtigung der angewandten
Sicherheitsmaßnahmen gehören.
Es mag ein überzeugendes Argument dafür geben, dass z. B.
die technischen Maßnahmen und Mechanismen der Infrastruktur des Entwicklers ausreichend sind, um
die angemessene Sicherheitsstufe zu halten (z. B. kryptographische Mechanismen sowie physische
Schutzmechanismen, Eigenschaften des CM-Systems (vgl. ALC_CMC.4-5));
das System, das die Darstellung der Implementierung des TOEs enthält (auch bezüglich der Leitlinien-
dokumente), einen wirksamen Schutz gegen logische Angriffe bietet, z. B. durch einen „trojanischen“ Code
oder Viren. Es könnte angemessen sein, wenn die Darstellung der Implementierung auf einem isolierten
System gehalten wird, auf dem nur die für die Wartung notwendige Software installiert wird und danach
keine zusätzliche Software installiert wird.
die in dieses System eingebrachten Daten genau geprüft werden müssen, um zu verhindern, dass
versteckte Funktionen in das System eingebaut werden. Die Wirksamkeit dieser Maßnahmen muss
geprüft werden, z. B. durch den selbstständigen Versuch, Zugriff auf den Rechner zu erhalten, eine
zusätzliche ausführbare Datei (Programm, Makro usw.) zu installieren oder durch logische Angriffe einige
Informationen aus dem Rechner herauszuholen.
Die entsprechenden organisatorischen (verfahrenstechnischen und persönlichen) Maßnahmen werden

bedingungslos durchgesetzt.
192
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss die Vertraulichkeits- und Integritätspolitiken der Entwicklung untersuchen, um
festzustellen, ob die eingesetzten Sicherheitsmaßnahmen ausreichend sind.
Der Evaluator sollte untersuchen, ob Folgendes in den Politiken enthalten ist:
a) welche Informationen in Bezug auf die Entwicklung des TOEs vertraulich behandelt werden müssen und
welche Mitglieder des Entwicklungspersonals Zugriff auf solches Material haben dürfen;
b) welches Material vor unbefugten Änderungen geschützt werden muss, um die Integrität des TOEs zu
erhalten, und welche Mitglieder des Entwicklungspersonals dieses Material ändern dürfen.
Der Evaluator sollte feststellen, dass diese Politiken in der Entwicklungssicherheitsdokumentation

beschrieben sind, dass die verwendeten Sicherheitsmaßnahmen gegenüber den Politiken konsistent sind und
dass sie vollständig sind.
Es sollte beachtet werden, dass die Verfahren des Konfigurationsmanagements dazu beitragen, die Integrität
des TOEs zu schützen, und der Evaluator sollte Überschneidungen mit den Workunits vermeiden, die für „CM
capabilities“ (ALC_CMC) durchgeführt wurden. Beispielsweise kann die CM-Dokumentation die
Sicherheitsverfahren beschreiben, die zur Kontrolle der Rollen oder Personen erforderlich sind, die Zugang
zur Entwicklungsumgebung haben sollten und die den TOE modifizieren können.
Während die Anforderungen an die „CM capabilities“ (ALC_CMC) festgelegt sind, hängen die Anforderungen
für die „Development security“ (ALC_DVS), die nur notwendige Maßnahmen vorschreiben, von der Art des
TOEs und von den Informationen ab, die in der ST bereitgestellt werden können. Beispielsweise kann die ST
eine Sicherheitszielsetzung für die Entwicklungsumgebung festlegen, die erfordert, dass der TOE von
Mitarbeitern entwickelt wird, die über eine Sicherheitsfreigabe verfügen. Die Evaluatoren würden dann
feststellen, dass eine solche Politik im Rahmen dieser Unteraufgabe angewandt wurde.
Der Evaluator muss die Entwicklungssicherheitsdokumentation und die damit verbundenen Nachweise
untersuchen, um festzustellen, dass die Sicherheitsmaßnahmen angewendet werden.
In dieser Workunit muss der Evaluator feststellen, dass die in der Entwicklungssicherheitsdokumentation
beschriebenen Sicherheitsmaßnahmen befolgt werden, so dass die Integrität des TOEs und die Vertraulichkeit
der zugehörigen Dokumentation angemessen geschützt werden. Dies könnte zum Beispiel durch die
Untersuchung des vorgelegten dokumentierenden Nachweises festgestellt werden. Der dokumentierende
Nachweis sollte durch eine Besichtigung der Entwicklungsumgebung ergänzt werden. Eine Besichtigung der
Entwicklungsumgebung ermöglicht es dem Evaluator,
a) die Anwendung von Sicherheitsmaßnahmen (z. B. physische Maßnahmen) zu beobachten;
b) dokumentierende Nachweise für die Anwendung der Verfahren zu untersuchen;
c) das Entwicklungspersonal zu befragen, um das Bewusstsein für die Sicherheitspolitiken und -verfahren
der Entwicklung und ihre Verantwortlichkeiten zu prüfen.
Maßnahmen zu gewinnen. Jede Entscheidung, von einer solchen Besichtigung abzusehen, sollte in Absprache
mit der Evaluierungsinstanz getroffen werden.
193
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
12.6 Mängelbeseitigung (ALC_FLR)
12.6.1 Evaluierung der Unteraufgabe (ALC_FLR.1)
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob der Entwickler Verfahren zur
Mängelbeseitigung eingerichtet hat, die die Verfolgung von Sicherheitsmängeln, die Identifizierung von
Korrekturmaßnahmen und die Verteilung von Informationen über Korrekturmaßnahmen an die Benutzer des
TOEs beschreiben.
12.6.1.2 Eingaben
a) die Dokumentation der Mängelbeseitigungsverfahren.
12.6.1.3 Aktion ALC_FLR.1.1E
ISO/IEC 15408-3 ALC_FLR.1.1C: Die Dokumentation der Verfahren zur Mängelbeseitigung muss die Verfahren
zur Verfolgung aller gemeldeten Sicherheitsmängel in jeder Version des TOEs beschreiben.
12.6.1.3.1 Workunit ALC_FLR.1-1
Der Evaluator muss die Dokumentation der Verfahren zur Mängelbeseitigung untersuchen, um festzustellen,
dass sie die Verfahren beschreibt, die zur Verfolgung aller gemeldeten Sicherheitsmängel in jeder Version des
TOEs verwendet werden.
Die Verfahren beschreiben die Aktionen, die der Entwickler ab dem Zeitpunkt der Meldung jedes vermuteten
Sicherheitsmangels bis zu seiner Behebung ergreift. Dies umfasst den gesamten Zeitrahmen des Mangels, von
der ersten Erkennung über die Feststellung, dass es sich um einen Sicherheitsmangel handelt, bis zur
Behebung des Sicherheitsmangels.
Wenn ein Mangel als nicht sicherheitsrelevant entdeckt wird, besteht (im Sinne der Anforderungen an die
„Flaw remediation“ (ALC_FLR)) keine Notwendigkeit, dass die Verfahren zur Mängelbeseitigung ihn
weiterverfolgen; es muss nur eine Erläuterung dafür gegeben werden, warum der Mangel nicht
sicherheitsrelevant ist.
Diese Anforderungen schreiben zwar nicht vor, dass es für Benutzer des TOEs ein öffentliches Mittel zur
Meldung von Sicherheitsmängeln geben muss, sie schreiben jedoch vor, dass alle gemeldeten Sicherheits-
mängel verfolgt werden müssen. Das heißt, ein gemeldeter Sicherheitsmangel kann nicht einfach ignoriert
werden, weil er von außerhalb der Organisation des Entwicklers kommt.
ISO/IEC 15408-3 ALC_FLR.1.2C: Die Verfahren zur Mängelbeseitigung müssen eine Beschreibung der Art und
der Auswirkung jedes Sicherheitsmangels sowie des Status der Suche nach einer Möglichkeit für ein Beheben
dieses Mangels vorschreiben.
Der Evaluator muss die Verfahren zur Mängelbeseitigung untersuchen, um festzustellen, dass die Anwendung
dieser Verfahren eine Beschreibung jedes Sicherheitsmangels in Bezug auf seine Art und seine Auswirkungen
ergeben würde.
Die Verfahren identifizieren die Aktionen, die vom Entwickler ergriffen werden, um die Art und die
Auswirkungen jedes Sicherheitsmangels ausreichend detailliert zu beschreiben, damit er reproduziert
werden kann. Die Beschreibung der Art eines Sicherheitsmangels befasst sich mit der Frage, ob es sich um
194
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
einen Fehler in der Dokumentation, einen Mangel im Design der TSF, einen Mangel in der Implementierung
der TSF usw. handelt. Die Beschreibung der Auswirkungen des Sicherheitsmangels zeigt auf, welche Teile der
TSF betroffen sind und wie diese Teile betroffen sind. Beispielsweise könnte ein Sicherheitsmangel in der
Implementierung gefunden werden, der die von der TSF durchgesetzte Identifizierung und Authentifizierung
beeinträchtigt, indem die Authentifizierung mit dem Passwort „BACK DOOR“ erlaubt wird.
dieser Verfahren den Status der Suche nach einer Möglichkeit für ein Beheben jedes Sicherheitsmangels
erkennen lässt.
Die Verfahren zur Mängelbeseitigung identifizieren die verschiedenen Stufen von Sicherheitsmängeln. Diese
Unterscheidung umfasst mindestens: vermutete Sicherheitsmängel, die gemeldet wurden, vermutete
Sicherheitsmängel, die als Sicherheitsmängel bestätigt wurden, und Sicherheitsmängel, deren Lösungen
implementiert wurden. Es ist zulässig, zusätzliche Stufen (z. B. gemeldete, aber noch nicht untersuchte Mängel,
Mängel, die noch untersucht werden, Sicherheitsmängel, für die eine Lösung gefunden, aber noch nicht
umgesetzt wurde) einzubeziehen.
ISO/IEC 15408-3 ALC_FLR.1.3C: Die Verfahren zur Mängelbeseitigung müssen vorschreiben, dass für jeden der
Sicherheitsmängel Korrekturmaßnahmen identifiziert werden.
Der Evaluator muss die Verfahren zur Mängelbeseitigung prüfen, um festzustellen, dass die Anwendung
dieser Verfahren die Korrekturmaßnahme für jeden Sicherheitsmangel ermitteln würde.
Die Korrekturmaßnahmen können aus einer Reparatur der Hardware-, Firmware- oder Software-Teile des
TOEs, einer Änderung der TOE-Leitlinien oder aus beidem bestehen. Korrekturmaßnahmen, die eine
Änderung der TOE-Leitlinien darstellen (z. B. Einzelheiten der Verfahrensmaßnahmen, die zur Vermeidung
des Sicherheitsmangels zu ergreifen sind), umfassen sowohl die Maßnahmen, die nur als Zwischenlösung
dienen (bis zur Ausgabe der Reparatur), als auch die Maßnahmen, die als dauerhafte Lösung dienen (wenn
festgestellt wird, dass die Verfahrensmaßnahme die beste Lösung ist).
Wenn die Quelle der Sicherheitsmängel ein Dokumentationsfehler ist, besteht die Korrekturmaßnahme aus
einer Aktualisierung der betroffenen TOE-Leitlinien. Wenn es sich bei der Korrekturmaßnahme um eine
Verfahrensmaßnahme handelt, wird diese Maßnahme eine Aktualisierung der betroffenen TOE-Leitlinien
umfassen, die diese Korrekturverfahren widerspiegelt.
ISO/IEC 15408-3 ALC_FLR.1.4C: Die Dokumentation der Verfahren zur Mängelbeseitigung muss die zur
Bereitstellung von Informationen über Mängel, Korrekturen und Leitlinien für Korrekturmaßnahmen für
TOE-Benutzer verwendeten Methoden beschreiben.
dass sie ein Mittel beschreibt, das den Benutzern des TOEs die notwendigen Informationen über jeden
Sicherheitsmangel zur Verfügung stellt.
Die notwendigen Informationen über jeden Sicherheitsmangel bestehen aus seiner Beschreibung (nicht
notwendigerweise auf dem gleichen Detaillierungsgrad wie derjenige, der als Teil der Workunit ALC_FLR.1-2
zur Verfügung gestellt wird), der vorgeschriebenen Korrekturmaßnahme und allen zugehörigen Leitlinien zur
Umsetzung der Korrektur.
195
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Benutzer des TOEs können solche Informationen, Korrekturen und Dokumentationsaktualisierungen auf
verschiedene Weise erhalten, z. B. durch Veröffentlichung auf einer Website, durch Zusendung an Benutzer
des TOEs oder durch Vorkehrungen für den Entwickler zur Installation der Korrektur. In Fällen, in denen die
Mittel zur Bereitstellung dieser Informationen eine vom TOE-Benutzer einzuleitende Aktion erfordern, prüft
der Evaluator alle TOE-Leitlinien, um sicherzustellen, dass sie Anweisungen zum Abrufen der Informationen
enthalten.
Die einzige Metrik zur Beurteilung der Angemessenheit des Verfahrens, das für die Bereitstellung der
Informationen, Korrekturen und Leitlinien verwendet wird, besteht darin, dass eine begründete Erwartung
besteht, dass die Benutzer des TOEs diese Informationen erhalten oder erhalten können. Es ist zum Beispiel
das Verfahren der Verbreitung zu bedenken, bei dem die erforderlichen Daten einen Monat lang auf einer
Website gepostet werden und die Benutzer des TOEs wissen, dass dies geschehen wird und wann es
geschehen wird. Dies mag nicht besonders angemessen oder effektiv sein (wie z. B. ein permanenter Beitrag
auf der Website), dennoch ist es möglich, dass der Benutzer des TOEs die notwendigen Informationen erhalten
könnte. Wenn die Informationen andererseits nur eine Stunde lang auf der Website gepostet wurden, die
Benutzer des TOEs jedoch keine Möglichkeit hatten, dies oder den Zeitpunkt des Beitrags zu erfahren, ist es
unausführbar, dass sie jemals die erforderlichen Informationen erhalten würden.
TOEs beschreiben. Zusätzlich bestimmt diese Unteraufgabe, ob die Verfahren des Entwicklers das Beheben
von Sicherheitsmängeln, den Empfang von Mängelberichten von TOE-Benutzern und die Zusicherung, dass
die Korrekturen keine neuen Sicherheitsmängel einführen, vorsehen.
Damit der Entwickler in der Lage ist, auf Berichte von TOE-Benutzern über Sicherheitsmängel angemessen zu
reagieren, müssen die Benutzer des TOEs verstehen, wie sie Berichte über Sicherheitsmängel an den
Entwickler senden können, und die Entwickler müssen wissen, wie sie diese Berichte erhalten können. An den
TOE-Benutzer gerichtete Leitlinien zur Mängelbeseitigung stellen sicher, dass die TOE-Benutzer wissen, wie
sie mit dem Entwickler kommunizieren können; die Mängelbeseitigungsverfahren beschreiben die Rolle des
Entwicklers bei dieser Kommunikation
12.6.2.2 Eingaben
a) die Dokumentation der Mängelbeseitigungsverfahren,
b) die Dokumentation der Mängelbeseitigungsleitlinien.
196
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
ergeben würde.
TSF betroffen sind und wie diese Teile betroffen sind. Zum Beispiel könnte ein Sicherheitsmangel in der
beeinträchtigt, indem die Authentifizierung mit dem Passwort „BACKDOOR“ erlaubt wird.
dieser Verfahren den Status der Feststellung einer Korrektur für jeden Sicherheitsmangel erkennen lässt.
197
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
enthalten.
ISO/IEC 15408-3 ALC_FLR.2.5C: Die Verfahren zur Mängelbeseitigung müssen ein Mittel beschreiben, mit dem
der Entwickler von TOE-Benutzern Berichte und Anfragen zu vermuteten Sicherheitsmängeln im TOE erhält.
Der Evaluator muss die Verfahren zur Mängelbeseitigung untersuchen, um festzustellen, dass sie Verfahren
beschreiben, mit denen der Entwickler Berichte über Sicherheitsmängel oder Anfragen zum Beheben solcher
Mängel akzeptieren kann.
Die Verfahren stellen sicher, dass die Benutzer des TOEs über ein Mittel verfügen, durch das sie mit dem
Entwickler des TOEs kommunizieren können. Durch eine Kontaktmöglichkeit mit dem Entwickler kann der
Benutzer Sicherheitsmängel melden, sich über den Status von Sicherheitsmängeln erkundigen oder das
Beheben von Mängeln verlangen. Diese Kontaktmöglichkeit kann Teil einer allgemeineren Kontaktmöglichkeit
für die Meldung von nicht sicherheitsbezogenen Problemen sein.
Die Verwendung dieser Verfahren ist nicht auf die Benutzer des TOEs beschränkt; allerdings werden nur die
Benutzer des TOEs aktiv mit den Einzelheiten dieser Verfahren versorgt. Andere, die möglicherweise Zugriff
auf den TOE haben oder mit dem TOE vertraut sind, können die gleichen Verfahren anwenden, um Berichte
198
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
an den Entwickler zu übermitteln, von dem dann erwartet wird, dass er sie bearbeitet. Jegliche Art der
Übermittlung von Berichten an den Entwickler, die nicht von diesem identifiziert wurden, liegt außerhalb des
Anwendungsbereichs dieser Workunit; Berichte, die mit anderen Mitteln erstellt wurden, müssen nicht
behandelt werden.
ISO/IEC 15408-3 ALC_FLR.2.6C: Die Verfahren zur Bearbeitung gemeldeter Sicherheitsmängel müssen
sicherstellen, dass alle gemeldeten Mängel behoben und die Verfahren zur Mängelbeseitigung den TOE-Benutzern
dargelegt werden.
dieser Verfahren dazu beitragen würde, dass jeder gemeldete Mangel behoben wird.
Die Verfahren zur Mängelbeseitigung decken nicht nur die von den Entwicklern entdeckten und gemeldeten
Sicherheitsmängel ab, sondern auch die von den Benutzern des TOEs gemeldeten Sicherheitsmängel. Die
Verfahren sind ausreichend detailliert, so dass sie beschreiben, wie sichergestellt wird, dass jeder gemeldete
Sicherheitsmangel behoben wird. Die Verfahren enthalten vernünftige Schritte, die Fortschritte aufzeigen, die
zu einer letztendlichen, unvermeidlichen Lösung führen.
Die Verfahren beschreiben den Prozess, der von dem Punkt, an dem der vermutete Sicherheitsmangel als
Sicherheitsmangel festgestellt wird, bis zu dem Punkt, an dem er behoben wird, durchgeführt wird.
dieser Verfahren dazu beitragen würde, sicherzustellen, dass den Benutzern des TOEs für jeden
Sicherheitsmangel Verfahren zur Mängelbeseitigung zur Verfügung gestellt werden.
Sicherheitsmangel festgestellt wird, bis zu dem Punkt, an dem er behoben wird, durchgeführt wird. Die
Verfahren zur Lieferung von Korrekturmaßnahmen sollten gegenüber den Sicherheitszielsetzungen
konsistent sein; sie müssen nicht notwendigerweise mit den Verfahren zur Lieferung des TOEs identisch sein,
die zur Erfüllung von ALC_DEL dokumentiert sind, wenn sie in den Vertrauenswürdigkeitsanforderungen
enthalten sind. Wenn z. B. der Hardware-Teil eines TOEs ursprünglich durch einen gebundenen Kurier
geliefert wurde, würde erwartet werden, dass Aktualisierungen der Hardware, die sich aus der
Mängelbeseitigung ergeben, ebenfalls durch einen gebundenen Kurier verteilt werden. Aktualisierungen, die
nicht mit der Mängelbeseitigung zusammenhängen, würden den Verfahren folgen, die in der Dokumentation
festgelegt sind, die die Anforderungen der „Delivery“ (ALC_DEL) erfüllen.
ISO/IEC 15408-3 ALC_FLR.2.7C: Die Verfahren zur Bearbeitung gemeldeter Sicherheitsmängel müssen die
Gewähr bieten, dass durch das Beheben dieser Sicherheitsmängel keine neuen Mängel eingeführt werden.
Der Evaluator muss die Verfahren zur Mängelbeseitigung untersuchen, um festzustellen, ob die Anwendung
dieser Verfahren die Gewähr dafür bieten würde, dass die potentielle Korrektur keine nachteiligen
Auswirkungen hat.
Durch Analyse, Prüfung oder eine Kombination aus beiden kann der Entwickler die Wahrscheinlichkeit
verringern, dass beim Beheben eines Sicherheitsmangels nachteilige Auswirkungen auftreten. Der Evaluator
beurteilt, ob die Verfahren im Einzelnen angeben, wie die notwendige Mischung aus Analyse- und
Prüfaktionen für eine vorgegebene Korrektur bestimmt werden soll.
199
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator stellt auch fest, dass für Fälle, in denen die Quelle des Sicherheitsmangels ein Dokumentations-
problem ist, die Verfahren die Mittel zum Schutz gegen die Einführung von Widersprüchen mit anderen
Dokumentationen enthalten.
ISO/IEC 15408-3 ALC_FLR.2.8C: Die Leitlinien zur Mängelbeseitigung müssen ein Mittel beschreiben, mit dem
TOE-Benutzer dem Entwickler vermutete Sicherheitsmängel des TOEs melden.
12.6.2.3.10Workunit ALC_FLR.2-10
Der Evaluator muss die Leitlinien zur Mängelbeseitigung untersuchen, um festzustellen, ob die Anwendung
dieser Verfahren dazu führen würde, dass der TOE-Benutzer Berichte über vermutete Sicherheitsmängel oder
Anfragen zum Beheben solcher Mängel zur Verfügung stellen kann.
Die Leitlinien stellen sicher, dass die Benutzer des TOEs über ein Mittel verfügen, durch das sie mit dem
Beheben von Mängeln verlangen.
TOEs beschreiben. Zusätzlich bestimmt diese Unteraufgabe, ob die Verfahren des Entwicklers das Beheben
von Sicherheitsmängeln, den Empfang von Mängelberichten von TOE-Benutzern, die Zusicherung, dass die
Korrekturen keine neuen Sicherheitsmängel einführen, die Einrichtung einer Kontaktstelle für jeden
TOE-Benutzer und die rechtzeitige Ausgabe von Korrekturmaßnahmen an die TOE-Benutzer vorsehen.
Damit der Entwickler in der Lage ist, auf Berichte von TOE-Benutzern über Sicherheitsmängel angemessen zu
reagieren, müssen die Benutzer des TOEs verstehen, wie sie Berichte über Sicherheitsmängel an den
Entwickler senden können, und die Entwickler müssen wissen, wie sie diese Berichte erhalten können. An den
TOE-Benutzer gerichtete Leitlinien zur Mängelbeseitigung stellen sicher, dass die TOE-Benutzer wissen, wie
sie mit dem Entwickler kommunizieren können; die Mängelbeseitigungsverfahren beschreiben die Rolle des
Entwicklers bei dieser Kommunikation.
12.6.3.2 Eingaben
a) die Dokumentation der Mängelbeseitigungsverfahren,
b) die Dokumentation der Mängelbeseitigungsleitlinien.
200
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
ergeben würde.
TSF betroffen sind und wie diese Teile betroffen sind. Zum Beispiel könnte ein Sicherheitsmangel in der
beeinträchtigt, indem die Authentifizierung mit dem Passwort „BACKDOOR“ erlaubt wird.
dieser Verfahren den Status der Suche nach einer Möglichkeit für ein Beheben jedes Sicherheitsmangels
erkennen lässt.
201
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
enthalten.
Für TOE-Benutzer, die sich beim Entwickler registrieren lassen (siehe Workunit ALC_FLR.3-12), ist die passive
Verfügbarkeit dieser Informationen nicht ausreichend. Die Entwickler müssen die Informationen (oder eine
Benachrichtigung über ihre Verfügbarkeit) aktiv an registrierte TOE-Benutzer senden.
ISO/IEC 15408-3 ALC_FLR.3.5C: Die Verfahren zur Mängelbeseitigung müssen ein Mittel beschreiben, mit dem
der Entwickler von TOE-Benutzern Berichte und Anfragen zu vermuteten Sicherheitsmängeln im TOE erhält.
dieser Verfahren dazu führen würde, dass der Entwickler vom TOE-Benutzer Berichte über vermutete
Sicherheitsmängel oder Anfragen zur Behebung solcher Mängel erhält.
Die Verfahren stellen sicher, dass die Benutzer des TOEs über ein Mittel verfügen, durch das sie mit dem
Beheben von Mängeln verlangen. Diese Kontaktmöglichkeit kann Teil einer allgemeineren Kontaktmöglichkeit
für die Meldung von nicht sicherheitsbezogenen Problemen sein.
202
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Die Verwendung dieser Verfahren ist nicht auf die Benutzer des TOEs beschränkt; allerdings werden nur die
Benutzer des TOEs aktiv mit den Einzelheiten dieser Verfahren versorgt. Andere, die möglicherweise Zugriff
auf den TOE haben oder mit dem TOE vertraut sind, können die gleichen Verfahren anwenden, um Berichte
an den Entwickler zu übermitteln, von dem dann erwartet wird, dass er sie bearbeitet. Jegliche Art der
Übermittlung von Berichten an den Entwickler, die nicht von diesem identifiziert wurden, liegt außerhalb des
Anwendungsbereichs dieser Workunit; Berichte, die mit anderen Mitteln erstellt wurden, müssen nicht
behandelt werden.
ISO/IEC 15408-3 ALC_FLR.3.6C: Die Verfahren zur Mängelbeseitigung müssen ein Verfahren enthalten, das eine
rechtzeitige Reaktion und die automatische Verteilung von Berichten über Sicherheitsmängel und die damit
verbundenen Korrekturen an registrierte Benutzer, die von dem Sicherheitsmangel betroffen sein könnten,
erfordert.
dieser Verfahren dazu führen würde, dass den registrierten Benutzern des TOEs, die betroffen sein könnten,
rechtzeitig Berichte über jeden Sicherheitsmangel und die damit verbundenen Korrekturen zur Verfügung
gestellt werden.
Die Frage der Rechtzeitigkeit gilt sowohl für die Ausstellung von Berichten über Sicherheitsmängel als auch
für die damit verbundenen Korrekturen. Diese müssen jedoch nicht gleichzeitig ausgestellt werden. Es wird
anerkannt, dass Mängelberichte erstellt und herausgegeben werden sollten, sobald eine Zwischenlösung
gefunden wird, selbst wenn diese Lösung so drastisch ist wie das Abschalten des TOEs. Ebenso sollte, wenn
eine dauerhaftere (und weniger drastische) Lösung gefunden wird, diese ohne unangemessene Verzögerung
herausgegeben werden.
Es ist unnötig, die Empfänger der Berichte und der damit verbundenen Korrekturen auf diejenigen Benutzer
des TOEs zu beschränken, die von dem Sicherheitsmangel betroffen sein könnten; es ist zulässig, dass alle
Benutzer des TOEs solche Berichte und Korrekturen für alle Sicherheitsmängel erhalten, sofern dies
rechtzeitig geschieht.
dieser Verfahren zu einer automatischen Verteilung der Berichte und der damit verbundenen Korrekturen an
die registrierten Benutzer des TOEs führen würde, die davon betroffen sein könnten.
Automatische Verteilung bedeutet nicht, dass bei dem Verteilungsverfahren keine menschliche Interaktion
erlaubt ist. Tatsächlich könnte das Verteilungsverfahren vollständig aus manuellen Verfahren bestehen,
vielleicht durch ein genau überwachtes Verfahren mit vorgeschriebener Eskalation bei fehlender Ausgabe von
Berichten oder Korrekturen.
Es ist unnötig, die Empfänger der Berichte und der damit verbundenen Korrekturen auf diejenigen Benutzer
des TOEs zu beschränken, die von dem Sicherheitsmangel betroffen sein könnten; es ist zulässig, dass alle
Benutzer des TOEs solche Berichte und Korrekturen für alle Sicherheitsmängel erhalten, sofern dies
automatisch geschieht.
ISO/IEC 15408-3 ALC_FLR.3.7C: Die Verfahren zur Bearbeitung gemeldeter Sicherheitsmängel müssen
sicherstellen, dass alle gemeldeten Mängel behoben und die Verfahren zur Mängelbeseitigung den TOE-Benutzern
dargelegt werden.
203
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
dieser Verfahren dazu beitragen würde, dass jeder gemeldete Mangel behoben wird.
Die Verfahren zur Mängelbeseitigung decken nicht nur die von den Entwicklern entdeckten und gemeldeten
Sicherheitsmängel ab, sondern auch die von den Benutzern des TOEs gemeldeten Sicherheitsmängel. Die
Verfahren sind ausreichend detailliert, so dass sie beschreiben, wie sichergestellt wird, dass jeder gemeldete
Sicherheitsmangel behoben wird. Die Verfahren enthalten vernünftige Schritte, die Fortschritte aufzeigen, die
zu einer letztendlichen, unvermeidlichen Lösung führen.
Sicherheitsmangel festgestellt wird, bis zu dem Punkt, an dem er behoben wird, durchgeführt wird.
dieser Verfahren dazu beitragen würde, sicherzustellen, dass den Benutzern des TOEs für jeden
Sicherheitsmangel Verfahren zur Mängelbeseitigung zur Verfügung gestellt werden.
Sicherheitsmangel festgestellt wird, bis zu dem Punkt, an dem er behoben wird, durchgeführt wird. Die
Verfahren zur Lieferung von Behebungsverfahren sollten gegenüber den Sicherheitszielsetzungen konsistent
sein; sie müssen nicht notwendigerweise mit den Verfahren zur Lieferung des TOEs identisch sein, die zur
Erfüllung der „Delivery“ (ALC_DEL) dokumentiert sind, wenn sie in den Vertrauenswürdigkeitsanforderungen
enthalten sind. Wenn z. B. der Hardware-Teil eines TOEs ursprünglich durch einen gebundenen Kurier
geliefert wurde, würde erwartet werden, dass Aktualisierungen der Hardware, die sich aus der
Mängelbeseitigung ergeben, ebenfalls durch einen gebundenen Kurier verteilt werden. Aktualisierungen, die
nicht mit der Mängelbeseitigung zusammenhängen, würden den Verfahren folgen, die in der Dokumentation
festgelegt sind, die die Anforderungen der „Delivery“ (ALC_DEL) erfüllen.
ISO/IEC 15408-3 ALC_FLR.3.8C: Die Verfahren zur Bearbeitung gemeldeter Sicherheitsmängel müssen die
Gewähr bieten, dass durch das Beheben dieser Sicherheitsmängel keine neuen Mängel eingeführt werden.
dieser Verfahren die Gewähr dafür bieten würde, dass die potentielle Korrektur keine nachteiligen
Auswirkungen hat.
Durch Analyse, Prüfung oder eine Kombination aus beiden kann der Entwickler die Wahrscheinlichkeit
verringern, dass beim Beheben eines Sicherheitsmangels nachteilige Auswirkungen auftreten. Der Evaluator
beurteilt, ob die Verfahren im Einzelnen angeben, wie die notwendige Mischung aus Analyse- und
Prüfaktionen für eine vorgegebene Korrektur bestimmt werden soll.
Der Evaluator stellt auch fest, dass für Fälle, in denen die Quelle des Sicherheitsmangels ein Dokumentations-
problem ist, die Verfahren die Mittel zum Schutz gegen die Einführung von Widersprüchen mit anderen
Dokumentationen enthalten.
TOE-Benutzer dem Entwickler vermutete Sicherheitsmängel des TOEs melden.
204
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss die Leitlinien zur Mängelbeseitigung untersuchen, um festzustellen, ob die Anwendung
dieser Verfahren dazu führen würde, dass der TOE-Benutzer Berichte über vermutete Sicherheitsmängel oder
Anfragen zum Beheben solcher Mängel zur Verfügung stellen kann.
Die Leitlinien stellen sicher, dass die Benutzer des TOEs über ein Mittel verfügen, durch das sie mit dem
Beheben von Mängeln verlangen.
sich die TOE-Benutzer beim Entwickler registrieren lassen können, um Anspruch auf Berichte über
Sicherheitsmängel und Korrekturen zu haben.
Der Evaluator muss die Leitlinien zur Mängelbeseitigung untersuchen, um festzustellen, dass sie ein Mittel
beschreiben, das es den TOE-Benutzern ermöglicht, sich beim Entwickler zu registrieren.
Die TOE-Benutzer in die Lage zu versetzen, sich beim Entwickler zu registrieren, bedeutet einfach, dass es für
jeden TOE-Benutzer eine Möglichkeit gibt, dem Entwickler eine Kontaktstelle zur Verfügung zu stellen; diese
Kontaktstelle soll dazu verwendet werden, dem TOE-Benutzer Informationen über Sicherheitsmängel, die
diesen TOE-Benutzer betreffen könnten, zusammen mit allen Korrekturen des Sicherheitsmangels zur
Verfügung zu stellen. Die Registrierung des TOEs-Benutzers kann als Teil der Standardverfahren durchgeführt
werden, die TOE-Benutzer durchlaufen, um sich gegenüber dem Entwickler zu identifizieren, eine Software-
Lizenz zu registrieren oder Aktualisierungen und andere nützliche Informationen zu erhalten.
Es muss nicht ein registrierter TOE-Benutzer je Installation des TOEs sein; es würde ausreichen, wenn es einen
registrierten TOE-Benutzer für eine Organisation gäbe. Beispielsweise könnte ein TOE-Benutzer in einem
Unternehmen eine zentrale Beschaffungsstelle für alle seine Standorte haben. In diesem Fall wäre die
Beschaffungsstelle als Kontaktstelle für alle Standorte dieses TOE-Benutzers ausreichend, so dass alle
TOE-Installationen des TOEs-Benutzers eine registrierte Kontaktstelle haben.
In jedem Fall muss es möglich sein, jeden TOE, der zu einer Organisation geliefert wird, zuzuordnen, um
sicherzustellen, dass es für jeden TOE einen registrierten Benutzer gibt. Bei Organisationen, die viele
verschiedene Adressen haben, wird dadurch sichergestellt, dass es keinen Benutzer gibt, von dem
fälschlicherweise angenommen wird, dass er von einem registrierten TOE-Benutzer abgedeckt wird.
Es sollte beachtet werden, dass sich die TOE-Benutzer nicht registrieren müssen; ihnen muss lediglich ein
Mittel dafür zur Verfügung gestellt werden. Benutzern, die sich für eine Registrierung entscheiden, müssen
die Informationen (oder eine Benachrichtigung über ihre Verfügbarkeit) jedoch direkt zugeschickt werden.
ISO/IEC 15408-3 ALC_FLR.3.11C: Die Leitlinien zur Mängelbeseitigung müssen die spezifischen Kontaktstellen
für alle Berichte und Anfragen zu Sicherheitsaspekten im Zusammenhang mit dem TOE identifizieren.
Der Evaluator muss die Leitlinien zur Mängelbeseitigung untersuchen, um festzustellen, dass er spezifische
Kontaktstellen für Benutzerberichte und Anfragen zu Sicherheitsfragen im Zusammenhang mit dem TOE
benennt.
Die Leitlinien enthalten ein Mittel, mit dem registrierte TOE-Benutzer mit dem Entwickler interagieren
können, um entdeckte Sicherheitsmängel im TOE zu melden oder Anfragen zu entdeckten Sicherheitsmängeln
im TOE zu stellen.
205
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
12.7 Definition des Lebenszyklus (ALC_LCD)
12.7.1 Evaluierung der Unteraufgabe (ALC_LCD.1)
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob der Entwickler ein dokumentiertes Modell
des Lebenszyklus des TOEs verwendet hat.
12.7.1.2 Eingaben
a) die ST,
b) die Dokumentation zur Definition des Lebenszyklus.
12.7.1.3 Aktion ALC_LCD.1.1E
ISO/IEC 15408-3 ALC_LCD.1.1C: Die Dokumentation zur Definition des Lebenszyklus muss das für die
Entwicklung und Wartung des TOEs verwendete Modell beschreiben.
12.7.1.3.1 Workunit ALC_LCD.1-1
Der Evaluator muss die dokumentierte Beschreibung des verwendeten Lebenszyklusmodells untersuchen,
um festzustellen, dass es den Entwicklungs- und Wartungsprozess abdeckt.
Die Beschreibung des Lebenszyklusmodells sollte Folgendes beinhalten:
a) Informationen über die Lebenszyklusphasen des TOEs und die Grenzen zwischen den nachfolgenden
Phasen;
b) Informationen über die vom Entwickler verwendeten Verfahren, Tools und Techniken (z. B. für Design,
Kodierung, Prüfen, Fehlerbehebung);
c) eine allgemeine Managementstruktur, die die Anwendung der Verfahren regelt (z. B. eine Identifizierung
und Beschreibung der einzelnen Verantwortlichkeiten für jedes der Verfahren, die für den vom
Lebenszyklusmodell abgedeckten Entwicklungs- und Wartungsprozess erforderlich sind);
d) Informationen darüber, welche Teile des TOEs von Unterauftragnehmern geliefert werden, falls
Unterauftragnehmer beteiligt sind.
Die „Evaluation of sub-activity“ (ALC_LCD.1) erfordert nicht, dass das verwendete Modell mit einem Standard-
Lebenszyklusmodell übereinstimmt.
ISO/IEC 15408-3 ALC_LCD.1.2C: Das Lebenszyklusmodell muss die notwendige Kontrolle über die Entwicklung
und Wartung des TOEs sicherstellen.
Der Evaluator muss das Lebenszyklusmodell untersuchen, um festzustellen, dass die Verwendung der durch
das Lebenszyklusmodell beschriebenen Verfahren, Tools und Techniken den notwendigen positiven Beitrag
zur Entwicklung und Wartung des TOEs leisten wird.
Die im Lebenszyklusmodell enthaltenen Informationen geben dem Evaluator die Gewissheit, dass die
angenommenen Entwicklungs- und Wartungsverfahren die Wahrscheinlichkeit von Sicherheitsmängeln
minimieren würden. Wenn das Lebenszyklusmodell beispielsweise den Überprüfungsprozess beschreibt,
206
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
aber keine Vorkehrungen für die Aufzeichnung von Änderungen an Komponenten vorsieht, dann ist der
Evaluator möglicherweise weniger zuversichtlich, dass keine Fehler in den TOE eingebracht werden. Der
Evaluator kann weitere Vertrauenswürdigkeit gewinnen, indem er die Beschreibung des Modells mit dem
Verständnis des Entwicklungsprozesses vergleicht, das er bei der Durchführung anderer Evaluatorenaktionen
im Zusammenhang mit der Entwicklung des TOEs gewonnen hat (z. B. die unter „CM capabilities“ (ALC_CMC)).
Identifizierte Mängel im Lebenszyklusmodell sind dann bedenklich, wenn sie aller Voraussicht nach entweder
versehentlich oder absichtlich zur Einführung von Mängeln in den TOE führen können.
ISO/IEC 15408 schreibt keinen bestimmten Entwicklungsansatz vor, und jeder sollte anhand der Leistung
beurteilt werden. Beispielsweise können Spiral-, Rapid-Prototyping- und Wasserfallansätze für das Design
verwendet werden, um einen hochwertigen TOE zu produzieren, wenn sie in einer kontrollierten Umgebung
angewendet werden.
12.7.2 Evaluierung der Unteraufgabe (ALC_LCD.2)
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob der Entwickler ein dokumentiertes und
messbares Modell des Lebenszyklus des TOEs verwendet hat.
12.7.2.2 Eingaben
a) die ST,
b) die Dokumentation zur Definition des Lebenszyklus,
c) Informationen zur verwendeten Norm,
d) die Dokumentation zum Ergebnis des Lebenszyklus.
12.7.2.3 Aktion ALC_LCD.2.1E
ISO/IEC 15408-3 ALC_LCD.2.1C: Die Dokumentation zur Definition des Lebenszyklus muss das für die
Entwicklung und Wartung des TOEs verwendete Modell beschreiben, einschließlich der Einzelheiten seiner
arithmetischen Parameter und/oder Metriken, die zur Messung der Qualität des TOEs und/oder seiner
Entwicklung verwendet werden.
Der Evaluator muss die dokumentierte Beschreibung des verwendeten Lebenszyklusmodells untersuchen,
um festzustellen, dass es den Entwicklungs- und Wartungsprozess abdeckt, einschließlich der Einzelheiten
seiner arithmetischen Parameter und/oder Metriken, die zur Messung der Entwicklung des TOEs verwendet
werden.
Die Beschreibung des Lebenszyklusmodells beinhaltet Folgendes:
a) Informationen über die Lebenszyklusphasen des TOEs und die Grenzen zwischen den nachfolgenden
Phasen;
b) Informationen über die vom Entwickler verwendeten Verfahren, Tools und Techniken (z. B. für Design,
Kodierung, Prüfen, Fehlerbehebung);
c) eine allgemeine Managementstruktur, die die Anwendung der Verfahren regelt (z. B. eine Identifizierung
und Beschreibung der einzelnen Verantwortlichkeiten für jedes der Verfahren, die für den vom
Lebenszyklusmodell abgedeckten Entwicklungs- und Wartungsprozess erforderlich sind);
207
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
d) Informationen darüber, welche Teile des TOEs von Unterauftragnehmern geliefert werden, falls
Unterauftragnehmer beteiligt sind;
e) Informationen über die Parameter/Metriken, die zur Messung der TOE-Entwicklung verwendet werden.
Metriknormen enthalten in der Regel Leitfäden für die Messung und Produktion zuverlässiger Produkte
und decken die Aspekte Zuverlässigkeit, Qualität, Leistung, Komplexität und Kosten ab. Für die
Evaluierung sind all jene Metriken von Bedeutung, die zur Erhöhung der Qualität durch Verringerung der
Fehlerwahrscheinlichkeit und damit wiederum zur Erhöhung der Vertrauenswürdigkeit in die Sicherheit
des TOEs verwendet werden.
ISO/IEC 15408-3 ALC_LCD.2.2C: Das Lebenszyklusmodell muss die notwendige Kontrolle über die Entwicklung
und Wartung des TOEs sicherstellen.
Der Evaluator muss das Lebenszyklusmodell untersuchen, um festzustellen, dass die Verwendung der durch
das Lebenszyklusmodell beschriebenen Verfahren, Tools und Techniken den notwendigen positiven Beitrag
zur Entwicklung und Wartung des TOEs leisten wird.
Die im Lebenszyklusmodell enthaltenen Informationen geben dem Evaluator die Gewissheit, dass die
angenommenen Entwicklungs- und Wartungsverfahren die Wahrscheinlichkeit von Sicherheitsmängeln
minimieren würden. Wenn das Lebenszyklusmodell beispielsweise den Überprüfungsprozess beschreibt,
aber keine Vorkehrungen für die Aufzeichnung von Änderungen an Komponenten vorsieht, dann ist der
Evaluator möglicherweise weniger zuversichtlich, dass keine Fehler in den TOE eingebracht werden. Der
Evaluator kann weitere Vertrauenswürdigkeit gewinnen, indem er die Beschreibung des Modells mit dem
Verständnis des Entwicklungsprozesses vergleicht, das er bei der Durchführung anderer Evaluatorenaktionen
im Zusammenhang mit der Entwicklung des TOEs gewonnen hat (z. B. die unter „CM capabilities“ (ALC_CMC)).
Identifizierte Mängel im Lebenszyklusmodell sind dann bedenklich, wenn sie aller Voraussicht nach entweder
versehentlich oder absichtlich zur Einführung von Mängeln in den TOE führen können.
ISO/IEC 15408 schreibt keinen bestimmten Entwicklungsansatz vor, und jeder sollte anhand der Leistung
beurteilt werden. Beispielsweise können Spiral-, Rapid-Prototyping- und Wasserfallansätze für das Design
verwendet werden, um einen hochwertigen TOE zu produzieren, wenn sie in einer kontrollierten Umgebung
angewendet werden.
Für die im Lebenszyklusmodell verwendeten Metriken/Maße müssen Nachweise erbracht werden, die zeigen,
wie diese Metriken/Maße sinnvoll zur Minimierung der Wahrscheinlichkeit von Mängeln beitragen. Dies kann
als Gesamtziel für die Messung im ALC-Kontext betrachtet werden. Infolgedessen müssen die Metriken/Maße
auf der Grundlage ihrer Fähigkeit ausgewählt werden, dieses Gesamtziel zu erreichen oder dazu beizutragen.
In erster Linie ist eine Metrik/Maßeinheit in Bezug auf den ALC geeignet, wenn eine Korrelation zwischen der
Metrik/Maßeinheit und der Anzahl der Mängel mit einer gewissen Zuverlässigkeit angegeben werden kann.
Aber auch eine Metrik/Maßeinheit, die für Management-Zwecke wie für die Planung und Überwachung der
TOE-Entwicklung nützlich ist, ist hilfreich, da bei schlecht geführten Projekten die Gefahr besteht, dass
schlechte Qualität produziert und Mängel eingeführt werden.
Es kann möglich sein, Metriken zur Qualitätsverbesserung zu verwenden, für die diese Verwendung nicht
offensichtlich ist. Beispielsweise kann eine Metrik zur Schätzung der zu erwartenden Kosten einer
Produktentwicklung der Qualität helfen, wenn der Entwickler nachweisen kann, dass diese zur Bereitstellung
eines angemessenen Budgets für Entwicklungsprojekte verwendet wird und dass dies dazu beiträgt,
Qualitätsprobleme aufgrund von Ressourcenknappheit zu vermeiden.
Es ist nicht erforderlich, dass jeder einzelne Schritt im Lebenszyklus des TOEs messbar ist. Der Evaluator sollte
jedoch aus der Beschreibung der Maßnahmen und Verfahren erkennen, dass die Metriken geeignet sind, die
Gesamtqualität des TOEs zu kontrollieren und dadurch mögliche Sicherheitsmängel zu minimieren.
ISO/IEC 15408-3 ALC_LCD.2.3C: Die Dokumentation zum Ergebnis des Lebenszyklus muss die Ergebnisse der
Messungen der TOE-Entwicklung unter Verwendung des messbaren Lebenszyklusmodells bereitstellen.
208
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss die Dokumentation zum Ergebnis des Lebenszyklus untersuchen, um festzustellen, dass
sie die Ergebnisse der Messungen der TOE-Entwicklung unter Verwendung des messbaren Lebenszyklus-
modells liefert.
Die Ergebnisse der Messungen und der Verlauf des Lebenszyklus des TOEs sollten mit dem Lebenszyklus-
modell übereinstimmen.
Die Dokumentation zum Ergebnis enthält nicht nur numerische Werte der Metriken, sondern dokumentiert
auch Aktionen, die als Ergebnis der Messungen und in Übereinstimmung mit dem Modell ergriffen wurden. Es
kann beispielsweise die Anforderung bestehen, dass eine bestimmte Designphase wiederholt werden muss,
wenn einige während der Prüfungen gemessene Fehlerraten außerhalb eines definierten Schwellenwertes
liegen. In diesem Fall sollte die Dokumentation zeigen, dass solche Aktionen ergriffen wurden, wenn die
Schwellenwerte tatsächlich nicht erreicht wurden.
Wenn die Evaluierung parallel zur Entwicklung des TOEs durchgeführt wird, ist es möglich, dass in der
Vergangenheit keine Qualitätsmessungen verwendet wurden. In diesem Fall sollte der Evaluator die
Dokumentation der geplanten Verfahren verwenden, um Vertrauen zu gewinnen, dass Korrekturmaßnahmen
definiert werden, wenn die Ergebnisse der Qualitätsmessungen von einem bestimmten Schwellenwert
abweichen.
12.8 Tools und Techniken (ALC_TAT)
12.8.1 Evaluierung der Unteraufgabe (ALC_TAT.1)
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob der Entwickler genau festgelegte
Entwicklungstools (z. B. Programmiersprachen oder Computer Aided Design (CAD-)Systeme) verwendet hat,
die konsistente und vorhersehbare Ergebnisse liefern.
12.8.1.2 Eingaben

a) die Dokumentation des Entwicklungstools,
b) die Untergruppe der Darstellung der Implementierung.
Diese Arbeit kann parallel zu den Evaluierungsaufgaben unter „Implementation representation“ (ADV_IMP)
durchgeführt werden, insbesondere im Hinblick auf die Bestimmung der Verwendung von Merkmalen in den
Toolsn, die sich auf den Objektcode auswirken (z. B. Kompilierungsoptionen).
12.8.1.4 Aktion ALC_TAT.1.1E
ISO/IEC 15408-3 ALC_TAT.1.1C: Jedes für die Implementierung verwendete Entwicklungstool muss genau
festgelegt sein.
12.8.1.4.1 Workunit ALC_TAT.1-1
Der Evaluator muss die zur Verfügung gestellte Dokumentation der Entwicklungstools untersuchen, um
festzustellen, dass jedes Entwicklungstool genau festgelegt ist.
209
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Zum Beispiel kann eine genau definierte Sprache, ein Compiler oder ein CAD-System als übereinstimmend mit
einer anerkannten Norm, wie z. B. den ISO-Normen, gelten. Eine genau definierte Sprache ist eine Sprache, die
eine klare und vollständige Beschreibung ihrer Syntax und eine detaillierte Beschreibung der Semantik jedes
Konstrukts hat.
ISO/IEC 15408-3 ALC_TAT.1.2C: Die Dokumentation jedes Entwicklungstools muss die Bedeutung aller
Aussagen sowie aller bei der Implementierung verwendeten Konventionen und Richtlinien eindeutig definieren.
Der Evaluator muss die Dokumentation jedes Entwicklungstools untersuchen, um festzustellen, dass es die
Bedeutung aller Aussagen sowie aller Konventionen und Richtlinien, die bei der Implementierung verwendet
werden, eindeutig definiert.
Die Dokumentation des Entwicklungstools (z. B. Spezifikationen der Programmiersprache und Benutzer-
handbücher) sollte alle Aussagen abdecken, die bei der Darstellung der Implementierung des TOEs verwendet
werden, und für jede dieser Aussagen sollte eine klare und eindeutige Definition des Zwecks und der Wirkung
dieser Aussage gegeben werden. Diese Arbeit kann parallel zu der vom Evaluator während der Unteraufgabe
ADV_IMP durchgeführten Untersuchung der Darstellung der Implementierung durchgeführt werden. Die
wichtigste Prüfung, die der Evaluator anwenden sollte, ist die Frage, ob die Dokumentation eindeutig genug
ist, dass der Evaluator die Darstellung der Implementierung verstehen kann oder nicht. Die Dokumentation
sollte (zum Beispiel) nicht davon ausgehen, dass der Leser ein Experte in der verwendeten
Programmiersprache ist.
Die Verweisung auf die Verwendung einer dokumentierten Norm ist ein akzeptabler Ansatz, um diese
Anforderung zu erfüllen, vorausgesetzt, die Norm steht dem Evaluator zur Verfügung. Abweichungen von der
Norm sollten dokumentiert werden.
Die entscheidende Prüfung besteht darin, ob der Evaluator den TOE-Quellcode verstehen kann, wenn er die in
der Unteraufgabe ADV_IMP behandelte Quellcodeanalyse durchführt. Die folgende Checkliste kann jedoch
zusätzlich für die Suche nach Problembereichen verwendet werden:
a) In der Sprachdefinition können Formulierungen wie „die Wirkung dieses Konstrukts ist nicht definiert“
und Begriffe wie „implementierungsabhängig“ oder „fehlerhaft“ auf undefinierte Bereiche hinweisen.
b) Aliasing (d. h. die Möglichkeit, auf ein und denselben Speicherort auf unterschiedliche Weise zu
verweisen) ist eine häufige Quelle von Mehrdeutigkeitsproblemen.
c) Die Ausnahmebehandlung (z. B. was nach einer Speichererschöpfung oder einem Stapelüberlauf
geschieht) ist oft schlecht definiert.
Die meisten gebräuchlichen Sprachen, wie gut auch immer gestaltet, werden einige problematische
Konstrukte haben. Wenn die Implementierungssprache meist genau definiert ist, aber einige problematische
Konstrukte vorhanden sind, dann sollte bis zur Untersuchung des Quellcodes eine nicht bewertbare
Entscheidung zugewiesen werden.
Der Evaluator sollte bei der Untersuchung des Quellcodes verifizieren, dass durch die Verwendung der
problematischen Konstrukte keine Anfälligkeiten entstehen. Der Evaluator sollte auch sicherstellen, dass
Konstrukte, die durch die dokumentierte Norm ausgeschlossen sind, nicht verwendet werden.
Die Dokumentation des Entwicklungstools sollte alle Konventionen und Richtlinien definieren, die bei der
Implementierung verwendet werden.
implementierungsabhängigen Optionen eindeutig definieren.
210
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss die Dokumentation des Entwicklungstools untersuchen, um festzustellen, dass sie die
Bedeutung aller implementierungsabhängigen Optionen eindeutig definiert.
Die Dokumentation von Software-Entwicklungstools sollte Definitionen von implementierungsabhängigen

Optionen enthalten, die die Bedeutung des ausführbaren Codes beeinflussen können, sowie solche, die sich
von der dokumentierten Standardsprache unterscheiden. Wenn dem Evaluator der Quellcode zur Verfügung
gestellt wird, sollten auch Informationen über die verwendeten Kompilierungs- und Verknüpfungsoptionen
angegeben werden.
Die Dokumentation für Hardware-Design- und Entwicklungstools sollte die Verwendung aller Optionen
beschreiben, die das Arbeitsergebnis der Tools beeinflussen (z. B. detaillierte Hardware-Spezifikationen oder
die tatsächliche Hardware).
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob der Entwickler klar festgelegte
Entwicklungstools (z. B. Programmiersprachen oder Computer Aided Design (CAD-)Systeme) verwendet hat,
die konsistente und vorhersehbare Ergebnisse liefern, und ob Implementierungsnormen angewendet wurden.
12.8.2.2 Eingaben

b) die Beschreibung der Implementierungsnormen,
c) die vorgesehene Darstellung der Implementierung des TSF.
Diese Arbeit kann parallel zu den Evaluierungsaufgaben unter Darstellung der Implementierung (ADV_IMP)
durchgeführt werden, insbesondere im Hinblick auf die Bestimmung der Verwendung von Merkmalen in den
Toolsn, die sich auf den Objektcode auswirken (z. B. Kompilierungsoptionen).
festgelegt sein.
festzustellen, dass jedes Entwicklungstool genau definiert ist.
Konstrukts hat.
211
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Die Dokumentation des Entwicklungstools (z. B. Spezifikationen der Programmiersprache und

Benutzerhandbücher) sollte alle Aussagen abdecken, die bei der Darstellung der Implementierung des TOEs
verwendet werden, und für jede dieser Aussagen sollte eine klare und eindeutige Definition des Zwecks und
der Wirkung dieser Aussage gegeben werden. Diese Arbeit kann parallel zu der vom Evaluator während der
Unteraufgabe ADV_IMP durchgeführten Untersuchung der Darstellung der Implementierung durchgeführt
werden. Die wichtigste Prüfung, die der Evaluator anwenden sollte, ist die Frage, ob die Dokumentation
eindeutig genug ist, dass der Evaluator die Darstellung der Implementierung verstehen kann oder nicht. Die
Dokumentation sollte (zum Beispiel) nicht davon ausgehen, dass der Leser ein Experte in der verwendeten
Programmiersprache ist.
zusätzlich für die Suche nach Problembereichen verwendet werden:

angegeben werden.
212
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss Aspekte des Implementierungsprozesses untersuchen, um festzustellen, ob die

dokumentierten Implementierungsnormen angewendet wurden.
Diese Workunit erfordert, dass der Evaluator die bereitgestellte Darstellung der Implementierung des TOEs
analysiert, um festzustellen, ob die dokumentierten Implementierungsnormen angewendet wurden.
Der Evaluator sollte überprüfen, dass die durch die dokumentierte Norm ausgeschlossenen Konstrukte nicht
verwendet werden.
Zusätzlich sollte der Evaluator die Verfahren des Entwicklers überprüfen, die die Anwendung der definierten
Normen innerhalb des Design- und Implementierungsprozesses des TOEs sicherstellen. Deshalb sollte der
dokumentierende Nachweis durch eine Besichtigung der Entwicklungsumgebung ergänzt werden. Eine
Besichtigung der Entwicklungsumgebung ermöglicht es dem Evaluator:
a) die Anwendung definierter Normen zu beobachten;
b) dokumentierende Nachweise für die Anwendung der Verfahren, die die Verwendung von definierten
Normen beschreiben, zu untersuchen;
c) das Entwicklungspersonal zu befragen, um das Bewusstsein für die Anwendung der definierten Normen
und Verfahren zu prüfen.
Verfahren zu gewinnen. Jede Entscheidung, von einer solchen Besichtigung abzusehen, sollte in Absprache mit
der Evaluierungsinstanz getroffen werden.
Der Evaluator vergleicht die zur Verfügung gestellte Darstellung der Implementierung mit der Beschreibung
der angewandten Implementierungsnormen und überprüft deren Anwendung.
Auf dieser Ebene ist es nicht erforderlich, dass die vollständig bereitgestellte Darstellung der Implementierung
der TSF auf Implementierungsnormen basiert, sondern nur die Teile, die vom TOE-Entwickler selbst
entwickelt werden. Der Evaluator kann die Konfigurationsliste konsultieren, die vom „CM scope“ (ALC_CMS)
vorgeschrieben ist, um die Information zu erhalten, welche Teile vom TOE-Entwickler und welche von
Drittentwicklern entwickelt werden.
Wenn die in Bezug genommenen Implementierungsnormen zumindest für Teile der bereitgestellten
Darstellung der Implementierung nicht angewendet werden, wird die Evaluatorenaktion, die sich auf diese
Workunit bezieht, mit einer „abgelehnt“-Entscheidung belegt.
Es ist zu beachten, dass Teile des TOEs, die nicht TSF-relevant sind, nicht untersucht werden müssen.
Diese Workunit kann in Verbindung mit den Evaluierungsaufgaben unter ADV_IMP durchgeführt werden.
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob der Entwickler und seine Unter-
auftragnehmer genau definierte Entwicklungstools (z. B. Programmiersprachen oder Computer Aided Design
(CAD-Systeme) verwendet haben, die konsistente und vorhersehbare Ergebnisse liefern, und ob
Implementierungsnormen angewendet wurden.
213
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
12.8.3.2 Eingaben

b) die Beschreibung der Implementierungsnormen,
c) die vorgesehene Darstellung der Implementierung des TSF.
Diese Arbeit kann parallel zu den Evaluierungsaufgaben unter ADV_IMP durchgeführt werden, insbesondere
im Hinblick auf die Bestimmung der Verwendung von Merkmalen in den Toolsn, die sich auf den Objektcode
auswirken (z. B. Kompilierungsoptionen).
festgelegt sein.
festzustellen, dass jedes Entwicklungstool genau definiert ist.
Konstrukts hat.
Auf dieser Stufe muss die Dokumentation von Entwicklungstools, die von Dritten, die zum TOE beitragen,
verwendet werden, in die Untersuchung des Evaluators einbezogen werden.
Die Dokumentation des Entwicklungstools (z. B. Spezifikationen der Programmiersprache und Benutzer-
handbücher) sollte alle Aussagen abdecken, die bei der Darstellung der Implementierung des TOEs verwendet
werden, und für jede dieser Aussagen sollte eine klare und eindeutige Definition des Zwecks und der Wirkung
dieser Aussage gegeben werden. Diese Arbeit kann parallel zu der vom Evaluator während der Unteraufgabe
ADV_IMP durchgeführten Untersuchung der Darstellung der Implementierung durchgeführt werden. Die
wichtigste Prüfung, die der Evaluator anwenden sollte, ist die Frage, ob die Dokumentation eindeutig genug
ist, dass der Evaluator die Darstellung der Implementierung verstehen kann oder nicht. Die Dokumentation
sollte (zum Beispiel) nicht davon ausgehen, dass der Leser ein Experte in der verwendeten Programmier-
sprache ist.
214
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
zusätzlich für die Suche nach Problembereichen verwendet werden.

angegeben werden.
Der Evaluator muss Aspekte des Implementierungsprozesses untersuchen, um festzustellen, ob die

dokumentierten Implementierungsnormen angewendet wurden.
215
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Diese Workunit erfordert, dass der Evaluator die bereitgestellte Darstellung der Implementierung des TOEs
analysiert, um festzustellen, ob die dokumentierten Implementierungsnormen angewendet wurden.
Der Evaluator sollte überprüfen, dass die durch die dokumentierte Norm ausgeschlossenen Konstrukte nicht
verwendet werden.
Zusätzlich sollte der Evaluator die Verfahren des Entwicklers überprüfen, die die Anwendung der definierten
Normen innerhalb des Design- und Implementierungsprozesses des TOEs sicherstellen. Deshalb sollte der
dokumentierende Nachweis durch eine Besichtigung der Entwicklungsumgebung ergänzt werden. Eine
Besichtigung der Entwicklungsumgebung ermöglicht es dem Evaluator,
a) die Anwendung definierter Normen zu beobachten;

b) dokumentierende Nachweise für die Anwendung der Verfahren, die die Verwendung von definierten
Normen beschreiben, zu untersuchen;
c) das Entwicklungspersonal zu befragen, um das Bewusstsein für die Anwendung der definierten Normen
und Verfahren zu prüfen.
Verfahren zu gewinnen. Jede Entscheidung, von einer solchen Besichtigung abzusehen, sollte in Absprache mit
der Evaluierungsinstanz getroffen werden.
Der Evaluator vergleicht die zur Verfügung gestellte Darstellung der Implementierung mit der Beschreibung
der angewandten Implementierungsnormen und überprüft deren Anwendung.
Auf dieser Ebene ist es erforderlich, dass die vollständig bereitgestellte Darstellung der Implementierung der
TSF auf Implementierungsnormen basiert, einschließlich Beiträgen von Dritten. Dazu kann es erforderlich
sein, dass der Evaluator die Standorte der Mitwirkenden besucht. Der Evaluator kann die Konfigurationsliste
konsultieren, die vom „CM scope“ (ALC_CMS) vorgeschrieben ist, um zu sehen, wer welchen Teil des TOEs
entwickelt hat.
Es ist zu beachten, dass Teile des TOEs, die nicht TSF-relevant sind, nicht untersucht werden müssen.
Diese Workunit kann in Verbindung mit den Evaluierungsaufgaben unter ADV_IMP durchgeführt werden.
13 Klasse ATE: Prüfungen
13.1 Einleitung
Ziel dieser Aufgabe ist es, festzustellen, ob sich der TOE so verhält, wie in der ST beschrieben und wie in den
Evaluationsnachweisen (beschrieben in der Klasse ADV) festgelegt. Diese Bestimmung wird durch eine
Kombination aus eigenen Funktionsprüfungen der TSF „Functional tests“ (ATE_FUN) durch den Entwickler
und unabhängigen Prüfungen der TSF „Independent testing“ (ATE_IND) durch den Evaluator erreicht. Auf der
niedrigsten Vertrauenswürdigkeitsstufe ist die Beteiligung des Entwicklers nicht erforderlich, so dass die
einzigen Prüfungen vom Evaluator unter Verwendung der begrenzt verfügbaren Informationen über den TOE
durchgeführt werden. Zusätzliche Vertrauenswürdigkeit wird gewonnen, wenn sich der Entwickler
zunehmend sowohl an den Prüfungen als auch an der Bereitstellung zusätzlicher Informationen über den TOE
beteiligt und wenn der Evaluator die unabhängigen Prüfaufgaben erhöht.
Das Prüfen der TSF wird vom Evaluator und in den meisten Fällen vom Entwickler durchgeführt. Der
Prüfaufwand des Evaluators besteht nicht nur in der Erstellung und Durchführung von Originalprüfungen,
sondern auch in der Beurteilung der Angemessenheit der Prüfungen des Entwicklers und der erneuten
Durchführung einer Teilmenge davon.
216
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator analysiert die Prüfungen des Entwicklers, um festzustellen, inwieweit sie ausreichen, um
nachzuweisen, dass die TSFI (siehe „Functional specification“ (ADV_FSP)) wie angegeben funktioniert, und um
den Prüfansatz des Entwicklers zu verstehen. In ähnlicher Weise analysiert der Evaluator die Prüfungen des
Entwicklers, um festzustellen, inwieweit sie ausreichen, um das interne Verhalten und die Eigenschaften der
TSF nachzuweisen.
Der Evaluator führt auch eine Teilmenge der dokumentierten Prüfungen des Entwicklers durch, um Vertrauen
in die Prüfergebnisse des Entwicklers zu gewinnen: Der Evaluator verwendet die Ergebnisse dieser Analyse
als Eingabe für das unabhängige Prüfen einer Teilmenge der TSF. In Bezug auf diese Teilmenge verfolgt der
Evaluator einen anderen Prüfansatz als der Entwickler, insbesondere wenn die Prüfungen des Entwicklers
Defizite aufweisen.
Um die Angemessenheit der Prüfdokumentation des Entwicklers zu bestimmen oder neue Prüfungen zu
erstellen, muss der Evaluator das gewünschte erwartete Verhalten der TSF, sowohl intern als auch aus Sicht
der TSFI, im Zusammenhang mit den von ihm zu erfüllenden SFRs verstehen. Der Evaluator kann sich dafür
entscheiden, TSF und TSFI in Teilmengen entsprechend den Funktionsbereichen der ST (Audit-Teilsystem,
auditbezogene TSFI, Authentifizierungsmodul, authentifizierungsbezogene TSFI usw.) zu unterteilen, wenn
sie nicht bereits in der ST unterteilt waren, und sich jeweils auf eine Teilmenge von TSF und TSFI zu
konzentrieren, wobei er die ST-Anforderung und die relevanten Teile der Entwicklungs- und
Leitliniendokumente untersucht, um ein Verständnis für das erwartete Verhalten des TOEs zu erhalten. Diese
Abhängigkeit von der Entwicklungsdokumentation unterstreicht die Notwendigkeit der Abhängigkeiten von
ADV durch „Coverage“ (ATE_COV) und „Depth“ (ATE_DPT).
ISO/IEC 15408 hat Abdeckung und Tiefe von Funktionsprüfungen getrennt, um die Flexibilität bei der
Anwendung der Komponenten der Familien zu erhöhen. Die Anforderungen der Familien sollen jedoch
gemeinsam angewendet werden, um zu bestätigen, dass die TSF nach ihrer Spezifikation arbeitet. Diese enge
Koppelung der Familien hat zu einer gewissen Duplizierung der Workunits der Evaluatoren über
Unteraufgaben hinweg geführt. Diese Anwendungshinweise werden verwendet, um Textüberschneidungen
zwischen Unteraufgaben zu minimieren.
13.2.1 Verständnis des erwarteten Verhaltens des TOEs
Bevor die Angemessenheit der Prüfdokumentation genau bewertet werden kann oder bevor neue Prüfungen
erstellt werden können, muss der Evaluator das gewünschte erwartete Verhalten einer Sicherheitsfunktion
im Zusammenhang mit den zu erfüllenden Anforderungen verstehen.
Wie bereits erwähnt, kann sich der Evaluator dafür entscheiden, die TSF und TSFI nach den SFRs (Audit,
Authentifizierung usw.) in der ST zu unterteilen und sich jeweils auf eine Teilmenge zu konzentrieren. Der
Evaluator untersucht jede ST-Anforderung und die relevanten Teile der Funktionsspezifikation und der
Leitliniendokumente, um ein Verständnis dafür zu gewinnen, wie sich die betreffende TSFI voraussichtlich
verhalten wird. In ähnlicher Weise untersucht der Evaluator die relevanten Teile der Dokumentation des
TOEs-Designs und der Sicherheitsarchitektur, um ein Verständnis dafür zu gewinnen, wie sich die zugehörigen
Module oder Teilsysteme der TSF voraussichtlich verhalten werden.
Mit einem Verständnis für das erwartete Verhalten untersucht der Evaluator den Prüfplan, um ein Verständnis
für den Prüfansatz zu erhalten. In den meisten Fällen führt der Prüfansatz dazu, dass eine TSFI stimuliert und
ihre Reaktionen beobachtet werden. Von außen sichtbare Funktionalität kann direkt geprüft werden; in
Fällen, in denen die Funktionalität außerhalb des TOEs nicht sichtbar ist (z. B. beim Prüfen der restlichen
Informationsschutzfunktionalität), müssen jedoch andere Mittel eingesetzt werden.
217
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
13.2.2 Prüfen gegenüber alternativen Ansätzen zur Überprüfung des erwarteten Verhaltens der
Funktionalität
In Fällen, in denen es unpraktisch oder unangemessen ist, bestimmte Funktionen zu prüfen (wenn sie keine
von außen sichtbare TSFI bieten), sollte der Prüfplan den alternativen Ansatz zur Überprüfung des erwarteten
Verhaltens aufzeigen. Es liegt in der Verantwortung des Evaluators, die Eignung des alternativen Ansatzes zu
bestimmen. Bei der Beurteilung der Eignung alternativer Ansätze sollte jedoch Folgendes berücksichtigt
werden.
a) Eine Analyse der Darstellung der Implementierung, um festzustellen, dass das geforderte Verhalten vom
TOE gezeigt werden sollte, ist ein akzeptabler alternativer Ansatz. Dies könnte eine Code-Inspektion für
einen Software-TOE oder vielleicht eine Chipmasken-Inspektion für einen Hardware-TOE bedeuten.
b) Es ist akzeptabel, Nachweise für die Integration durch den Entwickler oder Modulprüfungen zu
verwenden, selbst wenn die beanspruchten Anforderungen an die Vertrauenswürdigkeit nicht die
Verfügbarkeit von Beschreibungen niedrigerer Stufen der TOE-Module (z. B. „Evaluation of sub-activity“
(ADV_TDS.3) oder „Implementation representation“ (ADV_IMP)) beinhalten. Wenn der Nachweis der
Integration durch den Entwickler oder die Modulprüfung zur Verifizierung des erwarteten Verhaltens
einer Sicherheitsfunktionalität verwendet wird, sollte darauf geachtet werden, dass der Nachweis der
Prüfungen die aktuelle Implementierung des TOEs widerspiegelt. Wenn die Teilsysteme oder Module seit
den Prüfungen geändert wurden, ist in der Regel der Nachweis erforderlich, dass die Änderungen verfolgt
und durch Analysen oder weitere Prüfungen berücksichtigt wurden.
Es sollte betont werden, dass eine Ergänzung des Prüfaufwands durch alternative Ansätze nur dann
vorgenommen werden sollte, wenn sowohl der Entwickler als auch der Evaluator feststellen, dass es keine
anderen praktischen Mittel gibt, um das erwartete Verhalten zu prüfen.
13.2.3 Überprüfung der Angemessenheit der Prüfungen
Die Prüfungsvoraussetzungen sind notwendig, um die erforderlichen Ausgangsbedingungen für die Prüfung
zu schaffen. Sie können in Form von Parametern ausgedrückt werden, die festgelegt werden müssen, oder in
Form einer alphabetischen Prüfungsanordnung in Fällen, in denen der Abschluss einer Prüfung die
notwendigen Voraussetzungen für eine andere Prüfung schafft. Der Evaluator muss feststellen, dass die
Voraussetzungen vollständig und angemessen sind, da sie die beobachteten Prüfungsergebnisse nicht in
Richtung der erwarteten Prüfungsergebnisse verzerren.
Die Prüfschritte und erwarteten Ergebnisse spezifizieren die Aktionen und Parameter, die auf die TSFI
anzuwenden sind, sowie die Art und Weise, wie die erwarteten Ergebnisse verifiziert werden sollten und was
sie sind. Der Evaluator muss feststellen, dass die Prüfschritte und erwarteten Ergebnisse gegenüber den
Beschreibungen der TSFI in der Funktionsspezifikation konsistent sind. Dies bedeutet, dass jedes Merkmal
des TSFI-Verhaltens, das explizit in der Funktionsspezifikation beschrieben wird, Prüfungen und erwartete
Ergebnisse haben sollte, um dieses Verhalten zu verifizieren.
Das Gesamtziel dieser Prüftätigkeit besteht darin, festzustellen, ob jedes Teilsystem, Modul und TSFI
ausreichend gegen die Verhaltensansprüche in der Funktionsspezifikation, dem TOE-Design und der
Architekturbeschreibung geprüft wurde. Auf den höheren Vertrauenswürdigkeitsstufen umfasst das Prüfen
auch Grenz- und Negativprüfungen. Die Prüfverfahren geben einen Einblick, wie die TSFIs, Module und
Teilsysteme vom Entwickler während der Prüfungen ausgeführt wurden. Der Evaluator verwendet diese
Informationen bei der Entwicklung zusätzlicher Prüfungen, um die TSF unabhängig zu prüfen.
218
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
13.3 Abdeckung (ATE_COV)
13.3.1 Evaluierung der Unteraufgabe (ATE_COV.1)
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob der Entwickler die TSFIs geprüft hat und
ob der Nachweis der Prüfabdeckung des Entwicklers die Übereinstimmung zwischen den in der Prüf-
dokumentation identifizierten Prüfungen und den in der Funktionsspezifikation beschriebenen TSFIs zeigt.
13.3.1.2 Eingaben

a) die ST,
c) die Prüfdokumentation,
d) der Nachweis der Prüfabdeckung.
Die vom Entwickler vorgelegte Abdeckungsanalyse ist erforderlich, um die Übereinstimmung zwischen den
als Evaluationsnachweis vorgelegten Prüfungen und der Funktionsspezifikation aufzuzeigen. Die
Abdeckungsanalyse muss jedoch nicht nachweisen, dass alle TSFIs geprüft wurden oder dass alle von außen
sichtbaren Schnittstellen zum TOE geprüft wurden. Solche Defizite werden vom Evaluator während der
unabhängigen Prüfung „Evaluation of sub-activity“ (ATE_IND.2) berücksichtigt.
13.3.1.4 Aktion ATE_COV.1.1E
ISO/IEC 15408-3 ATE_COV.1.1C: Der Nachweis der Prüfabdeckung muss die Übereinstimmung zwischen den
Prüfungen in der Prüfdokumentation und den TSFIs in der Funktionsspezifikation zeigen.
13.3.1.4.1 Workunit ATE_COV.1-1
Der Evaluator muss den Nachweis der Prüfabdeckung untersuchen, um festzustellen, dass die
Übereinstimmung zwischen den in der Prüfdokumentation identifizierten Prüfungen und den in der
Funktionsspezifikation beschriebenen TSFIs genau ist.
Die Übereinstimmung kann in Form einer Tabelle oder einer Matrix erfolgen. Die für diese Komponente
erforderlichen Nachweise für die Abdeckung werden eher den Umfang der Abdeckung offenlegen, als eine
vollständige Abdeckung zu zeigen. In Fällen, in denen sich die Abdeckung als schwach erweist, sollte der
Evaluator die Ebene der unabhängigen Prüfungen erhöhen, um dies zu kompensieren.
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob der Entwickler alle TSFIs geprüft hat und
ob der Nachweis der Prüfabdeckung des Entwicklers die Übereinstimmung zwischen den in der Prüf-
dokumentation identifizierten Prüfungen und den in der Funktionsspezifikation beschriebenen TSFIs zeigt.
219
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
13.3.2.2 Eingaben
a) die ST,
c) die Prüfdokumentation,
d) die Analyse der Prüfabdeckung.
13.3.2.3 Aktion ATE_COV.2.1E
ISO/IEC 15408-3 ATE_COV.2.1C: Die Analyse der Prüfabdeckung muss die Übereinstimmung zwischen den
Prüfungen in der Prüfdokumentation und den TSFIs in der Funktionsspezifikation nachweisen.
Der Evaluator muss die Analyse der Prüfabdeckung untersuchen, um festzustellen, ob die Übereinstimmung
zwischen den Prüfungen in der Prüfdokumentation und den Schnittstellen in der Funktionsspezifikation
genau ist.
Eine einfache Kreuztabelle kann ausreichend sein, um die Prüfübereinstimmung zu zeigen. Die Identifizierung
der Prüfungen und der in der Prüfabdeckungsanalyse dargestellten Schnittstellen muss eindeutig sein.
Der Evaluator wird daran erinnert, dass dies nicht bedeutet, dass alle Prüfungen in der Prüfdokumentation
auf Schnittstellen in der Funktionsspezifikation abgebildet werden müssen.
Der Evaluator muss den Prüfplan untersuchen, um festzustellen, dass der Prüfansatz für jede Schnittstelle
das erwartete Verhalten dieser Schnittstelle nachweist.
Ein Leitfaden zu dieser Workunit findet sich in
a) 13.2.1, Verständnis des erwarteten Verhaltens des TOEs;
b) 13.2.2, Prüfen gegenüber alternativen Ansätzen zur Überprüfung des erwarteten Verhaltens der
Funktionalität.
Der Evaluator muss die Prüfverfahren untersuchen, um festzustellen, dass die Prüfvoraussetzungen, die
Prüfschritte und das/die erwartete(n) Ergebnis(e) jede Schnittstelle angemessen prüfen.
Ein Leitfaden zu diesen Workunits, wie sie sich auf die Funktionsspezifikation bezieht, findet sich in
a) 13.2.3, Überprüfung der Angemessenheit der Prüfungen.
ISO/IEC 15408-3 ATE_COV.2.2C: Die Analyse der Prüfabdeckung muss nachweisen, dass alle TSFIs in der
Funktionsspezifikation geprüft wurden.
Der Evaluator muss die Prüfabdeckungsanalyse untersuchen, um festzustellen, ob die Übereinstimmung

zwischen den Schnittstellen in der Funktionsspezifikation und den Prüfungen in der Prüfdokumentation
vollständig ist.
220
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Alle TSFIs, die in der Funktionsspezifikation beschrieben sind, müssen in der Prüfabdeckungsanalyse
vorhanden sein und auf Prüfungen abgebildet werden, damit die Vollständigkeit beansprucht werden kann,
obwohl eine erschöpfende Spezifikationsprüfung der Schnittstellen nicht erforderlich ist. Eine unvollständige
Abdeckung wäre offensichtlich, wenn eine Schnittstelle in der Funktionsspezifikation identifiziert und keine
Prüfung auf sie abgebildet würde.
auf Schnittstellen in der Funktionsspezifikation abgebildet werden müssen.
13.4 Tiefe (ATE_DPT)

13.4.1 Evaluierung der Unteraufgabe (ATE_DPT.1)
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob der Entwickler die TSF-Teilsysteme gegen
das TOE-Design und die Beschreibung der Sicherheitsarchitektur geprüft hat.
13.4.1.2 Eingaben
a) die ST,
c) das TOE-Design,
e) die Prüfdokumentation,
f) die Tiefe der Prüfanalyse.
13.4.1.3 Aktion ATE_DPT.1.1E
ISO/IEC 15408-3 ATE_DPT.1.1C: Die Analyse der Prüftiefe muss die Übereinstimmung zwischen den Prüfungen
in der Prüfdokumentation und den TSF-Teilsystemen im TOE-Design nachweisen.
13.4.1.3.1 Workunit ATE_DPT.1-1
Der Evaluator muss die Tiefe der Prüfanalyse untersuchen, um festzustellen, ob die Beschreibungen des
Verhaltens von TSF-Teilsystemen und ihrer Interaktionen in der Prüfdokumentation enthalten sind.
Diese Workunit verifiziert den Inhalt der Übereinstimmung zwischen den Prüfungen und den Beschreibungen
im TOE-Design. In Fällen, in denen in der Beschreibung der architektonischen Fundiertheit (in „Security
Architecture“ (ADV_ARC))) der TSF bestimmte Mechanismen genannt werden, überprüft diese Workunit auch
die Übereinstimmung zwischen den Prüfungen und den Beschreibungen des Verhaltens dieser Mechanismen.
der Prüfungen und des Verhaltens bzw. der Interaktion, die in der Analyse der Abdeckungstiefe dargestellt
werden, muss eindeutig sein.
Wenn die „Evaluation of sub-activity“ (ATE_DPT.1) mit einer Komponente des „TOE design“ (ADV_TDS)
kombiniert wird, die Beschreibungen auf Modulebene (z. B. die „Evaluation of sub-activity“ (ADV_TDS.3))
enthält, kann der Detaillierungsgrad, der zur Zuordnung der Prüffälle auf das Verhalten der Teilsysteme
erforderlich ist, die Verwendung von Informationen aus der Modulbeschreibung erfordern. Der Grund dafür
ist, dass die „Evaluation of sub-activity“ (ADV_TDS.3) die Beschreibung von Details von der Ebene der
Teilsysteme auf die Modulebene verlagert oder sogar die Teilsysteme ganz weggelassen werden können.
221
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
In jedem Fall kann der erforderliche Detaillierungsgrad in der bereitgestellten Verweisung auf das geprüfte
Verhalten definiert werden als „der Detaillierungsgrad, der für die Beschreibung des Teilsystemverhaltens,
wie durch die „Evaluation of sub-activity“ (ADV_TDS.2) (insbesondere Workunit ADV_TDS.2-4) definiert,
erforderlich ist“. In einer detaillierten Beschreibung des Verhaltens wird in der Regel erörtert, wie die
Funktionalität bereitgestellt wird, d. h. welche Schlüsseldaten und Datenstrukturen vorhanden sind, welche
Kontrollbeziehungen innerhalb eines Teilsystems bestehen und wie diese Elemente zusammenwirken, um das
SFR-durchsetzende Verhalten bereitzustellen.
Der Evaluator wird daran erinnert, dass nicht alle Prüfungen in der Prüfdokumentation auf eine
Verhaltens- oder Interaktionsbeschreibung des Teilsystems abgebildet werden müssen.
Der Evaluator muss den Prüfplan, die Prüfvoraussetzungen, die Prüfschritte und das/die erwartete(n)
Ergebnis(e) untersuchen, um festzustellen, ob der Prüfansatz für die Verhaltensbeschreibung das im
TOE-Design beschriebene Verhalten dieses Teilsystems nachweist.
Funktionalität.
Wenn TSF-Teilsystemschnittstellen beschrieben werden, kann das Verhalten dieser Teilsysteme direkt von
diesen Schnittstellen aus geprüft werden. Ansonsten wird das Verhalten dieser Teilsysteme über die
TSFI-Schnittstellen geprüft. Oder es kann eine Kombination aus beidem eingesetzt werden. Welche Strategie
auch immer verwendet wird, der Evaluator wird ihre Angemessenheit für das angemessene Prüfen des im
TOE-Design beschriebenen Verhaltens prüfen.
Ergebnis(e) untersuchen, um festzustellen, ob der Prüfansatz für die Verhaltensbeschreibung die im
TOE-Design beschriebenen Interaktionen zwischen Teilsystemen nachweist.
Während sich die vorherige Workunit mit dem Verhalten von Teilsystemen befasst, befasst sich diese
Workunit mit den Interaktionen zwischen den Teilsystemen.
222
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Funktionalität.
Wenn TSF-Teilsystemschnittstellen beschrieben werden, können die Interaktionen mit anderen Teilsystemen
direkt von diesen Schnittstellen aus geprüft werden. Andernfalls müssen die Interaktionen zwischen den
Teilsystemen aus den TSFI-Schnittstellen abgeleitet werden. Welche Strategie auch immer verwendet wird,
der Evaluator wird ihre Eignung für das angemessene Prüfen der im TOE-Design beschriebenen Interaktionen
zwischen Teilsystemen prüfen.
ISO/IEC 15408-3 ATE_DPT.1.2C: Die Analyse der Prüftiefe muss nachweisen, dass alle TSF-Teilsysteme im
TOE-Design geprüft wurden.
Der Evaluator muss die Prüfverfahren untersuchen, um festzustellen, dass alle Beschreibungen des
Verhaltens und der Interaktion des TSF-Teilsystems geprüft werden.
Diese Workunit verifiziert die Vollständigkeit der Workunit ATE_DPT.1-1. Alle Beschreibungen des
TSF-Teilsystem-Verhaltens und der Interaktionen zwischen TSF-Teilsystemen, die im TOE-Design vorgesehen
sind, müssen geprüft werden. Eine unvollständige Prüftiefe wäre offensichtlich, wenn eine Beschreibung des
TSF-Teilsystem-Verhaltens oder der Interaktionen zwischen TSF-Teilsystemen im TOE-Design identifiziert
würde und keine Prüfungen zugeordnet werden könnten.
auf das Verhalten oder die Interaktionsbeschreibung des Teilsystems im TOE-Design abgebildet werden
müssen.
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob der Entwickler alle TSF-Teilsysteme und
SFR-durchsetzenden Module im Vergleich mit dem TOE-Design und der Beschreibung der Sicherheits-
architektur geprüft hat.
223
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
13.4.2.2 Eingaben
a) die ST,
c) das TOE-Design,
e) die Prüfdokumentation,
in der Prüfdokumentation und den TSF-Teilsystemen und den SFR-durchsetzenden Modulen im TOE-Design
nachweisen.
Der Evaluator muss die Tiefe der Prüfanalyse untersuchen, um festzustellen, ob Beschreibungen des
Architecture“ (ADV_ARC)) der TSF bestimmte Mechanismen genannt werden, überprüft diese Workunit auch
die Übereinstimmung zwischen den Prüfungen und den Beschreibungen des Verhaltens dieser Mechanismen.
der Prüfungen und des Verhaltens bzw. der Interaktion, die in der Analyse der Abdeckungstiefe dargestellt

Funktionalität.
Wenn TSF-Teilsystemschnittstellen beschrieben werden, kann das Verhalten dieser Teilsysteme direkt von
diesen Schnittstellen aus geprüft werden. Ansonsten wird das Verhalten dieser Teilsysteme über die
224
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

Funktionalität.
Wenn TSF-Teilsystemschnittstellen beschrieben werden, können die Interaktionen mit anderen Teilsystemen
direkt von diesen Schnittstellen aus geprüft werden. Andernfalls müssen die Interaktionen zwischen den
Teilsystemen aus den TSFI-Schnittstellen abgeleitet werden. Welche Strategie auch immer verwendet wird,
der Evaluator wird ihre Eignung für das angemessene Prüfen der im TOE-Design beschriebenen Interaktionen
zwischen Teilsystemen prüfen.
Der Evaluator muss die Tiefe der Prüfanalyse untersuchen, um festzustellen, dass die Schnittstellen der
SFR-durchsetzenden Module in der Prüfdokumentation enthalten sind.
Architecture“ (ADV_ARC)) der TSF bestimmte Mechanismen auf modularer Ebene genannt werden, überprüft
diese Workunit auch die Übereinstimmung zwischen den Prüfungen und den Beschreibungen des Verhaltens
dieser Mechanismen.
der Prüfungen und der SFR-durchsetzenden Module, die in der Analyse der Abdeckungstiefe dargestellt
Der Evaluator wird daran erinnert, dass nicht alle Prüfungen in der Prüfdokumentation auf die Schnittstellen
der SFR-durchsetzenden Module abgebildet werden müssen.
Ergebnis(e) untersuchen, um festzustellen, ob der Prüfansatz für jede SFR-durchsetzende Modulschnittstelle
das erwartete Verhalten dieser Schnittstelle nachweist.
Während sich Workunit ATE_DPT.2-2 mit dem erwarteten Verhalten von Teilsystemen befasst, befasst sich
diese Workunit mit dem erwarteten Verhalten der SFR-durchsetzenden Modulschnittstellen, die von
ATE_DPT.2-4 abgedeckt werden.

Funktionalität.
225
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Das Prüfen einer Schnittstelle kann direkt an dieser Schnittstelle oder an den externen Schnittstellen bzw.
einer Kombination aus beidem durchgeführt werden. Welche Strategie auch immer verwendet wird, der
Evaluator wird ihre Eignung für das angemessene Prüfen der Schnittstellen prüfen. Konkret bestimmt der
Evaluator, ob das Prüfen an den internen Schnittstellen notwendig ist oder ob diese internen Schnittstellen
(wenn auch implizit) durch die Ausübung der externen Schnittstellen ausreichend geprüft werden können.
Diese Festlegung wird dem Evaluator überlassen, ebenso wie ihre Begründung.
Diese Workunit verifiziert die Vollständigkeit der Workunit ATE_DPT.2-1. Alle Beschreibungen des TSF-Teil-
system-Verhaltens und der Interaktionen zwischen TSF-Teilsystemen, die im TOE-Design vorgesehen sind,
müssen geprüft werden. Eine unvollständige Prüftiefe wäre offensichtlich, wenn eine Beschreibung des
müssen.
ISO/IEC 15408-3 ATE_DPT.2.3C: Die Analyse der Prüftiefe muss nachweisen, dass die SFR-durchsetzenden
Module im TOE-Design geprüft wurden.
Der Evaluator muss die Prüfverfahren untersuchen, um festzustellen, dass alle Schnittstellen der
SRF-durchsetzenden Module geprüft werden.
Diese Workunit verifiziert die Vollständigkeit der Workunit ATE_DPT.2-4. Alle Schnittstellen von SFR-durch-
setzenden Modulen, die im TOE-Design vorgesehen sind, müssen geprüft werden. Eine unvollständige
Prüftiefe wäre offensichtlich, wenn irgendeine Schnittstelle irgendwelcher SFR-durchsetzender Module im
TOE-Design identifiziert würde und ihr keine Prüfungen zugeordnet werden könnten.
auf eine Schnittstelle eines SFR-durchsetzenden Moduls im TOE-Design abgebildet werden müssen.
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob der Entwickler alle TSF-Teilsysteme und
Module im Vergleich mit dem TOE-Design und der Beschreibung der Sicherheitsarchitektur geprüft hat.
13.4.3.2 Eingaben
a) die ST;
b) die Funktionsspezifikation;
c) das TOE-Design;
d) die Beschreibung der Sicherheitsarchitektur;
e) die Prüfdokumentation;
226
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
in der Prüfdokumentation und den TSF-Teilsystemen und Modulen im TOE-Design nachweisen.
Der Evaluator muss die Tiefe der Prüfanalyse untersuchen, um festzustellen, ob Beschreibungen des
im TOE-Design. Eine einfache Kreuztabelle kann ausreichend sein, um die Prüfübereinstimmung zu zeigen.
Die Identifizierung der Prüfungen und des Verhaltens bzw. der Interaktion, die in der Analyse der
Abdeckungstiefe dargestellt werden, muss eindeutig sein.
Funktionalität.
Wenn TSF-Teilsystemschnittstellen vorgesehen sind, kann das Verhalten dieser Teilsysteme direkt von diesen
Schnittstellen aus durchgeführt werden. Ansonsten wird das Verhalten dieser Teilsysteme über die
Funktionalität.
Wenn TSF-Teilsystemschnittstellen vorgesehen sind, können die Interaktionen mit anderen Teilsystemen
direkt von diesen Schnittstellen aus durchgeführt werden. Andernfalls müssen die Interaktionen zwischen
den Teilsystemen aus den TSFI-Schnittstellen abgeleitet werden. Welche Strategie auch immer verwendet
wird, der Evaluator wird ihre Eignung für das angemessene Prüfen der im TOE-Design beschriebenen
Interaktionen zwischen Teilsystemen prüfen.
227
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss die Tiefe der Prüfanalyse untersuchen, um festzustellen, dass die Schnittstellen der
TSF-Module in der Prüfdokumentation enthalten sind.
im TOE-Design. Eine einfache Kreuztabelle kann ausreichend sein, um die Prüfübereinstimmung zu zeigen.
Die Identifizierung der Prüfungen und des Verhaltens bzw. der Interaktion, die in der Analyse der
Abdeckungstiefe dargestellt werden, muss eindeutig sein.
Ergebnis(e) untersuchen, um festzustellen, ob der Prüfansatz für jede TSF-Modulschnittstelle das erwartete
Verhalten dieser Schnittstelle nachweist.
Funktionalität.
Das Prüfen einer Schnittstelle kann direkt an dieser Schnittstelle oder an den externen Schnittstellen bzw.
einer Kombination aus beidem durchgeführt werden. Welche Strategie auch immer verwendet wird, der
Evaluator wird ihre Eignung für das angemessene Prüfen der Schnittstellen prüfen. Konkret bestimmt der
Evaluator, ob das Prüfen an den internen Schnittstellen notwendig ist oder ob diese internen Schnittstellen
(wenn auch implizit) durch die Ausübung der externen Schnittstellen ausreichend geprüft werden können.
Diese Festlegung wird dem Evaluator überlassen, ebenso wie ihre Begründung.
Diese Workunit verifiziert die Vollständigkeit der Workunit ATE_DPT.3-1. Alle Beschreibungen des TSF-Teil-
system-Verhaltens und der Interaktionen zwischen TSF-Teilsystemen, die im TOE-Design vorgesehen sind,
müssen geprüft werden. Eine unvollständige Prüftiefe wäre offensichtlich, wenn eine Beschreibung des
müssen.
ISO/IEC 15408-3 ATE_DPT.3.3C: Die Analyse der Prüftiefe muss nachweisen, dass alle TSF-Module im
228
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss die Prüfverfahren untersuchen, um festzustellen, dass alle Schnittstellen sämtlicher
TSF-Module geprüft werden.
Diese Workunit verifiziert die Vollständigkeit der Workunit ATE_DPT.3-4. Alle Schnittstellen von
TSF-Modulen, die im TOE-Design vorgesehen sind, müssen geprüft werden. Eine unvollständige Prüftiefe wäre
offensichtlich, wenn irgendeine Schnittstelle eines TSF-Moduls im TOE-Design identifiziert würde und ihr
keine Prüfungen zugeordnet werden könnten.
auf eine Schnittstelle eines TSF-Moduls im TOE-Design abgebildet werden müssen.
13.5 Funktionsprüfungen (ATE_FUN)
13.5.1 Evaluierung der Unteraufgabe (ATE_FUN.1)
Die Zielsetzung dieser Unteraufgabe soll darin bestehen, festzustellen, ob der Entwickler die Prüfungen
korrekt durchgeführt und in der Prüfdokumentation dokumentiert hat.
13.5.1.2 Eingaben
a) die ST,
c) die Prüfdokumentation.
Der Umfang, in dem die Prüfdokumentation zur Abdeckung der TSF erforderlich ist, hängt von der Vertrauens-
würdigkeitskomponente der Abdeckung ab.
Für die bereitgestellten Entwicklerprüfungen bestimmt der Evaluator, ob die Prüfungen wiederholbar sind
und inwieweit die Prüfungen des Entwicklers für den unabhängigen Prüfaufwand des Evaluators verwendet
werden können. Jede TSFI, bei der die Prüfergebnisse des Entwicklers darauf hindeuten, dass sie
möglicherweise nicht wie angegeben funktioniert, sollte vom Evaluator unabhängig geprüft werden, um
festzustellen, ob dies der Fall ist oder nicht.
13.5.1.4 Aktion ATE_FUN.1.1E
ISO/IEC 15408-3 ATE_FUN.1.1C: Die Prüfdokumentation muss aus Prüfplänen, erwarteten Prüfergebnissen und
tatsächlichen Prüfergebnissen bestehen.
13.5.1.4.1 Workunit ATE_FUN.1-1
Der Evaluator muss prüfen, ob die Prüfdokumentation Prüfpläne, erwartete Prüfergebnisse und tatsächliche
Prüfergebnisse enthält.
229
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator prüft, ob die Prüfpläne, erwarteten Prüfergebnisse und tatsächlichen Prüfergebnisse in der
Prüfdokumentation enthalten sind.
ISO/IEC 15408-3 ATE_FUN.1.2C: Die Prüfpläne müssen die durchzuführenden Prüfungen identifizieren und die
Szenarien für die Durchführung der einzelnen Prüfungen beschreiben. Diese Szenarien müssen alle
Ordnungsabhängigkeiten von den Ergebnissen anderer Prüfungen enthalten.
Der Evaluator muss den Prüfplan untersuchen, um festzustellen, dass er die Szenarien für die Durchführung
der einzelnen Prüfungen beschreibt.
Der Evaluator stellt fest, dass der Prüfplan Informationen über die verwendete Prüfkonfiguration enthält:
sowohl über die Konfiguration des TOEs als auch über die verwendeten Prüfgeräte. Diese Informationen
sollten detailliert genug sein, um sicherzustellen, dass die Prüfkonfiguration reproduzierbar ist.
Der Evaluator stellt auch fest, dass der Prüfplan Informationen darüber enthält, wie die Prüfung ausgeführt
werden soll: alle notwendigen automatisierten Einstellungsverfahren (und ob sie eine Berechtigung zur
Ausführung erfordern), die anzuwendenden Eingaben, wie diese Eingaben angewendet werden, wie die
Ausgabe erhalten wird, alle automatisierten Reinigungsverfahren (und ob sie eine Berechtigung zur
Ausführung erfordern) usw. Diese Informationen sollten detailliert genug sein, um sicherzustellen, dass die
Prüfung reproduzierbar ist.
Der Evaluator möchte bei der Durchführung dieser Workunit möglicherweise eine Stichprobenstrategie
anwenden.
Der Evaluator muss den Prüfplan untersuchen, um festzustellen, dass die Prüfkonfiguration des TOEs
gegenüber der ST konsistent ist.
Der TOE, auf den im Prüfplan des Entwicklers Bezug genommen wird, sollte den gleichen eindeutigen Bezug
haben, der durch die Unteraufgaben der „CM capabilities“ (ALC_CMC) festgelegt und in der ST-Einführung
identifiziert wurde.
Es ist möglich, dass die ST mehr als eine Konfiguration für die Evaluierung angibt. Der Evaluator überprüft, ob
alle in der Entwickler-Prüfdokumentation identifizierten Prüfkonfigurationen gegenüber der ST konsistent
sind. Die ST könnte zum Beispiel Konfigurationsoptionen definieren, die eingestellt werden müssen, was sich
auf das, was den TOE ausmacht, auswirken könnte, indem zusätzliche Teile ein- oder ausgeschlossen werden.
Der Evaluator überprüft, dass alle derartigen Varianten des TOEs berücksichtigt werden.
Der Evaluator sollte die in der ST beschriebenen Sicherheitszielsetzungen für die Betriebsumgebung
berücksichtigen, die für die Prüfumgebung gelten können. Es kann einige Zielsetzungen für die
Betriebsumgebung geben, die nicht für die Prüfumgebung gelten. Beispielsweise kann es sein, dass eine
Zielsetzung bezüglich der Benutzerfreigaben nicht zutrifft; jedoch würde eine Zielsetzung bezüglich eines
einzigen Verbindungspunktes zu einem Netzwerk gelten.
anwenden.
Wenn diese Workunit auf einen Komponenten-TOE angewendet wird, der in einem zusammengesetzten TOE
verwendet/integriert werden könnte (siehe „Class ACO: Composition“), gilt Folgendes. In den Fällen, in denen
der zu evaluierende TOE zur Unterstützung der Operation auf andere Komponenten in der Betriebsumgebung
angewiesen ist, kann der Entwickler in Erwägung ziehen, die andere(n) Komponente(n), die in dem
zusammengesetzten TOE zur Erfüllung der Anforderungen der Betriebsumgebung verwendet wird (werden),
als eine der Prüfkonfigurationen zu verwenden. Dadurch wird der Umfang einer zusätzlichen Prüfung, die für
die zusammengesetzte TOE-Evaluierung erforderlich ist, verringert.
230
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss die Prüfpläne untersuchen, um festzustellen, ob ausreichende Anweisungen für
Ordnungsabhängigkeiten vorhanden sind.
Einige Schritte müssen möglicherweise durchgeführt werden, um die Anfangsbedingungen festzulegen.

Beispielsweise müssen Benutzerkonten hinzugefügt werden, bevor sie gelöscht werden können. Ein Beispiel
für die Ordnungsabhängigkeiten von den Ergebnissen anderer Prüfungen ist die Notwendigkeit, in einer
Prüfung Aktionen durchzuführen, die zur Erstellung von Auditaufzeichnungen führen, bevor eine Prüfung
durchgeführt wird, um die Suche und Sortierung dieser Auditaufzeichnungen zu berücksichtigen. Ein weiteres
Beispiel für eine Ordnungsabhängigkeit wäre, wenn ein Prüffall eine Datei mit Daten generiert, die als Eingabe
für einen anderen Prüffall verwendet wird.
anwenden.
ISO/IEC 15408-3 ATE_FUN.1.3C: Die erwarteten Prüfergebnisse müssen die erwarteten Ausgaben einer
erfolgreichen Durchführung der Prüfungen zeigen.
Der Evaluator muss die Prüfdokumentation untersuchen, um festzustellen, dass alle erwarteten
Prüfergebnisse enthalten sind.
Die erwarteten Prüfergebnisse werden benötigt, um festzustellen, ob eine Prüfung erfolgreich durchgeführt
wurde oder nicht. Erwartete Prüfergebnisse sind ausreichend, wenn sie eindeutig sind und gegenüber dem
erwarteten Verhalten angesichts des Prüfansatzes konsistent sind.
anwenden.
ISO/IEC 15408-3 ATE_FUN.1.4C: Die tatsächlichen Prüfergebnisse müssen zu den erwarteten Prüfergebnissen
konsistent sein.
Der Evaluator muss prüfen, ob die tatsächlichen Prüfergebnisse in der Prüfdokumentation gegenüber den
erwarteten Prüfergebnissen in der Prüfdokumentation konsistent sind.
Ein Vergleich der tatsächlichen mit den erwarteten Prüfergebnissen, die vom Entwickler bereitgestellt
werden, wird etwaige Inkonsistenzen zwischen den Ergebnissen aufdecken. Es kann sein, dass ein direkter
Vergleich der tatsächlichen Ergebnisse erst nach einer gewissen Datenreduktion oder -synthese möglich ist.
In solchen Fällen sollte die Prüfdokumentation des Entwicklers den Prozess zur Reduzierung oder Synthese
der tatsächlichen Daten beschreiben.
Beispielsweise muss der Entwickler möglicherweise den Inhalt eines Nachrichtenpuffers nach dem Herstellen
einer Netzwerkverbindung prüfen, um den Inhalt des Puffers zu ermitteln. Der Nachrichtenpuffer enthält eine
Binärzahl. Diese Binärzahl müsste in eine andere Form der Datendarstellung umgewandelt werden, um die
Prüfung aussagekräftiger zu machen. Die Umwandlung dieser binären Darstellung von Daten in eine
übergeordnete Darstellung muss vom Entwickler so detailliert beschrieben werden, dass ein Evaluator den
Umwandlungsprozess (d. h. synchrone oder asynchrone Übertragung, Anzahl der Stoppbits, Parität usw.)
durchführen kann.
231
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Es sollte beachtet werden, dass die Beschreibung des Prozesses, der zur Reduzierung oder Synthese der
tatsächlichen Daten verwendet wird, vom Evaluator nicht dazu verwendet wird, die notwendige Änderung
tatsächlich durchzuführen, sondern um zu beurteilen, ob dieser Prozess korrekt ist. Es obliegt dem Entwickler,
die erwarteten Prüfergebnisse in ein Format umzuwandeln, das einen einfachen Vergleich mit den
tatsächlichen Prüfergebnissen ermöglicht.
anwenden.
Der Evaluator muss über den Prüfaufwand des Entwicklers berichten und dabei den Prüfansatz, die
Konfiguration, die Tiefe und die Ergebnisse skizzieren.
Die im ETR aufgezeichneten Entwickler-Prüfinformationen ermöglichen es dem Evaluator, den gesamten

Prüfansatz und den Aufwand des Entwicklers für das Prüfen des TOEs zu vermitteln. Die Absicht, diese
Informationen bereitzustellen, besteht darin, einen aussagekräftigen Überblick über den Prüfaufwand des
Entwicklers zu geben. Es ist nicht beabsichtigt, dass die Informationen über Entwicklerprüfungen im ETR eine
exakte Wiedergabe bestimmter Prüfschritte oder Ergebnisse einzelner Prüfungen darstellen. Die Absicht
besteht darin, genügend Einzelheiten zu liefern, um anderen Evaluatoren und Evaluierungsinstanzen einen
Einblick in den Prüfansatz des Entwicklers, den Umfang der durchgeführten Prüfungen, die Prüf-
konfigurationen des TOEs und die Gesamtergebnisse der Entwicklerprüfungen zu ermöglichen.
Zu den Informationen, die üblicherweise im ETR-Unterabschnitt über den Prüfaufwand des Entwicklers zu
finden sind, gehören Folgende:
a) TOE-Prüfkonfigurationen. Die besonderen Konfigurationen des TOEs, die geprüft wurden, einschließlich
der Frage, ob für die Einrichtung der Prüfungen oder die anschließende Bereinigung ein
Berechtigungscode erforderlich war;
b) Prüfansatz. Ein Bericht über die gesamte Prüfstrategie des Entwicklers;
c) Prüfergebnisse. Eine Beschreibung der gesamten Prüfergebnisse des Entwicklers.
Diese Liste ist keineswegs erschöpfend und soll nur einen gewissen Kontext hinsichtlich der Art von
Informationen liefern, die im ETR bezüglich des Prüfaufwands des Entwicklers enthalten sein sollten.
13.5.2 Evaluierung der Unteraufgabe (ATE_FUN.2)
13.6 Unabhängiges Prüfen (ATE_IND)

13.6.1 Evaluierung der Unteraufgabe (ATE_IND.1)
Ziel dieser Aufgabe ist es, festzustellen, durch unabhängiges Prüfen einer Teilmenge der TSFI festzustellen, ob
sich der TOE so verhält, wie in der Funktionsspezifikation und der Leitliniendokumentation festgelegt.
13.6.1.2 Eingaben
a) die ST,
c) die operativen Leitlinien für Benutzer,
d) die vorbereitenden Leitlinien für Benutzer,
e) der zum Prüfen geeignete TOE.
232
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
13.6.1.3 Aktion ATE_IND.1.1E
ISO/IEC 15408-3 ATE_IND.1.1C: Der TOE muss zum Prüfen geeignet sein.
13.6.1.3.1 Workunit ATE_IND.1-1
Der Evaluator muss den TOE untersuchen, um festzustellen, dass die Prüfkonfiguration gegenüber der zu
evaluierenden Konfiguration, wie in der ST festgelegt, konsistent ist.
Der vom Entwickler bereitgestellte TOE sollte den gleichen eindeutigen Bezug haben, der durch die
Unteraufgaben der „CM capabilities“ (ALC_CMC) festgelegt und in der ST-Einführung identifiziert wurde.
Es ist möglich, dass die ST mehr als eine Konfiguration für die Evaluierung angibt. Der TOE kann eine Menge
unterschiedliche Hardware- und Software-Entitäten umfassen, die in Übereinstimmung mit der ST geprüft
werden müssen. Der Evaluator überprüft, ob alle Prüfkonfigurationen gegenüber der ST konsistent sind.
berücksichtigen, die für die Prüfumgebung gelten können, und sicherstellen, dass sie in der Prüfumgebung
erfüllt werden. Es kann einige Zielsetzungen für die Betriebsumgebung geben, die nicht für die Prüfumgebung
gelten. Beispielsweise kann es sein, dass eine Zielsetzung bezüglich der Benutzerfreigaben nicht zutrifft;
jedoch würde eine Zielsetzung bezüglich eines einzigen Verbindungspunktes zu einem Netzwerk gelten.
Wenn Prüfressourcen (z. B. Messgeräte, Analysegeräte) verwendet werden, liegt es in der Verantwortung des
Evaluators, sicherzustellen, dass diese Ressourcen korrekt kalibriert werden.
Der Evaluator muss den TOE untersuchen, um festzustellen, dass er ordnungsgemäß installiert wurde und
sich in einem bekannten Zustand befindet.
Es ist für den Evaluator möglich, den Zustand des TOEs auf verschiedene Arten zu bestimmen. Beispielsweise
wird diese Workunit durch den vorherigen erfolgreichen Abschluss der Unteraufgabe „Evaluation of sub-
activity“ (AGD_PRE.1) erfüllt, wenn der Evaluator weiterhin darauf vertraut, dass der TOE, der zum Prüfen
verwendet wird, ordnungsgemäß installiert wurde und sich in einem bekannten Zustand befindet. Wenn dies
nicht der Fall ist, sollte der Evaluator die Verfahren des Entwicklers zur Installation und Inbetriebnahme des
TOEs befolgen und dabei ausschließlich die mitgelieferten Leitlinien verwenden.
Wenn der Evaluator die Installationsverfahren durchführen muss, weil sich der TOE in einem unbekannten
Zustand befindet, könnte diese Workunit bei erfolgreichem Abschluss die Workunit AGD_PRE.1-3 erfüllen.
Der Evaluator muss eine Prüfteilmenge ausarbeiten.
Der Evaluator wählt eine Prüfteilmenge und eine Prüfstrategie aus, die für den TOE geeignet sind. Eine
extreme Prüfstrategie bestünde darin, dass die Prüfteilmenge so viele Schnittstellen wie möglich enthält und
mit geringer Strenge geprüft wird. Eine andere Prüfstrategie bestünde darin, dass die Prüfteilmenge einige
wenige Schnittstellen auf der Grundlage ihrer wahrgenommenen Relevanz enthält und diese Schnittstellen
streng geprüft werden.
Normalerweise sollte der vom Evaluator gewählte Prüfansatz irgendwo zwischen diesen beiden Extremen
liegen. Der Evaluator sollte die meisten Schnittstellen mit mindestens einer Prüfung anwenden, aber die
Prüfungen müssen keine erschöpfenden Spezifikationsprüfungen nachweisen.
233
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator sollte bei der Auswahl der Teilmenge der zu prüfenden Schnittstellen die folgenden Faktoren
berücksichtigen.
a) Die Anzahl der Schnittstellen, auf die für die Prüfteilmenge zurückgegriffen wird. Wenn die TSF nur eine
kleine Anzahl von relativ einfachen Schnittstellen umfasst, kann es praktisch sein, alle Schnittstellen
streng zu prüfen. In anderen Fällen ist dies möglicherweise nicht kosteneffizient und es sind
Probenahmen erforderlich.
b) Aufrechterhaltung eines ausgewogenen Verhältnisses von Evaluierungsaufgaben. Der Aufwand des

Evaluators für die Prüfaufgabe sollte in einem angemessenen Verhältnis zu dem Aufwand für jede andere
Evaluierungsaufgabe stehen.
Der Evaluator wählt die Schnittstellen aus, aus denen sich die Teilmenge zusammensetzt. Diese Auswahl hängt
von einer Menge Faktoren ab und die Berücksichtigung dieser Faktoren kann auch die Wahl der Größe der
Prüfteilmenge beeinflussen.
a) Signifikanz der Schnittstellen. Diejenigen Schnittstellen, die signifikanter sind als andere, sollten in die
Prüfteilmenge aufgenommen werden. Ein wichtiger Faktor der „Signifikanz“ ist die Sicherheitsrelevanz
(SFR-durchsetzende Schnittstellen wären signifikanter als SFR-unterstützende Schnittstellen, die
signifikanter sind als SFR-nicht-störende Schnittstellen; siehe ISO/IEC 15408-3 Unterabschnitt
„Functional specification“ (ADV_FSP)). Der andere wichtige Faktor der „Signifikanz“ ist die Anzahl der
SFRs, die dieser Schnittstelle zugeordnet sind (wie bei der Identifizierung der Entsprechung zwischen den
Abstraktionsebenen in der ADV ermittelt wurde).
b) Komplexität der Schnittstelle. Komplexe Schnittstellen können komplexe Prüfungen erfordern, die an den
Entwickler oder Evaluator belastende Anforderungen stellen und einer kostengünstigen Evaluierung
möglicherweise nicht förderlich sind. Umgekehrt besteht hier eine Wahrscheinlichkeit, dass Fehler
gefunden werden und sie sind gut geeignet für die Teilmenge. Der Evaluator wird ein Gleichgewicht
zwischen diesen Überlegungen finden müssen.
c) Implizite Prüfungen. Beim Prüfen einiger Schnittstellen können oft implizit andere Schnittstellen geprüft
werden, und ihre Aufnahme in die Teilmenge kann die Anzahl der geprüften Schnittstellen maximieren
(wenn auch implizit). Bestimmte Schnittstellen werden in der Regel verwendet, um eine Vielzahl von
Sicherheitsfunktionen bereitzustellen, und sind in der Regel das Ziel eines effektiven Prüfansatzes.
d) Arten von Schnittstellen (z. B. programmatisch, Befehlszeile, Protokoll). Der Evaluator sollte die
Aufnahme von Prüfungen für alle verschiedenen Arten von Schnittstellen, die der TOE unterstützt, in
Erwägung ziehen.
e) Schnittstellen, die zu innovativen oder ungewöhnlichen Merkmalen führen. Wenn der TOE innovative
oder ungewöhnliche Merkmale enthält, die in der Marketingliteratur und in Leitliniendokumenten stark
vertreten sein können, sollten die entsprechenden Schnittstellen für Prüfungen gut geeignet sein.
Diese Leitlinien formulieren Faktoren, die während des Auswahlprozesses einer geeigneten Prüfteilmenge zu
berücksichtigen sind, aber diese sind keineswegs erschöpfend.
234
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss für die Prüfteilmenge eine Prüfdokumentation vorlegen, die ausreichend detailliert ist,
um die Prüfungen reproduzierbar zu machen.
Mit einem Verständnis für das erwartete Verhalten der TSF aus der ST und der Funktionsspezifikation muss
der Evaluator die praktikabelste Methode zum Prüfen der Schnittstelle bestimmen. Konkret betrachtet der
Evaluator
a) den Ansatz, der verwendet wird, z. B. ob eine externe Schnittstelle geprüft wird, oder eine interne
Schnittstelle unter Verwendung eines Test-Harnischs, oder ob ein alternativer Prüfansatz verwendet
wird (z. B. in Ausnahmefällen eine Code-Inspektion, wenn die Darstellung der Implementierung
verfügbar ist);
b) die Schnittstelle(n), die zum Prüfen und Beobachten der Antworten verwendet wird (werden);
c) die Anfangsbedingungen, die für die Prüfung vorhanden sein müssen (d. h. bestimmte Objekte oder
Subjekte, die vorliegen müssen, und Sicherheitseigenschaften, die sie haben müssen);
d) spezielle Prüfgeräte, die entweder zur Stimulation einer Schnittstelle (z. B. Paketgeneratoren) oder zur
Beobachtung einer Schnittstelle (z. B. Netzwerkanalysatoren) benötigt werden.
Der Evaluator kann es für praktisch halten, jede Schnittstelle anhand einer Reihe von Prüffällen zu prüfen,
wobei jeder Prüffall einen sehr spezifischen Aspekt des erwarteten Verhaltens prüft.
Die Prüfdokumentation des Evaluators sollte die Ableitung jeder Prüfung spezifizieren und bis zu der/den
relevanten Schnittstelle(n) zurückverfolgen.
Der Evaluator muss eine Prüfung durchführen.
Der Evaluator verwendet die entwickelte Prüfdokumentation als Grundlage für die Durchführung von
Prüfungen am TOE. Die Prüfdokumentation wird als Grundlage für die Prüfungen verwendet, was jedoch nicht
ausschließt, dass der Evaluator zusätzliche Ad-hoc-Prüfungen durchführt. Der Evaluator kann neue Prüfungen
auf der Grundlage des während der Prüfungen entdeckten Verhaltens des TOEs ausarbeiten. Diese neuen
Prüfungen werden in der Prüfdokumentation festgehalten.
Der Evaluator muss die folgenden Informationen über die Prüfungen, aus denen sich die Prüfteilmenge
zusammensetzt, aufzeichnen:
a) Identifizierung des zu prüfenden Schnittstellenverhaltens;

b) Anweisungen zum Anschließen und Einrichten aller erforderlichen Prüfgeräte, die zur Durchführung der
Prüfung erforderlich sind;
c) Anweisungen zur Festlegung aller erforderlichen Prüfbedingungen;
d) Anweisungen zur Stimulierung der Schnittstelle;
e) Anweisungen zum Beobachten des Verhaltens der Schnittstelle;
f) Beschreibungen aller erwarteten Ergebnisse und die notwendige Analyse des beobachteten Verhaltens
zum Vergleich mit den erwarteten Ergebnissen;
g) Anweisungen zum Abschluss der Prüfung und zur Herstellung des erforderlichen Zustands nach der
Prüfung für den TOE;
h) tatsächliche Prüfergebnisse.
235
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Detaillierungsgrad sollte so hoch sein, dass ein anderer Evaluator die Prüfungen wiederholen und ein
gleichwertiges Ergebnis erzielen könnte. Obwohl einige spezifische Details der Prüfergebnisse unterschiedlich
sein können (z. B. Zeit- und Datumsfelder in einem Audit-Datensatz), sollte das Gesamtergebnis identisch sein.
Es kann Fälle geben, in denen es nicht notwendig ist, alle in dieser Workunit dargestellten Informationen zu
liefern (z. B. erfordern die tatsächlichen Prüfergebnisse einer Prüfung möglicherweise keine Analyse, bevor
ein Vergleich zwischen den erwarteten Ergebnissen vorgenommen werden kann). Die Festlegung, diese
Informationen wegzulassen, wird dem Evaluator überlassen, ebenso wie die Begründung.
Der Evaluator muss prüfen, ob alle tatsächlichen Prüfergebnisse gegenüber den erwarteten Prüfergebnissen
konsistent sind.
Alle Unterschiede zwischen den tatsächlichen und den erwarteten Prüfergebnissen können darauf hindeuten,
dass der TOE nicht wie festgelegt arbeitet oder dass die Prüfdokumentation des Evaluators falsch sein kann.
Unerwartete tatsächliche Ergebnisse können eine korrektive Wartung des TOEs oder der Prüfdokumentation
und möglicherweise eine erneute Durchführung der betroffenen Prüfungen sowie eine Änderung der Größe
und Zusammensetzung der Prüfstichprobe erforderlich machen. Diese Festlegung wird dem Evaluator
überlassen, ebenso wie ihre Begründung.
Der Evaluator muss im ETR über den Prüfaufwand des Evaluators berichten und dabei den Prüfansatz, die
Die vom Evaluator im ETR gemeldeten Prüfinformationen ermöglichen es dem Evaluator, den gesamten
Prüfansatz und den Aufwand für die Prüfaufgabe während der Evaluierung zu vermitteln. Die Absicht, diese
Informationen bereitzustellen, besteht darin, einen aussagekräftigen Überblick über den Prüfaufwand zu
geben. Es ist nicht beabsichtigt, dass die Informationen über Prüfungen im ETR eine exakte Wiedergabe
bestimmter Prüfanweisungen oder Ergebnisse einzelner Prüfungen darstellen. Die Absicht besteht darin,
genügend Einzelheiten zu liefern, um anderen Evaluatoren und Evaluierungsinstanzen einen gewissen
Einblick in den gewählten Prüfansatz, den Umfang der durchgeführten Prüfungen, die Prüfkonfigurationen
des TOEs und die Gesamtergebnisse der Prüftätigkeit zu ermöglichen.
Zu den Informationen, die üblicherweise im ETR-Unterabschnitt über den Prüfaufwand des Evaluators zu
a) TOE-Prüfkonfigurationen. Die besonderen Konfigurationen des TOEs, die geprüft wurden;

b) die gewählte Größe der Teilmenge. Die Anzahl der Schnittstellen, die während der Evaluierung geprüft
wurden, und eine Begründung für die Größe;
c) Auswahlkriterien für die Schnittstellen, aus denen sich die Teilmenge zusammensetzt. Kurze Aussagen
über die Faktoren, die bei der Auswahl der Schnittstellen zur Aufnahme in die Teilmenge berücksichtigt
wurden;
d) geprüfte Schnittstellen. Eine kurze Auflistung der Schnittstellen, die für die Aufnahme in die Teilmenge
geeignet sind;
e) Entscheidung für die Aufgabe. Die Gesamtbeurteilung der Ergebnisse der Prüfung während der
Evaluierung.
Informationen liefern, die im ETR bezüglich der vom Evaluator während der Evaluierung durchgeführten
Prüfungen vorhanden sein sollten.
236
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Ziel dieser Aufgabe ist es, durch unabhängiges Prüfen einer Teilmenge der TSF festzustellen, ob sich der TOE
wie in der Designdokumentation festgelegt verhält, und Vertrauen in die Prüfergebnisse des Entwicklers zu
gewinnen, indem eine Stichprobe der Prüfungen des Entwicklers vorgenommen wird.
13.6.2.2 Eingaben
a) die ST,
c) die Beschreibung des TOEs-Designs,
d) die operativen Leitlinien für Benutzer,
e) die vorbereitenden Leitlinien für Benutzer,
f) die Konfigurationsmanagementdokumentation,
g) die Prüfdokumentation,
h) der zum Prüfen geeignete TOE.
ISO/IEC 15408-3 ATE_IND.2.1C: Der TOE muss zum Prüfen geeignet sein.
Der vom Entwickler bereitgestellte und im Prüfplan identifizierte TOE sollte den gleichen eindeutigen Bezug
237
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
ISO/IEC 15408-3 ATE_IND.2.2C: Der Entwickler muss einen gleichwertigene Satz von Ressourcen bereitstellen,
wie sie bei den TSF-Funktionsprüfungen durch den Entwickler verwendet wurden.
Der Evaluator muss die vom Entwickler zur Verfügung gestellte Menge Ressourcen untersuchen, um
festzustellen, ob sie mit der Menge Ressourcen übereinstimmt, die der Entwickler für die Funktionsprüfung
der TSF verwendet hat.
Die vom Entwickler verwendete Menge Ressourcen wird im Entwicklerprüfplan dokumentiert, wie in der
Familie der „Functional tests“ (ATE_FUN) berücksichtigt. Die Menge Ressourcen kann u. a. den Zugang zum
Labor und spezielle Prüfgeräte umfassen. Ressourcen, die nicht mit den vom Entwickler verwendeten
identisch sind, müssen in Bezug auf ihre Auswirkungen auf die Prüfergebnisse gleichwertig sein.
Der Evaluator muss die Prüfung unter Verwendung einer Stichprobe von Prüfungen durchführen, die im
Prüfplan und den Verfahren des Entwicklers enthalten sind.
Das Gesamtziel dieser Workunit besteht darin, eine ausreichende Anzahl von Entwicklerprüfungen
durchzuführen, um die Gültigkeit der Prüfergebnisse des Entwicklers zu bestätigen. Der Evaluator muss über
die Größe der Stichprobe und die Entwicklerprüfungen, aus denen sich die Stichprobe zusammensetzt,
entscheiden (siehe A.2).
Alle Entwicklerprüfungen lassen sich bis zu bestimmten Schnittstellen zurückverfolgen. Daher sind die
Faktoren, die bei der Auswahl der Prüfungen zur Zusammenstellung der Stichprobe zu berücksichtigen sind,
ähnlich denen, die für die Teilmengenauswahl in Workunit ATE_IND.2-6 aufgelistet sind. Zusätzlich möchte
der Evaluator möglicherweise ein Zufallsstichprobenverfahren anwenden, um Entwicklerprüfungen
auszuwählen, die in die Stichprobe aufgenommen werden sollen.
konsistent sind.
Inkonsistenzen zwischen den erwarteten Prüfergebnissen des Entwicklers und den tatsächlichen
Prüfergebnissen zwingen den Evaluator, die Diskrepanzen aufzulösen. Inkonsistenzen, auf die der Evaluator
gestoßen ist, könnten durch eine stichhaltige Begründung und Auflösung der Inkonsistenzen durch den
Entwickler behoben werden.
238
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Wenn keine zufriedenstellende Erklärung oder Auflösung erreicht werden kann, kann das Vertrauen des
Evaluators in die Prüfergebnisse des Entwicklers geschwächt werden, und es kann notwendig sein, dass der
Evaluator die Stichprobengröße so weit erhöht, dass die in Workunit ATE_IND.2-4 identifizierte Teilmenge
angemessen geprüft wird: Mängel bei den Prüfungen des Entwicklers müssen entweder zu Korrektur-
maßnahmen am TOE durch den Entwickler führen (z. B, wenn die Inkonsistenz durch falsches Verhalten
verursacht wird) oder an den Prüfungen des Entwicklers (z. B. wenn die Inkonsistenz durch eine falsche
Prüfung verursacht wird) oder bei der Erstellung neuer Prüfungen durch den Evaluator führen.
Der Evaluator muss eine Prüfteilmenge ausarbeiten.
Der Evaluator wählt eine Prüfteilmenge und eine Prüfstrategie aus, die für den TOE geeignet sind. Eine
extreme Prüfstrategie bestünde darin, dass die Prüfteilmenge so viele Schnittstellen wie möglich enthält und
mit geringer Strenge geprüft wird. Eine andere Prüfstrategie bestünde darin, dass die Prüfteilmenge einige
wenige Schnittstellen auf der Grundlage ihrer wahrgenommenen Relevanz enthält und diese Schnittstellen
streng geprüft werden.
Normalerweise sollte der vom Evaluator gewählte Prüfansatz irgendwo zwischen diesen beiden Extremen
liegen. Der Evaluator sollte die meisten Schnittstellen mit mindestens einer Prüfung anwenden, aber die
Prüfungen müssen keine erschöpfenden Spezifikationsprüfungen nachweisen.
Der Evaluator sollte bei der Auswahl der Teilmenge der zu prüfenden Schnittstellen die folgenden Faktoren
berücksichtigen:
a) Der Prüfnachweis des Entwicklers. Der Prüfnachweis des Entwicklers besteht aus: der
Prüfdokumentation, der verfügbaren Prüfabdeckungsanalyse und der verfügbaren Tiefe der Prüfanalyse.
Der Prüfnachweis des Entwicklers gibt Aufschluss darüber, wie die TSF vom Entwickler während der
Prüfung ausgeführt wurde. Der Evaluator verwendet diese Informationen bei der Entwicklung neuer
Prüfungen, um den TOE unabhängig zu prüfen. Konkret sollte der Evaluator Folgendes betrachten:
1) Erweiterung der Entwicklerprüfung für Schnittstellen. Möglicherweise möchte der Evaluator mehr
von derselben Art von Prüfungen durchführen, indem er die Parameter variiert, um die Schnittstelle
strenger zu prüfen.
2) Ergänzung der Entwicklerprüfstrategie für Schnittstellen. Der Evaluator möchte möglicherweise den
Prüfansatz einer bestimmten Schnittstelle variieren, indem er sie mit einer anderen Prüfstrategie
prüft.
b) Die Anzahl der Schnittstellen, auf die für die Prüfteilmenge zurückgegriffen wird. Wenn die TSF nur eine
kleine Anzahl von relativ einfachen Schnittstellen umfasst, kann es praktisch sein, alle streng zu prüfen.
In anderen Fällen ist dies möglicherweise nicht kosteneffizient und es sind Probenahmen erforderlich.
c) Aufrechterhaltung eines ausgewogenen Verhältnisses von Evaluierungsaufgaben. Der Aufwand des

Evaluators für die Prüfaufgabe sollte in einem angemessenen Verhältnis zu dem Aufwand für jede andere
Evaluierungsaufgabe stehen.
Der Evaluator wählt die Schnittstellen aus, aus denen sich die Teilmenge zusammensetzt. Diese Auswahl hängt
von einer Menge Faktoren ab und die Berücksichtigung dieser Faktoren kann auch die Wahl der Größe der
Prüfteilmenge beeinflussen.
a) Strenge des Entwicklers beim Prüfen der Schnittstellen. Diejenigen Schnittstellen, die nach Ansicht des
Evaluators zusätzliche Prüfungen erfordern, sollten in die Prüfteilmenge aufgenommen werden.
239
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
b) Prüfergebnisse des Entwicklers. Wenn die Ergebnisse der Entwicklerprüfungen den Evaluator daran
zweifeln lassen, dass eine Schnittstelle nicht ordnungsgemäß implementiert ist, dann sollte der Evaluator
solche Schnittstellen in die Prüfteilmenge aufnehmen.
c) Signifikanz der Schnittstellen. Diejenigen Schnittstellen, die signifikanter sind als andere, sollten in die
Prüfteilmenge aufgenommen werden. Ein wichtiger Faktor der „Signifikanz“ ist die Sicherheitsrelevanz
(SFR-durchsetzende Schnittstellen wären signifikanter als SFR-unterstützende Schnittstellen, die
signifikanter sind als SFR-nicht-störende Schnittstellen; siehe ISO/IEC 15408-3 Unterabschnitt
ADV_FSP). Der andere wichtige Faktor der „Signifikanz“ ist die Anzahl der SFRs, die dieser Schnittstelle
zugeordnet sind (wie bei der Identifizierung der Entsprechung zwischen den Abstraktionsebenen in der
ADV ermittelt wurde).
d) Komplexität der Schnittstellen. Schnittstellen, die eine komplexe Implementierung erfordern, können
komplexe Prüfungen erfordern, die an den Entwickler oder Evaluator belastende Anforderungen stellen,
die einer kostengünstigen Evaluierung möglicherweise nicht förderlich sind. Umgekehrt besteht hier eine
Wahrscheinlichkeit, dass Fehler gefunden werden und sie sind gut geeignet für die Teilmenge. Der
Evaluator wird ein Gleichgewicht zwischen diesen Überlegungen finden müssen.
e) Implizite Prüfungen. Beim Prüfen einiger Schnittstellen können oft implizit andere Schnittstellen geprüft
werden, und ihre Aufnahme in die Teilmenge kann die Anzahl der geprüften Schnittstellen maximieren
(wenn auch implizit). Bestimmte Schnittstellen werden in der Regel verwendet, um eine Vielzahl von
Sicherheitsfunktionen bereitzustellen, und sind in der Regel das Ziel eines effektiven Prüfansatzes.
f) Arten von Schnittstellen (z. B. programmatisch, Befehlszeile, Protokoll). Der Evaluator sollte die
Aufnahme von Prüfungen für alle verschiedenen Arten von Schnittstellen, die der TOE unterstützt, in
Erwägung ziehen.
g) Schnittstellen, die zu innovativen oder ungewöhnlichen Merkmalen führen. Wenn der TOE innovative
oder ungewöhnliche Merkmale enthält, die in der Marketingliteratur und in Leitliniendokumenten stark
vertreten sein können, sollten die entsprechenden Schnittstellen für Prüfungen gut geeignet sein.
Diese Leitlinien formulieren Faktoren, die während des Auswahlprozesses einer geeigneten Prüfteilmenge zu
berücksichtigen sind, aber diese sind keineswegs erschöpfend.
Der Evaluator muss für die Prüfteilmenge eine Prüfdokumentation vorlegen, die ausreichend detailliert ist,
um die Prüfungen reproduzierbar zu machen.
Mit einem Verständnis für das erwartete Verhalten der TSF aus der ST, der Funktionsspezifikation und der
Beschreibung des TOEs-Designs muss der Evaluator die praktikabelste Methode zum Prüfen der Schnittstelle
bestimmen. Konkret betrachtet der Evaluator
a) den Ansatz, der verwendet wird, z. B. ob eine externe Schnittstelle geprüft wird, oder eine interne
Schnittstelle unter Verwendung eines Test-Harnischs, oder ob ein alternativer Prüfansatz verwendet wird
(z. B. in Ausnahmefällen eine Code-Inspektion),
b) die Schnittstelle(n), die zum Prüfen und Beobachten der Antworten verwendet wird (werden),
c) die Anfangsbedingungen, die für die Prüfung vorhanden sein müssen (d. h. bestimmte Objekte oder
Subjekte, die vorliegen müssen, und Sicherheitseigenschaften, die sie haben müssen),
d) spezielle Prüfgeräte, die entweder zur Stimulation einer Schnittstelle (z. B. Paketgeneratoren) oder zur
Beobachtung einer Schnittstelle (z. B. Netzwerkanalysatoren) benötigt werden.
240
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator kann es für praktisch halten, jede Schnittstelle anhand einer Reihe von Prüffällen zu prüfen,
wobei jeder Prüffall einen sehr spezifischen Aspekt des erwarteten Verhaltens dieser Schnittstelle prüft.
Die Prüfdokumentation des Evaluators sollte die Ableitung jeder Prüfung spezifizieren und bis zu der/den
relevanten Schnittstelle(n) zurückverfolgen.
Der Evaluator muss eine Prüfung durchführen.
Der Evaluator verwendet die entwickelte Prüfdokumentation als Grundlage für die Durchführung von
Prüfungen am TOE. Die Prüfdokumentation wird als Grundlage für die Prüfungen verwendet, was jedoch nicht
ausschließt, dass der Evaluator zusätzliche Ad-hoc-Prüfungen durchführt. Der Evaluator kann neue Prüfungen
auf der Grundlage des während der Prüfungen entdeckten Verhaltens des TOEs ausarbeiten. Diese neuen
Prüfungen werden in der Prüfdokumentation festgehalten.
Der Evaluator muss die folgenden Informationen über die Prüfungen, aus denen sich die Prüfteilmenge
zusammensetzt, aufzeichnen:
a) Identifizierung des zu prüfenden Schnittstellenverhaltens;
b) Anweisungen zum Anschließen und Einrichten aller erforderlichen Prüfgeräte, die zur Durchführung der
Prüfung erforderlich sind;
c) Anweisungen zur Festlegung aller erforderlichen Prüfbedingungen;
d) Anweisungen zur Stimulierung der Schnittstelle;
e) Anweisungen zur Beobachtung der Schnittstelle;
Prüfung für den TOE;
h) tatsächliche Prüfergebnisse.
Der Detaillierungsgrad sollte so hoch sein, dass ein anderer Evaluator die Prüfungen wiederholen und ein
gleichwertiges Ergebnis erzielen könnte. Obwohl einige spezifische Details der Prüfergebnisse unterschiedlich
sein können (z. B. Zeit- und Datumsfelder in einem Audit-Datensatz), sollte das Gesamtergebnis identisch sein.
Es kann Fälle geben, in denen es nicht notwendig ist, alle in dieser Workunit dargestellten Informationen zu
liefern (z. B. erfordern die tatsächlichen Prüfergebnisse einer Prüfung möglicherweise keine Analyse, bevor
ein Vergleich zwischen den erwarteten Ergebnissen vorgenommen werden kann). Die Festlegung, diese
Informationen wegzulassen, wird dem Evaluator überlassen, ebenso wie die Begründung.
konsistent sind.
Alle Unterschiede zwischen den tatsächlichen und den erwarteten Prüfergebnissen können darauf hindeuten,
dass der TOE nicht wie festgelegt arbeitet oder dass die Prüfdokumentation des Evaluators falsch sein kann.
Unerwartete tatsächliche Ergebnisse können eine korrektive Wartung des TOEs oder der Prüfdokumentation
und möglicherweise eine erneute Durchführung der betroffenen Prüfungen sowie eine Änderung der Größe
und Zusammensetzung der Prüfstichprobe erforderlich machen. Diese Festlegung wird dem Evaluator
überlassen, ebenso wie ihre Begründung.
241
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss im ETR über den Prüfaufwand des Evaluators berichten und dabei den Prüfansatz, die
Die vom Evaluator im ETR gemeldeten Prüfinformationen ermöglichen es dem Evaluator, den gesamten
Prüfansatz und den Aufwand für die Prüfaufgabe während der Evaluierung zu vermitteln. Die Absicht, diese
Informationen bereitzustellen, besteht darin, einen aussagekräftigen Überblick über den Prüfaufwand zu
geben. Es ist nicht beabsichtigt, dass die Informationen über Prüfungen im ETR eine exakte Wiedergabe
bestimmter Prüfanweisungen oder Ergebnisse einzelner Prüfungen darstellen. Die Absicht besteht darin,
genügend Einzelheiten zu liefern, um anderen Evaluatoren und Evaluierungsinstanzen einen gewissen
Einblick in den gewählten Prüfansatz, den Umfang der durchgeführten Prüfungen des Evaluators, den Umfang
der durchgeführten Prüfungen des Entwicklers, die Prüfkonfigurationen des TOEs und die Gesamtergebnisse
der Prüfaufgabe zu ermöglichen.
Zu den Informationen, die üblicherweise im ETR-Unterabschnitt über den Prüfaufwand des Evaluators zu
a) TOE-Prüfkonfigurationen. Die besonderen Konfigurationen des TOEs, die geprüft wurden;
b) die gewählte Größe der Teilmenge. Die Anzahl der Schnittstellen, die während der Evaluierung geprüft
wurden, und eine Begründung für die Größe;
c) Auswahlkriterien für die Schnittstellen, aus denen sich die Teilmenge zusammensetzt. Kurze Aussagen
über die Faktoren, die bei der Auswahl der Schnittstellen zur Aufnahme in die Teilmenge berücksichtigt
wurden;
d) Geprüfte Schnittstellen. Eine kurze Auflistung der Schnittstellen, die für die Aufnahme in die Teilmenge
geeignet sind;
e) durchgeführte Entwicklerprüfungen. Die Anzahl der durchgeführten Entwicklerprüfungen und eine
kurze Beschreibung der Kriterien, die zur Auswahl der Prüfungen verwendet wurden;
f) Entscheidung für die Aufgabe. Die Gesamtbeurteilung der Ergebnisse der Prüfung während der
Evaluierung.
Prüfungen vorhanden sein sollten.
14 Klasse AVA: Anfälligkeitsbewertung
14.1 Einleitung
Der Zweck der Aufgabe der Anfälligkeitsbewertung besteht darin, die Ausnutzbarkeit von Mängeln oder
Schwächen des TOEs in der Betriebsumgebung zu bestimmen. Diese Festlegung basiert auf der Analyse der
Evaluationsnachweise und einer Suche nach öffentlich zugänglichem Material durch den Evaluator und wird
durch Penetrationstests des Evaluators unterstützt.
242
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
14.2 Anfälligkeitsanalyse (AVA_VAN)

14.2.1 Evaluierung der Unteraufgabe (AVA_VAN.1)
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob der TOE in seiner Betriebsumgebung
leicht identifizierbare ausnutzbare Anfälligkeiten aufweist.
14.2.1.2 Eingaben
a) die ST,
b) die Leitliniendokumentation,
c) der zum Prüfen geeignete TOE,
d) öffentlich zugängliche Informationen zur Unterstützung der Identifizierung potentieller Anfälligkeiten.
Weitere Eingaben für diese Unteraufgabe sind
a) aktuelle Informationen über potentielle Anfälligkeiten (z. B. von einer Evaluierungsinstanz).
Der Evaluator sollte die Durchführung zusätzlicher Prüfungen in Betracht ziehen, da bei der Durchführung
anderer Teile der Evaluierung potentielle Anfälligkeiten festgestellt wurden.
Die Verwendung des Begriffs Leitlinien in dieser Unteraufgabe bezieht sich auf die operativen Leitlinien und
die vorbereitenden Leitlinien.
Potentielle Anfälligkeiten können in öffentlich zugänglichen Informationen liegen oder auch nicht, und ihre
Ausnutzung kann Fertigkeiten erfordern oder auch nicht. Diese beiden Aspekte hängen zusammen, sind aber
unterschiedlich. Es sollte nicht davon ausgegangen werden, dass eine potentielle Anfälligkeit, nur weil sie aus
öffentlich zugänglichen Informationen erkennbar ist, leicht ausgenutzt werden kann.
14.2.1.4 Aktion AVA_VAN.1.1E
ISO/IEC 15408-3 AVA_VAN.1.1C: Der TOE muss zum Prüfen geeignet sein.
14.2.1.4.1 Workunit AVA_VAN.1-1
243
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss öffentlich zugängliche Informationsquellen untersuchen, um potentielle Anfälligkeiten

im TOE zu identifizieren.
Der Evaluator untersucht die öffentlich zugänglichen Informationsquellen, um die Identifizierung möglicher
potentieller Anfälligkeiten im TOE zu unterstützen. Es gibt viele öffentlich zugängliche Informationsquellen,
die in Betracht gezogen werden sollten, z. B. Mailinglisten und Sicherheitsforen im World Wide Web, die über
bekannte Anfälligkeiten in bestimmten Technologien berichten.
Der Evaluator sollte die Berücksichtigung öffentlich zugänglicher Informationen nicht auf die oben genannten
Punkte beschränken, sondern alle anderen verfügbaren relevanten Informationen berücksichtigen.
Bei der Prüfung der vorgelegten Nachweise wird der Evaluator die öffentlich zugänglichen Informationen
nutzen, um weiter nach potentiellen Anfälligkeiten zu suchen. Wenn die Evaluatoren Problemfelder
identifiziert haben, sollte der Evaluator öffentlich zugängliche Informationen berücksichtigen, die sich auf
diese Problemfelder beziehen.
Die Verfügbarkeit von Informationen, die für einen Angreifer leicht zugänglich sein können und die dazu
beitragen, Angriffe effektiv zu identifizieren und zu erleichtern, trägt dazu bei, das Angriffspotential eines
bestimmten Angreifers erheblich zu steigern. Die Zugänglichkeit von Anfälligkeitsinformationen und
ausgeklügelten Angriffstools im Internet macht es wahrscheinlicher, dass diese Informationen bei Versuchen,
potentielle Anfälligkeiten im TOE zu identifizieren und auszunutzen, verwendet werden. Moderne Suchtools
machen solche Informationen für den Evaluator leicht zugänglich, und die Bestimmung der Beständigkeit
gegen veröffentlichte potentielle Anfälligkeiten und bekannte generische Angriffe kann auf kosteneffiziente
Weise erreicht werden.
Die Suche nach den öffentlich verfügbaren Informationen sollte sich auf diejenigen Quellen konzentrieren, die
sich speziell auf das Produkt beziehen, von dem der TOE abgeleitet ist. Die Ausführlichkeit dieser Suche sollte
die folgenden Faktoren berücksichtigen: TOE-Typ, Erfahrung des Evaluators mit diesem TOE-Typ, erwartetes
Angriffspotential und die Ebene der verfügbaren ADV-Nachweise.
Der Identifizierungsprozess ist iterativ, wobei die Identifizierung einer potentiellen Anfälligkeit zur
Identifizierung eines anderen Problembereichs führen kann, der weiterer Untersuchungen bedarf.
244
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator wird berichten, welche Aktionen ergriffen wurden, um potentielle Anfälligkeiten in den
öffentlich zugänglichen Informationen zu identifizieren. Bei dieser Art von Suche ist der Evaluator jedoch
möglicherweise nicht in der Lage, die Schritte zur Identifizierung potentieller Anfälligkeiten vor Beginn der
Untersuchung zu beschreiben, da sich der Ansatz aufgrund der Ergebnisse bei der Suche weiterentwickeln
kann.
Der Evaluator wird über die Nachweise berichten, die bei der Suche nach potentiellen Anfälligkeiten
untersucht wurden.
Der Evaluator muss im ETR die identifizierten potentiellen Anfälligkeiten aufzeichnen, die für Prüfungen
geeignet und auf den TOE in seiner Betriebsumgebung anwendbar sind.
Es kann festgestellt werden, dass keine weitere Berücksichtigung der potentiellen Anfälligkeit erforderlich ist,
wenn der Evaluator beispielsweise feststellt, dass Maßnahmen in der Betriebsumgebung, sei es IT oder
Nicht-IT, die Ausnutzung der potentiellen Anfälligkeit in dieser Betriebsumgebung verhindern. Beispielsweise
kann nur die Beschränkung des physischen Zugangs zum TOE auf autorisierte Benutzer effektiv dafür sorgen,
dass eine potentielle Anfälligkeit für Eingriffe nicht ausgenutzt wird.
Der Evaluator zeichnet alle Gründe für den Ausschluss potentieller Anfälligkeiten von der weiteren
Betrachtung auf, wenn er feststellt, dass die potentielle Anfälligkeit in der Betriebsumgebung nicht anwendbar
ist. Andernfalls zeichnet der Evaluator die potentielle Anfälligkeit zur weiteren Betrachtung auf.
Eine Liste potentieller Anfälligkeiten, die auf den TOE in seiner Betriebsumgebung anwendbar sind und die
als Eingabe für Penetrationstestaufgaben verwendet werden können, muss von den Evaluatoren im ETR
gemeldet werden.
Der Evaluator muss Penetrationstests ausarbeiten, die auf der unabhängigen Suche nach potentiellen
Anfälligkeiten basieren.
Der Evaluator bereitet die Penetrationstests vor, die erforderlich sind, um die Empfindlichkeit des TOEs in
seiner Betriebsumgebung gegenüber den potentiellen Anfälligkeiten zu bestimmen, die bei der Suche nach
den öffentlich zugänglichen Informationsquellen festgestellt wurden. Alle aktuellen Informationen, die dem
Evaluator von einer dritten Partei (z. B. der Evaluierungsinstanz) über bekannte potentielle Anfälligkeiten zur
Verfügung gestellt werden, werden vom Evaluator zusammen mit allen potentiellen Anfälligkeiten, die bei der
Durchführung anderer Evaluierungsaufgaben aufgetreten sind, berücksichtigt.
Der Evaluator wird es wahrscheinlich praktisch finden, Penetrationstests anhand einer Reihe von Prüffällen
durchzuführen, wobei jeder Prüffall auf eine bestimmte potentielle Anfälligkeit hin geprüft wird.
Vom Evaluator wird nicht erwartet, dass er auf potentielle Anfälligkeiten (einschließlich solcher im
öffentlichen Bereich) prüft, die über diejenigen hinausgehen, die ein Angriffspotential Basic erfordern. In
einigen Fällen wird es jedoch notwendig sein, eine Prüfung durchzuführen, bevor die Ausnutzbarkeit
bestimmt werden kann. Entdeckt der Evaluator als Ergebnis des Evaluierungsgutachtens eine potentielle
Anfälligkeit, die über das Angriffspotential Basic hinausgeht, wird dies im ETR als Restanfälligkeit gemeldet.
245
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss die Dokumentation der Penetrationstests für die Prüfungen auf der Grundlage der Liste
der potentiellen Anfälligkeiten so detailliert vorlegen, dass die Prüfungen wiederholbar sind. Die
Prüfdokumentation muss Folgendes enthalten:
a) die Identifizierung der potentiellen Anfälligkeit, auf die der TOE geprüft wird;
b) Anweisungen zum Anschließen und Einrichten aller erforderlichen Prüfgeräte, die zur Durchführung des
Penetrationstests erforderlich sind;
c) Anweisungen zur Festlegung aller für den Penetrationstest erforderlichen Ausgangsbedingungen;
d) Anweisungen zur Stimulierung der TSF;
e) Anweisungen zum Beobachten des Verhaltens der TSF;
Prüfung für den TOE.
Der Evaluator bereitet sich auf Penetrationstests vor, die auf der Liste potentieller Anfälligkeiten basieren und
bei der Suche im öffentlichen Bereich identifiziert wurden.
Vom Evaluator wird nicht erwartet, dass er die Ausnutzbarkeit für potentielle Anfälligkeiten bestimmt, die
über diejenigen hinausgehen, für die ein Angriffspotential Basic zur Durchführung eines Angriffs erforderlich
sind. Als Ergebnis des Evaluierungsgutachtens kann der Evaluator jedoch eine potentielle Anfälligkeit
entdecken, die nur von einem Angreifer mit einem größeren als dem Angriffspotential Basic ausgenutzt
werden kann. Solche Anfälligkeiten sind im ETR als Restanfälligkeiten zu melden.
Mit dem Verständnis der potentiellen Anfälligkeit bestimmt der Evaluator die praktikabelste Art und Weise,
auf die Empfindlichkeit des TOEs zu prüfen. Konkret betrachtet der Evaluator
a) die TSFI oder eine andere TOE-Schnittstelle, die zur Stimulierung der TSF und zur Beobachtung der
Antworten verwendet wird;
b) Anfangsbedingungen, die für die Prüfung vorhanden sein müssen (d. h. bestimmte Objekte oder Subjekte,
die vorliegen müssen, und Sicherheitseigenschaften, die sie haben müssen);
c) spezielle Prüfgeräte, die entweder zur Stimulierung einer TSFI oder zur Beobachtung einer TSFI benötigt
werden (obwohl es unwahrscheinlich ist, dass Spezialgeräte erforderlich wären, um eine potentielle
Anfälligkeit auszunutzen, wenn von einem Angriffspotential Basic ausgegangen wird);
d) ob die theoretische Analyse die physische Prüfung ersetzen sollte, insbesondere dann, wenn die
Ergebnisse einer Erstprüfung extrapoliert werden können, um aufzuzeigen, dass wiederholte Versuche
eines Angriffs nach einer bestimmten Anzahl von Versuchen wahrscheinlich erfolgreich sein werden.
Die Absicht, diesen Detaillierungsgrad in der Prüfdokumentation festzulegen, ist es, einem anderen Evaluator
die Möglichkeit zu geben, die Prüfungen zu wiederholen und ein gleichwertiges Ergebnis zu erzielen.
246
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss Penetrationstests durchführen.
Der Evaluator verwendet die aus Workunit AVA_VAN.1-5 resultierende Dokumentation der Penetrationstests
als Grundlage für die Durchführung von Penetrationstests am TOE, was den Evaluator jedoch nicht daran
hindert, zusätzliche Ad-hoc-Penetrationstests durchzuführen. Bei Bedarf kann der Evaluator aufgrund der bei
den Penetrationstests gewonnenen Informationen Ad-hoc-Prüfungen ausarbeiten, die, falls sie vom Evaluator
durchgeführt werden, in der Dokumentation des Penetrationstests festzuhalten sind. Solche Prüfungen
können erforderlich sein, um unerwartete Ergebnisse oder Beobachtungen nachzuverfolgen oder um
potentielle Anfälligkeiten zu untersuchen, die dem Evaluator während der im Voraus geplanten Prüfungen
vorgeschlagen wurden.
bestimmt werden kann. Entdeckt der Evaluator als Ergebnis des Evaluierungsgutachtens eine potentielle
Der Evaluator muss die tatsächlichen Ergebnisse der Penetrationstests aufzeichnen.
Obwohl einige spezifische Details der tatsächlichen Prüfergebnisse von den erwarteten abweichen können
(z. B. Zeit- und Datumsfelder in einem Audit-Datensatz), sollte das Gesamtergebnis identisch sein. Alle
unerwarteten Prüfergebnisse sollten untersucht werden. Die Auswirkungen auf die Evaluierung sollten
angegeben und begründet werden.
Der Evaluator muss im ETR über den Aufwand der Penetrationstests für den Evaluator berichten und dabei
den Prüfansatz, die Konfiguration, die Tiefe und die Ergebnisse skizzieren.
Die im ETR berichteten Informationen über Penetrationstests ermöglichen es dem Evaluator, den gesamten
Penetrationstestansatz und den für diese Unteraufgabe aufgewendeten Aufwand zu vermitteln. Die Absicht,
diese Informationen bereitzustellen, besteht darin, einen aussagekräftigen Überblick über den Aufwand der
Penetrationstests für den Evaluator zu geben. Es ist nicht beabsichtigt, dass die Informationen über
Penetrationstests im ETR eine exakte Wiedergabe bestimmter Prüfschritte oder Ergebnisse einzelner
Penetrationstests darstellen. Die Absicht besteht darin, genügend Einzelheiten zu liefern, um anderen
Evaluatoren und Evaluierungsinstanzen einen gewissen Einblick in den gewählten Penetrationstestansatz,
den Umfang der durchgeführten Penetrationstests, die Prüfkonfigurationen des TOEs und die Gesamt-
ergebnisse der Penetrationstestaufgabe zu ermöglichen.
Zu den Informationen, die üblicherweise im ETR-Unterabschnitt über den Aufwand der Penetrationstests für
den Evaluator zu finden wären, gehören Folgende:
a) TOE-Prüfkonfigurationen. Die besonderen Konfigurationen des TOEs, deren Penetration geprüft wurde;
b) Prüfung auf Penetration der TSFI. Eine kurze Auflistung der TSFI- und anderer TOE-Schnittstellen, die im
Mittelpunkt der Penetrationstests standen;
c) Entscheidung für die Unteraufgabe. Die Gesamtbeurteilung der Ergebnisse der Penetrationstests.
Penetrationstests vorhanden sein sollten.
247
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss die Ergebnisse aller Penetrationstests untersuchen, um festzustellen, dass der TOE in
seiner Betriebsumgebung gegen einen Angreifer mit einem Angriffspotential Basic resistent ist.
Wenn die Ergebnisse zeigen, dass der TOE in seiner Betriebsumgebung Anfälligkeiten aufweist, die von einem
Angreifer mit weniger als dem Angriffspotential Enhanced-Basic ausgenutzt werden können, dann schlägt
diese Evaluatorenaktion fehl.
Die Leitlinien für Benutzer in B.4 sollten dazu dienen, das Angriffspotential zu bestimmen, das zur Ausnutzung
einer bestimmten Anfälligkeit erforderlich ist, und ob sie daher in der vorgesehenen Umgebung ausgenutzt
werden können. Möglicherweise muss das Angriffspotential nicht in jedem Fall berechnet werden, sondern
nur dann, wenn Zweifel bestehen, ob die Anfälligkeit von einem Angreifer mit einem geringeren
Angriffspotential als Enhanced-Basic ausgenutzt werden kann oder nicht.
Der Evaluator muss im ETR über alle ausnutzbaren Anfälligkeiten und Restanfälligkeiten berichten, wobei er
für jede einzelne Anfälligkeit detaillierte Angaben macht:
a) ihre Quelle (z. B. Aufgabe zur Evaluierungsmethodik, die bei der Konzeption durchgeführt wurde, dem
Evaluator bekannt ist und in einer Veröffentlichung gelesen wurde);
b) die nicht erfüllte(n) SFR(s);
c) eine Beschreibung;
d) ob sie in ihrer Betriebsumgebung ausnutzbar ist oder nicht (d. h. ausnutzbar oder Restanfälligkeit).
e) den Zeitaufwand, den Grad der Fachkenntnis, den Kenntnisstand über den TOE, den Grad der
Möglichkeiten und die Ausrüstung, die zur Durchführung der identifizierten Anfälligkeiten erforderlich
sind, sowie die entsprechenden Werte unter Verwendung der Tabelle B.2 „Berechnung des Angriffs-
potentials“ und Tabelle B.3 „Bewertung von Anfälligkeiten und TOE Beständigkeit“ in B.4.
Anfälligkeiten aufweist, die von Angreifern mit einem Angriffspotential Basic ausgenutzt werden können.
14.2.2.2 Eingaben
a) die ST,
c) das TOE-Design,
e) die Leitliniendokumentation,
f) der zum Prüfen geeignete TOE,
g) öffentlich zugängliche Informationen zur Unterstützung der Identifizierung möglicher potentieller
Anfälligkeiten.
248
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der verbleibende implizite Evaluationsnachweis für diese Unteraufgabe hängt von den Komponenten ab, die
in das Sicherheitspaket aufgenommen wurden. Die für jede Komponente vorgelegten Nachweise sollen als
Eingabe in dieser Unteraufgabe verwendet werden.
a) aktuelle Informationen über potentielle Anfälligkeiten und Angriffe im öffentlichen Bereich (z. B. von
einer Evaluierungsinstanz).
Der Evaluator sollte die Durchführung zusätzlicher Prüfungen in Betracht ziehen, wenn er in anderen Teilen
der Evaluierung auf potentielle Anfälligkeiten stößt.
249
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

die der Evaluator in Betracht ziehen sollte mittels Themen wie z. B. denen im World Wide Web verfügbaren,
einschließlich
a) Fachveröffentlichungen (Zeitschriften, Bücher);
b) Forschungsarbeiten.
beitragen, Angriffe zu identifizieren und zu erleichtern, kann das Angriffspotential eines bestimmten
Angreifers erheblich steigern. Die Zugänglichkeit von Anfälligkeitsinformationen und ausgeklügelten
Angriffstools im Internet macht es wahrscheinlicher, dass diese Informationen bei Versuchen, potentielle
Anfälligkeiten im TOE zu identifizieren und auszunutzen, verwendet werden. Moderne Suchtools machen
solche Informationen für den Evaluator leicht zugänglich, und die Bestimmung der Beständigkeit gegen
veröffentlichte potentielle Anfälligkeiten und bekannte generische Angriffe kann auf kosteneffiziente Weise
erreicht werden.
Die Suche nach den öffentlich verfügbaren Informationen sollte sich auf diejenigen Quellen konzentrieren, die
sich speziell auf das Produkt beziehen, von dem der TOE abgeleitet ist. Die Ausführlichkeit dieser Suche sollte
die folgenden Faktoren berücksichtigen: TOE-Typ, Erfahrung des Evaluators mit diesem TOE-Typ, erwartetes
Angriffspotential und die Ebene der verfügbaren ADV-Nachweise.
Der Evaluator wird berichten, welche Aktionen ergriffen wurden, um potentielle Anfälligkeiten im Nachweis
zu identifizieren. Bei dieser Art von Suche ist der Evaluator jedoch möglicherweise nicht in der Lage, die
Schritte zur Identifizierung potentieller Anfälligkeiten vor Beginn der Untersuchung zu beschreiben, da sich
der Ansatz aufgrund der Ergebnisse bei der Suche weiterentwickeln kann.
Der Evaluator wird über die Nachweise berichten, die bei der Suche nach potentiellen Anfälligkeiten unter-
sucht wurden. Diese Auswahl von Nachweisen kann aus den vom Evaluator identifizierten Problemfeldern
abgeleitet werden, die mit den Nachweisen verbunden sind, von denen angenommen wird, dass der Angreifer
in der Lage ist, sie zu erhalten, oder nach einer anderen vom Evaluator gelieferten Begründung.
250
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss eine Suche nach den Nachweisen für die ST, Leitliniendokumentation, Funktions-
spezifikation, das TOE-Design und die Beschreibung der Sicherheitsarchitektur durchführen, um mögliche
potentielle Anfälligkeiten im TOE zu ermitteln.
Es sollte eine Suche nach den Nachweisen abgeschlossen werden, wobei die Spezifikationen und die
Dokumentation des TOEs analysiert und dann Hypothesen oder Vermutungen über potentielle Anfälligkeiten
im TOE aufgestellt werden. Die Liste der hypothetischen potentiellen Anfälligkeiten wird dann auf der
Grundlage der geschätzten Wahrscheinlichkeit, dass eine potentielle Anfälligkeit vorhanden ist, und – unter
der Annahme, dass eine ausnutzbare Anfälligkeit vorhanden ist – des Angriffspotentials, das zu ihrer
Ausnutzung erforderlich ist, sowie des Umfangs der Kontrolle oder Gefährdung, den sie vorsehen würde, nach
Priorität geordnet. Die priorisierte Liste potentieller Anfälligkeiten wird für direkte Penetrationstests gegen
den TOE verwendet.
Die Beschreibung der Sicherheitsarchitektur bietet dem Entwickler eine Anfälligkeitsanalyse, da sie
dokumentiert, wie die TSF sich vor Störungen durch nicht vertrauenswürdige Subjekte schützt und die
Umgehung der sicherheitsdurchsetzenden Funktionen verhindert. Daher sollte der Evaluator diese
Beschreibung des Schutzes der TSF als Grundlage für die Suche nach möglichen Wegen zur Untergrabung der
TSF verwenden.
Vorbehaltlich der SFRs, die der TOE in der Betriebsumgebung erfüllen soll, sollte die unabhängige
Anfälligkeitsanalyse des Evaluators generische potentielle Anfälligkeiten unter jeder der folgenden
Überschriften berücksichtigen:
a) generische potentielle Anfälligkeiten, die für den Typ des zu evaluierenden TOEs relevant sind, wie sie
von der Evaluierungsinstanz geliefert werden können;
b) Umgehen;
c) Eingriffe;
d) direkte Angriffe;
e) Überwachung;
f) Fehlbenutzung.
Die Punkte b) bis f) werden in Anhang B ausführlicher erläutert.
Die Beschreibung der Sicherheitsarchitektur sollte im Lichte jeder der oben genannten generischen
potentiellen Anfälligkeiten betrachtet werden. Jede potentielle Anfälligkeit sollte in Betracht gezogen werden,
um nach möglichen Wegen zu suchen, wie der Schutz der TSF aufgehoben und die TSF untergraben werden
kann.
251
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
gemeldet werden.
Der Evaluator wird daran erinnert, dass zur Berücksichtigung der Beschreibung der Sicherheitsarchitektur
bei der Suche nach Anfälligkeiten (wie in AVA_VAN.2-4 detailliert beschrieben) Prüfungen durchgeführt
werden sollten, um die Architektureigenschaften zu bestätigen. Dies wird wahrscheinlich negative Prüfungen
erfordern, die versuchen, die Eigenschaften der Sicherheitsarchitektur zu widerlegen. Bei der Entwicklung der
Strategie für Penetrationstests stellt der Evaluator sicher, dass jedes der Hauptmerkmale der Beschreibung
der Sicherheitsarchitektur geprüft wird, entweder in Funktionsprüfungen (wie in Abschnitt 13) oder in
Penetrationstests des Evaluators.
bestimmt werden kann. Entdeckt der Evaluator als Ergebnis des Evaluierungsgutachtens eine ausnutzbare
Leitlinien zur Bestimmung des notwendigen Angriffspotentials zur Ausnutzung einer potentiellen Anfälligkeit
finden sich in B.4.
Potentielle Anfälligkeiten, über die Hypothesen aufgestellt werden, dass sie nur von Angreifern ausgenutzt
werden können, die über ein Angriffspotential Basic, Enhanced-Basic, Moderate oder High verfügen, führen
nicht zu einem Scheitern dieser Evaluatorenaktion. Wenn die Analyse die Hypothese unterstützt, müssen diese
nicht weiter als Eingabe für Penetrationstests betrachtet werden. Solche Anfälligkeiten werden jedoch im ETR
als Restanfälligkeiten gemeldet.
Potentielle Anfälligkeiten, über die Hypothesen aufgestellt werden, dass sie von einem Angreifer mit einem
Angriffspotential Basic ausnutzbar sind und zu einer Verletzung der Sicherheitszielsetzungen führen, sollten
die potentiellen Anfälligkeiten mit der höchsten Priorität sein, die die Liste umfasst, die für direkte
Penetrationstests gegen den TOE verwendet wird.
252
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
bei der Suche im öffentlichen Bereich sowie der Analyse der Evaluationsnachweise identifiziert wurden.
über diejenigen hinausgehen, für die ein Angriffspotential Basic zur Durchführung eines Angriffs erforderlich
sind. Als Ergebnis des Evaluierungsgutachtens kann der Evaluator jedoch eine potentielle Anfälligkeit
entdecken, die nur von einem Angreifer mit einem größeren als dem Angriffspotential Basic ausgenutzt
werden kann. Solche Anfälligkeiten sind im ETR als Restanfälligkeiten zu melden.
a) die TSFI oder eine andere Schnittstelle des TOEs, die zur Stimulierung der TSF und zur Beobachtung der
Antworten verwendet wird (es ist möglich, dass der Evaluator eine andere Schnittstelle zum TOE als die
TSFI verwenden muss, um Eigenschaften der TSF, wie sie in der Beschreibung der Sicherheitsarchitektur
beschrieben sind, nachzuweisen (wie von ADV_ARC gefordert). Es sollte darauf hingewiesen werden, dass
diese TOE-Schnittstellen zwar ein Mittel zum Prüfen der TSF-Eigenschaften bieten, aber nicht Gegenstand
der Prüfung sind);
Anfälligkeit auszunutzen, wenn von einem Angriffspotential Basic ausgegangen wird);
die Möglichkeit zu geben, die Prüfungen zu wiederholen und ein gleichwertiges Ergebnis zu erhalten.
253
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Sollten Penetrationstests zeigen, dass eine hypothetische potentielle Anfälligkeit nicht existiert, dann sollte
der Evaluator feststellen, ob die eigene Analyse des Evaluators falsch war oder nicht oder ob die
Evaluationsbeiträge falsch oder unvollständig sind.
den Umfang der durchgeführten Penetrationstests, die Prüfkonfigurationen des TOEs und die Gesamt-
ergebnisse der Penetrationstestaufgabe zu ermöglichen.
254
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
seiner Betriebsumgebung gegen einen Angreifer mit einem Angriffspotential Basic resistent ist.
Angreifer mit weniger als dem Angriffspotential Enhanced-Basic ausgenutzt werden können, dann schlägt
diese Evaluatorenaktion fehl.
Angriffspotential als Enhanced-Basic ausgenutzt werden kann oder nicht.
d) ob sie in ihrer Betriebsumgebung ausnutzbar ist oder nicht (d. h. ausnutzbar oder Restanfälligkeit);
e) den Zeitaufwand, den Grad der Fachkenntnis, den Kenntnisstand über den TOE, den Grad der
sind, sowie die entsprechenden Werte unter Verwendung der Tabelle B.2 und Tabelle B.3 in B.4.
Anfälligkeiten aufweist, die von Angreifern mit einem Angriffspotential Enhanced-Basic ausgenutzt werden
können.
14.2.3.2 Eingaben
a) die ST,
c) das TOE-Design,
255
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
e) die ausgewählte Implementierungsteilmenge,
f) die Leitliniendokumentation,
g) der zum Prüfen geeignete TOE,
h) öffentlich zugängliche Informationen zur Unterstützung der Identifizierung möglicher potentieller

Anfälligkeiten,
i) die Ergebnisse der Prüfung des Grunddesigns.
Während der Durchführung von Evaluierungsaufgaben kann der Evaluator auch Problemfelder identifizieren.
Dabei handelt es sich um spezifische Teile des TOEs-Nachweises, gegen die der Evaluator einige Vorbehalte
hat, obwohl der Nachweis die Anforderungen für die Aufgabe erfüllt, mit der der Nachweis verbunden ist.
Beispielsweise sieht eine bestimmte Schnittstellenspezifikation besonders komplex aus und kann daher
entweder bei der Entwicklung des TOEs oder beim Betrieb des TOEs fehleranfällig sein. In diesem Stadium ist
keine potentielle Anfälligkeit erkennbar, weitere Untersuchungen sind erforderlich. Dies geht über den
Rahmen des Aufgetretenen hinaus, da weitere Untersuchungen erforderlich sind.
Der fokussierte Ansatz zur Identifizierung potentieller Anfälligkeiten ist eine Analyse der Nachweise mit dem
Ziel, alle potentiellen Anfälligkeiten zu identifizieren, die sich aus den enthaltenen Informationen ergeben. Es
handelt sich um eine unstrukturierte Analyse, da der Ansatz nicht vorgegeben ist. Weitere Leitlinien zur
gezielten Anfälligkeitsanalyse finden sich in B.2.2.2.2.
256
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

einschließlich
a) Fachveröffentlichungen (Zeitschriften, Bücher);

b) Forschungsarbeiten;
c) Konferenzberichte.
erreicht werden.
Die Suche nach den öffentlich verfügbaren Informationen sollte sich auf jene Quellen konzentrieren, die sich
auf die Technologien beziehen, die bei der Entwicklung des Produkts, von dem der TOE abgeleitet ist,
verwendet werden. Die Ausführlichkeit dieser Suche sollte die folgenden Faktoren berücksichtigen: TOE-Typ,
Erfahrung des Evaluators mit diesem TOE-Typ, erwartetes Angriffspotential und die Ebene der verfügbaren
ADV-Nachweise.
257
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
untersucht wurden. Diese Auswahl von Nachweisen kann aus den vom Evaluator identifizierten
Problemfeldern abgeleitet werden, die mit den Nachweisen verbunden sind, von denen angenommen wird,
dass der Angreifer in der Lage ist, sie zu erhalten, oder nach einer anderen vom Evaluator gelieferten
Begründung.
Der Evaluator muss eine gezielte Suche nach der ST, der Leitliniendokumentation, Funktionsspezifikation,
dem TOE-Design, der Beschreibung der Sicherheitsarchitektur und Darstellung der Implementierung
durchführen, um mögliche potentielle Anfälligkeiten im TOE zu ermitteln.
Es muss eine Methodik zur Aufstellung von Mängelhypothesen verwendet werden, bei der die Spezifikationen
und die Nachweise für die Entwicklung und Leitlinien analysiert werden und dann Hypothesen oder
Vermutungen über potentielle Anfälligkeiten im TOE aufgestellt werden.
Der Evaluator verwendet die aus den Evaluationsbeiträgen des TOEs gewonnenen Kenntnisse über das Design
und den Betrieb des TOEs, um eine Mängelhypothese aufzustellen, um potentielle Mängel bei der Entwicklung
des TOEs und potentielle Fehler in der spezifizierten Betriebsweise des TOEs zu identifizieren.
Umgehung der sicherheitsdurchsetzenden Funktionen verhindert. Daher sollte der Evaluator auf dem
Verständnis des TSF-Schutzes aufbauen, das er aus der Analyse dieser Nachweise gewonnen hat, und dieses
dann mit den Erkenntnissen aus anderen Entwicklungs-ADV-Nachweisen weiterentwickeln.
Die Vorgehensweise richtet sich nach den Problemfeldern, die bei der Untersuchung der Nachweise während
der Durchführung der Evaluierungsaufgaben identifiziert wurden, und stellt sicher, dass eine repräsentative
Stichprobe der für die Evaluierung bereitgestellten Nachweise für die Entwicklung und Leitlinien recherchiert
wird.
Zur Anleitung von Probenahmen siehe A.2. Diese Anleitung sollte bei der Auswahl der Teilmenge unter Angabe
von Gründen für Folgendes berücksichtigt werden:
a) den bei der Auswahl verwendeten Ansatz;
b) die Qualifikation, dass die zu untersuchenden Nachweise diesen Ansatz unterstützen.
Die Problemfelder können sich auf die Angemessenheit spezifischer Schutzmerkmale beziehen, die in der
Beschreibung der Sicherheitsarchitektur detailliert aufgeführt sind.
Die bei der Anfälligkeitsanalyse zu berücksichtigenden Nachweise können mit den Nachweisen verknüpft
werden, von denen angenommen wird, dass der Angreifer in der Lage ist, sie zu erlangen. Beispielsweise kann
der Entwickler die Darstellungen des TOEs-Designs und der Implementierung schützen, so dass die einzigen
Informationen, von denen angenommen wird, dass sie einem Angreifer zur Verfügung stehen, die
Funktionsspezifikation und die Anleitung (öffentlich verfügbar) sind. Obwohl also die Zielsetzungen für die
Vertrauenswürdigkeit im TOE sicherstellen, dass die Anforderungen an das TOE-Design und die Darstellung
der Implementierung erfüllt werden, dürfen diese Designdarstellungen nur recherchiert werden, um
Problemfelder weiter zu untersuchen.
258
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Wenn andererseits die Quelle öffentlich zugänglich ist, wäre es logisch anzunehmen, dass der Angreifer
Zugang zu der Quelle hat und diese bei Versuchen, den TOE anzugreifen, nutzen kann. Daher sollte die Quelle
im Rahmen des fokussierten Untersuchungsansatzes berücksichtigt werden.
Im Folgenden sind Beispiele für die Auswahl der zu berücksichtigenden Teilmenge von Nachweisen
aufgeführt.
a) Für eine Evaluierung, bei der alle Ebenen der Designabstraktion von der Funktionsspezifikation bis zur
Darstellung der Implementierung bereitgestellt werden, kann die Untersuchung der Informationen in der
Funktionsspezifikation und der Darstellung der Implementierung gewählt werden, da die
Funktionsspezifikation Einzelheiten über die einem Angreifer zur Verfügung stehenden Schnittstellen
enthält und die Darstellung der Implementierung die auf allen anderen Designabstraktionen getroffenen
Designentscheidungen einbezieht. Daher werden die Informationen über das TOE-Design als Teil der
Darstellung der Implementierung betrachtet.
b) Untersuchung einer bestimmten Teilmenge von Informationen in jeder der für die Evaluierung
vorgesehenen Designdarstellungen.
c) Abdeckung bestimmter SFRs durch jede der für die Evaluierung vorgesehenen Designdarstellungen.
d) Untersuchung jeder der für die Evaluierung vorgesehenen Designdarstellungen unter Berücksichtigung
der unterschiedlichen SFRs innerhalb jeder Designdarstellung.
e) Untersuchung von Aspekten der für die Evaluierung vorgelegten Nachweise, die sich auf aktuelle
potentielle Anfälligkeitsinformationen beziehen, die der Evaluator erhalten hat (z. B. aus einem Schema).
Dieser Ansatz zur Identifizierung potentieller Anfälligkeiten besteht darin, einen geordneten und geplanten
Ansatz zu wählen und bei der Untersuchung ein System anzuwenden. Der Evaluator muss das zu verwendende
Verfahren in Bezug auf die zu berücksichtigenden Nachweise, die zu untersuchenden Informationen innerhalb
der Nachweise, die Art und Weise, in der diese Informationen berücksichtigt werden sollen, und die zu
erstellende Hypothese beschreiben.
Im Folgenden werden einige Beispiele aufgeführt, die eine Hypothese aufstellen kann:
a) Berücksichtigung von fehlerhafter Eingabe für Schnittstellen, die einem Angreifer an den externen
Schnittstellen zur Verfügung stehen;
b) Untersuchung eines wichtigen Sicherheitsmechanismus, der in der Beschreibung der Sicherheits-

architektur genannt wird, wie z. B. die Prozesstrennung, wobei die Hypothese interner Pufferüberläufe
aufgestellt wird, die zu einer Verschlechterung der Trennung führen können;
c) Recherche, um alle Objekte zu identifizieren, die in der Darstellung der TOE-Implementierung erstellt
wurden, die dann nicht vollständig von der TSF kontrolliert werden und von einem Angreifer zur
Untergrabung der SFRs verwendet werden könnten.
Der Evaluator kann z. B. feststellen, dass Schnittstellen ein potentieller Schwachpunkt des TOEs sind, und
einen Ansatz für die Suche festlegen, dass „alle in der Funktionsspezifikation und im TOE-Design enthaltenen
Schnittstellenspezifikationen durchsucht werden, um Hypothesen über potentielle Anfälligkeiten
aufzustellen“, und dann die in der Hypothese verwendeten Verfahren erläutern.
259
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
untersucht wurden. Diese Auswahl von Nachweisen kann aus den vom Evaluator identifizierten
Problemfeldern abgeleitet werden, die mit den Nachweisen verbunden sind, von denen angenommen wird,
dass der Angreifer in der Lage ist, sie zu erhalten, oder nach einer anderen vom Evaluator gelieferten
Begründung.
b) Umgehen;
c) Eingriffe;
e) Überwachung;
f) Fehlbenutzung.
Die Punkte b) bis f) werden ausführlicher erläutert in Anhang B.
kann.
gemeldet werden.
260
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
werden sollten, um die Architektureigenschaften zu bestätigen. Wenn Anforderungen aus ATE_DPT in den
SARs enthalten sind, schließt der Nachweis der Entwickler-Prüfungen Prüfungen ein, die durchgeführt
werden, um die korrekte Implementierung der in der Beschreibung der Sicherheitsarchitektur ausführlichen
spezifischen Mechanismen zu bestätigen. Die Prüfungen des Entwicklers werden jedoch nicht
notwendigerweise das Prüfen aller Aspekte der architektonischen Eigenschaften, die die TSF schützen,
beinhalten, da ein Großteil dieser Prüfungen negativer Natur sein wird und versucht, die Eigenschaften zu
widerlegen. Bei der Entwicklung der Strategie für Penetrationstests stellt der Evaluator sicher, dass alle
Aspekte der Beschreibung der Sicherheitsarchitektur geprüft werden, entweder in Funktionsprüfungen (wie
in Abschnitt 13 berücksichtigt) oder in Penetrationstests des Evaluators.
Es wird wahrscheinlich praktisch sein, Penetrationstests anhand einer Reihe von Prüffällen durchzuführen,
wobei jeder Prüffall auf eine bestimmte potentielle Anfälligkeit hin geprüft wird.
öffentlichen Bereich) prüft, die über diejenigen hinausgehen, die ein Angriffspotential Enhanced-Basic
erfordern. In einigen Fällen wird es jedoch notwendig sein, eine Prüfung durchzuführen, bevor die
Ausnutzbarkeit bestimmt werden kann. Entdeckt der Evaluator als Ergebnis des Evaluierungsgutachtens eine
ausnutzbare Anfälligkeit, die über das Angriffspotential Enhanced-Basic hinausgeht, wird dies im ETR als
Restanfälligkeit gemeldet.
finden sich in B.4.
Potentielle Anfälligkeiten, über die Hypothesen aufgestellt werden, dass sie nur von Angreifern ausgenutzt
werden können, die über ein Angriffspotential Moderate oder High verfügen, führen nicht zu einem Scheitern
dieser Evaluatorenaktion. Wenn die Analyse die Hypothese unterstützt, müssen diese nicht weiter als Eingabe
für Penetrationstests betrachtet werden. Solche Anfälligkeiten werden jedoch im ETR als Restanfälligkeiten
gemeldet.
Angriffspotential Basic oder Enhanced-Basic ausnutzbar sind und zu einer Verletzung der
Sicherheitszielsetzungen führen, sollten die potentiellen Anfälligkeiten mit der höchsten Priorität sein, die die
Liste umfasst, die für direkte Penetrationstests gegen den TOE verwendet wird.
261
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
über diejenigen hinausgehen, für die ein Angriffspotential Enhanced-Basic zur Durchführung eines Angriffs
erforderlich ist. Als Ergebnis des Evaluierungsgutachtens kann der Evaluator jedoch eine potentielle
Anfälligkeit entdecken, die nur von einem Angreifer mit einem größeren als dem Angriffspotential Enhanced-
Basic ausgenutzt werden kann. Solche Anfälligkeiten sind im ETR als Restanfälligkeiten zu melden.
beschrieben sind, nachzuweisen (wie von ADV_ARC gefordert)). Es sollte darauf hingewiesen werden,
dass diese TOE-Schnittstellen zwar ein Mittel zum Prüfen der TSF-Eigenschaften bieten, aber nicht
Gegenstand der Prüfung sind);
Anfälligkeit auszunutzen, wenn von einem Angriffspotential Enhanced-Basic ausgegangen wird);
262
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
der Evaluator feststellen, ob die eigene Analyse des Evaluators falsch war oder nicht oder ob die
Evaluationsbeiträge falsch oder unvollständig sind.
öffentlichen Bereich) prüft, die über diejenigen hinausgehen, die ein Angriffspotential Enhanced-Basic
erfordern. In einigen Fällen wird es jedoch notwendig sein, eine Prüfung durchzuführen, bevor die
Ausnutzbarkeit bestimmt werden kann. Entdeckt der Evaluator als Ergebnis des Evaluierungsgutachtens eine
ausnutzbare Anfälligkeit, die über das Angriffspotential Enhanced-Basic hinausgeht, wird dies im ETR als
Restanfälligkeit gemeldet.
den Umfang der durchgeführten Penetrationstests, die Prüfkonfigurationen des TOEs und die
Gesamtergebnisse der Penetrationstestaufgabe zu ermöglichen.
263
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
seiner Betriebsumgebung gegen einen Angreifer mit einem Angriffspotential Enhanced-Basic resistent ist.
Angreifer mit weniger als dem Angriffspotential Moderate ausgenutzt werden können, dann schlägt diese
Evaluatorenaktion fehl.
Angriffspotential als Moderate ausgenutzt werden kann oder nicht.
e) den Zeitaufwand, den Grad der Fachkenntnis, den Kenntnisstand über den EVG, den Grad der
Anfälligkeiten aufweist, die von Angreifern mit einem Angriffspotential Moderate ausgenutzt werden können.
14.2.4.2 Eingaben
a) die ST,
c) das TOE-Design,
e) die Darstellung der Implementierung,
264
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
f) die Leitliniendokumentation,
g) der zum Prüfen geeignete TOE,
h) öffentlich zugängliche Informationen zur Unterstützung der Identifizierung möglicher potentieller

Anfälligkeiten,
i) die Ergebnisse der Prüfung des Grunddesigns.
Der methodische Analyseansatz erfolgt in Form einer strukturierten Untersuchung der Nachweise. Bei diesem
Verfahren muss der Evaluator die Struktur und Form der Analyse festlegen (d. h. die Art und Weise, in der die
Analyse durchgeführt wird, ist im Gegensatz zur gezielten Analyse vorgegeben). Das Verfahren wird in Bezug
auf die zu berücksichtigenden Informationen und das Wie/Warum der Berücksichtigung festgelegt. Weitere
Leitlinien zur methodischen Anfälligkeitsanalyse finden sich in B.2.2.2.3.
265
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

einschließlich
a) Fachveröffentlichungen (Zeitschriften, Bücher),
b) Forschungsarbeiten,
c) Konferenzberichte.
erreicht werden.
Die Suche nach den öffentlich verfügbaren Informationen sollte sich auf jene Quellen konzentrieren, die sich
auf die Technologien beziehen, die bei der Entwicklung des Produkts, von dem der TOE abgeleitet ist,
verwendet werden. Die Ausführlichkeit dieser Suche sollte die folgenden Faktoren berücksichtigen: TOE-Typ,
Erfahrung des Evaluators mit diesem TOE-Typ, erwartetes Angriffspotential und die Ebene der verfügbaren
ADV-Nachweise.
266
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator beschreibt den Ansatz, der zur Identifizierung potentieller Anfälligkeiten in dem öffentlich
zugänglichen Material zu verfolgen ist, wobei die durchzuführende Suche detailliert beschrieben wird. Dies
kann durch Faktoren wie die vom Evaluator identifizierten Problemfelder in Verbindung mit den Nachweisen,
von denen angenommen wird, dass der Angreifer in der Lage ist, sie zu erlangen, beeinflusst werden. Es wird
jedoch anerkannt, dass sich die Vorgehensweise bei dieser Art der Suche aufgrund der Ergebnisse der Suche
weiter entwickeln kann. Daher wird der Evaluator auch über alle Aktionen berichten, die zusätzlich zu den im
Ansatz beschriebenen Aktionen ergriffen wurden, um Fragen weiter zu untersuchen, von denen angenommen
wird, dass sie zu potentiellen Anfälligkeiten führen, und er wird über die Nachweise berichten, die bei der
Suche nach potentiellen Anfälligkeiten untersucht wurden.
Der Evaluator muss eine methodische Analyse der ST, der Leitliniendokumentation, Funktionsspezifikation,
dem TOE-Design, der Beschreibung der Sicherheitsarchitektur und Darstellung der Implementierung
durchführen, um mögliche potentielle Anfälligkeiten im TOE zu ermitteln.
Leitlinien zur methodischen Anfälligkeitsanalyse finden sich in B.2.2.2.3.
Ansatz zu wählen. Bei der Untersuchung ist ein System anzuwenden. Der Evaluator soll das zu verwendende
Verfahren in Bezug auf die Art und Weise, in der diese Informationen berücksichtigt werden sollen, und die
zu erstellende Hypothese beschreiben.
Es muss eine Methodik zur Aufstellung von Mängelhypothesen verwendet werden, bei der die ST, die
Entwicklung (Funktionsspezifikation, TOE-Design und Darstellung der Implementierung) und der Nachweis
von Leitlinien analysiert und dann Hypothesen oder Vermutungen über Anfälligkeiten im TOE aufgestellt
werden.
Der Evaluator verwendet die aus den Evaluationsbeiträgen des TOEs gewonnenen Kenntnisse über das Design
und den Betrieb des TOEs, um eine Mängelhypothese aufzustellen, um potentielle Mängel bei der Entwicklung
des TOEs und potentielle Fehler in der spezifizierten Betriebsweise des TOEs zu identifizieren.
Umgehung der sicherheitsdurchsetzenden Funktionen verhindert. Daher sollte der Evaluator auf dem
Verständnis des TSF-Schutzes aufbauen, das er aus der Analyse dieser Nachweise gewonnen hat, und dieses
dann mit den Erkenntnissen aus anderen Entwicklungs-ADV-Nachweisen weiterentwickeln.
Der Ansatz für die methodische Suche nach Anfälligkeiten besteht darin, alle Problemfelder zu
berücksichtigen, die in den Ergebnissen der Beurteilung der Nachweise für die Entwicklung und Leitlinien
durch den Evaluator identifiziert wurden. Der Evaluator sollte jedoch auch jeden Aspekt der Analyse der
Sicherheitsarchitektur berücksichtigen, um nach Möglichkeiten zu suchen, wie der Schutz der TSF
untergraben werden kann. Es kann hilfreich sein, die methodische Analyse auf der Grundlage des in der
Beschreibung der Sicherheitsarchitektur dargestellten Materials zu strukturieren und gegebenenfalls
Bedenken aus anderen ADV-Nachweisen einzubringen. Die Analyse kann dann weiterentwickelt werden, um
sicherzustellen, dass alles andere Material aus dem ADV-Nachweis berücksichtigt wird.
Im Folgenden sind einige Beispiele enthalten für Hypothesen, die bei der Untersuchung der Nachweise
aufgestellt werden können:
267
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
b) Untersuchung eines wichtigen Sicherheitsmechanismus, der in der Beschreibung der Sicherheits-

architektur genannt wird, wie z. B. die Prozesstrennung, wobei die Hypothese interner Pufferüberläufe
aufgestellt wird, die zu einer Verschlechterung der Trennung führen können;
c) Recherche, um alle Objekte zu identifizieren, die in der Darstellung der TOE-Implementierung erstellt
einen Ansatz für die Suche festlegen, dass „alle Schnittstellenspezifikationen in den vorgelegten Nachweisen
durchsucht werden, um Hypothesen über potentielle Anfälligkeiten aufzustellen“, und dann die in der
Hypothese verwendeten Verfahren erläutern.
Darüber hinaus hat der Evaluator bei der Untersuchung der Nachweise im Rahmen der Durchführung von
Evaluierungsaufgaben Problemfelder identifiziert. Problemfelder können auch bei der Durchführung anderer
Workunits, die mit dieser Komponente, insbesondere AVA_VAN.4-7, AVA_VAN.4-5 und AVA_VAN.4-6
verbunden sind, identifiziert werden, und bei der Entwicklung und Durchführung von Penetrationstests
können weitere Problemfelder für eine Untersuchung oder potentielle Anfälligkeiten ermittelt werden.
Allerdings ist die Untersuchung nur einer Teilmenge der Nachweise für die Entwicklung und Leitlinien oder
deren Inhalt in dieser Stufe der Stringenz nicht zulässig. Die Beschreibung der Herangehensweise sollte die
Vorführung enthalten, dass der verwendete methodische Ansatz vollständig ist, und die Gewissheit vermitteln,
dass der für die Suche nach den Ergebnissen verwendete Ansatz alle in diesen Ergebnissen enthaltenen
Informationen berücksichtigt hat.
Ansatz zu wählen und bei der Untersuchung ein System anzuwenden. Der Evaluator soll das zu verwendende
Verfahren in Bezug darauf, wie die Nachweise berücksichtigt werden; auf die Art und Weise, in der diese
Informationen berücksichtigt werden sollen, und die zu erstellende Hypothese beschreiben. Dieser Ansatz
sollte mit der Evaluierungsinstanz vereinbart werden, und die Evaluierungsinstanz kann nähere Angaben zu
allen zusätzlichen Ansätzen machen, die der Evaluator bei der Anfälligkeitsanalyse verfolgen sollte, und alle
zusätzlichen Informationen angeben, die vom Evaluator berücksichtigt werden sollten.
Obwohl ein System zur Identifizierung potentieller Anfälligkeiten vordefiniert ist, kann der Identifizierungs-
prozess dennoch iterativ sein, wobei die Identifizierung einer potentiellen Anfälligkeit zur Identifizierung
eines anderen Problembereichs führen kann, der weiterer Untersuchungen bedarf.
b) Umgehen;
c) Eingriffe;
e) Überwachung;
f) Fehlbenutzung.
Die Punkte b) bis f) werden ausführlicher erläutert in Anhang B.
268
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
kann.
gemeldet werden.
werden sollten, um die Architektureigenschaften zu bestätigen. Wenn Anforderungen aus ATE_DPT in den
SARs enthalten sind, schließt der Nachweis der Entwickler-Prüfungen Prüfungen ein, die durchgeführt
werden, um die korrekte Implementierung der in der Beschreibung der Sicherheitsarchitektur ausführlichen
spezifischen Mechanismen zu bestätigen. Die Prüfungen des Entwicklers werden jedoch nicht
notwendigerweise das Prüfen aller Aspekte der architektonischen Eigenschaften, die die TSF schützen,
beinhalten, da ein Großteil dieser Prüfungen negativer Natur sein wird und versucht, die Eigenschaften zu
widerlegen. Bei der Entwicklung der Strategie für Penetrationstests stellt der Evaluator sicher, dass alle
Aspekte der Beschreibung der Sicherheitsarchitektur geprüft werden, entweder in Funktionsprüfungen (wie
in Abschnitt 13 berücksichtigt) oder in Penetrationstests des Evaluators.
öffentlichen Bereich) prüft, die über diejenigen hinausgehen, die ein Angriffspotential Moderate erfordern. In
Anfälligkeit, die über das Angriffspotential Moderate hinausgeht, wird dies im ETR als Restanfälligkeit
gemeldet.
269
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
finden sich in B.4.
Angriffspotential Moderate (oder weniger) ausnutzbar sind und zu einer Verletzung der Sicherheits-
zielsetzungen führen, sollten die potentiellen Anfälligkeiten mit der höchsten Priorität sein, die die Liste
umfasst, die für direkte Penetrationstests gegen den TOE verwendet wird.
über diejenigen hinausgehen, für die ein Angriffspotential Moderate zur Durchführung eines Angriffs
erforderlich ist. Als Ergebnis des Evaluierungsgutachtens kann der Evaluator jedoch eine potentielle
Anfälligkeit entdecken, die nur von einem Angreifer mit einem größeren als dem Angriffspotential Moderate
ausgenutzt werden kann. Solche Anfälligkeiten sind im ETR als Restanfälligkeiten zu melden.
beschrieben sind, nachzuweisen (wie von ADV_ARC gefordert)). Es sollte darauf hingewiesen werden,
dass diese TOE-Schnittstellen zwar ein Mittel zum Prüfen der TSF-Eigenschaften bieten, aber nicht
Gegenstand der Prüfung sind),
die vorliegen müssen, und Sicherheitseigenschaften, die sie haben müssen),
c) spezielle Prüfgeräte, die entweder zur Stimulation einer TSFI oder zur Beobachtung einer TSFI benötigt
werden,
270
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
der Evaluator feststellen, ob die eigene Analyse des Evaluators falsch war oder nicht oder ob die Evaluations-
beiträge falsch oder unvollständig sind.
öffentlichen Bereich) prüft, die über diejenigen hinausgehen, die ein Angriffspotential Moderate erfordern. In
Anfälligkeit, die über das Angriffspotential Moderate hinausgeht, wird dies im ETR als Restanfälligkeit
gemeldet.
den Umfang der durchgeführten Penetrationstests, die Prüfkonfigurationen des TOEs und die
Gesamtergebnisse der Penetrationstestaufgabe zu ermöglichen.
271
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
seiner Betriebsumgebung gegen einen Angreifer mit einem Angriffspotential Moderate resistent ist.
Angreifer mit weniger als einem Angriffspotential High ausgenutzt werden können, dann schlägt diese
Evaluatorenaktion fehl.
Angriffspotential als High ausgenutzt werden kann oder nicht.
e) den Zeitaufwand, den Grad der Fachkenntnis, den Kenntnisstand über den EVG, den Grad der
272
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
15 Klasse ACO: Zusammensetzung
15.1 Einleitung
Ziel dieser Aufgabe ist es, festzustellen, ob die Komponenten auf sichere Weise integriert werden können, wie
in der ST für den zusammengesetzten TOE definiert. Dies wird durch die Untersuchung und Prüfung der
Schnittstellen zwischen den Komponenten erreicht, unterstützt durch die Untersuchung des Designs der
Komponenten und die Durchführung von Anfälligkeitsanalysen.
Die Familie „Reliance of dependent component“ (ACO_REL) identifiziert, wo die abhängige Komponente in
ihrer Betriebsumgebung auf die IT angewiesen ist (die durch eine Basiskomponente in der
zusammengesetzten TOE-Evaluierung erfüllt wird), um ihre eigenen Sicherheitsdienste bereitzustellen. Diese
Verlässlichkeit wird im Hinblick auf die von der abhängigen Komponente erwarteten Schnittstellen
identifiziert, die von der Basiskomponente bereitgestellt werden sollen. „Development evidence“ (ACO_DEV)
bestimmen dann, welche Schnittstellen der Basiskomponente (als TSFI) bei der Komponentenevaluierung der
Basiskomponente berücksichtigt wurden.
Es sollte beachtet werden, dass „Reliance of dependent component“ (ACO_REL) keine anderen Nachweise
abdeckt, die zur Lösung des technischen Integrationsproblems bei der Zusammensetzung von Komponenten
erforderlich sein könnten (z. B. Beschreibungen von Nicht-TSF-Schnittstellen des Betriebssystems, Regeln für
die Integration usw.). Dies liegt außerhalb der Sicherheitsbeurteilung der Zusammensetzung und ist eine
Frage der funktionalen Zusammensetzung.
Als Teil der „Composed TOE testing“ (ACO_CTT) führt der Evaluator Prüfungen der zusammengesetzten
TOE-SFRs an den Schnittstellen des zusammengesetzten TOEs und den Schnittstellen der Basiskomponente
durch, auf die die abhängige Komponente angewiesen ist, um zu bestätigen, dass sie wie festgelegt
funktionieren. Die ausgewählte Teilmenge berücksichtigt die möglichen Auswirkungen von Änderungen an
der Konfiguration/Verwendung der Basiskomponente, wie sie im zusammengesetzten TOE verwendet wird.
Diese Änderungen werden anhand der bei der Evaluierung der Basiskomponente ermittelten Konfiguration
der Basiskomponente identifiziert. Der Entwickler wird für jede der Schnittstellen der Basiskomponente
Prüfnachweise erbringen (die Anforderungen an die Abdeckung sind gegenüber denen konsistent, die bei der
Evaluierung der Basiskomponente angewendet werden).
Zur „Composition rationale“ (ACO_COR) muss der Evaluator feststellen, ob die geeigneten Vertrauenswürdig-
keitsmaßnahmen auf die Basiskomponente angewendet wurden und ob die Basiskomponente in ihrer
evaluierten Konfiguration verwendet wird. Dazu gehört die Feststellung, ob die gesamte von der abhängigen
Komponente benötigte Sicherheitsfunktionalität innerhalb der TSF der Basiskomponente lag. Die
Anforderung an die „Composition rationale“ (ACO_COR) kann durch die Vorlage von Nachweisen erfüllt
werden, dass jede dieser Anforderungen erwiesenermaßen eingehalten wird. Dieser Nachweis kann in Form
der Sicherheitsvorgaben und eines öffentlichen Berichts über die Evaluierung der Komponente (z. B.
Zertifizierungsbericht) erfolgen.
Wenn andererseits einer der oben genannten Punkte nicht aufrechterhalten wurde, dann kann
möglicherweise ein Argument dafür vorgebracht werden, warum die bei einer ursprünglichen Evaluierung
gewonnene Vertrauenswürdigkeit nicht beeinträchtigt wird. Wenn dies nicht möglich ist, müssen
möglicherweise zusätzliche Evaluationsnachweise für die nicht abgedeckten Aspekte der Basiskomponente
vorgelegt werden. Dieses Material wird dann in „Development evidence“ (ACO_DEV) beurteilt.
Beispielsweise kann es, wie in B.3 „Interaktionen zwischen zusammengesetzten IT-Entitäten“ in

ISO/IEC 15408-3) beschrieben, der Fall sein, dass die abhängige Komponente verlangt, dass die
Basiskomponente im zusammengesetzten TOE mehr Sicherheitsfunktionalität bietet, als in der Evaluierung
der Basiskomponente enthalten ist. Dies würde bei der Anwendung der Familien „Reliance of dependent
component“ (ACO_REL) und „Development evidence“ (ACO_DEV) festgelegt werden. In diesem Fall würde der
273
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
vorgesehene Nachweis der „Composition rationale“ (ACO_COR) nachweisen, dass die aus der Evaluierung der
Basiskomponente gewonnene Vertrauenswürdigkeit nicht beeinträchtigt wird. Dies kann unter anderem
durch folgende Maßnahmen erreicht werden:
a) Durchführung einer Neubewertung der Basiskomponente mit Schwerpunkt auf den Nachweisen für den
erweiterten Teil der TSF;
b) Nachweis, dass der erweiterte Teil der TSF andere Teile der TSF nicht beeinträchtigen kann, und der
Nachweis, dass der erweiterte Teil der TSF die erforderliche Sicherheitsfunktionalität bietet.
15.3 Begründung der Zusammensetzung (ACO_COR)
15.3.1 Evaluierung der Unteraufgabe (ACO_COR.1)
15.3.1.1 Eingaben
a) die zusammengesetzte ST,
b) die Begründung der Zusammensetzung,
c) die Verlässlichkeitsinformationen,
d) die Entwicklungsinformationen,
e) eindeutiger Bezeichner.
15.3.1.2 Aktion ACO_COR.1.1E
ISO/IEC 15408-3 ACO_COR.1.1C: Die Begründung der Zusammensetzung muss nachweisen, dass für die
Supportfunktionalität der Basiskomponente ein mindestens ebenso hoher Grad an Vertrauenswürdigkeit erreicht
wurde wie für die abhängige Komponente, wenn die Basiskomponente so konfiguriert ist, dass sie die TSF der
abhängigen Komponente unterstützt.
15.3.1.2.1 Workunit ACO_COR.1-1
Der Evaluator muss die Übereinstimmungsanalyse mit den Entwicklungsinformationen und den
Verlässlichkeitsinformationen untersuchen, um die Schnittstellen zu identifizieren, auf die die abhängige
Komponente angewiesen ist und die in den Entwicklungsinformationen nicht detailliert aufgeführt sind.
In dieser Workunit verfolgt der Evaluator zwei Ziele:
a) Feststellung, bei welchen Schnittstellen, auf die die abhängige Komponente angewiesen ist, die
entsprechenden Vertrauenswürdigkeitsmaßnahmen angewendet wurden;
b) Feststellung, dass das bei der Evaluierung der Basiskomponente auf die Basiskomponente angewendete
Sicherheitspaket entweder die gleichen Vertrauenswürdigkeitsanforderungen enthielt wie das bei der
Evaluierung der abhängigen Komponente angewendete Paket oder hierarchisch höhere Vertrauens-
würdigkeitsanforderungen.
Der Evaluator kann die Übereinstimmungsverfolgung in den Entwicklungsinformationen anwenden, die bei
den Aufgaben „Development evidence“ (ACO_DEV) (z. B. ACO_DEV.1-2, ACO_DEV.2-4, ACO_DEV.3-6)
entwickelt wurden, um die in den Verlässlichkeitsinformationen erkannten Schnittstellen zu identifizieren,
die in den Entwicklungsinformationen nicht berücksichtigt werden.
274
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator wird die in den Verlässlichkeitsinformationen beschriebenen SFR-durchsetzenden Schnitt-

stellen aufzeichnen, die nicht in den Entwicklungsinformationen enthalten sind. Diese liefern Eingaben für
Workunit ACO_COR.1-3 und helfen dabei, die Teile der Basiskomponente zu identifizieren, in denen weitere
Verlässlichkeit erforderlich ist.
Wenn sowohl die Basis- als auch die abhängige Komponente anhand desselben Sicherheitspakets evaluiert
wurden, dann ist die Bestimmung, ob die Vertrauenswürdigkeitsstufe in den Teilen innerhalb der Evaluierung
der Basiskomponente mindestens so hoch ist wie die der abhängigen Komponente, trivial. Wenn sich jedoch
die bei den Komponentenevaluierungen auf die Komponenten angewandten Sicherheitspakete unterscheiden,
muss der Evaluator feststellen, dass die auf die Basiskomponente angewandten Vertrauenswürdigkeits-
anforderungen alle hierarchisch höher sind als die auf die abhängige Komponente angewandten Vertrauens-
würdigkeitsanforderungen.
Der Evaluator muss die Begründung der Zusammensetzung untersuchen, um für die enthaltenen Schnitt-
stellen der Basiskomponente, auf die die abhängige TSF angewiesen ist, festzustellen, ob die Schnittstelle bei
der Evaluierung der Basiskomponente berücksichtigt wurde.
Die ST, der öffentliche Evaluierungsbericht der Komponente (z. B. Zertifizierungsbericht) und die Leitlinien-
dokumente für die Basiskomponente liefern alle Informationen über den Umfang und die Grenzen der
Basiskomponente. Die ST liefert Einzelheiten über den logischen Umfang und die Grenzen des zusammen-
gesetzten TOE, so dass der Evaluator feststellen kann, ob sich eine Schnittstelle auf einen Teil des Produkts
bezieht, der in den Anwendungsbereich der Evaluierung fiel. Die Leitliniendokumentation enthält Einzel-
heiten zur Verwendung aller Schnittstellen für den zusammengesetzten TOE. Obwohl die Leitlinien-
dokumentation Einzelheiten zu Schnittstellen im Produkt enthalten kann, die nicht in den Anwendungs-
bereich der Evaluierung fallen, sollten solche Schnittstellen entweder aus den Scoping-Informationen in der
ST oder durch einen Teil der Leitlinie, der sich mit der evaluierten Konfiguration befasst, identifizierbar sein.
Der öffentliche Evaluierungsbericht kann alle erforderlichen zusätzlichen Einschränkungen für die
Verwendung des zusammengesetzten TOEs enthalten.
Daher ermöglicht es die Kombination dieser Eingaben dem Evaluator zu bestimmen, ob eine in der
Begründung der Zusammensetzung beschriebene Schnittstelle die erforderliche Vertrauenswürdigkeit
aufweist oder ob weitere Vertrauenswürdigkeit erforderlich ist. Der Evaluator wird diejenigen Schnittstellen
der Basiskomponente, für die zusätzliche Vertrauenswürdigkeit erforderlich ist, zur Berücksichtigung bei
ACO_COR.1-3 aufzeichnen.
Der Evaluator muss die Begründung der Zusammensetzung untersuchen, um festzustellen, ob die erforder-
lichen Maßnahmen zur Zusicherung der Vertrauenswürdigkeit auf die Basiskomponente angewendet wurden.
Die Evaluierungsentscheidungen und die daraus resultierende Vertrauenswürdigkeit für die Basis-
komponente können wiederverwendet werden, vorausgesetzt, dass die gleichen Teile der Basiskomponente
im zusammengesetzten TOE verwendet werden und dass sie in konsistenter Weise verwendet werden.
Um zu bestimmen, ob die erforderlichen Maßnahmen zur Zusicherung der Vertrauenswürdigkeit bereits auf
die Komponente angewendet wurden und für welche Teile der Komponente die Maßnahmen zur Zusicherung
der Vertrauenswürdigkeit noch angewendet werden müssen, sollte der Evaluator die Ausgabe der Aktion
ACO_DEV.*.2E sowie die Workunits ACO_COR.1-1 und ACO_COR.1-2 verwenden.
a) Für die in den Verlässlichkeitsinformationen („Reliance of dependent component“ (ACO_REL)) identifi-

zierten Schnittstellen, die aber nicht in den Entwicklungsinformationen („Development evidence“
(ACO_DEV)) erörtert wurden, sind zusätzliche Informationen erforderlich. (Identifiziert in ACO_COR.1-1.)
275
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
b) Für diejenigen Schnittstellen, die im zusammengesetzten TOE von der Basiskomponente aus inkonsistent
verwendet werden (Unterschied zwischen den Informationen, die in „Development evidence“ (ACO_DEV)
und „Reliance of dependent component“ (ACO_REL) bereitgestellt werden), müssen die Auswirkungen
der Unterschiede in der Nutzung berücksichtigt werden. (Identifiziert in ACO_DEV.*.2E.)
c) Für diejenigen Schnittstellen, die in der Begründung der Zusammensetzung identifiziert wurden und für
die zuvor keine Vertrauenswürdigkeit gewonnen wurde, sind zusätzliche Informationen erforderlich.
(Identifiziert in ACO_COR.1-2.)
d) Für die Schnittstellen, die in den Verlässlichkeitsinformationen, der Begründung der Zusammensetzung
und den Entwicklungsinformationen konsistent beschrieben sind, sind keine weiteren Aktionen erforder-
lich, da die Ergebnisse aus der Evaluierung der Basiskomponente wiederverwendet werden können.
Die Schnittstellen der Basiskomponente, von denen berichtet wird, dass sie in den Verlässlichkeits-
informationen erforderlich sind, die aber nicht in den Entwicklungsinformationen enthalten sind, geben die
Teile der Basiskomponente an, bei denen eine weitere Vertrauenswürdigkeit erforderlich ist. Die Schnitt-
stellen identifizieren die Eingangspunkte in die Basiskomponente.
Für die Schnittstellen, die sowohl in den Entwicklungsinformationen als auch in den Verlässlichkeits-
informationen enthalten sind, muss der Evaluator feststellen, ob die Schnittstellen im zusammengesetzten
TOE in einer Weise verwendet werden, die gegenüber der Evaluierung der Basiskomponente konsistent ist.
Das Verfahren zur Verwendung der Schnittstelle wird bei den Aufgaben „Development evidence“ (ACO_DEV)
berücksichtigt, um festzustellen, dass die Verwendung der Schnittstelle sowohl in der Basiskomponente als
auch im zusammengesetzten TOE konsistent ist. Die verbleibende Überlegung ist die Feststellung, ob die
Konfigurationen der Basiskomponente und des zusammengesetzten TOEs konsistent sind. Um dies zu
bestimmen, wird der Evaluator die Leitliniendokumentation der einzelnen Länder berücksichtigen, um
sicherzustellen, dass sie konsistent sind (siehe weitere Hinweise zur konsistenten Leitliniendokumentation
weiter unten). Jede Abweichung in der Dokumentation wird bei der Evaluierung weiter analysiert, um die
möglichen Auswirkungen zu ermitteln.
Für diejenigen Schnittstellen, die in den Verlässlichkeits- und Entwicklungsinformationen konsistent

beschrieben sind und für die die Anleitung für die Basiskomponente und den zusammengesetzten TOE
konsistent ist, wurde die erforderliche Vertrauenswürdigkeitsstufe bereitgestellt.
Die folgenden Unterabschnitte enthalten Hinweise darauf, wie die Konsistenz zwischen der in der
Basiskomponente gewonnenen Vertrauenswürdigkeit, den für den zusammengesetzten TOE gelieferten
Nachweisen und der vom Evaluator durchgeführten Analyse in den Fällen, in denen Inkonsistenzen
festgestellt werden, bestimmt wird.
15.3.1.2.3.1 Entwicklung
Die Verlässlichkeitsinformationen identifizieren die Schnittstellen in der abhängigen Komponente, die von der
Basiskomponente abgeglichen werden sollen. Wenn eine in den Verlässlichkeitsinformationen identifizierte
Schnittstelle nicht in den Entwicklungsinformationen identifiziert wird, dann soll die Begründung der
Zusammensetzung eine Begründung dafür liefern, wie die Basiskomponente die erforderlichen Schnittstellen
bereitstellt.
Wenn eine Schnittstelle, die in den Verlässlichkeitsinformationen identifiziert wurde, in den Entwicklungs-
informationen identifiziert wird, es aber Inkonsistenzen zwischen den Beschreibungen gibt, ist eine weitere
Analyse erforderlich. Der Evaluator identifiziert die Unterschiede in der Verwendung der Basiskomponente,
wie sie bei der Evaluierung der Basiskomponente und der zusammengesetzten TOE-Evaluierung
berücksichtigt wurden. Der Evaluator arbeitet durchzuführende Prüfungen (während der Durchführung von
„Composed TOE testing“ (ACO_CTT)) aus, um die Schnittstelle zu prüfen.
276
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Patch-Status der Basis- und abhängigen Komponenten, wie sie im zusammengesetzten TOE verwendet
werden, sollte während der Komponentenevaluierungen mit dem Patch-Status der Komponenten verglichen
werden. Wenn die Komponenten mit Patches versehen wurden, muss die Begründung der Zusammensetzung
Details der Patches enthalten, einschließlich potentieller Auswirkungen auf die SFRs der evaluierten
Komponente. Der Evaluator sollte die Einzelheiten der bereitgestellten Änderungen berücksichtigen und die
Genauigkeit der potentiellen Auswirkungen der Änderung auf die Komponenten-SFRs überprüfen. Der
Evaluator sollte dann überlegen, ob die durch den Patch vorgenommenen Änderungen durch Prüfungen
verifiziert werden sollten, und wird den notwendigen Prüfansatz ermitteln. Die Prüfungen können in Form
einer Wiederholung der für die Komponentenevaluierung der Komponente durchgeführten Prüfungen durch
den Evaluator/Entwickler erfolgen, oder es kann erforderlich sein, dass der Evaluator neue Prüfungen
ausarbeitet, um die geänderte Komponente zu bestätigen.
Wenn eine der einzelnen Komponenten seit dem Abschluss der Komponentenevaluierung Gegenstand von
Aufgaben zur Zusicherung der Kontinuität der Vertrauenswürdigkeit war, wird der Evaluator die Änderungen
berücksichtigen, die bei den Aufgaben zur Zusicherung der Kontinuität der Vertrauenswürdigkeit während
der unabhängigen Anfälligkeitsanalyse für den zusammengesetzten TOE (in „Composition vulnerability
analysis“ (ACO_VUL)) beurteilt wurden.
15.3.1.2.3.2 Leitlinien
Die Leitlinien für den zusammengesetzten TOE werden wahrscheinlich in erheblichem Maße auf die Leitlinien
für die einzelnen Komponenten verweisen. Die voraussichtlich mindestens erforderlichen Leitlinien sind die
Identifizierung sämtlicher Ordnungsabhängigkeiten bei der Anwendung der Leitlinien für die abhängigen und
Basiskomponenten, insbesondere während der Vorbereitung (Installation) des zusammengesetzten TOE.
Zusätzlich zur Anwendung der Familien „Preparative procedures“ (AGD_PRE) und „Operational user
guidance“ (AGD_OPE) für die Leitlinien des zusammengesetzten TOEs ist es notwendig, die Konsistenz
zwischen den Leitlinien für die Komponenten und dem zusammengesetzten TOE zu analysieren, um
gegebenenfalls Abweichungen zu identifizieren.
Wenn sich die Leitlinien für den zusammengesetzten TOE auf die Leitlinien für die Basiskomponente und die
abhängige Komponente beziehen, dann beschränkt sich die Betrachtung der Konsistenz auf die Konsistenz
zwischen der für jede der Komponenten bereitgestellten Leitliniendokumentation (d. h. die Konsistenz
zwischen den Leitlinien für die Basiskomponente und den Leitlinien für die abhängige Komponente). Wenn
jedoch für den zusammengesetzten TOE zusätzlich zu den Komponenten weitere Leitlinien zur Verfügung
gestellt werden, ist eine umfassendere Analyse erforderlich, da auch die Konsistenz zwischen der
Leitliniendokumentation für die Komponenten und der Leitliniendokumentation für den zusammengesetzten
TOE sichergestellt sein muss.
Konsistent bedeutet in diesem Fall, dass entweder die Leitlinien gleich sind oder dass sie die Funktionsweise
der einzelnen Komponenten in ihrer Kombination zusätzlich einschränken, ähnlich wie bei der Präzisierung
von Funktions-/Vertrauenswürdigkeitskomponenten.
Mit den verfügbaren Informationen (die als Eingabe für „Development evidence“ (ACO_DEV) oder für die oben
besprochenen Entwicklungsaspekte verwendet werden) ist der Evaluator möglicherweise in der Lage, alle
möglichen Auswirkungen der Abweichung von der in der Komponentenevaluierung festgelegten
Konfiguration der Basiskomponente zu bestimmen. Bei hohen EALs (bei denen die Evaluierung der
Basiskomponente Anforderungen an das „TOE design“ (ADV_TDS) enthielt), ist es jedoch denkbar, dass die
möglichen Auswirkungen der Änderung der Leitlinien nicht vollständig bestimmt werden können, da die
Interna des TOEs unbekannt sind, es sei denn, es werden detaillierte Designabstraktionen für die
Basiskomponente als Teil der Entwicklungsinformationen für den zusammengesetzten TOE geliefert. In
diesem Fall gibt der Evaluator das Restrisiko der Analyse an.
Diese Restrisiken sind in jeden öffentlichen Evaluierungsbericht für den zusammengesetzten TOE
aufzunehmen.
277
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator wird diese Abweichungen in der Anleitung für die Eingabe in die unabhängigen Prüfaufgaben
des Evaluators vermerken („Composed TOE testing“ (ACO_CTT)).
Die Leitlinien für den zusammengesetzten TOE können die Leitlinien für die Komponenten ergänzen,
insbesondere in Bezug auf die Installation und die Reihenfolge der Installationsschritte für die
Basiskomponente im Verhältnis zu den Installationsschritten für die abhängige Komponente. Die Reihenfolge
der Schritte für die Installation der einzelnen Komponenten sollte sich nicht ändern, sie müssen jedoch unter
Umständen verschachtelt werden. Der Evaluator wird diese Leitlinien untersuchen, um sicherzustellen, dass
sie weiterhin den Anforderungen der Aufgabe AGD_PRE entsprechen, die während der Evaluierungen der
Komponenten durchgeführt werden.
Es kann sein, dass die Verlässlichkeitsinformationen angeben, dass zusätzlich zu den als TSFI der Basis-
komponente identifizierten Schnittstellen der Basiskomponente auch Schnittstellen der Basiskomponente,
auf die die abhängige Komponente angewiesen ist, in den Verlässlichkeitsinformationen angegeben sind. Es
kann erforderlich sein, dass für die Verwendung solcher zusätzlichen Schnittstellen in der Basiskomponente
Leitlinien zur Verfügung gestellt werden. Unter der Voraussetzung, dass der Verbraucher des
zusammengesetzten TOEs die Leitliniendokumentation für die Basiskomponente erhalten soll, können die
Ergebnisse der AGD_PRE- und AGD_OPE-Entscheidungen für die Basiskomponente für die bei der Evaluierung
der Basiskomponente berücksichtigten Schnittstellen wiederverwendet werden. Für die zusätzlichen
Schnittstellen, auf die die abhängige Komponente angewiesen ist, muss der Evaluator jedoch feststellen, dass
die Leitliniendokumentation für die Basiskomponente die Anforderungen von AGD_PRE und AGD_OPE, wie
sie in den Evaluierungen der Basiskomponente angewandt werden, erfüllt.
Für diejenigen Schnittstellen, die bei der Evaluierung der Basiskomponente berücksichtigt wurden und für die
daher bereits Vertrauenswürdigkeit gewonnen wurde, stellt der Evaluator sicher, dass die Leitlinien für die
Verwendung jeder Schnittstelle für den zusammengesetzten TOE gegenüber den für die Basiskomponente
bereitgestellten Leitlinien konsistent sind. Um festzustellen, ob die Leitlinien für den zusammengesetzten TOE
gegenüber denen für die Basiskomponente konsistent sind, sollte der Evaluator für jede Schnittstelle eine
Zuordnung auf die sowohl für den zusammengesetzten TOE als auch für die Basiskomponente bereitgestellten
Leitlinien vornehmen. Der Evaluator vergleicht dann die Leitlinien, um die Konsistenz zu bestimmen.
Beispiele für zusätzliche Einschränkungen in zusammengesetzten TOE-Leitlinien, die als konsistent

gegenüber den Komponentenleitlinien gelten würden, sind (Leitlinien werden für eine Komponente
bereitgestellt, denen ein Beispiel für einen zusammengesetzten TOE folgt, wobei dieser als zusätzliche
Einschränkungen eingestuft würde):
Komponente: Die Länge des Passworts muss auf mindestens 8 Zeichen, einschließlich alphabetischer und
numerischer Zeichen, festgelegt werden;
zusammengesetzter TOE: Die Länge des Passworts muss auf mindestens 10 Zeichen, einschließlich
alphabetischer und numerischer Zeichen und mindestens eines der folgenden Sonderzeichen, festgelegt
werden: ( ) { } ^ < > - _;
ANMERKUNG: Es wäre nur akzeptabel, die Passwortlänge auf [ganze Zahl > 8] Zeichen zu erhöhen und gleichzeitig das
Mandat für die Aufnahme sowohl alphabetischer als auch numerischer Zeichen für den zusammengesetzten TOE
aufzuheben, wenn die gleiche oder eine höhere Metrik für die Bewertung der Passwortstärke erreicht wird (unter
Berücksichtigung der Wahrscheinlichkeit, dass das Passwort erraten wird);
Komponente: Die folgenden Dienste sind in den Registrierungseinstellungen zu deaktivieren: WWW

Publishing Service und ICDBReporter Service;
zusammengesetzter TOE: Die folgenden Dienste sind in den Registrierungseinstellungen zu deaktivieren:

Publishing Service, ICDBReporter Service, Remote Procedure Call (RPC) Locator und Procedure Call (RPC)
Service;
278
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Komponente: Es werden die folgenden Attribute ausgewählt, die in die Abrechnungsprotokolldateien

aufgenommen werden sollen: Datum, Uhrzeit, Art des Ereignisses, Identität des Subjekts und
Erfolg/Misserfolg;
zusammengesetzter TOE: Es werden die folgende Attribute ausgewählt, die in die Abrechnungs-
protokolldateien aufgenommen werden sollen: Datum, Uhrzeit, Art des Ereignisses, Identität des
Subjekts, Erfolg/Misserfolg, Ereignismeldung und Prozess-Thread.
Wenn die Leitlinien für den zusammengesetzten TOE von denen für die Basiskomponente bereitgestellten
Leitlinien abweichen (keine Präzisierung sind), wird der Evaluator die potentiellen Risiken der geänderten
Leitlinien beurteilen. Der Evaluator wird die verfügbaren Informationen (einschließlich der öffentlich zur
Verfügung gestellten Informationen, der Architekturbeschreibung der Basiskomponente im öffentlichen
Evaluierungsbericht (z. B. Zertifizierungsbericht), des Kontexts der Leitlinien aus der übrigen Dokumentation
der Leitlinien) verwenden, um die wahrscheinlichen Auswirkungen der geänderten Leitlinien auf die SFRs des
zusammengesetzten TOEs zu ermitteln.
Wenn während der Evaluierung der abhängigen Komponente bei der Versuchsanlage die Basiskomponente
verwendet wurde, um die Umgebungsanforderungen der abhängigen Komponente zu erfüllen, gilt diese
Workunit für den zusammengesetzten TOE als erfüllt. Wenn die Basiskomponente während der Evaluierung
der abhängigen Komponente nicht zur Erfüllung der Workunit AGD_PRE.1-3 verwendet wurde, wendet der
Evaluator die für den zusammengesetzten TOE vorgesehenen Benutzerverfahren an, um den zusammen-
gesetzten TOE in Übereinstimmung mit den in AGD_PRE.1-3 festgelegten Leitlinien vorzubereiten. Auf diese
Weise kann der Evaluator feststellen, dass die für den zusammengesetzten TOE bereitgestellten
vorbereitenden Leitlinien ausreichen, um den zusammengesetzten TOE und seine Betriebsumgebung sicher
vorzubereiten.
15.3.1.2.3.3 Lebenszyklus
Lieferung
Wenn für die Lieferung des zusammengesetzten TOEs ein anderer Lieferungsmechanismus verwendet wird
(d. h. die Komponenten werden nicht in Übereinstimmung mit den sicheren Lieferungsverfahren an den
Verbraucher geliefert, die während der Evaluierung der Komponenten definiert und beurteilt wurden),
müssen die Lieferungsverfahren für den zusammengesetzten TOE anhand der während der
Komponentenevaluierungen angewandten Anforderungen an die „Delivery“ (ALC_DEL) evaluiert werden.
Der zusammengesetzte TOE kann als integriertes Produkt geliefert werden, oder es kann erforderlich sein,
dass die Komponenten separat geliefert werden.
Wenn die Komponenten getrennt geliefert werden, werden die Ergebnisse der gelieferten Basiskomponente
und der abhängigen Komponente wiederverwendet. Die Lieferung der Basiskomponente wird während der
Versuchsinstallation der abhängigen Komponente durch den Evaluator überprüft, wobei die angegebenen
Leitlinien verwendet und die Aspekte der Lieferung geprüft werden, die in der Verantwortung des Benutzers
liegen, wie in der Leitliniendokumentation für die Basiskomponente beschrieben.
Wenn der zusammengesetzte TOE als neue Entität geliefert wird, dann muss das Lieferverfahren dieser Entität
bei den Evaluierungsaufgaben des zusammengesetzten TOEs berücksichtigt werden.
Die Beurteilung der Lieferverfahren für zusammengesetzte TOE-Positionen ist in Übereinstimmung mit der
Methodik für die „Delivery“ (ALC_DEL) wie für jeden anderen [Komponenten-]TOE durchzuführen, wobei
sicherzustellen ist, dass zusätzliche Positionen (z. B. zusätzliche Leitliniendokumente für den
zusammengesetzten TOE) in den Lieferverfahren berücksichtigt werden.
279
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
CM-Funktionen
Die eindeutige Identifizierung des zusammengesetzten TOEs wird bei der Anwendung der „Evaluation of sub-
activity“ (ALC_CMC.1) berücksichtigt, und die Elemente, aus denen der zusammengesetzte TOE besteht,
werden bei der Anwendung der „Evaluation of sub-activity“ (ALC_CMS.2) berücksichtigt.
Obwohl zusätzliche Leitlinien für den zusammengesetzten TOE erstellt werden können, wird die eindeutige
Identifizierung dieser Leitlinien (als Teil der eindeutigen Identifizierung des zusammengesetzten TOEs
während der „Evaluation of sub-activity“ (ALC_CMC.1)) als ausreichende Kontrolle der Leitlinien angesehen.
Die Entscheidungen der übrigen (oben nicht berücksichtigten) Aufgaben der Klasse ALC „Life-cycle support“
können aus der Evaluierung der Basiskomponente wiederverwendet werden, da während der Integration des
zusammengesetzten TOE keine weitere Entwicklung durchgeführt wird.
Es gibt keine zusätzlichen Überlegungen zur Entwicklungssicherheit, da davon ausgegangen wird, dass die
Integration entweder am Standort des Verbrauchers oder, falls der zusammengesetzte TOE als integriertes
Produkt geliefert wird, am Standort des Entwicklers der abhängigen Komponente erfolgt. Die Kontrolle am
Standort des Verbrauchers liegt außerhalb der Betrachtung der ISO/IEC 15408. Es sind keine zusätzlichen
Anforderungen oder Leitlinien erforderlich, wenn sich die Integration am gleichen Ort wie die der abhängigen
Komponente befindet, da alle Komponenten als Konfigurationselemente für den zusammengesetzten TOE
angesehen werden und daher ohnehin im Rahmen der Sicherheitsverfahren des Entwicklers der abhängigen
Komponente berücksichtigt werden sollten.
Tools und Techniken, die während der Integration eingesetzt werden, werden in den vom Entwickler der
abhängigen Komponente vorgelegten Nachweisen berücksichtigt. Alle Tools/Techniken, die für die
Basiskomponente relevant sind, werden bei der Evaluierung der Basiskomponente berücksichtigt worden
sein. Wenn z. B. die Basiskomponente als Quellcode geliefert wird und vom Verbraucher (z. B. einem
Entwickler der abhängigen Komponente, der die Integration durchführt) kompiliert werden muss, wäre der
Compiler bei der Evaluierung der Basiskomponente festgelegt und zusammen mit den entsprechenden
Argumenten beurteilt worden.
Es gibt keine auf den zusammengesetzten TOE anwendbare Lebenszyklus-Definition, da keine weitere
Entwicklung von Elementen stattfindet.
Die Ergebnisse der Mängelbeseitigung für eine Komponente sind nicht auf den zusammengesetzten TOE
anwendbar. Wenn das Sicherheitspaket für den zusammengesetzten TOE eine Mängelbeseitigung enthält,
dann sind die Anforderungen an die „Flaw remediation“ (ALC_FLR) während der Evaluierung des
zusammengesetzten TOEs (wie bei jeder Erweiterung) anzuwenden.
15.3.1.2.3.4 Prüfungen
Der zusammengesetzte TOE wird während der Durchführung der Aufgaben der Klasse ATE „Tests“ zur
Evaluierung der abhängigen Komponente geprüft worden sein, da die für das Prüfen der abhängigen
Komponente verwendeten Konfigurationen die Basiskomponente enthalten sollten, um die Anforderungen an
die IT in der Betriebsumgebung zu erfüllen. Wenn die Basiskomponente bei den Prüfungen der abhängigen
Komponente für die Evaluierung der abhängigen Komponente nicht verwendet wurde oder die Konfiguration
der beiden Komponenten von ihren evaluierten Konfigurationen abweicht, dann sind die für die Evaluierung
der abhängigen Komponente durchgeführten Entwicklerprüfungen zur Erfüllung der Anforderungen an die
Klasse ATE „Tests“ am zusammengesetzten TOE zu wiederholen.
280
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
15.4 Entwicklungsnachweis (ACO_DEV)
15.4.1 Evaluierung der Unteraufgabe (ACO_DEV.1)
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, dass die entsprechende Sicherheits-
funktionalität von der Basiskomponente zur Unterstützung der abhängigen Komponente bereitgestellt wird.
Dies wird erreicht, indem die Schnittstellen der Basiskomponente untersucht werden, um festzustellen, ob sie
gegenüber den in den Verlässlichkeitsinformationen festgelegten Schnittstellen konsistent sind, d. h.
gegenüber denen, die von der abhängigen Komponente benötigt werden.
Die Beschreibung der Schnittstellen zur Basiskomponente ist in einem Detaillierungsgrad bereitzustellen, der
gegenüber der „Evaluation of sub-activity“ (ADV_FSP.2) konsistent ist, obwohl nicht alle zur Erfüllung der
„Evaluation of sub-activity“ (ADV_FSP.2) notwendigen Aspekte für die „Evaluation of sub-activity“
(ACO_DEV.1) erforderlich sind, da nach der Identifizierung der Schnittstelle und der Beschreibung des Zwecks
die verbleibenden Details der Schnittstellenspezifikation aus der Evaluierung der Basiskomponente
wiederverwendet werden können.
15.4.1.2 Eingaben
b) die Entwicklungsinformationen,
c) die Verlässlichkeitsinformationen.
15.4.1.3 Aktion ACO_DEV.1.1E
ISO/IEC 15408-3 ACO_DEV.1.1C: Die Entwicklungsinformationen müssen den Zweck jeder im zusammen-
gesetzten TOE verwendeten Schnittstelle der Basiskomponente beschreiben.
15.4.1.3.1 Workunit ACO_DEV.1-1
Der Evaluator muss die Entwicklungsinformationen untersuchen, um festzustellen, dass sie den Zweck jeder
Schnittstelle beschreiben.
Die Basiskomponente bietet Schnittstellen zur Unterstützung der Interaktion mit der abhängigen
Komponente bei der Bereitstellung der abhängigen TSF. Der Zweck jeder Schnittstelle ist auf der gleichen
Ebene zu beschreiben wie die Beschreibung der Schnittstellen zur TSF-Funktionalität der abhängigen
Komponente, wie sie zwischen Teilsystemen im TOE-Design vorgesehen wäre („Evaluation of sub-activity“
(ADV_TDS.1)). Diese Beschreibung soll dem Leser ein Verständnis dafür vermitteln, wie die Basiskomponente
die von der TSF der abhängigen Komponente benötigten Dienste zur Verfügung stellt.
Diese Workunit kann durch die Bereitstellung der Funktionsspezifikation für die Basiskomponente für
diejenigen Schnittstellen, die TSFIs der Basiskomponente sind, erfüllt werden.
ISO/IEC 15408-3 ACO_DEV.1.2C: Die Entwicklungsinformationen müssen die Übereinstimmung zwischen den im
zusammengesetzten TOE verwendeten Schnittstellen der Basiskomponente und der abhängigen Komponente zur
Unterstützung der TSF der abhängigen Komponente zeigen.
281
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss die Entwicklungsinformationen untersuchen, um festzustellen, ob die Übereinstimmung

zwischen den Schnittstellen der Basiskomponente und den Schnittstellen, auf die die abhängige Komponente
angewiesen ist, korrekt ist.
Die Übereinstimmung zwischen den Schnittstellen der Basiskomponente und den Schnittstellen, auf die die
abhängige Komponente angewiesen ist, kann die Form einer Matrix oder Tabelle haben. Die Schnittstellen, auf
die die abhängige Komponente angewiesen ist, werden in den Verlässlichkeitsinformationen (wie während
der Aufgabe „Reliance of dependent component“ (ACO_REL) untersucht) identifiziert.
Bei dieser Aufgabe ist es nicht erforderlich, die Vollständigkeit der Abdeckung von Schnittstellen, auf die die
abhängige Komponente angewiesen ist, zu bestimmen, sondern es muss nur sichergestellt werden, dass die
Übereinstimmung korrekt ist und dass Schnittstellen der Basiskomponente auf die von der abhängigen
Komponente benötigten Schnittstellen abgebildet werden, wo immer dies möglich ist. Die Vollständigkeit der
Abdeckung wird bei den Aufgaben „Composition rationale“ (ACO_COR) berücksichtigt.
Der Evaluator muss die Entwicklungsinformationen und die Verlässlichkeitsinformationen untersuchen, um

festzustellen, ob die Schnittstellen konsistent beschrieben werden.
Das Ziel des Evaluators in dieser Workunit ist es, festzustellen, dass die in den Entwicklungsinformationen für
die Basiskomponente beschriebenen Schnittstellen und die Verlässlichkeitsinformationen für die abhängige
Komponente konsistent dargestellt werden.
Dies wird erreicht, indem die Schnittstellen und das damit verbundene Sicherheitsverhalten der Basis-
komponente untersucht werden, um festzustellen, ob sie gegenüber den in den Verlässlichkeitsinformationen
festgelegten Schnittstellen konsistent sind, d. h. gegenüber denen, die von der abhängigen Komponente
benötigt werden.
15.4.2.2 Eingaben
ISO/IEC 15408-3 ACO_DEV.2.1C: Die Entwicklungsinformationen müssen den Zweck und die Verwendungs-
methode jeder im zusammengesetzten TOE verwendeten Schnittstelle der Basiskomponente beschreiben.
282
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Ebene zu beschreiben wie die Beschreibung der Schnittstellen zur Funktionalität der TSF der abhängigen
Der Evaluator muss die Entwicklungsinformationen untersuchen, um festzustellen, dass sie die
Verwendungsmethode jeder Schnittstelle beschreiben.
Die Verwendungsmethode für eine Schnittstelle fasst zusammen, wie die Schnittstelle manipuliert wird, um
die Operationen aufzurufen und mit der Schnittstelle verbundene Ergebnisse zu erhalten. Der Evaluator sollte
in der Lage sein, anhand der Lektüre dieses Materials in den Entwicklungsinformationen zu bestimmen, wie
jede Schnittstelle zu verwenden ist. Dies bedeutet nicht unbedingt, dass es für jede Schnittstelle eine eigene
APIs aufgerufen werden, und dann jede Schnittstelle mit diesem allgemeinen Typ zu identifizieren.
ISO/IEC 15408-3 ACO_DEV.2.2C: Die Entwicklungsinformationen müssen eine allgemeine Beschreibung des
Verhaltens der Basiskomponente bereitstellen, die die Durchsetzung der SFRs der abhängigen Komponente
unterstützt.
Der Evaluator muss die Entwicklungsinformationen untersuchen, um festzustellen, dass sie das Verhalten
der Basiskomponente beschreiben, die die Durchsetzung der abhängigen Komponenten-SFRs unterstützt.
Die abhängige Komponente ruft Schnittstellen der Basiskomponente für die Bereitstellung von Diensten durch
die Basiskomponente auf. Für die Schnittstellen der Basiskomponente, die aufgerufen werden, müssen die
Entwicklungsinformationen eine allgemeine Beschreibung des zugehörigen Sicherheitsverhaltens der
Basiskomponente vorsehen. Die Beschreibung des Sicherheitsverhaltens der Basiskomponente gibt einen
Überblick darüber, wie die Basiskomponente beim Aufruf der Schnittstelle den erforderlichen Dienst
bereitstellt. Diese Beschreibung soll sich auf einer ähnlichen Ebene wie bei ADV_TDS.1.4C bewegen. Daher
würde die Bereitstellung des TOEs-Designnachweises aus der Evaluierung der Basiskomponente diese
Workunit erfüllen, wenn die von der abhängigen Komponente aufgerufenen Schnittstellen die TSFIs der
Basiskomponente sind. Wenn die von der abhängigen Komponente aufgerufenen Schnittstellen keine TSFIs
der Basiskomponente sind, wird das damit verbundene Sicherheitsverhalten nicht notwendigerweise im
TOE-Designnachweis der Basiskomponente beschrieben.
283
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

die die abhängige Komponente angewiesen ist, werden in den Verlässlichkeitsinformationen (wie bei
„Reliance of dependent component“ (ACO_REL)) untersucht) identifiziert.

Dies wird erreicht, indem die Schnittstellen und das damit verbundene Sicherheitsverhalten der Basis-
komponente untersucht werden, um festzustellen, ob sie gegenüber den in den Verlässlichkeitsinformationen
festgelegten Schnittstellen konsistent sind, d. h. gegenüber denen, die von der abhängigen Komponente
benötigt werden.
Zusätzlich zur Schnittstellenbeschreibung werden die Teilsysteme der Basiskomponente, die die von der
abhängigen Komponente benötigte Sicherheitsfunktionalität bereitstellen, beschrieben, damit der Evaluator
feststellen kann, ob diese Schnittstelle Teil der TSF der Basiskomponente war oder nicht.
15.4.3.2 Eingaben
284
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
ISO/IEC 15408-3 ACO_DEV.3.1C: Die Entwicklungsinformationen müssen den Zweck und die Verwendungs-
methode jeder im zusammengesetzten TOE verwendeten Schnittstelle der Basiskomponente beschreiben.
Ebene zu beschreiben wie die Beschreibung der Schnittstellen zur TSF-Funktionalität der abhängigen
Der Evaluator muss die Entwicklungsinformationen untersuchen, um festzustellen, dass sie die
Verwendungsmethode jeder Schnittstelle beschreiben.
Die Verwendungsmethode für eine Schnittstelle fasst zusammen, wie die Schnittstelle manipuliert wird, um
die Operationen aufzurufen und mit der Schnittstelle verbundene Ergebnisse zu erhalten. Der Evaluator sollte
in der Lage sein, anhand der Lektüre dieses Materials in den Entwicklungsinformationen zu bestimmen, wie
jede Schnittstelle zu verwenden ist. Dies bedeutet nicht unbedingt, dass es für jede Schnittstelle eine eigene
APIs aufgerufen werden, und dann jede Schnittstelle mit diesem allgemeinen Typ zu identifizieren.
ISO/IEC 15408-3 ACO_DEV.3.2C: Die Entwicklungsinformationen müssen diejenigen Teilsysteme der Basis-
komponente identifizieren, die im zusammengesetzten TOE verwendete Schnittstellen der Basiskomponente
bereitstellen.
Der Evaluator muss die Entwicklungsinformationen untersuchen, um festzustellen, dass alle Teilsysteme der
Basiskomponente, die Schnittstellen zu der abhängigen Komponente bereitstellen, identifiziert sind.
Für diejenigen Schnittstellen, die als Teil der TSFI der Basiskomponente betrachtet werden, handelt es sich
bei den mit der Schnittstelle verbundenen Teilsystemen um jene Teilsysteme, die in der Aufgabe „TOE design“
(ADV_TDS) bei der Evaluierung der Basiskomponente berücksichtigt werden. Die Schnittstellen, auf die die
abhängige Komponente angewiesen ist und die nicht Teil der TSFI der Basiskomponente waren, werden auf
Teilsysteme außerhalb der TSF der Basiskomponente abgebildet.
ISO/IEC 15408-3 ACO_DEV.3.3C: Die Entwicklungsinformationen müssen eine allgemeine Beschreibung des
Verhaltens derjenigen Teilsysteme der Basiskomponente bereitstellen, die die Durchsetzung der SFRs der
abhängigen Komponente unterstützen.
285
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss die Entwicklungsinformationen untersuchen, um festzustellen, dass sie das Verhalten
der Teilsysteme der Basiskomponente beschreiben, die die Durchsetzung der abhängigen Komponenten-SFRs
unterstützen.
Die abhängige Komponente ruft Schnittstellen der Basiskomponente für die Bereitstellung von Diensten durch
die Basiskomponente auf. Für die Schnittstellen der Basiskomponente, die aufgerufen werden, müssen die
Entwicklungsinformationen eine allgemeine Beschreibung des zugehörigen Sicherheitsverhaltens der
Basiskomponente vorsehen. Die Beschreibung des Sicherheitsverhaltens der Basiskomponente gibt einen
Überblick darüber, wie die Basiskomponente beim Aufruf der Schnittstelle den erforderlichen Dienst
bereitstellt. Diese Beschreibung soll sich auf einer ähnlichen Ebene wie bei ADV_TDS.1.4C bewegen. Daher
würde die Bereitstellung des TOEs-Designnachweises aus der Evaluierung der Basiskomponente diese
Workunit erfüllen, wenn die von der abhängigen Komponente aufgerufenen Schnittstellen die TSFIs der
Basiskomponente sind. Wenn die von der abhängigen Komponente aufgerufenen Schnittstellen keine TSFIs
der Basiskomponente sind, wird das damit verbundene Sicherheitsverhalten nicht notwendigerweise im
TOE-Designnachweis der Basiskomponente beschrieben.
ISO/IEC 15408-3 ACO_DEV.3.4C: Die Entwicklungsinformationen müssen eine Zuordnung von den Schnittstellen
zu den Teilsystemen der Basiskomponente bereitstellen.

zwischen den Schnittstellen und Teilsystemen der Basiskomponente genau ist.
Wenn der Nachweis des TOEs-Designs und der Funktionsspezifikation aus der Evaluierung der
Basiskomponente verfügbar ist, kann dieser zur Überprüfung der Genauigkeit der Übereinstimmung zwischen
den Schnittstellen und Teilsystemen der Basiskomponente, wie im zusammengesetzten TOE angewandt,
verwendet werden. Diejenigen Schnittstellen der Basiskomponente, die Teil der TSFI der Basiskomponente
waren, werden in der Funktionsspezifikation der Basiskomponente beschrieben, und die zugehörigen
Teilsysteme werden in den Nachweisen für das TOE-Design der Basiskomponente beschrieben. Die
Verfolgung zwischen den beiden wird in den TOE-Designnachweisen der Basiskomponente geliefert.
Wenn jedoch die Schnittstelle der Basiskomponente nicht Teil der TSFI der Basiskomponente war, wird die in
den Entwicklungsinformationen enthaltene Beschreibung des Verhaltens des Teilsystems verwendet, um die
Genauigkeit der Übereinstimmung zu überprüfen.

die die abhängige Komponente angewiesen ist, werden in den Verlässlichkeitsinformationen (wie bei
„Reliance of dependent component“ (ACO_REL) untersucht) identifiziert.
286
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

15.5 Verlässlichkeit der abhängigen Komponente (ACO_REL)
15.5.1 Evaluierung der Unteraufgabe (ACO_REL.1)
Die Zielsetzungen dieser Unteraufgabe bestehen darin, festzulegen, ob der Verlässlichkeitsnachweis des
Entwicklers ausreichende Informationen liefert, um festzustellen, dass die erforderliche Funktionalität in der
Basiskomponente verfügbar ist, sowie die Mittel, mit denen diese Funktionalität aufgerufen wird. Diese
werden in Form einer allgemeinen Beschreibung bereitgestellt.
15.5.1.2 Eingaben
b) die Funktionsspezifikation der abhängigen Komponente,
c) das Design der abhängigen Komponente,
d) die architektonische Gestaltung der abhängigen Komponente,
e) die Verlässlichkeitsinformationen.
Eine abhängige Komponente, deren TSF mit der Basiskomponente interagiert, erfordert Funktionalität, die
von dieser Basiskomponente bereitgestellt wird (z. B. Remote-Authentifizierung, Remote-Auditdaten-
speicherung). In diesen Fällen müssen die aufgerufenen Dienste für diejenigen beschrieben werden, die mit
der Konfiguration des zusammengesetzten TOEs für Endbenutzer beauftragt sind. Die Begründung für die
Anforderung dieser Dokumentation besteht darin, Integratoren des zusammengesetzten TOEs bei der
Bestimmung zu unterstützen, welche Dienste in der Basiskomponente nachteilige Auswirkungen auf die
abhängige Komponente haben könnten, und Informationen bereitzustellen, anhand derer die Kompatibilität
der Komponenten bei der Anwendung der Familie „Development evidence“ (ACO_DEV) festgelegt wird.
15.5.1.4 Aktion ACO_REL.1.1E
ISO/IEC 15408-3 ACO_REL.1.1C: Die Verlässlichkeitsinformationen müssen die Funktionalität der Hardware,
Firmware und/oder Software der Basiskomponente beschreiben, auf die sich die TSF der abhängigen
Komponente verlässt.
287
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
15.5.1.4.1 Workunit ACO_REL.1-1
Der Evaluator muss die Verlässlichkeitsinformationen prüfen, um festzustellen, dass sie die Funktionalität
der von der Basis abhängigen Hardware, Firmware und/oder Software beschreiben, auf die die TSF der
abhängigen Komponente angewiesen ist.
Der Evaluator beurteilt die Beschreibung der Sicherheitsfunktionalität, die für die TSF der abhängigen
Komponente durch die Hardware, Firmware und Software der Basiskomponente bereitgestellt werden muss.
Der Schwerpunkt dieser Workunit liegt auf dem Detaillierungsgrad dieser Beschreibung und nicht auf der
Beurteilung der Genauigkeit der Informationen. (Die Beurteilung der Genauigkeit der Informationen steht im
Mittelpunkt der nächsten Workunit.)
Diese Beschreibung der Funktionalität der Basiskomponente braucht nicht detaillierter zu sein als die Ebene
der Beschreibung einer Komponente der TSF, wie sie im „TOE design“ (ADV_TDS) vorgesehen ist.
Der Evaluator muss die Verlässlichkeitsinformationen untersuchen, um festzustellen, ob sie die für die
Betriebsumgebung der abhängigen Komponente festgelegten Zielsetzungen genau widerspiegeln.
Die Verlässlichkeitsinformationen enthalten die Beschreibung der Sicherheitsfunktionalität der Basis-

komponente, auf die die abhängige Komponente angewiesen ist. Um sicherzustellen, dass die Verlässlichkeits-
informationen gegenüber den Erwartungen der Betriebsumgebung der abhängigen Komponente konsistent
sind, vergleicht der Evaluator die Verlässlichkeitsinformationen mit den Zielsetzungen für die Umgebung in
der ST für die abhängige Komponente.
Wenn beispielsweise in den Verlässlichkeitsinformationen behauptet wird, dass die TSF der abhängigen
Komponente auf die Basiskomponente angewiesen ist, um Auditdaten zu speichern und zu schützen, aber
andere Evaluationsnachweise (z. B. das Design der abhängigen Komponente) deutlich machen, dass die TSF
der abhängigen Komponente selbst die Auditdaten speichert und schützt, würde dies auf eine Ungenauigkeit
hinweisen.
Es sollte beachtet werden, dass die Zielsetzungen für die Betriebsumgebung auch Zielsetzungen umfassen
können, die durch Nicht-IT-Maßnahmen erreicht werden können. Während die Dienste, die von der
Umgebung der Basiskomponente erwartet werden, in der Beschreibung der IT-Zielsetzungen für die Betriebs-
umgebung in der ST der abhängigen Komponente beschrieben werden können, ist es nicht erforderlich, dass
alle diese Erwartungen über die Umgebung in den Verlässlichkeitsinformationen beschrieben werden.
ISO/IEC 15408-3 ACO_REL.1.2C: Die Verlässlichkeitsinformationen müssen alle Interaktionen beschreiben,

durch die die TSF der abhängigen Komponente Dienste von der Basiskomponente anfragt.
Der Evaluator muss die Verlässlichkeitsinformationen untersuchen, um festzustellen, dass sie alle
Interaktionen zwischen der abhängigen Komponente und der Basiskomponente beschreiben, durch die die
TSF der abhängigen Komponente Dienste von der Basiskomponente anfragt.
Die TSF der abhängigen Komponente kann Dienste der Basiskomponente anfragen, die nicht innerhalb der
TSF der Basiskomponente lagen (siehe B.3 „Interaktionen zwischen zusammengesetzten IT-Entitäten“ in
ISO/IEC 15408-3).
Die Schnittstellen zur Funktionalität der Basiskomponente werden auf der gleichen Ebene beschrieben wie
die Beschreibung der Schnittstellen zur TSF-Funktionalität der abhängigen Komponente, wie sie zwischen
Teilsystemen im TOE-Design vorgesehen wären („Evaluation of sub-activity“ (ADV_TDS.1)).
288
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Zweck der Beschreibung der Interaktionen zwischen der abhängigen Komponente und der Basis-
komponente besteht darin, ein Verständnis dafür zu vermitteln, wie die TSF der abhängigen Komponente bei
der Bereitstellung von Diensten zur Unterstützung des Betriebs der Sicherheitsfunktionalität der abhängigen
Komponente auf die Basiskomponente angewiesen ist. Diese Interaktionen müssen nicht auf der
Implementierungsebene charakterisiert werden (z. B. Parameter, die von einer Routine in einer Komponente
an eine Routine in einer anderen Komponente übergeben werden), aber die für eine bestimmte Komponente
identifizierten Datenelemente, die von einer anderen Komponente verwendet werden sollen, sollten in dieser
Beschreibung abgedeckt werden. Die Aussage sollte dem Leser im Allgemeinen helfen zu verstehen, warum
die Interaktion notwendig ist.
Die Genauigkeit und Vollständigkeit der Schnittstellen basiert auf der Sicherheitsfunktionalität, die laut TSF
von der Basiskomponente bereitgestellt werden muss, wie in den Workunits ACO_REL.1-1 und ACO_REL.1-2
beurteilt. Es sollte möglich sein, die gesamte in den früheren Workunits beschriebene Funktionalität auf die
in dieser Workunit identifizierten Schnittstellen abzubilden und umgekehrt. Eine Schnittstelle, die nicht der
beschriebenen Funktionalität entspricht, würde ebenfalls auf eine Unzulänglichkeit hinweisen.
ISO/IEC 15408-3 ACO_REL.1.3C: Die Verlässlichkeitsinformationen müssen beschreiben, wie sich die abhängige
TSF vor Störungen und Eingriffen durch die Basiskomponente schützt.
Der Evaluator muss die Verlässlichkeitsinformationen untersuchen, um festzustellen, dass sie beschreiben,
wie sich die abhängige TSF vor Störungen und Eingriffen durch die Basiskomponente schützt.
Die Beschreibung, wie sich die abhängige Komponente vor Störungen und Eingriffen durch die Basis-
komponente schützt, ist in dem gleichen Detaillierungsgrad bereitzustellen wie für ADV_ARC.1-4 erforderlich.
15.5.2 Evaluierung der Unteraufgabe (ACO_REL.2)
Die Zielsetzungen dieser Unteraufgabe bestehen darin, festzulegen, ob der Verlässlichkeitsnachweis des
Entwicklers ausreichende Informationen liefert, um festzustellen, dass die erforderliche Funktionalität in der
Basiskomponente verfügbar ist, sowie die Mittel, mit denen diese Funktionalität aufgerufen wird. Dies wird
im Hinblick auf die Schnittstellen zwischen der abhängigen und der Basiskomponente und den
Rückgabewerten aus diesen Schnittstellen, die von der abhängigen Komponente aufgerufen werden,
bereitgestellt.
15.5.2.2 Eingaben

b) die Funktionsspezifikation der abhängigen Komponente,
c) das Design der abhängigen Komponente,
d) die Darstellung der Implementierung der abhängigen Komponente,
e) die architektonische Gestaltung der abhängigen Komponente,
f) die Verlässlichkeitsinformationen.
289
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Eine abhängige Komponente, deren TSF mit der Basiskomponente interagiert, erfordert Funktionalität, die
von dieser Basiskomponente bereitgestellt wird (z. B. Remote-Authentifizierung, Remote-Auditdaten-
speicherung). In diesen Fällen müssen die aufgerufenen Dienste für diejenigen beschrieben werden, die mit
der Konfiguration des zusammengesetzten TOEs für Endbenutzer beauftragt sind. Die Begründung für die
Anforderung dieser Dokumentation besteht darin, Integratoren des zusammengesetzten TOEs bei der
Bestimmung zu unterstützen, welche Dienste in der Basiskomponente nachteilige Auswirkungen auf die
abhängige Komponente haben könnten, und Informationen bereitzustellen, anhand derer die Kompatibilität
der Komponenten bei der Anwendung der Familie „Development evidence“ (ACO_DEV) festgelegt wird.
15.5.2.4 Aktion ACO_REL.2.1E
ISO/IEC 15408-3 ACO_REL.2.1C: Die Verlässlichkeitsinformationen müssen die Funktionalität der Hardware,
Firmware und/oder Software der Basiskomponente beschreiben, auf die sich die TSF der abhängigen
Komponente verlässt.
Der Evaluator muss die Verlässlichkeitsinformationen prüfen, um festzustellen, dass sie die Funktionalität
der von der Basis abhängigen Hardware, Firmware und/oder Software beschreiben, auf die die TSF der
abhängigen Komponente angewiesen ist.
Der Evaluator beurteilt die Beschreibung der Sicherheitsfunktionalität, die für die TSF der abhängigen
Komponente durch die Hardware, Firmware und Software der Basiskomponente bereitgestellt werden muss.
Der Schwerpunkt dieser Workunit liegt eher auf dem Detaillierungsgrad dieser Beschreibung als auf der
Beurteilung der Genauigkeit der Informationen. (Die Beurteilung der Genauigkeit der Informationen steht im
Mittelpunkt der nächsten Workunit.)
Diese Beschreibung der Funktionalität der Basiskomponente braucht nicht detaillierter zu sein als die Ebene
der Beschreibung einer Komponente der TSF, wie sie im „TOE design“ (ADV_TDS) vorgesehen ist.
Der Evaluator muss die Verlässlichkeitsinformationen untersuchen, um festzustellen, ob sie die für die
Betriebsumgebung der abhängigen Komponente festgelegten Zielsetzungen genau widerspiegeln.
Die Verlässlichkeitsinformationen enthalten die Beschreibung der Sicherheitsfunktionalität der Basis-

komponente, auf die die abhängige Komponente angewiesen ist. Um sicherzustellen, dass die Verlässlichkeits-
informationen gegenüber den Erwartungen der Betriebsumgebung der abhängigen Komponente konsistent
sind, vergleicht der Evaluator die Verlässlichkeitsinformationen mit den Zielsetzungen für die Umgebung in
der ST für die abhängige Komponente.
Wenn beispielsweise in den Verlässlichkeitsinformationen behauptet wird, dass die TSF der abhängigen
Komponente auf die Basiskomponente angewiesen ist, um Auditdaten zu speichern und zu schützen, aber
andere Evaluationsnachweise (z. B. das Design der abhängigen Komponente) deutlich machen, dass die TSF
der abhängigen Komponente selbst die Auditdaten speichert und schützt, würde dies auf eine Ungenauigkeit
hinweisen.
Es sollte beachtet werden, dass die Zielsetzungen für die Betriebsumgebung auch Zielsetzungen umfassen
können, die durch Nicht-IT-Maßnahmen erreicht werden können. Während die Dienste, die von der
Umgebung der Basiskomponente erwartet werden, in der Beschreibung der IT-Zielsetzungen für die Betriebs-
umgebung in der ST der abhängigen Komponente beschrieben werden können, ist es nicht erforderlich, dass
alle diese Erwartungen über die Umgebung in den Verlässlichkeitsinformationen beschrieben werden.
ISO/IEC 15408-3 ACO_REL.2.2C: Die Verlässlichkeitsinformationen müssen alle Interaktionen beschreiben,

durch die die TSF der abhängigen Komponente Dienste von der Basiskomponente anfragt.
290
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss die Verlässlichkeitsinformationen untersuchen, um festzustellen, dass sie alle
Interaktionen zwischen der abhängigen Komponente und der Basiskomponente beschreiben, durch die die
TSF der abhängigen Komponente Dienste von der Basiskomponente anfragt.
Die TSF der abhängigen Komponente kann Dienste der Basiskomponente anfragen, die nicht innerhalb der
TSF der Basiskomponente lagen (siehe B.3 „Interaktionen zwischen zusammengesetzten IT-Entitäten“ in
ISO/IEC 15408-3).
Die Schnittstellen zur Funktionalität der Basiskomponente werden auf der gleichen Ebene beschrieben wie
die Beschreibung der Schnittstellen zur TSF-Funktionalität der abhängigen Komponente, wie sie zwischen
Teilsystemen im TOE-Design vorgesehen wären („Evaluation of sub-activity“ (ADV_TDS.1)).
Der Zweck der Beschreibung der Interaktionen zwischen der abhängigen Komponente und der Basis-
komponente besteht darin, ein Verständnis dafür zu vermitteln, wie die TSF der abhängigen Komponente bei
der Bereitstellung von Diensten zur Unterstützung des Betriebs der Sicherheitsfunktionalität der abhängigen
Komponente auf die Basiskomponente angewiesen ist. Diese Interaktionen müssen nicht auf der
Implementierungsebene charakterisiert werden (z. B. Parameter, die von einer Routine in einer Komponente
an eine Routine in einer anderen Komponente übergeben werden), aber die für eine bestimmte Komponente
identifizierten Datenelemente, die von einer anderen Komponente verwendet werden sollen, sollten in dieser
Beschreibung abgedeckt werden. Die Aussage sollte dem Leser im Allgemeinen helfen zu verstehen, warum
die Interaktion notwendig ist.
Die Genauigkeit und Vollständigkeit der Schnittstellen basiert auf der Sicherheitsfunktionalität, die laut TSF
von der Basiskomponente bereitgestellt werden muss, wie in den Workunits ACO_REL.2-1 und ACO_REL.2-2
beurteilt. Es sollte möglich sein, die gesamte in den früheren Workunits beschriebene Funktionalität auf die
in dieser Workunit identifizierten Schnittstellen abzubilden und umgekehrt. Eine Schnittstelle, die nicht der
beschriebenen Funktionalität entspricht, würde ebenfalls auf eine Unzulänglichkeit hinweisen.
ISO/IEC 15408-3 ACO_REL.2.3C: Die Verlässlichkeitsinformationen müssen jede Interaktion in Bezug auf die
verwendete Schnittstelle und die Rückgabewerte dieser Schnittstellen beschreiben.
Die Verlässlichkeitsinformationen müssen jede Interaktion in Bezug auf die verwendete Schnittstelle und die
Rückgabewerte dieser Schnittstellen beschreiben.
Die Identifizierung der Schnittstellen, die von der TSF der abhängigen Komponente bei Dienstanfragen der
Basiskomponente verwendet werden, ermöglicht es einem Integrator festzustellen, ob die Basiskomponente
alle erforderlichen entsprechenden Schnittstellen bereitstellt. Dieses Verständnis wird durch die Angabe der
von der abhängigen Komponente erwarteten Rückgabewerte weiter vertieft. Der Evaluator stellt sicher, dass
für jede angegebene Interaktion Schnittstellen beschrieben werden (wie in ACO_REL.2-3 analysiert).
ISO/IEC 15408-3 ACO_REL.2.4C: Die Verlässlichkeitsinformationen müssen beschreiben, wie sich die abhängige
TSF vor Störungen und Eingriffen durch die Basiskomponente schützt.
Der Evaluator muss die Verlässlichkeitsinformationen untersuchen, um festzustellen, dass sie beschreiben,
wie sich die abhängige TSF vor Störungen und Eingriffen durch die Basiskomponente schützt.
Die Beschreibung, wie sich die abhängige Komponente vor Störungen und Eingriffen durch die Basis-
komponente schützt, ist in dem gleichen Detaillierungsgrad bereitzustellen wie für ADV_ARC.1-4 erforderlich.
291
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
15.6 Prüfen des zusammengesetzten TOEs (ACO_CTT)
15.6.1 Evaluierung der Unteraufgabe (ACO_CTT.1)
Die Zielsetzung dieser Unteraufgabe soll darin bestehen, festzustellen, ob der Entwickler für jede der
Schnittstellen der Basiskomponente, auf die die abhängige Komponente angewiesen ist, Prüfungen korrekt
durchgeführt und dokumentiert hat. Als Teil dieser Festlegung wiederholt der Evaluator eine Stichprobe der
vom Entwickler durchgeführten Prüfungen und führt alle zusätzlichen Prüfungen durch, die erforderlich sind,
um sicherzustellen, dass das erwartete Verhalten aller SFRs des zusammengesetzten TOEs und Schnittstellen
der Basiskomponente, auf die die abhängige Komponente angewiesen ist, nachgewiesen wird.
15.6.1.2 Eingaben
a) der zum Prüfen geeignete zusammengesetzte TOE,
b) der Prüfnachweis des zusammengesetzten TOEs,
d) die Entwicklungsinformationen.
15.6.1.3 Aktion ACO_CTT.1.1E
ISO/IEC 15408-3 ACO_CTT.1.1C: Die Prüfdokumentation für den zusammengesetzten TOE und die Schnittstellen
der Basiskomponente muss aus Prüfplänen, erwarteten Prüfergebnissen und tatsächlichen Prüfergebnissen
bestehen.
15.6.1.3.1 Workunit ACO_CTT.1-1
Der Evaluator muss die Prüfdokumentation für den zusammengesetzten TOE untersuchen, um festzustellen,
dass sie aus Prüfplänen, erwarteten Prüfergebnissen und tatsächlichen Prüfergebnissen besteht.
Diese Workunit kann durch die Bereitstellung der Prüfnachweise aus der Evaluierung der abhängigen
Komponente erfüllt werden, wenn die Basiskomponente verwendet wurde, um die Anforderungen an die IT
in der Betriebsumgebung der abhängigen Komponente zu erfüllen.
Alle Workunits, die zur Erfüllung von ATE_FUN.1.1E notwendig sind, werden herangezogen um festzulegen,
a) dass die Prüfdokumentation aus Prüfplänen, erwarteten Prüfergebnissen und tatsächlichen Prüf-
ergebnissen besteht,
b) dass die Prüfdokumentation die notwendigen Informationen enthält, um die Wiederholbarkeit der
Prüfungen sicherzustellen,
c) den Entwickleraufwand, der für das Prüfen der Basiskomponente aufgewendet wurde.
292
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss die Prüfdokumentation für die Schnittstelle der Basiskomponente untersuchen, um
festzustellen, dass sie aus Prüfplänen, erwarteten Prüfergebnissen und tatsächlichen Prüfergebnissen besteht.
Diese Workunit kann durch die Bereitstellung der Prüfnachweise aus der Evaluierung der Basiskomponente
für diejenigen Schnittstellen, auf die die abhängige Komponente im zusammengesetzten TOE angewiesen ist,
erfüllt werden, die TSFIs der erfolgreich evaluierten Basiskomponente sind. Die Festlegung, ob die
Schnittstellen der Basiskomponente, auf die die abhängige Komponente angewiesen ist, tatsächlich TSFIs der
evaluierten Basiskomponente waren, wird während der Aufgabe ACO_COR vorgenommen.
Alle Workunits, die zur Erfüllung von ATE_FUN.1.1E notwendig sind, werden herangezogen um festzustellen,
ISO/IEC 15408-3 ACO_CTT.1.2C: Die Prüfdokumentation von der Durchführung der Prüfungen des zusammen-
gesetzten TOEs durch den Entwickler muss nachweisen, dass sich die TSF entsprechend der Spezifikation verhält.
Der Evaluator muss die Prüfdokumentation untersuchen, um festzustellen, dass die Durchführung der
Prüfungen des zusammengesetzten TOEs durch den Entwickler nachweisen muss, dass sich die TSF wie
festgelegt verhält.
Der Evaluator sollte eine Zuordnung zwischen den im Prüfplan beschriebenen Prüfungen und den für den
zusammengesetzten TOE spezifizierten SFRs erstellen, um festzustellen, welche SFRs vom Entwickler geprüft
wurden.
a) 13.2.1,
b) 13.2.2.
Die Ergebnisse der erfolgreichen Ausführung der Prüfungen (wie für ATE_FUN.1.3C beurteilt) können mit der
Zuordnung verglichen werden, um festzustellen, dass sich die SFRs des zusammengesetzten TOE, wie vom
Entwickler geprüft, wie erwartet verhalten.
ISO/IEC 15408-3 ACO_CTT.1.3C: Die Prüfdokumentation von der Durchführung der Prüfungen des zusammen-
gesetzten TOEs durch den Entwickler muss nachweisen, dass sich die Schnittstelle der Basiskomponente, auf die
sich die abhängige Komponente verlässt, entsprechend der Spezifikation verhält.
Der Evaluator muss die Prüfdokumentation untersuchen, um festzustellen, dass die Ausführung der
Prüfungen für die Schnittstellen der Basiskomponente durch den Entwickler nachweisen muss, dass sich die
Schnittstellen der Basiskomponente, auf die die abhängige Komponente angewiesen ist, wie angegeben
verhalten.
293
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator sollte eine Zuordnung zwischen den im Prüfplan beschriebenen Prüfungen und den
Schnittstellen der Basiskomponente erstellen, auf die die abhängige Komponente angewiesen ist (wie in den
unter ACO_REL untersuchten Verlässlichkeitsinformationen festgelegt), um festzustellen, welche Schnitt-
stellen der Basiskomponente vom Entwickler geprüft wurden.
a) 13.2.1,
b) 13.2.2.
Zuordnung verglichen werden, um festzustellen, dass sich die Schnittstellen der Basiskomponente, wie vom
ISO/IEC 15408-3 ACO_CTT.1.4C: Die Basiskomponente muss zum Prüfen geeignet sein.
Der Evaluator muss den zusammengesetzten TOE untersuchen, um festzustellen, dass er ordnungsgemäß
installiert wurde und sich in einem bekannten Zustand befindet.
Um festzustellen, dass der zusammengesetzte TOE ordnungsgemäß installiert wurde und sich in einem
bekannten Zustand befindet, werden die Workunits ATE_IND.2-1 und ATE_IND.2-2 auf den vom Entwickler
zum Prüfen bereitgestellten TOE angewendet.
Der Evaluator muss die vom Entwickler zur Verfügung gestellten Ressourcen untersuchen, um festzustellen,
ob sie mit den Ressourcen übereinstimmen, die der Entwickler der Basiskomponente für die Funktions-
prüfung der Basiskomponente verwendet.
Um festzustellen, dass die Menge der zur Verfügung gestellten Ressourcen derjenigen entspricht, die zum
funktionellen Prüfen der wie im zusammengesetzten TOE eingesetzten Basiskomponente verwendet wird,
wird Workunit ATE_IND.2-3 angewandt.
Der Evaluator muss die Prüfung in Übereinstimmung mit ATE_IND.2.2E für eine Teilmenge der SFRs, die in
den zusammengestellten Sicherheitsvorgaben festgelegt sind, durchführen, um die Prüfergebnisse des
Entwicklers zu überprüfen.
Der Evaluator wendet alle Workunits an, die für die Erfüllung von ATE_IND.2.2E erforderlich sind, und
berichtet im ETR für den zusammengesetzten TOE über alle Analysen, Ergebnisse und Entscheidungen, wie
von den zugehörigen Workunits vorgegeben.
den zusammengestellten Sicherheitsvorgaben festgelegt sind, durchführen, um zu bestätigen, dass die TSF
wie angegeben funktioniert.
294
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
von den Workunits vorgegeben.
Bei der Auswahl der Schnittstellen der TSF des zusammengesetzten TOE, der geprüft werden soll, sollte der
Evaluator alle Änderungen an den Komponenten aus der evaluierten Version oder Konfiguration
berücksichtigen. Änderungen an der Komponente gegenüber der evaluierten Komponente können
eingeführte Patches, eine andere Konfiguration infolge geänderter Leitliniendokumente, die Abhängigkeit von
einem zusätzlichen Teil der Komponente, der nicht innerhalb der TSF der Komponente lag, umfassen. Diese
Änderungen werden während der Aufgabe „Composition rationale“ (ACO_COR) identifiziert worden sein.
15.6.2 Evaluierung der Unteraufgabe (ACO_CTT.2)
Die Zielsetzung dieser Unteraufgabe soll darin bestehen, festzustellen, ob der Entwickler für jede der
Schnittstellen der Basiskomponente, auf die die abhängige Komponente angewiesen ist, Prüfungen korrekt
durchgeführt und dokumentiert hat. Als Teil dieser Festlegung wiederholt der Evaluator eine Stichprobe der
vom Entwickler durchgeführten Prüfungen und führt alle zusätzlichen Prüfungen durch, die erforderlich sind,
um vollständig das erwartete Verhalten des zusammengesetzten TOEs und der Schnittstellen der
Basiskomponente, auf die die abhängige Komponente angewiesen ist, aufzuzeigen.
15.6.2.2 Eingaben
b) der Prüfnachweis des zusammengesetzten TOE,
d) die Entwicklungsinformationen.
ISO/IEC 15408-3 ACO_CTT.2.1C: Die Prüfdokumentation für den zusammengesetzten TOE und die Schnittstellen
der Basiskomponente muss aus Prüfplänen, erwarteten Prüfergebnissen und tatsächlichen Prüfergebnissen
bestehen.
Der Evaluator muss die Prüfdokumentation für den zusammengesetzten TOE untersuchen, um festzustellen,
dass sie aus Prüfplänen, erwarteten Prüfergebnissen und tatsächlichen Prüfergebnissen besteht.
Diese Workunit kann durch die Bereitstellung der Prüfnachweise aus der Evaluierung der abhängigen
Komponente erfüllt werden, wenn die Basiskomponente verwendet wurde, um die Anforderungen an die IT
in der Betriebsumgebung der abhängigen Komponente zu erfüllen.
Alle Workunits, die zur Erfüllung von ATE_FUN.1.1E notwendig sind, werden herangezogen um festzustellen,
295
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss die Prüfdokumentation für die Schnittstelle der Basiskomponente untersuchen, um
festzustellen, dass sie aus Prüfplänen, erwarteten Prüfergebnissen und tatsächlichen Prüfergebnissen besteht.
Diese Workunit kann durch die Bereitstellung der Prüfnachweise aus der Evaluierung der Basiskomponente
für diejenigen Schnittstellen, auf die die abhängige Komponente im zusammengesetzten TOE angewiesen ist,
erfüllt werden, die TSFIs der erfolgreich evaluierten Basiskomponente sind. Die Festlegung, ob die
Schnittstellen der Basiskomponente, auf die die abhängige Komponente angewiesen ist, tatsächlich TSFIs der
evaluierten Basiskomponente waren, wird während der Aufgabe ACO_COR vorgenommen.
Alle Workunits, die zur Erfüllung von ATE_FUN.1.1E notwendig sind, werden herangezogen um festzustellen
ISO/IEC 15408-3 ACO_CTT.2.2C: Die Prüfdokumentation von der Durchführung der Prüfungen des
zusammengesetzten TOEs durch den Entwickler muss nachweisen, dass sich die TSF entsprechend der
Spezifikation verhält und vollständig ist.
Der Evaluator muss die Prüfdokumentation untersuchen, um festzustellen, dass sie eine genaue Überein-
stimmung zwischen den Prüfungen in der Prüfdokumentation, die sich auf das Prüfen des zusammengesetzten
TOEs bezieht, und den SFRs des zusammengesetzten TOEs in den Sicherheitsvorgaben des
zusammengesetzten TOEs enthält.
der Übereinstimmung zwischen den Prüfungen und den in der Prüfdokumentation dargestellten SFRs muss
eindeutig sein.
Der Evaluator muss die Prüfdokumentation untersuchen, um festzustellen, dass die Durchführung der
Prüfungen des zusammengesetzten TOEs durch den Entwickler nachweisen muss, dass sich die TSF wie
festgelegt verhält.
a) 13.2.1,
b) 13.2.2.
Zuordnung verglichen werden, um festzustellen, dass sich die SFRs des zusammengesetzten TOE, wie vom
ISO/IEC 15408-3 ACO_CTT.2.3C: Die Prüfdokumentation von der Durchführung der Prüfungen des
zusammengesetzten TOEs durch den Entwickler muss nachweisen, dass sich die Schnittstelle der
Basiskomponente, auf die sich die abhängige Komponente verlässt, entsprechend der Spezifikation verhält und
vollständig ist.
296
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator muss die Prüfdokumentation untersuchen, um festzustellen, dass sie eine genaue Überein-
stimmung zwischen den Prüfungen in der Prüfdokumentation in Bezug auf das Prüfen der Schnittstellen der
Basiskomponente, auf die die abhängige Komponente angewiesen ist, und den in den
Verlässlichkeitsinformationen angegebenen Schnittstellen aufweist.
der Übereinstimmung zwischen den Prüfungen und den in der Prüfdokumentation dargestellten
Schnittstellen muss eindeutig sein.
Der Evaluator muss die Prüfdokumentation untersuchen, um festzustellen, dass die Ausführung der
Prüfungen für die Schnittstellen der Basiskomponente durch den Entwickler nachweisen muss, dass sich die
Schnittstellen der Basiskomponente, auf die die abhängige Komponente angewiesen ist, wie angegeben
verhalten.
a) 13.2.1,
b) 13.2.2.
Zuordnung verglichen werden, um festzustellen, dass sich die Schnittstellen der Basiskomponente, wie vom
ISO/IEC 15408-3 ACO_CTT.2.4C: Die Basiskomponente muss zum Prüfen geeignet sein.
bekannten Zustand befindet, werden die Workunits ATE_IND.2-1 und ATE_IND.2-2 auf den vom Entwickler
zum Prüfen bereitgestellten TOE angewendet.
Der Evaluator muss die vom Entwickler zur Verfügung gestellten Ressourcen untersuchen, um festzustellen,
ob sie mit den Ressourcen übereinstimmen, die der Entwickler der Basiskomponente für die Funktions-
prüfung der Basiskomponente verwendet.
Um festzustellen, dass die Menge der zur Verfügung gestellten Ressourcen derjenigen entspricht, die zum
funktionellen Prüfen der wie im zusammengesetzten TOE eingesetzten Basiskomponente verwendet wird,
wird Workunit ATE_IND.2-3 angewandt.
Die Prüfungen sind in Übereinstimmung mit ATE_IND.2.2E auszuwählen und durchzuführen, um das korrekte
Verhalten der in den Sicherheitsvorgaben des TOEs spezifizierten SFRs nachzuweisen.
297
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
von den zugehörigen Workunits vorgegeben.
den zusammengestellten Sicherheitsvorgaben festgelegt sind, durchführen, um zu bestätigen, dass die TSF
wie angegeben funktioniert.
Bei der Auswahl der Schnittstellen der TSF des zusammengesetzten TOE, der geprüft werden soll, sollte der
Evaluator alle Änderungen an den Komponenten aus der evaluierten Version oder Konfiguration
berücksichtigen. Änderungen an der Komponente gegenüber der evaluierten Komponente können
eingeführte Patches, eine andere Konfiguration infolge geänderter Leitliniendokumente, die Abhängigkeit von
einem zusätzlichen Teil der Komponente, der nicht innerhalb der TSF der Komponente lag, umfassen. Diese
Änderungen werden während der Aufgabe „Begründung der Zusammensetzung (ACO_COR)“ identifiziert
worden sein.
Der Evaluator muss die Prüfung in Übereinstimmung mit der „Evaluation of sub-activity“ (ATE_IND.2) für eine
Teilmenge der Schnittstellen für die Basiskomponente durchführen, um zu bestätigen, dass sie wie festgelegt
funktionieren.
Bei der Auswahl der Schnittstellen der zu prüfenden Basiskomponente sollte der Evaluator alle Änderungen
an der Basiskomponente aus der evaluierten Version oder Konfiguration berücksichtigen. Insbesondere sollte
der Evaluator die Entwicklung von Prüfungen in Betracht ziehen, um das korrekte Verhalten von
Schnittstellen der Basiskomponente nachzuweisen, die bei der Evaluierung der Basiskomponente nicht
berücksichtigt wurden. Diese zusätzlichen Schnittstellen und andere Änderungen an der Basiskomponente
werden während der Aufgabe „Begründung der Zusammensetzung (ACO_COR)“ identifiziert worden sein.
15.7 Anfälligkeitsanalyse der Zusammensetzung (ACO_VUL)

15.7.1 Evaluierung der Unteraufgabe (ACO_VUL.1)
Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob der zusammengesetzte TOE in seiner
Betriebsumgebung leicht ausnutzbare Anfälligkeiten aufweist.
Der Entwickler gibt Einzelheiten über alle verbleibenden Anfälligkeiten an, die aus der Evaluierung der
Komponenten gemeldet wurden. Der Evaluator führt eine Analyse der Verwendung der gemeldeten
Restanfälligkeiten durch und sucht auch im öffentlichen Bereich nach neuen potentiellen Anfälligkeiten in den
Komponenten (d. h. den Problemen, die seit der Evaluierung der Basiskomponente im öffentlichen Bereich
gemeldet wurden). Der Evaluator führt dann Penetrationstests durch, um nachzuweisen, dass die potentiellen
Anfälligkeiten im TOE in seiner Betriebsumgebung nicht von einem Angreifer mit niedrigem Angriffspotential
ausgenutzt werden können.
298
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
15.7.1.2 Eingaben
b) die zusammengesetzte ST,
c) die Begründung der Zusammensetzung,
d) die Leitliniendokumentation,
e) öffentlich zugängliche Informationen zur Unterstützung der Identifizierung möglicher Sicherheits-

anfälligkeiten,
f) verbleibende Anfälligkeiten, die bei der Evaluierung jeder Komponente gemeldet werden.
Siehe die Anwendungshinweise für „Evaluation of sub-activity“ (AVA_VAN.1).
15.7.1.4 Aktion ACO_VUL.1.1E
ISO/IEC 15408-3 ACO_VUL.1.1C: Der zusammengesetzte TOE muss zum Prüfen geeignet sein.
15.7.1.4.1 Workunit ACO_VUL.1-1
bekannten Zustand befindet, werden die Workunits ATE_IND.2-1 und ATE_IND.2-2 auf den zusammen-
gesetzten TOE angewendet.
Wenn das Sicherheitspaket eine Komponente aus der Familie ACO_CTT enthält, kann der Evaluator auf das
Ergebnis der Workunit ACO_CTT*-1 zurückgreifen, um nachzuweisen, dass dies erfüllt ist.
Der Evaluator muss die Konfiguration des zusammengesetzten TOEs untersuchen, um festzustellen, dass alle
Annahmen und Zielsetzungen in den STs, bei denen sich die Komponenten auf IT-Entitäten beziehen, von den
anderen Komponenten erfüllt werden.
Die STs für die Komponente können Annahmen über andere Komponenten enthalten, die die Komponente,
auf die sich die ST bezieht, verwenden können, z. B. kann die ST für ein Betriebssystem, das als Basis-
komponente verwendet wird, eine Annahme enthalten, dass alle auf dem Betriebssystem geladenen
Anwendungen nicht im Berechtigungsmodus laufen. Diese Annahmen und Zielsetzungen sollen durch andere
Komponenten des zusammengesetzten TOEs erfüllt werden.
Der Evaluator muss die Restanfälligkeiten aus der Evaluierung der Basiskomponente untersuchen, um
festzustellen, dass sie im zusammengesetzten TOE in ihrer Betriebsumgebung nicht ausnutzbar sind.
299
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Die Liste der im Produkt während der Evaluierung der Basiskomponente identifizierten Anfälligkeiten, die
sich in der Basiskomponente als nicht ausnutzbar erwiesen haben, ist als Eingabe für diese Aufgabe zu
verwenden. Der Evaluator stellt fest, dass die Voraussetzung(en), unter der/denen eine Anfälligkeit als nicht
ausnutzbar erachtet wurde, im zusammengesetzten TOE aufrechterhalten wird, oder ob die Kombination die
potentielle Anfälligkeit wieder eingebracht hat. Wenn bei der Evaluierung der Basiskomponente
beispielsweise angenommen wurde, dass ein bestimmter Dienst des Betriebssystems deaktiviert wurde, der
in der Evaluierung des zusammengesetzten TOEs aktiviert wird, sollten nun alle potentiellen Anfälligkeiten in
Bezug auf diesen Dienst, die zuvor ausgeblendet wurden, berücksichtigt werden.
Außerdem sollte diese Liste bekannter, nicht ausnutzbarer Anfälligkeiten, die sich aus der Evaluierung der
Basiskomponente ergibt, im Lichte aller bekannten, nicht ausnutzbaren Anfälligkeiten für die anderen
Komponenten (z. B. abhängige Komponente) innerhalb des zusammengesetzten TOEs betrachtet werden.
Dabei ist der Fall zu berücksichtigen, dass eine potentielle Anfälligkeit, die isoliert nicht ausnutzbar ist,
ausnutzbar ist, wenn sie mit einer IT-Entität integriert ist, die eine andere potentielle Anfälligkeit enthält.
Der Evaluator muss die Restanfälligkeiten aus der Evaluierung der abhängigen Komponente untersuchen, um
Die Liste der im Produkt während der Evaluierung der abhängigen Komponente identifizierten Anfälligkeiten,
die sich in der abhängigen Komponente als nicht ausnutzbar erwiesen haben, ist als Eingabe für diese Aufgabe
zu verwenden. Der Evaluator stellt fest, dass die Voraussetzung(en), unter der/denen eine Anfälligkeit als
nicht ausnutzbar erachtet wurde, im zusammengesetzten TOE aufrechterhalten wird, oder ob die
Kombination die potentielle Anfälligkeit wieder eingebracht hat. Wenn bei der Evaluierung der abhängigen
Komponente beispielsweise angenommen wurde, dass die IT, die die Anforderungen der Betriebsumgebung
erfüllt, als Antwort auf eine Dienstanfrage, die von der Basiskomponente in der Evaluierung des
zusammengesetzten TOEs bereitgestellt wird, keinen bestimmten Wert zurückgeben würde, sollten nun alle
potentiellen Anfälligkeiten in Bezug auf diesen Rückgabewert, die zuvor ausgeblendet wurden, berücksichtigt
werden.
abhängigen Komponente ergibt, im Lichte aller bekannten, nicht ausnutzbaren Anfälligkeiten für die anderen
Komponenten (z. B. Basiskomponente) innerhalb des zusammengesetzten TOEs betrachtet werden. Dabei ist
der Fall zu berücksichtigen, dass eine potentielle Anfälligkeit, die isoliert nicht ausnutzbar ist, ausnutzbar ist,
wenn sie mit einer IT-Entität integriert ist, die eine andere potentielle Anfälligkeit enthält.
Der Evaluator muss die öffentlich zugänglichen Informationsquellen zur Unterstützung der Identifizierung
möglicher Sicherheitsanfälligkeiten in der Basiskomponente untersuchen, die seit dem Abschluss der
Evaluierung der Basiskomponente bekannt geworden sind.
Der Evaluator wird die Informationen im öffentlichen Bereich, wie in AVA_VAN.1-2 beschrieben, verwenden,
um nach Anfälligkeiten in der Basiskomponente zu suchen.
Diejenigen potentiellen Anfälligkeiten, die vor der Evaluierung der Basiskomponente öffentlich zugänglich
waren, müssen nicht weiter untersucht werden, es sei denn, es ist für den Evaluator offensichtlich, dass das
Angriffspotential, das ein Angreifer benötigt, um die potentielle Anfälligkeit auszunutzen, erheblich reduziert
wurde. Dies kann durch die Einführung einiger neuer Technologien geschehen, da die Evaluierung der
Basiskomponente, die die Ausnutzung der potentiellen Anfälligkeit bedeutet, vereinfacht wurde.
300
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
möglicher Sicherheitsanfälligkeiten in der abhängigen Komponente untersuchen, die seit dem Abschluss der
Evaluierung der abhängigen Komponente bekannt geworden sind.
um nach Anfälligkeiten in der abhängigen Komponente zu suchen.
Diejenigen potentiellen Anfälligkeiten, die vor der Evaluierung der abhängigen Komponente öffentlich
zugänglich waren, müssen nicht weiter untersucht werden, es sei denn, es ist für den Evaluator offensichtlich,
dass das Angriffspotential, das ein Angreifer benötigt, um die potentielle Anfälligkeit auszunutzen, erheblich
reduziert wurde. Dies kann durch die Einführung einiger neuer Technologien geschehen, da die Evaluierung
der abhängigen Komponente, die die Ausnutzung der potentiellen Anfälligkeit bedeutet, vereinfacht wurde.
Der Evaluator muss im ETR die identifizierten potentiellen Sicherheitsanfälligkeiten aufzeichnen, die für
Prüfungen geeignet und auf den zusammengesetzten TOE in seiner Betriebsumgebung anwendbar sind.
Die ST, die Leitliniendokumentation und die Funktionsspezifikation werden verwendet, um festzustellen, ob
die Anfälligkeiten für den zusammengesetzten TOE in seiner Betriebsumgebung relevant sind.
Der Evaluator zeichnet alle Gründe für den Ausschluss von Anfälligkeiten aus der weiteren Betrachtung auf,
wenn er feststellt, dass die Anfälligkeit in der Betriebsumgebung nicht anwendbar ist. Andernfalls zeichnet
der Evaluator die potentielle Anfälligkeit zur weiteren Betrachtung auf.
als Eingabe für Penetrationstestaufgaben (d. h. ACO_VUL.1.4E) verwendet werden können, muss von den
Evaluatoren im ETR gemeldet werden.
Der Evaluator muss Penetrationstests durchführen, wie für AVA_VAN.1.3E ausführlich beschrieben.
Der Evaluator wendet alle Workunits an, die für die Erfüllung der Evaluatorenaktion AVA_VAN.1.3E
erforderlich sind, und berichtet im ETR für den zusammengesetzten TOE über alle Analysen, Ergebnisse und
Entscheidungen, wie von den Workunits vorgegeben.
Der Evaluator wendet auch die Workunits für die Evaluatorenaktion AVA_VAN.1.1E an, um festzustellen, ob
der vom Entwickler bereitgestellte zusammengesetzte TOE zum Prüfen geeignet ist.
Betriebsumgebung Anfälligkeiten aufweist, die von Angreifern mit einem niedrigen Angriffspotential
Der Entwickler liefert eine Analyse der Disposition der für die Komponenten gemeldeten Restanfälligkeiten
und der durch die Kombination der Basis- und abhängigen Komponenten eingeführten Anfälligkeiten. Der
Evaluator sucht im öffentlichen Bereich nach neuen potentiellen Anfälligkeiten in den Komponenten (d. h. den
Problemen, die seit Abschluss der Evaluierung der Komponenten im öffentlichen Bereich gemeldet wurden).
Der Evaluator wird auch eine unabhängige Anfälligkeitsanalyse des zusammengesetzten TOEs und
Penetrationstests durchführen.
301
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
15.7.2.2 Eingaben

d) die Verlässlichkeitsinformationen,
f) öffentlich zugängliche Informationen zur Unterstützung der Identifizierung möglicher Sicherheits-
anfälligkeiten,
g) verbleibende Anfälligkeiten, die bei der Evaluierung jeder Komponente gemeldet werden.
Wenn das Sicherheitspaket eine Familie ACO_CTT enthält, kann der Evaluator auf das Ergebnis der Workunit
„Composed TOE testing“ (ACO_CTT)*-1 zurückgreifen, um nachzuweisen, dass dies erfüllt ist.
302
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Komponente beispielsweise angenommen wurde, dass die IT, die die Anfragen der Betriebsumgebung erfüllt,
als Antwort auf eine Dienstanforderung, die von der Basiskomponente in der Evaluierung des
werden.
303
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
möglicher Sicherheitsanfälligkeiten in der abhängigen Komponente untersuchen, die seit dem Abschluss der
Eine Liste potentieller Anfälligkeiten, die auf den zusammengesetzten TOE in seiner Betriebsumgebung
anwendbar sind und die als Eingabe für Penetrationstestaufgaben (ACO_VUL.2.5E) verwendet werden
können, muss von den Evaluatoren im ETR gemeldet werden.
Der Evaluator muss eine Suche in der zusammengesetzten TOE-ST, in der Leitliniendokumentation, in den
Verlässlichkeitsinformationen und in der Begründung für die Zusammensetzung durchführen, um mögliche
Sicherheitsanfälligkeiten im zusammengesetzten TOE zu ermitteln.
Die Berücksichtigung der Komponenten des zusammengesetzten TOEs bei der Anfälligkeitsanalyse durch den
unabhängigen Evaluator wird eine etwas andere Form annehmen als die in AVA_VAN.2.3E dokumentierte bei
einer Komponentenevaluierung, da nicht unbedingt alle für das Sicherheitspaket relevanten Ebenen der
Designabstraktion berücksichtigt werden. Diese werden bereits bei der Evaluierung der Komponenten
berücksichtigt worden sein, aber die Nachweise stehen für die Evaluierung des zusammengesetzten TOEs
möglicherweise nicht zur Verfügung. Der allgemeine Ansatz, der in der mit AVA_VAN.2.3E verbundenen
Workunit beschrieben wird, ist jedoch anwendbar und sollte die Grundlage für die Suche des Evaluators nach
potentiellen Anfälligkeiten im zusammengesetzten TOE bilden.
Eine Anfälligkeitsanalyse der einzelnen im zusammengesetzten TOE verwendeten Komponenten wird bereits
während der Evaluierung der einzelnen Komponenten durchgeführt worden sein. Der Schwerpunkt der
Anfälligkeitsanalyse während der Evaluierung des zusammengesetzten TOEs besteht darin, alle Anfälligkeiten
zu identifizieren, die als Ergebnis der Integration der Komponenten oder aufgrund von Änderungen in der
Verwendung der Komponenten zwischen der evaluierten Komponentenkonfiguration und der Konfiguration
des zusammengesetzten TOEs eingeführt wurden.
304
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der Evaluator verwendet das Verständnis für die Konstruktion der Komponente, wie es in den Verlässlich-
keitsinformationen für die abhängige Komponente beschrieben ist, sowie die Entwicklungsinformationen und
die Begründung der Zusammensetzung für die Basiskomponente zusammen mit den Designinformationen der
abhängigen Komponente. Diese Informationen ermöglichen es dem Evaluator, ein Verständnis dafür zu
gewinnen, wie die Basiskomponente und die abhängige Komponente zusammenwirken, und potentielle
Anfälligkeiten zu identifizieren, die sich aus dieser Interaktion ergeben können.
Der Evaluator wird alle neuen Leitlinien berücksichtigen, die für die Installation, die Inbetriebnahme und den
Betrieb des zusammengesetzten TOEs bereitgestellt werden, um alle potentiellen Anfälligkeiten zu identifi-
zieren, die durch diese überarbeiteten Leitlinien eingeführt werden.
Wenn eine der einzelnen Komponenten seit dem Abschluss der Komponentenevaluierung Aufgaben zur
Zusicherung der kontinuierlichen Vertrauenswürdigkeit durchlaufen hat, wird der Evaluator den/die
Patch(es) in der unabhängigen Anfälligkeitsanalyse berücksichtigen. Informationen im Zusammenhang mit
der Änderung, die in einem öffentlichen Bericht über die Aufgaben zur Zusicherung der kontinuierlichen
Vertrauenswürdigkeit (z. B. Wartungsbericht) bereitgestellt werden, werden die Hauptquelle für das
Eingabematerial der Änderung sein. Dies wird ergänzt durch alle Aktualisierungen der Leitlinien-
dokumentation, die sich aus der Änderung ergeben, und alle Informationen über die Änderung, die im
öffentlichen Bereich, z. B. auf der Website des Anbieters, verfügbar sind.
Jegliche Risiken, die aufgrund mangelnder Nachweise zur Feststellung der vollen Auswirkung von Patches
oder Abweichungen in der Konfiguration einer Komponente von der evaluierten Konfiguration identifiziert
werden, sind in der Anfälligkeitsanalyse des Evaluators zu dokumentieren.
Betriebsumgebung Anfälligkeiten aufweist, die von Angreifern mit einem Angriffspotential Enhanced-Basic
Der Entwickler liefert eine Analyse der Disposition der für die Komponenten gemeldeten Restanfälligkeiten
und der durch die Kombination der Basis- und abhängigen Komponenten eingeführten Anfälligkeiten. Der
Evaluator sucht im öffentlichen Bereich nach neuen potentiellen Anfälligkeiten in den Komponenten (d. h. den
Problemen, die seit Abschluss der Evaluierungen der Komponenten im öffentlichen Bereich gemeldet
wurden). Der Evaluator wird auch eine unabhängige Anfälligkeitsanalyse des zusammengesetzten TOEs und
Penetrationstests durchführen.
305
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
15.7.3.2 Eingaben
d) die Verlässlichkeitsinformationen,
f) öffentlich zugängliche Informationen zur Unterstützung der Identifizierung möglicher Sicherheits-

anfälligkeiten,
g) verbleibende Anfälligkeiten, die bei der Evaluierung jeder Komponente gemeldet werden.
Wenn das Sicherheitspaket eine Familie ACO_CTT enthält, kann der Evaluator auf das Ergebnis der Workunit
„Composed TOE testing“ (ACO_CTT)*-1 zurückgreifen, um nachzuweisen, dass dies erfüllt ist.
306
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Komponente beispielsweise angenommen wurde, dass die IT, die die Anforderungen der Betriebsumgebung
erfüllt, als Antwort auf eine Dienstanfrage, die von der Basiskomponente in der Evaluierung des
werden.
307
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
möglicher Sicherheitsanfälligkeiten in der abhängigen Komponente untersuchen, die seit Abschluss der
Eine Liste potentieller Anfälligkeiten, die auf den zusammengesetzten TOE in seiner Betriebsumgebung
anwendbar sind und die als Eingabe für Penetrationstestaufgaben (ACO_VUL.3.5E) verwendet werden
können, muss von den Evaluatoren im ETR gemeldet werden.
Der Evaluator muss eine Suche in der zusammengesetzten TOE-ST, in der Leitliniendokumentation, in den
Verlässlichkeitsinformationen und in der Begründung für die Zusammensetzung durchführen, um mögliche
Sicherheitsanfälligkeiten im zusammengesetzten TOE zu ermitteln.
Die Berücksichtigung der Komponenten bei der Anfälligkeitsanalyse durch den unabhängigen Evaluator wird
eine etwas andere Form annehmen als die in AVA_VAN.3.3E dokumentierte bei einer Komponenten-
evaluierung, da nicht unbedingt alle für das Sicherheitspaket relevanten Ebenen der Designabstraktion
berücksichtigt werden. Diese werden bereits bei der Evaluierung der Basiskomponente berücksichtigt
worden sein, aber die Nachweise stehen für die Evaluierung des zusammengesetzten TOEs möglicherweise
nicht zur Verfügung. Der allgemeine Ansatz, der in der mit AVA_VAN.3.3E verbundenen Workunit beschrieben
wird, ist jedoch anwendbar und sollte die Grundlage für die Suche des Evaluators nach potentiellen
Anfälligkeiten im zusammengesetzten TOE bilden.
308
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Eine Anfälligkeitsanalyse der einzelnen im zusammengesetzten TOE verwendeten Komponenten wird bereits
während der Evaluierung der Komponenten durchgeführt worden sein. Der Schwerpunkt der Anfälligkeits-
analyse während der Evaluierung des zusammengesetzten TOEs besteht darin, alle Anfälligkeiten zu
identifizieren, die als Ergebnis der Integration der Komponenten oder aufgrund von Änderungen bei der
Verwendung der Komponenten zwischen der während der Komponentenevaluierung ermittelten Konfigu-
ration der Komponente und der Konfiguration des zusammengesetzten TOEs eingeführt wurden.
Der Evaluator verwendet das Verständnis für die Konstruktion der Komponente, wie es in den Verlässlich-
keitsinformationen für die abhängige Komponente sowie in der Begründung der Zusammensetzung und
Entwicklungsinformationen für die Basiskomponente zusammen mit den Designinformationen der
abhängigen Komponente detailliert beschrieben ist. Diese Informationen ermöglichen es dem Evaluator, ein
Verständnis dafür zu gewinnen, wie die Basiskomponente und die abhängige Komponente interagieren.
Der Evaluator wird alle neuen Leitlinien berücksichtigen, die für die Installation, die Inbetriebnahme und den
Betrieb des zusammengesetzten TOEs bereitgestellt werden, um alle potentiellen Anfälligkeiten zu
identifizieren, die durch diese überarbeiteten Leitlinien eingeführt werden.
Wenn eine der einzelnen Komponenten seit dem Abschluss der Komponentenevaluierung Aufgaben zur
Zusicherung der kontinuierlichen Vertrauenswürdigkeit durchlaufen hat, wird der Evaluator den Patch in der
unabhängigen Anfälligkeitsanalyse berücksichtigen. Informationen im Zusammenhang mit der Änderung, die
in einem öffentlichen Bericht über die Aufgaben zur Zusicherung der kontinuierlichen Vertrauenswürdigkeit
(z. B. Wartungsbericht) bereitgestellt werden. Dies wird ergänzt durch alle Aktualisierungen der
Leitliniendokumentation, die sich aus der Änderung ergeben, und alle Informationen über die Änderung, die
im öffentlichen Bereich, z. B. auf der Website des Anbieters, verfügbar sind.
Jegliche Risiken, die aufgrund mangelnder Nachweise zur Feststellung der vollen Auswirkung von Patches
oder Abweichungen in der Konfiguration einer Komponente von der evaluierten Konfiguration identifiziert
werden, sind in der Anfälligkeitsanalyse des Evaluators zu dokumentieren.
309
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Anhang A
(informativ)
Allgemeine Evaluierungsleitlinien
A.1 Zielsetzungen
Die Zielsetzung dieses Abschnitts ist es, allgemeine Leitlinien für den technischen Nachweis von Evaluierungs-
ergebnissen abzudecken. Die Verwendung solch allgemeiner Leitlinien trägt dazu bei, Objektivität, Wiederhol-
barkeit und Reproduzierbarkeit der vom Evaluator geleisteten Arbeit zu erreichen.
A.2 Probenahme
Dieser Unterabschnitt enthält allgemeine Leitlinien zur Probenahme. Spezifische und detaillierte Informatio-
nen werden in den Workunits unter den spezifischen Evaluatorenaktionselementen gegeben, in denen die
Probenahme durchgeführt werden muss.
Die Probenahme ist ein definiertes Verfahren eines Evaluators, bei der eine Teilmenge einer erforderlichen
Menge Evaluationsnachweise untersucht und als repräsentativ für die gesamte Menge angenommen wird. Sie
ermöglicht es dem Evaluator, genügend Vertrauen in die Richtigkeit bestimmter Evaluationsnachweise zu
gewinnen, ohne den gesamten Nachweis zu analysieren. Der Grund für die Probenahme ist die Einsparung von
Ressourcen bei gleichzeitiger Aufrechterhaltung einer angemessenen Vertrauenswürdigkeitsstufe. Die
Probenahme der Nachweise kann zwei mögliche Ergebnisse liefern:
a) Die Teilmenge weist keine Fehler auf, so dass der Evaluator darauf vertrauen kann, dass die gesamte
Menge korrekt ist.
b) Die Teilmenge enthüllt Fehler, und daher wird die Gültigkeit der gesamten Menge in Frage gestellt. Selbst
die Auflösung aller gefundenen Fehler kann nicht ausreichen, um dem Evaluator das nötige Vertrauen zu
geben, so dass der Evaluator möglicherweise den Umfang der Teilmenge erhöhen oder die Probenahme
für diesen speziellen Nachweis einstellen muss.
Die Probenahme ist eine Technik, die verwendet werden kann, um zu einer zuverlässigen Schlussfolgerung zu
gelangen, wenn eine Menge von Nachweisen relativ homogener Natur ist, z. B. wenn die Nachweise während
eines klar festgelegten Prozesses erbracht worden sind.
Die Probenahme in den in ISO/IEC 15408 identifizierten Fällen und in Fällen, die speziell in den
Arbeitsaufgaben zur Evaluierungsmethodik behandelt werden, wird als kosteneffektiver Ansatz zur
Durchführung von Evaluatorenaktionen anerkannt. Die Probenahme in anderen Bereichen ist nur in
Ausnahmefällen zulässig, wenn die Durchführung einer bestimmten Aufgabe in ihrer Gesamtheit einen
Aufwand erfordern würde, der in keinem Verhältnis zu den anderen Evaluierungsaufgaben steht, und wenn
dies die Vertrauenswürdigkeit nicht entsprechend erhöhen würde. In solchen Fällen muss eine Begründung
für die Verwendung von Probenahmen in diesem Bereich gegeben werden. Weder die Tatsache, dass der TOE
groß und komplex ist, noch die Tatsache, dass er viele funktionale Sicherheitsanforderungen hat, ist eine
ausreichende Begründung, da bei Evaluierungen großer, komplexer TOEs ein höherer Aufwand erwartet
werden kann. Vielmehr soll diese Ausnahme auf Fälle beschränkt werden, in denen der TOE-Entwick-
lungsansatz große Mengen an Material für eine bestimmte Anforderung der ISO/IEC 15408 liefert, die
üblicherweise alle geprüft oder untersucht werden müssten, und in denen nicht erwartet wird, dass eine
solche Aktion die Vertrauenswürdigkeit entsprechend erhöht.
310
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Die Probenahme muss unter Berücksichtigung der möglichen Auswirkungen auf die Sicherheitszielsetzungen
und Bedrohungen des TOEs begründet werden. Die Auswirkungen hängen davon ab, was bei der Probenahme
möglicherweise übersehen wird. Auch die Art der zu beprobenden Nachweise und die Anforderung, keine
Sicherheitsfunktionen zu schmälern oder zu ignorieren, müssen berücksichtigt werden.
Es sollte anerkannt werden, dass die Probenahme von Nachweisen, die direkt mit der Implementierung des
TOEs zusammenhängen (z. B. Prüfergebnisse des Entwicklers), einen anderen Ansatz für die Probenahme
erfordert als die Probennahme im Zusammenhang mit der Feststellung, ob ein Prozess befolgt wird. In vielen
Fällen muss der Evaluator feststellen, dass ein Prozess befolgt wird, und es wird eine Probenahmestrategie
empfohlen. Der Ansatz für die Probenahme der Prüfergebnisse eines Entwicklers wird unterschiedlich sein.
Dies liegt daran, dass es im ersten Fall darum geht, sicherzustellen, dass ein Prozess vorhanden ist, und im
zweiten Fall darum, die korrekte Implementierung des TOEs zu bestimmen. In der Regel sollten in Fällen, die
mit der korrekten Implementierung des TOEs zusammenhängen, größere Probengrößen analysiert werden,
als für die Sicherstellung eines Prozesses notwendig wären.
In bestimmten Fällen kann es für den Evaluator angemessen sein, der Wiederholung der Entwicklerprüfungen
mehr Gewicht zu geben. Wenn sich beispielsweise die dem Evaluator überlassenen unabhängigen Prüfungen
nur oberflächlich von denen unterscheiden, die in einem umfangreichen Entwicklerprüfsatz enthalten sind
(möglicherweise weil der Entwickler mehr Prüfungen durchgeführt hat, als zur Erfüllung der Kriterien
„Coverage“ (ATE_COV) und „Depth“ (ATE_DPT) erforderlich sind), dann wäre es angemessen, dass der
Evaluator der Wiederholung der Entwicklerprüfungen mehr Aufmerksamkeit schenkt. Es ist zu beachten, dass
dies nicht notwendigerweise die Anforderung einer hochprozentigen Stichprobe für die Wiederholung von
Entwicklerprüfungen impliziert; in der Tat kann der Evaluator bei einem umfangreichen Entwicklerprüfsatz
eine niedrigprozentige Stichprobe begründen.
Wenn der Entwickler eine automatisierte Prüfreihe zur Durchführung von Funktionsprüfungen verwendet
hat, wird es für den Evaluator in der Regel eher einfacher sein, die gesamte Prüfreihe erneut auszuführen, als
nur eine Stichprobe von Entwicklerprüfungen zu wiederholen. Der Evaluator ist jedoch verpflichtet, zu prüfen,
dass die automatische Prüfung keine falsch darstellenden Ergebnisse liefert. Daraus ergibt sich, dass diese
Prüfung für eine Stichprobe der automatischen Prüfreihe durchgeführt werden muss, wobei die Grundsätze
für die Auswahl einiger Prüfungen gegenüber anderen und die Sicherstellung einer ausreichenden
Stichprobengröße auch in diesem Fall gelten.
Die folgenden Grundsätze sollten bei jeder Probenahme befolgt werden:
a) Die Probenahme sollte nicht zufällig sein, sondern so gewählt werden, dass sie für alle Nachweise
repräsentativ ist. Die Größe und Zusammensetzung der Stichprobe muss immer begründet werden.
b) Wenn sich die Probenahme auf die korrekte Implementierung des TOEs bezieht, sollte die Stichprobe für
alle Aspekte repräsentativ sein, die für die untersuchten Bereiche relevant sind. Insbesondere sollte die
Auswahl eine Vielzahl von Komponenten, Schnittstellen, Entwickler- und Betriebsstandorten (wenn mehr
als einer beteiligt ist) und Hardware-Plattformtypen (wenn mehr als einer beteiligt ist) umfassen. Die
Stichprobengröße sollte der Kostenwirksamkeit der Evaluierung entsprechen und hängt von einer Menge
TOE-abhängiger Faktoren ab (z. B. Größe und Komplexität des TOEs, Umfang der Dokumentation).
c) Wenn es bei der Probenahme darum geht, den Nachweis zu erbringen, dass die Entwicklerprüfung
wiederholbar und reproduzierbar ist, muss die verwendete Stichprobe ausreichen, um alle verschiedenen
Aspekte der Entwicklerprüfungen, wie z. B. verschiedene Prüfprogramme, zu repräsentieren. Die
verwendete Stichprobe muss ausreichen, um jedes systematische Problem im Funktionsprüfprozess des
Entwicklers zu erkennen. Der Beitrag des Evaluators, der sich aus der Kombination von sich
wiederholenden Entwicklerprüfungen und der Durchführung unabhängiger Prüfungen ergibt, muss
ausreichen, um die wichtigsten Punkte zu behandeln, die für den TOE von Bedeutung sind.
d) Wenn sich die Probenahme auf die Erlangung von Nachweisen dafür bezieht, dass ein Prozess (z. B.
Besucherkontrolle oder Designprüfung), sollte der Evaluator genügend Informationen sammeln, um
angemessenes Vertrauen zu erlangen, dass das Verfahren befolgt wird.
311
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
e) Der Antragsteller und der Entwickler sollten nicht im Voraus über die genaue Zusammensetzung der
Stichprobe informiert werden, sofern die rechtzeitige Lieferung der Stichprobe und der unterstützenden
Beiträge, z. B. Test-Harnische und Ausrüstung, an den Evaluator in Übereinstimmung mit dem
Evaluierungszeitplan sichergestellt ist.
f) Die Wahl der Stichprobe sollte so weit wie möglich frei von systematischen Abweichungskomponenten
sein (es sollte nicht immer das erste oder letzte Element gewählt werden). Im Idealfall sollte die Auswahl
der Stichprobe von einer anderen Person als dem Evaluator vorgenommen werden.
Die in der Stichprobe gefundenen Fehler können entweder als systematisch oder als sporadisch eingestuft
werden. Wenn es sich um einen systematischen Fehler handelt, sollte das Problem behoben und eine komplett
neue Stichprobe entnommen werden. Wenn sie richtig erklärt werden, könnten sporadische Fehler behoben
werden, ohne dass eine neue Stichprobe benötigt wird, obwohl die Begründung bestätigt werden sollte. Der
Evaluator sollte sein Urteilsvermögen bei der Festlegung einsetzen, ob er die Stichprobengröße erhöht oder
eine andere Stichprobe verwendet.
A.3 Abhängigkeiten
Im Allgemeinen ist es möglich, die erforderlichen Evaluierungsaufgaben, Unteraufgaben und Aktionen in
beliebiger Reihenfolge oder parallel durchzuführen. Es gibt jedoch verschiedene Arten von Abhängigkeiten,
die vom Evaluator berücksichtigt werden müssen. Dieser Unterabschnitt enthält allgemeine Leitlinien zu
Abhängigkeiten zwischen verschiedenen Aufgaben, Unteraufgaben und Aktionen.
A.3.1 Abhängigkeiten zwischen Aufgaben
Für einige Fälle können die verschiedenen Vertrauenswürdigkeitsklassen eine Reihenfolge der damit
verbundenen Aufgaben empfehlen oder sogar erforderlich machen. Ein spezifischer Fall ist die ST-Aufgabe.
Die Evaluierungsaufgabe der ST wird vor allen TOE-Evaluierungsaufgaben begonnen, da die ST die Grundlage
und den Kontext für die Durchführung dafür liefert. Eine endgültige Entscheidung über die ST-Evaluierung ist
jedoch möglicherweise erst nach Abschluss der TOE-Evaluierung möglich, da sich aus den Ergebnissen der
Aufgaben während der TOE-Evaluierung Änderungen an der ST ergeben können.
A.3.2 Abhängigkeiten zwischen Unteraufgaben
Die in ISO/IEC 15408-3 identifizierten Abhängigkeiten zwischen den Komponenten müssen vom Evaluator
berücksichtigt werden. Die meisten Abhängigkeiten verlaufen in eine Richtung, z. B. „Evaluation of sub-
activity“ (AVA_VAN.1) beansprucht eine Abhängigkeit von „Evaluation of sub-activity“ (ADV_FSP.1) und
„Evaluation of sub-activity“ (AGD_OPE.1). Es gibt auch Fälle von gegenseitigen Abhängigkeiten, bei denen
beide Komponenten voneinander abhängen. Ein Beispiel dafür ist „Evaluation of sub-activity“ (ATE_FUN.1)
und „Evaluation of sub-activity“ (ATE_COV.1).
Einer Unteraufgabe kann in der Regel nur dann eine akzeptierte Entscheidung zugewiesen werden, wenn all
jene Unteraufgaben erfolgreich abgeschlossen werden, von denen sie in einer Richtung abhängig ist. Eine
akzeptierte Entscheidung zu „Evaluation of sub-activity“ (AVA_VAN.1) kann in der Regel nur zugewiesen
werden, wenn den Unteraufgaben in Bezug auf „Evaluation of sub-activity“ (ADV_FSP.1) und „Evaluation of
sub-activity“ (AGD_OPE.1) ebenfalls eine akzeptierte Entscheidung zugewiesen wird. Bei gegenseitiger
Abhängigkeit hängt die Reihenfolge dieser Komponenten davon ab, dass der Evaluator entscheidet, welche
Unteraufgabe zuerst ausgeführt wird. Es ist zu beachten, dass dies angibt, dass eine akzeptierte Entscheidung
in der Regel erst dann zugewiesen werden kann, wenn beide Unteraufgaben erfolgreich waren.
Bei der Festlegung, ob sich eine Unteraufgabe auf eine andere Unteraufgabe auswirkt, sollte der Evaluator also
berücksichtigen, ob diese Aufgabe von potentiellen Evaluierungsergebnissen aus abhängigen Unteraufgaben
abhängt. In der Tat kann es vorkommen, dass eine abhängige Unteraufgabe diese Unteraufgabe beeinflusst, so
dass zuvor abgeschlossene Evaluatorenaktionen erneut durchgeführt werden müssen.
312
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Ein signifikanter Abhängigkeitseffekt tritt bei vom Evaluator entdeckten Mängeln auf. Wenn ein Mangel als
Ergebnis der Durchführung einer Unteraufgabe identifiziert wird, ist die Zuordnung einer akzeptierten
Entscheidung zu einer abhängigen Unteraufgabe gegebenenfalls nicht möglich, bis alle Mängel im
Zusammenhang mit der Unteraufgabe, von der sie abhängt, behoben sind.
A.3.3 Abhängigkeiten zwischen Aktionen
Es kann der Fall sein, dass Ergebnisse, die vom Evaluator während einer Aktion erzeugt werden, für die
Durchführung einer anderen Aktion verwendet werden. Beispielsweise können Aktionen für Vollständigkeit
und Konsistenz erst dann abgeschlossen werden, wenn die Prüfungen auf Inhalt und Präsentation
abgeschlossen sind. Dies bedeutet zum Beispiel, dass dem Evaluator empfohlen wird, nach der Evaluierung
der Bestandteile des/der PP/ST die Begründung des/der PP/ST zu evaluieren.
A.4 Standortbesichtigungen
A.4.1 Einleitung
Die Vertrauenswürdigkeitsklasse ALC enthält Anforderungen für
a) die Anwendung des Konfigurationsmanagements, wobei sichergestellt wird, dass die Integrität des TOEs
erhalten bleibt,
b) Maßnahmen, Verfahren und Normen, die sich mit der sicheren Lieferung des TOEs befassen und
sicherstellen, dass der vom TOE angebotene Sicherheitsschutz während der Übertragung an den Benutzer
nicht beeinträchtigt wird,
c) Sicherheitsmaßnahmen, die zum Schutz der Entwicklungsumgebung eingesetzt werden.
Eine Besichtigung des Entwicklungsstandorts ist ein nützliches Mittel, bei dem der Evaluator feststellt, ob die
Verfahren konsistent gegenüber den in der Dokumentation beschriebenen Verfahren befolgt werden.
Gründe für Standortbesichtigungen sind unter anderem
a) die Verwendung des CM-Systems, wie im CM-Plan beschrieben, zu beobachten,
b) die praktische Anwendung der in der Lieferdokumentation beschriebenen Lieferverfahren zu

beobachten,
c) die Anwendung von Sicherheitsmaßnahmen während der Entwicklung und Wartung des TOEs, wie in der
Entwicklungssicherheitsdokumentation beschrieben, zu beobachten.
Spezifische und detaillierte Informationen werden in den Workunits für jene Aufgaben gegeben, bei denen
Standortbesichtigungen durchgeführt werden:
a) „CM capabilities“ (ALC_CMC).n mit n 3 (insbesondere Workunit ALC_CMC.3-10 = ALC_CMC.4-13

= ALC_CMC.5-19);
b) „Delivery“ (ALC_DEL) (insbesondere Workunit ALC_DEL.1-2);
c) „Development security“ (ALC_DVS) (insbesondere Workunit ALC_DVS.1-3 = ALC_DVS.2-4).
313
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
A.4.2 Allgemeiner Ansatz
Während einer Evaluierung ist es oft notwendig, dass der Evaluator den Entwickler mehr als einmal trifft, und
es ist eine Frage der guten Planung, die Standortbesichtigung mit einer weiteren Besprechung zu kombinieren,
um die Kosten zu senken. Zum Beispiel könnten die Standortbesichtigungen für das Konfigurations-
management, für die Sicherheit des Entwicklers und für die Lieferung kombiniert werden. Es kann auch
notwendig sein, mehr als eine Standortbesichtigung am selben Standort durchzuführen, um die Überprüfung
aller Entwicklungsphasen zu ermöglichen. Beispielsweise sollte berücksichtigt werden, dass die Entwicklung
an mehreren Einrichtungen innerhalb eines einzigen Gebäudes, an mehreren Gebäuden am selben Standort
oder an mehreren Standorten erfolgen könnte.
Die erste Standortbesichtigung sollte frühzeitig während der Evaluierung eingeplant werden. Im Falle einer
Evaluierung, die während der Entwicklungsphase des TOEs beginnt, ermöglicht dies die Durchführung von
Korrekturmaßnahmen, falls erforderlich. Im Falle einer Evaluierung, die nach der Entwicklung des TOEs
beginnt, könnte eine frühzeitige Standortbesichtigung die Einführung von Korrekturmaßnahmen
ermöglichen, wenn schwerwiegende Mängel in den angewandten Verfahren auftauchen. Dadurch wird
unnötiger Evaluierungsaufwand vermieden.
Befragungen sind auch ein nützliches Mittel, um festzustellen, ob die schriftlichen Verfahren das, was getan
wird, widerspiegeln. Bei der Durchführung solcher Befragungen strebt der Evaluator ein tieferes Verständnis
der analysierten Verfahren am Entwicklungsstandort an, wie sie in der Praxis eingesetzt werden und ob sie
wie in den vorgelegten Evaluationsnachweisen beschrieben angewendet werden. Solche Befragungen
ergänzen, ersetzen aber nicht die Untersuchung von Evaluationsnachweisen.
In einem ersten Schritt zur Vorbereitung der Standortbesichtigung sollten die Evaluatoren die Evaluatoren-
Workunits bezüglich der Vertrauenswürdigkeitsklasse ALC unter Ausschluss der Aspekte, die die Ergebnisse
der Standortbesichtigung beschreiben, durchführen. Auf der Grundlage der in der jeweiligen
Entwicklerdokumentation enthaltenen Informationen und der verbleibenden offenen Fragen, die durch die
Dokumentation nicht beantwortet wurden, stellen die Evaluatoren eine Checkliste der Fragen zusammen, die
durch die Standortbesichtigung gelöst werden sollen.
Die erste Version des Evaluierungsberichts bezüglich der Klasse ALC und der Checkliste dient als Eingabe für
die Beratung mit der Evaluierungsinstanz bezüglich der Standortbesichtigungen.
Die Checkliste dient als Orientierungshilfe für die Standortbesichtigungen, welche Fragen durch Einsicht-
nahme in die entsprechenden Maßnahmen, deren Anwendung und Ergebnisse sowie durch Befragungen
beantwortet werden sollen. Gegebenenfalls erfolgt eine Probenahme zur Erlangung des erforderlichen
Vertrauensgrads (siehe A.2).
Die Ergebnisse der Standortbesichtigungen werden aufgezeichnet und dienen als Eingabe für die endgültige
Version des Evaluierungsberichts bezüglich der Vertrauenswürdigkeitsklasse ALC.
Andere Ansätze zur Gewinnung von Vertrauen sollten in Betracht gezogen werden, die eine gleichwertige
Vertrauenswürdigkeitsstufe bieten (z. B. zur Analyse von Evaluationsnachweisen). Jede Entscheidung, von
einer Besichtigung abzusehen, sollte in Absprache mit der Evaluierungsinstanz getroffen werden. Geeignete
Sicherheitskriterien und eine Methodik sollten auf andere Normen des Bereichs Informationssicherheits-
managementsysteme basieren.
A.4.3 Orientierungshilfe für die Erstellung der Checkliste
Im Folgenden werden einige Stichworte gegeben, welche Themen bei einem Audit geprüft werden sollten.
314
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
A.4.3.1 Aspekte des Konfigurationsmanagements
Grundsätzliches
Elemente der Konfigurationsliste, einschließlich TOE, Quellcode, Laufzeitbibliotheken, Design-

dokumentation, Entwicklungstools (ALC_CMC.3-8).
Verfolgung der Designdokumentation, des Quellcodes, der Leitlinien für Benutzer zu verschiedenen
Versionen des TOEs.
Integration des Konfigurationssystems in den Design- und Entwicklungsprozess, die Prüfplanung, die
Prüfanalyse und die Qualitätsmanagementverfahren.
Prüfanalyse
Verfolgung von Prüfplänen und Ergebnissen zu bestimmten Konfigurationen und Versionen des TOEs.
Zugriffskontrolle zu Entwicklungssystemen
Politiken für Zugriffskontrolle und Protokollierung.

Politiken für die projektspezifische Zuweisung und Änderung von Zugriffsrechten.
Freigabe
Politiken zur Freigabe des TOEs und Leitlinien für Benutzer für den Kunden.
Politiken zum Prüfen und Genehmigen von Komponenten und dem TOE vor dem Einsatz.
A.4.3.2 Aspekte der Entwicklungssicherheit
Infrastruktur
Sicherheitsmaßnahmen für die physische Zugriffskontrolle zum Entwicklungsstandort und Begründung

für die Wirksamkeit dieser Maßnahmen.
Organisatorische Maßnahmen
Organisationsstruktur des Unternehmens im Hinblick auf die Sicherheit der Entwicklungsumgebung.

Organisatorische Trennung zwischen Entwicklung, Produktion, Prüfung und Qualitätssicherung.
Personalmaßnahmen
Maßnahmen zur Schulung des Personals im Hinblick auf die Entwicklungssicherheit.

Maßnahmen und rechtliche Vereinbarungen zur Nicht-Offenlegung interner Informationen.
Zugriffskontrolle
Zuordnung von gesicherten Objekten (z. B. TOE, Quellcode, Laufzeitbibliotheken, Designdokumentation,

Entwicklungstools, Leitlinien für Benutzer) und Sicherheitspolitiken.
Politiken und Verantwortlichkeiten bezüglich der Zugriffskontrolle und der Handhabung von
Authentifizierungsinformationen.
Politiken für die Protokollierung jeglicher Art von Zugriff auf den Entwicklungsstandort und den Schutz
der Protokolldaten.
Eingabe, Verarbeitung und Ausgabe von Daten
Sicherheitsmaßnahmen zum Schutz der Ausgabe und Ausgabegeräte (Drucker, Plotter und Displays).
Sicherung der lokalen Netzwerke und Kommunikationsverbindungen.
315
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Speicherung, Übertragung und Vernichtung von Dokumenten und Datenträgern.
Politiken für die Handhabung von Dokumenten und Datenträgern.

Politiken und Verantwortlichkeiten für die Vernichtung von aussortierten Dokumenten und die
Protokollierung dieser Ereignisse.
Datenschutz
Politiken und Verantwortlichkeiten für den Daten- und Informationsschutz (z. B. für die Durchführung
von Backups).
Notfallplan
Praktiken für den Notfall und Verantwortlichkeiten.

Dokumentation der Notfallmaßnahmen zur Zugriffskontrolle.
Informationen des Personals über die im Extremfall anzuwendenden Praktiken. Schutz (z. B. für die
Durchführung von Backups).
A.4.4 Beispiel für eine Checkliste

Die Beispiele für Checklisten für Standortbesichtigungen bestehen aus Tabellen für die Vorbereitung eines
Audits und für die Präsentation der Ergebnisse eines Audits.
Die im Folgenden dargestellte Struktur der Checkliste ist vorläufig. Abhängig von den konkreten Inhalten der
neuen Leitlinie könnten Änderungen notwendig werden.
Die Checkliste ist nach den in der Einleitung angegebenen Themen in drei Unterabschnitte unterteilt (A.4.1):
a) Konfigurationsmanagementsystem;
b) Lieferverfahren;
c) Sicherheitsmaßnahmen während der Entwicklung.
Diese Unterabschnitte entsprechen der derzeitigen ISO/IEC 15408, Klasse ALC, insbesondere den Familien
„CM capabilities“ (ALC_CMC).n mit n 3, „Delivery“ (ALC_DEL) und „Development security“ (ALC_DVS).
Die Unterabschnitte sind weiter in Zeilen unterteilt, die den entsprechenden Workunits dieser Internationalen
Norm entsprechen.
Die Spalten der Checkliste enthalten der Reihe nach
eine fortlaufende Nummer,

die in Bezug genommene Workunit,
die Verweisungen auf die entsprechende Entwicklerdokumentation,
die ausdrückliche Wiedergabe der Maßnahmen des Entwicklers,
besondere Bemerkungen und Fragen, die während der Besichtigung zu klären sind (über die Standard-
aufgabe des Evaluators zur Überprüfung der Anwendung der angegebenen Maßnahmen hinaus),
die Ergebnisse der Untersuchung bei der Besichtigung.
Wenn beschlossen wird, getrennte Checklisten für die Vorbereitung und die Berichterstattung des Audits zu
haben, wird die Ergebnisspalte in der Vorbereitungsliste und die Spalte für Bemerkungen und Fragen in der
Berichtsliste weggelassen. Die übrigen Spalten sollten in beiden Listen identisch sein.
316
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Tabelle A.1 — Beispiel für eine Checkliste bei EAL-Stufe 4 (Auszug)

A. Untersuchung des CM-Systems (ALC_CMC.4 und ALC_CMS.4)
Entwickler- Fragen und
Nr. Workunit Maßnahmen Ergebnis
dokumentation Anmerkungen
Das System, das die
Quellcodedateien
automatisch verwal- Wenn ein Benutzer
tet, ist in der Lage, Erfordert das Lesen nicht das Recht hat,
„Konfigurations- Benutzerprofile und oder Aktualisieren auf ein vertrauliches
ALC_CMC.4-11,
A.1 management- abgestufte Zugriffs- einer Quellcodedatei Dokument zuzu-
ALC_CMC.4-12
system“, Abschnitt ... rechte zu verwalten eine Benutzer- greifen, wird es ihm
und die Identifizie- authentifizierung? nicht einmal in der
rung und Authentifi- Dateiliste angezeigt.
zierung der Benutzer
zu überprüfen.
... ... ... ... ... ...
B. Untersuchung der Lieferverfahren (ALC_DEL.1)

Die Evaluatoren
haben den Prozess
Die Software wird
geprüft und wie
ALC_DEL.1-1, „Lieferung des PGP-signiert und
B.1 --- beschrieben vorge-
ALC_DEL.1-2 TOEs“, Abschnitt ... verschlüsselt an den
funden, zusätzlich
Kunden übertragen.
wird eine Prüfziffer
übermittelt.
... ... ... ... ... ...
C. Untersuchung der organisatorischen und infrastrukturellen Entwicklersicherheit (ALC_DVS.1, ALC_LCD.1,

ALC_TAT.1)
Ist die Umzäunung
Die Evaluatoren
„Sicherheit der Ent- Das Firmengelände stark und hoch
beurteilten die
ALC_DVS.1-1, wicklungsumgebung“, ist durch einen genug, um ein
C.1 Umzäunung als
ALC_DVS.1-2 Abschnitt ... Sicherheitszaun leichtes Eindringen
ausreichend stark
(Firmengelände) geschützt. in das Gelände zu
und hoch.
verhindern?
Das Gebäude verfügt
über folgende Zu- Über die ange-
gangsmöglichkeiten: gebenen Zugangs-
den Haupteingang, möglichkeiten
der vom Empfang hinaus gibt es einen
„Sicherheit der Ent-
überwacht wird und Ist die Auflistung der Notausgang, der von
ALC_DVS.1-1, wicklungsumgebung“,
C.2 geschlossen ist, Zugangsmöglichkeit außen nicht geöffnet
ALC_DVS.1-2 Abschnitt ...
wenn dieser nicht en vollständig? werden kann. Die
(Gebäude)
besetzt ist, und einen oben genannten
Zugang in der Rollläden können
Warenannahme, der nur von innen
durch zwei Rollläden bedient werden.
gesichert ist.
... ... ... ... ... ...
317
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
A.5 Zuständigkeiten des Schemas

Diese Internationale Norm beschreibt die technische Arbeit, die Evaluierungen, die unter Überwachungs-
behörden (Schema) durchgeführt werden, mindestens leisten müssen. Sie erkennt jedoch auch (sowohl
explizit als auch implizit) an, dass es Aufgaben oder Verfahren gibt, auf die die gegenseitige Anerkennung von
Evaluierungsergebnissen nicht angewiesen ist. Im Sinne der Gründlichkeit und Klarheit und um besser
abzugrenzen, wo diese Internationale Norm endet und die Methodik eines einzelnen Schemas beginnt, werden
die folgenden Angelegenheiten dem Ermessen der Schemata überlassen. Die Schemata können wählen, die
folgenden Angaben zu machen, auch wenn sie einige unbestimmt lassen können. (Es wurden alle
Anstrengungen unternommen, um sicherzustellen, dass diese Liste vollständig ist; Evaluatoren, die mit einem
Thema konfrontiert werden, das weder hier aufgeführt noch in dieser Internationalen Norm behandelt wird,
sollten ihre Evaluierungsschemata konsultieren, um festzustellen, unter wessen Schirmherrschaft das Thema
fällt).
Zu den Themen, die von den Schemata festgelegt werden können, gehören Folgende:
a) was erforderlich ist, um sicherzustellen, dass eine Evaluierung ausreichend durchgeführt wurde – jedes
Schema verfügt über ein Mittel zur Überprüfung der fachlichen Kompetenz, des Verständnisses der Arbeit
und der Arbeit seiner Evaluatoren, sei es, dass die Evaluatoren ihre Ergebnisse der
Überwachungsbehörde vorlegen müssen, sei es, dass die Überwachungsbehörde die Arbeit des
Evaluators wiederholen muss, oder sei es durch ein anderes Mittel, das dem Schema versichert, dass alle
Evaluierungsstellen angemessen und vergleichbar sind;
b) Prozess zur Entsorgung von Evaluationsnachweisen nach Abschluss einer Evaluierung;
c) alle Anforderungen an die Vertraulichkeit (seitens des Evaluators und die Geheimhaltung der während
der Evaluierung erhaltenen Informationen);
d) die Vorgehensweise, wenn während der Evaluierung ein Problem auftritt (ob die Evaluierung fortgesetzt
wird, wenn das Problem behoben ist, oder ob die Evaluierung sofort beendet wird und das nachge-
besserte Produkt erneut zur Evaluierung vorgelegt werden muss);
e) jede spezifische (natürliche) Sprache, in der die Dokumentation bereitgestellt werden muss;
f) alle aufgezeichneten Nachweise, die im ETR eingereicht werden müssen – diese Internationale Norm legt
fest, was in einem ETR mindestens gemeldet werden muss; einzelne Schemata können jedoch die
Aufnahme zusätzlicher Informationen fordern;
g) alle zusätzlichen Berichte (außer dem ETR), die von den Evaluatoren verlangt werden – zum Beispiel
Prüfberichte;
h) alle spezifischen ORs, die vom Schema gefordert werden können, einschließlich der Struktur, der
Empfänger usw. solcher ORs;
i) eine bestimmte inhaltliche Struktur eines schriftlichen Berichts als Ergebnis einer ST-Evaluierung – ein
Schema kann ein bestimmtes Format für alle seine Berichte haben, in denen die Ergebnisse einer
Evaluierung, sei es die Evaluierung eines TOEs oder einer ST, detailliert dargestellt werden;
j) alle zusätzlich erforderlichen PP/ST-Identifizierungsinformationen;
k) alle Aufgaben zur Bestimmung der Eignung explizit genannter Anforderungen in einer ST;
l) Anforderungen an die Bereitstellung von Evaluationsnachweisen zur Unterstützung der Neubewertung

und Wiederverwendung der Nachweise;
m) jede spezifische Handhabung von Schemabezeichnern, Logos, Warenzeichen usw.;
318
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
n) alle spezifischen Leitlinien im Umgang mit Kryptographie;
o) Handhabung und Anwendung von Interpretationen eines Schemas sowie nationaler und internationaler
Interpretationen;
p) eine Liste oder Charakterisierung geeigneter alternativer Ansätze für Prüfungen, wenn diese nicht
durchführbar sind;
q) der Mechanismus, mit dem eine Evaluierungsinstanz bestimmen kann, welche Schritte ein Evaluator beim
Prüfen unternommen hat;
r) bevorzugter Prüfansatz (falls vorhanden): an der internen Schnittstelle oder an der externen
Schnittstelle;
s) eine Liste oder Charakterisierung der akzeptablen Mittel zur Durchführung der Anfälligkeitsanalyse des
Evaluators (z. B. Methodik der Mängelhypothese);
t) Informationen über alle zu berücksichtigenden Anfälligkeiten und Schwächen.
319
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Anhang B
(informativ)
Anfälligkeitsbewertung (AVA)
Dieser Anhang enthält eine Erläuterung der AVA_VAN-Kriterien und Beispiele für deren Anwendung. Dieser
Anhang definiert nicht die AVA-Kriterien; diese Definition findet sich in ISO/IEC 15408-3, Klasse AVA:
Vulnerability assessment.
Dieser Anhang besteht aus zwei wesentlichen Teilen.
a) Leitlinien zur Durchführung einer unabhängigen Anfälligkeitsanalyse. Dies wird in B.1 zusammengefasst,
und eine ausführlichere Beschreibung findet sich in B.2. Diese Unterabschnitte beschreiben, wie ein
Evaluator an die Erstellung einer unabhängigen Anfälligkeitsanalyse herangehen sollte.
b) Wie das angenommene Angriffspotential eines Angreifers charakterisiert und genutzt wird. Dies wird
in B.3 bis B.5 beschrieben. In diesen Unterabschnitten wird beispielhaft beschrieben, wie ein
Angriffspotential charakterisiert werden kann und verwendet werden sollte, und es werden Beispiele
genannt.
B.1 Was ist eine Anfälligkeitsanalyse?

Der Zweck der Aufgabe einer Anfälligkeitsbewertung besteht darin, die Existenz und Ausnutzbarkeit von
Mängeln oder Schwächen des TOEs in der Betriebsumgebung festzustellen. Diese Festlegung basiert auf der
vom Evaluator durchgeführten Analyse und wird durch Evaluatorenprüfungen unterstützt.
Auf den untersten Stufen der „Vulnerability analysis“ (AVA_VAN) führt der Evaluator lediglich eine Suche nach
öffentlich zugänglichen Informationen durch, um alle bekannten Anfälligkeiten des TOEs zu ermitteln,
während der Evaluator auf den höheren Stufen eine strukturierte Analyse der Evaluationsnachweise des TOEs
durchführt.
Es gibt drei Hauptfaktoren bei der Durchführung einer Anfälligkeitsanalyse, nämlich
a) die Identifizierung von potentiellen Anfälligkeiten,
b) die Beurteilung, um festzustellen, ob die identifizierten potentiellen Anfälligkeiten es einem Angreifer mit
dem entsprechenden Angriffspotential ermöglichen könnten, die SFRs zu verletzen,
c) Penetrationstests, um festzustellen, ob die identifizierten potentiellen Anfälligkeiten in der Betriebs-

umgebung des TOEs ausnutzbar sind.
Die Identifizierung von Anfälligkeiten kann weiter zerlegt werden in die zu durchsuchenden Nachweise und
wie schwer es ist, diese Nachweise zu durchsuchen, um potentielle Anfälligkeiten zu identifizieren. In
ähnlicher Weise können die Penetrationstests weiter zerlegt werden in die Analyse der potentiellen
Anfälligkeit, um Angriffsverfahren zu identifizieren, und die Vorführung der Angriffsverfahren.
Diese Hauptfaktoren sind iterativer Natur, d. h. Penetrationstests von potentiellen Anfälligkeiten können zur
Identifizierung weiterer potentieller Anfälligkeiten führen. Daher werden diese als eine einzige Aufgabe der
Anfälligkeitsanalyse durchgeführt.
320
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
B.2 Erstellung einer Anfälligkeitsanalyse durch den Evaluator

Die Anfälligkeitsanalyse des Evaluators soll feststellen, dass der TOE gegen Penetrationsangriffe durch einen
Angreifer mit einem Angriffspotential Basic (für AVA_VAN.1 und AVA_VAN.2), Enhanced-Basic (für
AVA_VAN.3), Moderate (für AVA_VAN.4) oder High (für AVA_VAN.5) resistent ist. Der Evaluator beurteilt
zunächst die Ausnutzbarkeit aller identifizierten potentiellen Anfälligkeiten. Dies wird durch die
Durchführung von Penetrationstests erreicht. Der Evaluator sollte die Rolle eines Angreifers mit einem
Angriffspotential Basic (für AVA_VAN.1 und AVA_VAN.2), Enhanced-Basic (für AVA_VAN.3), Moderate (für
AVA_VAN.4) oder High (für AVA_VAN.5) übernehmen, wenn er versucht, in den TOE einzudringen.
Der Evaluator berücksichtigt potentielle Anfälligkeiten, auf die der Evaluator bei der Durchführung anderer
Evaluierungsaufgaben gestoßen ist. Der Penetrationstest des Evaluators zur Bestimmung der Beständigkeit
des TOEs gegen diese potentiellen Anfälligkeiten sollte in der Rolle eines Angreifers mit einem
Angriffspotential Basic (für AVA_VAN.1 und AVA_VAN.2), Enhanced-Basic (für AVA_VAN.3), Moderate (für
AVA_VAN.4) oder High (für AVA_VAN.5) durchgeführt werden.
Die Anfälligkeitsanalyse sollte jedoch nicht als isolierte Aufgabe durchgeführt werden. Sie ist eng mit ADV und
AGD verbunden. Der Evaluator führt diese anderen Evaluierungsaufgaben durch, wobei der Schwerpunkt auf
der Ermittlung potentieller Anfälligkeiten oder „Problemfelder“ liegt. Daher ist die Vertrautheit des Evaluators
mit den generischen Leitlinien für Anfälligkeiten (die in B.2.1 bereitgestellt werden) erforderlich.
B.2.1 Generische Leitlinien für Anfälligkeiten

Die folgenden fünf Kategorien bieten eine Erörterung der generischen Anfälligkeiten.
B.2.1.1 Umgehen
Das Umgehen umfasst alle Mittel, mit denen ein Angreifer die Sicherheitsdurchsetzung vermeiden könnte
durch
a) Ausnutzung der Fähigkeiten von Schnittstellen zum TOE oder von Dienstprogrammen, die mit dem TOE
interagieren können,
b) Übernahme von Berechtigungen oder anderen Fähigkeiten, die ansonsten verweigert werden sollten,
c) (wenn die Vertraulichkeit ein Anliegen ist) das Lesen sensibler Daten, die in unzureichend geschützten
Bereichen gespeichert oder dorthin kopiert wurden.
Jeder der folgenden Punkte sollte (soweit relevant) bei der unabhängigen Anfälligkeitsanalyse des Evaluators
berücksichtigt werden:
a) Angriffe, die auf der Ausnutzung der Fähigkeiten von Schnittstellen oder Versorgungseinrichtungen
beruhen, machen sich im Allgemeinen das Fehlen der erforderlichen Sicherheitsdurchsetzung an diesen
Schnittstellen zunutze. Zum Beispiel wird sich Zugang zu Funktionen verschafft, die auf einer niedrigeren
Stufe implementiert sind als die, auf der die Zugriffskontrolle durchgesetzt wird. Zu den relevanten
Punkten gehören Folgende:
1) Änderung der vordefinierten Reihenfolge des Aufrufs der TSFI;
2) Aufrufen einer zusätzlichen TSFI;
3) Verwendung einer Komponente in einem unerwarteten Kontext oder für einen unerwarteten Zweck;
4) Verwendung von Implementierungsdetails, die in weniger abstrakten Darstellungen eingeführt

wurden;
5) Nutzung der Verzögerung zwischen der Zeit der Zugriffsprüfung und der Zeit der Nutzung.
321
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
b) Eine Änderung der vordefinierten Reihenfolge des Aufrufs von Komponenten sollte in Betracht gezogen
werden, wenn es eine erwartete Reihenfolge gibt, in der Schnittstellen zum TOE (z. B. Benutzerbefehle)
aufgerufen werden, um eine TSFI aufzurufen (z. B. Öffnen einer Datei für den Zugriff und anschließendes
Lesen von Daten aus dieser Datei). Wenn eine TSFI über eine der TOE-Schnittstellen aufgerufen wird (z. B.
eine Zugriffskontrollprüfung), sollte der Evaluator prüfen, ob es möglich ist, die Kontrolle zu umgehen,
indem der Aufruf zu einem späteren Zeitpunkt in der Reihenfolge durchgeführt wird oder indem er ihn
ganz auslässt.
c) Die Ausführung einer zusätzlichen Komponente (in der vordefinierten Reihenfolge) ist eine ähnliche
Form des Angriffs wie die oben beschriebene, beinhaltet jedoch den Aufruf einer anderen beliebigen
TOE-Schnittstelle an einer beliebigen Stelle der Reihenfolge. Sie kann auch Angriffe auf der Grundlage des
Abfangens sensibler Daten beinhalten, die über ein Netzwerk mit Hilfe von Netzwerkverkehrs-
analysatoren (die zusätzliche Komponente ist hier der Netzwerkverkehrsanalysator) übertragen werden.
d) Die Verwendung einer Komponente in einem unerwarteten Kontext oder für einen unerwarteten Zweck
schließt die Verwendung einer unabhängigen TOE-Schnittstelle zur Umgehung der TSF ein, indem sie zur
Erreichung eines Zwecks verwendet wird, für den sie nicht konzipiert oder vorgesehen war. Verdeckte
Kanäle sind ein Beispiel für diese Art von Angriff (siehe B.2.1.4 für die weitere Erörterung der verdeckten
Kanäle). Auch die Verwendung undokumentierter Schnittstellen, die unsicher sein können, fällt in diese
Kategorie. Solche Schnittstellen können undokumentierte Unterstützungs- und Hilfseinrichtungen
umfassen.
e) Die Verwendung von Implementierungsdetails, die in niedrigeren Darstellungen eingeführt werden, kann
es einem Angreifer ermöglichen, zusätzliche Funktionen, Ressourcen oder Attribute zu nutzen, die als
Folge des Präzisierungsprozesses in den TOE eingeführt werden. Zusätzliche Funktionalität kann den in
den Softwaremodulen enthaltenen Test-Harnisch-Code und die während des Implementierungs-
prozesses eingeführten Hintertüren umfassen.
f) Die Verwendung der Verzögerung zwischen der Zeit der Prüfung und der Zeit der Nutzung schließt
Szenarien ein, in denen eine Zugriffskontrolle durchgeführt und der Zugriff gewährt wird und ein
Angreifer anschließend in der Lage ist, Bedingungen zu schaffen, die, wenn sie zum Zeitpunkt der
Zugriffsprüfung angewendet worden wären, ein Scheitern der Prüfung bewirkt hätten. Ein Beispiel wäre
ein Benutzer, der einen Hintergrundprozess erstellt, um hochsensible Daten zu lesen und an das Terminal
des Benutzers zu senden, und sich dann mit einer niedrigeren Empfindlichkeitsstufe abmeldet und wieder
anmeldet. Falls der Hintergrundprozess nicht beendet wird, sobald der Benutzer sich abmeldet, wären
die MAC-Prüfungen effektiv umgangen worden.
g) Angriffe, die auf der Übernahme von Berechtigungen basieren, beruhen im Allgemeinen auf dem
unerlaubten Erlangen der Berechtigungen oder Fähigkeiten einer Komponente, die eine Berechtigung
erfordert, in der Regel durch unkontrolliertes oder unerwartetes Verlassen dieser Komponente. Zu den
relevanten Punkten gehören Folgende:
1) Daten auszuführen, die nicht ausführbar sein sollen, oder sie ausführbar zu machen;
2) unerwartete Eingaben für eine Komponente zu generieren;
3) die Annahmen und Eigenschaften aufzuheben, auf die die Komponenten der unteren Ebenen
angewiesen sind.
h) Daten auszuführen, die nicht ausführbar sein sollen, oder sie ausführbar zu machen schließt Angriffe ein,
bei denen Viren zum Einsatz kommen (z. B. das Einfügen eines ausführbaren Codes oder von Befehlen in
eine Datei, die automatisch ausgeführt werden, wenn die Datei bearbeitet wird oder auf sie zugegriffen
wird, so dass alle Berechtigungen, über die der Eigentümer der Datei verfügt, übernommen werden).
322
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
i) Die Generierung unerwarteter Eingaben bei einer Komponente kann unerwartete Auswirkungen haben,
die ein Angreifer ausnutzen könnte. Wenn die TSF beispielsweise umgangen werden könnte, wenn ein
Benutzer Zugriff auf das zugrunde liegende Betriebssystem erhält, könnte es möglich sein, einen solchen
Zugriff nach der Anmeldesequenz zu erhalten, indem der Effekt des Treffens verschiedener Kontroll- oder
Escape-Sequenzen während der Authentisierung eines Passworts untersucht werden.
j) Das Aufheben von Annahmen und Eigenschaften, auf die untergeordnete Komponenten angewiesen sind,
umfasst Angriffe, die darauf basieren, aus den Beschränkungen einer Anwendung auszubrechen, um
Zugriff auf ein zugrunde liegendes Betriebssystem zu erhalten und so die TSF einer Anwendung zu
umgehen. In diesem Fall lautet die aufgehobene Annahme, dass es für einen Benutzer der Anwendung
nicht möglich ist, einen solchen Zugang zu erhalten. Ein ähnlicher Angriff kann gegen eine Anwendung
auf ein zugrunde liegendes Datenbankmanagementsystem ins Auge gefasst werden: Auch hier könnte die
TSF umgangen werden, wenn ein Angreifer aus den Beschränkungen der Anwendung ausbrechen kann.
k) Angriffe, die auf dem Lesen von sensiblen Daten basieren, die in unzureichend geschützten Bereichen
gespeichert sind (anwendbar, wenn die Vertraulichkeit ein Anliegen ist), umfassen die folgenden Punkte,
die als mögliches Mittel für den Zugriff auf sensible Daten in Betracht gezogen werden sollten:
1) Scavenging auf dem Datenträger;
2) Zugriff auf ungeschützten Speicher;
3) Ausnutzung des Zugriffs auf gemeinsame beschreibbare Dateien oder andere gemeinsame
Ressourcen (z. B. Auslagerungsdateien);
4) Aktivieren der Fehlerbehebung, um festzustellen, welche Zugriffe Benutzer erhalten können.

Beispielsweise kann ein automatisches Dateiwiederherstellungssystem nach einem Absturz ein Lost-
and-Found-Verzeichnis für Dateien ohne Header verwenden, die sich auf dem Datenträger ohne
Kennsätze befinden. Wenn der TOE obligatorische Zugriffskontrollen implementiert, ist es wichtig zu
untersuchen, auf welcher Sicherheitsstufe dieses Verzeichnis geführt wird (z. B. auf System hoch)
und wer Zugriff auf dieses Verzeichnis hat.
Es gibt eine Anzahl verschiedener Verfahren, mit denen ein Evaluator eine Hintertür identifizieren kann,
darunter zwei Haupttechniken. Erstens, indem der Evaluator beim Prüfen versehentlich eine Schnittstelle
identifiziert, die falsch benutzt werden kann. Zweitens, durch das Prüfen jeder externen Schnittstelle der TSF
in einem Debugging-Modus, um alle Module zu identifizieren, die nicht als Teil der Prüfung der
dokumentierten Schnittstellen aufgerufen werden, und dann durch die Inspektion des nicht aufgerufenen
Codes, um zu prüfen, ob es sich um eine Hintertür handelt.
Bei einem Software-TOE, bei dem die „Evaluation of sub-activity“ (ADV_IMP.2) und die Komponenten
ALC_TAT.2 oder höher im Sicherheitspaket enthalten sind, kann der Evaluator bei der Analyse der Tools die
Bibliotheken und Pakete berücksichtigen, die vom Compiler in der Kompilierungsphase verlinkt werden, um
festzustellen, dass in diesem Stadium keine Hintertüren eingeführt werden.
B.2.1.2 Eingriffe
Als Eingriff gilt jeder Angriff, der darauf beruht, dass ein Angreifer versucht, das Verhalten der TSF zu
beeinflussen (d. h. Korruption oder Deaktivierung), z. B. durch
a) Zugriff auf Daten, auf deren Vertraulichkeit oder Integrität die TSF angewiesen ist,
b) Zwang des TOEs, mit ungewöhnlichen oder unerwarteten Umständen umzugehen,
c) Deaktivierung oder Verzögerung der Sicherheitsdurchsetzung,
d) physische Änderung des TOEs.
323
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Jeder der folgenden Punkte sollte (soweit relevant) bei der unabhängigen Anfälligkeitsanalyse des Evaluators
berücksichtigt werden.
a) Zu den Angriffen, die auf dem Zugriff auf Daten basieren, deren Vertraulichkeit oder Integrität geschützt
ist, gehören
1) das direkte oder indirekte Lesen, Schreiben oder Ändern von internen Daten,
2) Verwendung einer Komponente in einem unerwarteten Kontext oder für einen unerwarteten Zweck,
3) Verwendung von Schnittstellen zwischen Komponenten, die auf einer höheren Abstraktionsebene
nicht sichtbar sind.
b) Das direkte oder indirekte Lesen, Schreiben oder Ändern interner Daten umfasst die folgenden Arten von
Angriffen, die in Betracht gezogen werden sollten:
1) das Lesen von intern gespeicherten „Geheimnissen“, wie z. B. Benutzerpasswörtern;
2) das Spoofing von internen Daten, auf die die sicherheitsdurchsetzenden Mechanismen angewiesen
sind;
3) das Ändern von Umgebungsvariablen (z. B. logische Namen) oder Daten in Konfigurationsdateien
oder temporären Dateien.
c) Es kann möglich sein, einen vertrauenswürdigen Prozess so zu täuschen, dass er eine geschützte Datei
modifiziert, auf die er üblicherweise nicht zugreifen würde.
d) Der Evaluator sollte auch die folgenden „gefährlichen Merkmale“ berücksichtigen:
1) Quellcode, der sich zusammen mit einem Compiler auf dem TOE befindet (z. B. kann es möglich sein,
den Login-Quellcode zu ändern);
2) ein interaktiver Debugger und eine Patch-Einrichtung (z. B. kann es möglich sein, das ausführbare
Bild zu modifizieren);
3) die Möglichkeit, Änderungen auf der Ebene der Gerätesteuerung vorzunehmen, wenn kein
Dateischutz besteht;
4) Diagnose-Code, der im Quellcode vorhanden ist und der optional enthalten sein kann;
5) die im TOE verbliebenen Entwicklertools.
e) Die Verwendung einer Komponente in einem unerwarteten Kontext oder für einen unerwarteten Zweck
umfasst (zum Beispiel), wenn der TOE eine Anwendung ist, die auf einem Betriebssystem aufbaut, die
Nutzung von Kenntnissen eines Textverarbeitungspakets oder eines anderen Editors zur Änderung der
eigenen Befehlsdatei (z. B. zum Erlangen höherer Berechtigungen).
f) Die Verwendung von Schnittstellen zwischen Komponenten, die auf einer höheren Abstraktionsebene
nicht sichtbar sind, schließt Angriffe ein, die den gemeinsamen Zugriff auf Ressourcen ausnutzen, wobei
die Änderung einer Ressource durch eine Komponente das Verhalten einer anderen (vertrauens-
würdigen) Komponente beeinflussen kann, z. B. auf Quellcode-Ebene, durch die Verwendung globaler
Daten oder indirekter Mechanismen wie gemeinsamer Speicher oder Semaphore.
g) Angriffe, die darauf basieren, den TOE zu zwingen, mit ungewöhnlichen oder unerwarteten Umständen
fertig zu werden, sollten immer in Betracht gezogen werden. Zu den relevanten Punkten gehören
1) unerwartete Eingaben für eine Komponente zu generieren,
2) die Annahmen und Eigenschaften aufzuheben, auf die die Komponenten der unteren Ebenen
angewiesen sind.
324
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
h) Die Erzeugung von unerwarteten Eingaben für eine Komponente schließt die Untersuchung des
Verhaltens des TOEs ein, wenn
1) Befehlseingabepuffer überlaufen (möglicherweise „Absturz des Stapels“ oder Überschreiben von

anderem Speicher, den ein Angreifer ausnutzen kann, oder Durchsetzen eines Crash-Dumps, der
sensible Informationen wie Klartext-Passwörter enthalten kann),
2) ungültige Befehle oder Parameter eingegeben werden (einschließlich der Übergabe eines
schreibgeschützten Parameters an eine Schnittstelle, die erwartet, Daten über diesen Parameter
zurückzugeben, und der Übergabe einer falsch formatierten Eingabe, wodurch das Parsing
fehlschlagen sollte, wie z. B. SQL-Injection, Formatierungszeichenketten),
3) eine Dateiende-Markierung (z. B. CTRL-Z oder CTRL-D) oder ein Nullzeichen in einem Audit-Trail
eingefügt wird.
i) Das Aufheben von Annahmen und Eigenschaften, auf die die untergeordneten Komponenten angewiesen
ist, schließt Angriffe ein, die Fehler im Quellcode ausnutzen, bei denen der Code (explizit oder implizit)
davon ausgeht, dass sicherheitsrelevante Daten in einem bestimmten Format vorliegen oder einen
bestimmten Wertebereich haben. In diesen Fällen sollte der Evaluator feststellen, ob er solche Annahmen
aufheben kann, indem er bewirkt, dass die Daten in einem anderen Format oder mit anderen Werten
vorliegen, und wenn ja, ob dies einem Angreifer einen Vorteil verschaffen könnte.
j) Das korrekte Verhalten der TSF kann von Annahmen abhängen, die unter extremen Umständen, wenn
Ressourcengrenzen erreicht werden oder Parameter ihren Höchstwert erreichen, aufgehoben werden.
Der Evaluator sollte (soweit praktisch durchführbar) das Verhalten des TOEs bei Erreichen dieser
Grenzen berücksichtigen, z. B:
1) Änderung von Daten (z. B. Untersuchung, wie sich der TOE verhält, wenn eine kritische
Datumsschwelle überschritten wird);
2) Befüllen der Datenträger;
3) Überschreitung der Höchstanzahl von Benutzern;
4) Füllen des Audit-Protokolls;
5) Sättigung der Sicherheitsalarmwarteschlangen an einer Konsole;
6) Überlastung verschiedener Teile eines Mehrbenutzer-TOEs, der stark auf Kommunikations-

komponenten angewiesen ist;
7) Überfluten eines Netzwerks oder einzelner Hosts mit Datenverkehr;
8) Füllen von Puffern oder Feldern.
k) Angriffe, die auf der Deaktivierung oder Verzögerung der Sicherheitsdurchsetzung beruhen, umfassen die
folgenden Punkte:
1) Verwendung von Interrupts oder Terminieren von Funktionen, um die Reihenfolge zu unterbrechen;
2) Unterbrechung der Gleichzeitigkeit;
3) Verwendung von Schnittstellen zwischen Komponenten, die auf einer höheren Abstraktionsebene
nicht sichtbar sind.
l) Die Verwendung von Interrupts oder die Terminierung von Funktionen zur Unterbrechung der
Reihenfolge schließt die Untersuchung des Verhaltens des TOEs ein, wenn
1) ein Befehl unterbrochen wird (mit CTRL-C, CTRL-Y usw.),
2) ein zweiter Interrupt ausgegeben wird, bevor der erste quittiert wird.
325
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
m) Die Auswirkungen der Beendigung sicherheitskritischer Prozesse (z. B. eines Audit-Daemons) sollten
untersucht werden. Ebenso kann es möglich sein, die Protokollierung von Auditaufzeichnungen, die
Ausgabe oder den Empfang von Alarmen so zu verzögern, dass es für einen Administrator nicht von
Nutzen ist (da der Angriff möglicherweise bereits erfolgreich war).
n) Die Unterbrechung der Gleichzeitigkeit schließt die Untersuchung des Verhaltens des TOEs ein, wenn
zwei oder mehr Subjekte gleichzeitig versuchen, darauf zuzugreifen. Es kann sein, dass der TOE mit der
erforderlichen Verriegelung zurechtkommt, wenn zwei Subjekte gleichzeitig versuchen, darauf
zuzugreifen, aber dass das Verhalten in Anwesenheit weiterer Subjekte weniger klar definiert wird.
Beispielsweise könnte ein kritischer Sicherheitsprozess in einen Ressourcen-Wartezustand versetzt
werden, wenn zwei andere Prozesse auf eine für ihn erforderliche Ressource zugreifen.
o) Die Verwendung von Schnittstellen zwischen Komponenten, die auf einer höheren Abstraktionsebene
nicht sichtbar sind, kann ein Mittel sein, um einen zeitkritischen vertrauenswürdigen Prozess zu
verzögern.
p) Physische Angriffe können in physische Sondierung, physische Eingriffe, physische Modifikation und
Substitution kategorisiert werden.
1) Physische Sondierung durch Eindringen in den TOE, die auf Interna des TOEs abzielt, z. B. Lesen an
internen Kommunikationsschnittstellen, Leitungen oder Speichern.
2) Physische Eingriffe können mit den TOE-Interna erfolgen, die auf interne Modifikationen des TOEs
(z. B. durch Verwendung optischer Fehlerinduktion als Interaktionsprozess), auf die externen
Schnittstellen des TOEs (z. B. durch Strom- oder Taktstörungen) und auf die Umgebung des TOEs
(z. B. durch Änderung der Temperatur) abzielen.
3) Physische Änderung von TOE-internen sicherheitsdurchsetzenden Attributen zur Übernahme von
Berechtigungen oder anderen Fähigkeiten, die im regulären Betrieb verweigert werden sollten.
Solche Veränderungen können z. B. durch die Induktion von optischen Fehlern verursacht werden.
Angriffe, die auf einer physischen Modifikation beruhen, können auch eine Modifikation der TSF
selbst bewirken, z. B. indem sie vor der Ausführung Fehler bei der programminternen
Datenübertragung des TOEs verursachen. Es ist zu beachten, dass eine solche Art des Umgehens
durch Modifikation der TSF selbst jede TSF gefährden kann, es sei denn, es gibt andere Maßnahmen
(möglicherweise Maßnahmen in Bezug auf die Umgebung), die einen Angreifer am physischen
Zugang zum TOE hindern.
4) Physische Substitution zum Austausch des TOEs durch eine andere IT-Entität während der Lieferung
oder des Betriebs des TOEs. Die Substitution während der Lieferung des TOEs aus der
Entwicklungsumgebung an den Benutzer sollte durch die Anwendung sicherer Lieferverfahren (wie
z. B. die unter „Development security“ (ALC_DVS)) verhindert werden. Die Substitution des TOEs
während des Betriebs kann durch eine Kombination aus Leitlinien für Benutzer und
Betriebsumgebung in Betracht gezogen werden, so dass der Benutzer sicher sein kann, dass er mit
dem TOE interagiert.
B.2.1.3 Direkte Angriffe
Ein direkter Angriff beinhaltet die Identifizierung von Penetrationstests, die notwendig sind, um die Stärke
von Permutations- oder wahrscheinlichkeitsbasierten Mechanismen und anderen Mechanismen zu prüfen,
um sicherzustellen, dass sie einem direkten Angriff standhalten.
Es kann zum Beispiel eine mangelhafte Annahme sein, dass eine bestimmte Implementierung eines
Pseudozufallszahlengenerators die erforderliche Entropie besitzt, die notwendig ist, um den Sicherheits-
mechanismus zu setzen.
Wenn ein wahrscheinlichkeitsbasierter oder Permutationsmechanismus auf der Wahl des Wertes eines
Sicherheitsattributs (z. B. Wahl der Passwortlänge) oder der Eingabe von Daten durch einen menschlichen
Benutzer (z. B. Wahl des Passworts) beruht, sollten die getroffenen Annahmen den ungünstigsten Fall
widerspiegeln.
326
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Wahrscheinlichkeitsbasierte oder Permutationsmechanismen sollten während der Untersuchung der

Evaluationsnachweise identifiziert werden, die als Eingabe für diese Unteraufgabe (Sicherheitsvorgaben,
Funktionsspezifikation, Teilmenge des TOEs-Designs und der Darstellung der Implementierung) erforderlich
sind, und in jeder anderen Dokumentation des TOEs (z. B. Leitlinien) können zusätzliche wahrscheinlichkeits-
basierte oder Permutationsmechanismen identifiziert werden.
Wenn der Designnachweis oder die Leitlinien Behauptungen oder Annahmen enthalten (z. B. darüber, wie
viele Authentisierungsversuche je Minute möglich sind), sollte der Evaluator unabhängig bestätigen, dass
diese korrekt sind. Dies kann durch Prüfungen oder durch eine unabhängige Analyse erreicht werden.
Direkte Angriffe, die sich auf eine Schwäche in einem kryptographischen Algorithmus stützen, sollten nicht
unter „Vulnerability analysis“ (AVA_VAN) in Betracht gezogen werden, da dies nicht in den Anwendungs-
bereich von ISO/IEC 15408 fällt. Die korrekte Implementierung des kryptographischen Algorithmus wird bei
den ADV- und ATE-Aufgaben berücksichtigt.
B.2.1.4 Überwachung
Informationen sind eine abstrakte Sicht auf die Beziehung zwischen den Eigenschaften von Entitäten, d. h. ein
Signal enthält Informationen für ein System, wenn der TOE in der Lage ist, auf dieses Signal zu reagieren. Die
TOE-Ressourcen verarbeiten und speichern Informationen, die durch Benutzerdaten dargestellt werden.
Daher gilt:
a) Informationen können mit den Benutzerdaten zwischen den Subjekten durch internen TOE-Transfer oder
Export aus dem TOE fließen;
b) Informationen können generiert und an andere Benutzerdaten weitergegeben werden;
c) Informationen können durch die Überwachung der Operationen auf Daten gewonnen werden, die diese
Informationen darstellen.
Die Informationen, die durch Benutzerdaten dargestellt werden, können durch Sicherheitsattribute wie
„Klassifizierungsstufe“ mit Werten wie z. B. unklassifiziert, vertraulich, geheim, streng geheim charakterisiert
werden, um Operationen an den Daten zu kontrollieren. Diese Informationen und damit die Sicherheits-
attribute können durch Operationen verändert werden, z. B. kann FDP_ACC.2 eine Senkung der Stufe durch
„Sanitarisierung“ oder eine Erhöhung der Stufe durch Kombination von Daten beschreiben. Dies ist ein Aspekt
einer Informationsflussanalyse, die sich auf kontrollierte Operationen von kontrollierten Subjekten an
kontrollierten Objekten konzentriert.
Der andere Aspekt ist die Analyse des unerlaubten Informationsflusses. Dieser Aspekt ist allgemeiner als der
direkte Zugriff auf Objekte mit Benutzerdaten, die von der Familie FDP_ACC angesprochen werden. Ein nicht
durchgesetzter Signalisierungskanal, der Informationen führt, die den Leitlinien für die Informationsfluss-
kontrolle unterliegen, kann auch durch die Überwachung der Verarbeitung eines beliebigen Objekts
verursacht werden, das diese Informationen enthält oder mit ihnen zusammenhängt (z. B. Seitenkanäle). Ein
durchgesetzter Signalisierungskanal kann in Bezug auf die Subjekte, die Ressourcen manipulieren, und das
Subjekt oder den Benutzer, das/der eine solche Manipulation beobachtet, identifiziert werden. Klassischer-
weise wurden verdeckte Kanäle als Synchronisierungs- oder Speicherkanäle identifiziert, je nach der
Ressource, die modifiziert oder moduliert wird. Wie bei anderen Überwachungsangriffen steht die
Verwendung des TOEs in Übereinstimmung mit den SFRs.
Verdeckte Kanäle sind üblicherweise anwendbar, wenn der TOE Anforderungen an die Leitlinien zur
Unbeobachtbarkeit UND zur mehrstufigen Trennung hat. Verdeckte Kanäle können bei der Analyse von
Anfälligkeiten und bei Designaufgaben routinemäßig entdeckt werden und sollten daher geprüft werden. Im
Allgemeinen werden solche Überwachungsangriffe jedoch nur durch spezielle Analysetechniken identifiziert,
die gemeinhin als „Analyse verdeckter Kanäle“ bezeichnet werden. Diese Techniken waren Gegenstand
zahlreicher Untersuchungen, und es gibt viele Veröffentlichungen zu diesem Thema. Leitlinien für die
Durchführung der Analyse verdeckter Kanäle sollten von der Evaluierungsinstanz eingeholt werden.
327
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Zu den nicht durchgesetzten Angriffen zur Überwachung des Informationsflusses gehören passive Analyse-
techniken, die auf die Offenlegung sensibler interner Daten des TOEs abzielen, indem der TOE in der Weise
betrieben wird, die den Leitliniendokumenten entspricht.
Die Seitenkanalanalyse umfasst kryptoanalytische Techniken, die auf physisch undichte Stellen des TOEs
basieren. Physisch undichte Stellen können durch Synchronisierinformationen, Leistungsaufnahme oder
Leistungsabgabe während der Berechnung einer TSF auftreten. Synchronisierinformationen können auch von
einem entfernten Angreifer (mit Netzwerkzugriff auf den TOE) gesammelt werden, leistungsbasierte
Informationskanäle setzen voraus, dass sich der Angreifer in der nahen Umgebung des TOEs befindet.
Abhörtechniken umfassen das Abfangen aller Formen von Energie, z. B. elektromagnetische oder optische
Ausstrahlung von Computeranzeigen, nicht unbedingt im Nahfeld des TOEs.
Die Überwachung umfasst auch das Ausnutzen von Protokollmängeln, z. B. einen Angriff auf die
SSL-Implementierung.
B.2.1.5 Fehlbenutzung
Eine Fehlbenutzung kann entstehen aus
a) unvollständiger Leitliniendokumentation,
b) unangemessenen Leitlinien,
c) unbeabsichtigte Fehlkonfiguration des TOEs,
d) durchgesetztes Ausnahmeverhalten des TOEs.
Wenn die Leitliniendokumentation unvollständig ist, weiß der Benutzer möglicherweise nicht, wie der TOE in
Übereinstimmung mit den SFRs zu betreiben ist. Der Evaluator sollte die durch die Durchführung anderer
Evaluierungsaufgaben erworbene Vertrautheit mit dem TOE anwenden, um festzustellen, dass die Leitlinien
vollständig sind. Insbesondere sollte der Evaluator die Funktionsspezifikation berücksichtigen. Die in diesem
Dokument beschriebene TSF sollte in den Leitlinien so beschrieben werden, wie es erforderlich ist, um eine
sichere Verwaltung und Nutzung durch die TSFI zu ermöglichen, die den menschlichen Benutzern zur
Verfügung steht. Darüber hinaus sollten die verschiedenen Betriebsarten in Betracht gezogen werden, um
sicherzustellen, dass für alle Betriebsarten Leitlinien bereitgestellt werden.
Der Evaluator kann als Hilfsmittel eine informelle Zuordnung zwischen den Leitlinien für Benutzer und diesen
Dokumenten erstellen. Jegliche Auslassungen in dieser Zuordnung können auf Unvollständigkeit hinweisen.
Die Leitlinien gelten als unangemessen, wenn sie Anforderungen an die Verwendung oder die Betriebs-
umgebung des TOEs stellen, die gegenüber der ST inkonsistent oder für die Aufrechterhaltung der Sicherheit
unangemessen belastend sind.
Ein TOE kann eine Vielzahl von Möglichkeiten nutzen, um den Verbraucher bei der effektiven Nutzung dieses
TOEs in Übereinstimmung mit den SFRs zu unterstützen und unbeabsichtigte Fehlkonfigurationen zu
verhindern. Ein TOE kann Funktionen (Merkmale) einsetzen, um den Verbraucher zu alarmieren, wenn sich
der TOE in einem Zustand befindet, der gegenüber den SFRs inkonsistent ist, während andere TOEs mit
erweiterten Leitlinien geliefert werden können, die Vorschläge, Hinweise, Verfahren usw. zur möglichst
effektiven Nutzung der vorhandenen Sicherheitsmerkmale enthalten; z. B. Leitlinien zur Nutzung des Audit-
Merkmals als Hilfe bei der Feststellung, wann die SFRs beeinträchtigt, d. h. unsicher werden.
Der Evaluator betrachtet die Funktionalität des TOEs, seinen Zweck und die Sicherheitszielsetzungen für die
Betriebsumgebung, um zu einer Schlussfolgerung darüber zu gelangen, ob die Verwendung der Leitlinien die
rechtzeitige Erkennung des Übergangs in einen unsicheren Zustand ermöglichen würde oder nicht.
328
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Das Potential des TOEs, in unsichere Zustände zu geraten, kann unter Verwendung der Evaluationsbeiträge,
wie z. B. der ST, der Funktionsspezifikation und aller anderen Designdarstellungen, die als Nachweis für die
im Sicherheitspaket für den TOE enthaltenen Komponenten geliefert werden (z. B. die TOE/TSF-Design-
spezifikation, wenn eine Komponente aus dem „TOE design“ (ADV_TDS) enthalten ist), bestimmt werden.
Fälle von durchgesetztem Ausnahmeverhalten der TSF könnten u. a. die folgenden sein, sind aber nicht darauf
beschränkt:
a) Verhalten des TOEs beim Starten, Abschalten oder bei der Fehlerbehebung;
b) Verhalten des TOEs unter extremen Umständen (manchmal als Überlastung oder asymptotisches
Verhalten bezeichnet), insbesondere wenn dies zur Deaktivierung oder Abschaltung von Teilen der TSF
führen könnte;
c) jedes Potential für unbeabsichtigte Fehlkonfiguration oder unsichere Nutzung, das sich aus den im obigen
Unterabschnitt über Eingriffe genannten Angriffen ergibt.
B.2.2 Identifizierung potentieller Anfälligkeiten
Potentielle Anfälligkeiten können vom Evaluator während verschiedener Aufgaben identifiziert werden. Sie
können während einer Evaluierungsaufgabe auftauchen oder als Ergebnis der Analyse von Nachweisen zur
Suche nach Anfälligkeiten identifiziert werden.
B.2.2.1 Vorgefunden
Bei der Identifizierung von Anfälligkeiten werden potentielle Anfälligkeiten vom Evaluator während der
Durchführung von Evaluierungsaufgaben identifiziert, d. h. die Nachweise werden nicht mit dem
ausdrücklichen Ziel analysiert, potentielle Anfälligkeiten zu identifizieren.
Das vorgefundene Identifizierungsverfahren hängt von der Erfahrung und dem Wissen des Evaluators ab; es
wird von der Evaluierungsinstanz überwacht und kontrolliert. Es ist im Ansatz nicht reproduzierbar, wird
aber dokumentiert, um die Wiederholbarkeit der Schlussfolgerungen aus den gemeldeten potentiellen
Anfälligkeiten sicherzustellen.
Für dieses Verfahren sind keine formalen Analysekriterien erforderlich. Potentielle Anfälligkeiten werden aus
den Nachweisen, die aufgrund von Wissen und Erfahrung vorgelegt werden, identifiziert. Dieses Verfahren
der Identifizierung ist jedoch nicht auf eine bestimmte Teilmenge von Nachweisen beschränkt.
Es wird davon ausgegangen, dass der Evaluator über Kenntnisse der Technologie des TOEs-Typs und
bekannte Sicherheitsmängel, wie sie in der öffentlichen Domäne dokumentiert sind, verfügt. Es wird von dem
Kenntnisstand ausgegangen, der aus einer für den TOE-Typ relevanten Sicherheits-E-Mail-Liste, den
regelmäßigen Bulletins (Listen von Mängeln, Anfälligkeiten und Sicherheitsmängeln), die von den
Organisationen veröffentlicht werden, die Sicherheitsfragen in weit verbreiteten Produkten und Technologien
untersuchen, gewonnen werden kann. Es wird nicht erwartet, dass sich dieses Wissen auf spezifische
Konferenzberichte oder detaillierte Thesen aus der Universitätsforschung für AVA_VAN.1 oder AVA_VAN.2
erstreckt. Um sicherzustellen, dass das angewandte Wissen auf dem neuesten Stand ist, muss der Evaluator
jedoch möglicherweise eine Suche in gemeinfreien Werken durchführen.
Für AVA_VAN.3 bis AVA_VAN.5 wird erwartet, dass die Suche nach öffentlich zugänglichen Informationen auch
Konferenzberichte und Thesen einschließt, die während der Forschungsaktivitäten von Universitäten und
anderen relevanten Organisationen erstellt wurden.
329
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Beispiele dafür, wie diese entstehen können (wie der Evaluator auf potentielle Anfälligkeiten stoßen kann):
a) während der Evaluator einige Nachweise prüft, löst er eine Erinnerung an eine potentielle Anfälligkeit
aus, die in einem ähnlichen Produkttyp identifiziert wurde und von der der Evaluator glaubt, dass sie auch
in dem zu evaluierenden TOE vorhanden ist;
b) Bei der Prüfung einiger Nachweise entdeckt der Evaluator einen Mangel in der Spezifikation einer
Schnittstelle, die eine potentielle Anfälligkeit widerspiegelt.
Dazu kann gehören, sich einer potentiellen Schwachstelle in einem TOE bewusst zu werden, indem über
generische Anfälligkeiten in einem bestimmten Produkttyp in einer IT-Sicherheitspublikation oder in einer
Sicherheits-E-Mail-Liste, die der Evaluator abonniert hat, gelesen wird.
Angriffsverfahren können direkt aus diesen potentiellen Anfälligkeiten entwickelt werden. Daher werden die
vorgefundenen potentiellen Anfälligkeiten zum Zeitpunkt der Erstellung von Penetrationstests auf der
Grundlage der Anfälligkeitsanalyse des Evaluators zusammengetragen. Es gibt keine explizite Aktion für den
Evaluator, um auf potentielle Anfälligkeiten zu stoßen. Daher wird der Evaluator durch eine implizite Aktion
geleitet, die in AVA_VAN.1.2E und AVA_VAN.*.4E festgelegt ist.
Aktuelle Informationen über öffentlich zugängliche Anfälligkeiten und Angriffe können dem Evaluator z. B.
von einer Evaluierungsinstanz zur Verfügung gestellt werden. Diese Informationen sind vom Evaluator bei
der Zusammenstellung der vorgefundenen Anfälligkeiten und Angriffsverfahren bei der Entwicklung von
Penetrationstests zu berücksichtigen.
B.2.2.2 Analyse
Die folgenden Arten von Analysen werden in Bezug auf die Aktionen des Evaluators vorgestellt.
B.2.2.2.1 Unstrukturierte Analyse
Die vom Evaluator durchzuführende unstrukturierte Analyse (für „Evaluation of sub-activity“ (AVA_VAN.2))
ermöglicht es dem Evaluator, die generischen Anfälligkeiten zu berücksichtigen (wie in B.2.1 erörtert). Der
Evaluator wird auch seine Erfahrung und sein Wissen über Mängel in ähnlichen Technologietypen anwenden.
B.2.2.2.2 Fokussiert
Während der Durchführung von Evaluierungsaufgaben kann der Evaluator auch Problemfelder identifizieren.
Dabei handelt es sich um spezifische Teile des TOEs-Nachweises, gegen die der Evaluator einige Vorbehalte
hat, obwohl der Nachweis die Anforderungen für die Aufgabe erfüllt, mit der der Nachweis verbunden ist.
Beispielsweise sieht eine bestimmte Schnittstellenspezifikation besonders komplex aus und kann daher
entweder bei der Entwicklung des TOEs oder beim Betrieb des TOEs fehleranfällig sein. In diesem Stadium ist
keine potentielle Anfälligkeit erkennbar, weitere Untersuchungen sind erforderlich. Dies geht über den
Rahmen des Aufgetretenen hinaus, da weitere Untersuchungen erforderlich sind.
Unterschied zwischen potentieller Anfälligkeit und Problemfeld:
a) Potentielle Anfälligkeit – der Evaluator kennt ein Angriffsverfahren, das zur Ausnutzung der Anfälligkeit
verwendet werden kann, oder der Evaluator kennt Informationen über Anfälligkeiten, die für den TOE
relevant sind.
b) Problemfeld – Der Evaluator kann das Anliegen als potentielle Anfälligkeit auf der Grundlage von
Informationen, die an anderer Stelle zur Verfügung gestellt wurden, unberücksichtigt lassen. Beim Lesen
der Schnittstellenspezifikation stellt der Evaluator fest, dass aufgrund der extremen (unnötigen)
Komplexität einer Schnittstelle eine potentielle Anfälligkeit in diesem Bereich liegen kann, auch wenn dies
aus dieser ersten Untersuchung nicht ersichtlich ist.
330
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der fokussierte Ansatz zur Identifizierung von Anfälligkeiten ist eine Analyse der Nachweise mit dem Ziel, alle
potentiellen Anfälligkeiten zu identifizieren, die sich aus den enthaltenen Informationen ergeben. Es handelt
sich um eine unstrukturierte Analyse, da der Ansatz nicht vorgegeben ist. Dieser Ansatz zur Identifizierung
potentieller Anfälligkeiten kann bei der unabhängigen Anfälligkeitsanalyse verwendet werden, die von der
„Evaluation of sub-activity“ (AVA_VAN.3) gefordert wird.
Diese Analyse kann durch verschiedene Ansätze erreicht werden, die zu einem angemessenen Vertrauensgrad
führen. Keiner der Ansätze hat ein starres Format für die durchzuführende Untersuchung der Nachweise.
Die Vorgehensweise richtet sich nach den Ergebnissen der beurteilten Nachweise durch den Evaluator, um
festzustellen, ob sie den Anforderungen der AVA/AGD-Unteraufgaben entspricht. Daher kann die Unter-
suchung der Nachweise für die bestehenden potentiellen Anfälligkeiten durch Folgendes geregelt werden:
a) Problemfelder, die bei der Untersuchung der Nachweise im Rahmen der Durchführung von Evaluierungs-
aufgaben identifiziert werden;
b) Abhängigkeit von einer bestimmten Funktionalität zur bei der Analyse des Architekturdesigns ermittel-
ten Trennung (wie in „Evaluation of sub-activity“ (ADV_ARC.1)), die eine weitere Analyse erfordert, um
festzustellen, dass sie nicht umgangen werden kann;
c) repräsentative Untersuchung der Nachweise zur Aufstellung von Hypothesen über potentielle
Anfälligkeiten im TOE.
zu identifizieren. Der Evaluator ist jedoch möglicherweise nicht in der Lage, die Schritte zur Identifizierung
potentieller Anfälligkeiten vor Beginn der Untersuchung zu beschreiben. Der Ansatz wird sich in Abhängigkeit
von den Ergebnissen der Evaluierungsaufgaben weiterentwickeln.
Die Problemfelder können sich aus der Untersuchung der Nachweise ergeben, die zur Erfüllung der für die
TOE-Evaluierung festgelegten SARs vorgelegt wurden. Die öffentlich zugänglichen Informationen werden
ebenfalls berücksichtigt.
Die vom Evaluator durchgeführten Aufgaben können wiederholt werden, und es können dieselben
Schlussfolgerungen in Bezug auf die Vertrauenswürdigkeitsstufe des TOEs erreicht werden, auch wenn die
Schritte, die zur Erreichung dieser Schlussfolgerungen unternommen werden, unterschiedlich sein können.
Da der Evaluator die Form der Analyse dokumentiert, sind auch die tatsächlichen Schritte, die zur Erreichung
dieser Schlussfolgerungen unternommen wurden, reproduzierbar.
B.2.2.2.3 Methodisch
Der methodische Analyseansatz erfolgt in Form einer strukturierten Untersuchung der Nachweise. Bei diesem
Verfahren muss der Evaluator die Struktur und Form der Analyse festlegen (d. h. die Art und Weise, in der die
Analyse durchgeführt wird, ist im Gegensatz zum fokussierten Identifizierungsverfahren vorgegeben). Das
Verfahren wird in Bezug auf die zu berücksichtigenden Informationen und das Wie/Warum der Berück-
sichtigung festgelegt. Dieser Ansatz zur Identifizierung potentieller Anfälligkeiten kann bei der unabhängigen
Anfälligkeitsanalyse verwendet werden, die von der „Evaluation of sub-activity“ (AVA_VAN.4) und „Evaluation
of sub-activity“ (AVA_VAN.5) gefordert wird.
Diese Analyse der Nachweise ist beabsichtigt und im Voraus geplant und berücksichtigt alle Nachweise, die
als Eingabe für die Analyse identifiziert wurden.
Alle Nachweise, die zur Erfüllung der im Sicherheitspaket festgelegten (ADV-)Vertrauenswürdigkeits-

anforderungen vorgelegt werden, werden als Eingabe für die Aufgabe zur Identifizierung potentieller
Anfälligkeiten verwendet.
331
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Der „methodische“ Kennsatz für diese Analyse wurde in dem Versuch verwendet, die Charakterisierung zu
erfassen, dass diese Identifizierung potentieller Anfälligkeiten einen geordneten und geplanten Ansatz
verfolgen soll. Bei der Untersuchung ist ein „Verfahren“ oder ein „System“ anzuwenden. Der Evaluator muss
das zu verwendende Verfahren in Bezug auf die zu berücksichtigenden Nachweise, die zu untersuchenden
Informationen innerhalb der Nachweise, die Art und Weise, in der diese Informationen berücksichtigt werden
sollen, und die aufzustellende Hypothese beschreiben.
Im Folgenden werden einige Beispiele aufgeführt, die eine Hypothese darstellen können:
b) Untersuchung eines Sicherheitsmechanismus, wie z. B. die Domänentrennung, wobei die Hypothese eines
internen Pufferüberlaufs aufgestellt wird, der zu einer Verschlechterung der Trennung führt;
c) Analyse, um alle Objekte zu identifizieren, die in der Darstellung der TOE-Implementierung erstellt
einen Ansatz für die Analyse festlegen, dass „alle in der Funktionsspezifikation und im TOE-Design enthaltenen
Schnittstellenspezifikationen analysiert werden, um Hypothesen über potentielle Anfälligkeiten aufzustellen“,
und dann die in der Hypothese verwendeten Verfahren erläutern.
Dieses Identifizierungsverfahren liefert einen Angriffsplan für den TOE, der von einem Evaluator durchgeführt
wird, der Penetrationstests für potentielle Anfälligkeiten im TOE durchführt. Die Begründung für das
Identifizierungsverfahren würde den Nachweis für die Abdeckung und die Tiefe der festgelegten Ausnutzung
liefern, die am TOE durchgeführt werden würde.
B.3 Wenn das Angriffspotential genutzt wird

B.3.1 Entwickler
Das Angriffspotential wird von einem PP/ST-Autor während der Entwicklung des/der PP/ST unter
Berücksichtigung des Bedrohungsumfeldes und der Auswahl der Vertrauenswürdigkeitskomponenten
genutzt. Dabei kann es sich einfach um die Feststellung handeln, dass das Angriffspotential, das die
angenommenen Angreifer des TOEs besitzen, generisch als Basic, Enhanced-Basic, Moderate oder High
charakterisiert wird. Alternativ kann das/die PP/ST bestimmte Ebenen einzelner Faktoren angeben, von
denen angenommen wird, dass sie sich im Besitz von Angreifern befinden. (Z. B. wird davon ausgegangen, dass
die Angreifer Experten in der Art der TOE-Technologie sind und Zugang zu spezieller Ausrüstung haben.)
Der PP/ST-Autor betrachtet das während einer Risikobeurteilung entwickelte Bedrohungsprofil (außerhalb
des Anwendungsbereichs der ISO/IEC 15408, aber als Eingabe für die Entwicklung des/der PP/ST im Hinblick
auf die Definition des Sicherheitsproblems oder im Falle von STs mit niedriger Vertrauenswürdigkeit, die
Anforderungsaussage). Die Berücksichtigung dieses Bedrohungsprofils im Hinblick auf einen der in den
folgenden Abschnitten besprochenen Ansätze ermöglicht die Spezifikation des Angriffspotentials, dem der
TOE widerstehen soll.
B.3.2 Evaluator
Das Angriffspotential wird vom Evaluator bei der ST-Evaluierung und den Aufgaben zur Anfälligkeits-
bewertung auf zwei verschiedene Arten besonders berücksichtigt.
Das Angriffspotential wird von einem Evaluator während der Durchführung der Unteraufgabe der
Anfälligkeitsanalyse verwendet, um festzustellen, ob der TOE unter der Annahme eines bestimmten
Angriffspotentials eines Angreifers gegen Angriffe resistent ist oder nicht. Wenn der Evaluator feststellt, dass
eine potentielle Anfälligkeit im TOE ausnutzbar ist, muss er bestätigen, dass sie unter Berücksichtigung aller
Aspekte der vorgesehenen Umgebung, einschließlich des von einem Angreifer angenommenen Angriffs-
potentials, ausnutzbar ist.
332
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Daher bestimmt der Evaluator anhand der in der Bedrohungsaussage der Sicherheitsvorgabe enthaltenen
Informationen das Angriffspotential, das ein Angreifer zur Durchführung eines Angriffs mindestens benötigt,
und kommt zu einer Schlussfolgerung über die Beständigkeit des TOEs gegen Angriffe. Tabelle B.1 zeigt die
Beziehung zwischen dieser Analyse und dem Angriffspotential.
Tabelle B.1 — Anfälligkeitsprüfung und Angriffspotential
Restanfälligkeiten können nur von

Anfälligkeits- TOE-resistent gegen Angreifer
Angreifern mit folgendem Angriffspotential
komponente mit folgendem Angriffspotential:
ausgenutzt werden:
VAN.5 High Beyond High
VAN.4 Moderate High
VAN.3 Enhanced-Basic Moderate
VAN.2 Basic Enhanced-Basic
VAN.1 Basic Enhanced-Basic
Der Begriff „Beyond High“ in der Spalte der Restanfälligkeiten in der obigen Tabelle stellt jene potentiellen
Anfälligkeiten dar, bei denen ein Angreifer ein größeres Angriffspotential als das von „High“ haben müsste, um
die potentielle Anfälligkeit auszunutzen. Eine in diesem Fall als Restanfälligkeit klassifizierte Anfälligkeit
spiegelt die Tatsache wider, dass eine bekannte Anfälligkeit im TOE vorhanden ist, aber in der aktuellen
Betriebsumgebung mit dem angenommenen Angriffspotential diese Anfälligkeit nicht ausgenutzt werden
kann.
Auf jeder Ebene des Angriffspotentials kann eine potentielle Anfälligkeit aufgrund einer Gegenmaßnahme in
der Betriebsumgebung, die verhindert, dass die Anfälligkeit ausgenutzt wird, als „nicht machbar“ angesehen
werden.
Eine Anfälligkeitsanalyse gilt für alle TSFIs, auch für solche, die auf wahrscheinlichkeitsbasierte oder
Permutationsmechanismen zugreifen. Es werden keine Annahmen über die Korrektheit des Designs und der
Implementierung der TSFI getroffen; es werden auch keine Einschränkungen hinsichtlich des Angriffs-
verfahrens oder der Interaktion des Angreifers mit dem TOE gemacht – wenn ein Angriff möglich ist, ist er bei
der Anfälligkeitsanalyse zu berücksichtigen. Wie aus Tabelle B.1 hervorgeht, zeigt eine erfolgreiche
Evaluierung anhand einer Komponente zur Sicherung der Anfälligkeit, dass die TSF so konzipiert und
umgesetzt wurde, dass sie vor dem erforderlichen Grad der Bedrohung schützt.
Es ist nicht notwendig, dass ein Evaluator für jede potentielle Anfälligkeit eine Berechnung des Angriffs-
potentials durchführt. In einigen Fällen zeigt sich bei der Entwicklung des Angriffsverfahrens, ob das für die
Entwicklung und Durchführung des Angriffsverfahrens erforderliche Angriffspotential mit dem
Angriffspotential, das vom Angreifer in der Betriebsumgebung angenommen wird, übereinstimmt oder nicht.
Für alle Anfälligkeiten, für die eine Ausnutzung festgestellt wird, führt der Evaluator eine Berechnung des
Angriffspotentials durch, um festzustellen, ob die Ausnutzung dem für den Angreifer angenommenen Grad des
Angriffspotentials angemessen ist.
Der unten beschriebene Ansatz ist immer dann anzuwenden, wenn es notwendig ist, das Angriffspotential zu
berechnen, es sei denn, die Evaluierungsinstanz gibt verbindliche Leitlinien, dass ein alternativer Ansatz
anzuwenden ist. Die in den Tabellen B.2 und B.3 unten angegebenen Werte sind nicht mathematisch bewiesen.
Daher müssen die in diesen Beispieltabellen angegebenen Werte möglicherweise je nach Technologietyp und
spezifischen Umgebungen angepasst werden. Der Evaluator sollte sich von der Evaluierungsinstanz beraten
lassen.
333
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
B.4 Berechnung des Angriffspotentials

B.4.1 Anwendung des Angriffspotentials
Das Angriffspotential ist abhängig von Fachwissen, Ressourcen und Motivation. Es gibt mehrere Verfahren zur
Darstellung und Quantifizierung dieser Faktoren. Es kann auch andere Faktoren geben, die für bestimmte
TOE-Typen anwendbar sind.
B.4.1.1 Handhabung der Motivation
Die Motivation ist ein Faktor des Angriffspotentials, der zur Beschreibung verschiedener Aspekte in Bezug auf
den Angreifer und die vom Angreifer gewünschten Vermögenswerte verwendet werden kann. Erstens kann
Motivation die Wahrscheinlichkeit eines Angriffs implizieren – es kann aus einer als hoch motiviert
beschriebenen Bedrohung abgeleitet werden, dass ein Angriff unmittelbar bevorsteht, oder dass aus einer
unmotivierten Bedrohung kein Angriff erwartet wird. Abgesehen von den beiden extremen Motivations-
ebenen ist es jedoch schwierig, aus der Motivation eine Wahrscheinlichkeit für das Auftreten eines Angriffs
abzuleiten.
Zweitens kann die Motivation den Wert des Vermögens, sei es in finanzieller oder anderer Form, für den
Angreifer oder den Vermögensinhaber implizieren. Ein Vermögen von sehr hohem Wert motiviert eher zu
einem Angriff als ein Vermögen von geringem Wert. Anders als in einer sehr allgemeinen Weise ist es jedoch
schwierig, den Wert eines Vermögens mit der Motivation in Beziehung zu setzen, da der Wert eines Vermögens
subjektiv ist – er hängt weitgehend von dem Wert ab, den ein Vermögensinhaber ihm beimisst.
Drittens kann Motivation das Fachwissen und die Ressourcen implizieren, mit denen ein Angreifer bereit ist,
einen Angriff durchzuführen. Daraus kann abgeleitet werden, dass ein hoch motivierter Angreifer
wahrscheinlich genügend Fachwissen und Ressourcen erwerben wird, um die Maßnahmen zum Schutz eines
Vermögenswertes zu vereiteln. Umgekehrt kann daraus abgeleitet werden, dass ein Angreifer mit erheblichen
Fachkenntnissen und Ressourcen nicht bereit ist, einen Angriff unter deren Verwendung durchzuführen,
wenn die Motivation des Angreifers gering ist.
Im Verlauf der Vorbereitung und Durchführung einer Evaluierung werden irgendwann alle drei Aspekte der
Motivation berücksichtigt. Der erste Aspekt, die Wahrscheinlichkeit eines Angriffs, ist das, was einen
Entwickler dazu veranlassen kann, eine Evaluierung durchzuführen. Wenn der Entwickler der Meinung ist,
dass die Angreifer ausreichend motiviert sind, einen Angriff zu starten, kann eine Evaluierung Gewissheit
darüber geben, ob der TOE in der Lage ist, die Bemühungen des Angreifers zu vereiteln. Wenn die
Betriebsumgebung klar definiert ist, z. B. bei einer Systemevaluierung, kann der Grad der Motivation für einen
Angriff bekannt sein und die Auswahl der Gegenmaßnahmen beeinflussen.
Unter Berücksichtigung des zweiten Aspekts kann ein Vermögensinhaber glauben, dass der Wert der
Vermögensgegenstände (wie auch immer bemessen) ausreicht, um einen Angriff gegen sie zu motivieren.
Sobald eine Evaluierung für notwendig erachtet wird, wird die Motivation des Angreifers in Betracht gezogen,
um die Angriffsverfahren, die unternommen werden können, sowie das Fachwissen und die Ressourcen, die
bei diesen Angriffen eingesetzt werden, zu bestimmen. Nach der Prüfung ist der Entwickler in der Lage, die
geeignete Vertrauenswürdigkeitsstufe, insbesondere die AVA-Anforderungskomponenten, entsprechend dem
Angriffspotential für die Bedrohungen zu wählen. Im Verlauf der Evaluierung und insbesondere als Ergebnis
des Abschlusses der Aufgabe zur Anfälligkeitsbewertung stellt der Evaluator fest, ob der TOE in seiner
Betriebsumgebung ausreicht, um Angreifer mit den identifizierten Fachkenntnissen und Ressourcen zu
vereiteln oder nicht.
Es kann für einen PP-Autor möglich sein, die Motivation eines Angreifers zu quantifizieren, da der PP-Autor
über größere Kenntnisse der Betriebsumgebung verfügt, in die der TOE (in Übereinstimmung mit den
Anforderungen des PP) gebracht werden soll. Daher könnte die Motivation einen expliziten Teil der
Darstellung des Angriffspotentials im PP bilden, zusammen mit den notwendigen Verfahren und Maßnahmen
zur Quantifizierung der Motivation.
334
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
B.4.2 Charakterisierung des Angriffspotentials

Dieser Unterabschnitt untersucht die Faktoren, die das Angriffspotential bestimmen, und bietet einige
Leitlinien, die helfen sollen, diesen Aspekt des Evaluierungsprozesses etwas von der Subjektivität zu
entfernen.
B.4.2.1 Bestimmung des Angriffspotentials
Die Bestimmung des Angriffspotentials für einen Angriff entspricht der Ermittlung des Aufwands, der
erforderlich ist, um den Angriff zu erstellen und nachzuweisen, dass er erfolgreich auf den TOE angewendet
werden kann (einschließlich der Einrichtung oder des Aufbaus der erforderlichen Prüfgeräte), wodurch die
Anfälligkeit im TOE ausgenutzt wird. Die Vorführung, dass der Angriff erfolgreich angewendet werden kann,
muss alle Schwierigkeiten bei der Erweiterung eines im Labor gezeigten Ergebnisses berücksichtigen, um
einen nützlichen Angriff zu schaffen. Wenn ein Experiment beispielsweise einige Bits oder Bytes eines
vertraulichen Datenelements (z. B. eines Schlüssels) aufdeckt, muss überlegt werden, wie der Rest des
Datenelements gewonnen werden könnte (in diesem Beispiel könnten einige Bits direkt durch weitere
Experimente gemessen werden, während andere durch eine andere Technik, wie z. B. eine erschöpfende
Suche, gefunden werden könnten). Möglicherweise müssen nicht alle Experimente durchgeführt werden, um
den vollständigen Angriff zu identifizieren, vorausgesetzt, es ist klar, dass der Angriff tatsächlich beweist, dass
der Zugriff auf einen TOE-Vermögenswert erlangt wurde, und dass der vollständige Angriff realistischerweise
unter Ausnutzung der angestrebten AVA_VAN-Komponente durchgeführt werden könnte. In einigen Fällen ist
der einzige Weg, um zu beweisen, dass ein Angriff realistischerweise unter Ausnutzung der angestrebten
AVA_VAN-Komponente durchgeführt werden kann, die vollständige Durchführung des Angriffs und die
anschließende Bewertung auf der Grundlage der tatsächlich benötigten Ressourcen. Als eines der Ergebnisse
der Identifizierung einer potentiellen Anfälligkeit wird ein Skript angenommen, das eine Schritt-für-Schritt-
Beschreibung der Durchführung des Angriffs enthält, die bei der Ausnutzung der Anfälligkeit an einer anderen
Instanz des TOEs verwendet werden kann.
In vielen Fällen werden die Evaluatoren die Parameter für die Ausnutzung schätzen, anstatt die vollständige
Ausnutzung durchzuführen. Die Schätzungen und ihre Begründung werden im ETR dokumentiert.
B.4.2.2 Zu berücksichtigende Faktoren
Die folgenden Faktoren sollten bei der Analyse des Angriffspotentials, das zur Ausnutzung einer Anfälligkeit
erforderlich ist, berücksichtigt werden:
a) Zeit, die zur Identifizierung und Ausnutzung benötigt wird (abgelaufene Zeit);
b) spezielle Sachkenntnis erforderlich (Fachwissen);
c) Kenntnisse über das Design und den Betrieb des TOEs (Wissen über den TOE);
d) Zugriffsgelegenheiten;
e) IT-Hardware/Software oder andere für die Ausnutzung erforderliche Ausrüstung.
In vielen Fällen sind diese Faktoren nicht unabhängig, sondern können sich in unterschiedlichem Maße
gegenseitig ersetzen. Zum Beispiel kann Fachwissen oder Hardware/Software ein Ersatz für Zeit sein. Eine
Erörterung dieser Faktoren folgt. (Die Stufen der einzelnen Faktoren werden in zunehmender Größenordnung
erörtert.) Wenn dies der Fall ist, wird die „erschwinglichere“ Kombination in der Phase der Ausnutzung in
Betracht gezogen.
335
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Abgelaufene Zeit ist die Gesamtzeit, die ein Angreifer benötigt, um zu erkennen, dass eine bestimmte
potentielle Anfälligkeit im TOE vorhanden sein könnte, um ein Angriffsverfahren zu entwickeln und um den
für den Angriff auf den TOE erforderlichen Aufwand aufrechtzuerhalten. Bei der Betrachtung dieses Faktors
wird das Worst-Case-Szenario zur Abschätzung des Zeitbedarfs herangezogen. Die identifizierte Zeitspanne
lautet wie folgt:
a) weniger als ein Tag;
b) zwischen einem Tag und einer Woche;
c) zwischen einer Woche und zwei Wochen;
d) zwischen zwei Wochen und einem Monat;
e) jeder weitere Monat bis zu 6 Monaten führt zu einem erhöhten Wert;
f) mehr als 6 Monate.
Fachwissen bezieht sich auf den generischen Kenntnisstand der zugrunde liegenden Prinzipien, des
Produkttyps oder der Angriffsverfahren (z. B. Internet-Protokolle, Unix-Betriebssysteme, Pufferüberläufe).
Die identifizierten Ebenen lauten wie folgt.
a) Laien sind im Vergleich zu Experten oder kompetenten Personen ohne besondere Fachkenntnisse
unwissend.
b) Kompetente Personen sind insofern sachkundig, als sie mit dem Sicherheitsverhalten des Produkt- oder
Systemtyps vertraut sind.
c) Experten sind mit den zugrunde liegenden Algorithmen, Protokollen, der Hardware, den Strukturen, dem
Sicherheitsverhalten, den Prinzipien und Konzepten der eingesetzten Sicherheit, den Techniken und
Toolsn für die Definition neuer Angriffe, der Kryptographie, den klassischen Angriffen für den Produkttyp,
den Angriffsverfahren usw., die im Produkt- oder Systemtyp implementiert sind, vertraut.
d) Die Stufe „Mehrfach-Experte“ wird eingeführt, um einer Situation Rechnung zu tragen, in der für
verschiedene Schritte eines Angriffs unterschiedliche Fachgebiete auf Expertenebene erforderlich sind.
Es kann vorkommen, dass mehrere Arten von Fachwissen erforderlich sind. Standardmäßig wird der höhere
der verschiedenen Faktoren des Fachwissens gewählt. In sehr spezifischen Fällen könnte die Ebene
„Mehrfach-Experte“ verwendet werden, aber es sollte beachtet werden, dass die Fachkenntnisse sich auf
Bereiche beziehen müssen, die sich strikt voneinander unterscheiden, wie z. B. HW-Manipulation und
Kryptographie.
Wissen über den TOE bezieht sich auf spezifische Fachkenntnisse in Bezug auf den TOE. Dies unterscheidet
sich von generischem Fachwissen, ist aber nicht ohne Bezug zu diesem. Die identifizierten Ebenen lauten wie
folgt:
a) öffentliche Informationen über den TOE (z. B. wie sie aus dem Internet gewonnen werden);
b) eingeschränkte Informationen bezüglich des TOEs (z. B. Wissen, das innerhalb der Entwickler-
organisation kontrolliert und mit anderen Organisationen im Rahmen einer Geheimhaltungs-
vereinbarung geteilt wird);
c) sensible Informationen über den TOE (z. B. Wissen, das zwischen diskreten Teams innerhalb der
Entwicklerorganisation ausgetauscht wird, wobei der Zugriff auf diese Informationen nur den Mitgliedern
der angegebenen Teams vorbehalten ist);
d) entscheidende Informationen über den TOE (z. B. Wissen, das nur einigen wenigen Personen bekannt ist,
dessen Zugriff sehr streng auf der Grundlage des strikten Wissensbedarfs und der individuellen
Verpflichtung kontrolliert wird).
336
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Das Wissen über den TOE kann entsprechend der Designabstraktion aufsteigen, obwohl dies nur auf der Basis
eines TOEs für jeden einzelnen TOE möglich ist. Einige TOE-Designs können aus öffentlichen Quellen stammen
(oder stark auf öffentlichen Quellen basieren), und daher würde sogar die Darstellung des Designs als
öffentlich oder höchstens eingeschränkt eingestuft werden, während die Darstellung der Implementierung für
andere TOEs sehr genau kontrolliert wird, da sie einem Angreifer Informationen liefern würde, die einen
Angriff unterstützen würden und daher als sensibel oder sogar kritisch angesehen wird.
Es kann vorkommen, dass mehrere Arten von Wissen erforderlich sind. In solchen Fällen wird der höhere der
verschiedenen Wissensfaktoren gewählt.
Zugriffsgelegenheiten (Gelegenheit) sind ebenfalls ein wichtiger Gesichtspunkt und stehen in Beziehung zum
Faktor abgelaufene Zeit. Das Erkennen oder Ausnutzen einer Anfälligkeit kann beträchtliche Mengen an
Zugriff auf einen TOE erfordern, was die Wahrscheinlichkeit der Entdeckung erhöhen kann. Einige
Angriffsverfahren können im Offline-Betrieb einen beträchtlichen Aufwand und nur einen kurzen Zugriff auf
den TOE zur Ausnutzung erfordern. Möglicherweise muss der Zugriff auch kontinuierlich oder über eine
Menge Sitzungen erfolgen.
Bei einigen TOEs können die Zugriffsgelegenheiten der Probenanzahl des TOEs entsprechen, die der
Angreifer erhalten kann. Dies ist besonders dann relevant, wenn Versuche, in den TOE einzudringen und die
SFRs zu untergraben, zur Zerstörung des TOEs führen können, wodurch die Verwendung dieser TOE-Probe
für weitere Prüfungen, z. B. von Hardware-Geräten, verhindert wird. Häufig wird in diesen Fällen die
Verteilung des TOEs kontrolliert, so dass der Angreifer Anstrengungen unternehmen muss, um weitere
Proben des TOEs zu erhalten.
Im Sinne dieser Erörterung
a) bedeutet unnötiger/unbeschränkter Zugriff, dass der Angriff keine Gelegenheit zur Realisierung benötigt,
da kein Risiko besteht, während des Zugriffs auf den TOE entdeckt zu werden, und es kein Problem ist,
auf die Anzahl der TOE-Proben für den Angriff zuzugreifen;
b) bedeutet einfach, dass der Zugriff weniger als einen Tag lang erforderlich ist und dass die Anzahl der
TOE-Proben, die zur Durchführung des Angriffs erforderlich sind, weniger als zehn beträgt;
c) bedeutet moderat, dass der Zugriff weniger als einen Monat lang erforderlich ist und dass die Anzahl der
TOE-Proben, die zur Durchführung des Angriffs erforderlich sind, weniger als einhundert beträgt;
d) bedeutet schwierig, dass der Zugriff mindestens einen Monat lang erforderlich ist oder dass die Anzahl
der TOE-Proben, die zur Durchführung des Angriffs erforderlich sind, mindestens einhundert beträgt;
e) bedeutet kein Zugriff, dass die Zugriffsgelegenheit für die Durchführung des Angriffs nicht ausreicht (die
Länge, für die der auszunutzende Vermögenswert verfügbar oder empfindlich ist, ist geringer als die für
die Durchführung des Angriffs erforderliche Länge der Gelegenheit – z. B. wenn der Schlüssel des
Vermögenswertes jede Woche geändert wird und der Angriff zwei Wochen benötigt); ein anderer Fall ist,
dass eine ausreichende Anzahl von TOE-Proben, die für die Durchführung des Angriffs erforderlich sind,
dem Angreifer nicht zugänglich ist – z. B. wenn der TOE eine Hardware ist und die Wahrscheinlichkeit,
den TOE während des Angriffs zu zerstören, anstatt erfolgreich zu sein, sehr hoch ist und der Angreifer
nur Zugang zu einer Stichprobe des TOEs hat.
Die Berücksichtigung dieses Faktors kann zu der Feststellung führen, dass es aufgrund von Anforderungen an
die zeitliche Verfügbarkeit, die größer als die Zeit der Gelegenheit ist, nicht möglich ist, die Ausnutzung
abzuschließen.
337
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
IT-Hardware/Software oder andere Ausrüstung bezieht sich auf die Ausrüstung, die erforderlich ist, um
eine Anfälligkeit zu erkennen oder auszunutzen.
a) Die Standardausrüstung steht dem Angreifer leicht zur Verfügung, entweder für die Identifizierung einer
Anfälligkeit oder für einen Angriff. Diese Ausrüstung kann ein Teil des TOEs selbst sein (z. B. ein Debugger
in einem Betriebssystem) oder leicht erhältlich sein (z. B. Internet-Downloads, Protokollanalysator oder
einfache Angriffsskripte).
b) Spezielle Ausrüstung steht dem Angreifer nicht ohne weiteres zur Verfügung, könnte aber ohne
unangemessenen Aufwand erworben werden. Dazu könnte die Anschaffung einer moderaten Menge an
Ausrüstung gehören (z. B. Stromanalyse-Tools, die Nutzung von Hunderten von über das Internet
verbundenen PCs würde in diese Kategorie fallen) oder die Entwicklung umfangreicherer Angriffsskripte
oder -programme. Wenn für verschiedene Schritte eines Angriffs deutlich unterschiedliche Prüfstände
mit spezieller Ausrüstung erforderlich sind, würde dies als maßgeschneidert eingestuft werden.
c) Maßgeschneiderte Geräte sind der Öffentlichkeit nicht ohne weiteres zugänglich, da sie unter Umständen
speziell hergestellt werden müssen (z. B. sehr anspruchsvolle Software) oder weil die Geräte so
spezialisiert sind, dass ihr Vertrieb kontrolliert, möglicherweise sogar eingeschränkt ist. Alternativ kann
die Ausrüstung sehr teuer sein.
d) Die Stufe „Mehrfach maßgeschneidert“ wird eingeführt, um einer Situation Rechnung zu tragen, in der
verschiedene Arten von maßgeschneiderter Ausrüstung für verschiedene Schritte eines Angriffs
erforderlich sind.
Fachwissen und Wissen über den TOE betreffen die Informationen, die für Personen erforderlich sind, um
einen TOE angreifen zu können. Es besteht eine implizite Beziehung zwischen dem Fachwissen eines
Angreifers (wobei es sich bei dem Angreifer um eine oder mehrere Personen mit sich ergänzenden
Wissensgebieten handeln kann) und der Fähigkeit, die Ausrüstung bei einem Angriff effektiv zu nutzen. Je
schwächer das Fachwissen des Angreifers, desto geringer ist die Möglichkeit, Ausrüstung (IT-Hardware/
Software oder andere Geräte) zu verwenden. Ebenso gilt: Je größer das Fachwissen, desto größer ist das
Potential, dass bei dem Angriff Ausrüstung einzusetzen ist. Obwohl implizit, gilt diese Beziehung zwischen
Fachwissen und dem Einsatz von Ausrüstung nicht immer, z. B. wenn Maßnahmen in Bezug auf die Umgebung
den Einsatz von Ausrüstung durch einen sachkundigen Angreifer verhindern oder wenn durch die
Bemühungen anderer Angriffstools, die wenig Fachwissen erfordern, um effektiv eingesetzt zu werden,
geschaffen und frei verbreitet werden (z. B. über das Internet).
B.4.2.3 Berechnung des Angriffspotentials
In Tabelle B.2 werden die im vorigen Unterabschnitt erörterten Faktoren identifiziert und numerische Werte
mit dem Gesamtwert jedes Faktors verknüpft.
Wenn ein Faktor nahe an die Grenze eines Bereichs fällt, sollte der Evaluator die Verwendung eines
Zwischenwerts zu den in der Tabelle angegebenen Werten in Betracht ziehen. Wenn beispielsweise zwanzig
Stichproben zur Durchführung des Angriffs erforderlich sind, kann für diesen Faktor ein Wert zwischen eins
und vier gewählt werden, oder wenn das Design auf einem öffentlich zugänglichen Design basiert, der
Entwickler jedoch einige Änderungen vorgenommen hat, sollte ein Wert zwischen null und drei gewählt
werden, je nachdem, wie der Evaluator die Auswirkungen dieser Entwurfsänderungen einschätzt. Die Tabelle
ist als Leitfaden gedacht.
Die Angabe „**“ in der Tabelle bei der Betrachtung von „Zugriffsgelegenheiten“ ist nicht als eine natürliche
Progression von den Zeitskalen zu sehen, die in den vorhergehenden, mit diesem Faktor verbundenen
Bereichen angegeben sind. Diese Spezifikation stellt fest, dass die potentielle Anfälligkeit aus einem
bestimmten Grund im TOE in seiner vorgesehenen Betriebsumgebung nicht ausgenutzt werden kann.
Beispielsweise kann der Zugriff auf den TOE in einem TOE mit bekannter Umgebung (d. h. im Fall eines
Systems), in der regelmäßige Kontrollgänge durchgeführt werden, nach einer gewissen Zeit entdeckt werden,
und der Angreifer könnte die erforderlichen zwei Wochen lang unentdeckt keinen Zugriff auf den TOE
erhalten. Dies gilt jedoch nicht für einen TOE, der an das Netzwerk angeschlossen ist, an dem ein Fernzugriff
möglich ist oder wo die physische Umgebung des TOEs unbekannt ist.
338
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Tabelle B.2 — Berechnung des Angriffspotentials
Faktor Wert
Abgelaufene Zeit
ein Tag 0
eine Woche 1
zwei Wochen 2
ein Monat 4
zwei Monate 7
drei Monate 10
vier Monate 13
fünf Monate 15
sechs Monate 17
> sechs Monate 19
Fachwissen
Laie 0
Kompetent 3* a
Experte 6
Mehrfach-Experten 8
Wissen über den TOE
Öffentlich 0
Eingeschränkt 3
Sensibel 7
Kritisch 11
Zugriffsgelegenheiten
Unnötiger/unbeschränkter Zugriff 0
Einfach 1
Moderat 4
Schwierig 10
Kein Zugriff ** b
Ausrüstung
Standard 0
Speziell 4c
Maßgeschneidert 7
Mehrfach maßgeschneidert 9
a Wenn mehrere kompetente Personen erforderlich sind, um den Angriffspfad zu vollenden, bleibt der resultierende Grad des
Fachwissens immer noch „kompetent“ (was zu einer Bewertung von 3 führt).
b Zeigt an, dass der Angriffspfad aufgrund anderer Maßnahmen in der vorgesehenen Betriebsumgebung des TOEs nicht
ausnutzbar ist.
c Wenn für verschiedene Schritte eines Angriffs deutlich unterschiedliche Prüfstände mit spezieller Ausrüstung erforderlich sind,
sollte dies als maßgeschneidert eingestuft werden.
339
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Um die Beständigkeit des TOEs gegenüber den identifizierten potentiellen Anfälligkeiten zu bestimmen,
sollten die folgenden Schritte angewendet werden.
a) Die möglichen Angriffsszenarien {AS1, AS2, ..., ASn} werden für den TOE in der Betriebsumgebung
definiert.
b) Für jedes Angriffsszenario wird eine theoretische Analyse durchgeführt und das entsprechende
Angriffspotential anhand von Tabelle B.2 berechnet.
c) Für jedes Angriffsszenario werden gegebenenfalls Penetrationstests durchgeführt, um die theoretische

Analyse zu bestätigen oder zu widerlegen.
d) Alle Angriffsszenarien {AS1, AS2, ..., ASn} werden in zwei Gruppen aufgeteilt:
1) die Angriffsszenarien, die erfolgreich waren (d. h. diejenigen, die zur erfolgreichen Untergrabung der
SFRs verwendet wurden); und
2) die Angriffsszenarien, die sich als erfolglos erwiesen haben.
e) Für jedes erfolgreiche Angriffsszenario wird Tabelle B.3 angewendet und festgestellt, ob ein Widerspruch
zwischen der Beständigkeit des TOEs und der gewählten AVA_VAN-Vertrauenswürdigkeitskomponente
besteht (siehe letzte Spalte von Tabelle B.3).
f) Sollte ein Widerspruch festgestellt werden, wird die Anfälligkeitsbewertung fehlschlagen, z. B. hat der
Autor der ST die Komponente AVA_VAN.5 gewählt und ein Angriffsszenario mit einem Angriffspotential
von 21 Punkten (hoch) hat die Sicherheit des TOEs verletzt. In diesem Fall ist der TOE gegen Angreifer
mit Angriffspotential Moderat resistent, dies steht im Widerspruch zu AVA_VAN.5, daher schlägt die
Anfälligkeitsbewertung fehl.
Die Spalte „Werte“ in Tabelle B.3 gibt den Bereich der (nach Tabelle B.2 berechneten) Werte des Angriffs-
potentials eines Angriffsszenarios an, das zu einer Untergrabung der SFRs führt.
Tabelle B.3 — Bewertung von Anfälligkeiten und TOE-Beständigkeit
Zur Ausnutzung TOE-Beständigkeit

Erfüllt Vertrauens-
des Szenarios gegen Angreifer Versagen der
Werte würdigkeits-
erforderliches mit folgendem Komponenten:
komponenten:
Angriffspotential: Angriffspotential:
AVA_VAN.1,
AVA_VAN.2,
0-9 Basic keine Bewertung - AVA_VAN.3,
AVA_VAN.4,
AVA_VAN.5
AVA_VAN.3,
AVA_VAN.1,
10-13 Enhanced-Basic Basic AVA_VAN.4,
AVA_VAN.2
AVA_VAN.5
AVA_VAN.1,
AVA_VAN.4,
14-19 Moderate Enhanced-Basic AVA_VAN.2,
AVA_VAN.5
AVA_VAN.3
340
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Zur Ausnutzung TOE-Beständigkeit

Erfüllt Vertrauens-
des Szenarios gegen Angreifer Versagen der
Werte würdigkeits-
erforderliches mit folgendem Komponenten:
komponenten:
Angriffspotential: Angriffspotential:
AVA_VAN.1,
AVA_VAN.2,
20-24 High Moderate AVA_VAN.5
AVA_VAN.3,
AVA_VAN.4
AVA_VAN.1,
AVA_VAN.2,
25 Beyond High High AVA_VAN.3, -
AVA_VAN.4,
AVA_VAN.5
Ein Ansatz wie dieser kann nicht jeden Umstand oder Faktor berücksichtigen, sollte aber einen besseren
Hinweis auf den Grad der Beständigkeit gegen Angriffe geben, der erforderlich ist, um die Standard-
einstufungen zu erreichen. Andere Faktoren, wie z. B. die Abhängigkeit von unwahrscheinlichen Zufalls-
ereignissen, sind nicht im Basismodell enthalten, können aber von einem Evaluator als Begründung für eine
andere Bewertung als die, die das Basismodell angeben könnte, verwendet werden.
Es sollte beachtet werden, dass eine Menge Anfälligkeiten, die einzeln bewertet werden, auf eine hohe
Beständigkeit gegen Angriffe hindeuten können, während die Kombination von Anfälligkeiten zusammen-
genommen darauf hindeuten kann, dass insgesamt eine niedrigere Bewertung zutrifft. Eine vorhandene
Anfälligkeit kann eine andere leichter ausnutzbar machen.
Wenn ein PP/ST-Autor die Angriffspotentialtabelle für die Bestimmung der Angriffsebene, der der TOE
standhalten sollte (Auswahl der Komponente Anfälligkeitsanalyse (AVA_VAN)), verwenden möchte, sollte er
wie folgt vorgehen: Für alle verschiedenen Angriffsszenarien (d. h. für alle verschiedenen Arten von
Angreifern und/oder verschiedene Arten von Angriffen, die der Autor im Sinn hat), die die SFRs nicht verletzen
dürfen, sollten mehrere Durchläufe über Tabelle B.2 durchgeführt werden, um die verschiedenen Werte des
Angriffspotentials zu bestimmen, die für jedes dieser erfolglosen Angriffsszenarien angenommen werden. Der
PP/ST-Autor wählt dann den höchsten Wert von ihnen, um den Grad der zu beanspruchenden
TOE-Beständigkeit aus Tabelle B.3 zu bestimmen: Die TOE-Beständigkeit muss mindestens diesem
ermittelten Höchstwert entsprechen. Der so ermittelte Höchstwert der Angriffspotentiale aller Angriffs-
szenarien, die die Sicherheitspolitik des TOEs nicht untergraben dürfen, ist z. B. Moderate; daher muss die
Beständigkeit des TOEs mindestens Moderate (d. h. Moderate oder High) sein; daher kann der PP/ST-Autor
entweder AVA_VAN.4 (für Moderate) oder AVA_VAN.5 (für High) als geeignete Vertrauenswürdigkeits-
komponente wählen.
B.5 Beispielrechnung für direkten Angriff

Mechanismen, die einem direkten Angriff ausgesetzt sind, sind oft lebenswichtig für die Systemsicherheit, und
die Entwickler verstärken diese Mechanismen oft. Als Beispiel könnte ein TOE einen einfachen Passnummern-
Authentisierungsmechanismus verwenden, der von einem Angreifer überwunden werden kann, der die
Gelegenheit hat, wiederholt die Passnummer eines anderen Benutzers zu erraten. Das System kann diesen
Mechanismus stärken, indem es die Passnummern und ihre Verwendung auf verschiedene Weise einschränkt.
Im Verlauf der Evaluierung könnte eine Analyse dieses direkten Angriffs wie folgt ablaufen:
341
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)
Aus den Informationen, die aus der ST und den Designnachweisen gewonnen wurden, geht hervor, dass die
Identifizierung und Authentifizierung die Grundlage für die Kontrolle des Zugriffs auf Netzwerkressourcen
von weit verteilten Terminals aus darstellt. Der physische Zugriff auf die Terminals wird nicht durch wirksame
Mittel kontrolliert. Die Dauer des Zugriffs auf ein Terminal wird nicht durch wirksame Mittel kontrolliert.
Autorisierte Benutzer des Systems wählen ihre eigenen Passnummern bei der ersten Autorisierung zur
Nutzung des Systems und danach auf Benutzeranfrage. Das System schränkt die vom Benutzer ausgewählten
Passnummern wie folgt ein:
a) die Passnummer muss mindestens vier und darf nicht mehr als sechs Ziffern haben;
b) aufeinanderfolgende Zahlenfolgen sind nicht zulässig (z. B. 7,6,5,4,3);
c) die Wiederholung von Ziffern ist nicht zulässig (jede Ziffer darf nur einmal vorkommen).
Die Leitlinien, die den Benutzern bei der Auswahl der Passnummer gegeben werden, legen fest, dass die
Passnummern so zufällig wie möglich sein sollten und nicht in irgendeiner Weise mit dem Benutzer
verbunden sein sollten – zum Beispiel ein Geburtsdatum.
Der Passnummernraum wird wie folgt berechnet:
a) Menschliche Nutzungsmuster sind wichtige Überlegungen, die die Vorgehensweise bei der Suche in einem
Passwort-Raum beeinflussen können. Angenommen, der Benutzer wählt im schlimmsten Fall eine Zahl,
die nur aus vier Ziffern besteht, dann gilt Folgendes für die Anzahl der Permutationen der Passnummer
unter der Annahme, dass jede Ziffer nur einmal vorkommen darf:
7(8)(9)(10) = 5 040
b) Die Anzahl der möglichen aufsteigenden Sequenzen beträgt sieben, ebenso wie die Anzahl der
absteigenden Sequenzen. Passnummernraum nach der Sperrung von Sequenzen ist:
5 040 14 = 5 026
Auf der Grundlage weiterer Informationen, die sich aus den Designnachweisen ergeben haben, wurde der
Passnummernmechanismus mit einer Terminalverriegelungsfunktion ausgestattet. Nach dem sechsten
fehlgeschlagenen Authentisierungsversuch wird das Terminal eine Stunde gesperrt. Die Zählung der
fehlgeschlagenen Authentisierungen wird nach fünf Minuten zurückgesetzt, so dass ein Angreifer bestenfalls
alle fünf Minuten fünf Passnummerneingaben oder 60 Passnummerneingaben je Stunde versuchen kann.
Im Durchschnitt müsste ein Angreifer 2 513 Passnummern eingeben, also mehr als 2 513 Minuten, bevor er
die richtige Passnummer eingeben kann. Der durchschnittliche erfolgreiche Angriff würde demzufolge in
etwas weniger als einem Jahr stattfinden:
2 513 min
42 Stunden
min
60
Stunde
Die Verwendung des im vorigen Unterabschnitt beschriebenen Ansatzes zur Berechnung des Angriffs-
potentials zeigt, dass es möglich ist, dass ein Laie innerhalb von Tagen (bei leichtem Zugriff auf den TOE), unter
Verwendung von Standardausrüstung und ohne Wissen über den TOE den Mechanismus außer Funktion
setzen kann, was einen Wert von 1 ergibt. Angesichts der sich daraus ergebenden Summe 1 wird das
Angriffspotential, das für einen erfolgreichen Angriff erforderlich ist, nicht bewertet, da es unter dem als Basic
angesehenen liegt.
342

Din en Iso Iec 18045 2021-02

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Din en Iso Iec 18045 2021-02

Hochgeladen von

Copyright:

Verfügbare Formate

DEUTSCHE NORM Februar 2021

DIN EN ISO/IEC 18045

Gesamtumfang 344 Seiten

DIN-Normenausschuss Informationstechnik und Anwendungen (NIA)

Das zuständige nationale Normungsgremium ist der Arbeitskreis NA 043-01-27-03 AK „Evaluationskriterien

DIN EN ISO/IEC 15408 (alle Teile), Informationstechnik — IT-Sicherheitsverfahren —- Evaluationskriterien

Diese Europäische Norm wurde vom CEN am 2. März 2020 angenommen.

CEN-CENELEC Management Centre:

Europäisches Vorwort .......................................................................................................................................................... 7

8.5.1 Evaluierung der Unteraufgabe (APE_SPD.1) ............................................................................................... 37

10.8.3 Evaluierung der Unteraufgabe (ADV_TDS.3)............................................................................................ 134

13.4.2 Evaluierung der Unteraufgabe (ATE_DPT.2)............................................................................................ 223

B.2.2 Identifizierung potentieller Anfälligkeiten............................................................................................... 329

Entsprechend der CEN-CENELEC-Geschäftsordnung sind die nationalen Normungsinstitute der folgenden

Kanada: Communications Security Establishment;

Frankreich: Direction Centrale de la Sécurité des Systèmes d'Information;

Deutschland: Bundesamt für Sicherheit in der Informationstechnik;

Japan: Information Technology Promotion Agency;

Niederlande: Netherlands National Communications Security Agency;

Spanien: Ministerio de Administraciones Públicas und Centro Criptológico Nacional;

Vereinigtes Königreich: Communications-Electronic Security Group;

ANMERKUNG Vertrauenswürdigkeitsfamilien werden in dieser Internationalen Norm nicht explizit behandelt, da

ANMERKUNG Siehe auch Gesamtentscheidung.

4 Symbole und Abkürzungen

OR Beobachtungsbericht (en: observation report)

5.1 Gliederung dieser Internationalen Norm

Abschnitt 6 definiert die in dieser Internationalen Norm verwendeten Konventionen.

Abschnitt 7 beschreibt allgemeine Evaluierungsarbeitsaufgaben, mit denen keine Entscheidungen verbunden

6.3 Allgemeine Evaluierungsleitlinien

7 Evaluierungsprozess und damit verbundene Arbeitsaufgaben

7.2 Überblick über den Evaluierungsprozess

a) Rollen und Verantwortlichkeiten der in den Evaluierungsprozess einbezogenen Parteien;

b) das allgemeine Evaluierungsmodell.

7.2.2 Verantwortlichkeiten der Rollen

7.2.3 Beziehung der Rollen

7.2.4 Allgemeines Evaluierungsmodell

Bild 2 — Generisches Evaluierungsmodell

Bild 3 — Beispiel der Entscheidungszuordnungsregel

1) die einzelnen Workunits der entsprechenden Aktion der Evaluierungsmethodologie, und

7.3 Eingabearbeitsaufgabe der Evaluierung

7.3.3 Management der Teilarbeitsaufgabe der Evaluationsnachweise

Der Evaluator muss die Konfigurationsüberwachung der Evaluationsnachweise durchführen.

a) Rückgabe der Evaluationsnachweise;

b) Archivierung der Evaluationsnachweise;

c) Vernichtung der Evaluationsnachweise.

7.5 Ausgabearbeitsaufgabe der Evaluierung

a) OR-Teilarbeitsaufgabe schreiben (falls im Zusammenhang mit der Evaluierung benötigt);

7.5.2 Management der Evaluierungsausgaben

7.5.4 OR-Teilarbeitsaufgabe schreiben

Bei jedem OR muss der Evaluator Folgendes angeben:

a) den Bezeichner des evaluierten PP oder TOE;

b) die Evaluierungsarbeitsaufgabe/-Unteraufgabe, während der die Beobachtung gemacht wurde;

f) den empfohlenen Zeitplan für die Lösung;

7.5.5 ETR-Teilarbeitsaufgabe schreiben

7.5.5.2 ETR für eine PP-Evaluierung

Bild 4 — ETR-Informationsgehalt für eine PP-Evaluierung

Der Evaluator muss die Schemabezeichner der Evaluierung angeben.

Der Evaluator muss die ETR-Bezeichner der Konfigurationsüberwachung angeben.

Der Evaluator muss die PP-Bezeichner der Konfigurationsüberwachung angeben.

Der Evaluator muss die Identität des Entwicklers angeben.

Der Evaluator muss die Identität des Antragstellers angeben.

Der Evaluator muss die Identität des Evaluators angeben.

7.5.5.2.3 Ergebnisse der Evaluierung