60 - Kritéria hodnocení bezpečnosti informačních systémů, historie, kritéria CC (Common Criteria), standardy pro management bezpečnosti Flashcards

1
Q

Kritéria hodnocení bezpečnosti IS

A

Kritéria hodnocení bezpečnosti IS:

NEzabývají se:
	• administrativními opatřeními
	• fyzickými aspekty bezpečnosti IT
	• metodologií hodnocení
	• dohodami o vzájemném uznávání
	• kryptografickými algoritmy
	• akreditací

Funkčnost (functionality) - co je implementováno
Zaručitelnost (assurance) - míra důvěry, že je to implemenotváno správně

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Orange Book (TCSEC - Trusted Computer System Evaluation Criteria)

A
  • USA
  • první kniha z Rainbow series (série knih o bezpečnosti od Department of Defense USA)
    TCSEC = Trusted Computer System Evaluation Criteria

Úrovně (pro funkčnost i zaručitelnost)
• D - minimální ochrana

• C - Nepovinné řízení přístupu
	○ C1 - nepovinná ochrana - identifikace, autentizace, nepovinné řízení přístupu 
	○ C2 - ochrana řízeného přístupu - opětné použití a audit 

• B - Povinné řízení přístupu
	○ B1 - víceúrovňová ochrana - povinné řízení přístupu pro některé objekty a subjekty  (neformální model bezpečnostní politiky)
	○ B2 - strukturovaná ochrana - povinné řízení přístupu pro všechny objekty a subjekty 
		§ formální model bezpečnostní politiky 
		§ bezpečná cesta přihlášení 
		§ princip minimálních privilegií 
		§ analýza paměťových skrytých kanálů 
		§ správa konfigurace 

	○ B3 - bezpečnostní domény 
		§ analýza všech skrytých kanálů 
		§ mechanismus validace referencí (ref. monitor) 
		§ omezení na vytváření kódu 
		§ požadavky na dokumentaci a testování 

• A - verifikovaný návrh - A1 - verifikovaný návrh - formální analýza a verifikace (důvěryhodná distribuce)

Úrovně TCSEC v praxi
• C1, C2 - mírně vylepšené současné operační systémy, aplikace nepoznají
• B1 - operační systémy se musejí pozměnit více (MAC), některé aplikace vyžadují změny (málo)
• B2 - OS jsou změněny zásadně, aplikace nefungují
• B3 - systémy, které nezvládly A1 (stejná funkčnost, ale formální návrh)
• A1 - systémy navržené od základu, netradiční metody

Oblasti TCSEC 
	• Bezpečnostní politika 
	• Účtovatelnost 
	• Zaručitelnost 
	• Dokumentace, 
	• Analýza skrytých kanálů 
	• Architektura systému 
	• Specifikace a verifikace návrhu 
Nedostatky TCSEC 
	• Chybí integrita dat 
	• Nezná počítačovou síť 
	• !!! Nerozlišuje funkčnost a zaručitelnost (funkčnost - co je implementováno, zaručitelnost - míra důvěry, že je to implementováno správně) 
	• Různé úrovně abstrakce v dokumentu 

Index rizika = používá k vyjádření stupně bezpečnosti systému. Podle něj se určuje požadovaná úroveň dle TCSEC (stupnice pro otevřené a uzavřené prostředí).
-> I = Rmax - Rmin
(citlivost dat - neklasifikovaná až přísně tajná) - (proveření uživatele - neprověřený + max))

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

ITSEC / ITSEM (Information Technology Security Evaluation Criteria/Manual)

A
  • EU - evropská kritéria, která vznikla spojením národních kritérií jako alternativa k TCSEC
    • Rozlišuje produkty a systémy
    • !!! Rozlišuje funkčnost a zaručitelnost
ITSEC = IT Security Evaluation Criteria (1991) 
ITSEM = IT Security Evaluation Manual (1993)

Úrovně funkčnosti ITSEC -> F-C1 až F-B3 (odpovídají TCSEC)

Úrovně zaručitelnosti (ochrana proti špatnému návrhu, implementačním chybám, neefektivním opatřením či mechanismům)
• E1 – jsou definovány bezpečnostní cíle, má neformální popis architektury
• E2 – neformální popis návrhu, kontrola nad konfigurací, distribuční kontrola
• E3 – korespondence mezi kódem a bezpečnostním cílem
• E4 – formální model bezpečnostní politiky, strukturovaný přístup k designu, analýza zranitelností vyplývajících z návrhu
• E5 – korespondence mezi návrhem a kódem, analýza zranitelnosti zdrojového kódu
• E6 – formální metody architektury a mapování návrhu na bezpečnostní politiku

Třídy funkčnosti (můžou se mapovat přímo na TCSEC)
	• F-IN - integrita 
	• F-AV - dostupnost 
	• F-DI - integrita přenosu dat 
	• F-DC - důvěrnost přenosu dat 

Síla mechanismů ITSEC (pouze vágní v praxi nepoužitelná definice)
• základní - proti náhodným poruchám
• střední - proti útočníkovi s omezenými prostředky
• vysoká - prosti útočníkům s vysokými prostředky

Síla mechanismů ITSEM - přesnější specifikace

Bere v úvahu:
• Znalosti - jak moc útočník zná produkt (začátečník, zkušený, expert)
• Prostředky (Čas - čas a provedení (minuty, dny, měsíce), Vybavení - (bez vybavení, běžné vybavení, speciální vybavení))
• Příležitost - neovlivněno útočníkem (komplot, šance, možnost detekce)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Common Criteria

A

= standardizovaná (ISO/EIC) kritéria hodnocení bezpečnosti systémů.
- Existuje dohoda vzájemného uznávání a státy mají národní schémata pro použití CC

CC se dělí na:
• třídy (FXX - např. FDP) - seskupení rodin, které jsou stejně zaměřeny
• rodiny (FXX_AXX - např. FDP_ACC) - seskupení komponent, které mají stejný bezpečnostní cíl, ale různou sílu nebo přísnost
• komponenty (např. FDP_ACC.1) - nejmenší volitelná sada prvků, která může být použita v Profilu ochrany nebo Bezpečnostním cíli

  • Třídy FUNKČNOSTI “Fxx”: Audit, Communication, Cryprographic Support, Data Protection, Identification and Authentization, security Management, Privacy, functionality Protection, Resource Usage, Trusted Paths
  • Úrovně ZARUČITELNOSTI jsou kompatibilní s TCSEC – EAL1 až EAL7.
  • Třídy ZARUČITELNOSTI “Axx”: Configuration Management, Delivery and Operation, Guidance Documents, Life Cycle support, Vulnerability Assesment, Development documentation, Testing

CEM (Common Evaluation Methodology) - popisuje aktivity hodnotitele CC (doplněk k CC, slouží pro vzájemné uznávání
• Obsah
○ část 1 – úvod a obecný model- terminologie a principy hodnoceni
○ část 2 – metodologie hodnocení
○ část 3 – rozšíření metodologie
————————————————–
Struktura CC
1) Úvod a použitý model - popis přístupu, pojmy a model, požadavky na profil ochrany pro kategorie produktů a bezpečnostní cíle pro konkrétní typy produktů
- Profil ochrany - popisuje prostředí, cíle, požadavky pro kategorii produktů nebo konkrétní typ produktu

2) Funkční požadavky
Dělí se na
• třídy (Fxx) - seskupení rodin stejného zaměření
• rodiny (Fxx_Axx) - seskupení komponent se stejným cílem
• komponenty (Fxx_Axx.xx) - nejmenší volitelné sada prvků

	Třídy funkčnosti F\_\_ 
	• AUdit 
	• CCmmunication 
	• Cryptographic Support 
	• Data Protoction 
	• Identification and Authentization 
	• Security Management 
	• Privacy 
	• Functionality Protection 
	• Resource Usage 
	• Trusted Paths 
3) Požadavky zaručitelnosti
Zaručitelnost je ochranou proti
	• Špatnému návrhu 
	• Implementačním chybám 
	• Neefektivním opatřením nebo mechanismům 

Úrovně zaručitelnosti -> jsou kompatibilní s TCSEC – EAL1 až EAL7 (EAL4 - nejvyšší pro běžně vyráběné produkty )
○ - EAL 1 – funkčne testovaný
○ - EAL2 – štrukturálne testovaný (C1)
○ - EAL3 – metodicky testovaný a kontrolovaný (C2)
○ - EAL4 – metodicky navrhovaný, testovaný a preskúmavaný (B1)
○ - EAL5 – semiformálne navrhovaný a testovaný (B2)
○ - EAL6 – testovaný so semiformálne overovaným návrhom (B3)
○ - EAL7 – testovaný s formálne overovaným návrhom (A1)

Třídy požadavků zaručitelnosti:
	• Configuration Management 
	• Delivery and Operation 
	• Guidance Documents 
	• Life Cycle support 
	• Vulneralibity Assesment 
	• Development documentation 
	• Testing 

4) Registr profilů ochrany
Modely při vývoji
• model bezpečností politky
• Funkční specifikace
• model architektury
• detailní model
• implementace
• Modely specifikace lze rozdělit následovně:
○ neformální – zapsaná v přirozeném jazyce, přičemž nepodléhá žádným omezením;
○ poloformální (semiformální) – vyžaduje užití některé omezující notace spolu s množinou konvencí, může mít buď grafickou podobu, nebo být založena na omezeném použítí přirozeného jazyka.
○ formální – zapsaná ve formální notaci, která využívá dobře definovaných matematických pojmů.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Management bezpečnosti - standardy

A

Bezpečnostní politika

Celková bezpečnostní politika (CBP) - popisuje globální cíle organizace a IS z hlediska bezpečnosti.
• Cílem je ochrana majetku, pověsti a činnosti celé organizace.
• Dokument je nadčasový, nezávislý na konkrétní IT implementaci, vedený jako vnitřní norma, veřejný a závazný.
• Stanovuje citlivé informace, aktiva, klasifikaci, hierarchii, zodpovědnosti, práva a minimální sílu bezpečnostních mechanismů.
• Stručný a srozumitelný, úplný dokument – otázky a konflikty lze vyřešit odkazem na paragrafy CBP

Systémová bezpečnostní politika - definuje implementaci celkové bezpečnostní politiky v konkrétní IT situaci
• Stanovují soubor principů a pravidel pro ochranu IS
• Volba technických, procedurálních, logických a administrativních opatření.
• Principy a pravidla ochrany IS.
• Pro rozsáhlejší systémy lze vybudovat SBP pro jednotlivé části.

Tvorba bezpečnostní politiky 
	• BP nikdy nevzniká jednorázovou akcí 
	• životní cyklus tvorby BP lze zjednodušeně vyjádřit následujícími (opakovaně) prováděnými kroky 
		1. posouzení vstupních vlivů 
		2. analýza rizik 
		3. vypracování BP 
		4. implementace BP 
		5. nasazení BP, kontrola její účinnosti a vyslovování závěrů 

Standardy
- TR 13335 (norma pro řízení bezpečnosti, definuje proces sestavení CBS a SBP)

  • BS 7799 - Určen jako referenční dokument pro osoby zodpovědné za implementaci a udržování informační bezpečnosti v organizaci.
    • BP, organizace bezpečnosti (role, zodpovědnosti,..), klasifikace a správa aktiv, personální a fyzické bezpečnosti, komunikace, přístup, údržba,..)
  • ISO 27001 - je nová mezinárodní norma pro Systém správy informační bezpečnosti, postupně nahrazuje BS - to samé ale asi rozšířenější, propracovanější
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Modely bezpečnosti

A

Modely bezpečnosti - formálně vyjadřují části bezpečnostní politiky

podle řízení přístupu:
• DAC (nepovinné řízení přístupu) (neužitečné)
• MAC (povinné řízení přístupu)

podle cílů, které zajišťují:
• modely důvěrnosti (použitelné)
• integrity
• dostupnosti

podle klasifikace informace:
• jedno
• víceúrovňové

entity: 
	• uživatel 
	• proces 
	• objekt 
	• subjekt 

Monitor = prostředek pro lokalizaci bezpečnostních funkcí do jednoho místa (def. v orange book)
Požadavky:
• nelze jej obejít
• je odolný proti útoku (schopen zajistit vlastní integritu)
• malý, aby mohl být podroben analýze správnosti

Víceúrovňové modely
• Stupeň utajení - neklasifikovaná < důvěrná < tajná < přísně tajná)
• Kategorie - osobní, obchodní, …
• Bezpečnostní atributy -
Relace <= (O - objekt, S - subjekt)
O <= S pokud st. utajení O <= st. utajení S a současně kategorie O je podmnožinou kategorie S
Svazový model - svazový model pro více úrovní (transitiviva, antisymetrie, nejvyšší prvek, nejnižší prvek, některé prvky jsou neporovnatelné)

Bell-LaPadulův model DŮVĚRYHODNOSTI
• stupeň důvěry v subjekt C(S)
• úroveň důvěrnosti objektu C(O)
jednoduchá ochrana (simple property) - subjekt S může číst objekt O, pouze pokud C(S) >= C(O)
omezující vlastnost (star property) - pokud S může číst O, pak může zapisovat do objektu P, pouze pokud C(P) >= C(O) (aby NEVYZRADIL)

Bibův model INTEGRITY
• stupeň důvěry v subjekt I(S) (míra důvěry, že člověk nezmodifikuje informace nevhodným způsobem)
• úroveň integrity objektu I(O) (míra naší závislosti na integritě objektu)
○ nejsou mechanismy, jak tyto informace zjistit
jednoduchá ochrana - subjekt S může modifikovat objekt O, pouze pokud I(S) >= I(O)
omezující vlastnost - pokud S může číst O, pak může zapisovat do objektu P, pouze pokud I(O) >= I(P) (aby NEPOKAZIL)

Modely dostupnosti
Systém kvót - každý uživatel má omezeno množství prostředků, které mu lze přidělit (diskový prostor, čas procesoru, …)
Amorosův model
• každý uživatel má prioritu p
• každý prostředek má kritičnost c
• funkce prevent(p,c) určuje, zda má prostředek uživateli poskytnout

Yu-Gligorův model
• spravedlivost – uživatel nebude blokovat navždy, pokud je možnost, aby pokračoval
• simultánnost – uživatel někdy dostane všechny možnosti, jak pokračovat
• dohoda uživatelů – současné požadavky uživatelů na službu jsou uspořádány podle analýzy všech ostatních požadavků

How well did you know this?
1
Not at all
2
3
4
5
Perfectly