Audit kvality služby navržené podle ITIL V3 pomocí CobiT 4.1

Úvod

V této práci se zaměřuji na provedení auditu IT služby, která je součástí informačního systému z průmyslově právní oblasti. Služba zajišťuje sběr dat z rejstříků patentových úřadů a předává je informačnímu systému pro další zpracování. Služba, její realizace i provoz byly navrženy dle procesního rámce ITIL V3.

K provedení auditu služby, zhodnocení její kvality i začlenění do celého informačního systém použiji jak procesní rámec ITIL, tak i Cobit. Aby mohly být výsledky jednotlivých metodik lépe hodnoceny, použiji jejich vzájemné mapování.

Popis služby a její začlenění v rámci IS

Jedná se o službu přijímající požadavky na poskytnutí informací o průmyslovém právu. Průmyslové právo je určeno několika atributy, se kterými je vždy zaneseno do rejstříku těchto práv v každé zemi. Jelikož průmyslové právo na mezinárodním poli vychází z mezinárodních dohod o průmyslových právech, obsahují i rejstříky těchto práv v jednotlivých zemích stejné údaje a struktura získávaných dat je tedy zpravidla shodná nebo alespoň velmi podobná.

Služba přijímá požadavek na zjištění informací o průmyslovém právu. Tento požadavek obsahuje určení země, kde má být průmyslové právo zjišťováno, druh průmyslového práva a číslo registrace průmyslového práva. Mezi druhy průmyslových práv rozlišuje služba patent, užitný a průmyslový vzor a ochrannou známku. Každé průmyslové právo je v daném rejstříku vedeno pod unikátním číselným označením. Tyto tři informace jsou dostačující, aby služba mohla jednoznačně v rejstříku dané právo identifikovat a získat o něm podrobné informace. Poté co služba požadované informace získá, předává je v definovaném formátu zpět informačnímu systému, který je dále zpracovává.

Vzhledem k tomu, že každý rejstřík průmyslových práv je veden jinou zemí (jejím patentovým úřadem), nejsou data, která služba potřebuje získat, shodně strukturována a neexistuje ani, vyjma evropského patentového úřadu, jednoznačný způsob jejich publikace. Proto musí být služba individuálně přizpůsobena jednotlivých patentovým úřadům a jejich formátům publikace dat. Některé úřady publikují data alespoň ve vlastních definovaných XML formátech, zato některé úřady používají ke zveřejňování informací ze svých databází výhradně internetové stránky. V takovém případě je služba nucena za použití technologií screen-capturingu a web crawlingu číst data přímo z jejich webů a na základě definovaných pravidel rozpoznávat jejich obsah, aby dokázala data sumarizovat do jednoznačné struktury a formy.

Volba metodiky pro hodnocení služby

Vzhledem k tomu, že služba byla navržena podle ITIL V3, budu při výběru hodnotících kritérií vycházet z tohoto procesního rámce. ITIL V3 se skládá z pěti klíčových procesů (ponechávám originální názvy): Service Strategy, Service Design, Service Transition, Service Operation a Continual Service Improvement. Každý z nich se pak dále dělí na více sub-procesů, které pokrývají vždy dílčí oblast klíčového procesu. Každý ITIL proces má zpravidla následující strukturu, kterou definuje:

"účel, záměry a cíle,
rozsah,
hodnotu pro podnikání,
politiky (strategie), principy a základní koncepty,
činnosti, metody a metodiky,
spouště, vstupy, výstupy a rozhraní,
klíčové indikátory výkonnosti (KPI) nebo metriky,
výzvy (čeho lze ještě dosáhnout), kritické faktory úspěchu (CSF) a rizika." [1]

Naproti tomu CobiT 4.1 se skládá ze 4 klíčových oblastí (opět ponechávám originální názvy): Plan and Organise, Acquire and Implement, Deliver and Support a Monitor and Evaluate. Každá tato oblast obsahuje definované procesy, které hodnotí využití IT zdrojů (IT Resources) podle definovaných informačních kritérií (Information Criteria).

„Chce-li podnik být schopen reagovat na obchodní požadavky na IT, musí investovat do zdrojů potřebných k vytvoření dostatečné technické způsobilosti (např. ERP systém) pro podporu podnikání (např. zavedení dodavatelského řetězce), což povede k požadovanému výsledku (např. zvýšení tržeb a finanční výhody).“ [2]

Do IT zdrojů řadí CobiT:

aplikace – automatizované systémy a manuální procedury, které zpracovávají informace,
informace – data ve všech svých formách, vstupy i výstupy informačních systémů v jakékoliv formě využívané pro podnikání,
infrastruktura – jsou technologie a zařízení (hw, os, db, nt apod.), které umožňují práci aplikací,
lidé – personál potřebný k plánování, organizování, získávání, implementaci, doručení, podpoře, sledování a vyhodnocování informačních systémů a služeb.
Mohou být vnitřní, outsoursovaní nebo najatí podle potřeby." [4]

Pro hodnocení definuje CobiT sedm kritérií:

Efektivita – určuje, zda je informace relevantní k byznys procesu stejně tak, jako že je doručena včas, správně, konzistentní a lze ji použít.
Účinnost – týká se poskytování informace za optimálního (produktivního, ekonomického) využití zdrojů.
Důvěrnost – spočívá v ochraně citlivých informací před nepovoleným odhalením,
Integrita – se vztahuje k přesnosti a kompletnosti informace, stejně tak k její platnosti ve vztahu k obchodním cílům a očekáváním,
Dostupnost – určuje, zda je informace dostupná, když ji proces vyžaduje. Zároveň se stará o hlídání potřebných zdrojů.
Soulad – určuje, zda jsou dodržovány zákonné požadavky, omezení a smluvní podmínky, ke kterým se proces vztahuje, stejně tak jako vnitřní nařízení.
Spolehlivost – vztahuje se k poskytování příslušných informací pro management, aby byl schopen zodpovědně vykonávat své povinnosti.

Každý CobiT proces je rozdělen do čtyř základních sekcí obsahujících klíčové komponenty, zdroje a kritéria:

sekce 1 – obsahuje popis jednotlivého procesu, sumarizující jeho cíle a mapování na informační kritéria a IT zdroje
sekce 2 – obsahuje kontrolní cíle pro tento proces,
sekce 3 – obsahuje vstupy a výstupy procesu, RACI model a metriky,
sekce 4 – obsahuje model zralosti pro každý proces

Aby mohl být na zhodnocení zkoumané služby použit CobiT 4.1, je potřeba provést mapování ITIL procesů na jednotlivé komponenty CobiT nacházející se v dílčích sekcích.

Při výběru kritérií budu postupovat tak, že nejprve zvolím příslušný proces dle ITIL V3, dle mapy pro vzájemné mapování ITIL a CobiT [1] zvolím příslušnou komponentu CobiT a měřením její metriky zjistím naplnění cíle a provedu vlastní zhodnocení.

Výběr nejrizikovějších oblastí pro provedení auditu

Ke zhodnocení kvality služby provedu výběr nejrizikovějších oblastí, které mají zásadní vliv na běh služby, a tyto oblasti podrobím detailní kontrole. Rizika, která na dané oblasti působí, jsou definována svým dopadem a pravděpodobností výskytu. Volím proto oblasti, která tvoří úzká místa služby a chyby v nich vzniklé mají dopad na celkovou funkčnost.

Každou oblast návrhu služby dle ITIL V3 hodnotím z pohledu složek rizika dle IT Assurance Guide [4]: chráněného aktiva, možného poškození, zranitelnosti, ochranných opatření, a pravděpodobnosti výskytu.

Vzhledem k výše uvedenému vynechávám záměrně část Service Strategy. Do této oblasti patří strategické plánování služby, jako jsou procesy definice trhu, určení příležitostí, finanční management, vytvoření nabídky apod. Tyto procesy nejsou z pohledu jediné služby tolik významné, jako její vlastní naplánování a provozování. Chráněným aktivem je informační systém a výpadek dané služby způsobuje nefunkčnost jeho části. Hrozbu tedy tvoří poškození dané služby, výpadky nebo nenaplnění definovaných požadavků na její úroveň. Tyto problémy mají také z pohledu provozu služby nejvyšší pravděpodobnost výskytu. Stejně tak vynechávám Continual Service Improvement zaměřující se na údržbu a zlepšování kvality služby.

Budu se držet jen kritických oblastí, kterými jsou návrh, nasazení a provozování služby, a z těchto oblastí volím podle mě tu nejdůležitější část ITIL V3 a to Service Design.

Z této části volím procesy Service Level Management, Availability Management a IT Service Continuity Management. Tyto procesy jsou nejdůležitější pro návrh služby. Jejich správné provedení zajišťuje řádnou úroveň kvality služby, dostupnost služby a ochranu před výpadkem služby.

Posouzení úrovně vyspělosti dílčích procesů služby

Zmíněná služba se skládá z mnoha dílčích procesů. Dále zmiňuji ty nejvýznamnější, které jsou kritické pro chod služby, a uvádím jejich popis a metriku jejich úspěšného provedení.

Přijetí požadavku

Popis: Služba je schopna na definovaném rozhraní přijmout požadavek.
Metrika: Doba přijetí požadavku. Od přijetí prvních dat, až do přijetí posledního bytu.

Kontrola vstupních údajů

Popis: Služba zkontroluje validitu vstupních dat.
Metrika: Doba provedení kontroly.

Klasifikace vstupních údajů

Popis: Služba určí ze vstupních údajů druh práva, číslo práva a cílovou zemi.
Metrika: Doba provedení klasifikace.

Určení cílového rejstříku

Popis: Na základě klasifikovaných vstupních údajů vybere služba cílový rejstřík práv.
Metrika: Doba určení rejstříku.

Volba dotazu na cílový rejstřík

Popis: Na základě druhu cílového rejstříku zvolí služba způsob dotazování.
Metrika: Způsob volby dotazování.

Dotaz na cílový rejstřík

Popis: Dle zvoleného druhu dotazu připraví služba dotaz a odešle ho na cílový rejstřík
Metrika: Doba potřebná k napojení na cílové rozhraní.

Přijetí požadavku z cílového rejstříku

Popis: Služba přijme data z cílového rejstříku dle návratového formátu cílového rejstříku.
Metrika: Doba odezvy odpovědi cílového rejstříku.

Formátování návratové hodnoty

Popis: Služba formátuje přijatá data do jednotného formátu.
Metrika: Doba provedení formátování.

Předání odpovědi na požadavek

Popis: Služba vrátí formátovaná data na definovaném rozhraní.
Metrika: Celková doba provedení požadavku.

Všechny uvedené procesy mají detailně popsaný průběh programovým kódem, vstupy i výstupy mají definovanou strukturu a u všech bylo provedeno testování několika možných způsobů realizace. U všech procesů předpokládáme aktuálně nejrychlejší možný způsob provedení. Jelikož právě rychlost je u nich hlavním měřítkem, můžeme tyto procesy považovat z hlediska vyspělosti určitě za plně řízené (úroveň 4), případně i optimalizované (úroveň 5). Pátou úroveň však nemůžeme určit se 100% jistotou, protože nevíme, zda ještě neexistuje jiný způsob rychlejšího provedení.

Provedení hodnocení

Hodnocení provedu tak, že budu postupně mapovat ITIL V3 procesy na CobiT 4.1 a provádět jejich hodnocení podle IT Assurance Guide [4] roadmap. U každého CobiT procesu určím generátor hodnoty a zhodnotím možná rizika i kvalitu ochranných opaření.

Mapuji jen ty procesy, které jsou z hlediska dané služby relevantní. Pokud není některý proces využíván (např. neexistují subdodavatelé, tedy ani smlouvy s nimi), nebude daný proces mapován, ani hodnocen. Taktéž vybírám jen hlavní procesy, které jsou pro danou službu klíčové. Pro snadnou orientaci v mapování ponechávám názvy procesů v originálním znění.

Service Level Management

ITIL V3	CobiT 4.1
SD 4.2.5.1 Designing SLA frameworks	DS1.1 Service level management framework
SD 4.2.5.2 Determine, document and agree requirements for new services and produce SLR	AI2.2 Detailed design DS1.3 Service level agreements
SD 4.2.5.3 Monitor service performance against SLA	DS1.5 Monitoring and reporting of service level achievements
SD 4.2.5.4 Collate, measure and improve customer satisfaction	PO8.4 Customer focus DS1.6 Review of service level agreements and contracts
SD 4.2.5.5 Review and revise underpinning agreements and service scope	DS1.4 operating level agreements DS1.6 Review of service level agreements and contracts
SD 4.2.5.6 Produce service reports DS1.5	DS1.5 Monitoring and reporting of service level achievements
SD 4.2.5.7 Conduct service reviews and instigate improvements within an overall SIO	PO8.5 Continuous improvement DS1.5 Monitoring and reporting of service level achievements ME1.4 Performance assessment
SD 4.2.5.8 Review and revise SLAs, service scope and underpinning agreements and contracts agreements	DS1.6 Review of service level
SD 4.2.5.9 Develop contracts and relationships	PO4.15 Relationships AI5.2 Supplier contract management DS1.1 Service level management framework DS2 Manage third-party services DS2.2 Supplier relationship management
SD 4.2.5.10 Complaints and compliments	DS1.5 Monitoring and reporting of service level achievements ME1.2 Definition and collection of monitoring data

AI2.2 Detailed design

Kontrolní cíle: Definované požadavky na službu a kritéria jejího hodnocení.
Generátor hodnoty: Efektivní aplikační kód, vyhnout se redundanci dat, aplikace splňuje požadovaná kritéria
Generátor rizika: Zpracování neplatných transakcí, data jsou chybně zpracována
Metriky: Chyby v kódu, kvalita architektury aplikace, správnost analýzy a návrhu aplikace.
Hodnocení: Před nasazením bylo provedeno opakované testování. Analýza i návrh architektury aplikace byly provedeny dle objektově orientované analýzy a návrhu za použití UML. Na závěr návrhu služby byla provedena kontrola konzistence událostí, akcí a stavů.

DS1.3 Service level agreements

Kontrolní cíle: Definované a odsouhlasené SLA. Důraz na dostupnost, spolehlivost, výkon, kapacitu, úroveň podpory, ochranu před pádem, bezpečnost.
Generátor hodnoty: Soulad mezi kvalitou služby, IT cíli a byznys požadavky.
Generátor rizika: Neschopnost dosáhnout požadavků odběratele služby, neefektivní a neúčinné užití služby, neschopnost identifikovat incidenty a reagovat na ně.
Metriky: Existence SLA, správná struktura SLA, určení zodpovědnosti IT za provoz služby, existence řízení životního cyklu SLA.
Hodnocení: Definice úrovně služby sice existuje, ale ne ve formě klasické SLA. Jsou pouze určeny zodpovědnosti IT a časy pro nápravu zaznamenaných chyb. Neexistuje jednotný způsob reportování chyb, neexistuje řízení SLA – odchycené chyby nejsou reflektovány aktualizací SLA.

DS1.5 Monitoring and reporting of service level achievements

Kontrolní cíle: Průběžné sledování kritérií výkonnosti služby, reportování v podobě srozumitelné pracovníkům vedení, analýza statistik provozu služby pro určení budoucího vývoje provozu služby.
Generátor hodnoty: Uživatelé služby mohou sledovat výkonnost, konzistentní komunikace mezi dotčenými subjekty.
Generátor rizika: Nedefinované primární problémy, nespokojenost uživatelů z nedostatku informací.
Metriky: Měkké metriky jako subjektivní hodnocení uživatelů, existence analýz sesbíraných statistik z provozu služby.
Hodnocení: Uživatelé mají přímou vazbu na IT podporu provozu služby, reakce je okamžitá (email, telefon). Statistiky provozu se sice vytvářejí, ale neexistuje jejich následná analýza. Využívají se jen pro zjištění původu incidentů.

DS1.6 Review of service level agreements and contracts agreements

Kontrolní cíle: Pravidelná kontrola SLA a zajištění jejího souladu s aktuálními požadavky.
Generátor hodnoty: Dodávané IT služby jsou v souladu s byznys požadavky.
Generátor rizika: Služby nesplňuje měnící se požadavky. Vniklé incidenty a finanční ztráty způsobené nepřizpůsobenými službami.
Metriky: Plán revizí SLA. Dodržování plánu.
Hodnocení: Vzhledem k neexistenci klasické SLA není veden ani plán její revize. Vznikající požadavky na změny jsou řešeny v rámci smlouvy o údržbě.

Availability management

ITIL V3

CobiT 4.1

SD 4.4.5.1 The reactive activities of availability management

DS3.4 IT resources availability

DS3.5 Monitoring and reporting

SD 4.4.5.2 The proactive activities of availability management

DS3.4 IT resources availability

DS4.3 Critical IT resources

DS4.8 IT services recovery and resumption

DS3.4 IT resources availability

Kontrolní cíle: Požadovaná kapacita a výkonnost s ohledem na zátěž, pohotovost a požadavky na úložiště.
Generátor hodnoty: Správné užití IT zdrojů.
Generátor rizika: Nedostupnost způsobená pádem IT zdrojů, nemožnost předvídat dostupnost služeb. Neočekávané výpadky služeb.
Metriky: Prioritizovaný seznam činností podporovaných IT aplikacemi, aktualizovaný plán kapacit, míra zavedených opravných opatření, správná procedura eskalace incidentů.
Hodnocení: Seznam činností, které služba podporuje, vychází z definice informačního systému, jehož je součástí. IS byl navržen pomocí OOAD a UML, obsahuje prioritizované požadavky včetně požadavků na službu. Plán kapacit ale neexistuje, stále je v platnosti jen navržená kapacita při uvedení o provozu. Opravná opatření se zavádějí dle smlouvy o údržbě. Stanovené časy jsou dodržovány. Eskalace incidentů není definována. Každý incident je předán IT správě k vyřešení. Požadavky na změny funkcionality jsou řešeny zvlášť společně s aktualizacemi celého IS. Protože neexistuje plán rozvoje služby, nelze ani měřit, zda jsou opravy a změny efektivně prováděny.

DS3.5 Monitoring and reporting

Kontrolní cíle: Pravidelná kontrola kapacity a výkonnosti IT zdrojů.
Generátor hodnoty: Identifikace problémů majících vliv na efektivitu poskytování služby
Generátor rizika: Nedostatek monitoringu. Odchylky nejsou včas identifikovány a negativně ovlivňují službu.
Metriky: Četnost kontrol IT zdrojů, odezva na nalezené problémy.
Hodnocení: Kontroly funkčnosti IT zdrojů jsou prováděny v denních intervalech. Výsledky jsou zaznamenávány a předávány odpovědným osobám v rámci pravidelných reportů. V případě nedostatku kapacity jsou přijímána ochranná opatření – rozšiřování kapacity IT zdrojů, úpravy kódu aplikací apod. Opatření jsou však lehce zpožděná a občas dochází ke snížení výkonnosti služby.

DS4.3 Critical IT resources

Kontrolní cíle: Zaměřit se na položky, které jsou kritické z hlediska udržení plynulosti provozu služby. Určení priorit v plánu obnovy provozu.
Generátor hodnoty: Prioritizované řízení obnovy provozu.
Generátor rizika: Nedostupnost kritických IT zdrojů, vzrůstající náklady na udržení plynulosti provozu služby.
Metriky: Plán obnovy provozu pro kritické funkce.
Hodnocení: Pro správné fungování služby jsou kritické všechny procesy, ze kterých se služba skládá. Výpadek kteréhokoliv z nich způsobuje téměř úplnou nefunkčnost celé služby. Částečná nefunkčnost může být způsobena nefungujícím určením cílového rejstříku. V případě, že dotazy v době výpadku na tento rejstřík nesměřují, může služba jinak plnit svou funkci. Správný chod všech procesů je zajištěn pravidelným testováním. Existuje plán průběžného testování dostupnosti všech rejstříků. Služba se pravidelně dotazuje na nahodilá práva a ověřuje dostupnost odpovědí z rejstříků. Výpadek rejstříku, i když se jedná o neovlivnitelný IT zdroj, také způsobuje nedostupnost celé služby. V případě nedostupnosti rejstříku jsou uživatelé ihned informování (výstražná oznámení v informačním systému, emailová zpráva apod.)

DS4.8 IT services recovery and resumption

Kontrolní cíle: Plán obnovy provozu, komunikace s uživateli při obnovování provozu, záložní IT zdroje a jejich uvedení do provozu v případě výpadku.
Generátor hodnoty: Minimální čas a náklady obnovy provozu.
Generátor rizika: Nedostatky v plánech obnovy, špatně definované procedury obnovy.
Metriky: Čas obnovy provozu, náklady obnovy provozu, četnost revizí plánů obnovy.
Hodnocení: Obnova provozu je součástí smlouvy o údržbě. Časy jsou většinou minimalizované, reakční doba okamžitá. Náklady jsou součástí pravidelných plateb za správu provozu. Některé IT zdroje je ale nutné obnovovat delší dobu – aplikační server a jeho programové vybavení. Pád tohoto IT zdroje by měl za následek minimálně 24 hodinový výpadek provozu služby. Neexistuje záložní aplikační server. Data jsou zálohována na oddělený HW. V databázovém serveru jsou zrcadlová disková pole. Výpadek disku nemá vliv na provoz. Datové spoje jsou zálohované oddělenou přípojkou.

Service continuity management

SD 4.5.5.1 Stage 1—Initiation	PO9.1 IT risk management framework PO9.2 Establishment of risk context DS4.1 IT continuity framework
SD 4.5.5.2 Stage 2—Requirements and strategy	PO9.2 Establishment of risk context PO9.3 Event identification PO9.4 Risk assessment AI1.2 Risk analysis report DS4.2 IT continuity plans DS4.9 Offsite backup storage
SD 4.5.5.3 Stage 3—Implementation (vague match)	PO9.5 Risk response DS4.2 IT continuity plans DS4.5 Testing of the IT continuity plan DS4.6 IT continuity plan training DS4.7 Distribution of the IT continuity plan DS4.10 Post-resumption review
SD 4.5.5.4 Stage 4—Ongoing operation	PO9.6 Maintenance and monitoring of a risk action plan DS4.3 Critical IT resources DS4.4 Maintenance of the IT continuity plan DS4.5 Testing of the IT continuity plan DS4.6 IT continuity plan training DS4.7 Distribution of the IT continuity plan DS4.8 IT services recovery and resumption DS4.10 Post-resumption review
SD 4.6 Information security management	DS5.1 Management of IT security

PO9.3 Event identification

Kontrolní cíle: Identifikace událostí s potenciálním negativním dopadem na cíle podniku. Určení původu události.
Generátor hodnoty: Konzistentní přístup k identifikaci rizik.
Generátor rizika: Zaměření se na irelevantní rizika na úkor těch významných.
Metriky: Proces řízení rizik. Jeho existence a postavení v rámci analýzy a návrhu a v rámci provozu služby.
Hodnocení: Hlavním a nejvýznamnějším rizikem služby je dodání chybné odpovědi na vznesený dotaz. Toto riziko je mnohem významnější než nedostupnost celé služby. Chybná odpověď způsobí mylnou identifikaci práva. Ta zase způsobí, že s vrácenými daty bude IS pracovat jinak, než by měl. To může mít fatální následky na jeho provoz. Správnost vrácených dat je potřeba permanentně hlídat. To je zabezpečeno na dvou místech – jednak jsou kontrolovány už vstupy do služby, především číslo práva je podrobeno kontrole založené na sérii pravidel, aby bylo zajištěno, že se služba na rejstříku bude dotazovat správnými vstupními daty. Výstupní data ze služby jsou opět ověřena těmito pravidly, aby i výstupní data byla korektní.

PO9.5 Risk response

Kontrolní cíle: Kontrola údržby procesu reagujícího na riziko, navrženého k nákladově efektivnímu zmírnění rizika. Proces reakce na riziko musí zahrnovat identifikovat strategie jako vyhnutí se riziku a redukci rizika a určovat odpovědnosti. Je vhodné zvážit úrovně tolerance rizika.
Generátor hodnoty: Efektivní řízení rizika, konzistentní přístup k vyhnutí se riziku, nákladově efektivní reakce na riziko
Generátor rizika: Neefektivní reakce na riziko, neidentifikované zbytkové riziko (riziko, které zůstává po odstranění známých rizik), spoléhání se na stávající slabé kontroly
Metriky: Zbytkové riziko, plány reakce na riziko
Hodnocení: Zbytkové riziko není definované. Jsou definována rizika v oblasti chodu aplikací, HW a síťové infrastruktury a jsou naplánovány potřebné akce ke snížení rizika vzniku chyb v těchto tradičních oblastech. IT sekce tyto oblasti sleduje, ale nejsou rozděleny do skupin dle pravděpodobnosti výskytu a míry dopadu. Další možná rizika nebyla zvážena.

DS4.5 Testing of the IT continuity plan

Kontrolní cíle: Plán kontinuity provozu IT, efektivní zotavení IT, identifikace nedostatků.
Generátor hodnoty: Efektivní plány obnovy IT, zaměstnanci zkušení s procesem obnovy, aktualizované plány překonávající nedostatky v obnově systémů
Generátor rizika: Nedostatky v plánech obnovy nebo zastaralé plány, nevhodné kroky při obnově. Neschopnost efektivní obnovy může způsobit vznik skutečné škody.
Metriky: Pravidelné testy kontinuity IT a aktualizace podle výsledků testů. Zhodnocení dokumentace k plánům.
Hodnocení: Kontinuita provozu IT je zajištěna kontrolou dat, aplikací i infrastruktury. U služby není příliš rozlišeno mezi IT a byznys kontinuitou a odpovědnost je přenesena především na IT. IT pravidelně testuje zálohování, aplikace i infrastrukturu. Jak bylo uvedeno už v procesu IT Service Recovery, chybí především záloha aplikačního serveru. Samotná sekce IT má vícečlenný tým, výpadek osob nebo u ní nemá vliv na chod. Vlastní infrastrukturu má zálohovanou, takže je dostupná i při jejím výpadku. V případě výpadku je vše zaznamenáno jen na straně IT a odpovědní pracovníci na byznys straně ani nemusí o výpadku vědět. IT sekce je příliš samostatná.

DS5.1 Management of IT security

Kontrolní cíle: Zhodnocení kvality řízení bezpečnosti, a zda je v souladu s byznys cíli organizace.
Generátor hodnoty: Ochrana kritických IT hodnot, správně zavedené bezpečnostní postupy, konzistentní se zákonnými požadavky a bezpečnostními standardy.
Generátor rizika: Nedostatečné řízení bezpečnosti, nechráněná data a informace.
Metriky: Napadnutelnost aplikací, dat, infrastruktury i lidí.
Hodnocení: Bezpečnost je v organizaci na vysoké úrovni. Jsou pravidelně prováděny testy napadnutelnosti systémů (HW, SW i infrastruktura). Data jsou pravidelně zálohována na externí zařízení a ty jsou bezpečně ukládána na místa s řízeným přístupem včetně protipožární ochrany. Bezpečnostní procesy jsou plně optimalizované, včetně pravidelné aktualizace a reakce na měnící se požadavky. Jsou definovány bezpečnostní politiky pro všechny osoby (používání výměnných datových nosičů, emailů, Internetu, notebooků a přenosných zařízení) a jsou přesně vymezeny kompetence a odpovědnost jednotlivých pracovníků.

Výsledky provedených testů kontrolních cílů

Každý CobiT proces byl zhodnocen na možná rizika, byly provedeny testy kontrolních cílů a bylo hodnoceno, do jaké míry jsou naplněny. U každého procesu je určen generátor hodnot, tedy ty atributy procesu, které přináší kvalitu. Stejně tak jsem u každého procesu vytyčil hlavní rizikové oblasti, které je potřeba mít na paměti a zahrnout je do kontrolních plánů. Dále uvádím hrubý nástin obsahu závěrečné auditorské zprávy po hodnocení služby pro získávání údajů o průmyslových právech, fungující v rámci komplexního informačního systému v průmyslově právní oblasti.

Zhodnocení kvality

Kvalitní příprava služby, použití standardů při návrhu i analýze. Krátké reakční časy při komunikaci mezi IT podporou a uživateli služby. Chyby jsou zaznamenávány a ukládány, uživatelé jsou ihned informováni o zprovoznění. Přímá komunikace uživatelů s podporou provozu.

Pro většinu IT zdrojů existuje plán obnovy a jsou dostupné záložní zdroje (jak hardwarové, tak i softwarové). Data jsou 2x zálohována včetně přenosu mimo provozní zařízení. Záloha HW ale není kompletní, některé HW zdroje nejsou zálohovány vůbec nebo nedostatečně (viz doporučení).

Jsou definovány události s negativním dopadem na provoz služby a adekvátní ochranná opatření. Základní negativní dopady lze předvídat a odstranit.

Samotná aplikace je navržena dobře. Její provoz je průběžně monitorován a odchylky od definovaných kritérií provozu jsou zaznamenávány. Vstupy i výstupy jsou vícenásobně kontrolovány.

Kontinuita provozu IT je zajištěna kontrolou dat, aplikací i infrastruktury. V případě výpadku je vše zaznamenáno jen na straně IT a odpovědní pracovníci vedení nejsou zpravidla informováni. IT sekce je příliš autonomní.

Vyspělé řízení bezpečnosti. V organizaci jsou zavedeny, dodržovány a aktualizovány bezpečnostní politiky a jsou pravidelně prováděny průnikové testy. Citlivá data jsou v databázových systémech šifrována, zálohována a bezpečně uložena mimo zařízení. Ačkoliv organizace nemá certifikaci řízení bezpečnosti a ani neprošla bezpečnostním auditem, je její řízení bezpečnosti na vyspělé úrovni. Mnoho prvků řízení bezpečnosti je shodných s ISO 27001 pro ISMS (Information Security Management System).

Způsob hodnocení zralosti procesů

Úroveň zralosti procesů lze hodnotit podle doporučení IT Assurance Guide [5]. U každého procesu posoudíme následující atributy:

povědomí o procesu a komunikace
politiky, plány a procedury,
nástroje a automatizace,
zkušenosti a odbornost,
odpovědnost (např. vlastník procesu) a povinná zodpovědnost (např. zákonná)
způsob měření dosažení cíle a metriky.

Např. proces DS3.5 Monitoring and reporting lze hodnotit následovně:

Povědomí o procesu a komunikace

Existuje plné porozumění procesu. Organizace zná jeho průběh, vlastníka, ovlivněné subjekty i zdroje. Mezi zúčastněnými stranami probíhá rychlá komunikace za použití standardních komunikačních kanálů (email, telefon).

Politiky, plány a procedury

Proces je zdokumentovaný a opakovatelný. Interní předpisy (především bezpečnostní) jsou v něm zahrnuty, management vede proces v evidenci. Řízení procesu je založeno na standardech (vychází z ITIL V3 Service Design) a jsou zavedeny procedury jeho provádění. Monitorování a reportování je součástí stanovené údržby služby ze strany IT sekce. Existuje odsouhlasený dokument o provádění této procedury.

Nástroje a automatizace

Jsou použity nástroje pro automatické zaznamenávání chyb a výjimek při běhu služby. IT oddělení průběžně sleduje záznamy o chybách. Existuje nedostatek v pravidelném předávání výsledků vedení organizace.

Zkušenosti a odbornost

Příslušní pracovníci dohledu provozu služby jsou vyškoleni a pobíhá jejich pravidelná rekvalifikace v souvislosti s vývojem služby a přidávám nové funkcionality. Pracovníci dohledu nad specifickými technologiemi mají příslušné certifikace znalosti těchto technologií (databáze, aplikační framework apod.).

Odpovědnost

Vlastníkem procesu je odpovědný pracovník monitoringu. Jeho odpovědnost je definována v rámci IT sekce a je vyžadována a kontrolována (kontrola pravidelných reportů, které má na starost). Porovnáním vystavených reportů a záznamů chyb lze dokumentovat chybovost.

Způsob měření dosažení cíle a metriky

Je měřeno a ukládáno množství zaznamenaných chyb a odchylek od vyváženého stavu hlavně na aplikační a datové úrovni služby. Jsou vyhodnocovány požadavky uživatelů na podporu užívání služby. Údaje však nejsou plánovaně a pravidelně předávány odpovědným pracovníkům vedení mimo IT.

Porovnáme-li výše uvedené charakteristiky procesu DS3.5 Monitoring and reporting s maticí úrovní procesu můžeme úroveň zralosti tohoto procesu charakterizovat následujícím grafem.

Graf úrovně zralosti procesu DS3.5 Monitoring and reporting

Lze tedy konstatovat, že daný proces se nachází převážně v úrovni 4 (řízený proces). Naproti tomu některé jeho atributy sklouzávají do nižší úrovně (definovaný proces) a zaslouží si tedy primární pozornost.

Obdobně lze provést hodnocení i ostatních procesů.

Doporučení

Vytvořit SLA s definovanou strukturou. Zavést konzistentní způsob reportování od IT sekce k vedení organizace nebo alespoň k manažerovi služby. Odchycené chyby nevedou ke změnám SLA. Neexistuje plán rozvoje služby. Urychlit přijímání opatření k zajištění kapacity IT zdrojů.

Nedokonalý plán obnovy služby (business recovery plan). Služba má špatně naplánované a provozované záložní plány a plány obnovy provozu po havárii. Chybí záložní aplikační server – obnova tohoto IT zdroje by zabrala neakceptovatelnou dobu.

Není podrobně řízeno riziko. Neexistuje plán reakce na riziko, tyto procesy se aktivují až se vznikem problému, což už je pozdě. Je potřeba zavést prioritizovaný plán zohledňující možné výskyty rizika v IT i byznys oblasti. Je potřeba alespoň rámcově znát zbytkové riziko a připravit reakční procesy k jeho zmírnění.

U služby není rozlišeno mezi IT a byznys kontinuitou a odpovědnost je přenesena především na IT. Je vhodné striktně rozdělit IT a byznys kontinuitu a zavést řízené plány testování zachování provozu jak IT oblasti, tak byznys oblasti samostatně.

IT sekce je příliš autonomní, což vede k zakrývání vzniklých problémů. Incidenty jsou sice včas řešeny, ale nejsou reportovány v sumarizované podobě vedení organizace. To má za následek, že vedení organizace nemá přesnou představu o množství oprav a nemůže efektivně řídit náklady na provoz a údržbu.

Použitá literatura

1. Mapping of ITIL v3 With COBIT® 4.1, str. 20, 2007 IT Governance Institute, ISBN 978-1-60420-035-5, dostupné z www http://www.isaca.org/Knowledge-Center/Research/ResearchDeliverables/Pages/COBIT-Mapping-Mapping-of-ITIL-V3-With-COBIT-4-11.aspx

2. Mapping of ITIL v3 With COBIT® 4.1, ISACA, str. 12, 2007 IT Governance Institute, ISBN 978-1-60420-035-5, dostupné z www http://www.isaca.org/Knowledge-Center/Research/ResearchDeliverables/Pages/COBIT-Mapping-Mapping-of-ITIL-V3-With-COBIT-4-11.aspx

3. IT Assurance Guide: Using COBIT®, 2007 IT Governance Institute, ISBN 1-933284-74-9, dostupné z www http://www.isaca.org/Knowledge-Center/Research/ResearchDeliverables/Pages/IT-Assurance-Guide-Using-COBIT.aspx

4. Mapping of ITIL v3 With COBIT® 4.1, str. 45, 2007 IT Governance Institute, ISBN 978-1-60420-035-5, dostupné z www http://www.isaca.org/Knowledge-Center/Research/ResearchDeliverables/Pages/COBIT-Mapping-Mapping-of-ITIL-V3-With-COBIT-4-11.aspx

5. IT Assurance Guide: Using COBIT®, str. 29, 2007 IT Governance Institute, ISBN 1-933284-74-9, dostupné z www http://www.isaca.org/Knowledge-Center/Research/ResearchDeliverables/Pages/IT-Assurance-Guide-Using-COBIT.aspx