Jak se ale pozná bezpečný systém? Jaká bezpečnostní funkcionalita musí být implementována? Mohu věřit tomu, že je funkcionalita implementována správně? Jak vůbec jednoduše definovat požadovanou úroveň bezpečnosti či naopak deklarovat její dosažení?
Pro tyto účely postupně vznikly různé bezpečnostní standardy, na jejichž základě nezávislé akreditované organizace provádějí bezpečnostní ohodnocení jednotlivých produktů a systémů. Průkopníkem formalizovaných bezpečnostních kriterií jsou Trusted Computer System Evaluation Criteria (TCSEC, známá také jako „Orange Book“), která byla přijata v USA v roce 1983. V dalších letech začala vznikat řada národních standardů. Z nepřehledné situace, ve které neexistovala žádná pravidla, se svět dostal do podobně nepřehledné situace, kdy existovalo tolik vzájemně nesourodých standardů, že pro zákazníka i pro dodavatele bylo prakticky nemožné se v nich vyznat a využívat je.
Prvním krokem ke sjednocení bylo vytvoření standardu Information Technology Security Evaluation Criteria (ITSEC) na základě standardů Velké Británie, Francie, Německa a Holandska. Oproti TCSEC nabízel ITSEC větší míru flexibility z hlediska hodnocených systémů a jejich parametrů a lépe tak reagoval na požadavky komerční i bezpečnostní sféry.
Common Criteria – mezinárodní standard
Zmatení jazyků dané existencí několika standardů vyřešilo až jejich nahrazení novým standardem Common Criteria for Information Technology Security Evaluation (často označovaného jen za Common Criteria nebo CC). Ten byl následně v roce 1999 přijat také jako mezinárodní norma ISO 15408. Mezinárodní dohody související s Common Criteria navíc umožnily vzájemné uznávání certifikace z jedné země v zemi druhé a definovaly samozřejmě také společnou metodiku provádění ohodnocení. Z našeho pohledu je důležité, že mezi země uznávající certifikace provedené na základě této normy v jiných zemích se v současnosti řadí i Česká republika.
Snahou při tvorbě Common Criteria bylo zajistit možnost jejich nejširšího použití. Bezpečnostní požadavky na různé systémy se však značně liší – srovnejte třeba čtečku kreditních karet a relační databázový systém jako je Oracle. Vzhledem k šířce možného využití nedefinují Common Criteria konkrétní požadavky na funkcionalitu systému jednotně. Místo toho určují jen důležité oblasti a způsob, jak lze definovat sady těchto požadavků pro různé skupiny systémů a jak lze popisovat skutečné možnosti konkrétního zařízení.
Protection Profile popisuje bezpečnostní požadavky pro určitou obecnou situaci danou sadou předpokladů, bezpečnostních hrozeb a bezpečnostního cíle. Protection Profile je společný pro určitou skupinu produktů – např. relační databázové systémy. Odpovídá na otázku: „Co od daného typu bezpečnostního řešení vyžaduji?“ a tvoří tak ideální vodítko pro zákazníky při specifikaci jejich požadavků.
Naopak Security Target popisuje situaci z pohledu konkrétního produktu. Definuje podobu hrozeb, požadavků a bezpečnostního cíle, pro nějž je konkrétní produkt certifikován, a shrnuje bezpečnostní funkce a způsob zajištění jejich důvěryhodnosti v daném produktu. Představuje tak podrobné zadání pro provedení bezpečnostního ohodnocení (případně už pro vlastní vývoj systému). Odpovídá tedy na otázku: „Co dodavatel v daném produktu z hlediska bezpečnosti nabízí?“.
Common Criteria oddělují hodnocení funkcionality a hodnocení míry důvěryhodnosti implementace. Mezi oblasti hodnocené v rámci kritérií funkcionality patří:
Bezpečnostní audit – jaké informace o důležitých aktivitách či událostech jsou ukládány, které události jsou takto auditovány, jak jsou tato data uložena a jak je lze analyzovat.
Komunikace – jak je řešeno zajištění identity autorů a příjemců přenášených dat a nepopiratelnost jejich komunikace.
Podpora šifrování – pokud produkt využívá šifrování například pro podporu komunikace nebo v rámci identifikace a autentizace, jak je zajištěna správa a použití šifrovacích klíčů.
Ochrana uživatelských dat – jak jsou chráněna data uživatelů během jejich uložení, importu či exportu. Jak lze definovat bezpečnostní atributy dat (řízení přístup k datům).
Identifikace a autentizace – jak je zajištěna jednoznačná identifikace uživatelů, určení jejich oprávnění pro přístup k systému a přiřazení správných bezpečnostních atributů mezi objekty a uživateli.
Ochrana soukromí – ochrana uživatelů před nežádoucím objevením a zneužitím jejich identity či nežádoucím sledováním jejich činnosti jinými uživateli.
Řízení bezpečnosti – správa bezpečnostních atributů, dat a funkcí, definice bezpečnostních rolí. Jakým způsobem je například omezena možnost přidělovat uživatelům různá přístupová práva.
Využití prostředků – zajištění dostupnosti systémových prostředků, překonání výpadku, přidělování prostředků podle priorit.
Přístup k systému – řízení připojování uživatelů k systému (nad rámec identifikace a autentizace) – tj. například limitování počtu připojených uživatelů.
Důvěryhodné spojení – zajištění důvěryhodné komunikační cesty mezi systémem a uživateli nebo jinými systémy.
Ochrana vlastních bezpečnostních funkcí – zajištění integrity bezpečnostních funkcí a jejich dat. Například nemožnost neoprávněně modifikovat mechanismus ověřování uživatelů.
Kritéria míry důvěryhodnosti nám signalizují, jak lze důvěřovat ve správnost implementace produktu – tedy že produkt skutečně bude správně dělat to, co dodavatel slibuje. Tato kriteria ve skutečnosti nehodnotí výsledný produkt, ale spíše systém řízení firmy dodavatele. Mezi tato kriteria patří:
Správa konfigurací – řízení procesu, jímž dochází k sestavení a provádění úprav v hodnoceném systému a související dokumentaci.
Dodávka a zprovoznění – zajištění dodávky, instalace a inicializace hodnoceného sys-
tému.
Vývoj – proces tvorby různých úrovní specifikace a návrhu na základě definovaného „security target“, včetně vyhodnocení jejich vzájemné konzistence a samozřejmě také vlastní implementace.
Testování – zajištění dostatečného rozsahu a hloubky funkčních testů, případně požadavky na nezávislé testy.
Dokumentace – zahrnutí všech relevantních bezpečnostních aspektů použití hodnoceného systému v uživatelské a administrátorské dokumentaci.
Životní cyklus produktu – definice životního cyklu produktu, prostředí vývoje, údržba produktu, způsob opravy bezpečnostních chyb objevených zákazníky.
Posouzení zranitelnosti – analýza existence skrytých slabých míst, jako jsou zadní vrátka v systému, zneužití špatné konfigurace systému, schopnost obejít bezpečnostní mechanismy, chyby implementace, kontrola síly implementovaných bezpečnostních funkcí.
Udržení důvěryhodnosti – zajištění toho, že hodnocený systém bude dále plnit svůj bezpečnostní cíl i po dokončení certifikace. Způsob vyhodnocení vlivu následných změn systému či prostředí.
Dále byla vytvořena sada sedmi úrovní důvěryhodnosti EAL 1 až EAL 7, jež představují typické kombinace faktorů z oblasti důvěryhodnosti a zjednodušují tak orientaci v certifikacích.
EAL1 vyžaduje od tvůrce systému jen minimální funkční testy.
EAL4 vyžaduje neformální popis podrobného návrhu, analýzy zdrojového kódu, testování funkcí včetně nezávislé analýzy slabých míst, definovaný životní cyklus produktu a třeba automatizovaný systém správy konfigurací.
EAL7 reprezentuje nejvyšší úroveň důvěry a vyžaduje velice striktní ověření formálního vývoje, verifikace a distribučních metod, které podstatně přesahuje rámec komerčně dostupných produktů a systémů.
Přínosy bezpečnostních ohodnocení
Zavedení bezpečnostních ohodnocení umožňuje zákazníkům lépe se orientovat v nabídce jednotlivých dodavatelů a jednodušeji specifikovat požadovanou úroveň bezpečnosti např. v poptávkách. Díky tomu, že je posuzován nejen rozsah funkcí, ale i mechanismy pro zajištění důvěryhodnosti, poskytuje certifikát dobrou představu i o kvalitě produktu.
Pro dodavatele znamená certifikace způsob, jak lépe propagovat bezpečnost svých produktů a lépe tak zhodnocovat investice do této části vývoje produktu. Bezpečnostní ohodnocení také pomáhá zdokonalovat kvalitu IT produktů a systémů. Jednotlivé systémy jsou důkladně prověřovány na úrovni architektury i vlastního zdrojového kódu, což umožňuje odhalit včas případné nedostatky. Testované produkty neprojdou, pokud nejsou všechny případně nalezené nedostatky odstraněny.
Z tohoto pohledu je zajímavé, jak rozdílně přistupují jednotliví dodavatelé, zvláště v některých oblastech, k ohodnocení podle Common Criteria. Zatímco například všechny „velké“ verze databáze Oracle od vytvoření první verze Common Criteria roku 1996 prošly úspěšně ohodnocením podle tohoto kriteria s mírou důvěryhodnosti EAL 4, jiné významné databázové systémy získaly první certifikaci buď teprve v nedávné době, nebo dokonce vůbec ne. Aktuální seznam certifikovaných produktů lze nalézt na adrese: www.commoncriteriaportal.org. 05s0014/jp o
David Krch pracuje ve společnosti Oracle Czech
PŘEDPLATNÉ
ČLÁNKY DO MAILU