Řízení rizik v modelu SPSPR

Transkript

1 Řízení rizik v modelu SPSPR Jan Guzanič Katedra systémové analýzy VŠE guzanic@medicafilter.cz Abstrakt: V práci byl podán náhled na řízení rizik podnikové informatiky při použití modelu SPSPR. V důsledku využití služeb poskytovatelů aplikačních služeb (či jiných úrovních outsourcingu) dochází k nárůstu komplexity systému samotného a systému řízení rizik.. V provedené identifikaci rizik a protiopatření v oblastech řízení obchodních rizik a řízení rizik informačních systémů lze nalézt náhled na to, jak daným změnám čelit. Tento náhled je pak shrnut do doporučení pro strategie řízení obchodních rizik a řízení rizik informačních systémů. Klíčová slova: řízení rizik, řízení informačních systémů, SPSPR, rizika, kontroly, outsourcing 1. Úvod 1.1 Tradiční řízení rizik podnikové informatiky (IS/IT) V současné době se pro řízení provozu podnikové informatiky uplatňuje řada norem a metodik. Za významné metodologie lze považovat: ITIL a COBIT, za významné normy lze považovat ISO 17999, resp. BS7799: V následující tabulce jsou zachyceny oblasti, pro které jsou dané metody určeny. Tabulka byla zpracována na základě studie použitelnosti těchto metod společnosti PWC [PWC, 2002]. Metoda/nástroj Silné stránky Slabé stránky Vhodné použití COBIT IT kontroly IT metriky Nepopisuje proces ITIL IT procesy Bezpečnost ISO IT bezpečnostní kontroly Vývoj Nepopisuje proces Prověrka stavu Definice metrik Zlepšení procesů a kontrol Definice struktur Prověrka stavu Zlepšení bezpečnostních a provozních kontrol Z hlediska řízení rizik je nejvýznamnější norma ISO19977, která se dotýká oblastí řízení rizik bezpečnosti a provozu IS/ICT. 1.2 Změna pohledu na řízení podnikové informatiky z pohledu modelu SPSPR Tradiční náhledy na řízení podnikové informatiky neuvažují v hloubi situaci, kdy jsou informatické služby pořizovány kombinací pořízení od třetích stran a pořízení ve vlastní režii, přičemž dochází k růstu komplexity vztahů v rámci systému podnikové informatiky (a mezi dalšími stranami). 25

2 Jan Guzanič Zjasnit náhled na situaci kdy jsou v podniku využívány informatické služby (kombinace externích a interních, na různých úrovních) můžeme pomocí modelu SPSPR dle [Vorisek,2003]. Jeho silnou stránkou pro zajištění interoperability mezi různými poskytovateli informatických služeb je jeho čtvrtá úroveň (Informatické procesy), která zajišťuje kompatibilitu s dosavadními náhledy na řízení podnikové informatiky (kompatibilita např. s Cobit, ITIL, požadavky ISO19977, atd.). Rostoucí komplexita vztahů obecně znesnadňuje úlohu řízení systému. Pro takovou situaci se jeví vhodné použít holistického modelu, který akcentuje vzájemnou souvislost všech prvků v komplexním systému. Jinými slovy, každá část systému je provázána se všemi ostatními a reakce v kterékoliv části se může přenést do libovolné jiné části (např. malý nedostatek v zdánlivě bezvýznamné servisní smlouvě může vést k přerušení podnikání na významnou dobu což způsobí těžké finanční ztráty). 1.3 Řízení rizik podnikové informatiky z pohledu modelu SPSPR V této části jsem nastínil model holistického řízení rizik při použití modelu SPSPR. 26

3 Řízení rizik v modelu SPSPR Model má tři úrovně. Vespod obrázku jsou znázorněna rizika v rámci systému řízení. Tyto rizika se mohou uplatňovat na jakékoliv úrovni řízení (SPSPR), resp. Lze je nalézt na všech úrovních řízení. Tato rizika jsou řízena ( zpracovávána ) prostřednictvím procesu řízení rizik. Model procesu řízení rizika je znázorněn uprostřed obrázku. Tento proces je kontinuální, pořadí jeho fází je znázorněno šipkami. Tímto modelem mají být řízeny individuální rizika či třídy rizik. V poslední (horní) části je zachycen model řízení SPSPR prolnutý s modelem řízení rizik. Vzhledem k vrstevnosti modelu řízení SPSPR je potřeba, aby procesy řízení rizik probíhaly na všech úrovních toto je znázorněno pěti obručemi. Každá z nich reprezentuje model procesu řízení rizik na dané úrovni. Vzhledem k tomu, že rizika lze těžko přiřadit na určitou úroveň řízení, musí se i proces řízení rizik odehrávat na všech úrovních, mezi všemi úrovněmi toto je znázorněno sklonem obručí. Model je modelem komplexního systému. Jednotlivé fáze procesu řízení rizik mohou interagovat s libovolnými jinými fázemi na libovolné jiné úrovni modelu řízení. Tato komplexita pak činí obtížnější úlohu řízení rizik. V praktickém důsledku to znamená větší nároky na integraci řízení rizik na jednotlivých úrovních (a to i mezi organizacemi). Pro plnění těchto požadavků je třeba alokovat dodatečné zdroje v personálních oblastech počínaje (CIO, Risk Manager, CRO). Tento model byl inspirován holistickým modelem řízení rizik podle [HIGUERA, 1996]. Klasickými oblastmi aplikace řízení rizik při řízení rizik podnikové informatiky jsou například: řízení obchodních rizik, řízení bezpečnostních rizik, řízení provozních rizik, řízení rizik projektu, řízení rizik vývoje SW a další. Dále se budu v této práci zabývat oblastmi řízení obchodních rizik a řízení bezpečnostních rizik. 2. Typy (třídy) rizik plynoucích z aplikace modelu SPSPR V této části budu identifikovat typy rizik plynoucích z pohledu aplikace modelu SPSPR. Vzhledem k tomu, aby řízení rizik bylo kompatibilní s modelem SPSPR, navrhuji aby třídy jednotlivých rizik odpovídaly dané úrovni modelu. Konkrétně by se třídy rizik na jednotlivých úrovních daly identifikovat jako: Úroveň modelu SPSPR Strategie Procesy Informatické služby Informatické procesy Informatické zdroje Třída rizik Rizika zadání procesu Rizika definice služby (SLA) Rizika výběru poskytovatele služby Rizika řízení informatických procesů Rizika řízení informatických zdrojů Následná identifikace rizik, resp.rizikových oblastí byla provedena ve dvou oblastech. - Identifikace obchodních (business) rizik plynoucích z použití modelu řízení podnikové informatiky. Jednotlivá rizika na daných úrovních řízení byla identifikována na základě rozboru dostupných informací o modelu SPSPR a 27

4 Jan Guzanič jeho použití viz. Literatura [Vorisek,2003],[Vorisek, Feuerlich 2004]. Rovněž na základě literatury a vlastních zkušeností jsem se pokusil navrhnout základní protiopatření/kontroly, které by měly být vzaty v úvahu při úvahách o použití modelu SPSPR a dodávkách informatických služeb. - Identifikace oblastí ve kterých může dojít vlivem použití modelu SPSPR ke změnám. Rizikové oblasti jsou identifikována ve struktuře dle ISO17799 na základě rozboru dostupných informací o modelu SPSPR a na základě použití znalostí získaných v praxi (Best practices v řízení rizik IS dle ISO1799). Identifikované body jsou pojímány jako témata k diskusi, resp. jako doporučení dobré praxe odpovídající ISO Rizika obchodní (business) a protiopatření Tato část obsahuje identifikaci základních rizik při řízení podnikové informatiky dle modelu SPSPR. Rizika budou členěna dle výše identifikovaných tříd rizik příslušející dané úrovni modelu. Následující části tabulkovým způsobem sumarizují rizikové oblasti a příslušející kontroly resp. Protiopatření. 3.1 Rizika zadání procesu Riziko Kontroly/ protiopatření Nebudou provázány obchodní strategie a strategie ICT se strategií Definovat strategie souběžně (z obchodní a řízení zdrojů(sourcing) ICT odvodit sourcing) Organizace nebude přizpůsobena přejít na model SPSPR Věnovat zvýšenou pozornost řízení zdrojů (ev. zvážit ustanovení pozice CRO Chief resource officer Ze strategické úrovně propagovat směrem dolů filosofii modelu SPSPR a strategii využívání aplikačních služeb. Změnový program může být vhodný, rovněž jako pilotní projekt s edukačními prvky. Stanovit a používat metriky. Neprovedení Nebudou stanoveny a používány tohoto požadavku je popřením filosofie metriky na aplikovatelných úrovních procesního řízení, čímž se i aplikace SPSPR doporučených v modelu modelu stane chaotickou. Nebudou vytvořeny a udrženy potřebné zdroje Je odpovědností vrcholového managementu zajistit, aby byly vytvořeny a udrženy potřebné zdroje. Vzhledem k náročnosti úlohy udržení zdrojů může být řešením ustanovení funkce CRO (Chief resource officer) 28

5 Řízení rizik v modelu SPSPR 3.2 Rizika definice služby (SLA) Riziko Informatické služby nebudou navrženy tak, aby optimálně podporovaly navržený proces Nebude vhodně navrženo SLA Cena služby bude přesahovat přínosy procesu Kontroly/ protiopatření Odpovědní pracovníci musejí být školeni jak v oblasti návrhu procesů, tak definování informatických požadavků na jejich podporu. Odpovědní pracovníci musejí být školeni v tvorbě SLA. Vhodným zdrojem parametrů SLA je např. ([Vorisek,2003], kap. 24) Navržené služby by měly projít kontrolou, zdali jejich rozsah, kvalita a přínos odpovídá ceně a zda je cena nižší než přínosy procesu. 3.3 Rizika výběru poskytovatele služby Riziko Nebude optimální granularita outsourcovaných řešení a přiřazeny odpovědnosti Nebude vhodně zvolena úroveň/strategie outsourcingu Nebude efektivně prováděno řízení (a integrace) zdrojů ( na úrovních x- x-s-p-r v závislosti na úrovni dle typu outsourcingu ) Nebude vhodně navržena technologická architektura Nebude správně proveden informatický projekt, skrze nějž se služba implementuje Služby nebudou efektivně integrovány Nebude efektivně proveden nákup služeb Kontroly/ protiopatření Na CRO resp. CIO by měly být vrcholovým vedením kladeny požadavky ohledně outsourcovaných služeb, zejména v oblastech flexibilita, škálovatelnost, interoperabilita. Rovněž tak musí být vznesen požadavek na jednoznačné přiřazení odpovědností. Rozhodnutí o strategii využití outsourcingu musí být učiněno na vrcholové úrovni. Věnovat zvýšenou pozornost řízení zdrojů (ev. zvážit ustanovení pozice CRO Chief resource officer) Rámcové požadavky na technologickou architekturu by měly být stanoveny vrcholovým vedením (za spolupráce CIO, CRO). Vhodně zvolená technologická architektura může výrazně zjednodušit integraci služeb a snížit náklady. Použít některou z metodologií řízení projektu a jeho rizik. Podmínky pro integraci služeb se musí vytvořit předem např. ve strategii outsourcingu. Na jednotlivých dodavatelích pak musí být tyto požadavky vyžadovány. Osobnost CIO resp. CRO musí být dostatečně silná na prosazení těchto požadavků do praxe. Nákupy by měly probíhat pomocí výběrových řízení dle SLA. 29

6 Jan Guzanič 3.4 Rizika řízení informatických procesů Riziko Technologická architektura bude nevhodně řízena Nebudou správně stanoveny či prováděny informatické procesy, a to i mezi organizacemi Kontroly/ protiopatření Strategické řízení musí stanovit požadavky na řízení technologické architektury a zajistit zdroje pro jejich řízení Strategické řízení musí stanovit požadavky na informatické procesy (i mezi organizacemi). Vhodné nástroje lze nejít mezi ISO17799, COBIT, ITIL 3.5 Rizika řízení informatických zdrojů Riziko Nebude efektivně zajištěna správa informatických zdrojů Nebude zajištěn rozvoj informatických zdrojů Nebudou efektivně řízeny náklady Kontroly/ protiopatření Strategické řízení musí stanovit požadavky na správu informatických zdrojů. Vhodné nástroje lze nejít mezi ISO17799, COBIT, ITIL V rámci definice SLA je třeba zvážit i budoucí požadavky na zdroje, zejména pokud lze očekávat velké odchylky v objemu procesu. Předpokladem je stanovení strategie outsourcingu a požadavků na technickou infrastrukturu. Doporučují se konzervativní nákupní strategie (follow). 4. Bezpečnostní rizika v oblastech dle ISO17799 Tato část obsahuje identifikace oblastí, ve kterých může dojít vlivem použití modelu SPSPR ke změnám. Rizikové oblasti jsou identifikována ve struktuře dle ISO17799 na základě rozboru dostupných informací o modelu SPSPR a na základě použití znalostí získaných v praxi (Best practices v řízení rizik IS dle ISO17799). Identifikované body jsou pojímány jako témata k diskuzi, resp. jako doporučení dobré praxe odpovídající ISO Dále jsem pak provedl expertním odhadem přiřazení jednotlivých oblastí rizik na úrovně modelu SPSPR, kde budou nejvíce aplikovatelné (ve skutečnosti se díky komplexnosti systému vyskytují na všech úrovních). 4.1 Ovlivnění systému řízení bezpečnosti dle ISO17799 Tabulka: Ovlivnění systému řízení bezpečnosti dle ISO17799 aplikací modelu SPSPR Standard Bezpečnostní politika 3.1 Bezpečnostní politika Změny ke zvážení při aplikaci modelu SPSPR a využití informatických služeb Dokument informační politiky by měl brát v úvahu rozšíření spolupráce s třetími stranami a z toho plynoucí rizikové oblasti. 30

7 Řízení rizik v modelu SPSPR Část dokumentu informační politiky by měla být komunikována třetím stranám, které se podílejí na spolupráci. Rovněž by měly být třetím stranám na principu potřeby vědět sděleny příslušné části bezpečnostní politiky a příslušející dokumentace. Pokud se jeví vhodné, zapojit třetí strany do diskuse ohledně příslušných oblastí. Změny v bezpečnostní politice týkajících se třetích stran by měly být oznámeny i jim Organizace bezpečnosti 4.1 Infrastruktura informační bezpečnosti Zvážit, zda by členem fóra informační bezpečnosti neměl být i některý zástupce třetích stran (významně ovlivňující systém bezpečnosti) Koordinace bezpečnosti musí rozšířit pole své působnosti i na třetí strany Měla by být jasně stanoveny hranice a přidělení odpovědnosti za informační bezpečnost. Aby bylo možno snadno přidělit odpovědnost za incident jedné či druhé organizaci. Pokud je vhodné, měly by být i třetí strany součástí autorizačního procesu pro zpracování informací. Do infrastruktury bezpečnosti by měl být zapojen CRO (Chief resource officer) 4.2 Zabezpečení přístupu třetích stran V případě, že do libovolné části systému vstupuje krom třetí strany(dodavatel) ještě další subjekt, měly by být i na něj kladeny bezpečnostní požadavky. 4.3 Outsourcing Požadavky na bezpečnost by měly být součástí smluv s třetími stranami. Klasifikace a řízení aktiv Důležité je, aby proces stanovení a vyžadování bezpečnostních požadavků na třetí strany byl pečlivě kontrolován a řízen Požadavky na bezpečnost třetích stran by měly odpovídat bezpečnostní informační politice. 5.1 Přiřaditelnost aktiv Součástí inventoráře aktiv by měla být i aktiva vlastněná organizací a vyskytující se u třetích stran, tak i aktiva třetích stran vyskytujících se v organizaci. 31

8 Jan Guzanič 5.2 Klasifikace informací Směrnice pro klasifikaci informací by měly brát v úvahu specifika vzniklé v důsledku vztahů s třetími stranami. Pokud jsou používány procedury na základě označení aktiv a pro zacházení na základě tohoto označení, měly by k nim být zavázány a s nimi obeznámeny třetí strany. Personální bezpečnost 6.1 Bezpečnost v popisu práce Pokud je zpracování citlivých informací prováděno třetími stranami, mělo by být získána osobní reference na osoby provádějící práci s těmito informacemi Požadavek na podepsání dohody o důvěrnosti se zaměstnanci třetích stran. 6.2 Trénink uživatelů Je vhodné, aby se zvážila účast zaměstnanců třetích stran na bezpečnostních školeních. 6.3 Reakce na bezpečnostní incidenty a nesprávnou funkčnost Hlášení bezpečnostních incidentů a nesprávné funkčnosti musí probíhat i s třetími stranami. Fyzická bezpečnost a bezpečnost prostředí Učení se z incidentů může probíhat ve spolupráci s třetími stranami. Pokud je vhodné, měla by být zajištěna možnost disciplinárního procesu i se zaměstnanci třetích stran. Tyto třetí organizace by se měly podílet jak na disciplinárním procesu, tak se i smluvně zavázat aplikovat sankce na daného zaměstnance. 7.1 Bezpečné prostory Měly by být zváženy požadavky na fyzickou bezpečnost třetích stran. 7.2 Bezpečnost vybavení Je vhodné aby obzvláště citlivé vybavení u třetích stran bylo pod zvýšenou fyzickou ochranou. Kabeláž u třetích stran by měla být zabezpečena. Třetí strany by měly udržovat seznam osob, které se podíleli na údržbě vybavení (resp. měli přístup). 32

9 Řízení rizik v modelu SPSPR Třetí strany by měly zabezpečit fyzickou ochranu, pokud je vybavení přesunuto mimo jejich místo působení. Třetí strany by měly bezpečně likvidovat zařízení. 7.3 Obecné kontroly Majetkem společnosti uloženým u třetích stran by neměl být stěhován bez předchozího schválení. Auditování doporučeno. Řízení provozu a komunikací 8.1 Provozní procedury a odpovědnost U třetích stran kde je vhodné je třeba zajistit, aby provozní procedury probíhaly dle požadavků odvozených z informační bezpečnostní politiky. Je vhodné, aby procedury řízení incidentů byly navrženy skrze hranice organizace s třetími stranami, u kterých je to potřebné. 8.2 Plánování systému a akceptace V případě, že lze předpokládat výkyvy v objemu obchodních procesů, je vhodné mít s třetí stranou zajištěno ujednání o řízení kapacit. 8.3 Ochrana proti škodlivému software Měla by být součástí ujednání s třetími stranami, stanovené oproti sankcím (recipročně). 8.4 Housekeeping Je vnitřní věcí třetí strany, poskytovatele. Zpravidla pokud bude mít více než minimální počet pracovníků, bude tyto činnosti ve vlastním zájmu vykonávat. 8.5 Správa sítě Vysoce riziková oblast. Pokud je správa a provoz sítě rozdělen mezi více subjektů, je vhodné koordinovat síťovou bezpečnost. Jako vhodné se jeví pravidelné technické prověrky, resp. penetrační testování. 8.6 Bezpečnost zacházení s médii Pokud jsou předávána média mezi stranami, měly by být stanoveny postupy pro jejich správu, až do likvidace. Měly by být ustanoveny procedury s třetími stranami pro zacházení s informacemi. 33

10 Jan Guzanič Dokumentace systémů poskytovaných třetími stranami by měla být bezpečně uložena, včetně kopií v jiné lokaci. Pro vhodnou záložní lokaci se mohou zvážit prostory vlastní organizace. Záložní dokumentace systémů třetích stran by měla být aktualizována v pravidelných intervalech, resp. při změně. 8.7 Výměna informací a software Ujednání o výměně informací a software by měla obsahovat požadavky na bezpečnost s ohledem na citlivost informací. Měly by být zváženy požadavky na média v transportu. Pokud jsou systémy od třetích stran používané pro elektronický obchod, měly by být vzneseny požadavky a sankce odpovídající významu a citlivosti systému. Pokud se jedná o systémy elektronického obchodu, měla by navíc být zvážena ochrana před specifickými riziky (jako fraudulence, falešné smlouvy, vyzrazení či modifikace informací). V případě elektronické pošty se jeví jako vhodné smluvně požadovat ochranu elektronické pošty (bezpečnost, spam, viry, relaying). Pokud jsou některé části systému od třetích stran veřejně přístupny, měly by být vybaveny odpovídajícími extra bezpečnostními opatřeními. Personálu třetích stran by se měl opakovaně vysvětlovat požadavek na důvěrnost. Řízení přístupu 9.1 Požadavky obchodu na řízení přístupu Třetí strany by měly být seznámeny s obchodními požadavky na přístup, které bude systém kontroly přístupu naplňovat. 9.2 Správá přístupu uživatelů Zvážit požadavky na správu přístupu uživatelů třetím stranám (registrace, správa privilegií, správa hesel, kontrola přístupových práv) 9.3 Odpovědnost uživatelů Uživatelé třetích stran by měly být odpovědní za použití hesla. 34

11 Řízení rizik v modelu SPSPR 9.4 Řízení přístupu k síti Měla by být vyžadována politika používání síťových služeb. Pokud je možno, měly by být použity vnucené cesty komunikace Je vhodné, aby externí spojení s třetími stranami byla autentikována. Kde je to vhodné, mělo by být zváženo oddělení sítí. Měla by být zajištěna a řízena bezpečnost sítě třetích stran (poskytovatelů). 9.5 Řízení přístupu k operačnímu systému Zvážit, zda nezvznést požadavky na třetí strany. 9.6 Řízení přístupu k aplikacím Vysoce riziková oblast. Přístup osob třetích stran by měl být povolován na základě jednotlivých obchodních požadavků (managementu resp. odpovědné osoby) konzistentními s politikou přístupu k informacím. V případě citlivých systémů zvážit, zda by z bezpečnostního hlediska nebylo vhodnější, aby běžely na izolovaných systémech (i přes možnosti úspor). 9.7 Monitorování přístupu a použití systému Na třetí stranu by měly být vzneseny požadavky na monitorování systému (pokud je vhodné). 9.8 Používání mobilních zařízení a práce na dálku V případě používání mobilních zařízení třetími stranami by měly být vzneseny specifické bezpečnostní požadavky. Vývoj a údržba systému 10.1 Bezpečnostní požadavky na systém Měly by být vzneseny bezpečnostní požadavky na systémy třetích stran. Třetí strany by měly vznést bezpečnostní požadavky na systém zákazníka (bez nichž by nešlo zajistit požadavky kladené zákazníkem). Zvážit, zda se třetí strany mají podílet na rizikové analýze. 35

12 Jan Guzanič 10.2 Bezpečnost v aplikačních systémech Zadavatel by měl vznést na třetí stranu požadavky na bezpečnost aplikací, zejména v oblastech kontroly dat, kontrol zpracování, autentikace zpráv (ochrana pře změněním), kontrola výstupních dat Kryptografické kontroly Na třetí strany by měly být vzneseny požadavky ohledně kryptografických kontrol, vyplývající z politiky použití kryptografických kontrol (šifrování, digitální podpis, nepopiratelnost, správa klíčů). Měly by být zváženy požadavky třetích stran na kryptografické kontroly u zákazníka Bezpečnost systému souborů Na třetí strany by měly být vzneseny požadavky ohledně ochrany testovacích dat Bezpečnost vývojového procesu a procesu podpory Požadavky na procedury kontroly změn by měly být součástí ujednání s třetími stranami. Pokud je součástí i instalace SW třetích stran na vybavení klienta, je třeba smluvně a procedurně zajistit ochranu před trojskými koňmi a zadními vrátky do systému. Pokud je outsourcován vývoj SW, je třeba aby krom obvyklých kontrol byly zváženy i požadavky na následující: licenční ujednání, ujednání v případě ukončení činnosti dodavatele, požadavky na kvalitu (SLA), požadavky na testování na trojské koně. Řízení kontinuity obchodu 11.1 Aspekty řízení kontinuity obchodu Zvážit, jakým způsobem ovlivní vztahy s třetími stranami požadavky na kontinuitu obchodu a její řízení. Zajistit, aby systémy třetích stran byly součástí analýzy dopadů. Musí být smluvně zajištěny požadavky vyplývající z plánu kontinuity, a to pod významnými sankcemi. Na testování plánů zachování kontinuity by se měly podílet i třetí strany (ev. mohou se podílet na formulaci některých částí). 36

13 Řízení rizik v modelu SPSPR Soulad Compliance 12.1 Soulad s právními požadavky Je třeba zvážit, zda se na třetí strany nepřenese odpovědnost stanovená zákonem. Je třeba zvážit, jak se změní situace v oblasti autorských práv. Je třeba smluvně zajistit požadavky na ochranu záznamů organizace (např. kvůli požadavkům zákona o účetnictví..). Je třeba zajistit plnění požadavků vyplývajících ze zákonů na ochranu osobních údajů. Smluvně je třeba zajistit požadavky na shromažďování evidence (zejména pokud se jedná o e-business) Revize bezpečnostní Je třeba zajistit kontroly souladu požadavků na politiky a technický soulad třetí strany s bezpečnostní politikou. Pokud je to vhodné, vznést na třetí strany požadavky ohledně testování technického souladu (povolení testování, postoupení auditních zpráv) 4.2 Rizikové oblasti ISO17799 dle úrovní modelu SPSPR Tato část obsahuje přiřazení rizik dle ISO17799 na úrovně modelu SPSPR, kde by těmto oblastem měl být dán zvýšený význam. Přiřazení jsem provedl expertním odhadem, avšak pouze na teoretické úrovni. Tabulka: přiřazení jednotlivých oblastí rizik dle ISO19977 na úrovně modelu SPSPR, kde budou nejvíce aplikovatelné Oblast Bezpečnostní ISO19977 / politika Úroveň modelu Organizace bezpečnosti Strategické řízení X X Procesy hlavní Klasifikace a řízení aktiv Personální a bezpečnost Fyzická bezpečnost bezpečnost prostředí Služby informatické X X X X X Procesy informatické X X X X Zdroje informatické X X 37

14 Jan Guzanič Oblast Řízení ISO19977 / provozu a Úroveň komunikací modelu Řízení přístupu Vývoj a údržba systému Řízení kontinuity obchodu Soulad Compliance Strategické řízení X X Procesy hlavní X X X Služby informatické X X X X X Procesy informatické X X X X X Zdroje informatické X X 5. Návrh strategie řízení rizik Na obecné úrovni lze říci, že při aplikaci modelu SPSPR a využití služeb ASP dojde k růstu komplexity řízení rizik, jak je znázorněno v holistickém modelu řízení rizik. Z dané práce se dají vyvodit doporučení pro tvorbu strategie v oblastech řízení obchodních rizik a řízení bezpečnostních rizik. Tato doporučení jsou implikací doporučení o zaměření sil na eliminaci rizik zveřejněného v článku IT Doesn't Matter [Carr, 2003]. 5.1 Strategie pro řízení obchodních rizik Jednotlivá doporučení, resp. body ke zvážení jsou uvedeny v části 3 - Rizika obchodní (business) a protiopatření. Za klíčové oblasti považuji zejména: - Provázání obchodní a ICT strategie se strategií řízení zdrojů (sourcing) - Zralost organizace pro použití modelu SPSPR, procesního řízení a správného použití metrik - Získání a udržení dodavatelů - Vhodné navržení informatických služeb - Správné použití SLA - Návrh a integrace technologické architektury a služeb - Stanovení a provádění informatických procesů napříč organizacemi - Efektivní správa informatických zdrojů a finančních prostředků 5.2 Strategie pro řízení bezpečnostních rizik Jednotlivá doporučení, resp. body ke zvážení jsou uvedeny v části 4 - Bezpečnostní rizika v oblastech dle ISO Za klíčové oblasti považuji zejména: - Zapojení třetích stran do infrastruktury informační bezpečnosti - Definice požadavků v bezpečnostní politice a jejich komunikace třetím stranám 38

15 Řízení rizik v modelu SPSPR - Jednoznačné stanovení provozních procedur a odpovědností s třetími stranami - Stanovení požadavků na řízení přístupu - Stanovení bezpečnostních požadavků již při definici služby a zapracování těchto do SLA - Zvážit jakým způsobem se mění situace v oblasti regulované předpisy - Aktivní spolupráce při řízení bezpečnosti s třetími stranami, kooperace, participace 6. Závěr V práci byl podán náhled na řízení rizik podnikové informatiky při použití modelu SPSPR, který umožňuje využití aplikačních služeb. V důsledku využití služeb poskytovatelů aplikačních služeb (či jiných úrovních outsourcingu) dochází k nárůstu komplexity systému samotného a systému řízení rizik. Toto je třeba vzít v úvahu pro řízení rizik v příslušných oblastech, kde dochází k posunu těžiště zájmu směrem ke vztahům s třetími stranami. V provedené identifikaci rizik a protiopatření v oblastech řízení obchodních rizik a řízení rizik informačních systémů lze nalézt náhled na to, jak daným změnám čelit. Tento náhled je pak shrnut v závěru do doporučení pro strategie řízení obchodních rizik a řízení rizik informačních systémů. 7. Summary The work provides insight into information risk management when applying model SPSPR, which enables the use of application services. The impact of using the services of application services providers (or other levels of outsourcing) is the growing complexity of system itself and the system of risk management. This has to be applied for the praxis of risk management in appropriate areas. The issues of third party relationship are becoming more important. In provided risk areas identification and countermeasures selection in areas of business risk management and information risk management, the insight how to face changes can be found. This insight is finally transformed into recommendations covering the areas of business risk management and information security management. As a part of this work, model of holistic risk management in SPSPR model is provided in order to get better insight into turbulent complexity of issues covered in the work later. Literatura: [Carr, 2003] Carr, N.G.: IT Doesn t Matter, Harvard Business Review, Vol. 81, No. 5, May 2003 [HIGUERA, 1996] Higuera, Ronald P.,Haimes Yacov Y.: Software Risk Management, Carnegie Mellon University Software Engineering Institute,1996 [ISO 19977] Code of practice for Information Security Management, ISO IEC 17799:2002 [PWC, 2002] Pricewaterhousecoopers : Cobit, Itil and ISO17799, Pricewaterhousecoopers Global risk management solutions,

16 Jan Guzanič [VER] Verisign 2004 White paper Effective Strategies for Risk Management, Verisign, 2004 [Vorisek,2003] Voříšek Jiří, Pavelka J.,Vít M.: Apliakční služby IS/ICT formou ASP Proč a jak pronajímat informatické služby, Grada Publishing, Praha 2003, ISBN [Vorisek, Feuerlich 2004] Voříšek Jiří, Feuerlicht George: Pre-requisities for successful adoption of the ASP model by user organization, University of Economics Prague,