Sie sind auf Seite 1von 344

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 Anwendungshinweise.......................................................................................................................................... 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.2 Anwendungshinweise.......................................................................................................................................... 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.4.4 Evaluierung der Unteraufgabe (ADV_FSP.4)............................................................................................. 105
10.4.5 Evaluierung der Unteraufgabe (ADV_FSP.5)............................................................................................. 111
10.4.6 Evaluierung der Unteraufgabe (ADV_FSP.6)............................................................................................. 118
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.6.2 Evaluierung der Unteraufgabe (ADV_INT.2)............................................................................................. 123
10.6.3 Evaluierung der Unteraufgabe (ADV_INT.3)............................................................................................. 125
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
10.8.2 Evaluierung der Unteraufgabe (ADV_TDS.2)............................................................................................ 129

3
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

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


10.8.4 Evaluierung der Unteraufgabe (ADV_TDS.4)............................................................................................ 144
10.8.5 Evaluierung der Unteraufgabe (ADV_TDS.5)............................................................................................ 155
10.8.6 Evaluierung der Unteraufgabe (ADV_TDS.6)............................................................................................ 155
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.2.2 Evaluierung der Unteraufgabe (ALC_CMC.2) ............................................................................................ 162
12.2.3 Evaluierung der Unteraufgabe (ALC_CMC.3) ............................................................................................ 164
12.2.4 Evaluierung der Unteraufgabe (ALC_CMC.4) ............................................................................................ 168
12.2.5 Evaluierung der Unteraufgabe (ALC_CMC.5) ............................................................................................ 174
12.3 CM-Umfang (ALC_CMS)...................................................................................................................................... 181
12.3.1 Evaluierung der Unteraufgabe (ALC_CMS.1) ............................................................................................ 181
12.3.2 Evaluierung der Unteraufgabe (ALC_CMS.2) ............................................................................................ 182
12.3.3 Evaluierung der Unteraufgabe (ALC_CMS.3) ............................................................................................ 183
12.3.4 Evaluierung der Unteraufgabe (ALC_CMS.4) ............................................................................................ 184
12.3.5 Evaluierung der Unteraufgabe (ALC_CMS.5) ............................................................................................ 185
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.6.2 Evaluierung der Unteraufgabe (ALC_FLR.2) ............................................................................................. 196
12.6.3 Evaluierung der Unteraufgabe (ALC_FLR.3) ............................................................................................. 200
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
12.8.2 Evaluierung der Unteraufgabe (ALC_TAT.2) ............................................................................................ 211
12.8.3 Evaluierung der Unteraufgabe (ALC_TAT.3) ............................................................................................ 213
13 Klasse ATE: Prüfungen...................................................................................................................................... 216
13.1 Einleitung .............................................................................................................................................................. 216
13.2 Anwendungshinweise....................................................................................................................................... 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.3.2 Evaluierung der Unteraufgabe (ATE_COV.2) ............................................................................................ 219
13.3.3 Evaluierung der Unteraufgabe (ATE_COV.3) ............................................................................................ 221
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.4.2 Evaluierung der Unteraufgabe (ATE_DPT.2)............................................................................................ 223


13.4.3 Evaluierung der Unteraufgabe (ATE_DPT.3)............................................................................................ 226
13.4.4 Evaluierung der Unteraufgabe (ATE_DPT.4)............................................................................................ 229
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
13.6.2 Evaluierung der Unteraufgabe (ATE_IND.2)............................................................................................. 237
13.6.3 Evaluierung der Unteraufgabe (ATE_IND.3)............................................................................................. 242
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
14.2.2 Evaluierung der Unteraufgabe (AVA_VAN.2) ........................................................................................... 248
14.2.3 Evaluierung der Unteraufgabe (AVA_VAN.3) ........................................................................................... 255
14.2.4 Evaluierung der Unteraufgabe (AVA_VAN.4) ........................................................................................... 264
14.2.5 Evaluierung der Unteraufgabe (AVA_VAN.5) ........................................................................................... 272
15 Klasse ACO: Zusammensetzung..................................................................................................................... 273
15.1 Einleitung .............................................................................................................................................................. 273
15.2 Anwendungshinweise....................................................................................................................................... 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.4.2 Evaluierung der Unteraufgabe (ACO_DEV.2)............................................................................................ 282
15.4.3 Evaluierung der Unteraufgabe (ACO_DEV.3)............................................................................................ 284
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
15.7.2 Evaluierung der Unteraufgabe (ACO_VUL.2) ............................................................................................ 301
15.7.3 Evaluierung der Unteraufgabe (ACO_VUL.3) ............................................................................................ 305
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)

8.3.1.1 Zielsetzungen

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)

8.3.1.3.2 Workunit APE_INT.1-2

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.

8.3.1.3.3 Workunit APE_INT.1-3

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.

8.3.1.3.4 Workunit APE_INT.1-4

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.

8.3.1.3.5 Workunit APE_INT.1-5

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)

8.4.1.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

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.

8.4.1.3.2 Workunit APE_CCL.1-2

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.

8.4.1.3.3 Workunit APE_CCL.1-3

Der Evaluator muss prüfen, ob der Konformitätsanspruch nach ISO/IEC 15408 entweder den Anspruch
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)

8.4.1.3.4 Workunit APE_CCL.1-4

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.

8.4.1.3.5 Workunit APE_CCL.1-5

Der Evaluator muss den Konformitätsanspruch nach ISO/IEC 15408 mit der ISO/IEC 15408-3 untersuchen,
um festzustellen, dass er gegenüber der erweiterten Komponentendefinition konsistent ist.

Wenn der Konformitätsanspruch nach ISO/IEC 15408 ISO/IEC 15408-3-konform enthält, stellt der Evaluator
fest, dass die erweiterte Komponentendefinition keine Vertrauenswürdigkeitskomponenten definiert.

Wenn der Konformitätsanspruch nach ISO/IEC 15408 ISO/IEC 15408-3-erweitert enthält, stellt der Evaluator
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.

8.4.1.3.6 Workunit APE_CCL.1-6

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.

8.4.1.3.7 Workunit APE_CCL.1-7

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)

8.4.1.3.8 Workunit APE_CCL.1-8

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.

8.4.1.3.9 Workunit APE_CCL.1-9

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.

Wenn das PP nicht die Konformität mit einem anderen PP beansprucht, ist diese Workunit nicht anwendbar
und gilt daher als erfüllt.

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.

8.4.1.3.10 Workunit APE_CCL.1-10

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
Sicherheitszielsetzungen für den TOE im PP, mit dem Konformität beansprucht wird, angesprochen
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.

ISO/IEC 15408-3 APE_CCL.1.9C: Die Begründung für den Konformitätsanspruch muss nachweisen, dass die
Aussage zu den Sicherheitszielsetzungen mit der Aussage der Sicherheitszielsetzungen in den PPs konsistent ist,
für die Konformität beansprucht wird.

8.4.1.3.11 Workunit APE_CCL.1-11

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.

Wenn das PP nicht die Konformität mit einem anderen PP beansprucht, 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

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
Sicherheitszielsetzungen für den TOE im PP, mit dem Konformität beansprucht wird, angesprochen
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.

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 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.

ISO/IEC 15408-3 APE_CCL.1.10C: Die Begründung für den Konformitätsanspruch muss nachweisen, dass die
Aussage zu den Sicherheitsanforderungen mit der Aussage zu den Sicherheitsanforderungen in den PPs konsistent
ist, für die Konformität beansprucht wird.

8.4.1.3.12 Workunit APE_CCL.1-12

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.

Wenn das PP nicht die Konformität mit einem anderen PP beansprucht, 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 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.

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 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.

8.4.1.3.13 Workunit APE_CCL.1-13

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)

8.5.1.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

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.

8.5.1.3.2 Workunit APE_SPD.1-2

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.

8.5.1.3.3 Workunit APE_SPD.1-3

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.

8.5.1.3.4 Workunit APE_SPD.1-4

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)

8.6.1.1 Zielsetzungen

Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob die Sicherheitszielsetzungen für die
Betriebsumgebung klar definiert sind.

8.6.1.2 Eingaben

Der Evaluationsnachweis für diese Unteraufgabe ist

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)

8.6.2.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

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.

8.6.2.3.1 Workunit APE_OBJ.2-1

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.

8.6.2.3.2 Workunit APE_OBJ.2-2

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)

8.6.2.3.3 Workunit APE_OBJ.2-3

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.

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 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.

8.6.2.3.4 Workunit APE_OBJ.2-4

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.

ISO/IEC 15408-3 APE_OBJ.2.5C: Die Begründung für die Sicherheitszielsetzungen muss nachweisen, dass die
Sicherheitszielsetzungen alle OSPs durchsetzen.

8.6.2.3.5 Workunit APE_OBJ.2-5

Der Evaluator muss die Begründung der Sicherheitszielsetzungen untersuchen, um festzustellen, ob sie für
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“.

ISO/IEC 15408-3 APE_OBJ.2.6C: Die Begründung für die Sicherheitszielsetzungen muss nachweisen, dass die
Sicherheitszielsetzungen für die Betriebsumgebung alle Annahmen einhalten.

8.6.2.3.6 Workunit APE_OBJ.2-6

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)

8.7.1.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

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.

8.7.1.3.2 Workunit APE_ECD.1-2

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.

8.7.1.3.3 Workunit APE_ECD.1-3

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.

Enthält das PP keine erweiterten Sicherheitsanforderungen, ist diese Workunit nicht anwendbar und gilt
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.

8.7.1.3.4 Workunit APE_ECD.1-4

Der Evaluator muss die erweiterte Komponentendefinition untersuchen, um festzustellen, dass jede
Definition einer erweiterten Komponente alle anwendbaren Abhängigkeiten dieser Komponente identifiziert.

Enthält das PP keine erweiterten Sicherheitsanforderungen, ist diese Workunit nicht anwendbar und gilt
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.

8.7.1.3.5 Workunit APE_ECD.1-5

Der Evaluator muss die erweiterte Komponentendefinition untersuchen, um festzustellen, dass jede
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.

8.7.1.3.6 Workunit APE_ECD.1-6

Der Evaluator muss die erweiterte Komponentendefinition untersuchen, um festzustellen, dass jede
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.

8.7.1.3.7 Workunit APE_ECD.1-7

Der Evaluator muss die erweiterte Komponentendefinition untersuchen, um festzustellen, dass jede
Definition einer neuen Funktionsklasse die bestehenden Funktionsklassen der ISO/IEC 15408 als Modell für
die Darstellung verwendet.

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)

8.7.1.3.8 Workunit APE_ECD.1-8

Der Evaluator muss die erweiterte Komponentendefinition untersuchen, um festzustellen, dass jede
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.

8.7.1.3.9 Workunit APE_ECD.1-9

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.

8.7.1.3.10 Workunit APE_ECD.1-10

Der Evaluator muss die erweiterte Komponentendefinition untersuchen, um festzustellen, dass jede
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.

8.7.1.3.11 Workunit APE_ECD.1-11

Der Evaluator muss die erweiterte Komponentendefinition untersuchen, um festzustellen, dass jede
Definition einer neuen Vertrauenswürdigkeitsklasse die bestehenden Vertrauenswürdigkeitsklassen der
ISO/IEC 15408 als Modell für die Darstellung verwendet.

Wenn das PP keine neuen Vertrauenswürdigkeitsklassen definiert, ist diese Workunit nicht anwendbar und
gilt daher als erfüllt.

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)

8.7.1.3.12 Workunit APE_ECD.1-12

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.

Enthält das PP keine erweiterten Sicherheitsanforderungen, ist diese Workunit nicht anwendbar und gilt
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

8.7.1.4.1 Workunit APE_ECD.1-13

Der Evaluator muss die erweiterte Komponentendefinition untersuchen, um festzustellen, dass jede
erweiterte Komponente nicht eindeutig durch vorhandene Komponenten ausgedrückt werden kann.

Enthält das PP keine erweiterten Sicherheitsanforderungen, ist diese Workunit nicht anwendbar und gilt
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)

8.8.1.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

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.

8.8.1.3.2 Workunit APE_REQ.1-2

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:

a) durch Verweisung auf eine einzelne Komponente in ISO/IEC 15408-3;

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 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.

8.8.1.3.3 Workunit APE_REQ.1-3

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.

8.8.1.3.4 Workunit APE_REQ.1-4

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.

8.8.1.3.6 Workunit APE_REQ.1-6

Der Evaluator muss die Aussage der Sicherheitsanforderungen untersuchen, um festzustellen, dass alle
Iterationsoperationen 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.

47
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

8.8.1.3.7 Workunit APE_REQ.1-7

Der Evaluator muss die Aussage der Sicherheitsanforderungen untersuchen, um festzustellen, dass alle
Auswahloperationen 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.

8.8.1.3.8 Workunit APE_REQ.1-8

Der Evaluator muss die Aussage der Sicherheitsanforderungen untersuchen, um festzustellen, dass alle
Präzisierungsoperationen 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.

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.

8.8.1.3.9 Workunit APE_REQ.1-9

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.

8.8.1.3.10 Workunit APE_REQ.1-10

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)

8.8.2.1 Zielsetzungen

Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob die SFRs und SARs klar, eindeutig und
genau definiert sind, ob sie in sich konsistent sind und ob die SFRs die Sicherheitszielsetzungen des TOEs
erfüllen.

8.8.2.2 Eingaben

Der Evaluationsnachweis für diese Unteraufgabe ist

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.

8.8.2.3.1 Workunit APE_REQ.2-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 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;

e) durch Vervielfältigung im PP.

Es ist nicht erforderlich, für alle SFRs das gleiche Identifizierungsmittel zu verwenden.

49
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

8.8.2.3.2 Workunit APE_REQ.2-2

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:

a) durch Verweisung auf eine einzelne Komponente in ISO/IEC 15408-3;

b) durch Verweisung auf eine erweiterte Komponente in der erweiterten Komponentendefinition des PP;

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;

e) durch Vervielfältigung im PP.

Es ist nicht erforderlich, für alle SARs das gleiche Identifizierungsmittel zu verwenden.

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.

8.8.2.3.3 Workunit APE_REQ.2-3

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);

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.

50
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

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.2.3C: Die Aussage zu den Sicherheitsanforderungen muss alle Operationen im
Zusammenhang mit den Sicherheitsanforderungen identifizieren.

8.8.2.3.4 Workunit APE_REQ.2-4

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.2.4C: Alle Operationen müssen korrekt durchgeführt werden.

8.8.2.3.5 Workunit APE_REQ.2-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.

8.8.2.3.6 Workunit APE_REQ.2-6

Der Evaluator muss die Aussage der Sicherheitsanforderungen untersuchen, um festzustellen, dass alle
Iterationsoperationen 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.

8.8.2.3.7 Workunit APE_REQ.2-7

Der Evaluator muss die Aussage der Sicherheitsanforderungen untersuchen, um festzustellen, dass alle
Auswahloperationen 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.

8.8.2.3.8 Workunit APE_REQ.2-8

Der Evaluator muss die Aussage der Sicherheitsanforderungen untersuchen, um festzustellen, dass alle
Präzisierungsoperationen 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.

ISO/IEC 15408-3 APE_REQ.2.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.

51
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

8.8.2.3.9 Workunit APE_REQ.2-9

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
Sicherheitsanforderungen 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 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
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.2.6C: Die Begründung für die Sicherheitsanforderungen muss jede SFR zu den
Sicherheitszielsetzungen für den TOE zurückverfolgen.

8.8.2.3.10 Workunit APE_REQ.2-10

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.

8.8.2.3.11 Workunit APE_REQ.2-11

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,
die sich auf diese Workunit bezieht, mit einer „abgelehnt“-Entscheidung belegt.

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.

8.8.2.3.12 Workunit APE_REQ.2-12

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.

8.8.2.3.13 Workunit APE_REQ.2-13

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.

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.

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 Anwendungshinweise

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)

9.3.1.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

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.

9.3.1.3.2 Workunit ASE_INT.1-2

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.

9.3.1.3.3 Workunit ASE_INT.1-3

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.

9.3.1.3.4 Workunit ASE_INT.1-4

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)

9.3.1.3.5 Workunit ASE_INT.1-5

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.

9.3.1.3.6 Workunit ASE_INT.1-6

Der Evaluator muss prüfen, dass der TOE-Überblick den TOE-Typ identifiziert.

9.3.1.3.7 Workunit ASE_INT.1-7

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.

9.3.1.3.8 Workunit ASE_INT.1-8

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)

9.3.1.3.9 Workunit ASE_INT.1-9

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.

9.3.1.3.10 Workunit ASE_INT.1-10

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

9.3.1.4.1 Workunit ASE_INT.1-11

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)

9.4.1.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

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.

9.4.1.3.2 Workunit ASE_CCL.1-2

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 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)

9.4.1.3.3 Workunit ASE_CCL.1-3

Der Evaluator muss prüfen, ob der Konformitätsanspruch nach ISO/IEC 15408 entweder den Anspruch
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.

9.4.1.3.4 Workunit ASE_CCL.1-4

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.

9.4.1.3.5 Workunit ASE_CCL.1-5

Der Evaluator muss den Konformitätsanspruch nach ISO/IEC 15408 mit der ISO/IEC 15408-3 untersuchen,
um festzustellen, dass er gegenüber der erweiterten Komponentendefinition konsistent ist.

Wenn der Konformitätsanspruch nach ISO/IEC 15408 ISO/IEC 15408-3-konform enthält, stellt der Evaluator
fest, dass die erweiterte Komponentendefinition keine Vertrauenswürdigkeitskomponenten definiert.

Wenn der Konformitätsanspruch nach ISO/IEC 15408 ISO/IEC 15408-3-erweitert enthält, stellt der Evaluator
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.

9.4.1.3.6 Workunit ASE_CCL.1-6

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)

9.4.1.3.7 Workunit ASE_CCL.1-7

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.

9.4.1.3.8 Workunit ASE_CCL.1-8

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.

9.4.1.3.9 Workunit ASE_CCL.1-9

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.

Wenn die ST nicht die Konformität mit einem PP beansprucht, ist diese Workunit nicht anwendbar und gilt
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
ist, für die Konformität beansprucht wird.

9.4.1.3.10 Workunit ASE_CCL.1-10

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 die ST nicht die Konformität mit einem PP beansprucht, ist diese Workunit nicht anwendbar und gilt
daher als erfüllt.

Wenn das PP 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 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.

ISO/IEC 15408-3 ASE_CCL.1.9C: Die Begründung für den Konformitätsanspruch muss nachweisen, dass die
Aussage zu den Sicherheitszielsetzungen mit der Aussage zu den Sicherheitszielsetzungen in den PPs konsistent
ist, für die Konformität beansprucht wird.

9.4.1.3.11 Workunit ASE_CCL.1-11

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.

Wenn die ST nicht die Konformität mit einem PP beansprucht, 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:

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.

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 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.

ISO/IEC 15408-3 ASE_CCL.1.10C: Die Begründung für den Konformitätsanspruch muss nachweisen, dass die
Aussage zu den Sicherheitsanforderungen mit der Aussage zu den Sicherheitsanforderungen in den PPs konsistent
ist, für die Konformität beansprucht wird.

9.4.1.3.12 Workunit ASE_CCL.1-12

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.

Wenn die ST nicht die Konformität mit einem PP beansprucht, 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 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.

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 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.

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 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)

9.5.1.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

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.

Wenn alle Sicherheitszielsetzungen nur aus Annahmen und/oder OSPs abgeleitet werden, muss die Aussage
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.

9.5.1.3.2 Workunit ASE_SPD.1-2

Der Evaluator muss die Sicherheitsproblemdefinition untersuchen, um festzustellen, dass alle Bedrohungen
anhand eines Bedrohungsagenten, eines Vermögenswertes und einer unerwünschten Aktion beschrieben
werden.

Wenn alle Sicherheitszielsetzungen nur aus Annahmen und/oder OSPs abgeleitet werden, muss die Aussage
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.

9.5.1.3.3 Workunit ASE_SPD.1-3

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.

9.5.1.3.4 Workunit ASE_SPD.1-4

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)

9.6.1.1 Zielsetzungen

Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob die Sicherheitszielsetzungen für die
Betriebsumgebung klar definiert sind.

9.6.1.2 Eingaben

Der Evaluationsnachweis für diese Unteraufgabe ist

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)

9.6.2.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

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.

9.6.2.3.1 Workunit ASE_OBJ.2-1

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.

9.6.2.3.2 Workunit ASE_OBJ.2-2

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 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)

9.6.2.3.3 Workunit ASE_OBJ.2-3

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.

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 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.

9.6.2.3.4 Workunit ASE_OBJ.2-4

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
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.

ISO/IEC 15408-3 ASE_OBJ.2.5C: Die Begründung für die Sicherheitszielsetzungen muss nachweisen, dass die
Sicherheitszielsetzungen alle OSPs durchsetzen.

9.6.2.3.5 Workunit ASE_OBJ.2-5

Der Evaluator muss die Begründung der Sicherheitszielsetzungen untersuchen, um festzustellen, ob sie für
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.

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“.

ISO/IEC 15408-3 ASE_OBJ.2.6C: Die Begründung für die Sicherheitszielsetzungen muss nachweisen, dass die
Sicherheitszielsetzungen für die Betriebsumgebung alle Annahmen einhalten.

9.6.2.3.6 Workunit ASE_OBJ.2-6

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)

9.7.1.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

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.

9.7.1.3.2 Workunit ASE_ECD.1-2

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.

9.7.1.3.3 Workunit ASE_ECD.1-3

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.

Enthält die ST keine erweiterten Sicherheitsanforderungen, ist diese Workunit nicht anwendbar und gilt 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, 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.

9.7.1.3.4 Workunit ASE_ECD.1-4

Der Evaluator muss die erweiterte Komponentendefinition untersuchen, um festzustellen, dass jede
Definition einer erweiterten Komponente alle anwendbaren Abhängigkeiten dieser Komponente identifiziert.

Enthält die ST keine erweiterten Sicherheitsanforderungen, ist diese Workunit nicht anwendbar und gilt daher
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.

9.7.1.3.5 Workunit ASE_ECD.1-5

Der Evaluator muss die erweiterte Komponentendefinition untersuchen, um festzustellen, dass jede
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.

9.7.1.3.6 Workunit ASE_ECD.1-6

Der Evaluator muss die erweiterte Komponentendefinition untersuchen, um festzustellen, dass jede
Definition einer neuen Funktionsfamilie die bestehenden Funktionsfamilien der ISO/IEC 15408 als Modell für
die Darstellung verwendet.

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.

9.7.1.3.7 Workunit ASE_ECD.1-7

Der Evaluator muss die erweiterte Komponentendefinition untersuchen, um festzustellen, dass jede
Definition einer neuen Funktionsklasse die bestehenden Funktionsklassen der ISO/IEC 15408 als Modell für
die Darstellung verwendet.

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)

9.7.1.3.8 Workunit ASE_ECD.1-8

Der Evaluator muss die erweiterte Komponentendefinition untersuchen, um festzustellen, dass jede
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.

9.7.1.3.9 Workunit ASE_ECD.1-9

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.

9.7.1.3.10 Workunit ASE_ECD.1-10

Der Evaluator muss die erweiterte Komponentendefinition untersuchen, um festzustellen, dass jede
Definition einer neuen Vertrauenswürdigkeitsfamilie die bestehenden Vertrauenswürdigkeitsfamilien der
ISO/IEC 15408 als Modell für die Darstellung verwendet.

Wenn die ST 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.

9.7.1.3.11 Workunit ASE_ECD.1-11

Der Evaluator muss die erweiterte Komponentendefinition untersuchen, um festzustellen, dass jede
Definition einer neuen Vertrauenswürdigkeitsklasse die bestehenden Vertrauenswürdigkeitsklassen der
ISO/IEC 15408 als Modell für die Darstellung verwendet.

Wenn die ST keine neuen Vertrauenswürdigkeitsklassen definiert, ist diese Workunit nicht anwendbar und
gilt daher als erfüllt.

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)

9.7.1.3.12 Workunit ASE_ECD.1-12

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.

Enthält die ST keine erweiterten Sicherheitsanforderungen, ist diese Workunit nicht anwendbar und gilt 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.

9.7.1.4 Aktion ASE_ECD.1.2E

9.7.1.4.1 Workunit ASE_ECD.1-13

Der Evaluator muss die erweiterte Komponentendefinition untersuchen, um festzustellen, dass jede
erweiterte Komponente nicht eindeutig durch vorhandene Komponenten ausgedrückt werden kann.

Enthält die ST keine erweiterten Sicherheitsanforderungen, ist diese Workunit nicht anwendbar und gilt 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 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)

9.8.1.1 Zielsetzungen

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.

9.8.1.2 Eingaben

Der Evaluationsnachweis für diese Unteraufgabe ist

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)

9.8.1.3.1 Workunit ASE_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 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.

Es ist nicht erforderlich, für alle SFRs das gleiche Identifizierungsmittel zu verwenden.

9.8.1.3.2 Workunit ASE_REQ.1-2

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:

a) durch Verweisung auf eine einzelne Komponente in ISO/IEC 15408-3;

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.

Es ist nicht erforderlich, für alle SARs das gleiche Identifizierungsmittel zu verwenden.

ISO/IEC 15408-3 ASE_REQ.1.2C: Alle Subjekte, Objekte, Operationen, Sicherheitsattribute, externen Entitäten
und andere in den SFRs und SARs verwendeten Begriffe müssen definiert sein.

9.8.1.3.3 Workunit ASE_REQ.1-3

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:

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);

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.

75
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

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 ST 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 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
Zusammenhang mit den Sicherheitsanforderungen identifizieren.

9.8.1.3.4 Workunit ASE_REQ.1-4

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. 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.

9.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.

9.8.1.3.6 Workunit ASE_REQ.1-6

Der Evaluator muss die Aussage der Sicherheitsanforderungen untersuchen, um festzustellen, dass alle
Iterationsoperationen 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.

9.8.1.3.7 Workunit ASE_REQ.1-7

Der Evaluator muss die Aussage der Sicherheitsanforderungen untersuchen, um festzustellen, dass alle
Auswahloperationen 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.

76
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

9.8.1.3.8 Workunit ASE_REQ.1-8

Der Evaluator muss die Aussage der Sicherheitsanforderungen untersuchen, um festzustellen, dass alle
Präzisierungsoperationen 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.

ISO/IEC 15408-3 ASE_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.

9.8.1.3.9 Workunit ASE_REQ.1-9

Der Evaluator muss die Aussage der Sicherheitsanforderungen untersuchen, um festzustellen, dass jede
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.

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 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
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 ASE_REQ.1.6C: Die Aussage zu den Sicherheitsanforderungen muss in sich konsistent sein.

9.8.1.3.10 Workunit ASE_REQ.1-10

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.

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;

77
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

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.

9.8.2 Evaluierung der Unteraufgabe (ASE_REQ.2)

9.8.2.1 Zielsetzungen

Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob die SFRs und SARs klar, eindeutig und
genau definiert sind, ob sie in sich konsistent sind und ob die SFRs die Sicherheitszielsetzungen des TOEs
erfüllen.

9.8.2.2 Eingaben

Der Evaluationsnachweis für diese Unteraufgabe ist

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.

9.8.2.3.1 Workunit ASE_REQ.2-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 der ST;

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;

e) durch Vervielfältigung in der ST.

Es ist nicht erforderlich, für alle SFRs das gleiche Identifizierungsmittel zu verwenden.

9.8.2.3.2 Workunit ASE_REQ.2-2

Der Evaluator muss prüfen, ob die Aussage der Sicherheitsanforderungen die SARs beschreibt.

Der Evaluator stellt fest, dass alle SARs auf eine der folgenden Arten identifiziert wird:

a) durch Verweisung auf eine einzelne Komponente in ISO/IEC 15408-3;

b) durch Verweisung auf eine erweiterte Komponente in der erweiterten Komponentendefinition der ST;

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;

e) durch Vervielfältigung in der ST.

Es ist nicht erforderlich, für alle SARs das gleiche Identifizierungsmittel zu verwenden.

ISO/IEC 15408-3 ASE_REQ.2.2C: Alle Subjekte, Objekte, Operationen, Sicherheitsattribute, externen Entitäten
und andere in den SFRs und SARs verwendeten Begriffe müssen definiert sein.

9.8.2.3.3 Workunit ASE_REQ.2-3

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:

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);
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 ST 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 in der
übrigen ST verwendet werden.

ISO/IEC 15408-3 ASE_REQ.2.3C: Die Aussage zu den Sicherheitsanforderungen muss alle Operationen im
Zusammenhang mit den Sicherheitsanforderungen identifizieren.

79
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

9.8.2.3.4 Workunit ASE_REQ.2-4

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. 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.

9.8.2.3.5 Workunit ASE_REQ.2-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.

9.8.2.3.6 Workunit ASE_REQ.2-6

Der Evaluator muss die Aussage der Sicherheitsanforderungen untersuchen, um festzustellen, dass alle
Iterationsoperationen 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.

9.8.2.3.7 Workunit ASE_REQ.2-7

Der Evaluator muss die Aussage der Sicherheitsanforderungen untersuchen, um festzustellen, dass alle
Auswahloperationen 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.

9.8.2.3.8 Workunit ASE_REQ.2-8

Der Evaluator muss die Aussage der Sicherheitsanforderungen untersuchen, um festzustellen, dass alle
Präzisierungsoperationen 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.

ISO/IEC 15408-3 ASE_REQ.2.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.

9.8.2.3.9 Workunit ASE_REQ.2-9

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.

80
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

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
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 ASE_REQ.2.6C: Die Begründung für die Sicherheitsanforderungen muss jede SFR zu den
Sicherheitszielsetzungen für den TOE zurückverfolgen.

9.8.2.3.10 Workunit ASE_REQ.2-10

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.

9.8.2.3.11 Workunit ASE_REQ.2-11

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,
die sich auf diese Workunit bezieht, mit einer „abgelehnt“-Entscheidung belegt.

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)

9.8.2.3.12 Workunit ASE_REQ.2-12

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.

9.8.2.3.13 Workunit ASE_REQ.2-13

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.

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 Vertrauenswürdigkeitsanforderung, 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.

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)

9.9.1.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

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.

9.9.1.4 Aktion ASE_TSS.1.2E

9.9.1.4.1 Workunit ASE_TSS.1-2

Der Evaluator muss die zusammenfassende Spezifikation des TOEs untersuchen, um festzustellen, dass sie
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)

9.9.2.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

a) die ST.

9.9.2.3 Aktion ASE_TSS.2.1E

ISO/IEC 15408-3 ASE_TSS.2.1C: Die zusammenfassende Spezifikation des TOEs muss beschreiben, wie der TOE
jede SFR erfüllt.

9.9.2.3.1 Workunit ASE_TSS.2-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.

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.

9.9.2.3.2 Workunit ASE_TSS.2-2

Der Evaluator muss die zusammenfassende Spezifikation des TOEs untersuchen, um festzustellen, dass sie
beschreibt, wie sich der TOE gegen Störungen und logische Eingriffe schützt.

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

9.9.2.3.3 Workunit ASE_TSS.2-3

Der Evaluator muss die zusammenfassende Spezifikation des TOEs untersuchen, um festzustellen, dass sie
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)

9.9.2.4 Aktion ASE_TSS.2.2E

9.9.2.4.1 Workunit ASE_TSS.2-4

Der Evaluator muss die zusammenfassende Spezifikation des TOEs untersuchen, um festzustellen, dass sie
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).

10.2 Anwendungshinweise

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)

10.3.1.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

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.

10.3.1.4.2 Workunit ADV_ARC.1-2

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.

10.3.1.4.3 Workunit ADV_ARC.1-3

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.

10.3.1.4.4 Workunit ADV_ARC.1-4

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.

10.3.1.4.5 Workunit ADV_ARC.1-5

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)

10.4.1.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

a) die ST,

b) die Funktionsspezifikation,

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.

10.4.1.3.2 Workunit ADV_FSP.1-2

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)

10.4.1.3.3 Workunit ADV_FSP.1-3

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.

10.4.1.3.4 Workunit ADV_FSP.1-4

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.

10.4.1.3.5 Workunit ADV_FSP.1-5

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)

10.4.1.4 Aktion ADV_FSP.1.2E

10.4.1.4.1 Workunit ADV_FSP.1-6

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.

10.4.1.4.2 Workunit ADV_FSP.1-7

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.

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 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.

10.4.2 Evaluierung der Unteraufgabe (ADV_FSP.2)

10.4.2.1 Zielsetzungen

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,

b) die Funktionsspezifikation,

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.

10.4.2.3 Aktion ADV_FSP.2.1E

ISO/IEC 15408-3 ADV_FSP.2.1C: Die Funktionsspezifikation muss die TSF vollständig darstellen.

10.4.2.3.1 Workunit ADV_FSP.2-1

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.

ISO/IEC 15408-3 ADV_FSP.2.2C: Die Funktionsspezifikation muss den Zweck und die Verwendungsmethode für
alle TSFIs beschreiben.

10.4.2.3.2 Workunit ADV_FSP.2-2

Der Evaluator muss die Funktionsspezifikation untersuchen, um festzustellen, dass sie den Zweck jeder 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 als eine Aussage, die dem Leser helfen soll, 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
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)

10.4.2.3.3 Workunit ADV_FSP.2-3

Der Evaluator muss die Funktionsspezifikation untersuchen, um festzustellen, dass die Verwendungs-
methode für jede TSFI gegeben ist.

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 Funktions-
spezifikation 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.

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.

10.4.2.3.4 Workunit ADV_FSP.2-4

Der Evaluator muss die Darstellung der TSFI untersuchen, um festzustellen, dass sie alle Parameter
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.

10.4.2.3.5 Workunit ADV_FSP.2-5

Der Evaluator muss die Darstellung der TSFI untersuchen, um festzustellen, dass sie alle Parameter
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,
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.

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.

10.4.2.3.6 Workunit ADV_FSP.2-6

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
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.

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.

10.4.2.3.7 Workunit ADV_FSP.2-7

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)

10.4.2.3.8 Workunit ADV_FSP.2-8

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.

10.4.2.4 Aktion ADV_FSP.2.2E

10.4.2.4.1 Workunit ADV_FSP.2-9

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.2-8 für 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 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.

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

10.4.2.4.2 Workunit ADV_FSP.2-10

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.

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 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.

99
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

10.4.3 Evaluierung der Unteraufgabe (ADV_FSP.3)

10.4.3.1 Zielsetzungen

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

Der von den Workunits geforderte Evaluationsnachweis für diese Unteraufgabe ist

a) die ST,

b) die Funktionsspezifikation,

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 Darstellung der Implementierung,

c) die Beschreibung der TSF-Interna,

d) die operativen Leitlinien für Benutzer.

10.4.3.3 Aktion ADV_FSP.3.1E

ISO/IEC 15408-3 ADV_FSP.3.1C: Die Funktionsspezifikation muss die TSF vollständig darstellen.

10.4.3.3.1 Workunit ADV_FSP.3-1

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.

ISO/IEC 15408-3 ADV_FSP.3.2C: Die Funktionsspezifikation muss den Zweck und die Verwendungsmethode für
alle TSFIs beschreiben.

100
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

10.4.3.3.2 Workunit ADV_FSP.3-2

Der Evaluator muss die Funktionsspezifikation untersuchen, um festzustellen, dass sie den Zweck jeder 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 als eine Aussage, die dem Leser helfen soll, 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
berücksichtigt, wie z. B. die Beschreibung der Aktionen und Fehlermeldungen.

10.4.3.3.3 Workunit ADV_FSP.3-3

Der Evaluator muss die Funktionsspezifikation untersuchen, um festzustellen, dass die Verwendungs-
methode für jede TSFI gegeben ist.

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 Funktions-
spezifikation 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.

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.3.3C: Die Funktionsspezifikation muss alle Parameter identifizieren und beschreiben,
die mit jeder TFSI verknüpft sind.

10.4.3.3.4 Workunit ADV_FSP.3-4

Der Evaluator muss die Darstellung der TSFI untersuchen, um festzustellen, dass sie alle Parameter
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.

101
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

10.4.3.3.5 Workunit ADV_FSP.3-5

Der Evaluator muss die Darstellung der TSFI untersuchen, um festzustellen, dass sie alle Parameter
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.

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

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.

10.4.3.3.6 Workunit ADV_FSP.3-6

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
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.

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.

10.4.3.3.7 Workunit ADV_FSP.3-7

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.

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

103
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

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 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.

10.4.3.3.8 Workunit ADV_FSP.3-8

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.

ISO/IEC 15408-3 ADV_FSP.3.7C: Die Rückverfolgung muss nachweisen, dass die SFRs auf TSFIs in der
Funktionsspezifikation zurückgehen.

10.4.3.3.9 Workunit ADV_FSP.3-9

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.

104
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

10.4.3.4 Aktion ADV_FSP.3.2E

10.4.3.4.1 Workunit ADV_FSP.3-10

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.3-9 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, 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.

10.4.3.4.2 Workunit ADV_FSP.3-11

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.

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 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.

10.4.4 Evaluierung der Unteraufgabe (ADV_FSP.4)

10.4.4.1 Zielsetzungen

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

Der von den Workunits geforderte Evaluationsnachweis für diese Unteraufgabe ist

a) die ST,

b) die Funktionsspezifikation,

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 Darstellung der Implementierung,

c) die Beschreibung der TSF-Interna,

d) die operativen Leitlinien für Benutzer.

10.4.4.3 Anwendungshinweise

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.

10.4.4.4 Aktion ADV_FSP.4.1E

ISO/IEC 15408-3 ADV_FSP.4.1C: Die Funktionsspezifikation muss die TSF vollständig darstellen.

106
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

10.4.4.4.1 Workunit ADV_FSP.4-1

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.

ISO/IEC 15408-3 ADV_FSP.4.2C: Die Funktionsspezifikation muss den Zweck und die Verwendungsmethode für
alle TSFIs beschreiben.

10.4.4.4.2 Workunit ADV_FSP.4-2

Der Evaluator muss die Funktionsspezifikation untersuchen, um festzustellen, dass sie den Zweck jeder 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 als eine Aussage, die dem Leser helfen soll, 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
berücksichtigt, wie z. B. die Beschreibung der Aktionen und Fehlermeldungen.

10.4.4.4.3 Workunit ADV_FSP.4-3

Der Evaluator muss die Funktionsspezifikation untersuchen, um festzustellen, dass die Verwendungs-
methode für jede TSFI gegeben ist.

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 Funktions-
spezifikation 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.

Der Evaluator sollte nicht nur feststellen, dass es eine Menge Beschreibungen der Verwendungsmethode gibt,
sondern auch, dass sie jede TSFI genau abdecken.

107
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

10.4.4.4.4 Workunit ADV_FSP.4-4

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.3C: Die Funktionsspezifikation muss alle Parameter identifizieren und beschreiben,
die mit jeder TFSI verknüpft sind.

10.4.4.4.5 Workunit ADV_FSP.4-5

Der Evaluator muss die Darstellung der TSFI untersuchen, um festzustellen, dass sie alle Parameter
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.

10.4.4.4.6 Workunit ADV_FSP.4-6

Der Evaluator muss die Darstellung der TSFI untersuchen, um festzustellen, dass sie alle Parameter
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.

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

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)

10.4.4.4.7 Workunit ADV_FSP.4-7

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.

10.4.4.4.8 Workunit ADV_FSP.4-8

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.

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 die Festplatte 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 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.

10.4.4.4.9 Workunit ADV_FSP.4-9

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.4.6C: Die Rückverfolgung muss nachweisen, dass die SFRs auf TSFIs in der
Funktionsspezifikation zurückgehen.

10.4.4.4.10Workunit ADV_FSP.4-10

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.

10.4.4.5 Aktion ADV_FSP.4.2E

10.4.4.5.1 Workunit ADV_FSP.4-11

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.4-10 für 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.

110
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

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

10.4.4.5.2 Workunit ADV_FSP.4-12

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.

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 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.

10.4.5 Evaluierung der Unteraufgabe (ADV_FSP.5)

10.4.5.1 Zielsetzungen

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

Der von den Workunits geforderte Evaluationsnachweis für diese Unteraufgabe ist

a) die ST,

b) die Funktionsspezifikation,

c) das TOE-Design,

d) die Darstellung der Implementierung.

111
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

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 Beschreibung der TSF-Interna,

c) das formelle Sicherheitspolitikmodell,

d) die operativen Leitlinien für Benutzer.

10.4.5.3 Aktion ADV_FSP.5.1E

ISO/IEC 15408-3 ADV_FSP.5.1C: Die Funktionsspezifikation muss die TSF vollständig darstellen.

10.4.5.3.1 Workunit ADV_FSP.5-1

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.

ISO/IEC 15408-3 ADV_FSP.5.2C: Die Funktionsspezifikation muss die TSFI in einem semiformalen Stil
beschreiben.

10.4.5.3.2 Workunit ADV_FSP.5-2

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.

ISO/IEC 15408-3 ADV_FSP.5.3C: Die Funktionsspezifikation muss den Zweck und die Verwendungsmethode für
alle TSFIs beschreiben.

112
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

10.4.5.3.3 Workunit ADV_FSP.5-3

Der Evaluator muss die Funktionsspezifikation untersuchen, um festzustellen, dass sie den Zweck jeder 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 als eine Aussage, die dem Leser helfen soll, 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
berücksichtigt, wie z. B. die Beschreibung der Aktionen und Fehlermeldungen.

10.4.5.3.4 Workunit ADV_FSP.5-4

Der Evaluator muss die Funktionsspezifikation untersuchen, um festzustellen, dass die Verwendungs-
methode für jede TSFI gegeben ist.

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 Funktions-
spezifikation 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.

Der Evaluator sollte nicht nur feststellen, dass es eine Menge Beschreibungen der Verwendungsmethode gibt,
sondern auch, dass sie jede TSFI genau abdecken.

10.4.5.3.5 Workunit ADV_FSP.5-5

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.5.4C: Die Funktionsspezifikation muss alle Parameter identifizieren und beschreiben,
die mit jeder TFSI verknüpft sind.

113
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

10.4.5.3.6 Workunit ADV_FSP.5-6

Der Evaluator muss die Darstellung der TSFI untersuchen, um festzustellen, dass sie alle Parameter
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.

10.4.5.3.7 Workunit ADV_FSP.5-7

Der Evaluator muss die Darstellung der TSFI untersuchen, um festzustellen, dass sie alle Parameter
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.

Um festzustellen, ob die Beschreibung der Parameter vollständig ist, sollte der Evaluator die restliche
Schnittstellenbeschreibung (Zweck, Verwendungsmethoden, 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,
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.

ISO/IEC 15408-3 ADV_FSP.5.5C: Die Funktionsspezifikation muss alle Aktionen beschreiben, die mit jeder TFSI
verknüpft sind.

10.4.5.3.8 Workunit ADV_FSP.5-8

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.

10.4.5.3.9 Workunit ADV_FSP.5-9

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.

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 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)

10.4.5.3.10Workunit ADV_FSP.5-10

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.

10.4.5.3.11Workunit ADV_FSP.5-11

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.

10.4.5.3.12Workunit ADV_FSP.5-12

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.

ISO/IEC 15408-3 ADV_FSP.5.9C: Die Rückverfolgung muss nachweisen, dass die SFRs auf TSFIs in der
Funktionsspezifikation zurückgehen.

10.4.5.3.13Workunit ADV_FSP.5-13

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.

10.4.5.4 Aktion ADV_FSP.5.2E

10.4.5.4.1 Workunit ADV_FSP.5-14

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.5-13 für 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 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)
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.

10.4.5.4.2 Workunit ADV_FSP.5-15

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.

117
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

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 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.

10.4.6 Evaluierung der Unteraufgabe (ADV_FSP.6)

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)

10.5.1.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

a) die Darstellung der Implementierung,

b) die Dokumentation der Entwicklungstools, wie sie sich aus ALC_TAT ergibt,

c) die Beschreibung des TOEs-Designs.

10.5.1.3 Anwendungshinweise

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.

10.5.1.4.2 Workunit ADV_IMP.1-2

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.

10.5.1.4.3 Workunit ADV_IMP.1-3

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)

Es gibt keine allgemeine Anleitung; das Schema sollte für diese Unteraufgabe konsultiert werden.

10.6 TSF-Interna (ADV_INT)

10.6.1 Evaluierung der Unteraufgabe (ADV_INT.1)

10.6.1.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

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.

10.6.1.3 Anwendungshinweise

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.

10.6.1.4.2 Workunit ADV_INT.1-2

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.

10.6.1.4.3 Workunit ADV_INT.1-3

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.

10.6.1.5 Aktion ADV_INT.1.2E

10.6.1.5.1 Workunit ADV_INT.1-4

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)

10.6.1.5.2 Workunit ADV_INT.1-5

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.

10.6.2 Evaluierung der Unteraufgabe (ADV_INT.2)

10.6.2.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

a) die Beschreibung des modularen Designs,

b) die Darstellung der Implementierung (wenn ADV_IMP Teil der beanspruchten Vertrauenswürdigkeit ist),

c) die Beschreibung der TSF-Interna,

d) die Dokumentation der Codierungsstandards, wie sie sich aus ALC_TAT ergibt.

10.6.2.3 Anwendungshinweise

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.

10.6.2.4 Aktion ADV_INT.2.1E

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)

10.6.2.4.1 Workunit ADV_INT.2-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 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.

10.6.2.4.2 Workunit ADV_INT.2-2

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.

10.6.2.5 Aktion ADV_INT.2.2E

10.6.2.5.1 Workunit ADV_INT.2-3

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.

10.6.2.5.2 Workunit ADV_INT.2-4

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.6.3 Evaluierung der Unteraufgabe (ADV_INT.3)

Es gibt keine allgemeine Anleitung; das Schema sollte für diese Unteraufgabe konsultiert werden.

10.7 Modellierung der Sicherheitspolitik (ADV_SPM)

10.7.1 Evaluierung der Unteraufgabe (ADV_SPM.1)

Es gibt keine allgemeine Anleitung; das Schema sollte für diese Unteraufgabe konsultiert werden.

10.8 TOE-Design (ADV_TDS)

10.8.1 Evaluierung der Unteraufgabe (ADV_TDS.1)

10.8.1.1 Eingaben

Der Evaluationsnachweis für diese Unteraufgabe ist

a) die ST,
b) die Funktionsspezifikation,
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.

10.8.1.2.2 Workunit ADV_TDS.1-2

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.

10.8.1.2.3 Workunit ADV_TDS.1-3

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.

10.8.1.2.4 Workunit ADV_TDS.1-4

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.

10.8.1.2.5 Workunit ADV_TDS.1-5

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)

10.8.1.2.6 Workunit ADV_TDS.1-6

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.

10.8.1.3 Aktion ADV_TDS.1.2E

10.8.1.3.1 Workunit ADV_TDS.1-7

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.

10.8.1.3.2 Workunit ADV_TDS.1-8

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 Evaluierung der Unteraufgabe (ADV_TDS.2)

10.8.2.1 Eingaben

Der Evaluationsnachweis für diese Unteraufgabe ist

a) die ST,

b) die Funktionsspezifikation,

c) die Beschreibung der Sicherheitsarchitektur,

d) das TOE-Design.

10.8.2.2 Aktion ADV_TDS.2.1E

ISO/IEC 15408-3 ADV_TDS.2.1C: Das Design muss die Struktur des TOEs in Form von Teilsystemen beschreiben.

10.8.2.2.1 Workunit ADV_TDS.2-1

Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass die Struktur des gesamten TOEs 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.2-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.

Der TOE (und die TSF) kann (können) in mehreren Abstraktionsschichten (d. h. Teilsystemen und Modulen)
beschrieben werden. Je nach Komplexität des TOEs 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.2.2C: Das Design muss alle Teilsysteme der TSF identifizieren.

129
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

10.8.2.2.2 Workunit ADV_TDS.2-2

Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass alle Teilsysteme der TSF identifiziert
werden.

In Workunit ADV_TDS.2-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.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.

10.8.2.2.3 Workunit ADV_TDS.2-3

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.

10.8.2.2.4 Workunit ADV_TDS.2-4

Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass er eine vollständige, genaue und
detaillierte Beschreibung des SFR-durchsetzenden Verhaltens der SFR-durchsetzenden Teilsysteme liefert.

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. 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.

10.8.2.2.5 Workunit ADV_TDS.2-5

Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass er eine vollständige, genaue und
allgemeine Beschreibung des SFR-unterstützenden und SFR-nicht-störenden Verhaltens der SFR-durch-
setzenden Teilsysteme liefert.

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.

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)

10.8.2.2.6 Workunit ADV_TDS.2-6

Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass er eine vollständige, genaue und
allgemeine Beschreibung des Verhaltens der SFR-unterstützenden Teilsysteme liefert.

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.

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.

10.8.2.2.7 Workunit ADV_TDS.2-7

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 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), 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.2.8C: Die Zuordnung muss nachweisen, dass sich alle TSFIs auf das im von ihnen
aufgerufenen TOE-Design beschriebene Verhalten zurückverfolgen lassen.

10.8.2.2.8 Workunit ADV_TDS.2-8

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.

10.8.2.3 Aktion ADV_TDS.2.2E

10.8.2.3.1 Workunit ADV_TDS.2-9

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.

133
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

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.

10.8.2.3.2 Workunit ADV_TDS.2-10

Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass es eine genaue Instanziierung aller
funktionalen Sicherheitsanforderungen darstellt.

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.3 Evaluierung der Unteraufgabe (ADV_TDS.3)

10.8.3.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

a) die ST,

b) die Funktionsspezifikation,

c) die Beschreibung der Sicherheitsarchitektur,

d) die TOE-Gestaltung.

10.8.3.3 Anwendungshinweise

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.

10.8.3.4 Aktion ADV_TDS.3.1E

ISO/IEC 15408-3 ADV_TDS.3.1C: Das Design muss die Struktur des TOEs in Form von Teilsystemen beschreiben.

135
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

10.8.3.4.1 Workunit ADV_TDS.3-1

Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass die Struktur des gesamten TOEs 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.3-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.

Der TOE (und die TSF) kann (können) in mehreren Abstraktionsschichten (d. h. Teilsystemen und Modulen)
beschrieben werden. Je nach Komplexität des TOEs 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.
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.

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.3.2C: Das Design muss die TSF in Form von Modulen beschreiben.

10.8.3.4.2 Workunit ADV_TDS.3-2

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).

ISO/IEC 15408-3 ADV_TDS.3.3C: Das Design muss alle Teilsysteme der TSF identifizieren.

136
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

10.8.3.4.3 Workunit ADV_TDS.3-3

Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass alle Teilsysteme der TSF identifiziert
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.

In Workunit ADV_TDS.3-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.3.4C: Das Design muss eine Beschreibung jedes Teilsystems der TSF bereitstellen.

10.8.3.4.4 Workunit ADV_TDS.3-4

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.

10.8.3.4.5 Workunit ADV_TDS.3-5

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.

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.

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.

137
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

Der Evaluator stellt sicher, dass alle Teilsysteme der TSF eine Beschreibung haben. Während sich die
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.

ISO/IEC 15408-3 ADV_TDS.3.5C: Das Design muss eine Beschreibung der Interaktionen zwischen allen
Teilsystemen der TSF bereitstellen.

10.8.3.4.6 Workunit ADV_TDS.3-6

Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass Interaktionen zwischen den
Teilsystemen der TSF beschrieben werden.

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

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
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), 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, 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.

10.8.3.4.7 Workunit ADV_TDS.3-7

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)

10.8.3.4.8 Workunit ADV_TDS.3-8

Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass die Zuordnung zwischen den
Teilsystemen der TSF und den Modulen der TSF genau 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. 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.

10.8.3.4.9 Workunit ADV_TDS.3-9

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.

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-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.

10.8.3.4.11Workunit ADV_TDS.3-11

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.

10.8.3.4.12Workunit ADV_TDS.3-12

Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass die Beschreibung des Zwecks jedes
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.

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 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
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 Funktionsspezifikation auf die Module der TSF abbildet.

10.8.3.4.13Workunit ADV_TDS.3-13

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.
Interrupts) von einem Hardware-Teilsystem an ein Interrupt-behandelndes Teilsystem), aber die für ein
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.

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

ISO/IEC 15408-3 ADV_TDS.3.10C: Die Zuordnung muss nachweisen, dass sich alle TSFIs auf das im von ihnen
aufgerufenen TOE-Design beschriebene Verhalten zurückverfolgen lassen.

10.8.3.4.14Workunit ADV_TDS.3-14

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 Module der im TOE-Design
beschriebenen TSF enthält.

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.

Der Evaluator bewertet die Vollständigkeit der Zuordnung, indem er sicherstellt, dass alle TSFIs auf
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.

10.8.3.5 Aktion ADV_TDS.3.2E

10.8.3.5.1 Workunit ADV_TDS.3-15

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 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)

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 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.

10.8.3.5.2 Workunit ADV_TDS.3-16

Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass es eine genaue Instanziierung aller
funktionalen Sicherheitsanforderungen darstellt.

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.

Wenn beispielsweise die ST-Anforderungen einen rollenbasierten Zugriffskontrollmechanismus vorsehen,


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.

10.8.4 Evaluierung der Unteraufgabe (ADV_TDS.4)

10.8.4.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

a) die ST,
b) die Funktionsspezifikation,
c) die Beschreibung der Sicherheitsarchitektur,
d) das TOE-Design.

144
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

10.8.4.3 Anwendungshinweise

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.

10.8.4.4 Aktion ADV_TDS.4.1E

ISO/IEC 15408-3 ADV_TDS.4.1C: Das Design muss die Struktur des TOEs in Form von Teilsystemen beschreiben.

10.8.4.4.1 Workunit ADV_TDS.4-1

Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass die Struktur des gesamten TOEs 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.4-4 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.

Der TOE (und die TSF) kann (können) in mehreren Abstraktionsschichten (d. h. Teilsystemen und Modulen)
beschrieben werden. Je nach Komplexität des TOEs 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.
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.

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.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.

10.8.4.4.2 Workunit ADV_TDS.4-2

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).

10.8.4.4.3 Workunit ADV_TDS.4-3

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.

ISO/IEC 15408-3 ADV_TDS.4.3C: Das Design muss alle Teilsysteme der TSF identifizieren.

10.8.4.4.4 Workunit ADV_TDS.4-4

Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass alle Teilsysteme der TSF identifiziert
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.

In Workunit ADV_TDS.4-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.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)

10.8.4.4.5 Workunit ADV_TDS.4-5

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.

10.8.4.4.6 Workunit ADV_TDS.4-6

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.

147
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

10.8.4.4.7 Workunit ADV_TDS.4-7

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.

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.

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.

Der Evaluator stellt sicher, dass alle Teilsysteme der TSF eine Beschreibung haben. Während sich die
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.

ISO/IEC 15408-3 ADV_TDS.4.5C: Das Design muss eine Beschreibung der Interaktionen zwischen allen
Teilsystemen des TSF enthalten.

10.8.4.4.8 Workunit ADV_TDS.4-8

Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass alle Interaktionen zwischen den
Teilsystemen der TSF beschrieben werden.

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

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

10.8.4.4.9 Workunit ADV_TDS.4-9

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.

10.8.4.4.10Workunit ADV_TDS.4-10

Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass die Zuordnung zwischen den
Teilsystemen der TSF zu den Modulen der TSF genau 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. 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.

10.8.4.4.11Workunit ADV_TDS.4-11

Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass die Beschreibung des Zwecks jedes
SFR-durchsetzenden und SFR-unterstützenden Moduls und der Beziehung zu anderen Modulen vollständig
und genau ist.

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-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).

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.4.10C durchgeführte Analyse unterstützt
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.

10.8.4.4.12Workunit ADV_TDS.4-12

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.

10.8.4.4.13Workunit ADV_TDS.4-13

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.

10.8.4.4.14Workunit ADV_TDS.4-14

Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass die Beschreibung des Zwecks jedes
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.

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

10.8.4.4.15Workunit ADV_TDS.4-15

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.
Interrupts) von einem Hardware-Teilsystem an ein Interrupt-behandelndes Teilsystem), aber die für ein
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.

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, 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 Interaktionen genau und vollständig
beschrieben werden.

ISO/IEC 15408-3 ADV_TDS.4.10C: Die Zuordnung muss nachweisen, dass sich alle TSFIs auf das im von ihnen
aufgerufenen TOE-Design beschriebene Verhalten zurückverfolgen lassen.

10.8.4.4.16Workunit ADV_TDS.4-16

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 Module der im TOE-Design
beschriebenen TSF enthält.

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.

Der Evaluator bewertet die Vollständigkeit der Zuordnung, indem er sicherstellt, dass alle TSFIs auf
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.

10.8.4.5 Aktion ADV_TDS.4.2E

10.8.4.5.1 Workunit ADV_TDS.4-17

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 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.

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 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.

10.8.4.5.2 Workunit ADV_TDS.4-18

Der Evaluator muss das TOE-Design untersuchen, um festzustellen, dass es eine genaue Instanziierung aller
funktionalen Sicherheitsanforderungen darstellt.

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.

Wenn beispielsweise die ST-Anforderungen einen rollenbasierten Zugriffskontrollmechanismus vorsehen,


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.

10.8.5 Evaluierung der Unteraufgabe (ADV_TDS.5)

Es gibt keine allgemeine Anleitung; das Schema sollte für diese Unteraufgabe konsultiert werden.

10.8.6 Evaluierung der Unteraufgabe (ADV_TDS.6)

Es gibt keine allgemeine Anleitung; das Schema sollte für diese Unteraufgabe konsultiert werden.

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.

11.2 Anwendungshinweise
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)

11.3.1.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

a) die ST,

b) die Funktionsspezifikation,

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.

11.3.1.3.2 Workunit AGD_OPE.1-2

Der Evaluator muss die operativen Leitlinien für Benutzer untersuchen, um festzustellen, dass sie für jede
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.

11.3.1.3.3 Workunit AGD_OPE.1-3

Der Evaluator muss die operativen Leitlinien für Benutzer untersuchen, um festzustellen, dass sie für jede
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.

11.3.1.3.4 Workunit AGD_OPE.1-4

Der Evaluator muss die operativen Leitlinien für Benutzer untersuchen, um festzustellen, dass sie für jede
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.

11.3.1.3.5 Workunit AGD_OPE.1-5

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.

11.3.1.3.6 Workunit AGD_OPE.1-6

Der Evaluator muss die operativen Leitlinien für Benutzer untersuchen, um festzustellen, dass sie für jede
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.

11.3.1.3.7 Workunit AGD_OPE.1-7

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.

11.3.1.3.8 Workunit AGD_OPE.1-8

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)

11.4.1.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

a) die ST,
b) der TOE einschließlich seiner vorbereitenden Verfahren,
c) die Beschreibung der Lieferverfahren des Entwicklers, falls zutreffend.

11.4.1.3 Anwendungshinweise

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.

11.4.1.4.2 Workunit AGD_PRE.1-2

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

11.4.1.5.1 Workunit AGD_PRE.1-3

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)

12.2.1.1 Zielsetzungen

Die Zielsetzung dieser Unteraufgabe bestehen darin, festzustellen, ob der Entwickler den TOE eindeutig
identifiziert hat.

12.2.1.2 Eingaben

Der Evaluationsnachweis für diese Unteraufgabe ist

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)

12.2.1.3.2 Workunit ALC_CMC.1-2

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.

12.2.2 Evaluierung der Unteraufgabe (ALC_CMC.2)

12.2.2.1 Zielsetzungen

Die Zielsetzungen dieser Unteraufgabe bestehen darin, festzustellen, ob der Entwickler ein CM-System
verwendet, das alle Konfigurationselemente eindeutig identifiziert.

12.2.2.2 Eingaben

Der Evaluationsnachweis für diese Unteraufgabe ist

a) die ST,
b) der zum Prüfen geeignete TOE,
c) die Konfigurationsmanagementdokumentation.

12.2.2.3 Anwendungshinweise

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.

12.2.2.4 Aktion ALC_CMC.2.1E

ISO/IEC 15408-3 ALC_CMC.2.1C: Der TOE muss mit seiner eindeutigen Verweisung gekennzeichnet sein.

162
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

12.2.2.4.1 Workunit ALC_CMC.2-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).

12.2.2.4.2 Workunit ALC_CMC.2-2

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.

ISO/IEC 15408-3 ALC_CMC.2.2C: Die CM-Dokumentation muss die zur eindeutigen Identifizierung der
Konfigurationselemente verwendete Methode beschreiben.

12.2.2.4.3 Workunit ALC_CMC.2-3

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.

12.2.2.4.4 Workunit ALC_CMC.2-4

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.

12.2.3 Evaluierung der Unteraufgabe (ALC_CMC.3)

12.2.3.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

a) die ST,
b) der zum Prüfen geeignete TOE,
c) die Konfigurationsmanagementdokumentation.

12.2.3.3 Aktion ALC_CMC.3.1E

ISO/IEC 15408-3 ALC_CMC.3.1C: Der TOE muss mit seiner eindeutigen Verweisung gekennzeichnet sein.

12.2.3.3.1 Workunit ALC_CMC.3-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).

164
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

12.2.3.3.2 Workunit ALC_CMC.3-2

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.

ISO/IEC 15408-3 ALC_CMC.3.2C: Die CM-Dokumentation muss die zur eindeutigen Identifizierung der
Konfigurationselemente verwendete Methode beschreiben.

12.2.3.3.3 Workunit ALC_CMC.3-3

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;

c) das Verfahren, das zur Identifizierung ersetzter Versionen eines Konfigurationselements verwendet
werden soll.

ISO/IEC 15408-3 ALC_CMC.3.3C: Das CM-System muss alle Konfigurationselemente eindeutig identifizieren.

12.2.3.3.4 Workunit ALC_CMC.3-4

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

165
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

Konfigurationselement einen eindeutigen Bezeichner in einer Weise besitzt, die gegenüber dem in der
CM-Dokumentation beschriebenen eindeutigen Identifizierungsverfahren konsistent ist.

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.

12.2.3.3.5 Workunit ALC_CMC.3-5

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.

12.2.3.3.6 Workunit ALC_CMC.3-6

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.

12.2.3.3.7 Workunit ALC_CMC.3-7

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.

12.2.3.3.8 Workunit ALC_CMC.3-8

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.

12.2.3.3.9 Workunit ALC_CMC.3-9

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.

Zur Anleitung von Probenahmen siehe A.2, Probenahme.

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.

12.2.4 Evaluierung der Unteraufgabe (ALC_CMC.4)

12.2.4.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

a) die ST,
b) der zum Prüfen geeignete TOE,
c) die Konfigurationsmanagementdokumentation.

12.2.4.3 Aktion ALC_CMC.4.1E

ISO/IEC 15408-3 ALC_CMC.4.1C: Der TOE muss mit seiner eindeutigen Verweisung gekennzeichnet sein.

12.2.4.3.1 Workunit ALC_CMC.4-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.

168
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

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).

12.2.4.3.2 Workunit ALC_CMC.4-2

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 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
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.

ISO/IEC 15408-3 ALC_CMC.4.2C: Die CM-Dokumentation muss die zur eindeutigen Identifizierung der
Konfigurationselemente verwendete Methode beschreiben.

12.2.4.3.3 Workunit ALC_CMC.4-3

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;
c) das Verfahren, das zur Identifizierung ersetzter Versionen eines Konfigurationselements verwendet
werden soll.

ISO/IEC 15408-3 ALC_CMC.4.3C: Das CM-System muss alle Konfigurationselemente eindeutig identifizieren.

169
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

12.2.4.3.4 Workunit ALC_CMC.4-4

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. 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.

12.2.4.3.5 Workunit ALC_CMC.4-5

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.

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.4.10C 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.4.5C: Das CM-System muss die Produktion des TOEs durch automatisierte Mittel
unterstützen.

12.2.4.3.6 Workunit ALC_CMC.4-6

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.

12.2.4.3.7 Workunit ALC_CMC.4-7

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.

ISO/IEC 15408-3 ALC_CMC.4.6C: Die CM-Dokumentation muss einen CM-Plan enthalten.

12.2.4.3.8 Workunit ALC_CMC.4-8

Der Evaluator muss prüfen, ob die bereitgestellte CM-Dokumentation einen CM-Plan enthält.

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.

ISO/IEC 15408-3 ALC_CMC.4.7C: Der CM-Plan muss beschreiben, wie das CM-System für die Entwicklung des
TOEs verwendet wird.

12.2.4.3.9 Workunit ALC_CMC.4-9

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) die Verfahren zur Unterstützung der Produktion;
e) welche anderen Objekte (Entwicklungskomponenten, Tools, Bewertungsumgebungen usw.) unter die
Kontrolle des CM gestellt werden;
f) 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);
g) wie CM-Instanzen (z. B. Änderungskontrollausschüsse, Schnittstellenkontroll-Arbeitsgruppen)
eingeführt und besetzt werden;
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
Konfigurationselementen vornehmen können;
j) die Verfahren, die verwendet werden, um sicherzustellen, dass keine Probleme durch nebenläufige
Prozesse wie gleichzeitige Änderungen an Konfigurationselementen auftreten;
k) 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;
l) 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.4.8C: Der CM-Plan muss die Verfahren zur Abnahme geänderter oder neu erstellter
Konfigurationselemente als Teile des TOEs beschreiben.

12.2.4.3.10Workunit ALC_CMC.4-10

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.

ISO/IEC 15408-3 ALC_CMC.4.9C: Der Nachweis muss zeigen, dass alle Konfigurationselemente im CM-System
gepflegt werden.

172
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

12.2.4.3.11Workunit ALC_CMC.4-11

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.4.10C: Der Nachweis muss zeigen, dass das CM-System in Übereinstimmung mit dem
CM-Plan betrieben wird.

12.2.4.3.12Workunit ALC_CMC.4-12

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.4.9C
gefordert gepflegt werden. Die Ausgabe könnte beispielsweise Formulare zur Änderungskontrolle oder
Formulare zur Genehmigung des Zugriffs auf Konfigurationselemente enthalten.

12.2.4.3.13Workunit ALC_CMC.4-13

Der Evaluator muss die Nachweise untersuchen, um festzustellen, dass das CM-System in Übereinstimmung
mit dem CM-Plan betrieben wird.

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.

Zur Anleitung von Probenahmen siehe A.2, Probenahme.

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.

173
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

12.2.5 Evaluierung der Unteraufgabe (ALC_CMC.5)

12.2.5.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

a) die ST,
b) der zum Prüfen geeignete TOE,
c) die Konfigurationsmanagementdokumentation.

12.2.5.3 Aktion ALC_CMC.5.1E

ISO/IEC 15408-3 ALC_CMC.5.1C: Der TOE muss mit seiner eindeutigen Verweisung gekennzeichnet sein.

12.2.5.3.1 Workunit ALC_CMC.5-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).

12.2.5.3.2 Workunit ALC_CMC.5-2

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 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
entsprechenden Elemente verfügen.

ISO/IEC 15408-3 ALC_CMC.5.2C: Die CM-Dokumentation muss die zur eindeutigen Identifizierung der
Konfigurationselemente verwendete Methode beschreiben.

12.2.5.3.3 Workunit ALC_CMC.5-3

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;
c) das Verfahren, das zur Identifizierung ersetzter Versionen eines Konfigurationselements verwendet
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.

12.2.5.3.4 Workunit ALC_CMC.5-4

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.4C: Das CM-System muss alle Konfigurationselemente eindeutig identifizieren.

12.2.5.3.5 Workunit ALC_CMC.5-5

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.

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)

12.2.5.3.6 Workunit ALC_CMC.5-6

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.

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.5.16C 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.5.6C: Das CM-System muss die Produktion des TOEs durch automatisierte Mittel
unterstützen.

12.2.5.3.7 Workunit ALC_CMC.5-7

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.

12.2.5.3.8 Workunit ALC_CMC.5-8

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.

12.2.5.3.9 Workunit ALC_CMC.5-9

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.

12.2.5.3.10Workunit ALC_CMC.5-10

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.

Zur Anleitung von Probenahmen siehe A.2, Probenahme.

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.

12.2.5.3.11Workunit ALC_CMC.5-11

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.

12.2.5.3.12Workunit ALC_CMC.5-12

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.

Zur Anleitung von Probenahmen siehe A.2, Probenahme.

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.

12.2.5.3.13Workunit ALC_CMC.5-13

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.

Zur Anleitung von Probenahmen siehe A.2, Probenahme.

ISO/IEC 15408-3 ALC_CMC.5.12C: Die CM-Dokumentation muss einen CM-Plan enthalten.

12.2.5.3.14Workunit ALC_CMC.5-14

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.5.13C: Der CM-Plan muss beschreiben, wie das CM-System für die Entwicklung des
TOEs verwendet wird.

12.2.5.3.15Workunit ALC_CMC.5-15

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) die Verfahren zur Unterstützung der Produktion;

e) welche anderen Objekte (Entwicklungskomponenten, Tools, Bewertungsumgebungen usw.) unter die


Kontrolle des CM gestellt werden;

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
einzelnen Konfigurationselementen erforderlich sind (für verschiedene Arten von
Konfigurationselementen (z. B. Designdokumentation oder Quellcode) können unterschiedliche Rollen
identifiziert werden);

g) wie CM-Instanzen (z. B. Änderungskontrollausschüsse, Schnittstellenkontroll-Arbeitsgruppen)


eingeführt und besetzt werden;
h) die Beschreibung des Änderungsmanagements;
i) die Verfahren, mit denen sichergestellt wird, dass nur autorisierte Personen Änderungen an
Konfigurationselementen vornehmen können;
j) die Verfahren, die verwendet werden, um sicherzustellen, dass keine Probleme durch nebenläufige
Prozesse wie gleichzeitige Änderungen an Konfigurationselementen auftreten;
k) 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;
l) 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.5.14C: Der CM-Plan muss die Verfahren zur Abnahme geänderter oder neu erstellter
Konfigurationselemente als Teile des TOEs beschreiben.

12.2.5.3.16Workunit ALC_CMC.5-16

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.

ISO/IEC 15408-3 ALC_CMC.5.15C: Der Nachweis muss zeigen, dass alle Konfigurationselemente im CM-System
gepflegt werden.

12.2.5.3.17Workunit ALC_CMC.5-17

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

179
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

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.5.16C: Der Nachweis muss zeigen, dass das CM-System in Übereinstimmung mit dem
CM-Plan betrieben wird.

12.2.5.3.18Workunit ALC_CMC.5-18

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.5.15C
gefordert gepflegt werden. Die Ausgabe könnte beispielsweise Formulare zur Änderungskontrolle oder
Formulare zur Genehmigung des Zugriffs auf Konfigurationselemente enthalten.

12.2.5.3.19Workunit ALC_CMC.5-19

Der Evaluator muss die Nachweise untersuchen, um festzustellen, dass das CM-System in Übereinstimmung
mit dem CM-Plan betrieben wird.

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.

Zur Anleitung von Probenahmen siehe A.2, Probenahme.

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.

12.2.5.4 Aktion ALC_CMC.5.2E

12.2.5.4.1 Workunit ALC_CMC.5-20

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.

Zur Anleitung von Standortbesichtigungen siehe A.4, Standortbesichtigungen.

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)

12.3.1.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

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.

12.3.1.3.2 Workunit ALC_CMS.1-2

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.

12.3.2 Evaluierung der Unteraufgabe (ALC_CMS.2)

12.3.2.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

a) die ST,

b) die Konfigurationsliste.

12.3.2.3 Aktion ALC_CMS.2.1E

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.

12.3.2.3.1 Workunit ALC_CMS.2-1

Der Evaluator muss prüfen, ob die Konfigurationsliste die folgende Menge Elemente enthält:

a) der TOE selbst;

b) die Teile, aus denen der TOE besteht;

c) der von den SARs geforderte Evaluationsnachweis.

ISO/IEC 15408-3 ALC_CMS.2.2C: Die Konfigurationsliste muss die Konfigurationselemente eindeutig


identifizieren.

12.3.2.3.2 Workunit ALC_CMS.2-2

Der Evaluator muss die Konfigurationsliste untersuchen, um festzustellen, dass sie jedes Konfigurations-
element eindeutig identifiziert.

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.

ISO/IEC 15408-3 ALC_CMS.2.3C: Für jedes TSF-relevante Konfigurationselement muss in der Konfigurationsliste
der Entwickler des Elements angegeben werden.

12.3.2.3.3 Workunit ALC_CMS.2-3

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
gilt daher als erfüllt.

182
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

12.3.3 Evaluierung der Unteraufgabe (ALC_CMS.3)

12.3.3.1 Zielsetzungen

Die Zielsetzung dieser Unteraufgabe soll darin bestehen, festzustellen, ob die Konfigurationsliste den TOE, die
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

Der Evaluationsnachweis für diese Unteraufgabe ist

a) die ST,

b) die Konfigurationsliste.

12.3.3.3 Aktion ALC_CMS.3.1E

ISO/IEC 15408-3 ALC_CMS.3.1C: Die Konfigurationsliste muss folgende Elemente enthalten: den TOE selbst, den
von den SARs geforderten Evaluationsnachweis, die Teile, aus denen der TOE besteht, und die Darstellung der
Implementierung.

12.3.3.3.1 Workunit ALC_CMS.3-1

Der Evaluator muss prüfen, ob die Konfigurationsliste die folgende Menge Elemente enthält:

a) der TOE selbst;

b) die Teile, aus denen der TOE besteht;

c) die Darstellung der TOE-Implementierung;

d) der von den SARs in der ST geforderte Evaluationsnachweis.

ISO/IEC 15408-3 ALC_CMS.3.2C: Die Konfigurationsliste muss die Konfigurationselemente eindeutig


identifizieren.

12.3.3.3.2 Workunit ALC_CMS.3-2

Der Evaluator muss die Konfigurationsliste untersuchen, um festzustellen, dass sie jedes Konfigurations-
element eindeutig identifiziert.

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
Evaluation verwendet wurden.

ISO/IEC 15408-3 ALC_CMS.3.3C: Für jedes TSF-relevante Konfigurationselement muss in der Konfigurationsliste
der Entwickler des Elements angegeben werden.

12.3.3.3.3 Workunit ALC_CMS.3-3

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
gilt daher als erfüllt.

183
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

12.3.4 Evaluierung der Unteraufgabe (ALC_CMS.4)

12.3.4.1 Zielsetzungen

Die Zielsetzung dieser Unteraufgabe soll darin bestehen, festzustellen, ob die Konfigurationsliste den TOE, die
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

Der Evaluationsnachweis für diese Unteraufgabe ist

a) die ST,

b) die Konfigurationsliste.

12.3.4.3 Aktion ALC_CMS.4.1E

ISO/IEC 15408-3 ALC_CMS.4.1C: Die Konfigurationsliste muss folgende Elemente enthalten: den TOE selbst, den
von den SARs geforderten Evaluationsnachweis, die Teile, aus denen der TOE besteht, die Darstellung der
Implementierung und Berichte über Sicherheitsmängel sowie deren Behebungsstatus.

12.3.4.3.1 Workunit ALC_CMS.4-1

Der Evaluator muss prüfen, ob die Konfigurationsliste die folgende Menge Elemente enthält:

a) der TOE selbst;

b) die Teile, aus denen der TOE besteht;

c) die Darstellung der TOE-Implementierung;

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).

ISO/IEC 15408-3 ALC_CMS.4.2C: Die Konfigurationsliste muss die Konfigurationselemente eindeutig


identifizieren.

12.3.4.3.2 Workunit ALC_CMS.4-2

Der Evaluator muss die Konfigurationsliste untersuchen, um festzustellen, dass sie jedes Konfigurations-
element eindeutig identifiziert.

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.

ISO/IEC 15408-3 ALC_CMS.4.3C: Für jedes TSF-relevante Konfigurationselement muss in der Konfigurationsliste
der Entwickler des Elements angegeben werden.

184
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

12.3.4.3.3 Workunit ALC_CMS.4-3

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
gilt daher als erfüllt.

12.3.5 Evaluierung der Unteraufgabe (ALC_CMS.5)

12.3.5.1 Zielsetzungen

Die Zielsetzung dieser Unteraufgabe soll darin bestehen, festzustellen, ob die Konfigurationsliste den TOE, die
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

Der Evaluationsnachweis für diese Unteraufgabe ist

a) die ST,

b) die Konfigurationsliste.

12.3.5.3 Aktion ALC_CMS.5.1E

ISO/IEC 15408-3 ALC_CMS.5.1C: Die Konfigurationsliste muss folgende Elemente enthalten: den TOE selbst, den
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.

12.3.5.3.1 Workunit ALC_CMS.5-1

Der Evaluator muss prüfen, ob die Konfigurationsliste die folgende Menge Elemente enthält:

a) der TOE selbst;

b) die Teile, aus denen der TOE besteht;

c) die Darstellung der TOE-Implementierung;

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.

ISO/IEC 15408-3 ALC_CMS.5.2C: Die Konfigurationsliste muss die Konfigurationselemente eindeutig


identifizieren.

185
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

12.3.5.3.2 Workunit ALC_CMS.5-2

Der Evaluator muss die Konfigurationsliste untersuchen, um festzustellen, dass sie jedes Konfigurations-
element eindeutig identifiziert.

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.

ISO/IEC 15408-3 ALC_CMS.5.3C: Für jedes TSF-relevante Konfigurationselement muss in der Konfigurationsliste
der Entwickler des Elements angegeben werden.

12.3.5.3.3 Workunit ALC_CMS.5-3

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
gilt daher als erfüllt.

12.4 Lieferung (ALC_DEL)

12.4.1 Evaluierung der Unteraufgabe (ALC_DEL.1)

12.4.1.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

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.

Zur Anleitung von Standortbesichtigungen siehe A.4, Standortbesichtigungen.

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)

12.5.1.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

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.

12.5.1.3.2 Workunit ALC_DVS.1-2

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.

12.5.1.4 Aktion ALC_DVS.1.2E

12.5.1.4.1 Workunit ALC_DVS.1-3

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.

Zur Anleitung von Standortbesichtigungen siehe A.4, Standortbesichtigungen.

12.5.2 Evaluierung der Unteraufgabe (ALC_DVS.2)

12.5.2.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

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.

12.5.2.3 Aktion ALC_DVS.2.1E

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.

12.5.2.3.1 Workunit ALC_DVS.2-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.

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.

12.5.2.3.2 Workunit ALC_DVS.2-2

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)

12.5.2.3.3 Workunit ALC_DVS.2-3

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.

12.5.2.4 Aktion ALC_DVS.2.2E

12.5.2.4.1 Workunit ALC_DVS.2-4

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.

Zur Anleitung von Standortbesichtigungen siehe A.4, Standortbesichtigungen.

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)

12.6.1.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

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.

12.6.1.3.2 Workunit ALC_FLR.1-2

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.

12.6.1.3.3 Workunit ALC_FLR.1-3

Der Evaluator muss die Verfahren zur Mängelbeseitigung untersuchen, um festzustellen, dass die Anwendung
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.

12.6.1.3.4 Workunit ALC_FLR.1-4

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.

12.6.1.3.5 Workunit ALC_FLR.1-5

Der Evaluator muss die Dokumentation der Verfahren zur Mängelbeseitigung untersuchen, um festzustellen,
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.

12.6.2 Evaluierung der Unteraufgabe (ALC_FLR.2)

12.6.2.1 Zielsetzungen

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. 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

Der Evaluationsnachweis für diese Unteraufgabe ist

a) die Dokumentation der Mängelbeseitigungsverfahren,

b) die Dokumentation der Mängelbeseitigungsleitlinien.

12.6.2.3 Aktion ALC_FLR.2.1E

ISO/IEC 15408-3 ALC_FLR.2.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.2.3.1 Workunit ALC_FLR.2-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.

196
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

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.

ISO/IEC 15408-3 ALC_FLR.2.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.

12.6.2.3.2 Workunit ALC_FLR.2-2

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
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. Zum Beispiel 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 „BACKDOOR“ erlaubt wird.

12.6.2.3.3 Workunit ALC_FLR.2-3

Der Evaluator muss die Verfahren zur Mängelbeseitigung untersuchen, um festzustellen, dass die Anwendung
dieser Verfahren den Status der Feststellung einer Korrektur für jeden Sicherheitsmangel 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.2.3C: Die Verfahren zur Mängelbeseitigung müssen vorschreiben, dass für jeden der
Sicherheitsmängel Korrekturmaßnahmen identifiziert werden.

12.6.2.3.4 Workunit ALC_FLR.2-4

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).

197
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

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.2.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.

12.6.2.3.5 Workunit ALC_FLR.2-5

Der Evaluator muss die Dokumentation der Verfahren zur Mängelbeseitigung untersuchen, um festzustellen,
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.2-2
zur Verfügung gestellt wird), der vorgeschriebenen Korrekturmaßnahme und allen zugehörigen Leitlinien zur
Umsetzung der Korrektur.

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.

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.

12.6.2.3.6 Workunit ALC_FLR.2-6

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.

12.6.2.3.7 Workunit ALC_FLR.2-7

Der Evaluator muss die Verfahren zur Mängelbeseitigung untersuchen, um festzustellen, dass die Anwendung
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.

12.6.2.3.8 Workunit ALC_FLR.2-8

Der Evaluator muss die Verfahren zur Mängelbeseitigung untersuchen, um festzustellen, dass die Anwendung
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.

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. 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.

12.6.2.3.9 Workunit ALC_FLR.2-9

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
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.

12.6.3 Evaluierung der Unteraufgabe (ALC_FLR.3)

12.6.3.1 Zielsetzungen

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. 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

Der Evaluationsnachweis für diese Unteraufgabe ist

a) die Dokumentation der Mängelbeseitigungsverfahren,

b) die Dokumentation der Mängelbeseitigungsleitlinien.

12.6.3.3 Aktion ALC_FLR.3.1E

ISO/IEC 15408-3 ALC_FLR.3.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.3.3.1 Workunit ALC_FLR.3-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.

200
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

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.

ISO/IEC 15408-3 ALC_FLR.3.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.

12.6.3.3.2 Workunit ALC_FLR.3-2

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
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. Zum Beispiel 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 „BACKDOOR“ erlaubt wird.

12.6.3.3.3 Workunit ALC_FLR.3-3

Der Evaluator muss die Verfahren zur Mängelbeseitigung untersuchen, um festzustellen, dass die Anwendung
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.3.3C: Die Verfahren zur Mängelbeseitigung müssen vorschreiben, dass für jeden der
Sicherheitsmängel Korrekturmaßnahmen identifiziert werden.

12.6.3.3.4 Workunit ALC_FLR.3-4

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).

201
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

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.3.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.

12.6.3.3.5 Workunit ALC_FLR.3-5

Der Evaluator muss die Dokumentation der Verfahren zur Mängelbeseitigung untersuchen, um festzustellen,
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.3-2
zur Verfügung gestellt wird), der vorgeschriebenen Korrekturmaßnahme und allen zugehörigen Leitlinien zur
Umsetzung der Korrektur.

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.

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.

12.6.3.3.6 Workunit ALC_FLR.3-6

Der Evaluator muss die Verfahren zur Mängelbeseitigung untersuchen, um festzustellen, ob die Anwendung
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
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.

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.

12.6.3.3.7 Workunit ALC_FLR.3-7

Der Evaluator muss die Verfahren zur Mängelbeseitigung untersuchen, um festzustellen, ob die Anwendung
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.

12.6.3.3.8 Workunit ALC_FLR.3-8

Der Evaluator muss die Verfahren zur Mängelbeseitigung untersuchen, um festzustellen, ob die Anwendung
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)

12.6.3.3.9 Workunit ALC_FLR.3-9

Der Evaluator muss die Verfahren zur Mängelbeseitigung untersuchen, um festzustellen, ob die Anwendung
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.

12.6.3.3.10Workunit ALC_FLR.3-10

Der Evaluator muss die Verfahren zur Mängelbeseitigung untersuchen, um festzustellen, dass die Anwendung
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.

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. 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.

12.6.3.3.11Workunit ALC_FLR.3-11

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.

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.3.9C: Die Leitlinien zur Mängelbeseitigung müssen ein Mittel beschreiben, mit dem
TOE-Benutzer dem Entwickler vermutete Sicherheitsmängel des TOEs melden.

204
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

12.6.3.3.12Workunit ALC_FLR.3-12

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
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.

ISO/IEC 15408-3 ALC_FLR.3.10C: Die Leitlinien zur Mängelbeseitigung müssen ein Mittel beschreiben, mit dem
sich die TOE-Benutzer beim Entwickler registrieren lassen können, um Anspruch auf Berichte über
Sicherheitsmängel und Korrekturen zu haben.

12.6.3.3.13Workunit ALC_FLR.3-13

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.

12.6.3.3.14Workunit ALC_FLR.3-14

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)

12.7.1.1 Zielsetzungen

Die Zielsetzung dieser Unteraufgabe besteht darin, festzustellen, ob der Entwickler ein dokumentiertes Modell
des Lebenszyklus des TOEs verwendet hat.

12.7.1.2 Eingaben

Der Evaluationsnachweis für diese Unteraufgabe ist

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.

12.7.1.3.2 Workunit ALC_LCD.1-2

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)

12.7.2.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

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.

12.7.2.3.1 Workunit ALC_LCD.2-1

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.

12.7.2.3.2 Workunit ALC_LCD.2-2

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)

12.7.2.3.3 Workunit ALC_LCD.2-3

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)

12.8.1.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist


a) die Dokumentation des Entwicklungstools,
b) die Untergruppe der Darstellung der Implementierung.

12.8.1.3 Anwendungshinweise

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.

12.8.1.4.2 Workunit ALC_TAT.1-2

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.

ISO/IEC 15408-3 ALC_TAT.1.3C: Die Dokumentation jedes Entwicklungstools muss die Bedeutung aller
implementierungsabhängigen Optionen eindeutig definieren.

210
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

12.8.1.4.3 Workunit ALC_TAT.1-3

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).

12.8.2 Evaluierung der Unteraufgabe (ALC_TAT.2)

12.8.2.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

a) die Dokumentation des Entwicklungstools,


b) die Beschreibung der Implementierungsnormen,
c) die vorgesehene Darstellung der Implementierung des TSF.

12.8.2.3 Anwendungshinweise

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).

12.8.2.4 Aktion ALC_TAT.2.1E

ISO/IEC 15408-3 ALC_TAT.2.1C: Jedes für die Implementierung verwendete Entwicklungstool muss genau
festgelegt sein.

12.8.2.4.1 Workunit ALC_TAT.2-1

Der Evaluator muss die zur Verfügung gestellte Dokumentation der Entwicklungstools untersuchen, um
festzustellen, dass jedes Entwicklungstool genau definiert ist.

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.2.2C: Die Dokumentation jedes Entwicklungstools muss die Bedeutung aller
Aussagen sowie aller bei der Implementierung verwendeten Konventionen und Richtlinien eindeutig definieren.

211
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

12.8.2.4.2 Workunit ALC_TAT.2-2

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


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.

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.

ISO/IEC 15408-3 ALC_TAT.2.3C: Die Dokumentation jedes Entwicklungstools muss die Bedeutung aller
implementierungsabhängigen Optionen eindeutig definieren.

12.8.2.4.3 Workunit ALC_TAT.2-3

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.

212
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

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).

12.8.2.5 Aktion ALC_TAT.2.2E

12.8.2.5.1 Workunit ALC_TAT.2-4

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.

Eine Besichtigung des Entwicklungsstandortes ist ein nützliches Mittel, um Vertrauen in die angewandten
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.

12.8.3 Evaluierung der Unteraufgabe (ALC_TAT.3)

12.8.3.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

a) die Dokumentation des Entwicklungstools,


b) die Beschreibung der Implementierungsnormen,
c) die vorgesehene Darstellung der Implementierung des TSF.

12.8.3.3 Anwendungshinweise

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).

12.8.3.4 Aktion ALC_TAT.3.1E

ISO/IEC 15408-3 ALC_TAT.3.1C: Jedes für die Implementierung verwendete Entwicklungstool muss genau
festgelegt sein.

12.8.3.4.1 Workunit ALC_TAT.3-1

Der Evaluator muss die zur Verfügung gestellte Dokumentation der Entwicklungstools untersuchen, um
festzustellen, dass jedes Entwicklungstool genau definiert ist.

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.

Auf dieser Stufe muss die Dokumentation von Entwicklungstools, die von Dritten, die zum TOE beitragen,
verwendet werden, in die Untersuchung des Evaluators einbezogen werden.

ISO/IEC 15408-3 ALC_TAT.3.2C: Die Dokumentation jedes Entwicklungstools muss die Bedeutung aller
Aussagen sowie aller bei der Implementierung verwendeten Konventionen und Richtlinien eindeutig definieren.

12.8.3.4.2 Workunit ALC_TAT.3-2

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 Programmier-
sprache 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.

214
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

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.

Auf dieser Stufe muss die Dokumentation von Entwicklungstools, die von Dritten, die zum TOE beitragen,
verwendet werden, in die Untersuchung des Evaluators einbezogen werden.

ISO/IEC 15408-3 ALC_TAT.3.3C: Die Dokumentation jedes Entwicklungstools muss die Bedeutung aller
implementierungsabhängigen Optionen eindeutig definieren.

12.8.3.4.3 Workunit ALC_TAT.3-3

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).

Auf dieser Stufe muss die Dokumentation von Entwicklungstools, die von Dritten, die zum TOE beitragen,
verwendet werden, in die Untersuchung des Evaluators einbezogen werden.

12.8.3.5 Aktion ALC_TAT.3.2E

12.8.3.5.1 Workunit ALC_TAT.3-4

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.

Eine Besichtigung des Entwicklungsstandortes ist ein nützliches Mittel, um Vertrauen in die angewandten
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.

13.2 Anwendungshinweise

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)

13.3.1.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist


a) die ST,
b) die Funktionsspezifikation,
c) die Prüfdokumentation,
d) der Nachweis der Prüfabdeckung.

13.3.1.3 Anwendungshinweise

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.

13.3.2 Evaluierung der Unteraufgabe (ATE_COV.2)

13.3.2.1 Zielsetzungen

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,
b) die Funktionsspezifikation,
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.

13.3.2.3.1 Workunit ATE_COV.2-1

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.

13.3.2.3.2 Workunit ATE_COV.2-2

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.

13.3.2.3.3 Workunit ATE_COV.2-3

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.

13.3.2.3.4 Workunit ATE_COV.2-4

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.

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.

13.3.3 Evaluierung der Unteraufgabe (ATE_COV.3)

Es gibt keine allgemeine Anleitung; das Schema sollte für diese Unteraufgabe konsultiert werden.

13.4 Tiefe (ATE_DPT)


13.4.1 Evaluierung der Unteraufgabe (ATE_DPT.1)

13.4.1.1 Zielsetzungen

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,

b) die Funktionsspezifikation,

c) das TOE-Design,

d) die Beschreibung der Sicherheitsarchitektur,

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.

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.

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.

13.4.1.3.2 Workunit ATE_DPT.1-2

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.

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.

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.

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.

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.

13.4.1.3.3 Workunit ATE_DPT.1-3

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 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)

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.

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.

13.4.1.3.4 Workunit ATE_DPT.1-4

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.

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.

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 dies nicht bedeutet, dass alle Prüfungen in der Prüfdokumentation
auf das Verhalten oder die Interaktionsbeschreibung des Teilsystems im TOE-Design abgebildet werden
müssen.

13.4.2 Evaluierung der Unteraufgabe (ATE_DPT.2)

13.4.2.1 Zielsetzungen

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,
b) die Funktionsspezifikation,
c) das TOE-Design,
d) die Beschreibung der Sicherheitsarchitektur,
e) die Prüfdokumentation,
f) die Tiefe der Prüfanalyse.

13.4.2.3 Aktion ATE_DPT.2.1E

ISO/IEC 15408-3 ATE_DPT.2.1C: Die Analyse der Prüftiefe muss die Übereinstimmung zwischen den Prüfungen
in der Prüfdokumentation und den TSF-Teilsystemen und den SFR-durchsetzenden Modulen im TOE-Design
nachweisen.

13.4.2.3.1 Workunit ATE_DPT.2-1

Der Evaluator muss die Tiefe der Prüfanalyse untersuchen, um festzustellen, ob 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.

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.

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.

13.4.2.3.2 Workunit ATE_DPT.2-2

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.

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.

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.

224
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

13.4.2.3.3 Workunit ATE_DPT.2-3

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 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.

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.

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.

13.4.2.3.4 Workunit ATE_DPT.2-4

Der Evaluator muss die Tiefe der Prüfanalyse untersuchen, um festzustellen, dass die Schnittstellen der
SFR-durchsetzenden Module 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 auf modularer Ebene genannt werden, überprüft
diese Workunit auch die Übereinstimmung zwischen den Prüfungen und den Beschreibungen des Verhaltens
dieser Mechanismen.

Eine einfache Kreuztabelle kann ausreichend sein, um die Prüfübereinstimmung zu zeigen. Die Identifizierung
der Prüfungen und der SFR-durchsetzenden Module, die in der Analyse der Abdeckungstiefe dargestellt
werden, muss eindeutig sein.

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.

13.4.2.3.5 Workunit ATE_DPT.2-5

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 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.

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.

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.

ISO/IEC 15408-3 ATE_DPT.2.2C: Die Analyse der Prüftiefe muss nachweisen, dass alle TSF-Teilsysteme im
TOE-Design geprüft wurden.

13.4.2.3.6 Workunit ATE_DPT.2-6

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.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
TSF-Teilsystem-Verhaltens oder der Interaktionen zwischen TSF-Teilsystemen im TOE-Design identifiziert
würde und keine Prüfungen zugeordnet werden könnten.

Der Evaluator wird daran erinnert, dass dies nicht bedeutet, dass alle Prüfungen in der Prüfdokumentation
auf das Verhalten oder die Interaktionsbeschreibung des Teilsystems im TOE-Design abgebildet werden
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.

13.4.2.3.7 Workunit ATE_DPT.2-7

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.

Der Evaluator wird daran erinnert, dass dies nicht bedeutet, dass alle Prüfungen in der Prüfdokumentation
auf eine Schnittstelle eines SFR-durchsetzenden Moduls im TOE-Design abgebildet werden müssen.

13.4.3 Evaluierung der Unteraufgabe (ATE_DPT.3)

13.4.3.1 Zielsetzungen

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;
f) die Tiefe der Prüfanalyse.

226
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

13.4.3.3 Aktion ATE_DPT.3.1E

ISO/IEC 15408-3 ATE_DPT.3.1C: Die Analyse der Prüftiefe muss die Übereinstimmung zwischen den Prüfungen
in der Prüfdokumentation und den TSF-Teilsystemen und Modulen im TOE-Design nachweisen.

13.4.3.3.1 Workunit ATE_DPT.3-1

Der Evaluator muss die Tiefe der Prüfanalyse untersuchen, um festzustellen, ob 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. 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.

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.

13.4.3.3.2 Workunit ATE_DPT.3-2

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.

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.

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
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.

13.4.3.3.3 Workunit ATE_DPT.3-3

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 die im
TOE-Design beschriebenen Interaktionen zwischen Teilsystemen 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.

Während sich die vorherige Workunit mit dem Verhalten von Teilsystemen befasst, befasst sich diese
Workunit mit den Interaktionen zwischen den Teilsystemen.

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)

13.4.3.3.4 Workunit ATE_DPT.3-4

Der Evaluator muss die Tiefe der Prüfanalyse untersuchen, um festzustellen, dass die Schnittstellen der
TSF-Module in der Prüfdokumentation enthalten sind.

Diese Workunit verifiziert den Inhalt der Übereinstimmung zwischen den Prüfungen und den Beschreibungen
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.

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.

13.4.3.3.5 Workunit ATE_DPT.3-5

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 jede TSF-Modulschnittstelle 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.

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.

ISO/IEC 15408-3 ATE_DPT.3.2C: Die Analyse der Prüftiefe muss nachweisen, dass alle TSF-Teilsysteme im
TOE-Design geprüft wurden.

13.4.3.3.6 Workunit ATE_DPT.3-6

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.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
TSF-Teilsystem-Verhaltens oder der Interaktionen zwischen TSF-Teilsystemen im TOE-Design identifiziert
würde und keine Prüfungen zugeordnet werden könnten.

Der Evaluator wird daran erinnert, dass dies nicht bedeutet, dass alle Prüfungen in der Prüfdokumentation
auf das Verhalten oder die Interaktionsbeschreibung des Teilsystems im TOE-Design abgebildet werden
müssen.

ISO/IEC 15408-3 ATE_DPT.3.3C: Die Analyse der Prüftiefe muss nachweisen, dass alle TSF-Module im
TOE-Design geprüft wurden.

228
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

13.4.3.3.7 Workunit ATE_DPT.3-7

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.

Der Evaluator wird daran erinnert, dass dies nicht bedeutet, dass alle Prüfungen in der Prüfdokumentation
auf eine Schnittstelle eines TSF-Moduls im TOE-Design abgebildet werden müssen.

13.4.4 Evaluierung der Unteraufgabe (ATE_DPT.4)

Es gibt keine allgemeine Anleitung; das Schema sollte für diese Unteraufgabe konsultiert werden.

13.5 Funktionsprüfungen (ATE_FUN)

13.5.1 Evaluierung der Unteraufgabe (ATE_FUN.1)

13.5.1.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

a) die ST,
b) die Funktionsspezifikation,
c) die Prüfdokumentation.

13.5.1.3 Anwendungshinweise

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.

13.5.1.4.2 Workunit ATE_FUN.1-2

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.

13.5.1.4.3 Workunit ATE_FUN.1-3

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.

Der Evaluator möchte bei der Durchführung dieser Workunit möglicherweise eine Stichprobenstrategie
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)

13.5.1.4.4 Workunit ATE_FUN.1-4

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.

Der Evaluator möchte bei der Durchführung dieser Workunit möglicherweise eine Stichprobenstrategie
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.

13.5.1.4.5 Workunit ATE_FUN.1-5

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.

Der Evaluator möchte bei der Durchführung dieser Workunit möglicherweise eine Stichprobenstrategie
anwenden.

ISO/IEC 15408-3 ATE_FUN.1.4C: Die tatsächlichen Prüfergebnisse müssen zu den erwarteten Prüfergebnissen
konsistent sein.

13.5.1.4.6 Workunit ATE_FUN.1-6

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.

Der Evaluator möchte bei der Durchführung dieser Workunit möglicherweise eine Stichprobenstrategie
anwenden.

13.5.1.4.7 Workunit ATE_FUN.1-7

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)

Es gibt keine allgemeine Anleitung; das Schema sollte für diese Unteraufgabe konsultiert werden.

13.6 Unabhängiges Prüfen (ATE_IND)


13.6.1 Evaluierung der Unteraufgabe (ATE_IND.1)

13.6.1.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

a) die ST,
b) die Funktionsspezifikation,
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.

Der Evaluator sollte die in der ST beschriebenen Sicherheitszielsetzungen für die Betriebsumgebung
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.

13.6.1.3.2 Workunit ATE_IND.1-2

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.

13.6.1.4 Aktion ATE_IND.1.2E

13.6.1.4.1 Workunit ATE_IND.1-3

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)

13.6.1.4.2 Workunit ATE_IND.1-4

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.

13.6.1.4.3 Workunit ATE_IND.1-5

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.

13.6.1.4.4 Workunit ATE_IND.1-6

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.

13.6.1.4.5 Workunit ATE_IND.1-7

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.

13.6.1.4.6 Workunit ATE_IND.1-8

Der Evaluator muss im ETR über den Prüfaufwand des Evaluators berichten und dabei den Prüfansatz, die
Konfiguration, die Tiefe und die Ergebnisse skizzieren.

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
finden sind, gehören Folgende:

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.

Diese Liste ist keineswegs erschöpfend und soll nur einen gewissen Kontext hinsichtlich der Art von
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)

13.6.2 Evaluierung der Unteraufgabe (ATE_IND.2)

13.6.2.1 Zielsetzungen

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

Der Evaluationsnachweis für diese Unteraufgabe ist

a) die ST,
b) die Funktionsspezifikation,
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.

13.6.2.3 Aktion ATE_IND.2.1E

ISO/IEC 15408-3 ATE_IND.2.1C: Der TOE muss zum Prüfen geeignet sein.

13.6.2.3.1 Workunit ATE_IND.2-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 und im Prüfplan identifizierte 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.

Der Evaluator sollte die in der ST beschriebenen Sicherheitszielsetzungen für die Betriebsumgebung
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.

237
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

13.6.2.3.2 Workunit ATE_IND.2-2

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.

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.

13.6.2.3.3 Workunit ATE_IND.2-3

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.

13.6.2.4 Aktion ATE_IND.2.2E

13.6.2.4.1 Workunit ATE_IND.2-4

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.

13.6.2.4.2 Workunit ATE_IND.2-5

Der Evaluator muss prüfen, ob alle tatsächlichen Prüfergebnisse gegenüber den erwarteten Prüfergebnissen
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.

13.6.2.5 Aktion ATE_IND.2.3E

13.6.2.5.1 Workunit ATE_IND.2-6

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.

13.6.2.5.2 Workunit ATE_IND.2-7

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.

13.6.2.5.3 Workunit ATE_IND.2-8

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.

13.6.2.5.4 Workunit ATE_IND.2-9

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;

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.

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.

13.6.2.5.5 Workunit ATE_IND.2-10

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.

241
DIN EN ISO/IEC 18045:2021-02
EN ISO/IEC 18045:2020 (D)

13.6.2.5.6 Workunit ATE_IND.2-11

Der Evaluator muss im ETR über den Prüfaufwand des Evaluators berichten und dabei den Prüfansatz, die
Konfiguration, die Tiefe und die Ergebnisse skizzieren.

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
finden sind, gehören Folgende:
a) TOE-Prüfkonfigurationen. Die besonderen Konfig