Bezpečnostní audit IT

MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Bezpečnostní audit IT DIPLOMOVÁ PRÁCE Brno, 2007 Štěpán Balcar 1

Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.. Na tomto místě bych rád vyjádřil poděkování RNDr. JUDr. Vladimíru Šmídovi, CSc., vedoucímu mé diplomové práce, za podnětné připomínky a navedení správným směrem. Také bych rád poděkoval všem, kteří mi byli při psaní oporou. 2

Shrnutí Tato práce podává souhrnný přehled o teorii a praxi bezpečnostního auditingu v oblasti IT. Předkládá informace o postupech a pravidlech z mezinárodně uznávaných norem a předních firem, zabývajících se problematikou řízení bezpečnosti informací. Detailněji popisuje nejběžnější způsob efektivního budování bezpečného IS - metodou PDCA. Část práce pak popisuje průběh bezpečnostního auditu IT v praxi. Autor se podílel na provedení analýzy bezpečnosti systému jedné konkrétní firmy. Tato práce podává zprávu o použitých postupech, dosažených výsledcích a navržených opatřeních v rámci tohoto projektu bezpečnostního auditu. Klíčová slova bezpečnostní audit, norma, řízení bezpečnosti, analýza, směrnice, aktiva, bezpečnostní politika, důvěrnost, integrita, dostupnost, autenticita, management, ISO, ISMS, PDCA 3

OBSAH 1. ÚVOD...1 1.1. MOTIVACE...1 1.2. BEZPEČNOST IT OBECNĚ...1 2. NORMY...4 2.1. NORMY PRO NÁVRH...4 2.2. NORMY PRO KONTROLU...6 3. BUDOVÁNÍ BEZPEČNÉHO IS...11 3.1. SYSTÉM MANAGEMENTU INFORMAČNÍ BEZPEČNOSTI - DPCA...11 3.1.1. PLAN, do, check, act...11 3.1.2. plan, DO, check, act...14 3.1.3. plan, do, CHECK, act...18 3.1.4. plan, do, check, ACT...21 3.2. BEZPEČNOSTNÍ POLITIKA, ANALÝZA RIZIK...23 4. NASAZENÍ V DOPRAVNÍM PODNIKU...29 4.1. PLÁN...29 4.2. ZADÁNÍ PROJEKTU...29 4.3. ZÁKLADNÍ PŘEHLED STAVU ICT...30 4.4. POSOUZENÍ BEZPEČNOSTI...34 4.5. OVĚŘENÍ VNITŘNÍCH PŘEDPISŮ...38 4.6. DALŠÍ TECHNICKÁ POSOUZENÍ...40 4.7. ANALÝZA RIZIK A SWOT ANALÝZA...44 5. ZÁVĚR...53 5.1. MANAŽERSKÉ SHRNUTÍ...53 5.2. REFLEXE...53 LITERATURA PŘÍLOHA A PŘÍLOHA B 4

1. ÚVOD 1.1 Motivace Pro soudobou informační společnost je typické plošné využívání informačních a komunikačních technologií (ICT). Řízení informatiky a její napojení na procesy ve firmě se stává jedním z klíčových prvků celkového managementu většiny organizací. Znalost skutečného stavu informatiky a jejího fungování v kontextu firemních procesů je základním předpokladem efektivního a úspěšného rozvoje každé společnosti. Stejně jako je třeba správně obsluhovat stroje, dodržovat výrobní postupy nebo respektovat firemní prodejní strategii, je nezbytně nutné, zapojovat ICT do chodu organizace správně a bezpečně. Právě proto, že informatika zastřešuje dnes téměř všechna oddělení firem a spojuje informace z různých zdrojů, je třeba zvlášť dbát na správnou implementaci a bezpečné fungování informačních a komunikačních technologií ve firmě. Efektivním nástrojem pro poznání stavu informační bezpečnosti a jejího řízení je bezpečnostní audit ICT. Tato práce se zabývá bezpečnostním auditem, mapuje normy a způsoby nasazení a ukazuje na konkrétním příkladě, jak může takový audit vypadat, jak probíhá a co přináší. Teoretická část práce čerpá z různých zdrojů a podává souhrnný přehled o hlavním proudu toho, co se obecně považuje za bezpečnostní auditing IT. Audit ve smyslu hodnotící analýzy je velice široký pojem, a proto se i v oblasti IT pod tímto názvem skrývá hned několik různých témat a služeb. Tato práce předkládá informace z mezinárodně uznávaných norem a z nabídky předních českých firem, zabývajících se bezpečností IT a analýzou IS. Praktická část pak vychází přímo z projektu společnosti RYANT, s.r.o, ve které je autor této práce zaměstnán a přímo se podílel na analýze bezpečnosti ve společnosti Dopravní podnik města X, a.s. Zákazník si nepřál, aby jméno společnosti bylo použito v této práci či jinak zveřejněno. Proto jsou některé údaje anonymizovány a upraveny (IP adresy, jména serverů, ) a o firmě samotné budeme psát jako o Dopravním podniku. Nicméně důležitá data a postupy bezpečnostního auditu jsou zcela autentické. V případě pochyb lze vše ověřit u jednatele společnosti RYANT, s.r.o. Ing. Karla Doležala, který také působil jako supervizor celého projektu. 1.2 Bezpečnost IT obecně Na IT bezpečnost se dá nahlížet z různých úhlů a obecně tento pojem zahrnuje celou řadu problémů a jejich řešení. Zabezpečení sítě, fyzických spojů a serverů, kódování datových přenosů, digitální podpis, dodržování firemních směrnic, autentizace, autorizace, autenticita, nepopiratelnost, antivirová a antispamová ochrana, ocenění a ochrana firemních aktiv, analýza rizik, zálohování, obnova po chybě, a tak dále. 5

Dá se říci, že bezpečnostní řešení je vždy na míru. Dodržování jistých obecných zásad je však žádoucí. V této práci bude dále popsáno několik mechanismů pro budování bezpečného IS a několik oficiálních norem, kterými je možné se řídit při celkové analýze bezpečnosti ICT. Již na tomto místě můžeme uvést jisté vodítko. Je jím úhel pohledu firmy, zákazníka a důvody, proč se bezpečností ICT a jejím řízením zabývat. - Stejně jako například certifikáty jakosti řady ISO 9000 zvýší důvěryhodnost firmy, znamená jasně definovaná bezpečnostní politika konkurenční výhodu. Transparentní způsob práce s daty a definované procesy ujistí klienty například v tom, že bude dobře postaráno o jejich obchodní tajemství. - Při důkladné bezpečnostní analýze jsou aktiva firmy ohodnocena a následně chráněna odpovídajícím způsobem s přihlédnutím k jejich významu pro společnost. Tento systém řízení bezpečnosti přinese optimální poměr výše nákladů a úrovní zabezpečení. - Správná vnitřní bezpečnostní politika (řízení přístupu, rozdělení odpovědnosti, nepopiratelnost, ) spolu s ochranou proti vnějším útokům zvýší stabilitu organizace a minimalizuje nebezpečí úniku dat. - Důsledné dodržování pravidel při práci s internetem a elektronickou poštou spolu s citlivě nastaveným systémem ochrany datové výměny (firewall, spamfilter, ) chrání před počítačovými viry, trojskými koňmi, červy a jinými útoky a minimalizují tak riziko ochromení organizace omezením funkčnosti IS. - Hierarchicky strukturovaný IS spolu s firemní bezpečnostní politikou jasně definující role omezuje absolutní moc pracovníků IT oddělení a dává sílu zpět do rukou vedení společnosti. - Systém řízení bezpečnosti by nebyl kompletní bez mechanismů umožňujících detekci chybových stavů, popis reakce na tyto neočekávané situace a řešení problémů a dokumentaci těchto událostí, aby jim bylo v budoucnu možno předejít. Při rozboru těchto šesti bodů do úrovně technického detailu zcela jistě narazíme na některé klíčové pojmy a zásadní úlohy k řešení. Souhrnně a v kontextu procesů budou tyto pojmy a úlohy popsány v kapitole Budování bezpečného IS, ale jejich základní popis a charakteristiku nastíníme již zde. Tak předně je počítač pro lidského uživatele jakousi černou skříňkou, která pouze manipuluje se sekvencemi jedniček a nul. Tyto jedničky a nuly jsou vzájemně zaměnitelné, nekonečně kopírovatelné a změna jednoho bitu není jednoduše zjistitelná. My ale chceme počítačům důvěřovat a práci, kterou provádíme pomocí ICT, považovat za bezpečnou. Ale jak poznat, případně zajistit, bezpečné IT prostředí? Více napoví následující odstavec a především kapitola Budování bezpečného IS. Pojďme si nyní ujasnit, jaké jsou základní stavební kameny související s pojmem Bezpečnost ICT, jak je popisuje například docent Staudek ve svých přednáškách na Fakultě informatiky. Zajišťujeme-li bezpečnost, musíme v prvé řadě vědět, co by mohlo být v nebezpečí, co je třeba chránit. Cokoliv, co má pro firmu nějakou hodnotu, ať je to drahý výrobní stroj či program nebo 6

postup, jak vyrobit tu nejlepší čokoládu, nazýváme aktivem. Ztráta či snížení aktiva pak způsobí firmě škodu. Tato škoda vznikne buď nedbalostí nebo jako důsledek útoku. Samotný útok je realizací hrozby a jeho dopadem je škoda. Hrozba existuje díky zranitelnosti systému obhospodařujícím aktiva a díky existenci zranitelných míst a útočníků. Pravděpodobnost uplatnění hrozby představuje riziko. Přijímáme proto soubor bezpečnostních opatření, která pomocí jasně definovaných bezpečnostních mechanizmů minimalizují rizika resp. škody. Souhrnem a popisem nasazení bezpečnostních opatření je pak definována bezpečnostní politika. K základním šesti bodům, uvedeným v úvodu této kapitoly, přibývají další oblasti, které je třeba obsáhnout a zajistit tak bezpečné IT prostředí. Jsou to - Důvěrnost. Některá aktiva musí být udržována v tajnosti. K důvěrným aktivům smí mít přístup pouze autorizované subjekty. Neautorizovaným subjektům nesmí být důvěrná aktiva odhalena. - Integrita. Manipulace či modifikace a rušení aktiv je umožněno pouze autorizovaným subjektům, autorizovaným způsobem. Jinak je zaručena celistvost aktiv. - Dostupnost. Aktiva musí být autorizovaným subjektů přístupná. Definovaným způsobem, po určenou dobu. Musí být přijata opatření zabraňující odmítnutí služby. - Autenticita. Musí být zajištěna ověřitelnost deklarovaného původu aktiva. Rozšířením autenticity o nemožnost popření původu aktiva dosáhneme Nepopiratelnosti (odeslání či přijetí zprávy, původu dokumentu, ). V manažerském pohledu se poslední bod někdy zaměňuje za odpovědnost. Výše uvedené (a v dalších kapitolách rozšířené) informace o bezpečnosti ICT lze shrnout do jednoduchého desatera, které sice značně zobecňuje, ale podává jednoduchý a srozumitelný návod, jak bezpečnost ICT pojmout. Podobných souhrnů lze v literatuře najít více, tento je inspirován přednáškami docenta Staudka. 1. Stanovení požadavků na zabezpečení provozního prostředí 2. Kvalifikované vymezení síly ochrany provozního prostředí 3. Zajištění dostatečných finančních zdrojů 4. Vypracování účinných bezpečnostních politik a opatření 5. Vyvinutí, provozování a testování zálohování a obnov 6. Účinné isolování intranetu kvalitními firewally 7. Instalování antivirového software 8. Pravidelné udržování ochranného software, vč. firewallu 9. Systematické proškolování zaměstnanců v tématech bezpečnosti ICT 10. Implementace silných, kvalitních a špatně uhodnutelných hesel. Pokud Vám toto desatero bylo málo, čtěte dál. 7

2. NORMY Pokud přistupujeme k návrhu bezpečného IS či jeho kontrole zodpovědně, nestačí nám pochopitelně pouze výše uvedené desatero. Je třeba založit analýzu či tvorbu bezpečného IS na jasně definovaných metodách a fungujících principech. Jako v mnoha jiných oborech, i v oblasti managementu bezpečnosti IS se angažují národní i nadnárodní standardizační organizace a řada firem si vytváří vlastní metodiky řešící tuto problematiku, více či méně reflektující na mezinárodní standardy. 2.1 Normy pro návrh V rámci spolupráce Mezinárodní standardizační organizace ISO a IEC (International Electrotechnical Commission) vznikla celá řada norem. V problematice bezpečnosti IT jsou některé dílem Společného technického výboru č.1 (Joint Technical Committee, JTC1), v jednotlivých podvýborech (Subcommittee, SC) a pracovních skupinách (Working Group, WG), některé vznikly jako technické zprávy (Technical Report, TR) těchto dvou spojených organizací. Takto vytvořené standardy mají celosvětový rozsah a často slučují to dobré z jiných standardů a pravidel. Konkrétně normy ISO/IEC v oblasti bezpečnosti IT mnohdy vychází z britských norem (British Standards, BS). Jaké konkrétní normy tedy popisují problematiku managementu bezpečnosti IT? ISO/IEC 17799, původně britský standard BS 7799 Code of praktice for information security management - uvádí soubor postupů správy informační bezpečnosti v organizaci (většina škod na informačních aktivech vzniká selháním lidského faktoru, ne technickou závadou či nedostatkem informačního systému) - doporučuje jak navrhnout, implementovat, udržovat a vylepšovat správu informační bezpečnosti v organizaci - definuje cca 130 nástrojů seskupených do cca 10 kategorií, obsahuje doporučení, jak vytvořit vlastní nástroje pro specifická prostředí - neřeší technické aspekty informační bezpečnosti - standard je spíše kodexem, radami pro budování bezpečného systému, slouží jako základní materiál pro posouzení vlastností a potřeb informační bezpečnosti - obvyklé je deklarovat soulad se standardem, certifikace se neprovádí 8

ISO/IEC 27001, původně britský standard BS 7799-2 Information security management system (ISMS) - Requirements - obsahuje požadavky na implementaci systému správy informační bezpečnosti (ISMS) - uvádí požadavky na implementaci opatření podle ISO/IEC 17799 - nezabývá se konkrétními nástroji správy informační bezpečnosti, specifikuje jak vybudovat systém, který posuzuje, implementuje, monitoruje a udržuje bezpečnostní systém organizace - standard je detailním popisem požadavků, které má ISMS organizace splnit, lze jej následně certifikovat dle ISO/IEC 27001 Následují další standardy z rodiny 27000 dále specifikující ISMS. Normy jsou založené na bázi modelu PDCA (Plan, Do, Check, Act). Návrh ISMS -> Implementace ISMS -> Monitorování a kritické hodnocení ISMS -> Vylepšení a korekce ISMS -> Návrh ISMS. Tento model bude podrobně popsán dále (a je například také bází standardů kvality ISO 9001). ISO/IEC 27002 Code of Practice - popisuje bezpečnostní cíle a nástroje pro jejich dosažení ISO/IEC 27003 - rezerva pro budoucí návod na implementaci ISO/IEC 27004 Information security management metrics and measurement - specifikuje co a jak měřit při určování a popisování účinnosti ISMS budovaného dle ISO/IEC 17799 ISO/IEC 27005 Information Security Risk Management - nahradí současnou BS 7799 part 3 ISO/IEC 13335 Management of information and communications technology security - obsahuje koncepty a modely tvořící základ pochopení IT bezpečnosti - specifikuje techniky provádění analýzy rizik - jedná se o původní ISO/IEC TR 13335-1 9

ISO/IEC TR 15945 Specification of TTP services to support the aplication of digital signatures - společný standard s doporučením X 843 ITU-T (doporučení mezinárodní telekomunikační unie) ISO/IEC TR 18043 System deployment a operations of intrusion detection systems - IDS - technická zpráva s metodickým návodem jak zahrnout IDS do IT struktury ISO/IEC TR 18044 Information security incident management - technická zpráva s metodickým pokynem pro správu reakce na bezpečnostní incident Dále ISO/IEC specifikuje řadu kryptografických a autentizačních technik a mechanismů například v normách: ISO/IEC 9796, ISO/IEC 9797, ISO/IEC 9798, ISO/IEC 10116, ISO/IEC 10118, ISO/IEC 11770, ISO/IEC 13888, ISO/IEC 14888 2.2 Normy pro kontrolu Nyní se nacházíme ve fázi, kdy jsme vytvořili bezpečný informační systém resp. v našem IS provozujeme ISMS jako proces. Jak zákazníkům či partnerům v případě potřeby prokážeme tuto vlastnost našeho systému? Případně si představme situaci, že stojíme před úkolem otestovat IS v jiné organizaci a určit, zda je bezpečný. I v takovém případě můžeme postupovat dle známých a osvědčených pravidel, která jsou specifikována v mezinárodně uznávaných normách. Jedním ze standardů, který lze použít na audit bezpečnosti IT je norma ISO/IEC 15408 Evaluation criteria for IT security resp. Common Criteria (CC) ISO/IEC 154408-1: Part 1: Introduction and general model ISO/IEC 154408-2: Part 2: Security functional requirements ISO/IEC 154408-3: Part 3: Security assurance requirements Hodnotící kritéria = seznam podmínek, které produkt nebo systém má být schopný naplnit. Hodnotící kritéria, která zde hrají hlavní roli však nesmíme zaměňovat se standardy kritérií vývoje z rodiny ISO/IEC 27000. I když lze standardy ISO/IEC 27001 a ISO/IEC 17799 použít pro hodnocení zacházení s informacemi, není to jejich cílem, jsou příliš technicky orientované, jejich smyslem je definovat, jak bezpečně manipulovat s informacemi. Ani jedna z uvedených norem 10

nepožaduje použití produktu hodnoceného dle CC. Požadují, aby systém byl externě auditovaný, a aby se pravidelně kontroloval soulad systému s implementačními kritérii (jimiž mohou být například hodnotící kritéria). Jako výstup z CC hodnocení je mimo jiné mezinárodně uznávané hodnocení CCRA Common Criteria Recognition Arrangement (ve 22 zemích) úroveň záruky bezpečnosti produktu (systému). EAL (Evaluation Assurance Level) nabývá sedmi hodnot. Od EAL01 funkční, testovaný systém (produkt), po EAL7 produkt (systém) formálně navržený, s formálně ověřeným návrhem. Někdy se můžeme setkat také s označením EAL0 nefunkční systém (produkt). Ale tyto úrovně si popíšeme níže. 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í 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. 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ě. Protože CC je v současné době nejpoužívanější metodou evaluace bezpečnosti IS, popíšeme si stručně jednotlivé úrovně míry záruky EAL: - 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. 11

- 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í. - 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. 12

Srovnatelnou metodikou je projekt amerického ministerstva obrany, který vznikl v roce 1985 kvůli hodnocení operačních systémů pro použití v armádních instalacích. Trusted Computer Security Evaluation Criteria (TCSEC) alias The Orange Book Hodnocený systém padá do jedné ze sedmi tříd spadajících do čtyřech kategorií. Pro každou třídu je dán seznam požadavků na funkcionalitu a zaručitelnost. Úroveň zabezpečení je svázána s úrovní zkoumání systém, který deklaruje vyšší úroveň zabezpečení, není zkoumán stejně jako systém deklarující dosažení nižší třídy. Tento systém donedávna používaly i struktury NATO, momentálně hodnotí bezpečnost systémů dle CC. Další nástroj pro hodnocení bezpečnosti systému byl používán v EU od roku 1995, v současné době je také nahrazován nástroji CC. Jedná se o Evropská hodnotící kritéria. Information Technology Security Evaluation Criteria (ITSEC) Tato norma byla hodně překládána do různých jazyků, což mnohdy narušilo jednotnou interpretaci. Výhodou ITSEC alias Superman Book, jak je někdy nazývána, je to, že přerušuje vazbu mezi funkcionalitou a zaručitelností obě kritéria lze zadat nezávisle. To přispívá k větší škálovatelnosti, ale v kombinaci s nepřesně definovanými předměty hodnocení (norma neukládá hodnocení konkrétních PH) to znamená spíše nejednotnost a nesrovnatelnost výsledků. Nicméně jako výstup existuje škála záruky v šesti stupních a je možné jí porovnat s TCSEC a CC. TCSEC ITSEC CC EAL1 C1 E1 EAL2 C2 E2 EAL3 B1 E3 EAL4 B2 E4 EAL5 B3 E5 EAL6 A1 E6 EAL7 13

Legislativa Právní normy, které upravují oblast bezpečnosti IS a její řízení, mimo jiné jsou: zákon č. 148/1998 Sb., o ochraně utajovaných skutečností (v roce 2002 novelizován a částečně nahrazen jinými zákony); zákon č. 227/2000 Sb., o elektronickém podpisu; zákon č. 365/2000 Sb., o informačních systémech veřejné správy; zákon č. 101/2000 Sb., o ochraně osobních údajů; zákon č. 480/2004 Sb., o některých službách informační společnosti. Detailní popis těchto norem není předmětem této práce, lze jej však nalézt například na webových stránkách Ministerstva vnitra ČR. 14

3. BUDOVÁNÍ BEZPEČNÉHO IS 3.1 Systém managementu informační bezpečnosti - DPCA Zásady budování a využívání systému řízení bezpečnosti informací (ISMS Information Security Management System) stanovené výše uvedenými, dnes platnými a v českém jazyce dostupnými normami (tj. ISO/IEC 17799:2005 a ISO/IEC 27001:2005) se dají interpretovat různými způsoby v závislosti na velikosti organizace. Jejich podstata však zůstává stejná informační bezpečnost musí být řízena. Velikost organizace a rozsáhlost jejího systému jsou jedním ze základních parametrů při určování způsobu zavádění ISMS. Plan, Do, Check, Act, tedy Plánování Implementace, Kontrola (sledování) a Vylepšení jsou 4 kroky, které postupně a cyklicky aplikujeme při zavádění a provozu ISMS dle doporučení normy ISO/IEC 27001 v organizaci jakékoliv velikosti. ISMS lze zavést a používat v organizaci s deseti pracovníky, a stejně tak i v obřím holdingu, kde se každý den můžete potkat s tisíci zaměstnanci. Zjednodušeně lze říci, že ISMS je jen jeden a to ten, který je popsán v normě ISO/IEC 27001. Interpretace a implementace jednotlivých doporučení se však může výrazně lišit podle rozsahu systému, počtu uživatelů, způsobů zpracování dat a jejich hodnoty apod. Například bezpečností politika, jako ten nejvyšší dokument o bezpečnosti informací v organizaci, může být velmi podobná pro živnostníka i pro obrovskou akciovou společnost. Naopak tomu je o organizace bezpečnosti. Pokud se ISMS zavádí ve velké společnosti, je nutné pro tisíce uživatelů zřídit samostatné bezpečností oddělení s 5-10 lidmi, ve střední firmě na to stačí 2 pracovníci a pokud máme systém pro 10 lidí, tak jeden člověk na půl úvazku je až moc. Jen pro doplnění uvádím, že ISMS a PDCA je zaváděno i do informačních systémů orgánů veřejné správy. Veřejné instituce tak postupují podle instrukcí směrnice OECD pro bezpečnost informačních systémů v rámci projektu budování Národní strategie informační bezpečnosti ČR (NSIB). Pro účely popisu mechanismu PDCA postačí, pokud rozdělíme firmy do tří skupin podle počtu zaměstnanců a podle počtu úrovní vedení. Malé firmy (do 15 zaměstnanců, 1-2 úrovně vedení), střední firmy (do 150 zaměstnanců, 3-5 úrovní vedení) a velké firmy (nad 150 zaměstnanců, 4 a více úrovní vedení). Podívejme se tedy detailně, jak vypadají jednotlivé fáze nejpoužívanějšího modelu řízení bezpečnosti IS PDCA. 3.1.1 PLAN, do, check, act Fáze PLAN by měla obsahovat následující netriviální kroky. Sestavení strategie (plánu) bezpečnosti Strategie bezpečnosti nebývá v malých a středních firmách popsána tak detailně, jako je tomu zvykem ve velkých společnostech. Zpravidla stačí, aby ředitel středně velké organizace měl vůli řešit bezpečnostní otázky a pak není nutné sepisovat rozsáhlý dokument o koncepci řízení bezpečnosti. Podstatné je především určit rozsah a cíle bezpečností strategie. 15

Návrh bezpečnostní politiky Proces vytvoření a schválení Bezpečnostní politiky je společný pro všechny typy organizací včetně publikování politiky vůči všem zaměstnancům. Také rozsah a obsah dokumentu je velmi podobný. Bezpečnostní politika definuje zásady a pravidla na úrovni cílů a ty jsou zpravidla shodné pro všechny organizace. Musí také obsahovat odkaz na dokument popisující rozsah ISMS, protože systém řízení bezpečnosti v malé ani střední firmě nemusí být zaveden pro celý informační systém (stejně jako systém řízení kvality podle ISO řady 9000). V dokumentu by měla být popsána mj. organizační struktura bezpečnosti, popis bezpečnostních rolí a jejich odpovědností musí odpovídat velikosti systému a počtu uživatelů. Navíc je nutné respektovat zavedenou organizační strukturu a proto je možné pro stejně velké společnosti použít různé modely organizace bezpečnosti. Je také třeba určit a rozdělit bezpečnostní odpovědnost. V malých firmách nemusí být přímo jmenován bezpečnostní ředitel na plný úvazek. Pokud má systém pouze několik desítek uživatelů, je možné jednotlivé kompetence rozdělit mezi několik stávajících pracovníků nejen z IT. Analýza rizik Znalost bezpečnostních rizik je základním kamenem pro vytvoření a správně řízení ISMS. Proto provedení analýzy rizik je nutná nikoli však postačující podmínka pro všechny organizace. Rozhodnutí, zda provést detailní či jen základní analýzu, je na vedení firmy, nicméně pouze detailní analýza provedená podle vybrané metodiky může poskytnou podklady pro efektivní výběr a implementaci bezpečnostních opatření. Analýze rizik bude věnována samostatná kapitola dále. Plán implementace a Prohlášení o aplikovatelnosti Krokem logicky navazujícím na analýzu a poslední činností v části plánování podle modelu PDCA je vytvoření Plánu implementace a následně Prohlášení o aplikovatelnosti (opatření). Bezpečnostní protiopatření by měla být vybrána na pokrytí zjištěných rizik a způsob jejich výběru je nezávislý na velikosti organizace. Jejich implementace bude rozdílná, ale například pro všechny organizace lze použít BIS-PD 3005 nebo knihovnu protiopatření CRAMM (vše viz dále). Velký rozdíl však je ve způsobu a zejména v rychlosti jejich prosazení. Při výběru bezpečnostních opatření je vždy nutné zohlednit jejich dopad na uživatele a na procesy organizace. V malé firmě je možné jednouše a rychle změnit téměř jakýkoli proces, aby byl více bezpečný. Stačí vůle ředitele a o změně je rozhodnuto. Čím je organizace větší, tím je složitější měnit procesy a zavedené postupy. Proto je nutné při výběru protiopatření ve střední firmě více respektovat současný stav. Prohlášení o aplikovatelosti (opatření) je jedním z dokumentů nutných k certifikaci. Obsahuje informace o implementovaných opatřeních normy, případně dalších protiopatřeních navržených na pokrytí rizik. Hlavním cílem je dokumentovat rozhodnutí, proč dané protiopatření bylo či nebylo vybráno k zavedení. Pokud firma neplánuje být v budoucnosti certifikována, není nutné vytvářet samostatný dokument 16

Následuje přehled výše uvedených kroků ve shrnující tabulce. Proces Malá organizace do 15 zaměstnanců, 1-2 úrovně vedení Střední organizace do 150 zaměstnanců, 3-5 úrovní vedení Velká organizace nad 150 zaměstnanců, 4 a více úrovní vedení Plán / projekt bezpečnosti Schválení strategie/plánu pro bezpečnost Schválení celkové koncepce bezpečnosti Schválení projektu bezpečnosti Schválení celkové koncepce bezpečnosti Vymezení rozsahu projektu + odhad zdrojů a harmonogramu Schválení projektu bezpečnosti Analýza stavu bezpečnosti Bezpečnostní politika Musí být napsána a schválena vedením Popisuje základní zásady bezpečnosti na úrovni cílů Definuje organizaci bezpečnosti, odpovědnosti a strukturu bezpečností dokumentace Obsahuje odkaz na rozsah ISMS Musí být napsána a schválena vedením Popisuje základní zásady bezpečnosti na úrovni cílů Definuje organizaci bezpečnosti, odpovědnosti a strukturu bezpečností dokumentace Obsahuje odkaz na rozsah ISMS Musí být napsána a schválena vedením Popisuje základní zásady bezpečnosti na úrovni cílů i strategií pro jejich dosažení včetně závazku podpory a alokace zdrojů Definuje organizaci bezpečnosti, odpovědnosti a strukturu bezpečností dokumentace Obsahuje odkaz na rozsah ISMS P L A N Organizace bezpečnosti Oddělení/Odbor bezpečnosti: NE Bezp. ředitel: ředitel firmy Bezp. administrátor: administrátor IS Bezp. auditor: odpovědnost delegována na pracovníka (mimo administrátora IS) Oddělení/Odbor bezpečnosti: ANO (pod IT) Bezp. ředitel: jmenován člen vedení Bezp. manažer: jmenováni 1-3 Bezp. auditor: pracovník interního auditu, nebo delegováno na pracovníka mimo IS Bezp. administrátoři: administrátoři částí systémů Oddělení/Odbor bezpečnosti: ANO (v IT i mimo) Bezp. ředitel: jmenován člen vrcholového managementu Existuje oddělení bezp. s odpovědnostmi za řízení i správu všech oblastí bezpečnosti Bezp. auditor: zajišťuje oddělení interního auditu 17

Analýza rizik Nutné provést: ANO Čas: max. 1 měsíc Členové projektového týmu: jeden interní pracovník a/nebo konzultant Respondenti: max. 5 Výstupy: Zpráva o analýze rizik + Implementační plán Nutné provést: ANO Čas: 3-5 měsíců Členové projektového týmu: 2-3 interní pracovníci a/nebo 2-3 konzultanti Resondenti: 5-20 Výstupy: Zpráva o aktivech a dopadech + Zpráva o analýze rizik + Implementační plán Nutné provést: ANO Čas: 4-12 měsíců Členové projektového týmu: 2-n interních pracovníků a/nebo 2-3 konzultanti Respondenti: desítky Výstupy: Zpráva o aktivech a dopadech + Zpráva o analýze rizik + Implementační plán Výběr opatření a plán implementace Protiopatření vyplývají z AR Prosazuje: ředitel firmy Protiopatření vyplývají z AR Prosazuje: ředitel a vedoucí oddělení společně Protiopatření vyplývají z AR Prosazuje: podle významu protiopatření od vedení společnosti po vedoucí oddělení Prohlášení o aplikovatelnosti Dokumentované rozhodnutí, samostatný dokument pouze v případ certifikace Dokumentované rozhodnutí, samostatný dokument pouze v případ certifikace Dokument Prohlášení o aplikovatelnosti 3.1.2 plan, DO, check, act Způsob implementace opatření a metody prosazení Výběr okruhů opatření ISMS je podobný pro malou i středně velkou firmu. Velký rozdíl však je ve způsobu a zejména v rychlosti jejich prosazení. V malé firmě rozhoduje zpravidla ředitel o tom, kdo bude mít přístup k jakým datům. Ve středně velké firmě je nutné vytvořit proces přidělování uživatelských oprávnění. V malých firmách je běžné, že bezpečnostní ředitel (zpravidla ředitel firmy) rozhodne ráno o změně délky hesla z 6 na 9 znaků. Bezpečnostní administrátor (zpravidla správce sítě) protiopatření zavede ještě před obědem a v rámci příjemně strávené siesty si všichni uživatelé rádi změní heslo. Následující den je protiopatření v systému již zcela zavedeno a automaticky používáno a akceptováno. Taková rychlost implementace je typická pouze pro malé firmy. Ve středně velkých organizacích je nutné vzít v úvahu akceptovatelnost protiopatření ze strany uživatelů a další souvislosti jejich realizace. Prosadit například změnu délky hesla vyžaduje revizi příslušné směrnice, zapojení několika administrátorů do práce a seznámení desítek uživatelů se změnou, například formou školení. Poté by měla následovat kontrola funkčnosti opatření. Bezpečnostní dokumentace Značné rozdíly mezi malou a středně velkou firmou jsou ve formě a míře detailu dokumentace bezpečnosti. Není příliš známo, že uvedené normy striktně nevyžadují papírovou formu 18

dokumentace ani její pevnou strukturu, ale ponechávají na preferencích jednotlivých firem, jakou formu a obsah zvolí. Přitom právě obava z přílišné formální administrativy nejčastěji odpuzuje malé a středně velké organizace od zavádění doporučení těchto norem. Dokumentace ISMS požadovaná k certifikaci podle ISO 27001 pochopitelně musí obsahovat určité, taxativně uvedené typy dokumentů, dané jednotlivými kroky procesu ISMS, ale jejich rozsah, obsah a forma může být překvapivě jednoduchá a flexibilní. Pracovníci malých firem se osobně znají a velká část bezpečnosti je založena na jejich vzájemné důvěře. Není nutné vytvářet složitý systém politik, směrnic a postupů. Postačí stručné pravidlo, že bezpečnostní dokumentace je vedena ve sdílené složce elektronické pošty, definovat role a přístupy zodpovědných osob a nezbytné typy bezpečnostních dokumentů realizovat formou elektronických záznamů, obsahující stručný popis realizace daného pravidla, postupu nebo odpovědnosti. Středně velká firma se v této oblasti opatření blíží firmě velké. Zde je již nutné zavádět podrobnější administrativní procedury, neboť existuje více oddělených rolí a odpovědností a také více definovaných pravidel. Tato administrativa je nutná, aby byly eliminovány činnosti, které se dějí při práci s daty jen tak, na dobré slovo. Rozsah a aktuálnost bezpečnostní dokumentace bývá často jedním z klíčových kritérií při posuzování kvality ISMS a míry dosažené shody s požadavky norem. Program zvyšování bezpečnostního povědomí Mezi další metody prosazení bezpečnosti v organizacích patří program zvyšování bezpečnostního povědomí v organizacích. Tato jednoduchá, levná a velice účinná metoda bývá bohužel mnohdy v malých a středně velkých organizacích opomíjena. A přitom jsou to právě zaměstnanci, kteří jsou často zdrojem bezpečnostních incidentů a kteří mohou, pokud jsou správně informováni, svým včasným jednáním šíření a škodám incidentů zabránit. Stále se můžeme setkat s užaslými tvářemi, když vysvětlujeme, že nejvyšší hodnotu pro organizaci mají v informačním systému data a nikoliv hardware a software. Existuje stále také mnoho uživatelů, kteří pokládají svou disketu nebo lokální harddisk svého PC v kanceláři za mnohem bezpečnější místo, než síťový disk s transparentně nastavenými přístupovými právy a pravidelným zálohováním. A přitom postačí, pokud zvyšování bezpečnostního povědomí opřeme o stručné vstupní školení všech zaměstnanců a občasné prodiskutování aktuálních bezpečnostních otázek dle potřeb organizace a vývoje nových potencionálních hrozeb. U středně velkých a velkých organizací zavedeme pravidelná školení či bezpečnostní semináře například ve spojení se stmelováním pracovních týmů (teambuildingy). U větších organizací by také nemělo být opomenuto informovat všechny zaměstnance dle potřeby o aktuálních hrozbách a opatřeních, např. formou zřízení centrálního informačního místa o bezpečnostních otázkách na firemním intranetu. Způsob zvládání rizik za provozu Jedním z hlavních důvodů proč zavádět ISMS, je potřeba zajistit kontinuální proces zvládání a řízení informačních rizik. Základem pro jejich úspěšné řízení je identifikace a analýza všech 19

potencionálních rizik a následné rozhodnutí o způsobu jejich zvládání a sledování v čase. Účelem řízení rizik není veškerá identifikovaná rizika bezezbytku pokrýt (mnohdy s vynaložením neadekvátních zdrojů), ale pokrýt zvolenými opatřeními pouze taková, u kterých je to efektivní. Ostatní rizika může organizace akceptovat a sledovat, některá může přenést na jinou organizaci, případně je pojistit. Pouze pokud organizace zná a sleduje všechna rizika související se zabezpečením informací a adekvátně rozhoduje o způsobu jejich zvládání, potom může prohlásit, že tyto rizika řídí (má je pod kontrolou). Tyto zásady jsou opět společné pro všechny velikosti a typy organizací. Nároky na provoz opatření a zajištění bezpečnosti Součástí plánu zvládání rizik je i sledování nároků na provoz jednotlivých opatření a celkového zajištění bezpečnosti. Zatímco u malých firem není potřeba plánovat ani vyhrazovat samostatný rozpočet, neboť případný nákup a provoz nezbytných opatření je operativně schválen ředitelem a hrazen dle aktuálních potřeb organizace, u středních a velkých firem je nezbytné provádět alespoň rámcové plánování potřebných finančních i lidských zdrojů. Z hlediska preferencí při výběru opatření hrají celkové nároky na jejich zavedení a provoz hlavní roli. Zatímco pro malé organizace není překážkou pružně zavádět administrativní a personální opatření i za cenu vyšších požadavků lidské zdrojů, úskalím však bývají finanční náklady na pořízení složitých technologických opatření. U velkých společností lze tyto preference vysledovat obráceně, neboť pro ně bývá snazší pružně zavést nové technologické opatření, než jej nahradit administrativními či organizačními změnami. V případě preferencí středně velkých firem je stav logicky někde uprostřed. Záleží na pružnosti řízení, technologické úrovni a znalostech pracovníků firmy, k jakým typům opatření se budou přiklánět více. Zavedení opatření DRP a IRH Poslední důležitou oblastí opatření při zavádění a provozu ISMS je tvorba a údržba Havarijních plánů (DRP Disaster Recovery Planning) a Postupů řešení bezpečnostních incidentů (IRH Incident Response Handling). Stejně jako v případě ostatních formálních postupů i zde platí, že pro malé organizace je neefektivní vypracovávat a udržovat podrobné formální havarijní plány. Pro obnovu systémů jim plně postačí vytvoření stručného univerzálního havarijního checklistu pro všechny možné případy havárie, který bude obsahovat postup bezpečného vypnutí a restartu technického vybavení a serverů, jednoduchý záznam výsledné konfigurace technologií a aplikací, postup obnovení dat ze záložních médií a seznam kontaktů na interní a externí osoby, které mohou pomoci při výskytu havárie nebo závažného bezpečnostního incidentu. Tyto havarijní postupy by měly být alespoň jednorázově otestovány a poté postačí testy opakovat až při zásadní změně používaných technologií a služeb. U středně velkých organizací je doporučeno rozšířit zmíněný havarijní checklist i o popis kroků instalace jednotlivých částí informačního systému a obnovy dat a aplikací ze záložních médií. U komplikovanějších informačních systémů je třeba rozlišit obnovu klíčových aktiv od ostatních a tomu přizpůsobit priority v havarijním plánování. Pro výběr strategie způsobu obnovy a nastavení priorit je nejlépe realizovat analýzu dopadů na činnosti organizace (BIA Business 20

Impact Analysis). Pokud byla správně realizována analýza rizik, lze informace o negativních dopadech nedostupnosti jednotlivých aktiv nalézt tam. Na základě těchto výsledků je vypracován strukturovaný havarijní plán obnovy, obsahující varianty postupu dle specifikovaných typů havarijních stavů. Takovýto plán je nezbytné pravidelně testovat a aktualizovat a na základě výsledků testů (v porovnání s cíly obnovy) vylepšovat. Proces Malá organizace do 15 zaměstnanců 1-2 úrovně vedení Střední organizace do 150 zaměstnanců 3-5 úrovní vedení Velká organizace nad 150 zaměstnanců 4 a více úrovní vedení D O Způsob implementace opatření Okamžitě, rychle, efektivně, bez zbytečné administrativy Podle významu protiopatření formou projektů nebo direktivním nařízením Formou projektů Metody prosazení bezpečnosti Direktivní Osobní - Neformální Stručné pokyny (email, Intranet) a verbální působení na všechny zaměstnance Direktivní Neosobní - Formální Kombinace verbálních pokynů vedoucích a písemných organizačních. Závazné a formální seznámení s nařízeními Direktivní Neosobní Důsledně formální Písemné organizační pokyny Závazné a formální seznámení s nařízeními Bezpečnostní dokumentace Bezpečnostní politika, některé směrnice, občas konkrétní postupy Bezpečnostní politika a další dokumentace včetně směrnic, postupů, návodů apod. Kompletní řízená bezpečnostní dokumentace a její průběžná (plánovaná) revize Program zvyšování bezpečnostního povědomí Jednorázové informace dle potřeby. Bezpečnostní minimum součástí úvodního zaškolení. Nepravidelné pokyny a nařízení Bezpečnostní minimum součástí úvodního zaškolení. Specializovaná školení pro vybrané zaměstnance. Strukturovaný kontinuální vzdělávací program. Pravidelná specializovaná školení všech zaměstnanců. Způsob zvládání rizik za provozu Neformální proces, bez speciálních postupů a pravomocí. Pokrytí a kontrola bezprostředně po identifikaci. Formální proces s rámcově stanoveným postupem a odpovědnostmi. Revize zvládání rizik nepravidelná, dle potřeby. Formálně řízený proces s předem stanovenými postupy a pravomocemi. Pravidelné analýzy a kontroly zvládání rizik. 21

Nároky na provoz opatření a zajištění bezpečnosti Zavedení opatření DRP a IRH (Havarijní plány) Krátkodobé plánování. Není separátní rozpočet. Externí spolupráce není obvyklá. Zpravidla řada neformálních havarijních postupů pro jednotlivá aktiva. Krátkodobé a střednědobé plánování Rozpočet v rámci IT/IS Prosazuje se outsourcing Formální univerzální havarijní plán Postupy zvládání bezpečnostních incidentů Dlouhodobé plánování Individuální rozpočet Běžné využití outsourcingu Provedena analýza dopadů (BIA) Strukturované havarijní plány Formální postupy zvládání bezpečnostních incidentů 3.1.3 plan, do, CHECK, act Monitoring provozu Monitoring provozu klíčových prvků IS a ochranných opatření je základním zdrojem informací pro kontrolu jejich funkčnosti a spolehlivosti. Pokud organizace zavádějící ISMS plánuje v budoucnu i jeho certifikaci, musí vytvářet a shromažďovat záznamy o fungování alespoň těch opatření, která jsou uvedena v Prohlášení o aplikovatelnosti (ty budou předmětem auditu). Bohužel ne všechny typy opatření samy automaticky generují záznamy o činnosti a tak je nezbytné přistoupit i v prostředí malých a středních firem k nepopulárnímu ručnímu generování záznamů u takových opatření, která tuto vlastnost nemají (především organizační a administrativní). Nemusí se přitom zdaleka jednat o únavnou administrativu, protože rozsah a složitost opatření, zvláště u malých a středních firem, nebývá nijak velký. Příkladem toho, co postačí pro audit funkčnosti opatření bezpečnostní školení uživatelů IS, jsou seznamy účastníků školení a datum a předmět školení. Povinnost vůči případnému auditu ISMS a certifikaci je splněna. Pro monitoring ICT postačí u malých organizacích výchozí nastavení logování dle standardní instalace většiny produktů a jejich ruční namátková kontrola určeným pracovníkem. U středních organizací, je již vzhledem ke komplikovanosti IS infrastruktury nedostatečné spolehnout se pouze na namátkové ruční kontroly log souborů a je třeba využít automatických nástrojů pro jejich filtrování a vyhodnocování nestandardních událostí např. pomocí skriptů nebo dodatečných produktů. Testování funkčnosti opatření Pasivní metody kontroly je třeba doplnit i o aktivní a preventivní způsoby, jakými jsou např. aplikační kontroly chyb výpočtů a zpracování dat nebo testování zranitelností, případně penetrační testování systémů. Zatímco komplikovanější a časově i finančně náročnější penetračního testování 22

má za cíl simulaci reálných útoků ze zvoleného prostředí a identifikaci možných negativních dopadů na IS, bezesporu jednodušším, rychlejším a levnějším způsobem testování odolnosti vůči útokům je vyhledání a testování zranitelností provozovaných ICT produktů. Oba způsoby mohou být prováděny z interní sítě, nebo častěji z externího prostředí zpravidla Internetu nebo bezdrátových sítí, což by měly být v případě malých a středních firem hlavní oblasti prevence proti útokům na IS. Protože se v případě penetračního testování jedná o vysoce specializovanou činnost, vyžadující detailní znalosti o technikách a nástrojích hackingu, stejně jako o bezpečnostních slabinách jednotlivých ICT produktů a komunikačních protokolů, bývá tento úkol svěřován specializovaným externím firmám, které mají dostatečné profesní zázemí pro jejich kvalifikovanou realizaci. Naproti tomu testování zranitelností je proces, který si mnohdy mohou počítačově gramotní uživatelé udělat sami, pomocí dostupných programů nebo využít specializovaných webových služeb. Pro střední a velké organizace by testování zranitelností klíčových serverů a služeb IS mělo být samozřejmostí, alespoň po implementaci bezpečnostních opatření a před rutinním provozem komunikačních spojů. Pokud střední a velké organizace provozují citlivá data a aplikace na Internetu, mohou zvážit realizaci penetračního testování nebo podrobný technický bezpečnostní audit konfigurace klíčových prvků IS a bezpečnostních opatření jako např. Firewallu, DNS nebo Internetového aplikačního nebo databázového serveru či routeru na rozhraní LAN/WAN. Audit a kontrola bezpečnostních opatření Spolu s monitorováním provozu, testováním zranitelností a technicky zaměřeným auditem konfigurace ICT, je další metodou kontroly implementace a provozu IS/ISMS realizace Auditu a kontrol bezpečnosti IS. Obecně lze říci, že audit opatření musí být prováděn v každém typu a velikosti organizace, která provozuje systém řízení nad opatřeními, jinak by neexistovala zpětná vazba o stavu reality vůči plánu a návrhu požadovaného cílového stavu. Každý typ auditu by se měl řídit pravidly ISO 19011:2002 a měl by probíhat dle schváleného ročního i operativního plánu. V případě ISMS by měl audit zahrnovat kontrolu funkčních bezpečnostních i řídících opatření ISMS, která jsou deklarována v Prohlášení o aplikovatelnosti a popsána v bezpečnostní dokumentaci. Audit by měl ověřit jak jsou realizována v praxi. U malých organizací není třeba vytvářet samostatná oddělení nebo pracovní funkce interního auditora, ale je nutné i v malé organizaci funkci interního auditora dedikovat, alespoň jako přidruženou pracovní náplň nějakému zaměstnanci. Jednou ročně je nezbytné projednání zjištěných výsledků plánovaných auditů i namátkových kontrol s majitelem/ředitelem organizace a následně se všemi zaměstnanci. V případě středně velké organizace se již doporučuje zvážit existenci samostatné funkce interního auditora, kterému připadne i funkce bezpečnostního auditora. I v tomto případě má za úkol provádění plánovaných i namátkových kontrol dle ročního i operativního plánu auditu, který je sestavován s přihlédnutím k největším rizikům a nálezům předchozích auditů. Pro dosažení vyšší odborné úrovně a komplexnosti výsledků kontroly je doporučeno realizovat alespoň jednou ročně přehledový srovnávací audit stavu ISMS, vzhledem k požadavkům ISO 27001, s účastí jednoho externího odborného konzultanta. 23

Revize adekvátnosti a efektivnosti ISMS Kromě ověření funkčnosti, spolehlivosti a úplnosti funkčních i řídících opatření je třeba přibližně jednou ročně zrevidovat rozsah, adekvátnost a efektivnost celého ISMS ve vztahu k potřebám, cílům a prostředí organizace. Výsledek této celkové revize ISMS by měl být stejně jako souhrnné výsledky auditů opatření projednán s vedením organizace a pořízeny záznamy o přijatých závěrech. Jelikož se jedná o činnost vyžadující široký přehled a značné zkušenosti z oblasti bezpečnosti informací a implementace ISMS v organizacích, musejí se malé i střední organizace spolehnout na pomoc externích specialistů, stejně jako v případě analýzy informačních rizik v etapě PLAN. Proces Malá organizace do 15 zaměstnanců, 1-2 úrovně vedení Střední organizace do 150 zaměstnanců, 3-5 úrovní vedení Velká organizace nad 150 zaměstnanců, 4 a více úrovní vedení Monitoring IS a testování funkčnosti opatření Namátkový monitoring provozu IS a vyhodnocování logů a záznamů událostí (v papírové i el. podobě). Otestování zranitelností u systémů připojených k Internetu. Pravidelný monitoring a vyhodnocování logů a záznamů událostí (v papírové i elektronické podobě). Otestování zranitelností u systémů připojeným k externím subjektům (třetím stranám). Centralizovaný a automatizovaný monitoring provozu ICT a vyhodnocování logů a záznamů událostí. Pravidelné testování zranitelností doplněné o penetrační testování (simulaci hacker útoků). Bezpečnostní analýza klíčových prvků systému. C H E C K Audit a kontrola bezpečnostních opatření Audit opatření včetně ISMS dle dokumentace a plánu auditu (v případě certifikace ISMS). Iniciuje ředitel, provádí vybraný pracovník jako rozšíření standardní pracovní náplně. Namátková interní kontrola stavu opatření. Audit opatření včetně ISMS dle dokumentace a plánu auditu (v případě certifikace ISMS). Bezpečnostní technický audit nastavení klíčových ICT systémů. Namátková interní kontrola stavu opatření. Pravidelná interní kontrola a audit bezpečnostních a ISMS opatření, dle interních směrnic a politik (vyhrazený interní auditor). Průběžný bezpečnostní technický audit konfigurace ICT a bezpečnostních záplat. Revize adekvátnosti a efektivnosti ISMS Rámcová revize procesu ISMS a vyhodnocení aktuálnosti, efektivnosti a adekvátnosti opatření. 1 denní workshop s využitím externího konzultanta. Roční podrobná revize procesu ISMS a stavu opatření s využitím externího konzultanta. Porovnávání stávajících opatření s novými trendy a vývojem hrozeb a zranitelností. Srovnávací audit stavu ISMS s normou. Průběžné přehodnocování míry zbytkových a akceptovaných rizik vůči cílům organizace. Revize podnětů na zlepšení efektivnosti. 24