BEZPEČNOST ICT
Marek Chlup
Obsah Předmluva ............................................................................................................................. 3
1.
Zavedení systému řízení bezpečnosti – ISMS ............................................................... 4
2.
Zavedení systému řízení bezpečnosti – ISMS Model PDCA......................................... 7
3.
ISMS - ohodnocení aktiv...............................................................................................11
4.
Analýza rizik .................................................................................................................14
5.
Analýza rizik - postupy..................................................................................................18
6.
Hrozby? A co s nimi?....................................................................................................21
7.
ISMS – Dokumentace...................................................................................................25
8.
ISMS nebo ITIL?...........................................................................................................29
9.
ISMS - nejčastější chyby...............................................................................................34
10. ISMS – Business Impact Analysis ................................................................................37 11. ISMS – školení .............................................................................................................40
Doslov ..................................................................................................................................43
2
Předmluva Vážení čtenáři, do rukou se vám dostává publikace o bezpečnosti informačních a komunikačních technologií. Motivací pro vznik tohoto „díla“ byla snaha přinést ucelené informace týkající se oblasti zásadní pro úspěšné fungování každé organizace. Ať už implementujete informační bezpečnost pomocí interních zdrojů, za spolupráce s externí firmou či bezpečnost IS zcela outsourcujete, publikace vám podá pomocnou ruku při orientaci v této problematice. Na oblast informační bezpečnosti budeme nahlížet z různých úhlů pohledu. Získáte přehled o normách upravujících informační bezpečnost, seznámíte se s postupy zavádění bezpečnosti, budete upozorněni na možné nástrahy a rizika při implementaci, obeznámíte se s dokumentací potřebnou k nastavení funkční bezpečnostní politiky a nakonec se dozvíte o důležitosti šíření povědomí o bezpečnosti IS v rámci firmy. Touto publikací jsme dále chtěli zdůraznit, že pro efektivní fungování informační bezpečnosti je velmi důležité, aby nebyla pouze jednorázovou aktivitou, ale kontinuálním procesem. Nyní se už v klidu začtěte do následujících řádků…
3
1. Zavedení systému řízení bezpečnosti – ISMS Bezpečnost ICT. Snad nejfrekventovanější termín všech rozhovorů o IT současnosti. Nejdříve si tedy upřesníme pojem bezpečnost IT: Pod pojmem bezpečnost IT obvykle rozumíme ochranu odpovídajících IS a informací, které jsou v nich uchovávány, zpracovávány a přenášeny. Součástí takto obecně chápané bezpečnosti IT je i komunikační bezpečnost, tj. ochrana informace přenášené mezi počítači, fyzická bezpečnost, tj. ochrana před přírodními hrozbami a fyzickými útočníky a personální bezpečnost, tj. ochrana před vnitřními útočníky.
Bezpečnost? Nelze jistě zpochybnit, že je to problém palčivý a urgentní. Před deseti lety jsme řešili problém, jak postavit síť nebo jak rozchodit informační systém. Bezpečnost byla velmi často jen překážka k rychlému dosažení cíle. Mnoha firmám se tento přístup však krutě nevyplatil. Proč se tento názor mění? Je to dáno mnoha faktory. Ten nejdůležitější je uvědomění si, že ICT znamená pro primární business společnosti naprosto nepostradatelnou složku. Nedostupnost systému bude mít za následek ochrnutí společnosti a její možný zánik. Dnes máme nepřeberné množství různých ochranných a obranných nástrojů. Jsou to softwarové a hardwarové nástroje. Třetí v řadě jsou bezpečnostní standardy. Bohužel všechny tři výše uvedené nástroje málokde stojí na stejné úrovní. Podle studie PSIB SR 041 byly uvedeny jako nejrozšířenější příčiny bezpečnostních incidentů výpadek proudu, počítačový virus a porucha hardware. O rok později podobné výzkumy ukazují, že největším rizikem se stávají vlastní zaměstnanci. Jedním z nejúčinnějších opatření proti vnitřnímu nepříteli ve firmě, je nasazení jasných a přesných bezpečnostních standardů. Je samozřejmě možné, vytvořit si strukturu takových standardů „podomácky“. Je to ovšem řešení s tím rizikem, že tvůrce může opomenout důležitý segment celkové bezpečnosti. Mnohem rozumnější je vzít si k ruce standardy již existující a ověřené. A právě o těchto standardech, jejich filozofii a způsobech nasazení bude tato publikace.
Normy Celosvětově uznávaných standardů určených k zavedení systému řízení bezpečnosti není mnoho. Ten nejrozšířenější se celým názvem jmenuje ISO/IEC 27001 – Information Security Management Systems (dále jen ISMS). Do češtiny je překládán jako systém pro řízení bezpečnosti informací. Tato norma ve své preambuli definuje svůj účel: 1
PSIB SR 04 – Prieskum stavu informačnej bezpečnosti v SR 2004, KPMG Slovensko, DSM, NBÚ SR
4
Tato mezinárodní norma byla připravena proto, aby poskytla podporu pro ustavení, zavedení, provozování, monitorování, udržování a zlepšování systému řízení bezpečnosti informací (Information Security Management Systems nebo ISMS2). Všimněte si pečlivě, k čemu norma slouží – podporu pro ustavení, zavedení, provozování, monitorování, udržování a zlepšování. Ano, to jsou ty hlavní pojmy při zavádění bezpečnosti. Staré pravidlo říká, že bezpečnost nelze jen zavést, ale je třeba ji dále rozvíjet a zlepšovat. A právě toto nám ISMS nejen umožňuje, ale přímo to od nás vyžaduje. Další existující normy a metodiky zde jen zmíníme, neboť jejich podrobný popis by vydal na celou knihu. Vážený čtenář si v případě zájmu jistě obstará informace, případně nechť se obrátí na autora.
BS 17799-2 Britský standard pro informační bezpečnost, BS 7799, uvedly v roce 1995 v život přední ekonomické organizace. Vznikl tak efektivní nástroj k hodnocení systémů řízení informační bezpečnosti (ISMS), který se rychle rozšířil po celém světě a dnes je k dostání ve více než 11 jazycích. V roce 1998 byla norma přizpůsobena požadavkům nových trendů, jako je e-commerce, a v roce 2000 schválena jako standard ISO. V roce 2005 byl uveden v platnost nejnovější standard, zahrnující ty nejaktuálnější poznatky z oblasti komplexní informační bezpečnosti - ISO 27001, který je postaven na základech BS 7799/ISO 17799. Norma sestává ze dvou částí: Příručka k řízení informační bezpečnosti a Specifikace pro ISMS. V současné době je plně nahrazena normou ISO/IEC 27001 ISMS.
ISO/IEC 20000 Norma ISO 20000 (známá také pod označením BS 15000) je nový standard, který se speciálně vztahuje k managementu služeb IT a zaměřuje na zlepšování kvality, zvyšování efektivity a snížení nákladů u IT procesů. ISO 20000, které vzešlo ze standardu BS 15000, popisuje integrovanou sadu procesů řízení pro poskytování služeb IT. Svojí filozofií a obsahem se řídí úspěšnými ustanoveními IT Infrastructure Library (ITIL). Není to však ITIL, jak je často a mylně uváděno. ITIL není standard ani metodika.
ITIL Information Technology Infrastructure Library (zkratka ITIL) je rámec přístupů k zajištění dodávky kvalitních IT služeb za přiměřených nákladů, který vychází z nejlepších praktických zkušeností. Knihovnu spravuje organizace Office of Government Commerce a je šířena formou knih, CD, školení, konzultací a certifikací. ITIL je v současnosti již de-facto mezinárodním standardem pro oblast řízení IT služeb.3
2 3
ISO/IEC 27001 – Information Security Management Systems http://www.ogc.gov.uk/
5
Knihovna ITIL je rozdělena do několika částí, zaměřených na specifickou oblast řízení IT služeb, které odpovídají klíčovým procesům v IT oddělení a vzájemně se prolínají. Dodávka IT služeb (IT Service Delivery) a Podpora IT služeb (IT service Support) se běžně 4 dohromady označují jako IT Service Management (ITSM).
ČSN ISO/IEC TR 13335 1-5 Sada technických zpráv, které jsou zaměřeny na jednotlivé kroky z hlediska zavádění bezpečnosti IT. Zde je jejich stručný popis: ČSN ISO/IEC TR 13335-1 Information technology -- Guidelines for the management of IT Security -- Part 1: Concepts and models for IT Security Informační technologie - Směrnice pro řízení bezpečnosti IT - Část 1: Pojetí a modely bezpečnosti IT ČSN ISO/IEC TR 13335-2 Information technology -- Guidelines for the management of IT Security -- Part 2: Managing and planning IT Security Informační technologie - Směrnice pro řízení bezpečnosti IT - Část 2: Řízení a plánování bezpečnosti IT ČSN ISO/IEC TR 13335-3 Information technology -- Guidelines for the management of IT Security -- Part 3: Techniques for the management of IT Security Informační technologie - Směrnice pro řízení bezpečnosti IT - Část 3: Techniky pro řízení bezpečnosti IT ČSN ISO/IEC TR 13335-4 Information technology -- Guidelines for the management of IT Security -- Part 4: Selection of safeguards Informační technologie - Směrnice pro řízení bezpečnosti IT - Část 4: Výběr ochranných opatření ISO/IEC TR 13335-5 Information technology -- Guidelines for the management of IT Security -- Part 5: Management guidance on network security Tyto technické zprávy jsou v případě zavádění systému řízení bezpečnosti nezbytným doplňkem a inspiračním materiálem. Některé techniky, které budeme v našem seriálu podrobně rozebírat (ohodnocení aktiv, analýza rizik) přímo vycházejí z těchto norem. Vyčerpávající seznam všech dostupných norem, které se zabývají bezpečností IT, naleznete na těchto www stránkách: http://domino.cni.cz/NP/NotesPortalCNI.nsf/key/technicka_normalizace~informace_o_norma ch~e_byznys~ceska_normalizace~bezpecnosti_it?Open
4
http://www.best-management-practice.com/
6
2. Zavedení systému řízení bezpečnosti – ISMS Model PDCA V první kapitole jsme si ve stručnosti popsali, co je bezpečnost IT a jaký je vztah některých ISO norem k ní. V druhé kapitole se budeme věnovat podrobnému popisu normy ISO/IEC 27001 – ISMS. Hlavní myšlenku celé normy Vám prozradím již nyní – informační bezpečnost musí být řízena a je lhostejno, zda se jedná o firmu s 30 nebo s 3000 zaměstnanci. Rozdílné budou pouze časové lhůty a množství práce. Systém řízení bezpečnosti informací je jeden. Rozdílné mohou být výklady jednotlivých doporučení a postupy, jak cíle dosáhnout. Principem celého ISMS je tzv. PDCA model (Demingův model), který je zobrazen na obrázku č.1. Obrázek 1: PDCA model ISMS
Tento model zavádí kontinuální systém řízení bezpečnosti informací v organizaci. Jeho jednotlivé kroky, tedy Plan – Do – Check - Act (plánuj, dělej, kontroluj a jednej) zaručují, že zavedení systému nebude jen jednorázovou aktivitou, ale neustálým koloběhem. Norma jasně popisuje, postup při zavádění ISMS a taxativně nařizuje, jakých cílů a bezpečnostních opatření musí být dosaženo. Tato část se nazývá „Příloha A“5 a je alfou a omegou při zavádění ISMS. V následujících odstavcích se pokusím popsat základní čtyři kroky při nasazení ISMS.
5
ISO/IEC 27001:2002 Information Security Management Systems
7
Kdo byl Edwards Deming? Většina modelů zlepšování procesů je založena na postupu, který zavedl W. Edwards Deming. Americký průkopník na poli managementu, který se proslavil po II. světové válce svojí činností v Japonsku, které pomohl hospodářsky postavit na nohy. Deming zavedl kroužky kvality složené ze samořízených týmů, které učil filozofii TQM a kontinuálního zlepšování (kaizen). Úspěchy japonské konkurence na světových trzích podnítily v 80. letech 20. století zájem západních průmyslníků o tyto metody. Součástí kontinuálního zlepšování je právě PDCA model, který byl převzat do mnoha odvětví.
ISMS - krok první Říká se, že všechny začátky jsou těžké. V případě implementace ISMS to platí dvojnásob, neboť jako první krok je nutné získat souhlas vedení společnosti s nasazením systému. Norma tento souhlas požaduje a z hlediska praktického, musí být zavádění ISMS prováděno směrem od vrchu dolů. Možná se Vám bude zdát, že získání souhlasu od managementu společnosti je poměrně snadnou záležitostí. Opak je pravdou. Management se tímto dokumentem zavazuje, že bude zavádění ISMS podporovat, což v praxi znamená, že to společnost bude stát v nejlepším případě lidské zdroje a téměř vždy i finance. Budete-li navíc ISMS nechávat certifikovat, bude to první dokument, který auditoři vyžadují. Tento dokument nemusí být rozsáhlý, ale musí pregnantně vyjadřovat ochotu a vůli společnosti, podřídit se systému ISMS. Bez tohoto dokumentu není možno nasazení systému řízení bezpečnosti uskutečnit.
ISMS - krok druhý V okamžiku, kdy získáme souhlas od vedení společnosti, který nám umožňuje implementaci ISMS, máme vytvořený implementační tým a můžeme tedy přikročit k druhému, kritickému kroku. Tento spočívá v provedení identifikace aktiv, jejich ocenění a vypracování celkové analýzy rizik. Identifikace a ocenění aktiv je v podstatě činnost, při které společnost provede „inventuru“ svých aktiv, což mohou být jak věci hmotné (např. výpočetní technika), tak věci nehmotné (data, znalosti, značka, apod.). Když jsou aktiva identifikována, je třeba ohodnotit je z hlediska integrity, dostupnosti a důvěrnosti. Nejlépe se tak činí na základě vlastního algoritmu, který určí hodnotu jednotlivých aktiv. Druhou částí je proces, který se nazývá analýza rizik a jeho provedení je popsáno například v normě ISO/IEC 133356. Je třeba si uvědomit, že analýza rizik je dokument, na němž se staví celý systém bezpečnosti informací. Jeho důležitost je tedy vysoká. Nebudete-li tento dokument mít dobře zpracován, je celý systém ISMS nefunkční a přivodí Vám obrovské problémy. Všechny tyto kroky budou podrobně popsány na následujících stránkách.
6
ISO/IEC TR 13335 - 3 Information Technology, Guidelines for the management of IT security – Part 3:Techniques for the management of IT Security.
8
ISMS - krok třetí Na analýzu rizik přímo navazuje dokument, který se jmenuje Návrh protiopatření. Popisuje, jak bude společnost reagovat na nalezená kritická místa. Ve stručné a jasné podobě popisuje, jak by měl vypadat cílový stav, jak ho společnost dosáhne, termín splnění a případné finanční nároky. Tento dokument je vedle analýzy rizik stěžejním dokumentem a budete-li certifikováni, auditoři jej budou velmi pečlivě studovat. Je vhodné, nechat si raději více času na jeho tvorbu a případnou diskusi s managementem. Nezapomínejte, že management, všechny dokumenty musí schválit, včetně finančních prostředků. Druhou variantou, jak lze na případná rizika reagovat, je tzv. institut akceptace rizika. Využívá se v případě, že nápravné opatření je například extrémně drahé a míra rizika velmi nízká. Obecně se doporučuje této možnosti využívat v minimální míře. Nyní máme téměř všechny dokumenty pohromadě a zbývá závěrečný souhrn, který patří k časově nejnáročnějším. Norma taxativně nařizuje, že společnost musí vytvořit dokument prohlášení o aplikovatelnosti. Vzpomínáte ještě na tzv. přílohu A normy, kde jsou popsány všechny náležitosti nutné pro zavedení ISMS? Zde je třeba krok za krokem doložit, které části ISMS a jak jsou zavedené. Nechejte si na vytvoření souladu dostatek času, teprve nyní můžete udělat konečné účtování a připravit se na certifikaci.
ISMS - krok čtvrtý Krok čtvrtý je z hlediska zavedení ISMS nepovinný. Rozhodnete-li se, že budete ISMS implementovat, neznamená to, že si jej musíte nechat certifikovat. Celý systém může fungovat i bez certifikace, ale je samozřejmě výhodnější projít certifikací. Skládá se ze dvou částí. V první je certifikována7 povinná dokumentace, ve druhé je kontrolováno praktické zavádění ISMS. Ti z Vás, kdo prošli certifikací například na ISO 9001, mají výhodu, neboť oba systémy jsou kompatibilní a vědí tedy, jak certifikace probíhá. Synergii ISMS a ostatních norem ISO bude věnována samostatná kapitola této publikace. Na závěr seznam nezbytných dokumentů v případě nasazení ISMS: A. Rozsah a hranice ISMS B. Politika ISMS C. Definice a popis přístupu k hodnocení rizik D. Identifikace rizik E. Analýza a vyhodnocení rizik F. Identifikace a varianty pro zvládání rizik G. Cíle opatření a bezpečnostní opatření pro zvládání rizik (viz příloha A) H. Akceptace rizik I. Získání povolení k provozování ISMS v rámci organizace J. Prohlášení o aplikovatelnosti
7
ISO/IEC 17799:2005 Information technology Security Techniques – Code of practice for information security management (Informační technologie Bezpečnostní techniky – Soubor postupů pro řízení bezpečnosti informací)
9
Neobávejte se pořizování velkého množství dokumentů. Některé z výše uvedených jsou jednostránkové deklarace (Politika ISMS), ostatní je možné spojovat. Standardní počet vedené dokumentace ISMS je 5 dokumentů, které je třeba revidovat v souladu s PDCA modelem.
10
3. ISMS - ohodnocení aktiv Abychom mohli hodnotit a analyzovat, je nutné danou entitu nejdříve popsat a identifikovat. Identifikace a ohodnocení aktiv organizace je základní krok v celkovém procesu analýzy rizik. Vlastní proces ohodnocení aktiv si každá organizace může nastavit sama podle svých potřeb. Pokud neví jak, základní popis nabízí norma ČSN ISO/IEC TR 13335. V této kapitole bude vysvětleno, jak by identifikace a ohodnocení aktiv měli probíhat.
Identifikace aktiv Aby organizace mohla provést ohodnocení svých aktiv, musí je nejprve identifikovat. V této etapě se doporučuje seskupit všechna aktiva, která k sobě logicky patří. Například programová aktiva, bezpečnostní aktiva, obchodní aktiva, služby apod. Vždy je nutné identifikovat vlastníka každého daného aktiva. Vlastníkem aktiva rozumíme přímo pověřenou osobu, plně odpovědnou za toto aktivum. S tímto vlastníkem posléze určujeme konkrétní hodnotu aktiva. Aktivum je komponenta nebo určitá část celého systému, které organizace přikládá jistou hodnotu, a pro kterou je třeba mít nastavený způsob ochrany. Je důležité uvědomit si, že aktivum vůbec nemusí být tvořeno hardwarem nebo softwarem. Mezi nejdůležitější aktiva řadíme: o informace – data (klasicky zákaznický systém) o hardware (PC, tiskárna, notebook) o software (aplikace apod.) o komunikační zařízení (sítě, telefony, modemy) o dokumenty (smlouvy, zápisy apod.) o personál (know how) o image organizace Jistě se nejedná o zcela vyčerpávající seznam. Ve výrobní firmě to mohou být například vyrobené součástky, v obchodě peníze apod. Bohužel praxe je taková, že všechna aktiva mimo hardware a software bývají hrubě podceňována. Zvláště markantní je podcenění papírových dokumentů, kterých je v každé organizaci mnoho. Obvykle jsou uloženy v nechráněných prostorách s volným přístupem. Často se jedná o strategické dokumenty (porady vedení, obchodní jednání, smlouvy, agenda personálního charakteru apod.).
Nástroje K hodnocení aktiv je vhodné využít softwarový nástroj. Existují specializované programy například CRAMM metodika. Případně je možné vytvořit si základní tabulky pro výpočet ohodnocení aktiv v programu MS Excel nebo v jiném tabulkovém editoru.
Ohodnocení aktiv Dalším logickým krokem je stanovit stupnici a hodnotící kritéria, která budou použita k přiřazování ohodnocení určitého aktiva. Tato stupnice může být vyjádřena penězi nebo
11
kvalitativními hodnotami. Je na zvážení organizace a výskytu konkrétních aktiv, kterou z variant zvolí. Možné je také obě varianty kombinovat. Stupnice peněžní bude vyjadřovat v místní měně hodnotu určitého aktiva. Stupnice kvalitativní vyjadřuje hodnotu v termínech například od velmi nízké až po kritickou. Typické termíny používané pro kvalitativní hodnocení jsou: 1 2 3 4 5
Žádný dopad na organizaci Zanedbatelný dopad na organizaci Potíže či finanční ztráty Vážné potíže či podstatné finanční ztráty Může znamenat existenční potíže organizace
Důležité je také barevné odlišení. Máme-li mít rozsáhlé tabulky s hodnocením aktiv, pomohou vhodně zvolené barvy k jednodušší orientaci. Výběr a rozsah termínů, které si organizace zvolí, závisí na bezpečnostních potřebách organizace, její velikosti apod. Má-li organizace zaveden systém řízení kvality (ISO 9001), může využít stávající model k ohodnocení aktiv. Hlavním principem při ohodnocení aktiv jsou náklady vzniklé v důsledku porušení DŮVĚRNOSTI, INTEGRITY a DOSTUPNOSTI. Tedy tyto tři kritéria poskytují podklady pro ohodnocení aktiv. Typická otázka může například znít: „Jaký dopad bude mít na organizaci nedostupnost centrálního informačního systému?“ Odpověď: od „žádný dopad na organizaci, až po existenční potíže organizace“. Toto hodnocení je třeba provádět s majitelem aktiv. Protože jeho hodnocení může být subjektivně zbarveno, je vhodné provést podobné interview s některým „superuživatelem“ daného aktiva. Tato forma křížové kontroly je důležitým faktorem upřesnění hodnoty aktiva a je doporučováno provádět ji u všech aktiv, u nichž existuje předpoklad vysoké hodnoty pro organizaci. Celá řada aktiv může mít v průběhu hodnocení přiřazeno několik hodnot. Například informační systém může být hodnocen z hlediska pořizovacích investic, z hlediska důvěrnosti a dostupnosti, z hlediska práce nutné na implementaci apod. Každá z takto definovaných hodnot se bude zcela jistě lišit. Finálně přiřazená hodnota se může rovnat maximální hodnotě ze všech uvedených, může být průměrem nebo součtem. Ať si vyberete jakýkoliv model, musíte jej pak použít pro všechny aktiva, u nichž je využita kombinovaná hodnota. Nezapomeňte, že zde stanovené hodnoty slouží jako základ pro analýzu rizik a výpočet nákladů na jejich ochranu.
Výpočet hodnoty aktiva Pro výpočet ohodnocení aktiva je možno využít různé postupy. Nejjednodušším a také nejpoužívanějším je tzv. součtový algoritmus. Principem je součet: Dostupnost + Důvěrnost + Integrita / 3. (x + y + z/3).
12
Následuje praktická ukázka: Hodnotící škála 1-5 (viz. výše) Aktivum: Data o zákaznících – Systém 1 Hodnota aktiva z hlediska Dostupnosti 5 Hodnota aktiva z hlediska Důvěrnosti 5 Hodnota aktiva z hlediska Integrity 3 Celková váha: 5 + 5 + 3/3 = 4 Závěr: Ztráta tohoto aktiva může pro organizaci znamenat vážné potíže či podstatné finanční ztráty. Tento součtový algoritmus poskytuje nejrychlejší způsob, jak získat hodnotu aktiva. Zároveň také odpovídá na otázku, jaký dopad pro organizaci bude mít zničení, případně poničení tohoto systému. Je vhodné při hodnocení aktiva věnovat zvýšené úsilí detailnímu popisu a „pátrání“, kde všude dané aktivum může být umístěno. Na příkladu, který je zde uváděn, lze provést ukázku. Aktivum, které je hodnoceno se jmenuje „Data o zákaznících“. Je jasné, že taková data nejsou umístěna jen na jednom místě. Takové informace se nachází v informačním systému, na síťových úložištích, na noteboocích pracovníků organizace a často také na mobilních zařízeních. Požadujeme-li tedy úplné a přesné ohodnocení aktiva „data o zákaznících“, je třeba ohodnotit jejich dostupnost, důvěrnost a integritu na všech lokacích, kde jsou umístěna. Dá se tedy jednoduše odvodit, že detailní ohodnocení je třeba udělat nejen pro informační systém, ale také pro síťové disky, notebooky a mobilní zařízení. Na obrázku je patrné, jak by mohla tabulka pro ohodnocení aktiv vypadat.
Aktivum
Informace o zákaznících
Zdroj
Dostupnost Důvěrnost Integrita
Váha
Systém 1
5
5
3
4
Síťové disky
2
5
3
3
PC a NB obchodních zástupců
5
5
3
4
13
4. Analýza rizik Tato kapitola bude věnována snad nejdůležitější části zavádění systému řízení bezpečnosti – Analýze rizik. Na předcházejících stránkách jsme si vysvětlili všechny principy a náležitosti. Vysvětlili jsme postup identifikace a ohodnocení aktiv. Analýza rizika je prováděna za účelem identifikace zranitelných míst Informačního systému organizace8. Následně zachycuje seznam hrozeb působících na IS a stanovuje rizika příslušná každému zranitelnému místu a hrozbě. Účelem takového dokumentuje snížení rizik na přijatelnou úroveň, respektive akceptaci zbytkových rizik tam, kde je jejich minimalizace neefektivní. Analýza rizik je rozdělována: o o o o
Analýza rizik – hrubá úroveň Analýza rizik – neformální přístup Analýza rizik – kombinovaný přístup Analýza rizik – podrobný přístup
Nejčastější průběh analýzy rizik je popsán ve směrnici ČSN ISO/IEC TR 13335-3. Doporučuje se použít kombinaci metod pragmatické (neformální) a detailní analýzy rizik. Nejprve je provedena počáteční analýza rizik na hrubé úrovni pro všechny systémy IT. U systémů, které budou identifikovány jako významné pro činnost organizace, případně vystavené vysokým rizikům, provádíme podrobnou analýzu rizik.
Analýza rizik na hrubé úrovni Tato analýza na hrubé úrovni bere v úvahu hodnotu systému IT pro činnost organizace a zpracovávaných informací a rizika z pohledu činnosti organizace. Pro rozhodnutí jaký přístup je pro daný systém IT vhodný, bude mít význam zohlednění následujících skutečností: o jakých cílů má být použitím systému IT dosaženo o úroveň investic do tohoto systému IT (vývoj, údržba, nahrazení) o aktiva systému IT, kterým organizace přiřazuje určitou hodnotu o stupeň, v jakém činnost organizace závisí na systému IT (zda funkce, které organizace považuje pro své přežití za kritické nebo efektivní, jsou závislé na tomto systému IT) Po tomto základním rozdělení budeme vědět, které systémy jsou vhodné k nasazení základního přístupu (ty méně kritické, nákladné apod.) a ty u kterých je nutné provést podrobnou analýzu rizik.
8
BS ISO 17799:2005
14
Analýza rizik - neformální přístup Tato možnost představuje neformální, pragmatickou analýzu rizik. Neformální přístup není založen na strukturovaných metodách, ale využívá znalosti a zkušenosti jednotlivců. Výhodou této volby je, že nevyžaduje obvykle mnoho zdrojů nebo času. K provedení této neformální analýzy není nutné se naučit nové dodatečné dovednosti a tato analýza je provedena rychleji než podrobná analýza rizik. Existuje však také několik nevýhod. Bez určitého typu formálního přístupu nebo detailních seznamů kontrol vzrůstá pravděpodobnost opomenutí některých důležitých detailů, je obtížné obhájit implementaci ochranných opatření ve vztahu k rizikům odhadnutým tímto způsobem. V minulosti byly některé přístupy založeny na zranitelnostech, tj. byla implementována bezpečnostní ochranná opatření založená na identifikovaných zranitelnostech, aniž by se zvažovalo, zda existovaly konkrétní hrozby, které by pravděpodobně využily tyto zranitelnosti, tj. zda vůbec existovala reálná potřeba ochranných opatření. Tímto způsobem může docházet ke zbytečnému navyšování finančních prostředků.
Analýza rizik – kombinovaná metoda Třetí možností je nejprve provést počáteční analýzu rizik na hrubé úrovni pro všechny systémy IT, která se soustřeďuje u každého případu na hodnotu systému IT pro činnost organizace a na vážná rizika, jimž je systém IT vystaven. U systémů IT, které jsou identifikovány jako významné pro činnost organizace a/nebo vystavené vysokým rizikům, by měla být přednostně provedena podrobná analýza rizik. Pro všechny zbývající systémy IT by měl být zvolen základní přístup. Tato volba, která je kombinací nejlepších charakteristik možností umožňuje minimalizaci času a úsilí věnovaného na identifikaci ochranných opatření, přičemž stále ještě zajišťuje, že jsou vysoká rizika systému chráněna příslušným způsobem.
Podrobná Analýza rizik Podrobná analýza rizik systému IT obsahuje identifikaci souvisejících rizik, a odhad jejich velikosti. AR se provádí identifikací potenciálních nepříznivých dopadů nežádoucích událostí na činnost organizace a pravděpodobnost jejich výskytu. Pravděpodobnost výskytu bude záviset na tom, jak atraktivní jsou aktiva pro potencionálního útočníka, na pravděpodobnosti výskytu hrozeb a na snadnosti s kterou mohou být zranitelnosti využity. Podrobná Analýza rizik zahrnuje hloubkovou revizi v každém z kroků, uvedených na obr. 2. na následující straně.
15
Obrázek 2
Tímto dosáhneme vhodného výběru oprávněných ochranných opatření jako část procesu managementu. Požadavky na tato ochranná opatření musí být zakomponovány do bezpečnostní politiky systému IT. V následujících odstavcích jsou popsány některé kroky naznačené obrázkem 2.
Stanovení hranic revize Stanovení hranic revize bude provedeno ještě před identifikací a hodnocením aktiv. Pečlivá definice hranic nám umožní vyvarovat se zbytečných činností. Jinými slovy budeme definovat, kterých prvků se bude analýza rizik týkat, například aktiva IT (HW, SW, data).
16
Identifikace aktiv Aktivum je komponenta nebo část celkového systému, které organizace přímo přiděluje hodnotu a pro kterou tudíž organizace požaduje ochranu. Při identifikaci aktiv vezmeme v úvahu i to, že systém IT netvoří jen HW a SW. Druhy aktiv mohou být například data, komunikační zařízení, dokumenty, zboží, personál, image firmy.
Ohodnocení aktiv Ve chvíli, kdy budeme mít identifikovaná aktiva, musíme k nim přiřadit hodnoty. Tyto hodnoty reprezentují význam aktiv pro činnost organizace. Vstupní údaje pro hodnocení aktiv budou zajištěny vlastníky a uživateli aktiv, například formou dotazníku, případně pomocí interview. Hodnota aktiv nemusí být určena finančním ohodnocením, ale například z hlediska nepříznivých dopadů na činnost organizace, plynoucí ze ztráty důvěrnosti, integrity, dostupnosti, individuální odpovědnosti, autenticity a spolehlivosti. Nejčastěji bývá použita hodnotová škála 1-5, přičemž 1 znamená nízká hodnota 5 velmi vysoká hodnota.
Hodnocení hrozeb Hrozba představuje možnost poškodit zkoumaný systém IT a jeho aktiva. Hrozby mohou být přírodního nebo lidského původu a mohou být úmyslné nebo náhodné. Jako základní katalog hrozeb lze využít seznam uvedený v normě ČSN ISO/IEC TR 13335-3 v příloze C. Hodnocení hrozeb bude dáno do souvislosti s identifikovanými aktivy společnosti.
Odhad zranitelnosti Tento odhad odhalí slabá místa ve fyzickém prostředí, organizaci, postupech, personálu managementu, administraci HW, SW, nebo komunikačním zařízení, která mohou být využita jako zdroj hrozby a způsobit tak škodu na aktivech. Následnými úkony, které budou následovat se rozumí: o identifikace existujících / plánovaných ochranných opatření o odhad rizik o přijetí / nepřijetí rizik o implementace nápravných opatření
17
5. Analýza rizik - postupy Základní přístup Cílem základní ochrany9 je stanovit minimální sadu ochranných opatření k ochraně všech nebo některých systémů IT. Při tomto přístupu je možné aplikovat základní ochranu na takto definovaných systémech. Odpovídající ochrany je možné dosáhnout použitím katalogů ochranných opatření, které navrhují a popisují sadu ochranných opatření k ochraně systému IT proti nejobecnějším hrozbám. Nejčastěji je použita sada ochranných opatřeních popsaná v normě ISO/IEC TR 13335-4.
Identifikace plánovaných a existujících ochranných opatření Součástí Analýzy rizik je tzv. identifikace plánovaných nebo existujících bezpečnostních opatření. Jednoduše řečeno jedná se o to, aby existující nebo plánovaná bezpečnostní opatření byla identifikována a popsána. Vyhneme se tak zbytečné práci, zvýšeným nákladům apod., které jsou způsobeny zdvojením ochranných opatření. Často dochází i k tomu, že identifikované ochranné opatření je revidováno a je buď zcela odebráno, nebo nahrazeno opatřením vhodnějším či lépe vyhovujícím novým podmínkám bezpečnosti. Dalším významným důvodem, proč provádět revizi těchto opatření, je kontrola sladění jednotlivých řešení. Při implementaci systému řízení bezpečnosti informací dochází často k souběžné práci jednotlivých týmů. Může nastat situace, kdy jednotlivá bezpečnostní opatření, ať už existující nebo navržená si mohou vzájemně překážet. Výsledným efektem je pak místo bezpečnostního opatření bezpečnostní díra a následně bezpečnostní incident. Při identifikaci existujících ochranných opatření je vhodné provést kontrolu, jinými slovy otestovat je, zda fungují tak, jak se předpokládá, a zda nejsou v rozporu s navrhovanými bezpečnostními opatřeními. Výsledkem tohoto kroku je mimo výše zmiňovaného také seznam všech existujících a plánovaných bezpečnostních opatření. Podcenění tohoto kroku může vést k vážným bezpečnostním zranitelnostem.
Výběr ochranných opatření Princip ochranných opatření spočívá ve snížení případných rizik na minimum. Aby se usnadnil popis jednotlivých typů ochranných opatření, jsou v rámci normy zavedeny kategorie ochranných opatření. Podrobně jsou popsána v normě ČSN ISO/IEC TR 13335-4. mezi nejdůležitější jsou řazena tzv. „všeobecně aplikovatelná ochranná opatření“. Jedná se o základní kategorie: o řízení a politiky bezpečnosti IT o kontrola bezpečnostní shody o řešení incidentů o personální opatření o provozní problémy o plánování kontinuity činnosti organizace o fyzická bezpečnost 9
ČSN ISO/IEC TR 13335-3
18
Ochranná opatření těchto kategorií vytváří základ pro úspěšné řízení bezpečnosti IT. Doporučuje se rozhodně nepodceňovat tyto základní kategorie. Každá z těchto kategorií je dále dělena. Veškeré podrobnosti jsou popsány v normě. Při výběru ochranných opatření je neméně důležité uvažovat z pohledu velikosti organizace, a její ochrany. Je jasné, že potřeba ochrany informací bude daleko vyšší v nemocnici nebo státním úřadě než v potravinářském družstvu. Nemocnice má nejen povinnost se o data postarat, ale má také možnosti (personální, finanční) data zabezpečit. Zda se tak skutečně děje, není tématem této publikace. Důležité je, že nejpozději v tomto okamžiku, by měla být zřízena funkce „bezpečnostního ředitele“. Osoby nebo role, která ponese odpovědnost za zavádění systému řízení bezpečnosti a bude mít samozřejmě i příslušné pravomoci.
Odhad rizik Cílem tohoto kroku je identifikovat a odhadnout rizika, kterým jsou systém IT a aktiva vystavena. Jednoduše řečeno, musíme zjistit, co nám hrozí a „odkud vítr vane“, tedy proč nám daná rizika hrozí. Existují různé metody vzájemného vztahu rizika a hrozeb. Nejjednodušší je stanovení si škály 1-5 od nejnižší míry rizika po nejvyšší. Pro každé riziko použijeme tuto škálu. Následně sečteme všechny hodnoty a podělíme je počtem jednotlivých rizik. Výsledná hodnota nám určuje celkovou míru rizika pro dané aktivum. Samozřejmě je možné vytvořit si metodiku vlastní, případně využít automatizované softwarové nástroje. Ať je použita jakákoliv metoda k odhadu míry rizika, výsledkem musí být seznam naměřených rizik. Nepodceňujme kvalitu vstupů! Čím přesnější vstupy budou, tím přesnější a pravděpodobnější budou odhady a výstupy.
Přijetí rizik Po identifikaci a odhadu rizik, po výběru a revizi ochranných opatření, vždy zůstávají tzv. zbytková rizika. Úplně bezpečný systém je pouze teoretická hypotéza, ke které není možno se v reálném provozu přiblížit. Tato zbytková rizika mohou být rozdělena a být buď akceptována (akceptace rizika), nebo neakceptována. Je záležitostí nejvyššího managementu, kterému jsou tato zbytková rizika předložena, jak rozhodne. Jakákoliv odpovědnost nenáleží implementačnímu týmu, ale pouze nejvyššímu managementu společnosti. V praxi bohužel, často o zbytkových rizicích nerozhoduje nejvyšší management, ale informatik z pověření managementu. Jestliže riziko není akceptováno, probíhá znovu výběr ochranných opatření a odhadování rizik. Je zde vysoké riziko, že může být přijato dodatečně ochranné opatření, které je příliš nákladné nebo z hlediska bezpečnosti zbytečné.
19
Politika bezpečnosti systému IT Politika bezpečnosti systému IT by měla obsahovat podrobnosti požadovaných ochranných opatření a popis, proč jsou nezbytná. Mnoho systémů vyžaduje své vlastní politiky bezpečnosti, které popisují specifická a podrobná řešení. Politika bezpečnosti všechny tyto dílčí materiály zastřešuje. Je založena na výsledcích analýzy rizik a identifikace ochranných opatření. Jedná se tedy o dokument, který zajistí, že množství již existujících dílčích „politik“ je revidováno s probíhající analýzou rizik a dáno do souladu se zaváděnými bezpečnostními pravidly.
Plán bezpečnosti IT Jedná se o shrnující dokument, který stručně popisuje veškeré akce, které se musí uskutečnit, aby mohla být implementována ochranná opatření. Stručně řečeno, vše co jsme v předchozích dílech popisovali, by mělo být zahrnuto v tomto dokumentu. Je vhodné rozčlenit jej v logické posloupnosti, stejně jak byl popisován v tomto seriálu. Výsledkem by měl být podrobný plán bezpečnosti, který zohledňuje výsledky celé analýzy rizik, včetně popisu ochranných opatření, postupů, rizik apod. Měl by také popisovat časový rozvrh pro následné postupy (implementace, revize, certifikace).
20
6. Hrozby? A co s nimi? Co je vlastně hrozbou pro Informační systém? Víme, že aktiva jsou předmětem mnoha typů hrozeb. Hrozba má potenciální schopnost způsobit nežádoucí incident, který může mít za následek poškození systému nebo organizace a jejich aktiv. Tato škoda se může vyskytnout jako důsledek přímého nebo nepřímého útoku na informační systém. Myšlena jsou například data uložená v rámci Informačního systému nebo služby, které systém využívá. Důsledkem je například neautorizované zničení dat, jejich zpřístupnění, modifikace, deformace, nedostupnost nebo ztráta.
Základní rozdělení hrozeb Hrozby mají původ buď přírodní (zemětřesení, blesk) nebo lidský (odposlech, chyba uživatele, apod.). Dále hrozby rozlišujeme na náhodné (vymazání souboru) a úmyslné (krádež). Z hlediska bezpečnosti je žádoucí, aby jak náhodné tak úmyslné hrozby byly identifikovány a měla by být odhadnuta jejich úroveň a pravděpodobnost. Otázka zní: Jaké hrozby jsou pro danou organizaci aktuální? Statistiky jsou dostupné například na Internetu (www.dsm.tate.cz ).Tato statistická data se týkající mnoha typů hrozeb okolního prostředí. Organizace by si měly tato data opatřit a použít je v procesu odhadu hrozeb. Obrázek 3
„Zdroj PSIB SR '04, KPMG Slovensko, DSM – data security management, NBÚ SR“.
21
Hrozby obecně mohou ovlivnit specifické části organizace, mnoha různými způsoby. Mezi nejčastější patří například narušení serverů a následně i osobních počítačů. Samozřejmě hrozby mohou být obecné vzhledem k okolnímu prostředí určitého místa, ve kterém systém nebo organizace působí, např. poškození budov vichřicí nebo blesky. Škoda způsobená nežádoucím incidentem může být dočasné povahy nebo může být trvalá, jako je tomu v případě zničení aktiv. Tabulka 1: Rozdělení hrozeb – příklad
Lidské hrozby
Hrozby prostředí
úmyslné
neúmyslné
odposlech
chyba uživatele
blesk
krádež
vymazání
povodeň
hacking
fyzická nehoda
požár
Posouzení hrozeb Posouzení hrozeb provádíme vždy v závislosti na následujících otázkách: o ztráta důvěrnosti – může vést například ke ztrátě důvěry vůči zákazníkům, právní odpovědnosti, ohrožení osobní bezpečnosti nebo finanční ztrátě o
ztráta integrity – může vést například k přijetí nesprávných rozhodnutí, rozpadu funkčnosti organizace
o
ztráta dostupnosti – může vést například k neschopnosti vykonávat kritické činnosti organizace
o
ztráta individuální odpovědnosti – může vést například k podvodu, špionáži, krádeži
o
ztráta autentičnosti – může vést například k použití neplatných dat, která vedou k neplatným výsledkům
o
ztráta spolehlivosti – může vést například k nespolehlivým dodavatelům, demotivace zaměstnanců
Při stanovení míry hrozeb a typů hrozeb je doporučováno využít standardní dělení, které vychází z předchozího seznamu. To znamená podívat se na každé aktivum z hlediska hrozby a dopadu například důvěrnosti. „Bude znamenat hrozba selhání dodávky energie pro centrální ekonomický software znamenat ohrožení důvěrnosti dat a organizace?“ Standardizovaný seznam možných hrozeb pro informační systém čítá 46 položek, zde však bude uvedeno jen několik nejčastějších, včetně popisu.
22
Nikdy nesmíme zapomenut na tzv. následné efekty hrozby. Například výpadek elektrické energie neznamená jen nedostupnost dat, ale může vést při dlouhodobém výpadku k ohrožení činnosti organizace, případně i ohrožení fyzické integrity člověka (nemocnice, hasiči, policie). Vždy je třeba promyslet možné dopady hrozeb do nejmenších podrobností.
Nejčastější hrozby Selhání dodávky energie Selhání dodávky energie může způsobit problémy z hlediska integrity a následně může způsobit i další poruch (selhání HW apod.). Selhání dodávky se samozřejmě netýká jen vlastního HW, ale také klimatizace, celého síťového prostředí, zálohování a podobně. Škodlivý software Škodlivý software může být použit ke zmaření autentizace a všech souvisejících služeb a bezpečnostních funkcí. Ve svém důsledku může vést ke ztrátě dostupnosti, jestliže jsou např. data nebo soubory zničeny osobou, která získala neautorizovaný přístup pomocí škodlivého programového kódu, nebo vlastním škodlivým programovým kódem. Selhání hardwaru Technické poruchy, např. v síti, mohou zničit dostupnost jakékoliv informace, která je uchovávána nebo zpracovávána v této síti. Mezi nejčastější příčiny selhání hardware patří například nedostatečná údržba, nejasné postupy při údržbě HW, nevhodné prostředí umístění HW (vlhkost, prach, výkyvy teploty apod.) Selhání komunikačních služeb Chyby a poruchy komunikačních zařízení a služeb ohrožují dostupnost informací přenášených prostřednictvím těchto služeb. V závislosti na příčině chyby nebo poruchy. Protiopatření vhodná k hrozbám Existují v podstatě tři aspekty, které mohou ochranná opatření postihnout, tj. dopady, hrozby, zranitelnosti. Hlavním cílem ochranných opatření jsou jednotlivé komponenty, které všechny dohromady mohou znamenat riziko, tj. dopady, hrozby a zranitelnosti. Způsoby, jakými mohou ochranná opatření řešit tyto aspekty, jsou: o hrozby – ochranná opatření mohou snížit pravděpodobnost výskytu hrozby (např. zvažujeme-li hrozbu ztráty dat v důsledku chyb uživatele, potom školení uživatelů by mohlo snížit množství těchto chyb) nebo, jako v případě záměrného útoku, mohou odstrašovat útočníka zvýšením technické složitosti pro provedení úspěšného útoku, o zranitelnost – ochranná opatření mohou odstranit zranitelnost nebo ji mohou učinit méně závažnou (například pokud je interní síť, připojená na vnější síť, zranitelná vzhledem k neautorizovanému přístupu, implementace vhodného firewallu by mohla učinit připojení méně zranitelným a odpojení odstraní tuto zranitelnost), nebo o dopad – ochranná opatření mohou omezit nebo vyloučit dopad (pokud je negativním dopadem nedostupnost informací, je omezena vytvořením kopie informací, které jsou někde jinde spolehlivě uloženy, a existujícím plánem kontinuity činnosti organizace,
23
připraveným k aktivaci); je-li k dispozici dobrý systém zaznamenávání auditních záznamů, prostředky pro analýzu a upozornění mohou napomoci včasnému odhalení incidentu a omezení nepříznivého dopadu na činnost organizace. To, jak a kde je ochranné opatření použito, může být příčinou velkého rozdílu v přínosech získaných jeho implementací. Velmi často mohou hrozby využívat více než jednu zranitelnost. Jestliže je tedy použito ochranné opatření, aby zabránilo výskytu takové hrozby, může být současně vyřešeno několik zranitelností. Možný je také opačný způsob – ochranné opatření chránící nějakou zranitelnost může postihnout několik hrozeb. Je-li to možné, měly by být při výběru ochranných opatření tyto přínosy zvažovány. Tyto dodatečné přínosy by měly být vždy dokumentovány, aby existoval podrobný přehled o bezpečnostních požadavcích, které ochranné opatření uspokojuje.
Závěrem Obecně lze doporučit provést ohodnocení minimálně kritických systémů z hlediska hrozeb. Vedle podrobné analýzy rizik je to další exaktní ověření zabezpečení systémů a stavu bezpečnosti. Doporučuje se ohodnocení hrozeb provést vždy. Jako dobrým návodem se jeví norma ISO/IEC TR 13335.
24
7. ISMS – Dokumentace V předchozích kapitolách o zavádění ISMS, byly předvedeny, vysvětleny a popsány jednotlivé postupy a principy, popisující jak, proč a kdy zavádět systém bezpečnosti informací. Byla obsažena i zmínka o povinné dokumentaci, kterou norma vyžaduje. Systém ISMS rozlišuje dva typy dokumentace – povinnou a nepovinnou. Povinná dokumentace je taková, kterou norma taxativně požaduje. Nepovinná je taková, kterou norma nezmiňuje, nicméně neznamená to, že taková dokumentace je nedůležitá. Typicky jde o různou pomocnou dokumentaci, která popisuje některé konkrétní činnosti. Nyní se zaměříme na dokumentací povinnou. V okamžiku, kdy plánujete zavedení ISMS ve své organizaci, aniž byste ho certifikovali, musíte tuto povinnou dokumentaci vytvořit. Dokumentace se tedy nevytváří „kvůli certifikaci“, ale jako základní část PDCA systému. Hlavním úkolem dokumentace je přehledné a aktuální zaznamenání všech důležitých komponent systému. A to ve srozumitelné formě, aby kdokoliv, kdo není obeznámen s podrobnostmi systému, po prostudování dokumentace pochopil celkové nastavení systému a dílčích segmentů.
Řízení dokumentů a záznamů Dokumentace a její vznik patří mezi nejméně oblíbené části systému ISMS. Obecně zde platí podobné principy jako u jiných částí ISMS. Doporučuji jmenovat pro každou část dokumentace garanta, plně odpovědného za vytvoření dokumentu. Dále je nesmírně důležité dodržovat schvalovací a verzovací principy. Jinak se může stát, že za několik dnů Vám bude po firmě běhat několik verzí jednoho dokumentu. Vzhledem k tomu, že nasazujeme systém bezpečnosti informací, tak by k takovým situacím nemělo docházet. V rámci implementace jste povinni dokumenty požadované ISMS chránit a řídit. Musí být vytvořen dokumentovaný postup tak, aby vymezil řídící činnosti potřebné ke správě dokumentace. Záznamy musí být vytvořeny a udržovány tak, aby poskytovaly důkaz o shodě s požadavky a o efektivním fungování ISMS. Záznamy musí být chráněny a řízeny. ISMS musí zohlednit všechny příslušné právní nebo regulatorní požadavky a smluvní závazky. Záznamy musí zůstat čitelné, snadno identifikovatelné a musí být možné je snadno vyhledat. Opatření potřebná k identifikaci, uložení, ochraně, vyhledání, době platnosti a uspořádání záznamů musí být dokumentována. Seznam dokumentů, které budeme potřebovat: o Rozsah a hranice ISMS o Politika ISMS o Definice a popis přístupu k hodnocení rizik o Identifikace a ohodnocení aktiv o Identifikace rizik o Analýza rizik
25
o o o o o
Návrh protiopatření Cíle opatření a bezpečnostní opatření pro zvládání rizik (viz příloha A) Akceptace rizik Získání povolení k provozování ISMS v rámci organizace Prohlášení o aplikovatelnosti.
Rozsah a hranice ISMS Dokument, který stanovuje jaké části systému ISMS budou implementovány a popsány. Definuje rozsah a hranice ISMS na základě posouzení specifických rysů činností organizace, jejího uspořádání, struktury, umístění (lokality), aktiv a technologií,včetně důvodů pro vyjmutí z rozsahu ISMS. Politika ISMS Základní a jednoduchý dokument, kterým vedení společnosti deklaruje plnou připravenost a odpovědnost za prosazení cílů při zavádění systému řízení bezpečnosti informací. Tento dokument znamená, že management společnosti si je vědom, co zavedení tohoto systému znamená a je připraven uvolnit personální a finanční prostředky. Definice a popis přístupu k hodnocení rizik Jedná se o dokument, který definuje systematický přístup k hodnocení rizik. Určuje metodiku hodnocení rizik, která vyhovuje ISMS a stanovené bezpečnosti informací, legislativním a regulatorním požadavkům. Metodikou rozumíme podrobný popis celkové činnosti. Je nutné si uvědomit, že na základě tohoto dokumentu, by měl být schopen například auditor provést Analýzu rizik tzn. tento dokument musí být jasný stručný a výstižný. Dále popisuje a určuje kritéria pro akceptaci rizik a pro definování jejich akceptační úrovně, tedy, která rizika budou akceptována. Je důležité mít vždy na mysli, že vybraná metodika hodnocení rizik musí zajistit, aby výsledky hodnocení rizik byly porovnatelné a reprodukovatelné. Identifikace a ohodnocení aktiv Dokument popisující jaká aktiva organizace vlastní, kdo je jejich majitelem a kterých aktiv se bude ohodnocení a identifikace týkat. Dále je zde popsán systém, jakým se provádí ohodnocení aktiv. Nedílnou součástí je konkrétní popis aktiv a jejich ohodnocení, standardně ve formě tabulky. Podrobnosti o hodnocení aktiv, byly zmíněny v předchozích kapitolách. Identifikace rizik Dokument, který může být součástí výše popisovaného dokumentu (např. v menší organizaci). Popisuje výsledky identifikace rizik konkrétního informačního systému. Musí zde být uveden název Informačního systému, odkaz na metodiku pro hodnocení rizik a tabulka s možnými hrozbami a mírou rizika. Analýza rizik Dokument, který může být součástí výše popisovaného dokumentu (např. v menší organizaci). Popisuje principy Analýzy rizik (minimálně algoritmus výpočtu), aktiva, rizika a výsledky Analýzy rizik. Podrobnosti najdete v předchozích dílech seriálu.
26
Návrh protiopatření Dokument popisující „jak minimalizovat zjištěná rizika“. Tento dokument může obsahovat jak konkrétní řešení (například popis konkrétní hardwarové komponenty), tak návrh řešení v obecné rovině (nasazení minimální úrovně zabezpečení). Dále tento dokument zahrnuje tzv. akceptovaná rizika. Podrobnosti viz. předchozí kapitoly. Cíle opatření a bezpečnostní opatření pro zvládání rizik Dokument, který vychází z přílohy A této normy. Musí být vybrány a implementovány vhodné cíle opatření a jednotlivá bezpečnostní opatření a tento výběr musí být zdůvodněn na základě výsledků procesů hodnocení a zvládání rizik. Při výběru musí být zohledněna kritéria pro akceptaci rizik, stejně tak jako legislativní, regulatorní a smluvní požadavky. Cíle opatření a jednotlivá bezpečnostní opatření uvedená v příloze A nejsou vyčerpávající, mohou tedy být vybrány i další cíle opatření a jednotlivá opatření. Příloha A obsahuje ucelený seznam cílů opatření a jednotlivých bezpečnostních opatření, které byly shledány jako obecně použitelné pro všechny typy organizací. Seznam poskytuje uživatelům důležité vodítko pro zajištění toho, aby nebyla opomenuta nebo přehlédnuta žádná z důležitých opatření. Akceptace rizik Dokument popisující ve stručné formě akceptovaná rizika. Vychází z dokumentu Návrh protiopatření, kde je navržena a zdůvodněna akceptace rizika. V tomto dokumentu je akceptace popsána a schválena nebo zamítnuta. Získání povolení k provozování ISMS v rámci organizace Dokument, ve kterém vedení organizace musí deklarovat svoji vůli k ustavení, zavedení, provozu, monitorování, přezkoumání, udržování a zlepšování ISMS. Dokument musí obsahovat: o stanovení cílů ISMS a plánu jejich dosažení, o stanovení rolí, povinností a odpovědnosti v oblasti bezpečnosti informací, o propagaci významu plnění cílů bezpečnosti informací, jejich souladu s politikou bezpečnosti informací, plnění povinností vyplývajících ze zákona a potřebu soustavného zlepšování v rámci organizace, o zajištění dostatečných zdrojů pro ustavení, zavedení, provoz, monitorování, přezkoumání, údržbu a zlepšování ISMS, o stanovení akceptovatelné úrovně rizika, o provádění interních auditů ISMS, o provedení přezkoumání ISMS. Prohlášení o aplikovatelnosti Dokument, který obsahuje dokumentované prohlášení popisující cíle opatření a jednotlivá bezpečnostní opatření, která jsou relevantní a aplikovatelná v rámci ISMS organizace. Dokument „Prohlášení o aplikovatelnosti“ musí obsahovat následující: o cíle opatření a jednotlivá bezpečnostní opatření vybrané a důvody pro jejich výběr,
27
o o
cíle opatření a jednotlivá bezpečnostní opatření, která jsou již v organizaci implementována, vyřazené cíle opatření a jednotlivá vyřazená bezpečnostní opatření uvedená v příloze A, včetně zdůvodnění pro jejich vyřazení.
Prohlášení o aplikovatelnosti poskytuje souhrn rozhodnutí jakým způsobem bude naloženo s identifikovanými riziky. Zdůvodnění pro vyřazení cílů a jednotlivých opatření poskytuje zpětnou kontrolu, zda nebyly vyřazeny omylem.
28
8. ISMS nebo ITIL? V první kapitole této publikace o ISMS byly zmíněny i další důležité normy, které se zabývají bezpečností Informačních systémů. Mezi jinými byla popsána norma ISO/IEC 20000 Informační technologie – management služeb. Druhá důležitá informace byla o knihovně ITIL (Information Technology Infrastructure Library). A právě o těchto možnostech přístupu k bezpečnosti Informačních systémů bude následující díl.
ITIL, ISO 20000 nebo BS 15000? V oblasti řízení a správy poskytovaných služeb IT se poměrně dlouhou dobu hovoří o knihovně nejlepších postupů, známých pod názvem Information Technology Infrastructure Library (ITIL). ITIL vznikl jako sada knižních publikací popisujících způsob řízení IT služeb a ICT infrastruktury. Dnes je zcela samostatným oborem činnosti a podnikání a v druhé verzi zahrnuje knihovnu čítající 8 svazků. V roce 2005 společnost OGC zahajuje projekt „ITIL Refresh“, jehož cílem je vývoj třetí verze knihovny ITIL, která je v roce 2007 vydána. ITIL předkládá sadu osvědčených „Best Practices“ z oblasti řízení služeb ICT, které, jsou-li implementovány, napomáhají dosažení kvality. ITIL je rámec pro design procesů. Mezinárodním standardem, v rámci kterého jsou tyto nejlepší zkušenosti shrnuty do konkrétně popsaných kritérií, je: o ISO/IEC 20000 – 1:2005 Information technology – Service management (Informační technologie – Management služeb – část1: Specifikace) o ISO/IEC 20000 – 2:2005 Information technology – Service management (informační technologie – Management služeb – část2: Soubor postupů) Tato norma historicky vychází z BS 15000 (British Standards) a popisuje implementaci ITSM Za zkratkou ITSM se skrývá IT Service Management neboli Řízení služeb informačních technologií. Obsah ITSM je definován následujícími britskými normami (vydanými British Standard Institute v roce 2000): o BS 15000-1:2002 - IT service management. Specification for service management, o BS 15000-2:2003 - IT service management. Code of practice for service management. Jak je patrno, vedle ISMS existují minimálně další tři možné cesty, jak nasadit bezpečný systém řízení a managementu ICT. Britský systém managementu ICT je poněkud odlišný od našeho středoevropského pojetí, Britové celý systém nejlepších postupů (BS 15000) založili na zkušenostech ze státní správy. Implementace celé knihovny ITIL je běh na velmi dlouhou trať a ten, kdo to myslí vážně, by si měl opatřit alespoň základní literaturu od ITILu.
29
ISO 20000 Stejně jako v případě automobilového průmyslu je specifikace TS 16949 upřesněním a zpřísněním systémových norem, především pak ISO 9001, je norma ISO 20000 podobným dokumentem pro služby ICT a navazuje na normu ISO 27001. Na obrázku vidíte, jakých typických oblastí se tato norma dotýká, a které jsou typické pro řízení a poskytování IT služeb. V předmluvě normy je její účel definován zcela pregnantně: „ISO/IEC 20000 stanovuje požadavky, které jsou kladeny na poskytovatele služeb, a které se týkají dodávky řízených služeb v kvalitě přijatelné pro jeho zákazníky“. Obrázek 4:
Norma ISO 20000 definuje pro tyto procesy jasně daná pravidla. Říká, kde má být dokumentovaný postup, kde je povinný záznam a stanovuje jejich povinný obsah. Právě na otázky hloubky přiměřeného plnění toho či onoho prvku mohou být v rámci implementace podle ISO 27001 často různé názory. Tato norma však řadu kritérií pro tuto oblast činnosti zpřesňuje tím, že v sobě obsahuje rozhodující slovo „MUSÍ“. Mezi nejpodstatnější odlišnosti od normy ISO 27001 patří tzv. povinně řízená dokumentace: o dokumentované politiky a plány managementu služeb o dokumentované dohody o úrovni služeb o dokumentované procesy a postupy požadované normou o záznamy požadované normou
30
Mnohem větší důraz je kladen na monitorování, měření a přezkoumávání. Veškeré tyto činnosti musí být prováděny v pravidelných intervalech, musí být o nich vedeny záznamy a musí být pravidelně vyhodnocovány. Vlastní implementace normy je prováděna podle druhé části normy a v následující tabulce vidíte její náležitosti: Tabulka 2:
Požadavek
Počet kapitol
Požadavky na systém managementu
Poznámka
5
Management systém
10
Service management
2
Planning and impl. New or changing services
Procesy dodávek služby
28
Service delivery
Procesy vztahů
12
Relationship processes
Procesy řešení
17
Resolution process
Řídící procesy
11
Kontrol processes
Proces uvolnění
10
Relase process
Plánování a implementace managementu služeb Plánování a implementace nových služeb
V následujících kapitolách jsou stručně uvedeny povinné části, které je nutné v rámci zavedení normy aplikovat. Požadavky na systém managementu o odpovědnost managementu o požadavky na dokumentaci o odborná způsobilost, vědomí závažnosti, výcvik o profesní rozvoj o uvažované přístupy Materiál: Dokument, který popíše ustavení Systému managementu, popíše jak je nakládáno s dokumentací, jak a kde je popsána odborná způsobilost, výcvik, profesní rozvoj a celkovou personální politiku. Plánování a implementace managementu služeb Součástí plánu managementu služeb by mělo být upřesnění rozsahu managementu služeb. Vedení by mělo stanovit rozsah jako součást svých manažerských odpovědností. Namísto jednoho rozsáhlého plánu může být použito více plánů managementu služeb. Tyto plány musí být součástí veškeré strategie organizace a vrcholové vedení za něj nese plnou odpovědnost.
31
Součástí úspěšné implementace je plán monitoringu, měření a následné analýzy procesů managementu služeb. Výsledky analýz tvoří vstupy do plánu pro zlepšování služeb. Poskytovatelé služeb (ať vnitřní nebo venkovní), by si měli uvědomit, že vždy existují možnosti dodávat služby lépe a efektivněji. Proto norma nařizuje mít politiku zlepšování služeb. Plánování a implementace nových služeb Cílem je zajistit, aby nové služby a změny ve službách byly proveditelné a řiditelné při dohodnutých nákladech a kvalitě poskytovaných služeb. Všechny změny, které se plánují a následně realizují musí být uvedeny v záznamech managementu služeb, což jsou například nábory zaměstnanců, školení uživatelů, komunikace o změnách apod. Procesy dodávky služeb Výsledkem je podrobný dokument popisující všechny kapitoly, především SLM (Service Level Management), systém pro kontinuitu a dostupnost a v neposlední řadě management kapacit. Snad nejdůležitější kapitola, kde jsou popsány vlastní pravidla, podmínky a metriky vázané ke kvalitě poskytovaných služeb. Dále je zde popsána činnost směřující ke kontinuitě poskytovaných služeb v případě výpadku systému, zničení systému apod. Procesy vztahů Podrobné dokumenty popisující vztah služeb poskytovaných IT směrem k primárnímu byznysu a druhý dokument popisující řízení vztahů s dodavateli služeb. Tato kapitola může popisovat principy poskytované tzv. vnitřnímu zákazníkovi (IT oddělení poskytuje například email pro celou firmu), ale lze jej využít i v případě, že organizace nakupuje určité služby venku (outsourcing). Procesy řešení Management incidentů a problémů jsou samostatné procesy, i když jsou spolu úzce provázány. Incident řeší obnovu služeb pro uživatele, zatímco problém se týká identifikace a odstraňování příčin incidentů. Cíle řešení musí být založeny na prioritách. Priority byly stanoveny v rámci analýzy rizik a ohodnocení míry aktiv působící na jednotlivá aktiva organizace. Hlavním cílem je co nejdříve obnovit dohodnuté služby pro byznys nebo reagovat na požadavky na službu. Řídící procesy Dokument popisující celkový systém managementu konfigurací, včetně principu změnového řízení, záznamů, dokumentace a ukončení změn. Management konfigurací by měl být plánován a implementován společně s managementem změn a uvolnění tak, aby bylo zajištěno, že poskytovatel služeb může efektivně spravovat svá IT aktiva a jejich konfigurace. Cílem je aby bylo možné stanovovat a řídit jednotlivé prvky služeb a infrastruktury a udržovat přesné konfigurační informace.
32
Proces uvolnění Pro úspěšnou přípravu a distribuci uvolnění (např. verzi SW) a pro řízení souvisejících dopadů a rizik na byznys a IT je nezbytné přesné plánování a řízení. Do přípravy uvolnění musí být zahrnuta aktualizace veškeré související dokumentace, musí být provedena analýza dopadu na byznys a musí být vzaty v úvahu všechny technické i netechnické aspekty.
Přínosy implementace normy Pro organizaci může implementace normy ISO 20000 znamenat například zefektivnění činnosti při poskytování služeb v oblasti ICT. Následně pak snížení výskytu incidentů, nedostupnosti služeb ICT a snížení finančních ztrát. Na druhou stranu bude celý proces implementace znamenat zvýšenou zátěž pro organizaci a to jak finanční tak personální. Možná proto, není tato norma v České republice ještě tolik rozšířena, jako například IS0 270001.
33
9. ISMS - nejčastější chyby Od přípravy na implementaci ISMS, vlastního nasazení a udržování celého systému řízení informační bezpečnosti společnosti se nyní dostáváme k popisu kritických situací, které mohou nastat jak v období přípravy zavedení systému, tak při jeho samotném zavedení.
Příprava Na začátku každého většího projektu, je vždy nutná podrobná příprava. Plánujete-li implementaci ISMS, zajistěte si nejprve podporu vedení společnosti. Veškeré další činnosti, které bude nutné v rámci implementace realizovat, mohou být velmi zásadní povahy (z hlediska procesů, personálních vazeb a právních úprav) a bez „podpory“ TOP managementu nerealizovatelné. Vůbec problematika lidských a sociálních animozit může znamenat obrovské nebezpečí pro implementaci systému. Půjdete-li představit projekt implementace ISMS, je nezbytně nutné, mít vytvořen celkový koncept nasazení, včetně časového finančního a personálního rozpočtu (nejlépe formou presentace). Neexistence takového plánu, je další častou chybou a důvodem proč není ISMS nasazeno nebo je nasazeno nesprávně. Tedy vhodný výběr členů implementačního týmu, zajištění podpory vedení a perfektně připravený projekt, jsou tři základní pilíře úspěšného nasazení ISMS. Závazek vedení společnosti, kterým se nejvyšší vedení organizace hlásí k podpoře implementace ISMS se jmenuje „Bezpečnostní politika“ a je taxativně vyžadován.
Ohodnocení aktiv Ohodnocení aktiv je vlastně první důležitá činnost spojená s implementací ISMS. Zjednodušeně řečeno, hlavním úkolem je najít všechna aktiva společnosti (vše co má pro organizaci cenu a význam vzhledem k primárnímu obchodnímu zaměření). Tato aktiva musí být pojmenována, musí být nalezen a jednoznačně určen vlastník tohoto aktiva a ohodnoceno (finančně, nebo z pohledu významu pro organizaci). A zde dochází k dalšímu fatálnímu selhávání. Organizace podceňují tuto operaci a neuvědomují si, že ohrožují všechny navazující činnosti, především pak analýzu rizik a dokument „Návrh protiopatření“. Proč se tak děje? Většinou to má dvě příčiny. První je nedostatek času a financí. Podkladem se tak stane nejčastěji seznam serverů, kde jsou například data obchodního charakteru. Hlavní chybou je, že se vůbec nezmapuje, kde všude se důležitá data organizace nacházejí, nejsou popsány vazby mezi nimi. Málokdy si totiž odpovědní pracovníci uvědomí, že data nejsou pouze např. v SQL databázi, ale že se tato data sdílejí a agregují v mnoha dalších systémech, zařízeních apod. Druhá příčina neznalost dané problematiky. Výsledkem je zavádějící seznam aktiv, téměř vždy bez jednoznačně definovaných majitelů. Myslí-li organizace implementaci systému řízení bezpečnosti vážně, je v takovém případě
34
vždy vhodnější (a v neposlední řadě i levnější) najmout firmu, která má pracovníky k této činnosti vyškolené.
Analýza rizik Analýza je činnost přímo navazující na ohodnocení aktiv. Od Analýzy rizik se vlastně odvíjí veškeré další kroky při implementaci ISMS. Je třeba si uvědomit, že tato analýza není žádnou kontrolou správců a majitelů aktiv společnosti. To je největší omyl. Jsou-li Analýzou rizik pověření pracovníci, kteří mají pocit, že za odhalený nesoulad budou potrestáni, je lepší implementaci ukončit. Takový člověk začne manipulovat s výsledky analýzy a tudíž následné činnosti (především dokument „Návrh protiopatření“) jsou zbytečné. Správnou volbou je, aby Analýzou rizik byl pověřen pracovník, který nemá žádnou spojitost s poskytovatelem IS/IT služeb ve společnosti. Bohužel ve své praxi se často setkávám s názorem, že nejvhodnější oddělení, které by mělo implementovat ISMS je právě odbor IS/IT. Má-li organizace zaveden například systém řízení kvality podle normy ISO 9001, je právě její správce tím vhodným garantem. Není-li vhodný pracovník v organizaci, je nejlepší variantou opět využít služeb externích subjektů.
Návrh protiopatření Mohlo by se zdát, že je to jen dokument, který popisuje, kde má organizace bezpečnostní problémy. Opak je pravdou. Tento dokument vlastně popisuje celkový rozvoj implementace a řízení bezpečnosti do budoucna. Jedná se o stejný dokument (svým významem a dopadem), jako má organizace z pohledu obchodu. Hlavní rizikem se může stát, že tento dokument nebude řádně zpracován na základě analýzy rizik. Jsou-li zkresleny výsledky analýzy rizik nebo nesprávně interpretovány, je dokument Návrh protiopatření zbytečný. Často se stává, že tento dokument je pouhým výčtem obecných návrhů. Přitom tento dokument musí být podrobný a obsáhlý. Jak jsme již několikrát napsali, dokument se stává (po svém schválení) strategickým rozhodnutím a cestou rozvoje informační bezpečnosti v organizaci.
Plány obnovy kritických aktiv společnosti Jsou organizace, které mají zpracován plán obnovy kritických aktiv společnosti (nejčastěji obchodní a komunikační systémy společnosti). Většina společností, však považuje tyto „plány obnovy“ za zbytečné a argumentují: „nám se to prostě stát nemůže“. V konečném důsledku vůbec nemusí jít o žádnou tragickou událost (požár, povodeň), stačí, když selže technika nebo lidský faktor (virus, krádež, havárie technologií). Základní plán obnovy přitom není žádným složitým systémem. Jde o to, mít popsaný a hlavně funkční systém záloh. Ověřené obnovení dat a činnosti. Málokdo si uvědomuje, že obnovení například datových záloh, znamená v případě zničení techniky značný (především logistický) problém. Proto dokument „plány obnovy kritických aktiv společnosti“ nesmí být jen mrtvým dokumentem. Musí být neustále prověřován, aktualizován a testován. Zlaté pravidlo informační bezpečnosti říká, že prověření musí být provedeno jedenkrát za 12 měsíců a při jakékoliv změně například Informačního systému.
35
Nedílnou součást plánů obnovy je tzv. dokument Business Continuity Planning. Tedy strukturovaný souhrn toho, co je pro organizaci podstatné, aby byl zachován primární obchodní režim. Teprve tyto dva plně funkční (ne jen na papíře) systémy zaručí, že organizace může vykonávat svoji obchodní činnost ( a ekonomicky přežít) i v případě fatální havárie kritických aktiv společnosti.
Plán bezpečnosti IT Jedná se o dokument, který popisuje, jak budou chráněna aktiva na úrovni poskytovatele IS/IT služeb. Mohlo by se zdát, že v tomto případě žádný problém nehrozí. Opak je pravdou. Bohužel většina pracovníků IS/IT oddělení chápe zavedení systému ISMS jako ohrožení vlastní existence. Proto zde znovu hrozí riziko (již popsané výše), že tyto strategické dokumenty budou nepřesné, v horším případě zavádějící. Cestou, jak toto hrozící riziko minimalizovat je například diskuse s pracovníky IS/IT oddělení. Je-li situace i nadále neprůchodná, doporučuji najmout externí společnost, která takové dokumenty vypracuje a implementuje. Realita je ovšem taková, že v mnoha organizacích není IS/IT oddělení bráno jako podstatný prvek a podpora primárního obchodního cíle, ale jako „druhořadé oddělení spravující servery a vyměňující tonery v tiskárně“. Tento věčný souboj mezi „ajtíky“ a zbytkem společnosti přináší bohužel, více problémů, než klidný a kontinuální rozvoj bezpečnosti.
36
10.
ISMS – Business Impact Analysis
I v této kapitole si povíme o nejčastějších chybách při zavádění systému řízení bezpečnosti informací – ISMS.
Business Impact Analysis Činnost, která je opředena mnoha tajemstvími. O co vlastně jde? Má-li organizace hotovou základní analýzu rizik a dokument návrh protiopatření, musí být vytvořeny tzv. plány obnovy (viz.předchozí díl). Nezbytnou součástí těchto plánů jsou tzv. plány obnovy záloh (Recovery Plan) a plány obnovy podnikání (Business Continuing Planning). V této fázi vzniká zásadní chyba, která může mít za následek dva fatální problémy. Prvním je, že vlastníci aktiv požadují obnovení činnosti svého aktiva okamžitě po výpadku. Druhým, že díky náročnosti (finanční a personální) takového požadavku se stává celý plán obnovy jen cárem papíru, který nebere nikdo vážně. Výsledek je lehce predikovatelný. Dojde-li k vážnému výpadku kritického aktiva, není toto obnoveno a organizaci tak může vzniknout závažný existenční problém. Pojistkou je právě Business Impact Analýza, tedy analýza obchodních dopadů v případě nedostupnosti kritického aktiva. Tato situace nastává v mnoha organizacích, které se rozhodli implementovat ISMS a to jako následek nesprávně provedené analýzy rizik. Máme-li tedy na základě analýz rizik vydefinovány kritické systémy, musí být provedeny rozhovory s vlastníky těchto aktiv. Hlavní otázky zní: Jak dlouho může být aktivum nedostupné? Jaké finanční ztráty nedostupnost aktiva znamená pro organizaci? Představme si aktivum XYZ, což je v našem případě základní Informační systém pro podporu obchodu, obsahuje veškeré informace o zákaznících, probíhajících zakázkách, včetně predikce zakázek budoucích. Je přímo navázán na systémy účtárny a na systém skladového hospodářství. Když se zeptáte majitele aktiva, jak dlouho může být systém nedostupný, dozvíme se, že maximálně hodinu. Co znamená jedna hodina? Znamená to tolik, že organizace nemůže mít standardní plán obnovy s připravenými zálohami. Tento požadavek vyžaduje mít on-line připojené záložní centrum, které je nejlépe připojeno optickým kabelem k primární databázi a ta je v reálném čase replikována. Je-li organizace takto vybavena, není problém do 60 minut obnovit činnost takového aktiva. A nyní obraťme list. Pokusme si spočítat, kolik bude organizaci stát, udržovat toto pracoviště buď vlastními silami nebo formou outsourcingu. Letmým výpočtem pronájmu optického vlákna, prostor, techniky a lidských kapacit zjistíme, že takový požadavek bude znamenat zvýšení nákladů o stovky tisíc korun měsíčně. Předložíme-li managementu organizace požadavek na zajištění bezpečnosti formou této fantastické sumy, bude nás čekat více, či méně taktní dotaz na naše psychické zdraví. Celá implementace ISMS je ukončena a výsledkem je zhoršení celkového stavu informační bezpečnosti v organizaci.
37
Je-li však rozhovor s majitelem aktiva proveden v souladu s požadavky organizace, lze přesně identifikovat a stanovit míru mezi požadavky majitele aktiva, požadavky organizace z hlediska dostupnosti a financí. Je tedy více než žádoucí vydefinovat následující informace: Tabulka 3: Finanční vyjádření ztrát způsobených nedostupností aktiva
Doba přerušení
Popis následků
Finanční vyjádření ztrát
1 hodina
Obchod může pokračovat
0
Obchod může pokračovat s drobnými výpadky Obchod může pokračovat, nelze uzavírat nové zakázky
1 den 3 dny Týden
Obchodování se zastaví
10.000 Kč 70.000 Kč 300.000 Kč
Z této tabulky tedy jasně vyplývá, že požadavek na zprovoznění aktiva XYZ do 60 minut po výpadku je zcela neopodstatněné. Vedle této tabulky je vhodné vytvořit tabulku druhou, která bude vyjadřovat finanční náklady na obnovení aktiva XYZ v definovaných lhůtách: Tabulka 4:.Finanční vyjádření nákladů na obnovení aktiva
Doba obnovení
Finanční vyjádření nákladů
1 hodina
100.000 Kč
1 den
50.000 Kč
3 dny
10.000 Kč
Týden
5.000 Kč
Je zcela patrné, že porovnáme-li tyto dvě tabulky, dojdeme k následujícímu závěru, že aktivum XYZ je nejvhodnější obnovit během 48 hodin, kdy definované ztráty mohou dosáhnout 10.000 Kč a náklady mohou vystoupat k 50.000 Kč. Zcela srozumitelný bude tento příklad z přiloženého grafu: Graf 1: Finanční vyjádření ztrát a nákladů
38
Samozřejmě, naprosto jiný režim bude například pro finanční instituci veřejné banky s tisíci klienty nebo ve výrobní organizaci s nepřerušovaným provozem. Ale takové organizace si mohou dovolit i poměrně vysoké náklady na udržení kritických systémů v režimu 7/24/365. Dále je třeba vzít v úvahu návaznost jednotlivých aktiv na aktiva další. V případě zásadní návaznosti mohou být ztráty z nedostupnosti aktiva násobeny nedostupností aktiva dalšího. Ale takové případy nenastávají příliš často. Tento díl zaměřil pozornost na opomíjenou činnost v rámci zaváděni ISMS. Činnost, která v důsledku může ušetřit organizaci nemalé personální a finanční náklady. Ve všech odborných publikacích, které se zabývají řízením informační bezpečnosti ve společnosti, najdete popsanou analýzu rizik. Vždy je zdůrazňováno, že se jedná o nejpodstatnější část celé implementace. Bohužel v málokteré literatuře se lze dopátrat, jak by taková analýza měla vypadat a na co by si měli pracovníci provádějící Analýzu rizik dát pozor. V naší publikaci jsme tuto problematiku rozvedli do maximální možné hloubky a byly zde popsány všechny důležité činnosti a zároveň i nejčastější chyby, omyly a mýty.
39
11.
ISMS – školení
V závěrečné kapitole si povíme něco málo o tom, proč uživatele IT školit, jaká forma školení je vhodná a v jakých časových intervalech školení provádět.
Proč uživatele školit? Na tuto otázku existuje celá řada odpovědí. Povinnost pravidelného školení vyplývá přímo z normy, která nařizuje pravidelné opakování školení (v případě, že je ISMS ve společnosti certifikován) v bodě 8.2.2. Opatření přímo říká: „Všichni zaměstnanci organizace, a je-li to důležité i pracovníci smluvních a třetích stran musí, s ohledem na svou pracovní náplň absolvovat odpovídající a pravidelně se opakující školení v oblasti bezpečnosti informací, bezpečnostní politiky organizace jejich směrnic.“ Co v případě, že organizace má ISMS pravidla implementována, ale není certifikována? Opět jednoduchá odpověď. I když organizaci vlastně nic nenutí provádět pravidelná školení, je jasné, že pokud nejsou dodržována tato základní pravidla, není celý systém řízení bezpečnosti informací vůbec funkční. Otřepané pravidlo říká, že jedině proškoleného uživatele je možno kontrolovat a upozornit ho na chyby. Samozřejmě správně poučený uživatel znamená mnohem menší riziko pro Váš Informační systém. Podle různých statistik patří bezpečnostním incidentům způsobených neznalostí uživatele první příčky. Nejčastěji se jedná o ukradené notebooky uložené v automobilech, otevření přílohy elektronické pošty s neznámým obsahem, případně instalace neschváleného SW (hry, aplikace) nebo hardware (fotoaparáty, flash disky, apod.).
Jak uživatele školit? Většina organizací má dnes vytvořen systém pravidelného vzdělávání svých zaměstnanců. Některá školení jsou taxativně nařízena (ochrana zdraví při práci, referentské zkoušku řidičů automobilů apod.). Je-li v organizaci implementováno ISO 9001 – kvalita práce (dnes je skoro všude), je velmi snadné, přidat k pravidelným školením této normy i školení na bezpečnost informací. V předchozích dílech bylo popsáno, že jedním ze základních dokumentů ISMS jsou tzv. „Minimální bezpečnostní pravidla pro uživatele“. Tedy základní návod, jak se má uživatel chovat při práci s výpočetní technikou a při práci s Informačními systémy. Veškerá základní školení by měla tedy logicky vycházet z tohoto dokumentu. Je vhodné dodržet při školení tyto základní body: o krátké vysvětlení co ISMS je a jaký je jeho přínos pro organizaci o ujasnění odborných pojmů (informační bezpečnost, aktivum, analýza rizik) o aktuální stav bezpečnostní politiky organizace o dokument „Minimální bezpečnostní pravidla pro uživatele“
40
o o
zdůraznění změn oproti předchozímu školení ověření znalostí uživatelů, například formou testu
Školení je vhodné rozvrhnout minimálně do dvou hodin. Doporučuje se forma názorných příkladů a případů bezpečnostních incidentů. Běžné uživatele IT není možné zahrnout technickými podrobnostmi. Taková školení jsou vhodná pro Administrátory, případně ostatní technický personál. Tip: Několik dní po školení na bezpečnost informací proveďte namátkový interní audit. Uživatelé, kteří nenaplní požadavky auditorů, musí školení absolvovat znovu. Nedoporučuje se masové školení v počtu desítek uživatelů. Vhodný počet je do 15 pracovníků. V takové situaci je možno věnovat se řešení různých individuálních problémů, případně se vrátit ke složitějším souvislostem.
Kdy uživatele školit? Ti z Vás, kteří již četli ISMS normu odpověď znají. Uživatelé by měli být proškoleni minimálně před vznikem pracovního poměru a v průběhu pracovního poměru. Tip: Doporučuje se také provést individuální proškolení uživatele při ukončení pracovního poměru. Především z důvodu připomenutí závazku mlčenlivosti apod. Před vznikem pracovního poměru je důležité, aby zaměstnanci a především pracovníci smluvních a třetích stran byli srozuměni se svými povinnostmi a právy. Bude-li mít pracovník například přístup ke klasifikovaným dokumentům, musí být proškolen i na tuto problematiku. Pracovníci jsou tak zároveň seznámeni s bezpečnostními pravidly a s odpovědností za jejich dodržování. Tip: Při nástupu do zaměstnání jsou taxativně nařízena školení v oblasti BOZP apod., je vhodné v rámci těchto školení provést i základní náhled do problematiky ISMS. V průběhu pracovního poměru je vhodné provádět školení pravidelně. V prvním cyklu zavádění ISMS (první cyklus PDCA) se doporučuje školit nejméně jedenkrát za šest měsíců. Je-li systém bezpečnosti již zaveden a „usazen“, lze přejít na roční cyklus. Tip: Jsou-li všichni zaměstnanci proškoleni na základní bezpečnostní pravidla, je vhodné zavést pokročilá školení. Především pro administrátory a obslužný personál. Dále pak pro vysoce odborné uživatele – superuživatele. Školení pro administrátory je vhodné pojmout technicky, zvláště v případě, kdy organizace využívá složité a sofistikované technologické komponenty. Speciální školení pro superuživatele je důležité, neboť velmi často mají nadstandardní přístup do informačních systémů a jejich omyl může mít pro organizaci fatální důsledky. Jiná školení Výše byla popsána standardní školení, která jsou plánována v časovém předstihu a pravidelně. Je-li však v mezidobí, mezi pravidelnými školeními provedena zásadní změna v informačním systému, je nutné všechny uživatele upozornit a provést nové školení. Není
41
třeba procházet celou náplň, ale soustředit se jen na nové funkčnosti systému a nová rizika z nich vyplývající.
42
Doslov Vážení čtenáři, právě jste dočetli publikaci věnovanou problematice nasazování a řízení bezpečnosti informací. Snažili jsme se vyhnout suché teorii a vytvořit praktického průvodce s konkrétními příklady z praxe. Nemyslíme si, že přečtením se z vás stanou odborníci na danou problematiku, ale minimálně budete schopni orientovat se v dané oblasti. Využijete-li tyto podklady k nasazení systému řízení bezpečnosti, nebo se rozhodnete vybrat si jen určité části, budeme rádi. Přejeme vám hodně úspěchů a funkční a bezpečný systém ochrany vašich informací.
43
