Wspólne kryteria - Common Criteria

Do Wspólne Kryteria oceny bezpieczeństwa technologii informacyjnych (dalej Common Criteria lub CC ) jest międzynarodowym standardem ( ISO / IEC 15408) dla bezpieczeństwa komputerowego certyfikacji. Obecnie jest w wersji 3.1, rewizja 5.

Common Criteria to struktura, w której użytkownicy systemów komputerowych mogą określić swoje wymagania funkcjonalne i bezpieczeństwa (odpowiednio SFR i SAR) w celu bezpieczeństwa (ST) i mogą być pobierane z profili ochrony (PP). Sprzedawcy mogą następnie wdrażać lub składać oświadczenia dotyczące atrybutów bezpieczeństwa swoich produktów, a laboratoria testujące mogą oceniać produkty, aby określić, czy rzeczywiście spełniają te oświadczenia. Innymi słowy, Common Criteria daje pewność, że proces specyfikacji, implementacji i oceny produktu bezpieczeństwa komputerowego został przeprowadzony w sposób rygorystyczny, standardowy i powtarzalny na poziomie współmiernym do docelowego środowiska użytkowania. Common Criteria prowadzi listę certyfikowanych produktów, w tym systemów operacyjnych, systemów kontroli dostępu, baz danych i systemów zarządzania kluczami.

Kluczowe idee

Oceny Common Criteria są przeprowadzane na produktach i systemach bezpieczeństwa komputerowego.

  • Target of Evaluation (TOE)  – produkt lub system będący przedmiotem oceny. Ocena służy do weryfikacji twierdzeń dotyczących celu. Aby mieć praktyczne zastosowanie, ocena musi zweryfikować zabezpieczenia obiektu docelowego. Odbywa się to w następujący sposób:
    • Profil Ochrony (PP)  – dokument, zwykle tworzony przez użytkownika lub społeczność użytkowników, który identyfikuje wymagania bezpieczeństwa dla klasy urządzeń zabezpieczających (na przykład karty inteligentne używane do dostarczania podpisów cyfrowych lub zapory sieciowe ) istotne dla tego użytkownika dla szczególny powód. Sprzedawcy produktów mogą zdecydować się na wdrożenie produktów, które są zgodne z jednym lub większą liczbą PP, a ich produkty zostaną ocenione pod kątem tych PP. W takim przypadku PP może służyć jako szablon dla ST produktu (cel bezpieczeństwa, jak zdefiniowano poniżej) lub autorzy ST zapewnią przynajmniej, że wszystkie wymagania w odpowiednich PP również pojawią się w dokumencie ST celu. Klienci poszukujący określonych rodzajów produktów mogą skoncentrować się na tych, które posiadają certyfikat PP spełniający ich wymagania.
    • Security Target (ST)  – dokument, który identyfikuje właściwości bezpieczeństwacelu oceny. ST może twierdzić, że jest zgodny z jednym lub więcej PP. TOE jest oceniany na podstawie SFR (Wymagań Funkcjonalnych Bezpieczeństwa. Znowu, patrz poniżej) ustalonych w jego ST, ni mniej, ni więcej. Dzięki temu dostawcy mogą dostosować ocenę tak, aby dokładnie odpowiadała zamierzonym możliwościom ich produktu. Oznacza to, że zapora sieciowa nie musi spełniać tych samych wymagań funkcjonalnych cosystem zarządzania bazami danych , a różne zapory mogą w rzeczywistości być oceniane pod kątem zupełnie różnych list wymagań. ST jest zwykle publikowany, aby potencjalni klienci mogli określić konkretne funkcje bezpieczeństwa, które zostały certyfikowane w ramach oceny.
    • Wymagania funkcjonalne zabezpieczeń (SFR)  – określają poszczególne funkcje bezpieczeństwa, które może zapewnić produkt. Common Criteria przedstawia standardowy katalog takich funkcji. Na przykład SFR może określać, w jaki sposób użytkownik pełniący określoną rolę może zostać uwierzytelniony . Lista SFR może się różnić w zależności od oceny, nawet jeśli dwa cele są tym samym rodzajem produktu. Chociaż Common Criteria nie zaleca uwzględniania żadnych SFR w ST, identyfikuje zależności, w których prawidłowe działanie jednej funkcji (takie jak możliwość ograniczenia dostępu zgodnie z rolami) jest zależne od innej (takiej jak możliwość identyfikacji poszczególnych ról ).

Proces oceny ma również na celu ustalenie poziomu zaufania, jaki można umieścić w zabezpieczeniach produktu poprzez procesy zapewniania jakości :

  • Security Assurance Requirements (SARs)  – opis środków podjętych podczas rozwoju i oceny produktu w celu zapewnienia zgodności z deklarowaną funkcjonalnością bezpieczeństwa. Na przykład ocena może wymagać przechowywania całego kodu źródłowego w systemie zarządzania zmianami lub wykonania pełnego testowania funkcjonalnego. Common Criteria zawiera ich katalog, a wymagania mogą się różnić w zależności od oceny. Wymagania dotyczące poszczególnych celów lub rodzajów produktów są udokumentowane odpowiednio w ST i PP.
  • Evaluation Assurance Level (EAL)  – ocena liczbowa opisująca głębokość i rygoryzm oceny. Każdy EAL odpowiada pakietowi wymagań dotyczących zapewnienia bezpieczeństwa (SARs, patrz powyżej), które obejmują pełne opracowanie produktu o określonym poziomie rygorystyczności. Common Criteria wymienia siedem poziomów, przy czym EAL 1 jest najbardziej podstawowym (a zatem najtańszym do wdrożenia i oceny), a EAL 7 jest najbardziej rygorystycznym (i najdroższym). Zwykle autor ST lub PP nie wybiera indywidualnie wymagań dotyczących zapewnienia, ale wybiera jeden z tych pakietów, ewentualnie „rozszerzając” wymagania w kilku obszarach o wymagania z wyższego poziomu. Wyższe EALs nie musi oznaczać „lepsze zabezpieczenia”, mają na myśli tylko to, że twierdził, zapewnienie bezpieczeństwa TOE został szerzej zweryfikowane .

Do tej pory większość PP i najczęściej oceniane ST/certyfikowane produkty dotyczyły komponentów IT (np. zapory ogniowe, systemy operacyjne , karty inteligentne). Certyfikacja Common Criteria jest czasami określana dla zamówień IT. Inne normy zawierające np. interoperacyjność, zarządzanie systemem, szkolenie użytkowników, uzupełniają CC i inne normy produktowe. Przykłady obejmują ISO/IEC 27002 ) i niemiecką podstawową ochronę IT .

Szczegóły implementacji kryptograficznej w TOE są poza zakresem CC. Zamiast tego standardy krajowe, takie jak FIPS 140-2 , podają specyfikacje modułów kryptograficznych, a różne standardy określają używane algorytmy kryptograficzne.

Niedawno autorzy PP włączyli wymagania kryptograficzne dla ocen CC, które zazwyczaj byłyby objęte ocenami FIPS 140-2, poszerzając granice CC poprzez interpretacje specyficzne dla schematu.

Niektóre krajowe systemy oceny wycofują oceny oparte na EAL i akceptują do oceny tylko produkty, które wykazują ścisłą zgodność z zatwierdzonym PP. Stany Zjednoczone obecnie dopuszczają wyłącznie oceny oparte na PP. Kanada jest w trakcie wycofywania ocen opartych na EAL.

Historia

CC wywodzi się z trzech standardów:

  • ITSEC  – Europejski standard, opracowany na początku lat 90. przez Francję, Niemcy, Holandię i Wielką Brytanię. Był to również ujednolicenie wcześniejszych prac, takich jak dwa podejścia brytyjskie (system oceny CESG UK skierowany do rynku obronności/wywiadu oraz zielona księga DTI mający na celu wykorzystanie komercyjne) i został przyjęty przez niektóre inne kraje, np. Australię.
  • CTCPEC  – standard kanadyjski był następstwem standardu amerykańskiego Departamentu Obrony, ale uniknął kilku problemów i był używany wspólnie przez oceniających zarówno z USA, jak i Kanady. Norma CTCPEC została po raz pierwszy opublikowana w maju 1993 roku.
  • TCSEC  – Departament Obrony Stanów Zjednoczonych DoD 5200.28 Std, zwany Pomarańczową Księgą i częściami Rainbow Series . Pomarańczowa Księga wywodzi się z prac związanych z bezpieczeństwem komputerowym, w tym Raportu Andersona, sporządzonego przez Narodową Agencję Bezpieczeństwa i Narodowe Biuro Standardów (NBS ostatecznie przekształciło się w NIST ) pod koniec lat siedemdziesiątych i na początku lat osiemdziesiątych. Główna teza Pomarańczowej Księgi wynika z pracy Dave'a Bella i Lena LaPaduli nad zestawem mechanizmów ochronnych.

CC został stworzony przez ujednolicenie tych wcześniej istniejących standardów, głównie po to, aby firmy sprzedające produkty komputerowe na rynek rządowy (głównie do użytku obronnego lub wywiadowczego) musiały poddać je ocenie tylko pod kątem jednego zestawu standardów. CC został opracowany przez rządy Kanady, Francji, Niemiec, Holandii, Wielkiej Brytanii i USA

Organizacje testujące

Wszystkie laboratoria badawcze muszą być zgodne z normą ISO/IEC 17025 , a jednostki certyfikujące będą zwykle zatwierdzane zgodnie z normą ISO/IEC 17065.

Zgodność z normą ISO/IEC 17025 jest zazwyczaj wykazywana przed krajowym organem zatwierdzającym:

Charakterystyka tych organizacji została zbadana i zaprezentowana podczas ICCC 10.

Porozumienie o wzajemnym uznawaniu

Oprócz standardu Common Criteria istnieje również poziom podtraktatowy Common Criteria MRA (ang. Mutual Recognition Arrangement), zgodnie z którym każda jego strona uznaje oceny w odniesieniu do standardu Common Criteria wykonane przez inne strony. Pierwotnie podpisane w 1998 r. przez Kanadę, Francję, Niemcy, Wielką Brytanię i Stany Zjednoczone, Australia i Nowa Zelandia przystąpiły do ​​1999 r., a następnie w 2000 r. Finlandia, Grecja, Izrael, Włochy, Holandia, Norwegia i Hiszpania. zmieniono nazwę Common Criteria Recognition Arrangement ( CCRA ), a liczba członków nadal rośnie . W ramach CCRA tylko oceny do EAL 2 są wzajemnie uznawane (w tym augmentacja z usuwaniem wad). Kraje europejskie objęte dawnym porozumieniem ITSEC zazwyczaj również uznają wyższe EAL. Oceny na poziomie EAL5 i wyższym zazwyczaj uwzględniają wymagania bezpieczeństwa rządu kraju gospodarza.

We wrześniu 2012 r. większość członków CCRA opracowała deklarację wizji, zgodnie z którą wzajemne uznawanie produktów ocenionych przez CC zostanie obniżone do EAL 2 (w tym rozszerzenia z usuwaniem wad). Co więcej, ta wizja wskazuje na całkowite odejście od poziomów pewności, a oceny będą ograniczone do zgodności z profilami ochrony, które nie mają określonego poziomu pewności. Zostanie to osiągnięte dzięki technicznym grupom roboczym opracowującym ogólnoświatowe PP, a okres przejściowy nie został jeszcze w pełni określony.

2 lipca 2014 r. została ratyfikowana nowa CCRA zgodnie z celami określonymi w oświadczeniu o wizji z 2012 r . . Główne zmiany w Porozumieniu obejmują:

  • Rozpoznawanie ocen tylko w oparciu o wspólny profil ochrony (cPP) lub poziomy pewności oceny od 1 do 2 i ALC_FLR.
  • Pojawienie się międzynarodowych wspólnot technicznych (iTC), grup ekspertów technicznych odpowiedzialnych za tworzenie cPP.
  • Plan przejściowy z poprzedniej CCRA, w tym uznawanie certyfikatów wydanych w ramach poprzedniej wersji Porozumienia.

Zagadnienia

Wymagania

Common Criteria jest bardzo ogólne; nie zawiera bezpośrednio listy wymagań bezpieczeństwa produktu lub funkcji dla określonych (klas) produktów: jest to zgodne z podejściem przyjętym przez ITSEC , ale było źródłem debaty w stosunku do tych stosowanych w bardziej nakazowym podejściu innych wcześniejszych standardów, takich jak TCSEC i FIPS 140 -2.

Wartość certyfikacji

Certyfikacja Common Criteria nie gwarantuje bezpieczeństwa, ale może zapewnić niezależną weryfikację twierdzeń o cechach bezpieczeństwa ocenianego produktu. Innymi słowy, produkty oceniane według standardu Common Criteria wykazują wyraźny łańcuch dowodów, że proces specyfikacji, implementacji i oceny został przeprowadzony w sposób rygorystyczny i standardowy.

Różne wersje systemu Microsoft Windows, w tym Windows Server 2003 i Windows XP , otrzymały certyfikaty , ale firma Microsoft wciąż publikuje poprawki bezpieczeństwa dla tych systemów Windows. Jest to możliwe, ponieważ proces uzyskiwania certyfikatu Common Criteria pozwala dostawcy ograniczyć analizę do określonych funkcji bezpieczeństwa i przyjąć pewne założenia dotyczące środowiska operacyjnego i siły zagrożeń, na jakie napotyka produkt w tym środowisku. Dodatkowo CC dostrzega potrzebę ograniczenia zakresu oceny w celu zapewnienia opłacalnych i użytecznych certyfikatów bezpieczeństwa, tak aby oceniane produkty były badane na poziomie szczegółowości określonym przez poziom pewności lub PP. W związku z tym działania ewaluacyjne są wykonywane tylko do pewnego stopnia, czasu i zasobów oraz dają wystarczającą pewność co do zamierzonego środowiska.

W przypadku Microsoftu założenia obejmują A.PEER:

„Zakłada się, że wszelkie inne systemy, z którymi komunikuje się TOE, podlegają tej samej kontroli zarządzania i działają w ramach tych samych ograniczeń polityki bezpieczeństwa. TOE ma zastosowanie do środowisk sieciowych lub rozproszonych tylko wtedy, gdy cała sieć działa pod tymi samymi ograniczeniami i znajduje się w pojedyncza domena zarządzania. Nie ma wymagań dotyczących bezpieczeństwa, które uwzględniałyby potrzebę zaufania do systemów zewnętrznych lub łączy komunikacyjnych z takimi systemami”.

To założenie jest zawarte w Profilu Ochrony Kontrolowanego Dostępu (CAPP), do którego stosują się ich produkty. Na podstawie tego i innych założeń, które mogą nie być realistyczne w przypadku powszechnego użytkowania systemów operacyjnych ogólnego przeznaczenia, oceniane są deklarowane funkcje bezpieczeństwa produktów Windows. Dlatego należy je uważać za bezpieczne tylko w założonych, określonych okolicznościach, zwanych też konfiguracją ocenianą .

Niezależnie od tego, czy uruchamiasz Microsoft Windows w dokładnie przeanalizowanej konfiguracji, czy nie, powinieneś zastosować poprawki bezpieczeństwa Microsoft dla luk w systemie Windows, gdy nadal się pojawiają. Jeśli którakolwiek z tych luk w zabezpieczeniach jest możliwa do wykorzystania w ocenianej konfiguracji produktu, dostawca powinien dobrowolnie wycofać certyfikat Common Criteria produktu. Alternatywnie dostawca powinien ponownie ocenić produkt, aby uwzględnić zastosowanie poprawek w celu naprawienia luk w zabezpieczeniach w ocenianej konfiguracji. Niepodjęcie przez sprzedawcę któregokolwiek z tych kroków skutkowałoby mimowolnym wycofaniem certyfikacji produktu przez jednostkę certyfikującą kraju, w którym produkt był oceniany.

Certyfikowane wersje systemu Microsoft Windows pozostają na poziomie EAL4+ bez uwzględniania w ocenianej konfiguracji żadnych łatek zabezpieczeń firmy Microsoft. Pokazuje to zarówno ograniczenia, jak i siłę ocenianej konfiguracji.

Krytyka

W sierpniu 2007 r. felietonista Government Computing News (GCN) William Jackson krytycznie przeanalizował metodologię Common Criteria i jej wdrożenie w USA przez Common Criteria Evaluation and Validation Scheme (CCEVS). W rubryce przeprowadzono wywiady z kadrą kierowniczą z branży bezpieczeństwa, badaczami oraz przedstawicielami National Information Assurance Partnership (NIAP). Zastrzeżenia przedstawione w artykule obejmują:

  • Ocena to kosztowny proces (często mierzony w setkach tysięcy dolarów amerykańskich) – a zwrot dostawcy z tej inwestycji niekoniecznie jest bezpieczniejszym produktem.
  • Ewaluacja skupia się przede wszystkim na ocenie dokumentacji ewaluacyjnej, a nie na faktycznym bezpieczeństwie, poprawności technicznej czy zaletach samego produktu. W przypadku ocen amerykańskich tylko na poziomie EAL5 i wyższym w analizie uczestniczą eksperci z Narodowej Agencji Bezpieczeństwa; i tylko w EAL7 wymagana jest pełna analiza kodu źródłowego.
  • Wysiłek i czas niezbędny do przygotowania dowodów oceny i innej dokumentacji związanej z oceną są tak uciążliwe, że do czasu zakończenia prac oceniany produkt jest generalnie przestarzały.
  • Informacje branżowe, w tym pochodzące od organizacji takich jak Forum dostawców Common Criteria , na ogół mają niewielki wpływ na cały proces.

W 2006 roku specjalista komputerowy David A. Wheeler zasugerował, że proces Common Criteria dyskryminuje organizacje i modele programistyczne zorientowane na wolne i otwarte oprogramowanie (FOSS). Wymagania dotyczące zapewnienia zgodności z kryteriami Common Criteria są zwykle inspirowane tradycyjną metodologią tworzenia oprogramowania kaskadowego . W przeciwieństwie do tego, wiele oprogramowania FOSS jest produkowanych przy użyciu nowoczesnych paradygmatów Agile . Chociaż niektórzy twierdzili, że oba paradygmaty nie pasują do siebie, inni próbowali pogodzić oba paradygmaty. Politolog Jan Kallberg wyraził obawy związane z brakiem kontroli nad rzeczywistą produkcją produktów po ich certyfikacji, brakiem stałego organu organizacyjnego, który monitoruje zgodność, oraz ideą, że zaufanie do certyfikatów bezpieczeństwa IT Common Criteria będzie być utrzymywane ponad granicami geopolitycznymi.

W 2017 roku luka ROCA została znaleziona na liście produktów kart inteligentnych z certyfikatem Common Criteria. Luka ujawniła kilka niedociągnięć systemu certyfikacji Common Criteria:

  • Luka tkwi w algorytmie generowania kluczy RSA, który nie został opublikowany i przeanalizowany przez społeczność zajmującą się kryptoanalizą. Jednak laboratorium badawcze TÜV Informationstechnik GmbH (TÜViT) w Niemczech zatwierdziło jego stosowanie, a jednostka certyfikująca BSI w Niemczech wydała certyfikaty Common Criteria dla produktów wrażliwych. Security Target ocenianego produktu twierdził, że klucze RSA są generowane zgodnie ze standardowym algorytmem. W odpowiedzi na tę lukę, BSI planuje teraz poprawić przejrzystość, wymagając, aby raport certyfikacyjny przynajmniej określał, czy wdrożona zastrzeżona kryptografia nie jest dokładnie zgodna z zalecanym standardem. BSI nie planuje w żaden sposób wymagać publikowania zastrzeżonego algorytmu.
  • Chociaż jednostki certyfikujące są teraz świadome, że oświadczenia dotyczące bezpieczeństwa określone w certyfikatach Common Criteria już nie obowiązują , ani ANSSI, ani BSI nie unieważniły odpowiednich certyfikatów. Według BSI zaświadczenie można cofnąć tylko wtedy, gdy zostało wydane w wyniku błędnego przekonania, np. gdy okaże się, że złożono błędne dowody. Po wystawieniu certyfikatu należy założyć, że ważność certyfikatu zmniejsza się w miarę upływu czasu w wyniku udoskonalania i wykrywania nowych ataków. Jednostki certyfikujące mogą wystawiać raporty z konserwacji, a nawet przeprowadzać ponowną certyfikację produktu. Działania te jednak muszą być inicjowane i sponsorowane przez sprzedawcę.
  • Chociaż kilka produktów z certyfikatem Common Criteria zostało dotkniętych wadą ROCA, odpowiedzi dostawców w kontekście certyfikacji były różne. W przypadku niektórych produktów wydano raport serwisowy, w którym stwierdzono, że tylko klucze RSA o długości 3072 i 3584 bitów mają poziom bezpieczeństwa co najmniej 100 bitów, podczas gdy w przypadku niektórych produktów raport serwisowy nie wspomina, że ​​zmiana TOE wpływa na certyfikowana funkcja bezpieczeństwa kryptograficznego, ale stwierdza, że ​​zmiana jest na poziomie dokumentacji wytycznych i nie ma wpływu na zapewnienie.
  • Według BSI użytkownicy certyfikowanych produktów końcowych powinni zostać poinformowani przez dostawców o podatności ROCA . Informacje te nie dotarły jednak w odpowiednim czasie do władz estońskich, które zastosowały podatny produkt na ponad 750 000 estońskich dowodów osobistych .

Alternatywne podejścia

Przez cały okres istnienia CC nie został on powszechnie przyjęty nawet przez kraje tworzące, w szczególności zatwierdzenie kryptograficzne jest obsługiwane oddzielnie, na przykład przez kanadyjską/amerykańską implementację FIPS-140 i CESG Assisted Products Scheme (CAPS ) w UK.

Wielka Brytania opracowała również szereg alternatywnych programów, w przypadku których stwierdzono, że ramy czasowe, koszty i ogólne koszty wzajemnego uznawania utrudniają działanie rynku:

  • CESG system oceny (SYSn) i podejście Fast Track (FTA) systemów zapewniania systemów rządowych zamiast generycznych produktów i usług, które zostały połączone w CESG Tailored Assurance Service (CTA)
  • Znak CESG Claims Tested Mark ( znak CCT), który ma na celu sprostanie mniej wyczerpującym wymaganiom dotyczącym zapewnienia produktów i usług w sposób efektywny kosztowo i czasowo

Na początku 2011 roku NSA/CSS opublikowało artykuł Chrisa Saltera, w którym zaproponował podejście do oceny zorientowane na profil ochrony . W tym podejściu wokół typów technologii tworzą się społeczności interesów, które z kolei opracowują profile ochrony, które definiują metodologię oceny dla danego typu technologii. Celem jest bardziej rzetelna ocena. Istnieją pewne obawy, że może to mieć negatywny wpływ na wzajemne uznawanie .

We wrześniu 2012 roku Common Criteria opublikowało Vision Statement, w dużej mierze wdrażając przemyślenia Chrisa Saltera z poprzedniego roku. Kluczowe elementy Wizji obejmowały:

  • Społeczności techniczne będą koncentrować się na tworzeniu profili ochrony (PP), które wspierają ich cel, jakim są rozsądne, porównywalne, powtarzalne i opłacalne wyniki oceny
  • Oceny powinny być dokonywane w odniesieniu do tych PP, jeśli to możliwe; w przeciwnym razie wzajemne uznawanie ocen celów bezpieczeństwa byłoby ograniczone do EAL2

Zobacz też

Bibliografia

Zewnętrzne linki