Řízení rizik v modelu SPSPR

Řízení rizik v modelu SPSPR Jan Guzanič Katedra systémové analýzy VŠE [email protected]

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:2-2002. 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 IT procesy

Nepopisuje proces

IT bezpečnostní kontroly

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

ITIL

ISO 17999

Bezpečnost Vývoj

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

SYSTÉMOVÁ INTEGRACE 4/2004

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


Ří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

Třída rizik

Strategie

Rizika zadání procesu

Procesy Informatické služby Informatické procesy Informatické zdroje

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 SYSTÉMOVÁ INTEGRACE 4/2004

27

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

3. 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) Věnovat zvýšenou pozornost řízení zdrojů (ev. zvážit ustanovení pozice CRO – Chief resource officer

Organizace nebude přizpůsobena přejít na model SPSPR

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

28

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)



3.2 Rizika definice služby (SLA) Riziko


Informatické služby nebudou navrženy tak, aby optimálně podporovaly navržený proces

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.

Nebude vhodně navrženo SLA Cena služby bude přesahovat přínosy procesu

3.3 Rizika výběru poskytovatele služby Riziko


Na CRO resp. CIO by měly být vrcholovým Nebude optimální granularita vedením kladeny požadavky ohledně outsourcovaných řešení a přiřazeny outsourcovaných služeb, zejména v oblastech odpovědnosti flexibilita, škálovatelnost, interoperabilita. Rovněž tak musí být vznesen požadavek na jednoznačné přiřazení odpovědností. Nebude vhodně zvolena Rozhodnutí o strategii využití outsourcingu úroveň/strategie outsourcingu musí být učiněno na vrcholové úrovni. Nebude efektivně prováděno řízení (a integrace) zdrojů ( na úrovních x- Věnovat zvýšenou pozornost řízení zdrojů x-S-P-R v závislosti na úrovni dle (ev. zvážit ustanovení pozice CRO – Chief typu outsourcingu ) resource officer) 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 SYSTÉMOVÁ INTEGRACE 4/2004

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

Jan Guzanič

3.4 Rizika řízení informatických procesů Riziko


Technologická architektura bude nevhodně řízena

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

Nebudou správně stanoveny či prováděny informatické procesy, a to i mezi organizacemi

3.5 Rizika řízení informatických zdrojů Riziko


Nebude efektivně zajištěna správa informatických zdrojů

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).

Nebude zajištěn rozvoj informatických zdrojů

Nebudou efektivně řízeny náklady

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

Změny ke zvážení při aplikaci modelu SPSPR a využití informatických služeb

Bezpečnostní politika 3.1

30

Bezpečnostní Dokument informační politiky by měl brát v úvahu rozšíření politika spolupráce s třetími stranami a z toho plynoucí rizikové oblasti. SYSTÉMOVÁ INTEGRACE 4/2004


Čá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. 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.

Klasifikace a řízení aktiv 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

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í Hlášení bezpečnostních incidentů a nesprávné incidenty a nesprávnou funkčnosti musí probíhat i s třetími stranami. funkčnost 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.

Fyzická bezpečnost a bezpečnost prostředí 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



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

8.3

Ochrana proti škodlivému Měla by být součástí ujednání s třetími stranami, software 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.


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.

33

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

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ů

34

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.

Uživatelé třetích stran by měly být odpovědní za použití hesla.



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 V případě používání mobilních zařízení třetími zařízení a práce na dálku 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 Měly by být vzneseny bezpečnostní požadavky na systém 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

Jan Guzanič

10.2 Bezpečnost v aplikačních Zadavatel by měl vznést na třetí stranu systémech 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. 10.3 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.

10.4 Bezpečnost systému souborů

Na třetí strany by měly být vzneseny požadavky ohledně ochrany testovacích dat.

10.5 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



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).

12.2 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é Fyzická Oblast Bezpečnostní Organizace Klasifikace a bezpečnost ISO19977 /politika bezpečnosti řízení aktiv Personální a Úroveň bezpečnost bezpečnost modelu prostředí Strategické řízení Procesy hlavní Služby informatické Procesy informatické

X

X X

X

X X

Zdroje informatické


X X

X X

X X X

37

Jan Guzanič

Řízení Oblast ISO19977 / provozu a komunikací Úroveň modelu Strategické řízení Procesy hlavní Služby informatické Procesy informatické Zdroje informatické

Řízení přístupu

Vývoj a údržba systému

Řízení Soulad – kontinuity Compliance obchodu

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

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 ISO17799. Za klíčové oblasti považuji zejména:

- Zapojení třetích stran do infrastruktury informační bezpečnosti -

38

Definice požadavků v bezpečnostní politice a jejich komunikace třetím stranám



-

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, 2004


39

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 80-247-0620-2 [Vorisek, Feuerlich 2004] Voříšek Jiří, Feuerlicht George: Pre-requisities for successful adoption of the ASP model by user organization, University of Economics Prague, 2004

40


Řízení rizik v modelu SPSPR

Recommend Documents