Wprowadzenie do metodyki projektowania i oceny zabezpieczeń według ISO/IEC Common Criteria

Transkrypt

1 Instytut Technik Innowacyjnych Wprowadzenie do metodyki projektowania i oceny zabezpieczeń według ISO/IEC Common Criteria dr inż. A. Białas Nr projektu: UDA POIG /08-00 Akronim projektu: CCMODE Plan prezentacji Podstawy uzasadnionego zaufania Standard ISO/IEC Common Criteria Kreowanie zaufania do zabezpieczeń Komponenty funkcjonalne i uzasadniające zaufanie Konstruowanie zabezpieczeń i przedmiotu oceny Poziomy uzasadnionego zaufania (EAL) Materiał dowodowy wypracowywany do oceny Stosowanie standardu Common Criteria, certyfikacja Współpraca międzynarodowa 2 1

2 Wprowadzenie dziedzina Tematyka dotyczy konstruowania produktów informatycznych (sprzętu, oprogramowania, w tym układowego) oraz zbudowanych z nich systemów informatycznych, zwanych ogólnie przedmiotami oceny (TOE Target of Evaluation), które posiadają jakiekolwiek zabezpieczenia swych funkcji użytkowych, czyli mają zaimplementowane funkcje zabezpieczające (SF Security Functions), a które to zabezpieczenia powinny cechować się tak zwanym uzasadnionym zaufaniem assurance przekonanie, że produkt/system IT, zwany TOE, spełnia wyspecyfikowane dla niego cele zabezpieczeń (czyli, że zabezpieczenia zadziałają ) 3 Co może być przedmiotem oceny? środki sprzętowe, np. kryptoprocesory, oprogramowanie (w tym układowe), np. szyfrator plików, ich kombinacja, np. system operacyjny współpracujący z kartami inteligentnymi, czy tak zwane systemy wbudowane programy użytkowe, aplikacje, np. bazodanowe, narzędzia do rozwoju produktów, całe systemy. ang. TOE Target of Evaluation UWAGA: Nie są to zawsze typowe produkty bezpieczeństwa! Wszelkie wytwory informatyków od prostych edytorów tekstu po systemy dystrybucji kluczy kryptograficznych dla komputerów kwantowych 4 2

3 "Filozofia" Wspólnych kryteriów użytkownik TOE Środowisko TOE zagrożenia Spełniające wymagania bezpieczeństwa, wypracowane z celów na zabezpieczenia, na podstawie analizy potrzeb użytkownika oraz analizy środowiska eksploatacji TOE Funkcje zabezpieczające można realizować w różny sposób Rygoryzm Uzasadnione zaufanie (EAL1-EAL7) Koszty również Uzasadnione zaufanie dla TOE podczas konstruowania, oceny i eksploatacji 5 Wspólne Kryteria CC - Common Criteria (ISO/IEC 15408) podstawą dla kreowania uzasadnionego zaufania ISO/IEC (CC Part 1): Introduction and General Model (Wprowadzenie i model ogólny) ISO/IEC (CC Part 2): Security Functional Requirements (Wymagania na funkcjonalność zabezpieczeń) ISO/IEC (CC Part 3): Security Assurance Requirements (Wymagania dotyczące uzasadnienia zaufania do zabezpieczeń) ISO/IEC TR IT Security techniques Guide for the production of protection profiles and security targets (IT techniki zabezpieczeń przewodnik tworzenia profili zabezpieczeń i zadań zabezpieczeń) CEM - Common Evaluation Methodology for Information Technology Security (Metodyka oceny zabezpieczeń teleinformatycznych) Podstawą uzasadnionego zaufania jest rygorystyczny proces konstruowania, wytwarzania, eksploatacji TOE, potwierdzony wnikliwą i niezależną oceną przeprowadzoną z wykorzystaniem kryteriów oceny zabezpieczeń. 6 3

4 Podstawowe pojęcia Przedmiot oceny (ang. TOE - Target of Evaluation) - produkt lub system informatyczny wraz z dokumentacją, Zadanie zabezpieczeń (ang. ST - Security Target) - zbiór wymagań bezpieczeństwa, ukierunkowany na określony sposób implementacji, Profil zabezpieczeń (ang. PP - Protection Profile) - zbiór wymagań dotyczących zabezpieczeń, niezależny od sposobu implementacji, Uzasadnione zaufanie (ang. assurance) - podstawa do zaufania, że oceniana jednostka realizuje zdefiniowane dla niej cele zabezpieczeń, Poziom uzasadnionego zaufania (ang. EAL Evaluation Assurance Level). Pakiet (ang. package) - grupuje wymagania dotyczące pewnego podzbioru celów zabezpieczeń i służy do wielokrotnego wykorzystania (np. pakiety EAL, CAP) 7 Kreowanie zaufania do zabezpieczeń Techniki kreowania uzasadnienia zaufania Właściciel Dostarczenie podstaw do przekonania, że zabezpieczenia są wystarczające, by móc wyeksponować zasoby w środowisku zagrożeń tworzą żąda poprzez Uzasadnienie zaufania daje poczucie Zaufanie zmniejszające pozwala dowieść Zabezpieczenia dla Ocena (ewaluacja) Ryzyko Jaka jest gwarancja, że zabezpieczenia zadziałają? Od czego to zależy? Zasoby 8 4

5 Klasy komponentów funkcjonalnych Klasa FAU FCO FCS FDP FIA FMT FPR FPT FRU FTA FTP Nazwa pełna Audyt bezpieczeństwa rejestracja zdarzeń (ang. Security audit) Transmisja (ang. Communication) Ochrona kryptograficzna (ang. Cryptographic support) Ochrona danych użytkownika (ang. User data protection) Identyfikacja i uwierzytelnianie (ang. Identification and authentication) Zarządzanie bezpieczeństwem (ang. Security management) Prywatność (ang. Privacy) Ochrona funkcji zabezpieczających (ang. Protection of the TSF) Wykorzystanie zasobów (ang. Resource utilisation) Dostęp do TOE (ang. TOE access) Wiarygodne ścieżki i kanały (ang. Trusted path/channels) 9 Klasy komponentów uzasadniających zaufanie Klasa ACO APE ASE ADV AGD ALC ATE AVA Nazwa pełna Systemy złożone (ang. Composition) Ocena dokumentu PP (ang. Protection Profile evaluation) Ocena dokumentu ST (ang. Security Target evaluation) Prace badawcze i rozwojowe (ang. Development) Dokumentacja (ang. Guidance documents) Wsparcie cyklu życia produktu (ang. Life cycle support) Testowanie (ang. Tests) Oszacowanie podatności (ang. Vulnerability assessment) 10 5

6 Wymagania użytkowe Wymagania na zabezpieczenia i funkcje zab. Analizy zgodności, testy integracyjne Specyfikacja funkcjonalna Projekt ogólny (wysokiego poziomu) Konstruowanie TOE i jego zabezpieczeń Konstruowanie zabezpieczeń TOE opracowanie zadania zabezpieczeń (ST-Security Target) Szczegółowość etapów konstruowania TOE zależy od poziomu EAL (Evaluation Assurance Level) Kody źródłowe, schematy elektroniczne,... Implementacja 11 Konstruowanie zabezpieczeń przykład System zaporowy MyFwl Chroniona sieć prywatna chronione zasoby? nasz TOE Sieć publiczna źródło zagrożeń 1. Wprowadzenie do zadania zabezpieczeń (ST Introduction) 2. Identyfikacja problemu bezpieczeństwa (Security problem definition) 3. Deklaracje zgodności (Conformance claims) 4. Wypracowanie i uzasadnienie celów na zabezpieczenia dla TOE i jego środowiska (Security objectives /rationale) 5. Zdefiniowanie komponentów rozszerzających (Extended components definition) 6. Wypracowanie i uzasadnienie wymagań bezpieczeństwa (SFR/SAR /rationale) 7. Wypracowanie i uzasadnienie Środowisko rozwojowe funkcji produktów zabezpieczających, i systemów informatycznych czyli specyfikacji końcowej TOE (TSS TOE Summary Specification) 12 6

7 Blok rejestracji i kontroli zdarzeń: F.AuditFacilities Funkcje zabezpieczające schemat blokowy MyFwl Chroniona sieć prywatna Sieć publiczna źródło zagrożeń Blok kontroli zakresu adresów IP: F.LmtIPAddr Blok kontroli numerów portów: F.LmtPortHost Blok bramy aplikacji: F.OnProxyAuth Administrator Systemu MyFwl Blok uwierzytelnienia administratora F.AdminAuth Objaśnienia: Blok zarządzania F.FirewallManagement 13 Strumień informacji kontrolowany Środowisko rozwojowe przez produktów MyFwl i systemów informatycznych Wewnętrzne informacje kontrolno-sterujące MyFwl Interpretacja poziomów uzasadnionego zaufania EAL7 oznacza, że projekt TOE jest formalnie weryfikowany i testowany (ang. formally verified design and tested), EAL6 oznacza, że projekt TOE jest półformalnie weryfikowany i testowany (ang. semiformally verified design and tested), EAL5 oznacza, że TOE jest półformalnie projektowany i testowany (ang. semiformally designed and tested), EAL4 oznacza, że TOE jest metodycznie projektowany, testowany i przeglądany (ang. methodically designed, tested and reviewed), EAL3 oznacza, że projekt TOE jest metodycznie sprawdzany i testowany (ang. methodically tested and checked), EAL2 oznacza, że TOE jest testowany strukturalnie (ang. structurally tested), EAL1 oznacza, że TOE jest testowany funkcjonalnie (ang. functionally tested). 14 7

8 Komponent ADV_TDS.1 Wytyczne do konstruowania TOE materiał dowodowy na uzasadnienie zaufania do zabezpieczeń Klasa ADV AGD ALC ATE Poziom uzasadnionego zaufania Rodzina EAL1 EAL2 EAL3 EAL4 EAL5 EAL6 EAL7 ADV_ARC ADV_FSP ADV_IMP ADV_INT ADV_SPM 1 1 ADV_TDS AGD_OPE AGD_PRE ALC_CMC ALC_CMS ALC_DEL ALC_DVS ALC_FLR opcjonalne dla dowolnego EAL ALC_LCD ALC_TAT ATE_COV ATE_DPT ATE_FUN ATE_IND AVA AVA_VAN o podwyższonych 1 wymaganiach 2 bezpieczeństwa Czym jest materiał dowodowy dla EALn? Konstruktor powinien wypracować materiał dowodowy potwierdzający, że wymagania zadeklarowanego EALn są spełnione, zaś niezależny oceniający powinien ten materiał wnikliwie zbadać. dokumentacja, np. plan zarządzania konfiguracją (potwierdza on fakt, że opracowano go dla TOE, zaś jego zawartość jest zgodna z treścią odpowiednich komponentów), podręcznik użytkownika lub administratora TOE, procedury instalacji lub kalibracji urządzenia, dokumentacja opisująca cykl życia TOE, wynik niezależnych badań lub obserwacji, np. raport dotyczący analizy podatności środowiska lub TOE, raport z niezależnego testowania TOE, raport z inspekcji środowiska rozwojowego przeprowadzonej przez oceniających, czy też lista rankingowa przypadków ryzyka zidentyfikowanych w środowisku rozwojowym, dokument potwierdzający zachowanie lub postępowanie, np. stosowanie procedury akceptacji produktu wytwarzanego w środowisku przed wysłaniem do klienta; oczywiście sama procedura też jest materiałem dowodowym dokumentem, lecz w tym przypadku chodzi o jeszcze inny rodzaj dowodu, dowodu który ma świadczyć, że samo zachowanie lub postępowanie, np. osoby pełniącej w środowisku określoną rolę jest właściwe; dowodem może być też protokół akceptacji czy tak zwane zapisy (ang. records). 16 8

9 Materiał dowodowy środowisko rozwoju Life-cycle Definition (ALC_LCD) definicja modelu cyklu życia informacje i działania (role personelu i podwykonawców, jak również stosowane procedury, narzędzia i techniki) towarzyszące rozwijanemu w środowisku produktowi lub systemowi we wszystkich fazach życia od powstania jego koncepcji, konstrukcji, wersji produkcyjnej, serwisowanej i utrzymywanej dla klienta, po końcową likwidację produktu Przykład cyklu życia tachografu cyfrowego z dokumentu: Annex 1B of Commission Regulation (EC) No.1360/2002 on recording equipment in road transport: Requirements for Construction, Testing, Installation and Inspection (in: Official Journal of the European Communities, L 207 / 1 ff.), Commission of the European Communities, Środowisko rozwojowe , produktów i systemów informatycznych appendix 10, chapter Materiał dowodowy środowisko rozwoju Configuration Management Capabilities (ALC_CMC) system zarządzania konfiguracją precyzyjne kontrolowanie wersji i elementów konfiguracji produktu, by wersja dostarczana dla klienta była zgodna z wersją poddaną wcześniej procesowi certyfikacji plan zarządzania konfiguracją z uwzględnieniem różnych faz cyklu życia i jego realizacja automatyczne generowanie wersji dystrybucyjnej produktu (od EAL4) komputerowo wspomagany system zarządzania konfiguracją z rejestracją śladu operacji Configuration Management Scope (ALC_CMS) zbiór elementów konfiguracji zarządzanych i służących do tworzenia list konfiguracji fizyczne i logiczne składniki produktu i jego dokumentacji, oprogramowanie lub urządzenia wykorzystywane w procesie rozwoju, komplet materiału dowodowego dla produktu lub systemu, 18 raporty dotyczące usuwania Środowisko błędów, rozwojowe reprezentacja produktów i systemów implementacji, informatycznych (kody źródłowe, pliki nagłówkowe, schematy elektroniczne, itp.) 9

10 Materiał dowodowy środowisko rozwoju Tools and Techniques (ALC_TAT) narzędzia i techniki służące do rozwoju, wytwarzania, utrzymywania i likwidowania produktu lub systemu informatycznego przedstawienie sposobu ich wykorzystania ze szczególnym uwzględnieniem opcji, które mogłyby wpływać na wieloznaczność osiąganych wyników, np. przy kompilacji Delivery Procedures (ALC_DEL) procedury dostawy zestaw procedur rządzących dystrybucją produktu do klientów Development Security (ALC_DVS) bezpieczeństwo środowiska rozwoju zabezpieczenia (fizyczne, proceduralne, osobowe, techniczne) stosowane w środowisku rozwojowym i podlegające zarządzaniu i służące do ochrony informacji dotyczących realizowanych projektów 19 Materiał dowodowy środowisko rozwoju Flaw Remediation (ALC_FLR) zarządzanie usuwaniem usterek system (procedury/procesy, narzędzia informatyczne, praktyki) odpowiedzialny za raportowanie usterek i błędów związanych z bezpieczeństwem, za ich analizę oraz śledzenie statusu usterek podczas ich naprawy Vulnerability Analysis (AVA_VAN) analiza podatności analiza podatności możliwych do wprowadzenia do TOE podczas rozwoju (np. możliwość omijania zabezpieczeń, czy też manipulacji bezpośredniej) lub eksploatacji (np. celowe lub pomyłkowe ustawienie niewłaściwych parametrów konfiguracyjnych) 20 10

11 Materiał dowodowy produkt lub system TOE Design (ADV_TDS) szczegółowość projektu dekompozycja TOE na podsystemy i moduły reprezentujące funkcje zabezpieczające Functional Specification (ADV_FSP) specyfikacja funkcjonalna określa interfejs TOE, jego podsystemów i modułów Kategorie interfejsów, podsystemów i modułów: interfejsy /podsystemy /moduły wymuszające spełnienie wymagań funkcjonalnych związanych z daną funkcją (ang. SFR enforcing interfaces /subsystems /modules), interfejsy /podsystemy /moduły wspomagające spełnienie wymagań funkcjonalnych przez funkcje (ang. SFR supporting interfaces /subsystems /modules), interfejsy /podsystemy /moduły nie mające związku z funkcjami zabezpieczającymi (ang. SFR noninterfering interfaces /subsystems /modules), tzn. niezwiązane z funkcjonalnością zabezpieczeń (np. pewne użytkowe). szczegółowość specyfikacji podsystemu lub modułu zależy silnie od ww. kategorii i od poziomu EAL (od opisu na poziomie bloków, przez opis interakcji, po dokładne struktury danych i opis algorytmu działania) szczegółowość specyfikacji interfejsu zależy od kategorii i od poziomu EAL (przeznaczenie, metoda użycia, 21 parametry i ich opis, czynności, Środowisko kody błędów rozwojowe oraz produktów odwzorowanie i systemów na informatycznych funkcjonalne wymagania bezpieczeństwa) Materiał dowodowy produkt lub system Implementation Representation (ADV_IMP) reprezentacja realizacji projektu specyfikacja kodów źródłowych, zbiorów nagłówkowych, schematów elektronicznych, itp., stanowiących reprezentację logiczną podsystemów i ich modułów Security Architecture (ADV_ARC) bezpieczeństwo architektury opis samoistnych lub specjalnie zaimplementowanych własności architektury, wykorzystywanych do ochrony funkcji zabezpieczających (wyróżnienie domen bezpieczeństwa, inicjalizacja urządzenia po włączeniu zasilania lub wystąpieniu określonego zdarzenia, mechanizmy ochrony przed manipulacją bezpośrednią, omijaniem zabezpieczeń) TSF Internals (ADV_INT) organizacja i poprawność struktury wewnętrznej (od EAL5) ocena wewnętrznej struktury funkcji zabezpieczających z punktu widzenia ich poprawności, przejrzystości i prostoty ( well structured ) pewnego ładu w konstrukcji 22 11

12 Materiał dowodowy produkt lub system Security Policy Modeling (ADV_SPM) formalny model polityki bezpieczeństwa (od EAL6) model reguł polityki bezpieczeństwa (wymagający dowodu matematycznego), pokazujący związki z wymaganiami funkcjonalnymi w kontekście paradygmatu funkcjonalnego Operational User Guidance (AGD_OPE) dokumentacja dla użytkowników dedykowane wersje dokumentacji użytkowej dla poszczególnych grup (ról) użytkowników TOE Preparative Procedures for the TOE (AGD_PRE) procedury instalacji i uruchomienia produktu lub systemu informatycznego procedury dotyczące przygotowania produktu lub systemu informatycznego do eksploatacji (dopuszczenia do eksploatacji, przygotowania do instalacji, samej instalacji i uruchomienia) 23 Materiał dowodowy produkt lub system Functional Tests (ATE_FUN) testy funkcjonalne dokładna specyfikacja testów funkcjonalnych oraz opis wyników testowania plany testowania i raporty Coverage of Tests (ATE_COV) kompletność testów funkcjonalnych wykazanie, że funkcje zabezpieczające i ich własności zostały pokryte odpowiednimi testami Depth of Tests (ATE_DPT) szczegółowość testów z uwzględnieniem struktury wykazanie, że podsystemy i ich moduły, na które zdekomponowano funkcje zabezpieczające, zostały pokryte testami Independent Testing (ATE_IND) testowanie niezależne eksperci z laboratorium Środowisko oceny rozwojowe powtarzają produktów lub i systemów uzupełniają informatycznych niektóre testy zawarte w przedłożonym przez konstruktorów materiale dowodowym i porównują osiągnięte wyniki 24 12

13 Struktura komponentu a materiał dowodowy Element D (ang. Developer Action Element) - jaki artefakt (dowód na spełnienie wymagania wyrażonego przez komponent) konstruktor powinien dostarczyć, na przykład opracować określony dokument lub jego część, Element C (Content and Presentation of Evidence Element) jaką postać powinien mieć i co ma zawierać ten artefakt Element E (ang. Evaluator Action Element) w jaki sposób dostarczony element o określonej postaci będzie sprawdzany przez oceniającego Przykład 1: Użycie ATE_DPT.2 (od EAL4) nakazuje konstruktorowi dostarczenie dowodu, że podsystemy i ich moduły typu SFR enforced, na które zdekomponowano TOE, zostały właściwie przetestowane. ATE_DPT.2.1D The developer shall provide the analysis of the depth of testing, ATE_DPT.2.1C The analysis of the depth of testing shall demonstrate the correspondence between the tests in the test documentation and the TSF subsystems and SFR-enforcing modules in the TOE design, ATE_DPT.2.2C The analysis of the depth of testing shall demonstrate that all TSF subsystems in the TOE design have been tested, ATE_DPT.2.3C The analysis of the depth of testing shall demonstrate that the SFR-enforcing modules in the TOE design have been tested. 25 ATE_DPT.2.1E The evaluator shall Środowisko confirm rozwojowe that the produktów information i systemów provided informatycznych meets all requirements for content and presentation of evidence. Przykład: Dekompozycja TOE (wg ADV_TDS.2) Podsystem B Interf#5 Interf#6 Moduł B1 Moduł B2 Podsystem A Interfejs podsystemu B Interfejs zewnętrzny TOE (TSFI) Moduł A1 Moduł A2 Interf#3 Moduł A3 Interf#1 Interf#2 Interf#4 Interfejs podsystemu A Interfejs podsystemu C Interf#9 Interf#7 Moduł C1 Moduł C3 Podsystem C Interf#8 Moduł C

14 Przykład: Głębokość testowania TOE (wg ATE_DPT.2) ADV_TDS ADV_FSP Nazwa testu Podsystem A Podsystem B Podsystem C Moduły typu SFR enforcing Podsystemu A Moduł A1 Moduł A2 Moduł A3 T-1 X X Moduły typu SFR enforcing Podsystemu B Moduł B1 Moduł B2 Moduły typu SFR enforcing Podsystemu C Moduł C1 Moduł C2 Moduł C3 T-2 X X T-3 X T-4 T-5 X X X X T-6 X Wymaga to precyzyjnego uzasadnienia! T-7 X T-8 X 27 T-9 X Ocena i certyfikacja zabezpieczeń Certyfikacja: ocena środków IT prowadzona przez niezależną instytucję wg uzgodnionych procedur i kryteriów, w zakresie spełnienia zakładanych wymagań dotyczących poufności, integralności i dostępności informacji, poświadczająca, że przedmiot oceny (TOE): realizuje prawidłowo określone funkcje bezpieczeństwa występują w nim pożądane zachowania, posiada mierzalny poziom wiarygodności zaufania, brak w nim niepożądanych zachowań (EAL)

15 Rodzaje ocen prowadzących do certyfikacji Ocena towarzysząca powstawaniu produktu lub systemu najefektywniejsza, ponieważ wszelkie błędy korygowane są we wczesnym stadium rozwoju produktu Ocena gotowego produktu lub systemu duże ryzyko, ponieważ wady produktu mogą być trudne do usunięcia Powtórna ocena nowej wersji produktu lub systemu recertyfikacja 29 Korzyści płynące z oceny i certyfikacji Staranne projektowanie i dokumentowanie produktu Redukcja ryzyka stosowania środków IT Wzrost zaufania do produktu zwłaszcza po ocenie prowadzonej w trakcie tworzenia produktu Ocenione produkty częściej są wykorzystywane do budowy bezpiecznych, złożonych systemów IT Ułatwienie użytkownikom wyboru i zakupu produktów IT o właściwie dobranym poziomie bezpieczeństwa Wejście na obce rynki (zasięg międzynarodowy standardu) 30 15

16 Ograniczenia CC nie obejmują zabezpieczeń administracyjnych (personalnych, organizacyjnych) nie pozwalają oceniać tego typu zabezpieczeń, jednak uwzględniają je w formie tzw. założeń podczas oceny nie uwzględniają zabezpieczeń fizyko-technicznych związanych z emisją ujawniającą w ograniczonym zakresie uwzględniają zabezpieczenia fizyczne, posiłkując się zaleceniami pomocniczymi nie przedstawiają w pełni tak zwanego kontekstu oceny (metodyka oceny wraz z otaczającą ją strukturą prawno - administracyjną), ale są jego elementem, w ramach którego to kontekstu mogą być one stosowane przez organy nadzorujące oceny nie przedstawiają procedury użycia wyników oceny do akredytacji produktu lub systemu (akredytacja jest działaniem administracyjnym, prowadzącym do wydania decyzji o zezwoleniu na eksploatację produktu lub systemu teleinformatycznego w jego środowisku rzeczywistym) 31 Do czego mogą służyć Wspólne Kryteria? Definicja kryteriów będących podstawą oceny właściwości zabezpieczeń produktów i systemów IT Możliwość porównania wyników ocen produktów Poradnik konstruowania produktów lub systemów posiadających funkcje zabezpieczające 32 16

17 Kto może korzystać z ISO/IEC 15408? Konsumenci raporty z przebiegu ocen pomagają dobrać właściwy produkt, który zaspokoi wymagane potrzeby bezpieczeństwa Twórcy produktów mogą precyzyjnie określać wymagania bezpieczeństwa oraz wyrażać i oceniać funkcjonalność zabezpieczeń Oceniający mogą jednoznacznie formułować osądy na temat zgodności produktu z wymaganiami na zabezpieczenia Administratorzy otrzymują wytyczne co do eksploatacji produktów i inni: audytorzy, architekci zabezpieczeń, akredytujący systemy, nadzorujący ocenę, sponsorzy 33 Współpraca międzynarodowa CCRA (Common Criteria Recognition Arrangement) 13 Krajów przodujących (Certificate Authorizing) posiadają wdrożone schematy i laboratoria oceny (liczby w nawiasach) Australia i Nowa Zelandia (3) Japonia (4) Hiszpania (3) Kanada (3) Republika Korei (5) Szwecja (2) Francja (5) Holandia (1) Wielka Brytania (4) Niemcy (12) Norwegia (3) USA (9) Włochy (0) Kraje wdrażające (Certificate Consuming) uznające certyfikaty (12) Austria, Czechy, Dania, Finlandia, Grecja, Węgry, Indie, Izrael, Malezja, Pakistan, Singapur oraz Turcja Polska nie uczestniczy w tych gremiach Portal Common Criteria:

18 Liczba certyfikowanych produktów i systemów informatycznych Według informacji zawartych na portalu stan na dzień : certyfikaty uzyskało 1156 produktów lub systemów informatycznych zarejestrowano 158 profili zabezpieczeń Liczba produktów lub systemów/liczba profili z podziałem na kategorie: Access Control Devices and Systems (61/4) Boundary Protection Devices and Systems (97/20) Data Protection (54/4) Databases (48/6) Detection Devices and Systems (27/12) Products for Digital Signatures (55/12) ICs, Smart Cards and Smart Card related Devices and Systems (295/41) Key Management Systems (29/2) Network and Network related Devices and Systems (101/14), Operating systems (96/10) Biometric Systems and Devices (1/4) Other Devices and Systems (296/32) 35 Certyfikowane produkty i systemy IT ( ) EAL Total EAL EAL EAL EAL EAL EAL EAL EAL EAL EAL EAL EAL EAL Total

19 Zarejestrowane profile zabezpieczeń ( ) EAL Total EAL EAL EAL EAL EAL EAL EAL EAL EAL EAL EAL Total Podsumowanie CC a rutynowe działania inżynierskie Metodyka Common Criteria (CC) jest podstawową, kompleksową, dojrzałą, ale i ciągle doskonaloną, metodyką kreowania podstaw zaufania do produktów i systemów informatycznych Proces konstruowania zabezpieczeń wg CC, jest utożsamiany z opracowaniem dokumentu zadania zabezpieczeń (ST Security Target) daje w wyniku zbiór funkcji zabezpieczających Dany zbiór funkcji zabezpieczających można implementować na różnym poziomie uzasadnionego zaufania (EAL1 EAL7) Poziom ten zależy od rygoryzmu zastosowanego wobec TOE i środowiska rozwoju, wytwarzania i eksploatowania TOE (w cyklu życia) Czy wolą Państwo powierzać swoje interesy produktom i systemom IT tworzonym ad hoc, czy też produktom i systemom: rozwijanym i wytwarzanym w środowiskach odpowiednio przygotowanych i zarządzanych, wyczerpująco przetestowanych, o zbadanych podatnościach, odpowiednio udokumentowanych, poddanych ocenie w niezależnym i akredytowanym laboratorium? 38 19

20 Dziękuję za uwagę 39 20