Kryteria oceny zaufanych systemów komputerowych — Trusted Computer System Evaluation Criteria

Pomarańczowa Księga

Tcsec ( TCSEC ) to Stany Zjednoczone Rząd Departament Obrony standardowe (DoD), który wyznacza podstawowe wymagania dotyczące oceny skuteczności bezpieczeństwa komputerowego sterowania wbudowane w systemie komputerowym . TCSEC został wykorzystany do oceny, klasyfikacji i wyboru systemów komputerowych, które są rozważane do przetwarzania, przechowywania i wyszukiwania informacji wrażliwych lub niejawnych .

TCSEC, często nazywana Pomarańczową Księgą , jest centralnym punktem publikacji DoD Rainbow Series . Pierwotnie wydany w 1983 roku przez National Computer Security Center (NCSC), ramię Narodowej Agencji Bezpieczeństwa , a następnie zaktualizowany w 1985 roku, TCSEC został ostatecznie zastąpiony przez międzynarodowy standard Common Criteria , pierwotnie opublikowany w 2005 roku.

Podstawowe cele i wymagania

W dniu 24 października 2002 roku, The Orange Book (aka DoDD 5200.28-STD) został anulowany przez DoDD 8500.1, który później został ponownie wydany jako DoDI 8500.02, w dniu 14 marca 2014 roku.

Polityka

Polityka bezpieczeństwa musi być jasna, dobrze zdefiniowana i egzekwowana przez system komputerowy. Określono trzy podstawowe zasady bezpieczeństwa:

  • Obowiązkowa polityka bezpieczeństwa — wymusza reguły kontroli dostępu oparte bezpośrednio na poświadczeniu osoby, autoryzacji informacji i poziomie poufności poszukiwanych informacji. Inne czynniki pośrednie to czynniki fizyczne i środowiskowe. Polityka ta musi również dokładnie odzwierciedlać przepisy prawa, ogólne zasady i inne odpowiednie wytyczne, z których wywodzą się zasady.
  • Oznaczanie — systemy zaprojektowane w celu egzekwowania obowiązkowej polityki bezpieczeństwa muszą przechowywać i zachowywać integralność etykiet kontroli dostępu oraz zachowywać etykiety, jeśli obiekt jest eksportowany.
  • Uznana polityka bezpieczeństwa — wymusza spójny zestaw reguł kontroli i ograniczania dostępu w oparciu o zidentyfikowane osoby, które zostały uznane za niezbędne do uzyskania informacji.

Odpowiedzialność

Należy egzekwować indywidualną odpowiedzialność niezależnie od polityki. Muszą istnieć bezpieczne środki zapewniające dostęp upoważnionego i kompetentnego agenta, który może następnie ocenić informacje dotyczące rozliczalności w rozsądnym czasie i bez nadmiernych trudności. Cel rozliczalności obejmuje trzy wymagania:

  • Identyfikacja — proces używany do rozpoznawania indywidualnego użytkownika.
  • Uwierzytelnianie – Weryfikacja uprawnień indywidualnego użytkownika do określonych kategorii informacji.
  • Inspekcja — informacje dotyczące inspekcji muszą być selektywnie przechowywane i chronione, aby można było prześledzić działania wpływające na bezpieczeństwo uwierzytelnionej osoby.

Zapewnienie

System komputerowy musi zawierać mechanizmy sprzętowe/programowe, które mogą być niezależnie oceniane, aby zapewnić wystarczającą pewność, że system wymusza powyższe wymagania. Co za tym idzie, zapewnienie musi obejmować gwarancję, że zaufana część systemu działa tylko zgodnie z przeznaczeniem. Aby osiągnąć te cele, potrzebne są dwa rodzaje zapewnienia z ich odpowiednimi elementami:

  • Mechanizmy zapewniania
  • Zapewnienie operacyjne: architektura systemu, integralność systemu, analiza ukrytych kanałów, zarządzanie zaufanymi obiektami i zaufane odzyskiwanie
  • Zapewnienie cyklu życia: testowanie bezpieczeństwa, specyfikacja projektu i weryfikacja, zarządzanie konfiguracją i dystrybucja zaufanego systemu
  • Zapewnienie ciągłej ochrony — zaufane mechanizmy, które wymuszają te podstawowe wymagania, muszą być stale chronione przed manipulacją lub nieautoryzowanymi zmianami.

Dokumentacja

W ramach każdej klasy dodatkowy zestaw dokumentacji dotyczy rozwoju, wdrażania i zarządzania systemem, a nie jego możliwościami. Ta dokumentacja obejmuje:

  • Podręcznik użytkownika funkcji zabezpieczeń, podręcznik zaufanego obiektu, dokumentacja testowa i dokumentacja projektowa

Podziały i klasy

TCSEC definiuje cztery działy: D, C, B i A, gdzie dział A ma najwyższy poziom bezpieczeństwa. Każdy dział reprezentuje znaczącą różnicę w zaufaniu osoby lub organizacji do ocenianego systemu. Dodatkowo podziały C, B i A są podzielone na szereg hierarchicznych podpodziałów zwanych klasami: C1, C2, B1, B2, B3 i A1.

Każda dywizja i klasa rozszerza lub modyfikuje, jak wskazano, wymagania bezpośrednio poprzedzającej dywizji lub klasy.

D – Minimalna ochrona

  • Zarezerwowane dla tych systemów, które zostały ocenione, ale nie spełniają wymagań wyższego podziału.

C – Ochrona uznaniowa

  • C1 – Uznaniowa ochrona bezpieczeństwa
    • Identyfikacja i uwierzytelnianie
    • Separacja użytkowników i danych
    • Uznaniowa kontrola dostępu (DAC) zdolna do egzekwowania ograniczeń dostępu na zasadzie indywidualnej
    • Wymagana dokumentacja systemu i instrukcje obsługi
  • C2 – Ochrona dostępu kontrolowanego
    • Bardziej drobnoziarnisty przetwornik cyfrowo-analogowy
    • Indywidualna odpowiedzialność poprzez procedury logowania
    • Ścieżki audytu
    • Ponowne wykorzystanie obiektu
    • Izolacja zasobów
    • Przykładem takiego systemu jest HP-UX

B – Obowiązkowa ochrona

  • B1 – Oznaczona ochrona bezpieczeństwa
    • Nieformalne oświadczenie o modelu polityki bezpieczeństwa
    • Etykiety wrażliwości danych
    • Obowiązkowa kontrola dostępu (MAC) nad wybranymi podmiotami i obiektami
    • Możliwości eksportu etykiet
    • Niektóre wykryte wady należy usunąć lub w inny sposób złagodzić
    • Specyfikacje projektowe i weryfikacja
  • B2 – Ochrona strukturalna
    • Model polityki bezpieczeństwa jasno zdefiniowany i formalnie udokumentowany
    • Egzekwowanie DAC i MAC rozszerzone na wszystkie podmioty i obiekty
    • Ukryte kanały przechowywania są analizowane pod kątem występowania i przepustowości
    • Starannie podzielone na elementy o kluczowym znaczeniu dla ochrony i niekrytyczne dla ochrony
    • Projekt i wdrożenie umożliwiają bardziej kompleksowe testowanie i przegląd
    • Wzmocnione mechanizmy uwierzytelniania
    • Zaufane zarządzanie obiektem zapewnia segregacja administratorów i operatorów
    • Narzucane są ścisłe kontrole zarządzania konfiguracją
    • Role operatora i administratora są rozdzielone.
    • Przykładem takiego systemu był Multics
  • B3 – Domeny bezpieczeństwa
    • Spełnia wymagania dotyczące monitora referencyjnego
    • Strukturalny, aby wykluczyć kod, który nie jest niezbędny do egzekwowania zasad bezpieczeństwa
    • Znacząca inżynieria systemowa ukierunkowana na minimalizację złożoności
    • Zdefiniowano rolę administratora bezpieczeństwa
    • Audytuj zdarzenia związane z bezpieczeństwem
    • Zautomatyzowane wykrywanie nieuchronnego włamania , powiadamianie i reagowanie
    • Zaufana ścieżka do TCB dla funkcji uwierzytelniania użytkownika
    • Zaufane procedury odzyskiwania systemu
    • Ukryte kanały czasowe są analizowane pod kątem występowania i przepustowości
    • Przykładem takiego systemu jest XTS-300, prekursor XTS-400

A – Zweryfikowana ochrona

  • A1 – Zweryfikowany projekt
    • Funkcjonalnie identyczny z B3
    • Formalne techniki projektowania i weryfikacji, w tym formalna specyfikacja najwyższego poziomu
    • Formalne procedury zarządzania i dystrybucji
    • Przykładami systemów klasy A1 są SCOMP firmy Honeywell , GEMSOS firmy Aesec i serwer SNS firmy Boeing. Dwa, które nie zostały ocenione, to produkcyjna platforma LOCK i anulowane jądro bezpieczeństwa DEC VAX.
  • Poza A1
    • Architektura systemu pokazuje, że wymagania samoochrony i kompletności dla monitorów referencyjnych zostały zaimplementowane w Trusted Computing Base (TCB).
    • Testowanie bezpieczeństwa automatycznie generuje przypadek testowy na podstawie formalnej specyfikacji najwyższego poziomu lub formalnej specyfikacji niższego poziomu.
    • Formalna specyfikacja i weryfikacja to sytuacja, w której TCB jest weryfikowana do poziomu kodu źródłowego, przy użyciu formalnych metod weryfikacji, o ile jest to możliwe.
    • Zaufane środowisko projektowe to miejsce, w którym TCB jest projektowana w zaufanym obiekcie z tylko zaufanym (przeszkolonym) personelem.

Dopasowanie klas do wymagań środowiskowych

Publikacja zatytułowana „Army Regulation 380-19” jest przykładem przewodnika określającego jaką klasę systemu należy zastosować w danej sytuacji.

Zobacz też

Bibliografia

Zewnętrzne linki