[skrót organizacji konstruktora] 1 [nazwa TOE] 2 [wersja TOE] 3. Zadanie zabezpieczeń

Transkrypt

1 Wstęp Dokument zawiera szablon materiału dowodowego wraz z komentarzem. Zamieszczony szablon zawiera wiele informacji, które nie będą 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.

2 [skrót organizacji konstruktora] 1 [nazwa TOE] 2 [wersja TOE] 3 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] Opracowane dla: Opracowane przez: [logo sponsora ST] [logo autorów ST] [organizacja sponsora ST] 14 [organizacja autorów ST] 15

3 (strona celowo pozostawiona pusta)

4 SPIS TREŚCI 1. Wprowadzenie do ST (ASE_INT) Metryczka ST Metryczka TOE Przegląd TOE Sposób użycia i główne cechy bezpieczeństwa TOE Typ TOE Wymagany sprzęt i oprogramowanie nie należące do TOE Opis TOE Składniki fizyczne i zakres fizyczny TOE Składniki logiczne i zakres logiczny TOE Deklaracje zgodności (ASE_CCL) Deklaracja zgodności z CC Deklaracja zgodności z PP Deklaracja zgodności z pakietami Uzasadnienie zgodności Definicja problemu bezpieczeństwa (ASE_SPD) Zasoby Podmioty Zagrożenia Polityki bezpieczeństwa organizacji Założenia Cele zabezpieczeń (ASE_OBJ) Cele zabezpieczeń dla TOE Cele zabezpieczeń dla środowiska operacyjnego Uzasadnienie celów zabezpieczeń...15 wersja: [wersja ST] Data: [data wydania ST] Strona 4 z 50

5 4.3.1 Odwzorowanie poszczególnych aspektów definicji problemu bezpieczeństwa na cele zabezpieczeń Uzasadnienia dla odwzorowania Definicja komponentów dodatkowych (ASE_ECD) Definicja dodatkowych komponentów SAR Definicja dodatkowych komponentów SFR Wymagania bezpieczeństwa (ASE_REQ) Wymagania na funkcjonalność zabezpieczeń Wymagania na uzasadnione zaufanie do zabezpieczeń Uzasadnienie wymagań bezpieczeństwa Odwzorowanie celów zabezpieczeń na komponenty SFR Uzasadnienia dla odwzorowania Uzasadnienie dla zależności Uzasadnienie zestawu komponentów SAR Specyfikacja końcowa TOE (ASE_TSS) Odwzorowanie komponentów SFR na funkcje zabezpieczające TOE Opis funkcji zabezpieczających TOE Architektura zabezpieczeń TOE Podsumowanie materiału dowodowego Załącznik Wykaz skrótów Słownik pojęć Bibliografia SPIS RYSUNKÓW 16 wersja: [wersja ST] Data: [data wydania ST] Strona 5 z 50

6 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] Data: [data wydania ST] Strona 6 z 50

7 Historia zmian w dokumencie 17 Wersja ST Autor Data Opis zmiany [nr wersji ST] [autor zmiany] [data zmiany] [opis zmiany] wersja: [wersja ST] Data: [data wydania ST] Strona 7 z 50

8 1. Wprowadzenie do ST (ASE_INT) 18 Dokument zadania zabezpieczeń (ST Security Target) opisuje cechy bezpieczeństwa dla produktu [nazwa TOE] 19 [wersja TOE] 20 ([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] Data: [data wydania ST] Strona 8 z 50

9 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ń Wersja ST [wersja ST] 26 Data wydania ST [data wydania ST] 27 Język dokumentu polski Nazwa pliku [skrót nazwy TOE] 28 _SecurityTarget_pl_[wersja ST] 29. [rozszerzenie pliku] 30 Autorzy ST [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] Data: [data wydania ST] Strona 9 z 50

10 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] 45 Konstruktor TOE [organizacja konstruktora] 46 Adres: [adres konstruktora] 47 Telefon: [tel. konstruktora] 48 Strona www: [strona www konstruktora] Przegląd TOE Sposób użycia i główne cechy bezpieczeństwa TOE [sposób użycia i główne cechy bezpieczeństwa TOE] Typ TOE [typ TOE] Wymagany sprzęt i oprogramowanie nie należące do TOE [wymagany sprzęt i oprogramowanie nie należące do TOE] Opis TOE Składniki fizyczne i zakres fizyczny TOE [składniki fizyczne i zakres fizyczny TOE] Składniki logiczne i zakres logiczny TOE [składniki logiczne i zakres logiczny TOE] 56 wersja: [wersja ST] Data: [data wydania ST] Strona 10 z 50

11 2. Deklaracje zgodności (ASE_CCL) Deklaracja zgodności z CC [deklaracja zgodności z CC] Deklaracja zgodności z PP [deklaracja zgodności z PP] (ST) nie deklaruje zgodności z jakimkolwiek profilem zabezpieczeń (PP). 2.3 Deklaracja zgodności z pakietami [deklaracja zgodności z pakietami] (ST) nie deklaruje zgodności z jakimkolwiek pakietem wymagań bezpieczeństwa. 2.4 Uzasadnienie zgodności [uzasadnienie zgodności z PP] Zadania zabezpieczeń (ST) nie deklaruje zgodności z jakimkolwiek profilem zabezpieczeń (PP), a zatem nie jest wymagane uzasadnienie tej zgodności. wersja: [wersja ST] Data: [data wydania ST] Strona 11 z 50

12 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 Zasoby 66 Tabela 3. Zasoby Symbol [symbol zasobu] 67 [opis zasobu] 68 Opis 3.2 Podmioty 69 Tabela 4. Podmioty Symbol [symbol podmiotu] 70 [opis podmiotu] 71 Opis 3.3 Zagrożenia 72 Tabela 5. Zagrożenia Symbol [symbol zagrożenia] 73 [opis zagrożenia] 74 Opis 3.4 Polityki bezpieczeństwa organizacji 75 Tabela 6. Polityki bezpieczeństwa organizacji Symbol [symbol polityki] 76 [opis polityki] 77 Opis wersja: [wersja ST] Data: [data wydania ST] Strona 12 z 50

13 3.5 Założenia 78 Tabela 7. Założenia Symbol [symbol założenia] 79 [opis założenia] 80 Opis wersja: [wersja ST] Data: [data wydania ST] Strona 13 z 50

14 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 TOE 82 Tabela 8. Cele zabezpieczeń dla TOE Symbol Opis [symbol celu 4TOE] 83 [opis celu zabezpieczeń dla TOE] Cele zabezpieczeń dla środowiska operacyjnego 85 Tabela 9. Cele zabezpieczeń dla środowiska operacyjnego Symbol Opis [symbol celu 4ENV] 86 [opis celu zabezpieczeń dla środowiska operacyjnego] 87 wersja: [wersja ST] Data: [data wydania ST] Strona 14 z 50

15 Cele zabezpieczeń 4TOE:[ symbol celu 4TOE] 90 4ENV:[ symbol celu 4ENV] 91 [skrót nazwy TOE] 4.3 Uzasadnienie celów zabezpieczeń Odwzorowanie poszczególnych aspektów definicji problemu bezpieczeństwa na cele zabezpieczeń Tabela 10. Odwzorowanie SPD na cele zabezpieczeń 89 Zagrożenie [symbol zagrożenia] 92 Polityka bezpieczeństwa [symbol polityki] 93 Założenie [symbol założenia] Uzasadnienia dla odwzorowania 95 Tabela 11. Odwzorowanie zagrożeń uzasadnienie 96 Zagrożenie Cel zabezpieczeń Uzasadnienie [symbol zagrożenia] 97 4TOE: [symbol celu 4TOE] 98 [uzasadnienie odwzorowania zagrożenia] 99 4ENV: [symbol celu 4ENV] 100 [uzasadnienie odwzorowania zagrożenia] 101 wersja: [wersja ST] Data: [data wydania ST] Strona 15 z 50

16 Tabela 12. Odwzorowanie polityk bezpieczeństwa organizacji uzasadnienie 102 Polityka Cel zabezpieczeń Uzasadnienie [symbol polityki] 103 4TOE: [symbol celu 4TOE] 104 [uzasadnienie odwzorowania polityki] 105 4ENV: [symbol celu 4ENV] 106 [uzasadnienie odwzorowania polityki] 107 Tabela 13. Odwzorowanie założeń uzasadnienie 108 Założenie Cel zabezpieczeń Uzasadnienie [symbol założenia] 109 4ENV: [symbol celu 4ENV] 110 [uzasadnienie odwzorowania założenia] 111 wersja: [wersja ST] Data: [data wydania ST] Strona 16 z 50

17 5. Definicja komponentów dodatkowych (ASE_ECD) 112 Ten rozdział zadania zabezpieczeń (ST) zawiera definicje komponentów dodatkowych, tzn. komponentów SAR i SFR 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] Nie zdefiniowano dodatkowych komponentów SAR. 5.2 Definicja dodatkowych komponentów SFR [definicja dodatkowych komponentów SFR] Nie zdefiniowano dodatkowych komponentów SFR. wersja: [wersja ST] Data: [data wydania ST] Strona 17 z 50

18 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] Wymagania na funkcjonalność zabezpieczeń 119 Tabela 14. Komponenty SFR Komponent SFR Element SFR Opis elementu SFR [symbol komponentu SFR] 120 [opis komponentu SFR] 121 [symbol elementu SFR] 122 [opis elementu SFR] Wymagania na uzasadnione zaufanie do zabezpieczeń 124 Tabela 15. Komponenty SAR Klasa SAR Komponent SAR Opis komponentu SAR [symbol klasy SAR] : 125 [opis klasy SAR] 126 [symbol komponentu SAR] 127 [opis komponentu SAR] Uzasadnienie wymagań bezpieczeństwa Niniejszy podrozdział zadania zabezpieczeń zawiera tabele przedstawiające odwzorowanie celów zabezpieczeń na komponenty SFR, uzasadnienie tego odwzorowania, uzasadnienie dla zależności oraz uzasadnienie wyboru zestawu komponentów SAR. wersja: [wersja ST] Data: [data wydania ST] Strona 18 z 50

19 Komponent SFR [skrót nazwy TOE] Odwzorowanie celów zabezpieczeń na komponenty SFR 129 Tabela 16. Odwzorowanie celów zabezpieczeń na komponenty SFR Cel zabezpieczeń dla TOE [symbol celu 4TOE] 131 [symbol komponentu SFR] Uzasadnienia dla odwzorowania 132 Tabela 17. Odwzorowanie celów zabezpieczeń dla TOE uzasadnienie Cel zabezpieczeń Komponent SFR Uzasadnienie [symbol celu 4TOE] 133 [symbol komponentu SFR] 134 [uzasadnienie odwzorowania celu 4TOE] Uzasadnienie dla zależności 136 Tabela 18. Zależności SAR uzasadnienie Komponent SAR [symbol komponentu SAR] 137 Komponent zależny Zależność spełniona Uzasadnienie niespełnienia [symbol zależnego komponentu SAR] 139 [uzasadnienie niespełnienia zależności SAR] 138 X 140 Tabela 19. Zależności SFR uzasadnienie Komponent SFR [symbol komponentu SFR] 141 Komponent zależny Zależność spełniona Uzasadnienie niespełnienia [symbol zależnego komponentu SFR] 143 [uzasadnienie niespełnienia zależności SFR] 142 X 144 wersja: [wersja ST] Data: [data wydania ST] Strona 19 z 50

20 6.3.4 Uzasadnienie zestawu komponentów SAR [uzasadnienie zestawu komponentów SAR] 145 wersja: [wersja ST] Data: [data wydania ST] Strona 20 z 50

21 Funkcja TSF [skrót nazwy TOE] 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 TOE 147 Tabela 20. Odwzorowanie komponentów SFR na funkcje zabezpieczające TSF Komponent SFR [symbol komponentu SFR] 149 [symbol funkcji TSF] Opis funkcji zabezpieczających TOE [opis funkcji zabezpieczających TOE] Architektura zabezpieczeń TOE 151 [architektura zabezpieczeń TOE] 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] Data: [data wydania ST] Strona 21 z 50

22 Tabela 21. Podsumowanie materiału dowodowego 153 Wymaganie SAR Materiał dowodowy 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ł ASE_INT.1.5C 158 Podrozdział ASE_INT.1.6C 159 Podrozdział ASE_INT.1.7C 160 Podrozdział ASE_INT.1.8C 161 Podrozdział 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 ASE_CCL.1.10C 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ł ASE_OBJ.2.3C 178 Podrozdział ASE_OBJ.2.4C 179 Podrozdziały i ASE_OBJ.2.5C 180 Podrozdziały i ASE_OBJ.2.6C 181 Podrozdziały i ASE_ECD.1.1C 182 Rozdział 5 ASE_ECD.1.2C 183 Rozdział 5 wersja: [wersja ST] Data: [data wydania ST] Strona 22 z 50

23 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 Podrozdziały 6.1 i 6.2 ASE_REQ.2.4C 190 Podrozdziały 6.1 i 6.2 ASE_REQ.2.5C 191 Podrozdział ASE_REQ.2.6C 192 Podrozdział ASE_REQ.2.7C 193 Podrozdziały i ASE_REQ.2.8C 194 Podrozdział ASE_REQ.2.9C 195 Rozdział 6 ASE_TSS.1.1C 196 Podrozdziały 7.1 i ASE_TSS.2.1C 198 Podrozdziały 7.1 i ASE_TSS.2.2C 200 Podrozdział ASE_TSS.2.3C 202 Podrozdział 7.3 wersja: [wersja ST] Data: [data wydania ST] Strona 23 z 50

24 8. Załącznik Wykaz skrótów 204 Skrót Rozwinięcie skrótu Tłumaczenie polskie CC Common Criteria Wspólne Kryteria EAL Evaluation Assurance Level Poziom uzasadnionego zaufania IT Information Technology Technologia informacyjna OSP Organisational Security Policy Polityka bezpieczeństwa organizacji PP 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 ST Security Target TOE Target of Evaluation Przedmiot oceny TSF TOE Security Functionality Funkcje zabezpieczające TOE [skrót] 205 [rozwinięcie skrótu] 206 [tłumaczenie skrótu] 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] Bibliografia 209 [CC_1] Common Criteria, Part 1: Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and General Model, Version 3.1, July [CC_2] Common Criteria, Part 2: Common Criteria for Information Technology Security Evaluation, Part 2: Security Functional Requirements, Version 3.1, July [CC_3] Common Criteria, Part 3: Common Criteria for Information Technology Security Evaluation, Part 3: Security Assurance Requirements, Version 3.1, July wersja: [wersja ST] Data: [data wydania ST] Strona 24 z 50

25 [CEM] Common Methodology for Information Technology Security Evaluation, Evaluation Methodology, Version 3.1, July [ST_Guide] ISO/IEC TR 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] [wydawca dokumentu] 213, [data wydania] , [nazwa dokumentu] 212, wersja: [wersja ST] Data: [data wydania ST] Strona 25 z 50

26 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; 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 Logo organizacji, która opracowała dokument ST. 14 Nazwa organizacji, która sponsoruje opracowanie dokumentu ST, czyli najczęściej organizacji sponsorującej cały proces certyfikacji TOE. 15 Nazwa organizacji, która opracowała dokument ST. 16 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 Pełna nazwa przedmiotu oceny (TOE). 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] Data: [data wydania ST] Strona 26 z 50

27 23 Skrócona nazwa organizacji konstruującej TOE, która przedstawia go do oceny. 24 Krótka nazwa (symboliczna) opisywanego przedmiotu oceny TOE, która pozwoli go identyfikować w dalszej części dokumentu. 25 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; Bieżąca wersja dokumentu ST. 27 Data wydania bieżącej wersji dokumenty ST. 28 Krótka nazwa (symboliczna) opisywanego przedmiotu oceny TOE, która pozwoli go identyfikować w dalszej części dokumentu. 29 Bieżąca wersja dokumentu ST. 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 sponsorującej cały proces certyfikacji TOE. 36 Adres organizacji, która sponsoruje opracowanie dokumentu ST, czyli najczęściej organizacji sponsorującej cały proces certyfikacji TOE. 37 Telefon organizacji, która sponsoruje opracowanie dokumentu ST, czyli najczęściej organizacji sponsorującej cały proces certyfikacji TOE. 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 Pełna nazwa przedmiotu oceny (TOE). 44 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; Krótka nazwa (symboliczna) opisywanego przedmiotu oceny TOE, która pozwoli go identyfikować w dalszej części dokumentu. 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] Data: [data wydania ST] Strona 27 z 50

28 50 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 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, kryptomodem, 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] Data: [data wydania ST] Strona 28 z 50

29 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; 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. 54 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 v 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 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). 58 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] Data: [data wydania ST] Strona 29 z 50

30 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 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ń: 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 w dziale Protection Profiles. 60 Tylko jeśli ST nie deklaruje zgodności z jakimkolwiek profilem zabezpieczeń. 61 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] Data: [data wydania ST] Strona 30 z 50

31 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: 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. EAL 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] Data: [data wydania ST] Strona 31 z 50

32 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 prywatny używany podczas tworzenia podpisu cyfrowego oraz Opis: 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] Data: [data wydania ST] Strona 32 z 50

33 Opis: Napastnik posiadający wysoki poziom umiejętności, wystarczające środki i głęboką motywację przeprowadza atak celowy na zasoby 70 Krótka nazwa symboliczna podmiotu, np.: SNA.HighPotenIntrud. 71 Opis podmiotu. 72 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] Data: [data wydania ST] Strona 33 z 50

34 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 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. 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] Data: [data wydania ST] Strona 34 z 50

35 Jedynie administratorzy sieci [SAU] mają dostęp do panelu sterowania systemem Opis: zaporowym 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. 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] Data: [data wydania ST] Strona 35 z 50

36 TOE zapewni mechanizmy zarządzania prawami dostępu użytkowników [SAU] do Opis: informacji [DTO] zawartych w TOE 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. 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: OEIT Cele dotyczące aspektów programowych i sprzętowych środowiska Typ generyka: operacyjnego TOE (oprogramowanie i sprzęt) Symbol: OEIT.KeyOper Podczas działania [SAU] żadna informacja o kluczach kryptograficznych nie jest Opis: gromadzona metodą DPA. 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. 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] Data: [data wydania ST] Strona 36 z 50

37 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] Data: [data wydania ST] Strona 37 z 50

38 90 Krótka nazwa symboliczna celu zabezpieczeń dla TOE, np.: OACC.UserPrivMan. 91 Krótka nazwa symboliczna celu zabezpieczeń dla środowiska operacyjnego, np.: OEIT.KeyOper 92 Krótka nazwa symboliczna zagrożenia, np.: TDA.EavesdrpCommLines. 93 Krótka nazwa symboliczna polityki bezpieczeństwa organizacji, np.: PACC.SysAccCtrl. wersja: [wersja ST] Data: [data wydania ST] Strona 38 z 50