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. 4.
BEZPEČNOSTNÍ POLITIKA, ANALÝZA RIZIK ............................................................23 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í Schválení strategie/plánu pro bezpečnost
Střední organizace do 150 zaměstnanců, 3-5 úrovní vedení Schválení celkové koncepce bezpečnosti Schválení projektu bezpečnosti
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
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ů
Plán / projekt bezpečnosti
Bezpečnostní politika
Organizace bezpečnosti P L A N
17
Velká organizace nad 150 zaměstnanců, 4 a více úrovní vedení Schválení celkové koncepce bezpečnosti Vymezení rozsahu projektu + odhad zdrojů a harmonogramu Schválení projektu bezpečnosti Analýza stavu bezpečnosti 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 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
Analýza rizik
Výběr opatření a plán implementace
Prohlášení o aplikovatelnosti
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
Protiopatření vyplývají z AR Prosazuje: ředitel firmy
Protiopatření vyplývají z AR Prosazuje: ředitel a vedoucí oddělení společně
Dokumentované rozhodnutí, samostatný dokument pouze v případ certifikace
Dokumentované rozhodnutí, samostatný dokument pouze v případ certifikace
Protiopatření vyplývají z AR Prosazuje: podle významu protiopatření od vedení společnosti po vedoucí oddělení 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
D O
Způsob implementace opatření
Malá organizace do 15 zaměstnanců 1-2 úrovně vedení Okamžitě, rychle, efektivně, bez zbytečné administrativy
Metody prosazení bezpečnosti
Direktivní – Osobní Neformální Stručné pokyny (email, Intranet) a verbální působení na všechny zaměstnance
Bezpečnostní dokumentace
Bezpečnostní politika, některé směrnice, občas konkrétní postupy
Program zvyšování bezpečnostního povědomí
Jednorázové informace dle potřeby. Bezpečnostní minimum součástí úvodního zaškolení.
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.
Střední organizace do 150 zaměstnanců 3-5 úrovní vedení Podle významu protiopatření formou projektů nebo direktivním nařízením 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
Velká organizace nad 150 zaměstnanců 4 a více úrovní vedení Formou projektů
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
Nepravidelné pokyny a nařízení Bezpečnostní minimum součástí úvodního zaškolení. Specializovaná školení pro vybrané zaměstnance. Formální proces s rámcově stanoveným postupem a odpovědnostmi. Revize zvládání rizik nepravidelná, dle potřeby.
Strukturovaný kontinuální vzdělávací program. Pravidelná specializovaná školení všech zaměstnanců.
21
Direktivní – Neosobní – Důsledně formální Písemné organizační pokyny Závazné a formální seznámení s nařízeními
Formálně řízený proces s předem stanovenými postupy a pravomocemi. Pravidelné analýzy a kontroly zvládání rizik.
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
Monitoring IS a testování funkčnosti opatření
C H E C K
Audit a kontrola bezpečnostních opatření
Revize adekvátnosti a efektivnosti ISMS
Malá organizace do 15 zaměstnanců, 1-2 úrovně vedení 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.
Střední organizace do 150 zaměstnanců, 3-5 úrovní vedení 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).
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í.
Velká organizace nad 150 zaměstnanců, 4 a více úrovní vedení 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. 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.
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
3.1.4 plan, do, check, ACT
Vyhodnocení fáze CHECK Základním předpokladem pro správné rozhodnutí „co a jak dál“ by vždy měly být co nejpřesnější a nejúplnější informace o aktuálním stavu a cílech organizace. Informace o aktuálním stavu týkající se monitoringu provozu, evidence chyb a bezpečnostních incidentů, výsledků testování funkčnosti a spolehlivosti implementovaných opatření, výsledků testování zranitelností a výsledky interních i externích auditů poskytuje předcházející fáze Kontroluj (CHECK). Vyhodnocení těchto informací provádí v malých firmách pracovník pověřený činností bezpečnostního managera (jako přidruženou činnost ke své pracovní náplni). Výsledky svého šetření by měl minimálně jednou ročně předložit majiteli, případně řediteli organizace a společně provést jejich analýzu a vyhodnocení. U středních a velkých organizací se již vyplatí přidat do tohoto kroku také revizi návrhů a možných zlepšení bezpečnosti informací i procesu ISMS, jejichž evidenci zajišťuje fórum pro bezpečnost informací, složené ze zástupců uživatelů, dodavatelů a odborných rolí delegovaných pro oblast bezpečnosti informací v organizaci. V rámci procesu řízení rizik je prováděno také pravidelné přehodnocování úrovně zbytkových a přenesených rizik, s ohledem na změny v organizaci, technologiích, podnikatelských cílech a vnějších událostech a hrozbách.
Identifikace a analýza neshod I když byla revize výsledků auditu zahrnuta již do předcházejícího kroku, je vhodné tuto činnost popsat podrobněji. Identifikace a analýza neshod má za úkol rozebrat výsledky interního i případného externího auditu a posoudit, které z nalezených neshod jsou skutečné, které pouze potenciální a vyřadit nesprávně identifikované neshody. Toto rozhodnutí je opět vhodné zaevidovat formou tabulky. Nakonec je pro odstranění skutečně identifikovaných neshod třeba navrhnout nápravná opatření a pro zabránění opakovaného výskytu skutečných i potencionálních neshod v budoucnu je třeba navrhnout preventivní opatření. Jejich výběr, implementace a ověření funkčnosti je již náplní dalších paralelních PDCA procesů (koleček), které jsou spuštěny pro každé nově navržené opatření. U malých organizací provede tuto analýzu neshod majitel, případně ředitel organizace, ve spolupráci s pracovníkem pověřeným funkcí bezpečnostního managera. S výsledným rozhodnutím je vhodné seznámit všechny zaměstnance. Implementace těchto rozhodnutí bývá velmi rychlá a flexibilní. Pokud malá firma usiluje o certifikaci ISMS, je vhodné obrátit se pro pomoc na externího konzultanta, případně zrealizovat srovnávací audit procesu ISMS vzhledem k ISO 27001 externí specializovanou firmou a s její pomocí navrhnout potřebná nápravná opatření pro dosažení souladu. U středních firem bude interpretace výsledků auditů i návrh nápravných a preventivních opatření komplikovanější a formální proces, řízený pracovníky interního auditu ve spolupráci s dalšími zainteresovanými odbornými pracovníky organizace. Při přípravě na certifikaci ISMS se i zde doporučuje sáhnout pro pomoc externích odborníků, pokud takoví nejsou ve vlastních řadách.
25
Nápravná a preventivní opatření Nápravná opatření slouží k odstranění skutečně nalezených nedostatků a chyb, spojených s implementací a provozem ISMS a k zabránění jejich dalšímu trvání (opakování). Jedná se například o neúplnou implementaci opatření zvolených v Prohlášení o aplikovatelnosti opatření, o chybějící dokumentaci těchto opatření, o nedostatečné proškolení pracovníků zainteresovaných v procesu ISMS apod. Preventivní opatření jsou vybírána s cílem zabránit výskytu potencionálních neshod v budoucnu, tedy za účelem eliminace příčin, které by mohly vést ke vzniku reálné nežádoucí situace a reálné neshody. Příkladem takové potencionální neshody může být například nedodržení oddělení rolí u některých činností a opatření ISMS nebo nedůsledné provádění potřebných monitorovacích a kontrolních činností. Pro malé organizace je typická rychlá praktická změna bez byrokratických průtahů a příklon především k organizačním a personálním opatřením, jejichž „pořízení a zavedení“ bývá pro majitele malých firem nejpřijatelnější. Pro střední organizace, stejně jako ve fázi DO (popis nároků na provoz opatření), není již hledisko nákladů na pořízení a zavedení opatření tak palčivé jako pro malé organizace a bude při jejich výběru více rozhodovat jeho účinnost a pokrytí nalezených nedostatků.
Proces
A C T
Vyhodnocení fáze Kontroluj
Identifikace a analýza neshod
Malá organizace do 15 zaměstnanců 1-2 úrovně vedení Revize zejména bezpečnostních incidentů, chyb a průběhu jejich řešení (dle potřeby). Revize penetračního a zkušebního testování, pokud bylo realizováno. Revize výsledků ročního auditu.
Střední organizace do 150 zaměstnanců 3-5 úrovní vedení Pravidelná revize incidentů, chyb a průběhu jejich řešení. Revize penetračních a dalších typů testů. Revize výsledků auditu. Revize nápadů a podnětů ke zlepšení. Revize adekvátnosti a efektivnosti ISMS.
Identifikace a evidence možností zlepšování, reálných neshod a potenciálních problémů. Interpretace a okamžitý návrh opatření ředitelem / majitelem.
Identifikace a evidence možností zlepšování, reálných neshod a potenciálních problémů. Interpretace výsledků kontrol interním auditem s využitím externích odborníků. Jednoduchý projekt pro návrh opatření.
26
Velká organizace nad 150 zaměstnanců 4 a více úrovní vedení Proces průběžné revize výsledků monitoringu provozu, IDS systémů, incidentů, chyb a průběhu jejich řešení. Revize penetračních testů a technických auditů konfigurace systémů. Revize nápadů a podnětů ke zlepšení. Revize adekvátnosti a efektivnosti ISMS. Identifikace a řízená evidence možností zlepšování, neshod a potenciálních problémů. Vícestupňový proces analýzy neshod bezp. auditem a jejich interpretace bezp. ředitelem. Kompletní projekt pro návrh a testování opatŘení
Nápravná a preventivní opatření
Přednostní výběr jednoduchých organizačních a personálních opatření, bez nutnosti investic. Rychlé zavedení dostupných opatření do praxe.
Výběr organizačních opatření podpořených technologiemi a nástroji. Testování opatření před uvedením do praxe. Aktualizace bezpečnostní dokumentace.
Výběr a implementace opatření formou projektu Primárně výběr robustních a automatizovaných opatření s podrobným testování a sledováním účinnosti a přizpůsobení organizaci. Řízená aktualizace bezpečnostní dokumentace
3.2 Bezpečnostní politika, analýza rizik Bezpečnostní politika je soubor pravidel, která specifikují účinný způsob uplatňování bezpečnostních opatření, potřebný pro dosažení požadované minimální úrovně bezpečnostních rizik. Bezpečnostní politika specifikuje co se chrání a proti čemu (definuje aktiva a bezpečnostní cíle) a určuje také způsob této ochrany (popisuje mechanismy, kterými dosáhneme požadovaných bezpečnostních cílů). Bezpečnostní politiku lze také popsat jako cyklický proces sestávající z následujících kroků posouzení vstupních vlivů analýza rizik vypracování projektu bezpečnostní politiky a její implementace test v „reálném provozu“ organizace posouzení dopadů a adekvátnosti bezpečnostní politiky analýza rizik … Model PDCA tuto strukturu rozmělňuje – nespadá pouze pod krok „Bezpečnostní politika“, ale v zásadě tento cyklus provádí také. Politika je něco jako programový dokument. Neobsahuje do detailu rozpracované způsoby a prostředky (ty se časem a vývojem mohou měnit), ale cíle a důvody. Proto je tím příhodným dokumentem, vhodným ke schválení vrcholovým vedením organizace. Jak by konkrétně měla taková politika vypadat? Podle doporučení ISO/IEC 17799 se v bezpečnostní politice definují cíle organizace při zajištění bezpečnosti informací v následujících základních oblastech: Organizace bezpečnosti - definování vhodných organizačních a řídících struktur, rolí a odpovědností pracovníků organizace. Klasifikace a kontrola aktiv – provedení inventury a klasifikace toho, co vlastně bude předmětem ochrany. Personální bezpečnost - definování cílů v oblasti zajištění a zvyšování bezpečnostního povědomí pracovníků. Fyzická bezpečnost - cíle v oblasti předcházení neautorizovaného přístupu do citlivých prostor a k citlivým informacím či prostředkům organizace.
27
-
Řízení provozu - zajištění správného a bezpečného provozu prostředků IT/IS Řízení přístupu - zajištění takového přístupu k informacím organizace, který odpovídá podnikatelským záměrům. Vývoj a údržba systému – stanovení bezpečnostních pravidel pro údržbu a zejména další rozvoj systému. Řízení kontinuity - minimalizace výpadků a škod způsobených bezpečnostními incidenty Soulad s požadavky – zajištění dodržování právních norem, smluvních a bezpečnostních požadavků.
Graficky znázorněno může schéma bezpečnostní politiky vypadat například takto.
BEZPEČNOSTNÍ POLITIKA ORGANIZACE BEZPEČNOSTI
ŘÍZENÍ PŘÍSTUPU
SPRÁVA KLASIFIKACE VÝVOJ A ŘÍZENÍ KONTINUITY PERSONÁLNÍ KOMUNIKACÍ A KONTROLA ÚDRŽBA PODNIKATELSKÝCH BEZPEČNOST A ŘÍZENÍ AKTIV SYSTÉMŮ ČINNOSTÍ PROVOZU
FYZICKÁ BEZPEČNOST A BEZPEČNOST PROSTŘEDÍ SOULAD S POŽADAVKY
Klíčovou součástí ISMS a PDCA je analýza rizik. Norma ISO 17799 specifikuje čtyři přístupy k provedení analýzy rizik: neformální analýza rizik není založena na formální metodologiích, není použito standardních strukturovaných metod, většinou založeno na zkušenostech jednotlivců základní analýza rizik postup dle všeobecných standardů či dle analogie s podobným systémem, minimum zdrojů detailní analýza rizik použití standardních strukturovaných metod (viz dále), finančně i časově nejnáročnější kombinovaná analýza rizik kombinované použití předcházejících metod dle potřeby (vliv mají i ekonomická hlediska), patrně nejčastěji volená metoda
28
Pokud přistoupíme k detailní analýze rizik, projdeme všechny následující kroky. U ostatních přístupů není aplikace všech následujících bodů pravidlem. Postup při analýze rizik: identifikace aktiv a stanovení jejich hodnot identifikace hrozeb pro aktiva 4 kroky označované jako identifikace zranitelných míst aktiv Risk Assessment, odhad rizik odhad rizik, resp. pravděpodobností útoků odhad očekávaných ztrát (zpravidla ročních) vypracování přehledu ochranných opatření a jejich ceny odhad úspor po aplikaci těchto opatření a stanovení přijatelných rizik Existuje ale také jiný pohled na typy analýzy rizik. Pojďme si nastínit výhody a nevýhody přístupů definovaných podle toho, kdo analýzu provádí, kdo je za ni odpovědný apod. Podle těchto kritérií lze rozdělit přístupy na: dodavatelský přístup projekt analýzy rizik provádí dodavatel a nese za něj také odpovědnost vlastní přístup projekt analýzy provádí pracovníci organizace vlastními silami s pomocí zakoupené nebo vlastní metodiky, odpovědnost za provedení je na těchto pracovnících partnerský přístup projekt analýzy provádí pracovníci organizace pod metodickým i projektovým vedením dodavatelské nebo konzultační společnosti, odpovědnost je na dodavateli (konzultantovi)
Hranice mezi přístupy, které jsou dány zejména odpovědností za provedení analýzy, mohou být u dodavatelského a partnerského přístupu těžko rozeznatelné. I u dodavatelského přístupu je spolupráce mezi organizací a dodavatelem poměrně intenzivní. Hlavní rozdíl je v celkovém pohledu na bezpečnost. U partnerského přístupu se organizace sama učí, jak zabezpečit svoje informace. V druhém případě spoléhá ve výhledu do budoucnosti ve všem na dodavatele a jím dodané (popř. outsourcované) produkty či služby. Dodavatelské a vlastní přístupy jsou známé a běžně používané. Partnerská varianta není tolik obvyklá, i když podle mého názoru je pro celou řadu organizací bez ohledu na jejich velikost optimálním řešením. Jednotlivé přístupy mají své nesporné výhody – přínos do budoucna, vyškolení vlastních pracovníků, přenos odpovědnosti na dodavatele, ale i nevýhody – cena, nejisté výstupy, nesystémové provádění ad-hoc. V následujících odstavcích jsou všechny tři přístupy podrobně popsány.
Dodavatelský přístup Management organizace stále úzce spojuje bezpečnost informací s technologiemi a není tedy nic jednoduššího, než zadat odpovědnému řediteli úkol, aby vypsal výběrové řízení na dodavatele takového projektu. Pokud je však vybrán dostatečně kompetentní dodavatel, je tento přístup optimální pro organizaci, která nemá k dispozici dostatečné know-how mezi vlastními pracovníky
29
nebo je nechce projektem vůbec zatěžovat. Určitá spolupráce zaměstnanců s dodavatelem projektu je však nezbytná. Zejména úvodní činnosti týkající se popisu systému a tvorby modelů aktiv se neobejdou bez aktivní spolupráce. Bezpodmínečně nutná je spolupráce při hodnocení aktiv, hrozeb a zranitelností. Zde analytik klade otázky, na které znají odpověď pouze pracovníci dané společnosti. V intenzitě spolupráce mohou být dodavatelský a partnerský přístup téměř adekvátní. Hlavní rozdíl je ale ve zpracování výstupů a prezentace výsledků analýzy. Výhodou dodavatelského přístupu je minimální zátěž pracovníků společnosti, protože kromě rozhovorů popřípadě vyplňování dotazníků dělá vše ostatní dodavatel projektu. Společnost tedy nepotřebuje nikoho, kdo ví, jak provádět analýzu rizik. Nemusí kupovat a studovat metodiky a hlavně nikdo z jejích pracovníků nemá odpovědnost za provedení analýzy. Zároveň však na konci projektu s posledním odborníkem od dodavatele odejde i know-how a vytvořené výstupy, se mohou stát nesrozumitelné. Výstupy by v každém případě měly mít vždy dvě formy: pro management stručné zprávy pro konkrétní pracovníky odpovědné za bezpečnost podrobné reporty včetně tabulek a dalších příloh
Vlastní přístup Mnoho společností, které disponují vlastními odborníky, řeší bezpečnost informací svými silami. Jedná se o optimální řešení, pokud je k dispozici potřebné know-how podporované metodickými postupy či nástroji. V takovém případě provádějí analýzu rizik odborníci z vlastních řad, kteří kromě toho, že rozumí problematice, také znají informační systém organizace. Navíc je ze všech tří přístupů tento nejvíce nákladově efektivní. Bez vlastních odborníků vede volba tohoto přístupu k jasné zkáze. Neexistuje horší varianta, než když se koupí metodika nebo software na provedení analýzy rizik a vyškolí se jeden z pracovníku oddělení IT. Ten dostane kromě svých každodenních povinností za úkol provést postupně detailní analýzu všech částí informačního systému včetně zpracování výstupů pro management či auditora. Takový přístup lze shrnout dvěma slovy: všechno špatně. Během provádění detailní analýzy se (ne)zkušenost analytiků projeví zejména při rozhovorech s respondenty týkajících se zjišťování hodnoty informačních aktiv. Při takovém rozhovoru musí mít analytik nejen znalosti o daném systému a bezpečnosti obecně, ale musí být také trochu psychologem. Hodnotu informací lze vždy spolehlivě určit až tehdy, pokud se s nimi doopravdy něco negativního stane. Bez takové zkušenosti je pro respondenty velmi těžké si představit, jaký vliv bude mít například týdenní nedostupnost celého účetnictví. Zkušenost je při provádění těchto činností velmi cenná a nesprávná interpretace vstupů může významně znehodnotit závěry celé analýzy. Jistou nevýhodou vlastního přístupu je možnost „vnitropodnikové slepoty“ ze strany analytiků, která je u ostatních variant eliminována externím pohledem dodavatele nebo konzultační firmy. Na druhou stranu je zde plno výhod plynoucích z využití vlastních odborníků. A pokud je navíc vlastní know-how kombinované s kvalitní metodikou pro provedení analýzy, není pro organizaci lepší volby.
30
Partnerský přístup Tento přístup není využíván příliš často, i když pro většinu organizací by byl velkým přínosem. Jestliže není k dispozici vlastní knowhow, nezbývá nic jiného než zvolit dodavatelský nebo partnerský přístup. Ten druhý však v sobě skrývá jednu zásadní výhodu: organizace postupně přechází z dodavatelského přístupu k vlastnímu řešení. Projekty související se zaváděním ISMS včetně detailní analýzy rizik nejsou jako dodání balíkového softwaru nebo vybavení serverovny klimatizací. Bezpečnost informací protíná celou organizaci, zasahuje do drtivé většiny činností a procesů, a proto je vhodnější takové projekty provádět více interně než dodavatelsky. Partnerský přístup je pro dotčené pracovníky prakticky školení o bezpečnosti. Konzultační firmy, které tento přístup nabízejí, přenáší na pracovníky organizace své know-how a tomu by také měla odpovídat cena za projekt. Ta může dosáhnout i 75% dodavatelské varianty a je tak významnou nevýhodou a tím i častým důvodem k odmítnutí ze strany managementu. U detailní analýzy je celkové zatížení pracovníků společnosti srovnatelné s vlastním přístupem. Na provádění veškerých činností se významně podílí interní pracovníci pod vedením (dohledem) externího konzultanta, který má odpovědnost za projektové a metodické vedení. Spolupráce je velmi intenzivní po celý průběh projektu, ať už při rozhovorech o hodnocení aktiv nebo při zkoumání hrozeb a zranitelností. Nejintenzivnější spolupráce je však při tvorbě výstupů, které jsou ve skutečnosti tvořeny pod hlavičkou dané společnosti nikoli jako dodavatelský materiál. Zprávy včetně doporučení tvoří pracovníci sami a tudíž rozhodují o stylu i formě, aby byly všechny výstupy srozumitelné pro všechny zainteresované včetně managementu. Prakticky to vypadá tak, že externí analytik dodá šablonu dokumentu, kterou pracovníci doplní vlastními závěry formulovanými na základě výsledků analýzy s minimální podporou od konzultační firmy.
Všechny tři přístupy jsou správné a vhodné, ale ne pro každého. Může rozhodovat velikost organizace, její obchodní zaměření nebo i počet uživatelů informačního systému. V praxi se však postupně opouští od striktně dodavatelského řešení „na klíč“ a organizace stále více využívají svých pracovníků a vlastního know-how nebo externích konzultantů na jeho získání. Přístupy nemusí být aplikovány pouze na projekt analýzy rizik, ale i na celkové řešení bezpečnosti informací – zavádění a podporu ISMS. Při rozhodování o správném přístupu je nutné zohlednit zejména očekávané přínosy pro organizaci. Pokud jsou ve vlastních řadách k dispozici odborníci na informační bezpečnost, není nutné volit dodavatelský přístup. V opačném případě závisí na zvolené strategii do budoucna. Přenést odpovědnost na dodavatele a nechat si vše externě zajistit nemusí být špatná volba. Ale organizace by měla zvážit, zda není vhodnější zvolit partnerský přístup a postupně přebírat odpovědnost za bezpečnost svých dat a vychovávat si tak vlastní odborníky.
31
32
4. NASAZENÍ V DOPRAVNÍM PODNIKU 4.1 Plán Vzhledem k výše popsaným postupům, metrikám a normám by se mohlo zdát, že provedení Bezpečnostního auditu ve firmě je pouhým vyplňováním předem nadepsané tabulky nebo odškrtáváním v již napsaném seznamu. Není tomu tak. Různí zákazníci mají různé požadavky a různá očekávání a ty je třeba respektovat. Není vždy vhodné postupovat v naprostém souladu s normou a usilovat o certifikaci. Například z finančních důvodů nebo s ohledem na rozsah či zaměření systému. V případě Dopravního Podniku jsme řešili přesně definované úkoly a výsledky prezentovali v předem dané formě výstupu. Nebylo použito postupů, které vedou k dosažení certifikace IS, nicméně některé rutiny a některá opatření z BS či ISO norem vycházejí. Až na určitá rozšiřující doporučení bylo přesně plněno zadání objednatele.
4.2 Zadání projektu Ze strany zadavatele – Dopravního podniku byly jasně určeny úkoly, které má projekt vyřešit, stejně tak i forma výstupu ke každému úkolu. Zadání ukládalo zpracování následujícího:
1.
Vyhotovit základní přehled stavu ICT Architektura ITC technologií, LAN/WAN sítě, servery/OS/aplikace, pracovní stanice, zhodnocení zálohovací strategie. Výstup: Strukturovaný a komentovaný přehled
2.
Posoudit bezpečnost ochrany počítačové sítě před útoky z internetu a z lokální sítě; zhodnocení bezpečnosti vzdálených přístupů do sítě objednatele; zhodnocení bezpečnosti a perspektivy používaných a možných typů komunikačních připojení k serverům a aplikacím z hlediska ochrany dat. Výstup: Zpráva obsahující veškeré zjištěné nedostatky v rámci konfigurace sítě, jejích bezpečnostních prvků a dalších komponent + doporučení ke zjednání nápravy a k implementaci změn včetně dopadu do interních procesů a směrnic.
33
3.
Ověřit zda jsou provoz a správa IT prováděny v souladu se směrnicemi DPML–S–308, 343,345, 347 a popisem činností OIT dle organizačního řádu. Výstup: Identifikace a komentovaný popis neshod obsahující nezbytná opatření a doporučení ke zjednání nápravy a k implementaci změn.
4.
Vytvořit SWOT analýzu a rizikovou analýzu IT. Výstup: Analýzy vztažené k bodům 1 až 3.
4.3 Základní přehled stavu ICT Architektura ICT Obecné principy architektury (tj. určitá nepsaná technologická vize) jsou obdobné jako v ostatních společnostech a nepředstavují pro budoucnost významné riziko. Bohužel tato vize není formalizována, přestože má zásadní vliv na další rozvoj společnosti v této oblasti. Některé zásadní otázky z pohledu architektury nejsou zatím řešeny, např. přístup k integraci dat. Konkrétní nedostatky a doporučení: -
Není stanovena strategie rozvoje IT technologií, a to ani jako interní dokument. V průběhu roku 2007 je třeba připravit strategický dokument, kritické části týkající se bezpečnosti zpracovat co nejdříve.
-
Obecné principy nejsou interně uplatňovány. Pokud je technickou vizí provozovat více jednoúčelových serverů je logicky optimálním, koncepčním řešením nasazení tzv. „blade“ serverů (server je fyzicky pouze kartou ve speciálním boxu, cena serverů je výrazně nižší)
Sítě LAN/WAN Síť LAN je vybudována zčásti „svépomocí“, neexistuje dokumentace k síti, protokoly a měření apod. Rozvodné skříně jsou umístněny z pohledu servisu zcela nevhodně. Síť WAN je tvořena několika technologiemi, jejichž nasazení má vzhledem k místním podmínkám opodstatnění. Zvolené technologie je možné považovat za standardní. Aktivní prvky jsou zařízení společnosti 3Com, Přístup k internetu a zajištění připojení předprodejních míst je řešen prostřednictvím zařízení Cisco 2801. Celková architektura sítě neodpovídá jejímu charakteru a není využíváno všech možností zařízení.
34
Konkrétní nedostatky a doporučení: Chybí segmentace sítě (bezpečnostní i provozní problém). Je třeba realizovat změny dle schématu v detailní technické zprávě a stanovit závazný plán. Je nutné si uvědomit, že se nejedná triviální operaci, ale technicky náročný projekt. Chybí dokumentace sítě. Doporučujeme realizovat kroky: a. Alespoň interně popsat a zakreslit síť LAN, v případě realizace rozsáhlejší rekonstrukce budovy zahrnout i kompletní rekonstrukci sítě LAN. b. S ohledem na prostředky v roce 2007 zvážit vybudování nové sítě (na základě prezentace pro management není zřejmé, jestli rekonstrukce fyzické sítě již neproběhla) -
Připojení předprodejních míst není stabilní. Doporučujeme provést interní revizi připojení zaměřenou na oblasti konfigurace, kapacity centrálního připojení na internet. OIT nemá k dispozici nástroj na alespoň jednoduché sledování chodu sítě (podobné nástroje lze využít i pro monitoring serverů). Opatřením je, zvážit implementaci SW nástroje na správu, která umožní predikci poruchových stavů a zkrátit reakci v případě poruchy.
Servery/OS/Aplikace Poměrně vysoký počet serverů je výrazně ovlivněn provozem odbavovacího systému, nelze měnit. Operační systémy serverů Windows nepředstavují vzhledem k charakteru aplikací riziko. Určitým rizikem je provoz serveru LINUX - nikoliv ze své podstaty, ale z důvodu nedostatečné podpory a rozdílné specializace pracovníků OIT. Odbavovací systém je postaven na principu třívrstvé architektury. Ostatní klíčové aplikace (tj. Integri – účetnictví a související agendy a Skeleton – dopravní agenda) jsou jednoduché proprietální aplikace. V dlouhodobém horizontu bude nutné zvážit nahrazení Integri plnohodnotným ERP systémem (tj. kategorie, kam spadá například SAP či Navision). Poštovní služby jsou rozděleny na dvě části – interní, kterou zajišťuje aplikace GroupWise (dočasně zajišťuje služby evidence interních dokumentů) a standardní elektronickou poštu, kterou zajišťuje mail server instalovaný v prostředí LINUX. Řešení je nestandardní, ale nelze jej považovat za nedostatek. Aplikaci je možné vzhledem ke své jednoduchosti hostovat u poskytovatelů internetových služeb bez významných nákladů. Nedoporučujeme přesun mailových schránek na externí server bez předchozí analýzy. Vzhledem k počtu schránek však nepovažujeme hosting mailu za efektivní. Prostředí serverové místnosti, ve kterém jsou servery provozovány není dostatečně zajištěno. Místnost slouží částečně i jako sklad a prostor není upraven pro umístnění serverů, klimatizace není zálohována. Je nezbytné si uvědomit, že značná část příkonu serveru je vyzářena do okolí jako zbytkové teplo a velký počet serverů může zvýšit teplotu v místnosti na takovou úroveň, že dojde k poškození výpočetní techniky. Konkrétní nedostatky a doporučení: Servery jsou provozovány tak jak byly dodány dodavatelem bez aplikace dalších bezpečnostních záplat zejména kritických. Doporučujeme procesně popsat povinnost OIT zajistit řádnou správu, vedení provozních deníků a zajistit smluvní podporu autorizovaným partnerem. Kterou záplatu provést je vždy na zvážení a zkušenosti správce, je nutné zajisti možnost konzultace s certifikovaným specialistou.
35
-
-
-
-
-
-
-
-
-
Neexistuje záložní Active Directory server (server zajišťuje evidenci uživatelů, hesla, oprávnění apod.). S ohledem na migraci aplikací zajistit záložní Active Directory server. Server Terminal má nainstalovaný systém pro vzdálený přístup přes ISDN, jenž není v současné době využíván. Doporučujeme odstavit tento server, aby se snížila možnost přístupu do vnitřní sítě mimo kontrolu. Možnost dohledání případných škod je nulová, neboť veškeré logy systému nejsou systematicky vyhodnocovány a navíc politika logování je nastavena tak, že jsou logy po krátké době přepisovány. Doporučujeme upravit povinnost kontrol a jejich případné uchování vnitřním předpisem (opět je nezbytné podpora specialistou) Rozvodná skříň je umístěna na chodbě. Tato skříň však není jištěna proti neoprávněné manipulaci. Doporučujeme zajistit skříň proti otevření nebo alespoň plombou. UPS nejsou k jednotlivým serverům propojena komunikačním kabelem zajišťujícím v případě nedostatku energie v bateriích bezpečné odstavení serverů bez hrozby ztráty dat. UPS neplní tedy svoji základní funkci. Doporučujeme realizovat propojení UPS se servery a zavést samostatnou evidenci týkající se výhradně UPS. Upravit v rámci vnitřního předpisu pravidelné testy a profilaxi UPS. V místnosti se nachází větší množství tonerových kazet tj. hromadění odpadu jenž může představovat požární ohrožení. Doporučujeme zakázat vnitřním předpisem skladování jakéhokoliv materiálu u serverů, včetně náhradních dílů, dokumentace apod. Jednotlivá zařízení (PC, switche,…) jsou umístněná na podlaze místnosti. Bez označení, nelze na první pohled zjistit, o které zařízení se jedná. Potíže v orientaci možnost zakopnutí atp. Navrhujeme neodkladně zajistit rack skříně (speciální skříně pro výpočetní techniku) nebo alespoň ocelové police (i více patrové) Klimatizace není zálohována a chybí dokumentace (profilaxe, výkon vzhledem k rozměrům místnosti a vyzářenému výkonu zařízení apod.). Revize klimatizace z pohledu využití a výhledově zajistit vhodnou formu zálohování je nutná. Neexistují pravidla pro akceptaci odbavovacího systému do rutinního provozu. K systému neexistuje provozní dokumentace. V rámci projektového týmu je nutné stanovit tato pravidla a vyžádat od dodavatele odpovídající dokumentaci. Nejsou vedeny Provozní denníky serverů, záznamy o UPS, nejsou kontrolovány záruční podmínky serverů apod. (viz předchozí body).
Pracovní stanice Stáří a vybavení lokálních stanic odpovídá stavu v jiných obdobných organizacích. Je obecně známo doporučení o výměně stanic v horizontu 4-5 let, ale málokteré organizaci se toto daří zcela dodržovat. Důvodem pro pravidelnou obměnu není pouze „morální zastaralost“, ale i větší poruchovost a vyšší náklady na opravy. Nákup nových PC je zde realizován ve formě objednávek od jedné značky, což hodnotíme jako správný krok. V budoucnu doporučujeme také omezení počtu různých variant konfigurací PC. Vybavení kancelářskými aplikacemi je možné považovat za standardní, včetně několika licencí Corel Draw apod.. Zvláštní aplikací je GIS vedený na stanici p. Bartoše (správa GIS je nejčastěji úkolem IT oddělení, p. Bartoš si servis zajišťuje sám). Tento stav není možné považovat za závadu, ale doporučujeme systém ve spolupráci s městem dále rozvíjet. Antivirová ochrana (McAffe) je řešena centrální distribucí. Správa licencí (OEM verze) je
36
přehledná. Tiskové úlohy jsou řešeny buď na lokální tiskárny nebo síťově prostřednictvím aplikace SafeQ. Konkrétní nedostatky a doporučení: Chybí evidence hlášených poruch a uživatelských požadavků (evidence je stanovena vnitřním předpisem, ale nedodržuje se). Doporučujeme aktualizovat vnitřní předpis. Nástroje pro vzdálenou správu jsou využívány i na pracoviště, kde je to z hlediska ochrany osobních údajů a obchodního tajemství nevhodné. Doporučením je realizovat vzdálenou správu tak, aby byla nezbytná součinnost koncového uživatele (spuštění aplikace, potvrzení přístupu). Na pracovištích managementu a pracovištích, která zpracovávají osobní data zaměstnanců přístup nepovolit. Nejsou definovány uživatelské profily. Doporučením je stanovit politiku jednotných profilů a podpořit ji vnitřním předpisem. Lze očekávat, že koncový uživatelé nebudou chtít spolupracovat, ale sjednocení profilů zjednoduší správu pracovišť, sníží poruchovost a dobu opravy poruch. Zálohování Zálohování je nutné hodnotit jako zcela nedostatečné. Stávající přístup vytváří významné riziko. Riziko minimální pravděpodobností vzniku, ale se zcela fatálními dopady! V případě požáru tak hrozí kompletní ztráta dat. Zálohovací strategie není optimalizována s ohledem na požadavek obnovitelnosti systému. V případě ztráty dat se tak s největší pravděpodobností podaří systém obnovit, ovšem bez jakékoliv garance času obnovy a objemu nenávratně ztracených dat (při obnově jsou určitá data vždy ztracena – minimálně ta, pořízená od poslední zálohy do havárie systému). Konkrétní nedostatky a doporučení: -
Veškerá data jsou zálohována na Windows XP počítač Zaloha, z nějž jsou jednou měsíčně vypalována na DVD. Celkový objem vypalovaných dat je cca 40 GB. Tento počítač však nemá ošetření vůči výpadku disků a tudíž hrozí nebezpečí ztráty dat.
-
V rámci zálohování jsou společně se všemi daty zálohovány i personální a mzdové údaje. Je tedy nemožné naplnit znění zákona, který ukládá smazání těchto údajů při odchodu zaměstnance ze společnosti.
-
Zálohována jsou jen data aplikací, samotné systémy zálohované nejsou.
-
Není určena osoba odpovídající za jednotlivé procesy záloh (kontrolující jejich bezvadnost). Neexistuje zvláštní evidence záloh (možno i jako součást provozního deníku)
-
Jednotlivé zálohy jsou uchovávány v pracovní místnosti IT pracovníků. Nejsou stanovena pravidla uchování záloh.
-
Ani pro jeden serverový systém není prováděna záloha systému v případě selhání serveru Caesar, jenž je hlavním serverem spravujícím uživatelské účty. Obnova systému při selhání tohoto serveru by byla náročná - musela by se prakticky implementovat počítačová síť od prvopočátku.
37
-
Zálohování odbavovacího systému je realizováno na samostatné pásky. Pracovníci OIT znají jen obecně zálohovací strategii. Neprobíhá kontrola pásek. Není stanoven postup pro obnovu systému.
-
Není stanoven (OIT není znám) celkový havarijní/krizový plán. V případě požáru v serverové místnosti a kanceláři OIT může dojít ke 100% ztrátě dat !
Není možné stanovit jednoduché doporučení. Je nutné přehodnotit celý systém zálohování. K krátkém období je nezbytné realizovat alespoň následující (byť dočasné) kroky. -
zkontrolovat stav pásek pro odbavovací systém
-
umístnit pracovní stanici Záloha mimo serverovou, nejlépe i mimo kancelář OIT
-
ukládat vybrané zálohy mimo pracoviště OIT
-
přehodnotit celou zálohovací strategii
4.4 Posouzení bezpečnosti Zcela chybí některé základní prvky bezpečnosti na organizační úrovni. Některá technická opatření jsou negována organizačními nedostatky. Základní technický prvek ochrany sítě z internetu – firewall, je realizován na serveru LINUX s nedostatečnou interní podporou a zcela bez jakékoliv smluvní podpory dodavatele (který ovšem správu provádí).
Konkrétní nedostatky a doporučení: -
Pracovníci IT mají na své uživatelské účty nastavena administrátorská práva. Zároveň není stanovena politika pro periodu změny hesel. Výsledkem je, že jakékoliv programy, se kterými zaměstnanci IT pracují, mají přístup k veškerým informacím a systémům, což v případě trojského koně či viru může vést ke zničení veškerých dat.
-
Pro řízení přístupu k prostředkům sítě je nevhodně využita skupina Everyone - u některých dat je nastaven plný přístup. Tímto způsobem jsou tato data veřejně dostupná pro kohokoliv .
-
Servery odbavovacího systému provozují vlastní domény. Toto je nevhodná konfigurace z hlediska LAN společnosti. Je nezbytné, provést oddělení těchto serverů od běžné sítě a nebo zajistit jejich integraci do domény společnosti. K těmto serverům má plný přístup externí dodavatel a pracovníkům IT není plně znám stav těchto serverů. Tyto servery představují tedy významné bezpečnostní riziko.
-
Otázkou je implementace WiFi sítě, jež může být hrozbou pro útok na IT systém společnosti. Není zřejmá konfigurace v jednotlivých vozech. Závazná dokumentace nebyla dodána.
38
-
Možnost dohledání případných škod je nulová, neboť veškeré logy systému nejsou systematicky vyhodnocovány, naopak jsou po krátké době mazány (viz výše). Některé logy v systému LINUX nejsou vytvářen vůbec.
-
Chybí segmentace sítě, v oblasti perimetru je v tuto chvíli několik adresných rozsahů, a i když L2 infrastrukturu tvoří přepínače, všechny adresní rozsahy se nacházejí v jedné L2 doméně. Kdokoliv, kdo má přístup k jakémukoliv Ethernet portu, může na síti odposlouchávat všechny adresné rozsahy a na základě zjištěných informací provést různé akce (od zjišťování informací po různé druhy útoků).
-
Jednotlivé logické segmenty v oblasti perimetru nejsou rozděleny do zón a přístup k nim tedy není řízený.
-
Elektronický odbavovací systém: Aplikační server není chráněn firewallem. K serverům není řízen přístup z ostatních segmentů.
-
Nedostatečná dokumentace serveru Linux. Vzhledem k tomu, ze služba je spravována třetí stranou (tzv. outsourcing), chybí k serveru uživatelská dokumentace. Měla by být poskytovatelem služby dodána pro účely přehledu o běžícím systému a jeho službách, účtech a jejich oprávnění.
-
Nedostatečné podklady požadavků elektronického odbavovacího systému na síťovou infrastrukturu (nároky na propustnost – současné a budoucí s ohledem na možné rozšíření systému, popis systému – schéma použitých síťových a komunikačních protokolů)
Doporučené schéma nápravy je popsáno dále. Nad rámec technických opatření navrhujeme zapracovat bezpečnost do interních předpisů. V delším časovém horizontu doporučujeme realizovat Firewall a Virtuální privátní síť (vzdálený přístup) na specializovaném technickém zařízení (Cisco PIX, Netscreen, Juniper) a implementovat zařízení typu IDS (zařízení detekující průnik do sítě). Specializované programové produkty Firewall jako například Check Point spíše nedoporučujeme z důvodu náročné správy.
Riziko zneužití dat externím subjektem Základní principy bezpečnosti jsou dodržovány nedostatečně nebo vůbec (periodicita měnění hesel, administrátorská práva mnoha lidí). Zneužití zdrojů vnitřní sítě neumí OIT identifikovat a vyhodnotit, nejsou logovány. Využití některých nástrojů je zcela neopodstatněné a usnadňují případné zneužití (vzdálený přístup na plochu zaměstnanců zpracovávajících osobní údaje). V rámci rámcové kontroly nebyly zjištěny skutečnosti, které by indikovaly zneužití prostředků firmy interním ani externím subjektem. Vzhledem k výše zmíněným skutečnostem však nelze garantovat, že k takovému zneužití v minulosti nedošlo. Z hlediska pravděpodobnosti zneužití dat můžeme definovat následující rizikové skupiny Vysoké riziko: -
Pracovníci OIT. Z principu věci je správce vždy rizikem, které lze snížit pouze vnitřními organizačními opatřeními (pracovní smlouvy apod.).
39
-
Dodavatel má plnou kontrolu nad přístupem do sítě. K serveru chybí dokumentace. Chybí smlouva se dodavatelem.
Střední riziko: -
Dodavatel2 má plný vzdálený přístup na několik serverů, které nejsou odděleny od vnitřní sítě. Jako střední riziko je firma hodnocena z toho důvodu, že prokazatelně disponuje odborníky a má detailní znalost o celkové architektuře. Nicméně podmínkou zneužití je znalost přístupových hesel.
Nízké riziko: -
Integri. Omezení vzdáleného přístupu na Firewallu a omezení uživatelského účtu je takového charakteru, že bez znalosti administrátorských hesel je zneužití komplikované.
-
Ostatní uživatelé vnitřní sítě. Omezení uživatelů a nesegmentovaná síť otevírá teoretickou možnost, že i středně znalý uživatel, který zná administrátorské přístupy, může data zneužít.
Konkrétní nedostatky a doporučení: Zjištěné nedostatky jsou již popsány výše (Servery/OS/Aplikace, Posouzení bezpečnosti).
Vzdálený přístup Samotný princip vzdáleného přístupu není nestandardní a řada firem jej využívá jednak pro servisní přístup, ale i pro uživatelský přístup vybraných uživatelů. Technicky je možné vzdálený přístup řešit několika technickými způsoby – v optimálním případě jednoúčelovým technickým zařízením (např. Netscreen). Níže doporučujeme realizovat přístup na prostředcích, které má firma k dispozici. Rozšíření vzdálených přístupů můžeme doporučit až po realizaci kroku, kdy se správa Firewallu přesune na Cisco 2801 a bude základním způsobem segmentována síť. Nezbytná je i určitá formalizace pro zřízení služby (formulář, evidence apod.) Nutnost vzdáleného přístupu pro společnost Integrit je na zvážení – vzdálený přístup je součástí dodatku č.2 smlouvy o trvalé technické pomoci. Z dodatku však nevyplývá jakýkoliv benefit pro Dopravní podnik.
Analýza stavu bezpečnosti informačních technologií Popis současné situace: - Linux server Server na platformě RedHat Linux v současné době plní funkci firewallu pro přístup z interní sítě do Internetu. Kromě toho je používán také jako SMTP server, interní DNS server a souborové úložiště.
40
-
-
-
elektronický odbavovací systém Hlavní část tvoří aplikační a databázový server. Přesun dat ke koncovým stanicím je realizován prostřednictvím FTP serverů. Předprodejní místa pak komunikují s aplikační částí sytému. Aplikační server má více rozhraní pro připojení k různým částem sítě. Jedno z rozhraní má přirazenou veřejnou IP adresu pro komunikaci s předprodejními místy, tzn. komunikace neprobíhá skrz firewall. Celý systém je postaven na platformě Windows. Komunikace předprodejních míst s aplikačním serverem je realizována šifrovaně přes Internet. router 2801 Jedná se o hraniční směrovač do Internetu (Internet Edge Router). Zařízení zajišťuje komunikaci do Internetu a zároveň ukončuje šifrovaná spojení z předprodejních míst. Síť obecně Servery a koncové stanice jsou rozděleny do několika privátních adresných rozsahů.
Konkrétní nedostatky: - Chybí segmentace sítě. V oblasti perimetru je v tuto chvíli několik adresných rozsahů, a i když L2 infrastrukturu tvoří přepínače, všechny adresní rozsahy se nacházejí v jedné L2 doméně. Kdokoliv, kdo má přístup k jakémukoliv Ethernet portu, může na síti odposlouchávat všechny adresné rozsahy a na základě zjištěných informací provést různé akce (od zjišťování informací, po různé druhy útoků). - Jednotlivé logické segmenty v oblasti perimetru nejsou rozděleny do zón a přístup k nim tedy není řízený. - Elektronický odbavovací systém - aplikační server není chráněn firewallem a používá zbytečně moc rozhraní. K serverům není řízen přístup z ostatních segmentů. - Nedostatečná dokumentace serveru Linux. Vzhledem k tomu, že služba je spravována třetí stranou (tzv. outsourcing), chybí k serveru uživatelská dokumentace. - Nedostatečné podklady požadavků elektronického odbavovacího systému na síťovou infrastrukturu (nároky na propustnost – současné a budoucí s ohledem na možné rozšíření systému, popis systému – schéma použitých síťových a komunikačních protokolů). - Nedostatečné plánování, sestavení strategického plánu. Zmiňujeme jako nedostatek abychom poukázali na důležitost aktivní spolupráce mezi managementem a oddělením IT tak, aby plány managementu na další rozvoj sítě a její infrastruktury mohly být dostatečně včas a vhodně podchyceny administrátory (nebo naopak).
Konkrétní doporučení: - síť segmentovat na více částí s cílem mít možnost filtrace přístupu (jeden ze způsobu jak lze segmentaci provést je znázorněn na obrázku) - nasazení HW firewallu - zavedení alespoň základní úrovně bezpečnosti (L2 Security - vytvoření VLAN) - vznik bezpečnostní politiky - zavedení a dodržování heslové politiky - zvýšení zabezpečení směrovače C2801 - výhledově nasazení pravidelných security auditů - zavést logování a monitoring sítě
41
Návrh segmentace na zamezení neautorizovaného přístupu mezi sítěmi:
Obr.: Příklad návrhu segmentace perimetru
Konkrétní návrh na změnu topologie je nutné navrhnout ve spolupráci se zadavatelem.
4.5 Ověření vnitřních předpisů Obsah jednotlivých interních předpisů obsahově neodpovídá obecnému principu dle „Výňatek organizačního řádu společnosti – oddělení IT“. Nepopisuje veškeré činnosti, které jsou nezbytné k zajištění provozuschopnosti informačních technologií a především žádným způsobem nepopisuje odpovědnosti. Velkým nedostatkem je, že obsahově splývají směrnice pro koncové uživatele a pro OIT. -
DPML-S-308, Provozní řád oddělení Informačních technologií,
42
-
DPML-S-347, Provozní řád podnikové počítačové sítě
-
DPML-S-343, Ošetřování a ochrana podnikové výpočetní techniky
DPML-S-345, Správa a údržba WWW presentace společnosti, dokument obsahuje základní odpovědnosti, popis postupu a strukturu dat. Z hlediska základního obsahu není nutné dokument aktualizovat. Vybrané náměty pro doplnění vnitřních směrnic: 1) Definice základních procesů správy a údržby výpočetní techniky a. Pravidelná údržba a profilaxe systémů b. Řešení poruchových stavů c. Řešení změnových požadavků. 2) Změnit filozofii dokumentů – posílit/definovat postavení firemních procesů a koncových uživatelů 3) Stanovit základní provozní požadavky na jednotlivé úlohy 4) Z hlediska struktury dokumentů oddělit směrnici pro koncové uživatele (DPML-S-343 a 348) a. Sjednocení obsahu dokumentů včetně částí obsažených ve směrnici DPML-S-308 b. Zjednodušení dokumentu a vyloučení částí, které uživatel nemůže ovlivnit (pracovní prostředí výpočetní techniky) nebo které jsou z jeho pohledu nerelevantní. c. Jednoznačně popsat procesy, hlášení chyb, žádost o změnu apod. 5) Detailně propracovat směrnici DPML-S-308 Provozní řád oddělení Informačních technologií, a. Stanovení jednoznačné odpovědnosti za servery a aplikace (při zachování principu zastupitelnosti). Včetně kontroly systému, evidencí a provozní komunikace s dodavateli. b. Stanovení odpovědnosti za zálohování a nakládání se zálohami. c. Stanovení pravidel bezpečnosti (odpovědnost, pravidla hesel , přidělování práv) d. Stanovení postupu řešení poruch a servisních požadavků, jejich prioritizaci, obecná pravidla eskalací jak na management tak na dodavatele a v neposlední řadě jejich evidenci. e. Stanovení pravidel změn v systému a aplikacích.
Smluvní dokumenty V rámci posouzení byly posouzeny některé smluvní vztahy v klíčovými dodavateli v oblasti správy výpočetní techniky.
43
Dodavatel1 – Smlouva na dodávku odbavovacího systému. Ze smlouvy není patrná detailní technická konfigurace IT částí řešení. Není zřejmá následná technická podpora, která je pro provoz aplikační části nezbytná. Dodavatel2 – Smlouva na systém Integrit, běžná obchodní smlouva na daný druh SW, z dodatků však není zřejmý jejich účel (vyšší cena není vyvážena vyšším servisem, dalšími moduly apod.) Dodavatel3. – Smlouva na poskytování připojení k internetu, smlouva neobsahuje část zahrnující správu firewallu, mail serveru, interního DNS a WEB serveru ! Dodavatel4. – Smlouva na systém Skeleton , běžná obchodní smlouva na daný druh SW. Dodavatel5 – Smlouva na servis bezdrátové spojení. Služby jsou nezbytné pro daný spoj a její rozsah je obvyklý. Dodavatel6 – Smlouva o poskytování CIS – Smlouva na poskytování internetu , výhrada – chybí běžné přílohy typu technické specifikace apod.
Smluvní dokumenty, které vzhledem k charakteru aplikací a provozu lze očekávat, ale ve skutečnosti chybí. -
Správa LINUX serveru – firewall, WEB Server, Mail Server
-
Podpora Platformy Microsoft – smluvní a servisní podpora serverů MS Windows Server 2000 a 2003
-
Podpora systému GroupWise – vzhledem k relativně nízké vnitřní prioritě systému není absence servisní smlouvy kritickým nedostatkem, ale pouze doporučením.
4.6 Další technická posouzení Počítačová síť IT pracovníci nemají k dispozici dokumentaci sítě. Provedli její základní značení, nalezení jednotlivých ukončení, avšak nemají informace o jejím vedení v budově. Existují dvě WiFi sítě, které slouží pro nahrávání dat do jednotek v tramvajích. Zajištění těchto WiFi sítí nebylo přesněji zjištěno, zajišťuje společnost Mikroektronika. Aktivní prvky jsou většinou L2 Switche 3COM, rozhraní do internetu je tvořeno Routerem Cisco 2801. VLAN v síti nejsou implementovány. WAN síť je tvořena kombinací bezdrátových technologií – ať již vlastními nebo pronajatými okruhy. Pro prodejní místa je využito přípojek ADSL Českého Telecomu (Telefonica O2). Trasy VPN sítí nejsou optimalizovány a routing probíhá přes NIX.
Doporučení 1. Zpětně dotázat dodavatelskou firmu o projektovou dokumentaci 2. Dokumentovat veškerou novou instalaci a alespoň rámcově zaznamenat stávající stav.
44
3. Požádat společnost Mikroelektronika o dodání dokumentace k zajištění bezpečnosti přístupu do interní počítačové sítě společnosti přes WiFi sítě vůči možnému útoku z vnějšku společnosti. Servery Následující servery byli podrobeny základní kontrole: 1. 2. 3. 4. 5. 6.
Caesar Zaloha Terminal Platon FTP L FTP M
Server Phoenix nebyl zkoumán důvodů jeho plánovaného odstavení v horizontu měsíce. A servery Alpha a Delta a Linux z důvodů že jsou pod plnou kontrolou externích dodavatelů. U všech serverů byli zjištěné nedostatky společné (již jednou výše uvedeno na různých místech). Servery jsou provozovány tak, jak byly dodány dodavatelem - bez aplikace dalších bezpečnostních záplat, zejména kritických. Fakt, že servery nemají přístup k internetu, není ochranou, neboť k serverům mají přístup uživatelé, jenž mají přístup k internetu. Otázkou je implementace WiFi sítě, jež může být hrozbou pro útok na IT systém společnosti. Možnost dohledání případných škod je nulová, neboť žádné logy systému nejsou systematicky vyhodnocovány a navíc politika logování je nastavena tak, že po krátké době jsou logy systému přepisovány. Ani pro jeden serverový systém není prováděna záloha systému, v případě selhání serveru Caesar, který je hlavním serverem spravujícím uživatelské účty, by následná obnova systému prakticky znamenala implementaci počítačové sítě od prvopočátku. Současně neexistuje záložní Active Directory server . Pracovníci IT mají na své uživatelské účty nastavena Administrátorská práva. Zároveň není stanovena politika pro periodu změny hesel. Výsledkem je, že jakékoliv programy, se kterými zaměstnanci IT pracují, mají přístup k veškerým informacím a systémům, což v případě trojského koně či viru může vést ke zničení veškerých dat. Pro řízení přístupu k prostředkům sítě je nevhodně využita skupina Everyone, kde u některých dat je nastaven plný přístup. Tímto způsobem jsou tyto data veřejně dostupná pro kohokoliv . Server Terminal má nainstalovaný systém pro vzdálený přístup přes ISDN, jenž není v současné době využíván. Doporučujeme odstavení, aby se snížila možnost přístupu do vnitřní sítě mimo kontrolu. Servery Alpha a Delta provozují vlastní domény. Toto je nevhodná konfigurace pro konfiguraci sítě jež je ve společnosti. Je nezbytné, provést oddělení těchto serverů od běžné sítě a nebo zajistit jejich integraci do domény společnosti. K těmto serverům má plný přístup externí dodavatel a pracovníkům IT není plně znám stav těchto serverů. Tyto servery jsou tedy významným bezpečnostním rizikem. Základní ochrana vůči útokům z vnější sítě (Internet) je řešena pomocí počítače s Linuxovým operačním systémem (s plnou správou externího dodavatele). Na základě diskuze bylo zjištěno, že
45
je vysoce pravděpodobné, že by tento dodavatel mohl reagovat i na požadavek o změnu konfigurace mimo pracovníky IT či pomocí velmi jednoduchý technik, podvržení falešného emailu.
Aplikace Serverové aplikační vybavení jsme pro lepší orientaci rozdělili do dvou skupin dle svého charakteru. Nedostatky, které jsou společné pro všechny aplikace jsou dokumentace, pravidla relase, backup a recovery plan a jakákoliv podoba funkční uživatelské specifikace. Bez uživatelského zadání nelze určit priority jednotlivých systémů. Funkčně jednoduché a nenáročné systémy, jako jsou například katalogy (Karosa apod.), však mohou mít zcela kritický dopad na určité činnosti firmy. Charakter lokálních aplikací je možné považovat za standardní, včetně specifických aplikací jako jsou Corel Draw, AutoCad a specializované katalogy.
•
Moderní aplikace s dlouhou morální životností Do této skupiny patří odbavovací systém - FareOn, jehož implementace není ukončena. Aplikace je navržena na třívrstvé architektuře, navíc využívá jako komunikační periferie tzv. FTP servery, které zajišťují fyzickou komunikaci s jednotlivými vozy. V průběhu kontroly bylo patrné, že na systému dochází k určitým změnám a systém není možné považovat za stabilní. Aplikace je integrována s aplikací Skeleton. V systému nejsou dopracovány některé funkční prvky (off-line komunikace), nejsou dány akceptační podmínky, není veden katalog chyb, chybí dokumentace k danému systému. Funkční vybavení v jednotlivých vozech je mimo správu OIT, přestože mohou zásadním způsobem ovlivnit celkovou funkci systému. Odstranění některých zásadních chyb systému bylo pravděpodobně neformálně eskalováno na dodavatele, ale o řešení chyb nebyl předložen žádný záznam. Za největší zaznamenané nedostatky z pohledu OIT považujeme. -
postupné přetěžování paměti serveru
-
vyšší potřeby na přenosovou kapacitu předprodejních míst než odpovídalo původní specifikaci
Systém dle dostupných informací není připraven na převzetí do rutinního provozu, k sytému navíc není připravena servisní smlouva, kterou vzhledem k charakteru aplikace považujeme za nezbytnou. •
Standardní síťové aplikace Do této skupiny zahrnujeme aplikace nejčastěji architektury „klient/server“ s vyšším počtem uživatelů: Integri Aplikace kromě základního účetnictví a ekonomických evidencí zahrnuje i některé další úlohy, ale vzhledem k rozsahu ji nemůžeme považovat za plnohodnotný ERP systém. Za
46
nedostatek aplikace považujeme využití databáze a využití HW klíčů. Vzhledem k významu aplikace považujeme za zcela nedostatečné, aby si dodavatel sám řídil release politiku a testování změn přímo s koncovými uživateli. GroupWise Aplikace je instalována v prostředí historicky, ale není dlouhodobě rozvíjena. Zjišťuje služby vnitřní elektronické pošty a jednoduchou formu eDMS. Aplikace splňuje základní požadavky, ale není aktualizována, nerozvíjí se a nepřímo se tak snižuje její přidaná hodnota. „Linux“ V rámci operačního systému Linux RedHat 7,2 je provozováno několik základních aplikací: Firewall, mail server, WebServer, ProxyServer, DNS. Vzhledem ke skutečnosti, že na serveru běží pro firmu klíčové aplikace, je zastaralý operační systém s problematickou aktualizaci nutné hodnotit jako zcela nedostatečný. Skeleton Klíčová aplikace pro řízení provozu, integrovaná s aplikací Freon samostatným konektorem. Dle sledovaných ukazatelů splňuje aplikace základní požadavky. ANET Aplikace nad „docházkovým systémem“. Dle sledovaných ukazatelů splňuje základní požadavky. SafeQ Aplikace pro sdílení a řízení tiskových úloh. Aplikace vzhledem ke svému účelu nepředstavuje zvýšená riziko. Správce pošty Drobná jednoduchá - evidenční aplikace bez významných rizik.
47
4.7 SWOT analýza a analýza rizik SWOT analýza stavu IT SWOT analýza je posuzována s pohledem na oddělení OIT jako na jednoho z klíčových oddělení. SILNÉ STRÁNKY Lidské zdroje Kvalitní evidence licencí a přístup k licenční politice Relativně kvalitní technologická základna Centralizované tiskové řešení
SLABÉ STRÁNKY Absence dlouhodobé strategie ITC Nedostatečné procesy ITC a z toho plynoucí dlouhé doby řešení poruchových stavů Nepokryté některé nezbytné smluvní vztahy Postavení IT ve firmě z pohledu vnitřní kultury (určité vyčlenění IT)
PŘÍLEŽITOSTI Odbavovací systém, jeho další rozvoj a přínosy pro zákazníky Přístup managementu k fondům EU jako zdroji financování rozvojových projektů. Vlastnictví trolejových vedení jako infrastruktury
HROZBY Bezpečnostní rizika ve vztahu k ITC Zálohování a rizika z toho plynoucí Nedostatečná součinnost ITC s vedením projektu implementace odbavovacího systému
Dopravní podnik je svém charakterem typickým představitelem středního podniku. Jeho zvláštností je vlastnická struktura, která jej řadí do obecné skupiny municipalit. Z pohledu informačních technologií nepředstavuje tato skutečnost zvláštní riziko. Geograficky je umístněn na okraji středně velkého města s vysokou mírou nezaměstnanosti. Potencionální hrozbou ve střednědobém horizontu je nedostatek odborníků v oblasti informačních technologií. Přes vysoký počet zjištěných nedostatků, nelze hodnotit celkový stav informačních technologií jako kritický. Revize přístupu především uvnitř samotného OIT je však nezbytná, především na provoz odbavovacího systému a jeho význam pro vlastní provoz. V delším časovém horizontu můžeme dát námět k následujícím krokům. -
Kompletní, detailní bezpečnostní audit informačních technologií. Tento krok lze doporučit po akceptaci odbavovacího systému a realizaci doporučených změn. Nepovažujeme za účelné provést audit v blízké době, protože by v první fázi zopakoval nedostatky uvedené v tomto dokumentu.
-
Test obnovení systému ze zálohy (ať realizovaný vlastním OIT nebo dodavatelem klíčového systému).
48
Analýza rizik Nedostatek Není stanovena strategie rozvoje IT technologií a to ani jako interní dokument. V průběhu roku 2007 připravit strategický dokument, kritické části týkající se bezpečnosti zpracovat co nejdříve. Chybí segmentace (např. oddělení uživatelů od serverů) sítě (bezpečnostní i provozní problém). Realizovat změny dle schématu v detailní technické zprávě a stanovit závazný plán. Je nutné si uvědomit, že se nejedná o triviální operaci, ale technicky náročný projekt.
Popis rizika Chybné investice do IT technologií
Bezpečnostní rizika, chyby na sítí a neefektivní zatížení sítě
Prodloužení doby Chybí dokumentace sítě, síť ve odstranění městě L není kategorie 5. poruch a vyšší cena za opravy Připojení předprodejních míst není Poruchovost stabilní. Doporučujeme provést připojení, interní revizi připojení zaměřenou dlouhá doba na oblasti konfigurace, kapacity oprav centrálního připojení na internet. OIT nemá k dispozici nástroj na alespoň jednoduché sledování Není možná chodu sítě (podobné nástroje lze účinná využít i pro monitoring serverů). predikce Opatřením je zvážit implementaci poruch, SW nástroje na správu, která dlouhé doba umožní predikci poruchových odstraňování stavů a zkrátit reakci v případě poruch poruchy.
Riziko vzniku
Dopad
Investice na odstranění rizika
Priorita
Střední
Interně, Významné maximálně finanční desítky tisíc za riziko odborné konsultace
2
Vysoké
Střední
Desítky tisíc za nákup zařízení a technická podpora při instalaci
2
Nízké
Minimální dokumentaci lze pořídit i interně
3
Střední
Interně, maximálně desítky tisíc za odborné konsultace
1
Střední
Desítky tisíc, v případě dražších řešení v řádů stovek tisíc doporučujeme řešit komplexně i s některými provozními celky.
2
Nízké
Vysoké
Střední
49
Servery jsou provozovány tak, jak byly dodány dodavatelem bez aplikace dalších bezpečnostních záplat, zejména kritických. Doporučujeme procesně popsat povinnost OIT, zajistit řádnou správu, vedení provozních denníků a zajistit smluvní podporu autorizovaným partnerem. Kterou záplatu provést, je vždy na zvážení a zkušenosti správce, je nutné zajistit možnost konsultace problému s certifikovaným specialistou.
Výpadky systémů a dlouhá doba odstranění poruch
Vysoké
Neexistuje záložní Active Directory server (server zajišťuje evidenci uživatelů, hesla, oprávnění apod.) . S ohledem na migraci aplikací zajistit záložní Active Directory server.
Ztráta vztahu uživatelů k právům apod. Významné prodloužení doby obnovy systému
Server Terminal má nainstalovaný systém pro vzdálený přístup přes ISDN, jenž není v současné době využíván. Doporučujeme zabezpečit tento RAS nejlépe vypnutím tak aby se snížila možnost přístupu do vnitřní sítě mimo kontrolu. Možnost dohledání případných škod je nulová, neboť veškeré logy systému nejsou systematicky vyhodnocovány a navíc politika logování je nastavena tak, že po krátké době jsou logy systému přepisovány. Doporučujeme upravit povinnost kontrol a jejich případné uchování vnitřním předpisem (opět je nezbytná podpora specialisty)
Střední
Servisní smlouvy s certifikovanými dodavateli (100200 tis ročně)
1
Nízké
Střední
Existuje několik variantních řešení
2
Neoprávněný přístup do vnitřní sítě
Nízké
Významné
Pouze interní konfigurace
1
Není možná účinná predikce poruch, dlouhá doba odstraňování poruch. Nemožnost dohledat zneužití sítě
Střední
Významné Interní opatření
50
1
Rozvodná skříň je připojena k rozvodům, jež mají svoji skříň na chodbě. Tato skříň však není jištěna proti neoprávněné manipulaci. Doporučujeme zajistit skříň proti otevření nebo alespoň plombou. UPS nejsou k jednotlivým serverům propojena komunikačním kabelem zajišťujícím v případě nedostatku energie v bateriích bezpečné odstavení serverů bez hrozby ztráty dat. UPS neplní tedy svoji základní funkci. Realizovat propojení UPS se servery a zavést samostatnou evidenci týkající se výhradně UPS. Upravit v rámci vnitřního předpisu pravidelné testy a profilaxi UPS. V místnosti serverovny se nacházelo větší množství tonerových kazet tj hromadění odpadu jež může představovat požární ohrožení. Zakázat vnitřním předpisem skladování jakéhokoliv materiálu u serverů, včetně náhradních dílů, dokumentace apod. Jednotlivé zařízení byla umístněná na podlaze místnosti (bez označení) Potíže v orientaci možnost zakopnutí atp. Neodkladně zajistit rack skříně (speciální skříně pro výpočetní techniku) nebo alespoň ocelové police (i více patrové)
Vyřazení aplikací "omylem" nebo úmyslně bez možnosti kontroly
Nízké
Střední
Interní nebo zanedbatelné
2
UPS nechrání servery proti delším výpadkům. Riziko následných poruch
Střední
Střední
Zanedbatelné (spotřební materiál)
1
Nízké
Kritické Poškození techniky a ztráta dat v případě požáru
Zanedbatelné, vyčlenění jiného skladovacího prostoru
1
Nízké
Zanedbatelné v případě nákupu Kritické ocelových polic a Poškození přestavby, do 100 techniky a tis v případě ztráta dat v nákupu Rack případě skříní (nejlépe v požáru souvislosti s novou technikou)
1
Zvýšení rizika požáru, zvýšená prašnost
Zvýšení riziko požáru, zvýšená prašnost
51
Klimatizace není zálohována a chybí dokumentace (profilaxe, výkon vzhledem k rozměrům místnosti a vyzářenému výkonu zařízení apod.). Revize klimatizace z pohledu využití a výhledově zajistit vhodnou formu zálohování. Neexistují pravidla pro akceptaci odbavovacího systému do rutinního provozu K systému neexistuje provozní dokumentace. V rámci projektového týmu stanovit tato pravidla a vyžádat od dodavatele dokumentaci. Nejsou vedeny Provozní denníky serverů, záznamy o UPS, kontrolovány záruční podmínky serverů apod. (viz předchozí body). Chybí evidence hlášených poruch a uživatelských požadavků (evidence je stanovena vnitřním předpisem, ale nedodržuje se. ) Doporučujeme aktualizovat vnitřní předpis. Nástroje pro vzdálenou správu jsou využívány i na pracoviště, kde je to nevhodné. Doporučením je realizovat vzdálenou správu tak, aby byla nezbytná součinnost koncového uživatele (spuštění aplikace, potvrzení přístupu. Na pracovištích managementu a pracovištích, která zpracovávají osobní data zaměstnanců, přístup nepovolit.
Riziko výpadku systému až poškození některých částí.
Střední
Převzetí systému s chybami a neúplnou dokumentací
Střední
Významné Interní
1
Riziko nesprávných reklamací. U UPS riziko výpadku systému
Střední
Nízké, především Interní finanční rizika
1
Opakování poruch a dlouhá doba na odstranění
Vysoké
Zvýšení rizika zneužití dat
Střední
52
Střední
Nízké
Nelze určit bez odborného projektu
2
Interní
1
Významné Interní
1
Nejsou definovány uživatelské profily. Doporučením je stanovit politiku jednotných profilů a podpořit ji vnitřním předpisem. Lze očekávat, že koncový uživatelé nebudou chtít spolupracovat, ale sjednocení profilů zjednoduší správu pracovišť a sníží poruchovost a doby na opravy poruch. Veškeré data jsou zálohována na Windows XP počítač Zaloha, z nějž jsou jednou měsíčně vypalována na DVD. Celkový objem vypalovaných dat je cca 40 GB. Tento počítač však nemá ošetření vůči výpadku disků a tudíž hrozí nebezpečí ztráty dat. V rámci zálohování jsou společně se všemi daty zálohována i data od zaměstnanců zajišťujících mzdové a osobní záležitosti a tudíž je nemožné, aby byl naplněn zákonný požadavek, že při odchodu zaměstnance ze společnosti jsou zničeny informace o této osobě.
Prodloužení doby odstranění poruch na lokálních stanicích
Vysoké
Riziko ztráty dat
Nízké
Nesoulad se zákonem na ochranu osobních údajů
Střední
Významné Zálohovány jsou jen Data aplikací prodloužení samotné systémy zálohované doby obnovy nejsou. systému Není ustanovena zodpovědná osoba za jednotlivé procesy záloh Riziko ztráty a kontrolující jejich bezvadnost. dat Neexistuje zvláštní evidence záloh prodloužení (možno i jako součást provozního doby obnovy deníku) Jednotlivé zálohy jsou uchovávány Riziko ztráty v pracovní místnosti IT dat v případě pracovníků. Nejsou stanovena požáru pravidla uchování záloh.
Nízké
Interní, organizačně náročné
ale
Nákup jednoúčelového serveru pro Významné zálohování, do 100, variantně 200 tis.
Nízké
Interní
3
1
2
Nízké
Zanedbatelné Významné (spotřební materiál)
1
Nízké
Významné Interní
1
Nízké
Kritické úplná ztráta dat v Interní případě požáru
1
53
Ani pro jeden serverový systém není prováděna záloha systému v případě selhání serveru Caesar jenž je hlavním serverem spravujícím uživatelské účty by následná obnova systému byla náročná musela by se prakticky implementovat počítačová síť od prvopočátku. Zálohování odbavovacího systému je realizováno na samostatné pásky, Pracovníci OIT znají jen obecně zálohovací strategii. Neprobíhá kontrola pásek, Není stanoven postup pro obnovu systému. Není stanoven (OIT není znám) celkový havarijní/ krizový plán. V případě požáru v serverové místnosti a kanceláři OIT může dojít ke 100% ztrátě dat ! Pracovníci IT pracují mají na své uživatelské účty nastavena Administrátorská práva . Zároveň není stanovena politika pro periodu změny hesel. Výsledkem je že jakékoliv programy se kterými IT pracovníci pracují mají přístup k veškerým informacím a systémům což v případě trojského koně či viru může vést ke zničení veškerých dat . Pro řízení přístupu k prostředkům sítě je nevhodně využita skupina Everyone kde u některých dat je nastaven plný přístup. Tímto způsobem jsou tyto data veřejně dostupná pro kohokoliv .
Prodloužení doby obnovy dat
Riziko ztráty dat a prodloužení doby obnovy
Nízké
Významné Interní
1
Střední
Kritické rizika ztráty klíčových dat.
1
Zanedbatelné (spotřební materiál)
Kritické úplná ztráta dat v interní případě požáru
Riziko ztráty dat
Nízké
Riziko poškození systému
Střední
Střední
Interní
1
Poškození dat v případě neoprávněné ho přístupu
Střední
Střední
Interní
1
54
2
Servery odbavovacího systému provozují vlastní domény, toto je nevhodný stav pro konfiguraci sítě společnosti. Je nezbytné provést oddělení těchto serverů od běžné sítě a nebo zajistit jejich integraci do domény společnosti. K těmto serverům má plný přístup externí dodavatel a pracovníkům IT není plně znám stav těchto serverů. Tyto servery jsou tedy významným bezpečnostním rizikem. Otázkou je implementace WiFi sítě jenž může být hrozbou pro útok na IT systém společnosti Není zřejmá konfigurace v jednotlivých vozech. Závazná dokumentace nebyla dodána.
Riziko poruch, malé riziko zneužití
Střední
Částečně řešeno jinými opatřeními, Významné nezbytnost provozní dokumentace systému
Riziko poruch, malé riziko zneužití
Nízké
Významné
Možnost dohledání případných škod je nulová neboť veškeré logy systému nejsou systematicky vyhodnocovány a navíc politika logování je nastavena tak že po krátké době jsou logy systému přepisovány. Některé Logy v systému LINUX nejsou vytvářen vůbec.
Není možná účinná predikce poruch, dlouhé doba odstraňování poruch. Nemožnost dohledat zneužití sítě
Střední
Významné Interní opatření
Chybí segmentace sítě, v oblasti perimetru je v tuto chvíli několik adresných rozsahů, a i když L2 infrastrukturu tvoří přepínače, všechny adresní rozsahy se nacházejí v jedné L2 doméně. Kdokoliv, kdo má přístup k jakémukoliv Ethernet portu, může na síti odposlouchávat všechny adresné rozsahy a na základě zjištěných informací provést různé akce (od zjišťování informací různého druhy útoků např. man-in the-middle).
Bezpečnostní rizika, chyby na sítí a neefektivní zatížení sítě
Vysoké
55
Střední
Provozní dokumentace
Desítky tisíc za nákup zařízení a technická podpora při instalaci
1
1
1
1
Jednotlivé logické segmenty v oblasti perimetru nejsou rozděleny do zón a přístup k nim tedy není řízený. Elektronický odbavovací systém : Aplikační server není chráněn firewallem a používá zbytečně moc rozhraní. K serverům není řízen přístup z ostatních segmentů. Nedostatečná dokumentace serveru Linux, Vzhledem k tomu, ze služba je spravována třetí stranou (tzv. outsourcing), chybí k serveru uživatelská dokumentace dodaná administrátorem pro účely přehledu o běžícím systému a jeho službám, účtech a jejich oprávnění. Nedostatečné podklady požadavků elektronického odbavovacího systému na síťovou infrastrukturu (nároky na propustnost – současné a budoucí s ohledem na možné rozšíření systému, popis systému – schéma použitých síťových a komunikačních protokolů)
Nízké
Lze řešit souběžně s Významná předchozím bodem
1
Bezpečnostní rizika
Nízké
Lze řešit souběžně s Významná předchozím bodem
2
Významná bezpečnostní rizika
Střední
Významná
Servisní smlouva na správu systému
1!
Riziko poruch a zmařených následných investic
Střední
Střední
Nelze určit bez dokumentace
2
Bezpečnostní rizika
56
5. ZÁVĚR 5.1 Manažerské shrnutí Stav informačních technologií v Dopravním podniku nelze označit za kritický. V rámci posuzování jednotlivých oblastí byla zjištěna celá řada vážných nedostatků, ale stejně tak jsou v oddělení OIT oblasti, které musíme označit za velmi dobré (Správa licencí, tiskové řešení apod.) Opustíme-li vlastní zadání, které se orientuje na provoz IT technologií, a nahlédneme-li o úroveň výš, musíme bohužel konstatovat, že zcela chybí dlouhodobá koncepce rozvoje IT technologií a procesní postupy/návyky řízení provozu informačních technologií. Většina nedostatků je právě důsledkem absence plánu a procesů. Důsledkem pak je také skutečnost, že odstranění většiny nedostatků nebude vyžadovat přímé investice, ale změny v procesech nebo konfiguracích stávajících technologií. Nedostatky můžeme obecně shrnout do následujících témat: -
Bezpečnost IT technologií, často je rozumně vytvořené technické řešení zcela degradováno nedůsledností ve správě hesel apod.
-
Organizace provozu, od vlastního uspořádání v serverové místnosti, přes absenci řady provozních dokumentů a končící nahodilou profilaxí.
-
Smluvní zajištění provozu od dodavatelů. Největšími nedostatky jsou smluvní nepokrytí správy firewallu a absence podpory operačního systému serverů (autorizovaný partner Microsoft) a sítě.
-
Zcela nedostatečné zálohování, v kombinaci s nedostatky v práci se zálohami a absencí plánů obnovy.
5.2 Reflexe
Provedení bezpečnostního audit v Dopravním podniku nebylo typickou ukázkou práce na certifikaci systému nebo na její kontrole. Návody a postupy uvedené v presentovaných normách jsou však uplatnitelné i jednotlivě a odděleně od procesu certifikace či analýzy souladu s normou. V případě Dopravního podniku šlo o plnění konkrétního zadání, které nezahrnovalo ani zmínku o řízení bezpečnosti. Nicméně hledání příčiny vzniku zákazníkových potíží někdy vede k odhalení systémové chyby nebo potřeby zavedení procesu řízení bezpečnosti nebo řízení informací obecně. I zde šlo o klasický případ, v praxi se tak často opakující, kdy řešení konkrétních problémů ukáže na
57
bolavá místa a nastaví správný směr vývoje v oblasti bezpečnosti a tvorby IS. Stejně tak v tomto případě směřovala mnohá doporučení k úpravě procesů, ne pouze k zalátání bezpečnostních děr. Požadavek na analýzu vznikl, jako potřeba ochrany investic při zavádění jednoho z výše uvedených systémů. Tento audit byl pouze doplňkem ke konkrétnímu zadání zákazníka – oponentury jiného projektu. Obě zakázky nakonec měly své úspěšné dokončení. Ochrana investic byla efektivně zvládnuta. Co je ale v tomto případě důležitější, je fakt, že Dopravní podnik začal na potřebu řízení bezpečnosti nahlížet jako nutnost pro fungování organizace. To je ten první správný krok, který dlouhodobě vede k úsporám a benefitům konkurenční výhody – bezpečné práce s informacemi a bezvadného IS.
Literatura Přílohy Analýza pravidel na Linux Serveru Analýza výpisu získaného příkazem iptables –L.
Pravidla firewallu: Chain FORWARD (policy DROP) - firewall je nastaven jako stavový (v řetězcích povoluje sestavená spojení, resp. hlídá TCP flagy) - default policy je DROP - je zapnuto logování ne některé události - chain FORWARD obsahuje další chainy
- na rozhraní eth0 (outside)
- povoluje přístup na vzdálenou plochu pro WIN z nížeuvedených adres a sítí: ACCEPT
tcp -- 213.235.101.40
NET-1_IP-252
ACCEPT
tcp -- 113-client2.wms.cz NET-1_IP-252
ACCEPT
tcp -- 85.193.10.8
ACCEPT
tcp -- 193.165.203.0/24
NET-1_IP-252 NET-1_IP-252
58
tcp dpt:3389 tcp dpt:3389 tcp dpt:3389 tcp dpt:3389
ACCEPT
tcp -- LLmikroelekt.worldonline.cz NET-1_IP-252
tcp dpt:3389
- zahazuje pakety z privátních rozsahů (dle RFC 1918) a všechno ostatní
- na rozhraní eth1 (inside) - nepropustí komunikaci do sítě 192.168.1.0/24 - povolí sestavená spojení (dle TCP flagu) - povoluje klientské DNS, jak UDP tak TCP - zakazuje “Microsoftí porty související se službou NETBIOS“ v řetězci REJECT
Chain INPUT Pro filtraci trafficu, který je určen pro Linux Server nebo odchází z Linux Server jsou definovány chains (řetězce) INPUT resp. OUTPUT.
Na outside rozhraní ve směru in je povoleno: - ssh a port 81 z adresy inet6.campbell.cz - jiné služby odkudkoliv (ping, ftp, smtp, http/s, dns - sestavené spojení
Na inside rozhraní ve směru out je povoleno: - udp bootp (tipuji, že jde o DHCP) - sestavené spojení - tcp přístup na squid port (mělo by to být 3128) - tcp přístup smtp, - dálší přístup: ping, ftp, smtp, dns (tcp, udp), http/s, pop3/s, imap/s, ntp, Microsoft SMB,
59
