Informatické kolokvium

Transkrypt

1 w ΛΞΠ± ΦΩfffiflffi» μνοßρχψ!"#$%&'()+,-./012345<y A } Management informační bezpečnosti Informatické kolokvium Jan Staudek

2 Bezpečnost, informační bezpečnost Bezpečnost stav, ve kterém nehrozí nebezpečí, újma, poškození,... Informační bezpečnost stav informačních systémů vekterém nehrozí neautorizované zpřístupňování nebo modifikace informací v nich uchovávaných, zpracovávaných a/nebo přenášených, odmítání jejich služeb autorizovaným uživatelům, poskytování jejich služeb neautorizovaným uživatelům, avekterém se adekvátně používají nástroje pro detekování, dokumentování a snižování rizik takových hrozeb, resp. pro jejich plnou eliminaci. Dosažená úroveň informační bezpečnosti se odvozuje od chápání informační bezpečnosti uživateli, provozovateli a dodavateli bezpečnostních, operačních, aplikačních,...(it) systémů Jan Staudek, FI MU Brno Informatické kolokvium,

3 Condicio sine qua non dosažení (informační) bezpečnosti jsou dostupné relevantní bezpečnostní nástroje pro ochranu..., detekci..., snižování rizik,... všechny bezpečnostní nástroje, adekvátní prodanýpřípad, se efektivně používají a eliminace rizik hrozeb, pro které přímé relevantníbezpečnostní nástroje dostupné nejsou, je dosažitelná kombinací účinků použití více bezpečnostních nástrojů Jan Staudek, FI MU Brno Informatické kolokvium,

4 Dehonestující realita Dehonestující realita škála relevantních bezpečnostních IT nástrojů nebude nikdy úplná z hlediska množiny potenciálních hrozeb reálné účinky dostupných bezpečnostních nástrojů v době jejich uplatnění mnohdy nesplňují jejich původně zamýšlený cíl Závěry Splnění nutné podmínky pro dosažení informačníbezpečnosti je nekonečný proces nemá smysl si klást za cíl nalezení svatého grálu absolutní bezpečí má smysl smysluplnými cestami se pokoušet o jeho nalezení apostupněslepé/neefektivní cesty eliminovat Jan Staudek, FI MU Brno Informatické kolokvium,

5 Škála bezpečnostních IT nástrojů nebudenikdyúplná Pohybujeme se ve světě (informačních) technologií Technologie The application of scientific knowledge to practical purposes in a particular field....a technical method of achieving a practical purpose. Technologie = jak něco DĚLAT,,něco postup, metoda,...dostupnádíky technologickému rozvoji Trvalá snaha dělat věci lépe/efektivněji trvalý rozvoj technologií Bezpečnost The state of being free from danger or injury. Bezpečnost = jak něco NEDĚLAT Dosahování bezpečnosti kráčí za rozvojem technologií, : ( Jan Staudek, FI MU Brno Informatické kolokvium,

6 Generický problém budování bezpečných (IT) systémů (IT) systém bude úspěšný (bezpečný) když bude zajišťovat ochranu proti všem možným útokům, tj. vč. útoků, které se v době jeho tvorby dosud nevyskytly Útočník bude úspěšný, když pro útok využije jedinou nedokonalost v bezpečnostních ochranách a může vyčkávat až mu technologický rozvoj poskytne adekvátní útočný nástroj, jehož existenci tvůrci systému vůbec nepředpokládali Dokonalost funkcionality individuálních bezpečnostních (např. kryptografických) nástrojů ještě nezaručuje dosažení požadované úrovně (kvality) bezpečnosti, když požadovaný účinek se dosahuje jejich kombinací viz např. dále uvedený příklad problému důvěryhodnosti digitálního podpisu Jan Staudek, FI MU Brno Informatické kolokvium,

7 Vybrané mýty a některá další fakta Vybrané mýty Nepopiratelnost (Non-repudiability) zajistí digitální podpisy Hrozba krádeže identity (Identity Theft) vesvětě budovaném na bázi IT je, a čím dál více bude, zdrojem nejvýznamějších rizik Některá další fakta o charakteru nastupujících hrozeb Měnísecharakterútoků vedených na IT Dosáhlo se racionální zvládnutí ochran proti fyzickým útokům (ztráta energie, ztráta propojení, ztráta dat...) Jakžtakžsepostupnězvládajíochranyprotisyntaktickým útokům (buffer overflow, command injection, protokolové díry,...) Začíná rychlýnárůst výskytů sémantických útoků (útoků cílených na to, jak lidé chápou obsah, nikoli na formu) Složitost skladby IT nástrojů exponenciálně roste Mění se zranitelnost aplikací pojejichpřevodu do síťového prostředí Jan Staudek, FI MU Brno Informatické kolokvium,

8 Hrozba sémantických útoků Jejich riziko rychle roste díky,,prosíťování světa Lidé majítendencivěřit tomu co čtou na potvrzování věrohodnosti,,není čas lidé jsoučasto obětmi chybných/falšovaných statistik, legend apodvodů Podfuk se síťovým prostředím s velkou pravděpodobností rozšíří extrémně rychle Komunikační média se používají prošíření,,věrohodných stupidností již pocelouvěčnost Současné- a blízko-budoucí počítačové sítě spuštění takových útoků usnadňují a zprávy diseminují extrémně rychle Digitální podpisy, autentizace, integritní opatření,... šíření podfuků nezabrání sémantické útoky jsou vedeny na HCI, nejméně bezpečné rozhraní(internetu) Jan Staudek, FI MU Brno Informatické kolokvium,

9 Hrozba sémantických útoků, 2 Pouze,,amatér či,,laik útočí na počítače a software realizuje fyzické a syntaktické útoky Profesionál útočí na lidi realizuje sémantické útoky ochrana proti sémantickým útokům musí být cílená nasociální řešení, ne na matematicko-logická (a technická) řešení Jan Staudek, FI MU Brno Informatické kolokvium,

10 Principy e-komerce usnadňující devastující podvody Snadnost automatizace procesů stejná automatizace, která činní e-komerci efektivnější než klasickýbyznys,zefektivňuje i provádění podvodů podvod vyžadující vynaložení desítek minut času v papírovém systému lze snadno provést,,na jedno kliknutí resp. snadno periodicky opakovat principem 24 7 singulární podvod s nízkou škodou ignorovatelný v papírovém systému může být hrozbou s rizikem velké škody v e-komerčním systému Izolovanost jurisdikce v místech zdroje a cíle útoku Geografie v elektronickém světě nehraježádnou roli Útočník nemusí být fyzicky blízko systému, na který útočí. Útočit může ze země, která,,nevydává zločince, která nemá adekvátní policejní aparát, kteránemápotřebné právní zázemí vhodnékestíhání,... Jan Staudek, FI MU Brno Informatické kolokvium,

11 Principy e-komerce usnadňující devastující podvody,2 Rychlost šíření,,prosíťovaným světem padělatel papírových peněz monetární systém nezdevastuje široká diseminace padělatelského nástroje je nereálná, rychlé a snadno nevystopovatelné šíření padělků je obtížné zpráva jak podvést široce používaný e-komerční systém,,diseminovaná Internetem (příp. s připojeným adekvátním softwarovým nástrojem) umožní,,si vhodně kliknout statisícům lidí během několika dní znalost jak podvést získal 1 člověk, útočit mohou statisíce lidí vextrémně krátkém časovém intervalu Jan Staudek, FI MU Brno Informatické kolokvium,

12 Důvěryhodnost nepopiratelnosti, co je to digitální podpis? Předpoklad mnoha současných právních norem: Důvěryhodnost digitálního podpisu je alespoň taková jako důvěryhodnost rukopisného podpisu Splňuje digitální podpis tento předpoklad? Formálně použitý matematický (kryptologický) základ je vyhovující Sémanticka aktu digitálního podpisu předpokladu nevyhovuje Předpoklad současných právních norem: Alicin podpis dokumentu indikuje odsouhlasení jeho obsahu Alicí Důvěryhodnost podpisu lze zesílit provedním podpisu u notáře Z digitálního podpisu Alice nelze implicitně odvodit, že Alice dokument viděla Alice v žádném případě nepočítala podpis = dokument P Kmod n, výpočet Alicina podpisu,,dokumentu (kterého???) dělal její počítač Jan Staudek, FI MU Brno Informatické kolokvium,

13 Důvěryhodnost nepopiratelnosti, co je to digitální podpis?, 2 Alice musí mít důvěru v to, že její aplikační systém podpisuje dokument, který jí prezentuje (problém trojských koňů) vjejím počítači nikdo neodchytává jejípk uchování PKvbezpečném modulu (karta) ovšem neřeší problém podvrženífalešného dokumentu trojským koněm Má-li být duvěryhodný Alicin podpis dokumentu, musí být důvěryhodný Alicin počítač podpisující dokument Nelze se spoléhat pouze na matematiku pro dosažení bezpečnosti Podstatně vyšší riziko představuje a bude představovat důvěryhodnost použitého hardware a software Digitální podpis Alice vypovídá pouze o tom, že v době podpisování byl použitý Alicin PK Digitální podpis nic neříká o tom,že Alice podepsala dokument, který viděla při podpisování Zadání pro budoucno jak zajistit, aby Alicin počítač byl nezfalšovatelný (tamperproof ) Jan Staudek, FI MU Brno Informatické kolokvium,

14 Hrozba krádeže identity vs. hrozba podvodných transakcí Identita totožnost entity (osoby, místa, věci,...obecně jistého objektu), resp. vyjádření vztažnosti (vymezení) entity vůči jiným entitám Identifikace určení, kterou entitu určuje jméno udané vjistém kontextu, příp. plus jaký má tato entita vudaném kontextu profil (výsady, omezení,...) Autentizace proces ověření, že entita je tou entitou, za kterou se prohlašuje Identitu nelze ukrást, identita je atribut a ne objekt Identitu lze změnit, resp. ztratit, ale ne dost dobře ukrást. Hrozbou neníkrádežidentity, hrozbou je (neúmyslně) nesprávné napodobení identity, resp. hrozbou je neoprávněné napodobení identityscílem podvést Jan Staudek, FI MU Brno Informatické kolokvium,

15 Hrozba krádeže identity vs. hrozba podvodných transakcí, 2 Podmínky, které využívá podvod napodobením identity osoba zanechává svá soukromá (= nemají být veřejně dostupná) personální (identitní) data na mnoha místech (vč. počítačů jiných stran), kde jsou potenciálně dostupnáútočníkům vizteze:bezpečnost kráčí za technologickým rozvojem pro provedení podvodu napodobením identity nenívesměs nutné vynakládat enormníúsilí identitajevesměs ověřovaná jednoduše a ledabyle srv. princip použití platební karty a zajišťování provozních podmínek při výrobě IOpoužitých pro konstrukci platebního terminálu Převládá trend koncentrace na řešení prvního problému omezování přístupu k OU Skutečný problém je druhý zmíněný problem pokud chceme snižovat rizika útoků využívající hrozby napodobení identity, je nutné se více koncentrovat na prevenci a detekci podvodných transakcí a než na bezpečnost přístupu k OU Jan Staudek, FI MU Brno Informatické kolokvium,

16 Hrozba enormního nárůstu složitosti a rozsahu Jan Staudek, FI MU Brno Informatické kolokvium,

17 Hrozba enormního nárůstu složitosti a rozsahu, 2 Enormě narůstá složitost vnitřních algoritmů (jádra) OS počty instrukcí spotřebovaných ve Windows při Zaslání zprávy mezi procesy: 6K 120 K podle použité metody Vyvtoření procesu:3m Vytvoření vlákna: 100K Vytvoření souboru: 60K Vytvoření semaforu: 10K 30K Nahrání DLLknihovny:3M Obsluha přerušení/výjimky: 100K 2M Přístup do systémové databáze Registry : 20K... Jan Staudek, FI MU Brno Informatické kolokvium,

18 Existuje řešení? Pesimismus není na místě Dosažení efektivní úrovně bezpečnosti IT systému výrazně podpoří jeho bezpečnostní politika (BP ITS) množina pravidel určujících užívání relevantních bezpečnostních nástrojů řádně vypracovaná a prosazovaná BP, BP s kvalitou odpovídající výši potenciálních škod BP periodicky auditovaná zhlediskajejího dodržování ajejíúčinnosti BP periodicky upřesňovaná podlevýsledků auditu BP vypracovaná v úzké návaznosti na ostatní politiky organizace tak, aby byla zaručená adekvátní kontinuita plnění cílů byznysu organizace, která sespoléhá napoužívání ITS, a to i při selhání některých ochran v ITS Jan Staudek, FI MU Brno Informatické kolokvium,

19 Dimenze řešení dosažení efektivní informační bezpečnosti zda použité bezpečnostní nástroje a jejich skladba odpovídá relevantním bezpečnostním cílům ISO/IEC 17779, původně britský standard BS 7779, Code of practice for information security management v r se plánuje vydání inovace pod číslem ISO/IEC doporučení jak navrhnout, implementovat, udržovat a vylepšovat správu informační bezpečnosti v organizaci ISO/IEC 27001, původně britský standard BS Information security management system Requirements základ pro činnost externí třetí strany *provádějící audit technik správy informační bezpečnosti a *vydávající o jejich validitě certifikát zda síla záruk za validitu použitých nástrojů a jejich skladby je adekvátní velikosti rizik velikost souladu se vhodnými implementačními kritérii příklad hodnotící kritéria Common Criteria, ISO/IEC Jan Staudek, FI MU Brno Informatické kolokvium,

20 ISO/IEC 17779, BS 7779, Code of practice for... doporučení jak navrhnout, implementovat, udržovat a vylepšovat správu informační bezpečnosti v organizaci neřeší se technické aspekty informační bezpečnosti uvádí se soubor postupů při správě informační bezpečnosti (většina škod na informačních aktivech vzniká chybou postupu člověka a ne technickou závadou a často mimo počítačový systém) definice cca 130 nástrojů seskupených do cca 10 kategorií bezpečnostní politika, perzonální bezpečnost, fyzická bezpečnost a bezpečné prostředí, provozní a komunikační bezpečnost, řízení přístupu, akvizice, vývoj a údržba IT systémů, ochrana kontinuity byznys procesů, zajištění vyhovění omezujícím podmínkám,... Jan Staudek, FI MU Brno Informatické kolokvium,

21 ISO/IEC 17779, BS 7779, Code of practice for... doporučení jak tvořit vlastní nástroje pro specifická prostředí elementární, počáteční materiál pro posouzení vlastností a potřeb informační bezpečnosti v obecném byznysu standard je spíše kodexem, radami pro budování bezpečného systému, obvyklé je deklarovat vyhovění standardu, certifikace se neprovádí v r se plánuje vydání inovace pod číslem ISO/IEC Jan Staudek, FI MU Brno Informatické kolokvium,

22 ISO/IEC 27001, BS ,... Requirements požadavky na implementaci systému správy informační bezpečnosti, ISMS Information security management system požadavky na implementaci opatření podle ISO/IEC nezabývá sekonkrétními nástroji správy informační bezpečnosti specicikuje jak vybudovat systém, který posuzuje, implementuje, monitoruje a udržuje bezpečnostní systém organizace detailní popis požadavků, které má ISMS organizace splnit, ISMS lze proti ISO/IEC certifikovat návod pro činnost externí třetí strany provádějící audit technik správy informační bezpečnosti v organizaci Jan Staudek, FI MU Brno Informatické kolokvium,

23 Generická struktura politiky informační bezpečnosti Šablona BP vyhovující standardu ISO/IEC Organizační zajištění informační bezpečnosti 2. Klasifikace informacíadat 3. Řízení přístupu k informacím a systémům v oblasti 4. Zpracování informacíadokumentů 5. Nákup a udržování komerčního software 6. Zabezpečování hardware, periférií a pod. 7. Ochrana před kyber-kriminalitou 8. Informačníbezpečnost e-byznysu 9. Vývoj a údržba vlastního software 10. Areálová bezpečnost 11. Řešení personálních problémů souvisejících s bezpečností 12. Výchova a zvyšování bezpečnostního uvědomění zaměstnanců 13. Vyhovění požadavkům práva a omezením stanovených politikami 14. Detekce bezpečnostních incidentů a reakce na jejich výskyt 15. Plány zachování kontinuity byznysu Jan Staudek, FI MU Brno Informatické kolokvium,

24 Schéma certifikace (kvality, bezpečnosti,...) v EU ex. iniciativa orgán EA, European co-operation for Accreditation ex. National Accreditation Body, NAB národní instituce, u kterých se akreditují pouzovatelé ISMS Certification Bodies, CB, působící vdanézemi ex. procedury, které musí NBA sdružené v EA používat, aby byly certifikáty ISMS, vydané,,jejich CB, vzájemně uznatelné ex. dokument EA7/03 návod pro NBA specifikující procesy certifikace ISMS prováděné CB při posuzování ISMS proti standardu ISO/IEC 27001:2005 CB (periodicky) posuzuje ISMS zájemce o certifikát proti standardu ISO/IEC 27001:2005 na komerční bázi Jan Staudek, FI MU Brno Informatické kolokvium,

25 Schéma certifikace (kvality, bezpečnosti,...) v EU/ČR příklady National Accreditation Body, NAB United Kingdom Accreditation Service, UKAS, Český institut pro akreditaci, o.p.s., CAI, Národníakreditační orgán založenývládou ČR poskytující služby ve všech oblastech akreditace jak státním, tak privátním subjektům. příklady Certification Bodies, CB BSI Assessment Services Limited Det Norske Veritas,... CQS Sdružení procertifikacisystémů jakosti, provádí mj. i certifikace systémů řízení bezpečnosti informací dle BS 7799 část 2:2002; ISO/IEC 27001:2005 člen mezinárodního sdružení IQNet síť certifikačních orgánů procertifikacisystémů řízení Jan Staudek, FI MU Brno Informatické kolokvium,

26 Požadavky na záruku z hlediska implementace Common Criteria, ISO/IEC 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 azáruky Development/Vývoj Tests/Testy Jan Staudek, FI MU Brno Informatické kolokvium,

27 Dva typy požadavků na IT bezpečnost podle CC funkční požadavky cíle CO PRODUKT DĚLÁ, resp. MÁ DĚLAT? definice bezpečného chování (identifikace, autentizace, nepopiratelnost,...) implementací funkčních požadavků vznikají bezpečnostní funkce požadavky zaručitelnosti bezpečnosti JE PRODUKT UDĚLÁN DOBŘE A DĚLÁ COMÁDĚLAT? určeno pro ustanovení důvěry v bezpečnostní funkce prokázuje sesprávnost implementace prokázuje se účinné splnění cílů stanovení síly (odolnosti) bezpečnostní funkce jaké důkazy musí poskytnout vývojář jaké důkazy musí vypracovat hodnotitel rozsah, hloubka, přísnost hodnocení Jan Staudek, FI MU Brno Informatické kolokvium,

28 Mezinárodní uznávání záruk z hlediska implementace Pro komerční životaschopnost hodnocení je nutné, aby bylo uznáváno v co nejširším obchodním prostoru Hodnotící autority musí souhlasit s uznáváním certifikátů vydaných hodnotícími centry, která pod ně nespadají 22 zemí uznává Common criteria recognition arrangement (CCRA), které totouznávání garantuje Stránky vybraných institucí provozujících národní schémata pro hodnocení a certifikaci IT podle CC, oprávněných k vydávání certifikátů IT v rámci CCRA: UK, USA, Německo, CZ, NBU certifikáty uznává, žádná organizace je nevydává Jan Staudek, FI MU Brno Informatické kolokvium,

29 EALs, Evaluation Assurance Levels, přehled úrovně zaručitelnosti bezpečnosti TOE odvozené z hodnocení 7 definovaných úrovní, základ vzájemného uznávání EAL1, funkčně testovanýtoe EAL2, strukturálně testovanýtoe( TSEC C1) EAL3, metodicky testovaný akontrolovanýtoe( TSEC C2) EAL4, metodicky navržený, testovaný apřezkoumaný TOE ( TSEC B1) EAL5, semiformálně navržený atestovanýtoe( TSEC B2) EAL6, semiformálně navrženýsesemiformálně ověřeným návrhem a testovaný TOE( TSEC B3) EAL7, formálně navrženýsformálněověřeným návrhem a testovaný TOE( TSEC A1) Jan Staudek, FI MU Brno Informatické kolokvium,

30 Charakteristiky EAL1 požaduje se správný (bezchybný) provoz TOE žádné hrozby nejsou považované za závažné vůči aktivům TOE požaduje se získání nezávisle vyslovené záruky podporující tvrzení, že byla vynaložena patřičná starost o ochranu DůvěraEAL1sedosahuje nezávislým testováním shody hodnoceného PP, ST nebo TOE sneformální funkčníspecifikacía zkoumáním předložených příruček pro uživatele hodnocení je proveditelné bezspoluúčasti a bez pomoci vývojáře vyžaduje vynaložení minimálních nákladů cílová EALpři zabezpečování systémů obsahujících např. pouze osobní údaje, evidenci DKP,... Jan Staudek, FI MU Brno Informatické kolokvium,

31 Charakteristiky EAL2 vyžaduje spolupráci vývojáře, vývojář musí dodat funkční specifikace určité informaceonávrhu bezpečnostních funkcí (na úrovni globálního návrhu, high-level design) a výsledky testování vývoj si nevyžaduje více úsilí nežli je potřebné pro dodržování dobré komerční praxe vhodná EAL pro případy, kdy je vývojář dostupný omezeně vývoj nezpůsobuje 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 Jan Staudek, FI MU Brno Informatické kolokvium,

32 Charakteristiky EAL2 Důvěryhodnost 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 Pro TOE musí být vypracovány procedury pro bezpečnou instalaci, generování aspuštění cílová EAL při zabezpečování systémů např. podnikového účetnictví Jan Staudek, FI MU Brno Informatické kolokvium,

33 Charakteristiky EAL3 maximálně vysoká úroveň záruky bezpečnosti TOE vyslovitelná na základě zjištění, že se při návrhu průkazně použilo bezpečnostní konstruování, a to aniž by vývojář musel podstatně měnit své dobré vývojové praktiky vyžaduje se 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í, kontrola vývojového prostředí a zajištění správy konfigurace hodnotí sedůkazy testování návrhu na vysoké (zdrojové) úrovni EAL vhodná pro podmínky, ve kterých vývojáři nebo uživatelé požadují získání nezávisle vyslovené průměrné úrovně záruky bezpečnosti a přitom nechtějí provádět rozsáhlý re-engineering bankovní software pro styk se zákazníky, software CA v PKI,... Jan Staudek, FI MU Brno Informatické kolokvium,

34 Charakteristiky EAL4 stále umožňuje pohybovat se v rámci dobré komerční vývojářské praxe nevyžadujísepodstatné specializované znalosti, dovednosti ajinézdroje nejvyšší úroveň 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ů vyžaduje ze strany vývojáře nebo uživatelů připravenost k pokrytí dodatečných specifických nákladů spjatých sbezpečnostním inženýrstvím Jan Staudek, FI MU Brno Informatické kolokvium,

35 Charakteristiky EAL4 Navíc oproti EAL3 se již vyžaduje také detailní návrh (low-level design) TOE, neformální modelbezpečnostní politiky TOE a dodání určité podmnožiny implementace (např. části 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 Jan Staudek, FI MU Brno Informatické kolokvium,

36 Charakteristiky EAL5 vyžaduje se přísné uplatnění dobré komerční vývojářské praxe aplikace speciálních technik bezpečnostního inženýrství vestředním rozsahu Daný TOE bude pravděpodobně jižnavržen a vyvíjen s cílem dosáhnout úrovně záruk EAL5 Nepředpokládá senicméně velkézvýšení nákladů oprotieal4 EAL5 je vhodná když se vyžaduje vysoká úroveň záruky nezávisle ověřené bezpečnosti aniž by náklady na specializované techniky byly nerozumně vysoké maximálně vysoká úroveň záruky bezpečnosti vyslovitelná na základě zjištění průkazného používaného bezpečnostního konstruování, založeného na dokonalých komerčních vývojových praktikách podporovaných běžnou, nikoli extrémní aplikací speciálních bezpečnostních technik Jan Staudek, FI MU Brno Informatické kolokvium,

37 Charakteristiky EAL5 vhodná pro podmínky, ve kterých vývojář nebo uživatel nechtějí hradit neodůvodněně zvýšené náklady na použití speciálních bezpečnostních technik Navíc oproti EAL4 je vyžadováno dodáníkompletní implementace TOE, formální modelbezpeč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 Jan Staudek, FI MU Brno Informatické kolokvium,

38 Charakteristiky EAL6 úroveň záruky bezpečnosti umožňující vytvářet zvláště propracované produkty nebo systémy IT pro ochranu aktiv s vysokou hodnotou provozované ve vysoce rizikových prostředích vhodná pro vývoj bezpečných produktů nebo systémů IT, které se mají používat ve vysoce rizikových prostředích a kde hodnota chráněných aktiv ospravedlňuje dodatečné vyšší náklady vyžaduje aplikaci technik bezpečnostního inženýrství do přísného vývojového prostředí 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 Jan Staudek, FI MU Brno Informatické kolokvium,

39 Charakteristiky EAL6 Navíc oproti EAL5 se vyžaduje poloformální detailní návrh, rozsáhlejší testování, návrh TOE musí být modulární avrstvový, 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 na kontroly vývojového prostředí Jan Staudek, FI MU Brno Informatické kolokvium,

40 Charakteristiky EAL7 EAL použitelná pro vývoj bezpečných IT produktů nebo systémů určených pro provozování ve vysoce rizikových prostředích, když vysoká hodnota aktiv ospravedlňuje vynaložení vyšších nákladů praktická použitelnost je v současné době omezena na produkty nebo systémy IT s úzce zaměřenou bezpečnostní funkcionalitou, kterou lze rozsáhle analyzovat formálně Vyžaduje se plná formalizace, formální modelbezpečnostní politiky, formální presentace funkčních specifikací ahigh-levelnávrhu, poloformální detailní návrh, Jan Staudek, FI MU Brno Informatické kolokvium, formální a poloformální demonstrace korespondence

41 Charakteristiky EAL7 Testování se vyžaduje na úrovni bílé skříňky (white-box) testy se definují se znalosti vnitřní struktury 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 Jan Staudek, FI MU Brno Informatické kolokvium,