Instytut Technik Innowacyjnych Konstruowanie produktu informatycznego (na przykładzie czujnika gazometrycznego) w środowisku rozwojowym na podstawie wzorców warsztaty część I Marcin Małachowski, Damian Nowak Nr projektu: UDA POIG 01.03.01.156/08-00 Akronim projektu: CCMODE Cel prezentacji Zilustrowanie wykorzystania wzorców materiału dowodowego dla badania zabezpieczeń oraz przedstawienie wybranych zagadnień związanych z konstruowaniem urządzeń zgodnie z wymaganiami standardu CCMODE na przykładzie czujnika gazometrycznego MCX.1.0
Przedmiot oceny Czujnik gazometryczny MCX 1.0 Ciągły pomiar metanu 0 100% Transmisja danych do stacji powierzchniowej Sygnalizacja przekroczenia dopuszczalnych stężeń Sterowanie wyjściami analogowymi do wyłączania energii w zagrożonym rejonie 3 Prezentowane wzorce materiału dowodowego Zadanie zabezpieczeń ST (Security Target) ADV_TDS.1 Projekt podstawowy ADV_FSP.2 Specyfikacja funkcjonalności bezpośrednio związanej z zabezpieczeniami ADV_ARC.1 Opis architektury zabezpieczeń 4
Wstęp Terminy używane w CC Akronim Znaczenie Target of Evaluation (TOE) EAL - Evaluation Assurance Levels SAR Security Assurance Requirement SFR Security Functional Requirements ST - Security Target TSF - TOE Security Functions przedmiot oceny, zestaw oprogramowania (software), firmware i/lub sprzętu poddawany ocenie i certyfikacji; np. czujnik gazometryczny MCX 1.0 predefiniowany zestaw wymagań dotyczących bezpieczeństwa poziomy od EAL1 do EAL7 wymagania uzasadniające zaufanie do zabezpieczeń wymagania funkcjonalne bezpieczeństwa zadanie zabezpieczeń funkcje zabezpieczeń TOE Struktura dokumentu wzorca zadania zabezpieczeń SECURITY TARGET WPROWADZENIE DO ST DEKLARACJE ZGODNOŚCI DEFINICJA PROBLEMU BEZPIECZEŃSTWA CELE ZABEZPIECZEŃ DEFINICJA KOMPONENTÓW DODATKOWYCH WYMAGANIA BEZPIECZEŃSTWA SPECYFIKACJA KOŃCOWA TOE
ST (Security Target) - struktura wzorca dokumentu zadania zabezpieczeń Rozdział 1 Wprowadzenie do ST identyfikacja dokumentu zadania zabezpieczeń oraz przedmiotu oceny (TOE), przegląd możliwości TOE oraz opis TOE, czyli podanie fizycznych i logicznych granic TOE; Rozdział 2 Deklaracje zgodności deklaracje zgodności z konkretną wersją normy CC, pakietami (np. EAL) oraz profilami zabezpieczeń (PP); Rozdział 3 Definicja problemu bezpieczeństwa opis zagrożeń, polityk bezpieczeństwa organizacji oraz założeń dotyczących przedmiotu oceny i jego środowiska operacyjnego; Rozdział 4 Definicja problemu bezpieczeństwa 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; ST (Security Target) - struktura wzorca dokumentu zadania zabezpieczeń Rozdział 5 Definicja komponentów dodatkowych 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; Rozdział 6 Wymagania bezpieczeństwa wymagania na uzasadnione zaufanie do zabezpieczeń (SAR) oraz wyrażenie celów zabezpieczeń dla TOE za pomocą wymagań na funkcjonalność zabezpieczeń (SFR); Rozdział 7 Specyfikacja końcowa TOE opis funkcji zabezpieczających TOE (TSF), czyli technicznych mechanizmów ochrony wykorzystywanych przez przedmiot oceny.
Wprowadzenie do ST SECURITY TARGET WPROWADZENIE DO ST DEKLARACJE ZGODNOŚCI DEFINICJA PROBLEMU BEZPIECZEŃSTWA CELE ZABEZPIECZEŃ DEFINICJA KOMPONENTÓW DODATKOWYCH WYMAGANIA BEZPIECZEŃSTWA SPECYFIKACJA KOŃCOWA TOE ST reference identyfikacja zadania zabezpieczeń podanie tytułu, wersji ST, daty oraz dla kogo i przez kogo został sporządzony dokument TOE reference indntyfikacja TOE podanie dokładnej nazwy, wersji oraz producenta przedmiotu oceny TOE overview przegląd możliwości TOE sprecyzowanie rodzaju produktu, jego funkcjonalności oraz środowiska działania TOE description podanie fizycznych i logicznych granic TOE, określenie co wchodzi w skład TOE, a co należy do jego otoczenia
Kluczowe elementy Precyzyjna i dobrze przemyślana definicja i zakres TOE 16
Deklaracja zgodności SECURITY TARGET WPROWADZENIE DO ST DEKLARACJE ZGODNOŚCI DEFINICJA PROBLEMU BEZPIECZEŃSTWA CELE ZABEZPIECZEŃ DEFINICJA KOMPONENTÓW DODATKOWYCH WYMAGANIA BEZPIECZEŃSTWA CC conformance claim deklaracja zgodności z konkretną wersją standardu CC oraz określenie czy użyto dodatkowych komponentów SAR lub SFR PP claim deklaracja zgodności z profilem zabezpieczeń package claim deklaracja zgodności z pakietem (zbiorem komponentów SAR lub SFR), najczęściej jest to deklaracja zgodności z konkretnym poziomem EAL conformance rationale uzasadnienie powyższych deklaracji zgodności SPECYFIKACJA KOŃCOWA TOE
Definicja problemu bezpieczeństwa SECURITY TARGET WPROWADZENIE DO ST threats identyfikacja zagrożeń TOE i jego otoczenia organisational security policies określe zasad polityki bezpieczeństwa dla TOE DEKLARACJE ZGODNOŚCI DEFINICJA PROBLEMU BEZPIECZEŃSTWA CELE ZABEZPIECZEŃ DEFINICJA KOMPONENTÓW DODATKOWYCH WYMAGANIA BEZPIECZEŃSTWA assumptions podanie założeń dotyczących środowiska operacyjnego i zamierzonego wykorzystania TOE w tym środowisku SPECYFIKACJA KOŃCOWA TOE
Kluczowe elementy Precyzyjna i dobrze przemyślana identyfikacja zagrożeń 22
Cele zabezpieczeń SECURITY TARGET WPROWADZENIE DO ST DEKLARACJE ZGODNOŚCI DEFINICJA PROBLEMU BEZPIECZEŃSTWA CELE ZABEZPIECZEŃ DEFINICJA KOMPONENTÓW DODATKOWYCH WYMAGANIA BEZPIECZEŃSTWA security objectives for the TOE cele zabezpieczeń dla TOE security objectives for the operational environment cele zabezpieczeń dla otoczenia security objectives rationale uzasadnienie rozwiązania problemów bezpieczeństwa za pomocą celów zabezpieczeń SPECYFIKACJA KOŃCOWA TOE
Kluczowe elementy Precyzyjnie zdefiniowane cele zabezpieczeń 25 Definicja komponentów dodatkowych SECURITY TARGET WPROWADZENIE DO ST jeśli do ST dodano komponenty SFR lub SAR spoza katalogu komponentów zdefiniowanych w CC, to w tym miejscu należy opisać te komponenty DEKLARACJE ZGODNOŚCI DEFINICJA PROBLEMU BEZPIECZEŃSTWA CELE ZABEZPIECZEŃ DEFINICJA KOMPONENTÓW DODATKOWYCH WYMAGANIA BEZPIECZEŃSTWA SPECYFIKACJA KOŃCOWA TOE
Wymagania bezpieczeństwa SECURITY TARGET WPROWADZENIE DO ST DEKLARACJE ZGODNOŚCI DEFINICJA PROBLEMU BEZPIECZEŃSTWA CELE ZABEZPIECZEŃ DEFINICJA KOMPONENTÓW DODATKOWYCH WYMAGANIA BEZPIECZEŃSTWA SPECYFIKACJA KOŃCOWA TOE security functional requirements funkcjonalne wymagania bezpieczeństwa - wyrażenie celów zabezpieczeń dla TOE za pomocą komponentów SFR security assurance requiments wymagania na uzasadnione zaufane zbiór komponentów SAR składających się na konkretny poziom EAL security requiments rationale uzasadnienie pokrycia celów zabezpieczeń dla TOE wymaganiami funkcjonalnymi, czyli komponentami SAR
Specyfikacja końcowa TOE SECURITY TARGET WPROWADZENIE DO ST DEKLARACJE ZGODNOŚCI pokrycie wymagań funkcjonalnych (SFR) funkcjami zabezpieczeń TSF (TSF ang. TOE Security Function) DEFINICJA PROBLEMU BEZPIECZEŃSTWA CELE ZABEZPIECZEŃ DEFINICJA KOMPONENTÓW DODATKOWYCH WYMAGANIA BEZPIECZEŃSTWA SPECYFIKACJA KOŃCOWA TOE
Koniec części I 35 Instytut Technik Innowacyjnych Konstruowanie produktu informatycznego (na przykładzie czujnika gazometrycznego) w środowisku rozwojowym na podstawie wzorców warsztaty część II Marcin Małachowski, Damian Nowak Nr projektu: UDA POIG 01.03.01.156/08-00 Akronim projektu: CCMODE 36
Rodzina ADV_TDS TOE design Projekt TOE Zadania dokumentacji związanej z rodziną ADV_TDS: opis TOE w zakresie implementacji funkcjonalności zabezpieczeń określenie granic funkcjonalności zabezpieczeń TOE 37 Rodzina ADV_TDS Struktura dokumentu - wzorca ADV_TDS Opis struktury TOE Odwzorowanie (przyporządkowanie) interfejsów 38
Rodzina ADV_TDS Podział TOE na podsystemy uzupełniony o diagramy UML Przyporządkowanie podsystemów do kategorii: SFR-enforcing, SFR-supporting, SFR-non-interfering ADV_TDS Opis poszczególnych podsystemów w zakrasie wymuszania lub wspierania realizacji zabezpieczeń Opis struktury TOE Odwzorowanie (przyporządkowanie) interfejsów 39 Opis struktury TOE czujnika gazometrycznego MCX.1.0 W strukturze czujnika MCX.1.0 wyróżniamy siedem podsystemów: MCXcore MCXdet MCXklaw MCXtranzas MCXwewy MCXlcd MCXobud Interfejsy typu SFR-enforcing Interfejsy typu SFR-supporting Interfejsy typu SFR-non-interfering 40
Struktura podsystemów i interfejsów TOE ŚRODOWISKO MCXobud OBUDOWA GAZ MCXdet POMIARY KAL IB MCXcore DANE T RAN S MCXlcd ZAS DANEWEWY Z AS Z AS K LAWIATURA MCXklaw KALIB TRANS MCXtranzas LINI A ZAS Z AS MCXwewy TOE ZAS WEJŚCIA WEJŚCIA WYJŚCIA 41 Opis podsystemu MCXdet GAZ MCXdet POMIARY Realizowane funkcje: konwersja wielkości fizycznych stężeń gazów na wielkości elektryczne realizacja funkcji diagnostycznych detektorów kontrola parametrów zasilania ZAS Interfejsy podsystemu MCXdet: MCXdet: GAZ MCXdet: POMIARY MCXdet: ZAS 42
Rodzina ADV_TDS ADV_TDS Opis struktury TOE Odwzorowanie (przyporządkowanie) interfejsów Przedstawienie odwzorowania interfejsów związanych z zabezpieczeniem na zdefiniowane podsystemy Lista interfejsów związanych z zabezpieczeniami pochodzi z!materiału dowodowego dla ADV_FSP 43 Odwzorowanie interfejsów Podsystemy Przyporządkowanie interfejsów TSFI do poszczególnych podsystemów TOE 44
Przyporządkowanie funkcji zabezpieczających do interfejsów TSFI TSFI Funkcja zabezpieczająca Opis MCXdet:GAZ OADT.ErrorInfo TOE zapewnia wyświetlenie oraz przekazanie do systemu telemetrycznego informacji o błędach w działaniu detektorów gazowych (rozkalibrowanie, przekroczenia zakresu, zmiana czułości). SFDP.SensorDataCheck Sprawdzenie prawidłowości zapisu informacji i przesłanie informacji o zmianie parametrów do systemu telemetrycznego. SFDP.ErrorCheck TOE ma możliwość sprawdzenia swoich elementów i poinformowania o swoim stanie system telemetryczny, tak aby transmisja przetworzonych w podsystemie MCXcore danych pomiarowych, danych identyfikacyjnych oraz sygnałów ewentualnych awarii lub alarmów nie była zakłócona i zafałszowana. Funkcja zabezpieczająca nie sprawdza podłączenia klawiatury kalibracyjnej i nie informuje o stanie podsystemu MCX:klaw....... Fragment zestawienia funkcji zabezpieczających z interfejsami TSFI Lista funkcji zabezpieczających pochodzi z materiału dowodowego!dla ADV_ARC 45 Kluczowe elementy Dokładna dekompozycja TOE na podsystemy i interfejsy 46
Problem! EAL 4 EAL 2 47 Rodzina ADV_FSP Functional specification Specyfikacja funkcjonalności Zadania dokumentacji związanej z rodziną ADV_FSP: wyspecyfikowanie interfejsów związanych z TOE i z zabezpieczeniami (TSFI) opis interfejsów związanych z TOE i z zabezpieczeniami (TSFI) w szczegółowości uzależnionej od przynależności do kategorii interfejsów TSFI: 1. SFR-wymuszajace (SFR-enforcing) 2. SFR-wspomagające (SFR-supporting) 3. SFR-nie powiązane (SFR-non-interfering) 48
Rodzina ADV_FSP Struktura dokumentu - wzorca ADV_FSP Opis wymagań SFR dla TOE Lista interfejsów TOE Pokrycie wymagań SFR interfejsami 49 Rodzina ADV_FSP ADV_FSP Ogólny opis nawiązujący do wymagań na funkcjonalność związaną z zabezpieczeniami Opis wymagań SFR dla TOE Lista interfejsów TOE Pokrycie wymagań SFR interfejsami 50
[i] Opis wymagań SFR dla TOE [ii]. Opis wymagań SFR dla TOE przedstawiono w formie tabeli zawierającej nazwę wymagania oraz jego krótki opis. Nazwa wymagania jednoznaczny identyfikator zgodny i spójny z identyfikatorami przedstawionymi w dokumencie ST. Opis wymagania. W opisie należy zwrócić uwagę przede wszystkim na aspekty bezpieczeństwa. Opis może być kopią opisu wymagań SFR z dokumentu ST. Nazwa wymagania Opis wymagania FCO_NRO.2 Wymuszenie wygenerowania dowodu nadania. Wymuszenie wygenerowania dowodu nadania, potwierdzającego każde wysłanie informacji. FCO_NRR.2 Wymuszenie wygenerowania dowodu otrzymania. Wymuszenie wygenerowania dowodu potwierdzającego każde otrzymanie informacji. FDP_UIT.3 Odzyskiwanie utraconych danych bez pomocy źródła. Odzyskiwanie utraconych danych bez pomocy źródła obejmuje odzyskiwanie informacji po wystąpieniu błędu bez pomocy strony będącej źródłem informacji....... Fragment opisu wymagań SFR dla TOE czujnika gazometrycznego MCX.1.0 51 Rodzina ADV_FSP Lista interfejsów TSFI ADV_FSP Opis zawierający: klasyfikacja interfejsu przeznaczenie, sposób użycia, możliwe do ustawienia parametry i ich opis, możliwe do wykonania akcje, opis komunikatów dotyczących błędów Opis wymagań SFR dla TOE Lista interfejsów TOE Pokrycie wymagań SFR interfejsami 52
Lista interfejsów TSFI TOE MCXdet: GAZ Interfejs zewnętrzny transportu gazu do komory pomiarowej. MCXklaw: KLAWIATURA interfejs odpowiedzialny za przesyłanie danych z klawiatury kalibracyjnej do podsystemu MCXklaw. MCXtranzas: LINIA interfejs, którym przesyłane są dane pomiarowe, informacja o zaistniałych przekroczeniach progów alarmowych, dane identyfikacyjne czujnika, stan wejść/wyjść dwustanowych do systemu telemetrycznego. MCXwewy: WYJŚCIA interfejs zawierający wyjścia dwustanowe czujnika MCX. MCXwewy: WEJŚCIA interfejs zawierający wyjścia dwustanowe czujnika MCX. MCXcore: OBUDOWA interfejs pośredniczący w zabezpieczeniu przed nieautoryzowanym otwarciem obudowy, plomba zabezpieczająca dane i program w podsystemie MCXcore. 53 Opis interfejsu MCXdet:GAZ Klasyfikacja interfejsu - SFR-enforcing (SFRwymuszający), zabezpieczenie przed ingerencją szkodliwych związków chemicznych. Ogólny opis przeznaczenia - transportu gazu ze środowiska TOE do komory pomiarowej podsystemu MCXdet. Sposób użycia (realizacja funkcjonalności) - funkcje zabezpieczające poprawność wprowadzonych danych od interfejsu: kontrola napięcia zasilania detektora, kontrola sygnału pomiarowego detektora, porównanie z wartościami zapisanymi w pamięci, kontrola czasu życia detektora, kontrola temperatury, kompensacja termiczna. 54
Opis interfejsu MCXdet:GAZ Ustawienia parametrów wpływających na sposób działania funkcji lokalizacja oraz miejsce zainstalowania czujnika. Możliwe do wykonania akcje interfejsu realizowane wymagania SFR FCO_NRO.2 FCO_NRR.2 FDP_SDI.2 FPT_PHP.2 Opis parametrów: parametr lokalizacji, parametr stężenia metanu poniżej progu zadziałania wyłączenie energii, Parametr stężenia metanu powyżej progu zadziałania wyłączenie energii (>2%CH4). 55 Opis interfejsu MCXdet:GAZ Komunikaty błędów związane z interfejsem: flaga braku poprawnego napięcia zasilania dostarczanego do detektora pomiarowego, stan przekroczenia wartości sygnału napięciowego analogowego z detektora do wartości zapisanej w pamięci, flaga błędu weryfikacji sygnałów cyfrowych detektorów w podsystemie MCXdet, flaga przekroczenia czasu życia detektora, flaga błędu przekroczenia dozwolonej temperatury pracy, brak kompensacji termicznej (ciśnieniowej) detektorów. 56
Rodzina ADV_FSP ADV_FSP Informacje o powiązaniu wymagań SFR i interfejsów TSFI w formie tabeli Opis wymagań SFR dla TOE Lista interfejsów TOE Pokrycie wymagań SFR interfejsami 57 Pokrycie wymagań SFR interfejsami 58
Rodzina ADV_ARC Security Architecture Architektura zabezpieczeń Zadania dokumentacji związanej z rodziną ADV_ARC: Dostarczenie informacji związanych z architekturą TOE w kontekście zabezpieczeń zastosowanych w TOE 59 Rodzina ADV_ARC Struktura dokumentu - wzorca ADV_ARC Ogólny opis architektury Inicjalizacja funkcji zabezpieczeń TOE Domeny bezpieczeństwa w TOE Szczegółowy opis mechanizmów zabezpieczeń TOE Opis zabezpieczeń interfejsów 60
Rodzina ADV_ARC ADV_ARC Ogólny opis architektury Informacja o sposobie działania TOE, otoczeniu, wymaganych warunkach działania, możliwych do ustawienia parametrach. Odwołania do interfejsów, podsystemów Inicjalizacja funkcji zabezpieczeń TOE Domeny bezpieczeństwa w TOE Szczegółowy opis mechanizmów zabezpieczeń TOE Opis zabezpieczeń interfejsów 61 Ogólny opis architektury Przeznaczenie czujnika Budowa Podstawowe operacje wykonywane przez czujnik Sposób komunikacji z urządzeniami współpracującymi Definicja podmiotów związanych lub współpracujących z TOE oraz ich podział na użytkowników autoryzowanych (SA) i użytkowników nieautoryzowanych (SNA) Zdefiniowane zagrożenia, które mogą w negatywny sposób wpłynąć na bezpieczeństwo TOE 62
Rodzina ADV_ARC ADV_ARC Ogólny opis architektury Opis sposobu inicjalizacji funkcji zabezpieczających. Opis sposobu zabezpieczenia inicjalizacji. Inicjalizacja funkcji zabezpieczeń TOE Domeny bezpieczeństwa w TOE Szczegółowy opis mechanizmów zabezpieczeń TOE Opis zabezpieczeń interfejsów 63 Inicjalizacja funkcji zabezpieczeń TOE Sprawdzenie pod względem funkcjonalności czujnika przez producenta Po podłączeniu zasilania: 1. Przeprowadzenie samokontroli podsystemów TOE przez czujnik 2. Wysłanie ramki o statusie urządzenia do systemu dyspozytorskiego 3. Oczekiwanie na odpowiedź systemu 4. Wybór trybu pracy urządzenia 64
Rodzina ADV_ARC ADV_ARC Ogólny opis architektury Inicjalizacja funkcji zabezpieczeń TOE Domeny bezpieczeństwa w TOE Opis sposobu odseparowania od siebie zdefiniowanych domen Szczegółowy opis mechanizmów zabezpieczeń TOE Opis zabezpieczeń interfejsów 65 Domeny bezpieczeństwa w TOE Urządzenie MCX.1.0 nie jest podzielone na domeny bezpieczeństwa. Wynika to z jego zakresu funkcjonalności i budowy. 66
Rodzina ADV_ARC ADV_ARC Ogólny opis architektury Inicjalizacja funkcji zabezpieczeń TOE Opis mechanizmów zrealizowanych w TOE dotyczących zabezpieczeń Udowodnićże mechanizmy nie pozwalają ominąć funkcji zabezpieczeń Domeny bezpieczeństwa w TOE Szczegółowy opis mechanizmów zabezpieczeń TOE Opis zabezpieczeń interfejsów 67 Szczegółowy opis mechanizmów zabezpieczeń TOE SFDP.SensorDataCheck - kontrola prawidłowości zapisu informacji SFCO.CalibTransCheck - kontrola poprawności transmisji z klawiatury kalibracyjnej SFIA.IdentCheck - weryfikacja autoryzacji klawiatury kalibracyjnej oraz czujnika podłączanego na daną linie transmisyjną SFDP.TransCheck kontrola obecności transmisji SFDP.ErrorCheck funkcja samokontroli podsystemów TOE SFPT.OuterProt - zapewnie bezpieczeństwa przed zewnętrznymi czynnikami ludzkimi oraz czynnikami atmosferycznymi i środowiskowymi SFMT.TOESecur - mechanizmy zapobiegające nieautoryzowanemu otwarciu obudowy SFMT.Atex - do złącza zasilacza może być podpięte tylko zasilanie iskrobezpieczne o parametrach wyspecyfikowanych w dokumentacji TOE 68
Rodzina ADV_ARC ADV_ARC Ogólny opis architektury Inicjalizacja funkcji zabezpieczeń TOE Domeny bezpieczeństwa w TOE Szczegółowy opis mechanizmów zabezpieczeń TOE Opis zabezpieczeń interfejsów Opis wszystkich interfejsów powinien wykazać, że dostęp do zasobów chronionych jest niemożliwy niezależnie od wywołanego interfejsu 69 Opis zabezpieczeń interfejsów Mechanizm zabezpieczeń TSFI 70
Podsumowanie Zastosowanie wzorców pozwala na: skupienie uwagi konstruktora na wypełnianiu treścią merytoryczną wzorców, a nie na szczegółową analizę wymagań standardu; skrócenie czasu tworzenia materiału dowodowego; wymusza ciągłe weryfikowanie wyników pracy; poprawę kultury projektowania urządzeń; poprawę jakości tworzonej dokumentacji; automatyzację procesu tworzenia materiału dowodowego Dziękujemy za uwagę m.malachowski@emag.pl d.nowak@emag.pl