INFORMACE O HODNOCENÍ BEZPEČNOSTI INFORMAČNÍCH TECHNOLOGIÍ COMMON CRITERIA (CC) V České republice je dobře známa norma ISO/IEC 15408-1:1999, která je totožná s textem, zveřejněným Organizacemi sponzorujícími projekt Společná kritéria, pod názvem “Common Criteria for Information Technology Security Evaluation”, verze 2.1. Tato kritéria jsou obvykle nazývána pouze “Common Criteria” a pro jejich označení se hojně používá zkratky “CC”. Zkratka “CC” je ponechána i v českém překladu normy. Mezinárodní norma ISO/IEC 15408:1999 má status české technické normy. Česká verze nese označení ČSN ISO/IEC 15408. Český překlad prvého dílu byl Českým normalizačním institutem vydán v červnu roku 2001, překlady dalších dvou dílů byly vydány v listopadu roku 2002. Jednotlivé díly jsou ve shodě s originálem normy označeny jako 15408-1, 15408-2 a l5408-3. V současné době je oficiální verzí CC verze 2.3, která je vydána také jako norma ISO/IEC 15408:2005. Již je připravena verze 3, která se stane v blízké budoucnosti novou oficiální verzí. Texty jsou dostupné např. na oficiálních stránkách projektu CC (www.commoncriteriaportal.org). CC vznikla na základě již dříve používaných kritérií hodnocení, zejména amerických TCSEC [1] a Federal Criteria, evropských ITSEC [2] a kanadských CTCPEC [3]. Na vývoji CC se podílely národní organizace, působící v oblasti bezpečnosti a standardizace, z šesti států světa, jmenovitě Kanady, Francie, Německa, Holandska, Velké Británie a Spojených států amerických a jsou posledním výsledkem úsilí o vytvoření společného standardu v oblasti hodnocení bezpečnosti informačních technologií. V uvedených státech lze nalézt většinu z uznávaných laboratoří, které prováděly hodnocení bezpečnosti produktů v oblasti informačních technologií podle dříve široce akceptovaných kritérií TCSEC nebo ITSEC a v současné době přecházejí nebo již přešly výhradně na hodnocení podle CC. Jako formální základ pro vzájemné uznávání hodnocení uzavřely Kanada, Francie, Německo, Velká Británie a Spojené státy americké v roce 1998 dohodu “Arrangement on the Recognition of Common Criteria Certificates in the field of Information Technology Security”, zkráceně nazývanou CCRA ( CC Recognition Arrangement). K této dohodě “států produkujících certifikáty”, tedy provozujících vlastní národní schéma pro hodnocení a certifikaci IT, přistoupila v říjnu roku 1999 ještě Austrálie a Nový Zéland a je otevřena i pro další země, které prokáží, že disponují adekvátními kapacitami pro provádění hodnocení podle CC a splňují přísné požadavky vyslovené v textu CCRA. V následujícím období byla připravena úprava dohody v tom smyslu, že jejími účastníky mohou být i země, které neprovozují národní schéma pro hodnocení a certifikaci informačních technologií podle CC. Tuto rozšířenou dohodu podepsalo v květnu roku 2000 13 států, kdy k původním účastníkům přibylo 6 zemí, které nemají vyvinuto vlastní schéma pro hodnocení a certifikaci podle CC, avšak rozhodly se deklarovat, že uznávají hodnocení a certifikáty vydávané v rámci CCRA. Jedná se o Itálii, Španělsko, Holandsko, Norsko, Finsko a Řecko. V listopadu 2000 se připojil Izrael, v únoru 2002 Švédsko, v listopadu 2002 Rakousko, v září 2003 Maďarsko a Turecko, nejnověji pak Indie a Singapur, přičemž všechny tyto země mají v současné době pouze status účastníků využívajících certifikáty vydané v rámci CCRA. Do skupiny certifikáty produkujících účastníků přibylo v září 2004 Japonsko. Česká republika se připojila k dohodě v září roku 2004 jako certifikáty využívající účastník. Dohodu podepsal ředitel NBÚ Mgr. Jan Mareš, zástupcem ČR v řídícím výboru CCRA je Ing. Jaroslav Šmíd, ředitel Technické sekce NBÚ.
NBÚ
1
prosinec 2005
Byla také vyvinuta společná metodologie pro provádění hodnocení podle CC - Common Evaluation Metodology (CEM). CEM zahrnuje hodnocení na úrovních EAL1 až EAL4 včetně. V důsledku toho je uznávání hodnocení v rámci CCRA prozatím omezeno na tyto prvé čtyři úrovně záruk. Oficiální verzí CEM je nyní verze 2.3, která je zároveň normou ISO/IEC 18405:2005. Hodnocení podle CC se soustřeďuje na hodnocení produktů IT (např. operační systémy, databázové systémy, síťové produkty, specializované bezpečnostní produkty), hodnocení sady bezpečnostních požadavků a specifikací pro daný produkt nazývané v CC “bezpečnostní cíl” (Security Target, ST) a hodnocení implementačně nezávislé sady bezpečnostních požadavků nazývané v CC “profil ochrany” (Protection Profile, PP). ST a PP se hodnotí zejména z hlediska úplnosti, konzistence a technické správnosti a tedy vhodnosti pro proklamované použití. Jednotlivé země provozující vlastní schéma hodnocení a certifikace IT vydávají seznamy již certifikovaných produktů (EPL – Evaluated Products List) a seznamy produktů, které jsou právě hodnoceny. Dosažitelné jsou rovněž certifikační zprávy, které jsou nedílnou a velmi důležitou součástí certifikátu. Profily ochrany (PP), které úspěšně prošly hodnocením podle CC jsou zaznamenány do registrů PP a mluví se o nich jako o certifikovaných nebo někdy také registrovaných profilech. Tyto profily jsou dostupné pro obecné použití. Organizace NATO přijala rozhodnutí nahradit dosavadní kritéria pro hodnocení bezpečnosti produktů a systémů používaných pro zpracování NATO informací (založená na TCSEC) kritérii CC v roce 2003. Vzhledem k tomu, že nebylo dosaženo souhlasu všech členských států NATO s direktivou NATO o používání CC v NATO a uznávání hodnocení podle CC, byla direktiva přepracována do směrnice NATO, jedná se tedy nikoliv o používání povinné, ale o doporučené. Nicméně hodnocení provedená v rámci národních schémat pro hodnocení a certifikaci IT, začleněných v CCRA a provozovaných v členských zemích NATO, budou uznávána i v rámci NATO. Zároveň se předpokládá, že budou podle potřeb NATO vytvořeny i PP a ST, které budou klasifikovány jako utajovaná skutečnost NATO. Využívání CC je z uvedených důvodů nanejvýš vhodné i v České republice a je v souladu se záměry NBÚ i v oblasti ochrany utajovaných skutečností. NBÚ doporučuje, aby tvůrci bezpečnostní dokumentace informačních systémů určených pro nakládání s utajovanými skutečnostmi opustili terminologii TCSEC a ITSEC a podle svých možností využívali již terminologii zavedenou v CC. Vyhláška NBÚ o bezpečnosti informačních a komunikačních systémů a o certifikaci stínicích komor, vydaná v roce 2005, je (stejně jako předchozí vyhláška č.56/1999 Sb.) pojata natolik obecně, že požadavky počítačové a komunikační bezpečnosti je možno vyjádřit pomocí CC komponent a jejich kombinací, jednoho nebo více registrovaných profilů ochrany (Protection Profile, PP) a splnit je za pomoci využití produktů IT (operačních systémů, databázových systémů apod.) úspěšně hodnocených podle CC na požadované úrovni záruk za správnost implementace. V oblasti výstavby a hodnocení bezpečnosti informačních systémů pro zpracování utajovaných skutečností se tak CC mohou uplatnit v bezpečnostní politice IS pro specifikaci funkčních bezpečnostních požadavků počítačové a komunikační bezpečnosti a při stanovení požadované úrovně záruk (EAL) pro jednotlivé komponenty IS, v závislosti na stupni utajení, bezpečnostním provozním módu a analýze rizik. K tomu je možné a vhodné využívat již vytvořených a registrovaných PP ( tedy prošlých úspěšně hodnocením podle CC). Přednostně byly vytvořeny v NSA v USA profily analogické dosud používaným třídám C2 a B1 podle TCSEC. Prvý z profilů se nazývá CAPP [4], druhý LSPP [5], oba zahrnují úroveň záruk EAL3. Tyto profily, podobně jako řada dalších, jsou volně dostupné např. na webových stránkách organizací, které zastřešují hodnocení a certifikaci podle CC.
NBÚ
2
prosinec 2005
I v případě, že tvůrci dokumentace nejsou obeznámeni se CC natolik, aby jim využívání terminologie CC přinášelo usnadnění jejich práce, uplatní se CC významně při navrhování bezpečnosti informačního systému, když se zvažuje nasazení konkrétních komponent. V blízké budoucnosti bude totiž hodnocení a certifikace IT prováděno pouze podle CC. Zároveň vždy platí, že jsou-li dosažitelné, mají přednost certifikované produkty. Je ovšem třeba mít na paměti, že ani sestavení informačního systému z certifikovaných produktů nevede automaticky k získání systému zabezpečeného. Záleží i na schopnosti spolupráce mezi produkty a konkrétním provozním prostředí.
NBÚ
3
prosinec 2005
Pro úplnost uvedeme přibližnou převodní tabulku mezi úrovněmi záruk v TCSEC, ITSEC a CC:
TCSE
ITSEC
CC
E1 E2
EAL1 EAL2 EAL3
E3 E4 E5 E6
EAL4 EAL5 EAL6 EAL7
C C1 C2 B1 B2 B3 A1
PRO PRVNÍ SEZNÁMENÍ s CC jsou dále uvedeny základní informace o jejich obsahu, filosofii a základních pojmech. CC jsou rozdělena do 3 částí: Část 1: Úvod a všeobecný model (Part 1: Introduction and general model), Část 2: Bezpečnostní funkční požadavky (Part 2: Security functional requirements), Část 3: Požadavky na záruky bezpečnosti (Part 3: Security assurance requirements). Jak již napovídá rozdělení CC do částí, jsou bezpečnostní požadavky vyjádřeny (podobně jako v ITSEC) odděleně pro oblast požadované bezpečnostní funkčnosti a pro oblast požadované úrovně záruky za správnost. V prvé části jsou uvedeny definice pojmů, je vysvětlena základní filosofie CC a je prezentován obecný model hodnocení. Důležitou součástí je vymezení několika stavebních prvků, které slouží pro jednotné vyjádření bezpečnostních požadavků, ať již funkčních nebo na záruku. Jsou to prvek (element) jako dále nedělitelný bezpečnostní požadavek ověřitelný při hodnocení, komponenta (component) jako nejmenší množina prvků pro zahrnutí do vyšších struktur v CC, rodina (family) jako seskupení komponent, z nichž všechny slouží k naplnění téhož cíle, ale liší se přísností požadavků, třída (class) jako seskupení rodin, které pokrývají jednotlivé dílčí cíle a dohromady tvoří konsistentní celek pro dosažení určitého cíle celkového. Důležitým pojmem v CC je “profil ochrany” (Protection Profile, PP), který představuje implementačně nezávislou množinu bezpečnostních požadavků pro zajištění definovaných cílů. Tyto požadavky mohou být vybrány z CC nebo být vyjádřeny explicitně a mají zahrnovat i míru záruky hodnocení (Evaluation Assurance Level, EAL). PP se obvykle vytváří tak, aby byl opakovatelně použitelný a musí obsahovat i zdůvodnění bezpečnostních cílů a požadavků. Jiným seskupením bezpečnostních požadavků v CC je “balík” (package). Balík je kombinace komponent buďto funkčních nebo z oblasti záruk, sestavená tak, že může být opakovatelně použita pro splnění definovaných bezpečnostních cílů. Má vymezit požadavky známé jako užitečné a efektivní při naplňování těchto cílů. Příkladem může být množina funkčních požadavků pro volitelné řízení přístupu. Charakter balíku má rovněž míra záruky hodnocení (EAL). NBÚ
4
prosinec 2005
Pokud jde o specifický produkt nebo systém, nazývaný “předmět hodnocení” ( Target of Evaluation, TOE), vyjadřují se bezpečnostní požadavky, které jsou v něm realizovány, jako tzv. “bezpečnostní cíl” (Security Target, ST). ST je množinou bezpečnostních požadavků, vyjádřených odkazem na PP, na existující balíky, na komponenty CC nebo explicitně.
Ve druhé části jsou stanoveny funkční komponenty, které budou používány jako standardní způsob vyjadřování funkčních požadavků. Jde v podstatě o katalog funkčních komponent, rodin a tříd. Je definováno 11 funkčních tříd, jejichž originální anglické názvy/české názvy jsou: • Audit/Bezpečnostní audit • Identification and Authentication/Identifikace a autentizace • Resource Utilisation/Využití zdrojů • Cryptographic Support/Kryptografická podpora • Security Management/správa bezpečnosti • TOE Access/Přístup k TOE • Communications/Komunikace • Privacy/Soukromí • Trusted Path/Channels / Důvěryhodná cesta/kanály • User Data Protection/Ochrana uživatelských dat • Protection of the TOE Security Functions/Ochrana TSF Každá ze tříd obsahuje několik rodin, např. třída Audit obsahuje 6 rodin, zabývajících se různými aspekty auditování ( např. generování auditních dat, analýza auditních dat, uchování auditních záznamů). Každá rodina se pak skládá z jedné nebo několika komponent. Komponenty mohou být uspořádány hierarchicky a/nebo ne-hierarchicky. Např. rodina Generování dat bezpečnostního auditu (Audit Data Generation) obsahuje 2 ne-hierarchické komponenty, jednu týkající se generování auditních záznamů, druhou přiřazení uživatele a auditovatelné události.
Třetí část zahrnuje komponenty pro popis požadavků na záruky. Je katalogem komponent záruk, jejich rodin a tříd. Rovněž jsou v ní definována kritéria pro hodnocení profilů ochrany (PP) a bezpečnostních cílů (ST). V CC je pro oblast záruk definováno 8 tříd, jejichž originální anglické názvy/české názvy jsou: • Configuration Management/Správa konfigurace • Guidance Documents/Průvodní dokumentace • Vulnerability Assessment/Posouzení zranitelnosti • Delivery and Operation/Dodání a provoz • Life Cycle Support/Podpora životního cyklu • Assurance Maintenance/Údržba záruky • Development/Vývoj • Tests/Testy Kromě toho jsou zavedeny dvě další třídy, které obsahují požadavky na záruky pro PP a ST. Každá ze tříd obsahuje několik rodin, např. třída Vývoj (Development) obsahuje 7 rodin, týkajících se podrobnosti a přesnosti dokumentace k návrhu. Každá rodina obsahuje jednu nebo několik komponent, pro oblast záruk jsou komponenty přísně hierarchicky uspořádány. Např. rodina Funkční specifikace (Function specification) obsahuje 4 komponenty, z nichž každá následující vyžaduje vyšší složitost a formálnost při specifikaci funkčnosti.
NBÚ
5
prosinec 2005
Důležité je stanovení předdefinované vzestupné stupnice pro úroveň hodnocení. CC poskytuje 7 předdefinovaných balíků pro záruky (assurance package), známých jako Evaluation Assurance Levels (EALs), v českém překladu míry záruky hodnocení. Jsou dobře promyšlené a vyvážené, obecně aplikovatelné. Analogii lze nalézt v třídách E1 až E6 v kritériích ITSEC. Veškerá hodnocení IT podle CC se dnes provádějí na úrovni některé z EAL, převážně do úrovně EAL4.
Stručně lze jednotlivé úrovně popsat následujícím způsobem: EAL1 je vhodná, pokud je vyžadována určitá základní důvěra ve správnost fungování hodnoceného PP, ST nebo TOE, avšak hrozby nejsou považovány za vážné. Důvěry se dosahuje nezávislým testováním shody hodnoceného PP, ST nebo TOE s neformální funkční specifikací a zkoumáním předložených příruček pro uživatele. EAL2 již vyžaduje spolupráci vývojáře, který musí v podstatě dodat funkční specifikace, určité informace o návrhu bezpečnostních funkcí (na úrovni globálního návrhu, high-level design) a výsledky testování, avšak vývoj si nevyžaduje více úsilí nežli je potřebné pro dodržování dobré komerční praxe, a v podstatě nepřináší zvýšení nákladů. Poskytuje nízkou až střední nezávisle ověřenou bezpečnost v případě, že není dostupná kompletní informace z fáze vývoje. Důvěry se dosahuje analýzou vyžadované dokumentace, ověřením výsledků některých testů, analýzou síly funkcí a analýzou zřejmých zranitelností. Pro TOE musí být sestaven seznam konfigurace a vypracovány procedura pro bezpečnou instalaci, generování a spouštění. EAL3 je možno ještě dosáhnout bez podstatných změn základních existujících vývojářských praktik. Je aplikovatelná v případě, že se vyžaduje střední úroveň nezávisle ověřené bezpečnosti a je opřena o důkladné zkoumání TOE (ST, PP). Navíc oproti EAL2 se vyžaduje rozsáhlejší testování, kontroly vývojového prostředí a zajištění správy konfigurace. EAL4 stále umožňuje pohybovat se v rámci dobré komerční vývojářské praxe. Jakkoliv přísné jsou tyto praktiky, nevyžadují podstatné specializované znalosti, dovednosti a jiné zdroje. EAL4 je nejvyšší úrovní záruk, kterou lze dosáhnout (za rozumné náklady) zpětně pro již existující produkt. Poskytuje střední až vysokou úroveň záruky nezávisle ověřené bezpečnosti pro běžnou komoditu produktů a vyžaduje ze strany vývojáře nebo uživatelů připravenost k pokrytí dodatečných specifických nákladů spjatých s bezpečnostním inženýrstvím. Navíc oproti EAL3 se již vyžaduje také detailní návrh (low-level design) TOE, neformální model bezpečnostní politiky TOE a dodání určité podmnožiny implementace (např. část zdrojového kódu bezpečnostních funkcí). Nezávislá analýza zranitelností musí demonstrovat odolnost vůči průniku útočníků s nízkým potenciálem pro útok. Kontroly vývojového prostředí jsou doplněny modelem životního cyklu, stanovením nástrojů a automatizovanou správou konfigurace. EAL5 vyžaduje kromě přísného uplatnění dobré komerční vývojářské praxe aplikaci speciálních technik bezpečnostního inženýrství ve středním rozsahu. Dané TOE bude pravděpodobně již navrženo a vyvíjeno s cílem dosáhnout úrovně záruk EAL5. Nepředpokládá se nicméně velké zvýšení nákladů oproti EAL4. EAL5 je tak vhodná v případech, kdy se vyžaduje vysoká úroveň záruky nezávisle ověřené bezpečnosti aniž by náklady na specializované techniky byly nerozumně vysoké. Navíc oproti EAL4 je vyžadováno dodání kompletní implementace TOE, formální model bezpečnostní politiky TOE, poloformální presentace funkčních specifikací, poloformální globální návrh (high-level design) a poloformální demonstrace korespondence. Nezávislá analýza zranitelností musí demonstrovat odolnost vůči průniku útočníků se středním potenciálem pro útok. Vyžaduje se také analýza skrytých kanálů a modularita návrhu. EAL6 vyžaduje aplikaci technik bezpečnostního inženýrství do přísného vývojového prostředí a je určena pro vývoj TOE sloužícího pro ochranu vysoce hodnotných aktiv proti význačným rizikům, kdy lze odůvodnit dodatečné náklady. Navíc oproti EAL5 se vyžaduje poloformální detailní návrh, rozsáhlejší testování, návrh TOE musí být modulární a zvrstvený, prezentace implementace strukturovaná. Nezávislá analýza zranitelností musí demonstrovat odolnost vůči průniku útočníků s vysokým potenciálem pro útok. Analýza skrytých kanálů musí být systematická. Vyšší nároky jsou kladeny na správu konfigurace a kontroly vývojového prostředí.
NBÚ
6
prosinec 2005
EAL7 je použitelná pro vývoj produktů určených do extrémně rizikového prostředí a/nebo kde vysoká hodnota aktiv ospravedlňuje vyšší náklady. Praktické použití EAL7 je v současnosti omezeno na TOE a úzce vymezenou bezpečnostní funkčností, kde lze provést formální analýzu v požadované míře. Vyžaduje se plná formalizace, formální model bezpečnostní politiky, formální presentace funkčních specifikací and high-level návrhu, poloformální detailní návrh, formální a poloformální demonstrace korespondence. Testování se vyžaduje na úrovni bílé skříňky (white-box) a musí být dosaženo úplného nezávislého potvrzení výsledků všech předložených testů. Složitost návrhu musí být minimalizována.
Odkazy na užitečné webové stránky se CC informacemi Oficiální stránky projektu Common Criteria: http://www.commoncriteriaportal.org Stránky institucí provozujících národní schéma pro hodnocení a certifikaci IT podle CC, oprávněných k vydávání certifikátů IT v rámci CCRA: Velká Británie Kanada USA Austrálie Německo Francie Japonsko
- http://www.cesg.gov.uk/site/iacs/index.cfm - http://www.cse-cst.gc.ca/en/services/common_criteria/common_criteria.html - http://niap.nist.gov/cc-scheme - http://www.dsd.gov.au - http://www.bsi.bund.de - http://www.ssi.gouv.fr - http://www.nite.go.jp
Na většině z těchto stránek lze nalézt i text CCRA.
Odkazy v textu [1] Trusted Computer System Evaluation Criteria (TCSEC), DoD USA, 1985 [2] Information Technology Security Evaluation Criteria (ITSEC), EC, 1991 [3] Canadian Trusted Computer Product Evaluation Criteria (CTCPEC), The Gov.of Canada, 1993 [4] Controlled Access Protection Profile (CAPP), ISSO 1999, NSA USA [5] Labeled Security Protection Profile, (LSPP), ISSO 1999, NSA USA
Použitá literatura Common Criteria for Information Technology Security Evaluation, verze 2.1 Common Evaluation Metodology, ver. 1.0 Common Criteria for Information Security Evaluation User Guide
NBÚ
7
prosinec 2005
