Trusted Computer System Evaluation Criteria

Trusted Computer System Evaluation Criteria (TCSEC) neboli kritéria hodnocení spolehlivosti počítačových systémů je normou ministerstva obrany vlády Spojených států amerických (DoD – Department of Defense), která stanoví základní požadavky pro hodnocení kontroly efektivnosti počítačové bezpečnosti v počítačovém systému. TCSEC byla využita pro hodnocení, klasifikaci a výběru počítačových systémů, u kterých bylo zvažováno jejich využití pro zpracování, ukládání a vyhledávání citlivých nebo tajných informací.^[1]

TCSEC, o které se často mluví jako o Oranžové knize, je ústředním bodem publikací Duhové řady ministerstva obrany Spojených států amerických. Původně byla vydána v roce 1983 Národním počítačovým bezpečnostním centrem (National Computer Security Center – NCSC), částí Národní bezpečnostní agentury (National Security Agency – NSA) a byla doplněna v roce 1985. TCSEC byla nahrazena Common Criteria, mezinárodním standardem, který byl vydán v roce 2005.

Základní cíle a požadavky

Oranžová kniha neboli DoDD 5200.28-STD byla zrušena DoDD 8500.1 dne 24. října 2002.^[2]

Politika

Bezpečnostní politika musí být výslovná, dobře definovaná a v počítačovém systému vymahatelná. Existují dvě základní bezpečnostní politiky:

• povinná bezpečnostní politika – Prosazuje pravidla řízení přístupu založené přímo na oprávnění jednotlivců, autorizaci pro informace a žádá utajení určité úrovně informací. Dalšími nepřímými faktory jsou faktory fyzické a týkající se okolí. Tato politika musí také přesně odrážet zákony, obecné zásady a další relevantní pokyny, ze kterých jsou pravidla odvozena.
• značení – Systémy směřující k prosazení povinné bezpečnostní politiky musí uchovávat a chránit integritu kontroly značek a zachování značek, pokud jsou vyváženy.
• volná bezpečnostní politika – Prosazuje konzistentní sadu pravidel pro kontrolu a omezený přístup založený na základě určených osob, u kterých je stanoveno, že určité informace potřebují vědět.

Zodpovědnost

Bez ohledu na politiku musí být prosazena osobní zodpovědnost. Musí existovat bezpečný způsob, který by zajistil přístup oprávněného, příslušného zástupce, který dokáže vyhodnotit zodpovědnost k informacím v přiměřeném čase a bez zbytečných potíží. Jsou tři požadavky vyplývající z cíle zodpovědnosti:

• identifikace – proces k rozpoznání jednotlivých uživatelů,
• autentifikace – ověření oprávnění uživatelů pro konkrétní kategorie informací,
• audit – informace z auditu musí být drženy a chráněny tak, aby akce zasahující do bezpečnosti mohly být vystopovány k autentifikovanému jednotlivci.

Záruka

Počítačový systém musí obsahovat hardwarové nebo softwarové mechanismy, které mohou být nezávisle hodnoceny k poskytnutí dostatečné záruky, že systém splňuje výše uvedené požadavky. Obecněji řečeno musí záruka obsahovat ujištění, že důvěrné části systémové fungují tak, jak bylo zamýšleno. Ke splnění těchto cílů je třeba dvou typů záruky s těmito jejich částmi:

• záruční mechanismy,
• provozní záruka – systémová architektura, systémová integrita, skryté využívání kanálů, analýza, spolehlivý facility management a důvěryhodné ozdravení,
• záruka v průběhu životního cyklu – testování bezpečnosti, navrhované specifikace a verifikace, uspořádané řízení a důvěryhodná distribuce systému,
• záruka nepřetržité ochrany – Důvěryhodné mechanismy, které prosazují tyto základní požadavky, musí být nepřetržitě chráněny proti manipulacím a/nebo neoprávněným změnám.

Dokumentace

V každé třídě je další sada dokumentace, která řeší spíše vývoj, implementaci a správu systému než jeho schopnosti. Tato dokumentace zahrnuje:

• uživatelský návod k bezpečnostnímu programu, manuál k zařízení, testovací dokumentaci a projektovou dokumentaci.

Divize a třídy

TCSEC definuje čtyři divize: D, C, B a A, kdy A znamená největší bezpečnost. Každá divize znamená důležitý rozdíl v důvěře, kterou může člověk či organizace věnovat vyhodnocenému systému. C, B a A jsou navíc rozděleny do několika hierarchických oddělení, do tzv. tříd C1, C2, B1, B2, B3 a A1.

Každá divize a třída rozšiřuje nebo mění dané požadavky, které od sebe odlišují jednotlivé divize nebo třídy.

D - minimální ochrana

• Určeno pro systémy, které byly vyhodnoceny, ale nesplňují požadavky pro zařazení do vyšší divize.

C - volitelná ochrana

• C1 – volitelná bezpečnostní ochrana
  • identifikace a autentizace
  • oddělení uživatelů a dat
  • řízení přístupu schopné prosadit omezení přístupu a individuální princip fungování
  • požadovaná systémová dokumentace a uživatelský návod
• C2 – kontrolovaná ochrana přístupu
  • jemněji definované řízení přístupu
  • individuální zodpovědnost díky přihlašovacím procedurám
  • sledování auditem
  • opětovné užití
  • izolace zdrojů

B – povinná ochrana

• B1 – ochrana bezpečnosti návěštím
  • neformální vyhlášení bezpečnostní politiky
  • značení bezpečnostní citlivosti dat
  • povinná přístupová kontrola přes vybrané předměty a objekty
  • značení možnosti vývozu
  • všechny objevené nedostatky musí být odstraněny nebo zmírněny
  • navrhované specifikace a verifikace
• B2 – strukturovaná ochrana
  • bezpečnostní politika jasně definovaná a formálně dokumentovaná
  • vymáhání řízení přístupu a povinné přístupové kontroly rozšířeny na všechny předměty a objekty
  • skryté skladovací kanály jsou analyzovány pro výskyt a šířku pásma
  • pečlivě strukturováno pro zabezpečené kritické a nezabezpečené kritické prvky
  • návrh a implementace umožňující komplexnější testování a přezkoumání
  • autentifikační mechanismy jsou zesílené
  • spolehlivý facility management je poskytován s oddělením administrace a obsluhy
  • využívá se přísně rozdělené řízení kontrol
• B3 – bezpečnostní domény
  • vyhovuje doporučením sledování požadavků
  • strukturované k vyloučení zákonů, které nejsou nezbytné k prosazení bezpečnostní politiky
  • významné systémové inženýrství směřující k minimalizaci složitosti
  • definována role bezpečnostního správce
  • audity událostí důležitých z hlediska bezpečnosti
  • automatické detekce, oznámení a odezvy na hrozící narušení bezpečnosti
  • důvěryhodné procedury pro obnovení systému
  • skryté časovací kanály jsou analyzovány pro výskyt a šířku pásma
  • příkladem takového systému je XTS-300, předchůdce XTS-400

A – ověřená ochrana

• A1 – ověřený design
  • funkčně identické jako B3
  • oficiální design a ověřené techniky obsahují oficiálně nejvyšší specifikaci
  • oficiální řízení a distribuci procedur
  • příkladem takového systému je Honywells’s Secure Communications Processor SCOMP, předchůdce XTS-400
• mimo A1
  • Systémová architektura ukazuje, že požadavky na vlastní ochranu a úplnost referenčního sledování byly implementovány v důvěryhodném výpočetním základu (Trusted Computing Base – TCB)
  • Bezpečnostní testování automaticky generuje testovací případy z formálně nejvyšší úrovně specifikace nebo formální požadavky na nižší úrovni
  • O formální specifikaci a verifikaci je možné mluvit tam, kde je verifikováno dle TCB až na úroveň zdrojového kódu za použití proveditelných formální verifikačních metod .
  • Důvěryhodné vývojové prostředí je to, kde je TCB vyvíjeno v důvěryhodném prostředí pouze důvěryhodným (prověřeným) personálem.

Třídy odpovídající ekologickým požadavkům

Armádní směrnice 380-19 je příkladem příručky k určení, která systémová třída by měla být použita v daných situacích.

Reference

V tomto článku byl použit překlad textu z článku Trusted Computer System Evaluation Criteria na anglické Wikipedii.

Související články

• Common Criteria

Externí odkazy

• Trusted Computer System Evaluation Criteria od Ministerstva obrany USA Archivováno 28. 2. 2013 na Wayback Machine.
• The Rainbow Books