Szablon materiału dowodowego

Transkrypt

Wstęp
Dokument
zawiera
szablon
Zamieszczony
szablon
zawiera
materiału
wiele
dowodowego
informacji,
które
wraz
nie
z
będą
komentarzem.
umieszczanie
w dokumencie wynikowym – materiale dowodowym opracowanym na podstawie szablonu.
Informacje te są metadanymi szablonu i ich zamieszczenie ma na celu ułatwienie
i zrozumienie sposobu tworzenia dokumentu wynikowego.
W dokumencie przyjęto, że pola oznaczone nawiasami kwadratowymi ([ ]) są
elementami zmiennymi (parametrami), które są bezpośrednio zależne od opisywanego
przedmiotu oceny i jego środowiska. Dodatkowo w celu objaśnienia znaczenia tych pól
oraz innych fragmentów szablonu stosowane są przypisy końcowe.
Przetwarzanie niniejszego dokumentu do postaci ostatecznego dokumentu powinno
polegać na zastępowaniu poszczególnych pól (zmiennych) odpowiednią treścią.
Wymagana treść jest opisana w przypisach, które nie są treścią materiału dowodowego,
jaki powstanie na podstawie szablonu.
Wersję elektroniczną niniejszego dokumentu można wykorzystać do opracowania
własnego dokumentu materiału dowodowego. Chcąc to osiągnąć należy:

usunąć pierwsze dwie strony (strona tytułowa i wstęp),

zastąpić wszystkie pola właściwą treścią,

usunąć wszystkie przypisy końcowe,

usunąć ostatnią stronę „Komentarze do szablonu materiału dowodowego”.
[skrót organizacji konstruktora]
[nazwa TOE]
[wersja TOE]
1
2
3
Zadanie zabezpieczeń
Security Target
Wersja dokumentu [wersja ST] 4
Data wydania [data wydania ST] 5
Common Criteria [wersja CC] 6 rewizja [rewizja CC] 7
Poziom uzasadnionego zaufania: [poziom EAL] 8
9
Wzbogacony o: [lista komponentów SAR wzbogacających dany poziom EAL] 10
[klauzula poufności dokumentu] 11
Opracowane dla:
Opracowane przez:
12
13
[logo sponsora ST]
[logo autorów ST]
[organizacja sponsora ST] 14
[organizacja autorów ST] 15
(strona celowo pozostawiona pusta)
[skrót nazwy TOE]
[klauzula poufności dokumentu]
[logo konstruktora]
SPIS TREŚCI
1.
Wprowadzenie do ST (ASE_INT) ................................................................................ 8
1.1
Metryczka ST ......................................................................................................... 9
1.2
Metryczka TOE .....................................................................................................10
1.3
Przegląd TOE .......................................................................................................10
1.3.1
Sposób użycia i główne cechy bezpieczeństwa TOE .....................................10
1.3.2
Typ TOE .........................................................................................................10
1.3.3
Wymagany sprzęt i oprogramowanie nie należące do TOE ...........................10
1.4
2.
3.
4.
Opis TOE ..............................................................................................................10
1.4.1
Składniki fizyczne i zakres fizyczny TOE ........................................................10
1.4.2
Składniki logiczne i zakres logiczny TOE .......................................................10
Deklaracje zgodności (ASE_CCL) ..............................................................................11
2.1
Deklaracja zgodności z CC ...................................................................................11
2.2
Deklaracja zgodności z PP ...................................................................................11
2.3
Deklaracja zgodności z pakietami .........................................................................11
2.4
Uzasadnienie zgodności .......................................................................................11
Definicja problemu bezpieczeństwa (ASE_SPD) ........................................................12
3.1
Zasoby ..................................................................................................................12
3.2
Podmioty ...............................................................................................................12
3.3
Zagrożenia ............................................................................................................12
3.4
Polityki bezpieczeństwa organizacji ......................................................................12
3.5
Założenia ..............................................................................................................13
Cele zabezpieczeń (ASE_OBJ) ..................................................................................14
4.1
Cele zabezpieczeń dla TOE .................................................................................14
4.2
Cele zabezpieczeń dla środowiska operacyjnego.................................................14
4.3
Uzasadnienie celów zabezpieczeń .......................................................................15
wersja: [wersja ST]
Data: [data wydania ST]
Strona 4 z 50
[skrót nazwy TOE]
4.3.1
[logo konstruktora]
Odwzorowanie poszczególnych aspektów definicji problemu bezpieczeństwa
na cele zabezpieczeń ................................................................................................. 15
4.3.2
5.
6.
7.
8.
Uzasadnienia dla odwzorowania.................................................................... 15
Definicja komponentów dodatkowych (ASE_ECD) .................................................... 17
5.1
Definicja dodatkowych komponentów SAR .......................................................... 17
5.2
Definicja dodatkowych komponentów SFR .......................................................... 17
Wymagania bezpieczeństwa (ASE_REQ) .................................................................. 18
6.1
Wymagania na funkcjonalność zabezpieczeń ...................................................... 18
6.2
Wymagania na uzasadnione zaufanie do zabezpieczeń ...................................... 18
6.3
Uzasadnienie wymagań bezpieczeństwa ............................................................. 18
6.3.1
Odwzorowanie celów zabezpieczeń na komponenty SFR ............................. 19
6.3.2
Uzasadnienia dla odwzorowania.................................................................... 19
6.3.3
Uzasadnienie dla zależności .......................................................................... 19
6.3.4
Uzasadnienie zestawu komponentów SAR ................................................... 20
Specyfikacja końcowa TOE (ASE_TSS) .................................................................... 21
7.1
Odwzorowanie komponentów SFR na funkcje zabezpieczające TOE ................. 21
7.2
Opis funkcji zabezpieczających TOE.................................................................... 21
7.3
Architektura zabezpieczeń TOE ........................................................................... 21
7.4
Podsumowanie materiału dowodowego ............................................................... 21
Załącznik .................................................................................................................... 24
8.1
Wykaz skrótów ..................................................................................................... 24
8.2
Słownik pojęć ....................................................................................................... 24
8.3
Bibliografia............................................................................................................ 24
SPIS RYSUNKÓW 16
wersja: [wersja ST]
Strona 5 z 50
[skrót nazwy TOE]
[logo konstruktora]
SPIS TABEL
Tabela 1. Metryczka ST ...................................................................................................... 9
Tabela 2. Metryczka TOE ..................................................................................................10
Tabela 3. Zasoby ...............................................................................................................12
Tabela 4. Podmioty ............................................................................................................12
Tabela 5. Zagrożenia .........................................................................................................12
Tabela 6. Polityki bezpieczeństwa organizacji ...................................................................12
Tabela 7. Założenia ...........................................................................................................13
Tabela 8. Cele zabezpieczeń dla TOE ...............................................................................14
Tabela 9. Cele zabezpieczeń dla środowiska operacyjnego ..............................................14
Tabela 10. Odwzorowanie SPD na cele zabezpieczeń ......................................................15
Tabela 11. Odwzorowanie zagrożeń – uzasadnienie.........................................................15
Tabela 12. Odwzorowanie polityk bezpieczeństwa organizacji – uzasadnienie .................16
Tabela 13. Odwzorowanie założeń – uzasadnienie ...........................................................16
Tabela 14. Komponenty SFR .............................................................................................18
Tabela 15. Komponenty SAR .............................................................................................18
Tabela 16. Odwzorowanie celów zabezpieczeń na komponenty SFR ...............................19
Tabela 17. Odwzorowanie celów zabezpieczeń dla TOE – uzasadnienie .........................19
Tabela 18. Zależności SAR – uzasadnienie.......................................................................19
Tabela 19. Zależności SFR – uzasadnienie .......................................................................19
Tabela 20. Odwzorowanie komponentów SFR na funkcje zabezpieczające TSF ..............21
Tabela 21. Podsumowanie materiału dowodowego ...........................................................22
wersja: [wersja ST]
Strona 6 z 50
[skrót nazwy TOE]
[logo konstruktora]
Historia zmian w dokumencie17
Wersja ST
Autor
Data
Opis zmiany
[nr wersji ST]
[autor zmiany]
[data zmiany]
[opis zmiany]
wersja: [wersja ST]
Strona 7 z 50
[skrót nazwy TOE]
[logo konstruktora]
1. Wprowadzenie do ST (ASE_INT)18
Dokument
zadania
zabezpieczeń
(ST
bezpieczeństwa dla produktu [nazwa TOE]
19
–
Security
[wersja TOE]
Target)
20
opisuje
cechy
([skrót nazwy TOE]
21
)
zwanego dalej przedmiotem oceny (TOE – Target of Evaluation) opracowanego przez
[organizacja konstruktora] 22.
Rozdział ten identyfikuje dokument zadania zabezpieczeń (ST), przedmiot oceny
(TOE) oraz opisuje strukturę zadania zabezpieczeń.
Struktura dokumentu zadania zabezpieczeń zdefiniowana w załączniku A do
pierwszej części normy CC [CC_1] jest następująca:

Wprowadzenie do ST (ASE_INT) – rozdział 1 – identyfikacja dokumentu
zadania zabezpieczeń oraz przedmiotu oceny (TOE), przegląd możliwości TOE
oraz opis TOE, czyli podanie fizycznego i logicznego zakresu TOE;

Deklaracje zgodności (ASE_CCL) – rozdział 2 – deklaracje zgodności
z konkretną wersją normy CC, pakietami (np. EAL) oraz profilami zabezpieczeń
(PP);

Definicja problemu bezpieczeństwa (ASE_SPD) – rozdział 3 – opis zagrożeń,
polityk bezpieczeństwa organizacji oraz założeń dotyczących przedmiotu oceny
i jego środowiska operacyjnego;

Cele zabezpieczeń (ASE_OBJ) – rozdział 4 – opis celów zabezpieczeń –
proponowane
rozwiązania
poszczególnych
aspektów
problemu
bezpieczeństwa w postaci celów zabezpieczeń dla TOE i dla środowiska
operacyjnego;

Definicja komponentów dodatkowych (ASE_ECD) – rozdział 5 – definicja
nowych komponentów na funkcjonalność zabezpieczeń (SFR) oraz na
uzasadnione zaufanie do zabezpieczeń (SAR) niewystępujących w drugiej
i trzeciej części normy CC;

Wymagania bezpieczeństwa (ASE_REQ) – rozdział 6 – wymagania na
uzasadnione zaufanie do zabezpieczeń (SAR) oraz
wyrażenie celów
zabezpieczeń dla TOE za pomocą wymagań na funkcjonalność zabezpieczeń
(SFR);
wersja: [wersja ST]
Strona 8 z 50
[skrót nazwy TOE]

[logo konstruktora]
Specyfikacja końcowa TOE (ASE_TSS) – rozdział 7 – opis funkcji
zabezpieczających TOE (TSF), czyli technicznych mechanizmów ochrony
wykorzystywanych przez przedmiot oceny.
1.1 Metryczka ST
Tabela 1. Metryczka ST
Tytuł ST
[skrót organizacji konstruktora]
23
,
[skrót nazwy TOE] 24 [wersja TOE]
25
– zadanie
zabezpieczeń
26
Wersja ST
[wersja ST]
Data wydania ST
[data wydania ST]
Język dokumentu
polski
Nazwa pliku
[skrót nazwy TOE]
27
28
_SecurityTarget_pl_[wersja ST]
[rozszerzenie pliku]
Autorzy ST
29
.
30
[organizacja autorów ST]
31
Adres: [adres autorów ST] 32
Telefon: [tel. autorów ST] 33
Strona www: [strona www autorów ST] 34
Sponsor ST
[organizacja sponsora ST]
35
Adres: [adres sponsora ST] 36
Telefon: [tel. sponsora ST] 37
Strona www: [strona www sponsora ST] 38
ID certyfikacji
[id jednostki certyfikującej] 39 [id certyfikacji] 40
Schemat oceny IT
[schemat oceny IT] 41
Instytucja oceniająca
[laboratorium akredytowane] 42
wersja: [wersja ST]
Strona 9 z 50
[skrót nazwy TOE]
[logo konstruktora]
1.2 Metryczka TOE
Tabela 2. Metryczka TOE
Nazwa TOE:
[nazwa TOE]
43
Wersja TOE
[wersja TOE]
44
Skrócona nazwa TOE
[skrót nazwy TOE]
Konstruktor TOE
[organizacja konstruktora]
45
46
Adres: [adres konstruktora]
47
Telefon: [tel. konstruktora] 48
Strona www: [strona www konstruktora] 49
1.3 Przegląd TOE50
1.3.1 Sposób użycia i główne cechy bezpieczeństwa TOE
[sposób użycia i główne cechy bezpieczeństwa TOE] 51
1.3.2 Typ TOE
[typ TOE] 52
1.3.3 Wymagany sprzęt i oprogramowanie nie należące do TOE
[wymagany sprzęt i oprogramowanie nie należące do TOE] 53
1.4 Opis TOE54
1.4.1 Składniki fizyczne i zakres fizyczny TOE
[składniki fizyczne i zakres fizyczny TOE] 55
1.4.2 Składniki logiczne i zakres logiczny TOE
[składniki logiczne i zakres logiczny TOE] 56
wersja: [wersja ST]
Strona 10 z 50
[skrót nazwy TOE]
[logo konstruktora]
2. Deklaracje zgodności (ASE_CCL)57
2.1 Deklaracja zgodności z CC
[deklaracja zgodności z CC] 58
2.2 Deklaracja zgodności z PP
[deklaracja zgodności z PP] 59
60
Zadanie zabezpieczeń (ST) nie deklaruje zgodności z jakimkolwiek profilem
zabezpieczeń (PP).
2.3 Deklaracja zgodności z pakietami
[deklaracja zgodności z pakietami] 61
62
Zadanie zabezpieczeń (ST) nie deklaruje zgodności z jakimkolwiek pakietem
wymagań bezpieczeństwa.
2.4 Uzasadnienie zgodności
[uzasadnienie zgodności z PP] 63
64
Zadania zabezpieczeń (ST) nie deklaruje zgodności z jakimkolwiek profilem
zabezpieczeń (PP), a zatem nie jest wymagane uzasadnienie tej zgodności.
wersja: [wersja ST]
Strona 11 z 50
[skrót nazwy TOE]
[logo konstruktora]
3. Definicja problemu bezpieczeństwa (ASE_SPD)65
W tej części dokumentu ST zdefiniowano problem bezpieczeństwa dotyczący TOE
i jego środowiska operacyjnego. Poszczególne aspekty problemu bezpieczeństwa
wyrażone są poprzez zagrożenia i polityki bezpieczeństwa organizacji dotyczące zarówno
TOE, jak i jego środowiska operacyjnego oraz założenia dotyczące tylko środowiska
operacyjnego. Dodatkowo zdefiniowano zasoby i podmioty, które są wykorzystywane przy
opisie poszczególnych aspektów definicji problemu bezpieczeństwa.
3.1 Zasoby66
Tabela 3. Zasoby
Symbol
67
[symbol zasobu]
Opis
[opis zasobu]
68
3.2 Podmioty69
Tabela 4. Podmioty
Symbol
70
[symbol podmiotu]
Opis
[opis podmiotu]
71
3.3 Zagrożenia72
Tabela 5. Zagrożenia
Symbol
73
[symbol zagrożenia]
Opis
[opis zagrożenia]
74
3.4 Polityki bezpieczeństwa organizacji75
Tabela 6. Polityki bezpieczeństwa organizacji
Symbol
76
[symbol polityki]
wersja: [wersja ST]
Opis
[opis polityki]
77
Strona 12 z 50
[skrót nazwy TOE]
[logo konstruktora]
3.5 Założenia78
Tabela 7. Założenia
Symbol
79
[symbol założenia]
wersja: [wersja ST]
Opis
[opis założenia]
80
Strona 13 z 50
[skrót nazwy TOE]
[logo konstruktora]
4. Cele zabezpieczeń (ASE_OBJ)81
Ten
rozdział
zadania
zabezpieczeń
przedstawia
proponowane
rozwiązania
poszczególnych aspektów problemu bezpieczeństwa w postaci celów zabezpieczeń dla
TOE i dla środowiska operacyjnego.
4.1 Cele zabezpieczeń dla TOE82
Tabela 8. Cele zabezpieczeń dla TOE
Symbol
83
[symbol celu 4TOE]
Opis
[opis celu zabezpieczeń dla TOE]
84
4.2 Cele zabezpieczeń dla środowiska operacyjnego85
Tabela 9. Cele zabezpieczeń dla środowiska operacyjnego
Symbol
86
[symbol celu 4ENV]
wersja: [wersja ST]
Opis
87
[opis celu zabezpieczeń dla środowiska operacyjnego]
Strona 14 z 50
[skrót nazwy TOE]
[logo konstruktora]
4.3 Uzasadnienie celów zabezpieczeń88
4.3.1 Odwzorowanie poszczególnych aspektów definicji problemu bezpieczeństwa
na cele zabezpieczeń
91
89
4ENV:[ symbol celu 4ENV]
4TOE:[ symbol celu 4TOE]
Cele zabezpieczeń
90
Tabela 10. Odwzorowanie SPD na cele zabezpieczeń
Zagrożenie
92
Polityka bezpieczeństwa
93
[symbol polityki]
Założenie
94
4.3.2 Uzasadnienia dla odwzorowania95
96
Tabela 11. Odwzorowanie zagrożeń – uzasadnienie
Zagrożenie
Cel zabezpieczeń
97
wersja: [wersja ST]
Uzasadnienie
98
4TOE: [symbol celu 4TOE]
100
4ENV: [symbol celu 4ENV]
99
[uzasadnienie odwzorowania zagrożenia]
101
[uzasadnienie odwzorowania zagrożenia]
Strona 15 z 50
[skrót nazwy TOE]
[logo konstruktora]
102
Tabela 12. Odwzorowanie polityk bezpieczeństwa organizacji – uzasadnienie
Cel zabezpieczeń
Polityka
[symbol polityki]
103
Uzasadnienie
104
4TOE: [symbol celu 4TOE]
106
105
[uzasadnienie odwzorowania polityki]
107
[uzasadnienie odwzorowania polityki]
108
Tabela 13. Odwzorowanie założeń – uzasadnienie
Założenie
Cel zabezpieczeń
109
wersja: [wersja ST]
Uzasadnienie
110
[uzasadnienie odwzorowania założenia]
111
Strona 16 z 50
[skrót nazwy TOE]
[logo konstruktora]
5. Definicja komponentów dodatkowych (ASE_ECD)112
Ten
rozdział
dodatkowych,
zadania
tzn.
zabezpieczeń
komponentów
SAR
(ST)
i
SFR
zawiera
definicje
komponentów
spoza
katalogu
komponentów
zdefiniowanych w drugiej i trzeciej części normy CC.
5.1 Definicja dodatkowych komponentów SAR
[definicja dodatkowych komponentów SAR] 113
114
Nie zdefiniowano dodatkowych komponentów SAR.
5.2 Definicja dodatkowych komponentów SFR
[definicja dodatkowych komponentów SFR] 115
116
Nie zdefiniowano dodatkowych komponentów SFR.
wersja: [wersja ST]
Strona 17 z 50
[skrót nazwy TOE]
[logo konstruktora]
6. Wymagania bezpieczeństwa (ASE_REQ)117
Ten rozdział zadania zabezpieczeń (ST) zawiera wymagania na funkcjonalność
zabezpieczeń (SFR) oraz wymagania na uzasadnione zaufanie do zabezpieczeń (SAR),
które są spełnione przez przedmiot oceny (TOE).
[konwencja zapisu operacji] 118
6.1 Wymagania na funkcjonalność zabezpieczeń119
Tabela 14. Komponenty SFR
Komponent SFR
[symbol komponentu SFR]
121
[opis komponentu SFR]
Element SFR
120
Opis elementu SFR
[symbol elementu SFR]
122
[opis elementu SFR]
123
6.2 Wymagania na uzasadnione zaufanie do zabezpieczeń124
Tabela 15. Komponenty SAR
Klasa SAR
[symbol klasy SAR] :
126
[opis klasy SAR]
Komponent SAR
125
[symbol komponentu SAR]
Opis komponentu SAR
127
[opis komponentu SAR]
128
6.3 Uzasadnienie wymagań bezpieczeństwa
Niniejszy
odwzorowanie
podrozdział
celów
zadania
zabezpieczeń
zabezpieczeń
na
zawiera
komponenty
tabele
SFR,
przedstawiające
uzasadnienie
tego
odwzorowania, uzasadnienie dla zależności oraz uzasadnienie wyboru zestawu
komponentów SAR.
wersja: [wersja ST]
Strona 18 z 50
[skrót nazwy TOE]
[logo konstruktora]
6.3.1 Odwzorowanie celów zabezpieczeń na komponenty SFR129
Cel zabezpieczeń dla TOE
[symbol celu 4TOE]
Komponent SFR
130
Tabela 16. Odwzorowanie celów zabezpieczeń na komponenty SFR
131
6.3.2 Uzasadnienia dla odwzorowania132
Tabela 17. Odwzorowanie celów zabezpieczeń dla TOE – uzasadnienie
Cel zabezpieczeń
[symbol celu 4TOE]
Komponent SFR
133
Uzasadnienie
134
[uzasadnienie odwzorowania celu 4TOE]
135
6.3.3 Uzasadnienie dla zależności136
Tabela 18. Zależności SAR – uzasadnienie
Komponent zależny
Zależność
spełniona
Uzasadnienie niespełnienia
[symbol zależnego komponentu SAR]
X139
[uzasadnienie niespełnienia zależności SAR]
Komponent SAR
[symbol komponentu SAR]
137
138
140
Tabela 19. Zależności SFR – uzasadnienie
Komponent zależny
Zależność
spełniona
Uzasadnienie niespełnienia
[symbol zależnego komponentu SFR]
X143
[uzasadnienie niespełnienia zależności SFR]
Komponent SFR
141
142
wersja: [wersja ST]
144
Strona 19 z 50
[skrót nazwy TOE]
[logo konstruktora]
6.3.4 Uzasadnienie zestawu komponentów SAR
[uzasadnienie zestawu komponentów SAR] 145
wersja: [wersja ST]
Strona 20 z 50
[skrót nazwy TOE]
[logo konstruktora]
7. Specyfikacja końcowa TOE (ASE_TSS)146
Ten
rozdział
zadania
zabezpieczeń
(ST)
szczegółowo
opisuje
funkcje
zabezpieczające TOE (TSF), czyli to jak TOE spełnia wymagania na funkcjonalność
zabezpieczeń (SFR).
7.1 Odwzorowanie komponentów SFR na funkcje zabezpieczające
TOE147
Komponent SFR
[symbol funkcji TSF]
Funkcja TSF
148
Tabela 20. Odwzorowanie komponentów SFR na funkcje zabezpieczające TSF
149
7.2 Opis funkcji zabezpieczających TOE
[opis funkcji zabezpieczających TOE] 150
7.3 Architektura zabezpieczeń TOE151
[architektura zabezpieczeń TOE] 152
7.4 Podsumowanie materiału dowodowego
Poniższa tabela podsumowuje informacje zawarte w dokumencie w odniesieniu do
wymagań klasy ASE dla zadania zabezpieczeń. Przedstawione wymagania są
reprezentowane przez poszczególne elementy typu C, określające zawartość materiału
dowodowego. Dla każdego elementu określone jest także, które części materiału
dowodowego odnoszą się do niego bezpośrednio, spełniając jego wymagania.
wersja: [wersja ST]
Strona 21 z 50
[skrót nazwy TOE]
Tabela 21. Podsumowanie materiału dowodowego
ASE_INT.1.1C
154
Rozdział 1
ASE_INT.1.2C
155
Podrozdział 1.1
ASE_INT.1.3C
156
Podrozdział 1.2
ASE_INT.1.4C
157
Podrozdział 1.3.1
ASE_INT.1.5C
158
Podrozdział 1.3.2
ASE_INT.1.6C
159
Podrozdział 1.3.3
ASE_INT.1.7C
160
Podrozdział 1.4.1
ASE_INT.1.8C
161
Podrozdział 1.4.2
ASE_CCL.1.1C
162
Podrozdział 2.1
ASE_CCL.1.2C
163
Podrozdział 2.1
ASE_CCL.1.3C
164
Podrozdział 2.1
ASE_CCL.1.4C
165
Podrozdziały 2.1, 5.1, 5.2
ASE_CCL.1.5C
166
Podrozdziały 2.2 i 2.3
ASE_CCL.1.6C
167
Podrozdział 2.3
ASE_CCL.1.7C
168
Podrozdział 2.4
ASE_CCL.1.8C
169
Podrozdział 2.4
ASE_CCL.1.9C
170
Podrozdział 2.4
171
Podrozdział 2.4
ASE_SPD.1.1C
172
Podrozdział 3.3
ASE_SPD.1.2C
173
Podrozdziały 3.2, 3.1, 3.3
ASE_SPD.1.3C
174
Podrozdział 3.4
ASE_SPD.1.4C
175
Podrozdział 3.5
ASE_OBJ.2.1C
176
Podrozdziały 4.1, 4.2
ASE_OBJ.2.2C
177
Podrozdział 4.3.1
ASE_OBJ.2.3C
178
Podrozdział 4.3.1
ASE_OBJ.2.4C
179
Podrozdziały 4.3.2 i 4.3.1
ASE_OBJ.2.5C
180
ASE_OBJ.2.6C
181
ASE_ECD.1.1C
182
Rozdział 5
ASE_ECD.1.2C
183
Rozdział 5
wersja: [wersja ST]
153
Materiał dowodowy
Wymaganie SAR
ASE_CCL.1.10C
[logo konstruktora]
Strona 22 z 50
[skrót nazwy TOE]
ASE_ECD.1.3C
184
Rozdział 5
ASE_ECD.1.4C
185
Rozdział 5
ASE_ECD.1.5C
186
Rozdział 5
ASE_REQ.2.1C
187
Rozdział 6
ASE_REQ.2.2C
188
Podrozdziały 8.2, 3.1 oraz 3.2
ASE_REQ.2.3C
189
ASE_REQ.2.4C
190
ASE_REQ.2.5C
191
Podrozdział 6.3.3
ASE_REQ.2.6C
192
Podrozdział 6.3.1
ASE_REQ.2.7C
193
ASE_REQ.2.8C
194
Podrozdział 6.3.4
ASE_REQ.2.9C
195
Rozdział 6
196
ASE_TSS.1.1C
197
198
199
200
Podrozdział 7.3
201
202
Podrozdział 7.3
ASE_TSS.2.1C
ASE_TSS.2.2C
ASE_TSS.2.3C
wersja: [wersja ST]
[logo konstruktora]
Strona 23 z 50
[skrót nazwy TOE]
[logo konstruktora]
8. Załącznik203
8.1 Wykaz skrótów204
Skrót
Rozwinięcie skrótu
Tłumaczenie polskie
CC
Common Criteria
Wspólne Kryteria
EAL
Evaluation Assurance Level
Poziom uzasadnionego zaufania
Information Technology
Technologia informacyjna
Organisational Security Policy
Polityka bezpieczeństwa organizacji
Protection Profile
Profil zabezpieczeń
SAR
Security Assurance Requirement
Wymaganie na uzasadnione zaufanie do zabezpieczeń
SFR
Security Functional Requirement
Wymaganie na funkcjonalność zabezpieczeń
SPD
Security Problem Definition
Definicja problemu bezpieczeństwa
Security Target
TOE
Target of Evaluation
Przedmiot oceny
TSF
TOE Security Functionality
Funkcje zabezpieczające TOE
IT
OSP
PP
ST
[skrót]
205
[rozwinięcie skrótu]
206
[tłumaczenie skrótu]
207
8.2 Słownik pojęć
Niniejszy słownik objaśnia terminy użyte w dokumencie, których znaczenie może być
niejasne bądź jest specyficzne w kontekście normy Common Criteria. Terminy wyjaśnione
w [CC_1] nie zostały tutaj powtórzone.
[wykaz terminów] 208
8.3 Bibliografia209
[CC_1]
Common Criteria, Part 1: Common Criteria for Information Technology
Security Evaluation, Part 1: Introduction and General Model, Version 3.1, July 2009.
[CC_2]
Security Evaluation, Part 2: Security Functional Requirements, Version 3.1, July 2009.
[CC_3]
Security Evaluation, Part 3: Security Assurance Requirements, Version 3.1, July 2009.
wersja: [wersja ST]
Strona 24 z 50
[skrót nazwy TOE]
[CEM]
[logo konstruktora]
Common Methodology for Information Technology Security Evaluation,
Evaluation Methodology, Version 3.1, July 2009.
[ST_Guide] ISO/IEC TR 15446 Guide for the production of Protection Profiles and
Security Targets.
[AB_SI]
Białas A.: Semiformal Common Criteria Compliant IT Security Development
Framework. Studia Informatica vol. 29, Number 2B(77), Silesian University of Technology
Press, Gliwice 2008
[[skrót nazwy dokumentu]
210
] [autorzy dokumentu]
211
, [nazwa dokumentu]
212
[wydawca dokumentu] 213, [data wydania] 214
wersja: [wersja ST]
Strona 25 z 50
,
[skrót nazwy TOE]
[logo konstruktora]
Komentarze do szablonu materiału dowodowego
1
Skrócona nazwa organizacji konstruującej TOE.
2
Pełna nazwa przedmiotu oceny (TOE).
3
Pole zawiera numer wersji przedmiotu oceny, zgodnie z przyjętym w organizacji schematem. Możliwe są
różne schematy oznaczania wersji TOE. Ważne jest, aby oznaczenie wersji nie zawierało nazwy skróconej
TOE. Przykłady: 1.2; 2.3.1.0.
4
Bieżąca wersja dokumentu ST.
5
Data wydania bieżącej wersji dokumentu ST.
6
Numer wersji Common Criteria, względem której prowadzona jest certyfikacja TOE.
7
Numer rewizji Common Criteria, względem której prowadzona jest certyfikacja TOE.
8
Zadeklarowany poziom EAL.
9
Tylko jeśli zadeklarowany poziom EAL został wzbogacony o inne komponenty.
10
Tylko jeśli zadeklarowany poziom EAL został wzbogacony o inne komponenty. W tym miejscu należy
wypisać wszystkie komponenty SAR wzbogacające dany poziom EAL. Lista komponentów ma być zgodna
z podrozdziałem 2.3, gdzie deklaruje się zgodność z pakietami (poziomy EAL są też pakietami).
11
Klauzula poufności dokumentu, określająca zakres informacji prawnie chronionych. Przykładowe klauzule:
Poufne, Tajemnica przedsiębiorstwa.
12
Logo organizacji, która sponsoruje opracowanie dokumentu ST, czyli najczęściej organizacji sponsorującej
cały proces certyfikacji TOE.
13
14
Logo organizacji, która opracowała dokument ST.
Nazwa organizacji, która sponsoruje opracowanie dokumentu ST, czyli najczęściej organizacji
sponsorującej cały proces certyfikacji TOE.
15
16
Nazwa organizacji, która opracowała dokument ST.
Spis rysunków dokumentu. Zalecane jest, aby spis został wygenerowany automatycznie z użyciem
narzędzi edytora tekstów.
17
Historia zmian dokumentu w formie tabeli. W kolejnych polach tabeli umieszcza się wersję dokumentu
(zgodną z określonym sposobem wersjonowania), autora zmiany, datę zmiany oraz krótki opis zmiany.
18
Wprowadzenie do zadania zabezpieczeń opisuje w języku naturalnym TOE, na trzech poziomach
abstrakcji:

metryczka ST (ST reference) oraz metryczka TOE (TOE reference), które identyfikują poszczególne
ST i TOE;

przegląd TOE (TOE overview), który krótko opisuje TOE;

opis TOE (TOE description), który bardziej szczegółowo opisuje TOE.
19
20
Wersja TOE.
21
Krótka nazwa (symboliczna) opisywanego przedmiotu oceny – TOE, która pozwoli go identyfikować
w dalszej części dokumentu.
22
Pełna nazwa organizacji konstruującej TOE, która przedstawia go do oceny.
wersja: [wersja ST]
Strona 26 z 50
[skrót nazwy TOE]
23
24
[logo konstruktora]
Skrócona nazwa organizacji konstruującej TOE, która przedstawia go do oceny.
25
26
27
Data wydania bieżącej wersji dokumenty ST.
28
29
30
Rozszerzenie pliku, np. „doc”, „pdf", „odt”.
31
Nazwa organizacji, która opracowała dokument ST.
32
Adres organizacji, która opracowała dokument ST.
33
Telefon organizacji, która opracowała dokument ST.
34
Adres strony internetowej organizacji, która opracowała dokument ST.
35
Nazwa organizacji, która sponsoruje opracowanie dokumentu ST, czyli najczęściej organizacji
36
Adres organizacji, która sponsoruje opracowanie dokumentu ST, czyli najczęściej organizacji
37
Telefon organizacji, która sponsoruje opracowanie dokumentu ST, czyli najczęściej organizacji
38
Adres strony internetowej organizacji, która sponsoruje opracowanie dokumentu ST, czyli najczęściej
organizacji sponsorującej cały proces certyfikacji TOE.
39
Identyfikator organizacji certyfikującej, np. BSI-DSZ-CC.
40
Identyfikator przeprowadzanego procesu certyfikacji.
41
Schemat oceny IT, np. German CC Evaluation Scheme.
42
Laboratorium certyfikujące TOE.
43
44
45
46
Pełna nazwa organizacji konstruującej TOE, która przedstawia go do oceny.
47
Adres organizacji konstruującej TOE, która przedstawia go do oceny.
48
Numer telefonu organizacji konstruującej TOE, która przedstawia go do oceny.
49
Adres strony internetowej organizacji konstruującej TOE, która przedstawia go do oceny.
wersja: [wersja ST]
Strona 27 z 50
[skrót nazwy TOE]
50
[logo konstruktora]
Przegląd TOE jest skierowany do potencjalnych klientów, którzy przeglądają listę ocenionych produktów
(TOE) w poszukiwaniu takich produktów, które spełniają ich oczekiwania w zakresie bezpieczeństwa oraz są
obsługiwane przez ich sprzęt, oprogramowanie oraz oprogramowanie układowe. Typowa wielkość opisu
dotyczącego przeglądu TOE to kilka akapitów.
Przegląd TOE krótko opisuje sposób użycia przedmiotu oceny i jego główne cechy bezpieczeństwa, określa
typ TOE oraz identyfikuje wymagany przez TOE sprzęt, oprogramowanie i oprogramowanie układowe (nie
będące przedmiotem oceny).
51
Opis sposobu użycia i głównych cech bezpieczeństwa TOE jest potrzebny, aby uzyskać bardzo ogólną
wiedzę o tym, jakie są możliwości TOE pod względem stosowanych zabezpieczeń. Podrozdział ten jest
dedykowany potencjalnym klientom, opisując za pomocą zrozumiałego dla nich języka sposób
użycia/użytkowania TOE i jego główne cechy bezpieczeństwa.
Przykładem takiego opisu jest:
„Baza danych MauveRAM v2.11 firmy MauveRAM jest wieloużytkownikową bazą danych przeznaczoną do
stosowania w środowisku sieciowym. Obsługuje jednocześnie do 1024 użytkowników. Pozwala na
uwierzytelnianie za pomocą hasła, tokena lub danych biometrycznych. Chroni przed przypadkowym
uszkodzeniem danych i może cofnąć (rollback) do 10000 operacji. Jej funkcje audytu są wysoce
konfigurowalne, co umożliwia szczegółowy audyt przeprowadzany dla poszczególnych użytkowników
i transakcji, przy jednoczesnej ochronie prywatności innych użytkowników i transakcji”.
52
Przegląd TOE określa ogólny typ TOE, np.: zapora sieciowa, zapora sieciowa VPN, karta chipowa, krypto-
modem, intranet, serwer WWW, baza danych, serwer WWW z bazą danych, sieć LAN, sieć LAN z serwerem
WWW i bazą danych, itp. Może się tak zdarzyć, że typ TOE jest trudny do określenia, w takim przypadku
dopuszczalny jest typ „żaden” („none”).
W niektórych przypadkach zadeklarowany typ TOE może wskazywać na funkcjonalność, której TOE
w rzeczywistości nie posiada, co może wprowadzić klientów w błąd, np.:

TOE należące do typu karta płatnicza, które nie obsługuje funkcji identyfikacji i uwierzytelniania;

TOE należące do typu zapora sieciowa, które nie obsługuje powszechnie stosowanych protokołów;

TOE należące do typu PKI (Infrastruktura Klucza Publicznego), które nie posiada funkcji
unieważniania certyfikatów.
Nieporozumienia mogą wynikać również z powodu zadeklarowanego typu TOE, gdy oczekuje się od niego,
że będzie działał w konkretnych środowiskach operacyjnych, a w rzeczywistości tego nie umożliwia, np.:

TOE należące do typu system operacyjny, które nie jest w stanie bezpiecznie funkcjonować, chyba
że komputer nie ma połączenia z siecią, stacji dyskietek oraz odtwarzacza CD/DVD;

TOE należące do typu zapora sieciowa, które nie jest w stanie bezpiecznie funkcjonować, chyba że
żaden użytkownik łączący się przez zaporę nie będzie złośliwy.
53
Większość przedmiotów oceny TOE (zwłaszcza oprogramowanie) wymaga dodatkowego sprzętu,
oprogramowania lub oprogramowania układowego. Przegląd TOE wymaga zidentyfikowania takich
produktów IT (nie należących do TOE). Lista wymaganych produktów IT nie musi być pełna, ale na tyle
szczegółowa, aby określić główny sprzęt, oprogramowanie i oprogramowanie układowe potrzebne do
użytkowania TOE.
wersja: [wersja ST]
Strona 28 z 50
[skrót nazwy TOE]
[logo konstruktora]
Przykładem takich produktów IT są:

standardowy komputer PC z przynajmniej 1GHz procesorem i 512 MB pamięci RAM, z systemem
operacyjnym Yaiza w wersji 3.0 Update 6b, c, wersji 7 lub wersji 4.0;

standardowy komputer PC z przynajmniej 1GHz procesorem i 512 MB pamięci RAM, z systemem
operacyjnym Yaiza w wersji 3.0 Update 6b oraz kartą graficzną WonderMagic 1.0 i sterownikiem 1.0
WM Driver Set;
54

standardowy komputer PC z systemem operacyjnym Yaiza w wersji 3.0 (lub nowszej);

układ scalony CleverCard SB2067;

układ scalony CleverCard SB2067 z systemem operacyjnym dla kart chipowych QuickOS v2.0;

instalacja sieci LAN z grudnia 2002 roku w biurze dyrektora generalnego Wydziału Ruchu.
Opis TOE, zazwyczaj kilkustronicowy, jest opisem przedmiotu oceny w języku naturalnym. Opis TOE
powinien dostarczać oceniającym i potencjalnym klientom wiedzę ogólną na temat możliwości przedmiotu
oceny dotyczących zabezpieczeń, ale w sposób bardziej szczegółowy niż w przeglądzie TOE. Opis ten
może zawierać również prezentację innych zastosowań TOE.
55
W opisie TOE należy omówić zakres fizyczny przedmiotu oceny, tzn. listę wszystkich części stanowiących
TOE, obejmującą sprzęt, oprogramowanie, oprogramowanie układowe oraz podręczniki. Lista ta powinna
być opisana na takim poziomie szczegółowości, aby dać czytelnikowi ogólny obraz części składowych TOE.
Ważną kwestią dotyczącą zakresu fizycznego i logicznego TOE jest to, aby w sposób jednoznaczny określić,
które części lub funkcje należą do TOE, a które znajdują się poza TOE. Jest to szczególnie ważne, gdy TOE
jest ściśle związane z innymi produktami IT, nie będącymi przedmiotem oceny.
Przykłady takich TOE ściśle związanych z innymi produktami IT to:

przedmiotem oceny jest koprocesor kryptograficzny, znajdujący się na karcie chipowej;

przedmiotem oceny jest układ scalony karty chipowej, z wyłączeniem procesora kryptograficznego;

przedmiotem oceny jest maskarada sieci (NAT – ang. Network Address Translation) jako część
systemu zaporowego MinuteGap v18.5.
56
W opisie TOE należy omówić również zakres logiczny przedmiotu oceny, czyli podać krótki opis funkcji
zabezpieczających TOE, szerzej opisanych w specyfikacji końcowej TOE. Opis ten powinien być na tyle
szczegółowy, aby czytelnik miał ogólne wyobrażenie na temat tych funkcji.
57
58
Ten rozdział zadania zabezpieczeń opisuje w jaki sposób ST jest zgodne z:

drugą i trzecią częścią normy Common Criteria;

profilami zabezpieczeń (opcjonalne);

pakietami (opcjonalne).
Deklaracja zgodności z CC wskazuje źródło katalogu wymagań bezpieczeństwa dla ocenianego ST.
Należy opisać:
a) wersję CC, z którą ST deklaruje zgodność, dodatkowo jeżeli korzystano z oficjalnego
tłumaczenie normy CC, należy podać również język i wersję tłumaczenia;
b) sposób zgodności z drugą częścią normy CC (z wymaganiami na funkcjonalność zabezpieczeń
– SFR) jako jeden z poniższych:
wersja: [wersja ST]
Strona 29 z 50
[skrót nazwy TOE]

[logo konstruktora]
zgodny z drugą częścią normy CC – ST jest zgodne z drugą częścią normy CC, jeśli
wszystkie wymagania SFR w tym ST są oparte (identyczne lub zmienione za pomocą
dozwolonych przez CC czterech operacji, więcej o operacjach w rozdziale 8.1 pierwszej
części normy CC [CC_1]) na komponentach SFR z części drugiej CC;

rozszerzony w stosunku do drugiej części normy CC – ST jest rozszerzone w stosunku do
drugiej części normy CC, jeśli przynajmniej jeden komponent SFR w tym ST nie jest oparty
na komponentach SFR z drugiej części CC.
c) opisuje sposób zgodności z trzecią częścią normy CC (wymagania na uzasadnione zaufanie
do zabezpieczeń – SAR) jako jeden z:

zgodny z trzecią częścią normy CC – ST jest zgodne z trzecią częścią normy CC, jeśli
wszystkie komponenty SAR w tym ST są oparte (identyczne lub zmienione za pomocą
dozwolonych przez CC czterech operacji) na komponentach uzasadniających zaufanie
z trzeciej części CC;

rozszerzony w stosunku do trzeciej części normy CC – ST jest rozszerzone w stosunku do
trzeciej części normy CC, jeśli przynajmniej jeden SAR w tym ST nie jest oparty
na komponentach uzasadniających zaufanie z trzeciej części CC.
Przykładem deklaracji zgodności z CC jest:
„Wersja CC: Common Criteria for Information Technology Security Evaluation, Version 3.1 Revision 3, lipiec
2009.
Dokument ST jest zgodny z drugą częścią normy CC oraz rozszerzony w stosunku do trzeciej części normy
CC”.
59
Tylko jeśli ST deklaruje zgodność z profilami zabezpieczeń. Deklaracja zgodności z profilami
zabezpieczeń (PP – Protection Profile) składa się z listy profilów zabezpieczeń, z którymi ST deklaruje
zgodność.
Przykład deklaracji zgodności z profilem zabezpieczeń:
„Zadanie zabezpieczeń deklaruje wykazaną (demonstrable) zgodność z profilem zabezpieczeń pt.
<<Controlled Access Protection Profile>>, wydanie 1.d z października 1999 roku. Powyższy profil
zabezpieczeń znajduje się na stronie internetowej www.commoncriteriaportal.org w dziale Protection
Profiles”.
60
61
Tylko jeśli ST nie deklaruje zgodności z jakimkolwiek profilem zabezpieczeń.
Tylko jeśli ST deklaruje zgodność z pakietami. Deklaracja zgodności z pakietami składa się z listy
pakietów, z którymi ST deklaruje zgodność. Pakiet to nazwany zbiór komponentów SAR lub SFR. Mieszane
pakiety, zawierające zarówno komponenty SAR jak i SFR są niedozwolone. Przykładami pakietów są
poziomy uzasadnionego zaufania (EAL). Dla każdego pakietu należy określić, czy ST jest w stosunku do
tego pakietu:

zgodne – jeśli wszystkie komponenty SFR z tego ST są identyczne z komponentami SFR z pakietu
lub wszystkie komponenty SAR z tego ST są identyczne z komponentami SAR z pakietu;
wersja: [wersja ST]
Strona 30 z 50
[skrót nazwy TOE]

[logo konstruktora]
wzbogacone – jeśli ST zawiera wszystkie komponenty SFR/SAR z tego pakietu oraz przynajmniej
jeden komponent SFR/SAR spoza pakietu lub jeden komponent SFR/SAR, który jest wyżej
w hierarchii, niż komponent SFR/SAR z pakietu.
Należy zauważyć, że w przypadku gdy TOE został pozytywnie oceniony na podstawie danego ST,
jakiekolwiek deklaracje zgodności ST odnoszą się również do TOE. Oznacza to, że TOE może również być
zgodne np. z drugą częścią normy CC.
Przykładowa zgodność z pakietem:
„Zadanie zabezpieczeń jest zgodne z pakietem EAL3 wzbogaconym o komponent ALC_FLR.2”.
W przypadku, gdy pakiet EAL zostanie wzbogacony, wtedy na stronie tytułowej do oznaczenia poziomu EAL
dopisywany jest znak „+”, np. EAL4+.
62
Tylko jeśli ST nie deklaruje zgodności z jakimkolwiek pakietem wymagań bezpieczeństwa.
63
Tylko jeśli ST deklaruje zgodność z profilami zabezpieczeń. Jeśli zadeklarowano zgodność z jakimkolwiek
profilem zabezpieczeń, to w tym podrozdziale dla każdego PP należy wykazać, że:

typ TOE zadeklarowany w ST jest zgodny z typem TOE opisanym w PP; czasem może to być prosta
zgodność (np. ST dla zapory sieciowej zgodny z PP dla zapory sieciowej) albo bardziej złożona (np.
ST dla kart inteligentnych, który jest zgodny z kilkoma PP jednocześnie – PP dla układów scalonych,
PP dla systemów operacyjnych kart inteligentnych i dwoma PP dla aplikacji dedykowanych pod karty
inteligentne);

definicja problemu bezpieczeństwa w ST jest zgodna z definicją problemu bezpieczeństwa
występującą w PP; uzasadnienie jest konieczne tylko jeśli PP wymaga wykazanej (demonstrable)
zgodności;

cele zabezpieczeń w ST są zgodne z celami zabezpieczeń opisanymi w PP; uzasadnienie jest
konieczne tylko jeśli PP wymaga wykazanej (demonstrable) zgodności;

wymagania bezpieczeństwa w ST są zgodne z listą wymagań bezpieczeństwa występującą w PP;
uzasadnienie jest konieczne tylko jeśli PP wymaga wykazanej (demonstrable) zgodności.
64
Tylko jeśli ST nie deklaruje zgodności z jakimkolwiek profilem zabezpieczeń.
65
Opracowywanie definicji problemu bezpieczeństwa wychodzi poza zakres CC. Oznacza to, że w normie
CC nie opisano komponentów z konkretnymi aspektami problemu bezpieczeństwa (zagrożeniami, politykami
bezpieczeństwa organizacji oraz założeniami). Istnieje jednak przewodnik dla konstruktorów zabezpieczeń
zgodny z CC [ST_Guide] oraz publikacje naukowe [AB_SI], które wprowadzają wzorcowe elementy
specyfikacji zwane generykami zapisane w języku półformalnym. Generyki te na wzór zdefiniowanych w CC
komponentów SAR i SFR opisują problem bezpieczeństwa (zagrożenia, polityki bezpieczeństwa oraz
założenia), cele zabezpieczeń (dla TOE i dla środowiska operacyjnego TOE) oraz funkcje zabezpieczające
TOE (TSF). Dodatkowo wprowadzono generyki opisujące zasoby (ang. assets), które podlegają
zagrożeniom oraz podmioty (ang. subjects) reprezentujące użytkowników TOE, procesy oraz agentów
zagrożeń.
Użyteczność wyników oceny w dużej mierze zależy od zadania zabezpieczeń ST, a użyteczność ST zależy
głównie od jakości definicji problemu bezpieczeństwa. Warto zatem poświęcić znaczne środki oraz
wersja: [wersja ST]
Strona 31 z 50
[skrót nazwy TOE]
[logo konstruktora]
skorzystać z dobrze zdefiniowanych procesów i analiz w celu uzyskania dobrej definicji problemu
bezpieczeństwa.
Należy pamiętać, że zgodnie z trzecią częścią normy CC nie ma obowiązku wykorzystania wszystkich trzech
rodzajów aspektów problemu bezpieczeństwa jednocześnie, tzn. jeśli w ST są zagrożenia, to nie muszą być
polityki bezpieczeństwa organizacji i odwrotnie. Ponadto w ST można pominąć również założenia.
W przypadku, gdy TOE jest fizycznie rozproszony, najczęściej lepiej jest omówić stosowne zagrożenia,
polityki (OSP) oraz założenia oddzielnie dla poszczególnych części środowiska operacyjnego.
66
Należy zauważyć, że norma CC nie określa bezpośrednio, czy trzeba wymieniać zasoby, które później
będą wykorzystywane przy opisie poszczególnych aspektów problemu bezpieczeństwa, jest to natomiast
z pewnością pomocne.
Zasobami mogą być pliki komputerowe, dokumenty, usługi oferowane przez TOE oraz procesy zachodzące
w środowisku operacyjnym TOE. Każdy zasób, który ulegnie uszkodzeniu może negatywnie wpływać na
TOE.
Przykładem zasobu zapisanego w języku naturalnym jest:
„Klucz prywatny używany podczas tworzenia podpisu cyfrowego oraz odszyfrowywania poufnych informacji”.
Ten sam zasób można zapisać w postaci półformalnego generyka:
Typ generyka:
DTO – Obiekty danych, usługi i inne zasoby związane z TOE
Symbol:
DTO.PrivKey
Klucz
Opis:
prywatny
używany
podczas
tworzenia
podpisu
cyfrowego
oraz
odszyfrowywania poufnych informacji
67
Krótka nazwa symboliczna zasobu, np.: DTO.PrivKey.
68
Opis zasobu.
69
Podmiotem jest każda aktywna jednostka wykonująca pewne operacje na zasobach TOE. Norma CC nie
określa wprost, że należy wymieniać podmioty będące agentami zagrożeń, które później będą
wykorzystywane przy opisie poszczególnych aspektów problemu bezpieczeństwa, jest to natomiast
z pewnością pomocne.
Agenci zagrożeń mogą być opisani jako pojedyncze podmioty, jako typy lub grupy podmiotów. Przykładem
takich agentów są: hakerzy, użytkownicy, procesy komputerowe oraz siła wyższa (czynnik sprawczy różnych
wypadków losowych). Agenci zagrożeń mogą być bardziej szczegółowo opisani przez takie aspekty, jak
umiejętności, zasoby, możliwości i motywacja.
Przykład podmiotu zapisanego w języku naturalnym:
„Napastnik posiadający wysoki poziom umiejętności, wystarczające środki i głęboką motywację
przeprowadza atak celowy na zasoby”.
Ten sam podmiot można zapisać w postaci półformalnego generyka:
Typ generyka:
SNA – Nieautoryzowany podmiot zdarzeń
Symbol:
SNA.HighPotenIntrud
wersja: [wersja ST]
Strona 32 z 50
[skrót nazwy TOE]
Napastnik posiadający wysoki poziom umiejętności, wystarczające środki i głęboką
Opis:
motywację przeprowadza atak celowy na zasoby
70
Krótka nazwa symboliczna podmiotu, np.: SNA.HighPotenIntrud.
71
Opis podmiotu.
72
[logo konstruktora]
Ta
część
definicji
problemu
bezpieczeństwa
identyfikuje
zagrożenia,
które
mają
być
zwalczane przez sam przedmiot oceny – TOE, jego środowisko operacyjne lub ich kombinację. Opis
zagrożenia zawiera agenta zagrożenia, zasób oraz niepożądane działanie agenta zagrożenia na tym
zasobie.
Niepożądanie działania to czynności wykonywane przez agentów zagrożeń na zasobach. Czynności te
mogą mieć wpływ na różne właściwości danego zasobu, co powoduje obniżenie wartości tego zasobu.
Przykładowe zagrożenia zapisane w języku naturalnym to:

haker (z dużą wiedzę, standardowym wyposażeniem i odpowiednią motywacją) zdalnie kopiujący
poufne pliki projektu TOE z wewnętrznej sieci danej firmy;

robak komputerowy, poważnie obniżający wydajność sieci rozległej WAN;

administrator systemu, naruszający prywatność użytkowników;

użytkownik internetowy, podsłuchujący poufną rozmowę elektroniczną.
Zagrożenia można zapisać również w postaci półformalnego generyka:
Typ generyka:
TDA – Zagrożenie spowodowane atakiem bezpośrednim hakera lub innego intruza
Symbol:
TDA.EavesdrpCommLines
Nieuprawniony użytkownik [SNA] otrzymał dane użytkownika [DTO] poprzez podsłuch
Opis:
na linii
Dla generyków zagrożeń, polityk bezpieczeństwa, założeń i celów zabezpieczeń możliwe jest dodanie
(w sekcji „opis”) parametrów związanych z generykami zasobów lub podmiotów. Parametry podaje się
w nawiasach kwadratowych w postaci typów zasobów lub podmiotów.
73
Krótka nazwa symboliczna zagrożenia, np.: TDA.EavesdrpCommLines.
74
Opis zagrożenia.
75
Ta część definicji problemu bezpieczeństwa identyfikuje polityki bezpieczeństwa organizacji (OSP –
Organisational security policies), które mają być wymuszane przez przedmiot oceny TOE, jego środowisko
operacyjne lub ich kombinację. Polityki bezpieczeństwa organizacji to zasady, praktyki lub wytyczne
dotyczące bezpieczeństwa nałożone (lub przypuszczalnie nakładane) teraz lub w przyszłości przez
potencjalnego klienta w jego środowisku operacyjnym TOE. Mogą one zostać ustanowione przez jednostkę
organizacyjną kontrolującą środowisko operacyjne TOE, być określone w drodze ustawodawczej lub
ustanowione przez organy regulacyjne. Polityki OSP mogą dotyczyć zarówno TOE jak i jego środowiska
operacyjnego.
Przykładowe polityki bezpieczeństwa organizacji to:

wszystkie produkty, które są używane przez rząd muszą być zgodne z krajową normą dotyczącą
generowania haseł i szyfrowania;
wersja: [wersja ST]
Strona 33 z 50
[skrót nazwy TOE]

[logo konstruktora]
tylko użytkownicy z prawami administratora systemu, będący pracownikami organizacji rządowej
Department Secret mają prawo do zarządzania serwerem plików Department Fileserver.
Polityki bezpieczeństwa organizacji można zapisać również w postaci półformalnego generyka:
Typ generyka:
PACC – Polityki specyfikujące kontrolę dostępu i zasady kontroli przepływu informacji
Symbol:
PACC.SysAccCtrl
Administrator systemu [SAU] zapewni kontrolę dostępu do systemu operacyjnego na
Opis:
którym zainstalowany jest TOE
76
Krótka nazwa symboliczna polityki bezpieczeństwa organizacji, np.: PACC.SysAccCtrl.
77
Opis polityki bezpieczeństwa organizacji.
78
Ta część definicji problemu bezpieczeństwa opisuje założenia dotyczące środowiska operacyjnego TOE.
Gdyby TOE znajdował się w środowisku operacyjnym, które nie spełnia tych założeń, wtedy nie mógłby
prawidłowo wykonywać wszystkich swoich funkcji zabezpieczających. Założenia mogą dotyczyć aspektów
fizycznych środowiska operacyjnego, jego personelu oraz aspektów połączeniowych tego środowiska.
Przykładowe założenia to:

założenia dotyczące fizycznych aspektów środowiska operacyjnego:
o
zakłada się, że TOE zostanie umieszczony w pomieszczeniu, które jest tak
zaprojektowane;
o
zakłada się, że pulpit sterowniczy administratora TOE będzie umieszczony
w obszarze ograniczonego dostępu.

założenia dotyczące personelu środowiska operacyjnego:
o
zakłada się, że użytkownicy TOE zostaną przeszkoleni w wystarczającym stopniu,
aby mogli pracować z TOE;
o
zakłada się, że użytkownicy TOE są dopuszczeni do informacji, które są
sklasyfikowane jako tajne dane typu „National Secret”;
o

zakłada się, że użytkownicy TOE nie będą zapisywać swoich haseł.
założenia dotyczące aspektów połączeniowych środowiska operacyjnego:
o
zakłada się, że dostępna jest dla TOE stacja robocza PC z dyskiem twardym co
najmniej 10 GB;
o
zakłada się, że TOE jest jedyną aplikacją poza systemem operacyjnym, pracującą
na tej stacji roboczej;
o
zakłada się, że TOE nie będzie podłączony do niezaufanej sieci.
Założenia można zapisać również w postaci półformalnego generyka:
Typ generyka:
APR – Założenia dotyczy personelu
Symbol:
APR.OnlyAdminAccess
wersja: [wersja ST]
Strona 34 z 50
[skrót nazwy TOE]
[logo konstruktora]
Jedynie administratorzy sieci [SAU] mają dostęp do panelu sterowania systemem
Opis:
zaporowym
Należy pamiętać, że w trakcie oceny wszystkie założenie są uważane za prawdziwe, tzn. nie są testowane
w jakikolwiek sposób. Z tego powodu, założenia mogą dotyczyć tylko środowiska operacyjnego. Założenia
nie mogą się odnosić do zachowania TOE, ponieważ stwierdzenia dotyczące pracy TOE będą sprawdzane
przez oceniającego. Nie można z góry zakładać, że TOE pracuje poprawnie.
79
Krótka nazwa symboliczna założenia, np.: APR.OnlyAdminAccess.
80
Opis założenia.
81
Cele zabezpieczeń to krótkie i zwięzłe stwierdzenia opisujące proponowane rozwiązania poszczególnych
aspektów zdefiniowanego wcześniej problemu bezpieczeństwa (SPD). Cele zabezpieczeń spełniają trzy
role:

dostarczenie rozwiązania problemu, które jest wyrażone na wysokim poziomie abstrakcji w języku
naturalnym;

podział proponowanych rozwiązań na dwie części (dla TOE i dla środowiska operacyjnego);

wykazanie, że obie części rozwiązań tworzą kompletne rozwiązanie problemu.
Cele zabezpieczeń składają się z zestawu krótkich i przejrzystych sformułowań, które razem tworzą
rozwiązanie problemu bezpieczeństwa (SPD) na takim poziomie abstrakcji, aby cele zabezpieczeń były
jasne i zrozumiałe dla potencjalnych klientów TOE. Cele zabezpieczeń są wyrażone w języku naturalnym.
W zadaniu zabezpieczeń ST rozwiązanie problemu bezpieczeństwa, wyrażone za pomocą celów
zabezpieczeń jest podzielone na dwie części rozwiązań: cele zabezpieczeń dla TOE oraz cele zabezpieczeń
dla środowiska operacyjnego. Oznacza to, że rozwiązania powinny być dostarczane oddzielnie przez
przedmiot oceny TOE i przez środowisko operacyjne.
82
Przedmiot oceny TOE zawiera funkcje zabezpieczające, będące rozwiązaniem poszczególnych aspektów
definicji problemu bezpieczeństwa. Cele zabezpieczeń dla TOE składają się z zestawu celów, które TOE
powinien osiągnąć, aby rozwiązać odpowiednie aspekty problemu bezpieczeństwa.
Przykładowe cele zabezpieczeń dla TOE to:

TOE musi zachować poufność treści plików, przesyłanych pomiędzy nim a serwerem;

TOE identyfikuje i uwierzytelnia wszystkich użytkowników przed umożliwieniem im dostępu do usług
przesyłowych świadczonych przez TOE;

TOE musi ograniczać dostęp do danych użytkownikom zgodnie z polityką dostępu do danych,
opisaną w załączniku nr 3 do niniejszego zadania zabezpieczeń.
Cele zabezpieczeń dla TOE można zapisać również w postaci półformalnego generyka:
Typ generyka:
OACC – Cele dotyczące dostępu do zasobów (dostęp logiczny)
Symbol:
OACC.UserPrivMan
wersja: [wersja ST]
Strona 35 z 50
[skrót nazwy TOE]
[logo konstruktora]
TOE zapewni mechanizmy zarządzania prawami dostępu użytkowników [SAU] do
Opis:
informacji [DTO] zawartych w TOE
W przypadku, gdy TOE jest fizycznie rozproszony, najczęściej lepiej jest podzielić rozdział ST dotyczący
celów zabezpieczeń dla TOE na kilka podrozdziałów.
83
Krótka nazwa symboliczna celu zabezpieczeń dla TOE, np.: OACC.UserPrivMan.
84
Opis celu zabezpieczeń dla TOE.
85
Środowisko operacyjne TOE zawiera techniczne i proceduralne środki, które wspomagają TOE
w poprawnym działaniu jego funkcji zabezpieczających (zdefiniowanych poprzez cele zabezpieczeń dla
TOE). Ta część rozwiązań to cele zabezpieczeń dla środowiska operacyjnego, które składają się z zestawu
sformułowań, opisujących cele, które środowisko operacyjne powinno osiągnąć.
Przykładowe cele zabezpieczeń dla środowiska operacyjnego to:

środowisko operacyjne wyposażone jest w stację roboczą z systemem operacyjnym „Inux” w wersji
3.01b, na której będzie pracował przedmiot oceny TOE;

środowisko operacyjne zapewnia, że wszyscy użytkownicy TOE zostaną odpowiednio przeszkoleni
zanim zaczną pracować z TOE;

środowisko operacyjne musi ograniczać fizyczny dostęp do TOE, tzn. dopuszczać tylko personel
administracyjny oraz personel techniczny pod nadzorem personelu administracyjnego;

środowisko operacyjne zapewnia poufność dziennika zdarzeń generowanego przez TOE przed
wysłaniem go do centralnego serwera audytów.
Cele zabezpieczeń dla środowiska operacyjnego można zapisać również w postaci półformalnego generyka:
Typ generyka:
Symbol:
OEIT – Cele dotyczące aspektów programowych i sprzętowych środowiska
operacyjnego TOE (oprogramowanie i sprzęt)
OEIT.KeyOper
Podczas działania [SAU] żadna informacja o kluczach kryptograficznych nie jest
Opis:
gromadzona metodą DPA.
W przypadku, gdy środowisko operacyjne TOE jest fizycznie rozproszone, a każda z tych części ma inne
właściwości, najczęściej lepiej jest podzielić rozdział ST dotyczący celów zabezpieczeń dla środowiska
operacyjnego na kilka podrozdziałów.
86
Krótka nazwa symboliczna celu zabezpieczeń dla środowiska operacyjnego, np.: OEIT.KeyOper.
87
Opis celu zabezpieczeń dla środowiska operacyjnego.
88
W rozdziale ST dotyczącym celów zabezpieczeń znajduje się również uzasadnienie celów zabezpieczeń
zawierające:
wersja: [wersja ST]
Strona 36 z 50
[skrót nazwy TOE]

[logo konstruktora]
relacje łączące (odwzorowanie, przypisanie) cele zabezpieczeń z konkretnymi zagrożeniami,
politykami bezpieczeństwa organizacji oraz założeniami;

zbiór uzasadnień cząstkowych potwierdzający poprawność odwzorowania wszystkich zagrożeń,
polityk (OSP) i założeń na cele zabezpieczeń.
89
Takie odwzorowanie pokazuje cele zabezpieczeń wywodzące się z poszczególnych aspektów definicji
problemu bezpieczeństwa (zagrożeń, polityk bezpieczeństwa organizacji oraz założeń). Poprawne
odwzorowanie oznacza, że:
a) brak zbędnych celów, tzn. dla każdego celu zabezpieczeń należy wskazać przynajmniej
jedno zagrożenie, politykę (OSP) lub założenie (zbiór celów jest konieczny);
b) zbiór celów jest kompletny w odniesieniu do definicji problemu bezpieczeństwa, czyli każde
zagrożenie, polityka (OSP) oraz założenie zostało odwzorowane na co najmniej jeden cel
zabezpieczeń (zbiór celów jest wystarczający);
c) poprawne odwzorowanie, poniższy rysunek (relacje pomiędzy celami zabezpieczeń
a definicją problemu bezpieczeństwa) pokazuje relacje łączące dozwolone przez trzecią
cześć normy CC [CC_3]; w szczególności należy zauważyć, że założenia mogą być
odwzorowane tylko na cele zabezpieczeń dla środowiska operacyjnego.
Kilka celów zabezpieczeń może być przypisanych do jednego zagrożenia, co oznacza, że wszystkie te cele
razem przeciwstawiają się temu zagrożeniu. Podobnie jest z politykami (OSP) oraz założeniami.
Przykład poprawnego odwzorowania poszczególnych aspektów definicji problemu bezpieczeństwa na cele
zabezpieczeń pokazuje poniższy rysunek, gdzie po lewej stronie wypisane są symbole generyków zagrożeń,
polityk i założeń, a u góry symbole generyków celów zabezpieczeń dla TOE (4TOE) i dla środowiska
operacyjnego (4ENV).
wersja: [wersja ST]
Strona 37 z 50
[skrót nazwy TOE]
[logo konstruktora]
90
91
Krótka nazwa symboliczna celu zabezpieczeń dla środowiska operacyjnego, np.: OEIT.KeyOper
92
93
wersja: [wersja ST]
Strona 38 z 50
[skrót nazwy TOE]
94
[logo konstruktora]
95
Uzasadnienie celów zabezpieczeń również pokazuje, że odwzorowanie jest skuteczne, tzn. że jeżeli
wszystkie cele zabezpieczeń wskazujące na poszczególne zagrożenia, polityki (OSP) oraz założenia są
osiągnięte,
to
bezpieczeństwa
wszystkie
aspekty
definicji
został
rozwiązany).
problemu
Poprzez
bezpieczeństwa
uzasadnienie
należy
są
zrealizowane
rozumieć
(problem
przeanalizowanie
poszczególnych celów pod kątem tego, czy rzeczywiście przeciwstawiają się zagrożeniom, wymuszają
polityki bezpieczeństwa organizacji oraz podtrzymują założenia.
W niektórych przypadkach, gdy dany aspekt definicji problemu bezpieczeństwa ściśle przypomina cel
zabezpieczeń, to uzasadnienie odwzorowania jest bardzo proste, np.: zagrożenie „T17: Agent zagrożeń
X przechwytuje poufne dane podczas ich przesyłania z miejsca A do B”, a cel zabezpieczeń dla TOE „OT12:
TOE zapewnia, że wszelkie dane przesyłane z miejsca A do B są szyfrowane”, wtedy uzasadnienie brzmi
następująco „T17 jest bezpośrednio zwalczane przez OT12”.
96
Tabela, w której należy wypisać wszystkie zagrożenia i odpowiadające im cele zabezpieczeń, a następnie
podać uzasadnienie.
97
98
Tylko jeśli jakiś cel zabezpieczeń dla TOE przeciwstawia się temu zagrożeniu. Krótka nazwa symboliczna
celu zabezpieczeń dla TOE, np.: OACC.UserPrivMan.
99
Uzasadnienie odwzorowania zagrożenia. Może to być pojedyncze uzasadnienie dla każdego celu lub
zbiorcze uzasadnienie dla kilku celów zabezpieczeń. Z uzasadnienia powinno jednoznacznie wynikać, czy
dane zagrożenie zostało wyeliminowane, zmniejszone, czy też złagodzono skutki zagrożenia.
100
Tylko jeśli jakiś cel zabezpieczeń dla środowiska operacyjnego przeciwstawia się temu zagrożeniu.
101
Uzasadnienie odwzorowania zagrożenia. Może to być pojedyncze uzasadnienie dla każdego celu lub
zbiorcze uzasadnienie dla kilku celów zabezpieczeń. Z uzasadnienia powinno jednoznacznie wynikać, czy
dane zagrożenie zostało wyeliminowane, zmniejszone, czy też złagodzono skutki zagrożenia.
102
Tabela, w której należy wypisać wszystkie polityki bezpieczeństwa organizacji i odpowiadające im cele
zabezpieczeń, a następnie podać uzasadnienie.
103
104
Tylko jeśli jakiś cel zabezpieczeń dla TOE wymusza tę politykę. Krótka nazwa symboliczna celu
zabezpieczeń dla TOE, np.: OACC.UserPrivMan.
105
Uzasadnienie odwzorowania polityki. Może to być pojedyncze uzasadnienie dla każdego celu lub
zbiorcze uzasadnienie dla kilku celów zabezpieczeń.
106
Tylko jeśli jakiś cel zabezpieczeń dla środowiska operacyjnego wymusza tę politykę. Krótka nazwa
symboliczna celu zabezpieczeń dla środowiska operacyjnego, np.: OEIT.KeyOper.
107
Uzasadnienie odwzorowania polityki. Może to być pojedyncze uzasadnienie dla każdego celu lub
108
Tabela, w której należy wypisać wszystkie założenia i odpowiadające im cele zabezpieczeń dla
środowiska operacyjnego, a następnie podać uzasadnienie.
109
wersja: [wersja ST]
Strona 39 z 50
[skrót nazwy TOE]
110
111
[logo konstruktora]
Uzasadnienie odwzorowania założenia. Może to być pojedyncze uzasadnienie dla każdego celu lub
112
W wielu przypadkach wymagania bezpieczeństwa, użyte w zadaniu zabezpieczeń ST, są oparte
(identyczne lub zmienione za pomocą dozwolonych przez CC czterech operacji) na komponentach
zdefiniowanych w drugiej i trzeciej części normy CC [CC_2], [CC_3]. Jednak czasem może się zdarzyć, że
należy użyć wymagań, których nie ma w normie CC. W takim przypadku należy zdefiniować nowe
komponenty (komponenty dodatkowe).
Komponenty dodatkowe należy zdefiniować w sposób analogiczny do komponentów już istniejących w CC.
Powinny one być zrozumiałe, jednoznaczne i możliwe do ocenienia (powinno być możliwe wykazanie, że
wymaganie oparte o dodatkowy komponent może być zastosowane dla TOE). Komponenty dodatkowe
muszą być podobnie oznaczone, w podobny sposób sformułowane i na podobnym poziomie szczegółowości
w stosunku do komponentów już zawartych w normie CC.
Wszystkie zależności komponentu dodatkowego, możliwe do zastosowania, powinny być uwzględnione
w definicji tego komponentu dodatkowego. Przykładami zależności są sytuacje, w których:

komponent dodatkowy odnosi się do audytu – być może należy uwzględnić zależności od
komponentów dot. audytu bezpieczeństwa (klasa FAU);

komponent dodatkowy modyfikuje lub uzyskuje dostęp do danych – być może należy uwzględnić
zależności od komponentów z rodziny dot. polityki kontroli dostępu (FDP_ACC);

komponent dodatkowy używa specyficznego opisu projektu – być może należy uwzględnić
zależności od odpowiednich komponentów związanych z konstruowaniem TOE np. z rodziny
ADF_FSP (Specyfikacja funkcjonalności).
W przypadku dodatkowego komponentu SFR, w definicji tego komponentu, należy uwzględnić wszystkie
istotne informacje dotyczące audytu oraz informacje o stosowanych operacjach na wzór komponentów
z drugiej części CC [CC_2]. W przypadku dodatkowego komponentu uzasadniającego zaufanie, należy
zapewnić odpowiednią metodykę oceny dla komponentu, podobną do metodyki CEM [CEM].
Komponenty dodatkowe mogą być umieszczone w istniejących rodzinach, w tym przypadku należy wykazać
zmiany dokonane w rodzinach. Jeśli komponenty nie pasują do istniejących rodzin, to należy je umieścić
w nowej rodzinie. Nowe rodziny powinny być zdefiniowane na wzór rodzin CC.
Nowe rodziny mogą być umieszczane w istniejących klasach. W takim przypadku należy wykazać zmiany
dokonane w klasach. Jeśli rodziny nie pasują do istniejących klas, to należy je umieścić w nowej klasie.
Nowe klasy powinny być zdefiniowane na wzór klas CC.
113
Tylko jeśli są dodatkowe komponenty SAR. W tym podrozdziale zadania ST należy podać listę
dodatkowych komponentów SAR oraz dla każdego komponentu jego dokładny opis wzorowany na opisie
komponentu z trzeciej części normy CC [CC_3].
Jeśli dany komponent należy do dodatkowej klasy, to również tę dodatkową klasę należy opisać, wzorując
się na opisie klas z trzeciej części normy CC [CC_3].
wersja: [wersja ST]
Strona 40 z 50
[skrót nazwy TOE]
[logo konstruktora]
Jeśli dany komponent należy do dodatkowej rodziny, to również tę dodatkową rodzinę należy opisać,
wzorując się na opisie rodzin z trzeciej części normy CC [CC_3]. Nowe rodziny mogą być umieszczane
w istniejących klasach. W takim przypadku należy wykazać zmiany dokonane w klasach.
Komponenty uzasadniające zaufanie składają się z trzech rodzajów elementów:

element D (ang. developer action element) – określa, jaki artefakt, czyli dowód na spełnienie
wymagania, powinien dostarczyć konstruktor,

element C (ang. content action element) – określa, jaką postać powinien mieć i co ma zawierać ten
artefakt,

element E (ang. evaluator action element) – określa, w jaki sposób element ma być sprawdzony
przez oceniającego.
zmiany dokonane w rodzinach.
114
Tylko jeśli ST nie zawiera dodatkowych komponentów SAR.
115
Tylko jeśli są dodatkowe komponenty SFR. W tym rozdziale zadania ST należy podać listę dodatkowych
komponentów SFR oraz dla każdego komponentu jego dokładny opis razem z elementami, wzorowany na
opisie komponentu z drugiej części normy CC [CC_2].
Jeśli dany komponent należy do dodatkowej klasy, to również tę dodatkową klasę należy opisać, wzorując
się na opisie klas z drugiej części normy CC [CC_2]Błąd! Nie można odnaleźć źródła odwołania..
Jeśli dany komponent należy do dodatkowej rodziny, to również tę dodatkową rodzinę należy opisać,
wzorując się na opisie rodzin z drugiej części normy CC [CC_2]. Nowe rodziny mogą być umieszczane
w istniejących klasach. W takim przypadku należy wykazać zmiany dokonane w klasach.
zmiany dokonane w rodzinach.
116
Tylko jeśli ST nie zawiera dodatkowych komponentów SFR.
117
Wymagania bezpieczeństwa składają się z dwóch grup wymagań:
a) wymagania na funkcjonalność zabezpieczeń (SFR – Security functional requirement), czyli
wyrażenie celów zabezpieczeń dla TOE za pomocą komponentów SFR, zapisanych
w ustandaryzowanym języku (przypisanie każdemu celowi zabezpieczeń jednego lub więcej
komponentów SFR);
b) wymagania na uzasadnione zaufanie do zabezpieczeń (SAR – Security assurance
requirement), czyli opis tego, w jaki sposób osiągane jest odpowiednie uzasadnione
zaufanie (wiarygodność), gdy TOE spełnia wymagania SFR.
Dodatkowo wszystkie podmioty, zasoby, atrybuty bezpieczeństwa, zewnętrzne obiekty i inne terminy, użyte
w sformułowaniach SFR lub SAR, powinny zostać zdefiniowane w słowniku pojęć na końcu dokumentu lub
w definicji problemu bezpieczeństwa (podmioty i zasoby).
118
W tym miejscu należy również opisać przyjętą konwencję, dotyczącą sposobu zapisu poszczególnych
operacji. Najczęściej stosuje się:

dla operacji przypisania: [tekst w nawiasach kwadratowych zapisany kursywą];

dla operacji wyboru: [tekst w nawiasach kwadratowych zapisany podkreśloną kursywą];
wersja: [wersja ST]
Strona 41 z 50
[skrót nazwy TOE]

[logo konstruktora]
dla operacji uszczegółowienia: tekst pogrubiony; jeśli jakiś fragment został usunięty, to stosuje się
przekreślenie;

dla operacji iteracji: za nazwą komponentu dodaje się w nawiasach zwykłych numer iteracji np.
FAU_GEN.1(5).
119
Norma CC wymaga wyrażenia na bardzo szczegółowym poziomie abstrakcji celów zabezpieczeń dla
TOE zapisanych w języku naturalnym (lub półformalnym w postaci generyków) za pomocą komponentów
SFR, zapisanych w ustandaryzowanym języku. Takie wyrażenie będzie w dalszej części opracowania zwane
odwzorowaniem celów zabezpieczeń (dla TOE) na komponenty SFR. Musi to być jednak pełne
odwzorowanie (wszystkie cele zabezpieczeń dla TOE muszą być odwzorowane na wymagania SFR) oraz
niezależne od konkretnego rozwiązania technicznego (implementacji). Norma CC wymaga takiego
odwzorowania na komponenty zapisane w ustandaryzowanym języku z kilku powodów:

dostarczenie dokładnego opisu tego co jest oceniane; cele zabezpieczeń dla TOE są zwykle
formułowane w języku naturalnym, natomiast zapisanie ich w postaci ustandaryzowanego języka
wymusza dokładniejszy opis funkcjonalności TOE;

możliwość porównywania ST między sobą; różni autorzy ST mogą używać różnej terminologii do
przedstawienia swoich celów zabezpieczeń, ustandaryzowany język wymusza natomiast użycia tej
samej terminologii i koncepcji, co pozwala na łatwe porównywanie poszczególnych zadań
zabezpieczeń.
Norma CC nie wymaga odwzorowania celów zabezpieczeń dla środowiska operacyjnego, ponieważ to nie
środowisko operacyjne jest oceniane.
Czasem może się zdarzyć, że część środowiska operacyjnego jest oceniana osobno, np. gdy przedmiotem
oceny jest system operacyjny, który wymaga w swoim środowisku operacyjnym zapory sieciowej. Ocena
takiej zapory sieciowej może być wykonywana niezależnie, wtedy przedmiotem oceny będzie tylko ta
zapora.
Norma Common Criteria wspomaga odwzorowanie celów zabezpieczeń na trzy sposoby:
a) poprzez predefiniowany, precyzyjny „język” stworzony po to, aby dokładnie opisać to co jest
oceniane; język ten jest zdefiniowany jako zestaw komponentów określonych w drugiej
części normy CC [CC_2]; korzystanie z tego języka, jako z dobrze zdefiniowanego
odwzorowania celów zabezpieczeń dla TOE na wymagania SFR jest obowiązkowe;
wyjątkiem są tylko komponenty dodatkowe (ASE_ECD);
b) poprzez operacje; są to mechanizmy, które pozwalają twórcom ST modyfikować wymagania
SFR, aby zapewnić bardziej precyzyjne odwzorowanie celów zabezpieczeń dla TOE; norma
CC definiuje cztery operacje: przypisanie, wybór, iteracja oraz uszczegółowienie; więcej
o operacjach w rozdziale 8.1 pierwszej części normy CC [CC_1];
c) poprzez zależności; mechanizm ten wspomaga kompletne odwzorowanie na wymagania
SFR; druga część normy CC [CC_2] opisuje zależności komponentów SFR od innych
komponentów SFR, oznacza to, że jeśli w ST użyto określony komponent SFR, na ogół
należy również użyć komponent SFR, od którego ten pierwszy jest zależny; mechanizm
zależności utrudnia celowe lub omyłkowe pominięcie niezbędnych komponentów SFR, a tym
wersja: [wersja ST]
Strona 42 z 50
[skrót nazwy TOE]
[logo konstruktora]
samym poprawia kompletność ST; więcej o zależnościach w rozdziale 8.2 pierwszej części
normy CC [CC_1].
120
Symbol komponentu SFR np. FAU_ARP.1. Przy operacji iteracji każda kolejna wersja komponentu
powinna być zapisana zgodnie z wcześniej przyjętą konwencją dotyczącą operacji, np.: FAU_ARP.1(1),
FAU_ARP.1(2) itd.
121
Krótki opis komponentu SFR z normy, np. dla FAU_ARP.1 jest to „Security audit data generation”
w wersji oryginalnej lub „Generowanie danych audytu bezpieczeństwa” wg tłumaczenia realizatorów projektu
CCMODE. Należy zauważyć, że PKN nie przetłumaczył nowej wersji normy CC.
122
Symbol elementu SFR np. FAU_ARP.1.1. Przy operacji iteracji komponentów symbol elementu również
powinien być zmieniony, np. dla komponentu FAU_ARP.1(2) symbolem elementu będzie FAU_ARP.1.1(2).
123
Opis elementu SFR z normy, czyli treść wymagania w wersji oryginalnej lub wg tłumaczenia realizatorów
projektu CCMODE. Należy zauważyć, że PKN nie przetłumaczył nowej wersji normy CC. Treść elementu
SFR powinna być zapisana zgodnie z wcześniej przyjętą konwencją dotyczącą operacji. Przykładowo dla
FAU_GEN.1.1 „TSF powinna zapewnić stosowanie następujących reguł dla monitoringu funkcjonowania
audytowanych zdarzeń
a) sumę lub kombinacje [przypisanie: podzbiór zdefiniowanych audytowanych zdarzeń] wymaganych aby
wykryć potencjalne naruszenie bezpieczeństwa;
b) [iloczyn sygnałów z czujników pozycjonowania].”
124
W tym rozdziale ST należy wymienić listę wybranych komponentów SAR, czyli wymagań na uzasadnione
zaufanie do zabezpieczeń. Najczęściej jest to lista komponentów wchodzących w skład zadeklarowanego
pakietu EAL (ewentualnie komponenty wzbogacające dany pakiet EAL).
125
Symbol klasy SAR np. ALC.
126
Krótki opis klasy SAR z normy, np. dla ALC jest to „Life-cycle support” w wersji oryginalnej lub „Wsparcie
cyklu życia” wg tłumaczenia realizatorów projektu CCMODE. Należy zauważyć, że PKN nie przetłumaczył
nowej wersji normy CC.
127
128
Symbol komponentu SAR np. ALC_CMC.1.
Krótki opis komponentu SAR z normy, np. dla ALC_CMC.1 jest to „Labelling of the TOE” w wersji
oryginalnej lub „Etykietowanie TOE” wg tłumaczenia realizatorów projektu CCMODE. Należy zauważyć, że
PKN nie przetłumaczył nowej wersji normy CC.
129
Takie odwzorowanie pokazuje komponenty SFR wywodzące się z poszczególnych celów zabezpieczeń
dla TOE. Oznacza to, że:

brak jest zbędnych komponentów SFR, tzn. każdy komponent SFR musi odwzorować przynajmniej
jeden cel zabezpieczeń dla TOE;

odwzorowanie jest kompletne w odniesieniu do celów zabezpieczeń dla TOE, czyli każdy cel
zabezpieczeń dla TOE został odwzorowany na co najmniej jeden komponent SFR.
Pokazuje to, że zbiór komponentów SFR jest konieczny i wystarczający w odniesieniu do celów
zabezpieczeń dla TOE.
Wiele komponentów SFR może odwzorować jeden cel zabezpieczeń dla TOE, co oznacza, że wszystkie te
komponenty razem pokrywają ten cel zabezpieczeń.
wersja: [wersja ST]
Strona 43 z 50
[skrót nazwy TOE]
[logo konstruktora]
Przykład poprawnego odwzorowania poszczególnych celów zabezpieczeń dla TOE na komponenty SFR
pokazuje rysunek poniżejBłąd! Nie można odnaleźć źródła odwołania., gdzie po lewej stronie w pionie
wypisane są symbole generyków celów zabezpieczeń dla TOE, a u góry symbole komponentów SFR.
130
FAU_ARP.1(2) itd.
131
132
Uzasadnienie wymagań bezpieczeństwa pokazuje, że odwzorowanie jest skuteczne, tzn. że jeżeli
wszystkie wymagania SFR, wskazujące na poszczególne cele zabezpieczeń dla TOE, są spełnione, to
wszystkie
cele
zabezpieczeń
dla
TOE
są
osiągnięte.
Poprzez
uzasadnienie
należy
rozumieć
przeanalizowanie rezultatów spełnienia poszczególnych wymagań SFR pod kątem tego, czy cele
zabezpieczeń dla TOE są rzeczywiście osiągnięte.
W niektórych przypadkach, gdy dany komponent ściśle przypomina cel zabezpieczeń dla TOE, to
uzasadnienie odwzorowania jest bardzo proste i wynika wprost z danego komponentu.
133
134
Symbol komponentu SFR, np. FAU_ARP.1. Przy operacji iteracji każda kolejna wersja komponentu
FAU_ARP.1(2) itd.
135
Uzasadnienie odwzorowania celu zabezpieczeń dla TOE. Może to być pojedyncze uzasadnienie dla
każdego komponentu SFR osobno lub zbiorcze uzasadnienie dla kilku komponentów SFR.
136
Dla każdego z komponentów SFR oraz SAR posiadających zależności należy określić, czy dana
zależność została spełniona (komponent zależny został dodany do listy komponentów). Jeśli komponent
zależny nie został włączony do ST, to należy uzasadnić dlaczego. Przykładem uzasadnienia może być tekst:
„Użyto komponentu ALC_CMC.4 hierarchicznie wyższego niż wymagany ALC_CMC.3”.
137
Symbol komponentu SAR np. ALC_CMC.1.
138
Symbol zależnego komponentu SAR np. dla ALC_CMC.3 komponentem zależnym jest ALC_DVS.1.
139
Tylko jeśli zależność jest spełniona.
wersja: [wersja ST]
Strona 44 z 50
[skrót nazwy TOE]
140
[logo konstruktora]
Tylko jeśli zależność nie jest spełniona. Należy wyjaśnić dlaczego zależność nie została spełniona.
Przykładem uzasadnienia może być tekst: „Użyto komponentu ALC_CMC.4 hierarchicznie wyższego niż
wymagany ALC_CMC.3”.
141
FAU_ARP.1(2) itd.
142
Symbol zależnego komponentu SFR np. dla FAU_GEN.2 komponentem zależnym jest FIA_UID.1.
143
Tylko jeśli zależność jest spełniona.
144
Tylko jeśli zależność nie jest spełniona. Należy wyjaśnić dlaczego zależność nie została spełniona.
Przykładem uzasadnienia może być tekst: „Użyto komponentu FIA_UID.2 hierarchicznie wyższego niż
wymagany FIA_UID.1”.
145
Zadanie zabezpieczeń ST zawiera również uzasadnienie wymagań bezpieczeństwa, które wyjaśnia,
dlaczego określony zbiór komponentów SAR został wybrany.
Przykładem niewłaściwego wyboru zestawu komponentów SAR jest sytuacja, gdy w opisie problemu
bezpieczeństwa umieszczono zagrożenie z agentem posiadającym dużą wiedzę i możliwości, a do listy
komponentów SAR dodano hierarchicznie niski komponent dotyczący analizy podatności (AVA_VAN), albo
nie wybrano go wcale.
146
Celem specyfikacji końcowej TOE jest dostarczenie potencjalnemu klientowi TOE opisu sposobu, w jaki
TOE spełnia wszystkie wymagania SFR. Podrozdział ten opisuje mechanizmy techniczne użyte w TOE w
celu jego ochrony. Poziom szczegółowości tego opisu powinien być na tyle dokładny, aby umożliwić
potencjalnym klientom zrozumienie ogólnej formy oraz implementacji TOE. Dla przykładu, jeśli przedmiotem
oceny jest komputer PC podłączony do Internetu, a na liście wymagań SFR znajduje się komponent
FIA_UAU.1 dotyczący uwierzytelniania, to w specyfikacji końcowej TOE należy wskazać jak to
uwierzytelnianie jest zrealizowane: hasło, token, skanowanie tęczówki, itd. Dodatkowe informacje, takie jak
stosowanie konkretnych norm potrzebnych do spełnienia wymagań SFR lub bardziej szczegółowe opisy
również mogą być dostarczone.
147
W tym podrozdziale zadania zabezpieczeń należy pokazać, że wszystkie wymagania SFR (również te
zależne, które nie zostały odrzucone) są odwzorowane (spełnione) na konkretne funkcje zabezpieczające
(TSF). Najczęściej jest tak, że kilka komponentów SFR jest odwzorowanych na jedną funkcję TSF.
148
149
Krótka nazwa symboliczna funkcji zabezpieczającej, np. SFAU.AuditFacilities.
FAU_ARP.1(2) itd.
150
Każdą funkcję zabezpieczającą należy w tym podrozdziale dokładnie opisać. Wielkość takiego opisu to
zazwyczaj od kilku akapitów do kilku stron.
151
Tylko dla komponentu ASE_TSS.2. W przypadku, gdy komponent ASE_TSS.1 jest zamieniony na
hierarchicznie
wyższy
ASE_TSS.2,
należy
specyfikację
końcową
uzupełnić
o
opis
architektury
zabezpieczeń. Komponent ASE_TSS.2 jest wzbogaceniem każdego z poziomów EAL.
wersja: [wersja ST]
Strona 45 z 50
[skrót nazwy TOE]
152
[logo konstruktora]
Tylko dla komponentu ASE_TSS.2. W niniejszym podrozdziale należy opisać jak TOE chroni się przed
zakłóceniami, manipulacjami logicznymi oraz przed obejściem zabezpieczeń.
153
Należy zauważyć, że obok symbolu wymagania znajduje się przypis końcowy z treścią oryginalną
wymagania oraz z polskim tłumaczeniem wykonanym przez realizatorów projektu CCMODE.
154
The ST introduction shall contain an ST reference, a TOE reference, a TOE overview and a TOE
description.
Wprowadzenie powinno zawierać metryczkę/adnotację dokumentu ST oraz metryczkę, przegląd ogólny
i opis przedmiotu oceny TOE.
155
The ST reference shall uniquely identify the ST.
Metryczka ST musi jednoznacznie identyfikować zadanie zabezpieczeń.
156
The TOE reference shall identify the TOE.
Metryczka TOE powinna identyfikować przedmiot oceny – TOE, którego dotyczy dokument ST.
157
The TOE overview shall summarise the usage and major security features of the TOE.
W przeglądzie ogólnym TOE powinny zostać umieszczone dane kierowane do potencjalnych odbiorców
końcowych TOE. Tak więc powinien zostać opisany sposób użycia lub użytkowania i główne cechy
bezpieczeństwa TOE.
158
The TOE overview shall identify the TOE type.
W przeglądzie ogólnym TOE powinien zostać podany typ TOE, na przykład system operacyjny, baza
danych, smart card, firewall, itp.
159
The TOE overview shall identify any non-TOE hardware/ software/ firmware required by the TOE.
Przegląd ogólny powinien identyfikować wszystkie wymagane przez TOE, ale spoza TOE, elementy
sprzętowe, programowe oraz oprogramowanie firmowe i inne.
160
The TOE description shall describe the physical scope of the TOE.
Opis TOE powinien określić fizyczne granice TOE, podając listę jego części sprzętowych, programowych,
oprogramowania firmowego oraz podręczników.
161
The TOE description shall describe the logical scope of the TOE.
Opis TOE powinien zawierać logiczne granice TOE.
162
The conformance claim shall contain a CC conformance claim that identifies the version of the CC to
which the ST and the TOE claim conformance.
Deklaracja zgodności powinna zawierać deklarację zgodności ST i samego TOE z konkretną wersją normy
CC.
163
The CC conformance claim shall describe the conformance of the ST to CC Part 2 as either CC
Part 2 conformant or CC Part 2 extended.
Deklaracja zgodności powinna precyzować zgodność dokumentu ST z CC Part2 pełną/zgodną lub
rozszerzoną (jeśli użyto dodatkowych komponentów spoza katalogu CC).
164
The CC conformance claim shall describe the conformance of the ST to CC Part 3 as either CC Part 3
conformant or CC Part 3 extended.
Deklaracja zgodności powinna precyzować zgodność dokumentu ST z CC Part3 pełną/zgodną lub
rozszerzoną (jeśli użyto dodatkowych komponentów spoza katalogu CC).
wersja: [wersja ST]
Strona 46 z 50
[skrót nazwy TOE]
165
[logo konstruktora]
The CC conformance claim shall be consistent with the extended components definition.
Deklaracja zgodności powinna być spójna z definicją komponentów rozszerzających CC.
166
The conformance claim shall identify all PPs and security requirement packages to which the ST claims
conformance.
Deklaracja zgodności powinna identyfikować wszystkie profile PP i pakiety wymagań bezpieczeństwa,
z którymi ST deklaruje zgodność.
167
The conformance claim shall describe any conformance of the ST to a package as either package-
conformant or package-augmented.
Deklaracja zgodności powinna precyzyjnie podawać czy zgodność z pakietami jest pełna czy wzbogacona
o nowe aspekty bezpieczeństwa.
168
The conformance claim rationale shall demonstrate that the TOE type is consistent with the TOE type in
the PPs for which conformance is being claimed.
Uzasadnienie deklaracji zgodności powinno wykazać, że typ TOE jest zgodny z typem TOE opisanym
w profilu zabezpieczeń PP, z którym ST deklaruje zgodność.
169
The conformance claim rationale shall demonstrate that the statement of the security problem definition is
consistent with the statement of the security problem definition in the PPs for which conformance is being
claimed.
Uzasadnienie deklaracji zgodności powinno wykazać, że definicja problemu bezpieczeństwa – SPD
w zadaniu zabezpieczeń ST jest zgodna z SPD występującym w dokumencie profilu zabezpieczeń PP,
z którym ST deklarowało zgodność.
170
The conformance claim rationale shall demonstrate that the statement of security objectives is consistent
with the statement of security objectives in the PPs for which conformance is being claimed.
Uzasadnienie deklaracji zgodności powinno wykazać, że deklaracja celów zabezpieczeń występująca
w zadaniu zabezpieczeń ST jest zgodna z odpowiadającą jej deklaracją występującą w dokumencie profilu
zabezpieczeń PP, z którym ST deklarowało zgodność.
171
The conformance claim rationale shall demonstrate that the statement of security requirements is
consistent with the statement of security requirements in the PPs for which conformance is being claimed.
Uzasadnienie deklaracji zgodności powinno wykazać, że deklaracja wymagań bezpieczeństwa występująca
w zadaniu zabezpieczeń ST jest zgodna z deklaracją występującą w dokumencie profilu zabezpieczeń PP,
z którym ST deklarowało zgodność.
172
The security problem definition shall describe the threats.
Definicja problemu bezpieczeństwa powinna obejmować zagrożenia.
173
All threats shall be described in terms of a threat agent, an asset, and an adverse action.
Zagrożenia powinny być opisane z użyciem terminologii agent zagrożenia, atakowany zasób i działanie
niepożądane.
174
The security problem definition shall describe the OSPs.
Definicja problemu bezpieczeństwa powinna obejmować polityki bezpieczeństwa organizacji.
175
The security problem definition shall describe the assumptions about the operational environment of the
TOE.
wersja: [wersja ST]
Strona 47 z 50
[skrót nazwy TOE]
[logo konstruktora]
Definicja problemu bezpieczeństwa powinna obejmować założenia dotyczące środowiska operacyjnego
TOE.
176
The statement of security objectives shall describe the security objectives for the TOE and the security
objectives for the operational environment.
Deklaracja celów zabezpieczeń powinna zawierać cele zabezpieczeń dla TOE i dla środowiska
operacyjnego.
177
The security objectives rationale shall trace each security objective for the TOE back to threats countered
by that security objective and OSPs enforced by that security objective.
Uzasadnienie każdego celu zabezpieczeń dla TOE powinno wskazać zagrożenia, którym się (ten cel)
przeciwstawia oraz polityki, które są egzekwowane przez niego.
178
The security objectives rationale shall trace each security objective for the operational environment back
to threats countered by that security objective, OSPs enforced by that security objective, and assumptions
upheld by that security objective.
Uzasadnienie każdego celu zabezpieczeń dla środowiska operacyjnego TOE powinno wskazać zagrożenia,
którym się (ten cel) przeciwstawia, polityki, które są egzekwowane przez niego i założenia, które
podtrzymuje (utrzymuje w mocy, wspiera).
179
The security objectives rationale shall demonstrate that the security objectives counter all threats.
Uzasadnienie celów zabezpieczeń powinno wykazać, że postawione cele przeciwstawiają się wszystkim
zagrożeniom.
180
The security objectives rationale shall demonstrate that the security objectives enforce all OSPs.
Uzasadnienie celów zabezpieczeń powinno wykazać, że postawione cele egzekwują wykonanie wszystkich
zidentyfikowanych polityk.
181
The security objectives rationale shall demonstrate that the security objectives for the operational
environment uphold all assumptions.
Uzasadnienie celów zabezpieczeń powinno wykazać, że postawione cele zabezpieczeń dla środowiska
operacyjnego podtrzymują wszystkie zidentyfikowane założenia.
182
The statement of security requirements shall identify all extended security requirements.
Deklaracja
wymagań
bezpieczeństwa
powinna
identyfikować
wszystkie
dodatkowo
zdefiniowane
wymagania.
183
The extended components definition shall define an extended component for each extended security
requirement.
Każde dodatkowe wymaganie bezpieczeństwa powinno posiadać odpowiadający mu dodatkowo
zdefiniowany komponent
184
The extended components definition shall describe how each extended component is related to the
existing CC components, families, and classes.
Definicje komponentów dodatkowych powinny opisywać powiązania nowego komponentu z istniejącymi
w CC komponentami, rodzinami i klasami.
185
The extended components definition shall use the existing CC components, families, classes, and
methodology as a model for presentation.
wersja: [wersja ST]
Strona 48 z 50
[skrót nazwy TOE]
[logo konstruktora]
Definicje komponentów dodatkowych powinny używać modelu prezentacji stosowanego dla komponentów
w normie CC (klasa, rodzina i komponent)
186
The extended components shall consist of measurable and objective elements such that conformance or
nonconformance to these elements can be demonstrated.
Komponenty dodatkowe powinny się składać z elementów wymiernych i obiektywnych, takich, że zgodność
lub niezgodność do tych elementów może być wykazana.
187
The statement of security requirements shall describe the SFRs and the SARs.
Deklaracja wymagań bezpieczeństwa powinna zawierać wymagania funkcjonalne – SFR i wymagania
uzasadniające zaufanie – SAR.
188
All subjects, objects, operations, security attributes, external entities and other terms that are used in the
SFRs and the SARs shall be defined.
Wszystkie podmioty, cele, operacje, atrybuty bezpieczeństwa, zewnętrzne obiekty i inne terminy, użyte
w sformułowaniach SFR lub SAR, powinny zostać zdefiniowane.
189
The statement of security requirements shall identify all operations on the security requirements.
Deklaracja wymagań bezpieczeństwa powinna identyfikować wszystkie operacje na wymaganiach
bezpieczeństwa.
Operacje te, to:
190

uszczegółowienie – refinement – dla komponentu,

iteracja – iteration – dla komponentu,

przypisanie – assignment – dla elementu SFR,

wybór – selection – dla elementu.
All operations shall be performed correctly.
Wszystkie operacje powinny być wykonane poprawnie.
191
Each dependency of the security requirements shall either be satisfied, or the security requirements
rationale shall justify the dependency not being satisfied.
Każda zależność, podana w normie CC dla zadeklarowanych wymagań, musi zostać przeanalizowana i albo
dany komponent jest włączany do zadania zabezpieczeń, albo w ST należy uzasadnić dlaczego zależność
ta nie jest spełniona.
192
The security requirements rationale shall trace each SFR back to the security objectives for the TOE.
Dla każdego wymagania SFR należy wskazać cele zabezpieczeń, które to wymaganie pokrywa.
193
The security requirements rationale shall demonstrate that the SFRs meet all security objectives for the
TOE.
Uzasadnienie wymagań bezpieczeństwa powinno wykazać, że wymagania SFR pokrywają wszystkie
zidentyfikowane cele zabezpieczeń dla TOE.
194
The security requirements rationale shall explain why the SARs were chosen.
Uzasadnienie wymagań bezpieczeństwa powinno wyjaśnić, dlaczego wymagania SAR zostały wybrane.
195
The statement of security requirements shall be internally consistent.
Deklaracja wymagań bezpieczeństwa powinna być wewnętrznie spójna.
196
The TOE summary specification shall describe how the TOE meets each SFR.
wersja: [wersja ST]
Strona 49 z 50
[skrót nazwy TOE]
[logo konstruktora]
Specyfikacja końcowa powinna opisywać jak TOE spełnia wymagania SFR.
197
Tylko jeśli poziom EAL jest wzbogacony o komponent ASE_TSS.2. W tym przypadku należy usunąć
wymaganie ASE_TSS.1.1C.
198
The TOE summary specification shall describe how the TOE meets each SFR.
Specyfikacja końcowa powinna opisywać jak TOE spełnia wymagania SFR.
199
200
The TOE summary specification shall describe how the TOE protects itself against interference and
logical tampering.
Specyfikacja końcowa powinna opisywać jak TOE chroni się przed zakłóceniami i manipulacjami logicznymi.
201
202
The TOE summary specification shall describe how the TOE protects itself against bypass.
Specyfikacja końcowa powinna opisywać jak TOE chroni się przed obejściami zabezpieczeń.
203
Rozdział powinien zawierać listę załączników powiązanych z dokumentem lub tych, które są istotne dla
pełnego zrozumienia dokumentu.
204
Niniejsza lista objaśnia skróty użyte w dokumentacji.
205
Pozostałe skróty używane w dokumencie.
206
Rozwinięcie skrótu.
207
Polskie tłumaczenie skrótu.
208
Wykaz pojęć użytych w dokumencie. Należy zauważyć, że nie wymaga się objaśniania terminów
zawartych w oficjalnym słowniku pojęć CC (rozdział 4 [CC_1]). Słownik pojęć najlepiej opracować w formie
tabeli, np.:
Termin
Objaśnienie
Jednostka
Podmiot gospodarczy prowadzący przedsiębiorstwo, który stanowi równocześnie
badawczo-rozwojowa
szczególny typ placówki naukowej, specjalizujący się we wdrażaniu nowych
technologii i ulepszaniu ich.
209
W tym miejscu należy wymienić pozostałe dokumenty do których odnosi się ten dokument. Przykład:
[CC_1] Common Criteria, Part 1: Common Criteria for Information Technology Security Evaluation, Part 1:
Introduction and General Model, Version 3.1, July 2009.
210
Krótka symboliczna nazwa dokumentu.
211
Lista autorów dokumentu sformatowana jako: nazwisko, pierwsza litera imienia lub imion, kropka. Pole
jest opcjonalne.
212
Nazwa przywoływanego dokumentu.
213
Wydawca dokumentu.
214
Data wydania dokumentu.
wersja: [wersja ST]
Strona 50 z 50

Szablon materiału dowodowego

Transkrypt

Podobne dokumenty

Formularz zgłoszeniowy seminarium "Standard umowy EFET

Projektowanie zabezpieczeń informatycznych na przykładzie

Formularz asortymentowo-cenowy.

Bogactwo technologii na ma³ej powierzchni

Deklaracja członkowska w formacie PDF