TCSEC
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í.
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.[1]
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.