====== 8. "Papírová bezpečnost II" ====== Hodnocení bezpečnosti, kritéria a procesy hodnocení. Standardy bezpečnosti IT a kryptografie, legislativa a kryptologie. ====== Vypracování ====== * Mírně se překrývá s [[mgr-szz:in-ins:6-ins|6. otázkou oboru INS]] ===== Hodnocení bezpečnosti, kritéria a procesy hodnocení ===== Hodnocení bezpečnosti se provádí, aby se zjistila dosažená úroveň bezpečnosti. K hodnocení bezpečnosti je využíván standard Common Criteria (ISO/IEC 15408) a kritéria OWASP (Open Web Application Security Project). ==== Common Criteria ==== K hodnocením se využívá hodnotících kritérií což je obecně seznam podmínek které vyvíjený/kupovaný produkt nebo systém má být schopný (musí) plnit. Common Criteria poskytují framework, který umožňuje, aby uživatel specifikoval požadavky na bezpečnost produktu, výrobce specifikoval vlastnosti produktu a nezávislý hodnotitel posoudil zda výrobek odpovídá požadavkům. Historicky se namísto Common Criteria v Evropě používali ITSEC (IT Security Evaluation Criteria) a v USA TCSEC (Trusted Computer Security Evaluation Criteria). Tento standard se dělí do 3 částí: * Part 1: Introduction and general model * Part 2: Security functional requirements * Part 3: Security assurance requirements * historicky se používaly ITSEC (Evropa) a TCSEC (aka Orange Book, USA) * hodnocení provádí hodnotitel, certifikační autorita (NIST nebo v Evropě komerční organizace) pak vydává certifikát * hlavní pojmy: * **Target Of Evaluation** - produkt/systém, který se má hodnotit * **Security Functional Requirements** (SFR) - bezpečnostní funkce poskytované produktem/systémem (TOE), CC obsahuje katalog takových funkcí * **Protection Profile** - dokument popisující bezpečnostní požadavky na určitou třídu zařízení/systémů, jeden nebo více společně mohou sloužit jako základ pro Security Target * **Security Target** - dokument popisující vlastnosti (SFRs), které má TOE mít * **Security Assurance Requirements** (SAR) - vyjadřují míru jistoty, že produkt/systém splňuje funkční požadavky * **Evaluation Assurance Level** - číselná hodnota (0-7) vyjadřující hloubku hodnocení, každá úroveň definuje množinu SARs, které mají být naplněny * konrétní TOE je hodnocený proti konkrétnímu ST do určité úrovně prověření (EAL) - od 0 (nevyhovující) po 7 (formálně navržený s formálně ověřeným návrhem a testovaný TOE) * vyšší EAL neznamená lepší bezpečnost, pouze vyšší míru prověření Přínosy hodnocení produktu jsou: * Provedení hodnocení může otevřít cestu na nové trhy (státní zpráva, zdravotnictví, armáda) * Výsledky hodnocení bývají dobrý reklamní nástroj * Hodnocení může odstranit starost, zda výrobek obstojí na trhu Problémy hodnocení: * Jakákoliv změna PH (předmět hodnocení, další označení k TOE - viz dále) hodnocení znehodnocuje až anuluje * Uživatel, který není expertem v hodnocení musí porozumět správně zárukám, které jsou ve výsledcích vysloveny Hodnocení provádí //hodnotitel// a po provedeném hodnocení vydává //certifikační autorita// na základě //hodnotící zprávy// //certifikát//. Certifikační autority bývají vládní agentury (NIST) nebo licencované komerční organizace (tak se to dělá v EU). //Metodika hodnocení// je dvojího druhu * Investigativní - produktově/systémově orientované hodnocení, kde se zkoumají vlastnosti daného produktu. Toto měření je těžko opakovatelné, je to individuální pro každý produkt * Auditní postup - procesně orientované, kde se zkoumá dokumentace a procesy vývoje. Je to sice upřednostňovaná forma, ale pro koncového uživatele méně užitečná. Hlavním dokumentem CC je takzvaný //Protection Profile// (PP). Je typicky vytváření uživatelem či nějakou uživatelskou komunitou a identifikuje požadavky na bezpečnost pro jisté prostředí. Výrobce následně může zvolit, že bude vyráběž zařízení, které vyhovuje konkrétnímu PP. Další zákazníci mají pak na výběr výrobky pro různé PP. Další dokument CC je //Security Target// (ST) a specifikuje bezpečnostní funkce poskytované produktem. Jak CC používají: * **Zadavatelé vývoje** Jako specifikace bezpečnostních požadavků na TOE (//Target of Evaluation// - produkt) PP. Tedy generické požadavky na bezpečnostní rysy produktu. * **Vývojáři** Pomocí dokumentu ST definují bezpečnostní vlastnosti produktu * **Hodnotitelé** Používají PP a ST jako měřítko míry, jestli TOE vyhovuje dané bezpečnosti * **Zákazníci** Vyhledávají PP, který jim vyhovuje a použijí ho pro specifikaci objednávky či výběrového řízení * **Uživatelské sdružení, resorty** Definují PP 7 EAL(úroveň záruk) === OWASP === //The Open Web Application Security Project// má být nástrojem pro měření úrovně bezpečnosti webových aplikací. Bezpečnostní kritéria podle OWASP se dělí na //základní kritéria// a //rozšiřující kritéria// (která zaručují vyšší stupeň úroveň ochrany). Dále se každé kritérium ohodnocuje podle úroveň záruk za bezpečnost a to do těchto kategorií: * Vysoká záruka - dané bezpečnostní opatření byly prokázané //manuální kontrolou zdrojového kódu aplikace// * Střední záruka - dané bezpečnostní opatření byly prokázané //manuální kontrolou funkcionality dané aplikace// * Nízká záruka - dané bezpečnostní opatření byly prokázané //automatizovaným testováním kódu nebo aplikace// * Velmi nízká záruka - dané bezpečnostní opatření byly prokázané //analýzou návrhu aplikace// * Žádná - aplikace nebyla nijak analyzována ===== Standardy bezpečnosti IT a kryptografie, legislativa a kryptologie. ===== Standard (neboli norma, doporučení) je úmluva o technické specifikaci, nebo o jiném podobně přesně stanoveném kritériu. Standardy se dělí na de iure (schválena uznávanou institucí) na de facto (v rámci jisté komunity, např.: RFC) a firemní (proprietární) standardy. V různých oblastech technického života existují známé standardizační de iure organizace. Zde je výčet několika z nich: Standardizace čehokoliv: ISO - International Organization for Standardization Oblast elektrotechniky: IEC International Electrotechnical Commision Komunikace: ITU International Telecommunications Union V oblasti IT: ISO/IEC JTC1 tzv. Joint Technical Committee. JTC1 zřídilo společně ISO a IEC, proto ISO/IEC :-) V oblasti bezpečnosti IT: podvýbor SC 2 výboru ISO TC 68 V oblasti IT komunikace: ITU-T (úzce spolupracuje s ISO/IEC JTC1) Dále existují speciální, evropské, standardizační organizace (opět de iure): CEN (obdoba ISO), CENELEC (obdoba IEC), ETSI (obdoba ITU). Na národní úrovni existují také de iure organizace (např. ČSNI). Nicméně v IT hrají důležitou roli především ty z USA: IEEE (elektronika, elektrotechnika), NIST, ANSI (zástupce USA v organizaci ISO, věnuje se bezpečnosti v IT a především v bankovnictví). Co se týče De Facto standardů tak nejznámější jsou organizace ISOC (internet society) a IAB (internet activities board - rada pro internetové činnosti). Dobrým příkladem De Facto standardů jsou RFC, které zpracovává IETF (internet engineering task force). IETF byla pověřena IABem. Posledním zajímavou De Facto standardizační komunitou je OWASP (Open Web Application Security Project). Jak název napovídá vydává standardy vývoje bezpečných webových aplikací. Konkrétních standardů je samozřejmě velké množství (přehled je ve slidech 03_standardy od strany 25). Nejdůležitější asi je ISMS (Information Security Management System) standard (ISO/IEC 27001:2005). Krom výše uvedených standardů jsou důležité i ty z kategorie firemních, příkladem je PKCS (public key cryptography standards), který je publikovaný firmou RSA Labs. * Classification of standards by publisher * Worldwide – ISO, ISO/IEC, CCITT/ITU * US – ANSI, NIST * EU – CEN, CENELEC, ETSI, ECMA * Groups – IETF-RFC, IEEE * Industrial – RSA – PKCS * Basic cryptography standards * Symmetric crypto – DES, AES * Asymmetric crypto – encryption, signatures, key exchange and transfer * IEEE P1363 – Factoring-based, Discrete log based, Elliptic curve * NIST FIPS 186-3 – Digital Signature Standard * Hash functions – SHA-1, RIPEMD, (MD5), SHA-512 * Applied/Functional cryptography standards * Digital certificates – X.509, * PKCS – RSA, D-H, Certificate, Message, Private-Key, Attributes, Certificate Request, Crypto Token Interface & Information, ECC * Security/Crypto protocols * Low level – basic standards (entity auth.) * ISO/IEC – Key Management 11770, Non-rep. 13888 * IETF (Internet Engineering Task Force) – PKIX, IPSEC, S/MIME * PKCS - norma vyvinutá formou RSA Security pro snadné používání kryptografie s veřejnými klíči (často definovány i v RFC) * PKCS#1 - RSA šifra * PKCS#3 - Diffie Hellman * PKCS#5 - symetrické šifry * PKCS#7 - syntaxe kryptografických zpráv - CMS, S/MIME apod. * PKCS#8 - formát soukromých klíčů * PKCS#10 - formát žádosti o certifikát * PKCS#11 - obecné API pro práci s crypto-tokeny * PKCS#12 - ukládání soukromých klíčů i s certifikátem, chráněno heslem * PKCS#13 - kryptografie nad eliptickými křivkami * ISO 27k – BS7799 * Code of Practice for Information Security Management – 1995 * Specification for Information Security Management Systems – 1998 * Update of both in 1999 * ISO/IEC standard 17799 * ISO/IEC 27000 series * – ISO/IEC 27001 replaces ISO/IEC 17799 * ISO/IEC 9798-1:2010 Information technology -- Security techniques -- Entity authentication * Part 3: * Unilateral auth. * One-pass – signed sequence number or timestamp * Two-pass – challenge-response (random number) * Mutual auth. * Two-pass – signed sequence numbers or timestamps * Three-pass – challenge-response (random number) * Two-pass parallel – two unilateral two-pass protocols * ISO/IEC 11770-1:2010 Information technology -- Security techniques -- Key management * Part 1: Key management framework * Part 2: Mechanisms using symmetric techniques * Part 3: Mechanisms using asymmetric techniques * Secret key agreement (7 mechanisms) * Secret key transport (6 mechanisms) * Public key transport * Without a TTP (2 mechanisms) * Using a CA (1 mechanism  ) * https://is.muni.cz/auth/el/1433/podzim2012/PV181/um/std/Cryptographic_standards.pdf * MDx hashe v RFC * SHA hashe v NIST FIPS 180 ====== Materiály ====== http://www.vutbr.cz/www_base/zav_prace_soubor_verejne.php?file_id=37209 https://is.muni.cz/auth/el/1433/podzim2012/PV079/um/PV079_2012_L07.pdf druha polovica slajdov ~~DISCUSSION~~ 6. otázka oboru INS