Wstęp Dokument zawiera szablon materiału dowodowego wraz z komentarzem. Zamieszczony szablon zawiera wiele informacji, które nie będą umieszczane 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.
[nazwa TOE] 1 [wersja TOE] 2 [nazwa konstruktora] 3 [adres konstruktora] 4 Projekt TOE Projekt architektury () [klauzula poufności dokumentu - krótka] 5 [klauzula poufnosci dokumentu - pełna] 6
7 Wersja [wersja dokumentu] 8 Stan wydania [stan dokumentu] 9 Data [data dokumentu] 10 Autorzy [autorzy dokumentu] 11 Nazwa pliku [skrót nazwy TOE] pl_ [wersja dokumentu] 12
SPIS TREŚCI 1. Wprowadzenie... 6 1.1 Identyfikatory dokumentu... 6 1.2 Zawartość dokumentu... 6 2. Oświadczenia konstruktora... 7 3. Opis struktury TOE... 8 3.1[identyfikator podsystemu]... 8 3.1.1[identyfikator modułu]... 8 4. Mapowanie interfejsów TSFI... 9 4.1 Tabelaryczne podsumowanie mapowania interfejsów... 9 4.2 Szczegóły mapowania interfejsów TSFI... 9 5. Formalny opis podsystemów...błąd! Nie zdefiniowano zakładki. 6. Podsumowanie materiału dowodowego...10 7. Załącznik...11 7.1 Wykaz skrótów...11 7.2 Słownik pojęć...11 7.3 Bibliografia...12 SPIS RYSUNKÓW [spis rysunków] 13 SPIS TABEL Tabela 1. Metryczka dokumentu... 6 Tabela 2. Podsumowanie materiału dowodowego...10 wersja: [wersja dokumentu] Data: [data wydania dokumentu] Strona 4 z 20
Historia zmian w dokumencie 14 Wersja dokumentu Autor Data Opis zmiany [nr wersji dokumentu] [imię i nazwisko] [data wydania wersji] [opis zmian] wersja: [wersja dokumentu] Data: [data wydania dokumentu] Strona 5 z 20
1. Wprowadzenie 1.1 Identyfikatory dokumentu Dokument jest materiałem dowodowym wymaganym przez dla [nazwa TOE] 15 dostarczonego przez [nazwa konstruktora] 16 do oceny na zgodność ze Wspólnymi Kryteriami. Tabela 1 zawiera metryczkę dokumentu. Tabela 1. Metryczka dokumentu Tytuł dokumentu [skrót nazwy TOE] 17 Projekt TOE () Data wydania dokumentu [data wydania dokumentu] 18 Wersja dokumentu [wersja dokumentu] 19 Język dokumentu polski Autorzy [organizacja autorów dokumentu] 20 Zadanie zabezpieczeń [nazwa dokumentu ST] 21, wersja: [wersja ST] 22 TOE [nazwa TOE] 23, wersja: [wersja TOE] 24 Konstruktor TOE [nazwa konstruktora] 25 Zleceniodawca TOE [nazwa sponsora] 26 ID certyfikacji [id jednostki certyfikującej] 27 [id certyfikacji] 28 Schemat oceny IT [schemat oceny IT] 29 Instytucja oceniająca [laboratorium akredytowane] 30 Dokument jest zgodny z normą Common Criteria wersja 3.1, rewizja 3, lipiec 2009 (CCMB-2009-07-003). 31 1.2 Zawartość dokumentu Dokument zawiera projekt TOE wymagany przez dla produktu [nazwa TOE] 32 [wersja TOE] 33 ([skrót nazwy TOE] 34 ) zwanego dalej przedmiotem oceny (TOE Target of Evaluation) opracowanego przez [nazwa konstruktora] 35. Dokument jest wymagany dla produktów o poziomie uzasadnionego zaufania EAL3. Dokument posiada strukturę zgodną z wytycznymi przewodnika dla konstruktorów przygotowujących produkt do oceny wg CC v3.1 [G-BSI]. wersja: [wersja dokumentu] Data: [data wydania dokumentu] Strona 6 z 20
2. Oświadczenia konstruktora Konstruktor dołożył wszelkich starań by opisy zachowania były na odpowiednim poziomie szczegółowości. Konstruktor deklaruje również, że dokumentacja projektowa jest stale aktualizowana i jest spójna z pozostałymi elementami TOE (pozostałą dokumentacją, reprezentacją implementacji itd.). Do mapowania TSFI 36 użyte zostało narzędzie [informacje o narzędziu do mapowania]. 37,38 Konstruktor dokumentuje projekt całego TOE. Możliwy jest wgląd do tej dokumentacji przez oceniającego pod następującymi warunkami: [warunki wglądu do dokumentacji] 39. Podstawą powyższych deklaracji są zarządzenia wewnętrzne [lista zarządzeń wewnętrznych] 40,41 wersja: [wersja dokumentu] Data: [data wydania dokumentu] Strona 7 z 20
3. Opis struktury TOE [Czym jest TOE - przypomnienie] 42 [Ogólny opis struktury wewnętrznej] 43 [Lista zidentyfikawanych podsystemów] 44 [Lista zidentyfikowanych modułów] 45 [Łączny opis zachowania podsystemów] 46 3.1 [identyfikator podsystemu] 47 [Opis podsystemu] 48 [Opis interakcji podsystemu] 49 [Opis zachowania podsystemu] 50 3.1.1 [identyfikator modułu] 51 [Opis modułu] 52 w tym: [Opis interfejsów modułu] 53, [Opis celu i interakcji modułu] 54. wersja: [wersja dokumentu] Data: [data wydania dokumentu] Strona 8 z 20
4. Mapowanie interfejsów TSFI 55 W rozdziale zostały zaprezentowane powiązania interfejsów TSFI (zdefiniowanych w [ADV_FSP]) do podsystemów/modułów, 56 które implementują te interfejsy. Mapowanie dostarcza informacji jak żądanie skierowane do TSFI jest zaimplementowane w poszczególnych podsystemach/modułach. 4.1 Tabelaryczne podsumowanie mapowania interfejsów [tabela mapowania interfejsów] 57 4.2 Szczegóły mapowania interfejsów TSFI [Identyfikator TSFI] 58 [Opis mapowania TSFI] 59 wersja: [wersja dokumentu] Data: [data wydania dokumentu] Strona 9 z 20
5. Podsumowanie materiału dowodowego Poniższa tabela podsumowuje informacje zawarte w dokumencie w odniesieniu do wymagań komponentu. 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. Tabela 2. Podsumowanie materiału dowodowego 60 Wymaganie SAR Materiał dowodowy.1c 61 Rozdział 3.2C 62 Rozdział 3 z podrozdziałami.3c 63 Rozdział 3 z podrozdziałami.4c 64 Rozdział 3.5C 65 Rozdział 3.6C 66 Rozdział 3.7C 67 Rozdział 3 z podrozdziałami.8c 68 Rozdział 4 wersja: [wersja dokumentu] Data: [data wydania dokumentu] Strona 10 z 20
6. Załącznik 69 6.1 Wykaz skrótów Niniejszy wykaz skrótów objaśnia skróty użyte w dokumentacji. Objaśnienie jest zgodne z normą Common Criteria. [wykaz skrótów] 70 6.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. Ich objaśnienie jest zgodne z interpretacją normy Common Criteria. Termin SFR-enforcing SFR-supporting SFR-non-interfering Kategoryzacja modułów lub podsystemów Objaśnienie SFR-wymuszajace interfejsy i akcje, które bezpośrednio są związane z wymaganiami zabezpieczeń realizują bezpośrednio funkcjonalność zabezpieczeń. SFR-wspomagające interfejsy i akcje, które pełnią rolę pomocniczą w realizacji funkcjonalności zabezpieczeń SFR-nie powiązane interfejsy i akcje, które w żaden sposób nie uczestniczą w realizacji funkcjonalności zabezpieczeń podobnie jak jest to w przypadku interfejsów na SFR-enforcing, SFR-supporting i SFR-non-interfering Zachowanie podsystemu określa, co podsystem robi w kontekście wymuszania lub wspierania realizacji zabezpieczeń Podsumowanie zachowania podsystemu ogólny opis akcji, jakie wykonuje Opis podsystemu zachowania dokładne wyjaśnienie wszystkiego, co robi podsystem Opis interakcji między opisuje powód, dla jakiego podsystem lub moduł komunikuje się podsystemami lub z innym podsystemem lub modułem, jakie informacje wersja: [wersja dokumentu] Data: [data wydania dokumentu] Strona 11 z 20
modułami wymieniają między sobą. Opis interfejsów Cel podsystemu lub modułu opisuje szczegóły w zakresie tego jak przebiega interakcja między modułami. Opisana zostaje struktura wymienianych komunikatów, semafory, procesy związane w komunikacją wewnętrzną. określa, w jaki sposób moduł zapewnia swoją funkcjonalność. Opis ten powinien być na tyle szczegółowy by móc zbudować moduł bez podejmowania dodatkowych decyzji projektowych. [wykaz terminów] 71 6.3 Bibliografia 72 [[skrót nazwy dokumentu bibl.] 73 ] [autorzy dokumentu bibl.] 74, [nazwa dokumentu bibl.] 75, [wydawca dokumentu bibl.] 76, [data wydania bibl.] 77 [ST] [autorzy dokumentu ST], [nazwa dokumentu ST] ([data dokumentu ST]), [data wydania ST]. [ADV_FSP] [autorzy ADV_FSP], [nazwa dokumentu ADV_FSP], ([data dokumentu ADV_FSP]), [data wydania ADV_FSP]. 78 wersja: [wersja dokumentu] Data: [data wydania dokumentu] Strona 12 z 20
Komentarze do szablonu materiału dowodowego 1 Pełna nazwa przedmiotu oceny (TOE). 2 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. 3 Pole powinno zawierać nazwę organizacji konstruktora, istotne jest podanie pełnej nazwy. 4 Dane adresowe pozwalające na kontakt z konstruktorem bądź osobą reprezentującą. Istotne są dane pozwalające na zlokalizowanie siedziby konstruktora, numery telefonów, adresy poczty elektronicznej oraz inne dane ułatwiające identyfikację konstruktora. 5 Klauzula poufności dokumentu, określająca w zwięzły sposób zakres informacji prawnie chronionych. Przykładowe klauzule: Poufne, Tajemnica przedsiębiorstwa. 6 Klauzula poufności dokumentu definiująca w sposób pełny zakres i sposób ochrony informacji zawartych w dokumencie. 7 Identyfikator dokumentu w formie tabeli przedstawia podstawowe informacje, które w pełni identyfikują dokument. Tabela przedstawia, kto jest autorem dokumentu (osoby odpowiedzialne za jego przygotowanie), stan dokumentu, kiedy dokument został opublikowany oraz w jakim pliku jest przechowywany. 8 Oznaczenie wersji dokumentu zgodnie z przyjętym schematem wersjonowania dokumentów. Ważne jest, aby wersja dokumentu miała też swoje odzwierciedlenie w metryce zmian dokumentu. 9 Stan dokumentu określa, na jakim etapie edycji znajduje się dokument. Pole może przyjmować jedną z czterech wartości: roboczy, do zatwierdzenia, zatwierdzony, wycofany. 10 Data wydania dokumentu określa datę ostatniej jego modyfikacji. 11 Autorzy odpowiedzialni za przygotowanie dokumentu. 12 Nazwa pliku, w którym umieszczony jest dokument. Nazwa pliku powinna zawierać informacje o TOE, komponencie, języku przygotowania i wersji dokumentu. 13 Spis rysunków dokumentu. Zalecane jest, aby spis został wygenerowany automatycznie z użyciem narzędzi edytora tekstów. 14 Historia zmian dokumentu w formie tabeli. W kolejnych wierszach tabeli umieszcza się wersję dokumentu (zgodną z określonym sposobem wersjonowania), autora zmiany, datę zmiany oraz krótki opis zmiany. 15 Pełna nazwa przedmiotu oceny (TOE). 16 Pełna nazwa konstruktora, który jest autorem TOE i przedstawia go do oceny. 17 Krótka nazwa (symboliczna) opisywanego przedmiotu oceny TOE, która pozwoli go identyfikować w dalszej części dokumentu. 18 Data wydania bieżącego dokumentu, która określa wydanie ostatecznej wersji dokumentu, a nie jego wersji roboczej. 19 Wersja bieżącego dokumentu zgodna ze sposobem wersjonowania określonym przez konstruktora. 20 Organizacja autorów dokumentu, najczęściej jest to organizacja konstruktora. 21 Tytuł dokumentu zadania zabezpieczeń ST, do którego odnosi się bieżący dokument. 22 Wersja dokumentu ST, do którego odnosi się bieżący dokument. 23 Pole powinno zawierać pełna nazwę przedmiotu oceny (TOE). 24 Wersja TOE zgodna ze sposobem wersjonowania określonym przez konstruktora. wersja: [wersja dokumentu] Data: [data wydania dokumentu] Strona 13 z 20
25 Pełna nazwa konstruktora, który jest autorem TOE i przedstawia go do oceny. 26 Pełna nazwa zleceniodawcy (sponsora oceny TOE). W szczególnym przypadku może to być także nazwa konstruktora. 27 Identyfikator organizacji certyfikującej, np. BSI-DSZ-CC. 28 Identyfikator przeprowadzanego procesu certyfikacji. 29 Schemat oceny IT, np. German CC Evaluation Scheme. 30 Laboratorium certyfikujące TOE. 31 Należy zauważyć, że niniejszy szablon jest zgodny z CC 3.1 rewizja 3. Zmiana wersji lub nawet rewizji może wymagać aktualizacji szablonu. 32 Pełna nazwa przedmiotu oceny (TOE). 33 Wersja TOE. 34 Krótka nazwa (symboliczna) opisywanego przedmiotu oceny TOE, która pozwoli go identyfikować w dalszej części dokumentu. 35 Pełna nazwa konstruktora, który jest autorem TOE i przedstawia go do oceny. 36 Mapowanie TSFI to powiązanie interfejsu (TSFI) z podsystemem lub modułem, który je implementuje bezpośrednio odpowiada za jego działanie. 37 Informacja o narzędziu użytym do mapowania TSFI na moduły i podsystemy: typ narzędzia, nazwa narzędzia, numer wersji. Przykładowo może to być narzędzie typu Enterprise Architect, tabelka w Excelu, lub inne dedykowane narzędzie projektowe. Zamieszczanie informacji o mapowaniu nie wynika bezpośrednio z normy, ale jest to cenna informacja dla oceniającego. Daje to oceniającemu możliwość zbudowania wyobrażenia środowiska, w jakim powstaje TOE. Metodologia oceny CEM w wielu punktach w ten sposób uzasadnia konieczność podawania poszczególnych informacji. 38 Zdanie należy zamieścić, gdy do mapowania TSFI do modułów/podsystemów zostało użyte jakieś narzędzie. W przypadku, gdy żadne narzędzie nie zostało użyte do zrealizowania mapowania autor materiału dowodowego może pominąć ten fragment w dokumencie, bądź zamieście informacje wprost, że żadne szczególne narzędzie informatyczne nie zostało do tego wykorzystane. 39 Lista warunków do spełnienia np. konieczność podpisania klauzuli poufności, określenie miejsca i sposobu wglądu do dokumentacji, zakres dokumentacji możliwy do wglądu 40 Lista zarządzeń wewnętrznych - organizacyjnych gwarantujących prawdziwość oświadczenia o prowadzeniu dokumentacji projektowej. W wielu organizacjach wprowadzone są wewnętrzne regulacje, które wprowadzają regulacje dotyczące realizacji zachodzących w organizacji procesów, relacji miedzy nimi i innych warunków funkcjonowania. Wewnętrzne regulacje, w różnym zakresie, mogą się pokrywać, czy wręcz zaspokajać wymagania wynikające z normy CC. Wskazanie tych regulacji wzbogaci materiał dowodowy i ułatwi oceniającemu proces oceny. 41 Zdanie opcjonalne, dodawane tylko, gdy kwestie dokumentacji projektowej są uregulowane takimi zarządzeniami, innymi normami itp. 42 Pole powinno zawierać krótkie przypomnienie, czym jest TOE i jakie jest jego przeznaczenie. Opis powinien stanowić przypomnienie informacji zawartych w dokumencie ST. 43 Ogólny opis struktury TOE z podziałem na podsystemy. Strukturę można uzupełnić o diagram UML (np. diagram komponentów, klas). Jeśli autor materiału dowodowego wykorzysta diagramy UML powinien wersja: [wersja dokumentu] Data: [data wydania dokumentu] Strona 14 z 20
zamieścić informacje o użytym do modelowania UML narzędziu (w rozdziale 2). Pole powinno zawierać podział całego TOE (zakres TOE określony jest w ST) na podsystemy. Należy zidentyfikować wszystkie podsystemy, zarówno te które stanowią TSF jak i te które TSF nie stanowią. Ogólny opis struktury TOE powinien zakończyć się na identyfikacji podsystemów (dla komponentu i wzwyż również modułów). Opisy zidentyfikowanych elementów są umieszczane osobno wg dalej zamieszczonych wskazówek. 44 Opis ogólny struktury TOE powinien zawierać identyfikację podsystemów w dowolnej formie listy, wyliczenia, luźnego opisu. 45 Dla i wzwyż opis ogólny struktury TOE powinien zawierać identyfikację modułów w dowolnej formie listy, wyliczenia, luźnego opisu. 46 Dla komponentów ADV_TDS.1 i należy zamieścić informacje o zachowaniu podsystemów. Mogą one być zamieszczone w formie łącznej w bieżącym opisie (zgodnie z normą CC) lub rozdzielone pomiędzy opisy poszczególnych podsystemów (taką sugestię zawiera CEM). W pozostałych komponentach opis zachowania jest bardziej szczegółowy i powinien być częścią opisu poszczególnych podsystemów. Treść tego pola powinna być zatem pusta. W przypadku zdecydowania się na opis łączny, w bieżącym opisie należy zmieścić następujące informacje: Dla komponentu należy: dla podsystemów SFR-enforcing należy opisać zachowanie związane z zabezpieczeniami (SFRenforcing) oraz podsumować zachowanie pośrednio związane z zabezpieczeniami (SFR-supporting) i niezwiązane z zabezpieczeniami (SFR-non-interfering). dla podsystemów SFR-supporting należy podsumować zachowanie każdego rodzaju. Niezależnie od wyboru sposobu zamieszczenia informacji o zachowaniu podsystemów, zachowanie SFRnon-interfering (dla ) należy opisać indywidualnie, dla każdego podsystemu. Informacja o sposobie zamieszczenia podsumowania zachowania rozdzielonego na poszczególne podsystemy, znajduje się w komentarzu do pola [Opis zachowania podsystemu]. 47 Dla każdego zidentyfikowanego podsystemu należy przedstawić jego opis. 48 Zawartość opisu podsystemu zależy od wybranego komponentu zgodnie, z którym powstawać będzie dokument. Niezależnie od komponentu konstruktor może (ale nie musi) dokonywać jawnego podziału na rodzaje podsystemów, nie mniej podział taki mimo, że pomaga zorganizować konstruktorowi pracę nad materiałem dowodowym będzie jedynie wskazówką dla oceniającego. Zadaniem oceniającego jest ostateczny podział na rodzaje podsystemów i ocena czy dany podsystem jest odpowiednio opisany. Analizując materiał dowodowy oceniający może sięgać po inne materiały np.: specyfikację funkcjonalną, architekturę bezpieczeństwa, reprezentację implementacji. Wszystkie te elementy powinny być spójne. W ramach opisu podsystemu należy: Podać identyfikator podsystemu (tak by można się do niego łatwo odnosić w innych częściach materiału dowodowego). wersja: [wersja dokumentu] Data: [data wydania dokumentu] Strona 15 z 20
Określić kategorię podsystemu (SFR-enforcing, SFR-supporting, SFR-non-interfering). Zarówno norma jak i metodologia oceny CEM nie uznają jawnej klasyfikacji elementów, jako wymaganej i koniecznej. Kategoryzacja służyć ma autorowi materiału dowodowego, jako ułatwienie w konstruowaniu szczegółowego opisu elementów. Oceniający musi przeprowadzić własną kategoryzację, w trakcie oceniania materiału dowodowego, w sposób niezależny od konstruktora, na podstawie dostarczonego materiału dowodowego (nie tylko związanego z ADV_TDS). Poziom szczegółowości informacji zamieszczanych w materiale dowodowym zależy od dwóch czynników: komponentu uzasadniającego zaufanie i kategorii opisywanego elementu. Jak wynika z wymagań normy szczegółowość (objętość) opisu elementu dla danego komponentu może się zacznie różnić. Może zdarzyć się, że konstruktor oznaczy element, jako SFR-enforcing i załączy opis właściwy dla tej kategorii, a oceniający element oznaczy jako SFR-non-interfering i będzie oczekiwał opisu o znacznie większym poziomie szczegółowości. W takim przypadku, jeśli oceniający nie odnajdzie w innym miejscu (materiał dowodowy) odpowiednich informacji może uznać materiał dowodowy jako niewystarczający. Z powyższej dyskusji wynika (i taka sugestia jest zawarta w CEM), że konstruktor może zaproponować zunifikowany opis na najwyższym poziomie szczegółowości właściwym dla danego komponentu uzasadniającego zaufanie, niezależnym od kategorii elementu. Definicję kategorii w kontekście podsystemów przedstawiono w metodologii CEM w akapicie 748. Pamiętać należy, że ostateczną, wiążącą kategoryzację określa oceniający w trakcie oceny materiału dowodowego. Jeżeli jednak konstruktor nie wprowadzi kategoryzacji powinien zaznaczyć czy dany podsystem jest częścią TSF czy nie. 49 Opis interakcji podsystemu w zależności od komponentu i kategorii modułu należy zamieścić właściwy opis interakcji podsystemu. Dostarczony przez konstruktora opis powinien dostarczyć informacji, która uzasadnia potrzebę interakcji między podsystemami. Interakcja jest w tym przypadku rozumiana, jako interfejs na poziomie szczegółowości, jaki jest właściwy dla projektu TOE w kontekście podziału na podsystemy. Dla : Określić interfejsy, jakie są realizowane przez dany podsystem. Pozwoli to na opisanie zachowania podsystemu. Interfejsy te powinny być opisane na poziomie ogólnym, bez szczegółów implementacyjnych. Nie należy opisywać parametrów, czy konkretnych struktur danych. Powinny zostać jednak zidentyfikowane i opisane elementy danych dla poszczególnych podsystemów. Opisać interakcje z innymi podsystemami. W ramach tego opisu należy podać powód, dla którego następuje komunikacja oraz dane, jakie są wymieniane. Opis może być ogólny. Należy opisać relacje sterujące, jakie zachodzą między systemami. 50 Opis zachowania podsystemu w zależności od komponentu i kategorii modułu należy zamieścić właściwy opis zachowania podsystemu. Dla : W przypadku decyzji autora materiału dowodowego o zamieszczeniu informacji o zachowaniu podsystemu w bieżącym polu (zgodnie z sugestią CEM), dla podsystemów SFR-enforcing należy wersja: [wersja dokumentu] Data: [data wydania dokumentu] Strona 16 z 20
opisać zachowanie związane z zabezpieczeniami (SFR-enforcing) oraz podsumować zachowanie pośrednio związane z zabezpieczeniami (SFR-supporting) i niezwiązane z zabezpieczeniami (SFRnon-interfering). Opis powinien być na wyższym poziomie szczegółowości niż w przypadku ADV_TDS.1. W przypadku decyzji autora materiału dowodowego o zamieszczeniu informacji o zachowaniu podsystemu w bieżącym polu (zgodnie z sugestią CEM), dla podsystemów SFR-supporting należy podsumować zachowanie każdego rodzaju. Jeżeli opisywany podsystem należy do kategorii SFR-non-interfering, należy opisać zachowanie tak, by można było stwierdzić, że przynależność do tej grupy jest uzasadniona. Opis zachowania nie powinien być na wysokim poziomie szczegółowości. Pamiętać jednak należy, że oceniający w swoim kwalifikowaniu podsystemów kierować się będzie też objętością, więc jeśli opis zachowania podsystemu będzie skąpy oceniający może uznać ten podsystem, jako SFR-non-interfering mimo odmiennej deklaracji konstruktora. 51 Należy opisać każdy z modułów. Opis jest obowiązkowy w przypadku zgodności z komponentem ADV_TDS.3 i wyższym. Opis na poziomie szczegółowości właściwym dla modułów powinien pokrywać całość TSF, błędem jest uwzględnianie tylko części TSF. Opisy dostarczone przez konstruktora powinny umożliwić oceniającemu przegląd reprezentacji implementacji. Opisy modułów powinny umożliwiać ich implementację bez konieczności sięgania po dodatkowe informacje. Utworzona w ten sposób implementacja powinna być: 1. identyczna z aktualną TSF, na poziomie przedstawionych interfejsów, 2. identyczna pod względem użytkowania interfejsów, 3. ekwiwalentem funkcjonalnym aktualnej implementacji TSF. Zgodnie z wymaganiami z normy CC konstruktor w materiale dowodowym powinien przedstawić mapowanie (przyporządkowanie) modułów i podsystemów. Przedstawiony wzorzec materiału ma tak zorganizowaną treść by spełnić to wymaganie. Jednak, jeśli autorzy zmienią układ treści muszą pamiętać o tym wymaganiu. 52 Zawartość opisu modułu zależy od wybranego komponentu zgodnie, z którym powstawać będzie dokument. Celem tego fragmentu materiału dowodowego jest dostarczenie opisu, jaka funkcjonalność jest realizowana. Niezależnie od komponentu konstruktor może, ale nie musi dokonywać jawnego podziału na rodzaje modułów, nie mniej podział taki, mimo że pomaga zorganizować konstruktorowi pracę nad materiałem dowodowym będzie jedynie wskazówką dla oceniającego. Zadaniem oceniającego jest ostateczny podział na rodzaje modułów i ocena czy dany moduł jest odpowiednio opisany. Wymagany przez normę poziom szczegółowości dla modułów powoduje, że ten fragment materiału dowodowego nie powinien być tworzony w oderwaniu od procesu projektowania i implementacji. Opis modułów powinien być częścią implementowania, powstawać i uszczegółowiać się równolegle z tworzeniem TOE. W przypadku tych części TOE, które są oprogramowaniem istnieje szereg narzędzi i technik pozwalających na tworzenie tego typu dokumentacji implementacyjnej. Przedstawiając opis modułów należy pamiętać, że niektóre języki programowania posiadają możliwość definiowania dodatkowych interfejsów, które mogą nie być postrzegane, jako interfejsy, a jednak powinny być opisane. Dotyczy to na przykład przeciążania operatorów w C++. wersja: [wersja dokumentu] Data: [data wydania dokumentu] Strona 17 z 20
Pojedynczy moduł powinien być traktowany, jako mały zbiór powiązanych ze sobą logicznie interfejsów, choć oczywiście może istnieć moduł, który posiada tylko jeden interfejs. W przypadku opisu modułów, mimo wysokiego poziomu szczegółowości opisu należy mieć świadomość, że ocena tego materiału będzie się wiązać z częstymi żądaniami dodatkowych informacji ze strony oceniającego. 53 Opis interfejsów modułu zgodnie z uwagami w komentarzu do pola [Opis modułu] 54 Opis celu modułu i realizowanych interakcji z innymi modułami zgodnie z uwagami w komentarzu do pola [Opis modułu]. Dodatkowo należy pamiętać, że interakcja jest rodzajem interfejsu z tym zastrzeżeniem, że posiada mniej rygorystycznie sformalizowany opis. Opis interakcji powinien przedstawiać z funkcjonalnego punktu widzenia, dlaczego poszczególne moduły wchodzą wzajemnie w interakcje. 55 Treści przedstawione w tym rozdziale zostaną przez oceniających zweryfikowane w następujący sposób: 1. Sprawdzone zostanie czy TSFI są mapowane do tej części TOE, która została wskazana, jako TSF 2. Potwierdzenie, że wszystkie funkcjonalne wymagania bezpieczeństwa z zadania zabezpieczeń [ST] mają swoje odzwierciedlenie w projekcie TOE. W trakcie swoich czynności oceniający może sporządzić własną mapę relacji miedzy SFR a elementami projektu TOE. 56 Podsystemy dla komponentów ADV_TDS.1 i, dla ADV_TDS.3 i wyższych podsystemy oraz moduły 57 Mapowanie interfejsów zrealizowane w formie tabelki. Poziom szczegółowości (podsystemy, moduły) zależy od wybranego komponentu, z którym dokument ma być zgodny - dla komponentów ADV_TDS.1 i na poziomie podsystemów, a dla ADV_TDS.3 i wyższych na poziomie podsystemów i modułów. Przykładowo można to zrealizować w formie tabelki. W poniższych tabelkach X oznacza związek pomiędzy podsystemem lub modułem, a interfejsem. Tabela występuje tu w roli podsumowania związków, jakie istnieją miedzy elementami projektu TOE a TSFI. Nie jest wymagane kompletne drzewo wywołań podsystemów. Fakt oznaczenia mapowania interfejsów musi mieć odzwierciedlenie w opisie podsystemu/moduły. Oceniający analizując materiał dowodowy będzie opierał się na dokumencie ST, przez stworzenie własnego mapowania pomiędzy SFR a podsystemami/modułami wykazanymi w materiale dowodowym. Na tej podstawie oceniający będzie oceniał czy dany podsystem/moduł zaspokaja SFR. Dla ADV_TDS.1 i : TSFI 1 TSFI 2 TSFI 3 TSFI N Podsystem 1 Podsystem 2 Podsystem M X X X X 58 Identyfikator interfejsu TSFI opisanego w Specyfikacji funkcjonalnej [ADV_FSP]. Dla każdego zidentyfikowanego interfejsu TSFI należy dołączyć stosowny opis pokazujący połączenie z projektem TOE. wersja: [wersja dokumentu] Data: [data wydania dokumentu] Strona 18 z 20
59 Opisane w formie tabeli zależności między elementami projektu TOE a TSFI należy wzbogacić o bardziej szczegółowy opis. Dla ADV_TDS.1 i : Dla każdego TSFI (z materiału dowodowego ADV_FSP) należy opisać, który z podsystemów jest angażowany, jako pierwszy w obsługę żądania związanego z danym TSFI, który podsystem jest główną implementacją TSFI. 60 Zestawienie zależności dla różnych komponentów rodziny ADV_TDS. W zależności od wybranego komponentu należy usunąć z tabelki opisy dotyczące pozostałych komponentów. 61 The design shall describe the structure of the TOE in terms of subsystems. Projekt powinien przedstawić strukturę TOE definiując jego podsystemy. 62 The design shall identify all subsystems of the TSF. Projekt powinien zidentyfikować wszystkie podsystemy TSF. 63 The design shall describe the behaviour of each SFR-non-interfering TSF subsystem in detail sufficient to determine that it is SFR-non-interfering. Projekt powinien opisać zachowanie każdego z podsystemów zakwalifikowanych, jako SFR-non-interfering, tak by mieć pewność, że właściwie został zakwalifikowany, jako SFR-non-interfering. 64 The design shall describe the SFR-enforcing behaviour of the SFR-enforcing subsystems. Projekt powinien opisać zachowanie bezpośrednio związane z realizowanymi zabezpieczeniami podsystemów zakwalifikowanych, jako SFR-enforcing. 65 The design shall summarise the SFR-supporting and SFR-non-interfering behaviour of the SFR-enforcing subsystems. Projekt powinien podsumować zachowanie wspierające realizowane zabezpieczenia i niezwiązane z zabezpieczeniami dla podsystemów zakwalifikowanych, jako SFR-enforcing. 66 The design shall summarise the behaviour of the SFR-suporting subsystems. Projekt powinien podsumować zachowanie podsystemów zakwalifikowanych, jako SFR-supporting. 67 The design shall provide a description of the interactions among all subsystems of the TSF. Projekt powinien zapewnić opis interakcji pomiędzy wszystkimi podsystemami TSF. 68 The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke. W projekcie powinno znaleźć się mapowanie, które wykaże, że wszystkie TSFI są powiązane z opisywanym w projekcie zachowaniem. 69 Rozdział powinien zawierać listę załączników powiązanych z dokumentem lub tych, które są istotne dla pełnego zrozumienia dokumentu. 70 Wykaz skrótów używanych w dokumencie. Przykładowo: CC Common Criteria EAL Evaluation Assurance Level SAR Security Assurance Requirement SFR Security Functional Requirement ST Security Target wersja: [wersja dokumentu] Data: [data wydania dokumentu] Strona 19 z 20
TOE Target of Evaluation CM Configuration Management LC Life cycle 71 Wykaz pojęć w słowniku. Przykładowo: Termin Poziom uzasadnionego zaufania (ang. Evaluation Assurance Level) Objaśnienie Poziom wiarygodności oceny zbiór wymagań uzasadniających zaufanie. Skala EAL jest siedmiostopniowa: EAL1 EAL7. Skład pakietów jest opisany w trzeciej części CC. 72 W tym miejscu należy wymienić pozostałe dokumenty z materiałem dowodowym dostarczanym do oceny. 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. [CC_2 ]Common Criteria, Part 2: Common Criteria for Information Technology Security Evaluation, Part 2: Security Functional Requirements, Version 3.1, July 2009. [CC_3] Common Criteria, Part 3: Common Criteria for Information Technology Security Evaluation, Part 3: Security Assurance Requirements, Version 3.1, July 2009. [CEM] Common Methodology for Information Technology Security Evaluation, Evaluation Methodology, Version 3.1, July 2009. [G-BSI] Guidelines for Developer Documentation according to Common Criteria Version 3.1, Bundesamt für Sicherheit in der Informationstechnik 2007. [normy, przepisy i inna literatura dotycząca projektowanego TOE] [ST] Firma ABC, Czujnik ruchu v1 Zadanie zabezpieczeń, 2010.04.10 [CMC] Czujnik ruchu v1 Możliwości systemu CM (ALC_CMC) v2.0, Maria Kowalska, 2010.04.02. 73 Krótka symboliczna nazwa dokumentu. 74 Lista autorów dokumentu sformatowana, jako: nazwisko, pierwsza litera imienia lub imion, kropka. Pole jest opcjonalne. 75 Nazwa przywoływanego dokumentu. 76 Wydawca dokumentu. 77 Data wydania dokumentu. 78 Wszystkie zmienne pola dotyczą cytowanego dokumentu: data wydania, nazwa TOE, nazwa konstruktora itd. wersja: [wersja dokumentu] Data: [data wydania dokumentu] Strona 20 z 20